Bug#886585: Suggests / Recommends two non-existent packages: python-scitools and python-mshr

2018-01-07 Thread Steve M. Robbins 
Package: fenics
Version: 1:2017.1.0.1
Severity: minor

Hi,

I tried to install the Suggested and Recommended packages, but found two are 
non-existent.

python-scitools: appears to have existed at one time, but now removed from 
Debian; see 
https://packages.qa.debian.org/s/scitools/news/20160506T061253Z.html  This 
Recommends should probably be removed (?).

python-mshr: I guess this is the binary package of src:mshr that is stalled due 
to using embedded, modified copy of CGAL; c.f. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824716  


-Steve


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fenics depends on:
ii  dolfin-bin  2017.1.0-4
ii  dolfin-doc  2017.1.0-4
ii  libdolfin-dev   2017.1.0-4+b4
ii  python-dijitso  2017.1.0-3
ii  python-dolfin   2017.1.0-4+b4
ii  python-ffc  2017.1.0-2
ii  python-fiat 2017.1.0-2
ii  python-instant  2017.1.0-2
ii  python-ufl  2017.1.0-2
ii  python-ufl-doc  2017.1.0-2

Versions of packages fenics recommends:
pn  python-scitools  

Versions of packages fenics suggests:
pn  python-mshr  

-- 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#857491: Computation of top_dir is fooled by README

2017-03-11 Thread Steve M. Robbins 
Package: python-sfepy
Version: 2016.2-2
Severity: normal

I tried to run the examples using:

  sfepy-run simple examples/diffusion/poisson_short_syntax.py

and obtained:

  sfepy: left over: ['verbose', '__builtins__', '__file__', '__doc__', 
'__name__', 'data_dir', '__package__', '_filename']
  sfepy: reading mesh [line2, tri3, quad4, tetra4, hexa8] 
(/usr/lib/python2.7/dist-packages/meshes/3d/cylinder.mesh)...

... which fails because the mesh path is wrong.  There needs to be a sfepy 
after dist-packages.


The root cause of this is the computation of "top_dir" in version.py:

# If installed, up_dir is '.', otherwise (in (git) source directory) '..'.
for up_dir in ['..', '.']:
top_dir = op.normpath(op.realpath(op.join(op.dirname(__file__),
  up_dir)))
aux = op.join(top_dir, 'README')
if op.isfile(aux):
break
else:
raise RuntimeError('cannot determine SfePy top level directory!')

The trouble is that ".." is tried first and there happens to be a README file
at that path: /usr/lib/python2.7/dist-packages/README !

There's an obvious Debian-only fix to remove '..' in version.py, which is
what I've done locally for now.




-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-sfepy depends on:
ii  ipython   5.1.0-3
ii  libc6 2.24-9
ii  libsuitesparse-dev1:4.5.4-1
ii  mayavi2   4.5.0-1
ii  python2.7.13-2
ii  python-matplotlib 2.0.0+dfsg1-2
ii  python-numpy [python-numpy-abi9]  1:1.12.0-2
ii  python-pyparsing  2.1.10+dfsg1-1
ii  python-scipy  0.18.1-2
ii  python-sparse 1.1.1-1
ii  python-tables 3.3.0-5
pn  python:any

python-sfepy recommends no packages.

python-sfepy 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#844373: ros-image-common: FTBFS (incompatible build-dependencies)

