Processing commands for cont...@bugs.debian.org:
> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to '
Russ Allbery writes:
> If this already works, we should document it, since it can be quite
> useful. Here's an attempt at wording. Please check this and make sure
> that I'm correctly documenting what works.
I've now merged this patch for the next release.
--
Russ Allbery (r...@debian.org)
Processing commands for cont...@bugs.debian.org:
> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to '
Russ Allbery writes:
> Tobias Frost writes:
>> Looking at #262257, as an exampple, there are packages which declares
>> conflicts for whatever reason. However, the reason is NOT, that thec
>> packages could not co-existent on the same system (For the example,
>> retchmail could be also installed
Processing commands for cont...@bugs.debian.org:
> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to '
Steve Langasek writes:
> I think "invoke-rc.d" is wrong per se for this. Where the behavior of
> 'invoke-rc.d foo reload' differs from that of '/etc/init.d/reload', it's
> *incorrect* in the context of log rotation: the post-rotation reopening
> of logfiles should complete regardless of the runl
Russ Allbery writes:
> Yeah, there's that too. We're probably best off just saying that every
> package needs a maintainer. Hopefully it's clear enough since we're
> saying that the package needs one, not just the software.
Here's a patch which implements that. Objections or seconds?
diff --
Don Armstrong writes:
> On Mon, 05 Jul 2010, Russ Allbery wrote:
>> Well, they do, in that binNMUs do change the changelog included in the
>> package. I'm inclined to agree that it's not a big deal if we lose that
>> information in the installed package, though.
> Right; this is kind of an odd t
Sorry for coming back to this, I think I missed this new requirement
initially (or I skipped this thread, I don't remember...).
On Thu, Nov 12, 2009 at 23:28:11 -0800, Russ Allbery wrote:
> Charles Plessy writes:
> > Le Thu, Nov 12, 2009 at 10:22:37PM -0800, Russ Allbery a écrit :
>
> >> It's a
* Russ Allbery , 2010-07-07, 09:12:
+
+ The packages are the same version (both source and Debian
+ revision) with the possible exception of binary-only
+ rebuilds of one of the packages, since otherwise
+ the changelog.Debian.gz in one o
Jakub Wilk writes:
> * Russ Allbery , 2010-07-07, 09:12:
>>+
>>+ The packages are the same version (both source and Debian
>>+ revision) with the possible exception of binary-only
>>+ rebuilds of one of the packages, since otherwise
>>+ the changel
On Wed, 07 Jul 2010, Jakub Wilk wrote:
> This encourages arch:any -> arch:all symlinks, which is exactly what
> I wanted to be disallowed.
If we're going to allow any symlinks, these are the ones that are most
advantagous to allow, because otherwise we're duplicating
documentation and copyrights i
On Wed, Jul 07, 2010 at 05:36:34PM +0100, Julien Cristau wrote:
> > I'm also proposing changing the requirement for debian/copyright from a
> > should to a must. I believe that reflects existing practice. A package
> > that has no debian/copyright file is not going to make it into the archive
>
Steve Langasek writes:
> On Wed, Jul 07, 2010 at 05:36:34PM +0100, Julien Cristau wrote:
>> Russ Allbery writes:
>>> I'm also proposing changing the requirement for debian/copyright from
>>> a should to a must. I believe that reflects existing practice. A
>>> package that has no debian/copyrig
On Mon, Jul 05, 2010 at 07:16:52PM -0700, Russ Allbery wrote:
> Don Armstrong writes:
> > On Sun, 04 Jul 2010, Russ Allbery wrote:
> >> Here's the question: should we say flat-out that both packages must
> >> either be architecture-dependent or architecture-independent and then
> >> say that the
On Wed, Jul 07, 2010 at 11:59:51AM -0700, Don Armstrong wrote:
> I think there's some confusion here; [debian/changelog] documents changes
> to the source package, and as such, should always have the source
> version listed. [Binnmus have a changelog revision, but this is
> technically a violation,
Steve Langasek writes:
> OTOH, thinking ahead a little bit, if we *do* insist on requiring
> changelog entries for binNMUs in the package that may make things
> interesting for multiarch. Since binNMUS are per-architecture, binNMUS
> on two architectures may have the same version but different c
On Wed, Jul 07, 2010 at 05:30:57PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > OTOH, thinking ahead a little bit, if we *do* insist on requiring
> > changelog entries for binNMUs in the package that may make things
> > interesting for multiarch. Since binNMUS are per-architecture, bi
On Wed, 07 Jul 2010, Steve Langasek wrote:
> On Wed, Jul 07, 2010 at 11:59:51AM -0700, Don Armstrong wrote:
> > I think there's some confusion here; [debian/changelog] documents changes
> > to the source package, and as such, should always have the source
> > version listed. [Binnmus have a changel
Steve Langasek writes:
> On Wed, Jul 07, 2010 at 05:30:57PM -0700, Russ Allbery wrote:
>> Steve Langasek writes:
>>> OTOH, thinking ahead a little bit, if we *do* insist on requiring
>>> changelog entries for binNMUs in the package that may make things
>>> interesting for multiarch. Since binNM
20 matches
Mail list logo
