Re: RFR: src:lapack's 64bit-indexing variant
Hi Sébastien, On 2019-09-30 11:59, Sébastien Villemot wrote: > > I have uploaded 3.8.0-5 to experimental, that fixes this issue and > several other ones. The package now builds everywhere, and passes both > piuparts and autopkgtests. saw that. > Lumin: Do you have other pending changes? Or should we go ahead and > upload to unstable? no. I think we can go ahead. > The main remaining issue is CBLAS64. Let's just postpone the CBLAS64 support from src:lapack https://github.com/Reference-LAPACK/lapack/issues/184 and move on to openblas64.
Re: RFR: src:lapack's 64bit-indexing variant
Le mercredi 25 septembre 2019 à 19:25 +0200, Sébastien Villemot a écrit : > Le samedi 21 septembre 2019 à 11:00 +0200, Graham Inggs a écrit : > > On Sat, 21 Sep 2019 at 07:07, Mo Zhou wrote: > > > mips64el, s390x, ppc64, sparc64, they are not > > > typical architectures used for intensive > > > scientific computing. > > > > Besides the slow mips64el, the other architectures are all big-endian, > > 64-bit. > > I note the build was successful on powerpc (big-endian, 32-bit) so my > > guess is somewhere a 64-bit variable is accessed as a 32-bit variable, > > which happens to work on little-endian, but not on big-endian. > > Thanks Graham for your insight. You were perfectly right. > > It turns out that the functions under the INSTALL/ directory are > currently not recompiled with -fdefault-integer-8. > > I realized this because, in the test logs for s390x, the LAPACK version > number displayed by the test program is incorrect for the 64-bit > variant. This is because INSTALL/ilaver.f returns the 3 components of > the version as integers. Since the file is not recompiled for 64-bit, > it returns them as 32-bit integers, which works on little-endian archs, > but breaks for big-endian ones. > > I am working on a patch and will hopefully do an upload soon. I hope > this will be enough to fix the testsuite on all arches. I have uploaded 3.8.0-5 to experimental, that fixes this issue and several other ones. The package now builds everywhere, and passes both piuparts and autopkgtests. Lumin: Do you have other pending changes? Or should we go ahead and upload to unstable? The main remaining issue is CBLAS64. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFR: src:lapack's 64bit-indexing variant
Le samedi 21 septembre 2019 à 11:00 +0200, Graham Inggs a écrit : > Hi Mo > > On Sat, 21 Sep 2019 at 07:07, Mo Zhou wrote: > > mips64el, s390x, ppc64, sparc64, they are not > > typical architectures used for intensive > > scientific computing. > > Besides the slow mips64el, the other architectures are all big-endian, 64-bit. > I note the build was successful on powerpc (big-endian, 32-bit) so my > guess is somewhere a 64-bit variable is accessed as a 32-bit variable, > which happens to work on little-endian, but not on big-endian. Thanks Graham for your insight. You were perfectly right. It turns out that the functions under the INSTALL/ directory are currently not recompiled with -fdefault-integer-8. I realized this because, in the test logs for s390x, the LAPACK version number displayed by the test program is incorrect for the 64-bit variant. This is because INSTALL/ilaver.f returns the 3 components of the version as integers. Since the file is not recompiled for 64-bit, it returns them as 32-bit integers, which works on little-endian archs, but breaks for big-endian ones. I am working on a patch and will hopefully do an upload soon. I hope this will be enough to fix the testsuite on all arches. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFR: src:lapack's 64bit-indexing variant
Hi Mo On Sat, 21 Sep 2019 at 07:07, Mo Zhou wrote: > mips64el, s390x, ppc64, sparc64, they are not > typical architectures used for intensive > scientific computing. Besides the slow mips64el, the other architectures are all big-endian, 64-bit. I note the build was successful on powerpc (big-endian, 32-bit) so my guess is somewhere a 64-bit variable is accessed as a 32-bit variable, which happens to work on little-endian, but not on big-endian. e.g. a loop counter that is initialized as 64-bit, but decremented as 32-bit. Regards Graham
Re: RFR: src:lapack's 64bit-indexing variant
That workaround didn't work. I patched the makefile to make the tests verbose in order to avoid timeout during tests. However timeout still happened: https://buildd.debian.org/status/package.php?p=lapack=experimental That means the 4 weird architectures got stuck at a strange line due to some reason. Should we disable the BLAS64/LAPACK64 builds for the 4 architectures and head towards openblas64? mips64el, s390x, ppc64, sparc64, they are not typical architectures used for intensive scientific computing. On 2019-09-04 02:21, Mo Zhou wrote: > Finally the 3.8.0-3 build result on all architectures > are available: > https://buildd.debian.org/status/package.php?p=lapack=experimental > It passed on all architectures except 4 (mips64el, ppc64, sparc64, > s390x) > that weirdly timeout during the tests. > > Yunqiang Su (@syq) has helped me rebuild the package on > mips64el. And we found that it's just mips64el runs the test > too slow. > > The most straightforward way to mitigate the timeout issue > is to have test programs print something to stdout. However > I'm curious how the 4 architecture take half a day to finish > the tests that the others only take a few seconds. > > On 2019-08-20 17:40, Sébastien Villemot wrote: >> Le mardi 20 août 2019 à 19:29 +0200, Gilles Filippini a écrit : >>> Mo Zhou a écrit le 20/08/2019 à 18:21 : >>> > On 2019-08-20 16:15, Sébastien Villemot wrote: >>> > > I realize that I don’t know what we should put in the Architecture >>> > > field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there >>> > > is no 64-bit wildcard. >>> > > >>> > > One option is to painfully list all the existing 64-bit architectures >>> > > (including ports), but this is not very maintainable over the long-run. >>> > > Is there a better option? I guess we’re not the first ones to face this >>> > > problem. >>> > >>> > dpkg-architecture has a flag: >>> > >>> >DEB_HOST_ARCH_BITS=64 (on amd64) >>> > >>> > that can be used in d/rules. >>> > >>> > For d/control I cannot think of anything other than manually listing. >>> >>> You can keep 'Architecture: any' in d/control, and set DH_OPTIONS in >>> d/rules to filter out the binary package with '-N'. >> >> Thanks for this tip! It is much better than manually listing the >> architectures.
Re: RFR: src:lapack's 64bit-indexing variant
Finally the 3.8.0-3 build result on all architectures are available: https://buildd.debian.org/status/package.php?p=lapack=experimental It passed on all architectures except 4 (mips64el, ppc64, sparc64, s390x) that weirdly timeout during the tests. Yunqiang Su (@syq) has helped me rebuild the package on mips64el. And we found that it's just mips64el runs the test too slow. The most straightforward way to mitigate the timeout issue is to have test programs print something to stdout. However I'm curious how the 4 architecture take half a day to finish the tests that the others only take a few seconds. On 2019-08-20 17:40, Sébastien Villemot wrote: > Le mardi 20 août 2019 à 19:29 +0200, Gilles Filippini a écrit : >> Mo Zhou a écrit le 20/08/2019 à 18:21 : >> > On 2019-08-20 16:15, Sébastien Villemot wrote: >> > > I realize that I don’t know what we should put in the Architecture >> > > field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there >> > > is no 64-bit wildcard. >> > > >> > > One option is to painfully list all the existing 64-bit architectures >> > > (including ports), but this is not very maintainable over the long-run. >> > > Is there a better option? I guess we’re not the first ones to face this >> > > problem. >> > >> > dpkg-architecture has a flag: >> > >> >DEB_HOST_ARCH_BITS=64 (on amd64) >> > >> > that can be used in d/rules. >> > >> > For d/control I cannot think of anything other than manually listing. >> >> You can keep 'Architecture: any' in d/control, and set DH_OPTIONS in >> d/rules to filter out the binary package with '-N'. > > Thanks for this tip! It is much better than manually listing the > architectures.
Re: RFR: src:lapack's 64bit-indexing variant
Sébastien Villemot writes:
> One option is to painfully list all the existing 64-bit architectures
> (including ports), but this is not very maintainable over the long-run.
> Is there a better option? I guess we’re not the first ones to face this
> problem.
At the end, this would also be a problem for those who *use* the
lapack64 variant: One f.e. can't just do a
Build-Depends: lapack64-dev | lapack-dev
since then on a 64-bit architecture, lapack-dev would also be used when
lapack64-dev is not available (f.e. due to a failed build).
I am wondering why there is no empty "arch-64-bit" package that one
could build-depend on (similarly "arch-32-bit", "arch-bigendian",
"arch-littleendian") -- or a single empty package that provides these
depending on the architecture. In principle, this one could also provide
directly the architecture ("arch-x86-64"), allowing to restrict the
build of an arch:all package to a specific architecture (not sure buildd
could handle this).
Wouldn't that be an elegant way to handle architecture type dependent
build deps?
Best regards
Ole
Re: RFR: src:lapack's 64bit-indexing variant
Le mardi 20 août 2019 à 19:29 +0200, Gilles Filippini a écrit : > Mo Zhou a écrit le 20/08/2019 à 18:21 : > > On 2019-08-20 16:15, Sébastien Villemot wrote: > > > I realize that I don’t know what we should put in the Architecture > > > field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there > > > is no 64-bit wildcard. > > > > > > One option is to painfully list all the existing 64-bit architectures > > > (including ports), but this is not very maintainable over the long-run. > > > Is there a better option? I guess we’re not the first ones to face this > > > problem. > > > > dpkg-architecture has a flag: > > > >DEB_HOST_ARCH_BITS=64 (on amd64) > > > > that can be used in d/rules. > > > > For d/control I cannot think of anything other than manually listing. > > You can keep 'Architecture: any' in d/control, and set DH_OPTIONS in > d/rules to filter out the binary package with '-N'. Thanks for this tip! It is much better than manually listing the architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFR: src:lapack's 64bit-indexing variant
Hi, Mo Zhou a écrit le 20/08/2019 à 18:21 : > On 2019-08-20 16:15, Sébastien Villemot wrote: >> Le mardi 20 août 2019 à 18:11 +0200, Sébastien Villemot a écrit : >>> Le mardi 20 août 2019 à 09:00 -0700, Mo Zhou a écrit : Got it. But keep in mind that we haven't adapted the rules/control for 32-bit architectures -- they don't support BLAS64/LAPACK64. I'll add some guards in rules later and test it in an i386 env. >>> >>> Oh, I had overlooked that. >> >> I realize that I don’t know what we should put in the Architecture >> field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there >> is no 64-bit wildcard. >> >> One option is to painfully list all the existing 64-bit architectures >> (including ports), but this is not very maintainable over the long-run. >> Is there a better option? I guess we’re not the first ones to face this >> problem. > > dpkg-architecture has a flag: > >DEB_HOST_ARCH_BITS=64 (on amd64) > > that can be used in d/rules. > > For d/control I cannot think of anything other than manually listing. You can keep 'Architecture: any' in d/control, and set DH_OPTIONS in d/rules to filter out the binary package with '-N'. See for example d/rules from the navit source package[1]. [1] https://sources.debian.org/src/navit/0.5.3+dfsg.1-2/debian/rules/#L89 _g. signature.asc Description: OpenPGP digital signature
Re: RFR: src:lapack's 64bit-indexing variant
On 2019-08-20 16:15, Sébastien Villemot wrote: > Le mardi 20 août 2019 à 18:11 +0200, Sébastien Villemot a écrit : >> Le mardi 20 août 2019 à 09:00 -0700, Mo Zhou a écrit : >> > Got it. But keep in mind that we haven't adapted the rules/control >> > for 32-bit architectures -- they don't support BLAS64/LAPACK64. >> > I'll add some guards in rules later and test it in an i386 env. >> >> Oh, I had overlooked that. > > I realize that I don’t know what we should put in the Architecture > field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there > is no 64-bit wildcard. > > One option is to painfully list all the existing 64-bit architectures > (including ports), but this is not very maintainable over the long-run. > Is there a better option? I guess we’re not the first ones to face this > problem. dpkg-architecture has a flag: DEB_HOST_ARCH_BITS=64 (on amd64) that can be used in d/rules. For d/control I cannot think of anything other than manually listing.
Re: RFR: src:lapack's 64bit-indexing variant
Le mardi 20 août 2019 à 18:11 +0200, Sébastien Villemot a écrit : > Le mardi 20 août 2019 à 09:00 -0700, Mo Zhou a écrit : > > Got it. But keep in mind that we haven't adapted the rules/control > > for 32-bit architectures -- they don't support BLAS64/LAPACK64. > > I'll add some guards in rules later and test it in an i386 env. > > Oh, I had overlooked that. I realize that I don’t know what we should put in the Architecture field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there is no 64-bit wildcard. One option is to painfully list all the existing 64-bit architectures (including ports), but this is not very maintainable over the long-run. Is there a better option? I guess we’re not the first ones to face this problem. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFR: src:lapack's 64bit-indexing variant
Le mardi 20 août 2019 à 09:00 -0700, Mo Zhou a écrit : > On 2019-08-20 15:26, Sébastien Villemot wrote: > > The only change that I’d like you to do now is to add DEP-3 headers > > to > > makefile-blas-remove-dep.patch. > > The intention of that patch is to remove a makefile dependency to > avoid unwanted recompilation that would fail due to our special > manual builds... Ok. Please just document it in the header. > > Otherwise things look good, and you can proceed with the upload (to > > experimental, since we have to go through NEW, and because of the > > new > > source-only uploads policy). > > Got it. But keep in mind that we haven't adapted the rules/control > for 32-bit architectures -- they don't support BLAS64/LAPACK64. > I'll add some guards in rules later and test it in an i386 env. Oh, I had overlooked that. > My plan: > > 1. upload src:lapack for BLAS64/LAPACK64 (we omit CBLAS64 > temporarily) > > 2. upload src:openblas for the indexing variants and threading >variants (libopenblas64.so needs liblapack64-pic.a to build) >and we have to add an extra libjulia-openblas package, >providing a special build for the julia package > >libjulia-openblas will ship libopenblas64_.so >(soname=libopenblas64_.so), with all BLAS/LAPACK symbols >mangled (suffixing "64_") > > 3. Add bin:libjulia-suitesparse to src:suitesparse > >libjulia-suitesparse will be built with the '-DSUN64' (IIRC) >compiler flag, against libjulia-openblas. > > 4. remove src:julia's vendored suitesparse source and openblas >source. > > 5. patch CBLAS for the 64-bit indexing support >(then we can announce that all the BLAS64/LAPACK64 libraries > are switchable.) > > All related source packages are maintained by you. > Does these plans look good to you? Sounds good, please go ahead. You should not need my input anymore for step 1 (but I’m ready to help if needed). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFR: src:lapack's 64bit-indexing variant
Hi Sébastien, On 2019-08-20 15:26, Sébastien Villemot wrote: > I pushed a few further commits from myself to address some remaining > issues. The main one concerns the override to dh_makeshlibs that you > had removed, but which is really needed so that packages have the > correct DEBIAN/shlibs file generated. OK > The only change that I’d like you to do now is to add DEP-3 headers to > makefile-blas-remove-dep.patch. The intention of that patch is to remove a makefile dependency to avoid unwanted recompilation that would fail due to our special manual builds... > Otherwise things look good, and you can proceed with the upload (to > experimental, since we have to go through NEW, and because of the new > source-only uploads policy). Got it. But keep in mind that we haven't adapted the rules/control for 32-bit architectures -- they don't support BLAS64/LAPACK64. I'll add some guards in rules later and test it in an i386 env. >> 2. Upstream CBLAS code is not ready for the >>64bit-indexing feature. the upstream somehow postponed >>this feature[1]. As a result, I didn't deal with >>the CBLAS build and CBLAS development files. >>I can patch CBLAS, but let's do it when the >>64bit variant of OpenBLAS is available. >> >> 3. the test packages and autopkgtest updates are >>postponed by me. Let's finalize them in the >>next round of src:lapack update with the >>CBLAS64 patch. > > If I understand correctly, your intention is to fix these two remaining > issues in a subsequent upload? That's fine with me, as long as we don't > forget them. I've added the autopkgtest for the BLAS64/LAPACK64 libraries, and my local sbuild+autopkgtest tests are clean. So (3.) has been resolved. I mean the CBLAS code is not ready for the 64-bit indexing feature until I (or somebody else) patched it. Let's postpone the patching work and first get OpenBLAS's 64bit variant uploaded. My plan: 1. upload src:lapack for BLAS64/LAPACK64 (we omit CBLAS64 temporarily) 2. upload src:openblas for the indexing variants and threading variants (libopenblas64.so needs liblapack64-pic.a to build) and we have to add an extra libjulia-openblas package, providing a special build for the julia package libjulia-openblas will ship libopenblas64_.so (soname=libopenblas64_.so), with all BLAS/LAPACK symbols mangled (suffixing "64_") 3. Add bin:libjulia-suitesparse to src:suitesparse libjulia-suitesparse will be built with the '-DSUN64' (IIRC) compiler flag, against libjulia-openblas. 4. remove src:julia's vendored suitesparse source and openblas source. 5. patch CBLAS for the 64-bit indexing support (then we can announce that all the BLAS64/LAPACK64 libraries are switchable.) All related source packages are maintained by you. Does these plans look good to you?
Re: RFR: src:lapack's 64bit-indexing variant
Dear Mo Zhou, Le samedi 27 juillet 2019 à 19:55 -0700, Mo Zhou a écrit : > My 64bit-indexing updates for src:lapack are ready for > review. Please have a look at my git commits on the > "lumin" branch: > > > g...@salsa.debian.org > :science-team/lapack.git -b lumin Thanks for your work. I have merged your changes (squashing them into a single commit). I pushed a few further commits from myself to address some remaining issues. The main one concerns the override to dh_makeshlibs that you had removed, but which is really needed so that packages have the correct DEBIAN/shlibs file generated. The only change that I’d like you to do now is to add DEP-3 headers to makefile-blas-remove-dep.patch. Otherwise things look good, and you can proceed with the upload (to experimental, since we have to go through NEW, and because of the new source-only uploads policy). > 2. Upstream CBLAS code is not ready for the >64bit-indexing feature. the upstream somehow postponed >this feature[1]. As a result, I didn't deal with >the CBLAS build and CBLAS development files. >I can patch CBLAS, but let's do it when the >64bit variant of OpenBLAS is available. > > 3. the test packages and autopkgtest updates are >postponed by me. Let's finalize them in the >next round of src:lapack update with the >CBLAS64 patch. If I understand correctly, your intention is to fix these two remaining issues in a subsequent upload? That's fine with me, as long as we don't forget them. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
RFR: src:lapack's 64bit-indexing variant
Hi science team, My 64bit-indexing updates for src:lapack are ready for review. Please have a look at my git commits on the "lumin" branch: g...@salsa.debian.org:science-team/lapack.git -b lumin Several points to note: 1. I merged the content of liblapack-pic into liblapack-dev. 2. Upstream CBLAS code is not ready for the 64bit-indexing feature. the upstream somehow postponed this feature[1]. As a result, I didn't deal with the CBLAS build and CBLAS development files. I can patch CBLAS, but let's do it when the 64bit variant of OpenBLAS is available. 3. the test packages and autopkgtest updates are postponed by me. Let's finalize them in the next round of src:lapack update with the CBLAS64 patch. [1] https://github.com/Reference-LAPACK/lapack/issues/184