2016-11-14 Thread Steve M. Robbins 
On Tuesday, November 15, 2016 1:02:10 AM CST Santiago Vila wrote:
> Package: librospack-dev,libgtest-dev,src:ros-image-common
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build ros-image-common in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> 
>  [...]
> Unpacking librospack-dev (2.3.1-1+b1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-dJJuDK/111-librospack-dev_2.3.1-1+b1_amd64.deb
> (--unpack): trying to overwrite '/usr/include/gtest/gtest-death-test.h',
> which is also in package libgtest-dev:amd64 1.7.0-4 dpkg-deb: error:
> subprocess paste was killed by signal (Broken pipe)

I think it should be clear that /usr/include/gtest is owned by libgtest-dev, 
so I'll reassign the bug to librospack-dev.

Best case: librospack-dev can use Debian's libgtest-dev.  If not, then please 
place the files somewhere else.

> OTOH, if one of the packages librospack-dev or libgtest-dev should not
> contain the file, then please reassign to the package at fault and
> also send an "affects" command to the control address, so that we can
> still see that this bug affects src:ros-image-common in its BTS web page.
> 
> Sorry that I can't tell for sure which one of those cases is the truth,
> I just detected this problem by trying to build ros-image-common.
> 
> Thanks.



signature.asc
Description: This is a digitally signed message part.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Comments regarding ipe_7.2.4-1_amd64.changes

2016-07-10 Thread Steve M. Robbins 
On Monday, June 27, 2016 12:38:45 PM CDT Chris Lamb wrote:
> please clarify src/ipelib/ipebitmap.cpp

Can I request that you ask a more specific question, please?

Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.
-- 
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#822129: Boost 1.55 to be removed; your attention required

2016-04-21 Thread Steve M. Robbins 
Package: diet
Severity: normal

Boost 1.55 has not built correctly since the GCC 5 introduction in July 2015 
and I plan
to ask for its removal from unstable very shortly.  It has already been removed 
from
testing.

The package diet appeared on a list of reverse dependencies generated 
using 'dak rm -Rn boost1.55' (see below).  This bug is to request an
upload with updated boost dependencies.

If your package build-depends on the default boost, then a simple rebuild will 
suffice.
If your package uses 1.55-versioned build-deps, then please check whether you 
can
move to default boost.  Or if not, at least move to 1.58.

Output from ssh mirror.ftp-master.debian.org "dak rm -Rn boost1.55" follows.

Checking reverse dependencies...
# Broken Depends:
ball: ballview [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libball1.4 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libballview1.4 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  python-ball [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  python-ballview [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
cufflinks/non-free: cufflinks [amd64]
diet: diet-agent [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-admin2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-client2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-dagda2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-sed2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
feel++: feel++-apps [amd64 i386 powerpc]
libfeel++1 [amd64 i386 powerpc]
gqrx-sdr: gqrx-sdr [kfreebsd-amd64 kfreebsd-i386]
gr-air-modes: gr-air-modes [kfreebsd-amd64 kfreebsd-i386]
  libair-modes0 [kfreebsd-amd64 kfreebsd-i386]
gr-osmosdr: gr-osmosdr [kfreebsd-amd64 kfreebsd-i386]
libgnuradio-osmosdr0.1.3 [kfreebsd-amd64 kfreebsd-i386]
kig: kig [hurd-i386]
librime: librime-bin [hurd-i386]
 librime1 [hurd-i386]
limereg: limereg [mips mipsel]
mongodb: mongodb-clients [hurd-i386 kfreebsd-i386]
 mongodb-server [hurd-i386 kfreebsd-i386]
openvrml: libopenvrml9 [amd64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
  openvrml-lookat [amd64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
pcb2gcode: pcb2gcode [kfreebsd-amd64 kfreebsd-i386]
qbittorrent: qbittorrent [kfreebsd-amd64 kfreebsd-i386]
 qbittorrent-nox [kfreebsd-amd64 kfreebsd-i386]
qpid-cpp: libqpidcommon2 [amd64 arm64 i386 mipsel powerpc ppc64el]
  qpidd [amd64 arm64 i386 mipsel powerpc ppc64el]
smc: smc [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel 
powerpc s390x]
swift-im: libswiften-dev [amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x]
  libswiften2 [amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
  swift-im [amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]

-- 
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#822125: Boost 1.55 to be removed; your attention required

2016-04-21 Thread Steve M. Robbins 
Package: limereg
Severity: normal

Boost 1.55 has not built correctly since the GCC 5 introduction in July 2015 
and I plan
to ask for its removal from unstable very shortly.  It has already been removed 
from
testing.

The package limereg appeared on a list of reverse dependencies generated 
using 'dak rm -Rn boost1.55' (see below).  This bug is to request an
upload with updated boost dependencies.

If your package build-depends on the default boost, then a simple rebuild will 
suffice.
If your package uses 1.55-versioned build-deps, then please check whether you 
can
move to default boost.  Or if not, at least move to 1.58.

Output from ssh mirror.ftp-master.debian.org "dak rm -Rn boost1.55" follows.

Checking reverse dependencies...
# Broken Depends:
ball: ballview [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libball1.4 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libballview1.4 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  python-ball [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  python-ballview [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
cufflinks/non-free: cufflinks [amd64]
diet: diet-agent [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-admin2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-client2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-dagda2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-sed2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
feel++: feel++-apps [amd64 i386 powerpc]
libfeel++1 [amd64 i386 powerpc]
gqrx-sdr: gqrx-sdr [kfreebsd-amd64 kfreebsd-i386]
gr-air-modes: gr-air-modes [kfreebsd-amd64 kfreebsd-i386]
  libair-modes0 [kfreebsd-amd64 kfreebsd-i386]
gr-osmosdr: gr-osmosdr [kfreebsd-amd64 kfreebsd-i386]
libgnuradio-osmosdr0.1.3 [kfreebsd-amd64 kfreebsd-i386]
kig: kig [hurd-i386]
librime: librime-bin [hurd-i386]
 librime1 [hurd-i386]
limereg: limereg [mips mipsel]
mongodb: mongodb-clients [hurd-i386 kfreebsd-i386]
 mongodb-server [hurd-i386 kfreebsd-i386]
openvrml: libopenvrml9 [amd64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
  openvrml-lookat [amd64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
pcb2gcode: pcb2gcode [kfreebsd-amd64 kfreebsd-i386]
qbittorrent: qbittorrent [kfreebsd-amd64 kfreebsd-i386]
 qbittorrent-nox [kfreebsd-amd64 kfreebsd-i386]
qpid-cpp: libqpidcommon2 [amd64 arm64 i386 mipsel powerpc ppc64el]
  qpidd [amd64 arm64 i386 mipsel powerpc ppc64el]
smc: smc [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel 
powerpc s390x]
swift-im: libswiften-dev [amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x]
  libswiften2 [amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
  swift-im [amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]

-- 
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#822120: Boost 1.55 to be removed; your attention required

2016-04-21 Thread Steve M. Robbins 
Package: feel++
Severity: normal

Boost 1.55 has not built correctly since the GCC 5 introduction in July 2015 
and I plan
to ask for its removal from unstable very shortly.  It has already been removed 
from
testing.

The package feel++ appeared on a list of reverse dependencies generated 
using 'dak rm -Rn boost1.55' (see below).  This bug is to request an
upload with updated boost dependencies.

If your package build-depends on the default boost, then a simple rebuild will 
suffice.
If your package uses 1.55-versioned build-deps, then please check whether you 
can
move to default boost.  Or if not, at least move to 1.58.

Output from ssh mirror.ftp-master.debian.org "dak rm -Rn boost1.55" follows.

Checking reverse dependencies...
# Broken Depends:
ball: ballview [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libball1.4 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libballview1.4 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  python-ball [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  python-ballview [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
cufflinks/non-free: cufflinks [amd64]
diet: diet-agent [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-admin2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-client2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-dagda2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
  libdiet-sed2.8 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
feel++: feel++-apps [amd64 i386 powerpc]
libfeel++1 [amd64 i386 powerpc]
gqrx-sdr: gqrx-sdr [kfreebsd-amd64 kfreebsd-i386]
gr-air-modes: gr-air-modes [kfreebsd-amd64 kfreebsd-i386]
  libair-modes0 [kfreebsd-amd64 kfreebsd-i386]
gr-osmosdr: gr-osmosdr [kfreebsd-amd64 kfreebsd-i386]
libgnuradio-osmosdr0.1.3 [kfreebsd-amd64 kfreebsd-i386]
kig: kig [hurd-i386]
librime: librime-bin [hurd-i386]
 librime1 [hurd-i386]
limereg: limereg [mips mipsel]
mongodb: mongodb-clients [hurd-i386 kfreebsd-i386]
 mongodb-server [hurd-i386 kfreebsd-i386]
openvrml: libopenvrml9 [amd64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
  openvrml-lookat [amd64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
pcb2gcode: pcb2gcode [kfreebsd-amd64 kfreebsd-i386]
qbittorrent: qbittorrent [kfreebsd-amd64 kfreebsd-i386]
 qbittorrent-nox [kfreebsd-amd64 kfreebsd-i386]
qpid-cpp: libqpidcommon2 [amd64 arm64 i386 mipsel powerpc ppc64el]
  qpidd [amd64 arm64 i386 mipsel powerpc ppc64el]
smc: smc [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel 
powerpc s390x]
swift-im: libswiften-dev [amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x]
  libswiften2 [amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]
  swift-im [amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el 
s390x]

-- 
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#780186: GMP doesn't manage memory correctly

2015-06-08 Thread Steve M. Robbins 
On Tue, Mar 10, 2015 at 09:07:52AM +0100, Julien Puydt wrote:
> Package: gmp
> Version: 2:6.0.0+dfsg-6
> 
> Hi,
> 
> the sagemath software is using MPIR, but we're trying to package it for
> debian using the default lib for multi-precision arithmetic : GMP.
> 
> Sagemath uses mp_set_memory_functions to override the default memory
> management and make it better for their purpose (trigger their error
> handling), but there are places where gmp still calls its own functions!

Please list the places.


> And we have a failing test in their suites where an abort is triggered,
> because _mpz_realloc in mpz/realloc.c is called instead of the
> sagemath-provided realloc.

"their" suites -- is that a GMP test suite or something else?


> GMP shouldn't call its own realloc if a better one has been provided.

I'll need more information to process this bug further.

Thanks,
-Steve


signature.asc
Description: Digital 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

Re: Bug#745233: libhogweed2: should have versioned depend on newer libgmp10

2014-04-22 Thread Steve M. Robbins 
Well,

Thank you.

On April 21, 2014 04:56:21 PM Niels Möller wrote:
> Magnus Holmgren  writes:
> > Oh well, I went ahead and did it for you. However, as you can see, some
> > symbols went missing in both 5.1 and 6.0.
> 
> Are those the ones in the #MISSING: lines in your file? They are all
> undocumented internal functions in GMP.

I think I understand the rationale for using the super-fine-grained symbol 
versioning.  If someone from the debian-science-maintainers team would like to 
maintain this file, please go ahead and commit it to the repository.  
Unfortunately, I don't have the time to audit each release; so if left to me, 
I will use the easy and conservative "dh_makeshlibs -V" solution.

Regards,
-Steve


signature.asc
Description: This is a digitally signed message part.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#744302: mpz_invert behavior -addendum

2014-04-22 Thread Steve M. Robbins 
On April 22, 2014 07:43:18 PM Benjamin Eltzner wrote:
> Ah, yes, sorry I forgot about that. The bug can be closed.

Done.  For future reference: you can close the bug yourself simply by emailing 
nnn-d...@bugs.debian.org.

Regards,
-Steve



signature.asc
Description: This is a digitally signed message part.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#745233: libhogweed2: should have versioned depend on newer libgmp10

2014-04-20 Thread Steve M. Robbins 
On April 20, 2014 06:59:31 PM Magnus Holmgren wrote:
> reassign 745233 libgmp10
> retitle 745233 libgmp10: Wrong shlibs information after 6.0.0 adds new
> symbols affects 745233 libhogweed2
> thanks
> 
> söndagen den 20 april 2014 12.55.09 Ivo De Decker:
> > On Sun, Apr 20, 2014 at 01:14:18AM +0200, Magnus Holmgren wrote:
> > > That kind of thing should never happen; that's what we have shlibs and
> > > symbols files for. Do you know if there's any reason that libgmp10
> > > doesn't include a symbols file and/or declare new a minimum version in
> > > it's shlibs file?
> > 
> > I agree that this shouldn't happen, but I don't know why libgmp10 doesn't
> > include symbols or shlibs files that enforce this dependency. I'm adding a
> > Cc to to gmp maintainers.

Well, the reason would be ignorance and sloth on my part.  :-(

 
> I think I can even dare reassign the bug. Please update the dh_makeshlibs
> command for gmp 6.0.0 

So to be sure: adding "-V" is the right thing to do here?

Thanks,
-Steve



signature.asc
Description: This is a digitally signed message part.
-- 
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#744302: mpz_invert yields wrong result

2014-04-12 Thread Steve M. Robbins 
On Sat, Apr 12, 2014 at 07:08:35PM +0200, Benjamin Eltzner wrote:

> I have no idea, whether this bug is in the package or in the upstream
> library. If it concerns upstream, I would be very glad if you forwarded
> it and set me to CC.

There is only one tiny patch to gmp in this version: to disable one
bit of assembly in arm/thumb; c.f. #742814.  So this issue is either
an upstream bug or a usage problem.

I can't tell which, so I suggest you contact upstream with all the
required information https://gmplib.org/#BUGREPORTS One of the items
required will be a complete self-contained program, which you almost
provided.

Regards,
-Steve


signature.asc
Description: Digital 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

Re: Bug#742814: please address the issue, don't work around it (assembly not ready for ARM Thumb)

2014-04-06 Thread Steve M. Robbins 
On April 6, 2014 12:12:29 PM Matthias Klose wrote:
> Control: reopen -1
> Control: severity -1 important
> Control: tags -1 + help
> 
> you applied a work around, but didn't fix the issue. Please keep the issue
> open until it is addressed.

I fixed the build failure with a patch from upstream, so #742814 is indeed 
closed.

There is no upstream support for Thumb assembly.   You already reported this 
in #649740 and that issue remains open with a request for help from upstream:

This looks incomplete, and is not documented.  I will not apply a
patch in such a state, sorry.

Please do follow-up with gmp-devel mailing list.

Regards,
-Steve


signature.asc
Description: This is a digitally signed message part.
-- 
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#743177: libvtk6 should conflicts with libvtk5.8

2014-04-01 Thread Steve M. Robbins 
On April 1, 2014 09:12:24 AM Anton Gladky wrote:
> 2014-03-31 10:58 GMT+02:00 Mathieu Malaterre :
> > Typical scenarios that should not happen is an app linked against
> > vtkCommon and vtkCommonCore. This gets even worst with python
> > 
> > $ python
> > import vtkCommon
> > import vtkCommonCore
> 
> We can declare as conflicting python-vtk and python-vtk6.
> IMHO we get a lot of troubles, declaring libvtk5.8 and libvtk6 as
> conflicting.

I agree with the last statement.  

Now I'm just curious about the original motivation for the bug.  Mathieu: did 
you experience some trouble?

-Steve


signature.asc
Description: This is a digitally signed message part.
-- 
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#743177: libvtk6 should conflicts with libvtk5.8

2014-04-01 Thread Steve M. Robbins 
On April 1, 2014 08:59:13 AM you wrote:
> As explained in details libs have different SONAME (vtkCommon !=
> vtkCommonCore) however they provide the same symbols (up to the ABI
> diff). This is bad (tm) !

Sorry, what details are you referring to?

-Steve



signature.asc
Description: This is a digitally signed message part.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Bug#743177: libvtk6 should conflicts with libvtk5.8

2014-03-31 Thread Steve M. Robbins 
On March 31, 2014 10:58:28 AM Mathieu Malaterre wrote:
> Package: libvtk6
> 
> Clearly there is something missing here. libvtk6 can be co-installed
> with libvtk5.8. VTK API (ABI too) is completely incompatible in
> between those two versions.

Clearly I'm missing something, because it is routine to have different-SONAME 
versions of a library co-installable.  That is largely the point of having the 
SOVERSION in the package name.

 
> Typical scenarios that should not happen is an app linked against
> vtkCommon and vtkCommonCore. 

These have the SOVERSION correctly set in the library, don't they?  The 5.8 
libraries do 

steve@riemann{~}objdump -p /usr/lib/libvtkCommon.so.5.8.0|grep SON
  SONAME   libvtkCommon.so.5.8

and while I don't have 6.0 installed, the list of files shows the library names 
all end with ".so.6.0".

Any application will contain within it a list of the SONAMES required, so 
there is no confusion if both libvtkCommon.so.5.8 and libvtkCommon.so.6.0 are 
present on the system.


> This gets even worst with python
> 
> $ python
> import vtkCommon
> import vtkCommonCore

Well, this is a problem in that the python scripts don't or can't declare 
which version of VTK API they conform to.  I presume the trouble is that 
"import vtkCommon" brings in a different API on 5.8 v.s. 6.0.  If so, that is a 
still a problem even if the two packages conflict: I may write a script for the 
5.8 API, then upgrade to VTK 6 (removing VTK 5.8) and the script is broken.

-Steve


signature.asc
Description: This is a digitally signed message part.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Boost needs help

2014-03-12 Thread Steve M. Robbins 
On March 12, 2014 01:56:26 PM Jose Luis Rivero wrote:
> New boost release version (-5) was uploaded fixing the bug 739904 according
> to the changelog[1].

Yes.  Strangely sometime after I sent the "help boost" message to the mailing 
list, my originally-rejected upload got published.  I appreciate that.  

However; no-one contacted me to say what changed, so I expect the next upload 
will face similar issues and the request for help still stands.

-Steve



> 
> [1]
> http://metadata.ftp-master.debian.org/changelogs//main/b/boost1.54/boost1.54
> _1.54.0-5_changelog
> 
> 
> On Wed, Mar 5, 2014 at 10:20 AM, Leopold Palomo-Avellaneda  > wrote:
> > 
> > A Dimecres, 5 de març de 2014, Steve M. Robbins va escriure:
> > > On March 3, 2014 09:22:01 AM Leopold Palomo-Avellaneda wrote:
> > > > > [1] https://svn.boost.org/trac/boost/ticket/8731
> > > > > [2] https://svn.boost.org/trac/boost/changeset/84950
> > > > > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739904
> > > > > [4] https://bugs.gentoo.org/show_bug.cgi?id=482372
> > > > 
> > > > Thanks Jose,
> > > > 
> > > > so, when the new package of boost were upload, then we can try to
> > > > build
> > > > again and see if it works... I hope so.
> > > 
> > > The fix for this bug has been made and uploaded.
> > > 
> > > Unfortunately, the upload was rejected for unrelated bugs.  Apparently
> > 
> > they
> > 
> > > are "serious" bugs but not the kind I am not motivated to fix.  So
> > 
> > patches
> > for
> > 
> > > #735339 and #735353 would be welcome.  Please work against
> > > svn.debian.org/svn/pkg-boost/boost/branches/1.54.0
> > 
> > Hi,
> > 
> > I don't know if I'm surprised, thinking if it's Aprils fools or what.
> > Simply I
> > don't understand the situation. Anyway, looking the bugs:
> > 
> > 735339:Non free w3m valid icons
> > 
> > I think that it could be several solutions. One is repack the source
> > without
> > that file. I don't know how to send a patch for this. It's a NMU. Maybe,
> > we
> > can change the icon, but ...
> > 
> > If it's just to change the icon, I can borrow the equivalent icons from
> > piuparts and change it.
> > 
> > And the last is create a libboost-nonfree with all this stuff.
> > 
> > 
> > 735353: Sourceless file
> > 
> > I have no idea about javascript. Looking the files the are scripts, some
> > firstly I don't understand the bug. However, I imagine that this "strange
> > files" come from some sources, and the file provided is just the exit from
> > another script.
> > 
> > I don't know sufficiently the policies but maybe it could be sufficient
> > do:
> > or put a note in the README with the two links from where download the
> > sources,
> > or include the two sources in some place of the package.
> > 
> > 
> > Regards,
> > 
> > Leopold
> > 
> > 
> > 
> > --
> > --
> > Linux User 152692
> > Catalonia


signature.asc
Description: This is a digitally signed message part.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers