Bug#895334: libsundials-nvecparallel-petsc2: uninstallable on current unstable
Package: libsundials-nvecparallel-petsc2 Version: 2.7.0+dfsg-2+b2 Severity: grave Justification: renders package unusable Dear Maintainer, Since petsc was updated in unstable from 3.7 to 3.8, the libsundials-nvecparallel-petsc2 package is uninstallable in unstable. It depends on libpetsc3.7, which no longer exists in the archive. This is probably easily fixed with a binNMU. Thanks. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsundials-nvecparallel-petsc2 depends on: ii libc62.27-2 ii libopenmpi2 2.1.1-8 ii libpetsc3.7.7 [libpetsc3.7] 3.7.7+dfsg1-2+b3 libsundials-nvecparallel-petsc2 recommends no packages. libsundials-nvecparallel-petsc2 suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#876410: libgl2ps1: please include support for SOURCE_DATE_EPOCH
On Sat, Mar 24, 2018 at 23:08:25 +0100, Anton Gladky wrote: > thanks for the bugreport. I do not think, that adding the > fixed timestamp to all files produced by the gl2os that is > what the users want. Thank you for your reply. Respectfully, I am a user of gl2ps, and I do want to be able to use it to write deterministic postscript output. I do think the current behavior should be the default, I am only asking for an option to create an output with a known timestamp. If this is not done in gl2ps, then my workarounds include embedding a patched version of gl2ps.c, using faketime, or post-processing the .ps files to edit the timestamp strings. None of these are particularly appealing options. My original report may have sounded like a "why not?" request. So just to be clear, I do have a real need for gl2ps to produce postscript files that are deterministic. Cheers, -- mike signature.asc Description: PGP signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#891465: glpk: prints warnings which lead to failing sagemath tests
Package: libglpk40 Version: 4.65-1 Followup-For: Bug #891465 Hi, I also see this bug affecting octave, although as a minor cosmetic issue. Octave's glpk unit tests also intentionally set msg_lev to GLP_MSG_OFF to have no output generated. With glpk 4.65, this same message is now appearing in the test suite output log. It would be very helpful if GLP_MSG_OFF suppressed this message as it does with other messages. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libglpk40 depends on: ii libamd2 1:5.1.2-2 ii libc6 2.26-6 ii libcolamd2 1:5.1.2-2 ii libgmp102:6.1.2+dfsg-2 ii libltdl72.4.6-2 ii zlib1g 1:1.2.8.dfsg-5 libglpk40 recommends no packages. Versions of packages libglpk40 suggests: pn default-libmysqlclient-dev pn libiodbc2-dev -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#876410: libgl2ps1: please include support for SOURCE_DATE_EPOCH
Package: libgl2ps1 Version: 1.3.9-4 Severity: wishlist Tags: upstream Dear Maintainer, All files produced by gl2ps include the current time in the local time zone. It would be helpful if this could be overridden so that files produced using gl2ps could be deterministic. Please consider adding support for the standard SOURCE_DATE_EPOCH environment variable. If present, it should override the use of the current time, and should also influence times to be written in a format that does not depend on the local time zone or locale. Thanks for your work on gl2ps. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgl2ps1 depends on: ii libc62.24-17 ii libgl1 0.2.999+git20170802-4 ii libgl1-mesa-glx 17.2.1-1 libgl2ps1 recommends no packages. libgl2ps1 suggests no packages. -- no debconf information signature.asc Description: PGP signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#875697: arpack: debian versions 3.4.0-1 and 3.5.0-1 are actually upstream version 3.3.0
On Wed, Sep 13, 2017 at 10:51:06 -0700, Mike Miller wrote: > I noticed that arpack 3.4.0-1 and 3.5.0-1 are actually built from the > upstream source version 3.3.0. The sources in the Debian archive are > identical: I guess this was caused by a buggy filenamemangle rule in debian/watch, which should also be fixed: $ uscan --destdir . --download-version 3.3.0 uscan: Newest version of arpack on remote site is 3.3.0, specified download version is 3.3.0 $ uscan --destdir . --download-version 3.4.0 uscan: Newest version of arpack on remote site is 3.4.0, specified download version is 3.4.0 $ uscan --destdir . --download-version 3.5.0 uscan: Newest version of arpack on remote site is 3.5.0, specified download version is 3.5.0 $ ls -lgo arpack*.tar.gz lrwxrwxrwx 1 18 Sep 13 11:15 arpack_3.3.0.orig.tar.gz -> arpack-ng-0.tar.gz lrwxrwxrwx 1 18 Sep 13 11:15 arpack_3.4.0.orig.tar.gz -> arpack-ng-0.tar.gz lrwxrwxrwx 1 18 Sep 13 11:15 arpack_3.5.0.orig.tar.gz -> arpack-ng-0.tar.gz -rw-r- 1 937287 Sep 13 11:15 arpack-ng-0.tar.gz -- mike signature.asc Description: PGP signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#875697: arpack: debian versions 3.4.0-1 and 3.5.0-1 are actually upstream version 3.3.0
Source: arpack Version: 3.5.0-1+b1 Severity: important Dear Maintainer, I noticed that arpack 3.4.0-1 and 3.5.0-1 are actually built from the upstream source version 3.3.0. The sources in the Debian archive are identical: $ sha256sum arpack_*.orig.tar.gz ad59811e7d79d50b8ba19fd908f92a3683d883597b2c7759fdcc38f6311fe5b3 arpack_3.3.0.orig.tar.gz ad59811e7d79d50b8ba19fd908f92a3683d883597b2c7759fdcc38f6311fe5b3 arpack_3.4.0.orig.tar.gz ad59811e7d79d50b8ba19fd908f92a3683d883597b2c7759fdcc38f6311fe5b3 arpack_3.5.0.orig.tar.gz Please provide a package built from the true 3.5.0 upstream source. Please note that this also affects stable. Thank you for your work on arpack. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#872564: gnuplot: description text "This package is for transition" may be outdated and misleading
Package: gnuplot Version: 5.0.6+dfsg1-1 Severity: minor Dear Maintainer, You may want to consider rewriting the description text of the gnuplot metapackage. It seems misleading to me that it includes the following This package is for transition and to install a full-featured gnuplot supporting the X11-output. The phrase "This package is for transition" has been in the description of the gnuplot metapackage unaltered since gnuplot 4.0.0, when gnuplot-nox and gnuplot-x11 were introduced. I think this leads users to believe that the package may go away at some point and that they should not depend directly on it. Since this metapackage still exists 13 years later, it seems that this is not really a transitional package at all. It might help to clarify the intent by rewording this last paragraph of the description. Thanks for your work. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnuplot depends on: ii gnuplot-qt [gnuplot-nox] 5.0.6+dfsg1-1 gnuplot recommends no packages. Versions of packages gnuplot suggests: pn gnuplot-doc -- no debconf information signature.asc Description: PGP signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#824882: libgl2ps0 unexpectedly provides libgl2ps.so.1
Package: libgl2ps0 Version: 1.3.8-2 Severity: serious Justification: Policy 8.1 The libgl2ps0 package now installs libgl2ps.so.1.3.8 with soname libgl2ps.so.1. This is a policy violation, either the patch that introduced this change must be undone restoring .so.0, or the package must be renamed to do a proper library transition. I see the new upstream version in experimental provides the properly named libgl2ps1 package. So a possible resolution would be to upload 1.3.9 to unstable. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgl2ps0 depends on: ii libc6 2.22-9 libgl2ps0 recommends no packages. libgl2ps0 suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#749820: gnuplot: Uninstallable
(Not maintainer, just interested user.) On Fri, May 30, 2014 at 01:00:06 +0200, Axel Beckert wrote: > since the 4.6.5-2 upload gnuplot is uninstallable at least on amd64: > > gnuplot depends on gnuplot-nox and ( gnuplot-x11 or gnuplot-qt ) > > Both, gnuplot-x11 and gnuplot-qt conflict with gnuplot-nox. It is not uninstallable for me at least. Both gnuplot-x11 and gnuplot-qt provide gnuplot-nox, so either one will satisfy both of the depends. The change I see with 4.6.5-2 is gnuplot and gnuplot-nox can no longer be installed together. Installing gnuplot-nox now removes gnuplot, and installing gnuplot requires either gnuplot-x11 or gnuplot-qt and uninstalls gnuplot-nox. Whether or not that's desired I can't say, but that's the effect I see here at least. -- mike -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
