Bug#1072517: /etc/apparmor.d/cockpit-desktop in Zeile 1: Could not open 'abi/4.0'
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/20543 Control: tag -1 patch pending Hello Michael, Michael Biebl [2024-06-03 14:39 +0200]: > Jun 03 14:35:42 mars apparmor.systemd[1026]: AppArmor-Analysefehler f?r > /etc/apparmor.d in profile /etc/apparmor.d/cockpit-desktop in Zeile 1: Could > not open 'abi/4.0': Datei oder Verzeichnis nicht gefunden Argh, thanks for spotting! I have a fix for this, sent upstream and I'll cherry-pick it now. Martin
Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)
Control: tag -1 upstream fixed-upstream patch
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19790
Hello Salvatore and Santiago,
Salvatore Bonaccorso [2024-04-15 19:28 +0200]:
> The update for cockpit in DSA 5655-1 had problems with the
> test-sshbridge test, causing FTBFS:
>
> >From the tail of the test failure:
>
> # cockpit-protocol-DEBUG: test-ssh: output queue empty
>
> (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702:
> (src/ssh/cockpitsshrelay.c:1423):cockpit_ssh_connect: runtime check failed:
> (ssh_options_set (data->session, SSH_OPTIONS_HOST, host) == 0)
>
> (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702:
> (src/ssh/cockpitsshrelay.c:1424):cockpit_ssh_connect: runtime check failed:
> (ssh_options_parse_config (data->session, NULL) == 0)
> # cockpit-protocol-DEBUG: test-ssh: reading input 1
> # cockpit-protocol-DEBUG: test-ssh: received a 82 byte payload
> # cockpit-protocol-DEBUG: test-ssh: want more data
> **
> cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init:
> assertion failed (json_object_get_string_member (init, "command") == "init"):
> ("authorize" == "init")
> Bail out!
> cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init:
> assertion failed (json_object_get_string_member (init, "command") == "init"):
> ("authorize" == "init")
> cockpit-ssh-Message: 20:51:17.704: cockpit-ssh some_host: -1 couldn't
> connect: Hostname required 'some_host' '22'
> cockpit-ssh-Message: 20:51:17.704: couldn't write control message: Broken pipe
> cockpit-ssh-Message: 20:51:17.704: couldn't write authorize message:
> Inappropriate ioctl for device
> FAIL test-sshbridge (exit status: 134)
Argh, I can reproduce. The test passes with the previous
http://snapshot.debian.org/package/libssh/0.10.5-3/ but fails with current
0.10.6-0+deb12u1.
The reason is annoyingly mundane, and already got fixed upstream half a year
ago:
https://github.com/cockpit-project/cockpit/commit/518d36c3492020525
I prepared a package update with that fix cherry-picked. See attached debdiff.
It builds fine in a clean bookworm container now.
But I don't know how exactly to target and upload this: to bookworm-security or
-updates? It's a follow-up for a previous security update to make that actually
work, but not a security update in itself.
Santiago Vila [2024-04-15 20:28 +0200]:
> For completeness: this was already happening in bullseye and bookworm
> before the DSA. (Reminder for myself: report all the bugs I found
> last week while rebuilding bullseye and bookworm).
Right, that makes sense. There are no C code changes between 287 and 287.1.
Thanks, and sorry for the trouble,
Martin
diff -Nru cockpit-287.1/debian/changelog cockpit-287.1/debian/changelog
--- cockpit-287.1/debian/changelog 2024-04-02 11:11:19.0 +0200
+++ cockpit-287.1/debian/changelog 2024-04-16 09:20:17.0 +0200
@@ -1,3 +1,11 @@
+cockpit (287.1-0+deb12u2) bookworm-security; urgency=medium
+
+ * Add 0001-ssh-Use-valid-host-name-in-test-sshbridge.patch:
+Use valid host name in test-sshbridge. Fixes FTBFS due to unit test
+failure when building against libssh 0.10.6. (Closes: #1069059)
+
+ -- Martin Pitt Tue, 16 Apr 2024 09:20:17 +0200
+
cockpit (287.1-0+deb12u1) bookworm-security; urgency=medium
* New upstream security update:
diff -Nru
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
---
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
1970-01-01 01:00:00.00000 +0100
+++
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
2024-04-16 09:19:18.0 +0200
@@ -0,0 +1,36 @@
+From 518d36c349202052578a459872c3657760226648 Mon Sep 17 00:00:00 2001
+From: Martin Pitt
+Date: Fri, 29 Dec 2023 07:12:11 +0100
+Subject: [PATCH] ssh: Use valid host name in test-sshbridge
+
+libssh 0.10.6 made host name parsing stricter. `some_host` is not a
+valid general host name, and is rejected with the latest version.
+---
+ src/ssh/test-sshbridge.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/ssh/test-sshbridge.c b/src/ssh/test-sshbridge.c
+index e0ff9a7a9..9c561e29a 100644
+--- a/src/ssh/test-sshbridge.c
b/src/ssh/test-sshbridge.c
+@@ -323,7 +323,7 @@ setup (TestCase *tc,
+ if (!fixture->knownhosts_home)
+ g_assert_cmpint (mkdir (tc->home_ssh_dir, 0700), ==, 0);
+
+- g_string_append (content, "Host some_host\n");
++ g_string_append (content, "Host somehost\n");
+ g_string_append_printf (content, "\tHostname %s\n", ho
Bug#1067208: umockdev: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/216 Control: tag -1 upstream pending Hello all, Thorsten Glaser [2024-03-20 3:05 +]: > /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed > only with _FILE_OFFSET_BITS=64" >26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" > | ^ > > > I admit I don’t exactly see what’s going on here. Does it > maybe #unset _FILE_OFFSET_BITS or something? Yes, it currently does on main/latest release, see https://github.com/martinpitt/umockdev/issues/216 Simon McVittie [2024-03-21 12:30 +]: > I don't think the proposed fix in kmod is correct, and I don't think > an equivalent in umockdev would be correct either. Since glibc 2.34, > on 32-bit architectures all such LD_PRELOAD modules will need updating > to also wrap __lstat64_time64(), __stat64_time64(), __fstat64_time64() > and __fstatat64_time64() on architectures where they exist - otherwise, > programs and libraries compiled with 64-bit time_t will bypass the > wrapped stat(), stat64() etc. and call __stat64_time64() instead, and > therefore the wrapping will be ineffective and umockdev's mock devices > will not be seen. Correct. As it happens, the latest Ubuntu package got fixes for both of these issues recently, thanks to Steve Langasek and Zixing Liu! I'll integrate them upstream and then make a new release. Martin
Bug#1062354: libatomic1: 14-20240127-1 missing libat_test_and_set_1_i2
Control: severity 1061370 grave Control: forcemerge -1 1061370 Matthias Klose [2024-02-01 8:30 +0100]: > please don't file duplicate reports, see #1061370 Ah, sorry -- it wasn't clear from the title that it was about this problem, nor was it RC. Marking a duplicate, so that it's easier to find. Pitti
Bug#1062354: libatomic1: 14-20240127-1 missing libat_test_and_set_1_i2
Package: libatomic1 Version: 14-20240127-1 Severity: grave Justification: breaks a lot of unrelated packages Hello, yesterday's cockpit armel build failed [1] on armel like this in the ./configure test for the PCP library: | configure:6158: gcc -o conftest -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c -lssh >&5 | /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to `libat_test_and_set_1_i2' PCP hasn't changed since the previous build [2]; however, libatomic1 (via gcc-14) did -- [2] built against libatomic1/gcc 13.2.0-9. I spot-checked a few of the autopkgtest regressions on the PTS [3], and they all failed on the exact same issue, e.g. [4]. Thanks! Martin [1] https://buildd.debian.org/status/fetch.php?pkg=cockpit&arch=armel&ver=310-1&stamp=1706722995&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=cockpit&arch=armel&ver=309-1&stamp=1705590895&raw=0 [3] https://tracker.debian.org/pkg/gcc-14 [4] https://ci.debian.net/packages/3/389-ds-base/testing/armel/42559327/
Bug#1058214: sosreport: FTBFS -- NMU debdiff
Hello again,
as promised, I uploaded the fix with the attached debdiff.
Martin
diff -Nru sosreport-4.0/debian/changelog sosreport-4.0/debian/changelog
--- sosreport-4.0/debian/changelog 2021-01-27 15:29:24.0 +0100
+++ sosreport-4.0/debian/changelog 2024-01-10 08:16:54.0 +0100
@@ -1,3 +1,12 @@
+sosreport (4.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * d/p/0004-unittest-assertEquals.patch: unittest.TestCase.assertEquals() was
+deprecated in Python 3, and finally dropped in Python 3.12. Fixes FTBFS
+due to unit tests failing. (Closes: #1058214)
+
+ -- Martin Pitt Wed, 10 Jan 2024 08:16:54 +0100
+
sosreport (4.0-2) unstable; urgency=medium
* d/p/0003-systemd-prefer-resolvectl-over-systemd-resolve.patch:
diff -Nru sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch
sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch
--- sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch
1970-01-01 01:00:00.0 +0100
+++ sosreport-4.0/debian/patches/0004-unittest-assertEquals.patch
2024-01-10 08:16:40.0 +0100
@@ -0,0 +1,545 @@
+Description: [tests] Drop obsolete TestCase.assertEquals()
+Author: Martin Pitt
+Bug: https://github.com/sosreport/sos/pull/3467
+Bug-Debian: https://bugs.debian.org/1058214
+
+Index: sosreport-4.0/tests/archive_tests.py
+===
+--- sosreport-4.0.orig/tests/archive_tests.py
sosreport-4.0/tests/archive_tests.py
+@@ -92,7 +92,7 @@ class TarFileArchiveTest(unittest.TestCa
+ self.tf.add_string('this is my content', 'tests/string_test.txt')
+
+ afp = self.tf.open_file('tests/string_test.txt')
+-self.assertEquals('this is my content', afp.read())
++self.assertEqual('this is my content', afp.read())
+
+ def test_rewrite_file(self):
+ """Test that re-writing a file with add_string() modifies the content.
+@@ -101,7 +101,7 @@ class TarFileArchiveTest(unittest.TestCa
+ self.tf.add_string('this is my new content', 'tests/string_test.txt')
+
+ afp = self.tf.open_file('tests/string_test.txt')
+-self.assertEquals('this is my new content', afp.read())
++self.assertEqual('this is my new content', afp.read())
+
+ def test_make_link(self):
+ self.tf.add_file('tests/ziptest')
+Index: sosreport-4.0/tests/cleaner_tests.py
+===
+--- sosreport-4.0.orig/tests/cleaner_tests.py
sosreport-4.0/tests/cleaner_tests.py
+@@ -41,12 +41,12 @@ class CleanerMapTests(unittest.TestCase)
+
+ def test_mac_map_skip_ignores(self):
+ _test = self.mac_map.get('ff:ff:ff:ff:ff:ff')
+-self.assertEquals(_test, 'ff:ff:ff:ff:ff:ff')
++self.assertEqual(_test, 'ff:ff:ff:ff:ff:ff')
+
+ def test_mac_map_avoid_duplicate_obfuscation(self):
+ _test = self.mac_map.get('ab:cd:ef:fe:dc:ba')
+ _dup = self.mac_map.get(_test)
+-self.assertEquals(_test, _dup)
++self.assertEqual(_test, _dup)
+
+ def test_ip_map_obfuscate_v4_with_cidr(self):
+ _test = self.ip_map.get('192.168.1.0/24')
+@@ -68,7 +68,7 @@ class CleanerMapTests(unittest.TestCase)
+
+ def test_ip_skip_ignores(self):
+ _test = self.ip_map.get('127.0.0.1')
+-self.assertEquals(_test, '127.0.0.1')
++self.assertEqual(_test, '127.0.0.1')
+
+ def test_hostname_obfuscate_domain_options(self):
+ _test = self.host_map.get('www.redhat.com')
+Index: sosreport-4.0/tests/option_tests.py
+===
+--- sosreport-4.0.orig/tests/option_tests.py
sosreport-4.0/tests/option_tests.py
+@@ -34,10 +34,10 @@ class GlobalOptionTest(unittest.TestCase
+ ]
+
+ def test_simple_lookup(self):
+-self.assertEquals(self.plugin.get_option('test_option'), 'foobar')
++self.assertEqual(self.plugin.get_option('test_option'), 'foobar')
+
+ def test_cascade(self):
+-self.assertEquals(self.plugin.get_option(('baz')), False)
++self.assertEqual(self.plugin.get_option(('baz')), False)
+
+
+ if __name__ == "__main__":
+Index: sosreport-4.0/tests/plugin_tests.py
+===
+--- sosreport-4.0.orig/tests/plugin_tests.py
sosreport-4.0/tests/plugin_tests.py
+@@ -123,36 +123,36 @@ class PluginToolTests(unittest.TestCase)
+ ['this is only a test', 'there are only two lines'])
+ test_fo = StringIO(test_s)
+ matches = regex_findall(r".*lines$", test_fo)
+-self.assertEquals(mat
Bug#1058214: sosreport: FTBFS: AttributeError: 'TailTest' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- NMU announcement
Control: forwarded -1 https://github.com/sosreport/sos/pull/3467 Control: tag -1 upstream pending Hello Lucas and Eric, I sent an upstream fix for this to the PR above. Their CI didn't even spot that error yet (argh big testing gaps). This has been open for a month now. As this threatens to make all cockpit packages fall out of testing, I'm going to do an NMU now. The package is essentially orphaned in Debian: last upload 3 years ago, VCS repo is lagging behind even more, and Ubuntu package is much newer. So I won't bother with any extra bureaucracy like delayed uploads. But of course I will attach the NMU debdiff here. Thanks, Martin
Bug#1059467: python-dbusmock: new version 0.30.1-1 causes upower's autopkgtest to fail
Control: reassign -1 upower 1.90.2-7 Control: tag -1 fixed-upstream pending The upower test adjustment landed upstream, I'll cherry-pick it into Debian. Martin
Bug#1059467: python-dbusmock: new version 0.30.1-1 causes upower's autopkgtest to fail
Control: tag -1 upstream Control: forwarded -1 https://gitlab.freedesktop.org/upower/upower/-/merge_requests/207 Hello Luca, Luca Boccassi [2023-12-26 12:46 +0100]: > Not sure whether it was a legitimate change and upower's tests need an > update, or if it is a new bug, but 0.30.1-1 causes src:upower > autopkgtest to fail and stops migration of a bunch of unrelated > packages from unstable to testing as debci bundles new packages > together when testing for regressions, and everything is held back. Thanks for the report and sorry for the trouble! This is better fixed in upower's tests IMHO. I sent a fix for upower's tests to the above MR. I'll give it three days to review (it's holiday season, after all), and will then upload the fix to Debian's upower either as a cherry-pick or a downstream patch. Martin
Bug#1057148: marked as pending in python-dbusmock
Control: tag -1 pending Hello, Bug #1057148 in python-dbusmock reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-dbusmock/-/commit/122e5ff6f4274db2d91fe315bb4a2bc78dcc5e69 Add missing python3-pytest autopkgtest dependency Closes: #1057148 (this message was generated automatically) -- Greetings https://bugs.debian.org/1057148
Bug#1027050: growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found
Hello Santiago, Santiago Vila [2023-02-18 0:26 +0100]: > Martin Pitt wrote: > > The "flock: not found" is #1014662, but that is already present in our > > current > > image with cloud-initramfs-tools 0.18.debian8, and does not seem fatal. So > > far > > the "wait-for-root: not found" seems to be the culprit? > > That's what it seems, yes. There is a fix here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014662#34 > > I've just tested it and it seems to work. I tested it as well, and confirm that it works. I left a review in the Salsa MR: https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2 Thanks! Martin
Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures
Control: tag -1 fixed-upstream pending Hello again, Martin Pitt [2022-10-26 6:04 +0200]: > Argh, this keeps haunting us. We already tried to fix that in [1] and [2], but > no way. Why must glib be so unpredictable? 😢 > [2] https://github.com/cockpit-project/cockpit/pull/17755 Nevermind.. [2] is part of release 278, and I just didn't package that yet 🙈 will do now! Martin
Bug#1022788: cockpit: FTBFS on armel/mipsel/mips64el: dh_auto_test failures
Hello Michael, hello Lis, Michael Biebl [2022-10-26 1:41 +0200]: > cockpit seems to fail its test suite on the aforementioned architectures Thanks for the report! > on armel: > ~ > Bail out! GLib-FATAL-WARNING: GChildWatchSource: Exit status of a child > process was requested but ECHILD was received by waitpid(). See the > documentation of g_child_watch_source_new() for possible causes. > > (test-channelresponse:13227): GLib-WARNING **: 11:53:58.590: > GChildWatchSource: Exit status of a child process was requested but ECHILD > was received by waitpid(). See the documentation of > g_child_watch_source_new() for possible causes. > ** Argh, this keeps haunting us. We already tried to fix that in [1] and [2], but no way. Why must glib be so unpredictable? 😢 Lis, WDYT about just running this particular check in upstream CI (env var or so?), and not during downstream `make check`? Thanks, Martin [1] https://github.com/cockpit-project/cockpit/pull/17728 [2] https://github.com/cockpit-project/cockpit/pull/17755
Bug#1016064: rpcbind: rpcbind.service fails with "cannot get uid of '_rpc': Success"
Martin Pitt [2022-07-26 11:58 +0200]: > A fresh installation of rpcbind fails to start the service: This can also be seen on package installation [1]: Setting up rpcbind (1.2.6-5) ... /usr/lib/tmpfiles.d/rpcbind.conf:2: Failed to resolve user '_rpc': No such process Martin [1] https://logs.cockpit-project.org/logs/image-refresh-3664-20220726-100606/log signature.asc Description: PGP signature
Bug#1016064: rpcbind: rpcbind.service fails with "cannot get uid of '_rpc': Success"
Package: rpcbind Version: 1.2.6-4 Severity: serious A fresh installation of rpcbind fails to start the service: systemd[1]: Starting RPC bind portmap service... rpcbind[314]: cannot get uid of '_rpc': Success systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: rpcbind.service: Failed with result 'exit-code'. systemd[1]: Failed to start RPC bind portmap service. That's because the `_rpc` user does not exist. Upgrading from an earlier image (with 1.2.6-3) works because earlier versions created it: # id _rpc uid=108(_rpc) gid=65534(nogroup) groups=65534(nogroup) Release -4 said "Remove obsolete debian/postinst file", and most of it may be obsolete, but not this bit: if [ "$1" = configure ] ; then # run daemon as non-root (see #852066) adduser --force-badname --system --quiet --home /run/rpcbind --no-create-home _rpc Please put this back. Or better yet, use systemd's User=, DynamicUser=, and RuntimeDirectory= options to contain all of the setup in the unit. Thanks! Martin signature.asc Description: PGP signature
Bug#1015068: python-dbusmock: FTBFS: AssertionError: Regex didn't match: b'[0-9.]+ Notify "fooApp" 0 "warning_icon" "title" "my text" \\[\\] {"urgency": 1} 27\n' not found in b'1657951521.419 GetServe
Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/martinpitt/python-dbusmock/pull/139
Ça va Lucas,
Lucas Nussbaum [2022-07-16 15:32 +0200]:
> > ==
> > FAIL: test_options (tests.test_notification_daemon.TestNotificationDaemon)
> > notify-send with some options
> > --
> > Traceback (most recent call last):
> > File
> > "/<>/.pybuild/cpython3_3.9/build/tests/test_notification_daemon.py",
> > line 68, in test_options
> > self.assertRegex(log, b'[0-9.]+ Notify "fooApp" 0 "warning_icon"
> > "title" "my text" \\[\\] {"urgency": 1} 27\n')
> > AssertionError: Regex didn't match: b'[0-9.]+ Notify "fooApp" 0
> > "warning_icon" "title" "my text" \\[\\] {"urgency": 1} 27\n' not found in
> > b'1657951503.818 GetServerInformation\n1657951503.819
> > GetServerInformation\n1657951503.820 Notify "fooApp" 0 "warning_icon"
> > "title" "my text" [] {"urgency": 1, "sender-pid": 168975} 27\n'
Thanks for the report! The tests need to be adjusted to the new libnotify 0.8.
I fixed this upstream, and will do a new release ASAP.
Bonne soirée,
Martin
Bug#1010958: sscg FTBFS with OpenSSL 3.0.3
Control: reassign -1 openssl 3.0.2-1 Control: affects -1 sscg 3.0.2-1 Control: tag -1 fixed-upstream Kurt Roeckx [2022-05-15 23:05 +0200]: > It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247 Indeed, thank you! Updating bug status. I see openssl 3.0.3-4 is supposed to fix that, I'll test and verify/close this bug. Martin
Bug#1010958: sscg FTBFS with OpenSSL 3.0
Control: tag -1 upstream confirmed
Control: retitle -1 sscg FTBFS with OpenSSL 3.0.3
Adrian Bunk [2022-05-14 9:48 +0300]:
> https://buildd.debian.org/status/logs.php?pkg=sscg&ver=3.0.2-1%2Bb1
>
> ...
> 1/10 generate_rsa_key_test FAIL 0.01s killed by signal 11
> SIGSEGV
> 04:32:21 MALLOC_PERTURB_=87
> /<>/obj-x86_64-linux-gnu/generate_rsa_key_test
Trivially reproducible locally, see below. It still works with the previous
3.0.2-1 version, so this is a very recent regression.
I can't tell yet whether this is a bug in sscg or OpenSSL. Fedora still has
3.0.2, so Debian is just the first distro where we noticed.
I confirm this also still happens with current upstream main (02f0a22769a6).
| ❱❱❱ gdb ./generate_rsa_key_test
| Starting program: /var/home/martin/debian/sscg/b/generate_rsa_key_test
| [Thread debugging using libthread_db enabled]
| Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
|
| Program received signal SIGSEGV, Segmentation fault.
| __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:141
| 141 ../sysdeps/x86_64/multiarch/strcmp-sse42.S: No such file or directory.
| (gdb) bt full
| #0 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:141
| No locals.
| #1 0x77d471df in EVP_PKEY_Q_keygen (libctx=libctx@entry=0x0,
propq=propq@entry=0x0, type=type@entry=0x60ef "RSA")
| at ../crypto/evp/evp_lib.c:1172
| args = {{gp_offset = 24, fp_offset = 32767, overflow_arg_area =
0x7fffe6a0, reg_save_area = 0x7fffe650}}
| bits = 93824992239747
| name =
| params = {{key = 0x0, data_type = 0, data = 0x0, data_size = 0,
return_size = 0}, {key = 0x0, data_type = 0, data = 0x0,
| data_size = 0, return_size = 0}}
| ret = 0x0
| __func__ = "EVP_PKEY_Q_keygen"
| #2 0x537f in sscg_generate_rsa_key
(mem_ctx=mem_ctx@entry=0x9300, bits=bits@entry=512,
| _key=_key@entry=0x7fffe6c8) at ../src/key.c:48
| ret =
| pkey = 0x0
| tmp_ctx = 0x0
| #3 0x51b6 in main (argc=, argv=)
at ../test/generate_rsa_key_test.c:46
| ret =
| pkey = 0x
| j =
| bits = {512, , , ,
}
| tmp_ctx = 0x9300
| (gdb)
Thanks,
Martin
Bug#1006465: marked as pending in python-dbusmock
Control: tag -1 pending Hello, Bug #1006465 in python-dbusmock reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-dbusmock/-/commit/c194f1196efc571e828809057701592b7b309379 debian/python3-dbusmock.docs: Update for README rst → md change Closes: #1006465 (this message was generated automatically) -- Greetings https://bugs.debian.org/1006465
Bug#1005004: lots of missing entries in debian/copyright
Control: tag -1 upstream pending Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/16928 I sent an upstream PR to add the missing node_modules/ copyrights. If there is anything else wrong, I'll need more information (see my previous reply). Thanks! Martin
Bug#1005004: lots of missing entries in debian/copyright
tag -1 moreinfo Hallo Thorsten, Thorsten Alteholz [2022-02-05 9:40 +]: > please rework your debian/copyright. Especially everything from node_modules > seems to be missing. Please also check other releases. The webpack bits in dist/ are autogenerated, and we have spent quite some effort to make sure that this is correct and up to date. Over the last year it shrank significantly, as we were able to drop a lot of npm modules (such as jquery, mustache, or PatternFly 3). Indeed copyright for the three node_modules/ are missing (these are test dependencies for the integration test); they are not shipped in debs, but in the source package, so they should be mentioned. That part is clear. However, your report sounds like you found other problems apart from node_modules/ -- what are they? Do you have an example? Thanks, Martin
Bug#995672: cockpit-machines: 253-1 fails to build via apt-src
Control: severity -1 normal
Control: tag -1 unreproducible moreinfo
Hello Friedemann,
Friedemann Schorer [2021-10-03 23:40 +0200]:
> Severity: serious
That feels inflated to me. The package builds fine in official buildds [1], in
upstream CI (which uses pbuilder) and locally in a debian-sid container, and it
is really quite harmless -- the build is more or less "install a bunch of
files". Also, the error message below doesn't even get to the point where it
even attempts to build c-machines, it seems to fail early in apt-src's
name-to-location mapping? So that's certainly not a regression compared to the
testing version.
[1] https://buildd.debian.org/status/package.php?p=cockpit-machines
> Got the latest source packages for cockpit-machines 253-1, unpacked them
> locally via 'dpkg-source -x', made the source known to apt-src ('apt-src
> import cockpit-machines --location cockpit-machines-253') and tried to
> build it.
> Here's the output:
>
> ~/build: apt-src list
>
> i cockpit-machin 253-1 /home/frschorer/build/cockpit-machines-253
>
> ~/build: apt-src build cockpit-machines
>
> E: Not installed
>
> When I import the sourcetree of cockpit 254-1 from unstable sources,
> too, and then try to build cockpit-machines apt-src builds the other cockpit
> packages instead.
I never used apt-src, so I'm trying to reproduce this:
sudo apt install -y apt-src
cd /tmp
apt-get source cockpit-machines
apt-src import cockpit-machines --location cockpit-machines-253/
apt-src build cockpit-machines
the latter works:
> dpkg-buildpackage: info: source package cockpit-machines
> dpkg-buildpackage: info: source version 253-1
> [...]
> dpkg-deb: building package 'cockpit-machines' in
> '../cockpit-machines_253-1_all.deb'.
> dpkg-buildpackage: info: binary-only upload (no source included)
> I: Successfully built in /tmp/cockpit-machines-253
Do these exact commands work for you? What did you do differently? How does your
~/.apt-src/status file look like? If you move it away, or try this as a
different user, what result do you get?
Thanks,
Martin
Bug#986012: fatrace: autopkgtest regression: ^rm(.*): D /tmp/autopkgtest-lxc.yky1gevw/downtmp/build.jzI/src$ not found in log
Control: tag -1 pending Paul Gevers [2021-03-27 21:43 +0100]: > https://ci.debian.net/data/autopkgtest/testing/amd64/f/fatrace/11288159/log.gz > > autopkgtest [23:08:44]: test fatrace-currentmount: [--- > ^rm(.*): D /tmp/autopkgtest-lxc.yky1gevw/downtmp/build.jzI/src$ not > found in log I finally found some time to reproduce this with [1]. I tested fatrace manually, and I don't find any way any more to get open_by_handle_at() or fanotify to work in an LXC container with the default security profile any more. As I don't have any influence over the container setting in production debci, I'm afraid my only way out is to apply "isolation-machine" to fatrace-currentmount as well. At least all the tests are runnning both in upstream and Ubuntu CI. Thanks, Martin [1] https://ci.debian.net/doc/file.MAINTAINERS.html
Bug#982613: NetworkManager triggers assert in python-dbusmock test suite
Control: reassign -1 network-manager 1.29.90-1 Control: tag -1 upstream fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/662 This eventually *did* turn out to be a bug in NetworkManager itself, and only became visible now because of the beta version number. I validated that the fix https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e1e9abdf041b4cc backports cleanly on top of 1.29.90 and fixes the assertion and the python-dbusmock tests. Thus moving this bug back to NM. I don't think this beta version should move into testing, as it's prone to cause assertion crashes in real-life situations as well. But of course Michael has the last word on this. Thanks Thomas and Michael for your help here! Martin
Bug#982613: NetworkManager triggers assert in python-dbusmock test suite
Martin Pitt [2021-02-14 11:41 +0100]: > So this is some weird NM build system issue that breaks something for any tag > (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* > tags > have version 1.27.x. I checked out tag 1.30-rc1 (aka version 1.29.0), and changed configure.ac+meson.build from 1.29.90 → 1.30.0, and voilà, it works. So it's not something specific to 28, but specific to doing a final release. Setting the version to 1.30.90 also works, and it's enough to change configure.ac, leaving meson.build alone. (Debian's package still uses automake, not meson). And here we have the explanation at last: configure.ac sets `more_asserts_default` for odd (development) minor versions, i.e. non-release versions are built with --with-more-asserts=100. So now I need to figure out what the (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) assertion is really about, and mock this harder. So reassigning to dbusmock was justified, this is not a regression in NM, and thus the autopkgtest regression should be ignored/overridden. Martin [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/configure.ac#L1066
Bug#982613: NetworkManager triggers assert in python-dbusmock test suite
Hello all, CC'ing Thomas, maybe he has some idea about this. Thomas, please see [0] for the python-dbusmock failure that triggered this bug report. Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: assertion > failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > Bail out! libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: > assertion failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > ERROR I enabled tests on Debian unstable upstream now [1] to reproduce the failure [2]. I first ran a bisect between tags 1.28.0 (which works) and 1.30-rc1 (which is release 1.29.90, and fails). Curiously that came out as "release: bump version to 1.29.0 (development) is the first bad commit". It turns out that the 1.29.0-dev branch got based off 1.28-rc1, not 1.28.0, and `git shortlog 1.28-rc1..1.28.0` has a good deal of changes. I confirmed that 1.28-rc1 itself also has that failure (otherwise I'd really be 🤯), and so does 1.28-rc2. Then I ran a bisect between 1.28-rc2 and 1.28.0, and again it resulted in the first bad version being "release: bump version to 1.28.0" [3] (which is again trivial). I used a test script [4] which builds everything from a clean git tree, and I uninstalled network-manager from the container that I'm running this in, so there are no stale files between builds. The NM dbusmock [5] does not have any version check or other version sensitive code. So this is some weird NM build system issue that breaks something for any tag (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* tags have version 1.27.x. I grepped the NM source for '1_28' and '\b1\b.*\b28\b', but that did not spot anything obvious. I also checked for '\b1\b.*\b27\b' (just in case there is some condition on <= 1.27), but that does not hit anything relevant. So at the moment I'm totally stumped about this. Thomas, are you aware of any version sensitive magic in NM's build? Thanks! Martin [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982613#5 [1] https://github.com/martinpitt/python-dbusmock/commit/8350ab65eb [2] https://github.com/martinpitt/python-dbusmock/actions/runs/565487941 [3] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/6f32c5c10736 [4] #!/bin/sh set -eux cd /tmp/NetworkManager git clean -ffdx ./autogen.sh --with-crypto=gnutls --with-iptables=/usr/sbin/iptables make -j4 clients/cli/nmcli cd /source PATH=/tmp/NetworkManager/clients/cli:$PATH PYTHONPATH=. python3 tests/test_networkmanager.py TestNetworkManager.test_one_wifi_with_accesspoints [5] https://github.com/martinpitt/python-dbusmock/blob/master/dbusmock/templates/networkmanager.py
Bug#982613: Debian Python Team
Control: reassign -1 0.22.0-1 Control: affects -1 network-manager Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: assertion > failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > Bail out! libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: > assertion failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > ERROR This is almost surely not a bug in NM itself, but that the current dbusmock does not properly emulate the new NM 1.29.90. Reassigning, I'll take a look. Martin
Bug#978310: umockdev: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1
Control: tag -1 fixed-upstream pending Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/115 Hello Lucas, Lucas Nussbaum [2020-12-26 22:57 +0100]: > > Bail out! ERROR:../tests/test-umockdev.c:1135:t_testbed_usb_lsusb: > > assertion failed (exit_status == 0): (256 == 0) I noticed that a few days as well, and someone else also noticed in https://github.com/martinpitt/umockdev/issues/115 The fix is already upstream, I'll do a new release ASAP. Thanks for your report and your continous rebuild efforts! These are much appreciated. Martin
Bug#973010: pcp is uninstallable on many architectures due to new bpftrace dependency
Package: pcp
Version: 5.2.1-1
Severity: serious
Tags: patch
The recent 5.2.1-1 upload made a dependency change to pcp:
Package: pcp
-Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, libpcp-web1
+Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, bpftrace (>= 0.9.2), libpcp-web1
But the "bpftrace" package only exists on a few architectures [1]. This is what
makes the package uninstallable and prevents testing migration [2].
Please fix
that at least by restricting the architectures, like so:
Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, bpftrace (>= 0.9.2) [amd64 arm64 ppc64 ppc64el],
libpcp-web1
Preferably you would also drop it to Recommends:, as hopefully bpftrace isn't
an absolute requirement for running PCP? I.e.
Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, libpcp-web1
Recommends: bpftrace (>= 0.9.2)
Thanks!
Martin
[1] https://packages.debian.org/sid/bpftrace
[2] https://tracker.debian.org/pkg/pcp
signature.asc
Description: PGP signature
Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input
Package: podman Version: 2.0.3+dfsg1-1 Severity: serious Tags: upsteam fixed-upstream Version 2.0.3 breaks the REST API really hard, which breaks cockpit-podman and any other API user. This is tracked here: https://github.com/containers/podman/issues/7078 This has been fixed upstream and will be in 2.0.4. I'd like to block this version from testing to avoid the regression. If you disagree and would rather get this in ASAP (given how young the package is still), I'm fine with that as well, and disable the cockpit-podman test on debian-testing for a while. Thanks, Martin
Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"
Control: retitle -1 FTBFS on IPv6-only hosts
Control: found -1 188-1
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/14098
Control: tag -1 patch upstream
Hello Aurelien,
Aurelien Jarno [2020-05-16 19:27 +0200]:
> This is an IPv6 host only,
Ah! This explains the issue indeed. I'm able to reproduce this now.
To unbreak unstable users ASAP, I uploaded a binary-all build for now.
Aurelien Jarno [2020-05-17 17:04 +0200]:
> As g_network_address_parse() supports escaping addresses with [] even
> for IPv4 addresses, I guess the following *untested* patch should fix
> the issue.
>
> --- a/src/common/test-webserver.c
> +++ b/src/common/test-webserver.c
> @@ -93,7 +93,7 @@
>/* HACK: this should be "localhost", but this fails on COPR;
> https://github.com/cockpit-project/cockpit/issues/12423 */
>tc->localport = g_strdup_printf ("127.0.0.1:%d", port);
>if (str)
> -tc->hostport = g_strdup_printf ("%s:%d", str, port);
> +tc->hostport = g_strdup_printf ("[%s]:%d", str, port);
>if (inet)
> g_object_unref (inet);
>g_free (str);
Spot on, thank you! 👏 I tested this and sent an upstream PR to fix this.
Martin
Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"
Michael Biebl [2020-05-16 12:39 +0200]: > Source: cockpit > Version: 219-1 > Severity: serious > > Hi Martin, > > looks like the latest release reliably triggers a FTBFS on arch-all: > > https://buildd.debian.org/status/logs.php?pkg=cockpit&ver=219-1&arch=all > > The relevant part from the build log > ** > cockpit-protocol:ERROR:src/common/test-webserver.c:374:perform_request: > assertion failed (error == NULL): Error resolving > ?2a02:16a8:dc41:100::238:46259?: Name or service not known > (g-resolver-error-quark, 0) > SKIP: test-webserver Bail out! > cockpit-protocol:ERROR:src/common/test-webserver.c:374:perform_request: > assertion failed (error == NULL): Error resolving > ?2a02:16a8:dc41:100::238:46259?: Name or service not known > (g-resolver-error-quark, 0) > Aborted > ERROR: test-webserver process failed: 134 Right, this seems to be an annoying mis-configuration of the new "conova" buildd. The test hasn't changed in a long time, and works fine on every other buildd, architecture, or distribution (Ubuntu, Fedora, RHEL, Arch, etc.) https://buildd.debian.org/status/logs.php?pkg=cockpit&arch=all Buildd admins, is there something weird about conova, like it resolves "localhost" to that IPv6 address, or more likely, "localhost" cannot be resolved in NSS locally and it's trying to resolve it with that DNS server? As a stopgap I'll probably do a locally built all binary upload, but I can't do it right now. Thanks, Martin
Bug#956550: src:umockdev: fails to migrate to testing for too long
Hello Paul, Paul Gevers [2020-04-12 20:35 +0200]: > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package src:umockdev in > its current version in unstable has been trying to migrate for 60 days > [2]. Hence, I am filing this bug. Whoops, thanks for the reminder! Indeed I fixed the RC bug (https://bugs.debian.org/951114) two months ago already, but typoed the "Closes #" so that the bug stayed open. I closed it now. Martin
Bug#951114: umockdev fails autopkg test with stderr output
Control: tag -1 fixed-upstream pending Hello Matthias, Matthias Klose [2020-02-11 11:45 +0100]: > autopkgtest [17:12:07]: test upstream: ---] > autopkgtest [17:12:07]: test upstream: - - - - - - - - - - results - - - - - > - > - - - - > upstream FAIL stderr: > autopkgtest [17:12:08]: test upstream: - - - - - - - - - - stderr - - - - - > - - > - - - > > ** (tests/.libs/test-umockdev:14610): WARNING **: 17:11:56.893: > umockdev.vala:1205: failed to create /tmp/umockdev.3JZ6F0/dev/link -> > /tmp/umockdev.3JZ6F0/dev/other symlink for device /devices/other: File exists > autopkgtest [17:12:08]: summary > upstream FAIL stderr: Oops! Fixed upstream: https://github.com/martinpitt/umockdev/commit/af719667e1d27352 Thanks, Martin
Bug#947712: autopkgtest regressions in python-dbusmock with newer network-manager 1.22.2-1
Hello Michael and Thomas, Michael Biebl [2020-01-08 19:42 +0100]: > > The latest update of network-manager causes an autopkgtest regression in > > python-dbusmock. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3793816/log.gz > > > > == > > FAIL: test_eth_and_wifi (__main__.TestNetworkManager) > > -- > > Traceback (most recent call last): > > File "test_networkmanager.py", line 138, in test_eth_and_wifi > > self.assertRegex(out, r'eth0.*\sdisconnected') > > AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in > > 'DEVICE TYPE STATECONNECTION \neth0ethernet unknown -- > >\nwlan0 wifi unknown -- \n' Note that this may look similar to the recent StateReason issue fixed in https://github.com/martinpitt/python-dbusmock/commit/bd51d9108e08 but it's different. python-dbusmock upstream runs tests against Fedora rawhide as well, and I just restarted a run against latest rawhide: https://travis-ci.org/martinpitt/python-dbusmock/jobs/628460969 this succeeds against NetworkManager-1:1.22.2-1.fc32.x86_64, i. e. the same NM upstream version that up uploaded into Debian. As per https://ci.debian.net/packages/p/python-dbusmock/unstable/amd64/ the first failure happened in https://ci.debian.net/data/packages/unstable/amd64/p/python-dbusmock/3694572.log against NM 1.22.0, while the last successful run was against 1.20.8. I'll investigate this more closely tomorrow. Right now my sid schroot is rather broken due to some weirdness with gnupg disappearing from the archive. Thanks, Martin
Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Hello Nathan, Nathan Scott [2020-01-07 11:18 +1100]: > Thanks for looking into this issue while we were all off, Martin and Sunil! > > To summarise where I understand things are at now: Martin's uploaded > a pcp package for rebuild which drops the python2 build steps. I think > this is fine and solves the immediate, pressing issue. My pleasure -- the NMU did probably not clean up some bits in the control.master etc. bits, but it should be good enough to get into testing and fix the RC bug/avoid being kicked out of testing indeed. > Ken and Andreas, this would mean we set Debian8 (and the equivalent > Ubuntu release) as the minimum required for Makepkgs builds. Would > that be a problem for anyone? It turns out that was the first Debian that > used systemd as the init system, so there's a possibility of several other > useful packaging cleanups if we take this path. Note that Debian 8 went EOL some time ago. There are some efforts to provide security update maintenance for it, but that doesn't mean that you still have to support it upstream -- these security updates would only do selected patch backports, not new upstream releases. Debian 9 should still be supported for roughly another half year. (See https://www.debian.org/releases/) Thanks, Martin
Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Control: tag -1 pending Hello again, Martin Pitt [2020-01-05 10:54 +0100]: > > I ran into similar issue when attempting to build with multiple parallel > > tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this > > turned on, please try disabling it. > > I indeed had that option set, thanks for pointing out! pcp's packaging is > rather complex and debian/rules rather old-fashioned and hard to understand, > and apparently doesn't get along well with parallel builds. This RC bug fix is > not the time for more intrusive changes though, so let's ignore this for now > indeed. > > However, even with unsetting it it still fails: Nevermind, I also had MAKEVARS=-j4 set, which caused this issue. I now uploaded this as an NMU to DELAYED/3, using the exact patch that I attached yesterday. Thanks, Martin
Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Hello Sunil, Sunil Mohan Adapa [2020-01-04 12:15 -0800]: > > This file doesn't exist anywhere -- apparently src/include/builddefs.install > > builds it, but at this point this is pretty deeply woven into the build > > system. > > Curiously, resuming the build with "make" and "dpkg-buildpackage -us -uc > > -b -nc" > > gets over that, but then in the end it still fails with > > I believe the rm commands run during cleanup. I suspect the source is > not conducive to running multiple build/cleanup cycles. It's the other way around -- I always started from a clean tree. I wanted to debug that further, which is why I ran `make` and a `-nc` build, and noticed that it then made further progress. > I ran into similar issue when attempting to build with multiple parallel > tasks with DEB_BUILD_OPTIONS=parallel=8 or with -j8. If you have this > turned on, please try disabling it. I indeed had that option set, thanks for pointing out! pcp's packaging is rather complex and debian/rules rather old-fashioned and hard to understand, and apparently doesn't get along well with parallel builds. This RC bug fix is not the time for more intrusive changes though, so let's ignore this for now indeed. However, even with unsetting it it still fails: > mv: cannot stat 'Makefile.fix': No such file or directory > make[4]: Makefile: No such file or directory > make[4]: *** No rule to make target 'Makefile'. Stop. > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 I can't get around this failure in my sid chroot. And I don't want to embarrass myself by doing a source-only NMU with hoping that it works on the buildds.. Thanks, Martin
Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Hello, Sunil Mohan Adapa [2020-01-01 19:29 -0800]: > Debian build servers are unable to build the latest Debian package of pcp > uploaded to repositories: 5.0.2-1 [1]. As a consequence, pcp and it's > dependencies cockpit and freedombox are at threat of being removed from Debian > testing on January 10, 2020 [2]. > > This is due to incorrect invocation of dh_python2 which is no longer available > on these build machines. Right, as the previous upload (rightfully) dropped the py2 build deps. I attach a first debdiff, but it doesn't work yet. The package build fails later on with | === src === | rm -f Makefile.new Makefile.fix; CFLAGS='-fPIC -fno-strict-aliasing -D_GNU_SOURCE -Wall -O2 -g -DPCP_VERSION=\"5.0.2\" -I../../../src/include -I../../../src/include/pcp' CXXFLAGS='' LDFLAGS=' -Wall -L../../../src/libpcp/src -L../../../src/libpcp_web/src -L../../../src/libpcp_pmda/src ' QT_SELECT=5 /usr/bin/qmake -o Makefile.new CONFIG+=release && sed -e 's/Makefile.new/Makefile/g' Makefile.fix && ( if [ -f Makefile ]; then if diff Makefile Makefile.fix >/dev/null; then :; else rm -f Makefile; mv Makefile.fix Makefile; fi; else mv Makefile.fix Makefile; fi ); rm -f Makefile.new Makefile.fix; /usr/bin/make --no-print-directory -f Makefile | rm -f Makefile.new Makefile.fix; CFLAGS='-fPIC -fno-strict-aliasing -D_GNU_SOURCE -Wall -O2 -g -DPCP_VERSION=\"5.0.2\" -I../../../src/include -I../../../src/include/pcp' CXXFLAGS='' LDFLAGS=' -Wall -L../../../src/libpcp/src -L../../../src/libpcp_web/src -L../../../src/libpcp_pmda/src ' QT_SELECT=5 /usr/bin/qmake -o Makefile.new CONFIG+=release && sed -e 's/Makefile.new/Makefile/g' Makefile.fix && ( if [ -f Makefile ]; then if diff Makefile Makefile.fix >/dev/null; then :; else rm -f Makefile; mv Makefile.fix Makefile; fi; else mv Makefile.fix Makefile; fi ); rm -f Makefile.new Makefile.fix; /usr/bin/make --no-print-directory -f Makefile | diff: Makefile: No such file or directory | make[5]: Makefile: No such file or directory | mv: cannot stat 'Makefile.fix': No such file or directory This file doesn't exist anywhere -- apparently src/include/builddefs.install builds it, but at this point this is pretty deeply woven into the build system. Curiously, resuming the build with "make" and "dpkg-buildpackage -us -uc -b -nc" gets over that, but then in the end it still fails with | dpkg-deb: building package 'pcp-import-sar2pcp' in '../pcp-import-sar2pcp_5.0.2-1.1_all.deb'. | dpkg-deb: building package 'pcp-import-mrtg2pcp' in '../pcp-import-mrtg2pcp_5.0.2-1.1_all.deb'. | dpkg-deb: building package 'pcp-import-iostat2pcp' in '../pcp-import-iostat2pcp_5.0.2-1.1_all.deb'. | dpkg-deb: building package 'pcp-doc' in '../pcp-doc_5.0.2-1.1_all.deb'. | dpkg-deb: building package 'pcp-import-sheet2pcp' in '../pcp-import-sheet2pcp_5.0.2-1.1_all.deb'. | dpkg-deb: building package 'pcp-import-ganglia2pcp' in '../pcp-import-ganglia2pcp_5.0.2-1.1_all.deb'. | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 without any apparent error message (the dh_builddeb -i itself succeeds). As pcp and its reverse dependencies are very close to being kicked out of testing (in 6 days), I'm interested in doing an NMU. However, with the above build system trouble, it may be necessary to fix this upstream first? Thanks, Martin diff -Nru pcp-5.0.2/debian/changelog pcp-5.0.2/debian/changelog --- pcp-5.0.2/debian/changelog 2019-12-04 03:00:17.0 + +++ pcp-5.0.2/debian/changelog 2020-01-04 09:58:40.0 + @@ -1,3 +1,11 @@ +pcp (5.0.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop remaining python2 build commands (closes: #947916) + * Build-depend on python3-all-dev for the py3 extension build. + + -- Martin Pitt Sat, 04 Jan 2020 09:58:40 + + pcp (5.0.2-1) unstable; urgency=low * New release (full details in CHANGELOG). diff -Nru pcp-5.0.2/debian/control pcp-5.0.2/debian/control --- pcp-5.0.2/debian/control2019-12-10 20:52:01.0 + +++ pcp-5.0.2/debian/control2020-01-04 09:58:40.0 + @@ -4,10 +4,9 @@ Homepage: https://pcp.io Maintainer: PCP Development Team Uploaders: Nathan Scott , Eric Desrochers , Ken McDonell -Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python3-all, python3-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libuv1-dev, libavahi-common-dev, qtbase5-dev, qtbase5-dev-tools, libqt5svg5-dev, qtchooser, autotools-dev, zlib1g-dev, autoconf, libclass-
Bug#937260: [pcp] Bug#937260: Offering NMU
Hello Nathan, Nathan Scott [2019-12-02 10:51 +1100]: > Thanks! I've updated the PCP deb builds in the upstream PCP repo and plan > to close this issue out with the pcp-5.0.2 release (scheduled for Wed 11th). > If > you need the fix sooner though, feel free to NMU. Nice, thanks! That's soon enough for sure, pcp's autoremoval is currently scheduled for Jan 1. Martin
Bug#937260: Offering NMU
Hello, I just checked that python-pcp has zero reverse build and binary dependencies, so it's fine to just drop it and thus fix this RC bug. If you don't have time, I'm happy to do an NMU for this (as cockpit maintainer I don't want cockpit to get dropped from testing due to pcp disappearing). Thanks, Martin
Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency
Hello Jussi, Olly, Olly Betts [2019-10-27 11:52 +1300]: > However, then the build fails for me running tests using ccache - the > problem is that $HOME is /sbuild-nonexistent under sbuild, which > doesn't exist, and cache tries to create its cache under $HOME/.ccache > by default. I don't have that, but I also have failing tests. > [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 > simple/spin.pcf' spin.blif -o spin.asc > FAILED: spin.asc > /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' > spin.blif -o spin.asc > spin.blif:50: fatal error: invalid formal-actual > ninja: build stopped: subcommand failed. For me, fpga also fails, but the failure looks different: Found ninja-1.9.0 at /usr/bin/ninja [0/1] /usr/bin/python3 /tmp/meson-0.52.0/meson.py --internal regenerate '/tmp/meson-0.52.0/test cases/fpga/1 simple' '/tmp/meson-0.52.0/b 2eab81bce2' --backend ninja The Meson build system Version: 0.52.0 Source dir: /tmp/meson-0.52.0/test cases/fpga/1 simple Build dir: /tmp/meson-0.52.0/b 2eab81bce2 Build type: native build Project name: lattice Project version: undefined C compiler for the host machine: cc (gcc 9.2.1 "cc (Debian 9.2.1-14) 9.2.1 20191025") C linker for the host machine: GNU ld.bfd 2.33.1 Host machine cpu family: x86_64 Host machine cpu: x86_64 Build targets in project: 5 Found ninja-1.9.0 at /usr/bin/ninja [1/3] /usr/bin/yosys -q -p 'synth_ice40 -blif spin.blif' '../test cases/fpga/1 simple/spin.v' [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' spin.blif -o spin.asc FAILED: spin.asc /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf' spin.blif -o spin.asc spin.blif:50: fatal error: invalid formal-actual ninja: build stopped: subcommand failed. ninja explain: output build.ninja older than most recent input ../test cases/fpga/1 simple/meson.build (1572245204477705522 vs 1572245204489705475) ninja explain: output spin.blif doesn't exist ninja explain: spin.blif is dirty ninja explain: spin.asc is dirty ninja explain: spin.bin is dirty This is an up to date Debian sid amd64 chroot, with /dev/shm bind-mounted from the host (otherwise it fails way earlier). So I'm afraid I can't upload this either :/ Martin
Bug#919390: Bug #919390 in systemd marked as pending
Control: tag -1 pending Hello, Bug #919390 in systemd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/systemd-team/systemd/commit/40df7df1f6c4812fa7b074c5d48dcfce6ce8a782 Backport upstream patch reverting interface renaming changes. Closes: #919390 (this message was generated automatically) -- Greetings https://bugs.debian.org/919390
Bug#920018: Bug #920018 in systemd marked as pending
Control: tag -1 pending Hello, Bug #920018 in systemd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/systemd-team/systemd/commit/59be1833846225c29a5241fdc63e02ac9fa60a84 process-util: Fix memory leak Closes: #920018 (this message was generated automatically) -- Greetings https://bugs.debian.org/920018
Bug#920018: Please give this bug attention.
Hello Nye, Nye Liu [2019-01-23 14:16 -0800]: > Please apply https://github.com/systemd/systemd/pull/11527 It's in the pipeline now, I need to sort out some git paperwork issue with Felipe. But either way, I'll upload the fix tomorrow. (Sorry, just back from meeting/devconf.cz week with essentially ignoring all email) Martin
Bug#919390: Bug #919390 in systemd marked as pending
Hello Felipe, Felipe Sateler [2019-01-26 0:04 +]: > Bug #919390 in systemd reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/systemd-team/systemd/commit/ca9bf5fdd69e1f6bb137d905f90225de7fc057e4 > > > Pick patch proposed upstream to reduce journald memory usage > > Closes: #919390 This should have been #920018. I was about to do the cherry-picks, but I'm really confused here. Where *did* your two commits land? They are clearly not on master, and there are no other (recent) branches. Even trying to show the SHA directly doesn't work (no such object). Did you force-unpush them? Or was this an unnamed branch somehow? Should I pick them from the salsa web UI and push them to master (and fixing the bug number while I'm at it), and upload? Thanks! Martin
Bug#919799: cockpit: FTBFS (failing tests)
Control: retitle -1 FTBFS without a loopback inet device Control: severity -1 normal Hello Santiago, Santiago Vila [2019-01-19 17:35 +]: > I tried to build this package in buster but it failed: This fails a lot of tests like this: | cockpit-protocol:ERROR:src/common/test-webserver.c:57:setup: assertion failed: (inet != NULL) | FAIL: test-webserver 2 /web-server/query-string This is due to the build environment not having a loopback inet device. I don't consider this an RC bug, it's IMHO really a broken environment. Martin
Bug#918439: cockpit: FTBFS (failing tests)
Hello Santiago, Santiago Vila [2019-01-13 13:37 +0100]: > > Indeed, this points out a broken build environment that doesn't have a > > loopback > > device. [...] > > No, not the case. This used to build ok in the past in my autobuilders: The loopback issue does not affect *your* builds. E. g. https://people.debian.org/~sanvila/build-logs/cockpit/cockpit_184-1_amd64-20190105T051830.660Z only has failed ssh tests, which are due to #918892. That part applied to the failing tests from the reproducible-builds machines that Andreas investigated. > Status: successful cockpit_184-1_amd64-20181226T121643.534Z > Status: failed cockpit_184-1_amd64-20190105T051830.660Z Which matches the upload of libssh 0.8.6. Thanks, Martin
Bug#918439: cockpit: FTBFS (failing tests)
Control: block -1 by bug 918892
Hello Santiago, Andreas,
Andreas Henriksson [2019-01-12 21:41 +0100]:
> > # FAIL: 31
>
> Lots of failing tests there
Right, but they have two different root causes. The first is bug 918892, a
recent regression in libssh 0.8.6, which causes all the cockpit-ssh unit tests
to fail, e. g.:
| cockpit-ssh-Message: 07:28:13.450: cockpit-ssh 127.0.0.1:46795: -1 couldn't
connect: Public key from server (rsa-sha2-512) doesn't match user preference
(ssh-rsa,ssh-dss,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256)
'127.0.0.1' '46795'
| **
| ERROR:src/ssh/test-sshbridge.c:515:wait_until_transport_init: assertion
failed (problem == expect_problem): ("no-host" == NULL)
Thus blocking this bug bug by that, and I bumped 918892 to RC as well.
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cockpit.html
>
> I just looked at the first one and it fails here:
>
> $ head -n 57 src/common/test-webserver.c | tail -n 2
> inet = cockpit_test_find_non_loopback_address ();
> g_assert (inet != NULL);
>
> I'm thus going to assume that the build environments that runs into
> these problems uses network namespaces or similar and doesn't expose
> anything but loopback to the build chroot.
Indeed, this points out a broken build environment that doesn't have a loopback
device. But this isn't new, nor happens on the official buildds (nor in local
schroot), and thus isn't an RC bug.
Thanks,
Martin
Bug#907341: umockdev: autopkgtest regression: g_path_get_dirname: assertion 'file_name != NULL' failed
Control: tag -1 fixed-upstream Hello Paul and Jeremy, Thanks for the report and the reminder. Indeed I investigated this problem a while ago and fixed it upstream: https://github.com/martinpitt/umockdev/commit/a95afb886945c2df https://github.com/martinpitt/umockdev/commit/45b6dc5d1d5db I just forgot to do a release, will do this ASAP! Martin signature.asc Description: PGP signature
Bug#906049: Broken Version: in pkg-config file
Package: libssh-dev Version: 0.8.0-1 Severity: serious The new libssh's pkg-config file is broken, it has an empty version: | $ pkg-config --modversion libssh | $ grep Version /usr/lib/x86_64-linux-gnu/pkgconfig/libssh.pc | Version: The previous version, still in testing, is correct: | $ pkg-config --modversion libssh | 0.7.5 | $ RC bug as this causes depending packages to FTBFS, e. g. cockpit: | checking for LIBSSH... no | configure: error: Package requirements (libssh >= 0.6.0) were not met: | | Requested 'libssh >= 0.6.0' but version of libssh is Thanks, Martin
Bug#895978: FSHS violation: systemd-timesyncd installed in /lib
Control: tag -1 moreinfo
Hello Thomas,
Thomas Goirand [2018-04-18 9:36 +0200]:
> Package: systemd
> Version: 232-25+deb9u2
> Severity: serious
What is the rationale for this being release-critical?
> Doing my everyday $work, I found that a machine had systemd-timesyncd
> installed. To the contrary of a lot of people, I don't really mind it,
> if it does the job. Though it got installed in
> /lib/systemd/systemd-timesyncd. This makes no sense for a daemon, that
> must be installed in /bin (if needed at boot time) or in /usr/bin
> (more likely).
This isn't a program which you are supposed to run on the command line, so
putting it into $PATH makes no sense. This is a typical example of a program
that should be in LIBEXECDIR, which is {,/usr}/lib/ in Debian.
So it can certainly be argued that this (and a lot of similar programs) should
move to /usr/lib/systemd/systemd-timesyncd instead of /lib, but that doesn't
seem to be release critical to me. I can't find a Debian Policy requirement
that would mandate this, but maybe I'm overlooking something.
Martin
Bug#863784: policykit-1: Please drop dependency against mozjs 1.8.5
Control: tag -1 -buster bi...@debian.org [2017-05-31 9:24 +0200]: > Source: policykit-1 > Version: 0.113-2 > Severity: normal > Tags: sid buster > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: oldlibs mozjs185 > > Dear maintainer, > > Your package is depending against mozjs 1.8.5. This package is old > and currently orphaned. Removing buster tag, as this version is only in experimental - for exactly this reason. We really don't want policykit to use mozjs in any release, both for maintenance/security reasons and also because it's a rather bad idea in general to have a touring complete and weakly-typed language to describe security properties instead of the current declarative rules. Martin
Bug#886203: FTBFS: dh: unable to load addon scour
Adrian Bunk [2018-01-23 16:53 +0200]: > > ... so that after > > the buster release I can remove the python-scour → scour dependency again. > > Nitpick: > After buster python-scour will be removed (no Python 2 in bullseye). So much the better! /me starts sharpening the knife :-) Martin
Bug#886203: FTBFS: dh: unable to load addon scour
Control: tag -1 pending Hello Adrian and all, Adrian Bunk [2018-01-23 7:54 +0200]: > This is actually a bug in scour, where the scour binary and debhelper > addon moved from python-scour to python3-scour. > > Neither is the right place. > > scour should go into an own binary package of the same name, > and the debhelper addon could also go there. > > For properly handling stretch->buster upgrades, python-scour should > depend on the new scour package. Agreed, sorry for the troubles. Done in https://anonscm.debian.org/cgit/collab-maint/scour.git/commit/?id=d3a95f82d449 I uploaded 0.36-2, it will hit the binNEW queue soon. After it's in, I'll file bug reports against reverse dependencies to move to "scour", so that after the buster release I can remove the python-scour → scour dependency again. Martin
Bug#871060: umockdev: FTBFS: Test failures
Control: tag -1 pending fixed-upstream
Control: forwarded -1
https://github.com/martinpitt/umockdev/commit/33ef8438abd779
Lucas Nussbaum [2017-08-06 18:08 -0400]:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> > ERROR:tests/test-umockdev.c:1236:t_testbed_dev_query_gudev: assertion
> > failed (g_udev_device_get_sysfs_path(device) == "/sys/devices/stream"):
> > ("/sys/dev/char/../../devices/stream" == "/sys/devices/stream")
Seems this is a behaviour change in udev. Fixed upstream.
Thanks,
Martin
Bug#869934: cockpit: Incomplete debian/copyright?
Hey Chris, Chris Lamb [2017-07-28 7:56 +0100]: > > That's only for the bundled JavaScript modules. > > I don't have the package in front of me right now but I think > the other issue was that d/copyright was mentioning .JS but in > the wrong location (node_modules/ vs. dist/ IIRC). Again this > is from memory so disregard if I'm wrong :) It's not wrong - node_modules/ has the original modules (i. e. preferred form of modification). The topmost comment in d/copyright tries to explain this: This does not directly cover the files in dist/*. These are "minified" and compressed JavaScript/HTML files built from pkg/* and node_modules/* with node, npm, and webpack. Their copyrights and licenses are described below. Rebuilding these requires internet access as that process needs to download additional npm modules from the Internet, thus upstream ships the pre-minified webpacks as part of the upstream release tarball so that the package can be built without internet access and lots of extra unpackaged build dependencies. The upstream tarballs ship dist/ it to relieve downstreams from having to build-depend on and call webpack during the package build (unless they want to patch). So its similar to pre-generated PDF documentation or autotools Makefiles. If that's unclear, I'm happy to improve the wording? Thanks, Pitti
Bug#869934: cockpit: Incomplete debian/copyright?
Control: found -1 146-1 Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/7397 Hello Chris, Chris Lamb [2017-07-27 21:11 +0100]: > I just ACCEPTed cockpit from NEW but noticed it was missing > attribution in debian/copyright for at least Nokia in mock-io-stream.c. Thanks for spotting! > (This is not exhaustive so please check over the entire package > carefully and address these on your next upload.) I went over the source again with a reasonably fine comb: git grep -i copyright | grep -Ev 'COPYING:|Red Hat' and spotted mock-io-stream.c and a few others. PR sent (see above). > I see there is some script to generate debian/copyright; perhaps it needs > to be re-run, I'm not sure.. :) That's only for the bundled JavaScript modules. It does get run with each upstream PR and release, and as soon as an upstream PR changes the included modules in a way that breaks automatic license detection it will fail CI, so I'm reasonably sure on that part. But this doesn't cover the C code in src/. Thanks, Martin
Bug#868379: calibre breaks with recent python-dateutil
Hello Manolo, Manolo Díaz [2017-07-16 18:36 +0200]: > > So calibre should clean up *.pyc files (probably from ancient > > installations) in /usr/lib/calibre. > > Cheers, > > -- Guido > > It would help, but I think it isn't enough. Given the following > sequence calibre would have failed to start. > > - upgrade or reinstall calibre (all *.pyc are cleaned up) > - run calibre as root (they are created again) > - upgrade python-dateutil. I don't think that there's much that a Python application package can do about it. Cleaning up the pyc files on package upgrades should alleviate this (I'll add that to the packaging), but I figure the mch better solution here is "don't run calibre as root". Martin
Bug#866102: calibre: Calibre-server fails to start with missing dependancy
Control: tag -1 pending dmm [2017-06-27 21:21 +1000]: > I recently upgraded from calibre 2.75 to 3.1.1, after the upgrade > calibre-server would not run. > > Appears there was a missing dependancy, fixed with > > # apt-get install python-msgpack Whoops, sorry about that! Fixed in git, will upload soon. Thanks, Martin
Bug#860637: mkosi: FTBFS on i386: help2man: can't get `--help' info from ./mkosi
Andreas Henriksson [2017-04-19 14:48 +0200]: > I've tried to reproduce this but failed. I'm using an amd64 stretch > install as a base, with a newly debootstrapped --arch=i386 > --variant=minbase chroot where I installed mkosi build-deps, fetched > mkosi sources and ran debian/rules binary. > I've also tried to manually check return codes (0) and mkosi --help > output (stdout). Nothing peculiar noticed. Does it help to run "linux32 chroot.." or "linux32 mkosi --help" to set the right (32 bit) personality? Supposedly it's doing `uname -m` somewhere. Martin
Bug#853755: Bug#852811: fixed in systemd 232-16
Hello Breno, Breno Leitao [2017-02-14 11:14 -0200]: > Are you going to move systemd to 232-16 or backport the patch to stretch > 232-15? Yes, we'll give -18 a few days to settle in unstable, then I'll ask the release team for letting it in. Martin
Bug#855050: systemd: systemctl regressions, assertion failure with "--user enable" without HOME, and more
Control: tag -1 pending Control: severity -1 important Raphaël Hertzog [2017-02-13 16:39 +0100]: > Severity: serious That seems grossly inflated, adjusting. > Any invocation of "systemctl --user enable/disable" will fail if > XDG_RUNTIME_DIR is not set while it's strictly not required to do > its job. > > The same pull request also fixes other regressions where you can't > properly track processes of a unit that has been removed or even > disable that dropped unit. > > https://github.com/systemd/systemd/pull/5303 I cherry-picked some appropriate ones which are relatively straightforward and safe for the freeze: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=7864ad6a6 https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=cb8df0e367064 Martin
Bug#853004: security: javascript in the book can access files on the computer using XMLHttpRequest?
Hello Salvatore, Salvatore Bonaccorso [2017-01-31 17:15 +0100]: > This has been assigned CVE-2016-10187, in Want me to upload the previously sent patch to the queue (with adding the CVE to the patch/changelog)? Martin
Bug#853004: security: javascript in the book can access files on the computer using XMLHttpRequest?
Hello Antoine,
Antoine Beaupré [2017-01-29 10:48 -0500]:
> Next time could you coordinate more closely with the security team?
Point taken, sorry about that.
> 3. (optionnally) request a CVE at OSS-security with a CC upstream:
>http://oss-security.openwall.org/wiki/mailing-lists/oss-security
Mail sent, you were in CC. Kovid (upstream) already made the original bug
public, which has a reproducer.
> 5. (optionnally) help the security team backporting the patch to stable
>and (even more optionnally) to Debian LTS
Stretch debdiff with the backported patch attached, this still has some es
for the pending CVE.
Martin
diff -Nru calibre-2.5.0+dfsg/debian/changelog
calibre-2.5.0+dfsg/debian/changelog
--- calibre-2.5.0+dfsg/debian/changelog 2014-10-12 22:43:15.0 +0200
+++ calibre-2.5.0+dfsg/debian/changelog 2017-01-29 17:42:15.0 +0100
@@ -1,3 +1,11 @@
+calibre (2.5.0+dfsg-1+deb8u1) stable-security; urgency=medium
+
+ * Add js_no_local_file_access.patch: E-book viewer: Prevent javascript in
+the book from accessing files on the computer using XMLHttpRequest.
+Patch backported from 2.75.1. (CVE--, Closes: #853004)
+
+ -- Martin Pitt Sun, 29 Jan 2017 17:42:15 +0100
+
calibre (2.5.0+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru calibre-2.5.0+dfsg/debian/patches/js_no_local_file_access.patch
calibre-2.5.0+dfsg/debian/patches/js_no_local_file_access.patch
--- calibre-2.5.0+dfsg/debian/patches/js_no_local_file_access.patch
1970-01-01 01:00:00.0 +0100
+++ calibre-2.5.0+dfsg/debian/patches/js_no_local_file_access.patch
2017-01-29 17:42:10.0 +0100
@@ -0,0 +1,45 @@
+From 3a89718664cb8cce0449d1758eee585ed0d0433c Mon Sep 17 00:00:00 2001
+From: Kovid Goyal
+Date: Wed, 21 Dec 2016 17:59:00 +0530
+Subject: [PATCH] E-book viewer: Prevent javascript in the book from accessing
+ files on the computer using XMLHttpRequest. Fixes #1651728 [Private
+ bug](https://bugs.launchpad.net/calibre/+bug/1651728)
+
+---
+ src/calibre/gui2/tweak_book/preview.py | 2 ++
+ src/calibre/gui2/viewer/documentview.py | 3 +--
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+Bug: https://launchpad.net/bugs/1651728
+Bug-Debian: https://bugs.debian.org/853004
+
+Index: calibre-2.5.0+dfsg/src/calibre/gui2/tweak_book/preview.py
+===
+--- calibre-2.5.0+dfsg.orig/src/calibre/gui2/tweak_book/preview.py
calibre-2.5.0+dfsg/src/calibre/gui2/tweak_book/preview.py
+@@ -261,6 +261,7 @@ class WebPage(QWebPage):
+ settings.setAttribute(settings.PrivateBrowsingEnabled, True)
+ settings.setAttribute(settings.JavascriptCanOpenWindows, False)
+ settings.setAttribute(settings.JavascriptCanAccessClipboard, False)
++settings.setAttribute(settings.LocalContentCanAccessFileUrls, False)
# ensure javascript cannot read from local files
+ settings.setAttribute(settings.LinksIncludedInFocusChain, False)
+ settings.setAttribute(settings.DeveloperExtrasEnabled, True)
+ settings.setDefaultTextEncoding('utf-8')
+Index: calibre-2.5.0+dfsg/src/calibre/gui2/viewer/documentview.py
+===
+--- calibre-2.5.0+dfsg.orig/src/calibre/gui2/viewer/documentview.py
calibre-2.5.0+dfsg/src/calibre/gui2/viewer/documentview.py
+@@ -109,6 +109,7 @@ class Document(QWebPage): # {{{
+ settings.setAttribute(QWebSettings.PluginsEnabled, False)
+ settings.setAttribute(QWebSettings.JavascriptCanOpenWindows, False)
+ settings.setAttribute(QWebSettings.JavascriptCanAccessClipboard,
False)
++settings.setAttribute(QWebSettings.LocalContentCanAccessFileUrls,
False) # ensure javascript cannot read from local files
+
+ # Miscellaneous
+ settings.setAttribute(QWebSettings.LinksIncludedInFocusChain, True)
+@@ -1315,5 +1316,3 @@ class DocumentView(QWebView): # {{{
+ return ret
+
+ # }}}
+-
+-
diff -Nru calibre-2.5.0+dfsg/debian/patches/series
calibre-2.5.0+dfsg/debian/patches/series
--- calibre-2.5.0+dfsg/debian/patches/series2014-10-12 22:43:15.0
+0200
+++ calibre-2.5.0+dfsg/debian/patches/series2017-01-29 17:39:08.0
+0100
@@ -1,4 +1,5 @@
# cherrypicked from/accepted into trunk:
+js_no_local_file_access.patch
# sent upstream
signature.asc
Description: PGP signature
Bug#853004: security: javascript in the book can access files on the computer using XMLHttpRequest?
Control: notfound -1 2.75.1+dfsg-1 Hello Antoine, Antoine Beaupre [2017-01-28 15:56 -0500]: > Someone pointed me to this note in the 2.75.1 changelog: > > E-book viewer: Prevent javascript in the book from accessing files > on the computer using XMLHttpRequest. I did mention this in the 2.75.1 changelog (https://tracker.debian.org/news/827355), so marking as fixed in the current testing/unstable version. The corresponding upstream commit is: https://github.com/kovidgoyal/calibre/commit/3a89718664cb8c Martin
Bug#846719: umockdev: FTBFS: Test failures
Control: tag -1 unreproducible help
Control: severity -1 important
Hello Lucas,
first, thanks for running these rebuild tests!
Lucas Nussbaum [2016-12-03 8:44 +0100]:
> > ERROR:tests/test-umockdev-run.c:1550:t_input_touchpad: assertion failed
> > (_tmp52_ == ""): ("Unable to connect to X server\n" == "")
> > /bin/bash: line 1: 93517 Aborted TOP_BUILDDIR=.
> > TOP_SRCDIR=. LD_LIBRARY_PATH=./.libs:$LD_LIBRARY_PATH GI_TYPELIB_PATH=.
> > PATH=./src:$PATH G_SLICE=debug-blocks MALLOC_PERTURB_=85 MALLOC_CHECK_=3
> > ./src/umockdev-wrapper $f
I tried to run a complete package build in a clean sbuild sid environment, and
also ran the test in a loop:
| $ for i in `seq 100`; do PATH=src:$PATH LD_LIBRARY_PATH=.libs
src/umockdev-wrapper tests/test-umockdev-run -p
/umockdev-run/integration/input-touchpad; done
| /umockdev-run/integration/input-touchpad: OK
| [...]
and I'm afraid I'm unable to reproduce this. Indeed this is the only test that
spawns an X.org server with the dummy driver:
https://anonscm.debian.org/cgit/collab-maint/umockdev.git/tree/tests/test-umockdev-run.vala#n443
so that it can run that under umockdev and verify that the input devices get
simulated correctly. This already waits until /tmp/.X11-unix/X5 exists, which
AFAIK is the official signal from X.org that it started up sufficiently to
allow clients to connect to it. This obviously worked, as otherwise the test
would show "SKIP: Xorg failed to start up..." (and not fail).
Can you reproduce this somehow (particularly with the above loop, in a built
tree)? If you can, it would be great if you could try and add
Posix.sleep (2);
after the loop that polls for the socket, i. e. to line 492. If that helps,
then it's a race condition with X.org's startup, if it does not help then
the dummy Xorg server is somehow broken in that environment.
Since this is unreproducible and it doesn't seem to happen on the Debian
builders either, I downgrade to important. If you disagree, feel free to bump
it back, but I don't think this is a sufficient reason to kick it out of
testing.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#843145: files with the same name installed in / and /usr -- NMUed
Hello again,
Martin Pitt [2016-11-09 10:24 +0100]:
> I pushed the fix now:
>
>
> https://anonscm.debian.org/cgit/collab-maint/json-c.git/commit/?id=bf85685a69
>
> (without changelog as you apparently do that on release time).
>
> > (I'd also fix the broken Vcs-Browse: field while I'm at it).
>
> Done as well:
>
>
> https://anonscm.debian.org/cgit/collab-maint/json-c.git/commit/?id=2873190fdf
I uncommitted these, as even that branch is out of date: it has
0.12-3, but testing/unstable have 0.12.1-1.
> I uploaded this as an NMU to DELAYED/5, with the attached "release"
> commit. I will push this to git if and when this lands.
As there is no git branch that corresponds to reality, I attach the
NMU debdiff.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
diff -Nru json-c-0.12.1/debian/changelog json-c-0.12.1/debian/changelog
--- json-c-0.12.1/debian/changelog 2016-09-02 10:28:57.0 +0200
+++ json-c-0.12.1/debian/changelog 2016-11-14 11:33:17.0 +0100
@@ -1,3 +1,12 @@
+json-c (0.12.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/control: Fix Vcs-Browser URL
+ * debian/libjson-c-dev.links: Fix library symlinks to not collide between
+ /lib/ and /usr/lib/ (Closes: #843145, LP: #1629552)
+
+ -- Martin Pitt Mon, 14 Nov 2016 11:33:17 +0100
+
json-c (0.12.1-1) unstable; urgency=medium
* Imported Upstream version 0.12.1
diff -Nru json-c-0.12.1/debian/control json-c-0.12.1/debian/control
--- json-c-0.12.1/debian/control2016-09-02 10:28:57.0 +0200
+++ json-c-0.12.1/debian/control2016-11-14 11:33:10.0 +0100
@@ -10,7 +10,7 @@
Section: libs
Homepage: https://github.com/json-c/json-c/wiki
Vcs-Git: git://anonscm.debian.org/git/collab-maint/json-c
-Vcs-Browser: http://anonscm.debian.org/?p=collab-maint/json-c.git;a=summary
+Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/json-c.git
Package: libjson-c3
Architecture: any
diff -Nru json-c-0.12.1/debian/libjson-c-dev.links
json-c-0.12.1/debian/libjson-c-dev.links
--- json-c-0.12.1/debian/libjson-c-dev.links2016-09-02 10:28:57.0
+0200
+++ json-c-0.12.1/debian/libjson-c-dev.links2016-11-14 11:33:10.0
+0100
@@ -1,3 +1,2 @@
#!/usr/bin/dh-exec
-/lib/${DEB_HOST_MULTIARCH}/libjson-c.so.3
/usr/lib/${DEB_HOST_MULTIARCH}/libjson-c.so.3
-/usr/lib/${DEB_HOST_MULTIARCH}/libjson-c.so.3
/usr/lib/${DEB_HOST_MULTIARCH}/libjson-c.so
+/lib/${DEB_HOST_MULTIARCH}/libjson-c.so.3
/usr/lib/${DEB_HOST_MULTIARCH}/libjson-c.so
signature.asc
Description: PGP signature
Bug#843145: files with the same name installed in / and /usr -- NMUed
Control: tag -1 pending Hello again, Martin Pitt [2016-11-07 23:22 +0100]: > # head /lib/x86_64-linux-gnu/libjson-c.so.3 > head: cannot open '/lib/x86_64-linux-gnu/libjson-c.so.3' for reading: Too > many levels of symbolic links > > Thus bumping severity. I'm happy to do an NMU if you don't have time I pushed the fix now: https://anonscm.debian.org/cgit/collab-maint/json-c.git/commit/?id=bf85685a69 (without changelog as you apparently do that on release time). > (I'd also fix the broken Vcs-Browse: field while I'm at it). Done as well: https://anonscm.debian.org/cgit/collab-maint/json-c.git/commit/?id=2873190fdf Plus, I fixed the broken /git/collab-maint/json-c.git on git.d.o which was an ancient version of the repo, and /git/collab-maint/json-c was current but not exposed to the web frontend. I moved the old one to json-c.git.old (in case you still need it for anything, but I figure it can just go), renamed /json-c to /json-c.git, and added a symlink "json-c" to not break your checkout. I uploaded this as an NMU to DELAYED/5, with the attached "release" commit. I will push this to git if and when this lands. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) From 2f0370b353344bbbc8ba2699df12a1414bf2c4ce Mon Sep 17 00:00:00 2001 From: Martin Pitt Date: Wed, 9 Nov 2016 10:18:15 +0100 Subject: [PATCH] releasing package json-c version 0.12-3.1 --- debian/changelog | 9 + 1 file changed, 9 insertions(+) diff --git a/debian/changelog b/debian/changelog index de59f73..f3e8d06 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +json-c (0.12-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: Fix Vcs-Browser URL + * debian/libjson-c-dev.links: Fix library symlinks to not collide between + /lib/ and /usr/lib/ (Closes: #843145, LP: #1629552) + + -- Martin Pitt Wed, 09 Nov 2016 10:11:41 +0100 + json-c (0.12-3) unstable; urgency=medium * Fix the .so links in the -dev package (Closes: #821768) -- 2.10.2 signature.asc Description: PGP signature
Bug#843537: Fails to start dovecot/resolved with NAMESPACE spawning error
Hello Yuri, Yuri D'Elia [2016-11-07 16:10 +0100]: > Nov 7 15:26:03 e systemd[18963]: systemd-resolved.service: Failed at step > NAMESPACE spawning /bin/sh: Bad file descriptor As Michael said, your kernel is likely too old. I suspect one of the new hardening options in /lib/systemd/system/systemd-resolved.service: PrivateTmp=yes PrivateDevices=yes ProtectControlGroups=yes ProtectKernelTunables=yes RestrictRealtime=yes RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 You can try commenting some or all of them. Nevertheless, this is most likely a wontfix. We can't support ancient kernels forever. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#841548: autopkgtest: FTBFS: Tests failures
Control: reassign -1 python3-wand
Control: forcemerge 841653 -1
Martin Pitt [2016-10-21 20:22 +0200]:
> | File "/tmp/autopkgtest.2SwpBj/build.7IV/real-tree/debian/tests/t", line 2,
> in
> | from wand.image import Image
> | File
> "/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/image.py",
> line 21, in
> | from .color import Color
> | File
> "/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/color.py",
> line 12, in
> | from .version import QUANTUM_DEPTH
> | File
> "/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/version.py",
> line 95, in
> | *map(int, MAGICK_RELEASE_DATE_STRING.split('-')))
> | TypeError: Required argument 'month' (pos 2) not found
>
> So it looks like imagemagic changed recently, so at first sight I'll
> just need to adjust the test case to that.
Turns out this is an actual bug in python3-wand, not a bug in the
tests. I reported this as https://bugs.debian.org/841653 and make this
a duplicate.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#841653: Importing wand.image fails
Package: python3-wand
Severity: serious
Version: 0.3.9-1
Hello,
In current sid, at least in a minimal chroot, this module is broken:
# apt-get install -y python3-wand
# python3 -c 'import wand.image'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/wand/image.py", line 21, in
from .color import Color
File "/usr/lib/python3/dist-packages/wand/color.py", line 12, in
from .version import QUANTUM_DEPTH
File "/usr/lib/python3/dist-packages/wand/version.py", line 95, in
*map(int, MAGICK_RELEASE_DATE_STRING.split('-')))
TypeError: Required argument 'month' (pos 2) not found
This must have happened relatively recently. This is spotted by
autopkgtest's testsuite, and Lukas just reported that it's now failing
(#841548). It was still working on October 7 when I did the last
upload.
Thanks for considering,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#841548: autopkgtest: FTBFS: Tests failures
Control: tag -1 confirmed
Hello Lucas,
Lucas Nussbaum [2016-10-21 15:09 +0200]:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
Not quite, the interesting portion is this:
| File "/tmp/autopkgtest.2SwpBj/build.7IV/real-tree/debian/tests/t", line 2,
in
| from wand.image import Image
| File
"/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/image.py",
line 21, in
| from .color import Color
| File
"/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/color.py",
line 12, in
| from .version import QUANTUM_DEPTH
| File
"/tmp/autopkgtest.2SwpBj/deps/usr/lib/python3/dist-packages/wand/version.py",
line 95, in
| *map(int, MAGICK_RELEASE_DATE_STRING.split('-')))
| TypeError: Required argument 'month' (pos 2) not found
So it looks like imagemagic changed recently, so at first sight I'll
just need to adjust the test case to that.
I'll look into this ASAP, thanks for the report!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#837759: network configuration stops working reliably
Control: severity -1 important Contro: tag -1 unreproducible In accordance with the severity definitions [1] I downgrade this to "important". It does not completely break systemd, we don't enable networkd by default, and it does not affect every installation (it's not reproducible on our side yet). Don't worry, I'm still eager to find out what's happening here; I'll look at your logs as soon as possible. Martin [1] https://www.debian.org/Bugs/Developer#severities -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#837759: network configuration stops working reliably
Hello Wolfgang, Wolfgang Walter [2016-09-14 23:34 +0200]: > > > I tested this with a script: FTR, I tried this as welll, and I cannot reproduce the bug either. Wolfgang Walter [2016-09-14 17:56 +0200]: > Yes, systemd-networkd ist active. But on most machines I only have *.link > entries, usually one to name the device: *.link entries are handled by udev, not networkd. So if you can reproduce this on a machine with only has files like > == > [Match] > MACAddress=11:22:33:44:55:66 > > [Link] > Name=net > WakeOnLan=off > == then can you please "systemctl disable --now systemd-networkd" and check if the problem still happens? I suppose not, but if so, this tells us that this is being done through udev. If networkd itself is really the culprit, can you please try the following: * Keep it disabled, run your test.sh to set up the dummy interface, and run SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd (as root). Does this now cause the addresses to be removed? This will run much later than test.sh, so this will tell us if this is a principal logic error or a race condition, i. e. only happens if networkd starts at the right time after test.sh. * Enable networkd again, and boot with "debug" in the kernel command line. Does this still reproduce the bug? If so, please attach the output of "journalctl -b". If not, just enable debugging for networkd with mkdir -p /etc/systemd/system/systemd-networkd.service.d/ printf '[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug' > /etc/systemd/system/systemd-networkd.service.d/debug.conf and reboot. If you catch the bug, please attach "journalctl -b". Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#834367: systemctl daemon-reexec (as run on systemd upgrade) causes all keystrokes to go to text console in addition to X (including passwords)
Control: tag -1 pending Felipe Sateler [2016-08-16 10:44 -0300]: > This may be related to upstream issue > https://github.com/systemd/systemd/issues/3842. > > The linked commit there seems very relevant: > "pid1: reconnect to the console before being re-executed" [1]. Could > someone try to reproduce this with this patch reverted? I did, and that indeed fixes it. Thanks for digging this out! Revert pushed to packaging git. I suppose we should upload this ASAP? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#833503: autopkgtest: accesses the internet during build
Control: severity -1 normal
Hello Chris,
Chris Lamb [2016-08-05 10:02 +0200]:
> Whilst autopkgtest builds successfully on unstable/amd64, according to
> Debian Policy 4.9 packages may not attempt network access during
> a build.
I'm lowering severity as
- Violating a "may not" is not an RC bug as per policy 1.1.
- While this is technically part of a "required" d/rules target, it
only affects running the tests. These can be skipped with
DEB_BUILD_OPTIONS=nocheck.
- autopkgtest itself and the tests only download things via "apt-get
download" (which is not random internet access but stays within the
boundaries of the Debian archive, same like installing build
dependencies). These tests get skipped if "apt-get download" fails,
thus this is *not* an FTBFS if network access does not actually
work.
So I believe that while this can be interpreted as a policy violation
it is still acceptable by the spirit of policy 4.9. I could completely
disable the network-using tests during package build, but that would
make regressions harder to detect.
> The culprit seems to be:
>
> testbed.satisfy_dependencies_string('git, ca-certificates', 'install git for
> --git-source')
That is one case -- your testbed does have "git" installed (otherwise
that tests would be skipped), but not "ca-certificates" to actually be
able to verify SSL certs. I recommend to install that in your system
as well.
The various test_tmp_install*() test cases also download some packages
with "apt-get download", so these would need to be skipped as well if
this is really to be considered a policy violation.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#833487: systemd: Replaces file in systemd-container 230-1
Control: tag -1 pending Hello, Michael Biebl [2016-08-05 9:11 +0200]: > That's a result of > https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=fa607af7b4c57e95675c533b26bc7ecab001e836 > > I think this rule should be re-added, as those clean-up rules are not > obsolete. Upstream still ships busname units. Agreed, sorry about that. Done in packaging git. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#830982: dist-upgrade from jessie to stretch fails: rpcbind.socket fails to start
Control: tag -1 patch
Hello Michael,
Michael Biebl [2016-07-13 18:28 +0200]:
> > We need to replace is-enabled with something which also works for
> > sysv-only services (with v215).
> [...]
> v215 for a sysv only service
> $ systemctl is-enabled rpcbind
> Failed to get unit file state for rpcbind.service: No such file or directory
This works in >= 220-1 via the systemd-sysv-install wrapper, but not
before. WDYT about the attached patch? I tested that in a Jessie
container. This is more relaxed than the SLINK/SSLINK= further down as
it does not rely on `runlevel`.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>From 08d6d3ce4d3bf2c3428d40e6a33665aba7270f59 Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Thu, 14 Jul 2016 15:39:53 +0200
Subject: [PATCH] invoke-rc.d: Add SysV fallback for "systemctl is-enabled" for
systemd < 220
Commit 6dd9d53f4 switched to "systemctl is-enabled" to determine if a service
is enabled. This also has worked for SysV init scripts since systemd 220-1 (via
the systemd-sysv-install wrapper), but does not yet work under Jessie's systemd
215.
Add a fallback to checking runlevel symlinks (for any runlevel) to fix upgrades
where init-system-helpers gets upgraded before systemd, and to make i-s-h
backportable to Jessie.
Closes: #830982
---
script/invoke-rc.d | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/script/invoke-rc.d b/script/invoke-rc.d
index ec87bbc..214f498 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -380,8 +380,11 @@ RC=
### LOCAL POLICY: Enforce that the script/unit is enabled. For SysV init
### scripts, this needs a start entry in either runlevel S or current runlevel
### to allow start or restart.
+### Note that systemd 215 does not yet support is-enabled for SysV scripts,
+### this works only with systemd >= 220-1 (systemd-sysv-install).
if [ -n "$is_systemd" ]; then
-if systemctl --quiet is-enabled "${UNIT}" 2>/dev/null; then
+if systemctl --quiet is-enabled "${UNIT}" 2>/dev/null || \
+ ls ${RCDPREFIX}[S2345].d/S[0-9][0-9]${INITSCRIPTID} >/dev/null 2>&1; then
RC=104
else
RC=101
--
2.8.1
Bug#829127: systemd: Please make sure /lib/systemd/systemd is not linked with something in /usr
Hello Eric, Eric Valette [2016-07-02 9:40 +0200]: > Turns out I did it and it produced no trace (no file just systemd was > printing like crasy). As I've been using my own kernel without initramfs for > so long, I simply forgot to enable initrd support in this kernel. I enabled > it and voilà, /usr is mounted. Haha, glad you solved the mystery! :-) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#829127: systemd: Please make sure /lib/systemd/systemd is not linked with something in /usr
Hello Eric, Eric Valette [2016-06-30 21:33 +0200]: > > I have an initrd on this machine so this is something else OK, I owe you an apology then, sorry. In #771652 you didn't yet, so I just assumed that was still the case. > I was lucky to see at the top of the screen something about shared object, > booted with sysvinit and found it. I suspect the bug is true even with an > initrd this time. Maybe analysing the initrd could tell us. That's strange indeed. Mind booting with "debug" and attaching /run/initramfs/initramfs.debug? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#829127: systemd: Please make sure /lib/systemd/systemd is not linked with something in /usr
Control: reassing -1 libaudit1 Control: forcemerge 828991 -1 Hello Eric, Eric Valette [2016-06-30 21:05 +0200]: > Package: systemd > Version: 230-3 > Severity: critical > Justification: breaks the whole system > > Today a system using initrd was unbootable after upgrade because of the very > same problem of /usr/lib library dependency. > > Please make a check afetr building the binary so this is automagically > detected! systemd already grew a check in debian/rules [1], after you previously filed [2]. But this doesn't help, because this time this: > valette@tri-yann4:~$ ldd /lib/systemd/systemd > libcap-ng.so.0 => /usr/lib/x86_64-linux-gnu/libcap-ng.so.0 > (0x7f962afa4000) ... was not caused by a systemd upload, but by a new audit package. But really, this is a whack-a-mole game. You keep running an unsupported configuration, you get to keep both halves. You *must* run an initrd if you have a separate /usr. At some point we'll get the /usr merge and this will be the latest point where separate /usr without initrd will break for good, and even now it can't work reliably (not just because of linking to pid 1, but also because of udev rules or early boot scripts calling programs from /usr, etc.). This has never been a supported configuration, and just because it happend to mostly work once it doesn't mean that it can be guaranteed forever, sorry. Martin [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=24b267b53 [2] https://bugs.debian.org/771652 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#829110: systemd: FTBFS: FAIL: test-process-util [..] test-calendarspec
Control: reassign -1 libaudit1 Control: forcemerge 828991 -1 Hello Chris, Chris Lamb [2016-06-30 16:53 +0100]: > systemd fails to build from source in unstable/amd64: This is known, due to yesterday's libaudit. Merging/linking bugs. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#828842: calibre: AttributeError when editing metadata
Control: severity -1 important Control: tag -1 unreproducible Hello Sandro, Sandro Pratesi [2016-06-28 14:28 +0200]: > Severity: grave > Justification: renders package unusable I cannot reproduce this, so it's not an universal error in the package, lowering severity. > since the last update when I open the window for metadata editing of a > book in calibre, after selecting one of the fields, pressyng any key > produces the following error: > > calibre, version 2.55.0 > ERROR: Unhandled exception: AttributeError:'QResizeEvent' object has > no attribute 'key' Does that happen for any kind of book? What's your desktop environment? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#828991: libaudit1 gained a dependency against libcap-ng.so.0 which is installed in /usr
Laurent Bigonville [2016-06-29 18:26 +0200]: > Le 29/06/16 à 17:56, Simon McVittie a écrit : > > Is there consensus that supporting this situation is worth developers' > > time? FWIW, I don't think it is. It's an eternal whack-a-mole, it will be moot once we actually land the /usr merge, and even with having the libraries in /lib there will still be more subtle breakage due to udev rules or early init scripts calling stuff from /usr. Just because this *happened* to work a decade ago should not imply that we should be forever condemned to support each weird corner case. > I don't think so and I don't think that there is a lot of our userbase is > even using this (well apparently last time this broke at least tree > different people have opened a bug report about it) These for the record; it was three bugs, but from only two different people: https://bugs.debian.org/771652 https://bugs.debian.org/771723 https://bugs.debian.org/788913 Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#827705: dependency loop between initscripts and sysvinit-utils causes dist-upgrade failure
Control: tag -1 pending Hello Michael, Michael Biebl [2016-06-20 0:59 +0200]: > The issue being that /lib/init/vars.sh has been moved from initscripts > to sysvinit-utils. > sysvinit-utils got a Breaks/Replaces: initscripts (<< 2.88dsf-59.5) for > that. > On the other hand, the initscripts has got a dependency on > sysvinit-utils (>= 2.88dsf-59.5) to ensure /lib/init/vars.sh is available. > > As mentioned, dropping the Breaks should break the loop. I can reproduce the upgrade failure in a schroot, this is indeed very similar to the util-linux vs. sysvinit upgrade problem that we had some weeks ago. Similar to what we did back then, I also see no other option than dropping the Breaks:. This will break carefully crafted downgrade scenarios, but if you do these you are already on your own anyway.. I verified that upgrading from jessie to unstable plus a local apt repo without the Breaks: works fine, so I committed this: http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=f1acba82 I'll 0-day NMU this now, as it got introduced by my previous NMU and fixes an RC bug. Thanks and sorry for the trouble, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#827212: initscripts: upgrade fails because of missing vars.sh
Control: tag -1 pending Hello Michal, Michal Politowski [2016-06-13 20:50 +0200]: > vars.sh got moved to sysvinit-utils but there seems to be nothing > to stop initscripts from upgrading first: Argh, I didn't run into that in my upgrade testing, I guess I've just been lucky. Fixed package with tighter dependency uploaded, thanks for the report! I tested this again with a local apt-ftparchive, the tight dependency doesn't seem to cause any trouble. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#791907: [Pkg-sysvinit-devel] Bug#791907: bootlogd RC bug now on my radar.
Andreas Henriksson [2016-05-25 16:02 +0200]: > Thanks for looking at this! I've pushed the changes to pkg-sysvinit git. > Hopefully someone comes along and does an upload soon, but otherwise > I might just go ahead with a NMU after a while to get these bug reports > off my RC bug radar I NMUed this change together with #826205 and #825937 to DELAYED/5. I'll push the corresponding release commit/tags if/when this lands. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#790765: FTBFS: [munched.A] Error 1
Hello again, Martin Pitt [2016-04-06 14:55 +0200]: > norwegian still FTBFS in current sid: > > | sed -e 's/stringchar *� *�//' -e 's/[��]//g' nb.aff.in > nb.aff.new && \ > | mv nb.aff.new nb.aff > | cat forkort-nb.txt munched.B munched.A munched.N munched.M munched.K > munched.D munched.O munched.C \ > | | tr -d '\-0-9 ' \ > | | grep "\/.*[z\\_\`]" \ > | > comp1.tmp > | Makefile:517: recipe for target 'nb.mch' failed > | make[2]: *** [nb.mch] Error 1 > | make[2]: Leaving directory '/<>' > > So it's not exactly the same error any more, but still an FTBFS RC bug. This is yet another fallout of the changed grep behaviour in 2.23. The package builds fine with "GREP_OPTIONS=-a", but this is only a bandaid as $GREP_OPTIONS is deprecated. So it'd be better to fix the Makefile to use "grep -a" everywhere, or rework it to not use grep, or run it under an appropriate locale. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#790765: FTBFS: [munched.A] Error 1
Petter Reinholdtsen [2016-01-02 18:31 +0100]: > [Tollef Fog Heen] > > Indeed it does. Seems to be caused by > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794152 > > This bug is fixed in ispell now. Should this bug be closed as fixed too? norwegian still FTBFS in current sid: | sed -e 's/stringchar *� *�//' -e 's/[��]//g' nb.aff.in > nb.aff.new && \ | mv nb.aff.new nb.aff | cat forkort-nb.txt munched.B munched.A munched.N munched.M munched.K munched.D munched.O munched.C \ | | tr -d '\-0-9 ' \ | | grep "\/.*[z\\_\`]" \ | > comp1.tmp | Makefile:517: recipe for target 'nb.mch' failed | make[2]: *** [nb.mch] Error 1 | make[2]: Leaving directory '/<>' So it's not exactly the same error any more, but still an FTBFS RC bug. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#818185: autopkgtest: lxc backend broken
Control: tag -1 pending Hey Antonio, Antonio Terceiro [2016-03-14 14:22 -0300]: > adt-run: DBG: got reply from testbed: Created container adt-virt-lxc-uqfvgj > as copy of adt-sid-amd64 > adt-run: DBG: TestbedFailure sent `open', got `Created container > adt-virt-lxc-uqfvgj as copy of adt-sid-amd64', expected `ok...' Ah, my bad. Fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=92aaf4dedb4 I'll upload a new version ASAP. BTW, for your production use I *really* recommend running at least /var/lib/lxc/ on btrfs. It's *soo* much faster to clone and cleanup containers, and saves quite some disk space too. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#815020: breaks coredump handling for systems without systemd-coredump
Control: tag -1 pending Hey all, Martin Pitt [2016-02-27 12:24 +0100]: > So I think I'll revert the second hunk of the above commit for now to > get things back to normal. To avoid breaking systemd-coredump, which > now looks at the process' RLIMIT_CORE (which is IMHO wrong), we need > to adjust https://github.com/systemd/systemd/commit/bdfd7b2c63 > accordingly. I committed http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=64599ffe44f0d for now which does that. It's minimally intrusive, and basically reverts to the behaviour of 228. Opinions? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#815020: breaks coredump handling for systems without systemd-coredump
Control: forwarded -1 https://github.com/systemd/systemd/issues/2643 Hello all, FTR, this got introduced in https://github.com/systemd/systemd/commit/15a900327a . There is a closely related discussion about this upstream here: https://github.com/systemd/systemd/issues/2643 it's not precisely this issue, but the root cause is the same, thus I set it as the upstream bug. (I also just followed up there). So I think I'll revert the second hunk of the above commit for now to get things back to normal. To avoid breaking systemd-coredump, which now looks at the process' RLIMIT_CORE (which is IMHO wrong), we need to adjust https://github.com/systemd/systemd/commit/bdfd7b2c63 accordingly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#746580: sysv-rc: [patch] much improved update-rc.d integration w/ systemd
Control: severity -1 normal Florian Schlichting [2015-03-21 0:47 +0100]: > I think the severity should be raised - the working of update-rc.d ought > to be improved for jessie. As that didn't happen, I'm downgrading this back to normal. Sorry for the late response -- we just mass-reassigned bugs to the init-system-helpers package as update-rc.d, service, and invoke-rc.d moved there yesterday. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#811157: [Pkg-postgresql-public] Bug#811157: FTBFS: debian/control needs updating from debian/control.in
Control: tag -1 pending Martin Michlmayr [2016-01-16 0:11 -0800]: > plr fails to build in unstable: This is waiting in NEW: https://ftp-master.debian.org/new/plr_1:8.3.0.16-1.html Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#810785: ifupdown breaks debootstrap of Debian
Hello Raphaël, Weird, why did britney migrate ifupdown to testing despite being uninstallable? This sounds like a major britney bug -- ifupdown and systemd were clearly meant to go in together, as the Breaks: indicate. Raphaël Hertzog [2016-01-12 10:23 +0100]: > The problem is that stretch still has systemd 228-2 and 228-4 is unlikely > to migrate quickly since it just got updated and seems to have a new RC bug. No, should be okay. http://bugs.debian.org/810114 got fixed by -4 (which was what was holding back -3), and the new RC bug https://bugs.debian.org/808151 already affects stretch, so britney should not hold back -4 because of that. TBH, I don't see what we can do about that in ifupdown. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#809744: /var/lib/dpkg/info/udev.prerm called with unknown argument 'deconfigure'
Control: tag -1 pending Andreas Beckmann [2016-01-08 11:52 +0100]: > Why can't this be fixed in a jessie point release? It can, but we can't guarantee that the jessie update will be installed before dist-upgrading to wheezy. > So at least upgrades from up-to-date jessie would have a deconfigurable > udev. Right, this can't hurt in either case. I cherry-picked this: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie&id=966a8a40 (@Michael: I deliberately picked 0b45b4c as that's less intrusive than ea089f29bb; but I don't have a strong opinion.) > In ifupdown, adding a > Conflicts: udev (<< 228-3) > could convince dpkg to deconfigure the other package (i.e. ifupdown) > involved in this Breaks loop ... (but I haven't tested this). ifupdown 0.8.5 actually did have such a Breaks:, but that completely breaks upgrades from the current udev versions, so that got dropped as a workaround. (See #809658, #809743). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#810104: usb-modeswitch: uses /lib/udev/hotplug.functions, which is gone
clone 810104 -1 reassign -1 udev 228-3 retitle -1 put back /lib/udev/hotplug.functions, other packages still use it severity 810104 normal retitle 810104 please drop usage of /lib/udev/hotplug.functions clone 810104 -2 -3 reassign -2 joystick 1:1.4.8-2 reassign -3 ifplugd 0.28-19 thanks Hello Jakub, Jakub Wilk [2016-01-06 15:54 +0100]: > /lib/udev/usb_modeswitch uses /lib/udev/hotplug.functions, but this file has > been removed: Thanks for spotting! This was supposed to be an internal helper API and is not documented anywhere. However, I see two other packages which still use it. I'm cloning to udev (keeping RC) to put back the helper for the time being, and cloning the bug some more about eliminiating its usage from the other packages. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#809265: debci: FTBFS: ./test_blame.sh failed at least one test (test_passing_the_test_resets_the_blame?)
Chris Lamb [2015-12-28 21:18 +]: > ./test_blame.sh > ln: failed to create symbolic link > ‘/tmp/tmp.qdthkLehjc/data/packages/unstable/amd64/f/foobar/20151228_221440.autopkgtest.log.gz’: > File exists > ln: failed to create symbolic link > ‘/tmp/tmp.VTKBDbCmvI/data/packages/unstable/amd64/f/foobar/20151228_221449.autopkgtest.log.gz’: > File exists I see that in Ubuntu's production CI tests too, and I can reproduce it reliably. Keeping some notes from my initial investigation for the record: - Tests currently use real-time timestamps, and as a single process() run usually takes less than a second, the chance that two successive calls to process() use the same timestamp is thus very high. - process() does "__day=$(($__day + 1))" but that's not being used anywhere. The intention was certainly to use that to forge the timestamps. - This happened until http://anonscm.debian.org/cgit/collab-maint/debci.git/commit/?id=499f3d0f which removed the usage of faketime. Antonio says that using faketime created other problems. - One possibility is to add a "sleep 1" to process() so that the time stamps are guaranteed to be different. This makes the tests a tad slower, but would at least fix this RC bug for the time being. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#808151: systemd: failed to start remount root and kernel file system
Hello Frank, Frank B. Brokken [2016-01-04 12:06 +0100]: > However, if there is/are .deb packages available that I can use to test the > new, hopefully fixed, version I'm of course more than willing to give it a > try: in that case all dependencies and the installation/removal of files are > handled by the package installer, and I don't have to be afraid of possibly > breaking the operational integrity of my computer. You reported the bug on i386, so I built packages with that patch for that arch, and put them on https://people.debian.org/~mpitt/tmp/systemd-808151/ You can use that as an apt source by adding deb [trusted=yes] http://people.debian.org/~mpitt/tmp/systemd-808151/ / to /etc/apt/sources.list (or sources.list.d/pitti.list or similar), then running "apt update" and "apt upgrade". Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
