Re: Action needed for R-pkg Uploaders
Le lundi 11 mars 2024 à 15:47 +0100, Andreas Tille a écrit : > 1. Verify the list of packages whether you want to keep on working > on this/these package(s) (and if you have different e-mail > addresses please stick to only one) > Sébastien Villemot : > r-cran-bdsmatrix > r-cran-dynlm > r-cran-isocodes > r-cran-mfilter > r-cran-nleqslv > r-cran-plm > r-cran-pwt > r-cran-pwt8 > r-cran-pwt9 > r-cran-rdbnomics > r-cran-rjson > r-cran-rsdmx > r-cran-statmod > r-cran-truncdist > r-cran-wdi As I don’t use R much these days, I’d rather have someone else take over those packages. However I’ll try to keep an eye on them as long as I am listed as Uploader. Best wishes, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: build-depends on atlas, which is obsolete and scheduled for removal
Control: tags -1 + patch Hi Andreas, Le mercredi 29 novembre 2023 à 11:53 +0100, Andreas Tille a écrit : > Control: tags -1 help > > [Ritika Ramani in CC to inform that Debian tries to get rid of Atlas > which also affects phast. see https://bugs.debian.org/1056681] > > Hi, > > I tried to replace clapack by LAPACKE. Unfortunately this is not a > drop-in replacement. As you can see in the raw(! normal log is to > long!) build log on Salsa[1] when seeking for the string > too few arguments to function > you see > > ... > phast_eigen.c: In function 'mat_diagonalize': > phast_eigen.c:62:3: error: too few arguments to function 'dgeev_' >62 | dgeev_(&jobvl, &jobvr, &n, tmp, &n, wr, wi, vl, > | ^~ > In file included from /usr/include/lapack.h:11, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/external_libs.h:43, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/vector.h:19, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/matrix.h:18, > from > /builds/med-team/phast/debian/output/source_dir/src/../include/phast/eigen.h:18, > from phast_eigen.c:18: > /usr/include/lapack.h:1828:6: note: declared here > 1828 | void LAPACK_dgeev_base( > | ^ > phast_eigen.c: In function 'mat_eigenvals': > phast_eigen.c:199:3: error: too few arguments to function 'dgeev_' > 199 | dgeev_(&jobvl, &jobvr, &n, tmp, &n, wr, wi, NULL, > | ^~ > ... Actually we had already completed the migration away from the old CLAPACK in clapack.patch. Only a minor cleanup was still needed to remove ATLAS. I opened a merge request that seems to do the job: https://salsa.debian.org/med-team/phast/-/merge_requests/1 Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Help for emmax needed (Was: Removing ATLAS?)
Control: tags -1 + patch
Hi Andreas,
Le mercredi 29 novembre 2023 à 10:06 +0100, Andreas Tille a écrit :
> Control: tags -1 help
>
> Am Fri, Jul 14, 2023 at 01:40:22AM +0200 schrieb Sébastien Villemot:
> > Le lundi 10 juillet 2023 à 22:01 +0200, Andreas Tille a écrit :
> > > I've checked my responsibility for the dependencies and stumbled about
> > > emmax
> > >
> > >
> > > emmax.c:10:10: fatal error: clapack.h: No such file or directory
> > >10 | #include
> > > | ^~~
> > > compilation terminated.
> > > ...
> >
> > clapack.h is apparently an early attempt at providing a C interface to
> > some LAPACK functions (which are in Fortran). It indeed looks ATLAS-
> > specific.
> >
> > The modern solution for that problem is to use LAPACKE (note the final
> > “E”), which is provided by liblapacke-dev. It is a standardized and
> > maintained C interface to all LAPACK routines.
> >
> > I guess it should be feasible to adapt emmax to make it work with
> > LAPACKE.
>
> I tried to do so in Salsa. Unfortunately LAPACKE is not a drop in
> replacement and I'm lacking the necessary knowledge about all these
> LAPACK implementations. For instance I have no idea how to fix the
> error you can see in Salsa CI[1] which has
>
> ...
> emmax.c: In function 'dsyevd':
> emmax.c:1633:17: error: conflicting types for 'dsyevd_'; have 'void(char *,
> char *, int *, double *, int *, double *, double *, int *, int *, int *, int
> *)'
> 1633 | extern void dsyevd_ (char *JOBZp, char *UPLOp, int *Np,
> | ^~~
> In file included from /usr/include/lapack.h:11,
> from emmax.c:10:
> /usr/include/lapack.h:17096:6: note: previous declaration of 'dsyevd_' with
> type 'void(const char *, const char *, const int32_t *, double *, const
> int32_t *, double *, double *, const int32_t *, int32_t *, const int32_t *,
> int32_t *, size_t, size_t)' {aka 'void(const char *, const char *, const int
> *, double *, const int *, double *, double *, const int *, int *, const int
> *, int *, long unsigned int, long unsigned int)'}
> 17096 | void LAPACK_dsyevd_base(
> | ^~
> emmax.c: In function 'dsyevr':
> emmax.c:1652:17: error: conflicting types for 'dsyevr_'; have 'void(char *,
> char *, char *, int *, double *, int *, double *, double *, int *, int *,
> double *, int *, double *, double *, int *, int *, double *, int *, int *,
> int *, int *)'
> 1652 | extern void dsyevr_ (char *JOBZp, char *RANGEp, char *UPLOp, int
> *Np,
> | ^~~
>
> Looking at the last line of this snippet (line 901 in the linked CI
> log[1]) the parameter char *RANGEp is not part of the declaration of
> LAPACK_dsyevd_base given in line 17096 of /usr/include/lapack.h.
>
> I admit this is hard to solve for me and I would love if someone
> with some knowledge of LAPACK could provide some patch. A similar
> issue exists for dgetrf.
>
> Any help would be appreciated.
I opened a merge request that completes the migration away from ATLAS:
https://salsa.debian.org/med-team/emmax/-/merge_requests/1
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Re: Removing ATLAS?
Le dimanche 05 novembre 2023 à 14:02 +0100, Sébastien Villemot a écrit : > Le samedi 08 juillet 2023 à 10:01 +0200, Sébastien Villemot a écrit : > > As the maintainer of the atlas package over the last decade, I now > > wonder whether we should remove it from the archive. > > Since the present thread seems to indicate that there to be a consensus > towards removing atlas from Debian, I am going to move forward. Thanks to those who gave me feedback. I went ahead and reported the bugs, here is the list: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=atlas-rm;users=debian-science@lists.debian.org Any help in fixing those is of course much welcome. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Removing ATLAS?
Hi, Le dimanche 05 novembre 2023 à 21:49 -0500, Mo Zhou a écrit : > The following line is what I use for the PyTorch package (ignore the > fact that I forgot to bump the BLIS abi from 3 to 4): > > Recommends: libopenblas0 | libblis3 | libatlas3-base | libmkl-rt | libblas3 > > So the latest Recommends line for performance critical packages relying > on BLAS/LAPACK should use: > > Recommends: libopenblas0 | libblis4 | libmkl-rt | libblas3 > > libmkl-rt is oudated (I knew it), but anyway usable. Quite a few months > ago I wrote the plan for overhauling the MKL package. Will carry it out > when I'm available for that. Indeed I think it is ok to add libmkl-rt here despite the fact that it is non-free, because it is not the default alternative (see Policy §2.2.1). I’m not really sure that I want to encourage that though. > libblas3 as the last fallback when none of the others are available. > This seems missing from the message draft. It is not necessary to mention libblas3 in Recommends because the Depends field normally already includes libblas.so.3 | libblas3. Hence libblas3 is already the last fallback. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Removing ATLAS?
Le samedi 08 juillet 2023 à 10:01 +0200, Sébastien Villemot a écrit : > As the maintainer of the atlas package over the last decade, I now > wonder whether we should remove it from the archive. Since the present thread seems to indicate that there to be a consensus towards removing atlas from Debian, I am going to move forward. Please find below a bug report template, which I plan to use for reporting bugs against the ~20 packages that currently have a (build- )dependency against atlas. Feedback is welcome. -- Subject: (build-)depends on atlas, which is obsolete and scheduled for removal Package: $PACKAGE / Source: $SOURCE Version: $VERSION Tags: sid trixie User: debian-science@lists.debian.org Usertags: atlas-rm Dear Maintainer, $SOURCE build-depends on libatlas-base-dev / $PACKAGE depends on libatlas3-base, which is produced by the source package atlas. atlas is obsolete and scheduled to be removed from Debian, ideally by the trixie release. See the following thread on the Debian Science list for more details: https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org As a consequence, please drop any (build-)dependency on atlas. This should normally be straightforward to achieve, by simply replacing atlas with another BLAS (and possibly also LAPACK) implementation. The typical setup is to build depend on the Netlib reference implementation (libblas-dev and possibly also liblapack-dev), and to not enforce anything in dependencies of binary packages. If an optimized BLAS/LAPACK implementation is needed at build time (for example for accelerating tests), then libopenblas-dev and libblis-dev offer good options (keeping in mind that openblas is only available on some architectures). If one wants to encourage users to install an optimized implementation, then one can use “Recommends: libopenblas0 | libblis4” in binary packages. Also note that if your package needs libcblas (which is currently only provided by libatlas-base-dev), then the solution is to modify the build system so that it rather uses libblas (because, under Debian, the latter already incorporates the symbols provided by libcblas). Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Removing ATLAS?
Le mercredi 12 juillet 2023 à 15:34 +0200, Rafael Laboissière a écrit : > * Sébastien Villemot [2023-07-08 10:01]: > > > As the maintainer of the atlas package over the last decade, I now > > wonder whether we should remove it from the archive. […] > Thanks for starting this discussion and proposing a plan, Sébastien. > > I looked at xmds2, which currently build-depends and depends on > libatlas-base-dev. For those who do not know, xmds2 is a tool written in > Python for generating C++ code that solvesq differential equations, using > a XML file with the description of the problem. > > When generating the C++ code, the xmds tool tries to link against > libcblas.so, which, currently, only exists in the libatlas-base-dev > package. > > I “fixed” the problem with a hacky patch to the file > xpdeint/support/wscript and by changing the dependencies to > libopenblas-dev | libblis-dev. If someone can review my changes [*], I > will be grateful. Your fix looks good. Note that an even better fix is to simply Build- Depend on libblas-dev. Linking against an optimized BLAS does not really help at build time, because since all variants are ABI compatible and use the same SONAME, it’s the runtime dependency that really matters. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Removing ATLAS?
Le mercredi 12 juillet 2023 à 16:05 +0200, Andreas Tille a écrit : > Am Wed, Jul 12, 2023 at 03:34:09PM +0200 schrieb Rafael Laboissière: > > When generating the C++ code, the xmds tool tries to link against > > libcblas.so, which, currently, only exists in the libatlas-base-dev package. > > I admit this is actually the reason why any of the packages I'm maintaining > depends from libatlas-base-dev: These are linking against libcblas which is > only provided in this package. If we might find a way to provide some kind > of "wrapper" so other implementations could provide libcblas as well, this > could be some generic solution. Unfortunately I'm probably pretty naive > and I'm asking for the impossible. Short version: any package that links against libcblas can normally be fixed by linking against libblas. Long version: for historical reasons, libblas.so in Debian contains both the BLAS Fortran routines, and a C interface to these routines (called CBLAS). Hence all the symbols that are in libcblas.so (which have the common “cblas_” prefix) are present in libblas.so. (Note that this is different from the LAPACK case: liblapack.so only includes the Fortran routines, while the C interface is provided by the separate liblapacke.so). You can check this for yourself by running the following commands: $ objdump -T /usr/lib/x86_64-linux-gnu/libblas.so $ objdump -T /usr/lib/x86_64-linux-gnu/libcblas.so -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Removing ATLAS?
Le lundi 10 juillet 2023 à 22:01 +0200, Andreas Tille a écrit : > Hi Sébastian, > > Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot: > > > > So, given all that, I’m inclined to (try to) remove atlas during the > > trixie development cycle. > > Sounds reasonable. > > > Any thought on this? > > I've checked my responsibility for the dependencies and stumbled about > emmax > > > emmax.c:10:10: fatal error: clapack.h: No such file or directory >10 | #include > | ^~~ > compilation terminated. > > > and noticed > > $ apt-file search clapack.h > libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h > ... (other instances are not blas related) > > which was probably the reason why I've picked libatlas-base-dev > originally. I would not say that emmax is important and its > also a not maintained upstream any more. However, I vaguely > remember that this >#include > in some code pieces of Debian Med was the reason to actually > pick this blas implementation. Any hint how to deal with such > cases? clapack.h is apparently an early attempt at providing a C interface to some LAPACK functions (which are in Fortran). It indeed looks ATLAS- specific. The modern solution for that problem is to use LAPACKE (note the final “E”), which is provided by liblapacke-dev. It is a standardized and maintained C interface to all LAPACK routines. I guess it should be feasible to adapt emmax to make it work with LAPACKE. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Removing ATLAS?
Hi, As the maintainer of the atlas package over the last decade, I now wonder whether we should remove it from the archive. As a reminder, ATLAS is an optimized BLAS implementation, that fits into our BLAS/LAPACK alternatives framework.¹ Its strategy for achieving good performance is to adjust various internal array sizes (at build time) so that they fit in the processor cache. It was probably the first optimized BLAS added to Debian (in 1999). Today, the project looks dead. The last stable release (3.10.3) happened in 2016. The last development release (3.11.41, not packaged) was in 2018. The git repository has seen no commit since 2019.² Moreover, there are better alternatives. Most people today use OpenBLAS. There is also BLIS, which can in particular be used on architectures not supported by OpenBLAS. Also note that ATLAS has never been really well-suited to our distribution model. To get the most of ATLAS, you have to recompile it locally using the specific CPU that you want to target; a generic binary package like the one we distribute is a suboptimal solution, since it is not adapted to the local CPU cache size. So, given all that, I’m inclined to (try to) remove atlas during the trixie development cycle. There are quite a few package which (build-)depend on atlas, I attach a list. But my guess is that these should be easily fixable, because most (if not all) do not require ATLAS specifically. One should normally not need to build-depend on atlas, since all our BLAS implementations are ABI-compatible (build-depending on libblas-dev should give an equivalent binary, unless one is doing static linking). For the dependencies of binary packages, I guess those were added to ensure that the user has an optimized BLAS installed; so they can probably be replaced by something like libopenblas0 | libblis4 (keeping in mind that since BLAS/LAPACK implementations are managed by the alternatives system, a dependency relationship cannot enforce the implementation used at runtime on the user machine). Any thought on this? Cheers, ¹ https://wiki.debian.org/DebianScience/LinearAlgebraLibraries ² https://github.com/math-atlas/math-atlas/ -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org sebastien@coccia:~$ dak rm -nR atlas Will remove the following packages from unstable: atlas | 3.10.3-13 | source libatlas-base-dev | 3.10.3-13 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libatlas-doc | 3.10.3-13 | all libatlas-test | 3.10.3-13 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libatlas3-base | 3.10.3-13 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x Maintainer: Debian Science Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: ceres-solver: libceres-dev libceres3 colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x] dune-common: libdune-common-dev emmax: emmax ergo: ergo iml: libiml0 nipy: python3-nipy-lib [armel mipsel] psfex: psfex python-escript: python3-escript [armel mipsel] python3-escript-mpi [armel mipsel] qm-dsp: libqm-dsp0 scamp: scamp [amd64 arm64 mips64el ppc64el s390x] scikit-misc: python3-skmisc sight: libsight [amd64] source-extractor: source-extractor xmds2: xmds2 # Broken Build-Depends: ceres-solver: libatlas-base-dev dune-common: libatlas-base-dev emmax: libatlas-base-dev libatlas3-base ergo: libatlas-base-dev ghmm: libatlas-base-dev halide: libatlas-base-dev hpcc: libatlas-base-dev iml: libatlas-base-dev ncl: libatlas3-base odin: libatlas-base-dev opm-material: libatlas-base-dev phast: libatlas-base-dev plink1.9: libatlas-base-dev plink2: libatlas-base-dev psfex: libatlas-base-dev qm-dsp: libatlas-base-dev scamp: libatlas-base-dev scikit-misc: libatlas-base-dev source-extractor: libatlas-base-dev theli: libatlas-base-dev xmds2: libatlas-base-dev Dependency problem found. signature.asc Description: This is a digitally signed message part
Re: libsuitesparse-dev and libcholmod4
Dear Giulio, Le mardi 30 mai 2023 à 11:32 -0400, Giulio Genovese a écrit : > There are two issues related to CHOLMOD. > > The first issue is that the libsuitesparse-dev package includes the > headers in the /usr/include/suitesparse/ rather than the > /usr/include/ directory which is not what SutieSparse does by default > and it is not what other package managers do (e.g. Homebrew and > Conda), creating an heterogeneous set of environments that > complicates the situation for developers. > > Since SuiteSparse has recently consolidated many of its header files > with the latest release, I do wonder whether it would be a good time > to revisit the decision to keep the headers in > /usr/include/suitesparse/ as this could create a uniform environment > across distributions. If having all headers in /usr/include/ is still > considered too much, could a soft link to > /usr/include/suitesparse/cholmod.h be present in /usr/include/? This > would allow code calling this header with the command: > #include "cholmod.h" > To work without issues across different environments. As the suitesparse package maintainer, I understand your point that such a move would provide more homogeneity across distributions, and would be more in line with upstream’s practice. On the other hand, this move is not straightforward (because that implies adapting the many Debian packages that depend on suitesparse). More importantly, having for e.g. /usr/include/amd.h would be highly confusing to most users, because the average user would expect that amd.h is related to AMD the processor brand. Even upstream acknowledges this problem, and recognizes that putting everything under /usr/include/suitesparse/ from the beginning would have been better.¹ Since Debian has already made the transition long ago to that better location, I’m rather inclined to keep it as it is. Note that most upstream packages are anyways already used to dealing with the two different locations. Also note that creating a symlink for just one header (cholmod.h), as you suggest as an alternative, seems weird and not in line with usual Debian practices. > The other issue is that CHOLMOD performance is significantly degraded > by libopenblas0-pthread, one of the packages that provides > libblas.so.3. As CHOLMOD is based on OpenMP, using a multi-threaded > version of BLAS causes significant cache issues when running multi- > threaded functions. I have observed CHOLMOD running twice as fast > when using libopenblas0-openmp instead of libopenblas0-pthread. > Although it would not solve all configurations, could the libcholmod4 > debian package recommend the installation of libopenblas0-openmp? > This would not guarantee that users would use the OpenMP version of > OpenBLAS when running CHOLMOD for users that have already a non- > OpenMP version installed, but it would at least default to this > version for users that don't have OpenBLAS installed to begin with. > > There might be other workarounds that I have not thought of so I am > open to alternative suggestions. Thanks for raising this issue, I was not aware of it. Interaction between pthread and OpenMP at different levels of the dependency tree has always been a delicate issue (see for example #737675 and #739331). Your suggestion to add a Recommends over libopenblas0-openmp in libcholmod4 could be a solution, but it may create problems in some applications given our historical experience (but maybe the situation has improved, I don’t know). Also it won’t work in all cases, because the OpenBLAS flavours are handled by the alternatives system, and the pthread flavour currently has a higher priority than the OpenMP one (so that if both are installed, the pthread flavour takes precedence unless the user explicitly says otherwise). I would be interested in hearing the opinion from others on this list who have more experience with this issue. Best wishes, ¹ https://github.com/DrTimothyAldenDavis/SuiteSparse/issues/177#issuecomment-1374828162 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: suitesparse-graphblas_6.0.0+dfsg-1_amd64.changes ACCEPTED into unstable, unstable
Le vendredi 26 novembre 2021 à 19:58 +0100, Vincent Prat a écrit : > > > I haven’t yet added the new dependencies of libsuitesparse-dev on > > libgraphblas-dev (and of libsuitesparse-doc on libgraphblas-doc), to > > avoid triggering the file conflict on upgrades. I’m going to wait for > > your upload. > I just uploaded version 6.0.0+dfsg-3, which breaks and replaces the -dev > and -doc packages from src:suitesparse (<< 1:5.10.1+dfsg-3). Note that the Breaks+Replaces on libsuitesparse-doc is useless. There is no common file between the two -doc packages. > > By the way, I’m wondering whether these should be Recommends instead of > > Depends. It’s perfectly possible to use the libraries provided by > > src:suitesparse without using GraphBLAS, so a Depends might be too > > strict. And it seems that no package currently builds against > > GraphBLAS, so this should not break stuff. What do you think? > I agree with you. Recommends is probably enough. I’ve added the Recommends in suitesparse 1:5.10.1+dfsg-4. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: suitesparse-graphblas_6.0.0+dfsg-1_amd64.changes ACCEPTED into unstable, unstable
Hi Vincent, Le mercredi 24 novembre 2021 à 19:26 +0100, v...@debian.org a écrit : > Please let me know when src:suitesparse stops providing graphblas, so > that I can make libgraphblas-dev conflict with previous versions of > libsuitesparse-dev. I have just uploaded suitesparse 1:5.10.1+dfsg-3, which no longer provides GraphBLAS. Note that you will need to add a Breaks+Replaces, and not a Conflicts, against older versions. I haven’t yet added the new dependencies of libsuitesparse-dev on libgraphblas-dev (and of libsuitesparse-doc on libgraphblas-doc), to avoid triggering the file conflict on upgrades. I’m going to wait for your upload. By the way, I’m wondering whether these should be Recommends instead of Depends. It’s perfectly possible to use the libraries provided by src:suitesparse without using GraphBLAS, so a Depends might be too strict. And it seems that no package currently builds against GraphBLAS, so this should not break stuff. What do you think? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: suitesparse-graphblas_6.0.0+dfsg-1_amd64.changes is NEW
Le mercredi 17 novembre 2021 à 23:15 +0100, v...@debian.org a écrit : > @sebastien: As you can see, the SOVERSION of GraphBLAS changed so there > is no more conflict with libgraphblas5 from the suitesparse source package. Great, thanks for that. Could you possibly send me a notification when suitesparse-graphblas is accepted, so that I adapt src:suitesparse to stop building it? Also, do you think we should add a Depends of libsuitesparse-dev on libgraphblas-dev (and of libsuitesparse-doc on libgraphblas-doc), to preserve the current behaviour? Best, > Le 17/11/2021 à 23:06, Debian FTP Masters a écrit : > > binary:libgraphblas-dev is NEW. > > binary:libgraphblas-doc is NEW. > > binary:libgraphblas6 is NEW. > > binary:libgraphblas-dev is NEW. > > binary:libgraphblas-doc is NEW. > > binary:libgraphblas6 is NEW. > > source:suitesparse-graphblas is NEW. > > > > Your package has been put into the NEW queue, which requires manual action > > from the ftpteam to process. The upload was otherwise valid (it had a good > > OpenPGP signature and file hashes are valid), so please be patient. > > > > Packages are routinely processed through to the archive, and do feel > > free to browse the NEW queue[1]. > > > > If there is an issue with the upload, you will receive an email from a > > member of the ftpteam. > > > > If you have any questions, you may reply to this email. > > > > [1]: https://ftp-master.debian.org/new.html > > or https://ftp-master.debian.org/backports-new.html for *-backports > > -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: GraphBLAS and SuiteSparse
Le samedi 02 octobre 2021 à 14:06 +0200, Vincent Prat a écrit : > Le 02/10/2021 à 13:17, Sébastien Villemot a écrit : > > Le samedi 02 octobre 2021 à 11:06 +0200, Vincent Prat a écrit : > > > Le 27/09/2021 à 17:26, Sébastien Villemot a écrit : > > > > Le samedi 25 septembre 2021 à 17:57 +0200, Vincent Prat a écrit : > > > > > I recently started packaging python-suitesparse-graphblas [1], which > > > > > is > > > > > a Python binding of SuiteSparse:GraphBLAS [2]. > > > > > The version of GraphBLAS packaged in Debian comes from a different > > > > > repository that includes many other pieces of software, SuiteSparse > > > > > [3]. > > > > > My problem is that the version included in SuiteSparse (currently > > > > > 5.0.5) > > > > > is out of date compared to the standalone version (currently 5.1.7) > > > > > used > > > > > by python-suitesparse-graphblas. > > > > > > > > > > What is the best option? > > > > > a) packaging the standalone version with a different name > > > > > b) packaging the standalone version instead of the one included in > > > > > SuiteSparse > > > > > c) packaging an outdated version of python-suitesparse-graphblas to > > > > > fit > > > > > the version of GraphBLAS included in SuiteSparse > > > > > > > > > > As far as I know, other pieces included in SuiteSparse do not depend > > > > > on > > > > > GraphBLAS, so I would rather go for option b. > > > > > Sébastien, can you confirm this ? > > > > I was not aware that GraphBLAS was also distributed independently of > > > > SuiteSparse. > > > > > > > > I am perfectly fine with option b. > > > > > > > > Just note that you will have to be careful with version numbers, > > > > especially since suitesparse currently has an epoch. The libgraphblas5 > > > > binary package that will be produced by your new source package must > > > > have a greater version number than the current one. > > > > > > > > What I would suggest is to not put the epoch in the new source package > > > > version, and to only add the epoch on the libgraphblas5 binary package > > > > (this is technically possible, see e.g. gcc-defaults). > > > > > > > > And when libgraphblas bumps its SOVERSION (whichs happens quite > > > > frequently), then you will be able to drop the epoch and revert to a > > > > standard versioning scheme. > > > > > > > Thank you for your reply. > > > I think I understand how to do this. > > > Besides, the Debian policy states that before increasing the epoch, one > > > should get a consensus on devian-devel, so I guess the discussion has to > > > move there. > > Actually there is no need to increase an epoch. There is already one on > > libgraphblas5, and we’re just talking about moving that binary package > > to a new source package, so it’s inevitable that the epoch has to stay. > > I don’t think that requires a discussion on debian-devel@. > > > What should be the version of the new binary package, then? > The version of SuiteSparse itself (5.10.1) is higher than that of > standalone GraphBLAS (5.1.7). > Do you suggest something like 1:5.10.1+really5.1.7+dfsg-1? Sorry, I had overlooked the fact that the version number of GraphBLAS itself is currently lower than GraphBLAS. Maybe this case indeed warrants an epoch bump (which would be only a temporary one until the SOVERSION is bumped to 6). Alternatively, the +really trick could also be a solution. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: GraphBLAS and SuiteSparse
Le samedi 02 octobre 2021 à 11:06 +0200, Vincent Prat a écrit : > Le 27/09/2021 à 17:26, Sébastien Villemot a écrit : > > > > Le samedi 25 septembre 2021 à 17:57 +0200, Vincent Prat a écrit : > > > I recently started packaging python-suitesparse-graphblas [1], which is > > > a Python binding of SuiteSparse:GraphBLAS [2]. > > > The version of GraphBLAS packaged in Debian comes from a different > > > repository that includes many other pieces of software, SuiteSparse [3]. > > > My problem is that the version included in SuiteSparse (currently 5.0.5) > > > is out of date compared to the standalone version (currently 5.1.7) used > > > by python-suitesparse-graphblas. > > > > > > What is the best option? > > > a) packaging the standalone version with a different name > > > b) packaging the standalone version instead of the one included in > > > SuiteSparse > > > c) packaging an outdated version of python-suitesparse-graphblas to fit > > > the version of GraphBLAS included in SuiteSparse > > > > > > As far as I know, other pieces included in SuiteSparse do not depend on > > > GraphBLAS, so I would rather go for option b. > > > Sébastien, can you confirm this ? > > I was not aware that GraphBLAS was also distributed independently of > > SuiteSparse. > > > > I am perfectly fine with option b. > > > > Just note that you will have to be careful with version numbers, > > especially since suitesparse currently has an epoch. The libgraphblas5 > > binary package that will be produced by your new source package must > > have a greater version number than the current one. > > > > What I would suggest is to not put the epoch in the new source package > > version, and to only add the epoch on the libgraphblas5 binary package > > (this is technically possible, see e.g. gcc-defaults). > > > > And when libgraphblas bumps its SOVERSION (whichs happens quite > > frequently), then you will be able to drop the epoch and revert to a > > standard versioning scheme. > > > Thank you for your reply. > I think I understand how to do this. > Besides, the Debian policy states that before increasing the epoch, one > should get a consensus on devian-devel, so I guess the discussion has to > move there. Actually there is no need to increase an epoch. There is already one on libgraphblas5, and we’re just talking about moving that binary package to a new source package, so it’s inevitable that the epoch has to stay. I don’t think that requires a discussion on debian-devel@. Please let me know when you want to move on with all this, so that I make the necessary changes in src:suitesparse in a coordinated fashion. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: GraphBLAS and SuiteSparse
Hi Vincent, Le samedi 25 septembre 2021 à 17:57 +0200, Vincent Prat a écrit : > I recently started packaging python-suitesparse-graphblas [1], which is > a Python binding of SuiteSparse:GraphBLAS [2]. > The version of GraphBLAS packaged in Debian comes from a different > repository that includes many other pieces of software, SuiteSparse [3]. > My problem is that the version included in SuiteSparse (currently 5.0.5) > is out of date compared to the standalone version (currently 5.1.7) used > by python-suitesparse-graphblas. > > What is the best option? > a) packaging the standalone version with a different name > b) packaging the standalone version instead of the one included in > SuiteSparse > c) packaging an outdated version of python-suitesparse-graphblas to fit > the version of GraphBLAS included in SuiteSparse > > As far as I know, other pieces included in SuiteSparse do not depend on > GraphBLAS, so I would rather go for option b. > Sébastien, can you confirm this ? I was not aware that GraphBLAS was also distributed independently of SuiteSparse. I am perfectly fine with option b. Just note that you will have to be careful with version numbers, especially since suitesparse currently has an epoch. The libgraphblas5 binary package that will be produced by your new source package must have a greater version number than the current one. What I would suggest is to not put the epoch in the new source package version, and to only add the epoch on the libgraphblas5 binary package (this is technically possible, see e.g. gcc-defaults). And when libgraphblas bumps its SOVERSION (whichs happens quite frequently), then you will be able to drop the epoch and revert to a standard versioning scheme. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: double handling of BLAS alternatives: blas.so vs blas.so.3
Hi Drew and Mo, Le mardi 04 mai 2021 à 05:25 +, M. Zhou a écrit : > On Sun, 2021-05-02 at 13:50 +0200, Drew Parsons wrote: > > Mo Zhou did the good work of setting up an alternatives framework for > > our BLAS libraries, which is great. We can select between OpenBLAS, > > BLIS, whatever is best for the local system (even intel-mkl). > > Actually that alternative system is NOT my original work -- I just > refined it with BLAS64 alternatives along with some minor enhancements > IIRC. Only Gentoo's initial version of BLAS/LAPACK switching is > my original work. I confirm that this setup is very old, i.e. at least 10 years, maybe more. It also predates my involvement in the BLAS/LAPACK ecosystem. > > But the framework was set up with double handling of the basic > > libblas.so alternative symlink in each /usr/lib/ directory. > > There's one for the unversioned libblas.so, and a separate one for > > libblas.so.3. > > > > This means it's possible for the libblas.so alternative to point at > > blis-pthread/libblas.so, for instance, while libblas.so.3 points at > > openblas-pthread/libblas.so.3. It seems to me that's a potential for > > disaster. While I agree that the separation between libblas.so and libblas.so.3 is a bit confusing, I don’t see where is the “potential for disaster”. My understanding is that it makes no difference whether libblas.so points to reference BLAS or OpenBLAS or whatever, as long as you’re doing dynamic linking. Since all those libraries are ABI-compatible, the resulting executable will be the same in all cases (with libblas.so.3 in the NEED section of the ELF binary). The libblas.so alternative only matters when you’re doing static linking, since that alternative also governs libblas.a. But we don’t use static linking much in Debian. And for someone who is doing static linking, the libblas.so.3 alternative is irrelevant anyways, so there is no risk of confusion. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
octave-symbolic and sympy
Dear Georges, Since the upload of sympy 1.7, the autopkgtest of octave-symbolic fails (and the package FTFBS), see bug #980707.¹ As a consequence, sympy 1.7 has not yet migrated into testing. The problem has been forwarded to octave-symbolic’s upstream, but so far there has been no answer. I’m not fluent enough in Python/SymPy to solve it myself. If nothing is done, octave-symbolic will be removed from testing in one week, and sympy 1.7 will migrate to testing (and thus be in bullseye). I think that from a user’s perspective, it’s more important to have an up-to-date sympy in bullseye than to have octave-symbolic. But if you have an idea how to fix the problem and have both in bullseye, that would be great. Best, ¹ https://bugs.debian.org/980707 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Newbie OpenBLAS Packaging Question
Dear John, Le dimanche 26 juillet 2020 à 10:00 +0100, John Duffy a écrit : > In my Debian/Ubuntu /usr/lib/aarch64-linux-gnu/openblas-serial directory I > have... > > -rw-r--r-- 1 root root 8435720 Jun 2 10:55 libblas.so.3 > -rw-r--r-- 1 root root 13712616 Jun 2 10:55 liblapack.so.3 > -rw-r--r-- 1 root root 14269784 Jun 2 10:55 libopenblas-r0.3.8.so > lrwxrwxrwx 1 root root 21 Jun 2 10:55 libopenblas.so.0 -> > libopenblas-r0.3.8.so > > What is the difference between the libblas.so.3 and libopenblas-r0.3.8.so? I > note they are not the same size. They mostly ship the same contents, though with a different SONAME. The libopenblas.so object is bigger because it also contains LAPACK. > I have a horrible suspicion that I have been linking to a reference > Blas library (the libblas.so.3), through the update- > alternatives mechanism, and not OpenBLAS (the libopenblas.so.0 -> > libopenblas-r0.3.8.so). The choice via the update-alternatives mechanism does not matter much at link time, as long as your are doing dynamic linking (and not static linking). It only matters at runtime. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: OpenBlas Pthread issue with R
Hi Dirk and Mo, Le jeudi 28 mai 2020 à 08:12 +, Mo Zhou a écrit : > After browsing some of the related discussions, I think we can try > rebuilding openblas with one of of these options (MAKE_OPTIONS) > > USE_SIMPLE_THREADED_LEVEL3=1 > USE_TLS=0 > > On Wed, May 27, 2020 at 11:22:32PM -0500, Dirk Eddelbuettel wrote: > > > But not to take this away from the key aspect: > > > > - on some platforms (and my i7-8700k fits) R is _unuseable_ > > > > That is a grave issue. Fixing this should maybe take precedence over > > designing new schemes that are yet to be tested. I agree that there is a bug that needs to be fixed. I happen to have access to an i7-8700K CPU, so I’ll try to reproduce the problem. I also think we should track this in a proper Debian bug, adding links to the “relevant discussions” mentioned by Mo above. Can one of you open that bug, so that we can move the discussion there? Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFR: build libjulia-openblas64 from src:openblas
Hi Mo, Le samedi 09 mai 2020 à 14:58 +, Mo Zhou a écrit : > Julia needs a openblas library with some special configs (symbol > mangling) I'm getting rid of the embedded code copies from src:julia, so > just submitted my changes as a pull request: > https://salsa.debian.org/science-team/openblas/-/merge_requests/2 It looks good to me. I’ve merged your changes. You can go ahead with an upload if you will. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: [GSoC] BLAS/LAPACK Ecosystem Enhancement for Debian
Le lundi 11 mai 2020 à 21:10 +0200, Sébastien Villemot a écrit : > Le mardi 12 mai 2020 à 01:48 +0800, Drew Parsons a écrit : > > 2b) A separate thing to look into is whether the alternative for > > libblas.so.3 can be slaved on to libblas.so (or vice versa) so they > > don't have to be configured separately. If there's likely to be a > > libblas.so.4 then it makes more sense to keep them separate, but > > it's > > been libblas.so.3 since the 1980s I believe. They are different > > packages so it's not so straightforward to slave-link them to one > > another. But the HDF5 maintainer recently found a way to do it (to > > link > > hdf5-mpi.pc against the preferred MPI alternative, see > > libhdf5-openmpi-dev.postinst) > > I think the difficulty here is that libblas.so and libblas.so.3 live in > different packages (-dev versus shared library). Sorry I had overlooked your remark about HDF5. What is done there looks a bit hackish, but if it works and is robust, why not… Note however that the libblas.so alternative should actually not matter much. Since the various implementations are supposed to be ABI- compatible, whichever is used at link time should normally be irrelevant. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: [GSoC] BLAS/LAPACK Ecosystem Enhancement for Debian
Hi Drew, Le mardi 12 mai 2020 à 01:48 +0800, Drew Parsons a écrit : > 2) The naming of the alternatives links is not intuitive, marked > arch-specifically as libblas.so-x86_64-linux-gnu, > libblas.so.3-x86_64-linux-gnu, etc. > Normally it would just be libblas.so, as in "update-alternatives > --config libblas.so", or better still "update-alternatives --config > blas". > Is it really necessary to include the arch in the alternative name? This is necessary for multiarch, see #770290. > 2b) A separate thing to look into is whether the alternative for > libblas.so.3 can be slaved on to libblas.so (or vice versa) so they > don't have to be configured separately. If there's likely to be a > libblas.so.4 then it makes more sense to keep them separate, but > it's > been libblas.so.3 since the 1980s I believe. They are different > packages so it's not so straightforward to slave-link them to one > another. But the HDF5 maintainer recently found a way to do it (to > link > hdf5-mpi.pc against the preferred MPI alternative, see > libhdf5-openmpi-dev.postinst) I think the difficulty here is that libblas.so and libblas.so.3 live in different packages (-dev versus shared library). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: OpenBlas Pthread issue with R
Le vendredi 01 mai 2020 à 07:05 -0500, Dirk Eddelbuettel a écrit : > On 1 May 2020 at 05:16, Mo Zhou wrote: > > On Thu, Apr 30, 2020 at 11:26:23PM -0500, Dirk Eddelbuettel wrote: > > > Switching to libopenblas0-openmp works but one needs to uninstall > > > libopenblas0-pthread (or else fiddle with the alternatives priority). > > > > Does that mean the update-alternatives mechanism is malfunctioning? > > I do not know. > > It could just be the default ranking is wrong. I did not check, and was > interested in fiddling manually (as I find it always bites me years later...) > > Given that openblas-pthread renders R _unuseable_ and that Seb said it was a > known issue, maybe we should ensure it ranks lower than it currently does? I did not say that it is a known issue. I said that we had a similar issue in the past, but that it was solved. Also, I tried to reproduce the problem on an unstable system with OpenBLAS/pthreads selected as the alternative, but I couldn’t. The computation goes fine for me. So I guess the problem manifests only on specific systems or CPUs. I suggest that you open a bug report, providing as many details as possible on the system where it manifests (in particular, the precise CPU model). Also, I don’t think we should change the alternatives priorities. The OpenMP flavour of OpenBLAS has its own problems (in particular, because it is compiled with GNU OpenMP, it is incompatible with applications compiled against Intel’s OpenMP, and we cannot do anything about that). So we should rather fix the bug that you encountered. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: OpenBlas Pthread issue with R
Le jeudi 30 avril 2020 à 10:43 -0500, Dirk Eddelbuettel a écrit : > On the r-sig-debian list (hosted by the R Project for users of R on Debian > and Ubuntu) someone pointed out that R hangs on simple calls into OpenBLAS > Pthread, i.e. /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 > > To witness, just launch R and issue the example(solve) which spends two > lines setting a helper Hilbert function and input data with it and then hangs > on the actual call to solve() (see below for full example) > > Is this a known issue? Do we need to set some OpenMP env vars to limit thread > use? The problem was there in the past but was solved. I don’t know why it is happening again. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739331 Also note that (in unstable/testing) there are now OpenMP and single- threaded flavours of OpenBLAS (in packages libopenblas0-openmp and libopenblas0-serial). As a workaround, you can try to install one of these two (and adjust the BLAS alternatives accordingly). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: updated vspline package data to upstream version 1.0.0
Dear Kay, Le samedi 04 avril 2020 à 11:08 +0200, Kay F. Jahnke a écrit : > After yet another year of constant use I have decided on moving vspline > up to version 1.0.0. I consider it mature enough to warrant this step, > and I feel I can recommend it's use in production code, mainly due to my > own extensive use in pv, my image and panorama viewer, and in > python-vspline, the cppyy-based python interface to vspline. > > I hope this decision meets your approval, and I also hope that my > modifications to the package infrastructure are correct - here on my > system I managed to successfully do a uscan import from upstream and > build a package with gbp which installed locally, so all should be well. > > Sébastien, if you are happy with my work, please do your part. If > anything is amiss, please let me know! Could you possibly: - push the upstream and pristine-tar branches, and also the tags - run the lintian-brush tool (from a sid chroot), which fix various small issues (it will also bump to debhelper 12), and push the result > When I installed the package I made here on my system, the package > management said the license was 'proprietary'. My code is licensed with > the Expat license, and this is also what I've put into debian/copyright. > Can someone help with this issue? I'd like potential users to see that > the license is indeed common and very permissive. I don’t understand how this can happen, since your package is in the main component of Debian (and not in contrib or non-free). Could you give more details about the warning message, and about the tool that displayed it? Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: [need mentor] GSoC Proposal: Enhancement to Debian's BLAS/LAPACK Ecosys
Hi Lumin and Andreas, Le jeudi 12 décembre 2019 à 11:11 +0100, Andreas Tille a écrit : > since I need to admit that I have no idea about BLAS/LAPACK and I'm just > a happy user of these packages as dependencies of several of my own > packages, I'm volunteering to co-mentor this project since I regard it > really important and would love to see it happen. A real mentor who can > give some advise and set directions (which I really can not!) would be > very welcome. My time for Debian is currently rather limited, so I was hesitating to be a mentor for this, though my position as long-time maintainer of BLAS/LAPACK (and suitesparse) makes me a natural candidate. On the other hand, Lumin has been doing a very valuable work on those packages, and we should make everything possible to allow him to continue and get all the support he needs. So, if this is possible, having Andreas and myself as co-mentors could be a workable solution. I should be able to give guidance and feedback from time to time. And Lumin is already quite familiar with the issues at hand, so I’m sure he can be autonomous to a large extent. What I’m much less motivated to do however is the “administrative” part, such as wrapping up the proposal or writing reports (though I don’t exactly what a mentor is supposed to do in that area). Maybe someone with more experience with GSoC could comment on that. Best, > On Wed, Dec 11, 2019 at 03:15:13PM +, Mo Zhou wrote: > > Hi science team, > > > > I'm proposing the following project for GSoC 2020: > > "Enhancement to Debian's BLAS/LAPACK Ecosys" > > To some extent this is basically making some portion of my > > todo-list well-funded by Google :-) > > > > I cannot "mentor" myself as I'm the participating student... > > So I think I need a GSoC mentor at this point. > > Please tell me if you are willing to be the mentor for this > > proposed project. > > > > Content of Proposal > > --- > > > > 1. write down the formal (science team) policies about BLAS/LAPACK > >linkage and add corresponding lintian warnings. (Partially > >discussed on -devel before.) > > 2. help BLAS/LAPACK reverse dependencies get rid of the > >libcblas.so linkage. (confirmed in the previous MBF) > > 3. remove libcblas.so from src:atlas (confirmed by Sébastien) > > 4. integrate libflame into our ecosys (preliminary packaging > >already available on salsa. may need to work with upstream > >and solve some remaining problems. when the package is ready > >for debian, I'll also port it to Gentoo) > > 5. a fine documentation about debian's BLAS/LAPACK ecosys > >(some of you have already seen a private copy of this) > > > > Optional targets (if there will be enough time for me) > > -- > > > > 1. update src:openblas and src:suitesparse and remove the vendored > >openblas/suitesparse from src:julia. > > 2. patch src:lapack and add 64bit-indexing support for CBLAS. > > > > Background/Who am I > > --- > > > > I'm confident about acceptance ... as long as Debian will not fall > > out > > from the hosting organization list this year... > > > > 1. I'm currently a master student. > > 2. During GSoC2019, I introduced a blas/lapack runtime switch > > mechanism > >to Gentoo ( > > https://wiki.gentoo.org/wiki/Blas-lapack-switch > > ) > >which is to some extent similar to our update-alternatives. > > 3. currently I co-maintain a portion of blas/lapack packages for > >both Gentoo and Debian. > > 4. I have sufficient skill set (as a DD) to finish the proposal > >(that has been dragged for long time due to my slacking off) > > > > > > -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: uploading lapack 3.8.0-8 and openblas to unstable?
Hi Lumin, Le jeudi 31 octobre 2019 à 01:22 +, Mo Zhou a écrit : > Shall we upload lapack 3.8.0-8 > > + [ Sébastien Villemot ] > + * Migrate to Python 3 > ++ python3.patch: new patch > ++ d/control, d/tests/control: replace python by python3 (Closes: #943142) > + * Bump to debhelper compat level 12. > +On mipsel, disable dh_dwz. > + > + [ Mo Zhou ] > + * Fix FTBFS with doxygen 1.8.16 (Closes: #943431) > + * Add README.if-you-look-for-libcblas.so.3 to libblas-dev (Closes: #943715) > > and openblas > > +openblas (0.3.7+ds-3) UNRELEASED; urgency=medium > + > + * Upload to unstable. > > to unstable? buildd/openblas looks good. Sure, feel free to go ahead. BTW, thanks again for all your recent work on those two packages. 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:openblas Multi-Flavour updates
Hi Lumin, Le samedi 21 septembre 2019 à 22:59 -0700, Mo Zhou a écrit : > I've updated the git branch for this feature: > > https://salsa.debian.org/science-team/openblas/commits/lumin > > > It can be built against the git master version of src:lapack > (i.e. 3.8.0-4 + 1 commit that fixes installation path). > Problems pointed out in the previous round of review have > been fixed already. I’ve finally found some time to review your useful work. Here are my remarks: - piuparts reports an error: 2m45.8s ERROR: FAIL: Package purging left files on system: /usr/lib/x86_64-linux-gnu/pkgconfig/ owned by: libopenblas-dev:amd64 - the autopkgtest installs all flavors, but only tests the 32- bit/pthread one. At the very least, it should be updated to install only the flavor it tests (for the sake of clarity and simplicity). But ideally it should test all the flavors. - My understanding is that you merged order-files.patch into shared- blas-lapack.patch. You should then also update the metadata of the latter patch (explain that it also reorders the files, and give the reference to the original Debian bug #). - In debian/rules, the UAPRI_* variable names are rather obscure. Either use more explicit names, or add a comment. Once those are fixed, you can go ahead with an upload to experimental (because we have to go through NEW). Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Add to salsa group + sundials update
Dear James, Le samedi 19 octobre 2019 à 17:40 +1100, James Tocknell a écrit : > Cool, thanks, I've pushed my changes. It looks like the fortran > libraries are almost trivial (there's only a few functions, which > only call sundials functions), so I've added lintian ignores for the > non-linking to them. As there's an ABI break, we probably should > upload 4.1 to experimental (not unstable), so octave and others don't > FTBFS. I haven't dug into what new features are available in 4.1, so > I'm going to look at what new things can be activated (things like > cuda are obviously out, but I'll see what new backends I can switch > on), but feel free to upload as is (I only added a snapshot to the > changelog, so adding a new entry should be the only thing to do > before uploading). Thanks. I just uploaded the package to experimental, so we now have to wait until it clears the NEW queue. There are several minor issues that it would be nice to fix for the next upload. Lintian reports several info level tags, among which: I: sundials source: duplicate-short-description libsundials-arkode3 libsundials-sunlinsol2 libsundials-sunmatrix2 I: sundials source: duplicate-long-description libsundials-sunlinsol2 libsundials-sunmatrix2 I: sundials source: license-file-listed-in-debian-copyright LICENSE I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/FindMPI.cmake (paragraph at line 56) I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/SundialsMPIC.cmake (paragraph at line 56) I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/SundialsMPIF.cmake (paragraph at line 56) I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/SundialsPETSc.cmake (paragraph at line 56) I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/SundialsFortran90.cmake (paragraph at line 145) I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/SundialsMPICXX.cmake (paragraph at line 145) I: sundials source: wildcard-matches-nothing-in-dep5-copyright config/SundialsMPIF90.cmake (paragraph at line 145) I: sundials source: debian-watch-uses-insecure-uri http://computation.llnl.gov/projects/sundials/sundials-software I: sundials source: out-of-date-standards-version 4.2.1 (released 2018-08-25) (current is 4.4.1) I: libsundials-sunlinsol2: symbols-file-missing-build-depends-package-field Also, adequate reports the following dangling symbolic links: libsundials-dev: broken-symlink /usr/lib/x86_64-linux-gnu/libsundials_fsunnonlinsolfixedpoint.so -> libsundials_fsunnonlinsolfixedpoint.so.1 libsundials-dev: broken-symlink /usr/lib/x86_64-linux-gnu/libsundials_fsunnonlinsolnewton.so -> libsundials_fsunnonlinsolnewton.so.1 libsundials-dev: broken-symlink /usr/lib/x86_64-linux-gnu/libsundials_sunnonlinsolfixedpoint.so -> libsundials_sunnonlinsolfixedpoint.so.1 libsundials-dev: broken-symlink /usr/lib/x86_64-linux-gnu/libsundials_sunnonlinsolnewton.so -> libsundials_sunnonlinsolnewton.so.1 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: Add to salsa group + sundials update
Hi James, Thanks for working on sundials. Le vendredi 11 octobre 2019 à 18:17 +1100, James Tocknell a écrit : > Can someone give me access to the salsa group (my username is > aragilar-guest, same as it was on alioth)? Actually you are already a member of the Science Team group on salsa. However, you have only “Developer” status, which means that you cannot push to (protected branches of) repositories. Could some group owner grant James the “Maintainer” level for the sundials repository? > I've got an almost working update of sundials (from 3.1.1. to 4.1 - > see aragilar-guest/sundials, though I need to clean up the commits). > Lintian is flagging that the fortran wrappers are now not linking to > libc, however looking at the code they do not seem to require a > direct link to libc (they only explicitly depend on the equivalent C > library), would anyone know if that's a bug in lintian or gfortran? What do you mean by “they only explicitly depend on the equivalent C library”? In any case, if you’re sure that your binaries don’t require any symbol from the libc, it’s ok to override the lintian warnings. 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
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
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
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
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
Re: Towards lapack / lapack64 packaging
Hi Lumin, Le mercredi 15 mai 2019 à 08:39 -0700, Mo Zhou a écrit : > (1) building problem about OpenBLAS's liblapack64.so > - > > Sébastien provided some possible solutions: > > 1. build a 64-bit indexing variant of src:lapack > 2. provide a liblapack64-pic (Sébastien prefer this) First, note that solution 1 is a superset of solution 2 (i.e. we would also provide liblapack64-pic in solution 1). Actually solution 1 is my preferred one. But since I do not have the time to work on it in the immediate future, and since you’ve said you were not interested in investing time in non- optimized implementations, I would be ok if you were implementing solution 2 as an intermediate step. Then I could implement 1 later. > Yes, the solution *2 poses very little workload because > we just need to rebuild lapack with fortran flag "-i8". > > However, I'm thinking about the 3-rd solution: > > 3. disentangle src:lapack and src:openblas and just > use src:openblas's embedded copy of src:lapack. > (currently that embedded copy is removed from debian > source) I don’t think this is an acceptable solution. I deliberately stripped the embedded copy of src:lapack in order to follow best practices. See Debian Policy §4.13 and https://wiki.debian.org/EmbeddedCodeCopies > (2) confirming details for our standard of BLAS/LAPACK virtual packages > --- > 1. BLAS/CBLAS packages looks relatively tidy, except Atlas >which splitted CBLAS into a separate libcblas.so . This is not true, as you can easily verify by running: nm -D /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 | grep cblas_ >That's a pitfall and numpy had ever fell into it: #913567 The numpy issue is unrelated. >Debian's Atlas is terribly slow due to ISA baseline.[2] Note that ATLAS is meant to be recompiled locally in order to get best performance, as explained in the extended description of the package. But it’s true that it’s slower than OpenBLAS and BLIS. >Should we squash Atlas's libcblas.so back into it's >libblas.so ? [3] Like all other alternative libraries did. As said above, this is already done. > 2. LAPACK and LAPACKE are well-seperated into different >shared libraries. Sometimes LAPACKE is simply not >built. LAPACK has been registered in the alternatives >system: "liblapack.so", "liblapack.so.3". > >Can we confirm that it's fine to provide only LAPACK >via liblapack.so and don't register LAPACKE in the >alternatives system? Yes I think it’s fine. LAPACKE is only a thin C wrapper above LAPACK, and there is only one implementation of that wrapper. And liblapacke.so is dynamically linked against liblapack.so, so it will pick whatever LAPACK implementation is currently selected in the alternatives system. Thanks for your work on BLAS/LAPACK, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Please start reviewing the updated OpenBLAS packaging for six different flavors
Dear Lumin, Le dimanche 28 avril 2019 à 09:36 +, Mo Zhou a écrit : > Please start checking the updated openblas packaging here, I'm almost > finalizing the changes. The experimental package can be built and > installed: > https://salsa.debian.org/science-team/openblas/tree/lumin > > > I say "almost" because this is a hell of detail. I still have to > check > the package contents again, and compare the headers for different > variants. That would still take some time but the basic shaping of > the package was finished. I guess I still have to fix some missing > "64" postfixes, or something alike. I took some time reviewing it (only looking at source code for the time being, I haven’t yet compiled or tested it). Here are my comments. The first is a major issue, the others are minor or easy to address. 1) Unless I am missing something, I think the LAPACK provided by the 64-bit indexing variants is broken. The problem is that OpenBLAS provides optimized versions of only a subset of the LAPACK routines. The others are directly copied from the liblapack-pic binary, which is has 32-bit integer indexing. Hence the generated 64-bit indexing LAPACK is a mixture of 32-bit and 64-bit indexing routines, depending on whether OpenBLAS overrides them, which is obviously broken. I think there is no other choice but to build a 64-bit indexing variant of src:lapack (either just providing a liblapack64-pic, providing the full-fledged alternatives; I tend to favor the second option, but I understand that you're not interested in that; this can probably be discussed in a separate thread). 2) You removed the "-frecursive" Fortran option in debian/rules. I think this is incorrect. This option is added by Makefile.system. It is necessary for correct operation of LAPACK (see #693269; see also the debian/rules of src:lapack). I understand from your comments that the option creates a test failure somewhere, so more investigation is probably needed. 3) libopenblas-base should be in section “oldlibs”, since it is a transitional package 4) There were two preinst scripts (one for the shared library, one for the dev package) whose purpose was to remove old alternatives from the pre-multiarch layout, during the stretch→buster upgrade. You moved these scripts to the new binary packages, but I think this is incorrect, since these scripts are only needed when upgrading from older packages. I think these scripts should either be left as they were (and no preinst should be added to the 64-bit flavour), or they could as well be entirely dropped, since they won’t be needed for the buster→bullseye upgrade. 5) Maybe we should put more space between priority levels. Instead of 100>99>98, maybe put 100>95>90. So that it is easier to put something in between, should the need arise. 6) In debian/rules, the test for determining whether the architecture is 64-bit could probably be simplified and made more generic by checking the value of the variable DEB_HOST_ARCH_BITS. 7) The extended package descriptions are the same across variants. I think they should be differentiated by explaining the options contained in a given package (and in particular, mention that 32-bit indexing vs 64-bit indexing is just about matrix indexing, not about CPU ISA). 8) The git history is quite messy. I think your branch should be squashed in a single commit. Thanks for your work, I think it’ll be a great step forward for t he OpenBLAS package (once we’ve fixed these issues). 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: Bug#926330: RFS: cuba/4.2-1 [ITP]
Le jeudi 25 avril 2019 à 23:46 +0200, Francesco Montanari a écrit : > Thanks for taking the time to review the package. I just the upload (after fixing a remaining typo). Thanks for your contribution, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Bug#926330: RFS: cuba/4.2-1 [ITP]
Hi Francesco, Le jeudi 11 avril 2019 à 23:21 +0200, Francesco Montanari a écrit : > Thanks! I updated the package after going through Debian Science > Policy and pushed the changes to the git repository. I'd appreciate if > someone is available to sponsor the package. > > As mentioned in the ITP [1], a previous version of the library, > libcuba3, was already in Debian and I based the package on that one. I > reached out to the previous maintainer to verify that he is fine with me > reintroducing the package. I quickly reviewed the package and I think it is almost ready. There are however some issues: — The autopkgtest does not work. I get: autopkgtest [14:48:10]: test cuba: [--- make: *** No rule to make target 'check'. Stop. autopkgtest [14:48:11]: test cuba: ---] autopkgtest [14:48:11]: test cuba: - - - - - - - - - - results - - - - - - - - - - cuba FAIL non-zero exit status 2 — I think there is a typo in the long description of libcuba4. It talks about “libuba4-dev”, while I guess you meant “libcuba-dev”. — In debian/changelog, you should keep the three former entries corresponding to the previous version of the package. Keeping the whole history of the package will facilitate the long-term maintenance. See https://tracker.debian.org/media/packages/c/cuba/changelog-3.0%2B20111124-2 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: Bug#926330: RFS: cuba/4.2-1 [ITP]
Le vendredi 05 avril 2019 à 12:06 +0200, Francesco Montanari a écrit : > On 4/4/19 9:13 AM, Sébastien Villemot wrote: > > 2. Put the packaging on salsa.debian.org in the science-team group > > > https://salsa.debian.org/science-team > > >(you’ll need someone to create the project for you, once you have > > joined the group; I can do that if you want) > > Yes please, that'd great. (Just registered as fmnt-guest and requested > access.) Done: https://salsa.debian.org/science-team/cuba I granted you Maintainer access on that project. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFS: cuba/4.2-1 [ITP]
Dear Francesco, Le mercredi 03 avril 2019 à 17:22 +0200, Francesco Montanari a écrit : > Package: sponsorship-requests > Severity: wishlist > I am looking for a sponsor for my package "cuba" > > * Package name: cuba > Version : 4.2-1 > > Upstream Author : Thomas Hahn > * URL : http://www.feynarts.de/cuba/ > * License : LGPL-3+ > Section : math Since you CC’d this bug report to the debian-science mailing list, I guess that you’d like to have this package maintained within the team (BTW, you should have rather used the X-Debbugs-CC pseudo-header, so that we get informed of the bug number). If this is indeed your intention, you should: 1. Set the Maintainer field to: Debian Science Team (and put yourself in the Uploaders field) 2. Put the packaging on salsa.debian.org in the science-team group https://salsa.debian.org/science-team (you’ll need someone to create the project for you, once you have joined the group; I can do that if you want) 3. Subscribe to debian-science@lists.debian.org And more generally, you should follow the rules described in the Debian Science Policy: https://science-team.pages.debian.net/policy/ In particular, in the future, sponsorship requests should be done by simply sending an adequately formatted message to debian-science@l.d.o. 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: RFS: python-h5netcdf/0.7.1-1 [RC]
Le lundi 01 avril 2019 à 22:11 +0200, ghisv...@gmail.com a écrit : > I have just fixed the current RC affecting `python-h5netcdf` with an > update to its new upstream release. Uploaded, thanks. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFS: python-bayespy/0.5.18-1
Le dimanche 31 mars 2019 à 12:34 +0200, ghisv...@gmail.com a écrit : > I forgot to verify that `python-bayespy` had a new upstream release > during yesterday's BSP session. Could someone sponsor it please? Uploaded, thanks. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFS: python-ltfatpy/1.0.16-1 [RC]
Le dimanche 31 mars 2019 à 12:31 +0200, ghisv...@gmail.com a écrit : > I am currently fixing some bugs as part of the Paris BSP this weekend. > > I have just fixed pending issues affecting python-ltfatpy (including 1 > RC bug) and need someone to sponsor its upload. The only thing left is > to run `dch --release`, tag and submit. Uploaded, thanks. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFS: python-bayespy/0.5.11-2 [RC]
Le samedi 30 mars 2019 à 18:55 +0100, ghisv...@gmail.com a écrit : > I am currently fixing some bugs as part of the Paris BSP this > weekend. > > I fixed the pending issues (2 bugs including 1 RC) with python-bayespy > [1] and would need someone to sponsor it. The only thing left is to run > `dch --release` on it and submit. Uploaded, thanks. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Started working on OpenBLAS flavors: six variants in total
Hi Lumin, Le dimanche 10 février 2019 à 15:03 +, Mo Zhou a écrit : > I started working on the 6 variants of OpenBLAS: > > (32-bit, 64-bit) x (pthread, openmp, serial) > > The priorities of pthread, openmp, serial variants are 100, 99, 98 > respectively. > > The work-in-progress updates can be found in the "lumin" branch at > > g...@salsa.debian.org:science-team/openblas.git > > Binary package layout is the same as my latest proposal. > I'm basically imitating the packaging of BLIS for OpenBLAS. > > g...@salsa.debian.org:science-team/blis.git > > Apart from that, I think I'll stop introducing more BLAS64/LAPACK64 > candidate packages, for example I will not patch netlib blas into > a 64-bit verison. People who really need BLAS64/LAPACK64 doesn't > need a backend in poor performance. > > That means my expected list of BLAS64 providers is: > > BLIS, OpenBLAS, MKL > > And the expected list of LAPACK64 providers is: > > OpenBLAS, MKL > > When I finished updating OpenBLAS packaging, I'll write an > announcement > to d-devel-announce and update the wikipage accordingly. Next I'll > make julia compile against the 64-bit (pthread) version. > > What I said is not for Buster at all. I'll ping you again when > I think the "lumin" branch is ready to be reviewed/merged. Thanks for working on this. I did not look at the details, but the overall design looks good to me. Let’s talk again about it when Buster is released. > The first upload should go to experimental, and we will need a simple > transition: > > Good: .depends ~ /\b(libopenblas0)\b/ > Bad: .depends ~ /\b(libopenblas-base)\b/ > > where libopenblas-base is changed into a transitional dummy package. > It should be removed for Debian 12. Note that for a similar transition in the past (libblas3gf → libblas3), the Release Team declined to schedule rebuilds, since it’s not an ABI change (just a package renaming). Hence we had to wait for rebuilds to be gradually made over time through sourceful uploads. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://seb astien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Updates about BLAS64, co-installable variants
Le mardi 05 février 2019 à 03:34 +, Mo Zhou a écrit : > I'd like to update the proposal again. Alerted by the threading issue > about Octave+MKL, I changed my mind to make all variants co-installable > so any user would have a chance to switch them without installation/removal. > This proposal has been applied to BLIS (>= 0.5.1-8) already. > > I believe this version of layout looks far much better. Thanks. Indeed I also prefer the flat layout. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://seb astien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition
Control: retitle -1 octave: gives wrong results when used with MKL Le vendredi 01 mars 2019 à 01:41 +, Mo Zhou a écrit : > On Sun, Feb 03, 2019 at 12:07:20PM +, Mo Zhou wrote: > > It turns out that the incorrect matrix product is a result of > > gomp + iomp library clash: octave is linked against the GNU OMP, > > while libmkl-rt.so invokes Intel(LLVM) OMP by default. > > I got in touch with MKL team and they confirmed that the iomp+gomp > mixture is actually a very common error among users. They plan to > change > the loading mechanism of libmkl-rt for the 2020 production line, to > avoid iomp+gomp clash (sounds like yet another magic). > > So let's keep this bug open for both MKL and Octave for a while, > in case any other user came across similar errors. Maybe this > bug will be fixed in the late 2019 (they released MKL 2019 in late > 2018). Sounds good, thanks for the heads up. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline
Le samedi 09 février 2019 à 15:47 +, PICCA Frederic-Emmanuel a écrit : > What about creating a specific profile for this purpose ? Note that openblas and atlas already use DEB_BUILD_OPTIONS=custom for that purpose (but we could switch to another profile name). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition
Control: tags -1 unreproducible Dear Lumin, Le dimanche 03 février 2019 à 03:36 +, Mo Zhou a écrit : > Package: octave > Version: 4.4.1-4 > Severity: grave > > X-Debbugs-CC: debian-science@lists.debian.org, ido...@neto.net.il > > I received an astonishing bug report[1] saying that MKL returns wrong > result for matrix multiplication. However, my further investigation > suggests that the problem is very likely a threading bug of octave. > OpenMP is highly suspected according to my following experimental > results. I've tried to reproduce the problem with Netlib BLAS, OpenBLAS and BLIS, but without success (I did not try with MKL since I don't want such a large binary blob on my system). Basically you're suggesting that Octave's basic matrix multiplication functionality is utterly broken, without anybody else noticing. This is highly unlikely. Did you try to reproduce the problem on a pristine sid chroot, or another system? 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: blas wreckage ?
Le lundi 07 janvier 2019 à 11:53 +0100, Jörg-Volker Peetz a écrit : > running the appended little script on my system a lot of packages are found > which contain libraries linked to libopenblas.so.0. But all these packages > don't > declare a dependency on libopenblas-base. > This seems to me not o.k. > > Since libblas.so.3 from package libopenblas-base itself is linked to > libopenblas.so.0, I guess the linking to libopenblas.so.0 is expendable. > > Any idea? It looks like you are misled by ldd, which for some reason lists libopenblas.so.0 as an ELF dynamic dependency, while it is not actually needed (at least as a direct dependency). For example, liboctave6 appears in your list, and indeed ldd returns libopenblas.so.0 in the ELF dynamic dependencies when libopenblas-base is installed. But as soon as I remove openblas, that dependency disappears, and octave runs smoothly. So I think there is no bug here, only confusing output from ldd. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Updates about BLAS64
Le jeudi 03 janvier 2019 à 14:37 +, Mo Zhou a écrit : > On Thu, Jan 03, 2019 at 03:13:00PM +0100, Drew Parsons wrote: > > I'd say it's more common for non-coinstallable packages to be installed in > > subdirs (e.g. using DESTDIR facilities during configuration and build), and > > Theoretically yes, but in fact I don't want to make different variants > co-installable, particularly for BLIS. That's because the co-installbility > would result in 2 levels of alternatives system and make things complicated: > > something asks for libblas.so.3 > -> (looking for libblas.so.3 provider) > -> we found libblis.so.X > -> (looking for libblis.so.X provider) > -> we found the real libblis in some subdir. > > And I don't know if there is any user who wants to confuse themself > by installing all the variants and got no idea which on earth is > really used when they encountered some threading trouble. > > Such threadding trouble happend to OpenBLAS in history. > And mixing the usage of different threading library leads to nightmare. > > @Sébastien: What's your opinion at this point? I mean, what if we > are talking about the 6 variants of OpenBLAS? For sure I don't want 2 levels of alternatives, this would be too confusing for the user. However my first inclination would be to make all the variants co- installable, and have them all registered through the alternatives system. We provided this alternative system precisely to avoid people the hassle of installing/purging packages when switching between BLAS implementations. So, by the same logic, we should provide the same facility for switching between variants of a given implementation. Of course there would be a default variant (in the case of OpenBLAS, the pthread one) that would have the highest priority (and that would also probably be the first alternative in the metapackage dependency). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Updates about BLAS64
Le mardi 18 décembre 2018 à 15:12 +, Mo Zhou a écrit : > On Tue, Dec 18, 2018 at 12:42:22PM +0100, Sébastien Villemot wrote: > > > BTW, what is the "-base" (in libopenblas-base) supposed to mean? > > > > I don't even remember what it means, but it is clearly a legacy from > > the past. Ideally the package should be named "libopenblas0". But I did > > not bother with transitioning from one to the other, since it is rather > > tedious, with strictly zero benefit for users. > > Then it's a good chance for us to get rid of it, when modifying the > package layout. We can avoid a transition if we turn the old pacakges > into meta packages. I still prefer my proposed package layout, i.e. > > libopenblas0 (meta): > deps: libopenblas0-openmp | libopenblas0-pthread | ... > libopenblas-base (meta, because it cannot be safely removed): > deps: libopenblas0 > libopenblas0-openmp: > conflicts: libopenblas0-pthread, ... > > libopenblas-dev (meta): > deps: libopenblas0, > libopenblas-openmp-dev | libopenblas-pthread-dev | ... > libopenblas-openmp-dev: > conflicts: libopenblas-pthread-dev, ... > > Such layout has several advantages: > > 1. compared to (libopenblas0 i.e. pthread version, libopenblas0-openmp), > the (libopenblas0-openmp, libopenblas0-pthread) layout is more >explicit and tidy. > > 2. we can control the default openblas implementation by adjusting > the dependency of libopenblas0 (meta) and libopenblas-dev (meta). >And maintainers of reverse dependencies won't have the headache to >choose one from (openmp, pthread, ...) > > 3. won't break packages that depend on libopenblas-base Ok, I think you convinced me. Note that we also want a libopenblas0-serial. (I'm CC'ing #878121 so that we don't forget this layout proposal for OpenBLAS). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFS: numexpr v2.6.9
Le dimanche 30 décembre 2018 à 11:06 +0100, Antonio Valentino a écrit : > Dear Sébastien, > thank you for looking at the numexpr package. > > Il 30/12/18 09:57, Sébastien Villemot ha scritto: > > > Le vendredi 21 décembre 2018 à 08:22 +0100, Antonio Valentino a écrit : > > > I prepared an updated debain package for the new upstream version of > > > numexpr (2.6.9-1). > > > > > > It is available on git [1] and on mentors [2]. > > > > > > Please consider to upload. > > > > I got a look at your prepared upload. > > > > Unfortunately, it failed to build, with: > > > > dh_builddeb -O--buildsystem=pybuild > > dpkg-deb: error: failed to open package info file > > 'debian/python-numexpr/DEBIAN/control' for reading: No such file or > > directory > > dpkg-deb: error: failed to open package info file > > 'debian/python3-numexpr/DEBIAN/control' for reading: No such file or > > directory > > dpkg-deb: error: failed to open package info file > > 'debian/python-numexpr-dbg/DEBIAN/control' for reading: No such file or > > directory > > dpkg-deb: error: failed to open package info file > > 'debian/python3-numexpr-dbg/DEBIAN/control' for reading: No such file or > > directory > > > > I guess this has to do with your recent changes to debian/control? > > no, it was a change in the rules file. > I have just reverted it. > > > Also, there are two other issues to be fixed: > > > > – please merge the last two changelog entries, it does not make sense > > to create 2.6.9-2 when 2.6.9-1 has not been uploaded > > ok, done > > > – in the copyright files, there are open-ended copyright years interval > > (in the main stanza and in the debian/*). I don't think this makes > > sense from the perspective of copyright legislation. You should put > > real years there (i.e. close the interval with 2018). > > done. > > > All changes are now available in git [1]. Thanks, uploaded. Note that I pushed a minor fix to the changelog (I removed the entry that has been reverted). 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: RFS: numexpr v2.6.9
Dear Antonio, Le vendredi 21 décembre 2018 à 08:22 +0100, Antonio Valentino a écrit : > I prepared an updated debain package for the new upstream version of > numexpr (2.6.9-1). > > It is available on git [1] and on mentors [2]. > > Please consider to upload. I got a look at your prepared upload. Unfortunately, it failed to build, with: dh_builddeb -O--buildsystem=pybuild dpkg-deb: error: failed to open package info file 'debian/python-numexpr/DEBIAN/control' for reading: No such file or directory dpkg-deb: error: failed to open package info file 'debian/python3-numexpr/DEBIAN/control' for reading: No such file or directory dpkg-deb: error: failed to open package info file 'debian/python-numexpr-dbg/DEBIAN/control' for reading: No such file or directory dpkg-deb: error: failed to open package info file 'debian/python3-numexpr-dbg/DEBIAN/control' for reading: No such file or directory I guess this has to do with your recent changes to debian/control? Also, there are two other issues to be fixed: – please merge the last two changelog entries, it does not make sense to create 2.6.9-2 when 2.6.9-1 has not been uploaded – in the copyright files, there are open-ended copyright years interval (in the main stanza and in the debian/*). I don't think this makes sense from the perspective of copyright legislation. You should put real years there (i.e. close the interval with 2018). 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: hwloc and openblas backports for AMD Zen
Le mercredi 19 décembre 2018 à 04:14 +, Mo Zhou a écrit : > I think backporting openblas is possible, and it won't require much > work. Recently I've worked on some similar packages. intel-mkl has > been backported to stable but I suspect whether MKL's performance > is guaranteed on AMD CPUs. Another new BLAS library called BLIS > is waiting in the NEW queue, which ships AMD Zen CPU support. > > I CC'ed Sébastien in case he didn't subscribe to the backports list. > Science team is also CC'ed because we're talking about BLAS. I'm personally not interested in backporting openblas. But if someone wants to create it and maintain it until stretch is EOL, please go ahead. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Updates about BLAS64
Le dimanche 16 décembre 2018 à 09:34 +, Mo Zhou a écrit : > On Sun, Dec 16, 2018 at 09:15:03AM +0100, Sébastien Villemot wrote: > > > src:blis > > > bin:libblis1 (meta) > > > deps: libblis1-openmp | libblis1-pthread | libblis1-serial > > > provides: libblas.so.3 > > > bin:libblis64-1 (meta) > > > deps: libblis64-1-openmp | ... > > > provides: libblas64.so.3 > > > ... > > > > > > Note that BLIS doesn't provide LAPACK implementation. > > > > > > @Sebastian: Does this look good to OpenBLAS? > > > > I don't understand what your actual question is. Could you be more > > specific? > > Sorry for the misspelling of name. > > My question is, does it look good if we update OpenBLAS to provide > similar set of binary packages? i.e. > > src: openblas > > bin: libopenblas-base (meta) > deps: libopenblasX-openmp | libopenblasX-pthread, > bin: libopenblasX-openmp > conflict: libopenblasX-pthread > bin: libopenblasX-pthread > conflict: ... > bin: libopenblas-dev (meta) > deps: libopenblas-base > bin: libopenblas-openmp-dev > deps: libopenblasX-openmp > conflict: libopenblas-pthread-dev > bin: libopenblas-pthread-dev > deps: libopenblasX-pthread > conflict: libopenblas-openmp-dev > > bin: libopenblas64-base (meta) > [...omitted...] > bin: libopenblas64-dev (meta) > [...omitted...] I am not entirely convinced that meta-packages are needed. Isn't the "Provides: libblas.so.3" not enough? The main OpenBLAS package could actually remain the pthread version, as it is now, and there would be two new packages, for the OpenMP and the single threaded ones. > As we know, NEW packages such as BLIS are good candidates experiments > without risking to break existing packages such as OpenBLAS. So if the > way we compile BLIS is proved working, we can also apply it to OpenBLAS. That is a good idea. As a matter of fact, I think we are now too close from the freeze to start modifying the layout for OpenBLAS; let's wait for the Bullseye cycle. > BTW, what is the "-base" (in libopenblas-base) supposed to mean? I don't even remember what it means, but it is clearly a legacy from the past. Ideally the package should be named "libopenblas0". But I did not bother with transitioning from one to the other, since it is rather tedious, with strictly zero benefit for users. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Is there any plan to make python3-getfem++ package?
Dear Tetsuo, Le dimanche 16 décembre 2018 à 21:06 +0900, Tetsuo Koyama a écrit : > Hello. My name is Tetsuo Koyama and I'm a user of python-getfem++ user > in Debian package. > I want to know that is there any plan to make python3-getfem++ Debian > packages? > I could compile Getfem++ Python3 interface, but I think it is useful > if it can be installed by apt or aptitude. > > Sorry I don't have a knowledge to release Debian package.If you could > give me some advise, I would do it myself. My advice would be to start by filing a (wishlist) bug against getfem++, asking for the Python 3 package. This will not magically do the work, but at least the issue will be properly tracked. 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: Updates about BLAS64
Le dimanche 16 décembre 2018 à 01:51 +, Mo Zhou a écrit : > Some time ago we discussed about packages for BLAS64 ABI/API. > Here are some updates about the subsequent works: > > * blas64 and lapack64 symlinks and alternatives have been added to intel-mkl. > > src:intel-mkl > bin:libmkl-rt > enhances: libblas.so.3, libblas64.so.3, liblapack.so.3, > liblapack64.so.3 > alternative: libblas64.so.3 -> libmkl_rt.so > liblapack64.so.3 -> libmkl_rt.so > ... > bin:libmkl-dev > enhances: libblas64.so, liblapack64.so, ... > alternative: libblas64.so -> libmkl_rt.so > liblapack64.so -> libmkl_rt.so > > * A new BLAS implementation called BLIS[1] is nearly ready to upload. > This is likely the first package that will provide 64bit BLAS API/ABI > in main section of our archive. > > BLIS supports three different threading models, just like openblas. > The difference is that, BLIS will be compiled 6 times with different > configurations: > > (openmp, pthread, serial) x (32-bit, 64-bit) = 6 combinations > > BLIS shared libraries with different threading models and the same > index length cannot coexist. Any 32-bit lib can co-exist with any > 64-bit one. > > src:blis > bin:libblis1 (meta) > deps: libblis1-openmp | libblis1-pthread | libblis1-serial > provides: libblas.so.3 > bin:libblis64-1 (meta) > deps: libblis64-1-openmp | ... > provides: libblas64.so.3 > ... > > Note that BLIS doesn't provide LAPACK implementation. > > @Sebastian: Does this look good to OpenBLAS? I don't understand what your actual question is. Could you be more specific? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: HELP needed for uploading a new debianisation of the Rheolef package
Le lundi 29 octobre 2018 à 21:10 +0100, Pierre Saramito a écrit : > I just commit with git a new release 7.0-2 of the debianisation > of the rheolef package: it fixes a FTBS bug #897846 (see > d/changelog). > > The upstream version is unchanged (7.0). > > Could you please upload it in debian ? I have just uploaded rheolef 7.0-2. Thanks for your work. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK
Le mardi 23 octobre 2018 à 14:12 +, Mo Zhou a écrit : > On Mon, Oct 22, 2018 at 07:58:38PM +0200, Bastian Blank wrote: > > On Mon, Oct 22, 2018 at 07:55:10PM +0200, Sébastien Villemot wrote: > > > For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they > > > will be compiled using LP64, and not ILP64. Only integers exposed > > > through the interface will be affected, through the use of appropriate > > > types. > > > > So you could also to a proper library transition and drop the support > > for 32-bit indicies completely? > > Completely dropping 32-bit-index version of BLAS/LAPACK for 64-bit > architectures is a long way to go. We can keep 32-bit-index version and > 64-bit-index version at the same time for a while and see if the > 32-bit-version is really droppable. > > This reminds me two points about wheter the 32-bit-index version is > droppable. As far as I know, Debian (will) have these BLAS[1] providers: > > (1) bin:libblas3 from src:lapack > (2) bin:libatlas3-base from src:atlas > (3) bin:libopenblas-base from src:openblas > (4) bin:libblis1 from src:blis [WIP] > (5) bin:libmkl-rt from src:intel-mkl [non-free] > (6) bin:libnvblas9.1 from src:nvidia-cuda-toolkit [non-free] [2] > > * I confirm these providers support 64-bit index in the API. > (2) (3) (4) (5) > > @Sebastien could you please confirm the status of 64-bit-index support > in lapack, i.e. (1) ? Since the BLAS and LAPACK implementations provided by src:lapack are pure Fortran code, my understanding is that it's just a matter of compiling them with -fdefault-integer-8 to get 64-bit indexing. This package also provides C interfaces (resp. CBLAS and LAPACKE). LAPACKE provides the necessary type aliases to get 64-bit indexing. Curiously, CBLAS does not seem to have that flexibility, and will probably need some (reasonably simple) patching. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK
Le mardi 23 octobre 2018 à 14:17 +, Mo Zhou a écrit : > Two in the audience are object to the "-ilp64" naming convention. > Then how about this? > > src:openblas > bin:libblas-base (...) > bin:libblas-dev(...) > bin:libblas64-base (filename=libblas64.so.3, SONAME=libblas64.so.3, > provides=libblas64.so.3-x86_64-linux-gnu) > bin:libblas64-dev (...) Adding a "64" suffix to the package name and to the SONAME (compared to the 32-bit indexing version) sounds good to me. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK
Le lundi 22 octobre 2018 à 18:38 +0100, Simon McVittie a écrit : > On Mon, 22 Oct 2018 at 18:17:32 +0100, Ben Hutchings wrote: > > On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote: > > > Here are some references: > > > > > > 1. > > > https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-ilp64-interface-vs-lp64-interface > > > > > > The Intel MKL ILP64 libraries use the 64-bit integer type (necessary > > > for indexing large arrays, with more than 231-1 elements), whereas > > > the LP64 libraries index arrays with the 32-bit integer type. > > > > [...] > > > > The correct C types for indexing arrays are ptrdiff_t and size_t. > > These are already 64-bit in LP64 ABIs. So this seems like a workaround > > for code using the wrong types. > > Do BLAS/LAPACK really mean ILP64, or do they really mean "ABI with large > array indexes"? The latter. This is why I think that "ILP64" is a misnomer, and should not be used for labeling the newly introduced libraries. The ambiguity arises from the fact that some BLAS/LAPACK implementations are written in Fortran, and use the default integer type for array indexes. Hence the solution is to compile them with -fdefault-integer-8. But this does not mean that this code is really ILP64, because it's not C and hence it does not uses the C ABI. Only integers exposed through the BLAS/LAPACK ABI are affected (most of them are array indices, the remaining others are return codes). For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they will be compiled using LP64, and not ILP64. Only integers exposed through the interface will be affected, through the use of appropriate types. 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: updated vspline package data to upstream version 0.4.1
Dear Kay, Le lundi 08 octobre 2018 à 10:21 +0200, Kay F. Jahnke a écrit : > After roughly one year of tweaking, I've settled on vspline 0.4.1 as a > version which I'd like to release to debian. […] > I hope my updates to the package data are all as they should be, and I'd > like to ask you, Sébastien, to take a look and, if everything is well, > build and upload the package. If anything is amiss, please let me know. I uploaded the package (after fixing a typo in debian/control). Thanks for your contribution, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: O: double-conversion -- routines to convert IEEE floats to and from strings
Le dimanche 19 août 2018 à 03:06 +, Lumin a écrit : > On Sat, Aug 18, 2018 at 07:23:48PM +0200, Sébastien Villemot wrote: > Le samedi 18 août 2018 à 15:16 +, Lumin a écrit : > libtensorflow.so FTBFS with double-conversion 3.0.0 so I need a > snapshot > version of double-conversion. Updated package has been prepared in a > separate branch: > > g...@salsa.debian.org:science-team/double-conversion.git > - lumin/3.0.0 > > Dom-amd64: > experimental: http://debomatic-amd64.debian.net/distribution#experim > ental/double-conversion/3.0.0+git20180802.4e8b3b5-1/buildlog > cosmic: http://debomatic-amd64.debian.net/distribution#cosmic/double > -conversion/3.0.0+git20180802.4e8b3b5-1u1/autopkgtest > > PPA: > https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages > > I haven't checked API, but there is no ABI bump. Should I ask for a > transition slot and bump ABI anyway? If you are sure that there is no ABI and API breakage, then no need for a transition slot, and you can go ahead. If you are not sure, then you should check the ABI (for example with a tool like abi-compliance-checker), and also verify that all reverse dependencies still compile correctly. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Re: O: double-conversion -- routines to convert IEEE floats to and from strings
Hi Lumin, Le samedi 18 août 2018 à 15:16 +, Lumin a écrit : > double-conversion is a tensorflow dependency and surprisingly it was > orphaned. I will continue maintaining it within d-science team. Great! > However, in order to avoid embedding a copy of double-conversion source > code in tensorflow source package, may I upload a snapshot[1] version of > double-conversion specified by tensorflow? Then I only need to embed a > copy of eigen3. You should probably check with reverse dependencies that it's ok to package a snapshot. In particular, Qt5 depends on double-conversion, so you should handle this package with care. 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: Sundials lagging behind upstream
On Tue, Jun 19, 2018 at 06:51:02PM -0700, Dima Kogan wrote: > Sébastien Villemot writes: > > > On Sat, Jun 16, 2018 at 10:16:18PM -0700, Dima Kogan wrote: > > > >> These packages are not perfect, but I think they're good-enough to push. > >> So I just pushed them to the archive. They still need to clear NEW, so > >> don't expect them to be installable TOMORROW, but soon. > > > > I have just seen that you uploaded sundials 3.1 to unstable, without > > coordinating the transition. Now this is getting untangled with the octave > > transition, and I see that sundials FTBFS on several archs. Sigh. > > > > Next time, please upload first to experimental, and at least coordinate with > > maintainers reverse dependencies. > > Yes. Right. I haven't had to think about transitions in the past, and > this clearly shows why I should in the future. Sorry. > > I looked at the sundials FTBFS; looks like some subset of tests is > timing out on some arches. I'll look into it. Is there anything in > particular I should do to make octave happy again in the near term? Thanks for your feedback. For Octave there are two options: either leave it as it is, but then the Octave transition becomes dependent on Sundials (i.e. Octave 4.4 will migrate to testing only when Sundials 3.1 does, and in particular this means that sundials build failures must be fixed soon); or I can simply temporarily remove the (build-)dependency of Octave on Sundials. Note that I could actually do the latter, because it turns out that Octave 4.4 is not (yet) compatible with Sundials 3.1. So no rush on your side anyways. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Sundials lagging behind upstream
On Sat, Jun 16, 2018 at 10:16:18PM -0700, Dima Kogan wrote: > These packages are not perfect, but I think they're good-enough to push. > So I just pushed them to the archive. They still need to clear NEW, so > don't expect them to be installable TOMORROW, but soon. I have just seen that you uploaded sundials 3.1 to unstable, without coordinating the transition. Now this is getting untangled with the octave transition, and I see that sundials FTBFS on several archs. Sigh. Next time, please upload first to experimental, and at least coordinate with maintainers reverse dependencies. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: new upstream version of PyTables
Hi Antonio, On Sun, Jun 17, 2018 at 05:10:06PM +0200, Antonio Valentino wrote: > Il 17/06/2018 10:09, PICCA Frederic-Emmanuel ha scritto: > > what about becoming DM this way we could grant your the right to upload > > your packages directly into Debian :). > > > > It would be very nice, thank you for proposing that. > > Unfortunately at the moment I do not have "a strong (>= 2048 bit > required; 4096 bit recommended) RSA GnuPG key (see line above) and it > must be signed by at least one (but ideally more than one) Debian > Developers" [1]. > So I cannot apply at the moment or in the near future. What about generating a new key and looking for a DD to sign it? There are many DDs offering key signing, especially in Italy (where I guess you live): https://wiki.debian.org/Keysigning/Offers Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Freecad is looking for new maintainers
Hi Anton, On Wed, May 23, 2018 at 11:17:35PM +0200, Anton Gladky wrote: > freecad_0.16.6712+dfsg1-2 has just been uploaded and > two of its maintainers (me and Teemu) decided not to maintain > this package any more. Adam, which is currently the only > one in "Uploaders"-field seems to be not active for a long time. > > I am not orphaning the package because it is team-maintained. > But it would be good if somebody could take over the package. IMO, it's better to orphan the package, to make it clear that it has no active maintainer. Otherwise that critical piece of information may go unnoticed for a long time by third parties, including potentially interested maintainers. And this doesn't prevent the future maintainer from keeping it in Debian Science. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sun, May 06, 2018 at 08:29:29AM +, Lumin wrote: > > He put forward a simpler solution: Just don't provide libblas.so.3, such > > that MKL will never be used to satisfy the dependency of libblas.so.3 . > > Based on his idea, my new solution is the follows: > > > > libmkl-rt -- > > Depends: libblas3 | libblas.so.3 > > Provides: NOTHING ... (4) > > > > So it's totally safe now. If there is MKL, there must be a free > > libblas.so.3 implementation with a priority definitely larger than 1, > > overriding MKL in terms of auto-mode alternatives. On the other hand, > > if that alternative is manually set, then there is nothing to worry > > about. This solution is also able to resolve problems found in (1) and (3). > > Now libmkl-rt doesn't provide libblas.so.3 and liblapack.so.3, and it > pre-depends on libblas3 | libblas.so.3 and liblapack3 | liblapack.so.3 . > Similar change was applied to libmkl-dev. Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2: Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress. You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached. See Dependencies. I also think that removing the Provides is not a good idea. The alternative is provided by the package, and that should be made clear in the dependency relationships. I'm sorry but I don't have an ideal solution to the problems we previously discussed. But IMO it's acceptable to not perfectly deal with the corner case where only MKL is installed, as long as some warning is displayed. > Previously Sébastien expressed his interest on benchmarking. I'm > interested in that too. So apart from the debconf part, I wrote a simple > benchmarker[4] in Julia[5] for comparing several BLAS implementations. > Thanks to Julia's convenient FFI functionality, I can test all > implementations within a single run, without any modification to environment > variable or alternatives. > > Test result on my laptop (CPU=i5-7440HQ) matches expectation: > > dnrm2 Julia > 0.33 seconds > dnrm2 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0 > 0.74 seconds (3 allocations: 48 bytes) > dnrm2 Error :1.1368683772161603e-13 > dnrm2 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 > 0.38 seconds (3 allocations: 48 bytes) > dnrm2 Error :0.0 > dnrm2 /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so > 0.31 seconds (3 allocations: 48 bytes) > dnrm2 Error :0.0 > dnrm2 /usr/lib/x86_64-linux-gnu/libmkl_rt.so > 0.029561 seconds (3 allocations: 48 bytes) > dnrm2 Error :0.0 > dgemm Julia > 4.362279 seconds (2 allocations: 128.000 MiB, 0.20% gc time) > dgemm /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0 > 47.893710 seconds (10 allocations: 160 bytes) > dgemm Error :2.0735139719127268e-10 > dgemm /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 > 10.412422 seconds (10 allocations: 160 bytes) > dgemm Error :2.4175670445887973e-11 > dgemm /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so > 1.211220 seconds (10 allocations: 160 bytes) > dgemm Error :2.770610675980814e-11 > dgemm /usr/lib/x86_64-linux-gnu/libmkl_rt.so > 1.103356 seconds (10 allocations: 160 bytes) > dgemm Error :2.7982744719588258e-11 > > Netlib is always the slowest one. For small matrices OpenBLAS is > very competitive. For large matrices MKL is the fastest. Thanks, this is an interesting data point. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: New upstream release: numexpr 2.6.5
On Sun, May 06, 2018 at 12:21:28PM +0200, Antonio Valentino wrote: > I prepared the debian package for the new upstream version of numexpr: > 2.6.5 [1,2]. > It would be nice if you could upload it. Uploaded, thanks. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Bug#897238: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sun, May 06, 2018 at 08:00:53AM +, Lumin wrote: > On Wed, May 02, 2018 at 10:03:38AM -0500, Dirk Eddelbuettel wrote: > > > > On 2 May 2018 at 14:41, Lumin wrote: > > | Seems that things are getting more complicated. Recall that here we'are > > | going to prevent users from GPL violation in situations such as this > > | one: > > | > > | debootstrap; apt install libmkl-rt; apt install octave; octave ... (1) > > > > Are you sure? I do not think that is correct. Downloading and installating > > MKL, and running it with R or Octave (or any other package linking the BLAS > > interface) does not constitute a GPL violation AFAIK. > > Not sure. I admit that I'm not good at long licences such as GPL. > Whether it violates GPL or not, what we do in config/postinst won't > change: make sure it's the user's explicit choice to use MKL as the > default BLAS/LAPACK implementation, and in contrast, MKL will not be > used without the explicit choice. > > > (There may well be limitations on further redistribution of the aggregate > > even though even the MKL now limits redistribution as it is of course still > > a > > no-source-code piece of software.) > > Intel's ISSL license allows redistribution, as long as no file is > changed. Yes, but it’s the GPL that forbids distribution of a binary linking together GPL code and non-free code. I’m not entirely sure whether it is legal to locally have such a binary on your hard drive, that you would not redistribute (but anyways nobody will know). The problem is that, by providing GPL'd software (e.g. GNU Octave), MKL and a way to dynamically link the two together, one may consider that Debian is distributing such an binary and therefore violating the GPL. So at the very least we must clearly warn the user about that risk and not have MKL the default BLAS implementation. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: [RFS] librecad/2.1.3 version (one month waiting for revision and upload)
On Fri, May 04, 2018 at 05:25:38PM +0200, Innocent De Marchi wrote: > > Thanks, I have made the upload (with two extra commits, one for > > fixing the watch file which was broken, and the other one for > > removing the obsolete get-orig-source rule). > > Oops! I did not realize the problem with watch file. The thing about > get-orig-source I saw it but I thought it could be removed on another > occasion. Actually it looks like my fix for the debian/watch file was incorrect (it returns a version with a path), sorry for that. You may want to fix it in a later upload (taking inspiration from the examples given in uscan(1) manpage for github repos). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: RFS: texmaker/5.0.2-2 [fixes RC bug]
Dear Philipp, On Thu, May 03, 2018 at 06:13:49PM +0200, Philip Rinn wrote: > I was just hit by texmaker crashing on start and fixed it right away :-) > > Could someone with upload rights please review and upload? > texmaker (5.0.2-2) unstable; urgency=medium > > * Team upload. > * d/patches: fix crash with new libsynctex (fixes: #896656, #897071) > + Add 60-fix-for-new-libsynctex1-API.patch to fix crash on startup > * Update Vcs URLs in d/control to point to salsa.d.o > > -- Philip Rinn Thu, 03 May 2018 17:36:23 +0200 Shouldn't you also close #896567 ? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: [RFS] librecad/2.1.3 version (one month waiting for revision and upload)
On Thu, May 03, 2018 at 07:54:45PM +0200, Innocent De Marchi wrote: > > > > In any case, it's no problem for me to keep their names. > > > > > > Since they have not asked to be removed, and unless they are MIA > > > (Missing in Action), you should keep their names (adding yours as a > > > third one). Removing them in this context would be rude. > > > > > > Done! Thanks, I have made the upload (with two extra commits, one for fixing the watch file which was broken, and the other one for removing the obsolete get-orig-source rule). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Fw: [RFS] librecad/2.1.3 version (one month waiting for revision and upload)
On Wed, May 02, 2018 at 05:09:49PM +0200, Innocent De Marchi wrote: > > I actually sent a message about your sponsorship request, but you > > never replied: > > > > https://lists.debian.org/debian-science/2018/04/msg00016.html > > > > Sorry! I just have not seen this message: I'm subscribed to the list, > and to the game team, and to debian-devel ... > > There are so many emails, that, simply, I think I should have deleted > the email without realizing that it was about librecad. That’s fine, no worry. > I sent an email [0] to the list (with a copy to Scott Howard and Ruben > Molina) about my intention to update the package. They have not > answered the mail (maybe they have not read it as it has happened to > me). > > I have updated some packages in the games team and I have > followed the same procedure with the field debian/uploaders field. > > In any case, it's no problem for me to keep their names. Since they have not asked to be removed, and unless they are MIA (Missing in Action), you should keep their names (adding yours as a third one). Removing them in this context would be rude. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Tue, May 01, 2018 at 12:14:17PM +, Lumin wrote: > Since libmkl-rt Provides libblas.so.3, it is not totally safe even > if we set its priority to 1. That's because MKL will still be selected > when there is only one libblas.so.3 provider, namely MKL. Due to > this reason, I appended libopenblas-base as a dependency of libmkl-rt, > so that MKL will never be selected by update-alternatives in auto mode. > (I'm not sure what will happen if a package which provides libblas.so.3 > and also depends libblas.so.3 . Let me simply depend on openblas > instead.) I had overlooked this corner case, thanks. It should be however very rare, because all packages that depend on a BLAS/LAPACK implementation use something like "Depends: libblas3 | libblas.so.3" (i.e. a concrete package before the virtual one). But it can indeed happen if the user first selects MKL then the depending package. I think depending on openblas is a bit weird. If the users reply "no" and MKL is the only alternative available, then I'd rather display a debconf message warning the user about the situation. The test about MKL being the only option could be something like: if [ $(update-alternatives --query libblas.so.3-@DEB_HOST_MULTIARCH@ | grep ^Alternative: | wc -l) = 1 ] > Current HEAD is 2ce1edd8cc57ed87c080edccd36456bb9953fd22. > I haven't test the new postinst script yet. Thanks. There is a small bug: in both libmkl-rt.postinst.in and libmkl-dev.postinst.in, when the users reply "no", you put both BLAS and LAPACK alternatives in auto mode if MKL was selected for BLAS. You should rather split that in two tests: one for BLAS, one for LAPACK, because in theory it's possible to have BLAS pointing to MKL and not LAPACK. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
OBOn Mon, Apr 30, 2018 at 05:49:16PM +0200, Sébastien Villemot wrote:
> On Mon, Apr 30, 2018 at 03:31:29PM +, Lumin wrote:
>
> > Four symbol links are installed to usr/lib/${DEB_HOST_MULTIARCH}/mkl/
> > directory, see [2][3]. Using ld.so environt variable to switch
> > blas/lapack is documented in README.Debian [4].
>
> Reading that README.Debian, I realize that your implementation of the debconf
> prompt changes the priority to 50. This is not what I had in mind. I think
> that
> the priority should be left unchanged if the user answers yes to the prompt,
> but in that case the postinst script would manually select the MKL alternative
> using an extra command:
>
> update-alternatives --set libblas.so.3-@DEB_HOST_MULTIARCH@
> /usr/lib/@DEB_HOST_MULTIARCH@/libmkl_rt.so
>
> (and similarly for other alternative groups)
And, if the user replies no, then the script should put back the alternative in
automatic mode if it was previously pointing on MKL. This could be done with:
if [ $(update-alternatives --query libblas.so.3-@DEB_HOST_MULTIARCH@ | grep
^Value: | cut -d ' ' -f 2) = /usr/lib/@DEB_HOST_MULTIARCH@/libmkl_rt.so ]; then
update-alternatives --auto libblas.so.3-@DEB_HOST_MULTIARCH@
fi
In this way, the script will work as expected:
- if MKL was not already selected and the user says no, the setting will be
left untouched (either in automatic or manual mode, depending on the user
customization)
- if MKL was already selected and the user says no (e.g. after a reconfigure),
then MKL will be unselected (and the BLAS with the highest priority will
become the current alternative)
- if the user says yes, MKL is selected (while with your actual code, if the
alternative was in manual mode, then MKL would still be unselected even with
priority 50)
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: PGP signature
Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Mon, Apr 30, 2018 at 03:31:29PM +, Lumin wrote:
> Four symbol links are installed to usr/lib/${DEB_HOST_MULTIARCH}/mkl/
> directory, see [2][3]. Using ld.so environt variable to switch
> blas/lapack is documented in README.Debian [4].
Reading that README.Debian, I realize that your implementation of the debconf
prompt changes the priority to 50. This is not what I had in mind. I think that
the priority should be left unchanged if the user answers yes to the prompt,
but in that case the postinst script would manually select the MKL alternative
using an extra command:
update-alternatives --set libblas.so.3-@DEB_HOST_MULTIARCH@
/usr/lib/@DEB_HOST_MULTIARCH@/libmkl_rt.so
(and similarly for other alternative groups)
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
On Sun, Apr 29, 2018 at 09:18:08AM +0800, Drew Parsons wrote:
> The discussion raises a separate question. Suppose the administrator
> does make OpenBLAS the preferred alternative for the system, but an
> individual user prefers to use IntelMKL. How should the user configure
> this (for the generic blas.so.3 symbols, not recompiling explicitly
> against the specific library) ? Set up symlinks in a local dir and
> point to that dir with LD_LIBRARY_PATH ?
Using LD_LIBRARY_PATH is indeed the easiest way to switch between BLAS
implementations on a per-user basis (since each one of them has a specific
subdir under /usr/lib/${DEB_HOST_MULTIARCH}/). So the same should probably be
done for MKL.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
Dear Lumin, On Sun, Apr 29, 2018 at 07:28:20AM +, Lumin wrote: > > I agree, debconf configuration is a good compromise. > > Thank you everyone for your attention. I agree to use debconf > too and it looks like the best solution to the disagreements > in previous discussions. The mechanism was implemented in > the packaging lately. > > The user will be asked whether he/she wants to use libmkl_rt.so > as an alternative to libblas.so.3 and liblapack.so.3 [1][2], > and the db_input importance is set to critical. Default option > is false. By default, or if user rejects this proposal, the > lowest priority will be assgined to libmkl-rt [3]. > Another reason why default is set to false is because we > have to also consider about the users who don't know what > they are doing, and the users who don't know what MKL is at all. Thanks for implementing this. I think this is a reasonable compromise. Maybe the wording about license violations could be slightly improved. I suggest the following for replacing the 2nd paragraph of the debconf prompt: However, MKL is non-free software, and in particular its source code is not publicly available. By using MKL as the default BLAS/LAPACK implementation, you might be violating the licensing terms of copyleft software that would become dynamically linked against it. Please verify that the licensing terms of the program(s) that you intend to use with MKL are compatible with the MKL licensing terms. For the case of software under the GNU General Public License, you may want to read this FAQ: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs > In the original post I proposed to also set it as alternative to > libblas.so/liblapack.so . However this is problematic since > MKL is a superset which not only includes BLAS/LAPACK symbols > but also many other MKL-specific symbols. To avoid accidents > or problematic usage such as an ELF being linked at symbols > which exist in MKL, (e.g. #include , gcc ... -lblas -llapack) > but not the other BLAS implementations, I changed my mind > and decided to do nothing with libblas.so / liblapack.so . Note that ATLAS and OpenBLAS have similar issues: they export symbols that are not in the BLAS ABI, but are nevertheless registered as libblas.so alternative. My assumption has been that, if someone links with -lblas, then he is only asking for the BLAS ABI and not more. If someone wants to link against symbols specific to ATLAS/OpenBLAS, then he should link against -latlas/-lopenblas. So, for consistency, I think it is ok to register MKL as providing libblas.so/liblapack.so. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: [RFS] librecad/2.1.3 version (one month waiting for revision and upload)
Dear Innocent, On Sun, Apr 29, 2018 at 09:26:48AM +0200, Innocent De Marchi wrote: > Hi everyone, > > It seems that nobody is available to review and upload the new version > of the librecad package [0]. I actually sent a message about your sponsorship request, but you never replied: https://lists.debian.org/debian-science/2018/04/msg00016.html This time I’m putting you in CC in case you’re not subscribed to the list (but you’re supposed to be unless you tell otherwise). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
OBOn Sat, Apr 28, 2018 at 02:35:29PM -0500, Dirk Eddelbuettel wrote: > > On 28 April 2018 at 11:56, Dima Kogan wrote: > | Andreas Tille writes: > | > | > On Fri, Apr 27, 2018 at 06:36:51PM +0200, S?bastien Villemot wrote: > | > > | >> There is also a licensing issue: using GPL'd software (e.g. GNU > | >> Octave) with MKL is not allowed. > | > > | > I think that's a pretty strong reason to rate non-free software lowest > | > in the alternatives. Packaging useful non-free software is fine but > | > ranking it higher than free alternatives seems in contrast with our > | > social contract. Users who want to use it should be able to handle > | > alternatives system. > | > | I really would like to see MKL having the highest priority. > | > | Is the licensing issue only there when any other components being linked > | are licensed under the GPL? If so, we need to either > | > | 1. actually handle this issue to make the link fail in cases of license > |violations > | > | 2. not ship MKL at all > | > | 3. decide that the user is sophisticated-enough to manually figure this > |out > | > | Currently we're on the path to option 3. non-free repos are already > | opt-in, and the user already needs to do manual work to get them. If > | they have done this manual work, that's plenty of an indication that > | they have decided that license purity isn't a priority for them. > | > | If I was a user who manually added the non-free repos and then manually > | installed the mkl libraries, I'd be aggravated to find out that there's > | yet another hoop I need to jump through to actually use these libraries. > | This would be a waste of my time, especially since I have already taken > | actions to clearly indicate that I want MKL. > | > | We can decide that we're not interested in providing a license-impure > | option, but then we shouldn't be providing a non-free, and we don't need > | to rehash that argument. > > Seconded. > > Going through all this work to end up with a priority below all alternatives > is absurd. It effectively _hides_ the MKL. > > Remember "our priority are our users" ? If we decide to build and ship this > within the project (even via non-free/contrib) then it may as well be useful. The exact text of point 4 of the Social Contract is “Our priorities are our users and free software”. You seem to have forgotten the second half of the sentence. > If we decide that we are too pure for this, then we can indeed move on. But > let's now ship crippling packages that only pretend to help our users. This has nothing to do with crippling the MKL package. Reference BLAS and ATLAS have already a lower priority than OpenBLAS. See: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries These priorities are meant to express what Debian thinks is the best option to implement BLAS. I can’t see how we could collectively think that MKL is better than OpenBLAS: we have always valued freedom above performance or features, it is the essence of this project. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
OBOn Sat, Apr 28, 2018 at 11:56:02AM -0700, Dima Kogan wrote: > Andreas Tille writes: > > On Fri, Apr 27, 2018 at 06:36:51PM +0200, S?bastien Villemot wrote: > > > >> There is also a licensing issue: using GPL'd software (e.g. GNU > >> Octave) with MKL is not allowed. > > > > I think that's a pretty strong reason to rate non-free software lowest > > in the alternatives. Packaging useful non-free software is fine but > > ranking it higher than free alternatives seems in contrast with our > > social contract. Users who want to use it should be able to handle > > alternatives system. > > I really would like to see MKL having the highest priority. > > Is the licensing issue only there when any other components being linked > are licensed under the GPL? If so, we need to either > > 1. actually handle this issue to make the link fail in cases of license >violations > > 2. not ship MKL at all > > 3. decide that the user is sophisticated-enough to manually figure this >out > > Currently we're on the path to option 3. non-free repos are already > opt-in, and the user already needs to do manual work to get them. If > they have done this manual work, that's plenty of an indication that > they have decided that license purity isn't a priority for them. The non-free section is enabled on a lot of bare metal machines, because you almost always need a firwmare blob to use mainstream hardware. Or you may want to read documentation under GFDL-with-invariant-section. So enabling the non-free section does not necessarily mean that you are happy with using non-free software, especially when there are free alternatives. > If I was a user who manually added the non-free repos and then manually > installed the mkl libraries, I'd be aggravated to find out that there's > yet another hoop I need to jump through to actually use these libraries. > This would be a waste of my time, especially since I have already taken > actions to clearly indicate that I want MKL. Note that this is already the case if you want to use reference BLAS or ATLAS but have OpenBLAS installed (because the latter has the highest priority). So we are not special-casing MKL here. > We can decide that we're not interested in providing a license-impure > option, but then we shouldn't be providing a non-free, and we don't need > to rehash that argument. There seems to be a consensus in favor of packaging MKL, so I don’t understand why you’re saying this. We’re just talking about clearly expressing the fact that Debian prefers free alternatives and making sure that the user is aware of licensing issues with dynamic linking. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS
Dear Lumin, On Fri, Apr 27, 2018 at 04:24:43PM +, Lumin wrote: > The main purpose for me to write this mail is to notify > you guys that I'm going to assign MKL a higher priority > than OpenBLAS via the update-alternative mechanism. > > MKL provides alternatives to e.g. libblas.so.3 > > > intel-mkl provides a magical dispatcher library named libmkl_rt.so, > which contains symbols of BLAS and LAPACK. This library > can be used as an alternative to libblas.so.3 and liblapack.so.3 . > (didn't actually test it. This is still WIP) > > So I'm going to provide these alternatives with a higher priority > compared to OpenBLAS: > > libblas.so.3 libmkl_rt.so 50 > liblapack.so.3 libmkl_rt.so 50 > libblas.so libmkl_rt.so 50 > liblapack.so libmkl_rt.so 50 > > Such non-free package won't be automatically installed. However > once MKL is installed, the user must means to use it. By the way, > I'm linking both .so and .so.3 to libmkl_rt.so because the upstream > didn't give it a SOVERSION ... > > Please let me know if you are object to this :-) > Sébastien, how do you like this? I think packaging MKL for Debian is useful, thanks for doing this. But I disagree with it being higher priority than the other implementations. This is Debian, and we strongly discourage users from using non-free software. In my opinion, MKL should rather be of a priority lower than all the other alternatives (including the BLAS reference implementation). It’s quite easy to install a package and to forget about it, and users may be using MKL without really mean it, especially because MKL is not used directly, since it’s a library. Having to configure the alternatives system is a good way of expressing one’s intention to use non-free software, and to be aware of the implications (i.e. MKL will be used as a library by many other applications). There is also a licensing issue: using GPL'd software (e.g. GNU Octave) with MKL is not allowed. And finally I may well be personally interested in installing your MKL package, for doing occasional benchmarks. But I don't want to have to modify the default priorities for my daily usage (I would modify them temporarily for doing those benchmarks). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: VTK7 in unstable, future of vtk6
On Thu, Apr 12, 2018 at 10:14:39AM -0400, Kyle Edwards wrote: > I'm somewhat sad to hear that you're dropping Java, -doc, and -example. What > are the challenges you're facing with these packages? This would be good for > me to know so that I can improve them in VTK 9 and hopefully bring them back > for the VTK 9 package. (I believe Tcl/Tk have been dropped from VTK in the > latest version, so those won't be coming back.) My understanding is that Gert intends to drop java, -doc and -example from the VTK 6 packages, and not on newer ones.. Best, P.S.: please don't top post, it makes it difficult to read threads. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: RFS: ann
On Wed, Mar 28, 2018 at 10:56:25AM +0300, Teemu Ikonen wrote: > I've prepared a new revision of ann at > https://salsa.debian.org/science-team/ann > > The intention of this revision was to fix #865148, but I ended up also > converting the package from cdbs to dh and updated it to current > standards. Uploaded, thanks for your contribution. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: RFS and Upload: librecad
Dear Innocent, On Tue, Mar 27, 2018 at 06:51:05PM +0200, Innocent De Marchi wrote: > I have updated the librecad package to version 2.1.3 [0]. > The package is lintian clean and it does not have important news > regarding the last update. I see that you removed Scott Howard and Ruben Molina from the Uploaders field. But this change is not documented in the changelog. Did they express their desire to be removed? Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Fwd: MKL is redistributable; Should we package it?
On Fri, Mar 30, 2018 at 08:07:17AM +, Ghislain Vaillant wrote: > Le ven. 30 mars 2018 à 08:18, Lumin a écrit : > > I noticed that intel's math kernel library is redistributable[1]. > > Since it is widely used in various fields, an mkl package > > in Debian archive my be beneficial to at least science > > software users. > > > > However despite of the explicit declaration that MKL > > is redistributable, MKL itself is a proprietary and > > its source is not available. That means mkl must enter > > nonfree, and the packaging is to simply repack a pile > > of binary blobs. > For BLAS and FFT, there are already performant and established alternatives > (OpenBLAS and FFTW), so the appeal to provide a non-free alternative is > lower, imo. I agree with this analysis. Also note that, in addition to OpenBLAS, we have ATLAS (which is more portable across architectures). Nevertheless, if you are willing to do the packaging work, please integrate MKL with the alternatives system, as described on this page: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: HELP needed for uploading a new upstream version of the Rheolef package
On Thu, Mar 29, 2018 at 10:00:33PM +0200, Pierre Saramito wrote: > Are the debianization files ready for an upload in Debian ? I made a few more changes (pushed to the git repository), and uploaded the result. Note that there is still a rather important issue that needs to be fixed in the next upload: librheolef.so.1.0.0 is underlinked (it looks like it's missing a link to boost and/or standard C++ library, maybe more). I get these messages: dpkg-shlibdeps: warning: symbol _ZSt2wsIcSt11char_traitsIcEERSt13basic_istreamIT_T0_ES6_ used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZTISt13runtime_error used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZNSolsEs used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol __cxa_free_exception used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZTTNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEE used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZSt5flushIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZN5boost13serialization13typeid_system27extended_type_info_typeid_015type_unregisterEv used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZNK5boost3mpi12communicatorcvP19ompi_communicator_tEv used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZSt7getlineIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RNSt7__cxx1112basic_stringIS4_S5_T1_EES4_ used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 f ound in none of the libraries dpkg-shlibdeps: warning: symbol _ZN5boost7archive6detail14basic_oarchiveC2Ej used by debian/librheolef1/usr/lib/x86_64-linux-gnu/librheolef.so.1.0.0 found in none of the libraries dpkg-shlibdeps: warning: 218 other similar warnings have been skipped (use -v to see them all) Thanks for your contribution. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: HELP needed for uploading a new upstream version of the Rheolef package
On Wed, Mar 28, 2018 at 04:50:29PM +0200, Sébastien Villemot wrote: > - there are files under Copyright 2000 Gray Watson and under the NTP license, > not mentioned in debian/copyright: > config/dmalloc_return.h > util/dmallocxx/conf.h > util/dmallocxx/dmallocc.cc > util/dmallocxx/return.h > util/dmallocxx/settings.h Sorry, there is already a stanza for these files, but you need to add config/dmalloc_return.h which is not listed there. Also, I tried to build the package, and got these lintian errors/messages that should be fixed: E: rheolef source: malformed-override Possibly wrong package in override at line 10 (got librheolef-dev, expected rheolef) I: rheolef source: binary-control-field-duplicates-source field "section" in package rheolef I: rheolef source: vcs-field-not-canonical https://salsa.debian.org/science-team/rheolef.git https://salsa.debian.org/science-team/rheolef (for the latter, you should basically drop the .git suffix from Vcs-Browser in debian/control) -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: HELP needed for uploading a new upstream version of the Rheolef package
On Wed, Mar 28, 2018 at 04:18:28PM +0200, Pierre Saramito wrote: > > In this precise case, this file looks incorect: it states that most of the > > code > > is GPL-3 (only) and that utils/bamg/* is LGPL-2.1 (only). But these two > > licenses are incompatible! > > Looking at the source code, it looks like utils/bamg/* is LGPL-2.1+ (note > > the > > plus, which means v2.1 *or later*), which solves the problem. > > Hum... I am not very fluent with this subject! > I've just added a + after LGPL-2.1 for utils/bamg in debian/copyright > and enter "git push" : is it fixed now ? > > > > Also, it could not figure if the rest of the code is GPL-2+ or GPL-3+ (the > > README file says > > GPL-2+, but the COPYING file says GPL-3+). > > The upstream source code has updated the COPYING file to GPL-3+ while, in the > header > of some individual files, there is some previous text still indicating GPL-2+. > It will fixed later in the upstream. > Is it a problem for uploading the new 7.0 upstream version in Debian ? Since GPL-3 is implied by GPL-2+, this is not by itself a problem (no need to make a new upstream release). Still, the debian/copyright file is not yet correct: - the description of the various licenses is not complete, you must copy/paste the whole licensing terms (short of what is already in /u/s/common-licenses). See for example what is done here for GPL-2+: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#examples - there are files under Copyright 2000 Gray Watson and under the NTP license, not mentioned in debian/copyright: config/dmalloc_return.h util/dmallocxx/conf.h util/dmallocxx/dmallocc.cc util/dmallocxx/return.h util/dmallocxx/settings.h - similarly, config/install-sh is under the Expat license. I think that's all for the missing files, though I did a very superficial check. - for the rest of the software, and debian/*, why not using GPL-3+ instead of GPL-3? - moreover, you could use a separate license paragraph for the latter two, to avoid duplicating license information I could do the above changes myself, though I would prefer you do them. Let me know. In any case, the copyright file is a very important one (maybe the most important one), so great care should be given to ensure it is accurate. Note that you can also use "cme fix dpkg-copyright" from libconfig-model-dpkg-perl once you are finish, to fix some automatically-fixable mistakes. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: HELP needed for uploading a new upstream version of the Rheolef package
Dear Pierre, On Wed, Mar 28, 2018 at 03:42:27PM +0200, Pierre Saramito wrote: > I've just update the upstream branch and merge it into master. > The repository should now contains the 7.0 version. > Is there something else to do for the new 7.0 version in Debian ? As with every new upstream release, you should verify that the debian/copyright file is up-to-date. In this precise case, this file looks incorect: it states that most of the code is GPL-3 (only) and that utils/bamg/* is LGPL-2.1 (only). But these two licenses are incompatible! Looking at the source code, it looks like utils/bamg/* is LGPL-2.1+ (note the plus, which means v2.1 *or later*), which solves the problem. Also, it could not figure if the rest of the code is GPL-2+ or GPL-3+ (the README file says GPL-2+, but the COPYING file says GPL-3+). You can find the reference documentation for the machine-readable format of debian/copyright at the following place: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Join the Debian Science team
Hi Innocent, On Tue, Mar 20, 2018 at 07:51:06PM +0100, Innocent De Marchi wrote: > I see that there are some packages that have not been updated for a > long time: I think I will start my collaboration with them [0]. > [0] https://packages.qa.debian.org/x/xppaut.html > https://packages.qa.debian.org/p/python-neuroshare.html Note that xppaut and python-neuroshare are not currently maintained by the Debian Science Team. So if you want to move these packages to Debian Science, you first have to obtain permission from the current maintainers. Welcome! -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: New sundials upstream release
On Tue, Dec 26, 2017 at 09:58:38PM +1100, James Tocknell wrote: > I had a quick look at the changes when 3.0 came out (I'm not sure about the > difference between 3.0 and 3.1, there was no announcement of 3.1 that I > saw). Upstream appears to have changed their API again. The next release of > octave is broken by the changes ( > https://savannah.gnu.org/bugs/?func=detailitem&item_id=52475), but it's not > in Debian. There were also mentions of build issues on the mailing list ( > http://sundials.2283335.n4.nabble.com/Re-cmake-and-linkage-on-Unix-td4654099.html, > http://sundials.2283335.n4.nabble.com/sundials-3-0-build-patches-td4654087.html, > http://sundials.2283335.n4.nabble.com/cmake-and-linkage-on-Unix-td4653972.html), > but I'm not sure if they've been fixed or not. Any update on this? I see that the git upstream branch has been updated to 3.1. Is there any blocker, other than lack of time? I'm willing to help if needed. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: gbp import-orig failure on bcolz
On Wed, Mar 14, 2018 at 07:13:31AM +0100, Daniel Stender wrote:
> I've problems with importing the upstream tarball into the repo of Bcolz:
>
>
> $ uscan --no-conf --verbose --download --force-download --destdir ../
> --rename --repack --compression xz
> {...}
> $ gbp import-orig ../bcolz_1.1.2+ds1.orig.tar.xz
> What is the upstream version? [1.1.2+ds1]
> gbp:info: Importing '../bcolz_1.1.2+ds1.orig.tar.xz' to branch 'upstream'
> (filtering out ['.gitignore'])...
> gbp:info: Source package is bcolz
> gbp:info: Upstream version is 1.1.2+ds1
> gbp:info: Merging to 'debian/master'
> gbp:error: Automatic merge failed.
> gbp:error: Error detected, Will roll back changes.
> gbp:info: Rolling back branch upstream by resetting it to
> 8cacdf572b1bf20b1c2b37bc60af4db142ca9f24
> gbp:info: Rolling back branch pristine-tar by resetting it to
> c940849f7c81d4de8fdf02255dfcdb9fe9c9e188
> gbp:info: Rolling back tag upstream/1.1.2+ds1 by deleting it
> gbp:info: Rolling back branch debian/master by resetting it to
> 241aa4d7c3d822473dfb38b55e6d2386b76fa083
> gbp:info: Rolling back failed merge of upstream/1.1.2+ds1
> gbp:error: Rolled back changes after import error.
>
>
> Can anybody figure out what's going wrong here?
The problem comes from the file bcolz/version.py that is present in the
upstream branch and tarball, but not in the debian/master branch.
You should first resurrect this file on the debian/master branch, then retry
gbp import-orig.
(I figured this out by using the --no-rollback option of gbp import-orig, which
leaves the repo in the unmerged state)
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: PGP signature
