Bug#948316: MIA?

[Russ Allbery]

Angel Abad  writes:
> On Tue, Jan 28, 2020 at 09:35:15PM +0800, Yao-Po Wang wrote:

>> Sorry for the late reply and I did not use the package a long time. How
>> can I transfer the owner to you?

> Hi, Russ, you have a functional package, do you want to maintain yadm on
> Debian?

> If dont I can take care of yadm.

I can maintain it and have a functional package, although I'd love some
help.  Happy to have someone else update it when I'm busy!

I've pushed my branch to debian/master in the Salsa repository.  It's
based on the current master branch, although I usually use the DEP-14
branch naming, so normally I'd delete the master branch if that also works
for you.

I think the one thing that needs to be done before uploading to Debian
unstable is to write a NEWS.Debian file telling people they need to run
yadm upgrade (and upgrade Maintainer and Uploaders).  I will be able to
get to that in the next couple of days, or happy for someone else to do
it.

-- 
Russ Allbery (r...@debian.org)  

Bug#948316: MIA?

[Angel Abad]

On Mon, Feb 03, 2020 at 11:48:45PM -0800, Russ Allbery wrote:
> Angel Abad  writes:
> > On Tue, Jan 28, 2020 at 09:35:15PM +0800, Yao-Po Wang wrote:
> 
> >> Sorry for the late reply and I did not use the package a long time. How
> >> can I transfer the owner to you?
> 
> > Hi, Russ, you have a functional package, do you want to maintain yadm on
> > Debian?
> 
> > If dont I can take care of yadm.
> 
> I can maintain it and have a functional package, although I'd love some
> help.  Happy to have someone else update it when I'm busy!
> 
> I've pushed my branch to debian/master in the Salsa repository.  It's
> based on the current master branch, although I usually use the DEP-14
> branch naming, so normally I'd delete the master branch if that also works
> for you.
> 
> I think the one thing that needs to be done before uploading to Debian
> unstable is to write a NEWS.Debian file telling people they need to run
> yadm upgrade (and upgrade Maintainer and Uploaders).  I will be able to
> get to that in the next couple of days, or happy for someone else to do
> it.

Cool, we can co-maintain the package. I will try to write a NEWS.Debian file
this week.

Cheers!

> -- 
> Russ Allbery (r...@debian.org)  


signature.asc
Description: PGP signature

Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot

[Felix Zielcke]

Am Montag, den 03.02.2020, 18:59 +0100 schrieb Matthias Klose:

> $ dpkg -S libgcc_s.so.1
> libgcc-s1:amd64: /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> libgcc1: /lib/libgcc_s.so.1
> 
> if you need the library in /lib, make sure that you depend on
> libgcc1, else it's
> found in /usr/lib/.
> 
> I'm fine to add some breaks if required.

This gets now fixed directly in initramfs-tools:

https://salsa.debian.org/kernel-team/initramfs-tools/commit/f2ac13e8881f975b062a56050ceda85ef9ccc015

See also #950254

So I guess as soon as that is uploaded, libgcc1 should then Breaks: the
older versions.

Bug#950516: file: please backport 5.38 to stable for removal of python2

[Christoph Biedl]

Felix Lechner wrote...

> On Sun, Feb 2, 2020 at 11:14 PM Christoph Biedl

>> Actually, I don't (yet) follow why this is a problem "even on stable".
>
> The service lintian.d.o runs on stable (buster). Without a backport, I
> don't think Debian's infrastructure can detect the tag
> 'source-contains-prebuilt-python-object' for any package in Debian
> (for python3 byte compiled binaries).

Understood, that bit of information was missing.

>> (1) The buster version of file should be available in stretch-backports.
>
> I am hoping to see the version from bullseye (testing) in buster
> (stable). Isn't stretch the previous stable release (old-stable)?

Yeah, off-by-one.

So, rephrasing, what are you asking for?

(1) The Debian 11 ("bullseye") version of file should be available in
the backports for Debian 10 ("buster").

(2) The Debian 11 ("bullseye") version of file should be available in
the main archive of Debian 10 ("buster), i.e. the rather seldom
case of bringing a completely new version to stable.

This is what I had in mind, and so the consequences are as written:

>> About (1), I am be happy to provide and extensively test such a
>> backport, but will not upload for non-technical reasons. If somebody is
>> willing to do this, and on a regular base, please drop me a line and
>> we'll arrange things.
>
> Does this complexity still exist in view of my comment above?

Yes.

>> About (2): This is a big change. Breakage is not likely but *if* it
>> happens the impact will be huge, so the anger created. Let me propose an
>> alternative approach, almost risk-free: Cherry-pick the applicable
>> commits from upstream and upload to stable-proposed-updates. With
>> backing from the lintian team, the release team will certainly not
>> object.
>
> Also, is this recommendation still applicable in view of my comment above?

Yes.

So which option have you been reqesting. If really (2), what about my
suggestion?

Christoph

PS: Please leave it to me when I consider the "moreinfo" requirement
fulfilled. Since so far it ist not, and I don't think ping-pong is a
nice game.


signature.asc
Description: PGP signature

Bug#948316: MIA?

[Angel Abad]

On Tue, Jan 28, 2020 at 09:35:15PM +0800, Yao-Po Wang wrote:
> Hi Angel,
> 
> Sorry for the late reply and I did not use the package a long time. How can
> I transfer the owner to you?

Hi, Russ, you have a functional package, do you want to maintain yadm on Debian?

If dont I can take care of yadm.

Cheers!

> br,
> yp
> 
> On Tue, Jan 28, 2020, 01:00 Angel Abad  wrote:
> 
> > It seems that Yao-Po Wang is mia, so, could we adopt this package?
> >
> > Thanks!
> >


signature.asc
Description: PGP signature

Bug#793340: Возвратные УПД за этот месяц

[Яна Зимина]

По состоянию на 04.02 вами немного не возвращены УПД. Список в письме ниже.

Просьба до следующей недели отправить на мою почту, полностью все док-ты.
Признательна за понимание.


Dogovor za etot mesyac.001
Description: Binary data

Bug#950603: yodl-doc: Embeds timestamp in yodl.ps and yodl.dvi

[tony mancill]

On Mon, Feb 03, 2020 at 06:51:44PM -0800, Vagrant Cascadian wrote:
> Package: yodl-doc
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> The timestamp is embedded in /usr/share/doc/yodl-doc/yodl.ps.gz and
> yodl.dvi.gz, which causes unreproducible builds.
> 
> The fix is to export FORCE_SOURCE_DATE=1 in debian/rules to get texlive
> to respect the SOURCE_DATE_EPOCH variable.

Thank you Vagrant.  I will address this is yodl and related packages
real soon now!

Cheers,
tony

Bug#950420: efl FTCBFS: src/bin/eolian/meson.build:25:2: ERROR: Program(s) ['eolian_gen'] not found or not executable

[Ross Vandegrift]

Hi Helmut,

On Sat, Feb 01, 2020 at 01:10:25PM +0100, Helmut Grohne wrote:
> I'm proposing a libefl-all-dev-bin package. We simply move eolian_gen to
> that new package and have libefl-all-dev depend on it. For consumers,
> nothing changes. Two things do change:
>  * libefl-all-dev-bin is being marked Multi-Arch: foreign, so eolian_gen
>becomes usable for cross compilation.
>  * efl can build depend on libefl-all-dev-bin  to make the tool
>available.
> 
> Please consider applying the attached patch. Yes, that means going
> through NEW.

Sounds fine to me, I pushed a tweaked version of your patch to salsa.  There
are two small changes.

- I modified it to create libeolian-bin.  The other /usr/bin/ binaries in
  libefl-all-dev are debug tools not used during build (so no real need for a
  general package).  And libeolian-bin is more in line with how the other EFL
  packages are divided up.

- The Build-Depends for eolian_gen is versioned like this: 
libeolian-bin (= ${source:Upstream-Version}) 
  eolian is not officially stable upstream, which means they are still open to
  breaking changes.  Thus building EFL 1.X with eolian_gen 1.Y could be
  problematic.  Will this be burdensome for cross builds?


Thanks for the good explanation and patch,
Ross

Bug#950457: linux-image-5.4.0-0.bpo.2-amd64: Regression: mount option not correctly handled

[Phillip Lougher]

On Sun, Feb 2, 2020 at 2:55 PM Ben Hutchings  wrote:
>
> Control: tag -1 upstream
>
> On Sun, 2020-02-02 at 00:22 +0100, Vincent Danjean wrote:
> > Package: src:linux
> > Version: 5.4.8-1~bpo10+1
> > Severity: important
> >
> >   Hi,
> >
> >   I'm using singularity on kvm Debian machines. After the last upgrade
> > that installed the linux-image-5.4.0-0.bpo.2-amd64 kernel, I cannot
> > start any singularity image. The error is:
> > $ singularity -v -v shell /srv/scratch/atac-20180906-012322.simg
> > [...]
> > VERBOSE: Mounting squashfs image: /dev/loop0 -> 
> > /var/lib/singularity/mnt/container
> > ERROR  : Failed to mount squashfs image in (read only): Invalid argument
> > ABORT  : Retval = 255
> >
> >   Using strace, I investiguate the problem, and find this:
> > # mount -o ro,loop,offset=31,errors=remount-ro -t squashfs 
> > /srv/scratch/atac-20180906-012322.simg  /mnt/
> > mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, 
> > missing codepage or helper program, or other error.
> > # mount -o ro,loop,offset=31 -t squashfs 
> > /srv/scratch/atac-20180906-012322.simg  /mnt/
>
> It seems that squashfs used to ignore unknown mount options, but
> rejects them since:
>
> commit 5a2be1288b514d74acdb3f0131d4d8fa3d689f06
> Author: David Howells 
> Date:   Mon Mar 25 16:38:32 2019 +
>
> vfs: Convert squashfs to use the new mount API
>
> Although ignoring mount options was a bug, this change is a user-space
> regression and at least this option should still be ignored.
>
> Ben.
>

This cropped up in Fedora last year
https://bugzilla.redhat.com/show_bug.cgi?id=1781863

Laura Abbott submitted a patch which got up to a V2

https://lore.kernel.org/linux-fsdevel/20191212224139.15970-1-labb...@redhat.com/

CC'ing Laura Abbott

Phillip


> > # ls /mnt
> > [ all file of my singularity image ]
> >
> >   With the previous installed kernel (5.3.0-0.bpo.2-amd64), the first mount
> > (with the "errors=remount-ro" option) succeed. And, of course, strace told
> > me that singularity is using the "errors=remount-ro" option...
> >
> >   For now, I'm downgrading my kernel and using 5.3.0-0.bpo.2-amd64 as
> > a workaround.
> >
> >   Regards,
> > Vincent
> >
> > PS: see https://github.com/sylabs/singularity/issues/4801 for
> > the issue in singularity where it will be fixed (errors=remount-ro
> > removed). But as I'm still using singularity from strech-backports,
> > (singularity-container is not in buster and, in any case, I need
> > to stick to 2.X version for singularity due to the use of datacenters
> > where 3.X images are not yet supported)
> [...]
>
> --
> Ben Hutchings
> I haven't lost my mind; it's backed up on tape somewhere.
>
>

Bug#950606: gdb-source: generated tarball includes system metadata

[Vagrant Cascadian]

Package: gdb-source
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps umask username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The tarball produced in gdb-source binary package includes metadata from
the filesystem, including umask, timestamps, and potentially username,
group, and sort order of the files in the tarball.

The attached patch passes arguments to tar to ensure reproducible builds
of this package.

There are several outstanding reproducibility issues with the other
packages produced by gdb, but please consider applying this to improve
the signal to noise ratio.


Thanks for maintaining gdb!


live well,
  vagrant
From cb9a4e0584e3f3dca2efa25078b81b5821ef747a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 4 Feb 2020 03:16:30 +
Subject: [PATCH] debian/rules: Use tar arguments to ensure consistant
 tarballs, setting file mode, uid/gid, timestamps and sort order.

---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index a6ad6ac71..d05d28ad7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -287,6 +287,11 @@ binary-post-install/gdb-source ::
 	cd $(BUILDDIRSOURCE) && debian/rules clean
 	cd $(dir $(BUILDDIRSOURCE)) \
 	  && tar -cjf $(shell pwd)/debian/gdb-source/usr/src/gdb.tar.bz2 \
+	 --format=gnu \
+	 --mode=755 \
+	 --mtime="@$${SOURCE_DATE_EPOCH}" --clamp-mtime \
+	 --numeric-owner --owner=0 --group=0 \
+	 --sort=name \
 	 $(notdir $(BUILDDIRSOURCE))
 
 debian/control:: debian/control.in $(CROSS_FORCE)
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#950420: efl FTCBFS: src/bin/eolian/meson.build:25:2: ERROR: Program(s) ['eolian_gen'] not found or not executable

[Helmut Grohne]

Hi Ross,

On Mon, Feb 03, 2020 at 10:14:24PM -0800, Ross Vandegrift wrote:
> Sounds fine to me, I pushed a tweaked version of your patch to salsa.  There
> are two small changes.
> 
> - I modified it to create libeolian-bin.  The other /usr/bin/ binaries in
>   libefl-all-dev are debug tools not used during build (so no real need for a
>   general package).  And libeolian-bin is more in line with how the other EFL
>   packages are divided up.

Thank you for improving upon my patch.

> - The Build-Depends for eolian_gen is versioned like this: 
> libeolian-bin (= ${source:Upstream-Version}) 
>   eolian is not officially stable upstream, which means they are still open to
>   breaking changes.  Thus building EFL 1.X with eolian_gen 1.Y could be
>   problematic.  Will this be burdensome for cross builds?

Yes and no. For cross builds, we generally do not support different
source vs build architecture versions. So the restriction is not a
limitation.

However, dpkg does not support substitution variables in Build-Depends,
so this dependency won't be satisfiable due to not being substituted.
We've had this for qtbase-opensource-src recently and agreed to turn it
into a build-time check (i.e. have debian/rules reject a different
version). Does that work for you?

Helmut

Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot

[Vincent Bernat]

Package: libgcc1
Version: 1:10-20200202-1
Followup-For: Bug #950551

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

On both my systems running unstable, libgcc-s1 is installed, but I
don't have /usr/lib/x86_64-linux-gnu/libgcc_s.so.1. So, it seems
something removes it. I have no clue on why. Reinstalling libgcc-s1
fixes the problem.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgcc1 depends on:
ii  gcc-10-base  10-20200202-1
ii  libc62.29-9
ii  libgcc-s110-20200202-1

libgcc1 recommends no packages.

libgcc1 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl45Bb4SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5MDkP/AoeAopCOY4NEL8+GG5qC/4xiQk4SKWY
tBqFKmEhrex/46+idUV9AmY5G7BGJQad1i0L551vcuyNye2utz6dP/2XIgSJk3Ai
HVSjApSGDdo8MDVW6w2C0GucGSQAX55XPGtC6BU7I5C5ukny+MZx6Z0R/5cOYjy9
BWL8KejRawltzKIZpPIT7DuA+OG1tAQ6njdfbQxn5ihNGIHXoEcgEShEVlBhx48I
lIadw5jKJkhK6LDYWmzfvigVo9NIC/IIgepvzapNrMirjjsQE6Q/OpsxMjakfk+t
+dI4kiBbPqXNqDyaSMgUG3nKYZcIjgMU14fMC2JbRKIOOvXMHzgn5I/oj3zxau50
qZ5l1Yk1Rkds0u9mGVxmrGefxEd5IWet2HVwsqhDXNz+xyHH0yZE59UbXcdO+mfq
JVn2vbbXUBpYaAVmKyaocinDlgUYMg987j+HCNQYtmbyXfgD0GobVc3yDJykHiRj
T3Isk2ZbwLZhT5yb2p4KTbodZO1AWbGW2wabODjgAfeCtOM3tJjUioVYvXlHCnVm
hxReC7+c81CvzkNA95hT23TL4GKu21KXUpD60TWUv3i6VFp2dvDs4YV2JGzPjXbB
zIlSk04AhOlzLP8N3gRRW0J+vLQdLB+7USeyDlNgbf7HPhuNlvekPsAwh/BxDxdf
bClIfmr3peYd
=lto4
-END PGP SIGNATURE-

Bug#950250: False positive for debian-watch-could-verify-download

[Felix Lechner]

Hi Ben,

Both of these bugs are probably caused by this line:


https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/watch.pm#L124

It requires that options are separated merely by commas (without
spaces) in watch file versions 3 or lower. You use version 3 with
spaces. In both cases all options after the first are disregarded.

The check has been for some time on my list for a rewrite. I finally
took the opportunity, and it is nearly done. Both bugs will be fixed
within a few days.

Thank you for helping to make Lintian better for everyone.

Kind regards
Felix Lechner

Bug#916260: gparted mounts partition without protection

[Marc Lehmann]

On Mon, Feb 03, 2020 at 01:07:55PM -0500, Phillip Susi  
wrote:
> > 3. Now *another user* on the same machine can access that file system,
> >which I unwittingly mounted and exposed.
> 
> I get it, I just don't understand why you would have a filesystem around
> whose internal permissions were not already set up correctly but instead
> you relied on not mounting it to protect it.

It happens also for filesystems with correct permissions - maybe this is
the point you have problems with?

The effective permissions for a path depend on more than just the
permissions of the file it refers to. For example, a root-only readable
file can still be changed by normal users if the directory is writable for
them.

That means the whole access path needs to be taken into account, and
this is why the security issue is in gparted, because gparted changes
effective permissions in ways not expected by the user, by mounting it in
an insecure location.

Or in other wors, gparted can make files accessible that weren't
accessible before, without the user reasonably expecting this (as the user
expectation is that gparted doesn't widen effective permissions).

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#950605: Please, enable micro-C plugin

[David Prévot]

Package: why3
Version: 1.2.1-2+b3
Severity: wishlist
Tags: upstream

Hi Ralf,

Upstream recently added a [micro-C] plugin that one can use [online],
but it’s not enabled in the Debian package.

  micro-C: https://gitlab.inria.fr/why3/why3/tree/master/plugins/microc
   online: http://why3.lri.fr/micro-C/

I realise it’s not actually available from the actual [source] used in
the Debian package, but don’t know why (that why I’ve also tagged this
bug “upstream”).

   source: https://gforge.inria.fr/frs/?group_id=2990

I’d very much like to use this plugin without the need to rely on a
webservice, so thanks in advance if you’re able to add such feature (and
yes, it’s already used in some courses ;).

Regards

David


signature.asc
Description: PGP signature

Bug#950604: gitg: Gdk-ERROR **: 04:20:22.357: The program 'gitg' received an X Window System error.

[Christoph Anton Mitterer]

Package: gitg
Version: 3.32.1-1
Severity: important


Hi.

When clicking at the a certain commit within gitg it crashes with the following 
in gdb:
$ gdb gitg .
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gitg...
(No debugging symbols found in gitg)
"/home/calestyo/prj/cfg/x/rkhunter/." is not a core dump: Is a directory
(gdb) run 
Starting program: /usr/bin/gitg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x720a8700 (LWP 2810892)]
[New Thread 0x718a7700 (LWP 2810893)]
[New Thread 0x70fb8700 (LWP 2810894)]
[New Thread 0x7fffe3fff700 (LWP 2810895)]
[New Thread 0x7fffe33ce700 (LWP 2810896)]
[New Thread 0x7fffe2bcd700 (LWP 2810897)]
[Thread 0x7fffe2bcd700 (LWP 2810897) exited]
[Thread 0x7fffe3fff700 (LWP 2810895) exited]
[New Thread 0x7fffe3fff700 (LWP 2810898)]
[Thread 0x7fffe3fff700 (LWP 2810898) exited]

(gitg:2810888): Gdk-ERROR **: 04:20:22.357: The program 'gitg' received an X 
Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 7135 error_code 11 request_code 130 (MIT-SHM) minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Thread 1 "gitg" received signal SIGTRAP, Trace/breakpoint trap.
_g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
554 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
#0  0x77d79e25 in _g_log_abort (breakpoint=1) at 
../../../glib/gmessages.c:554
#1  0x77d7c72c in g_log_writer_default (log_level=6, 
log_level@entry=G_LOG_LEVEL_ERROR, fields=fields@entry=0x7fffd0a0, 
n_fields=n_fields@entry=6, user_data=user_data@entry=0x0)
at ../../../glib/gmessages.c:2694
#2  0x77d7aa57 in g_log_structured_array (n_fields=6, 
fields=0x7fffd0a0, log_level=G_LOG_LEVEL_ERROR) at 
../../../glib/gmessages.c:1925
#3  0x77d7aa57 in g_log_structured_array (log_level=G_LOG_LEVEL_ERROR, 
fields=0x7fffd0a0, n_fields=6) at ../../../glib/gmessages.c:1898
#4  0x77d7b470 in g_log_structured_standard
(log_domain=log_domain@entry=0x77523017 "Gdk", 
log_level=log_level@entry=G_LOG_LEVEL_ERROR, file=file@entry=0x77541a00 
"../../../../../gdk/x11/gdkdisplay-x11.c", line=line@entry=0x77541457 
"2763", func=func@entry=0x775420f0 <__func__.78549> 
"_gdk_x11_display_error_event", 
message_format=message_format@entry=0x77542442 "%s")
at ../../../glib/gmessages.c:1982
#5  0x774e261a in _gdk_x11_display_error_event 
(display=display@entry=0x5564b080 [GdkX11Display], 
error=error@entry=0x7fffd6f0)
at ../../../../../gdk/x11/gdkdisplay-x11.c:2763
#6  0x774ef453 in gdk_x_error (error=0x7fffd6f0, 
xdisplay=0x5563c2b0) at ../../../../../gdk/x11/gdkmain-x11.c:307
#7  0x774ef453 in gdk_x_error (xdisplay=0x5563c2b0, 
error=0x7fffd6f0) at ../../../../../gdk/x11/gdkmain-x11.c:269
#8  0x7676714b in _XError () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x76763f77 in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x76764015 in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#11 0x76764f6d in _XReply () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#12 0x7676081d in XSync () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#13 0x774ef791 in _gdk_x11_display_send_xevent
(display=display@entry=0x5564b080 [GdkX11Display], window=, propagate=propagate@entry=0, event_mask=event_mask@entry=0, 
event_send=event_send@entry=0x7fffd930)
at ../../../../../gdk/x11/gdkmain-x11.c:363
#14 0x774f3fbb in _gdk_x11_display_send_selection_notify
(display=0x5564b080 [GdkX11Display], requestor=, 
selection=, target=0x8c, property=0x72, time=34849809)
at ../../../../../gdk/x11/gdkselection-x11.c:329
#15 0x77842f75 in _gtk_selection_request 
(widget=widget@entry=0x55770380 [GtkInvisible], 
event=event@entry=0x55c56d30) at 

