Re: Re: source-only uploads
Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
> Why? Does it B-D on itself?
And, if it does, can it not be built using stretch ?
Ian.
I don't know about Java but I had an issue with freepascal not so long ago
(back when Jessie was stable and stretch was testing).
A change in glibc broke freepascal on powerpc stretch/sid to the point it
wouldn't install. Freepascal needs itself to build. Sids freepascal would not
build in jessie due to using newer debhelper features.
To fix this I had to take sid's freepascal, apply the upstream patch for the
glibc issue, hack it up so it would build in a jessie environment, build it in
a jessie environment on the porterbox, install the binaries from that build
into a sid environmentin qemu (because self-built packages can't be installed
on porterboxes).
This kind of stuff does happen and we need to be able to deal with it.
Having said that I believe the default should be to throw away maintainer-built
binaries, they should only be accepted if the developer explicitly asks for it.
Re: source-only uploads
On Fri, Sep 01, 2017 at 07:18:58PM +0100, Ian Jackson wrote:
> Andrey Rahmatullin writes ("Re: source-only uploads"):
> > On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > > Just yesterday I completely broke a key package used to build
> > > many Java packages, and I couldn't even rebuild it to fix the issue.
> >
> > Why? Does it B-D on itself?
>
> And, if it does, can it not be built using stretch ?
How will that help?
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: source-only uploads
Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
> Why? Does it B-D on itself?
And, if it does, can it not be built using stretch ?
Ian.
Re: source-only uploads
On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote: > Just yesterday I completely broke a key package used to build > many Java packages, and I couldn't even rebuild it to fix the issue. Why? Does it B-D on itself? -- WBR, wRAR signature.asc Description: PGP signature
Re: source-only uploads
> and after someone > has implemented a solution for that there is no blocker left for > allowing only source-only uploads from maintainers. I'm all for source-only uploads and I adopted them recently, but I hope this restriction won't happen, or at least not without a derogation mechanism. Just yesterday I completely broke a key package used to build many Java packages, and I couldn't even rebuild it to fix the issue. I had to install a missing package locally and rebuild the binary on my machine. It would have been very difficult to fix that without binary uploads. Emmanuel Bourg
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Sun, Nov 25, 2012 at 01:32:16PM -0500, Barry Warsaw wrote: On Nov 23, 2012, at 03:06 PM, YunQiang Su wrote: you always need to build for one arch and test, then why not upload it? I think there are a lot of good reasons to do source-only uploads, even when you should be building locally for testing purposes. * Reproducibility - buildds provide a more controlled environment than developers' machines. [snip] * Testability - Is there any guarantee that a package's tests have been run during the local build process? [snip] These both would be provided by throwing away the built component and rebuilding in a closed environment, which is (I believe) the current thinking of the best way forward. Neil -- signature.asc Description: Digital signature
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Nov 23, 2012, at 03:06 PM, YunQiang Su wrote: you always need to build for one arch and test, then why not upload it? I think there are a lot of good reasons to do source-only uploads, even when you should be building locally for testing purposes. * Reproducibility - buildds provide a more controlled environment than developers' machines. This means that it's less likely that some local environmental factor creeps into your binary packages, or is silently relied upon to produce a successful build. * Testability - Is there any guarantee that a package's tests have been run during the local build process? I think it's a good thing to enable more packages tests (e.g. through dh_auto_tests or DEP 8 tests), so ensuring that DEP 8 tests for example are always run before the package is published is, IMO a good thing. Cheers, -Barry signature.asc Description: PGP signature
Re: release goal for jessie! (Re: Source-only uploads
]] Gunnar Wolf Didier Raboud dijo [Wed, Nov 21, 2012 at 09:21:19PM +0100]: Actually, I like that way to put it as it leaves us with multiple ways forward: * accept source-only; * drop uploaded binaries; I would join this camp as well. Without the working knowledge of being a DSA or buildd-admin, I cannot assure how much would this increase our workload, but it would probably just mean rebuilding for the most popular architectures (that is, AMD64 or i386), hardware for which is readily available and should pose no additional effort to get. And it would mean IMO a good leap forward in ensuring buildability — Even more with arch:all I doubt it would make any change in the workload for us in the DSA. I assume it will lead to a slight increase in workload for the buildd maintainers. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2z3fc3t@xoog.err.no
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
Didier Raboud dijo [Wed, Nov 21, 2012 at 09:21:19PM +0100]: I am asking why, when I had a reason to do so, was not able to do a source-only upload. Is this a feature of dak, or a policy enforcement? Both. I'd argue that it's a bug in both. BTW, can we have this as a release goal for jessie, that all packages have been build on Debian buildd infrastructure? ;-) Actually, I like that way to put it as it leaves us with multiple ways forward: * accept source-only; * drop uploaded binaries; I would join this camp as well. Without the working knowledge of being a DSA or buildd-admin, I cannot assure how much would this increase our workload, but it would probably just mean rebuilding for the most popular architectures (that is, AMD64 or i386), hardware for which is readily available and should pose no additional effort to get. And it would mean IMO a good leap forward in ensuring buildability — Even more with arch:all * (optionally: ) diff built and uploaded binaries, blame; This can be a bit more tricky. Of course, diffing the .build fails would not work, to begin with, because of the pathnames. But even diffing the shipped files — two shipped files are not guaranteed to be bit-by-bit identical, even if compiled in the same hardware. What is yet unclear is if we want to build all (as in arch:any+all) or all (as in arch:any) packages on buildds. Rebuilding arch:all packages is quite important IMO. I would probably add a rebuild when entering testing where this to be a perfect world, to ensure continued buildability. But I know it's probably too much to ask... And it would still be incomplete (as rebuilding anything that build-depends on this package could still be added — And down this path we can find madness...) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121123163002.ga6...@gwolf.org
Re: release goal for jessie! (Re: Source-only uploads
On 11/24/2012 12:30 AM, Gunnar Wolf wrote: I would join this camp as well. Without the working knowledge of being a DSA or buildd-admin, I cannot assure how much would this increase our workload, but it would probably just mean rebuilding for the most popular architectures (that is, AMD64 or i386), hardware for which is readily available and should pose no additional effort to get. And it would mean IMO a good leap forward in ensuring buildability — Even more with arch:all +1 to all of the above Though I'm in the favor of dropping binaries rather than source-only, so that later it would be possible to do some sanity checks with the buildd and DD version of the binary packages (it doesn't have to be a bit-by-bit compare, but I'm sure we can find some interesting tests to do, like checking if control files are identical, etc...). Just a 2 cents idea, since I wont be implementing it, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50afd5a3.6090...@debian.org
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Wed, Nov 21, 2012 at 09:21:19PM +0100, Didier Raboud wrote: What is yet unclear is if we want to build all (as in arch:any+all) or all (as in arch:any) packages on buildds. Are there any reasons to not built arch:all on buildds aside from technical problems? -- WBR, wRAR signature.asc Description: Digital signature
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
you always need to build for one arch and test, then why not upload it? On Thu, Nov 22, 2012 at 4:33 PM, Andrey Rahmatullin w...@wrar.name wrote: On Wed, Nov 21, 2012 at 09:21:19PM +0100, Didier Raboud wrote: What is yet unclear is if we want to build all (as in arch:any+all) or all (as in arch:any) packages on buildds. Are there any reasons to not built arch:all on buildds aside from technical problems? -- WBR, wRAR -- YunQiang Su
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Fri, Nov 23, 2012 at 03:06:22PM +0800, YunQiang Su wrote: you always need to build for one arch and test, then why not upload it? How is that related to my question? Also, please don't top-post and dont send me copies. On Thu, Nov 22, 2012 at 4:33 PM, Andrey Rahmatullin w...@wrar.name wrote: On Wed, Nov 21, 2012 at 09:21:19PM +0100, Didier Raboud wrote: What is yet unclear is if we want to build all (as in arch:any+all) or all (as in arch:any) packages on buildds. Are there any reasons to not built arch:all on buildds aside from technical problems? -- WBR, wRAR signature.asc Description: Digital signature
release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
Hi, On Dienstag, 20. November 2012, Henrique de Moraes Holschuh wrote: I am asking why, when I had a reason to do so, was not able to do a source-only upload. Is this a feature of dak, or a policy enforcement? Both. I'd argue that it's a bug in both. BTW, can we have this as a release goal for jessie, that all packages have been build on Debian buildd infrastructure? ;-) cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201211212059.03249.hol...@layer-acht.org
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
Le mercredi, 21 novembre 2012 20.59:02, Holger Levsen a écrit : Hi, On Dienstag, 20. November 2012, Henrique de Moraes Holschuh wrote: I am asking why, when I had a reason to do so, was not able to do a source-only upload. Is this a feature of dak, or a policy enforcement? Both. I'd argue that it's a bug in both. BTW, can we have this as a release goal for jessie, that all packages have been build on Debian buildd infrastructure? ;-) Actually, I like that way to put it as it leaves us with multiple ways forward: * accept source-only; * drop uploaded binaries; * (optionally: ) diff built and uploaded binaries, blame; What is yet unclear is if we want to build all (as in arch:any+all) or all (as in arch:any) packages on buildds. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201211212121.19776.o...@debian.org
Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On 20 November 2012 12:23, Henrique de Moraes Holschuh h...@debian.org wrote: On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote: I am sorry, if I was not clear. I am aware of the last iteration, but I am not enquiring about the default policy within debian as to how we should upload by default. I am asking why, when I had a reason to do so, was not able to do a source-only upload. Is this a feature of dak, or a policy enforcement? Both. Where is this policy documented? I have checked Debian Policy and ftp-masters mini-site faq/rejects sections. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujq19s9rvymg8_o6eireyh6fvhlhmzh6u5j-bv8_nc...@mail.gmail.com
Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On 20 November 2012 11:14, Andrey Rahmatullin w...@wrar.name wrote: On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote: Source-only uploads are not allowed. Why not? May I request a binNMU for the architecture (amd64) I upload? I currently do not have facilities to build the package in question with the host running Debian's kernel. For the package in question it is important to build in the same environment as the rest of the packages in the distribution. The sole purpose of the package is to gather as much detail about the environment as possible, which has been proven to be highly valuable for security analysis and fixing highly strict test-suites. The last iteration of this was started at http://lists.debian.org/debian-devel/2012/10/msg00296.html I am sorry, if I was not clear. I am aware of the last iteration, but I am not enquiring about the default policy within debian as to how we should upload by default. I am asking why, when I had a reason to do so, was not able to do a source-only upload. Is this a feature of dak, or a policy enforcement? If it's a policy enforcement, I am ok with it. Otherwise, I'd would like to see dak accept those. I have a vague recollection of a UDD presentations which did list count of DDs doing source-only uploads. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujhme6yf+xsjorlkj_xtf62s6xehew8f+zehojpktk...@mail.gmail.com
Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote: I am sorry, if I was not clear. I am aware of the last iteration, but I am not enquiring about the default policy within debian as to how we should upload by default. I am asking why, when I had a reason to do so, was not able to do a source-only upload. Is this a feature of dak, or a policy enforcement? Both. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121120122309.gb22...@khazad-dum.debian.net
Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Tue, Nov 20, 2012 at 12:08:13PM +, Dmitrijs Ledkovs wrote: If it's a policy enforcement, I am ok with it. Otherwise, I'd would like to see dak accept those. I have a vague recollection of a UDD presentations which did list count of DDs doing source-only uploads. source+all uploads probably? Also, I'm subscribed. -- WBR, wRAR signature.asc Description: Digital signature
Re: Source only uploads? -- Survey evaluation
On Tue, 2003-12-02 at 02:41, Goswin von Brederlow wrote: Source only uploads were afaik disabled because the uploaded source would just disapear and never enter the archive afaik. It was just easier to block them than to fix the archive scripts I guess. Just trying it (for fun, see package spass ;-), I didn't encounter any problems. Wolfgang [1] could reproduce it (see the packages pages when they are up again), but it was disabled some day afterwards. bye, Roland [1] http://lists.debian.org/debian-devel/2003/debian-devel-200310/msg01226.html signature.asc Description: This is a digitally signed message part
Re: Source only uploads? -- Survey evaluation
On Mon, Dec 01, 2003 at 10:09:34PM +0100, Roland Stigge wrote: Finally, the decision isn't just technical. Ah, the inevitable cry of the advocate of the technically inferior approach. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads? -- Survey evaluation
On 01-Dec-03, 08:26 (CST), Roland Stigge [EMAIL PROTECTED] wrote: Unfortunately, there wasn't much response to this. Maybe this is related to the big Debian KO. Or maybe because making technical decisions by voting is silly. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Source only uploads? -- Survey evaluation
* Roland Stigge ([EMAIL PROTECTED]) [031201 15:55]: On Sat, 2003-11-15 at 14:50, Roland Stigge wrote: [...] Instead, I volunteer to host a small, unofficial and non-anonymous survey to get an impression of the community's opinion. If you are a Debian Developer, please send me a private mail with Source only uploads: Yes or Source only uploads: No in the subject. At the beginning of December, I will post the results, and if there is any doubt, I will disclose the list of names and votes. Unfortunately, there wasn't much response to this. Maybe this is related to the big Debian KO. I didn't see this survey timly (and as I'm not a DD you'd probably also not interested in my opinion). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Source only uploads? -- Survey evaluation
Hi Steve, Unfortunately, there wasn't much response to this. Maybe this is related to the big Debian KO. Or maybe because making technical decisions by voting is silly. At this stage, I personally decided that more official efforts wouldn't be appropriate just to reflect the community's opinion (at least better than the preceding discussion) considering that source only uploads were enabled and disabled in the past without further notice or discussion otherwise. Of course, we can take this as a base of further actions. Finally, the decision isn't just technical. bye, Roland signature.asc Description: This is a digitally signed message part
Re: Source only uploads? -- Survey evaluation
On Tue, 2003-12-02 at 01:26, Roland Stigge wrote:
Meanwhile, I strongly suggest the utilization of pbuilder{,-uml} to
increase quality. Some developers (not the ones who participated here) I
talked with have never used these tools. Their usage will prevent many
of those stupid FTBFS bugs.
Does it make sense to have a boilerplate suggestion line suggesting
this, produced by default for all FTBFS emails sent out by bug tracker?
zen
--
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.
Re: Source only uploads? -- Survey evaluation
Roland Stigge [EMAIL PROTECTED] writes: Hi Steve, Unfortunately, there wasn't much response to this. Maybe this is related to the big Debian KO. Or maybe because making technical decisions by voting is silly. At this stage, I personally decided that more official efforts wouldn't be appropriate just to reflect the community's opinion (at least better than the preceding discussion) considering that source only uploads were enabled and disabled in the past without further notice or discussion otherwise. Of course, we can take this as a base of further actions. Finally, the decision isn't just technical. Source only uploads were afaik disabled because the uploaded source would just disapear and never enter the archive afaik. It was just easier to block them than to fix the archive scripts I guess. MfG Goswin
Re: Source only uploads?
On Mon, Oct 20, 2003 at 02:07:33PM -0500, Gunnar Wolf wrote: I think a third (or, after reading some replies to this same mail, fourth, fifth or nth) way could be used: Binary packages enter Sid as usual. Now, after the 10-day period, when they are ready to enter Testing, they are autobuilt. Only the autobuilt version hits Testing. This will help us reduce the load on autobuilders, as not every probably-buggy version will be autobuilt. It will also help maintain Testing's quality/stability, as all packages entering it will have proof of at least being buildable. Of course, for human developers, this might mean a bit of extra work, finding out why the heck did it not compile as planned when entering Testing, as we will have to check for specific versions and probably work in chroots or similar environments (which we already sometimes need)... But testing will be cleaner, which is a Good Thing. This will also solve one additional thing: many packages have not hit Testing (or have been held for too long) because one of their dependencies is stuck in Unstable. If packages that prove that _by themselves_ introduce no new bugs are allowed into testing, this will be less of an issue. (Now that... Well, yes, some important libraries such as glibc will have to trigger myriads of autobuilds when they finally enter Testing, in order to ensure that things are still OK - This seems a bit scary, but at least interesting ;-) ) Oh, now we've gotten the build packages against Testing debate intermingled with the autobuild everything debate? At least, that's how I read that last paragraph... I was _expecting_ (based on the rest of the email) that you meant building against unstable as of the testing-candidate time to pick up newer dependancies having been uploaded in the meantime (which I can understand might help with packages keeping newer dependancies out of testing) However, I think that would both load the autobuilders and delay the entire testing process, as _all_ arches would need to rebuild the package twice (unless you propose candidates become valid without being built on all architectures) and of course, the time between valid candidicy and sarge+1-ing would allow the possible skew to reoccur, solving nothing. Maybe someway of tracking dependancies and knowing when the package needs to be auto-rebuilt against a newer dependant package would help, but that seems orthogonal to _this_ discussion. -- --- Paul TBBle Hampson 6th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] If they leave no survivors, where do the stories come from? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Source only uploads?
On Tue, Oct 21, 2003 at 09:52:14AM +1000, Brian May wrote: 1. A package may not be important to developers, but is still important to users. Alternatively, developers may simply recompile the package without submitting a bug report. One would hope that developers would bother filing a bug report. 2. The package may be broken in that it is inconsistant, but still work fine, or work fine for most features. There is also the possibility that it'll be broken in a way that only shows up when it hits testing - remember all the debconf problems that showed up when testing was in its infancy? -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Source only uploads?
Paul Hampson dijo [Tue, Oct 21, 2003 at 02:19:53PM +1000]: Oh, now we've gotten the build packages against Testing debate intermingled with the autobuild everything debate? At least, that's how I read that last paragraph... I was _expecting_ (based on the rest of the email) that you meant building against unstable as of the testing-candidate time to pick up newer dependancies having been uploaded in the meantime (which I can understand might help with packages keeping newer dependancies out of testing) However, I think that would both load the autobuilders and delay the entire testing process, as _all_ arches would need to rebuild the package twice (unless you propose candidates become valid without being built on all architectures) and of course, the time between valid candidicy and sarge+1-ing would allow the possible skew to reoccur, solving nothing. Maybe someway of tracking dependancies and knowing when the package needs to be auto-rebuilt against a newer dependant package would help, but that seems orthogonal to _this_ discussion. Yes, part of my reasoning was done while writing the message :-) I know this seems to solve nothing, although I insist it does - It would require, yes, more autobuilder time. It would noticeably speed up packages entering testing. I know, this would require -as you say- tracking dependencies and probably auto-rebuilding versions that are already in Testing when newer versions of their dependencies enter Testing, and breakage can occur along the road, but I think it would be a worthy idea - If we can spare the extra building time it will require, specially on slow architectures. Or (although I understand some of the concerns against it) autobuilding using cross-compilers. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 06:55:50PM +0200, Joachim Breitner wrote: Hi, Am So, den 19.10.2003 schrieb Andrew Suffield um 21:08: On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Well, any maintainer that uses packages from experimental should not build their packages on these mixed systems. Therefore, they use chroots or a similar thing (unless they can afford an extra box for building). In any case, this is an artificial environment, constructed especially for the purpose of building packages for debian. Thus, that is no way better or worse than debian's buildd. Yep, i was again bitten with what was apparently a problem related to not doing so. I built lablgl on my system, and as a result a glMultTransposeMatrixd is wrapped, while only glMultTransposeMatrixdARB seems to be available in the 4.2.1 mesa packages or something such. Will need to rebuild in a pbuilder. Friendly, Sven Luther
Re: Source only uploads?
On Mon, Oct 20, 2003 at 02:07:33PM -0500, Gunnar Wolf wrote: Andrew Suffield dijo [Mon, Oct 20, 2003 at 07:57:20AM +0100]: So, we have two scenarios. Let the package be broken in such a way that it builds differently on different platforms. a) All packages uploaded to the archive are built in an artifical environment. All packages in the archive function as expected. b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. I would prefer (a) over (b) - Yes, it breaks more, but that is exactly what we want: We want broken packages to appear as seldom as possible in the archive. Uhh... what? That didn't make any sense. it breaks more, but that is exactly what we want: ... in particular. You seem to have gotten your goals really twisted here. The goal, as I see it, is to produce the best packages that we realistically are able to. Not to produce a superficially working release. Strictly as stated, your goal is accurate, but as implied, it is not. You are implying that this applies only to binary packages. I say that failing to function when built in anything but a particular artificial environment is a serious bug in a source package. Any action whose effect is to avoid noticing these bugs cannot be a good idea. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 06:55:50PM +0200, Joachim Breitner wrote: Am So, den 19.10.2003 schrieb Andrew Suffield um 21:08: On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Well, any maintainer that uses packages from experimental should not build their packages on these mixed systems. Therefore, they use chroots or a similar thing (unless they can afford an extra box for building). In any case, this is an artificial environment, constructed especially for the purpose of building packages for debian. Thus, that is no way better or worse than debian's buildd. Sure, it happens sometimes. This is not an argument for it to happen in every case, which is what I was responding to. [Ignore Sven's small army of straw men, they aren't even remotely relevant] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Tue, Oct 21, 2003 at 09:11:28AM +1000, Andrew Pollock wrote: On Mon, Oct 20, 2003 at 06:08:27PM +0200, Sven Luther wrote: Sure, sure. Just give me one real world reason why it is not good to build in an artificial environment like you call it (either pbuilder or an autobuilder) and i will go away, as you say. Yes, please do. I've been following this thread with interest, because I have always found it inconsistent that usually $(DEBIAN_ARCHITECTURES) - 1 were built by the buildds, but the binary package the maintainer uploads was built in a completely heterogenous environment to the rest. I would have thought for the sake of consistency, it would be best if binary packages for all $(DEBIAN_ARCHITECTURES) were built the same way. For the same reason, I would have thought an unstable pbuilder chroot would provide a higher degree of consistency for the one binary package the maintainer uploads now, than to build the package in the significantly more random environment of the developer's development machine? (Unless he/she dedicates a machine to tracking unstable for no other purpose than to build packages). Forgive me, I am relatively new, so I may be missing the obvious... Read my earlier mails in the thread. I already covered this. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 07:46:27PM +0200, Goswin von Brederlow wrote: Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Oct 20, 2003 at 12:13:22PM +0200, Goswin von Brederlow wrote: b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. Why would it ever be noticed? That only happens if someone manually rebuilds the package and notices a difference. Something like being linked against different versions of libc or even different versions of libpng might go unnoticed for a long time. If you are arguing that such issues will not be noticed, then you have just defeated your own argument. Your argument has been founded upon the notion that packages built on real-world systems might be broken. You are now saying that nobody will notice - in which case it doesn't matter at all, and the status quo should remain. There are lots of cases where the source is broken or the used libraries are not what they should be that don't make the programm segfault. A user might never notice the difference. At the moment, unless someone manually rebuilds, a binary-all package can be completly unbuildable unless you have the exact same environment as the maintainer and do the same dirty hacks he did to build. The case where an uploaded binary just does not run is pretty uncommon and will get noticed by the first user updating. Thats what sid is for. I'm not realy concerned with bugs in the binary (in this discusson), source only uploads wont do a think to change them. Okay, you're committing the fallacy of affirmation of the consequant. Your implication is: If we only make source uploads, then this problem won't happen And your assertion is: We don't want this problem to happen From this you derive the conclusion: We should only make source uploads This is logically invalid. When the consequant is true, the antecedent is irrelevant. Translating this into practical terms, you're wrong because we could fix this problem in other ways. For example, we could build the arch-indep packages someplace and not bother to upload them. Hey, that's what actually happens. It just isn't automated yet. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. You say that in case B bugs will be noticed, which implies people are recompiling the packages in their own environments. But then bugs would just as well be noticed in case A. So far the best suggestion for this problem I have heart was to allow (require) binary uploads but to hold them back and autobuild everything for all archs. Only binaries allowed into archive are autobuilders and binary-only uploads (to allow fixing autobuilder lags or problems). It is evident from these two paragraphs that you did not read my mail and understand it. I have already given reasons for why they are wrong, albeit not attached to the same examples. You reason for case B (that people will test build and find bugs) just as well applies to case A. That makes your point void. Empirically false. In fact, you've missed the point entirely, since that *was* the point. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
Andrew Suffield dijo [Tue, Oct 21, 2003 at 07:12:22PM +0100]: Strictly as stated, your goal is accurate, but as implied, it is not. You are implying that this applies only to binary packages. I say that failing to function when built in anything but a particular artificial environment is a serious bug in a source package. Any action whose effect is to avoid noticing these bugs cannot be a good idea. I completely agree with you. A natural environment has a much larger probability to introduce mistakes than an artificial one - if a mistake appears when building in a overly limited artificial environment, we can quite confidently conclude that the packager omitted something. Most (trivial) FTBFS bugs I have inspected arise from an omitted build-dependency. Many, as Sven Luther points out, are introduced because the natural environment (the maintainer's machine) has some packages that do not belong to our unstable branch and thus generate problematic (sometimes with problems too subtle to be easily found, that often arise after the package has descended into testing). I sent this idea because many people were debating if it would be a waste of autobuilder resources to restrict to source-only uploads or binary uploads with a discarded binary (which I think would be best). While writting down my idea, some extra thoughts twisted it beyond any recognition - but the basic idea stands. I would prefer not letting packages into testing which were not autobuilt. As a sidenote, I remember some months ago there was a thread about information regarding a particular developer's working environment being distributed with the packages they built - If everything were to be autobuilt, we would also get rid of this (minor, IMHO) problem. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Source only uploads?
* John Hasler | Matt Zimmerman writes: | This premise assumes that only developers use unstable, and in my | experience this is very far from the truth. | | It is true that some packages go into testing without having been tested on | all platforms. Some packages probably go into stable without having been tested on all platforms. If this happens, well, then that arch is a little screwed. That's the cost of not having people running unstable for that arch. (I can imagine say, KDE being broken on m68k without anybody really noticing -- it's probably so slow on that hardware, so nobody in their right mind will run it on that hardware. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Source only uploads?
On Tue, Oct 21, 2003 at 03:12:17PM -0500, Gunnar Wolf wrote: beyond any recognition - but the basic idea stands. I would prefer not letting packages into testing which were not autobuilt. Another argument: trojaned binaries can more easyly happen on hundrets of machines with differen secuirty policies. Not that I think auto builders are safe from that, but the environemnt is more easyly controleable. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Source only uploads?
On Mon, Oct 20, 2003 at 09:39:54AM +1000, Brian May wrote: On Sun, Oct 19, 2003 at 08:08:11PM +0100, Andrew Suffield wrote: And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? What are you talking about? I'm not the one proposing anything. The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Autobuilders already build packages in an artificial environment for every architecture except the one the maintainer used for uploading. Surely making every package consistant on every architecture should be a goal for Debian? Sure, ideally the package should build exactly the same way where ever it is built, but differences can emerge with out being obvious, for instance if a package detects an extra library is installed on the maintainers machine and automatically uses it without the maintainer being aware of what is happening (this happened with early versions of Heimdal and libhesiod0 in fact). So, we have two scenarios. Let the package be broken in such a way that it builds differently on different platforms. a) All packages uploaded to the archive are built in an artifical environment. All packages in the archive function as expected. b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
Hi, Andrew Suffield wrote:
a) All packages uploaded to the archive are built in an artifical
environment. All packages in the archive function as expected.
b) The package is uploaded from real-world environments. Sometimes it
breaks; when this happens the bug is noticed and corrected, so that the
package always builds the same way.
c) The package is uploaded from the real-world environment where it works,
built on the architecture 99% of the users have. The breakage in the
other architectures' autobuilt packages is not noticed until after Sarge,
and/or when somebody does an NMU (or takes over the package) and suffers
from severe brain trauma trying to figure out how the h*ll it could have
worked _ever_.
I say that (b) is vastly superior to (a).
I say that (a) and (b) have different trade-offs. However, you can't have
(b) without also risking (c). Since (c) is really not a nice thing to
happen, IMHO we should default to (a) -- consistency is good.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
O'Toole's commentary on Murphy's Law:
Murphy was an optimist.
Re: Source only uploads?
On Sun, Oct 19, 2003 at 08:08:11PM +0100, Andrew Suffield wrote: On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: On Sat, Oct 18, 2003 at 09:39:05PM +0100, Andrew Suffield wrote: On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote: Its good for the autobuilders to check again if a package builds in a mainly minimal environment. That's an argument for building it *once* in such an environment. It is definitely not an argument that it should only be built in such an environment, which was the point in question. Ok, no problem. I suppose you just volunteered to fix all the bugs against my packages that fail due to broken dependency brought in by using experimental packages. You have a significant number of such bugs? That's like standing up in a crowded room and announcing you have a highly contagious skin disease. Well, i would potentially have one for every xlibs depending package i upload. As well as all the other people who run experimental stuff on their developer box. And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? What are you talking about? I'm not the one proposing anything. Yes, you propose that we should build our packages on widely unhomogenous systems with random non-official packages on it, some of which may even include incompatible patches or whatever. The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Thanks for calling me braindamaged :) Seriously, i perfectly understood what you are proposing, and i think you don't realize the things involved for making such a proposal. Think about it seriously, and you will see why your proposal is not a good idea. Friendly, Sven Luther
Re: Source only uploads?
On Mon, Oct 20, 2003 at 07:57:20AM +0100, Andrew Suffield wrote: On Mon, Oct 20, 2003 at 09:39:54AM +1000, Brian May wrote: On Sun, Oct 19, 2003 at 08:08:11PM +0100, Andrew Suffield wrote: And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? What are you talking about? I'm not the one proposing anything. The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Autobuilders already build packages in an artificial environment for every architecture except the one the maintainer used for uploading. Surely making every package consistant on every architecture should be a goal for Debian? Sure, ideally the package should build exactly the same way where ever it is built, but differences can emerge with out being obvious, for instance if a package detects an extra library is installed on the maintainers machine and automatically uses it without the maintainer being aware of what is happening (this happened with early versions of Heimdal and libhesiod0 in fact). So, we have two scenarios. Let the package be broken in such a way that it builds differently on different platforms. a) All packages uploaded to the archive are built in an artifical environment. All packages in the archive function as expected. This is the good think to do. b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. A Malicious maintainer has installed a version of libc or whatever on his system that opens the way to a security hole. He builds a package on his system which links this libc statically and uploads it. Conclusion, there is a security hole in the uploaded packages that there is no way to trace given the sources only. Furthermore, it may even violate the GPL in some cases, where a maintainer uses a patch on his system, which is linked into a packages he uploads, and there is no trace of the source code for this patch anywhere. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. And you think than building the package in an environment corresponding to what _1_ maintainer use is better than building it in an environment that will be the same for every installed system once it is rebuilt. Friendly, Sven Luther
Re: Source only uploads?
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Oct 20, 2003 at 09:39:54AM +1000, Brian May wrote: So, we have two scenarios. Let the package be broken in such a way that it builds differently on different platforms. a) All packages uploaded to the archive are built in an artifical environment. All packages in the archive function as expected. The environment is not perfectly artifical. All but the first build of a new chroot have some possible dirt lying around. Actually a few Build-Conflicts have been noticed that way by accident. b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. Why would it ever be noticed? That only happens if someone manually rebuilds the package and notices a difference. Something like being linked against different versions of libc or even different versions of libpng might go unnoticed for a long time. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. You say that in case B bugs will be noticed, which implies people are recompiling the packages in their own environments. But then bugs would just as well be noticed in case A. So far the best suggestion for this problem I have heart was to allow (require) binary uploads but to hold them back and autobuild everything for all archs. Only binaries allowed into archive are autobuilders and binary-only uploads (to allow fixing autobuilder lags or problems). MfG Goswin
Re: Source only uploads?
Hi, what if we stick to our principle the maintainer knows best and provide the infrastructure for source only uploads, but leave it to the maintainer whether he wants to do so. Some here think buildd'ed packages are better, some think their building the packages themselves is better. So just the former one do so and see what is used more, what stands the test. Eventually, we might agree on one or the other way, but there is actually no need for that. Compare it to the different ways of building a package (self-made debian/rules, dh_helper, cdbs) - it's all about choice and preference. with regards, nomeata Am Mi, den 15.10.2003 schrieb W. Borgert um 19:48: Hi, a few days ago, I uploaded an emacs mode package (all) source only w/o problems to ftp-master. Today, a source only upload was rejected. Why? I think, we should get rid of binary uploads... Cheers! -- Joachim nomeata Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Source only uploads?
Goswin writes: So far the best suggestion for this problem I have heart was to allow (require) binary uploads but to hold them back and autobuild everything for all archs. Or hold them back until at least one autobuild succeeds. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Source only uploads?
On Mon, Oct 20, 2003 at 10:51:20AM +0200, Matthias Urlichs wrote: Hi, Andrew Suffield wrote: a) All packages uploaded to the archive are built in an artifical environment. All packages in the archive function as expected. b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. c) The package is uploaded from the real-world environment where it works, built on the architecture 99% of the users have. The breakage in the other architectures' autobuilt packages is not noticed until after Sarge, and/or when somebody does an NMU (or takes over the package) and suffers from severe brain trauma trying to figure out how the h*ll it could have worked _ever_. This is the same as (b), only delayed. Still acceptable - we noticed the bug and fixed it. I say that (b) is vastly superior to (a). I say that (a) and (b) have different trade-offs. However, you can't have (b) without also risking (c). Since (c) is really not a nice thing to happen, IMHO we should default to (a) -- consistency is good. Sounds like the perfect getting in the way of the good; the end result sucks. Papering over these issues is *not the answer*. Find them and fix them, it's not hard. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
I disagree with the parent mail in every respect. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 12:13:22PM +0200, Goswin von Brederlow wrote: b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. Why would it ever be noticed? That only happens if someone manually rebuilds the package and notices a difference. Something like being linked against different versions of libc or even different versions of libpng might go unnoticed for a long time. If you are arguing that such issues will not be noticed, then you have just defeated your own argument. Your argument has been founded upon the notion that packages built on real-world systems might be broken. You are now saying that nobody will notice - in which case it doesn't matter at all, and the status quo should remain. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. You say that in case B bugs will be noticed, which implies people are recompiling the packages in their own environments. But then bugs would just as well be noticed in case A. So far the best suggestion for this problem I have heart was to allow (require) binary uploads but to hold them back and autobuild everything for all archs. Only binaries allowed into archive are autobuilders and binary-only uploads (to allow fixing autobuilder lags or problems). It is evident from these two paragraphs that you did not read my mail and understand it. I have already given reasons for why they are wrong, albeit not attached to the same examples. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 10:55:40AM +0200, Sven Luther wrote: Seriously, i perfectly understood what you are proposing, and i think you don't realize the things involved for making such a proposal. Think about it seriously, and you will see why your proposal is not a good idea. FUD. Go away. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 03:24:54PM +0100, Andrew Suffield wrote: On Mon, Oct 20, 2003 at 10:55:40AM +0200, Sven Luther wrote: Seriously, i perfectly understood what you are proposing, and i think you don't realize the things involved for making such a proposal. Think about it seriously, and you will see why your proposal is not a good idea. FUD. Go away. Sure, sure. Just give me one real world reason why it is not good to build in an artificial environment like you call it (either pbuilder or an autobuilder) and i will go away, as you say. Friendly, Sven Luther
Re: Source only uploads?
Hi, Am So, den 19.10.2003 schrieb Andrew Suffield um 21:08: On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Well, any maintainer that uses packages from experimental should not build their packages on these mixed systems. Therefore, they use chroots or a similar thing (unless they can afford an extra box for building). In any case, this is an artificial environment, constructed especially for the purpose of building packages for debian. Thus, that is no way better or worse than debian's buildd. I hope this supports my proposal in the other mail :-) nomeata -- Joachim nomeata Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Source only uploads?
On Mon, Oct 20, 2003 at 08:01:08AM -0500, John Hasler wrote: Goswin writes: So far the best suggestion for this problem I have heart was to allow (require) binary uploads but to hold them back and autobuild everything for all archs. Or hold them back until at least one autobuild succeeds. You're going to have to explain this one to me. You want to hold them back (not try to build them) until one build succeeds? In that scenario, no build will succeed, but I hope you meant something else. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Source only uploads?
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Oct 20, 2003 at 12:13:22PM +0200, Goswin von Brederlow wrote: b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. Why would it ever be noticed? That only happens if someone manually rebuilds the package and notices a difference. Something like being linked against different versions of libc or even different versions of libpng might go unnoticed for a long time. If you are arguing that such issues will not be noticed, then you have just defeated your own argument. Your argument has been founded upon the notion that packages built on real-world systems might be broken. You are now saying that nobody will notice - in which case it doesn't matter at all, and the status quo should remain. There are lots of cases where the source is broken or the used libraries are not what they should be that don't make the programm segfault. A user might never notice the difference. At the moment, unless someone manually rebuilds, a binary-all package can be completly unbuildable unless you have the exact same environment as the maintainer and do the same dirty hacks he did to build. The case where an uploaded binary just does not run is pretty uncommon and will get noticed by the first user updating. Thats what sid is for. I'm not realy concerned with bugs in the binary (in this discusson), source only uploads wont do a think to change them. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. You say that in case B bugs will be noticed, which implies people are recompiling the packages in their own environments. But then bugs would just as well be noticed in case A. So far the best suggestion for this problem I have heart was to allow (require) binary uploads but to hold them back and autobuild everything for all archs. Only binaries allowed into archive are autobuilders and binary-only uploads (to allow fixing autobuilder lags or problems). It is evident from these two paragraphs that you did not read my mail and understand it. I have already given reasons for why they are wrong, albeit not attached to the same examples. You reason for case B (that people will test build and find bugs) just as well applies to case A. That makes your point void. MfG Goswin
Re: Source only uploads?
On Mon, Oct 20, 2003 at 10:51:20AM +0200, Matthias Urlichs wrote: c) The package is uploaded from the real-world environment where it works, built on the architecture 99% of the users have. The breakage in the other architectures' autobuilt packages is not noticed until after Sarge, and/or when somebody does an NMU (or takes over the package) and suffers from severe brain trauma trying to figure out how the h*ll it could have worked _ever_. If a broken package is not noticed in unstable, the package must not be particularly important to anyone. -- - mdz
Re: Source only uploads?
Andrew Suffield dijo [Mon, Oct 20, 2003 at 07:57:20AM +0100]: So, we have two scenarios. Let the package be broken in such a way that it builds differently on different platforms. a) All packages uploaded to the archive are built in an artifical environment. All packages in the archive function as expected. b) The package is uploaded from real-world environments. Sometimes it breaks; when this happens the bug is noticed and corrected, so that the package always builds the same way. I say that (b) is vastly superior to (a). The tradeoff is temporary bugs in sid versus unnoticed bugs in a release. We'll never trap all the bugs, but going out of your way to _not look_ cannot be a good idea. I would prefer (a) over (b) - Yes, it breaks more, but that is exactly what we want: We want broken packages to appear as seldom as possible in the archive. I think a third (or, after reading some replies to this same mail, fourth, fifth or nth) way could be used: Binary packages enter Sid as usual. Now, after the 10-day period, when they are ready to enter Testing, they are autobuilt. Only the autobuilt version hits Testing. This will help us reduce the load on autobuilders, as not every probably-buggy version will be autobuilt. It will also help maintain Testing's quality/stability, as all packages entering it will have proof of at least being buildable. Of course, for human developers, this might mean a bit of extra work, finding out why the heck did it not compile as planned when entering Testing, as we will have to check for specific versions and probably work in chroots or similar environments (which we already sometimes need)... But testing will be cleaner, which is a Good Thing. This will also solve one additional thing: many packages have not hit Testing (or have been held for too long) because one of their dependencies is stuck in Unstable. If packages that prove that _by themselves_ introduce no new bugs are allowed into testing, this will be less of an issue. (Now that... Well, yes, some important libraries such as glibc will have to trigger myriads of autobuilds when they finally enter Testing, in order to ensure that things are still OK - This seems a bit scary, but at least interesting ;-) ) This last consideration might kill the first advantage I talked about (reducing buildd workload), but I think it can help us have a stabler Testing distribution. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Source only uploads?
I wrote: Or hold them back until at least one autobuild succeeds. Wouter Verhelst writes: You're going to have to explain this one to me. You want to hold them back (not try to build them) until one build succeeds? Hold back the maintainer's binary upload until at least one autobuild succeeds. This would keep unbuildable packages out of the archive. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Source only uploads?
Gunnar Wolf writes: I think a third (or, after reading some replies to this same mail, fourth, fifth or nth) way could be used: Binary packages enter Sid as usual. Now, after the 10-day period, when they are ready to enter Testing, they are autobuilt. Only the autobuilt version hits Testing. Then Sid would contain almost nothing but i386 binaries. And when Chrony breaks on one of the autobuilders and I upload a hopefully fixed version I would get to wait ten days before it gets autobuilt again. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Source only uploads?
On Mon, Oct 20, 2003 at 11:03:03AM +0200, Sven Luther wrote: A Malicious maintainer has installed a version of libc or whatever on his system that opens the way to a security hole. Because, of course, a malicious buildd admin or member of the Debian Security Team is a flat impossibility, as is compromise of a buildd box. Why, breach of a Debian Project machine is so impossible, it hasn't even happened in the past *COUGHCOUGHCOUGHCOUGHCOUGH -- GAG CHOKE WHEEZE -- COUGHCOUGHCOUGHmaybeyoushouldreaddebian-privateCOUGHCOUGHCOUGH*. And we've never had a package uploaded with an *upstream* Trojan in it either, which escaped the attention of the package maintainer and which was gleefully compiled by the buildds, and dutifully signed by the buildd admins! *COUGH*micq*COUGH* /me clears throat. Much better. Yes, surely your proposed scenario will save us from these evils. -- G. Branden Robinson|Of two competing theories or Debian GNU/Linux |explanations, all other things [EMAIL PROTECTED] |being equal, the simpler one is to http://people.debian.org/~branden/ |be preferred. -- Occam's Razor signature.asc Description: Digital signature
Re: Source only uploads?
John Hasler dijo [Mon, Oct 20, 2003 at 03:25:45PM -0500]: Gunnar Wolf writes: I think a third (or, after reading some replies to this same mail, fourth, fifth or nth) way could be used: Binary packages enter Sid as usual. Now, after the 10-day period, when they are ready to enter Testing, they are autobuilt. Only the autobuilt version hits Testing. Then Sid would contain almost nothing but i386 binaries. And when Chrony breaks on one of the autobuilders and I upload a hopefully fixed version I would get to wait ten days before it gets autobuilt again. No, we would still build when entering Sid for the rest of the architectures. Only that when entering Testing, it would be autobuilt for just the remaining architecture or (if it was needed) for all of them. I know that my idea instead of saving buildd time works the other way around, but it can at least help us get a more stable Testing. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Source only uploads?
On Mon, Oct 20, 2003 at 06:08:27PM +0200, Sven Luther wrote: Sure, sure. Just give me one real world reason why it is not good to build in an artificial environment like you call it (either pbuilder or an autobuilder) and i will go away, as you say. Yes, please do. I've been following this thread with interest, because I have always found it inconsistent that usually $(DEBIAN_ARCHITECTURES) - 1 were built by the buildds, but the binary package the maintainer uploads was built in a completely heterogenous environment to the rest. I would have thought for the sake of consistency, it would be best if binary packages for all $(DEBIAN_ARCHITECTURES) were built the same way. For the same reason, I would have thought an unstable pbuilder chroot would provide a higher degree of consistency for the one binary package the maintainer uploads now, than to build the package in the significantly more random environment of the developer's development machine? (Unless he/she dedicates a machine to tracking unstable for no other purpose than to build packages). Forgive me, I am relatively new, so I may be missing the obvious... Andrew
Re: Source only uploads?
On Mon, Oct 20, 2003 at 02:17:40PM -0400, Matt Zimmerman wrote: c) The package is uploaded from the real-world environment where it works, built on the architecture 99% of the users have. The breakage in the other architectures' autobuilt packages is not noticed until after Sarge, and/or when somebody does an NMU (or takes over the package) and suffers from severe brain trauma trying to figure out how the h*ll it could have worked _ever_. If a broken package is not noticed in unstable, the package must not be particularly important to anyone. I disagree. 1. A package may not be important to developers, but is still important to users. Alternatively, developers may simply recompile the package without submitting a bug report. A variation on the theme, all the developers who use package X only do so on platform Y, so it doesn't get tested on other platforms. 2. The package may be broken in that it is inconsistant, but still work fine, or work fine for most features. -- Brian May [EMAIL PROTECTED]
Re: Source only uploads?
On Tue, Oct 21, 2003 at 09:52:14AM +1000, Brian May wrote: On Mon, Oct 20, 2003 at 02:17:40PM -0400, Matt Zimmerman wrote: If a broken package is not noticed in unstable, the package must not be particularly important to anyone. I disagree. 1. A package may not be important to developers, but is still important to users. Alternatively, developers may simply recompile the package without submitting a bug report. A variation on the theme, all the developers who use package X only do so on platform Y, so it doesn't get tested on other platforms. This premise assumes that only developers use unstable, and in my experience this is very far from the truth. 2. The package may be broken in that it is inconsistant, but still work fine, or work fine for most features. ...in which case we cannot hope to discover the bugs in it unless someone uses it. -- - mdz
Re: Source only uploads?
On Mon, Oct 20, 2003 at 02:07:33PM -0500, Gunnar Wolf wrote: I think a third (or, after reading some replies to this same mail, fourth, fifth or nth) way could be used: Binary packages enter Sid as usual. Now, after the 10-day period, when they are ready to enter Testing, they are autobuilt. Only the autobuilt version hits Testing. Aargh, no, this is a dreadful idea. Getting things into testing is slow enough as it is without having to wait 10 days just to find out whether an autobuild problem exists! We want to find this sort of thing out earlier, not later. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Source only uploads?
Matt Zimmerman writes: This premise assumes that only developers use unstable, and in my experience this is very far from the truth. It is true that some packages go into testing without having been tested on all platforms. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Source only uploads?
On Oct 21, Andrew Pollock ([EMAIL PROTECTED]) wrote: On Mon, Oct 20, 2003 at 06:08:27PM +0200, Sven Luther wrote: Sure, sure. Just give me one real world reason why it is not good to build in an artificial environment like you call it (either pbuilder or an autobuilder) and i will go away, as you say. Yes, please do. I've been following this thread with interest, because I have always found it inconsistent that usually $(DEBIAN_ARCHITECTURES) - 1 were built by the buildds, but the binary package the maintainer uploads was built in a completely heterogenous environment to the rest. I would have thought for the sake of consistency, it would be best if binary packages for all $(DEBIAN_ARCHITECTURES) were built the same way. For the same reason, I would have thought an unstable pbuilder chroot would provide a higher degree of consistency for the one binary package the maintainer uploads now, than to build the package in the significantly more random environment of the developer's development machine? (Unless he/she dedicates a machine to tracking unstable for no other purpose than to build packages). Building in a pbuilder chroot is what I do, for exactly the reason you stated. I do all my work on the package in my regular environment, then create the package for upload with pbuilder, then test the resulting package before uploading it. -- Neil Roeth
Re: Source only uploads?
Hi, Wouter Verhelst wrote:
Sven Luther:
Well, we just need an arch: all autobuilder and that's it, or one of the
autobuilders building the arch: all stuff.
Feel free to set up one.
I have my personal i386 autobuilder running that way for some months now.
It makes sense; I certainly have caught quite a few problems with it --
there's not just the missing-dependency problem that makes packages
non(re)buildable.
Sure, some uploaded packages will be unbuildable, which would generate
more work for the builders, but that problem is solveable. For example, we
could block a package from building when two other autobuilders have
reported a failure on it. That would have the added benefit to place
somewhat less load on already-overworked architectures like m68k.
My vote would be to Just Do It. I can certainly help set up and/or admin a
few autobuilders for i386, if that's what it takes.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Nasrudin called at a large house to collect for charity. The servant said
My master is out. Nasrudin replied, Tell your master that next time he
goes out, he should not leave his face at the window. Someone might steal it.
Re: Source only uploads?
On Sat, Oct 18, 2003 at 09:39:05PM +0100, Andrew Suffield wrote: On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote: Its good for the autobuilders to check again if a package builds in a mainly minimal environment. That's an argument for building it *once* in such an environment. It is definitely not an argument that it should only be built in such an environment, which was the point in question. Ok, no problem. I suppose you just volunteered to fix all the bugs against my packages that fail due to broken dependency brought in by using experimental packages. And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? Naturally, i build my packages in my own enviornment, but i try not to upload those, since i may miss build-dependencies, and some of the stuff running on my system may break the upload. I run upstream out of CVS X for example, and have the experimental X packages installed too. Friendly, Sven Luther
Re: Source only uploads?
On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: On Sat, Oct 18, 2003 at 09:39:05PM +0100, Andrew Suffield wrote: On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote: Its good for the autobuilders to check again if a package builds in a mainly minimal environment. That's an argument for building it *once* in such an environment. It is definitely not an argument that it should only be built in such an environment, which was the point in question. Ok, no problem. I suppose you just volunteered to fix all the bugs against my packages that fail due to broken dependency brought in by using experimental packages. You have a significant number of such bugs? That's like standing up in a crowded room and announcing you have a highly contagious skin disease. And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? What are you talking about? I'm not the one proposing anything. The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
Op zo 19-10-2003, om 15:25 schreef Matthias Urlichs: [...] For example, we could block a package from building when two other autobuilders have reported a failure on it. That would have the added benefit to place somewhat less load on already-overworked architectures like m68k. Please, no. Our autobuilder architecture is only half-automated for a reason. I won't trust any computer to *reliably* decide whether a build failed because of a transitional problem (unresolved build-depends, network problems, ...), because it shouldn't be built (architecture header in debian/control), because of architecture-specific problems (toolchain), or because there was a bug in the package. Your suggestion would only be The Right Thing in the last case... (no particular objection to the rest of your mail, though) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Source only uploads?
Wouter Verhelst writes: Our autobuilder architecture is only half-automated for a reason. I won't trust any computer to *reliably* decide whether a build failed because of a transitional problem (unresolved build-depends, network problems, ...), because it shouldn't be built (architecture header in debian/control), because of architecture-specific problems (toolchain), or because there was a bug in the package. Yes, but it seems to me that if a package fails on the first two (or maybe three) architectures that it might be a good idea to suspend further autobuilding until someone can look into the problem. It doesn't seem likely that many packages are going to fail on the first three architectures and then succeed on all the others. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Source only uploads?
Hi, John Hasler wrote:
Yes, but it seems to me that if a package fails on the first two (or maybe
three) architectures
Thanks for the first; that additional word improves the heuristic
significantly.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Decorate your home. It gives the illusion that your life is more
interesting than it really is.
-- C. Schulz
Re: Source only uploads?
On Sun, Oct 19, 2003 at 08:08:11PM +0100, Andrew Suffield wrote: And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? What are you talking about? I'm not the one proposing anything. The proposal was All packages should be built in an artificial environment of this form. I have pointed out that this is a braindamaged idea. Autobuilders already build packages in an artificial environment for every architecture except the one the maintainer used for uploading. Surely making every package consistant on every architecture should be a goal for Debian? Sure, ideally the package should build exactly the same way where ever it is built, but differences can emerge with out being obvious, for instance if a package detects an extra library is installed on the maintainers machine and automatically uses it without the maintainer being aware of what is happening (this happened with early versions of Heimdal and libhesiod0 in fact). -- Brian May [EMAIL PROTECTED]
Re: Source only uploads?
On Fri, Oct 17, 2003 at 04:30:03PM +0200, Sven Luther wrote: Sure, the ideal would be to rebuild everything in pbuilder Stop. Who has been perpetrating this myth? It's idiotic. The objective is not to create Debian packages that build in an artificial environment. The objective is to create Debian packages that build on any Debian host that is running the same release. The worst thing we could possibly do, short of never building the packages, is to build them all in an artificial environment. Since the buildds are by their nature artificial, it falls to the maintainer to build the package on a real-world system. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
Andrew Suffield [EMAIL PROTECTED] writes: On Fri, Oct 17, 2003 at 04:30:03PM +0200, Sven Luther wrote: Sure, the ideal would be to rebuild everything in pbuilder Stop. Who has been perpetrating this myth? It's idiotic. The objective is not to create Debian packages that build in an artificial environment. The objective is to create Debian packages that build on any Debian host that is running the same release. The worst thing we could possibly do, short of never building the packages, is to build them all in an artificial environment. Since the buildds are by their nature artificial, it falls to the maintainer to build the package on a real-world system. Uploads are different from building. Who said the maintainer should stop building packages or test what they do before uploading? They deserve to be shot. Its good for the autobuilders to check again if a package builds in a mainly minimal environment. Esspecially since binary-all packages are never crosschecked with binary uploads. MfG Goswin
Re: Source only uploads?
On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote: Its good for the autobuilders to check again if a package builds in a mainly minimal environment. That's an argument for building it *once* in such an environment. It is definitely not an argument that it should only be built in such an environment, which was the point in question. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Source only uploads?
On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote: On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote: Hi, a few days ago, I uploaded an emacs mode package (all) source only w/o problems to ftp-master. Today, a source only upload was rejected. Why? I think, we should get rid of binary uploads... Cheers! Please search the list archives for the reasons why source uploads are not allowed. This has been hashed out before. Highlights: - it encourages carelessness - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. The reason why source only uploads (or binary uploads where the binary part is ignored) are good, is that they limit the errors that may be introduced by the DD build environment, which may be a bit more than just sid. Like when you have XFree86 4.3.0 experimental packages installed for example. And if we are going to use experimental more and more, like aj suggested, this is going to be more and more of a problem in the future. Friendly, Sven Luther
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote: On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote: On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote: Hi, a few days ago, I uploaded an emacs mode package (all) source only w/o problems to ftp-master. Today, a source only upload was rejected. Why? I think, we should get rid of binary uploads... Cheers! Please search the list archives for the reasons why source uploads are not allowed. This has been hashed out before. Highlights: - it encourages carelessness - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. The reason why source only uploads (or binary uploads where the binary part is ignored) are good, is that they limit the errors that may be introduced by the DD build environment, which may be a bit more than just sid. Like when you have XFree86 4.3.0 experimental packages installed for example. The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. By requiring at least one binary package, we ensure the package can at least be built. That's a good thing, since it saves time otherwise wasted on packages failing to build because the maintainer didn't even bother to test. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). And if we are going to use experimental more and more, like aj suggested, this is going to be more and more of a problem in the future. Since experimental isn't autobuilt, I fail to see your point. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. I feel like I am missing something here. Could you explain Architecture: all packages would not get built? Is the problem with binary arch independent packages? The reason why source only uploads (or binary uploads where the binary part is ignored) are good, is that they limit the errors that may be introduced by the DD build environment, which may be a bit more than just sid. Like when you have XFree86 4.3.0 experimental packages installed for example. The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. By requiring at least one binary package, we ensure the package can at least be built. That's a good thing, since it saves time otherwise wasted on packages failing to build because the maintainer didn't even bother to test. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). binary uploads where the binary part is ignored sounds very good. I don't expect problems related to time-consuming since most binary uploads are for x86 these days and x86 autobuilder cpu time should not be very hard to find. And if we are going to use experimental more and more, like aj suggested, this is going to be more and more of a problem in the future. Since experimental isn't autobuilt, I fail to see your point. It believe he means that dd are more likely to have experimental packages installed on their systems and thus upload broken binary packages. Christophe -- Christophe Barbé [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E In theory there is no difference between theory and practice. In practice there is. -- Yogi Berra
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote: On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote: On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote: Hi, a few days ago, I uploaded an emacs mode package (all) source only w/o problems to ftp-master. Today, a source only upload was rejected. Why? I think, we should get rid of binary uploads... Cheers! Please search the list archives for the reasons why source uploads are not allowed. This has been hashed out before. Highlights: - it encourages carelessness - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. Yeah, sure, not problem, and i will set it up behind my ADSL link, right ? The reason why source only uploads (or binary uploads where the binary part is ignored) are good, is that they limit the errors that may be introduced by the DD build environment, which may be a bit more than just sid. Like when you have XFree86 4.3.0 experimental packages installed for example. The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. By requiring at least one binary package, we ensure the package can at least be built. That's a good thing, since it saves time otherwise wasted on packages failing to build because the maintainer didn't even bother to test. Sure, but there where also people who did it after having built their packages, to be sure the packages where built in a clean sid environment. Also, there may be people who do source only uploads because of bandwith concerns. I know i did when i was using a pay per minutes 56K modem line, and had to upload multi-megabyte binary packages. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). Well, most people upload x86 anyway, and to a lesser extent powerpc. I doubt any of these arches have problem rebuilding those packages. It is not like everyone was uploading m68k or arm. And if we are going to use experimental more and more, like aj suggested, this is going to be more and more of a problem in the future. Since experimental isn't autobuilt, I fail to see your point. Well, try to install the quark 3.21-1 package on your system for example then, and you will see what i mean. I have XFree86 4.3.0 installed on my system, and i guess many other DD have it or other experimental stuff installed, or self installed stuff, or some older version of a library, or who knows what else. When i uploaded quark 3.21-1, do you know what happened ? It brang with it a xlibs ( 4.3.0) dependency, which naturally was not fullfillable in sid or sarge. The packages was fine for all other architectures where it was autobuilt. And there may be thousand of other ways why you shouldn't thrust the build environment of the individual developers, not even taking in acount malicious uploads, and these may be problems that don't appear in the source of the packages. Friendly, Sven Luther
Re: Source only uploads?
On Fri, Oct 17, 2003 at 09:24:25AM -0400, christophe barbe wrote: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: [somebody deleted some attributions here, so I no longer know who said what] - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. I feel like I am missing something here. Could you explain Architecture: all packages would not get built? Is the problem with binary arch independent packages? Autobuilders use dpkg-buildpackage -B which does not build Architecture: all. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). binary uploads where the binary part is ignored sounds very good. I don't expect problems related to time-consuming since most binary uploads are for x86 these days and x86 autobuilder cpu time should not be very hard to find. Competent human operator time is more valuable and in shorter supply. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Source only uploads?
On Fri, Oct 17, 2003 at 03:12:14PM +0200, Sven Luther wrote: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: Since experimental isn't autobuilt, I fail to see your point. Well, try to install the quark 3.21-1 package on your system for example then, and you will see what i mean. I have XFree86 4.3.0 installed on my system, and i guess many other DD have it or other experimental stuff installed, or self installed stuff, or some older version of a library, or who knows what else. When i uploaded quark 3.21-1, do you know what happened ? It brang with it a xlibs ( 4.3.0) dependency, which naturally was not fullfillable in sid or sarge. The packages was fine for all other architectures where it was autobuilt. I have to say that you really should have noticed this. Before I sign and upload a package, I always use debc to read the control fields and debdiff to compare it with the previous version to make sure the changes are what I expected them to be. debdiff will show you changes in control fields in wdiff format, so changes in dependency versions are quite obvious. Frankly, I expect this or the equivalent to be the bare minimum any developer should do. I know that people make mistakes, but noticing problems like this is just part of due care and attention to testing, and if people are failing to notice this kind of thing then I don't think that not being required to build their packages at all will improve their testing procedures. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Source only uploads?
On Fri, Oct 17, 2003 at 09:24:25AM -0400, christophe barbe wrote: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. I feel like I am missing something here. Could you explain Architecture: all packages would not get built? Is the problem with binary arch independent packages? No, when you upload a multi-binary package, and you have some which are binary : all, and others that are binary: any. The autobuilders will only build the arch-dependent stuff, and nobody build the arch: all packages. Usually when you upload, you upload both your arch's arch-dependent and the arch-independent packages. The reason why source only uploads (or binary uploads where the binary part is ignored) are good, is that they limit the errors that may be introduced by the DD build environment, which may be a bit more than just sid. Like when you have XFree86 4.3.0 experimental packages installed for example. The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. By requiring at least one binary package, we ensure the package can at least be built. That's a good thing, since it saves time otherwise wasted on packages failing to build because the maintainer didn't even bother to test. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). binary uploads where the binary part is ignored sounds very good. I don't expect problems related to time-consuming since most binary uploads are for x86 these days and x86 autobuilder cpu time should not be very hard to find. x86 or powerpc. Maybe i will be able to provide a 1GHz G4 autobuilder in a few weeks or so, not sure though. It would probably need hosting though. And if we are going to use experimental more and more, like aj suggested, this is going to be more and more of a problem in the future. Since experimental isn't autobuilt, I fail to see your point. It believe he means that dd are more likely to have experimental packages installed on their systems and thus upload broken binary packages. Yep, that is what i meant. Friendly, Sven Luther
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:48:00PM +0100, Colin Watson wrote: On Fri, Oct 17, 2003 at 03:12:14PM +0200, Sven Luther wrote: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: Since experimental isn't autobuilt, I fail to see your point. Well, try to install the quark 3.21-1 package on your system for example then, and you will see what i mean. I have XFree86 4.3.0 installed on my system, and i guess many other DD have it or other experimental stuff installed, or self installed stuff, or some older version of a library, or who knows what else. When i uploaded quark 3.21-1, do you know what happened ? It brang with it a xlibs ( 4.3.0) dependency, which naturally was not fullfillable in sid or sarge. The packages was fine for all other architectures where it was autobuilt. I have to say that you really should have noticed this. Before I sign and upload a package, I always use debc to read the control fields and debdiff to compare it with the previous version to make sure the changes are what I expected them to be. debdiff will show you changes in control fields in wdiff format, so changes in dependency versions are quite obvious. Frankly, I expect this or the equivalent to be the bare minimum any developer should do. Well, sure, but why not automate these kind of things in order to let less place to human mistakes ? And the XFree86 dependencies are strange, i did an upgrade from xfree86 4.3.0-0pre1v1 to 4.3.0-0pre1v3, and then this started to happen, while for other packages it didn't. I think it is higly time that 4.3.0 from upstream reaches unstable finally. But again, this is only one of the things that can go wrong, what if i have an incompatible version of some library, or other selfbuilt stuff ? Sure, the ideal would be to rebuild everything in pbuilder, which is what i try to do with xfree86 dependent packages now, but still, it is placing the burden of it on all the individual developers, while a centralized way to solve this problem would be easy to achieve, and cost almost nothing in time. I had this discussion with some of the ftp-master or debian-admin folk some time in the past, don't remember exactly with whom or at which occasion, and they agreed with me that this would be good idea to implement. The build tools just mark something in the changes file to mark that the package has been built, but dupload does not upload the binaries, even if it check that they are present. Then one of the autobuilders is modified to build its arch and arch:all packages, and voila, we have reached one more level of security and quality of our package, by eliminating the human error factor. Also we diminish the bandwith requirement of the developers, which is maybe not such a bad thing. Sure, you will tell me that some may then fake the build on their arches, or something such, but then the autobuilder will notice. There could even be a two level autobuild process. Where one extra machine will build the package for both arch: all and its arch, and then, if it is sucessfull, all other packages build it or something. Additionnaly, you have the added benefit of having a full build log of all the packages in the archive, which is worth it. Friendly, Sven Luther
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:35:17PM +0100, Colin Watson wrote: On Fri, Oct 17, 2003 at 09:24:25AM -0400, christophe barbe wrote: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: [somebody deleted some attributions here, so I no longer know who said what] - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. I feel like I am missing something here. Could you explain Architecture: all packages would not get built? Is the problem with binary arch independent packages? Autobuilders use dpkg-buildpackage -B which does not build Architecture: all. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). binary uploads where the binary part is ignored sounds very good. I don't expect problems related to time-consuming since most binary uploads are for x86 these days and x86 autobuilder cpu time should not be very hard to find. Competent human operator time is more valuable and in shorter supply. You drop the -B option of one of the autobuilders, and the problem is solved, the operator will not have an added burden, since the autobuilders log are available to the package maintainer, and he is responsible for seing the package built anyway. Friendly, Sven Luther
Re: Source only uploads?
Op vr 17-10-2003, om 15:12 schreef Sven Luther: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote: On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote: Please search the list archives for the reasons why source uploads are not allowed. This has been hashed out before. Highlights: - it encourages carelessness - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. Yeah, sure, not problem, and i will set it up behind my ADSL link, right ? Why not? That's what I do with my buildd[1]. [...] The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. By requiring at least one binary package, we ensure the package can at least be built. That's a good thing, since it saves time otherwise wasted on packages failing to build because the maintainer didn't even bother to test. Sure, but there where also people who did it after having built their packages, to be sure the packages where built in a clean sid environment. Also, there may be people who do source only uploads because of bandwith concerns. I know i did when i was using a pay per minutes 56K modem line, and had to upload multi-megabyte binary packages. No excuse. Upload the source to one of the debian machines, and use screen(1). I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). Well, most people upload x86 anyway, and to a lesser extent powerpc. I doubt any of these arches have problem rebuilding those packages. It is not like everyone was uploading m68k or arm. Are you considering the fact that our current buildd infrastructure might not cope with the extra amount of packages that would need to be built? A buildd which has to do almost nothing, such as the i386 one, may not be prepared to handle the full load of building the archive; in fact, the i386 buildd is gluck[2], which has more to do than just autobuilding. Suddenly requesting that gluck be able to handle autobuilding a full architecture might not be a good idea. As said, if you can assure that it does not become so a problem in any way, I don't have a problem with this, but I'll need more than doubts and assumptions. [1] 'quickstep'. OK, I admit, it's an m68k one. [2] last I heard, at least. It might've changed. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Source only uploads?
On Fri, Oct 17, 2003 at 05:27:15PM +0200, Wouter Verhelst wrote: Op vr 17-10-2003, om 15:12 schreef Sven Luther: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote: On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote: Please search the list archives for the reasons why source uploads are not allowed. This has been hashed out before. Highlights: - it encourages carelessness - Architecture: all packages would not get built Well, we just need an arch: all autobuilder and that's it, or one of the autobuilders building the arch: all stuff. Feel free to set up one. Yeah, sure, not problem, and i will set it up behind my ADSL link, right ? Why not? That's what I do with my buildd[1]. And you rebuild every package on it ? I don't know, most debian machines are on 100Mb/s links, and the smallest one are 1.5Mb/s links. I only have 512/128 Ko/s, not very much. And beside, i switch off my box for the night, since it is noisy and power hungry. The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. By requiring at least one binary package, we ensure the package can at least be built. That's a good thing, since it saves time otherwise wasted on packages failing to build because the maintainer didn't even bother to test. Sure, but there where also people who did it after having built their packages, to be sure the packages where built in a clean sid environment. Also, there may be people who do source only uploads because of bandwith concerns. I know i did when i was using a pay per minutes 56K modem line, and had to upload multi-megabyte binary packages. No excuse. Upload the source to one of the debian machines, and use screen(1). Sure, sure. I have less problems with the second part of your suggestion (binary uploads where the binary part is ignored), as long as it's not so time-consuming that becomes a problem (which I'm afraid is likely to be the case). Well, most people upload x86 anyway, and to a lesser extent powerpc. I doubt any of these arches have problem rebuilding those packages. It is not like everyone was uploading m68k or arm. Are you considering the fact that our current buildd infrastructure might not cope with the extra amount of packages that would need to be built? A buildd which has to do almost nothing, such as the i386 one, may not be prepared to handle the full load of building the archive; in fact, the i386 buildd is gluck[2], which has more to do than just autobuilding. Suddenly requesting that gluck be able to handle autobuilding a full architecture might not be a good idea. Sure, but it could be fixed easily by adding a new machine if nothing else. If there is a will to implement this, then solution can be found. As said, if you can assure that it does not become so a problem in any way, I don't have a problem with this, but I'll need more than doubts and assumptions. [1] 'quickstep'. OK, I admit, it's an m68k one. :)) [2] last I heard, at least. It might've changed. Or it might in the future. Friendly, Sven Luther
Re: Source only uploads?
On Fri, Oct 17, 2003 at 05:27:15PM +0200, Wouter Verhelst wrote: Op vr 17-10-2003, om 15:12 schreef Sven Luther: On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote: Are you considering the fact that our current buildd infrastructure might not cope with the extra amount of packages that would need to be built? A buildd which has to do almost nothing, such as the i386 one, may not be prepared to handle the full load of building the archive; in fact, the i386 buildd is gluck[2], which has more to do than just autobuilding. Suddenly requesting that gluck be able to handle autobuilding a full architecture might not be a good idea. This is really a null argument with all the high powered PCs running around recompiling Gentoo every day I think we can find one to rebuild Debain too. I'm sure I could get approval to use my work stations as buildds if needed, but I have a sneaking suspicious somebody else has something better than a single proc Athlon XP 2000+ they want to use to keep their house/office warm. PCs are a dime a dozen, and broadband is widely available, I don't see away to out grow the building potential we have other than ignoring it. Out of curiosity, does anybody have any numbers on how much churn there is in x86? - Nick Lopez [EMAIL PROTECTED] -- Randomly selected signature -- I saw a VW Beatle the other day. The vanity Plates said FEATURE
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote: The reason why source only uploads are bad, is that they encourage bad practice such as people not checking the build. More precisely, they fail to discourage it. There is not actually any positive reinforcement for uploading an unbuildable package. -- G. Branden Robinson|No executive devotes much effort to Debian GNU/Linux |proving himself wrong. [EMAIL PROTECTED] |-- Laurence J. Peter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Source only uploads?
On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote: Hi, a few days ago, I uploaded an emacs mode package (all) source only w/o problems to ftp-master. Today, a source only upload was rejected. Why? I think, we should get rid of binary uploads... Cheers! Please search the list archives for the reasons why source uploads are not allowed. This has been hashed out before. Highlights: - it encourages carelessness - Architecture: all packages would not get built -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Source-only uploads
On Mon, 31 Dec 2001, Jonathan Hseu wrote: Last I asked on #debian-devel, source-only uploads aren't allowed (as in, you can't just upload the orig.tar and the diff. With auto-builders in place, is there any reason why? They are allowed. See pine. There are reasons why source-only uploads should be preferred, some being: I consisder these reasons they should not be allowed. - The package can be compiled on boxes that are up-to-date with bugfixes in gcc and other Build-Depends. I personally don't upgrade my sid box that often (I currently have to upgrade 843 new packages, install 33 new ones, remove 17 for a dist-upgrade, understand why? :) So, the maintainer doesn't know if his package works with the current set of software in debian? This seems like a loss. - Wouldn't the binaries be more trusted if they came from auto-builders anyways? So that way a maintainer can't just stick something in there that's not in the source code. I would rather have the original upload be a binary one. I trust this more, as the maintainer has more likely installed what he has just built, and tested it out. No such assurance happens with a source only upload. Binary uploads should be allowed for packages that don't have source code at all or ones that depend on themselves for bootstrapping. For packages that don't have source this is the only way, so your argument means absolutely nothing.
Re: Source-only uploads
On Mon, Dec 31, 2001 at 03:26:10AM -0600, Adam Heath wrote: On Mon, 31 Dec 2001, Jonathan Hseu wrote: - Wouldn't the binaries be more trusted if they came from auto-builders anyways? So that way a maintainer can't just stick something in there that's not in the source code. I would rather have the original upload be a binary one. I trust this more, as the maintainer has more likely installed what he has just built, and tested it out. No such assurance happens with a source only upload. Conversely, I would sometimes like to be able to get my arch-specific and arch-independant packages built by the build daemons in order to detect build time errors that don't show up on my own system (missing build deps, for example). -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpmctHxZzvLz.pgp Description: PGP signature
Re: Source-only uploads
On Mon, Dec 31, 2001 at 09:59:04AM +, Mark Brown wrote: Conversely, I would sometimes like to be able to get my arch-specific and arch-independant packages built by the build daemons in order to detect build time errors that don't show up on my own system (missing build deps, for example). a clean chroot will solve that one for you. besides, the buildd's may still have an un-listed build dependency, from a previous build. -john
Re: Source-only uploads
On Mon, Dec 31, 2001 at 02:05:05AM -0800, John H. Robinson, IV wrote: a clean chroot will solve that one for you. besides, the buildd's may still have an un-listed build dependency, from a previous build. It would still be nice to have the external check. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgp47dC0ozcqT.pgp Description: PGP signature
Re: Source-only uploads
At (time_t)1009793105 John H. Robinson, IV wrote: On Mon, Dec 31, 2001 at 09:59:04AM +, Mark Brown wrote: Conversely, I would sometimes like to be able to get my arch-specific and arch-independant packages built by the build daemons in order to detect build time errors that don't show up on my own system (missing build deps, for example). a clean chroot will solve that one for you. besides, the buildd's may still have an un-listed build dependency, from a previous build. Missing build-deps that do not cause the build process to break are a common problem on non-i386 architectures. The packages may be crippled in some way by the missing build dependency, and the maintainer and other users from the same architecture never notice, because the original binary upload was created with all necessary build dependencies installed. Source-only uploads would not automatically catch this problem, but if a package is missing certain key components on i386, the problem tends to be detected more quickly. Consistent use of chroots would also help address this. -- John Daily [EMAIL PROTECTED]
Re: Source-only uploads
In Mon, 31 Dec 2001 09:59:04 + Mark cum veritate scripsit : Conversely, I would sometimes like to be able to get my arch-specific and arch-independant packages built by the build daemons in order to detect build time errors that don't show up on my own system (missing build deps, for example). Try pbuilder sometime. It's too much of a hack, but it kinda works. As to source-only uploads, I think it's dangerous. Are we trying to force users to use binary packages that even the maintainer of the package has not tried to install/run ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: Source-only uploads
On Mon, Dec 31, 2001 at 08:19:24PM +0900, Junichi Uekawa wrote: Are we trying to force users to use binary packages that even the maintainer of the package has not tried to install/run ? We do all the time. I expect the majority of the packages on the machine I'm typing this on have not been installed or run by the maintainer - but I guess that's what I get for using PowerPC. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpzoSaGc3TUL.pgp Description: PGP signature
Re: Source-only uploads
On Mon, Dec 31, 2001 at 02:34:56PM +, Mark Brown wrote: On Mon, Dec 31, 2001 at 08:19:24PM +0900, Junichi Uekawa wrote: Are we trying to force users to use binary packages that even the maintainer of the package has not tried to install/run ? We do all the time. I expect the majority of the packages on the machine I'm typing this on have not been installed or run by the maintainer - but I guess that's what I get for using PowerPC. At least the architecture-independent parts, like the postinst scripts, should have been run by somebody, which is a useful check. -- Colin Watson [EMAIL PROTECTED]
