Bug#985040: qemu-system-data: too tight dependencies breaking on binNMUs

2021-03-14 Thread Sven Joachim
Control: reopen -1

On 2021-03-14 13:59 +0300, Michael Tokarev wrote:

> Version: 1:5.2+dfsg-7
>
> 12.03.2021 09:52, Sven Joachim wrote:
>> Package: qemu-system-data
>> Version: 1:5.2+dfsg-6
>> Severity: serious
>> The fix for #956377 has made the latest binNMU of qemu-system-x86
>> uninstallable:
>
> This is fixed by 1:5.2+dfsg-7 upload, and I missed to mention this bugreport
> in the Closes: clause.

No, it is not fixed.  You removed the dependencies from
qemu-system-common, but the ones in qemu-system-data remain.  The next
binNMU will therefore reintroduce the uninstallability. :-(

AFAICS the right fix would be to make qemu-system-x86 and co. depend on
qemu-system-data (= ${source:Version}) and remove the dependencies on
qemu-system-foo from qemu-system-data.

Cheers,
   Sven



Bug#985040: qemu-system-data: too tight dependencies breaking on binNMUs

2021-03-11 Thread Sven Joachim
Package: qemu-system-data
Version: 1:5.2+dfsg-6
Severity: serious

The fix for #956377 has made the latest binNMU of qemu-system-x86
uninstallable:

,
| $ LANG=C apt -s install qemu-system-x86
| NOTE: This is only a simulation!
|   apt 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... Done
| 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:
|  qemu-system-data : Depends: qemu-system-x86 (= 1:5.2+dfsg-6) or
|  qemu-system-arm (= 1:5.2+dfsg-6) or
|  qemu-system-mips (= 1:5.2+dfsg-6) or
|  qemu-system-ppc (= 1:5.2+dfsg-6) or
|  qemu-system-sparc (= 1:5.2+dfsg-6) or
|  qemu-system-misc (= 1:5.2+dfsg-6) or
|  qemu-system-s390x (= 1:5.2+dfsg-6) or
|  qemu-system-x86-xen (= 1:5.2+dfsg-6) but it is 
not installable
| E: Unable to correct problems, you have held broken packages.
`

The reason is that there was a binNMU bumping the version of
qemu-system-x86 et al to 1:5.2+dfsg-6+b1, but qemu-system-data is
arch:all and therefore still at version 1:5.2+dfsg-6.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.23-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-data depends on:
ii  qemu-system-x86  1:5.2+dfsg-6

qemu-system-data recommends no packages.

qemu-system-data suggests no packages.

-- no debconf information



Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

2021-03-07 Thread Sven Joachim
On 2021-03-05 14:41 +0100, Aurelien Jarno wrote:

> control: notfound -1 libc6/2.28-10
> control: found -1 libc6/2.31-9
> control: severity -1 grave
>
> On 2021-03-04 19:26, Thomas Hahn wrote:
>> Package: libc6
>> Version: 2.28-10
>> Severity: normal
>> X-Debbugs-Cc: thah...@t-online.de
>>
>> Dear Maintainer,
>>
>> installed buster, then apt upgrade  was also fine,
>> but the following dist-upgrade put the system in a broken state.
>>
>> Preparing to unpack .../62-locales_2.31-9_all.deb ...
>> Unpacking locales (2.31-9) over (2.28-10) ...
>> Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ...
>> Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ...
>> Preparing to unpack .../64-libc6_2.31-9_amd64.deb ...
>> whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not
>> found (required by /lib/x86_64-linux-gnu/libslang.so.2)
>
> This seems to show that libslang2 has been wrongly unpacked before
> libc6. Do you happen to have the beginning of the log? You can find it
> in /var/log/apt/term.log.*
>
>> debconf: whiptail output the above errors, giving up!
>> Checking for services that may need to be restarted...dpkg: error
>> processing archive
>> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb (--unpack):
>>  new libc6:amd64 package pre-installation script subprocess returned error 
>> exit status 255
>> Selecting previously unselected package libcrypt1:amd64.
>> dpkg: considering deconfiguration of libc6:amd64, which would be broken by 
>> installation of libcrypt1:amd64 ...
>> dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
>> Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
>> De-configuring libc6:amd64 (2.28-10) ...
>> Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
>> Errors were encountered while processing:
>>  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
>> Error: Timeout was reached
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> To unbreak your system the best would be to unpack libc6 manually using
> the following command:
>   dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb /

No, never do that!  This command actually runs "dpkg-deb -x" which,
unlike "dpkg -i", will silently overwrite symlinks to directories on the
filesystem with directories contained in the package.  This is very bad
if /lib is a symlink to /usr/lib (the "usrmerge" layout).

Cheers,
   Sven



Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

2021-03-06 Thread Sven Joachim
On 2021-03-06 02:49 +0530, Utkarsh Gupta wrote:

> Hi Thorsten
>
> On Sat, Mar 6, 2021 at 2:25 AM Thorsten Glaser  wrote:
>> debian/patches/CVE-2021-27135.patch changes button.c line (after
>> patching) 3747 to:
>>
>>line = realloc(line, screen->selection_size);
>>
>> But “line” is a local variable, the address of the buffer must
>> be stored in the one handed out, too, so please change this to:
>>
>> if ((have * 2) < (size_t) j) {
>> Char *next = realloc(line, have + 1);
>> if (next) {
>> screen->selection_data = line = next;
>> screen->selection_size = have + 1;
>> }
>> }
>>
>> This also deals properly with realloc failures (since we’re
>> shrinking, ignore them and just keep the older, larger area).

I see that this might be a problem (albeit unlikely to happen in
practice), however I have trouble understanding exactly where a
use-after-realloc bug comes into play.  Maybe Thorsten can help me fix
my blindness?

> Thanks for the very comprehensive bug report and for the patch as well!
>
>> I’ve not looked at jessie-ELTS or buster-security whether they
>> are affected as well; sid is clean (and where I got the realloc
>> failure check necessity from, although sid’s free()s the buffer
>> if realloc fails; this isn’t needed @Tom).
>
> If this seems to be happening in stretch, I assume there's a problem
> with jessie-ELTS as well. That said, buster is good because a DSA
> wasn't issued and this will be fixed via a point release.

I had already prepared an update for buster, but fortunately it did not
happen yet, because that one also has the same bug as yours.

> I am glad and surprised that sid is okay and there doesn't seem to be
> a problem.  Just to cross-check and ensure I get it right (for stretch
> and jessie), can you send me the reproducer as well? I'd like to be
> able to reproduce this before and after your patch (just to be one the
> safer side) and do the same for jessie as well!

Run xterm under valgrind and select some text.  Valgrind will be very
unhappy with xterm 327-2+deb9u1 but should not show up any errors in
that regard with a correctly patched version.  Instead of Thorsten's
suggestion you could also apply the patches to the SaltTextAway()
function from xterm 365e.

Cheers,
   Sven



Bug#979519: stockfish: FTBFS on any-i386, x86-32-old architecture is gone

2021-01-07 Thread Sven Joachim
Source: stockfish
Version: 12-1
Severity: serious
Tags: patch

Your package FTBFS on {,hurd-,kfreebsd-}i386:

,
| Testing config sanity. If this fails, try 'make help' ...
|
| make[2]: *** [Makefile:824: config-sanity] Error 1
`

This was not too helpful at first glance, but a closer inspection showed
that the support for the x86-32-old architecture has been removed[1] and
general-32 should be used instead.  Doing so worked for me in an i386
build chroot, see the attached patch. :)

Note that x86-32 cannot be used here as it includes sse which is not
part of the i386 baseline.

Thank you for maintaining stockfish!


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386


1. 
https://github.com/official-stockfish/Stockfish/commit/42e8789f0b3935b7ea389b3aa929e05e0a016872

diff -Nru stockfish-12/debian/rules stockfish-12/debian/rules
--- stockfish-12/debian/rules	2021-01-06 20:35:55.0 +0100
+++ stockfish-12/debian/rules	2021-01-07 11:08:23.0 +0100
@@ -13,10 +13,6 @@

 TARGET := profile-build ARCH=general-$(DEB_HOST_ARCH_BITS)

-ifeq (i386,$(DEB_HOST_ARCH_CPU))
-TARGET := profile-build ARCH=x86-32-old
-endif
-
 ifneq (,$(findstring amd64,$(DEB_HOST_ARCH)))
 TARGET := profile-build ARCH=x86-64
 endif


Bug#978367: libmaa: FTBFS: bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" utility'

2021-01-04 Thread Sven Joachim
Control: reassign -1 mk-configure 0.35.0-1
Control: forcemerge 977908 -1

On 2020-12-26 23:03 +0100, Lucas Nussbaum wrote:

> Source: libmaa
> Version: 1.4.7-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201226 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> [...]
>> checking C compiler type... gcc 10.2.1
>> bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 
>> 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" 
>> utility'
>> *** Error code 1
>> dh_auto_build: error: mkcmake PREFIX=/usr MANDIR=/usr/share/man 
>> INFODIR=/usr/share/info SYSCONFDIR=/etc STRIPFLAG= 
>> LIBDIR=/usr/lib/x86_64-linux-gnu LIBEXECDIR=/usr/lib/x86_64-linux-gnu 
>> returned exit code 1
>> make: *** [debian/rules:12: binary] Error 25

This had already been reported by the libmaa maintainer in #977908 and
has been fixed in mk-configure 0.35.really.0.33.0-1.

Cheers,
   Sven



Bug#978171: aptitude: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory

2020-12-26 Thread Sven Joachim
On 2020-12-26 23:15 +0100, Axel Beckert wrote:

> Sven Joachim wrote:
>> > Looks like a missing dependency on libxxhash-dev on a first glance.
>> >
>> > Will check if that helps. (And I wonder where that one got lost.)
>>
>> It did not get lost, rather I suppose that the latest apt upload
>> introduced this new include without adding a proper dependency on
>> libxxhash-dev to libapt-pkg-dev.
>
> That's what I meant with "got lost" more or less. Thanks!
>
> So this should be fixed in src:apt then? (Cc'ing our deities. ;-)

Yes, there were at least three other bugs with the same problem, and one
of them had already been reassigned to libapt-pkg-dev.  I have merged
them all now.

Cheers,
   Sven



Bug#978171: [Aptitude-devel] Bug#978171: aptitude: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory

2020-12-26 Thread Sven Joachim
On 2020-12-26 22:46 +0100, Axel Beckert wrote:

> Hi Lucas,
>
> Lucas Nussbaum wrote:
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>
> Thanks for the bug report!
>
>> > /usr/include/apt-pkg/pkgcachegen.h:32:10: fatal error: xxhash.h: No such 
>> > file or directory
>> >32 | #include 
>> >   |  ^~
>> > compilation terminated.
>> > make[6]: *** [Makefile:582: apt.o] Error 1
>
>
> Looks like a missing dependency on libxxhash-dev on a first glance.
>
> Will check if that helps. (And I wonder where that one got lost.)

It did not get lost, rather I suppose that the latest apt upload
introduced this new include without adding a proper dependency on
libxxhash-dev to libapt-pkg-dev.

Cheers,
   Sven



Bug#975455: devtodo: failing autopkgtests with grep 3.6

2020-11-22 Thread Sven Joachim
Source: devtodo
Version: 0.1.20-8
Severity: serious
X-Debbugs-Cc: Carlos Henrique Lima Melara , Sven 
Joachim 

The purge-tasks and rm-tasks-and-db-file autopkgtests are currently
failing on ci.debian.net, creating a migration problem for ncurses.  It
seems however that this has nothing to do with the new ncurses version
but is related to a change in grep 3.5:

,
|   The --files-without-match (-L) option has reverted to its behavior
|   in grep 3.1 and earlier.  That is, grep -L again succeeds when a
|   line is selected, not when a file is listed.  The behavior in grep
|   3.2 through 3.4 was causing compatibility problems.
`

Both tests in question run grep -L as their last command and are failing
with grep 3.6-1 while they succeeded with earlier grep versions (prior
to 2020-11-17, testing had grep 3.4-1).



Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

2020-11-19 Thread Sven Joachim
On 2020-11-19 19:47 +0100, Marco d'Itri wrote:

> On Nov 16, Niko Tyni  wrote:
>
>> As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
>> for one release cycle, so that libc6 cannot be unpacked before libcrypt1
>> is fully installed.
> I think that Niko is right, so I would like to know the opinion of the
> glibc maintainers.

I am not one of them, but AFAICS that would introduce a fatal circular
dependency between libc6 and libcrypt1: libc6 needs libcrypt1 to be
configured before it can be unpacked, but libcrypt1 depends on libc6 so
it cannot be configured before libc6 is at least unpacked.

Cheers,
   Sven



Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

2020-11-13 Thread Sven Joachim
On 2020-11-13 18:23 +0100, Niels Thykier wrote:

> Control: reassign -1 perl-base
> Control: affects -1 upgrade-reports
> Control: severity -1 grave
>
> Hi Perl team,
>
> I have reassigned this bug to perl because perl-base being essential
> must remain functional during an upgrade and AFAICT perl-base fails in
> this case here.
>
> If it is a direct linkage, then you might be needing a Pre-Depends.  If
> it is an indirect linkage then I am not sure how to fix it. :-/

I don't think perl-base is doing anything wrong here, it already uses
Pre-Depends.  AFAICS the problem is that libcrypt.so.1 can temporarily
go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the
assumption that binaries from essential packages are always usable.

I don't have a good idea how to fix that, though. :-(

Cheers,
   Sven

> Alois Wohlschlager:
>> Package: upgrade-reports
>> Severity: critical
>> Justification: breaks the whole system
>> X-Debbugs-Cc: alo...@gmx-topmail.de
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>>* What led up to the situation?
>> 
>>Do an upgrade from buster to bullseye.
>> 
>> 
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>> 
>>1. adjust sources.list
>>2. apt upgrade
>>3. apt dist-upgrade
>> 
>>* What was the outcome of this action?
>> 
>>apt dist-upgrade goes horribly wrong. Excerpt from the log:
>> 
>> ---
>> Entpacken von libc6:amd64 (2.31-4) über (2.28-10) ...
>> Vormals nicht ausgewähltes Paket libc6:i386 wird gewählt.
>> Vorbereitung zum Entpacken von .../4-libc6_2.31-4_i386.deb ...
>> Entpacken von libc6:i386 (2.31-4) ...
>> Vormals nicht ausgewähltes Paket libgcc-s1:i386 wird gewählt.
>> Vorbereitung zum Entpacken von .../5-libgcc-s1_10.2.0-16_i386.deb ...
>> Entpacken von libgcc-s1:i386 (10.2.0-16) ...
>> Vormals nicht ausgewähltes Paket gcc-10-base:i386 wird gewählt.
>> Vorbereitung zum Entpacken von .../6-gcc-10-base_10.2.0-16_i386.deb ...
>> Entpacken von gcc-10-base:i386 (10.2.0-16) ...
>> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot 
>> open
>> shared object file: No such file or directory
>> dpkg: Fehler: Fehler beim Ausführen des Hooks »if [ -x /usr/share/debian-
>> security-support/check-support-status.hook ] ; then /usr/sh
>> are/debian-security-support/check-support-status.hook ; fi«, Exitkode 32512
>> ---
>> 
>>At this point, perl is still the version from buster, and libcrypt1 is not
>> yet installed. The missing libcrypt.so.1 also completely breaks PAM, so login
>> and sudo don't work any more.
>>To recover from this outcome, I had to boot with "init=/bin/sh", install 
>> the
>> libcrypt1 package with dpkg and run "apt -f install" twice. This rendered the
>> system operational again and a further "apt dist-upgrade" ran through 
>> smoothly.
>> 
>>* What outcome did you expect instead?
>> 
>>libcrypt1 is installed before libcrypt.so.1 is required again, so the 
>> dist-
>> upgrade can proceed normally.
>> 
>> [...]



Bug#972610: getmail6: file conflicts with getmail

2020-10-24 Thread Sven Joachim
On 2020-10-22 21:08 +0100, Sudip Mukherjee wrote:

> On Wed, Oct 21, 2020 at 09:44:14AM +0200, Sven Joachim wrote:
>> Package: getmail6
>> Version: 6.7-1
>> Severity: serious
>>
>> Your package ships /usr/bin/getmail and various other files owned by the
>> getmail package, here is a complete list:
> 
>>
>> A Conflicts with getmail would solve that, however I think it would also
>> be desirable to work out a transition plan for bullseye.  The getmail
>> package is not installable there, and dist-upgrades from buster are
>> going to remove python and its reverse dependencies including getmail.
>
> I was aware of the file conflicts and I was thinking of adding "Conflicts:"
> but when I was testing in my vm I did "dist-upgrade" and old getmail was
> removed. And since 'getmail' has been removed from 'testing', so I assumed
> it will not cause any problem. Apparently, I was wrong. :(

It is true that dist-upgrades would have removed getmail, but we also
support partial upgrades in Debian.  Additionally, there is now the
python-is-python2 package which Provides python, so apt might choose to
install that and leave the old getmail package in place.

> I am not sure how the transition will work here, I only know about the
> library transition process.

I was thinking about taking over the getmail binary package from
src:getmail and make it a transitional package for getmail6, so that
users upgrading from Buster won't be left in the cold.  But that is not
something you should do unilaterally, please talk to the getmail
maintainer and ask him about this plans.

Once Charles Cazabon releases an official version with Python3 support,
Debian might want to switch back to it, but I am afraid this is not
going to happen before the Bullseye freeze.

> Do you want me to add "Conflicts" and upload for now?

That would be good, to getmail6 into testing ASAP.

Cheers,
   Sven



Bug#972610: getmail6: file conflicts with getmail

2020-10-21 Thread Sven Joachim
Package: getmail6
Version: 6.7-1
Severity: serious

Your package ships /usr/bin/getmail and various other files owned by the
getmail package, here is a complete list:

,
| # dpkg -i --force-overwrite getmail6_6.7-1_all.deb
| (Reading database ... 13802 files and directories currently installed.)
| Preparing to unpack getmail6_6.7-1_all.deb ...
| Unpacking getmail6 (6.7-1) ...
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/bin/getmail', which is also in 
package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/bin/getmail-gmail-xoauth-tokens', 
which is also in package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/bin/getmail_fetch', which is also in 
package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/bin/getmail_maildir', which is also 
in package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/bin/getmail_mbox', which is also in 
package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/man/man1/getmail.1.gz', which 
is also in package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/man/man1/getmail_fetch.1.gz', 
which is also in package getmail 5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite 
'/usr/share/man/man1/getmail_maildir.1.gz', which is also in package getmail 
5.13-1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/man/man1/getmail_mbox.1.gz', 
which is also in package getmail 5.13-1
| Setting up getmail6 (6.7-1) ...
`

A Conflicts with getmail would solve that, however I think it would also
be desirable to work out a transition plan for bullseye.  The getmail
package is not installable there, and dist-upgrades from buster are
going to remove python and its reverse dependencies including getmail.

Thank you for packaging the Python3 fork of getmail! :-)


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.1-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#971674: cowdancer: uses ncurses in the LD_PRELOADed DLL, making upgrades unreliable

2020-10-04 Thread Sven Joachim
Control: forcemerge 970555 971674

Am 04.10.2020 um 21:07 schrieb Thorsten Glaser:

> found 971674 0.81
> notfound 971674 0.80
> thanks
>
>> Definitively an issue as log.c (part of the DLL) uses curses
>> making the whole thing fragile.
>
> Jessica, you added this in e4b477ef7e77316c5171d15ac119b5766ee2ed73.
>
> I think we either need to create a variant of the DLL without the
> ncurses dependency and use that during upgrades, or do away with
> it completely.
>
> I personally am in favour of the latter. We don’t need colours in
> logging, especially as they are annoying in logfiles. But I don’t
> want to step on your toes…
>
> … anyway, this is pretty much a blocker for all my development now.

Use the --no-cowdancer-update as suggested at the end of your log file.

IMO this is not a bug in ncurses, libncurses6 and libtinfo6 are unpacked
in the same dpkg run and the former is not guaranteed to work with
different versions of the latter anyway.  No essential programs depend
on libncurses6, so this is not usually a problem.

