Joey Hess [EMAIL PROTECTED] writes:
One wonders why you don't. Thisporting effort seems to lead to a lot of
bitter people being involved in it. One wonders why. Anyhow, TTFN.
Well, I think I can see why. Because porting is a thankless and
gruelling task. You come head to head with every
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 implement some
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
freshly unpacked
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
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
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
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.
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! Now
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
Joey Hess [EMAIL PROTECTED] writes:
Hartmut Koptein wrote:
1. binary-only NMUs breaks policity
Probably.
Wrong.
--
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 on this
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:
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 rarely
On Fri, Oct 16, 1998 at 02:54:53PM +0100, James Troup wrote:
Joey Hess [EMAIL PROTECTED] writes:
snip
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
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
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?
Another
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
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 foobar 1.1-3, do you
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 which depends
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. If I'm
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 different
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 changes on anyone but
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. If I'm
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 skip
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
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
[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
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 fat no.
[ 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
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 over
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
31 matches
Mail list logo