Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Samuel Thibault]

Lisandro Damián Nicanor Pérez Meyer, le mer. 12 avril 2023 21:54:03 -0300, a 
ecrit:
> Samuel: do you know if this bug is also applicable to Qt 6?

Yes it is. The patch I have sent upstream should apply fine on debian's
qt6.

Samuel

Bug#1034333: doc files empty offline

[Dan Jacobson]

Package: imagemagick-6-doc
Version: 8:6.9.11.60+dfsg-1.6
Severity: important
File: /usr/share/doc/imagemagick-6-common/html/www/examples.html

Testing offline,
In firefox and chrome, all one sees is
"
Home (current)
Download
Tools
Command-line
Develop
Community
"

one sees much more in w3m.

Bug#1034332: Occasional garbled Chinese pdf lines

[Dan Jacobson]

Package: abiword
Version: 3.0.5~dfsg-3.2
File: /usr/bin/abiword

Here we see that there is a bug in the pdf creator:
{ echo 哈哈 郵編123 哈哈; echo 郵編123;} > /tmp/n.txt
abiword --to=pdf /tmp/n.txt
When viewing the resultant pdf, one line is garbled.

But if I use
LC_ALL=C abiword --to=pdf /tmp/n.txt
then all worked fine.

OK, what was my
$ locale?
LANG=zh_TW.UTF-8
LANGUAGE=en_US:en
LC_CTYPE=zh_TW.UTF-8
LC_NUMERIC="zh_TW.UTF-8"
LC_TIME="zh_TW.UTF-8"
LC_COLLATE=C
LC_MONETARY="zh_TW.UTF-8"
LC_MESSAGES=C
LC_PAPER="zh_TW.UTF-8"
LC_NAME="zh_TW.UTF-8"
LC_ADDRESS="zh_TW.UTF-8"
LC_TELEPHONE="zh_TW.UTF-8"
LC_MEASUREMENT="zh_TW.UTF-8"
LC_IDENTIFICATION="zh_TW.UTF-8"
LC_ALL=

So sure, always use LC_ALL=C ... but some other characters still get
messed up. But I would have to send you my whole secret letter to
reproduce it. So just take my word for it.

And using LC_ALL=zh_CN.UTF-8 didn't help.

Versions of packages abiword recommends:
pn  abiword-plugin-grammar 
ii  aspell-en [aspell-dictionary]  2020.12.07-0-1
ii  fonts-liberation   1:1.07.4-11
ii  poppler-utils  22.12.0-2+b1

Yes, pdffonts will show the fonts used.
I didn't see anything on the abiword man page about controling what fonts get 
used.

Bug#1034334: Loading any HTML fails

[Dan Jacobson]

Package: gnumeric
Version: 1.12.55-1
File: /usr/bin/ssconvert

Loading any HTML fails.
No. Nobody knows why it fails.
It just says it fails.
$ ssconvert jidanni.org/index.html /tmp/i.html
Loading file:///home/jidanni/jidanni.org/index.html failed

Bug#1034335: ssconvert man page break missing

[Dan Jacobson]

Package: gnumeric
Version: 1.12.55-1
Severity: minor
File: /usr/share/man/man1/ssconvert.1.gz

The ssconvert man page has:

   --list-importers
  List the available importers (file formats that  can  be  read).
BREAK MISSING:-I,  --import-type=ID  Specify  which importer to use; see below
  for a list. This is only necessary when the  right  format  does
  not follow from the input file name.

Bug#1034098: reportbug: gamemode needs policykit-1 as a dependency

[Stephan Lachnit]

Hi Safir,

thanks for the report. Can you open a MR on Salsa with this change?
https://salsa.debian.org/games-team/gamemode

Regards,
Stephan

Bug#1034337: ltunify: udev not triggered after installation

[Laurent Bigonville]

Package: ltunify
Version: 0.3-1
Severity: normal

Hello,

It seems that the package is installing a udev rules file, but udev is
not (re)triggered after installation.

You should probably add something like that (to be tested) in the postinst 
script:

udevadm control --reload || true
udevadm trigger --subsystem-match=hidraw --action=change || true

Kind regards,
Laurent Bigonville


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1034338: kwin-wayland: Resizing Window leads to malformed decorations

[Jonas Seiler]

Package: kwin-wayland
Version: 4:5.27.2-1
Severity: important

When resizing windows decorated by non-standard decorations in Plasma 5.27.2 
Wayland, the window decorations such as window title and buttons are malformed 
and nigh unusable.

This was reported here [1] and apparently got fixed with this commit [2], as 
mentioned in the bug report.

This happens on a fresh install of the current bookworm installation without 
further adjustments and noticeably impacts the workflow when the window is not 
correctly displayed most of the time and moving/resizing windows with the mouse 
is not feasible due to this anymore.
Cherry-picking that commit would be greatly appreciated.

Kind regards,
Jonas

[1] https://bugs.kde.org/show_bug.cgi?id=465790 [2] 
https://invent.kde.org/plasma/kwin/-/commit/715f4147fec2734a0ed56f7ae799e678e18f451f

Bug#1034339: libpam-mount: 'sudo -i' gives 'HXproc_run_async: pmvarrun: No such file or directory'

[Keith Edmunds]

Package: libpam-mount
Version: 2.19-1
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Running 'sudo -i' causes 'HXproc_run_async: pmvarrun: No such file or 
directory' to be printed. The sudo call works without problem.

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

sudo -i

   * What was the outcome of this action?

'HXproc_run_async: pmvarrun: No such file or directory' was printed

   * What outcome did you expect instead?

Not to see that message

