Bug#996672: SV: Bug#996672: linux-image-5.10.0-9-amd64: ite_cir floods syslog with receive overflow warning messages

[Salvatore Bonaccorso]

Hi Björn,

On Sun, Oct 17, 2021 at 09:26:39PM +0200, Salvatore Bonaccorso wrote:
> Hi Björn,
> 
> On Sun, Oct 17, 2021 at 05:40:43PM +, Björn Wiberg wrote:
> > Hello Salvatore!
> > 
> > Many thanks for your reply!
> > 
> > I’m afraid I cannot switch to unstable (or ”mix”), and if I
> > understand it correctly, the unsigned kernel from backports won’t
> > boot if Secure Boot is being used (which is the case on this
> > server)?
> 
> Right but i expect the signed packages to appear "soonish" as well.
> The signing machinery needs to be triggered once the respective
> linux-signed-{amd64,i386,arm64} are there. So we can afford to wait a
> couple of days yet if you are open to test the bpo kernel version.

FTR, bullseye-backports packages are now as well available for the
signed packages for linux-signed-amd64.

Regards,
Salvatore

Bug#996926: unattended-upgrades reboots when Unattended-Upgrade::Automatic-Reboot = False

[Bálint Réczey]

Control: tags -1 moreinfo unreproducible invalid

Hi Chris,

Chris Stromsoe  ezt írta (időpont: 2021. okt. 20., Sze, 23:03):
>
> Package: unattended-upgrades
> Version: 1.11.2
>
> I recently started using unattended-upgrades to keep a machine up to date.
> After installing, I've had a few instances where the machine restarted on
> its own.  I believe that unattended-upgrades rebooted my machine even
> though Automatic-Reboot is set to False.
>
> Logged from syslog:
>
> Oct 20 12:15:43 potato systemd[1]: Started Unattended Upgrades Shutdown.

This is just the unattended-upgrades.service starting.

> From /etc/apt/apt.conf.d/50unattended-upgrades:
>
> Unattended-Upgrade::Automatic-Reboot "false";
>
>
> Looking at the source for /usr/bin/unattended-upgrade, reboots are handled
> by reboot_if_requested_and_needed().  The check for Automatic-Reboot is on
> lines 1336 and 1337.  I believe the check is wrong.
>
> The test for False on line 1337 should be True, to indicate that if
> Automatic-Reboot is not set to True in the configuration file, the
> function should return without proceeding.
>
> 1331 def reboot_if_requested_and_needed():
> 1332 # type: () -> None
> 1333 """auto-reboot (if required and the config for this is set)"""
> 1334 if not os.path.exists(REBOOT_REQUIRED_FILE):
> 1335 return
> 1336 if not apt_pkg.config.find_b(
> 1337 "Unattended-Upgrade::Automatic-Reboot", False):
> 1338 return
> 1339 # see if we need to check for logged in users
> 1340 if not apt_pkg.config.find_b(
> 1341 "Unattended-Upgrade::Automatic-Reboot-WithUsers", True):
> 1342 users = logged_in_users()
> 1343 if users:
> 1344 msg = gettext.ngettext(
> 1345 "Found %s, but not rebooting because %s is logged in." % 
> (
> 1346 REBOOT_REQUIRED_FILE, users),
> 1347 "Found %s, but not rebooting because %s are logged in." 
> % (
> 1348 REBOOT_REQUIRED_FILE, users),
> 1349 len(users))
> 1350 logging.warning(msg)
> 1351 return
> 1352 # reboot at the specified time
> 1353 when = apt_pkg.config.find(
> 1354 "Unattended-Upgrade::Automatic-Reboot-Time", "now")
> 1355 logging.warning("Found %s, rebooting" % REBOOT_REQUIRED_FILE)
> 1356 cmd = ["/sbin/shutdown", "-r", when]
> 1357 try:
> 1358 shutdown_msg = subprocess.check_output(cmd, 
> stderr=subprocess.STDOUT)
> 1359 if shutdown_msg.strip():
> 1360 logging.warning("Shutdown msg: %s", shutdown_msg.strip())
> 1361 except Exception as e:
> 1362 logging.error("Failed to issue shutdown: %s", e)
> 1363

This seems to work OK according to your next email.
I think something else restarted the system.

Cheers,
Balint

Bug#996586: heimdal: CVE-2021-3671

[Salvatore Bonaccorso]

Hi Brian,

Only commenting on the first part for now:

On Thu, Oct 21, 2021 at 11:19:50AM +1100, Brian May wrote:
> Salvatore Bonaccorso  writes:
> 
> > Source: heimdal
> > Version: 7.7.0+dfsg-2
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > Control: found -1 7.5.0+dfsg-3
> 
> Does this need to be grave? Considering it was considered a minor issue
> everywhere else, maybe not?

Right, when filling a bug the severity is often "orthogonal" to a
no-dsa security tracking decision. With the grave severity as RC I
would like to basically make the statement here, the security issue
should be considered RC and the next release (far away) should contain
this fix.

A RC severity fileld bug does not make necdssarily the implication
that a DSA is needed (instead of e.g. fixing it via point release,
which seems sensible here for me). OTOH, many non-RC severity
warranted a DSA.

Hope this explains a bit. If you feel strong about the severity beeing
to hight, feel free to downgrade, please.

Regards,
Salvatore

Bug#996938: ITP: golang-github-pelletier-go-toml.v2 -- Go library for the TOML file format

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-pelletier-go-toml.v2
  Version : 2.0.0~beta3-1
  Upstream Author : Thomas Pelletier
* URL : https://github.com/pelletier/go-toml/tree/v2
* License : Expat, Apache-2.0
  Programming Lang: Go
  Description : Go library for the TOML file format

 go-toml v2 is a Go library for the TOML format.
 It supports TOML (Tom's Obvious, Minimal Language) version v1.0.0.
 .
 Features:
 .
 Stdlib behavior
 As much as possible, this library is designed to behave similarly
 as the standard library's encoding/json.
 .
 Performance
 While go-toml favors usability, it is written with performance in mind.
 Most operations should not be shockingly slow.
 .
 Strict mode
 Decoder can be set to "strict mode", which makes it error when some parts
 of the TOML document was not prevent in the target structure.
 This is a great way to check for typos.
 .
 Contextualized errors
 When decoding errors occur, go-toml returns DecodeError), which contains
 a human readable contextualized version of the error.
 .
 Local date and time support
 TOML supports native local date/times. It allows to represent a given
 date, time, or date-time without relation to a timezone or offset.
 To support this use-case, go-toml provides LocalDate, LocalTime, and
 LocalDateTime. Those types can be transformed to and from time.Time,
 making them convenient yet unambiguous structures for their respective
 TOML representation.


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

Bug#996928: liblemonldap-ng-portal-perl: Missing javascript folder on htdocs

[Yadd]

Le 21/10/2021 à 00:49, Manuel Flores a écrit :
> Package: liblemonldap-ng-portal-perl
> Maintainer: Debian Perl Group
>  >
> Architecture: all
> Source: lemonldap-ng
> Version: 2.0.11+ds-4
> Severity: important
> 
> 
> On a fresh install and initial configuration this message appears in
> apache2 log files:
> [Wed Oct 20 17:16:44.015537 2021] [core:info] [pid 7893] [client
> 192.168.1.235:42442 ] AH00128: File does not
> exist:
> /usr/share/lemonldap-ng/manager/htdocs/javascript/angular.js/angular-animate.min.js,
> referer: http://manager.local/ 
> 
> And the web interface does not load correctly.
> 
> The solution I follow was to create a symlink on
> /usr/share/lemonldap-ng/portal/htdocs with the following command :
>  ln -s /usr/share/javascript/ /usr/share/lemonldap-ng/portal/htdocs
>  ln -s /usr/share/javascript/ /usr/share/lemonldap-ng/manager/htdocs
> 
> This happens on the manager package.
> 
> Thank you

Hi,

no need to do that, you just have to enable javascript-common:

  sudo a2enconf javascript-common

Cheers,
Yadd

Bug#996699: [Debian-on-mobile-maintainers] Bug#996699: chatty: Cross-building fails to resolve libpurple-dev

[Richard Laager]

On a related note, I still need to bring this package's debehlper compat 
level current. That would hopefully address these:
W: finch-dev: pkg-config-unavailable-for-cross-compilation 
usr/lib/pkgconfig/finch.pc
W: libpurple-dev: pkg-config-unavailable-for-cross-compilation 
usr/lib/pkgconfig/purple.pc
W: pidgin-dev: pkg-config-unavailable-for-cross-compilation 
usr/lib/pkgconfig/pidgin.pc


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994045: Root cause of 994045

[Stefano Rivera]

Hi Michalik, (2021.09.11_01:54:07_-0700)
> The try..except ladder in _get_html_page() uses
> 
> 
> 
> while the exception raised by requests is
> 
> 
> 
> and so pip does not recognize the two as equal.

They *should* be the same, the pip._vendor mechanism should have put the
requests whl on sys.path and aliased it through the pip._vendor tree:

This test is not attempting to duplicate the virtualenv bootstrap
environment, so it's possible that I'm missing something, but:

$ python3
Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pip._vendor.requests.exceptions
>>> import requests.exceptions
>>> pip._vendor.requests.exceptions is requests.exceptions
True
>>> pip._vendor.requests.exceptions.HTTPError is requests.exceptions.HTTPError
True
>>> requests.__path__
['/usr/share/python-wheels/requests-2.21.0-py2.py3-none-any.whl/requests']

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996937: raspi-firmware: possibly disable cma= setting on Pi CM4 as well

[Cyril Brulebois]

Package: raspi-firmware
Version: 1.20210303+ds-2
Severity: normal

Hi,

Looking at #980536, and if I'm reading between the lines correctly, the
whole Pi 4 family should have no cma= setting, and we should be skipping
it on the Compute Module 4 the same way we do on the Pi 4.

The current check happens with:

grep -q 'Raspberry Pi 4' /proc/device-tree/model

If my understanding is correct, we should be additionally checking:

grep -q 'Raspberry Pi Compute Module 4' /proc/device-tree/model

This would avoid re-adding cma=$CMA (with CMA defaulting to 64M) on the
CM4, which the image-specs build disabled initially, when producing the
image with `make raspi_4_bullseye.img`.


If the setting is confirmed to be extraneous, and is gotten rid of,
it would reduce the differences between before/after first boot's
cmdline.txt (see also [1]).

 1. https://salsa.debian.org/raspi-team/image-specs/-/issues/57


I'm happy to propose a tested patch once I have a confirmation regarding
the “should we do it” part. :)


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#994045: python-pip-whl: pip 18.1 raises EnvironmentError on 404 from index, which leads to PIP_FIND_LINKS being ignored

[Stefano Rivera]

Hi MrMino (2021.09.10_08:45:58_-0700)
> Since python-virtualenv will try to install pkg_resources==0.0.0 as a
> separate package (which does not exist on any Python index, given that
> it's a part of setuptools), it will instruct pip to do something akin to
> "pip install pkg_resources". Pip will ask the index about pkg_resources,
> which will return a 404. Then, pip will move to resolving the dependency
> using PIP_FIND_LINKS.

Somewhat related is #994952. The patch I'm proposing for Buster will
avoid trying to install pkg_resources==0.0.0. But setuptools and pip
still need to be installable from your index or you'll still hit this
bug.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996936: libtool might not use the recommended linker options for macOS >= 12

[Carlo Arenas]

Package: libtool
Version: 2.4.6-14
Severity: important
Tags: upstream
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44605

As originally discussed in upstream bug report 44684, any package
bootstrapped using the upstream libtool.m4 will fail to recognise
macOS BigSur and use the wrong linker flags, which could result in
issues when the libraries are later dlopen (ex: libgcrypt when used by
Guile 3.0.7 through guile-gcrypt[2])

A partial fix for this was committed as
debian/patches/0070-libtool-bigsur.patch but it only corrected the
default call, and will break if MACOSX_DEPLOYMENT_TARGET=12.0 is
provided (which will happen with the release of Monterrey next week)

The simplest solution would be to change the last condition to match
all versions instead of only "10.*|11.*"

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44684
[2] https://dev.gnupg.org/T5610

Bug#996935: gnome-shell-extension-shortcuts: settings dialog broken: Error: Type name ShortcutsPrefsWidget is already registered

[Paul Wise]

Package: gnome-shell-extension-shortcuts
Version: 1.2.1-1
Severity: important
Usertags: crash
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41
File: /usr/share/gnome-shell/extensions/shortc...@kyle.aims.ac.za/prefs.js

Now that the extension is compatible with GNOME 41, when
opening the settings dialog, I get a crash dialog instead:

   Error: Type name ShortcutsPrefsWidget is already registered
   
   Stack trace:
 _construct@resource:///org/gnome/gjs/modules/script/_legacy.js:536:31
 wrapper@resource:///org/gnome/gjs/modules/script/_legacy.js:83:27
 newClass@resource:///org/gnome/gjs/modules/script/_legacy.js:115:21
 @/usr/share/gnome-shell/extensions/shortc...@kyle.aims.ac.za/prefs.js:62:30
 _init@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:206:33
 
OpenExtensionPrefsAsync/<@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:122:28
 
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
 run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:177:20
 main@resource:///org/gnome/Shell/Extensions/js/main.js:19:13
 run@resource:///org/gnome/gjs/modules/script/package.js:206:19
 start@resource:///org/gnome/gjs/modules/script/package.js:190:8
 @/usr/share/gnome-shell/org.gnome.Shell.Extensions:1:17
  
-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-shell-extension-shortcuts depends on:
ii  gnome-shell  41.0-2

gnome-shell-extension-shortcuts recommends no packages.

gnome-shell-extension-shortcuts suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental

[Aaron M. Ucko]

Étienne Mollier  writes:

> The issue turned out to be related, and I came up with some
> hackery to smoothen the transition to python-biopython 1.79.
> The corresponding patch is in attachment.  I welcome remarks,
> since I'm only half happy with the result, although I tried hard
> to make sure it is functionally equivalent.

Great, thanks!  I suppose it might be slightly cleaner to factor out a
helper predicate function.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#996923: apt-listbugs: page long buglists

[Francesco Poli]

On Wed, 20 Oct 2021 16:40:46 -0400 Moshe Piekarski wrote:

[...]
> Apt-listtbugs output is less usefull on large upgrades due
> to bugs scrolling offscreen
> please implement paging for long buglists.

Hello Moshe,
thanks for your feature request.

I am under the impression that your need is a bit unusual.
The reason is that apt-listbugs is most useful (I think), when using
Debian testing or unstable and upgrading reasonably often.
In this scenario, it is quite uncommon to see a very long list of RC
bugs during one upgrade session...

However, I see that you are using Debian testing, but apparently you do
not upgrade very often (your system still thinks that bullseye ==
testing ...).
Oh, and I also see that you configured apt-listbugs to also show
important bugs, along with RC bugs.
These two points might explain the bigger number of bugs that you
encounter.

I don't know whether I will consider implementing a paging option for
apt-listbugs.
A naive implementation could be feasible without too much hassle, but
it would be too tied to specific tool choices (for instance, it could
be written to forcibly use the "less" pager, but, what if a user has or
prefers another pager?).
Maybe a more general solution should be sought.
Perhaps the use of a helper Ruby library, such as [tty-pager]?
Unfortunately, it seems that this library is not (yet) included in
Debian. Would you be willing to file an RFP bug for this library
(or, better yet, to file an ITP bug and package it yourself)?

[tty-pager]: 

> 
> 
> - -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
[...]
> - -- Configuration Files:
> /etc/apt/apt.conf.d/10apt-listbugs changed:
[...]
> AptListbugs::Severities "critical,grave,serious,important";
> // AptListbugs::IgnoreRegexp "FTBFS";
[...]

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgparSOKutoAe.pgp
Description: PGP signature

Bug#996934: install failure without /etc/flash-kernel/machine pre-existing

[Joey Hess]

Package: flash-kernel
Version: 3.104
Severity: normal

I have some image building scripts that installed flash-kernel in a chroot
(on unrelated hardware; user mode qemu), then configured
/etc/flash-kernel/machine, then ran flash-kernel.
That used to work (in 2018), and now fails:

Creating config file /etc/default/flash-kernel with new version
Setting up flash-kernel (3.104) ...
Processing triggers for libc-bin (2.32-4) ...
Processing triggers for initramfs-tools (0.140) ...
Warning: root device  does not exist
Unsupported platform ''.
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 initramfs-tools

This left initramfs-tools half-configured, and apt-get install flash-kernel
exited nonzero.

It seems unreasonable for installing the flash-kernel package to leave the
system in this state when a file that is only documented in that package does
not exist before the package is installed.

Also "Unsupported platform ''" is not the best error message.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#996586: heimdal: CVE-2021-3671

[Brian May]

Salvatore Bonaccorso  writes:

> Source: heimdal
> Version: 7.7.0+dfsg-2
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 7.5.0+dfsg-3

Does this need to be grave? Considering it was considered a minor issue
everywhere else, maybe not?

I attempted to fix this for unstable - and committed changed to Debian
git repo, but:


* Patch breaks compilation on latest Heimdal release:

krb5tgs.c: In function ‘tgs_build_reply’:
krb5tgs.c:1665:2: warning: implicit declaration of function ‘_kdc_set_e_text’ 
[-Wimplicit-function-declaration]
 1665 |  _kdc_set_e_text(priv, "No server in request");
  |  ^~~
krb5tgs.c:1665:2: warning: nested extern declaration of ‘_kdc_set_e_text’ 
[-Wnested-externs]
krb5tgs.c:1665:18: error: ‘priv’ undeclared (first use in this function)
 1665 |  _kdc_set_e_text(priv, "No server in request");
  |  ^~~~
krb5tgs.c:1665:18: note: each undeclared identifier is reported only once for 
each function it appears in
  CC   config.o
make[2]: *** [Makefile:1037: krb5tgs.lo] Error 1


* Heimdal doesn't appear build on sid anymore. Syntax error in
  configure, which I can't work out (the file looks fine to me).

checking for dn_expand... yes
checking for _res... yes
./configure: line 20867: syntax error near unexpected token `)'
./configure: line 20867: `)'
make[1]: *** [debian/rules:38: override_dh_auto_configure] Error 2


Anyway, just my status for now. Help appreciated :-)
-- 
Brian May 

Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

[Nicholas D Steeves]

Hi Paul!

Paul Gevers  writes:

> Source: python-volatile
> Version: 2.1.0-2
> Severity: serious
> Control: close -1 2.1.0-3
> X-Debbugs-CC: jel...@debian.org   
> Tags: sid bookworm pending
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
[snip]
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bookworm, so
> it doesn't affect (old-)stable.
>
> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.
>

Solving this bug justifies an upload, and I'd also like to update my
email address in src:python-volatile.  Normally I don't think changing
an email address would justify an upload, so this is a great opportunity
;-)

I will of course credit you for identifying this issue and taking the
initiative to fix it, and will upload without delay once I receive your
ACK (please CC me).

For future reference, if there was an NMUdiff, I would incorporate it
into the -4 release along with my change, but then, what is the best
practise?  Ask for the NMU submitter to cancel the delayed upload,
upload -4 which will presumably cause -3.1 to be rejected when the
delayed timer fires, or cancel the delayed upload myself?

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental

[Étienne Mollier]

Control: tags -1 + patch

Hello,

Étienne Mollier, on 2021-10-19:
> After some digging, I found one possible cause of breakage.
> Since biopython 1.79, Bio.Seq.UnknownSeq is deprecated [1], so
> it might be possible that ncbi-acc-download does not parse the
> instanciation of that class very well.
> 
> [1]: 
> https://github.com/biopython/biopython/blob/master/DEPRECATED.rst#biosequnknownseq

The issue turned out to be related, and I came up with some
hackery to smoothen the transition to python-biopython 1.79.
The corresponding patch is in attachment.  I welcome remarks,
since I'm only half happy with the result, although I tried hard
to make sure it is functionally equivalent.

> Looks like I would want to take the issue upstream.

Will do once I have a handle to the patch in the bts.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
Description: fix wgs download for unknown sequences with biopython 1.79
 Biopython 1.79 deprecated the UnknownSeq class, and as a side effect, the
 instantiation of UnknownSeq in Biopython internals became replaced in favor of
 regular Seq of None data and non-zero length, thus breaking checks on objects
 being instances of UnknownSeq.  Onwards, unknown sequences can be detected as
 data access would raise UndefinedSequenceError, but this error class didn't
 exist yet in Biopython 1.78.
 .
 This patch tries to smoothen the transition between biopython 1.78 and 1.79 by
 making the logic support both versions, probably at the cost of quickly
 unnecessary complexity though, since "try" and "if" statements don't mix very
 well.
Author: Étienne Mollier 
Bug-Debian: https://bugs.debian.org/996794
Forwarded: no
Last-Update: 2021-10-20
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- ncbi-acc-download.orig/ncbi_acc_download/wgs.py
+++ ncbi-acc-download/ncbi_acc_download/wgs.py
@@ -15,6 +15,7 @@
 
 from io import StringIO
 import time
