Hello,
On Tue 23 Jul 2019 at 01:21PM +10, Stuart Prescott wrote:
> A more general question about these data -- is there enough information in
> the dsc and Git-Tag-Info/Git-Tag-Tagger to know *what* was signed and where
> it is located? I like that the proposal is to maintain the signer's
> infor
Hello,
On Mon 22 Jul 2019 at 07:55PM +01, Ian Jackson wrote:
> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package. To rememdy that I propose the following new field:
>
> Git-Tag-Info: FINGERPRINT
Jonathan Nieder writes:
> For command line options like "-b", I would be okay with following the
> same model as last time and using space as a source of extensibility
> (i.e., breaking compatibility). So for that I wouldn't want to use
> the bracket syntax.
> For future settings in the same sp
Russ Allbery wrote:
> If you want to do what vcswatch is doing (analyze the current code
> repository for Debian packaging for commits that haven't been uploaded),
> and the team is, like Haskell, using a single repository for all the
> packages, you need to be able to find that specific package i
Jonathan Nieder writes:
> In Git, when you "git clone" a repository, that represents a single
> codebase. There is no parameter you can pass to "git clone" that
> tells it to clone just a subdirectory. So we aren't including the
> in Vcs-Git in order to determine what parameters to pass to
> "
Hi,
Ian Jackson wrote:
> Russ Allbery writes:
>> So, maybe something like:
>>
>> -b [; = ...]
>>
>> to build off of what we already have? (With, obviously, a bunch of that
>> syntax marked as optional.) If we ban "=" in , we can allow for
>> to be optional but some other key/value pair t
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
>> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
>> info in .dsc [and 1 more messages]"):
>> > Git-Tag-Info: fingerprint=FING
Ian Jackson writes:
> SGTM. We can specify that [ ] contains optional information. I guess
> that is why that syntax was chosen...
> Then critical information which *should* cause an old parser to fail
> can also be added.
> So the overall syntax is roughly
>[ " -b " ] [ " " ]
> [
Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
info in .dsc [and 1 more messages]"):
> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagg
Russ Allbery wrote:
> Git-Tag-Info: fingerprint=FINGERPRINT
> Git-Tag-Tagger: Firstname Surname
>
> and then Git-Tag-Info could be extended later using additional key/value
> pairs to hold other information, use spaces or commas between attributes,
> and so forth? For instance, that woul
Sean Whitton writes:
> On Sun 14 Jul 2019 at 10:22AM +02, Ansgar wrote:
>> How should we continue with this issue?
>
> Thank you for following up.
>
> I still do not see any positive reason for deleting documentation which
> might be helpful to someone, especially when discussion in the bug has
> i
Hi,
adding Sean to cc: for the question mentioned below.
On Mon, Jul 22, 2019 at 11:24:41PM +0900, Osamu Aoki wrote:
> Do you know anyone good in this. Is there any volunteer? (I am
> seeking help on the mailinglist at sphinx-us...@googlegroups.com now)
I'm currently constantly asking on the
On Mon, 22 Jul 2019 20:54:29 +0100, Ian Jackson wrote:
> > Unfortunately , doing something extensible within the field requires adding
> > a separator, which in turn requires dealing with escaping, and thus is
> > kind of a mess. Given that, what if you instead used two fields:
> >
> > Git-T
Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer info
in .dsc [and 1 more messages]"):
> One thing that jumps out at me here is that this field isn't extensible,
> since anything after the first space-separated word has to be taken to be
> the tagger line.
Hi. Thanks for
Ian Jackson writes:
> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package. To rememdy that I propose the following new field:
> Git-Tag-Info: FINGERPRINT Firstname Surname
> The parsing rules ar
Hi. I am consulting on the name and syntax of a new field I intend to
put in .dsc's.
This is for our tag-to-upload service[1], as described here:
https://spwhitton.name/blog/entry/tag2upload/
The tag2upload service will take a signed git tag, and verify it
against the Debian keyrings and dm.tx
Russ Allbery writes ("Re: Bug#932696: Please document Haskell team style
Vcs-Git sytax [and 1 more messages]"):
> So, maybe something like:
>
> -b [; = ...]
>
> to build off of what we already have? (With, obviously, a bunch of that
> syntax marked as optional.) If we ban "=" in , we can
Ian Jackson writes:
> Russ Allbery writes:
>> Sure, an extensible syntax sounds great. The problem is that we kind
>> of had one (Vcs-Git was a subset of a git checkout command line, which
>> allowed support of the -b option), but this (if I understand it
>> correctly) is a whole new type of thi
Russ Allbery writes ("Re: Bug#932696: Please document Haskell team style
Vcs-Git sytax [and 1 more messages]"):
> Sure, an extensible syntax sounds great. The problem is that we kind of
> had one (Vcs-Git was a subset of a git checkout command line, which
> allowed support of the -b option), but
Re-sending to the bug thread.
-- Forwarded message -
From: David Steele
Date: Mon, Jul 22, 2019 at 9:15 AM
Subject: Re: Bug#932704: debian-policy: Don't force sysvinit
compatibility if e.g. alternate init required
To: Sean Whitton
On Mon, Jul 22, 2019 at 7:02 AM Sean Whitton w
Hi,
On Mon, Jul 22, 2019 at 01:45:50AM +, Holger Levsen wrote:
...
> > Maybe, now I think Sphinx expert can take over to get proper packaging.
>
> yeah, indeed! ;)
Do you know anyone good in this. Is there any volunteer? (I am
seeking help on the mailinglist at sphinx-us...@googlegroups.c
On Mon, 22 Jul 2019 at 13:39:31 +0200, Ansgar wrote:
> What sort of dependencies are we talking about? Package-level
> dependencies (e.g. Depends: systemd-sysv directly or indirectly)?
Probably yes. systemd-cron and dbus-user-session are examples of packages
that rely on the systemd service manage
On Sun, Jul 21, 2019 at 08:29:16PM -0700, Russ Allbery wrote:
> Sure, an extensible syntax sounds great. The problem is that we kind of
> had one (Vcs-Git was a subset of a git checkout command line, which
> allowed support of the -b option), but this (if I understand it correctly)
> is a whole ne
On Mon, 2019-07-22 at 12:01 +0100, Sean Whitton wrote:
> > "Also, SysV-style init scripts may be omitted for packages which have
> > an explicit dependency on an alternate init system."
What sort of dependencies are we talking about? Package-level
dependencies (e.g. Depends: systemd-sysv directly
Hello,
On Sun 21 Jul 2019 at 08:46PM -04, David Steele wrote:
> In section 9.11 (The Operating System/Alternate init systems), it is
> stated that "...any package integrating with other init systems must
> also be backwards-compatible with sysvinit by providing a SysV-style
> init script...". The
On Sun, 21 Jul 2019 at 21:08:15 -0700, Russ Allbery wrote:
> I think it's clear that we're not making forward progress here, and the
> lack of a clear specification for the BROWSER environment variable doesn't
> seem to be causing a lot of noticable ongoing pain. I'm therefore going
> to close thi
26 matches
Mail list logo