The only way to "solve" this from the ncurses side would be to merge
libncurses6 and libncursesw6 into libtinfo6, but then people will likely
complain about bloating their chroots.

Cheers,
   Sven



Bug#971274: webext-compactheader: not compatible with thunderbird 78

2020-09-28 Thread Sven Joachim
Package: webext-compactheader
Version: 3.0.0~beta5-2
Severity: grave
Control: forwarded -1 https://github.com/jmozmoz/compactheader/issues/42

After upgrading thunderbird from 68 to 78, it deactivated the
CompactHeader extension as incompatible.

Perhaps it should be replaced by
https://addons.thunderbird.net/en-US/thunderbird/addon/compact-headers/ ?


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-rc7-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages webext-compactheader depends on:
ii  thunderbird  1:78.3.1-1

webext-compactheader recommends no packages.

webext-compactheader suggests no packages.

-- no debconf information



Bug#970912: Fails to upgrade: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

2020-09-25 Thread Sven Joachim
Control: reassign -1 cowdancer
Control: forcemerge 970555 -1

On 2020-09-25 13:28 +0200, Michael Biebl wrote:

> Package: libncurses6
> Version: 6.2+20200918-1
> Severity: serious
>
> Today I tried to upgrade my cowbuilder chroots.
> This failed with the following error message:
>
> Preparing to unpack .../libncurses6_6.2+20200918-1_amd64.deb ...
> Unpacking libncurses6:amd64 (6.2+20200918-1) over (6.2-1) ...
> rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
> not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)
> dpkg: error while cleaning up:
>  rm command for cleanup subprocess returned error exit status 1
> dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
> rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
> not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)
> dpkg: error processing archive 
> /var/cache/apt/archives/libtinfo6_6.2+20200918-1_amd64.deb (--unpack):
>  rm command for cleanup subprocess returned error exit status 1
> Errors were encountered while processing:
>  /var/cache/apt/archives/libtinfo6_6.2+20200918-1_amd64.deb

Use the --no-cowdancer-update cowbuilder option to work around this, see
#970555 for details.

Cheers,
   Sven



Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

2020-09-21 Thread Sven Joachim
Control: reassign -1 cowdancer
Control: forcemerge 970555 -1

On 2020-09-21 17:53 +0200, Rene Engelhard wrote:

> Package: libtinfo6
> Version: 6.2+20200918-1
> Severity: serious
>
> Hi,
>
> in a (dist-|cowbuilder ) upgrade  of my i386 chroot:
>
> Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
> Unpacking libncursesw6:i386 (6.2+20200918-1) over (6.2-1) ...
> Preparing to unpack .../libncurses6_6.2+20200918-1_i386.deb ...
> Unpacking libncurses6:i386 (6.2+20200918-1) over (6.2-1) ...
> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
> dpkg: error while cleaning up:
>  rm command for cleanup subprocess returned error exit status 1
> dpkg-split: /lib/i386-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/i386-linux-gnu/libncurses.so.6)
> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
> dpkg: error processing archive 
> /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb (--unpack):
>  rm command for cleanup subprocess returned error exit status 1
> Errors were encountered while processing:
>  /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> I: Copying back the cached apt archive contents
> I: unmounting /home filesystem
> I: unmounting dev/ptmx filesystem
> I: unmounting dev/pts filesystem
> I: unmounting dev/shm filesystem
> I: unmounting proc filesystem
> I: unmounting sys filesystem
> E: pbuilder update failed
> E: could not update with cowdancer, try --no-cowdancer-update option

Please follow that advice, see #970555 for details.

Cheers,
   Sven



Bug#970577: marked as pending in ncurses

2020-09-19 Thread Sven Joachim
Control: tag -1 pending

Hello,

Bug #970577 in ncurses reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/ncurses/-/commit/2d6ac0aae872eacba1c6052543303774ace080de


New upstream patchlevel

In this patchlevel, curses.events is no longer appended to curses.h
and therefore the broken parsers in dpkg and zsh can no longer find
the KEY_EVENT definition there.

Closes: #970577


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/970577



Bug#970545: dpkg FTBFS: KEY_EVENT undeclared

2020-09-19 Thread Sven Joachim
Control: clone -1 -2
Control: reassign -2 libncurses-dev 6.2+20200912-1
Control: retitle -2 dpkg and zsh FTBFS: KEY_EVENT undeclared
Control: severity -1 normal
Control: tags -2 - ftbfs

On 2020-09-18 19:29 +0200, Guillem Jover wrote:

> On Fri, 2020-09-18 at 18:26:34 +0200, Sven Joachim wrote:
>> Am 18.09.2020 um 13:43 schrieb Helmut Grohne:
>> > Source: dpkg
>> > Version: 1.20.5
>> > Severity: serious
>> > Tags: ftbfs
>> >
>> > dpkg FTBFS as of today:
>> >
>> > | In file included from ../../dselect/curkeys.cc:30:
>> > | ./curkeys.h:168:5: error: ‘KEY_EVENT’ was not declared in this scope; 
>> > did you mean ‘KEY_OPEN’?
>> > |   168 |   { KEY_EVENT,  "Event"   },
>> > |   | ^
>> > |   | KEY_OPEN
>
>> > I suppose this is connected to a ncurses upload.
>
>> Quoting the ncurses NEWS file:
>> 
>> ,
>> | 20200817
>> |+ prevent KEY_EVENT from appearing in curses.h unless the configure
>> |  option --enable-wgetch-events is used (report by Werner Fink).
>> `
>
> Right, thanks for the confirmation, that's along the lines of what I
> had gathered from checking the header. Even though the problem here
> is that the macro is there, but just behind a conditional, I suppose
> that's still expected?

No, that was not expected and an oversight which has been corrected in
the 20200918 ncurses patchlevel.  At least one other package (zsh) is
affected.

>> See the thread at
>> https://lists.gnu.org/archive/html/bug-ncurses/2020-08/threads.html#00017
>> for a discussion that motivated this change.
>
> I'll check this later, but no matter what, I think it is still worth
> fixing the dpkg build system to handle this kind of case more robustly.
> I've prepared the attached patch which seems to work with gcc and clang,
> and I'll try to upload either later today or tomorrow.

I agree that dpkg's parsing of curses.h needs improvement, but no need
to hurry with an upload, I will upgrade ncurses to the 20200918
patchlevel this weekend.

Cheers,
   Sven



Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

2020-09-18 Thread Sven Joachim
Control: reassign -1 cowdancer 0.88
Control: retitle -1 cowdancer: needlessly links with ncurses
Control: severity -1 important

On 2020-09-18 18:22 +0200, Sebastiaan Couwenberg wrote:

> Control: tags -1 - moreinfo
>
> On 9/18/20 6:13 PM, Sven Joachim wrote:
>> On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:
>>> Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:
>>>
>>>  Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
>>>  Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
>>>  Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
>>>  Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
>>>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>>> `NCURSES6_TINFO_6.2.current' not found (required by 
>>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>>  dpkg: error while cleaning up:
>>>   rm command for cleanup subprocess returned error exit status 1
>>>  dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>>> `NCURSES6_TINFO_6.2.current' not found (required by 
>>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>>> `NCURSES6_TINFO_6.2.current' not found (required by 
>>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>>  dpkg: error processing archive 
>>> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
>>>   rm command for cleanup subprocess returned error exit status 1
>>>  Errors were encountered while processing:
>>>   /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
>>>  E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> I cannot reproduce this, but my pbuilder chroots do not have libncurses6
>> installed at all.
>
> What about cowbuilder chroots?

Thanks for the hint, I do not use cowbuilder but had a look at the
manpage where I found this option:

,
|  --no-cowdancer-update
| Do  not use cowdancer on cowbuilder update. Please use this
| option when cowdancer is interfering with upgrade  process,
| or cowdancer itself is being upgraded within chroot.
`

Apparently this is what you need to use, for cowdancer seems to bring
libncurses.so.6 into the address space of every binary on the system,
which is "interfering with upgrade process".

>> What is this rm binary in your chroot, apparently it
>> is linked to libncurses.so.6?
>
>  # which rm
>  /bin/rm
>  # dpkg -S /bin/rm
>  coreutils: /bin/rm
>  # ldd /bin/rm
>  linux-vdso.so.1 (0x7ffea75fb000)
>  /usr/lib/cowdancer/libcowdancer.so (0x7f2e6a6db000)
>  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2e6a512000)
>  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2e6a50c000)
>  libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6
> (0x7f2e6a4e3000)
>  libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
> (0x7f2e6a4b4000)
>  /lib64/ld-linux-x86-64.so.2 (0x7f2e6a6f9000)
>  # aptitude why libncurses6
>  i   cowdancer Depends libncurses6 (>= 6)

It seems that cowdancer should not link with ncurses in the first place,
as it only uses the tinfo library.  In fact, rebuilding cowbuilder with
a current toolchain that defaults to the "--as-needed" linker flag
causes cowbuilder and cowdancer to depend on libtinfo6 only.

Cheers,
   Sven



Bug#970545: dpkg FTBFS: KEY_EVENT undeclared

2020-09-18 Thread Sven Joachim
Am 18.09.2020 um 13:43 schrieb Helmut Grohne:

> Source: dpkg
> Version: 1.20.5
> Severity: serious
> Tags: ftbfs
>
> dpkg FTBFS as of today:
>
> | g++ -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\"
> | -DADMINDIR=\"/var/lib/dpkg\" -DLIBDIR=\"/usr/lib/dpkg\"
> | -DLOCALLIBDIR=\"/usr/local/lib/dpkg\" -idirafter ../../lib/compat
> | -iquote . -I.. -I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -fno-rtti
> | -fno-exceptions -Wall -Wextra -Wcast-align -Wduplicated-branches
> | -Wduplicated-cond -Wformat -Wformat-security -Wformat=2 -Winit-self
> | -Wlogical-not-parentheses -Wlogical-op -Wmissing-declarations
> | -Wmissing-format-attribute -Wno-missing-field-initializers
> | -Wno-nonnull-compare -Wno-unused-parameter -Wnull-dereference
> | -Wpointer-arith -Wredundant-decls -Wregister -Wrestrict -Wshadow
> | -Wshift-negative-value -Wsizeof-array-argument -Wswitch-bool -Wvla
> | -Wwrite-strings -Wc++11-compat -Wcast-qual -Wold-style-cast
> | -Wzero-as-null-pointer-constant -g -O2
> | -fdebug-prefix-map=/<>=. -fstack-protector-strong
> | -Wformat -Werror=format-security -Wall -Wextra
> | -Wno-missing-field-initializers -Wno-nonnull-compare
> | -Wno-unused-parameter -MT curkeys.o -MD -MP -MF .deps/curkeys.Tpo -c
> | -o curkeys.o ../../dselect/curkeys.cc
> | mv -f .deps/pkgdisplay.Tpo .deps/pkgdisplay.Po
> | mv -f .deps/pkginfo.Tpo .deps/pkginfo.Po
> | mv -f .deps/pkgcmds.Tpo .deps/pkgcmds.Po
> | In file included from ../../dselect/curkeys.cc:30:
> | ./curkeys.h:168:5: error: ‘KEY_EVENT’ was not declared in this scope; did 
> you mean ‘KEY_OPEN’?
> |   168 |   { KEY_EVENT,  "Event"   },
> |   | ^
> |   | KEY_OPEN
> | make[4]: *** [Makefile:617: curkeys.o] Error 1
> | make[4]: *** Waiting for unfinished jobs
> | mv -f .deps/pkgdepcon.Tpo .deps/pkgdepcon.Po
> | mv -f .deps/pkgsublist.Tpo .deps/pkgsublist.Po
> | mv -f .deps/pkgtop.Tpo .deps/pkgtop.Po
> | mv -f .deps/pkglist.Tpo .deps/pkglist.Po
> | make[4]: Leaving directory '/<>/build-tree/dselect'
> | make[3]: *** [Makefile:650: all-recursive] Error 1
> | make[3]: Leaving directory '/<>/build-tree/dselect'
> | make[2]: *** [Makefile:743: all-recursive] Error 1
> | make[2]: Leaving directory '/<>/build-tree'
> | make[1]: *** [Makefile:609: all] Error 2
> | make[1]: Leaving directory '/<>/build-tree'
> | make: *** [debian/rules:74: build] Error 2
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
>
> I suppose this is connected to a ncurses upload.

Quoting the ncurses NEWS file:

,
| 20200817
|   + prevent KEY_EVENT from appearing in curses.h unless the configure
| option --enable-wgetch-events is used (report by Werner Fink).
`

See the thread at
https://lists.gnu.org/archive/html/bug-ncurses/2020-08/threads.html#00017
for a discussion that motivated this change.

Cheers,
   Sven



Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

2020-09-18 Thread Sven Joachim
Control: tags -1 moreinfo

On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:

> Source: ncurses
> Version: 6.2+20200912-1
> Severity: serious
> Justification: makes the package in question unusable or mostly so
>
> Dear Maintainer,
>
> Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:
>
>  Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
>  Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
>  Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
>  Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
>  dpkg: error while cleaning up:
>   rm command for cleanup subprocess returned error exit status 1
>  dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
>  dpkg: error processing archive 
> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
>   rm command for cleanup subprocess returned error exit status 1
>  Errors were encountered while processing:
>   /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
>  E: Sub-process /usr/bin/dpkg returned an error code (1)

I cannot reproduce this, but my pbuilder chroots do not have libncurses6
installed at all.  What is this rm binary in your chroot, apparently it
is linked to libncurses.so.6?

Cheers,
   Sven



Bug#967932: closed by Matthias Klose (Re: redland-bindings: FTBFS: lots of undefined reference errors from ld)

2020-08-09 Thread Sven Joachim
Control: fixed -1 1.0.17.1+dfsg-1.4

On 2020-08-08 19:42 +, Matthias Klose wrote:

> not sure what the bug submitter was trying, but 1.0.17.1+dfsg-1.4 just built 
> fine.

I tried to build the package with sbuild in a sid chroot, which failed.
Apparently some change in dh-python made it necessary to configure with
--with-python=python2 as you did in 1.0.17.1+dfsg-1.4.  I can confirm
this version builds for me.

Thanks,
   Sven



Bug#966787: hardcoded dependency of python-librdf on python

2020-08-05 Thread Sven Joachim
The python-librdf package has a hardcoded dependency on python.  Simply
removing it should be enough to fix this bug, however the package does
currently FTBFS, see #967932.

Cheers,
   Sven



Bug#967932: redland-bindings: FTBFS: lots of undefined reference errors from ld

2020-08-05 Thread Sven Joachim
Source: redland-bindings
Version: 1.0.17.1+dfsg-1.3
Severity: serious
Tags: bullseye sid ftbfs

I was looking at #966787, and while the fix for that bug should be easy
(just remove python-librdf's hardcoded python dependency), I could not
build the package in a current amd64 sid chroot:

,
| gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/rasqal -I/usr/include/raptor2  -DSWIG_PYTHON_SILENT_MEMLEAK -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security Redland_wrap.so  -Wl,-z,relro  -lrdf  -lrasqal 
-lraptor2  -o _Redland
| /usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/Scrt1.o: in function 
`_start':
| (.text+0x20): undefined reference to `main'
| /usr/bin/ld: Redland_wrap.so: in function `SWIG_Python_ErrorType':
| ./python2.7/./Redland_wrap.c:955: undefined reference to `PyExc_IOError'
| /usr/bin/ld: ./python2.7/./Redland_wrap.c:952: undefined reference to 
`PyExc_MemoryError'
`

In the last successful build[1], the corresponding gcc commandline used
"-shared" and ended with "-o _Redland.so" rather "-o _Redland", so
trying to build an executable is apparently want went wrong here.

A build log is attached for reference.


1. 
https://buildd.debian.org/status/fetch.php?pkg=redland-bindings=amd64=1.0.17.1%2Bdfsg-1.3%2Bb9=1584636898=0



redland-bindings_1.0.17.1+dfsg-1.3_amd64.build.xz
Description: application/xz


Bug#967912: texlive-luatex: file conflict with old texlive-latex-extra package

2020-08-04 Thread Sven Joachim
Package: texlive-luatex
Version: 2020.20200804-1
Severity: serious

There was a hiccup installing your package (sorry for the German):

,
| Entpacken von texlive-luatex (2020.20200804-1) über (2020.20200629-1) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-78owrZ/04-texlive-luatex_2020.20200804-1_all.deb 
(--unpack):
|  Versuch, »/usr/share/texlive/texmf-dist/scripts/cloze/cloze.lua« zu 
überschreiben, welches auch in Paket texlive-latex-extra 2020.20200629-1 ist
`

After upgrading texlive-latex-extra to 2020.20200804-1, the
texlive-luatex installation completed successfully, so it seems another
Breaks+Replaces combo is in order.

Thanks for maintaining texlive! :-)


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-luatex depends on:
ii  libjs-jquery  3.5.1+dfsg-4
ii  lmodern   2.004.5-6
ii  tex-common6.15
ii  texlive-base  2020.20200804-1
ii  texlive-binaries  2020.20200327.54578-4+b1

texlive-luatex recommends no packages.

texlive-luatex suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.20.5
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.2

Versions of packages texlive-luatex is related to:
ii  tex-common6.15
ii  texlive-binaries  2020.20200327.54578-4+b1

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:
  tex-common/singleuser: false



Bug#963377: xterm: FTBFS: /bin/sh: 1: col: not found

2020-06-22 Thread Sven Joachim
On 2020-06-21 17:11 -0400, Thomas Dickey wrote:

> On Sun, Jun 21, 2020 at 10:13:41PM +0200, Lucas Nussbaum wrote:
>> Source: xterm
>> Version: 356-1
>> Severity: serious
>> Justification: FTBFS on amd64
>> Tags: bullseye sid ftbfs
>> Usertags: ftbfs-20200620 ftbfs-bullseye
>> 
>> Hi,
>> 
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>
> col's in bsdmainutils

It used to be there, but has recently been moved to bsdextrautils.  This
has caused a lot of breakage, so bsdmainutils ought to depend on
bsdextrautils for the time being to fix that.  However…

>> > GROFF_NO_SGR=stupid /bin/sh -c "tbl ../ctlseqs.ms | groff -Tascii -ms | 
>> > col -bx" >../ctlseqs.txt
>> > /bin/sh: 1: col: not found
>> > make[2]: *** [Makefile:180: ../ctlseqs.txt] Error 127
>
> refer to
>
> xterm (332-1) unstable; urgency=medium
>
>   * Regenerate ctlseqs.txt from ctlseqs.ms (Closes: #848818). 
>   
> - Add groff to Buils-Depends.

…I should also have added a build dependency on bsdmainutils there.
That package is already pulled in via debhelper → man-db → bsdmainutils,
so I overlooked it.

I have just uploaded xterm 356-2 with
bsdextrautils | bsdmainutils (<< 12.1.1~) added to Build-Depends.

Cheers,
   Sven



Bug#962271: libncurses5-dev: Dependency issue

2020-06-05 Thread Sven Joachim
Control: severity -1 normal
Control: tags -1 moreinfo wontfix

On 2020-06-05 14:35 +0300, Mohammed Alnajdi wrote:

> Package: libncurses5-dev
> Version: 6.1+20181013-2+deb10u2
> Severity: serious
> Justification: Installing libncurses5-dev installs libncurses6 from
> libncurses-dev and not
>
> Hello, I noticed that if i install libncurses5-dev i get libncurses6 which
> breaks software which still relay on libncurse5.

I fail to see how it does that, could you please elaborate?

> I believe installing
> libncurses5-dev should bring everything that is  libncurses5 not
> libncurses6.

Sorry, not going to happen.  In general Debian only provides -dev
packages for the latest ABI of libraries, and ncurses is no exception,
especially as its API has not changed.

If for some reason you need to compile software against the old ABI, use
a chroot for that, e.g. with Debian 9 in it.  Or build ncurses yourself.

Cheers,
   Sven



Bug#961960: libunistring: FTBFS on non-amd64 due to broken debian/not-installed

2020-06-01 Thread Sven Joachim
Source: libunistring
Version: 0.9.10-3
Severity: serious
Tags: patch

Your package FTBFS everywhere except on amd64, because the path to
libunistring.la in debian/not-installed does not match on other
architectures.  See the attached patch, tested on i386.

From c7f9cb848f8da2e4807753138f64acce0397b343 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 1 Jun 2020 09:08:10 +0200
Subject: [PATCH 1/1] Fix d/not-installed for non-amd64

---
 debian/not-installed | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/not-installed b/debian/not-installed
index b08b312..7641c51 100644
--- a/debian/not-installed
+++ b/debian/not-installed
@@ -1,2 +1,2 @@
 usr/share/info/libunistring.info
-usr/lib/x86_64-linux-gnu/libunistring.la
+usr/lib/*/libunistring.la
--
2.27.0.rc2



Bug#958075: crispy-doom: file conflict with chocolate-doom

2020-04-17 Thread Sven Joachim
Package: crispy-doom
Version: 5.8.0-1
Severity: serious

There was a problem installing your package (sorry for the German):

,
| Vorbereitung zum Entpacken von .../crispy-doom_5.8.0-1_amd64.deb ...
| Entpacken von crispy-doom (5.8.0-1) über (5.6.4-1) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/var/cache/apt/archives/crispy-doom_5.8.0-1_amd64.deb (--unpack):
|  Versuch, »/usr/share/man/man5/heretic.cfg.5.gz« zu überschreiben, welches 
auch in Paket chocolate-doom 3.0.0-6 ist
| Fehler traten auf beim Bearbeiten von:
|  /var/cache/apt/archives/crispy-doom_5.8.0-1_amd64.deb
`

Since chocolate-doom was there first to ship the offending file, I
assume it should be removed from crispy-doom.

Thanks for crispy-doom! :-)


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.5-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages crispy-doom depends on:
ii  libc62.30-4
ii  libpng16-16  1.6.37-2
ii  libsamplerate0   0.1.9-2
ii  libsdl2-2.0-02.0.10+dfsg1-3
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-2+b1
ii  libsdl2-net-2.0-02.0.1+dfsg1-4+b1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages crispy-doom recommends:
ii  game-data-packager  64

