Le Sun, Sep 27, 2009 at 10:46:04AM +0200, Raphael Hertzog a écrit :
> - have dak check those fields (would avoid packages built on ubuntu being
> uploaded in debian)
Hi Raphaël,
That part may not be necessary since it was announced that all packages
distributed by Debian will be autobuilt:
D
Russ Allbery wrote:
> I wonder what's up with all the Gstreamer and Npp fields.
Those are used to find the needed package for autocodec installation when you
try to reproduce a package with a missing decoder/encoder/whatever (package
gnome-codec-install).
Cheers,
Emilio
signature.asc
Descripti
On Sat, 26 Sep 2009, Russ Allbery wrote:
> Paul Wise writes:
> > http://lintian.debian.org/tags/redundant-origin-field.html
>
> When I asked the dpkg developers about that, I think the answer was that
> dpkg's use was intended as an example of correct use.
Yes, but we also plan to auto-add the O
> George Danchev writes:
>
> >> Autobuild should probably go into Policy. It's used for non-free
> >> packages to indicate that it's legal for the buildds to build the
> >> packages.
> >>
> >> Original-Maintainer is odd -- Ubuntu uses that for packages imported
> >> and modified in Ubuntu, but
George Danchev writes:
>> Autobuild should probably go into Policy. It's used for non-free
>> packages to indicate that it's legal for the buildds to build the
>> packages.
>>
>> Original-Maintainer is odd -- Ubuntu uses that for packages imported
>> and modified in Ubuntu, but I'm not sure wha
> George Danchev writes:
>
> > Candidates for policy so far:
> > http://people.debian.org/~danchev/survey/sorted/4policy
> > (Multi-Arch field added)
>
> Oh, good, that's less than I thought there would be.
IMO, standardized fields (non-XBSC) are quite well documented in policy, and I
didn't
George Danchev writes:
> Candidates for policy so far:
> http://people.debian.org/~danchev/survey/sorted/4policy
> (Multi-Arch field added)
Oh, good, that's less than I thought there would be. We should probably
add Origin as well.
> The rest are user-defined fields (X[SBC]) which are possible
> George Danchev writes:
>
> > Okay, that sounds reasonable, provided all non-user-defined fields are
> > standard, or otherwise illegal. Another standard field (i.e. non-X[BSC]
> > ) I found is `Bugs'; seems they are hinting someone or something like
> > BTS or LP, though I'm not exactly sure if
Paul Wise writes:
> Sounds like it should be something documented in policy.
> lintian already complains about it:
> http://lintian.debian.org/tags/redundant-bugs-field.html
> I'm wondering why it is overriden by dpkg, any ideas?
> dpkg also overrides the Origin field, which is also strange.
On Sun, Sep 27, 2009 at 3:26 AM, Russ Allbery wrote:
> Bugs is sort of an interesting case since there's no reason to ever
> include it in a Debian package, but it's part of the package format and
> people making packages for non-Debian distributions should be aware of
> it. reportbug honors it
George Danchev writes:
> Okay, that sounds reasonable, provided all non-user-defined fields are
> standard, or otherwise illegal. Another standard field (i.e. non-X[BSC]
> ) I found is `Bugs'; seems they are hinting someone or something like
> BTS or LP, though I'm not exactly sure if it is good
> George Danchev writes:
>
> > So, the question being: from where to start documenting and sorting
> > these out: policy, dpkg/doc/, devref, wiki, blogs ;-), somewhere else.
>
> Standardized fields should be documented in Policy. Patches and
> contributions are definitely welcome. (And person
> George Danchev wrote:
> > You are correct, I missed these either because dpkg-scanpackages has not
> > been invoked with -tudeb or udebs are not built for the official
> > archive.
>
> They are in the official archive, but in separate sections (with their own
> Packages files): '.../main/debian
George Danchev wrote:
> You are correct, I missed these either because dpkg-scanpackages has not
> been invoked with -tudeb or udebs are not built for the official
> archive.
They are in the official archive, but in separate sections (with their own
Packages files): '.../main/debian-installer/bin
> George Danchev wrote:
> > I've recently done a little survey about the fields used in our control
> > files (*_Release files excluded). Currently there are ~80 different
> > fields [1] used in testing and unstable, which basically fall into these
> > groups:
>
> Looks like you did not include u
George Danchev writes:
> So, the question being: from where to start documenting and sorting
> these out: policy, dpkg/doc/, devref, wiki, blogs ;-), somewhere else.
Standardized fields should be documented in Policy. Patches and
contributions are definitely welcome. (And personally, I think
George Danchev wrote:
> I've recently done a little survey about the fields used in our control
> files (*_Release files excluded). Currently there are ~80 different
> fields [1] used in testing and unstable, which basically fall into these
> groups:
Looks like you did not include udebs in your s
On Fri, Sep 25, 2009 at 2:55 PM, George Danchev wrote:
> I've recently done a little survey about the fields used in our control files
> (*_Release files excluded). Currently there are ~80 different fields [1] used
> in
> testing and unstable, which basically fall into these groups:
>
> 1) listed
Hi,
I've recently done a little survey about the fields used in our control files
(*_Release files excluded). Currently there are ~80 different fields [1] used
in
testing and unstable, which basically fall into these groups:
1) listed in debian policy and accompanied sub-policies (like Python
19 matches
Mail list logo
