Re: python-numpy has problems on buildbots
So the problem still persists on amd64 as reported by Jose. Apparently the problem still persists on amd64: $ apt-cache show python-numpy Package: python-numpy Priority: optional Section: python Installed-Size: 6092 Maintainer: Debian Python Modules Team [EMAIL PROTECTED] Architecture: amd64 Version: 1:1.0.4-2 Provides: python-f2py, python-numpy-dev, python-numpy-ext, python2.4-numpy, python2.5-numpy Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | libatlas.so.3, libc6 (= 2.7-1), libg2c0 (= 1:3.4.4-5), libgcc1 (= 1:4.2.1), python ( 2.6), python (= 2.4), python-central (= 0.5.8) The atlas3-base | libatlas.so.3 dependency forces users to install atlas. Is not such a big deal, as users will want to install atlas anyway... On i386 it is: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, libc6 (= 2.7-1), libg2c0 (= 1:3.4.4-5), libgcc1 (= 1:4.2.1), python ( 2.6), python (= 2.4), python-central (= 0.5.8) so it's the refblas3, that is missing on amd64, right? Exactly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
I tried that - i.e. installed atlas3-base on my system, commented out build-conflicts, built python-numpy and got these dependencies: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, ... which is imho correct, right? We are going to upload now. So it indeed seems to work: http://buildd.debian.org/pkg.cgi?pkg=python-numpy numpy built on i386, alpha, amd64, mips, mipsel, powerpc and probably on all the others. The i386 is in incoming, so tomorrow expect working python-numpy on your system. And if it isn't working, file a bug. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
Hi, On 12/5/07, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, we with Kumar made a progress and had python-numpy uploaded (thanks Fabio). It builds nicely in pbuilder, but fails to build on buildbots. See: http://buildd.debian.org/pkg.cgi?pkg=python-numpy Fabio uploaded it on amd64, so that one is fine. Crucial are the following lines from debian/control: Build-Depends: cdbs (= 0.4.43), python-all-dev, python-all-dbg, python-central (= 0.5.6), refblas3-dev [!arm !m68k], lapack3-dev [!arm !m68k], debhelper (= 5.0.38), g77, patchutils, python-docutils, fftw3-dev Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k], atlas2-base, atlas2-base-dev, atlas3-base, atlas3-base-dev As you can see, arm and m68k are exceptions and indeed python-numpy builds on them just fine (see the link above). (It's still building on m68k, but last revision built there fine). It doesn't build on other architectures. If we look for example why it failed on the most important architecture i386: [...] So as you can see, the problem is that buildbots install atlas3-base for some reason and because we build-conflict with it, we fail. Three questions: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) So instead of getting the desired: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, ... dpkg-shlibdeps would produce: Depends: atlas2-base Or Depends: atlas3-base 2. Why are there the exceptions to m68k and arm? Because m68k and arm don't have atlas. 3. If the build-conflict is needed, how can we fix the package so that it builds on buildbots? I don't know. Perhaps the solution is to fix the packages listed Build-Conflicts so that when dpkg-shlibdeps traverses them, it produces the right dependency list. Or find someway to override dpkg-shlibdeps behavior so that it produces the right dependency list. I think I used another debian package as reference for this. You might want to see how other debian packages that link against lapack+blas / atlas are doing nowadays. CCing to Lucas, because he has some experience with these kinds of problems. Thanks, Ondrej Cheers, José
Re: python-numpy has problems on buildbots
Build-Depends: cdbs (= 0.4.43), python-all-dev, python-all-dbg, python-central (= 0.5.6), refblas3-dev [!arm !m68k], lapack3-dev [!arm !m68k], debhelper (= 5.0.38), g77, patchutils, python-docutils, fftw3-dev lapack3-dev and refblas3-dev should exist on all architectures now. Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k], atlas2-base, atlas2-base-dev, atlas3-base, atlas3-base-dev 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. 2. Why are there the exceptions to m68k and arm? Because m68k and arm don't have atlas. but they have lapack/blas now, which should be enough. 3. If the build-conflict is needed, how can we fix the package so that it builds on buildbots? try it without the Build-Conflicts. I guess it works. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k], atlas2-base, atlas2-base-dev, atlas3-base, atlas3-base-dev 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. But this would still present problems for the developer who has those packges installed and then wonders why his numpy binaries are broken, no? (Or do we not care about those developers silly enough to build on their full system?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
On 05/12/07 at 13:37 +0100, Bernd Zeimetz wrote: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. if you look into a random log you'll see that the build chroot is cleaned up after a build. There're only packages left if something really goes wrong. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
Ondrej Certik writes: On Dec 5, 2007 8:10 PM, Lucas Nussbaum [EMAIL PROTECTED] wrote: On 05/12/07 at 13:37 +0100, Bernd Zeimetz wrote: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. So would do you suggest? Just to wait until python-numpy gets build on buildbots? Or do you suggest to take some action (which)? :) help getting refblas3, lapack3 and atlas getting built with gfortran, fix the shlibs lines in these packages and then rebuild the python-numpy package. If you're interested, please join the debian-toolchain list or have a look at the archives. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
On Dec 5, 2007 8:10 PM, Lucas Nussbaum [EMAIL PROTECTED] wrote: On 05/12/07 at 13:37 +0100, Bernd Zeimetz wrote: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. So would do you suggest? Just to wait until python-numpy gets build on buildbots? Or do you suggest to take some action (which)? :) Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
On Wed, Dec 05, 2007 at 10:07:15PM +0100, Bernd Zeimetz wrote: There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. if you look into a random log you'll see that the build chroot is cleaned up after a build. There're only packages left if something really goes wrong. His statement is nevertheless correct, there is *no* guarantee that packages will be built in pristine environments, and if this causes a problem for your package then your package is missing either a build-dependency or a build-conflict (or is buggy in some other way). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. if you look into a random log you'll see that the build chroot is cleaned up after a build. There're only packages left if something really goes wrong. His statement is nevertheless correct, there is *no* guarantee that packages will be built in pristine environments, and if this causes a problem for your package then your package is missing either a build-dependency or a build-conflict (or is buggy in some other way). The package seems to have a correct build-conflict, so it refuses to built, if it knows it would fail anyway. But I didn't understood - are the buildbots going to ever remove the build-conflicting package? or not? How was it that numpy was ever built on buildbots? One option of course is to help with the atlas transition. But does that mean that python-numpy will be broken until this gets resolved? This is not acceptable for me. So we need to find some solution, that allows us to build python-numpy, python-scipy et. al. on buildbots now. I'll try things that Jose and Bernd suggested and we'll see. There must be a way to build and fix it now, instead of tomorrow. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
José Fonseca [EMAIL PROTECTED] writes: Or find someway to override dpkg-shlibdeps behavior so that it produces the right dependency list. Supplying a suitable shlibs.local should achieve this. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
