I applied the patch that jcowgill submitted upstream plus another upstream
commit and disabled vdpau support (which has been removed upstream) and was
able to get the debian package to build, so I uploaded it to raspbian.
A debdiff should appear soon at
package: ipe-tools
severity: serious
version: 1:7.2.7-1
ipe-tools failed to build from source during the re-builds for the poppler
transition.
https://buildd.debian.org/status/fetch.php?pkg=ipe-tools=amd64=1%3A7.2.7-1%2Bb3=1540034720=0
pdftoipe.cpp: In function 'int main(int, char**)':
Found 917598 3.10.0-3
thanks.
Unfortunately it seems it still fails with the same error.
On 29/12/18 20:21, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the petsc4py package:
#917598: petsc4py FTBFS error: ‘SNESTEST’
Package: sagemath
Version: 8.4-2
Severity: serious
sagemath versions from 8.4-2 through to 8.6-2 have failed to build on mipsel
and mips64el.
mipsel is failing with
Success: 42 tests failed, up to 90 failures are tolerated
Error: critical test failures (e.g. timeout, segfault, etc.)
make[2]:
package: timbl
version: 6.4.8-1
severity: serious
timbl and libtimbl4 depend on libticcutils2v5 and the timbl source package
depends on libtimbl4-dev. These packages are no longer build by the ticcutils
source package.
I notice there is a new version in new that looks like it probablly fixes
Package: pivy
Version: 0.6.4-1
Severity: serious
pivy cannot be built on mips/mipsel because of a depedency on pyside2 which is
not built on mips/mipsel pyside2 is not being built on those architectures due
to a dependency on patchelf. patchelf is not currently building on mips* due to
a
package: petsc4py
version: 3.10.0-2
severity: serious
While trying to get the petsc/slepc/etc stack in raspbian buster into a
consistent state I ran into the following error with petsc4py. I was also able
to reproduce this in a Debian sid amd64 environment, so it's not raspbian
specific.
Package: python-escript
Version: 5.2-4
Severity: serious
The most recent upload of python-escript failed to build on armhf, mipsel,
mips64el and mips. All seemed to fail while linking a C++ library.
g++ -o debian/tmp2/posix/weipa/src/libescriptreader.so -Wl,-z,relro -Wl,-z,now
-fopenmp
Package: getdp
Version:3.0.4+dfsg1-1
Severity: serious
Tags: patch, bullseye, sid
getdp build-depends on texlive-generic-recommended which is no longer built by
texlive-base. Please update your build-dependency to texlive-plain-generic.
--
debian-science-maintainers mailing list
Severity 938494 serious
Thanks
skimage (build-)depends on python-cloudpickle which has already been dropped by
the cloudpickle source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
severity 937593 serious
thanks
python-aws-xray-sdk depends on the python-wrapt binary package which has
already been dropped by the python-wrapt source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Severity 938551 serious
Thanks
spyder-kernels (build-)depends on python-cloudpickle which has already been
dropped by the cloudpickle source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Severity 938550 serious
Thanks
spyder (build-)depends on python-cloudpickle which has already been dropped by
the cloudpickle source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
severity 938804 serious
thanks
python-vtk6 depends on the python-autobahn binary package which has already
been dropped by the python-autobahn source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: pspp
Version: 3.5.2-1
Tags: bullseye, sid, patch
Severity: serious
pspp build-depends on texlive-generic-reccomended which is no longer built by
the texlive-base source package. Please build-depend on texlive-plain-generic
instead.
--
debian-science-maintainers mailing list
package: libopencv-imgcodecs-dev
version: 4.1.2+dfsg-4
severity: serious
The libopencv-imgcodecs-dev binary package depends on and the opencv source
package build-depends on libgdcm2-dev which is no longer built by the gdcm
source package.
--
debian-science-maintainers mailing list
severity 936190 serious
thanks
python-bcolz depends on python-pandas which is no longer built by the pandas
source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
It looks like gdcm recently replaced libgdcm2-dev, libgdcm2.8, libvtkgdcm2-dev
and libvtkgdcm2.8a with libgdcm2-dev, libgdcm2.8, libvtkgdcm2-dev and
libvtkgdcm2.8a
The cruft report shows a bunch of stuff (build-)depending on the old packages.
Only insighttoolkit4 seems to have been updated for
Package: silx
Version:0.11.0+dfsg-2
Severity: serious
silx build-depends on ipython3-qtconsole which is no longer built by the
python-qtconsole source package. It is still present in unstable as a cruft
package, but is completely gone from testing.
Please change your build-dependency to
Should the package attempt to clean this up (and if so is there a better
method than unconditionally deleting those directories), or is
permanently leaving this behind (to become more and more obsolete, and
potentially be read by users looking for the current documentation) the
best that can be
severity 938481 serious
thanks
silx depends on python-h5py which has already been dropped by the h5py source
package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
severity 937745 serious
thanks
python-fabio depends on python-h5py which has already been dropped by the h5py
source package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: sardana
Version: 3.0.0a+3.f4f89e+dfsg-1
Severity: serious
The release team have decreed that non-buildd binaries cannot migrate to
testing. Please make a source-only upload so your package can migrate.
--
debian-science-maintainers mailing list
On 17/10/2019 22:23, PICCA Frederic-Emmanuel wrote:
ok, but this packages comes from NEW.
So it would be nice if the process NEW -> unstable could be a source upload.
Ir is not possible to upload without the binary in New.
This processus necessitate two uploads if I understand correctly.
Package: python-fabio
Version: 0.9.0+dfsg-2
Severity: serious
Python-fabio's autopkgtest is failing,
==
ERROR: testFullFormatName (fabio.test.testfabioconvert.TestFabioConvert)
All three failures give the error message
OverflowError: Python int too large to convert to C long
from
File "sage/rings/polynomial/polynomial_integer_dense_flint.pyx", line 284, in
sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint.__init__
severity 936684 serious
thanks
h5py build-depends on the python-pkgconfig binary package, which is no longer
built by the python-pkgconfig source package. The binary package is still
present in unstable as a cruft package, but is completely gone from testing.
--
debian-science-maintainers
Disabling the PROJ support was not an option as it was for vtk6. You may
want to reinstate the embedded copy and use that instead.
It looks like a commit doing this was made on salsa on august 6th
https://salsa.debian.org/science-team/vtk7/commit/19d6e5e2e02cbd10404dd96e750370546feaa82b
Is
Severity 934870 serious
Thanks
statsmodels in testing build-depends on python-cvxopt, which is no longer
present in testing or unstable.
This is fixed in the unstable statsmodels package (by dropping the python 2
binary package), unfortunately that is failing to migrate due to an autopkgtest
Package: statsmodels
Version: 0.10.2-1
Severity: serious
Statsmodels autopkgtest is failing, both in the unstable to testing migration
tests, and in the pure unstable tests.
The migration test is failing with the following error (
On 23/12/2019 04:15, Ximin Luo wrote:
I've set the severity of this bug to important, because it should not block
migration.
If this were a regression then it would be RC, but since sagemath is already
not in testing, it is not a regression. There is no reason or policy to block
migration
tags 950433 +patch
tags 944055 +patch
thanks
As has been reported linbox is currently blocked from migrating to testing by
build failures on armhf and mipsel autobuilders.
In some armhf environments (notablly on Debian porterboxes and buildds with
arm64 kernels), linbox fails to build with
Package: linbox
Version: 1.6.3-1
Severity: serious
Since I was looking at the linbox failure on armhf, I figured i'd have a look
at the mipsel one too. Based on past experiences with other packages, I was
expecting it to also be related to alignment issues.
However I was wrong! It seems it is
libm4ri is in NEW
I would guess that the maintainer uploaded libm4ri and libm4rie to the new
queue together, but the ftpmasters only released the latter and not the former.
The question I guess is whether it is worth doing a source only upload of
libm4rie now, only to have to get it rebuilt
Package: pysph
Version: 1.0~b0~20191115.gite3d5e10-1
Severity: serious
The most recent upload got pysph building on amd64 on the autobuilders, but it
still failed for all the other release architectures (it succeeded for some
debian-ports architectures, but some of them may be building with
severity 937543 serious
thanks
pysph in testing build-depends on python-enthoughtbase, which has been removed
from testing and unstable.
This is fixed in unstable, but the fix is blocked from migrating to testing by
bug 945326
--
debian-science-maintainers mailing list
(using -quiet aliases where multiple involved packages have the same maintainer
listed.
Hi
I have just been running some self-contained buildability tests on bullseye and
these tests indicated that the python-linecache2 and python-traceback2 source
packages have been unbuildable in testing
On 20/04/2020 08:57, Thomas Goirand wrote:
Option 1: fix all four packages to be python 2 free.
Option 2: Remove python2 stuff from traceback2, python-funcsigs and
numba. Break the dependencies of nipype in sid.
Option 3: Remove python2 stuff from traceback2, modify python-funcsigs
so it still
Package: mlpy
Version: 3.5.0+ds-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing, please make a source-only upload so your package can migrate.
--
debian-science-maintainers mailing list
Package: ignition-transport
Version: 8.0.0+dfsg-3
Severity: serious
It seems that ignition-transport fails to build in testing with the following
error.
CMake Error in src/CMakeLists.txt:
Imported target "ZeroMQ::ZeroMQ" includes non-existent path
"-isystem"
in its
severity 943135 serious
tags 943135 +patch
thanks
This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:
(source:numba)Testsuite-Triggers->python-all-dev
(source:numba)Testsuite-Triggers->python-funcsigs
On 21/04/2020 22:20, Thomas Goirand wrote:
So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.
Yes, whichever approach is taken to dealing with funcsigs, unittest2
Package: sleef
Version: 3.4.1-4
Severity: serious
The most recent upload of sleef fixed the build on amd64, armhf, i386 and
ppc64el. Unfortunately
it is still failing on arm64, with the following error.
In file included from /<>/src/libm/sleefsimdsp.c:209:
/<>/src/arch/helpersve.h:94:27:
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Package: ipe-tools
Severity: serious
Version: 1:7.2.7.2-4
Tags: patch
ipe-tools fails to build with poppler 0.85, there are multiple issues.
I whipped up a patch and uploaded it to raspbian, A debdiff should appear
soon at https://debdiffs.raspbian.org/main/i/ipe-tools
I notice it looks like
tags 968637 +patch
thanks
On 26/08/2020 06:04, peter green wrote:
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
I was able to succesfully apply the upstream change to the
Debian package and built it in Raspbian bullseye-staging .
I also bumped the build
Tags 993269 +patch
thanks
I decided to have a poke around to see if anyone else had fixed this. I
followed the homepage link
to e-antic FTBFS with flint 2.8.0 and noted that the "master" branch was a
much newer release series,
but there was also a "master0" branch. Selecting that branch told
Package: bagel
Version: 1.2.2-3
Severity: serious
x-debbugs-cc: mp...@packages.debian.org
bagel's autopkgtest is failing on amd64 with mpich 4.0.1-1 and hence
blocking it's migration to testing and hence blocking the finalisation
of the slurm-wlm transition.
Package: fenics-basix
Version: 0.3.0-11
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release."
Your package build-depends on python3-numba.
Unfortunately numba is not ready for python 3.10, it has been removed from
testing
and since the recent upload
Package: arachne-pnr
Version: 0.1+20190728gitc40fb22-2
Tags: bookworm, sid
Severity: serious
arachne-pnr build-depends on fpga-icestorm-chipdb which is no longer built by
the fpga-icestorm source package, it is still present in unstable as a cruft
package, but is completely gone from testing.
The skimage autopkgtest usually, but not always, fails on armhf with several
out-of-memory errors
BTW "out-of-memory" errors nearly always relate to address space rather than
actual memory. The Linux kernel overcommits memory by default, so actually
running out of memory is more likely to
Package: calculix-cgx
Version: 2.17+dfsg-2
Severity: serious
Tags: trixie, sid
calculix-cgx build-depends on libgl1-mesa-glx which is no longer built by the
mesa source package. It is still present in unstable and on a couple of
architectures in testing as a cruft package, but it is completely
vtk7 is one of the (possiblly the) last blockers for the ffmpeg transition
that is in testing and is not marked for autoremoval.
The last 7.x upstream release was over 5 years ago. The last vtk7 upload
by someone listed in "uploaders" was over 2 years ago. Since then the
package has been kept on
Package: dask.distributed
Version: 2022.12.1+ds.1-1
Severity: serious
X-debbugs-cc:
pkg-grass-de...@lists.alioth.debian.org,debian-science-maintain...@lists.alioth.debian.org
The autopkgtest for dask.distributed is failing.
Package: python3-brial
Version: 1.2.11-2
Severity: serious
X-debbugs-cc: singu...@packages.debian.org
python3-brial recently added a dependency on python3-sage, however python3-sage
is only available on amd64, arm64, i386 and riscv64.
This also means that the build-depends of singular on those
Package: librsb
Version: 1.3.0.2+dfsg-1
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
librsb build-depends on coccinelle which appears to have been removed
on
Package: facet-analyser
Version: 0.0~git20221121142040.6be10b8+ds1-3
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: s...@debian.org
facet-analyser
kalzium needs to be rebuilt for the time64 transition, but it has had
a FTBFS bug with no maintainer response for 4 months. The only reverse
dependencies seem to be a number of metapackages.
In particular, the kdeedu package is a key package and has a hard
dependency on kalzium. This means that
58 matches
Mail list logo
