Bug#978958: release.debian.org: package Thunderbird stucks on autopkgtest on ppc64el for ever

[Carsten Schoenert]

Package: release.debian.org
Severity: normal

Hi there,

since ppc64el was added to the CI pipeline of autopkgtest the package
Thunderbird did never pass a single test on the CI platform as it always
staying in status "Test in progress" one a new version get uploaded.

There is something looking fishy to me in principal on ppc64el.

If the real reason can't be found why thunderbird isn't tested
successful on ppc64el I suggest to ignore this testing on this
architecture.

Regards
Carsten

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

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

Bug#978957: gvmd: Version in testing FTBFS against libgvm-dev in sid manage.c:4179:16: error: too few arguments to function 'osp_target_new'

[Andreas Metzler]

Package: gvmd
Version: 9.0.1-4.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

this is mainly a tracking bug for other people wondering about failing
CI in testing. - I will do a versioned close, once I have a bugnumber.

gvmd 9.0.1 (testing) seems to be incompatible with libgvm-dev as present
in sid since the prototype for 'osp_target_new' has changed.

cu Andreas

[ 13%] Building C object src/CMakeFiles/gvmd.dir/manage.c.o
cd /dev/shm/gvmd-9.0.1/obj-x86_64-linux-gnu/src && /usr/lib/ccache/cc 
-DBINDIR=\"/usr/bin\" -DCACERT=\"/var/lib/gvm/CA/cacert.pem\" 
-DCA_DIR=\"/var/lib/gvm/gvmd/trusted_certs\" 
-DCLIENTCERT=\"/var/lib/gvm/CA/clientcert.pem\" 
-DCLIENTKEY=\"/var/lib/gvm/private/CA/clientkey.pem\" -DGMP_VERSION=\"9.0\" 
-DGVMD_CERT_DATABASE_VERSION=6 -DGVMD_DATABASE_VERSION=221 
-DGVMD_DATA_DIR=\"/usr/share/gvm/gvmd\" -DGVMD_SCAP_DATABASE_VERSION=16 
-DGVMD_STATE_DIR=\"/var/lib/gvm/gvmd\" -DGVMD_VERSION=\"9.0.1\" 
-DGVM_CERT_DATA_DIR=\"/var/lib/gvm/cert-data\" 
-DGVM_CERT_RES_DIR=\"/usr/share/gvm/cert\" -DGVM_DATA_DIR=\"/usr/share/gvm\" 
-DGVM_LIB_INSTALL_DIR=\"/usr/lib\" -DGVM_LOG_DIR=\"/var/log/gvm\" 
-DGVM_NVT_DIR=\"/var/lib/openvas/plugins/\" 
-DGVM_OS_NAME=\"Linux-5.9.0-5-amd64\" -DGVM_RUN_DIR=\"/var/run/gvm\" 
-DGVM_SCAP_DATA_DIR=\"/var/lib/gvm/scap-data\" 
-DGVM_SCAP_RES_DIR=\"/usr/share/gvm/scap\" -DGVM_STATE_DIR=\"/var/lib/gvm\" 
-DGVM_SYSCONF_DIR=\"/etc/gvm\" -DPREFIX=\"/usr\" 
-DSCANNERCERT=\"/var/lib/gvm/CA/servercert.pem\" 
-DSCANNERKEY=\"/var/lib/gvm/private/CA/serverkey.pem\" -I/usr/include/gvm 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/p11-kit-1 
-I/usr/include/uuid -I/usr/include/postgresql 
-I/usr/include/postgresql/13/server -g -O2 
-fdebug-prefix-map=/dev/shm/gvmd-9.0.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -D_BSD_SOURCE 
-D_ISOC99_SOURCE -D_SVID_SOURCE -D_DEFAULT_SOURCE -D_FILE_OFFSET_BITS=64 -O3 
-DNDEBUG -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -fstack-protector 
-Wredundant-decls -o CMakeFiles/gvmd.dir/manage.c.o -c 
/dev/shm/gvmd-9.0.1/src/manage.c
/dev/shm/gvmd-9.0.1/src/manage.c: In function 'launch_osp_openvas_task':
/dev/shm/gvmd-9.0.1/src/manage.c:4179:16: error: too few arguments to function 
'osp_target_new'
 4179 |   osp_target = osp_target_new (hosts_str, ports_str, exclude_hosts_str);
  |^~
In file included from /dev/shm/gvmd-9.0.1/src/manage.h:40,
 from /dev/shm/gvmd-9.0.1/src/manage.c:50:
/usr/include/gvm/osp/osp.h:203:1: note: declared here
  203 | osp_target_new (const char *, const char *, const char *, int, int, 
int);
  | ^~
/dev/shm/gvmd-9.0.1/src/manage.c:4413:18: error: 'osp_start_scan_opts_t' has no 
member named 'parallel'
 4413 |   start_scan_opts.parallel = 1;
  |  ^
make[3]: *** [src/CMakeFiles/gvmd.dir/build.make:137: 
src/CMakeFiles/gvmd.dir/manage.c.o] Error 1
make[3]: Leaving directory '/dev/shm/gvmd-9.0.1/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:178: src/CMakeFiles/gvmd.dir/all] Error 2
make[2]: Leaving directory '/dev/shm/gvmd-9.0.1/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:185: all] Error 2
make[1]: Leaving directory '/dev/shm/gvmd-9.0.1/obj-x86_64-linux-gnu'
dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:6: binary] Error 25

Bug#908058: openjdk-9-jre-headless: dependency of x11-common but a headless package

[Evan Widloski]

Seems like this is still an issue.  I'm installing jre on a machine without a 
display, so I don't understand why X11 is needed here.

Bug#978956: RM: picolisp [armel armhf i386 mipsel] -- ROM; upstream removed 32bit arch support

[陳侃如]

Package: ftp.debian.org
Severity: normal

Bug#978955: last update disables socket activation

[Marc Haber]

Package: openssh-server
Version: 1:8.4p1-3
Severity: important

Hi,

with this last update of the Debian package,
unstable systems that are using socket activated
ssh lose ssh access (connection refused).

It ie nscessary to do systemctl stop ssh.service,
systemctl start ssh.socket to be able to log in again.

Greetings
Marc


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.2-zgbpi-armmp-lpae (SMP w/2 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.20.5
ii  libaudit1  1:3.0-1
ii  libc6  2.31-6
ii  libcom-err21.45.6-1
ii  libcrypt1  1:4.4.17-1
ii  libgssapi-krb5-2   1.18.3-4
ii  libkrb5-3  1.18.3-4
ii  libpam-modules 1.4.0-2
ii  libpam-runtime 1.4.0-2
ii  libpam0g   1.4.0-2
ii  libselinux13.1-2+b2
ii  libssl1.1  1.1.1i-1
ii  libsystemd0247.2-3
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-3
ii  openssh-sftp-server1:8.4p1-3
ii  procps 2:3.3.16-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  247.2-3
ii  ncurses-term 6.2+20201114-1
ii  xauth1:1.0.10-1

Versions of packages openssh-server suggests:
ii  molly-guard   0.7.2
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/password-authentication: true
* openssh-server/permit-root-login: true

Bug#264589: fixed now?

[Paul Wise]

On Thu, 2020-12-31 at 11:35 +0100, Thomas Lange wrote:

> I wonder if your patch
> 0001-Link-to-manual-pages-Closes-264589.patch
> was applied and this bug can now be closed?

The patch is untested and the packages site isn't well maintained so
that would seem unlikely, did you check git for the patch?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#978948: RFS: kcollectd/0.12.0-1 -- simple collectd graphing front-end for KDE

[Antonio Russo]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: aeru...@aerusso.net

Dear mentors,

I am looking for a sponsor for my package "kcollectd"

 * Package name: kcollectd
   Version : 0.12.0-1
   Upstream Author : Antonio Russo 
 * URL : https://www.antonioerusso.com/projects/kcollectd/
 * License : GPLv3+
 * Vcs : https://salsa.debian.org/qt-kde-team/extras/kcollectd
   Section : utils
   Description : simple collectd graphing front-end for KDE

This package provides a basic KDE application for viewing RRD files
created by collectd, the system statistics storage daemon. It allows
easy mouse-driven navigation through data collections and can be used
as a virtual chart recorder.

It builds the binary packages:

  kcollectd - simple collectd graphing front-end for KDE

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.12.0-1.dsc

I am also upstream for this project, and have incorporated a few minor UI
improvements since my last release, in addition to some under the hood build
simplifications.  The upstream update also subsumes a fix for a build failure
that was addressed by an NMU upload earlier this month.  It also updates my
email address.

On the Debian side, this upload tracks the changes upstream, also updating my
email address.

Best,
Antonio Russo


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#978952: wsjtx: No audio on transmit

[tony mancill]

On Fri, Jan 01, 2021 at 04:08:57AM +, Hilary Snaden wrote:
> Package: wsjtx
> Version: 2.3.0~rc2+repack-1+b1
> Severity: grave
> Justification: renders package unusable
> 
> There is no audio output to any of the listed devices (I have tried them 
> all). This was also the case with version 2.2.2,
> 
> Operation in receive mode is mostly satisfactory.

Hi,

Please provide more information about your setup so we can try to
determine if this is an issue with the software or with your local
configuration.  That you had the same issue with 2.2.2 leads me to
suspect latter.  Both 2.3.0-rc2 and 2.2.2 wsjtx have been working fine
for me.

I am changing the severity of this bug from grave [1], as that severity
has the potential to remove the package from the archive for all users.

Thank you,
tony

[1] https://www.debian.org/Bugs/Developer#severities


signature.asc
Description: PGP signature

Bug#977647: 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs

[Ryutaroh Matsumoto]

Control: retitle 977647 5.10.4 Debian kernel does not boot on amd64 with btrfs 
rootfs
Control: reassign 977647 linux-image-5.10.0-1-amd64 5.10.4-1

I installed (signed) linux-image-5.10.0-1-amd64 5.10.4-1 on my laptop 
incompatible
with Linux 5.10.2. It still fails to boot.

On the other hand, I re-confirm that
linux-image-5.9.0-5-amd64 5.9.15-1 boots well and there seems no problem with 
it...

Best regards, Ryutaroh Matsumoto

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Ryutaroh Matsumoto]

> As I said in debian-private (which, of course, is not read by
> everybody), I am in a [VAC] period. I am having quite limited
> available time, and this will continue at least until the beginning of
> 2021. So, please, if you have an upload to make - NMU the package at
> will!

Hi Gunnar,
CC: Christian

vmdb 0.21 appeared in the upstream:
http://git.liw.fi/vmdb2/log/?showmsg=1

I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye
before its deadline.

Best regards, Ryutaroh

Bug#978946: gfxboot: reproducible builds: Embeds user id and group id in cpio files

[Vagrant Cascadian]

Control: tags 978946 fixed-upstream

On 2020-12-31, Vagrant Cascadian wrote:
> Various cpio archives shipped in gfxboot contain the user id and group
> id of the build user:
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/gfxboot.html
>
>   etc/bootsplash/example_01/cdrom/bootlogo
>
>   -rw-r--r--···1··42639·2020-12-24·13:17:48.00·init
>   vs.
>   -rw-r--r--···1··42639·2022-01-26·19:45:05.00·init
>
>
> The attached patch fixes this by passing the owner argument to the cpio
> calls when creating the archives.

This is fixed upstream:

  https://github.com/openSUSE/gfxboot/pull/35

> Unfortunately, the cpio archives also embed the timestamps of the files
> included, which will likely vary between builds, so this does not
> resolve all reproducibility issues with these archives.

Timestamp issues also fixed upstream in the same pull request.


I think applying similar patches to themes/examples* may still be
needed.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#978954: pepperflashplugin-nonfree: should not be part of next stable Debian release

[Ying-Chun Liu (PaulLiu)]

Package: pepperflashplugin-nonfree
Version: 1.8.7
Severity: grave
Justification: renders package unusable

Dear Maintainer,

flash has been EOL today. Browsers are starting to block flash.
I think we should block this package goes into next release?

Yours,
Paul

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

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

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils 2.35.1-6
ii  ca-certificates  20200601
ii  libgcc-s110.2.1-3
ii  libstdc++6   10.2.1-3
ii  wget 1.20.3-1+b3

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   83.0.4103.116-3.1+b2
pn  ttf-dejavu 
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information


signature.asc
Description: PGP signature

Bug#978951: ITP: golang-github-bep-godartsass -- Go API backed by the native Dart Sass Embedded executable

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-bep-godartsass
  Version : 0.11.0-1
  Upstream Author : Bjørn Erik Pedersen
* URL : https://github.com/bep/godartsass
* License : Expat
  Programming Lang: Go
  Description : Go API backed by the native Dart Sass Embedded executable.

 This is a Go API backed by the native Dart Sass Embedded executable,
 see https://github.com/sass/dart-sass-embedded
 .
 The primary motivation for this project is to provide SCSS support to Hugo,
 see https://gohugo.io/
 .
 For LibSass bindings in Go, see GoLibSass at https://github.com/bep/golibsass,
 packaged as golang-github-bep-golibsass-dev for Debian

Reason for packaging: Needed by hugo (>= 0.80.0)

Bug#953931: libarchive: Switch from deprecated to

[Guillem Jover]

On Fri, 2021-01-01 at 00:41:54 +0100, Andreas Henriksson wrote:
> On Sat, Mar 14, 2020 at 08:01:16PM +0100, Guillem Jover wrote:
> > Source: libarchive
> > Source-Version: 3.4.0-2
> > Severity: important
> > User: a...@packages.debian.org
> > Usertags: libattr-drop-attr-xattr-header

> > This package uses the deprecated  header (from libattr)
> > instead of the one provided now by glibc .
> [...]
> > It looks like this is the only header used by this package from libattr,
> [...]
> 
> As Tobi already mentioned, libarchive checks for both attr/xattr.h and
> sys/xattr.h  revelant upstream commit that introduced this is:
> https://github.com/libarchive/libarchive/commit/365a91def0c9c173b93643698d6ee4e8e0fc2746
> 
> I've verified in a chroot that libarchive still builds just fine even
> when after `rm /usr/include/attr/xattr.h` has been done, the configure
> output looks like this (only xattr parts included):
> 
> ```
> # grep 'checking for.*xattr' /tmp/log 
> checking for attr/xattr.h... no
> checking for sys/xattr.h... yes
> checking for library containing setxattr... none required
> checking for fgetxattr... yes
> checking for flistxattr... yes
> checking for fsetxattr... yes
> checking for getxattr... yes
> checking for lgetxattr... yes
> checking for listxattr... yes
> checking for llistxattr... yes
> checking for lsetxattr... yes
> ```
> 
> So it should be safe to drop the attr/xattr.h header from libattr1-dev
> as far as libarchive is concerned.
> 
> If I missed something please enlighten me, otherwise this bug report
> should likely just be closed.

As mentioned in the part that got trimmed, the libattr1-dev
Build-Depends can be dropped, and even if it still gets pulled in by
libacl1-dev (which currently does need it), it does not matter, as
this package will just stop using the header when it finally
disappears.

Thanks,
Guillem

Bug#978950: rox-filer: black-on-black text with a dark GTK theme

[Adam Borowski]

Package: rox-filer
Version: 1:2.11-2
Severity: normal

Hi!
The rox-filer is unusable with a dark theme, as it displays text in black
even if the background is black as well.

It must either obey both foreground and background color from the theme,
or neither.


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

Kernel: Linux 5.11.0-rc1-umbar-00014-g59361a5e5d24 (SMP w/6 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rox-filer depends on:
ii  libc62.31-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk2.0-0  2.24.33-1
ii  libice6  2:1.0.10-1
ii  libpango-1.0-0   1.46.2-3
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.12-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  shared-mime-info 2.0-1

Versions of packages rox-filer recommends:
pn  zeroinstall-injector  

Versions of packages rox-filer suggests:
ii  file  1:5.39-3
pn  menu  

-- no debconf information

Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM

[Christoph Anton Mitterer]

Hey.


Just wondered:


1) Since this is a binary blob who, by it's nature, is made for
surveillance, it's IMO more a rather serious security issue than just a
DFSG-policy problem.
No one really knows what exactly Google ships there.

So maybe people should be told about this more actively in a DSA or
NEWS.Debian entry?



2) To my great surprise (and shock - due to the compromise) I found the
binaries downloaded last July, even though I never used chromium on any
site that uses EME or things like that.
Which makes this behaviour even more suspicious.



