Bug#943500: my NMU made it FTBFS
Hi Jan and Martin,
unfortunately, my NMU made cracklib2 FTBFS on various architectures. It
turns out that the py_builddir_sh also needs the _PYTHON_* variables or
it will disagree with them. I've immediately uploaded another to fix it.
It further simplifies my previous version and simply exports then on the
top level. That was not possible on the initial posting as their value
differed for python 3.8, which is no longer covered.
Sorry for the FTBFS. NMU diff attached.
Helmut
diff --minimal -Nru cracklib2-2.9.6/debian/changelog
cracklib2-2.9.6/debian/changelog
--- cracklib2-2.9.6/debian/changelog2020-12-26 13:42:43.0 +0100
+++ cracklib2-2.9.6/debian/changelog2020-12-30 08:38:46.0 +0100
@@ -1,3 +1,11 @@
+cracklib2 (2.9.6-3.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on various archs: The environment of py_builddir_sh needs to
+carry the _PYTHON_* variables as well.
+
+ -- Helmut Grohne Wed, 30 Dec 2020 08:38:46 +0100
+
cracklib2 (2.9.6-3.3) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru cracklib2-2.9.6/debian/rules cracklib2-2.9.6/debian/rules
--- cracklib2-2.9.6/debian/rules2020-12-26 13:21:03.0 +0100
+++ cracklib2-2.9.6/debian/rules2020-12-29 22:40:05.0 +0100
@@ -23,6 +23,11 @@
CRACKLIB_PACKER=/usr/sbin/cracklib-packer
endif
+# The _PYTHON_* asssignments are required for cross building. Don't
+# delete them unless you verify that cross building keeps working.
+export _PYTHON_HOST_PLATFORM=$(DEB_HOST_ARCH_OS)-$(DEB_HOST_GNU_CPU)
+export
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
+
override_dh_auto_configure:
aclocal && libtoolize && automake --add-missing && autoreconf
mkdir -p $(CURDIR)/debian/buildtmp/base
@@ -34,8 +39,6 @@
--with-default-dict=/var/cache/cracklib/cracklib_dict \
--without-zlib \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
- # The _PYTHON_* asssignments are required for cross building. Don't
- # delete them unless you verify that cross building keeps working.
set -e; \
for i in $(PY3VERS); do \
mkdir -p $(CURDIR)/debian/buildtmp/python$$i; \
@@ -46,8 +49,6 @@
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--with-default-dict=/var/cache/cracklib/cracklib_dict \
--without-zlib \
-
_PYTHON_HOST_PLATFORM=$(DEB_HOST_ARCH_OS)-$(DEB_HOST_GNU_CPU) \
-
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
\
PYTHON_PREFIX=$(call py_builddir_sh,$$i) \
PYTHON=/usr/bin/python$$i \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)"
LDFLAGS="$(LDFLAGS)"; \
@@ -62,8 +63,6 @@
cd $(CURDIR)/debian/buildtmp/python$$i; \
rm -rf lib; ln -s $(CURDIR)/debian/buildtmp/base/lib lib; \
cd python; \
- _PYTHON_HOST_PLATFORM=$(DEB_HOST_ARCH_OS)-$(DEB_HOST_GNU_CPU) \
-
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
\
CFLAGS="-I$(CURDIR)/lib $(CFLAGS)" LDFLAGS="$(LDFLAGS)"
CPPFLAGS="$(CPPFLAGS)" python$$i setup.py build ; \
done
endif
@@ -79,8 +78,6 @@
set -e; \
for i in $(PY3VERS); do \
cd $(CURDIR)/debian/buildtmp/python$$i/python/$(call
py_builddir_sh,$$i); \
- _PYTHON_HOST_PLATFORM=$(DEB_HOST_ARCH_OS)-$(DEB_HOST_GNU_CPU) \
-
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
\
LD_LIBRARY_PATH=$(CURDIR)/debian/buildtmp/base/lib/.libs
python$$i \
-c 'import cracklib;
cracklib.test(dictpath="$(CURDIR)/debian/tmp/cracklib_dict")'; \
done
@@ -139,8 +136,6 @@
set -e; \
for i in $(PY3VERS); do \
cd $(CURDIR)/debian/buildtmp/python$$i/python; \
- _PYTHON_HOST_PLATFORM=$(DEB_HOST_ARCH_OS)-$(DEB_HOST_ARCH) \
-
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
\
python$$i setup.py install --install-layout=deb --root
$(CURDIR)/debian/python3-cracklib; \
done
endif
Bug#896910: O: libdigidoc -- DigiDoc digital signature library
On 2018-04-25, Andrej Shadura wrote: > I intend to orphan libdigidoc. This library is a part of a bigger software > suite for Estonian eID. My current eID is expiring this month, and since I > never used it for anything serious and probably don’t intend to, I won’t be > renewing it. Not being a user, maintaining it in Debian doesn’t seem right > or fair. The status of libdigidoc seems half-way a QA package, and half-way maintained by Andrej Shadura. Notably, a few lintian issues make the current status a bit unclear: https://lintian.debian.org/sources/libdigidoc/3.10.5-1.html E uploaders-in-orphan W no-qa-in-changelog W orphaned-package-maintained-in-private-space Vcs-Git https://salsa.debian.org/eidas-team/libdigidoc.git Since it was orphaned, several uploads have been done, including a switch to using the eidas-team salsa repository. Previously dgit URLs were in Vcs-*. I'd like to do a QA upload to fix a reproducible builds issue (#978064) and other basic package maintenance as I'm able without disturbing the package too much, but the above makes it a little unclear how to proceed... I'd rather just use dgit than subscribe to another salsa team. live well, vagrant signature.asc Description: PGP signature
Bug#977538: fonts-agave: does not follow upstream's recommended build procedure
Hi Gürkan, Am Dienstag, den 29.12.2020, 20:37 +0100 schrieb Gürkan Myczko: > I think that's what you wanted: could you please push your changes to GIT so I can review them there? > Happy New Year! It's not over yet, but I can't wait for it, too. ;) - Fabian signature.asc Description: This is a digitally signed message part
Bug#962296: hotspot: Please package new upstream version (1.3.0)
I'll check it later, maybe within a week. Mathieu Malaterre writes: > 1.3.0 is out > > https://github.com/KDAB/hotspot/releases/tag/v1.3.0
Bug#978678: gnome-calendar: segfault when clicking certain buttons
Package: gnome-calendar Version: 3.30.1-2 Severity: important Dear Maintainer, * What led up to the situation? I'm not sure. One day, clicking on the "next month" arrow when in month view caused app to crash. Once in the next month (via the year view) clicking on "Today" to get back to the current month also caused a segfault. This began happening 2 3 days ago. I found the following in the syslog file "kernel: [1335490.174368] gnome-calendar[18775]: segfault at 10 ip 7f4b4bd989bc sp 7ffdd50160f0 error 4 in libglib-2.0.so.0.5800.3[7f4b4bd7c000+7e000]" "kernel: [1335490.174377] Code: 00 48 8d 35 a6 5b 06 00 48 8d 3d 6d 16 06 00 e8 ba df 01 00 31 c0 48 83 c4 08 c3 0f 1f 00 55 48 89 fd 53 48 89 f3 48 83 ec 08 <8b> 77 10 48 8b 7f 08 e8 38 36 04 00 48 63 75 14 48 89 df 48 ba 00" -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-calendar depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii gsettings-desktop-schemas3.28.1-1 ii libc62.28-10 ii libcairo21.16.0-4 ii libdazzle-1.0-0 3.30.2-2 ii libecal-1.2-19 3.30.5-1+deb10u1 ii libedataserver-1.2-233.30.5-1+deb10u1 ii libedataserverui-1.2-2 3.30.5-1+deb10u1 ii libgeoclue-2-0 2.5.2-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgoa-1.0-0b3.30.1-2 ii libgtk-3-0 3.24.5-1 ii libgweather-3-15 3.28.2-2 ii libical3 3.0.4-3 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libsoup2.4-1 2.64.2-2 Versions of packages gnome-calendar recommends: ii evolution-data-server 3.30.5-1+deb10u1 gnome-calendar suggests no packages. -- no debconf information -- Znoteer znot...@mailbox.org
Bug#978685: libjhlabs-filters-java: tries to overwrite /usr/share/doc-base/doc-base
Package: libjhlabs-filters-java Version: 2.0.235-3.1 Severity: serious The source NMU and subsequent rebuild of (the quite ancient) libjhlabs-filters-java resulted in a binary package containing /usr/share/doc-base/doc-base, which breaks the dpkg install run. This has been addressed in the upload of 2.0.235-4.
Bug#978675: libsys-hostname-long-perl: FTBFS, tests fail
Control: tag -1 + ftbfs fixed Hi Holger, Holger Levsen wrote: > Package: libsys-hostname-long-perl > Version: 1.5-1 I've added the tag ftbfs so that it also shows up on https://buildd.debian.org/status/package.php?p=libsys-hostname-long-perl > when trying to build libsys-hostname-long-perl in current sid it fails: Thanks for the bug report. gregoa just made an upload which modernizes the package and also increases verbosity to see what actually goes wrong. And as it seems, the general overhaul seems also have to fixed this issue. At least on the buildds, the package built fine: https://buildd.debian.org/status/package.php?p=libsys-hostname-long-perl=unstable Holger: Can you check if this is the case on your side, too? gregoa: I'll leave up to you if you already want to close the bug report or not. Feel free to replace my fixed tag with a pending tag or so. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
On Tue, 29 Dec 2020 14:52:17 +0100 Ansgar wrote: > On Mon, 2020-12-28 at 20:34 -0800, Josh Triplett wrote: > > - Make pam_unix dlopen the necessary libraries > [...] > > - Build pam_unix with and without NIS support, and make libpam- > > modules > > Wouldn't it be cleaner to move NIS stuff into its own PAM module, > i.e. a pam_nis? Yes, absolutely. Unfortunately, pam_unix has historically had NIS support built-in rather than as a separate module, so at the very least, moving that to a separate module would require a *very careful* configuration migration. And compared to other possibilities, editing existing PAM configuration seems extremely error-prone. That would also be a divergence from upstream PAM. For all those reasons, I'd be extremely hesitant to advocate such an approach. That said, if that were the approach the PAM maintainers would prefer, I'd be happy to help implement it. It seems more robust to either dlopen NIS support or ship two versions of pam_unix. Both of those would keep existing configurations working entirely unmodified. The former approach would involve a NEWS.Debian entry telling the user to install NIS libraries if needed; the latter would involve either a package with the NIS version of pam_unix and a diversion, or two mutually exclusive packages. > > - Migrate libpam-modules itself towards dropping the Essential flag. [For clarity, this would be a much larger task, and I'm not proposing doing this quickly. I think it would make more sense to take one of the other steps first.] > Do utilities like `su` or `sudo` still work w/o libpam-modules > installed (at least for root)? No, by design they would not; if you want to use either of those, or otherwise support interactive users, you'd need PAM installed and configured. sudo already depends on libpam-modules. passwd does as well. setuid/setgid programs would still work. And there are several tools that can run programs as a different user: setpriv for interactive or script use as root, start-stop-daemon for init scripts, systemd's User and Group directives, runit's chpst, and likely others. So it would still be possible to run programs as other users, and to drop privileges; it just wouldn't be possible to interactively authenticate to gain privileges. Any system with interactive users almost certainly wants PAM. Embedded systems, special-purpose servers, and containers/chroots don't necessarily need it, though. > Is it possible to log in to a system w/o libpam-modules installed? > Via OpenSSH public key auth? Via local console? It's possible to log in via OpenSSH or Dropbear or similar, if configured to not use PAM. OpenSSH does have a hard dependency on libpam-modules, but dropbear would work (and it's a common choice on embedded systems).
Bug#978382: phpmyadmin: FTBFS: Test directory "./test/engines" not found
Hi, Le Sat, Dec 26, 2020 at 11:07:44PM +0100, Lucas Nussbaum a écrit : > Source: phpmyadmin […] > > PHPUnit 9.5.0 by Sebastian Bergmann and contributors. > > > > Test directory "./test/engines" not found > > make[1]: *** [debian/rules:16: override_dh_auto_test] Error 2 This issue may be trivial (you “just” need to skip the Engines testsuite), but a look at the last buildlog of phpmyadmin reveals 459 warnings, most of them related to PHPUnit 9 (that are now errors). I’m sorry I haven’t noticed this sooner: the new autopkgtest failures didn’t show up about the transition of phpunit from experimental (and they still don’t show up regarding the transition of phpunit to testing). I notice that PHPMyAdmin 5 has already been released a year ago, and the next one will be 5.1 (already RC) according to their last announcement. On the other end, 4.9 seems to be the LTS to support PHP 5.5-7.0 (no end of extended security support available on their public download page). Since version 5 is not yet in Debian, I assume you intend to ship version 4.9 for Bullseye (but would prefer to have an explicit acknowledgement before trying to look at all of these issues). On the other hand, I believe this version won’t be compatible with PHP 8.0, so you may want to at least document that in a bug blocking #976811 if you intend to stick with 4.9. Anyway, I apologize for pushing PHPUnit 9 to unstable so late in the release cycle (#976811 transition: php8.0 triggered some panic), and intend to help fixing those issues if needed, so please, do not hesitate to ask, I CCed the PHP PEAR (and Composer) Maintainers list for that. Regards David signature.asc Description: PGP signature
Bug#870682: a2ps does not install files in (x)emacs paths
On 2017-08-03, David Bremner wrote: > The .el files are in the binary package, but I guess the postinst > doesn't follow debian emacs policy to get the files byte compiled and > installed in the right place. In the QA upload I just did, I thought about weather to fix this by converting to dh-elpa based on the lintian warning: https://lintian.debian.org/tags/emacsen-common-without-dh-elpa.html "Please consider transitioning the package build to use dh-elpa, unless the package is required to work with XEmacs." But it wasn't clear to me, a humble QA uploader barely familiar with emacs, XEmacs, and .el files at all, weather it is required to work with XEmacs or how I would figure that out. The lintian warning I saw helpfully provided a link (that I managed to ignore until just a few moments ago) to: https://wiki.debian.org/Teams/DebianEmacsenTeam/elpa-hello But that seems geared towards a package actually shipping a package just for elpa, as opposed to a package that happens to ship a stray, lonely .el file. And with a very brief and casual search, none of the above linked to a Debian Emacs Policy, though if I spent even more time looking for it, maybe I would find it helpful... oh look, the emacsen-common package ships /usr/share/doc/emacsen-common/debian-emacs-policy.gz ... that is probably it. Well, if anyone more courageous than me wants to take a stab at making a2ps comply with debian-emacs-policy, maybe my meandering response will help you find your way to a patch and/or upload. live well, vagrant signature.asc Description: PGP signature
Bug#971930: a2ps-lpr-wrapper.1: fix some typographic issues
Control: tags 971930 - patch On 2020-10-09, Bjarni Ingi Gislason wrote: > Fix warnings from "mandoc -T lint" (superfluous macro ".PP"). > > Fix warnings from test-groff (space at the end of an argument). > > Reduce space between words. > > Begin a sentence on a new line. > > Remove an unnecessary second font change. > > Use ".BR" for references for a manual page. > > ### > > Patch: > > --- a2ps-lpr-wrapper.12020-10-08 20:32:56.0 + > +++ a2ps-lpr-wrapper.1.new2020-10-08 23:24:03.0 + > @@ -2,31 +2,27 @@ > .SH "NAME" > a2ps-lpr-wrapper \(em lp/lpr wrapper script for GNU a2ps on Debian > .SH "SYNOPSIS" > -.PP > -\fBa2ps-lpr-wrapper\fR [\fB-d \fIprinter\fR\fP] [\fB\fIfiles\fR\fP] > +\fBa2ps-lpr-wrapper\fR [\fB-d \fIprinter\fR] [\fB\fIfiles\fR] > .SH "DESCRIPTION" > -.PP > This manual page documents briefly the > -\fBa2ps-lpr-wrapper\fR command. > +\fBa2ps-lpr-wrapper\fR command. > .PP > \fBa2ps-lpr-wrapper\fR uses either > \fBlp\fP or \fBlpr\fP to send > -\fIfiles\fR to \fIprinter\fR. It > -determines which of the two programs is currently installed and adds the > -appropriate parameters. > +\fIfiles\fR to \fIprinter\fR. > +It determines which of the two programs is currently installed and > +adds the appropriate parameters. > .SH "OPTIONS" > -.IP "\fB-d \fIprinter\fR\fP " 10 > +.IP "\fB-d \fIprinter\fR" 10 > Destination system printer. > -.IP "\fB\fIfiles\fR\fP " 10 > +.IP \fIfiles\fR 10 > List of files to be printed. > .SH "SEE ALSO" > -.PP > -a2ps (1). > +.BR a2ps (1). > .PP > The programs are documented fully by the a2ps documentation available via the > \fBInfo\fP system. > .SH "AUTHOR" > -.PP > This manual page was written by Michael Tautschnig tauts...@model.in.tum.de > for > the \fBDebian\fP system (but may be used by others). Permission is > granted to copy, distribute and/or modify this document under Thanks for the patch! Unfortunately it cannot be applied to the package, as a2ps-lpr-wrapper.1 is generated from debian/manpages/a2ps-lpr-wrapper.sgml: https://browse.dgit.debian.org/a2ps.git/tree/debian/manpages/a2ps-lpr-wrapper.sgml In debian/rules: https://browse.dgit.debian.org/a2ps.git/tree/debian/rules#n27 Can you update your patch to apply to the .sgml source? live well, vagrant signature.asc Description: PGP signature
Bug#978381: google-recaptcha: FTBFS: TypeError: Argument 2 passed to PHPUnit\Framework\Assert::assertContains() must be iterable, string given, called in /<>/tests/ReCaptcha/RequestMethod
Control: tag -1 patch
Le Sat, Dec 26, 2020 at 11:02:04PM +0100, Lucas Nussbaum a écrit :
> Relevant part (hopefully):
[…]
> > There were 6 errors:
> >
> > 1) ReCaptcha\ReCaptchaTest::testExceptionThrownOnInvalidSecret with data
> > set #0 ('')
> > RuntimeException: No secret provided
[…]
> > 6) ReCaptcha\RequestMethod\PostTest::testHTTPContextOptions
> > TypeError: Argument 2 passed to PHPUnit\Framework\Assert::assertContains()
> > must be iterable, string given, called in
> > /<>/tests/ReCaptcha/RequestMethod/PostTest.php on line 118
Please find attached a patch fixing these issues (that were already
warnings with PHPUnit 8).
I wonder why this failure wasn’t caught sooner by the autopkgtest (or I
would have noticed it before pushing PHPUnit 9 to unstable).
Regards
David
From: =?utf-8?q?David_Pr=C3=A9vot?=
Date: Tue, 29 Dec 2020 22:51:55 -0400
Subject: Adapt to recent version of PHPUnit (9)
Bug-Debian: https://bugs.debian.org/978381
---
tests/ReCaptcha/ReCaptchaTest.php | 2 +-
tests/ReCaptcha/RequestMethod/PostTest.php | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/ReCaptcha/ReCaptchaTest.php b/tests/ReCaptcha/ReCaptchaTest.php
index ddb16f0..6a90d9e 100644
--- a/tests/ReCaptcha/ReCaptchaTest.php
+++ b/tests/ReCaptcha/ReCaptchaTest.php
@@ -40,11 +40,11 @@ class ReCaptchaTest extends TestCase
{
/**
- * @expectedException \RuntimeException
* @dataProvider invalidSecretProvider
*/
public function testExceptionThrownOnInvalidSecret($invalid)
{
+$this->expectException('\RuntimeException');
$rc = new ReCaptcha($invalid);
}
diff --git a/tests/ReCaptcha/RequestMethod/PostTest.php b/tests/ReCaptcha/RequestMethod/PostTest.php
index bdfb78e..88a298d 100644
--- a/tests/ReCaptcha/RequestMethod/PostTest.php
+++ b/tests/ReCaptcha/RequestMethod/PostTest.php
@@ -115,7 +115,7 @@ class PostTest extends TestCase
'Content-type: application/x-www-form-urlencoded',
);
foreach ($headers as $header) {
-$this->assertContains($header, $options['http']['header']);
+$this->assertStringContainsString($header, $options['http']['header']);
}
}
signature.asc
Description: PGP signature
Bug#978684: autopkgtest should test the installed package
Source: apk-parser Severity: serious Hi, As pointed in the see autopkgtest specification [1] linked from the release team documentation [2] “the tests must test the *installed* version of the package”. The autopkgtest from this package only uses the source package, and as such violates the specification. Displaying it as an example in the wiki [3] may not be advisable. Regards David 1: https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst 2: https://release.debian.org/bullseye/freeze_policy.html 3: https://wiki.debian.org/Java/Packaging#autopkgtest signature.asc Description: PGP signature
Bug#978683: Cython appears to default to Py2, even for a Py3 build
Source: peewee
Version: 3.14.0+dfsg-1
Severity: important
I hope I'm wrong, but this doesn't look right to me:
L838 of the build log for 3.14.0+dfsg-1
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:369: FutureWarning:
Cython directive 'language_level' not set, using 2 for now (Py2). This will
change in a later release! File: /<>/playhouse/_sqlite_ext.pyx
tree = Parsing.p_module(s, pxd, full_module_name)
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:369: FutureWarning:
Cython directive 'language_level' not set, using 2 for now (Py2). This will
change in a later release! File: /<>/playhouse/_sqlite_udf.pyx
tree = Parsing.p_module(s, pxd, full_module_name)
I unsuccessfully attempted to enable a Cython extension for this in
setup.py. I also unsuccessfully attempted to enable Py3 using the "#
cython: language_level=3" header in playhouse/_sqlite_ext.pyx and
playhouse/_sqlite_udf.pyx.
In the second case I got a useful warning and backtrace, which makes
me suspect this might need work upstream.
[1/2] Cythonizing playhouse/_sqlite_ext.pyx
Error compiling Cython file:
...
# Store a reference to the columns in the index info structure.
joinedCols = encode(','.join(columns))
idxStr = sqlite3_malloc((len(joinedCols) + 1) * sizeof(char))
memcpy(idxStr, joinedCols, len(joinedCols))
idxStr[len(joinedCols)] = '\x00'
^
playhouse/_sqlite_ext.pyx:612:34: Unicode literals do not support coercion to C
types other than Py_UNICODE/Py_UCS4 (for characters) or Py_UNICODE* (for
strings).
Traceback (most recent call last):
File "setup.py", line 162, in
_do_setup(extension_support, sqlite_extension_support)
File "setup.py", line 157, in _do_setup
ext_modules=cythonize(ext_modules))
File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", line
1097, in cythonize
cythonize_one(*args)
File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", line
1220, in cythonize_one
raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: playhouse/_sqlite_ext.pyx
Regards,
Nicholas
Bug#978682: xfce4-verve-plugin: build-depends on obsolete package.
Package: xfce4-verve-plugin Version: 2.0.0-1 Severity: serious Tags: bullseye, sid xfce4-verve-plugin build-depends on libexo-1-dev which is no longer built by the exo source package, it is still present in unstable as a cruft package, but is completely gone from testing.
Bug#978681: xfce4-mpc-plugin: build-depends on obsolete package.
Package: xfce4-mpc-plugin Version: 0.5.2-1 Severity: serious Tags: bullseye, sid xfce4-mpc-plugin build-depends on libexo-1-dev which is no longer built by the exo source package, it is still present in unstable as a cruft package, but is completely gone from testing.
Bug#978680: xfce4-indicator-plugin: build-depends on obsolete package.
Package: xfce4-indicator-plugin Version: 2.3.4-2 Severity: serious Tags: bullseye, sid xfce4-indictor-plugin build-depends on libexo-1-dev which is no longer built by the exo source package, it is still present in unstable as a cruft package, but is completely gone from testing.
Bug#978679: bedtools: autpkgtest failures
Package: bedtools Version: 2.29.2+dfsg-4 Severity: serious The autopkgtests for bedtools are failing on all tested architectures (though they are "not a regression" on i386 and armhf). When I look at the amd64 failure logs, the failures all seem to be missing "../htsutil" Testing bedtools bamtobed: test-bamtobed.sh: line 22: ../htsutil: No such file or directory Testing bedtools bamtofastq: test-bamtofastq.sh: line 17: ../htsutil: No such file or directory Testing bedtools bedtobam: bedtobam.t1...test-bedtobam.sh: line 23: ../htsutil: No such file or directory Testing bedtools coverage: test-coverage.sh: line 22: ../htsutil: No such file or directory Testing bedtools genomecov: test-genomecov.sh: line 22: ../htsutil: No such file or directory Testing bedtools intersect: intersect.t01...ok intersect.t02...ok intersect.t03...ok intersect.t04...ok intersect.t05...ok intersect.t06...ok intersect.t07...ok intersect.t08...ok intersect.t09...ok intersect.t10...ok intersect.t11...ok intersect.t12...ok intersect.t13...ok intersect.t14...ok intersect.t15...ok intersect.t16...ok test-intersect.sh: line 200: ../htsutil: No such file or directory Testing bedtools multicov: test-multicov.sh: line 17: ../htsutil: No such file or directory
Bug#978667: bug #978667 update
see attached for program which generates the reported bug.This program assumes (two identical) cameras at /dev/video1 and /dev/video3// v4l2_test.c
// compile as $ gcc v4l2_test.c -o v4l2_test
#define MMAP_BUFFERS 3
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct v4l2_capability lcap, rcap;
struct v4l2_format lfmt, rfmt;
int xioctl(int fh, int request, void *arg){
int r;
do {
r = ioctl(fh, request, arg);
} while (r == -1 && ((errno == EINTR) || (errno == EAGAIN)));
return r;
}
int main(int argc, char **argv){
char *left_camera, *right_camera;
int lfd, rfd, i, r;
struct v4l2_buffer lbuf, rbuf;
left_camera = "/dev/video1";
right_camera = "/dev/video3";
// Open the device
lfd = open(left_camera, O_RDWR | O_NONBLOCK, 0);
if (lfd < 0) {
printf("Failed to open left camera\n");
exit(EXIT_FAILURE);
}
rfd = open(right_camera, O_RDWR | O_NONBLOCK, 0);
if (rfd < 0) {
printf("Failed to open right camera\n");
exit(EXIT_FAILURE);
}
if (-1 == xioctl(lfd, VIDIOC_QUERYCAP, )) {
printf("Left ERROR: %s\n", strerror(errno));
if(lcap.capabilities != V4L2_CAP_VIDEO_CAPTURE)
printf("ERROR Left camera deficient capability\n");
exit(EXIT_FAILURE);
}
if (-1 == xioctl(rfd, VIDIOC_QUERYCAP, )) {
printf("Right ERROR: %s\n", strerror(errno));
if(rcap.capabilities != V4L2_CAP_VIDEO_CAPTURE)
printf("ERROR Right camera deficient capability\n");
exit(EXIT_FAILURE);
}
// poll fd for device format
lfmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; // == 1
if(-1 == xioctl(lfd, VIDIOC_G_FMT, )){
printf("ERROR getting info from %s\n", left_camera);
return 1;
}
// poll fd for device format
rfmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; // == 1
if(-1 == xioctl(rfd, VIDIOC_G_FMT, )){
printf("ERROR getting info from %s\n", right_camera);
return 1;
}
// Request N buffers that are memory mapped between
// our application space and the device
struct v4l2_requestbuffers l_request, r_request;
l_request.count = r_request.count = MMAP_BUFFERS;
l_request.type = r_request.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
l_request.memory = r_request.memory = V4L2_MEMORY_MMAP;
if(r = xioctl(lfd, VIDIOC_REQBUFS, _request) < 0){
printf("ERROR Request l buffer failed\n");
}
if(r = xioctl(lfd, VIDIOC_REQBUFS, _request) < 0){
printf("ERROR Request r buffer failed\n");
}
if(l_request.count != r_request.count)
printf("ERROR in request count match\n");
printf("request count = %d\n", l_request.count);
// Queue the buffers, i.e. indicate to the device
// that they are available for writing now.
for (i = 0; i < l_request.count; ++i) {
// struct v4l2_buffer buf; - declared at head of main()
lbuf.type = rbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
lbuf.memory = rbuf.memory = V4L2_MEMORY_MMAP;
lbuf.index = rbuf.index = i;
if(r = xioctl(lfd, VIDIOC_QBUF, ) < 0)
printf("ERROR Failed to QBUF left camera\n");
if(r = xioctl(rfd, VIDIOC_QBUF, ) < 0)
printf("ERROR Failed to QBUF right camera\n");
}
// Start stream v4l_buf_type
enum v4l2_buf_type type;
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
r = xioctl(lfd, VIDIOC_STREAMON, );
if(r < 0)printf("ERROR Failed to STREAMON left camera\n");
r = xioctl(rfd, VIDIOC_STREAMON, );
if(r < 0)printf("ERROR Failed to STREAMON right camera\n");
}
Bug#978667: bug #978667 update
There is a typo in line 95 my previous submission. Corrected program is attachedThe result is that ioctl(rfd, VIDIOC_QBUF, );is successful, but ioctl(rfd, VIDIOC_STREAMON, );(i.e. second camera) is not successful// v4l2_test.c
// compile as $ gcc v4l2_test.c -o v4l2_test
#define MMAP_BUFFERS 3
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct v4l2_capability lcap, rcap;
struct v4l2_format lfmt, rfmt;
int xioctl(int fh, int request, void *arg){
int r;
do {
r = ioctl(fh, request, arg);
} while (r == -1 && ((errno == EINTR) || (errno == EAGAIN)));
return r;
}
int main(int argc, char **argv){
char *left_camera, *right_camera;
int lfd, rfd, i, r;
struct v4l2_buffer lbuf, rbuf;
left_camera = "/dev/video1";
right_camera = "/dev/video3";
// Open the device
lfd = open(left_camera, O_RDWR | O_NONBLOCK, 0);
if (lfd < 0) {
printf("Failed to open left camera\n");
exit(EXIT_FAILURE);
}
rfd = open(right_camera, O_RDWR | O_NONBLOCK, 0);
if (rfd < 0) {
printf("Failed to open right camera\n");
exit(EXIT_FAILURE);
}
if (-1 == xioctl(lfd, VIDIOC_QUERYCAP, )) {
printf("Left ERROR: %s\n", strerror(errno));
if(lcap.capabilities != V4L2_CAP_VIDEO_CAPTURE)
printf("ERROR Left camera deficient capability\n");
exit(EXIT_FAILURE);
}
if (-1 == xioctl(rfd, VIDIOC_QUERYCAP, )) {
printf("Right ERROR: %s\n", strerror(errno));
if(rcap.capabilities != V4L2_CAP_VIDEO_CAPTURE)
printf("ERROR Right camera deficient capability\n");
exit(EXIT_FAILURE);
}
// poll fd for device format
lfmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; // == 1
if(-1 == xioctl(lfd, VIDIOC_G_FMT, )){
printf("ERROR getting info from %s\n", left_camera);
return 1;
}
// poll fd for device format
rfmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; // == 1
if(-1 == xioctl(rfd, VIDIOC_G_FMT, )){
printf("ERROR getting info from %s\n", right_camera);
return 1;
}
// Request N buffers that are memory mapped between
// our application space and the device
struct v4l2_requestbuffers l_request, r_request;
l_request.count = r_request.count = MMAP_BUFFERS;
l_request.type = r_request.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
l_request.memory = r_request.memory = V4L2_MEMORY_MMAP;
if(r = xioctl(lfd, VIDIOC_REQBUFS, _request) < 0){
printf("ERROR Request l buffer failed\n");
}
if(r = xioctl(rfd, VIDIOC_REQBUFS, _request) < 0){
printf("ERROR Request r buffer failed\n");
}
if(l_request.count != r_request.count)
printf("ERROR in request count match\n");
printf("request count = %d\n", l_request.count);
// Queue the buffers, i.e. indicate to the device
// that they are available for writing now.
for (i = 0; i < l_request.count; ++i) {
// struct v4l2_buffer buf; - declared at head of main()
lbuf.type = rbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
lbuf.memory = rbuf.memory = V4L2_MEMORY_MMAP;
lbuf.index = rbuf.index = i;
if(r = xioctl(lfd, VIDIOC_QBUF, ) < 0)
printf("ERROR Failed to QBUF left camera\n");
if(r = xioctl(rfd, VIDIOC_QBUF, ) < 0)
printf("ERROR Failed to QBUF right camera\n");
}
// Start stream v4l_buf_type
enum v4l2_buf_type type;
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
r = xioctl(lfd, VIDIOC_STREAMON, );
if(r < 0)printf("ERROR Failed to STREAMON left camera\n");
r = xioctl(rfd, VIDIOC_STREAMON, );
if(r < 0)printf("ERROR Failed to STREAMON right camera\n");
}
Bug#978677: ITP: backport9 -- A collection of backports and utilities to support libraries in Java 9
Package: wnpp Severity: wishlist Owner: po...@debian.org * Package name : backport9 Version : 1.10 Upstream Author : Charles Oliver Nutter * URL : https://github.com/headius/backport9 * License : Apache-2.0 Programming Lang: Java Description : A collection of backports and utilities to support libraries and apps that want to use Java 9 features but still function on Java 8. This package is a dependency for jruby 9.2.x. I intend to maintain it in the Java Team. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#978676: wolfssl: New upstream version 4.6.0
Source: wolfssl Version: wolfssl/4.5.0+dfsg-4 Severity: normal A new wolfSSL version 4.6.0 is available. Patches are enclosed with all necessary changes to build the new version. Please consider updating the package. >From 5e5c68b3f7a70cf46bf67bf0a41956729bd02863 Mon Sep 17 00:00:00 2001 From: Bastian Germann Date: Tue, 29 Dec 2020 20:01:25 +0100 Subject: [PATCH 1/5] Amend general copyright year --- debian/copyright | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/copyright b/debian/copyright index 295b8f784..40c6abc9c 100644 --- a/debian/copyright +++ b/debian/copyright @@ -15,7 +15,7 @@ Files-Excluded: Files: * Copyright: - 2006-2019 wolfSSL Inc. + 2006-2020 wolfSSL Inc. License: GPL-2+ Files: -- 2.29.2 >From 80b6272b1ea8298c46fb0f8efe341a1373ed508c Mon Sep 17 00:00:00 2001 From: Bastian Germann Date: Tue, 29 Dec 2020 23:33:39 +0100 Subject: [PATCH 2/5] Remove upstream patch --- ...cc91d0cd276befe7f08f87ba2dc5ee7122ff.patch | 26 --- debian/patches/series | 1 - 2 files changed, 27 deletions(-) delete mode 100644 debian/patches/b90acc91d0cd276befe7f08f87ba2dc5ee7122ff.patch diff --git a/debian/patches/b90acc91d0cd276befe7f08f87ba2dc5ee7122ff.patch b/debian/patches/b90acc91d0cd276befe7f08f87ba2dc5ee7122ff.patch deleted file mode 100644 index ec70ea9fa..0 --- a/debian/patches/b90acc91d0cd276befe7f08f87ba2dc5ee7122ff.patch +++ /dev/null @@ -1,26 +0,0 @@ -Description: Make ByteReverseWords available on s390x - Cherry picked from upstream -Origin: https://github.com/wolfSSL/wolfssl/pull/3255/commits/b90acc91d0cd276befe7f08f87ba2dc5ee7122ff -Forwarded: not-needed -This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ -diff --git a/wolfcrypt/src/misc.c b/wolfcrypt/src/misc.c -index fe66ee0a1a..23bfa1adc5 100644 a/wolfcrypt/src/misc.c -+++ b/wolfcrypt/src/misc.c -@@ -120,7 +120,6 @@ WC_STATIC WC_INLINE word32 ByteReverseWord32(word32 value) - return rotlFixed(value, 16U); - #endif - } --#if defined(LITTLE_ENDIAN_ORDER) - /* This routine performs a byte swap of words array of a given count. */ - WC_STATIC WC_INLINE void ByteReverseWords(word32* out, const word32* in, - word32 byteCount) -@@ -131,7 +130,6 @@ WC_STATIC WC_INLINE void ByteReverseWords(word32* out, const word32* in, - out[i] = ByteReverseWord32(in[i]); - - } --#endif /* LITTLE_ENDIAN_ORDER */ - - #if defined(WORD64_AVAILABLE) && !defined(WOLFSSL_NO_WORD64_OPS) - diff --git a/debian/patches/series b/debian/patches/series index 4ab700070..229a39e30 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,4 +1,3 @@ -b90acc91d0cd276befe7f08f87ba2dc5ee7122ff.patch utf8.patch multi-arch.patch reproducible-build.patch -- 2.29.2 >From 10ef9256051987983fbaed7943373e97407ea423 Mon Sep 17 00:00:00 2001 From: Bastian Germann Date: Tue, 29 Dec 2020 23:36:47 +0100 Subject: [PATCH 3/5] Update DFSG patch --- debian/patches/dfsg.patch | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/debian/patches/dfsg.patch b/debian/patches/dfsg.patch index b1a47c7dd..52775a920 100644 --- a/debian/patches/dfsg.patch +++ b/debian/patches/dfsg.patch @@ -3,9 +3,9 @@ Forwarded: not-needed From: Felix Lechner --- a/Makefile.am +++ b/Makefile.am -@@ -168,25 +168,6 @@ include tests/include.am - include sslSniffer/sslSnifferTest/include.am +@@ -173,25 +173,6 @@ include sslSniffer/sslSnifferTest/include.am include rpm/include.am + include linuxkm/include.am -# Exclude references to non-DFSG sources from build files -if !BUILD_DISTRO @@ -28,4 +28,4 @@ From: Felix Lechner -endif include scripts/include.am - if USE_VALGRIND + if BUILD_LINUXKM -- 2.29.2 >From c277ef0951b1252203685036b09ad1873fc42534 Mon Sep 17 00:00:00 2001 From: Bastian Germann Date: Tue, 29 Dec 2020 23:28:08 +0100 Subject: [PATCH 4/5] Replace patches with configure option --- debian/patches/disable-crl-monitor.patch | 18 -- debian/patches/series | 2 -- .../patches/turn-off-fastmath-for-amd64.patch | 24 --- debian/rules | 2 ++ 4 files changed, 2 insertions(+), 44 deletions(-) delete mode 100644 debian/patches/disable-crl-monitor.patch delete mode 100644 debian/patches/turn-off-fastmath-for-amd64.patch diff --git a/debian/patches/disable-crl-monitor.patch b/debian/patches/disable-crl-monitor.patch deleted file mode 100644 index 9bd9a8e25..0 --- a/debian/patches/disable-crl-monitor.patch +++ /dev/null @@ -1,18 +0,0 @@ -Description: Disable CRL monitor on all architectures - CRL monitor is unavailable on Debian architecture kFreeBSD, causes FTBFS -Author: Felix Lechner -Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860514 -Forwarded: not-needed -Last-Update: 2017-04-22 -This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ a/configure.ac -+++
Bug#977982: Info received (Bug#977982: mirrors.ptisp.pt: 403 Forbidden error)
Fixed. Sent from my iPhone > On 23 Dec 2020, at 21:19, Debian Bug Tracking System > wrote: > > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Mirrors Team > > If you wish to submit further information on this problem, please > send it to 977...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 977982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977982 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#975696: [Pkg-sugar-devel] Bug#975696: link-grammar: multi-thread test fails
Control: severity -1 serious Quoting Jonas Smedegaard (2020-12-29 23:30:11) > Quoting Graham Inggs (2020-12-29 20:35:03) > > The build of link-grammar/5.8.0-3 has already failed on ppc64el [1] > > (details below). > > > > As fun as it is, please let's avoid the BTS sports and leave this > > bug open until link-grammar builds and passes its autopkgtests > > reliably. > > I closed the bugreport when in -3 I optimistally expected the test > failures to be gone. I agree this bug should stay open when that's > not the case. > > I disagree, however, that the current level of flakiness renders the > package unsuitable for a stable Debian release. Ouch - I begin to understand now why others before ne had patches the build routines to fully avoid checking tests during build: autopkgtest can be marked build-needed and flaky, but apparently the build includes any build-time tests and failing those are not considered flaky. I am now in touch with upstream on getting to the bottom of the causes for the test failure. I will also try simplify autopkgtest to not need to rebuild all source. I've bumped severity back to serious: I thought that a) build-time failure was less frequent and b) I had succeeded in annotating this test as flaky for autopkgtest - but the latter is clearly not the case and I am not so sure about the former either... :-/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#978589: systemd based startup not working
> Once logged in, I can see some active process of xscreensaver (this is what > "pidof xscreensaver" tells me). > > But after some seconds, this process is gone. Why? Don't know. Dunno. Maybe it's trying to connect and timing out. Run xscreensaver with --log log.txt Or if you have an old version, -verbose -no-capture -log log.txt > 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd > > The manpage of this binary is slightly confusing. That is some kind of > helper, fine, but who is supposed to run it? Xsession? Or systemd user > session? It mentions "When run from ~/.xsession or equivalent" but there > is no information on what is considered "equivalent" here. It is launched by xscreenasver itself. > Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Service has > more than one ExecStart= setting, which is only allowed for Type=oneshot > services. Refusing. > Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Cannot add > dependency job, ignoring: Unit xscreensaver.service has a bad unit file > setting. Sounds like it doesn't like your edits? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Mon, Dec 28 2020, 06:07:55PM]: > The fact that $DISPLAY is not set at the time xscreensaver is launched is not > a good sign. The cookie error suggests that ~/.Xauthority does not exist or > is not readable. However you do appear to be running as yourself, not as > "nobody". Perhaps $HOME is set to something weird? Maybe try setting your > command to "printenv ; pwd ; xdpyinfo ; xscreensaver" and see if that > provides some clues. > No, nothing special I am aware of. Symptoms are very strange. Once logged in, I can see some active process of xscreensaver (this is what "pidof xscreensaver" tells me). But after some seconds, this process is gone. Why? Don't know. And I see another process, what is this? 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd The manpage of this binary is slightly confusing. That is some kind of helper, fine, but who is supposed to run it? Xsession? Or systemd user session? It mentions "When run from ~/.xsession or equivalent" but there is no information on what is considered "equivalent" here. Anyway, I patched /usr/lib/systemd/user/xscreensaver.service to add your instructions: $ cat /usr/lib/systemd/user/xscreensaver.service [Unit] Description=XScreenSaver [Service] #ExecStart=xscreensaver ExecStart=/bin/sh -c "printenv ; pwd ; xdpyinfo ; xscreensaver" [Install] WantedBy=default.target I did daemon-reload (for --user). Net result: no visible change but the state is this now: $ systemctl --user status xscreensaver.service ● xscreensaver.service - XScreenSaver Loaded: loaded (/usr/lib/systemd/user/xscreensaver.service; enabled; vendor preset: enabled) Active: inactive (dead) Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing. Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Cannot add dependency job, ignoring: Unit xscreensaver.service has a bad unit file setting. Now this does not make any sense anymore. Best regards, Eduard.
Bug#977237: icewm: background image not shown
Source: icewm Followup-For: Bug #977237 Not a problem with icewm 2.0.0 fro testing. -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (990, 'stable'), (800, 'oldoldstable'), (800, 'testing'), (500, 'oldoldstable'), (400, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system)
Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Ross, Ross Gammon writes: > I have spent some time going through the commit messages. There has > been a lot of work done! Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between prereleases was the worst of it. >> Will you be sponsoring from git or mentors? How would you like me to >> work during the WIP cycles of the review? The git history will look a >> bit silly and confusing with too many "refinalise for release to >> unstable" commits ;-) > > I can do either. But I think in this case, I would prefer to work from > mentors (mainly because I have problems with my gbp setup on this > computer). But please also keep the git repository in sync (even if it > is on a different branch that we can merge later). > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it just now; it doesn't contain much yet. I will update mentors as soon as we have an upload candidate (still too many outstanding big issues at this time). > Actually, I would like to compliment you on your commit messages. It was > pleasing to see a verbose reason for the change, instead of some short > cryptic message that just generates more questions. > Thank you you, I appreciate that you noticed! It really helps with making sense of work from months ago that I've now forgotten the details and reasoning. And for other team members, of course. 'wish all new contributors were mentored to value this ;-) (I was) >> On #debian-multimedia, Sebastinas did a preliminary review, and two big >> issues were: >> >> 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >>* I've fixed this locally >> 2. I was missing an override_dh_auto_configure to make use of >>$DEB_CMAKE_EXTRA_FLAGS >>* I believe that is why the extra lib and dev packages became >> necessary. Now that I know what was causing the problem I can >> restore something closer to the old packaging. >>* Changing this in the future will require another trip through NEW, >> so what do you think the correct split of the package is? > > I was wondering why the library packages suddenly appeared. I think if > it is possible, it is best to stick to the old packages. What > applications would want to use hydrogen as a library? > Hypothetical 3rd party plugins, I think? Unfortunately even with -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which appears to have not been installed in the 0.9.7 series of Debian packages. I can whitelist and ignore it, but for comparison to other distributions, OpenSUSE chose to ship the lib: https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) Also, I'm also not sure if there is any practical benefit to hydrogen-dev (hypothetical plugin development), so I'm wondering if the headers should not be installed; they weren't installed in the last release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package is arch-specific, and if that's the case it seems like merging the -dev package into bin:libhydrogen-core-1.0.1 would be reasonable. There is something to be said the principle of least surprise when moving between distributions, but I don't have a position on way or the other. At this time we can also reassess the hydrogen and hydrogen-data split. If I was packaging Hydrogen from scratch I'm not sure that I would split them... Finally, if we maintain the split, what is your position on .desktop and appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? >> I have not yet reopened any bugs. The list of -rm bugs is: >> 945042 642014 629105 870395 794042 586087 874907 347279 945042 >> [snip] > > I think the best thing is to reopen the bug and then close them in the > changelog once it is confirmed that they are closed. That way they are > closed with the right version information. The most important thing is > to ensure that bugs that are not fixed in the new version remain open. > I've reopened this list of bugs. > Let me know when the new version is available on mentors. > Will do! I'd just want to take care of the major design decisions first. Cheers, Nicholas signature.asc Description: PGP signature
Bug#977604: smarty3: broken internal parsetree code
Hi Wolfgang, On Di 29 Dez 2020 12:52:01 CET, Wolfgang Schweer wrote: After digging into this a bit (w/o having a real clue about PHP and Smarty), I noticed that it is sufficient to replace one file to make both Gosa and slbackup-php work; see the comment about variables prior to PHP 5.5: [patch] What is the origin of this patch. Are you the author? How did you get to that solution? Wolfgang Thanks for investing time into this! Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp1raoohbQV_.pgp Description: Digitale PGP-Signatur
Bug#928943: cryptsetup-initramfs: Error message during boot: Couldn't find device with uuid
Hi Christof, On Mon, 13 May 2019 at 20:48:41 +0200, Christof Baumann wrote: > In order to get rid of this I changed the script to only attempt > activation of lvm volume groups after all the disks in /etc/crypttab > have been unlocked. Thanks for the patch! > The check for dm-crypt devices needs to stay in the first pass as this > is part of the unlocking procedure but the lvm volume group activation > can be moved to a second step. > Like this the above error messages are gone and I couldn't think > of anything that would now go wrong because of that. It's not regression per se, but our root supports arbitrary block device stacks, and moving the lvm logic to the end adds a bit of complexity while only solving one step on the way. The warning would likely appear with a more complex stack, for instance something involving RAID between dm-crypt and lvm. I think a better fix would be to remove the lvm logic from our boot script altogether and better interact with the one from the lvm2 package (which handles dmcrypt-over-lvm setups). Maybe run the lvm2 script again after cryptroot and loop until a stable state is reached. Unfortunately lvm is chatty and is responsible for the infamous Loading initial ramdisk ... Volume group "$foo-vg" not found Cannot process volume group $foo-vg warning at startup time. It's also the `lvm pvs` call that yields the “Couldn't find device with uuid …” warning. In principle one could skip the call to vchange if the VG is missing or some of its PVs are missing, but `pvs -o vg_missing_pv_count` spits the warning too along with the missing count, and I was not able to silence it (short of throwing away the whole error output which is not really an option). Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
On Tue, Dec 29, 2020 at 06:34:35AM -0500, Sam Hartman wrote: > > "Josh" == Josh Triplett writes: > Josh> I'm happy to contribute towards any of these paths, or another > Josh> path that would avoid expanding the pseudo-Essential set. > > Josh, I found your message fairly frustrating, because you jumped > immediately to the assumption that we want to limit the pseudo-essential > set in this way. That wasn't the intention. I wasn't asking people to actively contribute towards that goal; I was seeking feedback on potential solutions, prior to putting in implementation effort. I was also raising the issue on -devel, because changes in Essential/pseudo-Essential typically get discussed there, and this one hadn't been as far as I could find. I realize that often, in such discussions, people reporting bugs or making feature requests may be expecting others to do the work of implementing such solutions. I was trying to avert that. I started with the baseline assumption that anyone wanting to see the pseudo-Essential set shrink or even remain at the same size would also have to step up and do the work; I wanted to start that discussion and offer to help. I wasn't assuming that everyone agreed with that goal. It certainly didn't cross my mind to think my message made any assumptions that could generate a strong negative reaction. Based on the functionality factored out of libc6 and the transitional handling of those libraries (treating them as successors and adding temporary -dev dependencies but avoiding runtime dependencies so that the libraries would be possible to remove in the future), I thought it would help to catch a case that might otherwise potentially result in a multi-release challenge in trying to remove such packages. Packages in the pseudo-Essential set, while not Essential themselves, can be quite challenging to remove once released; other packages may have implicit assumptions about their presence. So, to restate explicitly: - If we're going to handle this, I think it'll be *much* easier to do so before it hits stable. - I'm willing to help with this. - I'd like to figure out the best approach to handling this. > I'm not involved in PAM these days, so consider this the opinion of an > outside bystander. > > I think it would be most interesting to see about dllopening the NIS > support. > That seems least invasive to sysadmin experience--if you have NIS > installed at the libc6 nsswitch layer, you can also get it at the pam > layer. That seemed like the least invasive option to me, as well. Long-term, I think it may still make sense to make PAM non-Essential, but I think that'd be a substantially larger change, and one that would require more time.
Bug#536750: option to not chmod() on destination at all
Thank you very much for reporting this error. I would like to ask you if this error is still present in the most recent versions of rdiff-backup. Currently after a series of improvements and bug fixes, rdiff-backup is at version 2.0.5 It would be very helpful if you checked again if this bug is still present. Otherwise we can agree to close the bug, -- ⢀⣴⠾⠻⢶⣦⠀ Pablo Mestre Drake ⣾⠁⢠⠒⠀⣿⡁ -- ⢿⡄⠘⠷⠚⠋ https://debian.org ⠈⠳⣄ Debian, the universal operating system.
Bug#537114: base dir token for exclude filelists
Thank you very much for reporting this error. I would like to ask you if this error is still present in the most recent versions of rdiff-backup. Currently after a series of improvements and bug fixes, rdiff-backup is at version 2.0.5 It would be very helpful if you checked again if this bug is still present. Otherwise we can agree to close the bug, -- ⢀⣴⠾⠻⢶⣦⠀ Pablo Mestre Drake ⣾⠁⢠⠒⠀⣿⡁ -- ⢿⡄⠘⠷⠚⠋ https://debian.org ⠈⠳⣄ Debian, the universal operating system.
Bug#978675: libsys-hostname-long-perl: FTBFS, tests fail
Package: libsys-hostname-long-perl Version: 1.5-1 Severity: serious Dear Maintainer, when trying to build libsys-hostname-long-perl in current sid it fails: I: Building the package I: Running cd /build/libsys-hostname-long-perl-1.5/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" HOME="/nonexistent" dpkg-buildpackage -us -uc dpkg-buildpackage: info: source package libsys-hostname-long-perl dpkg-buildpackage: info: source version 1.5-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Axel Beckert dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . fakeroot debian/rules clean dh clean dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_clean dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building libsys-hostname-long-perl using existing ./libsys-hostname-long-perl_1.5.orig.tar.gz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: building libsys-hostname-long-perl in libsys-hostname-long-perl_1.5-1.debian.tar.xz dpkg-source: info: building libsys-hostname-long-perl in libsys-hostname-long-perl_1.5-1.dsc debian/rules build dh build dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_update_autotools_config dh_auto_configure dh_auto_configure: warning: Compatibility levels before 10 are deprecated (level 9 in use) perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -fdebug-prefix-map=/build/libsys-hostname-long-perl-1.5=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/build/libsys-hostname-long-perl-1.5=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for Sys::Hostname::Long Writing MYMETA.yml and MYMETA.json dh_auto_build dh_auto_build: warning: Compatibility levels before 10 are deprecated (level 9 in use) make -j1 make[1]: Entering directory '/build/libsys-hostname-long-perl-1.5' cp testall.pl blib/lib/Sys/Hostname/testall.pl cp lib/Sys/Hostname/Long.pm blib/lib/Sys/Hostname/Long.pm Manifying 1 pod document make[1]: Leaving directory '/build/libsys-hostname-long-perl-1.5' dh_auto_test dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 in use) make -j1 test TEST_VERBOSE=1 make[1]: Entering directory '/build/libsys-hostname-long-perl-1.5' PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/ hostname: Temporary failure in name resolution t/local.t .. 1..1 # Running under perl version 5.032000 for linux # Current time local: Tue Dec 29 23:17:35 2020 # Current time GMT: Tue Dec 29 23:17:35 2020 # Using Test.pm version 1.31 not ok 1 Your hostname = Failed 1/1 subtests Sys::Hostname::Long - Last Dispatch method = ip at /build/libsys-hostname-long-perl-1.5/blib/lib/Sys/Hostname/Long.pm line 206. Use of uninitialized value $hostname in string ne at t/local.t line 10. # Failed test 1 in t/local.t at line 10 # t/local.t line 10 is: ok($hostname ne ""); Use of uninitialized value $hostname in concatenation (.) or string at t/local.t line 12. Test Summary Report --- t/local.t (Wstat: 0 Tests: 1 Failed: 1) Failed test: 1 Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.04 cusr 0.00 csys = 0.07 CPU) Result: FAIL make[1]: Leaving directory '/build/libsys-hostname-long-perl-1.5' Failed 1/1 test programs. 1/1 subtests failed. make[1]: *** [Makefile:830: test_dynamic] Error 255 dh_auto_test: error: make -j1 test TEST_VERBOSE=1 returned exit code 2 make: *** [debian/rules:4: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 I: copying local configuration E: Failed autobuilding of package I: unmounting dev/ptmx filesystem I: unmounting dev/pts filesystem I: unmounting dev/shm filesystem I: unmounting proc filesystem I: unmounting sys filesystem I: cleaning the build env I: removing directory /srv/workspace/pbuilder/7694 and its subdirectories -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ If secure encryption is outlawed, only criminals will have it. signature.asc Description: PGP signature
Bug#563722: rdiff-backup: --exclude-other-filesystems wrongly excludes even mountpoint
Thank you very much for reporting this error. I would like to ask you if this error is still present in the most recent versions of rdiff-backup. Currently after a series of improvements and bug fixes, rdiff-backup is at version 2.0.5 It would be very helpful if you checked again if this bug is still present. Otherwise we can agree to close the bug, -- ⢀⣴⠾⠻⢶⣦⠀ Pablo Mestre Drake ⣾⠁⢠⠒⠀⣿⡁ -- ⢿⡄⠘⠷⠚⠋ https://debian.org ⠈⠳⣄ Debian, the universal operating system.
Bug#618964: rdiff-backup is not friendly at all when called with --help
Thank you very much for reporting this error. I would like to ask you if this error is still present in the most recent versions of rdiff-backup. Currently after a series of improvements and bug fixes, rdiff-backup is at version 2.0.5 It would be very helpful if you checked again if this bug is still present. Otherwise we can agree to close the bug, -- ⢀⣴⠾⠻⢶⣦⠀ Pablo Mestre Drake ⣾⠁⢠⠒⠀⣿⡁ -- ⢿⡄⠘⠷⠚⠋ https://debian.org ⠈⠳⣄ Debian, the universal operating system.
Bug#978601: [PATCH] libpam-runtime.postrm: Remove session-noninteractive files on purge
Control: tags -1 + patch Patch attached. >From cf44256bc32e6b9a8f6658e5f340ab8a14ee2068 Mon Sep 17 00:00:00 2001 Message-Id: From: Josh Triplett Date: Tue, 29 Dec 2020 15:24:09 -0800 Subject: [PATCH] libpam-runtime.postrm: Remove session-noninteractive files on purge --- debian/libpam-runtime.postrm | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/debian/libpam-runtime.postrm b/debian/libpam-runtime.postrm index 9a11040d..b17b1ad8 100644 --- a/debian/libpam-runtime.postrm +++ b/debian/libpam-runtime.postrm @@ -2,9 +2,11 @@ if [ "$1" = "purge" ]; then rm -f /etc/pam.d/common-auth /etc/pam.d/common-account \ - /etc/pam.d/common-session /etc/pam.d/common-password + /etc/pam.d/common-session /etc/pam.d/common-password \ + /etc/pam.d/common-session-noninteractive rm -f /var/lib/pam/auth /var/lib/pam/account /var/lib/pam/session \ - /var/lib/pam/password /var/lib/pam/seen + /var/lib/pam/password /var/lib/pam/seen \ + /var/lib/pam/session-noninteractive rmdir --ignore-fail-on-non-empty /var/lib/pam fi -- 2.30.0
Bug#978674: python3-build: Fails to work unless pip is installed
Package: python3-build
Version: 0.1.0-2
Severity: normal
As I was trying out the new PEP-517 build system, I installed python3-build and
tried to run it, only to get this stacktrace:
/tmp/build-env-axtchyw0/bin/python: No module named ensurepip
/tmp/build-env-axtchyw0/bin/python: No module named pip
Traceback (most recent call last):
File "/usr/bin/pyproject-build", line 33, in
sys.exit(load_entry_point('build==0.1.0', 'console_scripts',
'pyproject-build')())
File "/usr/lib/python3/dist-packages/build/__main__.py", line 206, in
entrypoint
main(sys.argv[1:])
File "/usr/lib/python3/dist-packages/build/__main__.py", line 202, in main
build_package(args.srcdir, outdir, distributions, config_settings, not
args.no_isolation, args.skip_dependencies)
File "/usr/lib/python3/dist-packages/build/__main__.py", line 81, in
build_package
_build_in_isolated_env(builder, outdir, distributions)
File "/usr/lib/python3/dist-packages/build/__main__.py", line 45, in
_build_in_isolated_env
with IsolatedEnvBuilder() as env:
File "/usr/lib/python3/dist-packages/build/env.py", line 55, in __enter__
executable, pip_executable = _create_isolated_env(self._path)
File "/usr/lib/python3/dist-packages/build/env.py", line 187, in
_create_isolated_env
subprocess.check_call([executable, '-Im', 'pip', 'uninstall', 'setuptools',
'-y'])
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/tmp/build-env-axtchyw0/bin/python',
'-Im', 'pip', 'uninstall', 'setuptools', '-y']' returned non-zero exit status 1.
I don't know why build requires pip (I don't think it should?), but in any case
it seems it should be added as a dependency.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-build depends on:
ii python33.9.0-4
ii python3-packaging 20.4-1
ii python3-pep517 0.9.1-1
ii python3-toml 0.10.1-1
python3-build recommends no packages.
Versions of packages python3-build suggests:
pn python-build-doc
-- no debconf information
Bug#890833: at-spi2-core: Intermittent 90s shutdown delay: at-spi-dbus-bus.service: State 'stop-sigterm' timed out
Control: found -1 2.38.0-2 Hey, I have a sid system with at-spi2-core 2.38.0-2 running KDE Plasma Desktop. I still can see the problem. One thing I see is that this is only a problem if I start chromium. If I do not use chromium, the log is quite uninteresting. hefee Start chromium: 13:03:58 xxx systemd[5372]: Starting Accessibility services bus... 13:03:58 xxx systemd[5372]: Started Accessibility services bus. 15:16:09 xxx at-spi-bus-launcher[36537]: dbus-daemon[36537]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=36459 comm="/usr/lib/chromium/chromium --sho> 15:16:09 xxx at-spi-bus-launcher[36537]: dbus-daemon[36537]: Successfully activated service 'org.a11y.atspi.Registry' 15:16:09 xxx at-spi-bus-launcher[36552]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry 22:13:48 xxx at-spi-bus-launcher[36552]: X connection to :0 broken (explicit kill or server shutdown). 22:13:51 xxx systemd[5372]: Stopping Accessibility services bus... 22:15:21 xxx systemd[5372]: at-spi-dbus-bus.service: State 'stop-sigterm' timed out. Killing. 22:15:21 xxx systemd[5372]: at-spi-dbus-bus.service: Killing process 5689 (at-spi-bus-laun) with signal SIGKILL. 22:15:21 xxx systemd[5372]: at-spi-dbus-bus.service: Killing process 5696 (gdbus) with signal SIGKILL. 22:15:21 xxx systemd[5372]: at-spi-dbus-bus.service: Main process exited, code=killed, status=9/KILL 22:15:21 xxx systemd[5372]: at-spi-dbus-bus.service: Failed with result 'timeout'. 22:15:21 xxx systemd[5372]: Stopped Accessibility services bus. 22:15:21 xxx systemd[5372]: at-spi-dbus-bus.service: Consumed 4.294s CPU time. Without chromium: 22:25:26 xxx systemd[5284]: Starting Accessibility services bus... 22:25:27 xxx systemd[5284]: Started Accessibility services bus. 22:27:36 xxx systemd[5284]: Stopping Accessibility services bus... 22:27:36 xxx systemd[5284]: at-spi-dbus-bus.service: Succeeded. 22:27:36 xxx systemd[5284]: Stopped Accessibility services bus. signature.asc Description: This is a digitally signed message part.
Bug#978607: Please drop empty /etc/udev/udev.conf
On Tue, Dec 29, 2020 at 12:51:47PM +0100, Michael Biebl wrote: > Am 29.12.20 um 08:29 schrieb Josh Triplett: > > The systemd family of packages has generally tried to minimize the > > number of files in /etc, in favor of files in /usr. > > > > /etc/udev/udev.conf contains nothing but comments. Please consider > > dropping it (when unmodified). > > This is true for all config files shipped by both udev and systemd (i.e. all > files matching /etc/systemd/*.conf). All of them only contain comments (i.e. > commented out default values). > It feels a bit odd, to special-case udev here. That's entirely fair. I reported it on udev because I was working with udev at the time. > I have to add, that those files are provided by upstream. > I would feel more easy if this was discussed upstream. I don't really want > to deviate downstream here. Of course. It looks like those files are installed upstream by the install-sysconfdir option, which also controls the installation of empty .d directories and similar, and I think we want to keep the latter. I've filed https://github.com/systemd/systemd/issues/18112 about the possibility of splitting that option.
Bug#975696: [Pkg-sugar-devel] Bug#975696: link-grammar: multi-thread test fails
Control: severity -1 important Quoting Graham Inggs (2020-12-29 20:35:03) > The build of link-grammar/5.8.0-3 has already failed on ppc64el [1] > (details below). > > As fun as it is, please let's avoid the BTS sports and leave this bug > open until link-grammar builds and passes its autopkgtests reliably. I closed the bugreport when in -3 I optimistally expected the test failures to be gone. I agree this bug should stay open when that's not the case. I disagree, however, that the current level of flakiness renders the package unsuitable for a stable Debian release. Please do clarify if you think that my reasoning is wrong. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#978673: RFS: paho.mqtt.cpp/1.2.0-1 [ITP] -- Eclipse Paho MQTT C++ Client Library - development files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "paho.mqtt.cpp": * Package name: paho.mqtt.cpp Version : 1.2.0-1 Upstream Author : Eclipse Paho Development Team * URL : https://github.com/eclipse/paho.mqtt.cpp/ * License : EPL-2.0 * Vcs : https://salsa.debian.org/matthiasklein/paho.mqtt.cpp Section : libs It builds those binary packages: libpaho-mqttpp-dev - Eclipse Paho MQTT C++ Client Library - development files libpaho-mqttpp3-1 - Eclipse Paho MQTT C++ Client Library - shared libraries To access further information about this package, please visit the following URL: https://mentors.debian.net/package/paho.mqtt.cpp/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/paho.mqtt.cpp/paho.mqtt.cpp_1.2.0-1.dsc Changes for the initial release: paho.mqtt.cpp (1.2.0-1) UNRELEASED; urgency=low . * Initial release. Closes: #977740 This package depends on the package libpaho-mqtt1.3 in version 1.3.8, but in unstable is so far only version 1.3.5. I have created a bug for the package, but have no feedback on it yet. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978434 I have therefore worked with a local build: https://salsa.debian.org/matthiasklein/paho.mqtt.c Regards, -- Matthias Klein
Bug#978662: apertium-cy-en: autopkgtest failure
This is a chicken-and-egg problem that should solve itself. New apertium 3.7.1 can't migrate until apertium-cy-en is fixed, but fixed apertium-cy-en won't build correctly with existing apertium 3.6.1. -- Tino Didriksen
Bug#968011: Dedicated non-public executable to get latest policy version from Lintian data
Control: clone -1 -2 Control: retitle -2 Stop shipping private/latest-policy-version Control: unblock -1 by 968000 968154 > the interface is scheduled to change again in the near future. Lintian will soon stop shipping its modules in the Perl system path. For the benefit of libconfig-model-dpkg-perl (and only for the benefit of that package), Lintian will instead provide a dedicated program to obtain the latest policy version from Lintian data. The location of the non-public executable is /usr/share/lintian/private/latest-policy-version Kind regards, Felix Lechner
Bug#977845: dgit: unhelpful behavior in case previous upload contained new upstream release
Sean Whitton writes ("Bug#977845: dgit: unhelpful behavior in case previous
upload contained new upstream release"):
> It can't distinguish between stuck in some dak queue vs. actually
> rejected, though?
dgit doesn't currently distinguish that. Mostly because I thought the
information is not available.
> I must be missing something here, because I don't see why the rejected
> orig.tar is needed. apt-get source will get you the orig.tar for the
> version actually in the archive, which is what you want to base your
> work off?
Well, that depends. dgit (currently) takes the view that in this
situation you should start from the version in git rather than the
version in the archive.
This is in large part because if you do "dgit clone" in the period
between "dgit push" and archive publication, you probably didn't want
to revert what the last uploader did.
I hesitate to put it like this, but: it is difficult to represent the
Debian archive in something moderately sensible like the git data
model, because the Debian archive is slow[1], opaque[2],
capricious[3], and racy[4].
Ideally the situation I would like is that if someone does dgit push,
and has the package REJECTed for some reason, their co-maintainer
should be able to fix it without having to do more than "dgit fetch",
hack hack hack, "dgit push". For this the co-maintainer needs the new
orig, not the one in the archive.
If a dgit-clone-using NMUer wants to upload from the last ACCEPTed,
either the git history has to diverge (and then what?), or the NMUer
has to make a pseudomerge which effectively reverts the
new-source-package upload.
This is all quite a mess. I think it's a worse mess to try to go
backwards, than to treat the uploaded-but-REJECTed version as the
baseline.
Ian.
[1] Several hours from upload to visibility in ftpmaster data API, in
the best case. Significant fractions of a year in the worst.
[2] As I understand it, you can't tell what's queued and whether
things are held back, or rejected, or what.
[3] Software can only do a very poor job of predicting whether a
particular package will go via the fast path, or the slow path of
NEW, or the very slow path of sitting in NEW for months while
people procrastinate and/or argue.
[4] Proper use of the Debian archive data model requires external
synchronisation on a per-source-package basis, to avoid lost
updates. This is because the update operation does not guarantee
that of multiple concurrent updates, at most one will return
"success" for the synchronous result of the upload attempt. In
dgit's data model, this synchronisation is provided by the
dgit-repos git server. In the trad Debian data model this is
provided by unstructured and manual human coordination.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#978588: firefox: should depend on either libgdk-pixbuf package
reassign 978588 libgdk-pixbuf2.0-dev thanks On Tue, Dec 29, 2020 at 10:22:49AM +1100, David Tulloh wrote: > Package: firefox > Version: 84.0-3 > Severity: important > > The libgdk-pixbuf packages are migrating from > libgdk-pixbuf2.0-0 to libgdk-pixbuf-2.0.0 > > The most recent firefox package has matched this name transition. > > However many other packages have not yet made the transition, causing > clashes which require their removal. Popular packages include > mutter and gimp. This significantly impacts the overall usability of the > system. > > The dependency should be: libgdk-pixbuf-2.0-0 | libgdk-pixbuf2.0-0 > > This is the practice recommended by libgdk-pixbuf > > Firefox only requires 2.22.0 which either package can meet. I think that rather than having reverse dependencies handle this all one by one, this should be handled by libgdk-pixbuf itself, via its symbols file, leaving it to dh_shlibdeps to add the desired deps. Mike
Bug#978671: apt http transport gets stuck after package download
On Tue, Dec 29, 2020 at 1:27 PM Ivan Babrou wrote: > > Package: apt > Version: 1.8.2.1 > Severity: normal > Tags: patch > > Dear Maintainer, > > On Debian Buster we're seeing 30s timeouts when downloading > a particular set of debian packages from an internal repo: > > ``` > $ time apt-get download -y rubygem-stud rubygem-mustache rubygem-insist > rubygem-pleaserun rubygem-fpm > ... > Fetched 451 kB in 30s (15.0 kB/s) > > real0m31.022s > user0m0.923s > sys 0m0.080s > ``` > > The issue is fixed in the following commit in apt 2.1.9: > > ``` > commit 08f05aa8beb58fa32485e2087eb21a9f3cb267bb > Author: Julian Andres Klode > Date: Mon Jun 29 14:03:21 2020 +0200 > > http: Redesign reading of pending data > > Instead of reading the data early, disable the timeout for the > select() call and read the data later. Also, change Read() to > call only once to drain the buffer in such instances. > > We could optimize this to call read() multiple times if there > is also pending stuff on the socket, but that it slightly more > complex and should not provide any benefits. > ``` > > Please consider backporting this into Debian Buster, > as it fixes the problem and the patch itself applies cleanly. > > -- System Information: > Debian Release: 10.6 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.70 > Kernel taint flags: TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: unable to detect > > Versions of packages apt depends on: > ii adduser 3.118 > ii debian-archive-keyring 2019.1 > ii gpgv2.2.12-1+deb10u1 > ii libapt-pkg5.0 1.8.2.1 > ii libc6 2.28-10 > ii libgcc1 1:8.3.0-6 > ii libgnutls30 3.6.7-4+deb10u5 > ii libseccomp2 2.5.1-1 > ii libstdc++6 8.3.0-6 > > Versions of packages apt recommends: > ii ca-certificates 20200601~deb10u1 > > Versions of packages apt suggests: > pn apt-doc > pn aptitude | synaptic | wajig > ii dpkg-dev 1.19.7 > ii gnupg2.2.12-1+deb10u1 > ii gnupg2 2.2.12-1+deb10u1 > pn powermgmt-base > > -- no debconf information CC'd Julian, who is the author of the patch.
Bug#978671: apt http transport gets stuck after package download
Package: apt Version: 1.8.2.1 Severity: normal Tags: patch Dear Maintainer, On Debian Buster we're seeing 30s timeouts when downloading a particular set of debian packages from an internal repo: ``` $ time apt-get download -y rubygem-stud rubygem-mustache rubygem-insist rubygem-pleaserun rubygem-fpm ... Fetched 451 kB in 30s (15.0 kB/s) real0m31.022s user0m0.923s sys 0m0.080s ``` The issue is fixed in the following commit in apt 2.1.9: ``` commit 08f05aa8beb58fa32485e2087eb21a9f3cb267bb Author: Julian Andres Klode Date: Mon Jun 29 14:03:21 2020 +0200 http: Redesign reading of pending data Instead of reading the data early, disable the timeout for the select() call and read the data later. Also, change Read() to call only once to drain the buffer in such instances. We could optimize this to call read() multiple times if there is also pending stuff on the socket, but that it slightly more complex and should not provide any benefits. ``` Please consider backporting this into Debian Buster, as it fixes the problem and the patch itself applies cleanly. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.70 Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.12-1+deb10u1 ii libapt-pkg5.0 1.8.2.1 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4+deb10u5 ii libseccomp2 2.5.1-1 ii libstdc++6 8.3.0-6 Versions of packages apt recommends: ii ca-certificates 20200601~deb10u1 Versions of packages apt suggests: pn apt-doc pn aptitude | synaptic | wajig ii dpkg-dev 1.19.7 ii gnupg2.2.12-1+deb10u1 ii gnupg2 2.2.12-1+deb10u1 pn powermgmt-base -- no debconf information
Bug#978557: lutris: Add German translation
Hi Sven, > there is a German translation patch available in my own Github repostitory Cool, thanks for your contribution! I gave it a quick review, loogs good to me. Can you open a PR upstream? I want to avoid downstream patches. > To use the newer development version build of lutris I had to install the > package python3-lxml Thanks for catching that! Opened a PR upstream: https://github.com/lutris/lutris/pull/3355 Grüße, Stephan
Bug#978669: ITP: bazel-skylib -- Skylib
Package: wnpp Severity: wishlist Owner: Olek Wojnar * Package name: bazel-skylib Version : 1.0.3 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/bazel-skylib * License : Apache-2 Programming Lang: Starlark Description : Skylib Library of Starlark functions for manipulating collections, file paths, and various other data types in the domain of Bazel build rules. . Each of the .bzl files in the lib directory defines a "module" — a struct that contains a set of related functions and/or other symbols that can be loaded as a single unit, for convenience. . Skylib also provides build rules under the rules directory.
Bug#978670: xserver-xorg-video-ati: FTBFS on mips64el, mipsel
package: src:xserver-xorg-video-ati version: 1:19.1.0-2 severity: serious tags: ftbfs Hi, The latest upload of xserver-xorg-video-ati to unstable fails on mips64el, mipsel: https://buildd.debian.org/status/package.php?p=xserver-xorg-video-ati Cheers, Ivo
Bug#978631: ufw does not work at all!
On Tue, 29 Dec 2020, Energo Koder wrote: > Package: ufw > Version: 0.36-1 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > I run these commands on ufw protected Debian 10: > > $ sudo ufw status > [sudo] hasło użytkownika energokoder: > Status: active > > To Action From > -- -- > Samba ALLOW 192.168.0.0/16 > 80/tcp ALLOW 192.168.0.0/16 > 443/tcpALLOW 192.168.0.0/16 > 22/tcp ALLOW 192.168.0.0/16 > Anywhere on enp0s25LIMIT Anywhere > Anywhere on wlx08beac034eef LIMIT Anywhere I suspect it is these two lines that are allowing the traffic. It is saying to allow (with rate limiting) anything coming in on the enp0s25 and wlx08beac034eef interfaces. Is 192.168.1.40 associated with either of these interfaces? -- Email: ja...@strandboge.com IRC: jdstrand
Bug#978040: [Pkg-pascal-devel] Bug#978040: Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Matija,
On Tue, 2020-12-29 at 18:50 +0100, Matija Nalis wrote:
> As for hard coding, those paths are ALREADY hard-coded at least forIntel
> architectures (amd64, i386), for example:
...
> That hard-coded paths seem to already be auto-generated on build somehow.
The file names /etc/fpc-${version}.cfg is generated automatically by postinst
script using fpcmkcfg tool that is shipped with the compiler.
So it is somewhat not hard coded, even if with time it will become wrong (for
example after a distupgrade)
> Note that current values also seem wrong if one is using multiarch /cross-
> compiling; as a path for "ifdef cpui386" should probably bedifferent than than
> the one for "ifdef cpux86_64".
Yes this is true, and is probably fixable by hacking in fpcmkcfg tool.
The fix should use variables recognized by the compiler (like $fpctarget) in
order to support correctly multi-arch.
I'll have a deeper look on that as it looks quite serious.
-- Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#978668: ITP: bazel-stardoc -- Starlark Documentation Generator
Package: wnpp Severity: wishlist Owner: Olek Wojnar * Package name: bazel-stardoc Version : 0.4.0 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/stardoc * License : Apache-2 Programming Lang: Starlark Description : Starlark Documentation Generator Documentation generator for Bazel build rules written in Starlark. Stardoc provides a Starlark rule that can be used to build documentation for Starlark rules in Markdown. Stardoc generates one documentation page per .bzl file. * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#971018: libgnatcoll-db: FTBFS on mips(64)el with assembler message: branch out of range
tags 971018 +patch thanks I did some testing on the porterbox, which showed optimizing for size is enough to make things build on mipsel. Debdiff attached, no intent to NMU. diff -Nru libgnatcoll-db-21.0.0/debian/changelog libgnatcoll-db-21.0.0/debian/changelog --- libgnatcoll-db-21.0.0/debian/changelog 2020-12-22 22:35:21.0 + +++ libgnatcoll-db-21.0.0/debian/changelog 2020-12-29 13:27:55.0 + @@ -1,3 +1,10 @@ +libgnatcoll-db (21.0.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use -Os on mipsel, to work around jump length error (Closes: 971018). + + -- Peter Michael Green Tue, 29 Dec 2020 13:27:55 + + libgnatcoll-db (21.0.0-5) unstable; urgency=medium [ Adrian Bunk ] diff -Nru libgnatcoll-db-21.0.0/debian/rules libgnatcoll-db-21.0.0/debian/rules --- libgnatcoll-db-21.0.0/debian/rules 2020-11-17 18:33:55.0 + +++ libgnatcoll-db-21.0.0/debian/rules 2020-12-29 13:27:55.0 + @@ -34,6 +34,11 @@ DEB_CFLAGS_MAINT_APPEND := -mxgot endif +# Use -Os on mipsel to workaround further jump length issues +ifneq (,$(filter mipsel,$(DEB_HOST_ARCH))) + DEB_CFLAGS_MAINT_APPEND += -Os +endif + include /usr/share/dpkg/buildflags.mk include $(wildcard /usr/share/ada/debian_packaging-$(GNAT_VERSION).mk) # wildcard means: not during -indep builds.
Bug#978667: libv4l-dev: ioctl(rfd, VIDIOC_QBUF, ) fails
Package: libv4l-dev Version: 1.16.3-3 Severity: serious Justification: Policy 2.5 - important - Unix is a multi-port operating system Dear Maintainer, * What led up to the situation? Attempted to open access to a second device (camera) * What exactly did you do (or not do) that was effective (or ineffective)? wrote the attached program which minimally opens the stream from the second camera * What was the outcome of this action? The program reportes that although the first camera was accessible, identical code opening a stream for a second camera was not successful * What outcome did you expect instead? Expected ioctl to return r==0, indicating successful system call -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libv4l-dev depends on: ii libv4l-01.16.3-3 ii libv4l2rds0 1.16.3-3 ii libv4lconvert0 1.16.3-3 libv4l-dev recommends no packages. Versions of packages libv4l-dev suggests: ii pkg-config 0.29-6 -- no debconf information
Bug#978666: RFP: bazel-rules-proto -- Protobuf Rules for Bazel
Package: wnpp Severity: wishlist * Package name: bazel-rules-proto Version : Pending Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/rules_proto * License : Apache-2 Programming Lang: Starlark Description : Protobuf Rules for Bazel Starlark implementation of Protobuf rules in Bazel. * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#977845: dgit: unhelpful behavior in case previous upload contained new upstream release
Hello,
On Mon 28 Dec 2020 at 12:08PM GMT, Ian Jackson wrote:
> Sean Whitton writes ("Bug#977845: dgit: unhelpful behavior in case previous
> upload contained new upstream release"):
>> On Mon 21 Dec 2020 at 09:01PM +01, Paul Gevers wrote:
>> > In the end I resorted to
>> > paul@mulciber ~/packages/bugs $ dgit clone f2fs-tools testing
>> > as unstable and testing have the same version, but that doesn't work if
>> > unstable and testing don't have the same version.
>>
>> In this situation what it seems we want to achieve is
>>
>> a) get the version you want to hack on into dgit as if `dgit clone` had
>>given it you
>>
>> b) make it easy to `dgit push` your new version, which is based on the
>>result of (a).
>
> The problem is that in this situation the person who uses dgit clone
> does not get the orig tarball and has no systematic way to find it.
>
>> However, detecting whether an upload made it to the archive would
>> require incorporating a lot of idiosyncratic knowledge about dak into
>> dgit, I think, with a fair bit of guessing? Or is the way that dak
>> keeps track of such things amenable to adding a new ftp-master API query
>> to find out?
>
> dgit clone already knows this situation has arisen, because it can see
> that the version in git is newer than the version in the archive.
It can't distinguish between stuck in some dak queue vs. actually
rejected, though?
>> In the meantime what I would have done is `apt-get source` followed by
>> `dgit import-dsc` followed by pseudomerging in the result of `dgit fetch
>> unstable`. What do you think about the error message suggesting that
>> for this sort of situation?
>
> That wouldn't work either, because apt-get source doesn't have access
> to the orig tarball.
>
> The original uploader had the orig tarball. dgit push sent it to the
> archive. But I think if the upload was REJECTed (or dcut or
> something), the archive doesn't have it any more. I don't think
> ftpmaster keep uploaded things that don't end up in the archive.
> (Please correct me if I'm wrong.)
>
> I think the solution has to involve dgit push messing about with
> pristine-tar to send a pristine-tar branch to dgit-repos :-/.
I must be missing something here, because I don't see why the rejected
orig.tar is needed. apt-get source will get you the orig.tar for the
version actually in the archive, which is what you want to base your
work off?
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#978540: RFS: ancient/1.0-1 [ITP] -- decompression routines for ancient formats
On Mon, Dec 28, 2020 at 01:56:23PM +0100, Gürkan Myczko wrote: > * Package name: ancient >Version : 1.0-1 > * URL : https://github.com/temisu/ancient > ancient (1.0-1) unstable; urgency=medium > . >* Initial release. (Closes: #978090) The copyright file lacks at least bzip2 license for src/BZIP2Table.hpp For a command-line program, I'd say a man page is a must. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#978665: ITP: bazel-rules-pkg -- Bazel package building & fetching rules
Package: wnpp Severity: wishlist Owner: Olek Wojnar * Package name: bazel-rules-pkg Version : 0.3.0 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/rules_pkg * License : Apache-2 Programming Lang: Starlark Description : Bazel package building & fetching rules Bazel rules for packaging and fetching (for Debian and other distribution channels). * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#978663: facter: please package facter 4.x
Package: src:facter Severity: wishlist Dear maintainer, While puppet 6 still supports facter 3.x, I think it wouldn't be a bad idea to package facter 4.x in the archive. It seems the current version of puppet in Debian (puppet 5) requires the 3.x version though [1], so we can't just push 4.x to sid. Considering facter 4.x is a re-write in ruby, I think the best option would be to create a "facter4" package and keep facter in Debian as "facter3". [1]: https://github.com/puppetlabs/puppet/blob/5.5.22/.gemspec#L33 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#978664: RFP: bazel-rules-java -- Java Rules for Bazel
Package: wnpp Severity: wishlist * Package name: bazel-rules-java Version : 0.1.1 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/rules_java * License : Apache-2 Programming Lang: Starlark Description : Java Rules for Bazel * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#978662: apertium-cy-en: autopkgtest failure
Source: apertium-cy-en Version: 0.1.1~r57554-5 Severity: serious apertium-cy-en's autopkgtest in testing currently fails with apertium from unstable: autopkgtest [08:11:43]: test runsampletest: [--- Everyone are born free. is not equal to Everyone are born free! autopkgtest [08:11:44]: test runsampletest: ---] autopkgtest [08:11:44]: test runsampletest: - - - - - - - - - - results - - - - - - - - - - runsampletestFAIL non-zero exit status 1 autopkgtest [08:11:44]: summary runsampletestFAIL non-zero exit status 1 See https://ci.debian.net/data/autopkgtest/testing/amd64/a/apertium-cy-en/9220240/log.gz And apertium-cy-en's autopkgtest in unstable also fails with apertium from testing: autopkgtest [20:25:40]: test runsampletest: [--- Segmentation fault is not equal to Everyone are born free! autopkgtest [20:25:41]: test runsampletest: ---] autopkgtest [20:25:41]: test runsampletest: - - - - - - - - - - results - - - - - - - - - - runsampletestFAIL non-zero exit status 1 See https://ci.debian.net/data/autopkgtest/testing/amd64/a/apertium-cy-en/9208858/log.gz Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#978661: sympa: Security update 6.2.40~dfsg-1+deb10u1 fails to install - related to bash(?)
Package: sympa
Version: 6.2.40~dfsg-1+deb10u1
Severity: important
Dear Maintainer,
The latest Sympa security update fails to install normally on my Debian Buster,
but works normally, if restarted manually after the package install failure.
Error logs seem to be:
-sh: 11: /etc/bash.bashrc: shopt: not found
-sh: 35: /etc/bash.bashrc: shopt: not found
-sh: 26: /usr/share/bash-completion/bash_completion: Syntax error: "("
unexpected
===
# dpkg -s sympa
Package: sympa
Status: install ok half-configured
Priority: optional
Section: mail
Installed-Size: 15323
Maintainer: Debian Sympa team
Architecture: i386
Version: 6.2.40~dfsg-1+deb10u1
Config-Version: 6.2.40~dfsg-1
# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up sympa (6.2.40~dfsg-1+deb10u1) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/sympa.conf
dbconfig-common: flushing administrative password
Ensuring that permissions and ownerships are right (this can take a while)...
apache2_invoke sympa.conf: already enabled
apache2_invoke sympa-soap.conf: already enabled
Moving configuration files for Sympa >= 6.2 (if required)
-sh: 11: /etc/bash.bashrc: shopt: not found
-sh: 35: /etc/bash.bashrc: shopt: not found
-sh: 26: /usr/share/bash-completion/bash_completion: Syntax error: "("
unexpected
dpkg: error processing package sympa (--configure):
installed sympa package post-installation script subprocess returned error
exit status 2
Errors were encountered while processing:
sympa
E: Sub-process /usr/bin/dpkg returned an error code (1)
# service sympa status
● sympa.service - SYMPA mailing list manager
Loaded: loaded (/lib/systemd/system/sympa.service; enabled; vendor preset:
enabled)
Active: inactive (dead) since Tue 2020-12-29 22:20:13 EET; 28s ago
Docs: man:sympa_msg(8)
Main PID: 4977 (code=exited, status=0/SUCCESS)
Dec 29 21:39:46 kallio systemd[1]: Starting SYMPA mailing list manager...
Dec 29 21:39:48 kallio sympa_msg[4960]: info main::_load() Configuration file
read, default log level 0
Dec 29 21:39:48 kallio sympa_msg[4960]: notice Sympa::Process::daemonize()
Starting sympa/msg daemon, PID 4977
Dec 29 21:39:48 kallio sympa_msg[4977]: notice main:: Sympa/msg 6.2.40 Started
Dec 29 21:39:48 kallio systemd[1]: Started SYMPA mailing list manager.
Dec 29 22:20:13 kallio systemd[1]: Stopping SYMPA mailing list manager...
Dec 29 22:20:13 kallio sympa_msg[4977]: notice main::sigterm() Signal TERM
received, still processing current task
Dec 29 22:20:13 kallio sympa_msg[4977]: notice main:: Sympa/msg exited normally
due to signal
Dec 29 22:20:13 kallio systemd[1]: sympa.service: Succeeded.
Dec 29 22:20:13 kallio systemd[1]: Stopped SYMPA mailing list manager.
# service sympa restart
# service sympa status
● sympa.service - SYMPA mailing list manager
Loaded: loaded (/lib/systemd/system/sympa.service; enabled; vendor preset:
enabled)
Active: active (running) since Tue 2020-12-29 22:21:36 EET; 15s ago
Docs: man:sympa_msg(8)
Process: 23068 ExecStartPre=/bin/mkdir -p /run/sympa (code=exited,
status=0/SUCCESS)
Process: 23072 ExecStartPre=/bin/chown sympa:sympa /run/sympa (code=exited,
status=0/SUCCESS)
Process: 23076 ExecStart=/usr/lib/sympa/bin/sympa_msg.pl (code=exited,
status=0/SUCCESS)
Main PID: 23095 (sympa_msg.pl)
Tasks: 1 (limit: 4915)
Memory: 49.1M
CGroup: /system.slice/sympa.service
└─23095 /usr/bin/perl /usr/lib/sympa/bin/sympa_msg.pl
Dec 29 22:21:35 kallio systemd[1]: Starting SYMPA mailing list manager...
Dec 29 22:21:36 kallio sympa_msg[23076]: info main::_load() Configuration file
read, default log level 0
Dec 29 22:21:36 kallio sympa_msg[23076]: notice Sympa::Process::daemonize()
Starting sympa/msg daemon, PID 23095
Dec 29 22:21:36 kallio sympa_msg[23095]: notice main:: Sympa/msg 6.2.40 Started
Dec 29 22:21:36 kallio systemd[1]: Started SYMPA mailing list manager.
=
Regards,
Harri
-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.utf8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8),
LANGUAGE=en_DK.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sympa depends on:
ii adduser3.118
ii ca-certificates20200601~deb10u1
ii dbconfig-common
Bug#978660: RFP: bazel-rules-cc -- C++ rules for Bazel
Package: wnpp Severity: wishlist * Package name: bazel-rules-cc Version : pending Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/rules_cc * License : Apache-2 Programming Lang: Starlark Description : C++ rules for Bazel Starlark implementation of C++ rules in Bazel. * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#977604: smarty3: broken internal parsetree code
[ Mike Gabriel, 2020-12-29 ] > What is the origin of this patch. Are you the author? How did you get to > that solution? Maybe I should have been more verbose. It isn't a solution and not a patch. These are the changes done to smarty_internal_templatecompilerbase.php since the last release, please take a look at the timestamps: diff -u a/smarty_internal_templatecompilerbase.php b/smarty_internal_templatecompilerbase.php --- a/smarty_internal_templatecompilerbase.php 2018-08-31 00:00:00.0 +0200 +++ b/smarty_internal_templatecompilerbase.php 2020-04-14 00:00:00.0 +0200 According to the file's upstream history, the diff is due to the last two commits concerning smarty_internal_templatecompilerbase.php ( which is now causing the GOsa and slbackup-php issues). Maybe these fixes (for other issues) broke code shipped with GOsa and slbackup-php, maybe both the GOsa and slbackup-php code is outdated. I just wanted to point to something to investigate further... No idea how to fix it. Wolfgang signature.asc Description: PGP signature
Bug#936071: fixed in pam 1.4.0-1
On Mon, Dec 28, 2020 at 06:36:06AM +, Debian Bug Tracking System wrote: > pam (1.4.0-1) unstable; urgency=medium > . >* New upstream release. Closes: #948188. [...] >* Drop patches to implement "nullok_secure" option for pam_unix. > Closes: #674857, #936071, LP: #1860826. [...] >* debian/patches-applied/nullok_secure-compat.patch: Support > nullok_secure as a deprecated alias for nullok. >* debian/pam-configs/unix: use nullok, not nullok_secure. Thank you for the fix! I really appreciate it. And thank you for thinking about backwards compatibility of existing configurations, as well. - Josh Triplett
Bug#978659: vtk9: FTBFS on hurd-i386 and non-java ports
Package: vtk9
Version: 9.0.1+dfsg1-5
Severity: important
Tags: patch
Hello,
Just like for vtk7, vtk9 needs fixes on hurd-i386 (for applism), and on
non-java ports, please see the attached patches.
Samuel
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500,
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500,
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'),
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages vtk9 depends on:
ii libc6 2.31-6
ii libgcc-s1 11-20201216-2
ii libstdc++6 11-20201216-2
pn libvtk9
vtk9 recommends no packages.
Versions of packages vtk9 suggests:
pn vtk9-doc
pn vtk9-examples
--
Samuel
bouhouhouh, b il m'a abandonné. Tout ca parce que je regardais plus mon
emacs que lui !
s/lui/ses messages irc/
-+- #ens-mim esseulé -+-
https://gitlab.kitware.com/diatomic/diy/-/merge_requests/59
>From bb0d55c8ae34a43354b1002262dad722c410d8cb Mon Sep 17 00:00:00 2001
From: Samuel Thibault
Date: Sat, 13 Jun 2020 13:59:31 +0200
Subject: [PATCH] Fix build on mach-based OS which are not OS X
---
include/diy/time.hpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
b/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
index 692cf36..671e69d 100644
--- a/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
+++ b/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
@@ -3,11 +3,11 @@
#ifndef _WIN32
#include
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
#include
#include
-#endif // __MACH__
+#endif // __MACH__ && __APPLE__
#endif // ifndef _WIN32
namespace diy
{
@@ -16,7 +16,7 @@ typedef unsigned long time_type;
inline time_type get_time()
{
-#ifdef __MACH__ // OS X does not have clock_gettime, use clock_get_time
+#if defined(__MACH__) && defined(__APPLE__) // OS X does not have
clock_gettime, use clock_get_time
clock_serv_t cclock;
mach_timespec_t ts;
host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, );
--
GitLab
--- debian/control.original 2020-12-29 14:14:29.0 +
+++ debian/control 2020-12-29 14:15:29.0 +
@@ -8,7 +8,7 @@
Build-Depends: chrpath,
cmake (>= 3.2.0),
debhelper-compat (= 13),
- default-jdk,
+ default-jdk [!hppa !hurd-any !kfreebsd-any],
default-libmysqlclient-dev,
dh-python,
doxygen-latex,
@@ -115,7 +115,7 @@
libtiff-dev,
libutfcpp-dev,
libvtk9 (= ${binary:Version}),
- libvtk9-java (= ${binary:Version}),
+ libvtk9-java (= ${binary:Version}) [!hppa !hurd-any !kfreebsd-any],
libx11-dev,
libxft-dev,
libxml2-dev,
@@ -161,7 +161,7 @@
that use VTK.
Package: libvtk9-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
Section: java
Depends: ${java:Depends},
${misc:Depends},
--- debian/rules.original 2020-12-29 14:15:37.0 +
+++ debian/rules2020-12-29 14:18:12.0 +
@@ -3,7 +3,11 @@
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+nojava_archs=hppa hurd-i386 kfreebsd-i386 kfreebsd-amd64
+ifneq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH), $(nojava_archs)))
export JAVA_HOME=/usr/lib/jvm/default-java
+extra_flags += -DVTK_WRAP_JAVA=ON
+endif
ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc sh4))
export DEB_CXXFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic
-Wl,--as-needed
@@ -52,7 +56,6 @@
-DVTK_MODULE_USE_EXTERNAL_VTK_zlib:BOOL=ON \
-DVTK_PYTHON_VERSION:STRING=3 \
-DVTK_USE_TK=ON \
- -DVTK_WRAP_JAVA=ON \
-DVTK_WRAP_PYTHON=ON \
-DCMAKE_BUILD_TYPE=RelWithDebInfo
@@ -70,8 +73,10 @@
override_dh_auto_install:
dh_auto_install -X.pyc -X.pyo
+ifneq ($(JAVA_HOME),)
# Correct headers for paraview
mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/java/vtk.jar
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/java/vtk9.jar
+endif
sed -i -e "s/FATAL_ERROR/STATUS/g"
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/vtk-9.0/VTK-targets.cmake
override_dh_install:
Bug#978658: cairo: CVE-2020-35492
Source: cairo Version: 1.16.0-4 Severity: important Tags: security upstream Forwarded: https://gitlab.freedesktop.org/cairo/cairo/-/issues/437 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for cairo. CVE-2020-35492[0]: | cairo: libreoffice slideshow aborts with stack smashing in cairo's | composite_boxes If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-35492 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35492 [1] https://gitlab.freedesktop.org/cairo/cairo/-/issues/437 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1898396 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#954823: Sponsorship of hydrogen
Hi Nicholas, I have spent some time going through the commit messages. There has been a lot of work done! On 29/12/2020 17:29, Nicholas D Steeves wrote: > Hi Ross! > > Ross Gammon writes: > >> owner 954823 rossgam...@debian.org >> thanks >> >> Hi Nicholas, >> >> I am happy to take a look at hydrogen, and sponsor it. I have some spare >> time over the next few days. >> > Thank you, I really appreciate this! :-D Here are some notes and > questions: > > Will you be sponsoring from git or mentors? How would you like me to > work during the WIP cycles of the review? The git history will look a > bit silly and confusing with too many "refinalise for release to > unstable" commits ;-) I can do either. But I think in this case, I would prefer to work from mentors (mainly because I have problems with my gbp setup on this computer). But please also keep the git repository in sync (even if it is on a different branch that we can merge later). Actually, I would like to compliment you on your commit messages. It was pleasing to see a verbose reason for the change, instead of some short cryptic message that just generates more questions. I think it is best to keep a record of the review in the RFS bug. So I have cc'd the RFS bug (sorry - I did not spot it when I started), and we can continue the discussion there. > > On #debian-multimedia, Sebastinas did a preliminary review, and two big > issues were: > > 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >* I've fixed this locally > 2. I was missing an override_dh_auto_configure to make use of >$DEB_CMAKE_EXTRA_FLAGS >* I believe that is why the extra lib and dev packages became > necessary. Now that I know what was causing the problem I can > restore something closer to the old packaging. >* Changing this in the future will require another trip through NEW, > so what do you think the correct split of the package is? I was wondering why the library packages suddenly appeared. I think if it is possible, it is best to stick to the old packages. What applications would want to use hydrogen as a library? > 3. override_dh_auto_clean failed to run "dh_auto_clean". Oops :-/ This might explain why I found that the package failed to build twice in a row for me. > I've already make local fixes for these and other issues, but will delay > pushing until I receive your preference regarding the shared lib and dev > packages. I'm of course open to fixing other issues and removing > anything you consider vestigial to the old cdbs packaging (I chose the > more labour-intensive approach rather than clean packaging)! > >> Have you reopened any bugs that were closed when the package was removed? >> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages >> > I have not yet reopened any bugs. The list of -rm bugs is: > 945042 642014 629105 870395 794042 586087 874907 347279 945042 > > There seem to be differences in perspective about when/if these bugs > should be reopened. My preference is to maintain a strong link between > the changelog and BTS, for future reference, and for future > maintainers. Given "changelog closes bugs in wrong way", I feel like > reopening the bugs that will be closed by the yet-to-be-uploaded > changelog entry is the correct approach, because it creates a strong > link between the changelog and BTS. I think the best thing is to reopen the bug and then close them in the changelog once it is confirmed that they are closed. That way they are closed with the right version information. The most important thing is to ensure that bugs that are not fixed in the new version remain open. Let me know when the new version is available on mentors. Ross signature.asc Description: OpenPGP digital signature
Bug#978657: unknown-horizons: Crash on startup with xml AttributeError "no attribute 'getchildren'"
Package: unknown-horizons Version: 2019.1-2 Severity: grave Tags: a11y Justification: renders package unusable Hi, I encountered a problem starting unknown-horizons. I installed from standard debian testing repository and get the following error: --- $ unknown-horizons --debug Logging to b'/home/sal/.local/share/unknown-horizons/log/unknown- horizons-2020-12-29_20-40-06.log' and /usr/share/unknown-horizons/fife.log Python version: sys.version_info(major=3, minor=9, micro=1, releaselevel='final', serial=0) Platform: Linux-5.9.0-4-amd64-x86_64-with-glibc2.31 SYS.PATH: ['/usr/games', '/usr/lib/python39.zip', '/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload', '/usr/local/lib/python3.9/dist-packages', '/usr/lib/python3/dist-packages'] PATHSEP: ":" SEP: "/" LD_LIBRARY_PATH: PATH: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/var/lib/flatpak/exports/bin PYTHONPATH Python version: sys.version_info(major=3, minor=9, micro=1, releaselevel='final', serial=0) Platform: Linux-5.9.0-4-amd64-x86_64-with-glibc2.31 Using fife version 0.4.2, at least 0.4.2 required Traceback (most recent call last): File "/usr/games/unknown-horizons", line 381, in main() File "/usr/games/unknown-horizons", line 122, in main ret = horizons.main.start(options) File "/usr/lib/python3/dist-packages/horizons/main.py", line 113, in start horizons.globals.fife = Fife() File "/usr/lib/python3/dist-packages/horizons/engine/engine.py", line 46, in __init__ self._setting = Settings(PATHS.USER_CONFIG_FILE, PATHS.SETTINGS_TEMPLATE_FILE) File "/usr/lib/python3/dist-packages/horizons/engine/settings.py", line 39, in __init__ self._settings_serializer.load(settings_file) File "/usr/lib/python3/dist- packages/fife/extensions/serializers/simplexml.py", line 132, in load self._validateTree() File "/usr/lib/python3/dist- packages/fife/extensions/serializers/simplexml.py", line 386, in _validateTree for c in self._root_element.getchildren(): AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 'getchildren' Unknown Horizons has crashed. We are very sorry for this and want to fix the underlying error. In order to do this, we need the information from the logfile: /home/sal/.local/share/unknown-horizons/log/unknown- horizons-2020-12-29_20-40-06.log Please give it to us via IRC or our forum, for both see http://unknown- horizons.org . --- I also attached the unknown-horizons log file. If you need more information just get back on me. Kind regards Steffen -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/6 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unknown-horizons depends on: ii python3 3.9.0-4 ii python3-enet0.0~vcs.2017.05.26.git-2.2+b2 ii python3-fife0.4.2-2+b3 ii python3-future 0.18.2-5 ii python3-yaml5.3.1-3+b1 ii ttf-unifont 1:13.0.04-1 unknown-horizons recommends no packages. unknown-horizons suggests no packages. -- no debconf information Unknown Horizons has crashed. We are very sorry for this and want to fix the underlying error. In order to do this, we need the information from the logfile: /home/sal/.local/share/unknown-horizons/log/unknown-horizons-2020-12-29_20-40-06.log Please give it to us via IRC or our forum, for both see http://unknown-horizons.org . : ":" SEP: "/" LD_LIBRARY_PATH: PATH: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/var/lib/flatpak/exports/bin PYTHONPATH Python version: sys.version_info(major=3, minor=9, micro=1, releaselevel='final', serial=0) Platform: Linux-5.9.0-4-amd64-x86_64-with-glibc2.31 Using fife version 0.4.2, at least 0.4.2 required Traceback (most recent call last): File "/usr/games/unknown-horizons", line 381, in main() File "/usr/games/unknown-horizons", line 122, in main ret = horizons.main.start(options) File "/usr/lib/python3/dist-packages/horizons/main.py", line 113, in start horizons.globals.fife = Fife() File "/usr/lib/python3/dist-packages/horizons/engine/engine.py", line 46, in __init__ self._setting = Settings(PATHS.USER_CONFIG_FILE, PATHS.SETTINGS_TEMPLATE_FILE) File "/usr/lib/python3/dist-packages/horizons/engine/settings.py", line 39, in __init__ self._settings_serializer.load(settings_file) File "/usr/lib/python3/dist-packages/fife/extensions/serializers/simplexml.py", line 132, in load self._validateTree() File "/usr/lib/python3/dist-packages/fife/extensions/serializers/simplexml.py", line 386, in _validateTree for c in self._root_element.getchildren(): AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 'getchildren'
Bug#968518: clevis: "clevis decrypt" does not work in initrd
Marek Rusinowski wrote...
> To fix, I've simply removed the lines 168-170 in clevis-decrypt-tpm2:
>
> # The on_exit() trap will not be fired after exec, so let's clean up the temp
> # directory at this point.
> [ -d "${TMP}" ] && rm -rf "${TMP}"
>
> because with subprocess the trap will be executed and now it works
> without issues for me.
Errm, yes, I had already submitted that upstream in
https://github.com/latchset/clevis/pull/275
but forgot to include it here. Next upload then, once I've figured out
why the build on mispel failed.
Thanks for all your testing and feedback
Christoph
signature.asc
Description: PGP signature
Bug#978656: RFA: zenburn-emacs -- low contrast color theme for Emacs
Package: wnpp Severity: normal X-debbugs-cc: debian-em...@lists.debian.org I request an adoptor for the zenburn-emacs package, which I haven't used for some months now. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. The package description is: A port of the popular Vim theme Zenburn for Emacs, built using the new built-in theme support in Emacs 24. . Zenburn is designed to minimise eye strain during long periods of work. -- Sean Whitton signature.asc Description: PGP signature
Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i
The OpenSSL devs intended this to be a breaking change - but it's not documented anywhere. Sigh. I've got a WIP patch against trunk that causes test_ssl to pass - see below. It also seems to work with OpenSSL 1.1.1h as well as OpenSSL 1.1.1i / 1.1.1-stable, AFAICT. James: can you please give it a try as well? We've been on the threshold of releasing serf 1.4 for quite some time now...maybe we should just do that... If this looks reasonable, I'll try to clean this up and get it into trunk and 1.4.x. Cheers. -- justin Index: test/test_serf.h === --- test/test_serf.h (revision 1884847) +++ test/test_serf.h (working copy) @@ -296,6 +296,14 @@ handler_baton_t handler_ctx[], apr_pool_t *pool); +/* Helper function, runs the client and server context loops and validates + that errors were encountered. */ +void +run_client_and_mock_servers_loops_expect_fail(CuTest *tc, test_baton_t *tb, + int num_requests, + handler_baton_t handler_ctx[], + apr_pool_t *pool); + /* Logs a test suite error with its code location, and return status SERF_ERROR_ISSUE_IN_TESTSUITE. */ #define REPORT_TEST_SUITE_ERROR()\ Index: test/test_ssl.c === --- test/test_ssl.c (revision 1884847) +++ test/test_ssl.c (working copy) @@ -465,9 +465,10 @@ tb->result_flags |= TEST_RESULT_SERVERCERTCB_CALLED; +test__log(TEST_VERBOSE, __FILE__, "Cert failure received: %d ; expected failure mask: %d\n", failures, expected_failures); /* We expect an error from the certificate validation function. */ if (failures & expected_failures) -return APR_SUCCESS; +return APR_EGENERAL; else return REPORT_TEST_SUITE_ERROR(); } @@ -532,8 +533,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, + handler_ctx, tb->pool); } /* Validate that connecting to a SSLv2 only server fails. */ @@ -1121,8 +1122,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, + handler_ctx, tb->pool); CuAssertTrue(tc, tb->result_flags & TEST_RESULT_SERVERCERTCB_CALLED); } @@ -1165,8 +1166,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, + handler_ctx, tb->pool); CuAssertTrue(tc, tb->result_flags & TEST_RESULT_SERVERCERTCB_CALLED); } @@ -2095,8 +2096,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, + handler_ctx, tb->pool); CuAssertTrue(tc, tb->result_flags & TEST_RESULT_SERVERCERTCB_CALLED); } @@ -2138,8 +2139,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, + handler_ctx, tb->pool); CuAssertTrue(tc, tb->result_flags & TEST_RESULT_SERVERCERTCB_CALLED); } @@ -2181,8 +2182,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, + handler_ctx, tb->pool); CuAssertTrue(tc, tb->result_flags & TEST_RESULT_SERVERCERTCB_CALLED); } @@ -2310,8 +2311,8 @@ create_new_request(tb, _ctx[0], "GET", "/", 1); -run_client_and_mock_servers_loops_expect_ok(tc, tb, num_requests, -handler_ctx, tb->pool); +run_client_and_mock_servers_loops_expect_fail(tc, tb, num_requests, +
Bug#977538: fonts-agave: does not follow upstream's recommended build procedure
Hi Fabian, I think that's what you wanted: https://mentors.debian.net/package/fonts-agave/ Happy New Year!
Bug#975696: [Pkg-sugar-devel] Bug#975696: link-grammar: multi-thread test fails
Control: reopen -1 Hi Jonas The build of link-grammar/5.8.0-3 has already failed on ppc64el [1] (details below). As fun as it is, please let's avoid the BTS sports and leave this bug open until link-grammar builds and passes its autopkgtests reliably. Regards Graham [1] https://buildd.debian.org/status/fetch.php?pkg=link-grammar=ppc64el=5.8.0-3=1609265548=0 FAIL: multi-thread == link-grammar: Info: Dictionary found at ../data/en/4.0.dict link-grammar: Info: Dictionary found at ../data/ru/4.0.dict link-grammar: Info: ru: Spell checker disabled. double free or corruption (fasttop) FAIL multi-thread (exit status: 134)
Bug#978647: [Pkg-matrix-maintainers] Bug#978647: matrix-mirage: wrong config path in README.Debian
clone 978647 -1 reopen -1 notfound -1 matrix-mirage/0.6.4~dfsg+~hsluv1.0.0-3 retitle -1 matrix-mirage: uses non-renamed path ~/.cache/mirage thanks Quoting Reiner Herrmann (2020-12-29 19:24:21) > I also just noticed two mirage-related cache directories. I have one > directory ~/.cache/matrix-mirage, but also ~/.cache/mirage which > contains qmlcache files. > > Maybe the path needs to be adjusted in another place as well. Indeed. Thanks. In future, please post as separate bug (it is easier to merge than to split). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#978654: python3-cypari2: Depends on cysignals
Package: python3-cypari2 Version: 2.1.2-1+b1 Severity: important Dear Maintainer, The module cypari2 seems to be impossible to import without the module cysignals. Here's the traceback: >>> import cypari2 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/cypari2/__init__.py", line 1, in from .pari_instance import Pari File "cypari2/pari_instance.pyx", line 1, in init cypari2.pari_instance File "cypari2/gen.pyx", line 1, in init cypari2.gen File "cypari2/stack.pyx", line 1, in init cypari2.stack ModuleNotFoundError: No module named 'cysignals' Installing python3-cysignals-bare or python3-cysignals-pari fixes it. Therefore, I would suggest adding a dependency to 'python3-cysignal-bare | python3-cysignals-pari'. Best regards, Celelibi -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-cypari2 depends on: ii libc6 2.31-6 ii libpari-gmp-tls7 2.13.0-2 ii python3 3.9.0-4 python3-cypari2 recommends no packages. python3-cypari2 suggests no packages. -- no debconf information
Bug#978499: #978499: fop: reproducible builds: Support using SOURCE_DATE_EPOCH for timestamps in PDF files
Control: notfixed 978499 1:2.5-2
On 2020-12-27, Vagrant Cascadian wrote:
> Several packages use fop to generate PDF files in Debian packages, but
> the resulting PDF files have embedding timestamp information in the
> CreationDate of the PDF:
>
>
> https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_pdf_generated_by_apache_fop_issue.html
Thanks for the quick upload! unfortunately...
> For example, in xorg-docs:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/xorg-docs.html
>
> /usr/share/doc/xorg-docs/xlfd/xlfd.pdf.gz
>
> CreationDate:·"D:20201225182038-12'00'"
> vs.
> CreationDate:·"D:20220129025203+14'00'"
I rescheduled various builds after fop landed in unstable, and it
appears to not fully fix the issue...
It clearly fixed the issue for me when building xorg-docs with reprotest
locally, which does test time and timezone variations... but it uses
faketime, which often behaves differently than a system with an adjusted
running clock such as the tests.reproducible-builds.org infrastructure.
hrm.
> The attached patch fixes this by adding support for the
> SOURCE_DATE_EPOCH environment variable to fop, which embeds the
> specified timestamp rather than the current time:
>
> https://reproducible-builds.org/docs/source-date-epoch/
>
>
> Thanks for maintaining fop!
>
>
> live well,
> vagrant
> From 25826ea9c86d01a8392cf593b9aa93c72b469b19 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian
> Date: Mon, 28 Dec 2020 02:48:21 +
> Subject: [PATCH] PDFInfo.java: Support SOURCE_DATE_EPOCH environment variable.
>
> https://reproducible-builds.org/docs/source-date-epoch/
> ---
> fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
> b/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
> index 3aa5d97..79f3f42 100644
> --- a/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
> +++ b/fop-core/src/main/java/org/apache/fop/pdf/PDFInfo.java
> @@ -305,7 +305,14 @@ public class PDFInfo extends PDFObject {
> * @return the requested String representation
> */
> protected static String formatDateTime(final Date time) {
> -return formatDateTime(time, TimeZone.getDefault());
> +// https://reproducible-builds.org/docs/source-date-epoch/
> +String source_date_epoch = System.getenv("SOURCE_DATE_EPOCH");
> +if (source_date_epoch != null) {
> +Long sourcedate = (1000 * Long.parseLong(source_date_epoch));
> +return formatDateTime(new Date(sourcedate),
> TimeZone.getTimeZone("Etc/UTC"));
> +} else {
> +return formatDateTime(time, TimeZone.getDefault());
> +}
> }
>
> /**
> --
> 2.20.1
Ah well, if anyone has a suggestion for how to really fix it, that would
be nice, since it would fix several packages...
live well,
vagrant
signature.asc
Description: PGP signature
Bug#968518: clevis: "clevis decrypt" does not work in initrd
Hi Christoph,
The upstream.work-around-missing-dev-fd-links.patch doesn't
work for the tpm2 pin yet.
You replaced exec with a child process but in this case the on_exit trap
continues to run and the decryption with tpm2 pin will always fail with
Delete temporary files failed!
You need to clean up: $TMP
because files will try to be removed twice.
To fix, I've simply removed the lines 168-170 in clevis-decrypt-tpm2:
# The on_exit() trap will not be fired after exec, so let's clean up the temp
# directory at this point.
[ -d "${TMP}" ] && rm -rf "${TMP}"
because with subprocess the trap will be executed and now it works
without issues for me.
Thank you,
Marek
Bug#978471: waybar fails to launch
On Wed, Dec 30, 2020 at 2:39 AM Shengjing Zhu wrote: > Follow Sebastian's advice, please see the following patch. Having one typo, so creating a MR https://salsa.debian.org/med-team/spdlog/-/merge_requests/3 -- Shengjing Zhu
Bug#978401: ibus-libpinyin: FTBFS on armel, armhf and mipsel: lua test failure
在 2020-12-28星期一的 15:41 +0100，Gunnar Hjalmarsson写道： > FWIW test-lua-plugin passed when I did a test build on armhf in an > Ubuntu PPA with lua re-enabled. That would be great. Since I am not familiar with ARM porting, it would be great if anyone can analyze what is happening with Debian's lua. > Fixing that is an administrative procedure which may take some time, > so > for now I uploaded ibus-libpinyin to Ubuntu with lua5.3 and without > opencc support. > > https://launchpad.net/ubuntu/+source/ibus-libpinyin/1.12.0-3ubuntu1 > > Questions: > - How important is the upgrade to lua5.4? > - How important is the opencc support? > I'd say they are not so important since I didn't receive any bug reports regarding the features missing when they were disabled. Since now you have a solution of patching in Ubuntu, that looks like a viable solution. Thanks, Boyuan Yang
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
Hans-Christoph Steiner: It looks like the clean build stops before the error you reported: https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291335 In file included from runtime/runtime.cc:53: runtime/asm_support.h:24:10: fatal error: 'asm_defines.h' file not found #include "asm_defines.h" ^~~ 1 error generated. make[2]: *** [debian/libart.mk:473: runtime/runtime.o] Error 1 My guess is that the Makefile dependency rules are wrong, since the target that builds asm_defines.h works fine when manually run. If you use your own fork, and force-push commits to your fork's master branch, it'll run the CI jobs, which are totally clean builds each time. Ok, I fixed the dependency issue, now it gets reliably to the point rosh gets to: https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291535 .hc
Bug#978630: [pkg-gnupg-maint] Bug#978630: Bug#978630: gnupg: --check-sigs trusts weak digest alg if weak digest was trusted when importing key
It gets cached if it has been checked. There are some pre-conditions for this for example the existance of the corresponding public key.
Bug#978471: waybar fails to launch
Hi,
On Tue, Dec 29, 2020 at 07:10:23PM +0100, Sebastian Ramacher wrote:
> On 2020-12-29 22:01:15, Andrey Rahmatullin wrote:
> > Control: reassign -1 libspdlog1/1:1.8.1+ds-2+b1
> > Control: affects -1 waybar
> > Control: severity -1 serious
> > Control: retitle -1 libspdlog1 breaks ABI on rebuilds with different libfmt
> >
> > On Sun, Dec 27, 2020 at 09:26:09PM +0100, Michele Cane wrote:
> > > waybar: symbol lookup error: waybar: undefined symbol:
> > > _ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v617basic_string_viewIcEENS_5level10level_enumES6_
> > This is because libspdlog1 was rebuilt with newer libfmt and this caused
> > symbol renames.
> >
> > #977454 says "The code is actually working with the new version, only the
> > symbols file is wrong here. spdlog uses fmtlib internal API and exposes it
> > through the symbols files. This looks wrong to me, as every new fmtlib
> > will cause spdlog ftbfs due to the symbols file.". If it's about the same
> > problem then it looks like it failed to mention that symbol changes cause
> > much worse problems than just needing to update the symbols file.
>
> The situtation is somewhat similar to liboost-regex and libicu.
> libboost-regex exports symbols that depend on libicu's ABI and change
> whenever liboost-regex is rebuilt against a version of libicu with a
> different ABI.
>
> For spdlog this can be solved in the same way as for boost.
> liboost-regexX.Y provides libboost-regexX.Y-icuZ when built against
> libicuZ. Reverse dependencies then depend on libboost-regexX.Y-icuZ. See
>
> https://salsa.debian.org/debian/boost/-/blob/master/debian/rules#L53
> https://salsa.debian.org/debian/boost/-/blob/master/debian/rules#L289
> https://salsa.debian.org/debian/boost/-/blob/master/debian/rules#L338
>
> Cheers
> --
> Sebastian Ramacher
Follow Sebastian's advice, please see the following patch.
diff --git a/debian/changelog b/debian/changelog
index 1d31b26..f4b7f55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+spdlog (1:1.8.1+ds-3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Track fmtlib abi in libspdlog1
+
+ -- Shengjing Zhu Wed, 30 Dec 2020 02:30:44 +0800
+
spdlog (1:1.8.1+ds-2) unstable; urgency=medium
[ Shengjing Zhu ]
diff --git a/debian/control b/debian/control
index e83f692..ab6d998 100644
--- a/debian/control
+++ b/debian/control
@@ -38,6 +38,8 @@ Package: libspdlog1
Architecture: any
Multi-Arch: same
Section: libs
+Breaks: libspdlog (<< 1:1.8.1+ds-3)
+Provides: ${spdlog:Provides}
Depends: ${shlibs:Depends},
${misc:Depends}
Description: Very fast C++ logging library
diff --git a/debian/rules b/debian/rules
index f20dd81..154cbdc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,10 @@ endif
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+soversion = 1
+fmtabi = $(shell apt show libfmt-dev 2>/dev/null | sed -n 's/Depends: .*libfmt\([0-9]*\) .*/\1/p')
+spdlogfmtabi = libspdlog$(soversion)-fmt$(fmtabi)
+
%:
dh $@ --with pkgkde_symbolshelper --buildsystem=cmake
@@ -41,3 +45,9 @@ override_dh_auto_install:
rm -f example/logs/.gitignore
dh_auto_install
find debian -name .gitignore -delete
+
+override_dh_gencontrol:
+ dh_gencontrol -- -Vspdlog:Provides=$(spdlogfmtabi)
+
+override_dh_makeshlibs:
+ dh_makeshlibs -plibspdlog1 -V '$(spdlogfmtabi)'
Bug#978351: requests: FTBFS: AttributeError: 'LookupDict' object has no attribute '__name__'
On Mon, 28 Dec 2020 17:11:47 +0100 Daniele Tricoli wrote: > > I can reproduce it using python3-sphinx 3.4.1, I'm still investigating since > from sphinx's CHANGELOG the only incompatible change[¹] upgrading from sphinx > 3.3.1 (using it building the documentation is fine) seems to not be related to > this. I opened an issue upstream https://github.com/sphinx-doc/sphinx/issues/8616 but I'm going to close this temporary patching out the the part of the documentation that is failing to build, so we can close this without reassigning to sphinx. The temporary patch will just exclude the autodocumentation for requests.codes. Cheers, -- Daniele Tricoli 'eriol' https://mornie.org signature.asc Description: PGP signature
Bug#978653: ITP: bazel-platforms -- Bazel Platforms
Package: wnpp Severity: wishlist Owner: Olek Wojnar * Package name: bazel-platforms Version : 0.0.2 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/platforms * License : Apache-2 Programming Lang: Settings Description : Bazel Platforms All canonical constraint_setting()s, constraint_value()s and platform()s that are universally useful across languages and Bazel projects. * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#978652: RFP: bazel-java-tools -- Bazel Tools for Java
Package: wnpp Severity: wishlist * Package name: bazel-java-tools Version : 10.5 Upstream Author : Google Inc. * URL : https://github.com/bazelbuild/java_tools * License : Apache-2 Programming Lang: Java Description : Bazel Tools for Java Tools used by Bazel to compile Java. * This package is part of the Bazel Build System. If you would like to package it, please joint the team at https://salsa.debian.org/bazel-team and upload to the pre-made project for this package. Please contact us at bazel-t...@lists.launchpad.net if you have any questions! *
Bug#978647: [Pkg-matrix-maintainers] Bug#978647: matrix-mirage: wrong config path in README.Debian
Hi Jonas, On Tue, Dec 29, 2020 at 07:02:07PM +0100, Jonas Smedegaard wrote: > > > On Debian, binary is renamed to "matrix-mirage". > > > Correspondingly, config path is changed to "$XDG_CONFIG_HOME/mirage/". > > > > But the config path is actually also different. On my system the > > configuration is stored in "$XDG_CONFIG_HOME/matrix-mirage/". > > Whoops, that's a typo: The intended message is that config path is > changed too - but then I accidentally pased the old path without editing > it. I also just noticed two mirage-related cache directories. I have one directory ~/.cache/matrix-mirage, but also ~/.cache/mirage which contains qmlcache files. Maybe the path needs to be adjusted in another place as well. Kind regards, Reiner signature.asc Description: PGP signature
Bug#978640: undefined symbol: _ZTIN3fmt2v612format_errorE
On Tue, 29 Dec 2020 19:55:57 +0530, Utkarsh Gupta said: > Dear maintainer, > Whilst trying to open nheko, it fails to open with the following > message: > ``` $ nheko nheko: symbol lookup error: nheko: undefined symbol: > _ZTIN3fmt2v612format_errorE ``` > Is that known? Any idea what caused this regression or failure? Any > workaround this? Hmm. Can you try installing libfmt7 (from sid) and see if that fixes it? -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Bug#978471: waybar fails to launch
On 2020-12-29 22:01:15, Andrey Rahmatullin wrote: > Control: reassign -1 libspdlog1/1:1.8.1+ds-2+b1 > Control: affects -1 waybar > Control: severity -1 serious > Control: retitle -1 libspdlog1 breaks ABI on rebuilds with different libfmt > > On Sun, Dec 27, 2020 at 09:26:09PM +0100, Michele Cane wrote: > > waybar: symbol lookup error: waybar: undefined symbol: > > _ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v617basic_string_viewIcEENS_5level10level_enumES6_ > This is because libspdlog1 was rebuilt with newer libfmt and this caused > symbol renames. > > #977454 says "The code is actually working with the new version, only the > symbols file is wrong here. spdlog uses fmtlib internal API and exposes it > through the symbols files. This looks wrong to me, as every new fmtlib > will cause spdlog ftbfs due to the symbols file.". If it's about the same > problem then it looks like it failed to mention that symbol changes cause > much worse problems than just needing to update the symbols file. The situtation is somewhat similar to liboost-regex and libicu. libboost-regex exports symbols that depend on libicu's ABI and change whenever liboost-regex is rebuilt against a version of libicu with a different ABI. For spdlog this can be solved in the same way as for boost. liboost-regexX.Y provides libboost-regexX.Y-icuZ when built against libicuZ. Reverse dependencies then depend on libboost-regexX.Y-icuZ. See https://salsa.debian.org/debian/boost/-/blob/master/debian/rules#L53 https://salsa.debian.org/debian/boost/-/blob/master/debian/rules#L289 https://salsa.debian.org/debian/boost/-/blob/master/debian/rules#L338 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#978647: [Pkg-matrix-maintainers] Bug#978647: matrix-mirage: wrong config path in README.Debian
Hi Reiner, Quoting Reiner Herrmann (2020-12-29 18:36:33) > the README.Debian file mentions: > > > On Debian, binary is renamed to "matrix-mirage". > > Correspondingly, config path is changed to "$XDG_CONFIG_HOME/mirage/". > > But the config path is actually also different. On my system the > configuration is stored in "$XDG_CONFIG_HOME/matrix-mirage/". Whoops, that's a typo: The intended message is that config path is changed too - but then I accidentally pased the old path without editing it. Thanks for spotting that! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#977925: dh-runit: does not create the /etc/sv/*/log/supervise symlink
On Wed, 23 Dec 2020 00:23:12 +0100 Mathieu Mirmont wrote: > Package: dh-runit > Version: 2.10.2 > Severity: wishlist > > Dear Maintainer, > > When I use the logscript option, a log/supervise symlink is created by > dh_runit. When I don't use the logscript option and provide my own > log/run script instead, the log/supervise symlink is not created. > > As a result /etc/sv/.../log/supervise ends up being a directory > created at runtime, which while not breaking is a bit inconsistent. > I'm shipping a dangling symlink as log/supervise for now, but that is > also inconsistent since the main supervise symlink is taken care of by > dh_runit. > > The right logic I think would be to make the symlink is logscript is > not given but a log/run script is present. > > Cheers, > Hi Mathieu, Thanks for the report, will fix this in 2.10.3. Cheers, Lorenzo
Bug#978638: RFS: dh-runit/2.10.3 -- debhelper add-on to handle runit runscripts
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear mentors, I am looking for a sponsor for my package "dh-runit": * Package name: dh-runit Version : 2.10.3 Upstream Author : [fill in name and email of upstream] * URL : https://salsa.debian.org/debian/dh-runit * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-runit Section : admin It builds those binary packages: runit-helper - dh-runit implementation detail dh-runit - debhelper add-on to handle runit runscripts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-runit/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.10.3.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/dh-runit/-/tree/2.10.3-release Changes since the last upload: dh-runit (2.10.3) unstable; urgency=medium . * Always create supervise link for log service (Closes: #977925) * Add 2 testcase for supervise links * Bump out version to 2.10.3 * Bump Stadards-Version to 4.5.1 Regards, -- Lorenzo Puliti
Bug#978640: undefined symbol: _ZTIN3fmt2v612format_errorE
Hi Hubert, On Tue, Dec 29, 2020 at 11:17 PM Hubert Chathi wrote: > Hmm. Can you try installing libfmt7 (from sid) and see if that fixes > it? The issue could be fixed by rebuilding nheko against the newly updated libfmt-dev version. I've prepared and pushed a fix to the salsa repository. If it's okay with you, can I do the upload as well? - u
Bug#940858: Info received ([Pkg-mailman-hackers] Bug#940858: mailman3: `mailman create` as root creates directory with wrong owner)
Control: tag -1 wontfix Am 29.12.20 um 18:51 schrieb Debian Bug Tracking System: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Mailman Team If you wish to submit further information on this problem, please send it to 940...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#978637: Bug in multiple ldaps URIs handling
Package: libnet-ldap-perl Version: 1:0.6500+dfsg-1 According to https://rt.cpan.org/Public/Bug/Display.html?id=118477 when creating a new ldaps:// connection using multiple URIs in the connection string (faiover in case of communication problems), it will only succeed if the connection to the first server succeeds. If the connection to the first server fails (i.e. first LDAP server is down or has invalid cert), connection to all subsequent servers will fail too. Problem was fixed by upstream in https://github.com/perl-ldap/perl-ldap/pull/58/files Please fix also in Debian packages. -- Regards, Paweł Bogusławski IB Development Team E: d...@ib.pl
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
On Tue, Dec 29, 2020 at 03:20:14PM +0100, Abou Al Montacir wrote: > Why gcc10 and not gcc8? I assume you are using sid.But then we need a way to > avoid hard coding the gcc version. Yes, gcc-10 is what build-essential installs on Sid (and Bullseye), which is what I am using there (as I'm trying to prepare my package using fpc for Bullseye). As for hard coding, those paths are ALREADY hard-coded at least for Intel architectures (amd64, i386), for example: - on amd64 Buster, /etc/fpc-3.0.4.cfg contains this hard-coded block: # path to the gcclib #ifdef cpui386 -Fl/usr/lib/gcc/x86_64-linux-gnu/8 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/x86_64-linux-gnu/8 #endif - on i386 Sid, /etc/fpc-3.2.0.cfg contains this hard-coded block: # path to the gcclib #ifdef cpui386 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif That hard-coded paths seem to already be auto-generated on build somehow. Note that current values also seem wrong if one is using multiarch / cross-compiling; as a path for "ifdef cpui386" should probably be different than than the one for "ifdef cpux86_64". I see two ways to fix this bug: - easier: Just remove the ifdefs, that is make that whole block just one line: -Fl/usr/lib/gcc/$TRIPLET/$GCC # whatever variable names are... eg. -Fl/usr/lib/gcc/i686-linux-gnu/10 # when generating binary package on i386 -Fl/usr/lib/gcc/x86_64-linux-gnu/10 # when generating binary package on amd64 -Fl/usr/lib/gcc/arm-linux-gnueabi/10 # when generating binary package on armel etc. Then it will be behaving just it does now on amd64 and i386, but would also fix arm and other non-intel architectures - better (also fixing not just arm* builds, but multiarch too), but more work: Do not generate that block using variables, instead hard-code it manually for each Debian release and supported architectures from https://wiki.freepascal.org/Platform_defines, eg. #ifdef cpui386 -Fl/usr/lib/gcc/i686-linux-gnu/10 #endif #ifdef cpux86_64 -Fl/usr/lib/gcc/x86_64-linux-gnu/10 #endif #ifdef cpuarm -Fl/usr/lib/gcc/arm-linux-gnueabi/10 #endif #etc... While it needs more testing to find all the correct fpc ifdefs and gcc path triplets, it would fix all supported architectures, and make it more multiarch friendly (although there might be other multiarch blockers, I haven't checked) -- Opinions above are GNU-copylefted.
Bug#978651: debbugs: SOAP interface: get_bug_log() should not return messages known to be spam
Package: debbugs Severity: wishlist X-Debbugs-Cc: nis.marten...@web.de Let's take bug #711404 as an example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711404 Here the bug log currently shows four messages. However, when running `reportbug -u text -N 711404`, you'll be shown 12 messages. The last 8 messages are all spam, and debbugs knows about this, otherwise bugreport.cgi would show them as well. It would be great if the get_bug_log() SOAP query learned to ignore spam messages.
Bug#940858: [Pkg-mailman-hackers] Bug#940858: mailman3: `mailman create` as root creates directory with wrong owner
Control: -1 wontfix Hello, Am 21.02.20 um 21:56 schrieb Pierre-Elliott Bécue: When using the command `mailman create` as root, it creates a folder in /var/lib/mailman3/lists/ with the root:root owner/group. This then causes the following error that makes the mailing list unusable: Sep 20 16:28:58 2019 (30951) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman3/lists/ml.example.org/digest.mmdf' FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/mailman3/lists/ml.example.org/digest.mmdf' I think this command, when run as root, should create the directory with the appropriate owner/group (list:list), so that we don't have to chown the directory manually thereafter. Or at least tell us that we need to run this chown manually if mailman can't do it for some reason. The main reason it's not obvious to act upon this is that it's Debian's choice to run mailman3 as list:list, hence the program can't really guess if being launched as root:root is normal or not. In my opinon one should know the potential impact of running a program as a specific user. If you have an idea of a way to work upon that properly, I'm all ears. Just to let you know: that's exactly what `/usr/bin/mailman-wrapper` is for. It takes care of invoking `/usr/bin/mailman` as user `list:list`. Kind regards jonas OpenPGP_signature Description: OpenPGP digital signature
