Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx k...@roeckx.be wrote: On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote: If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? So that in case various packages have to be build in an order, where the seconds depends on the first being available and so on, that it doesn't take weeks to get them all build. We would have to wait at least a dinstall before the next one could be build, assuming sometimes has the time to sign the package between dinstalls. It basicly just avoids a whole lot of delays. Unfortunately, it seems also to add quite some delays in the self-compiling case. :-/ Each time a buildd finishes, that buildd's Packages file gets updated due to the completed binary upload and all other buildds go back into the BD-Uninstallable state. (I assume this also means the package loses its place in line on the busy buildd queues) I wonder if the same rules applied to the unstable package list (don't include the all for a package whose any is not done) could be applied also to the buildd's Packages?
Re: new buildd dependency resolution breaks self depends?
On Wed, Mar 30, 2011 at 06:45:50PM +0200, Wesley W. Terpstra wrote: On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx k...@roeckx.be wrote: On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote: If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? So that in case various packages have to be build in an order, where the seconds depends on the first being available and so on, that it doesn't take weeks to get them all build. We would have to wait at least a dinstall before the next one could be build, assuming sometimes has the time to sign the package between dinstalls. It basicly just avoids a whole lot of delays. Unfortunately, it seems also to add quite some delays in the self-compiling case. :-/ Each time a buildd finishes, that buildd's Packages file gets updated due to the completed binary upload and all other buildds go back into the BD-Uninstallable state. (I assume this also means the package loses its place in line on the busy buildd queues) That actually doesn't seem to be that case. I think ftp-master just removed the old binary from unstable, and didn't give the buildd's the chance to actually build against the old version, and we're screwed now. I suggest you ask them to restore the old binaries in unstable, (and remove the arch all) packages for those arches it's not yet build/uploaded for. Kurt -- 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/20110330172213.ga32...@roeckx.be
Re: new buildd dependency resolution breaks self depends?
Kurt Roeckx k...@roeckx.be writes: On Wed, Mar 30, 2011 at 06:45:50PM +0200, Wesley W. Terpstra wrote: On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx k...@roeckx.be wrote: On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote: If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? So that in case various packages have to be build in an order, where the seconds depends on the first being available and so on, that it doesn't take weeks to get them all build. We would have to wait at least a dinstall before the next one could be build, assuming sometimes has the time to sign the package between dinstalls. It basicly just avoids a whole lot of delays. Unfortunately, it seems also to add quite some delays in the self-compiling case. :-/ Each time a buildd finishes, that buildd's Packages file gets updated due to the completed binary upload and all other buildds go back into the BD-Uninstallable state. (I assume this also means the package loses its place in line on the busy buildd queues) That actually doesn't seem to be that case. I think ftp-master just removed the old binary from unstable, and didn't give the buildd's the chance to actually build against the old version, and we're screwed now. I suggest you ask them to restore the old binaries in unstable, (and remove the arch all) packages for those arches it's not yet build/uploaded for. Kurt It used to be that any _all.deb uploaded was added to all archs directly. Under that setup the build would never have succeeded. Having it suceed with a delay between upload and builds is an improvement already. MfG Goswin -- 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/87pqp8s6i4.fsf@frosties.localnet
new buildd dependency resolution breaks self depends?
I've read that there was a recent change made to the buildd resolution with regards to ensuring that consistent package versions are used on the builds [0]. Is it possible that this changed also messed up self-dependency resolution? My package, mlton, has a versioned dependency on itself for version = 20070826. As it is a compiler for SML written in SML, it needs a previous version of itself installed in order to compile the new version. Previously, this has presented no problems; the buildd installed the old version and compiled the new version. Now, the buildd demands that the same version be installed as is to be built [1]: *mlton/alpha dependency installability problem:* mlton (= 20100608-3) build-depends on one of: - mlton (= 20100608-3) ... this is, of course, impossible. The buildd must install the old version in order to build the new. I have a suspicion that an overzealous 'use the same version' rule in the dependency resolver might be the cause of this bug. Thanks for any help understanding why the buildd system will no longer attempt to build my package! [0] http://lists.debian.org/debian-policy/2011/03/msg00103.html [1] https://buildd.debian.org/status/package.php?p=mlton
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 17:25:14 +0200, Wesley W. Terpstra wrote: I've read that there was a recent change made to the buildd resolution with regards to ensuring that consistent package versions are used on the builds [0]. Is it possible that this changed also messed up self-dependency resolution? My package, mlton, has a versioned dependency on itself for version = 20070826. As it is a compiler for SML written in SML, it needs a previous version of itself installed in order to compile the new version. Previously, this has presented no problems; the buildd installed the old version and compiled the new version. Now, the buildd demands that the same version be installed as is to be built [1]: *mlton/alpha dependency installability problem:* mlton (= 20100608-3) build-depends on one of: - mlton (= 20100608-3) ... this is, of course, impossible. The buildd must install the old version in order to build the new. I have a suspicion that an overzealous 'use the same version' rule in the dependency resolver might be the cause of this bug. As far as I can tell the problem is that you switched the mlton binary package to 'Architecture: all'. Which means it's available on all architectures already in the new version, even though it's not installable. Cheers, Julien -- 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/20110329155223.gg3...@radis.liafa.jussieu.fr
Re: new buildd dependency resolution breaks self depends?
Hi, Am Dienstag, den 29.03.2011, 17:52 +0200 schrieb Julien Cristau: *mlton/alpha dependency installability problem:* mlton (= 20100608-3) build-depends on one of: - mlton (= 20100608-3) ... this is, of course, impossible. The buildd must install the old version in order to build the new. I have a suspicion that an overzealous 'use the same version' rule in the dependency resolver might be the cause of this bug. As far as I can tell the problem is that you switched the mlton binary package to 'Architecture: all'. Which means it's available on all architectures already in the new version, even though it's not installable. sounds similar to what just happend to me with ghc: http://lists.debian.org/debian-haskell/2011/03/msg00108.html In this case, with some help of the ftp team this could be resolved. But in your case, as it is not transitional, it looks harder. I guess you need to ensure that version n+1 can be built using the arch:any packages of version n and the arch:all packages of either version n or version n +1... or undo the package split. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 5:52 PM, Julien Cristau jcris...@debian.org wrote: As far as I can tell the problem is that you switched the mlton binary package to 'Architecture: all'. Which means it's available on all architectures already in the new version, even though it's not installable. Ahh! That makes a lot of sense, thanks. I'll need to figure out a way to work-around this.
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 05:52:23PM +0200, Julien Cristau wrote: As far as I can tell the problem is that you switched the mlton binary package to 'Architecture: all'. Which means it's available on all architectures already in the new version, even though it's not installable. If I understand the situation, this means the buildd's already see the new mlton arch all in the Packages file for the buildds. But you won't see in on the mirrors until the arch any package for that arch is available. And the arch all binary package has a strict version requirement binary any package. As long as the Packages file for the buildds mentions this arch all package, no buildd can build it, because it only considers installing the latest version. But it should get removed from that file after 24 or 32 hours or something. In which case we'll only see the old version, can install those, and things should work from there. So I think you either need to be patient, or have a less strict version requirement. Kurt -- 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/20110329164239.ga13...@roeckx.be
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx k...@roeckx.be wrote: As long as the Packages file for the buildds mentions this arch all package, no buildd can build it, because it only considers installing the latest version. But it should get removed from that file after 24 or 32 hours or something. In which case we'll only see the old version, can install those, and things should work from there. I hope what you're telling me is true, because it will save me a lot of work! :) What I don't understand about your explanation: once the new all+i386 .debs hit unstable, won't the buildds see the new 'all' package in unstable and thus want to install it in preference to the old 'any' package even after it is removed from the Packages file? The 'all' package will still be uninstallable since it depends on the missing 'any' packages. While I can fix the problem at hand by removing the mlton 'all' package for an upload, I see a more troublesome problem on the horizon: The basis, runtime, and compiler packages should all be at the same version to compile correctly. The basis package is an 'all' package which includes the cross-platform bits of the runtime library. The runtime and compiler are 'any' packages with compiled object code. If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current problem), any future uploads will see that it has these versions available: mlton-compiler (= old-version) depends on runtime mlton-runtime (= old-version) depends on basis mlton-basis (= new version) ... which I believe means that the old-version mlton-compiler package will be uninstallable since the old-version of the basis in unstable is hidden by the new-version. Have I understood this problem correctly?
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 06:58:36PM +0200, Wesley W. Terpstra wrote: I hope what you're telling me is true, because it will save me a lot of work! :) What I don't understand about your explanation: once the new all+i386 .debs hit unstable, won't the buildds see the new 'all' package in unstable and thus want to install it in preference to the old 'any' package even after it is removed from the Packages file? The 'all' package will still be uninstallable since it depends on the missing 'any' packages. While I can fix the problem at hand by removing the mlton 'all' package for an upload, I see a more troublesome problem on the horizon: The basis, runtime, and compiler packages should all be at the same version to compile correctly. The basis package is an 'all' package which includes the cross-platform bits of the runtime library. The runtime and compiler are 'any' packages with compiled object code. If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current problem), any future uploads will see that it has these versions available: mlton-compiler (= old-version) depends on runtime mlton-runtime (= old-version) depends on basis mlton-basis (= new version) ... which I believe means that the old-version mlton-compiler package will be uninstallable since the old-version of the basis in unstable is hidden by the new-version. Have I understood this problem correctly? Does mlton-basis depend on mlton-runtime or mlton-compiler to build? If the answer is yes, then most likely these should not be three seperate source packages. If no, then why doesn't it just work or is the problem a previous version causing a mess? I hate circular build dependancies. :) -- Len Sorensen -- 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/20110329171048.ga...@caffeine.csclub.uwaterloo.ca
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 06:58:36PM +0200, Wesley W. Terpstra wrote: On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx k...@roeckx.be wrote: As long as the Packages file for the buildds mentions this arch all package, no buildd can build it, because it only considers installing the latest version. But it should get removed from that file after 24 or 32 hours or something. In which case we'll only see the old version, can install those, and things should work from there. What I don't understand about your explanation: once the new all+i386 .debs hit unstable, won't the buildds see the new 'all' package in unstable and thus want to install it in preference to the old 'any' package even after it is removed from the Packages file? The 'all' package will still be uninstallable since it depends on the missing 'any' packages. Let's take a look at all current Packages files: - The buildd Packages file, as seen by *all* the buildds, not only the i386 one: kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/buildd-sid/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture Package: mlton-basis version: 20100608-3 Architecture: all Package: mlton-compiler version: 20100608-3 Architecture: i386 Package: mlton version: 20100608-3 Architecture: all Package: mlton-tools version: 20100608-3 Architecture: i386 Package: mlton-runtime-native version: 20100608-3 Architecture: i386 Package: mlton-runtime-i486-linux-gnu version: 20100608-3 Architecture: i386 Package: mlton-doc version: 20100608-3 Architecture: all The i386 unstable one: kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/archive/sid/main/binary-i386/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture Package: mlton-basis version: 20100608-3 Architecture: all Package: mlton-compiler version: 20100608-3 Architecture: i386 Package: mlton-doc version: 20100608-3 Architecture: all Package: mlton-runtime-i486-linux-gnu version: 20100608-3 Architecture: i386 [...] The amd64 one: kroeckx@grieg:~$ zcat /org/wanna-build/tmp/archive/debian/archive/sid/main/binary-amd64/Packages.gz | grep-dctrl -F Package mlton -s Package,version,Architecture Package: mlton version: 20100608-2 Architecture: amd64 Note that in unstable you don't see the arch arch all version until the arch any version is also available. Or you would see the old arch all version until the new arch any version is available. This means that the version from unstable should always be installable, unless there is some other reason it's not like a transition of some other library. The problem is that the buildds currently also see the newer arch all version. But this version will go away after some time and it will only see the version from unstable. The basis, runtime, and compiler packages should all be at the same version to compile correctly. The basis package is an 'all' package which includes the cross-platform bits of the runtime library. The runtime and compiler are 'any' packages with compiled object code. If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current problem), any future uploads will see that it has these versions available: mlton-compiler (= old-version) depends on runtime mlton-runtime (= old-version) depends on basis mlton-basis (= new version) ... which I believe means that the old-version mlton-compiler package will be uninstallable since the old-version of the basis in unstable is hidden by the new-version. The new version of mlton-basis will only be visible to the buildds for about a day, after which they should have no problem building it. Kurt -- 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/20110329172733.ga14...@roeckx.be
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote: The problem is that the buildds currently also see the newer arch all version. But this version will go away after some time and it will only see the version from unstable. If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? So that in case various packages have to be build in an order, where the seconds depends on the first being available and so on, that it doesn't take weeks to get them all build. We would have to wait at least a dinstall before the next one could be build, assuming sometimes has the time to sign the package between dinstalls. It basicly just avoids a whole lot of delays. Kurt -- 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/20110329180343.ga14...@roeckx.be
Re: new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 7:27 PM, Kurt Roeckx k...@roeckx.be wrote: Note that in unstable you don't see the arch arch all version until the arch any version is also available. Or you would see the old arch all version until the new arch any version is available. That's great! My thanks to whomever had the foresight to prevent this temporary dependency breakage for all-any dependencies. I guess this would otherwise have annoyed unstable users for packages that had yet to be built for their architecture..? This means that the version from unstable should always be installable, unless there is some other reason it's not like a transition of some other library. Yes, the libgmp3-dev - libgmp-dev transition already bit me this way. I assumed I was in for more of the same with the self dependency. The problem is that the buildds currently also see the newer arch all version. But this version will go away after some time and it will only see the version from unstable. If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? The new version of mlton-basis will only be visible to the buildds for about a day, after which they should have no problem building it. Thank god. :)
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 7:10 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: Does mlton-basis depend on mlton-runtime or mlton-compiler to build? If the answer is yes, then most likely these should not be three seperate source packages. It's all one source package. I split it up the binaries because: 1) about 60% of the package could be in an 'all' package. 2) the runtime components for different architectures can be installed side-by-side... thus enabling cross-compilation. If no, then why doesn't it just work or is the problem a previous version causing a mess? According to Kurt, there is no problem. It's all in my head. :)
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
On Tue, Mar 29, 2011 at 07:59:12PM +0200, Wesley W. Terpstra wrote: It's all one source package. I split it up the binaries because: 1) about 60% of the package could be in an 'all' package. 2) the runtime components for different architectures can be installed side-by-side... thus enabling cross-compilation. Oh OK, so there is no build dependancy issue at all then (since no one would be dumb enough to make a package that build depends on one of its own binaries, would they?). According to Kurt, there is no problem. It's all in my head. :) Oh good. -- Len Sorensen -- 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/20110329190808.gb...@caffeine.csclub.uwaterloo.ca
Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?
[Lennart Sorensen] Oh OK, so there is no build dependancy issue at all then (since no one would be dumb enough to make a package that build depends on one of its own binaries, would they?). You didn't read the beginning of the thread, I guess? This is a situation much like gcc, where the compiler is self-hosting. gcc avoids the (explicit) self-dependency by being in Build-Essential. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20110329222820.gg10...@p12n.org