3) AFAIU, now the Debian package no longer downloads it automatically
(with widevine-cdm-cu.patch), but many people will still have it
silently in place (and presumably executed). Which is again kinda a
point for (1).



4) This problem of browsers downloading their own closed-source and
possibly compromised stuff has already surfaced in the past.
Wouldn't it be safer to completely remove the code doing at all?
Right now we have widevine-cdm-cu.patch which is fine for just this,
and as soon as Google would add something new it would probably get
downloaded again until someone notices by chance.


In general, I think it's pretty bad if software circumvents secure APT
do download further software:

- there is no central security support (just imagine an attacked simply
blocks any time chromium tries to upgrade the binary blobs) and
people will not even notice if upgrades from within the software fail.

- it's not taken into account by tools like check_apt either

- unless someone knows that Chromium puts software in .config it will
stay there forever and not begin removed or so when the chromium
package would be removed

- an evil Google could just selectively distribute hacked versions of
their binaries - something which is more or less impossible when all
software comes via secure APT

- doing package upgrade really in a secure way (i.e. preventing
blocking attacks, downgrade attacks, or just not using
outdated/insecure algorithms) is actually not that easy and I've seen
many downloader packages doing it wrong - with secure APT there's one
central place where all this is handled (securely)



Cheers,
Chris.

Bug#978942: reportbug: Previously-filed WNPP bugs are not clearly identified

[Sandro Tosi]

> I've noticed that when filing WNPP bugs for new packages, reportbug does not
> clearly identify if there is a previous WNPP bug for that (new) package.
> Instead, it seems to just return all WNPP bugs.
>
> Expected behavior:
> Debian packager files an ITP bug for foo. Packager forgets they have filed
> and later begins to file another ITP bug for foo. The reportbug program lists
> "1) #123456 ITP: foo -- package that does bar" as the first entry after
> querying the BTS.
>
> Actual behavior:
> The reportbug program lists all WNPP bugs. If the prior ITP for foo is 
> present,
> it is many pages down and the packager is unlikely to see it.
>
> I have replicated this behavior with a few ITP/RFP bugs, but please let me
> know if you have any questions or issues with replicating. Thank you!

did you know you can filter the bugs list?

(2-62/6492) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? ?
y - Problem already reported; optionally add extra information.
N - (default) Problem not listed above; possibly check more (skip to Next page).
b - Open the complete bugs list in a web browser.
m - Get more information about a bug (you can also enter a number
without selecting "m" first).
r - Redisplay the last bugs shown.
q - I'm bored; quit please.
s - Skip remaining problems; file a new report immediately.
f - Filter bug list using a pattern.
e - Open the report using an e-mail client.
? - Display this help.

"f" in this menu, which you can access by typing "?" at the prompt. f.e.

(2-62/6492) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? f
Enter the search pattern (a Perl-compatible regular expression)
or press ENTER to exit: python
Bugs with severity normal: 69 reports (8 remain)
   1) #516501  RFH: libapache2-mod-python -- Python-embedding module
for Apache 2
   2) #623685  O: pygresql -- PostgreSQL module for Python
   3) #677174  O: python-minimock -- simple library for Python mock objects
   4) #816512  O: python-svg.path -- SVG path objects and parser for Python
...


it is probably preferable that the user is going to initiate the
search for a possible similar (or same package); the reason is that
there are several ways to call a source package (not to include
typos), with prefix/suffix for the programming language used and other
harmonization.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#978949: dh-python: pybuild build system detection not consistent

[Graham Inggs]

Source: dh-python
Version: 4.20201102

Hi Maintainer

Pybuild's build system detection is not consistent across
architectures. While building src:python-blosc, the build system was
detected as distutils for most architectures, except for ia64 [1],
riscv64 [2], sparc64 [3] and x32 [4] it was detected as cmake, and the
builds failed there.

In Ubuntu, the build system was detected as cmake for most
architectures, except for ppc64el and riscv64 it was detected as
distutils.

Happy New Year!
Graham


[1] 
https://buildd.debian.org/status/fetch.php?pkg=python-blosc=ia64=1.9.2%2Bds1-2=1607985420=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=python-blosc=riscv64=1.9.2%2Bds1-2=1608483844=0
[3] 
https://buildd.debian.org/status/fetch.php?pkg=python-blosc=sparc64=1.9.2%2Bds1-2=1607985340=0
[4] 
https://buildd.debian.org/status/fetch.php?pkg=python-blosc=x32=1.9.2%2Bds1-2=1607985287=0

Bug#978947: gcc-defaults: please upload gcc-defaults/experimental (for gcc-11)

[Adam Borowski]

Source: gcc-defaults
Version: 4:10.2.0-1
Severity: wishlist

Hi!
The gcc-11 package is available (mighty thanks!) but there's no
gcc/experimental counterpart for it.

Software with sane build systems can be tested using "CC=gcc-11 CXX=g++-11
CPP=cpp-11" but sanity is not as widespread as one would hope.

Also, such packages make testing that involves sbuild much easier.

Thus: please upload gcc-11 defaults to experimental.


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

Kernel: Linux 5.10.2-00014-g6b5bceb19acf (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#978935: [Pkg-utopia-maintainers] Bug#978935: network-manager: disconnect on upgrade

[Vincent Lefevre]

On 2020-12-31 20:22:56 +0100, Michael Biebl wrote:
> Am 31.12.20 um 18:37 schrieb Vincent Lefevre:
> > During the upgrade, network-manager disconnected, so that I completely
> > lost the network connection. Fortunately, I was in front of my machine,
> > but this means that a remote upgrade can make the machine unavailable!
> 
> I might be mistaken, but afaics, this has always been the case for WiFi
> connections (as it is not really possible to carry the state across daemon
> reexecs). Are you saying this is not the case?

I've been using NetworkManager only since July on my laptop.
I've checked my logs, and this was the first time I upgraded
NetworkManager over WiFi.

Before using NetworkManager, I've never had such an problem, IIRC.
When my machine was connected via WiFi, I was using wicd. I suppose
that it could handle the reconnection, or this would mean that
I upgraded it only over Ethernet (I don't remember).

The name of the active connection could be stored in a file, so that
a reexec'ed daemon could pick the information. By active connection,
I mean the last connection chosen by the user, under the condition
that the user has not explicitly disconnected.

> Ethernet connections should not be torn down on a daemon stop.
> 
> A remote upgrade over a WiFi connection without a side-band is not something
> I would encourage.

Perhaps, but anyway, this is not nice to disconnect the user (at least
leave the connection disconnected just after the restart) without an
explicit request. This can make some parts of the upgrade process fail
(e.g. how-can-i-help, which is run just after the upgrade and needs a
working connection).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#978946: gfxboot: reproducible builds: Embeds user id and group id in cpio files

[Vagrant Cascadian]

Source: gfxboot
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various cpio archives shipped in gfxboot contain the user id and group
id of the build user:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/gfxboot.html

  etc/bootsplash/example_01/cdrom/bootlogo

  -rw-r--r--···1··42639·2020-12-24·13:17:48.00·init
  vs.
  -rw-r--r--···1··42639·2022-01-26·19:45:05.00·init


The attached patch fixes this by passing the owner argument to the cpio
calls when creating the archives.


Unfortunately, the cpio archives also embed the timestamps of the files
included, which will likely vary between builds, so this does not
resolve all reproducibility issues with these archives.


Thanks for maintaining gfxboot!


live well,
  vagrant
From 7a670f72d5305aaf692597f1748937d552d290a3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 31 Dec 2020 08:57:55 +
Subject: [PATCH 1/2] Patch calls to create cpio archives to set owner and
 group.

---
 bin/unpack_bootlogo  | 2 +-
 gfxboot  | 4 ++--
 themes/openSUSE/Makefile | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/bin/unpack_bootlogo b/bin/unpack_bootlogo
index ec83d0b..7672e16 100755
--- a/bin/unpack_bootlogo
+++ b/bin/unpack_bootlogo
@@ -48,7 +48,7 @@ sub unpack_bootlogo
 }
   }
 
-  open P, "| cd $tmp; cpio --quiet -o >../bootlogo";
+  open P, "| cd $tmp; cpio --quiet --owner=+0:+0 -o >../bootlogo";
   print P "$_\n" for grep $_, @files;
   if($xdir) { print P "$_\n" for @ext }
   close P;
diff --git a/gfxboot b/gfxboot
index f7cda36..4015dd2 100755
--- a/gfxboot
+++ b/gfxboot
@@ -2597,7 +2597,7 @@ sub pack_archive
 }
 
 if(@pack_list) {
-  open $f, "| ( cd $dir ; cpio --quiet -o ) >$file/$archive";
+  open $f, "| ( cd $dir ; cpio --quiet --owner=+0:+0 -o ) >$file/$archive";
   print $f join("\n", @pack_list);
   close $f;
 }
@@ -2606,7 +2606,7 @@ sub pack_archive
   else {
 $file = $gfxboot_tmp->file;
 
-$i = system "cd $dir ; find . | cpio --quiet -o >$file 2>/dev/null";
+$i = system "cd $dir ; find . | cpio --quiet --owner=+0:+0 -o >$file 2>/dev/null";
 die "$file: failed to create archive\n" if $i;
   }
 
diff --git a/themes/openSUSE/Makefile b/themes/openSUSE/Makefile
index 3a71f9b..1c8de69 100644
--- a/themes/openSUSE/Makefile
+++ b/themes/openSUSE/Makefile
@@ -56,7 +56,7 @@ ifdef DEFAULT_LANG
 	@echo $(DEFAULT_LANG) >bootlogo.dir/lang
 endif
 	@sh -c 'cd bootlogo.dir; chmod +t * ; chmod -t init languages'
-	@sh -c 'cd bootlogo.dir; echo * | sed -e "s/ /\n/g" | cpio --quiet -o >../bootlogo'
+	@sh -c 'cd bootlogo.dir; echo * | sed -e "s/ /\n/g" | cpio --quiet --owner=+0:+0 -o >../bootlogo'
 
 message: src/main.bin src/gfxboot.cfg help-boot/.ready po/.ready fonts/.ready
 	@rm -rf message.dir
@@ -71,7 +71,7 @@ ifdef DEFAULT_LANG
 	@echo $(DEFAULT_LANG) >message.dir/lang
 	@echo $(DEFAULT_LANG) >>message.dir/languages
 endif
-	@sh -c 'cd message.dir; echo * | sed -e "s/ /\n/g" | cpio --quiet -o >../message'
+	@sh -c 'cd message.dir; echo * | sed -e "s/ /\n/g" | cpio --quiet --owner=+0:+0 -o >../message'
 
 clean:
 	@for i in $(SUBDIRS) ; do [ ! -f $$i/Makefile ] ||  make -C $$i clean || break ; done
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#953931: libarchive: Switch from deprecated to

[Andreas Henriksson]

Hello,

On Sat, Mar 14, 2020 at 08:01:16PM +0100, Guillem Jover wrote:
> Source: libarchive
> Source-Version: 3.4.0-2
> Severity: important
> User: a...@packages.debian.org
> Usertags: libattr-drop-attr-xattr-header
> 
> Hi!
> 
> This package uses the deprecated  header (from libattr)
> instead of the one provided now by glibc .
[...]
> It looks like this is the only header used by this package from libattr,
[...]

As Tobi already mentioned, libarchive checks for both attr/xattr.h and
sys/xattr.h  revelant upstream commit that introduced this is:
https://github.com/libarchive/libarchive/commit/365a91def0c9c173b93643698d6ee4e8e0fc2746

I've verified in a chroot that libarchive still builds just fine even
when after `rm /usr/include/attr/xattr.h` has been done, the configure
output looks like this (only xattr parts included):

```
# grep 'checking for.*xattr' /tmp/log 
checking for attr/xattr.h... no
checking for sys/xattr.h... yes
checking for library containing setxattr... none required
checking for fgetxattr... yes
checking for flistxattr... yes
checking for fsetxattr... yes
checking for getxattr... yes
checking for lgetxattr... yes
checking for listxattr... yes
checking for llistxattr... yes
checking for lsetxattr... yes
```

So it should be safe to drop the attr/xattr.h header from libattr1-dev
as far as libarchive is concerned.

If I missed something please enlighten me, otherwise this bug report
should likely just be closed.

Regards,
Andreas Henriksson

Bug#978945: thunderbird: Message subwindow tilts (resizes in a loop)

[Alejandro Colomar]

Package: thunderbird
Version: 1:84.0~
Severity: normal
X-Debbugs-Cc: alx.manpages@g

Dear Maintainer,

I opened an email from linux-...@vger.kernel.org mailing list,
and when I clicked on '1 more' to see the full list of CCs,
the subwindow containing the email header (From, Subject, To, Cc, Date)
and the subwindow containing the message itself, both started resizing in a 
loop, tilting.
The email was unreadable.  I was using thunderbird 78.5.1.

I upgraded to 84.0b3 from experimental to see if the bug was fixed, and no luck.

However, when I opened the about page (Alt > Help > About Thunderbird)
to check the exact version that was running,
the bug disappeared and I can't trigger it again.

Before opening that, closing and opening thunderbird didn't solve the issue.
It only happened to me with that email.

The email id is:
Message-ID: <160945467182.2830865.6578267403605057347.stgit@magnolia>
You can find it here:
https://lore.kernel.org/linux-api/160945467182.2830865.6578267403605057347.stgit@magnolia/



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

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

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-6
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.20-1
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-3
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libicu67 67.1-5
ii  libjson-c5   0.15-1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.60-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-3
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.6.12-1
ii  libx11-xcb1  2:1.6.12-1
ii  libxcb-shm0  1.14-2.1
ii  libxcb1  1.14-2.1
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.3-1
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.5-1+b2
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.18.3-4
ii  libgtk2.0-0   2.24.32-5

-- no debconf information

Bug#978944: linux-image-5.10.0-1-amd64-unsigned: Please enable CONFIG_PCENGINES_APU2

[Maximilian Wilhelm]

Package: src:linux
Version: 5.10.4-1
Severity: wishlist

Dear Maintainer,

while booting the latest kernels on PCengins APU2 boards I noticed to following
entry in the kernel log:

leds_apu: No PC Engines APUv1 board detected. For APUv2,3 support, enable 
CONFIG_PCENGINES_APU2

It would be nice to have supporte for fiddling with the LEDs of the board so I
would like to ask you to enable above config option in future kernels if there
is no reasons to not to :)

Thank you for you work!

Kind regards
Max

Bug#923387: ping -- still breaks unrelated packages

[Adam Borowski]

Ping!
ABI issues have long since been addressed (per your pre-Buster request),
and we're approaching Bullseye freeze.  Thus, another ping: could you please
apply this one-line patch?

This dependency (default-logind | logind) is a part of official Policy, as
of version 4.4.0.

Because of udisks2's position on desktop environments dependency chains, the
no-alternative dependency on libpam-systemd makes many unrelated packages
uninstallable, even on installs that don't use any of udisks2's
functionality (like, I use it on my laptops but not desktops).  This can
be worked around with libpam-elogind-compat, but that's an experimental-only
hack that was explicitely described as not supposed to ever reach a release.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#977994: apt: Output from sandboxed methods should not be trusted

[Demi M. Obenour]

On 12/31/20 6:03 AM, David Kalnischkies wrote:
> On Wed, Dec 30, 2020 at 09:32:32PM -0500, Demi M. Obenour wrote:
>> That is true.  Nevertheless, if we are going to put in the work to
>> confine the methods, we should also make sure they cannot escape
>> their confinement.
> 
> The confinement can never be perfect given that we always have to let
> data escape to actually work with it. Its also fatal to go into
> discussion with an attitude of demanding perfectism as nothing else
> registers as improvement over the status quo.
> 
> Is APT perfect? Certainly not. Was it a good idea to not run the http
> method as root? It surely was work, but we hope it was an improvement
> even if not bulletproof and hence not to your liking. Can we do more?
> Yes, if time and energy permits.

Indeed.  Running the HTTP method not as root was absolutely an
improvement, and perfection is not possible.

>> 1. libapt-pkg spawns its methods as normal.
>>
>> 2. When libapt-pkg requests that a file be downloaded, it creates
>>a socketpair and passes one end to the method using SCM_RIGHTS.
>>libapt-pkg reads from the other end in a background thread.
>>
>> 3. The method downloads the file as normal, but instead of writing it
>>to a file, it writes it to the file descriptor it received above.
>>libapt-pkg reads this data, hashes it, and writes it to a temporary
>>file.
> 
> You fail to mention who is (e.g. in the case of https) creating the
> connection to the server, keeping it alive, handling handshakes (https),
> reading/running proxy configuration and pipelining(http1.1).

