Bug#862542: reprozip: File conflict: trying to overwrite '/usr/bin/reprozip', which is also in package python3-reprozip:i386 1.0.9-2

2017-05-14 Thread Axel Beckert 
Source: reprozip
Version: 1.0.9-2
Severity: serious

Upgrading reprozip from 1.0.9-1 to 1.0.9-2 fails for me as follows:

Preparing to unpack .../19-reprozip_1.0.9-2_all.deb ...
Unpacking reprozip (1.0.9-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-LZ6LIl/19-reprozip_1.0.9-2_all.deb (--unpack):
 trying to overwrite '/usr/bin/reprozip', which is also in package 
python3-reprozip:i386 1.0.9-2
Errors were encountered while processing:
 /tmp/apt-dpkg-install-LZ6LIl/19-reprozip_1.0.9-2_all.deb

On another machine (the one I'm writing this report on) it fails the
other way round (due to different upgrade order):

Preparing to unpack .../python3-reprozip_1.0.9-2_amd64.deb ...
Unpacking python3-reprozip:amd64 (1.0.9-2) over (1.0.9-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python3-reprozip_1.0.9-2_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/reprozip', which is also in package reprozip 
1.0.9-2
Errors were encountered while processing:
 /var/cache/apt/archives/python3-reprozip_1.0.9-2_amd64.deb

Seems as if /usr/bin/reprozip has been installed by accident into both
packages, python3-reprozip and reprozip.

See also https://piuparts.debian.org/sid/source/r/reprozip.html which
has caught this issue, too.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reprozip depends on:
ii  python3-reprozip  1.0.9-1
pn  python3:any   

reprozip recommends no packages.

reprozip 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#803552: libeigen3-dev: Upgrade from 3.2.x to 3.3~alpha causes gnudatalanguage to FTBFS on arm64

2015-11-09 Thread Axel Beckert 
Hi,

Anton Gladky wrote:
> thanks for bugreport, I will try to contact upstream
> regarding this issue, usually they are very responsive. So
> I hope we will solve this issue as far as possible.

Looks promising so far: It has been added as blocker for the 3.3
release and it has been assigned to someone:
http://eigen.tuxfamily.org/bz/show_activity.cgi?id=1103

Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

-- 
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#803552: libeigen3-dev: Upgrade from 3.2.x to 3.3~alpha causes gnudatalanguage to FTBFS on arm64

2015-10-31 Thread Axel Beckert 
Package: libeigen3-dev
Version: 3.3~alpha1-2
Severity: grave
Control: affects -1 src:gnudatalanguage
Justification: Makes package unusable on one release architecture

Hi,

with the most recent upload of gnudatalanguage (which just changed
documentation stuff), it deterministically FTBFS on arm64 -- and only
there (not counting non-release architectures which have different
issues):

https://buildd.debian.org/status/package.php?p=gnudatalanguage
https://buildd.debian.org/status/fetch.php?pkg=gnudatalanguage=arm64=0.9.5-3=1445723100

Example log excerpt:

In function 'float64x2_t vdupq_lane_f64(float64x1_t, int)',
inlined from 'Packet Eigen::internal::pmul(const Packet&, const Packet&) 
[with Packet = Eigen::internal::Packet1cd]' at 
/usr/include/eigen3/Eigen/src/Core/arch/NEON/Complex.h:329:22,
inlined from 'Packet Eigen::internal::pmadd(const Packet&, const Packet&, 
const Packet&) [with Packet = Eigen::internal::Packet1cd]' at 
/usr/include/eigen3/Eigen/src/Core/GenericPacketMath.h:450:14,
inlined from 'static void Eigen::internal::etor_product_packet_impl<0, -1, 
Lhs, Rhs, Packet, LoadMode>::run(Eigen::Index, Eigen::Index, const Lhs&, const 
Rhs&, Eigen::Index, Packet&) [with Lhs = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; Rhs = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; Packet = Eigen::internal::Packet1cd; int 
LoadMode = 0; Eigen::Index = long int]' at 
/usr/include/eigen3/Eigen/src/Core/ProductEvaluators.h:601:7,
inlined from 'const PacketType 
Eigen::internal::product_evaluator, ProductTag, 
Eigen::DenseShape, Eigen::DenseShape, typename Lhs::Scalar, typename 
Rhs::Scalar>::packet(Eigen::Index, Eigen::Index) const [with int LoadMode = 0; 
PacketType = Eigen::internal::Packet1cd; Lhs = 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>; Rhs = Eigen::Map, 16, 
Eigen::Stride<0, 0> >; int ProductTag = 8; typename Rhs::Scalar = 
std::complex; typename Lhs::Scalar = std::complex; Eigen::Index 
= long int]' at /usr/include/eigen3/Eigen/src/Core/ProductEvaluators.h:493:5,
inlined from 'void 
Eigen::internal::generic_dense_assignment_kernel::assignPacket(Eigen::Index, Eigen::Index) 
[with int StoreMode = 16; int LoadMode = 0; PacketType = 
Eigen::internal::Packet1cd; DstEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; SrcEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1> >; Functor = Eigen::internal::assign_op; int 
Version = 0; Eigen::Index = long int]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:598:5,
inlined from 'void 
Eigen::internal::generic_dense_assignment_kernel::assignPacketByOuterInner(Eigen::Index, 
Eigen::Index) [with int StoreMode = 16; int LoadMode = 0; PacketType = 
Eigen::internal::Packet1cd; DstEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> > >; SrcEvaluatorTypeT = 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1> >; Functor = Eigen::internal::assign_op; int 
Version = 0; Eigen::Index = long int]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:612:5,
inlined from 'static void Eigen::internal::dense_assignment_loop::run(Kernel&) [with Kernel = 
Eigen::internal::generic_dense_assignment_kernel, 16, Eigen::Stride<0, 0> > >, 
Eigen::internal::evaluator, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1> >, Eigen::internal::assign_op, 0>]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:516:9,
inlined from 'void Eigen::internal::call_dense_assignment_loop(const 
DstXprType&, const SrcXprType&, const Functor&) [with DstXprType = 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>; SrcXprType = Eigen::Product, 16, Eigen::Stride<0, 0> >, 
Eigen::Map, 16, Eigen::Stride<0, 0> 
>, 1>; Functor = Eigen::internal::assign_op]' at 
/usr/include/eigen3/Eigen/src/Core/AssignEvaluator.h:659:3:
/usr/lib/gcc/aarch64-linux-gnu/5/include/arm_neon.h:14027:10: error: lane 1 out 
of range 0 - 0
   return

