Source: python-magcode-core
Version: 1.5.4-2
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.
to try on a mips64el computer, Let me know, You can connect to my
Cloud Platforms using ssh.
Hoping to help
Peter Ji
d with -O2 on ppc64el, the embedded ICU ftbfs otherwise.
+ * Fix clean target.
+
+ -- Peter Michael Green Thu, 17 Sep 2020 18:48:36 +
+
mozjs52 (52.9.1-1) unstable; urgency=medium
* Team upload
diff -Nru mozjs52-52.9.1/debian/control mozjs52-52.9.1/debian/control
--- mozjs52-52.9.1/debi
The debian python maintainers are trying to phase out python 2.
python 2 has been granted a stay of execution as some important software
requires it to build. However we should still
be attempting to get rid of use at runtime if at all possible. Also the "unversioned
python" packages have been
The libaccounts-glib package does not seem to be getting maintained in Debian,
it has had a rc bug (deprecated declarations
and -Werror) for 8 months with no maintainer response and has recently picked
up a second one (unversioned python removal).
It has not had an upload for 3 years.
Both of
Source: aseba
Version: 1.6.0-5
Severity: serious
Tags: bullseye, sid
aseba build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to strictly
Source: flowcanvas
Version: 0.7.1+dfsg0-0.5
Severity: serious
Tags: bullseye, sid
flowcanvas build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due
Source: avw.lv2
Version: 0.1.6~dfsg0-1
Severity: serious
Tags: bullseye, sid
avw.lv2 build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to
ing back the armel build until it succeeded...
I knew I should not do that, but I was kind of anxious to get a couple
of fixes in, and... yeah. Sorry, and thanks for keeping track of buildd
logs and failures!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@sto
Source: pdf2djvu
Version: 0.9.17-1
Severity: serious
Tags: ftbfs, fixed-upstream
pdf2djvu's configure script fails to parse the poppler version with the newly
released poppler 20.
This results in a bunch of errors.
This is fixed upstream in version 0.9.17.1
It seems the recent upload of poppler 20 introduced further breakage.
Poppler changed the return type of Catalog::getDestNameTreeDest and
Catalog::getDestsDest
from LinkDest * to std::unique_ptr
If I am following the code correctly, it seems that extractpdfmark had a memory
leak,
previously,
Package: gnome-builder
Version: 3.36.0-3
Severity: serious
Tags: patch
The gnome-builder source package build-depends on libenchant-dev (source
package enchant)
which was recently removed from testing (see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956881 ).
However the gnome-builder
Package: python3-azure-cli
Version: 2.10.1-1
Severity: serious
python3-azure-cli depends on python3-cryptography << 3.0.0 . In unstable this
dependency is unsatisfiable
because python3-cryptography is now at version 3.1-1 .
In testing the dependency is strictly-speaking satisfiable because
On 03/09/2020 14:45, tony mancill wrote:
Hi Peter,
If you have fixes for closure-compiler, please feel free to go ahead and
NMU. I will pick up the changes and apply them to the packaging repo
from the NMU.
NMU uploaded.
Thank you for helping with this,
tony
On Thu, Sep 03, 2020 at 02:05
cy=medium
+
+ * Non-maintainer upload.
+ * Set Java source and target versions to 8 (Closes: 961839)
+ * Replace build-dependency on python-docutils with python3-docutils
+(Closes: 942965)
+
+ -- Peter Michael Green Thu, 03 Sep 2020 12:32:03 +
+
closure-compiler (20130227+dfsg1-10) unst
Lucas Nussbaum wrote:
> The following packages have unmet dependencies:
> sbuild-build-depends-main-dummy : Depends: libopencc2-data but it is not
installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.
Fixed in git.
Tagging this bug as pending
This
uct. gcc 10 has
+arm_sve.h but not __sizeless_struct which is needed by the sve
+implementation in this version.
+
+ -- Peter Michael Green Tue, 01 Sep 2020 21:17:11 +
+
sleef (3.4.1-4) unstable; urgency=medium
* Team Upload.
diff -Nru sleef-3.4.1/debian/patches/check-for-sizeless-st
Package: uwsgi-emperor
Version: 2.0.18-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
After installing uwsgi-emperor 2.0.18 it's impossible to change the
running state of the service, as the provided init-script is doing
nothing. This can be easily seen by the script
Tags 957069 +patch
thanks
gcc-10 changed the behaviour around global variables defined in multiple
compilation units. Defined a variable in
multiple compilation units with the default compiler flags will now result in a
link failure.
However in this particular case the variable doesn't appear
Tags 966904 +patch
thanks
The issue is that Magick++.h (indirectly) includes assert.h inside a namespace.
Note that generally only the first include of a header actually does anything
due to the presense of include gaurds.
Therefore if assert.h is included before Magick++.h then everything is
tags 963290 +patch
thanks
I just took a look at this issue.
First I did some digging in the upstream git repo. Once I figured out their branch
structure (the "master0" branch is
apparently where current releases are made from) I was able to find two
relavent commits.
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
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
Thanks so much! I am on vacation so *should* have time to look into this
soonish. Would you like to take over the package? I would be happy for
you to do that!
Peter
> Control: tags -1 + fixed-upstream
> Control: forwarded -1
> https://git.savannah.nongnu.org/cgit/xforms.git/c
I have prepared a patch for chromium addressing bugs 965960 and 967124
Bug 965960 (crash on 32-bit) was caused by lack of support in the sandbox for
the 64-bit time syscalls that
have recently been added to Linux/glibc. I added __NR_clock_gettime64,
__NR_clock_nanosleep_time64
and
rc/plugins/select/cons_tres/job_test.c
+ * Move definiton of "opt" from scanel.h to scanel.c
+
+ -- Peter Michael Green Sat, 22 Aug 2020 22:59:50 +
+
slurm-llnl (19.05.5-2) unstable; urgency=medium
* Declare libslurm-dev Breaks+Replaces relation with the old
diff -Nru slurm
Package: diffoscope
Version: 156
Severity: serious
Diffoscope has been removed from testing and cannot re-enter because it
build-depends on
gnumeric, which has been kicked out of testing due to a python2 dependency.
Since this build-dependency only appears to be used for testing I would
On 20/08/2020 06:50, Graham Inggs wrote:
For what it's worth, I tried building fpc including your debdiff and
running the autopkgtests in an Ubuntu PPA.
They passed on amd64,
Thanks for confirming (my local setup is far from the same as the test
infrastructure)
and failed on arm64 [1]
Source: haskell-gi-pango
Version: 1.0.22-1
Severity: serious
Tags: ftbfs
The most recent binnmus of haskell-gi-pango in sid failed with
GI/Pango/Objects/Font.hs:670:9: error:
parse error on input ‘HarfBuzz.FeatureT.feature_t’
|
670 | Ptr HarfBuzz.FeatureT.feature_t -> --
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
Package: popplerkit.framework
Version: 0.0.20051227svn-8
Severity: serious
Tags: bullseye sid patch
popplerkit.framework FTBFS with poppler 0.85 because globalParams is now a
std::unique_ptr
https://github.com/freedesktop/poppler/commit/759d190581f8ff069ecee9155313a8e69a2ca9c6
I have whipped
Package: extractpdfmark
Version: 1.1.0-1
Severity: serious
Tags: patch
extractpdfmark FTBFS with poppler 0.85
destname.cc:85:62: error: no matching function for call to ‘PDFDoc::findPage(int&,
int&)’
85 | pagenum = doc->findPage (page_ref.num, page_ref.gen);
Doing a bit of
On 11/08/2020 16:27, peter green wrote:
Package: fpc
Version: 3.2.0+dfsg-5
Severity: serious
The autopkgtest for fpc 3.2.0 is failing
Compiling utests.pp
PPU Loading
/usr/lib/x86_64-linux-gnu/fpc/3.2.0/units/x86_64-linux/fcl-base/custapp.ppu
PPU Source: custapp.pp not available
Recompiling
Control: tag -1 pending
Hello,
Bug #968246 in Dnstwist 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:
w version of
dnstwist last week [0]. Given Scott's planned NMU it might be good to
hold off the upload of the new version until the NMU is acknowledged.
Best regards,
Peter
[0] https://lists.debian.org/debian-security-tools/2020/08/msg0.html
Package: fpc
Version: 3.2.0+dfsg-5
Severity: serious
The autopkgtest for fpc 3.2.0 is failing
Compiling utests.pp
PPU Loading
/usr/lib/x86_64-linux-gnu/fpc/3.2.0/units/x86_64-linux/fcl-base/custapp.ppu
PPU Source: custapp.pp not available
Recompiling CustApp, checksum changed for
m
+
+ * Patch proposed to BTS
+ * Use getters rather than direct access for properties that
+access fields in other classes to fix build with fpc 3.2.
+ (Closes: 968121)
+
+ -- Peter Michael Green Tue, 11 Aug 2020 14:26:53 +
+
ddrescueview (0.4~alpha3-3) unstable; urgency=medium
On 11/08/2020 13:06, Graham Inggs wrote:
I've also looked at mricron [2][3], and changing '(**)' to '*)' in
both places fixes the compilation, but I have no idea what the '(**)'
means. Can anyone tell me?
(* and *) are comment delimeters
Borland style pascal traditionally handled comments
ed
golang dependencies to buster. I recently moved the acmetool package
to the go-team, which you will need to join on salsa to push to its
git repository. Please let me know in case you have any questions.
Peter
+#MISSING: 2.6+2.0.8+dfsg-1#
_ZN7QVectorI6QPointE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base
2.6~alpha
c++filt -n decodes this to
QVector::reallocData(int, int, QFlags)
This looks like an instantiation of a QT template that may or may not be
included in the library as a
notfound 967991 2.35-1
found 967991 2.32-1
close 967991 2.35-1
thanks
On 06/08/2020 13:20, Clint Adams wrote:
On Thu, Aug 06, 2020 at 11:20:00AM +0100, peter green wrote:
glirc can no longer be built in testing because haskell-regex-tdfa is no longer
present in testing. Ilias Tsitsimpis has
Ilias Tsitsimpis wrote:
We should make sure that anyone using this package has migrated to
skylighting and then remove it.
hi, highlighting-kate was just removed from testing at your request, but
carettah still build-depends on it in both testing and
unstable.
Should I go ahead and file a rc
Package: glirc
Version: 2.35-1
Severity: serious
Justification: rc policy: "packages must be buildable within the same release"
glirc can no longer be built in testing because haskell-regex-tdfa is no longer
present in testing. Ilias Tsitsimpis has filed a bug report against the package
saying
On Thu, Aug 06, 2020 at 03:23:08AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 03:10:55AM +0200, Michał Mirosław wrote:
> > On Thu, Aug 06, 2020 at 02:39:42AM +0200, Michał Mirosław wrote:
> > > On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
>
On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> [...]
> > > Using print-debugging, I see that it stops at wait_for_child
On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> On Wed, Aug 05, 2020 at 09:28:12PM +0300, Peter Pentchev wrote:
> > On Wed, Aug 05, 2020 at 08:01:53PM +0200, Michał Mirosław wrote:
> > > On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> >
On Wed, Aug 05, 2020 at 08:01:53PM +0200, Michał Mirosław wrote:
> On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> > On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
> [...]
> > --- a/debian/tests/runtime
> > +++ b/debian/tests/runtime
>
oday
:)
Keeping this one open for now, of course...
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
On Sun, Aug 02, 2020 at 10:28:04PM +0200, Moritz Mühlenhoff wrote:
> Hi Peter,
>
> On Mon, Jul 27, 2020 at 05:20:23PM +0300, Peter Pentchev wrote:
> > Now... related to that. I am not sure whether Moritz Muehlenhoff, when
> > reopening this bug, was aware of the fact that Dm
t I believe that it may have
been something more likely related to GCC than to Kakoune. Of course,
it is possible that Kakoune does something weird that uncovered it, but
still, it seems to build now...
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:
t; I can see (excerpt):
[snip useful excerpt]
Hi,
Thanks a lot for reporting this and for the strace output!
Can you check whether the attached trivial patch will work for you?
There is a slightly more verbose way to do pretty much the same, but
let's see if this works first. If it does... sorry, I real
On 27/07/2020 16:31, s...@debian.org wrote:
On Thu, 23 Jul 2020 at 18:01:55 +0100, peter green wrote:
dbus-python in testing build-depends on python-gi
which is no longer available in testing. This is fixed in
unstable but the fix is blocked from migrating to testing by
https://bugs.debian.org
own source package to allow
the rest to eventually migrate to testing.
I am late in coming to this discussion, so let me express my thanks to
everyone who has spoken their mind in good faith in the bug log.
Here's hoping we find some way to move forward :)
G'luck,
Peter
--
Peter Pentchev r...@ri
Package: x264
Version: 2:0.159.2999+git296494a-2
Severity: serious
Tags: patch
Make 4.3 changed the escaping rules with the # symbol is used inside a
parameter to functions like $shell.
Previously it needed to be escaped, now it needs to *not* be escaped. A change
was applied to the debian
.
+ * Adjust make 4.3 patch to also work with make 4.2 (Closes: 965298 )
+ * Apply upstream patch to make "lv2" plugin build with gcc-10 (Closes:
957314 )
+
+ -- Peter Michael Green Thu, 23 Jul 2020 12:47:21 +
+
gst-plugins-bad1.0 (1.16.2-2.2) unstable; urgency=medium
* Non-
h.gnu.org/bugs/index.php?58810
https://salsa.debian.org/debian/xnee/-/merge_requests/1
Thanks for taking care of cnee/xnee in Debian, and thanks, Matthias, for
your rebuilds!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.o
Last blockers for removal:
1. node-yarnpkg - #960120 - should be patched/fixed for 1.x or switch
to 'berry'/2.x (supports babel 7) in time for bullseye
2. libjs-webrtc-adapte - #959798 - browserify-lite can be replaced by
webpack
3. rainloop - #960021 - not in bullseye
Once the blockers are
Package: opendht
Version: 0.6.6-1
Severity: serious
x-debbugs-cc: msgpac...@packages.debian.org
tags: ftbfs
opendht cannot currently be built in unstable, there are two issues.
Firstly, the build can't even be attempted on armel or mipsel because
the build-dependencies are unsatisfiable. The
Package: ocamlnet
Version: 4.1.6-1
Severity: serious
Tags: FTBFS
When binnmu'd for the nettle transition ocamlnet failed to build on most
architectures
(it succeeded on mipsel, mips64el and armel) with the following error.
make[1]: Leaving directory '/<>'
dh_dwz -a
dwz:
Package: haskell-incremental-parser
Version: 0.4.0.2-1
Severity: serious
haskell-incremental-parser 0.4.0.2-1 added a build-dependency on
libghc-rank2classes-dev (>= 1.0)
however this package is only available on four out of the ten release
archictures.
Potential ways forward:
1. fix
Package: gst-plugins-bad1.0
Version: 1.16.2-2.1
Severity: serious
x-debbugs-cc: sramac...@debian.org, locutusofb...@debian.org
Neither version 1.16.2-2.1 (from bullseye) or version 1.16.2-2.2 (from sid) can
be built in testing.
1.16.2-2.1 cannot be built because libsrt-dev has been removed.
On 17/07/2020 08:42, peter green wrote:
On 17/07/2020 06:40, Sebastian Ramacher wrote:
Hi
On 2020-07-17 00:02:17 +0100, peter green wrote:
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for baresip (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/2.
While
On 17/07/2020 06:40, Sebastian Ramacher wrote:
Hi
On 2020-07-17 00:02:17 +0100, peter green wrote:
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for baresip (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/2.
While I have not tested, I am 99% sure your
) bullseye-staging; urgency=medium
+
+ * Raspbian upload based on Sebastian Ramacher's proposed NMU
+ [Sebastian Ramacher]
+ * debian/patches:
+- Unbreak patch 1002 with make 4.3 (Closes: #961811)
+- Apply upstream patch to fix build of selftest
+ [Peter Michael Green]
+ * Further adjust
(note: I am not the maintainer)
Sebastian Ramacher wrote:
I've prepared an NMU for gst-plugins-bad1.0 (versioned as 1.16.2-2.2) and
uploaded it to DELAYED/2.
Hi, I tried adding your proposed NMU to raspbian as part of trying to get the
x265 transition to go through there.
Unfortunately it
Both the django-mailman3 and the hyperkitty build failures look like the same
issue
, my looking however was focused on the hyperkitty failure as that is the one I
became
aware of first.
First I looked at test history for hyperkitty on reproducible builds and
looking at when relavent
packages
+ * Apply upstream patch to move away from asynctest and move towards
+the testing functionality in the standard library.
+ * Update build-depenencies, remove build-dependency on python3-asynctest
+and add build-dependency on python3-all-dev (>= 3.8.2-3) | python3-mock
+
+ -- Peter Michae
Package: oca-core
Version: 11.0.20191007-3
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.
2020-07-04 23:10:28.0 +
@@ -1,3 +1,10 @@
+glewlwyd (2.3.1-2.1) UNRELEASED; urgency=medium
+
+ * Patch proposed to BTS
+ * Split architecture dependent and independent builds.
+
+ -- Peter Michael Green Sat, 04 Jul 2020 23:10:28 +
+
glewlwyd (2.3.1-2) unstable; urgency=medium
Package: glewlywd
Version: 2.3.1-2
Severity: serious
The new glewlywd package cannot be built on armel, mipsel or mips64el due to
unsatisfiable
build-dependencies. Specifically nodejs/npm on armel and librhonabwy-dev on
mipsel/mips64el
Generally there are three possible ways forward with this
+
+ * Non-maintainer upload.
+ * Change build-dependency from libcrmservice-dev to pacemaker-dev
+(Closes: ??)
+
+ -- Peter Michael Green Thu, 25 Jun 2020 08:26:43 +
+
booth (1.0-174-gce9f821-2) unstable; urgency=medium
* d/patches: try to fix flaky lock file test
diff -Nru booth-1.0
and remove any obsolete packages from older
> releases before you upgrade to any version newer than Debian 10.
>
> > The bug actually lies in libglibmm-2.4-1v5 which is not propagating the
> > proper versioned dependency, so I'm reassigning this bug to them.
>
> This will be fixed in unstable shortly.
>
> smcv
>
--
Peter
Putting the Debian bug back in cc, for earlier mails please see
https://marc.info/?l=linux-xfs=159253950420613=2
Eric Sandeen wrote:
How does debian fix this for xfsprogs? Doesn't the same issue exist?
I'm not seeing any cases like xfsdump where a binary is located in /sbin but
symlinked
Putting the debian bug back in cc, previous mails are visible at
https://marc.info/?l=linux-xfs=159253950420613=2
On 19/06/2020 23:43, Dave Chinner wrote:
Isn't the configure script supposed to handle install locations?
Both xfsprogs and xfsdump have this in their include/builddefs.in:
-debian files. ( Closes: 953537 )
+
+ -- Peter Michael Green Fri, 19 Jun 2020 01:01:18 +
+
xfsdump (3.1.9) unstable; urgency=low
* New upstream release
diff -Nru xfsdump-3.1.9/debian/rules xfsdump-3.1.9+nmu1/debian/rules
--- xfsdump-3.1.9/debian/rules 2020-01-31 17:30:58.0 +
Package: qbittorrent
Version: 4.1.7-1
Severity: serious
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/qbittorrent.html
./../src/base/bittorrent/infohash.cpp: In constructor
'BitTorrent::InfoHash::InfoHash(const sha1_hash&)':
../../src/base/bittorrent/infohash.cpp:44:43:
of build-depends on pypy-pytest (Closes: 962232)
+(thanks to Chris Lamb for the initial patch)
+
+ -- Peter Michael Green Sat, 13 Jun 2020 01:49:35 +
+
vanguards (0.3.1-2) unstable; urgency=medium
[ Nicolas Braud-Santoni ]
diff -Nru vanguards-0.3.1/debian/control vanguards-0.3.1/debian
Package: apper
Version: 1.0.0-2
Severity: serious
Tags: bullseye, sid, patch
http://buildd.raspbian.org/status/fetch.php?pkg=apper=armhf=1.0.0-2%2Bb4=1591727741
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apper.html
CMake Error at
Yes, that. I look regularly at
https://qa.debian.org/dose/debcheck/src_testing_main/ as we (the release
team) require packages to be buildable in testing (we have some
tolerance as the migration of build dependencies isn't guaranteed when
checking if a package may migrate). Please help the rust
, no immediate intent to NMU.
+ * Apply upstream patches for new boost ( Closes: 959439 ).
+
+ -- Peter Michael Green Mon, 08 Jun 2020 07:17:12 +
+
supercollider (1:3.10.0+repack-1) unstable; urgency=medium
* fixed a little error in d/rules: create a missing directory
diff -Nru supercollider-3.10.0
eye-staging; urgency=medium
+
+ * Explicitly convert tribool to bool, this seems to be needed with the
+new boost.
+
+ -- Peter Michael Green Mon, 08 Jun 2020 01:56:54
+
+
libpwiz (3.0.18342-2) unstable; urgency=low
* Improve header path (move pwiz to proteowizard) to ease with nest
Package: pglogical
Version: 2.3.1-1
Severity: serious
Tags: ftbfs
It seems pglogical recently started failing to build.
http://buildd.raspbian.org/status/fetch.php?pkg=pglogical=armhf=2.3.1-1%2Bb1=1591473342
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pglogical.html
I downloaded the build logs and filtered them to show the missing symbols that
were not already marked as optional.
plugwash@thinkpad:~$ wget -O zimlib.log
'https://buildd.debian.org/status/fetch.php?pkg=zimlib=amd64=4.0.4-5%2Bb1=1591384179=0'
plugwash@thinkpad:~$ html2text -width 10
+
@@ -1,3 +1,10 @@
+lix (0.9.29-1+rpi1) bullseye-staging; urgency=medium
+
+ * Add patch from upstream pull request to fix build with new libphobos
+(Closes: 961986)
+
+ -- Peter Michael Green Fri, 05 Jun 2020 22:49:20
+
+
lix (0.9.29-1) unstable; urgency=medium
* New upstream
On 04/06/2020 23:12, Thomas Goirand wrote:
On 6/4/20 10:33 PM, peter green wrote:
A few days ago Sandro Tosi uploaded the python-unittest2 and
python-funcsigs source packages. It seems that both of these were
effectively "team uploads" though they were not marked as such.
A few years
A few days ago Sandro Tosi uploaded the python-unittest2 and python-funcsigs source
packages. It seems that both of these were effectively "team uploads" though
they were not marked as such. The python-unittest2 upload dropped python 2 support while
the python-funcsigs package dropped python 2
)
+
+ -- Peter Michael Green Thu, 04 Jun 2020 19:21:14 +
+
vanguards (0.3.1-2) unstable; urgency=medium
[ Nicolas Braud-Santoni ]
diff -Nru vanguards-0.3.1/debian/control vanguards-0.3.1/debian/control
--- vanguards-0.3.1/debian/control 2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1
Source: libdr-tarantool-perl
Version: 0.45-2
Severity: serious
Tags: bullseye, sid
libdr-tarantool-perl build-depends on
tarantool-lts | tarantool (<< 1.6)
tarantool-lts has been removed from Debian and tarantool is now at version
1.9.1.26.g63eb81e3c-1.1
Package: picard-tools
Version: 2.18.25+dfsg-3
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.
The aufs package last saw a maintainer upload in September 2019 and was
last-updated (by a NMU) in October 2019. It has had broken build-dependencies
in testing for half a year now (since Linux 5.3.9-3 migrated to testing in
November 2019).
According to dak rm the aufs source-package has two
Source: user-mode-linux
Version: 5.5um1
Severity: serious
user-mode-linux build-depends on linux-source-5.5 which is no longer available
in testing.
2020 at 10:15, Peter Eckersley wrote:
>
> pde@graphene:~$ ls -l /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> lrwxrwxrwx 1 root root 22 Apr 16 07:01
> /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 -> libgio-2.0.so.0.6400.2
> pde@graphene:~$ ls -l /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
moreinfo unreproducible
>
> On Thu, May 21, 2020 at 11:34:49PM +1000, Peter Eckersley wrote:
> > Package: inkscape
> > Version: 1.0-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > $ inkscape
> > inkscape: symbol lookup error:
> >
Source: python-cobra
Version: 0.18.0-1
Severity: serious
Three of the last four builds of python-cobra on s390x have failed with.
=== FAILURES ===
___ test_model_summary_to_frame_with_fva[optlang-glpk-0.95]
i imagemagick 8:6.9.10.23+dfsg-2.1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1
ii libimage-magick-perl 8:6.9.10.23+dfsg-2.1
ii libwmf-bin 0.2.8.4-12
ii python3-lxml 4.5.0-1.1
ii python3-numpy1:1.18.2-2
ii python3-scour0.37-4
Versions of packages inkscape suggests:
pn dia
pn inkscape-tutorials
pn libsvg-perl
pn libxml-xql-perl
pn pstoedit
pn python3-uniconvertor
ii ruby 1:2.7+1
-- no debconf information
--
Peter
machines right now...
Peter
On Sat, May 16, 2020 at 2:22 PM Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Peter Cock
>
> Hi Peter,
>
> it seems the patch applied does not work for 32bit architectures.
>
> Kind regards
>
> Andreas.
>
The small patch on this pull request ought to solve the immediate Debian
testing issue for biopython:
https://github.com/biopython/biopython/pull/2890
Peter
On Wed, May 6, 2020 at 3:06 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:
> Thank you for the additional inform
Source: python-pybedtools
Version: 0.8.0-3
Severity: serious
bedtools is no longer available in testing on armel, armhf or mipsel (or i386
but python-pybedtools never seems to have built there) which makes the
build-dependencies of python-pybedtools unsatisfiable on those architectures.
On 10/05/2020 21:44, Adrian Bunk wrote:
On Sun, May 10, 2020 at 09:29:23PM +0100, peter green wrote:
2. file a bug against ftp.debian.org asking for the removal of
rust-packed-simd on armel/mips64el/mipsel/s390x
That isn't really a workable option. It would just push the problem down
2. file a bug against ftp.debian.org asking for the removal of
rust-packed-simd on armel/mips64el/mipsel/s390x
That isn't really a workable option. It would just push the problem down the
line to other packages. Taken to it's conclusion, solving this through the
removal request route
501 - 600 of 3616 matches
Mail list logo