Bug#1025314: linux: ext4 checksum errors after resizing

[Dan Nicholson]

It's not fixed on bullseye-backports. I checked yesterday and there have
been no commits on that branch since the 6.0.3 upload.

On Fri, Dec 2, 2022, 5:51 AM Bastian Blank  wrote:

> Control: forcemerge 1023450 -1
>
> On Fri, Dec 02, 2022 at 05:35:06AM -0700, Dan Nicholson wrote:
> > The bullseye-backports 6.0.3 kernel contains an ext4 bug that causes
> > the filesystem to become corrupted after resizing the filesystem. See
> > https://www.spinics.net/lists/linux-ext4/msg85795.html for details and
> > a reproducer.
>
> This is a duplicate and already fixed, thus merging the bug reports.
>
> Bastian
>
> --
> Earth -- mother of the most beautiful women in the universe.
> -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
>

Bug#1025314: linux: ext4 checksum errors after resizing

[Dan Nicholson]

Package: linux-image-6.0.0-0.deb11.2-cloud-amd64
Version: 6.0.3-1~bpo11+1

The bullseye-backports 6.0.3 kernel contains an ext4 bug that causes
the filesystem to become corrupted after resizing the filesystem. See
https://www.spinics.net/lists/linux-ext4/msg85795.html for details and
a reproducer.

This is particularly problematic on systems that resize the root
filesystem during boot using systemd-growfs or similar. ext4 remounts
the filesystem read only after the checksum fails and the system
becomes unbootable. This happens on the EC2 cloud images, for example.

The fix at 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/ext4?h=linux-6.0.y=2f8d9b94176d48d733a461e13bb4f6589653ba05
is in 6.0.8. Some further fixes are identified at
https://www.spinics.net/lists/linux-ext4/msg86163.html but those
haven't been merged yet. I haven't tested either, but I presume the
fix already on 6.0.8 is enough and the remaining fixes are more for
correctness.

--
Dan Nicholson  |  Endless OS Foundation

Bug#1020530: ostree-push: New upstream version 1.0.0

[Dan Nicholson]

Package: ostree-push
Version: 0.20170708+gitabc601f-2

This has been out for a few months and is available on PyPI now. It would
be nice to get this packaged in Debian again.

I took a crack at packaging it. See:

https://salsa.debian.org/dbn/ostree-push/-/tree/debian/unstable
https://salsa.debian.org/dbn/ostree-push/-/tree/upstream/latest
https://salsa.debian.org/dbn/ostree-push/-/tree/pristine-lfs

--
Dan Nicholson  |  Endless OS Foundation

Bug#1015211: Remove 0.0.20171228 tarball

[Dan Nicholson]

I made an MR at
https://salsa.debian.org/debian/ostree-push/-/merge_requests/1 to just
remove it unless you can figure out what's going on. Perhaps it's a
permissions issue?

--
Dan Nicholson  |  Endless OS Foundation

Bug#1015211: ostree-push: pristine-lfs files missing from server

[Dan Nicholson]

Package: ostree-push
Version: 0.20170708+gitabc601f-2

>From a clone of https://salsa.debian.org/debian/ostree-push.git, you can't
checkout the pristine-lfs branch because the first object is not on salsa.

$ git checkout pristine-lfs
Downloading ostree-push_0.0.20171228.orig.tar.gz (17 KB)
Error downloading object: ostree-push_0.0.20171228.orig.tar.gz (ad0201e):
Smudge error: Error downloading ostree-push_0.0.20171228.orig.tar.gz
(ad0201eab71e71e6d62381199ac9925926ddb8be4e49c913269d819298b5c5db):
[ad0201eab71e71e6d62381199ac9925926ddb8be4e49c913269d819298b5c5db] Object
does not exist on the server or you don't have permissions to access it:
[404] Object does not exist on the server or you don't have permissions to
access it

Errors logged to
/home/dan/src/ostree-push-debian/.git/lfs/logs/20220717T123943.933153388.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: ostree-push_0.0.20171228.orig.tar.gz: smudge filter lfs failed

Looking at the commit log, this appears to be from a pre-Debian Apertis
commit and there's no 0.0.20171228 in debian/changelog. Can you upload it
or add a commit that removes this file?

--
Dan Nicholson  |  Endless OS Foundation

Bug#1014030: conmon: Hang with lots of terminal output

[Dan Nicholson]

Tags: patch

Attached is a debdiff that adds the upstream patch for bullseye.