+import sys
 
 from ncbi_acc_download.download import (
 build_params,
@@ -28,6 +29,11 @@
 try:
 from Bio import SeqIO
 from Bio.Seq import UnknownSeq
+try:
+from Bio.Seq import UndefinedSequenceError
+except ImportError:  # didn't exist in biopython 1.78 and earlier
+class UndefinedSequenceError(ValueError):
+"""Sequence contents is undefined."""
 HAVE_BIOPYTHON = True
 except ImportError:  # pragma: no cover
 HAVE_BIOPYTHON = False
@@ -101,15 +107,25 @@
 handle.seek(0)
 records = list(SeqIO.parse(handle, config.format))
 for record in records:
-run_download = isinstance(record.seq, UnknownSeq)
-if run_download and ('wgs_scafld' in record.annotations or
- 'wgs' in record.annotations or
- 'tsa' in record.annotations):
-updated_records.extend(download_wgs_for_record(record, config))
-elif run_download and 'contig' in record.annotations:
-updated_records.extend(fix_supercontigs(record, config))
+junk = open('/dev/null', mode='w')
+try:
+# dummy trigger for Biopython 1.79 and later
+print(record.seq, file=junk)
+# adjusted logic for Biopython 1.78 and earlier
+if isinstance(record.seq, UnknownSeq):
+raise UndefinedSequenceError
+except UndefinedSequenceError:
+if ('wgs_scafld' in record.annotations or
+'wgs' in record.annotations or
+'tsa' in record.annotations):
+updated_records.extend(download_wgs_for_record(record, config))
+elif 'contig' in record.annotations:
+updated_records.extend(fix_supercontigs(record, config))
+else:
+updated_records.append(record)
 else:
 updated_records.append(record)
+junk.close()
 
 outhandle = StringIO()
 SeqIO.write(updated_records, outhandle, config.format)


signature.asc
Description: PGP signature

Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource

[Adam Sampson]

On Tue, Oct 19, 2021 at 02:49:40PM +0200, Vincent Lefevre wrote:
> Xpdf*font: foo
[...]
> $ xpdf
> Warning: Cannot convert string "foo" to type FontStruct
> Segmentation fault (core dumped)

I've been able to reproduce the crash -- it's occurring in Motif when
xpdf tries to create the text widgets in the About window, with the same
traceback as in #996903.

This seems to be because I used XmStringGenerate with a rendition tag to
style the text. It looks like Motif still thinks that an Xft font is
being used to render it (which is incorrect), and ends up dereferencing
NULL because the font hasn't been loaded. I guess this is a Motif bug...

I've worked around this (in xpopple Git) by styling the widgets using
resources rather than rendition tags. Specifying Xpdf*font now correctly
overrides all the default fonts again.

Thanks,

-- 
Adam Sampson  

Bug#994762: warnings about session IDs

[Antoine Beaupré]

On 2021-10-20 20:22:08, Ian Campbell wrote:
> On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
>> And I can confirm it works, or at least does not warn.
>
> Excellent, thanks.
>
> Is the diff as simple as:
>
>$ git diff
>diff --git a/doc/xss-lock.service b/doc/xss-lock.service
>index 52086c8..37d733e 100644
>--- a/doc/xss-lock.service
>+++ b/doc/xss-lock.service
>@@ -4,7 +4,7 @@ PartOf=graphical-session.target
> 
> [Service]
> Type=simple
>-ExecStart=/usr/bin/xss-lock -l -s ${GRAPHICAL_SESSION_ID} -- i3lock
>+ExecStart=/usr/bin/xss-lock -l -s ${XDG_SESSION_ID} -- i3lock
> 
> [Install]
> WantedBy=graphical-session.target

That sounds about right, here's my current service file.

-- 
Your injured body has become the burden of your digital soul.
- Yin Aiwen, 2013, The Massage is the Medium

[Unit]
Description=xss-lock - use external locker as X screen saver
Documentation=man:xss-lock(1)
PartOf=graphical-session.target
Wants=xset.service
After=xset.service

[Service]
Type=simple
EnvironmentFile=/home/anarcat/.xsecurelock.env
# note that when this works, document in #994762
ExecStart=/usr/bin/xss-lock --verbose --transfer-sleep-lock 
--session=${XDG_SESSION_ID} --notifier /usr/libexec/xsecurelock/dimmer -- 
xsecurelock

[Install]
WantedBy=graphical-session.target

Bug#993370: RFP: rg-el -- elpa-rg

[Antoine Beaupré]

On 2021-10-20 18:58:03, Nicholas D. Steeves wrote:

[...]

> As an aside, personally I'm happy with counsel-ag, and cousel-rg works
> great; I packaged bin:elpa-counsel as part of src:emacs-ivy, which used
> to be a hard dependency of elpa-find-file-in-project, which used to be a
> dependency of src:elpy, my first big project (and your RFP).
> Unfortunately upstream wasn't able to keep pace with Python breaking
> changes, Python 3.9 broke Elpy's ERT tests badly.
>
> For a user who doesn't know which to choose, at this point it seems like
> this:
>
>   Choose rg.el for the traditional Emacs interface or Magit-like interface
>   Choose Ivy/Counsel for a completion framework that is non-jarring for
>   long-time Emacs users, and that is fast (in both cases, in when
>   compared to Helm).  In other words, it seems to be a case of UI
>   preference and inclination due to established habits.
>
> At the moment I'm currently stumped about why "M-x rg" doesn't find
> hits/matches that /usr/bin/rg does, even thought the ERT tests indicate
> that this codepath is functional and correct.  My hypothesis is that
> someone made a perfectly reasonable assumption that may have now been
> revealed to be a technical deficiency.

[...]

Thanks for the update! That's interesting! I've been meaning to look at
other completion frameworks, I keep getting confused because I can't
even remember which one I'm using.

For the record, I'm probably going to switch away from elpy towards the
more standard lsp-mode, which covers more languages and actually works
with Python (and other tools like mypy/pyright). I'm sorry you had to
work so hard on this package only to see it miss bullseye and end up in
that state. But I guess that's the life of software: a few of my own
personal projects didn't make it to bullseye due to bitrot and I was
also sad about that...

I am not sure we should continue with rg-el. Maybe deadgrep or
counsel-rg are better paths forward?

Thanks again!

a.

-- 
La démocratie réelle se définit d'abord et avant tout par la
participation massive des citoyens à la gestion des affaires de la cité.
Elle est directe et participative. Elle trouve son expression la plus
authentique dans l'assemblée populaire et le dialogue permanent sur
l'organisation de la vie en commun.  - De la servitude moderne

Bug#996933: ITP: griddb -- Database for IoT with both NoSQL interface and SQL Interface

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: griddb
  Version : 4.6.1
  Upstream Author : cont...@griddb.org
* URL : https://github.com/griddb
* License : AGPL
  Programming Lang: C++
  Description : Database for IoT with both NoSQL interface and SQL Interface

 GridDB is Database for IoT with both NoSQL interface and SQL Interface.
 This adopts its own extended key container type for the data model.

Bug#996752: clang-13: -static-pie AND -fuse-ld=lld produce unusable a.out

[Ryutaroh Matsumoto]

Control: clone -1 -2
Control: reassign -2 clang-12 1:12.0.1-12
Control: retitle -2 -static-pie AND -fuse-ld=lld-12 produce unusable a.out

The same symptom appears with
clang-12 -static-pie AND -fuse-ld=lld-12

Best regards, Ryutaroh

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Adam Sampson]

On Wed, Oct 20, 2021 at 05:23:10PM +0300, Eugene Berdnikov wrote:
>  Xpdf 3.04+git20211001-1 crashes on bookworm/sid (amd64).

> #0  ComputeMetrics (rend=0x55f686580c40, text=text@entry=0x55f686580e74, 
> byte_count=7, type=, 
> which_seg=which_seg@entry=3, width=width@entry=0x7fffdb64203c, 
> height=0x7fffdb64203e, ascent=0x0, descent=0x0, 
> utf8=0 '\000') at XmString.c:6343

Thanks for the traceback! The change that has almost certainly caused
this is that xpdf now uses Motif's Xft font rendering support (in the
interests of being able to render characters beyond ASCII properly in
the GUI).

The crash is happening inside the Motif library when xpdf tries to
create its very first text widget, on this line of code:

asc = _XmRendXftFont(rend)->ascent;

The font pointer in question was set elsewhere in Motif from the results
of an XftFontOpenPattern call, which returns NULL if no font was
matched. However, the font it's asking for is very generic (Serif bold
20) so I'd expect it to match something... which suggests this is
probably something odd about Motif rather than xpdf specifically.

I assume you have some fonts installed that Xft/fontconfig knows about
(running "fc-list" prints something)?

It would be worth setting a breakpoint on XftFontOpenPattern and seeing
if it's getting there at all -- strace might also tell you whether it's
finding the fontconfig cache and any font files.

Thanks,

-- 
Adam Sampson  

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Adam Sampson]

On Thu, Oct 21, 2021 at 12:23:16AM +0100, Adam Sampson wrote:
> [xpdf crashes in Motif on] asc = _XmRendXftFont(rend)->ascent;

Hmm -- the crash in #996832 is happening in the same place...

Do you have an Xpdf*font: resource (or something similar) set on your
display?

Thanks,

-- 
Adam Sampson  

Bug#994952: Fails to create Python 3 virtualenv in buster: 404 Client Error: Not Found for url: https://pypi.org/simple/pkg-resources/

[Stefano Rivera]

Filed bug #996929 to update Buster.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996930: warzone2100: Can't play multiplayer through lobby: "Can't find any games for your version"

[Linus Lüssing]

Package: warzone2100
Version: 3.3.0-4+b1
Severity: normal

Hi,

When trying to play a multiplayer game through the lobby, the following
error is returned:

"Can't find any game for your version. -
Download 4.1.3 - 3.1.5 & 3.2.3 are unsupported!"

To avoid breaking lobby multiplayer it would be great if at least Sid
could always follow and provide the latest release.

Skirmish and multiplayer work fine for me when building and running
Warzone2100 4.1.3 from the source.

I haven't tried campaign for a while but several release notes mention
campaign fixes, too. So might help with #862917 as well.

Regards, Linus


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

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

Versions of packages warzone2100 depends on:
ii  libc6 2.32-2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libgl11.3.2-1
ii  libglew2.22.2.0-4
ii  libharfbuzz0b 2.7.4-1
ii  libminiupnpc172.1-1+b2
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-2
ii  libphysfs13.0.2-5
ii  libpng16-16   1.6.37-3
ii  libqt5core5a  5.15.2+dfsg-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5script5 5.15.2+dfsg-2
ii  libqt5widgets55.15.2+dfsg-5
ii  libsdl2-2.0-0 2.0.14+dfsg2-3
ii  libstdc++610.2.1-6
ii  libtheora01.1.1+dfsg.1-15
ii  libvorbis0a   1.3.7-1
ii  libvorbisfile31.3.7-1
ii  warzone2100-data  3.3.0-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages warzone2100 recommends:
ii  warzone2100-music  3.3.0-4

warzone2100 suggests no packages.

-- no debconf information

Bug#994258: python-django breaks lava autopkgtest: PASSWORD_RESET_TIMEOUT_DAYS/PASSWORD_RESET_TIMEOUT are mutually exclusive.

[Adrian Bunk]

Control: clone -1 -2
Control: reassign -1 lava-server 2020.12-5
Control: retitle -1 lava-server fails to install with python3-django 3.2
Control: reassign -2 python3-django 2:3.2.8-1
Control: retitle -2 python3-django needs Breaks for the bullseye lava-server
Control: block -2 by -1

On Tue, Sep 14, 2021 at 09:27:21PM +0200, Paul Gevers wrote:
>...
> lava-server manage migrate --noinput --fake-initial
> Traceback (most recent call last):
>   File "/usr/bin/lava-server", line 68, in 
> main()
>   File "/usr/bin/lava-server", line 64, in main
> execute_from_command_line([sys.argv[0]] + options.command)
>   File
> "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
> line 419, in execute_from_command_line
> utility.execute()
>   File
> "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
> line 413, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py",
> line 354, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py",
> line 398, in execute
> output = self.handle(*args, **options)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py",
> line 86, in wrapped
> saved_locale = translation.get_language()
>   File
> "/usr/lib/python3/dist-packages/django/utils/translation/__init__.py",
> line 254, in get_language
> return _trans.get_language()
>   File
> "/usr/lib/python3/dist-packages/django/utils/translation/__init__.py",
> line 57, in __getattr__
> if settings.USE_I18N:
>   File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line
> 82, in __getattr__
> self._setup(name)
>   File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line
> 69, in _setup
> self._wrapped = Settings(settings_module)
>   File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line
> 190, in __init__
> raise ImproperlyConfigured(
> django.core.exceptions.ImproperlyConfigured:
> PASSWORD_RESET_TIMEOUT_DAYS/PASSWORD_RESET_TIMEOUT are mutually exclusive.

Note that what fails is installing lava-server, this can be reproduced 
easily just by trying to install the package.

I'm splitting this into two bugs:
1. lava-server needs fixing for Django 3.2 (Antonio told me that work is 
ongoing)
2. after that, python3-django needs Breaks against older versions
   this is important both for upgrades from bullseye, and for 
   python3-django/bullseye-backports that will likely exist

cu
Adrian

Bug#993370: RFP: rg-el -- elpa-rg

[Nicholas D Steeves]

Hi Antoine,

It looks like I forgot to send this draft... (Dated 07 Sep 2021).  So,
here's an update on the packaging: It's done, but the software seems to
be fundamentally broken by something that I haven't yet been able to
identify.  I also confess to low motivation, and to worrying that this
package could become a huge time/energy sink like Elpy...I should
probably share my WIP soon so someone can go "Aha!  That this is what
you missed!", and I'm hoping that's all it is, because I'm appalled that
the most basic function (rg) is nonfunctional.  Meanwhile, counsel-rg
works perfectly.
--

If you're short on time, skip to "As an aside" for some new info (you've
read the rest on IRC).

Antoine Beaupré  writes:

>> If you think the process might be interesting content for
>> Debian Planet, please let me know :-)
>
> That would be interesting, for sure, but no pressure. :)

Ok, will do!  Casual deadline of mid-October.

>>> I'm not actually sure why Nicholas picked rg.el.
>>
>> I can update this bug with my rationale (from IRC) if you think it would
>> be useful to others.
>
> That, however, seems like an important thing to document here, for
> posterity.
>

Ok, for posterity :-)

Why this source package name?  Rg-el, because we can't have src:rg.el,
and the -el suffix denotes elisp; you're totally right, src:rg-el will
produce bin:elpa-rg :-)  Finally, ITPs are for source package names, but
I can't remember if this is a rule or convention.

I chose rg.el over alternatives (such as the excellent Deadgrep) for a
variety of reasons.  First, based on the README, it seemed to fit what I
think your use case (and criteria for an improved grep) was; second, it
(subjectively) seemed like a more familiar interface (standard Emacs
conventions and expectations), and it has (rg-enable-menu) which uses
Magit's transient.el.  The menu mode has a "magit-like" interface, and
UI consistency between modes is part of my overarching goal of making
contributions that make Emacs more accessible and less arcane for new
users; third, it impresses me that rg.el provides a backward-compatible
config key for keybindings when it moved to new, allegedly more
consistent ones ("new is better" is a pet peeve of mine, and I believe
that Emacs projects that have churn in this area would annoy you);
finally, the test suite impresses me, especially how it takes care to
test interoperation with other modes for possible regressions.

Rg.el also seems to be significantly more popular on MELPA, which is
more of a "probability of popularity in Debian" than a quality
thing... (eg: number of people who benefit to hours of work ratio thing)

As an aside, personally I'm happy with counsel-ag, and cousel-rg works
great; I packaged bin:elpa-counsel as part of src:emacs-ivy, which used
to be a hard dependency of elpa-find-file-in-project, which used to be a
dependency of src:elpy, my first big project (and your RFP).
Unfortunately upstream wasn't able to keep pace with Python breaking
changes, Python 3.9 broke Elpy's ERT tests badly.

For a user who doesn't know which to choose, at this point it seems like
this:

  Choose rg.el for the traditional Emacs interface or Magit-like interface
  Choose Ivy/Counsel for a completion framework that is non-jarring for
  long-time Emacs users, and that is fast (in both cases, in when
  compared to Helm).  In other words, it seems to be a case of UI
  preference and inclination due to established habits.

At the moment I'm currently stumped about why "M-x rg" doesn't find
hits/matches that /usr/bin/rg does, even thought the ERT tests indicate
that this codepath is functional and correct.  My hypothesis is that
someone made a perfectly reasonable assumption that may have now been
revealed to be a technical deficiency.

Worse case scenario: please ping me in mid-October.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#996929: buster-pu: package python-virtualenv/15.1.0+ds-2

