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#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#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#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#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]

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#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#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#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({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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1025069: pavucontrol

[Lucas]

On Tue, 11 Apr 2023 14:30:38 +0200 Alban Browaeys
 wrote:
> Still could you try with pipewire-jack instead of jackd (even if you
> prefer to run jackd only while running a jack application.

Okay, I just installed it.  I had to start ardour with this command,
to get sound working on it:
$  pw-jack -s 96000 ardour

It didn't change Gnome Settings, but it did retain pavucontrol's
configuration the entire time jack was running, which is a very neat
trick, but doesn't seem worth having ardour see a difference in the
device, nor modifying ardour's command.  I've never needed ardour and
pulseaudio running at the same time, and it doesn't seem to help the
port detection issue with Gnome Settings.

Bug#1034331: 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#1033440: [Debian-lego-team] Bug#1033440: leocad: yet another application deeply broken by triple buffering patch

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + moreinfo

Quoting Jérémy Lal (2023-03-24 21:11:51)
> Leocad rendering is broken, with the mouse pointer leaving trail,
> and everything being drawn several times before being erased from the display.

I'm unable to reproduce that effect. Can you give more context?

> I strongly suspect the triple buffering patch that was enabled at the last 
> minute :(

What is "the triple buffering patch"?

Where was it enabled "last minute"? leocad hasn't seen an update in quite a
while.

> I've rebuilt leocad to latest version, just in case it was already fixed, no 
> luck.

What have you rebuilt? And what version?

Thanks!

cheers, josch

signature.asc
Description: signature