Bug#950603: yodl-doc: Embeds timestamp in yodl.ps and yodl.dvi

[Vagrant Cascadian]

Package: yodl-doc
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The timestamp is embedded in /usr/share/doc/yodl-doc/yodl.ps.gz and
yodl.dvi.gz, which causes unreproducible builds.

The fix is to export FORCE_SOURCE_DATE=1 in debian/rules to get texlive
to respect the SOURCE_DATE_EPOCH variable.


live well,
  vagrant
From 24c81b1342e743fca81e0833a24e0c19cdd47776 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 4 Feb 2020 02:28:57 +
Subject: [PATCH] debian/rules: Set FORCE_SOURCE_DATE=1 so texlive respects
 SOURCE_DATE_EPOCH for reproducible builds.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index b790453..432de57 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,6 +24,9 @@ export CXX = g++
 
 export LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS) -Wl,-z,now
 
+# Set so texlive respects SOURCE_DATE_EPOCH for reproducible builds.
+export FORCE_SOURCE_DATE=1
+
 unexport NAME
 
 %:
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#885213: make-dfsg: please migrate to guile-2.2

[Rob Browning]

Actually now that guile-3.0 is in sid (though it's not yet building on
all the release architectures), I suppose we might just side-step 2.2
entirely, but either would be much appreciated.

Here this at least builds via "fakeroot debian/rules binary", but
regardless, I'd really like to resolve this soon.  I'm happy to make an
NMU if that's preferable.

Thanks