[Stefano Rivera]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
python-virtualenv recently had a regression in buster caused by a
server-side change on pypi.org (#994952).
It started to 404 (breaking virtualenv) where it had previously returned
an empty directory listing for the pkg_resources package.

pip, setuptools, and pkg_resources are bootstrapped into virtualenvs.

pkg_resources is part of the setuptools PyPI package, upstream. But in
Debian its packaged as its own binary package, so we have some patches
in Debian to explicitly install pkg_resources.

The old behaviour is currently back on pypi.org, see
https://github.com/pypa/warehouse/issues/10081

But the fix to avoid virtualenv from depending on this empty directory
listing is very simple, so we should probably apply it.

[ Impact ]
Reliance on pypi.org serving a workaround for our virtualenv version.
Without that workaround, virtualenv fails (unless explicitly run with
--no-download)

[ Tests ]
Manually tested behaviour with and without --no-download.

[ Risks ]
Trivial patch.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
When bootstrapping setuptools and pip into the virtualenv *from PyPI*,
don't ask pip to install pkg_resources.

[ Other info ]
(Anything else the release team should know.)
diff -Nru python-virtualenv-15.1.0+ds/debian/changelog 
python-virtualenv-15.1.0+ds/debian/changelog
--- python-virtualenv-15.1.0+ds/debian/changelog2018-12-13 
11:19:35.0 -0800
+++ python-virtualenv-15.1.0+ds/debian/changelog2021-10-20 
15:48:33.0 -0700
@@ -1,3 +1,9 @@
+python-virtualenv (15.1.0+ds-2+deb10u1) buster; urgency=medium
+
+  * Avoid attempting to install pkg_resources from PyPI. (Closes: #994952)
+
+ -- Stefano Rivera   Wed, 20 Oct 2021 15:48:33 -0700
+
 python-virtualenv (15.1.0+ds-2) unstable; urgency=medium
 
   [ Vincent Bernat ]
diff -Nru python-virtualenv-15.1.0+ds/debian/patches/use-wheels.patch 
python-virtualenv-15.1.0+ds/debian/patches/use-wheels.patch
--- python-virtualenv-15.1.0+ds/debian/patches/use-wheels.patch 2018-12-13 
11:19:35.0 -0800
+++ python-virtualenv-15.1.0+ds/debian/patches/use-wheels.patch 2021-10-20 
15:48:33.0 -0700
@@ -22,8 +22,8 @@
  scripts/virtualenv  |  9 +++
  setup.py|  4 ++--
  virtualenv.egg-info/SOURCES.txt |  4 ++--
- virtualenv.py   | 52 ++---
- 4 files changed, 62 insertions(+), 7 deletions(-)
+ virtualenv.py   | 53 ++---
+ 4 files changed, 63 insertions(+), 7 deletions(-)
 
 diff --git a/scripts/virtualenv b/scripts/virtualenv
 index 418bd79..7dd0203 100644
@@ -126,7 +126,7 @@
  if cert_data is not None:
  cert_file = tempfile.NamedTemporaryFile(delete=False)
  cert_file.write(cert_data)
-@@ -928,8 +948,34 @@ def create_environment(home_dir, site_packages=False, 
clear=False,
+@@ -928,8 +948,35 @@ def create_environment(home_dir, site_packages=False, 
clear=False,
  
  to_install = []
  
@@ -157,7 +157,8 @@
 +
  if not no_setuptools:
  to_install.append('setuptools')
-+to_install.append('pkg_resources')
++if not download:
++to_install.append('pkg_resources')
  
  if not no_pip:
  to_install.append('pip')

Bug#996928: liblemonldap-ng-portal-perl: Missing javascript folder on htdocs

[Manuel Flores]

Package: liblemonldap-ng-portal-perl
Maintainer: Debian Perl Group 
Architecture: all
Source: lemonldap-ng
Version: 2.0.11+ds-4
Severity: important
Depends: perl:any, fonts-font-awesome, lemonldap-ng-fastcgi-server (=
2.0.11+ds-4) | lemonldap-ng-uwsgi-app (= 2.0.11+ds-4) | apache2 |
httpd-cgi, libclone-perl, liblemonldap-ng-handler-perl (= 2.0.11+ds-4),
libjs-bootstrap4, libjs-cryptojs, libjs-jquery, libjs-jquery-ui,
libjs-jquery-cookie, libtext-unidecode-perl, libregexp-assemble-perl,
libemail-date-format-perl
Pre-Depends: debconf
Recommends: gsfonts, libcrypt-openssl-bignum-perl, libconvert-base32-perl,
libio-string-perl, libipc-run-perl, libgd-securityimage-perl,
libmime-tools-perl, libnet-ldap-perl, libio-socket-timeout-perl,
libunicode-string-perl
Suggests: gpg, libcrypt-u2f-server-perl, libdbi-perl, libglib-perl,
libgssapi-perl, libimage-magick-perl, liblasso-perl,
libnet-facebook-oauth2-perl (>= 0.10), libnet-openid-consumer-perl,
libnet-openid-server-perl, libnet-oauth-perl, libsoap-lite-perl,
libweb-id-perl, slapd
Conffiles:
 /etc/cron.d/liblemonldap-ng-portal-perl dea6dd6b10f2c97aee90913dc33ef239
 /etc/lemonldap-ng/portal-apache2.X.conf 7ea93307e1b956807ae2ca080684c15e
 /etc/lemonldap-ng/portal-nginx.conf d7f80aa02e4c0b761a9add83bdcf28b2
Description: Lemonldap::NG authentication portal part
 Lemonldap::NG is a complete Web-SSO system that can run with
reverse-proxies
 or directly on application webservers. It can be used in conjunction with
 OpenID-Connect, CAS and SAML systems as identity or service provider. It
can
 also be used as proxy between those federation systems.
 .
 It manages both authentication and authorization and provides headers for
 accounting. So you can have a full AAA protection. Authorizations are
built by
 associating a regular expression and a rule. Regular expression is applied
on
 the requested URL and the rule calculates if the user is authorized.
 .
 Lemonldap::NG::Portal provides the authentication portal.
 .
 You may have to install some suggested packages depending on plugins you
 enabled. For example, libgd-securityimage-perl and gsfonts are needed if
you
 want to use Captcha, libcrypt-u2f-server-perl for U2F features,...
Homepage: https://lemonldap-ng.org/



On a fresh install and initial configuration this message appears in
apache2 log files:
[Wed Oct 20 17:16:44.015537 2021] [core:info] [pid 7893] [client
192.168.1.235:42442] AH00128: File does not exist:
/usr/share/lemonldap-ng/manager/htdocs/javascript/angular.js/angular-animate.min.js,
referer: http://manager.local/

And the web interface does not load correctly.

The solution I follow was to create a symlink on
/usr/share/lemonldap-ng/portal/htdocs with the following command :
 ln -s /usr/share/javascript/ /usr/share/lemonldap-ng/portal/htdocs
 ln -s /usr/share/javascript/ /usr/share/lemonldap-ng/manager/htdocs

This happens on the manager package.

Thank you

-- 
Atte. Manuel Flores

"Good artists borrow, great artists steal" - Pablo Picasso

Bug#983505: doas: persist option still does not work

[Scupake]

Hello,

It was fixed in 6.8.1-3, you still have 6.8.1-2.
I think Devuan Chimaera is based on Debian Stable so it'll take a while
for it to get the update.

-- 
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

[Ole Christian Nilsen]

On Wed, 28 Sep 2016 12:57:49 +0100 Tim Small  wrote:
> Package: curl
> Followup-For: Bug #834724
>
> I fixed this on a sid install by removing libgnutls-deb0-28 which was
> being kept around by an old librtmp1 package version, left over from
> Jessie debian-multimedia.  Possibly libcurl should conflict with this
> package?
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages curl depends on:
> ii  libc62.24-3
> ii  libcurl3-gnutls  7.50.1-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> curl recommends no packages.
>
> curl suggests no packages.
>
> -- debconf-show failed
>
>

Bug#996927: Drop NSCD_SOCKET_OLD and harden systemd unit?

[Trent W. Buck]

Trent W. Buck wrote:
> RuntimeDirectory=unscd

That's a typo, it should be "RuntimeDirectory=nscd".
Testing didn't catch it until I did a reboot, because
the non-systemd doesn't remove /run/nscd when unscd stops.

Bug#996926: Acknowledgement (unattended-upgrades reboots when Unattended-Upgrade::Automatic-Reboot = False)

[Chris Stromsoe]

I misunderstood the functionality of apt_pkg.config.find_b().  My 
troubleshooting on this is wrong and the proposed fix doesn't fix the 
problem.  I'm still looking at why my system rebooted and will update if 
I find anything.  Otherwise, please close this if you feel that's 
warranted.

Bug#994952: Fails to create Python 3 virtualenv in buster: 404 Client Error: Not Found for url: https://pypi.org/simple/pkg-resources/

[Stefano Rivera]

Hi Debian (2021.09.23_13:56:44_-0700)
> Creating a virtualenv fails, we presume this is a recent regression due
> to some server-side change on PyPI.

I never found anything in the warehouse git history to explain that, but
https://pypi.org/simple/pkg-resources/ now returns a 200 and an empty
directory listing, so things are working again.

However, there is a simple change we can make to avoid needing this
directory to exist, so I'll run that by the stable release team.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#892730: nslcd: Please add systemd .service file

[Trent W. Buck]

PS: the hardening bit also works as a dropin,
i.e. you can put it into /etc/systemd/system/nslcd.service.d/hardening.conf
and the rest of the unit remains auto-generated from /etc/init.d/nslcd.

Trent W. Buck wrote:
> # nslcd listens to /run/nslcd/socket and creates /run/nslcd/nslcd.pid.
> # We can tell systemd about this.
> RuntimeDirectory=nslcd
> WorkingDirectory=/run/nslcd
> 
> 
> # Additional security lockdown (optional).
> # $ systemd-analyze security nslcd:
> # → Overall exposure level for nslcd.service: 1.2 OK 
> [Service]
> CapabilityBoundingSet=
> RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
> DevicePolicy=closed
> NoNewPrivileges=yes
> PrivateDevices=yes
> PrivateTmp=yes
> PrivateUsers=yes
> ProtectClock=yes
> ProtectControlGroups=yes
> ProtectHome=yes
> ProtectKernelLogs=yes
> ProtectKernelModules=yes
> ProtectKernelTunables=yes
> ProtectProc=invisible
> ProtectSystem=strict
> RestrictSUIDSGID=yes
> SystemCallArchitectures=native
> SystemCallFilter=@system-service
> # We can't drop @privileged because we fail with:
> #   nslcd: wait_for_response(): read_response() returned 0 (expected 4)
> #   nslcd: unable to daemonize: No data available
> #SystemCallFilter=~@privileged
> SystemCallFilter=~@resources
> RestrictNamespaces=yes
> RestrictRealtime=yes
> LockPersonality=yes
> MemoryDenyWriteExecute=yes
> RemoveIPC=yes
> UMask=0077
> ProtectHostname=yes
> ProcSubset=pid

Bug#996927: Drop NSCD_SOCKET_OLD and harden systemd unit?

[Trent W. Buck]

Package: unscd
Version: 0.54-1
Severity: wishlist

I wrote a hardening dropin (attached) for unscd.service.

$ systemd-analyze security
UNIT   EXPOSURE PREDICATE HAPPY
unscd.service   9.6 UNSAFE  # before
unscd.service   1.1 OK  # after

Please consider adding some/all of it to debian/unscd.service.
You may need to "dial back" the hardening a little, e.g.
PADL libnss-ldap (dead since 2016, but still in Debian 11) probably needs 
AF_INET AF_INET6.

Two further improvements require source code changes:

  * Removing NSCD_SOCKET_OLD from nscd.c.
I *think* glibc hasn't used this path for over a decade now!
Removing it will allow systemd to block write access to /run.

  * Make unscd only drop privileges if it starts as root (or so).
This will allow systemd to drop privileges before unscd starts, and
block CAP_SET[UG]ID and sete[ug]id(2).

I am using unscd with its default nscd.conf.
It provides a short-term cache for nss-pam-ldapd,
reducing the load on the LDAP server (slapd or samba-ad) by 90% to 99%.

My test case was to do this (testing passwd negative-ttl only) :

# for i in {1..}; do touch "$i"; chown -h 1234 "$i"; done
# time find -nouser -fprintf /dev/null .
real0m1.176s# unscd is stopped
real0m0.446s# unscd is running

With my dropin, this test still passes, so I think unscd is both running and 
working.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
# This file goes in /etc/systemd/system/unscd.service.d/hardening.conf

[Service]
PrivateNetwork=yes
## We can't drop root privs before starting, because
## it wants to bind BOTH of these:
##
##define NSCD_SOCKET "/var/run/nscd/socket"
##define NSCD_SOCKET_OLD "/var/run/.nscd_socket"
##
## Probably the latter should just be removed from unscd.c entirely, since
## the implementations of glibc that use it are probably long gone.
# User=unscd
# DynamicUser=yes
RuntimeDirectory=unscd
WorkingDirectory=/run/nscd
CapabilityBoundingSet=
# FIXME: once we Users=unscd, tighten this up.
CapabilityBoundingSet=CAP_SETUID CAP_SETGID
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
DevicePolicy=closed
IPAddressDeny=any
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
# FIXME: once we Users=unscd, tighten this up.
# UPDATE: er, we probably need PrivateUsers=no anyway, because
# nscd's job is to see & cache users. :-)
#PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
# FIXME: once NSCD_SOCKET_OLD is gone, remove this.
ReadWritePaths=/run
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
# FIXME: once we Users=unscd, tighten this up.
#SystemCallFilter=~@privileged
SystemCallFilter=~@resources
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
UMask=0077
ProtectHostname=yes
ProcSubset=pid

Bug#996926: unattended-upgrades reboots when Unattended-Upgrade::Automatic-Reboot = False

[Chris Stromsoe]

Package: unattended-upgrades
Version: 1.11.2

I recently started using unattended-upgrades to keep a machine up to date. 
After installing, I've had a few instances where the machine restarted on 
its own.  I believe that unattended-upgrades rebooted my machine even 
though Automatic-Reboot is set to False.


Logged from syslog:

Oct 20 12:15:43 potato systemd[1]: Started Unattended Upgrades Shutdown.



From /etc/apt/apt.conf.d/50unattended-upgrades:


Unattended-Upgrade::Automatic-Reboot "false";


Looking at the source for /usr/bin/unattended-upgrade, reboots are handled 
by reboot_if_requested_and_needed().  The check for Automatic-Reboot is on 
lines 1336 and 1337.  I believe the check is wrong.


The test for False on line 1337 should be True, to indicate that if 
Automatic-Reboot is not set to True in the configuration file, the 
function should return without proceeding.


1331 def reboot_if_requested_and_needed():
1332 # type: () -> None
1333 """auto-reboot (if required and the config for this is set)"""
1334 if not os.path.exists(REBOOT_REQUIRED_FILE):
1335 return
1336 if not apt_pkg.config.find_b(
1337 "Unattended-Upgrade::Automatic-Reboot", False):
1338 return
1339 # see if we need to check for logged in users
1340 if not apt_pkg.config.find_b(
1341 "Unattended-Upgrade::Automatic-Reboot-WithUsers", True):
1342 users = logged_in_users()
1343 if users:
1344 msg = gettext.ngettext(
1345 "Found %s, but not rebooting because %s is logged in." % (
1346 REBOOT_REQUIRED_FILE, users),
1347 "Found %s, but not rebooting because %s are logged in." % (
1348 REBOOT_REQUIRED_FILE, users),
1349 len(users))
1350 logging.warning(msg)
1351 return
1352 # reboot at the specified time
1353 when = apt_pkg.config.find(
1354 "Unattended-Upgrade::Automatic-Reboot-Time", "now")
1355 logging.warning("Found %s, rebooting" % REBOOT_REQUIRED_FILE)
1356 cmd = ["/sbin/shutdown", "-r", when]
1357 try:
1358 shutdown_msg = subprocess.check_output(cmd, 
stderr=subprocess.STDOUT)
1359 if shutdown_msg.strip():
1360 logging.warning("Shutdown msg: %s", shutdown_msg.strip())
1361 except Exception as e:
1362 logging.error("Failed to issue shutdown: %s", e)
1363

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgradel

[Thorsten Glaser]

On Wed, 20 Oct 2021, Jesse Smith wrote:

> 1. There is something about the host system that is causing insserv to

But what, given I can reproduce this in a chroot and on my laptop?

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#996925: ITP: python-django-contrib-comments -- Django comments framework

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-contrib-comments
  Version : 2.1.0
  Upstream Author : Django Software Foundation
* URL : https://github.com/django/django-contrib-comments/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django comments framework

Django used to include a comments framework; since Django 1.6 it's been
separated to a separate project. This is that project.

This framework can be used to attach comments to any model, so you can use it
for comments on blog entries, photos, book chapters, or anything else.

I intend to maintain this package as part of the Debian Python team.

-BEGIN PGP SIGNATURE-

iQFEBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmFweyoRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wq+4Qf4oP2Ikk2SP84g6VFuUgEnIokMWclKftVa
ajzGVxv1feLJUEqxJVNyJR09oq9wXwK9qwDEcUxIDh8jwFWYRBUsjTwib3zZBzRZ
Ly6zZIuwWoILNM6YIJWuDFg44dwNXHI20wtVeS/VCYOmCUKGBYh2ip5Y2XJtsxHV
zk9iKcphIiFI7NbUHHRg4HkVFdm3aEihPpmus7xfOKkz213VbNkjSZ1m5VtFm260
HgSXnt41HjM+FMzJbuUE3kLz8sQyJOvt1VF5T3HpmIScCnyk60oPnfWaITO+enrd
UiBsski1yR1KcFxgOzD1q+Jmim1fFB7/TBaOIqqTgMf5ta+PTeDG
=vxrB
-END PGP SIGNATURE-

Bug#996924: nextcloud-desktop: deletes dirs on the server although they're still here locally

[Roland Mas]

Package: nextcloud-desktop
Version: 3.1.1-2+deb11u1
Severity: important

>From time to time, whole directories get erased from the server for no
reason.  I've seen it happen a few times already, but not early enough
to be able to catch logs. So far I've been lucky enough to be able to
restore from backups, but it's not something that I can afford to see
happen again.

In my case, the client sent a DELETE request for a directory that
hadn't been deleted locally. The
~/.local/share/Nextcloud/Documents_sync.log file shows it:

12:27:42||TEMP|INST_REMOVE|Up|1633813324|61620350e2e1d|0|06377550ocptyqgkbgt0|4||204|0|0

At the same time, the server log shows the corresponding request:

[REDACTED] [17/Oct/2021:14:27:42 +0200] "DELETE 
/remote.php/dav/files/DetR/Documents/TEMP HTTP/1.1" 204 609 "-" "Mozilla/5.0 
(Linux) mirall/3.1.1-2+deb11u1 (Nextcloud)"

So obviously, on all other clients using that shared Documents
directory, the TEMP directory is deleted. It's still present locally,
but there's a discrepancy with the server, and that discrepancy is not
always resolved in the right direction: sometimes in the past the
directory was restored from the local version and eventually
re-uploaded then re-synced to other clients, but other times the local
version was deleted too, in which case the directory is completely
lost.

This is really major, and the fact that it happens "rarely" (although
a couple of times a year for me) doesn't make it less grave.

For reference the server runs 21.0.0, but I've seen this bug happen
with previous versions too, and I don't think the bug is server-side.

I'm fully willing to help provide more info if instructed how, but
note that the bug is unpredictable to me.

It may be relevant that my Documents share is about 500 GB in size,
with about 300k files.

Please advise.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 nextcloud-desktop depends on:
ii  libc6  2.31-13+deb11u2
ii  libcloudproviders0 0.3.0-3
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libnextcloudsync0  3.1.1-2+deb11u1
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5keychain10.10.0-1
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5qml5 5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5webenginecore5   5.15.2+dfsg-3
ii  libqt5webenginewidgets55.15.2+dfsg-3
ii  libqt5webkit5  5.212.0~alpha4-11
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  nextcloud-desktop-common   3.1.1-2+deb11u1
ii  nextcloud-desktop-l10n 3.1.1-2+deb11u1
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-6
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-6
ii  qml-module-qtquick-window2 5.15.2+dfsg-6
ii  qml-module-qtquick25.15.2+dfsg-6

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.1.1-2+deb11u1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgradel

[Jesse Smith]

On 2021-10-20 4:59 p.m., Mark Hindley wrote:
> I am unclear as to the significance of the reordering of  .depends.* that
> happens on the first run. Jesse, is that expected. Does it point to something?

I suspect the initial reordering probably indicates one of two things:

1. There is something about the host system that is causing insserv to
toggle ordering back and forth which we haven't been able to reproduce.
This would result in insserv switching things back to "normal" when run
on another system, and then leave it be.

2. Something on the host system changed init script dependencies,
resulting in a reshuffling. This isn't necessarily a bad thing, it can
happen when a script is added or removed from /etc/init.d, possibly by
the package manager. It usually just indicated something changed since
the last time insserv was run.

Jesse

Bug#916796: IEEEfull.bib: cannot be read in encoding 'utf8' by biber

[Hilmar Preuße]

Am 15.01.2019 um 22:24 teilte Hilmar Preuße mit:

On 15.01.19 09:59, Damir Islamov wrote:


Hi Damir,


I got response from Michael Shell, maintainer of IEEEtran.bst package.


Please make sure the file uploaded to CTAN, else we won't get the fix.


Did your hear anything from Michael Shell for this?

This issue is still present and the bib file on CTAN is still the broken 
version,


Thanks,
  Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996923: apt-listbugs: page long buglists

[Moshe Piekarski]

Package: apt-listbugs
Version: 0.1.35
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Apt-listtbugs output is less usefull on large upgrades due to bugs scrolling 
offscreen
please implement paging for long buglists.


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 2.2.3
ii  ruby1:2.7+2
ii  ruby-debian 0.3.10+b4
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-5
ii  ruby-unicode0.4.4.4-1+b1
ii  ruby-xmlparser  0.7.3-4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2

Versions of packages apt-listbugs suggests:
ii  firefox [www-browser]86.0-2
ii  links2 [www-browser] 2.21-1+b1
ii  lynx [www-browser]   2.9.0dev.6-2
ii  reportbug7.10.3
ii  sensible-utils   0.0.14
ii  xdg-utils1.1.3-4.1
ii  xemacs21-mule [www-browser]  21.4.24-9

- -- Configuration Files:
/etc/apt/apt.conf.d/10apt-listbugs changed:
// Before installing packages, check whether they have release-critical bugs.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs apt";};
DPkg::Tools::Options::/usr/bin/apt-listbugs "";
DPkg::Tools::Options::/usr/bin/apt-listbugs::Version "3";
DPkg::Tools::Options::/usr/bin/apt-listbugs::InfoFD "20";
AptListbugs::Severities "critical,grave,serious,important";
// AptListbugs::IgnoreRegexp "FTBFS";


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAmFwfscZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igT/5EACFYxZK3WPChptuzIgs21O/
W04UMPVMPyQROqXHI6CnVD1ZbRi1+ylQc9Ph/hBnPXWKhF/AYrrKIPKYo2ygdMHA
tumXbIT+BkXUW0HQ9OD2GBghEjZuOp4J60XNjJ8mbW2dBX89c0YeROoUmzL57+/C
P3Gv7O8zPGcMe6DZd4QpXAgG326SYxsmB1iqZaDWF0nq78ubq2GlBoaMx4TkBUtb
TfyWaYzZjqagdi7f/u70EBH/wwCdQQYsQSioV/OrQadLMrIwHZdDMzJmUsj1E1Ck
aWKTKvi84PWwVLslG6XtV/9j7pcXT8MKs9g608QFaAnQ/CGQjLQc5Qyo9FzlkATa
boIQ0YqBzV5XWbgTBAovJH1q7ozq97zRyQ+hb3pz/PiLjnVdTp8biaKUrcbaYobk
QvNjI6aHlD2o1je/8hJeYqOmEOACsGFfxn+dSOGQGPFMHrHRdPabX4AShdw0k1T7
n7SbHZoipJqw6yNXhVdLbrhRu4L11BOWzPNcgbEK3pPSOghM+R4wkHimCMAY95F4
ncW2SYIRlY7TFXCdk8JurNyM3KYP8gzoPESv1U5yV7KZCe1i038ciI5ohHxSvX9x
zCNkypvzShEfuKjr0mK5y/3L3NM//JgdN91S0QpjqwEKTf7UHC7DdjZK9v5bfR8E
6JzbFk1Iy9KslSN7n/RKRQ==
=x7Ax
-END PGP SIGNATURE-

Bug#996922: firefox exits with SIGFPE on startup (no user interaction)

[Bastian Germann]

Package: firefox
Version: 92.0-1
Severity: grave

Dear Maintainer,

   * What led up to the situation?

Starting firefox or firefox-esr (or even chromium). I guess it is caused by a 
common dependency only on i386.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

No user interaction.

   * What was the outcome of this action?

The browser exits after showing a crashed tab panel with SIGFPE.

   * What outcome did you expect instead?

Running the browser normally.



-- Package-specific info:

Starting program: /usr/bin/firefox.real 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb77ffac0 (LWP 11257)]
[Thread 0xb77ffac0 (LWP 11257) exited]
[Detaching after fork from child process 11258]
[Detaching after fork from child process 11259]
[New Thread 0xab86aac0 (LWP 11260)]
[New Thread 0xa73f1ac0 (LWP 11261)]
[New Thread 0xa73b0ac0 (LWP 11262)]
[New Thread 0xa736fac0 (LWP 11263)]
[New Thread 0xa70ffac0 (LWP 11264)]
[New Thread 0xb77ffac0 (LWP 11265)]
[New Thread 0xa6effac0 (LWP 11266)]
[New Thread 0xa64ffac0 (LWP 11269)]
[Detaching after fork from child process 11270]
[New Thread 0xabdb2ac0 (LWP 11271)]
[New Thread 0xa66b8ac0 (LWP 11272)]
[New Thread 0xa732eac0 (LWP 11273)]
[New Thread 0xa6677ac0 (LWP 11274)]
[New Thread 0xa52ffac0 (LWP 11277)]
[New Thread 0xa5100ac0 (LWP 11278)]
[New Thread 0xa5cfeac0 (LWP 11279)]
[New Thread 0xa5cbdac0 (LWP 11280)]
[New Thread 0xa5c7cac0 (LWP 11281)]
[New Thread 0xa4ab9ac0 (LWP 11282)]
[Thread 0xa64ffac0 (LWP 11269) exited]
[Thread 0xa4ab9ac0 (LWP 11282) exited]
[New Thread 0xa4ab9ac0 (LWP 11283)]
[New Thread 0xa64ffac0 (LWP 11284)]
[New Thread 0xa4258ac0 (LWP 11285)]
[Thread 0xa64ffac0 (LWP 11284) exited]
[New Thread 0xa64ffac0 (LWP 11286)]
[Thread 0xa4258ac0 (LWP 11285) exited]
[Thread 0xa4ab9ac0 (LWP 11283) exited]
[Thread 0xa64ffac0 (LWP 11286) exited]
[New Thread 0xa64ffac0 (LWP 11287)]
[New Thread 0xa4ab9ac0 (LWP 11288)]
[New Thread 0xa4258ac0 (LWP 11289)]
[Thread 0xa4ab9ac0 (LWP 11288) exited]
[Thread 0xa4258ac0 (LWP 11289) exited]
[New Thread 0xa3a4aac0 (LWP 11290)]
[New Thread 0xa38ffac0 (LWP 11291)]
[New Thread 0xa4258ac0 (LWP 11292)]
[New Thread 0xa4ab9ac0 (LWP 11293)]
[New Thread 0xa36ffac0 (LWP 11294)]
[New Thread 0xa32ffac0 (LWP 11295)]
[New Thread 0xa38beac0 (LWP 11296)]
[New Thread 0xa386dac0 (LWP 11297)]
[New Thread 0xa2a4cac0 (LWP 11298)]
[New Thread 0xa23ffac0 (LWP 11299)]
[Thread 0xa66b8ac0 (LWP 11272) exited]
[New Thread 0xa2250ac0 (LWP 11300)]
[New Thread 0xa66b8ac0 (LWP 11301)]
[New Thread 0xa16ffac0 (LWP 11302)]
[New Thread 0xa16beac0 (LWP 11303)]
[New Thread 0xa167dac0 (LWP 11304)]
[New Thread 0xa163cac0 (LWP 11305)]
[New Thread 0xa15fbac0 (LWP 11306)]
[New Thread 0xa15baac0 (LWP 11307)]
[New Thread 0xa1579ac0 (LWP 11308)]
[New Thread 0xa13ffac0 (LWP 11309)]
[Thread 0xa13ffac0 (LWP 11309) exited]
[Thread 0xa5cfeac0 (LWP 11279) exited]
[New Thread 0xa13beac0 (LWP 11310)]
[New Thread 0xa137dac0 (LWP 11311)]
[New Thread 0xa0effac0 (LWP 11312)]
[Thread 0xa13beac0 (LWP 11310) exited]
[Thread 0xa137dac0 (LWP 11311) exited]
[Thread 0xa0effac0 (LWP 11312) exited]
[New Thread 0xa0effac0 (LWP 11313)]
[New Thread 0xa137dac0 (LWP 11314)]
[New Thread 0xa3827ac0 (LWP 11315)]
[New Thread 0xa04ffac0 (LWP 11316)]
[New Thread 0xa02feac0 (LWP 11317)]
[New Thread 0xa00fdac0 (LWP 11318)]
[New Thread 0x9fcffac0 (LWP 11319)]
[New Thread 0xa13beac0 (LWP 11320)]
[New Thread 0xa5cfeac0 (LWP 11321)]
[Detaching after fork from child process 11322]
[New Thread 0xa13ffac0 (LWP 11324)]
[New Thread 0xa0e55ac0 (LWP 11326)]
[New Thread 0xa07ffac0 (LWP 11327)]
[New Thread 0x9efffac0 (LWP 11339)]
[New Thread 0x9edfeac0 (LWP 11340)]
[New Thread 0xa07beac0 (LWP 11341)]
[New Thread 0xa077dac0 (LWP 11342)]
[New Thread 0x9e9ffac0 (LWP 11343)]
[New Thread 0x9fe88ac0 (LWP 11344)]
[New Thread 0x9fe47ac0 (LWP 11345)]
[Thread 0xa5cbdac0 (LWP 11280) exited]
[New Thread 0x98cffac0 (LWP 11346)]
[New Thread 0xa5cbdac0 (LWP 11347)]
[Detaching after fork from child process 11348]
[New Thread 0xa0ea5ac0 (LWP 11349)]
[New Thread 0x9e09bac0 (LWP 11358)]
[New Thread 0x9e05aac0 (LWP 11364)]
[New Thread 0x97891ac0 (LWP 11365)]
[New Thread 0x1ac0 (LWP 11366)]
[New Thread 0x99950ac0 (LWP 11367)]
[New Thread 0x97850ac0 (LWP 11373)]
[New Thread 0x9678bac0 (LWP 11374)]
[New Thread 0xa0e64ac0 (LWP 11375)]
[New Thread 0x95dffac0 (LWP 11376)]
[New Thread 0x95bfeac0 (LWP 11377)]
[New Thread 0x959fdac0 (LWP 11378)]
[Detaching after fork from child process 11379]
[New Thread 0x967ffac0 (LWP 11381)]
[New Thread 0x952ffac0 (LWP 11383)]
[New Thread 0x9674aac0 (LWP 11398)]
[New Thread 0x957fcac0 (LWP 11399)]
[New Thread 0x9eb94ac0 (LWP 11412)]
[Thread 0x967ffac0 (LWP 11381) exited]

###!!! [Parent][MessageChannel] Error: 
(msgtype=0x390145,name=PContent::Msg_AsyncMessage) Channel error: cannot 
send/recv

[Detaching after fork from child process 11414]
[New Thread 0x917ffac0 (LWP 11415)]
[Thread 

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgradel

[Thorsten Glaser]

On Wed, 20 Oct 2021, Mark Hindley wrote:

> As Ian said previously, we are clearly still missing something here. I am 
> pretty much in
> the dark and clutching at straws. But what filesystem are you using? My
> /var/cache/pbuilder is ext3.

Oh wow.

Mine is on:
/dev/mapper/vg--tglase-lv--tglase on / type ext4 (rw,relatime)

> I am afraid I am still unable to reproduce this behaviour in my own or your
> supplied chroot.

Also not with my supplied chroot‽ So it’s nothing about differences
in the chroot either… good to know, but puzzling for this issue.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgradel

[Mark Hindley]

Thorsten,

Thanks for this and sorry for taking some time to actually get round to trying
it.

On Wed, Oct 06, 2021 at 08:16:40PM +0200, Thorsten Glaser wrote:
> On Wed, 6 Oct 2021, Thorsten Glaser wrote:
> 
> > So I can verify this behaviour in an otherwise clean chroot.
> 
> And https://mops.tarent.de/.tmp/base.cow-bullseye-amd64.tar.xz is the
> chroot, just in case it is something about that as well.

I am afraid I am still unable to reproduce this behaviour in my own or your
supplied chroot.

The only thing that happens is a reordering of the .depend* files on the first
insserv invocation.  After that, there are no changes on subsequent runs.

mark@apollo:/var/cache/pbuilder% sudo tar xJf 
~/Downloads/base.cow-bullseye-amd64.tar.xz
mark@apollo:~% sudo cp /tmp/etc-stripped.tgz 
/var/cache/pbuilder/build/cow.23212/tmp/
mark@apollo:~% cdiff --stat  
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{,1}
 .../init.d/.depend.boot| 20 -
 .../init.d/.depend.start   | 26 +++---
 .../init.d/.depend.stop| 14 ++--
 3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat  
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,2}
 .../init.d/.depend.boot| 20 -
 .../init.d/.depend.start   | 26 +++---
 .../init.d/.depend.stop| 14 ++--
 3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat  
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,3}
 .../init.d/.depend.boot| 20 -
 .../init.d/.depend.start   | 26 +++---
 .../init.d/.depend.stop| 14 ++--
 3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat  
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,4}
 .../init.d/.depend.boot| 20 -
 .../init.d/.depend.start   | 26 +++---
 .../init.d/.depend.stop| 14 ++--
 3 files changed, 30 insertions(+), 30 deletions(-)
mark@apollo:~% cdiff --stat 
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{2,3}
mark@apollo:~% cdiff --stat 
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{2,4}
mark@apollo:~% cdiff --stat -u 
/var/cache/pbuilder/build/cow.23212/tmp/etc-stripped{1,2}
 .../init.d/.depend.boot| 20 -
 .../init.d/.depend.start   | 26 +++---
 .../init.d/.depend.stop| 14 ++--
 3 files changed, 30 insertions(+), 30 deletions(-)
 
diff --git 
var/cache/pbuilder/build/cow.23212/tmp/etc-stripped1/init.d/.depend.boot 
var/cache/pbuilder/build/cow.23212/tmp/etc-stripped2/i
nit.d/.depend.boot  
 
index 3fc1825..54d3471 100644
--- var/cache/pbuilder/build/cow.23212/tmp/etc-stripped1/init.d/.depend.boot
+++ var/cache/pbuilder/build/cow.23212/tmp/etc-stripped2/init.d/.depend.boot
@@ -1,4 +1,4 @@  
-TARGETS = mountkernfs.sh udev mountdevsubfs.sh keyboard-setup.sh bootlogd 
hwclock.sh hostname.sh checkroot.sh cryptdisks-early cryptdisks
 networking mountnfs.sh mountnfs-bootclean.sh mountall.sh mountall-bootclean.sh 
lvm2 x11-common early-rng-init-tools urandom brightness al
sa-utils checkfs.sh checkroot-bootclean.sh screen-cleanup stop-bootlogd-single 
bootmisc.sh mount-configfs kmod procps lm-sensors 
+TARGETS = mountkernfs.sh udev mountdevsubfs.sh keyboard-setup.sh bootlogd 
hwclock.sh hostname.sh checkroot.sh cryptdisks-early cryptdisks
 mountnfs.sh mountnfs-bootclean.sh mountall.sh mountall-bootclean.sh brightness 
networking lvm2 checkfs.sh urandom x11-common early-rng-in
it-tools alsa-utils mount-configfs kmod bootmisc.sh procps screen-cleanup 
stop-bootlogd-single lm-sensors checkroot-bootclean.sh 
 INTERACTIVE = udev keyboard-setup.sh checkroot.sh cryptdisks-early cryptdisks 
checkfs.sh
 udev: mountkernfs.sh
 mountdevsubfs.sh: udev
@@ -9,23 +9,23 @@ hostname.sh: bootlogd
 checkroot.sh: hostname.sh keyboard-setup.sh
 cryptdisks-early: checkroot.sh udev
 cryptdisks: cryptdisks-early lvm2
-networking: mountkernfs.sh mountall.sh mountall-bootclean.sh urandom procps
 mountnfs.sh: mountall.sh mountall-bootclean.sh networking
 mountnfs-bootclean.sh: mountall.sh mountall-bootclean.sh mountnfs.sh
-mountall.sh: checkfs.sh checkroot-bootclean.sh
+mountall.sh: lvm2 checkfs.sh checkroot-bootclean.sh
 mountall-bootclean.sh: mountall.sh
+brightness: mountall.sh mountall-bootclean.sh
+networking: mountkernfs.sh mountall.sh mountall-bootclean.sh urandom procps
 lvm2: cryptdisks-early bootlogd
+checkfs.sh: checkroot.sh 

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[David Bremner]

Sean Whitton  writes:
>
> I hereby call for votes on the following ballot to resolve #994275.  The
> voting period starts immediately and lasts for up to one week, or until
> the outcome is no longer in doubt (Constitution 6.3.1).
>
> === Resolution A ===
>
> The Technical Committee resolves:
>
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
>
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
>
> 2. The which(1) program must not print any deprecation warnings.
>
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
>
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
>
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
>
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
>
> === Resolution B ===
>
> As Resolution A, except strike point (2) and renumber succeeding items.
>
> === End Resolutions ===
>
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion
>
> -- 
> Sean Whitton

I vote B > A > F



signature.asc
Description: PGP signature

Bug#996921: RFA: unifrac

[Nilesh Patra]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-...@lists.debian.org

Hi,

I currently have no interest in maintaining unifrac, which
is a bit cumbersome to maintain (the new update being an example)
and it doesn't motivate me enough to keep maintaining it.

Should you feel motivated, feel free to adopt this one.

Package Description:

 ---  High-performance phylogenetic diversity calculations ---
 The de facto repository for high-performance phylogenetic diversity
 calculations. The methods in this repository are based on an
 implementation of the Strided State UniFrac algorithm which is faster,
 and uses less memory than Fast UniFrac. Strided State UniFrac supports
 Unweighted UniFrac, Weighted UniFrac, Generalized UniFrac, Variance
 Adjusted UniFrac and meta UniFrac. This repository also includes Stacked
 Faith (manuscript in preparation), a method for calculating Faith's PD
 that is faster and uses less memory than the Fast UniFrac-based
 reference implementation.


Nilesh

Bug#996909: [Pkg-javascript-devel] Bug#996909: Bug#996909: acorn: Invalid package section for node-debbundle-acorn

[Mattia Rizzolo]

On Wed, Oct 20, 2021 at 08:47:51PM +0200, Bastien ROUCARIES wrote:
> Go nmu
> 
> I will be far from a computer a few days...
> 
> Do no t forger to apply to salsa or at least do a merge request

There is no actual urgency to fix it since in ubuntu they already made
an upload there to workaround it.

I pushed the fix, but I'll leave the upload to you (or others) whenever
you see fit.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#995271: Same error

[Irfan Ali-Khan]

Hi, I’m trying to install the same nvidia driver on bookworm 5.14 and
getting the same error. Is there another command for the new drivers?  I’m
using both apt-get install nvidia-driver and the non-free version, both
give same error of config issues for dkms. Please advise, thanks in
advance!

Bug#996920: RFS: glm/0.9.9.8+ds-2 [RC] [Team] -- documentation for the OpenGL Mathematics (GLM) library

[Leandro Cunha]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: glm
   Version : 0.9.9.8+ds-2
   Upstream Author : Christophe Riccio 
 * URL : https://glm.g-truc.net/
 * License : Expat
 * Vcs : https://salsa.debian.org/science-team/glm
   Section : libs

It builds those binary packages:

  libglm-dev - C++ library for OpenGL GLSL type-based mathematics
  libglm-doc - documentation for the OpenGL Mathematics (GLM) library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/g/glm/glm_0.9.9.8+ds-2.dsc

Changes since the last upload:

 glm (0.9.9.8+ds-2) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Leandro Cunha ]
   * Add debian/salsa-ci.yml.
   * Add debian/upstream/metadata.
   * debian/control:
 - Update debhelper-compat old 12 to 13.
 - Bump Standards-Version 4.6.0.
 .
   [ Lukas Märdian ]
   * Add d/p/00-tests-no-optimization.patch to fix FTBFS with
 GCC-11. (LP: #1946750, Closes: #996241)

Regards,
-- 
  Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#996712: libcache-memcached-fast-perl: autopkgtest failure on armhf: Fetched all keys / Match results

[gregor herrmann]

On Sun, 17 Oct 2021 18:40:24 +0200, Paul Gevers wrote:

> You recently added an autopkgtest to your package
> libcache-memcached-fast-perl, great. However, it fails on armhf.
> Currently this failure is blocking the migration to testing [1]. Can you
> please investigate the situation and fix it?

I don't know what exacatly is going on, but I note that it now also
fails on amd64.

I was a bit surprised that the same tests pass during build but the
explanation is simple: They are skipped as no memcached is running …

Guess mode: Either the tests or the code are incompatible with the
current memcached version, or the tests are not supposed to be run
against a production memcached (not started by the package).
 

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


signature.asc
Description: Digital Signature

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Sean Whitton]

