"Christopher C. Chimelis" <[EMAIL PROTECTED]> writes:
> This is true, and this should be fixed, IMO. If "Debian", as an entity,
> is making a decision to become multi-arch supportive, then maybe it's
> time to update the older rules that were made when x86 was the only
> arch, and time to implemen
James Troup wrote:
> i.e. "I can't actually respond to this, so I'll dismiss it as flames."
> Good effort.
Ie, you weren't talking to me and I have better things to do with my life.
One wonders why you don't. Thisporting effort seems to lead to a lot of
bitter people being involved in it. One won
On Fri, Oct 16, 1998 at 02:54:53PM +0100, James Troup wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> Are you trolling? As I've said 3 times already (at least): because
> they only affect one architecture. And because there are perfectly
> valid reasons to do binary-only NMUs (which you seem
Joey Hess <[EMAIL PROTECTED]> writes:
> James Troup wrote:
>
> > Who said [binary-only NMU's for i386] were bad?
>
> You did.
No, I said binary-only NMUs as a whole were not ideal; I didn't say
anything about binary-only NMU's for i386. Please try to stick to the
facts.
> > They are very rarel
Joey Hess <[EMAIL PROTECTED]> writes:
> Each day you autobuild say, 30 packages from Incoming.
Building (especially auto-building) packages from Incoming is a bad
idea, please don't encourage it.
--
James
Joey Hess <[EMAIL PROTECTED]> writes:
> > If you're building foobar 1.1-3, do you really recompile from a
> > freshly unpacked foobar_1.1-3.dsc?
>
> Yes.
Congratulations; you're in the minority.
> > > Binary-only and normal NMU's are the same thing,
> >
> > No they're not. Why do you insist
Joey Hess <[EMAIL PROTECTED]> writes:
> Hartmut Koptein wrote:
> > 1. binary-only NMUs breaks policity
>
> Probably.
Wrong.
--
James
Hartmut Koptein wrote:
> Ahhh! Now you have it! This is very bad! Because: low on time, low on hd
> space,
> low brain :-), and so on ...
>
> Forget it then. This is not possible. (Reminder: porters (i) talk about > 200
> packages, and after my list 'work for developers' only two people get in
> > 3. Porters needn't to ask maintainers for permission
>
> No-one has to ask for permission for a NMU. That's the point of a NMU. You
> file a bug, you wait a reasonable time, if it's not closed, you do a MNU.
^^^
Ahhh! No
Ok, fine, then please insert a pointer to the patchs in the description,
Sorry for that..
But that still leaves the rest of my argument fully intact, and someone
stated in past messages that they sent the patchs directly to the
maintainer and NOT through the BTS, for a binary only NMU.
Zephaniah
Hartmut Koptein wrote:
> 1. binary-only NMUs breaks policity
Probably.
> 2. every NMU must be with source
I hope.
> 3. Porters needn't to ask maintainers for permission
No-one has to ask for permission for a NMU. That's the point of a NMU. You
file a bug, you wait a reasonable time, if i
James Troup wrote:
> Who said they were bad?
You did. A few days ago you agreed that bin-only NMU's were not ideal. I
can't dig it up right now.
> They are very rarely necessary however, since
> 99.5% of the time (the only exception I know of is Hartmut's packages)
> i386 packages are already com
Manoj Srivastava wrote:
> Really? I use cvs, and hence all my packages are indeed built
> from scratch. I was under the impression that more and more people
> are etting converted to CVS, but I guess that is wishful thinking.
Well I don't use cvs, but my hand-crafted version control and pa
James Troup wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > James Troup wrote:
> > > They don't compile from freshly unpacked source.
> >
> > How odd. Other maintainer must work substantially differently than I, then.
>
> If you're building foobar 1.1-3, do you really recompile from a
> fre
Hartmut Koptein <[EMAIL PROTECTED]> writes:
> 1. binary-only NMUs breaks policity
> 2. every NMU must be with source
> 3. Porters needn't to ask maintainers for permission
> 4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer
>
> ok for all ?
That would be a big
[EMAIL PROTECTED] writes:
> > binary-only MNU hits only one arch
> > normal NMU hits possible all archs=20
>
> A binary-only MNU violates the GPL, end of story.
FUD, FUD, FUD and more FUD. The source changes for our binary-only
NMUs are _always_ sent to the BTS.
Also, please get over this GPL
Hi James,
> Who said they were bad? They are very rarely necessary however, since
> 99.5% of the time (the only exception I know of is Hartmut's packages)
yes, my packages are the only one that test masters scripts for non-i386
maintainer source uploads. :-)
This is now possible but it was not
Ok,
let us a little bit summarize:
1. binary-only NMUs breaks policity
2. every NMU must be with source
3. Porters needn't to ask maintainers for permission
4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer
ok for all ?
If the answer is 'yes' i agree !
I don't really want to get into this, I've got enough people mad at me
for filing some bug reports, but I think this needs to be said, anyways.
On Thu, Oct 15, 1998 at 02:54:02AM +0200, Hartmut Koptein wrote:
>
> > But you're missing my point. Why does a binary-only NMU give you the right
> > to s
On Thu 15 Oct 1998, James Troup wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > Why does a binary-only NMU give you the right to skip waiting, while
> > a normal NMU does not? Why are they different?
>
> Because I'm not forcing my changes on anyone but the architecture I'm
> uploading for.
Buddha Buck <[EMAIL PROTECTED]> writes:
> James Troup said:
> > Joey Hess <[EMAIL PROTECTED]> writes:
> >
> > > James Troup wrote:
> > > Why does a binary-only NMU give you the right to skip waiting, while
> > > a normal NMU does not? Why are they different?
> >
> > Because I'm not forcing my ch
Buddha Buck wrote:
>
> How does that differ from -any- binary-only NMU, regardless of
> architechture? If binary-only NMU's for i386 are bad, why are
> binary-only NMUs for m68k OK?
>
> The only -real- problem I see with normal NMUs is that then the i386
> and m68k binaries are built from differ
James Troup said:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > James Troup wrote:
> > Why does a binary-only NMU give you the right to skip waiting, while
> > a normal NMU does not? Why are they different?
>
> Because I'm not forcing my changes on anyone but the architecture I'm
> uploading for.
Hi,
>>"James" == James Troup <[EMAIL PROTECTED]> writes:
James> They don't compile from freshly unpacked source. Problems which
James> aren't noticed are, for example, a debian/rules clean which depends on
James> debian/rules build having at least partially run, or a debian/rules
James> whic
Hi,
>>"James" == James Troup <[EMAIL PROTECTED]> writes:
James> Joey Hess <[EMAIL PROTECTED]> writes:
>> James Troup wrote:
>> > They don't compile from freshly unpacked source.
>>
>> How odd. Other maintainer must work substantially differently than I, then.
James> If you're building foob
> But you're missing my point. Why does a binary-only NMU give you the right
> to skip waiting, while a normal NMU does not? Why are they different? Why
> does one let you circumvent the rules, for however noble a purpose?
>
> Binary-only and normal NMU's are the same thing, and if you can do a
>
Joey Hess <[EMAIL PROTECTED]> writes:
> James Troup wrote:
> > They don't compile from freshly unpacked source.
>
> How odd. Other maintainer must work substantially differently than I, then.
If you're building foobar 1.1-3, do you really recompile from a
freshly unpacked foobar_1.1-3.dsc?
> >
James Troup wrote:
> They don't compile from freshly unpacked source.
How odd. Other maintainer must work substantially differently than I, then.
> Another thing is that i386 maintainers _won't_ notice is two of our
> most common problems: YAFHIC386 in debian/control's Architecture and
> debian/f
Joey Hess <[EMAIL PROTECTED]> writes:
> [ Moving this to debian-devel, discussion doesn't belong in the bug report. ]
[ Killed the Cc: line. ]
> James Troup wrote:
> > There is no i386 port in as much as i386 maintainers 99.5% of the time
> > _don't_ compile packages from scratch, which is when
[ Moving this to debian-devel, discussion doesn't belong in the bug report. ]
James Troup wrote:
> There is no i386 port in as much as i386 maintainers 99.5% of the time
> _don't_ compile packages from scratch, which is when over 50% of the
> problems (at least on m68k, and judging by the diff's I
30 matches
Mail list logo