Re: alpine_1.0+dfsg-2_source.changes REJECTED
Dear Mentors, I'm a Debian Maintainer now and am uploading a new release of my package alpine, for which I successfully uploaded 1.0+dfsg-1 to the archive. I noticed that according to http://buildd.debian.org/build.php?pkg=alpine , the Debian archive never builds i386 packages. To my surprise, it accepts the binary .debs I upload with the source package. That sort of creeps me out - I'd much rather exercise a buildd and make sure that a pristine package gets into the archive. So I thought I would upload a dsc containing only source. (That dsc is available at http://mentors.debian.net/debian/pool/main/a/alpine/alpine_1.0+dfsg-2.dsc .) However, I got this message back: On Sat, 12 Jan 2008, Debian Installer wrote: Rejected: source only uploads are not supported. Dear Debian-Mentors, Is it possible to ask the buildds to rebuild my package on all architectures as part of an upload? Thanks! -- Asheesh. -- The herd instinct among economists makes sheep look like independent thinkers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Asheesh Laroia wrote: I'm a Debian Maintainer now and am uploading a new release of my package alpine, for which I successfully uploaded 1.0+dfsg-1 to the archive. Indeed, check[1]. 1. http://packages.qa.debian.org/a/alpine/news/20080105T014704Z.html I noticed that according to http://buildd.debian.org/build.php?pkg=alpine , the Debian archive never builds i386 packages. To my surprise, it accepts the binary .debs I upload with the source package. It accepts any binary package you upload together with the source package. If you upload from amd64, it then won't build an amd64 package, but use the one you uploaded instead. Rejected: source only uploads are not supported. That's exactly the point: at the moment, source-only uploads are REJECTED. You have to provide at least the binaries for one architecture. Is it possible to ask the buildds to rebuild my package on all architectures as part of an upload? No. If you want to *rebuild* a package using the very same source already in the archive, you can read about binNMUs. But that only happens for good reasons (e.g. transitions). That's not a workaround so that source-only uploads can happen. -- Cyril Brulebois pgpxmwUAMfK76.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
Please use list-reply. No need to Cc people if they didn't request it, see the Debian lists policy. On 12/01/2008, Asheesh Laroia wrote: Interesting. Is there a reason for this policy, or is it just historical? ISTR it was intended to ensure the package at least builds fine in the developer's environment, to reduce FTBFSes. I wasn't there at that time though, but I've been told several times that I'll be an old DD before it gets a chance to be changed. I guess you can call it historical. Got it, now I understand the way things work. I still have the above question about why they work that way. Check for “source only uploads” in the list archives, and maybe in the DWN. First shot gives [1,2]. 1. http://lists.debian.org/debian-devel/2003/10/msg01226.html 2. http://lists.debian.org/debian-devel/2003/10/msg01227.html -- Cyril Brulebois pgpUswW5Yoe2R.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On Sat, 12 Jan 2008, Cyril Brulebois wrote: Rejected: source only uploads are not supported. That's exactly the point: at the moment, source-only uploads are REJECTED. You have to provide at least the binaries for one architecture. Interesting. Is there a reason for this policy, or is it just historical? Is it possible to ask the buildds to rebuild my package on all architectures as part of an upload? No. If you want to *rebuild* a package using the very same source already in the archive, you can read about binNMUs. But that only happens for good reasons (e.g. transitions). That's not a workaround so that source-only uploads can happen. Got it, now I understand the way things work. I still have the above question about why they work that way. Thanks for the quick reply! -- Asheesh. -- Don't abandon hope: your Tom Mix decoder ring arrives tomorrow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
Asheesh Laroia wrote: I'm a Debian Maintainer now Congratulations. That sort of creeps me out - I'd much rather exercise a buildd and make sure that a pristine package gets into the archive. It's a bit of a historical thing, left over from the days when everybody used i386 boxes. There is only one i386 buildd (which was down recently). The idea is that since you should be test building your package in a clean sid chroot anyway you might as well upload the results (after signing it of course) to save time on Debian resources. regards, Colin -- Colin Tuckley | +44(0)1903 236872 | PGP/GnuPG Key Id Debian Developer | +44(0)7799 143369 | 0x1B3045CE Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Colin Tuckley wrote: It's a bit of a historical thing, left over from the days when everybody used i386 boxes. There is only one i386 buildd (which was down recently). The idea is that since you should be test building your package in a clean sid chroot anyway you might as well upload the results (after signing it of course) to save time on Debian resources. But nothing ensures it is built in a chroot, which might occasion disparities between uploaded binaries and built-on-the-buildd-network binaries. And no log is available for that build. Not to mention the disparities between (build-)dependencies' versions in case the package stays in NEW for some time. I find it a shame to rely on everyone to upload binaries to save time on Debian resources, rather than having a comprehensive and reliable buildd network. About the above: it's not like i386 is a rare architecture and it isn't possible to find some machines that could act as build daemons. Remember Vancouver? Cheers, -- Cyril Brulebois pgpLkzjSjU08F.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On Sat, Jan 12, 2008 at 11:51:14AM +0100, Cyril Brulebois wrote: ISTR it was intended to ensure the package at least builds fine in the developer's environment, to reduce FTBFSes. I wasn't there at that time though, but I've been told several times that I'll be an old DD before it gets a chance to be changed. I guess you can call it historical. The most precise reference to this issue it comes to my mind is: http://lists.debian.org/debian-devel/2007/01/msg00760.html In that mail it is well explained (or at least, it is explained in a way I agree with) why we should require *also* binary packages to be uploaded. However, it is not well motivated IMO why we shouldn't, for example, upload them and throw them away afterwards (see footnote [4], with which I personally disagree). The point of not having resources I'm quite sure can be mitigated. Feel free to revamp the discussion. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
* Asheesh Laroia [EMAIL PROTECTED] [080112 11:41]: That's exactly the point: at the moment, source-only uploads are REJECTED. You have to provide at least the binaries for one architecture. Interesting. Is there a reason for this policy, or is it just historical? Sorry if this sounds rude: But how have you tested this package when you did not have a binary package built in a suiteable environment available? And if you have this package, why did you not include it? Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
* Cyril Brulebois [EMAIL PROTECTED] [080112 12:13]: But nothing ensures it is built in a chroot, which might occasion disparities between uploaded binaries and built-on-the-buildd-network binaries. Binaries do not need a chroot, just a clean unstable environment. While a minimal chroot is good to test against missing build-dependencies, a full real-world system is needed to test for missing build-conflicts or configure switches to disable specific autodetections. So when you get disparities between a package build in a pure unstable environment and on a buildd or a minimal chroot, that is not a bug in the process but a bug in the package, which would not be catched when only using buildds. And no log is available for that build. Not to mention the disparities between (build-)dependencies' versions in case the package stays in NEW for some time. disparities can also happen with differently fast buildds or just by the differences of the different architectures. Things should be able to work with this. I find it a shame to rely on everyone to upload binaries to save time on Debian resources, rather than having a comprehensive and reliable buildd network. Please, don't argue against things by claiming stupid reasons and then arguing how stupid those reasons are. And for source only uploads please take a look at Ubuntu. I really hope we do not want to go that path and up with totally unuseable packages (in the sense of can't possibly ever do the single thing that package is there for) ending up in stable releases. About the above: it's not like i386 is a rare architecture and it isn't possible to find some machines that could act as build daemons. There is a i386 buildd. Quite some people are uploading amd64 packages. I personally usually only upload sparc binaries with my sources. Sometimes the i386 buildd makes problems, sometimes another buildd. Nothing specific with i386 here. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Bernhard R. Link wrote: While a minimal chroot is good to test against missing build-dependencies, a full real-world system is needed to test for missing build-conflicts or configure switches to disable specific autodetections. Sure. So when you get disparities between a package build in a pure unstable environment and on a buildd or a minimal chroot, that is not a bug in the process but a bug in the package, which would not be catched when only using buildds. Well, no. A “pure unstable environment” on a development box can have various configuration tweaks, differing from the defaults shipped with the packages, and that can impact the built binaries. disparities between (build-)dependencies' versions in case the package stays in NEW for some time. disparities can also happen with differently fast buildds or just by the differences of the different architectures. Things should be able to work with this. Maybe trying to limit these disparities might be interesting… and then arguing how stupid those reasons are. And for source only uploads please take a look at Ubuntu. I really hope we do not want to go that path and up with totally unuseable packages (in the sense of can't possibly ever do the single thing that package is there for) ending up in stable releases. I don't see how requesting to have a binary along the source package ensures it has been tested, that upgrades and transitions are OK, etc. About the above: it's not like i386 is a rare architecture and it isn't possible to find some machines that could act as build daemons. There is a i386 buildd. Quite some people are uploading amd64 packages. I personally usually only upload sparc binaries with my sources. Sometimes the i386 buildd makes problems, sometimes another buildd. Nothing specific with i386 here. Having a single point of failure is i386-specific as far as I can tell. Testing migration suffered from that. Are you saying that redundancy is totally useless and that one should just not care about it? -- Cyril Brulebois pgprjHEnD5CA3.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
* Cyril Brulebois [EMAIL PROTECTED] [080112 14:38]: Well, no. A ???pure unstable environment??? on a development box can have various configuration tweaks, differing from the defaults shipped with the packages, and that can impact the built binaries. Source packages are supposed to be also buildable by normal people which should not need to setup any buildd environment for that. Thus packages should work in any reasonable environment and give comparable results. And at least I consider pure changes of configuration, different programs choosen to supply a specific alternative and stuff like this as reasonable environment changes. Things like having versions of stuff installed not available in unstable or making changes to the system that would also make normal packages depending on that no longer functional are a other thing, though. But most systems go without such massive tweaks. and then arguing how stupid those reasons are. And for source only uploads please take a look at Ubuntu. I really hope we do not want to go that path and up with totally unuseable packages (in the sense of can't possibly ever do the single thing that package is there for) ending up in stable releases. I don't see how requesting to have a binary along the source package ensures it has been tested, that upgrades and transitions are OK, etc. Having a binary available means the blame can be more certainly assigned later. When there is a binary package and that is already misbuilt in a way it cannot work, it is clear who is to blame. No but here it worked, the official buildd must do something a little bit different is possible. Having a single point of failure is i386-specific as far as I can tell. Testing migration suffered from that. Are you saying that redundancy is totally useless and that one should just not care about it? Redundancy is good and important. But in the last time there was hardly a point where i386 was effected by lack of it. More machines alone would not have stopped a vacation of the one to sign to make some packages go a bit slower. And even that (as nice at is was to shortly see some other architectures being over i386 in the architectures keeping up graph for a day or two) was a very isolated event that other architectures can have quite often when some i386-assumptions in toolchain packages hit another architecture hard. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
Bernhard R. Link wrote: While a minimal chroot is good to test against missing build-dependencies, a full real-world system is needed to test for missing build-conflicts or configure switches to disable specific autodetections. But nothing in the current system ensures that packages are built in such an environment at all. A DD can easily build their package only in a clean chroot and upload that, missing all such testing. Source-only uploads + the build daemon from hell would be a more consistent approach that should catch more problems too. -- see shy jo signature.asc Description: Digital signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On Sat, 12 Jan 2008, Stefano Zacchiroli wrote: On Sat, Jan 12, 2008 at 11:51:14AM +0100, Cyril Brulebois wrote: ISTR it was intended to ensure the package at least builds fine in the developer's environment, to reduce FTBFSes. I wasn't there at that time though, but I've been told several times that I'll be an old DD before it gets a chance to be changed. I guess you can call it historical. The most precise reference to this issue it comes to my mind is: http://lists.debian.org/debian-devel/2007/01/msg00760.html In that mail it is well explained (or at least, it is explained in a way I agree with) why we should require *also* binary packages to be uploaded. However, it is not well motivated IMO why we shouldn't, for example, upload them and throw them away afterwards (see footnote [4], with which I personally disagree). The point of not having resources I'm quite sure can be mitigated. Stefano, Thanks - I have read the whole http://lists.debian.org/debian-devel/2007/01/msg00760.html thread now, as well as have skimmed the debian-mentors thread another posted here. I agree whole-heartedly with your position, which has been described by others here on debian-mentors and on debian-devel. I think Require binaries and throw them away is a very good strategy. It seems there is fairly wide consensus that having the buildds build every package is a good thing. Have you considered making a General Resolution on the topic to create a policy that allows the buildds to build every package? I realize that the arch: all packages would need technical attention before the policy can be realized in practice, and there may be other small technical issues to work out, but I imagine there are solutions to those issues. -- Asheesh. -- It is not a good omen when goldfish commit suicide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Asheesh Laroia wrote: I realize that the arch: all packages would need technical attention before the policy can be realized in practice, and there may be other small technical issues to work out, but I imagine there are solutions to those issues. I guess some packages might be exceptions to such a rule, like compilers or other packages needing bootstrap at some point. Cheers, -- Cyril Brulebois pgpzU2yrXnby0.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On Sat, 12 Jan 2008, Cyril Brulebois wrote: On 12/01/2008, Asheesh Laroia wrote: I realize that the arch: all packages would need technical attention before the policy can be realized in practice, and there may be other small technical issues to work out, but I imagine there are solutions to those issues. I guess some packages might be exceptions to such a rule, like compilers or other packages needing bootstrap at some point. That's a good point - the simplest fair rule I can think of would be to make it opt-in by developers who *want* the buildds to rebuild their packages, and mark the package in a way that says Please throw away my binary packages. -- Asheesh. -- Pause for storage relocation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Il giorno Mon, 07 Jan 2008 05:52:03 +0100 Michael Biebl [EMAIL PROTECTED] ha scritto: Could you please make the yelp dependency a Recommends? May I ask why? I believe yelp is better suited as a Depends (AFAIK, to read gnome-doc documentation, you need yelp) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
Asheesh Laroia skrev: others here on debian-mentors and on debian-devel. I think Require binaries and throw them away is a very good strategy. It seems there is fairly wide consensus that having the buildds build every package is a good thing. Man, source-only uploads would literally save me hours when uploading my packages... They're big (50-100MB) and my uplink bandwidth isn't so hot where I am right now... why not take things like that into consideration when considering this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
On 13/01/2008, David Paleino wrote: Could you please make the yelp dependency a Recommends? May I ask why? So that it gets pulled in by default. But so that one can still choose not to install yelp at all, e.g. because one isn't interested at all by documentation (e.g. because online helps will be sufficient, if ever needed). Cheers, -- Cyril Brulebois pgplbIdro2s7S.pgp Description: PGP signature
