Bug#767999: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd
[ BCC'ing Santiago, Holger, Adam, Cyril ]
Hi all,
I'm refraining from quoting the preceding mails as most of you will have those
in their inbox, and I'd rather summarise the situation right here:
At least Santiago's and my opinion diverge on whether base-passwd is presently
in line with policy on 3.8 Essential packages. Therefore the route from here
appears to hinge on interpreting policy in one of two ways: my point is that
base-passwd, at present, is not providing its functionality after just being
unpacked - it does require postinst having been run. Santiago claims, if I
interpret this correctly, that every package has to be configured at least once
before being useful at all (irrespective of whether it is essential or not).
The steps from here are such:
1. Determine whether base-passwd is in line with policy on providing its
functionality as an essential package.
A) If it is, then debootstrap is buggy.
B) If base-passwd violates policy, then base-passwd is buggy.
2. If debootstrap is buggy, then the most effective way of updating as many
debootstrap installations as possible must be found.
3. If base-passwd violates policy, policy could be amended to acknowledge
base-passwd's special case. Then again we are in situation 2.
4. If base-passwd violates policy and policy would not be amended, then
base-passwd will need to be changed. Again, as you aren't base-passwd's
maintainer, you are not to be tasked with this.
My point of view is that base-passwd should be changed, and thanks to
suggestions from Tollef last night the attached patch should actually achieve
this. The idea simply is to sort out creating /etc/passwd and /etc/group in
preinst already, so that these files will be present once the package reaches
the state unpacked.
Using a version of base-passwd modified in this way makes wheezy's debootstrap
work for me.
I am thus CC'ing Colin as base-passwd's maintainer to gather his input - I'm not
really up for any bug-reassigning game, so I'd rather not do this myself without
consent by any of the involved package maintainers (I'm just a debootstrap
user...).
Best,
Michael
diff -Nru base-passwd-3.5.36/debian/other base-passwd-3.5.36/debian/other
--- base-passwd-3.5.36/debian/other 1970-01-01 01:00:00.0 +0100
+++ base-passwd-3.5.36/debian/other 2014-11-06 11:18:54.0 +
@@ -0,0 +1,10 @@
+
+override_dh_clean:
+ dh_auto_clean
+ $(RM) debian/preinst
+
+override_dh_auto_configure:
+ cp debian/preinst.in debian/preinst
+ sed -e '/@PASSWD@/ {' -e 'r passwd.master' -e 'd' -e '}' -i
debian/preinst
+ sed -e '/@GROUP@/ {' -e 'r group.master' -e 'd' -e '}' -i debian/preinst
+
diff -Nru base-passwd-3.5.36/debian/preinst.in
base-passwd-3.5.36/debian/preinst.in
--- base-passwd-3.5.36/debian/preinst.in1970-01-01 01:00:00.0
+0100
+++ base-passwd-3.5.36/debian/preinst.in2014-11-06 10:47:29.0
+
@@ -0,0 +1,23 @@
+#! /bin/sh
+
+set -e
+
+if [ ! $1 = install ] ; then
+exit 0
+fi
+
+if [ ! -e /etc/passwd ] ; then
+ cat /etc/passwd EOF
+@PASSWD@
+EOF
+fi
+
+if [ ! -e /etc/group ] ; then
+ cat /etc/group EOF
+@GROUP@
+EOF
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru base-passwd-3.5.36/debian/rules base-passwd-3.5.36/debian/rules
--- base-passwd-3.5.36/debian/rules 2014-08-31 18:04:51.0 +0100
+++ base-passwd-3.5.36/debian/rules 2014-11-06 11:25:54.0 +
@@ -5,6 +5,16 @@
export DEB_BUILD_MAINT_OPTIONS := hardening=+all
export DEB_CFLAGS_MAINT_APPEND := -Wall
+override_dh_auto_clean:
+ dh_auto_clean
+ $(RM) debian/preinst
+
+override_dh_auto_install:
+ cp debian/preinst.in debian/preinst
+ sed -e '/@PASSWD@/ {' -e 'r passwd.master' -e 'd' -e '}' -i
debian/preinst
+ sed -e '/@GROUP@/ {' -e 'r group.master' -e 'd' -e '}' -i debian/preinst
+ dh_auto_install
+
override_dh_installdebconf:
touch debian/base-passwd.substvars
mv debian/base-passwd.substvars debian/base-passwd.substvars.real
pgpx38I6SSozq.pgp
Description: PGP signature
Bug#767999: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd
Hi, On Thu, Nov 06, 2014 at 22:44:40 +0100, Adam Borowski wrote: On Thu, Nov 06, 2014 at 02:06:07PM +, Michael Tautschnig wrote: [...] 1. Determine whether base-passwd is in line with policy on providing its functionality as an essential package. A) If it is, then debootstrap is buggy. Even if it somehow is, there's a practical problem: it's impossible to deploy a fix to a significant part of users. Yes, I can see that. But determining the package at fault would nevertheless help to see what the best fix is in the long run. B) If base-passwd violates policy, then base-passwd is buggy. I say it is, but since the only consumer that matters is base-files, it might be safer to change the latter. Well, as Santiago has said in many ways, the necessary changes to base-files could be painful as well. I'd rather see it the other way: if base-passwd were changed, it might as well be possible to simplify debootstrap further as it could be the case that the present dpkg -i call specific to base-files and base-passwd would no longer be necessary, i.e., they could just be installed in arbitrary sequence with the other essential packages. My point of view is that base-passwd should be changed, and thanks to suggestions from Tollef last night the attached patch should actually achieve this. The idea simply is to sort out creating /etc/passwd and /etc/group in preinst already, so that these files will be present once the package reaches the state unpacked. I tested your patch when debootstrapping from squeeze, it did work. Should I test some more scenarios (cdebootstrap? 2-phase cross-arch debootstrap? some other distro?) -- or do you think it should be safe? Cool, thanks!! If testing is trivial for you then I'm sure this would be appreciated (in particular the it did not work before, but not it works improvement). While I wouldn't really expect any new problems, I don't know enough about, e.g., cdebootstrap so maybe something could go wrong over there? Best, Michael pgps39u023zjj.pgp Description: PGP signature
Bug#766459: debootstrap: should not try to configure
Hi Santiago, All, On Tue, Oct 28, 2014 at 13:39:06 +0100, Santiago Vila wrote: [...] I already tried to fix this problem yesterday in base-files by making minor changes. It didn't work. And it didn't work because contrary to what some people in this thread has suggested, this issue has *absolutely* nothing to do with recent changes in base-files. Most probably, this is what happened: debootstrap in wheezy installs base-passwd and base-files in the same dpkg run. The order in which base-files and base-passwd are configured is not defined in policy so it may depend on the dpkg version, which is almost like saying that it could be random. At this moment dpkg in jessie and sid are quite different, so most likely: dpkg in jessie happen to configure base-passwd first, and it works. dpkg in sid happen to configure base-files first, and it fails. So I could be wrong, but this (recent changes in dpkg) is most likely the real reason this didn't bite us before. Yes, and I'm trying to confirm this right now. The diff between set-of-working packages vs. set-of-failing packages is 5c5 base-files_7.8_amd64.deb --- base-files_7.7_amd64.deb 21c21 dpkg_1.17.20_amd64.deb --- dpkg_1.17.19_amd64.deb 56c56 libc6_2.19-12_amd64.deb --- libc6_2.19-11_amd64.deb 59c59 libc-bin_2.19-12_amd64.deb --- libc-bin_2.19-11_amd64.deb 61c61 libcryptsetup4_2%3a1.6.6-3_amd64.deb --- libcryptsetup4_2%3a1.6.6-2_amd64.deb 132c132 multiarch-support_2.19-12_amd64.deb --- multiarch-support_2.19-11_amd64.deb 159c159 tzdata_2014i-1_all.deb --- tzdata_2014h-2_all.deb 162,163c162,163 vim-common_2%3a7.4.488-1_amd64.deb vim-tiny_2%3a7.4.488-1_amd64.deb --- vim-common_2%3a7.4.481-1_amd64.deb vim-tiny_2%3a7.4.481-1_amd64.deb but likely it all boils down to the changes in dpkg. So please next time a simple chown root:root fails, let us not kill the messenger, ok? It has been quite disappointing to me to see so many fingers wrongly pointing at base-files, when base-files was never to blame for this. As surely I was among the people pointing fingers I would like to apologise for not having identified the right change causing those problems. I'm not yet sure about the other absent dependency, but I'll do proper debugging before coming up with further ideas. Best, Michael pgpmjxKfzOisk.pgp Description: PGP signature
Bug#766459: debootstrap: should not try to configure
Hi all, I'm being heavily bitten by this one as well and I'm mildly shocked to see it crop up this late in the release cycle. I'm not going to hide that I believe this ought to be reassigned to base-files. I'll try to elaborate below. Santiago Vila wrote: [...] In this particular case, I believe the reason for the failure (that didn't happen before) is some change in base-passwd, not something that base-files does differently now. I tend to disagree: base-passwd hasn't been touched since 2014-09-04, whereas debootstrap only started to fail last week, when base-files 7.7 was uploaded. It's this change I believe: http://sources.debian.net/src/base-files/7.7/debian/postinst.in/?hl=132,133,134#L132 Causing chown: invalid user: 'root:root' Admittedly, though, this just exposes a problem that had been lingering for a while as the calls to chown using root:root could have been invoked from several bits of the postinst script. In principle, every essential package may depend on any other, and the set of real dependencies may change over time, so it's natural that debootstrap needs minor adjustments from time to time. So would you expect some sort of versioned dependencies in debootstrap? As the upload of base-files 7.7 showed, it is changes in packages that suddenly require new hacks. And a key problem is that tools like debootstrap ought to work from within, e.g., stable release to bootstrap future releases like testing or unstable. Suggesting that a bootstrapping tool is changed due to updates in another package is going to cause a major dependency loop as at least testing efforts such as those of jenkins.d.n will be broken. In fact it would be easier to codify this in dpkg than in debootstrap, I believe, as dpkg would live in the same suite as the package to be installed. But this sounds like very bad design indeed. You will find a more complete explanation of this in the logs for Bug#760568 where I'm asked no less than to depend on base-passwd, which is essential! IMHO, this is definitely not the way to go. Using the essential! hammer doesn't sound like a great argument when your package is essential. It's past time to be untangling the Essential hairball. Correct dependency metadata is much more scalable than hacks in debootstrap. I agree that you may have a point here. In fact, in the aforementioned bug #760568 against cdebootstrap, which is very similar to this one, I suggested the idea that if the knowledge about right package ordering among essential packages were codified and written somewhere, other similar tools could use the same information without having to reinvent the wheel. I see now that the control file could be such common place to have that information, but I would like to see a little bit of *design* before doing anything which is not in policy yet. For example, we could use: * The same Depends field we are using for normal dependencies. * A new field for this particular purpose which dpkg and friends ignore under normal circumstances, and an environment variable which debootstrap may set to tell dpkg and friends that they should actually honor them instead of ignoring them. * An extension of the Depends field, much like !stage1 is used in Build-Depends for build profiles. So yes, we could consider to codify this metadata (the fact that base-files postinst uses chown and expect the root user to exist, for example) in *some* way... Stop being part of the problem, and add the dependency already.. ... but please let us think about it first. Starting to add Depends field here and there in a random fashion just because it makes debootstrap not to fail anymore is not something I will be happy with. I do fully agree that care must be taken, as dependency loops would obviously be a major problem. The Depends field is implicit among the set of essential packages. I'm not too sure about the among bit here? No doubt that this is implicit for any non-essential package, but among them I'm not sure whether any rules apply right now? If a tool like apt-get or dpkg really behaves in a different way when I add a Depends field which was already implicit, I think that there is something fundamentally wrong here. Does dpkg really add the essential information into its dependency information? Wouldn't this rather be seen as ah, essential, so it must be there? At least briefly looking at dpkg's source code I cannot seem to see dpkg considering this implicit dependency at all (unless attempting to remove an essential package). So, to summarize: I'm not opposed to modify policy when it says that we don't need to include dependencies on essential packages, but if we decide to go that route, please let us do it according to some *plan*, not in a random fashion, because otherwise, IMHO, *that* would be the real hack. I do appreciate being careful, but then bug fixes for a bug of normal severity (#763405) shouldn't
Re: Bug#766459: debootstrap: should not try to configure
I'm hoping this is not going to be too philosophical, so I'll enlist the facts first (please let me know if I got any of them wrong): debootstrap'ing a system fails, because - chown root:root ... won't work when invoked from base-files' postinst - version 7.7 of base-files is the first to actually have this call when invoked from within (c)debootstrap - using root:root relies on /etc/passwd and /etc/group being in place and populated - /etc/passwd and /etc/group are provided by base-passwd, which is essential On Mon, Oct 27, 2014 at 11:08:55 +0100, Santiago Vila wrote: I'm going to reply to Julien first, then to Michael. On Mon, 27 Oct 2014, Julien Cristau wrote: On Mon, Oct 27, 2014 at 08:35:14 +, Michael Tautschnig wrote: I agree this should be fixed in base-files. Bugs should be fixed where they are. If base-files, or any other package, essential or not, can't make a simple chown root:root, then it is a bug in whatever package was responsible for making sure that the root user exist in a Debian system, base-passwd and debootstrap in this case. [...] This has worked for ages, and it should continue to work, because base-passwd is essential. So let's see what Debian Policy says in 3.8 Essential packages: [...] Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate. [...] While base-passwd is essential, the question seems to be whether providing /etc/passwd and /etc/group are its core functionality. The description of base-passwd states: These are the canonical master copies of the user database files (/etc/passwd and /etc/group), containing the Debian-allocated user and group IDs. The package base-passwd, however, will only copy those files into place in its postinst script. It may thus be argued (if provision of the files is considered core functionality) that base-passwd violates policy. Yet it may be impossible for base-passwd to implement this bit of policy unless unconditionally overwriting /etc/passwd and /etc/group were deemed acceptable (which it surely isn't, unless we implement something like /etc/passwd.d/ and /etc/group.d/). A collection of possible ways forward - feel free to add more: - base-passwd should no longer be marked essential, but instead base-files should depend on it (making base-passwd implicitly essential), hence neither would base-passwd be violating policy nor would we any longer face the problems in base-files/(c)debootstrap. But maybe other issues arise, which I might not be aware of. - base-files should explicitly depend on base-passwd, because it uses functionality that is not considered core functionality of base-passwd. - We ignore the policy violation of base-passwd or consider the use of /etc/passwd in base-files use of non-core functionality and hence ignore the bug in base-files. Either ignorance will then require working around those bugs in (c)debootstrap. Best, Michael pgp8tHayOOAmV.pgp Description: PGP signature
Re: Bug#766459: debootstrap: should not try to configure
Apologies if I may be repeating information as we were concurrently working on those messages. On Mon, Oct 27, 2014 at 11:34:06 +0100, Santiago Vila wrote: [...] I just expect debootstrap maintainers to cooperate with the release managers to ensure that the version in stable is able to debootstrap the testing distribution, whenever it is possible to do so. This should, however, ideally work both ways: any package modification expected to break debootstrap would have to be communicated. But arguably this will not necessarily be obvious, as can be seen here. I've heard that the version in wheezy-backports does not have this problem. Maybe it could be just a matter of making an upload for the next point release. I don't know. That's because of the following workaround, which is being disputed: debootstrap (1.0.56) unstable; urgency=low . [ Tollef Fog Heen ] * Install base-passwd and base-files in two calls rather than one to avoid problems with home-built media with different ordering in Packages. Thanks to Jo Shields for pointing this out and providing the workaround. Closes: #601670. LP: #1001131. Though see my earlier mail: if debootstrap ends up being the package to finally close this bug, then, yes, this might be the route to go. [...] If a tool like apt-get or dpkg really behaves in a different way when I add a Depends field which was already implicit, I think that there is something fundamentally wrong here. Does dpkg really add the essential information into its dependency information? Wouldn't this rather be seen as ah, essential, so it must be there? At least briefly looking at dpkg's source code I cannot seem to see dpkg considering this implicit dependency at all (unless attempting to remove an essential package). In the general case we don't have to worry about that because once that essential packages are properly installed and configured, they will continue to work all the time unless apt-get does some really weird things. Yes and no: mind that that essential only provides guarantees for functionality being available as soon as the package is unpacked. The configured bit is irrelevant for features deemed essential. But how are we expected to have all the essential packages properly installed and configured? Should base-files worry about base-passwd being properly installed and configured before making a chown? Certainly not, this is the work of debootstrap! No. As you are using the base-passwd is essential argument, base-files can only rely on functionality provided by base-passwd when that is unpacked. The order of packages being configured is not covered by essential and neither should it be debootstrap's job to sort this out (but debootstrap 1.0.56 does do this). [...] In either case, I'm going to re-examine carefully what I did in base-files 7.7 and see if there is a simple workaround that may be done to avoid this problem. Much appreciated, but obviously we should, as you suggested, see what the right way of fixing this is. Best, Michael pgpDPcf798kxO.pgp Description: PGP signature
Re: Bug#766459: debootstrap: should not try to configure
On Mon, Oct 27, 2014 at 12:07:24 +0100, Santiago Vila wrote: On Mon, 27 Oct 2014, Michael Tautschnig wrote: I'm hoping this is not going to be too philosophical, so I'll enlist the facts first (please let me know if I got any of them wrong): debootstrap'ing a system fails, because - chown root:root ... won't work when invoked from base-files' postinst - version 7.7 of base-files is the first to actually have this call when invoked from within (c)debootstrap Regarding previous point, it should be noted that base-files postinst has a lot of chown calls. I would like to know how it is possible that only the recently added is the one that fails and not the others (if that's really the case). I suppose none of the others are being executed as all of them are guarded by some combination of checks? BTW: I don't know what is the proper way to debug this (private repository using reprepro?). Can anybody confirm that the chown that fails is exactly the one at the very end? Indeed it could be a very different one. I'm attaching a full log with the postinst script having set -evx. It might be obvious, but this is being run on a wheezy system. So let's see what Debian Policy says in 3.8 Essential packages: [...] Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate. [...] This is about dpkg when making upgrades. It means that once an essential package is properly configured, it should not stop working because of it being unconfigured by dpkg (whatever that means). I think it does not apply here. Then maybe take the first sentence in 3.8 Essential packages instead: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the Unpacked state. If not this one (and not the one above), which bit of policy are you then relying on when you do the chown calls? [ snipped philosophical stuff. I would much prefer to have free time to work on this rather than discuss about it. Really ]. As you please. I was just hoping to find potential options other than revert the change in base-files. Best, Michael root@mt-farm05:~# mkdir /srv/sid-base.cow root@mt-farm05:~# pbuilder create --aptcache /srv/jenkins-slave/aptcache --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --buildplace /srv/sid-base.cow --mirror ftp://ftp.uk.debian.org/debian --distribution sid --no-targz --extrapackages cowdancer I: Running in no-targz mode I: Distribution is sid. I: Current time: Mon Oct 27 11:44:42 GMT 2014 I: pbuilder-time-stamp: 1414410282 I: Building the build environment I: running debootstrap /usr/sbin/debootstrap I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: acl adduser dmsetup init-system-helpers insserv libaudit-common libaudit1 libbz2-1.0 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdebconfclient0 libdevmapper1.02.1 libgcrypt20 libgdbm3 libgpg-error0 libkmod2 libncursesw5 libprocps3 libsemanage-common libsemanage1 libslang2 libsystemd0 libudev1 libustr-1.0-1 perl perl-modules procps systemd systemd-sysv udev I: Found additional base dependencies: binutils bzip2 cpp cpp-4.9 debian-archive-keyring dpkg-dev g++ g++-4.9 gcc gcc-4.9 gnupg gpgv libapt-pkg4.12 libasan1 libatomic1 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4 libdpkg-perl libgcc-4.9-dev libgmp10 libgomp1 libisl10 libitm1 liblsan0 libmpc3 libmpfr4 libquadmath0 libreadline6 libstdc++-4.9-dev libstdc++6 libtimedate-perl libtsan0 libubsan0 libusb-0.1-4 linux-libc-dev make patch readline-common xz-utils I: Checking component main on ftp://ftp.uk.debian.org/debian... I: Retrieving acl I: Validating acl I: Retrieving libacl1 I: Validating libacl1 I: Retrieving adduser I: Validating adduser I: Retrieving apt I: Validating apt I: Retrieving libapt-pkg4.12 I: Validating libapt-pkg4.12 I: Retrieving libattr1 I: Validating libattr1 I: Retrieving libaudit-common I: Validating libaudit-common I: Retrieving libaudit1 I: Validating libaudit1 I: Retrieving base-files I: Validating base-files I: Retrieving base-passwd I: Validating base-passwd I: Retrieving bash I: Validating bash I: Retrieving binutils I: Validating binutils I: Retrieving build-essential I: Validating build-essential I: Retrieving bzip2 I: Validating bzip2 I: Retrieving libbz2-1.0 I: Validating
Re: Bug#766459: debootstrap: should not try to configure
On Mon, Oct 27, 2014 at 16:36:42 +0100, Santiago Vila wrote: [...] For example, your interpretation would force base-passwd to lose its essential flag, because it can't provide its core functionality only when in unpacked state. Then, according to policy, base-files and *every* other package using any of the system users in any of its maintainer scripts would have to add a Depends: base-passwd, since they depend on functionality which is only available after base-passwd has been configured. Yes, indeed this is what I'd infer from policy. But I could easily be wrong. Frankly, I don't think that's what we want. I would say that at least we do not want this at this point in the release cycle as it appears be bear way too many risks. Admittedly, all that *I* want is a working debootstrap, so I'm also ok just having the changes in base-files for now (or maybe also in debootstrap). Best, Michael pgp4bTvfbnFKY.pgp Description: PGP signature
Bug#749995: debian-installer-netboot-images: FTBFS - debian-installer not found in wheezy-proposed-updates
Package: debian-installer-netboot-images Version: 20130613+deb7u2.b1 Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. [...] sha256sum: debian-installer_20130613+deb7u2+b1_amd64.deb.sha256sum: no properly formatted SHA256 checksum lines found debian/rules:18: recipe for target 'get-images-amd64' failed The reason lies here: - The code fetches http://mirror.lchost.net/debian/dists/wheezy-proposed-updates/main/binary-amd64/Packages.gz - Checks, unpacks, eventually ends up as amd64.Packages - `grep-dctrl -P debian-installer -X -s Sha256 amd64.Packages` returns nothing So debian-installer simply doesn't exist in wheezy-proposed-updates. I'm leaving the severity of this bug report untouched as this may all be well known? Best, Michael pgpjU28btnKUL.pgp Description: PGP signature
Bug#749228: kbd-chooser: Conflicting return types of loadkeys_wrapper
Package: kbd-chooser Version: 1.67 Severity: wishlist Usertags: goto-cc During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder) the build failed with the following error. Please note that we use our research compiler tool-chain (using tools from the cbmc package), which permits extended reporting on type inconsistencies at link time. [...] cc -Wall -I. -DNDEBUG=1 -fomit-frame-pointer -Os -DAT_KBD -DUSB_KBD kbd-chooser.c -o kbd-chooser loadkeys.o findfile.o ksyms.o getfd.o at-kbd.o usb-kbd.o -ldebconfclient -ldebian-installer error: conflicting function declarations loadkeys_wrapper old definition in module kbd-chooser file kbd-chooser.c line 27 signed int (char *) new definition in module loadkeys file loadkeys.y line 257 void (char *map) Makefile:95: recipe for target 'kbd-chooser' failed make[1]: *** [kbd-chooser] Error 64 make[1]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-kbd-chooser/kbd-chooser-1.67' dh_auto_build: make -j1 returned exit code 2 debian/rules:3: recipe for target 'build' failed make: *** [build] Error 2 As the actual implementation does not return a value, and neither does the call site pick up a return value, this seems to be just a mistake here: http://sources.debian.net/src/kbd-chooser/1.67/kbd-chooser.c?hl=27#L27 Yet it is worth fixing to avoid any future (invalid) use of the presumed return value. Best, Michael pgppN_AU8b5z2.pgp Description: PGP signature