On Wed 20 Oct 2021 at 12:30PM -07, Sean Whitton wrote:

> === Resolution A ===
>
> The Technical Committee resolves:
>
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
>
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
>
> 2. The which(1) program must not print any deprecation warnings.
>
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
>
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
>
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
>
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
>
> === Resolution B ===
>
> As Resolution A, except strike point (2) and renumber succeeding items.
>
> === End Resolutions ===
>
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion

I vote:

A > B > F

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Sean Whitton]

Hello,

I hereby call for votes on the following ballot to resolve #994275.  The
voting period starts immediately and lasts for up to one week, or until
the outcome is no longer in doubt (Constitution 6.3.1).

=== Resolution A ===

The Technical Committee resolves:

1. The debianutils package must continue to provide the which(1) program
   until a compatible utility is available in a package that is at least
   transitively essential in Debian 12.

   For the Debian 12 release, we expect which(1) to be in either an
   Essential package or a transitively Essential package (that is, a
   package that is depended on by an Essential package).

2. The which(1) program must not print any deprecation warnings.

3. We decline to overrule the maintainer of debianutils regarding the
   use of alternatives.  If another package takes over responsibility
   for which(1), then the debianutils maintainers and the other
   package's maintainers should coordinate to choose a suitable
   mechanism, which might be either versioned Depends/Breaks/Replaces,
   dpkg-divert, alternatives or something else.

4. The debianutils package must continue to provide the tempfile(1)
   program until a compatible utility is available in a package that is
   at least transitively essential in Debian 12.

   For the Debian 12 release, we expect tempfile(1) to be in either an
   Essential package or a transitively Essential package.

5. Programs in debianutils must not be moved to /usr until we have a
   project-wide consensus on going ahead with such a move, and any
   programs that have already been moved must be moved back.  In
   particular, this means debianutils must contain /bin/run-parts and
   /sbin/installkernel for the time being.

=== Resolution B ===

As Resolution A, except strike point (2) and renumber succeeding items.

=== End Resolutions ===

A: Issue Resolution A
B: Issue Resolution B
F: Further Discussion

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#985201: flameshot: Unable to Capture Screen - GNOME 41 Wayland session

[SDA]

Package: flameshot
Version: 0.10.1+ds1-1
Followup-For: Bug #985201
X-Debbugs-Cc: marathon.duran...@gmail.com

Dear Maintainer,

Same behaviour, same message. 'Unable to Capture Screen'
Happens in both the .deb package and Flatpak. HTH

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

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

Versions of packages flameshot depends on:
ii  hicolor-icon-theme0.17-2
ii  libc6 2.32-4
ii  libgcc-s1 11.2.0-9
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5dbus5   5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5network55.15.2+dfsg-12
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-12
ii  libspdlog1 [libspdlog1-fmt7]  1:1.8.5+ds-3
ii  libstdc++611.2.0-9

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20211016
ii  openssl  1.1.1l-1

-- no debconf information

Bug#994762: warnings about session IDs

[Ian Campbell]

On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
> And I can confirm it works, or at least does not warn.

Excellent, thanks.

Is the diff as simple as:

   $ git diff
   diff --git a/doc/xss-lock.service b/doc/xss-lock.service
   index 52086c8..37d733e 100644
   --- a/doc/xss-lock.service
   +++ b/doc/xss-lock.service
   @@ -4,7 +4,7 @@ PartOf=graphical-session.target

[Service]
Type=simple
   -ExecStart=/usr/bin/xss-lock -l -s ${GRAPHICAL_SESSION_ID} -- i3lock
   +ExecStart=/usr/bin/xss-lock -l -s ${XDG_SESSION_ID} -- i3lock

[Install]
WantedBy=graphical-session.target
   
?

Bug#996907: xfce4-power-manager: Screen blank is active but not configurable when xfce4-power-manager is NOT installed

[Phil Endecott]

Package: xfce4-power-manager
Version: 4.16.0-1
Severity: normal

Dear Maintainer,

I did a miminal install of xfce, i.e. "apt-get install xfce4", which 
did NOT install xfce4-power-manager.

The resulting system had screen blank configured to activate after 
10 minutes, but there was no settings panel to adjust or disable 
this.

After a lot of googling and trial-and-error I discovered that the 
display power management settings are part of this xfce4-power-manager 
package. After installing this, I was able to adjust the timeouts.

It seems to me that (1) maybe screen blank settings should be installed 
as part of a default xfce4 install, and/or (2) if the screen blank 
settings panel is not installed, then screen blank should be disabled 
by default.


Regards, Phil.

Bug#996869: mail.debian.org: https://postgrey.schweikert.ch/help/bugs.debian.org.html contact email broken

[Adam D. Barratt]

