Package: libimlib2-dev
Severity: grave
The package is uninstallable because it depends on the non-existent
libltdl3-dev.
This is related to #980829.
As no package maintainer stepped up to fix this, I am NMUing the package with
the enclosed changes.diff -Nru connman-1.36/debian/changelog connman-1.36/debian/changelog
--- connman-1.36/debian/changelog 2021-10-09 22:49:52.0 +0200
+++ connman-1.36/debian/changelog 2022-02-26 0
No team member reacted to Fabio's requests, so I am going to sponsor Fabio's
NMU.
The debdiff is enclosed.diff -Nru virt-manager-3.2.0/debian/changelog
virt-manager-3.2.0/debian/changelog
--- virt-manager-3.2.0/debian/changelog 2020-12-05 09:36:56.0 +0100
+++ virt-manager-3.2.0/debian/ch
On Tue, 25 Jan 2022 17:55:18 +0100 Fabio Fantoni
wrote:
Hi, I saw that remain few days for autoremoval from testing I prepared
an MR with some upstream patch that solve current FTBFS with some tests
and another small fix for a crash case:
https://salsa.debian.org/libvirt-team/virt-manager/-/m
X-Debbugs-CC: Andrea Pappacoda
On Tue, 25 Jan 2022 18:13:01 +0100 Dennis Filder wrote:
X-Debbugs-CC: Bastian Germann
On Mon, Jan 24, 2022 at 08:18:02PM +0100, Bastian Germann wrote:
> Upstream has that fixed with
>
https://gitlab.linphone.org/BC/public/bctoolbox/-/
Control: tags -1 patch fixed-upstream
Upstream has that fixed with
https://gitlab.linphone.org/BC/public/bctoolbox/-/commit/9ac0e412c45bf28d02829e9d912342359714f638
attrs, Closes: #999824)
+
+ -- Bastian Germann Mon, 24 Jan 2022 18:33:09 +0100
+
ima-evm-utils (1.4-1.1) unstable; urgency=high
* Non-maintainer upload.
diff -Nru ima-evm-utils-1.4/debian/control ima-evm-utils-1.4/debian/control
--- ima-evm-utils-1.4/debian/control2022-01-24 10:49
Control: retitle -1 ima-evm-utils: FTBFS without extended attributes support
On Mon, 24 Jan 2022 13:36:00 +0100 Bastian Germann wrote:
Version 1.4 was imported but still fails to build from scratch on buildd
because the unit tests for
that new feature do not run without gnutls-bin and softhsm2
On Thu, 18 Nov 2021 21:59:12 +0100 Bastian Germann wrote:
Your package fails to build from scratch in an environment with no internect
connection.
Please check the buildd logs for this.
I am going to fix this via a NMU as it was not resolved with the latest upload.diff -Nru ima-evm-utils-1.4
On Wed, 6 Oct 2021 17:26:59 +0200 Bastian Germann wrote:
Package: openlp
Severity: serious
Version: 2.4.6-1
OpenLP v2.4.6 is licensed under GPL-2-only. This is incompatible with PyQt5's GPL-3+
license, which it depends on. Upstream has released OpenLP beta versions licensed under
GPL-
Source: rsplib
Severity: serious
Version: 3.3.3-1
rsplib fails to build on sid/mipsel:
https://buildd.debian.org/status/fetch.php?pkg=rsplib&arch=mipsel&ver=3.3.3-1&stamp=1640318034&raw=0
...
[ 55%] Linking CXX executable cspmonitor
cd /<>/obj-mipsel-linux-gnu/src && /usr/bin/cmake -E cmake_link
Source: ogre-1.12
Severity: serious
Version: 1.12.10+dfsg2-1.2
ogre-1.12 does not build on sid/mipsel:
https://buildd.debian.org/status/fetch.php?pkg=ogre-1.12&arch=mipsel&ver=1.12.10%2Bdfsg2-1.2&stamp=1640306818&raw=0
...
cd /<>/obj-mipsel-linux-gnu/PlugIns/OctreeZone && /usr/bin/c++
-DPlugin_
Control: tag -1 pending
Hello,
Bug #1001303 in alure 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:
https://salsa.debian.org/games-team/alure/-/commit/e0b8e0694173e6167408284e827a3e0ae
Source: rsplib
Version: 3.3.3-1
Severity: serious
The build dependency valgrind is not available for armel.
If this is optional, please make the package build without it on armel or exclude armel from the
build architectures.
On Mon, 20 Jul 2020 19:35:34 + Niels Thykier
wrote:
Source: python-pysnmp4-mibs
Version: 0.1.3-3
Severity: normal
Usertags: compat-5-6-removal
Hi,
The package python-pysnmp4-mibs uses debhelper with a compat level of 5 or 6,
which is deprecated and scheduled for removal[1].
For the repo
On Tue, 7 Dec 2021 17:39:26 -0800 Steve Langasek
wrote:
I don't know what is causing this misbehavior of the build system; if I look
at obj-x86_64-linux-gnu/CMakeCache.txt I see other variables using similar
separators but these only seem to leak onto the commandline for the
fluidsynth cflags:
Control: fixed -1 firefox-esr/91.3.0esr-2
I think this bug can be closed. A newer version builds on i386.
On Thu, 2 Dec 2021 13:04:21 +0100 bret curtis wrote:
MyGUI could possibly be maintained by games-team, but I don't know how to
initiate that transfer.
You should have received an invitation to the repo in games-team.
Source: c-blosc
Severity: serious
Version: 1.21.1+ds2-1
The build fails on mips64el with:
98% tests passed, 35 tests failed out of 1651
Total Test time (real) = 452.24 sec
The following tests FAILED:
1 - test_api (Failed)
2 - test_bitshuffle_leftovers (Failed)
270 -
Source: ima-evm-utils
Severity: serious
Version: 1.3.2-2.1
Hey,
Your package fails to build from scratch in an environment with no internect
connection.
Please check the buildd logs for this.
Thanks,
Bastian
Control: forwarded -1 https://gitlab.com/crosswire-bible-society/tdavid
Source: zycore-c
Version: 1.0.0-2
Severity: serious
Hi,
The issue that seemed to be addressed by a patch included in the latest
revision was not fixed;
the package still FTBFS at least on mips64el:
/usr/bin/cc -DZYCORE_EXPORTS -DZycore_EXPORTS -D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE
-I/<>/inc
Hi Camm,
On 09.11.21 23:12, Camm Maguire wrote:
But in any case, I no longer understand the premise of this
bug, unless it was your understanding that the source was gplv2*only*
instead of "or any later version".
Yes, this was the premise and that is what debian/copyright claims at the
bottom
Side note: the git version that I have used for the NMU is now available as
0.6.0.
Control: reassign -1 libgoogle-glog-dev
Control: retitle -1 glog cmake files with static archive break ceres-solver
build
Control: notforwarded -1
In your debian/rules file, installation of the static library build happens after installation of
the shared library build. Therefore, the cmake fil
:13.0
+0100
@@ -1,3 +1,10 @@
+mediastreamer2 (1:4.4.21-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS by building without -Werror (Closes: #984234)
+
+ -- Bastian Germann Wed, 03 Nov 2021 18:24:13 +0100
+
mediastreamer2 (1:4.4.21-3) unstable; urgency=medium
On Wed, 03 Mar 2021 16:15:27 + Matthias Klose wrote:
[...]
from /usr/include/bctoolbox/list.h:23,
from /usr/include/ortp/rtpsession.h:34,
from /<>/include/mediastreamer2/stun.h:24,
from /<>/src/voip/ice.c:31:
In function ‘st
On Sat, 23 Oct 2021 21:18:54 +0200 Lucas Nussbaum wrote:
Source: netperfmeter
Version: 1.8.6~rc2-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> cd "/<>/obj-x86_
Control: forwarded -1 https://github.com/ceres-solver/ceres-solver/issues/715
On Sat, 23 Oct 2021 20:31:26 +0200 Lucas Nussbaum wrote:
Source: ceres-solver
Version: 1.14.0-14
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
This also breaks on the current draft version 2.0.0-1.
Control: retitle -1 spyne: unit test fail with sqlalchemy 1.4
Control: severity -1 important
Control: notfound -1 spyne/2.13.16-1
Control: found -1 spyne/2.13.16-2
The FTBFS is fixed but the root cause is not (see forwarded upstream issue).
Control: reopen -1
Control: reassign -1 ftp.debian.org
On Sat, 23 Oct 2021 19:11:04 +0100 Ximin Luo wrote:
Source: rust-lalrpop
Followup-For: Bug #995339
The d/copyright file is about the source package not the binary package, you
are misinterpreting policy.
In Policy 12.5, I read "Every pa
@@
+swupdate (2021.04-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Remove deprecated Salsa CI config
+ * latexmk without :native is alternative build dependency (Closes: #997473)
+ * Add tex-gyre build dependency
+
+ -- Bastian Germann Sun, 24 Oct 2021 13:34:27 +0200
+
swupdate
Package: firefox
Version: 92.0-1
Severity: grave
Dear Maintainer,
* What led up to the situation?
Starting firefox or firefox-esr (or even chromium). I guess it is caused by a
common dependency only on i386.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Source: dvbstreamer
Version: 2.1.0-5.1
Severity: serious
Tags: sid bookworm
dvbstreamer fails building with autoconf 2.71. A build log of an
unrelated NMU can be seen at
https://buildd.debian.org/status/fetch.php?pkg=dvbstreamer&arch=amd64&ver=2.1.0-5.3&stamp=1634219631
(On my test machine th
Am 14.10.21 um 10:15 schrieb Chris Hofstaedtler:
* Bastian Germann [211014 09:57]:
On Sat, 2 Jan 2021 18:36:38 +0100 Bastian Germann
wrote:
There is an easy solution to the problem: Replacing the build dependency
libreadline-dev with libeditreadline-dev links with the BSD-licensed
libedit
On Sat, 2 Jan 2021 18:36:38 +0100 Bastian Germann
wrote:
There is an easy solution to the problem: Replacing the build dependency
libreadline-dev with libeditreadline-dev links with the BSD-licensed
libedit library which is a readline replacement.
You will need the patch at
https
On Sun, 03 Jan 2021 14:17:05 +0530 Ritesh Raj Sarraf wrote:
On Sat, 2021-01-02 at 18:36 +0100, Bastian Germann wrote:
> This package depends on libreadline8 which is GPL-3+ licensed.
> According
> to debian/copyright parts of your package are GPL-2-only licensed. If
>
+ * Update Debian's manpage (Closes: #995001)
+ * Remove autobuild tag (Closes: #862028)
+ * d/watch: Make the package a MUT (download both origtars)
+
+ -- Bastian Germann Wed, 13 Oct 2021 18:51:43 +0200
+
rar (2:5.5.0-1) unstable; urgency=medium
* New upstream release
diff -Nru rar-
Control: tags -1 patch
Hi,
A copyright file for abook with the necessary fixes for this bug is enclosed.
Please include it in a new package revision.
Thanks,
Bastian
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: abook
Upstream-Contact: Jaakko Heinonen
this!
It would be nice to migrate to editreadline. GCL at present constructs
a binary license banner indicating GPL'ed components. How would runtime
gcl distinguish between these two libraries of the same name?
Take care,
Bastian Germann writes:
Control: found -1 5.44.0-3
On Sat, 2 Ja
Control: found -1 5.44.0-3
On Sat, 2 Jan 2021 18:48:19 +0100 Bastian Germann
wrote:
However, that is orphaned in Debian, so
libeditreadline-dev should be preferred, which does not compile with
your package without any patch. It links with the BSD-licensed libedit
library which is a readline
I am sponsoring the NMU with the enclosed debdiff.
diff -Nru connman-1.36/debian/changelog connman-1.36/debian/changelog
--- connman-1.36/debian/changelog 2021-06-09 20:48:07.0 +0200
+++ connman-1.36/debian/changelog 2021-10-09 22:49:52.0 +0200
@@ -1,3 +1,12 @@
+connman
On Sat, 9 Oct 2021 16:04:33 -0600 Ross Vandegrift wrote:
Upstream relicensed the client source to GPL v2 or later in 27e37a50
specifically to address this issue [1]. That change was released in 1.10, but
d/copyright does not reflect it.
I've opened an MR with the fix at [2], but need a sponsor
@@
+omake (0.10.3-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build with libedit instead of libreadline (Closes: #979096)
+
+ -- Bastian Germann Sat, 09 Oct 2021 20:02:08 +0200
+
omake (0.10.3-2) unstable; urgency=medium
* Team upload.
diff -Nru omake-0.10.3/debian/control
Hi,
Can you please take a look at #995843 which I think is a Policy violation by abook not
including all distribution licenses in the copyright file. The package maintainer does not
think so and claims that only including the main license (GPL-2+) is good enough.
There are at least two BSD li
Am 07.10.21 um 10:55 schrieb Rhonda D'Vine:
I think you misunderstand how the GPL works. The GPL is known to be
viral, and licenses compatible with the GPL are indeed compatible with
it because they allow to be covered under the GPL. The whole work in
the end is covered by the GPL, and thus i
Source: abook
Severity: serious
Version: 0.6.1-1
abook contains distribution licenses that are not copied to
debian/copyright. At least BSD-2-clause (xmalloc.c, misc.c), old-style
MIT (ldif.c), FSFULLR (configure, Makefile.in), X11 (install-sh), and
probably others.
Am 06.10.21 um 21:34 schrieb Rhonda D'Vine:
> Are you reading the debian/copyright file correct? Yes, it says
> "License: GPL-2" but AIUI that is just a reference indicator, and the
> long paragraph below that is the relevant one. And that clearly states
> "or later", and it's the only explenati
Package: openlp
Severity: serious
Version: 2.4.6-1
OpenLP v2.4.6 is licensed under GPL-2-only. This is incompatible with PyQt5's GPL-3+
license, which it depends on. Upstream has released OpenLP beta versions licensed under
GPL-3+. A package for those versions is currently available at
https:/
Source: unrar-free
Severity: serious
Version: 1:0.0.1+cvs20140707-4
src/unrar.c says "dos_to_unix_time came from unzip sources." However, unzip's Info-ZIP
license requires to copy the license to distributions and it is not available in unrar-free.
https://gitlab.com/bgermann/unrar-free/-/commi
On Mon, 20 Apr 2020 23:30:00 +0200 Johannes 'josch' Schauer
wrote:
In this state, pdfrw should not be included in the next Debian stable
release.
https://github.com/sarnold/pdfrw has a fork that is actively maintained.
Gentoo already uses this as upstream.
Package: lalrpop
Severity: serious
Version: 0.17.2-7
The d/copyright file only contains the license info of the source package but it
does not contain the license info for each software that is contained in the
binary /usr/bin/lalrpop:
X-Cargo-Built-Using: rust-aho-corasick (= 0.7.10-1), rust
Package: tortoisehg
Severity: serious
At https://groups.google.com/g/thg-dev/c/AYFxHk5aLKg/ I started a conversation about TortoiseHg
(GPLv2-only) having an incompatible license with the currently packaged PyQt5 version (GPLv3). In
almost a year, upstream did not do anything to handle the issue
Control: severity -1 normal
On Thu, 1 Apr 2021 23:48:51 +0200 Timo Röhling wrote:
On Tue, 23 Mar 2021 00:44:07 +0100 Bastian Germann
wrote:
> As far as I can see, the license for NSS's PKCS#11 headers is MPL 2.0
> (DFSG-free) and not the OASIS IPR.
Well, I can see from the dis
On Wed, 2 Dec 2020 02:46:36 + peter green wrote:
> This will impact quite some other modules.
I agree that the current autoremoval list looks pretty scary, so I decided to
do some
dependency analysis. It seems there are 5 source packages with direct or
indirect hard
dependencies on rust-
Am 11.07.21 um 01:28 schrieb Colin Watson:
Thanks for committing a fix for this to git.
Do you need sponsorship help to upload this (if so, I'd be happy to do
it), or is an upload already in progress?
The change needs sponsorship. It is in the Python Team's RFS queue, so please
go ahead.
This is from the cloned bug but belongs here.
Am 18.05.21 um 08:31 schrieb Heinrich Schuchardt:
The original problem report showed the following situation was hit:
common/malloc_simple.c:29:
log_err("alloc space exhausted\n");
You cannot expect normal system behavior when reaching this situat
Am 18.05.21 um 03:27 schrieb Vagrant Cascadian:
On 2021-05-07, Vagrant Cascadian wrote:
On 2021-04-16, Bastian Germann wrote:
I figured out my problem is caused by
https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f.
The
boot_efi_bootmgr will run and read a bad
On Fri, 16 Apr 2021 17:06:37 +0200 Bastian Germann
wrote:
> The issue is fixed in 2021.04 (experimental) which has the same default
environment as 2021.01.
The upstream commit that fixed this is
https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83
It appl
Am 16.04.21 um 14:25 schrieb Bastian Germann:
The issue is fixed in 2021.04 (experimental) which has the same default
environment as 2021.01.
The upstream commit that fixed this is
https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83
It applies cleanly on 2021.01
On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker wrote:
On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote:
> >> I'll test on a few of my systems to see if I can reproduce the issue.
> >
> > I can confirm similar behavior on a pinebook, although the kernel does
> > boot and actual
Control: severity -1 important
Am 07.04.21 um 11:10 schrieb Andreas Henriksson:
Could we please just add a patch that either just rips out the NDEBUG
lines (or inverts the login to #ifdef DEBUG ) ?! Such a patch could/should
be forwarded upstream as well A library should not print to stdout
Control: tags -1 patch
A patch is enclosed.
From: Bastian Germann
Date: Sat, 3 Apr 2021 14:36:37 +0200
Subject: Compile with NDEBUG set
This makes the tools' output more compatible with the original fw_*env tools.
Signed-off-by: Bastian Germann
---
debian/rules | 2 +-
1 file chang
On Fri, 26 Mar 2021 16:53:31 +0100 Paul Jena wrote:
Package: libubootenv-tool
Version: 0.3-1
Severity: grave
Hello,
there are compatibility problems with RAUC and the libubootenv-tool package.
RAUC requires the fw_setenv and fw_printenv utilites to interact with the
u-boot-environment. After
Control: severity -1 normal
On Sun, 28 Mar 2021 13:27:57 +1000 Russell Stuart
wrote:
On 28/3/21 3:01 am, Andrey Rahmatullin wrote> On Thu, Mar 25, 2021 at
07:30:14PM +1000, Russell Stuart wrote:>> Justification: renders package
unusable> >> python3-pep8 does not install the pep8 executable un
Source: imx-code-signing-tool
Severity: serious
code/back_end-hsm contains doc/HSM-CST_UG.pdf which has an unclear
license and is probably not in source format. Also, the OASIS PKCS#11
headers are contained in the subdirectory src/include. It is unclear
whether OASIS is DFSG-free (see #952951)
On Tue, 23 Mar 2021 00:18:08 +0100 Bastian Germann wrote:> Upstream had
a discussion about the license at
> https://phabricator.services.mozilla.com/D63241 and with OASIS at
> https://markmail.org/thread/4juvugfvj45iyrmp
As far as I can see, the license for NSS's PKCS#11 headers is
On Sun, 14 Feb 2021 00:29:59 +0100 t...@gaussglocke.de wrote:
> On Mon, 2 Mar 2020 17:16:09 +0800 Alvin Chen wrote:
> > You can use an alternative header like p11-kit which is licensed under
> > a more liberal license.
> I had a look at the PKCS #11 headers; the biggest problem is that NSS
> uses
Am 20.03.21 um 17:49 schrieb Roberto C. Sánchez:
Could you request from the release team an exception for this
bug so that we can deal with it in the next release cycle without
completely expelling the package in the meantime?
If you think that is a reasonable request, you can do so.
If you wan
On Sun, 28 Feb 2021 13:33:23 +0100 Salvatore Bonaccorso
wrote:
CVE-2021-3407[0]:
| A flaw was found in mupdf 1.18.0. Double free of object during
| linearization may lead to memory corruption and other potential
| consequences.
See #983104 for a NMU RFS with the fix for buster.
Package: sword-comm-tdavid
Severity: serious
Control: forwarded https://tracker.crosswire.org/browse/MOD-404
sword-comm-tdavid is missing source. The suggested decompression
commands in debian/copyright will not give the original source because
the translation process is lossy.
I suggest to m
Package: sword-comm-scofield
Severity: serious
Control: forwarded https://tracker.crosswire.org/browse/MOD-402
sword-comm-scofield is missing source. The suggested decompression
commands in debian/copyright will not give the original source because
the translation process is lossy.
I suggest
The claim about the eBible version supposedly not being in public domain
was only asserted directed towards the crown copyright. Nobody actually
came up with a copyright violation claim against eBible.
That said, I imported the engKJV2006eb version with its USFX source.
The sword module is not
Am 04.03.21 um 22:02 schrieb Bastian Germann:
Am 04.03.21 um 21:48 schrieb Bastian Germann:
If we want to keep a KJV module in main, we can replace the KJV with
ebible's KJVCPB module, which comes with source. Then we have to think
about the version number. We can also move kjv to non-fre
Am 04.03.21 um 21:48 schrieb Bastian Germann:
If we want to keep a KJV module in main, we can replace the KJV with
ebible's KJVCPB module, which comes with source. Then we have to think
about the version number. We can also move kjv to non-free and introduce
a new package sword-text-k
Am 04.03.21 um 21:07 schrieb Teus Benschop:
On Thu, 4 Mar 2021 at 20:56, Bastian Germann <mailto:bastiangerm...@fishpost.de>> wrote:
This was discussed in #338077 and found to be okay (because it is a
Commonwealth problem only). This is not the problem here. It is the
ed
Am 04.03.21 um 20:33 schrieb Teus Benschop:
Here is an article on the copyright issues with regard to the KJV.
https://en.wikipedia.org/wiki/King_James_Version#Copyright_status
It says, among many other things that "The Authorized Version is in the
public domain in most of the world. However, in
Source: sword-text-kjv
Severity: serious
Version: 2.10-1
sword-text-kjv is non-free in all of its versions. The details are in
https://gitlab.com/crosswire-bible-society/kjv/-/commit/0203c85010a9a
For the (binary) sword module a "General public license for distribution
for any purpose" is gra
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for the package "grcompiler":
* Package name: grcompiler
Version : 5.2-2.2
Upstream Author : silgraphite-de...@lists.sourceforge.net
* URL : https://github.com/silnrsi/grco
On Wed, 20 Jan 2021 21:46:07 +0100 Lucas Nussbaum wrote:
> Start 9: compare_PigLatinTest_v2
> 4/15 Test #9: compare_PigLatinTest_v2 .***Failed0.01 sec
> Files "PigLatinTest_v2.ttf" to
"/<>/test/GrcRegressionTest/fonts/PigLatinBenchmark_v2.ttf" are different.
> ...
> 93%
On Thu, 07 Jan 2021 21:09:25 +0100 Salvatore Bonaccorso > The following
vulnerability was published for wolfssl.
CVE-2020-36177[0]:
| RsaPad_PSS in wolfcrypt/src/rsa.c in wolfSSL before 4.6.0 has an out-
| of-bounds write for certain relationships between key size and digest
| size.
If you fix
-x
https://mentors.debian.net/debian/pool/main/a/alure/alure_1.2-7.dsc
Changes since the last upload:
alure (1.2-7) unstable; urgency=low
.
* Team upload
.
[ Ansgar Burchardt ]
* debian/control: Remove DM-Upload-Allowed.
.
[ Bastian Germann ]
* Disable DYNLOAD which causes proble
Package: src:ucommon
Version: 7.0.0-17
Severity: serious
Tags: sid ftbfs
armel and armhf builds fail. The symbol ost::Mutex::Mutex()@Base needs
to be marked optional to make them build.
Am 05.12.20 um 14:29 schrieb Lucas Nussbaum:
Source: sword-text-web
Version: 349.0-1
Severity: serious
Justification: FTBFS on arm64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201205 ftbfs-bullseye
Hi,
During a rebuild of all packages in sid, your package failed to build
on arm64 (I don't know
Does someone care about this issue? This will impact quite some other
modules.
Source: aravis
Severity: serious
Version: aravis/0.8.1-1
aravis 0.8.1-1 does not migrate to bullseye, because it was uploaded
with all and amd64 binaries. While the amd64 binary was replaced by a
BinNMU, the all binary sticks around. Please reupload a source-only version.
The fix from Adrian is now applied on salsa. Who wants to upload
bibletime 3.0-3?
On Sat, 24 Oct 2020 11:50:14 +0800 Paul Wise wrote:
On Sat, 2020-10-24 at 03:06 +, kpcyrd wrote:
> Yes, running the build.py script would cause reproducible builds issues
> because it's used to take snapshots of Mozilla's trusted root CA
> certificates.
Hmm, I assume that is because it wou
On Wed, 27 Mar 2019 11:04:30 +0100 Christoph Berg
wrote:> Re: Ansgar Burchardt 2019-03-20
<751a89074fcaa393f2cc26ff676e9e3434ecd706.ca...@43-1.org>
> > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> > than just libpq5: just looking at a small sample of the direct rdeps of
>
On Tue, 6 Oct 2020 13:04:24 +0200 Gregor Riepl wrote:
> Thunderbird 78.3.1 is now in unstable, and without Enigmail 2.2,
> existing users may lose their existing configuration.
>
> Please consider uploading the migration wizard (i.e. Enigmail 2.2) as
> soon as possible.
enigmail seems to be the
On Tue, 15 Sep 2020 18:51:14 +0200 Tobias Frost wrote:
> Package: sponsorship-requests
> Followup-For: Bug #969910
> Control: close -1
>
> Hi Bastian,
>
> the NMU looks good. I uploaded it to DELAYED/5 and send a nmudiff to the
> package.
> (I'm closing the bug, if something happens to the NMU
Am 15.09.20 um 22:22 schrieb Joel Rivera:
> Bastian,
>
> correct me if I'm wrong, but you're suggesting to remove [1] in favor of [2]?
That is right.
> I've been trying to update editline to the fork that seems to have been
> evolved from the original debian sources at [3]. My interest in parti
Importing the new upstream version 4.5.0 will need the enclosed changes.
Upstream commit dfee8d03468f25667a95902008933e3c4080d38d introduced an
ABI change that might have to be dealt with: Unifying
wolfSSL_sk_SSL_CIPHER_dup and wolfSSL_sk_X509_dup to wolfSSL_sk_dup.
From: Bastian Germann
Date
Control: tag -1 patch
There is a patch available on
https://salsa.debian.org/python-team/modules/libapache2-mod-python
which is not in the last upload's Vcs-Git.
https://salsa.debian.org/fonts-team/grcompiler/-/merge_requests/2
includes the proposed upstream patches.
As already pointed out in #937093, the upstream version 1.17.0 is
compatibel with python3. Please update the Debian package to that version.
What was the point of introducing the python-fdb (py2) package again? It
will never enter testing.
The current xiphos upstream version switched to yelp.
I created a merge request with all necessary changes to import it:
https://salsa.debian.org/pkg-crosswire-team/xiphos/-/merge_requests/4
=1095962
Subject: chromium: add patch for media alloc fix
Closes: https://bugs.gentoo.org/728624
Fixed-by: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Aaron Bauman
[removed third_party/ffmpeg/chromium/dllmain.cc hunk]
Signed-off-by: Bastian Germann
--- /media/base/media.cc
+++ /media/base
Am 16.06.20 um 02:17 schrieb Russell Stuart:
> On Tue, 2020-06-16 at 02:00 +0200, Bastian Germann wrote:
>> It is no longer marked as alpha; version 2.13.15 > 2.13.4-alpha.
>> Please check the RFS again.
>
> Apologies Bastian, I was looking at spyne's home page.
601 - 700 of 729 matches
Mail list logo