crispy-doom suggests no packages.

-- no debconf information



Bug#955651: libinput: FTBFS: /<>/obj-x86_64-linux-gnu/meson-private/tmpwq1q3syj/testfile.c:4:12: error: #error "Header 'xlocale.h' could not be found"

2020-04-05 Thread Sven Joachim
Control: reassign -1 libwacom-dev 1.3-1
Control: fixed -1 libwacom/1.3-2

On 2020-04-03 21:37 +0200, Lucas Nussbaum wrote:

> Source: libinput
> Version: 1.15.4-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
>> [...]
>> Run-time dependency libwacom found: NO
>>
>> ../meson.build:140:1: ERROR: Could not generate cargs for libwacom:
>> Package gudev-1.0 was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `gudev-1.0.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'gudev-1.0', required by 'libwacom', not found

That happened because libwacom-dev lacked a dependency on
libgudev-1.0-dev.  This has been fixed in the latest libwacom upload,
and I have just successfully built libinput in a sid chroot.

Cheers,
   Sven



Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1

2020-03-23 Thread Sven Joachim
Package: libgcc-8-dev
Version: 8.4.0-2
Severity: grave

The latest version of gcc-8 is not installable because libgcc-8-dev
depends on libgcc-s1 (>= 1:8.4.0-2), but the version of libgcc-s1 in the
archive does not have an epoch and is therefore too low to fulfill this
requirement.

The same holds for libgcc-7-dev 7.5.0-6.



Bug#952271: apitrace: FTBFS: make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libprocps.so', needed by 'glretrace'. Stop.

2020-02-23 Thread Sven Joachim
Control: reassign -1 libprocps-dev
Control: forcemerge 951494 -1

On 2020-02-23 14:27 +0100, Lucas Nussbaum wrote:

> Source: apitrace
> Version: 9.0+repack-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
>> make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
>> make[3]: *** No rule to make target 
>> '/usr/lib/x86_64-linux-gnu/libprocps.so', needed by 'glretrace'.  Stop.

This is bug #951494 in libprocps-dev.

Cheers,
   Sven



Bug#950916: libtool-doc: trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is also in package libtool

2020-02-09 Thread Sven Joachim
Control: notfound -1 2.4.6-11
Control: found -1 2.4.6-12

On 2020-02-08 10:49 +0100, Jakub Wilk wrote:

> Package: libtool-doc
> Version: 2.4.6-11
> Severity: serious
>
> The package failed to upgrade:
>
>   Preparing to unpack .../28-libtool-doc_2.4.6-12_all.deb ...
>   Unpacking libtool-doc (2.4.6-12) over (2.4.6-11) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-Kxxra4/28-libtool-doc_2.4.6-12_all.deb (--unpack):
>trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is also in 
> package libtool 2.4.6-12

I have not looked at the package, but I bet this is a side effect of the
debhelper compat bump from 9 to 12, see the following note in
debhelper(7) about compat level 11:

,
|  -   The dh_installdocs and dh_installexamples tools may
|  now install most of the documentation in a different
|  path to comply with the recommendation from Debian
|  policy §12.3 (since version 3.9.7).
`

>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-Kxxra4/28-libtool-doc_2.4.6-12_all.deb
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

Here is a complete list of clashing files:

,
| # dpkg --force-overwrite -i 
/var/cache/apt/archives/libtool-doc_2.4.6-12_all.deb
| (Reading database ... 14428 files and directories currently installed.)
| Preparing to unpack .../libtool-doc_2.4.6-12_all.deb ...
| Unpacking libtool-doc (2.4.6-12) ...
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/AUTHORS', which is 
also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/NEWS.gz', which is 
also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/README', which is 
also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/THANKS.gz', which 
is also in package libtool 2.4.6-12
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/doc/libtool/TODO.gz', which is 
also in package libtool 2.4.6-12
| Setting up libtool-doc (2.4.6-12) ...
`

Cheers,
   Sven



Bug#950624: libgcc-s1: libgcc_s.so.1 can be missing after upgrade on usrmerge systems

2020-02-04 Thread Sven Joachim
Package: libgcc-s1
Version: 10-20200202-1
Severity: serious

On systems where /lib is a symlink to /usr/lib (which is the case for
every new buster installation, for instance), it can easily happen that
/usr/lib/$DEB_HOST_MUTIARCH/libgcc_s.so.1 disappears on upgrades.  This
happens whenever libgcc-s1 is unpacked before the new libgcc1, because
the old libgcc1 package ships /lib/$DEB_HOST_MUTIARCH/libgcc_s.so.1
which is in the same place, but unfortunately dpkg does not detect that
this means there is a file conflict.

This actually happened to me in a usrmerge chroot, here is the relevant
excerpt from dpkg.log:

,
| # grep libgcc.*1: /var/log/dpkg.log
| 2020-02-04 10:02:17 install libgcc-s1:amd64  10-20200202-1
| 2020-02-04 10:02:17 status half-installed libgcc-s1:amd64 10-20200202-1
| 2020-02-04 10:02:17 status unpacked libgcc-s1:amd64 10-20200202-1
| 2020-02-04 10:02:17 configure libgcc-s1:amd64 10-20200202-1 
| 2020-02-04 10:02:17 status unpacked libgcc-s1:amd64 10-20200202-1
| 2020-02-04 10:02:17 status half-configured libgcc-s1:amd64 10-20200202-1
| 2020-02-04 10:02:17 status installed libgcc-s1:amd64 10-20200202-1
| 2020-02-04 10:02:17 upgrade libgcc1:amd64 1:9.2.1-1 1:10-20200202-1
| 2020-02-04 10:02:17 status half-configured libgcc1:amd64 1:9.2.1-1
| 2020-02-04 10:02:17 status unpacked libgcc1:amd64 1:9.2.1-1
| 2020-02-04 10:02:17 status half-installed libgcc1:amd64 1:9.2.1-1
| 2020-02-04 10:02:17 status unpacked libgcc1:amd64 1:10-20200202-1
| 2020-02-04 10:02:17 configure libgcc1:amd64 1:10-20200202-1 
| 2020-02-04 10:02:17 status unpacked libgcc1:amd64 1:10-20200202-1
| 2020-02-04 10:02:17 status half-configured libgcc1:amd64 1:10-20200202-1
| 2020-02-04 10:02:17 status installed libgcc1:amd64 1:10-20200202-1
`

Fortunately "apt reinstall libgcc-s1" remedies the situation, but if the
system is rebooted before that, the effects could be more drastic (see
#950254 and #950551).


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.1-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#947822: closed by Andreas Rönnquist (Bug#947822: fixed in geeqie 1:1.5.1-4)

2020-01-07 Thread Sven Joachim
Control: tags -1 + patch

On 2020-01-07 20:03 +0800, Paul Wise wrote:

> Control: reopen -1
> Control: found -1 1:1.5.1-5
> Control: notfixed -1 1:1.5.1-4
> Control: usertags -1 + bittenby
>
> On Tue, 7 Jan 2020 10:51:14 + Tomas Janousek wrote:
>
>> I don't think this is fixed, I got the same error as Sven when updating from
>> 1:1.5.1-2 to 1:1.5.1-5:
>> 
>> ...
>> Připravuje se nahrazení …/08-geeqie_1%3a1.5.1-5_amd64.deb …
>> Rozbaluje se geeqie (1:1.5.1-5) přes (1:1.5.1-2) …
>> dpkg: chyba při zpracovávání archivu 
>> /tmp/apt-dpkg-install-WWTusb/08-geeqie_1%3a1.5.1-5_amd64.deb (--unpack):
>>  zkouším přepsat soubor „/usr/share/man/man1/geeqie.1.gz“, který je také 
>> v balíku geeqie-common 1:1.5.1-2
>> Připravuje se nahrazení …/09-geeqie-common_1%3a1.5.1-5_all.deb …
>> Rozbaluje se geeqie-common (1:1.5.1-5) přes (1:1.5.1-2) …
>> ...
>> 
>> (Sorry for it not being in English.)
>> 
>> As you can see, it still unpacks geeqie before unpacking geeqie-common.
>
> I also had this problem, reopening.

There is a Breaks/Replaces relationship on geeqie-common, but it is
missing the epoch.  See the attached patch (trivial, but untested).

Cheers,
   Sven

From c5090b2eb850ab5055bb5da1dbb309db47509bef Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Tue, 7 Jan 2020 16:33:58 +0100
Subject: [PATCH] Add missing epoch in Breaks/Replaces relationship

Closes: #947822
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index af774668..403d0ae5 100644
--- a/debian/control
+++ b/debian/control
@@ -42,8 +42,8 @@ Suggests: gimp,
   geeqie-dbg,
   libjpeg-progs,
   ufraw
-Replaces: gqview, geeqie-common (<= 1.5.1-2)
-Breaks: geeqie-common (<= 1.5.1-2)
+Replaces: gqview, geeqie-common (<= 1:1.5.1-2)
+Breaks: geeqie-common (<= 1:1.5.1-2)
 Description: image viewer using GTK+
  Geeqie is a browser for graphics files offering single click viewing of
  your graphics files. It includes thumbnail view, zoom, filtering
--
2.25.0.rc1



Bug#947823: geeqie-common: Debian changelog is not compressed

2019-12-30 Thread Sven Joachim
Package: geeqie-common
Version: 1:1.5.1-3
Severity: serious

The changelogs in this package are not compressed:

,
| $ ls /usr/share/doc/geeqie-common/changelog*
| /usr/share/doc/geeqie-common/changelog  
/usr/share/doc/geeqie-common/changelog.Debian
`

Looking at debian/rules, apparently the intention was to leave only the
upstream changelog uncompressed so that geeqie can find it at runtime,
but debhelper's -X option does not quite work the way a naive user might
suspect.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.6-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

geeqie-common depends on no packages.

Versions of packages geeqie-common recommends:
ii  geeqie  1:1.5.1-3

geeqie-common suggests no packages.

-- no debconf information



Bug#947822: geeqie: file conflict with older geeqie-common

2019-12-30 Thread Sven Joachim
Package: geeqie
Version: 1:1.5.1-3
Severity: serious

There was a problem when updating your package (sorry for the German):

,
| Vorbereitung zum Entpacken von .../6-geeqie_1%3a1.5.1-3_amd64.deb ...
| Entpacken von geeqie (1:1.5.1-3) über (1:1.5.1-2) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-aJs4JD/6-geeqie_1%3a1.5.1-3_amd64.deb (--unpack):
|  Versuch, »/usr/share/man/man1/geeqie.1.gz« zu überschreiben, welches auch in 
Paket geeqie-common 1:1.5.1-2 ist
| Vorbereitung zum Entpacken von .../7-geeqie-common_1%3a1.5.1-3_all.deb ...
| Entpacken von geeqie-common (1:1.5.1-3) über (1:1.5.1-2) ...
| Fehler traten auf beim Bearbeiten von:
|  /tmp/apt-dpkg-install-aJs4JD/6-geeqie_1%3a1.5.1-3_amd64.deb
`

Thou shalt not move files between packages without proper Replaces &
Breaks - see Policy § 7.6.1.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.6-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages geeqie depends on:
ii  geeqie-common1:1.5.1-3
ii  libc62.29-7
ii  libcairo21.16.0-4
ii  libexiv2-14  0.25-4
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc1  1:9.2.1-21
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-2
ii  libglib2.0-0 2.62.4-1
ii  libgtk2.0-0  2.24.32-4
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4
ii  liblirc-client0  0.10.1-6
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libstdc++6   9.2.1-21
ii  libtiff5 4.1.0+git191117-1
ii  sensible-utils   0.0.12+nmu1

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.1-1
ii  exiftran 2.10-3+b1
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  librsvg2-common  2.46.4-1
pn  ufraw-batch  
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg   
pn  gimp 
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- no debconf information



Bug#946939: wine: no longer builds wine-binfmt and fonts-wine packages

2019-12-18 Thread Sven Joachim
Source: wine
Version: 5.0~rc1-1
Severity: serious

This upload has silently dropped the wine-binfmt and fonts-wine
packages.  This seems to be a consequence of building from the git
master branch used for wine-development and probably has not really been
intended.

Bringing back these packages probably requires a trip through NEW as
they have already been removed from unstable.



Bug#946429: texlive-latex-recommended: File conflict with old texlive-latex-extra

2019-12-08 Thread Sven Joachim
Package: texlive-latex-recommended
Version: 2019.20191208-1
Severity: serious

Once again a file has moved to a different package without proper
Breaks+Replaces:

,
| Vorbereitung zum Entpacken von 
.../01-texlive-latex-recommended_2019.20191208-1_all.deb ...
| Entpacken von texlive-latex-recommended (2019.20191208-1) über 
(2019.20191112-1) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-W9Ippi/01-texlive-latex-recommended_2019.20191208-1_all.deb
 (--unpack):
|  Versuch, 
»/usr/share/texlive/texmf-dist/tex/latex/grffile/grffile-2017-06-30.sty« zu 
überschreiben, welches auch in Paket texlive-latex-extra 2019.20191112-1 ist
| dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe 
unterbrochen (broken pipe)) getötet
`

After upgrading texlive-latex-extra the installation of
texlive-latex-recommended succeeded.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.2-nouveau (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-latex-recommended depends on:
ii  tex-common  6.13
ii  texlive-base2019.20191208-1
ii  texlive-binaries2019.20190605.51237-3
ii  texlive-latex-base  2019.20191208-1

texlive-latex-recommended recommends no packages.

Versions of packages texlive-latex-recommended suggests:
ii  texlive-latex-recommended-doc  2019.20191208-1
pn  texlive-luatex 
pn  texlive-pstricks   

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.7.2

Versions of packages texlive-latex-recommended is related to:
ii  tex-common6.13
ii  texlive-binaries  2019.20190605.51237-3

-- debconf information:
  tex-common/singleuser: false
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:



Bug#946287: webext-compactheader: too low dependency on thunderbird

2019-12-06 Thread Sven Joachim
Package: webext-compactheader
Version: 3.0.0~beta5-1
Severity: serious

The webext-compactheader depends on thunderbird (>= 68.0~), missing the
epoch that the thunderbird package carries.  I have just installed it
with thunderbird 1:60.9.0-1 where it does not work.

Going to upgrade thunderbird now to fix that.  Thanks for maintaining
thunderbird and this extension!


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.2-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages webext-compactheader depends on:
ii  thunderbird  1:60.9.0-1

webext-compactheader recommends no packages.

webext-compactheader suggests no packages.

-- no debconf information



Bug#944021: xul-ext-compactheader: not compatible with thunderbird 68

2019-11-02 Thread Sven Joachim
Package: xul-ext-compactheader
Version: 2.1.6-1
Severity: serious

This package is not compatible with thunderbird 68 which has just appeared
in unstable:

,
| $ LANG=C aptitude -s install thunderbird thunderbird-l10n-de
| The following packages will be upgraded:
|   thunderbird{b} thunderbird-l10n-de
| The following packages are RECOMMENDED but will NOT be installed:
|   lightning
| 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
| Need to get 35.3 MB of archives. After unpacking 2812 kB will be used.
| The following packages have unmet dependencies:
|  thunderbird : Breaks: xul-ext-compactheader (< 3.0.0) but 2.1.6-1 is 
installed
`

On the thunderbird side of things, shouldn't the Breaks be adjusted to
(<< 3.0.0~), since 3.0.0.~beta3 is the latest version on
https://github.com/jmozmoz/compactheader/releases ?


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.8-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xul-ext-compactheader depends on:
ii  thunderbird  1:60.9.0-1

xul-ext-compactheader recommends no packages.

xul-ext-compactheader suggests no packages.

-- no debconf information



Bug#943838: grml2usb: check_for_fat() always fails

2019-10-30 Thread Sven Joachim
Control: tags -1 + patch
Control: forwarded -1 https://github.com/grml/grml2usb/pull/24

On 2019-10-30 17:09 +0100, Sven Joachim wrote:

> Package: grml2usb
> Version: 0.16.7
> Severity: grave
>
> The check_for_fat() function always fails, no matter what:
>
> ,
> | # file -s /dev/sdc2
> | /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID
> | "mkfs.fat", sectors/cluster 64, reserved sectors 64, root entries
> | 1024, Media descriptor 0xf8, sectors/FAT 256, sectors/track 32,
> | heads 64, hidden sectors 27265024, sectors 3512319 (volumes > 32
> | MB), serial number 0xadbb, unlabeled, FAT (16 bit)
> | # sudo grml2usb grml96-full_2018.12.iso /dev/sdc2
> | Executing grml2usb version 0.16.7
> | Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
> (Use --fat16 or run mkfs.vfat /dev/sdc2)
> | # grml2usb --fat16 grml96-full_2018.12.iso /dev/sdc2
> | Executing grml2usb version 0.16.7
> | Are you sure you want to format the specified partition with fat16? y/N y
> | Note: you can skip this question using the option --force
> | Formating partition with fat16 filesystem
> | mkfs.fat 4.1 (2017-01-24)
> | Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
> (Use --fat16 or run mkfs.vfat /dev/sdc2)
> `
>
> I am not really a Python expert, but AFAICS the problem is that by
> default Subprocess.open() opens file objects in binary mode, so the
> "filesystem" variable is an array of bytes, and comparing it to a string
> always yields false.

So that was indeed the case, but after fixing it I immediately ran into
another "strings vs bytes" problem in check_boot_flag().  Fortunately
that was the last issue, and now I have a USB stick with GRML on it. :-)
Have not tested whether it actually boots yet, though.

I have sent a pull request on GitHub.

Cheers,
   Sven



Bug#943838: grml2usb: check_for_fat() always fails

2019-10-30 Thread Sven Joachim
Package: grml2usb
Version: 0.16.7
Severity: grave

The check_for_fat() function always fails, no matter what:

,
| # file -s /dev/sdc2
| /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", 
sectors/cluster 64, reserved sectors 64, root entries 1024, Media descriptor 
0xf8, sectors/FAT 256, sectors/track 32, heads 64, hidden sectors 27265024, 
sectors 3512319 (volumes > 32 MB), serial number 0xadbb, unlabeled, FAT (16 
bit)
| # sudo grml2usb grml96-full_2018.12.iso /dev/sdc2
| Executing grml2usb version 0.16.7
| Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
(Use --fat16 or run mkfs.vfat /dev/sdc2)
| # grml2usb --fat16 grml96-full_2018.12.iso /dev/sdc2
| Executing grml2usb version 0.16.7
| Are you sure you want to format the specified partition with fat16? y/N y
| Note: you can skip this question using the option --force
| Formating partition with fat16 filesystem
| mkfs.fat 4.1 (2017-01-24)
| Execution failed: Partition /dev/sdc2 does not contain a FAT16 filesystem. 
(Use --fat16 or run mkfs.vfat /dev/sdc2)
`

