Package: cmtk
Version: 3.3.1-1.2
Severity: serious
cmtk FTBFS in sid. Preusmablly this is caused by the new dcmtk
https://buildd.debian.org/status/fetch.php?pkg=cmtk=amd64=3.3.1-1.2%2Bb2=1547410724=0
/<>/apps/dcm2image.cxx: In function 'void AddPatternToMap(std::map >&, const char*)':
Control: tag -1 pending
Hello,
Bug #917982 in fenix reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Package: python-gpiozero
Version: 1.4.1-1
Severity: serious
The 1.4.1-1 upload of gpiozero added the "pinout" utility, unfortunately it
added it to both the python-gpiozero and python3-gpiozero packages. The result is a file
conflict between the two packages.
I see two possible solutions.
1.
and python3-yaml (Closes: 918645)
+
+ -- Peter Michael Green Thu, 10 Jan 2019 06:14:08 +
+
dfwinreg (20181214-2) unstable; urgency=medium
* watch: Mangle download filename
diff -Nru dfwinreg-20181214/debian/control dfwinreg-20181214/debian/control
--- dfwinreg-20181214/debian/control2018-12-21
usr/lib/*/libsocksd.la
...this is a better approach, thank you very much for suggesting it
and for the bug report itself!
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7
package: python3-dfwinreg
version: 20180712-1
severity: serious
It seems that with the most recent upload the build-dependencies were fixed from "dtfabric" to
"python-dtfabric" and "python3-dtfabric", but the binary dependencies for python-dfwinreg and
python3-dtwinreg are still on "dtfabric",
reassign 914607 dfwinreg
found 914607 20180712-1
fixed 914607 20181214-2
thanks
Britney gets confused when a bug is closed by a package other than the one it
is filed against, so I am reassinging the bug to the package that closed it.
On 01/01/19 23:09, Debian Bug Tracking System wrote:
This
18-12-25 15:30:09.0 +
+++ meep-lam4-1.7.0/debian/changelog2019-01-03 02:10:44.0 +
@@ -1,3 +1,9 @@
+meep-lam4 (1.7.0-2+rpi1) buster-staging; urgency=medium
+
+ * Fix postinst and prerm scripts for python-meep-mpich2 to use correct
package name.
+
+ -- Peter Michael Green Thu,
2 (1.7.0-2+rpi1) buster-staging; urgency=medium
+
+ * Fix postinst script for python-meep-mpich2 to use correct package name.
+
+ -- Peter Michael Green Thu, 03 Jan 2019 01:21:28
+
+
meep-mpich2 (1.7.0-2) unstable; urgency=medium
* upload to unstable
diff -Nru meep-mpich2-1.7.0/debian/
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
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: elkcode
Version: 4.0.15-2
Severity: serious
During binnmus for the libxc5 transition elkcode failed with the following
error.
mpif90 `dpkg-buildflags --get FFLAGS` `dpkg-buildflags --get CPPFLAGS` -Wall
-ffast-math -funroll-loops -fopenmp `dpkg-buildflags --get LDFLAGS` -o elk
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: pyside2
Version: 5.11.2-1
Severity: serious
It seems that patchelf has been removed on mips64el due to testsuite failures,
but pyside2 still bulid-depends on it. So pyside cannot be built on mips64el
anymore.
Possible fixes (in roughly descending order of preferences)
1. Fix the
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: openscenegraph
version: 3.2.2+dfsg1-2
severity: serious
libopenscenegraph100v5 depends on libcoin80-5 and the openscenegraph source
package bulid-depends on libcoin80-dev. These packages are no longer built by
the coin3 source package. They appear to have been replaced by libcoin80c
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: libcoq-ocaml
Version: 8.6-5
Severity: serious
libcoq-ocaml depends on liblablgtksourceview2-ocaml- (where is a
string that varies between different architectures) which is a virtual package provided by
liblablgtksourceview2-ocaml . Similarly libcoq-ocaml-dev depends on
On Fri, 07 Dec 2018, intrigeri wrote:
> Hi,
>
> Peter Palfrader:
> > onionshare uses /tmp/onionshare_server.log as a logfile with --debug.
>
> Good catch!
>
> While that code obviously conflicts with basic secure programming best
> practices, it seems t
, 'onionshare_server.log'))
tempfile.gettempdir() returns /tmp. It does not give you a
dedicated temp-directory. It is not mkdtemp.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating
Package: shibboleth-resolver
Severity: serious
Version: 1.0.0-1
Tags: sid, patch
shibboleth-resolver FTBFS, there are three issues.
Firstly it fails to find log4shib because it tries to use log4shib-config which
no longer exists. I patched configure.ac to use pkg-config instead and enabled
nflicts
++ add libcasa-python3-3 to build-depends
+ * Apply patch from
https://salsa.debian.org/debian-astro-team/python-casacore/commit/e9c031474c3f3f4abaf4c83fa32311cc3857b2ee.diff
+to fix build with new boost.
+ * Apply upsteam patch to fix build with casacore 3
+
+ -- Peter Michael Gree
Package: plaso
Version: 1.5.1+dfsg-4
Severity: serious
plaso depends on python-dfwinreg which is no longer built by the dfwinreg
source package.
tags 913708 +patch
thanks
This was one of the few remaining blockers for the icu transition in raspbian
buster, so I hacked up a fix.
I am far from an expert (just a maintainer of a Debian derivative who ran into
this build failure) but here is my interpretation of what is going on.
Control: tag -1 pending
Hello,
Bug #899439 in acmetool reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Package: keymapper
Version: 0.5.3-11
Severity: serious
keymapper depends on python-yapps2 which does not appear to exist, did you mean
to depend on python-yapps?
On 11/11/18 19:14, Nicolas Boulenguez wrote:
Package: src:gnat-gps
Followup-For: Bug #913371
Control: reopen -1
Version: 18-3
With parallelism disabled, the build should use (at least) two times
less memory at a given moment.
Virtual address space is per-process. So while disabling make-level
package: gmrender-resurrect
version: 0.0.7~git20180618.d0f46f5-2
severity: serious
gmrender-resurrect build-depends on libupnp1.8-dev and it's binary package
gmrender depends on libupnp10. These packages are no longer built by pupnp-1.8.
They appear to have been replaced by libupnp-dev and
Package: tpm2-pk11
Version: 0~git20180426-1
Severity: serious
tpm2-pk11 build-depends on libsapi-dev and depends on libsapi0, these packages
are no longer built by source package tpm2-tss. They appear to have been
replaced by libtss2-dev and libtss2-esys0 .
Package: tpm2-abrmd
Version: 1.3.1-1.1
Severity: serious
tpm2-abrmd build-depends on libsapi-dev and depends on libsapi0, these packages
are no longer built by source package tpm2-tss. They appear to have been
replaced by libtss2-dev and libtss2-esys0 .
severity 908670 important
unblock 908345 by 908670
thanks
> I think this solution makes the least effort for all involved parties
> and is in line with the practical use of this package on armhf.
I went ahead and filed the removal
requesthttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908920
Package: vibe.d
Version: 0.8.4-1
Severity: serious
Vibe.d fails to build with the following error. Presumablly this was triggered
by the upgrade to ldc 1.12.0.
https://buildd.debian.org/status/fetch.php?pkg=vibe.d=amd64=0.8.4-1%2Bb1=1540811095=0
found 902036 1.9.4.post1+dfsg-1
tags 902036 +patch
thanks
On 30/10/18 02:03, peter green wrote:
Unfortunately while the 1.9.4.post1+dfsg-1 upload fixed the ppc64el failure, it
did not fix the s390x failure.
I just took a look at this, turned out to be a typo in a #if causing a 32-bit
value
found 902036 1.9.4.post1+dfsg-1
thanks
Unfortunately while the 1.9.4.post1+dfsg-1 upload fixed the ppc64el failure, it
did not fix the s390x failure.
018-10-07 13:15:30.0 +
+++ mixxx-2.1.4~dfsg/debian/changelog 2018-10-28 03:49:20.0 +
@@ -1,3 +1,11 @@
+mixxx (2.1.4~dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove inappropriate compiler flags on arm.
+ * Fix clean target.
+
+ -- Peter Michae
Tags 911976 +patch
Thanks
This seems to be a simple case of a missing include, I just uploaded a fix to
raspbian. A debdidf should appear soon at
https://debdiffs.raspbian.org/main/b/bind-dyndb-ldap . No intent to NMU in
Debian.
depends on:
ii bzip2 1.0.6-9
ii gnupg11.4.23-1
ii gpgv1 1.4.23-1
ii libc6 2.27-6
ii xz-utils 5.2.2-1.3
aptly recommends no packages.
Versions of packages aptly suggests:
ii graphviz 2.40.1-5
-- no debconf information
--
Peter Felecan
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**)':
On 18/10/18 23:37, Steve McIntyre wrote:
That "vld1.8 {d16-d17}, [r3]" is a direct consequence of incorrectly
targetting NEON - the target registers don't exist on platforms
without it. Please fix the build of your package to do this correctly.
BTW there is a patch to rip out the incorrect
Dear Maintainer,
this problem may be related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909310
I could solve my problem by setting "Above 4GB mapping" (in the BIOS's
PCI settings) to "disabled" (following advice from Fujitsu Tech Support).
Bes
pygame in Debian testing is currently python2 only, I am sure I am not alone in
thinking this is not a good state of affairs given that pygame is frequently
used for introducing people to programming.
pygame in sid has python3 support but is held back from migrating to testing by
three rc
Package: syslog-ng
Version: 3.13.2-4.1
Severity: serious
syslog-ng failed to build on all release architectures during binnmus for the
hiredis transition. The failure seems to be in a python related test but the
build log doesn't seem to indicate why exactly it failed.
package: python-hiredis
version: 0.2.0-3
severity: serious
python-hiredis failed to build during the re-build for libhiredis0.14, this
failure does not seem to be architecture specific
Traceback (most recent call last):
File "/<>/test.py", line 4, in
import test
File
package: varnish-modules
version: 0.12.1-1+b1
severity: serious
x-debbugs-cc: team+varnish-t...@tracker.debian.org
varnish-modules depends on libvarnishapi1 which is no longer built by varnish,
it seems to have been replaced by libvarnishapi2
There does not seem to have been any attempt to
> how is a versioned break helping anything? The minimal key limit, hash
> and TLS version can be overriden via config file and this what is
> causing the problems from what I can tell. So either the remote side
> upgrades their things or the users enabled "lower security" mode.
> Is there
(note: I'm just a guy taking a flyby look at bugs)
The following script is used to generate the key:
/usr/share/synergy/gen_ssl_pem.sh
Fixing that script is easy enough, but that is only the start of fixing the
issue.
Firstly grepping the source finds a couple of other places where it seems
I literally poked that patch into debian/patches{/series}, quilt
applied it and rebuilt, and it started working for me. Maybe there's
something different about our configs?
Strange, that patch seems to slightly change how the hardcoded dh params are
loaded, but it doesn't seem to change the
hardcoded cert/key with a 4096 bit one to keep recent openssl happy.
Author: Peter Michael Green
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you
: Peter Michael Green
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: https://bugs.debian.org/
Bug
clang-6.0 and friends advertise their default target on armhf as
armv8l-unknown-linux-gnueabihf, which sounds like nonsense.
Not really "nonsense", armv8 is best known for adding 64-bit mode but it did
also add some enhancements for the 32-bit architecture. I don't know if clang has the
at 06:15:00AM +, Niels Thykier wrote:
> Sven Joachim:
> > On 2018-09-18 14:09 +0300, Peter Pentchev wrote:
> >
> >> Package: debhelper
> >> Version: 11.4
> >> Severity: serious
> >>
> >> Hi,
> >>
> >> Thanks for main
debhelper and Debian,
and keep up the great work!
G'luck,
Peter
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Loca
On 13/09/18 21:49, Andreas Tille wrote:
Hi Peter,
thanks a lot for your analysis.
On Thu, Sep 13, 2018 at 01:27:58PM +0100, peter green wrote:
4. Simply get libundead removed on armhf/raspbian. libundead seems to only have
two reverse build-dependencies neither of which has ever successfully
:29.0 +
+++ google-authenticator-20170702/debian/changelog 2018-09-16
07:31:09.0 +
@@ -1,3 +1,10 @@
+google-authenticator (20170702-1.1) UNRELEASED; urgency=medium
+
+ * Patch proposed to BTS, no intent to NMU
+ * update for libqrcode4.
+
+ -- Peter Michal Green Sun, 16 Sep
I (with my raspbian maintainer hat on) reported this to ldc upstream at
https://github.com/ldc-developers/ldc/issues/2848 and some digging has been
done. The short version is that we know what commit caused the build failures.
However that commit was a fix for mis compilation, so I don't think
On Tue, Sep 04, 2018 at 08:41:09AM -0400, Antoine Beaupré wrote:
> On 2018-09-04 11:17:42, Peter Pentchev wrote:
> > Control: tags -1 + upstream patch
>
> [...]
>
> > I'm not really sure what changed to cause this bug, but I can certainly
> > reproduce it;
rary,
> but I really have no idea...
I'm not really sure what changed to cause this bug, but I can certainly
reproduce it; moreover, it has been reported as a problem upstream[1]
and then fixed[2]. The attached patch (line numbers adapted for 1.11)
fixes it for me; an upgrade of python-sh to
Package: gtkpod
Version: 2.1.5-6
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
I installed gtkpod, ran gio mount afc://serialnumber then started
gtkpod. ~/.gtkpod did not exist before I started. The iPad is
mounted in
wrote
earlier for the Debian package. I'm aware that not closing this bug,
now that it's serious, will not allow this new upload to migrate to
testing, but this is on purpose - what this upload does is merely
a workaround, not a fix; I'll wait for upstream's reply on this.
Thanks again for everyone's eff
--- calligra-3.1.0+dfsg/debian/changelog2018-03-09 08:37:57.0
+
+++ calligra-3.1.0+dfsg/debian/changelog2018-08-22 20:34:52.0
+
@@ -1,3 +1,9 @@
+calligra (1:3.1.0+dfsg-2+rpi1) buster-staging; urgency=medium
+
+ * Add missing qt includes.
+
+ -- Peter Michael
,
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Package: php-apcu
Version: 5.1.8+4.0.11-1
Severity: grave
Tags: patch fixed-upstream
I had originally reported this to ubuntu because we first noticed it on a
machine running ubuntu, however, ubuntu doesnt seem to maintain this pkg so
therefore I am reporting this here.
After upgrading our
Package: pygame
Version: 1.9.3+dfsg2-2
Severity: serious
pygame fails to build with python 3.7
src/pypm.c:4976:18: error: 'PyThreadState {aka struct _ts}' has no member named
'exc_type'; did you mean 'curexc_type'?
if ((tstate->exc_type != NULL) & (tstate->exc_type != Py_None)) {
I
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
vdpau_render_state has disappeard and I hae no
idea what if anything
+ it can be replaced with.
+ * Remove po/de.gmo in clean target, it seems that the build process changes
it.
+
+ -- Peter Michael Green Thu, 02 Aug 2018 14:55:06
+
+
gmerlin-avdecoder (1.2.0~dfsg-9) unstable; urgency=medium
package: dracut
version: 047+31-2
severity: serious
dh_installdocs -a
dh_installdocs: Cannot find (any matches for) "README.Debian" (tried in .)
install -d debian/dracut-core/usr/share/doc/dracut-core
debian/rules:8: recipe for target 'binary-arch' failed
I initially noticed this
tags 888345+patch
thanks
I backported the upstream ffmpeg 4.0 patches to the version in Debian and was
able to get a successful build in raspbian buster, I have not tested the
results beyond that. A debdiff can be found at.
+
_Z27qRegisterNormalizedMetaTypeIP7QActionEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS5_Xaasr12QMetaTypeId2IS5_E7DefinedntsrSA_9IsBuiltInEE11DefinedTypeE@Base
2.6~beta-4
(optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP13QGraphicsItemEvPvR5QListIT_E@Base
2.6~alpha
.so.2]
/lib/x86_64-linux-gnu/libcap.so.2.25
readelf: Error: '/lib/x86_64-linux-gnu/libgpg-error.so.0.24.2': No such file
�0x0001 (NEEDED)������������ Shared
library: [libcap.so.2]
/usr/lib/apache2/modules/mpm_itk.so
cheers, Peter
signature.asc
Description: Digital Signature
During a recompilation as part of the octave-4.4 transition, libsbml failed to
build (for a reason apparently unrelated to the transition):
Specifically this seems to have been caused by the change of default java
version from 9 to 10.
In raspbian buster I solved this for the time being by
Package: freedv
Version: 1.3-1
Severity: serious
freedv failed to build during the binnmu for the libcodec transition.
https://buildd.debian.org/status/package.php?p=freedv=unstable
dh_installdocs -a -O--builddir=Build -O--build-system=cmake
dh_installdocs: Cannot find (any matches for)
Package: libsass-python
Severity: serious
Version: 0.13.4-1
A new version of libsass was recently uploaded which transitioned to a new
libary soname and appears to have changed the API in a way that causes
libsass-python to fail to build.
i686-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2
Package: haskell-raaz
Severity: serious
Version: 0.2.0-2
haskell-raaz recently failed to build in raspbian buster with
dh_installexamples -plibghc-raaz-dev
dh_installexamples: Cannot find (any matches for) "bin/Command/Checksum.lhs"
(tried in .)
The reproducible builds tests on amd64, armhf
Package: pygame
Severity: serious
Version: 1.9.3+dfsg2
The two most recent attempts to build pygame on s390x failed with the following
error.
==
ERROR: test_write (pygame.tests.bufferproxy_test.BufferProxyLegacyTest)
Package: pygame
Severity: serious
The most recent attempt to build pygame on ppc64el failed with the following
error.
==
FAIL: test_render_args (pygame.tests.font_test.FontTest)
Package: python3.6-venv
Version: 3.6.6~rc1-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
This version of pyvenv can't create a working virtual env. The failing command
is an ensurepip invocation. The error message also tells me to install
python3-venv, but that
Package: acbuild
Severity: serious
acbuild build-depends on golang-go.crypto-dev which is no longer built by
golang-go.crypto, the replacement appears to be golang-golang-x-crypto-dev. I
was able to succesfully do a build in raspbian bister with the build-dependency
changed.
movw and movt are armv7 only, so this is also affecting Raspbian. To fix both
armel and raspbian the conditional should be <7
I whipped up a patch for that. I then ran into another issue, the compiler was
bitching about uint16_t vs char16_t issues so I whipped up a patch for that too.
Debdiff
)
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
4xx/libglx.so
xserver-xorg-video-nvidia-legacy-340xx: /usr/lib/nvidia/legacy-340xx/libglx.so
I don't know if these packages can be installed together. If they can,
there will be random failures again.
Best regards,
Peter
I don't know how to fix this without patching the xserver code. Maybe
it's possible to manipulate the search path with an xorg.conf
fragment?
Best regards,
Peter
Hello Luca,
[Cc'ing bugs this time]
> I don't think so - I still can't reproduce the problem despite that. It
> should all go through the glvnd blobs.
OK. I don't know what I can do to help. This affected both of my
computers with nvidia graphics, and for now I "fixed" it by copying
the
/modules/extensions/.
See this commit:
https://cgit.freedesktop.org/xorg/xserver/commit/?id=97bd6e453676516891250389ec0fd695c110087c
Best regards,
Peter
package: webkitgtk
version: 2.4.11-3
severity: serious
Webkitgtk seems to be failing to build, failures have been seen with binnmus in
Debian and Raspbian and also on the reproducible builds service. I had a look
at the insanely large build log from reproducible builds and found the
following
stinst would help about this, right?
That entire commit seems highly problematic and not well
through-through for all use-cases.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Oper
.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
changes.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
> My password does not contain any non-ASCII characters, so I believe this
> is a separate issue from bug 780460 (which was mentioned earlier in the
> discussion for bug 822989).
>
> Best,
> James
>
--
| .''`. ** Debian **
Peter Palfrader
Reassign 897005 mpi-defaults
Close 897005 1.13
Thanks
Sorry it seems I screwed up the package name when filing this bug, it's
mpi-defaults not openmpi-defaults.
Anyway this seems to be fixed, version 1.13 built succesfully both on the i386
reproducible builds for buster and in raspbian
Tags 897114 +patch
thanks
This was blocking a transition in raspbian, so I whipped up a fix. Debdiff at
http://debdiffs.raspbian.org/main/i/ifrit/ifrit_4.1.2-5%2brpi1.debdiff , no
intent to NMU in Debian.
The only tricky bit was that there seems to have been a typo in debian/rules,
there was
Package: python-gwcs
Version: 0.8.0-1
Severity: serious
python-gwcs depends on the binary package python-asdf which is no longer built
by the source package python-asdf
As a workaround to let the poppler transition complete in raspbian I whipped up
a version of the package that forces openjdk-8.
A debdiff should appear soon at https://debdiffs.raspbian.org/main/g/gdcm/
No intent to NMU in Debian.
Package: openmpi-defaults
Severity: serious
Version: 1.12
Tags: buster
openmpi-defaults FTBFS in buster, I first noticed this in raspbian but it's
also showing up on the Debian reproducible builds service.
https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/mpi-defaults.html
tags 893515 +patch
thanks
I am currently doing a final build with the changes, assuming it suceeds I will
upload it to Raspbian and post a
debdiff to this bug.
debdiff can be found at
http://debdiffs.raspbian.org/main/d/digikam/digikam_5.7.0-2+rpi1.debdiff
Package: golang-github-influxdb-influxdb-dev
Version: 1.1.1+dfsg1-4
Severity: serious
golang-github-influxdb-influxdb-dev depends on golang-go.crypto-dev which is no
longer built by golang-go.crypto
Package: golang-github-endophage-gotuf
Version: 0.0~git20151020.0.2df1c8e-1
Severity: serious
golang-github-endophage-gotuf depends on golang-go.crypto-dev which is no
longer built by golang-go.crypto
Package: golang-github-bradfitz-http2-dev
Version: 0.0~git20150509-2
Severity: serious
golang-github-bradfitz-http2-dev depends on golang-go.crypto-dev which is no
longer built by golang-go.crypto
This was blocking stuff up in Raspbian buster so I decided to take a look.
I decided to base my work on the version currently in Debian experimental.
First of all I reduced the exiv2 dependency in both the Debian packaging and
the upstream cmake to 0.25.
I then turned my attention to the
ng jessie to stretch. Following a request for printing,
this message appears with absence of hardcopy output.
File "/usr/lib/cups/filter/rastertogutenprint.5.2" not available: ...
The file is available of course.
peter@dalton:/usr/lib/cups/filter$ ls -ld rastertogutenprint.5.2
-rwxr-xr-x 1
901 - 1000 of 3600 matches
Mail list logo
