Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name
Hey Paul, Raphael, happy new year to you, On Sat, Jan 01, 2022 at 10:05:21PM +0100, Paul Gevers wrote: > Hi Raphael, > > On 01-01-2022 21:37, Raphael Hertzog wrote: > > On Fri, 31 Dec 2021, Paul Gevers wrote: > > > > Otherwise I would like to suggest to create two entries, one with > > > > "Pin: release a=foo" and one with "Pin: release n=foo" so that > > > > we are sure to match on any of the 3 fields. > > > > > > I'll have to check and think about this. I remember that I had lots of > > > issues with coming up with changes to autopkgtest that also worked for > > > Ubuntu, as they use the same Codename for the real Suite and the > > > *-proposed > > > Suite (which they call pocket). I don't recall if that was with respect to > > > pinning or other aspects of autopkgtest and it's requirement to manipulate > > > where packages should be installed from. Before committing your proposal I > > > need to understand that I'm not breaking existing valid configurations > > > too. > > > > I saw a comment mentionning this, but it was related to the "--apt-pocket" > > option and I didn't change that part, which still uses the "a=foo" syntax. > > > > https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263 > > Right, thanks for referencing that line as it has the bug number where the > relevant information was. As the --pin-packages option will already have the > *-pocket in the name, I think this would work for Ubuntu too. CC-ing Iain > for a sanity check on our reasoning. Thanks for copying me on this. Julian might be a good one also. I fear I've probably forgotten most of these details, so please pardon me for this response… Wasn't the problem for Ubuntu that 'Pin: release foo' also applies to foo-proposed too? I think 'Pin: release foo-proposed' will work as intended though, right? Is the latter what we'll start generating with this? Seeing some example generated pins (before / after the patch) would be great to help reason about this. I guess a test covering this for all of the Ubuntu, Debian & Kali cases would be helpful in terms of confidence both with this change and making any future changes here. The one thing I do remember is that it's hairy, like all the pinning stuff in autopkgtest. :-) Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#977787: Removed package(s) from unstable
On Fri, Feb 12, 2021 at 12:59:53PM +0100, Bastian Germann wrote: > On Wed, 10 Feb 2021 15:53:24 +0100 Gunnar Hjalmarsson > wrote: > > Hi! > > > > It appears to me that this removal was done prematurely. The removal > > prevents quite a few packages from trying to build on kfreebsd-amd64 and > > kfreebsd-i386. This is one example which I stumbled upon: > > > > https://buildd.debian.org/status/package.php?p=marisa=experimental > > > > Tracking the reason for those "BD-Uninstallable" occurrences leads me - > > over perl, gettext and emacs - to this: > > > > https://buildd.debian.org/status/package.php?p=git > > > > Not sure I make the correct analysis, though. It's rather messy. > > > > -- > > Gunnar Hjalmarsson > > https://launchpad.net/~gunnarhj > > > > It seems like a bigger problem on kfreebsd: git does not build because the > old gettext cannot be installed without the libcroco. Also, a newer gettext > does not build (via emacs) without git-man at some specific version. Would > it make sense to reintroduce libcroco for unstable only and losen the > versioned git -> git-man dependency to resolve this? There are test-depends too, so this breaks some autopkgtests. The one I just found was: https://salsa.debian.org/js-team/node-normalize.css/-/blob/master/debian/tests/control -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#983162: test dependency libcroco-tools removed
Source: node-normalize.css Version: 8.0.1-3 Severity: normal Heya, In #977787 libcroco was removed. This is a test dependency of node-normalize.css, so the test is broken now. Not sure if there's something else which can be used or if the package should be resurrected, or what. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#982633: Support separate libtirpc
On Fri, Feb 12, 2021 at 05:49:44PM +, Iain Lane wrote: > Once I get a bug number back I'll attach the patch. Upstream doesn't > seem that alive, and I don't have a SF account, so I've not forwarded - > if you could help me do that that would be super useful. Here you go! -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] diff -Nru netatalk-3.1.12~ds/debian/changelog netatalk-3.1.12~ds/debian/changelog --- netatalk-3.1.12~ds/debian/changelog 2020-12-16 22:11:11.0 + +++ netatalk-3.1.12~ds/debian/changelog 2021-02-11 11:05:14.0 + @@ -1,3 +1,13 @@ +netatalk (3.1.12~ds-9) UNRELEASED; urgency=medium + + * Build agianst libtirpc: ++ debian/patches/allow-use-of-tirpc: Fixes quota support being disabled + where this isn't available. ++ debian/rules: Pass --with-libtirpc to enable this new support. ++ debian/control: BD on libtirpc-dev. + + -- Iain Lane Thu, 11 Feb 2021 11:05:14 + + netatalk (3.1.12~ds-8) unstable; urgency=medium * update patch 105 to support cross-compilation; diff -Nru netatalk-3.1.12~ds/debian/control netatalk-3.1.12~ds/debian/control --- netatalk-3.1.12~ds/debian/control 2020-12-16 21:32:17.0 + +++ netatalk-3.1.12~ds/debian/control 2021-02-11 11:05:13.0 + @@ -25,6 +25,7 @@ libssl-dev, libtalloc-dev, libtdb-dev, + libtirpc-dev, libtracker-miner-2.0-dev, libtracker-sparql-2.0-dev, libwrap0-dev, diff -Nru netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch --- netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch 1970-01-01 01:00:00.0 +0100 +++ netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch 2021-02-11 11:05:14.0 + @@ -0,0 +1,97 @@ +Description: Support building against libtirpc as separate from glibc +Author: Iain Lane +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982633 + +unchanged: +Index: b/macros/quota-check.m4 +=== +--- a/macros/quota-check.m4 b/macros/quota-check.m4 +@@ -4,23 +4,37 @@ + AC_DEFUN([AC_NETATALK_CHECK_QUOTA], [ + AC_ARG_ENABLE(quota, + [ --enable-quota Turn on quota support (default=auto)]) ++ AC_ARG_WITH([libtirpc], [AS_HELP_STRING([--with-libtirpc], [Use libtirpc as RPC implementation (instead of sunrpc)])]) + + if test x$enable_quota != xno; then +- QUOTA_LIBS="" +- netatalk_cv_quotasupport="yes" +- AC_CHECK_LIB(rpcsvc, main, [QUOTA_LIBS="-lrpcsvc"]) +- AC_CHECK_HEADERS([rpc/rpc.h rpc/pmap_prot.h rpcsvc/rquota.h],[],[ +- QUOTA_LIBS="" +- netatalk_cv_quotasupport="no" +- AC_DEFINE(NO_QUOTA_SUPPORT, 1, [Define if quota support should not compiled]) +- ]) +- AC_CHECK_LIB(quota, getfsquota, [QUOTA_LIBS="-lquota -lprop -lrpcsvc" +- AC_DEFINE(HAVE_LIBQUOTA, 1, [define if you have libquota])], [], [-lprop -lrpcsvc]) ++ if test "x$with_libtirpc" = xyes; then ++ PKG_CHECK_MODULES([TIRPC], ++ [libtirpc], ++ [QUOTA_CFLAGS=$TIRPC_CFLAGS ++ QUOTA_LIBS=$TIRPC_LIBS ++ netatalk_cv_quotasupport="yes" ++ AC_DEFINE(NEED_RQUOTA, 1, [Define various xdr functions])], ++ [AC_MSG_ERROR([libtirpc requested, but library not found.])] ++ ) ++ else ++ QUOTA_CFLAGS="" ++ QUOTA_LIBS="" ++ netatalk_cv_quotasupport="yes" ++ AC_CHECK_LIB(rpcsvc, main, [QUOTA_LIBS="-lrpcsvc"]) ++ AC_CHECK_HEADERS([rpc/rpc.h rpc/pmap_prot.h rpcsvc/rquota.h],[],[ ++ QUOTA_LIBS="" ++ netatalk_cv_quotasupport="no" ++ AC_DEFINE(NO_QUOTA_SUPPORT, 1, [Define if quota support should not compiled]) ++ ]) ++ AC_CHECK_LIB(quota, getfsquota, [QUOTA_LIBS="-lquota -lprop -lrpcsvc" ++ AC_DEFINE(HAVE_LIBQUOTA, 1, [define if you have libquota])], [], [-lprop -lrpcsvc]) ++ fi + else + netatalk_cv_quotasupport="no" + AC_DEFINE(NO_QUOTA_SUPPORT, 1, [Define if quota support should not compiled]) + fi + ++ AC_SUBST(QUOTA_CFLAGS) + AC_SUBST(QUOTA_LIBS) + ]) + +Index: b/etc/afpd/Makefile.am +===
Bug#982633: Support separate libtirpc
Package: src:netatalk Version: 3.1.12~ds-8 Severity: normal Tags: upstream patch Hiya, I noticed on Ubuntu that the autopkgtest is failing[0]: # Failed test 'Quota support' I think it's because: # Quota support: No quota support is disabled. After a lot of digging around I found it's because the Sun RPC support is gone there[1]. I'd *guess* that once 2.32 comes to Debian we'll start seeing the same issues here. I've got a patch to start building against the replacement external libtirpc. It works in as far as building, keeping the quota support enabled, and the tests finishing successfully. Once I get a bug number back I'll attach the patch. Upstream doesn't seem that alive, and I don't have a SF account, so I've not forwarded - if you could help me do that that would be super useful. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] [0] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/n/netatalk/20210212_152746_09e47@/log.gz [1] https://lists.ubuntu.com/archives/ubuntu-devel/2020-October/041241.html
Bug#975044: Breaks/Replaces for appstream file move are too strict
Package: gparted Version: 1.0.0-0.1build1 Severity: normal Tags: patch Hiya, I'm filing this from an Ubuntu system, but it's a fix I think we should do in Debian, to help all derivatives. When upgrading gparted just now, I got: > Unpacking gparted (1.1.0-0.1) over (1.0.0-0.1build1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-WEMwFJ/165-gparted_1.1.0-0.1_amd64.deb (--unpack): > trying to overwrite '/usr/share/metainfo/gparted.appdata.xml', which is also > in package gparted-common 1.0.0-0.1build1 It's because Ubuntu performed a no-change rebuild of gparted for a library transition (we don't have binary uploads there). Your Breaks/Replaces matches only the exact version of the file that shipped the appdata in Debian, so any modified downstream versions will not match. It would be nicer to either just use `<<` for all earlier versions, or if you want add a lower bound too. I'm happy to supply and upload a patch if you'd like. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#970716: New upstream release 1.18.0
Package: src:gst-omx Severity: normal Hi, There's a new upstream release available. I just packaged it for Ubuntu because I noticed that the autopkgtest was broken after GStreamer 1.18 was uploaded. (Couldn't find omx.so.) They ported to meson, so it required some changes. Here's my packaging in case that's useful for you for Debian. Feel free to take it and change whatever you want. https://people.debian.org/~laney/gst-omx/ -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#966923: meson: diff for NMU version 0.55.0-2.1
Control: tags 966923 + patch
Control: tags 966923 + pending
Control: tags 968704 + pending
Dear maintainer,
I'm sponsoring an NMU for meson (versioned as 0.55.0-2.1) and uploaded
it without delay, after Marco spoke to Martin. Hopefully this doesn't
cause you too much trouble - the skip bug is blocking our work on
updating GNOME to 3.38 so we need this fixed at least in unstable.
Regards,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru meson-0.55.0/debian/changelog meson-0.55.0/debian/changelog
--- meson-0.55.0/debian/changelog 2020-07-16 17:19:52.0 +0100
+++ meson-0.55.0/debian/changelog 2020-08-20 18:10:34.0 +0100
@@ -1,3 +1,11 @@
+meson (0.55.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't consider skipped tests as failures. Closes: #966923
+ * Fix test with setuptools 49. Closes: #968704
+
+ -- Marco Trevisan (Treviño) Thu, 20 Aug 2020 18:10:34 +0100
+
meson (0.55.0-2) unstable; urgency=medium
* Fix crossbuild test from Gianfranco Costamagna. Closes: #963546
diff -Nru meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch
--- meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch 1970-01-01 01:00:00.0 +0100
+++ meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch 2020-08-20 18:10:31.0 +0100
@@ -0,0 +1,125 @@
+From 998ee63e9596d8b3315ddce3d6f4612fec3588ef Mon Sep 17 00:00:00 2001
+From: Simon McVittie
+Date: Mon, 3 Aug 2020 13:31:42 +0100
+Subject: [PATCH] mtest: TestResult.SKIP is not a failure
+
+If some but not all tests in a run were skipped, then the overall result
+is given by whether there were any failures among the non-skipped tests.
+
+Resolves: https://github.com/mesonbuild/meson/issues/7515
+Signed-off-by: Simon McVittie
+
+Bug-Upstream: https://github.com/mesonbuild/meson/issues/7515
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966923
+Origin: https://github.com/mesonbuild/meson/pull/7525
+Applied-Upstream: 0.56.0
+---
+ mesonbuild/mtest.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mesonbuild/mtest.py b/mesonbuild/mtest.py
+index 0d8169218f..817550e666 100644
+--- a/mesonbuild/mtest.py
b/mesonbuild/mtest.py
+@@ -489,7 +489,7 @@ def make_tap(cls, test: 'TestSerialisation', test_env: T.Dict[str, str],
+ failed = True
+ elif isinstance(i, TAPParser.Test):
+ results.append(i.result)
+-if i.result not in {TestResult.OK, TestResult.EXPECTEDFAIL}:
++if i.result not in {TestResult.OK, TestResult.EXPECTEDFAIL, TestResult.SKIP}:
+ failed = True
+ elif isinstance(i, TAPParser.Error):
+ results.append(TestResult.ERROR)
+
+diff --git a/test cases/common/213 tap tests/cat.c b/test cases/common/213 tap tests/cat.c
+new file mode 100644
+index 00..4b92010ade
+--- /dev/null
b/test cases/common/213 tap tests/cat.c
+@@ -0,0 +1,26 @@
++#include
++#include
++
++int main(int argc, char **argv) {
++char buf[1024];
++size_t len;
++FILE *fh;
++
++if (argc != 2) {
++fprintf(stderr, "Incorrect number of arguments, got %i\n", argc);
++return 1;
++}
++fh = fopen(argv[1], "r");
++if (fh == NULL) {
++fprintf(stderr, "Opening %s: errno=%i\n", argv[1], errno);
++return 1;
++}
++do {
++len = fread(buf, 1, sizeof(buf), fh);
++if (len > 0) {
++fwrite(buf, 1, len, stdout);
++}
++} while (len > 0);
++fclose(fh);
++return 0;
++}
+diff --git a/test cases/common/213 tap tests/issue7515.txt b/test cases/common/213 tap tests/issue7515.txt
+new file mode 100644
+index 00..ca8563778d
+--- /dev/null
b/test cases/common/213 tap tests/issue7515.txt
+@@ -0,0 +1,27 @@
++1..26
++ok 1 Gtk overrides UI template sets up internal and public template children
++ok 2 Gtk overrides UI template sets up public template children with the correct widgets
++ok 3 Gtk overrides UI template sets up internal template children with the correct widgets
++ok 4 Gtk overrides UI template connects template callbacks to the correct handler
++ok 5 Gtk overrides UI template binds template callbacks to the correct object
++ok 6 Gtk overrides UI template from resource sets up internal and public template children
++ok 7 Gtk overrides UI template from resource sets up public template children with the correct widgets
++ok 8 Gtk overrides UI template from resource sets up internal template children with the correct widgets
++ok 9 Gtk overrides UI template from resource connects template callbacks to the correct handler
++ok 10 Gtk
Bug#968184: autopkgtest is infinitely outputting "ERROR: not valid"
Control: severity -1 serious On Mon, Aug 10, 2020 at 11:32:42AM +0100, Iain Lane wrote: > I've pinged the Debian CI people, will report back & upgrade the > severity if they confirm it is happening on Debian too. Yeah, same here https://ci.debian.net/data/autopkgtest/testing/arm64/c/calculix-cgx/6606733/log.gz -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#968184: autopkgtest is infinitely outputting "ERROR: not valid"
Package: src:calcluix-cgx Version: 2.17+dfsg-1 Severity: normal I just noticed on the Ubuntu autopkgtest runners that our disk had filled up. When investigating the cause, it turns out that calculix-cgx autopkgtest runs of version 2.17+dfsg-1 have been (apparently) infinitely spamming "ERROR:^@ not valid". The biggest such log that I noticed was 37G! It looks like autopkgtest [07:05:15]: test build1: [--- on a Linux machine, nodename autopkgtest, release 5.4.0-42-generic, version #46-Ubuntu SMP Fri Jul 10 00:22:04 UTC 2020, machine ppc64le The HOME was detected:/home/ubuntu parameters:3 arguments:2 send.fbl opened reading file WARNING: Found a 'sys' command (a system call): sys rm -f *.flm *.rad *.msh *.bou *.equ Since a system call can be dangerous You have to chose now between stop (s), continue (c) or enable (e). If you chose 'e' the 'sys' command will be un-locked by creating or extending your personal config file '/home/ubuntu/.cgx' with the un-lock command ALLOW_SYS. You may delete this command from your '.cgx' file to lock the 'sys' command again. Waiting for user input. Please type into the terminal either s,c or e (the terminal has to be the active window!): ERROR:^@ not valid ERROR:^@ not valid ERROR:^@ not valid ... (forever) I've pinged the Debian CI people, will report back & upgrade the severity if they confirm it is happening on Debian too. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#965064: pkg-haskell-tools: FTBFS in unstable
On Wed, Jul 15, 2020 at 02:40:39PM +0100, Dimitri John Ledkov wrote: > • No instance for (MonadFail Action) arising from a use of ‘fail’ AFAIK (slightly out of the loop), this is because fail is not a part of Monad any more https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html Upgrading shake will fix this, or it can be worked around in the meantime in pkg-haskell-tools by import Control.Monad.Fail as fail instance MonadFail Action where fail = Fail.fail Don't have time to upload it myself, but HTH. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#926409: lintian: autopkgtest takes very long to finish
On Wed, Jun 03, 2020 at 02:50:04AM +0200, Mattia Rizzolo wrote: > On Wed, 3 Jun 2020, 1:09 am Felix Lechner, > ... > > On Fri, Apr 5, 2019 at 4:33 AM Iain Lane wrote: > > > > > > We do similar in some pkg-gnome packages, for example glib2.0 ships a > > > -tests package that contains "installed tests" which are compiled as > > > part of the package build and then executed during the autopkgtests. > > > > Should we ship all built test packages as part of our releases? I > > can't think of a better way to close this bug. > > > Now lintian autopkgtests take approximately 1 hour everywhere I checked. > Honestly, I believe 1 hour to be acceptable. It is broadly acceptable, but if you can reduce the time by assembling artifacts in advance, I think that it is still worth doing to save time and not repeat computation that doesn't need to be repeated. As a bonus you're then not also testing the package build toolchain with each Lintian CI run - you are (mostly) only testing Lintian itself. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#960023: SSHFP stops working with libc6 2.31 [AD bit stripped]
Control: forwarded -1 https://github.com/systemd/systemd/issues/15767 On Sun, May 10, 2020 at 09:33:34AM +0200, Michael Biebl wrote: > Hi Iain > > Am 08.05.20 um 14:32 schrieb Iain Lane: > > systemd > > === > > > > systemd-resolved similarly adds 'options edns0' to resolv.conf files it > > generates for its stub resolver. It could be extended (untested) to add > > the 'trust-ad' option. > > > Could you please raise this at > https://github.com/systemd/systemd/issues > > To me this sounds like something that should be discussed (and > eventually implemented) upstream . Of course. I filed it here because I wanted to see if the Debian maintainers had any thoughts first (and because the SSH behaviour is a Debian patch). Here you go: https://github.com/systemd/systemd/issues/15767 Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#960023: SSHFP stops working with libc6 2.31 [AD bit stripped]
Package: ssh,systemd
Severity: normal
Hey
I've just been playing with SSHFP as a way of verifying SSH host keys
(VerifyHostKeyDNS=yes) when I can trust my local DNS resolver. I was
trying on Ubuntu 20.04 and I could just *not* get it to work. It was
considering the response to be untrusted. I'll spare you all of the
tedious details of the many things I tried, but it comes down to this.
As of 2.31, glibc's stub resolver is stripping the AD (authenticated
data) bit from resposes that it receives from its upstream name servers.
This is documented in the release notes for 2.31:
* The DNS stub resolver will optionally send the AD (authenticated
data) bit in queries if the trust-ad option is set via the options
directive in /etc/resolv.conf (or if RES_TRUSTAD is set in
_res.options). In this mode, the AD bit, as provided by the name
server, is available to applications which call res_search and
related functions. In the default mode, the AD bit is not set in
queries, and it is automatically cleared in responses, indicating a
lack of DNSSEC validation. (Therefore, the name servers and the
network path to them are treated as untrusted.)
and a couple of relevant links
https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/461
https://bugzilla.redhat.com/show_bug.cgi?id=1164339#c15
I'm filing this on *both* SSH and systemd, since I think either or both
are places that might want to consider being altered to account for
this and I'd be interested in the maintainers' opinions.
openssh
===
In Debian we are patching ssh to unconditionally send EDNS0, even if not
specified in /etc/resolve.conf, in an effort to support this feature.
Sending TRUSTAD too is arguably in keeping with the spirit of this
patch. I tried this in the attached patch and it works.
systemd
===
systemd-resolved similarly adds 'options edns0' to resolv.conf files it
generates for its stub resolver. It could be extended (untested) to add
the 'trust-ad' option.
Counterargument
===
I'm not very well-read here yet, but it seems like this is done because
AD can be faked by malicious resolvers, and so the argument is that it's
not safe to trust it unless you know you're in a trusted environment. In
that light, perhaps what ssh and systemd are doing (adding edns0 to make
the AD bit be sent automatically) is working against upstream glibc's
goal, and so we shouldn't do this for users without their opt-in? This
is where I'd appreciate the input of wiser heads.
If this type of argument is accepted, it would be good to provide a
simple way to turn trust-ad on so that people can do it when they are on
trusted networks. (Maybe even with higher-level support from something
like network-manager too.)
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru openssh-8.2p1/debian/patches/dnssec-sshfp.patch
openssh-8.2p1/debian/patches/dnssec-sshfp.patch
--- openssh-8.2p1/debian/patches/dnssec-sshfp.patch 2020-02-26
10:55:07.0 +
+++ openssh-8.2p1/debian/patches/dnssec-sshfp.patch 2020-05-03
20:00:01.0 +0100
@@ -17,11 +17,11 @@
openbsd-compat/getrrsetbyname.h | 3 +++
3 files changed, 21 insertions(+), 6 deletions(-)
-diff --git a/dns.c b/dns.c
-index e4f9bf830..9c9fe6413 100644
+Index: b/dns.c
+===
--- a/dns.c
+++ b/dns.c
-@@ -210,6 +210,7 @@ verify_host_key_dns(const char *hostname, struct sockaddr
*address,
+@@ -210,6 +210,7 @@
{
u_int counter;
int result;
@@ -29,7 +29,7 @@
struct rrsetinfo *fingerprints = NULL;
u_int8_t hostkey_algorithm;
-@@ -233,8 +234,19 @@ verify_host_key_dns(const char *hostname, struct sockaddr
*address,
+@@ -233,8 +234,19 @@
return -1;
}
@@ -50,11 +50,11 @@
if (result) {
verbose("DNS lookup error: %s", dns_result_totext(result));
return -1;
-diff --git a/openbsd-compat/getrrsetbyname.c b/openbsd-compat/getrrsetbyname.c
-index dc6fe0533..e061a290a 100644
+Index: b/openbsd-compat/getrrsetbyname.c
+===
--- a/openbsd-compat/getrrsetbyname.c
+++ b/openbsd-compat/getrrsetbyname.c
-@@ -209,8 +209,8 @@ getrrsetbyname(const char *hostname, unsigned int rdclass,
+@@ -209,8 +209,8 @@
goto fail;
}
@@ -65,7 +65,7 @@
result = ERRSET_INVAL;
goto fail;
}
-@@ -226,9 +226,9 @@ getrrsetbyname(const char *hostname, unsigned int rdclass,
+@@ -226,9 +226,9 @@
#endif /* DEBUG */
#ifdef RES_USE_DNSSEC
@@ -74,15 +74,25 @@
- _resp->options |= RES_USE_DNSSEC;
+ /* turn on DNSSEC if required */
+ if (flags & RRSET_FORCE_EDNS0)
-+
Bug#959805: libproxy1-plugin-mozjs: Passes invalid/corrupted strings to FindProxyForURL()
On Tue, May 05, 2020 at 06:35:28PM -0400, Jeremy Bicha wrote: > On Tue, May 5, 2020 at 10:33 AM Simon McVittie wrote: > > However, this plugin has a popcon of 108 installations (compared with 27K > > for its webkit counterpart), wasn't shipped in buster, and I don't think > > we consider mozjs68 to be safe for use with untrusted content (although > > PAC is probably at least semi-trusted in any reasonable threat model); > > so perhaps it should just be removed instead? > > Does anyone know if there is anything the mozjs plugin can do that the > webkit can't? > > I'd prefer we only offer the webkit version. I'd be OK with that. I only worked on the port because it was required for the mozjs68 transition and evidently didn't test it enough! I asked upstream for help testing / reviewing, but they apparently merged it when it was broken, so that speaks to how much it's cared for there: perhaps they would consider dropping it too. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#948228: bug 948228 is forwarded to https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/55
On Tue, Mar 24, 2020 at 10:13:50AM +, Simon McVittie wrote: > forwarded 948228 > https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/55 > thanks I've just uploaded 0.6.55-2 which is supposed to fix this bug (we were getting a lot of people hitting it in Ubuntu when doing an upgrade to focal). Please give it a go and let me know if it doesn't work for you. Upstream we were wondering whether some more protection would be needed. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#956115: FTBFS against icu in experimental: /usr/include/unicode/localpointer.h:371:1: error: template with C linkage
Package: libcmis
Version: 0.5.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Hi,
When built against icu in experimental:
/usr/include/unicode/localpointer.h:371:1: error: template with C linkage
371 | template
| ^~~~
In file included from repository.cxx:29:
../../inc/libcmis-c/repository.h:32:1: note: ‘extern "C"’ linkage started here
32 | extern "C" {
| ^~
In file included from /usr/include/unicode/uenum.h:23,
from /usr/include/unicode/ucnv.h:53,
from /usr/include/libxml2/libxml/encoding.h:31,
from /usr/include/libxml2/libxml/parser.h:810,
from /usr/include/libxml2/libxml/globals.h:18,
from /usr/include/libxml2/libxml/threads.h:35,
from /usr/include/libxml2/libxml/xmlmemory.h:218,
from /usr/include/libxml2/libxml/tree.h:1307,
from ../../inc/libcmis-c/repository.h:35,
from repository.cxx:29:
/usr/include/unicode/ucnv.h:585:1: error: conflicting declaration of C function
‘void icu_66::swap(icu_66::LocalUConverterPointer&,
icu_66::LocalUConverterPointer&)’
585 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUConverterPointer, UConverter,
ucnv_close);
| ^~~
/usr/include/unicode/uenum.h:68:1: note: previous declaration ‘void
icu_66::swap(icu_66::LocalUEnumerationPointer&,
icu_66::LocalUEnumerationPointer&)’
68 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUEnumerationPointer, UEnumeration,
uenum_close);
| ^~~
make[4]: *** [Makefile:619: libcmis_c_0.5_la-repository.lo] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory '/<>/src/libcmis-c'
make[3]: *** [Makefile:523: all-recursive] Error 1
make[3]: Leaving directory '/<>/src'
make[2]: *** [Makefile:538: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:43: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:23: build] Error 2
Fixed with the attached patch. I'll poke upstream to re-consider it.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru libcmis-0.5.2/debian/control libcmis-0.5.2/debian/control
--- libcmis-0.5.2/debian/control2020-02-03 20:42:17.0 +
+++ libcmis-0.5.2/debian/control2020-04-07 15:16:03.0 +0100
@@ -1,7 +1,6 @@
Source: libcmis
Priority: optional
-Maintainer: Ubuntu Developers
-XSBC-Original-Maintainer: Debian LibreOffice Maintainers
+Maintainer: Debian LibreOffice Maintainers
Uploaders: Rene Engelhard
Build-Depends: debhelper (>= 9), autotools-dev, libxml2-dev, libboost-dev,
libboost-program-options-dev, libcurl4-gnutls-dev, libcppunit-dev (>= 1.12),
docbook2x, libboost-date-time-dev, dpkg-dev (>= 1.16.1), pkg-config,
dh-autoreconf, docbook-xml, dh-exec (>= 0.3)
Standards-Version: 3.9.6
diff -Nru
libcmis-0.5.2/debian/patches/include-libxml-headers-outside-of-extern-c
libcmis-0.5.2/debian/patches/include-libxml-headers-outside-of-extern-c
--- libcmis-0.5.2/debian/patches/include-libxml-headers-outside-of-extern-c
1970-01-01 01:00:00.0 +0100
+++ libcmis-0.5.2/debian/patches/include-libxml-headers-outside-of-extern-c
2020-04-07 15:16:01.0 +0100
@@ -0,0 +1,22 @@
+Description: Move include outside of "extern C" block
+Author: Iain Lane
+Bug-Upstream: https://unicode-org.atlassian.net/browse/ICU-20530
+Forwarded: https://github.com/tdf/libcmis/issues/35
+
+--- libcmis-0.5.2.orig/inc/libcmis-c/repository.h
libcmis-0.5.2/inc/libcmis-c/repository.h
+@@ -28,12 +28,12 @@
+ #ifndef _REPOSITORY_H_
+ #define _REPOSITORY_H_
+
++#include
++
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+
+-#include
+-
+ #include "libcmis-c/libcmis-c-api.h"
+ #include "libcmis-c/types.h"
+
diff -Nru libcmis-0.5.2/debian/patches/series
libcmis-0.5.2/debian/patches/series
--- libcmis-0.5.2/debian/patches/series 2018-12-28 19:02:55.0 +
+++ libcmis-0.5.2/debian/patches/series 2020-04-07 15:09:40.0 +0100
@@ -1 +1,2 @@
fix-docbook-to-man-call.diff
+include-libxml-headers-outside-of-extern-c
Bug#955039: Acknowledgement (llvm-dev doesn't ensure that the corresponding clang is installed)
Here's the actual attachment. :( -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] mozjs68_68.6.0-1_amd64.build.xz Description: application/xz
Bug#955039: llvm-dev doesn't ensure that the corresponding clang is installed
Package: llvm-dev Version: 1:10.0-50~exp1 Severity: normal Hi there, Please see the attached build log. It's from mozjs68 which has Build-Depends: llvm-dev, clang. Get: 73 https://mirrors.wikimedia.org/debian unstable/main s390x clang-10 s390x 1:10.0.0-1 [104 kB] Get: 74 https://mirrors.wikimedia.org/debian experimental/main s390x clang s390x 1:10.0-50~exp1 [8132 B] ... Get: 97 https://mirrors.wikimedia.org/debian experimental/main s390x libclang-dev s390x 1:10.0-50~exp1 [7756 B] ... Get: 116 https://mirrors.wikimedia.org/debian unstable/main s390x llvm-9-tools s390x 1:9.0.1-10 [322 kB] Get: 117 https://mirrors.wikimedia.org/debian unstable/main s390x llvm-9-dev s390x 1:9.0.1-10 [25.2 MB] Get: 118 https://mirrors.wikimedia.org/debian unstable/main s390x llvm-dev s390x 1:9.0-49.1 [8052 B and then later on the build failed with: ERROR: The file /usr/lib/llvm-9/bin/clang returned by `llvm-config --bindir` does not exist. It ultimately happened because of #954826 meaning clang-9 is uninstallable ATM. But it would be good if the packaging of llvm could somehow ensure that the matching clang is always installed - in this case, it would have required installing llvm-10-dev. I don't actually see how to achieve this in consuming packages. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#945015: only-branch only takes exact branch names
On Thu, Mar 19, 2020 at 11:34:19AM +0100, gregor herrmann wrote: > On Tue, 26 Nov 2019 21:27:14 +0200, Damyan Ivanov wrote: > > > -=| gregor herrmann, 25.11.2019 21:38:54 +0100 |=- > > > On Mon, 18 Nov 2019 12:42:55 +, Iain Lane wrote: > > > > > > > I think it'd be cool if this were instead to support globbing. If I were > > > > to propose a merge request which changes this into a glob (Text::Glob?), > > > > would you merge that? > > > > > > I think the idea totally makes sense, and if the change is > > > backwards-compatible and doesn't pose any other issue I don't see why > > > we wouldn't take it. > > > > > > Maybe Dam who wrote the webhook support has some ideas on how to best > > > implement it or can share other thoughts. > > > > I think that using Text::Glob is a nice idea. > > > > Reading Text::Glob(3pm) I noticed that '/' is treated specially - '*' > > doesn't match it. Hopefully that's not a deal breaker. > > > > Going for full regular expression support seems overkill, and > > dangerous. > > > > So, please, Iain, send that merge request. Thanks! > > The merge request exists, thanks Iain! > > https://salsa.debian.org/kgb-team/kgb/-/merge_requests/7 Ah yeah, I should have updated the bug. > To me it looks good, and I especially appreciate the added tests. > Iain, I guess you tested the changes also with a test installation, > as discussed on IRC? I did, yes - and it seems to work as designed. Thanks for the initial review! Hopefully once this is merged the "production" instances can be updated to use it? Then I can fix pkg-gnome's webhooks to not spam #debian-gnome :-). Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#888313: Upstream metadata: Repository-Type field
On Sat, Mar 07, 2020 at 12:32:14PM +, Jelmer Vernooij wrote: > On Thu, Mar 05, 2020 at 09:40:33PM +0100, gregor herrmann wrote: > > On Thu, 05 Mar 2020 10:28:03 +0000, Iain Lane wrote: > > > Since the discussions on the bug I've learned a > > > bit more about the upstream metadata spec > > > https://wiki.debian.org/UpstreamMetadata > > > I think a slight gap there is that the "Repository:" field is just a > > > URL: it's not really enough information to tell if it's a git repository > > > we could add a remote for. To solve that I'm proposing a new > > > "Repository-Type" field, which would have values like "git, svn, hg, > > > ...". Opinions? > > > > In the perl team we just check if it's a git repo and continue from > > there: > > if ! GIT_ASKPASS=/bin/true git ls-remote "$REPOURL" >/dev/null 2>&1; > > then > > > > Having to add another field to thousands of files doesn't sound too > > appealing to me (especially as at least in our case there are hardly > > any non-git upstream repos involved). > +1 > > It would be nice to not fail hard if the upstream repository turns out > to not be a Git repository, but some other kind of vcs > (in which case you presumably just want to ignore it?). Thanks for the feedback! I think in this case I can actually simply try to fetch the repository and ignore it if it can't be fetched so this isn't a blocker for me. I'm not sure what other use-cases there are for this field though, and if that would work for them. It does feel a bit hard to use in general without knowing which VCS a URL points to - presumably that's why we have Vcs-$type in control files. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#888313: Upstream metadata: Repository-Type field
[ please Cc me, I am not subscribed ] Hey, I'm planning to work on #888313 (add upstream git remotes automatically with gbp clone) today. Since the discussions on the bug I've learned a bit more about the upstream metadata spec https://wiki.debian.org/UpstreamMetadata I think a slight gap there is that the "Repository:" field is just a URL: it's not really enough information to tell if it's a git repository we could add a remote for. To solve that I'm proposing a new "Repository-Type" field, which would have values like "git, svn, hg, ...". Opinions? In terms of the git-buildpackage implementation, I'm thinking of adding and fetching the upstream repository but *not* creating any tracking branches by default - that would avoid some of the discussions we've had in the bug and I think should be enough for most Debian packaging workflows (dealing with tags). Probably together with an option in gbp.conf to disable this behaviour too. Feedback on that appreciated (or on the patch when I send it [will go just to the bug, not -qa@]). Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#952745: Fix tests with gedit 3.35
Package: dogtail
Version: 0.9.11-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Heya,
We noticed via Ubuntu that dogtail fails to build / test once gedit is
updated, because it's testing for a part of the UI that doesn't exist in
this version.
I just submitted this to upstream - would be nice if you could upload to
Debian too. I wrote it in such a way that it should work with old and
new gedit, so should be safe to upload now.
Thanks!
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru
dogtail-0.9.11/debian/patches/0001-test_tree-Move-test_unicode_char_-to-use-a-different.patch
dogtail-0.9.11/debian/patches/0001-test_tree-Move-test_unicode_char_-to-use-a-different.patch
---
dogtail-0.9.11/debian/patches/0001-test_tree-Move-test_unicode_char_-to-use-a-different.patch
1970-01-01 01:00:00.0 +0100
+++
dogtail-0.9.11/debian/patches/0001-test_tree-Move-test_unicode_char_-to-use-a-different.patch
2020-02-28 13:06:44.0 +
@@ -0,0 +1,52 @@
+From 9e0c7c35d88e18b042735f2d3be831da77021df8 Mon Sep 17 00:00:00 2001
+From: Iain Lane
+Date: Fri, 28 Feb 2020 12:34:45 +
+Subject: [PATCH] test_tree: Move test_unicode_char_* to use a different UI
+ element
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+In gedit 3.35, the "Open" button was re-designed to no longer have the
+"Other Documents…" button inside it.
+
+Move to testing the (hamburger) menu button instead, as it has an item
+"Find and Replace…" which we can look for instead. This works on
+pre-3.35 gedit too.
+
+Forwarded: https://gitlab.com/dogtail/dogtail/-/merge_requests/19
+---
+ tests/test_tree.py | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/tests/test_tree.py b/tests/test_tree.py
+index 46f276c..8646380 100644
+--- a/tests/test_tree.py
b/tests/test_tree.py
+@@ -875,18 +875,18 @@ class TestUnicodeNames(unittest.TestCase):
+ self.app = dogtail.tree.root.application('gedit')
+
+ def test_unicode_char_in_name(self):
+-self.app.child('Open', roleName='toggle button').click()
++self.app.child('Menu', roleName='toggle button').click()
+ unicode_button = None
+-unicode_button = self.app.child(name=u'Other Documents…',
roleName='push button')
++unicode_button = self.app.child(name=u'Find and Replace…',
roleName='push button')
+ assert unicode_button is not None
+
+ def test_unicode_char_in_name_click(self):
+-self.app.child('Open', roleName='toggle button').click()
+-unicode_button = self.app.child(name=u'Other Documents…',
roleName='push button')
++self.app.child('Menu', roleName='toggle button').click()
++unicode_button = self.app.child(name=u'Find and Replace…',
roleName='push button')
+ unicode_button.click()
+ dialog = None
+ try:
+-dialog = self.app.child(name=u'Open', roleName='file chooser')
++dialog = self.app.child(name=u'Find and Replace',
roleName='dialog')
+ except dogtail.tree.SearchError:
+ self.fail()
+ assert dialog is not None
+--
+2.20.1
+
diff -Nru dogtail-0.9.11/debian/patches/gedit_3.34
dogtail-0.9.11/debian/patches/gedit_3.34
--- dogtail-0.9.11/debian/patches/gedit_3.342019-09-13 18:50:52.0
+0100
+++ dogtail-0.9.11/debian/patches/gedit_3.342020-02-28 13:08:18.0
+
@@ -8,11 +8,11 @@
It was renamed into org.gnome.gedit in gedit 3.34.
-diff --git a/tests/test_tree.py b/tests/test_tree.py
-index 46f276c..ab2b238 100644
+Index: b/tests/test_tree.py
+===
--- a/tests/test_tree.py
+++ b/tests/test_tree.py
-@@ -872,7 +872,10 @@ class TestUnicodeNames(unittest.TestCase):
+@@ -872,7 +872,10 @@
dogtail.config.config.searchCutoffCount = 3
import dogtail.utils
self.pid = dogtail.utils.run('gedit')
@@ -23,4 +23,4 @@
+self.app = dogtail.tree.root.application('gedit')
def test_unicode_char_in_name(self):
- self.app.child('Open', roleName='toggle button').click()
+ self.app.child('Menu', roleName='toggle button').click()
diff -Nru dogtail-0.9.11/debian/patches/series
dogtail-0.9.11/debian/patches/series
--- dogtail-0.9.11/debian/patches/series2019-09-13 18:50:52.0
+0100
+++ dogtail-0.9.11/debian/patches/series2020-02-28 13:08:18.0
+
@@ -1,3 +1,4 @@
+0001-test_tree-Move-test_unicode_char_-to-use-a-different.patch
python3_vs_python2
0003-desktop_file.patch
fix-icon-path-check.patch
Bug#951204: libdleyna-core-1.0-5 can't be upgraded: trying to overwrite '/usr/lib/x86_64-linux-gnu/libdleyna-core-1.0.so.5.0.0', which is also in package libdleyna-core-1.0-3:amd64 0.6.0-1
Package: libdleyna-core-1.0-5 Version: 0.6.0-3 Severity: serious Heya, Disclaimer: this happened on Ubuntu and I haven't tried on Debian yet. Not sure if this bug should be RC since this affects only people who picked up 0.6.0-1 from experimental. (Ubuntu synced this so it's a more important problem for us on that side.) When upgrading, apt bombed out like this: Selecting previously unselected package libdleyna-core-1.0-5:amd64.^M Preparing to unpack .../064-libdleyna-core-1.0-5_0.6.0-3_amd64.deb ...^M Unpacking libdleyna-core-1.0-5:amd64 (0.6.0-3) ...^M dpkg: error processing archive /tmp/apt-dpkg-install-B5lolQ/064-libdleyna-core-1.0-5_0.6.0-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libdleyna-core-1.0.so.5.0.0', which is also in package libdleyna-core-1.0-3:amd64 0.6.0-1 Looks like a missing Breaks/Replaces: 0.6.0-1 had the bumped SONAME but the package wasn't renamed until later, so there's a file conflict with upgrades from that version only. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#951044: Revdeps which use the typelib FTBFS: dh_girepository: error: Could not find ICalGLib-3.0.typelib dependency
On Tue, Feb 11, 2020 at 12:53:38AM -0500, Nicolas Mora wrote: > Le 20-02-10 à 06 h 02, Iain Lane a écrit : > > > > Since this is breaking the build of reverse dependencies, I'm proposing > > to NMU a fix to DELAYED/5. The debdiff is attached. Feel free to fix it > > yourself sooner, though. > > > Thanks for the patch, I apply it to the package now! Thanks! Would you mind if I reschedule the NMU to be uploaded straight away so we don't have to wait to be able to build evolution-data-server? Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#951044: Revdeps which use the typelib FTBFS: dh_girepository: error: Could not find ICalGLib-3.0.typelib dependency
Package: src:libical3
Version: 3.0.7-1
Severity: serious
Tags: patch
Hi,
Reverse dependencies which want to use libical3's typelibs fail to build
with this message now:
dh_girepository: error: Could not find ICalGLib-3.0.typelib dependency
It's because that file is installed in the wrong location. See:
laney@disco> debdiff gir1.2-ical-3.0_3.0.5-2_amd64.deb
gir1.2-ical-3.0_3.0.7-1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/ICal-3.0.typelib
-rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/ICalGLib-3.0.typelib
Files in first .deb but not in second
-
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/girepository-1.0/ICal-3.0.typelib
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/girepository-1.0/ICalGLib-3.0.typelib
Control files: lines which differ (wdiff format)
[-Depends: gir1.2-glib-2.0, libical3 (>= 3.0.0)-]
Installed-Size: [-258-] {+257+}
Version: [-3.0.5-2-] {+3.0.7-1+}
Because of this change in the debdiff:
diff -Nru libical3-3.0.5/debian/gir1.2-ical-3.0.install
libical3-3.0.7/debian/gir1.2-ical-3.0.install
--- libical3-3.0.5/debian/gir1.2-ical-3.0.install 2019-01-12
17:56:50.0 +
+++ libical3-3.0.7/debian/gir1.2-ical-3.0.install 2020-02-02
14:14:47.0 +
@@ -1 +1,2 @@
-/usr/lib/*/girepository-1.0/*.typelib
+#! /usr/bin/dh-exec
+/usr/lib/*/girepository-1.0/*.typelib usr/lib/${DEB_HOST_MULTIARCH}
It misses the directory from the end of the destination. What was the
reason for that change? On the surface the previous rules file looks
fine to me, and unfortunately this change isn't mentioned in the
changelog so I can't see what problem was being fixed.
Since this is breaking the build of reverse dependencies, I'm proposing
to NMU a fix to DELAYED/5. The debdiff is attached. Feel free to fix it
yourself sooner, though.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru libical3-3.0.7/debian/changelog libical3-3.0.7/debian/changelog
--- libical3-3.0.7/debian/changelog 2020-02-02 14:14:47.0 +
+++ libical3-3.0.7/debian/changelog 2020-02-10 10:38:37.0 +
@@ -1,3 +1,11 @@
+libical3 (3.0.7-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix .typelib install path after .install files were converted to dh-exec.
+(Closes: #xxx)
+
+ -- Iain Lane Mon, 10 Feb 2020 10:38:37 +
+
libical3 (3.0.7-1) unstable; urgency=medium
* New upstream version. (Closes: #950461)
diff -Nru libical3-3.0.7/debian/gir1.2-ical-3.0.install
libical3-3.0.7/debian/gir1.2-ical-3.0.install
--- libical3-3.0.7/debian/gir1.2-ical-3.0.install 2020-02-02
14:14:47.0 +
+++ libical3-3.0.7/debian/gir1.2-ical-3.0.install 2020-02-10
10:38:25.0 +
@@ -1,2 +1,2 @@
#! /usr/bin/dh-exec
-/usr/lib/*/girepository-1.0/*.typelib usr/lib/${DEB_HOST_MULTIARCH}
+/usr/lib/*/girepository-1.0/*.typelib
usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0
Bug#948867: The dev shoulds depends on libx11-xcb-dev
Control: forwarded -1 https://salsa.debian.org/gstreamer-team/gst-plugins-base1.0/merge_requests/4/ On Tue, Jan 14, 2020 at 12:09:13PM +0100, Sebastien Bacher wrote: > The Build-Depends is needed as well, updated patch attached oops, I noticed this too before seeing the bug/patch, filed an MR on salsa: https://salsa.debian.org/gstreamer-team/gst-plugins-base1.0/merge_requests/4/ sorry for the duplication! Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#946896: hyphenation change in 1.44 series causes rendering differences
Package: libpango-1.0-0 Version: 1.44.7-1 Severity: normal Tags: upstream Control: forwarded -1 https://gitlab.gnome.org/GNOME/pango/issues/438 Please read the linked bug for full details. Upstream commit eb4882cada397268948ec24da046ff75615dfb9e made some changes relating to hyphenation - the part of pango's layouting algorithm that decides when it should insert a hyphen when breaking lines in the middle of paragraphs (because there isn't enough vertical space). Somehow this results in extra whitespace being inserted when it wasn't before. I think this is a regression (i.e. not an intended rendering change). The only practical impact that I know of so far is that it breaks gtk+3.0's reftests. In Ubuntu we had already updated to the 1.44 series before we discovered this impact - as a consequence we have marked the particular reftests as "known fail": https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gtk+3.0/commit/?id=315462e7c8cfabc755e6bcb420963e80bba6b22f Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#945015: only-branch only takes exact branch names
Package: src:kgb-bot Version: 1.55-2 Severity: normal Tags: upstream Hey, In the GNOME team we're going to start hosting Ubuntu's packaging branches on salsa soon. To avoid spamming #debian-gnome with Ubuntu notifications, I'd like to make KGB notify only on git commits to branches matching `debian/*`, `upstream/*` and `pristine-tar` to OFTC, and `ubuntu/*`, `upstream/*` and `pristine-tar` to Freenode. (possibly in future also doing this for merge request target branches too - maybe just extending `only_branch` to be considered for MRs as well) It seems that `only_branch` matches exactly (with `eq`) the branches that are given, though - this would mean that I have to list all possible `debian/foo` resp. `ubuntu/foo` branches in the corresponding webhooks and keep updating those as the distros create new releases. I think it'd be cool if this were instead to support globbing. If I were to propose a merge request which changes this into a glob (Text::Glob?), would you merge that? Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#943396: FTBFS on armhf: testsuite segfault
Package: src:fftw3 Version: 3.3.8-2 Severity: serious Tags: patch Hiya, We found this in an Ubuntu test rebuild, but I just confirmed on harris.d.o: > perl -w ./check.pl -r --estimate -c=5 -v `pwd`/bench > Executing "/home/laney/fftw3-3.3.8/tests/bench -o estimate --verbose=1 > --verify '//obrd7560' --verify '//ibrd7560' --verify '//ofrd7560' --verify > '//ifrd7560' --verify 'obrd7560' --verify 'ibrd7560' --verify 'ofrd7560' > --verify 'ifrd7560' --verify '//obcd7560' --verify '//ibcd7560' --verify > '//ofcd7560' --verify '//ifcd7560' --verify 'obcd7560' --verify 'ibcd7560' > --verify 'ofcd7560' --verify 'ifcd7560' --verify 'okd5e00*18' --verify > 'ikd5e00*18' --verify 'obrd8x3x7v7' --verify 'ibrd8x3x7v7' --verify > 'ofrd8x3x7v7' --verify 'ifrd8x3x7v7' --verify '//obcd8x3x7v7' --verify > '//ibcd8x3x7v7' --verify '//ofcd8x3x7v7' --verify '//ifcd8x3x7v7' --verify > 'obcd8x3x7v7' --verify 'ibcd8x3x7v7' --verify 'ofcd8x3x7v7' --verify > 'ifcd8x3x7v7' --verify 'okd17472o00' --verify 'ikd17472o00' --verify > 'obr5x8x10x14v6' --verify 'ibr5x8x10x14v6' --verify 'ofr5x8x10x14v6' --verify > 'ifr5x8x10x14v6' --verify '//obc5x8x10x14v6' --verify '//ibc5x8x10x14v6' > --verify '//ofc5x8x10x14v6' --verify '//ifc5x8x10x14v6' --verify > 'obc5x8x10x14v6' --verify 'ibc5x8x10x14v6' --verify 'ofc5x8x10x14v6' --verify > 'ifc5x8x10x14v6'" > //obrd7560 2.36623e-07 7.01972e-07 2.57654e-07 > //ibrd7560 2.70078e-07 7.01972e-07 2.48174e-07 > //ofrd7560 2.32727e-07 7.01972e-07 2.3547e-07 > Segmentation fault I can try to get a backtrace if you want, or feel free to grab the build from harris:~laney/fftw3-3.3.8 and poke at it. Daniel Van Vugt from the Ubuntu team investigated this a little bit and found that disabling Neon works around this problem. See the MR: https://salsa.debian.org/science-team/fftw3/merge_requests/1 Would appreciate your thoughts. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#941488: dbus-test-runner: diff for NMU version 16.10.0~bzr100+repack1-4.1
Control: tags 941488 + patch
Control: tags 941488 + pending
Hiya,
I thought I'd be helpful (to speed along the glib2.0 migration), so I've
prepared an NMU for dbus-test-runner (versioned as
16.10.0~bzr100+repack1-4.1) and uploaded it to DELAYED/5. Please feel
free to tell me if I should delay it longer, or cancel it yourself,
upload it under your own name or anything similar.
Cheers!
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru dbus-test-runner-16.10.0~bzr100+repack1/debian/changelog dbus-test-runner-16.10.0~bzr100+repack1/debian/changelog
--- dbus-test-runner-16.10.0~bzr100+repack1/debian/changelog 2018-11-02 21:43:17.0 +
+++ dbus-test-runner-16.10.0~bzr100+repack1/debian/changelog 2019-10-02 10:02:52.0 +0100
@@ -1,3 +1,15 @@
+dbus-test-runner (16.10.0~bzr100+repack1-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/dont-build-with-werror.patch: Don't build with -Werror;
+this is a bad idea for release builds as it means you get build failures
+for deprecations (Closes: #941488)
+ * debian/patches/replace-deprecated-functions.patch: tests: Replace
+deprecated g_main_{pending,iteration} with current
+g_main_context_{pending,iteration}
+
+ -- Iain Lane Wed, 02 Oct 2019 10:02:52 +0100
+
dbus-test-runner (16.10.0~bzr100+repack1-4) unstable; urgency=medium
* debian/control:
diff -Nru dbus-test-runner-16.10.0~bzr100+repack1/debian/patches/dont-build-with-werror.patch dbus-test-runner-16.10.0~bzr100+repack1/debian/patches/dont-build-with-werror.patch
--- dbus-test-runner-16.10.0~bzr100+repack1/debian/patches/dont-build-with-werror.patch 1970-01-01 01:00:00.0 +0100
+++ dbus-test-runner-16.10.0~bzr100+repack1/debian/patches/dont-build-with-werror.patch 2019-10-02 09:59:33.0 +0100
@@ -0,0 +1,97 @@
+Description: Don't build with -Werror; this is a bad idea for release builds as it means you get build failures for deprecations
+Author: Iain Lane
+Origin: https://bazaar.launchpad.net/~indicator-applet-developers/dbus-test-runner/trunk.16.10/revision/102
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 24a3f1f..7c44544 100644
+--- a/src/Makefile.am
b/src/Makefile.am
+@@ -6,7 +6,7 @@
+ $(COVERAGE_CFLAGS) \
+ -I$(top_srcdir) \
+ -DDEFAULT_SESSION_CONF="\"$(datadir)/dbus-test-runner/session.conf\"" \
+- -Wall -Werror -Wextra
++ -Wall -Wextra
+ dbus_test_runner_LDADD = $(DBUS_TEST_RUNNER_LIBS) \
+ $(top_builddir)/libdbustest/libdbustest.la
+ dbus_test_runner_LDFLAGS = $(COVERAGE_LDFLAGS)
+diff --git a/build.sh b/build.sh
+index 11bd1ed..4c691ab 100755
+--- a/build.sh
b/build.sh
+@@ -1,3 +1,3 @@
+ #!/bin/sh
+
+-gcc -o dbus-test-runner `pkg-config --cflags --libs glib-2.0 gobject-2.0` dbus-test-runner.c -Wall -Werror
++gcc -o dbus-test-runner `pkg-config --cflags --libs glib-2.0 gobject-2.0` dbus-test-runner.c -Wall
+diff --git a/libdbustest/Makefile.am b/libdbustest/Makefile.am
+index d76ff52..d048a83 100644
+--- a/libdbustest/Makefile.am
b/libdbustest/Makefile.am
+@@ -40,7 +40,7 @@
+ -DBUSTLE_DUAL_MONITOR="\"$(pkgdatadir)/dbus-test-bustle-handler\"" \
+ -DWATCHDOG="\"$(pkglibexecdir)/dbus-test-watchdog\"" \
+ -DG_LOG_DOMAIN=\"libdbustest\" \
+- -Wall -Werror -Wextra
++ -Wall -Wextra
+
+ libdbustest_la_LIBADD = \
+ libdbustest-generated.la \
+@@ -59,7 +59,7 @@
+ $(DBUS_TEST_RUNNER_CFLAGS) \
+ -I$(builddir) \
+ -DG_LOG_DOMAIN=\"libdbustest\" \
+- -Wall -Werror
++ -Wall
+
+ libdbustest_generated_la_SOURCES = \
+ dbus-mock-iface.h \
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 7eccc63..4f4aad9 100644
+--- a/tests/Makefile.am
b/tests/Makefile.am
+@@ -245,7 +245,7 @@
+ test-own-name.c
+ test_own_name_CFLAGS = \
+ $(DBUS_TEST_RUNNER_CFLAGS) \
+- -Wall -Werror
++ -Wall
+ test_own_name_LDADD = \
+ $(DBUS_TEST_RUNNER_LIBS)
+
+@@ -253,7 +253,7 @@
+ test-check-name.c
+ test_check_name_CFLAGS = \
+ $(DBUS_TEST_RUNNER_CFLAGS) \
+- -Wall -Werror
++ -Wall
+ test_check_name_LDADD = \
+ $(DBUS_TEST_RUNNER_LIBS)
+
+@@ -351,7 +351,7 @@
+ -I$(top_srcdir) \
+ -DSESSION_CONF="\"$(top_srcdir)/data/session.conf\"" \
+ -DGETNAME_PATH="\"$(abs_builddir)/test-libdbustest-getname\"" \
+- -Wall -Werror
++ -Wall
+ test_libdbustest_LDADD = \
+ $(DBUS_TEST_RUNNER_LIBS) \
+ $(top_builddir)/libdbustest/libdbustest.la
+@@ -360,7 +360,7 @@
+ test-libdbustest-getname.c
+ test_libdbustest_getname_CFLAGS = \
+ $(DBUS_TEST_RUNNER_CFLAGS) \
+- -Wall -Werror
++ -Wall
+ test_libdbustest_getname_LDADD = \
+ $(DBUS_TEST_RUNNER_LIBS)
+
+@@ -389,7 +389,7 @@
+ -I$(top_srcdir) \
+ -DSESSION_CONF="\"$(top_srcdir)/data/session.conf\"" \
+ -DGETNAME_PATH="\"$(abs_builddir)/
Bug#939378: mhash: diff for NMU version 0.9.9.9-7.1
Package: mhash Version: 0.9.9.9-7 Severity: normal Tags: patch pending Dear maintainer, Via Ubuntu we found a use-after-free in mhash. The testsuite fails with a segfault, with the following backtrace: Program received signal SIGSEGV, Segmentation fault. tcache_get (tc_idx=2) at malloc.c:2937 2937malloc.c: No such file or directory. (gdb) bt #0 tcache_get (tc_idx=2) at malloc.c:2937 #1 __GI___libc_malloc (bytes=36) at malloc.c:3051 #2 0xf7f9c0c5 in mutils_malloc (n=36) at stdfns.c:91 #3 0xf7f9b670 in mhash_init_int (type=MHASH_MD5) at mhash.c:319 #4 0xf7f9b86c in mhash_init (type=MHASH_MD5) at mhash.c:430 #5 0xf7f9b957 in mhash_hmac_deinit (td=0x5655a2e0, result=0x5655a390) at mhash.c:479 #6 0xf7f9ba9b in mhash_hmac_end_m (td=0x5655a2e0, hash_malloc=0xf7f9c0a0 ) at mhash.c:529 #7 0xf7f9bad2 in mhash_hmac_end (td=0x5655a2e0) at mhash.c:536 #8 0x565563d3 in main () at hmac_test.c:93 This is a use after free - see the attached diff. I've prepared an NMU for mhash (versioned as 0.9.9.9-7.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] diff -Nru mhash-0.9.9.9/debian/changelog mhash-0.9.9.9/debian/changelog --- mhash-0.9.9.9/debian/changelog 2014-05-24 08:48:29.0 +0100 +++ mhash-0.9.9.9/debian/changelog 2019-09-04 09:53:54.0 +0100 @@ -1,3 +1,12 @@ +mhash (0.9.9.9-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/patches/0015-mhash-0.9.9-no-free-before-use.patch: Take patch from +Fedora to fix use-after-free in the testsuite, which is failing in Ubuntu +and likely will in Debian at some point. + + -- Iain Lane Wed, 04 Sep 2019 09:53:54 +0100 + mhash (0.9.9.9-7) unstable; urgency=medium * add build dependency on pkg-config for its autoconf macros. diff -Nru mhash-0.9.9.9/debian/patches/0015-mhash-0.9.9-no-free-before-use.patch mhash-0.9.9.9/debian/patches/0015-mhash-0.9.9-no-free-before-use.patch --- mhash-0.9.9.9/debian/patches/0015-mhash-0.9.9-no-free-before-use.patch 1970-01-01 01:00:00.0 +0100 +++ mhash-0.9.9.9/debian/patches/0015-mhash-0.9.9-no-free-before-use.patch 2019-09-04 09:48:01.0 +0100 @@ -0,0 +1,16 @@ +Description: Don't free the 'tmp' variable when it's used later. +Author: Hanno Böck +Origin: https://src.fedoraproject.org/rpms/mhash/c/baa57fdba46abadbac4d05762d8812db1cb1b93d?branch=master + +diff -up mhash-0.9.9.9/src/hmac_test.c.nofree mhash-0.9.9.9/src/hmac_test.c +--- mhash-0.9.9.9/src/hmac_test.c.nofree 2019-07-29 14:44:55.856345469 -0400 mhash-0.9.9.9/src/hmac_test.c 2019-07-29 14:45:11.466021935 -0400 +@@ -72,7 +72,7 @@ int main() + return(MUTILS_INVALID_RESULT); + } + +- mutils_free(tmp); ++ /* mutils_free(tmp); */ + + /* Test No 2 */ + diff -Nru mhash-0.9.9.9/debian/patches/series mhash-0.9.9.9/debian/patches/series --- mhash-0.9.9.9/debian/patches/series 2014-05-24 08:43:38.0 +0100 +++ mhash-0.9.9.9/debian/patches/series 2019-09-04 09:46:16.0 +0100 @@ -12,3 +12,4 @@ 0012-autoconf-toe-step.patch 0013-autotools-updates.patch 0014-generate-mhash.pc.patch +0015-mhash-0.9.9-no-free-before-use.patch signature.asc Description: PGP signature
Bug#935801: Deprecated types in exported API as of GLib 2.62
Package: libgconf2-dev Version: 3.2.6-5ubuntu1 Severity: normal Tags: patch upstream Control: forwarded -1 https://gitlab.gnome.org/Archive/gconf/merge_requests/1 Hi there, gconf's headers contains functions which refer to types that are deprecated in GLib 2.62. For example, gconf's autopkgtest starts failing due to this: autopkgtest [13:41:39]: test build: [--- In file included from /usr/include/gconf/2/gconf/gconf-schema.h:26, from /usr/include/gconf/2/gconf/gconf.h:27, from /usr/include/gconf/2/gconf/gconf-client.h:25, from build_test.c:1: /usr/include/gconf/2/gconf/gconf-value.h:139:3: error: ‘GTime’ is deprecated: Use 'GDateTime' instead [-Werror=deprecated-declarations] 139 | GTime mod_time; /* time of the modification */ | ^ /usr/include/gconf/2/gconf/gconf-value.h:144:1: error: ‘GTime’ is deprecated: Use 'GDateTime' instead [-Werror=deprecated-declarations] 144 | GTime gconf_meta_info_mod_time (GConfMetaInfo *gcmi); | ^ /usr/include/gconf/2/gconf/gconf-value.h:153:46: error: ‘GTime’ is deprecated: Use 'GDateTime' instead [-Werror=deprecated-declarations] 153 | GTime mod_time); | ^ cc1: all warnings being treated as errors autopkgtest [13:41:40]: test build: ---] autopkgtest [13:41:40]: test build: - - - - - - - - - - results - - - - - - - - - - buildFAIL non-zero exit status 1 (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/g/gconf/20190825_134153_ffcc3@/log.gz) I wrote a patch to turn off these warnings - since it's not really possible to fix as that would be an API break - and forwarded it upstream. I was about to upload to Debian and then I noticed that gconf isn't pkg-gnome any more. https://gitlab.gnome.org/iainl/gconf/commit/6b97432b90c595ed799dce681101748568ae7f20 Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#934745: FTBFS against evolution-data-server 3.33: error: 1 missing arguments for `bool E.BookClient.add_contact (E.Contact, uint32, GLib.Cancellable?, out string)'
Package: src:folks Version: 0.11.4-1 Severity: normal Tags: patch Control: block 933577 by -1 Hi there, Folks needs updating for EDS 3.33, which is in experimental now. It's fixed upstream and I filed an MR with the required fix: https://salsa.debian.org/telepathy-team/folks/merge_requests/1/diffs (not a full package update which might be better, don't know) Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9
On Fri, Aug 02, 2019 at 11:26:48AM +0100, Simon McVittie wrote: > On Fri, 12 Jul 2019 at 11:16:53 +0100, Iain Lane wrote: > > I saw this on Ubuntu (9.1.0-8ubuntu1) but I've also reproduced this with > > 9.1.0-8 on sid (w/gcc-defaults from experimental to use gcc-9 by > > default). > > > > clutter's tests hang: > ... > > It's adding some stuff to a main loop and expecting it to finish when a > > particular signal handler is called. > > I can reproduce this with current unstable GLib, 2.60.6-1 (after reverting > the change that makes it explicitly build with gcc 8). > > In the non-working case, it looks as though the paint signal is not > getting emitted at all. The Clutter master clock appears to be the thing > that is meant to be scheduling GLib main-loop events in this case (and > then I got lost and couldn't work out what was wrong). Thanks for reproducing. For the record: at Debconf doko suggested to me that a way to start debugging this from the GCC end would be to produce one working and one "broken" build of the same version of glib2.0, and then copy object files from the broken to the working one until that too becomes broken. That sounded long / tedious / fiddly so we didn't manage to get round to doing it while we were both there, unfortunately. > I have been trying to reproduce this with the upstream GLib source code > so that I can try a build of GLib with ThreadSanitizer or AddressSanitizer, > but so far this has not been successful. Hmm, I thought I tried that and did manage to reproduce. Perhaps that's my memory being slightly faulty. Will try again (probably in a week after I'm back from holidays) if you don't beat me to it. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#933668: Doesn't build against libecal-2.0
Package: src:almanah Version: 0.11.1-2 Severity: wishlist Tags: patch upstream Control: block 933577 by -1 Hi, This is in experimental-NEW at the minute, but you can grab the packages out of evolution-data-server Vcs-Git to test this. tl;dr is that ecal broke API with this release. There are patches upstream which I grabbed and applied to the Debian package (untested though). Diff attached for you to review. If you wanted to upload to experimental now that would be OK, or you can wait until we're ready to go to unstable - at which point I'll raise the severity of this bug. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] diff -Nru almanah-0.11.1/debian/changelog almanah-0.11.1/debian/changelog --- almanah-0.11.1/debian/changelog 2018-03-26 17:21:29.0 +0100 +++ almanah-0.11.1/debian/changelog 2019-08-01 17:21:20.0 +0100 @@ -1,3 +1,18 @@ +almanah (0.11.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * events-Removed-Evolution-runtime-dependency.patch, +trivial-Fixed-indentation.patch, +event-factories-Port-to-libecal-2.0.patch, +data-Updated-the-AppData-format.patch, +Update-the-AppData-file-to-version-0.7.patch, +Add-a-missing-tag-to-the-AppData-file.patch, +libecal-2.0: +Backport a load of patches from upstream to enable building against +libecal-2.0. + + -- Iain Lane Thu, 01 Aug 2019 17:21:20 +0100 + almanah (0.11.1-2) unstable; urgency=medium * Increase Priority to optional. Priority: extra is deprecated diff -Nru almanah-0.11.1/debian/control almanah-0.11.1/debian/control --- almanah-0.11.1/debian/control 2018-01-05 08:46:04.0 + +++ almanah-0.11.1/debian/control 2019-08-01 16:56:47.0 +0100 @@ -2,15 +2,17 @@ Section: gnome Priority: optional Maintainer: Angel Abad -Build-Depends: debhelper (>= 9), - autotools-dev, +Build-Depends: appstream-util, + debhelper (>= 9), + dh-autoreconf, + gnome-common, intltool (>= 0.35.0), libglib2.0-dev, libgtk-3-dev (>= 3.5.6), libsqlite3-dev, libcryptui-dev (>= 3.0.0), libgpgme11-dev, - libecal1.2-dev (>= 3.6.0), + libecal2.0-dev, libedataserver1.2-dev (>= 3.6.0), libgtkspell3-3-dev Standards-Version: 3.9.6 diff -Nru almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch --- almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch 1970-01-01 01:00:00.0 +0100 +++ almanah-0.11.1/debian/patches/Add-a-missing-tag-to-the-AppData-file.patch 2019-08-01 17:11:39.0 +0100 @@ -0,0 +1,22 @@ +From 9c94abafe29415dbac1b6460af17c5af254e5859 Mon Sep 17 00:00:00 2001 +From: Richard Hughes +Date: Mon, 25 Jan 2016 15:12:21 + +Subject: [PATCH] Add a missing tag to the AppData file + +--- + data/almanah.appdata.xml.in | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/data/almanah.appdata.xml.in b/data/almanah.appdata.xml.in +index df93a75..d50f20c 100644 +--- a/data/almanah.appdata.xml.in b/data/almanah.appdata.xml.in +@@ -31,4 +31,5 @@ + AppMenu + ModernToolkit + ++ almanah + +-- +2.20.1 + diff -Nru almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch --- almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch 1970-01-01 01:00:00.0 +0100 +++ almanah-0.11.1/debian/patches/data-Updated-the-AppData-format.patch 2019-08-01 17:13:02.0 +0100 @@ -0,0 +1,26 @@ +From 45971f9b492b366989ae0afd89243218be9b5fb1 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?=C3=81lvaro=20Pe=C3=B1a?= +Date: Sat, 7 Mar 2015 20:54:43 +0100 +Subject: [PATCH] data: Updated the AppData format + +Included the fields "name" and "summary". +--- + data/almanah.appdata.xml.in | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/data/almanah.appdata.xml.in b/data/almanah.appdata.xml.in +index 17a0a7d..31db07d 100644 +--- a/data/almanah.appdata.xml.in b/data/almanah.appdata.xml.in +@@ -4,6 +4,8 @@ + almanah.desktop + CC0-1.0 + GPL-3.0+ ++ Almanah Diary ++ <_summary>Keep a diary of your life + + <_p> + Almanah Diary is an application to allow you to keep a diary of your life. +-- +2.20.1 + diff -Nru almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch --- almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch 1970-01-01 01:00:00.0 +0100 +++ almanah-0.11.1/debian/patches/event-factories-Port-to-libecal-2.0.patch 2019-08-01 16:52:27.0 +0100 @@ -0,0 +1,821 @@ +From cb11d217448161562ae6eb4b94d01186e89b275f Mon Sep 17 00:00:00 2001 +Fro
Bug#933577: transition: evolution-data-server
Package: release.debian.org Severity: normal Tags: moreinfo User: release.debian@packages.debian.org Usertags: transition Hi, You're probably as used to these as I am by now. :-) I've uploaded to experimental-NEW and I'm in the process of testing r(-build)-deps now. I'll make any bugs block this one so we can see what's needed. This definitely *will* need sourceful changes to quite a few packages. +moreinfo for now until we're ready to go. Ben file (not super confident in the correctness of this but I guess we can fix it later): title = "evolution-data-server"; is_affected = .depends ~ /libebook-1.2-19|libedata-book-1.2-25|libebook-contacts-1.2-2|libecal-1.2-19|libedata-cal-1.2-29|libebook-contacts-1.2-2/ | .depends ~ /libebook-1.2-20|libedata-book-1.2-26|libebook-contacts-1.2-4|libecal-2.0-1|libedata-cal-2.0-1|libebook-contacts-1.2-3/ | .build-depends /libecal1.2-dev|libedata-cal1.2-dev/ | .build-depends /libecal2.0-dev|libedatacal1.2-dev/; is_good = .depends ~ /libebook-1.2-20|libedata-book-1.2-26|libebook-contacts-1.2-4|libecal-2.0-1|libedata-cal-2.0-1|libebook-contacts-1.2-3/ | .build-depends /libecal1.2-dev|libedata-cal1.2-dev/; is_bad = .depends ~ /libebook-1.2-19|libedata-book-1.2-25|libebook-contacts-1.2-2|libecal-1.2-19|libedata-cal-1.2-29|libebook-contacts-1.2-2/ | .build-depends /libecal2.0-dev|libedatacal1.2-dev/; Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#933573: FTBFS against evolution-data-server 3.33.4: error: too few arguments to function ‘e_book_client_add_contact_sync’
Package: src:eweous Version: 0.11 Severity: wishlist Tags: patch upstream Control: user pkg-gnome-maintain...@lists.alioth.debian.org Control: usertag -1 = evolution-data-server-3-33 Hi, This version of e-d-s is still in experimental-NEW, but I'm trying to prepare the archive for it to be uploaded (and I want to upload to Ubuntu sooner probably). If you build from Vcs-Git, you should be able to test this patch if you like. eweous fails to build. One of the functions has changed its signature. Build log attached, and a patch. Instead of E_BOOK_OPERATION_FLAG_NONE, you could pass any other of the flags if that's appropriate. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] sbuild (Debian sbuild) 0.77.1 (10 September 2018) on disco +==+ | eweouz 0.11 (amd64) Wed, 31 Jul 2019 16:11:23 + | +==+ Package: eweouz Version: 0.11 Source Version: 0.11 Distribution: experimental Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/experimental-amd64-3688a7c7-abac-464b-afbd-23d258e6e54c' with '<>' I: NOTICE: Log filtering will replace 'build/eweouz-aSh58r/resolver-m1XVh2' with '<>' +--+ | Update chroot| +--+ Get:1 file:/srv/mirrors/debian sid InRelease [149 kB] Get:1 file:/srv/mirrors/debian sid InRelease [149 kB] Get:2 file:/srv/mirrors/debian experimental InRelease [78.9 kB] Get:2 file:/srv/mirrors/debian experimental InRelease [78.9 kB] Get:3 file:/srv/mirrors/debian sid/contrib Sources [48.6 kB] Ign:3 file:/srv/mirrors/debian sid/contrib Sources Get:4 file:/srv/mirrors/debian sid/main Sources [8519 kB] Ign:4 file:/srv/mirrors/debian sid/main Sources Get:5 file:/srv/mirrors/debian sid/contrib amd64 Packages [58.3 kB] Ign:5 file:/srv/mirrors/debian sid/contrib amd64 Packages Get:6 file:/srv/mirrors/debian sid/main amd64 Packages [8380 kB] Ign:6 file:/srv/mirrors/debian sid/main amd64 Packages Get:3 file:/srv/mirrors/debian sid/contrib Sources [48.6 kB] Get:4 file:/srv/mirrors/debian sid/main Sources [8519 kB] Get:5 file:/srv/mirrors/debian sid/contrib amd64 Packages [58.3 kB] Get:6 file:/srv/mirrors/debian sid/main amd64 Packages [8380 kB] Get:7 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [43.2 kB] Get:8 file:/srv/mirrors/debian experimental/main Sources [387 kB] Ign:8 file:/srv/mirrors/debian experimental/main Sources Get:9 file:/srv/mirrors/debian experimental/main amd64 Packages [423 kB] Ign:9 file:/srv/mirrors/debian experimental/main amd64 Packages Get:8 file:/srv/mirrors/debian experimental/main Sources [387 kB] Get:9 file:/srv/mirrors/debian experimental/main amd64 Packages [423 kB] Get:10 https://swift-proxy.bos01.canonistack.canonical.com:8080/v1/AUTH_1c975a261cc3453c8543c7485f5e4560/debian experimental InRelease [5991 B] Get:11 https://swift-proxy.bos01.canonistack.canonical.com:8080/v1/AUTH_1c975a261cc3453c8543c7485f5e4560/debian experimental/main amd64 Packages [24.2 kB] Get:12 http://incoming.debian.org/debian-buildd buildd-unstable/contrib amd64 Packages [3788 B] Get:13 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages [158 kB] Fetched 235 kB in 2s (102 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Local sources - eweouz_0.11.dsc exists in .; copying to chroot I: NOTICE: Log filtering will replace 'build/eweouz-aSh58r/eweouz-0.11' with '<>' I: NOTICE: Log filtering will replace 'build/eweouz-aSh58r' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper (>= 9), autotools-dev, emacs | emacsen, libedataserver1.2-dev, libebook1.2-dev, libglib2.0-dev, dh-autoreconf, libedataserver1.2-dev (>= 3.33.4), libebook1.2-dev (>= 3.33.4), build-essential, fakeroot Filter
Bug#933548: transition: gnome-desktop3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: tags -1 moreinfo Hi, Not for right now, but I'm filing this straight away for information. gnome-desktop3 has bumped SONAME from 17 to 18 and so we need a transition. I've uploaded to experimental/NEW and test built the rdepends locally. Everything succeeded except for gnome-contacts which I think is an independent FTBFS. Logs: https://people.debian.org/~laney/libgnome-desktop-3-18/ There is a sourceful change required to gnome-shell to adjust to the API break - this is a runtime error rather than build-time (I guess I should add a Breaks): https://gitlab.gnome.org/GNOME/gnome-shell/commit/f9a7718dda9641bf3750faba789edd701dfff5da Ben file: title = "gnome-desktop3"; is_affected = .depends ~ "libgnome-desktop-3-17" | .depends ~ "libgnome-desktop-3-18"; is_good = .depends ~ "libgnome-desktop-3-18"; is_bad = .depends ~ "libgnome-desktop-3-17"; Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9
Source: gcc-9 Version: 9.1.0-8 Severity: important Control: affects -1 gcc libglib2.0-0 Hiya, I saw this on Ubuntu (9.1.0-8ubuntu1) but I've also reproduced this with 9.1.0-8 on sid (w/gcc-defaults from experimental to use gcc-9 by default). clutter's tests hang like this: 0x77b316f4 in __GI___poll (fds=0x558d0420, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) bt #0 0x77b316f4 in __GI___poll (fds=0x558d0420, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x77c62c9e in g_main_context_poll (priority=, n_fds=2, fds=0x558d0420, timeout=, context=0x555b0cd0) at ../glib/gmain.c:4213 #2 g_main_context_iterate (context=0x555b0cd0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/gmain.c:3909 #3 0x77c63023 in g_main_loop_run (loop=0x55f01d10) at ../glib/gmain.c:4108 #4 0x6634 in verify_redraw (expected_paint_count=1, data=, data=) at actor-offscreen-redirect.c:172 Here's the bit of code. https://sources.debian.org/src/clutter-1.0/1.26.2+dfsg-10/tests/conform/actor-offscreen-redirect.c/#L172 It's adding some stuff to a main loop and expecting it to finish when a particular signal handler is called. There's obviously a lot of code going on here (this isn't anything like a minimal testcase, and glib2.0's own testsuite & autopkgtests pass so it's not like GMainLoop is completely broken). I found an upstream report which I suspect is the same thing: https://gitlab.gnome.org/GNOME/clutter/issues/6 Things which make it work again - Building glib2.0 w/gcc-9 -O1 (and -O0) - Building w/gcc-8 (obviously) Happy to help try to narrow this down to the optimisation that's breaking glib and/or the code in glib that's breaking the optimisation. Maybe in person at Debconf. For now I'm going to upload a glib2.0 that builds with gcc-8 explicitly. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#894880: ruby-graphviz: please use HOME (or do not override) instead of G_HOME
Control: severity -1 minor On Thu, Apr 05, 2018 at 09:07:09AM +0100, Simon McVittie wrote: > Package: ruby-graphviz > Version: 1.2.3-1 > Severity: normal > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: g-home > > ruby-graphviz has this in d/rules: > > > # Tests try to read /root/.pangorc and fail if we don't set this variable. > > # See #570313 for more details > > export G_HOME=/ > > […] > Please investigate whether this is still needed, and if it is, set HOME=/ > instead. I just test-built with libglib2.0-0 2.60.4-1 from experimental. This version of glib2.0 does not respect G_HOME. The build ran the upstream testsuite, and it all passed, so I believe the above portion of debian/rules is likely to be obsolete and can be removed. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hi Simon, others, Thanks to those involved so far in shepherding this side of the issue along. And also for poking me (repeatedly!) to reply. On Wed, Jun 19, 2019 at 09:19:49PM +0100, Simon McVittie wrote: > On Wed, 19 Jun 2019 at 17:33:55 +0100, Jonathan Dowland wrote: > > So far as I am aware there is still radio silence from active GNOME > > packaging team members regarding this issue. No comment yet on the > > patch I adapted, positive or negative; this bug (#927667) remains > > at an RC severity. Right, sorry about that. It's a big lack of spoons for me (please consider that if you are thinking about rebutting my points below). I personally find this kind of topic a bit draining, although I appreciate that the temperature of the bug (not the previous -devel thread) is quite low. Thanks for that. > (Adding debian-gtk-gnome, debian-desktop and some people who might have > useful input to Cc) > […] > - Ubuntu GNOME team: which recent Ubuntu versions, if any, are using > Wayland for their GNOME-based desktop? Seb's explained that, and the reasons why that decision was made. So you can have my inconclusive personal opinion: I've been deliberately using Wayland-on-Ubuntu and Wayland-on-Debian the whole time, and the only thing that has irritated *me* was one time I couldn't screen share from Firefox. I *like* that it's raised the bar for privilege separation (the Synaptic case), as I find it quite distasteful to be running the entire thing as root. I acknowledge that the shell-crashing-crashes-the-session model could be uncomfortable sometimes — but my experience has not been one where that happens. Some of the upstream improvements (e.g. fractional scaling, which is still experimental) are Wayland-only. I've read and understood the counter-arguments posted on the bug. I don't feel in a particularly good position with respect to weighing up the balance here. If you are affected by a Wayland-specific bug, especially if it impacts you frequently (e.g. you can't do something you need to do, or the shell repeatedly crashes / the mouse becomes unresponsive / similar), that is going to be really quite irritating. And I share Ansgar's concern about this all being very late now. Part of that is down to our (GNOME team at large) lack of engagement on the bug — apologies again — but it would have felt late to me even at the end of April. That said, Ubuntu has been shipping with this configuration and we don't know of any particular issues. Release team, what do you think? In conclusion, I will not stand in the way of anyone if they want to execute this change, but it's not likely to be me doing it. > I've left some comments on > https://salsa.debian.org/gnome-team/gdm/merge_requests/8 regarding the > technical side of the proposed change. Someone could probably look in Ubuntu's gdm3 package to see what we're doing. We provide "GNOME" (Xorg, the default) and "GNOME on Wayland" sessions. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#929705: unblock: nautilus/3.30.5-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nautilus.
Nautilus contains an embedded copy of the thumbnailing code from
`gnome-desktop3'. This has received several updates upstream, which it'd
be great to get into buster. Here's my changelog entry, to avoid
repeating myself too much:
* Update gnome-desktop code. Nautilus contains a copy of this code,
which originated in gnome-desktop3.
+ Fixes a potential crash during thumbnailing
+ Fixes thumbnailer on 32-bit systems where /lib64 is not available.
+ Also improves handling of usrmerged and non-usrmerged systems.
+ Mounts the fontconfig cache dir, to improve performance if fontconfig
is used
- Add a corresponding BD on libfontconfig1-dev, to fetch the needed
variable from its pcfile.
+ Fixes seccomp filter bypass. CVE-2019-11461
+ Closes: #928054
I don't actually know how the CVE could be triggered from Nautilus, but
it got 'medium' severity and a request from the security team to be
fixed. That's the main reason for this upload, but there are also other
important fixes in this code too. I'd be grateful if you could consider
it for buster.
unblock nautilus/3.30.5-2
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru nautilus-3.30.5/debian/changelog nautilus-3.30.5/debian/changelog
--- nautilus-3.30.5/debian/changelog2018-12-22 13:53:04.0 +
+++ nautilus-3.30.5/debian/changelog2019-05-29 12:47:33.0 +0100
@@ -1,3 +1,20 @@
+nautilus (3.30.5-2) unstable; urgency=medium
+
+ * debian/control{,.in}, gbp.conf: Update debian branch to debian/buster
+ * Update gnome-desktop code. Nautilus contains a copy of this code,
+which originated in gnome-desktop3.
+ + Fixes a potential crash during thumbnailing
+ + Fixes thumbnailer on 32-bit systems where /lib64 is not available.
+ + Also improves handling of usrmerged and non-usrmerged systems.
+ + Mounts the fontconfig cache dir, to improve performance if fontconfig
+is used
+- Add a corresponding BD on libfontconfig1-dev, to fetch the needed
+ variable from its pcfile.
+ + Fixes seccomp filter bypass. CVE-2019-11461
+ + Closes: #928054
+
+ -- Iain Lane Wed, 29 May 2019 12:47:33 +0100
+
nautilus (3.30.5-1) unstable; urgency=medium
* New upstream release
diff -Nru nautilus-3.30.5/debian/control nautilus-3.30.5/debian/control
--- nautilus-3.30.5/debian/control 2018-12-22 13:53:04.0 +
+++ nautilus-3.30.5/debian/control 2019-05-29 12:47:33.0 +0100
@@ -15,6 +15,7 @@
gobject-introspection (>= 0.9.12-4~),
gtk-doc-tools (>= 1.10),
libatk1.0-dev (>= 1.32.0),
+ libfontconfig1-dev,
libgail-3-dev,
libgexiv2-dev (>= 0.10.0),
libgirepository1.0-dev (>= 0.10.7-1~),
@@ -41,7 +42,7 @@
Rules-Requires-Root: no
Homepage: https://wiki.gnome.org/action/show/Apps/Nautilus
Vcs-Browser: https://salsa.debian.org/gnome-team/nautilus
-Vcs-Git: https://salsa.debian.org/gnome-team/nautilus.git
+Vcs-Git: https://salsa.debian.org/gnome-team/nautilus.git -b debian/buster
Standards-Version: 4.2.1
Package: nautilus
diff -Nru nautilus-3.30.5/debian/control.in nautilus-3.30.5/debian/control.in
--- nautilus-3.30.5/debian/control.in 2018-12-22 13:53:04.0 +
+++ nautilus-3.30.5/debian/control.in 2019-05-29 12:47:33.0 +0100
@@ -11,6 +11,7 @@
gobject-introspection (>= 0.9.12-4~),
gtk-doc-tools (>= 1.10),
libatk1.0-dev (>= 1.32.0),
+ libfontconfig1-dev,
libgail-3-dev,
libgexiv2-dev (>= 0.10.0),
libgirepository1.0-dev (>= 0.10.7-1~),
@@ -37,7 +38,7 @@
Rules-Requires-Root: no
Homepage: https://wiki.gnome.org/action/show/Apps/Nautilus
Vcs-Browser: https://salsa.debian.org/gnome-team/nautilus
-Vcs-Git: https://salsa.debian.org/gnome-team/nautilus.git
+Vcs-Git: https://salsa.debian.org/gnome-team/nautilus.git -b debian/buster
Standards-Version: 4.2.1
Package: nautilus
diff -Nru nautilus-3.30.5/debian/gbp.conf nautilus-3.30.5/debian/gbp.conf
--- nautilus-3.30.5/debian/gbp.conf 2018-12-22 13:53:04.0 +
+++ nautilus-3.30.5/debian/gbp.conf 2019-05-29 12:47:33.0 +0100
@@ -1,6 +1,6 @@
[DEFAULT]
pristine-tar = True
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
upstream-vcs-tag = %(version)s
diff -Nru
nautilus-3.30.5/debian/patches/Define-symbol-needed-for-gnome-desktop.patch
nautilus-3.30.5/debian/patches/Define-symbol-needed-for-gnome-desktop.pa
Bug#897975: [gdm3]
Hi, Sorry for the delay. Niels pointed me at this bug, which is suspiciously similar to one we saw on Ubuntu around the same time ... On Wed, Jun 13, 2018 at 01:43:18PM +0200, rastersoft wrote: > After several tests, I started to suspect that the problem could be in the > firmware loading: my hypothesis is that when I use my SSD hard disk, the > loading is so fast that the graphic card is still not available when GDM > tries to boot in Wayland mode, so it fails and tries again in X11 mode. At > this moment it has ended loading the firmware as is available, so this mode > succeeds, but without offering Wayland because that failed before. If I > enter a session and exit, GDM is reloaded and this time the Wayland mode > works because the graphics card's firmware is already loaded. > > To test this I renamed /usr/sbin/gdm3 to /usr/sbin/gdm3_bin, and created a > little script at /usr/sbin/gdm3 that waits 3 seconds before launching the > true gdm3. With this quick and dirty hack everything works fine: GDM3 is > always shown after booting, and I have Wayland available. > > Of course, this is not a true solution: the system should wait until the > graphics card is fully available before continuing loading, and not just > "add a delay". But I think it proofs that there is some kind of race > condition during boot. Your theory is right - GDM is starting up before the DRM devices that it needs are available, and it doesn't handle that very well. We have a workaround in place in Ubuntu which seems to have fixed the bug. There is actually a logind boolean property "CanGraphical" for this, that was introduced so display managers like GDM can wait before they start up. But the branch to make GDM respect this property[0] isn't yet merged because it is a bit unreliable so far. So I cherry-picked the Ubuntu workaround to a branch on salsa. Would you be able to try it please? (Test built but not tried it myself yet, so sorry if there's some stupid mistake.) https://salsa.debian.org/gnome-team/gdm/commits/wip/gdm-wait-for-drm I can't test this myself. Apparently none of my machines are capable of tickling this bug. :( Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] [0] https://gitlab.gnome.org/GNOME/gdm/merge_requests/37 signature.asc Description: PGP signature
Bug#926948: unblock: tracker/2.1.8-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tracker
This fixes crash bug #926946 that I filed, although we don't have an
existing report of it / steps to reproduce, so you might not consider
this really RC. Up to you.
unblock tracker/2.1.8-2
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru tracker-2.1.8/debian/changelog tracker-2.1.8/debian/changelog
--- tracker-2.1.8/debian/changelog 2019-02-21 01:26:33.0 +
+++ tracker-2.1.8/debian/changelog 2019-04-12 16:20:46.0 +0100
@@ -1,3 +1,10 @@
+tracker (2.1.8-2) unstable; urgency=medium
+
+ * gbp.conf: Update debian-branch for buster
+ * Cherry-pick upstream patch to fix crash (Closes: #926946)
+
+ -- Iain Lane Fri, 12 Apr 2019 16:20:46 +0100
+
tracker (2.1.8-1) unstable; urgency=medium
* New upstream release
diff -Nru tracker-2.1.8/debian/control tracker-2.1.8/debian/control
--- tracker-2.1.8/debian/control2019-02-21 01:26:33.0 +
+++ tracker-2.1.8/debian/control2019-04-12 16:20:46.0 +0100
@@ -6,7 +6,7 @@
Section: utils
Priority: optional
Maintainer: Debian GNOME Maintainers
-Uploaders: Iain Lane , Jeremy Bicha , Tim
Lunn
+Uploaders: Jeremy Bicha , Michael Biebl ,
Tim Lunn
Build-Depends: debhelper (>= 11),
gnome-common,
pkg-config,
diff -Nru tracker-2.1.8/debian/gbp.conf tracker-2.1.8/debian/gbp.conf
--- tracker-2.1.8/debian/gbp.conf 2019-02-21 01:26:33.0 +
+++ tracker-2.1.8/debian/gbp.conf 2019-04-12 16:20:46.0 +0100
@@ -1,6 +1,6 @@
[DEFAULT]
pristine-tar = True
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
upstream-vcs-tag = %(version)s
diff -Nru tracker-2.1.8/debian/patches/series
tracker-2.1.8/debian/patches/series
--- tracker-2.1.8/debian/patches/series 2019-02-21 01:26:33.0 +
+++ tracker-2.1.8/debian/patches/series 2019-04-12 16:20:46.0 +0100
@@ -5,3 +5,4 @@
libtracker-miners-common-Make-g_error-a-soft-error.patch
build-Restore-right-soversion-to-libraries.patch
functional-tests-Require-Bash-for-test-runner.patch
+tracker-miner-Fix-cancellation-of-g_file_enumerator_next_.patch
diff -Nru
tracker-2.1.8/debian/patches/tracker-miner-Fix-cancellation-of-g_file_enumerator_next_.patch
tracker-2.1.8/debian/patches/tracker-miner-Fix-cancellation-of-g_file_enumerator_next_.patch
---
tracker-2.1.8/debian/patches/tracker-miner-Fix-cancellation-of-g_file_enumerator_next_.patch
1970-01-01 01:00:00.0 +0100
+++
tracker-2.1.8/debian/patches/tracker-miner-Fix-cancellation-of-g_file_enumerator_next_.patch
2019-04-12 16:20:46.0 +0100
@@ -0,0 +1,43 @@
+From: Andrea Azzarone
+Date: Mon, 1 Apr 2019 16:52:15 +0100
+Subject: tracker-miner: Fix cancellation of
+ g_file_enumerator_next_files_async
+
+The async op is not owner of the user data, so it may be actually gone in the
+GAsyncReadyCallback. Ensure we only use it on success or on other errors than
+cancelled.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926946
+Bug-Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1822629
+Bug-Upstream: https://gitlab.gnome.org/GNOME/tracker/issues/86
+Origin: upstream, commit:465b8031d0a73ac775952c07d0374206746a8a46
+Applied-Upstream: 2.2.2
+---
+ src/libtracker-miner/tracker-crawler.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/libtracker-miner/tracker-crawler.c
b/src/libtracker-miner/tracker-crawler.c
+index 93b1ab1..4031d86 100644
+--- a/src/libtracker-miner/tracker-crawler.c
b/src/libtracker-miner/tracker-crawler.c
+@@ -899,7 +899,7 @@ enumerate_next_cb (GObject *object,
+ {
+ DataProviderData *dpd;
+ GList *info;
+- GError *error = NULL;
++ g_autoptr(GError) error = NULL;
+
+ info = g_file_enumerator_next_files_finish (G_FILE_ENUMERATOR (object),
result, );
+ dpd = user_data;
+@@ -918,9 +918,9 @@ enumerate_next_cb (GObject *object,
+ g_warning ("Could not enumerate next item in
container / directory '%s', %s",
+ uri, error ? error->message : "no
error given");
+ g_free (uri);
++ } else {
++ return;
+ }
+-
+- g_clear_error ();
+ } else {
+ /* Done enumerating, start processing what we got ... */
+ data_provider_data_add (dpd);
Bug#926946: tracker-miner-fs SIGSEGV in process_func_start()
Package: src:tracker Version: 2.1.8-1 Severity: serious Tags: patch upstream fixed-upstream Hi, Just filing so I have a bug reference for the unblock. In Ubuntu's error tracker we noticed reports of a crash in tracker-miner that looks like this: #0 0x7f1a2c1db676 in process_func_start (crawler=0x0) at tracker-crawler.c:713 No locals. #1 0x7f1a2c1db9d0 in enumerate_next_cb (object=, result=, user_data=0x7f19ec0886f0) at tracker-crawler.c:930 dpd = 0x7f19ec0886f0 info = error = 0x0 #2 0x7f1a2c030df6 in next_async_callback_wrapper (source_object=0x55d54803ccd0, res=0x55d547f2e1b0, user_data=0x7f19ec0886f0) at ../../../gio/gfileenumerator.c:305 enumerator = 0x55d54803ccd0 #3 0x7f1a2c070059 in g_task_return_now (task=0x55d547f2e1b0) at ../../../gio/gtask.c:1209 No locals. #4 0x7f1a2c070099 in complete_in_idle_cb (task=0x55d547f2e1b0) at ../../../gio/gtask.c:1223 No locals. #5 0x7f1a2be98958 in ?? () No symbol table info available. #6 0x7ffecede7820 in ?? () No symbol table info available. #7 0x7f1a in ?? () No symbol table info available. #8 0x in ?? () No symbol table info available. Andrea Azzarone from the Canonical team fixed this upstream[0]. I'm proposing to include the fix in buster, and I'm uploading to unstable now to hopefully achieve this. These are automated reports and I don't have steps to reproduce I'm afraid. You can see from frame #0 that process_func_start() is passed NULL. The fix avoids calling this if the operation has been cancelled, in which case data_provider_end() will be called, which frees the data. That's how we get NULL there. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] [0] https://gitlab.gnome.org/GNOME/tracker/merge_requests/86
Bug#926841: unblock: librsvg/2.44.10-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
Maybe you'll see this anyway since the upload closes an RC bug?
librsvg 2.44.10-2 (just uploaded, not accepted yet) is am upload only to
fix a build failure on (at least) i386, AKA #926840. Please could you
unblock it?
unblock librsvg/2.44.10-2
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru librsvg-2.44.10/debian/changelog librsvg-2.44.10/debian/changelog
--- librsvg-2.44.10/debian/changelog2018-12-11 21:02:52.0 +
+++ librsvg-2.44.10/debian/changelog2019-04-11 09:29:30.0 +0100
@@ -1,3 +1,13 @@
+librsvg (2.44.10-2) unstable; urgency=medium
+
+ * debian/patches/typenum-i386-ftbfs.patch: backport an upstream fix for a
+build failure in the vendored typenum crate on i386 (LP: #1823426)
+(Closes: #926840)
+ * debian/patches/i386-rounding-errors.patch: fix a rounding error on i386
+that would result in a unit test failure
+
+ -- Olivier Tilloy Thu, 11 Apr 2019 09:29:30
+0100
+
librsvg (2.44.10-1) unstable; urgency=medium
* New upstream release
diff -Nru librsvg-2.44.10/debian/patches/i386-rounding-errors.patch
librsvg-2.44.10/debian/patches/i386-rounding-errors.patch
--- librsvg-2.44.10/debian/patches/i386-rounding-errors.patch 1970-01-01
01:00:00.0 +0100
+++ librsvg-2.44.10/debian/patches/i386-rounding-errors.patch 2019-04-11
09:29:30.0 +0100
@@ -0,0 +1,17 @@
+Description: fix a rounding error on i386 that would result in a unit test
failure
+Author: Olivier Tilloy
+Origin:
https://gitlab.gnome.org/GNOME/librsvg/commit/aaef7bb37c9f0cceffc3bdf2138ec80242349653
+
+--- a/rsvg_internals/src/marker.rs
b/rsvg_internals/src/marker.rs
+@@ -589,7 +589,9 @@ fn find_outgoing_directionality_forwards
+
+ // Normalizes an angle to [0.0, 2*PI)
+ fn normalize_angle(mut angle: f64) -> f64 {
+-if angle < 0.0 {
++if angle.abs() < std::f64::EPSILON {
++angle = angle.abs();
++} else if angle < 0.0 {
+ while angle < 0.0 {
+ angle += PI * 2.0;
+ }
diff -Nru librsvg-2.44.10/debian/patches/series
librsvg-2.44.10/debian/patches/series
--- librsvg-2.44.10/debian/patches/series 2018-12-11 21:02:52.0
+
+++ librsvg-2.44.10/debian/patches/series 2019-04-11 09:29:30.0
+0100
@@ -1 +1,3 @@
10_rsvg-gz.patch
+typenum-i386-ftbfs.patch
+i386-rounding-errors.patch
diff -Nru librsvg-2.44.10/debian/patches/typenum-i386-ftbfs.patch
librsvg-2.44.10/debian/patches/typenum-i386-ftbfs.patch
--- librsvg-2.44.10/debian/patches/typenum-i386-ftbfs.patch 1970-01-01
01:00:00.0 +0100
+++ librsvg-2.44.10/debian/patches/typenum-i386-ftbfs.patch 2019-04-11
09:29:30.0 +0100
@@ -0,0 +1,22 @@
+Descriptpion: round result of (highest as f64).log(2.0)
+Author: Michael Hudson-Doyle
+Origin:
https://github.com/paholg/typenum/commit/14a3322d1081fd63d5eb44bf8ab8f90676208228
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/1823426
+
+--- a/vendor/typenum/build/main.rs
b/vendor/typenum/build/main.rs
+@@ -77,7 +77,7 @@ pub fn no_std() {}
+ fn main() {
+ let highest: u64 = 1024;
+
+-let first2: u32 = (highest as f64).log(2.0) as u32 + 1;
++let first2: u32 = (highest as f64).log(2.0).round() as u32 + 1;
+ let first10: u32 = (highest as f64).log(10.0) as u32 + 1;
+ let uints = (0..(highest + 1))
+ .chain((first2..64).map(|i| 2u64.pow(i)))
+--- a/vendor/typenum/.cargo-checksum.json
b/vendor/typenum/.cargo-checksum.json
+@@ -1 +1 @@
+-{"files":{".travis.yml":"8cb8369c4baa618c5add98700b8b0509f5a63f15c1dc9474d4bc967d80439a4a","CHANGELOG.md":"caf37574d41c38570e892c4fed38cbc2fd22794ec512949c1f0faad1d866fced","Cargo.toml":"58822547c70a09449e6a069e6c197423a9e471d993ebf4ea20101e042781edf7","LICENSE":"a825bd853ab71619a4923d7b4311221427848070ff44d990da39b0b274c1683f","README.md":"7a19a1fb2f219fbc270535e0fee2caa96968b976cd74d33d12e2f2ef436d0895","build/main.rs":"44d33ee79a76a90a769096547ba4c7a5d3822afffeed025dfbcc5bb755227d52","build/op.rs":"a393b6818384a50688db8cb923891f86ccce39a9dccbf7c684efb9bef83b4acf","build/tests.rs":"a04fd3185ea8b19c36cb939178e5fedf16b4b36c2df0a2e79593339d998bd1ce","src/array.rs":"7243dbe44f3818c852c67bd0c3af14d57473fb9c3efda2c0d98251b3fe8b4d57","src/bit.rs":"023f9f6768331ac17de72b6248c6a9d6a7b856842f56067c9c1e04b729ed9e04","src/int.rs":"de4c49717a7a40572e579fad2380f29698c5571844ff1462e368531072dba55e","src/lib.rs":"2a58
Bug#926409: lintian: autopkgtest takes very long to finish
On Thu, Apr 04, 2019 at 12:10:31PM -0700, Felix Lechner wrote: > On Thu, Apr 4, 2019 at 10:42 AM Chris Lamb wrote: > > > > * I'm not sure *how* we can speed up the tests. I mean, they all > >essentially involve building Debian packages with all the usual > >debhelper calls, etc. Speeding *this* up is somewhat out-of-scope > >of this Lintian wishlist issue, alas. > > > > However, perhaps Felix has some input here as he has been doing a lot > > of work on the test suite recently? > > About 95% of the time is spent building packages, even though they > almost never change. The tests would run much faster if we shipped > pre-built packages. One way to accomplish that would be to package the > tests separately. Yep, that'd be the way to go IMO. You aren't trying to test dpkg-buildpackage or parts of the package-building toolchain - you're trying to test Lintian, which operates on the results of that. Shunting this part to a one-time operation would be eminently sensible. We do similar in some pkg-gnome packages, for example glib2.0 ships a -tests package that contains "installed tests" which are compiled as part of the package build and then executed during the autopkgtests. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#924657: kbdnames are generated with incorrect translations
Package: keyboard-configuration Version: 1.188 Severity: serious Tags: patch Control: forwarded -1 https://salsa.debian.org/installer-team/console-setup/merge_requests/2 I'm reporting from my Ubuntu system but I've confirmed this also affects 1.188 in buster, or any version that was built with perl ≥ 5.28. The generated names in keyboard-configuration.config are translated incorrectly: laney@raleigh> dpkg --ctrl-tarfile keyboard-configuration_1.188_all.deb | tar xO- ./config | grep "en_GB\*model\*sun_type6_jp" en_GB*model*sun_type6_jp*Sun Type 6 (Japonesa) en_GB*model*sun_type6_jp_usb*Sun Type 6 USB (Japonesa) That should be "(Japanese)". Very many other entries are also affected. I've provided a patch on the referenced salsa URL. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] -- System Information: Debian Release: buster/sid APT prefers disco-proposed APT policy: (500, 'disco-proposed'), (500, 'disco') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.0-7-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en_AU:en (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keyboard-configuration depends on: ii debconf 1.5.71 ii liblocale-gettext-perl 1.07-3build3 keyboard-configuration recommends no packages. keyboard-configuration suggests no packages. Versions of packages console-setup depends on: ii console-setup-linux 1.178ubuntu10 ii debconf 1.5.71 ii xkb-data 2.23.1-1ubuntu1.18.10.1 Versions of packages console-setup suggests: ii locales 2.29-0ubuntu1 ii lsb-base 10.2018112800ubuntu1 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.56+nmu1 ii initscripts 2.88dsf-59.6ubuntu1 ii kbd 2.0.4-4ubuntu1 Versions of packages console-setup-linux suggests: ii console-setup 1.178ubuntu10 Versions of packages keyboard-configuration is related to: pn console-common pn console-data pn console-tools ii gnome-control-center 1:3.32.0.1-1ubuntu3 ii kbd 2.0.4-4ubuntu1 ii systemd 240-6ubuntu1 -- debconf information: console-setup/fontsize-fb47: 8x16 console-setup/fontsize: 8x16 console-setup/codesetcode: Uni2 keyboard-configuration/xkb-keymap: gb console-setup/fontface47: Fixed keyboard-configuration/model: PC genèric de 105 tecles (intl.) keyboard-configuration/unsupported_layout: true console-setup/store_defaults_in_debconf_db: true console-setup/use_system_font: * keyboard-configuration/layout: английска — великобританска keyboard-configuration/store_defaults_in_debconf_db: true keyboard-configuration/ctrl_alt_bksp: false keyboard-configuration/compose: No compose key console-setup/fontsize-text47: 8x16 keyboard-configuration/toggle: No toggling keyboard-configuration/optionscode: console-setup/guess_font: keyboard-configuration/modelcode: pc105 keyboard-configuration/switch: No temporary switch keyboard-configuration/altgr: The default for the keyboard layout keyboard-configuration/unsupported_config_layout: true console-setup/charmap47: UTF-8 console-setup/detect: keyboard-configuration/unsupported_options: true debian-installer/console-setup-udeb/title: console-setup/framebuffer_only: keyboard-configuration/layoutcode: gb keyboard-configuration/variantcode: keyboard-configuration/unsupported_config_options: true console-setup/ask_detect: false * keyboard-configuration/variant: английска — великобританска keyboard-configuration/other: console-setup/codeset47: . Combined - Latin; Slavic Cyrillic; Greek console-setup/detected:
Bug#923805: age: gnome-shell-extension-desktop-icons/19.01.1-1
Package: release.debian.org Severity: normal Hi again, Similar to gdk-pixbuf, could you please age gnome-shell-extension-desktop-icons so that it can go into buster? The reasons are different: is a fairly young project still and it would do us well to be closer to upstream when we get buster out, I think, since it provides (to some people) an important feature - reinstating the desktop icons that nautilus stopped handling. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#923803: age: gdk-pixbuf/2.38.1+dfsg-1
Package: release.debian.org Severity: normal Hi there, I should have uploaded this with a higher urgency probably - could you please age gdk-pixbuf so that it can go into buster before the hard freeze? Maybe 5 days? This is a bugfix release with some quite nice fixes that it would be good to release with. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#920938: autopkgtests fail with: Cannot open input file: No such file or directory
Hi,
You're giving the tests the wrong input filename - that is a bug in
pcapfix (the tests weren't updated for the .pcap move).
The second thing is that returning 254 on errors breaks autopkgtest, so
it would be good if you could change exit codes 128 < code < 255 into
one below 128. That's arguably an autopkgtest bug, so you might not want
to fix it, but if you do it will help the testers.
Cheers,
Iain
On Wed, Jan 30, 2019 at 07:06:47PM +0100, Robert Krause wrote:
> Hi Iain,
>
> thank you for this bug report.
>
> Did I get it right that is a bug in the tool (pcapfix) itself and not the
> testing process?
>
> I am a bit confused, since I did not change any return codes since version
> 1.1.4.
> Nevertheless it is correct, that pcapfix returns negative numbers in case of
> errors.
> I can fix this and turn them positive if this will make autopkgtest work
> again.
>
> Is "no such file" also a bug of pcapfix or is it the test case. I checked
> file opening function and process and it works on my system.
>
> Thanks in advance.
>
> Cheers,
> Robert
>
> On 2019-01-30 18:48, Iain Lane wrote:
> > Package: src:pcapfix
> > Version: 1.1.4-1
> > Severity: normal
> >
> > Hi,
> >
> > Removing autopkgtest-satdep (0) ...
> > autopkgtest [15:14:06]: test command1: pcapfix
> > debian/test/test_2018.pcap
> > autopkgtest [15:14:06]: test command1: [---
> > [-] Cannot open input file: No such file or directory
> > pcapfix 1.1.4 (c) 2012-2019 Robert Krause
> >
> > [*] Reading from file: debian/test/test_2018.pcap
> > autopkgtest [15:14:07]: ERROR: testbed failure: testbed auxverb
> > failed with exit code 254
> >
> > The path to the .pcap file is wrong since 1.1.4-1.
> >
> > In addition, the last line shows that the exit status of the test
> > command is making autopkgtest think that *it* failed rather than the
> > test command. It only supports exit 0-125 - is there any chance you
> > could chop off any larger exit codes please? In a script, something like
> > (untested)
> >
> > #!/bin/sh
> > pcapfix ...; RC=$?
> > if [ "${RC}" -gt 125 ]; then
> > RC=125
> > fi
> > exit ${RC}
> >
> > (The closest bit of documentation I can find for this is in [0]:
> >
> > program's exit status will be that of the testbed command if the
> > latter exits with a value from 0..125.
> >
> > ...
> >
> > If program fails it will exit 254 or 255
> >
> > Where "program" is not the test program: it is an autopkgtest-internal
> > program to execute a given command inside the testbed.)
> >
> > Thanks!
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
signature.asc
Description: PGP signature
Bug#920938: autopkgtests fail with: Cannot open input file: No such file or directory
Package: src:pcapfix
Version: 1.1.4-1
Severity: normal
Hi,
Removing autopkgtest-satdep (0) ...
autopkgtest [15:14:06]: test command1: pcapfix debian/test/test_2018.pcap
autopkgtest [15:14:06]: test command1: [---
[-] Cannot open input file: No such file or directory
pcapfix 1.1.4 (c) 2012-2019 Robert Krause
[*] Reading from file: debian/test/test_2018.pcap
autopkgtest [15:14:07]: ERROR: testbed failure: testbed auxverb failed with
exit code 254
The path to the .pcap file is wrong since 1.1.4-1.
In addition, the last line shows that the exit status of the test
command is making autopkgtest think that *it* failed rather than the
test command. It only supports exit 0-125 - is there any chance you
could chop off any larger exit codes please? In a script, something like
(untested)
#!/bin/sh
pcapfix ...; RC=$?
if [ "${RC}" -gt 125 ]; then
RC=125
fi
exit ${RC}
(The closest bit of documentation I can find for this is in [0]:
program's exit status will be that of the testbed command if the
latter exits with a value from 0..125.
...
If program fails it will exit 254 or 255
Where "program" is not the test program: it is an autopkgtest-internal
program to execute a given command inside the testbed.)
Thanks!
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
[0]
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.virtualisation-server.rst
Bug#919224: RM: maliit-framework/experimental -- ROM; dead upstream, unused
Package: ftp.debian.org Severity: normal Control: clone -1 -2 Control: retitle -2 maliit-plugins/experimental -- ROM; dead upstream, unused Hi, These were going to be used as a general OSK type thing, but then the project(s) died upstream, and I forgot about them until bunk reminded me on IRC. We should remove them as they're not really useful/usable/used. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#918810: Artifacts directory can have unbounded size
Package: autopkgtest
Version: 5.7
Severity: normal
Tags: upstream
Hi there,
We just had a misbehaving test which ended up accidentally dumping 6G+
of data in to ${AUTOPKGTEST_ARTIFACTS}. autopkgtest tried to copy this
up and do the usual stuff with it, which ended up ENOSPCing the host. If
this hadn't ENOSPCed, it would have continued to be bad because then
we'd have tried to upload this to our cloud storage (swift), and the
sysadmins wouldn't have liked that. :-)
Suggestion: impose a (configurable, default 10M or so) limit on the
artifacts directory, and error out if it's over limit. I'm not sure
which error code should be used, mind you.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
Bug#915857: radare2: 3.1 fails to build on mipsel, ppc64el, s390x
Control: tags -1 + pending fixed-upstream Control: forwarded -1 https://github.com/radare/radare2/pull/12455 > io.c: In function 'r_io_ptrace_func': > io.c:680:2: error: unknown type name 'ptrace_wrap_instance' > ptrace_wrap_instance *wrap = io_ptrace_wrap_instance (io); > ^~~~ It was a problem with --disable-debugger. I submitted a fix upstream and uploaded to DELAYED/5 - feel free to reschedule/cancel/upload yourself/whatever. Also on https://salsa.debian.org/pkg-security-team/radare2/merge_requests/1/ for merging convenience (signed tag in my fork too). Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#915881: Ubuntu's custom build flags are overridden by Debian's
On Sun, Dec 09, 2018 at 11:17:15PM +0100, Guillem Jover wrote: > Iain: Should your mail address really be @debian or perhaps it should > have been either @canonical or @ubuntu instead? For better © tracking. Cheers for that. And sure, s/debian/ubuntu/ works for me too. It's just that my reportbug configuration defaults to d.o and I didn't override it. Merci, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#915881: Ubuntu's custom build flags are overridden by Debian's
Package: libdpkg-perl
Version: 1.19.1
Severity: normal
Tags: patch
Heya,
In Ubuntu we recently got a version of dpkg including
d5374bc618310917557daa9c9ac2f4930515a0b2 for the first time, and I
noticed that our ppc64el -O3 build flag wasn't being used - -O2 was
being passed instead.
See the attached commit for my proposed fix - please let me know what
you think. There are other valid approaches such as having Debian.pm
check the value doesn't contain `-g -O\d' before appending it.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
>From c23ab654f69b25019edd4e3b2b533dfc7659f618 Mon Sep 17 00:00:00 2001
From: Iain Lane
Date: Fri, 7 Dec 2018 14:14:27 +
Subject: [PATCH] Dpkg::Vendor::Ubuntu: Chain up to update-buildflags first,
not last
Since d5374bc618310917557daa9c9ac2f4930515a0b2, Dpkg::Vendor::Debian
(Dpkg::Vendor::Ubuntu's parent class) appends `-g -O2' or `-g -O2' to
the build flags. For ppc64el, Ubuntu sets the flag to `-g -O3'.
Ubuntu calls up to Debian's implementation at the end, meaning that
Debian's default build flags are appended after Ubuntu's, which means
that they take precedence:
$ DEB_HOST_ARCH=ppc64el dpkg-buildflags --get CFLAGS
-g -O3 -g -O2 -fdebug-prefix-map=/home/laney=. -fstack-protector-strong
-Wformat -Werror=format-security
Fix this by having Ubuntu chain up at the start, and then append when it
sets flags, meaning that its changes will win out over Debian's:
$ DEB_HOST_ARCH=ppc64el dpkg-buildflags --get CFLAGS
-g -O2 -fdebug-prefix-map=/home/laney=. -fstack-protector-strong -Wformat
-Werror=format-security -g -O3
---
scripts/Dpkg/Vendor/Ubuntu.pm | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/Dpkg/Vendor/Ubuntu.pm b/scripts/Dpkg/Vendor/Ubuntu.pm
index eb2dffefe..8662c2351 100644
--- a/scripts/Dpkg/Vendor/Ubuntu.pm
+++ b/scripts/Dpkg/Vendor/Ubuntu.pm
@@ -98,6 +98,9 @@ sub run_hook {
} elsif ($hook eq 'update-buildflags') {
my $flags = shift @params;
+ # Run the Debian hook to add hardening flags
+ $self->SUPER::run_hook($hook, $flags);
+
require Dpkg::BuildOptions;
my $build_opts = Dpkg::BuildOptions->new();
@@ -109,15 +112,12 @@ sub run_hook {
if (Dpkg::Arch::debarch_eq($arch, 'ppc64el')) {
for my $flag (qw(CFLAGS CXXFLAGS OBJCFLAGS OBJCXXFLAGS GCJFLAGS
FFLAGS FCFLAGS)) {
- $flags->set($flag, '-g -O3', 'vendor');
+ $flags->append($flag, '-g -O3', 'vendor');
}
}
}
# Per https://wiki.ubuntu.com/DistCompilerFlags
- $flags->set('LDFLAGS', '-Wl,-Bsymbolic-functions', 'vendor');
-
- # Run the Debian hook to add hardening flags
- $self->SUPER::run_hook($hook, $flags);
+ $flags->append('LDFLAGS', '-Wl,-Bsymbolic-functions', 'vendor');
} else {
return $self->SUPER::run_hook($hook, @params);
}
--
2.17.1
Bug#915705: Team maintenance
Package: src:appstream-glib Severity: wishlist Hey ximion, Hope all's good! What do you think about making the Maintainer of as-glib the pkgutopia-team and having yourself in Uploaders? Looks like a couple of us have been 'illegally' contributing to it from time to time, since the maintainer is currently you and not the team. Would be good for it to be legalised. The VCS is under pkg-utopia already so I take that as a slight hint. :-) Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#915618: poppler 0.71 support
Package: xpdf
Version: 3.04-9
Severity: wishlist
Tags: patch moreinfo
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch
Hi,
Here's the patch I came up for in Ubuntu, where we've switched to
poppler 0.71 (libpopler82 ABI). This isn't in Debian yet, but it will
presumably be at some point and you might find this useful then.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru xpdf-3.04/debian/control xpdf-3.04/debian/control
--- xpdf-3.04/debian/control2018-11-26 06:02:49.0 +
+++ xpdf-3.04/debian/control2018-12-04 17:35:33.0 +
@@ -1,8 +1,7 @@
Source: xpdf
Section: text
Priority: optional
-Maintainer: Ubuntu Developers
-XSBC-Original-Maintainer: Debian QA Group
+Maintainer: Debian QA Group
Standards-Version: 4.1.3
Build-Depends:
debhelper (>= 9),
diff -Nru xpdf-3.04/debian/patches/poppler-0.71.patch
xpdf-3.04/debian/patches/poppler-0.71.patch
--- xpdf-3.04/debian/patches/poppler-0.71.patch 1970-01-01 01:00:00.0
+0100
+++ xpdf-3.04/debian/patches/poppler-0.71.patch 2018-12-04 17:35:33.0
+
@@ -0,0 +1,1072 @@
+Description: poppler 0.71 removed several functions we rely on; update
accordingly
+Author: Iain Lane
+Bug-Debian: -1
+
+Index: b/xpdf/PDFCore.cc
+===
+--- a/xpdf/PDFCore.cc
b/xpdf/PDFCore.cc
+@@ -144,7 +144,7 @@
+ delete out;
+ }
+
+-int PDFCore::loadFile(GString *fileName, GString *ownerPassword,
++int PDFCore::loadFile(const GString *fileName, GString *ownerPassword,
+ GString *userPassword) {
+ int err;
+
+@@ -208,9 +208,7 @@
+ // nothing displayed yet
+ topPage = -99;
+ midPage = -99;
+- while (pages->getLength() > 0) {
+-delete (PDFCorePage *)pages->del(0);
+- }
++ pages->clear();
+
+ // compute the max unscaled page size
+ maxUnscaledPageW = maxUnscaledPageH = 0;
+@@ -244,9 +242,7 @@
+ // no page displayed
+ topPage = -99;
+ midPage = -99;
+- while (pages->getLength() > 0) {
+-delete (PDFCorePage *)pages->del(0);
+- }
++ pages->clear();
+
+ // redraw
+ scrollX = scrollY = 0;
+@@ -269,9 +265,7 @@
+ // no page displayed
+ topPage = -99;
+ midPage = -99;
+- while (pages->getLength() > 0) {
+-delete (PDFCorePage *)pages->del(0);
+- }
++ pages->clear();
+
+ // redraw
+ scrollX = scrollY = 0;
+@@ -491,9 +485,7 @@
+ rotateA != rotate) {
+ needUpdate = gTrue;
+ setSelection(0, 0, 0, 0, 0);
+-while (pages->getLength() > 0) {
+- delete (PDFCorePage *)pages->del(0);
+-}
++pages->clear();
+ zoom = zoomA;
+ rotate = rotateA;
+ dpi = dpiA;
+@@ -613,14 +605,21 @@
+
+ // delete pages that are no longer needed and insert new pages
+ // objects that are needed
+-while (pages->getLength() > 0 &&
+- ((PDFCorePage *)pages->get(0))->page < pg0) {
+- delete (PDFCorePage *)pages->del(0);
+-}
+-i = pages->getLength() - 1;
+-while (i > 0 && ((PDFCorePage *)pages->get(i))->page > pg1) {
+- delete (PDFCorePage *)pages->del(i--);
++for (auto it = pages->begin(); it != pages->end();) {
++ auto page = static_cast (*it);
++ if (page->page >= pg0)
++break;
++ it = pages->erase(it);
+ }
++
++for (auto it = pages->rbegin(); it != pages->rend();) {
++ auto page = static_cast (*it);
++ if (page->page <= pg1)
++break;
++
++ it = decltype(it){ pages->erase(std::next(it).base()) };
++}
++
+ j = pages->getLength() > 0 ? ((PDFCorePage *)pages->get(0))->page - 1
+: pg1;
+ for (i = pg0; i <= j; ++i) {
+@@ -648,11 +647,11 @@
+ }
+
+ // delete tiles that are no longer needed
+- for (i = 0; i < pages->getLength(); ++i) {
+-page = (PDFCorePage *)pages->get(i);
++ for (auto it = pages->begin(); it != pages->end(); it++) {
++page = static_cast (*it);
+ j = 0;
+-while (j < page->tiles->getLength()) {
+- tile = (PDFCoreTile *)page->tiles->get(j);
++for (auto itt = page->tiles->begin(); itt != page->tiles->end();) {
++ tile = static_cast (*itt);
+ if (continuousMode) {
+ y0 = pageY[page->page - 1] + tile->yMin;
+ y1 = pageY[page->page - 1] + tile->yMax;
+@@ -664,9 +663,9 @@
+ tile->xMin > scrollX + drawAreaWidth + drawAreaWidth / 2 ||
+ y1 < scrollY - drawAreaHeight / 2 ||
+ y0 > scrollY + drawAreaHeight + drawAreaHeight / 2) {
+- delete (PDFCoreTile *)page->tiles->del(j);
++itt = page->tiles->erase(itt);
+ } else {
+-
Bug#914691: RFA: agda-stdlib -- standard library for Agda
Package: wnpp Severity: normal Hi there, I'm not involved in this area any more. I've been basically ignoring the package and people from the Haskell team have been kindly uploading it in my absence. I'd like it if someone were to take it off my hands. That will probably be the Haskell team, but Sean points out to me that there would be no human uploaders if the team were to take it over directly. So ideally someone in the team would sign up to be an Uploader and make pkg-haskell the Maintainer. Cheers, and happy type safety, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#914437: ITP: gnome-shell-extension-desktop-icons -- desktop icon support for GNOME shell
Package: wnpp Severity: wishlist Owner: Iain Lane * Package name: gnome-shell-extension-desktop-icons Version : 18.11~rc1 Upstream Author : Carlos Soriano , Sergio Costas * URL : https://gitlab.gnome.org/World/ShellExtensions/desktop-icons * License : GPL-3+ Programming Lang: Javascript Description : desktop icon support for GNOME shell This package provides a GNOME Shell extension for showing the contents of ~/Desktop on the desktop of the Shell. Common file management operations such as launching, copy/paste, rename and deleting are supported. This is replacing functionality that was in Nautilus prior to 3.28. It uses D-Bus APIs provided by Nautilus to implement some of the features mentioned above. The GNOME team will maintain this package. I'll initially upload to experimental, probably at least until there is a stable release as opposed to a release candidate.
Bug#913077: closed by Debian FTP Masters (Bug#913077: Removed package(s) from unstable)
Control: reopen -1 On Thu, Nov 08, 2018 at 06:36:06AM +, Debian Bug Tracking System wrote: > gdm3 | 3.30.1-1 | s390x I think we missed some of gdm3's binaries here (thanks jcristau) laney@nightingale> rmadison -u debian -S -s unstable -a s390x gdm3 ~ gir1.2-gdm-1.0 | 3.30.1-1 | unstable | s390x libgdm-dev | 3.30.1-1 | unstable | s390x libgdm1| 3.30.1-1 | unstable | s390x Could those be removed too, please? Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908930: gnome-settings-daemon: new suspend-then-hibernate behaviour
On Sun, Sep 16, 2018 at 10:08:00AM +0200, Leonardo Canducci wrote: > since a couple of days hibernation occurs after 3 hours of suspension to > RAM. This new behaviour (gnome 3.30 related I guess) happens without > changing settings and is not described in the dialogs. > > I get suspend-the-hibernate is useful on laptops but I'd rather have > just suspend to RAM on my desktop. > > How do I disable suspent-then-hibernate and get back to suspend only? It looks like upstream have come around to this point of view too. Please see: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/54/ I was about to work on 3.30.1.1, but I will now wait a while and see if this is merged. If so, I'll cherry pick to Debian. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#910184: Move gjs build dependency to build-depends-indep
Package: gpaste Version: 3.28.2-1 Severity: important Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch Hi there, Soon gjs is probably going to be removed on s390x (see #909536 and #906016). This will be a problem for gpaste's build dependency on libgjs-dev. However, this is only used to build a gnome shell extension for an Arch: all package. I think it would be okay to move the BD to BDI and fiddle with the configure flags to only build the extension when building its package. See the attached patch. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] diff -Nru gpaste-3.28.2/debian/control gpaste-3.28.2/debian/control --- gpaste-3.28.2/debian/control2018-09-06 14:29:43.0 +0100 +++ gpaste-3.28.2/debian/control2018-10-03 12:17:31.0 +0100 @@ -21,9 +21,9 @@ libdbus-1-dev, libxtst-dev, libclutter-1.0-dev, - libgjs-dev (>= 1.48.0), libmutter-3-dev, valac (>= 0.32) +Build-Depends-Indep: libgjs-dev (>= 1.50.0) Standards-Version: 4.2.1 Homepage: https://github.com/Keruspe/GPaste Vcs-Git: https://salsa.debian.org/debian/gpaste/gpaste.git diff -Nru gpaste-3.28.2/debian/rules gpaste-3.28.2/debian/rules --- gpaste-3.28.2/debian/rules 2018-03-31 10:57:09.0 +0100 +++ gpaste-3.28.2/debian/rules 2018-10-03 12:52:42.0 +0100 @@ -3,6 +3,12 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all +CONFFLAGS := --with-systemduserunitdir=/usr/lib/systemd/user \ + --enable-introspection \ + --enable-appstream-util \ + --enable-applet \ + --enable-vala=no + %: dh $@ --with gir @@ -10,12 +16,13 @@ dh_autoreconf -- ./autogen.sh override_dh_auto_configure: - dh_auto_configure -- \ - --with-systemduserunitdir=/usr/lib/systemd/user - --enable-introspection \ - --enable-appstream-util \ - --enable-applet \ - --enable-vala=no +ifeq (gnome-shell-extensions-gpaste,$(filter gnome-shell-extensions-gpaste,$(shell dh_listpackages))) + dh_auto_configure -- $(CONFFLAGS) \ +--enable-gnome-shell-extension +else + dh_auto_configure -- $(CONFFLAGS) \ +--disable-gnome-shell-extension +endif override_dh_clean: dh_clean
Bug#910070: xdg-screensaver: libdbus assertion when window title is not valid UTF-8
Package: xdg-utils
Version: 1.1.2
Severity: normal
Tags: patch upstream
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=108121
Hi,
This was first reported in Launchpad, but it affects Debian too.
If the window title that 'suspend's argument refers to is invalid UTF-8
then the spawned perl process will crash with an assertion. We notice
more in Ubuntu because this causes a crash pop-up - without that then
the problem is probably that suspend hasn't worked.
A patch is attached to fix this by sanitising the window name. I thought
you might like to apply that in Debian.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
>From bfee96b1b954b49fff3064d2ab22bd0f71775984 Mon Sep 17 00:00:00 2001
From: Iain Lane
Date: Tue, 2 Oct 2018 10:29:03 +0100
Subject: [PATCH] xdg-screensaver: Sanitise window name before sending it over
the bus
libdbus expects string arguments to be valid UTF-8. If they are not,
then it aborts, which causes our backgrounded command to terminate
abnormally.
---
scripts/xdg-screensaver.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/xdg-screensaver.in b/scripts/xdg-screensaver.in
index 9e68196..ccb4307 100644
--- a/scripts/xdg-screensaver.in
+++ b/scripts/xdg-screensaver.in
@@ -468,6 +468,7 @@ screensaver_gnome_screensaver()
perl -e '
use strict;
use warnings;
+use Encode qw(decode);
use IO::File;
use Net::DBus;
use X11::Protocol;
@@ -489,6 +490,10 @@ while (1) {
}
}
+# Replace any invalid unicode characters with U+FFFD, so we dont crash when we
+# pass them over to D-Bus
+$window_name = decode("utf8", $window_name, Encode::FB_DEFAULT);
+
# Inhibit idle detection (flags = 8) with window name and ID.
# We have no reason so just send the window name again.
my $bus = Net::DBus->session();
--
2.17.0
Bug#910006: "basic" autopkgtest fails when bwrap is non-suid
Package: src:bubblewrap
Version: 0.3.1-1
Severity: minor
Tags: patch
Hey,
Filing as minor because this doesn't affect the package as built in
Debian.
When the package is built non-suid, not all GIDs are mapped into the
new (implicitly created) user namespace. The "basic" test is testing
that this does happen, so it fails:
autopkgtest [11:52:43]: test basic: [---
ok 1 - "bwrap --ro-bind / / /usr/bin/id" should succeed
# Failed test at /tmp/autopkgtest.TprZKQ/build.wEi/src/debian/tests/basic
line 17.
# got: 'uid=1000(ubuntu) gid=1001(ubuntu)
groups=1001(ubuntu),65534(nogroup)
# '
# expected: 'uid=1000(ubuntu) gid=1001(ubuntu)
groups=1001(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),115(netdev),1000(lxd)
# '
not ok 2
1..2
# Looks like you failed 1 test of 2.
autopkgtest [11:52:44]: test basic: ---]
basicFAIL non-zero exit status 1
autopkgtest [11:52:44]: test basic: - - - - - - - - - - results - - - - - -
- - - -
I think this test is just trying to show that bwrap "basic"ally works. To get
the test passing again in Ubuntu I applied the attached commit, checking
that the euid and egid survive. Maybe it's an idea to add "-n" to both
calls, which would amount to a test of the {uid,gid}_map code.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
>From 0ae7028bf4c6a3b87dd9ad0e571a026e4c57c92c Mon Sep 17 00:00:00 2001
From: Iain Lane
Date: Mon, 1 Oct 2018 09:21:01 +0100
Subject: [PATCH] basic: Don't assume `id` will be the same inside the sandbox
When bwrap is installed non-suid, unsharing the user namespace happens
implicitly. Not all GIDs are mapped into the sandbox, which results in
any supplementary groups returning as "nogroup".
As a basic test of bubblewrap's functionality, instead let's test if `id
-u` and `id -g` are the same inside and outside a sandbox.
---
debian/tests/basic | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/debian/tests/basic b/debian/tests/basic
index fbf1b61..c8e3449 100755
--- a/debian/tests/basic
+++ b/debian/tests/basic
@@ -13,7 +13,9 @@ sub run_ok {
}
my $out;
-run_ok([qw(bwrap --ro-bind / / /usr/bin/id)], '<', \undef, '>', \$out);
-is($out, `id`);
+run_ok([qw(bwrap --ro-bind / / /usr/bin/id -u)], '<', \undef, '>', \$out);
+is($out, `id -u`);
+run_ok([qw(bwrap --ro-bind / / /usr/bin/id -g)], '<', \undef, '>', \$out);
+is($out, `id -g`);
done_testing;
--
2.17.0
Bug#909243: gnome-shell segfaults on start in libmutter-3
Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/issues/194 Control: tags -1 - moreinfo Control: tags -1 + upstream fixed-upstream Hi there, On Thu, Sep 20, 2018 at 02:00:40PM +0200, Henry Schwanbeck wrote: > Hi Simon, > > the last one was incomplete, I got traces of xwayland and gnome shell > this time. > Stack trace of thread 7703: > #0 0x7f0460f48050 meta_logical_monitor_get_layout > (libmutter-3.so.0) > #1 0x7f0460fd27d4 send_xdg_output_events > (libmutter-3.so.0) > #2 0x7f045f359fce ffi_call_unix64 (libffi.so.6) > #3 0x7f045f35993f ffi_call (libffi.so.6) > #4 0x7f045bdb7b2d wl_closure_invoke > (libwayland-server.so.0) > #5 0x7f045bdb45a9 wl_client_connection_data > (libwayland-server.so.0) > #6 0x7f045bdb5b72 wl_event_loop_dispatch > (libwayland-server.so.0) > #7 0x7f0460fb77b7 wayland_event_source_dispatch > (libmutter-3.so.0) > #8 0x7f0461e7ec3e g_main_dispatch (libglib-2.0.so.0) > #9 0x7f0461e7eed8 g_main_context_iterate > (libglib-2.0.so.0) > #10 0x7f0461e7f1d2 g_main_loop_run (libglib-2.0.so.0) > #11 0x7f0460fb89c6 meta_xwayland_start (libmutter-3.so.0) > #12 0x7f0460fb7e04 meta_wayland_init (libmutter-3.so.0) > #13 0x7f0460f8952e meta_init (libmutter-3.so.0) > #14 0x55a43de4d528 main (gnome-shell) > #15 0x7f0460d1fb17 __libc_start_main (libc.so.6) > #16 0x55a43de4d8da _start (gnome-shell) This looks like https://gitlab.gnome.org/GNOME/mutter/issues/194 to me. If that's right, it should be fixed in mutter 3.30.1 which is out next week and should be in Debian soon after. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908323: libgtk3-perl: FTBFS: t/overrides.t failure
On Wed, Sep 12, 2018 at 11:59:49PM +0200, gregor herrmann wrote: > That's great news, thanks. > Please give us a short ping once the fixed package is available. I've just uploaded gdk-pixbuf 2.38.0+dfsg-5. There will be the normal delay, but hopefully this fixes the issue for you. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908323: libgtk3-perl: FTBFS: t/overrides.t failure
Control: clone -1 -2 Control: reassign -2 gir1.2-gdkpixbuf-2.0 Control: found -2 2.38.0+dfsg-4 Control: retitle -2 gdk_pixbuf_new_from_inline introspection metadata is broken Control: forwarded -2 https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/92 Control: tags -2 + upstream confirmed patch Control: affects -1 = Control: affects -2 src:libgtk3-perl Hi there, On Sat, Sep 08, 2018 at 03:43:21PM +0200, gregor herrmann wrote: > Control: tag -1 + confirmed upstream > > On Sat, 08 Sep 2018 15:03:13 +0300, Niko Tyni wrote: > > > I'm guessing this regressed with gdk-pixbuf 2.38.0+dfsg-1 or so, but I > > haven't verified that (and the ci.debian.net machinery doesn't seem to > > have pinpointed it yet either.) > > Sounds plausible; the changelog mentions > "Generate separate introspection data for GdkPixdata API" > and there's now a > /usr/lib/x86_64-linux-gnu/girepository-1.0/GdkPixdata-2.0.typelib > besides the old > /usr/lib/x86_64-linux-gnu/girepository-1.0/GdkPixbuf-2.0.typelib Right - this part is "expected". I should have tried build testing libgtk3-perl with the new version, sorry about that. > > I tried with > > #v+ > --- a/lib/Gtk3.pm > +++ b/lib/Gtk3.pm > [...] > #v- This diff looks correct to me - I think it could be forwarded upstream and/or uploaded. > but then the tests failed differently, with: > > Gtk3::Gdk::Pixbuf::new_from_inline: passed too few parameters (expected 4, > got 3) at t/overrides.t line 762. > # Looks like your test exited with 255 just after 162. ...and this one is a real bug in gdk-pixbuf. I forwarded a potential fix to upstream - will wait a little while to see what they say. I've confirmed that after applying the patch already in this bug and that proposed patch libgtk3-perl's autopkgtests pass again. Once it gets an ack or if there is no reply then I'll upload to Debian. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908070: libdazzle FTBFS: test failure
Control: reassign -1 libgtk-3-0 Control: found -1 3.24.0-2 Control: affects -1 src:libdazzle Control: tags -1 + upstream confirmed fixed-upstream Hey, On Wed, Sep 05, 2018 at 11:21:02PM +0300, Adrian Bunk wrote: > (/<>/obj-x86_64-linux-gnu/tests/test-application:23435): > GLib-GIO-CRITICAL **: 12:30:40.566: g_dbus_connection_call_internal: > assertion 'object_path != NULL && g_variant_is_object_path (object_path)' > failed Thanks! I think this is https://gitlab.gnome.org/GNOME/gtk/commit/3c7d5e749ccafa75718ef00f1d5f6cdc0defacb3. In gtk+3.0 3.24 there is a bug when shutting down GtkApplications and not using portals. We should probably cherry-pick that patch if it's breaking things. FTR, I doubt this g_critical is causing visible problems for people at runtime, but an FTBFS fix is justification enough. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908576: Accidentally installed file /usr/bin/gvfs-less.xml
Control: tags -1 + pending On Tue, Sep 11, 2018 at 01:17:00PM +0100, Iain Lane wrote: > Package: gvfs-bin > Version: 1.38.0-2 > Severity: normal > > gvfs-bin 1.38.0-2 includes a file /usr/bin/gvfs-less.xml that shouldn't > be there. > > W: gvfs-bin: executable-not-elf-or-script usr/bin/gvfs-less.xml Bah, I thought that this would have been tagged pending by the webhook we have on salsa. Anyway, fixed in https://salsa.debian.org/gnome-team/gvfs/commit/91127fb056772f6ebd917dfbcd8c22c2e5bfbcb4 to be in the next upload. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908576: Accidentally installed file /usr/bin/gvfs-less.xml
Package: gvfs-bin Version: 1.38.0-2 Severity: normal gvfs-bin 1.38.0-2 includes a file /usr/bin/gvfs-less.xml that shouldn't be there. W: gvfs-bin: executable-not-elf-or-script usr/bin/gvfs-less.xml Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#908298: libgdk-pixbuf2.0-0: FTBFS on i386: Directory $'/<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu' does not seem to be a Meson build directory.
On Sat, Sep 08, 2018 at 09:19:46AM +0200, Sven Joachim wrote: > > | Directory $'/<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu' does > > not seem to be a Meson build directory. > > | make[1]: *** [debian/rules:26: override_dh_auto_test] Error 1 > > ` > > > > Will send a patch as soon as I have the bug number. > > Here it is, tested in an i386 sbuild chroot. :-) Thanks Sven! I actually didn't know about this problem (obviously, or I wouldn't have made the upload like that), good to learn something. :-) -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#908193: Can sometimes fail to timeout
Package: autopkgtest
Version: 5.5
Severity: normal
Hey,
We don't have much information to help with debugging of this problem. I
just wanted to make sure it is recorded.
We've got an autopkgtest process that is currently (Sep 7) still
running, when it was started:
Aug 25 07:44:36 juju-prod-ues-proposed-migration-machine-11 sh[31372]:
2018-08-25 07:44:36,816 [31372] INFO: Received request for package
r-cran-fastmatch on cosmic/ppc64el; params: {'triggers':
['glibc/2.28-0ubuntu1']}
Aug 25 07:44:36 juju-prod-ues-proposed-migration-machine-11 sh[31372]:
2018-08-25 07:44:36,817 [31372] INFO: Running
/home/ubuntu/autopkgtest/runner/autopkgtest --output-dir
/tmp/autopkgtest-work.fdcdgul6/out --timeout-copy=6000 --setup-commands
/home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh
--setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed
--apt-pocket=proposed=src:glibc --apt-upgrade r-cran-fastmatch
--env=ADT_TEST_TRIGGERS=glibc/2.28-0ubuntu1 -- ssh -s
/home/ubuntu/autopkgtest/ssh-setup/nova -- --nova-reboot --flavor autopkgtest
--security-groups autopkgtest@bos02-ppc64el-20.secgroup --name
adt-cosmic-ppc64el-r-cran-fastmatch-20180825-074436 --image
adt/ubuntu-cosmic-ppc64el-server --keyname
testbed-juju-prod-ues-proposed-migration-machine-11
--net-id=net_ues_proposed_migration -e 'http_proxy=http://squid.internal:3128'
-e 'https_proxy=http://squid.internal:3128' -e
'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,changelogs.ubuntu.com,ddebs.ubuntu.com,ppa.launchpad.net'
--mirror=http://ftpmaster.internal/ubuntu
a long time ago.
I was away at the time, but apparently this affected several instances
around the same time, so it is likely that some event disrupted the
tests and they should have failed / been retried. Unfortunately the logs
have been deleted since then, so I can't see if there is any evidence in
them. If that's true then there might be an additional bug that they
didn't fail harder. This one says that the timeout should be there as an
ultimate fallback.
We're running 5243905d9dbee07d2b712d747fea0decd6e0c78c, so it's a bit
old - but scanning the changes doesn't show anything that's likely to
have changed this. Do let me know if that's wrong though. I'll try to
update us soon in any event.
Cheers!
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
Bug#907664: RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1
On Wed, Sep 05, 2018 at 08:50:56AM -0300, Herbert Fortes wrote: > > Thanks Herver - due to the new binary with this upload (libbudgie-private0) > > FTP-Master has rejected the package with this message > > > > "ACL dm: NEW uploads are not allowed > > > > binary:libbudgie-private0 is NEW." > > > > Can this be sponsored this time around please? > > > > Uploaded to experimental. > > But please update debian/copyright before the upload to SID. Ah, I had just come here to look at uploading this to *unstable* - we've just uploaded mutter-3 there, and so budgie-desktop will need fixing now. Could you possibly re-upload to unstable NEW please? I guess if some copyright fixes are required then David might need to post a new package. Cheers! -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#906015: transition: mutter 3.30, gnome-shell 3.30
Control: tags -1 - moreinfo On Mon, Aug 13, 2018 at 10:35:55AM +0100, Simon McVittie wrote: > When GNOME 3.30 is available, the GNOME team will need to do a couple > of transitions around gnome-shell. I'm reporting this tagged moreinfo > for your information, because we are not ready to proceed yet: The final stable releases are out, and we're ready to go. Removing the moreinfo tag. > > * mutter from libmutter-2-0 to libmutter-3-0, already tracked at > https://release.debian.org/transitions/html/auto-mutter.html > (one affected non-GNOME package: budgie-desktop will need sourceful > changes, already available in Ubuntu) budgie-desktop has a package available for sponsoring and I'll help David with that if his regular sponsor can't do it soon. > > * gnome-shell from 3.28 to 3.30 > (various GNOME Shell extensions will need porting or perhaps removal, > > <https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=shell-3.30=pkg-gnome-maintainers%40lists.alioth.debian.org>) Most of the extensions are fixed; those that aren't are pending autoremoval and Simon added versione Breaks from gnome-shell to all of those that needed updating. > It might also make sense to entangle this with the gjs transition from > mozjs52 to mozjs60, but for now I'm filing that as a separate bug. mozjs60 is still in NEW, so I'm keeping the two separate. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#907616: budgie-desktop: needs modification for Mutter 3.30
On Wed, Sep 05, 2018 at 12:40:40PM +0100, David Mohammed wrote: > Iain - the open RFS I have open requires someone to sponsor it due to > it including a new binary "libbudgie-private0" > > My DM rights will not allow me to upload new binaries. > > Can you sponsor please? Sure, no worries. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#907616: budgie-desktop: needs modification for Mutter 3.30
Hi there, We're uploading mutter 3.30 to unstable today - please could you upload the fixed budgie-desktop there instead of experimental now? Cheers, Iain On Thu, Aug 30, 2018 at 09:34:09AM +0100, David Mohammed wrote: > Simon > > Not clear here. Should I submit an upload to experimental? > > If so I will do that asap > > David > > On Thu, 30 Aug 2018, 09:21 Simon McVittie, wrote: > > > Source: budgie-desktop > > Version: 10.4+git20171031.10.g9f71bb8-1.2 > > Severity: serious > > Justification: https://bugs.debian.org/906015 > > > > The version of budgie-desktop in testing/unstable is not compatible with > > mutter 3.29.x/3.30, which is required by the corresponding GNOME Shell > > version. These are currently in experimental, but should be uploaded to > > unstable soon. > > > > The version in Ubuntu 'cosmic' appears to have already been patched to > > be compatible with GNOME 3.30. > > > > smcv > > -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#907316: [pkg-cli-apps-team] Bug#907316: tomboy: Is tomboy still being maintained?
Control: tags -1 + help Hi, On Sun, Aug 26, 2018 at 02:08:14PM +0200, Tobias Frost wrote: > Package: src:tomboy > Severity: serious > > Dear maintaines for tomboy, > > We've received concerns about tomboy being not properly maintained by a > user of this package. It seems to that the package is indeed not being > maintained properly, as of this writing is is RC buggy with 3 RC-bugs, > the repo has not been migrated to salsa and upstream has released > several (5+) new versions, the latest over an year ago. > > It would be great if you could update the package and then close this > bug. Otherwise, I will re-evalute in 3 months and if there is no answer > to this bug, I will orphan this package on behalf of the MIA team. Thanks for the bug. The mono / CLI teams are quite inactive at the minute - most of the previous menbers have moved on to focusing on other things. I don't think orphaning will particularly help - if anybody wants to assist with maintaining this and our other packages, please just join the existing teams and work there. One of us will probably even sponsor your work if you're not a DD - come find us in #debian-cli on OFTC. No objections from me to kicking tomboy out of testing (the bug's RC severity). Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#906331: [git-buildpackage/master] Ignore merge commits when looking at the pristine-tar branch
tag 906331 pending thanks Date: Fri Aug 17 11:22:01 2018 +0100 Author: Iain Lane Commit ID: 5fedb2baf1b03c3c128898de545984c1622bac79 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=5fedb2baf1b03c3c128898de545984c1622bac79 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=5fedb2baf1b03c3c128898de545984c1622bac79 Ignore merge commits when looking at the pristine-tar branch When there is a merge commit in this branch, we currently get the warning: gbp:warning: Unknown compression type of Merge branch 'pristine-tar' into 'pristine-tar', assuming gzip because we're grepping the commit logs to find out the compression type of the tarballs in there. For now, we can just use `git log ... --no-merges' to not see these commits. Signed-off-by: Guido Günther Closes: #906331
Bug#906331: Fails when pristine-tar branch contains a merge commit
On Fri, Aug 17, 2018 at 01:28:47PM +0200, Guido Günther wrote:
> Yeah, exactly. There are some external uses and we don't want to break
> API for them.
Aha!
OK, here's a new patch which does what you suggest.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
From 48d259ea6bd56f340a6bcde78e7d5d6bdb18c4bd Mon Sep 17 00:00:00 2001
From: Iain Lane
Date: Fri, 17 Aug 2018 11:22:01 +0100
Subject: [PATCH] Ignore merge commits when looking at the pristine-tar branch
When there is a merge commit in this branch, we currently get the
warning:
gbp:warning: Unknown compression type of Merge branch 'pristine-tar' into 'pristine-tar', assuming gzip
because we're grepping the commit logs to find out the compression type
of the tarballs in there.
For now, we can just use `git log ... --no-merges' to not see these
commits.
---
gbp/git/repository.py | 4 +++-
gbp/pkg/pristinetar.py | 2 +-
gbp/scripts/export_orig.py | 2 +-
tests/05_test_detection.py | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index 1fc92ee9..827bf17b 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -1645,7 +1645,7 @@ class GitRepository(object):
raise GitRepositoryError("can't get %s: %s" % (id, stderr.decode().rstrip()))
return obj
-def grep_log(self, regex, since=None):
+def grep_log(self, regex, since=None, merges=True):
"""
Get commmits matching I{regex}
@@ -1655,6 +1655,8 @@ class GitRepository(object):
@type since: C{str}
"""
args = ['--pretty=format:%H']
+if not merges:
+args.append("--no-merges")
args.append("--grep=%s" % regex)
if since:
args.append(since)
diff --git a/gbp/pkg/pristinetar.py b/gbp/pkg/pristinetar.py
index 1da72bfb..be301326 100644
--- a/gbp/pkg/pristinetar.py
+++ b/gbp/pkg/pristinetar.py
@@ -71,7 +71,7 @@ class PristineTar(Command):
return None
regex = ('pristine-tar .* %s' % archive_regexp)
-commits = self.repo.grep_log(regex, self.branch)
+commits = self.repo.grep_log(regex, self.branch, merges=False)
if commits:
commit = commits[-1]
gbp.log.debug("Found pristine-tar commit at '%s'" % commit)
diff --git a/gbp/scripts/export_orig.py b/gbp/scripts/export_orig.py
index 95b83da5..ea6c8870 100755
--- a/gbp/scripts/export_orig.py
+++ b/gbp/scripts/export_orig.py
@@ -236,7 +236,7 @@ def guess_comp_type(comp_type, source, repo, tarball_dir):
if comp_type == 'auto':
if repo and repo.has_pristine_tar_branch():
regex = 'pristine-tar .* %s_%s\.orig.tar\.' % (source.name, source.upstream_version)
-commits = repo.grep_log(regex, repo.pristine_tar_branch)
+commits = repo.grep_log(regex, repo.pristine_tar_branch, merges=False)
if commits:
commit = commits[-1]
gbp.log.debug("Found pristine-tar commit at '%s'" % commit)
diff --git a/tests/05_test_detection.py b/tests/05_test_detection.py
index d2579dfa..5e903db3 100644
--- a/tests/05_test_detection.py
+++ b/tests/05_test_detection.py
@@ -24,7 +24,7 @@ class MockGitRepository:
def pristine_tar_branch(self):
'pristine-tar'
-def grep_log(self, regex, branch):
+def grep_log(self, regex, branch, merges=True):
return None
def get_commit_info(self, commit):
--
2.17.0
signature.asc
Description: PGP signature
Bug#906331: Fails when pristine-tar branch contains a merge commit
On Fri, Aug 17, 2018 at 01:04:34PM +0200, Guido Günther wrote: > We do that to get the last used compression type. If we do a ls-tree > or even `pristine-tar list` we have no ordering. Interesting. I was imagining (without checking!) that you'd be interested in the compression a particular file had, not the last one. > Patch is mostly good but we must not break other grep_log users so > changing the signature to > > def grep_log(self, regex, since=None, merges=True): > > and calling it with False in your case would be the right thing. I try > to get around to add this before the next release (which is long overdue > too). I checked both call sites: get_commit() and guess_comp_type(). The second one is the direct cause of this bug, but it looks to me like the second one would be OK with this fix too. AFAICS it is ultimately used to determine if we should pristine-tar commit a file or skip it because it already exists. In that case we shouldn't look for the merge commit either, or? Ah, maybe you're saying this is API and we shouldn't change semantics for external users? Thanks! -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#906331: Fails when pristine-tar branch contains a merge commit
Package: git-buildpackage
Version: 0.9.9
Severity: normal
Tags: patch
Hey,
[ as spoilered over private email ;-) ]
We currently grep the log of the pristine-tar branch to find out which
compression type the tarball we're interested in has. The regex we use
to do that fails when it encounters something unknown - like a merge
commit. Like this:
gbp:warning: Unknown compression type of Merge branch 'pristine-tar' into
'pristine-tar', assuming gzip
gbp:info: Tarballs 'gnome-session_3.29.90.orig.tar.gz' not found at
'../tarballs/'
gbp:info: Creating
/home/laney/dev/debian/packaging/pkg-gnome/build-area/gnome-session_3.29.90.orig.tar.gz
gbp:error: Error creating gnome-session_3.29.90.orig.tar.gz: Pristine-tar
couldn't checkout "gnome-session_3.29.90.orig.tar.gz": fatal: Path
'gnome-session_3.29.90.orig.tar.gz.delta' does not exist in
'refs/heads/pristine-tar'
pristine-tar: git show
refs/heads/pristine-tar:gnome-session_3.29.90.orig.tar.gz.delta failed
(We might get a merge commit if someone clicks the 'merge' button in
salsa, for example.)
This can be worked around by passing "--no-merges" to the git log
invocation. That's what the attached patch does. Please could you review
it?
Don't let this stop you from merging the commit (I don't know if I'll
have time to write this patch soon if it's the right idea and I have the
other one already which works), but is there a reason why we don't use
e.g. "git ls-tree -r --name-only pristine-tar" and look at the filenames
in the branch directly?
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
>From 0e222c0591aec4d9b2644e951b2a07f6205d71c3 Mon Sep 17 00:00:00 2001
From: Iain Lane
Date: Fri, 17 Aug 2018 11:22:01 +0100
Subject: [PATCH] Ignore merge commits when looking at the pristine-tar branch
When there is a merge commit in this branch, we currently get the
warning:
gbp:warning: Unknown compression type of Merge branch 'pristine-tar' into
'pristine-tar', assuming gzip
because we're grepping the commit logs to find out the compression type
of the tarballs in there.
For now, we can just use `git log ... --no-merges' to not see these
commits.
---
gbp/git/repository.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index 1fc92ee9..19778710 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -1654,7 +1654,7 @@ class GitRepository(object):
@param since: where to start grepping (e.g. a branch)
@type since: C{str}
"""
-args = ['--pretty=format:%H']
+args = ['--pretty=format:%H', '--no-merges']
args.append("--grep=%s" % regex)
if since:
args.append(since)
--
2.17.1
Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote: > > One obvious solution if vendor-specific series files get outlawed in > > Debian would be to switch from ubuntu.series to manual patching in > > debian/rules based on dpkg-vendor(1). > > Or it would mean that Ubuntu would carry a XubuntuY version and do > manual (or automatic, based on whatever tooling they have available) > merges from Debian, marking it clearly as a different work. I would like you to consider - and I think this is part of what Adrian is raising too¹ - this kind of case where the Debian maintainer *wants* to support particular derivatives in their source package in Debian and is willing to test it properly. Having this facility avoids the need for any kind of source package delta resolution process needing to take place², which might add arbitrary delays between a new package being uploaded to unstable and becoming available in the derivative's unstable suite. It means that the Debian uploader does not need to become - or to find - a derivative uploader to perform this resolution. And it avoids maintainers having to cook up their own solution if they want to do it at build time without tool support. FAOD I am not challenging that the drawbacks of vendor-specific patch series as outlined in this bug exist - just saying that Adrian's point has some merit in that having this *kind* of support (perhaps not this specific implementation) easily available is useful. TBH I'm not sure what I'd ask -ctte to do with this argument. If you do decide to outlaw the vendor-specific series, maybe advice (6.1.5) to relevant developers to consider designing a way to better support derivative specific patches within Debian. Cheers for handling this issue, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] ¹ sorry for putting words in your mouth if this isn't what you meant :-) ² in Ubuntu's case this is not automatic; a human uploader needs to at the very least review the output of merge-o-matic). signature.asc Description: PGP signature
Bug#888338: libavg: FTBFS with FFmpeg 4.0
On Thu, Aug 02, 2018 at 09:28:50PM +0100, peter green wrote: > I applied the patch that jcowgill submitted upstream plus another upstream > commit and disabled vdpau support (which has been removed upstream) and was > able to get the debian package to build, so I uploaded it to raspbian. > > A debdiff should appear soon at > https://debdiffs.raspbian.org/main/liba/libavg/ No intent to nmu in debian. Thanks Peter. I'm going to upload that to Ubuntu. For reference, I saw an additional FTBFS due to confusion between CXXFLAGS and CPPFLAGS. Patch for that is attached, but it looks like upstream has dropped autotools in favour of CMake anyway so maybe it won't be needed. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] Description: Pass AM_CXXFLAGS for a C++ build, not CPPFLAGS which is for the preprocessor Author: Iain Lane --- libavg-1.8.2.orig/src/base/triangulate/Makefile.am +++ libavg-1.8.2/src/base/triangulate/Makefile.am @@ -1,4 +1,4 @@ -AM_CPPFLAGS = -I.. @XML2_CFLAGS@ @PTHREAD_CFLAGS@ +AM_CXXFLAGS = -I.. @XML2_CFLAGS@ @PTHREAD_CFLAGS@ ALL_H = Triangulate.h Shapes.h Utils.h \ AdvancingFront.h Sweep.h SweepContext.h signature.asc Description: PGP signature
Bug#888357: opal: FTBFS with FFmpeg 3.5
Control: tags -1 + patch
On Wed, Jan 24, 2018 at 10:26:50PM +, jcowg...@debian.org wrote:
> Source: opal
> Version: 3.10.10~dfsg2-2.1
> Severity: important
> User: debian-multime...@lists.debian.org
> Usertags: ffmpeg-3.5-transition
>
> Hi,
>
> Your package FTBFS with the upcoming version 3.5 of FFmpeg. In FFmpeg 3.5,
> there are a number of API changes which will cause many packages to FTBFS.
> For this reason I have uploaded an early development snapshot to experimental
> before the 3.5 release in an attempt to fix some of these a bit quicker.
> While 3.5 has not been finalized and the ABI is not stable yet, there should
> not be any significant API breakages before the release.
Attached is a patch which at least makes opal build. I think probably
some of the "#if" guards are wrong and should be replaced with new API,
but I'm not sure. Hope it helps.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
Description: FFmpeg 4.0 compatibility
Author: Iain Lane
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888357
Forwarded: yes
Index: b/plugins/video/H.263-1998/h263-1998.cxx
===
--- a/plugins/video/H.263-1998/h263-1998.cxx
+++ b/plugins/video/H.263-1998/h263-1998.cxx
@@ -230,7 +230,7 @@
m_context->opaque = this;
- m_context->flags = CODEC_FLAG_TRUNCATED // Possible missing packets
+ m_context->flags = AV_CODEC_FLAG_TRUNCATED // Possible missing packets
;
m_context->pix_fmt = AV_PIX_FMT_YUV420P;
@@ -341,9 +341,9 @@
// Level 3+
// works with eyeBeam
if (atoi(value) == 1)
- m_context->flags |= CODEC_FLAG_AC_PRED;
+ m_context->flags |= AV_CODEC_FLAG_AC_PRED;
else
- m_context->flags &= ~CODEC_FLAG_AC_PRED;
+ m_context->flags &= ~AV_CODEC_FLAG_AC_PRED;
return;
}
@@ -351,9 +351,9 @@
// Annex J: Deblocking Filter
// works with eyeBeam
if (atoi(value) == 1)
- m_context->flags |= CODEC_FLAG_LOOP_FILTER;
+ m_context->flags |= AV_CODEC_FLAG_LOOP_FILTER;
else
- m_context->flags &= ~CODEC_FLAG_LOOP_FILTER;
+ m_context->flags &= ~AV_CODEC_FLAG_LOOP_FILTER;
return;
}
@@ -420,9 +420,11 @@
m_context->max_qdiff = 10; // was 3 // max q difference between frames
m_context->qcompress = 0.5; // qscale factor between easy &
hard scenes (0.0-1.0)
+#if LIBAVCODEC_VERSION_INT <= AV_VERSION_INT(52, 0, 0)
// Lagrange multipliers - this is how the context defaults do it:
m_context->lmin = m_context->qmin * FF_QP2LAMBDA;
m_context->lmax = m_context->qmax * FF_QP2LAMBDA;
+#endif
// YUV420P input
m_inputFrame->linesize[0] = m_context->width;
@@ -599,7 +601,7 @@
#ifdef CODEC_FLAG_H263P_UMV
m_context->flags &= ~CODEC_FLAG_H263P_UMV;
#endif
- m_context->flags &= ~CODEC_FLAG_4MV;
+ m_context->flags &= ~AV_CODEC_FLAG_4MV;
#if LIBAVCODEC_RTP_MODE
m_context->flags &= ~CODEC_FLAG_H263P_AIC;
#endif
Index: b/plugins/video/H.263-1998/rfc2429.cxx
===
--- a/plugins/video/H.263-1998/rfc2429.cxx
+++ b/plugins/video/H.263-1998/rfc2429.cxx
@@ -286,7 +286,7 @@
unsigned char * RFC2429Frame::GetBuffer()
{
- memset (m_encodedFrame.ptr + m_encodedFrame.pos,0 ,
FF_INPUT_BUFFER_PADDING_SIZE);
+ memset (m_encodedFrame.ptr + m_encodedFrame.pos,0 ,
AV_INPUT_BUFFER_PADDING_SIZE);
return (m_encodedFrame.ptr);
}
@@ -340,10 +340,10 @@
unsigned remBytes = packet.GetPayloadSize() - headerPLEN - (headerV ? 3 : 2);
- if ((m_encodedFrame.pos + (headerP ? 2 : 0) + remBytes) > (m_maxFrameSize -
FF_INPUT_BUFFER_PADDING_SIZE)) {
+ if ((m_encodedFrame.pos + (headerP ? 2 : 0) + remBytes) > (m_maxFrameSize -
AV_INPUT_BUFFER_PADDING_SIZE)) {
PTRACE(2, "H.263-RFC2429", "Trying to add " << remBytes
<< " bytes to frame at position " << m_encodedFrame.pos + (headerP ?
2 : 0)
- << " bytes while maximum frame size is " << m_maxFrameSize << "-" <<
FF_INPUT_BUFFER_PADDING_SIZE << " bytes");
+ << " bytes while maximum frame size is " << m_maxFrameSize << "-" <<
AV_INPUT_BUFFER_PADDING_SIZE << " bytes");
return false;
}
Index: b/plugins/video/MPEG4-ffmpeg/mpeg4.cxx
===
--- a/plugins/video/MPEG4-ffmpeg/mpeg4.cxx
+++ b/plugins/video/MPEG4-ffmpeg/mpeg4.cxx
@@ -546,11 +546,14 @@
// Reduce the diffe
Bug#904608: Support specifying upstream VCS location in debian/control
On Thu, Jul 26, 2018 at 09:05:33AM +0800, Sean Whitton wrote: > control: tag -1 +moreinfo > Even if we did want to add this to d/control files, we would want to see > it already used in d/control files in the archive before documenting > that in Policy. Thanks Sean. This is an interesting tangential point. I wanted this field so that tools can use it, which implies some engineering upon those tools. That's really the reason why I asked here first - I didn't want myself or anybody else to have to go and rewrite some code they've just written if we change our minds here about where the location should be - as it seems is happening. Hope that helps. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
Control: retitle -1 Specify a canonical location for upstream's VCS to be declared On Wed, Jul 25, 2018 at 06:20:52PM -0700, Jonathan Nieder wrote: > My feeling is that it doesn't belong in debian/control. > > The debian/control file is the source for control fields that appear > in the binary package, Packages file, and Sources file. If I > understand correctly, the primary consumers of this field would > already have a copy of the source (via Vcs-Git) so they can get the > information from other files in the debian/ directory; they don't need > to get it from the Sources file. > > With that in mind, Sean's suggestion of using debian/upstream/metadata[1] > sounds good to me. Would it work well for you? Thanks for the feedback. I don't particularly mind where it is - it just "felt" natural to me to have this alongside the other important repository: the packaging one. Hopefully my retitling helps. However, I'm not very keen on the extra work that would be required to transfer that wiki page into policy as opposed to specifying an extra field. Do you agree that policy should recommend such a location and is the path to this recommendation, in your opinion, a ratification of the UpstreamMetadata page or something like it? Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#904608: Support specifying upstream VCS location in debian/control
Package: debian-policy Version: 4.1.5.0 Severity: normal Hi, Some tools, like git-buildpackage, can support merging an upstream's version history into Debian packaging repositories. This enables more rich usage of (D)VCS when packaging - for example `git blame' works properly. Currently there's no canonical place to specify where upstream's VCS is located so people have to set this up manually themselves. If there were such a place, it would be possible for tools like `gbp clone' to configure the VCS to know about the upstream history when checking out a packaging repository. The request here is to ask whether this would be suitable for debian/control, along the lines of the Vcs-* fields specified in 5.6.26 and the Homepage field in 5.6.23. If so, I'd be happy to propose wording for policy. I'm not set on any particular name, so please feel free to weigh in on that if you'd like. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#899838: gst-fluendo-mp3: Invalid maintainer address pkg-gstreamer-maintain...@lists.alioth.debian.org
retitle 899838 RM: gst-fluendo-mp3: ROM; Obsolete - superseded by mpg123 in gstreamer1.0-plugins-good reassign 899838 ftp.debian.org thanks Hi, On Thu, May 24, 2018 at 09:43:58AM +0200, Christoph Biedl wrote: > […] > Addresses that were not migrated have been disabled some time ago. As > a result your package is now in violation of a "must" in the Debian > policy (3.3, working email address), making it unfit for release. > > Please fix this before long. Among other reasons, keep in mind bug > reports and important notifications about your package might not reach > you. Thanks for the bug. We think this package should instead be removed - it's not needed any more with current gstreamer 1.0. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#888313: please allow git remote configuration (e.g. for upstream remote)
[ dropped d-x ] Hey all, Thanks for this bug and the work so far. I just wanted to give a couple of thoughts, and maybe later on help with the patch if that's useful. > We can likely do with a single control file entry like: > > X-Vcs-Upstream-Git: -b > > which would match the existing Vcs-* syntax. What do you imagine the `-b' switch doing? For me I am mainly interested in upstream's commits to use with `--upstream-vcs-tag'. Maybe it creates a tracking branch 'upstream/'? My real main question, though, is about derivatives. I mainly work on Ubuntu, and for GNOME stuff we're starting the process of converting off our bzr branches to base on top of Debian's gbp repositories. In order to pull new commits/uploads, we need to have Debian's commits available to `git merge' with. There's a not-consistently-followed-but-could-be convention of using XS-Debian-Vcs-$VCS: $foo in d/control when updating Vcs-Git to represent the (distro) upstream's VCS. It'd be good to use this, or some other metadata, to set up a `debian' remote too. Questions: - Would this be acceptable? - How do we know what to put in the middle of the field there? One answer is the 'Parent' distribution: laney@nightingale> dpkg-vendor --query Parent # running on Ubuntu Debian ? Or we could just directly specify this in gbp.conf when forking a repsitory from Debian: [ clone ] extra-remotes = debian,someurl xxx,yyy ... Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#895473: ca-certificates: Post-install script subprocess return error exit status 3 while upgrading
On Tue, Apr 17, 2018 at 03:57:27PM -0700, Brian Murray wrote: > In Ubuntu I encounter this issue when upgrading ca-certificates from > 20170717~16.04.1 (Ubuntu 16.04) to 20180409 (Ubuntu 18.04) when the > package python-ubuntu-sso-client (only available in Ubuntu 16.04) is > also installed. The python-ubuntu-sso-client package put > "/etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pem" on disk. Here's the > error: Yes, you can do a similar thing on sid: (ca-certificates 20170717 installed initially) root@set-opossum:~# cp /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt /etc/ssl/certs/Go_Daddy_Class_2_CA_dup.pem root@set-opossum:~# apt install ca-certificates Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: ca-certificates 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 161 kB of archives. After this operation, 35.8 kB disk space will be freed. Get:1 http://deb.debian.org/debian sid/main amd64 ca-certificates all 20180409 [161 kB] Fetched 161 kB in 0s (757 kB/s) debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 8975 files and directories currently installed.) Preparing to unpack .../ca-certificates_20180409_all.deb ... Unpacking ca-certificates (20180409) over (20170717) ... Setting up ca-certificates (20180409) ... Updating certificates in /etc/ssl/certs... rehash: skipping duplicate certificate in Go_Daddy_Class_2_CA_dup.pem dpkg: error processing package ca-certificates (--configure): installed ca-certificates package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: ca-certificates E: Sub-process /usr/bin/dpkg returned an error code (1) Adding set -x to the postinst and update-ca-certificates shows it's failing: + openssl rehash . rehash: skipping duplicate certificate in Go_Daddy_Class_2_CA.pem + cleanup + rm -f /tmp/ca-certificates.crt.tmp.vCjXJG + rm -f /tmp/ca-certificates.tmp.AsH4ms + rm -f /tmp/ca-certificates.tmp.e9IHEJ dpkg: error processing package ca-certificates (--install): installed ca-certificates package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: ca-certificates It looks like `c_rehash' just warned in this case and it was non-fatal, but `openssl rehash' exits with a bad error code and we bomb the installation. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#895541: doc-rfc autopkgtest broken, fixed by using Ghostscript's ps2txt instead of unmaintained pstotext
Control: severity -1 normal On Thu, Apr 12, 2018 at 01:23:01PM +0200, Till Kamppeter wrote: > Package: doc-rfc > Version: 20170121-1 > Severity: grave [ In Debian autopkgtest failures aren't RC bugs; downgrading ] > pstotext stopped working with the recent update to Ghostscript 9.22. This is > not only due to the deprecation of "-dDELAYBIND" in Ghostscript (which was > withdrawn in 9.23) but also by an additional problem in Ghostscript. I just wanted to say that I filed #895513 about pstotext being broken in Debian. I agree with Till that moving to ghostscript's own implementation is a sensible idea for you to do here. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#895513: pstotext doesn't work any more: Unrecoverable error: undefined in DELAYBIND
On Thu, Apr 12, 2018 at 09:41:03AM +0100, Iain Lane wrote: > Unrecoverable error: undefined in DELAYBIND > > I tried a patch to add -dREALLYDELAYBIND to the gs commandline, but then > it fails with "Error: /undefined in NOBIND". btw, adding -dNOBIND makes this error go away. I don't know if that's right. But more importantly a real testcase (running the doc-rfc autopkgtest) still fails with errors about setpagedevice. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#895513: pstotext doesn't work any more: Unrecoverable error: undefined in DELAYBIND
Package: pstotext Version: 1.9-6 Severity: grave Tags: upstream Hi, This "makes the package in question unusable by most or all users", hence the severity. pstotext appears to have been broken by ghostscript 9.22. This is me attempting to convert an empty input. (sid-amd64)root@nightingale:/# echo | pstotext -debug GPL Ghostscript 9.22 (2017-10-04) Copyright (C) 2017 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. *** WARNING - the DELAYBIND command has been deprecated, and will be removed in the next version. For now you can restore the behaviour by using -dREALLYDEALYBIND but if you require continued use of this command you should contact the Ghostscript developers. Commercial customers of Artifex should email their support contact, free users are encouraged to talk to us on the #ghostscript IRC channel on irc.freenode.net. Unrecoverable error: undefined in DELAYBIND I tried a patch to add -dREALLYDELAYBIND to the gs commandline, but then it fails with "Error: /undefined in NOBIND". Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#894094: Pin 'release foo' matches foo-proposed in Ubuntu
Package: autopkgtest Version: 5.1 Severity: normal Hi, 7130136a49a2c055d19782f84dba6ea2b27c7006 which we developed last week isn't sufficient (most output elided): laney@nightingale> lxc launch -e images:ubuntu/bionic/amd64 pinning-test laney@nightingale> lxc file push <(echo "Package: *\nPin: release bionic\nPin-Priority: 990") pinning-test/etc/apt/preferences.d/default-release laney@nightingale> lxc file push <(echo "deb http://archive.ubuntu.com/ubuntu bionic-proposed main universe multiverse restricted") pinning-test/etc/apt/sources.list.d/proposed.list laney@nightingale> lxc exec pinning-test -- apt update laney@nightingale> lxc exec pinning-test -- apt policy gnome-online-accounts gnome-online-accounts: Installed: (none) Candidate: 3.27.92-1ubuntu2 Version table: 3.27.92-1ubuntu2 990 990 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 3.27.92-1 990 990 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages We expected that to have 3.72.92-1 as the candidate. Pin a= works for Ubuntu, but the reason that upstream had avoided that is that they wanted a syntax which works for suite and codename (i.e. 'unstable' and 'sid'). For Ubuntu codename is always the release name - 'bionic-proposed' has codename 'bionic', so this breaks down. The implementation isn't fully coherent though, because AFAICS --pin-package=release=foo only works for suite names, not codenames - we always generates a=release pins. We just allow both for the default release, probably partly because this is grabbed from sources.list if unspecified. Can someone think of a clever solution? I'm not clever so the only thing I can come up with off the top of my head is to use distro-info and generate 'release a=' pins for Ubuntu releases and plain 'release' ones otherwise, assuming they are Debian. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#893754: autopkgtest 5.1 "autopkgtest-default-release" breaks tests that exercise apt
Thanks Steve.
On Wed, Mar 21, 2018 at 05:18:53PM -0700, Steve Langasek wrote:
> When autopkgtest 5.2 was recently rolled out to the Ubuntu infrastructure,
> various package-manager-related test suites began to fail as a result of the
> use of APT::Default-Release introduced in 5.1:
> […]
I see autopkgtest already does:
for default in default_releases:
script += 'printf "\nPackage: *\\nPin: release
a=%(default)s\\nPin-Priority: 990\\n" >>
/etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
{'release': release, 'default': default}
if there are default releases passed to this function, which there are
only for -updates. But AIUI (jak?) this is effectively the same as
APT::Default-Release anyway, so I'm proposing that we always do this for
the default release instead of the apt.conf.d snippet.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
signature.asc
Description: PGP signature
Bug#890509: dh_installsystemd/init-system-helpers: support user units
Package: debhelper,init-system-helpers Severity: wishlist Hi there! I'm working on some GNOME changes (upstream) to support activating session components using systemd user units instead of execing them from gnome-session. As a part of this, a few packages will grow systemd user units. AFAICS dh_installsystemd and deb-systemd-helper don't support user units, only system ones. Particularly enabling/disabling is interesting - I think it'd be useful if they were to gain this functionality so that packagers don't have to manage the symlinks themselves. It's mostly a matter of additionally operating on the systemwide non-transient …/user directories listed in systemd.unit(5) - /etc/systemd/user and /usr/lib/systemd/user. I'll try to get some time to work on this change, but I wanted to get your opinions first. (If we decide this is indeed desirable, I'll clone/reassign the bug to each package.) I suppose from dh_installsystemd this should be done at a compat bump, to not break packages which might set user units up themselves already. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ]
Bug#877761: Debdiff
Control: tags -1 + pending confirmed
On Thu, Oct 05, 2017 at 09:50:03AM +0200, Didier Roche wrote:
> Please find a patch enclosed for that issue. Already applied and tested in
> the ubuntu package.
Thanks, I think it looks good. I've committed so it'll be in the next
upload.
It would have been nice to attach a reproducer, so for the record here's
mine. It gives:
laney@raleigh> LC_MESSAGES=zh_CN.UTF-8 ./a.out
Name: 终端
action new-window: 新终端
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
/* gcc $(pkg-config --cflags glib-2.0 gio-unix-2.0) test.c $(pkg-config --libs glib-2.0 gio-unix-2.0) -g
*
* Test with LC_MESSAGES=some_LOCALE ./a.out on a system where the translations
* are available using gettext.
*
*/
#include
#include
#include
#include
#include
int
main()
{
g_autoptr(GDesktopAppInfo) terminal = NULL;
g_autoptr(GError) error = NULL;
g_autoptr(GKeyFile) key_file = g_key_file_new ();
g_autofree gchar *name = NULL;
const gchar * const * actions;
setlocale (LC_MESSAGES, "");
if (!g_key_file_load_from_data_dirs (key_file,
"applications/org.gnome.Terminal.desktop",
NULL,
G_KEY_FILE_NONE,
))
{
g_critical ("Couldn't load GKeyFile: %s", error->message);
return EXIT_FAILURE;
}
terminal = g_desktop_app_info_new_from_keyfile (key_file);
if (!terminal) {
g_critical ("Couldn't make GDesktopAppInfo");
return EXIT_FAILURE;
}
actions = g_desktop_app_info_list_actions (terminal);
name = g_key_file_get_locale_string (key_file,
G_KEY_FILE_DESKTOP_GROUP,
G_KEY_FILE_DESKTOP_KEY_NAME,
NULL,
);
if (!name) {
g_critical ("Couldn't get name: %s", error->message);
return EXIT_FAILURE;
}
g_printf ("Name: %s\n", name);
for (int i = 0; actions[i]; ++i) {
g_printf ("action %s: %s\n", actions[i],
g_desktop_app_info_get_action_name (terminal, actions[i]));
}
}
signature.asc
Description: PGP signature