--
Dan Nicholson  |  Endless OS Foundation
diff -Nru conmon-2.0.25+ds1/debian/changelog conmon-2.0.25+ds1/debian/changelog
--- conmon-2.0.25+ds1/debian/changelog	2021-07-14 11:46:07.0 -0600
+++ conmon-2.0.25+ds1/debian/changelog	2022-06-29 09:35:38.0 -0600
@@ -1,3 +1,10 @@
+conmon (2.0.25+ds1-1.1+deb11u1) bullseye; urgency=medium
+
+  * Backport upstream fix to not hang when forwarding container
+stdout/stderr with lots of output. (Closes: #1014030)
+
+ -- Dan Nicholson   Wed, 29 Jun 2022 09:35:38 -0600
+
 conmon (2.0.25+ds1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
--- conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch	1969-12-31 17:00:00.0 -0700
+++ conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch	2022-06-29 09:33:10.0 -0600
@@ -0,0 +1,37 @@
+From 2b873145a85a212f703c9c00db13717ab0204318 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano 
+Date: Tue, 2 Feb 2021 11:35:39 +0100
+Subject: [PATCH] conn_sock: do not fail on EAGAIN
+
+commit 6287bd884d9bf29e76ac877e0c7e6aad04bc24a4 introduced the
+regression.
+
+writes to the attached sockets must be blocking, otherwise the
+write_back_to_remote_consoles() shutdowns the socket when write fails
+with EAGAIN.
+
+I've verified the original issue fixed with commit 62887bd is not
+reintroduced with this patch.
+
+Closes: https://github.com/containers/conmon/issues/236
+
+Signed-off-by: Giuseppe Scrivano 
+---
+ src/conn_sock.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/conn_sock.c b/src/conn_sock.c
+index e569113..02aee70 100644
+--- a/src/conn_sock.c
 b/src/conn_sock.c
+@@ -280,7 +280,6 @@ static gboolean attach_cb(int fd, G_GNUC_UNUSED GIOCondition condition, gpointer
+ 			pexit("Failed to allocate memory");
+ 		}
+ 		init_remote_sock(remote_sock, srcsock);
+-		g_unix_set_fd_nonblocking(new_fd, TRUE, NULL);
+ 		remote_sock->fd = new_fd;
+ 		g_unix_fd_add(remote_sock->fd, G_IO_IN | G_IO_HUP | G_IO_ERR, remote_sock_cb, remote_sock);
+ 		g_ptr_array_add(remote_sock->dest->readers, remote_sock);
+-- 
+2.30.2
+
diff -Nru conmon-2.0.25+ds1/debian/patches/series conmon-2.0.25+ds1/debian/patches/series
--- conmon-2.0.25+ds1/debian/patches/series	2021-07-14 11:46:07.0 -0600
+++ conmon-2.0.25+ds1/debian/patches/series	2022-06-29 09:33:10.0 -0600
@@ -1 +1,2 @@
 0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
+0002-conn_sock-do-not-fail-on-EAGAIN.patch

Bug#1014030: conmon: Hang with lots of terminal output

[Dan Nicholson]

Package: conmon
Version: 2.0.25+ds1-1.1

conmon 2.0.25 contains a bug where the container will hang when there
is lots of terminal output. You can easily reproduce like so:

podman run -it --rm debian:latest
find /

This is fixed in 2.0.26 with
https://github.com/containers/conmon/commit/2b873145a85a212f703c9c00db13717ab0204318.
See https://github.com/containers/conmon/issues/236.

--
Dan Nicholson  |  Endless OS Foundation

Bug#1006905: bullseye-pu: package ostree/2020.8-2+deb11u1

[Dan Nicholson]

On Mon, Mar 7, 2022 at 6:09 PM Simon McVittie  wrote:
>
> If d/p/Fall-back-if-copy_file_range-fails-with-EINVAL.patch is not applied,
> users with an eCryptFS encrypted home directory cannot use `flatpak --user`.
> If they had already configured all necessary remotes before encrypting the
> home directory, the symptom is that `flatpak build-bundle` crashes; if not,
> from my tests on unstable, it appears that the symptom is that
> `flatpak remote-add` fails. (#1004467)
> There are indications from upstream bug reports that this patch might
> also fix similar issues for ZFS users, although this is not yet confirmed.

This is a safe patch as it just extends the cases where a fallback
will be run. Since it affects all users of ecryptfs, it seems like a
good idea to include.

> If d/p/Fix-marking-static-delta-commits-as-partial.patch is not applied,
> interrupted downloads can result in a corrupted local repository, requiring
> manual cleanup via `flatpak repair` or `ostree fsck`.

This is a really unfortunate bug in ostree that should be fixed ASAP.
For Endless I'm going to backport this to all of our supported stable
branches but haven't gotten around to it yet.

> If d/p/libotutil-Avoid-infinite-recursion-during-error-unwinding.patch is
> not applied, some failure modes (in particular the symptom of #1004467)
> lead to a crash instead of a graceful failure.

The change here is clearly correct and should have no unintended side
effects. Since this also affects all users of ecryptfs, it's a good
idea to have it in stable.

> If d/p/Fix-translation-of-file-URIs-into-paths.patch is not applied,
> users will be unable to install Flatpak apps from paths on the local
> filesystem that contain a backslash or non-ASCII, most commonly during
> "sideloading" from a USB stick created by `flatpak create-usb`.

We've been shipping this in Endless stable for about a year with no
reported issues.

> If d/p/lib-Fix-a-bad-call-to-g_file_get_child.patch is not applied,
> checking out only a subset of a commit (most frequently seen in Flatpak
> when installing locale data) can fail with an assertion failure if a
> backport or local build of GLib 2.71 is in use. I'm a little unsure about
> this one for bullseye, since I would generally not recommend backporting
> something as foundational as GLib, but it's a one-line fix. With my
> GNOME team hat on, we need to get GLib >= 2.72 into bookworm within the
> next few weeks, so if someone does a backport of bookworm's GLib into
> bullseye-backports, then the priority of this change will suddenly go up.

Even though this would only manifest with a newer GLib release, I
think this is a good idea to include in bullseye. It's a bit
unfortunate that GLib changed the semantics of g_file_get_child, but
the change makes OSTree checkouts more robust all around in the face
of user supplied subpaths.

> [ Risks ]
> I would say this is low-risk. They're narrowly-targeted patches, and
> all are straightforward backports, either from upstream release 2022.2
> (in unstable, not in testing yet) or from older releases that are already
> in testing.

I would agree that this is low risk. These patches fix real bugs, were
vetted by upstream, and are narrowly scoped. I think the risk of
regressions is very low. These are all things I plan to put in our
stable branch for Endless (I actually have the task to do that this
week).

--
Dan

Bug#991623: intltool: make distcheck broken

[Dan Nicholson]

Should be fixed in
https://salsa.debian.org/gnome-team/intltool/-/merge_requests/4.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#991623: intltool: make distcheck broken

[Dan Nicholson]

Package: intltool
Version: 0.51.0-6

A patch in version 0.51.0-5.1 causes intltool-merge to use a lock file
for a cache. Unfortunately, the upstream patch did not update the
intltool Makefile.in.in stub to clean up the lock file. This causes
"make distcheck" to fail for projects using intltool. See
https://bugs.launchpad.net/intltool/+bug/1712194.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#991525: golang-github-containernetworking-plugin-dnsname should depend on dnsmasq-base

[Dan Nicholson]

Package: golang-github-containernetworking-plugin-dnsname
Version: 1.1.1+ds1-4+b7

This plugin works by invoking dnsmasq and will immediately fail if it
can't be found:
https://github.com/containers/dnsname/blob/main/plugins/meta/dnsname/service.go#L19.
As such, it should depend on dnsmasq-base since it's entirely
non-functional without it.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#991440:

[Dan Nicholson]

On Fri, Jul 23, 2021 at 11:22 AM Dan Nicholson  wrote:
>
> See https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/3.

This change would also allow dropping an unnecessary Recommends:
malcontent from gnome-initial-setup since the only reason for that is
to make sure the interfaces and policies are available.

--
Dan

Bug#991440:

[Dan Nicholson]

See https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/3.
--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#991440: libmalcontent-0-0: Missing D-Bus interfaces

[Dan Nicholson]

Package: libmalcontent-0-0
Version: 0.10.0-2
Severity: normal

Currently the com.endlessm.ParentalControls D-Bus interface
definitions and the polkit policy are provided from the malcontent
package. This is wrong, though, as the interface provides an
account-service extension that's managed entirely from
libmalcontent-0. The malcontent package provides the malcontent-client
CLI tool, but most programs such as flatpak and gnome-control-center
use the libmalcontent API to access the parental controls data.
Without the D-Bus interface files this functionality is broken.

I suggest moving these files into the libmalcontent-0-0 package.
Another option is to have a separate malcontent-data package, but IMO
there would be little to gain by just having the interfaces separately
installable.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#948645: pesign FTBFS: nss-induced error: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘496’ to ‘240’ [-Werror=overflow]

[Dan Nicholson]

This was fixed upstream in
https://github.com/rhboot/pesign/commit/b535d1ac5cbcdf18a97d97a92581e38080d9e521.

Bug#966394: libgtk-3-bin: Add dependency on librsvg2-common

[Dan Nicholson]

Package: libgtk-3-bin
Version: 3.24.20-1
Severity: normal

libgtk-3-bin provides gtk-encode-symbolic-svg. This program works by
loading an SVG icon and generating a PNG from it. Loading of the SVG
is done by the gdk-pixbuf, and the SVG loader is provided by
librsvg2-common. IMO, libgtk-3-bin should have a full dependency on
librsvg2-common since one of the programs it provides is entirely
non-functional without it.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#927889: libgit2: Specify certificate locations

[Dan Nicholson]

On Thu, Mar 12, 2020 at 4:22 AM Fabian Grünbichler
 wrote:
>
> this bug affects cargo depending on which build environment libgit2 was
> built-in:
>
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953668
>
> are you planning on build-depending on ca-certificates or applying this
> patch, or should all users of libgit2 work around this by providing the
> ca-certificates location themselves by default?

cargo was the reason I did this since it also affected armhf (IIRC).
Adding a build dependency on ca-certificates is also a reasonable way
to go.

--
Dan

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Dan Nicholson]

On Wed, 5 Feb 2020 11:40:32 -0600 Michael Shuler 
wrote:
> On 2/5/20 11:12 AM, Dan Nicholson wrote:
> > 2. Build openssl with LFS as noted above.
>
> Noted, thanks. This is why I am starting to believe this is a bug with
> openssl, not ca-certificates.

Can this be reassigned to openssl in the meantime? I think it's a goal to
have all of Debian built with largefile support, anyways.

Bug#824649: ostree: document how to prepare and update a .deb-based system root

[Dan Nicholson]

On Mon, 5 Nov 2018 11:13:06 + Simon McVittie  wrote:
> On Sat, 03 Nov 2018 at 12:44:16 +0100, Felix Krull wrote:
> > what's the status on this? Is there anything else I can do or did you
just not
> > get around to it yet?
>
> Reviewing this is on my list, but it's a somewhat long list :-)
>
> (Because this involves new package names and the NEW queue, there's a
> strong incentive to get it right first time, rather than having more
> than one attempt.)

ostree-boot got in a while ago and it looks like you added the
documentation Felix started in
https://salsa.debian.org/debian/ostree/-/commits/debian/master/debian/ostree-boot-examples.
So, I think this can be closed now?

--
Dan

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Dan Nicholson]

It posted https://salsa.debian.org/debian/openssl/merge_requests/4 to
build openssl with largefile support.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Dan Nicholson]

I recently ran into this same issue and dug into it for a while. The
real problem stems from
https://sourceware.org/bugzilla/show_bug.cgi?id=23960. The issue is
that glibc 2.28 changed readdir to always use getdents64. This causes
problems when you're running a 32 bit guest in QEMU on a 64 bit host.
So, this would also affect running an i386 guest on an x86_64 host,
for example.

The issue is that rehash calls OPENSSL_DIR_read on the certificate
directory. This is actually just a wrapper around readdir. However, if
you compile openssl (really libcrypto) with large file support, then
glibc actually uses readdir64, which will use a dirent64 structure
that doesn't have the overflow issues that the regular dirent
structure has in this situation.

After building openssl locally with future=+lfs in
DEB_BUILD_MAINT_OPTIONS, I was able to get the right behavior. Here's
a comparison (certs is just a local directory with one of the symlinks
from /etc/ssl/certs copied into it).

Current behavior:

root@talkbox:~# /qemu-arm-static -strace /usr/bin/openssl rehash
certs/ 2>&1 | grep getdents64
20411 getdents64(3,-13637592,32768,-559685376,-13637592,-622472) = 128

With LFS libcrypto:

root@talkbox:~#
LD_LIBRARY_PATH=libssl1.1-patched/usr/lib/arm-linux-gnueabihf
/qemu-arm-static -strace /usr/bin/openssl rehash certs/ 2>&1 | grep
getdents64
20402 getdents64(3,-13637592,32768,0,32,-13637624) = 128
20402 getdents64(3,-13637592,32768,128,32,-13637624) = 0

And just the normal rehash output:

root@talkbox:~# openssl rehash -v certs/
Doing certs/
root@talkbox:~#
LD_LIBRARY_PATH=libssl1.1-patched/usr/lib/arm-linux-gnueabihf/ openssl
rehash -v certs/
Doing certs/
link thawte_Primary_Root_CA.pem -> 2e4eed3c.0

So, I think there are a few options on what to do.

1. Change update-ca-certificates back to using c_rehash. Presumably
perl is built with LFS and it's readdir wrapper DTRT.

2. Build openssl with LFS as noted above.

3. Wait for a fix to be hashed out between the glibc, kernel and qemu folks.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#945160: RFP: pytest-datafiles -- pytest plugin for using predefined datafiles

[Dan Nicholson]

Package: wnpp
Severity: wishlist

This is a pytest plugin for creating a tmpdir with predefined files
and/or directories. It's required for the bst-external testsuite,
which is currently ignoring test failures.

The source is on PyPI.

https://pypi.org/project/pytest-datafiles/

Original source is on github and the license is MIT:

https://github.com/omarkohl/pytest-datafiles
https://github.com/omarkohl/pytest-datafiles/blob/master/LICENSE

The only dependency appears to be pytest (python-pytest or python3-pytest).

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#927889: libgit2: Specify certificate locations

[Dan Nicholson]

Source: libgit2
Version: 0.27.7+dfsg.1-0.1
Severity: important
Tags: patch

When libgit2 is built with mbedTLS, it tries to determine the trusted
certificate location at build time. Unless openssl and ca-certificates are
installed, then it won't find the appropriate path and it will set the CA
chain to NULL when using mbedTLS. This means that using libgit2 with an
https remote immediately fails with the message "The certificate is not
correctly signed by the trusted CA".

Instead of relying on detection, pass in the standard ca-certificates path
via CERT_LOCATION. While here, pass in USE_HTTPS=mbedTLS for the release
build so it doesn't try to use a different TLS implementation. This was
only being done for the static build.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
diff -Nru libgit2-0.27.7+dfsg.1/debian/changelog libgit2-0.27.7+dfsg.1/debian/changelog
--- libgit2-0.27.7+dfsg.1/debian/changelog	2018-12-26 11:29:30.0 -0600
+++ libgit2-0.27.7+dfsg.1/debian/changelog	2019-04-24 10:52:15.0 -0500
@@ -1,3 +1,11 @@
+libgit2 (0.27.7+dfsg.1-0.1endless1) master; urgency=medium
+
+  * Specify mbedTLS for https for both builds and pass in the standard
+certificate location since it otherwise fails to set a certificate
+path if openssl and ca-certificates are not installed at build time.
+
+ -- Dan Nicholson   Wed, 24 Apr 2019 10:52:15 -0500
+
 libgit2 (0.27.7+dfsg.1-0.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru libgit2-0.27.7+dfsg.1/debian/rules libgit2-0.27.7+dfsg.1/debian/rules
--- libgit2-0.27.7+dfsg.1/debian/rules	2018-12-26 11:29:30.0 -0600
+++ libgit2-0.27.7+dfsg.1/debian/rules	2019-04-24 10:47:18.0 -0500
@@ -18,6 +18,8 @@
 	dh_auto_configure --builddirectory=build-debian-release -- \
 		-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
 		-DUSE_OPENSSL:BOOL=OFF \
+		-DUSE_HTTPS=mbedTLS \
+		-DCERT_LOCATION=/etc/ssl/certs/ca-certificates.crt \
 		-DUSE_CURL_SSL:BOOL=ON \
 		-DUSE_GSSAPI:BOOL=ON \
 		-DTHREADSAFE:BOOL=ON \
@@ -28,6 +30,7 @@
 		-DCMAKE_BUILD_TYPE:STRING=Release \
 		-DTHREADSAFE:BOOL=ON \
 		-DUSE_HTTPS=mbedTLS \
+		-DCERT_LOCATION=/etc/ssl/certs/ca-certificates.crt \
 		-DUSE_CURL_SSL:BOOL=ON \
 		-DUSE_GSSAPI:BOOL=ON \
 		-DBUILD_CLAR:BOOL=OFF \

Bug#869194: awscli failing to upload empty files on => due to python-s3transfer

[Dan Nicholson]

On Tue, 15 May 2018 15:14:24 -0700 Joseph Herlant 
wrote:
> 
> There are actually 2 upstream patches, the 2nd one superseeding the
> 1st: https://github.com/boto/s3transfer/pull/88 and
> https://github.com/boto/s3transfer/pull/102

I'm the author of the 2nd pull request and have been using it in our
packages at Endless for a while. I'm not sure why upstream is totally
unresponsive, but I'm confident it does the right thing. It would be
great if this could be carried in Debian until upstream does something
about the issue.

--
Dan

Bug#903481: debootstrap: Save apt compatible lists

[Dan Nicholson]

Package: debootstrap
Version: 1.0.106
Severity: normal
Tags: patch

Since commit 
https://salsa.debian.org/installer-team/debootstrap/commit/48d77abf3a4209f7cff72aec20f618e086169aa7
debootstrap no longer saves repo list files in an apt compatible
format. A side effect of the old debootstrap.invalid setup was that
the mv_invalid_to function renamed the downloaded repo lists to files
that apt uses. Before you'd get the following:

var/lib/apt/lists/deb.debian.org_debian_dists_sid_InRelease

Now you get

var/lib/apt/lists/http:__deb.debian.org_debian_dists_sid_InRelease

That means that you're required to run apt update after debootstrap
finishes since apt will ignore the downloaded lists.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
From ef2c7d1d7810b50f58554da0351e6daf572be11d Mon Sep 17 00:00:00 2001
From: Dan Nicholson 
Date: Tue, 10 Jul 2018 06:05:42 -0500
Subject: [PATCH] Strip URL scheme from apt lists

Apt saves the repo lists without the URL scheme, so when debootstrap
keeps the URL scheme in the name they're not usable by apt. That means
you need to run apt update in the completed target even though the lists
have already been fetched. Without this change the default InRelease was
saved as http:__deb.debian.org_debian_dists_sid_InRelease.

This is a regression from commit 48d77ab since the old
debootstrap.invalid setup would rename the lists to the proper name in
most cases since it stripped the leading http://.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/functions b/functions
index 38c710b..7b893d7 100644
--- a/functions
+++ b/functions
@@ -490,12 +490,12 @@ apt_dest () {
 	pkg)
 		local m="$5"
 		printf "%s" "$APTSTATE/lists/"
-		echo "${m}_$6" | sed 's/\//_/g'
+		echo "${m}_$6" | sed -e 's,^[^:]\+://,,' -e 's/\//_/g'
 		;;
 	rel)
 		local m="$3"
 		printf "%s" "$APTSTATE/lists/"
-		echo "${m}_$4" | sed 's/\//_/g'
+		echo "${m}_$4" | sed -e 's,^[^:]\+://,,' -e 's/\//_/g'
 		;;
 	esac
 }