Fix (but I don't know whether this is the best or correct fix):

--- /tmp/pam_mount.conf.xml.original2023-04-13 09:23:42.587754765 +0100
+++ /etc/security/pam_mount.conf.xml2023-04-13 09:16:31.053801290 +0100
@@ -38,4 +38,7 @@
 
 
 
+
+/usr/sbin/pmvarrun -u %(USER)
+
 


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpam-mount depends on:
ii  libc62.36-8
ii  libcryptsetup12  2:2.6.1-3~deb12u1
ii  libhx32  4.10-1
ii  libmount12.38.1-5+b1
ii  libpam-runtime   1.5.2-6
ii  libpam0g 1.5.2-6
ii  libpcre2-8-0 10.42-1
ii  libssl3  3.0.8-1
ii  libxml2  2.9.14+dfsg-1.1+b3

Versions of packages libpam-mount recommends:
ii  libpam-mount-bin  2.19-1

Versions of packages libpam-mount suggests:
ii  cifs-utils2:7.0-2
pn  davfs2
ii  fuse3 [fuse]  3.14.0-3
pn  hxtools   
ii  lsof  4.95.0-1
ii  openssl   3.0.8-1
ii  psmisc23.6-1
ii  sshfs 3.7.3-1.1
ii  xfsprogs  6.1.0-1

-- Configuration Files:
/etc/security/pam_mount.conf.xml changed:


















/usr/sbin/pmvarrun -u %(USER)



-- no debconf information

Bug#1034340: ltunify: 0.3-1

[Laurent Bigonville]

Package: ltunify
Version: 0.3-1
Severity: normal

Hello,

The udev rules file starts with the following:

# skip actual unified devices, only consider the receiver
DRIVERS=="logitech-djdevice", GOTO="not_unify_recv"

For what I understand only the permissions of reciver should be modified

But for what I can see, the permissions of the hidraw device of my mouse
are also modified:

$ ls -la /dev/hidraw*
[...]
crw-rw+ 1 root root 248, 3 13 avr 10:15 /dev/hidraw3
crw-rw+ 1 root root 248, 4 13 avr 10:15 /dev/hidraw4

[259919.846547] logitech-djreceiver 0003:046D:C52B.0034: hiddev0,hidraw3: USB 
HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-1.1.4/input2
[259919.976009] logitech-hidpp-device 0003:046D:101A.0035: input,hidraw4: USB 
HID v1.11 Mouse [Logitech Performance MX] on usb-:00:14.0-1.1.4/input2:2

So that doesn't seem to be right.

When running udevadm info on the two devices, I don't see the driver
being displayed, so I think that the matching based on the driver is not
working.

Kind regards,
Laurent Bigonville

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1034341: mirror listing update for linux.purple-cat.net

[Mike Hosken]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: linux.purple-cat.net
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: Mike Hosken 
Country: NZ New Zealand
Location: Dunedin 
Sponsor: Unifone NZ https://unifone.net.nz/
Comment: Updated information as not on list anymore. Ip address has changed. 
Also full Debian ports repo on debian-ports and Debian archive on debian-archive




Trace Url: http://linux.purple-cat.net/debian/project/trace/
Trace Url: 
http://linux.purple-cat.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://linux.purple-cat.net/debian/project/trace/linux.purple-cat.net

Bug#1034342: firebuild: Can miscalculate cache size and aborts when this is detected

[Bálint Réczey]

Package: firebuild
Version: 0.2.12-2
Severity: important
Tags: upstream fixed-upstream pending

Hi,

After garbage collecting the cache firebuild can store a negative
cache size value and then fail to start later with the following
message:

Assertion `cached_bytes >= 0': `-1154798 >= 0' failed.
firebuild: ./src/firebuild/execed_process_cacher.cc:1717: off_t
firebuild::ExecedProcessCacher::get_stored_bytes_from_cache() const:
Assertion `0 && "see previous message"' failed.

This can be fixed by deleting the cache or fixing
~/.cache/firebuild/size to a reasonable value, for example to the size
calculated with "du --apparent-size -b -s ~/.cache/firebuild".

I'm about to upload the fix to unstable.

Thanks,
Balint

Bug#1034343: unblock: rally/3.3.0-2

[Thomas Goirand]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rally

[ Reason ]
The python3-rally package was missing the alembic.ini needed
for the db migration. Version 3.3.0-2 fixes the issue.

[ Impact ]
Without the alembic.ini, it's impossible to run the script
to populate the Rally DB, making it impossible to use Rally.

[ Tests ]
I manually checked that the added "install-all-files.patch"
fixes the issue, and alembic.ini really is packaged this time.

[ Risks ]
>From my point of view: no risk.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock rally/3.3.0-2
diff -Nru rally-3.3.0/debian/changelog rally-3.3.0/debian/changelog
--- rally-3.3.0/debian/changelog2021-11-03 10:39:35.0 +0100
+++ rally-3.3.0/debian/changelog2023-04-13 11:06:02.0 +0200
@@ -1,3 +1,9 @@
+rally (3.3.0-2) unstable; urgency=medium
+
+  * Add install-missing-files.patch.
+
+ -- Thomas Goirand   Thu, 13 Apr 2023 11:06:02 +0200
+
 rally (3.3.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru rally-3.3.0/debian/patches/install-missing-files.patch 
rally-3.3.0/debian/patches/install-missing-files.patch
--- rally-3.3.0/debian/patches/install-missing-files.patch  1970-01-01 
01:00:00.0 +0100
+++ rally-3.3.0/debian/patches/install-missing-files.patch  2023-04-13 
11:06:02.0 +0200
@@ -0,0 +1,4 @@
+--- /dev/null  2023-04-12 22:33:09.798387821 +0200
 b/MANIFEST.in  2023-04-13 11:01:20.443835477 +0200
+@@ -0,0 +1 @@
++recursive-include rally *
diff -Nru rally-3.3.0/debian/patches/series rally-3.3.0/debian/patches/series
--- rally-3.3.0/debian/patches/series   2021-11-03 10:39:35.0 +0100
+++ rally-3.3.0/debian/patches/series   2023-04-13 11:06:02.0 +0200
@@ -1,2 +1,3 @@
 remove-failing-tests.patch
 remove-test-walk-version.patch
+install-missing-files.patch

Bug#1034219: debomatic: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Luca Falavigna]

tags 1034219 + patch
thanks


Hi Laurent, hi Andreas,

First of all, thanks for the bug report and for the discussion so far!

Il giorno mer 12 apr 2023 alle ore 10:51 Andreas Henriksson
 ha scritto:
> I'm not sure exactly what the best option is to adress this for pybuild
> using packages, but my guess would be to have some debian/rules hack
> that moves the file (if it's not already located in the same path as
> returned by `pkg-config --variable=systemdsystemunitdir systemd`) after
> dh_install has run probably.

I made a patch adjusting upstream setup.py file to create a symlink of
usr/lb to lib, this is the easiest way to let the buildsystem to
handle with the correct path.

I built the package on debomatic itself where we can see the unit file
is now shipped under /lib/systemd/system:
http://debomatic-amd64.debian.net/distribution#unstable/debomatic/0.26-2/contents

Do you think this will be enough to solve the bug?

-- 
Cheers,
Luca


bug1034219.debdiff
Description: Binary data

Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Paul Gevers]

Control: clone -1 -2
Control: reassign -2 release-notes

On 12-04-2023 16:57, Santiago Ruano Rincón wrote:

If the current behaviour
would be part of bookworm, a NEWS entry would be great.


And a release note would be worth it too I guess.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034207: okular: typewriter annotation ignores some letters

[Janusz S . Bień]

On Tue, Apr 11 2023 at  8:34 +02, Janusz S. Bień wrote:
> Package: okular
> Version: 4:20.12.3-2
> Severity: normal
> X-Debbugs-Cc: none, Janusz S. Bień 
>
> Looks like the annotation ignores non-ASCII letters, cf. the attachment.
>

Does this

https://bugs.kde.org/show_bug.cgi?id=445674

mean that the problem was solved upstream?

JSB

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Hans-Christoph Steiner]

Package: usrmerge
Version: 25
Severity: serious

I have some VPSes which are based on Xen, so the kernel comes from the host, and 
the VPS has no kernel installed.  /lib/modules is mounted but not via 
/etc/fstab.  When trying to upgrade from bullseye to bookworm, I get:


Preparing to unpack .../archives/usrmerge_35_all.deb ...
Unpacking usrmerge (35) ...
Setting up usrmerge (35) ...

FATAL ERROR:

/lib/modules/ is a mount point.
Probably this system is using User Mode Linux.

To continue the conversion please:
- replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
- reboot
- try again

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1

Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)


Here is some more info which should hopefully be helpful:

# umount /lib/modules/
umount: /lib/modules/: target is busy.
# lsof /lib/modules
COMMANDPID USER  FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-u 1145 root memREG   0,20   1503845 
/lib/modules/5.10.104/modules.symbols.bin
systemd-u 1145 root memREG   0,20   3224788 
/lib/modules/5.10.104/modules.alias.bin
systemd-u 1145 root memREG   0,20   119456   10 
/lib/modules/5.10.104/modules.dep.bin
systemd-u 1145 root memREG   0,20 76634 
/lib/modules/5.10.104/modules.builtin.bin

# ps -ef|grep 1145
root  1145 1  0 09:29 ?00:00:00 /lib/systemd/systemd-udevd
root 16599 25980  0 10:11 pts/100:00:00 grep 1145
# dpkg -l linux*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---===
un  linux-kernel-log-daemon   (no description available)
ii  linux-libc-dev:amd646.1.20-1 amd64Linux support headers for 
userspace development

# mount |grep /lib
modules on /lib/modules type tmpfs (rw,relatime,size=102400k,mode=700)
# cat /etc/fstab

/dev/xvda1  /   xfs defaults0   0
proc/proc   procdefaults0   0
#

Bug#1034347: spamd timeout after reboot: dns: bad dns reply: bgread: recv() failed

[Martin Michlmayr]

Package: spamd
Version: 4.0.0-4
Severity: important

After upgrading to bookworm, I'm getting timeouts from spamd.  This is
solved by:

sudo systemctl restart spamd.service

I have to do this after each reboot.

getmail tells me that procmail (which calls "spamc") time outs:

Delivery error...  child operation error: waiting child pid 24988 timed out)

The log show:

2023-04-13T17:05:45.739957+08:00 jirafa spamd[2629]: check: (run_eval) exceeded 
time limit, skipping further tests
2023-04-13T17:05:45.742269+08:00 jirafa spamd[2629]: async: aborting after 
298.682 s, past original deadline: URIBL, 
A/braze.eu.dob.sibl.support-intelligence.net, rules: URIBL_RHS_DOB
2023-04-13T17:05:45.742424+08:00 jirafa spamd[2629]: async: aborting after 
298.669 s, past original deadline: URIBL, 
A/www.ajwernick.co.uk.multi.surbl.org, rules: URIBL_MW_SURBL, URIBL_CR_SURBL, 
URIBL_WS_SURBL, URIBL_PH_SURBL, SURBL_BLOCKED, URIBL_ABUSE_SURBL
...
2023-04-13T17:05:46.076924+08:00 jirafa spamd[2629]: dns: sendto() to 
[127.0.0.1]:53 failed: Connection refused, failing over to [::1]:53
2023-04-13T17:05:46.077523+08:00 jirafa spamd[2629]: dns: sendto() to [::1]:53 
failed: Connection refused, failing over to [127.0.0.1]:53
2023-04-13T17:05:46.077901+08:00 jirafa spamd[2629]: dns: bad dns reply: 
bgread: recv() failed: Connection refused at 
/usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm line 752,  line 116.
2023-04-13T17:05:46.079571+08:00 jirafa spamd[2629]: dns: bad dns reply: 
bgread: recv() failed: Connection refused at 
/usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm line 752,  line 116.
2023-04-13T17:05:49.092655+08:00 jirafa spamd[2629]: dns: bad dns reply: 
bgread: recv() failed: Connection refused at 
/usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm line 752,  line 116.

A Google search has led to:
https://bugzilla.redhat.com/show_bug.cgi?id=1985587
The proposed patch seems relevant to Debian's spamd service file too:
https://src.fedoraproject.org/rpms/spamassassin/pull-request/12#request_diff

(I haven't tested it, though.)

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1034348: at: autopkgtest regression on arm64: Either at.20377 doesn't exist or the content differs.

[Paul Gevers]

Source: at
Version: 3.2.5-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on 
arm(64|el|hf) since September 2022 (and slightly longer on s390x). Can 
you please investigate the situation and fix it? I copied some of the 
output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/a/at/32696040/log.gz

autopkgtest [01:12:17]: test basic-usage: [---
+ TMPFILE=at.20377
++ mktemp -d
+ WORKDIR=/tmp/tmp.7IsxZpWEJn
+ trap 'rm -rf /tmp/tmp.7IsxZpWEJn' 0 INT QUIT ABRT PIPE TERM
++ atq
++ wc -l
+ JOBS_BEFORE=0
+ at now + 1 minute
++ date
warning: commands will be executed using /bin/sh
+ echo 'echo Fri Apr  7 01:12:17 CST 2023 > /tmp/tmp.7IsxZpWEJn/at.20377'
job 1 at Fri Apr  7 01:13:00 2023
+ sleep 2
+ test -f at.20377
+ echo 'OK, at.20377 doesn'\''t exist yet; expected..'
OK, at.20377 doesn't exist yet; expected..
++ atq
++ wc -l
+ JOBS_AFTER=1
+ [[ 1 -eq 1 ]]
+ echo 'OK, 1 new queued job exists..'
+ sleep 58
OK, 1 new queued job exists..
+ grep -Fq UTC /tmp/tmp.7IsxZpWEJn/at.20377
+ echo 'Either at.20377 doesn'\''t exist or the content differs.'
+ exit 1
Either at.20377 doesn't exist or the content differs.
+ rm -rf /tmp/tmp.7IsxZpWEJn
autopkgtest [01:13:18]: test basic-usage: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Marco d'Itri]

Control: severity -1 normal

On Apr 13, Hans-Christoph Steiner  wrote:

> I have some VPSes which are based on Xen, so the kernel comes from the host,
> and the VPS has no kernel installed.  /lib/modules is mounted but not via
> /etc/fstab.  When trying to upgrade from bullseye to bookworm, I get:
Then fix it as suggested, but not via fstab?
Looks like this is a documentation issue.
What do you think should be changed here, exactly?

> To continue the conversion please:
> - replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
> - reboot
> - try again

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034349: bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted)

[Paul Gevers]

Source: bedtools
Version: 2.30.0+dfsg-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/b/bedtools/32856831/log.gz

autopkgtest [18:36:06]: test run-unit-test: [---
test.sh: 4: ulimit: error setting limit (Operation not permitted)
autopkgtest [18:36:07]: test run-unit-test: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

On Wed, Apr 12, 2023 at 3:53 PM Leo Antunes  wrote:

> Sorry for the late reply. My laptop decided it was a good time to break,
> so I'll have even less time to work on this in the next few days/weeks :/
>
> --- Original Message ---
> On Sunday, March 26th, 2023 at 22:07, Reinhard Tartler 
> wrote:
>
> > Sounds good.
> >
> > I'm happy to take on the easier dependencies, such as pkg/browser or
> jellydator/ttlcache.
>
>
> That would be a huge help already!
>
>
https://tracker.debian.org/pkg/golang-github-jellydator-ttlcache
https://tracker.debian.org/pkg/golang-github-pkg-browser

you're welcome :-)

-- unfortunately, I made a mistake: I packaged version 3 of
jellydator-ttlcache, which has a significantly different API than version2,
which sigstore currently uses.

I'm considering either downgrading the package, or making sigstore use v3.
I guess the latter is better in the long term. Mh.


> > But the dependency on boulder is giving me a massive headache. It is
> really unfortunate that they chose to use such a heavy dependency for a
> rather simple task (goodkey). What are your thoughts on resolving this?
>
>
> I didn't dive deep into the code, but I suspect we can patch away the
> boulder dep. I'll gladly give it a try as soon as I have a workable laptop
> again (but feel free to jump in if you find the time!)
>
>
I think this patch should do it:

modified   pkg/cryptoutils/publickey.go
@@ -16,7 +16,6 @@
 package cryptoutils

 import (
- "context"
  "crypto"
  "crypto/ecdsa"
  "crypto/ed25519"
@@ -30,8 +29,6 @@ import (
  "encoding/pem"
  "errors"
  "fmt"
-
- "github.com/letsencrypt/boulder/goodkey"
 )

 const (
@@ -139,20 +136,8 @@ func genErrMsg(first, second crypto.PublicKey, keyType
string) string {
 func ValidatePubKey(pub crypto.PublicKey) error {
  switch pk := pub.(type) {
  case *rsa.PublicKey:
- // goodkey policy enforces:
- // * Size of key: 2048 <= size <= 4096, size % 8 = 0
- // * Exponent E = 65537 (Default exponent for OpenSSL and Golang)
- // * Small primes check for modulus
- // * Weak keys generated by Infineon hardware (see
https://crocs.fi.muni.cz/public/papers/rsa_ccs17)
- // * Key is easily factored with Fermat's factorization method
- p, err := goodkey.NewKeyPolicy(&goodkey.Config{FermatRounds: 100}, nil)
- if err != nil {
- // Should not occur, only chances to return errors are if fermat rounds
- // are <0 or when loading blocked/weak keys from disk (not used here)
- return errors.New("unable to initialize key policy")
- }
- // ctx is unused
- return p.GoodKey(context.Background(), pub)
+ // Avoid dependency on Goodkey for debian
+ return nil;
  case *ecdsa.PublicKey:
  // Unable to use goodkey policy because P-521 curve is not supported
  return validateEcdsaKey(pk)
modified   pkg/cryptoutils/publickey_test.go
@@ -183,6 +183,8 @@ func TestValidatePubKeyUnsupported(t *testing.T) {
 }

 func TestValidatePubKeyRsa(t *testing.T) {
+ t.Skip("Validations disabled for Debian")
+
  // Validate common RSA key sizes
  for _, bits := range []int{2048, 3072, 4096} {
  priv, err := rsa.GenerateKey(rand.Reader, bits)



-- 
regards,
Reinhard

Bug#996892: cyrus-sasl2: consider handling as system library

[Philipp Hahn]

Hello fellow DDs,

Looking at 
[cyrus-sasl/COPYING](https://github.com/cyrusimap/cyrus-sasl/blob/master/COPYING) 
I find this text:



* 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer. 
 *

 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The name "Carnegie Mellon University" must not be used to
 *endorse or promote products derived from this software without
 *prior written permission. For permission or any other legal
 *details, please contact 

...

 * 4. Redistributions of any form whatsoever must retain the following
 *acknowledgment:
 *"This product includes software developed by …."


This looks like 
[BSD-3-Clause-Attribution](https://spdx.org/licenses/BSD-3-Clause-Attribution.html) 
to me:



1. Redistributions of source code must retain the above copyright notice, this 
list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, 
this list of conditions and the following disclaimer in the documentation 
and/or other materials provided with the distribution.
> 3. Neither the name of the copyright holder nor the names of its 
contributors may be used to endorse or promote products derived from 
this software without specific prior written permission.


4. Redistributions of any form whatsoever must retain the following 
acknowledgment: 'This product includes software developed by the ….'



Not [BSD-4-Clause](https://spdx.org/licenses/BSD-4-Clause.html) which 
differs in 3 and 4:



3. All advertising materials mentioning features or use of this software must 
display the following acknowledgement:
This product includes software developed by the organization.

4. Neither the name of the copyright holder nor the names the copyright holder 
nor the names of its contributors may be used to endorse or promote products 
derived from this software without specific prior written permission.



See 
 
for a nicer comparison.


Looking at 
[popcon](https://qa.debian.org/popcon.php?package=cyrus-sasl2) I see the 
library to be install almost everywhere, which IMHO would qualify it as 
a "system library":



libsasl2-2  209141  99.40%  86


What needs to be done to get this bug move forward?

Thanks
pmhahn
--
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen

📞 +49-421-22232-57
🖶 +49-421-22232-99

✉️ h...@univention.de
🌐 https://www.univention.de/

Geschäftsführer: Peter H. Ganten, Stefan Gohmann
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#1029628: pkgconf: add testsuite from old pkg-config

[Gianfranco Costamagna]

Hello,

What about starting with a really simple and easy basic testsuite?
(we can also maybe require build to make sure a other packages are not 
regressing the build testsuite!)

Tests: basic
Depends: libsdl2-dev, @builddeps@
Restrictions: build-needed


cat debian/tests/basic
#!/bin/sh

set -eux

if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
else
CROSS_COMPILE=
fi

"${CROSS_COMPILE}pkg-config" --cflags --libs sdl2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034332: Occasional garbled Chinese pdf lines

[Jonas Smedegaard]

Control: tag -1 + unreproducible moreinfo

Hi Jidanni,

Quoting Dan Jacobson (2023-04-13 02:56:11)
> Here we see that there is a bug in the pdf creator:
> { echo 哈哈 郵編123 哈哈; echo 郵編123;} > /tmp/n.txt
> abiword --to=pdf /tmp/n.txt
> When viewing the resultant pdf, one line is garbled.
> 
> But if I use
> LC_ALL=C abiword --to=pdf /tmp/n.txt
> then all worked fine.

Sorry, I cannot reproduce, neither consistently using my personal locale
da_DK.UTF-8 nor consistently using zh_TW.UTF-8.

Is the contents of the shell-generated plaintext file identical to a
plaintext file generated while having LC_ALL=C.UTF-8 ?

Do abiword produce garbled or correct PDF if instead of (your complex
personal settings or) C the locale is generally set to C.UTF-8?

If the bug is only reproducible on your system, then it is highly
unlikely to be addressed upstream (nor by custom-patching in Debian).
So I recommend that you try create a minimally reproducible test - e.g.
a shell script that when executed in a pristine Debian system account
with locale C.UTF-8 (i.e. where any unusual locales are exported within
the shell script, assuming only that locales are generated on the host)
reproduce the problem.

> I didn't see anything on the abiword man page about controling what fonts get 
> used.

Smells independent from the above reported bug, in that changes to
locale is unlikely to involve changes to fonts (and you did not mention
above any changes to fonts either).

This might help: http://abiword.com/help/en-US/howto/howtonormaltemplate.html

Please file separate bugreports for each issue.

Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#1034350: gnutls28: autopkgtest regression everywhere except amd64: src/nonexist-builddir/gnutls_ktls: not found

[Paul Gevers]

Source: gnutls28
Version: 3.7.9-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails everywhere but 
on amd64. If I understand correctly, the 32 bits architecture failures 
are due to datefudge/faketime (bug 1031553) and started in September 
2022. The 64 bits architectures started to fail more recently in March 
2023. Because some hosts on ci.debian.net have been upgraded to bookworm 
recently, I was fearing/suspecting it might be kernel related, but 
running the test on an amd64/bookworm kernel passes. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/g/gnutls28/32726537/log.gz

https://ci.debian.net/data/autopkgtest/testing/arm64/g/gnutls28/32726537/log.gz

running [83]../../tests/ktls.sh ...
/proc/modules:tls 114688 0 - Live 0x
../../tests/ktls.sh: 40: 
/tmp/autopkgtest-lxc.p44qznnk/downtmp/build.Wzp/src/nonexist-builddir/gnutls_ktls: 
not found

FAIL [83]../../tests/ktls.sh


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034332: Occasional garbled Chinese pdf lines

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2023-04-13 13:13:34)
> Control: tag -1 + unreproducible moreinfo
> 
> Hi Jidanni,
> 
> Quoting Dan Jacobson (2023-04-13 02:56:11)
> > Here we see that there is a bug in the pdf creator:
> > { echo 哈哈 郵編123 哈哈; echo 郵編123;} > /tmp/n.txt
> > abiword --to=pdf /tmp/n.txt
> > When viewing the resultant pdf, one line is garbled.
> > 
> > But if I use
> > LC_ALL=C abiword --to=pdf /tmp/n.txt
> > then all worked fine.
> 
> Sorry, I cannot reproduce, neither consistently using my personal locale
> da_DK.UTF-8 nor consistently using zh_TW.UTF-8.
> 
> Is the contents of the shell-generated plaintext file identical to a
> plaintext file generated while having LC_ALL=C.UTF-8 ?
> 
> Do abiword produce garbled or correct PDF if instead of (your complex
> personal settings or) C the locale is generally set to C.UTF-8?
> 
> If the bug is only reproducible on your system, then it is highly
> unlikely to be addressed upstream (nor by custom-patching in Debian).
> So I recommend that you try create a minimally reproducible test - e.g.
> a shell script that when executed in a pristine Debian system account
> with locale C.UTF-8 (i.e. where any unusual locales are exported within
> the shell script, assuming only that locales are generated on the host)
> reproduce the problem.
> 
> > I didn't see anything on the abiword man page about controling what fonts 
> > get used.
> 
> Smells independent from the above reported bug, in that changes to
> locale is unlikely to involve changes to fonts (and you did not mention
> above any changes to fonts either).
> 
> This might help: http://abiword.com/help/en-US/howto/howtonormaltemplate.html
> 
> Please file separate bugreports for each issue.

Ohh, might be related after all: Looking below
/usr/share/abiword-3.0/templates there are locale-specific normal.awt-*
files, which I guess mean that a unusual locale would cause the file
normal.awt to be used, and that that file might be rarely tested because
commonly it is shadowed by a locale-specific file.

Hope that helps.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#1034351: autopkgtest-build-* tools should check their dependencies at startup

[Paul Gevers]

Package: autopkgtest

Hi,

I was just helping somebody on IRC to debug the failure of 
autopkgtest-build-qemu and several of the failures were missing 
dependencies. Now, they are *Suggests* in the binary Dependencies of 
bin:autopkgtest, which I think is fine, but that doesn't really help 
people spotting the problem quickly.


I think it would help if the autopkgtest-build-* tools would check their 
requirements at startup and give a helpful error message in case tools 
are missing.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Source: golang-github-azure-go-autorest
Version: 14.2.0+git20220726.711dde1-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on arm64 only 
since July 2022. Can you please investigate the situation and fix it? I 
copied some of the output at the bottom of this report. I'd like to note 
that our arm64 workers are all hosted in China, which *might* be of 
relevance as this test seems to be testing against the internet (I could 
be wrong). If it is testing against the internet, it requires the 
needs-internet restriction (although that currently doesn't change 
anything).


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32818576/log.gz

=== RUN   TestLogReqRespNoBody
logger_test.go:90: request header doesn't match: 
(2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET 
https://fakething/dot/com

--- FAIL: TestLogReqRespNoBody (0.01s)
=== RUN   TestLogReqRespWithBody
logger_test.go:155: request header doesn't match: 
(2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET 
https://fakething/dot/com

--- FAIL: TestLogReqRespWithBody (0.01s)
FAIL
FAILgithub.com/Azure/go-autorest/logger 0.017s


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034353: mime-type: image/jpeg instead of image/jls

[Mathieu Malaterre]

Source: file
Version: 1:5.44-3

Steps:

% wget -O filelogo.jls
"https://bugs.astron.com/file_download.php?file_id=214&type=bug";
% file --mime-type filelogo.jls
filelogo.jls: image/jpeg

However upstream claims this is fixed since 5.41, some kind of regression ?

* https://bugs.astron.com/view.php?id=252

Bug#996892: cyrus-sasl2: consider handling as system library

[Bastian Germann]

Hi Philipp,

Thanks for clarifying that. There is one file in cyrus-sasl2 that is licensed under BSD-4-clause-KTH (which really has 
an advertisement clause), which we can get rid of; see https://github.com/cyrusimap/cyrus-sasl/pull/724.


The OpenSSL license can be eliminated by repackaging.

This leaves us with the two supposedly GPL-incompatible licenses 
BSD-3-Clause-Attribution and RSA-MD.

Thanks for taking care of this,
Bastian

Bug#972439: RFP: tailscale -- wireguard overlay network manager (client)

[ilf]

It would be great to have tailscale in Debian!

I asked upstream tailscale, but it looks like they won't do it 
themselves: https://github.com/tailscale/tailscale/issues/7847


Anyone else up for packaging it?

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

Bug#1034015: exim4: exim paniclog on lenovo has non-zero size

[Wensheng Xie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

在 2023-04-09星期日的 15:14 +0200，Marc Haber写道：
> exim paniclog
Thank you. paniclog removed

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEMNkEN5bfqrr/ykm8AZx+p0DYjwsFAmQ3+poACgkQAZx+p0DY
jwvm/gv8C7MODD8ocExFJ6Yyoz7tHLpK+f/wYxQelb6GHuh6nbC3dadxI8SEridg
PDT8/9h5HfYYt7KsxsJOLmhDswjpnOur88QoK+U4673uAk/x+JOy4Tr4XyKFZfiu
wYSsNJBzs/1qcGLIj6umkqFezsJ4Na0ICG9C3/ZxUpRnD/Uax/l2WOV3BCG9Sd9X
eHxCkssnB56bHNbqNZDNO/34mY6+qllNUOsonojWW9zBAIK2x961EifgIibs8f/k
Fp3397nGgqCaaveg3klPp+EHqJNEkmBXDFS3v9Vzq7FUYFkxrq97ZAAPOc14Gq4v
0N+D8vhwFCFpzCfgsK1iQXPlh4MqRI7UnbACS1TUijBJ52nG1n01EBUuL+t2fJox
mryRj9QCG0Wm3fZTx4YPXwBiPToBZMqRGGHYZ9cf/7pOUp42XRQXwIA11m2hYfce
7PpAet01JBXfECIEenTgN1KSpPEj0ZoaW5KQd5wmaFPax97UqIFYZSoLcPYNbHDJ
XVHa2MCi
=NhWB
-END PGP SIGNATURE-

Bug#1034354: unblock: liblrdf/0.6.1-4

[Sebastian Ramacher]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package liblrdf

[ Reason ]
Packages that are MA: same (such as gstreamer1.0-plugins-bad) gained a
dependency on liblrdf0 which is missing MA: same in bookworm. This is
fixed in unstable.

[ Impact ]
Packages that are expected to be MA: same fail to meet the expectation.

[ Tests ]
The fix is in unstable for 26 days without reported regressions.

[ Risks ]
None as far as I can tell.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock liblrdf/0.6.1-4

Cheers
-- 
Sebastian Ramacher
--- liblrdf-0.6.1/debian/changelog  2022-10-23 17:57:01.0 +
+++ liblrdf-0.6.1/debian/changelog  2023-03-17 21:17:37.0 +
@@ -1,3 +1,12 @@
+liblrdf (0.6.1-4) unstable; urgency=medium
+
+  * Team upload
+
+  [ Jan Kriho ]
+  * Use Multi-Arch: same (Closes: #1032832)
+
+ -- Sebastian Ramacher   Fri, 17 Mar 2023 22:17:37 +0100
+
 liblrdf (0.6.1-3) unstable; urgency=medium
 
   [ Jonas Smedegaard ]
diff -Nru liblrdf-0.6.1/debian/control liblrdf-0.6.1/debian/control
--- liblrdf-0.6.1/debian/control2022-10-23 17:54:59.0 +
+++ liblrdf-0.6.1/debian/control2023-03-17 21:17:16.0 +
@@ -41,6 +41,7 @@
 Package: liblrdf0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Suggests: liblrdf0-dev

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Shengjing Zhu]

On Thu, Apr 13, 2023 at 8:12 PM Paul Gevers  wrote:
>
> === RUN   TestLogReqRespNoBody
>  logger_test.go:90: request header doesn't match:
> (2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET
> https://fakething/dot/com
> --- FAIL: TestLogReqRespNoBody (0.01s)
> === RUN   TestLogReqRespWithBody
>  logger_test.go:155: request header doesn't match:
> (2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET
> https://fakething/dot/com
> --- FAIL: TestLogReqRespWithBody (0.01s)
> FAIL
> FAILgithub.com/Azure/go-autorest/logger 0.017s

Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?

-- 
Shengjing Zhu

Bug#900928: deps

[matthias . geiger1024]

Hi Jonas,



> Is your work available publicly somewhere?
>
Yes. The matrix-sdk depends mainly on ruma which is 80% packaged in the 
debcargo-conf repo.
The GTK-rs update is visible here: 
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/463 and most 
of the *debs are here: 
https://salsa.debian.org/werdahias/obfuscate-wip/-/tree/debs?ref_type=heads 

Stuff still missing: ashpd, oo7 and matrix-sdk. The former two are GTK related 
and I will package them as soon as the GTK update gets uploaded because I need 
them anyway. the latter needs ruma which I have constantly been working on.
comrak isn't needed anymore apparently.

wrt maintaining: I thought all GNOME circle apps should be also maintained 
within the GNOME team, maybe even in a separate workspace, but that is just my 
opinion (especially since I maintain three of those programs that way). You're 
free to maintain it however you see fit, I didn't want to impose.

Regarding the "credit": also maybe came off wrong. My POV: I made a list of all 
the fractal deps and slowly started working those off. I put in a lot of effort 
to get the GTK-rs update underway and the rest of the fractal stuff like ruma. 
I guess that resulted in me thinking "Well, I do want some of the credit for 
working on fractal!" And I think while that may seem selfish I still deserve 
that as I put in constant work towaord the goal of packaging fractal. It's not 
my intention to come off that way but I think you get my point.

Honestly: Feel free to do whatever you think best for debian. The GTK stack 
will land in trixie and then it's straightforward to finish packaging. Please 
don't interfere with a) the gtk stack and b) the rest of the ruma stack,
I kinda don't care about the rest. (not trying to start a side discussion which 
rust packaging is better; if I have an overview for both stacks that makes 
things easier)

Sorry for a bit of an rant and the wall of text,

I hope this clears things up.

regards,

---
Matthias Geiger (werdahias)

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Marco d'Itri]

On Apr 13, Hans-Christoph Steiner  wrote:

> Well, I'm a Debian user since 1998 and I know Debian, but I don't know Xen
> or how that /lib/modules mount even got there.  I suppose it could be solved
> via documentation, but I don't know how to fix this, so I have a production
> server stuck with an incomplete bookworm upgrade.
Me neither, I think that this kind of Xen setup falls squarely in the 
retrocomputing area at this point.
I suggest that you unmount /lib/modules/, continue the upgrade and see 
what happens after a reboot. I expect that it will work just fine.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Hans-Christoph Steiner]

Marco d'Itri:

Control: severity -1 normal

On Apr 13, Hans-Christoph Steiner  wrote:


I have some VPSes which are based on Xen, so the kernel comes from the host,
and the VPS has no kernel installed.  /lib/modules is mounted but not via
/etc/fstab.  When trying to upgrade from bullseye to bookworm, I get:

Then fix it as suggested, but not via fstab?
Looks like this is a documentation issue.
What do you think should be changed here, exactly?


Well, I'm a Debian user since 1998 and I know Debian, but I don't know Xen or 
how that /lib/modules mount even got there.  I suppose it could be solved via 
documentation, but I don't know how to fix this, so I have a production server 
stuck with an incomplete bookworm upgrade.

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Hans-Christoph Steiner]

Marco d'Itri:

On Apr 13, Hans-Christoph Steiner  wrote:


Well, I'm a Debian user since 1998 and I know Debian, but I don't know Xen
or how that /lib/modules mount even got there.  I suppose it could be solved
via documentation, but I don't know how to fix this, so I have a production
server stuck with an incomplete bookworm upgrade.

>

Me neither, I think that this kind of Xen setup falls squarely in the
retrocomputing area at this point.
I suggest that you unmount /lib/modules/, continue the upgrade and see
what happens after a reboot. I expect that it will work just fine.


I emailed the support for more info.  In the meantime I did:

# service systemd-udevd stop
# umount /lib/modules
# apt dist-upgrade
# mount | grep /lib
modules on /usr/lib/modules type tmpfs (rw,relatime,size=102400k,mode=700)
# reboot
Failed to connect to bus: No such file or directory
#

So I rebooted from the VPS provider's console, and it seems to have worked.

Bug#1034355: cpu-x(1) man page: incorrect short options and missing options

[Vincent Lefevre]

Package: cpu-x
Version: 4.5.2-2
Severity: normal

The short options listed in the cpu-x(1) man page are incorrect.
For instance, it says:

   Available options to be used as :

   -g, --gtk
   Start graphical user interface (GUI) (default).

   -n, --ncurses
   Start text-based user interface (TUI).

   -d, --dump
   Dump all data on standard output and exit.

   -D, --dmidecode
   Run embedded command dmidecode and exit.

   Available options to be used as :

   -a, --tab
   Set default tab (integer).
[...]

but "cpu-x --help" says:

Available DISPLAY:
  -G, --gtkStart graphical user interface (GUI) (default)
  -N, --ncursesStart text-based user interface (TUI)
  -D, --dump   Dump all data on standard output and exit
  -M, --dmidecode  Run embedded command dmidecode and exit
  -B, --bandwidth  Run embedded command bandwidth and exit

Available OPTIONS:
  -r, --refreshSet custom time between two refreshes (in seconds)
  -t, --tabSet default tab (integer)
  -p, --type   Select core type to monitor (integer)
  -c, --core   Select CPU core to monitor (integer)
  -b, --cachetest  Set custom bandwidth test for CPU caches speed (integer)
  -g, --gpuSelect default graphic card (integer)
  -d, --daemon Start and connect to daemon
  -v, --verboseVerbose output
[...]

and some options are missing in the man page:

  -B, --bandwidth  Run embedded command bandwidth and exit
  -p, --type   Select core type to monitor (integer)
  -c, --core   Select CPU core to monitor (integer)
  -b, --cachetest  Set custom bandwidth test for CPU caches speed (integer)
  -g, --gpuSelect default graphic card (integer)
  -d, --daemon Start and connect to daemon

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 cpu-x depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libcpuid16   0.6.2+repack1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgl1   1.6.0-1
ii  libglfw3 3.3.8-1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libncursesw6 6.4-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpci3  1:3.9.0-4
ii  libproc2-0   2:4.0.3-1
ii  libtinfo66.4-2
ii  libvulkan1   1.3.239.0-1
ii  procps   2:4.0.3-1

cpu-x recommends no packages.

cpu-x suggests no packages.

-- no debconf information

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

Bug#1034356: gnome-shell: Frozen UI and massive log flodding

[H . -Dirk Schmitt]

Package: gnome-shell
Version: 43.3-3
Severity: important
X-Debbugs-Cc: none, H.-Dirk Schmitt 

After migration to bookworm on 2 different machines the gnome-shell was frozen 
in the last week.
Via SSH – or switching to the good old console – I was able to see that 
journald was running with 100% cpu at that time.
The problem was recoverable by sending SIGHUP to the gnome-shell process – 
`pkill -1 gnome-shell`

Analysing the log I see over and over repeating a stack trace message – but 
without the usual stack information:
Apr 13 14:50:39 schroeder gnome-shell[6317]: == Stack trace for context 
0x556ad68a9170 ==

>From this time on – till the gnome-shell restart at 14:54:05 – I count this 
>message 182187 times in 3:26 min.

This machine was running for several days.
The other machine with a similar problem was running for ~2 hours.

The log messages from the gnome-shell are attached.


log-extract.xz
Description: application/xz


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:de:en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.37-2
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-2
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.3-5
ii  gir1.2-nm-1.01.42.4-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-2
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.40.0-3
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.3-3
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-2
ii  libedataserver-1.2-273.46.4-2
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-1
ii  libglib2.0-bin   2.74.6-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.37-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.3-5
ii  libnm0   1.42.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  122-3
ii  libpolkit-gobject-1-0122-3
ii  libpulse-mainloop

Bug#1034262: buffer overflow on peculiar drive

[Martijn van Brummelen]

Hi Antoine,

Thank for this patch , will upload/fix it soon after I checked if the 
length is still sufficient or not.


Kind regards,
Martijn van Brummelen
On 2023-04-11 22:20, Antoine Beaupre wrote:

Package: nwipe
Version: 0.34-1+b1
Severity: normal
Tags: patch

I've used nwipe probably dozens of times on various times, and it
works fairly reliably. So I was surprised to find out it chokes on
this tiny little SSD drive here:

anarcat@angela:~$ sudo nwipe /dev/sdc
*** buffer overflow detected ***: terminated
Aborted
anarcat@angela:~[SIGABRT]$

Well isn't this odd! This is a fiarly normal drive:

anarcat@angela:~$ sudo smartctl -i -qnoserial /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-7-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron RealSSD m4/C400/P400
Device Model: M4-CT512M4SSD1
Firmware Version: 040H
User Capacity:512 110 190 592 bytes [512 GB]
Sector Size:  512 bytes logical/physical
Rotation Rate:Solid State Device
Form Factor:  2.5 inches
TRIM Command: Available, deterministic
Device is:In smartctl database 7.3/5319
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:Tue Apr 11 15:42:51 2023 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

And speaking of smartctl, I suspect it's where nwipe chokes, because
as it turns out it crashes right after calling it, according to
strace:


anarcat@angela:~$ sudo strace -s8192 nwipe /dev/sdc
execve("/usr/sbin/nwipe", ["nwipe", "/dev/sdc"], 0x7ffda312d030 /* 15
vars */) = 0
brk(NULL)   = 0x55afbf726000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fbb351ae000
[...]
read(3, "smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-7-amd64]
(local build)\nCopyright (C) 2002-22, Bruce Allen, Christian Franke,
www.smartmontools.org\n\n", 4096) = 150
read(3, "=== START OF INFORMATION SECTION ===\nModel Family:
Crucial/Micron RealSSD m4/C400/P400\nDevice Model:
M4-CT512M4SSD1\nSerial Number:REDACTED\nLU WWN Device Id: 5 00a075
109210beb\nFirmware Version: 040H\n", 4096) = 223
read(3, "User Capacity:
512\342\200\257110\342\200\257190\342\200\257592 bytes [512
GB]\nSector Size:  512 bytes logical/physical\nRotation Rate:
Solid State Device\n", 4096) = 137
read(3, "Form Factor:  2.5 inches\nTRIM Command: Available,
deterministic\nDevice is:In smartctl database 7.3/5319\nATA
Version is:   ACS-2, ATA8-ACS T13/1699-D revision 6\nSATA Version is:
SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)\nLocal Time is:Tue Apr 11
15:44:34 2023 EDT\nSMART support is: Available - device has SMART
capability.\nSMART support is: Enabled\n\n", 4096) = 366
read(3, "", 4096)   = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=72484,
si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
close(3)= 0
wait4(72484, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 72484
writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow
detected", iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}],
3*** buffer overflow detected ***: terminated
) = 45
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fbb351ad000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()= 72472
getpid()= 72472
tgkill(72472, 72472, SIGABRT)   = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=72472, 
si_uid=0} ---

+++ killed by SIGABRT +++
Aborted

Of you look at the spaces in the "User Capacity" field more closely,
you'll notice it's actually a little odd. Those are not mere spaces in
those thousands separators, they are actually `U+202F NARROW NO-BREAK
SPACE` (represented by \342\200\257 in strace), according to
unicode(1). That, in itself, shouldn't be a problem: my terminal,
foot(1), is handling that fine, for example. But I bet it's the cause
of the overflow here.

Looking at gdb:

(gdb) bt
#0  __pthread_kill_implementation (threadid=,
signo=signo@entry=6,
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x77d8dd2f in __pthread_kill_internal (signo=6,
threadid=) at ./nptl/pthread_kill.c:78
#2  0x77d3eef2 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/posix/raise.c:26
#3  0x77d29472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77d822d0 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x77e9c210 "*** %s ***: terminated\n")
at ../sysdeps/posix/libc_fatal.c:155
#5  0x77e1af32 in __GI___fortify_fail (
msg=msg@entry=0x77e9c1b6 "buffer overflow detected")
at ./debug/fortify_fail.c:26
#6  0x77e19a40 in __GI___chk_fail () at ./debug/chk_fail.c:28
#7  0x77e19322 in __strcpy_chk

Bug#1034357: cpu-x(1) man page: incorrect information about cpu-x_polkit

[Vincent Lefevre]

Package: cpu-x
Version: 4.5.2-2
Severity: normal

The cpu-x(1) man page says:

SYNOPSIS
   cpu-x [  ] [  ] cpu-x_polkit [  ] [  
]

and in the DESCRIPTION section: "If your desktop session has PolicyKit
support, you can launch cpu-x_polkit."

The SYNOPSIS is badly formatted, but anyway, the cpu-x package does not
ship a cpu-x_polkit program. So this is incorrect anyway.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 cpu-x depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libcpuid16   0.6.2+repack1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgl1   1.6.0-1
ii  libglfw3 3.3.8-1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libncursesw6 6.4-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpci3  1:3.9.0-4
ii  libproc2-0   2:4.0.3-1
ii  libtinfo66.4-2
ii  libvulkan1   1.3.239.0-1
ii  procps   2:4.0.3-1

cpu-x recommends no packages.

cpu-x suggests no packages.

-- no debconf information

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

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Hi Shengjing,

On 13-04-2023 14:56, Shengjing Zhu wrote:

On Thu, Apr 13, 2023 at 8:12 PM Paul Gevers  wrote:


=== RUN   TestLogReqRespNoBody
  logger_test.go:90: request header doesn't match:
(2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET
https://fakething/dot/com
--- FAIL: TestLogReqRespNoBody (0.01s)
=== RUN   TestLogReqRespWithBody
  logger_test.go:155: request header doesn't match:
(2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET
https://fakething/dot/com
--- FAIL: TestLogReqRespWithBody (0.01s)
FAIL
FAILgithub.com/Azure/go-autorest/logger 0.017s


Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?


In my opinion we should do both. You don't want people to go figure this 
out if they try to run the tests themselves in their own timezone. Also, 
we are only in control of the hosts that Debian uses. Any downstream may 
run into the same problems.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034357: cpu-x(1) man page: incorrect information about cpu-x_polkit

[Vincent Lefevre]

On 2023-04-13 15:28:50 +0200, Vincent Lefevre wrote:
> The cpu-x(1) man page says:
> 
> SYNOPSIS
>cpu-x [  ] [  ] cpu-x_polkit [  ] [ 
>  ]
> 
> and in the DESCRIPTION section: "If your desktop session has PolicyKit
> support, you can launch cpu-x_polkit."
> 
> The SYNOPSIS is badly formatted, but anyway, the cpu-x package does not
> ship a cpu-x_polkit program. So this is incorrect anyway.

I can see in the changelog.Debian.gz file that the cpu-x_polkit.1
man page was dropped in 2020:

cpu-x (4.0.1-1) unstable; urgency=medium
[...]
  * man pages:
+ Drop cpu-x_polkit.1 man page. Obsolete.

But what about the utility?

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

Bug#1034358: libvncclient1: license conflict with libsasl2

[Bastian Germann]

Package: libvncclient1
Version: 0.9.14+dfsg-1
Severity: serious

Hi,

libvncclient1 depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the 
RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (libvncclient1's license).

There are several possible solutions to this problem:

1) Build without SASL support. The affected symbols GetTLSCipherBits, HandleSASLAuth, and ReadFromSASL are not used by 
any of the reverse dependencies.


2) Support my request at #996892.

3) Ask upstream to add a license exception for libsasl2-2, similar to the one 
that was required by Debian for OpenSSL
for a long time.

Thanks for your consideration,
Bastian

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Hi,

On 13-04-2023 15:39, Paul Gevers wrote:

Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?


In my opinion we should do both. You don't want people to go figure this 
out if they try to run the tests themselves in their own timezone. Also, 
we are only in control of the hosts that Debian uses. Any downstream may 
run into the same problems.


I have changed the timezone on all our hosts, but your test still fails.

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32859920/log.gz 
is the test I just scheduled. It failed in the same way.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034095: mount options could be cause

[James Abernathy]

I reran an install but this time when I remounted the @ and @home
subvolumes I only used the default, compress=zstd, and subvol= options.

This time it worked. After booting successfully, I edited fstab to add in
noatime and it still worked.  At this point. it still could be the discard
or ssd options.

I'd look at what has changed in this area since Debian 11.

Bug#1034322:

[Benji Dial]

I found a report of a similar thing happening once before on Ubuntu: 
https://github.com/racket/racket/issues/4169

The issue there was that libncurses-dev was not installed while Racket was 
being built. Racket's build system apparently checks for the presence of the 
ncurses headers and then disables certain features if it can't find those. I 
don't know enough about the Debian build system to see if that's what's 
happening here, but it might be a good starting point.

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Peter Green]

BTW, Fabian messages sent to bug reports are not sent to the sumbitter
by default, if you are replying to a submitter you need to put them
in to/cc or they may not see your reply.

Fabian Grünbichler wrote:

hope that's okay for the time being :) feel free to ping the bug if you
have the feeling that the situation has changed!


I just took a quick look at this.

It seems that ron, sniffglue, ureq and the sequoia packages are the only
ones that still depend on 0.13 upstream, most packages now seem to be on
-21 with a few still on 0.20, I think the changes between 0.20 and 0.21
are quite small and it probablly makes more sense to go to 0.21 directly.

I've filed a bug with sequoia upstream. I haven't investigated the other
packages at this time.

https://gitlab.com/sequoia-pgp/sequoia/-/issues/1002

Bug#1034359: Regression finding system certificates

[Gabriel]

Package: libcurl3-nss
Version: 7.88.1-5

Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:

curl (7.88.1-4) unstable; urgency=medium

  * d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.

Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.

libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.

Here is a way to test the regression:
debbisect -v --cache=./cache \
   
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
  20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"'

Bug#1034314: Also fixed by moving to p11-kit..

[David Härdeman]

And a more complete fix would be this MR:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/208

Bug#1034360: ITP: supersonic -- A lightweight cross-platform desktop client for Subsonic music servers

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: supersonic
  Version : 0.1.0~beta-1
  Upstream Author : Drew Weymouth
* URL : https://github.com/dweymouth/supersonic
* License : GPL-3.0
  Programming Lang: Go
  Description : A lightweight cross-platform desktop client for Subsonic 
music servers

A lightweight cross-platform desktop client for Subsonic music servers
(Navidrome, Gonic, Airsonic, etc).

Features

* Fast, lightweight, native UI
* High-quality gapless audio playback powered by MPV, with optional
  audio exclusive mode
* ReplayGain support (depends on files being tagged on server)
* Infinite scrolling
* Scrobble plays to server, with configurable criteria
* Browse by albums, artists, genres, playlists
* Album and playlist views with tracklist and cover image
* Artist view with biography, image, similar artists, and discography
* Create, play, and update playlists
* Configure visible tracklist columns
* Set/unset favorite and browse by favorite albums, artists, and
  songs
* View and edit play queue (add and remove tracks; reorder support
  coming soon)
* Shuffle and repeat playback modes (partial; shuffle album,
  playlist, artist radio, random songs)



We already have a Subsonic client in Debian (sublime-music, Python),
packaged by my friend pollo. But in my experience, sublime is really
slow and clunky, so much that it barely works at all.

In comparison, Supersonic is, well, supersonic! I've tested the git
build and it just works flawlessly, really impressive stuff.

There's a handful of limitations though:

 * Set filters in albums browsing view (planned)
 * Browse by folders (planned)
 * Multi-server support (planned)
 * Download songs, albums or playlists (planned)
 * Cast to uPnP/DLNA devices (likely planned)
 * Built-in multi-band equalizer (eventully planned)
 * Offline mode (eventually planned)
 * Lyrics support (eventually planned)
 * iOS/Android support (maybe eventually planned)

The "download" part is probably the most important part for me, but for
now I can actually live without it...

Dependency-wise, however, it's another story altogether. Supersonic is
built with a GUI framework called Fyne which is, as far as I know, not
at all packaged in Debian and *that* is quite a chunk of stuff to
package:

https://github.com/fyne-io/fyne/blob/master/go.mod

I count 20+ deps there that need to at least be checked to see if
they're in Debian. Faithful to itself, dh-make-golang crashes on
estimate, so it's unclear to me how easy packaging that would be.

Other than Fyne, it looks like the following packages are also missing:

 * github.com/20after4/configdir
 * github.com/dweymouth/go-mpv
 * github.com/dweymouth/go-subsonic

The latter two being libraries made by the same author, presumably
specifically for Supersonic, but that could possibly be used by other
packages of course...

The first one is kind of odd. There's another configdir package in
Debian (https://github.com/shibukawa/configdir) and it *looks* kind of
similar if you squinte a little, but their git history doesn't seem
related as far as GitHub is concerned. 20after4/configdir is also a fork
of kirsle/configdir, also unrelated. It looks like two similar
implementations (complete with the same filename) but with completely
different *actual* implementation. Epic.

Anyway, not even close to being packaged, but I thought I'd throw this
one out there.

Bug#900928: deps

[Jonas Smedegaard]

Hi Matthias,

[quoting previous private post to help establish context]

Quoting matthias.geiger1...@tutanota.de (2023-03-14 11:39:30)
> I wanted to discuss fractal. I also have a somewhat related interest to it. I 
> have been constantly working on it. My wip-gtk branch covers most of its 
> missing dependencies, so the big chunks missing are the matrix sdk and 
> comrak. I have been constantly working on those, too. I'd like fractal to be 
> maintained within the GNOME team since 1) it uses the GTK stack and 2) is 
> also a circle app. Since I also put in some effort I also would like to be 
> included as uploader. I think this is fair since now 80% of the dependencies 
> are covered.

Quoting matthias.geiger1...@tutanota.de (2023-04-13 14:57:41)
> > Is your work available publicly somewhere?
> >
> Yes. The matrix-sdk depends mainly on ruma which is 80% packaged in the 
> debcargo-conf repo.
> The GTK-rs update is visible here: 
> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/463 and 
> most of the *debs are here: 
> https://salsa.debian.org/werdahias/obfuscate-wip/-/tree/debs?ref_type=heads 
> 
> Stuff still missing: ashpd, oo7 and matrix-sdk. The former two are GTK 
> related and I will package them as soon as the GTK update gets uploaded 
> because I need them anyway. the latter needs ruma which I have constantly 
> been working on.
> comrak isn't needed anymore apparently.

Ah, makes sense now.  I thought you meant that you mean a wip-gtk branch
of the fractal packaging - i.e. this git repo:
https://salsa.debian.org/matrix-team/fractal

I appreciate your work on getting dependent Rust crates packaged for
Debian.

Personally I dislike the all-crates-in-one-git approach practiced in the
Rust team, and since the team has made it a "must" to do so within the
team I am not in that team at all.

Please consider using the Debian bugtracker to communicate "intents to
package" by filing an ITP bugreport for each single upstream project
that you work on packaging for Debian.  That enables us to keep track of
efforts targeted but not yet included formally into Debian - i.e. the
very purpose of that class of bugreports in the Debian bugtracker.

> wrt maintaining: I thought all GNOME circle apps should be also maintained 
> within the GNOME team, maybe even in a separate workspace, but that is just 
> my opinion (especially since I maintain three of those programs that way). 
> You're free to maintain it however you see fit, I didn't want to impose.

There are benefits of streamlining packaging within a team, but there
are also drawbacks of "optimizations" done within single teams.  There
is a real risk that packages may bitrot when maintained by a team with a
too large focus, as single packages at the edge of their focus may not
get adequate attention.

Obviously a package may lack attention *anywhere - we do not magically
get more hands by splitting the task into more smaller buckets.  But in
a smaller team mistreated packages has arguably a higher chance of
getting noticed - either by the team itself or by fellow Debian devopers
outside of the team or by users.

I mean, the task list for the security team is several pages long:
https://udd.debian.org/dmd/?team%2Bpkg-security%40tracker.debian.org#todo

...but that pales in comparison with the task list for the python team:
https://udd.debian.org/dmd.cgi?email1=team%2Bpython%40tracker.debian.org

There is no single obvious way to group packaging efforts.

Some teams streamline for one build systems (e.g. Rust team).  Some
teams streamline for one programming language, across build systems
(e.g. Perl, Java, and Python teams).  Some teams streamline for one
widget toolkit use, across languages (e.g. the GNOME team).  Some teams
streamline for one desktop environment, across widget toolkits (e.g.
LXQT team)

Most packaging teams at https://wiki.debian.org/Teams, however, have a
scope of concrete tools or a smaller collection of interrelated tools.

The GNOME team likely has a team policy that optimized towards projects
closely related to the GNOME core infrastructure, at the expense of
packages more loosely related to that.  That does not mean that all
projects close to GNOME is better off maintained by that team, only that
maintenance of the projects there benefits from that optimization - but
the backside is that maintainers are then expected to align with the
policy.

I don't use the GNOME desktop myself, and do not maintain a range of
packages tightly related to GNOME, so for me it would be more a burden
to engage in yet another team with maybe-peculiar-to-me policies.

> Regarding the "credit": also maybe came off wrong. My POV: I made a list of 
> all the fractal deps and slowly started working those off. I put in a lot of 
> effort to get the GTK-rs update underway and the rest of the fractal stuff 
> like ruma. I guess that resulted in me thinking "Well, I do want some of the 
> credit for working on fractal!" And I think while that may

Bug#1034361: haveged: autopkgtest fails on bookworm kernel: service fails to start

[Paul Gevers]

Source: haveged
Version: 1.9.14-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore, however, I have a strong suspicion that it points 
out that the package is broken. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/h/haveged/32696042/log.gz

autopkgtest [01:12:21]: test check-service: [---
failed
haveged service is not active
× haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; 
preset: enabled)
 Active: failed (Result: exit-code) since Fri 2023-04-07 01:12:20 
CST; 1s ago

   Duration: 1ms
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 1104 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=exited, status=225/NETWORK)

   Main PID: 1104 (code=exited, status=225/NETWORK)
CPU: 1ms
autopkgtest [01:12:21]: test check-service: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001793: mate-terminal: Wrong context menu font when using libvte-2.91-0[-common] 0.66.1-1 or 0.66.2-1

[Faidon Liambotis]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/mate-desktop/mate-terminal/issues/407

On Wed, Apr 12, 2023 at 10:37:19AM +0300, Faidon Liambotis wrote:
> On Thu, Dec 16, 2021 at 12:29:48PM +0100, Jasmin68k wrote:
> > Using Debian sid, running apt-get upgrade, which installed
> > libvte-2.91-0 and libvte-2.91-common 0.66.1-1.  After that, the
> > context (right-click) menu font in mate-terminal became monospace,
> > probably the same system wide monospace font, mate-terminal is using
> > for terminal output, instead of the regular system wide application
> > font.
> 
> This seems like a pretty serious UX issue. It also seems this was
> reported against Ubuntu, and fixed there with 1.26.0-1ubuntu2.
 
To add to this:

This seems to be upstream bug #407 fixed with upstream git commit
52fa45d4ca35e6be11ddee818eac84b768f15e22:
https://github.com/mate-desktop/mate-terminal/commit/52fa45d4ca35e6be11ddee818eac84b768f15e22

This was reported against Ubuntu with LP #1955505, and fixed in
1.26.0-1ubuntu2, with a backport of the aforementioned patch:
https://git.launchpad.net/ubuntu/+source/mate-terminal/commit/?id=a0d6e4951b3443ba849be12397cc02136e62b8d6

The fix seems to be, thankfully, a trivial one-liner :)

Faidon

Bug#1034346: more info

[Hans-Christoph Steiner]

Turns out the provider has a custom initrd that does the /lib/modules mount.  I 
don't know how common this is for VPS providers.  Could the "Probably this 
system is using User Mode Linux." prompt check if /lib/modules is in /etc/fstab, 
and if not, offer a different suggestion, e.g. something like the steps I took.

Bug#900928: deps

[matthias . geiger1024]

13. Apr. 2023, 17:39 von jo...@jones.dk:

>
> I appreciate your work on getting dependent Rust crates packaged for
> Debian.
>
thanks.

> Personally I dislike the all-crates-in-one-git approach practiced in the
> Rust team, and since the team has made it a "must" to do so within the
> team I am not in that team at all.
>
that's what I hoped to avoid.

> Please consider using the Debian bugtracker to communicate "intents to
> package" by filing an ITP bugreport for each single upstream project
> that you work on packaging for Debian.  
>
I won't do that for the rust crates (except binary ones) since that is the Rust 
Teams' policy. You choose not to do so. While I agree that a big monorepo  is 
not ideal the updating process is way more streamlined and that much crates 
can't all be maintained each in a seperate repo. That'd be madness.

>
> I don't use the GNOME desktop myself, and do not maintain a range of
> packages tightly related to GNOME, so for me it would be more a burden
> to engage in yet another team with maybe-peculiar-to-me policies.
>
they use a pretty standardized workflow (DEP 14). just a thought. 

> I totally get that.
>
> It pains me that when I ask about your work, you point me to what I
> perceive as a teamwork with little visibility of your efforts in it.
>
well it's always teamwork I guess;  I can claim the GTK update as my efforts. 

> Personally I suspect that some of the pain you have gone through in
> getting those packages in shape is due to the Rust team "streamlining",
> and I fear that the current blocker of bug#1017905 is a sign of that.
>
No. This is (while indirectly caused by me) not an issue imo, rather ftpmasters 
insisting the GTK-rs code generator needs to be shipped. (Note that this was 
fine before for some time) See the linked thread on the bug.


> What I think is best for Debian is that we collaborate more in Debian.
>
Agreed.

>
> In Debian as a whole, not (only) within teams.
>
> I dislike several things in the Rust team, and I suspect that
> bug#1017905 exists because of the Rust team insisting that Debian
> packaging should mimic upstream distribution design.  
>
See above.

> You apparently work in the Rust team.  If it works for you, then great -
> I am not saying you should leave.  But I am saying that I am torn
> between wanting to collaborate and then having strong opinions myself
> that arguably hinders collaboration.
>
I will maintain the GTK stack within the rust team as ITP some more GTK-rs 
stuff. fwiw I continuously commented my progress here and in the 
debcargo-confs' TODO file.

Regards,
Matthias Geiger

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBr

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Shengjing Zhu]

On Thu, Apr 13, 2023 at 10:15 PM Paul Gevers  wrote:
>
> Hi,
>
> On 13-04-2023 15:39, Paul Gevers wrote:
> >> Looks like it was caused by the UTC+8 timezone in the testbed.
> >>
> >> I agree it's nice to have the tests not depending on the system
> >> timezone. But do we really want to bother with that? Could you just
> >> ensure all testbeds have the same timezone?
> >
> > In my opinion we should do both. You don't want people to go figure this
> > out if they try to run the tests themselves in their own timezone. Also,
> > we are only in control of the hosts that Debian uses. Any downstream may
> > run into the same problems.
>
> I have changed the timezone on all our hosts, but your test still fails.
>
> https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32859920/log.gz
> is the test I just scheduled. It failed in the same way.

Maybe you haven't rebuilt the lxc image with the new timezone, so it
still uses UTC+8.

Anyway, I've staged the change in git
https://salsa.debian.org/go-team/packages/golang-github-azure-go-autorest/-/commit/73b09d0


--
Shengjing Zhu

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Peter Green]

On 13/04/2023 15:31, Peter Green wrote:


I've filed a bug with sequoia upstream. I haven't investigated the other
packages at this time.


I just did a quick test of sniffglue, ron and ureq, sniffglue and ron were
all able to run "cargo test --all --all-targets --all-features" succesfully
with the base64 dependency bumped to 0.21. ureq required a slighkt different
testing methodology to avoid some unrelated issues but also seemed ok.

So it seems that sequoia is now likely the only blocker.

P.S. ureq is maintained by Jonas outside debcargo-conf.

Bug#1034362: [PATCH] sgmls: Avoid implicit ints/function declarations in configure

[Florian Weimer]

Package: linuxdoc-tools
Version:  0.9.82-1
Tags: upstream patch

These C features are no longer part of C99, and future compilers
will no longer support them by default, causing the build to fail.

The changes assume that the usual system headers (,
) are present, but that should not be a problem on current
systems.

Related to:

  
  

diff --git a/sgmls-1.1/configure b/sgmls-1.1/configure
index 5d3e197..e674d24 100755
--- a/sgmls-1.1/configure
+++ b/sgmls-1.1/configure
@@ -110,13 +110,15 @@ cat >doit.c <<\EOF
 
 #include 
 #include 
+#include 
+#include 
 
 static int whoops()
 {
   _exit(1);
 }
 
-main()
+int main(void)
 {
   int c;
 #ifdef isascii
@@ -213,13 +215,15 @@ else
 fi
 
 cat >doit.c <<\EOF
+#include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
 remove("foo");
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -231,13 +235,15 @@ else
 fi
 
 cat >doit.c <<\EOF
+#include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
 getopt(argc, argv, "v");
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -248,14 +254,16 @@ else
off="$off HAVE_GETOPT"
 fi
 
-cat >doit.c <<\EOF
+cat>doit.c <<\EOF
+#include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
 access("foo", 4);
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -267,13 +275,15 @@ else
 fi
 
 cat >doit.c <<\EOF
+#include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
 vfork();
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -285,6 +295,8 @@ else
 fi
 
 cat >doit.c <<\EOF
+#include 
+int
 main(argc, argv)
 int argc;
 char **argv;
@@ -294,7 +306,7 @@ char **argv;
 int status;
 waitpid(-1, &status, 0);
   }
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -307,13 +319,14 @@ fi
 
 cat >doit.c <<\EOF
 #include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
 strerror(0);
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -326,13 +339,14 @@ fi
 
 cat >doit.c <<\EOF
 #include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
bcopy((char *)0, (char *)0, 0);
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -341,13 +355,14 @@ then
# Only use BSD_STRINGS if ANSI string functions don't work.
cat >doit.c <<\EOF
 #include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
memcpy((char *)0, (char *)0, 0);
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -363,13 +378,14 @@ fi
 
 cat >doit.c <<\EOF
 #include 
+int
 main(argc, argv)
 int argc;
 char **argv;
 {
   if (argc == 0)
 raise(SIGINT);
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -382,6 +398,7 @@ fi
 
 cat >doit.c <<\EOF
 #include 
+int
 main(argc, argv)
 int argc;
 char **argv;
@@ -391,7 +408,7 @@ char **argv;
 fsetpos(stdin, &pos);
 fgetpos(stdin, &pos);
   }
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -407,6 +424,7 @@ cat >doit.c <<\EOF
 #include 
 #include 
 
+int
 main(argc, argv)
 int argc;
 char **argv;
@@ -423,7 +441,7 @@ char **argv;
 WTERMSIG(status);
 WSTOPSIG(status);
   }
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -437,13 +455,16 @@ fi
 cat >doit.c <<\EOF
 #include 
 #include 
+#include 
+#include 
+#include 
 
 static int whoops()
 {
   _exit(1);
 }
 
-main()
+int main(void)
 {
   char buf[30];
 #ifdef SIGSEGV
@@ -470,6 +491,7 @@ fi
 cat >doit.c <<\EOF
 #include 
 
+int
 main(argc, argv)
 int argc;
 char **argv;
@@ -479,7 +501,7 @@ char **argv;
 catgets(d, 1, 1, "default");
 catclose(d);
   }
-  exit(0);
+  return 0;
 }
 EOF
 
@@ -492,9 +514,11 @@ fi
 
 cat >doit.c <<\EOF
 #include 
+#include 
 
 char c = UCHAR_MAX;
 
+int
 main(argc, argv)
 int argc;
 char **argv;
@@ -512,16 +536,16 @@ then
char_signed=
 else
cat >doit.c <<\EOF
-main()
+int main(void)
 {
   int i;
 
   for (i = 0; i < 512; i++) {
 char c = (char)i;
 if (c < 0)
-   exit(1);
+   return 1;
   }
-  exit(0);
+  return 0;
 }
 EOF
 
-- 
2.39.2

Bug#1033826: podman: Cannot load gzip compressed images

[Shengjing Zhu]

Hi

On Wed, Apr 12, 2023 at 6:49 PM Reinhard Tartler  wrote:
>
>
>
> On Wed, Apr 12, 2023 at 6:41 AM Reinhard Tartler  wrote:
>>
>> Control: reassign -1 golang-github-klauspost-pgzip 1.2.5-2
>> Control: affects -1 libpod
>> Control: forwarded -1 https://github.com/containers/podman/issues/15944
>> Control: severity -1 important
>>
>
> I've prepared an MR for this at 
> https://salsa.debian.org/go-team/packages/golang-github-klauspost-pgzip/-/merge_requests/4
>
> I'm looking for opinions whether this code change is appropriate for bookwork 
> at this point.
>

The patch looks complicated... I can't easily understand it. So beyond
the code review, I look at other facts.

The patch is on upstream master branch and not tagged. So all
consumers expect pdoman haven't used that. It makes me worry.

Maybe we could ask upstream if they can tag a new version, to indicate
they are confident about the change?

-- 
Shengjing Zhu

Bug#1001793: mate-terminal: Wrong context menu font when using libvte-2.91-0[-common] 0.66.1-1 or 0.66.2-1

[Mike Gabriel]

Control: tags -1 patch

On  Do 13 Apr 2023 17:53:21 CEST, Faidon Liambotis wrote:


Control: tags -1 upstream
Control: forwarded -1  
https://github.com/mate-desktop/mate-terminal/issues/407


On Wed, Apr 12, 2023 at 10:37:19AM +0300, Faidon Liambotis wrote:

On Thu, Dec 16, 2021 at 12:29:48PM +0100, Jasmin68k wrote:
> Using Debian sid, running apt-get upgrade, which installed
> libvte-2.91-0 and libvte-2.91-common 0.66.1-1.  After that, the
> context (right-click) menu font in mate-terminal became monospace,
> probably the same system wide monospace font, mate-terminal is using
> for terminal output, instead of the regular system wide application
> font.

This seems like a pretty serious UX issue. It also seems this was
reported against Ubuntu, and fixed there with 1.26.0-1ubuntu2.


To add to this:

This seems to be upstream bug #407 fixed with upstream git commit
52fa45d4ca35e6be11ddee818eac84b768f15e22:
https://github.com/mate-desktop/mate-terminal/commit/52fa45d4ca35e6be11ddee818eac84b768f15e22

This was reported against Ubuntu with LP #1955505, and fixed in
1.26.0-1ubuntu2, with a backport of the aforementioned patch:
https://git.launchpad.net/ubuntu/+source/mate-terminal/commit/?id=a0d6e4951b3443ba849be12397cc02136e62b8d6

The fix seems to be, thankfully, a trivial one-liner :)

Faidon



Tagging with patch tag.

Thanks for this! Will do an upload soonish.
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpq1YU4lTuUv.pgp
Description: Digitale PGP-Signatur

Bug#1020482: Ready to Implement

[Soren Stoutner]

Rene,

The dependencies are finally in place so this can be implemented.

To make things simpler for dictionary packagers, we are using a virtual 
package and an unversioned path for the conversion tool so that dictionary 
packagers don’t have to make modifications to their packages when the versions 
of Qt change in Debian.

All you should need to do for most of the dictionaries is the following:

1.  Build-depend on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

More detailed information can be found in the dictionary packager 
documentation at:

file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic

Regarding Aragonese, do you think upstream would be amenable to replacing the 
tab in 
their .aff file with spaces?

For Galician, a copy of the .aff file will need to be made during build time, 
the extra long 
lines removed, and then the .bdic built from that modified .aff.

For Hungarian and Ukrainian, a copy of the .aff files will need to be made 
during build time, 
the IGNORE commands removed, and then the .bdic files built from that modified 
.affs.

Thanks,

Soren
-- 
Soren Stoutner
so...@stoutner.com


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

Bug#1034069: /var/log/boot~ is never created

[Mark Hindley]

Ingo,

On Thu, Apr 13, 2023 at 06:04:04PM +0200, Ingo Brückl wrote:
> On Wed, 12 Apr 2023 09:58:27 +0100 Mark Hindley  wrote:
> 
> > +   savelog -q -p -n -c 5 /var/log/boot
> 
> What about:
> 
>   [ -e /etc/logrotate.d/boot ] || savelog -q -p -n -c 5 /var/log/boot

I am not convinced that logrotate is a better tool here. It is designed for
the routine rotation of logs. /var/log/boot is written at the end of the boot
process and then is unchanged until the next boot. Savelog makes more sense to
me for that use.

Or am I missing your point?

Thanks

Mark

Bug#1034363: firefox: Non-default fonts no longer work

[Rishi Cutchin]

Package: firefox
Version: 112.0-1
Severity: normal
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,


Updated firefox, no longer able to render Terminus font that I was using
before and I am forced to switch to the default. When loading Firefox
with Terminus set gives this error.

"[ERROR glean_core] Error setting metrics feature config:
Json(Error("EOF while parsing a value", line: 1, column: 0))"

Some testing with other fonts appeared to replicate the behavior.



-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (50, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.6-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.89-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.4-2
ii  libx11-xcb1  2:1.8.4-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.2-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec58  7:4.3.5-0+deb11u1
ii  libavcodec59  7:5.1.3-1
ii  libavcodec60  7:6.0-1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-1+b1
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Package: kde-baseapps
Version: 4:22.12.3+5.142
Severity: important

Dear Maintainers,

consider removing konqueror from the depencies of kde-baseapps.

Rationale:

kde-baseapps for version 5:111 (stable) and 5:142 (unstable) depends on
  konqueror
but konqueror depends on
  libqt5webenginecore5
source package is
  qtwebengine-opensource-src
which according to 
https://salsa.debian.org/debian/debian-security-support/-/blob/573b1a3f35208754bdf50a2af03f6c1b8c066a8b/security-support-limited
is not security maintained:
   "qtwebengine-opensource-src No security support upstream and
   backports not feasible, only for use on trusted content"

If this information is still correct,
konqueror should not be recommended or depended on
as user should by default get a system which is reasonable secure.

Thanks
Bernhard

Bug#1034054: fvwm dies too often

[Roland Rosenfeld]

Today I installed a fresh bullseye system with fvwm and also run into
this issue.  Several actions on the desktop resulted in this error
message and fvwm terminating.
Restarting fvwm via
+   "Restart fvwm"  Restart fvwm
in the menu reproducibly triggered the issue.

I installed fvwm 2.6.8-1 from buster, but the problem stayed there, so
this may be some regression triggered by some other component of
bullseye in combination with different versions of fvwm.

Since loosing the desktop with all open windows drives me crazy (and I
don't want to learn the behavior of some other window manager), I
installed fvwm3 and used this one and except that I have to adapt my
configuration to use Colorsets (instead of Colors) now, everything
seems to work as expected and I can no longer reproduce the issue with
fvwm3.

Greetings
Roland

Bug#900928: deps

[Jonas Smedegaard]

Quoting matthias.geiger1...@tutanota.de (2023-04-13 18:04:54)
> 13. Apr. 2023, 17:39 von jo...@jones.dk:
> > Please consider using the Debian bugtracker to communicate "intents
> > to package" by filing an ITP bugreport for each single upstream
> > project that you work on packaging for Debian.  
> >
> I won't do that for the rust crates (except binary ones) since that is
> the Rust Teams' policy.
[...]
> I will maintain the GTK stack within the rust team as ITP some more
> GTK-rs stuff. fwiw I continuously commented my progress here and in
> the debcargo-confs' TODO file.

Ok, so your avoiding Debbugs to track ITPs is deliberate.

I shall try to remember that, to not waste more time for both of us.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Fabian Grünbichler]

On Thu, Apr 13, 2023 at 05:21:50PM +0100, Peter Green wrote:
> On 13/04/2023 15:31, Peter Green wrote:
> 
> > I've filed a bug with sequoia upstream. I haven't investigated the other
> > packages at this time.
> 
> I just did a quick test of sniffglue, ron and ureq, sniffglue and ron were
> all able to run "cargo test --all --all-targets --all-features" succesfully
> with the base64 dependency bumped to 0.21. ureq required a slighkt different
> testing methodology to avoid some unrelated issues but also seemed ok.
> 
> So it seems that sequoia is now likely the only blocker.
> 
> P.S. ureq is maintained by Jonas outside debcargo-conf.

sounds like it should be do-able to upgrade once the freeze is lifted :)
thanks for the follow-up!

Bug#1034350: gnutls28: autopkgtest regression everywhere except amd64: src/nonexist-builddir/gnutls_ktls: not found

[Andreas Metzler]

On 2023-04-13 Paul Gevers  wrote:
> Source: gnutls28
> Version: 3.7.9-1
> Severity: serious
> Control: tags -1 bookworm-ignore
> User: debian...@lists.debian.org
> Usertags: regression

> Dear maintainer(s),

> Your package has an autopkgtest, great. However, it fails everywhere but on
> amd64. If I understand correctly, the 32 bits architecture failures are due
> to datefudge/faketime (bug 1031553) and started in September 2022. The 64
> bits architectures started to fail more recently in March 2023. Because some
> hosts on ci.debian.net have been upgraded to bookworm recently, I was
> fearing/suspecting it might be kernel related, but running the test on an
> amd64/bookworm kernel passes. Can you please investigate the situation and
> fix it?
[...]

Thank you. Looks like this did not fail on amd64 since thes machines do
not have the tls module loaded while arm64 has.

The test should be properly blacklisted instead since a) gnutls is built
without ktls support and b) because it is not a pure shell test using
gnutls-bin. Should be trivial to fix, will do.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Hi,

On 13-04-2023 18:17, Shengjing Zhu wrote:

Maybe you haven't rebuilt the lxc image with the new timezone, so it
still uses UTC+8.


That's what I thought so later too. Let's see what tomorrow brings.


Anyway, I've staged the change in git
https://salsa.debian.org/go-team/packages/golang-github-azure-go-autorest/-/commit/73b09d0

Great.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034365: evolution: search folder continues to show messages marked as deleted

[andrew bezella]

Package: evolution
Version: 3.46.4-1
Severity: normal

Dear Maintainer,

i have a search folder that aggegrates a number of imapx INBOXes into a
single location and have the accounts set to mark messages as deleted
(i.e., they do not "Use a real folder for Trash").  the "Show Deleted
Messages" option is not selected.

when i mark a message as deleted from the search folder, it is updated
in the list as a strike-through but is still shown in the list of
messages.  when i take an action such as opening another message in
the mail browser the list finally updates and the message disappears
from view.

given my settings, i would expect a deleted message to be immediately
removed from the list of messages in the search folder.  this worked
as expected at some point in the (now distant) past.  there is an
upstream bug that is perhaps related:
Search folder doesn't reflect correct state of local mail folder (#1740)
https://gitlab.gnome.org/GNOME/evolution/-/issues/1740

thanks in advance.

andy

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (990, 'testing-security'), (990, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  evolution-common3.46.4-1
ii  evolution-data-server   3.46.4-2
ii  libc6   2.36-8
ii  libcamel-1.2-64 3.46.4-2
ii  libecal-2.0-2   3.46.4-2
ii  libedataserver-1.2-27   3.46.4-2
ii  libevolution3.46.4-1
ii  libglib2.0-02.74.6-1
ii  libgtk-3-0  3.24.37-2
ii  libical33.0.16-1+b1
ii  libnotify4  0.8.1-1
ii  libwebkit2gtk-4.1-0 2.40.0-3
ii  libxml2 2.9.14+dfsg-1.1+b3
ii  psmisc  23.6-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.46.4-1
ii  evolution-plugin-pstimport   3.46.4-1
ii  evolution-plugins3.46.4-1
ii  yelp 42.2-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.40-1.1
ii  network-manager 1.42.4-1

-- no debconf information

Bug#900928: deps

[matthias . geiger1024]

13. Apr. 2023, 19:18 von jo...@jones.dk:

> Quoting matthias.geiger1...@tutanota.de (2023-04-13 18:04:54)
>
>> 13. Apr. 2023, 17:39 von jo...@jones.dk:
>> > Please consider using the Debian bugtracker to communicate "intents
>> > to package" by filing an ITP bugreport for each single upstream
>> > project that you work on packaging for Debian. 
>> >
>> I won't do that for the rust crates (except binary ones) since that is
>> the Rust Teams' policy.
>>
> [...]
>
>> I will maintain the GTK stack within the rust team as ITP some more
>> GTK-rs stuff. fwiw I continuously commented my progress here and in
>> the debcargo-confs' TODO file.
>>
>
> Ok, so your avoiding Debbugs to track ITPs is deliberate.
>
No, I do use debugs to track ITPs  (like this one, see comments above on my 
progress).
No one except you uses it to track rust library crates because the policy of 
the rust team states that. And I think most maintainers have better use of 
their little time to file 20+ ITPs for rust crates. ftpmasters are also ok with 
that, so I really don't see the issue here. And updating stacks with 60+ crates 
like GTK is way easier if it all is in one repo. 

I hoped to avoid this can of worms exactly because of that.

regards,


---
Matthias Geiger (werdahias)


-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1034366: mutter: Alt+Tab broken for 'sloppy' focus mode on Wayland

[andrew bezella]

Source: mutter
Version: 43.3-5
Severity: normal

Dear Maintainer,

this issue was reported upstream and there are details in:
Alt+Tab broken for 'sloppy' focus mode on Wayland (#888)
https://gitlab.gnome.org/GNOME/mutter/-/issues/888

there is a fix that has been merged into GNOME 44:
Fix Sloppy/mouse focus mode on Wayland (!2828)
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828

if it would be possible to cherry-pick this it would be appreciated.

thanks in advance.

andy

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (990, 'testing-security'), (990, 'testing')
Architecture: amd64 (x86_64)

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

Bug#1034313: Does not build anymore with kernel 6.1.12

[Klaus Ethgen]

Hi,

Am Mi den 12. Apr 2023 um 22:58 schrieb Andreas Beckmann:
> > Package: nvidia-tesla-470-kernel-source
> > Version: 470.182.03-1
> > Severity: important
>
> # grep -r list_for_each_safe modules/nvidia-tesla-470-kernel/
> 
> I don't know what you are compiling, but that is not 470.182.03-1

This was my mistake. I tried to compile nvidia-kernel-source as I did
for years now. nvidia-tesla-470-kernel-source does compile fine.

Please close the bug as invalid.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1034367: v2ray geoip data has problematic license

[Hans-Christoph Steiner]

Package: v2ray

From https://lists.debian.org/debian-legal/2023/02/msg4.html

V2Fly project provides a geoip data file in https://github.com/v2fly/geoip. The 
license is declared as CC-BY-SA-4.0 but it uses the data from GeoLite2, which is 
licensed under an EULA https://www.maxmind.com/en/geolite2/eula. The EULA looks 
like not a free license.


Debian packages the data file in the v2ray package. And Debian marks the data as 
MIT which is also wrong. Could you please check the license?


Also, there is now libloc packages for this that should be free.  For example, 
libloc-database should provide a free, compatible version of the geoip database.

Bug#1034368: unblock: amazon-ec2-net-utils/2.3.0-3

[Noah Meyerhans]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: amazon-ec2-net-ut...@packages.debian.org
Control: affects -1 + src:amazon-ec2-net-utils

Please unblock package amazon-ec2-net-utils

This is a targeted change to work around the debhelper dh_installsystemd issues
with management of unit files in /usr/lib/systemd/system (background in
#1031695). This closes RC bug #1034212 by moving these files to
/lib/systemd/system as shown below:

$ debdiff amazon-ec2-net-utils_2.3.0-2.dsc amazon-ec2-net-utils_2.3.0-3.dsc 
   
dpkg-source: warning: extracting unsigned source package 
(/home/noahm/src/debian/cloud/amazon-ec2-net-utils_2.3.0-2.dsc)
dpkg-source: warning: extracting unsigned source package 
(/home/noahm/src/debian/cloud/amazon-ec2-net-utils_2.3.0-3.dsc)
diff -Nru amazon-ec2-net-utils-2.3.0/debian/changelog 
amazon-ec2-net-utils-2.3.0/debian/changelog
--- amazon-ec2-net-utils-2.3.0/debian/changelog 2023-01-21 11:25:53.0 
-0800
+++ amazon-ec2-net-utils-2.3.0/debian/changelog 2023-04-13 10:22:32.0 
-0700
@@ -1,3 +1,9 @@
+amazon-ec2-net-utils (2.3.0-3) unstable; urgency=medium
+
+  * Install systemd services to /lib/systemd/system. (Closes: 1034212)
+
+ -- Noah Meyerhans   Thu, 13 Apr 2023 10:22:32 -0700
+
 amazon-ec2-net-utils (2.3.0-2) unstable; urgency=medium
 
   * Set Maintainer to the cloud team and add myself to Uploaders
diff -Nru amazon-ec2-net-utils-2.3.0/debian/patches/debian-changes 
amazon-ec2-net-utils-2.3.0/debian/patches/debian-changes
--- amazon-ec2-net-utils-2.3.0/debian/patches/debian-changes2023-01-21 
11:25:53.0 -0800
+++ amazon-ec2-net-utils-2.3.0/debian/patches/debian-changes2023-04-13 
10:22:32.0 -0700
@@ -1,3 +1,16 @@
+diff --git a/GNUmakefile b/GNUmakefile
+index d06847d..dd077a7 100644
+--- a/GNUmakefile
 b/GNUmakefile
+@@ -6,7 +6,7 @@ PREFIX?=/usr/local
+ BINDIR=${DESTDIR}${PREFIX}/bin
+ UDEVDIR=${DESTDIR}/usr/lib/udev/rules.d
+ SYSTEMDDIR=${DESTDIR}/usr/lib/systemd
+-SYSTEMD_SYSTEM_DIR=${SYSTEMDDIR}/system
++SYSTEMD_SYSTEM_DIR=${DESTDIR}/lib/systemd/system
+ SYSTEMD_NETWORK_DIR=${SYSTEMDDIR}/network
+ SHARE_DIR=${DESTDIR}/${PREFIX}/share/${pkgname}
+ 
 diff --git a/lib/lib.sh b/lib/lib.sh
 index d01dd23..02357d9 100644
 --- a/lib/lib.sh
$ debdiff amazon-ec2-net-utils_2.3.0-2_amd64.changes 
amazon-ec2-net-utils_2.3.0-3_amd64.changes
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   /lib/systemd/system/policy-routes@.service
-rw-r--r--  root/root   /lib/systemd/system/refresh-policy-routes@.service
-rw-r--r--  root/root   /lib/systemd/system/refresh-policy-routes@.timer

Files in first .changes but not in second
-
-rw-r--r--  root/root   /usr/lib/systemd/system/policy-routes@.service
-rw-r--r--  root/root   /usr/lib/systemd/system/refresh-policy-routes@.service
-rw-r--r--  root/root   /usr/lib/systemd/system/refresh-policy-routes@.timer

Control files: lines which differ (wdiff format)

Installed-Size: [-44-] {+47+}
Version: [-2.3.0-2-] {+2.3.0-3+}

[ Impact ]

Without this change, systemd services and timers installed by
amazon-ec2-net-utils may not be activated as expected when the package is
installed.

[ Tests ]

n/a

[ Risks ]

Worst case, if everything goes horribly wrong, is that certain non-default
network configuration in Amazon EC2 won't be applied. This includes
configuration of secondary network interfaces and secondary IPv4 addresses on
any interfaces.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)

unblock amazon-ec2-net-utils/2.3.0-3

Bug#1034369: libcereal: autopkgtest regression on non x86: cc1plus: all warnings being treated as errors

[Paul Gevers]

Source: libcereal
Version: 1.3.2+dfsg-4
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on all 
architectures except amd64 and i386 since August 2022. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report. (src:gcc-defaults switching to gcc-12 migrated on 
2022-08-10 to testing)


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/libc/libcereal/32116422/log.gz

[ 25%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
In file included from 
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:28:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:34:68: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]
   65 |   o_esplmap.insert({random_value(gen),  { 
random_value(gen), random_value(gen) }});

  | ~~^
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::PortableBinaryInputArchive; OArchive = 
cereal::PortableBinaryOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:39:84: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::XMLInputArchive; OArchive = cereal::XMLOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:44:62: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::JSONInputArchive; OArchive = cereal::JSONOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:49:64: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]

cc1plus: all warnings being treated as errors
make[2]: *** [unittests/CMakeFiles/test_map.dir/build.make:76: 
unittests/CMakeFiles/test_map.dir/map.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:556: 
unittests/CMakeFiles/test_map.dir/all] Error 2

make: *** [Makefile:146: all] Error 2


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034370: network-manager-gnome: Unable to (re)establish mobile broadband connection (that worked in version before)

[sebastian]

Package: network-manager-gnome
Version: 1.30.0-2
Severity: important
X-Debbugs-Cc: dasebast...@wvnet.at

Dear Maintainer,

after upgrading from Bullseye to Bookworm I cannot (re)establish an already 
used mobile broadband connection to/from my cellphone (yes, the ones with keys) 
via an USB-Cable.

The connection to this specific device worked like a charm under Buster and 
Bullseye, I plugged the cellphone via USB-cable in, choose "New mobile 
broadband connection", answered a few questions - established and ready to work.

It makes no difference now, wheter I use the "old" connection or delete it and 
try to make a new one - the connection just fails.

Have I (my cellphone) got "sorted out"?



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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.6-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  libatk1.0-0   2.46.0-5
ii  libayatana-appindicator3-10.5.92-1
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-1
ii  libgtk-3-03.24.37-2
ii  libjansson4   2.14-2
ii  libmm-glib0   1.20.4-1
ii  libnm01.42.4-1
ii  libnma0   1.10.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libsecret-1-0 0.20.5-3
ii  libselinux1   3.4-1+b5
ii  lxpolkit [polkit-1-auth-agent]0.5.5-2+b1
ii  network-manager   1.42.4-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-8

Versions of packages network-manager-gnome recommends:
ii  awesome [notification-daemon]   4.3-7
ii  gnome-icon-theme3.12.0-5
ii  gnome-keyring   42.1-1+b2
ii  iso-codes   4.13.0-1
ii  mobile-broadband-provider-info  20221107-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#1034371: gcc-sh-elf: autopkgtest fails

[Bastian Germann]

Source: gcc-sh-elf
Version: 4.1
Severity: important

The autopkgtest fails after 4.1 fixed the build (even if there are still errors 
found in the build log).
You should solve this soon to make the package stay in bookworm.

Bug#1002666: still fails

[Hans-Christoph Steiner]

I just tried this today, and it fails to download.  It tries to get version 
12.0.4.

Bug#1034372: ncurses: CVE-2023-29491

[Moritz Mühlenhoff]

Source: ncurses
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ncurses.

CVE-2023-29491 was assigned to 
https://invisible-island.net/ncurses/NEWS.html#index-t20230408

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-29491
https://www.cve.org/CVERecord?id=CVE-2023-29491

Please adjust the affected versions in the BTS as needed.

Bug#1034373: imagemagick: CVE-2023-1906

[Moritz Mühlenhoff]

Source: imagemagick
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for imagemagick.

CVE-2023-1906[0]:
https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-35q2-86c7-9247
https://github.com/ImageMagick/ImageMagick6/commit/e30c693b37c3b41723f1469d1226a2c814ca443d
 (ImageMagick 6.9.12-84)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1906
https://www.cve.org/CVERecord?id=CVE-2023-1906

Please adjust the affected versions in the BTS as needed.

Bug#1034374: RUSTSEC-2023-0031

[Moritz Muehlenhoff]

Source: rust-spin
Version: 0.9.5-1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://rustsec.org/advisories/RUSTSEC-2023-0031.html
https://github.com/mvdnes/spin-rs/issues/148

Cheers,
 Moritz

Bug#900928: deps

[Jonas Smedegaard]

Quoting matthias.geiger1...@tutanota.de (2023-04-13 19:28:16)
> 13. Apr. 2023, 19:18 von jo...@jones.dk:
> > Quoting matthias.geiger1...@tutanota.de (2023-04-13 18:04:54)
> >> I won't do that for the rust crates (except binary ones) since that
> >> is the Rust Teams' policy.
> > [...]
> >> I will maintain the GTK stack within the rust team as ITP some more
> >> GTK-rs stuff. fwiw I continuously commented my progress here and in
> >> the debcargo-confs' TODO file.
> >>
> >
> > Ok, so your avoiding Debbugs to track ITPs is deliberate.
> >
> No, I do use debugs to track ITPs

I was referring to the packages you "have been constantly working on"
yet didn't appear in the header of this bug#900928.

> No one except you uses it to track rust library crates
[...]
> I really don't see the issue here.

Fine. I thought you saw an issue with recognition, and apologize for
having wasted your time with a collaboration practice that (according to
you) noone but me bothers doing.

Let's dial back to your original request before my ramblings:

Quoting matthias.geiger1...@tutanota.de (2023-03-14 11:39:30)
> I wanted to discuss fractal. [...] I have been constantly working on
> [deps]. [...] I have been constantly working on [more deps], too.
> [...] Since I also put in some effort I also would like to be included
> as uploader. I think this is fair since now 80% of the dependencies
> are covered.

When you work on, say, gtk+3.0, then you receive recognition for your
work in that package.  Not in e.g. gnome-control-center or firefox
despite both of those other packages depend on gtk+3.0 and thus benefit
from your contribution there.

Similarly, that you "have been constantly working on" a shitload of
dependencies for fractal does not grant uploader right/recognition
for fractal. Not because you are any lesser than me nor because of how I
choose to create packages nor because I am not member of the Rust team,
but because it would not be fair to do so.

I welcome collaboration. Both indirect ones like packaging of needed
dependencies, and direct ones like patches to packaging.

I shall gladly acknowledge contributions, fairly.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1028508: python3-packaging: Please package 23.0, 22.0 has an annoying bug

[Stanislav Maslovski]

Package: python3-packaging
Version: 23.0-1
Followup-For: Bug #1028508
X-Debbugs-Cc: stanislav.maslov...@gmail.com

Hi,

The "annoying bug" that prevents installation of some packages with
pipx still exists in ver. 23.0.

Just now I had to downgrade python3-packaging to ver. 20.9-2 in order
to be able to do:

  pipx install teroshdl --include-deps

You can try it yourself and see the error it produces. It is similar to
the ones described in the links to bugreports provided by the original
reporter of #1028508.

BR,

Stanislav

Bug#1019356: gnome-feeds: Update to 2.2.0

[Brendon]

The current upstream differs substantially from our copy, which is over six 
months old now.

>From 1.0.3, webkitgtk dependency is now at 6.0.



sent with FairEmail

Bug#1034375: ITP: trurl -- command line tool for URL parsing and manipulation

[Michael Ablassmeier]

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

* Package name: trurl
  Version : 0.4
  Upstream Author : Daniel Stenberg, 
* URL : https://github.com/curl/trurl/
* License : curl
  Programming Lang: C
  Description : command line tool for URL parsing and manipulation

Parses, manipulates and outputs URLs and parts of URLs.

Typically you pass in one or more URLs and decide what of that you want
output. Posssibly modifying the URL as well.

trurl knows URLs and every URL consists of up to ten separate and independent
"components". These components can be extracted, removed and updated with
trurl and they are referred to by their respective names: scheme, user,
password, options, host, port, path, query, fragment and zoneid.

Bug#1034195: upstream gcc bug

[Gert van de Kraats]

Phil

I made an upstream issue at GCC:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504 .

Perhaps you can add other packages there, that have the same problem?

Bug#1034310: Upstream issue

[Marco Mattiolo]

Hi Rainer,

I'm not Digikam's maintainer, then maybe not the help you were looking for.

But I noticed your bug report looks same as an issue reported upstream 
[1] on a different platform: if those issues are really the same, then 
it's not Debian-specific bug. I would suggest following developer's 
indication in the linked bug report, both trying a newer version and 
collecting backtrace.


In the end, all of that will be useful for developers to find out what 
is going wrong and for Debian maintainers to cherry-pick a fix into 
stable release.


Kind regards

Marco

[1] https://bugs.kde.org/show_bug.cgi?id=466170

Bug#763193: kde-base: KDE Memory leak still present in jessie

[Bernhard Reiter]

As kde4libs are not in Bullseye anymore and phased out completely,
we have moved to the KDE Frameworks generation of technology.

This defect is potentially not relevant anymore as a lot of the technology is 
different now. At least it needs a new reproduction
and thus confirmation that is is still present on Bullseye or Unstable/
Testing.

My suggestion is to close the report, because there would have been more 
information meanwhile if a similar defect has shown in the last 9 years.

Leslie thanks again for reporting this problem, sorry that it could not
fixed for kde4libs based technology. (Or, by chance are you still using the 
new stuff and experiencing still such problems?)

Bug#1034349: bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted)

[Paul Gevers]

Hi Andreas (and others)

On Thu, 13 Apr 2023 12:42:04 +0200 Paul Gevers  wrote:
Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


Thanks for the quick fix. There is good news. Thanks to discussions on 
IRC we found a change to the lxc configuration that will enable us to 
circumvent the issue. Which means that you can drop the workaround in a 
future upload. Sorry for the noise.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034376: unblock: opm-common/2022.10+ds-7

[Markus Blatt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package opm-common

It contains an important fix of the printed version number. It is only blocked
because britney thinks that autopkgtests have not run, but they have

[ Reason ]
It contains an important fix of the printed version number and reduces resource
usage during the build.

[ Impact ]
No impact for users if there no binary rebuilds.
In the case of rebuilds resource usage on buildd will be much higher than with
new version.

[ Tests ]
All autopkgtest have run successfully for official architectures with binary
packages

[ Risks ]
None that I can think of

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
None

unblock opm-common/2022.10+ds-7
diff --git a/debian/changelog b/debian/changelog
index 0af409a45..a011537d5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+opm-common (2022.10+ds-7) unstable; urgency=medium
+
+  * d/control: Limit the architectures to known working ones.
+
+ -- Markus Blatt   Thu, 23 Mar 2023 08:34:59 +0100
+
+opm-common (2022.10+ds-6) unstable; urgency=medium
+
+  * Reduce compile time and resources with g++-12
+  * d: Fixed version string used in binaries.
+
+ -- Markus Blatt   Wed, 08 Mar 2023 23:05:15 +0100
+
+opm-common (2022.10+ds-5) experimental; urgency=medium
+
+  * Backported fixes for python tests from upstream (to fix mipsel*?)
+  * d/rules: Try to limit parallel builds to ensure 3GB RAM per process
+
+ -- Markus Blatt   Sun, 05 Feb 2023 13:59:47 +0100
+
 opm-common (2022.10+ds-4) unstable; urgency=medium
 
   * Make sure copy_python is run before CopyHeaders Closes: #1029440
diff --git a/debian/control b/debian/control
index 86112f71a..55debe51b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,9 @@ Source: opm-common
 Priority: optional
 Maintainer: Debian Science Maintainers 

 Uploaders: Arne Morten Kvarving , Markus Blatt 

-Build-Depends: cmake (>=3.10), mpi-default-bin, mpi-default-dev,
+Build-Depends: cmake (>=3.10), mpi-default-bin, mpi-default-dev, bc, procps,
debhelper-compat (= 12), libcjson-dev, libfmt-dev, quilt, 
dh-python,
-   pkg-config, git, libtool, doxygen, graphviz,
+   pkg-config, lsb-release, libtool, doxygen, graphviz,
texlive-latex-extra, texlive-latex-recommended,
ghostscript, libboost-system-dev, libboost-test-dev,
zlib1g-dev, python3-dev, libpython3-dev, python3-numpy, 
python3-distutils,
@@ -19,7 +19,7 @@ Rules-Requires-Root: no
 
 Package: libopm-common
 Pre-Depends: ${misc:Pre-Depends}
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
 Provides: ${opm:shared-library}
@@ -36,7 +36,7 @@ Description: Tools for Eclipse reservoir simulation files -- 
library
 
 Package: libopm-common-bin
 Pre-Depends: ${misc:Pre-Depends}
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
 Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: libopm-common1-bin
@@ -52,7 +52,7 @@ Description: Tools for Eclipse reservoir simulation files -- 
utility programs
 
 Package: libopm-common-dev
 Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
 Multi-Arch: same
 Suggests: libopm-common-doc
 Replaces: libopm-common1-dev
@@ -85,7 +85,7 @@ Description: Tools for Eclipse reservoir simulation files -- 
documentation
 Package: python3-opm-common
 Section: python
 Pre-Depends: ${misc:Pre-Depends}
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, 
libopm-common, python3-numpy, python3-decorator
 Description: Tools for Eclipse reservoir simulation files -- Python wrappers
  The Open Porous Media (OPM) software suite provides libraries and
diff --git a/debian/opm-debian.mk b/debian/opm-debian.mk
index 3b74fbe07..ea37112a8 100644
--- a/debian/opm-debian.mk
+++ b/debian/opm-debian.mk
@@ -2,10 +2,10 @@ include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
 include /usr/share/dune/dune-debian.env
 
-LSB_RELEASE = lsb_release -r | sed "s/.*:\s*\([^\s]*\).*/\1/"
+LSB_RELEASE = lsb_release -d | sed "s/.*:\s\+\(.*\)/\1/"
 # Needed for reproducable builds as we use __FILE__
 export DEB_BUILD_MAINT_OPTIONS += reproducible=+fixfilepath
-OPM_DEBIAN_CMAKE_FLAGS += -DBUILD_SHARED_LIBS=1 
-DCMAKE_INSTALL_DOCDIR=share/doc/lib$(DEB_SOURCE) 
-DPYTHON_INSTALL_PREFIX=lib/python3/dist-packages 
-DOPM_INSTALL_COMPILED_PYTHON=OFF -DUSE_RUNPATH=OFF -DWITH_NATIVE=OFF 
-DUSE_MPI=ON -DUSE_BASH_COMPLETIONS_DIR=ON 
-DOPM_BINARY_PACKAGE_VERSION="$(DEB_V

Bug#1034377: unblock: opm-grid/2022.10+ds-3

[Markus Blatt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package opm-grid


[ Reason ]
Only debian/control has been cleaned up.
Blocked only because britney thinks not all autopkgtests have run, but they
have for official architectures with binaries

[ Impact ]
No impact for the user if it stays blocked

[ Tests ]
autopkgtests have run successfully on all offical architectures with binaries.

[ Risks ]
None that I can think o.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
None

unblock opm-grid/2022.10+ds-3
diff --git a/debian/changelog b/debian/changelog
index ea72b63d..d008b89a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+opm-grid (2022.10+ds-3) unstable; urgency=medium
+
+  * d/control: Removed unneeded git from Build-Depends.
+
+ -- Markus Blatt   Wed, 08 Mar 2023 23:49:15 +0100
+
+opm-grid (2022.10+ds-2) experimental; urgency=medium
+
+  * d/control: Bumped standards version to 4.6.2 (no-change)
+
+ -- Markus Blatt   Mon, 09 Jan 2023 12:08:19 +0100
+
 opm-grid (2022.10+ds-1) unstable; urgency=medium
 
   * New upstream version 2022.10
diff --git a/debian/control b/debian/control
index 765a482b..923f671d 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Maintainer: Debian Science Maintainers 
, Markus Blatt 

 Build-Depends: debhelper-compat (= 12), cmake (>=3.10), quilt,
libboost-system-dev, libboost-test-dev,
-   libdune-common-dev (>= 2.6), bc, git, zlib1g-dev, libtool, 
pkg-config,
+   libdune-common-dev (>= 2.6), bc, zlib1g-dev, libtool, 
pkg-config,
libdune-grid-dev (>= 2.6), libtinyxml-dev,
libdune-istl-dev (>= 2.6), doxygen, texlive-latex-extra,
texlive-latex-recommended, ghostscript,
@@ -13,7 +13,7 @@ Build-Depends: debhelper-compat (= 12), cmake (>=3.10), quilt,
   libscotchmetis-dev, libscotchparmetis-dev,
libdune-geometry-dev (>= 2.6), libtrilinos-zoltan-dev, 
mpi-default-dev,
mpi-default-bin
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Section: libs
 Homepage: http://opm-project.org
 Vcs-Browser: https://salsa.debian.org/science-team/opm-grid

Bug#1034378: Allow Percentage Formatting in apt

[Emir SARI]

Package: apt

Hello,

The percentage formatting among different locales can vary. For instance, 
Turkish uses %100 style formatting, whereas French uses 100 %. There are also 
other languages that use varying styles like using non-break spaces between the 
sign and the number and else. However, the percentage values displayed in apt 
only uses a fixed format, such as 100%.

Please allow localising the percentage values. This will allow a more complete 
l10n experience, where the translated text matches the other locale formatting.

Bug#1034379: unblock: opm-material/2022.10+ds-4

[Markus Blatt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package opm-material


[ Reason ]
New package contains various cleanups in debian/*control files.
Only blocked by britney, because it thinks that not all autopkgtest have run,
but they have for official architectures with binaries.

[ Impact ]
No direct impact on user-

[ Tests ]
All autopkgtests on official architectures with binaries have run successfully

[ Risks ]
None that I can think off.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
None

unblock opm-material/2022.10+ds-4
diff --git a/debian/changelog b/debian/changelog
index 0c12d4aa..eacf04c9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+opm-material (2022.10+ds-4) unstable; urgency=medium
+
+  * d/(tests/)control: Limit the architectures to known working ones.
+
+ -- Markus Blatt   Fri, 24 Mar 2023 09:33:42 +0100
+
+opm-material (2022.10+ds-3) unstable; urgency=medium
+
+  * d/control: Removed unneeded git from Build-Depends.
+
+ -- Markus Blatt   Wed, 08 Mar 2023 23:37:43 +0100
+
+opm-material (2022.10+ds-2) experimental; urgency=medium
+
+  * d/control: Bump standards version to 4.6.2 (no-change)
+
+ -- Markus Blatt   Mon, 09 Jan 2023 11:35:45 +0100
+
 opm-material (2022.10+ds-1) unstable; urgency=medium
 
   * New upstream version 2022.10
diff --git a/debian/control b/debian/control
index d1d6ea3e..75591d3c 100644
--- a/debian/control
+++ b/debian/control
@@ -5,10 +5,10 @@ Uploaders: Arne Morten Kvarving 
, Markus Blatt <
 Build-Depends: debhelper-compat (= 12),
pkg-config, libopm-common-dev (>= 2022.10), quilt,  
libboost-test-dev,
libdune-common-dev, cmake, bc,
-   git, zlib1g-dev, libtool, doxygen,  graphviz,
+   zlib1g-dev, libtool, doxygen,  graphviz,
texlive-latex-extra, texlive-latex-recommended, ghostscript,
mpi-default-dev, mpi-default-bin, libatlas-base-dev
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Section: libs
 Homepage: http://opm-project.org
 Vcs-Browser: https://salsa.debian.org/science-team/opm-material
@@ -17,7 +17,7 @@ Rules-Requires-Root: no
 
 Package: libopm-material-dev
 Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
 Multi-Arch: same
 Depends: ${misc:Depends}, libopm-common-dev (>= 2022.10), libdune-common-dev
 Replaces: libopm-material1-dev
diff --git a/debian/tests/control b/debian/tests/control
index d07f6ee1..ad95245a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -6,3 +6,4 @@ Depends:
   libboost-test-dev
 # skip test on architectures where there is no installable package (e.g. 32bit)
 Restrictions: allow-stderr, skip-not-installable
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64

Bug#1034260: update reportbug for bookworm release

[Nis Martensen]

> To avoid the need to update reportbug in a bookworm point release and
> prevent bug 992332 from happening in this release, can we have a version
> of reportbug that does the right thing in bookworm?

Yes we can.

Is it acceptable for us to include one or two other small fixes in the
new version? You will want to review the diff before the upload,
correct? Until when do we have time to get this ready?

 Nis

Bug#761037: epub bugs

[Dr. David Alan Gilbert]

Hi Boris,
  Are your bugs fixed by:
  
https://github.com/captn3m0/ebook-tools/commit/5079e63250cd2f04a0829b273623c15ecb7586c4

I noticed that patch from a few days ago, and that was by someone who
had run afl against it.

It seems to fix Okular epub bug:
  https://bugs.kde.org/show_bug.cgi?id=466425

(I can't tell if these are actually security bugs or not, but havining
epub readers crash feels dodgy)

Dave

-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Bug#1034380: unblock: opm-models/2022.10+ds-4

[Markus Blatt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package opm-models


[ Reason ]
Package contains fixes to d/*control files. Is blocked only because britney
thinks that not all autopkgtests have run, but those for official architectures
with binaries have run

[ Impact ]
No impact on the user if this is not unblocked

[ Tests ]
All autopkgtests for architectures with binaries have run

[ Risks ]
None, because no real code is changed

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
None

unblock opm-models/2022.10+ds-4
diff --git a/debian/changelog b/debian/changelog
index 221675485..5a43ea694 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+opm-models (2022.10+ds-4) unstable; urgency=medium
+
+  * d/(tests/)control: Limit the architectures to known working ones.
+
+ -- Markus Blatt   Fri, 24 Mar 2023 09:43:28 +0100
+
+opm-models (2022.10+ds-3) unstable; urgency=medium
+
+  * Release to unstable (no-change)
+
+ -- Markus Blatt   Wed, 08 Mar 2023 23:45:45 +0100
+
+opm-models (2022.10+ds-2) experimental; urgency=medium
+
+  * d/control: Bumped standards version to 4.6.2
+
+ -- Markus Blatt   Mon, 09 Jan 2023 15:55:47 +0100
+
 opm-models (2022.10+ds-1) unstable; urgency=medium
 
   * New upstream version 2022.10
diff --git a/debian/control b/debian/control
index fa91260d4..add7ae3c6 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: debhelper-compat (= 12), cmake,
 # Build-Depends-Indep: # broken on precise pbuilder
  doxygen, texlive-latex-extra, texlive-latex-recommended, ghostscript,
  zlib1g-dev
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Homepage: http://opm-project.org
 Vcs-Browser: https://salsa.debian.org/science-team/opm-models
 Vcs-Git: https://salsa.debian.org/science-team/opm-models.git
@@ -20,7 +20,7 @@ Rules-Requires-Root: no
 
 Package: libopm-models-dev
 Section: libdevel
-Architecture: any
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64
 Multi-Arch: same
 Depends: ${misc:Depends},
  libdune-grid-dev, libdune-istl-dev,
diff --git a/debian/tests/control b/debian/tests/control
index 423df4959..fdc4cac7a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -6,3 +6,4 @@ Depends:
   libboost-test-dev
 # skip test on architectures where there is no installable package (e.g. 32bit)
 Restrictions: allow-stderr, skip-not-installable
+Architecture: amd64 arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64