I am not really a Python expert, but AFAICS the problem is that by
default Subprocess.open() opens file objects in binary mode, so the
"filesystem" variable is an array of bytes, and comparing it to a string
always yields false.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.8-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages grml2usb depends on:
ii  grub-pc-bin 2.04-3
ii  grub2-common2.04-3
ii  kmod26-3
ii  mtools  4.0.23-1+b1
ii  python3 3.7.5-1
ii  python3-parted  3.11.2-11
ii  rsync   3.1.3-8
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-1

Versions of packages grml2usb recommends:
ii  genisoimage 9:1.1.11-3+b2
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-1
pn  syslinux-utils  

grml2usb suggests no packages.

-- no debconf information



Bug#942066: filezilla: FTBFS with GCC 9: error: #error You need to use a C++17 compiler.

2019-10-09 Thread Sven Joachim
Control: retitle -1 filezilla: FTBFS with libfilezilla 0.18.2

On 2019-10-09 21:06 +0200, Andreas Beckmann wrote:

> Package: filezilla
> Version: 3.39.0-2
> Severity: serious
> Tags: sid bullseye
> Justification: fails to build from source (but built successfully in the past)
>
> filezilla FTBFS in sid, probably related to the default compiler being
> switched from GCC 8 to GCC 9:

Not really, I think.

> In file included from /usr/include/libfilezilla/libfilezilla.hpp:4,
>  from ../../src/include/libfilezilla_engine.h:12,
>  from ./filezilla.h:1,
>  from backend.cpp:1:
> /usr/include/libfilezilla/private/defs.hpp:10:4: error: #error You need to 
> use a C++17 compiler. Try passing -std=c++17 as compiler flag.
>10 |   #error You need to use a C++17 compiler. Try passing -std=c++17 as 
> compiler flag.
>   |^

That's because libfilezilla is built with -std=c++17.  See #941193.

Cheers,
   Sven



Bug#941193: filezilla: Crash on startup: undefined symbol: _ZTIN2fz6threadE

2019-10-09 Thread Sven Joachim
On 2019-09-26 08:16 +0200, Sven Joachim wrote:

> Control: reassign -1 libfilezilla0 0.18.2-1
>
> On 2019-09-26 17:53 +1200, jfp wrote:
>
>> Package: filezilla
>> Version: 3.39.0-2
>> Severity: grave
>> Justification: renders package unusable
>>
>> Dear Maintainer,
>>
>> Crashes on startup with the folloing error:
>>
>> filezilla: symbol lookup error: filezilla: undefined symbol: _ZTIN2fz6threadE
>
> Confirmed here, looks like libfilezilla changed the ABI without bumping
> SONAME.  Downgrading libfilezilla0 to 0.15.1-1 helps.

I am not really a C++ expert, but probably this ABI break has been
caused by libfilezilla being built with "-std=c++17".  If so, the SONAME
should be retained and either

- the packagename changed, or

- a versioned Breaks against filezilla added to debian/control and
  shlibs bumped (e.g. via "dh_makeshlibs -VUpstream-Version" in
  debian/rules).

And of course a new filezilla needs to be uploaded with a bumped
Build-Depends on libfilezilla-dev.

Cheers,
   Sven



Bug#935753: Bug reported upstream

2019-10-05 Thread Sven Joachim
Control: tags -1 - moreinfo
Control: tags -1 + fixed-upstream patch
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/issues/1860

This has been reported and fixed upstream, patch from [1] attached here.

Cheers,
   Sven

1. 
https://gitlab.freedesktop.org/mesa/mesa/commit/1c6fdbc83cf1094c735b964902da421978005cb3

From 1c6fdbc83cf1094c735b964902da421978005cb3 Mon Sep 17 00:00:00 2001
From: Lionel Landwerlin 
Date: Wed, 2 Oct 2019 17:13:06 +0300
Subject: [PATCH 1/1] intel: fix topology query

i915 will report ENODEV on generations prior to Haswell because there
is no point in reporting values on those. This is prior any fusing
could happen on parts with identical PCI ids.

This query call was previously only triggered on generations that
support performance queries, which happens to match generation for
which i915 reports topology, but the commit pointed below started
using it on all generations.

Signed-off-by: Lionel Landwerlin 
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/1860
Cc: 
Fixes: 96e1c945f2 ("i965: Move device info initialization to common code")
Reviewed-by: Mark Janes 
---
 src/intel/dev/gen_device_info.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 3953a1f4af3..85fa978f9c1 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -1320,6 +1320,9 @@ query_topology(struct gen_device_info *devinfo, int fd)
if (gen_ioctl(fd, DRM_IOCTL_I915_QUERY, ))
   return false;

+   if (item.length < 0)
+  return false;
+
struct drm_i915_query_topology_info *topo_info =
   (struct drm_i915_query_topology_info *) calloc(1, item.length);
item.data_ptr = (uintptr_t) topo_info;
--
2.23.0



Bug#941128: xorg-server FTBFS

2019-09-29 Thread Sven Joachim
Control: found -1 2:1.19.1-1
Control: tags -1 bullseye sid

On 2019-09-28 19:06 +, Niels Thykier wrote:

> Control: reassign -1 xorg-server
> Control: retitle -1 xorg-server: build target must depend on build-*
> Control: tags -1 ftbfs
>
> Timo Aaltonen:
>> Package: debhelper
>> Severity: important
>>
>> Hi, debhelper 12.4 was fine but the current one broke xorg-server build,
>> build-indep isn't run at all. With the old version it was run right in
>> the beginning:
>>
>> dh build --with quilt,autoreconf --parallel
>>debian/rules build-indep
>> make[1]: Entering directory '/<>'
>> mkdir -p build-source
>> tar \
>> --owner=0 --group=0 \
>> --transform 's,^,xorg-server/,' \
>> --exclude=debian \
>> --exclude=autom4te.cache \
>> -cf - * | xz > build-source/xorg-server.tar.xz
>> tar: build-source/xorg-server.tar.xz: file changed as we read it
>>> build-source-stamp
>> dh build-indep --with quilt,autoreconf --parallel
>>dh_quilt_patch -i -O--parallel
>> Applying patch 001_fedora_extramodes.patch
>> patching file hw/xfree86/common/extramodes
>> ...
>>
>> but now it's skipped:
>>
>> dh build --with quilt,autoreconf --parallel
>>dh_quilt_patch -O--parallel
>> Applying patch 001_fedora_extramodes.patch
>> patching file hw/xfree86/common/extramodes
>> ...
>>
> This problem is fundamentally caused by xorg-server's "build" target not
> invoking build-arch and build-indep (eventually).  The xorg-server
> package is assumed to invoke all relevant build steps as a part of the
> build target itself but it fails to do the build-arch and build-indep
> steps as a part of its build target.

It seem this has been present since xorg-server's rules file was
switched to dh, but it only has become serious recently.

I had a look how to fix that, here is what I tried.

Naive approach 1:

--8<---cut here---start->8---
diff --git a/debian/rules b/debian/rules
index 7365fed6c..c5d5e5e03 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,8 +34,8 @@ override_dh_auto_build:
 override_dh_auto_test:
dh_auto_test -- -j1 VERBOSE=1

-build: abibumpcheck
-build-indep: build-source-stamp
+build build-arch: abibumpcheck
+build build-indep: build-source-stamp

 override_dh_auto_install:
dh_auto_install --builddirectory=debian/build/main \
--8<---cut here---end--->8---

Result was that make processed the build-source-stamp target first
before running dh_quilt_patch and dh_autoreonf.  This is bad, because
xorg-server-source is supposed to contain the patched and autoreconfed
source.

Naive approach 2:

--8<---cut here---start->8---
diff --git a/debian/rules b/debian/rules
index 7365fed6c..cbdd15c31 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,8 +34,9 @@ override_dh_auto_build:
 override_dh_auto_test:
dh_auto_test -- -j1 VERBOSE=1

-build: abibumpcheck
+build-arch: abibumpcheck
 build-indep: build-source-stamp
+build: build-arch build-indep

 override_dh_auto_install:
dh_auto_install --builddirectory=debian/build/main \
--8<---cut here---end--->8---

This seems to work, but now a full (arch+indep) build configures and
builds the source tree twice, which wastes quite a bit of time.

In the end I decided to remove the build and build-indep targets
altogether[1], which does the trick for me (tested full, arch-only and
indep-only builds).

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/c119638422dbb051d6f575e12df353b2cc3a0f44



Bug#941193: filezilla: Crash on startup: undefined symbol: _ZTIN2fz6threadE

2019-09-26 Thread Sven Joachim
Control: reassign -1 libfilezilla0 0.18.2-1

On 2019-09-26 17:53 +1200, jfp wrote:

> Package: filezilla
> Version: 3.39.0-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Crashes on startup with the folloing error:
>
> filezilla: symbol lookup error: filezilla: undefined symbol: _ZTIN2fz6threadE

Confirmed here, looks like libfilezilla changed the ABI without bumping
SONAME.  Downgrading libfilezilla0 to 0.15.1-1 helps.

Cheers,
   Sven



Bug#940909: xserver-xorg-video-tdfx: missing dependencies

2019-09-21 Thread Sven Joachim
Package: xserver-xorg-video-tdfx
Version: 1:1.5.0-1
Severity: serious

In version 1:1.5.0-1 xserver-xorg-video-tdfx no longer depends on
xorg-video-abi-24 and xserver-xorg-core.  The reason is that commit
058dc36806b3 ("Bump debhelper to 12.") inadvertently dropped not only
autoreconf, but also xsf from the list of dh sequences.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.1-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#939779: kmod FTBFS: dh_makeshlibs: The udeb libkmod2-udeb does not contain any shared libraries but --add-udeb=libkmod2-udeb was passed!?

2019-09-08 Thread Sven Joachim
Am 08.09.2019 um 20:10 schrieb Helmut Grohne:

> Source: kmod
> Version: 26-1
> Severity: serious
> Tags: ftbfs
>
> kmod fails to build from source in unstable:
>
> | dh_makeshlibs --add-udeb=libkmod2-udeb -- -c4
> | dh_makeshlibs: The udeb libkmod2-udeb does not contain any shared libraries 
> but --add-udeb=libkmod2-udeb was passed!?
> | make: *** [debian/rules:115: .stamp-binary] Error 255
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
>
> Is this a debhelper regression?

Not really, it was certainly a bug that earlier dh_makeshlibs versions
did not complain here.  Using --add-udeb when the udeb does not actually
contain a shared library is IMO a serious bug.  It is currently possible
to build a udeb with a program that links to libkmod.so.2 and have its
dependencies fulfilled, but such a program will fail at runtime in the
installer because the library is not there.

Cheers,
   Sven



Bug#935792: libglx-mesa0: error creating symbolic link (missing dependency?)

2019-08-31 Thread Sven Joachim
Control: severity -1 normal
Control: tags -1 unreproducible moreinfo

On 2019-08-26 11:10 +0200, P.H. wrote:

> Package: libglx-mesa0
> Version: 18.3.6-2
> Severity: serious
> Justification: Policy 3.5
>
> Dear Maintainer,
>
> the update from Stretch to Buster failed with
>
>Unpacking libglx-mesa0:amd64 (18.3.6-2) ...
>dpkg: error processing archive 
> /var/cache/apt/archives/libglx-mesa0_18.3.6-2_amd64.deb (--unpack):
> error creating symbolic link 
> './usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0': No such file or directory

That's rather strange, but the diversions below show how it could
happen.

> $ env LANG=C dpkg -S /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0
> diversion by glx-diversions from: 
> /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0
> diversion by glx-diversions to: 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0
>
> and after installing the 'glx-diversions' package, 'libglx-mesa0' is happy 
> again.

The question is in what state the glx-diversions was before that.
Apparently it was installed due to the reported diversion, but maybe it
was broken.  In particular, apparently there was no
/usr/lib/mesa-diverted/x86_64-linux-gnu directory, that's why dpkg
failed to create the symlink there.  However, that directory is shipped
in the glx-diversions package.

> I am not sure what exactly happened, as my other computers upgraded
> smoothly and while they do have 'libglx-mesa0' installed, they do not
> need the 'glx-diversions' package. I guess the different graphic card
> drivers are to thank for...
>
>
> Anyway, this might only happen in strange environments but since my
> system seems sound, it is definitely a problem.

I don't think your system had been sound when you encountered the
unpacking error.  Installing/upgrading glx-diversions appears to have
fixed it, though.

I tried to reproduce your problem by installing glx-diversions from
stretch in a chroot, then installing libglx-mesa0 from buster.  This
worked just fine, so unless you can give additional information, there's
not much we can do.

Cheers,
   Sven



Bug#935300: rsyslog: FTBFS on s390x

2019-08-21 Thread Sven Joachim
On 2019-08-21 15:43 +0200, Ivo De Decker wrote:

