On Mon, Apr 23, 2001 at 04:52:08PM -0700, Sean 'Shaleh' Perry wrote:
> This would prevent the NMUers from doing things like debhelper/debconfizing
> packages without the maintainer's consent, as well as keep NMU bugs down.
Well, but other problems like broken dependencies on binary packages dont
g
* Mark Brown <[EMAIL PROTECTED]> [20010425 13:32]:
> It would be nice if this were more widely advertised (for example, it
> doesn't appear to be linked from http://qa.debian.org/). Such a list
fixed.
--
Martin Michlmayr
[EMAIL PROTECTED]
> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
Steve> On 23-Apr-01, 18:52 (CDT), Sean 'Shaleh' Perry
Steve> <[EMAIL PROTECTED]> wrote:
>> This would prevent the NMUers from doing things like
>> debhelper/debconfizing packages without the maintainer's
>> consent, a
On Tue, Apr 24, 2001 at 10:05:00AM -0500, John Goerzen wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > > I shouldn't have to add my name to the list of maintainers whose
> > > packages should never be NMUd.
> > IS there such a list? I don't think there should be.
> Yes:
> http://bugs.d
Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> Personally I think the best way to avoid the problem is never
> to install non-official/pre-release packages.
Which is good but then how are you supposed to test them :) Just install
them in a chroot and you won't have to worry about it.
--
Debian GNU/
On Tue, Apr 24, 2001 at 10:05:00AM -0500, John Goerzen wrote:
> Again, I'm not ranting that NMUs occured. I'm ranting that they were
> not done correctly.
Fair enough. It is irresponsible for developers to be using
any packages which aren't in the archive to build packages,
as happened in this ca
On Tue, Apr 24, 2001 at 01:31:05PM +0300, Richard Braakman wrote:
>
> Ironically, it won't prevent the problem that sparked this thread,
> namely a weird build environment on the machine where the NMU is
> compiled.
thanks to debootstrap, we no longer have any reason to not have a clean
build env
On Tue, 24 Apr 2001, Richard Braakman wrote:
> Oh, I didn't mean _only_ sending the diff. It was an addendum
> to Shaleh's suggestion. The idea is to send the diff, then have
> someone else look at it, and then do the NMU.
You could just drop the NMUed package into some public space
(http://my.
On Tue, 24 Apr 2001, Richard Braakman wrote:
> Ironically, it won't prevent the problem that sparked this thread,
> namely a weird build environment on the machine where the NMU is
> compiled.
I would still love to see Source Only uploads becoming the standard
way of getting new versions into the
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > I shouldn't have to add my name to the list of maintainers whose
> > packages should never be NMUd.
>
> IS there such a list? I don't think there should be.
Yes:
http://bugs.debian.net/
> The NMU was buggy, but with all due respect it appears tha
On 23-Apr-01, 18:52 (CDT), Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
> This would prevent the NMUers from doing things like debhelper/debconfizing
> packages without the maintainer's consent, as well as keep NMU bugs down.
NMUs should *never* change the build/install process to such an
exten
On Tue, Apr 24, 2001 at 11:07:20AM +0300 , Richard Braakman wrote:
> In that case the right "repository" could be a bugreport to the package
> involved. That way the diff submission is guaranteed. If the diff turns
though this doesn't catch broken build environment :(( like XF4.0.3 or
obsolete s
On Tue, Apr 24, 2001 at 11:32:42AM +0200, Arthur Korn wrote:
> Richard Braakman schrieb:
> > In that case the right "repository" could be a bugreport to the package
> > involved. That way the diff submission is guaranteed.
>
> I agree with you that _something_ has to be done about
> catastrophal
Hi
Richard Braakman schrieb:
> In that case the right "repository" could be a bugreport to the package
> involved. That way the diff submission is guaranteed.
I agree with you that _something_ has to be done about
catastrophal NMUs, but just stopping to NMU and only submitting
diffs, even on pac
On Mon, Apr 23, 2001 at 04:52:08PM -0700, Sean 'Shaleh' Perry wrote:
> So perhaps we need to come up with some more structure for the bug parties.
> Perhaps the right thing to do is have those involved create diffs of their
> work
> and place these in a repository for some group of devels respons
You can convince me to stop doing stupid things, but I refuse to stop
being stupid.
~ESP
--
Evan Prodromou
[EMAIL PROTECTED]
On 23-Apr-2001 John Goerzen wrote:
> OK, I'm rather annoyed. Recently I'm doing "squash bugs on my packages"
> and I have had already THREE that have been broken by NMUs that
> occured over the past week.
>
So perhaps we need to come up with some more structure for the bug parties.
Perhaps the
On 23-Apr-01, 17:26 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> The NMU was buggy, but with all due respect it appears that the package
> had not been updated in a long time before that. The standards-version
> was really old and you were using pre-FHS path names.
If the NMUer had followed
On Mon, Apr 23, 2001 at 02:40:30PM -0500, John Goerzen wrote:
> OK, I'm rather annoyed. Recently I'm doing "squash bugs on my packages"
> and I have had already THREE that have been broken by NMUs that
> occured over the past week.
> I shouldn't have to add my name to the list of maintainers whos
On 23 Apr 2001, John Goerzen wrote:
>...
> Heed the advice therein:
>
> * Don't fix something that's not broken.
>
> * E-mail the maintianer.
>...
In general I do totally agree with you, but I want to add a small
addition: A "Debian bug-squashing party may involve your packages" mail
sent some
I should add: I appreciate the efforts of the QA team and those
associated with it. I understand that mistakes happen and everyone is
human. I do not gripe about NMUs. I gripe about NMUs done wrongly.
Thanks.
-- John
21 matches
Mail list logo
