Bug#1011474: libhrash0: Cannot load libcrypto.so.3

[Daniel Schepler]

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

[Daniel Schepler]

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'

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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 (?)

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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)

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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;
+use warnings;
+
+use IPC::Run qw(run start finish);
+use IO::Handle;
+use File::Basename qw(basename);
+
+BEGIN {
+use Exporter ();
+use Sbuild::Chroot;
+our (@ISA, @EXPORT);
+
+@ISA = qw(Exporter Sbuild::Chroot);
+
+ 

Bug#948522: If I rebuild src:file with libseccomp-dev installed, then "fakeroot file ..." crashes with "Bad system call"

[Daniel Schepler]

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.*'

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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=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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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?

[Daniel Schepler]

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?

[Daniel Schepler]

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

[Daniel Schepler]

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~)

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

l 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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

 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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

On Tue, Feb 20, 2018 at 2:47 PM, Lisandro Damián Nicanor Pérez Meyer
<perezme...@gmail.com> 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

[Daniel Schepler]

: 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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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)

[Daniel Schepler]

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

[Daniel Schepler]

H=/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

[Daniel Schepler]

_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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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'

[Daniel Schepler]

On Thu, Jan 11, 2018 at 1:41 AM, Santiago Vila <sanv...@unex.es> 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'

[Daniel Schepler]

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(_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'

[Daniel Schepler]

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 

Bug#884750: happy: stage1 build profile FTBFS

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

/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

[Daniel Schepler]

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

[Daniel Schepler]

On Sun, Nov 19, 2017 at 9:37 AM, Julian Andres Klode <j...@debian.org> 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 > F

Bug#882151: apt is having trouble resolving dependencies of libgtk-3-dev in sid

[Daniel Schepler]

On Sun, Nov 19, 2017 at 9:24 AM, Emilio Pozuelo Monfort
<po...@debian.org> 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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

On Wed, Oct 25, 2017 at 2:31 PM, Jussi Pakkanen <jpakk...@gmail.com> wrote:
> On Tue, Oct 24, 2017 at 10:43 PM, Daniel Schepler <dschep...@gmail.com> 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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

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

[Daniel Schepler]

On Fri, Aug 11, 2017 at 1:33 PM, Emmanuel Bourg <ebo...@apache.org> 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

[Daniel Schepler]

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

Bug#871585: python-apt: FTBFS: Test failure

[Daniel Schepler]

Source: python-apt
Version: 1.4.0~beta3
Severity: serious

>From my pbuilder build log:

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/python-apt-1.4.0~beta3'
set -e; for python in python2.7 python3.6 python3.5 ; do \
   $python tests/test_all.py -q || [ "linux" = "hurd" ]; \
done;
[tests] Running on 2.7.13+ (default, Jul 19 2017, 18:15:03) [GCC 6.4.0 20170704]
Using library_dir:
'/build/python-apt-1.4.0~beta3/build/lib.linux-x86_64-2.7'WARNING:
Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
==
ERROR: testAddKeyFromServer (test_auth.TestAuthKeys)
Install a GnuPG key from a remote server.
--
Traceback (most recent call last):
 File "/build/python-apt-1.4.0~beta3/tests/test_auth.py", line 239, in
testAddKeyFromServer
   "hkp://localhost:%d" % self.keyserver_port)
 File "/build/python-apt-1.4.0~beta3/build/lib.linux-x86_64-2.7/apt/auth.py",
line 137, in add_key_from_keyserver
   shutil.rmtree(tmp_keyring_dir)
 File "/usr/lib/python2.7/shutil.py", line 266, in rmtree
   onerror(os.remove, fullname, sys.exc_info())
 File "/usr/lib/python2.7/shutil.py", line 264, in rmtree
   os.remove(fullname)
OSError: [Errno 2] No such file or directory: '/tmp/tmpVdpO4x/S.gpg-agent.extra'

--
Ran 97 tests in 21.771s

FAILED (errors=1, skipped=2)
debian/rules:50: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/python-apt-1.4.0~beta3'
debian/rules:16: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- 
Daniel Schepler