Bug#1082846: ITS: xzip
On Fri, Sep 27, 2024 at 5:24 AM Andreas Tille wrote: > I'm interested in salvaging your package xzip, in accordance with the > Package Salvaging procedure outlined in the Developers Reference[1]. > Your package meets the criteria for this process, and I would love to > assist in preserving and maintaining it. As the Salvage process > suggests, here is a list of the criteria that apply, in my opinion: > > - Bugs filed against the package do not have answers from the > maintainer. > - There are QA issues with the package. > > I believe your package would be a great addition to the Debian Games > team, and I'm planning to create the Salsa repository here[2]. If you > choose not to accept the ITS, I'd be more than happy to help you move it > to another location, such as debian/, or wherever you prefer. My goal is > to make it as easy as possible for you to join the team. I'd also be > delighted to assist in adding you as a team member if you could share > your Salsa login. > > Your package was highlighted in the Bug of the Day[3] initiative, which > aims to introduce newcomers to manageable tasks and guide them through > the workflow to solve them. The focus of this initiative is on migrating > packages to Salsa, as it's a great way to familiarize newcomers with a > consistent Git-based workflow. That would be fine with me. In fact, I haven't had much time over the past few years to work on Debian, so I would probably resign if not for the fact that my Debian developer GPG key has already been removed from the keyring for being old format, and I haven't been able to meet with anyone to get a new key signed. -- Daniel Schepler
Bug#1011474: libhrash0: Cannot load libcrypto.so.3
Package: libhrash0 Version: 1.4.2-1 Severity: normal I notice that even if I recompile rhash against the latest libssl-dev, the Recommends is still on libssl1.1. And it appears that this is because the source code does a dlopen trying a hard-coded list of library names, and libcrypto.so.3 is not in that list. I also notice that libcrypto.so is at the front of the list, which means that the behavior might be different if libssl-dev version 3.* is installed, versus if it's not installed but it happens that the obsolete package libssl1.1 is installed. Normally, I would recommend that code not do a dlopen on a development .so link and instead it should dlopen based on the library's SONAME. (So, I would suggest removing the "libcrypto.so" entry from the head of the libNames list.) -- Daniel Schepler
Bug#1010739: haskell-distributive: FTBFS: doctests: : cannot satisfy -package distributive-0.6.2
Source: haskell-distributive Version: 0.6.2-1 Severity: serious >From my sbuild build log (on amd64, and haskell-devscripts version was >0.16.14): ... Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct Non-zero exit code 1. Running 2 test suites... Test suite doctests: RUNNING... -i -i/<>/dist-ghc/build/autogen -i/<>/dist-ghc/build -i/<>/src -package-env=- -hide-all-packages -no-user-package-db -package-db=/var/lib/ghc/package.conf.d -package-db=dist-ghc/package.conf.inplace -optP-include -optPdist-ghc/build/autogen/cabal_macros.h -package-id=base-4.13.0.0 -package-id=base-orphans-0.8.2-1Y1ZqNmIsRFEurBzE3x0AA -package-id=tagged-0.8.6-FYc8l1vwILF5OSKkSTSNII -package-id=transformers-0.5.6.2 -package=distributive-0.6.2 -package-id=doctest-0.16.3-5Rdunu33bocFtnt3QIeq3L Data.Distributive Data.Distributive.Generic Test suite doctests: FAIL Test suite logged to: dist-ghc/test/distributive-0.6.2-doctests.log Test suite spec: RUNNING... Generics Id distribute idExample = idExample Stream runId (shead (stail (distribute streamExample))) = 1 PolyRec runId (plast (runId (pinit (distribute polyRecExample = 1 Finished in 0.0240 seconds 3 examples, 0 failures Test suite spec: PASS Test suite logged to: dist-ghc/test/distributive-0.6.2-spec.log 1 of 2 test suites (1 of 2 test cases) passed. doctests: : cannot satisfy -package distributive-0.6.2 (use -v for more information) at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 106. Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup", "test", "--builddir=dist-ghc", "--show-details=direct") called at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 130 Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", "test", "--builddir=dist-ghc", "--show-details=direct") called at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 685 Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called at -e line 1 make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 -- Daniel Schepler
Bug#1010703: haskell-hashable: FTBFS on i386: unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'
Source: haskell-hashable Version: 1.3.0.0-2 Severity: serious >From my build log (in an i386 container, and haskell-devscripts version was 0.16.14): ... debian/rules binary-arch test -x debian/rules dh_testroot dh_prep dh_installdirs -A mkdir -p "." CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85 CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85 Adding cdbs dependencies to debian/libghc-hashable-dev.substvars dh_installdirs -plibghc-hashable-dev \ perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \ -E 'make_setup_recipe' Running ghc --make Setup.hs -o debian/hlibrary.setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking debian/hlibrary.setup ... perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \ -E 'configure_recipe; build_recipe; haddock_recipe; check_recipe' Running find . ! -newer /tmp/V8FdEAcJVW -exec touch -d "1998-01-01 UTC" {} ; Running dh_listpackages libghc-hashable-dev libghc-hashable-prof libghc-hashable-doc Running dh_listpackages libghc-hashable-dev libghc-hashable-prof libghc-hashable-doc Running dpkg-buildflags --get LDFLAGS -Wl,-z,relro Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl,-z,relro --haddockdir=/u sr/lib/ghc-doc/haddock/hashable-1.3.0.0/ --datasubdir=hashable --htmldir=/usr/share/doc/libghc-hashable-doc/html/ --enable-library-profiling --hsc2hs-options=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 --gcc-options=-D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 --ghc-options=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -optc -D_LARGEFILE_SOURCE -optc -D_FILE_OFFSET_BITS=64 Non-zero exit code 1. unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64' unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64' unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64' unrecognized 'configure' option `-optc' unrecognized 'configure' option `-D_LARGEFILE_SOURCE' unrecognized 'configure' option `-optc' unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64' at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 106. Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup", "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", "--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", "--libe xecdir=/usr/lib", ...) called at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 130 Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", "--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", "--libexecdir =/usr/lib", ...) called at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 629 Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() called at -e line 1 make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 -- Daniel Schepler
Bug#1010289: audit: FTBFS: error: cast specifies array type
Source: audit Version: 1:3.0.7-1 Severity: serious >From my build log: ... Making all in python3 make[6]: Entering directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7/debian/build/bindings/swig/python3' swig -o audit_wrap.c -python -py3 -modern -I. -I../../.. -I../../../../../lib -I/usr/include/python3.10 -I/usr/include/python3.10 ../../../../../bindings/swig/python3/../src/auditswig.i Deprecated command line option: -modern. This option is now always on. /bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../../bindings/swig/python3 -I../../.. -I. -I../../.. -I../../../../../lib -I/usr/include/python3.10 -I/usr/include/python3.10 -Wdate-time -D_FORT IFY_SOURCE=2 -shared -g -O2 -ffile-prefix-map=/home/tmpbuilder/cross-i386/audit/audit-3.0.7=. -fstack-protector-strong -Wformat -Werror=format-security -c -o _audit_la-audit_wrap.lo `test -f 'audit_wrap.c' || echo '../../../../../bindin gs/swig/python3/'`audit_wrap.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../../bindings/swig/python3 -I../../.. -I. -I../../.. -I../../../../../lib -I/usr/include/python3.10 -I/usr/include/python3.10 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-ma p=/home/tmpbuilder/cross-i386/audit/audit-3.0.7=. -fstack-protector-strong -Wformat -Werror=format-security -c audit_wrap.c -fPIC -DPIC -o .libs/_audit_la-audit_wrap.o audit_wrap.c: In function '_wrap_audit_rule_data_buf_set': audit_wrap.c:4701:17: error: cast specifies array type 4701 | arg1->buf = (char [])(char *)memcpy(malloc((size)*sizeof(char)), (const char *)(arg2), sizeof(char)*(size)); | ^ audit_wrap.c:4701:15: error: invalid use of flexible array member 4701 | arg1->buf = (char [])(char *)memcpy(malloc((size)*sizeof(char)), (const char *)(arg2), sizeof(char)*(size)); | ^ audit_wrap.c:4703:15: error: invalid use of flexible array member 4703 | arg1->buf = 0; | ^ make[6]: *** [Makefile:518: _audit_la-audit_wrap.lo] Error 1 make[6]: Leaving directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7/debian/build/bindings/swig/python3' make[5]: *** [Makefile:417: all-recursive] Error 1 make[5]: Leaving directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7/debian/build/bindings/swig' make[4]: *** [Makefile:414: all-recursive] Error 1 make[4]: Leaving directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7/debian/build/bindings' make[3]: *** [Makefile:471: all-recursive] Error 1 make[3]: Leaving directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7/debian/build' make[2]: *** [Makefile:403: all] Error 2 make[2]: Leaving directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7/debian/build' dh_auto_build: error: cd debian/build && make -j8 returned exit code 2 make[1]: *** [debian/rules:64: debian/build-python-stamp] Error 2 make[1]: Leaving directory '/home/tmpbuilder/cross-i386/audit/audit-3.0.7' make: *** [debian/rules:34: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Looking at the situation a bit, it seems that a recent update to /usr/include/linux/audit.h made a change such that struct audit_rule_data is no longer swig friendly. -- Daniel Schepler
Bug#1010287: libnet-ssleay-perl: FTBFS: bad line in substvars file debian/libnet-ssleay-perl.substvars at line 2
Source: libnet-ssleay-perl Version: 1.92-1 Severity: serious >From my build log: ... dh_installdocs -a dh_installchangelogs -a dh_installexamples -a dh_installman -a dh_perl -a dh_perl_openssl -a dh_link -a dh_strip_nondeterminism -a dh_compress -a dh_fixperms -a dh_missing -a dh_dwz -a dh_strip -a dh_makeshlibs -a dh_shlibdeps -a dpkg-shlibdeps: error: bad line in substvars file debian/libnet-ssleay-perl.substvars at line 2 dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/libnet-ssleay-perl.substvars debian/libnet-ssleay-perl/usr/lib/x86_64-linux-gnu/perl5/5.34/auto/Net/SSLeay/SSLeay.so returned exit code 255 dh_shlibdeps: error: Aborting due to earlier error make: *** [debian/rules:6: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 Looking at the file it's complaining about, debian/libnet-ssleay-perl.substvars contains: perl:Depends=perl, perl-openssl-abi-1.1 , perlapi-5.34.0 (My best guess would be that this is a bug in perl-openssl-defaults / dh_perl_openssl, but it's just a guess...) -- Daniel Schepler
Bug#1010121: libx11: FTCBFS: cannot run test program while cross compiling
Source: libx11 Version: 2:1.7.5-1 Severity: wishlist While doing a test bootstrap of i386 from amd64, I ran into an error trying to cross build libx11: ... checking for xproto >= 7.0.25 xextproto xtrans xcb >= 1.11.1 kbproto inputproto... yes checking whether malloc(0) returns NULL... configure: error: in `/home/tmpbuilder/cross-i386/libx11/libx11-1.7.5/build': configure: error: cannot run test program while cross compiling See `config.log' for more details ... (This came up as a Build-Depends of groff, while trying to cross-compile enough packages to make debhelper installable.) -- Daniel Schepler
Bug#949843: sbuild: add systemd-nspawn chroot mode
On Mon, Apr 4, 2022 at 3:03 PM Luca Boccassi wrote: > > On Sat, 25 Jan 2020 11:36:09 -0800 Daniel Schepler > wrote: > > Package: sbuild > > Version: 0.78.1-2 > > Severity: wishlist > > > > Here's my initial version of the cleaned up patch for adding a > > --chroot-mode=systemd-nspawn. Some things I'm not sure about: > > - Should we maybe ping upstream and/or Debian maintainers on > > https://github.com/systemd/systemd/issues/13297 to see how hard it > > would be to get it fixed so I could remove that whole ugly > workaround? > > (The workaround also only handles bind mount settings at present - > > and for example, I've found that a lot of package builds will require > > SystemCallFilter=@memlock due to a lot of crypto libraries and > > utilities giving errors if they're denied access to mlock. So I > would > > probably want to add that to my > > /etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.) > > As mentioned on https://github.com/systemd/systemd/issues/13297 adding > --ephemeral means the machine name has a randomized suffix. Passing -- > machine=$chroot should ensure the config files are picked up as > expected. OK, if I did that, then would that mean that it's no longer possible to have two sbuild processes using the same base chroot at the same time? (Not that that would be too much of an issue in practice. Though I do admit it's convenient to be able to have my micro_buildd script running one sbuild instance, while on another terminal I can run a manual build with e.g. DEB_BUILD_OPTIONS=nocheck sbuild ... --profiles=nocheck tobootstrap_1.0 .) > > - It currently requires giving sudo access for systemd-run, which > > essentially would open up execution of anything desired. And the > fact > > that it requires NOPASSWD (because some of the commands redirect > > stdin/stdout) makes things even worse. And even if you restrict it > to > > e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it would > > be possible to fool that with something like "sudo systemd-run -M > > unstable-amd64-sbuild -M .host ~/myevilcmd". > > This seems to be used to implement manual synchronization, but this is > not necessary as it's already implemented, see: > > https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready= That's just one use of systemd-run, and a minor one at that. The main use is to run the commands that sbuild needs to invoke, from "apt-get update", "apt-get dist-upgrade", "apt-get source package=ver", "dpkg-source -x filename.dsc", "dpkg-buildpackage" (with --property=PrivateNetwork=yes on this one), "cat *.changes" into a pipe, etc. And as for synchronization, I think I do remember seeing the --notify-ready option. But the man page said the notification would be going to systemd, and I didn't immediately see any way for the sbuild parent process to get that notification or to wait for it. -- Daniel Schepler
Bug#1006790: python-unicodedata2: FTBFS without network access
Source: python-unicodedata2 Version: 14.0.0+ds-7 Severity: serious See https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-unicodedata2.html : (I also see the same error in my custom build environment based on sbuild, but using a systemd-nspawn container with network access disabled.) ... bunzip2 -ckd /usr/share/unicode/Unihan_NumericValues.txt.bz2 > data/Unihan_NumericValues.txt python3 makeunicodedata.py --- Reading UnicodeData.txt ... Traceback (most recent call last): File "/usr/lib/python3.9/urllib/request.py", line 1346, in do_open h.request(req.get_method(), req.selector, req.data, headers, File "/usr/lib/python3.9/http/client.py", line 1285, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib/python3.9/http/client.py", line 1331, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib/python3.9/http/client.py", line 1280, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib/python3.9/http/client.py", line 1040, in _send_output self.send(msg) File "/usr/lib/python3.9/http/client.py", line 980, in send self.connect() File "/usr/lib/python3.9/http/client.py", line 946, in connect self.sock = self._create_connection( File "/usr/lib/python3.9/socket.py", line 823, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -3] Temporary failure in name resolution During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/build/1st/python-unicodedata2-14.0.0+ds/makeunicodedata.py", line 1356, in maketables(1) File "/build/1st/python-unicodedata2-14.0.0+ds/makeunicodedata.py", line 117, in maketables unicode = UnicodeData(UNIDATA_VERSION) File "/build/1st/python-unicodedata2-14.0.0+ds/makeunicodedata.py", line 1004, in __init__ for s in UcdFile(UNICODE_DATA, version): File "/build/1st/python-unicodedata2-14.0.0+ds/makeunicodedata.py", line 934, in records with open_data(self.template, self.version) as file: File "/build/1st/python-unicodedata2-14.0.0+ds/makeunicodedata.py", line 898, in open_data urllib.request.urlretrieve(url, filename=local) File "/usr/lib/python3.9/urllib/request.py", line 239, in urlretrieve with contextlib.closing(urlopen(url, data)) as fp: File "/usr/lib/python3.9/urllib/request.py", line 214, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python3.9/urllib/request.py", line 517, in open response = self._open(req, data) File "/usr/lib/python3.9/urllib/request.py", line 534, in _open result = self._call_chain(self.handle_open, protocol, protocol + File "/usr/lib/python3.9/urllib/request.py", line 494, in _call_chain result = func(*args) File "/usr/lib/python3.9/urllib/request.py", line 1375, in http_open return self.do_open(http.client.HTTPConnection, req) File "/usr/lib/python3.9/urllib/request.py", line 1349, in do_open raise URLError(err) urllib.error.URLError: make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1 make[1]: Leaving directory '/build/1st/python-unicodedata2-14.0.0+ds' make: *** [debian/rules:9: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
Bug#991729: With glibc 2.34, it seems more is broken
On Mon, Aug 2, 2021 at 10:45 PM Shachar Shemesh wrote: > Can you run fakeroot-ng with "-l" and attach the generated log file? Here's the log from the run where make fails. -- Daniel Schepler fakeroot-ng.log Description: Binary data
Bug#991729: With glibc 2.34, it seems more is broken
Since I did a test upgrade of a container (non-Debian) to glibc 2.34, it seems I no longer need anything as esoteric as python asyncio.subprocess to trigger a similar error: (lfs chroot) lfs:/tmp/make-test$ cat Makefile all: echo Nothing to do (lfs chroot) lfs:/tmp/make-test$ make echo Nothing to do Nothing to do (lfs chroot) lfs:/tmp/make-test$ echo $? 0 (lfs chroot) lfs:/tmp/make-test$ fakeroot-ng make echo Nothing to do Nothing to do make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs make: *** wait: No child processes. Stop. (lfs chroot) lfs:/tmp/make-test$ echo $? 2 As far as I recall, make was working fine under fakeroot-ng with glibc 2.33. -- Daniel Schepler
Bug#991729: fakeroot-ng: Breaks python asyncio.subprocess
Package: fakeroot-ng Version: 0.18-4.1 Severity: normal As a small reproduction case (on amd64, using kernel 5.10.0-8-amd64): daniel@frobnitz:/tmp$ cat asyncproc.py import asyncio async def task(): proc = await asyncio.create_subprocess_exec('sleep', '1') await proc.wait() if proc.returncode != 0: raise RuntimeError('subprocess failed') asyncio.run(task()) daniel@frobnitz:/tmp$ python3 asyncproc.py daniel@frobnitz:/tmp$ fakeroot-ng python3 asyncproc.py [1]+ Stopped fakeroot-ng python3 asyncproc.py daniel@frobnitz:/tmp$ Unknown child process pid 34258, will report returncode 255 Traceback (most recent call last): File "/tmp/asyncproc.py", line 9, in asyncio.run(task()) File "/usr/lib/python3.9/asyncio/runners.py", line 44, in run return loop.run_until_complete(main) File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete return future.result() File "/tmp/asyncproc.py", line 7, in task raise RuntimeError('subprocess failed') RuntimeError: subprocess failed [1]+ Exit 1 fakeroot-ng python3 asyncproc.py -- Daniel Schepler
Bug#958597: Build-Depends on dh-systemd is back
found 958597 1.7.6-1 thanks It looks like the 1.7.6-1 upload of src:pmacct unintentionally added the Build-Depends on dh-systemd back in. -- Daniel Schepler
Bug#981580: hplip: hp-scan gets segmentation fault
Package: hplip Version: 3.20.11+dfsg0-1 Severity: important Trying to run hp-scan (connecting to a Photosmart Plus) I get: daniel@frobnitz:~/Documents$ hp-scan HP Linux Imaging and Printing System (ver. 3.20.11) Scan Utility ver. 2.2 Copyright (c) 2001-18 HP Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. warning: No destinations specified. Adding 'file' destination by default. Using device hpaio:/net/Photosmart_Plus_B209a-m?ip=192.168.1.121 Opening connection to device... Resolution: 300dpi Mode: gray Compression: JPEG Scan area (mm): Top left (x,y): (0.00mm, 0.00mm) Bottom right (x,y): (215.84mm, 296.925995mm) Width: 215.84mm Height: 296.925995mm Destination(s): file Output file: warning: File destination enabled with no output file specified. Setting output format to PNG for greyscale mode. warning: Defaulting to '/home/daniel/Documents/hpscan012.png'. Warming up... Scanning... Closing device. Segmentation fault This is a regression: hp-scan was working just fine up until a few months ago, at least. -- Daniel Schepler
Bug#979833: libtiff4: Document that Debian build is GPL due to dependency on libjbig0 (?)
Package: libtiff5 Version: 4.2.0-1 Severity: wishlist I'm wondering whether it would make sense to document in /usr/share/doc/libtiff5/copyright that even though the tiff source package in general is under a BSD/MIT style license, the Debian build is necessarily GPL due to linking against the GPL library libjbig0. On the other hand, similar reasoning would suggest going through all the reverse dependencies of libtiff4 to see what other packages would need to put in similar disclaimers - I would suppose probably at least all Gtk and Qt based packages would be affected. But that would be a huge and invasive task; so I'm not sure whether this request makes sense or not. -- Daniel Schepler
Bug#977611: apt-cacher-ng: Daily cron job frequently hangs
Package: apt-cacher-ng Version: 3.5-3 Severity: important Running apt-cacher-ng to serve an sbuild container which gets used heavily, I frequently get a hang in the daily cron job. The process tree involved is: anacron -d -q -s └─sh -c run-parts --report /etc/cron.daily └─run-parts --report /etc/cron.daily └─apt-cacher-ng /etc/cron.daily/apt-cacher-ng └─acngtool maint -c /etc/apt-cacher-ng SocketPath=/var/run/apt-cacher-ng/socket This then prevents the system from reaching other /etc/cron.daily entries. -- Daniel Schepler
Bug#968250: cryptsetup: FTBFS with systemd installed
Source: cryptsetup Version: 2.3.3-1 Severity: normal >From my sbuild log: ... checking for systemd tmpfiles config directory... /usr/lib/tmpfiles.d ... dh_missing -a dh_missing: warning: usr/lib/tmpfiles.d/cryptsetup.conf exists in debian/tmp but is not installed to anywhere (related file: "scripts/cryptsetup.conf") dh_missing: error: missing files, aborting Some of the files had a file that looked similar to a missing counter part. Perhaps one of the debhelper tools should installed the missing file instead of its related file assuming the content is identical. As an example, perhaps you want to replace: * scripts/cryptsetup.conf with: * usr/lib/tmpfiles.d/cryptsetup.conf in a file in debian/ or as argument to one of the dh_* tools called from debian/rules. (Note it is possible the paths are not used verbatim but instead directories containing or globs matching them are used instead) Alternatively, add the missing file to debian/not-installed if it cannot and should not be used. The following debhelper tools have reported what they installed (with files per package) * dh_install: cryptsetup (19), cryptsetup-bin (27), cryptsetup-initramfs (15), cryptsetup-run (0), cryptsetup-udeb (16), libcryptsetup-dev (3), libcryptsetup12 (2), libcryptsetup12-udeb (2) * dh_installdocs: cryptsetup (53), cryptsetup-bin (0), cryptsetup-initramfs (1), cryptsetup-run (0), libcryptsetup-dev (1), libcryptsetup12 (0) * dh_installexamples: cryptsetup (1), cryptsetup-bin (0), cryptsetup-initramfs (0), cryptsetup-run (0), libcryptsetup-dev (0), libcryptsetup12 (0) * dh_installman: cryptsetup (4), cryptsetup-bin (0), cryptsetup-initramfs (0), cryptsetup-run (0), libcryptsetup-dev (0), libcryptsetup12 (0) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built For a short-term work-around: Add the files to debian/not-installed make: *** [debian/rules:19: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 I do have systemd installed in my chroot image, since I'm using a custom version of sbuild with a backend using systemd-nspawn to start up a container to build in. -- Daniel Schepler
Bug#961863: zatacka: Depends/Build-Depends on cruft package ttf-dejavu-core
Package: zatacka Version: 0.1.8-5.2 Severity: serious Currently, src:zatacka Build-Depends on ttf-dejavu and the binary package Depends on ttf-dejavu-core. However, src:fonts-dejavu dropped these packages as of 2.37-2; so it's currently only possible to install the package by using obsolete packages in sid, and once 2.37-2 migrates to testing, the packages will become uninstallable. -- Daniel Schepler
Bug#961561: gazebo: Build-Depends on cruft package ttf-dejavu-core
Source: gazebo Version: 11.0.0+dfsg1-2 Severity: serious As the subject says: src:gazebo has a Build-Depends on ttf-dejavu-core which is no longer built as of src:fonts-dejavu version 2.37-2. As a result, it will only be possible to build on sid using an obsolete binary package, and it won't be possible at all on testing once fonts-dejavu 2.37-2 migrates to testing. -- Daniel Schepler
Bug#961560: yade: Build-Depends-Indep on cruft package texlive-generic-extra
Source: yade Version: 2020.01a-7 Severity: serious As the subject says: src:yade has a Build-Depends-Indep on texlive-generic-extra | texlive-plain-generic where texlive-generic-extra is no longer built by the texlive-extra source package. That will cause issues trying to build using sbuild on a testing chroot, since sbuild forces the first alternative to be used. -- Daniel Schepler
Bug#960976: libguava-java: Generates unsatisfiable dependencies on libguava-java (>= 29.0-jre)
Package: libguava-java Version: 29.0-2 Severity: important For example, if I build guice_4.2.1-1 (using sbuild) then the resulting libguice-java package gets dependencies of: libguice-java_4.2.1-1_all.deb - new Debian package, version 2.0. size 963020 bytes: control archive=1896 bytes. 1100 bytes,23 lines control 3818 bytes,35 lines md5sums Package: libguice-java Source: guice Version: 4.2.1-1 Architecture: all Maintainer: Debian Java Maintainers Installed-Size: 1184 Depends: libaopalliance-java, libatinject-jsr330-api-java, libguava-java (>= 29.0-jre), libjsr305-java Suggests: libasm-java (>= 7.2), libcglib-java (>= 3.2.12) Built-Using: asm (= 7.2-1), cglib (= 3.2.12-1) Section: java Priority: optional Homepage: https://github.com/google/guice Description: lightweight dependency injection framework for Java 5 and above Guice provides support for dependency injection using annotations to configure Java objects. Dependency injection is a design pattern whose core principle is to separate behavior from dependency resolution. . Guice allows implementation classes to be programmatically bound to an interface, then injected into constructors, methods or fields using an @Inject annotation. When more than one implementation of the same interface is needed, the user can create custom annotations that identify an implementation, then use that annotation when injecting it. Which then obviously makes the resulting package uninstallable: daniel@frobnitz:~/rebuild$ apt-get -s install ./libguice-java_4.2.1-1_all.deb NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'libguice-java' instead of './libguice-java_4.2.1-1_all.deb' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libguice-java : Depends: libguava-java (>= 29.0-jre) but 29.0-2 is to be installed E: Unable to correct problems, you have held broken packages. -- Daniel Schepler
Bug#943162: linphone: Build-Depends on obsolete package python-pystache
severity 943162 serious thanks With python-pystache now being removed from unstable, the Python2 removal bug becomes RC since that makes the Build-Depends of src:linphone uninstallable. -- Daniel Schepler
Bug#960619: libzypp1702: Depends on cruft package libsolv0
Package: libzypp1702 Version: 17.7.0-1+b1 Severity: serious The current build of libzypp1702 (17.7.0-1+b1 on amd64) Depends on libsolv0, while the current version of src:libsolv builds only libsolv1. This also cannot be resolved with a new binNMU: src:libzypp Build-Depends on libsolv0-dev, while the current version of src:libsolv builds only libsolv1-dev. -- Daniel Schepler
Bug#960615: libbssolv-perl: Build-Depends on cruft package libsolv0-dev
Source: libbssolv-perl Version: 0.17-1 Severity: serious The source package libbssolv-perl Build-Depends on libsolv0-dev, whereas the current version of src:libsolv builds only libsolv1-dev. -- Daniel Schepler
Bug#950939: sbuild: Build of package with version "0" has no "Version: 0" in the log's Summary
Package: sbuild Version: 0.79.0-1 Severity: minor At the end of my sbuild log for fonts-recommended_0, I get: +--+ | Summary | +--+ Build Architecture: amd64 Build Type: all Build-Space: 64 Build-Time: 3 Distribution: unstable Host Architecture: amd64 Install-Time: 9 Job: fonts-recommended_0 Machine Architecture: amd64 Package: fonts-recommended Package-Time: 23 Space: 64 Status: successful Finished at 2020-02-08T12:14:35Z Build needed 00:00:23, 64k disk space ... I have a script which is then erroring out because of the lack of a "Version" field in the summary. -- Daniel Schepler
Bug#949843: Missed part of systemd-nspawn patch
I just realized based on some testing that I forgot to send part of the patch, which is needed for sbuild-update to work with the systemd-nspawn chroot backend. -- Daniel Schepler Description: missed part of systemd-nspawn backend patch needed for sbuild-update Author: Daniel Schepler --- sbuild-0.78.1.orig/lib/Sbuild/Utility.pm +++ sbuild-0.78.1/lib/Sbuild/Utility.pm @@ -99,6 +99,9 @@ sub setup ($$$) { } elsif ($conf->get('CHROOT_MODE') eq 'unshare') { require Sbuild::ChrootInfoUnshare; $chroot_info = Sbuild::ChrootInfoUnshare->new($conf); +} elsif ($conf->get('CHROOT_MODE') eq 'systemd-nspawn') { + require Sbuild::ChrootInfoNspawn; + $chroot_info = Sbuild::ChrootInfoNspawn->new($conf); } else { require Sbuild::ChrootInfoSudo; $chroot_info = Sbuild::ChrootInfoSudo->new($conf);
Bug#950354: dose-builddebcheck: Filter out Architecture: all sources with --deb-drop-b-d-indep
Package: dose-builddebcheck Version: 5.0.1-14 Severity: wishlist Brief background: I'm currently working on a "local buildd" script, which I envisioned as being useful for something like the KDE team using it to test prerelease builds of a set of interdependent packages. Previously I had it ignoring Build-Depends and trying to build everything that came in, assuming that users would order their uploads appropriately. But it does seem that in the KDE example, for instance each new release of Frameworks will all come out at the same time, and it could be useful to have a script that initially just upgrades all source packages (and regenerates each debian/control's Build-Depends to the new version for internal interdependencies) and dumps them into the micro-buildd to see what breaks. So, I was considering using dose-builddebcheck to replicate that part of buildd's functionality. I was hoping I could also, as a side effect, implement architecture filtering by dose-builddebcheck's filtering. So far, when I do the full run on debian_main_source_Sources with --deb-native-arch=amd64, I do see for example that iprutils (Architecture: powerpc ppc64 ppc64el) gets filtered out. The problem happens when I want to split out the binary-arch and binary-indep builds. If I run with --deb-native-arch=amd64 --deb-drop-b-d-indep, for example, I'm still seeing zzzeeksphinx in the output even though zzzeeksphinx is purely Architecture: all. Similarly, if I run with --deb-native-arch=amd64 --deb-drop-b-d-arch, I still see zziplib in the output even though zziplib is purely Architecture: any and has no arch=all packages. -- Daniel Schepler
Bug#949848: sbuild: Support running just apt-get under eatmydata
Package: sbuild Version: 0.78.1-2 Severity: wishlist When using my systemd-nspawn chroot mode backend, the installation process is fairly slow due to it being on a BTRFS filesystem. (And also, I was never really comfortable with the current recommendation to put "eatmydata" into the schroot configuration to apply to all commands, in case the LD_PRELOAD applying also to dpkg-buildpackage might break some package build.) So, this patch adds the ability to request sbuild to run just the apt-get commands under eatmydata. (It might not apply cleanly to a current source package since I based it on top of my previous patch from #939843.) -- Daniel Schepler Description: eatmydata support Adds support for executing only apt-get under eatmydata (instead of needing to configure schroot to execute everything, even dpkg-buildpackage, under eatmydata). Author: Daniel Schepler --- sbuild-0.78.1.orig/lib/Sbuild/ChrootNspawn.pm +++ sbuild-0.78.1/lib/Sbuild/ChrootNspawn.pm @@ -53,7 +53,7 @@ sub begin_session { '/dev/null', '2>pipe', $CONTAINER_STDERR; -my $session_id, $location; +my ($session_id, $location); if (($_ = <$CONTAINER_STDERR>) =~ m/^Spawning container (\S*) on (.*)\.$/) { $session_id = $1; $location = $2; --- sbuild-0.78.1.orig/lib/Sbuild/Conf.pm +++ sbuild-0.78.1/lib/Sbuild/Conf.pm @@ -476,6 +476,21 @@ sub setup ($) { DEFAULT => 'md5sum', HELP => 'Path to md5sum binary' }, + 'EATMYDATA'=> { + TYPE => 'STRING', + VARNAME => 'eatmydata', + GROUP => 'Programs', + DEFAULT => 'eatmydata', + HELP => 'Path to eatmydata binary' + }, + 'USE_EATMYDATA'=> { + TYPE => 'BOOL', + VARNAME => 'use_eatmydata', + GROUP => 'Programs', + DEFAULT => 0, + HELP => 'Use eatmydata for installing packages?', + CLI_OPTIONS => ['--use-eatmydata', '--no-use-eatmydata'] + }, 'STATS_DIR'=> { TYPE => 'STRING', VARNAME => 'stats_dir', --- sbuild-0.78.1.orig/lib/Sbuild/ResolverBase.pm +++ sbuild-0.78.1/lib/Sbuild/ResolverBase.pm @@ -646,7 +646,8 @@ sub upgrade { { COMMAND => [$self->get_conf('APT_GET'), '-uy', '-o', 'Dpkg::Options::=--force-confold', 'upgrade'], ENV => {'DEBIAN_FRONTEND' => 'noninteractive'}, USER => 'root', - DIR => '/' }); + DIR => '/', + EATMYDATA => 1 }); return $?; } @@ -657,7 +658,8 @@ sub distupgrade { { COMMAND => [$self->get_conf('APT_GET'), '-uy', '-o', 'Dpkg::Options::=--force-confold', 'dist-upgrade'], ENV => {'DEBIAN_FRONTEND' => 'noninteractive'}, USER => 'root', - DIR => '/' }); + DIR => '/', + EATMYDATA => 1 }); return $?; } @@ -690,7 +692,8 @@ sub autoremove { { COMMAND => [$self->get_conf('APT_GET'), '-y', 'autoremove'], ENV => {'DEBIAN_FRONTEND' => 'noninteractive'}, USER => 'root', - DIR => '/' }); + DIR => '/', + EATMYDATA => 1}); return $?; } @@ -848,7 +851,8 @@ sub run_apt { ENV => {'DEBIAN_FRONTEND' => 'noninteractive'}, USER => 'root', PRIORITY => 0, - DIR => '/' }); + DIR => '/', + EATMYDATA => 1 }); if (!$pipe) { $self->log("Can't open pipe to apt-get: $!\n"); return 0; @@ -1555,6 +1559,15 @@ sub get_apt_command_internal { @aptcommand = @$command; } +if (exists $options->{'EATMYDATA'} && $options->{'EATMYDATA'} && + $self->get_conf('USE_EATMYDATA')) { + my $session = $self->get('Session'); + if (defined($session->get('Session Purged')) && + $session->get('Session Purged') == 1) { + unshift @aptcommand, $self->get_conf('EATMYDATA'); + } +} + debug2("APT Command: ", join(" ", @aptcommand), "\n"); $options->{'INTCOMMAND'} = \@aptcommand; --- sbuild-0.78.1.orig/man/sbuild.1.in +++ sbuild-0.78.1/man/sbuild.1.in @@ -66,6 +66,8 @@ sbuild \- build debian packages from sou .RB [ \-n \[or] \-\-nolog ] .RB [ \-\-clean\-source ] .RB [ \-\-no\-clean\-source ] +.RB [ \-\-use-eatmydata ] +.RB [ \-\-no-use-eatmydata ] .RB [ \-\-run\-lintian ] .RB [ \-\-no\-run\-lintian ] .RB [ \-\-lintian\-opt=\fIoptions\fP ] @@ -645,6 +647,22 @@ This command line option sets the \fBCLE .BR sbuild.conf (5) for more information. .TP +.BR \-\-use\-eatmydata +When installing packages in the chroot, use eatmydata to speed up the +installation. Note that this only has an effect on cloned chroots, and not +for example when running sbuild\-update on a source chroot. It also requires +the eatmydata package to be preinstalled in the chroot. +This command line option sets the \fBUSE_EATMYDATA\fP configuration variable. See +.BR sbuild.conf (5) +for more information +.TP +.BR \-\-no\-use\-eatmydata +When installing packages in the chroot, do not use eatmydata to speed up the +installation. +This command line option sets the \fBUSE_EATMYDATA\fP configuration variable. See +.BR sbuild.conf (5) +for more information +.TP .BR \-\-run\-lintian Run lintian after a successful build. This command line option sets the \fBRUN_LINTIAN\fP configuration variable. See
Bug#949843: sbuild: add systemd-nspawn chroot mode
Package: sbuild Version: 0.78.1-2 Severity: wishlist Here's my initial version of the cleaned up patch for adding a --chroot-mode=systemd-nspawn. Some things I'm not sure about: - Should we maybe ping upstream and/or Debian maintainers on https://github.com/systemd/systemd/issues/13297 to see how hard it would be to get it fixed so I could remove that whole ugly workaround? (The workaround also only handles bind mount settings at present - and for example, I've found that a lot of package builds will require SystemCallFilter=@memlock due to a lot of crypto libraries and utilities giving errors if they're denied access to mlock. So I would probably want to add that to my /etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.) - It currently requires giving sudo access for systemd-run, which essentially would open up execution of anything desired. And the fact that it requires NOPASSWD (because some of the commands redirect stdin/stdout) makes things even worse. And even if you restrict it to e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it would be possible to fool that with something like "sudo systemd-run -M unstable-amd64-sbuild -M .host ~/myevilcmd". - If you want to ignore the small patch in lib/Sbuild/Chroot.pm that's fine. It's not really related to the systemd-nspawn chroot mode. - It does add a dependency on libipc-run-perl. - It would be nice (as a future enhancement) if it would be possible to configure this backend to start the container in --network-veth mode and set up the host's side of the veth to forward only traffic to/from apt-cacher-ng on localhost:3142. Not sure how hard that would be to accomplish. -- Daniel Schepler Description: Implement systemd-nspawn chroot mode Adds a chroot mode using systemd-nspawn to start a container to use for builds. Author: Daniel Schepler --- sbuild-0.78.1.orig/lib/Sbuild/Build.pm +++ sbuild-0.78.1/lib/Sbuild/Build.pm @@ -53,6 +53,7 @@ use Sbuild::ChrootInfoSchroot; use Sbuild::ChrootInfoUnshare; use Sbuild::ChrootInfoSudo; use Sbuild::ChrootInfoAutopkgtest; +use Sbuild::ChrootInfoNspawn; use Sbuild::ChrootRoot; use Sbuild::Sysconfig qw($version $release_date); use Sbuild::Sysconfig; @@ -422,6 +423,8 @@ sub run_chroot_session { $chroot_info = Sbuild::ChrootInfoAutopkgtest->new($self->get('Config')); } elsif ($self->get_conf('CHROOT_MODE') eq 'unshare') { $chroot_info = Sbuild::ChrootInfoUnshare->new($self->get('Config')); + } elsif ($self->get_conf('CHROOT_MODE') eq 'systemd-nspawn') { + $chroot_info = Sbuild::ChrootInfoNspawn->new($self->get('Config')); } else { $chroot_info = Sbuild::ChrootInfoSudo->new($self->get('Config')); } --- sbuild-0.78.1.orig/lib/Sbuild/Chroot.pm +++ sbuild-0.78.1/lib/Sbuild/Chroot.pm @@ -244,10 +244,8 @@ sub get_read_file_handle { my $dir = "/"; $dir = $options->{'DIR'} if defined $options->{'DIR'}; -my $escapedsource = shellescape $source; - my $pipe = $self->pipe_command({ - COMMAND => [ "sh", "-c", "cat $escapedsource" ], + COMMAND => [ "cat", "--", $source ], DIR => $dir, USER => $user, PIPE => 'in' --- /dev/null +++ sbuild-0.78.1/lib/Sbuild/ChrootInfoNspawn.pm @@ -0,0 +1,68 @@ +package Sbuild::ChrootInfoNspawn; + +use Sbuild::ChrootInfo; +use Sbuild::ChrootNspawn; + +use strict; +use warnings; + +BEGIN { +use Exporter (); +our (@ISA, @EXPORT); + +@ISA=qw(Exporter Sbuild::ChrootInfo); + +@EXPORT = qw(); +} + +sub new { +my $class = shift; +my $conf = shift; + +my $self = $class->SUPER::new($conf); +bless($self, $class); + +return $self; +} + +sub get_info_all { +my $self = shift; + +my $chroots = {}; + +open CHROOTS, '-|', $self->get_conf('MACHINECTL'), 'list-images' + or die 'Can\'t run machinectl list-images'; + +# skip header line +; + +while (($_ = ) ne "\n") { + chomp; + my @fields = split /\s+/, $_; + my $chroot = $fields[0]; + $chroots->{'chroot'}->{$chroot} = 1; + $chroots->{'source'}->{$chroot} = 1; +} + +# skip "N images listed" +; + +close CHROOTS or die "Can't close machinectl list-images pipe"; + +$self->set('Chroots', $chroots); +} + +sub _create { +my $self = shift; +my $chroot_id = shift; + +my $chroot = undef; + +if (defined($chroot_id)) { + $chroot = Sbuild::ChrootNspawn->new($self->get('Config'), $chroot_id); +} + +return $chroot; +} + +1; --- /dev/null +++ sbuild-0.78.1/lib/Sbuild/ChrootNspawn.pm @@ -0,0 +1,238 @@ +package Sbuild::ChrootNspawn; + +use strict;
Bug#948522: If I rebuild src:file with libseccomp-dev installed, then "fakeroot file ..." crashes with "Bad system call"
Source: file Version: 1:5.38-3 Severity: normal As the subject says: in my environment with libseccomp-dev installed, the resulting file package gets a dependency on libseccomp2. And if I install that, then I subsequently get strange errors while trying to build src:binutils, which I eventually tracked down to: $ fakeroot file /usr/bin/file Bad system call $ "fakeroot strace file /usr/bin/file" shows: ... futex(0x7ff6fb5b06f4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0 prctl(PR_SET_DUMPABLE, SUID_DUMP_DISABLE) = 0 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) seccomp(SECCOMP_SET_MODE_FILTER, 0, 0x55c39592c300) = 0 futex(0x7ff6fb3f40c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 stat(0x55c39592d910, 0x7ffe668c02f0)= -1 ENOENT (No such file or directory) stat(0x55c39592d910, 0x7ffe668c02f0)= -1 ENOENT (No such file or directory) openat(AT_FDCWD, 0x55c39592d910, O_RDONLY) = -1 ENOENT (No such file or directory) stat(0x55c39592fb70, 0x7ffe668c02e0)= 0 msgget(0x41c5ccd5, IPC_CREAT|0600) = ? +++ killed by SIGSYS +++ Bad system call (core dumped) (It might also be relevant here that I am running the Debian environment within a systemd-nspawn container which already applies its own seccomp filters, and also that I am running on a locally built kernel not an official Debian kernel - and also the host system is a custom built system so my systemd-nspawn does not have Debian patches.) I would guess the easiest way to resolve this would be to add an explicit "--disable-libseccomp" to the dh_auto_configure command. (Which I would certainly prefer to having the source package Build-Conflicts: libseccomp-dev.) -- Daniel Schepler
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
Source: xz-utils Version: 5.2.4-1 Severity: serious >From my pbuilder build log: ... debian/rules build dh build --parallel dh_update_autotools_config -O--parallel dh_auto_configure -O--parallel dh_auto_build -O--parallel dh_auto_test -O--parallel fakeroot debian/rules binary dh binary --parallel debian/rules install make[1]: Entering directory '/build/xz-utils-5.2.4' dh install --parallel debian/rules build make[2]: Entering directory '/build/xz-utils-5.2.4' dh build --parallel make[2]: Leaving directory '/build/xz-utils-5.2.4' dh_testroot -O--parallel dh_prep -O--parallel debian/rules override_dh_auto_install make[2]: Entering directory '/build/xz-utils-5.2.4' dh_auto_install --builddirectory debian/xzdec-build dh_auto_install --builddirectory debian/normal-build dh_auto_install --builddirectory debian/static-build set -e; arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH); \ install -d debian/tmp/lib/$arch; \ mv debian/tmp/usr/lib/$arch/liblzma.so.* debian/tmp/lib/$arch/; \ dso=$(basename $(readlink debian/tmp/usr/lib/$arch/liblzma.so)); \ ln -s -f /lib/$arch/$dso debian/tmp/usr/lib/$arch/liblzma.so mv: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*': No such file or directory make[2]: *** [debian/rules:34: override_dh_auto_install] Error 1 make[2]: Leaving directory '/build/xz-utils-5.2.4' make[1]: *** [debian/rules:4: install] Error 2 make[1]: Leaving directory '/build/xz-utils-5.2.4' make: *** [debian/rules:4: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
Bug#945553: binutils: FTBFS with strip-nondeterminism installed
Source: binutils Version: 2.33.1-4 Severity: normal My trial build, in a container with lots of extra packages installed including strip-nondeterminism, ends with: : # Get rid of .la files since libtool obviously has no idea about transient paths rm -f debian/binutils-s390x-linux-gnu/usr/x86_64-linux-gnu/s390x-linux-gnu/lib/*.la if which strip-nondeterminism >/dev/null 2>&1; then \ find debian/binutils-s390x-linux-gnu -name '*.a' -print0 \ | xargs -0r strip-nondeterminism --type ar; \ fi ar: Unknown file type xargs: strip-nondeterminism: exited with status 255; aborting make: *** [debian/rules:850: stamps/install.s390x] Error 124 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 (This also affects cross-toolchain-base* but I'm supposing it's because those source packages use binutils-source.) -- Daniel Schepler
Bug#945362: tpm-udev: Fails to install in systemd-nspawn container
Package: tpm-udev Version: 0.2 Severity: normal X-Debbugs-Cc: tpm2-...@packages.debian.org While trying to build packages in a systemd-nspawn container, I ran into a failure of tpm-udev to install: ... Preparing to unpack .../tpm-udev/tpm-udev_0.2_all.deb ... Unpacking tpm-udev (0.2) ... Selecting previously unselected package libtss2-esys0. Preparing to unpack .../libtss2-esys0_2.3.1-2_amd64.deb ... Unpacking libtss2-esys0 (2.3.1-2) ... Selecting previously unselected package libtss2-dev. Preparing to unpack .../libtss2-dev_2.3.1-2_amd64.deb ... Unpacking libtss2-dev (2.3.1-2) ... Setting up tpm-udev (0.2) ... Adding group `tss' (GID 170) ... Done. Adding system user `tss' (UID 153) ... Adding new user `tss' (UID 153) with group `tss' ... Not creating home directory `/var/lib/tpm'. Failed to send reload request: No such file or directory Failed to write 'change' to '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00/tpm/tpm0/uevent': Read-only file system Failed to write 'add' to '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00/tpm/tpm0/uevent': Read-only file system dpkg: error processing package tpm-udev (--configure): installed tpm-udev package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of libtss2-esys0: libtss2-esys0 depends on tpm-udev; however: Package tpm-udev is not configured yet. dpkg: error processing package libtss2-esys0 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libtss2-dev: libtss2-dev depends on libtss2-esys0 (= 2.3.1-2); however: Package libtss2-esys0 is not configured yet. dpkg: error processing package libtss2-dev (--configure): dependency problems - leaving unconfigured Processing triggers for man-db (2.9.0-1) ... Processing triggers for libc-bin (2.29-3) ... Errors were encountered while processing: tpm-udev libtss2-esys0 libtss2-dev E: Sub-process /usr/bin/dpkg returned an error code (1) E: Failed to process build dependencies That, in turn, means that I cannot build such packages as src:fwupd, src:openconnect, src:tpm2-abrmd in this container (this last one is the one that first came up on my radar). -- Daniel Schepler
Bug#937926: python-pbr package
In a message to #937926 you said that you've re-introduced python-pbr. Could I ask where that was re-introduced? I've checked the new upload of src:python-pbr version 5.4.3-1, and I've also checked unstable and NEW for anything like a python2-pbr source package without seeing anything relevant. -- Daniel
Bug#937926: python-pbr has been removed
severity 937926 serious thanks The latest upload of src:python-pbr has now removed the python[2]-pbr binary package, thus making the build dependencies of src:python-mock uninstallable, and raising the urgency of dropping that build dependency. (Unless you install an older binary package of python-pbr from the archive; but in any case, either this will block python-pbr from migrating to testing, or else in testing the source package for python-mock will be truly unbuildable.) -- Daniel Schepler
Bug#934978: mini-buildd: Does not function behind a NAT router
On Sat, Aug 24, 2019 at 1:22 AM Stephan Sürken wrote: > For 1.1.x development, please try to run 'dpkg-reconfigure mini-buildd' > and change/add this endpoint argument: > > --httpd-endpoint=tcp6:port=8066:interface=localhost > > I guess this might solve the problem at hand. Sorry for the delay in testing. I had concluded that to meet my needs (for instance I also wanted to have support for source.changes uploads which mini-buildd currently rejects for lack of packages from required architecture amd64), it would probably be easier to write my own version of the build daemon backend from scratch. As a result, I removed the chroot and the sudo configuration for mini-buildd. (I never installed mini-buildd as a package, I just ran it from a local installation directory. Incidentally, that did require a patch to replace a hard-coded static files location to one calculated based on __file__.) So, it would take a while to get things set back up for more testing. That said, I was already passing -E tcp:port=8066:interface=127.0.0.1 on the command line. If you would still like to see whether tcp6 vs. tcp, or localhost vs. 127.0.0.1, makes a difference, then I might be able to recreate the chroot and redo the sudo configuration sometime later this week. -- Daniel Schepler
Bug#934978: mini-buildd: Does not function behind a NAT router
On Mon, Aug 19, 2019 at 12:25 PM Stephan Sürken wrote: > I am not quite getting it ;), I guess I need more information here. > > What's the 'Hostname' entry of the 'Daemon' instance? localhost > Do you have remotes configured (not needed if you are building on that > host only)? No, no remotes configured. Also, on further investigation, it appears that "a23-195-69-106.deploy.static.akamaitechnologies.com" is actually the FQDN of the host my ISP's broken DNS redirects me to for nonexistent host names :( , rather than the external IP address of the NAT router. -- Daniel Schepler
Bug#934978: mini-buildd: Does not function behind a NAT router
Package: mini-buildd Version: 1.1.18 Severity: wishlist I think I've gotten my local mini-buildd instance mostly set up. But now, when I try to upload to it to do a test build, I get a failure along the lines of: Host: a23-195-69-106.deploy.static.akamaitechnologies.com Build request failed: 100 (upload-failed): Failed to update status for remote via URL 'http://a23-195-69-106.deploy.static.akamaitechnologies.com:8066/mini_buildd/api?command=status&output=python': I've verified by direct search through config.sqlite that no instances of that external host name are left in the configuration; yet it still seems to be getting that from somewhere as the address to connect builders to. My intent is to use it only locally, and not to expose it to the internet. (Note that I was making some local changes to try to adapt it to my use case of using it as the primary buildd of a custom distribution. e.g. I wanted it to be able to produce unstable,experimental distributions instead of the current form ?-?-?. But as far as I know, none of the changes I made touched anything related to the setting of the base URL.) -- Daniel Schepler
Bug#934346: sbuild: No need to install fakeroot for source packages with Rules-Requires-Root: no
Package: sbuild Version: 0.78.1-2 Severity: wishlist I notice that on my source packages which declare "Rules-Requires-Root: no" I still see sbuild installing fakeroot in the chroot which shouldn't be necessary. -- Daniel Schepler
Bug#931124: debhelper: Add dh_missing option or feature to report/error on unreproduced empty directories
Package: debhelper Version: 12.1.1 Severity: wishlist It's not uncommon for an upstream build system's install process to create a hierarchy of empty directories as placeholders for data storage. It would be nice if dh_missing would report it (and error out in --fail-missing mode) when a maintainer has failed to include those placeholder directories in any package. -- Daniel Schepler
Bug#905866: uscan: prefers watch files from a random dir over debian/watch
I find the recursive search feature useful for when I have a large collection of unpacked source packages in $HOME/src/debian, then I can "cd ~/src/debian; uscan --report" to check for updates to any of those source packages. As for an example I've run into: https://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz contains several invalid debian/watch files which trigger error messages in the multiple-package uscan run until I manually delete them. -- Daniel Schepler
Bug#836934: Bug#871215: Does it make sense to keep frobtads?
On Thu, Dec 20, 2018 at 10:33 AM Sebastian Andrzej Siewior wrote: > If you want then I can sponsor the upload. If you want me to package the > latest release and NMU then this might work, too. Someone should do the > testing who is familiar with it. > However if there is no interest in the package then... Well, I'm leaving for Christmas vacation soon, so probably the earliest I could prepare an upload would be about the middle of January. (I do admit it's probably a niche package - but I still fire it up occasionally to play some of the games written in the system.) -- Daniel Schepler
Bug#836934: Bug#871215: Does it make sense to keep frobtads?
On Wed, Dec 19, 2018 at 3:42 PM Sebastian Andrzej Siewior wrote: > frobtads wasn't part of Stretch and has two RC bugs open with no action > in over a year. > Can it be removed or is somehow important? In a Google search, I found newer upstream releases on GitHub - https://github.com/realnc/frobtads/releases . The release notes do mention fixing some compilation issues with newer gcc. Same goes for qtads - there's a 2.1.7 release, though that's from 2016. It might be worth checking if that version builds, and whether it works with Qt 5. (The latter needs a run-time test: when I tried it last, 2.1.6 built successfully against Qt 5 but then the resulting executable was completely broken.) Currently, though, my previous GPG key was removed from the Debian keyring and I haven't gotten around to finding somebody locally who could sign a new key for me. So, I wouldn't be able to upload updated packages myself. -- Daniel Schepler
Bug#912056: xdffileio: FTBFS: Test failures
Source: xdffileio Version: 0.3-2 Severity: serious Tags: ftbfs >From my pbuilder build log: ... make check-TESTS make[3]: Entering directory '/build/xdffileio-0.3/tests' make[4]: Entering directory '/build/xdffileio-0.3/tests' PASS: readcheck PASS: errorcheck FAIL: testbdf PASS: testedf PASS: testgdf2 FAIL: testgdf1 = xdffileio 0.3: tests/test-suite.log = # TOTAL: 6 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: testbdf = Version : xdffileio 0.3 One of the files cannot be opened FAIL testbdf (exit status: 1) FAIL: testgdf1 == Version : xdffileio 0.3 The files are identical The files are identical Cannot create an XDF file: (17) File exists FAIL testgdf1 (exit status: 1) Testsuite summary for xdffileio 0.3 # TOTAL: 6 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 See tests/test-suite.log Please report to nicolas.burd...@epfl.ch make[4]: *** [Makefile:918: test-suite.log] Error 1 make[4]: Leaving directory '/build/xdffileio-0.3/tests' make[3]: *** [Makefile:1026: check-TESTS] Error 2 make[3]: Leaving directory '/build/xdffileio-0.3/tests' make[2]: *** [Makefile:1135: check-am] Error 2 make[2]: Leaving directory '/build/xdffileio-0.3/tests' make[1]: *** [Makefile:630: check-recursive] Error 1 make[1]: Leaving directory '/build/xdffileio-0.3' dh_auto_test: make -j8 check VERBOSE=1 returned exit code 2 make: *** [debian/rules:26: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 It looks like reproducible-builds.org also got testsuite errors in build2, though with somewhat different errors. So, it looks like there's probably some race condition in the testsuite that causes random failures. -- Daniel Schepler
Bug#912054: xapian-omega: FTBFS: can't parse dependency libxapian30 (>= 1.4.7) (>= 1.4.6~)
Source: xapian-omega Version: 1.4.7-1 Severity: serious Tags: ftbfs >From my pbuilder build log: ... dh_makeshlibs dh_installdeb dh_shlibdeps # Rewrite the dependency on libxapianN to be >= our version, since # we may require features added in that version. sed -i \ 's/^shlibs:Depends=.*libxapian[0-9][0-9a-z]*/& (>= 1.4.7)/' \ debian/*.substvars dh_gencontrol dpkg-gencontrol: warning: can't parse dependency libxapian30 (>= 1.4.7) (>= 1.4.6~) dpkg-gencontrol: error: error occurred while parsing Depends field: libc6 (>= 2.15), libgcc1 (>= 1:3.0), libmagic1 (>= 5.12), libpcre3, libstdc++6 (>= 5.2), libxapian30 (>= 1.4.7) (>= 1.4.6~), zlib1g (>= 1:1.1.4), dh_gencontrol: dpkg-gencontrol -pxapian-omega -ldebian/changelog -Tdebian/xapian-omega.substvars -Pdebian/.debhelper/xapian-omega/dbgsym-root -UPre-Depends -URecommends -USuggests -UEnhances -UProvides -UEssential -UConflicts -DPriority=optional -UHomepage -UImportant -DAuto-Built-Package=debug-symbols -DPackage=xapian-omega-dbgsym "-DDepends=xapian-omega (= \${binary:Version})" "-DDescription=debug symbols for xapian-omega" "-DBuild-Ids=00d9192b 51a1d49fa8968505670baec8e5cfd71b 30db2840f00652052da4c6fc234ffaa78ce204fc 49d4db29d9ae124e69ae7eb91d3cba05a742d51a b511e8b16c908bf52b66447d9e119e0bbf191207" -DSection=debug -UMulti-Arch -UReplaces -UBreaks returned exit code 25 dh_gencontrol: Aborting due to earlier error make: *** [debian/rules:183: binary-arch] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912053: twms: FTBFS: UnicodeDecodeError
Source: twms Version: 0.06y-1 Severity: serious Tags: ftbfs >From my pbuilder build log: ... fakeroot debian/rules clean dh clean --with=python3 --with=systemd --buildsystem=pybuild dh_auto_clean -O--buildsystem=pybuild I: pybuild base:217: python3.7 setup.py clean running clean removing '/build/twms-0.06y/.pybuild/cpython3_3.7/build' (and everything under it) /usr/lib/python3/dist-packages/setuptools/dist.py:407: UserWarning: The version specified ('0.06y') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details. "details." % self.metadata.version 'build/bdist.linux-amd64' does not exist -- can't clean it 'build/scripts-3.7' does not exist -- can't clean it I: pybuild base:217: python3.6 setup.py clean Traceback (most recent call last): File "setup.py", line 48, in long_description = read('README.md'), File "setup.py", line 14, in read return open(os.path.join(os.path.dirname(__file__), fname)).read() File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 86: ordinal not in range(128) E: pybuild pybuild:338: clean: plugin distutils failed with: exit code=1: python3.6 setup.py clean dh_auto_clean: pybuild --clean -i python{version} -p "3.7 3.6" returned exit code 13 make: *** [debian/rules:3: clean] Error 25 dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912052: sslsplit: FTBFS: Failure in test -r session.pem
Source: sslsplit Version: 0.5.3-1 Severity: serious Tags: ftbfs >From my pbuilder build log: ... make -C extra/pki testreqs session make[2]: Entering directory '/build/sslsplit-0.5.3/extra/pki' openssl genrsa -out rsa.key 2048 openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus (2 primes) Generating RSA private key, 2048 bit long modulus (2 primes) . + +++ +.+ +. .e is 65537 (0x010001) openssl req -new -nodes -x509 -sha256 -out server.crt -key server.key \ -config x509v3ca.cnf -extensions v3_crt \ -subj '/C=CH/O=SSLsplit Test Certificate/CN=daniel.roe.ch/' \ -set_serial 42 -days 365 cat server.crt server.key >server.pem openssl s_server -accept 46143 -cert server.pem -quiet & \ pid=$! ; \ sleep 1 ; \ echo q | openssl s_client -connect localhost:46143 \ -quiet -no_ign_eof -sess_out session.pem ; \ kill $pid + e is 65537 (0x010001) openssl req -new -nodes -x509 -sha256 -out rsa.crt -key rsa.key \ -config x509v3ca.cnf -extensions v3_ca \ -subj '/C=CH/O=SSLsplit Root CA/CN=SSLsplit Root CA/' \ -set_serial 1 -days 3650 cat rsa.crt rsa.key >rsa.pem mkdir -p targets mkdir -p targets openssl genrsa -out targets/daniel.roe.ch.key 2048 openssl genrsa -out targets/wildcard.roe.ch.key 2048 Generating RSA private key, 2048 bit long modulus (2 primes) Generating RSA private key, 2048 bit long modulus (2 primes) ..++.++.+ ..+.++.++ ...++.++.+ e is 65537 (0x010001) openssl req -new -sha256 -subj '/C=CH/CN=*.roe.ch/' \ -key targets/wildcard.roe.ch.key \ -out targets/wildcard.roe.ch.csr ..Can't load /nonexistent/.rnd into RNG 139907575923136:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/nonexistent/.rnd ...openssl x509 -req -sha256 -CAcreateserial -days 365 \ -CA rsa.crt -CAkey rsa.key \ -in targets/wildcard.roe.ch.csr \ -out targets/wildcard.roe.ch.crt ..Signature ok subject=C = CH, CN = *.roe.ch Getting CA Private Key ..cat targets/wildcard.roe.ch.crt targets/wildcard.roe.ch.key rsa.crt \ >targets/wildcard.roe.ch.pem .rm -f targets/wildcard.roe.ch.key targets/wildcard.roe.ch.csr \ targets/wildcard.roe.ch.crt + e is 65537 (0x010001) openssl req -new -sha256 -subj '/C=CH/CN=daniel.roe.ch/' \ -key targets/daniel.roe.ch.key \ -out targets/daniel.roe.ch.csr Can't load /nonexistent/.rnd into RNG 140554678874560:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/nonexistent/.rnd openssl x509 -req -sha256 -CAcreateserial -days 365 \ -CA rsa.crt -CAkey rsa.key \ -in targets/daniel.roe.ch.csr \ -out targets/daniel.roe.ch.crt Signature ok subject=C = CH, CN = daniel.roe.ch Getting CA Private Key cat targets/daniel.roe.ch.crt targets/daniel.roe.ch.key rsa.crt \ >targets/daniel.roe.ch.pem rm -f targets/daniel.roe.ch.key targets/daniel.roe.ch.csr \ targets/daniel.roe.ch.crt rm -f rsa.srl depth=0 C = CH, O = SSLsplit Test Certificate, CN = daniel.roe.ch verify error:num=18:self signed certificate verify return:1 depth=0 C = CH, O = SSLsplit Test Certificate, CN = daniel.roe.ch verify return:1 DONE test -r session.pem make[2]: *** [GNUmakefile:117: session.pem] Error 1 make[2]: Leaving directory '/build/sslsplit-0.5.3/extra/pki' make[1]: *** [GNUmakefile:410: test] Error 2 make[1]: Leaving directory '/build/sslsplit-0.5.3' dh_auto_test: make -j8 test returned exit code 2 make: *** [debian/rules:13: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912051: rsyncrypto: FTBFS: aclocal-1.15: command not found
Source: rsyncrypto Version: 1.14-1 Severity: serious >From my pbuilder build log: ... dh_auto_build make -j1 make[1]: Entering directory '/build/rsyncrypto-1.14' CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /build/rsyncrypto-1.14/missing aclocal-1.15 /build/rsyncrypto-1.14/missing: line 81: aclocal-1.15: command not found WARNING: 'aclocal-1.15' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> make[1]: *** [Makefile:361: aclocal.m4] Error 127 make[1]: Leaving directory '/build/rsyncrypto-1.14' dh_auto_build: make -j1 returned exit code 2 make: *** [debian/rules:19: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912049: orbit2: FTBFS: libname-server-2.a: No such file or directory
Source: orbit2 Version: 1:2.14.19-4 Severity: seriouis Tags: ftbfs >From my pbuilder build log: ... /bin/bash ../../../libtool --tag=CC --mode=link gcc -g -O2 -fdebug-prefix-map=/build/orbit2-2.14.19=. -fstack-protector-strong -Wformat -Werror=format-security -Werror-implicit-function-declaration -Wl,-z,relro -o name- client-2 name-client.o name-support.o ../../../src/orb/libORBit-2.la libORBitCosNaming-2.la -lm -lgobject-2.0 -lgthread-2.0 -pthread -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 libtool: link: gcc -g -O2 -fdebug-prefix-map=/build/orbit2-2.14.19=. -fstack-protector-strong -Wformat -Werror=format-security -Werror-implicit-function-declaration -Wl,-z -Wl,relro -o .libs/name-client-2 name-client.o name-s upport.o -pthread -Wl,--export-dynamic -pthread ../../../src/orb/.libs/libORBit-2.so ./.libs/libORBitCosNaming-2.so -lm -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -pthread gcc -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../../include -I../../../include -DORBIT2_INTERNAL_API -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -I../../../linc2/include -I../../../linc2/include -pthread -I/usr/ include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/orbit2-2.14.19=. -fstack-protector-strong -Wformat -Werror=format-security -Werror-implicit-func tion-declaration -c -o boot.o boot.c boot.c: In function 'main': boot.c:124:15: warning: pointer targets in assignment from 'char *' to 'CORBA_octet *' {aka 'unsigned char *'} differ in signedness [-Wpointer-sign] okey._buffer = opt_corbaloc_key; ^ /bin/bash ../../../libtool --tag=CC --mode=link gcc -g -O2 -fdebug-prefix-map=/build/orbit2-2.14.19=. -fstack-protector-strong -Wformat -Werror=format-security -Werror-implicit-function-declaration -Wl,-z,relro -o orbit -name-server-2 boot.o libname-server-2.a ../../../src/orb/libORBit-2.la libORBitCosNaming-2.la -lm -lgobject-2.0 -lgthread-2.0 -pthread -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 libtool: link: gcc -g -O2 -fdebug-prefix-map=/build/orbit2-2.14.19=. -fstack-protector-strong -Wformat -Werror=format-security -Werror-implicit-function-declaration -Wl,-z -Wl,relro -o .libs/orbit-name-server-2 boot.o -pthrea d -Wl,--export-dynamic -pthread libname-server-2.a ../../../src/orb/.libs/libORBit-2.so ./.libs/libORBitCosNaming-2.so -lm -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -pthread gcc: error: libname-server-2.a: No such file or directory make[6]: *** [Makefile:645: orbit-name-server-2] Error 1 make[6]: Leaving directory '/build/orbit2-2.14.19/src/services/name' make[5]: *** [Makefile:481: all] Error 2 make[5]: Leaving directory '/build/orbit2-2.14.19/src/services/name' make[4]: *** [Makefile:396: all-recursive] Error 1 make[4]: Leaving directory '/build/orbit2-2.14.19/src/services' make[3]: *** [Makefile:393: all-recursive] Error 1 make[3]: Leaving directory '/build/orbit2-2.14.19/src' make[2]: *** [Makefile:599: all-recursive] Error 1 make[2]: Leaving directory '/build/orbit2-2.14.19' make[1]: *** [Makefile:436: all] Error 2 make[1]: Leaving directory '/build/orbit2-2.14.19' make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) I do see in #890459 that you're planning to remove the package soon anyway. I just wanted to post this so you could decide whether you need to do an interim upload to fix this issue before the removal happens. -- Daniel Schepler
Bug#912048: obs-build: FTBFS: Test failures
ok t/richdeps.t 1..45 ok 1 - install () ok 2 - install (n and ) ok 3 - install (n foo m) ok 4 - install n ok 5 - install (n or o) ok 6 - install (n and o) ok 7 - install n1 ok 8 - install (n2 and d) ok 9 - install (n2 or d) ok 10 - install a ok 11 - install i j ok 12 - install (b if b) ok 13 - install (n if n) ok 14 - install lr ok 15 - install lc1 ok 16 - install lc2 ok 17 - install m ok 18 - install b c d !(b and c and d) ok 19 - install !(n if n) ok 20 - install b cx d ok 21 - install ign ok 22 - install ign1 ok 23 - install ign2 ok 24 - install ign3 ok 25 - install b ign4 ok 26 - install b ok 27 - install bad1 ok 28 - install bad2 ok 29 - install sc b ok 30 - install ifelse ok 31 - install ifelse i ok 32 - install ifelse c ok 33 - install unless b ok 34 - install unless b !i ok 35 - install unlesselse b c ok 36 - install unlesselse b ok 37 - install unlesselse c ok 38 - install (wx and wy) ok 39 - install (wx with wy) ok 40 - install (wx without wy) ok 41 - install (wy without wx) ok 42 - install (wa with wa) ok 43 - install (wa with nnn) ok 44 - install (wa without wa) ok 45 - install (wa without nnn) ok Test Summary Report --- t/changelog2spec.t (Wstat: 2816 Tests: 11 Failed: 11) Failed tests: 1-11 Non-zero exit status: 11 Files=8, Tests=107, 1 wallclock secs ( 0.04 usr 0.02 sys + 0.95 cusr 0.14 csys = 1.15 CPU) Result: FAIL make[1]: *** [Makefile:27: test] Error 1 make[1]: Leaving directory '/build/obs-build-20180831' dh_auto_test: make -j1 test returned exit code 2 make: *** [debian/rules:3: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912047: nullmailer: FTBFS: Test failure
nject rejects bad addresses. nullmailer-inject: Invalid header line: from: foo to Testing queue from <@b.c> to Testing queue from to <@e.f> Testing queue from <> to Done. Running test /build/nullmailer-2.1/test/tests/dsn... Testing envelope: sender, recipient, end Testing header: from, to, subject, date, message-id, mime, content-type Testing report header: reporting-mta, date Testing recipient report 1: final-recipient, action, status, date Testing recipient report 2: final-recipient, action, status, date Testing quoted message pre-header Testing quoted message header Testing quoted message body Testing fixed bounce address Testing max-lines: 0, 1, 2, bouncelines=1, override Done. 16 tests run, 1 failed make[2]: *** [Makefile:636: check] Error 1 make[2]: Leaving directory '/build/nullmailer-2.1/test' make[1]: *** [Makefile:365: check-recursive] Error 1 make[1]: Leaving directory '/build/nullmailer-2.1' dh_auto_test: make -j8 check VERBOSE=1 returned exit code 2 make: *** [debian/rules:16: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912045: mb2md: FTBFS: Test failures
Source: mb2md Version: 3.20-8 Severity: serious Tags: ftbfs >From my pbuilder build log: ... debian/rules override_dh_auto_test make[1]: Entering directory '/build/mb2md-3.20' debian/tests/run-testsuite.sh perl `pwd`/mb2md-3.20.pl # Failed test 'Check return from 'perl /build/mb2md-3.20/mb2md-3.20.pl -s example.mbox -d example.maildir' is 0' # at debian/tests/t/mb2md.t line 35. # got: '2' # expected: '0' # Failed test 'Stdout as expected ($HOME)' # at debian/tests/t/mb2md.t line 36. # got: '' # expected: 'Converting /tmp/TTcKFt21wi/home/example.mbox to maildir: /tmp/TTcKFt21wi/home/example.maildir # Source Mbox is /tmp/TTcKFt21wi/home/example.mbox # Target Maildir is /tmp/TTcKFt21wi/home/example.maildir # 2 messages. # # ' # Failed test 'No stderr ($HOME)' # at debian/tests/t/mb2md.t line 37. # got: 'Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu /perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /build/mb2md-3.20/mb2md-3.20.pl line 385. # BEGIN failed--compilation aborted at /build/mb2md-3.20/mb2md-3.20.pl line 385. # ' # expected: '' Error opendir on '/tmp/TTcKFt21wi/home/example.maildir/cur': No such file or directory at debian/tests/t/mb2md.t line 38. # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 2 just after 11. debian/tests/t/mb2md.t .. ok 1 - Created '/tmp/TTcKFt21wi/home' ok 2 - Successfully copied example.mbox to fake home directory /tmp/TTcKFt21wi/home/ ok 3 - Created '/tmp/TTcKFt21wi/1' ok 4 - Successfully copied example.mbox to fake home directory /tmp/TTcKFt21wi/1/ ok 5 - Created '/tmp/TTcKFt21wi/2' ok 6 - Successfully copied example.mbox to fake home directory /tmp/TTcKFt21wi/2/ ok 7 - Can run 'perl /build/mb2md-3.20/mb2md-3.20.pl -s example.mbox -d example.maildir' ok 8 - Process terminated without a signal not ok 9 - Check return from 'perl /build/mb2md-3.20/mb2md-3.20.pl -s example.mbox -d example.maildir' is 0 not ok 10 - Stdout as expected ($HOME) not ok 11 - No stderr ($HOME) Dubious, test returned 2 (wstat 512, 0x200) Failed 3/11 subtests Test Summary Report --- debian/tests/t/mb2md.t (Wstat: 512 Tests: 11 Failed: 3) Failed tests: 9-11 Non-zero exit status: 2 Parse errors: No plan found in TAP output Files=1, Tests=11, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.08 cusr 0.01 csys = 0.12 CPU) Result: FAIL make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1 make[1]: Leaving directory '/build/mb2md-3.20' make: *** [debian/rules:6: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 (Also reproducible in the reproducible-builds.org log.) -- Daniel Schepler
Bug#912044: libterm-readline-ttytter-perl: FTBFS: Testsuite hangs
at http://www.perl.com/CPAN Or use perl -MCPAN -e shell to reach CPAN. Falling back to 'stty'. If you do not want to see this warning, set PERL_READLINE_NOWARN in your environment. at blib/lib/Term/ReadLine/readline_ttytter.pm line 1815. readline_ttytter::SetTTY() called at blib/lib/Term/ReadLine/readline_ttytter.pm line 1652 eval {...} called at blib/lib/Term/ReadLine/readline_ttytter.pm line 1652 readline_ttytter::readline("Enter arithmetic or Perl expression: ", "exit") called at blib/lib/Term/ReadLine/TTYtter.pm line 9 Term::ReadLine::TTYtter::readline(Term::ReadLine::TTYtter=ARRAY(0x555a07667ad8), "Enter arithmetic or Perl expression: ", "exit") called at test.pl line 63 stty: 'standard input': Inappropriate ioctl for device Cannot call `stty': Inappropriate ioctl for device at blib/lib/Term/ReadLine/readline_ttytter.pm line 1827. at blib/lib/Term/ReadLine/readline_ttytter.pm line 1653. readline_ttytter::readline("Enter arithmetic or Perl expression: ", "exit") called at blib/lib/Term/ReadLine/TTYtter.pm line 9 Term::ReadLine::TTYtter::readline(Term::ReadLine::TTYtter=ARRAY(0x555a07667ad8), "Enter arithmetic or Perl expression: ", "exit") called at test.pl line 63 Enter arithmetic or Perl expression: At this point, the build process hangs and has to be terminated manually. -- Daniel Schepler
Bug#912039: libpetail-utils-perl: FTBFS: Test failures
Source: libpetal-utils-perl Version: 0.06-3 Severity: serious Tags: ftbfs >From my pbuilder build log: ... dh_auto_test dh_auto_test: Compatibility levels before 9 are deprecated (level 8 in use) perl Build test --verbose 1 # Failed test 'use set :default' # at t/01__import.t line 21. # got: 'Can't find Petal plugin: 'Date'! at /build/libpetal-utils-perl-0.06/blib/lib/Petal/Utils.pm line 111. # BEGIN failed--compilation aborted at (eval 13) line 1. # ' # expected: '' # Looks like you failed 1 test of 6. t/01__import.t ... ok 1 - use Petal::Utils ok 2 - use set :none not ok 3 - use set :default ok 4 - use plugin UpperCase ok 5 - error loading non-existent set ok 6 - error loading non-existent plugin 1..6 Dubious, test returned 1 (wstat 256, 0x100) Failed 1/6 subtests t/02__debug.t ok 1 - dump 1..1 ok t/03__text.t . ok 1 - lc ok 2 - uc ok 3 - uc_first 1..3 ok t/04__logic.t ok 1 - first ok 2 - second ok 3 - or ok 4 - and ok 5 - equal ok 6 - like ok 7 - if ok 8 - if 1..8 ok Can't find Petal plugin: 'Date'! at /build/libpetal-utils-perl-0.06/blib/lib/Petal/Utils.pm line 111. BEGIN failed--compilation aborted at t/05__date.t line 15. t/05__date.t . skipped: (no reason given) t/06__list.t . ok 1 - sort 1..1 ok t/07__hash.t . ok 1 - each ok 2 - each ok 3 - each ok 4 - keys ok 5 - keys ok 6 - keys not ok 7 - dkeys # TODO Petal cannot use dynamic hash keys to look up values # Failed (TODO) test 'dkeys' # at t/07__hash.t line 45. # ' # # # # # ekey2 => evalue2ekey3 => evalue3ekey1 => evalue1 # # # # # # kkey3 => kkey2 => kkey1 => # # # # ' # doesn't match '(?^:kkey1 => kvalue1)' 1..7 ok t/08__uri.t .. ok 1 - & ok 2 - ' ' ok 3 - , ok 4 - ; ok 5 - / ok 6 - ? ok 7 - . 1..7 ok t/20__Base.t . ok 1 - split_first_arg - 'first second' ok 2 - split_first_arg - 'first second' ok 3 - split_first_arg - ''first' second' ok 4 - split_first_arg - ''first' second' ok 5 - split_first_arg - 'first second third' ok 6 - split_first_arg - 'first second third' ok 7 - split_first_arg - 'first second third' ok 8 - split_first_arg - ''first' second third fourth' ok 9 - split_first_arg - ''first' second third fourth' ok 10 - split_first_arg - ''first' second third fourth' ok 11 - split_first_arg - ''first' second third fourth' ok 12 - split_first_arg - 'string: first second'' ok 13 - split_first_arg - 'string: first second'' ok 14 - split_args - 'first second' ok 15 - split_args - 'first second' ok 16 - split_args - ''first' second' ok 17 - split_args - ''first' second' ok 18 - split_args - 'first second third' ok 19 - split_args - 'first second third' ok 20 - split_args - 'first second third' ok 21 - split_args - ''first' second third fourth' ok 22 - split_args - ''first' second third fourth' ok 23 - split_args - ''first' second third fourth' ok 24 - split_args - ''first' second third fourth' ok 25 - split_args - 'string: first second' ok 26 - split_args - 'string: first second' ok 27 - split_args - 'string: first second' ok 28 - Fetch value of Dad ok 29 - Fetch plaintext ok 30 - Fetch number ok 31 - Fetch number with decimal 1..31 ok t/21__Limit.t ok 1 - no limit ok 2 - limit 1 ok 3 - limit 2 1..3 ok t/22__Limitr.t ... ok 1 - no limit ok 2 - limit 1 ok 3 - limit 2 1..3 ok t/23__Create_Href.t .. ok 1 - url1 ok 2 - url2 ok 3 - url3 ok 4 - url4 1..4 ok t/24__Substr.t ... ok 1 - substr1 ok 2 - substr2 ok 3 - substr3 ok 4 - substr4 ok 5 - substr4 1..5 ok t/25__Decode.t ... ok 1 - decode1 ok 2 - decode2 ok 3 - decode2a ok 4 - decode2b ok 5 - decode3 - true (1) ok 6 - decode4 - false (0) ok 7 - decode5 - false (false) ok 8 - decode6 ok 9 - decode7 ok 10 - decode8 ok 11 - decode9 ok 12 - decode10 ok 13 - decode11 ok 14 - decode12 ok 15 - decode13 ok 16 - decode14 ok 17 - decode15 1..17 ok t/26__Printf.t ... ok 1 - printf1 ok 2 - printf2 ok 3 - printf3 ok 4 - printf4 ok 5 - printf5 ok 6 - printf6 1..6 ok Test Summary Report --- t/01__import.t (Wstat: 256 Tests: 6 Failed: 1) Failed test: 3 Non-zero exit status: 1 t/05__date.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Files=15, Tests=102, 2 wallclock secs ( 0.06 usr 0.01 sys + 1.16 cusr 0.14 csys = 1.37 CPU) Result: FAIL Failed 2/15 test programs. 1/102 subtests failed. dh_auto_test: perl Build test --verbose 1 returned exit code 255 make: *** [debian/rules:4: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 (Also reproduced on reproducible-builds.org.) -- Daniel Schepler
Bug#912037: ignore-me: FTBFS: Race condition in Making install in src
Source: ignore-me Version: 0.1.2-1 Severity: serious Tags: ftbfs >From my pbuilder build log: ... Making install in src make[2]: Entering directory '/build/ignore-me-0.1.2/src' make[3]: Entering directory '/build/ignore-me-0.1.2/src' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/build/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /bin/mkdir -p '/build/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /usr/bin/install -c -m 644 bzr.mk cvs.mk git.mk hg.mk svn.mk '/build/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /usr/bin/install -c -m 644 bzr.mk cvs.mk git.mk hg.mk svn.mk '/build/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /usr/bin/install: cannot change permissions of '/build/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me/bzr.mk': No such file or directory make[3]: *** [Makefile:372: install-ignoremeDATA] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/build/ignore-me-0.1.2/src' make[2]: *** [Makefile:444: install-am] Error 2 make[2]: Leaving directory '/build/ignore-me-0.1.2/src' make[1]: *** [Makefile:453: install-recursive] Error 1 make[1]: Leaving directory '/build/ignore-me-0.1.2' dh_auto_install: make -j8 install DESTDIR=/build/ignore-me-0.1.2/debian/ignore-me AM_UPDATE_INFO_DIR=no returned exit code 2 make: *** [debian/rules:4: binary] Error 2 The reproducible-builds machines got a similar error: Making install in src make[2]: Entering directory '/build/1st/ignore-me-0.1.2/src' make[3]: Entering directory '/build/1st/ignore-me-0.1.2/src' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /bin/mkdir -p '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /usr/bin/install -c -m 644 bzr.mk cvs.mk git.mk hg.mk svn.mk '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /usr/bin/install -c -m 644 bzr.mk cvs.mk git.mk hg.mk svn.mk '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me' /usr/bin/install: cannot create regular file '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me/bzr.mk': File exists /usr/bin/install: cannot create regular file '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me/cvs.mk': File exists /usr/bin/install: cannot create regular file '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me/git.mk': File exists /usr/bin/install: cannot create regular file '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me/hg.mk': File exists /usr/bin/install: cannot create regular file '/build/1st/ignore-me-0.1.2/debian/ignore-me/usr/share/ignore-me/svn.mk': File exists make[3]: *** [Makefile:351: install-dist_ignoremeDATA] Error 1 -- Daniel Schepler
Bug#910843: jaxb: Rebuilding from source gives broken dependencies
On Fri, Oct 12, 2018 at 6:38 AM Emmanuel Bourg wrote: > > I'm unable to reproduce the issue. libjaxb-java doesn't get a versioned > dependency on libdtd-parser-java. Do you still have the full pbuilder > log please? Unfortunately, I didn't save logs of the manual builds I did in the pbuilder login session. I could probably repeat the process later today and send you the logs then - along with possibly the rebuilt packages from dtd-parser and jaxb for comparison with the current versions in the Debian archive, if that would be useful. I think maybe, I vaguely remember that the pom files installed into /usr/share/maven-repo in the rebuilt libdtd-parser-java package contain tags or something along those lines which aren't there in the archive's version of the package. I'm not sure about that, though. -- Daniel
Bug#910843: jaxb: Rebuilding from source gives broken dependencies
Source: jaxb Version: 2.3.0.1-5 Severity: important To reproduce the error I'm seeing, run this in a pbuilder login session: adduser pbuildd echo 'deb-src http://deb.debian.org/debian sid main' > /etc/apt/source.list.d/debian-src.list apt update apt install eatmydata fakeroot cd /build mkdir dtd-parser cd dtd-parser eatmydata apt build-dep dtd-parser chown -R pbuildd:pbuildd . su pbuildd -c "apt source -b dtd-parser" eatmydata apt install ./*.deb cd .. mkdir jaxb cd jaxb eatmydata apt build-dep jaxb chown -R pbuildd:pbuildd . su pbuildd -c "apt source -b jaxb" eatmydata apt install ./*.deb With which I get the error: The following packages have unmet dependencies: libjaxb-java : Depends: libdtd-parser-java (>= 1.2-SNAPSHOT) but 1.2~svn20110404-1 is to be installed E: Unable to correct problems, you have held broken packages. (I don't really know anything about how the dependency generation works, so I don't really have any idea if this is a bug in src:jaxb, src:dtd-parser, or maybe even in one of the build tools.) -- Daniel Schepler
Bug#905550: pbuilder: Use a cgroup to allow cleaning up stray build processes
As it happens, my patch just caught one of these cases in my local setup to test builds of all packages from the archive. So, I can now provide sample output: make[1]: Leaving directory '/build/fwupd-1.1.0' dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../fwupd_1.1.0-7+bpb1_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build fwupd-1.1.0 dpkg-buildpackage: info: binary-only upload (no source included) I: copying local configuration I: unmounting /var/cache/pbuildd filesystem I: unmounting dev/pts filesystem I: unmounting dev/shm filesystem I: unmounting proc filesystem I: unmounting sys filesystem W: Cleaning up stray processes from build * system-pbuilder-27742.slice Loaded: loaded Active: active since Sun 2018-08-05 16:49:17 PDT; 2min 23s ago Tasks: 1 Memory: 770.5M CGroup: /system.slice/system-pbuilder.slice/system-pbuilder-27742.slice `-run-rf0fc6f2d6b3b45f7b652a09facf17199.scope `-16261 gpg-agent --homedir /tmp/fwupd-self-test/var/lib/fwupd/gnupg --use-standard-socket --daemon Aug 05 16:49:17 frobozz systemd[1]: Created slice system-pbuilder-27742.slice. I: cleaning the build env I: removing directory /build/chroot-amd64/ and its subdirectories I: Current time: Sun Aug 5 16:51:41 PDT 2018 I: pbuilder-time-stamp: 1533513101 -- Daniel Schepler
Bug#905550: pbuilder: Use a cgroup to allow cleaning up stray build processes
Package: pbuilder Version: 0.229.3 Severity: wishlist Tags: patch I've written a small patch which isolates processes from a build into a cgroup (named like system-pbuilder-N.slice where N comes from the pbuilder PID). Then, if it sees after the build is done that there are still stray processes left over, it will print a warning to the log along with a list of these processes, and then kill them. (Of course, this will only work on Linux systems running systemd.) The attached patch is the output of "git diff" against the current contents of https://salsa.debian.org/pbuilder-team/pbuilder.git . -- Daniel diff --git a/debian/changelog b/debian/changelog index 3521bc57..866116d3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,9 @@ pbuilder (0.229.4) UNRELEASED; urgency=medium * WIP. + [ Daniel Schepler ] + * Clean up stray processes from builds on Linux systems running systemd. + -- Mattia Rizzolo Sun, 29 Jul 2018 15:44:12 +0200 pbuilder (0.229.3) unstable; urgency=medium diff --git a/pbuilder-checkparams b/pbuilder-checkparams index f02c88ee..526d1993 100755 --- a/pbuilder-checkparams +++ b/pbuilder-checkparams @@ -83,6 +83,10 @@ while [ -n "$1" ]; do USENETWORK="$2" shift 2 ;; +--use-cgroup) +USECGROUP="$2" +shift 2 +;; --distribution) DISTRIBUTION="$2"; OVERRIDE_APTLINES_WARN=yes @@ -384,6 +388,14 @@ if [ -z "${CHROOTEXEC}" ]; then EATMYDATA=not-available fi fi +if [ "$USECGROUP" = "yes" ]; then +if systemctl is-system-running --quiet >/dev/null 2>&1 ; then +CHROOTEXEC="systemd-run --quiet --scope --slice=system-pbuilder-$$.slice $CHROOTEXEC" +else +log.w "cgroups are not available on the host, not using them." +USECGROUP=not-available +fi +fi fi # handle 'experimental' specially. -- required for raw pbuilder (create/update) only. diff --git a/pbuilder-modules b/pbuilder-modules index e7cad591..ca0037c9 100644 --- a/pbuilder-modules +++ b/pbuilder-modules @@ -529,6 +529,19 @@ function cleanbuildplace () { fi unloadhooks if [ "${INTERNAL_BUILD_UML}" != "yes" ]; then +if [ "${USECGROUP}" = "yes" ]; then +tasks="$(systemctl show system-pbuilder-$$.slice --property=TasksCurrent | tr -d '\n')" +if [ "$tasks" != "TasksCurrent=0" -a "$tasks" != "TasksCurrent=[not set]" ]; then +log.d "Waiting for systemd to register process exits" +sleep 0.1s +tasks="$(systemctl show system-pbuilder-$$.slice --property=TasksCurrent | tr -d '\n')" +if [ "$tasks" != "TasksCurrent=0" -a "$tasks" != "TasksCurrent=[not set]" ]; then +log.w "Cleaning up stray processes from build" +systemctl status system-pbuilder-$$.slice +systemctl stop system-pbuilder-$$.slice +fi +fi +fi if [ -d "$BUILDPLACE" ]; then # A directory on the same partition as $BUILDPLACE, bind-mounted # into $BUILDPLACE, will be cleaned out by clean_subdirectories diff --git a/pbuilderrc b/pbuilderrc index bcd1d883..d0513c55 100644 --- a/pbuilderrc +++ b/pbuilderrc @@ -33,6 +33,7 @@ USEDEVFS=no USEDEVPTS=yes USESYSFS=yes USENETWORK=no +USECGROUP=yes BUILDRESULT=/var/cache/pbuilder/result/ # specifying the distribution forces the distribution on "pbuilder update" diff --git a/pbuilderrc.5 b/pbuilderrc.5 index 05b907ab..1c597e61 100644 --- a/pbuilderrc.5 +++ b/pbuilderrc.5 @@ -481,6 +481,13 @@ Network is not available on a Debian buildd, so you might want to keep the default. Disabling network access currently only works on Linux. .TP +.BI "USECGROUP=" "yes" +Specify +.B yes +to use a cgroup to isolate build processes, so that any stray processes +from the build can be cleaned up afterwords. +This currently only works on Linux systems running systemd. +.TP .BI "USESHM=" "yes" Specify .B yes
Bug#902570: asm: Package rebuilt from source gets lots of empty jars
Source: asm Version: 6.0-1 Severity: serious When I build src:asm using pbuilder, the build completes without errors. However, then the generated deb file contains mostly empty jars - the only one with any real contents is asm-debug-all-6.0.jar. -- Daniel Schepler
Bug#896011: expat: Make source package bootstrappable
Source: expat Version: 2.2.5-3 Severity: wishlist The expat source package is involved in a build dependency cycle: expat Build-Depends on docbook2x docbook2x Depends on libxml-sax-expat-perl libxml-sax-expat-perl Depends on libxml-parser-perl libxml-parser-perl Depends on libexpat1 It would be good if you could provide a build profile to be able to bootstrap without docbook2x being installable. -- Daniel Schepler
Bug#895339: libbpp-phyl: FTBFS: Could not find compatible version of bpp-seq
Source: libbpp-phyl Version: 2.3.2-2 Severity: serious >From my pbuilder build log: ... debian/rules build dh build dh_update_autotools_config dh_autoreconf dh_auto_configure cd obj-x86_64-linux-gnu && cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -- The CXX compiler identification is GNU 7.3.0 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Error at CMakeLists.txt:56 (find_package): Could not find a configuration file for package "bpp-seq" that is compatible with requested version "11.0.0". The following configuration files were considered but not accepted: /usr/lib/x86_64-linux-gnu/cmake/bpp-seq/bpp-seq-config.cmake, version: 12.0.0 -- Configuring incomplete, errors occurred! See also "/build/libbpp-phyl-2.3.2/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log". cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt ... dh_auto_configure: cd obj-x86_64-linux-gnu && cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" returned exit code 1 make: *** [debian/rules:8: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Daniel Schepler
Bug#894565: vim: FTBFS: Test failures if build user cannot open /dev/stdout
On Mon, Apr 2, 2018 at 7:21 PM, James McCoy wrote: > Why is /dev/stdout missing? It's possible one of the attached patches > will work around that issue, but I'm more curious why that's happening > in the first place. /dev/stdout is present in the chroot. However, in my setup, stdout is a pipe to a "tee" process, and the pipe is owned by root so the build user can't access it through /dev/stdout. I'd imagine much the same must be true in the reproducible-builds environment. (Of course, then I have no clue how it's working at all on the buildd's.) -- Daniel
Bug#894565: vim: FTBFS: Test failures if build user cannot open /dev/stdout
Source: vim Version: 2:8.0.1453-1 Severity: serious >From >https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/vim.html (and I'm also seeing pretty much the same failure under pbuilder): ... Executing Test_z() Executing Test_z_negative_lnum() Executing Test_z_overflow() Executed 345 tests >From test_writefile.vim: Found errors in Test_writefile_sync_dev_stdout(): Caught exception in Test_writefile_sync_dev_stdout(): Vim(call):E482: Can't create file /dev/stdout @ function RunTheTest[38]..Test_writefile_sync_dev_stdout, line 5 Test results: >From test_writefile.vim: Found errors in Test_writefile_sync_dev_stdout(): Caught exception in Test_writefile_sync_dev_stdout(): Vim(call):E482: Can't create file /dev/stdout @ function RunTheTest[38]..Test_writefile_sync_dev_stdout, line 5 TEST FAILURE make[2]: *** [Makefile:42: report] Error 1 make[2]: Leaving directory '/build/1st/vim-8.0.1453/src/vim-basic/testdir' make[1]: *** [Makefile:2069: scripttests] Error 2 make[1]: Leaving directory '/build/1st/vim-8.0.1453/src/vim-basic' make: *** [debian/rules:272: build-stamp-vim-basic] Error 2 rm configure-stamp-vim-basic dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
Bug#893322: node-glob: Package built in nocheck build profile is broken
Source: node-glob Version: 7.1.2-4 Severity: normal When building node-glob with DEB_BUILD_PROFILES=nocheck it appears the resulting package is missing a dependency on node-fs.realpath. However, the module itself does still require fs.realpath, so this makes no sense, and it breaks builds of other packages if they Build-Depend on node-glob (either directly or indirectly). -- Daniel
Bug#893067: libinput-dev: pkg-config file does not work without libwacom-dev installed
Package: libinput-dev Version: 1.10.3-1 Severity: important Justification: causing numerous new FTBFS bugs In a clean pbuilder chroot: # apt install libinput-dev pkg-config # pkg-config --cflags libinput Package libwacom was not found in the pkg-config search path. Perhaps you should add the directory containing 'libwacom.pc' to the PKG_CONFIG_PATH environment variable Package 'libwacom', required by 'libinput', not found # pkg-config --exists libinput # echo $? 1 I've been seeing several new FTBFS issues in other packages due to this, either due to configure scripts erroring out when they find libinput "does not exist", or in the case of qtbase-opensource-src, the configuration leaves out the libinput plugin which then causes an error at dh_install time. -- Daniel
Bug#887902: qtwebchannel-opensource-src: FTBFS with cmake installed
On Tue, Feb 20, 2018 at 2:47 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > As far as I see this bug could be "please add cmake to Build-Conflicts", but > in that case policy says a package *can* declare relationships (policy 7.7). Well, that would be one possible solution, but IMO the least preferred solution, as I consider Build-Conflicts the option of last resort. Other options, of course, would be to fix the test case (best), or either skip the test or ignore failures (middle). (And then if the test case is fixed, it would certainly make sense to add "Build-Depends: cmake ".) > I don't see anything that justifies it to be RC. I'm so downgrading the > severity. > > If I missed something in policy, please do not heasitate to reply (but not > increasing the severity until we check it). Well, I guess https://release.debian.org/buster/rc_policy.txt doesn't explicitly state this: - 4. Autobuilding Packages must list any packages they require to build beyond those that are "build-essential" in the appropriate Build-Depends: fields. ... Packages must autobuild without failure on all architectures on which they are supported. ... - But still, my interpretation of the spirit is that the Build-Depends and Build-Conflicts together have to be sufficient to ensure the package builds both successfully and correctly. And that there's no requirement that everybody building it must necessarily be using a minimal chroot, or even any chroot at all. (Otherwise, what would the purpose of Build-Conflicts be in the first place?) -- Daniel Schepler
Bug#890811: lynx: FTBFS: msgfmt errors
kefile:129: cs.gmo] Error 1 .pass2.tmp:470: duplicate message definition... pass2.tmp:366: ...this is the location of the first definition pass2.tmp:474: duplicate message definition... pass2.tmp:370: ...this is the location of the first definition pass2.tmp:478: duplicate message definition... pass2.tmp:374: ...this is the location of the first definition pass2.tmp:482: duplicate message definition... pass2.tmp:378: ...this is the location of the first definition pass2.tmp:487: duplicate message definition... pass2.tmp:383: ...this is the location of the first definition pass2.tmp:492: duplicate message definition... pass2.tmp:388: ...this is the location of the first definition pass2.tmp:497: duplicate message definition... pass2.tmp:393: ...this is the location of the first definition pass2.tmp:502: duplicate message definition... pass2.tmp:398: ...this is the location of the first definition pass2.tmp:507: duplicate message definition... pass2.tmp:403: ...this is the location of the first definition pass2.tmp:512: duplicate message definition... pass2.tmp:408: ...this is the location of the first definition pass2.tmp:516: duplicate message definition... pass2.tmp:412: ...this is the location of the first definition pass2.tmp:521: duplicate message definition... pass2.tmp:417: ...this is the location of the first definition pass2.tmp:527: duplicate message definition... pass2.tmp:423: ...this is the location of the first definition pass2.tmp:531: duplicate message definition... pass2.tmp:427: ...this is the location of the first definition pass2.tmp:536: duplicate message definition... pass2.tmp:432: ...this is the location of the first definition pass2.tmp:541: duplicate message definition... pass2.tmp:437: ...this is the location of the first definition pass2.tmp:547: duplicate message definition... pass2.tmp:443: ...this is the location of the first definition pass2.tmp:552: duplicate message definition... pass2.tmp:449: ...this is the location of the first definition pass2.tmp:557: duplicate message definition... pass2.tmp:457: ...this is the location of the first definition pass2.tmp:563: duplicate message definition... pass2.tmp:465: ...this is the location of the first definition . done. pass2.tmp:1204: end-of-file within string /usr/bin/msgfmt: too many errors, aborting ..make[2]: *** [makefile:129: de.gmo] Error 1 ... done. ... done. .. done. ...merged against ./lynx.pot file=./`echo et | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH /usr/bin/msgfmt -o $file pass2.tmp ...merged against ./lynx.pot file=./`echo fr | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH /usr/bin/msgfmt -o $file pass2.tmp ...merged against ./lynx.pot file=./`echo da | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH /usr/bin/msgfmt -o $file pass2.tmp ...merged against ./lynx.pot file=./`echo eo | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH /usr/bin/msgfmt -o $file pass2.tmp /usr/bin/msgfmt: error while opening "pass2.tmp" for reading: No such file or directory make[2]: *** [makefile:127: eo.gmo] Error 1 ...merged against ./lynx.pot file=./`echo fi | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH /usr/bin/msgfmt -o $file pass2.tmp /usr/bin/msgfmt: error while opening "pass2.tmp" for reading: No such file or directory make[2]: *** [makefile:129: fi.gmo] Error 1 make[2]: Leaving directory '/build/lynx-2.8.9dev16/po' make[1]: *** [makefile:218: all] Error 2 make[1]: Leaving directory '/build/lynx-2.8.9dev16' dh_auto_build: make -j8 returned exit code 2 make: *** [debian/rules:55: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
Bug#889176: bc: Exhausts process table during build
Source: bc Version: 1.07.1-1 Severity: important I just noticed that on building bc, it hangs for quite a while at the point where it's calling "dh_auto_install". Top shows that eventually it's creating an infinite chain of processes "make global.o" and the build only succeeds once these processes have filled the process table. Given that, it probably makes sense to just skip trying to run "dh_auto_install", and instead provide an "override_dh_auto_install" which runs the "make install" manually. (Unless you can determine that there's a bug in either the bc Makefile, or in dh_auto_install, that you can fix.) -- Daniel Schepler
Bug#888861: schroot: Add operation mode running chroot image as systemd container
Package: schroot Version: 1.6.10-4 Severity: wishlist After seeing the capabilities of systemd-run and systemd-nspawn, I wonder if it would make sense to be able to configure an schroot to use these facilities. That would have the advantage of being able to provide greater sandboxing - for example, it would be possible to have stray processes from each command in an schroot session be cleaned up after the individual commands, and in fact that's the default operation mode of systemd-run. (The disadvantage would be a few extra processes in the container, and the fact that the chroot image would have to have at least systemd and dbus installed to support sessions.) So, roughly what I'm thinking is: Session start: "systemd-nspawn -b -D /path/to/chroot" or "machinectl start " and then possibly "machinectl bind /path/to/bindpoint" Session execute command: "systemd-run --machine --pipe " Session end: "machinectl stop " Single-command session: "systemd-nspawn -D /path/to/chroot " And if schroot also provided a mechanism to pass extra properties for the transient service to the systemd-run command, then I imagine sbuild being able to run something like: # run apt build-dep with network access schroot -c apt build-dep pkg # run dpkg-buildpackage without network access, only lo interface schroot -c --user=sbuild --systemd-property PrivateNetwork=yes -d /build/pkg dpkg-buildpackage -b -uc At this point, I'm not sure whether it makes sense or not to incorporate this into schroot, or how much work it would be. It would still be nice, though, to have an integration of schroot's capabilities to unpack/update tar files, create LVM snapshots, etc. with systemd's sandbox functionality. (Or some similar sandbox functionality, though I wouldn't see much point in reproducing all that.) -- Daniel Schepler
Bug#888519: python-cliff: FTBFS: Test failures
Source: python-cliff Version: 2.8.0-3 Severity: serious >From my pbuilder build log (on amd64): ... cliff.tests.test_utils.TestTerminalWidth.test cliff.tests.test_utils.TestTerminalWidth.test ... ok cliff.tests.test_utils.TestTerminalWidth.test_get_terminal_size cliff.tests.test_utils.TestTerminalWidth.test_get_terminal_size ... skipped u'only needed for python 3.3 onwards' cliff.tests.test_utils.TestTerminalWidth.test_ioctl cliff.tests.test_utils.TestTerminalWidth.test_ioctl ... ok cliff.tests.test_utils.TestTerminalWidth.test_windows cliff.tests.test_utils.TestTerminalWidth.test_windows ... ok == FAIL: cliff.tests.test_app.TestInteractiveMode.test_interactive_mode_cmdloop cliff.tests.test_app.TestInteractiveMode.test_interactive_mode_cmdloop -- _StringException: Traceback (most recent call last): File "cliff/tests/test_app.py", line 77, in test_interactive_mode_cmdloop app.run([]) File "cliff/app.py", line 277, in run result = self.interact() File "cliff/app.py", line 316, in interact from .interactive import InteractiveApp File "cliff/interactive.py", line 20, in import cmd2 File "/usr/lib/python2.7/dist-packages/cmd2.py", line 333, in except pyperclip.exceptions.PyperclipException: AttributeError: 'module' object has no attribute 'exceptions' == FAIL: unittest2.loader._FailedTest.cliff.tests.test_interactive unittest2.loader._FailedTest.cliff.tests.test_interactive -- _StringException: Traceback (most recent call last): ImportError: Failed to import test module: cliff.tests.test_interactive Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in _get_module_from_name __import__(name) File "cliff/tests/test_interactive.py", line 15, in import cmd2 File "/usr/lib/python2.7/dist-packages/cmd2.py", line 333, in except pyperclip.exceptions.PyperclipException: AttributeError: 'module' object has no attribute 'exceptions' -- Ran 151 tests in 1.026s FAILED (failures=2, skipped=1) debian/rules:35: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/build/python-cliff-2.8.0' debian/rules:8: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Daniel Schepler
Bug#887930: html-xml-utils: FTBFS with netcat-traditional installed (testsuite hangs in extract1.sh)
Source: html-xml-utils Version: 7.5-1 Severity: serious Recently, while rebuilding a bunch of packages in a chroot without pbuilder, I discovered the following failure: ... PASS: tests/xmlasc7.sh PASS: tests/xmlasc4.sh PASS: tests/xref3.sh PASS: tests/xref1.sh PASS: tests/xmlns1.sh PASS: tests/xref5.sh PASS: tests/xref4.sh PASS: tests/xref2.sh PASS: tests/xref6.sh PASS: tests/xref7.sh At this point, the build hangs, and a "ps" shows a bunch of "nc" processes as children of "/bin/sh ./tests/extract1.sh". At this point, I have to terminate the build manually. I was subsequently able to reproduce this using "pbuilder build --extrapackages netcat-traditional html-xml-utils_7.5-1.dsc". (By the way, I've been seeing the same thing in all the recent uploads, starting with version 7.1-1 - though 7.5-1 is the only version for which I've tried reproducing the issue with pbuilder.) -- Daniel Schepler
Bug#887902: qtwebchannel-opensource-src: FTBFS with cmake installed
ource-src-5.9.2' dh_auto_test: make -j1 check QT_QPA_PLATFORM=minimal QML2_IMPORT_PATH=/build/qtwebchannel-opensource-src-5.9.2/test_root/usr/lib/x86_64-linux-gnu/qt5/qml returned exit code 2 debian/rules:52: recipe for target 'override_dh_auto_test-arch' failed make[1]: *** [override_dh_auto_test-arch] Error 2 make[1]: Leaving directory '/build/qtwebchannel-opensource-src-5.9.2' debian/rules:15: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 I've subsequently been able to reproduce it with "pbuilder build --extrapackages cmake qtwebchannel-opensource-src_5.9.2-3.dsc". -- Daniel Schepler
Bug#887898: graphviz: FTBFS with libgs-dev installed
] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 I have subsequently been able to reproduce it with "pbuilder build graphviz_2.38.0-18.dsc --extrapackages libgs-dev". Fortunately, it appears that just adding "--without-ghostscript" to the configure command line in debian/rules will be sufficient to fix this, so no need for an ugly Build-Conflicts. -- Daniel Schepler
Bug#887673: graphviz: Drop dependency on libgnomeui
Source: graphviz Version: 2.38.0-18 Severity: normal X-Debbugs-Cc: 885767-submit...@bugs.debian.org According to #885767 , libgnomeui is slated for removal from sid and buster. So, it would be great to have src:libgnomeui drop the Build-Depends on libgnomeui-dev (and the corresponding dependencies of binary packages, if any - though I didn't notice any of the src:graphviz packages showing up in my quick scan of the output of "apt-cache showpkg libgnomeui-0"). -- Daniel Schepler
Bug#887655: mariadb-10.1: FTBFS with liblz4-dev installed
Source: mariadb-10.1 Version: 1:10.1.29-6 Severity: serious >From my pbuilder build log: ... -- Looking for compress in z -- Looking for compress in z - found -- Checking for module 'liblz4' -- Found liblz4, version 131 -- Checking for module 'kytea' -- No package 'kytea' found ... CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: LZ4_LIBS linked by target "libgroonga" in directory /home/daniel/src/debian/mariadb-10.1/mariadb-10.1-10.1.29/storage/mroonga/vendor/groonga/lib -- Configuring incomplete, errors occured! See also "/home/daniel/src/debian/mariadb-10.1/mariadb-10.1-10.1.29/builddir/CMakeFiles/CMakeOutput.log". See also "/home/daniel/src/debian/mariadb-10.1/mariadb-10.1-10.1.29/builddir/CMakeFiles/CMakeError.log". debian/rules:73: recipe for target 'override_dh_auto_configure' failed make[1]: *** [override_dh_auto_configure] Error 1 make[1]: Leaving directory '/home/daniel/src/debian/mariadb-10.1/mariadb-10.1-10.1.29' debian/rules:177: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Removing liblz4-dev seems to work around the issue. -- Daniel Schepler
Bug#887482: xorg-server: FTBFS: dh_autoreconf can only be run once
Source: xorg-server Version: 2:1.19.5-1 Severity: serious >From my pbuilder build log: ... make[6]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb/test/xi2' make[5]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb/test' make[4]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb/test' make[4]: Entering directory '/build/xorg-server-1.19.5/debian/build/udeb' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb' make[3]: Leaving directory '/build/xorg-server-1.19.5/debian/build/udeb' make[2]: Leaving directory '/build/xorg-server-1.19.5' debian/rules override_dh_auto_test make[2]: Entering directory '/build/xorg-server-1.19.5' dh_auto_test -- -j1 VERBOSE=1 make[2]: Leaving directory '/build/xorg-server-1.19.5' make[1]: Leaving directory '/build/xorg-server-1.19.5' dh_quilt_patch -O--parallel -Nxserver-common -Nxorg-server-source File series fully applied, ends at patch 06_use-intel-only-on-pre-gen4.diff dh_update_autotools_config -O--parallel -Nxserver-common -Nxorg-server-source dh_autoreconf -O--parallel -Nxserver-common -Nxorg-server-source dh_autoreconf: Can only be run once, see dh-autoreconf(7) debian/rules:8: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 On further testing, it seems that on a freshly unpacked source, either "dpkg-buildpackage -B" or "dpkg-buildpackage -A" separately will work; but "dpkg-buildpackage -b" will fail with the above error. -- Daniel Schepler
Bug#886901: base-files: FTBFS: cannot remove '/etc/debian_version'
On Thu, Jan 11, 2018 at 1:41 AM, Santiago Vila wrote: > Also: Is this the kind of FTBFS bug that should be fixed in stable? > (I think maybe not because it does not happen in autobuilders, > as they do dpkg-buildpackage). As far as I know, there shouldn't be any need for an upload to stable. This built successfully for me with basically the same setup earlier, on Sep 20 (from sid, with debhelper version at the time = 10.9). So, I'm guessing there might have been some debhelper changes since then which broke a build that previously happened to work. (And yes, I do use "dpkg-buildpackage -b -uc" in my builds through pbuilder, whereas buildds use "dpkg-buildpackage -B ...". It seems dpkg-buildpackage -B still works on the package in current sid. -- Daniel Schepler
Bug#886903: gpm: FTBFS: undefined reference to `__sigemptyset'
Source: gpm Version: 1.20.4-6.2 Severity: serious >From my pbuilder build log: ... gcc -I. -I/build/gpm-1.20.4/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR="\"/etc\"" -DSBINDIR="\"/usr/sbin\"" -Wall -g -D_REENTRANT -O2 -Wall -g -D_REENTRANT -O2 -c -o prog/gpm-root.o prog/gpm-root.c /build/gpm-1.20.4/src/prog/gpm-root.y: In function 'scr_restore': /build/gpm-1.20.4/src/prog/gpm-root.y:963:10: warning: variable 'y' set but not used [-Wunused-but-set-variable] int x,y, dumpfd; ^ /build/gpm-1.20.4/src/prog/gpm-root.y:963:8: warning: variable 'x' set but not used [-Wunused-but-set-variable] int x,y, dumpfd; ^ /build/gpm-1.20.4/src/prog/gpm-root.y: In function 'postmenu': /build/gpm-1.20.4/src/prog/gpm-root.y:1030:32: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] #define PUTS(s,f,b) for(curr2=s;*curr2;PUTC(*(curr2++),f,b)) ^ /build/gpm-1.20.4/src/prog/gpm-root.y:1045:10: note: in expansion of macro 'PUTS' PUTS(draw->title,draw->head,draw->back); ^~~~ /build/gpm-1.20.4/src/prog/gpm-root.y:1030:32: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] #define PUTS(s,f,b) for(curr2=s;*curr2;PUTC(*(curr2++),f,b)) ^ /build/gpm-1.20.4/src/prog/gpm-root.y:1053:10: note: in expansion of macro 'PUTS' PUTS(item->name,draw->fore,draw->back); i+=strlen(item->name); ^~~~ /build/gpm-1.20.4/src/prog/gpm-root.y: In function 'main': /build/gpm-1.20.4/src/prog/gpm-root.y:1200:4: warning: implicit declaration of function '__sigemptyset'; did you mean 'sigemptyset'? [-Wimplicit-function-declaration] __sigemptyset(&childaction.sa_mask); ^ sigemptyset At top level: /build/gpm-1.20.4/src/prog/gpm-root.y:446:12: warning: 'f_debug_one' defined but not used [-Wunused-function] static int f_debug_one(FILE *f, Draw *draw) ^~~ gcc -L/build/gpm-1.20.4/src -o prog/gpm-root prog/gpm-root.o lib/libgpm.so.2 prog/gpm-root.o: In function `main': /build/gpm-1.20.4/src/prog/gpm-root.y:1200: undefined reference to `__sigemptyset' collect2: error: ld returned 1 exit status Makefile:151: recipe for target 'prog/gpm-root' failed make[2]: *** [prog/gpm-root] Error 1 rm prog/display-coords.o prog/hltest.o prog/mev.o prog/disable-paste.o prog/display-buttons.o make[2]: Leaving directory '/build/gpm-1.20.4/src' Makefile:62: recipe for target 'do-all' failed make[1]: *** [do-all] Error 1 make[1]: Leaving directory '/build/gpm-1.20.4' debian/rules:46: recipe for target 'build-arch' failed make: *** [build-arch] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Daniel Schepler
Bug#886901: base-files: FTBFS: cannot remove '/etc/debian_version'
Source: base-files Version: 10 Severity: serious >From my pbuilder build log: ... debian/rules build dh build dh_update_autotools_config debian/rules override_dh_auto_build make[1]: Entering directory '/build/base-files-10' sh debian/check-md5sum-etc profile sed -e "s&#OSNAME#&"GNU/`uname | sed -e 's/GNU\///'`"&g" debian/copyright.in > debian/copyright sed -e "s/#VENDORFILE#/debian/g" debian/postinst.in > debian/postinst make[1]: Leaving directory '/build/base-files-10' fakeroot debian/rules binary dh binary debian/rules install make[1]: Entering directory '/build/base-files-10' install -p -m 644 etc/* /etc install: cannot remove '/etc/debian_version': Permission denied install: cannot remove '/etc/host.conf': Permission denied install: cannot remove '/etc/issue': Permission denied install: cannot remove '/etc/issue.net': Permission denied install: cannot remove '/etc/os-release': Permission denied debian/rules:39: recipe for target 'install' failed make[1]: *** [install] Error 1 make[1]: Leaving directory '/build/base-files-10' debian/rules:14: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
Bug#884750: happy: stage1 build profile FTBFS
Source: happy Version: 1.19.8-1 Severity: normal >From my pbuilder build log, trying to bootstrap the package with a tsage1 build profile: ... fakeroot debian/rules clean CDBS WARNING: copyright-check disabled - touch debian/copyright_hints to enable. test -x debian/rules cp -a dist/build/happy/happy-tmp/*.hs src/ cp: cannot stat 'dist/build/happy/happy-tmp/*.hs': No such file or directory debian/rules:20: recipe for target 'cleanbuilddir/happy' failed make: *** [cleanbuilddir/happy] Error 1 dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2 -- Daniel Schepler
Bug#883095: phonon: FTBFS: Cannot find QtCore/qfeatures.h
ty=hidden -fvisibility-inlines-hidden -fPIC -std=gnu++11 -o CMakeFiles/phonon4qt5.dir/abstractvideooutput.cpp.o -c /build/phonon-4.9.0/phonon/abstractvideooutput.cpp [ 12%] Building CXX object phonon/CMakeFiles/phonon4qt5.dir/audiooutputinterface.cpp.o cd /build/phonon-4.9.0/build-qt5/phonon && /usr/bin/c++ -DHAVE_PULSEAUDIO -DMAKE_PHONON_LIB -DPHONON_ASSERT_STATES -DPHONON_BACKEND_DIR_SUFFIX=\"/phonon4qt5_backend/\" -DPHONON_BUILD_WITH_CMAKE -DPHONON_LIBRARY_PATH=\"/usr/lib/x86_64-linux-gnu/qt5/plugins\" -DPHONON_NO_GRAPHICSVIEW -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/build/phonon-4.9.0/build-qt5/phonon -I/build/phonon-4.9.0/phonon -I/build/phonon-4.9.0/build-qt5/phonon/phonon4qt5_autogen/include -I/build/phonon-4.9.0 -I/build/phonon-4.9.0/includes -I/build/phonon-4.9.0/build-qt5/includes/phonon -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem /usr/include/x86_64-linux-gnu/qt5/QtDBus -g -O2 -fdebug-prefix-map=/build/phonon-4.9.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -std=gnu++11 -o CMakeFiles/phonon4qt5.dir/audiooutputinterface.cpp.o -c /build/phonon-4.9.0/phonon/audiooutputinterface.cpp In file included from /build/phonon-4.9.0/phonon/audiooutput_p.h:28:0, from /build/phonon-4.9.0/phonon/audiooutput.cpp:23: /build/phonon-4.9.0/build-qt5/phonon/phononconfig_p.h:6:10: fatal error: QtCore/qfeatures.h: No such file or directory #include ^~~~ compilation terminated. phonon/CMakeFiles/phonon4qt5.dir/build.make:209: recipe for target 'phonon/CMakeFiles/phonon4qt5.dir/audiooutput.cpp.o' failed make[5]: *** [phonon/CMakeFiles/phonon4qt5.dir/audiooutput.cpp.o] Error 1 make[5]: *** Waiting for unfinished jobs make[5]: Leaving directory '/build/phonon-4.9.0/build-qt5' CMakeFiles/Makefile2:262: recipe for target 'phonon/CMakeFiles/phonon4qt5.dir/all' failed make[4]: *** [phonon/CMakeFiles/phonon4qt5.dir/all] Error 2 make[4]: Leaving directory '/build/phonon-4.9.0/build-qt5' Makefile:143: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/build/phonon-4.9.0/build-qt5' dh_auto_build: cd build-qt5 && make -j8 returned exit code 2 debian/rules:21: recipe for target 'override_dh_auto_build' failed make[2]: *** [override_dh_auto_build] Error 2 make[2]: Leaving directory '/build/phonon-4.9.0' /usr/share/pkg-kde-tools/qt-kde-team/2/dhmk.mk:97: recipe for target 'pre_build_dh_auto_build' failed make[1]: *** [pre_build_dh_auto_build] Error 2 make[1]: Leaving directory '/build/phonon-4.9.0' /usr/share/pkg-kde-tools/qt-kde-team/2/dhmk.mk:110: recipe for target 'debian/dhmk_build' failed make: *** [debian/dhmk_build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Daniel Schepler
Bug#883093: srtp: FTBFS with alternatives to doxygen-latex installed
hare/texlive/texmf-dist/tex/latex/listings/listings.cfg)) (/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty (/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg)) (/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty) (/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty (/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg) (/usr/share/texlive/texmf-dist/tex/latex/colortbl/colortbl.sty (/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty))) (/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty (/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def)) (/usr/share/texlive/texmf-dist/tex/latex/base/alltt.sty) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty)) (/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty) (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/auxhook.sty) (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def) (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/hyperref.cfg) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/backref.sty (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty)) (/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)) Package hyperref Message: Driver: hpdftex. (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def) (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty (/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def (/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu))) (/usr/share/texlive/texmf-dist/tex/latex/psnfss/mathptmx.sty) (/usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty) (/usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty) ! LaTeX Error: File `sectsty.sty' not found. Type X to quit or to proceed, or enter new name. (Default extension: sty) Enter file name: ! Emergency stop. l.41 \usepackage [titles]{tocloft}^^M ! ==> Fatal error occurred, no output PDF file produced! Transcript written on refman.log. Makefile:6: recipe for target 'refman.pdf' failed make[3]: *** [refman.pdf] Error 1 make[3]: Leaving directory '/build/srtp-1.4.5~20130609~dfsg/doc/latex' Makefile:24: recipe for target 'libsrtpdoc' failed make[2]: *** [libsrtpdoc] Error 2 make[2]: Leaving directory '/build/srtp-1.4.5~20130609~dfsg/doc' Makefile:192: recipe for target 'libsrtpdoc' failed make[1]: *** [libsrtpdoc] Error 2 make[1]: Leaving directory '/build/srtp-1.4.5~20130609~dfsg' debian/rules:80: recipe for target 'build/srtp-docs' failed make: *** [build/srtp-docs] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Daniel Schepler
Bug#882193: xauth: FTBFS under pbuilder with output redirected
Source: xauth Version: 1:1.0.9-1 Severity: important >From my pbuilder build log, with stdout redirected to a pipe into "tee .../build-log-amd64": ... debian/rules override_dh_auto_test make[1]: Entering directory '/build/xauth-1.0.9' dh_auto_test -- VERBOSE=1 dh_auto_test: Compatibility levels before 9 are deprecated (level 8 in use) cd build && make -j1 check VERBOSE=1 VERBOSE=1 make[2]: Entering directory '/build/xauth-1.0.9/build' Making check in man make[3]: Entering directory '/build/xauth-1.0.9/build/man' make[3]: Nothing to be done for 'check'. make[3]: Leaving directory '/build/xauth-1.0.9/build/man' Making check in tests make[3]: Entering directory '/build/xauth-1.0.9/build/tests' make test_xauth make[4]: Entering directory '/build/xauth-1.0.9/build/tests' gcc -DHAVE_CONFIG_H -I. -I../../tests -I.. -g -O2 -c -o test_xauth.o ../../tests/test_xauth.c gcc -g -O2 -o test_xauth test_xauth.o make[4]: Leaving directory '/build/xauth-1.0.9/build/tests' make check-TESTS make[4]: Entering directory '/build/xauth-1.0.9/build/tests' make[5]: Entering directory '/build/xauth-1.0.9/build/tests' FAIL: test_xauth === xauth 1.0.9: tests/test-suite.log === # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_xauth Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run self.process_args(args) File "/usr/bin/cmdtest", line 64, in process_args self.setup_ttystatus(td) File "/usr/bin/cmdtest", line 105, in setup_ttystatus self.ts = ttystatus.TerminalStatus(period=0.001) File "/usr/lib/python2.7/dist-packages/ttystatus/status.py", line 37, in __init__ period=period, _terminal=_terminal) File "/usr/lib/python2.7/dist-packages/ttystatus/messager.py", line 45, in __init__ self._terminal.open_tty() File "/usr/lib/python2.7/dist-packages/ttystatus/tty.py", line 36, in open_tty curses.setupterm(None, self._terminal.fileno()) error: setupterm: could not find terminal FAIL test_xauth (exit status: 1) Testsuite summary for xauth 1.0.9 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See tests/test-suite.log Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg Makefile:628: recipe for target 'test-suite.log' failed make[5]: *** [test-suite.log] Error 1 make[5]: Leaving directory '/build/xauth-1.0.9/build/tests' Makefile:734: recipe for target 'check-TESTS' failed make[4]: *** [check-TESTS] Error 2 make[4]: Leaving directory '/build/xauth-1.0.9/build/tests' Makefile:807: recipe for target 'check-am' failed make[3]: *** [check-am] Error 2 make[3]: Leaving directory '/build/xauth-1.0.9/build/tests' Makefile:521: recipe for target 'check-recursive' failed make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory '/build/xauth-1.0.9/build' dh_auto_test: cd build && make -j1 check VERBOSE=1 VERBOSE=1 returned exit code 2 debian/rules:12: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 2 make[1]: Leaving directory '/build/xauth-1.0.9' debian/rules:18: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Daniel Schepler
Bug#882151: apt is having trouble resolving dependencies of libgtk-3-dev in sid
On Sun, Nov 19, 2017 at 9:37 AM, Julian Andres Klode wrote: > Could you please provide the appropriate debugging output: > > ### Dependency resolution > > APT works in its internal resolver in two stages: First all packages are > visited > and marked for installation, keep back or removal. Option > `Debug::pkgDepCache::Marker` > shows this. This also decides which packages are to be installed to satisfy > dependencies, > which can be seen by `Debug::pkgDepCache::AutoInstall`. After this is done, > we might > be in a situation in which two packages want to be installed, but only on of > them can be. > It is the job of the pkgProblemResolver to decide which of two packages > 'wins' and can > therefore decide what has to happen. You can see the contenders as well as > their fight and > the resulting resolution with `Debug::pkgProblemResolver`. OK, attaching the results of "apt -o Debug::pkgDepCache::Marker=1 -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1 install libgtk-3-dev". -- Daniel Schepler WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Reading package lists... Building dependency tree... Reading state information... MarkInstall libgtk-3-dev:amd64 < none -> 3.22.26-1 @un puN Ib > FU=1 Installing libgtk-3-0 as Depends of libgtk-3-dev MarkInstall libgtk-3-0:amd64 < none -> 3.22.26-1 @un uN Ib > FU=0 Installing libgtk-3-common as Depends of libgtk-3-0 MarkInstall libgtk-3-common:amd64 < none -> 3.22.26-1 @un uN Ib > FU=0 Installing dconf-gsettings-backend as Depends of libgtk-3-common MarkInstall dconf-gsettings-backend:amd64 < none -> 0.26.1-1 @un uN Ib > FU=0 Installing libglib2.0-0 as Depends of dconf-gsettings-backend MarkInstall libglib2.0-0:amd64 < none -> 2.54.2-1 @un uN > FU=0 Installing dconf-service as Depends of dconf-gsettings-backend MarkInstall dconf-service:amd64 < none -> 0.26.1-1 @un uN Ib > FU=0 Installing libdconf1 as Depends of dconf-service MarkInstall libdconf1:amd64 < none -> 0.26.1-1 @un uN > FU=0 Installing dbus-user-session as Depends of dconf-service MarkInstall dbus-user-session:amd64 < none -> 1.12.2-1 @un uN Ib > FU=0 Installing dbus as Depends of dbus-user-session MarkInstall dbus:amd64 < none -> 1.12.2-1 @un uN Ib > FU=0 Installing libapparmor1 as Depends of dbus MarkInstall libapparmor1:amd64 < none -> 2.11.1-3 @un uN > FU=0 Installing libdbus-1-3 as Depends of dbus MarkInstall libdbus-1-3:amd64 < none -> 1.12.2-1 @un uN > FU=0 Installing libexpat1 as Depends of dbus MarkInstall libexpat1:amd64 < none -> 2.2.3-2 @un uN > FU=0 Installing libpam-systemd as Depends of dbus-user-session MarkInstall libpam-systemd:amd64 < none -> 235-3 @un uN Ib > FU=0 Installing systemd as Depends of libpam-systemd MarkInstall systemd:amd64 < none -> 235-3 @un uN Ib > FU=0 Installing libcap2 as Depends of systemd MarkInstall libcap2:amd64 < none -> 1:2.25-1.1 @un uN > FU=0 Installing libcryptsetup4 as Depends of systemd MarkInstall libcryptsetup4:amd64 < none -> 2:1.7.5-1 @un uN Ib > FU=0 Installing libdevmapper1.02.1 as Depends of libcryptsetup4 MarkInstall libdevmapper1.02.1:amd64 < none -> 2:1.02.145-4 @un uN Ib > FU=0 Installing dmsetup as Depends of libdevmapper1.02.1 MarkInstall dmsetup:amd64 < none -> 2:1.02.145-4 @un uN > FU=0 Installing libidn11 as Depends of systemd MarkInstall libidn11:amd64 < none -> 1.33-2 @un uN > FU=0 Installing libip4tc0 as Depends of systemd MarkInstall libip4tc0:amd64 < none -> 1.6.1-2+b1 @un uN > FU=0 Installing libkmod2 as Depends of systemd MarkInstall libkmod2:amd64 < none -> 24-1 @un uN > FU=0 Installing procps as Depends of systemd MarkInstall procps:amd64 < none -> 2:3.3.12-3 @un uN Ib > FU=0 Installing libncurses5 as Depends of procps MarkInstall libncurses5:amd64 < none -> 6.0+20170902-1 @un uN > FU=0 Installing libprocps6 as Depends of procps MarkInstall libprocps6:amd64 < none -> 2:3.3.12-3 @un uN > FU=0 Installing systemd-shim as Depends of libpam-systemd MarkInstall systemd-shim:amd64 < none -> 10-3 @un uN Ib >
Bug#882151: apt is having trouble resolving dependencies of libgtk-3-dev in sid
On Sun, Nov 19, 2017 at 9:24 AM, Emilio Pozuelo Monfort wrote: > What architecture are you using? Are you running kfreebsd or hurd by any > chance? > Using reportbug would give us that information fwiw... This was on amd64 (using a just updated pbuilder chroot of sid, so the host system details reported by reportbug wouldn't necessarily be completely relevant). -- Daniel Schepler
Bug#882151: apt is having trouble resolving dependencies of libgtk-3-dev in sid
Package: apt Version: 1.6~alpha5 Severity: important X-Debbugs-CC: pkg-gnome-maintain...@lists.alioth.debian.org Affects: libgtk-3-dev Recently, in pbuilder builds on my machine, apt has been having trouble figuring out how to install libgtk-3-dev. Debugging within a "pbuilder login" session shows: root@frobozz:/# apt install libgtk-3-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgtk-3-dev : Depends: gir1.2-gtk-3.0 (= 3.22.26-1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. The strange thing is, if I try to dig into what the problem is with "apt install libgtk-3-dev gir1.2-gtk-3.0", then the installation is successful. So the package is actually installable, it's just that for some reason apt is having difficulties figuring out the installation set. -- Daniel Schepler
Bug#881787: Frequent refresh-cache operations are taking a lot of CPU time
On Thu, Nov 16, 2017 at 10:19 AM, Gerry Cocco wrote: > Daniel > > I see this on three "native hardware" systems as well. The only thing I > have noticed is that it one test system I installed without KDE, it did not > have this problem. Are you running KDE by any chance? Yes, I am running KDE (on testing, so packagekit version here is 1.1.7-1). -- Daniel
Bug#881787: Frequent refresh-cache operations are taking a lot of CPU time
I noticed the same symptoms on my system (not a VM). What made me really notice it was that under "top", there are frequently "apt-config shell" processes taking up 100% CPU time, for minutes at a time (though that's several apt-config shell processes running serially, which each take several seconds to complete). -- Daniel
Bug#881640: pbuilder: --preserve-buildplace is broken with pbuilder-satisfydepends-classic
Package: pbuilder Version: 0.229 Severity: normal Since a recent upload, pbuilder copies and extracts the source package in the chroot before invoking the satisfydepends script. With the combination of pbuilder-satisfydepends-classic and --preserve-buildplace, this breaks things because the chroot "cache directory" is no longer left in its initial (clean) state. This especially breaks things with my setup, which contains a post-unpack hook which relies on there being exactly one source package in /build. (The setup, which was the original use case I had in mind in implementing --preserve-buildplace in the first place, is a script to maintain a "dogfooding" local mirror of bootstrapped packages, and run a loop that goes through all the packages that haven't been bootstrapped so far trying to build them all. So, the --preserve-buildplace is essential to get any kind of speed when most of the packages don't yet have satisfiable Build-Depends from the bootstrapped set.) (It would also be nice if pbuilder-satisfydepends-apt would support --preserve-buildplace by returning exit code 2 if "apt-get -s build-dep" fails. That would be so much faster than pbuilder-satisfydepends-classic.) -- Daniel Schepler
Bug#879704: meson: nocheck build profile still requires rustc and c++-compiler-arm-linux-gnueabihf
On Wed, Oct 25, 2017 at 2:31 PM, Jussi Pakkanen wrote: > On Tue, Oct 24, 2017 at 10:43 PM, Daniel Schepler wrote: > >> Currently, if you build meson with the nocheck build profile, it still >> requires rustc and c++-compiler-arm-linux-gnueabihf. That looks like >> a mistake, that the was probably intended to apply to both >> alternatives in e.g. "rustc | bash-doc " - but as written, > > Is the correct format > > rustc | bash-doc > > If yes, I'll fix it in the next upload. Yes, that would be correct format for "require neither rustc nor bash-doc in the nocheck build profile". (Although to be honest, I don't know exactly what role bash-doc would play in the testsuite...) -- Daniel Schepler
Bug#879704: meson: nocheck build profile still requires rustc and c++-compiler-arm-linux-gnueabihf
Source: meson Version: 0.43.0-1 Severity: minor Currently, if you build meson with the nocheck build profile, it still requires rustc and c++-compiler-arm-linux-gnueabihf. That looks like a mistake, that the was probably intended to apply to both alternatives in e.g. "rustc | bash-doc " - but as written, it only applies to bash-doc, so the effect is actually that in stage1 rustc is required (and bash-doc is not sufficient to satisfy the entry as it is in a regular build). -- Daniel
Bug#879695: doxygen: Make source package bootstrappable
On Tue, Oct 24, 2017 at 11:49 AM, Helmut Grohne wrote: > I've been bitten by pregenerated files more than once and dislike your > sketched solution. At the same time I acknowledge that it may be > unavoidable. [...] I see what you mean: The choice would be whether or not to add code to error out if the pregenerated files don't match what was actually generated. If you don't, you risk people forgetting to update the files and therefore having the bootstrap build be broken. If you do, then you risk the normal package build breaking unnecessarily because of some change in a newer version of yui-compressor or ruby-compass / sass. > The other major alternative is moving doxygen to Build-Depends-Indep and > thus move the generated documentation to arch:all packages. This makes > more sense conceptually as it would remove doxygen from the bootstrap > set entirely, but results in more work and more binary packages. I agree that would be the optimal solution. Practically, though, as you already hinted, I think there are probably enough packages in the core bootstrap set that would need to be updated, that it might take a while and having some interim measure in the meantime would be good. (And if eventually we want Architecture: all packages also to be bootstrappable from a minimal starting set, then there would be some cases also requiring a "nodocs" build profile, so for example you could build libasound2-data or libthai-data without needing to build libasound2-doc or libthai-doc. And this point would also be the biggest issue I would have with the solution of moving the JS stuff into separate files and a separate package: you would still need to bootstrap the JS files somehow in this scenario, until all the source packages that need to would provide a bootstrap build without doxygen docs.) -- Daniel
Bug#879695: doxygen: Make source package bootstrappable
Source: doxygen Version: 1.8.13-9 Severity: wishlist Currently, doxygen's Build-Depends on yui-compressor creates build dependency cycles such as: yui-compressor Depends on default-jre-headless default-jre-headless Depends on openjdk-8-jre-headless openjdk-8 Build-Depends on cups cups Build-Depends on dh-apparmor apparmor Build-Depends on apache2-dev apache2 Build-Depends on libapr1-dev apr Build-Depends on doxygen It would be nice if there were a way to bootstrap doxygen without needing Java. For example, maybe the debian/ directory could contain pregenerated versions of the relevant files and then copy those into place in a stage1 build where the normal build would run yui-compressor and ruby-compass. -- Daniel
Bug#879254: libgd2: FTBFS: Requested unknown package libgd2-xpm-dev via -p/--package
Source: libgd2 Version: 2.2.5-3 Severity: serious >From my pbuilder log log: ... debian/rules override_dh_install make[1]: Entering directory '/build/libgd2-2.2.5' dh_install --fail-missing -Xlibgd.la -Xgdlib-config dh_install: Please use dh_missing --list-missing/--fail-missing instead dh_install: This feature will be removed in compat 12. make[1]: Leaving directory '/build/libgd2-2.2.5' debian/rules override_dh_installdocs make[1]: Entering directory '/build/libgd2-2.2.5' dh_installdocs -plibgd2-xpm-dev -plibgd2-noxpm-dev --link-doc=libgd-dev dh_installdocs: Requested unknown package libgd2-xpm-dev via -p/--package, expected one of: libgd-tools libgd-dev libgd3 dh_installdocs: Requested unknown package libgd2-noxpm-dev via -p/--package, expected one of: libgd-tools libgd-dev libgd3 dh_installdocs: unknown option or error during option parsing; aborting debian/rules:32: recipe for target 'override_dh_installdocs' failed make[1]: *** [override_dh_installdocs] Error 25 make[1]: Leaving directory '/build/libgd2-2.2.5' debian/rules:23: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 -- Daniel Schepler
Bug#876672: e2fsprogs: FTBFS: Unknown package libblkid1-udeb given via -N/--no-package
Source: e2fsprogs Version: 1.43.6-1 Severity: serious >From my pbuilder build log: ... dh_testdir dh_testroot dh_lintian mkdir -p /build/e2fsprogs-1.43.6/debian/libss2/usr/share/doc/libss2 mkdir -p /build/e2fsprogs-1.43.6/debian/ss-dev/usr/share/doc ln -sf libss2 /build/e2fsprogs-1.43.6/debian/ss-dev/usr/share/doc/ss-dev mkdir -p /build/e2fsprogs-1.43.6/debian/libcomerr2/usr/share/doc/libcomerr2 mkdir -p /build/e2fsprogs-1.43.6/debian/comerr-dev/usr/share/doc ln -sf libcomerr2 /build/e2fsprogs-1.43.6/debian/comerr-dev/usr/share/doc/comerr-dev mkdir -p /build/e2fsprogs-1.43.6/debian/e2fslibs/usr/share/doc/e2fslibs mkdir -p /build/e2fsprogs-1.43.6/debian/e2fslibs-dev/usr/share/doc ln -sf e2fslibs /build/e2fsprogs-1.43.6/debian/e2fslibs-dev/usr/share/doc/e2fslibs-dev dh_installdocs -Ne2fsprogs-udeb -Nlibblkid1-udeb -Nlibuuid1-udeb dh_installdocs: Unknown package libblkid1-udeb given via -N/--no-package, expected one of: fuse2fs e2fsck-static e2fsprogs-l10n libcomerr2 comerr-dev libss2 ss-dev e2fsprogs-udeb e2fslibs e2fslibs-dev e2fsprogs dh_installdocs: Unknown package libuuid1-udeb given via -N/--no-package, expected one of: fuse2fs e2fsck-static e2fsprogs-l10n libcomerr2 comerr-dev libss2 ss-dev e2fsprogs-udeb e2fslibs e2fslibs-dev e2fsprogs dh_installdocs: unknown option or error during option parsing; aborting debian/rules:372: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 -- Daniel Schepler
Bug#867707: Bootstrapping of libfm / menu-cache
There is more work that needs to be done in order to make the libfm / menu-cache cycle bootstrappable. Currently, menu-cache Build-Depends on libfm-dev, which is not built by the stage1 build profile of src:libfm. -- Daniel Schepler
Bug#873276: liboggz: Make source package bootstrappable
Source: liboggz Version: 1.1.1-5 Severity: wishlist Since liboggz and vorbis-tools both Build-Depend on each other, there is a cycle here that needs to be broken for the packages to be bootstrappable. Probably, if debian/rules were fixed to respect DEB_BUILD_OPTIONS=nocheck, then the Build-Depends for liboggz could be adjusted to "..., vorbis-tools " which would break the cycle. -- Daniel Schepler
Bug#871764: snappy-java: Make source package bootstrappable
On Fri, Aug 11, 2017 at 1:33 PM, Emmanuel Bourg wrote: > Good point. I think plexus-archiver should be modified such that the > snappy dependency becomes optional. I don't think it's used anyway. > Would that fix the bootstrapping issue? I believe it would - in my recent experience, once openjdk-8 was bootstrapped, and I downloaded all the Architecture: all dependencies of maven-debian-helper, that was the only thing keeping maven-debian-helper from being installable. -- Daniel Schepler
Bug#871764: snappy-java: Make source package bootstrappable
Source: snappy-java Version: 1.1.4-1 Severity: wishlist Currently, src:snappy-java Build-Depends on maven-debian-helper, which indirectly Depends on libsnappy-java (through libplexus-archiver-java), which Depends on libsnappy-jni. It would be nice if the source package could provide a build profile to bootstrap libsnappy-jni. -- Daniel Schepler