Bug#1006639: RFS: rednotebook/2.24+ds-1~bpo11+1 -- Modern desktop diary and personal journaling tool

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: rednotebook
   Version : 2.24+ds-1~bpo11+1
   Upstream Author : Jendrik Seipp 
 * URL : https://rednotebook.app
 * License : LGPL-3+, PSF-2, CC0-1.0, GPL-2+, GPL-3+
 * Vcs : https://github.com/jendrikseipp/rednotebook
   Section : text

It builds those binary packages:

  rednotebook - Modern desktop diary and personal journaling tool

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.24+ds-1~bpo11+1.dsc

Changes since the last upload:

 rednotebook (2.24+ds-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1005339: [Solved] This issue is not a Debian bullseye problem

[Mario Natiello]

[Solved]
The issue is solved if the external monitor is connected natively to the
laptop's displayport instead of using displaymanager-debian through a
dock.

-- 
Mario Natiello

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Andrius Merkys]

Hi Dima,

On 2022-02-28 22:04, Dima Kogan wrote:
> Andrius: you packaged some of the dependencies of BoofCV, and you
> mentioned that you were interested in getting BoofCV itself into Debian.
> Are you still interested in doing that? If you already looked into it,
> can you share any specific challenges that you hit when trying to
> package this library? I spoke to the upstream dev (Peter Abeles, Cc-ed),
> and he's potentially interested in helping with this effort. The 3 of us
> should be able to get this done.

Thanks for an ITP. I am also interested in getting BoofCV into Debian
due to one of my interests, Cephis, depending on BoofCV. I recall
running into obstacles beyond my capabilities, thus I dropped the ball.
Nevertheless I would be happy to revive the effort.

One of the obstacles I faced was the Gradle build system. Gradle in
Debian is several major releases old, and sources usually quite tightly
depend on it. Moreover, I do not have much experience with Gradle in
Debian, thus back then I used to spend much time patching the build.

Also I got quite many problems with dependencies. Some were difficult to
package for Debian, some were even non-free (if I recall right) and some
just caused FTBFS possibly due to API changes. Sorry for the vagueness,
this was in 2019 and I did not leave much self-notes on this. I ended up
patching many submodules due to the problems with dependencies.

I have my packaging at hand and I will push it once Salsa becomes online
again. I will use my personal namespace. I will let you know when this
is done.

It is great that you have contacted Peter Abeles about BoofCV. It would
surely be great to have Peter's help. However, I am afraid we may have
to start by looking into updating Gradle in Debian.

Best,
Andrius

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer Marin Rodrigues]

Quoting Francesco Poli (2022-03-01 00:49:50)
> > > However, it leaves a lot of "production scrap" within /dev/shm :
> > >
> > >  $ du --si -s /dev/shm/.guestfs-1000/
> > >  755M/dev/shm/.guestfs-1000/
> > >
> > > More than 750 MB of "production scrap"!
> > >
> > > Why does guestfish do this?
> > 
> > I don't know and I don't have these files in my own $TMPDIR.
> 
> I added a
> 
>   rm -Rf ${TMPDIR}/.guestfs-*/
> 
> at the end of the script...

Interesting. I don't see a directory like that anywhere on my system. Not even
while guestfish is running.

> > In any case, if it works for you now, maybe you can close this bug?
> 
> Well, I first need to check that it actually works as a testbed for
> autopkgtest (this was the initial goal of this incredible journey, if
> you recall!).

Yes. :)

> Moreover, I tried to modify the script to more closely follow the
> [streamlined suggestions].
> 
> [streamlined suggestions]: 
> 
> 
> And, after doing so, the image was no longer able to boot!
> It hanged (seemingly forever) while booting from hard disk.
> 
> I performed various tests (basically bisecting between the working
> script and the failing one).
> I found out that the issue was in the suggested 'extlinux.conf':
> 
> $ diff -u bin/BAD_mmdebstrap-autopkgtest-qemu bin/mmdebstrap-autopkgtest-qemu 
> --- bin/BAD_mmdebstrap-autopkgtest-qemu 2022-03-01 00:05:16.418739282 +0100
> +++ bin/mmdebstrap-autopkgtest-qemu 2022-03-01 00:27:14.874469123 +0100
> @@ -134,7 +134,7 @@
>  
>  label linux
>  kernel /vmlinuz
> -append initrd=/initrd.img root=/dev/vda1 console=ttyS0
> +append initrd=/initrd.img root=/dev/vda1 rw net.ifnames=0 console=ttyS0
>  EOF
>  
>  $GUESTFISH --new debian-unstable.img=disk:"$SIZE" -- \
> 
> 
> I don't understand why, but this is how I fixed the script.
> Should the documentation be fixed?

Yes, thank you! I can confirm that the "rw" kernel cmdline option is indeed
essential (I don't know why) so thanks for finding this before I make a release
with wrong instructions.

Can you share the final version of your script? Maybe I should include it
somewhere in the mmdebstrap packaging.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Hi Rob!

On 2/28/22 19:18, John Paul Adrian Glaubitz wrote:
> The attached patch seems to work correctly. I had to escape the whole 
> statements
> so that they are not interpreted by automake.

I have verified that the attached patch fixes the build on 32-bit PowerPC 
(powerpc).

Adrian

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

Bug#1006638: firmware-misc-nonfree: /lib/firmware/i915/adlp_dmc_ver2_12.bin missing

[Stefan Rücker]

Package: firmware-misc-nonfree
Version: 20210818-1
Severity: normal

root@mars:/lib/firmware/i915# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.16.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/adlp_dmc_ver2_12.bin for module
i915

It can be found here:
https://anduin.linuxfromscratch.org/sources/linux-firmware/i915/


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

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

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.140

-- no debconf information

Bug#1006637: greenbone-security-assistant: No more sysvinit service file

[Bardot Jerome]

Package: greenbone-security-assistant
Version: 21.4.3-1
Severity: important
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

I just see the sysvinit script have been remove.
So service can not start on systemd less system.


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

Kernel: Linux 5.15.0-3-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) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages greenbone-security-assistant depends on:
ii  greenbone-security-assistant-common  21.4.3-1
ii  gvmd 21.4.4-1
ii  libc62.33-7
ii  libgcrypt20  1.9.4-5
ii  libglib2.0-0 2.70.4-1
ii  libgnutls30  3.7.3-4+b1
ii  libgvm21 21.4.3-1
ii  libmicrohttpd12  0.9.75-3
ii  libxml2  2.9.12+dfsg-6
ii  lsb-base 11.1.0

greenbone-security-assistant recommends no packages.

greenbone-security-assistant suggests no packages.

-- no debconf information

Bug#997383: dh-virtualenv: FTBFS: AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'

[Kunal Mehta]

severity 997383 minor
tags 997383 fixed-upstream
thanks

Hi,

On Sat, 23 Oct 2021 21:49:56 +0200 Lucas Nussbaum  wrote:

> Exception occurred:
>   File "/<>/doc/conf.py", line 30, in setup
> app.add_stylesheet('css/custom.css')
> AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'
> The full traceback has been saved in /tmp/sphinx-err-qj3dzcul.log, if you 
want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
message can be provided next time.
> A bug report can be filed in the tracker at 
. Thanks!
> make[1]: *** [debian/rules:28: override_dh_installdocs] Error 1


From what I can tell, the add_stylesheet removal was delayed upstream 
and as a result dh-virtualenv no longer FTBFS in sid, so I'm downgrading 
the severity to minor.


Fixing the deprecation warning should be as simple as cherry-picking 
, 
which I can do as a NMU if that's wanted.


-- Kunal

Bug#1006636: Thunderbird fails to edit a recurring event

[Daniel Kahn Gillmor]

Package: thunderbird
Version: 1:91.6.1-1

The attached .ics file ("foo.ics") contains a recurring event.

If i use Thunderbird's "File » Open » Calendar File…" to open this, it
creates a new calendar named "redacted", and the event shows up as
expected (on 2022-03-02).

If i right-click the event in the calendar view, and choose "edit", i
get an option "Edit only this occurence" or "Edit all occurrences".

