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%2B2024-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
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
Bug#926330: 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-scie...@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
Bug#913493: RFS: geneweb/6.08+git20181019+dfsg-1
Dear Guillaume, On Sun, 11 Nov 2018 12:26:21 -0500 Guillaume Brochu wrote: > Package: sponsorship-requests > Severity: normal > I am looking for a sponsor for the package "geneweb", that is in Debian > since July 2000. > Following closure of #908850 and a e-mail communication with Boyuan Yang, > here is a new upload for the geneweb package. > > * Package name: geneweb > Version : 6.08+git20181019+dfsg-1 > Upstream Author : Daniel de Rauglaudre et al. > * URL : https://github.com/geneweb/geneweb > * License : GPL-2 > Section : misc I did a quick review of the package. The debian/copyright file needs to be fixed: – the copyright years for the main INRIA copyright notice are incomplete. My understanding is that it should now be at least 1998- 2012 – there is a missing attribution for the file contrib/gwdiff/gwdiff.ml, which is Copyright © 2001 Ludovic LEDIEU (the easiest solution is probably to create a new stanza for that one) – around the end of the "GPL-2" paragraph, at the end of the paragraph giving the FSF address, there is a spurious "License: GPL-2+" that should be removed Otherwise the package looks good. Here are a few things that you might want to improve, but that I don't consider as a blocker for an upload: – all the Pre-Depends on "dpkg (>= 1.15.6~)" could be removed, because even wheezy has a version of dpkg that satisfies this constraint – debhelper compat level could be bumped to 11 – you could migrate to the new way of specifying debhelper compat level (removing debian/compat, and specifying "debhelper-compat (= NN)" in Build-Depends, see debhelper(1)) – most entries (if not all) in the debian/*.dirs files are useless; these files should only be used to create empty directories; otherwise, directories are automatically created by debhelper once you install a file in them – you could bump Standards-Version to 4.3.0 (that has just been released) Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://seb astien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#897238: 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
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
Bug#897238: 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
Bug#897238: RFS: intel-mkl/2018.2.199-1 -- Intel Math Kernel Library (Intel MKL)
On Mon, Apr 30, 2018 at 04:49:13PM +, Lumin wrote: > Package: sponsorship-requests > Severity: wishlist > X-Debbugs-CC: debian-scie...@lists.debian.org > I am looking for a sponsor for my package "intel-mkl" > > * Package name: intel-mkl >Version : 2018.2.199-1 >Upstream Author : Intel > * URL : https://software.intel.com/en-us/mkl > * License : Intel Simplified Software License (ISSL) >Section : science > > Thanks for people who joind the discussion about MKL packaging > at debian-science list. > > Intel MKL is widely used among scientific research/computing > communities > because of it's well-optimized and super fast. > As previously discussed > in debian-science list, having intel-mkl > in Debian archive would be > useful, and would benifit our > users (especially the scientific users). > So here is the package. As said on debian-science@, the current handling of alternatives within the postinst script needs to be improved: https://lists.debian.org/debian-science/2018/04/msg00096.html https://lists.debian.org/debian-science/2018/04/msg00097.html Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility
Also, there is a GPG key under debian/upstream/signing-key.asc, but I see no signature on upstream website (https://common-lisp.net/project/asdf/archives/). Am I missing something? Or should the key be removed? Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility
On Wed, Oct 11, 2017 at 07:10:09PM +0200, Kambiz Darabi wrote: > > > Could you please push your changes to the git repository for cl-asdf > > on alioth? > > I just pushed the changes and an additional one for fixing > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873035 > > which I had forgotten. Thanks. However it looks like you forgot to push the upstream branch and the tags. Could you please do so? > > Also, in the future, I suggest that you make requests for sponsorship > > on the list of the Debian Common Lisp Team, which is the right place > > to discuss about this package. > > Will do. The previous maintainer told me to send an email to debian-mentors. > When I did so, a mentor told me that I should file a formal RFS. > That's the reason why I did so. > > If you think it is not necessary to file a RFS bug, I email the > pkg-common-lisp-devel list only. Since this is a package maintained by the Debian Common Lisp Team, you should indeed write first to the list of the team, asking for sponsorship. If the team is alive, that should work. RFS should only be considered as a very last resort option, if the team is dying… Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility
Dear Kambiz, On Tue, 10 Oct 2017 19:14:39 +0200 Kambiz Darabi <dar...@m-creations.net> wrote: > Package: sponsorship-requests > Severity: normal > I have packaged the new upstream release 3.3.0 of the Common Lisp ASDF > software: Thanks for your work. Could you please push your changes to the git repository for cl-asdf on alioth? I will make an upload based on your work (probably making minor additional changes). Also, in the future, I suggest that you make requests for sponsorship on the list of the Debian Common Lisp Team, which is the right place to discuss about this package. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#732188: RFS: freedict -- free bilingual dictionary databases
Le dimanche 15 décembre 2013 à 13:13 +0100, Sebastian Humenda a écrit : after the FreeDict packages got orphaned I started to prepare new Debian packages because Debian as a international project needs free dictionary databases in its archive. Now I'm looking for sponsors for my package(s): * Package name: freedict * Version : 2013.11.30 * Upstream Author : The FreeDict project * URL : http://freedict.org * License : various (depending on dictionary, included in copyright notice) * Section : text Thanks for doing this work. A few things that I would like to see fixed before uploading: - the dict-freedict-all package depends on nonexistent afr-deu package - the source package does not build in a minimal chroot (with pbuilder/cowbuilder); there seem to be some missing dependency on a perl XML module - could you please add a pristine-tar branch to the git repository, so that the tarball created from the git is always the same? (option --pristine-tar of git-import-orig) - upgrade to latest Standards-Version (3.9.5) - remove the packaging team from the Uploaders field (it is already in the Maintainer field, no need to repeat it) - add fields Vcs-Git and Vcs-Browser in debian/control; by the way, the repository should be name freedict.git, like the source package (without the prepending pkg-) -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#718893: RFS: coinutils/2.9.4-1 [ITA] -- CoinOR base library
Le mardi 13 août 2013 à 01:22 -0400, Miles Lubin a écrit : I've uploaded a new version with a best-effort attempt to conform to the debian-science guidelines. Please let me know of any issues. After a quick review of the package, I found the following issues that I would like you to fix before an upload: - make the package lintian clean, which means fix the 4 warnings. A few hints follow: + for the embedded javascript file, you should make the package depend on libjs-jquery, and replace the jquery.js file in your package with a symlink to the same file provided by libjs-jquery + for the debian/copyright file, the indentation of the paragraph describing the EPL is not correct; you should shift it right by one column, and replace empty lines by a space followed by a dot + for the outdated autotools files, you should regenerate them at build time using the dh-autoreconf helper - put the source of the package in a git repository on alioth under the debian-science tree, as explained in the Debian Science policy, and add the corresponding Vcs-* fields in the debian/control file. You need to create an alioth account and ask to join the Debian Science group there before being able to create the repository. - remove the obsolete README.source Don't hesitate to ask if you need help on any of these points. Best, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