On Wed, 2021-10-20 at 10:01 +0300, Andrei POPESCU wrote:
> Control: reassign -1 bugs.debian.org
> 
> On Ma, 19 oct 21, 18:28:43, Thomas Groman wrote:
[...]
> > Upon sending to b...@debian.org I encountered the following message
> > in my log files:
> > "relay="[2607:f8f0:614:1::1274:39] (buxtehude.debian.org)" delay=5s
> > result="TempFail" stat="451 Greylisted, see 
> > http://postgrey.schweikert.ch/help/bugs.debian.org.html;
> > 
> > Upon going to the URL listed it has a friendly webpage Postgrey
> > help with 
> > information on who to contact for help. The email listed for
> > contact is "[email protected]". 
> > [email protected] is not a valid email address and should anyone
> > attempt to 
> > email [email protected] mail would not go through and help would
> > not be recieved.

Note that the page listed is not maintained by anyone in Debian, but by
the upstream provider of the postgrey software.

Looking at the source of the page, it appears that this is because some
Javascript is used to replace the "[email protected]" text with the
relevant address (although I suspect it always just uses 
postmaster@domain), and you are presumably not allowing that script to
load.

I suspect that the only way that will change is if you ask the provider
to make their page work without script.

Regards,

Adam

Bug#996867: openjdk-17-jre-headless: Update to version "17+35"

[anna]

Control: fixed -1 openjdk-17/17+35-1

Bug#996909: [Pkg-javascript-devel] Bug#996909: acorn: Invalid package section for node-debbundle-acorn

[Bastien ROUCARIES]

Go nmu

I will be far from a computer a few days...

Do no t forger to apply to salsa or at least do a merge request

Thanks

Le mer. 20 oct. 2021 à 18:06, Steve Langasek 
a écrit :

> Package: acorn
> Version: 8.5.0+ds+~cs24.17.6-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
>
> Hi Bastien,
>
> The latest version of acorn has node-debbundle-acorn listed in Section:
> oldlib.  This is invalid; the correct section name is 'oldlibs'.  In the
> Debian archive, this is not an issue because the Debian archive applies
> overrides to all packages (indeed, I see the archive still lists this
> package as 'Section: javascript'), but in Ubuntu this blocks the binary
> package from being uploaded.  So I have applied the attached patch for
> Ubuntu, which should also be correct for Debian.
>
> Cheers,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#996867: openjdk-17-jre-headless: Correct affected versions

[anna]

Package: openjdk-17-jre-headless
Version: 17~19-1
Followup-For: Bug #996867

Bug#996797: solution found

[Armin Fuerst]

I found the solution to this issue:
in /etc/ssl/certs, there must be a symlink to 
"DigiCert_Global_Root_CA.pem" named "3513523f.0"
Reinstalling ca-certificates was not sufficient, because following link 
was existing:
DigiCert_Global_Root_CA.pem -> 
/usr/share/ca-certificates/mozilla/DigiCert_Global_Root_CA.crt
After deleting this link and reinstalling ca-certificates, the 
certificate could be verified successfully.

Bug#892730: nslcd: Please add systemd .service file

[Trent W. Buck]

Michael Biebl wrote:
> Am 12.03.2018 um 11:26 schrieb Laurent Bigonville:
> > Package: nslcd
> > Version: 0.9.9-1
> > Severity: normal
> > User: pkg-systemd-maintain...@lists.alioth.debian.org
> > Usertags: systemd-units
> > 
> > Hi,
> > 
> > nslcd currently doesn't provides a systemd .service file.
> > 
> > This is a problem as nslcd should order itself with the
> > nss-lookup.target and/or nss-user-lookup.target (see systemd.special(7)
> > manpage).
> 
> Well, the SysV init has
> 
> # Should-Start:  $named
> 
> So the generated .service file should already have an
> After=nss-lookup.target ordering. Are you saying this is incorrect?
> If so, is the SysV init script incorrect as well?

I think the current behaviour is wrong.
systemd's sysvinit generator treats any reference to $named as "I depend on 
named", but
in this case you're trying to say "I am named".

i.e. it should be Before=nss-lookup.target not After=nss-lookup.target.

In any case, I think either is DEFINITELY WRONG for the common case of RFC2307
users and groups, i.e. "passwd: files ldap"   In that case it should be 
nss-user-lookup.target.


Attached is my first rough draft for a native systemd nslcd.service.
I haven't done much testing yet; this ticket isn't a priority for me.
I tested on Debian 11 (pam-nss-ldapd=0.9.11-1).
# FIXME: can/should nslcd be socket-activated?
#In the typical use case of "passwd: files ldap", this
#allows nslcd to avoid starting until the first remote user login (or 
similar).
#I don't see an option like "nslcd --inetd" which would implement this.
#
# FIXME: /etc/init.d/nslcd has kerberos integration which I'm not even TRYING 
to reproduce here.
#Something like this as "nslcd-k5start.service"...
#
#[Unit]
#Description="Keep alive Kerberos ticket"
#PartOf=nslcd.service
#Environment=K5START_BIN=/usr/bin/k5start
#Environment=K5START_PIDFILE=$NSLCD_STATEDIR/k5start_nslcd.pid
#Environment=K5START_MODE=600
#Environment=K5START_KEYTAB=/etc/krb5.keytab
#Environment=K5START_CCREFRESH=60
#Environment=K5START_PRINCIPAL="host/$(hostname -f)"
#Environment=K5START_CCFILE=$(sed -n 
's/^krb5_ccname[[:space:]]*\(FILE:\)\?\([^:[:space:]]*\)[[:space:]]*$/\2/ip' 
$NSLCD_CFG)
#EnvironmentFile=-/etc/default/nslcd
#ConditionEnvironment=K5START_START=yes
#[Install]
#WantedBy=nslcd.service
#[Service]
#User=nslcd
#ExecStart=$K5START_BIN -b -p $K5START_PIDFILE -o $K5START_USER -g 
$K5START_GROUP -m $K5START_MODE -f $K5START_KEYTAB -K $K5START_CCREFRESH -u 
$K5START_PRINCIPAL -k $K5START_CCFILE


[Unit]
Description=LDAP connection daemon

# FIXME: I'm really not sure if this is the right place to inject a low-level 
daemon.
# Need to compare with other stuff like systemd-resolved.service...
[Install]
WantedBy=multi-user.target

# Needed unless your nslcd.conf has a local LDAP server, e.g.
#   uri ldapi:///
#   uri ldap://localhost
[Unit]
Wants=network-online.target

# Needed if your nsswitch.conf has "ldap" in any of
#   passwd group shadow gshadow
# FIXME: is "Wants" right here???
#cf. systemd-user-sessions.service
[Unit]
Before=nss-user-lookup.target
Wants=nss-user-lookup.target

# Needed if your nsswitch.conf has "ldap" in any of
#   hosts networks protocols service ethers rpc
# FIXME: is "Wants" right here???
#cf. systemdsystemd-resolved.service
[Unit]
Before=nss-lookup.target
Wants=nss-lookup.target


[Service]
Type=forking
ExecStart=
ExecStart=nslcd

# This replaces "uid nslcd" and "gid nslcd" in /etc/nslcd.conf.
# The "Group=nslcd" is implied as that is nslcd user's default group.
# NOTE: because of this, /etc/nslcd.conf must be readable by user/group nslcd.
#   In Debian 11 sysvinit script "root:root 0400 nslcd.conf" works because 
priv drop happens later.
User=nslcd

# This also has to move into the systemd unit due to early priv drop:
OomScoreAdjust=-1000

# SIGUSR1: Cause nslcd to retry any failing connections to the LDAP server, 
regardless of the reconnect_sleeptime and reconnect_retrytime options.
# I'm 80% sure this is a confusing and bad idea, since it doesn't reread 
nslcd.conf.
ExecReload=kill -USR1 $MAINPID

# nslcd listens to /run/nslcd/socket and creates /run/nslcd/nslcd.pid.
# We can tell systemd about this.
RuntimeDirectory=nslcd
WorkingDirectory=/run/nslcd


# Additional security lockdown (optional).
# $ systemd-analyze security nslcd:
# → Overall exposure level for nslcd.service: 1.2 OK 
[Service]
CapabilityBoundingSet=
RestrictAddressFamilies=AF_UNIX AF_INET AF_INTE6
DevicePolicy=closed
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
RestrictSUIDSGID=yes

Bug#996919: deborphan: incorrectly guesses package dependencies as orphan

[Martin-Éric Racine]

Package: deborphan
Version: 1.7.35
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

$ LC_ALL=C sudo apt-get --option Debug::pkgDepCache::AutoInstall=true install 
ubuntu-dev-tools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ignore old unsatisfied important dependency on debian-keyring:i386
  Installing distro-info:i386 as Depends of ubuntu-dev-tools:i386
  Installing python3-launchpadlib:i386 as Depends of ubuntu-dev-tools:i386
Installing python3-keyring:i386 as Depends of python3-launchpadlib:i386
  Installing python3-importlib-metadata:i386 as Depends of 
python3-keyring:i386
Installing python3-zipp:i386 as Depends of 
python3-importlib-metadata:i386
  Installing python3-more-itertools:i386 as Depends of python3-zipp:i386
  Installing python3-jeepney:i386 as Depends of python3-keyring:i386
  Installing python3-secretstorage:i386 as Depends of python3-keyring:i386
Installing python3-cryptography:i386 as Depends of 
python3-secretstorage:i386
  Installing python3-cffi-backend:i386 as Depends of 
python3-cryptography:i386
Installing python3-lazr.restfulclient:i386 as Depends of 
python3-launchpadlib:i386
  Installing python3-lazr.uri:i386 as Depends of 
python3-lazr.restfulclient:i386
  Installing python3-wadllib:i386 as Depends of 
python3-lazr.restfulclient:i386
  Installing python3-oauthlib:i386 as Depends of 
python3-lazr.restfulclient:i386
Installing python3-blinker:i386 as Depends of python3-oauthlib:i386
  Installing python3-ubuntutools:i386 as Depends of ubuntu-dev-tools:i386
  Installing genisoimage:i386 as Recommends of ubuntu-dev-tools:i386
  Installing python3-dns:i386 as Recommends of ubuntu-dev-tools:i386
The following additional packages will be installed:
  distro-info genisoimage python3-blinker python3-cffi-backend 
python3-cryptography python3-dns python3-importlib-metadata python3-jeepney 
python3-keyring python3-launchpadlib
  python3-lazr.restfulclient python3-lazr.uri python3-more-itertools 
python3-oauthlib python3-secretstorage python3-ubuntutools python3-wadllib 
python3-zipp
Suggested packages:
  shunit2 wodim cdrkit-doc python-blinker-doc python-cryptography-doc 
python3-cryptography-vectors gir1.2-secret-1 gnome-keyring libkf5wallet-bin 
python3-keyrings.alt
  python3-testresources python-secretstorage-doc qemu-user-static
Recommended packages:
  debian-keyring
The following NEW packages will be installed:
  distro-info genisoimage python3-blinker python3-cffi-backend 
python3-cryptography python3-dns python3-importlib-metadata python3-jeepney 
python3-keyring python3-launchpadlib
  python3-lazr.restfulclient python3-lazr.uri python3-more-itertools 
python3-oauthlib python3-secretstorage python3-ubuntutools python3-wadllib 
python3-zipp ubuntu-dev-tools
0 upgraded, 19 newly installed, 0 to remove and 0 not upgraded.
Need to get 1421 kB of archives.
After this operation, 6456 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian unstable/main i386 distro-info i386 1.0 
[20.6 kB]
Get:2 http://deb.debian.org/debian unstable/main i386 genisoimage i386 
9:1.1.11-3.2 [393 kB]
Get:3 http://deb.debian.org/debian unstable/main i386 python3-blinker all 
1.4+dfsg1-0.3 [14.1 kB]
Get:4 http://deb.debian.org/debian unstable/main i386 python3-cffi-backend i386 
1.15.0-1 [89.8 kB]
Get:5 http://deb.debian.org/debian unstable/main i386 python3-cryptography i386 
3.3.2-1 [208 kB]
Get:6 http://deb.debian.org/debian unstable/main i386 python3-dns all 3.2.1-1 
[27.5 kB]
Get:7 http://deb.debian.org/debian unstable/main i386 python3-more-itertools 
all 4.2.0-3 [42.7 kB]
Get:8 http://deb.debian.org/debian unstable/main i386 python3-zipp all 1.0.0-3 
[6060 B]
Get:9 http://deb.debian.org/debian unstable/main i386 
python3-importlib-metadata all 4.6.4-1 [22.5 kB]
Get:10 http://deb.debian.org/debian unstable/main i386 python3-jeepney all 
0.6.0-1 [27.8 kB]
Get:11 http://deb.debian.org/debian unstable/main i386 python3-secretstorage 
all 3.3.1-1 [16.5 kB]
Get:12 http://deb.debian.org/debian unstable/main i386 python3-keyring all 
23.2.0-1 [52.2 kB]
Get:13 http://deb.debian.org/debian unstable/main i386 python3-lazr.uri all 
1.0.6-1 [15.3 kB]
Get:14 http://deb.debian.org/debian unstable/main i386 python3-wadllib all 
1.3.6-1 [41.7 kB]
Get:15 http://deb.debian.org/debian unstable/main i386 python3-oauthlib all 
3.1.1-1 [93.6 kB]
Get:16 http://deb.debian.org/debian unstable/main i386 
python3-lazr.restfulclient all 0.14.4-1 [57.1 kB]
Get:17 http://deb.debian.org/debian unstable/main i386 python3-launchpadlib all 
1.10.14-1 [58.8 kB]
Get:18 http://deb.debian.org/debian unstable/main i386 python3-ubuntutools all 
0.185 [99.9 kB]
Get:19 http://deb.debian.org/debian unstable/main i386 ubuntu-dev-tools all 
0.185 [135 kB]
Fetched 1421 kB in 0s (7921 kB/s)  
Selecting previously unselected package 

Bug#996904: doas: Add pam_limit.so to PAM configuration (Cf. #518464 for sudo)

[Salvatore Bonaccorso]

Control: tags -1 + patch

On Wed, Oct 20, 2021 at 04:56:02PM +0200, Salvatore Bonaccorso wrote:
> Source: doas
> Version: 6.8.1-2
> Severity: important
> Tags: security
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi
> 
> It looks that doas replicates the PAM configuration from sudo, which
> is missing the inclusion for pam_limits.so (cf. #518464).
> 
> The oss-security post in
> https://www.openwall.com/lists/oss-security/2021/10/20/2 given some
> details on why.
> 
> For sudo I created the following merge request
> https://salsa.debian.org/sudo-team/sudo/-/merge_requests/7 and can
> sent as similar change for 'doas' if needed.

Merge request at https://salsa.debian.org/debian/doas/-/merge_requests/2

Regards,
Salvatore

Bug#994967: r-cran-googlesheets4_1.0.0-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Andreas,


On 19.10.21 19:46, Andreas Tille wrote:

do you have an idea which package contains roxygen2, which is used to create 
googlesheets4-package.Rd?
The term "package" in CRAN terminology is usually what we have as a 
r-cran-CRANPACKAGE so this
is r-cran-roxygen2.


aaah, ok , I did find this.




Anyway, upstream has different ideas about the copyright holder in 
googlesheets4-package.Rd and LICENSE.
There seems to be room for improvement.

On what string is your statement based?  The copyright holder of the
automatically generated file should be the same as the source, shouldn't
it.


Yes, it is not the copyright of that file but its contents.

 googlesheets4-package.Rd  says: "\item RStudio [copyright holder, funder]"
 LICENSE says:  COPYRIGHT HOLDER: Jennifer Bryan and RStudio

So I would say that Jennifer Bryan is paid by RStudio for the work on 
r-cran-googlesheets4, but RStudio is the only copyright holder.



For the moment I've added a separate

Files: man/googlesheets4-package.Rd

paragraph even if I do not see any actual reason for it.


Neither do I, sorry.

   Thorsten

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Tomasz Wolak]

Hi Gianfranco,

Thanks for having a look at the issue.

On Thu, 14 Oct 2021 19:17:53 +0200 Gianfranco Costamagna 
 wrote:

> Hello Tomasz
> […]
> can you please check if 0.7.0 in debian/experimental fixes this issue?
> The cmake scripts have been reworked, and I can't see anymore the 
variable not correctly evaluated.

>
> In case please let me know if the bug is fixed
>
> thanks
>
> Gianfranco
>