-- 
2.11.0

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Wed, 22 Nov 2017 05:08:47 -0600 Dan Nicholson <nichol...@endlessm.com
> wrote:
> On Fri, Aug 25, 2017 at 4:07 PM, Dan Nicholson <nichol...@endlessm.com
>
> wrote:
> 
> > On Tue, Aug 22, 2017 at 10:23 AM, Dan Nicholson <nicholson@endlessm.
com>
> > wrote:
> > >
> > > That certainly helps, but it doesn't cover everything since the
> > > mkdir's and ln's could fail. Those are easier to handle by adding
-p
> > > and -f, respectively, but that's a subtle change in behavior for
ln
> > > relative to the mknod change. In the mknod case, an existing
device is
> > > left as is. In the ln case, it would be forcefully overwritten.
> >
> > Attached is a patch to handle all the potentially failing cases. I
> > tested this by running debootstrap once, wiping everything the
target
> > except /dev, and running debootstrap again. It succeeded. As
mentioned
> > above, an existing device is skipped while the symlinks are
forcefully
> > overwritten. That seems inconsistent, but I'm not sure it matters. I
> > could easily change the mknod function to forcefully remove, too.
> >
> 
> Ping? Patch is pretty straightforward, but I'd be happy to adjust any
> direction people like.

Ping? It seemed like people were interested in having this change. Happy
to change the patch in whatever way anyone wants or just step aside and
let one of the maintainers fix it the way they want.

Bug#868030: qemu-user-static: Please enable "F - fix binary" flag for binfmt entries

[Dan Nicholson]

On Mon, 17 Jul 2017 13:54:55 -0500 Dan Nicholson <nichol...@endlessm.com
> wrote:
> Attached debdiff makes use of the --fix-binary option added in
> binfmt-support 2.1.7, which sets the "F" flag in the binfmt entry. I
> tested this on amd64 stretch (with binfmt-support-2.1.7-1 from sid). I
> created a chroot with debootstrap --arch=armhf and then chrooted into
> it. It worked correctly and I was able to run the armhf binaries with
> no changes besides installing qemu-user-static.
> 
> I left qemu-user-binfmt without the --fix-binary flag since it seems
> unlikely that would work as well with dynamic linking and shared
> libraries. It can easily be changed to require binfmt-support 2.1.7 in
> both cases and pass --fix-binary unconditionally.

Ping. Anything needed here? It would be really nice to have this in as
it would make qemu-user-static much more usable out of the box.

--
Dan

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Fri, Aug 25, 2017 at 4:07 PM, Dan Nicholson <nichol...@endlessm.com>
wrote:

> On Tue, Aug 22, 2017 at 10:23 AM, Dan Nicholson <nichol...@endlessm.com>
> wrote:
> >
> > That certainly helps, but it doesn't cover everything since the
> > mkdir's and ln's could fail. Those are easier to handle by adding -p
> > and -f, respectively, but that's a subtle change in behavior for ln
> > relative to the mknod change. In the mknod case, an existing device is
> > left as is. In the ln case, it would be forcefully overwritten.
>
> Attached is a patch to handle all the potentially failing cases. I
> tested this by running debootstrap once, wiping everything the target
> except /dev, and running debootstrap again. It succeeded. As mentioned
> above, an existing device is skipped while the symlinks are forcefully
> overwritten. That seems inconsistent, but I'm not sure it matters. I
> could easily change the mknod function to forcefully remove, too.
>

Ping? Patch is pretty straightforward, but I'd be happy to adjust any
direction people like.

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Tue, Aug 22, 2017 at 10:23 AM, Dan Nicholson <nichol...@endlessm.com> wrote:
>
> That certainly helps, but it doesn't cover everything since the
> mkdir's and ln's could fail. Those are easier to handle by adding -p
> and -f, respectively, but that's a subtle change in behavior for ln
> relative to the mknod change. In the mknod case, an existing device is
> left as is. In the ln case, it would be forcefully overwritten.