The method would be responsible for all of that.

> The later can actually cause the method to change the file it is working
> with if it detects a server has messed up pipelining. I presume
> a potential http2 can do that on purpose due to their streams.

I was not aware of that.  

> Other things to consider are partial downloads (one optional input file),
> pdiff patches (potentially infinite amount of input files) and methods
> who do not produce a verifiable stream of data as output (e.g. gpgv).
> 
> They all produce countless different messages accompanying the raw data
> though, like progress reports and error messages – both based at least
> tangibly if not directly on (untrusted) data from the server.
> 
> You also fail to mention how you handle e.g. redirects, which was the
> start of this whole CVE message passing ordeal.
> 
> 
>> 4. The method returns its response and closes the file descriptor.
> 
> Oh, so you are passing a message from the method to libapt. How is that
> message secured given it is data coming from a source (= the method) you
> do not trust?

I am assuming that the message parser in libapt is trusted.

>> 5. libapt-pkg reads the response.  It reads and closes the file
>>descriptor, and checks the hash against the signed manifest.
> 
> The size of unprocessed data in a pipe is not infinite. You make it
> sound like you could download a 4 GB deb to an open file descriptor and
> leave it there until the process is done. In reality you have to
> constantly process that data (= calculate hash) and store on disk long
> before the process is done.

100% agree.  libapt would presumably do this on a background thread.

> (Also, just so we be clear: There is no "the" hash. APT supports
>  multiple, the involved methods support multiple, the repository
>  supports multiple, and these (at least) three sets hopefully have
>  a non-empty intersection.)

Poor phrasing on my part.

>>If the file being downloaded is a diff, then the hash of the diff
>>is checked.
> 
> As said, e.g. the method "store" takes e.g. a Contents.xz (which passed
> hashes check), extracts it (= subject to e.g. an extraction bomb) and
> produces a Contents.lz4. The result can not be verified. The
> intermediate product (= the uncompressed data) only this method sees can.
> Or are you saying that because the file passed hashes once, its
> absolutely no longer hostile (I mentioned extraction bomb for a reason)
> and no mistakes could have been made?

Correct.  Once a strong hash of the file has been verified, I assume
that it can be trusted.  So I would run “store” as a separate
user than the untrusted “http” method.

Could mistakes have been made?  Absolutely.  But I don’t consider
such mistakes to be any more likely than they are now.

> Similar, why only check the hash of the diff if we can and should also
> check the hash of the file it produced (potentially as an intermediate
> as its on disk storage is potentially again a compressed file).
> 
> With that train of thought we can just use https and be done with it.
> 
> 
>> This is safe.  If the method returns malicious data, libapt-pkg will
>> detect it.  The hashing and writing can be performed in a background
>> thread, so there is very little performance penalty.
> 
> God forbid that someone runs `sed -i -e 's#background thread#method#'` on
> this sentence. The word "thread" doesn't 

Bug#978943: clang-check dumps stack trace with no CLI args

[John Scott]

Package: clang-tools-11
Version: 1:11.0.0-5+b1
Severity: minor

For some reason clang-check raises SIGABRT if it's not given any
command-line arguments. gdb gives me a backtrace like this

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fffefd05537 in __GI_abort () at abort.c:79
#2  0x70cf2c48 in report_fatal_error ()
at 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/llvm/lib/Support/ErrorHandling.cpp:126
#3  0x70cf2c67 in report_fatal_error ()
at 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/llvm/lib/Support/ErrorHandling.cpp:87
#4  0x773c2eb6 in CommonOptionsParser ()
at 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/clang/lib/Tooling/CommonOptionsParser.cpp:173
#5  0x00405eb3 in CommonOptionsParser ()
at 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/clang/include/clang/Tooling/CommonOptionsParser.h:78
#6  main () at 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/clang/tools/clang-check/ClangCheck.cpp:163

but running clang-check with the debugging symbols installed is much more
noisy; unfortunately it looks like usrmerge confusion caused it to omit the
interesting bit:

 #0 0x7f6476cd9e7f llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/llvm/lib/Support/Unix/Signals.inc:564:13
 #1 0x7f6476cd81b2 llvm::sys::RunSignalHandlers() 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/llvm/lib/Support/Signals.cpp:69:18
 #2 0x7f6476cda355 SignalHandler 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/llvm/lib/Support/Unix/Signals.inc:0:3
 #3 0x7f647dead140 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
 #4 0x7f6475c52c81 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7f6475c3c537 abort ./stdlib/abort.c:81:7
 #6 0x7f6476c29c48 (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xb20c48)
 #7 0x7f6476c29c67 (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xb20c67)
 #8 0x7f647d2f9eb6 (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x20f4eb6)
 #9 0x00405eb3 _M_ptr 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:173:42
#10 0x00405eb3 get 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:422:21
#11 0x00405eb3 operator* 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:408:10
#12 0x00405eb3 getCompilations 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/clang/include/clang/Tooling/CommonOptionsParser.h:103:12
#13 0x00405eb3 main 
/build/llvm-toolchain-11-eHqKZY/llvm-toolchain-11-11.0.0/clang/tools/clang-check/ClangCheck.cpp:164:32
#14 0x7f6475c3dd0a __libc_start_main ./csu/../csu/libc-start.c:308:16
#15 0x00405b7a (/usr/lib/llvm-11/bin/clang-check+0x405b7a)

Although clang-check is technically-oriented, just as assertion checks are
no substitute for proper error handling, I don't think basically dumping
core is a sound thing to do, if this is intentional.

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-tools-11 depends on:
ii  clang-111:11.0.0-5+b1
ii  libc6   2.31-6
ii  libclang-cpp11  1:11.0.0-5+b1
ii  libclang1-111:11.0.0-5+b1
ii  libgcc-s1   10.2.1-3
ii  libllvm11   1:11.0.0-5+b1
ii  libstdc++6  10.2.1-3
ii  python3 3.9.0-4

clang-tools-11 recommends no packages.

clang-tools-11 suggests no packages.

-- no debconf information


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

Bug#978942: reportbug: Previously-filed WNPP bugs are not clearly identified

[Olek Wojnar]

Package: reportbug
Version: 7.9.0
Severity: normal

Dear reportbug Maintainers,

I've noticed that when filing WNPP bugs for new packages, reportbug does not
clearly identify if there is a previous WNPP bug for that (new) package.
Instead, it seems to just return all WNPP bugs.

Expected behavior:
Debian packager files an ITP bug for foo. Packager forgets they have filed
and later begins to file another ITP bug for foo. The reportbug program lists
"1) #123456 ITP: foo -- package that does bar" as the first entry after
querying the BTS.

Actual behavior:
The reportbug program lists all WNPP bugs. If the prior ITP for foo is present,
it is many pages down and the packager is unlikely to see it.

I have replicated this behavior with a few ITP/RFP bugs, but please let me
know if you have any questions or issues with replicating. Thank you!

-Olek

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

control: tag -1 - moreinfo

On Mon, Dec 21, 2020 at 11:32 AM David Steele  wrote:

