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]
Fwd: python-numpy has problems on buildbots
On Dec 5, 2007 1:03 PM, José Fonseca [EMAIL PROTECTED] wrote: 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 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. Ondrej
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]
python-numpy has problems on buildbots
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: [...] Setting up xfonts-utils (1:1.0.1-2) ... Setting up xterm (229-1) ... Setting up xutils (1:7.3+7) ... Checking correctness of source dependencies... After installing, the following source dependencies are still unsatisfied: atlas3-base(still installed) atlas3-base-dev(still installed) Source-dependencies not satisfied; skipping python-numpy /usr/bin/sudo dpkg --root=/home/buildd/build/chroot-unstable --purge libx11-data fontconfig-config libio-compress-base-perl gettext file libxaw7 ttf-dejavu python-all-dbg libfftw3-dev python2.5-minimal libxxf86dga1 libio-stringy-perl debconf-utils x11-common libfontenc1 libcompress-raw-zlib-perl libxi6 gcc-3.4 python2.4-dev libfribidi0 libfontconfig1 libidn11 patchutils libobject-realize-later-perl x11-utils gcc-3.4-base x11-xserver-utils libx11-6 libkrb53 libnewt0.52 atlas3-headers libxdamage1 libxt6 blt x11-session-utils xutils libssh2-1 python-all libice6 intltool-debian lapack3-dev libxrender1 libttf2 xfonts-utils ttf-dejavu-extra libxtst6 libxft2 libxext6 libxtrap6 atlas3-base libsqlite3-0 python2.5-dev libfile-remove-perl libxinerama1 tcl8.4 libncursesw5 libxmu6 python-docutils xfonts-encodings defoma libtimedate-perl libdigest-sha1-perl ttf-dejavu-core python2.5 libdrm2 liburi-perl curl libxpm4 autotools-dev refblas3 libmailtools-perl libxmuu1 python2.4-dbg cpp-3.4 p ython2.5-dbg libpopt0 libmail-sendmail-perl libfreetype6 libssl0.9.8 x11-xfs-utils libmime-types-perl libgl1-mesa-glx libcompress-zlib-perl libcurl3 tk8.4 libxv1 html2text xbitmaps debhelper libxrandr2 libkeyutils1 libuser-identity-perl xutils-dev libdmx1 python python-roman atlas3-base-dev libmagic1 libexpat1 libio-compress-zlib-perl libxau6 libdigest-hmac-perl g77-3.4 libfftw3-3 mime-support whiptail libxdmcp6 libxfixes3 libgpmg1 libg2c0 po-debconf g77 refblas3-dev libxfont1 python-all-dev python-dbg libxxf86vm1 python-dev lapack3 libft-perl python-minimal python2.4 cdbs ucf xterm libg2c0-dev libfs6 gettext-base libxxf86misc1 libsm6 python-central python2.4-minimal libmail-box-perl (Reading database ... 15444 files and directories currently installed.) Removing python-all-dbg ... Removing libfftw3-dev ... Removing debconf-utils ... [...] 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) 2. Why are there the exceptions to m68k and arm? 3. If the build-conflict is needed, how can we fix the package so that it builds on buildbots? CCing to Lucas, because he has some experience with these kinds of problems. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
