Bug#895334: libsundials-nvecparallel-petsc2: uninstallable on current unstable

2018-04-09 Thread Mike Miller
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

2018-04-06 Thread Mike Miller
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

2018-02-27 Thread Mike Miller
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

2017-09-21 Thread Mike Miller
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

2017-09-13 Thread Mike Miller
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

2017-09-13 Thread Mike Miller
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

2017-08-18 Thread Mike Miller
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

2016-05-20 Thread Mike Miller
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