>
>
> On Mon, Dec 14, 2020 at 5:29 PM David Steele  wrote:
>
>> On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton 
>> wrote:
>>
>>>
>>> Could you provide an actual patch against policy.git, please, for
>>> seconding?  See README.md in policy.git for more info.
>>>
>>> --
>>> Sean Whitton
>>>
>>
>>
>> https://salsa.debian.org/steele/policy/-/tree/bug976402-steele
>>
>> diff --git a/virtual-package-names-list.yaml
>> b/virtual-package-names-list.yaml
>> index 2a9857a..11afe1e 100644
>> --- a/virtual-package-names-list.yaml
>> +++ b/virtual-package-names-list.yaml
>> @@ -65,6 +65,9 @@ virtualPackages:
>>  - name: tclsh
>>description: a /usr/bin/tclsh
>>alternatives: [/usr/bin/tclsh]
>>  {+- name: todo.txt+}
>> {+   description: a command-line task management utility compatible with
>> todo.txt CLI (http://todotxt.org)+}
>> {+   alternatives: [/usr/bin/todo.txt]+}
>>  - name: wish
>>description: a /usr/bin/wish
>>alternatives: [/usr/bin/wish]
>>
>
> Second seconds request.
>
>
I'm not aware of any other inputs expected of me.

Bug#976003: RFP: tree-sitter -- incremental parsing system for programming tools

[James McCoy]

Control: retitle -1 ITP: tree-sitter -- incremental parsing system for 
programming tools
Control: owner -1 !

On Fri, Nov 27, 2020 at 09:49:49PM -0500, James McCoy wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: tree-sitter
>   Version : 0.17.3
>   Upstream Author : Max Brunsfeld 
> * URL : https://tree-sitter.github.io/tree-sitter/
> * License : MIT
>   Programming Lang: C, Rust
>   Description : incremental parsing system for programming tools
> 
> [...]
>  - is it a dependency for another package? do you use it?
> 
> Yes, it will be used by an upcoming version of Neovim.

I'm going to work on an initial package for the C library and
development headers.  Additional binary packages can be added later, if
there's demand.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#978742: mmtarfilter: Slow performance with many path exclusions

[Josh Triplett]

On Wed, Dec 30, 2020 at 10:38:58PM -0800, Josh Triplett wrote:
> With a large number of path exclusions specified (around 500),
> mmtarfilter starts to become a noticeable performance bottleneck.
> 
> It looks like mmtarfilter checks each file linearly against each filter
> using fnmatch.
> 
> Python's fnmatch implementation works by translating shell patterns into 
> regular
> expressions. Python also provides a function to do that translation
> separate from fnmatch. One fairly simple optimization would be to walk the 
> list of
> patterns *once*, take each series of consecutive exclude or include
> filters, turn each one into a regex, join all the regexes in
> each group together using (?:...)|(?:...) , and compile the resulting
> regexes once. That should provide a substantial performance improvement.

Turns out there's a much simpler explanation with a simpler fix. fnmatch
has a 256-entry LRU cache for the translated regular expressions. Once
there are more than 256 path filters, the cache stops working entirely,
and every shell pattern gets re-translated and re-compiled on every
invocation of fnmatch.

I wrote the attached patch for mmtarfilter to address this. On an
invocation of mmdebstrap with around 500 path filters, this saves more
than a minute.

- Josh Triplett
>From 2218e9d882516c4cdb4a6ba41121355e475da06d Mon Sep 17 00:00:00 2001
Message-Id: <2218e9d882516c4cdb4a6ba41121355e475da06d.1609448641.git.j...@joshtriplett.org>
From: Josh Triplett 
Date: Thu, 31 Dec 2020 12:49:16 -0800
Subject: [PATCH] Optimize mmtarfilter to handle many path exclusions

mmtarfilter uses fnmatch to handle path exclusions and inclusions.
Python's fnmatch handles shell patterns by translating them to regular
expressions, with a 256-entry LRU cache. With more than 256 path
exclusions or inclusions, this LRU cache no longer works, and every
invocation of fnmatch on every file in every package will re-translate
and re-compile a regular expression, resulting in much worse
performance.

Translate all the shell patterns to regular expressions once. For an
mmdebstrap invocation with around 500 path filters, this speeds up
mmdebstrap by more than a minute.
---
 debian/changelog |  7 +++
 tarfilter| 13 +++--
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 87d1f32..06227cf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mmdebstrap (0.7.4-1) UNRELEASED; urgency=medium
+
+  [ Josh Triplett ]
+  * Optimize mmtarfilter to handle many path exclusions (closes: #978742)
+
+ -- Johannes 'josch' Schauer   Thu, 31 Dec 2020 12:56:02 -0800
+
 mmdebstrap (0.7.3-1) unstable; urgency=medium
 
   * new upstream release
diff --git a/tarfilter b/tarfilter
index 838e4f5..ab76683 100755
--- a/tarfilter
+++ b/tarfilter
@@ -21,14 +21,15 @@
 import tarfile
 import sys
 import argparse
-from fnmatch import fnmatch
+import fnmatch
 import re
 
 
 class FilterAction(argparse.Action):
 def __call__(self, parser, namespace, values, option_string=None):
 items = getattr(namespace, "filter", [])
-items.append((self.dest, values))
+regex = re.compile(fnmatch.translate(values))
+items.append((self.dest, regex))
 setattr(namespace, "filter", items)
 
 
@@ -64,17 +65,17 @@ dpkg(1) for information on how these two options work in detail.
 skip = False
 if not args.filter:
 return False
-for (t, f) in args.filter:
-if fnmatch(member.name[1:], f):
+for (t, r) in args.filter:
+if r.match(member.name[1:]) is not None:
 if t == "path_include":
 skip = False
 else:
 skip = True
 if skip and (member.isdir() or member.issym()):
-for (t, f) in args.filter:
+for (t, r) in args.filter:
 if t != "path_include":
 continue
-prefix = re.sub(r"^([^*?[\\]*).*", r"\1", f)
+prefix = re.sub(r"^([^*?[\\]*).*", r"\1", r.pattern)
 prefix = prefix.rstrip("/")
 if member.name[1:].startswith(prefix):
 if member.name == "./usr/share/doc/doc-debian":
-- 
2.30.0

Bug#978941: ITP: golang-github-d2r2-go-sht3x -- interact with Sensirion SHT3x humidity and temperature sensor's family (library)

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: golang-github-d2r2-go-sht3x
  Version : 0.0~git20181222.074abc2-1
  Upstream Author : Denis Dyakov
* URL : https://github.com/d2r2/go-sht3x
* License : Expat
  Programming Lang: Go

This library is written in Go programming language for Raspberry Pi and
counterparts. It makes all necessary i2c-bus interactions and values
computation to give you relative humidity and temperature values from
the Sensirion SHT30, SHT31, and SHT35 humidity and temperature sensors.
These sensors have an integrated heater which could be helpful in some
specific application (such as periodic condensate removal, for example).

I am working on a Prometheus sensors exporter which is using go-bsbmp
and go-sht3x. I will maintain these libraries as part of the Debian Go
Packaging Team.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#977172: buster-pu: package qxmpp/1.0.0-4+deb10u1

[Boris Pek]

>>  I would like to push a fix for potential SEGFAULT on connection error
>>  in qxmpp library. Proposed patch is well tested in Debian unstable
>>  since qxmpp/1.0.0-5.
>
> Please go ahead.

Uploaded.

Thanks

-- 
Boris

Bug#978940: ITP: golang-github-d2r2-go-bsbmp -- interact with Bosch Sensortec BMP180/BMP280/BME280/BMP388 sensors via I2C-bus (library)

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: golang-github-d2r2-go-bsbmp
  Version : 0.0~git20190515.3b4b3ae-1
  Upstream Author : Denis Dyakov
* URL : https://github.com/d2r2/go-bsbmp
* License : Expat
  Programming Lang: Go
  Description : interact with Bosch Sensortec BMP180/BMP280/BME280/BMP388 
sensors via I2C-bus (library)

Digital humidity and pressure sensors from Bosch Sensortec are popular
among Arduino and Raspberry Pi developers. These sensors are compact and
quite accurately measuring, working via Inter-Integrated Circuit (I2C)
bus interface.

This library is written in Go programming language for Raspberry Pi and
counterparts. It makes all necessary i2c-bus interactions and values
computation to gives you the temperature and atmospheric pressure
values. BME sensors also provide relative humidity values.

Following sensors from Bosch Sensortec are supported:
  * BMP180 (pressure and temperature)
  * BMP280 (pressure and temperature)
  * BME280 (humidity, pressure, and temperature)
  * BMP388 (pressure and temperature)

I am working on a Prometheus sensors exporter which is using go-bsbmp
and go-sht3x. I will maintain these libraries as part of the Debian Go
Packaging Team.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#978935: [Pkg-utopia-maintainers] Bug#978935: network-manager: disconnect on upgrade

[Michael Biebl]

Control: tags -1 + moreinfo

Am 31.12.20 um 18:37 schrieb Vincent Lefevre:

Package: network-manager
Version: 1.28.0-1+b1
Severity: serious

During the upgrade, network-manager disconnected, so that I completely
lost the network connection. Fortunately, I was in front of my machine,
but this means that a remote upgrade can make the machine unavailable!


I might be mistaken, but afaics, this has always been the case for WiFi 
connections (as it is not really possible to carry the state across 
daemon reexecs). Are you saying this is not the case?

Ethernet connections should not be torn down on a daemon stop.

A remote upgrade over a WiFi connection without a side-band is not 
something I would encourage.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976232: ITP: ustreamer -- Lightweight and fast MJPG-HTTP streamer

[Sam Reed]

Hey Reinhard,

I'm not currently actively working on it, no. But it's mostly ready to go (I 
think, anyway. I have had another friend give some feeback) - 
https://salsa.debian.org/reedy/ustreamer

I'm currently waiting on the next release of ustreamer, as it brings in a 
couple of changes I upstreamed; fixing some typos and adding a manpage (both of 
which the Debian packaging scripts flag in different ways), rather than just 
having them exist in the Debian packaging repo - 
https://github.com/pikvm/ustreamer/commits?author=reedy

I have just filed https://github.com/pikvm/ustreamer/issues/74 to ask when that 
might be.

Thanks though for the offer. Please feel free to look over my packaging repo 
and let me know if you've got feedback.


Sam

> On 31/12/2020 18:35 Reinhard Tartler  wrote:
> 
> 
> Hi Sam,
> 
> On Tue, Dec 1, 2020 at 5:06 PM Sam Reed  wrote:
> > Package: wnpp
> >  Severity: wishlist
> >  Owner: Sam Reed 
> >  
> >  * Package name : ustreamer
> >  Version : 2.2
> >  Upstream Author : Maxim Devaev 
> >  * URL : https://pikvm.org/
> >  * License : GPL-3
> >  Programming Lang: C
> >  Description : Lightweight and fast MJPG-HTTP streamer
> >  
> >  µStreamer is a lightweight and very quick server to stream MJPG
> >  videofrom any V4L2 device to the network. All new browsers have
> >  native support of this video format, as well as most video
> >  players such as mplayer, VLC etc. µStreamer is a part of the
> >  Pi-KVM project designed to stream VGA and HDMI screencast
> >  hardware data with the highest resolution and FPS possible.
> >  
> >  ustreamer is used as part of Pi-KVM (a Raspberry Pi based IP
> >  KVM), to stream video to a web browser.
> >  
> >  It is intended to get this packaged so it will eventually be
> >  available in Raspberry Pi OS (and other Debian derivatives),
> >  allowing Pi-KVM to be used on those OS rather than using Arch.
> >  
> >  I currently use it as part of the Pi-KVM project, and
> >  hopefully when it is packaged, also use it as part of
> >  OctoPrint and the OctoPi OS (version of Raspberry Pi OS).
> >  
> >  MJPG-Streamer is alternative software providing the same
> >  function, however it is currently not packaged for Debian
> >  either, though it is available in a snap.
> >  
> >  I'm happy to work on packaging/maintaining it in future,
> >  and I believe the upstream Author (Maxim) may be interested
> >  too, but is currently busy with other work, hence me packaging
> >  it.
> 
> Are you still working on the package? I'm happy to review and upload the 
> package for you, if that was helpful to you.
> 
> 
> 
> -- 
> 
> regards,
>  Reinhard

Bug#978939: zeekctl: missing Breaks+Replaces: broctl (<< 2)

[Andreas Beckmann]

Package: zeekctl
Version: 2.2.0+ds1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../zeekctl_2.2.0+ds1-1_all.deb ...
  Unpacking zeekctl (2.2.0+ds1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/zeekctl_2.2.0+ds1-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/broctl', which is also in package broctl 1.4-1
  Errors were encountered while processing:
   /var/cache/apt/archives/zeekctl_2.2.0+ds1-1_all.deb


cheers,

Andreas


broctl=1.4-1_zeekctl=2.2.0+ds1-1.log.gz
Description: application/gzip

Bug#976113: Bug#954823: Sponsorship of hydrogen

[Nicholas D Steeves]

Hi Ross,

Updated package upload to mentors, and pushed to the WIP branch called
rfs-976113-rebase.  I've of course merged this to master locally, so
that the debian release tag will exist on the correct branch.  Let me
know if there's anything else you'd like to see.  Other than that, reply
follows inline:

Ross Gammon  writes:

> On 30/12/2020 00:55, Nicholas D Steeves wrote:
>> Ross Gammon  writes:

> OK - I think we are a bit too close to the next Debian release to be
> making things complicated. Maintaining a library complicates upgrades to
> new versions if transitions are required, and can be problematic if the
> the ABI is not stable. I don't know how stable the hydrogen library is.
> Why don't we just stick to how it was structured before it was removed?
> That way users of Hydrogen in making music (like me) can just use the
> application like they used to.
>

Done.

> We have to go through the NEW queue to get hydrogen into the next
> release, so making the ftp-master review as simple as possible (with a
> rock solid copyright file) is the least risky approach.
>

Copyright should be good.  I did at least three full reviews in 2020,
including one just now.

> I think the main reason for splitting stuff out into a *-data package is
> to split the architecture dependent files from the architecture
> independent files. When looking at the contents of the old hydrogen
> package, you could question some of the decisions between the -data and
> -doc packages.
>

Ah, yes that makes sense :-)

> Maybe after the release we can think about helping developers of
> potential plugins, and moving files around between packages? That is
> unless the previous structural decisions contributed to any bugs!
>
> We can always backport new versions for users of Debian stable after the
> release if there is a demand.
>

Agreed, and I like your plan for this case.


Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#675076: dd ignores SIGUSR1 to output statistics

[Michael Musenbrock]

Package: coreutils
Version: 8.32-4+b1
Followup-For: Bug #675076

Hi,

I experience the same issue on a quite newly installed system.

> kill -USR1 
does not output anything. Only at the end of the dd run I get the 'normal' 
summary.

> $ debsums coreutils | grep dd
> /bin/dd   
> OK
> /usr/share/man/man1/dd.1.gz   
> OK

I experienced this on another of my systems as well in the past, I will verify 
the
issue on the other systems in the next days.

regards (and happy new year) m

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (504, 'unstable'), (503, 'testing'), (502, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-trunk-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-9
ii  libattr1 1:2.4.48-6
ii  libc62.31-6
ii  libgmp10 2:6.2.1+dfsg-1
ii  libselinux1  3.1-2+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Thu, Dec 31, 2020 at 9:26 AM Antonio Terceiro 
wrote:

> Control: done -1 2.2.1+dfsg1-1
>
> On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> > Can you please try the podman version in experimental? I believe what you
> > describe (the shortnames) should work with version 2.2 just fine thanks
> to
> > the shortnames.conf file.
>
> Ah yes the version in exprimental does fix this. Thanks!
>
> > Also, what version of podman did you use in Fedora for this test?
>
> [terceiro@fedora ~]$ podman --version
> podman version 2.2.1
>

As I thought. Experimental has version 2.2, unstable/testing currently 2.1
What you are asking for is one (maybe the?) major new feature introduced in
2.2.0.


-- 
regards,
Reinhard

Bug#977705: installation bug report - no hdd detected!

[Holger Wansing]

Hi,

Jacek Czerniawski  wrote:
> 
> Graphic installer used. HDD not detected, list of drivers for manual
> selection appears. Haven't tried all of them but tried a few without
> success. Installer works fine with Buster release.

Same here on a Thinkpad T60.

Interestingly, when I plug in a second usb stick or my usb backup harddisk
(it seems that any usb data storage does the trick), the built-in harddisk 
gets detected!

Removing the second usb storage makes the build-in harddisk disappear again
here!!

(Found this out, because I was prompted for firmware for my wlan module.)


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#976232: ITP: ustreamer -- Lightweight and fast MJPG-HTTP streamer

[Reinhard Tartler]

Hi Sam,

On Tue, Dec 1, 2020 at 5:06 PM Sam Reed  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Sam Reed 
>
> * Package name: ustreamer
>   Version : 2.2
>   Upstream Author : Maxim Devaev 
> * URL : https://pikvm.org/
> * License : GPL-3
>   Programming Lang: C
>   Description : Lightweight and fast MJPG-HTTP streamer
>
> µStreamer is a lightweight and very quick server to stream MJPG
> videofrom any V4L2 device to the network. All new browsers have
> native support of this video format, as well as most video
> players such as mplayer, VLC etc. µStreamer is a part of the
> Pi-KVM project designed to stream VGA and HDMI screencast
> hardware data with the highest resolution and FPS possible.
>
> ustreamer is used as part of Pi-KVM (a Raspberry Pi based IP
> KVM), to stream video to a web browser.
>
> It is intended to get this packaged so it will eventually be
> available in Raspberry Pi OS (and other Debian derivatives),
> allowing Pi-KVM to be used on those OS rather than using Arch.
>
> I currently use it as part of the Pi-KVM project, and
> hopefully when it is packaged, also use it as part of
> OctoPrint and the OctoPi OS (version of Raspberry Pi OS).
>
> MJPG-Streamer is alternative software providing the same
> function, however it is currently not packaged for Debian
> either, though it is available in a snap.
>
> I'm happy to work on packaging/maintaining it in future,
> and I believe the upstream Author (Maxim) may be interested
> too, but is currently busy with other work, hence me packaging
> it.
>

Are you still working on the package? I'm happy to review and upload the
package for you, if that was helpful to you.


-- 
regards,
Reinhard

Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3

[Colin Watson]

On Thu, Dec 31, 2020 at 04:46:43PM +, Adam D. Barratt wrote:
> I do have a _slight_ concern that someone with a crazily small /boot
> will end up being broken by the new backup code, but agree that it is
> better than the current situation.

It's true that this is a possibility.  I'd like to add that the total
size of /boot/grub/ at least on the buster system I have handy here is
~12MB, about a third of the size of an initramfs - so any system that
close to the wire will probably be in trouble soon anyway.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#978938: ITP: golang-github-d2r2-go-i2c -- I2C-bus interaction of peripheral sensors with single-board computers (library)

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: golang-github-d2r2-go-i2c
  Version : 0.0~git20191123.73a8a79-1
  Upstream Author : Denis Dyakov
* URL : https://github.com/d2r2/go-i2c
* License : Expat
  Programming Lang: Go
  Description : I2C-bus interaction of peripheral sensors with single-board 
computers (library)

This library written in Go is intended to activate and interact with the
I2C (Inter-Integrated Circuit) bus by reading and writing data. The i2c
library is a starting point to interact with various peripheral devices
and sensors for use on embedded Linux devices.

Following libraries for the listed devices and sensors use this i2c
library:
  * go-hd44780: Liquid-crystal display driven by Hitachi HD44780 IC
  * go-bsbmp: BMP180/BMP280/BME280 temperature and pressure sensors
  * go-aosong: DHT12/AM2320 humidity and temperature sensors
  * go-si7021: Si7021 relative humidity and temperature sensor
  * go-sht3x: SHT3x humidity and temperature sensor
  * go-vl53l0x: VL53L0X time-of-flight ranging sensor
  * go-bh1750: BH1750 ambient light sensor
  * go-mpl3115a2: MPL3115A2 pressure and temperature sensor

I am working on a Prometheus sensors exporter which is using go-bsbmp,
go-sht3x and therefore need go-i2c. I will maintain these libraries as
part of the Debian Go Packaging Team.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#978812: fim: ftbfs with autoconf 2.70

[Rafael Laboissière]

Control: tags -1 + unreproducible
Control: tags -1 + moreinfo

Hello Matthias,

Unfortunately, I cannot replicate this bug in a Debian unstable system 
with autoconf 2.70.  Autoreconf does issue a lot of warnings, but the 
package builds fine for me.  I am attaching the build log to this 
message.  Is there anything special with your chroot that is 
triggering the bug ?


Best regards,

Rafael Laboissière

* Matthias Klose  [2020-12-31 14:27]:


 Package: src:fim
 Version: 0.5.3-4
 Severity: normal
 Tags: sid bookworm
 User: d...@debian.org
 Usertags: ftbfs-ac270

 [This bug report is not targeted to the upcoming bullseye release]

 The package fails to build in a test rebuild on at least amd64 with
 autoconf 2.70, but succeeds to build with autoconf 2.69. The
 severity of this report will be raised before the bookworm release,
 so nothing has to be done for the bullseye release.

 The full build log can be found at:
 http://qa-logs.debian.net/2020/09/26.ac270/fim_0.5.3-4_unstable_ac270.log
 The last lines of the build log are at the end of this report.

 To build with autoconf 2.70, please install the autoconf package from
 experimental:  apt-get -t=experimental install autoconf

 [...]
 dpkg-source: info: unpacking fim_0.5.3-4.debian.tar.xz
 dpkg-source: info: using patch list from debian/patches/series
 dpkg-source: info: applying compile-with-gcc-9.patch
 dpkg-source: info: applying reproducible-build.patch
 dpkg-source: info: applying compile-with-gcc-10.patch

 Check disk space
 
 
 Sufficient free space for build
 
 User Environment

 
 
 APT_CONFIG=/var/lib/sbuild/apt.conf

 HOME=/sbuild-nonexistent
 LANG=C.UTF-8
 LC_ALL=C.UTF-8
 LOGNAME=user42
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 SCHROOT_ALIAS_NAME=unstable
 SCHROOT_CHROOT_NAME=sid-amd64-sbuild
 SCHROOT_COMMAND=env
 SCHROOT_GID=1001
 SCHROOT_GROUP=user42
 SCHROOT_SESSION_ID=sid-amd64-sbuild-e8b5a736-c604-44d9-a5ad-2ed97c9ced1a
 SCHROOT_UID=1001
 SCHROOT_USER=user42
 SHELL=/bin/sh
 USER=user42
 
 dpkg-buildpackage

 -
 
 Command: dpkg-buildpackage -us -uc -sa -rfakeroot

 dpkg-buildpackage: info: source package fim
 dpkg-buildpackage: info: source version 0.5.3-4
 dpkg-buildpackage: info: source distribution unstable
 dpkg-buildpackage: info: source changed by Rafael Laboissière 

 dpkg-source --before-build .
 dpkg-buildpackage: info: host architecture amd64
 dpkg-source: info: using options from fim-0.5.3/debian/source/options: 
--extend-diff-ignore=src/version\.h|config\.log|lex\.yy\.c|src/config\.h\.in|INSTALL|install-sh|aclocal\.m4|Makefile\.in|configure|missing|scripts/Makefile\.in|distros/Makefile\.in|doc/fimrc\.man\.html|doc/FIM\.html|doc/fimgs\.man\.html|doc/Makefile\.in|doc/fim\.man\.html|src/Makefile\.in
 debian/rules clean
 dh clean
   dh_clean
 dpkg-source -b .
 dpkg-source: warning: cannot import key in 
fim-0.5.3/debian/upstream/signing-key.asc since GnuPG is not installed
 dpkg-source: info: using options from fim-0.5.3/debian/source/options: 
--extend-diff-ignore=src/version\.h|config\.log|lex\.yy\.c|src/config\.h\.in|INSTALL|install-sh|aclocal\.m4|Makefile\.in|configure|missing|scripts/Makefile\.in|distros/Makefile\.in|doc/fimrc\.man\.html|doc/FIM\.html|doc/fimgs\.man\.html|doc/Makefile\.in|doc/fim\.man\.html|src/Makefile\.in
 dpkg-source: info: using source format '3.0 (quilt)'
 dpkg-source: info: building fim using existing ./fim_0.5.3.orig.tar.gz
 dpkg-source: info: building fim using existing ./fim_0.5.3.orig.tar.gz.asc
 gpgv: Signature made Sat Jul 29 09:11:52 2017 UTC
 gpgv:using DSA key E0E669C8EF1258B8
 gpgv: Can't check signature: No public key
 dpkg-source: warning: failed to verify signature on ./fim_0.5.3.orig.tar.gz.asc
 dpkg-source: info: using patch list from debian/patches/series
 dpkg-source: info: building fim in fim_0.5.3-4.debian.tar.xz
 dpkg-source: info: building fim in fim_0.5.3-4.dsc
 debian/rules binary
 dh binary
   dh_update_autotools_config
   dh_autoreconf
 sh: 1: svnversion: not found
 /usr/bin/m4:configure.ac:15: Warning: excess arguments to builtin `m4_define' 
ignored
 autom4te: error: /usr/bin/m4 failed with exit status: 1
 aclocal: error: echo failed with exit status: 1
 autoreconf: error: aclocal failed with exit status: 1
 dh_autoreconf: error: autoreconf -f -i returned exit code 1
 make: *** [debian/rules:8: binary] Error 25
 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package fim
dpkg-buildpackage: info: source version 0.5.3-4
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Rafael Laboissière 

 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: using options from fim/debian/source/options: 

Bug#978937: RFP: acpilight -- backward-compatibile replacement for xbacklight that uses the ACPI interface

[David Bremner]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: acpilight
  Version : 1.2
  Upstream Author : Yuri D'Elia 
* URL : https://gitlab.com/wavexx/acpilight
* License : GPL3
  Programming Lang: python3
  Description : backward-compatibile replacement for xbacklight that uses 
the ACPI interface

- From upstream:

On some modern laptops "XRandR" might lack the ability to set the display 
brightness. This capability was moved/unified to the kernel's ACPI interface, 
via /sys/class/backlight/.

"acpilight" provides a drop-in replacement for the xbacklight command that uses 
the ACPI interface instead of "XRandR", allowing old scripts to run. As a 
result, xbacklight can subsequently be used also from the console and Wayland 
(X11 is not used at all).

When paired with the ddcci-backlight kernel module, the backlight of most 
professional external monitors can be controlled as well.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl/uE2AACgkQA0U5G1Wq
FSFvDhAAoAJ9MCsyU5GUeQmSPovqToKG4GqzhT90edCG8OQEK1vCX0+mzLEgEvHU
SziCsnzKCfOJTDPbUAQlyaM1uajjCyd4WNlkQImYohDrlbkhm40+EOY54IJaueOO
jCKzwaDHI8ltlqCDzE1qfaRV352/pT4YSjnkV3DwBXj9TgRQ1a+FZI3vReoojO+O
f+twXtuLiK9nAMJUnyBIXUdkiodXrLz313PjEV1TW9n13GuoFHiryB9N8CsbjcPV
yhQCqHwZnbm4+NEe/6xC/aRnml2O2FyyH4pEJjNACLz0ILpGwepv2Kc5TzYP0y4q
Micf1lazY2Jl3NLbY3bUr2nEts/uSskPvhJzdvZ/QU7z2/8KSsDalK+wdHgKO+xr
rWFVxodD/Vokh/kEAraGuiy8T16+TXLPrX7vbnmqOU5UvWdTzbBbnnp15W2jQUtP
hsokgQmn06BeHlFmOGNw61IDBkpIS9xxJkyARUDyLbSu1zU/fMvQQT/SwQmMCGMe
kxmSB1GjLet6kCYhLppfQHNnirwHuLLVjjV17gNOnRgi87EB80vTp98znnaZzyg5
0jmODG2PDSdrowcxuRfyqqEpXq0XLJzgOnRsRNnrvYSJRbO2rXVmSFefaYu4sCYZ
lXpgHZvvEm5pP/y+IaZKqwUL6MmOMFVkSktML389CXd6OBMFcWg=
=63ZW
-END PGP SIGNATURE-

Bug#978936: darktable: FTBFS on arm64

[David Bremner]

Package: darktable
Version: 3.4.0-1
Severity: serious
Tags: upstream
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: -1 forwarded https://github.com/darktable-org/darktable/issues/7583

The new release requires xmmintrin.h in several places, and that
include file is only present (in Debian) on amd64.


https://buildd.debian.org/status/fetch.php?pkg=darktable=arm64=3.4.0-1=1608929069=0


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

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
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
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages darktable depends on:
ii  libc62.31-6
ii  libcairo21.16.0-4
ii  libcolord-gtk1   0.1.26-2
ii  libcolord2   1.4.4-2
ii  libcups2 2.3.3op1-3
ii  libcurl3-gnutls  7.72.0-1
ii  libexiv2-27  0.27.3-3
ii  libgcc-s110.2.1-3
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgomp1 10.2.1-3
ii  libgphoto2-6 2.5.26-2
ii  libgphoto2-port122.5.26-2
ii  libgraphicsmagick-q16-3  1.4+really1.3.36-1
ii  libgtk-3-0   3.24.24-1
ii  libilmbase25 2.5.3-2
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libjson-glib-1.0-0   1.6.0-2
ii  liblcms2-2   2.9-4+b1
ii  liblensfun1  0.3.2-5
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libopenexr25 2.5.3-2
ii  libopenjp2-7 2.3.1-1
ii  libosmgpsmap-1.0-1   1.1.0-7
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpugixml1v51.11.4-1
ii  librsvg2-2   2.50.2+dfsg-1
ii  libsecret-1-00.20.4-1
ii  libsoup2.4-1 2.72.0-2
ii  libsqlite3-0 3.34.0-1
ii  libstdc++6   10.2.1-3
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2+b1
ii  libx11-6 2:1.6.12-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  zlib1g   1:1.2.11.dfsg-2

darktable recommends no packages.

darktable suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl/uD6kACgkQA0U5G1Wq
FSFD8A/+KlBt0LMrGwiDWI/p56Gcdg5EMMbPMG7G7E1LJBBMSyQ5EhEUjo+TQRhR
HRBzfEKPgkYJu+93XvDRVeITJtq9xIL1KTISWgcQRTIC71SDDHGtG7nvJTLVK/fD
7+PnVI3hTPoyNmg2WAK8PtX/TbsOcGNIsx3h173/vonGpL7PUMkhJOWNhH4u/OB8
R7NgusGmji5ylnaPFVNYHII0Ig4r2pBQa7crNiBbCCS7gLMV/BZbp+zbcsnFyLsR
Iynu2+I0S0lCHIEbMblwwz68eHoC0cwaJQ6ypcansMT/4v8pYWnByc9U9qZfc8yf
g4ZhQKBxofq3GRFY/k+CguIDXub1jBP23WWM7lWZgRL/l0BYQDybPvJ7kqCevDM3
xdJNA2/XZA7M6e0VlNR7V4wuuSaThhUusqE+FZebS2yfCfV2n4QdW74vBDV+E7dP
DqexnuS5Xig0lC/PZ5Eg49ZN4k65Qpf945UMjbHzSKNa45m4+wJLigxdvdMXBN0H
E0cdYwGecL0WAlzZNUtfLLEYG0zyZxijrWHV3DjysDf3AnxWcuS+3fFoy/aR/oNw
niQFX+M21HLUaqpJBTBs3xCZWMvmMK6vbETuWqEzSR18HDKIXnuTCkpNsZ23BnQ7
5OrPfb2eZZUWkfg9fhFS6lgv6Ysk/Liv7FJ9YVrR4V7XKx7m6Ow=
=HiaZ
-END PGP SIGNATURE-

Bug#978739: chardet: Upgrading python3-chardet breaks many packages

[Daniele Tricoli]

Hello Sebastiaan,

On Thu, Dec 31, 2020 at 04:28:40PM +0100, Sebastiaan Couwenberg wrote:
> Thanks for quickly acting on this, but the problem is not limited to
> python3-requests. Several other reverse dependencies need to be updated
> for the new chardet as well. The autopkgtest failures include some of them:
> 
>  https://qa.debian.org/excuses.php?package=chardet

Oh, sorry my fault, I confused this bug for one of the bugs opened for requests.
Sorry for the noise and thanks for reopening!

Cheers and happy new year!

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org


signature.asc
Description: PGP signature

Bug#978935: network-manager: disconnect on upgrade

[Vincent Lefevre]

Package: network-manager
Version: 1.28.0-1+b1
Severity: serious

During the upgrade, network-manager disconnected, so that I completely
lost the network connection. Fortunately, I was in front of my machine,
but this means that a remote upgrade can make the machine unavailable!

In the journalctl output:

[...]
Dec 31 18:23:56 zira systemd[1]: Reloading.
Dec 31 18:23:56 zira systemd-fstab-generator[201684]: Swap unit generation 
disabled on kernel command line, ignoring fstab swap entry for 
/dev/mapper/zira--vg-swap_1.
Dec 31 18:23:56 zira systemd-fstab-generator[201684]: Failed to create unit 
file /run/systemd/generator/media-mem.mount, as it already exists. Duplicate 
entry in /etc/fstab?
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/dictd' lacks a native systemd unit file. Automatically generating 
a unit file for compatibility. Please update package to include a native 
systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/gpm' lacks a native systemd unit file. Automatically generating a 
unit file for compatibility. Please update package to include a native systemd 
unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/netplug' lacks a native systemd unit file. Automatically 
generating a unit file for compatibility. Please update package to include a 
native systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/mcelog' lacks a native systemd unit file. Automatically generating 
a unit file for compatibility. Please update package to include a native 
systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/shellinabox' lacks a native systemd unit file. Automatically 
generating a unit file for compatibility. Please update package to include a 
native systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/monit' lacks a native systemd unit file. Automatically generating 
a unit file for compatibility. Please update package to include a native 
systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/loadcpufreq' lacks a native systemd unit file. Automatically 
generating a unit file for compatibility. Please update package to include a 
native systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201693]: SysV service 
'/etc/init.d/cpufrequtils' lacks a native systemd unit file. Automatically 
generating a unit file for compatibility. Please update package to include a 
native systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd[201676]: 
/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 
1.
Dec 31 18:23:56 zira systemd[1]: /lib/systemd/system/smartmontools.service:10: 
Standard output type syslog is obsolete, automatically updating to journal. 
Please update your unit file, and consider removing the setting altogether.
Dec 31 18:23:56 zira systemd[1]: Reloading.
Dec 31 18:23:56 zira systemd-fstab-generator[201707]: Swap unit generation 
disabled on kernel command line, ignoring fstab swap entry for 
/dev/mapper/zira--vg-swap_1.
Dec 31 18:23:56 zira systemd-fstab-generator[201707]: Failed to create unit 
file /run/systemd/generator/media-mem.mount, as it already exists. Duplicate 
entry in /etc/fstab?
Dec 31 18:23:56 zira systemd-sysv-generator[201716]: SysV service 
'/etc/init.d/dictd' lacks a native systemd unit file. Automatically generating 
a unit file for compatibility. Please update package to include a native 
systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201716]: SysV service 
'/etc/init.d/gpm' lacks a native systemd unit file. Automatically generating a 
unit file for compatibility. Please update package to include a native systemd 
unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201716]: SysV service 
'/etc/init.d/netplug' lacks a native systemd unit file. Automatically 
generating a unit file for compatibility. Please update package to include a 
native systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201716]: SysV service 
'/etc/init.d/mcelog' lacks a native systemd unit file. Automatically generating 
a unit file for compatibility. Please update package to include a native 
systemd unit file, in order to make it more safe and robust.
Dec 31 18:23:56 zira systemd-sysv-generator[201716]: SysV service 
'/etc/init.d/shellinabox' lacks a native systemd unit file. Automatically 

Bug#958853: Updating Anki in Debian - current status

[alberto fuentes]

On Thu, Dec 31, 2020 at 6:14 PM Julian Gilbey  wrote:

> Sorry to not have better news on this front.
>
> Best wishes, and happy new year,
>

Thank you very much for your work!

Also, Im very glad upstream is collaborative with debian efforts

I hate it when the building script downloads random packages and repos in
random commit states. So your effort to make a local build possible is very
much appreciated. It also helps reproducible builds which is a very laudable
goal


Happy new year and besh wishes for you too!

Bug#978772: autogen: ftbfs with autoconf 2.70

[Bruce Korb]

On 12/31/20 7:21 AM, Andreas Metzler wrote:

Hello,

For autogen/experimental (5.19.96) config/std-gnu11.m4 needs to be
updated from gnulib m4/std-gnu11.m4 with
---
a3b3fc85e3e632374811b27cb2111e50fa177e36
2020-12-09 04:06:40
 std-gnu11: Make compatible with Autoconf 2.70.

 * m4/std-gnu11.m4: Disable the entire file if Autoconf >= 2.70 is in
 use.
---

cu Andreas


Andreas,

This means a re-release with current gnulib fixes the issue?

Bug#978157: buster-pu: package iproute2/4.20.0-2+deb10u1

[Luca Boccassi]

On Thu, 31 Dec 2020 at 16:56, Adam D. Barratt  wrote:
>
> Control: tags -1 + confirmed
>
> On Sat, 2020-12-26 at 19:20 +, Luca Boccassi wrote:
> > I would like to do a bugfix upload of iproute2 to buster-proposed-
> > updates. This would be the first upload for this source package, so
> > waiting for feedback before uploading.
> >
> > The version would backport 3 bug fixes, which have been fixed in the
> > latest upstream release, and which were reported on Debian Buster by
> > users. They make some subcommands unusable or downright dangerous.
> >
> > The first two are about fixing invalid json output - these bugs make
> > the affected subcommands output unusable, as consumers need valid
> > formatted json:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961278
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972784
>
> The metadata for #961278 implies that it still affects the package in
> unstable. I assume that's simply an oversight? If so, please add an
> appropriate fixed version, and go ahead with the upload; if not, please
> fix unstable first.
>
> Regards,
>
> Adam

Hi,

Yes it was fixed upstream long before it was reported, so I forgot to
close it. Done now, and uploaded.

Thanks!

Kind regards,
Luca Boccassi

Bug#978932: sympa: webinterface broken after installing 6.2.40~dfsg-1+deb10u1

[Stefan Hornburg (Racke)]

On 12/31/20 5:41 PM, Tobias Frost wrote:
> Package: sympa
> Version: 6.2.40~dfsg-1+deb10u1
> Severity: important
> 
> Dear Maintainer,
> 
> After installation of the security update the web isterface is defunct.
> It still loads the "default" site (here: https://$DOMAIN/wws/) but that also
> the site that will be loaded when selecting an menue entry, for example 
> "Login".
> (IOW, Login not possible as the login form is not presented)
> 
> Downgrading to 6.2.40~dfsg-1 makes it work again.
> 
> Webserver is an nginx instance.
> 
> The only hint I got (could be a red herring) is this in the nginx error log,
> the sympa log is silent… 
> 
> Heres a example of the  nginx one:
> (There are many of those…)
> 
> 2020/12/27 12:13:57 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
> Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value in string ne 
> at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M
> [Sun Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value 
> $remote_addr in string ne at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 
> 408" while reading upstream, client: 80.209.204.233, server: 
> lists.regensburg-repariert.de, request: "GET /wws/reviewbouncing/info 
> HTTP/2.0", upstream: "fastcgi://unix:/run/fcgiwrap.socket:", host: 
> "lists.regensburg-repariert.de"
> 2020/12/27 12:14:21 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
> Dec 27 12:14:21 2020] wwsympa.fcgi: Use of uninitialized value in string ne 
> at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M
> 
> (Those started exactly on Dec 24, after unattende-upgrades pulled in the 
> security update)
> 
> Let me know if I can provide more information…
> 
> Cheers,
> 

Yes, please share the part of your Nginx configuration with regards to Sympa 
and your WWSympa FCGI service setup.
If you use the wwsympa wrapper, please drop it.

Regards
 Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#958853: Updating Anki in Debian - current status

[Julian Gilbey]

Dear all,

I thought I would let you know about the current status of Anki and
its hopes of getting into Debian.

The upstream maintainers started 2020 by incorporating a Rust library
into the package, which increased the complexity of the Debian
maintenance process by an order of magnitude: it is now necessary to
work with the Rust team to ensure that all the necessary crates are in
sync, which is quite challenging!

But the year has gotten even more challenging: they have now switched
to using Bazel as their build system, and are also using a bunch of
Node.js libraries (most notably TypeScript).  Unfortunately, Bazel is
only just in the process of being packaged for Debian, and Bazel's
model is to download everything it needs from the internet.  So Bazel
will need some significant work, joint between the Debian team and
upstream, to modify it to allow for local builds.  This is not going
to happen in time for the bullseye release, but it should happen at
some point during the following release cycle (bullseye+1).

So for the time being, we will have to stick with anki 2.1.15 in
Debian.  If you are deperate to use a newer version, upstream does
provide pre-built binaries, or you can compile it yourself.

Sorry to not have better news on this front.

Best wishes, and happy new year,

   Julian

Bug#977782: buster-pu: package postsrsd/1.5-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-12-20 at 20:48 +0100, Oxan van Leeuwen wrote:
> Upstream recently discovered a potential remote denial-of-service
> attack in  postsrsd (CVE-2020-35573) [1]. Fortunately, this issue is
> currently not  exploitable in Debian due to gcc optimizing the
> problematic loop away. Thus, the  security has decided not to issue a
> DSA [2], but instead suggested to fix it 
> through a stable update.
> 

Please go ahead.

Regards,

Adam

Bug#978934: RFS: streamlink/2.0.0-1~bpo10+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
buster-backports repository.

 * Package name: streamlink
   Version : 2.0.0-1~bpo10+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from various 
websites
  python3-streamlink-doc - CLI for extracting video streams from various 
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to a 
video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_2.0.0-1~bpo10+1.dsc

More information about streamlink can be obtained at
https://streamlink.github.io/

Changes since the last upload to buster-backports:
streamlink (2.0.0-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.
  * d/patches: remove sphinx 3.0 requirement as it is not available in stable

 -- Alexis Murzeau   Thu, 31 Dec 2020 17:57:09 +0100

streamlink (2.0.0-1) unstable; urgency=medium

  * New upstream version 2.0.0
  * debian/*: update patches, control, tests to replace new furo theme
  * debian/patches: update patches
  * examples: use python3 interpreter instead of python
  * Bump Standards-Version to 4.5.1 (no changes)
  * debian/watch: removing repacking as not needed anymore
  * Add patch to use icons from font awesome 4 instead of font awesome 5

 -- Alexis Murzeau   Fri, 25 Dec 2020 23:28:50 +0100

Differences from testing package (2.0.0-1):
  * Update d/README.source for buster-backports
  * Revert docs-use-recommonmark-as-an-extension (upstream applied) patch as
Buster has recommonmark 0.4.0 and this patch requires recommonmark 0.5.0+.
  * d/patches: remove sphinx 3.0 requirement as it is not available in stable

Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#978091: buster-pu: package geoclue-2.0/2.5.2-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-12-25 at 22:29 +0100, Laurent Bigonville wrote:
> There are currently several issues with geoclue-2.0 in debian buster:
> 
> 1) The daemon is not respecting the user choice to not query the
> location, that could be seen as a privacy/GDPR breach as it contacts
> MLS
> and sends data (ESSID,..) to them without explicit approval. This is
> only happening for "system" (non-flatpak) applications.
> 
> 2) The indicator (in the gnome-shell,...) showing that geoclue is
> active
> and looking for the location of the computer is never turned on.
> 
> 3) This version of geoclue is using a generic Mozilla Location
> service
> API key, Mozilla would like us to use a dedicated key for geoclue in
> debian: https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/136
> 

Please go ahead.

Regards,

Adam

Bug#977895: buster-pu: package slirp/1:1.0.17-8

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-12-22 at 13:31 +, Thorsten Alteholz wrote:
> The attached debdiff for slirp fixes CVE-2020-8608 and CVE-2020-7039
> in  Buster.
> 
> Both are marked as no-dsa by the security team.
> 

Please go ahead.

Regards,

Adam

Bug#943676: Re: Sponsor request for 'Open Surge'

[Alexandre Martins]

Hi Bruno,

Thank you for your reply.

By playing Johan's songs in our game, we are paying homage to an
artist who has contributed greatly to our project.

By the way, Johan himself has uploaded that very same music to
opengameart.org, this time under the CC-BY-SA 3.0:
https://opengameart.org/content/theme-from-open-surge

Johan can no longer speak on this plane, but I can speak for him. Even
though he said we could use his music under the public domain, I think
it's more fair if we used it under the CC-BY-SA 3.0 instead. We begin
to pick a license that requires attribution if his music is used
elsewhere, as a way to honor his work. The copyright file of the
Debian package could reflect that choice.

Looking forward to seeing Open Surge in Debian,
Alexandre

Em qui., 31 de dez. de 2020 às 02:36, Bruno Kleinert
 escreveu:
>
> Hi Martin,
>
> Am Mittwoch, dem 30.12.2020 um 15:02 -0300 schrieb Alexandre Martins:
>
> Hi. Upstream here.
>
>
> From what I've seen in Open Surge it seems this is another example of 
> upstream copying random files from the web and pretend to have the permission 
> to create derivate works from them and redistribute them
>
>
> Let me clarify a few things. We never "copy random files from the
>
> web". The "copyright issue" you have raised is not valid.
>
>
> Johan Brodd (aka jobromedia) has created the song Minds Wide Open
>
> (theme.ogg) for Open Surge. He joined our project years ago and
>
> contributed with his musical talent.
>
>
> Free content is very important to our project and I talk to artists
>
> about it. I have talked to Johan about his music and he has agreed to
>
> release it under the public domain. Unfortunately, Johan passed away a
>
> few years back (we have even included a RIP in our credits screen).
>
>
> While not directly related to musics/theme.ogg, in a forum thread
>
> dated from December 2011 I explain to Johan about free content and
>
> then he decides to release his files under the public domain:
>
> http://forum.opensurge2d.org/viewtopic.php?id=1114
>
>
> Regarding musics/theme.ogg specifically, I invite you to take a look
>
> at a screenshot of a private conversation between me and Johan, where
>
> he expresses gratitude for having that music included in the game:
>
> http://forum.opensurge2d.org/misc/jobro_theme.png He is a deceased man
>
> now, but he has made that music for Open Surge, and it's free. He
>
> cared and he has provided great free music to our project. The
>
> inference that our project "copies random files from the web and
>
> pretend to have permission" sounds disrespectful to me and to
>
> everybody who has contributed content.
>
>
> Thanks for providing the links. From 
> https://forum.opensurge2d.org/viewtopic.php?pid=8700#p8700 "[…] I set all my 
> files to public domain now […]" is the crucial piece of information. I 
> consider it worthy to document that within the distribution of the game. 
> Other FLOSS distributions, e.g., fedora, also benefit from clear copyright 
> and license documentation.
>
>
> Let me also clarify that our C source code is released under the
>
> GPLv3, but our artwork is mostly under the CC-BY 3.0. We also have a
>
> few files under the public domain and under the CC-BY-SA 3.0 (check
>
> our credits screen). In addition, we have a scripting system called
>
> SurgeScript inside the game; scripts written in SurgeScript (.ss
>
> files) are released under the MIT license.
>
>
> We have never re-licensed any CC-BY-SA 3.0 content to the GPLv3.
>
> Artwork is not code. Years ago I read about a claimed incompatibility
>
> between the CC-BY-SA and the GPL, but I have learned since that this
>
> doesn't hold. My understanding is that they are compatible and can be
>
> mixed in a game. The popular SuperTux mixes CC-BY-SA artwork with GPL
>
> code, as can be seen in their README
>
> https://github.com/SuperTux/supertux
>
>
> My apologies, the re-licensing was something I misunderstood from Carlos. For 
> a Debian package it's required to document all respective copyright holders 
> and respective licenses in file /usr/share/doc//copyright.
>
> That file's content must be carefully gathered and verified to avoid any 
> possibilities of copyright infringements or license violations by Debian as 
> we redistribute the work and must make sure to have the permission to do so. 
> That's why me and sure many other Debian Developers are keen on clear and 
> unambiguous copyright and licensing documentation of upstream work.
>
> To get an idea of what this file looks like, take a look at out 
> work-in-progess here: 
> https://salsa.debian.org/games-team/opensurge/-/blob/debian/master/debian/copyright
>
> Btw. in licenses/ there seems to be 
> https://creativecommons.org/licenses/by-sa/3.0/legalcode.txt missing for the 
> CC-BY-SA-3.0 licensed content.
>
>
> I hope this sorts it out. If you find any issues, I'm open and willing
>
> to help. I too would like to see our project in Debian. What has been
>
> claimed, however, is a 

Bug#977172: buster-pu: package qxmpp/1.0.0-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-12-12 at 05:04 +0300, Boris Pek wrote:
> I would like to push a fix for potential SEGFAULT on connection error
> in qxmpp library. Proposed patch is well tested in Debian unstable
> since qxmpp/1.0.0-5.
> 

Please go ahead.

Regards,

Adam

Bug#978933: node-rollup-plugin-babel: drop legacy plugin for bullseye

[Pirate Praveen]

Package: node-rollup-plugin-babel
Version: 5.2.1+repack+~4.4.0-2
Severity: important

I think we should try to remove the embedded copy of legacy plugin to 
reduce maintenance for bullseye (similar to how we did node-resolve 
plugin).

Bug#978157: buster-pu: package iproute2/4.20.0-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-12-26 at 19:20 +, Luca Boccassi wrote:
> I would like to do a bugfix upload of iproute2 to buster-proposed-
> updates. This would be the first upload for this source package, so
> waiting for feedback before uploading.
> 
> The version would backport 3 bug fixes, which have been fixed in the
> latest upstream release, and which were reported on Debian Buster by
> users. They make some subcommands unusable or downright dangerous.
> 
> The first two are about fixing invalid json output - these bugs make
> the affected subcommands output unusable, as consumers need valid
> formatted json:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961278
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972784

The metadata for #961278 implies that it still affects the package in
unstable. I assume that's simply an oversight? If so, please add an
appropriate fixed version, and go ahead with the upload; if not, please
fix unstable first.

Regards,

Adam

Bug#978736: diffutils: Please fix some critical zh_CN translation errors

[Santiago Vila]

> Besides, I'm just wondering what will happen if no repack is involved.
> My thought is that all new .po files will be provided in the debian/
> dir and patch the main source tree before build.

Yes, I have currently a gigantic patch called 03-translations.patch.

There is a potential problem of "unrepresentable sources in the diff"
but this is easily fixed by removing all .gmo files in the clean target.

As I said, I've done this before (at least in recode, a lot of time ago).

Thanks.

Bug#978736: diffutils: Please fix some critical zh_CN translation errors

[Boyuan Yang]

在 2020-12-31星期四的 17:41 +0100，Santiago Vila写道：
> Hmm, no, don't worry. A repack should not be required.
> 
> I plan to do something like this:
> 
> override_dh_auto_build:
>     dh_auto_build
>     $(MAKE) -C po update-gmo
> 
> but I have not tested it yet (I have been updating the Spanish
> translation, which had several errors...).

Just a little hint: if we will be under debhelper v13, using
execute_after_dh_auto_build might be better. In this way we don't need
to worry whether the override of dh_auto_build have missed any
parameters that have possibly passed onto the target.

Besides, I'm just wondering what will happen if no repack is involved.
My thought is that all new .po files will be provided in the debian/
dir and patch the main source tree before build.

Testing should be simple: if a translation change is eventually
reflected in the output binary package, that means it's working.

Thanks,
Boyuan

Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sun, 2020-11-29 at 16:57 +, Colin Watson wrote:
> Following the security updates in July for the "BootHole" set of
> vulnerabilities, we had a number of reports of failures to boot after
> the upgrade.  These weren't fundamentally a new problem, in that
> we've always had a smattering of such reports after GRUB
> kernel/module ABI changes, but it's obviously problematic for
> affected users and it creates a considerable distraction from trying
> to work out whether the security update itself is in fact OK, so I'd
> like to attempt to improve the situation in stable.
> 
> The attached patch is a set of backports from unstable, partly by me
> and partly from similar attempts to improve upgrade reliability in
> Ubuntu, thanks to Dimitri John Ledkov.

Sorry for the delay in picking this back up.

I do have a _slight_ concern that someone with a crazily small /boot
will end up being broken by the new backup code, but agree that it is
better than the current situation.

As grub produces udebs, this will need a KiBi-ack, so tagging and CCing
accordingly.

Regards,

Adam

Bug#969372: Missing After=network-online.target

[Thomas Goirand]

Hi,

The above .service file looks ok, though it's missing this:

After=network-online.target

Cheers,

Thomas Goirand (zigo)

Bug#978759: rsync: --noatime rename breaks rsync with older versions

[Mara Sophie Grosch]

Package: rsync
Version: 3.2.3-3
Severity: important

Dear Maintainer,

I was trying to rsync my server to my desktop as a backup today, running
testing on my desktop and stable on the server. First my script failed
due to --noatime being renamed to --open-noatime, easily fixed. Then it
failed because the server doesn't know about --open-noatime:

  rsync: on remote machine: --open-noatime: unknown option

Easiest "fix" for now seems to be accepting "--noatime" on newer
versions and deprecate it when "--open-noatime" is more widely spread.

Installing rsync from buster-backports on my servers helped as a
workaround for now.

Best regards, thank your for your work and have a happy new year (if
your calendar overflows this night)
Mara Sophie Grosch

(second try, reportbug not configured on this machine x.x)

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-9
ii  libc62.31-6
ii  liblz4-1 1.9.3-1
ii  libpopt0 1.18-2
ii  libssl1.11.1.1i-1
ii  libxxhash0   0.8.0-1
ii  libzstd1 1.4.5+dfsg-4
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-3
ii  openssh-server  1:8.4p1-3
ii  python3 3.9.0-4

-- no debconf information

Bug#978736: diffutils: Please fix some critical zh_CN translation errors

[Santiago Vila]

Hmm, no, don't worry. A repack should not be required.

I plan to do something like this:

override_dh_auto_build:
dh_auto_build
$(MAKE) -C po update-gmo

but I have not tested it yet (I have been updating the Spanish
translation, which had several errors...).

Thanks.

Bug#978932: sympa: webinterface broken after installing 6.2.40~dfsg-1+deb10u1

[Tobias Frost]

Package: sympa
Version: 6.2.40~dfsg-1+deb10u1
Severity: important

Dear Maintainer,

After installation of the security update the web isterface is defunct.
It still loads the "default" site (here: https://$DOMAIN/wws/) but that also
the site that will be loaded when selecting an menue entry, for example "Login".
(IOW, Login not possible as the login form is not presented)

Downgrading to 6.2.40~dfsg-1 makes it work again.

Webserver is an nginx instance.

The only hint I got (could be a red herring) is this in the nginx error log,
the sympa log is silent… 

Heres a example of the  nginx one:
(There are many of those…)

2020/12/27 12:13:57 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M
[Sun Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value 
$remote_addr in string ne at /usr/share/sympa/lib/Sympa/WWW/Session.pm line 
408" while reading upstream, client: 80.209.204.233, server: 
lists.regensburg-repariert.de, request: "GET /wws/reviewbouncing/info 
HTTP/2.0", upstream: "fastcgi://unix:/run/fcgiwrap.socket:", host: 
"lists.regensburg-repariert.de"
2020/12/27 12:14:21 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
Dec 27 12:14:21 2020] wwsympa.fcgi: Use of uninitialized value in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M

(Those started exactly on Dec 24, after unattende-upgrades pulled in the 
security update)

Let me know if I can provide more information…

Cheers,
-- 
tobi

Bug#976891: Unable to find next sigaction in signal chain

[Hans-Christoph Steiner]

Now fastboot and aapt build and link but both report this error:

   Unable to find next sigaction in signal chain

Looks like some dynamically loaded code is missing, the error is in 
sigchainlib/sigchain.cc:


static void lookup_next_symbol(T* output, T wrapper, const char* name) {
  void* sym = dlsym(RTLD_NEXT, name);  // NOLINT glibc triggers 
cert-dcl16-c with RTLD_NEXT.

  if (sym == nullptr) {
sym = dlsym(RTLD_DEFAULT, name);
if (sym == wrapper || sym == sigaction) {
  fatal("Unable to find next %s in signal chain", name);
}
  }
  *output = reinterpret_cast(sym);
}

Bug#978736: diffutils: Please fix some critical zh_CN translation errors

[Boyuan Yang]

Hi,

在 2020-12-31星期四的 17:15 +0100，Santiago Vila写道：
> Simple question: How did you tell the build system that the gmo files
> need to be regenerated? I guess the diff which simply patches the .po
> file might not be enough.
> 
> (I will probably switch to debhelper 13, but without the
> autoconfiguration stuff, which I dislike very much).

I think you got the point. Just made some tests and looks like simply
patch the .po file is indeed not enough. It seems that the translation
toolchain in GNU projects is more complicated than I thought.

The current tarball in Debian source is the released version from
upstream (perhaps generated by "make dist"). If we need to patch the
translation files, a repack that involves downloading po files from TP
website as well as updating .gmo files seems necessary.

Thanks for raising this issue and I'm looking forward to a properly-
patched new diffutils upload.

Regards,
Boyuan Yang

Bug#978749: requests: circular dependency makes requests unbuildable

[Thomas Goirand]

On 12/31/20 4:31 PM, Daniele Tricoli wrote:
> Nowadays for
> urllib3 upstream uses a range of versions, and I take care of both urllib3 and
> requests, so we should not have problems.

Oh, it's very nice that upstream changed their mind, after all of this
time. Thanks for sharing this info. I can clearly remember heated
discussions in the OpenStack list where they really stand on the opinion
they should vendor everything and that everyone suggesting otherwise was
a fool. :)

> Thomas thanks for spotting the missing "nodoc", I will fix also this but not
> with the upload that will close this bug.

Great! :)

> Many thanks, cheers and happy new year!

Happy new year too.

Cheers,

Thomas Goirand (zigo)

Bug#978736: diffutils: Please fix some critical zh_CN translation errors

[Santiago Vila]

Simple question: How did you tell the build system that the gmo files
need to be regenerated? I guess the diff which simply patches the .po
file might not be enough.

(I will probably switch to debhelper 13, but without the
autoconfiguration stuff, which I dislike very much).

Bug#978736: diffutils: Please fix some critical zh_CN translation errors

[Boyuan Yang]

Hi,

在 2020-12-31星期四的 12:06 +0100，Santiago Vila写道：
> Hi.
> 
> I would rather update all diffutils translations and not just the
> Chinese one for which you are the author. After all, I'm also the
> upstream for es.po and a small review would be a good thing.
> 
> Can you confirm that this is the right URL for your translation?
> 
>  
> https://translationproject.org/PO-files/zh_CN/diffutils-3.6.17.zh_CN.po

It would be great if you could use this one. Please verify that the
file has a PO-Revision-Date of 2020-11-19 22:04-0500 or later.

The ideal case would be diffutils releasing a new version. However,
that is unlikely to happen in near future.

> Please note that I will *not* apply the proposed patch (hence, I
> would
> welcome if you could cancel your NMU). Instead, I will wget all the
> translations and put them in place (no need another patch for that,
> I've already done this in the past with some other package).

I will try to cancel it but I'm not sure whether it would work (I have
never cancelled a deferred upload before). In case my attempt does not
succeed, you should be able to upload a cancel command as well.


> (Maybe we should ask Benno about uploading an "official" pot file for
> version 3.7, the fact that the latest is 3.6.17 and not 3.7 is a
> little bit confusing to me).

The POT template and the version string included is handled by the
software upstream. Maybe we need to contact diffutils upstream instead
of Benno.

The so-called "canonical upstream" is actually
https://git.savannah.gnu.org/git/diffutils.git/ but the git repo does
not include translation files. The PO files seem to be hosted on TP
site.

Thanks,
Boyuan Yang

Bug#978684: autopkgtest should test the installed package

[Roger Shimizu]

> As pointed in the see autopkgtest specification [1] linked from the
> release team documentation [2] “the tests must test the *installed*
> version of the package”. The autopkgtest from this package only uses the
> source package, and as such violates the specification. Displaying it as
> an example in the wiki [3] may not be advisable.

Thanks for spotting this!
I edited the wiki to add this is a bad example for autopkgtest.
And I'm going to remove the debian/tests folder on the next upload.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#978931: gssproxy: CVE-2020-12658

[Salvatore Bonaccorso]

Source: gssproxy
Version: 0.8.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gssproxy.

CVE-2020-12658[0]:
| gssproxy (aka gss-proxy) before 0.8.3 does not unlock cond_mutex
| before pthread exit in gp_worker_main() in gp_workers.c.


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-12658
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12658
[1] 
https://github.com/gssapi/gssproxy/commit/cb761412e299ef907f22cd7c4146d50c8a792003

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#978889: python-crypto: ftbfs with autoconf 2.70

[Sebastian Ramacher]

Control: tags -1 wontfix

On 2020-12-31 14:28:46 +, Matthias Klose wrote:
> Package: src:python-crypto
> Version: 2.6.1-13.1
> Severity: normal
> Tags: sid bookworm
> User: d...@debian.org
> Usertags: ftbfs-ac270
> 
> [This bug report is not targeted to the upcoming bullseye release]
> 
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2020/09/26.ac270/python-crypto_2.6.1-13.1_unstable_ac270.log
> The last lines of the build log are at the end of this report.
> 
> To build with autoconf 2.70, please install the autoconf package from
> experimental:  apt-get -t=experimental install autoconf 
> 
> [...]
> Skipping optional fixer: set_literal
> Skipping optional fixer: ws_comma
> running build_ext
> running build_configure
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether the compiler supports GNU C... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to enable C11 features... none needed
> checking for __gmpz_init in -lgmp... yes
> checking for __gmpz_init in -lmpir... no
> checking how gcc reports undeclared, standard C functions... error
> checking whether mpz_powm is declared... yes
> checking whether mpz_powm_sec is declared... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for inttypes.h... (cached) yes
> checking for limits.h... yes
> checking for stddef.h... yes
> checking for stdint.h... (cached) yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for wchar.h... yes
> checking for inline... inline
> checking for int16_t... yes
> checking for int32_t... yes
> checking for int64_t... yes
> checking for int8_t... yes
> checking for size_t... yes
> checking for uint16_t... yes
> checking for uint32_t... yes
> checking for uint64_t... yes
> checking for uint8_t... yes
> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." 
> "./../.."
> Traceback (most recent call last):
>   File "setup.py", line 451, in 
> core.setup(**kw)
>   File "/usr/lib/python3.8/distutils/core.py", line 148, in setup
> dist.run_commands()
>   File "/usr/lib/python3.8/distutils/dist.py", line 966, in run_commands
> self.run_command(cmd)
>   File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
> cmd_obj.run()
>   File "/usr/lib/python3.8/distutils/command/build.py", line 135, in run
> self.run_command(cmd_name)
>   File "/usr/lib/python3.8/distutils/cmd.py", line 313, in run_command
> self.distribution.run_command(command)
>   File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
> cmd_obj.run()
>   File "setup.py", line 246, in run
> self.run_command(cmd_name)
>   File "/usr/lib/python3.8/distutils/cmd.py", line 313, in run_command
> self.distribution.run_command(command)
>   File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
> cmd_obj.run()
>   File "setup.py", line 273, in run
> raise RuntimeError("autoconf error")
> RuntimeError: autoconf error
> E: pybuild pybuild:352: build: plugin distutils failed with: exit code=1: 
> /usr/bin/python3 setup.py build 
> dh_auto_build: error: pybuild --build -i python{version} -p 3.8 returned exit 
> code 13
> make: *** [debian/rules:9: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2

I won't spend any time on this because python-crypto needs to be removed
ASAP.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#978749: requests: circular dependency makes requests unbuildable

[Sebastian Ramacher]

On 2020-12-31 16:03:48 +0100, Thomas Goirand wrote:
> On 12/31/20 1:25 PM, Sebastian Ramacher wrote:
> > Hi Thomas
> > 
> > On 2020-12-31 13:06:37 +0100, Thomas Goirand wrote:
> >> Hi Sebastian,
> >>
> >> I'm challenging the fact that a circular dependency is a problem for
> >> arch:all packages. At least, it shouldn't be an RC bug, IMO.
> > 
> > If packages cannot be built on the buildds, they are RC-buggy.
> 
> Which is a different topic.
> 
> >> I also don't understand why you've renamed the original bug, which seems
> >> to be very different from the circular dependency you're describing. Can
> >> you explain why they are related, and why we shouldn't have 2 bugs?
> > 
> > The bug is that a build of requests is missing. The version that fixes
> > the uninstallability of python3-requests was already uploaded.
> 
> If I understand correctly, the issue was that requests had:
> 
> python3-chardet (>= 3.0.2), python3-chardet (<< 3.1.0)

No, the issue was that requests with a fixed dependency on
python3-chardet was not buildable because it build-depends on sphinx
which in turn depends on python3-requests which was not installable.

Cheers

> 
> as (build-)depends, which prevents using charted 4. This is very
> different from a circular dependency problem.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#900381: Fails to boot cirros QEMU image with tuned running

[Evgeni Golov]

On Wed, Dec 30, 2020 at 08:33:09PM +0100, Evgeni Golov wrote:
> > And the tuned line that breaks the whole thing is
> > 
> > [sysctl]
> > kernel.sched_wakeup_granularity_ns = 1500
> 
> This also happens on seabios 1.13.0-1 from snapshot.d.o.
> 
> I originally wanted to go and bisect that with upstream seabios.git, but
> then couldn't reproduce with upstreams 1.14.0… Until I realized that I
> built it with CONFIG_ATA_DMA=y (as Debians 1.12) and indeed, this is
> what was changed in 1.13 to n (see [1]) and also what does trigger the
> bug you describe: with ATA_DMA=n the boot hangs, with ATA_DMA=y it boots
> fine.
> 
> Now understanding *why* ATA_DMA=n and sched_wakeup_granularity_ns
> together have this result requires more scotch than I have at hand right
> now.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934134

Just to write down some more facts…

I can reproduce the issue by just poking 
/proc/sys/kernel/sched_wakeup_granularity_ns, so pretty sure it's not really 
tuned who is at foul here.

The original value in my VM seems to be 100 and tuned raises that up
to 1500, which breaks things.

I tried a bit around and the real breaking number seems to be somewhere
between 299 and 300 (I didn't try to find the exact one yet). At
least on my setup, no idea if that fluctuates between systems.

Bug#978758: linux-image-5.5.0-0.bpo.2-amd64: Fails to suspend with „Some devices failed to suspend, or early wake event detected”

[Emil Nowak]

On 31-12-2020, at 15:22:01 Ben Hutchings wrote:

> Control: tag -1 moreinfo
> 
> On Thu, 2020-12-31 at 13:29 +0100, Emil Nowak wrote:
> > Package: src:linux
> > Version: 5.5.17-1~bpo10+1  
> 
> This is quite old now; please test whether the issue still exists in
> the current version (5.9.6-1~bpo10+1).

I upgraded to 5.9.15-1. It doesn't work in a different way:
1. There is no error in dmesg.
2. Monitor seems to go offline - it is blank

But,
1. All fans are still spining
2. Power button on komputer is backlit as it was powered-on.

Bug#978749: requests: circular dependency makes requests unbuildable

[Daniele Tricoli]

Hello Thomas, hello Sebastian!


Thomas, thanks for always caring about requests!

On Thu, Dec 31, 2020 at 04:03:48PM +0100, Thomas Goirand wrote:
> If I understand correctly, the issue was that requests had:
> 
> python3-chardet (>= 3.0.2), python3-chardet (<< 3.1.0)
> 
> as (build-)depends, which prevents using charted 4. This is very
> different from a circular dependency problem.

As discussed on IRC I'm going to drop the upper bounds for both chardet and
urllib3: they was introduced at the time when requests was vendoring all its
dependencies and it was more coupled especially with urllib3. Nowadays for
urllib3 upstream uses a range of versions, and I take care of both urllib3 and
requests, so we should not have problems. chardet is more mature and should not
be a problem at all.

For the severity of this issue, well I think that we all want Debian in the best
shape, so I don't care too much, it's something to be fixed! :)

Thomas thanks for spotting the missing "nodoc", I will fix also this but not
with the upload that will close this bug.

Many thanks, cheers and happy new year!

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org


signature.asc
Description: PGP signature

Bug#975403: knocker 0.8.0

[Gabriele Giorgetti]

version 0.8.0 is out, it should fix the upstream bug.

thanks

Bug#978739: chardet: Upgrading python3-chardet breaks many packages

[Sebastiaan Couwenberg]

reopen 978739
thanks

On 12/31/20 4:13 PM, Daniele Tricoli wrote:
> On Thu, Dec 31, 2020 at 05:55:17AM +0100, Bas Couwenberg wrote:
>> Package: chardet
>> Version: 4.0.0-1
>> Severity: serious
>> Justification: makes the package in question unusable or mostly so
>> Control: affects -1 src:requests src:qgis
>>
>> Dear Maintainer,
>>
>> Upgrading python3-chardet causes the removal of many packages:
>>
>>  The following packages will be REMOVED:
>>chrome-gnome-shell gnome-music pycsw pycsw-wsgi python3-astropy-helpers 
>> python3-boto3 python3-botocore python3-cupshelpers python3-gitlab 
>> python3-numpydoc python3-owslib python3-plotly python3-pycsw python3-pywps 
>> python3-qgis
>>python3-reportbug python3-requests python3-requests-oauthlib 
>> python3-s3transfer python3-sphinx python3-sphinx-astropy 
>> python3-sphinx-automodapi python3-sphinx-gallery pywps qgis 
>> qgis-plugin-grass reportbug system-config-printer
>>system-config-printer-common system-config-printer-udev 
>> torbrowser-launcher
>>  The following packages will be upgraded:
>>python3-chardet
>>  1 upgraded, 0 newly installed, 31 to remove and 0 not upgraded.
>>
>> python3-requests does not support version 3.1.0 or higher:
>>
>>   python3-chardet (<< 3.1.0)
>>
>> With the freeze coming in a few months it may be wise to revert back to 
>> 3.0.x for bullseye.
>>
>> Otherwise the python3-chardet rdeps need to fixed before that time.
> 
> As soon as noticed the chardet upload I uploaded requests 2.25.1+dfsg-1 which
> fix the problem, but there was a time window during the propagation of the new
> version when the problem was reproducible.

Thanks for quickly acting on this, but the problem is not limited to
python3-requests. Several other reverse dependencies need to be updated
for the new chardet as well. The autopkgtest failures include some of them:

 https://qa.debian.org/excuses.php?package=chardet

> Happy new year!

The same to you!

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#978616: mediastreamer2: doesn't build correct libraries with cmake?

[Gianfranco Costamagna]

control: forwarded -1 
https://github.com/BelledonneCommunications/mediastreamer2/pull/27

thanks

G.

Bug#653916: cmake doesn't read $CPPFLAGS, ignores some hardening flags

[Samuel Thibault]

Modestas Vainius, le lun. 27 févr. 2012 00:54:52 +0200, a ecrit:
> The plan how to solve this problem properly on the cmake side has been 
> outlined in the upstream bug report [1]. The rest [2] will have to be done by 
> package maintainers / dh / cdbs.
> 
> [1] http://www.cmake.org/Bug/view.php?id=12928#c28716
> [2] -DCMAKE_POLICY_DEFAULT_CMP=NEW

FTR, we are missing CPPFLAGS in the "c++ -dM -E" commands:

https://salsa.debian.org/debian/vite/-/jobs/1298406

353:CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c 
/usr/share/cmake-3.18/Modules/CMakeCXXCompilerABI.cpp -DMT_PARSING 
-DQT_CHARTS_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB 
-DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB 
-I/usr/include/open-trace-format 
-I/builds/debian/vite/debian/output/source_dir/obj-x86_64-linux-gnu/src/common 
-I/builds/debian/vite/debian/output/source_dir/obj-x86_64-linux-gnu/src 
-I/builds/debian/vite/debian/output/source_dir/src 
-I/builds/debian/vite/debian/output/source_dir/externals/qtcolorpicker/src 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ 
-I/usr/include/x86_64-linux-gnu/qt5/QtXml 
-I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL 
-I/usr/include/x86_64-linux-gnu/qt5/QtUiTools 
-I/usr/include/x86_64-linux-gnu/qt5/QtCharts 
-I/usr/include/x86_64-linux-gnu/qt5/QtSvg -I/usr/include/c++/10 
-I/usr/include/x86_64-linux-gnu/c++/10 -I/usr/include/c++/10/backward 
-I/usr/lib/gcc/x86_64-linux-gnu/10/include -I/usr/local/include 
-I/usr/include/x86_64-linux-gnu -I/usr/include

I circumvented the issue by passing
-DCMAKE_CXX_COMPILER_ARG1="$(CPPFLAGS)" to cmake

Samuel

Bug#978772: autogen: ftbfs with autoconf 2.70

[Andreas Metzler]

Control: tags -1 patch

On 2020-12-31 Matthias Klose  wrote:
> Package: src:autogen
> Version: 5.18.16-4

> [This bug report is not targeted to the upcoming bullseye release]

> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

> The full build log can be found at:
> http://qa-logs.debian.net/2020/09/26.ac270/autogen_5.18.16-4_unstable_ac270.log
> The last lines of the build log are at the end of this report.

> To build with autoconf 2.70, please install the autoconf package from
> experimental:  apt-get -t=experimental install autoconf 

Hello,

For autogen/experimental (5.19.96) config/std-gnu11.m4 needs to be
updated from gnulib m4/std-gnu11.m4 with
---
a3b3fc85e3e632374811b27cb2111e50fa177e36
2020-12-09 04:06:40
std-gnu11: Make compatible with Autoconf 2.70.

* m4/std-gnu11.m4: Disable the entire file if Autoconf >= 2.70 is in
use.
---

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Description: Fix build error with autoconf 2.70
 Update config/std-gnu11.m4 from gnulib m4/std-gnu11.m4
 a3b3fc85e3e632374811b27cb2111e50fa177e36
Author: Andreas Metzler 
Origin: vendor
Bug-Debian: https://bugs.debian.org/978772
Forwarded: no
Last-Update: 2020-12-31

--- autogen-5.19.96.orig/config/std-gnu11.m4
+++ autogen-5.19.96/config/std-gnu11.m4
@@ -6,6 +6,8 @@
 # This implementation will be obsolete once we can assume Autoconf 2.70
 # or later is installed everywhere a Gnulib program might be developed.
 
+m4_version_prereq([2.70], [], [
+
 
 # Copyright (C) 2001-2020 Free Software Foundation, Inc.
 
@@ -822,3 +824,6 @@ dnl Tru64	N/A (no support)
 dnl with extended modes being tried first.
 [[-std=gnu++11 -std=c++11 -std=gnu++0x -std=c++0x -qlanglvl=extended0x -AA]], [$1], [$2])[]dnl
 ])# _AC_PROG_CXX_CXX11
+
+
+])# m4_version_prereq

Bug#978739: chardet: Upgrading python3-chardet breaks many packages

[Daniele Tricoli]

Version: 2.25.1+dfsg-1

Hello Bas,
thanks for the report!

On Thu, Dec 31, 2020 at 05:55:17AM +0100, Bas Couwenberg wrote:
> Package: chardet
> Version: 4.0.0-1
> Severity: serious
> Justification: makes the package in question unusable or mostly so
> Control: affects -1 src:requests src:qgis
> 
> Dear Maintainer,
> 
> Upgrading python3-chardet causes the removal of many packages:
> 
>  The following packages will be REMOVED:
>chrome-gnome-shell gnome-music pycsw pycsw-wsgi python3-astropy-helpers 
> python3-boto3 python3-botocore python3-cupshelpers python3-gitlab 
> python3-numpydoc python3-owslib python3-plotly python3-pycsw python3-pywps 
> python3-qgis
>python3-reportbug python3-requests python3-requests-oauthlib 
> python3-s3transfer python3-sphinx python3-sphinx-astropy 
> python3-sphinx-automodapi python3-sphinx-gallery pywps qgis qgis-plugin-grass 
> reportbug system-config-printer
>system-config-printer-common system-config-printer-udev torbrowser-launcher
>  The following packages will be upgraded:
>python3-chardet
>  1 upgraded, 0 newly installed, 31 to remove and 0 not upgraded.
> 
> python3-requests does not support version 3.1.0 or higher:
> 
>   python3-chardet (<< 3.1.0)
> 
> With the freeze coming in a few months it may be wise to revert back to 3.0.x 
> for bullseye.
> 
> Otherwise the python3-chardet rdeps need to fixed before that time.

As soon as noticed the chardet upload I uploaded requests 2.25.1+dfsg-1 which
fix the problem, but there was a time window during the propagation of the new
version when the problem was reproducible.

Happy new year!

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org


signature.asc
Description: PGP signature

Bug#977538: fonts-agave: does not follow upstream's recommended build procedure

[Fabian Greffrath]

Am Mittwoch, den 30.12.2020, 19:09 +0100 schrieb Gürkan Myczko:
> I wish I could. I'm struggling with that pipeline. Maybe you can hint
> me?

Hm, not sure, quite some usual GIT workflow:

I clone the repository with "git clone ", apply my local changes,
add or remove files with "git add/rm", review my changes with "git
diff", check what would be commited with "git status", commit my
changes with "git commit -- debian" and finally push them to salsa with
"git push --all".

This does not involve package building and uploading, yet. For this I
use "gbp buildpackage" for test builds and finally "gbp buildpackage --
git-tag --git-pbuilder" for the version that I am going to upload.
After that, I push the tag with "git push --all && git push --tags".

Anyway, I have just imported your revision 3 DSC file, fixed a nitpick
and uploaded it. Thanks!

Oh, and I just uploaded the fresh new v36 release as well...

Happy new year. ;)

 - Fabian



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

Bug#978749: requests: circular dependency makes requests unbuildable

[Thomas Goirand]

On 12/31/20 1:25 PM, Sebastian Ramacher wrote:
> Hi Thomas
> 
> On 2020-12-31 13:06:37 +0100, Thomas Goirand wrote:
>> Hi Sebastian,
>>
>> I'm challenging the fact that a circular dependency is a problem for
>> arch:all packages. At least, it shouldn't be an RC bug, IMO.
> 
> If packages cannot be built on the buildds, they are RC-buggy.

Which is a different topic.

>> I also don't understand why you've renamed the original bug, which seems
>> to be very different from the circular dependency you're describing. Can
>> you explain why they are related, and why we shouldn't have 2 bugs?
> 
> The bug is that a build of requests is missing. The version that fixes
> the uninstallability of python3-requests was already uploaded.

If I understand correctly, the issue was that requests had:

python3-chardet (>= 3.0.2), python3-chardet (<< 3.1.0)

as (build-)depends, which prevents using charted 4. This is very
different from a circular dependency problem.

Cheers,

Thomas Goirand (zigo)

Bug#978756: RFS: gkdebconf/2.1.1 [QA] [RC] -- Helper to reconfigure packages with Debconf

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "gkdebconf":

 * Package name: gkdebconf
   Version : 2.1.1
   Upstream Author :
 * URL :
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/gkdebconf
   Section : admin

It builds those binary packages:

  gkdebconf - Helper to reconfigure packages with Debconf

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/gkdebconf/gkdebconf_2.1.1.dsc

Changes since the last upload:

 gkdebconf (2.1.1) unstable; urgency=low
 .
   * QA upload.
   [ Debian Janitor ]
   * Set debhelper-compat version in Build-Depends.
   * Update standards version to 4.5.0, no changes needed.
 .
   [ Helge Kreutzmann ]
   * Update German translation (Closes: #978115)
 .
   [ Håvard Flaget Aasen ]
   * d/control:
 - Bump debhelper to 13
 - Update Standards-Version to 4.5.1
   * Rename d/NEWS.debian to d/NEWS and change distribution
 from unreleased to unstable.
   * Drop de_DE.po and es_ES.po translation, rely on de.po and es.po instead
   * Require gettext 0.21, update with gettextize (Closes: #978375)


I'm not to familiar with gettext and translations, but I tested the
packaged with different translations and it was identical as the
previous version.

The changes has also been pushed to my repository [0]

Regards,
Håavrd

[0] https://salsa.debian.org/haava/gkdebconf

Bug#977331: test rebuild and bug reports

[Matthias Klose]

Zack Weinberg (upstream) asked for a test rebuild in September:
http://qa-logs.debian.net/2020/09/26.ac270/

I filed now bug reports for all affected packages. See:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-ac270;users=d...@debian.org

There's also an autoconf2.69 package in the NEW queue, which I intend to
maintain under the GCC team umbrella.

Bug#978650: podman: please provide a default container registry for looking up short image names

[Antonio Terceiro]

Control: done -1 2.2.1+dfsg1-1

On Thu, Dec 31, 2020 at 08:14:08AM -0500, Reinhard Tartler wrote:
> Can you please try the podman version in experimental? I believe what you
> describe (the shortnames) should work with version 2.2 just fine thanks to
> the shortnames.conf file.

Ah yes the version in exprimental does fix this. Thanks!

> Also, what version of podman did you use in Fedora for this test?

[terceiro@fedora ~]$ podman --version
podman version 2.2.1


signature.asc
Description: PGP signature

Bug#978616: mediastreamer2: doesn't build correct libraries with cmake?

[Gianfranco Costamagna]

On Wed, 30 Dec 2020 17:18:41 +0100 Bernhard Schmidt  wrote:
> Dear Gianfranco,
> 
> Thanks for filing this bug report. I’m away for the next couple of days and 
> could not check, but wouldn’t just patching the pkgconfig file (your second 
> option) be a lot easier? Upstream merged both libraries and they probably 
> just forgot to change the pkgconfig file as well.
> 
> In the end linphone upstream does not seem to care much about other programs 
> using their library. 
> 

I did my assumption based on this:

[2.9.0] - 2013-05-27
Added
[...]
Changed
Split the libmediastreamer library in two libraries: libmediastreamer_base and 
libmediastreamer_voip. For VoIP support, both libraries must be linked to the 
executable.


So I thought that upstream was moving from 1 library into 2 different libs.
If upstream moved from 2 to 1, patching the pkgconfig file is indeed the right 
(and upstreamable) thing to do.

But according to git log, you seems to be right:

commit 50c9633712a57910612c4c58d237fbe5652843dd
Author: Ghislain MARY 
Date:   Mon Oct 15 10:51:37 2018 +0200

Build a single mediastreamer library (instead of mediastreamer_base and 
mediastreamer_voip) and a single mediastreamer2 framework for iOS.


So, ok for the easier approach!

Description: Fix pkgconfig linkage
Author: Gianfranco Costamagna 
Last-Update: 2020-12-31

--- mediastreamer2-4.4.21.orig/mediastreamer.pc.in
+++ mediastreamer2-4.4.21/mediastreamer.pc.in
@@ -7,5 +7,5 @@ Name: mediastreamer
 Description: A mediastreaming library for telephony applications
 Requires: ortp bctoolbox
 Version: @MEDIASTREAMER_VERSION@
-Libs: -L@libdir@ -lmediastreamer_base -lmediastreamer_voip
+Libs: -L@libdir@ -lmediastreamer
 Cflags: -I@includedir@ @MS_PUBLIC_CFLAGS@


This one should do the trick.
I'll upstream it in a pull request shortly!

G.

Bug#978758: linux-image-5.5.0-0.bpo.2-amd64: Fails to suspend with „Some devices failed to suspend, or early wake event detected”

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2020-12-31 at 13:29 +0100, Emil Nowak wrote:
> Package: src:linux
> Version: 5.5.17-1~bpo10+1

This is quite old now; please test whether the issue still exists in
the current version (5.9.6-1~bpo10+1).

> Severity: normal
> 
> Dear Maintainer,
> 
> When I invoke suspend using:
> # systemctl suspend
> machine starts suspending but after turning off monitor and disks
> spinning, it wakes up again.
> It used to work on the same machine - I'm not sure after which
> upgrade it failed.
[...]

Does it work with the buster kernel (4.19-based)?

Ben.


-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken


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

Bug#978761: gcc-11: Please temporarily disable Ada on m68k

[John Paul Adrian Glaubitz]

Source: gcc-11
Version: 10.2.1-3
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

The Ada bootstrap is currently broken on m68k which causes gcc-11 to FTBFS:

> +===GNAT BUG DETECTED==+
> | 11.0.0 20201228 (experimental) [master revision 
> 12ae2bc7084:08ca52bdc1f:97d3ddcfc9c67d26e3869a261a506ef70e7f092e] 
> (m68k-linux-gnu) |
> | Storage_Error stack overflow or erroneous memory access  |
> | No source file position information available|
> | Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
> | Use a subject line meaningful to you and us to track the bug.|
> | Include the entire contents of this bug box in the report.   |
> | Include the exact command that you entered.  |
> | Also include sources listed below.   |
> +==+
> 
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).

I have reported the issue upstream [1] and also bisected the commit that 
introduced
the problem.

Could you disable Ada in gcc-11 on m68k until the issue has been fixed upstream?

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341

--
 .''`.  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#978437: geoclue-2.0: regression in 2.5.7-1, no geolocation returned

[gregor herrmann]

On Thu, 31 Dec 2020 03:48:25 +0100, Laurent Bigonville wrote:

> The following line is actually the real problem, I did all my tests on
> laptop with wifi cards, I just tried on my desktop and I get the same error
> (and timeout as you)
> > (geoclue:10479): Geoclue-WARNING **: 16:26:35.098: Failed to create query: 
> > No WiFi devices available
> It looks like geoclue is not doing any request to the Mozilla Location
> Service is there is no wifi cards (or wifi network around) anymore

Thanks for the fix!

I can confirm that it works for me now as well \o/

(The interesting thing is that I did this on my laptop; admittedly
yesterday with Wifi turned off but I thought I had tried last week as
well after enabling Wifi but I might have fallen into some trap,
maybe the startup timeout …)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Kings of Convenience: My Ship Isn't Pretty


signature.asc
Description: Digital Signature

Bug#974979: make courier configuration by default on directories.. event files

[PICCORO McKAY Lenz]

Currently  Courier uses several configuration files in /etc/courier
that can be replaced by a subdirectory whose contents are
concatenated and treated as a single, consolidated, configuration file.

This behaviour is less confused for the few tutorials and works better
to manipulate the files by scripts (as webadmin cgi does)

First setp to solve this is in courier-base package, must be changed
to true, this will create the minimal set of directories.

Later in a new revision remove the question and migrate to use
only directories (that can co-exist with normal files), manpages
of the courier suite points so many times about those directories..

by example the esmtpacceptmailfor: can be a single file
in the path /etc/courier/esmtpacceptmailfor of a directory at
the path /etc/courier/esmtpacceptmailfor.dir and all files inside
will be parsed as single one.

better example is hosted domains, can be a single file in
/etc/courier/hosteddomains
but is better a directory /etc/courier/hosteddomains and each domain
could be a single file (named as the domain without dots) and with
domain inside in plain text.

as i said.. this behaviour is more elaborated but more organized
for huge servers like production real cases

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


El jue, 31 de dic. de 2020 a la(s) 05:58, Markus Wanner
(mar...@bluegap.ch) escribió:
>
> Control: tags -1 +moreinfo
> Control: severity -1 normal
>
> Hi,
>
> from this wording, I have no idea what this bug is about, sorry.  Please
> clarify your proposal.
>
> Markus

Bug#978753: usercopy: Kernel memory exposure attempt

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Markus,

Thanks for your report.

On Thu, Dec 31, 2020 at 12:45:47PM +0200, Markus Bäcklund wrote:
> Package: src:linux-image-4.19.0-13-amd64
> Version: 4.19.160-2
> Severity: critical
> Justification: breaks the whole system
> 
> 
> 
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
> 
> 
> -- System Information:
> Debian Release: 10.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.86 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_UNSIGNED_MODULE

5.4.86 is not a Debian kernel in buster and was tainted. Can you
please provide the kernel logs as well? This might give some better
clue.

Regards,
Salvatore

Bug#978748: libboost-dev: Boost 1.75

[Giovanni Mascellani]

Hi,

Il 31/12/20 10:20, Olaf van der Spek ha scritto:

Could Boost 1.75 be packaged?


Eventually it will be (either 1.75 or a newer version), but I don't know 
when. 1.74 will be in bullseye, there is no point rushing a new 
transition now.


Giovanni.
--
Giovanni Mascellani 

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

Can you please try the podman version in experimental? I believe what you
describe (the shortnames) should work with version 2.2 just fine thanks to
the shortnames.conf file.

Also, what version of podman did you use in Fedora for this test?

-rt

On Tue, Dec 29, 2020 at 12:45 PM Antonio Terceiro 
wrote:

> Package: podman
> Version: 2.1.1+dfsg1-3
> Severity: wishlist
>
> When running stuff that was originally written for docker, image names
> will usually be provided in their short form, i.e. debian:10,
> fedora:rawhide. In the current state of the Debian packaging, those will
> fail like this:
>
> $ cat Containerfile
> FROM debian
> $ podman build -t foobar .
> STEP 1: FROM debian
> Error: error creating build container: (image name "debian" is a short
> name and no search registries are defined in
> /etc/containers/registries.conf): while pulling "debian" as
> "localhost/debian": Error initializing source
> docker://localhost/debian:latest: error pinging docker registry localhost:
> Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection
> refused
>
> On Fedora, on the other hand, this just works, because their
> registries.conf provides by default a list of as few registries
> registries where to look up unqualified image names:
>
> [terceiro@fedora tmp]$ grep -v '^#' /etc/containers/registries.conf
> unqualified-search-registries = ['registry.fedoraproject.org', '
> registry.access.redhat.com', 'registry.centos.org', 'docker.io']
>
> I don't think we want to include the fedora/redhat/centos registries,
> but we should include at least the docker.io registry, which is the _de
> facto_ standard in the container world at the moment. So can we please
> provide something like the line below by default in
> /etc/containers/registries.conf?
>
> unqualified-search-registries = ['docker.io']
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
> 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.0.20-1
> ii  containernetworking-plugins  0.8.7-1
> ii  crun 0.15.1+dfsg-1
> ii  golang-github-containers-common  0.26.3+ds1-2
> ii  init-system-helpers  1.60
> ii  libc62.31-6
> ii  libdevmapper1.02.1   2:1.02.173-1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1
> ii  runc 1.0.0~rc92+dfsg1-5
>
> Versions of packages podman recommends:
> ii  buildah 1.16.6+dfsg1-2
> ii  catatonit   0.1.5-2
> ii  fuse-overlayfs  1.2.0-1
> ii  slirp4netns 1.0.1-1
> ii  tini0.19.0-1
> ii  uidmap  1:4.8.1-1
>
> Versions of packages podman suggests:
> pn  containers-storage  
>
> -- no debconf information
>


-- 
regards,
Reinhard