> Hi,
>
> On 8/21/19 3:14 PM, Michael Biebl wrote:
>> Am 21.08.19 um 14:39 schrieb Ivo De Decker:
>>> package: src:rsyslog
>>> version: 8.1908.0-1
>>> severity: serious
>>> tags: ftbfs
>>>
>>> Hi,
>>>
>>> The latest version of rsyslog in unstable fails on s390x:
>>>
>>> https://buildd.debian.org/status/package.php?p=rsyslog
>> It's a test-suite failure. Seems the test-suite ran out-of
>> ressources
>> rsyslogd: file './rstb_365910_e7e00756.4.log': open error: Too many
>> open
>> files [v8.1908.0 try https://www.rsyslog.com/e/2433 ]
>> Maybe just a temporary issue. Could you give it back?
>
> I already did that. It failed twice.

The same error occurred on powerpc, ppc64 and sparc64, so I suspect
it is specific to big endian architectures.

Cheers,
   Sven



Bug#935017: debhelper breaks strip-nondeterminism autopkgtest

2019-08-18 Thread Sven Joachim
Control: reassign -1 debhelper 12.5.1

On 2019-08-18 06:45 +, Niels Thykier wrote:

> Control: reassign -1 strip-nondeterminism
>
>
> On Sun, 18 Aug 2019 08:19:37 +0200 Paul Gevers  wrote:
>> Source: debhelper, strip-nondeterminism
>> Control: found -1 debhelper/12.5.1
>> Control: found -1 debhelper/12.5
>> Control: found -1 strip-nondeterminism/1.5.0-1
>> Severity: serious
>> X-Debbugs-CC: debian...@lists.debian.org
>> User: debian...@lists.debian.org
>> Usertags: breaks needs-update
>>
>> Dear maintainers,
>>
>> With a recent upload of debhelper the autopkgtest of
>> strip-nondeterminism fails in testing when that autopkgtest is run with
>> the binary packages of debhelper from unstable. It passes when run with
>> only packages from testing. In tabular form:
>>passfail
>> debhelper  from testing12.5.1
>> strip-nondeterminism   from testing1.5.0-1
>> all others from testingfrom testing
>>
>> I copied some of the output at the bottom of this report.
>>
>> Currently this regression is blocking the migration of debhelper to
>> testing [1]. Due to the nature of this issue, I filed this bug report
>> against both packages. Can you please investigate the situation and
>> reassign the bug to the right package?
>>
>> More information about this bug and the reason for filing it can be found on
>> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>>
>> Paul
>>
>> [1] https://qa.debian.org/excuses.php?package=debhelper
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/s/strip-nondeterminism/2758965/log.gz
>>
>> 1..2
>> not ok 1 - bin/dh_strip_nondeterminism --help returns 255
>>
>> #   Failed test 'bin/dh_strip_nondeterminism --help returns 255'
>> #   at t/binaries.t line 42.
>> ok 2 - bin/strip-nondeterminism --help returns 0
>> # Looks like you failed 1 test of 2.
>>
>
> I cannot reproduce this locally in a sane way. For me, it returned 1
> before and after upgrading to debhelper/12.5.1 (from 12.4).  Digging in
> the tests, it looks like strip-nondeterminism is *not* testing the
> installed binaries[1].

This may be so, but the installed dh_strip-nondeterminism fails in the
same way:

,
| $ dh_strip_nondeterminism --help
| dh_strip_nondeterminism: "debian/control" not found. Are you sure you are in 
the correct directory?
`

The same error is seen with "dh --help" (which worked in 12.4, although
it is not documented) and "dh --list", which is supposed to work from
any directory.

Cheers,
   Sven



Bug#932854: initramfs-tools-core: Please depend on logsave

2019-07-25 Thread Sven Joachim
Control: severity -1 normal

On 2019-07-25 12:37 -0400, rharw...@club.cc.cmu.edu wrote:

> Package: initramfs-tools
> Version: 0.133
> Followup-For: Bug #932854
> Control: severity -1 critical
>
> Raising severity of this since it renders the machine unbootable.

The critical part is that e2fsprogs 1.45.3-1 did not depend on logsave
after splitting that into its own package, see #932861.

Cheers,
   Sven



Bug#932881: add dependency on logsave

2019-07-23 Thread Sven Joachim
Control: reassign -1 e2fsprogs 1.45.3-1
Control: forcemerge 932861 -1

On 2019-07-24 08:32 +0300, Aleksi Suhonen wrote:

> Package: initramfs-tools
> Severity: grave
> Version: 0.133
>
> After upgrading e2fsprogs to 1.45.3-1, computer fails to boot because
> rootfs fails to fsck. And fsck fails because binary for logsave is
> missing. Or in fact, fsck doesn't fail, but the init script reports it
> did, because it cannot tell the difference...
>
> This is because logsave has just been split into its own package
> "logsave." The initrd builder scripts should depend on it, except it
> seems that not all hardware platforms have the logsave package yet...

It is e2fsprogs which needs to depend on logsave for the time being in
order not to break its reverse dependencies.  As for initramfs-tools,
initramfs-tools-core should probably depend on
logsave | e2fsprogs (<< 1.45.3), that is tracked in #932854.

Cheers,
   Sven



Bug#932874: logsave: Insufficient Breaks/Replaces on e2fsprogs

2019-07-23 Thread Sven Joachim
Package: logsave
Version: 1.45.3-1
Severity: serious

Installing logsave without upgrading e2fsprogs fails:

,
| Preparing to unpack .../logsave_1.45.3-1_amd64.deb ...
| Unpacking logsave (1.45.3-1) ...
| dpkg: error processing archive 
/var/cache/apt/archives/logsave_1.45.3-1_amd64.deb (--install):
|  trying to overwrite '/sbin/logsave', which is also in package e2fsprogs 
1.45.2-1
`

There are a Replaces/Breaks relationships on e2fsprogs (<< 1.45.2-1)
which need to be bumped to (<< 1.45.3-1).


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.60-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages logsave depends on:
ii  libc6  2.28-10

logsave recommends no packages.

logsave suggests no packages.

-- no debconf information



Bug#932603: missing dependency on libnet1

2019-07-21 Thread Sven Joachim
On 2019-07-21 09:21 +0200, Sven Joachim wrote:

> Am 21.07.2019 um 08:56 schrieb Felix Zielcke:
>
>> Package: tcptraceroute
>> Version: 1.5beta7+debian-4.1
>> Severity: serious
>>
>> I hadn't libnet1 installed due to nothing depending on it and tcptraceroute 
>> failed now with:
>>
>> # tcptraceroute www.debian.org
>> tcptraceroute: error while loading shared libraries: libnet.so.1:
>> cannot open shared object file: No such file or directory
>>
>> And indeed the tcptraceroute_1.5beta7+debian-4.1_amd64.deb doestn't
>> have any Depends: line in DEBIAN/control.
>
> This is a consequence of debhelper bug #932240, the package needs to be
> rebuilt with a fixed debhelper.

I have requested a binNMU in #932616.

Cheers,
   Sven



Bug#932603: missing dependency on libnet1

2019-07-21 Thread Sven Joachim
Am 21.07.2019 um 08:56 schrieb Felix Zielcke:

> Package: tcptraceroute
> Version: 1.5beta7+debian-4.1
> Severity: serious
>
> I hadn't libnet1 installed due to nothing depending on it and tcptraceroute 
> failed now with:
>
> # tcptraceroute www.debian.org
> tcptraceroute: error while loading shared libraries: libnet.so.1: cannot open 
> shared object file: No such file or directory
>
> And indeed the tcptraceroute_1.5beta7+debian-4.1_amd64.deb doestn't
> have any Depends: line in DEBIAN/control.

This is a consequence of debhelper bug #932240, the package needs to be
rebuilt with a fixed debhelper.

Cheers,
   Sven



Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

2019-07-13 Thread Sven Joachim
On 2019-07-12 23:24 +0200, Diederik de Haas wrote:

> Package: grub-efi-amd64
> Followup-For: Bug #931896
>
> I don't have grub-efi-amd64 installed, but I ran into the same problem.
> The only enabled lines in /etc/default/grub are these:
> GRUB_DEFAULT=0
> GRUB_TIMEOUT=5
> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> GRUB_CMDLINE_LINUX_DEFAULT="quiet"
> GRUB_CMDLINE_LINUX=""
>
> Which, afaik, is the default.
> The versions reported are what's currently installed as with 2.04 my
> system doesn't boot.
>
> I'm not sure/don't understand what Colin meant with 'firmware'. My guess
> would be my BIOS, but I haven't changed that recently.

It is the system's firmware, called UEFI on modern systems or BIOS on
older ones, where you would install grub-pc rather than grub-efi-amd64.

> But up until version 2.04 grub2 has worked perfectly well and I don't
> recall me having configured anything manually, so I wouldn't know why
> it would be misconfigured.

Most likely you had grub configured to install to the wrong disk, this
is what happened to me.  When I installed an SSD into my old PC back in
December 2016, I copied all files from the already present hard drive,
ran "grub-install /dev/sdb" and told the BIOS to boot from the SSD
(which is /dev/sdb).  Everything was working fine until I upgraded
grub-pc to version 2.04.

What I finally figured out after getting my system to boot again, is
that grub was still configured to install its core image to /dev/sda,
the old hard disk.  This configuration is apparently only stored in the
debconf database and nowhere else.

> I can send my grub.cfg in a separate email if that would help.
> (How can I do a followup with bugreport so that the full output is
> reported as you'd get with an initial filing of a bug?)

You can run "reportbug --template grub-pc" and paste the output to your
preferred mailer.

Cheers,
   Sven



Bug#925136: help2man: FTBFS in unstable (dh_clean fails)

2019-03-22 Thread Sven Joachim
On 2019-03-21 20:45 +1100, Brendan O'Dea wrote:

> On Wed, Mar 20, 2019 at 10:21:39AM +0100, Gianfranco Costamagna wrote:
>>Looks like README needs a newer timestamp wrt help2man.PL file?
> [...]
>>dpkg-buildpackage: info: host architecture amd64
>> fakeroot debian/rules clean
>>test README -nt help2man.PL  # maintainer sanity check
>>make: *** [debian/rules:40: clean] Error 1
>
> Well this is odd, it seems that there has been a change in dpkg-source which
> breaks this particular sanity check (intended to ensure that I've run the
> maint-prep step since updating the version in help2man.PL).
>
> I suspect that it is related to reproducible builds, since the timestamps that
> ended up in the tarball have been changed to the changlog timestamp (in fact
> there are no files in the tarball with later dates).

There has indeed been such a change in dpkg-source:

,
| - Generate reproducible source tarballs by using the new GNU tar
|   --clamp-mtime option in Dpkg::Source::Archive, to make sure no file
|   in source packages has an mtime later than the changelog entry time.
`

However, that was in version 1.18.10, uploaded July 2016.

It seems that in previous versions of help2man help2man.PL was older
than debian/changelog, so you did not hit the problem.

>  ~/debian/help2man-1.47.9 $ ls -l README help2man.PL
>  -rw-r--r--   1 bodbod   540 2019-03-18 19:16 README
>  -rwxr-xr-x   1 bodbod 23166 2019-03-18 19:13 help2man.PL
>  ~/debian/help2man-1.47.9 $ tar tvJf ../help2man-1.47.9.tar.xz 
> help2man-1.47.9/README help2man-1.47.9/help2man.PL
>  -rw-r--r-- 0/0 540 2019-03-18 19:10 help2man-1.47.9/README
>  -rwxr-xr-x 0/0   23166 2019-03-18 19:10 help2man-1.47.9/help2man.PL
>  ~/debian/help2man-1.47.9 $ dpkg-parsechangelog -S Date
>  Mon, 18 Mar 2019 19:10:35 +1100
>
> I'll try to find a way to revise this check that will be more robust to this
> kind of timestamp modification.  Somewhat annoyingly, the "test" builtin has
> -nt and -ot options, but no way to test that timestamps are newer or equal (or
> even just equal).

A negated test with the -ot option might help:

! test README -ot help2man.PL # maintainer sanity check

Cheers,
   Sven



Bug#924397: corekeeper: insecure use of world-writable /var/crash

2019-03-13 Thread Sven Joachim
On 2019-03-13 20:29 +0800, Paul Wise wrote:

> On Wed, 2019-03-13 at 13:11 +0100, Jakub Wilk wrote:
>
>> Also, it looks like dpkg doesn't update directory permissions on 
>> upgrade. Ugh. :-(
>
> dpkg maintainers, do you know if this is a known bug or intentional?

Both, see #515211[1].

Cheers,
   Sven


1. https://bugs.debian.org/515211



Bug#922956: libgd-perl: no longer Provides libgd-gd2-noxpm-perl and libgd-gd2-perl

2019-02-22 Thread Sven Joachim
Package: libgd-perl
Version: 2.71-1
Severity: serious

In the switch from cdbs to dh (commit f8669559ff6c), libgd-perl lost its
Provides for libgd-gd2-noxpm-perl and libgd-gd2-perl.  This breaks
various reverse dependencies.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-rc7-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgd-perl depends on:
ii  libc6   2.28-7
ii  libgd3  2.2.5-5.1
ii  perl5.28.1-4
pn  perlapi-5.28.1  

libgd-perl recommends no packages.

libgd-perl suggests no packages.

-- no debconf information



Bug#921763: weston: FTBFS (dh_install: missing files)

2019-02-09 Thread Sven Joachim
On 2019-02-08 21:19 +, Santiago Vila wrote:

> Package: src:weston
> Version: 5.0.0-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster but it failed:
> [...]
> dh_install: Cannot find (any matches for) "usr/lib/*/weston/cms-colord.so" 
> (tried in ., debian/tmp)
>
> dh_install: weston missing files: usr/lib/*/weston/cms-colord.so
> dh_install: Cannot find (any matches for) "usr/lib/*/weston/cms-static.so" 
> (tried in ., debian/tmp)
>
> dh_install: weston missing files: usr/lib/*/weston/cms-static.so
> dh_install: missing files, aborting
> make[1]: *** [debian/rules:13: override_dh_install] Error 25

Thanks for the report.  This is a consequence of the latest colord
upload where libcolord-dev dropped its dependency on liblcms2-dev.
Adding the latter to Build-Depends, which I have just done in git, fixes
the problem.

Cheers,
   Sven



Bug#911515: dvtm in backports

2019-02-06 Thread Sven Joachim
On 2019-01-17 21:28 +, Dmitry Bogatov wrote:

> Hello?

Hello.

Apologies for not replying sooner.  Your mail from October[1] never
reached me, and during the past three weeks I have been rather ill.

> Dear maintainer of ncurses, could you please upload a backport of
> ncurses-term?

I am afraid this will be difficult.  For starters, ncurses 6.1 has
introduced a new terminfo format, and several important libraries in
stretch such as libslang2 are not compatible with it.  So it is not
advisable to just rebuild the buster ncurses package on stretch.

It would be possible to build the terminfo database in the old format,
but that requires a few non-trivial packaging changes, and I would not
be comfortable to upload such a package to backports when these changes
had never been tested in unstable.

Maybe you could re-add the missing terminfo files in the dvtm backport?
In that case, they should be installed under /lib/terminfo rather than
under /usr/share/terminfo to avoid clashes with the files in
ncurses-term.

Cheers,
   Sven


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911515#10



Bug#921221: icmake,icmake-doc: both ship /usr/share/man/man1/icmun.1.gz

2019-02-03 Thread Sven Joachim
On 2019-02-03 09:32 -0800, tony mancill wrote:

> On Sun, Feb 03, 2019 at 11:44:41AM +0100, Andreas Beckmann wrote:
>> Package: icmake,icmake-doc
>> Version: 9.02.08-1
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: piuparts   
>>  
>>
>> 
>> Hi,
>> 
>> both icmake and icmake-doc ship /usr/share/man/man1/icmun.1.gz, that
>> file should probably go into the icmake package only.
>> 
>>   Preparing to unpack .../icmake-doc_9.02.08-1_all.deb ...
>>   Unpacking icmake-doc (9.02.08-1) ...
>>   dpkg: error processing archive 
>> /var/cache/apt/archives/icmake-doc_9.02.08-1_all.deb (--unpack):
>>trying to overwrite '/usr/share/man/man1/icmun.1.gz', which is also in 
>> package icmake 9.02.08-1
>>   Errors were encountered while processing:
>>/var/cache/apt/archives/icmake-doc_9.02.08-1_all.deb
>
> Hi Andreas,
>
> Thank you for the bug report.  I'm trying to reproduce this locally, but
> when I build the binary packages in a clean chroot, there are no
> manpages in the icmake-doc package:
>
> $ debc icmake_9.02.08-1_amd64.changes icmake-doc | grep -i man
> (no output)
>
> All of the manpages are found in the icmake package:
>
> $ debc icmake_9.02.08-1_amd64.changes icmake | grep -i man
> drwxr-xr-x root/root 0 2019-02-02 15:19 ./usr/share/man/
> drwxr-xr-x root/root 0 2019-02-02 15:19 ./usr/share/man/man1/
> -rw-r--r-- root/root 14962 2019-02-02 15:19 
> ./usr/share/man/man1/icmake.1.gz
> -rw-r--r-- root/root  3998 2019-02-02 15:19 
> ./usr/share/man/man1/icmbuild.1.gz
> -rw-r--r-- root/root  2846 2019-02-02 15:19 
> ./usr/share/man/man1/icmstart.1.gz
> drwxr-xr-x root/root 0 2019-02-02 15:19 ./usr/share/man/man7/
> -rw-r--r-- root/root  4820 2019-02-02 15:19 
> ./usr/share/man/man7/icmconf.7.gz
> -rw-r--r-- root/root  1606 2019-02-02 15:19 
> ./usr/share/man/man7/icmstart.rc.7.gz
> lrwxrwxrwx root/root 0 2019-02-02 15:19 
> ./usr/share/man/man1/icmun.1.gz -> icmake.1.gz
>
> Just making sure that debc isn't telling me the wrong thing, I checked
> the contents of the .debs I built:
>
> $ dpkg -x ./icmake-doc_9.02.08-1_all.deb foo
> $ find foo/ | grep man | wc -l
> 0
>
> But when I check the binary built by the buildds from the source
> package, I see:
>
> $ dpkg -x 
> /var/cache/apt-cacher-ng/debrep/pool/main/i/icmake/icmake-doc_9.02.08-1_all.deb
>  bar
>
> $ find bar/ | grep -i man
> bar/usr/share/man
> bar/usr/share/man/man1
> bar/usr/share/man/man1/icmun.1.gz
>
> So I'll need to look into why the binary package built by the buildds is
> different than what gbp builds for me locally.  I use gbp with the
> --source-only-changes option like so:
>
>  gbp buildpackage --git-pbuilder --git-pbuilder-options=--source-only-changes
>
> I question why/how a single manpage from icmake could end up in the
> icmake-doc binary - it seems like it would be all of them if it was a
> packaging bug.  Is there a chance that there is some sort of race/reuse
> on the buildds?

No, your dh_link override is broken.  This is what you have in
debian/rules:

,
| override_dh_link:
|   dh_link usr/share/man/man1/icmake.1.gz usr/share/man/man1/icmun.1.gz
`

Like most debhelper commands, dh_link acts upon the first package it
finds by default.  In a full or arch-only build this is the icmake
package, but in an arch-indep build it is icmake-doc, since icmake is
not built then.  Use "dpkg-buildpackage -A" to see for yourself.

The solution is to use override_dh_link-arch instead of
override_dh_link.  Or create an icmake.links file and drop the override.

Cheers,
   Sven



Bug#918316: nocache: FTBFS in sid

2019-01-04 Thread Sven Joachim
On 2019-01-04 22:49 +, Santiago Vila wrote:

> Package: src:nocache
> Version: 1.1-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in sid but it failed:
>
> 
> [...]
>  debian/rules build-arch
> dh build-arch
>dh_update_autotools_config -a
>dh_autoreconf -a
>dh_auto_configure -a
>dh_auto_build -a
>   make -j1 "INSTALL=install --strip-program=true"
> make[1]: Entering directory '/<>'
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -o cachedel cachedel.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -o cachestats cachestats.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -fPIC -c -o nocache.o nocache.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -fPIC -c -o fcntl_helpers.o fcntl_helpers.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -fPIC -c -o pageinfo.o pageinfo.c
> cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -pthread -shared -Wl,-soname,nocache.so -o nocache.so 
> nocache.o fcntl_helpers.o pageinfo.o -ldl
> sed 's!##libdir##!$(dirname "$0")!' nocache
> chmod a+x nocache
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> ## #916415
> timeout 11 ./nocache apt show coreutils 1>>/dev/null
>
> WARNING: apt does not have a stable CLI interface. Use with caution in 
> scripts.
>
> make[1]: *** [debian/rules:21: override_dh_auto_test] Error 124

I get a different error here:

,
| ## #916415
| timeout 11 ./nocache apt show coreutils 1>>/dev/null
| apt: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
| Aborted
| make[1]: *** [debian/rules:21: override_dh_auto_test] Error 134
`

Increasing the timeout to 60 as you suggested does not help.

Cheers,
   Sven



Bug#916074: pcc: useless without libpcc-dev

2018-12-09 Thread Sven Joachim
Package: pcc
Version: 1.2.0~DEVEL+20181202-1
Severity: serious
Control: block -1 by 915633

Without libpcc-dev, pcc cannot compile any but the most trivial C
programs (e.g. #including  causes the preprocessor to complain
about a missing stddef.h) and cannot link any C program because ld fails
to find crtbegin.o.

For this reason I think that libpcc-dev should be bumped from Recommends
to Depends.  Of course this requires pcc-libs to be uploaded to unstable
and to be built on all (release) architectures where pcc is currently
available.  The initial upload to experimental FTBFS everywhere except
on amd64 (see #915633).


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.20.0-rc5-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pcc depends on:
ii  libc6  2.28-2

Versions of packages pcc recommends:
ii  libpcc-dev  1.2.0~DEVEL+20180604-1

pcc suggests no packages.

-- no debconf information



Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory

2018-11-20 Thread Sven Joachim
On 2018-11-20 09:19 +0200, Timo Aaltonen wrote:

> On 20.11.2018 9.04, Mathieu Malaterre wrote:
>> Package: mesa-common-dev
>> Version: 18.2.5-1
>> Severity: serious
>> Tags: ftbfs
>> 
>> OpenVDB fails to build from source because of:
>> 
>> In file included from /usr/include/GL/gl.h:2055,
>>  from viewer/Font.h:40,
>>  from viewer/Font.cc:31:
>> /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No
>> such file or directory
>>  #include 
>>   ^~~
>> compilation terminated.
>> 
>> ref:
>> https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=5.2.0-5=154226=0
>> 
>> It would be nice to fix this, upstream seems to have provided a patch:
>> 
>> https://bugs.freedesktop.org/show_bug.cgi?id=107511
>
> That commit is in 18.2.5:
>
> commit 2645ea5817f4fd05905b8deda96c268cd69fa48c
> Author: Eric Engestrom 
> Date:   Tue Aug 7 12:56:25 2018 +0100
>
> configure: install KHR/khrplatform.h when needed
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511
> Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)"
> Signed-off-by: Eric Engestrom 
> Tested-by: Brad King 
> Reviewed-by: Emil Velikov 
> (cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f)
>
> so something else is wrong.

KHR/khrplatform.h is installed, but into libegl1-mesa-dev, on which
mesa-common-dev does not currently depend.

Cheers,
   Sven



Bug#912544: libomp-7-dev: conflicts with libomp-dev which depends on it

2018-11-01 Thread Sven Joachim
Package: libomp-7-dev
Version: 1:7-6
Severity: serious

In the latest llvm-defaults upload libomp-dev depends on libomp-7-dev, but
libomp-7-dev conflicts with libomp-dev, so the latter is not installable.



Bug#911510: nfs-utils: scripts using rpcinfo don't find it

2018-10-22 Thread Sven Joachim
Control: severity -1 serious
Control: reassign -1 rpcbind 1.2.5-0.1
Control: retitle -1 rpcbind: changed location of rpcinfo breaks nfs-utils

Am 21.10.2018 um 09:54 schrieb Elimar Riesebieter:

> Source: nfs-utils
> Version: 1.3.4-2.2
> Severity: grave
> Tags: patch
> Justification: renders package unusable
>
>
> bug- and initscripts using rpcinfo are looking in $PREFIX/sbin.
> Since rpcbind installs rpcinfo in $PREFIX/bin we need to adjust the
> scripts as proposed in the attached patch.

It would also be necessary to add adjust the dependency on rpcbind to
(>= 1.2.5), since earlier versions of rpcbind installed rpcinfo in
/usr/sbin.  And rpcbind would need a versioned Breaks on
nfs-{common,kernel-server}.

> Or we need to change rpcbind to install rpcinfo in $PREFIX/sbin

That's where it was before the rpcbind NMUs.  Certainly /usr/bin is a
more logical place for rpcinfo; the reason why it was put into /usr/sbin
is that libc-bin versions before 2.16 used to ship /usr/bin/rpcinfo.
See also #707589 on that topic.

Cheers,
   Sven



Bug#911056: chromium,webext-browserpass: impossible to install chromium and webext-browserpass together

2018-10-15 Thread Sven Joachim
On 2018-10-15 10:12 +0200, Jonas Smedegaard wrote:

> Package: chromium,webext-browserpass
> Severity: serious
> Justification: 7
>
> With chromium 70.0.3538.54-1 and webext-browserpass 2.0.11+dfsg-2 installed,
> attempting to upgrade to chromium 70.0.3538.54-2 fails:
>
> Gør klar til at udpakke .../chromium_70.0.3538.54-2_amd64.deb ...
> Udpakker chromium (70.0.3538.54-2) over (70.0.3538.54-1) ...
> dpkg: advarsel: chromium: konfigurationsfil '/etc/chromium' er hverken en 
> almindelig fil eller symbolsk lænke (= '/etc/chromium')
> dpkg: fejl under behandling af arkivet 
> /var/cache/apt/archives/chromium_70.0.3538.54-2_amd64.deb (--unpack):
>  forsøger at overskrive kataloget '/etc/chromium' i pakken webext-browserpass 
> 2.0.11+dfsg-2 med ikke-katalog
> dpkg-deb: fejl: indsæt subprocess was killed by signal (Kanalen blev brudt)
> dpkg: overvejer at afkonfigurere chromium, som ville være i konflikt med 
> installation af chromium-common ...
> dpkg: ja, vil afkonfigurere chromium (ødelagt af chromium-common)
> Gør klar til at udpakke .../chromium-common_70.0.3538.54-2_amd64.deb ...
> Afkonfigurerer chromium (70.0.3538.54-1) ...
> Udpakker chromium-common (70.0.3538.54-2) over (70.0.3538.54-1) ...
> Der opstod fejl under behandlingen:
>  /var/cache/apt/archives/chromium_70.0.3538.54-2_amd64.deb
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Sætter chromium-common (70.0.3538.54-2) op ...
> dpkg: afhængighedsproblemer forhindrer konfiguration af chromium:
>  chromium afhænger af chromium-common (= 70.0.3538.54-1); men:
>   Version af chromium-common på systemet er 70.0.3538.54-2.
>  chromium-common (70.0.3538.54-2) ødelægger chromium (<< 70.0.3538.54-2) og 
> er installeret.
>   Versionen af chromium, der skal sætte op, er 70.0.3538.54-1.
>
> Above is in danish, but I guess the essence is noticable for english speakers:
> /etc/chromium is somehow "owned" by both packages,
> which causes trouble (now that chromium adds a conffile, I guess).

Actually the problem is that chromium 70.0.3538.54-2 introduces
/etc/chromium as a conffile while webext-browserpass (and other
packages) ship it as a directory.

,
| $ apt-file search etc/chromium/
| chrome-gnome-shell: 
/etc/chromium/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
| debian-edu-config: /etc/chromium/policies/managed/chromium-networked-prefs
| plasma-browser-integration: 
/etc/chromium/native-messaging-hosts/org.kde.plasma.browser_integration.json
| webext-browserpass: 
/etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json
`

Cheers,
   Sven



Bug#872806: libgpg-error0 packs runtime support files in shared library

2018-10-12 Thread Sven Joachim
Control: tags -1 + patch

Am 21.08.2017 um 14:53 schrieb Helmut Grohne:

> Package: libgpg-error0
> Version: 1.27-3
> Severity: serious
> Justification: policy 8.2
> User: helm...@debian.org
> Usertags: rebootstrap
>
> libgpg-error0 packs runtime support files (i.e. .mo files) into the
> shared library package. It happens that these files are not versioned
> (e.g. libgpg-error.mo rather than libgpg-error0.mo). Doing so violates
> Debian policy section 8.2:
>
> |If your package contains files whose names do not change with each change
> |in the library shared object version, you must not put them in the shared
> |library package. Otherwise, several versions of the shared library cannot
> |be installed at the same time without filename clashes, making upgrades
> |and transitions unnecessarily difficult.

There are a few other library package which include .mo files, but most
include the soname in their filename, so they don't have that problem.

> This happens to also break multiarch. Rebuilds of libgpg-error are not
> currently coinstallable with other instances from the archive:
>
> | Unpacking libgpg-error-dev:ppc64 (1.27-3) ...
> | dpkg: error processing archive 
> /tmp/repo/pool/main/libg/libgpg-error/libgpg-error0_1.27-3_ppc64.deb 
> (--unpack):
> |  trying to overwrite shared
> | '/usr/share/locale/cs/LC_MESSAGES/libgpg-error.mo', which is
> | different from other instances of package libgpg-error0:ppc64
> | Errors were encountered while processing:
> |  /tmp/repo/pool/main/libg/libgpg-error/libgpg-error0_1.27-3_ppc64.deb
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> | E: Failed to process build dependencies

This was apparently due to some changes in msgfmt's output format at the
time.  It does not seem to be a problem currently, but future changes in
msgfmt might bring it up again.

> I suggest moving them to an Arch:all package.

Attached is a patch which does that, introducing a libgpg-error-l10n
package with the translation files.  The exact Provides/Replaces
versions might have to be adjusted, and the exact relationship between
libgpg-error0 and libgpg-error-l10n is also debatable.  I have chosen an
unversioned Recommends, but others are also possible.  What would not
work is an exact "Depends: libgpg-error-l10n (= ${source:Version}),
since that breaks when libgpg-error1 comes along.

Cheers,
   Sven

>From da01ec471e451de75415589bb5ba942599ee5d26 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Fri, 12 Oct 2018 11:25:02 +0200
Subject: [PATCH] Move the translation files to a new libgpg-error-l10n package

Closes: #872806
---
 debian/control   | 22 ++
 debian/libgpg-error-l10n.install |  1 +
 debian/libgpg-error0.install.in  |  1 -
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 debian/libgpg-error-l10n.install

diff --git a/debian/control b/debian/control
index 1ff8e2e..ec14e5c 100644
--- a/debian/control
+++ b/debian/control
@@ -43,6 +43,8 @@ Depends:
  ${shlibs:Depends},
 Pre-Depends:
  ${misc:Pre-Depends},
+Recommends:
+ libgpg-error-l10n,
 Description: GnuPG development runtime library
  Library that defines common error values, messages, and common
  runtime functionality for all GnuPG components.  Among these are GPG,
@@ -102,3 +104,23 @@ Description: library of error values and messages in GnuPG (Windows development)
  This is a Windows version of libgpg-error.  It's meant to be used
  when cross-building software that targets the Windows platform,
  e.g. the win32-loader component of Debian-Installer.
+
+Package: libgpg-error-l10n
+Architecture: all
+Section: localization
+Multi-Arch: foreign
+Depends:
+ ${misc:Depends},
+Replaces:
+ libgpg-error0 (<< 1.32-1.1~),
+Breaks:
+ libgpg-error0 (<< 1.32-1.1~),
+Description: library of error values and messages in GnuPG (localization files)
+ Library that defines common error values, messages, and common
+ runtime functionality for all GnuPG components.  Among these are GPG,
+ GPGSM, GPGME, GPG-Agent, libgcrypt, pinentry, SmartCard Daemon and
+ possibly more in the future.
+ .
+ It will likely be renamed "gpgrt" in the future.
+ .
+ This package contains the translation files for the use in non-English locales.
diff --git a/debian/libgpg-error-l10n.install b/debian/libgpg-error-l10n.install
new file mode 100644
index 000..3635480
--- /dev/null
+++ b/debian/libgpg-error-l10n.install
@@ -0,0 +1 @@
+usr/share/locale
diff --git a/debian/libgpg-error0.install.in b/debian/libgpg-error0.install.in
index ebdeae6..eea2676 100644
--- a/debian/libgpg-error0.install.in
+++ b/debian/libgpg-error0.install.in
@@ -1,2 +1 @@
 usr/lib/@DEB_HOST_MULTIARCH@/libgpg-error.so.* lib/@DEB_HOST_MULTIARCH@/
-usr/share/locale
-- 
2.19.1



Bug#910217: apparmor: removed shipped file: /var/cache/apparmor/CACHEDIR.TAG

2018-10-12 Thread Sven Joachim
Control: tags -1 + patch

On 2018-10-03 17:33 +0200, Andreas Beckmann wrote:

> Package: apparmor
> Version: 2.13-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package removes files that
> it has shipped.
>
> From the attached log (scroll to the bottom...):
>
> 0m35.9s ERROR: FAIL: debsums reports modifications inside the chroot:
>   debsums: missing file /var/cache/apparmor/CACHEDIR.TAG (from apparmor 
> package)
>
>
> This was observed after a stretch->buster upgrade.

Attached is a patch (untested).

Cheers,
   Sven

>From 6c6d71192d2b1dc0ec47757f8c6acaf0c85a079e Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Fri, 12 Oct 2018 10:54:04 +0200
Subject: [PATCH] Do not remove /var/cache/apparmor/CACHEDIR.TAG on upgrades

Closes: #910217
---
 debian/apparmor.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/apparmor.postinst b/debian/apparmor.postinst
index 7fefe18c..28cb4c78 100644
--- a/debian/apparmor.postinst
+++ b/debian/apparmor.postinst
@@ -32,7 +32,7 @@ case "$1" in
 	# since 2.13-1 apparmor_parser won't create cache files at the root
 	# of the cache-loc, but instead in sub-directories.
 	if dpkg --compare-versions "$2" lt-nl "2.13-7"; then
-		find /var/cache/apparmor -maxdepth 1 -type f -delete
+		find /var/cache/apparmor -maxdepth 1 -type f '!' -name CACHEDIR.TAG -delete
 	fi
 
 	# Try to determine values for apparmor/homedirs if the administrator
-- 
2.19.1



Bug#896487: datamash FTBFS on !x86/ia64: FAIL: tests/datamash-output-format

2018-10-12 Thread Sven Joachim
Control: tags -1 + fixed-upstream patch

On 2018-04-21 19:05 +0300, Adrian Bunk wrote:

> Source: datamash
> Version: 1.3-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=datamash=sid
>
> ...
> FAIL: tests/datamash-output-format
> ==
>
> datamash (GNU datamash) 1.3
> Copyright (C) 2018 Assaf Gordon
> License GPLv3+: GNU GPL version 3 or later 
> .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Assaf Gordon.
> r1...
> r2...
> r3...
> r4...
> r5...
> r6...
> r7...
> r8...
> r9...
> f1...
> f2...
> f3...
> f4...
> f5...
> f6...
> f7...
> g1...
> g2...
> g3...
> g4...
> g5...
> g6...
> g7...
> e1...
> e2...
> a1...
> datamash-output-format.pl: test a1: stdout mismatch, comparing a1.2 
> (expected) and a1.O (actual)
> *** a1.2  Sun Apr 15 12:44:18 2018
> --- a1.O  Sun Apr 15 12:44:18 2018
> ***
> *** 1 
> ! 0x8.000p-3
> --- 1 
> ! 0x1.000p+0
> m1...
> m2...
> FAIL tests/datamash-output-format.pl (exit status: 1)
> ...
> 
> Testsuite summary for GNU datamash 1.3
> 
> # TOTAL: 20
> # PASS:  17
> # SKIP:  2
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to assafgor...@gmail.com
> 
> Makefile:3168: recipe for target 'test-suite.log' failed
> make[5]: *** [test-suite.log] Error 1

Should be fixed by commit d446dba317[1] ("tests: fix --format='%4000f'
expected output").

Cheers,
   Sven


1. 
https://git.savannah.gnu.org/cgit/datamash.git/commit/?id=d446dba317aa067440d6312d955d523129949327

>From d446dba317aa067440d6312d955d523129949327 Mon Sep 17 00:00:00 2001
From: Assaf Gordon 
Date: Thu, 22 Mar 2018 11:00:34 -0600
Subject: [PATCH 1/1] tests: fix --format='%4000f' expected output

Can be 1.09... or 1.08999, depending on representation.

* tests/datamash-output-format.pl: Check only the first 5 digits.
---
 tests/datamash-output-format.pl | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/datamash-output-format.pl b/tests/datamash-output-format.pl
index 52c68a2..ca99bb0 100755
--- a/tests/datamash-output-format.pl
+++ b/tests/datamash-output-format.pl
@@ -98,12 +98,13 @@ my @Tests =
{OUT => "0" x 3999 . "1\n"}],
 
   # due to binary floating representation, some decimal point digits won't be
-  # zero (e.g. 1.09052345325432000...).
-  # The OUT_SUBST replaces exactly 3994 digits (as expected from the format)
+  # zero (e.g. 1.09052345325432000... or
+  # 1.0899...).
+  # The OUT_SUBST replaces exactly 3995 digits (as expected from the format)
   # with an "X".
   ['m2', '--format "%.4000f"   sum 1',  {IN_PIPE=>$in1},
-   {OUT => "1.09X\n"},
-   {OUT_SUBST => 's/^(1\.09)([0-9]{3994})$/\1X/'}],
+   {OUT => "1.0X\n"},
+   {OUT_SUBST => 's/^(1\.0)([0-9]{3995})$/\1X/'}],
 
 );
 