If i choose "Edit only this occurrence", the edit dialog box appears,
but i cannot change which calendar it is in (i cannot move it to a
different calendar, because the "Calendar:" entry dropdown field is
grayed out.

If i choose "Edit all occurrences", the Calendar: dropdown is enabled,
but the edit view contains no information but the starting date/time: no
title, ending time is the same as start time, no location, etc.  And
indeed i cannot even save the event properly in this case without
entering something for the title.

I've tried this with a brand new profile, and see the same problem
repeatedly.

It's entirely possible that this is a malformed .ics file, but it is a
copy of a text/calendar attachment that i received from an Outlook
client via Office365, with various content fields redacted: i changed
nothing related to date/time, but redacted participant names, location
URLs, etc.

It's also entirely possible that this is an upstream bug.  If you think
i should forward it upstream, please let me know.

Thanks for maintaining Thunderbird in Debian!

  --dkg

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=The Sender:mailto:sen...@example.org
DESCRIPTION;LANGUAGE=en-US:test
UID:04008200E00074C5B7101A82E008E970F189431CD801000
 010001AA5D6D60C3FB840A00FDCC4BE749158
RECURRENCE-ID;TZID=Eastern Standard Time:20220302T13
SUMMARY;LANGUAGE=en-US:All Staff Meeting
DTSTART;TZID=Eastern Standard Time:20220302T13
DTEND;TZID=Eastern Standard Time:20220302T14
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20220228T214601Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:2
LOCATION;LANGUAGE=en-US:https://test.example.org/
X-MICROSOFT-CDO-APPT-SEQUENCE:2
X-MICROSOFT-CDO-OWNERAPPTID:2120367593
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-ONLINEMEETINGINFORMATION:{"OnlineMeetingChannelId":null\,"Onlin
 eMeetingProvider":3}
X-MICROSOFT-SKYPETEAMSMEETINGURL:https://foo.example.org
X-MICROSOFT-SCHEDULINGSERVICEUPDATEURL:https://bar.example.org
X-MICROSOFT-SKYPETEAMSPROPERTIES:{"cid":"19:meeting_baz@thread.v2"\,"rid":0\,"mid":0\,"uid":null\,"priva
 te":true\,"type":0}
X-MICROSOFT-ONLINEMEETINGCONFLINK:conf:sip:sen...@example.org\;gruu\;opaque=a
 pp:conf:focus:id:teams:2:0!19:meeting_baz-thread.v2!uuid1!uuid2
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONDISPLAYNAME:https://test.example.org
X-MICROSOFT-LOCATIONSOURCE:None
X-MICROSOFT-LOCATIONS:[{"DisplayName":"https://test.example.org"\,"LocationAnnotation":""\,
 "LocationUri":""\,"LocationStreet":""\,"LocationCity":""\,"LocationState":
 ""\,"LocationCountry":""\,"LocationPostalCode":""\,"LocationFullAddress":"
 "}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR


signature.asc
Description: PGP signature

Bug#1006635: Unable to fetch DNSKEY set '.'

[Marco d'Itri]

Package: bind9
Version: 1:9.16.22-1~deb11u1
Severity: normal

I get this message every few days:

Feb  1 23:14:56 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out
Feb  2 23:14:43 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out
Feb  3 23:15:14 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out
Feb  4 23:14:54 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out
Feb  5 23:14:40 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out
Feb  6 23:14:56 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out
Feb 24 23:14:12 attila named[1757]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': operation canceled
Feb 28 23:14:12 attila named[1757]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': operation canceled
Jan 30 23:14:43 attila named[23911]: managed-keys-zone: Unable to fetch DNSKEY 
set '.': timed out

But DNSSEC generally appears to work:

Feb 27 00:14:13 attila named[1757]: managed-keys-zone: Key 20326 for zone . is 
now trusted (acceptance timer complete)
Feb 27 23:14:12 attila named[1757]: managed-keys-zone: Key 20326 for zone . is 
now trusted (acceptance timer complete)
Feb 28 00:14:13 attila named[1757]: managed-keys-zone: Key 20326 for zone . is 
now trusted (acceptance timer complete)
Mar  1 00:14:12 attila named[1757]: managed-keys-zone: Key 20326 for zone . is 
now trusted (acceptance timer complete)



options {
...

  dnssec-validation auto;
};

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#984053: fix for etl: ftbfs with GCC-11

[Rodolfo Ribeiro Gomes]

I fixed this issue upstream and attached the patch here.

Upstream commit:
https://github.com/synfig/synfig/commit/e2f89aac473ba9016582d35f9fac74e61e99ec8c
From e2f89aac473ba9016582d35f9fac74e61e99ec8c Mon Sep 17 00:00:00 2001
From: rodolforg 
Date: Mon, 28 Feb 2022 22:46:15 -0300
Subject: [PATCH] ETL test: avoid clash between ETL::hermite and std::hermite (#2547)

---
 ETL/test/angle.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ETL/test/angle.cpp b/ETL/test/angle.cpp
index 60042ef..3cc52b1 100644
--- a/ETL/test/angle.cpp
+++ b/ETL/test/angle.cpp
@@ -201,7 +201,7 @@ int angle_test()
 
 		affine_combo combo;
 
-		hermite hermie(a,b,b.dist(a),b.dist(a));
+		etl::hermite hermie(a,b,b.dist(a),b.dist(a));
 
 		for(f=0;f<1.001;f+=0.1)
 		{
--
libgit2 1.1.0

Bug#1006634: ITP: golang-github-hairyhenderson-go-codeowners -- A Go package that finds and parses GitHub CODEOWNERS files

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-hairyhenderson-go-codeowners
  Version : 0.2.2+git20201026.cdc7c07-1
  Upstream Author : Dave Henderson
* URL : https://github.com/hairyhenderson/go-codeowners
* License : Expat
  Programming Lang: Go
  Description : Go package that finds and parses GitHub CODEOWNERS files

 go-codeowners is a Go package that finds and parses CODEOWNERS files;
 see https://help.github.com/articles/about-codeowners/
 .
 Features:
 .
  * operates on local repos
  * doesn't require a cloned repo (i.e. doesn't need a .git directory to
be present at the repo's root)
  * can be called from within a repo (doesn't have to be at the root)
  * will find CODEOWNERS files in all documented locations: the repo's
root, docs/, and .github/ (or .gitlab/ for GitLab repos)

Reason for packaging: Needed by hugo >= v0.93.0

Bug#1006633: procmail is unmaintained and a security liability

[Antoine Beaupre]

Package: procmail
Version: 3.22-26
Severity: critical
Tags: security
X-Debbugs-Cc: Debian Security Team 

procmail is a security liability and completely unmaintained
upstream. there are viable alternatives, and it should be removed from
debian. details below.

# unmaintained

procmail is unmaintained. the "Final release", according to
Wikipedia[1], dates back to September 10, 2001 (3.22). this is the
release that is shipped with Debian, although we do have *26*
debian-specific uploads on top of that (3.22-26, in all suites since
buster).

[1]: https://en.wikipedia.org/wiki/Procmail

that release entered Debian on 2001-11-21, now twenty (!) years ago,
and presumably shipped with Debian 3.0 "woody":

https://tracker.debian.org/news/269157/installed-procmail-322-1-i386-source/

the upstream website has been down since about 2016, according to a
quick tour around archive.org. it currently returns an empty JSON
document, mysteriously. (reported as #805864 in 2015, no change
since.)

in effect, we are maintaining a fork of this dead software.

# security liability

by default, procmail is installed suid root:mail. there's no debconf
or preseed that can change that, although you could, in theory, do a
dpkg-divert to workaround that, but I doubt anyone deploying procmail
these days does that.

the last maintainer of procmail explicitly advised us (in #769938) and
other projects (e.g. OpenBSD, in [2]) to stop shipping it.

[2]: https://marc.info/?l=openbsd-ports=141634350915839=2

Quote:

> Executive summary: delete the procmail port; the code is not safe
> and should not be used as a basis for any further work.

That Debian bug report is still open, and concerns a NULL pointer
dereference. I do not know if it is exploitable. Strangely, the
original procmail author (Stephen R. van den Berg, presumably) wrote
in that bug report *last year* saying that was "Fixed in upcoming 3.23
release", which has been targeted for release for all of those last 20
years.

# alternatives

there are plenty of modern alternatives to procmail, typically part of
the mail server. Dovecot has its own LDA which implements the standard
Sieve language (RFC 5228, published in 2008, 7 years after procmail's
death). Courier has "maildrop" which has its own filtering
mechanism. then the tmux author, in 2007, wrote fdm as a fetchmail and
procmail replacement.

but procmail, of course, doesn't just ship procmail (that would be too
easy). it ships `mailstat(1)` which we could probably ignore because
it only parses procmail log files. but more importantly, it also
ships:

lockfile - conditional semaphore-file creator
formail - mail (re)formatter

lockfile already has somewhat acceptable (if TOCTOU is something you
like) in the form of `flock(1)`, part of util-linux (which is
Essential). it might not be a direct drop-in replacement, but it
should be close enough.

formail is similar: the courier `maildrop` package ships
`reformail(1)` which is, presumably, a rewrite of formail. it's
unclear if it's a drop-in replacement, but it should probably possible
to port uses of formail to it easily.

# conclusion

there is really, absolutely, no reason to keep procmail in Debian at
this point. it's a great part of our computing history, and it should
be kept forever in our museums and historical archive, but not in
main, and certainly not in bookworm or even sid. it's just a bomb
waiting to go off.

-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 procmail depends on:
ii  libc6  2.31-13+deb11u2

Versions of packages procmail recommends:
ii  postfix [mail-transport-agent]  3.5.6-1+b1

procmail suggests no packages.

Bug#1006632: Please upgrade to 22.1.0 (1st stable release!)

[Nicholas D Steeves]

Package: black
Version: 21.12b0-1
Severity: normal
X-Debbugs-Cc: s...@debian.org, Neil Williams , Sylvestre 
Ledru , Chris Lamb 

The Black project has made it's first stable release, and it even has
a defined stability policy!

  
https://black.readthedocs.io/en/stable/the_black_code_style/index.html#stability-policy

I'm happy to read that a potentially large risk of disruptive change
will now only occur be once a year :-D

Changelog is available here:

  https://github.com/psf/black/blob/main/CHANGES.md

Reverse Depends:
  elpa-elpy
  python3-typer
  python3-schema-salad
  python3-pylsp-black
  python3-cogent3
  python3-pyls-black
  lava-dev

I would prefer if someone else would update and upload, because I'm
not sure to what degree the changes affect the rdeps, and I don't want
to carelessly make trouble for others.  Also, I'm not sure if the
documented issues related to mypyc affect our Black package, nor if
these issues represent a regression between 21.12b0 and 22.1.0.

My stake in this is Elpy, which is finally actively maintained again.
At this time, the upstream snapshot of Elpy (merged to salsa) FTBFS
due to missing/bad/changed pyproject.toml parsing support in Black,
and obviously it's a better use of time and goodwill to target the
stable version (which we want in Debian) rather than the current
version.  I concede that the bug may be in Elpy, and in this case it
makes sense to fix it for a year rather than fix it for backwards
compat with a beta release of Black.

Kind regards,
Nicholas

Bug#1004829: goldendict: diff for NMU version 1.5.0~rc2+git20210630+ds-2.1

[Sebastian Ramacher]

Control: tags 1004829 + patch
Control: tags 1004829 + pending

Dear maintainer,

I've prepared an NMU for goldendict (versioned as 1.5.0~rc2+git20210630+ds-2.1) 
and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru goldendict-1.5.0~rc2+git20210630+ds/debian/changelog goldendict-1.5.0~rc2+git20210630+ds/debian/changelog
--- goldendict-1.5.0~rc2+git20210630+ds/debian/changelog	2021-09-21 00:41:11.0 +0200
+++ goldendict-1.5.0~rc2+git20210630+ds/debian/changelog	2022-03-01 01:08:32.0 +0100
@@ -1,3 +1,10 @@
+goldendict (1.5.0~rc2+git20210630+ds-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix build with ffmpeg 5.0 (Closes: #1004829)
+
+ -- Sebastian Ramacher   Tue, 01 Mar 2022 01:08:32 +0100
+
 goldendict (1.5.0~rc2+git20210630+ds-2) unstable; urgency=medium
 
   * Rebuild against opencc 1.1.3.
diff -Nru goldendict-1.5.0~rc2+git20210630+ds/debian/patches/0002-add-supprt-for-ffmpeg-5.0.patch goldendict-1.5.0~rc2+git20210630+ds/debian/patches/0002-add-supprt-for-ffmpeg-5.0.patch
--- goldendict-1.5.0~rc2+git20210630+ds/debian/patches/0002-add-supprt-for-ffmpeg-5.0.patch	1970-01-01 01:00:00.0 +0100
+++ goldendict-1.5.0~rc2+git20210630+ds/debian/patches/0002-add-supprt-for-ffmpeg-5.0.patch	2022-03-01 01:07:48.0 +0100
@@ -0,0 +1,25 @@
+From 8acb288c9e9bdb3c6bf2e803954dd3b6ac273c05 Mon Sep 17 00:00:00 2001
+From: Liao Junxuan 
+Date: Sun, 20 Feb 2022 12:28:05 +0800
+Subject: [PATCH] add support for ffmpeg 5.0
+
+---
+ ffmpegaudio.cc | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/ffmpegaudio.cc b/ffmpegaudio.cc
+index d550f4a77..7948d2187 100644
+--- a/ffmpegaudio.cc
 b/ffmpegaudio.cc
+@@ -94,7 +94,11 @@ struct DecoderContext
+   QByteArray audioData_;
+   QDataStream audioDataStream_;
+   AVFormatContext * formatContext_;
++#if LIBAVCODEC_VERSION_MAJOR < 59
+   AVCodec * codec_;
++#else
++  const AVCodec * codec_;
++#endif
+   AVCodecContext * codecContext_;
+   AVIOContext * avioContext_;
+   AVStream * audioStream_;
diff -Nru goldendict-1.5.0~rc2+git20210630+ds/debian/patches/series goldendict-1.5.0~rc2+git20210630+ds/debian/patches/series
--- goldendict-1.5.0~rc2+git20210630+ds/debian/patches/series	2021-08-28 19:07:48.0 +0200
+++ goldendict-1.5.0~rc2+git20210630+ds/debian/patches/series	2022-03-01 01:07:58.0 +0100
@@ -1 +1,2 @@
 0001-Disable-default-autostart.patch
+0002-add-supprt-for-ffmpeg-5.0.patch


signature.asc
Description: PGP signature

Bug#1006631: lintian: Recommend moving D-Bus policy files from /etc to /usr

[Simon McVittie]

Package: lintian
Version: 2.114.0
Severity: wishlist

dbus supports policy files in both /usr/share/dbus-1/system.d and
/etc/dbus-1/systemd. I recently released dbus 1.14.0, which officially
deprecates installing packages' default policies into /etc/dbus-1/systemd,
instead reserving it for the sysadmin. This is the same idea as the
difference between /lib/udev/rules.d and /etc/udev/rules.d.

It would be useful for Lintian to have a dbus-policy-in-etc tag, mirroring
udev-policy-in-etc. I attach an implementation (based on commit 11926263,
and might need rebasing on current git, which I can't do because salsa
is down at the moment).

/usr/share/dbus-1 has worked since Debian 9, and the transition from
/etc/dbus-1 to /usr/share/dbus-1 is already about ⅓ complete:
/usr/share/dbus-1/system.d is currently used by 75 policy files in 61
binary packages, while /etc/dbus-1/system.d is used by 135 files in
124 binary packages.

Thanks,
smcv
>From 34fffb40208ec3241f1af43670fa55751f7af474 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 28 Feb 2022 19:43:41 +
Subject: [PATCH] desktop/dbus: Check for dbus policy files installed into /etc

dbus 1.14.0 officially deprecates this, following the same principles
used for udev rules. /etc/dbus-1 is now reserved for the sysadmin
(analogous to /etc/udev), and OS packages should use /usr/share/dbus-1
(analogous to /lib/udev).

Signed-off-by: Simon McVittie 
---
 lib/Lintian/Check/Desktop/Dbus.pm|  3 +++
 .../dbus/dbus-policy/build-spec/debian/install   |  1 +
 .../share}/dbus-1/system.d/at-console.conf   |  0
 .../checks/desktop/dbus/dbus-policy/eval/hints   |  5 +++--
 tags/d/dbus-policy-in-etc.tag| 16 
 5 files changed, 23 insertions(+), 2 deletions(-)
 rename t/recipes/checks/desktop/dbus/dbus-policy/build-spec/orig/{etc => usr/share}/dbus-1/system.d/at-console.conf (100%)
 create mode 100644 tags/d/dbus-policy-in-etc.tag

diff --git a/lib/Lintian/Check/Desktop/Dbus.pm b/lib/Lintian/Check/Desktop/Dbus.pm
index e49e63c2e..582a5263c 100644
--- a/lib/Lintian/Check/Desktop/Dbus.pm
+++ b/lib/Lintian/Check/Desktop/Dbus.pm
@@ -74,6 +74,9 @@ my $PROPERTIES = 'org.freedesktop.DBus.Properties';
 sub check_policy {
 my ($self, $item) = @_;
 
+$self->pointed_hint('dbus-policy-in-etc', $item->pointer)
+  if $item->name =~ m{^etc/};
+
 my $xml = $item->decoded_utf8;
 return
   unless length $xml;
diff --git a/t/recipes/checks/desktop/dbus/dbus-policy/build-spec/debian/install b/t/recipes/checks/desktop/dbus/dbus-policy/build-spec/debian/install
index ee19d5d17..a75e23712 100644
--- a/t/recipes/checks/desktop/dbus/dbus-policy/build-spec/debian/install
+++ b/t/recipes/checks/desktop/dbus/dbus-policy/build-spec/debian/install
@@ -1 +1,2 @@
 etc
+usr
diff --git a/t/recipes/checks/desktop/dbus/dbus-policy/build-spec/orig/etc/dbus-1/system.d/at-console.conf b/t/recipes/checks/desktop/dbus/dbus-policy/build-spec/orig/usr/share/dbus-1/system.d/at-console.conf
similarity index 100%
rename from t/recipes/checks/desktop/dbus/dbus-policy/build-spec/orig/etc/dbus-1/system.d/at-console.conf
rename to t/recipes/checks/desktop/dbus/dbus-policy/build-spec/orig/usr/share/dbus-1/system.d/at-console.conf
diff --git a/t/recipes/checks/desktop/dbus/dbus-policy/eval/hints b/t/recipes/checks/desktop/dbus/dbus-policy/eval/hints
index 164613fd4..60660677c 100644
--- a/t/recipes/checks/desktop/dbus/dbus-policy/eval/hints
+++ b/t/recipes/checks/desktop/dbus/dbus-policy/eval/hints
@@ -4,5 +4,6 @@ dbus-policy (binary): dbus-policy-without-send-destination  [etc/dbus-1/system.d/send-destination.conf:3]
 dbus-policy (binary): dbus-policy-excessively-broad  [etc/dbus-1/system.d/send-destination.conf:5]
 dbus-policy (binary): dbus-policy-excessively-broad  [etc/dbus-1/system.d/send-destination.conf:4]
-dbus-policy (binary): dbus-policy-at-console  [etc/dbus-1/system.d/at-console.conf:3]
-dbus-policy (binary): dbus-policy-at-console  [etc/dbus-1/system.d/at-console.conf:4]
+dbus-policy (binary): dbus-policy-in-etc [etc/dbus-1/system.d/send-destination.conf]
+dbus-policy (binary): dbus-policy-at-console  [usr/share/dbus-1/system.d/at-console.conf:3]
+dbus-policy (binary): dbus-policy-at-console  [usr/share/dbus-1/system.d/at-console.conf:4]
diff --git a/tags/d/dbus-policy-in-etc.tag b/tags/d/dbus-policy-in-etc.tag
new file mode 100644
index 0..b126f877b
--- /dev/null
+++ b/tags/d/dbus-policy-in-etc.tag
@@ -0,0 +1,16 @@
+Tag: dbus-policy-in-etc
+Severity: warning
+Check: desktop/dbus
+Explanation: The package contains D-Bus policy configuration and installs it
+ under /etc/dbus-1/system.d or
+ /etc/dbus-1/session.d. These directories are reserved for
+ local configuration, which overrides the default policies in
+ /usr.
+ .
+ The correct directory for system bus policy installed by packages is
+ /usr/share/dbus-1/system.d.
+ .
+ The correct directory for session bus policy installed by packages
+ (not usually needed) is 

Bug#1002010: find-completion: don't look for -exec etc command if completing before it

[chris]

Hi!

I, too, have been experiencing this bug for more than a year. 
Applying https://www.github.com/scop/bash-completion/
commit/f1ddf810e4ee6693acb9fab1be1794586aa111a0[1], 
fixed it right away. The bash-completion version I've applied it 
to, was 1:2.11-5, so just as the comment above.


[1] https://www.github.com/scop/bash-completion/commit/
f1ddf810e4ee6693acb9fab1be1794586aa111a0

Bug#1004616: performous: FTBFS with ffmpeg 5.0

[Sebastian Ramacher]

Control: tags -1 upstream fixed-upstream

On 2022-01-30 22:20:04 +0100, Sebastian Ramacher wrote:
> Source: performous
> Version: 1.1+git20181118-5
> Severity: important
> X-Debbugs-Cc: sramac...@debian.org
> Tags: sid bookworm ftbfs
> Usertags: ffmpeg5.0
> 
> performous FTBFS with ffmpeg 5.0 (available in experimental):
> | cd /<>/obj-x86_64-linux-gnu/game && /usr/lib/ccache/c++ 
> -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK 
> -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK 
> -DBOOST_LOCALE_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK 
> -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DUSE_PORTMIDI 
> -DUSE_WEBSERVER -I/<>/ced -I/usr/include/SDL2 
> -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -I/usr/include/harfbuzz -I/usr/include/libmount -I/usr/include/blkid 
> -I/usr/include/fribidi -I/usr/include/pixman-1 -I/usr/include/uuid 
> -I/usr/include/libpng16 -I/usr/include/librsvg-2.0 
> -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/lib/x86_64-linux-gnu/libxml++-2.6/include -I/usr/include/libxml++-2.6 
> -I/usr/include/libxml2 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include 
> -I/usr/include/glibmm-2.4 -I/usr/include/sigc++-2.0 
> -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/cpprest 
> -I/<>/obj-x86_64-linux-gnu/game -DBOOST_NO_CXX11_SCOPED_ENUMS 
> -std=c++14 -Wall -Wextra -fcx-limited-range -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -pthread 
> -MD -MT game/CMakeFiles/performous.dir/fs.cc.o -MF 
> CMakeFiles/performous.dir/fs.cc.o.d -o CMakeFiles/performous.dir/fs.cc.o -c 
> /<>/game/fs.cc
> | /<>/game/ffmpeg.cc: In member function ‘void FFmpeg::open()’:
> | /<>/game/ffmpeg.cc:100:93: error: invalid conversion from 
> ‘AVCodec**’ to ‘const AVCodec**’ [-fpermissive]
> |   100 | m_streamId = av_find_best_stream(m_formatContext, 
> (AVMediaType)m_mediaType, -1, -1, , 0);
> |   | 
> ^~
> |   | 
> |
> |   | 
> AVCodec**
> | In file included from /<>/game/ffmpeg.cc:15:
> | /usr/include/x86_64-linux-gnu/libavformat/avformat.h:2161:41: note:   
> initializing argument 5 of ‘int av_find_best_stream(AVFormatContext*, 
> AVMediaType, int, int, const AVCodec**, int)’
> |  2161 | const AVCodec **decoder_ret,
> |   | ^~~
> | /<>/game/ffmpeg.cc:104:47: error: invalid conversion from 
> ‘const AVCodec*’ to ‘AVCodec*’ [-fpermissive]
> |   104 | AVCodec* pCodec = 
> avcodec_find_decoder(m_formatContext->streams[m_streamId]->codecpar->codec_id);
> |   |   
> ^~
> |   |   |
> |   |   const AVCodec*
> | make[3]: *** [game/CMakeFiles/performous.dir/build.make:289: 
> game/CMakeFiles/performous.dir/ffmpeg.cc.o] Error 1

This issue is fixed in upstream's 1.2.0-rc1.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1006630: smartmontools: Please do not change the upstream default of the 'smartd -q' option

[Christian Franke]

Package: smartmontools
Version: 7.2-1

The "default_never-quit.patch" changes the default of the 'smartd -q' 
option from '-q nodev' to '-q never'. It should be at least mentioned on 
the man page that this change is Debian (and possibly Ubuntu) specific.


The change of the default is not required as the following setting in 
the service file has the same effect:


  ExecStart=/usr/sbin/smartd -n -q never $smartd_opts

The '-q' option could then still be overridden via $smartd_opts.

Note that the new 7.3 version of smartmontools adds `-q *nodev0*` option 
variants which change the 'no devices' exit code from 17 to 0. The 
service should be no longer reported as failed then. "No devices to 
monitor" is reported via sd_notify() if configured.


Regards,
Christian Franke
smartmontools.org

Bug#1006629: unattended-upgrades: dry-run should not interfere with the system locks

[Micah Anderson]

Package: unattended-upgrades
Version: 2.8
Severity: wishlist

When unattended-upgrades is run with the --dry-run flag, it still acquires a
cache lock (presumably from apt update?), and makes a pid file. These can
interfere with unattended-upgrade runs that are done without the --dry-run, and
can result in Cache acquire lock errors.

Ideally, for --dry-run, unattended-upgrades could use a temporary directory for
the lists location, and the pid, if it even needs one.

thanks!

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

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-dbus   1.2.16-5
ii  python3-distro-info1.0
ii  ucf3.0043
ii  xz-utils   5.2.5-2

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-30
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd-sysv247.3-6

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20180807cvs-2
ii  needrestart 3.5-4
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  powermgmt-base  1.36
ii  python3-gi  3.38.0-2

-- debconf information excluded

Bug#1006628: needs versioned build-dep on golang-golang-x-sys-dev

[dann frazier]

Source: golang-github-moby-sys
Version: 0.0~git20201113.5a29239-1
Severity: normal
Tags: patch

Rebuilding golang-github-moby-sys with an older golang-golang-x-sys-dev
fails:

golang.org/x/sys/unix
path/filepath
github.com/moby/sys/mountinfo
# github.com/moby/sys/mountinfo
src/github.com/moby/sys/mountinfo/mounted_linux.go:15:16: undefined: 
unix.Openat2
src/github.com/moby/sys/mountinfo/mounted_linux.go:15:50: undefined: 
unix.OpenHow
src/github.com/moby/sys/mountinfo/mounted_linux.go:24:13: undefined: 
unix.Openat2
src/github.com/moby/sys/mountinfo/mounted_linux.go:24:40: undefined: 
unix.OpenHow
github.com/moby/sys/symlink
dh_auto_build: error: cd _build && go install -trimpath -v -p 1 
github.com/moby/sys/mount github.com/moby/sys/mountinfo 
github.com/moby/sys/symlink returned exit code 2
make: *** [debian/rules:6: binary] Error 2


It looks like the first upload w/ Openat2 support was:
  0.0~git20201101.da20708-1

So could we add a versioned build-dep?

--- debian/control.orig 2022-02-28 22:06:00.957994723 +
+++ debian/control  2022-02-28 22:00:28.630593702 +
@@ -7,7 +7,7 @@
 Build-Depends: debhelper-compat (= 12),
dh-golang,
golang-any,
-   golang-golang-x-sys-dev
+   golang-golang-x-sys-dev (>> 0.0~git20201101.da20708-1~)
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-moby-sys
 Vcs-Git: https://salsa.debian.org/go-team/packages/golang-github-moby-sys.git


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

Kernel: Linux 5.17.0-rc4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1006627: ntpsec package depends on libssl1.1 even if built against openssl3

[Michael Hudson-Doyle]

Source: ntpsec
Version: 1.2.1+dfsg1-3
Severity: normal

Dear Maintainer,

The ntpsec binary package on Ubuntu still depends on libssl1.1 despite
being built against openssl3. The reason for this turns out to be very
mundane:

mwhudson@anduril:~/src/pkg/ntpsec-1.2.1+dfsg1$ grep ssl1.1 --before 1 
debian/control
Depends: adduser,
 libssl1.1 (>= 1.1.1b),

Simply dropping this line and letting dh_shlibdeps do its thing seems
like it works for me but maybe there's some reason for this I don't
understand.

Cheers,
mwh
-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
'impish'), (400, 'impish-proposed'), (100, 'impish-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-30-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972525: fixed in gnupg2 2.2.27-1

[Aurelien Jarno]

control: reopen 972525
control: found 972525 gnupg2/2.2.27-2

On 2021-02-08 23:18, Debian FTP Masters wrote:
>* debian/patches/gpg-change-agent-spawn-2019-07-24-v2.patch: New patch to
>  fix a race condition, backported from master (Closes: #868550, #972525).

Although it *seems* to happen less often, we still observe the failure
from time to time on the buildds. For instance:

Signature with key '37B76E354F4D3F4EB64D699B374AD85D2226CD3D' requested:
 signfile buildinfo /home/buildd/build/linux_5.10.92-2_amd64-buildd.buildinfo 
37B76E354F4D3F4EB64D699B374AD85D2226CD3D
gpg: can't connect to the agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "37B76E354F4D3F4EB64D699B374AD85D2226CD3D": No agent running
gpg: /tmp/debsign.12nNJjLy/linux_5.10.92-2_amd64-buildd.buildinfo: clear-sign 
failed: No agent running
debsign: gpg error occurred!  Aborting


signature.asc
Description: PGP signature

Bug#1006626: biber: Lots of "Use of uninitialized value" warnings after biber update

[Ralf Jung]

Package: biber
Version: 2.17-2
Severity: normal

Dear Maintainer,

I updated biber to 2.17, and now I am getting many warnings (thousands of them
for large bib files, which significantly slows down biber itself) from files
that were clean before. The warnings all look like this:
```
Use of uninitialized value $opt in hash element at 
/usr/share/perl5/Biber/Config.pm line 977.
Use of uninitialized value within %Biber::Config::CONFIG_OPTSCOPE_BIBLATEX in 
hash dereference at /usr/share/perl5/Biber/Config.pm line 977.
```
Sometimes the line numbers are different (I have seen 967, 972, 977).

*Any* use of biber causes that warning for me, so here is an arbitrary example:
```
\documentclass[10pt,a4paper]{article}
\usepackage[backend=biber]{biblatex}

\addbibresource{bib.bib}

\begin{document}

\fullcite{iris}

\end{document}
```
With `bib.bib` being
```
@inproceedings{iris,
  author= {Ralf Jung and
   David Swasey and
   Filip Sieczkowski and
   Kasper Svendsen and
   Aaron Turon and
   Lars Birkedal and
   Derek Dreyer},
  title = {{Iris}: Monoids and Invariants as an Orthogonal Basis for 
Concurrent
   Reasoning},
  booktitle = {{POPL}},
  year  = {2015},
  doi   = {10.1145/2676726.2676980},
}
```

I reported this upstream at https://github.com/plk/biber/issues/403, but the
maintainer suggested this might be a packaging issues since they could not
reproduce the problem.

Kind regards,
Ralf

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

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages biber depends on:
ii  libautovivification-perl  0.18-1+b4
ii  libbusiness-isbn-perl 3.006-1
ii  libbusiness-ismn-perl 1.202-1
ii  libbusiness-issn-perl 1.005-1
ii  libclass-accessor-perl0.51-1
ii  libdata-compare-perl  1.27-1
ii  libdata-dump-perl 1.25-1
ii  libdata-uniqid-perl   0.12-1.1
ii  libdate-simple-perl   3.0300-3+b2
ii  libdatetime-calendar-julian-perl  0.107-1
ii  libdatetime-format-builder-perl   0.8300-1
ii  libdatetime-perl  2:1.55-1+b1
ii  libencode-eucjpms-perl0.07-3+b10
ii  libencode-hanextra-perl   0.23-5+b4
ii  libencode-jis2k-perl  0.03-1+b8
ii  libfile-slurper-perl  0.013-1
ii  libipc-run3-perl  0.048-2
ii  liblingua-translit-perl   0.28-1
ii  liblist-allutils-perl 0.19-1
ii  liblist-moreutils-perl0.430-2
ii  liblog-log4perl-perl  1.54-1
ii  liblwp-protocol-https-perl6.10-1
ii  libparse-recdescent-perl  1.967015+dfsg-2
ii  libreadonly-perl  2.050-3
ii  libregexp-common-perl 2017060201-1
ii  libsort-key-perl  1.33-2+b4
ii  libtext-bibtex-perl   0.88-3+b3
ii  libtext-csv-perl  2.01-1
ii  libtext-csv-xs-perl   1.47-1+b1
ii  libtext-roman-perl3.5-2.1
ii  libunicode-collate-perl   1.31-1+b1
ii  libunicode-linebreak-perl 0.0.20190101-1+b4
ii  liburi-perl   5.10-1
ii  libwww-perl   6.61-1
ii  libxml-libxml-simple-perl 1.01-1
ii  libxml-libxslt-perl   1.99-1+b2
ii  libxml-writer-perl0.900-1
ii  perl [libunicode-collate-perl]5.34.0-3
ii  tex-common6.17

Versions of packages biber recommends:
ii  texlive-bibtex-extra  2021.20220204-1

biber suggests no packages.

-- no debconf information

Bug#1006614: libccid: support for Solo2 and Nitrokey 3

[Ludovic Rousseau]

Le 28/02/2022 à 18:25, Dave Love a écrit :

Package: libccid
Version: 1.4.34-1~solo2+1
Severity: wishlist
X-Debbugs-Cc: none, Dave Love 


Hello Dave,


Various functions of the new free software/hardware Solo 2 security key
don't work in Debian 11 because libccid doesn't support it.  The same
probably goes for the Nitrokey 3 when it's available as it shares basic
firmware.  It seems worth supporting them since they're free devices,
either by backporting from unstable or patching the version in stable.
I don't know which is the best solution (or whether patching for extra
support is within policy), but I've tried both with success.

I built 1.5 from unstable on buster and bullseye (lowering the debhelper
version so it would also work on 10, and also Ubuntu 18.04 and 20.04).
Installing it solves at least that part of problems with the solo2 cli.
Then I tried the version from bullseye plus the /etc/libccid_Info.plist
from 1.5, which works; I'll probably post it for Solo 2 users.  As that
worked I rebuilt the bullseye version with a patch for
readers/supported_readers.txt to add Solo2 and Nitrokey entries, though
I guess it could have all the additions from the 1.5 version.  The
results are under .
Obviously I can send a patch if that's helpful.


I can't fix or upgrade packages in Debian stable, unless that is a security 
issue.

What you can do instead is backport the libccid package from unstable to 
stable. That is what you did.
This is also handled by the Debian backports project 
https://backports.debian.org/

Feel free to provide backported versions on your own web site if you want.

For the libccid package in Debian unstable, support of the Nitrokey 3 and 
SoloKeys Solo 2 is already included
https://ccid.apdu.fr/ccid/shouldwork.html#0x20A00x42B2
https://ccid.apdu.fr/ccid/shouldwork.html#0x12090xBEEE

So I have nothing to fix in Debian unstable.
I plan to close this bug report unless you think I can do something.

Bye

--
Dr. Ludovic Rousseau

Bug#1006625: pulseaudio-module-bluetooth: A2DP and HSP profiles unavailable after update

[Claire]

Package: pulseaudio-module-bluetooth
Version: 15.0+dfsg1-4
Severity: important
X-Debbugs-Cc: claire.dbts-0...@sitedethib.com

Dear Maintainer,

Since updating to 15.0+dfsg1-4 from 15.0+dfsg1-3, I am stuck with the
low-quality HFP profile.

Reinstalling pulseaudio, libpulseaudio0 and pulseaudio-module-bluetooth to
15.0+dfsg1-3 fixes the issue.

Rebuilding the pulseaudio packages by changing `-Dbluez5-gstreamer=enabled` to
`-Dbluez5-gstreamer=disabled` also works.

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

Kernel: Linux 5.17.0-rc5-custom (SMP w/32 CPU threads; PREEMPT)
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 pulseaudio-module-bluetooth depends on:
ii  bluez   5.62-2
ii  libbluetooth3   5.62-2
ii  libc6   2.33-7
ii  libdbus-1-3 1.12.22-1
ii  libglib2.0-02.70.4-1
ii  libgstreamer-plugins-base1.0-0  1.20.0-2
ii  libgstreamer1.0-0   1.20.0-1
ii  libpulse0   15.0+dfsg1-4
ii  libsbc1 1.5-3
ii  pulseaudio  15.0+dfsg1-4

Versions of packages pulseaudio-module-bluetooth recommends:
ii  gstreamer1.0-plugins-bad  1.20.0-3

pulseaudio-module-bluetooth suggests no packages.

-- no debconf information

Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

[nick black]

> However, I don't think that adding lmodern to the package Depends is the
> right solution, as that would lead to parts of tex (admittely, a small
> part, but still) having to be installed on the system, which is not
> required by pandoc itself.
> The right solution, I believe, is to add lmodern to the tests/control
> Depends, and I've just realized that I prepared that in git, but I never
> actually did the upload (ups), and was wondering why it wasn't
> working.

agreed, so long as it's not required by most outputs (i.e. you
can run pypandoc without it and it works).

> I will do the upload myself in the next few days, since I have an
> up-to-date copy of the repo locally (and salsa is down).

alrightie. this was my NM application bug; i guess i will find
another one. have a good day!


signature.asc
Description: PGP signature

Bug#1006519: openvpn: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

On 2022-02-28 17:22:35 [+0100], Bernhard Schmidt wrote:
> If you want to feel free to push this transition ahead, I can either live
> with temporary removal from testing or I will upload a git snapshot.

Thank you for looking into it. And no need to rush. The transistion did
not start yet. Once it does then you may have a new upstream release
ready ;)

Sebastian

Bug#1006624: src:ats2-lang: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: ats2-lang
Version: 0.4.0-1
Severity: serious
Control: close -1 0.4.2-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ats2-lang has been trying to migrate for 
63 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


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.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ats2-lang



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006623: src:lsp-plugins: fails to migrate to testing for too long: FTBFS on armhf

[Paul Gevers]

Source: lsp-plugins
Version: 1.1.30-1
Severity: serious
Control: close -1 1.1.31-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1003904

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:lsp-plugins has been trying to migrate for 
62 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


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.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=lsp-plugins



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006569: autodep8: generated dkms autopkg test should be superficial

[Paul Gevers]

Hi Andreas,

On 27-02-2022 22:25, Andreas Beckmann wrote:

the dkms autopkgtest generated by autodep8 misses the "superficial"
restriction. Failing to build the kernel module is a good indicator for
something being broken, but being able to build a kernel module does not
say anything about its usability.


I recalled having discussed this already, and sure, I found a bug where 
it was mentioned. The bug was filed by a certain Andreas Beckmann ;) bug 
#959976.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

[Elena ``of Valhalla'']

On 2022-02-28 at 10:20:10 -0500, nick black wrote:
> lmodern needed be listed as a regular Depends, not just a
> Build-Depends, in order for the autopkgtests to successfully
> run. I have added it, and verified that this fixes the
> autopkgtests on the testing distribution.

Thanks for working on it!

However, I don't think that adding lmodern to the package Depends is the
right solution, as that would lead to parts of tex (admittely, a small
part, but still) having to be installed on the system, which is not
required by pandoc itself.

The right solution, I believe, is to add lmodern to the tests/control
Depends, and I've just realized that I prepared that in git, but I never
actually did the upload (ups), and was wondering why it wasn't
working.

I will do the upload myself in the next few days, since I have an
up-to-date copy of the repo locally (and salsa is down).

sorry.

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#1006622: network-manager: Upgrade from 1.34.0-2 to any higher version breaks IPv6 config on mobile broadband

[Bjoern Buerger]

Package: network-manager
Version: 1.36.0-2
Severity: important
Tags: ipv6

Dear Maintainer,


after upgrading network-manager from version 1.34.0-2 to 1.35.91-1 or higher,
NetworkManager fails to set the IPv6 addresses, received via mobile boradband
connection.

* Downgrading to 1.34.0-2 immediately fixes the problem.
* All later Versions, starting with 1.35.91-1 are affected
* contents of journal:

  schnipp ---

[...] device (cdc-wdm1): Activation: starting connection 'T-Mobile IPv6 only' 
(...)
[...] audit: op="connection-activate" uuid="..." name="T-Mobile IPv6 only" 
pid=1635 uid=1000 result="success"
[...] device (cdc-wdm1): state change: disconnected -> prepare (reason 'none', 
sys-iface-state: 'managed')
[...] manager: NetworkManager state is now CONNECTING
[...] device (cdc-wdm1): state change: prepare -> config (reason 'none', 
sys-iface-state: 'managed')
[...] device (cdc-wdm1): state change: config -> ip-config (reason 'none', 
sys-iface-state: 'managed')
[...] device (cdc-wdm1): retrieving IP configuration failed: modem IP method 
unsupported
[...] modem-broadband[cdc-wdm1]: IPv6 base configuration:
[...] modem-broadband[cdc-wdm1]:   address 
2a01:598:99b8:8a19:3964:a9a3:911d:89a3/64 lft forever pref forever lifetime 
113-0[0,0] src unknown (slaac disabled)
[...] modem-broadband[cdc-wdm1]:   gateway 2a01:598:99b8:8a19:d85c:74aa:b2a2:5c8
[...] modem-broadband[cdc-wdm1]:   DNS 2a01:598:7ff:0:10:74:210:221
[...] modem-broadband[cdc-wdm1]:   DNS 2a01:598:7ff:0:10:74:210:222
[...] platform-linux: do-add-ip6-address[4: 
2a01:598:99b8:8a19:3964:a9a3:911d:89a3]: failure 13 (Keine Berechtigung)

 ^^

 ||

[...] device (cdc-wdm1): state change: ip-config -> ip-check (reason 'none', 
sys-iface-state: 'managed')
[...] device (cdc-wdm1): state change: ip-check -> secondaries (reason 'none', 
sys-iface-state: 'managed')
[...] device (cdc-wdm1): state change: secondaries -> activated (reason 'none', 
sys-iface-state: 'managed')
[...] manager: NetworkManager state is now CONNECTED_LOCAL
[...] manager: NetworkManager state is now CONNECTED_SITE
[...] policy: set 'T-Mobile IPv6 only' (wwan0) as default for IPv6 routing and 
DNS
[...] device (cdc-wdm1): Activation: successful, device activated.
[...] manager: NetworkManager state is now CONNECTED_GLOBAL

 schnapp 

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

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

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-4
ii  libaudit11:3.0.7-1
ii  libbluetooth35.62-2
ii  libc62.33-7
ii  libcurl3-gnutls  7.81.0-1
ii  libglib2.0-0 2.70.4-1
ii  libgnutls30  3.7.3-4+b1
ii  libjansson4  2.13.1-1.1
ii  libmm-glib0  1.18.6-2
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-5+b1
ii  libnm0   1.36.0-2
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1.2-1
ii  libselinux1  3.3-1+b1
ii  libsystemd0  250.3-2
ii  libteamdctl0 1.31-1
ii  libudev1 250.3-2
ii  policykit-1  0.105-32
ii  udev 250.3-2

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.86-1.1
ii  libpam-systemd   250.3-2
ii  modemmanager 1.18.4-1
ii  ppp  2.4.9-1+1
ii  wireless-regdb   2021.08.28-1
ii  wpasupplicant2:2.10-2

Versions of packages network-manager suggests:
ii  iptables   1.8.7-1
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.2-P1-1

-- no debconf information

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: boofcv
  Version : 0.40.1
  Upstream Author : Peter Abeles 
* URL or Web page : http://boofcv.org
* License : Apache-2.0
  Description : Real-time computer vision library

This is for the BoofCV library for computer vision.

Andrius: you packaged some of the dependencies of BoofCV, and you
mentioned that you were interested in getting BoofCV itself into Debian.
Are you still interested in doing that? If you already looked into it,
can you share any specific challenges that you hit when trying to
package this library? I spoke to the upstream dev (Peter Abeles, Cc-ed),
and he's potentially interested in helping with this effort. The 3 of us
should be able to get this done.

Thanks

Bug#1006620: src:httpie: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: httpie
Version: 2.4.0-1
Severity: serious
Control: close -1 2.6.0-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:httpie has been trying to migrate for 62 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


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.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=httpie



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005899: mplayer: should not release with bookworm

[Reimar Döffinger]

> On 28 Feb 2022, at 19:12, Ian Jackson  wrote:
> It seems to me that at #1004579 (ffmpeg 5.0) and #939032 (giflib)
> would need to be addressed,

These are definitely fixed in 1.5, and the fix for giflib should be not hard to 
cherry-pick for 1.4 if there is a need.

> and #958865 (crash on theora) really ought
> to be fixed too.

I could never reproduce it, but it could be I never tested 1.4 Debian build. 
But chances are this is fixed by 1.5 at least.

>  If we had a maintainer who is able to deal with
> those, and also deal with some of the outstanding bug gardening, then
> we could conclude that mplayer ought to stay.

I am completely unfamiliar with the Debian processes and doubt I have time to 
learn (and interacting with the bug tracker seems supremely painful and 
confusing to me).
So I also don't know what exactly is needed.
But if it's just about debugging/fixing bugs or finding patches to cherry-pick 
I am here, and as said the lists are also there, as is MPlayer's trac bug 
tracker (though not that actively monitored, so would need to ping me for a 
fast response).

Best regards,
Reimar

Bug#1006619: O: libcec -- USB CEC Adaptor communication Library

[Bálint Réczey]

Package: wnpp
Severity: normal

Orphaning the package.

Thanks,
Balint

Bug#1006594: RFS: vfu/4.23-1~bpo11+1 -- Versatile text-based file-manager

[Bastian Germann]

Control: tags -1 moreinfo

On Mon, 28 Feb 2022 03:44:38 +0200 Boian Bonev wrote:

Changes since the last upload:

 vfu (4.23-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.


First off: Please only send backport sponsorship requests for packages that formally qualify for backporting. This 
version has not arrived in bookworm yet, so does not qualify.


What justifies having this backport? What features does 4.23 provide over 4.21?

When the package has migrated and you gave a reason, please untag moreinfo.

Bug#1006537: dask: autopkgtest failure on 32 bit, mismatch in size of data structure.

[Diane Trout]

On Sun, 2022-02-27 at 08:34 +, Peter Michael Green wrote:
> Package: dask
>  Version: 2022.01.0+dfsg-1
>  Severity: serious
>  
>  The autopkgtest for dask is once-again failing on 32-bit
> architectures,
>  this is blocking the fix for
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005962
>  from migrating to testing.
>  

Drat!

I'd thought I'd found an upstream fix for that.

And right now there's some problem where a dask dependency isn't
installable in 32-bit as it depends on something still in NEW. 


The following packages have unmet dependencies:
 python3-fonttools : Depends: python3-unicodedata2 (>= 14.0.0) but it
is not installable or
  python3-all (>= 3.11.0) but 3.9.8-1 is to
be installed
E: Unable to correct problems, you have held broken packages.


So debugging it is a bit challenging at the moment.

Diane

Bug#1000980: kubernetes: Please upgrade to golang-1.17

[Nilesh Patra]

On Tue, 8 Feb 2022 18:02:54 + Janos LENART  wrote:
> I'll get on this. Thanks.

Janos, Any updates on this?
There is a patch as well in this email[1]

Can you please apply and upload?

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

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1005899: mplayer: should not release with bookworm

[Sebastian Ramacher]

On 2022-02-28 18:12:27, Ian Jackson wrote:
> This bug came to my attention as a user of mplayer, due to the testing
> autoremoval which is the consequence of an RC bug.
> 
> I tried Sebastian Ramacher's suggested alternative of `mpv` and,
> speaking entirely personally, it would do OK for me as a replacement
> for mplayer.  It seems to have many of the same advantages over other
> programs (eg vlc), for me.
> 
> But:
> 
> I have to say that I found the original report in this bug rather
> unfriendly in tone.  Removing things is usually regrettable - at the
> very least, there will usually be people who are going to be upset.
> And an RC bug like this has very high visibility and will draw the
> attention of people without much of the context.

As I am effectively its last maintainer, the original bug report
describes mplayers state in Debian: it is not maintained. And it hasn't
been since 2018 (or even 2016 which saw the last maintainer upload).

> A message which was kinder about mplayer, and which more positively
> spoke of the advantages of mpv, would have avoided darkening my day
> today.
> 
> 
> I had a look at the bug list in Debian and it doesn't seem to have
> insuperable problems.  I'm not able to commit substantial amounts of
> time but I wouldn't want this package to fall out of Debian just
> because no-one with the appropriate permissions is available to
> support people who want to do the actual maintenance.  So I hereby
> volunteer to sponsor uploads.
> 
> It seems to me that at #1004579 (ffmpeg 5.0) and #939032 (giflib)
> would need to be addressed, and #958865 (crash on theora) really ought
> to be fixed too.  If we had a maintainer who is able to deal with
> those, and also deal with some of the outstanding bug gardening, then
> we could conclude that mplayer ought to stay.

Please feel free to take over.

Cheers
-- 
Sebastian Ramacher

Bug#1006618: lcd4linux new homepage

[Geert Stappers]

Package: lcd4linux


Hi,

Currently is lcd4linux
homepage https://ssl.bulix.org/projects/lcd4linux/
unvailable.

What would / should be the new homepage
for debian/control/Homepage: ?


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1006590: os-prober: Fail to install in BSD port: depends on mount not installable

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Lorenzo Puliti, le dim. 27 févr. 2022 19:30:57 -0600, a ecrit:
> Could you please add in the control file freebsd-utils as an alternative
> to mount ?

I have commited it to my git tree, will push when alsa comes back.

Samuel

Bug#1006617: gcl: emacs dependency should be "emacs | emacsen"

[Adrian Bunk]

Package: gcl
Version: 2.6.12-102
Severity: important

Depends: ..., emacs24 | emacsen, ...

The emacs24 package was last in unstable, since GNU Emacs
is now in the package "emacs" without version in it name
please change this to
  emacs | emacsen

Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Hi Rob!

The attached patch seems to work correctly. I had to escape the whole statements
so that they are not interpreted by automake.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- guile-3.0-3.0.8.orig/bootstrap/Makefile.am
+++ guile-3.0-3.0.8/bootstrap/Makefile.am
@@ -22,7 +22,11 @@
 
 
 GUILE_WARNINGS = -W0
-GUILE_OPTIMIZATIONS = -O1
+$(ifeq($SCM_PREBUILT_BINARIES,"32-bit-little-endian") \
+	GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives -Ocps \
+else \
+	GUILE_OPTIMIZATIONS = -O1 \
+endif)
 
 include $(top_srcdir)/am/bootstrap.am
 
--- guile-3.0-3.0.8.orig/stage0/Makefile.am
+++ guile-3.0-3.0.8/stage0/Makefile.am
@@ -22,7 +22,12 @@
 
 
 GUILE_WARNINGS = -W0
-GUILE_OPTIMIZATIONS = -O1
+$(ifeq($SCM_PREBUILT_BINARIES,"32-bit-little-endian") \
+	GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives -Ocps \
+else \
+	GUILE_OPTIMIZATIONS = -O1 \
+endif)
+
 GUILE_BOOTSTRAP_STAGE = stage0
 
 include $(top_srcdir)/am/bootstrap.am

Bug#1006616: firefox: new upstream version

[Christoph Anton Mitterer]

Package: firefox
Version: 96.0.3-1
Severity: wishlist


Hey.

Numerous security holes have been fixed in FF 97... would it be possible to get 
that
packaged for unstable/testing?

Thanks,
Chris.

Bug#1005899: mplayer: should not release with bookworm

[Ian Jackson]

This bug came to my attention as a user of mplayer, due to the testing
autoremoval which is the consequence of an RC bug.

I tried Sebastian Ramacher's suggested alternative of `mpv` and,
speaking entirely personally, it would do OK for me as a replacement
for mplayer.  It seems to have many of the same advantages over other
programs (eg vlc), for me.

But:

I have to say that I found the original report in this bug rather
unfriendly in tone.  Removing things is usually regrettable - at the
very least, there will usually be people who are going to be upset.
And an RC bug like this has very high visibility and will draw the
attention of people without much of the context.

A message which was kinder about mplayer, and which more positively
spoke of the advantages of mpv, would have avoided darkening my day
today.


I had a look at the bug list in Debian and it doesn't seem to have
insuperable problems.  I'm not able to commit substantial amounts of
time but I wouldn't want this package to fall out of Debian just
because no-one with the appropriate permissions is available to
support people who want to do the actual maintenance.  So I hereby
volunteer to sponsor uploads.

It seems to me that at #1004579 (ffmpeg 5.0) and #939032 (giflib)
would need to be addressed, and #958865 (crash on theora) really ought
to be fixed too.  If we had a maintainer who is able to deal with
those, and also deal with some of the outstanding bug gardening, then
we could conclude that mplayer ought to stay.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1005870: [Resolved] Unable to activate singularity container from within boot service script

[Nilesh Patra]

control: fixed -1 3.9.5+ds1-3
control: close -1

As confirmed by the bug reporter, this bug is
fixed, hence closing

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1005870: Unable to activate singularity container from within boot service script

[Fox, Ron]

Thanks for your work.  I’m able to activate containers from within  a script 
run at boot time.  The update did the trick.


Ron.


Ron Fox
Senior Scientist
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824, USA
Tel. 517-908-7349
Email: f...@frib.msu.edu

[cid:image001.jpg@01D823DD.5CA436C0]



From: Nilesh Patra
Sent: Sunday, February 27, 2022 1:54 AM
To: Fox, Ron
Cc: 1005...@bugs.debian.org
Subject: Re: Unable to activate singularity container from within boot service 
script

[EXTERNAL] This email originated from outside of FRIB

On Wed, Feb 23, 2022 at 11:50:30PM +, Fox, Ron wrote:
> Thank you we'll give it a try as soon as it migrates out to our internal 
> mirrors.

Ron,
Any update on this - if it is there on your internal servers by now?

Regards,
Nilesh

Bug#1006615: python3-pybind11: Handle Python 3.10's default sysconfig paths

[Stefano Rivera]

Package: python3-pybind11
Version: 2.9.1-1
Severity: normal
Tags: patch
Forwarded: https://github.com/pybind/pybind11/pull/3764

Until recently, the Python sysconfig module didn't know about Debian's
deb_system and posix_local schemes that were patched into
distutils.sysconfig. This changed in 3.10.2-3, to allow the deprecation
of distutils, upstream.

See https://bugs.launchpad.net/ubuntu/+source/python3.10/+bug/1960608
for some of the back-story here.

The effective change here is that with Python 3.10 as default, packages
using pybind11 are FTBFS because they can't find Python.h. e.g.
https://launchpad.net/ubuntu/+source/avogadrolibs/1.95.1-8

> CMake Error in python/CMakeLists.txt:
>   Imported target "pybind11::module" includes non-existent path
> 
> "/usr/local/include/python3.10"
> 
>   in its INTERFACE_INCLUDE_DIRECTORIES.

I'm pointing to Ubuntu bugs here, because we're hitting these issues in
Ubuntu first, where Python 3.10 is the default Python 3. Debian hasn't
got there, yet.

The solutions here are two-fold:
1. Migrate from distutils.sysconfig to sysconfig. This needs to happen,
   upstream, before distutils is gone from stdlib.
2. Explicitly select the correct system scheme when looking for
   Python3's headers, rather than the default install-to-/usr/local
   scheme.

Attached are a pair of patches to address the issue. I've forwarded them
upstream in https://github.com/pybind/pybind11/pull/3764

SR
From 5262ff794498b45c12f23f64e9adef30d51e667f Mon Sep 17 00:00:00 2001
From: Stefano Rivera 
Date: Mon, 28 Feb 2022 12:49:51 -0400
Subject: [PATCH 1/2] Use sysconfig in Python >= 3.10

Rely on sysconfig for installation paths for Python >= 3.10. distutils
has been deprecated and will be removed.

Fixes: #3677
---
 tools/FindPythonLibsNew.cmake | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/FindPythonLibsNew.cmake b/tools/FindPythonLibsNew.cmake
index 7aeffa44..31eeffa0 100644
--- a/tools/FindPythonLibsNew.cmake
+++ b/tools/FindPythonLibsNew.cmake
@@ -112,11 +112,20 @@ endif()
 # VERSION. VERSION will typically be like "2.7" on unix, and "27" on windows.
 execute_process(
   COMMAND
-"${PYTHON_EXECUTABLE}" "-c" "from distutils import sysconfig as s;import sys;import struct;
+"${PYTHON_EXECUTABLE}" "-c" "
+import sys;import struct;
+import sysconfig as s
+USE_SYSCONFIG = sys.version_info >= (3, 10)
+if not USE_SYSCONFIG:
+from distutils import sysconfig as ds
 print('.'.join(str(v) for v in sys.version_info));
 print(sys.prefix);
-print(s.get_python_inc(plat_specific=True));
-print(s.get_python_lib(plat_specific=True));
+if USE_SYSCONFIG:
+print(s.get_path('platinclude'))
+print(s.get_path('platlib'))
+else:
+print(ds.get_python_inc(plat_specific=True));
+print(ds.get_python_lib(plat_specific=True));
 print(s.get_config_var('EXT_SUFFIX') or s.get_config_var('SO'));
 print(hasattr(sys, 'gettotalrefcount')+0);
 print(struct.calcsize('@P'));
-- 
2.34.1

From 697e8e1fca67bb48e477a61a9bbfa049c653ecd2 Mon Sep 17 00:00:00 2001
From: Stefano Rivera 
Date: Mon, 28 Feb 2022 13:11:45 -0400
Subject: [PATCH 2/2] Explicitly select the posix_prefix scheme for platinclude
 on Debian

Debian's default scheme is posix_local, for installing locally-built
packages to /usr/local/.  We want to find the Python headers in /usr/,
so search posix_prefix.
---
 tools/FindPythonLibsNew.cmake | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/FindPythonLibsNew.cmake b/tools/FindPythonLibsNew.cmake
index 31eeffa0..6ad5fe15 100644
--- a/tools/FindPythonLibsNew.cmake
+++ b/tools/FindPythonLibsNew.cmake
@@ -121,7 +121,11 @@ if not USE_SYSCONFIG:
 print('.'.join(str(v) for v in sys.version_info));
 print(sys.prefix);
 if USE_SYSCONFIG:
-print(s.get_path('platinclude'))
+scheme = s.get_default_scheme()
+if scheme == 'posix_local':
+# Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+scheme = 'posix_prefix'
+print(s.get_path('platinclude', scheme))
 print(s.get_path('platlib'))
 else:
 print(ds.get_python_inc(plat_specific=True));
-- 
2.34.1

Bug#1006614: libccid: support for Solo2 and Nitrokey 3

[Dave Love]

Package: libccid
Version: 1.4.34-1~solo2+1
Severity: wishlist
X-Debbugs-Cc: none, Dave Love 

Various functions of the new free software/hardware Solo 2 security key
don't work in Debian 11 because libccid doesn't support it.  The same
probably goes for the Nitrokey 3 when it's available as it shares basic
firmware.  It seems worth supporting them since they're free devices,
either by backporting from unstable or patching the version in stable.
I don't know which is the best solution (or whether patching for extra
support is within policy), but I've tried both with success.

I built 1.5 from unstable on buster and bullseye (lowering the debhelper
version so it would also work on 10, and also Ubuntu 18.04 and 20.04).
Installing it solves at least that part of problems with the solo2 cli.
Then I tried the version from bullseye plus the /etc/libccid_Info.plist
from 1.5, which works; I'll probably post it for Solo 2 users.  As that
worked I rebuilt the bullseye version with a patch for
readers/supported_readers.txt to add Solo2 and Nitrokey entries, though
I guess it could have all the additions from the 1.5 version.  The
results are under .
Obviously I can send a patch if that's helpful.

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libccid depends on:
ii  libc6 2.31-13+deb11u2
ii  libusb-1.0-0  2:1.0.24-3

libccid recommends no packages.

Versions of packages libccid suggests:
pn  pcmciautils  

-- no debconf information

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 5:44 PM Santiago R.R.  wrote:
>
> El 28/02/22 a las 16:26, Martin-Éric Racine escribió:
> > > * You are moving stuff to /usr. Do you have any reason for making this
> > >   change in this NMU?
> > >   While I think it is a good thing, this is not documented in
> > >   d/changelog, and I think an NMU should focus on the reason for doing it
> > >   (the newest upstream release in this case).
> > >   From the developers reference (5.11.1.): "...Fixing cosmetic issues or
> > >   changing the packaging style in NMUs is discouraged."
> >
> > I try to keep the delta with upstream defaults as small as possible.
> > Upstream uses /usr.  The only thing that doesn't work as expected is
> > that upstream's configure script fails at putting the prefix for
> > manual pages.
> >
> > As a side-issue, Lintian incorrectly reports the upstream default for
> > its lease database (/var/db) as non-standard. See Bug#1006482. Because
> > of this, I've kept the directory unchanged for now.
>
> Sorry, just to be sure of understanding, are you reverting the move to
> /usr? If yes, please tell me when you have a new version to review.
> Otherwise, please document it in d/changelog.

Read again. Prefix is currently to upstream default at /usr. The DHCP
lease database would be in /var/db/dhcpcd, but Lintian considers
/var/db as non-standard even though it is FHS. Bug filed against
Lintian accordingly and the lease database remains in /var/lib until
Lintian has been fixed.

> > > * Could you please fix the indentation of the your new entry in 
> > > d/copyright?
> >
> > IMHO, the whole file's indentation needs to be fixed. I had troubles
> > aligning my addition, because the file currently uses TAB+2SPACES.
> > There really should be a linting tool for that.
>
> Idem.

Either I run wrap-and-sort on the source tree, or I make no attempt to
fix the formatting of d/copyright.

Martin-Éric

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R.  wrote:
>
> El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> > >  wrote:
> > > >
> > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  
> > > > wrote:
> > > > > * Could you please fix the indentation of the your new entry in 
> > > > > d/copyright?
> > > >
> > > > IMHO, the whole file's indentation needs to be fixed. I had troubles
> > > > aligning my addition, because the file currently uses TAB+2SPACES.
> > > > There really should be a linting tool for that.
> > >
> > > Actually, it seems that wrap-and-sort can be used for d/copyright too.
> > > I somehow was under the impression that it's only used for d/control.
> > > I'm extremely tempted to run it on the whole package.
> >
> > Reading back on Bug #964947, I notice that the request was for both
> > packaging current upstream and dropping the 5 out of the package name.
> > I would tend to agree. The 5 really only was meant as an upstream
> > branch tag.  The source and binary really should be called 'dhcpcd'
> > since it essentially is a fork of the abandoned source of the same
> > name.
>
> Changing the source name means creating (or reintroducing) a different
> debian package. Just in case:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218
>
> Changing the binary name only means it would have to pass by NEW…

Merely changing the binary name sounds perfectly reasonable to me.

Martin-Éric

Bug#1005228: linux-image-4.19.0-18-amd64: Short freeze on virtual machine with message: "rcu: INFO: rcu_sched self-detected stall on CPU"

[Ben Hutchings]

On Mon, 2022-02-28 at 15:03 +, Adrien TREMOT wrote:
> Hi,
> 
> It seems the issue was linked to the 8139cp NIC driver.
> I changed the NIC driver to virtio and the stall did not occure anymore.
> Let me know if you need more informations about this or if I should signal 
> the issue somewhere else.

My memory is that the 8139cp emulation in QEMU has very poor
performance (the physical device was only designed for 100 Mbit/s
Ethernet anyway) and is not suitable for use in production.

If virtio_net is working for you then I don't think this bug is worth
investigating.

But if you would like to investigate this, you could try applying the
attached patch and switching back to 8139cp temporarily.  Instructions
for rebuilding a kernel package can be found in the debian-kernel-
handbook package at
file:///usr/share/doc/debian-kernel-handbook/kernel-handbook.html/ch-common-tasks.html#s-common-official
(This is normally also available online but that server is currently
down.)

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
From 139819f9b8009144f15a6659ce767023a0583ef8 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Mon, 28 Feb 2022 17:44:27 +0100
Subject: [PATCH] 8139cp: Count Rx failures towards polling budget

In cp_rx_poll() the loop condition is 'while (rx < budget)', but in
error cases it moves on to the next descriptor without incrementing
rx.  This is not correct and can lead to a soft lockup.

Reported-by: Adrien TREMOT 
Fixes: bea3348eef27 ("[NET]: Make NAPI polling independent of struct ...")
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/realtek/8139cp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index ad7b9e9d7f95..063a4dc338cc 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -535,7 +535,6 @@ static int cp_rx_poll(struct napi_struct *napi, int budget)
 		cp->rx_skb[rx_tail] = new_skb;
 
 		cp_rx_skb(cp, skb, desc);
-		rx++;
 		mapping = new_mapping;
 
 rx_next:
@@ -547,6 +546,8 @@ static int cp_rx_poll(struct napi_struct *napi, int budget)
 		else
 			desc->opts1 = cpu_to_le32(DescOwn | cp->rx_buf_sz);
 		rx_tail = NEXT_RX(rx_tail);
+
+		rx++;
 	}
 
 	cp->rx_tail = rx_tail;


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

Bug#1006613: ITP: gsad -- Greenbone Security Assistant HTTP server

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 
X-Debbugs-Cc: debian-de...@lists.debian.org, sop...@offensive-security.com

* Package name: gsad
  Version : 21.4.4
  Upstream Author : Greenbone Networks GmbH
* URL : https://github.com/greenbone/gsad
* License : AGPL-3+
  Programming Lang: C
  Description : Greenbone Security Assistant HTTP server

The Greenbone Security Assistant HTTP Server is the server developed for
the communication with the Greenbone Security Manager appliances.
It connects to the Greenbone Vulnerability Manager Daemon gvmd to provide
a full-featured HTTP interface for vulnerability management.

This package is part of gvm tools. The code was in the
greenbone-security-assistant source package but upstream split the code
in two different repos: gsa (greenbone-security-assistant) and gsad.

I plan to maintain this package within the pkg-security-team.

Bug#1006612: live-build: netboot IPv6 only and NFSv4 → dracut

[Andreas B. Mundt]

Package: live-build
Version: 1:20210902
Severity: wishlist
X-Debbugs-Cc: a...@debian.org

Hi,

we are using live-build to provide diskless (fat) client images in our
network.  Clients are IPv6 PXE booted and load Grub (bootnetx64.efi)
which in turn loads the kernel and initrd.  The rootfs is then mounted
from an NFS share.  This works fine so far, however, there are two
shortcomings, related to the initrd and klibc:

 • it is not possible (without tweaks) to use NFSv4 (#409272, #409271)
 • it is not possible to download/mount the rootfs using IPv6 (#627164)

A hack which seems to work for my setup is using dracut to build the
initrd.  To switch, use this draft patch applied to
'/usr/lib/live/build/chroot_hacks':  

/usr/lib/live/build$ diff -u chroot_hacks.orig chroot_hacks
--- chroot_hacks.orig   2022-01-16 21:04:27.445797506 +0100
+++ chroot_hacks2022-02-28 12:40:52.147919670 +0100
@@ -66,7 +66,10 @@
 
 if [ "${LB_INITRAMFS}" != "none" ]
 then
-   Chroot chroot "${UPDATE_INITRAMFS_OPTIONS} update-initramfs -k all -t 
-u"
+   #Chroot chroot "${UPDATE_INITRAMFS_OPTIONS} update-initramfs -k all -t 
-u"
+   VER="$(find chroot/boot -maxdepth 1 -name 'vmlinuz-*' | sed 
's#.*/vmlinuz-##')"
+# Modules c.f. 'man dracut'
+   Chroot chroot "dracut --no-hostonly --force -m base -m livenet -m 
network -m nfs --kver $VER"
 fi

For the record, here are the grub menu entries I used for testing
(dracut seems to provide quite good support for live systems):

  menuentry "Debian GNU/Linux Live Dracut RAM" {
linux  /d-i/n-live/vmlinuz boot=live components ip=dhcp6 
root=live:http://[fd39:4487:170a::994]/d-i/n-live/filesystem.squashfs 
initrd /d-i/n-live/initrd.img
  }
  
  menuentry "Debian GNU/Linux Live Dracut RAM fetch-NFS" {
linux  /d-i/n-live/vmlinuz boot=live components ip=dhcp6 
root=live:nfs4:[fd39:4487:170a::994]:/live/filesystem.squashfs rd.live.ram=1
initrd /d-i/n-live/initrd.img
  }
  
  menuentry "Debian GNU/Linux Live Dracut mount-NFS" {
linux  /d-i/n-live/vmlinuz boot=live components ip=dhcp6 
root=live:nfs4:[fd39:4487:170a::994]:/live/filesystem.squashfs
initrd /d-i/n-live/initrd.img
  }

Perhaps this is useful for others who run into the same problems or
live-build development for the future.

Best regards,

  Andi



-- debsums errors found:
debsums: changed file /usr/lib/live/build/chroot_hacks (from live-build package)

Bug#1006611: mirror submission for mirrors.neusoft.edu.cn

[Fulong Sun]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.neusoft.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Fulong Sun 
Country: CN China
Location: Dalian
Sponsor: Dalian Neusoft University of Information (大连东软信息学院) 
http://www.neusoft.edu.cn
Comment: Dalian Neusoft University of Information (大连东软信息学院)




Trace Url: http://mirrors.neusoft.edu.cn/debian/project/trace/
Trace Url: 
http://mirrors.neusoft.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirrors.neusoft.edu.cn/debian/project/trace/mirrors.neusoft.edu.cn

Bug#1006519: openvpn: FTBFS with OpenSSL 3.0

[Bernhard Schmidt]

Control: tags -1 + confirmed upstream

OpenSSL 3.0 compatibility is part of OpenVPN 2.6, which is supposed to 
be released next month. See 
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26 .


If you want to feel free to push this transition ahead, I can either 
live with temporary removal from testing or I will upload a git snapshot.

Bug#1006610: gnucash: Crash with std::bad_alloc when trying to create any report

[Maximilian Stein]

Package: gnucash
Version: 1:4.8-1
Severity: important

Dear Maintainer,

Since recently, Gnucash crashes with an std::bad_alloc exception
whenever I try to open a report. I am unsure whether this bug is
related to #851783.

This is the valgrind output in the moment I try to open a report:


==56964== Warning: set address range perms: large range [0x59c83000, 
0x99c85000) (noaccess)
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
==56964== 
==56964== Process terminating with default action of signal 6 (SIGABRT)
==56964==at 0x5F348A1: raise (raise.c:50)
==56964==by 0x5F1E545: abort (abort.c:79)
==56964==by 0x5D70889: ??? (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D7C059: ??? (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D7C0C4: std::terminate() (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D7C358: __cxa_throw (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0x5D73020: std::__throw_bad_alloc() (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29)
==56964==by 0xE5A00CB: 
WTF::FileSystemImpl::pathByAppendingComponent(WTF::String const&, WTF::String 
const&) (in /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18.19.11)
==56964==by 0x9EA7B5E: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964==by 0x9EA7BEA: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964==by 0x9E9289A: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964==by 0x9E1ABA0: ??? (in 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.55.9)
==56964== 
==56964== HEAP SUMMARY:
==56964== in use at exit: 71,053,921 bytes in 773,876 blocks
==56964==   total heap usage: 7,066,048 allocs, 6,292,172 frees, 941,857,631 
bytes allocated
==56964== 
==56964== LEAK SUMMARY:
==56964==definitely lost: 80,109 bytes in 116 blocks
==56964==indirectly lost: 63,377 bytes in 2,639 blocks
==56964==  possibly lost: 415,818 bytes in 3,965 blocks
==56964==still reachable: 63,512,529 bytes in 734,429 blocks
==56964==   of which reachable via heuristic:
==56964== newarray   : 211,048 bytes in 30 
blocks
==56964== suppressed: 0 bytes in 0 blocks
==56964== Rerun with --leak-check=full to see details of leaked memory
==56964== 
==56964== Use --track-origins=yes to see where uninitialised values come from
==56964== For lists of detected and suppressed errors, rerun with: -s
==56964== ERROR SUMMARY: 20027 errors from 232 contexts (suppressed: 0 from 0)



Is this a known issue? Can I assist somehow in further diagnosis?

Thanks for your help!

Best,
Maximilian

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

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

Versions of packages gnucash depends on:
ii  gnucash-common 1:4.8-1
ii  guile-2.2  2.2.7+1-6+b1
ii  guile-3.0-libs 3.0.7-1+b1
ii  libaqbanking44 6.4.3beta-1
ii  libboost-filesystem1.74.0  1.74.0-14
ii  libboost-locale1.74.0  1.74.0-14
ii  libboost-program-options1.74.0 1.74.0-14
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-14
ii  libc6  2.33-6
ii  libcairo2  1.16.0-5
ii  libcrypt-ssleay-perl   0.73.06-1+b4
ii  libdate-manip-perl 6.86-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.51-1
ii  libgcc-s1  11.2.0-16
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.4-1
ii  libgtk-3-0 3.24.31-1
ii  libgwengui-gtk3-79 5.9.0-1
ii  libgwenhywfar795.9.0-1
ii  libhtml-tableextract-perl  2.15-1.1
ii  libhtml-tree-perl  5.07-2
ii  libicu67   67.1-7
ii  libofx71:0.10.3-1
ii  libpango-1.0-0 

Bug#983349: sane-escl fails with an ENVY 5530 on bullseye

[Brian Potkin]

On Sun 29 Aug 2021 at 10:12:42 +0200, alain wrote:

> hplip seems to be not compatible with debian sid .

Hello Alain,

This is incorrect. You are able to scan with airscan. A limitation in
the ENVY's hardware prevents scanning with hpaio. This is unavoidable
when ipp-usb is active. It is not a bug in libsane1, hplip or ipp-usb.

You should also have been able to scan with escl but were not able to
do so. This would have been a bug in escl at the time you made your
first report.

What we need to know now is whether the bug is still present in version
1.1.1-4 of libsane1 in Debian sid.

Bring your sid OS up to date and do

  simple-scan escl:http://127.0.0.1:6

Check that http://127.0.0.1:6 is correct using 'scanimage -L'.

Cheers,

Brian.

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Santiago R.R.]

El 28/02/22 a las 16:52, Martin-Éric Racine escribió:
> On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
>  wrote:
> >
> > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  
> > > wrote:
> > > > * Could you please fix the indentation of the your new entry in 
> > > > d/copyright?
> > >
> > > IMHO, the whole file's indentation needs to be fixed. I had troubles
> > > aligning my addition, because the file currently uses TAB+2SPACES.
> > > There really should be a linting tool for that.
> >
> > Actually, it seems that wrap-and-sort can be used for d/copyright too.
> > I somehow was under the impression that it's only used for d/control.
> > I'm extremely tempted to run it on the whole package.
> 
> Reading back on Bug #964947, I notice that the request was for both
> packaging current upstream and dropping the 5 out of the package name.
> I would tend to agree. The 5 really only was meant as an upstream
> branch tag.  The source and binary really should be called 'dhcpcd'
> since it essentially is a fork of the abandoned source of the same
> name.

Changing the source name means creating (or reintroducing) a different
debian package. Just in case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218

Changing the binary name only means it would have to pass by NEW…

 -- Santiago


signature.asc
Description: PGP signature

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Santiago R.R.]

El 28/02/22 a las 16:26, Martin-Éric Racine escribió:
> On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  wrote:
> >
> > (Removing some people from CC to avoid polluting their mailboxes)
> >
> > El 25/02/22 a las 11:25, Martin-Éric Racine escribió:
> > > On Fri, Feb 25, 2022 at 10:31 AM Roy Marples  wrote:
> > > >
> > > > On 24/02/2022 21:31, Santiago R.R. wrote:
> > > >  >
> > > >  > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> > > >  wrote:
> > > >  >>
> > > >  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> > > >  wrote:
> > > >  >>> Package: dhcpcd5
> > > >  >>> Followup-For: Bug #964947
> > > >  >>> X-Debbugs-Cc:
> > > > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> > > >  >>>
> > > > > I have an NMU waiting on Mentors.
> > > > >
> > > > > 
> > > > >
> > > > >> Thanks for your work! I do not have too much free cycles, but I will 
> > > > >> do my best to review and upload it soon.
> > ...
> >
> > I forgot to say I hope Scott is doing well. I hope his lack of activity
> > is just a lack of available time.
> 
> The last upload was made in May 2019 i.e. oldstable.
> 
> Bug #964947 requesting the packaging of current version was filed in
> July 2020. That's nearly 2 years ago. It remains unanswered by Scott
> despite recent activity on the bug. My packaging therefore assumes
> that Scott is MIA and focuses on bringing the package closer to what's
> expected for contemporary usage.
> 
> > * You are moving stuff to /usr. Do you have any reason for making this
> >   change in this NMU?
> >   While I think it is a good thing, this is not documented in
> >   d/changelog, and I think an NMU should focus on the reason for doing it
> >   (the newest upstream release in this case).
> >   From the developers reference (5.11.1.): "...Fixing cosmetic issues or
> >   changing the packaging style in NMUs is discouraged."
> 
> I try to keep the delta with upstream defaults as small as possible.
> Upstream uses /usr.  The only thing that doesn't work as expected is
> that upstream's configure script fails at putting the prefix for
> manual pages.
> 
> As a side-issue, Lintian incorrectly reports the upstream default for
> its lease database (/var/db) as non-standard. See Bug#1006482. Because
> of this, I've kept the directory unchanged for now.

Sorry, just to be sure of understanding, are you reverting the move to
/usr? If yes, please tell me when you have a new version to review.
Otherwise, please document it in d/changelog.

> 
> If Debian followed FHS by the book, we would probably want the DHCP
> client to sit in /sbin since it's needed to bring up the network and
> /usr may be mounted later during bootup. Since Debian doesn't mount
> /usr separately, using upstream defaults works as-is.
> 
> >   This also concerns the minor bump version number in d/watch.
> 
> It was a low-hanging fruit and verified to work.

Yes, I can acknowledge that. But again, I have some doubts that's the
changes that should be expected in an NMU.

> 
> > * Could you please fix the indentation of the your new entry in d/copyright?
> 
> IMHO, the whole file's indentation needs to be fixed. I had troubles
> aligning my addition, because the file currently uses TAB+2SPACES.
> There really should be a linting tool for that.

Idem.

> 
> > * Part of the changes you are including had already been done in the VCS
> >   by Scott. There is no rule about this, but *I* would give credit to
> >   him. Maybe I would have cherry-picked the relevant changes needed for
> >   packaging this new upstream release, and use `gdp dch`. This is up to
> >   you.
> 
> I have not checked what's in VCS since no upload has taken place since
> 2019 and no reaction to bugs has take place since then either.
> 
> > * Could you please tell me how have you tested it?
> 
> For the past week, it's been the DHCP client on an host that matches
> upstream assumptions:  hotpluggable Ethernet or USB WiFi dongles. The
> host in question has Ethernet, and I've randomly used a variety of USB
> dongles to test WiFi support. Configuring wpa_supplicant manually
> via/etc/wpa_supplicant/wpa_supplicant.conf rather than passing the
> SSID and PSK key via /etc/network/interfaces required a lot of
> googling but works as expected. This initially didn't work as
> expected, because the package was not compiled with libudev and
> upstream's BUILDING.md makes no mention of what libraries may be used
> to enable some features. That's how I ended up adding the Build-Dep.

Great, thank you!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1

[nick black]

Control: tags 1005778 + patch
Control: tags 1005778 + pending

Dear maintainer,

I've prepared an NMU for pypandoc (versioned as 1.7.2+ds0-1.1) and
it will be uploaded by my Account Manager, Sebastian Ramacher.
Please feel free to tell me if he should delay it.

lmodern needed be listed as a regular Depends, not just a
Build-Depends, in order for the autopkgtests to successfully
run. I have added it, and verified that this fixes the
autopkgtests on the testing distribution.

hack on, nick
diff -Nru pypandoc-1.7.2+ds0/debian/changelog pypandoc-1.7.2+ds0/debian/changelog
--- pypandoc-1.7.2+ds0/debian/changelog	2021-12-29 05:19:10.0 -0500
+++ pypandoc-1.7.2+ds0/debian/changelog	2022-02-28 10:12:41.0 -0500
@@ -1,3 +1,11 @@
+pypandoc (1.7.2+ds0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add dependency on lmodern for runtime to fix autopkgtests.
+Closes: #1005778
+
+ -- Nick Black   Mon, 28 Feb 2022 10:12:41 -0500
+
 pypandoc (1.7.2+ds0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru pypandoc-1.7.2+ds0/debian/control pypandoc-1.7.2+ds0/debian/control
--- pypandoc-1.7.2+ds0/debian/control	2021-12-29 05:19:10.0 -0500
+++ pypandoc-1.7.2+ds0/debian/control	2022-02-28 10:10:24.0 -0500
@@ -27,6 +27,7 @@
 Package: python3-pypandoc
 Architecture: all
 Depends:
+ lmodern,
  pandoc,
  ${misc:Depends},
  ${python3:Depends}

Bug#1003188: bullseye-pu: package mmdebstrap/0.7.5-2.2

[Johannes Schauer Marin Rodrigues]

Quoting Adam D. Barratt (2022-02-19 19:07:46)
> On Wed, 2022-01-05 at 20:28 +0100, Johannes Schauer Marin Rodrigues wrote:
> > Currently, when a user happens to have an ASCII armored key in
> > /etc/apt/trusted.gpg.d, running mmdebstrap without any special
> > options
> > will not work. See #1003175 for details.
> > 
> > The problem is fixed in unstable and testing, starting with 0.8.0-1.
> 0001-Do-not-use-gpg-trust-model-always isn't mentioned in the
> changelog. Is it part of the fix for the issue mentioned above, or a
> separate change?

I picked both patches directly from upstream git. The patch you mention fixes a
bug in the other so they are only useful together. I can merge both patches
into one if that's more helpful.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1006608: RM: aroarfw -- ROM; not used / developed / required anymore

[Patrick Matthäi]

Package: ftp.debian.org
Severity: normal

Hello,

I have also talked with upstream about this package,
please remove it from unstable (and testing if possible for you).
popcon is just 2.

Bug#1006469: [Pkg-javascript-devel] Bug#1006469: Bug#1006469: node-puppeteer shouldn't embed devtools-protocol

[Andrius Merkys]

On 2022-02-28 08:58, Andrius Merkys wrote:
> If I get a second opinion that
> node-devtools-protocol is not worthy as a package on its own, I will RM it.

Here I meant second opinion besides mine. So if anyone would say
node-devtools-protocol is not worth staying in Debian on its own, I will
RM it.

Best,
Andrius

Bug#1005228: linux-image-4.19.0-18-amd64: Short freeze on virtual machine with message: "rcu: INFO: rcu_sched self-detected stall on CPU"

[Adrien TREMOT]

Hi,

It seems the issue was linked to the 8139cp NIC driver.
I changed the NIC driver to virtio and the stall did not occure anymore.
Let me know if you need more informations about this or if I should signal the 
issue somewhere else.

Regards,


On Wed, 09 Feb 2022 14:59:10 +0100 root  wrote:
> Package: src:linux
> Version: 4.19.208-1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>Installing and running in production a fresh debian 10 with php/apache2 
> installed.
>This is a virtual machine with 8 virtual CPU / 4 physical CPU / 8 GB Ram, 
> running on
>an OpenNebula cluster. The VM freeze apparantly randomly (from 1 to
>10 times a day), during
>approximatively 1 minute then come back without any manual action or 
> reboot.
>I tried to reinstall the VM and the same issue occurs. This is the
>most active VM of the OpenNebula cluster.
>The other VM of the Cluster from the same vm template does not have the 
> issue.
>The kernel trace is not exactly the same each time, but the behavior
>seems the same. Let me know if I
>need to update each one.
>I did not see any relevant log on the OpenNebula worker (hypervisor), 
> which have these
>packages installed:
> 
>root@one-w-2-th3:~# dpkg -l | grep libvirt
>ii  libvirt-clients  5.0.0-4+deb10u1
>amd64Programs for the libvirt library
>ii  libvirt-daemon   5.0.0-4+deb10u1
>amd64Virtualization daemon
>ii  libvirt-daemon-system5.0.0-4+deb10u1
>amd64Libvirt daemon configuration files
>ii  libvirt0:amd64   5.0.0-4+deb10u1
>amd64library for interfacing with different virtualization
>systems
>root@one-w-2-th3:~# dpkg -l | grep qemu
>ii  ipxe-qemu1.0.0+git-20190125.36a4c85-1
>all  PXE boot firmware - ROM images for qemu
>ii  qemu-block-extra:amd64   1:3.1+dfsg-8+deb10u8
>amd64extra block backend modules for qemu-system and
>qemu-utils
>ii  qemu-kvm 1:3.1+dfsg-8+deb10u8
>amd64QEMU Full virtualization on x86 hardware
>ii  qemu-system-common   1:3.1+dfsg-8+deb10u8
>amd64QEMU full system emulation binaries (common files)
>ii  qemu-system-data 1:3.1+dfsg-8+deb10u8
>all  QEMU full system emulation (data files)
>ii  qemu-system-gui  1:3.1+dfsg-8+deb10u8
>amd64QEMU full system emulation binaries (user interface and
>audio support)
>ii  qemu-system-x86  1:3.1+dfsg-8+deb10u8
>amd64QEMU full system emulation binaries (x86)
>ii  qemu-utils   1:3.1+dfsg-8+deb10u8
>amd64QEMU utilities
>root@one-w-2-th3:~# dpkg -l | grep nebula
>ii  opennebula-common5.12.0.1-1.ce
>all  Common OpenNebula package shared by various components
>(Community Edition)
>ii  opennebula-common-onescape   5.12.0.1-1.ce
>all  Helpers for OpenNebula OneScape project (Community
>Edition)
>ii  opennebula-node  5.12.0.1-1.ce
>all  Services for OpenNebula KVM node (Community Edition)
>root@one-w-2-th3:~# uname -a


---
Adrien Trémot
Admin systèmes réseaux
SI

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine
 wrote:
>
> On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
>  wrote:
> >
> > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  
> > wrote:
> > > * Could you please fix the indentation of the your new entry in 
> > > d/copyright?
> >
> > IMHO, the whole file's indentation needs to be fixed. I had troubles
> > aligning my addition, because the file currently uses TAB+2SPACES.
> > There really should be a linting tool for that.
>
> Actually, it seems that wrap-and-sort can be used for d/copyright too.
> I somehow was under the impression that it's only used for d/control.
> I'm extremely tempted to run it on the whole package.

Reading back on Bug #964947, I notice that the request was for both
packaging current upstream and dropping the 5 out of the package name.
I would tend to agree. The 5 really only was meant as an upstream
branch tag.  The source and binary really should be called 'dhcpcd'
since it essentially is a fork of the abandoned source of the same
name.

Martin-Éric

Bug#552596: libtorrent-rasterbar: please add a -nossl flavour of the package

[Christian Marillat]

Hi,

Do you still think it-s a good idea to have a libtorrent-rasterbar with
-nossl flavour ?

Christian

Bug#1006369: re-installation Buster 10.10

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



there is the follow-up report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006442
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCYhzblgAKCRDn6sEfJS3n
C9CQAJ91gxj3o33yl4/XpLLB7Fsx0TNUTwCfRpyG/qUu3n1D7W2OEee6fs+IsOw=
=ZX4M
-END PGP SIGNATURE-

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine
 wrote:
>
> On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  wrote:
> > * Could you please fix the indentation of the your new entry in d/copyright?
>
> IMHO, the whole file's indentation needs to be fixed. I had troubles
> aligning my addition, because the file currently uses TAB+2SPACES.
> There really should be a linting tool for that.

Actually, it seems that wrap-and-sort can be used for d/copyright too.
I somehow was under the impression that it's only used for d/control.
I'm extremely tempted to run it on the whole package.

Martin-Éric

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Martin-Éric Racine]

On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R.  wrote:
>
> (Removing some people from CC to avoid polluting their mailboxes)
>
> El 25/02/22 a las 11:25, Martin-Éric Racine escribió:
> > On Fri, Feb 25, 2022 at 10:31 AM Roy Marples  wrote:
> > >
> > > On 24/02/2022 21:31, Santiago R.R. wrote:
> > >  >
> > >  > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> > >  wrote:
> > >  >>
> > >  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> > >  wrote:
> > >  >>> Package: dhcpcd5
> > >  >>> Followup-For: Bug #964947
> > >  >>> X-Debbugs-Cc:
> > > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> > >  >>>
> > > > I have an NMU waiting on Mentors.
> > > >
> > > > 
> > > >
> > > >> Thanks for your work! I do not have too much free cycles, but I will 
> > > >> do my best to review and upload it soon.
> ...
>
> I forgot to say I hope Scott is doing well. I hope his lack of activity
> is just a lack of available time.

The last upload was made in May 2019 i.e. oldstable.

Bug #964947 requesting the packaging of current version was filed in
July 2020. That's nearly 2 years ago. It remains unanswered by Scott
despite recent activity on the bug. My packaging therefore assumes
that Scott is MIA and focuses on bringing the package closer to what's
expected for contemporary usage.

> * You are moving stuff to /usr. Do you have any reason for making this
>   change in this NMU?
>   While I think it is a good thing, this is not documented in
>   d/changelog, and I think an NMU should focus on the reason for doing it
>   (the newest upstream release in this case).
>   From the developers reference (5.11.1.): "...Fixing cosmetic issues or
>   changing the packaging style in NMUs is discouraged."

I try to keep the delta with upstream defaults as small as possible.
Upstream uses /usr.  The only thing that doesn't work as expected is
that upstream's configure script fails at putting the prefix for
manual pages.

As a side-issue, Lintian incorrectly reports the upstream default for
its lease database (/var/db) as non-standard. See Bug#1006482. Because
of this, I've kept the directory unchanged for now.

If Debian followed FHS by the book, we would probably want the DHCP
client to sit in /sbin since it's needed to bring up the network and
/usr may be mounted later during bootup. Since Debian doesn't mount
/usr separately, using upstream defaults works as-is.

>   This also concerns the minor bump version number in d/watch.

It was a low-hanging fruit and verified to work.

> * Could you please fix the indentation of the your new entry in d/copyright?

IMHO, the whole file's indentation needs to be fixed. I had troubles
aligning my addition, because the file currently uses TAB+2SPACES.
There really should be a linting tool for that.

> * Part of the changes you are including had already been done in the VCS
>   by Scott. There is no rule about this, but *I* would give credit to
>   him. Maybe I would have cherry-picked the relevant changes needed for
>   packaging this new upstream release, and use `gdp dch`. This is up to
>   you.

I have not checked what's in VCS since no upload has taken place since
2019 and no reaction to bugs has take place since then either.

> * Could you please tell me how have you tested it?

For the past week, it's been the DHCP client on an host that matches
upstream assumptions:  hotpluggable Ethernet or USB WiFi dongles. The
host in question has Ethernet, and I've randomly used a variety of USB
dongles to test WiFi support. Configuring wpa_supplicant manually
via/etc/wpa_supplicant/wpa_supplicant.conf rather than passing the
SSID and PSK key via /etc/network/interfaces required a lot of
googling but works as expected. This initially didn't work as
expected, because the package was not compiled with libudev and
upstream's BUILDING.md makes no mention of what libraries may be used
to enable some features. That's how I ended up adding the Build-Dep.

Martin-Éric

Bug#1006607: Extended the long description

[Neil Williams]

 EPICS is the Experimental Physics and Industrial Control System.
 .
 This package installs the library for Python 3 and a collection
 of EPICS applications, including:
 .
 * AreaDetector Display to view EPICS Area Detector images
 * Step Scan
 * Strip Chart to plot recent history of Process Variables
 * EPICS Instruments to help organise EPICS Process Variables
 * Sample Stage - a GSECARS-specific GUI for moving a set of
   motors for a sample stage, grabbing microscope images and
   saving named positions
 * Motor Setup - to configure EPICS Motors.
 * Ion Chamber - synchrotron-beamline specific application
   to calculate absored and transmitted flux in photons/sec
   and write back to EPICS Process Variables.
 * XRF Collector - interact with a small EPICS database to
   collect data from a multi-element flourescence detector.


-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgpVjMmkzccBm.pgp
Description: OpenPGP digital signature

Bug#1006464: Please use "mdadm monitoring " as default MAILFROM

[Felix Lechner]

Hi,

On Fri, Feb 25, 2022 at 1:06 PM Marvin Renich  wrote:
>
> create a default From address that is useful when root's mail is being
> forwarded off the current system

We just released 4.2-2 in order to address this issue in part.

Hoping to improve the default MAILFROM value for all users we merely added the
host name for now. That value was readily available in upstream's code. The
patch has a better chance of being accepted upstream.

The /etc/mailname mechanism is specific to Debian. A later release of mdadm in
Debian may bring the MAILFROM value into compliance with Debian mail customs.

I tried to test the change but my local mail server replaces all From addresses
with meaningful values. (It was my fix for the reporter's issue.) Please let us
know if this patch does not work as expected.

Salsa is currently down. The patch is instead attached for your review.

Kind regards
Felix Lechner
Description: Add host name to default MAILFROM
 The host on which the error occurred is mentioned in the subject and also in
 the message body, but some may find it useful in the From address, as well.
Author: Felix Lechner 
Bug-Debian: https://bugs.debian.org/1006464
Forwarded: no
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/Monitor.c
+++ b/Monitor.c
@@ -440,8 +440,8 @@ static void alert(char *event, char *dev
 			if (info->mailfrom)
 fprintf(mp, "From: %s\n", info->mailfrom);
 			else
-fprintf(mp, "From: %s monitoring \n",
-	Name);
+fprintf(mp, "From: %s monitoring \n",
+	Name, hname);
 			fprintf(mp, "To: %s\n", info->mailaddr);
 			fprintf(mp, "Subject: %s event on %s:%s\n\n",
 event, dev, hname);

Bug#1006607: ITP: epicsapps -- Collection of applications for EPICS

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 
X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org

* Package name: epicsapps
  Version : 0.9.2
  Upstream Author : Matthew Newville 
* URL : https://github.com/pyepics/epicsapps
* License : EPICS
  Programming Lang: Python
  Description : Collection of applications for EPICS

EPICS is the Experimental Physics and Industrial Control System.
epicsapps provides a collection of apps that use EPICS and
the epicsapps Python3 library.

epicsapps is a dependency for xraylarch and will be maintained with the
Debian PaN maintainers and Debian Science Team.

Bug#1006606: ITP: python-cfg-diag -- common configuration-storage class with a .diag() method

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
r...@debian.org

* Package name: python-cfg-diag
  Version : 0.2.0
  Upstream Author : Peter Pentchev 
* URL : https://github.com/storpool/python-cfg_diag
* License : BSD-2-clause
  Programming Lang: Python
  Description : common configuration-storage class with a .diag() method

 This module provides four classes that may be used as base classes for
 storing program runtime configuration with a `verbose` boolean field.
 The classes provide a `.diag(msg)` method that decides whether to
 output the provided message based on the value of the object's
 `verbose` field.

I intend to maintain this package within the Python packaging team.


signature.asc
Description: PGP signature

Bug#873717: Fixed [with --disable-sigrok] a long time ago....

[Andreas Beckmann]

Control: fixed -1 5.7.2-2

On 28/02/2022 11.13, Bernd Zeimetz wrote:

On 2022-02-28 09:57, Andreas Beckmann wrote:

This was worked around in 5.7.2-2 with --disable-sigrok


That actually fixes a bug called 'ftbfs'. The package will build again.
Its not a workaround, this is the only solution.


If that was your intention, lets close it with that version.
Using a different upstream version made me think you wanted to indicate 
"fixed upstream long ago", but you typoed the fixed version because it 
predated the found version.



Andreas

Bug#1006578: swi-prolog: FTBFS with OpenSSL 3.0

[dogsleg]

Hi Sebastian,

Sebastian Andrzej Siewior писал 2022-02-28 03:41:
> Source: swi-prolog
> Version: 8.2.4+dfsg-1
> Severity: important
> Tags: bookworm sid
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: ftbfs-3.0
> 
> Your package is failing to build using OpenSSL 3.0 with the
> following error:
> 
> | /<>/packages/ssl/crypto4pl.c: In function ‘get_padding’:
> | /<>/packages/ssl/crypto4pl.c:851:69: error:
> ‘RSA_SSLV23_PADDING’ undeclared (first use in this function); did
> you mean ‘RSA_X931_PADDING’?
> |   851 | else if ( a == ATOM_sslv23  && mode == RSA_MODE )   
> *padding = RSA_SSLV23_PADDING;
> |   | 
>^~
> |   | 
>RSA_X931_PADDING
> | /<>/packages/ssl/crypto4pl.c:851:69: note: each
> undeclared identifier is reported only once for each function it
> appears in

This is version of swi-prolog from testing, newer version in unstable,
8.4.2+dfsg-2, should compile clean against OpenSSL 3.0. Sorry, at the
moment
I cannot test it by myself. Could you re-run your build test for the
version in unstable?

With regards,
Lev

Bug#1006605: xserver-xorg-video-radeon: on login; any desktop which has screen orientation saved as portrait logs out

[Chris Guiver]

Package: xserver-xorg-video-radeon
Version: 1:19.1.0-2+b1
Severity: important
X-Debbugs-Cc: guiv...@ubuntu.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Updates that led to this issue are

Start-Date: 2022-02-24  22:36:20
Commandline: apt full-upgrade
Requested-By: guiverc (1000)
Install: xcvt:amd64 (0.1.1-3, automatic)
Upgrade: xserver-xorg-video-nouveau:amd64 (1:1.0.17-1, 1:1.0.17-2), xserver-
xorg-video-amdgpu:amd/rad64 (21.0.0-2, 21.0.0-2+b1), xserver-xorg-core:amd64
(2:1.20.14-1, 2:21.1.3-2+b1), xserver-xorg-video-intel:amd64
(2:2.99.917+git20200714-2, 2:2.99.917+git20210115-1), xserver-xorg-video-
vesa:amd64 (1:2.5.0-1, 1:2.5.0-1+b1), xserver-xorg-legacy:amd64 (2:1.20.14-1,
2:21.1.3-2+b1), xserver-common:amd64 (2:1.20.14-1, 2:21.1.3-2), xserver-xorg-
video-radeon:amd64 (1:19.1.0-2, 1:19.1.0-2+b1), xserver-xorg-video-vmware:amd64
(1:13.3.0-3, 1:13.3.0-3+b1), xserver-xorg-input-libinput:amd64 (1.2.0-1,
1.2.1-1+b1), xserver-xephyr:amd64 (2:1.20.14-1, 2:21.1.3-2+b1), xserver-xorg-
video-ati:amd64 (1:19.1.0-2, 1:19.1.0-2+b1), xserver-xorg-video-fbdev:amd64
(1:0.5.0-1, 1:0.5.0-2), xserver-xorg-video-qxl:amd64 (0.1.5+git20200331-1,
0.1.5+git20200331-2)
End-Date: 2022-02-24  22:36:41

Issue occurred on next login (the following day)

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

My system has multiple desktops installed & any that have a default config that
matches my setup (landscape+portrait) allow screens to go black, cursor to draw
then logout without message; this includes LXQt, Xfce, ...


   * What was the outcome of this action?

Machine cannot be used by any installed desktop that had my screen orientation
saved.

   * What outcome did you expect instead?

Normal behavior - login gets my desktop drawn & allows me to use it.  I've
altered this GNOME to return to defaults so I have one display readable (other
is orientated wrongly as it's sideways; setup is landscape as that works but
monitor is portrait..)

LXDE still logs in, but it didn't have screen orientation configured; however
if I run the script

xrandr --output HDMI-0 --mode 1280x1024 --pos 1280x0 --rotate left --output
DVI-0 --primary --mode 1280x1024 --pos 0x0 --rotate normal --output VGA-0 --off

which adjusts display to match my setup - instant logout !!


In `sudo journalctl` I see the following when I run the `xrandr` command I just
mentioned; I see equivalent on login via Xfce/LXQt/.. too; but I've copy/pasted
from a LXDE session where I ran the `xrand` command

Feb 28 20:31:48 dc780-deb kernel: [ cut here ]
Feb 28 20:31:48 dc780-deb kernel: WARNING: CPU: 0 PID: 833 at
drivers/gpu/drm/ttm/ttm_bo.c:411 ttm_bo_release+0x384/0x3b0 [ttm]
Feb 28 20:31:48 dc780-deb kernel: Modules linked in: bnep snd_seq_dummy
snd_hrtimer snd_seq snd_seq_device nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss
nfsv4 dns_resolver nfs lockd grace fscac>
Feb 28 20:31:48 dc780-deb kernel:  libcrc32c crc32c_generic amdgpu gpu_sched
hid_generic usbhid hid sd_mod t10_pi uas crc_t10dif crct10dif_generic
usb_storage sr_mod cdrom crct10dif_common >
Feb 28 20:31:48 dc780-deb kernel: CPU: 0 PID: 833 Comm: Xorg Not tainted
5.16.0-1-amd64 #1  Debian 5.16.7-2
Feb 28 20:31:48 dc780-deb kernel: Hardware name: Dell Inc. OptiPlex 780
/0200DY, BIOS A03 02/13/2010
Feb 28 20:31:48 dc780-deb kernel: RIP: 0010:ttm_bo_release+0x384/0x3b0 [ttm]
Feb 28 20:31:48 dc780-deb kernel: Code: 00 e8 50 ca 8a f2 48 8b 43 e8 eb a8 be
03 00 00 00 e8 f0 51 6c f2 e9 6f fd ff ff e8 c6 a7 8a f2 e9 65 fd ff ff 48 89
e8 eb 8a <0f> 0b e9 af fc ff ff >
Feb 28 20:31:48 dc780-deb kernel: RSP: 0018:b47d40dabdf0 EFLAGS: 00010202
Feb 28 20:31:48 dc780-deb kernel: RAX:  RBX: 921c063f3dd8
RCX: 
Feb 28 20:31:48 dc780-deb kernel: RDX: 0002 RSI: b374e32e
RDI: 921c063f3dd8
Feb 28 20:31:48 dc780-deb kernel: RBP: 921c00b846f0 R08: 921c063f3dd8
R09: 0064
Feb 28 20:31:48 dc780-deb kernel: R10: 0010 R11: 921c04a98b68
R12: 921c063f3c78
Feb 28 20:31:48 dc780-deb kernel: R13: 921d2ffbf560 R14: 921c04699780
R15: 
Feb 28 20:31:48 dc780-deb kernel: FS:  7f1b35623ec0()
GS:921d2fe0() knlGS:
Feb 28 20:31:48 dc780-deb kernel: CS:  0010 DS:  ES:  CR0:
80050033
Feb 28 20:31:48 dc780-deb kernel: CR2: 7f89dea28a30 CR3: 0001159c
CR4: 000406f0
Feb 28 20:31:48 dc780-deb kernel: Call Trace:
Feb 28 20:31:48 dc780-deb kernel:  
Feb 28 20:31:48 dc780-deb kernel:  ? __inode_wait_for_writeback+0x7e/0xe0
Feb 28 20:31:48 dc780-deb kernel:  ? fsnotify_grab_connector+0x49/0x80
Feb 28 20:31:48 dc780-deb kernel:  radeon_bo_unref+0x1a/0x30 [radeon]
Feb 28 20:31:48 dc780-deb kernel:  radeon_gem_object_free+0x30/0x50 [radeon]
Feb 28 20:31:48 dc780-deb kernel:  drm_gem_dmabuf_release+0x36/0x50 [drm]
Feb 28 

Bug#1006604: debian-edu-config: Debian Edu clients without GOsa system entry loose IP address after 30min

[Holger Levsen]

On Mon, Feb 28, 2022 at 10:22:09AM +, Mike Gabriel wrote:
> Comments, opinions?
 
I wonder if this is a bug in Debian Edu at all: don't we require hosts to be
added to GOsa in the first place?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"I know what you're thinking" used to be an idiom but now it's a business model.


signature.asc
Description: PGP signature

Bug#1006603: evolution: Can't lock mbox file: The reported error was “Could not lock “/var/mail/adrian””

[Patrice Duroux]

Hi,

Probably the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004484
which points to the possible problem source and also a temporary solution.

Regards,
Patrice

On Mon, 28 Feb 2022 11:04:33 +0100 Adrian Immanuel Kiess 
wrote:
> Package: evolution
> Version: 3.43.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
>  Upgrading Evolution some months ago
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  apt -u dist-upgrade
>    * What was the outcome of this action?
>  Evolution is unable to lock the mbox file in /var/mail/adrian and reports
> error
>    * What outcome did you expect instead?
>  Evolution being able to read and lock mbox mail file in /var/mail
> 
> in the recent Evolution mail reader on Debian/testing, I can't read my local
> mails stored in /var/mail/adrian.
> 
> The error Evolution spits out is this:
> 
> Failed to refresh folder “adr...@lan.dac : INBOX”.
> 
> The reported error was “Could not lock “/var/mail/adrian””.
> 
> Here is the directory listing of /var/mail on my system:
> 
> root@g6 /var/mail # ls -lah
> total 1,4M
> drwxrwsr-x  2 root mail 4,0K 28 févr. 07:43 ./
> drwxr-xr-x 17 root root 4,0K 18 oct.  11:49 ../
> -rw-rw  1 adrian   mail    0 28 févr. 07:44 adrian
> 
> Reading the mail with Sylpheed works fine.
> 
> I searched the Internet with Google, but could not find a solution.
> 
> I would be very gladful for help or fix.
> 
> Sincerely,
> 
> Adrian Kiess
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (990, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> 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 evolution depends on:

Bug#964947: dhcpcd5: New upstream version available: 9.1.4

[Santiago R.R.]

(Removing some people from CC to avoid polluting their mailboxes)

El 25/02/22 a las 11:25, Martin-Éric Racine escribió:
> On Fri, Feb 25, 2022 at 10:31 AM Roy Marples  wrote:
> >
> > On 24/02/2022 21:31, Santiago R.R. wrote:
> >  >
> >  > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R."
> >  wrote:
> >  >>
> >  >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine"
> >  wrote:
> >  >>> Package: dhcpcd5
> >  >>> Followup-For: Bug #964947
> >  >>> X-Debbugs-Cc:
> > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org
> >  >>>
> > > I have an NMU waiting on Mentors.
> > >
> > > 
> > >
> > >> Thanks for your work! I do not have too much free cycles, but I will do 
> > >> my best to review and upload it soon.
...

I forgot to say I hope Scott is doing well. I hope his lack of activity
is just a lack of available time.


Martin-Éric, thank you again for preparing this NMU. Here you have some
comments/questions:

* You are moving stuff to /usr. Do you have any reason for making this
  change in this NMU?
  While I think it is a good thing, this is not documented in
  d/changelog, and I think an NMU should focus on the reason for doing it
  (the newest upstream release in this case).
  From the developers reference (5.11.1.): "...Fixing cosmetic issues or
  changing the packaging style in NMUs is discouraged."

  This also concerns the minor bump version number in d/watch.

* Could you please fix the indentation of the your new entry in d/copyright?

* Part of the changes you are including had already been done in the VCS
  by Scott. There is no rule about this, but *I* would give credit to
  him. Maybe I would have cherry-picked the relevant changes needed for
  packaging this new upstream release, and use `gdp dch`. This is up to
  you.

* Could you please tell me how have you tested it?

(I will answer Roy's messages in another mail)

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1006511: net-snmp: FTBFS with OpenSSL 3.0

[Craig Small]

On Sun, 27 Feb 2022 at 02:42, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> wrote:

> | transports/snmpTLSBaseDomain.c:59:22: error: static declaration of
> ‘ERR_get_error_all’ follows non-static declaration
> |59 | static unsigned long ERR_get_error_all(const char **file, int
> *line,

|   |  ^
> | In file included from transports/snmpTLSBaseDomain.c:31:
> | /usr/include/openssl/err.h:406:15: note: previous declaration of
> ‘ERR_get_error_all’ with type ‘long unsigned int(const char **, int
> *, const char **, const char **, int *)’
> |   406 | unsigned long ERR_get_error_all(const char **file, int *line,
> |   |   ^
>
This should not be compiled because HAVE_ERR_GET_ERROR_ALL should be
defined (so it's skipped over) Looks like the configure script is not
picking it up.
It looks like the test program does not include openssl/err.h which means
it fails. AC_CHECK_FUNC doesn't include additional headers, which is why
this isn't working.

| transports/snmpTLSBaseDomain.c: In function ‘ERR_get_error_all’:
> | transports/snmpTLSBaseDomain.c:64:5: warning:
> ‘ERR_get_error_line_data’ is deprecated: Since OpenSSL 3.0
> [-Wdeprecated-declarations]
> |64 | return ERR_get_error_line_data(file, line, data, flags);
> |   | ^~
> | In file included from transports/snmpTLSBaseDomain.c:31:
> | /usr/include/openssl/err.h:413:15: note: declared here
> |   413 | unsigned long ERR_get_error_line_data(const char **file, int
> *line,
> |   |   ^~~
> | make[3]: *** [Makefile:101: transports/snmpTLSBaseDomain.lo] Error 1
> | make[3]: Leaving directory '/<>/snmplib
>

At the very least I'll just remove the code within the ifndef as its a
*backport* of the OpenSSL 1.1.1e function.
I'll look at
https://stackoverflow.com/questions/63942436/determining-openssl-version-with-ifdef
or something like that to properly check the result.

 - Craig

Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Hi!

On 2/28/22 11:16, John Paul Adrian Glaubitz wrote:
> On 2/28/22 09:53, John Paul Adrian Glaubitz wrote:
>> I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
>> chroot, but unfortunately it didn't work:
> 
> I think this check is wrong:
> 
> diff --git a/configure.ac b/configure.ac
> index 827e1c09d..dec060414 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -369,6 +369,9 @@ else
>  fi
>  AC_SUBST([SCM_I_GSC_T_PTRDIFF])
>  
> +AM_CONDITIONAL([DEB_GUILE_32_BIT_BIG_ENDIAN],
> +  [test "$ac_cv_words_bigendian" && test "$ac_cv_sizeof_void_p" -lt 8])
> +
>  AC_CHECK_HEADERS([stdatomic.h])
>  
>  AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])
> 
> It looks like the correct variable name for the big-endian check is
> 
>   $ac_cv_c_bigendian

Why not just use the result of this check?

AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])
SCM_PREBUILT_BINARIES=
case "$ac_cv_c_bigendian-$ac_cv_sizeof_void_p" in
  yes-8) SCM_PREBUILT_BINARIES=64-bit-big-endian;;
  yes-4) SCM_PREBUILT_BINARIES=32-bit-big-endian;;
  no-8) SCM_PREBUILT_BINARIES=64-bit-little-endian;;
  no-4) SCM_PREBUILT_BINARIES=32-bit-little-endian;;
  *) AC_MSG_ERROR([Unexpected endianness+pointer size combination.])
esac
AC_MSG_RESULT($SCM_PREBUILT_BINARIES)
AC_SUBST([SCM_PREBUILT_BINARIES])

Adrian

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

Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Hi Rob!

On 2/28/22 09:53, John Paul Adrian Glaubitz wrote:
> I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
> chroot, but unfortunately it didn't work:

I think this check is wrong:

diff --git a/configure.ac b/configure.ac
index 827e1c09d..dec060414 100644
--- a/configure.ac
+++ b/configure.ac
@@ -369,6 +369,9 @@ else
 fi
 AC_SUBST([SCM_I_GSC_T_PTRDIFF])
 
+AM_CONDITIONAL([DEB_GUILE_32_BIT_BIG_ENDIAN],
+  [test "$ac_cv_words_bigendian" && test "$ac_cv_sizeof_void_p" -lt 8])
+
 AC_CHECK_HEADERS([stdatomic.h])
 
 AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])

It looks like the correct variable name for the big-endian check is

$ac_cv_c_bigendian

Adrian

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

Bug#873717: Fixed a long time ago....

[Bernd Zeimetz]

Control: close -1

On 2022-02-28 09:57, Andreas Beckmann wrote:


Definitively not.

This was worked around in 5.7.2-2 with --disable-sigrok


That actually fixes a bug called 'ftbfs'. The package will build again.
Its not a workaround, this is the only solution.


Trying to re-enable it on 5.12.0-9 only results in

  checking for libsigrok < 0.4... no

and a subsequent configure failure.


There is not libsigrok < 0.4 in Debian. Not even 0.4 is supported.


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer Marin Rodrigues]

Hi Francesco,

Quoting Francesco Poli (2022-02-26 00:35:01)
> At least, it completes without any error.
> And it generates a 'debian-unstable.qcow2' image that can boot, if I
> test it with:
> 
>   $ qemu-system-x86_64 -enable-kvm -m 512 -serial 
> unix:/tmp/ttyS0,server,nowait -drive  
> "file=./debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"
> 
> I can even login as root (password-less!) in the graphical window that
> QEMU shows!
> 
> Now, I remember that you said I should test the serial console with
> minicom on the /tmp/ttyS0 socket.
> I typically use picocom for serial console connections.
> Is there a way to make picocom connect to a UNIX socket?
> 
> Maybe I should try after using socat, as suggested in this [howto].
> 
> [howto]: 
> 
> Or is there a better way?

I don't know about picocom. Either of the following should work:

$ minicom -D unix#/tmp/ttyS0
$ nc -U /tmp/ttyS0
$ socat - UNIX-CONNECT:/tmp/ttyS0

> However, it leaves a lot of "production scrap" within /dev/shm :
>
>  $ du --si -s /dev/shm/.guestfs-1000/
>  755M/dev/shm/.guestfs-1000/
>
> More than 750 MB of "production scrap"!
>
> Why does guestfish do this?

I don't know and I don't have these files in my own $TMPDIR.

In any case, if it works for you now, maybe you can close this bug?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1006603: evolution: Can't lock mbox file: The reported error was “Could not lock “/var/mail/adrian””

[Adrian Immanuel Kiess]

Package: evolution
Version: 3.43.2-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Upgrading Evolution some months ago
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt -u dist-upgrade
   * What was the outcome of this action?
 Evolution is unable to lock the mbox file in /var/mail/adrian and reports
error
   * What outcome did you expect instead?
 Evolution being able to read and lock mbox mail file in /var/mail

in the recent Evolution mail reader on Debian/testing, I can't read my local
mails stored in /var/mail/adrian.

The error Evolution spits out is this:

Failed to refresh folder “adr...@lan.dac : INBOX”.

The reported error was “Could not lock “/var/mail/adrian””.

Here is the directory listing of /var/mail on my system:

root@g6 /var/mail # ls -lah
total 1,4M
drwxrwsr-x  2 root mail 4,0K 28 févr. 07:43 ./
drwxr-xr-x 17 root root 4,0K 18 oct.  11:49 ../
-rw-rw  1 adrian   mail0 28 févr. 07:44 adrian

Reading the mail with Sylpheed works fine.

I searched the Internet with Google, but could not find a solution.

I would be very gladful for help or fix.

Sincerely,

Adrian Kiess


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 evolution depends on:
ii  dbus   1.12.22-1
ii  evolution-common   3.43.2-2
ii  evolution-data-server  3.43.2-1
ii  libc6  2.33-7
ii  libcamel-1.2-633.43.2-1
ii  libclutter-gtk-1.0-0   1.8.4-4+b1
ii  libecal-2.0-1  3.43.2-1
ii  libedataserver-1.2-26  3.43.2-1
ii  libevolution   3.43.2-2
ii  libglib2.0-0   2.70.4-1
ii  libgtk-3-0 3.24.31-1
ii  libical3   3.0.14-1
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.74.2-3
ii  libxml22.9.12+dfsg-6
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.43.2-2
ii  evolution-plugin-pstimport   3.43.2-2
ii  evolution-plugins3.43.2-2
ii  yelp 42~beta-2

Versions of packages evolution suggests:
pn  evolution-ews   
ii  evolution-plugins-experimental  3.43.2-2
ii  gnupg   2.2.27-3
pn  network-manager 

-- debconf information:
  evolution/kill_processes:
  evolution/needs_shutdown:

Bug#1005594: rygel: FTBFS: ../meson.build:99:0: ERROR: Could not generate cargs for gst-editing-services-1.0:

[Laurent Bigonville]

reassign 1005594 libges-1.0-dev 1.20.0-1
affects 1005594 src:rygel
thanks

On Sun, 13 Feb 2022 08:31:17 +0100 Lucas Nussbaum  wrote:


> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
[...]

> > Package 'python-3.9-embed', required by 'gst-editing-services-1.0', 
not found


This is an issue with gstreamer-editing-services1.0

libges-1.0-dev package should depends against libpython3-dev (or 
libpython3.X-dev) as the .pc file requires it


I'm not sure how to automatically calculate that we need 
libpython3.9-dev vs libpython3.10-dev for example

Bug#1006602: ITP: txdbus -- implementation of the DBus protocol for the Twisted networking framework

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pyt...@tracker.debian.org

* Package name: txdbus
  Version : 1.1.2 (2020-10-14)
  Upstream Author : Tom Cocagne 
* URL : https://github.com/cocagne/txdbus
* License : MIT
  Programming Lang: Python
  Description : implementation of the DBus protocol for the Twisted 
networking framework

> TxDBus is a native Python implementation of the DBus protocol for the
> Twisted networking framework.
>
> In addition to a tutorial, and collection of examples the
> documentation for this project also includes An Overview of the DBus
> Protocol.

This is a new/future dependency for libervia-backend.
I'll maintain it within the Python team.

Bug#862191: Any news on ITP: brython?

[Martin]

Hi, is there any progress in packaging Brython? TIA!

Bug#1006601: ITP: qvge -- Qt Visual Graph Editor

[Gürkan Myczko]

> On 28 Feb 2022, at 10:06, Maxime Chambonnet  wrote:
> 
> Hello, Do you know about pgModeler?

No I was not aware of it.

> 
>> On 2/28/22 09:57, Gürkan Myczko wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Gürkan Myczko 
>> X-Debbugs-Cc: debian-de...@lists.debian.org
>> 
>> * Package name: qvge
>>   Version : 0.6.3
>>   Upstream Authors: 2018-Ars Masiuk
>>   URL : https://github.com/ArsMasiuk/qvge
>> * License : MIT
>>   Description : Qt Visual Graph Editor
>>  This is a multiplatform graph editor written in C++/Qt. Its main goal
>> is to
>>  make possible visually edit two-dimensional graphs in a simple and
>> intuitive
>>  way.
>> 
> 

Bug#1006431: dkms leaves directories under /lib/modules for removed kernels

[Vincent Lefevre]

This may be due to a bug with "dkms remove": the warnings at the end
suggest an inconsistent state.

# dkms remove nvidia-legacy-390xx/390.147 -k 5.16.0-1-amd64
Module nvidia-legacy-390xx-390.147 for kernel 5.16.0-1-amd64 (x86_64).
Before uninstall, this module version was ACTIVE on this kernel.

nvidia-legacy-390xx.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.16.0-1-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


nvidia-legacy-390xx-modeset.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.16.0-1-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


nvidia-legacy-390xx-drm.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.16.0-1-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


nvidia-legacy-390xx-uvm.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.16.0-1-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

do_depmod 5.16.0-1-amd64
depmod: WARNING: could not open modules.order at /lib/modules/5.16.0-1-amd64: 
No such file or directory
depmod: WARNING: could not open modules.builtin at /lib/modules/5.16.0-1-amd64: 
No such file or directory

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

Bug#1006601: ITP: qvge -- Qt Visual Graph Editor

[Maxime Chambonnet]

Hello, Do you know about pgModeler?

On 2/28/22 09:57, Gürkan Myczko wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gürkan Myczko 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name    : qvge
>   Version : 0.6.3
>   Upstream Authors: 2018-Ars Masiuk
>   URL : https://github.com/ArsMasiuk/qvge
> * License : MIT
>   Description : Qt Visual Graph Editor
>  This is a multiplatform graph editor written in C++/Qt. Its main goal
> is to
>  make possible visually edit two-dimensional graphs in a simple and
> intuitive
>  way.
>

Bug#1006601: ITP: qvge -- Qt Visual Graph Editor

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: qvge
  Version : 0.6.3
  Upstream Authors: 2018-Ars Masiuk
  URL : https://github.com/ArsMasiuk/qvge
* License : MIT
  Description : Qt Visual Graph Editor
 This is a multiplatform graph editor written in C++/Qt. Its main goal 
is to
 make possible visually edit two-dimensional graphs in a simple and 
intuitive

 way.

Bug#873717: Fixed a long time ago....

[Andreas Beckmann]

Control: reopen -1

On Fri, 21 Jan 2022 20:04:14 +0100 Bernd Zeimetz  wrote:

Version: 5.6.0-1


Definitively not.

This was worked around in 5.7.2-2 with --disable-sigrok

Trying to re-enable it on 5.12.0-9 only results in

  checking for libsigrok < 0.4... no

and a subsequent configure failure.


Andreas

Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Hi Rob!

On 2/28/22 05:13, Rob Browning wrote:
> Oh, and I'm not sure it's working exactly right yet, but I'd been toying
> with a more selective approach that works with automake's if/then
> restrictions via an AM_CONDITIONAL.  Of course we'll still need to
> figure out which Makefiles we need to adjust.

I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
chroot, but unfortunately it didn't work:

In unknown file:
  13 (_ # # #)
  12 (_ # # #)
In ice-9/eval.scm:
619:8 11 (_ #(#(# # ?)))
   196:35 10 (_ #(#(# ?) #))
In unknown file:
   9 (_ # # #)
   8 (_ # # #)
   7 (_ # # #)
In ice-9/eval.scm:
   202:35  6 (_ #(#(# ?) ?))
In language/tree-il/optimize.scm:
 56:6  5 (_ _ #)
In language/tree-il.scm:
   573:16  4 make[4]: *** [Makefile:2419: language/cps/intset.go] Segmentation 
fault

FWIW, you can access the porterbox yourself using your Debian SSH account.

Adrian

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

Bug#1006600: mathjax: please package v3.*

[Andrius Merkys]

Source: mathjax
Severity: wishlist

Hello,

mathjax v3.0.0 was released in September 2019. It would be nice to have
it in bookworm. I am working on updating pdb2pqr which wants mathjax
v3.* features in its documentation, in particular tex-mml-chtml.js which
is not available in v2.*.

Andrius

Bug#1006568: rauc: FTBFS with OpenSSL 3.0

[Jan Lübbe]

On Sun, 27 Feb 2022 22:15:45 +0100 Sebastian Andrzej Siewior 
 wrote:
> Your package is failing to build using OpenSSL 3.0 with the
> following error:
> 
> |Creating bundle in 'plain' format
> |C08ACC46967F:error:12800067:DSO support routines:DSO_load:could not load 
> the shared library:../crypto/dso/dso_lib.c:152:
> |C08ACC46967F:error:1384:engine routines:dynamic_load:dso not 
> found:../crypto/engine/eng_dyn.c:422:
> |C08ACC46967F:error:1374:engine routines:ENGINE_by_id:no such 
> engine:../crypto/engine/eng_list.c:430:id=pkcs11
> |not ok 20 - rauc bundle with PKCS11 (key 1)
> |FAIL: test/rauc.t 20 - rauc bundle with PKCS11 (key 1)

This seems to be caused by a missing PKCS#11 OpensSSL engine. RAUC's test suite
uses SoftHSM to test the PKCS#11 support, so it needs a working PKCS#11 engine
and module matching the active OpenSSL. In Debian, the engine is provided by
libp11 (in libengine-pkcs11-openssl) and the module is provided by SoftHSM (in
libsofthsm2).

Neither of libp11 nor SoftHSM have been updated to OpenSSL 3 in Debian yet, so
the PKCS#11 tests can't work. Without PKCS#11 support, RAUC should already work
with OpenSSL 3, though. As soon as the dependencies are updated, PKCS#11 in RAUC
should work as well without further changes to RAUC.

Regards,
Jan

Bug#1004433: Patches for CVE-2022-23959

[Andreas Unterkircher]

It appreciate if you could test bullseye as well.  Thanks!


Have updated a server with Buster (on which I've tested Varnish 
v6.1.1-1+deb10u3 before) to Bullseye and upgraded Varnish to 
6.5.1-1+deb11u2.


The results are pretty much the same as with Buster.

The hosted pages work correctly with HTTP 1.1 trough Varnish.
The same for HTTP2.
Locust against Varnish with 100 req/sec gives stable results for 10min 
testing.


user@host:~$ sudo varnishd -V
varnishd (varnish-6.5.1 revision 
1dae23376bb5ea7a6b8e9e4b9ed95cdc9469fb64)

Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2020 Varnish Software
user@host:~$ sudo varnishstat  -n $(hostname) -1
MGT.uptime1054 1.00 Management process uptime
MGT.child_start  1 0.00 Child process started
MGT.child_exit   0 0.00 Child process normal exit
MGT.child_stop   0 0.00 Child process unexpected 
exit

MGT.child_died   0 0.00 Child process died (signal)
MGT.child_dump   0 0.00 Child process core dumped
MGT.child_panic  0 0.00 Child process panic
MAIN.summs   7445070.57 stat summ operations
MAIN.uptime   1055 1.00 Child process uptime
MAIN.sess_conn   2539324.07 Sessions accepted
MAIN.sess_fail   0 0.00 Session accept failures
MAIN.sess_fail_econnaborted0 0.00 Session accept 
failures: connection aborted
MAIN.sess_fail_eintr   0 0.00 Session accept 
failures: interrupted system call
MAIN.sess_fail_emfile  0 0.00 Session accept 
failures: too many open files
MAIN.sess_fail_ebadf   0 0.00 Session accept 
failures: bad file descriptor
MAIN.sess_fail_enomem  0 0.00 Session accept 
failures: not enough memory
MAIN.sess_fail_other   0 0.00 Session accept 
failures: other
MAIN.client_req_4000 0.00 Client requests 
received, subject to 400 errors
MAIN.client_req_4170 0.00 Client requests 
received, subject to 417 errors
MAIN.client_req3503033.20 Good client 
requests received

MAIN.cache_hit 3370331.95 Cache hits


Cheers,
Andreas