Attached is a patch to handle all the potentially failing cases. I
tested this by running debootstrap once, wiping everything the target
except /dev, and running debootstrap again. It succeeded. As mentioned
above, an existing device is skipped while the symlinks are forcefully
overwritten. That seems inconsistent, but I'm not sure it matters. I
could easily change the mknod function to forcefully remove, too.
From 5e97c8d293764015fae25085cb884c5bf265207a Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Fri, 25 Aug 2017 15:44:26 -0500
Subject: [PATCH] Handle existing /dev (Closes: #872577)

When devices.tar.gz was being used, the devices would be written into
place with tar. This has the effect that the devices would be merged
into an existing /dev in the target. setup_devices_simple() does not
handle this case and fails when /dev already exists.

Normally, the target would be empty and this wouldn't be an issue.
However, some tools that use debootstrap to initialize a target depended
on the old behavior. In particular, the obs-build package used for OBS
sets up a minimal /dev in the generic prep code before using debootstrap
to install packages needed for building debian packages.

Allow for existing devices, directories and symlinks by skipping
existing devices and directories and forcefully overwriting existing
symlinks.
---
 functions | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/functions b/functions
index 3cfa0d4..877cdbd 100644
--- a/functions
+++ b/functions
@@ -1161,26 +1161,39 @@ setup_dynamic_devices () {
 	esac
 }
 
+# Create a device node if it does not exist. By default, the mode is 666.
+mknod_if_needed () {
+	local device="$1"
+	local type="$2"
+	local major="$3"
+	local minor="$4"
+	local mode="${5:-666}"
+
+	if [ ! -e "$device" ]; then
+		mknod -m "$mode" "$device" "$type" "$major" "$minor"
+	fi
+}
+
 setup_devices_simple () {
 	# The list of devices that can be created in a container comes from
 	# src/core/cgroup.c in the systemd source tree.
-	mknod -m 666 $TARGET/dev/null	c 1 3
-	mknod -m 666 $TARGET/dev/zero	c 1 5
-	mknod -m 666 $TARGET/dev/full	c 1 7
-	mknod -m 666 $TARGET/dev/random	c 1 8
-	mknod -m 666 $TARGET/dev/urandom	c 1 9
-	mknod -m 666 $TARGET/dev/tty	c 5 0
-	mkdir $TARGET/dev/pts/ $TARGET/dev/shm/
+	mknod_if_needed $TARGET/dev/null	c 1 3
+	mknod_if_needed $TARGET/dev/zero	c 1 5
+	mknod_if_needed $TARGET/dev/full	c 1 7
+	mknod_if_needed $TARGET/dev/random	c 1 8
+	mknod_if_needed $TARGET/dev/urandom	c 1 9
+	mknod_if_needed $TARGET/dev/tty	c 5 0
+	mkdir -p $TARGET/dev/pts/ $TARGET/dev/shm/
 	# Inside a container, we might not be allowed to create /dev/ptmx.
 	# If not, do the next best thing.
-	if ! mknod -m 666 $TARGET/dev/ptmx c 5 2; then
+	if ! mknod_if_needed $TARGET/dev/ptmx c 5 2; then
 		warning MKNOD "Could not create /dev/ptmx, falling back to symlink. This chroot will require /dev/pts mounted with ptmxmode=666"
-		ln -s pts/ptmx $TARGET/dev/ptmx
+		ln -sf pts/ptmx $TARGET/dev/ptmx
 	fi
-	ln -s /proc/self/fd   $TARGET/dev/fd
-	ln -s /proc/self/fd/0 $TARGET/dev/stdin
-	ln -s /proc/self/fd/1 $TARGET/dev/stdout
-	ln -s /proc/self/fd/2 $TARGET/dev/stderr
+	ln -sf /proc/self/fd   $TARGET/dev/fd
+	ln -sf /proc/self/fd/0 $TARGET/dev/stdin
+	ln -sf /proc/self/fd/1 $TARGET/dev/stdout
+	ln -sf /proc/self/fd/2 $TARGET/dev/stderr
 }
 
 setup_devices_fakechroot () {
-- 
2.5.5

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Sun, Aug 20, 2017 at 4:57 PM, Philip Hands <p...@hands.com> wrote:
> Ben Hildred <426...@gmail.com> writes:
>
>> On Sun, Aug 20, 2017 at 3:25 AM, Ansgar Burchardt <ans...@debian.org> wrote:
>>
>>> Dan Nicholson writes:
>>> > On Fri, Aug 18, 2017 at 2:48 PM, Henrique de Moraes Holschuh
>>> > <h...@debian.org> wrote:
>>> >> Wouldn't it be more straigthforward to "test -e || mknod" ?
>>> >
>>> > I definitely considered that, but it seemed more noisy to the code to
>>> > add a conditional for every call. But I'd be fine reworking to that
>>> > approach if that's more acceptable, though.
>>>
>>> You can always introduce a `mknod_if_not_exists` function or so.  Though
>>> I'm not sure this is worth here (the name is so long the `test -e` is
>>> almost shorter).
>>>
>>> Ansgar
>>>
>>>
>> function mknod-e () {
>> [ -e "$1" ] || mknod "$@"
>> }
>
> $1 for mknod in this case is liable to be '-m'
>
> The attached patch might satisfy the quest for neatness.
>
> One could instead call the function something like
> ensure-exists-in-target and leave the /dev/'s on all the filenames, if
> that were considered clearer.

That certainly helps, but it doesn't cover everything since the
mkdir's and ln's could fail. Those are easier to handle by adding -p
and -f, respectively, but that's a subtle change in behavior for ln
relative to the mknod change. In the mknod case, an existing device is
left as is. In the ln case, it would be forcefully overwritten.

It's not a big deal in my case (both OBS and debootstrap setup /dev
properly), but I don't know if that's important to others.

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Fri, Aug 18, 2017 at 2:48 PM, Henrique de Moraes Holschuh
<h...@debian.org> wrote:
> On Fri, 18 Aug 2017, Dan Nicholson wrote:
>> When devices.tar.gz was being used, the devices would be written into
>> place with tar. This has the effect that the devices would be merged
>> into an existing /dev in the target. setup_devices_simple() does not
>> handle this case and fails when /dev already exists.
>>
>> Normally, the target would be empty and this wouldn't be an issue.
>> However, some tools that use debootstrap to initialize a target depended
>> on the old behavior. In particular, the obs-build package used for OBS
>> sets up a minimal /dev in the generic prep code before using debootstrap
>> to install packages needed for building debian packages.
>>
>> The attached patch fixes this by using tar to emulate the old
>> behavior. It would be really helpful if this could be applied.
>
> Wouldn't it be more straigthforward to "test -e || mknod" ?

I definitely considered that, but it seemed more noisy to the code to
add a conditional for every call. But I'd be fine reworking to that
approach if that's more acceptable, though.

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

Package: debootstrap
Version: 1.0.89
Severity: normal
Tags: patch

When devices.tar.gz was being used, the devices would be written into
place with tar. This has the effect that the devices would be merged
into an existing /dev in the target. setup_devices_simple() does not
handle this case and fails when /dev already exists.

Normally, the target would be empty and this wouldn't be an issue.
However, some tools that use debootstrap to initialize a target depended
on the old behavior. In particular, the obs-build package used for OBS
sets up a minimal /dev in the generic prep code before using debootstrap
to install packages needed for building debian packages.

The attached patch fixes this by using tar to emulate the old
behavior. It would be really helpful if this could be applied.

Thanks!

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
From d5b723f800c027e0d377627946bc1d697a5be322 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Fri, 18 Aug 2017 13:36:27 -0500
Subject: [PATCH] Merge devices to /dev with tar

When devices.tar.gz was being used, the devices would be written into
place with tar. This has the effect that the devices would be merged
into an existing /dev in the target. setup_devices_simple() does not
handle this case and fails when /dev already exists.

Normally, the target would be empty and this wouldn't be an issue.
However, some tools that use debootstrap to initialize a target depended
on the old behavior. In particular, the obs-build package used for OBS
sets up a minimal /dev in the generic prep code before using debootstrap
to install packages needed for building debian packages.

Emulate the old behavior by creating the devices in a temporary
debootstrap/dev and then use tar to write them into place.
---
 functions | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/functions b/functions