-- 
2.19.1



Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"

2018-10-05 Thread Sven Joachim
Control: found -1 1.4.7-3

On 2018-10-05 03:08 +0100, Olly Betts wrote:

> On Tue, Oct 02, 2018 at 11:10:46PM +0200, Sven Joachim wrote:
>> Indeed, but that needs to be fixed in libxapian30's shlibs file.
>
> Fixed there by xapian-core 1.4.7-3.

Unfortunately it is not really fixed:

,
| $ cat /var/lib/dpkg/info/libxapian30:amd64.shlibs 
| libxapian 30 libxapian30
`

In debian/changelog you mentioned

,
|   * debian/rules: Generate shlibs.local so that reverse dependencies get a
| versioned dependency on libxapian30 based on the version when the ABI
| last changed. (Closes: #910110)
`

But shlibs.local only influences binaries built from the same source
package.  Instead of shlibs.local, you probably want to generate
libxapian30.shlibs - see dh_makeshlibs(1).

>> Then aptitude (and other reverse dependencies of libxapian30 that
>> might be affected) can be rebuilt to pick up the changed dependency.
>
> I've pulled out a list of the packages which need rebuilding from the
> buildinfo files on mirror.ftp-master.d.o (anything built against
> libxapian-dev 1.4.6-1 or higher which doesn't already have a suitably
> versioned dependency):
>
> 07/10/pinot_1.05-2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1),
> 07/10/zeitgeist_1.0.1-0.2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1),
> 08/08/maildir-utils_1.0-6_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 08/17/baloo-kf5_5.49.0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 08/28/recoll_1.24.1-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/06/plasma-desktop_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/06/plasma-workspace_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/07/aptitude_0.8.11-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 09/29/packagesearch_2.7.9_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/02/cyrus-imapd_2.5.11-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/03/akonadiconsole_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/03/akonadi-search_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/04/notmuch_0.28~rc0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2),
> 10/05/libsearch-xapian-perl_1.2.25.2-1_kfreebsd-amd64.buildinfo: 
> libxapian-dev (= 1.4.7-2),

Thanks for your research.

> I'll request rebuilds once 1.4.7-3 has built on most architectures,
> and recheck the latest buildinfo files in case anything gets built
> against the current libxapian-dev before the new one propagates
> everywhere.

The rebuilds should be scheduled with a dep-wait for libxapian-dev (>=
1.4.7-4) if that version indeed fixes the bug (see
https://release.debian.org/wanna-build.html).

Cheers,
   Sven



Bug#910305: easyloggingpp FTBFS: configure: error: cannot find install-sh, install.sh, or shtool in build-aux ".."/build-aux

2018-10-04 Thread Sven Joachim
Am 04.10.2018 um 18:53 schrieb Helmut Grohne:

> Source: easyloggingpp
> Version: 9.96.5+dfsg-1
> Severity: serious
> Tags: ftbfs
>
> easyloggingpp fails to build from source in unstable. The build log
> essentially looks like this:
>
> | dpkg-buildpackage: info: source package easyloggingpp
> | dpkg-buildpackage: info: source version 9.96.5+dfsg-1
> | dpkg-buildpackage: info: source distribution unstable
> | dpkg-buildpackage: info: source changed by Stephen Kitt 
> |  dpkg-source --before-build .
> | dpkg-buildpackage: info: host architecture amd64
> |  debian/rules clean
> | dh clean
> |dh_clean
> |  debian/rules binary
> | dh binary
> |dh_update_autotools_config
> |dh_autoreconf
> |debian/rules override_dh_auto_configure
> | make[1]: Entering directory '/<>'
> | mkdir gtest-build
> | cp -a /usr/src/googletest/googletest gtest-source
> | dh_auto_configure -Dgtest-source -Bgtest-build
> | cd gtest-build && ../gtest-source/configure 
> --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include 
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info 
> --sysconfdir=/etc --localstatedir=/var --disable-silent-rules 
> --libdir=\${prefix}/lib/x86_64-linux-gnu 
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
> --disable-maintainer-mode --disable-dependency-tracking
> | configure: WARNING: unrecognized options: --disable-maintainer-mode
> | configure: error: cannot find install-sh, install.sh, or shtool in 
> build-aux ".."/build-aux
> | cd gtest-build && tail -v -n \+0 config.log
> | ==> config.log <==
> | ...
> | dh_auto_configure: cd gtest-build && ../gtest-source/configure 
> --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include 
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info 
> --sysconfdir=/etc --localstatedir=/var --disable-silent-rules 
> --libdir=\${prefix}/lib/x86_64-linux-gnu 
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
> --disable-maintainer-mode --disable-dependency-tracking returned exit code 1
> | make[1]: *** [debian/rules:13: override_dh_auto_configure] Error 2
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:7: binary] Error 2
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
>
> This looks like some dependency changed possibly debhelper or autoconf
> or something.

Almost certainly it is has been triggered by the recent upload of
googletest, since the gtest-source directory is just a copy (via cp -a)
of /usr/src/googletest/googletest.  Looks like that googletest upload
broke out-of-tree builds.

Cheers,
   Sven



Bug#909860: xserver-xorg-video-intel FTBFS on i386 with gcc 8

2018-09-29 Thread Sven Joachim
On 2018-09-29 20:21 +0300, Adrian Bunk wrote:

> Source: xserver-xorg-video-intel
> Version: 2:2.99.917+git20171229-1
> Severity: serious
> Tags: ftbfs
>
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/i386/xserver-xorg-video-intel.html
> https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intel=i386=2%3A2.99.917%2Bgit20180925-1=1537881787=0
>
> ...
> In file included from ../../../src/sna/gen4_vertex.c:34:
> ../../../src/sna/gen4_vertex.c: In function 'emit_vertex':
> ../../../src/sna/sna_render_inline.h:40:26: error: inlining failed in call to 
> always_inline 'vertex_emit_2s': target specific option mismatch
>  static force_inline void vertex_emit_2s(struct sna *sna, int16_t x, int16_t 
> y)
>   ^~
> ../../../src/sna/gen4_vertex.c:308:25: note: called from here
>  #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX assert(!too_large(x, 
> y)); */
>  ^~~~
> ../../../src/sna/gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX'
>   OUT_VERTEX(dstX, dstY);
>   ^~
> make[5]: *** [Makefile:695: gen4_vertex.lo] Error 1

It seems that Fedora and openSUSE have stumbled upon this earlier:

https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/c/f2e86334f3a168b04afddb57d4bc4f630e59a5e9
https://bugzilla.suse.com/show_bug.cgi?id=1092541

Disclaimer: I don't really have an informed opinion here.

Cheers,
   Sven



Bug#909762: debhelper 11.4 makes dublin-traceroute FTBFS

2018-09-27 Thread Sven Joachim
On 2018-09-27 23:20 +0300, Adrian Bunk wrote:

> Package: debhelper
> Version: 11.4
> Severity: serious
> Control: affects -1 src:dublin-traceroute
>
> https://buildd.debian.org/status/package.php?p=dublin-traceroute=sid
>
> ...
>dh_install -a
>   install -d debian/dublin-traceroute//usr/bin
>   cp --reflink=auto -a debian/tmp/usr/bin/dublin-traceroute 
> debian/dublin-traceroute//usr/bin/
> dh_install: Cannot find (any matches for) 
> "usr/lib/libdublintraceroute.so.0.*" (tried in ., debian/tmp)
>
> dh_install: libdublintraceroute0 missing files: 
> usr/lib/libdublintraceroute.so.0.*
> dh_install: Cannot find (any matches for) "usr/lib/libdublintraceroute.so" 
> (tried in ., debian/tmp)
>
> dh_install: libdublintraceroute-dev missing files: 
> usr/lib/libdublintraceroute.so
> dh_install: missing files, aborting
>   install -d debian/.debhelper/generated/dublin-traceroute
>   install -d debian/.debhelper/generated/libdublintraceroute0
>   install -d debian/.debhelper/generated/libdublintraceroute-dev
> make: *** [debian/rules:8: binary-arch] Error 25

This is apparently a side effect of the fix for #903042 (commit bab43d46,
"cmake: Explicitly set CMAKE_INSTALL_LIBDIR").  The Debian changelog
entry says "This should not make any pratical difference" but for
dublin-traceroute it does.  That's because its CMakeLists.txt has the
following three lines:

if (NOT CMAKE_INSTALL_LIBDIR)
set(CMAKE_INSTALL_LIBDIR "lib")
endif()

