SUMMARY -- (was Bug#27823: proftpd: non-maintainer upload (alpha) diffs)
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 little packaging mistake, get bit by the flubs of newbie Debian developers and silly oversights by developers who should know better, and face the fear, hostility, and a general lack of understanding by quite a few (i386-centric) Debian folks. I think this whole discussion got off on the wrong foot because the issues got confused. Let's try to break them out so we can address them constructively. ISSUE 1: Portability or packaging fixes made by porters should propogate into the upstream Debian package. Solution: porters must submit bugs for their fixes to the BTS This is *already* the case, so this is a non-issue, IMHO. Asking porters to wait for the upstream maintainer to respond and fix the bug does *not* scale to the level of packages that porters routinely have to deal with. I think that porters should be allowed and encouraged to do binary-only NMUs + BTS bug filed against package (which some caveats, see licensing below). Asking porters to wait is basically like trying to kill the porting effort, which Mssr. Hess should try to realize. ISSUE 2: There are a lot of common errors made by package maintainers, i.e., wrong architecture in debian/control, leaving 'debian/files' in the source package. Solution: work with the lintian maintainer and have error conditions or warnings generated for these cases, if it is not already the case. Write a section for the packaging manual on dos and don'ts based on the unique experience of the porters. ISSUE 3: Binary-only packages w/o source may break some licenses. A lot of this comes down to whether distributing source via the ftp archive, and patches via the BTS, conform to a given license's requirements. This issue is being hashed out in debian-policy, so I really don't want to go into it here. Basically my stand is that assuming that the patch has been submitted to the BTS, porters should simply be able to state in the changelog something like patches for this port available on the Debian Bug Tracking System URL:http://www.debian.org/Bugs. I think it's important that our ass is covered for GPL and NPL and MPL packages (or any license w/ the source availability requirement), but I really don't think ports can succeed if uploading binaries with minor portability fixes is a major hassle. Any other issues? I'm about to go toddle off to the Developer's Reference and add a section for porters. I think a clearly documented practice for porters would be a good thing, i.e., less verbal lore for porters to have to know, so becoming a porter would be easier, and more comprehension of the process by x86-centric maintainers. .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 rules and methods that are more consistent with multi-architecture development. In short, instead of arguing here, let's try to learn to work together on this. I agree, although I'd like to know exactly what in Policy is anti-porter, and how, specifically, we can improve the process and the quality of the ports. What parts of policy are unfriendly to porters? I will personnally do my utmost to correct and bugs in Policy, if you could point me to the actual sections which have the problems. Ideally, ALL maintainers would have access to a machine of every arch to compile their own packages on it, but I still have a feeling that alot of maintainers wouldn't bother compiling their packages on any other arch than x86. I'd love to be able to do this, as an x86 maintainer. Are the accounts available to x86-maintainers on other boxes? How do x86 maintainers go about getting such an account? I'd be happy to add this information to the Developer's Reference, if you can give me some information. Why are the different? Aside from Binary-only apparantly breaking current policy? Where in policy does it state this? I've seen this claim put forth many times but I don't see any section of Policy that states this. I think Policy is broken if it does state this, but I'm sure that's a controversial claim. The only think that I know of that makes ports second-class citizens is you claiming that because you are different, you should follow different rules. I don't think Joey is anti-non-i386, but that he instead wants everyone to play by the same rules. IMHO, Porters do have slightly different rules, because their duties as packagers are so radically different from the duties of normal package maintainers. Maintaining a port *is* different from maintaining just one package for one architecture. We have to realize this, and allow for it. I think that other archs ARE being treated like second-class citizens in more regards than just NMUs. I *wish* I had more interest from maintainers as to whether their packages compile ok on Alphas or not. To date, I've only had three maintainers actually ask me to test build their packages on Alphas and run some tests (which they provided) to make sure things worked ok. I was more than willing to do this. However, on the flip side, I've also received feedback from a couple of maintainers that basically said that they don't really care about us. I'll try to add some stronger wording about porting and why maintainers *must* care about them if they're going to maintain a package. We can't force people to care, but if they don't care, maybe they shouldn't be a Debian maintainer at all? In short, if *you* think the current rules are multi-arch-friendly, then I might as well stop porting to the Alpha totally. Like it or not, other archs have to get some latitude because of the problems that come with being on a machine that most maintainers DON'T have access to. No, but I'd like to know specific steps we can take to fix this. Hey, if you really want, I can start dbuild on the master archive and just forward all of the build reports to the main maintainers. If it doesn't build, it doesn't build. It would then be up to the maintainer to fix it a billion times until it passed a dbuild (because most maintainers don't know the quirks of other archs), and in the meantime, the other arch ports NEVER get released. Is that a better solution? I hope you don't think it is Definately not. Maybe it would be a good idea if we had source-depends though. AFAIK, the lack of source-depends is one of the most annoying problems that porters have to deal with. Do you think we could add an extra field to control files to get this going? Just so long as it was understood by dbuild, we would be in pretty good shape to start getting source-depends working. Then we could require that field by Policy... ? (Yes, I know this is a complex issue, but I'd like to see interest in this functionality revived.) A source package which doesn't compile out-of-the-box in the standard Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc for i386, glibc2.1 plus whatever compiler/libraries/binutils is used for m86k, and so forth) has a bug -- unless it is specifically architechture dependent. Well, sometimes it requires other programs to be installed, like debiandoc-sgml. This is not a bug in the package, really. It's not a bug with the m68k version only, it's a bug, plain and simple. If it fails on m68k because the maintainer unconsiously thought that All The World's an i386, then the source package still needs to be changed --
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 foobar_1.1-3.dsc? Yes. Binary-only and normal NMU's are the same thing, No they're not. Why do you insist on this obvious falsehood? Um, how are they different? Will you please get off your high horse and stop being so incredibly condescending? It doesn't help in anyway whatsoever and without some facts to back up your anti-non-i386 rants, it's really rather pointless. What exactly makes us second class citizens (your wishes aside)? I've heard complaints from porters many times that the ports are treated as second class citizens. I think I could dig up complaints form *you* saying that. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 package building system has the exact same effect. We should encourage people to build from scratch. Maybe that should be noted in some document. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 compiled for i386 and don't need to be compiled by someone other than the maintainer. That's when binary-only-NMUs occur on non-i386. Plenty of people rebuild i386 stuff from scratch for various reasons. Lars Wirenzious autobuilds i386. Joe User/Developer will occasionally extract a package's source and build it from scratch. That doesn't make it right for those people to do i386 binary only NMU's to fix clean-buiild bugs, does it? [ snip remainder of flamage] Please, calm down. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 it's not closed, you do a MNU. 4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer No, you still have to put a patch for yuor NMU in the BTS. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 E, Hull.. On Thu, Oct 15, 1998 at 08:30:46PM +0100, James Troup wrote: [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 obsession, there is *plenty* of software in main _not_ covered by the GPL. -- James [Want to know how Debian violates the GPL all the time? Check how many GPLed packages in Debian have modifications yet don't obey 2(a).] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpnnbxbf34li.pgp Description: PGP signature
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 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 contact). I think, we should it do as we have it done the last three years. Thanks, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 contact). Well, then, keep a list of the bugs you've filed. Each day you autobuild say, 30 packages from Incoming. If they fail to build, you file bugs and add them to the bottom of your list. Then you look at the top 1/7th [1] of the list. For each bug, if the maintainer has fixed the bug, you build binaries (if you haven't already). If the maintainer hasn't, you do a NMU. If the list starts getting too small, great, you can start looking at more packages each day from incoming. If it gets too long, you can cut back on how many new packages you build each day. -- see shy jo [1] So you go through the full list in a week, giving the maintainer a week to react.
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Joey Hess [EMAIL PROTECTED] writes: Hartmut Koptein wrote: 1. binary-only NMUs breaks policity Probably. Wrong. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 obvious falsehood? Um, how are they different? 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 to want to ignore) [see my bash example in [EMAIL PROTECTED]]. I think I could dig up complaints form *you* saying that. That would be a cunning trick. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 necessary however, since 99.5% of the time (the only exception I know of is Hartmut's packages) i386 packages are already compiled for i386 and don't need to be compiled by someone other than the maintainer. That's when binary-only-NMUs occur on non-i386. Plenty of people rebuild i386 stuff from scratch for various reasons. It's not even vaguely comparable to ports, because of the scale of the recompilation (so Lars and Johnie do the occasional auto-building, big deal.. it hardly compares to the constant building done by the 6 ports) and because if compiling from the source doesn't work on i386 there is always the binary to fall back on, which isn't the case for non-i386. [ snip remainder of flamage ] i.e. I can't actually respond to this, so I'll dismiss it as flames. Good effort. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 to want to ignore) [see my bash example in [EMAIL PROTECTED]]. If the changes break the other architectures then the changes are BROKEN, learn how not to do it, simple.. We all make mistakes, its a fact of life, and there are some RARE cases where a binary only NMU is needed, however they are the EXCEPTION, not the rule.. Basicly, your argument of it only affecting one architectures is bogus, if your worried about your changes not working on other architectures then go over to master and compile it, if you need testers go over to #debian and ASK, if I'm there (nick Mercury, idle a LOT) and I use the package I'll test it for 80x86, so in the end, give one GOOD reason why they should be the norm, and the only affecting one architecture is not a good reason.. Zephaniah E, Hull.. -- I think I could dig up complaints form *you* saying that. That would be a cunning trick. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpmP9YnPAu2w.pgp Description: PGP signature
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 wonders why. Anyhow, TTFN. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 thing is that i386 maintainers _won't_ notice is two of our
most common problems: YAFHIC386 in debian/control's Architecture and
debian/files not being removed during debian/rules clean.
I can see the first, but I've certianly ran into the second before I
modified debhelper to delete debian/files.
debian/files being present in freshly unpacked source is rarely a
problem on i386; it's *always* a problem on non-i386.
[ ... ]
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 wrong in some drastic way, only m68k suffers.
You're also forgetting the vast majority of our fixes fall into two
categories:
1) Fixing lame packaging bugs.
2) Portability fixes.
In both cases it's hard for a maintainer to turn round and say, No,
your fix is wrong, I wanted the package to be unbuildable from source
or No, get some real hardware, I don't want this package to be
portable, or No, that's not the right fix for $ARCH, you should do
this instead.
Binary-only and normal NMU's are the same thing,
No they're not. Why do you insist on this obvious falsehood?
[ ... ]
Do you want the ports to remain forever second class citizens, or do you
want them to eventually mature to be equal with i386?
Will you please get off your high horse and stop being so incredibly
condescending? It doesn't help in anyway whatsoever and without some
facts to back up your anti-non-i386 rants, it's really rather
pointless. What exactly makes us second class citizens (your wishes
aside)?
All ports needs to make a lot of changes because so many source
packages are broken. It's got little or nothing to do with the
newness of the port (if you look at the {binary-,}NMU's and bug
reports, they aren't predominantly from the new ports, but rather the
older ones (m68k alpha)).
Broken source package has nothing to do with a port at all.
Of course they bloody do; we have to build them. And the breakage I'm
talking about, is the sort of breakage which doesn't show up for 99.5%
of i386/source maintainers.
Eh? Define ``standard'', please? I rather hope you don't mean what
i386 uses.
I mean that we should converge on using the same build environment and build
mechanisms (and NMU mechanisms) for all architectures, and until we do, the
ports are going to remain second class citizens.
Ehm, so all the architectures using glibc 2.1 are second class
citizens? If I didn't know better, I'd think you were just using this
issue as an excuse to vent some anti-non-i386 feelings you seem to
have.
--
James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 binary-only NMU w/o waiting, you should be able to do a normal NMU w/o waiting. And if you can do that, it follows you should, since a normal NMU is better. How will you feal, if i get one of your packages, make necessary patches for kernel-2.1 and glibc-2.1 and egcs to it and upload the package _with_ source (without asking you for permission) to master. And then you notice that this new source-package is broken on your system? binary-only MNU hits only one arch normal NMU hits possible all archs Another story: I patched a debian binary in february, forwarded the patch directly to the maintainer (not to the BTS) and uploaded this package as a binary-only MNU. This package (with the patch) is always not yet available, because the maintainer is very busy to make a new release. This is more then a 1/2 year ! Greetings, Hartmut PS: we talk no about two or three packages, porters means 100 or 200 packages :-) -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 really recompile from a James freshly unpacked foobar_1.1-3.dsc? Close. I work from a freshly exported version. (rm -rf old dir, export again, dpkg-buildpackage). That is what cvs-buildpackage does. Why is that so surprising? manoj -- No one gets sick on Wednesdays. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 on something in debian/* being executable (when James dpkg-source -x only makes debian/rules executable). 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. manoj -- The Kosher Dill was invented in 1723 by Joe Kosher and Sam Dill. It is the single most popular pickle variety today, enjoyed throughout the free world by man, woman and child alike. An astounding 350 billion kosher dills are eaten each year, averaging out to almost 1/4 pickle per person per day. New York Times food critic Mimi Sheraton says The kosher dill really changed my life. I used to enjoy eating McDonald's hamburgers and drinking Iron City Lite, and then I encountered the kosher dill pickle. I realized that there was far more to haute cuisine then I'd ever imagined. And now, just look at me. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 wrong in some drastic way, only m68k suffers.
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 source packages, and I don't
know if our archiving system has a way of dealing with that.
You're also forgetting the vast majority of our fixes fall into two
categories:
1) Fixing lame packaging bugs.
2) Portability fixes.
Both of which, regardless of architecture, are bugs. If there is a
lame packaging bug that prevents easy porting, it should be dealt with
as a bug -- and if that calls for a NMU, then it should be a normal NMU.
Portability fixes are the same way.
In both cases it's hard for a maintainer to turn round and say, No,
your fix is wrong, I wanted the package to be unbuildable from source
or No, get some real hardware, I don't want this package to be
portable, or No, that's not the right fix for $ARCH, you should do
this instead.
Then they probably won't, and if you are lucky, the next Maintainer
Upload will include the changes made for your NMU.
What is the procedure for normal NMU's in place to ensure that
necessary bug-fixes get rolled into the next MU anyway?
Binary-only and normal NMU's are the same thing,
No they're not. Why do you insist on this obvious falsehood?
Why are the different? Aside from Binary-only apparantly breaking
current policy?
[ ... ]
Do you want the ports to remain forever second class citizens, or do you
want them to eventually mature to be equal with i386?
Will you please get off your high horse and stop being so incredibly
condescending? It doesn't help in anyway whatsoever and without some
facts to back up your anti-non-i386 rants, it's really rather
pointless. What exactly makes us second class citizens (your wishes
aside)?
The only think that I know of that makes ports second-class citizens is
you claiming that because you are different, you should follow
different rules.
I don't think Joey is anti-non-i386, but that he instead wants everyone
to play by the same rules.
All ports needs to make a lot of changes because so many source
packages are broken. It's got little or nothing to do with the
newness of the port (if you look at the {binary-,}NMU's and bug
reports, they aren't predominantly from the new ports, but rather the
older ones (m68k alpha)).
Broken source package has nothing to do with a port at all.
Of course they bloody do; we have to build them. And the breakage I'm
talking about, is the sort of breakage which doesn't show up for 99.5%
of i386/source maintainers.
Just because they don't show up most of the time, they are still
broken. And they should be fixed, regardless of if it was found by the
m68k people, the PPC people, the PalmPilot people, or the i386 people.
Eh? Define ``standard'', please? I rather hope you don't mean what
i386 uses.
I mean that we should converge on using the same build environment and build
mechanisms (and NMU mechanisms) for all architectures, and until we do, the
ports are going to remain second class citizens.
Ehm, so all the architectures using glibc 2.1 are second class
citizens? If I didn't know better, I'd think you were just using this
issue as an excuse to vent some anti-non-i386 feelings you seem to
have.
I think he was referring to Procedures and Policy, not which
compiler/libraries you use.
A source package which doesn't compile out-of-the-box in the standard
Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc
for i386, glibc2.1 plus whatever compiler/libraries/binutils is used
for m86k, and so forth) has a bug -- unless it is specifically
architechture dependent. It's not a bug with the m68k version only,
it's a bug, plain and simple. If it fails on m68k because the
maintainer unconsiously thought that All The World's an i386, then the
source package still needs to be changed -- and Procedures and Policy
should allow that.
I don't think that the non-i386 ports are second-class citizens. I
think that they should be treated as equally, under Procedures and
Policies, as possible. If you claim, as I do, that non-i386 ports
shouldn't be treated as second-class citizens, why do you ask for
special treatment?
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Buddha Buck [EMAIL PROTECTED]
Just as the strength of the Internet is chaos, so the
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 source packages, and I don't know if our archiving system has a way of dealing with that. 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 rules and methods that are more consistent with multi-architecture development. In short, instead of arguing here, let's try to learn to work together on this. Both of which, regardless of architecture, are bugs. If there is a lame packaging bug that prevents easy porting, it should be dealt with as a bug -- and if that calls for a NMU, then it should be a normal NMU. Portability fixes are the same way. Well, I've got mixed emotions on this. Yes, technically, we should be waiting for the maintainer to handle it, BUT most of the bugs I've filed haven't even gotten a responce from the maintainer save the automated one. It would be one thing if it was A bug in A package, but it's usually five fixes in 100 packages. If there were 100 of me doing this, I wouldn't have a problem waiting, but in the meantime, I'm watching 5 new revisions of these packages come out WITHOUT fixes. Plus, I've got 30 new package to compile, all of which need fixes... it's a viscious circle. It seems like alot of the maintainers just don't care sometimes too. In short, it gets frustrating when things aren't addressed and your problem keeps mounting and compounding like that. Ideally, ALL maintainers would have access to a machine of every arch to compile their own packages on it, but I still have a feeling that alot of maintainers wouldn't bother compiling their packages on any other arch than x86. Then they probably won't, and if you are lucky, the next Maintainer Upload will include the changes made for your NMU. Yeah, right. I hate to be nasty, but I've got at least three bugs that have been sitting in the BTS for over 110 days. These are fixes that are NEEDED to compile on Alphas (one of them is netstd, so it's not like I'm talking about some dumb game here). Also, one of them is an improvement that the upstream author had made a note to change one day, but that hasn't even made its way into the package. If 110 days is not alot of time to wait on an important package, then I might as well stop trying to port ANYTHING anymore because it's becoming obvious to me that not many maintainers really care how portable their packages are. Why are the different? Aside from Binary-only apparantly breaking current policy? Because we're trying to walk both sides of the line in doing a binary-only NMU. For one, it takes care of a problem that isn't being taken care of otherwise (because nobody else seems to care) and also, we file diffs in the BTS. I have to give alot of the maintainers good credit for incorporating the patches in a timely manner, but there are still quite a few that remain outstanding. How would *you* deal with it? Would you wait 110+ days while your machine doesn't run right because of a broken package or would you do a binary NMU to help yourself and others WHILE waiting for the maintainer to get around to fixing their package? On the x86, it's not much of a problem because usually maintainers can test and easily incorporate patches easily (not to mention how much easier it is to diagnose bugs on their native arch). When it comes to porters, we end up having to make our patches drop-in easily because we want to make it as easy as possible for the maintainer or else it'll take another three weeks to make the patches friendly to all archs. The only think that I know of that makes ports second-class citizens is you claiming that because you are different, you should follow different rules. I don't think Joey is anti-non-i386, but that he instead wants everyone to play by the same rules. I think that other archs ARE being treated like second-class citizens in more regards than just NMUs. I *wish* I had more interest from maintainers as to whether their packages compile ok on Alphas or not. To date, I've only had three maintainers actually ask me to test build their packages on Alphas and run some tests (which they provided) to make sure things worked ok. I was more than willing to do this. However, on the flip side, I've also received feedback from a couple of maintainers that basically said that they don't really care about us. In short, if *you* think the current rules are multi-arch-friendly, then I might as well stop porting to the Alpha totally. Like it or not, other archs have to get some latitude because of the problems that come with being on a machine that
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 the architecture I'm uploading for. If I'm wrong in some drastic way, only m68k suffers. 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? 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) i386 packages are already compiled for i386 and don't need to be compiled by someone other than the maintainer. That's when binary-only-NMUs occur on non-i386. You're also forgetting the vast majority of our fixes fall into two categories: 1) Fixing lame packaging bugs. 2) Portability fixes. Both of which, regardless of architecture, are bugs. Well, duh. [ Actually, if, e.g. postgresql plain lacks m68k support upstream, that's hardly a bug on the part of the postgresql maintainer or upstream. Some packages are non-trivial to port and require good knowledge of the architecture in question. ] If there is a lame packaging bug that prevents easy porting, it should be dealt with as a bug -- and if that calls for a NMU, then it should be a normal NMU. Why? Portability fixes are the same way. Again, why? What is the procedure for normal NMU's in place to ensure that necessary bug-fixes get rolled into the next MU anyway? Good God, why the hell are you taking part in this discussion, if you need to ask a question like that? Binary-only and normal NMU's are the same thing, No they're not. Why do you insist on this obvious falsehood? Why are the different? Because one includes source and one does not. And because one only affects one architecture, and one affects all architectures. And because binary-only NMU's have a distinct and clear purpose aside from the current issue of fixing bugs in the source which everyone seems willing to forget[1]. Aside from Binary-only apparantly current policy? Ehm, please show me which part of policy binary-only-NMUs break? Stop the FUD! I don't think Joey is anti-non-i386, but that he instead wants everyone to play by the same rules. You don't even know the damn rules, so what the hell are you talking about? But in case you hadn't noticed playing by the same rules doesn't work, because i386 is not the be all and end all of architectures. [...] Broken source package has nothing to do with a port at all. Of course they bloody do; we have to build them. And the breakage I'm talking about, is the sort of breakage which doesn't show up for 99.5% of i386/source maintainers. Just because they don't show up most of the time, they are still broken. So? And they should be fixed, regardless of if it was found by the m68k people, the PPC people, the PalmPilot people, or the i386 people. Again, so? Both your statements are highly irrelevant to what I said, please try to stick to the point. [...] Ehm, so all the architectures using glibc 2.1 are second class citizens? If I didn't know better, I'd think you were just using this issue as an excuse to vent some anti-non-i386 feelings you seem to have. I think he was referring to Procedures and Policy, not which compiler/libraries you use. Rubbish. Read what he wrote: | and your build environment may be non-standard. ^^^ | | Eh? Define ``standard'', please? I rather hope you don't mean what | i386 uses. A source package which doesn't compile out-of-the-box in the standard Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc for i386, glibc2.1 plus whatever compiler/libraries/binutils is used for m86k, and so forth) has a bug -- unless it is specifically architechture dependent. Yes, it's a bug. So what? I know it's a bug. That's why I always file a _bug_ in the _bug_ tracking system. It's not a bug with the m68k version only, it's a bug, plain and simple. Your talent for stating the obvious blows me away. If you claim, as I do, that non-i386 ports shouldn't be treated as second-class citizens, why do you ask for special treatment? I don't... actually all I want for Debian is more maintainers with a clue. But I don't think, I'll being seeing too much of that in this lifetime. [1] Everyone seems to be forgetting the indisputably valid forms of binary-NMUs where a simple recompile with no source changes (other than an entry to debian/changelog) occur. Real life example: some lamer (i.e. me) compiled bash on an m68k box without ncurses3.0-altdev installed; end result = libreadline2 linked with libc5 and libc6. Back when this was hamm, and people were
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 wrong in some drastic way, only m68k suffers. Additionally, a normal NMU is to fix generic problems with the workings of the package itself, not the building process; at least, *I* have never seen an NMU (with source) done for i386 to fix a build problem. Hmmm, we should make it policy that i386 packages aren't allowed to be directly uploaded into Debian; instead, the source should be uploaded, and then another maintainer (not related in any way to the uploader) must download the source, build the package, and upload the resulting binary. If the build fails, either don't upload or upload a complete NMU with source. That should equalize things between i386 and the rest :-) Also, the speed at which updates come would be slowed to acceptable rates... Binary-only and normal NMU's are the same thing, No they're not. Why do you insist on this obvious falsehood? IMO the difference is that a binary-only NMU fixes building difficulties, and a normal NMU fixes the functionality or problems with installing. A binary-only NMU package should function that same way in all respects to the original binary. Do you want the ports to remain forever second class citizens, or do you want them to eventually mature to be equal with i386? Will you please get off your high horse and stop being so incredibly condescending? It doesn't help in anyway whatsoever and without some I have to agree that I fail to see any added value in Joey's comment here. Broken source package has nothing to do with a port at all. Of course they bloody do; we have to build them. And the breakage I'm talking about, is the sort of breakage which doesn't show up for 99.5% of i386/source maintainers. Precisely; couldn't the QA team check that packages build correctly for third parties? What's the point of supplying source packages if they're useless. I mean that we should converge on using the same build environment and build Source dependencies would be a *big* help. Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 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 binary-only NMU w/o waiting, you should be able to do a normal NMU w/o waiting. And if you can do that, it follows you should, since a normal NMU is better. How will you feal, if i get one of your packages, make necessary patches for kernel-2.1 and glibc-2.1 and egcs to it and upload the package _with_ source (without asking you for permission) to master. And then you notice that this new source-package is broken on your system? There is a reason libc's have version #defs, and that gcc and alike have version #defs, and *gasps* kernels too.. Basicly, use #if and #ifdef, if your changes blindly assume a arch then your no better then the programmers who assume ix86, if not worse because you KNOW how important the issues are.. binary-only MNU hits only one arch normal NMU hits possible all archs A binary-only MNU violates the GPL, end of story. Another story: I patched a debian binary in february, forwarded the patch directly to the maintainer (not to the BTS) and uploaded this package as a binary-only MNU. This package (with the patch) is always not yet available, because the maintainer is very busy to make a new release. This is more then a 1/2 year ! This is why you should include source with the NMU!!! Zephaniah E, Hull. Greetings, Hartmut PS: we talk no about two or three packages, porters means 100 or 200 packages :-) -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpO2UrqfrDvo.pgp Description: PGP signature
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 ! If so, we (porters) increment always the debian package minor number +1 . MfG, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 always the case in the past. Its time to remember: - multi archs cds are comming - work is in progress for downloading serveral arch binaries from our web pages - documentation will be better and better - debian is always free but: we have always no consens for an easy installation - what means: (new) users have not the choice to select for a base- , middle- or big-installing procedure. This is more important then a x11 installation (for boot-floppies). [joda filter off] :-) Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
[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 obsession, there is *plenty* of software in main _not_ covered by the GPL. -- James [Want to know how Debian violates the GPL all the time? Check how many GPLed packages in Debian have modifications yet don't obey 2(a).]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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. (1) is patently untrue, (2) is not happening any time ever and (4) is, with all due respect, stupid beyond belief. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
[ 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've seen from Paul, similar-ish on alpha) show up. I don't get it. How do people upload a new version of a package w/o compiling it from scratch? FWIW, I don't like binary-only NMUs either as they do mean duplication as each port fixes the same (usually lame) packaging bug, but I realise their necessity (what Paul says is true; if we waited for source maintainers to integrate fixes, we would get nowhere very fast). I seem to be hearing the argument that binary-only NMU's can be made without waiting, while a normal NMU requires that you wait for the maintainer to have a reasonable time to do something about a bug report. I don't understand why this would be so. Why are binary-only NMU's special? Seems to me like they're both just NMU's, and that binary-only NMU's are not as good as normal NMU's because they don't make it easy to share fixes between architectures, so I don't see why they should be made at all. [1] -- see shy jo [1] I recognize the value of binary-only NMU's when a new port is being started and you can't afford to wait on the maintainer, and you may need to make a lot of changes, and your build environment may be non-standard. But as a port matures, their value decreses. I think porters are mostly making binary-only NMU's now out of tradition.
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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 50% of the
problems (at least on m68k, and judging by the diff's I've seen from
Paul, similar-ish on alpha) show up.
I don't get it. How do people upload a new version of a package w/o
compiling it from scratch?
They don't compile from freshly unpacked source. Problems which
aren't noticed are, for example, a debian/rules clean which depends on
debian/rules build having at least partially run, or a debian/rules
which depends on something in debian/* being executable (when
dpkg-source -x only makes debian/rules executable).
Another thing is that i386 maintainers _won't_ notice is two of our
most common problems: YAFHIC386 in debian/control's Architecture and
debian/files not being removed during debian/rules clean.
There really isn't an i386 port.
I seem to be hearing the argument that binary-only NMU's can be made without
waiting, while a normal NMU requires that you wait for the maintainer to
have a reasonable time to do something about a bug report. I don't
understand why this would be so.
Because I refuse to wait for maintainers who take weeks and weeks (if
not months or years [This was actually the case till Guy finally
purged the old style source format packages]) to respond to trivial
bugs; there is no reason why non-i386 users and developers should be
held up by slow-to-respond i386/source maintainers, when we have
already done the work and found the fix for their bugs.
[1] I recognize the value of binary-only NMU's when a new port is being
started and you can't afford to wait on the maintainer,
Eh? Why should a port be able to afford to wait on i386-maintainers
just because it's no longer new?
and you may need to make a lot of changes,
All ports needs to make a lot of changes because so many source
packages are broken. It's got little or nothing to do with the
newness of the port (if you look at the {binary-,}NMU's and bug
reports, they aren't predominantly from the new ports, but rather the
older ones (m68k alpha)).
and your build environment may be non-standard.
Eh? Define ``standard'', please? I rather hope you don't mean what
i386 uses.
But as a port matures, their value decreses.
Says who and why?
I think porters are mostly making binary-only NMU's now out of
tradition.
No, it's not tradition at all, I simply want to get things done. If I
find a bug in a package I'm compiling for m68k, I will fix it, and
forward the patch to the BTS. I've done this for years and will
continue to do it, unless someone provides me with a) a better system
and/or b) reasons not to.
--
James
[Bah, gnus' auto-signature erasure is a PITA when footnotes below the
signature are used]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
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/files not being removed during debian/rules clean.
I can see the first, but I've certianly ran into the second before I
modified debhelper to delete debian/files.
I seem to be hearing the argument that binary-only NMU's can be made without
waiting, while a normal NMU requires that you wait for the maintainer to
have a reasonable time to do something about a bug report. I don't
understand why this would be so.
Because I refuse to wait for maintainers who take weeks and weeks (if
not months or years [This was actually the case till Guy finally
purged the old style source format packages]) to respond to trivial
bugs; there is no reason why non-i386 users and developers should be
held up by slow-to-respond i386/source maintainers, when we have
already done the work and found the fix for their bugs.
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
binary-only NMU w/o waiting, you should be able to do a normal NMU w/o
waiting. And if you can do that, it follows you should, since a normal NMU
is better.
[1] I recognize the value of binary-only NMU's when a new port is being
started and you can't afford to wait on the maintainer,
Eh? Why should a port be able to afford to wait on i386-maintainers
just because it's no longer new?
Do you want the ports to remain forever second class citizens, or do you
want them to eventually mature to be equal with i386? If you want the
latter, at some point you're going to have to start playing by the same
rules as everyone else.
Put another way, how would you like it if I did an i386 binary-only NMU?
I'll bet I'd be flamed to death.
All ports needs to make a lot of changes because so many source
packages are broken. It's got little or nothing to do with the
newness of the port (if you look at the {binary-,}NMU's and bug
reports, they aren't predominantly from the new ports, but rather the
older ones (m68k alpha)).
Broken source package has nothing to do with a port at all. I can find the
same errors rebuilding on i386.
Eh? Define ``standard'', please? I rather hope you don't mean what
i386 uses.
I mean that we should converge on using the same build environment and build
mechanisms (and NMU mechanisms) for all architectures, and until we do, the
ports are going to remain second class citizens.
--
see shy jo