I have tried to build the source package 0.7.0 
(https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian 
(bullseye), but unfortunately building the package fails with:



nm --dynamic --defined-only build-shared/libyaml-cpp.so | awk '$2 ~ /W/ 
{ print " " $3 "@Base 0.7.0" } ' > debian/weak-symbols

dh_makeshlibs -VNone
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the 
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libyaml-cpp0.7/DEBIAN/symbols doesn't 
match completely debian/libyaml-cpp0.7.symbols

[...]
dh_makeshlibs: error: failing due to earlier errors
make[1]: *** [debian/rules:62: override_dh_makeshlibs] Error 25
make[1]: Leaving directory '/home/debian/tmp/yaml-cpp-0.7.0+dfsg'
make: *** [debian/rules:71: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess 
returned exit status 2

debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed


It passes compilation and tests but fails on the
"Install the project..." part.

In consequence, I cannot see what would be in the built package to be 
sure, but the configuration files for cmake seem to be generated. The 
contents of the generated file 
yaml-cpp-0.7.0+dfsg/build-shared/yaml-cpp-config.cmake

is as follows:


# - Config file for the yaml-cpp package
# It defines the following variables
#  YAML_CPP_INCLUDE_DIR - include directory
#  YAML_CPP_LIBRARIES- libraries to link against

# Compute paths
get_filename_component(YAML_CPP_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
set(YAML_CPP_INCLUDE_DIR "")

# Our library dependencies (contains definitions for IMPORTED targets)
include("${YAML_CPP_CMAKE_DIR}/yaml-cpp-targets.cmake")

# These are IMPORTED targets created by yaml-cpp-targets.cmake
set(YAML_CPP_LIBRARIES "")


so it does not seem correct (both include and libs settings are empty...).

I do not know the process of fixing bugs in Debian (ie. whether you 
rather backport a newer version from testing/unstable or fix current 
version), but at the moment it seems to me that it would be easier to 
fix the current package (0.6.3) and just make it usable with cmake than 
backporting 0.7.0 (which seems to have more complex issues when building 
on bullseye).


Cheers,
Tomasz

Bug#996918: hunspell: FTBFS: format not a string literal and no format arguments

[Sven Joachim]

Source: hunspell
Version: 1.7.0-3
Severity: serious
Tags: ftbfs bookworm sid patch

Your package FTBFS in unstable, here is the relevant part of my build
log:

,
| g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/hunspell -I../../src/hunspell 
-I../../src/parsers -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/usr/local/src/deb-src/hunspell/hunspell=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o munch.o 
munch.cxx
| hunspell.cxx: In function 'char* scanline(char*)':
| hunspell.cxx:584:9: error: format not a string literal and no format 
arguments [-Werror=format-security]
|   584 |   printw(message);
|   |   ~~^
`

This happened because ncurses added format attributes to several
functions, and dpkg-buildpackage defaults to -Werror=format-security.
For details about the ncurses change, see #993179.

I have attached a simple patch which could be added to the series in
debian/patches, but there are also a few warnings which might be worth
looking at.

From 91148a568c5994768e660ca5a968df16ae4a146c Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 20 Oct 2021 19:40:36 +0200
Subject: [PATCH] Fix string format error with recent ncurses

---
 src/tools/hunspell.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/tools/hunspell.cxx b/src/tools/hunspell.cxx
index 690e34a..b165634 100644
--- a/src/tools/hunspell.cxx
+++ b/src/tools/hunspell.cxx
@@ -581,7 +581,7 @@ const char* basename(const char* s, char c) {
 #ifdef HAVE_CURSES_H
 char* scanline(char* message) {
   char input[INPUTLEN];
-  printw(message);
+  printw("%s", message);
   echo();
   getnstr(input, INPUTLEN);
   noecho();
--
2.33.0

Bug#996917: blender: Please add support for riscv64

[Aurelien Jarno]

Package: blender
Version: 2.93.4+dfsg-1
Severity: wishlist
Tags: ftbfs upstream patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear maintainer,

kodi currently fails to build from source on riscv64 due to missing
support for this architecture [1]. There are two reasons for that:

- Missing upstream support for this architecture. This is something that
  has been fixed recently [2], however it is only available on the
  master branch.

- Unavailability of gold linker on riscv64 and broken upstream support
  for bfd linker. I have proposed a patch to fix that [3].

I have included the corresponding patches in a debdiff patch attached,
and verified that the resulting package build successfully on riscv64.
If you are fine with this patch, could you please consider applying it
for the future uploads? 

Regards,
Aurelien


[1] 
https://buildd.debian.org/status/fetch.php?pkg=blender=riscv64=2.93.4%2Bdfsg-1=1633013030=0
[2] https://developer.blender.org/rB468d59e496eb3263c1b0284459c03b599fe84a2a
[3] https://developer.blender.org/D12911
--- 
blender-2.93.4+dfsg/debian/patches/0006-add-support-for-risc-v-architecture.patch
+++ 
blender-2.93.4+dfsg/debian/patches/0006-add-support-for-risc-v-architecture.patch
@@ -0,0 +1,67 @@
+From 468d59e496eb3263c1b0284459c03b599fe84a2a Mon Sep 17 00:00:00 2001
+From: Heinrich Schuchardt 
+Date: Thu, 15 Jul 2021 14:22:08 +0200
+Subject: [PATCH] Add support for RISC-V architecture
+
+* On RISC-V GCC 10.3 does not define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_n.
+* Avoid a build error
+  "Please add support for your platform in build_config.h"
+  Cf: https://github.com/sergeyvfx/libNumaAPI/pull/3
+
+Differential Revision: https://developer.blender.org/D11910
+---
+ intern/atomic/intern/atomic_ops_unix.h |  6 +++---
+ intern/numaapi/source/build_config.h   | 13 +
+ 2 files changed, 16 insertions(+), 3 deletions(-)
+
+diff --git a/intern/atomic/intern/atomic_ops_unix.h 
b/intern/atomic/intern/atomic_ops_unix.h
+index dc1e71cda76..b08a0e9bc28 100644
+--- a/intern/atomic/intern/atomic_ops_unix.h
 b/intern/atomic/intern/atomic_ops_unix.h
+@@ -49,9 +49,9 @@
+ 
+ #include "atomic_ops_utils.h"
+ 
+-#if defined(__arm__)
+-/* Attempt to fix compilation error on Debian armel kernel.
+- * arm7 architecture does have both 32 and 64bit atomics, however
++#if defined(__arm__) || defined(__riscv)
++/* Attempt to fix compilation error on Debian armel and RISC-V kernels.
++ * Both architectures do have both 32 and 64bit atomics, however
+  * its gcc doesn't have __GCC_HAVE_SYNC_COMPARE_AND_SWAP_n defined.
+  */
+ #  define JE_FORCE_SYNC_COMPARE_AND_SWAP_1
+diff --git a/intern/numaapi/source/build_config.h 
b/intern/numaapi/source/build_config.h
+index fdd6ff704c3..49d82aa3e87 100644
+--- a/intern/numaapi/source/build_config.h
 b/intern/numaapi/source/build_config.h
+@@ -324,6 +324,16 @@
+ #  define ARCH_CPU_ARM64 1
+ #  define ARCH_CPU_64_BITS 1
+ #  define ARCH_CPU_LITTLE_ENDIAN 1
++#elif defined(__riscv) && __riscv_xlen == 32
++#  define ARCH_CPU_RISCV_FAMILY 1
++#  define ARCH_CPU_RISCV32 1
++#  define ARCH_CPU_64_BITS 0
++#  define ARCH_CPU_LITTLE_ENDIAN 1
++#elif defined(__riscv) && __riscv_xlen == 64
++#  define ARCH_CPU_RISCV_FAMILY 1
++#  define ARCH_CPU_RISCV64 1
++#  define ARCH_CPU_64_BITS 1
++#  define ARCH_CPU_LITTLE_ENDIAN 1
+ #elif defined(__pnacl__) || defined(__asmjs__) || defined(__wasm__)
+ #  define ARCH_CPU_32_BITS 1
+ #  define ARCH_CPU_LITTLE_ENDIAN 1
+@@ -381,6 +391,9 @@
+ #if !defined(ARCH_CPU_PPC64_FAMILY)
+ #  define ARCH_CPU_PPC64_FAMILY 0
+ #endif
++#if !defined(ARCH_CPU_RISCV_FAMILY)
++#  define ARCH_CPU_RISCV_FAMILY 0
++#endif
+ #if !defined(ARCH_CPU_S390_FAMILY)
+ #  define ARCH_CPU_S390_FAMILY 0
+ #endif
+-- 
+2.30.2
+
--- 
blender-2.93.4+dfsg/debian/patches/0007-cmake-fix-linking-with-with-x11-xf86vmode-and-bfd.patch
+++ 
blender-2.93.4+dfsg/debian/patches/0007-cmake-fix-linking-with-with-x11-xf86vmode-and-bfd.patch
@@ -0,0 +1,25 @@
+From: Aurelien Jarno 
+Date: Mon Oct 18 23:02:51 2021 +0200
+Subject: fix linking with WITH_X11_XF86VMODE and bfd
+Forwarded: https://developer.blender.org/D12911
+
+Fix typos in the variables of the Xxf86vm libray to fix link failure
+with bfd.  These variables are defined in platform_unix.cmake.
+
+diff --git a/intern/ghost/CMakeLists.txt b/intern/ghost/CMakeLists.txt
+index 05423209c71..64faf464290 100644
+--- a/intern/ghost/CMakeLists.txt
 b/intern/ghost/CMakeLists.txt
+@@ -245,10 +245,10 @@ elseif(WITH_GHOST_X11 OR WITH_GHOST_WAYLAND)
+ if(WITH_X11_XF86VMODE)
+   add_definitions(-DWITH_X11_XF86VMODE)
+   list(APPEND INC_SYS
+-${X11_xf86vmode_INCLUDE_PATH}
++${X11_Xxf86vmode_INCLUDE_PATH}
+   )
+   list(APPEND LIB
+-${X11_Xf86vmode_LIB}
++${X11_Xxf86vmode_LIB}
+   )
+ endif()
+ 
--- blender-2.93.4+dfsg/debian/patches/series
+++ blender-2.93.4+dfsg/debian/patches/series
@@ -3,3 +3,5 @@
 0003-do_not_use_version_number_in_system_path.patch
 

Bug#996902: RFP: psstop - accurately measure memory consumption using proportional set size (PSS)

[Andrei POPESCU]

Control: reassign -1 wnpp

On Mi, 20 oct 21, 17:02:31, Andrei Shevchuk wrote:
> Package: psstop
> Severity: wishlist
> 
> * Package name: psstop
>   Version : 1.3
>   Upstream Author : Arjan van de Ven , Victor
> Rodriguez 
> * URL : https://github.com/clearlinux/psstop
> * License : GPL
>   Programming Lang: C
>   Description : accurately measure memory consumption using
> proportional set size (PSS)
> 
> A tiny utility similar to smem, but in C, so it's faster and uses less memory:
> 
> > /usr/bin/time -f "Total time: %E | Memory (RSS): %M KB" ./psstop > /dev/null
> Total time: 0:00.61 | Memory (RSS): 1796 KB
> 
> > /usr/bin/time -f "Total time: %E | Memory (RSS): %M KB" smem -t > /dev/null
> Total time: 0:03.30 | Memory (RSS): 42156 KB

Reassigning to correct (pseudo-)package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#996916: gedit: FTBFS on hurd-i386 and kfreebsd-any

[Svante Signell]

Source: gedit
Version: 40.1-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org debian-k...@lists.debian.org
Usertags: hurd

Hi,

Currently gedit FTBFS on GNU/Hurd and GNU/kFreeBSD due to failure to
define ENABLE_GVFS_METADATA in config.h during configuraation.
With the attached patch, meson.build.patch, gedit builds fine again.
The patch has been used to successfully build gedit on Linux, Hurd
and kFreeBSD.

Thanks!

Index: gedit-40.1/meson.build
===
--- gedit-40.1.orig/meson.build
+++ gedit-40.1/meson.build
@@ -75,7 +75,7 @@ config_h.set_quoted('DATADIR', join_path
 config_h.set_quoted('VERSION', meson.project_version())
 
 enable_gvfs_metadata = get_option('enable-gvfs-metadata')
-if enable_gvfs_metadata == 'yes' or (enable_gvfs_metadata == 'auto' and host_machine.system() == 'linux')
+if enable_gvfs_metadata == 'yes' or (enable_gvfs_metadata == 'auto' and ['linux', 'gnu', 'gnu/kfreebsd'].contains(host_machine.system()))
   enable_gvfs_metadata = true
 else
   enable_gvfs_metadata = false

Bug#996915: raspi-firmware: hook breaks label-based booting

[Cyril Brulebois]

Package: raspi-firmware
Version: 1.20210303+ds-2
Severity: important

Hi,

Building bullseye images using raspi-team/image-specs[1] for the Pi 4 B
or PI CM4 devices (`make raspi_4_bullseye.img`), I've been getting weird
things…

 1. https://salsa.debian.org/raspi-team/image-specs

Sometimes the boot would stop after a few seconds (last kernel log with
a timestamp around 6 seconds shown on HDMI), sometimes one would get a
prompt about a missing root filesystem, and be dropped inside an
initramfs prompt. (I've no certain answer at this point, but it seems
that the order of console= parameters in cmdline.txt might explain that
the prompt goes to the screen or the serial console; namely going to the
serial console during the first boot, and on screen for further boots,
due to the switched order after initial reconfiguration…)

Anyway, let's focus on the raspi-firmware issue:
 - image-specs generates a label-based booting, using this cmdline
   parameter: root=LABEL=RASPIROOT (similar to root=UUID=…).
 - The first boot ensures the raspi-firmware hook is called:
   /etc/kernel/postinst.d/z50-raspi-firmware
 - Running this hook results in the root= parameter's being replaced
   with the /dev/mmcblkNp2 du jour (it might be /dev/mmcblk0p2, it might
   be /dev/mmcblk1p2).
 - Further boots might see the same device come up with a different ID,
   leading to the root= vs. actual /dev/mmcblkNp2 mismatch that prevents
   booting.

In passing, the workaround in such cases is quite simple (when the
actual error messages are accessible, and one has access to a keyboard
or a serial console depending on cases):
 - symlink /dev/mmcblkXp2 to /dev/mmcblkYp2
 - exit the initramfs shell

and booting continues.


I think I'd prefer it if raspi-firmware wouldn't touch an existing root=
parameter. This would probably fix the very similar #984691 (about btrfs
booting).


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#996858: temporary solution

[alain]

downloaded the *.deb as mentioned above.
installed .
frozen the packages (apt-mark hold)

now I'm doing the refurbishment of my distribution.

Bug#996911: systemd: dbus signal JobRemoved for a failed job is 'done' instead of 'failed'

[Alexandre Rossi]

Hi,

Many thanks for your quick feedback, this is driving me crazy.

Le Wed, Oct 20, 2021 at 06:26:45PM +0200, Michael Biebl a écrit :
> > man:org.freedesktop.systemd1 says:
> > 
> >  JobRemoved() are sent out each time a new job is queued or dequeued.
> >  [...] done indicates successful execution of a job.
> > 
> > However, when I subscribe to the JobRemoved signal and I restart a failing
> > job, I get 'done' as a result.
> 
> I tried to reproduce this issue with a more minimal service:
> 
> # systemctl cat fail.service
> # /etc/systemd/system/fail.service
> [Unit]
> Description=fail
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/false
> 
> # systemctl start fail
> Job for fail.service failed because the control process exited with error
> code.
> See "systemctl status fail.service" and "journalctl -xeu fail.service" for
> details.
> 
> $ python3 demo.py
> received event for unit fail.service with result failed
> 
> Looks all fine to me.

Do you get the same result with Type=simple ?

Thanks,

Alex

Bug#996910: linphone: Segmentation fault when registering a sip account

[Dennis Filder]

X-Debbugs-CC: Tiago Bortoletto Vaz 

On Wed, Oct 20, 2021 at 12:06:05PM -0400, Tiago Bortoletto Vaz wrote:
> Package: linphone
> Version: 4.2.5-3
> Severity: important
> X-Debbugs-Cc: ti...@debian.org
>
> Dear Maintainer,
>
> I'm getting a segmentation fault every time I try to registar a regular UDP
> account from my SIP provider:
>
> [...]
> : Implicitly defined onFoo properties in Connections are deprecated. Use this 
> syntax instead: function onFoo() { ... }
> [11:59:09:441][0x55a449eb92b0][Info]app/App.cpp:225: "Creating subwindow: 
> `qrc:/ui/views/App/Settings/SettingsWindow.qml`."
> [11:59:09:506][0x55a449eb92b0][Info]app/App.cpp:232: "Subwindow status: `1`."
> [11:59:09:682][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:
>  qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:7: QML Connections: 
> Implicitly defined onFoo properties in Connections are deprecated. Use this 
> syntax instead: function onFoo() { ... }
> [11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:149:
>  qrc:/ui/views/App/Settings/SettingsVideo.qml:149:7: QML Connections: 
> Implicitly defined onFoo properties in Connections are deprecated. Use this 
> syntax instead: function onFoo() { ... }
> [11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:142:
>  qrc:/ui/views/App/Settings/SettingsVideo.qml:142:7: QML Connections: 
> Implicitly defined onFoo properties in Connections are deprecated. Use this 
> syntax instead: function onFoo() { ... }
> [11:59:10:027][0x55a449eb92b0][Warning]app/App.cpp:802: System tray not found 
> on this system.
> [11:59:10:062][0x55a449eb92b0][Warning]qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:
>  qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:5: QML Connections: 
> Implicitly defined onFoo properties in Connections are deprecated. Use this 
> syntax instead: function onFoo() { ... }
> [11:59:10:236][0x55a449eb92b0][Info]components/core/event-count-notifier/AbstractEventCountNotifier.cpp:71:
>  "Notify event count: 0."
> [11:59:20:311][0x55a449eb92b0][Info]components/assistant/AssistantModel.cpp:416:
>  "Set config on assistant: 
> `/usr/share/linphone/assistant/use-other-sip-account.rc`."
> Segmentation fault

When you try to register the account, what steps to you go through?  I
presume in the main window you're clicking in this order: Home ->
Assistant -> Use a SIP Account.  If so, does Linphone still crash if
you omit the "sip:" prefix in the input field "SIP Domain"?  That
field must be a resolvable hostname, domain name or an IP address, and
unfortunately the input validation in that dialog is not as good as it
should be.

If the above advice does not resolve the issue, please give detailed
steps on what you click and what information you enter in each field.
Also exit Linphone and then start a new Linphone instance from a
terminal like this:

  catchsegv linphone 2>&1 | tee /tmp/linphone-segfault.txt

Then post that file here after it has crashed.

Regards.

Bug#996880: unconditionally unpauses media playback after call

[Dennis Filder]

X-Debbugs-CC: Timo Weingärtner 

On Wed, Oct 20, 2021 at 09:19:14AM +0200, Timo Weingärtner wrote:
> Package: linphone-desktop
> Version: 4.2.5-3
> Severity: normal
>
> steps to reproduce:
> * have any positive number of paused youtube videos opened in firefox
> * maybe wait hours or days after pausing the last one
> * call someone using linphone
> * end the call
> * be surprised that one of the videos resumes playback
>
> suggested solution:
> * remember whether there was media playback running when the call starts
> * only resume playback if it was running before the call

I have very strong doubts that linphone-desktop (or rather
libmediastreamer2) is the culprit here.  A pulseaudio client
disconnecting should leave other clients untouched, and clients
usually have no way of affecting other clients anyway.  This leaves
pulseaudio itself and Firefox as suspects.

Linphone creates its pulseaudio streams with the property
media.role="phone" which pulseaudio internally gives higher priority
so that when you get a phone call while watching a movie, the movie
stream gets automatically corked for the duration of the call and then
uncorked.  The event-handling code in Firefox probably does not deal
with that correctly leading to the unpausing.  This would also make
sense because the decision to pause/resume playback happens entirely
in the code of a pulseaudio client.

The pulseaudio backend code in Firefox currently is under:
91.2.0esr-1/third_party/rust/cubeb-pulse/src/backend/

Upstream at: github.com/mozilla/cubeb-pulse-rs/

What version of Firefox are you running?  It would also help a ton if
you could state if this bug happens with the Firefox nightly builds
from mozilla.org, too.

If you want this to ever get even close to being fixed you'll have to
find a way to reproduce the issue quicker somehow (restarting
pulseaudio, disconnecting and reconnecting network/Internet connection
etc.).  After that you should start Firefox like this:

  MOZ_LOG="cubeb:4" firefox --new-instance 2>&1 | tee /tmp/ff-cubeb.log

then reproduce the issue and post that log file here.  That will
hopefully generate enough clues to figure out what is happening.

I'll reassign the bug to firefox-esr unless I hear convincing
arguments for why the cause is to be sought elsewhere.

Regards.

Bug#996914: totem: Recommends transitional package gstreamer1.0-pulseaudio

[Martin-Éric Racine]

Package: totem
Version: 3.38.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Totem still Recommends gstreamer1.0-pulseaudio which is nowadays a transitional 
package.

gst-plugins-good1.0 (1.18.0-1) unstable; urgency=medium

  * New upstream stable release.
  * Upload to unstable.
  * Move PulseAudio plugin into the gstreamer1.0-plugins-good package (Closes: 
#840359).

Package: gstreamer1.0-pulseaudio
Source: gst-plugins-good1.0
Version: 1.18.5-1
Depends: gstreamer1.0-plugins-good (>= 1.18.0)
Description-en: GStreamer plugin for PulseAudio (transitional package)

- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 5.14.0-2-686 (SMP w/1 CPU thread)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages totem depends on:
ii  grilo-plugins-0.3   0.3.14-1
ii  gsettings-desktop-schemas   41.0-1
ii  gstreamer1.0-clutter-3.03.0.27-2+b1
ii  gstreamer1.0-plugins-base   1.18.5-1
ii  gstreamer1.0-plugins-good   1.18.5-1
ii  gstreamer1.0-x  1.18.5-1
ii  libc6   2.32-4
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii  libglib2.0-02.70.0-1+b1
ii  libgstreamer-plugins-base1.0-0  1.18.5-1
ii  libgstreamer1.0-0   1.18.5-1
ii  libgtk-3-0  3.24.30-3
ii  libpango-1.0-0  1.48.10+ds1-1
ii  libpangocairo-1.0-0 1.48.10+ds1-1
ii  libtotem-plparser18 3.26.6-1
ii  libtotem0   3.38.2-1
ii  libx11-62:1.7.2-2+b1
ii  totem-common3.38.2-1

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1.18.5-1
ii  gstreamer1.0-plugins-bad   1.18.5-1+b1
ii  gstreamer1.0-plugins-ugly  1.18.5-1
pn  gstreamer1.0-pulseaudio
ii  totem-plugins  3.38.2-1

Versions of packages totem suggests:
pn  gnome-codec-install  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFwQ68ACgkQrh+Cd8S0
17YSDBAAiJuNY8a1CBdiyP7wq0Oo13WLymQSp0bq0O3+ajwsCRPCHuqK4l2DaEoW
vln+9XcysvuvNWZOtER0DORvuIz2CTgfIYQnvgNyu1ilAMHNluWWWscIXP9NqSMR
T2FConacKOVBxggxdDW+i1s9iWnkq56G270uE/tBqZbk6LES0+RfS+aRzX+wv8Mc
Zl11DTV1HD6SU9/fqKXYscZDO1vybyp/xLprgsD10W5wBMtQS9H1jTKAyVSAMPbF
+QlvXmO/tduos0HfOkA2LcVGMNzkJ2x8F75oaw59TvJdHguoswZIjbLBGPa0uzKy
QkGeYmEemfpHJ8I0sIlVKw0q88hMCCwCF6BWGlvcbPl9b0/VSWiMS+4rAUHEdkic
h9SBWQi8TPwZUQMKsL0gzqS3xw+jAKpmpRjoY9zbV4iUjqtNHLlQaQmGF1D9rgcM
NEgBYhrR1vmlD7u9Ilbx5hlK2XbT6SqiZWnCqpUmvGSletmUkyZVNFvXlftUxxK7
fIJIFlBosFTjM/qgOu/uINeRR7p7gXLtk6Jxd99UeJlAU3/T0GmQ1c4y9IrsLuT4
eUlzHLew8y8BUalfcRjQN1xxfhTERYaYgPA2HQ1NEpdyNSev0NLQvffmM/hfp214
hi1FpzC3aSq/chgtHS56JEMpvrsdqHJ5TG1DCYsdTUPdemp4BOc=
=nPzV
-END PGP SIGNATURE-

Bug#926896: sysvinit-utils: pidof is unreliable

[Mark Hindley]

Jesse,

On Wed, Oct 20, 2021 at 11:29:23AM -0300, Jesse Smith wrote:
> Is there a reason for wanting to revert this behaviour instead of using
> the "-z" flag on the command line? If you use pidof a lot and expect to
> see processes that are in the uninterruptable sleep state then making an
> alias of pidof='pidof -z' seems like a straight forward approach.

I am trying to get a consensus on how we deal with this.

Personally, I was convinced by Tim's argument, particularly the one of least
surprise. I too would expect pidof to return processes in D.

Yes, a user could create an alias, but I am sure that pidof is used in scripts
where that approach is more difficult. And it is conceivable, although
undocumented to my knowledge, that such script usage has been broken by this
change.

Also start-stop-daemon is now a binary and no longer uses pidof as its script
predecessor did. Therefore the original report[1] that requested this change is
obsolete.

Going forward, my gut reaction is that if start-stop-daemon still fails in the
case of stuck NFS mounts, that should be addressed in src:dpkg rather than by
excluding processes from pidof.

But I am open to be persuaded! It is a difficult issue that benefits from
diverse minds and approaches.

Thanks

Mark

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

Bug#996911: systemd: dbus signal JobRemoved for a failed job is 'done' instead of 'failed'

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible
Hello Alexandre

Am 20.10.21 um 18:08 schrieb Alexandre Rossi:

Package: systemd
Version: 247.3-6
Severity: normal

Dear Maintainer,

man:org.freedesktop.systemd1 says:

 JobRemoved() are sent out each time a new job is queued or dequeued.
 [...] done indicates successful execution of a job.

However, when I subscribe to the JobRemoved signal and I restart a failing
job, I get 'done' as a result.




I tried to reproduce this issue with a more minimal service:



# systemctl cat fail.service
# /etc/systemd/system/fail.service
[Unit]
Description=fail

[Service]
Type=oneshot
ExecStart=/bin/false

# systemctl start fail
Job for fail.service failed because the control process exited with 
error code.
See "systemctl status fail.service" and "journalctl -xeu fail.service" 
for details.


$ python3 demo.py
received event for unit fail.service with result failed


Looks all fine to me.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984080: lamarc: ftbfs with GCC-11

[Andreas Tille]

Control: tags -1 help

Hi,

I was able to fix part of the compatibility issues[1] but now the build
stumbles upon:

...
g++ -DHAVE_CONFIG_H -I. -I./config   -Wdate-time -D_FORTIFY_SOURCE=2 
-DLAMARC_COMPILE_LINUX  -DNDEBUG  -Wall -Wextra -Wno-unused -I 
./config -I ./config -I ./src/bayeslike - I ./src/control -I ./src/conversion 
-I ./src/convErr -I ./src/convModel -I ./src/convParse -I ./src/convStrings -I 
./src/convUtil -I ./src/datalike -I ./src/force -I ./src/guiconv -I ./ 
src/guiutil -I ./src/lamarcmenus -I ./src/menu -I ./src/postlike -I 
./src/report -I ./src/tools -I ./src/tree -I ./src/ui_interface -I 
./src/ui_util -I ./src/ui_vars -I ./src/xml -I/usr/include/boost -I ./resources 
-DTIXML_USE_STL -g -O2 -ffile-prefix-map=/build/lamarc-2.1.10.1+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
src/datalike/lamarc-  phenotypes.o `test -f 'src/datalike/phenotypes.cpp' || 
echo './'`src/datalike/phenotypes.cpp
In file included from /usr/include/c++/11/set:60,
 from ./src/tools/rangex.h:26,
 from src/datalike/dlcalc.h:31,
 from src/datalike/locus.cpp:29:
/usr/include/c++/11/bits/stl_tree.h: In instantiation of 'static const _Key& 
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
_Alloc>::_S_key(std::_Rb_tree<_Key, _Val, _KeyOfValue,  _Compare, 
_Alloc>::_Const_Link_type) [with _Key = std::pair; _Val = 
std::pair; _KeyOfValue = std::_Identity >;  _Compare = rangecmp; _Alloc = std::allocator >; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
_Alloc>::_Const_Link_type = const std::_Rb_tree_node >*]':
/usr/include/c++/11/bits/stl_tree.h:2069:47:   required from 
'std::pair 
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
_M_get_insert_unique_pos(const key_type&) [with _Key = std::pair; _Val = std::pair; _KeyOfValue = 
std::_Identity >; _Compare = rangecmp; _Alloc = 
std::allocator >; std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>::key_type = std::pair]'
/usr/include/c++/11/bits/stl_tree.h:2122:4:   required from 
'std::pair, bool> std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>:: _M_insert_unique(_Arg&&) 
[with _Arg = std::pair; _Key = std::pair; _Val = std::pair; _KeyOfValue = std::_Identity >; _Compare = rangecmp; _Alloc = 
std::allocator >]'
/usr/include/c++/11/bits/stl_set.h:521:25:   required from 'std::pair, _Compare, typename 
__gnu_cxx::__alloc_traits<_Allocator>::  rebind<_Key>::other>::const_iterator, 
bool> std::set<_Key, _Compare, _Alloc>::insert(std::set<_Key, _Compare, 
_Alloc>::value_type&&) [with _Key = std::pair; _Compare = 
rangecmp; _Alloc = std::allocator >; typename 
std::_Rb_tree<_Key, _Key, std::_Identity<_Tp>, _Compare, typename 
__gnu_cxx::__alloc_traits<_Allocator>::   rebind<_Key>::other>::const_iterator 
= std::_Rb_tree, std::pair, 
std::_Identity >, rangecmp, std::
allocator > >::const_iterator; typename 
__gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key>::other = 
std::allocator >;typename 
__gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key> = 
__gnu_cxx::__alloc_traits >, 
std::pair >::rebind >; 
typename _Allocator::value_type = std::pair; std::set<_Key, 
_Compare, _Alloc>::value_type = std::pair]'
src/datalike/locus.cpp:204:24:   required from here
/usr/include/c++/11/bits/stl_tree.h:770:15: error: static assertion failed: 
comparison object must be invocable as const
  770 | In file included from /usr/include/c++/11/set:60,
 from ./src/tools/rangex.h:26,
 from src/datalike/dlcalc.h:31,
/usr/include/c++/11/bits/stl_tree.h:770:15: note: 'std::is_invocable_v&, const std::pair&>' evaluates to false
make[1]: *** [Makefile:7499: src/datalike/lamarc-locus.o] Error 1


Any help is welcome

  Andreas.

[1] 
https://salsa.debian.org/med-team/lamarc/-/blob/master/debian/patches/throw_noexcept.patch

-- 
http://fam-tille.de

Bug#996897: Should not suggest postgresql-12-plr

[Andreas Tille]

Hi Christoph,

Am Wed, Oct 20, 2021 at 02:39:10PM +0200 schrieb Christoph Berg:
> 
> please don't reference specific PostgreSQL versions in your
> dependencies as the number changes each year, and it is already wrong
> as 13 is current, and we are moving to 14:

I understand the issue but postgresql-plr is only a virtual package
and I need to specify a real package as first alternative.  Do you
see any chance to have a real postgresql-plr package depending from
the versioned one?

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#996913: rust-chrono: Potential segfault in localtime_r invocations

[Alexander Kjäll]

Source: rust-chrono
Severity: minor
Tags: security

Dear Maintainer,

This package is affected by this security vulnerability that isn't tracked by 
debian yet:

https://rustsec.org/advisories/RUSTSEC-2020-0159.html

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

Kernel: Linux 5.10.0-1-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

Bug#996912: RM: libjuh-java,libjurt-java,libridl-java,libunoil-java -- ROM; NBS

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal

Hi,

please remove

$ rmadison -s unstable libjuh-java libridl-java libunoil-java libjurt-java
libjuh-java   | 1:7.0.4-4 | unstable   | all
libjurt-java  | 1:7.0.4-4 | unstable   | all
libridl-java  | 1:7.0.4-4 | unstable   | all
libunoil-java | 1:7.0.4-4 | unstable   | all

They are obsolete long ago:

libreoffice (1:7.1.0~alpha1-1) experimental; urgency=medium

  * New upstream alpha release

  * debian/rules:
- add conditional and build-dep for new box2d (again)
- don't parse parallel=X manually but use dpkg-devs buildopts.mk
- build only en-US for now
- try to enable pdfium anywhere since configure says
  "Disable building PDFium. Results in unsecure PDF signature
  verification."
  * debian/control*in, debian/rules:
- split Java parts of the URE to ure-java so that libreoffice-java-common
  can depend on that. (For possible future archs starting with
  no-java where this then isn't fullfillable instead of silently "working"
  without actual Java stuff in "ure")
- stop building libjuh-java, libridl-java, libjurt-java and libunoil-java.
  Merge them (and provide them) in(to) liblibreoffice-java.

 -- Rene Engelhard   Tue, 27 Oct 2020 18:04:25 +0100

but not removed by auto-cruft when this was uploaded to sid after the
buster release.

Note that dak rm might complain about r-deps, but those all are having
unversioned dependencies and:

Provides: libjuh-java, libjurt-java, libridl-java, libunoil-java
Depends: libunoloader-java, ure-java
Breaks: libjuh-java (<< 1:7.1.0~), libjurt-java (<< 1:7.1.0~), libridl-java (<< 
1:7.1.0~), libunoil-java (<< 1:7.1.0~)
Replaces: libjuh-java (<< 1:7.1.0~), libjurt-java (<< 1:7.1.0~), libridl-java 
(<< 1:7.1.0~), libunoil-java (<< 1:7.1.0~)

in liblibreoffice-java.

Regards,

Rene

Bug#996911: systemd: dbus signal JobRemoved for a failed job is 'done' instead of 'failed'

[Alexandre Rossi]

Package: systemd
Version: 247.3-6
Severity: normal

Dear Maintainer,

man:org.freedesktop.systemd1 says:

JobRemoved() are sent out each time a new job is queued or dequeued.
[...] done indicates successful execution of a job.

However, when I subscribe to the JobRemoved signal and I restart a failing
job, I get 'done' as a result.

I used the following script:

--
#!/usr/bin/python3

from gi.repository import GLib

import dbus
import dbus.mainloop.glib


def systemd_event_cb(pid, jobid, unit, result):
print('received event for unit %s with result %s'
  % (unit, result))

def subscribe():
sysbus = dbus.SystemBus()
systemd1 = sysbus.get_object('org.freedesktop.systemd1',
 '/org/freedesktop/systemd1')
systemd1.connect_to_signal('JobRemoved', systemd_event_cb)
manager = dbus.Interface(systemd1,
 'org.freedesktop.systemd1.Manager')
manager.Subscribe()

GLib.timeout_add(100, subscribe)

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
loop = GLib.MainLoop()

loop.run()
--

The output of the script is:

received event for unit davmail.service with result done

However:

--
$ sudo systemctl status davmail
× davmail.service - Davmail Exchange gateway
 Loaded: loaded (/lib/systemd/system/davmail.service; disabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Wed 2021-10-20 17:15:21 CEST; 12s 
ago
Process: 10271 ExecStartPre=/usr/share/davmail/service-prepare 
(code=exited, status=0/SUCCESS)
Process: 10274 ExecStart=/usr/bin/davmail -server 
/etc/davmail/davmail.properties (code=exited, status=1/FAILURE)
   Main PID: 10274 (code=exited, status=1/FAILURE)
CPU: 27ms

oct. 20 17:15:21 skade systemd[1]: Starting Davmail Exchange gateway...
oct. 20 17:15:21 skade systemd[1]: Started Davmail Exchange gateway.
oct. 20 17:15:21 skade systemd[1]: davmail.service: Main process exited, 
code=exited, status=1/FAILURE
oct. 20 17:15:21 skade systemd[1]: davmail.service: Failed with result 
'exit-code'.
--

Thanks,

Alex

-- Package-specific info:

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 systemd depends on:
ii  adduser   3.118
ii  chrony [time-daemon]  4.0-8
ii  libacl1   2.2.53-10
ii  libapparmor1  2.13.6-10
ii  libaudit1 1:3.0-2
ii  libblkid1 2.36.1-8
ii  libc6 2.31-13+deb11u2
ii  libcap2   1:2.44-1
ii  libcrypt1 1:4.4.18-4
ii  libcryptsetup12   2:2.3.5-1
ii  libgcrypt20   1.8.7-6
ii  libgnutls30   3.7.1-5
ii  libgpg-error0 1.38-2
ii  libip4tc2 1.8.7-1
ii  libkmod2  28-1
ii  liblz4-1  1.9.3-2
ii  liblzma5  5.2.5-2
ii  libmount1 2.36.1-8
ii  libpam0g  1.4.0-9+deb11u1
ii  libseccomp2   2.5.1-1
ii  libselinux1   3.1-3
ii  libsystemd0   247.3-6
ii  libzstd1  1.4.8+dfsg-2.1
ii  mount 2.36.1-8
ii  util-linux2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  247.3-6

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
pn  libnss-systemd   
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]

-- no debconf information

Bug#996019: debootstrap: bootstrap of ubuntu impish is failing

[Dimitri John Ledkov]

Hi,

I've tried to reproduce this more and I have a few questions:

1) what is the version of debootstrap ?
2) do any config files divert as to which debootstrap's `functions`
file is used ?
3) what settings do you have in /tmp/configfile ?

I'm trying to eliminate a case where new scripts/impish is used that
sets AR extractor, and yet old functions file is used which doesn't
know how to zstdcat in the AR extractor.

ie.
```
$ grep zstdcat /usr/share/debootstrap/functions
control.tar.zst) cat_cmd=zstdcat ;;
data.tar.zst) cat_cmd=zstdcat ;;
```
I'm not sure what in your case is listed in /tmp/configfile. I assume
that one thing is pointer to the custom mirror.

I launched Debian sid, enabled experimental, installed debootstrap
from experimental, install cowbuilder and all the jenkins-debian-glue
stuff. I did echo custom mirror of
http://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive into
/tmp/configfile. Cause that looked like the only custom thing. Not
sure if there are anything else set there. and Things mostly
progressed fine for me:

# DIST=$d ARCH=$a cowbuilder --create --basepath
/var/cache/pbuilder/base-$d-$a.cow --distribution $d --debootstrap
debootstrap --architecture $a --debootstrapopts --arch
--debootstrapopts amd64 --debootstrapopts --variant=buildd
--configfile=/tmp/configfile --hookdir
/usr/share/jenkins-debian-glue/pbuilder-hookdir/
I: Invoking pbuilder
I: forking: pbuilder create --debootstrap debootstrap
--debootstrapopts --arch --debootstrapopts amd64 --debootstrapopts
--variant=buildd --configfile /tmp/configfile --hookdir
/usr/share/jenkins-debian-glue/pbuilder-hookdir/ --buildplace
/var/cache/pbuilder/base-impish-amd64.cow --mirror
http://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive/
--architecture amd64 --distribution impish --no-targz --extrapackages
cowdancer
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: Distribution is impish.
I: Current time: Wed Oct 20 15:07:00 UTC 2021
I: pbuilder-time-stamp: 1634742420
I: Building the build environment
I: running debootstrap
/usr/bin/which: this version of `which' is deprecated; use `command
-v' in scripts instead.
/usr/sbin/debootstrap
I: Target architecture can be executed
I: impish uses zstd compression, setting --extractor=ar option
I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on
http://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive...

...

I: Retrieving zlib1g 1:1.2.11.dfsg-2ubuntu7
I: Validating zlib1g 1:1.2.11.dfsg-2ubuntu7
I: Chosen extractor for .deb packages: ar
I: Extracting base-files...
I: Extracting base-passwd...



I: Installing core packages...
I: Unpacking required packages...
I: Unpacking base-files...
I: Unpacking base-passwd...

...

I: Configuring required packages...
I: Configuring gcc-11-base:amd64...
I: Configuring lsb-base...
I: Configuring libtirpc-common..
...

Eventually it failed for me with:

Package cowdancer is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'cowdancer' has no installation candidate
E: Package 'aptitude' has no installation candidate
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
E: pbuilder create failed
I: forking: rm -rf /var/cache/pbuilder/base-impish-amd64.cow

But that seems like further along than what you have. It is possible
that I didn't enable universe, cause aptitude is available in Ubuntu.

On Sat, 16 Oct 2021 at 10:05, Sylvestre Ledru  wrote:
>
> Hello Dimitri,
>
> Any idea how to fix that? I cannot generate packages for
> https://apt.llvm.org/ for impish from a Debian.
>
> thanks
> Sylvestre
>
> Le 11/10/2021 à 18:08, Sylvestre Ledru a écrit :
> > Hello
> >
> >
> > Le 10/10/2021 à 12:41, Sylvestre Ledru a écrit :
> >> Package: debootstrap
> >> Version: 1.0.124
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> $ sudo debootstrap impish impish 
> >> https://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive/
> >> I: impish uses zstd compression, setting --extractor=ar option
> >> I: Retrieving InRelease
> >> I: Retrieving Packages
> >> I: Validating Packages
> >> [...]
> >> I: Validating zlib1g 1:1.2.11.dfsg-2ubuntu7
> >> I: Chosen extractor for .deb packages: ar
> >> I: Extracting base-files...
> >> I: Extracting base-passwd...
> >> E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb 
> >> requires the zstdcat command, which is not available
> >
> >> One needs to install zstd on the host, including zstd in the
> > debootstrap,set will not help.,,Does $ sudo apt install zstd => fix the
> > issue for you?
> >
> > Yeah, it fixed my test case but my 

Bug#996910: linphone: Segmentation fault when registering a sip account

[Tiago Bortoletto Vaz]

Package: linphone
Version: 4.2.5-3
Severity: important
X-Debbugs-Cc: ti...@debian.org

Dear Maintainer,

I'm getting a segmentation fault every time I try to registar a regular UDP
account from my SIP provider:

[...]
: Implicitly defined onFoo properties in Connections are deprecated. Use this 
syntax instead: function onFoo() { ... }
[11:59:09:441][0x55a449eb92b0][Info]app/App.cpp:225: "Creating subwindow: 
`qrc:/ui/views/App/Settings/SettingsWindow.qml`."
[11:59:09:506][0x55a449eb92b0][Info]app/App.cpp:232: "Subwindow status: `1`."
[11:59:09:682][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:
 qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:7: QML Connections: 
Implicitly defined onFoo properties in Connections are deprecated. Use this 
syntax instead: function onFoo() { ... }
[11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:149:
 qrc:/ui/views/App/Settings/SettingsVideo.qml:149:7: QML Connections: 
Implicitly defined onFoo properties in Connections are deprecated. Use this 
syntax instead: function onFoo() { ... }
[11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:142:
 qrc:/ui/views/App/Settings/SettingsVideo.qml:142:7: QML Connections: 
Implicitly defined onFoo properties in Connections are deprecated. Use this 
syntax instead: function onFoo() { ... }
[11:59:10:027][0x55a449eb92b0][Warning]app/App.cpp:802: System tray not found 
on this system.
[11:59:10:062][0x55a449eb92b0][Warning]qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:
 qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:5: QML Connections: 
Implicitly defined onFoo properties in Connections are deprecated. Use this 
syntax instead: function onFoo() { ... }
[11:59:10:236][0x55a449eb92b0][Info]components/core/event-count-notifier/AbstractEventCountNotifier.cpp:71:
 "Notify event count: 0."
[11:59:20:311][0x55a449eb92b0][Info]components/assistant/AssistantModel.cpp:416:
 "Set config on assistant: 
`/usr/share/linphone/assistant/use-other-sip-account.rc`."
Segmentation fault

Thanks,

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

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

Versions of packages linphone depends on:
ii  linphone-desktop  4.2.5-3

linphone recommends no packages.

linphone suggests no packages.

-- no debconf information

Bug#996909: acorn: Invalid package section for node-debbundle-acorn

[Steve Langasek]

Package: acorn
Version: 8.5.0+ds+~cs24.17.6-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Bastien,

The latest version of acorn has node-debbundle-acorn listed in Section:
oldlib.  This is invalid; the correct section name is 'oldlibs'.  In the
Debian archive, this is not an issue because the Debian archive applies
overrides to all packages (indeed, I see the archive still lists this
package as 'Section: javascript'), but in Ubuntu this blocks the binary
package from being uploaded.  So I have applied the attached patch for
Ubuntu, which should also be correct for Debian.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru acorn-8.5.0+ds+~cs24.17.6/debian/control 
acorn-8.5.0+ds+~cs24.17.6/debian/control
--- acorn-8.5.0+ds+~cs24.17.6/debian/control2021-10-17 08:56:32.0 
-0700
+++ acorn-8.5.0+ds+~cs24.17.6/debian/control2021-10-19 22:06:36.0 
-0700
@@ -65,7 +65,7 @@
 Package: node-debbundle-acorn
 Architecture: all
 Multi-Arch: foreign
-Section: oldlib
+Section: oldlibs
 Depends: ${misc:Depends}
  , node-acorn (= ${binary:Version})
 Breaks: node-acorn (<<8.5.0+ds+~cs23.9.6-2~)

Bug#996908: ffado-tools come with libffado.so.2.4.4 that also come with the libffado2 package

[wargreen]

Package: ffado-tools
Version: 2.4.4-1
Severity: normal

Dear Maintainers,
The package ffado-tools come with /usr/lib/x86_64-linux-
gnu/libffado2/libffado.so.2.4.4 but depend of the package libffado2 that come
with /usr/lib/x86_64-linux-gnu/libffado.so.2.4.4.

The tools provided by ffado-tools link with libffado.so.2 =>
/usr/lib/x86_64-linux-gnu/libffado.so.2 (that come with the libffado2 package).

The two files have differents build IDs, so it can cause bugs if versions or
build option are differents and softwares don't use the good one.

Thank you


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ffado-tools depends on:
ii  dbus   1.12.20-2
ii  libc6  2.32-4
ii  libconfig++9v5 1.5-0.4
ii  libffado2  2.4.4-1
ii  libgcc-s1  11.2.0-8
ii  libglibmm-2.4-1v5  2.66.1-1
ii  libiec61883-0  1.2.0-4
ii  libraw1394-11  2.1.2-2
ii  libstdc++6 11.2.0-8
ii  libxml++2.6-2v52.40.1-3
ii  python33.9.2-3

ffado-tools recommends no packages.

ffado-tools suggests no packages.

Bug#996714: gnome-pass-search-provider: diff for NMU version 0.0~20191115+da2db41-1.1

[Boyuan Yang]

Control: tags 996714 + patch
Control: tags 996714 + pending

Dear maintainer,

I've prepared an NMU for gnome-pass-search-provider (versioned as
0.0~20191115+da2db41-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru gnome-pass-search-provider-0.0~20191115+da2db41/debian/changelog
gnome-pass-search-provider-0.0~20191115+da2db41/debian/changelog
--- gnome-pass-search-provider-0.0~20191115+da2db41/debian/changelog2020-
03-20 14:46:32.0 -0400
+++ gnome-pass-search-provider-0.0~20191115+da2db41/debian/changelog2021-
10-20 11:45:31.0 -0400
@@ -1,3 +1,10 @@
+gnome-pass-search-provider (0.0~20191115+da2db41-1.1) unstable;
urgency=medium
+
+  * Non-maintainer upload.
+  * No change source-only upload. (Closes: #996714)
+
+ -- Boyuan Yang   Wed, 20 Oct 2021 11:45:31 -0400
+
 gnome-pass-search-provider (0.0~20191115+da2db41-1) unstable; urgency=medium
 
   * Initial release (Closes: #954347)


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

Bug#996822: ensurepip throws an AssertionError on pypy3

[Ophir Lojkine]

>> If python3-pip is supposed to work with pypy, I would expect `apt install 
>> pypy3 python3-pip && pypy3 -m ensurepip --version` to return “pip 20.3.4-4”. 
>> Instead, it returns the long error message you mentioned above that suggests 
>> installing another package.
> 
> Nope, I get:
> $ pypy3 -m ensurepip --version
> pip 20.3.4

Yes, you are right, this works correctly. 

> If you read that error message, does that help?

Yes, that error message is fine and helpful. The only issue is the assertion 
error in ensurepip.

Bug#996901: ifupdown: When booting a thin client over the network (NFS-Root) ifup fails

[Santiago Ruano Rincón]

Hi,

El 20/10/21 a las 15:31, Ralf Schlatterbeck escribió:
> 
> Package: ifupdown
> Version: 0.8.36
> Severity: important
> X-Debbugs-Cc: r...@runtux.com
> 
> Dear Maintainer,
> 
> I'm trying to network-boot a thin client (orange-pi zero) with debian
> bullseye and a custom kernel. NFS mount works fine but ifup fails
> spectacularly. This works fine on debian buster (but may be kernel
> specific, the debian buster setup has an older 5.9 kernel).

What are you network mount points?

> 
> When booting with the 'auto eth0' in /etc/network/interfaces I'm getting
> a 5 Minute wait and then 
> 
> [FAILED] Failed to start Raise network interfaces.
> 
> And issuing the command 'ip addr ls' will reveal that a lot of IP
> addresses have been reserved for the eth0 interface (see below).
> 
> When removing the 'auto eth0' line and starting up the interface manually
> when the system is up (it already *has* an IP-Address at that point due
> to the NFS-Root) I'm getting:
> 
> root@sun7i:~# ifup eth0
> Internet Systems Consortium DHCP Client 4.4.1
> Copyright 2004-2018 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
> 
> Listening on LPF/eth0/02:42:b3:f0:2d:3e
> Sending on   LPF/eth0/02:42:b3:f0:2d:3e
> Sending on   Socket/fallback
> Created duid "\000\001\000\001)\002\266\310\002B\263\360->".
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
> DHCPOFFER of 10.23.5.173 from 10.23.5.254
> DHCPREQUEST for 10.23.5.173 on eth0 to 255.255.255.255 port 67
> DHCPACK of 10.23.5.173 from 10.23.5.254
> RTNETLINK answers: File exists
> DHCPDECLINE of 10.23.5.173 on eth0 to 255.255.255.255 port 67
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
> DHCPOFFER of 10.23.5.205 from 10.23.5.254
> DHCPREQUEST for 10.23.5.205 on eth0 to 255.255.255.255 port 67
> DHCPACK of 10.23.5.205 from 10.23.5.254
> DHCPDECLINE of 10.23.5.205 on eth0 to 255.255.255.255 port 67
...

Your dhclient is declining all of the offered IPs…
Are you sure they are available?

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#996699: [Debian-on-mobile-maintainers] Bug#996699: chatty: Cross-building fails to resolve libpurple-dev

[Helmut Grohne]

Control: tags -1 + patch

On Wed, Oct 20, 2021 at 02:59:14PM +0200, Helmut Grohne wrote:
> It's an Architecture: all package and those can never satisfy cross
> Build-Depends unless marked Multi-Arch: foreign. So clear thing, we mark
> it Multi-Arch: foreign and we're done, right? Unfortunately, not.
> libpurple-dev Depends on libpurple0 (among other things) and quite
> clearly, it exposes libpurple0. Since libpurple0 is
> architecture-dependent and exposed by libpurple-dev, libpurple-dev
> cannot be Multi-Arch: foreign. The thing is: When we issue a dependency
> on libpurple-dev (for a particular architecture), we want a matching
> libpurple0 (of the requested architecture). And this constraint cannot
> be transferred through Architecture: all packages. That issue is known
> as the "multiarch interpreter problem", because it happened with
> interpreters first. In any case, the canonical solution to this problem
> is to turn libpurple-dev Architecture: any. At that point the resolver
> will pick the host architecture libpurple-dev and the dependency will
> ensure that we also get the host architecture libpurple0.

I also said "don't file cross build bugs without a patch". Here you go.

Helmut
diff --minimal -Nru pidgin-2.14.7/debian/changelog 
pidgin-2.14.7/debian/changelog
--- pidgin-2.14.7/debian/changelog  2021-10-05 02:31:35.0 +0200
+++ pidgin-2.14.7/debian/changelog  2021-10-20 17:02:30.0 +0200
@@ -1,3 +1,10 @@
+pidgin (2.14.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert libpidgin-dev to Architecture: any. (Closes: #996699)
+
+ -- Helmut Grohne   Wed, 20 Oct 2021 17:02:30 +0200
+
 pidgin (2.14.7-2) unstable; urgency=medium
 
   * Backport fix for XMPP double free (Closes: 995370)
diff --minimal -Nru pidgin-2.14.7/debian/control pidgin-2.14.7/debian/control
--- pidgin-2.14.7/debian/control2021-01-23 06:14:46.0 +0100
+++ pidgin-2.14.7/debian/control2021-10-20 17:02:29.0 +0200
@@ -153,11 +153,10 @@
 
 Package: libpurple-dev
 Section: libdevel
-Architecture: all
+Architecture: any
 Depends: libdbus-glib-1-dev,
  libglib2.0-dev,
- libpurple0 (<< ${source:Upstream-Version}+1~),
- libpurple0 (>= ${source:Upstream-Version}),
+ libpurple0 (= ${binary:Version}),
  pkg-config,
  ${misc:Depends},
 Description: multi-protocol instant messaging library - development files

Bug#996699: [Debian-on-mobile-maintainers] Bug#996699: chatty: Cross-building fails to resolve libpurple-dev

[Helmut Grohne]

Control: tags -1 - ftbfs upstream
Control: reasign -1 libpurple-dev
Control: retitle -1 convert libpurple-dev to Architecture: any
Control: affects -1 + src:bitlbee src:chatty src:pidgin-awayonlock 
src:pidgin-gnome-keyring src:pidgin-nateon src:purple-discord src:purple-lurch 
src:purple-matrix src:purple-mm-sms src:purple-rocketchat 
src:purple-xmpp-carbons src:purple-xmpp-http-upload src:telegram-purple
Control: user debian-cr...@lists.debian.org
Control: usertags -1 + cross-satisfiability

On Wed, Oct 20, 2021 at 10:17:30AM +0200, Evangelos Ribeiro Tzaras wrote:
> On Sun, 2021-10-17 at 09:26 -0400, Travis Wrightsman via Debian-on-
> mobile-maintainers wrote:
> > Package: chatty
> > Version: 0.4.0-1
> > Severity: serious
> > Justification: fails to build from source
> > Tags: ftbfs upstream

We do not yet categorize cross build issues as ftbfs. In any case, cross
build issues are not release critical as Sebastian Ramacher pointed out.
Please refrain from filing cross build bugs without patches.

> > Chatty fails to cross-build due to a dependency resolution error for
> > the
> > libpurple-dev package.
> > 
> > I'm not sure this is a chatty-specific bug but I'm also not sure where
> > else to place it.
> 
> I've just checked with another package which uses libpurple-dev (f.e.
> purple-matrix)  and ran (perhaps unsurprisingly) into the same issue
> when crossbuilding.

You nailed it.

> Possibly (probably?) related crossbuild failure in pidgin:
> https://salsa.debian.org/debian/pidgin/-/jobs/2035973#L1446 

No. That's a different and unrelated issue.

> CCing debian-cross in the hopes that someone can shed some light here
> :)

Very good. That was the right thing to do.

> More generally: What should be the next steps?
> 
> I guess I could reassign this bug to the pidgin source package (as it
> provides libpurple-dev)?

This one is partially correct as I'll explain below.

> And open bugs to
> a) libxml-parser-perl
> b) libdevel-checklib-perl
> c) python3 (and/or all the packages that make python FTCBFS)

No.

As a general thing, if you want to look into why something doesn't cross
build, go check at our cross build quality assurance:
http://crossqa.debian.net/src/chatty

We learn a couple of things there:
 * chatty doesn't have satisfiable cross-Build-Depends for any
   architecture and consequently has never been built.
 * There are no linked bug reports (at the time of this writing, but the
   usertagging should make this bug show up there soon).
 * The dependency issue is with libpurple-dev (as you correctly
   identified).

crossqa uses dose to check dependency issues, so it can only see one of
many problems and the first issues it happens to see is with
libpurple-dev. To see the others, we check the bootstrap.d.n link:
https://bootstrap.debian.net/cross_all/chatty.html

Good news: It's libpurple-dev and libpurple-dev only.

Time to look into libpurple-dev, right?

It's an Architecture: all package and those can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign. So clear thing, we mark
it Multi-Arch: foreign and we're done, right? Unfortunately, not.
libpurple-dev Depends on libpurple0 (among other things) and quite
clearly, it exposes libpurple0. Since libpurple0 is
architecture-dependent and exposed by libpurple-dev, libpurple-dev
cannot be Multi-Arch: foreign. The thing is: When we issue a dependency
on libpurple-dev (for a particular architecture), we want a matching
libpurple0 (of the requested architecture). And this constraint cannot
be transferred through Architecture: all packages. That issue is known
as the "multiarch interpreter problem", because it happened with
interpreters first. In any case, the canonical solution to this problem
is to turn libpurple-dev Architecture: any. At that point the resolver
will pick the host architecture libpurple-dev and the dependency will
ensure that we also get the host architecture libpurple0.

If this leaves any questions, don't hesitate to ask
(debian-cr...@lists.debian.org).

Helmut

Bug#996906: klibc FTBFS on armhf: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU

[Helmut Grohne]

Source: klibc
Version: 2.0.8-6.1
Severity: serious
Tags: ftbfs

klibc fails to build from source in unstable on armhf. I suppose this is
fallout from gcc-11.

Reproduced by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/klibc_2.0.8-6.1.rbuild.log.gz
| /usr/bin/make all INSTALLROOT=debian/tmp ARCH=arm CONFIG_AEABI=y 
CPU_ARCH=armv7-a CPU_TUNE=cortex-a8 CONFIG_KLIBC_THUMB=y KBUILD_VERBOSE=1 
CONFIG_DEBUG_INFO=y
| make[2]: Entering directory '/build/1st/klibc-2.0.8'
| /usr/bin/make -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=klcc
| rm -f klcc/klibc.config
| echo 'ARCH=arm' >> klcc/klibc.config
| echo 'ARCHDIR=arm' >> klcc/klibc.config
| echo 'CROSS=' >> klcc/klibc.config
| echo 'KCROSS=' >> klcc/klibc.config
| echo 'CC=gcc' >> klcc/klibc.config
| echo 'LD=ld' >> klcc/klibc.config
| echo 'REQFLAGS=-D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=32 
-fno-stack-protector -fwrapv -fno-PIE -fno-builtin-bcmp -fcommon -ggdb 
-fno-exceptions -mthumb -mabi=aapcs-linux -nostdinc -iwithprefix include 
-D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=32' >> klcc/klibc.config
| echo 'OPTFLAGS=-Os -march=armv7-a -mtune=cortex-a8' >> klcc/klibc.config
| echo 'LDFLAGS=--thumb-entry _start --build-id=sha1' >> klcc/klibc.config
| echo 'STRIP=strip' >> klcc/klibc.config
| echo 'STRIPFLAGS=-R .ARM.exidx --strip-all -R .comment -R .note' >> 
klcc/klibc.config
| echo 'EMAIN=--thumb-entry main' >> klcc/klibc.config
| echo 'BITSIZE=32' >> klcc/klibc.config
| echo 'VERSION=2.0.8' >> klcc/klibc.config
| echo 'prefix=/usr/lib/klibc' >> klcc/klibc.config
| echo 'bindir=/usr/lib/klibc/bin' >> klcc/klibc.config
| echo 'libdir=/usr/lib/klibc/lib' >> klcc/klibc.config
| echo 'includedir=/usr/lib/klibc/include' >> klcc/klibc.config
|   perl klcc/makeklcc.pl /build/1st/klibc-2.0.8/klcc/klcc.in klcc/klibc.config 
/usr/bin/perl > klcc/klcc || ( rm -f klcc/klcc ; exit 1 ) && chmod a+x klcc/klcc
| :
| /usr/bin/make -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=.
| /usr/bin/make -rR -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc 
obj=scripts/basic
|   gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer   -o scripts/basic/fixdep scripts/basic/fixdep.c
| :
| /usr/bin/make -rR -f /build/1st/klibc-2.0.8/scripts/Kbuild.klibc obj=usr/klibc
|   gcc -Wp,-MD,usr/klibc/.__static_init.o.d  -nostdinc -iwithprefix include 
-I/build/1st/klibc-2.0.8/usr/include/arch/arm -Iusr/include/arch/arm 
-I/build/1st/klibc-2.0.8/usr/include/bits32 -Iusr/include/bits32 
-I/build/1st/klibc-2.0.8/usr/klibc/../include -Iusr/klibc/../include 
-I/build/1st/klibc-2.0.8/usr/include -Iusr/include 
-I/build/1st/klibc-2.0.8/linux/include -Ilinux/include -D__KLIBC__=2 
-D__KLIBC_MINOR__=0 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-PIE 
-fno-builtin-bcmp -fcommon -ggdb -fno-exceptions -mthumb -mabi=aapcs-linux -Os 
-march=armv7-a -mtune=cortex-a8 -W -Wall -Wno-sign-compare 
-Wno-unused-parameter -c -o usr/klibc/__static_init.o usr/klibc/__static_init.c
| cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
| make[4]: *** [/build/1st/klibc-2.0.8/scripts/Kbuild.klibc:261: 
usr/klibc/__static_init.o] Error 1
| make[3]: *** [/build/1st/klibc-2.0.8/./Kbuild:9: all] Error 2
| make[2]: *** [Makefile:121: klibc] Error 2
| make[2]: Leaving directory '/build/1st/klibc-2.0.8'
| make[1]: *** [debian/rules:51: override_dh_auto_build] Error 2
| make[1]: Leaving directory '/build/1st/klibc-2.0.8'
| make: *** [debian/rules:45: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also seen by crossqa:
http://crossqa.debian.net/build/klibc_2.0.8-6.1_armhf_20211019164552.log

Helmut

Bug#996905: pms FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Helmut Grohne]

Source: pms
Version: 0.42-1
Severity: serious
Tags: ftbfs

pms fails to build from source, because ncurses added format string
annotations. A non-parallel build in unstable now ends as follows:

| g++ -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DLOCALE_DIR=\""/usr/share/locale"\" -c -o display.o `test -f 'src/display.cpp' 
|| echo './'`src/display.cpp
| src/display.cpp: In function ‘void colprint(pms_window*, int, int, color*, 
const char*, ...)’:
| src/display.cpp:1703:40: error: format not a string literal and no format 
arguments [-Werror=format-security]
|  1703 | wprintw(w->h(), _(output.c_str()));
|   | ~~~^~~
| In file included from src/pms.h:46,
|  from src/display.cpp:26:
| src/display.cpp:1737:59: error: format not a string literal and no format 
arguments [-Werror=format-security]
|  1737 | wprintw(w->h(), _(buf));
|   |   ^~~
| src/i18n.h:31:22: note: in definition of macro ‘_’
|31 | #define _(x) gettext(x)
|   |  ^
| src/display.cpp:1745:59: error: format not a string literal and no format 
arguments [-Werror=format-security]
|  1745 | wprintw(w->h(), _(buf));
|   |   ^~~
| src/i18n.h:31:22: note: in definition of macro ‘_’
|31 | #define _(x) gettext(x)
|   |  ^
| src/display.cpp:1756:59: error: format not a string literal and no format 
arguments [-Werror=format-security]
|  1756 | wprintw(w->h(), _(buf));
|   |   ^~~
| src/i18n.h:31:22: note: in definition of macro ‘_’
|31 | #define _(x) gettext(x)
|   |  ^
| src/display.cpp:1790:32: error: format not a string literal and no format 
arguments [-Werror=format-security]
|  1790 | wprintw(w->h(), _(output.c_str()));
|   | ~~~^~~
| cc1plus: some warnings being treated as errors
| make[2]: *** [Makefile:470: display.o] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:235: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:4: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#996894: colordiff: Error messages interrupt output

[Reuben Thomas]

Package: colordiff
Version: 1.0.18-1
Severity: normal

Error messages are not correctly interleaved with output; for example:

-Foo
diff: bar/baz.html+Bar
: No such file or directory

Here, the error message should say

diff: bar/baz.html: No such file or directory

but the (presumably stderr) line has been split in the middle, and
interleaved with the (presumably stdout) output.

I see that there’s a new version of colordiff 1.0.19, but the changelog does
not mention this issue.

Thanks for working on colordiff!

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0-37-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages colordiff depends on:
ii  perl  5.30.0-9ubuntu0.2

colordiff recommends no packages.

colordiff suggests no packages.

-- no debconf information

Bug#996884: Ambiguous licenses for files in debian/patches/ folders

[Santiago Ruano Rincón]

El 20/10/21 a las 14:46, Dylan Aïssi escribió:
> Hi Santiago,
> 
> Le mer. 20 oct. 2021 à 14:03, Santiago Ruano Rincón
>  a écrit :
> >
> > Thanks for pointing this out. Hopefully, this change solves the
> > ambiguity:
> > https://salsa.debian.org/debian/libcgroup/-/blob/8476aa90da599fe59ad33d6a9911b931291b84f4/debian/copyright#L17
> >
> 
> Indeed, thanks :)
> 
> The copyright holders are probably wrong, you should add the patches authors.
…

Mmmm, I am not a license-nerd, and I am not sure about that. Could you
please provide documentation about the copyright holders of patches? Do
you have examples in debian packages that give that level of detail in
d/copyright about debian/patches/*?

Best,

 -- S


signature.asc
Description: PGP signature

Bug#996904: doas: Add pam_limit.so to PAM configuration (Cf. #518464 for sudo)

[Salvatore Bonaccorso]

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

Hi

It looks that doas replicates the PAM configuration from sudo, which
is missing the inclusion for pam_limits.so (cf. #518464).

The oss-security post in
https://www.openwall.com/lists/oss-security/2021/10/20/2 given some
details on why.

For sudo I created the following merge request
https://salsa.debian.org/sudo-team/sudo/-/merge_requests/7 and can
sent as similar change for 'doas' if needed.

Regards,
Salvatore

Bug#518464: Restore inclusion of pam_limits.so PAM module

[Salvatore Bonaccorso]

Control: retitle -1 sudo: Restore inclusion of pam_limits.so PAM module
Control: tags -1 + security
Control: severity -1 important

On Fri, Mar 06, 2009 at 12:23:27PM +0100, Xavier Martin wrote:
> Package: sudo
> Version: 1.6.9p17-2
> Severity: normal
> 
> I've upgraded from Etch to Lenny, 
> ulimit doesn't report correct open files limits set on my machine
> 
> Here's a test case:
> # sudo -u www-data /bin/bash -c 'ulimit -n'
> 4096
> 
> # grep nofile /etc/security/limits.conf 
> * soft nofile 4096
> * hard nofile 65535
> 
> 
> On previous version of sudo : 1.6.8p12-4
> 
> # sudo -u www-data /bin/bash -c 'ulimit -n'
> 65536
> 
> 
> I'd think it's related to a change in /etc/pam.d/sudo
> 
> 1.6.8p12-4:
> #%PAM-1.0
> 
> @include common-auth
> @include common-account
> 
> 1.6.9p17-2:
> #%PAM-1.0
> 
> @include common-auth
> @include common-account
> 
> session required pam_permit.so
> session required pam_limits.so

This is a longstanding issue and in fact we should restore the
inclusion of the pam_limits.so. This serves as mitigation/hardening
against the issue as explained in

https://www.openwall.com/lists/oss-security/2021/10/20/2

I made a merge request addressing this at least for unstable for now
in 

https://salsa.debian.org/sudo-team/sudo/-/merge_requests/7

The same issue affects 'doas', will fill a bug about it.

Regards,
Salvatore