$ git diff
diff --git a/configure.ac b/configure.ac
index 02481ec..476f549 100644
--- a/configure.ac
+++ b/configure.ac
@@ -168,7 +168,7 @@ AC_ARG_WITH([guile], [AS_HELP_STRING([--with-guile],
 # comes with it's own PC file so we have to specify them as individual
 # packages.  Ugh.
 AS_IF([test "x$with_guile" != xno],
-[ PKG_CHECK_MODULES([GUILE], [guile-2.0], [have_guile=yes],
+[ PKG_CHECK_MODULES([GUILE], [guile-3.0], [have_guile=yes],
   [PKG_CHECK_MODULES([GUILE], [guile-1.8], [have_guile=yes],
 [have_guile=no])])
 ])
diff --git a/debian/control b/debian/control
index e251b40..3588b46 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 4.1.3
 Homepage: https://www.gnu.org/software/make/
 Build-Depends: gettext, po-debconf, debhelper (>= 9.0.0), dh-autoreconf,
autoconf, automake | automaken, autopoint, file, pkg-config,
-   guile-2.0-dev, procps, libbsd-resource-perl 
+   guile-3.0-dev, procps, libbsd-resource-perl 

 Package: make
 Suggests: make-doc

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#950602: iwlwifi: Intel Dual Band Wireless AC 3160 fails to run INIT calibrations

[John-Marc Chandonia]

Package: firmware-iwlwifi
Version: 20190717-2
Severity: important
File: iwlwifi

Dear Maintainer,

The built-in wifi on my ASRock H270M-ITX/ac motherboard recently
stopped working.  I'm not sure what led to the problem; the device
is frequently used and suddenly stopped working, so this may be a
hardware issue.

I tried upgrading to firmware-iwlwifi version 20190114-2 to the latest
testing version, 20190717-2, but that didn't help.  I also upgraded
the motherboard's bios to the latest version, 2.50, but that also
didn't help.

I see the following lines in dmesg:
[   11.123303] iwlwifi :03:00.0: firmware: direct-loading firmware 
iwlwifi-3160-17.ucode
[   11.123492] iwlwifi :03:00.0: loaded firmware version 17.3216344376.0 
op_mode iwlmvm

and later on:
[   12.351480] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 
3160, REV=0x164
[   12.369498] iwlwifi :03:00.0: base HW address: f4:06:69:f1:57:2f
[   13.162476] intel_rapl: Found RAPL domain package
[   13.162480] intel_rapl: Found RAPL domain core
[   13.162482] intel_rapl: Found RAPL domain uncore
[   13.162485] intel_rapl: Found RAPL domain dram
[   13.935816] Adding 7812092k swap on /dev/sda3.  Priority:-2 extents:1 
across:7812092k FS
[   14.401126] iwlwifi :03:00.0: Failed to run INIT calibrations: -110
[   14.418902] [ cut here ]
[   14.418904] Timeout waiting for hardware access (CSR_GP_CNTRL 0x)
[   14.418955] WARNING: CPU: 0 PID: 613 at 
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2009 
iwl_trans_pcie_grab_nic_access+0x1e8/0x220 [iwlwifi]
[   14.418957] Modules linked in: intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel intel_cstate iwlmvm(+) intel_uncore snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic btusb intel_rapl_perf btrtl btbcm 
mac80211 btintel snd_hda_intel bluetooth snd_hda_codec snd_hda_core snd_hwdep 
i915 snd_pcm drbg evdev iwlwifi snd_timer ansi_cprng snd ecdh_generic soundcore 
crc16 serio_raw cfg80211 drm_kms_helper drm iTCO_wdt pcspkr rfkill 
iTCO_vendor_support sg video mei_me pcc_cpufreq button mei acpi_pad xfs btrfs 
zstd_decompress zstd_compress xxhash dm_mod raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic 
raid0 multipath linear uas usb_storage raid1 md_mod
[   14.419036]  sd_mod crc32c_intel ahci libahci libata aesni_intel xhci_pci 
scsi_mod e1000e aes_x86_64 crypto_simd cryptd glue_helper xhci_hcd igb usbcore 
i2c_algo_bit dca i2c_i801 usb_common
[   14.419062] CPU: 0 PID: 613 Comm: modprobe Not tainted 4.19.0-6-amd64 #1 
Debian 4.19.67-2+deb10u2
[   14.419064] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./H270M-ITX/ac, BIOS P2.50 03/16/2018
[   14.419080] RIP: 0010:iwl_trans_pcie_grab_nic_access+0x1e8/0x220 [iwlwifi]
[   14.419084] Code: 54 d4 49 8d 56 08 bf 00 02 00 00 e8 12 fa 4a d3 e9 33 ff 
ff ff 89 c6 48 c7 c7 c0 40 a0 c0 c6 05 b0 46 02 00 01 e8 62 26 49 d3 <0f> 0b e9 
ee fe ff ff 48 8b 7b 30 48 c7 c1 28 41 a0 c0 31 d2 31 f6
[   14.419086] RSP: 0018:b1fa012c3b60 EFLAGS: 00010086
[   14.419090] RAX:  RBX: 903deb920018 RCX: 94e4dea8
[   14.419092] RDX: 0001 RSI: 0096 RDI: 0047
[   14.419094] RBP:  R08: 030b R09: 0004
[   14.419095] R10:  R11: 0001 R12: 903deb92a258
[   14.419097] R13: b1fa012c3b90 R14:  R15: 903debfd5548
[   14.419101] FS:  7f43367a0480() GS:903dee40() 
knlGS:
[   14.419103] CS:  0010 DS:  ES:  CR0: 80050033
[   14.419105] CR2: 563704d16528 CR3: 000265a7c005 CR4: 003606f0
[   14.419107] Call Trace:
[   14.419123]  iwl_set_bits_prph+0x37/0xa0 [iwlwifi]
[   14.419138]  _iwl_trans_pcie_stop_device.constprop.34+0x1de/0x2b0 [iwlwifi]
[   14.419152]  iwl_trans_pcie_stop_device+0x2e/0x50 [iwlwifi]
[   14.419179]  iwl_op_mode_mvm_start+0x6d7/0x990 [iwlmvm]
[   14.419195]  iwl_opmode_register+0x7c/0xf0 [iwlwifi]
[   14.419200]  ? 0xc0d4d000
[   14.419220]  iwl_mvm_init+0x34/0x1000 [iwlmvm]
[   14.419228]  do_one_initcall+0x46/0x1c3
[   14.419233]  ? free_unref_page_commit+0x91/0x100
[   14.419239]  ? _cond_resched+0x15/0x30
[   14.419244]  ? kmem_cache_alloc_trace+0x169/0x1d0
[   14.419250]  do_init_module+0x5a/0x210
[   14.419254]  load_module+0x2118/0x2390
[   14.419263]  ? __do_sys_finit_module+0xad/0x110
[   14.419266]  __do_sys_finit_module+0xad/0x110
[   14.419273]  do_syscall_64+0x53/0x110
[   14.419280]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   14.419283] RIP: 0033:0x7f43368baf59
[   14.419287] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48
[   14.419289] RSP: 

Bug#950601: lsof: Unreadable manpage

[Celelibi]

Package: lsof
Version: 4.93.2+dfsg-1
Severity: normal

Dear Maintainer,

Here's the output of man when trying to read it.

$ man lsof
man: can't open /usr/share/man/./version: No such file or directory
No manual entry for lsof

I think some script didn't run properly to format the version number at
the begining of the man page.

Best regards,
Celelibi

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages lsof depends on:
ii  libc62.29-9
ii  libselinux1  3.0-1

lsof recommends no packages.

Versions of packages lsof suggests:
ii  perl  5.30.0-9

-- no debconf information

Bug#950600: jupyter-notebook: starts jupyter notebook for all users automatically

[Norbert Preining]

Package: jupyter-notebook
Version: 6.0.3-1
Severity: important

The service file for jupyter-notebook is installed and activated for
users, that means that even the lightdm user has a jupyter notebook
running.

This unit should either not be shipped, or disabled.

Norbert


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

Kernel: Linux 5.5.1 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jupyter-notebook depends on:
ii  init-system-helpers  1.57
ii  jupyter-core 4.6.1-1
ii  python3  3.7.5-3
ii  python3-notebook 6.0.3-1

jupyter-notebook recommends no packages.

jupyter-notebook suggests no packages.

-- no debconf information

Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library

[Nick Black]

John Goerzen left as an exercise for the reader:
> I have been rather annoyed at the increasing number of curses-like
> libraries that only work with ANSI terminals.  It is refreshing to see a
> new one that properly supports terminfo!

You might also be pleased to learn that notcurses, unlike so
many C libraries of late, also has a complete set of man pages:

  https://nick-black.com/notcurses/

They're of course present in the -dev package.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library

[Nick Black]

John Goerzen left as an exercise for the reader:
> Very cool!  (and apologies for missing it in the readme)

no problem at all; i merely wanted to highlight its existence,
as it has a great deal of information (i'm trying to properly
bear the torch of Thomas E. Dickey, who as ncurses maintainer
has written one of the all-time great bits of software
documentation in his NCURSES FAQ).

> I have been rather annoyed at the increasing number of curses-like
> libraries that only work with ANSI terminals.  It is refreshing to see a
> new one that properly supports terminfo!

you can credit Mr. Dickey with this. i was inspired to start
work on notcurses last November after reading Lexi Summer Hale's
essay "On Temrinal Emulators" (http://xn--rpa.cc/irl/term.html).
one of the things i disagreed with her on was the value of
terminfo support, something Mr. Dickey states numerous times in
his FAQ.

> I own a number of actual serial terminals from the 80s and 90s and
> actively use them in various projects.  They of course know nothing of
> Unicode (another challenge) or color, but otherwise are still quite
> functional.

i am the owner of no such devices, and any testing you can
perform on them would be invaluable to me :D. i will eagerly
move to fix problems you run into. so long as you're not
providing supraASCII characters for output, you needn't worry
about them being emitted.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

Bug#950599: RFS: xca/2.2.1-1 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca".  This is a new upstream
version release.

* Package name : xca
Version : 2.2.1-1
Upstream Author : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/xca

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.2.1-1.dsc

Changes since the last upload:

* New upstream release (2.2.1).
* d/control: Update Standards-Version to 4.5.0.
* d/patches/0001-Remove-misc-Info.plist-in-clean-target.patch: Refresh patch
* d/patches/0002-pkg-config-remove-hardcoding.patch: Refresh patch

Regards,

Bug#950598: python3-jupyter-sphinx: package relies on unavailable `ipywidgets.embed` module

[Sebastian Luque]

Package: python3-jupyter-sphinx
Version: 0.2.3-1
Severity: grave

Dear Maintainer,

The package is unuseable, as it relies on the `ipywidgets.embed` module,
which is unavailable in the latest sid version:

Extension error:
Could not import extension jupyter_sphinx.execute (exception: No module named 
'ipywidgets.embed')


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-jupyter-sphinx depends on:
ii  python3 3.7.5-3
ii  python3-ipython 5.8.0-2
ii  python3-ipywidgets  6.0.0-6
ii  python3-nbconvert   5.6.1-1
ii  python3-nbformat5.0.4-1
ii  python3-sphinx  1.8.5-5

python3-jupyter-sphinx recommends no packages.

python3-jupyter-sphinx suggests no packages.

-- no debconf information

Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library

[John Goerzen]

Very cool!  (and apologies for missing it in the readme)

I have been rather annoyed at the increasing number of curses-like
libraries that only work with ANSI terminals.  It is refreshing to see a
new one that properly supports terminfo!

I own a number of actual serial terminals from the 80s and 90s and
actively use them in various projects.  They of course know nothing of
Unicode (another challenge) or color, but otherwise are still quite
functional.

Best,

John

On Mon, Feb 03 2020, Nick Black wrote:

> Your questions are answered in the README.md, I believe:
>
> https://github.com/dankamongmen/notcurses
>
> Yes, it is powered by (and requires) Terminfo. It ought work, more or less,
> with all terminals capable of cursor-based addressing ("cup" Terminfo
> capability). It quantizes color down at the moment in the absence of 24bit
> RGB support, but I plan to issue perfect palettes for terminals with the
> "ccc" capability Real Soon Now.
>
> On Mon, Feb 3, 2020, 19:47 John Goerzen  wrote:
>
>> Hi Nick,
>>
>> This is interesting.  Out of curiosity, does notcurses still support
>> terminfo and provide a functional implementation on non-ANSI terminals?
>> (eg, IBM3151, etc)
>>
>>
>> On Sun, Feb 02 2020, Nick Black wrote:
>>
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Nick Black 
>> >
>> > * Package name: notcurses
>> >   Version : 1.1.4
>> >   Upstream Author : Nick Black 
>> > * URL : https://nick-black.com/dankwiki/index.php/notcurses
>> > * License : Apache-2.0
>> >   Programming Lang: C, C++, Python
>> >   Description : Character-mode graphics and TUI library
>> >
>> >  notcurses facilitates the creation of modern TUI programs,
>> >  making full use of Unicode and 24-bit direct color. It presents
>> >  an API similar to that of Curses, and rides atop libtinfo.
>> >
>> > Work on notcurses began in November of 2019, and it has had
>> Debian-compatible
>> > infrastructure (debhelper compat level 12) from the beginning. As of
>> February
>> > 2020, it is rapidly stabilizing, and being used in several tools. I've
>> > rewritten my "growlight" disk management tool using notcurses instead of
>> > ncurses, cutting out several thousand lines of UI code along the way.
>> Nestopia
>> > is about to merge notcurses support (coming out of maintenance mode to
>> do so).
>> > I'm working on a console SDR visualization tool that will make working
>> with
>> > remote SDRs much more pleasant, and expect to release it soon.
>> >
>> > Sid/unstable debs are available (and have been available for weeks) in
>> my repo
>> > at https://www.dsscaw.com/apt (this repo is available in Wouter
>> Verhelst's
>> > extrepo tool). The Debian packaging that I currently have can be seen
>> here:
>> > https://github.com/dankamongmen/notcurses/tree/master/debian
>> >
>> > Notcurses can be regarded as a successor to ncurses. It provides much of
>> the
>> > functionality of that package, with major improvements IMHO regarding
>> Unicode,
>> > multithreading, and color support. 24-bit RGB with two bits of
>> transparency is
>> > the fundamental color space, and input/output are entirely based off
>> UTF8 and
>> > Unicode's Extended Grapheme Clusters. I've written many thousand lines of
>> > ncurses code in my life, and expect to write no more--notcurses will
>> entirely
>> > supplant it in my projects. ncurses is a venerable, robust library, with
>> a
>> > fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to
>> > X/OSI. It's time to move past 90s-era TUI APIs.
>> >
>> > As for maintaining the package, I've written 90%+ of the code in
>> notcurses, and
>> > intend to maintain it for the long haul. I'm actively committed to
>> maintaining
>> > the Debian/Ubuntu packaging, and indeed hope to use it as a springboard
>> towards
>> > Debian Developer status.
>> >
>> > notcurses has been included in Arch's AUR since its 0.4.0 release in
>> November
>> > 2019.
>>
>>

Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library

[Nick Black]

Your questions are answered in the README.md, I believe:

https://github.com/dankamongmen/notcurses

Yes, it is powered by (and requires) Terminfo. It ought work, more or less,
with all terminals capable of cursor-based addressing ("cup" Terminfo
capability). It quantizes color down at the moment in the absence of 24bit
RGB support, but I plan to issue perfect palettes for terminals with the
"ccc" capability Real Soon Now.

On Mon, Feb 3, 2020, 19:47 John Goerzen  wrote:

> Hi Nick,
>
> This is interesting.  Out of curiosity, does notcurses still support
> terminfo and provide a functional implementation on non-ANSI terminals?
> (eg, IBM3151, etc)
>
>
> On Sun, Feb 02 2020, Nick Black wrote:
>
> > Package: wnpp
> > Severity: wishlist
> > Owner: Nick Black 
> >
> > * Package name: notcurses
> >   Version : 1.1.4
> >   Upstream Author : Nick Black 
> > * URL : https://nick-black.com/dankwiki/index.php/notcurses
> > * License : Apache-2.0
> >   Programming Lang: C, C++, Python
> >   Description : Character-mode graphics and TUI library
> >
> >  notcurses facilitates the creation of modern TUI programs,
> >  making full use of Unicode and 24-bit direct color. It presents
> >  an API similar to that of Curses, and rides atop libtinfo.
> >
> > Work on notcurses began in November of 2019, and it has had
> Debian-compatible
> > infrastructure (debhelper compat level 12) from the beginning. As of
> February
> > 2020, it is rapidly stabilizing, and being used in several tools. I've
> > rewritten my "growlight" disk management tool using notcurses instead of
> > ncurses, cutting out several thousand lines of UI code along the way.
> Nestopia
> > is about to merge notcurses support (coming out of maintenance mode to
> do so).
> > I'm working on a console SDR visualization tool that will make working
> with
> > remote SDRs much more pleasant, and expect to release it soon.
> >
> > Sid/unstable debs are available (and have been available for weeks) in
> my repo
> > at https://www.dsscaw.com/apt (this repo is available in Wouter
> Verhelst's
> > extrepo tool). The Debian packaging that I currently have can be seen
> here:
> > https://github.com/dankamongmen/notcurses/tree/master/debian
> >
> > Notcurses can be regarded as a successor to ncurses. It provides much of
> the
> > functionality of that package, with major improvements IMHO regarding
> Unicode,
> > multithreading, and color support. 24-bit RGB with two bits of
> transparency is
> > the fundamental color space, and input/output are entirely based off
> UTF8 and
> > Unicode's Extended Grapheme Clusters. I've written many thousand lines of
> > ncurses code in my life, and expect to write no more--notcurses will
> entirely
> > supplant it in my projects. ncurses is a venerable, robust library, with
> a
> > fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to
> > X/OSI. It's time to move past 90s-era TUI APIs.
> >
> > As for maintaining the package, I've written 90%+ of the code in
> notcurses, and
> > intend to maintain it for the long haul. I'm actively committed to
> maintaining
> > the Debian/Ubuntu packaging, and indeed hope to use it as a springboard
> towards
> > Debian Developer status.
> >
> > notcurses has been included in Arch's AUR since its 0.4.0 release in
> November
> > 2019.
>
>

Bug#950597: git-gui "Show History Context" raises "Application Error"

[Benjamin Poirier]

Package: git-gui
Version: 1:2.25.0-1
Severity: normal

When running `git gui blame` and using "Show history context", git-gui pops up
an "Application Error" window which says 'Error: can't read "::main_status":
no such variable'. Clicking "OK" closes the window and the rest of the
functionality appears unaffected.

To reproduce:
inside a git repository, for example a clone of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git,
run
$ git gui blame Makefile
After the git-gui status bar show "Annotation complete", right click on a
source line (ex. line #1) and choose "Show History Context". `gitk` is started
and the window with the error message appears.

Using https://snapshot.debian.org/binary/git-gui/ I tested that
1:2.25.0~rc2-1 is bad
1:2.25.0~rc1-1 is good

I also tested that the problem is still present in 1:2.25.0+next.20200116-1

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-gui depends on:
ii  git  1:2.25.0-1
ii  tk   8.6.9+1+b1

Versions of packages git-gui recommends:
ii  gitk  1:2.25.0-1

Versions of packages git-gui suggests:
ii  aspell   0.60.8-1
pn  git-doc  
pn  meld 

-- no debconf information

Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library

[John Goerzen]

Hi Nick,

This is interesting.  Out of curiosity, does notcurses still support
terminfo and provide a functional implementation on non-ANSI terminals?
(eg, IBM3151, etc)  


On Sun, Feb 02 2020, Nick Black wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Nick Black 
>
> * Package name: notcurses
>   Version : 1.1.4
>   Upstream Author : Nick Black 
> * URL : https://nick-black.com/dankwiki/index.php/notcurses
> * License : Apache-2.0
>   Programming Lang: C, C++, Python
>   Description : Character-mode graphics and TUI library
>
>  notcurses facilitates the creation of modern TUI programs,
>  making full use of Unicode and 24-bit direct color. It presents
>  an API similar to that of Curses, and rides atop libtinfo.
>
> Work on notcurses began in November of 2019, and it has had Debian-compatible
> infrastructure (debhelper compat level 12) from the beginning. As of February
> 2020, it is rapidly stabilizing, and being used in several tools. I've
> rewritten my "growlight" disk management tool using notcurses instead of
> ncurses, cutting out several thousand lines of UI code along the way. Nestopia
> is about to merge notcurses support (coming out of maintenance mode to do so).
> I'm working on a console SDR visualization tool that will make working with
> remote SDRs much more pleasant, and expect to release it soon.
>
> Sid/unstable debs are available (and have been available for weeks) in my repo
> at https://www.dsscaw.com/apt (this repo is available in Wouter Verhelst's
> extrepo tool). The Debian packaging that I currently have can be seen here:
> https://github.com/dankamongmen/notcurses/tree/master/debian
>
> Notcurses can be regarded as a successor to ncurses. It provides much of the
> functionality of that package, with major improvements IMHO regarding Unicode,
> multithreading, and color support. 24-bit RGB with two bits of transparency is
> the fundamental color space, and input/output are entirely based off UTF8 and
> Unicode's Extended Grapheme Clusters. I've written many thousand lines of
> ncurses code in my life, and expect to write no more--notcurses will entirely
> supplant it in my projects. ncurses is a venerable, robust library, with a
> fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to
> X/OSI. It's time to move past 90s-era TUI APIs.
>
> As for maintaining the package, I've written 90%+ of the code in notcurses, 
> and
> intend to maintain it for the long haul. I'm actively committed to maintaining
> the Debian/Ubuntu packaging, and indeed hope to use it as a springboard 
> towards
> Debian Developer status.
>
> notcurses has been included in Arch's AUR since its 0.4.0 release in November
> 2019.

Bug#950591: O: aboot

[Skye]

Thank you Adrian!

-Original Message-
From: John Paul Adrian Glaubitz [mailto:glaub...@physik.fu-berlin.de] 
Sent: Monday, February 03, 2020 2:57 PM
To: Debian Bug Tracking System
Subject: Bug#950591: O: aboot

Package: wnpp
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha

Hi!

I am orphaning aboot on behalf of the current maintainer now as he
has agreed on removing the package [1].

I would like to adopt aboot and address the open RC bugs so it can
be kept in the main archive. This way we don't have to upload the
package to the Debian Ports unreleased archive in order to be able
to build installation images for the alpha architecture.

I will update the package to use the fork of aboot that is being
maintained by a Gentoo developer on Github [2].

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949711#10
> [2] https://github.com/mattst88/aboot

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#950596: Completion for git add on directory path appends "./" rather than filename in directory

[Josh Triplett]

Package: git
Version: 1:2.25.0-1
Severity: normal
File: /usr/share/bash-completion/completions/git

/tmp$ git init test-repo
Initialized empty Git repository in /tmp/test-repo/.git/
/tmp$ cd test-repo/
/tmp/test-repo$ mkdir src
/tmp/test-repo$ touch src/main.rs

At this point, if you type "git add src/" and then press tab, the
completion appends "./" rather than appending "main.rs".

Using Alt-/ to complete a filename will append "main.rs" as expected.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git depends on:
ii  git-man  1:2.25.0-1
ii  libc62.29-9
ii  libcurl3-gnutls  7.67.0-2
ii  liberror-perl0.17029-1
ii  libexpat12.2.9-1
ii  libpcre2-8-0 10.34-7
ii  perl 5.30.0-9
ii  zlib1g   1:1.2.11.dfsg-1.1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1
ii  openssh-client [ssh-client]  1:8.1p1-5
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-10
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
ii  git-svn   1:2.25.0-1
ii  gitk  1:2.25.0-1
pn  gitweb

-- no debconf information

Bug#949584: mmdebstrap fails to create temp file if TMPDIR is set to directory with mode 0755

[Johannes Schauer]

Control: tag -1 + moreinfo

Hi,

Quoting Johannes Schauer (2020-01-22 21:40:49)
> Quoting Benjamin Drung (2020-01-22 13:23:36)
> > Am Mittwoch, den 22.01.2020, 13:13 +0100 schrieb Johannes Schauer:
> > > Quoting Benjamin Drung (2020-01-22 12:58:38)
> > > > when I set TMPDIR to a directory that has mode 0755, mmdebstrap
> > > > will fail:
> > > > 
> > > > ```
> > > > $ ls -ld .
> > > > drwxr-xr-x 3 bdrung bdrung 80 Jan 22 12:43 .
> > > > $ TMPDIR=$(pwd) mmdebstrap buster buster.tar.xz
> > > > I: automatically chosen mode: unshare
> > > 
> > > you are using the unshare mode. This means that your temporary
> > > directory needs
> > > to be accessible by the unshared user. Evidently it is not. I don't
> > > think there
> > > is anything that mmdebstrap can do about it.
> > 
> > mmdebstrap could create a temporary directory, change the mode to 1777 and
> > let unshare use that, couldn't it?
> 
> but that's not where the error comes from. From the output you posted in your
> report it seems like mmdebstrap is not able to create the temporary directory
> at all. Obviously it cannot change permissions of something that doesn't 
> exist.
> I don't think mmdebstrap should attempt touching the permissions of the 
> $TMPDIR
> directory.
> 
> Also: the sticky bit probably has no influence on whether or not you get the
> "permission denied" error, right?

any update on this issue?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#950595: cwidget: menu widget highlights ACS_VLINE on left side of selected item

[Nick Black]

Source: cwidget
Version: 0.5.18
Severity: minor
Tags: upstream

Dear Maintainer,

I noticed while running `testcwidget` that the left ACS_VLINE of a highlighted
item in the menu is shown as blue-on-white (I'm not sure whether this is due to
the color pair being set up that way, or whether A_REVERSE is in play).

I looked into the upstream git source for an hour or so, and couldn't figure it
out, so I'm filing this. I might take a look again later if no one else knocks
this out.

This was noticed while analyzing cwidget behavior for the purposes of designing
the notcurses widget. Thanks for being an inspiration!



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.15nlb (SMP w/20 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#948786: buster-pu: package apt-cacher-ng/3.2.1-1 pre-approval

[Adam D. Barratt]

On Mon, 2020-02-03 at 21:05 +0100, Eduard Bloch wrote:
> Hallo,
> * Adam D. Barratt [Tue, Jan 28 2020, 10:28:08PM]:
> 
> > > I can, of course, convert all that into debian/patches/XXX but
> > > honestly, that would really feel like greenwashing.
> > > 
> > > The changes reported here can be reviewed at
> > > https://salsa.debian.org/blade/apt-cacher-ng/commits/temp/debian-merge
> > > ,
> > > starting with the commit from 2019-12-20.
> > 
> > Those look OK as individual commits, thanks. For completeness,
> > could we
> > please have a finalised source debdiff of the built source package,
> > compared to current stable?
> 
> Of course, attached.

I noticed that you also uploaded. Note that proposed-updates is
currently frozen in preparation for the point releases on Saturday, so
the package won't be processed until some point after that happens.

Regards,

Adam

Bug#950594: flang FTBFS: dwz: Too many DIEs, not optimizing

[Adrian Bunk]

Source: flang
Version: 20190329-4
Severity: serious
Tags: ftbfs

...
   dh_dwz -O--buildsystem=cmake 
-O--builddirectory=/tmp/flang-20190329/debian/build
install -d debian/flang-7/usr/lib/debug/.dwz/x86_64-linux-gnu
dwz -mdebian/flang-7/usr/lib/debug/.dwz/x86_64-linux-gnu/flang-7.debug 
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/flang-7.debug -- 
debian/flang-7/usr/bin/flang-7 debian/flang-7/usr/bin/flang1 
debian/flang-7/usr/bin/flang2
dwz: debian/flang-7/usr/bin/flang-7: Too many DIEs, not optimizing
dwz: debian/flang-7/usr/bin/flang1: DWARF compression not beneficial - old size 
2259002 new size 2265054
dh_dwz: error: dwz 
-mdebian/flang-7/usr/lib/debug/.dwz/x86_64-linux-gnu/flang-7.debug 
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/flang-7.debug -- 
debian/flang-7/usr/bin/flang-7 debian/flang-7/usr/bin/flang1 
debian/flang-7/usr/bin/flang2 returned exit code 1
make: *** [debian/rules:14: binary] Error 25

Bug#950576: [Pkg-utopia-maintainers] Bug#950576: Bug#950576: Just do not want to fix? Normal among more thant 200 other that stay unfixed?

[Michael Biebl]

Am 03.02.20 um 23:31 schrieb Eric Valette:
> On 03/02/2020 22:57, Michael Biebl wrote:
>> Please read up on what the different severity levels mean.
> 
> network-manager breaks my system and probably manu others because using
> it I have no network.
> 
>> That said, I don't think your response is appropriate and I'm not
>> willing to have a discussion like that.
> 
> As I do not think handling bug like you did is appriopriate. I provided
> the requested info so what are you going to do with the info?

Ok, I'm out. Good bye



signature.asc
Description: OpenPGP digital signature

Bug#950576: [Pkg-utopia-maintainers] Bug#950576: Just do not want to fix? Normal among more thant 200 other that stay unfixed?

[Eric Valette]

On 03/02/2020 22:57, Michael Biebl wrote:

Please read up on what the different severity levels mean.


network-manager breaks my system and probably manu others because using 
it I have no network.



That said, I don't think your response is appropriate and I'm not
willing to have a discussion like that.


As I do not think handling bug like you did is appriopriate. I provided 
the requested info so what are you going to do with the info?


Remove the tag moreinfo at least?

-- eric

Bug#943343:

[Mario.Limonciello]

I expect that this should not be happening with current systemd in testing and 
fwupd in testing (or unstable).  Can you please confirm?

Bug#950593: clonezilla, raises many errors when clone on the fly

[PICCORO McKAY Lenz]

Package: clonezilla
Version: 3.27.16-1
Severity: normal

seems problems are related to the new behaviour of the systemd and
limited PATH's ...
trying to clone on the fly partitions beetween disk give me errors
before continue at confirm questions:

/usr/sbin/ocs-onthefly: line 2247:
ocs_onthefly_param_postaction_after_clone: command not found


after clone more errors:

*.
/usr/sbin/ocs-onthefly: line 2545: /var/lib/clonezilla/ocs-vars: No
such file or directory
/usr/sbin/ocs-onthefly: line 2546: /var/lib/clonezilla/ocs-vars: No
such file or directory
/usr/sbin/ocs-onthefly: line 2547: /var/lib/clonezilla/ocs-vars: No
such file or directory
Checking if udevd rules have to be restored...
Now syncing - flush filesystem buffers...
Ending /usr/sbin/ocs-onthefly at 2020-02-03 22:17:57 UTC...

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500,
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8),
LANGUAGE=es_VE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages clonezilla depends on:
ii  bc  1.06.95-9+b3
ii  dialog  1.3-20160828-2
ii  drbl2.20.11-1
ii  file1:5.30-1+deb9u1
ii  gdisk   1.0.1-1
ii  pigz2.3.4-1
ii  util-linux  2.29.2-1

Versions of packages clonezilla recommends:
pn  partclone  
pn  partimage  

Versions of packages clonezilla suggests:
ii  cifs-utils  2:6.7-1
ii  openssh-client  1:7.6p1-2
pn  sshfs   
pn  udpcast 

-- no debconf information


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#949187: libgcc_s breakage Re: Bug#949187: transition: python3.8

[Rebecca N. Palmer]

Matthias Klose wrote:
On 2/3/20 8:22 PM, Simon McVittie wrote: >> Meanwhile, multiple packages seem to FTBFS on s390x with the new 

libgcc_s

(I've just opened the bug for that, so no bug number known yet), which is
going to limit the ability to get things into testing.


please retry your package builds. it's fixed in unstable.


Do you mean #950525?  If so, you might need to wait a few hours because 
the fix (gcc-9 9.2.1-28) is still being built.


When it is ready, please retry pandas and statsmodels in experimental. 
(DMs can't do self-service give-backs.)

Bug#947061: libsdl2-gfx-dev missing SDL2_gfxPrimitives_font.h

[Felix Geyer]

Hi David,

On 20.12.19 08:10, David Griffith wrote:

Package: libsdl2-gfx-dev
Version: 1.0.4+dfsg-3
Severity: important

I tried to compile a program that requires SDL2_gfxPrimitives_font.h
from libsdl2-gfx-dev.  Specifically I tried to compile
https://github.com/lkundrak/koules from the SDL2 branch.

Doing "make -f Makefile.sdl" resulted in this:
...
gcc -g3 -Wall -Wno-error=array-bounds -Wno-error=unused-but-set-variable -Wno-error=unused-function -Isdl -DHAVEUSLEEP  
-D_REENTRANT -I/usr/include/SDL2   -DSOUNDDIR="\"/usr/local/lib/koules\"" -D SOUND -D MOUSE -D NETSUPPORT 
-DSOUNDSERVER=\"/usr/local/libexec/koules/koules.sndsrv.linux\" -DSOUNDDIR=\"/usr/local/lib/koules\" 
-DSOUNDDEV=\"/dev/dsp\" -DNODIRECT -DSDLSUPPORT -fomit-frame-pointer -O3 -ffast-math -Dlinux -Wall -Wall -c -o 
sdl/init.o sdl/init.c
sdl/init.c:24:10: fatal error: SDL2_gfxPrimitives_font.h: No such file or 
directory
  #include 
   ^~~
compilation terminated.
make: *** [Makefile.sdl:54: sdl/init.o] Error 1


This seems to be a bug in koules.
SDL2_gfxPrimitives_font.h is not installed by the upstream build system so
it's not in the Debian package.

The documentation of gfxPrimitivesSetFont says:
> \param fontdata Pointer to array of font data. Set to NULL, to reset global font to the default 
8x8 font.


So calling gfxPrimitivesSetFont with NULL as fontdata is what koules should
do instead of using gfxPrimitivesFontdata from a private header file.

Cheers,
Felix

Bug#950592: bibledit-cloud: please enable parallel building

[Pino Toscano]

Source: bibledit-cloud
Version: 5.0.813-1
Severity: wishlist
Tags: patch

Hi,

bibledit-cloud seems to build fine with multiple build jobs when
building. Thus, my suggestion is to enable the parallel build (with the
--parallel option of dh) to speed up the compilation when requested
(see also Policy §4.9.1).

(An alternative is to bump the debhelper compatibility to >= 10,
however that requires checking for other changes due to the
compatibility bump.)

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 export DH_VERBOSE=1
 
 %:
-   dh $@ --with autoreconf --with systemd
+   dh $@ --parallel --with autoreconf --with systemd
 
 override_dh_installchangelogs:
dh_installchangelogs help/changelog.html

Bug#950575: kamailio manual install fails die modules are not yet in path?¡

[Michael Biebl]

Control: reassign -1 kamailio

I don't see any systemd related failure here, so reassigning accordingly.

@kamailio maintainer: If you think there is something to fix on the
systemd, please reassign back with more details. The currently available
information suggests there is a temporary issue with the kamailo
configuration.




signature.asc
Description: OpenPGP digital signature

Bug#950591: O: aboot

[John Paul Adrian Glaubitz]

Package: wnpp
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha

Hi!

I am orphaning aboot on behalf of the current maintainer now as he
has agreed on removing the package [1].

I would like to adopt aboot and address the open RC bugs so it can
be kept in the main archive. This way we don't have to upload the
package to the Debian Ports unreleased archive in order to be able
to build installation images for the alpha architecture.

I will update the package to use the fork of aboot that is being
maintained by a Gentoo developer on Github [2].

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949711#10
> [2] https://github.com/mattst88/aboot

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#950575: kamailio manual install fails die modules are not yet in path?¡

[Michael Biebl]

Am 03.02.20 um 20:01 schrieb PICCORO McKAY Lenz:
>> Please run
>> reportbug --template systemd
>> reportbug --template kamailio
> already done

No, this information is completely missing.




signature.asc
Description: OpenPGP digital signature

Bug#950576: [Pkg-utopia-maintainers] Bug#950576: Just do not want to fix? Normal among more thant 200 other that stay unfixed?

[Michael Biebl]

Please read up on what the different severity levels mean.

That said, I don't think your response is appropriate and I'm not
willing to have a discussion like that.

Feel free to help with triaging bugs if you consider the current
situation unsatisfactory.





signature.asc
Description: OpenPGP digital signature

Bug#950590: evolution: Reportbug information for evolution is out of date: gitlab, not bugzilla

[Conrad J.C. Hughes (for Debian package stuff)]

Package: evolution
Version: 3.30.5-1.1
Severity: normal

Dear Maintainer,

The reportbug information for evolution, wherein you redirect people to
upstream, seems arguably out-of-date, in that you send people to
bugzilla.gnome.org, which is no longer accepting new bugs, and ask for a
Forwarded-To: header which links to same.

A pointer to https://gitlab.gnome.org/GNOME/evolution would seem more
appropriate (and helpful: it's *really* non-obvious how to find package pages
on gitlab!), and the sample bug link should probably be something like
https://gitlab.gnome.org/GNOME/evolution/issues/772.

Best regards,
Conrad



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evolution depends on:
ii  dbus   1.12.16-1
ii  evolution-common   3.30.5-1.1
ii  evolution-data-server  3.30.5-1
ii  libc6  2.28-10
ii  libcamel-1.2-623.30.5-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-1.2-19 3.30.5-1
ii  libedataserver-1.2-23  3.30.5-1
ii  libevolution   3.30.5-1.1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgtk-3-0 3.24.5-1
ii  libical3   3.0.4-3
ii  libnotify4 0.7.7-4
ii  libsoup2.4-1   2.64.2-2
ii  libwebkit2gtk-4.0-37   2.26.3-1~deb10u1
ii  libxml22.9.4+dfsg1-7+b3
ii  psmisc 23.2-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.30.5-1.1
ii  evolution-plugin-pstimport   3.30.5-1.1
ii  evolution-plugins3.30.5-1.1
ii  yelp 3.31.90-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.12-1+deb10u1
ii  network-manager 1.14.6-2+deb10u1

-- debconf-show failed

Bug#950589: lintian: collection/src-orig-index mishandles tarballs with whitespace in owner field

[Niko Tyni]

Package: lintian
Version: 2.47.0
Severity: minor

Lintian reports false warnings for src:libcryptx-perl_0.067-1
(only just uploaded, available at [1]):

  % lintian -I libcryptx-perl_0.067-1.dsc
  I: libcryptx-perl source: unused-file-paragraph-in-dep5-copyright paragraph 
at line 10
  I: libcryptx-perl source: unused-file-paragraph-in-dep5-copyright paragraph 
at line 16
  I: libcryptx-perl source: unused-file-paragraph-in-dep5-copyright paragraph 
at line 22
  I: libcryptx-perl source: unused-file-paragraph-in-dep5-copyright ... use 
--no-tag-display-limit to see all (or pipe to a file/program)
  I: libcryptx-perl source: wildcard-matches-nothing-in-dep5-copyright ppport.h 
(paragraph at line 10)
  I: libcryptx-perl source: wildcard-matches-nothing-in-dep5-copyright 
src/ltc/* (paragraph at line 16)
  I: libcryptx-perl source: wildcard-matches-nothing-in-dep5-copyright 
src/ltc/hashes/blake2b.c (paragraph at line 22)
  I: libcryptx-perl source: wildcard-matches-nothing-in-dep5-copyright ... use 
--no-tag-display-limit to see all (or pipe to a file/program)

This is not a fault with the copyright file afaics, but rather with
the file name matching.

The original tarball from [2] includes ownership info with whitespace,
an example line:

  -rw-r--r-- miko/Domain Users 220789 2019-06-07 10:40 CryptX-0.067/ppport.h

It looks like this confuses the common prefix removal in
collection/src-orig-index:index_orig() which relies on the file name
being in the sixth whitespace separated field.

I see #895175 was a similar issue and resulted in a rather complicated
regexp in Lintian::Collect::Package for parsing tar output (commit
a75f3edcb099bd4b8794e2ecb7fd19e129e77f03). I expect something like that
should work here as well. Sorry about the lack of a patch.

[1] https://salsa.debian.org/perl-team/modules/packages/libcryptx-perl.git 
[2] https://cpan.metacpan.org/authors/id/M/MI/MIK/CryptX-0.067.tar.gz

Thanks for your work on lintian,
-- 
Niko Tyni   nt...@debian.org

Bug#950588: (no subject)

[Fabrice BAUZAC]

Package: wnpp
Severity: wishlist
Owner: Fabrice BAUZAC 

* Package name: golang-github-jfrog-gofrog
  Version : 1.0.5-1
  Upstream Author : JFrog Ltd.
* URL : https://github.com/jfrog/gofrog
* License : Apache-2.0
  Programming Lang: Go
  Description : A collection of go utilities

Description: The gofrog collection of go utilities (library)
 This collection from JFrog contains modules for:
 * Running tasks in parallel
 * Caches following the Least-recently-used policy
 * Running commands and reading their output
 * Creating random files
 * A reader that publishes to multiple consumers
 * Basic AES encryption/decryption

Note: my ultimate goal is to package the JFrog-CLI commandline tool
(Apache-2.0 license).  golang-github-jfrog-gofrog is one of its
dependencies, and I have run dh-make-golang to help me make it.

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

[Sean Whitton]

Hello dkg,

On Fri 31 Jan 2020 at 05:43PM -05, Daniel Kahn Gillmor wrote:

> Thanks for the extensive review.  I've revised imap-dl, taking it into
> account, and have attached the revised version here.  You can also find
> it on my imap-dl-v2 branch on salsa.

Please send a v3 patch, or rebase your branch, so that I can compare
directly your v2 and v3 revisions of this work.  Right now it is
difficult for me to know which changes are in response to my review of
your v2 patch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Stephen Rothwell]

Hi Hagen,

On Mon, 3 Feb 2020 22:03:10 +0100 Hagen Paul Pfeifer  wrote:
>
> It seems other people (kernel folks, Stephen) have the identical error as
> well: https://lkml.org/lkml/2020/1/30/1005
> Stephen: or is the bug fixed somewhere else? Do you have an workaround?

I don't have a workaround, I just backed out the binutils-dev upgrade
(and all the things that depended on it).  So I have binutils-dev
2.33.1-6 currently installed.

-- 
Cheers,
Stephen Rothwell


pgp0u8mEXCiZ_.pgp
Description: OpenPGP digital signature

Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Matthias Klose]

[CCing to binutils]

On 2/3/20 10:03 PM, Hagen Paul Pfeifer wrote:
> CCed: Stephen Rothwell
> 
> * Matthias Klose | 2020-02-03 21:10:14 [+0100]:
> 
> Hey Matthias
> 
>> please can you reassign that to the appropriate package? both libopcodes and
>> libbfd have non-public interfaces.  If you use those, please adopt to these.
> 
> I don't get it: `apt-file search /usr/include/bfd.h` results in
> binutils-dev: /usr/include/bfd.h
> 
> On an slightly older bullseye the shipped version of bfd.h building perf works
> like a charm.
> 
> I don't get it why the currently shipped version of bfd.h by
> binutils-dev/bullseye should be fine? bfd.h looks broken now because they
> break API compatibility by silently removing previously defined public
> functions. libbfd-dev is an meta-package and provided by binutils-dev. I don't
> get the correlation to the bug.

binutils doesn't have any comitment to a stable ABI/API for libopcodes and 
libbfd.

> It seems other people (kernel folks, Stephen) have the identical error as
> well: https://lkml.org/lkml/2020/1/30/1005
> Stephen: or is the bug fixed somewhere else? Do you have an workaround?a

I don't have a work-around. If you rely on binutils internals, you really should
adjust to binutils upstream.
> 
> Thank you Matthias for the quick response!
> 
> Hagen

Matthias

Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot

[Nico Alt]

I can confirm this bug. After doing an apt full-upgrade, I faced the
same issue as OP. However, I was not able to fix it by downgrading
packages, but instead used a similar approach to the way described in
the btrfs bug #950556 [1].

After chrooting into the system, I changed the following file:

$ diff /usr/share/initramfs-tools/hooks/cryptroot.backup
/usr/share/initramfs-tools/hooks/cryptroot
416c416
< find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' -type f | while
read so; do
---
> find -L "/lib" -maxdepth 1 -name 'libgcc_s.*' -type f | while read so; do

After this, I updated initramfs with "update-initramfs -u -k all".

Note: for this to work cleanly, you need to bind proc, dev etc. and you
need to open your encrypted volume with the same name as described in
your system's /etc/crypttab. The commands I used:

sudo cryptsetup open /dev/sda5 sda5_crypt
[...]
sudo mount --bind /dev /mnt/dev
[...]

Cheers

Nico


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950556

Bug#950586: REDEFINITION: dkms build fails with kernel 5.4.0-3-686-pae but NOT with 4.17.0-3-686-pae

[Andreas Beckmann]

On 03/02/2020 22.14, js wrote:
> I expected the dkms module would be built for 5.4 as it was for 4.17.

The nvidia kernel module build usually breaks with every new major
kernel release, e.g. 5.4 -> 5.5

> [I understand this is an older version of nvidia-kernel-dkms but did not

Please check the description of the package, it will tell you the
maximum kernel version where we successfully built the module for.
(Usually the current kernel version at the time the package was uploaded.)

> find a bug report regarding this and would normally not upgrade both
> kernel and nvidia at the same time.]

Then upgrade nvidia first. The driver should be backwards compatible.


Andreas

Bug#738548: systemd support

[Brian May]

Andreas Henriksson  writes:

> I'd like to ask if there are anything that requires attention before
> https://bugs.debian.org/738548 can move forward? Help is available if
> actionable problems are described.
>
> I'd like to remind you that policy now explicitly states that providing
> native systemd units is recommended and we have a GR stating that
> declarative solutions are preferred. I don't think we can get much
> further into a decision-has-been-made territory.
>
> Seeing that this bug was opened over half a decade ago with patch
> provided makes me quite sad about how broken the Debian development
> model is and how pointless it apparently is to try to contribute
> improvements.

I have no objection to this other then technical issues. Plus the lack
of time on my behalf.

I tried making this change, and found it appears to be incomplete,
lintian complains with the following errors:

E: amavisd-new: omitted-systemd-service-for-init.d-script amavis-mc
E: amavisd-new: omitted-systemd-service-for-init.d-script amavisd-snmp-subagent

Maybe we need some sort of disabled by default systemd file for these
services too?
-- 
Brian May 

Bug#944251: e1000e: Link not detected after resume

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Wed, Nov 06, 2019 at 06:23:34PM +0100, Dietz Proepper wrote:
> Package: linux-image-5.3.0-1-amd64
> Version: 5.3.7-1
> Severity: important
> Tags: upstream
> 
> Hi,
> 
> there might be a regression in the e1000e ethernet driver:
> 
> After upgrade from 5.2.13 (handbuilt) to the precompiled kernel from above,
> the ethernet interface does sometimes (3 out of 5 times I think) not detect
> the cable connected after a resume.
> 
> Reverting to 5.2.x resolves the problem.
> 
> I already opened a bug at kernel.org, 
> https://bugzilla.kernel.org/show_bug.cgi?id=205357,
> there are some additional infos.

According to the provided information on the upstream issue you were
not able to reproduce the issue anymore with 5.5. Can you confirm the
same is for the Debian packages based on 5.5~rc5-1~exp1 (currently in
experimental)?

Regards,
Salvatore

Bug#950587: rootskel: kernel argument parsing in S02module-params ignores quoting

[Ferenc Wágner]

Package: rootskel
Severity: normal

Dear Maintainer,

If I preseed multiple nameservers on the kernel command line, like for
example netcfg/get_nameservers="193.225.12.63 193.225.14.58", in the
installed system the following /etc/modprobe.d/local.conf appears:

--8<--
# Local module settings
# Created by the Debian installer

options 193.225.14 225.14.58"=193.225.14.58"
--8<--

Indeed, if I pass a="b c.d" on the kernel command line, the
misunderstanding is already present in the installer environment:

--8<--
~ # cat /var/lib/register-module/c.params
options:d"=c.d"
--8<--

The problematic code is S02module-params in rootskel. Proper and secure
quote handling is indeed pretty hard in shell programming, but security
isn't relevant in the Debian Installer context, so using shell eval
seems acceptable and probably provides the easiest solution.

Please consider fixing this some way.
-- 
Thanks,
Feri.

Bug#950585: binutils-dev: included log files introduce reproducibility issues

[Vagrant Cascadian]

Package: binutils-dev
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness buildpath hostname timestamps username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The log files included in /usr/share/doc/binutils/tests/ include many
variable things (timestamps, timings, PIDs, temporary filenames,
usernames, addresses) that vary between builds.

I'm not sure what the rationale for including these test logs in the
package is, but from a reproducible builds perspective, ideally these
would simply not be included at all.

When running the build with DEB_BUILD_OPTIONS=nocheck, the build logs
are excluded, and results in a reproducible build. Perhaps you could
create a build profile that doesn't include these logs, and use it in
builds in which you want the logs?

If the logs must be included in the packages, the attached patch
attempts to sanitize the log file by removing everything that varies
between builds; I'm not sure if this removes too much data to be useful,
but it should make binutils reproducible at least in bullseye
(unstable/experimental also varies build path in the reproducible builds
test infrastructure, which triggers other issues). This approach does
feel a bit prone to playing whack-a-mole, so long-term this may not be
viable.

Please consider removing or sanitizing the logs so that this part of the
essential build toolchain can itself be built reproducibly!


Thanks for maintaining binutils!


live well,
  vagrant
From ec5b5081300f275991c4b7dad7401d7ac882a6aa Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 3 Feb 2020 20:44:51 +
Subject: [PATCH] Sanitize build logs to ensure reproducible builds by
 stripping out embedded timestamps, timings, PIDs, temporary filenames,
 usernames, function addresses, etc.

---
 debian/rules | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 1acbe57..0b202e3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1445,7 +1445,7 @@ binary.%: stamps/install.% install
 
 ifeq ($(with_check),yes)
 	: # remove user and date from test-summary for reproducible builds
-	sed -i -e '/Test Run By/Id' test-summary-$*
+	sed -i -e '/Test run by/d' test-summary-$*
 	$(install_file) test-summary-$* \
 	  $(D_CROSS)/$(PF)/share/doc/$(P_CROSS)/test-summary
 	gzip -9nf $(D_CROSS)/$(PF)/share/doc/$(P_CROSS)/test-summary
@@ -1668,7 +1668,7 @@ endif
 ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
 ifeq ($(with_check),yes)
 	: # remove user and date from test-summary for reproducible builds
-	sed -i -e '/Test Run By/Id' $(pwd)/test-summary
+	sed -i -e '/Test run by/d' $(pwd)/test-summary
 	$(install_dir) $(d_nat)/$(PF)/share/doc/$(p_bin)
 	$(install_file) test-summary \
 	  $(d_nat)/$(PF)/share/doc/$(p_bin)/test-summary-$(DEB_HOST_ARCH)
@@ -1680,8 +1680,27 @@ ifeq ($(with_check),yes)
 	for i in $$(find builddir-single -name '*.sum'); do \
 	  b=$$(basename $$i .sum); \
 	  $(install_file) $$i $(d_dev)/$(PF)/share/doc/$(p_bin)/tests/$$b.sum; \
+	  sed -i -e '/Test run by/d' $(d_dev)/$(PF)/share/doc/$(p_bin)/tests/$$b.sum; \
 	  xz -9v $(d_dev)/$(PF)/share/doc/$(p_bin)/tests/$$b.sum; \
 	  $(install_file) $${i%.sum}.log $(d_dev)/$(PF)/share/doc/$(p_bin)/tests/$$b.log; \
+	  sed -i -e '/Test run by/d' \
+	-e '/time stamp.*:/d' \
+	-e 's,completed in.*seconds,completed,g' \
+	-e 's,runtest completed.*,runtest completed,g' \
+	-e 's,completed at.*,completed,g' \
+	-e 's,/tmp/cc...,/tmp/ccXX.,g' \
+	-e 's,tmpdir/compiler[0-9]*,tmpdir/compilerXX,g' \
+	-e 's,tmpdir/plt[0-9]*,tmpdir/pltXX,g' \
+	-e 's,tmpdir/nopie[0-9]*,tmpdir/nopieXX,g' \
+	-e 's,tmpdir/int128[0-9]*,tmpdir/int128XX,g' \
+	-e 's,tmpdir/gnu2_tls[0-9]*,tmpdir/gnu2_tlsXX,g' \
+	-e 's,tmpdir/gnu[0-9]*,tmpdir/gnuXX,g' \
+	-e 's,tmpdir/static[0-9]*,tmpdir/staticXX,g' \
+	-e 's,tmpdir/dl_avail_test[0-9]*,tmpdir/dl_avail_testXX,g' \
+	-e 's,tmpdir/ifunc[0-9]*,tmpdir/ifuncXX,g' \
+	-e 's,func@0.*,func@ADDRESS_REDACTED_FOR_REPRODUCIBILITY,g' \
+	-e "s,$(CURDIR),BUILD_DIR/,g" \
+	$(d_dev)/$(PF)/share/doc/$(p_bin)/tests/$$b.log; \
 	  xz -9v $(d_dev)/$(PF)/share/doc/$(p_bin)/tests/$$b.log; \
 	done
 endif
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#950584: whitespace break "/etc/vsftpd.conf"

[Brian Wengel]

Package: vsftpd

Version: 3.0.3-12


If a whitespace surfix a option in the "/etc/vsftpd.conf" file, the service
fail to start.

E.g "guest_enable=YES "

I guess it depends of the eyes if this is a bug or a feature-request. But I
just wasted more than an hour because of this, so at the moment I feel it's
a bug ;-)

Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Hagen Paul Pfeifer]

CCed: Stephen Rothwell

* Matthias Klose | 2020-02-03 21:10:14 [+0100]:

Hey Matthias

>please can you reassign that to the appropriate package? both libopcodes and
>libbfd have non-public interfaces.  If you use those, please adopt to these.

I don't get it: `apt-file search /usr/include/bfd.h` results in
binutils-dev: /usr/include/bfd.h

On an slightly older bullseye the shipped version of bfd.h building perf works
like a charm.

I don't get it why the currently shipped version of bfd.h by
binutils-dev/bullseye should be fine? bfd.h looks broken now because they
break API compatibility by silently removing previously defined public
functions. libbfd-dev is an meta-package and provided by binutils-dev. I don't
get the correlation to the bug.

It seems other people (kernel folks, Stephen) have the identical error as
well: https://lkml.org/lkml/2020/1/30/1005
Stephen: or is the bug fixed somewhere else? Do you have an workaround?a

Thank you Matthias for the quick response!

Hagen

Bug#950032: Use python3 in build script

[Daniel Moran]

The issue seems to stem from the fact the python3 package(s) do not
provide /usr/bin/python.

I've attached a patch which should fix builds which use either the
CMakeList.txt file, or the ./configure.py script.

This is only an initial change, as I haven't been able to try it out,
but should force the use of python3 rather than relying on
/usr/bin/python to point to the correct place.

Regards,
Dan
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 440eab076509..9ce9b51f2042 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -158,7 +158,7 @@ if( ENABLE_RUNTIME_SUBNORMAL )
DESTINATION ${CMAKE_INSTALL_DATADIR}/clc )
 endif()
 
-find_program( PYTHON python )
+find_program( PYTHON python3 )
 file( TO_CMAKE_PATH ${CMAKE_SOURCE_DIR}/generic/lib/gen_convert.py script_loc )
 add_custom_command(
OUTPUT convert.cl
diff --git a/configure.py b/configure.py
index dab5dc94dfab..cd2a48235436 100755
--- a/configure.py
+++ b/configure.py
@@ -151,7 +151,7 @@ b.build(prepare_builtins, "LLVM_TOOL_LINK",
 
 b.rule("PREPARE_BUILTINS", "%s -o $out $in" % prepare_builtins,
'PREPARE-BUILTINS $out')
-b.rule("PYTHON_GEN", "python < $in > $out", "PYTHON_GEN $out")
+b.rule("PYTHON_GEN", "python3 < $in > $out", "PYTHON_GEN $out")
 b.build('generic/lib/convert.cl', "PYTHON_GEN", ['generic/lib/gen_convert.py'])
 
 manifest_deps = set([sys.argv[0], os.path.join(srcdir, 'build', 
'metabuild.py'),

Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )

[Bernhard Übelacker]

Control: reassign -1 libc6 2.29-9
Control: affects -1 bash


Dear Maintainer,
reassigning to get hold of libc6 maintainer about the issue
of incompatible tunables indices between libc6 versions.

Therefore applications could crash when libc is from
previous package version, then a package update gets installed,
and then libpthread is from new version is loaded.

Kind regards,
Bernhard

Bug#950333: [apt-cacher-ng] disc full

[Eduard Bloch]

Hallo,
* Jean-Marc LACROIX [Fri, Jan 31 2020, 02:29:39PM]:

> Package: apt-cacher-ng
> Version: 3.2-2
> Severity: important
>
> Dear maintainers,
>
> Many thanks for the packaging of this application ().

Just for your information, your mail setup makes it hard to receive your
mails (forged domain flag and similar in the spamfilter).

> Two questions about this application.
>
> After reading  the documentation and many  blogs on Internet, it seems
> not  possible to set  maximum size  to  the parameter : "CacheDir:" in
> configuration file.

What you mean is not the maximum size of the parameter (the string
length) but the maximum size of the cache.

> As a result, of course, after some times, this directory can be full.

Normally, a directory cannot be full. A harddisk can be full.

> Of course it is possible to mount this directory to one dedicated disc
> mount point, but the issue is always the same, it depends of disc size
> (!).

Yes. You can counteract with filesystem quotas, since the daemon
normally runs under aa specific user id.

> My dream   is to  specify  one limit  (!)   in this  parameter,  with
> potential associated   policy (optional) to   manage automatically old
> files when disc is full for example.
>
> Q1: Is it possible ?

Generally speaking: not yet. It is one of the new options which would
become available with the next generation (yeah, -ng-ng :-) ). The plan
is to move the internal metadata handling completely into an embedded
database. That will allow for tracking of used space at runtime without
serious costs on OS/CPU/disk.

But it's not as easy as you probably imagine it. Detecting out-of-space
condition is one thing, resolving the problem is another. It would
require some kind of "on-the-fly cache invalidation" strategy which the
user could specify in the configuration. And it needs to be extra
carefull in order to not destroy the whole cache by mistake.

At the moment, you can partly do something similar (but offline, not
online) with "acngtool shrink ..." command.  Although for a better
trade-off, it requires additional information which has to be collected
at runtime, so for most precise cache invalidation, it needs the
"TrackFileUse=1" option in the acng configuration. And having this set
for some time, so the daemon can collect statistics and then acngtool
knows which files are lest recently used and which ones are just
garbage.

> Q2: Furthermore, it seems that when disc is full, then all clients
> can not download files when launching apt update/upgrade  with following
> error : "Failed to update apt cache", perhaps due to
> [HTTP error, code: 503] in /var/log/apt-cacher-ng/apt-cacher.log ?

Not sure what you mean. Asking whether it looks like this? Probably yes.
Or asking to confirm it? Sorry, you refer to a Stable version.  Stable
is not subject to change (much), I don't have enough time to run after
such issues in a frozen version.

Best regards,
Eduard.

Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Ben Hutchings]

On Mon, 2020-02-03 at 21:10 +0100, Matthias Klose wrote:
> On 2/1/20 10:53 AM, Hagen Paul Pfeifer wrote:
> > Package: binutils-dev
> > Version: 2.33.90.20200122-2
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > linux perf build fails with current version of binutils-dev:
> 
> please can you reassign that to the appropriate package? both libopcodes and
> libbfd have non-public interfaces.  If you use those, please adopt to these.

Note that for linux-perf binary packages we don't use libbfd since the
licences are incompatible.  So this could only be minor for src:linux
(and I won't do anything to fix it).

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.



signature.asc
Description: This is a digitally signed message part

Bug#950583: rustc: Float number min() and max() methods on mips[64]el behave different from other architectures

[Wolfgang Silbermayr]

Package: rustc
Version: 1.40.0+dfsg1-5
Severity: normal

Dear Maintainer,

When calling the f64 and f32 min() and max() methods on mips[64]el, with one of
the numbers being NAN, the returned value is also NAN. On all other
architectures we have, the non-NAN number gets returned.

The following test reproducibly yields an error on the mips* architectures
while succeeding on the others.

```rust
#[cfg(test)]
mod tests {
#[test]
fn min() {
assert_eq!(1f64.min(std::f64::NAN), 1f64);
}

#[test]
fn max() {
assert_eq!(1f64.max(std::f64::NAN), 1f64);
}
}
```



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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rustc depends on:
ii  binutils  2.33.90.20200122-2
ii  gcc   4:9.2.1-3.1
ii  libc6 2.29-9
ii  libc6-dev [libc-dev]  2.29-9
ii  libgcc-s1 [libgcc1]   10-20200117-2
ii  libgcc1   1:9.2.1-25
ii  libllvm9  1:9.0.1-8
ii  libstd-rust-dev   1.40.0+dfsg1-5
ii  libstdc++69.2.1-25

Versions of packages rustc recommends:
ii  cargo 0.40.0-3
ii  rust-gdb  1.40.0+dfsg1-5

Versions of packages rustc suggests:
pn  lld-9 
pn  rust-doc  
pn  rust-src  

-- no debconf information

Bug#950582: i3pystatus: dependency missing

[Christian Schirge]

Package: i3pystatus
Version: 3.35+git20190107.1c972b8-1
Severity: minor

Dear Maintainer,
I installed the package and wanted to execute "i3pystatus-setting-util"
but it didn't run as it couldn't find the module "keyring":

Traceback (most recent call last):
  File "/usr/bin/i3pystatus-setting-util", line 11, in 
load_entry_point('i3pystatus==3.35', 'console_scripts', 
'i3pystatus-setting-util')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2793, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2411, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2417, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/i3pystatus/tools/setting_util.py", line 
11, in 
import keyring
ModuleNotFoundError: No module named 'keyring'

You need to install python3-keyring to get it running.

Best Regards


-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages i3pystatus depends on:
ii  python3  3.7.3-1

Versions of packages i3pystatus recommends:
ii  python3-colour 0.1.5-1
ii  python3-netifaces  0.10.4-1+b1

i3pystatus suggests no packages.

-- no debconf information

Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Matthias Klose]

On 2/1/20 10:53 AM, Hagen Paul Pfeifer wrote:
> Package: binutils-dev
> Version: 2.33.90.20200122-2
> Severity: important
> 
> Dear Maintainer,
> 
> linux perf build fails with current version of binutils-dev:

please can you reassign that to the appropriate package? both libopcodes and
libbfd have non-public interfaces.  If you use those, please adopt to these.

Bug#948786: buster-pu: package apt-cacher-ng/3.2.1-1 pre-approval

[Eduard Bloch]

Hallo,
* Adam D. Barratt [Tue, Jan 28 2020, 10:28:08PM]:

> > I can, of course, convert all that into debian/patches/XXX but
> > honestly, that would really feel like greenwashing.
> >
> > The changes reported here can be reviewed at
> > https://salsa.debian.org/blade/apt-cacher-ng/commits/temp/debian-merge ,
> > starting with the commit from 2019-12-20.
>
> Those look OK as individual commits, thanks. For completeness, could we
> please have a finalised source debdiff of the built source package,
> compared to current stable?

Of course, attached.

Although, there are a couple of changes which I added on top:
a) removing -Wl,threads from considered linker options. That's a non-functional 
change, supposed to counteract FTBFS on mipsel/mips64el which I had experienced 
recently (there is a similar workaround in Testing, which detects mipsel 
explicitly, but this change simply removed -Wl,threads completely for all 
architectures which is the safer option, IMHO)
b) upstreaming the fix of #928957 (this was approved last year for Stable 
already, the code just wanders from debian-patch into upstream change)

BTW, there is one remaining change in the Debian diff on the systemd file which 
I will keep as is. It existed already in Stable. Not critical and not that 
important, and might be upstreamed in Sid, sooner or later.

Best regards,
Eduard.
diff -Nru apt-cacher-ng-3.2/CMakeLists.txt apt-cacher-ng-3.2.1/CMakeLists.txt
--- apt-cacher-ng-3.2/CMakeLists.txt	2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/CMakeLists.txt	2020-02-03 19:54:57.0 +0100
@@ -58,6 +58,8 @@
 if(NOT DEFINED(RUNDIR))
 	set(RUNDIR "/run")
 endif()
+set(SOCKET_PATH "${RUNDIR}/${PACKAGE}/socket")
+

 # carefully splicing of command line arguments, even from lists
 macro(_append varname)
@@ -106,7 +108,7 @@
 _append(ACNG_CXXFLAGS -fvisibility-inlines-hidden)
 endif()

-foreach(linkarg -Wl,--as-needed -Wl,-O1 -Wl,--discard-all -Wl,--no-undefined -Wl,--build-id=sha1 -Wl,-fuse-ld=gold -Wl,--threads)
+foreach(linkarg -Wl,--as-needed -Wl,-O1 -Wl,--discard-all -Wl,--no-undefined -Wl,--build-id=sha1 -Wl,-fuse-ld=gold)
 	STRING(REGEX REPLACE "=|-|," "" optname "${linkarg}")
 	set(CMAKE_REQUIRED_FLAGS "${linkarg}")
 	CHECK_CXX_COMPILER_FLAG("" "LD_${optname}")
diff -Nru apt-cacher-ng-3.2/ChangeLog apt-cacher-ng-3.2.1/ChangeLog
--- apt-cacher-ng-3.2/ChangeLog	2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/ChangeLog	2020-02-03 19:54:57.0 +0100
@@ -1,3 +1,38 @@
+apt-cacher-ng (3.2.1) SHAUN-OF-THE-LIVING; urgency=medium
+
+  * POTENTIAL SECURITY ISSUE (CVE-2020-5202):
+- in certain situations, the maint job run by acngtool could leak the
+  administrator credentials from apt-cacher-ng configuration. This is only
+  likely if the attacker is able to impersonate the daemon with an own
+  server listening on the same port.
+- The mitigation path for this is:
+  - SocketPath option is configured by default
+  - By default, acngtool only attempts to run the maint job through the
+Unix Domain Socket. If SocketPath is not set but admin credentials are
+configured, the operation is denied.
+  - For non-standard cases where acngtool is used to run special arbitrary
+commands (ACNG_REQ variable) and the operation through SocketPath is not
+possible (i.e. missing permissions or the tool is run on a different
+host), the operation through TCP can be enforced with ACNG_INSECURE
+environment variable
+
+  [ REALITY SYNC ]
+  * increased size of the decompression line buffer for config file reading
+(Debian bug #942634)
+  * Support .zst compressed packages (reference:
+https://www.archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ )
+
+  [ Debian Stable Bugfix ]
+  * Fix of Debian bug #928957: overoptimistic guessing of the SHA256SUMS file location
+Incorrect assumption of an existing SHA256SUMS file for Debian
+repositories makes the expiration task fail without a proper way for the
+end user to recover from it. Now ignore a download error in this case
+(similar handling as for other guesses), assuming that permanent 404ing
+for other reasons than removal of remote content can be considered
+unlikely.
+
+ -- Eduard Bloch   Wed, 22 Jan 2020 20:53:50 +0100
+
 apt-cacher-ng (3.2) MY-NAME-IS-ANYBODY; urgency=medium

   * Maintenance release
diff -Nru apt-cacher-ng-3.2/VERSION apt-cacher-ng-3.2.1/VERSION
--- apt-cacher-ng-3.2/VERSION	2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/VERSION	2020-02-03 19:54:57.0 +0100
@@ -1 +1 @@
-3.2
+3.2.1
diff -Nru apt-cacher-ng-3.2/conf/acng.conf.in apt-cacher-ng-3.2.1/conf/acng.conf.in
--- apt-cacher-ng-3.2/conf/acng.conf.in	2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/conf/acng.conf.in	2020-02-03 19:54:57.0 +0100
@@ -81,11 +81,12 @@
 ReportPage: acng-report.html

 # Socket file for accessing through local 

Bug#950301: Fixed upstream in 0.10.0

[Fiona Klute]

This issue has been fixed in upstream version 0.10.0 (out just now).

This is caused by recent GnuTLS versions (since 3.6.11 AFAIK) listing
the peer's certificate type in the session description so they aren't
identical on anonymous client and authenticated server, so backporting
shouldn't be necessary.

Bug#950581: python-django: CVE-2020-7471: Potential SQL injection via StringAgg(delimiter)

[Salvatore Bonaccorso]

Source: python-django
Version: 2:2.2.9-2
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1:1.11.27-1~deb10u1

Hi,

The following vulnerability was published for python-django.

CVE-2020-7471[0]:
| Django 1.11 before 1.11.28, 2.2 before 2.2.10, and 3.0 before 3.0.3
| allows SQL Injection if untrusted data is used as a StringAgg
| delimiter (e.g., in Django applications that offer downloads of data
| as a series of rows with a user-specified column delimiter). By
| passing a suitably crafted delimiter to a
| contrib.postgres.aggregates.StringAgg instance, it was possible to
| break escaping and inject malicious SQL.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-7471
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7471
[1] https://www.djangoproject.com/weblog/2020/feb/03/security-releases/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#944040: haveged requires debhelper >= 12.5

[Daniel Baumann]

Hi Nicolas,

On 2/3/20 7:28 PM, Nicolas Braud-Santoni wrote:
> I had missed the dh_makeshlibs call when looking for something that would
> require a newer dh.  >_>'

good catch! i didn't spotted that when looking at it..

> I'm commiting a fix to the packaging repo r.n., so the next upload should
> have it available.

great, thanks.

> I can also take care of uploading to backports once this lands in bullseye,
> if you want me to.

thanks, I'm sure others would be glad to be able to use it. For me
personally, however, it doesn't matter (we're using our own backports
due different opinions about backporting policy).

Regards,
Daniel

Bug#950576: Just do not want to fix? Normal among more thant 200 other that stay unfixed?

[Eric Valette]

severity 950576 critical

Please give rationale to lower the priority. It breaks my system while 
being a well know and widely used Ethernet card from Intel... Otherwyse 
i will send this to control...



severity 950576 critical


00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network 
Connection (rev 06)


journalctl -g network

...

févr. 03 18:52:30 tri-yann4 systemd[1]: 
NetworkManager-dispatcher.service: Succeeded.
févr. 03 18:52:32 tri-yann4 NetworkManager[928]:  
[1580752352.2604] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:52:32 tri-yann4 NetworkManager[928]:  
[1580752352.7721] manager: NetworkManager state is now CONNECTING
févr. 03 18:52:34 tri-yann4 NetworkManager[928]:  
[1580752354.3132] agent-manager: 
agent[67d85ce270ae1291,:1.88/org.kde.plasma.networkmanagement/1000]: 
agent register>
févr. 03 18:52:38 tri-yann4 NetworkManager[928]:  
[1580752358.9086] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:52:39 tri-yann4 NetworkManager[928]:  
[1580752359.4914] manager: NetworkManager state is now CONNECTING
févr. 03 18:52:40 tri-yann4 systemd[1224]: Closed GnuPG network 
certificate management daemon.
févr. 03 18:52:45 tri-yann4 NetworkManager[928]:  
[1580752365.6225] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:52:46 tri-yann4 NetworkManager[928]:  
[1580752366.2755] manager: NetworkManager state is now CONNECTING
févr. 03 18:52:52 tri-yann4 NetworkManager[928]:  
[1580752372.4068] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:52:53 tri-yann4 NetworkManager[928]:  
[1580752373.0587] manager: NetworkManager state is now CONNECTING
févr. 03 18:52:59 tri-yann4 NetworkManager[928]:  
[1580752379.1901] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:52:59 tri-yann4 NetworkManager[928]:  
[1580752379.8428] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:05 tri-yann4 NetworkManager[928]:  
[1580752385.9728] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:06 tri-yann4 NetworkManager[928]:  
[1580752386.6271] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:12 tri-yann4 NetworkManager[928]:  
[1580752392.7579] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:13 tri-yann4 NetworkManager[928]:  
[1580752393.4117] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:19 tri-yann4 NetworkManager[928]:  
[1580752399.5425] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:20 tri-yann4 NetworkManager[928]:  
[1580752400.1314] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:26 tri-yann4 NetworkManager[928]:  
[1580752406.2634] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:26 tri-yann4 NetworkManager[928]:  
[1580752406.9158] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:33 tri-yann4 NetworkManager[928]:  
[1580752413.0476] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:33 tri-yann4 NetworkManager[928]:  
[1580752413.6351] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:39 tri-yann4 NetworkManager[928]:  
[1580752419.7664] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:40 tri-yann4 NetworkManager[928]:  
[1580752420.4194] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:46 tri-yann4 NetworkManager[928]:  
[1580752426.5499] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:52 tri-yann4 NetworkManager[928]:  
[1580752432.2589] manager: NetworkManager state is now CONNECTING
févr. 03 18:53:58 tri-yann4 NetworkManager[928]:  
[1580752438.3905] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:53:59 tri-yann4 NetworkManager[928]:  
[1580752439.0429] manager: NetworkManager state is now CONNECTING
févr. 03 18:54:05 tri-yann4 NetworkManager[928]:  
[1580752445.1759] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:54:05 tri-yann4 NetworkManager[928]:  
[1580752445.7627] manager: NetworkManager state is now CONNECTING
févr. 03 18:54:11 tri-yann4 NetworkManager[928]:  
[1580752451.8978] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:54:12 tri-yann4 NetworkManager[928]:  
[1580752452.6164] manager: NetworkManager state is now CONNECTING
févr. 03 18:54:18 tri-yann4 NetworkManager[928]:  
[1580752458.7459] manager: NetworkManager state is now DISCONNECTED
févr. 03 18:54:23 tri-yann4 NetworkManager[928]:  
[1580752463.4248] manager: NetworkManager state is now CONNECTING
févr. 03 18:54:32 tri-yann4 dbus-daemon[811]: [system] Activating via 
systemd: service name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'>
févr. 03 18:54:32 tri-yann4 systemd[1]: Starting Network Manager Script 
Dispatcher Service...
févr. 03 18:54:32 tri-yann4 systemd[1]: Started Network Manager Script 
Dispatcher Service.




journalctl -u NetworkManager.service




févr. 03 18:54:32 tri-yann4 NetworkManager[928]:  
[1580752472.1727] manager: NetworkManager state is 

Bug#950579: libgcc1: multiple packages FTBFS on s390x: /usr/bin/ld: cannot find -lgcc_s

[Aurelien Jarno]

On 2020-02-03 20:21, Matthias Klose wrote:
> On 2/3/20 8:14 PM, Simon McVittie wrote:
> >> Sanity check compile stderr:
> >> /usr/bin/ld: cannot find -lgcc_s
> >> collect2: error: ld returned 1 exit status
> 
> this is fixed in unstable. please retry the package build.
> 

That won't work. For that we have to first regenerate the chroots on
s390x. We agreed to do that after gcc-9 9.2.1-27 is built. As it FTBFS,
we need to wait for 9.2.1-28 to build. We also need to wait for a
dinstall cycle.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#950580: spids out way to many log entries on console

[Martin Zobel-Helas]

Package: cura
Version: 4.4.1-1
Severity: minor

Hi,

when starting cura from command line prompt, i see everything from ERROR
to DEBUG spid out by cura. Please reduce the amount of log entries
produced, maybe by only showing WARNING and ERROR.

Opening a single STL, where the corresponding SCAD code looks like this
one-liner

> cylinder (h = 4.5, d=30, center = true, $fn=100);

gave me approx 500 lines of logs.

Best regards,
Martin


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cura depends on:
ii  cura-engine 1:4.4.1-1
ii  fdm-materials   4.4.1-1
ii  fonts-open-sans 1.11-1
ii  python3 3.7.5-3
ii  python3-pyqt5   5.14.1+dfsg-2
ii  python3-pyqt5.qtopengl  5.14.1+dfsg-2
ii  python3-requests2.22.0-2
ii  python3-savitar 4.4.1-2
ii  python3-serial  3.4-5
ii  python3-shapely 1.7.0-1
ii  python3-uranium 4.4.1-1
ii  qml-module-qt-labs-folderlistmodel  5.12.5-5
ii  qml-module-qt-labs-settings 5.12.5-5
ii  qml-module-qtqml-models25.12.5-5
ii  qml-module-qtquick-controls 5.12.5-1+b1
ii  qml-module-qtquick-controls25.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs  5.12.5-1+b1
ii  uranium-plugins 4.4.1-1

Versions of packages cura recommends:
ii  python3-zeroconf  0.23.0-1

cura suggests no packages.

-- debconf-show failed

-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


signature.asc
Description: PGP signature

Bug#950579: libgcc1: multiple packages FTBFS on s390x: /usr/bin/ld: cannot find -lgcc_s

[Matthias Klose]

On 2/3/20 8:14 PM, Simon McVittie wrote:
>> Sanity check compile stderr:
>> /usr/bin/ld: cannot find -lgcc_s
>> collect2: error: ld returned 1 exit status

this is fixed in unstable. please retry the package build.

Bug#949187: transition: python3.8

[Matthias Klose]

On 2/3/20 8:22 PM, Simon McVittie wrote:
> On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote:
>> I think this is now in shape to be started.
> 
> Please can this wait until the remaining bits of the libffi7 transition
> and the restructuring of the libgcc_s packaging have settled down?
> 
> I'm still trying to sort out the missing Breaks around
> gobject-introspection, as highlighted by autopkgtest failures: this has
> been delayed by needing coordinated action between multiple packages,
> some of them quite big (glib2.0), and by Paul and I being at FOSDEM.
> This is entangled with python3.8 via pygobject (which will fail tests
> with python3.8 as default - an upload is pending to fix that).

fine. I'm happy to see that fixed.

> Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s
> (I've just opened the bug for that, so no bug number known yet), which is
> going to limit the ability to get things into testing.

please retry your package builds. it's fixed in unstable.

Bug#947526: gimp-help: build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Control: tags -1 + pending

This was already fixed in the VCS, just waiting for someone to upload it:

https://salsa.debian.org/gnome-team/gimp-help/commit/b54539899284d510e0d863d9552679ba16552784

Regards,
Andreas Henriksson

Bug#949187: transition: python3.8

[Simon McVittie]

On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote:
> I think this is now in shape to be started.

Please can this wait until the remaining bits of the libffi7 transition
and the restructuring of the libgcc_s packaging have settled down?

I'm still trying to sort out the missing Breaks around
gobject-introspection, as highlighted by autopkgtest failures: this has
been delayed by needing coordinated action between multiple packages,
some of them quite big (glib2.0), and by Paul and I being at FOSDEM.
This is entangled with python3.8 via pygobject (which will fail tests
with python3.8 as default - an upload is pending to fix that).

Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s
(I've just opened the bug for that, so no bug number known yet), which is
going to limit the ability to get things into testing.

Thanks,
smcv

Bug#950579: libgcc1: multiple packages FTBFS on s390x: /usr/bin/ld: cannot find -lgcc_s

[Simon McVittie]

Package: libgcc1
Version: 1:10-20200202-1
Severity: serious
Justification: FTBFS
Tags: ftbfs
Control: affects -1 src:glib2.0 src:xterm src:hdrmerge src:esorex

https://buildd.debian.org/status/fetch.php?pkg=glib2.0=s390x=2.62.4-2=1580755175=log

> Package versions:
[with linebreaks added for legibility, quoting only the most
libgcc-adjacent packages]
> gcc_4:9.2.1-3.1
> gcc-10-base_10-20200202-1
> gcc-9_9.2.1-25
> gcc-9-base_9.2.1-25
> libgcc-9-dev_9.2.1-25
> libgcc-s1_10-20200202-1
> libgcc1_1:10-20200202-1
...
> Sanity check compiler command line: cc
> /<>/debian/build/deb/meson-private/sanitycheckc.c
> -o /<>/debian/build/deb/meson-private/sanitycheckc.exe
> -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pipe
> -D_FILE_OFFSET_BITS=64 -Wl,-z,relro -Wl,-z,now -Wl,-z,defs
> -Wl,--no-as-needed -Wl,-O1
> Sanity check compile stdout:
> 
> -
> Sanity check compile stderr:
> /usr/bin/ld: cannot find -lgcc_s
> collect2: error: ld returned 1 exit status
> 
> -
> 
> meson.build:1:0: ERROR: Compiler cc can not compile programs.

Presumably the dependencies and Breaks should be such that it isn't
possible to get into a situation where libgcc_s can't be linked.

Recent builds of xterm, hdrmerge and esorex show similar symptoms.

smcv

Bug#947530: gnome-system-tools: build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Hi,

On Sat, Feb 01, 2020 at 03:25:11PM +0200, Andriy Grytsenko wrote:
> Hello Andreas!
> 
> Thank you very much for the patch. It appears you've done all the
> work and it worked like a charm. All porting guide steps are handled,
> I've rechecked that. Thank you very much.

FWIW I later realized that changing the use of gnome-help to xdg-open
(and thus the Recommends: xdg-utils) is likely not needed.
The only change necessary is changing the URI from ghelp:// to help://
as gnome-help command is still shipped in yelp package and should
work just fine.

Regards,
Andreas Henriksson

Bug#950575: kamailio manual install fails die modules are not yet in path?¡

[PICCORO McKAY Lenz]

i tested in another vm instance too, AWS copied from the previous one,
but clean before install kamailio: here are the requested info in
clean environment:

El lun., 3 de feb. de 2020 a la(s) 14:39, Michael Biebl
(bi...@debian.org) escribió:
> systemctl cat kamailio.service
# /lib/systemd/system/kamailio.service
[Install]
WantedBy=multi-user.target

[Unit]
Description=Kamailio (OpenSER) - the Open Source SIP Server
Documentation=man:kamailio(8)
Wants=network-online.target
After=network-online.target

[Service]
Type=forking
User=kamailio
Group=kamailio
Environment='CFGFILE=/etc/kamailio/kamailio.cfg'
Environment='SHM_MEMORY=112'
Environment='PKG_MEMORY=18'
EnvironmentFile=-/etc/default/kamailio
EnvironmentFile=-/etc/default/kamailio.d/*
# PIDFile requires a full absolute path
PIDFile=/run/kamailio/kamailio.pid
# ExecStart requires a full absolute path
ExecStart=/usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f $CFGFILE
-m $SHM_MEMORY -M $PKG_MEMORY
Restart=on-failure
# /run/kamailio in tmpfs
RuntimeDirectory=kamailio
RuntimeDirectoryMode=0750


> systemctl status kamailio.service

● kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
   Loaded: loaded (/lib/systemd/system/kamailio.service; enabled)
   Active: active (running) since Mon 2020-02-03 18:59:08 UTC; 10min ago
 Docs: man:kamailio(8)
  Process: 21724 ExecStart=/usr/sbin/kamailio -P
/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY
(code=exited, status=0/SUCCESS)
 Main PID: 21726 (kamailio)
   CGroup: /system.slice/kamailio.service
   ├─21726 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21727 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21728 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21729 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21730 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21731 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21732 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21733 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21734 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21735 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21736 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21737 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21738 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21739 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21740 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21741 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21742 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21743 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21744 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21745 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21746 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21747 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21748 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21749 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21750 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21751 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21752 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21753 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21754 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21755 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   └─21756 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12

Bug#944478: fixed in debhelper 12.8

[Niels Thykier]

Michael Biebl:
> Am 01.02.20 um 20:43 schrieb Michael Biebl:
>> What's your thought here? Should we transition to the name
>> debian/foo.tmpfiles in compat 13? It would probably be good to keep
>> support for debian/foo.tmpfile in compat 13 but logging a warning and
>> making the existentence of a debian/foo.tmpfile a hard error in compat 14?
>>
>> Or do you think the name is purely cosmetical and changing it now is
>> just creating busy work?
> 
> If we decide to change the name, now would probably be a good time
> before compat 13 is officially released. I assume it's still ok to
> change the behaviour of compat 13 or is this already too late?
> 
> Regards,
> Michael
> 

I have added the new name (in git@master) for dh_installtmpfiles.  The
old name is still accepted with a warning as a fallback.

To avoid "funny issues", dh_installtmpfiles requires "new name" xor "old
name".

~Niels

Bug#950575: kamailio manual install fails die modules are not yet in path?¡

[PICCORO McKAY Lenz]

> Please run
> reportbug --template systemd
> reportbug --template kamailio
already done, i already provide my 5c so ..for next pieces of info
requested, i must to reinstall again all the image, as i described, if
i install alone kamailio starts, but if i installed with some others
modules does not start intil rest of packages are installed, this it's
my las mail due i'm also busy and i provide my 5c

> systemctl cat kamailio.service

# /lib/systemd/system/kamailio.service
[Install]
WantedBy=multi-user.target

[Unit]
Description=Kamailio (OpenSER) - the Open Source SIP Server
Documentation=man:kamailio(8)
Wants=network-online.target
After=network-online.target

[Service]
Type=forking
User=kamailio
Group=kamailio
Environment='CFGFILE=/etc/kamailio/kamailio.cfg'
Environment='SHM_MEMORY=64'
Environment='PKG_MEMORY=8'
EnvironmentFile=-/etc/default/kamailio
EnvironmentFile=-/etc/default/kamailio.d/*
# PIDFile requires a full absolute path
PIDFile=/run/kamailio/kamailio.pid
# ExecStart requires a full absolute path
ExecStart=/usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f $CFGFILE
-m $SHM_MEMORY -M $PKG_MEMORY
Restart=on-failure
# /run/kamailio in tmpfs
RuntimeDirectory=kamailio
RuntimeDirectoryMode=0770

> systemctl status kamailio.service

● kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server
   Loaded: loaded (/lib/systemd/system/kamailio.service; enabled)
   Active: active (running) since Mon 2020-02-03 18:52:06 UTC; 2s ago
 Docs: man:kamailio(8)
  Process: 21724 ExecStart=/usr/sbin/kamailio -P
/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY
(code=exited, status=0/SUCCESS)
 Main PID: 21726 (kamailio)
   CGroup: /system.slice/kamailio.service
   ├─21726 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21727 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21728 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21729 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21730 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21731 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21732 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21733 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21734 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21735 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21736 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21737 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21738 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21739 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21740 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21741 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21742 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21743 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21744 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21745 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21746 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21747 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21748 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21749 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21750 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21751 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21752 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21753 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21754 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f
/etc/kamailio/kamailio.cfg -m 112 -M 12
   ├─21755 /usr/sbin/kamailio -P /run/kamailio/kamailio.pid 

Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 (patch attached)

[Pete Batard]

Package: src:linux
Version: 4.19.67-2
Severity: important
Tags: patch


Dear Maintainers,

While it is currently possible to boot and install Debian 10.x on the 
Raspberry Pi 4 using the official vanilla ARM64 ISO images (through the 
use of the latest EDK2 RPi4 firmware such as the one provided at [1]), 
one of the major drawbacks that exists is that, because the EDK2 
firmware currently only supports Linux boot in ACPI mode and also 
because the native Debian kernel does not include the bcmgenet module at 
all (module is currently disabled altogether), it is not possible to 
perform a networked installation of Debian on the Raspberry Pi 4.


Due to the popularity of the platform, we therefore suggest that 
bcmgenet should be enabled for the next Debian ARM64 10.x release as a 
matter of priority, after the the attached patch has been applied to the 
default kernel as some modifications are required for the network 
interface to work in ACPI mode in coordination with the EDK2 firmware.


With bcmgenet is currently being disabled as a module, and with the 
effort we made to ensure that the modifications applied have the least 
impact possible on existing code (the existing Device Tree code paths 
are left virtually untouched), we assert that the inclusion of this 
patch should be low risk and therefore very desirable to have for the 
potentially large number of RPi4 users, who should then be able to 
perform netinst installation of Debian 10.x on their platform using the 
vanilla ARM64 images.


Thanks and regards,

/Pete

[1] https://github.com/pftf/RPi4

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.87 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From d2fecdc2828dc0256df7c10e02fc6e7aaf99ce9a Mon Sep 17 00:00:00 2001
From: Jeremy Linton 
Date: Mon, 3 Feb 2020 17:39:14 +
Subject: [PATCH] net: bcmgenet: add ACPI bindings

This patch is needed to support the Raspberry Pi 4 network interface on
native Debian 4.19 kernels in ACPI mode. With this, network installation
of Debian 10.x, from vanilla ARM64 ISO images, should become possible
when using the official EDK2 UEFI firmware for the Raspberry Pi 4, which
currently requires the use of ACPI when booting Linux.

The changes covered by this patch can be summarized as follows:
* Since the 4.19 Genet driver private data structures are lacking this
  attribute compared to the 5.x version, and this is the least intrusive
  way of compensating for that, the max DMA burst length must be allowed
  to be overridden, when it is specified as an ACPI DSD parameter (which
  the UEFI firmware will provide accordingly).
* The MAC address must be allowed to be set from the hardware's UMAC
  registers (which the UEFI firmware will program accordingly).
  Note that we grouped the MAC initialization further down the code for
  readability and added random allocation on invalid MAC, rather than
  report an error, as this is what the current 5.x driver does.
* The relevant ACPI initialization structures must exist in the driver.

We also take this opportunity to add an entry for brcm,bcm2711-genet-v5
in the Device Tree list, which is how the Raspberry Pi Foundation
declares the network interface (though using it as such in a 4.19 kernel
will require the provision of the "brcm,max-dma-burst-size" attribute).

Signed-off-by: Pete Batard 
---
 .../net/ethernet/broadcom/genet/bcmgenet.c| 74 ++-
 drivers/net/ethernet/broadcom/genet/bcmmii.c  | 33 -
 drivers/net/phy/mdio-bcm-unimac.c | 26 ++-
 3 files changed, 111 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 338d22380434..2b4b2906a9b9 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -10,6 +10,7 @@
 
 #define pr_fmt(fmt)"bcmgenet: " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -2553,6 +2554,7 @@ static int bcmgenet_init_dma(struct bcmgenet_priv *priv)
int ret;
unsigned int i;
struct enet_cb *cb;
+   u32 dma_max_burst_length;
 
netif_dbg(priv, hw, priv->dev, "%s\n", __func__);
 
@@ -2584,8 +2586,13 @@ static int bcmgenet_init_dma(struct bcmgenet_priv *priv)
cb->bd_addr = priv->tx_bds + i * DMA_DESC_SIZE;
}
 
+   /* Set the max DMA burst length if specified. Else, use default */
+   if (!priv->pdev || device_property_read_u32(>pdev->dev,
+   "brcm,max-dma-burst-size", _max_burst_length) != 0)
+   dma_max_burst_length = DMA_MAX_BURST_LENGTH;
+
/* Init 

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Felipe Sateler]

On Sun, Feb 2, 2020, 17:04 Zbigniew Jędrzejewski-Szmek 
wrote:

> On Thu, Jan 30, 2020 at 11:51:48PM -0300, Felipe Sateler wrote:
> > On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl  wrote:
> >
> > > Hi Felipe
> > >
> > > Am 30.01.20 um 22:30 schrieb Felipe Sateler:
> > > >
> > > >
> > > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl  > > > > wrote:
> > > >
> > > > Am 28.01.20 um 17:27 schrieb Ansgar:
> > > > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> > > > >> Am 28.01.20 um 14:59 schrieb Ansgar:
> > > > >>> I tried linking systemd-{sysusers,tmpfiles} statically
> against
> > > > >>> systemd's private library earlier this month.  It increases
> the
> > > > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2
> MB of
> > > > >>> systemd that is just one percent).
> > > > >>
> > > > >> Is that 100K per binary?
> > > > >
> > > > > I checked my notes at it was 100 kB per binary: they are 212 kB
> > > larger
> > > > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested
> with
> > > > > systemd 243-8.
> > > > >
> > > > > It might be possible to make it a bit smaller if one was to
> somehow
> > > > > link libsystemd0 for functions available there
> (libsystemd-shared
> > > > > currently duplicates those).
> > > >
> > > >
> > > > That is not possible. There is global state that is not to be shared.
> > > > See
> https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
> > >
> > > What's your thought on how to solve this libsystemd-shared issue should
> > > we consider splitting out systemd-{sysusers,tmpfiles}
> > >
> > > - link statically (and carry a downstream patch for eternity)
> > > - move libsystemd-shared to systemd-utils and risk the breakage that
> can
> > > result from a partial/aborted upgrade
> > > - copy, instead of move, the binaries + libsystemd-shared and make the
> > > resulting systemd-utils package Conflict with systemd (instead of
> having
> > > systemd depend on systemd-utils)
> > > - something else?
> > >
> >
> > I tried linking statically the "can run without systemd-pid1 tools" with
> > the attached patch.
> >
> > Disk usage appears to increase by about 400 kb:
> > % dpkg --info systemd_244.1-1_amd64.deb|grep Installed
> >
> >  Installed-Size: 13908
> > % dpkg --info ../systemd_244-3_amd64.deb|grep Installed
> >  Installed-Size: 14319
> >
> > Maybe upstream can be persuaded to merge something like this?
> >
> > --
> >
> > Saludos,
> > Felipe Sateler
>
> > diff --git a/meson.build b/meson.build
> > index b8dff8cd94..39cef6b301 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1493,6 +1493,29 @@ make_autosuspend_rules_py =
> find_program('tools/make-autosuspend-rules.py')
> >
> >  
> >
> > +
> > +libutil = static_library(
> > +'util',
> > +[
> > +'src/shared/acl-util.c',
> > +'src/shared/enable-mempool.c',
> > +'src/shared/id128-print.c',
> > +'src/shared/pager.c',
> > +'src/shared/path-lookup.c',
> > +'src/shared/pretty-print.c',
> > +'src/shared/spawn-ask-password-agent.c',
> > +'src/shared/spawn-polkit-agent.c',
> > +'src/shared/specifier.c',
> > +'src/shared/sysctl-util.c',
> > +'src/shared/sysctl-util.h',
> > +'src/shared/tmpfile-util-label.c',
> > +'src/shared/uid-range.c',
> > +'src/shared/verbs.c',
> > +] + id128_sources,
> > +link_with: [libbasic, libsystemd_static],
> > +include_directories: includes
> > +)
>
> Is creating a separate static library actually necessary?  What would
> the results be if those binaries were linked to the static version of
> libshared that we already provide support for? I hope the compiler
> would be able to drop any unused objects and achieve the same size,
> without having to maintain yet another list of files.
>

I'd have to recheck, but that was my first idea and didn't pan out (at
least with the flags we use for the debian package).


> >  # binaries that have --help and are intended for use by humans,
> >  # usually, but not always, installed in /bin.
> >  public_programs = []
> > @@ -1537,6 +1560,7 @@ test_dlopen = executable(
> >  include_directories : includes,
> >  link_with : [libbasic],
> >  dependencies : [libdl],
> > +b_lto: false,
> >  build_by_default : want_tests != 'false')
> >
> >  foreach tuple : [['myhostname', 'ENABLE_NSS_MYHOSTNAME'],
> > @@ -2407,7 +2431,7 @@ install_data('src/sleep/sleep.conf',
> >  exe = executable('systemd-sysctl',
> >   'src/sysctl/sysctl.c',
> >   include_directories : includes,
> > - link_with : [libshared],
> > + link_with : [libutil],
>
> 

Bug#950577: Missing option in man (utf8_filesystem)

[Brian Wengel]

Package: vsftpd

Version: 3.0.3-12


The option "utf8_filesystem" in "/etc/vsftpd.conf" is not listed in the
manual.

I might be it's rather self-description, but the default value is not,
neither if the option is supported at all. One might think the remarked
option in the configfil is simple a left-over from an old version.

I hope you will add the option to the man :-)

Bug#950576: [Pkg-utopia-maintainers] Bug#950576: network-manager fails to correctly configure eth0 speed and fails when autoneg is on

[Michael Biebl]

Control: severity -1 normal
Control: tags -1 moreinfo


Am 03.02.20 um 19:27 schrieb Eric Valette:
> 
> If I let eth0 in /etc/network/interface I get my eth0 card correctly 
> configured by ifplugd
> each time using full duplex and 1000Mbps
> 
> ethtool eth0
> Settings for eth0:
> Supported ports: [ TP ]
> Supported link modes:   10baseT/Half 10baseT/Full 
> 100baseT/Half 100baseT/Full 
> 1000baseT/Full 
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes:  1000baseT/Full 
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: off (auto)
> Supports Wake-on: pumbg
> Wake-on: g
> Current message level: 0x0007 (7)
>drv probe link
> Link detected: yes
> 
> If I let network manager handle this interface and either set "allow autoneg" 
> or disable
> it and force  speed at 1000 I get no working interafce it keeps trying to 
> configure
> it in a loop.
> 
> The only config that works is:
> 1) disable autoneg
> 2) and set speed at 100Mbps
> 
> but this is not what I want and fisrt ethtool command shows the ethernet card 
> is capable
> of what I want.

Please provide a verbose debug log
https://wiki.gnome.org/Projects/NetworkManager/Debugging



signature.asc
Description: OpenPGP digital signature

Bug#950575: kamailio manual install fails die modules are not yet in path?¡

[Michael Biebl]

Control: tags -1 moreinfo
Control: severity -1 important

Please run

reportbug --template systemd
reportbug --template kamailio
systemctl cat kamailio.service
systemctl status kamailio.service
journalctl -b -u kamailio.service

on the affected system and attach the output to this bug report.



signature.asc
Description: OpenPGP digital signature

Bug#944040: haveged requires debhelper >= 12.5

[Nicolas Braud-Santoni]

PS: According to the manpage the actual version constraint should be 12.3

On Mon, Feb 03, 2020 at 07:28:29PM +0100, Nicolas Braud-Santoni wrote:
> Control: tag -1 - moreinfo + confirmed pending
> 
> Hi Daniel,
> 
> On Fri, Jan 31, 2020 at 08:28:02AM +0100, Daniel Baumann wrote:
> > On 1/31/20 5:54 AM, Nicolas Braud-Santoni wrote:
> > > I'm not able to reproduce your issue; I literally just made a backport
> > > without changing the original package (except for the d/changelog entry),
> > > which built fine in my buster-backports environment.
> > 
> > ---snip---
> > debian/rules override_dh_makeshlibs
> > make[1]: Entering directory '/build/haveged-1.9.8-3_progress5+u1'
> > # havege-udeb contains a library that's shipped in libhavege2; this is OK.
> > dh_makeshlibs --no-add-udeb
> > Unknown option: no-add-udeb
> > dh_makeshlibs: unknown option or error during option parsing; aborting
> 
> Thanks for the info!
> 
> I had missed the dh_makeshlibs call when looking for something that would
> require a newer dh.  >_>'
> 
> I'm commiting a fix to the packaging repo r.n., so the next upload should
> have it available.
> 
> I can also take care of uploading to backports once this lands in bullseye,
> if you want me to.
> 
> 
> Best,
> 
>   nicoo




signature.asc
Description: PGP signature

Bug#944040: haveged requires debhelper >= 12.5

[Nicolas Braud-Santoni]

Control: tag -1 - moreinfo + confirmed pending

Hi Daniel,

On Fri, Jan 31, 2020 at 08:28:02AM +0100, Daniel Baumann wrote:
> On 1/31/20 5:54 AM, Nicolas Braud-Santoni wrote:
> > I'm not able to reproduce your issue; I literally just made a backport
> > without changing the original package (except for the d/changelog entry),
> > which built fine in my buster-backports environment.
> 
> ---snip---
> debian/rules override_dh_makeshlibs
> make[1]: Entering directory '/build/haveged-1.9.8-3_progress5+u1'
> # havege-udeb contains a library that's shipped in libhavege2; this is OK.
> dh_makeshlibs --no-add-udeb
> Unknown option: no-add-udeb
> dh_makeshlibs: unknown option or error during option parsing; aborting

Thanks for the info!

I had missed the dh_makeshlibs call when looking for something that would
require a newer dh.  >_>'

I'm commiting a fix to the packaging repo r.n., so the next upload should
have it available.

I can also take care of uploading to backports once this lands in bullseye,
if you want me to.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#950574:

[Andreas Kloeckner]

I meant "makes it harder to build software *against* sundials." Sorry
for the confusing phrasing in the initial report.

Andreas


signature.asc
Description: PGP signature

Bug#950576: network-manager fails to correctly configure eth0 speed and fails when autoneg is on

[Eric Valette]

Package: network-manager
Version: 1.22.6-1
Severity: critical
Justification: breaks unrelated software

If I let eth0 in /etc/network/interface I get my eth0 card correctly configured 
by ifplugd
each time using full duplex and 1000Mbps

ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
100baseT/Half 100baseT/Full 
1000baseT/Full 
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  1000baseT/Full 
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes

If I let network manager handle this interface and either set "allow autoneg" 
or disable
it and force  speed at 1000 I get no working interafce it keeps trying to 
configure
it in a loop.

The only config that works is:
1) disable autoneg
2) and set speed at 100Mbps

but this is not what I want and fisrt ethtool command shows the ethernet card 
is capable
of what I want.

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

Kernel: Linux 5.4.17 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.13.12-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.52-1
ii  libc6  2.30-0experimental1
ii  libcurl3-gnutls7.67.0-2
ii  libglib2.0-0   2.63.3-3
ii  libgnutls303.6.12-1
ii  libjansson42.12-1
ii  libmm-glib01.10.4-0.1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.6-1
ii  libpam-systemd 244.1-2
ii  libpolkit-agent-1-00.116-2
ii  libpolkit-gobject-1-0  0.116-2
ii  libpsl50.20.2-2
ii  libreadline8   8.0-3
ii  libselinux13.0-1
ii  libsystemd0244.1-2
ii  libteamdctl0   1.30-1
ii  libudev1   244.1-2
ii  libuuid1   2.34-0.1
ii  policykit-10.116-2
ii  udev   244.1-2
ii  wpasupplicant  2:2.9-6

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1.1
ii  iptables 1.8.4-2
ii  modemmanager 1.10.4-0.1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1
pn  libteam-utils

-- no debconf information

Bug#915024: evince-thumbnailer: Permission denied due to apparmor

[Anthony DeRobertis]

Package: evince
Version: 3.34.1-1+b1
Followup-For: Bug #915024

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

See also https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1798091

Also, this affects caja as well, but the path that needs to be allowed
is /tmp/.mate_desktop_thumbnail.*

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (130, 'unstable-debug'), (130, 'unstable'), (120, 
'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-2
ii  evince-common3.34.1-1
ii  gsettings-desktop-schemas3.34.0-2
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-7
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libevdocument3-4 3.34.1-1+b1
ii  libevview3-3 3.34.1-1+b1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-2
ii  libglib2.0-0 2.62.4-1
ii  libgnome-desktop-3-183.34.2-2
ii  libgtk-3-0   3.24.13-1
ii  libnautilus-extension1a  3.34.1-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libsecret-1-00.19.1-1
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2

Versions of packages evince suggests:
ii  gvfs 1.42.1-3
ii  nautilus-sendto  3.8.6-3
ii  poppler-data 0.4.9-2
ii  unrar1:5.6.6-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXjhbyxUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf7vQgCfeNJdjrKvsxYJwcQRvP/4hOeoWjkA
n0P90qNdIr1OA1sMeyeAhAqkr3eh
=B5ZU
-END PGP SIGNATURE-

Bug#946996: wireguard-tools: 'wg-quick down' segfaults

[Celejar]

On Tue, 28 Jan 2020 14:14:01 -0500
Daniel Kahn Gillmor  wrote:

> On Mon 2020-01-27 19:45:36 -0500, Celejar wrote:
> > I think I'm probably missing something, but lately "ifdown wg0" isn't
> > segfaulting (even after downgrading back to 1.0.20200102-1) - but it
> > doesn't seem to be calling iptables-restore at all, but only nft:
> 
> Ah, that'd be because you installed nft.  If you only had iptables
> installed, and you didn't have nft installed, then you'd exercise the
> different codepath in wg-quick.

Okay, now I've gotten it. I've uninstalled nftables and put in the
debug line, and I get this (with 1.0.20200121-2):

~# ifdown wg0
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
RESTORING: *filter
COMMIT
*nat
COMMIT
*mangle
-D PREROUTING -p udp -m comment --comment "wg-quick(8) rule for wg0" -j 
CONNMARK --restore-mark --nfmask 0x --ctmask 0x
-D POSTROUTING -p udp -m mark --mark 0xca6c -m comment --comment "wg-quick(8) 
rule for wg0" -j CONNMARK --save-mark --nfmask 0x --ctmask 0x
COMMIT
*raw
COMMIT
[#] iptables-restore -n
/usr/bin/wg-quick: line 29: 2284068 Segmentation fault  "$@"

Celejar

Bug#916260: gparted mounts partition without protection

[Phillip Susi]

Nicolas Braud-Santoni writes:
> The scenario at play is the following:
>
> 1. I am a user with some level of administrative privileges, and run gparted.
> 2. I resize a partition (btrfs, in Marc's initial report),
>causing it to be mounted under /tmp, with a mountpoint that's chmod 0777.
> 3. Now *another user* on the same machine can access that file system,
>which I unwittingly mounted and exposed.

I get it, I just don't understand why you would have a filesystem around
whose internal permissions were not already set up correctly but instead
you relied on not mounting it to protect it.

> I agree with Marc that the simplest way to negate the issue would be
> for gparted to make a private, temporary directory (chmod 0700) and put
> all its temporary files and mountpoints there, so they cannot be accidentally
> exposed to other users.

Yea, I suppose it's a simple enough change.

Bug#950575: kamailio manual install fails die modules are not yet in path?¡

[PICCORO McKAY Lenz]

Package: kamailio,systemd
Version: kamailio/5.3.0-1
Version: systemd/230-7
Severity: grave

Another systemd related problem, (like happened with #921015 ), this
error seems does not hapened if are installed with apt.get

i try to install kamailio due other ways, like aptitude or gui others,
and in those ways will fail, because first selected package to install
are kamailio per se and some modules are not yet ready to use it,
this is the output due the systemd "thing" .. does not happened in devuan
with sysvinit or openrc only:

Feb  3 17:25:58 10-101-2-99 systemd[1]: Starting Kamailio (Openser)
SIP Server...
Feb  3 17:25:58 10-101-2-99 systemd[21293]: Failed at step
RUNTIME_DIRECTORY spawning /usr/sbin/kamailio: File exists
Feb  3 17:25:58 10-101-2-99 systemd[1]: kamailio.service: control
process exited, code=exited status=233
Feb  3 17:25:58 10-101-2-99 systemd[1]: Failed to start Kamailio
(Openser) SIP Server.
Feb  3 17:25:58 10-101-2-99 systemd[1]: Unit kamailio.service entered
failed state.
Feb  3 17:25:59 10-101-2-99 systemd[1]: kamailio.service holdoff time
over, scheduling restart.
Feb  3 17:25:59 10-101-2-99 systemd[1]: Stopping Kamailio (Openser)
SIP Server...
Feb  3 17:25:59 10-101-2-99 systemd[1]: Starting Kamailio (Openser)
SIP Server...
Feb  3 17:25:59 10-101-2-99 systemd[1]: Reloading.
Feb  3 17:25:59 10-101-2-99 kamailio[21315]: loading modules under
config path: /usr/lib/x86_64-linux-gnu/kamailio/modules/
Feb  3 17:25:59 10-101-2-99 kamailio[21315]: Listening on

i cannot find what means "RUNTIME DIRECTORY" maybe are due in buster
now path are not set and maybe does not find property the paths, but
only happened with systemd related, i tested same package in devuan
(yes, it works, taking directly from debian) and installs property..

i also tested with mxlinux and works too also..


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#950517: golang-1.14: please add support for riscv64

[Dr. Tobias Quathamer]

Am 02.02.20 um 23:18 schrieb Aurelien Jarno:
> Source: golang-1.14
> Version: 1.14~beta1-2
> Severity: wishlist
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hi,
> 
> golang 1.14 will add support for the 64-bit RISC-V architecture, aka
> riscv64. It has been committed upstream over the last days.
> 
> On the Debian packaging side, it requires very few changes. See the
> attached patch. With it and with a git snapshot from today, I have been
> able to bootstrap golang. Unfortunately bootstrapping it from gcc-go
> didn't work, one of the go1 process never ends. It's probably a GCC bug.
> Instead I have followed the process from Carlos Eduardo [1] to bootstrap
> it from amd64, and then build it natively. All seems to work fine.
> 
> Would it be possible to include that patch in the next golang-1.14
> upload?

Hi Aurelien,

thanks for your patch, I've added it to git, so it'll be part of the
next upload.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot

[Matthias Klose]

On 2/3/20 3:46 PM, Felix Zielcke wrote:
> On Mon, 03 Feb 2020 15:35:21 +0200 dimit...@stinpriza.org wrote:
>> Package: libgcc1
>> Version: 1:9.2.1-25
>> Severity: grave
>> Justification: renders package unusable
>>
>> hey,
>>
>> after upgrading some latest packages on sid, i can no longer unlock
> luks
>> partition and boot. message:
>>
>> "Please unlock disk rootfs:
>> libgcc_s.so.1 must be installed for pthread-cancel to work
>> Aborted"
>>
>> so i think it's libgcc1 related.
>> had to chroot to disk from liveusb, downgrade some packages & finally
> use a
>> different kernel to boot.
>> noticed that update-initramfs with libgcc1 1:9.2.1-25 adds file :
> "Adding
>> binary /lib/x86_64-linux-gnu/libgcc_s.so.1" , while libgcc1 version
>> 1:10-20200202-1 doesn't add any libgcc_s.so.1.
>>
>> also, version from testing includes file /lib/x86_64-linux-
> gnu/libgcc_s.so.1,
>> while sid version uses /lib/libgcc_s.so.1 . libgcc-s1 also includes
> this file :
>> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
>>
>> let me know if you need anymore info.
>>
>> thanks,
>> d.
> 
> The btrfs binary in initramfs is also affected by this.
> See #950556 [1]
> 
> Just now with your report I saw that both btrfs and cryptroot initramfs
> hooks expects libgcc_s.so.1 in the same dir as libc.so.6
> This was true in bullseye but now with the change to gcc-10 the path
> has also changed.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950556

$ dpkg -S libgcc_s.so.1
libgcc-s1:amd64: /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
libgcc1: /lib/libgcc_s.so.1

if you need the library in /lib, make sure that you depend on libgcc1, else it's
found in /usr/lib/.

I'm fine to add some breaks if required.

Bug#950574: sundials: Should ship pkgconfig files

[Andreas Kloeckner]

Source: sundials
Version: 4.1.0+dfsg-1+b2
Severity: wishlist

Dear Maintainer,

>From https://github.com/bmcage/odes I gather that sundials installs
pkgconfig files, however those don't seem to be included in the -dev
packages, which makes sundials harder than necessary to build.

Thanks,
Andreas

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-rc5 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:de (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#913104: [Pkg-privacy-maintainers] Bug#913104: torbrowser-launcher: apparmor denials: lsb_release, fontconfig conf.avail, gtk-3.0 settings.ini

[Roger Shimizu]

Now I can only see the appamor error log for lsb_release:

audit: type=1400 audit(1580483233.981:104): apparmor="DENIED"
operation="exec" profile="torbrowser_firefox" name=
"/usr/bin/lsb_release" pid=29898 comm="firefox.real"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

but TB starts successfully. so it seems no harm.