So it did not install the libraries into a multiarch directory before,
but now that CMAKE_INSTALL_LIBDIR is explicitly set it does, and the
debian/*.install files are of course not prepared for that.

Cheers,
   Sven



Bug#909089: debhelper: GNU configure $prefix expanded too early?

2018-09-18 Thread Sven Joachim
On 2018-09-18 14:09 +0300, Peter Pentchev wrote:

> Package: debhelper
> Version: 11.4
> Severity: serious
>
> Hi,
>
> Thanks for maintaining and extending debhelper!
>
> I don't have much information right now, maybe I'll look into it in
> the evening (Eastern European time), but trying to build gforth in
> a chroot containing debhelper-11.4 results in a package where all
> the paths passed to the GNU configure script as "\$prefix/something"
> are actually defined as "/something", thus placing binaries in /bin,
> include files in /include, etc.  Installing debhelper-11.3.5 fixes
> the problem.

Bisection shows that commit a7ec05c10093f ("dh: Track which options have
been passed") has triggered the problem.  I had a look at the gforth
build logs with debhelper 11.3.5 and 11.4, but could not spot an obvious
cause.  Maybe Niels has more luck.

Cheers,
   Sven



Bug#908298: libgdk-pixbuf2.0-0: FTBFS on i386: Directory $'/<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu' does not seem to be a Meson build directory.

2018-09-08 Thread Sven Joachim
Control: tags -1 + patch

On 2018-09-08 09:10 +0200, Sven Joachim wrote:

> Source: gdk-pixbuf
> Version: 2.38.0+dfsg-2
> Severity: serious
> Tags: ftbfs
>
> The attempt to fix the test timeouts on slow arches in 2.38.0+dfsg-2 has
> introduced a new FTBFS problem on i386[1]:
>
> ,
> |debian/rules override_dh_auto_test
> | make[1]: Entering directory '/<>/gdk-pixbuf-2.38.0+dfsg'
> | # on slow arches the "slow" tests take longer than the timeout allowed
> | # by upstream; allow even more time (-t is a multipiler)
> | meson test -C /<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu -t 5
> | Only ninja backend is supported to rebuild tests before running them.
> | Meson test encountered an error:
> | 
> | Directory $'/<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu' does 
> not seem to be a Meson build directory.
> | make[1]: *** [debian/rules:26: override_dh_auto_test] Error 1
> `
>
> Will send a patch as soon as I have the bug number.

Here it is, tested in an i386 sbuild chroot. :-)

>From 8d9f4796631dadb3bb7942ce1d1602940366bca3 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sat, 8 Sep 2018 09:15:54 +0200
Subject: [PATCH] Fix FTBFS on any-i386

The build directory is named after $(DEB_HOST_GNU_TYPE) rather than
$(DEB_HOST_MULTIARCH), and on any-i386 those are different.

Closes: #908298
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 88301a7c..dd9dac7a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,7 @@ infiles := \
 override_dh_auto_test:
 	# on slow arches the "slow" tests take longer than the timeout allowed
 	# by upstream; allow even more time (-t is a multipiler)
-	meson test -C $(CURDIR)/obj-$(DEB_HOST_MULTIARCH) -t 5
+	meson test -C $(CURDIR)/obj-$(DEB_HOST_GNU_TYPE) -t 5
 
 override_dh_install:
 	find $(CURDIR)/debian/tmp -name *.la -print -delete
-- 
2.19.0.rc2



Bug#908298: libgdk-pixbuf2.0-0: FTBFS on i386: Directory $'/<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu' does not seem to be a Meson build directory.

2018-09-08 Thread Sven Joachim
Source: gdk-pixbuf
Version: 2.38.0+dfsg-2
Severity: serious
Tags: ftbfs

The attempt to fix the test timeouts on slow arches in 2.38.0+dfsg-2 has
introduced a new FTBFS problem on i386[1]:

,
|debian/rules override_dh_auto_test
| make[1]: Entering directory '/<>/gdk-pixbuf-2.38.0+dfsg'
| # on slow arches the "slow" tests take longer than the timeout allowed
| # by upstream; allow even more time (-t is a multipiler)
| meson test -C /<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu -t 5
| Only ninja backend is supported to rebuild tests before running them.
| Meson test encountered an error:
| 
| Directory $'/<>/gdk-pixbuf-2.38.0+dfsg/obj-i386-linux-gnu' does not 
seem to be a Meson build directory.
| make[1]: *** [debian/rules:26: override_dh_auto_test] Error 1
`

Will send a patch as soon as I have the bug number.


1. 
https://buildd.debian.org/status/fetch.php?pkg=gdk-pixbuf=i386=2.38.0%2Bdfsg-2=1536340844=0



Bug#907997: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25 25.2+1-6+b2

2018-09-07 Thread Sven Joachim
Control: tags -1 + patch

On 2018-09-05 01:18 +0200, Axel Beckert wrote:

> Hi again,
>
> Axel Beckert wrote:
>> I'm sorry, but the Breaks/Replaces headers still seem incomplete. I just
>> experienced the following upgrade failure when I wanted to switch from
>> emacs25 to emacs-lucid on a Raspberry Pi running Buster/Testing arm64:
> […]
>> dpkg: error processing archive 
>> /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-11_arm64.deb (--unpack):
>>  trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in 
>> package emacs25 25.2+1-6+b2
>
> This is more or less the same issue as https://bugs.debian.org/904957
> which either hasn't been fixed correctly or the fix has been removed
> already again.

The former.  The attached patch should fix that, but I have not tested
it at all.

Cheers,
   Sven

>From c17bb8a334d3fded3f9e88fa37ada55f9cb80efb Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Fri, 7 Sep 2018 09:52:49 +0200
Subject: [PATCH] Correct the Replaces in emacs-{gtk,lucid,nox}

The predecessors of emacs-gtk, emacs-lucid and emacs-nox in
src:emacs25 were called emacs25, emacs25-lucid and emacs25-nox
respectively, so replace those rather than the new variants.

Closes: 907997
---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 6d4a533ea20..1dcd6a2a00a 100644
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,7 @@ Provides: emacs, emacsen, editor, info-browser, mail-reader, news-reader
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-gtk, emacs-nox
 Replaces: emacs-gtk, emacs-nox,
-  emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25)
+  emacs25 (<< 1:25), emacs25-lucid (<< 1:25), emacs25-nox (<< 1:25)
 Description: GNU Emacs editor (with Lucid GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs with support for a graphical user
@@ -74,7 +74,7 @@ Provides: emacs, emacsen, editor, info-browser, mail-reader, news-reader
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-gtk, emacs-lucid
 Replaces: emacs-gtk, emacs-lucid,
-  emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25)
+  emacs25 (<< 1:25), emacs25-lucid (<< 1:25), emacs25-nox (<< 1:25)
 Description: GNU Emacs editor (without GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs compiled without support for X,
@@ -100,7 +100,7 @@ Provides: emacs, emacsen, editor, info-browser, mail-reader, news-reader
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-lucid, emacs-nox
 Replaces: emacs-lucid, emacs-nox,
-  emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25)
+  emacs25 (<< 1:25), emacs25-lucid (<< 1:25), emacs25-nox (<< 1:25)
 Description: GNU Emacs editor (with GTK+ GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs with a graphical user interface
-- 
2.19.0.rc2



Bug#906504: pulseaudio: FTBFS in buster/sid (failing tests) => patch available

2018-09-07 Thread Sven Joachim
Control: found -1 12.2-1

On 2018-09-05 21:20 -0700, Joseph Herlant wrote:

> Control: forwarded -1
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4
> Control: tags -1 + patch
> Control: tags -1 + upstream
>
> Hi,
>
> The issue is due to a optiomizations impacting precision with GCC8.
> There is an existing bug report on this issue upstream:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/559
> and an existing merge request there too:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4
>
> I've created the MR on salsa to add the upstream patch with quilt in
> the current version:
> https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/1

Unfortunately pulseaudio 12.2-1 did still FTBFS on various
architectures, e.g. on arm64[1]:

,
| max deviation: 1 n=307
| 0%: Checks: 1, Failures: 1, Errors: 0
| tests/volume-test.c:148:F:volume:volume_test:0: Assertion 'mdn <= 300' failed
`

Similar on armhf, i386, s390x and sparc64.

Cheers,
   Sven

1. 
https://buildd.debian.org/status/fetch.php?pkg=pulseaudio=arm64=12.2-1=1536269336=0



Bug#907538: audit: FTBFS: /usr/bin/ld: lookup_test.o: file not recognized: file truncated

2018-08-29 Thread Sven Joachim
Source: audit
Version: 1:2.8.4-1
Severity: serious

The latest upload of audit FTBFS on various architectures.  It looks like
a test program is built twice in parallel and make stumbles upon that[1]:

,
| make[5]: Entering directory '/<>/debian/build/auparse/test'
| gcc -DHAVE_CONFIG_H -I. -I../../../../auparse/test -I../..  
-I../../../../auparse -I../../../../lib -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o auparse_test.o 
../../../../auparse/test/auparse_test.c
| ../../../../auparse/test/auparselol_test.c: In function 'main':
| ../../../../auparse/test/auparselol_test.c:219:46: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 4 has type 'unsigned 
int' [-Wformat=]
|  "%s: No memory to allocate %lu bytes\n",
| ~~^
| %u
|  argv[0], sizeof(int));
|   ~~~  
| /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -static -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o 
auparselol_test auparselol_test.o ../../auparse/libauparse.la 
../../lib/libaudit.la 
| libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -Wl,--as-needed -o auparselol_test auparselol_test.o  
../../auparse/.libs/libauparse.a 
/<>/debian/build/lib/.libs/libaudit.a ../../lib/.libs/libaudit.a 
-lcap-ng
| /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -static -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o 
auparse_test auparse_test.o ../../auparse/libauparse.la ../../lib/libaudit.la 
| gcc -DHAVE_CONFIG_H -I. -I../../../../auparse/test -I../..  
-I../../../../auparse -I../../../../lib -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o auparselol_test.o 
../../../../auparse/test/auparselol_test.c
| gcc -DHAVE_CONFIG_H -I. -I../../../../auparse/test -I../..  
-I../../../../auparse -I../../../../lib -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o lookup_test.o 
../../../../auparse/test/lookup_test.c
| make[5]: Nothing to be done for '../../../../auparse/test/auparse_test.py'.
| ../../../../auparse/test/auparselol_test.c: In function 'main':
| ../../../../auparse/test/auparselol_test.c:219:46: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 4 has type 'unsigned 
int' [-Wformat=]
|  "%s: No memory to allocate %lu bytes\n",
| ~~^
| %u
|  argv[0], sizeof(int));
|   ~~~  
| libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -Wl,--as-needed -o auparse_test auparse_test.o  
../../auparse/.libs/libauparse.a 
/<>/debian/build/lib/.libs/libaudit.a ../../lib/.libs/libaudit.a 
-lcap-ng
| /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -static -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o 
auparse_test auparse_test.o ../../auparse/libauparse.la ../../lib/libaudit.la 
| /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -static -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o 
auparselol_test auparselol_test.o ../../auparse/libauparse.la 
../../lib/libaudit.la 
| libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -Wl,--as-needed -o auparselol_test auparselol_test.o  
../../auparse/.libs/libauparse.a 
/<>/debian/build/lib/.libs/libaudit.a ../../lib/.libs/libaudit.a 
-lcap-ng
| libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -Wl,--as-needed -o auparse_test auparse_test.o  
../../auparse/.libs/libauparse.a 
/<>/debian/build/lib/.libs/libaudit.a ../../lib/.libs/libaudit.a 
-lcap-ng
| /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o lookup_test 
lookup_test.o ../../auparse/libauparse.la ../../lib/libaudit.la 
| libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -Wl,--as-needed -o 

Bug#907306: librsvg: FTBFS in buster/sid (configure fails)

2018-08-26 Thread Sven Joachim
On 2018-08-26 09:07 +, Santiago Vila wrote:

> Package: src:librsvg
> Version: 2.40.20-2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster but it failed:
> [...]
> Most probably, it also fails here in reproducible builds:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/librsvg.html
>
> where you can get a full build log if you need it.

The relevant lines from that build log are these:

,
| checking for gdk-pixbuf-query-loaders... no
| checking for gdk-pixbuf-query-loaders-64... no
| checking for gdk-pixbuf-query-loaders-32... no
| configure: error: gdk-pixbuf-query-loaders not found in path
`

This is due to the following change in gdk-pixbuf:

,
| gdk-pixbuf (2.36.12-2) unstable; urgency=medium
| 
|   [ Simon McVittie ]
|   * Update versioned Breaks/Replaces
|   * Remove /usr/bin/gdk-pixbuf-query-loaders symlink from -dev package.
| It has architecture-dependent output and breaks Multi-Arch: same
| co-installability. Debian packages do not seem to rely on this tool
| being in PATH.
| 
|  -- Simon McVittie   Tue, 21 Aug 2018 15:15:42 +0100
`

Apparently the statement "Debian packages do not seem to rely on this tool
being in PATH" was a bit too optimistic.

Cheers,
   Sven



Bug#906644: conkeror: not compatible with firefox >= 57

2018-08-19 Thread Sven Joachim
Package: conkeror
Version: 1.0.4-1
Severity: serious

With the event of firefox-esr 60 in unstable, it seems that conkeror's
days are numbered.  At the moment conkeror is still installable because
iceweasel 52.9.0esr-1 has not been decrufted, but I guess it would stop
working if I were to upgrade firefox-esr now.

,
| $ LANG=C aptitude -s install firefox-esr
| The following packages will be upgraded: 
|   firefox-esr 
| 1 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
| Need to get 41.5 MB of archives. After unpacking 56.3 MB will be used.
| The following packages have unmet dependencies:
|  conkeror : Depends: firefox (< 57~) but it is not going to be installed or
|  firefox-esr (< 57~) but 60.1.0esr-3 is to be installed or
|  iceweasel (< 57~) but it is not going to be installed
|  firefox-esr-l10n-de : Depends: firefox-esr (< 52.9.0esr-1.1~) but 
60.1.0esr-3 is to be installed
| The following actions will resolve these dependencies:
| 
|  Install the following packages:  

| 1) iceweasel [52.9.0esr-1 (unstable)] 

| 
|  Upgrade the following packages:  

| 2) firefox-esr-l10n-de [52.9.0esr-1 (now, unstable) -> 60.1.0esr-3 
(unstable)]
| 
| 
| 
| Accept this solution? [Y/n/q/?] 
| The following NEW packages will be installed:
|   iceweasel{a} 
| The following packages will be upgraded:
|   firefox-esr firefox-esr-l10n-de 
| 2 packages upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
| Need to get 42.2 MB of archives. After unpacking 56.5 MB will be used.
| 
| Note: Using 'Simulate' mode.
| Do you want to continue? [Y/n/?] 
| Would download/install/remove packages.
`


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.3-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages conkeror depends on:
ii  firefox-esr  52.9.0esr-1

Versions of packages conkeror recommends:
ii  conkeror-spawn-process-helper  1.0.4-1
ii  xdg-utils  1.1.3-1

Versions of packages conkeror suggests:
ii  emacs 47.0
ii  emacs-snapshot [emacsen]  1:20180810-1
ii  emacs25 [emacsen] 25.2+1-6+b3

-- no debconf information



Bug#906534: emacs-nox won't be upgraded to execute apt-get upgrade

2018-08-18 Thread Sven Joachim
Control: reassign -1 emacs25-nox 1:25.2+1-10
Control: retitle -1 emacs25-nox: too lax dependency on emacs-nox
Control: severity -1 serious

On 2018-08-18 04:46 +, Shin Yoshida wrote:

> Package: emacs-nox
> Version: 47.0
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
>
> Dear Maintainer,
>
> I installed emacs-nox package in 2018-07-16. Then packages emacs, emacs25-nox,
> emacs-nox were installed.
>
> I execute 'apt-get update && apt-get upgrade' in 2018-08-16. Then
> package emacs and emacs25-nox were upgraded, but emacs-nox had been kept
> back.
>
> At the time, emacs binary disappeared and I could not use emacs.

To elaborate on that, emacs-nox 47.0 depends on emacs25-nox
(unversioned), and emacs25-nox 1:25.2+1-10 depends on emacs-nox, also
unversioned.  The result is that you were left with two useless
metapackages.

> I executed 'apt-get install emacs-nox' to upgrade emacs-nox manually and
> /usr/bin/emacs-nox is installed. (So I can use emacs now.)

The fix is to version the dependency of the new emacs25-nox metapackage
to emacs-nox (>= 1:25) or something like that, and similar for the
other flavors.  Probably emacs' dependencies should be versioned as
well.

Cheers,
   Sven



Bug#905555: emacs-nox: fails to upgrade from 47.0

2018-08-06 Thread Sven Joachim
On 2018-08-06 08:34 +0200, Sven Joachim wrote:

> Package: emacs-nox
> Version: 1:25.2+1-9
> Severity: serious
>
> Upgrading emacs-nox from 47.0 failed in a chroot for me:
>
> ,
> | # apt-get dist-upgrade
> | Reading package lists... Done
> | Building dependency tree   
> | Reading state information... Done
> | Calculating upgrade... Done
> | The following package was automatically installed and is no longer required:
> |   emacs25-nox
> | Use 'sudo apt autoremove' to remove it.
> | The following packages will be REMOVED:
> |   emacs25-bin-common emacs25-common
> | The following NEW packages will be installed:
> |   emacs-bin-common emacs-common
> | The following packages will be upgraded:
> |   emacs-nox emacs25-nox emacsen-common
> | 3 upgraded, 2 newly installed, 2 to remove and 0 not upgraded.
> | Need to get 0 B/16.3 MB of archives.
> | After this operation, 78.8 kB disk space will be freed.
> | Do you want to continue? [Y/n] 
> | debconf: delaying package configuration, since apt-utils is not installed
> | (Reading database ... 15154 files and directories currently installed.)
> | Preparing to unpack .../emacs25-nox_1%3a25.2+1-9_all.deb ...
> | Remove emacsen-common for emacs25
> | emacsen-common: Handling removal of emacsen flavor emacs25
> | Unpacking emacs25-nox (1:25.2+1-9) over (25.2+1-6+b3) ...
> | (Reading database ... 15146 files and directories currently installed.)
> | Removing emacs25-bin-common (25.2+1-6+b3) ...
> | Removing emacs25-common (25.2+1-6) ...
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/scalable/mimetypes' not empty so not removed
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/scalable/apps' not empty so not removed
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/48x48/apps' not empty so not removed
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/32x32/apps' not empty so not removed
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/24x24/apps' not empty so not removed
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/16x16/apps' not empty so not removed
> | dpkg: warning: while removing emacs25-common, directory 
> '/usr/share/icons/hicolor/128x128/apps' not empty so not removed
> | (Reading database ... 12537 files and directories currently installed.)
> | Preparing to unpack .../emacsen-common_3.0.2_all.deb ...
> | Unpacking emacsen-common (3.0.2) over (2.0.8) ...
> | dpkg: warning: unable to delete old directory '/etc/emacs/site-start.d': 
> Directory not empty
> | dpkg: warning: unable to delete old directory '/etc/emacs': Directory not 
> empty
> | Selecting previously unselected package emacs-common.
> | Preparing to unpack .../emacs-common_1%3a25.2+1-9_all.deb ...
> | Unpacking emacs-common (1:25.2+1-9) ...
> | Selecting previously unselected package emacs-bin-common.
> | Preparing to unpack .../emacs-bin-common_1%3a25.2+1-9_i386.deb ...
> | Unpacking emacs-bin-common (1:25.2+1-9) ...
> | Preparing to unpack .../emacs-nox_1%3a25.2+1-9_i386.deb ...
> | dpkg-query: no packages found matching emacs-nox:i386
> | dpkg-query: package 'emacs-nox' is not installed
> | Use dpkg --info (= dpkg-deb --info) to examine archive files,
> | and dpkg --contents (= dpkg-deb --contents) to list their contents.
> | dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox' not owned 
> by package 'emacs-nox:i386'
> | dpkg-query: package 'emacs-nox' is not installed
> | Use dpkg --info (= dpkg-deb --info) to examine archive files,
> | and dpkg --contents (= dpkg-deb --contents) to list their contents.
> | dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox/copyright' 
> not owned by package 'emacs-nox:i386'
> | dpkg-query: package 'emacs-nox' is not installed
> | Use dpkg --info (= dpkg-deb --info) to examine archive files,
> | and dpkg --contents (= dpkg-deb --contents) to list their contents.
> | dpkg-maintscript-helper: error: file 
> '/usr/share/doc/emacs-nox/changelog.gz' not owned by package 'emacs-nox:i386'
> | dpkg-maintscript-helper: error: directory '/usr/share/doc/emacs-nox' 
> contains files not owned by package emacs-nox:i386, cannot switch to symlink
> | dpkg: error processing archive 
> /var/cache/apt/archives/emacs-nox_1%3a25.2+1-9_i386.deb (--unpack):
> |  new emacs-nox package pre-installation script subprocess returned error 
> exit status 1
> | Errors were encountered while processing:
> |  /var/cache/apt/archives/emacs-nox_1%3a25.2+1-9_i386.deb
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> `
>
> The "dpkg-query

Bug#905555: emacs-nox: fails to upgrade from 47.0

2018-08-06 Thread Sven Joachim
Package: emacs-nox
Version: 1:25.2+1-9
Severity: serious

Upgrading emacs-nox from 47.0 failed in a chroot for me:

,
| # apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Calculating upgrade... Done
| The following package was automatically installed and is no longer required:
|   emacs25-nox
| Use 'sudo apt autoremove' to remove it.
| The following packages will be REMOVED:
|   emacs25-bin-common emacs25-common
| The following NEW packages will be installed:
|   emacs-bin-common emacs-common
| The following packages will be upgraded:
|   emacs-nox emacs25-nox emacsen-common
| 3 upgraded, 2 newly installed, 2 to remove and 0 not upgraded.
| Need to get 0 B/16.3 MB of archives.
| After this operation, 78.8 kB disk space will be freed.
| Do you want to continue? [Y/n] 
| debconf: delaying package configuration, since apt-utils is not installed
| (Reading database ... 15154 files and directories currently installed.)
| Preparing to unpack .../emacs25-nox_1%3a25.2+1-9_all.deb ...
| Remove emacsen-common for emacs25
| emacsen-common: Handling removal of emacsen flavor emacs25
| Unpacking emacs25-nox (1:25.2+1-9) over (25.2+1-6+b3) ...
| (Reading database ... 15146 files and directories currently installed.)
| Removing emacs25-bin-common (25.2+1-6+b3) ...
| Removing emacs25-common (25.2+1-6) ...
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/scalable/mimetypes' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/scalable/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/48x48/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/32x32/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/24x24/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/16x16/apps' not empty so not removed
| dpkg: warning: while removing emacs25-common, directory 
'/usr/share/icons/hicolor/128x128/apps' not empty so not removed
| (Reading database ... 12537 files and directories currently installed.)
| Preparing to unpack .../emacsen-common_3.0.2_all.deb ...
| Unpacking emacsen-common (3.0.2) over (2.0.8) ...
| dpkg: warning: unable to delete old directory '/etc/emacs/site-start.d': 
Directory not empty
| dpkg: warning: unable to delete old directory '/etc/emacs': Directory not 
empty
| Selecting previously unselected package emacs-common.
| Preparing to unpack .../emacs-common_1%3a25.2+1-9_all.deb ...
| Unpacking emacs-common (1:25.2+1-9) ...
| Selecting previously unselected package emacs-bin-common.
| Preparing to unpack .../emacs-bin-common_1%3a25.2+1-9_i386.deb ...
| Unpacking emacs-bin-common (1:25.2+1-9) ...
| Preparing to unpack .../emacs-nox_1%3a25.2+1-9_i386.deb ...
| dpkg-query: no packages found matching emacs-nox:i386
| dpkg-query: package 'emacs-nox' is not installed
| Use dpkg --info (= dpkg-deb --info) to examine archive files,
| and dpkg --contents (= dpkg-deb --contents) to list their contents.
| dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox' not owned by 
package 'emacs-nox:i386'
| dpkg-query: package 'emacs-nox' is not installed
| Use dpkg --info (= dpkg-deb --info) to examine archive files,
| and dpkg --contents (= dpkg-deb --contents) to list their contents.
| dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox/copyright' not 
owned by package 'emacs-nox:i386'
| dpkg-query: package 'emacs-nox' is not installed
| Use dpkg --info (= dpkg-deb --info) to examine archive files,
| and dpkg --contents (= dpkg-deb --contents) to list their contents.
| dpkg-maintscript-helper: error: file '/usr/share/doc/emacs-nox/changelog.gz' 
not owned by package 'emacs-nox:i386'
| dpkg-maintscript-helper: error: directory '/usr/share/doc/emacs-nox' contains 
files not owned by package emacs-nox:i386, cannot switch to symlink
| dpkg: error processing archive 
/var/cache/apt/archives/emacs-nox_1%3a25.2+1-9_i386.deb (--unpack):
|  new emacs-nox package pre-installation script subprocess returned error exit 
status 1
| Errors were encountered while processing:
|  /var/cache/apt/archives/emacs-nox_1%3a25.2+1-9_i386.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
`

The "dpkg-query: no packages found matching emacs-nox:i386" error
message looks suspicious, this really should not happen.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.18.0-rc8-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via 

Bug#904957: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25-lucid 25.2+1-6+b3

2018-08-04 Thread Sven Joachim
On 2018-08-04 11:24 -0500, Rob Browning wrote:

> Axel Beckert  writes:
>
>> upgrading emacs25-lucid on armhf pulls in emacs-lucid, but that fails
>> to install as follows:
>>
>> Preparing to unpack .../emacs-lucid_1%3a25.2+1-8_armhf.deb ...
>> Unpacking emacs-lucid (1:25.2+1-8) ...
>> dpkg: error processing archive 
>> /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-8_armhf.deb (--unpack):
>>  trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in 
>> package emacs25-lucid 25.2+1-6+b3
>> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>> Errors were encountered while processing:
>>  /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-8_armhf.deb
>>
>> The Replaces header only contains emacs-gtk and emacs-nox, but likely
>> also needs emacs25-lucid. And probably also needs a "Breaks:
>> emacs25-lucid".
>
> I suspect I'm just misunderstanding the dependency system, but this
> confuses me because:
>
>   emacs25-lucid 25.2+1-6+b3
> Depends: emacs25-bin-common
>
> and
>
>   emacs25-bin-common
> Depends: emacs25-common
>
> and on the newer side
>
>   emacs-lucid 1:25.2+1-8
> Depends: emacs-common (= 1:25.2+1-8)
>
> and 
>
>   emacs-common 1:25.2+1-8
> Depends: emacsen-common (>= 3.0.0)
>
> and
>
>   emacsen-common (>= 3.0.0)
> Conflicts: emacs25-common

AFAICS this does not prevent emacs-lucid to be unpacked before
emacs-common and the new emacsen-common and emacs25-lucid versions, in
which case you hit the file conflict.

> So I'd expected the indirect dependency of emacs-lucid on the newer
> emacsen-common to have indirectly forced emacs25-lucid out (via the
> emacsen-common conflicts), so that there wouldn't be a file conflict,
> but obviously I'm missing something (and agree that it's a somewhat
> tortuous route).

I think emacs-lucid needs a "Replaces: emacs25-lucid (<< 1:25)" here,
and similarly for the other flavors.

Cheers,
   Sven



Bug#904816: emacs-goodies-el: dpkg-dev-el and debian-el dropped without replacement in unstable

2018-07-28 Thread Sven Joachim
Source: emacs-goodies-el
Version: 39.0
Severity: serious

The dpkg-dev-el and debian-el binary packages have been dropped from
src:emacs-goodies-el, but their elpafied replacements are so far only
available in experimental.

For now the old versions of {dpkg-dev,debian}-el from emacs-goodies-el
36.4 are still in the archive, but I think the 37.x versions need to be
uploaded to unstable before emacs-goodies-el is suitable for testing.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386



Bug#904775: Broken dependencies

2018-07-27 Thread Sven Joachim
On 2018-07-27 21:36 +0200, Alf Gaida wrote:

> Package: login
> Version: 1:4.5-1
> Severity: grave
>
> Dear Maintainer,
> please don't break util-linux that is not even released. At least _one_ valid 
> util-linux
> should be available.

Why was util-linux 2.32-0.2 not uploaded along shadow 1:4.5-1.1 to avoid
this breakage?

> W: See /var/cache/pyfll/fll_lxCa2q/amd64/debootstrap/debootstrap.log
> for details (possibly the package util-linux is at fault)
> 2018-07-27 21:30:20,668 CRITICAL - command failed with return value: 1
> 2018-07-27 21:30:20,669 INFO  - cleaning up...

To elaborate on that, debootstrapping a fresh sid chroot results in
util-linux being unpacked but not configured.  And this completely
breaks apt which is unwilling to perform any operations:

,
| # apt-get install hello
| Reading package lists... Done
| Building dependency tree... Done
| You might want to run 'apt --fix-broken install' to correct these.
| The following packages have unmet dependencies:
|  login : Breaks: util-linux (< 2.32-0.2~) but 2.32-0.1 is to be installed
| E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
| root@pavil:/# apt-get -f install
| Reading package lists... Done
| Building dependency tree... Done
| Correcting dependencies... Done
| The following packages will be REMOVED:
|   login
| WARNING: The following essential packages will be removed.
| This should NOT be done unless you know exactly what you are doing!
|   login
| 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
| 3 not fully installed or removed.
| After this operation, 2760 kB disk space will be freed.
| You are about to do something potentially harmful.
| To continue type in the phrase 'Yes, do as I say!'
|  ?] 
| Abort.
`

Cheers,
   Sven



Bug#903818: screen: should not try to link with -lelf

2018-07-15 Thread Sven Joachim
On 2018-07-15 14:04 +0200, Axel Beckert wrote:

> Control: tag -1 + confirmed pending
>
> Hi Sven,
>
> I just noticed the following:
>
> Sven Joachim wrote:
>> ,
>> | $ dpkg-deb -f screen-udeb_4.6.2-2_i386.udeb Depends 
>> | libc6-udeb (>= 2.27), libelf1 (>= 0.132), libtinfo6-udeb (>= 6.1)
>> `
>
> So this seems to stem from being build in a not so clean chroot,
> because my pbuilder-built upload on amd64 doesn't show that
> dependency.

Surely, it only happens if libelf-dev is present on the build system
which is usually not the case for official builds.  That's why I
reported it at normal severity and KiBi has not yelled at you yet. ;-)

> But I was able to reproduce the issue by rebuilding 4.6.2-2 locally
> after installing libelf-dev. And hence I can confirm that applying
> that commit against configure.ac fixes the issue.
>
> Will upload 4.6.2-3 with the fix soon.

Thanks.

Cheers,
   Sven



Bug#903708: xfce4: xfce fails to start with all methods

2018-07-14 Thread Sven Joachim
Control: reassign -1 xserver-xorg-core
Control: forcemerge 900550 -1

On 2018-07-13 10:55 -0400, annadane wrote:

> Package: xfce4
> Version: 4.12.4
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> On a fresh install of Sid (as in minimal Stable -> dist-upgrade), xfce
> fails to start with any of sddm, lightdm, or startx. Here's my xorg
> log; I'm really not certain how to fix it. (PS if it's wrong to
> include paste.d.n links in here instead of full output please let me
> know or just paste it verbatim) http://paste.debian.net/1033571/

Please include such logs directly in the bug report in the future, that makes
them easier to access.  Here is the relevant output:

,
| [  1275.433] (EE) Backtrace:
| [  1275.433] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x55abecc798dd]
| [  1275.433] (EE) 1: /usr/lib/xorg/Xorg (0x55abecac6000+0x1b7599) 
[0x55abecc7d599]
| [  1275.433] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f0b655d+0x128e0) [0x7f0b655e28e0]
| [  1275.433] (EE) 3: /usr/lib/xorg/Xorg (miRenderColorToPixel+0xe) 
[0x55abecbedbde]
| [  1275.433] (EE) 4: /usr/lib/xorg/modules/libexa.so (0x7f0b629f6000+0xf13b) 
[0x7f0b62a0513b]
| [  1275.433] (EE) 5: /usr/lib/xorg/Xorg (0x55abecac6000+0x13a8b6) 
[0x55abecc008b6]
| [  1275.433] (EE) 6: /usr/lib/xorg/Xorg (0x55abecac6000+0x12ec1c) 
[0x55abecbf4c1c]
| [  1275.433] (EE) 7: /usr/lib/xorg/Xorg (0x55abecac6000+0x5b008) 
[0x55abecb21008]
| [  1275.433] (EE) 8: /usr/lib/xorg/Xorg (0x55abecac6000+0x5f008) 
[0x55abecb25008]
| [  1275.433] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) 
[0x7f0b65435b17]
| [  1275.433] (EE) 10: /usr/lib/xorg/Xorg (_start+0x2a) [0x55abecb0ed0a]
| [  1275.433] (EE) 
| [  1275.433] (EE) Segmentation fault at address 0x8
| [  1275.433] (EE) 
| Fatal server error:
| [  1275.433] (EE) Caught signal 11 (Segmentation fault). Server aborting
`

This is bug #900550 in xserver-xorg-core, I have just cherry-picked the
upstream fix[1].

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/aa7aaeb5223830a3670dc658152e28f125c17de8



Bug#903224: udev: Fails to upgrade

2018-07-08 Thread Sven Joachim
On 2018-07-08 03:05 +0200, Michael Biebl wrote:

> Control: tags -1 moreinfo unreproducible
>
> Am 08.07.2018 um 00:26 schrieb Kurt Roeckx:
>> Package: udev
>> Version: 239-5
>> Severity: serious
>> 
>> Hi,
>> 
>> When upgrading udev, it failed to upgrade, because udev didn't
>> want to start. I think there might be some ordering problem.

In the logs it can be seen that udev is configured before systemd, and
that apparently hits the same problem as #902185.

> Unfortunately I can't reproduce your problem. I've just test-upgraded a
> buster VM from 238-5 to 239-5 without a problem.
> Can you provide instructions how to reproduce the problem?

The following steps might reproduce it:

- Downgrade the *systemd* and *udev* packages to 238-5.

- Unpack the 239-5 packages with dpkg --unpack.

- Run "dpkg --configure libudev1 udev".

Cheers,
   Sven



Bug#902998: libpam-systemd: breaks installing build depends e.g. gnupg2

2018-07-04 Thread Sven Joachim
On 2018-07-04 23:33 +0200, Michael Biebl wrote:

> Control: tags -1 moreinfo
>
>
> This is what I get when I build a package using pbuilder, which
> build-depends on policykit-1 (which in turn pulls in libpam-systemd):
>
> The following packages have unmet dependencies:
>  systemd : Breaks: systemd-shim (< 10-4~) but 10-3 is to be installed
> The following actions will resolve these dependencies:
>
>  Install the following packages:
> 1) systemd-sysv [239-4 (unstable)]
>
>  Keep the following packages at their current version:
> 2) systemd-shim [Not Installed]
>
> And the build succeeds.
>
> Or running apt install libpam-systemd inside a chroot:
>
> # apt install libpam-systemd
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following additional packages will be installed:
>   dbus dmsetup libapparmor1 libargon2-0 libargon2-1 libcap2
> libcryptsetup12 libdbus-1-3 libdevmapper1.02.1 libexpat1
>   libidn11 libip4tc0 libjson-c3 libkmod2 libprocps7 lsb-base procps
> systemd systemd-sysv
> Suggested packages:
>   default-dbus-session-bus | dbus-session-bus systemd-container policykit-1
> Recommended packages:
>   psmisc libnss-systemd
> The following NEW packages will be installed:
>   dbus dmsetup libapparmor1 libargon2-0 libargon2-1 libcap2
> libcryptsetup12 libdbus-1-3 libdevmapper1.02.1 libexpat1
>   libidn11 libip4tc0 libjson-c3 libkmod2 libpam-systemd libprocps7
> lsb-base procps systemd systemd-sysv
> 0 upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/5069 kB of archives.
> After this operation, 17.4 MB of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort.

This works, but "apt install libgtk-3-0" does not, for instance:

,
| # apt install libgtk-3-0
| 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-0 : Depends: libgtk-3-common (>= 3.22.30-2) but it is not going to 
be installed
|   Depends: librest-0.7-0 (>= 0.7) but it is not going to be 
installed
|   Depends: libsoup2.4-1 (>= 2.4.0) but it is not going to be 
installed
| E: Unable to correct problems, you have held broken packages.
`

Cheers,
   Sven



Bug#902448: timidity: Breaks: timidity-daemon (>= 2.14.0-1~) but 2.14.0-5 is to be installed

2018-06-26 Thread Sven Joachim
Package: timidity
Version: 2.14.0-5
Severity: serious

In this version, timidity-daemon has become uninstallable:

,
| $ LANG=C aptitude -s install timidity-daemon
| The following packages will be upgraded: 
|   timidity{b} timidity-daemon 
| The following packages are RECOMMENDED but will NOT be installed:
|   fluid-soundfont-gm 
| 2 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
| Need to get 676 kB of archives. After unpacking 49.2 kB will be used.
| The following packages have unmet dependencies:
|  timidity : Breaks: timidity-daemon (>= 2.14.0-1~) but 2.14.0-5 is to be 
installed
| The following actions will resolve these dependencies:
| 
|  Keep the following packages at their current version:
| 1) timidity [2.14.0-4 (now)]  
| 2) timidity-daemon [2.14.0-4 (now)]   
| 
| 
| 
| Accept this solution? [Y/n/q/?] q
| Abandoning all efforts to resolve these dependencies.
| Abort.
`

Most likely you meant to break timidity-daemon (<= 2.14.0-1~) rather
than (>= 2.14.0-1~).


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.17.3-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#902268: debhelper: skips multilib packages when building ncurses

2018-06-24 Thread Sven Joachim
On 2018-06-24 08:22 +, Niels Thykier wrote:

> Niels Thykier:
>> Sven Joachim:
>>> Package: debhelper
>>> Version: 11.3.3
>>> Severity: serious
>>>
>> 
>> Hi Sven,
>> 
>> Are you certain it is introduced in 11.3.3?  The messages / control
>> check you highlight is much older than 11.3.3.
>> 
>>>[...]
>
> Nvm, I reproduced it and I believe the attached patch fixes it.

Yes, that works. :-)

Cheers,
   Sven



Bug#902268: debhelper: skips multilib packages when building ncurses

2018-06-24 Thread Sven Joachim
Package: debhelper
Version: 11.3.3
Severity: serious

Doing a test build of ncurses, I noticed that the dh_* tools skipped the
multilib packages, resulting in an incomplete build.  This is
reproducible on both i386 and amd64.

,
| $ grep -B1 "All requested packages have been excluded" 
ncurses_6.1+20180210-4_amd64.build
| dh_installdocs -plib32tinfo6
| dh_installdocs: All requested packages have been excluded (e.g. via a 
Build-Profile or due to architecture restrictions).
| --
|--link-doc=lib32tinfo6
| dh_installdocs: All requested packages have been excluded (e.g. via a 
Build-Profile or due to architecture restrictions).
| --
| dh_makeshlibs -plib32tinfo6 -V "lib32tinfo6 (>= 6.1)" -- -c4
| dh_makeshlibs: All requested packages have been excluded (e.g. via a 
Build-Profile or due to architecture restrictions).
| dh_makeshlibs -plib32ncurses6 -V "lib32ncurses6 (>= 6.1)" -- -c4
| dh_makeshlibs: All requested packages have been excluded (e.g. via a 
Build-Profile or due to architecture restrictions).
| dh_makeshlibs -plib32ncursesw6 -V "lib32ncursesw6 (>= 6.1)" -- -c4
| dh_makeshlibs: All requested packages have been excluded (e.g. via a 
Build-Profile or due to architecture restrictions).
`

,
| $ grep "in control file but not in files list" 
ncurses_6.1+20180210-4_amd64.build
| dpkg-genchanges: warning: package lib32tinfo6 in control file but not in 
files list
| dpkg-genchanges: warning: package lib32ncurses6 in control file but not in 
files list
| dpkg-genchanges: warning: package lib32ncursesw6 in control file but not in 
files list
| dpkg-genchanges: warning: package lib32ncurses-dev in control file but not in 
files list
`


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.17.2-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  0.042-1
ii  dpkg 1.19.1
ii  dpkg-dev 1.19.1
ii  dwz  0.12-2
ii  file 1:5.33-3
ii  libdpkg-perl 1.19.1
ii  man-db   2.8.3-2
ii  perl 5.26.2-6
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201801

-- no debconf information



  1   2   3   4   5   6   7   8   9   >