index 3cfa0d4..0d99a95 100644
--- a/functions
+++ b/functions
@@ -1163,24 +1163,30 @@ setup_dynamic_devices () {
 
 setup_devices_simple () {
 	# The list of devices that can be created in a container comes from
-	# src/core/cgroup.c in the systemd source tree.
-	mknod -m 666 $TARGET/dev/null	c 1 3
-	mknod -m 666 $TARGET/dev/zero	c 1 5
-	mknod -m 666 $TARGET/dev/full	c 1 7
-	mknod -m 666 $TARGET/dev/random	c 1 8
-	mknod -m 666 $TARGET/dev/urandom	c 1 9
-	mknod -m 666 $TARGET/dev/tty	c 5 0
-	mkdir $TARGET/dev/pts/ $TARGET/dev/shm/
+	# src/core/cgroup.c in the systemd source tree. The devices are first
+	# created in a temporary /dev and written into place using tar like
+	# the old devices tarball.
+	mkdir $TARGET/debootstrap/dev
+	mknod -m 666 $TARGET/debootstrap/dev/null	c 1 3
+	mknod -m 666 $TARGET/debootstrap/dev/zero	c 1 5
+	mknod -m 666 $TARGET/debootstrap/dev/full	c 1 7
+	mknod -m 666 $TARGET/debootstrap/dev/random	c 1 8
+	mknod -m 666 $TARGET/debootstrap/dev/urandom	c 1 9
+	mknod -m 666 $TARGET/debootstrap/dev/tty	c 5 0
+	mkdir $TARGET/debootstrap/dev/pts/ $TARGET/debootstrap/dev/shm/
 	# Inside a container, we might not be allowed to create /dev/ptmx.
 	# If not, do the next best thing.
-	if ! mknod -m 666 $TARGET/dev/ptmx c 5 2; then
+	if ! mknod -m 666 $TARGET/debootstrap/dev/ptmx c 5 2; then
 		warning MKNOD "Could not create /dev/ptmx, falling back to symlink. This chroot will require /dev/pts mounted with ptmxmode=666"
-		ln -s pts/ptmx $TARGET/dev/ptmx
+		ln -s pts/ptmx $TARGET/debootstrap/dev/ptmx
 	fi
-	ln -s /proc/self/fd   $TARGET/dev/fd
-	ln -s /proc/self/fd/0 $TARGET/dev/stdin
-	ln -s /proc/self/fd/1 $TARGET/dev/stdout
-	ln -s /proc/self/fd/2 $TARGET/dev/stderr
+	ln -s /proc/self/fd   $TARGET/debootstrap/dev/fd
+	ln -s /proc/self/fd/0 $TARGET/debootstrap/dev/stdin
+	ln -s /proc/self/fd/1 $TARGET/debootstrap/dev/stdout
+	ln -s /proc/self/fd/2 $TARGET/debootstrap/dev/stderr
+
+	# Tar the temporary /dev into place to merge with an existing /dev
+	(cd $TARGET/debootstrap; tar -cf - dev) | (cd $TARGET; tar -xf -)
 }
 
 setup_devices_fakechroot () {
-- 
2.11.0

Bug#868030: qemu-user-static: Please enable "F - fix binary" flag for binfmt entries

[Dan Nicholson]

Attached debdiff makes use of the --fix-binary option added in
binfmt-support 2.1.7, which sets the "F" flag in the binfmt entry. I
tested this on amd64 stretch (with binfmt-support-2.1.7-1 from sid). I
created a chroot with debootstrap --arch=armhf and then chrooted into
it. It worked correctly and I was able to run the armhf binaries with
no changes besides installing qemu-user-static.

I left qemu-user-binfmt without the --fix-binary flag since it seems
unlikely that would work as well with dynamic linking and shared
libraries. It can easily be changed to require binfmt-support 2.1.7 in
both cases and pass --fix-binary unconditionally.

--
Dan
From e09b030e49ca67d3eb7a53884580bc4b67116e86 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Mon, 17 Jul 2017 10:03:23 -0500
Subject: [PATCH] Use binfmt-support --fix-binary option (#868030)

binfmt-support 2.1.7 added the --fix-binary boolean option that maps to
the kernel's F binfmt flag[1]. This flag instructs the kernel to open
the binfmt handler immediately when registered. This is very helpful in
the case of qemu-user-static where emulation of another architecture can
be handled with no updates to a chroot or container running foreign
architecture binaries.

However, in the case of qemu-user and qemu-update-binfmt, this is less
likely to be helpful since dynamic linking would still require the many
libraries in the alternate root. In that case, continue to run
update-binfmts without --fix-binary.

1. https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
---
 debian/binfmt-update-in | 2 +-
 debian/control-in   | 2 +-
 debian/rules| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/binfmt-update-in b/debian/binfmt-update-in
index aedf6dc..7c0da5d 100644
--- a/debian/binfmt-update-in
+++ b/debian/binfmt-update-in
@@ -86,7 +86,7 @@ case "$DPKG_MAINTSCRIPT_NAME:$1" in
 	eval "case $fmt in $omit) magic= ;; *) magic=\"\$${fmt}_magic\" mask=\"\$${fmt}_mask\" ;; esac"
 	if [ -n "$magic" ]; then
 		update-binfmts --package @PACKAGE@ --install qemu-$fmt /usr/bin/qemu-$fmt@SUFFIX@ \
-			--magic "$magic" --mask "$mask" --offset 0 --credential yes
+			--magic "$magic" --mask "$mask" --offset 0 --credential yes @FIX_BINARY@
 	else
 		remove_binfmt $fmt
 	fi
diff --git a/debian/control-in b/debian/control-in
index 0aaf556..e80e7b3 100644
--- a/debian/control-in
+++ b/debian/control-in
@@ -435,7 +435,7 @@ Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 mips mipsel powerpc pow
 Built-Using: ${built-using}
 Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: binfmt-support
+Recommends: binfmt-support (>= 2.1.7)
 Provides: qemu-user-binfmt
 Conflicts: qemu-user-binfmt
 Suggests: sudo
diff --git a/debian/rules b/debian/rules
index 3c8d74f..d8d9e6a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -253,9 +253,9 @@ ifeq ($(enable_linux_user),enable)
 
 	# binfmt support
 	for x in postinst prerm; do \
-	sed -e s/@SUFFIX@/-static/ -e s/@PACKAGE@/qemu-user-static/ \
+	sed -e s/@SUFFIX@/-static/ -e s/@PACKAGE@/qemu-user-static/ -e "s/@FIX_BINARY@/--fix-binary yes/" \
 		debian/binfmt-update-in >> debian/qemu-user-static.$$x.debhelper ; \
-	sed -e s/@SUFFIX@// -e s/@PACKAGE@/qemu-user-binfmt/ \
+	sed -e s/@SUFFIX@// -e s/@PACKAGE@/qemu-user-binfmt/ -e s/@FIX_BINARY@// \
 		debian/binfmt-update-in >> debian/qemu-user-binfmt.$$x.debhelper ; \
 	done
 
-- 
2.5.5

Bug#853820: Please add support for the F flag

[Dan Nicholson]

Tags: patch

Attached is a patch which seems to implement this correctly. I was
able to verify that it registers the binfmt correctly, but I haven't
actually run it through a system with a new enough kernel yet.

This is against upstream rather than a debian patch. Since upstream
doesn't have a bug tracker, I'm assuming it will be picked up
correctly here. Please let me know if there's a better place to send
it.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
From 805f0588efc33b5e57cfc2608c4960a82ea149c3 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Tue, 27 Jun 2017 13:20:22 -0500
Subject: [PATCH] Add support for fix binary flag

Recent kernels provide a binfmt flag F referred to as fix binary[1].
This flag instructs the kernel to open the interpreter immediately and
use always use the opened image. This has a big advantage in containers
or chroots where the interpreter may not exist at the specified path.

A primary use case would be for a static linked QEMU user emulator where
an architecture can be emulated in a container or chroot without any
alterations so long as the binfmt configuration is handled on the host.

1. https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
---
 man/update-binfmts.man8 |  7 ++-
 src/format.c|  5 +
 src/format.h|  1 +
 src/update-binfmts.c| 17 +++--
 4 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/man/update-binfmts.man8 b/man/update-binfmts.man8
index a5e5f7a..01b7163 100644
--- a/man/update-binfmts.man8
+++ b/man/update-binfmts.man8
@@ -237,6 +237,10 @@ Whether to preserve the original
 .Li argv[0]
 when running the interpreter, rather than overwriting it with the full path
 to the binary.
+.It Fl Fl fix-binary Cm yes , Fl Fl fix-binary Cm no
+Whether to open the emulator binary immediately and always use the opened
+image. This allows the emulator from the host to be used regardless of usage
+in changeroots or different mount namespaces.
 .El
 .Ss FORMAT FILES
 A format file is a sequence of options, one per line, corresponding roughly
@@ -259,8 +263,9 @@ The
 .Ar extension ,
 .Ar detector ,
 .Ar credentials ,
+.Ar preserve ,
 and
-.Ar preserve
+.Ar fix-binary
 options correspond to the command-line options of the same names.
 .Sh EXIT STATUS
 .Bl -tag -width 4n
diff --git a/src/format.c b/src/format.c
index 0bfdfe1..892 100644
--- a/src/format.c
+++ b/src/format.c
@@ -77,6 +77,7 @@ struct binfmt *binfmt_load (const char *name, const char *filename, int quiet)
 READ_LINE (detector, 1);
 READ_LINE (credentials, 1);
 READ_LINE (preserve, 1);
+READ_LINE (fix_binary, 1);
 
 #undef READ_LINE
 
@@ -108,6 +109,7 @@ struct binfmt *binfmt_new (const char *name, Hash_table *args)
 SET_FIELD (detector);
 SET_FIELD (credentials);
 SET_FIELD (preserve);
+SET_FIELD (fix_binary);
 
 #undef SET_FIELD
 
@@ -182,6 +184,7 @@ int binfmt_write (const struct binfmt *binfmt, const char *filename)
 WRITE_FIELD (detector);
 WRITE_FIELD (credentials);
 WRITE_FIELD (preserve);
+WRITE_FIELD (fix_binary);
 
 #undef WRITE_FIELD
 
@@ -207,6 +210,7 @@ void binfmt_print (const struct binfmt *binfmt)
 PRINT_FIELD (detector);
 PRINT_FIELD (credentials);
 PRINT_FIELD (preserve);
+PRINT_FIELD (fix_binary);
 
 #undef PRINT_FIELD
 }
@@ -231,6 +235,7 @@ void binfmt_free (struct binfmt *binfmt)
 free (binfmt->detector);
 free (binfmt->credentials);
 free (binfmt->preserve);
+free (binfmt->fix_binary);
 free (binfmt);
 }
 
diff --git a/src/format.h b/src/format.h
index 54a09e0..82fa924 100644
--- a/src/format.h
+++ b/src/format.h
@@ -32,6 +32,7 @@ struct binfmt {
 char *detector;
 char *credentials;
 char *preserve;
+char *fix_binary;
 };
 
 struct binfmt *binfmt_load (const char *name, const char *filename, int quiet);
diff --git a/src/update-binfmts.c b/src/update-binfmts.c
index 857b214..6aea32c 100644
--- a/src/update-binfmts.c
+++ b/src/update-binfmts.c
@@ -363,6 +363,7 @@ static int act_enable (const char *name)
 	const char *interpreter;
 	const char *credentials;
 	const char *preserve;
+	const char *fix_binary;
 	char *regstring;
 
 	procdir_name = xasprintf ("%s/%s", procdir, name);
@@ -417,10 +418,13 @@ static int act_enable (const char *name)
 		? "C" : "";
 	preserve = (binfmt->preserve && !strcmp (binfmt->preserve, "yes"))
 		? "P" : "";
-	regstring = xasprintf (":%s:%c:%s:%s:%s:%s:%s%s\n",
+	fix_binary =
+		(binfmt->fix_binary && !strcmp (binfmt->fix_binary, "yes"))
+		? "F" : "";
+	regstring = xasprintf (":%s:%c:%s:%s:%s:%s:%s%s%s\n",
 			   name, type, binfmt->offset, binfmt->magic,
 			   binfmt->mask, interpreter,
-			   credentials, preserve);
+			   credentials, preserve, fix_binary);
 	if (tes

Bug#865674: gnutls28: Disable RPATH during build

[Dan Nicholson]

Source: gnutls28
Version: 3.5.13-2
Severity: normal
Tags: patch

The --enable/disable-rpath option is provided by one of the GnuTLS m4
macros. It's used when searching for system libraries. When a library is
not found in one of /usr/lib or /usr/lib64, the build will supplement
the link command with an RPATH. Since most system libraries will be
found in the multiarch library directory (e.g.,
/usr/lib/x86_64-linux-gnu), then the build will add an RPATH to this
directory.

This is usually not an issue since the build later strips all the RPATHs
from the binaries. However, for tests that run during the build, this
might result in using system installed gnutls libraries instead of the
build libraries. This particularly can cause a test failure in
test-ciphers-openssl.sh since cipher-openssl-compat links to the system
libcrypto, and the RPATH added by the build will cause the system
libgnutls to be used instead of the built libgnutls.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
From 1625b56b9e15ca2b2cee3b337e8985689c9cc8da Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Fri, 23 Jun 2017 11:16:07 -0500
Subject: [PATCH] Configure with --disable-rpath

The --enable/disable-rpath option is provided by one of the GnuTLS m4
macros. It's used when searching for system libraries. When a library is
not found in one of /usr/lib or /usr/lib64, the build will supplement
the link command with an RPATH. Since most system libraries will be
found in the multiarch library directory (e.g.,
/usr/lib/x86_64-linux-gnu), then the build will add an RPATH to this
directory.

This is usually not an issue since the build later strips all the RPATHs
from the binaries. However, for tests that run during the build, this
might result in using system installed gnutls libraries instead of the
build libraries. This particularly can cause a test failure in
test-ciphers-openssl.sh since cipher-openssl-compat links to the system
libcrypto, and the RPATH added by the build will cause the system
libgnutls to be used instead of the built libgnutls.
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 7f6758f..de6dc4b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,7 @@ override_dh_auto_configure:
 	dh_auto_configure --verbose -- \
 	--enable-ld-version-script --enable-cxx \
 	--enable-static \
+	--disable-rpath \
 	--without-lzo \
 	--enable-libdane --without-tpm --disable-guile \
 	--enable-openssl-compatibility \
-- 
2.1.4

Bug#865297: libgnutls-deb0-28: Check for /dev/urandom validity broken

[Dan Nicholson]

Package: libgnutls-deb0-28
Version: 3.3.8-6+deb8u6
Severity: normal

If the application closes open files during startup (e.g., a daemon),
it may close the file that gnutls has open for /dev/urandom. The
recommended way to handle this situation is to call
gnutls_global_init() again. This will check if the fd for /dev/urandom
is still valid and re-open it if not.

Unfortunately, the way that the /dev/urandom fd is checked is not
reliable. It only checks the mode, which might be the same if the
application reused the fd for another character device with the same
permissions (e.g., /dev/null).

A fix for this was recently backported to the gnutls_3_3_x branch:

https://gitlab.com/gnutls/gnutls/commit/5006914fda50f25807451a03616cdf2e7be0268f

It would be great if this could be included in jessie as otherwise
calling gnutls_global_init() a 2nd time is unreliable. If it helps, I
can prepare a patch for the gnutls28 package, but I wasn't quite sure
about the patch naming conventions there.

Thanks,

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#862803: Respect the DEB_BUILD_OPTIONS=nocheck option

[Dan Nicholson]

On Wed, 17 May 2017 12:15:36 +0200 Krzesimir Nowak  wrote:
> 
> Attached patch should do the trick.

--- rules.old   2017-05-17 12:08:47.186950253 +0200
+++ rules   2017-05-17 12:10:35.833876166 +0200
@@ -27,7 +27,9 @@
    $(NULL)
 
 override_dh_auto_test:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
    debian/test.sh
+endif
 
 override_dh_auto_install:
    dh_auto_install

Actually, in the patch I think you want ifneq. This always trips me up,
but what happens is that $(filter will strip out everything except
nocheck from $(DEB_BUILD_OPTIONS). So, you want to test that the result
is _not_ empty. Or you could be explicit and check that the filtered
output matches nocheck.

https://www.gnu.org/software/make/manual/html_node/Text-Functions.html

It would be nice if make had a function for "is this word in a list",
but I don't think it does. The confusing ifeq + filter usage is about as
close as you can get.

--
Dan

Bug#860836: appstream-glib: run dh --with gir for ${gir:Depends}

[Dan Nicholson]

Source: appstream-glib
Version: 0.6.8-1
Severity: normal
Tags: patch

Currently the gir1.2-appstreamglib-1.0 package has no dependencies.
This is because the ${gir:Depends} value used in the control file
never gets set since dh_girepository never runs. Pass --with gir to dh
to make that happen.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
diff -Nru appstream-glib-0.6.8/debian/changelog appstream-glib-0.6.8/debian/changelog
--- appstream-glib-0.6.8/debian/changelog	2017-02-05 09:09:19.0 -0600
+++ appstream-glib-0.6.8/debian/changelog	2017-04-20 14:26:29.0 -0500
@@ -1,3 +1,9 @@
+appstream-glib (0.6.8-2) UNRELEASED; urgency=medium
+
+  * debian/rules: Pass --with gir to calculate ${gir:Depends}.
+
+ -- Dan Nicholson <nichol...@endlessm.com>  Thu, 20 Apr 2017 14:00:22 -0500
+
 appstream-glib (0.6.8-1) unstable; urgency=medium
 
   * New upstream version 0.6.8
diff -Nru appstream-glib-0.6.8/debian/rules appstream-glib-0.6.8/debian/rules
--- appstream-glib-0.6.8/debian/rules	2017-01-19 13:44:28.0 -0600
+++ appstream-glib-0.6.8/debian/rules	2017-04-20 14:25:32.0 -0500
@@ -13,7 +13,7 @@
 INSTALLDIR = $(CURDIR)/debian/tmp
 
 %:
-	dh $@ --with autoreconf
+	dh $@ --with autoreconf,gir
 
 override_dh_auto_configure:
 	dh_auto_configure -- $(AS_CONFIGURE_ARGS)

Bug#830271: flatpak: Don't initialize system repo in postinst

[Dan Nicholson]

On Tue, Feb 14, 2017 at 8:07 AM, Simon McVittie <s...@debian.org> wrote:
> On Thu, 07 Jul 2016 at 12:05:26 -0700, Dan Nicholson wrote:
>> Currently flatpak.postinst runs `flatpak remote-list --system` in
>> order to initialize the system repo. I don't see any reason why this
>> is needed, though.
>
> Flatpak upstream (Alex) specifically asked me to do this. I think the
> rationale was that guaranteeing that /var/lib/flatpak/exports/share
> exists means it will be more reliable and efficient for desktop
> environments to monitor it for new apps: they will be able to use
> inotify rather than either not monitoring it or falling back to polling.

Yeah, I can see that use case.

>> My real problem is that we want to have /var/lib/flatpak/repo be a
>> symlink to /ostree/repo so we can share the objects for the runtimes
>> with the OS.
>
> I suggest setting that up before installing flatpak, or deleting
> /var/lib/flatpak/repo and replacing it when preparing your "golden
> image" (if your OS is OSTree-managed, then the postinst won't run
> on end-user systems anyway).

Of course, we already do this. I just didn't see the usefulness in
initializing the repo since flatpak does that itself. Having it
nonexistent out of the box would allow me to detect that something was
wrong if the repo already existed.

Anyway, it's not a big deal. You can close this.

--
Dan

Bug#851284: apt tmpfiles.d configuration

[Dan Nicholson]

Package: apt
Version: 1.4~beta3
Tags: patch

Although apt creates all the directories in /var on install, it's
entirely possible that they won't exist at runtime. This is most likely
to happen on a stateless[1] systems, but could also happen if an
administrator wipes the directories in /var when cleaning up.

Provide a tmpfiles.d configuration to create these directories at boot
time on systemd systems. This will help ensure the directories always
exist so apt doesn't fail with missing directory errors.

1. http://0pointer.net/blog/projects/stateless.html

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
From 74ae3e2edb9549843cdbef1c7827b41333452830 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Fri, 13 Jan 2017 11:00:20 -0600
Subject: [PATCH] Provide tmpfiles.d configuration for stateless systems

Although apt creates all the directories in /var on install, it's
entirely possible that they won't exist at runtime. This is most likely
to happen on a stateless[1] systems, but could also happen if an
administrator wipes the directories in /var when cleaning up.

Provide a tmpfiles.d configuration to create these directories at boot
time on systemd systems. This will help ensure the directories always
exist so apt doesn't fail with missing directory errors.

1. http://0pointer.net/blog/projects/stateless.html
---
 CMakeLists.txt | 5 +
 apt-tmpfiles.conf  | 7 +++
 debian/apt.install | 1 +
 3 files changed, 13 insertions(+)
 create mode 100644 apt-tmpfiles.conf

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0afc73c..35c4eb3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -228,3 +228,8 @@ install_empty_directories(
   ${STATE_DIR}/periodic
   ${LOG_DIR}
 )
+
+# Install tmpfiles.d configuration for stateless (empty /var) systems
+install(FILES apt-tmpfiles.conf
+DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/tmpfiles.d"
+RENAME apt.conf)
diff --git a/apt-tmpfiles.conf b/apt-tmpfiles.conf
new file mode 100644
index 000..cfc58a5
--- /dev/null
+++ b/apt-tmpfiles.conf
@@ -0,0 +1,7 @@
+# See tmpfiles.d(5) for details
+
+# Type Path   Mode UID GID Age Argument
+d /var/cache/apt/archives/partial --   -   -
+d /var/lib/apt/lists/partial  --   -   -
+d /var/lib/apt/mirrors/partial--   -   -
+d /var/lib/apt/periodic   --   -   -
diff --git a/debian/apt.install b/debian/apt.install
index 2c21878..dcf4cf6 100644
--- a/debian/apt.install
+++ b/debian/apt.install
@@ -15,6 +15,7 @@ usr/lib/apt/methods/
 usr/lib/apt/planners/dump
 usr/lib/apt/solvers/dump
 usr/lib/dpkg/methods/apt/
+usr/lib/tmpfiles.d/apt.conf
 usr/share/bash-completion/completions/
 usr/share/doc/apt
 usr/share/locale/*/*/apt.mo
-- 
2.1.4

Bug#830271: flatpak: Don't initialize system repo in postinst

[Dan Nicholson]

Package: flatpak
Version: 0.6.7-1
Severity: normal

Currently flatpak.postinst runs `flatpak remote-list --system` in
order to initialize the system repo. I don't see any reason why this
is needed, though. The user may only want to install user
applications. Furthermore, install a system application is privileged
and the system repository will be setup whenever that happens by
flatpak in the exact same way that the postinst script is doing it.

My real problem is that we want to have /var/lib/flatpak/repo be a
symlink to /ostree/repo so we can share the objects for the runtimes
with the OS. Having flatpak forcefully create the system repo in
postinst makes it more difficult for us to manage this setup. The
postrm script will still work correctly whether the postinst script
creates the repo or not.

Thanks!

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#820359: init-system-helpers: Handle \ escape in systemd unit names

[Dan Nicholson]

On Thu, Apr 7, 2016 at 12:27 PM, Dan Nicholson <nichol...@endlessm.com> wrote:
> On Thu, Apr 7, 2016 at 11:56 AM, Felipe Sateler <fsate...@debian.org> wrote:
>>
>> AFAICT, the only difference between quotewords and split is that
>> quotewords takes into account quotes to allow "multiple words" to be
>> parsed as a single token. I don't think we have use for such a feature
>> (there are no such files in the archive).
>>
>> So, unless I'm missing something, this could be further simplified to
>> just use split.
>
> Yeah, that does seem possible. The only fields parsed are WantedBy,
> RequiredBy, Also and Alias. Since the values here are unit names,
> there shouldn't be any instances where there's valid whitespace in the
> words. So, I think you could do split followed by quote stripping and
> everything would be fine. I'll try that out.
>
> Of course, if init-system-helpers ever does parse any fields might
> contain contain multiple quoted words, then you'd need to go back to
> using quotewords or something like that.

The attached patch seems to work in my testing.

--
Dan
From 504671d973c2779e968bb975e844d0d04d6e67c9 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Thu, 7 Apr 2016 11:08:23 -0700
Subject: [PATCH] script: Handle \ escapes in unit names properly

Unit names can contain valid \ escapes in systemd. See systemd-escape(1)
for examples. Text::ParseWords::shellwords breaks that since it strips \
in addition to quotes. Instead, just use split as the only fields parsed
will contain unit names, which can't have whitespace. Any
leading/trailing quotes are then stripped separately.

Closes: #820359
---
 debian/changelog  |  7 +++
 script/deb-systemd-helper | 14 ++
 script/dh_systemd_enable  |  1 -
 script/dh_systemd_start   | 11 +--
 4 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index e5e0ce5..01c1433 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,13 @@ init-system-helpers (1.30) UNRELEASED; urgency=medium
   * dh_systemd_*: Add DH promise to avoid being called for no reason.
   * Update Vcs-* fields to use https.
 
+  [ Dan Nicholson ]
+  * deb-systemd-helper, dh_systemd_start: Use split rather than
+Text::ParseWords::shellwords since the latter will strip valid \
+escapes from unit names. The values then need to have leading and
+trailing quotes stripped. (Closes: #820359)
+  * dh_systemd_enable: Drop unused Text::ParseWords use.
+
  -- Felipe Sateler <fsate...@debian.org>  Fri, 11 Mar 2016 18:48:39 -0300
 
 init-system-helpers (1.29) unstable; urgency=medium
diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 2a87cb4..7241555 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -85,7 +85,6 @@ use warnings;
 use File::Path qw(make_path); # in core since Perl 5.001
 use File::Basename; # in core since Perl 5
 use File::Temp qw(tempfile); # in core since Perl 5.6.1
-use Text::ParseWords qw(shellwords); # in core since Perl 5
 use Getopt::Long; # in core since Perl 5
 # Make Data::Dumper::Dumper available if present (not present on systems that
 # only have perl-base, not perl).
@@ -183,13 +182,18 @@ sub get_link_closure {
 
 my $unit_name = basename($service_path);
 
+# The keys parsed from the unit file below can only have unit names
+# as values. Since unit names can't have whitespace in systemd,
+# simply use split and strip any leading/trailing quotes. See
+# systemd-escape(1) for examples of valid unit names.
 open my $fh, '<', $service_path or error("unable to read $service_path");
 while (my $line = <$fh>) {
 chomp($line);
 my $service_link;
 
 if ($line =~ /^\s*(WantedBy|RequiredBy)=(.+)$/i) {
-for my $value (shellwords($2)) {
+for my $value (split(/\s+/, $2)) {
+$value =~ s/^(["'])(.*)\g1$/$2/;
 my $wants_dir = "/etc/systemd/system/$value";
 $wants_dir .= '.wants' if $1 eq 'WantedBy';
 $wants_dir .= '.requires' if $1 eq 'RequiredBy';
@@ -198,7 +202,8 @@ sub get_link_closure {
 }
 
 if ($line =~ /^\s*Also=(.+)$/i) {
-for my $value (shellwords($1)) {
+for my $value (split(/\s+/, $1)) {
+$value =~ s/^(["'])(.*)\g1$/$2/;
 if ($value ne $unit_name) {
 push @links, get_link_closure($value, find_unit($value));
 }
@@ -206,7 +211,8 @@ sub get_link_closure {
 }
 
 if ($line =~ /^\s*Alias=(.+)$/i) {
-for my $value (shellwords($1)) {
+for my $value (split(/\s+/, $1)) {
+$value =~ s/^(["'])(.*)\g1$/$2/;
 if ($value ne $unit_name) {
  

Bug#820359: init-system-helpers: Handle \ escape in systemd unit names

[Dan Nicholson]

On Thu, Apr 7, 2016 at 11:56 AM, Felipe Sateler  wrote:
>
> AFAICT, the only difference between quotewords and split is that
> quotewords takes into account quotes to allow "multiple words" to be
> parsed as a single token. I don't think we have use for such a feature
> (there are no such files in the archive).
>
> So, unless I'm missing something, this could be further simplified to
> just use split.

Yeah, that does seem possible. The only fields parsed are WantedBy,
RequiredBy, Also and Alias. Since the values here are unit names,
there shouldn't be any instances where there's valid whitespace in the
words. So, I think you could do split followed by quote stripping and
everything would be fine. I'll try that out.

Of course, if init-system-helpers ever does parse any fields might
contain contain multiple quoted words, then you'd need to go back to
using quotewords or something like that.

--
Dan

Bug#820359: init-system-helpers: Handle \ escape in systemd unit names

[Dan Nicholson]

Package: init-system-helpers
Version: 1.29

Systemd unit names can have valid \ escape characters. See
systemd-escape(1) for examples. When a unit references a another unit
with escaped characters, init-system-helpers handles them incorrectly.
For example, a unit file having WantedBy=foo\x2dbar.target will have
an /etc/systemd/system/foox2dbar.target.wants directory created
without the x escaped by \.

The attached patch fixes this.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
From 4d2c003bd4f7739d1d075e7f7e067292030e47ce Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Thu, 7 Apr 2016 11:08:23 -0700
Subject: [PATCH] script: Handle \ escapes in unit names properly

Unit names can contain valid \ escapes in systemd. See systemd-escape(1)
for examples. Text::ParseWords::shellwords breaks that since it strips \
in addition to quotes. Use quotewords directly with keep set and strip
the leading/trailing quotes as necessary.
---
 debian/changelog  |  7 +++
 script/deb-systemd-helper | 14 ++
 script/dh_systemd_enable  |  1 -
 script/dh_systemd_start   | 10 --
 4 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index e5e0ce5..bd16993 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,13 @@ init-system-helpers (1.30) UNRELEASED; urgency=medium
   * dh_systemd_*: Add DH promise to avoid being called for no reason.
   * Update Vcs-* fields to use https.
 
+  [ Dan Nicholson ]
+  * deb-systemd-helper, dh_systemd_start: Use Text::ParseWords::quotewords
+rather than shellwords since the latter will strip valid \ escapes
+from unit names. The returned values then need to have leading and
+trailing quotes stripped.
+  * dh_systemd_enable: Drop unused Text::ParseWords use.
+
  -- Felipe Sateler <fsate...@debian.org>  Fri, 11 Mar 2016 18:48:39 -0300
 
 init-system-helpers (1.29) unstable; urgency=medium
diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 2a87cb4..dc10b0c 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -85,7 +85,7 @@ use warnings;
 use File::Path qw(make_path); # in core since Perl 5.001
 use File::Basename; # in core since Perl 5
 use File::Temp qw(tempfile); # in core since Perl 5.6.1
-use Text::ParseWords qw(shellwords); # in core since Perl 5
+use Text::ParseWords qw(quotewords); # in core since Perl 5
 use Getopt::Long; # in core since Perl 5
 # Make Data::Dumper::Dumper available if present (not present on systems that
 # only have perl-base, not perl).
@@ -183,13 +183,17 @@ sub get_link_closure {
 
 my $unit_name = basename($service_path);
 
+# Use quotewords to split, but keep characters and remove
+# leading/trailing quotes since \ is valid in systemd unit names.
+# See systemd-escape(1).
 open my $fh, '<', $service_path or error("unable to read $service_path");
 while (my $line = <$fh>) {
 chomp($line);
 my $service_link;
 
 if ($line =~ /^\s*(WantedBy|RequiredBy)=(.+)$/i) {
-for my $value (shellwords($2)) {
+for my $value (quotewords('\s+', 1, $2)) {
+$value =~ s/^(["'])(.*)\g1$/$2/;
 my $wants_dir = "/etc/systemd/system/$value";
 $wants_dir .= '.wants' if $1 eq 'WantedBy';
 $wants_dir .= '.requires' if $1 eq 'RequiredBy';
@@ -198,7 +202,8 @@ sub get_link_closure {
 }
 
 if ($line =~ /^\s*Also=(.+)$/i) {
-for my $value (shellwords($1)) {
+for my $value (quotewords('\s+', 1, $1)) {
+$value =~ s/^(["'])(.*)\g1$/$2/;
 if ($value ne $unit_name) {
 push @links, get_link_closure($value, find_unit($value));
 }
@@ -206,7 +211,8 @@ sub get_link_closure {
 }
 
 if ($line =~ /^\s*Alias=(.+)$/i) {
-for my $value (shellwords($1)) {
+for my $value (quotewords('\s+', 1, $1)) {
+$value =~ s/^(["'])(.*)\g1$/$2/;
 if ($value ne $unit_name) {
 push @links, { dest => $service_path, src => "/etc/systemd/system/$1" };
 }
diff --git a/script/dh_systemd_enable b/script/dh_systemd_enable
index 39955c4..a45615b 100755
--- a/script/dh_systemd_enable
+++ b/script/dh_systemd_enable
@@ -9,7 +9,6 @@ dh_systemd_enable - enable/disable systemd unit files
 use strict;
 use Debian::Debhelper::Dh_Lib;
 use File::Find;
-use Text::ParseWords qw(shellwords); # in core since Perl 5
 
 =head1 SYNOPSIS
 
diff --git a/script/dh_systemd_start b/script/dh_systemd_start
index 4e22d59..8b14d8e 100755
--- a/script/dh_systemd_start
+++ b/script/dh_systemd_start
@@ -9,7 +9,7 @@ dh_systemd_start - start/stop/restart systemd unit files
 use strict;
 use Debian::Debhelper::Dh_Lib;
 use File::Find;
-use Text::ParseWords qw(shellwords); # in core s

Bug#819551: lintian: binaries-missing-depends-on-libc failure

[Dan Nicholson]

Package: lintian
Version: 2.5.42.1

If you run the binaries-missing-depends-on-libc test with
-Wl,--as-needed in LDFLAGS (or on by default in your linker), then you
might not actually get libc linked into the C++ library. Then the test
fails because only the C library has libc in NEEDED but is missing the
Depends.

Running the test with -Wl,--no-as-needed fixes this and seems like a
smart thing to do in general as we don't want the linker to silently
remove things we're trying to test. Attached patch does that.

--
Dan
diff -Nru lintian-2.5.42.1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules lintian-2.5.42.1endless1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules
--- lintian-2.5.42.1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules	2016-02-08 12:50:20.0 -0800
+++ lintian-2.5.42.1endless1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules	2016-03-29 15:02:25.0 -0700
@@ -2,6 +2,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+# Make sure the C++ library actually links to libc
+export DEB_LDFLAGS_MAINT_APPEND=-Wl,--no-as-needed
+
 %:
 	dh $@
 

Bug#819506: Keep TEXTREL objdump info

[Dan Nicholson]

Package: lintian
Version: 2.5.42.1

The shared-libs-non-pic-i386 test fails on i386 because the objdump
helper no longer keeps the TEXTREL info from the dynamic section.
Attached patch fixes it.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
The i386 non-pic test needs to see if TEXTREL is in the dynamic section,
so keep that.

diff -Nru lintian-2.5.42.1/helpers/coll/objdump-info-helper lintian-2.5.42.1endless1/helpers/coll/objdump-info-helper
--- lintian-2.5.42.1/helpers/coll/objdump-info-helper	2016-02-08 12:50:20.0 -0800
+++ lintian-2.5.42.1endless1/helpers/coll/objdump-info-helper	2016-03-29 12:11:22.0 -0700
@@ -168,6 +168,8 @@
 $value =~ s/.*\[//;
 $value =~ s/\]\s*$//;
 $keep = 1;
+} elsif ($type eq 'TEXTREL') {
+$keep = 1;
 }
 $keep = 1
   if $value =~ s/^(?:Shared library|Library soname): \[(.*)\]/$1/;

Bug#811555: dh_systemd_enable should run before dh_installinit

[Dan Nicholson]

Package: cdbs
Version: 0.4.130

Currently, the debhelper rules run dh_systemd_enable and
dh_systemd_start consecutively towards the end of the binary-install
phase. However, according to dh_systemd_enable(1), dh_systemd_enable
should run before dh_installinit. Indeed, the dh-systemd debhelper
sequence module does it this way:

$ cat /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm 
#!/usr/bin/perl
use warnings;
use strict;
use Debian::Debhelper::Dh_Lib;

# dh_systemd_enable runs unconditionally, and before dh_installinit, so that
# the latter can use invoke-rc.d and all symlinks are already in place.
insert_before("dh_installinit", "dh_systemd_enable");

# dh_systemd_start handles the case where there is no corresponding init
# script, so it runs after dh_installinit.
insert_after("dh_installinit", "dh_systemd_start");

1

The attached patch should fix it.

--
DanFrom 119c49e03fdd8c3b9e5ab9603474effd4177a810 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Tue, 19 Jan 2016 11:57:05 -0800
Subject: [PATCH] Run dh_systemd_enable before dh_installinit

According to dh_systemd_enable(1), it needs to be run before
dh_installinit. Change the ordering in binary-install appropriately.
---
 1/rules/debhelper.mk.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/1/rules/debhelper.mk.in b/1/rules/debhelper.mk.in
index 13d149a..4e43a56 100644
--- a/1/rules/debhelper.mk.in
+++ b/1/rules/debhelper.mk.in
@@ -212,6 +212,9 @@ $(patsubst %,binary-install/%,$(DEB_ALL_PACKAGES)) :: binary-install/%:
 		$(call cdbs_expand_curvar,DEB_DH_INSTALL_MENU_ARGS)
 	dh_installcron -p$(cdbs_curpkg) \
 		$(call cdbs_expand_curvar,DEB_DH_INSTALL_CRON_ARGS)
+	$(if $(wildcard /usr/bin/dh_systemd_enable),\
+		dh_systemd_enable -p$(cdbs_curpkg) \
+			$(call cdbs_expand_curvar,DEB_DH_SYSTEMD_ENABLE_ARGS))
 	dh_installinit -p$(cdbs_curpkg) \
 		$(if $(call cdbs_expand_curvar,DEB_UPDATE_RCD_PARAMS),\
 			--update-rcd-params="$(call cdbs_strip_quotes,$(call cdbs_expand_curvar,DEB_UPDATE_RCD_PARAMS))") \
@@ -248,9 +251,6 @@ $(patsubst %,binary-install/%,$(DEB_ALL_PACKAGES)) :: binary-install/%:
 		$(if $(DEB_DH_INSTALL_SOURCEDIR),\
 			--sourcedir=$(DEB_DH_INSTALL_SOURCEDIR)) \
 		$(call cdbs_expand_curvar,DEB_DH_INSTALL_ARGS)
-	$(if $(wildcard /usr/bin/dh_systemd_enable),\
-		dh_systemd_enable -p$(cdbs_curpkg) \
-			$(call cdbs_expand_curvar,DEB_DH_SYSTEMD_ENABLE_ARGS))
 	$(if $(wildcard /usr/bin/dh_systemd_start),\
 		dh_systemd_start -p$(cdbs_curpkg) \
 			$(call cdbs_expand_curvar,DEB_DH_SYSTEMD_START_ARGS))
-- 
2.1.4

Bug#494172: libosmesa6: libOSMesa / libGl symbol collision

[Dan Nicholson]

On Tue, Jun 29, 2010 at 8:33 AM, Julien Cristau jcris...@debian.org wrote:
 [Josep, sorry for the very late answer]

 Hi Dan,

 Josep reported the following bug against libOSMesa in Debian (see
 http://bugs.debian.org/494172), and I'm not quite sure how it's supposed
 to work, so I was hoping you'd know a bit more:

 On Thu, Aug  7, 2008 at 17:52:56 +0200, Josep wrote:

 I'm integrating osmesa with an application that use Qt/OpenGl to do
 Off Screen rendering.

 But there is somthing that fails.
 First something strange happends in the link proces. The linking proces is:

 g++  -o qgreco release/com.o release/crono.o release/dbas.o release/dbasv2.o
 release/error.o release/fam.o release/full_rt_rcs.o release/gid.o
 release/grabar.o release/grecoPost.o release/ideas.o release/iges.o
 release/image.o release/init.o release/input.o release/mialloc.o
 release/neutral.o release/octree.o release/oiges.o release/param.o
 release/po_rcs.o release/ptd_rcs.o release/qt_win.o release/rcs.o
 release/reflexiones.o release/rt_rcs.o release/teselar.o
 release/vertex_arrays.o release/xogdibuj.o release/glwidget.o
 release/glwindow.o release/logowidget.o release/twindow.o release/gwindow.o
 release/initrcs.o release/memoryrc.o release/moc_glwidget.o
 release/moc_glwindow.o release/moc_logowidget.o release/moc_twindow.o
 release/moc_gwindow.o release/moc_initrcs.o    -L/usr/X11R6/lib -L/usr/lib
 -lOSMesa -lXext -lX11 -lm -lQtXml -lQtOpenGL -lQtGui -lQtCore -lQtUiTools
 -lGLU -lGL -lpthread

 The important part are the linked libraries, first I noticied that depending
 on the order of the libraries the program fails with segmentation fault
 (linking GL after OSMesa ) or drawing bad images (linking OSMesa after GL).

 Then I found that if I link with the Mesa Libraries compiled from the
 original sources my program run well.

 The difference I noticied:
 Using:
 nm -D /usr/lib/libOSMesa.so (from Debian Packages)
 Returns a lot of symbols included gl*
 And ldd.
         linux-vdso.so.1 =  (0x7fff1e7fe000)
         libm.so.6 = /lib/libm.so.6 (0x7fad15f38000)
         libpthread.so.0 = /lib/libpthread.so.0 (0x7fad15d1c000)
         libc.so.6 = /lib/libc.so.6 (0x7fad159c8000)
         /lib64/ld-linux-x86-64.so.2 (0x7fad1664)



 nm -D mycompiledlibOSMesa.so (compiled from sources)
 Returns only some symbols without gl*
 And ldd.
         linux-vdso.so.1 =  (0x7fff467fe000)
 -        libGL.so.1 = /usr/lib/libGL.so.1 (0x7f6a3e297000)
         libc.so.6 = /lib/libc.so.6 (0x7f6a3df44000)
         libX11.so.6 = /usr/lib/libX11.so.6 (0x7f6a3dc37000)
         libXext.so.6 = /usr/lib/libXext.so.6 (0x7f6a3da26000)
         libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x7f6a3d821000)
         libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x7f6a3d61e000)
         libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x7f6a3d519000)
         libdrm.so.2 = /usr/lib/libdrm.so.2 (0x7f6a3d31)
         libm.so.6 = /lib/libm.so.6 (0x7f6a3d08c000)
         libpthread.so.0 = /lib/libpthread.so.0 (0x7f6a3ce7)
         libdl.so.2 = /lib/libdl.so.2 (0x7f6a3cc6c000)
         /lib64/ld-linux-x86-64.so.2 (0x7f6a3e742000)
         libxcb-xlib.so.0 = /usr/lib/libxcb-xlib.so.0 (0x7f6a3ca6a000)
         libxcb.so.1 = /usr/lib/libxcb.so.1 (0x7f6a3c84e000)
         libXau.so.6 = /usr/lib/libXau.so.6 (0x7f6a3c64c000)
         libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x7f6a3c446000)


 I think that libOSMesa.so have compiled in the same libgl code and then
 there are symbols colision.

 Can you make the libOSMesa package didn't link libGL static?
 Otherwise, can you explain myself how to build the package from Debian
 sources but linking GL libraries dynamically?
 There ara any other workarrounds to prevent this?

 Is libOSMesa supposed to conflict with libGL?

OSMesa standalone has all the GL entrypoints, so it conflicts in a
sense. On prior releases of Mesa an optimization was made that OSMesa
was linked to GL to save space on the internal libraries when
--with-driver!=osmesa. Later hidden symbol visibility was used and
OSMesa started having resolution problems when it tried to use
internal mesa functions. So, we changed always making OSMesa
standalone.

It looks like debian has built the standalone OSMesa. If you grab
mesa-7.8.2, this is also how you'll get OSMesa regardless of the other
options you throw at configure.

 Josep, do you really need to link with -lGL in addition to -lOSMesa?

I would suggest not linking an app to both -lGL and -lOSMesa. If
you're going to use OSMesa, it either has the GL symbols already or
will pull in GL. I.e., just link against `pkg-config --libs osmesa` or
`pkg-config --libs --static osmesa` if necessary.

--
Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org