Bug#803552: libeigen3-dev: Upgrade from 3.2.x to 3.3~alpha causes gnudatalanguage to FTBFS on arm64

2015-10-31 Thread Axel Beckert 
Hi Anton,

Anton Gladky wrote:
> thanks for bugreport, I will try to contact upstream
> regarding this issue, usually they are very responsive. So
> I hope we will solve this issue as far as possible.

Thanks, much appreciated.

> There were reasons, why I uploaded alpha version into sid.
> First of all this version was precisely tested for all packages
> (yes, arm64 was not used for that). But the main reason is
> the following: starting from 3.3 old eigen2-support will be
> dropped. So affected packages were NMU-ed, dropping
> eigen2-interface and migrating to eigen3. To escape the new
> package uploads into the sid, which could potentially use
> eigen2, this alpha version was uploaded.

I see, thanks for the explanation. (I actually didn't mind uploading
alpha versions to Sid, especially if they're well tested. I just
mentioned it because for me it raised the probability that the issue
is not in gnudatalanguage. :-)

> Regarding bug`s severity, I think it should be important. This
> affects only one package on one architecture, even if it is
> a release architecture.

Feel free to downgrade the severity. As mentioned I veered between
those two severities.

> I can just propose now to remove gnudatalanguage on arm64 till the
> issue is not resolved.

That's my plan B, yes. ;-)

But I'll first wait a little bit more before I'll do this.

        Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers