date:20240123

Source: font-manager
Version: 0.8.8-3
Severity: serious
Tags: trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0
Forwarded: https://github.com/FontManager/font-manager/issues/343

Debian's webkit2gtk maintainers intend to stop building the 4.0 API
soon. Please switch to using the 4.1 API which is the same as the 4.0
API except that it uses libsoup3 instead of libsoup2.4.

The webkit feature is only used by the Google Fonts integration
feature. It is possible to build font-manager without that feature.

Or someone could port the feature to use libsoup3. It was actually
already done in the experimental GTK4 branch, but I don't think it was
done in a way that is easy to backport.

There is documentation and examples at
https://gitlab.gnome.org/GNOME/libsoup/-/issues/218

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#1061411: giada: Stop using webkit2gtk 4.0

Source: giada
Version: 0.22.0-3
Severity: serious
Tags: patch trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0
Forwarded: https://salsa.debian.org/multimedia-team/giada/-/merge_requests/3

The webkit2gtk maintainers intend to stop building the 4.0 API soon.
The 4.1 API is the same as the 4.0 API except that it uses libsoup3
instead of libsoup2.4.

giada has an unnecessary build dependency on webkit2gtk 4.0. Please
review the attached merge proposal and upload to Debian soon.

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#797071: debconf: dpkg-preconfigure extracting template message is written to stderr, should be stdout.

2024-01-23 Thread Colin Watson

On Thu, Aug 27, 2015 at 04:52:41PM +0200, Benoît SÉRIE wrote:
> When installing packages, apt calls dpkg-preconfigure.
> The message "Extracting templates from packages..." is written to
> stderr.
> http://anonscm.debian.org/cgit/debconf/debconf.git/tree/dpkg-preconfigure#n173
> 
> IMHO, it should be written to stdout as this not an error.

When I added that message in 2005, I wrote it to stderr because stdout
was already in use for the output from apt-extracttemplates, which is
read and parsed by dpkg-preconfigure so adding human-readable text into
it isn't a good idea.

However, there's nothing to stop us using a separate pipe to communicate
with apt-extracttemplates - it's just a bit more fiddly.  I've done that
now:

https://salsa.debian.org/pkg-debconf/debconf/-/commit/ad03066a1b69f634a81bfb3083a81de1900c91a9

Thanks,

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

Bug#1061374: rust-version-sync - upcoming rust-toml update.

Quoting Peter Green (2024-01-23 22:13:37)
> On 23/01/2024 16:07, Jonas Smedegaard wrote:
> >> I have also searched
> >> to see if there are any reverse dependencies of said feature
> >> and did not find any (though it's possible that something is
> >> using the feature without declaring it).
> > Virtual package librust-version-sync-0.9+default-dev, provided by
> > librust-assert-json-diff-dev and built from src:rust-version-sync, is a
> > reverse build-dependency of src:rust-assert-json-diff.
> 
> Thanks for spotting my mistake, I had somehow failed to spot
> that markdown_deps_updated was in the default feature set.
> 
> Anyway I just built and ran the autopkgtests for rust-assert-json-diff
> with the patched rust-version-sync and it passed fine. I also tested a
> bunch of other packages that have autopkgtest dependencies on
> rust-version-sync. I didn't find any regressions.

Upstream of rust-version-sync has a git commit not yet part of a release
which bumps dependency on toml with no changes to Rust code, which makes
me confident that none is needed.

Thanks for the thorough investigation.

 - 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#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

2024-01-23 Thread Joshua Hudson

On Tue, Jan 23, 2024 at 3:16 PM Guillem Jover  wrote:
>
> Hi!
>
> On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote:
> > Package: dpkg
> > Version: 1.21.22
> > Severity: important
>
> > On unpacking a custom .dpkg file with long symbolic links, I found a
> > bunch of symbolic links ending in right, and one with copyright. The
> > overrun made all the links exactly the same length; suggesting reuse
> > of some kind of static buffer, but it's not clear if that's really
> > the case.
> >
> > Making long link records an extra byte longer for the trailing null
> > fixed the overrun and allowed the package to unpack correctly.
>
> Where those long name lengths exactly multiples of 512?

They were not. Must have been a 0 byte in the buffer after copyright.

>
> > Source for long link record length does not include trailing null:
> >
> > https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294
> >
> > I've stashed the offending .deb package but I'm not sure if I can
> > get clearance to release it.
>
> Ack. I did not try to reproduce this yet because it was not obvious
> exactly how to do that from the report, instead just inspected the
> code for potential brokenness related to this, and I think I've fixed
> this now, but as I've not tested it, could you instead try applying
> the attached patch against dpkg and test with your package whether
> this fixes the problem you've found?

That patch fixed the bug. Knowing where the bug is, I can see how
the bug works and explain why. I'm wondering if this was just a
pending disaster for everybody or if there's some actual reason it
doesn't trip on official packages.

Bug#1059159: foliate: Foliate 4-1 is actually 2.6.4, restores segfaults

Jonathan,

The debian/watch file wasn't precise enough and uscan grabbed
2.6.4.tar.gz but treated it as version 4.

Here is a merge request with an improved debian/watch:
https://salsa.debian.org/debian/foliate/-/merge_requests/5

Can I do an NMU to fix this up and also include a couple other Salsa
merge requests?

Thank you,
Jeremy Bícha

Bug#1061409: rasdaemon does not actually support PAGE_CE_ACTION etc.

2024-01-23 Thread Robert L Mathews

Package: rasdaemon
Version: 0.6.8-1.1

rasdaemon upstream offers the ability to offline memory when failures are 
detected (see ).

Debian's rasdaemon includes the configuration files to do that at 
/etc/default/rasdaemon, with lines like:

 PAGE_CE_REFRESH_CYCLE="24h"
 PAGE_CE_THRESHOLD="50"
 PAGE_CE_ACTION="soft"

This makes it look like the feature is enabled.

However, those settings in /etc/default/rasdaemon are never actually used, and 
rasdaemon will never try to offline failing memory, because the Debian package 
is not compiled with the necessary "--enable-memory-ce-pfa" flag.

Compiling rasdaemon with "--enable-memory-ce-pfa" would fix this. I tested 
compiling with that extra flag, and if you do so, these new lines are emitted 
in the logs when it is started, indicating the code is working:

 rasdaemon: Page offline choice on Corrected Errors is soft
 rasdaemon: Threshold of memory Corrected Errors is 50 / 24h

I'd like to suggest that this option be enabled. If people don't want to use 
this feature, they can edit /etc/default/rasdaemon as documented to change it 
to PAGE_CE_ACTION="off".

If it is decided not to enable this feature, then /etc/default/rasdaemon should 
be modified to remove these options so it doesn't look like it is enabled.

-- 
Robert L Mathews

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

2024-01-23 Thread Guillem Jover

Hi!

On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: important

> On unpacking a custom .dpkg file with long symbolic links, I found a
> bunch of symbolic links ending in right, and one with copyright. The
> overrun made all the links exactly the same length; suggesting reuse
> of some kind of static buffer, but it's not clear if that's really
> the case.
> 
> Making long link records an extra byte longer for the trailing null
> fixed the overrun and allowed the package to unpack correctly.

Where those long name lengths exactly multiples of 512?

> Source for long link record length does not include trailing null:
> 
> https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294
> 
> I've stashed the offending .deb package but I'm not sure if I can
> get clearance to release it.

Ack. I did not try to reproduce this yet because it was not obvious
exactly how to do that from the report, instead just inspected the
code for potential brokenness related to this, and I think I've fixed
this now, but as I've not tested it, could you instead try applying
the attached patch against dpkg and test with your package whether
this fixes the problem you've found?

> This is a potential security vulnerability due to the bug class,
> but I can'd find a plausible exploit pathway.

I don't think this is a security issue, because dpkg-deb (which is the
only component that's expected to be used with untrusted .debs, in
contrast to dpkg which expects only trusted data) never uses the libdpkg
tar extracting implementation, and instead it uses the external GNU tar
implementation.

See 
and 
for recently added blurbs on the security expectations. :)

Thanks,
Guillem
diff --git i/lib/dpkg/tarfn.c w/lib/dpkg/tarfn.c
index bc39acd7d..d999db68e 100644
--- i/lib/dpkg/tarfn.c
+++ w/lib/dpkg/tarfn.c
@@ -362,7 +362,7 @@ tar_gnu_long(struct tar_archive *tar, struct tar_entry *te, char **longp)
 	int long_read;

 	free(*longp);
-	*longp = bp = m_malloc(te->size);
+	*longp = bp = m_malloc(te->size + 1);

 	for (long_read = te->size; long_read > 0; long_read -= TARBLKSZ) {
 		int copysize;
@@ -386,6 +386,7 @@ tar_gnu_long(struct tar_archive *tar, struct tar_entry *te, char **longp)
 		memcpy(bp, buf, copysize);
 		bp += copysize;
 	}
+	*bp = '\0';

 	return status;
 }

Bug#1027085: Still hapening on 5.10.0-26-amd64

2024-01-23 Thread Benoît-Pierre Demaine


On 05/01/2024 18:37, 陈 晟祺 wrote:

Control: tags -1 + unreproducible


Still hapening on 5.10.0-26-amd64 , but this fixed the system:
update-initramfs -u ; update-grub

Did your apt run finish normally? The update of initramfs and grub is commonly
done by postinst hooks, which will be triggered when kernel / zfs is upgraded.
So if running manually can solve the problem, I suspect some faulty packages
might be preventing this process.

Thanks,
Shengqi Chen


When I ran it to fix my system, I ran it manually, and it succeeded.

My system broke "all by itself". Probably some weekly auto update. I 
would need to check system logs to see what the system did; but I am not 
sure logs will contain the return value or exit message.


I put my laptop to sleep everyt night, so I may have uptime up to 60d 
easily, covering 3 to 8 weekly updates; that's why checking log is 
difficult : cron weekly may have run 6 or 8 times when I endure the bug !!!


Did not have the issue recently ; my current kernel is 
vmlinuz-5.10.0-26-amd64 installed 29 sept.


Today, "apt-get -f install" returns 0.

--
 >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would'nt have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Bug#1061408: bullseye-pu: package debian-ports-archive-keyring/2024.01.05~deb11u1

2024-01-23 Thread Aurelien Jarno

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-ports-archive-keyr...@packages.debian.org
Control: affects -1 + src:debian-ports-archive-keyring

[ Reason ]
A new debian-ports archive key for the year 2025 has been added to the
debian-ports-archive-keyring package. It will starts to be used
beginning of January 2025, while the current key will expire end of
January 2025.

The package in bookworm also needs a similar update.

[ Impact ]
Users of the debian-ports archive will not be able to validate the
archive starting end of January 2025.

[ Tests ]
There is no test associated with this package. This package only
contains "data", no code.

[ Risks ]
Risks are very low, key addition is done regularly every year.

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

[ Changes ]
Excluding the changelog entry, the changes compared to the testing/sid
version or compared to the version currently in bullseye consist only in
the addition of the 2025 key. Therefore I went out for the easy solution
of uploading the package from testing/sid with a new changelog entry.

[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.
diff -Nru 
debian-ports-archive-keyring-2023.02.01~deb11u1/active-keys/debian-ports-archive-2025.key
 
debian-ports-archive-keyring-2024.01.05~deb11u1/active-keys/debian-ports-archive-2025.key
--- 
debian-ports-archive-keyring-2023.02.01~deb11u1/active-keys/debian-ports-archive-2025.key
   1970-01-01 01:00:00.0 +0100
+++ 
debian-ports-archive-keyring-2024.01.05~deb11u1/active-keys/debian-ports-archive-2025.key
   2024-01-05 20:54:43.0 +0100
@@ -0,0 +1,30 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBGWX3noBEADmc5RFBt8D1ThBiQmyoaFL50kLALOhsOREY+wY9RerYlMeXk07
+XQ+Oo6ukSvC+66hKs3Gg1lX8RLfEeHre+vvBfkZEd55iQ+XcmiWN2FjAS6eHJHSl
+AxDeb9tKghEfiFfVneDwVcQ3K2EeiGaUKQaQEd4ELYazYXWxFYhpfZeb7Iysj/MY
+JZ3Y2P9NmvsaCfF2wteZzoIIXo16fBHTiP8DIbjJQ0pGb7XzFYDqF0Xxuq6KKlY6
+bg/gwj5KqlaVVOt5RaRCJWRxy3A1wGNNlf2GxOgOB5zMxrwmDw+d6jchkX3Pz0Bp
+dJRmEkmQ5V0n/DYIfyjjmsVVDT7guCKjM1Jc5gkKpJvpoPRGTrkVTU/ubjflEBke
+QJyOcGooPDaAj7LAtL8uhUL0eylJi9k8BVAVlWoi+9BExlg9jMZ82dWqNQc719D7
+P/yybyrDKb233jdiw3n2gqCDhQ9a+inXuTD0K+mU08TZMoZsjr7+S6Q7y/c1Js4x
+ROI7OI9tAs5M4VcnO+pPPwRCocZhR0m3Z2ltW6FacYTPVp2RM8L0P1cSJiA4K+ub
+kdRnQ8Beuqq7mniTuitlw+NUiZ59qZekKm9aOYehKN0tCNUhra8LAc6R+esT4qIH
+SMGbg+nXyirUVWtZOk+EIGGR+xcLmt2NxJNztwnCPHR5f1Fl/1vN2Y027wARAQAB
+tFVEZWJpYW4gUG9ydHMgQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIw
+MjUpIDxmdHBtYXN0ZXJAcG9ydHMtbWFzdGVyLmRlYmlhbi5vcmc+iQJUBBMBCgA+
+FiEEUZdZ+8Zwv6bIfkJBOvZfk9b7xbkFAmWX3noCGwMFCQPnUQAFCwkIBwIGFQoJ
+CAsCBBYCAwECHgECF4AACgkQOvZfk9b7xblgexAA4VTlb2Toh156WOh/oa4Os31S
+kEBGTVbdV36G9ARv6V5VdTMNtPi+2G2+VOAOE8oqSZVqtNQR6c1oq6/C4Wd0S0IY
+ULEklCH6+SMgzG0YhW6z8jFuEJcqm4qjVfXH8ef9k3p6FOf5uajflAsWwpcI1mq6
+MkyPoMz/YrEIie2LHwZumCy6A55nUv/+IyCTtvYyw0snPnSNx/T7K6PSWYKsUs1/
+pJW5F1VT4Hct1HqYtDXLCYjJVgoDhYMbeAyfEJnaKgxXHPhZkmpqRxwVP0o3PXvP
+MIgop7+ScO7cHFqtwsgNOyvm/QUewkf5yiX88RolwGwgNvXuMTaaStq/MEZKD4oE
+v/xZO3Zf2zma5YMYUPPTV+Puehxa+TheSbk05pKcr+eZqPHmCb4KTVbo4Tr2QIMj
+tgQKfciLb7o4Kjr3kFpGcDoLjsPMlMs0ItT0RZKh58c0c5iKllc1pajJDyjVPLrH
+l3oJ0i2lS8mFLpRv0g6OabeQZBi5OU0NFUC/jpso9Nlx4UfB/rAHESaH57ZjFczs
+Euj8jczqLTeQvxIUsFJTkeRDBhnOPX4LKBvGxnhVMR+nRo8Ti/xoiFW6fGg1YIRy
++vkdTD2LfdllpTNqCgPkyQHcVSPiKlpTCMuC64E3ikjKCIlhS+cv/19qMc5pqVbL
+mR9pi1smH4Dnib709Ac=
+=12JI
+-END PGP PUBLIC KEY BLOCK-
diff -Nru debian-ports-archive-keyring-2023.02.01~deb11u1/debian/changelog 
debian-ports-archive-keyring-2024.01.05~deb11u1/debian/changelog
--- debian-ports-archive-keyring-2023.02.01~deb11u1/debian/changelog
2023-02-05 22:38:24.0 +0100
+++ debian-ports-archive-keyring-2024.01.05~deb11u1/debian/changelog
2024-01-23 22:32:56.0 +0100
@@ -1,8 +1,15 @@
-debian-ports-archive-keyring (2023.02.01~deb11u1) bullseye; urgency=medium
+debian-ports-archive-keyring (2024.01.05~deb11u1) bullseye; urgency=medium
 
   * Upload to bullseye.
 
- -- Aurelien Jarno   Sun, 05 Feb 2023 22:38:24 +0100
+ -- Aurelien Jarno   Tue, 23 Jan 2024 22:32:56 +0100
+
+debian-ports-archive-keyring (2024.01.05) unstable; urgency=medium
+
+  * Add Debian Ports Archive Automatic Signing Key (2025)
+ (ID: 3AF65F93D6FBC5B9).
+
+ -- Aurelien Jarno   Fri, 05 Jan 2024 22:27:05 +0100
 
 debian-ports-archive-keyring (2023.02.01) unstable; urgency=high

Bug#1061407: bookworm-pu: package debian-ports-archive-keyring/2024.01.05~deb12u1

2024-01-23 Thread Aurelien Jarno

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-ports-archive-keyr...@packages.debian.org
Control: affects -1 + src:debian-ports-archive-keyring

[ Reason ]
A new debian-ports archive key for the year 2025 has been added to the
debian-ports-archive-keyring package. It will starts to be used
beginning of January 2025, while the current key will expire end of
January 2025.

The package in bullseye also needs a similar update.

[ Impact ]
Users of the debian-ports archive will not be able to validate the
archive starting end of January 2025.

[ Tests ]
There is no test associated with this package. This package only
contains "data", no code.

[ Risks ]
Risks are very low, key addition is done regularly every year.

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

[ Changes ]
Excluding the changelog entry, the changes compared to the testing/sid
version or compared to the version currently in bookworm consist only in
the addition of the 2025 key. Therefore I went out for the easy solution
of uploading the package from testing/sid with a new changelog entry.

[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.
diff -Nru 
debian-ports-archive-keyring-2023.02.01/active-keys/debian-ports-archive-2025.key
 
debian-ports-archive-keyring-2024.01.05~deb12u1/active-keys/debian-ports-archive-2025.key
--- 
debian-ports-archive-keyring-2023.02.01/active-keys/debian-ports-archive-2025.key
   1970-01-01 01:00:00.0 +0100
+++ 
debian-ports-archive-keyring-2024.01.05~deb12u1/active-keys/debian-ports-archive-2025.key
   2024-01-05 20:54:43.0 +0100
@@ -0,0 +1,30 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBGWX3noBEADmc5RFBt8D1ThBiQmyoaFL50kLALOhsOREY+wY9RerYlMeXk07
+XQ+Oo6ukSvC+66hKs3Gg1lX8RLfEeHre+vvBfkZEd55iQ+XcmiWN2FjAS6eHJHSl
+AxDeb9tKghEfiFfVneDwVcQ3K2EeiGaUKQaQEd4ELYazYXWxFYhpfZeb7Iysj/MY
+JZ3Y2P9NmvsaCfF2wteZzoIIXo16fBHTiP8DIbjJQ0pGb7XzFYDqF0Xxuq6KKlY6
+bg/gwj5KqlaVVOt5RaRCJWRxy3A1wGNNlf2GxOgOB5zMxrwmDw+d6jchkX3Pz0Bp
+dJRmEkmQ5V0n/DYIfyjjmsVVDT7guCKjM1Jc5gkKpJvpoPRGTrkVTU/ubjflEBke
+QJyOcGooPDaAj7LAtL8uhUL0eylJi9k8BVAVlWoi+9BExlg9jMZ82dWqNQc719D7
+P/yybyrDKb233jdiw3n2gqCDhQ9a+inXuTD0K+mU08TZMoZsjr7+S6Q7y/c1Js4x
+ROI7OI9tAs5M4VcnO+pPPwRCocZhR0m3Z2ltW6FacYTPVp2RM8L0P1cSJiA4K+ub
+kdRnQ8Beuqq7mniTuitlw+NUiZ59qZekKm9aOYehKN0tCNUhra8LAc6R+esT4qIH
+SMGbg+nXyirUVWtZOk+EIGGR+xcLmt2NxJNztwnCPHR5f1Fl/1vN2Y027wARAQAB
+tFVEZWJpYW4gUG9ydHMgQXJjaGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDIw
+MjUpIDxmdHBtYXN0ZXJAcG9ydHMtbWFzdGVyLmRlYmlhbi5vcmc+iQJUBBMBCgA+
+FiEEUZdZ+8Zwv6bIfkJBOvZfk9b7xbkFAmWX3noCGwMFCQPnUQAFCwkIBwIGFQoJ
+CAsCBBYCAwECHgECF4AACgkQOvZfk9b7xblgexAA4VTlb2Toh156WOh/oa4Os31S
+kEBGTVbdV36G9ARv6V5VdTMNtPi+2G2+VOAOE8oqSZVqtNQR6c1oq6/C4Wd0S0IY
+ULEklCH6+SMgzG0YhW6z8jFuEJcqm4qjVfXH8ef9k3p6FOf5uajflAsWwpcI1mq6
+MkyPoMz/YrEIie2LHwZumCy6A55nUv/+IyCTtvYyw0snPnSNx/T7K6PSWYKsUs1/
+pJW5F1VT4Hct1HqYtDXLCYjJVgoDhYMbeAyfEJnaKgxXHPhZkmpqRxwVP0o3PXvP
+MIgop7+ScO7cHFqtwsgNOyvm/QUewkf5yiX88RolwGwgNvXuMTaaStq/MEZKD4oE
+v/xZO3Zf2zma5YMYUPPTV+Puehxa+TheSbk05pKcr+eZqPHmCb4KTVbo4Tr2QIMj
+tgQKfciLb7o4Kjr3kFpGcDoLjsPMlMs0ItT0RZKh58c0c5iKllc1pajJDyjVPLrH
+l3oJ0i2lS8mFLpRv0g6OabeQZBi5OU0NFUC/jpso9Nlx4UfB/rAHESaH57ZjFczs
+Euj8jczqLTeQvxIUsFJTkeRDBhnOPX4LKBvGxnhVMR+nRo8Ti/xoiFW6fGg1YIRy
++vkdTD2LfdllpTNqCgPkyQHcVSPiKlpTCMuC64E3ikjKCIlhS+cv/19qMc5pqVbL
+mR9pi1smH4Dnib709Ac=
+=12JI
+-END PGP PUBLIC KEY BLOCK-
diff -Nru debian-ports-archive-keyring-2023.02.01/debian/changelog 
debian-ports-archive-keyring-2024.01.05~deb12u1/debian/changelog
--- debian-ports-archive-keyring-2023.02.01/debian/changelog2023-02-01 
07:59:29.0 +0100
+++ debian-ports-archive-keyring-2024.01.05~deb12u1/debian/changelog
2024-01-23 22:32:07.0 +0100
@@ -1,3 +1,16 @@
+debian-ports-archive-keyring (2024.01.05~deb12u1) bookworm; urgency=medium
+
+  * Upload to bookworm.
+
+ -- Aurelien Jarno   Tue, 23 Jan 2024 22:32:07 +0100
+
+debian-ports-archive-keyring (2024.01.05) unstable; urgency=medium
+
+  * Add Debian Ports Archive Automatic Signing Key (2025)
+ (ID: 3AF65F93D6FBC5B9).
+
+ -- Aurelien Jarno   Fri, 05 Jan 2024 22:27:05 +0100
+
 debian-ports-archive-keyring (2023.02.01) unstable; urgency=high
 
   * Set the priority to high as it fixes issues already affected debian-ports.

Bug#1043009: lcovutil.pm is missing

2024-01-23 Thread Sudip Mukherjee

Control: fixed -1 lcov/2.0-4
Control: close -1 lcov/2.0-4
--

On Fri, Aug 04, 2023 at 10:19:08AM +0100, Danilo Egea Gondolfo wrote:
> Package: lcov
> Version: 2.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> The new version of the lcov package (2.0-1) is not installing the file
> lib/lcovutil.pm.
> This file didn't exist in the previous version so I guess it's just a matter
> of updating d/rules accordingly.

I tested on Debian Sid and I see lcov is working.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux trixie/sid
Release:n/a
Codename:   trixie

$ lcov --version
lcov: LCOV version 2.0-1

Marking it as fixed 2.0-4.

-- 
Regards
Sudip

Bug#1061406: geany-plugins: Stop using webkit2gtk 4.0

Source: geany-plugins
Version: 2.0-4
Severity: serious
Tags: patch trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0

The webkit2gtk maintainers intend to stop building the 4.0 API soon.
Please switch to using the 4.1 API which is the same as the 4.0 API
except that it uses libsoup3 instead of libsoup2.4.

Unfortunately, it is probably necessary to handle all 4 related
plugins at the same time.
- geany-plugin-markdown (uses webkit2gtk 4.0)
- geany-plugin-webhelper (uses webkitgtk 4.0)
- geany-plugin-geniuspaste (uses libsoup2)
- geany-plugin-updatechecker (uses libsoup2)

There is a patch for webhelper at
https://github.com/geany/geany-plugins/pull/1295 and it is daily easy
to switch markdown. (I can supply a basic patch if needed.)

Personally, I recommend to stop building the updatechecker plugin. It
is common in Debian for individual app's update check mechanism to be
disabled since there isn't any practical way for Debian-packaged apps
to be updated to a new upstream version outside the Debian repository.

That leaves the geniuspaste plugin. If it is not ported in time, it
could be disabled. There is some porting documentation at
https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 and many linked
examples.

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#1061405: cctbx: python3-future is being removed from Debian

2024-01-23 Thread Alexandre Detiste

Source: cctbx
Version: 2023.12+ds2+~3.17.0+ds1-2
Severity: normal


Dear Maintainer,

Please apply the following MR & release:

https://salsa.debian.org/science-team/cctbx/-/merge_requests/3

#1029789

Greetings

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

2024-01-23 Thread Joshua Hudson

Package: dpkg
Version: 1.21.22
Severity: important

Dear Maintainer,

On unpacking a custom .dpkg file with long symbolic links, I found a
bunch of symbolic links ending in right, and one with copyright. The
overrun made all the links exactly the same length; suggesting reuse
of some kind of static buffer, but it's not clear if that's really
the case.

Making long link records an extra byte longer for the trailing null
fixed the overrun and allowed the package to unpack correctly.

Source for long link record length does not include trailing null:

https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294

I've stashed the offending .deb package but I'm not sure if I can
get clearance to release it.

This is a potential security vulnerability due to the bug class,
but I can'd find a plausible exploit pathway.

-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

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

Kernel: Linux 6.1.0-16-amd64 (SMP w/8 CPU threads; PREEMPT)
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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9+deb12u3
ii  liblzma5 5.4.1-0.2
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b6
ii  libzstd1 1.5.4+dfsg2-5
ii  tar  1.34+dfsg-1.2
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.6.1
pn  debsig-verify  

-- no debconf information

Bug#1061403: python3-pykwalify: Missing dependencies to docopt and dateutil

2024-01-23 Thread Wolfram Sang

Package: python3-pykwalify
Version: 1.8.0-2
Severity: important

Dear Maintainer,

after upgrading to latest bookworm (but happened also with trixie),
running pykwalify failed with:

  File "/usr/bin/pykwalify", line 33, in 
sys.exit(load_entry_point('pykwalify==1.8.0', 'console_scripts', 
'pykwalify')())
 

  File "/usr/bin/pykwalify", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/pykwalify/cli.py", line 11, in 
from docopt import docopt
ModuleNotFoundError: No module named 'docopt'

After manually installing python3-docopt, the same happened for module
'dateutil'. With both modules installed, everything works fine again.
Upstream explicitly mentions these packages as "required
dependencies"[1]. Yet, I don't see the dependencies mentioned in the
Debian package. I haven't researched why it worked before the update,
but I think the dependencies should be added in any case.

Thank you for your work,

   Wolfram

[1] https://pykwalify.readthedocs.io/en/unstable/

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
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)

Versions of packages python3-pykwalify depends on:
ii  python3  3.11.4-5+b1

Versions of packages python3-pykwalify recommends:
ii  python3-ruamel.yaml  0.17.21-1

python3-pykwalify suggests no packages.

-- no debconf information

Bug#1061321: firmware-nonfree: Important changes coming up with upstream version 20230919

2024-01-23 Thread Diederik de Haas

On Monday, 22 January 2024 15:42:48 CET Diederik de Haas wrote:
> I'm currently working on an update for upstream version 20230919, based
> upon MR86 (Release 20230804) [1], which itself is based upon MR85
> (Update to 20230625) [2] and I'm running into some major issues:

https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/87

> 3) Upstream commit a0142c57045701b7557c3060af5c4246c420e4d8 titled
>"ath10k/WCN3990: move wlanmdsp to qcom/sdm845" would mean moving
>entries from ``debian/config/atheros`` to ``debian/config/qcom-soc``
>and adding a 'recommends' field to ``atheros``'s ``defines`` file.
>Which means that qcom-soc recommends atheros and atheros recommends
>qcom-soc. Technically doable, but it raises the question whether this
>separation still makes sense.

Small correction: qcom-soc no longer recommends atheros as the 'wlanmdsp' file 
was the (sole) reason for the recommends, so that can be dropped.

I still think the separation is rather arbitrary and unlikely to be useful 
(going forward).

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

Bug#1060801: Bug#1061392: swig 4.2.0 needed for Python 3.12 compatibility

2024-01-23 Thread Rafael Laboissière


Control: assign 1060801 src:swig
Control: severity 1060801 important
Control: merge 1060801 -1

* Matthias Klose  [2024-01-23 18:12]:


Package: src:swig
Version: 4.1.0-0.3
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

please update to swig 4.2.0 needed for Python 3.12 compatibility, at 
least that's what the upstream changelog suggests at


https://www.swig.org/

Bug#1061374: rust-version-sync - upcoming rust-toml update.

2024-01-23 Thread Peter Green


On 23/01/2024 16:07, Jonas Smedegaard wrote:

I have also searched
to see if there are any reverse dependencies of said feature
and did not find any (though it's possible that something is
using the feature without declaring it).

Virtual package librust-version-sync-0.9+default-dev, provided by
librust-assert-json-diff-dev and built from src:rust-version-sync, is a
reverse build-dependency of src:rust-assert-json-diff.


Thanks for spotting my mistake, I had somehow failed to spot
that markdown_deps_updated was in the default feature set.

Anyway I just built and ran the autopkgtests for rust-assert-json-diff
with the patched rust-version-sync and it passed fine. I also tested a
bunch of other packages that have autopkgtest dependencies on
rust-version-sync. I didn't find any regressions.

Bug#1061402: ITP: ly -- a TUI display manager

2024-01-23 Thread matt

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

* Package name: ly
  Version : 0.6.0
  Upstream Author : https://github.com/fairyglade
* URL : https://github.com/fairyglade/ly
* License : (wtfpl)
  Programming Lang: (C)
  Description : a TUI display manager

lightweight TUI (ncurses-like) display manager for Linux and BSD.
this package is useful to me because it's a tui display manager instead
of a graphical display manager, 
it does not have dependencies for any other packages, I use it, 
 emptty  can be considered similar because it's not a graphical display manger 
however, it's a tui display manager instead of a cli display manager,
 I plan on maintaining it by compiling the latest package,
I would need a need a sponsor

Bug#1059085: xpdf: text searching is very slow

2024-01-23 Thread Florian Schlichting

Hi Vincent,

On Wed, Dec 20, 2023 at 04:27:40AM +0100, Vincent Lefevre wrote:
> Package: xpdf
> Version: 3.04+git20231213-1
> Severity: important
> 
> With the latest version, text searching (Ctrl-F) is very slow.
> 
> For instance, on a PDF document with 3952 pages, with a word
> that has no occurrences:
>   * xpdf 3.04+git20220601-1 takes 8 seconds on an old machine;
>   * xpdf 3.04+git20231213-1 takes 110 seconds on a new machine.

I don't have precise numbers, but in my impression xpdf 3.04+git20240118
(which contains Adam's text search fix and is uploading as I write this,
so will take a few hours before being available for download) has become
a bit faster searching through large documents. When convenient, could
you check again with the same document, so we know for sure?

Thanks, Florian

Bug#1041221: lsm: Please package upstream version 1.0.24

2024-01-23 Thread Lucas Castro




Em 15/07/2023 15:52, Daniel Gröber escreveu:

Source: lsm
Severity: wishlist
X-Debbugs-Cc: d...@darkboxed.org

Hi Lucas,

it looks like there haven't been any uploads of lsm since 2020. The
version we currently have in Debian is 1.0.4 but upstream has been
busy and is at version 1.0.24.


I guess you mean 1.0.21. The upload is planned for next.



Unfortunately it's unclear what changes have been made upstream since
neither a changelog nor a git repo are provided. Still it's best to
keep packages up-to-date.

If you're not interested in maintaining lsm anymore I might be
interested in taking over, though I'm evaluating if lsm covers my
use-case :)

Thanks,
--Daniel



Thanks,

Lucas Castro.

Bug#1061401: python-django-appconf: please drop extraneous python3-six dependency

2024-01-23 Thread Alexandre Detiste

Source: python-django-appconf
Severity: normal

Dear Maintainer,

Please remove leftover dependency on python3-six:


/tmp/python-django-appconf $ grep six -r
debian/control: python3-six,
debian/control: python3-six,
/tmp/python-django-appconf $

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1061400: RM: python-django-etcd-settings -- ROM; unmaintained upstream, low popcon

2024-01-23 Thread Michael Fladischer

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512




-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmWwIRAbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqky0IAIt2WCnvEsrUgEBRuCbR
Trak4yeT8ztT76kgtzzgqNO6mpDLOBVlYL3HUJx3/VQ6WMoeB8tLw6VKDUOe6xZq
QduBLi86sB7wPFMgDg8lx/nJRqK1dZO4LQe8hGkL+XVlmp5bR6hdoIfzRycaL71a
gxzTPYAyQhg5TLgqUZyWTth1JmFXtr/6ZH02+bkgTOapGBiJtZCUwex/ICkiYKOx
frYEsnQ1fJB3ZuzMiPOQgPl7+6GY/5RoXI4JeOh8xuPTNgGBjSBYXZvJBrVE7GZi
s5X02B4l4SfJOoW2lrtdDRAi6edgCKMf4h/0Thd2qDOwwv2shWJEy7GmmSm+9jLy
ijc=
=y3OJ
-END PGP SIGNATURE-

Bug#1054086: lsm: let dh_installsystemd choose the location of units

2024-01-23 Thread Lucas Castro


Hello Helmut,

Em 16/10/2023 15:11, Helmut Grohne escreveu:

Source: lsm
Version: 1.0.4-2
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. lsm is involved, because it installs a systemd
unit. Rather than move the unit, I recommend installing it using
dh_installsystemd, because that'll automatically revert back to the old
location for bookworm-backports and thus honour the moratorium that
still is in effect there. debdiff cannot represent this patch:

 rm debian/lsm.install
 ln -s ../lsm.service debian/lsm.service


I'm planing upload a new version next week.

dh_installsystemd look only for maintainer scripts. That means it looks 
only for scripts residing in debian/ folder.


I guess you should know about that, therefore you propose to create a 
symlink from systemd file provided by upstream.


Sorry, I'm not going to apply the solution proposed on the next release, 
but I take a look what it should be the best approach for this.





Helmut



Regards,

Lucas Castro.

Bug#1061399: ITP: streamlink-twitch-gui -- A multi-platform Twitch.tv browser for Streamlink

2024-01-23 Thread matt

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

* Package name: streamlink-twitch-gui
  Version : 2.4.1
  Upstream Author : Sebastian Meyer
* URL : https://streamlink.github.io/streamlink-twitch-gui/
* License : (MIT/X,)
  Programming Lang: (JavaScript)
  Description : A multi-platform Twitch.tv browser for Streamlink

A graphical user interface on top of the Streamlink command line interface.
Built with NW.js, a web application platform powered by Chromium and Node.js.

- this package is useful to me because I don't need to open the browser
   to watch a twitch stream, it does not have dependencies
   for any other packages, I use it, gnome-twitch has similar
   functionality but is unmaintained and lacks features that 
streamlink-twitch-gui has example hiding vods,
 - I plan on maintaining it by compiling the latest package or use the
   appimage they provide, I would need a need a sponsor

Bug#1061398: jdupes segfaults on too many files

2024-01-23 Thread Kelly Price

Package: jdupes
Version: 1.19.1-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Run "jdupes -dN -r ." on a file system with millions of files
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
See above
   * What was the outcome of this action?
Segfault, program exited
   * What outcome did you expect instead?
Working copy not segfaulting.

Old version of jdupes found, as this bug was fixed in jdupes 1.20.x.  
Note, sources have moved to https://codeberg.org/jbruchon/jdupes



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

Kernel: Linux 6.1.0-0.deb11.13-amd64 (SMP w/12 CPU threads; PREEMPT)
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)

Versions of packages jdupes depends on:
ii  libc6  2.31-13+deb11u7

jdupes recommends no packages.

jdupes suggests no packages.

-- no debconf information

Bug#1061397: network-manager-openconnect: Stop using webkit2gtk 4.0

Source: network-manager-openconnect
Version: 1.2.10-2
Severity: serious
Tags: patch trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0
Forwarded: 
https://salsa.debian.org/debian/network-manager-openconnect/-/merge_requests/7

The webkit2gtk maintainers intend to stop building the 4.0 API soon.
Please switch to using the 4.1 API which is the same as the 4.0 API
except that it uses libsoup3 instead of libsoup2.4.

I have prepared a merge request to fix this issue. Please
upload the fix soon.

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#1061396: keyman: Stop using webkit2gtk 4.0

Source: keyman
Version: 16.0.144-1
Severity: serious
Tags: patch trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0
Forwarded: https://salsa.debian.org/debian/gnucash/-/merge_requests/4

The webkit2gtk maintainers intend to stop building the 4.0 API soon.
Please switch to using the 4.1 API which is the same as the 4.0 API
except that it uses libsoup3 instead of libsoup2.4.

I have prepared an upstream merge request to fix this issue. Please
upload the fix soon.

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#1001084: ITP: meli -- terminal mail client

0.8.5+20240101 draft 1 needs embedding 5 crates (3 missing, 2 ahead); runs and 
seems to work from a brief test use.

Main tasks are still to keep package up-to-date with upstream releases,
and to package more of the crates currently embedded.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/meli/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1060247: bluez disconnects device when changing status to idle

2024-01-23 Thread Flávio Amieiro

Package: bluez
Version: 5.71-1
Followup-For: Bug #1060247
X-Debbugs-Cc: flavio.amie...@gmail.com

Dear Maintainer,

As I had previously mentioned on another bug I thought was similar (#995399), I
have the exact same issue.

I'm commenting again because the behavior I see is exactly the same as the one
described in this bug report.

As I previously mentioned, when I pair the speaker, it connects fine and stays
connected. The problem comes up as soon as I pause any audio or video. About 3
seconds after pausing media playback, `bluetooth.service` restarts
(`code=killed, status=11/SEGV`) and the speaker disconnects.


Here are, again, the bluetooth service logs and dmesg output in case it helps.


-- bluetooth service journal:

jan 22 08:31:10 berlin bluetoothd[11332]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/faststream
jan 22 08:31:10 berlin bluetoothd[11332]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/faststream_duplex
jan 22 08:31:10 berlin bluetoothd[11332]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSink/opus_05
jan 22 08:31:10 berlin bluetoothd[11332]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/opus_05
jan 22 08:31:10 berlin bluetoothd[11332]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSink/opus_05_duplex
jan 22 08:31:10 berlin bluetoothd[11332]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/opus_05_duplex
jan 22 08:55:40 berlin bluetoothd[11332]: 
/org/bluez/hci0/dev_04_21_44_B5_B0_FC/sep1/fd0: fd(40) ready
jan 22 08:55:54 berlin systemd[1]: bluetooth.service: Main process exited, 
code=killed, status=11/SEGV
jan 22 08:55:54 berlin systemd[1]: bluetooth.service: Failed with result 
'signal'.
jan 22 08:55:54 berlin systemd[1]: Starting bluetooth.service - Bluetooth 
service...
jan 22 08:55:54 berlin (uetoothd)[18037]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. 
(File system: 755 ConfigurationDirectoryMode: 555)
jan 22 08:55:54 berlin bluetoothd[18037]: Bluetooth daemon 5.71
jan 22 08:55:54 berlin systemd[1]: Started bluetooth.service - Bluetooth 
service.
jan 22 08:55:54 berlin bluetoothd[18037]: Starting SDP server
jan 22 08:55:54 berlin bluetoothd[18037]: src/plugin.c:plugin_init() System 
does not support csip plugin
jan 22 08:55:54 berlin bluetoothd[18037]: profiles/audio/micp.c:micp_init() 
D-Bus experimental not enabled
jan 22 08:55:54 berlin bluetoothd[18037]: src/plugin.c:plugin_init() System 
does not support micp plugin
jan 22 08:55:54 berlin bluetoothd[18037]: src/plugin.c:plugin_init() System 
does not support vcp plugin
jan 22 08:55:54 berlin bluetoothd[18037]: src/plugin.c:plugin_init() System 
does not support mcp plugin
jan 22 08:55:54 berlin bluetoothd[18037]: src/plugin.c:plugin_init() System 
does not support bass plugin
jan 22 08:55:54 berlin bluetoothd[18037]: src/plugin.c:plugin_init() System 
does not support bap plugin
jan 22 08:55:54 berlin bluetoothd[18037]: Bluetooth management interface 1.22 
initialized
jan 22 08:55:54 berlin bluetoothd[18037]: Battery Provider Manager created
jan 22 08:55:54 berlin bluetoothd[18037]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
jan 22 08:55:54 berlin bluetoothd[18037]: sap-server: Operation not permitted 
(1)
jan 22 08:55:54 berlin bluetoothd[18037]: Failed to set privacy: Rejected (0x0b)
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/ldac
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSink/aptx_hd
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/aptx_hd
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSink/aptx
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/aptx
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSink/sbc
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/sbc
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSink/sbc_xq
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/sbc_xq
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/aptx_ll_1
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/aptx_ll_0
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered: sender=:1.71 
path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
jan 22 08:55:54 berlin bluetoothd[18037]: Endpoint registered:

Bug#1061140: Cross-building against sqlite3 broken for riscv64

2024-01-23 Thread Aurelien Jarno

Hi,

On 2024-01-19 11:11, Jan Kiszka wrote:
> Package: release.debian.org
> 
> Please align the uploaded versions of sqlite3 packages so that
> cross-building against some lib of this source is working for riscv64.

The sqlite3 upload version 3.45.0-1 fixed that. Closing the bug.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1007940:

0.6.0 draft 2 needs embedding 45 crates (21 missing, 1 broken, 12 ahead, 11 
unreleased); cannot build due to unsatisfied build-dependency on 
librust-axum-0.6+form-dev

Main task now is packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/matrix-team/matrix-conduit/-/blob/debian/latest/debian/TODO

-- 
 * 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#1061370: gcc-14 ftbfs on armel

2024-01-23 Thread Matthias Klose


On 23.01.24 15:56, Wookey wrote:

On 2024-01-23 09:01 +0100, Matthias Klose wrote:

Package: src:gcc-14
Version: 14-20240121-1
Severity: important
Tags: sid trixie ftbfs
X-Debbugs-CC: debian-...@lists.debian.org

gcc-14 ftbfs on armel.  This is a long standing, re-occurring issue which
never has been forwarded and committed by the armel ports to GCC upstream.
Please do it.


Why do you want the armel porters to forward this bug upstream, when
forwarding bugs upstream is normally the package maintainers job?

I mean sure someone could do that, but it's probably not been done so
far becuase they thought you would.

Is your point that actually it's not just a matter of formwarding -
some armel-specific investigation is needed first to work out what's actually 
wrong?


it's porters work to keep the basic toolchains working in Debian.  This 
is not done by the armel porters.  I'm not doing this work.  If you want 
to keep this port alive, please spend the time and resources to do so.

Bug#1024683: ITP: helix - efficient console-based modal text editor

23.10 snapshot 20231229 draft 1 needs embedding 35 crates (28 missing, 2 
broken, 5 outdated); rustc build succeeds but packaging fails at the last 
stages due to issues with embedding crates

Main task now is packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/hx/-/blob/debian/latest/debian/TODO

-- 
 * 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#1061395: gnucash: Stop using webkit2gtk 4.0

Source: gnucash
Version: 1.3.0-2
Severity: serious
Tags: patch trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0
Forwarded: https://salsa.debian.org/debian/gnucash/-/merge_requests/4

The webkit2gtk maintainers intend to stop building the 4.0 API soon.
Please switch to using the 4.1 API which is the same as the 4.0 API
except that it uses libsoup3 instead of libsoup2.4.

I have prepared a merge request to fix this issue. Please upload the fix soon.

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#1051238: ITP: biome - formatter and linter for web languages

1.5.2 draft 1 needs embedding 20 crates (15 missing, 1 broken, 1 incomplete, 1 
outdated, 2 ahead); built binary is totally untested

Main task now is packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/biome/-/blob/debian/latest/debian/TODO


-- 
 * 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#798819: debconf: support for Wayland

2024-01-23 Thread Colin Watson

On Sun, Sep 13, 2015 at 02:21:09PM +0530, Ritesh Raj Sarraf wrote:
> So I'm running "GNOME on Wayland" and now the Debconf Graphical User
> Interface does not show up. This seems to be because of the limitation
> Wayland has, as it does not support X11 like Forwarding.
> 
> The FAQ on Wayland has some ideas, but I don't think anything is readily
> available.
> 
> http://wayland.freedesktop.org/faq.html#heading_toc_j_7

I'm sorry for the very long delay in replying to this!

I don't quite see the link with forwarding, unless you're connecting
over SSH.  I just tested the debconf UI in a bookworm VM running
Wayland, and things seemed to work fine (it used Xwayland until I
realized I had to pass the XDG_RUNTIME_DIR environment variable through
sudo, but that was the only hitch).

Is it possible that this has been fixed by something other than debconf
in the intervening years?

Thanks,

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

Bug#1061394: ITP: langtable -- Python 3 library for guessing locale defaults

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
Control: affects -1 src:langtable
Owner: jeremy.bi...@canonical.com

Package Name: langtable
Version: 0.0.64
Upstream Author: Mike Fabian
License: GPL-3+
Programming Lang: Python 3

Description: Python 3 library for guessing locale defaults
 langtable is a Python 3 library that guesses reasonable defaults for
 locale, keyboard, territory, etc. based on the information already known.

Other Info
--
This package will be maintained by the Debian Python team. Packaging is at
https://salsa.debian.org/python-team/packages/langtable

langtable is a proposed build dependency for the gnome-desktop library

Thanks,
Jeremy Bícha

Bug#1061194: podman: cannot run rootful containers with many layers using overlay driver

2024-01-23 Thread Tee Hao Wei

On Tue, 23 Jan 2024, at 16:19, Faidon Liambotis wrote:
> I think that's big enough to make me at least a bit uncomfortable about
> a cherry-pick to stable. Could you elaborate on your use case? It sounds
> like this manifests only with a large number of layers, and I'm not sure
> how common this is.

Thanks for taking a look. I'm just running the home-assistant container
ghcr.io/home-assistant/home-assistant.

> The alternative to a stable update is a backport of the latest podman
> version (currently 4.8.3), plus associated packages like
> containers/storage, of course.  It's a moderate amount of work; Reinhard
> who's been doing the version updates in unstable could speak more to the
> work he's been putting into package updates etc. It would help with
> bringing in a lot of more fixes from what I'd consider a very active
> upstream. We also have #1059496, as another recent, concrete example.
> 
> I'm still unsure and debating targeted s-p-u fixes vs. a backport. My
> concern is basically that we may start playing whack-a-mole. A quick
> peek at the upstream changelog reveals tons of fixed bugs in every
> release, and us trying to keep up by cherry-picking fixes to two years
> of upstream development may prove futile...
> 
> Thoughts?

I think backporting makes sense to me. In fact I built my own podman
from upstream in the meantime.. 

Actually, I initially submitted a backport request. But gibmat thought
it would be better to have it fixed in stable so everyone benefits,
although I agree it's not a common thing to run into.

--
Hao Wei

Bug#1056073: audacious: No media buttons in QT mode

2024-01-23 Thread Jelle Haandrikman

With the recent Debian Testing (Trixie) the problem seems to have been 
resolved.


Both my systems have libqt6svg6 installed. And Audacious shows the media 
buttons.


This bug can be closed.

Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates

On 2024-01-23 14:39, Maytham Alsudany wrote:

Hi Drew,

On Tue, 2024-01-23 at 11:24 +0100, Drew Parsons wrote:

> > Hi Maytham, I can upload it.  But note how pkcs11 is failing on 32 bit
> > arches.  That needs to be sorted out.  I had been waiting for that
> > before uploading enterprise-certificate-proxy.
>
> 
https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/merge_requests/2
>
> go-pkcs11 builds successfully and passes autopkgtest, lintian, and
> piuparts on
> both amd64 and i386.

The problem is on debci. See the failing tests at
  https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/

summarised also at
https://tracker.debian.org/pkg/golang-github-google-go-pkcs11

I'm aware, and the PR I've linked is a fix, please have a look.

You can look at the patch file itself at [1] (have a look at the 
description to

understand what the PR/patch does).

Thanks Maytham.  The patch handling it via malloc_arg makes sense.

I left a review commenting about supporting other 32 bit architectures, 
not just 386 and arm.
I can see how to adapt your patch to control it at build time. Let me 
know if you're happy

with that idea or if you can see another way to do it.

(an alternative could be checking bits, along the lines of
"const PtrSize = 32 << uintptr(^uintptr(0)>>63)"
But I wouldn't necessarily trust that to always give the right 
indication.

Your idea of handling two separate definitions should work fine)

Drew

Bug#1061393: runescape: Runescape launcher won't start because of missing dependencies

2024-01-23 Thread Markus Schmees

Package: runescape
Version: 0.8-2
Severity: important
X-Debbugs-Cc: schm...@web.de

After installing "runescape" (by "sudo apt install runescape") I could start
the program "runescape", but it stopped executing at 98%.

I could adjust the file "/usr/games/runescape" so that error messages were
shown, which revealed a "java.lang.NoClassDefFoundError:
java/util/jar/Pack200".

The currently installed Java-Runtime is openjdk-17-jre. It appears that the
Java-class Pack200 is deprecated since openjdk-11 (see:
https://openjdk.org/jeps/336 ) and removed since openjdk-14 (see:
https://openjdk.org/jeps/367 ).

Therefore the package "runescape" won't work any longer. I don't see a way to
fix this bug (other than adding old and deprecated java-classes). What do you
think?


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

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

Versions of packages runescape depends on:
ii  7zip [p7zip-full]23.01+dfsg-7
ii  default-jre [java10-runtime] 2:1.17-75
ii  openjdk-17-jre [java10-runtime]  17.0.10+7-1
ii  p7zip-full   16.02+transitional.1
ii  wget 1.21.4-1+b1
ii  zenity   4.0.1-1

runescape recommends no packages.

runescape suggests no packages.

-- no debconf information

Bug#1061392: swig 4.2.0 needed for Python 3.12 compatibility

2024-01-23 Thread Matthias Klose


Package: src:swig
Version: 4.1.0-0.3
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

please update to swig 4.2.0 needed for Python 3.12 compatibility, at 
least that's what the upstream changelog suggests at


https://www.swig.org/

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

2024-01-23 Thread Helmut Grohne

Hi,

TL;DR: I brainstorm solutions and appreciated feedback, but no action is
required at this time.

On Sun, Jan 21, 2024 at 10:32:29PM +0100, Helmut Grohne wrote:
> This seems pretty much unfxiable to me now.

Unfixable was a bit too strong. With much help from Aurelien and ideas
from Enrico I looked at this more systematically.

I first tried to understand what kind of file sharing we between glibc
packages. To that end I wrote a collect.sh (attached) that downlods all
the glibc packages and a diagnose.py (attached) that tries to scrape
relevant detail from them. This results in an output.txt (attached).
This is all quite hacky, but it gets the job done. For the purpose of
this analysis, I am assuming that files that differ in content also
differ in size (which of course is not generally correct, but simplifies
matters). That output.txt lists files (normalized to lack any /usr
prefix) and the packages shipping them (as a 3-tuple package name,
architecture, size or symlink target). Assuming that all the packages
were Multi-Arch: same, files with identical content (i.e. size) are
discarded. We're left with three kinds of file sharing:

debhelper version on sh4


Apparently sh4 has a different debhelper that emits different files in
/usr/share/doc. This breaks M-A:same, but is otherwise boring in the
DEP17 context.

Conflicting multilibs
=

Around 300 files in /lib64 conflict between libc6-ppc64:powerpc,
libc6-amd64:i386 and libc6-amd64:x32. Likewise, around 300 files in
/lib32 conflict between libc6-s390:s390x, libc6-sparc:sparc64,
libc6-i386:amd64 libc6-powerpc:ppc64, libc6-i386:x32 and
libc6-mipsn32:mips64el. These are declared file conflicts.
Unfortunately, we learned that Conflicts do not reliably prevent
concurrent unpacks in the presence of aliasing, so when moving these
libraries, we can construct a file loss, for example:

 * apt install libc6:mips64el libc6-i386:amd64
 * Add hypothetical apt sources with a moved glibc.
 * echo libc6-i386:amd64 deinstall | dpkg --set-selections
 * dpkg --auto-deconfigure --install libc6-mipsn32_usrmoved_mips64el.deb

In essence, this will be upgrading from bookworm to trixe while
simultaneously replacing libc6-i386 with libc6-mipsn32 for some reason.
On top of that, I guess that apt would prefer removing libc6-i386 before
unpacking libc6-mipsn32 such that the loss scenario likely requires
working with dpkg directly.

There is a relatively simple mitigation. For every file in SLIBDIR in
the trixie, libc-alt.preinst can set up a diversion for the
corresponding aliased location diverting to some non-existent filename.
libc-alt.postinst then removes these diversions. The Conflicts require
the conflicting libc-alt to actually be removed before libc-alt.postinst
is run. (Breaks is not sufficient as I learned the hard way.) These are
very temporary diversions, but they're also quite many (300).

At the time of this writing, I have not prototyped this approach. Let me
already pose the question of how you assess the involved risks here.
Actually triggering this failure is a rather strange corner case and it
is not clear to me whether this corner case is worth risking possible
implementation bugs in the mitigation.

Conflicting runtime dynamic linkers between multiarch packages
==

Some architecture combinations such as s390, powerpc, hppa, m68k,
mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting
runtime dynamic loaders. In theory this violates Multi-Arch: same, but
there is basically nothing we can do about this and dropping Multi-Arch:
same from the packages would completely break any kind of multiarch
setup. There is little we can do here and this is also unrelated to
DEP17.

Conflicting runtime dynamic linkers between multiarch and multilib
==

Runtime dynamic linkers need to be installed both into libc:ARCH and
libc-ARCH:SIBLINGARCH. An example is libc6:i386 and libc6-i386:amd64
both containing /lib/ld-linux.so.2. Both packages really need to ensure
presence of the runtime dynamic linker on installation in the exact
location so there is little we can do about this. The current situation
is that the multiarch package Replaces the multilib one such that
ownership is automatically transferred to the multiarch one when both
are installed. The multiarch postrm also checks whether a multilib
package is remaining and restores the symlink if it was stolen.

This way of doing things works badly with the /usr-move. In the DEP17
document, this amounts to a P1 problem where a file is both moved from
one package to another and from / to /usr. Since we actually want to
permit concurrent unpack, we cannot use Conflicts (M7). We will have to
employ protective diversions one way or another. Unfortunately, the
/usr-move makes it difficult to safely transition the ownership of the
runtime dynamic

Bug#1061374: rust-version-sync - upcoming rust-toml update.

Quoting Peter Green (2024-01-23 09:55:04)
> I hope to update rust-toml to 0.8 soon, probably in a week or so.
> The upstream changelog mentions the following under breaking changes
> 
> > Serialization and deserialization of tuple variants has changed from 
> > being an array to being a table with the key being the variant name and the 
> > value being the array
> 
> toml is an optional (in the cargo sense) dependency of version-sync,
> it is used by the markdown_deps_updated feature. I have tested
> that rust-version-sync package builds and runs it's autopkgtests
> successfully with the new version of toml.

Thanks!  I'll look into updating.


> I have also searched
> to see if there are any reverse dependencies of said feature
> and did not find any (though it's possible that something is
> using the feature without declaring it).

Virtual package librust-version-sync-0.9+default-dev, provided by
librust-assert-json-diff-dev and built from src:rust-version-sync, is a
reverse build-dependency of src:rust-assert-json-diff.


 - 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#1061391: libpoppler126: search across pages not working

2024-01-23 Thread Emil

Package: libpoppler126
Version: 22.12.0-2+b1
Severity: normal

If I compiling xpdf v3.04 from original package search works fine.

If I compile the debian version of xpdf v3.04 you obtain an executable
linked to libpoppler126

Take a random pdf file for example: 
https://www.cs.dartmouth.edu/~sergey/cs258/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf
The word 'hash' appears 62 times in this file:
$ps2ascii UlrichDrepper-How-To-Write-Shared-Libraries.pdf  | grep -i hash | wc 
-l
62

Open the above pdf in xpdf on page 1 and then Find text: 'hash' - nothing is 
found
go to page 5 and try to find 'hash' again - hash if found several times 
in pages 5 to 10 but nothing after

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

Kernel: Linux 4.19.303 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libpoppler126 depends on:
ii  libc62.37-13
ii  libfontconfig1   2.14.2-6+b1
ii  libfreetype6 2.13.2+dfsg-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libopenjp2-7 2.5.0-1+b1
ii  libpng16-16  1.6.39-2
ii  libstdc++6   13.2.0-5
ii  libtiff6 4.5.0-6
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages libpoppler126 recommends:
ii  poppler-data  0.4.12-1

libpoppler126 suggests no packages.

-- no debconf information

Bug#1061390: iwlwifi: crash when disabling wifi

2024-01-23 Thread Salvatore Bonaccorso

Control: forcemerge 1058887 -1

Hi Thomas,

On Tue, Jan 23, 2024 at 04:19:18PM +0100, Thomas Goirand wrote:
> Source: linux
> Version: 6.1.69-1
> Severity: important
> 
> Hi,
> 
> In some cases, when I disable wifi with the network manager GUI
> (ie: right click, "Enable Wifi" to disable it), my iwlwifi driver
> crashes, with the crash dump attached to this bug report.
> 
> When this happen, then my network stack is kind of completely
> broken, and I have to reboot.
> 
> Let me know what I can do to improve this bug report. Maybe
> install the debug kernel?
> 
> Cheers,
> 
> Thomas Goirand (zigo)

> [114704.251050] iwlwifi :6f:00.0: RF_KILL bit toggled to disable radio.
> [114704.251053] iwlwifi :6f:00.0: reporting RF_KILL (radio disabled)
> [114704.265509] wlp111s0: deauthenticating from f0:9f:c2:ff:9f:62 by local 
> choice (Reason: 3=DEAUTH_LEAVING)
> [114706.269470] iwlwifi :6f:00.0: fail to flush all tx fifo queues Q 5
> [114706.271154] iwlwifi :6f:00.0: Queue 5 is active on fifo 3 and stuck 
> for 1 ms. SW [5, 6] HW [6, 6] FH TRB=0x080305005
> [114708.273433] iwlwifi :6f:00.0: fail to flush all tx fifo queues Q 5
> [114708.274068] iwlwifi :6f:00.0: Queue 5 is active on fifo 3 and stuck 
> for 1 ms. SW [5, 6] HW [6, 6] FH TRB=0x080305005
> [114708.274125] [ cut here ]
> [114708.274127] WARNING: CPU: 0 PID: 80864 at net/mac80211/sta_info.c:1297 
> __sta_info_destroy_part2+0x12e/0x160 [mac80211]
> [114708.274291] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi 
> snd_seq_device tun ctr ccm rfcomm xt_conntrack xt_MASQUERADE 
> nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat 
> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype iptable_filter 
> br_netfilter bridge stp llc cpufreq_ondemand cpufreq_userspace 
> cpufreq_conservative cpufreq_powersave scsi_transport_iscsi nvme_fabrics cmac 
> algif_hash algif_skcipher af_alg overlay qrtr bnep snd_hda_codec_hdmi 
> snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel 
> soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci 
> snd_sof_xtensa_dsp binfmt_misc snd_sof xfs snd_sof_utils nls_ascii 
> soundwire_bus nls_cp437 snd_soc_skl vfat squashfs fat snd_soc_hdac_hda 
> snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match 
> snd_soc_acpi iwlmvm snd_ctl_led snd_soc_core x86_pkg_temp_thermal 
> snd_hda_codec_realtek intel_powerclamp btusb coretemp snd_hda_codec_generic 
> btrtl snd_compress
> [114708.274367]  mac80211 btbcm snd_hda_intel btintel snd_intel_dspcfg 
> kvm_intel btmtk snd_intel_sdw_acpi dell_rbtn bluetooth libarc4 snd_hda_codec 
> kvm uvcvideo snd_hda_core jitterentropy_rng snd_hwdep videobuf2_vmalloc 
> dell_laptop iwlwifi snd_pcm_oss irqbypass videobuf2_memops ledtrig_audio 
> dell_wmi drbg snd_mixer_oss videobuf2_v4l2 
> processor_thermal_device_pci_legacy joydev mei_hdcp mei_wdt rapl 
> processor_thermal_device dell_smbios intel_rapl_msr ansi_cprng dell_smm_hwmon 
> snd_pcm videobuf2_common iTCO_wdt cfg80211 processor_thermal_rfim 
> intel_cstate ucsi_acpi dcdbas dell_wmi_sysman ecdh_generic 
> processor_thermal_mbox snd_timer intel_pmc_bxt intel_uncore videodev 
> processor_thermal_rapl mei_me dell_wmi_descriptor typec_ucsi 
> firmware_attributes_class pcspkr roles iTCO_vendor_support snd 
> intel_rapl_common intel_wmi_thunderbolt wmi_bmof mc watchdog rfkill ee1004 
> soundcore mei ecc typec int3403_thermal intel_soc_dts_iosf int3400_thermal 
> intel_hid intel_pch_thermal int340x_thermal_zone
> [114708.274434]  dell_smo8800 ac intel_pmc_core acpi_thermal_rel acpi_pad 
> sparse_keymap hid_multitouch evdev serio_raw msr i2c_dev parport_pc ppdev lp 
> parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 
> mbcache jbd2 btrfs blake2b_generic zstd_compress usbhid dm_crypt dm_mod 
> efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor 
> async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear 
> md_mod i915 crc32_pclmul drm_buddy crc32c_intel i2c_algo_bit nvme 
> drm_display_helper ghash_clmulni_intel sha512_ssse3 nvme_core cec ahci 
> sha512_generic hid_generic t10_pi rc_core rtsx_pci_sdmmc libahci sha256_ssse3 
> xhci_pci crc64_rocksoft_generic ttm sha1_ssse3 crc64_rocksoft xhci_hcd libata 
> crc_t10dif mmc_core drm_kms_helper crct10dif_generic usbcore intel_lpss_pci 
> i2c_hid_acpi aesni_intel scsi_mod i2c_i801 i2c_hid video crct10dif_pclmul 
> crypto_simd intel_lpss crc64 cryptd drm e1000e i2c_smbus rtsx_pci 
> crct10dif_common scsi_common idma64 usb_common
> [114708.274507]  hid battery wmi button
> [114708.274511] CPU: 0 PID: 80864 Comm: kworker/0:0 Tainted: G   
> X   6.1.0-17-amd64 #1  Debian 6.1.69-1
> [114708.274514] Hardware name: Dell Inc. Precision 7530/0C1D71, BIOS 1.29.1 
> 07/05/2023
> [114708.274516] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
> [114708.274576] RIP:

Bug#1061390: iwlwifi: crash when disabling wifi

2024-01-23 Thread Thomas Goirand

Source: linux
Version: 6.1.69-1
Severity: important

Hi,

In some cases, when I disable wifi with the network manager GUI
(ie: right click, "Enable Wifi" to disable it), my iwlwifi driver
crashes, with the crash dump attached to this bug report.

When this happen, then my network stack is kind of completely
broken, and I have to reboot.

Let me know what I can do to improve this bug report. Maybe
install the debug kernel?

Cheers,

Thomas Goirand (zigo)
[114704.251050] iwlwifi :6f:00.0: RF_KILL bit toggled to disable radio.
[114704.251053] iwlwifi :6f:00.0: reporting RF_KILL (radio disabled)
[114704.265509] wlp111s0: deauthenticating from f0:9f:c2:ff:9f:62 by local 
choice (Reason: 3=DEAUTH_LEAVING)
[114706.269470] iwlwifi :6f:00.0: fail to flush all tx fifo queues Q 5
[114706.271154] iwlwifi :6f:00.0: Queue 5 is active on fifo 3 and stuck for 
1 ms. SW [5, 6] HW [6, 6] FH TRB=0x080305005
[114708.273433] iwlwifi :6f:00.0: fail to flush all tx fifo queues Q 5
[114708.274068] iwlwifi :6f:00.0: Queue 5 is active on fifo 3 and stuck for 
1 ms. SW [5, 6] HW [6, 6] FH TRB=0x080305005
[114708.274125] [ cut here ]
[114708.274127] WARNING: CPU: 0 PID: 80864 at net/mac80211/sta_info.c:1297 
__sta_info_destroy_part2+0x12e/0x160 [mac80211]
[114708.274291] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi 
snd_seq_device tun ctr ccm rfcomm xt_conntrack xt_MASQUERADE 
nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype iptable_filter 
br_netfilter bridge stp llc cpufreq_ondemand cpufreq_userspace 
cpufreq_conservative cpufreq_powersave scsi_transport_iscsi nvme_fabrics cmac 
algif_hash algif_skcipher af_alg overlay qrtr bnep snd_hda_codec_hdmi 
snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel 
soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci 
snd_sof_xtensa_dsp binfmt_misc snd_sof xfs snd_sof_utils nls_ascii 
soundwire_bus nls_cp437 snd_soc_skl vfat squashfs fat snd_soc_hdac_hda 
snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match 
snd_soc_acpi iwlmvm snd_ctl_led snd_soc_core x86_pkg_temp_thermal 
snd_hda_codec_realtek intel_powerclamp btusb coretemp snd_hda_codec_generic 
btrtl snd_compress
[114708.274367]  mac80211 btbcm snd_hda_intel btintel snd_intel_dspcfg 
kvm_intel btmtk snd_intel_sdw_acpi dell_rbtn bluetooth libarc4 snd_hda_codec 
kvm uvcvideo snd_hda_core jitterentropy_rng snd_hwdep videobuf2_vmalloc 
dell_laptop iwlwifi snd_pcm_oss irqbypass videobuf2_memops ledtrig_audio 
dell_wmi drbg snd_mixer_oss videobuf2_v4l2 processor_thermal_device_pci_legacy 
joydev mei_hdcp mei_wdt rapl processor_thermal_device dell_smbios 
intel_rapl_msr ansi_cprng dell_smm_hwmon snd_pcm videobuf2_common iTCO_wdt 
cfg80211 processor_thermal_rfim intel_cstate ucsi_acpi dcdbas dell_wmi_sysman 
ecdh_generic processor_thermal_mbox snd_timer intel_pmc_bxt intel_uncore 
videodev processor_thermal_rapl mei_me dell_wmi_descriptor typec_ucsi 
firmware_attributes_class pcspkr roles iTCO_vendor_support snd 
intel_rapl_common intel_wmi_thunderbolt wmi_bmof mc watchdog rfkill ee1004 
soundcore mei ecc typec int3403_thermal intel_soc_dts_iosf int3400_thermal 
intel_hid intel_pch_thermal int340x_thermal_zone
[114708.274434]  dell_smo8800 ac intel_pmc_core acpi_thermal_rel acpi_pad 
sparse_keymap hid_multitouch evdev serio_raw msr i2c_dev parport_pc ppdev lp 
parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 
mbcache jbd2 btrfs blake2b_generic zstd_compress usbhid dm_crypt dm_mod 
efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor 
async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear 
md_mod i915 crc32_pclmul drm_buddy crc32c_intel i2c_algo_bit nvme 
drm_display_helper ghash_clmulni_intel sha512_ssse3 nvme_core cec ahci 
sha512_generic hid_generic t10_pi rc_core rtsx_pci_sdmmc libahci sha256_ssse3 
xhci_pci crc64_rocksoft_generic ttm sha1_ssse3 crc64_rocksoft xhci_hcd libata 
crc_t10dif mmc_core drm_kms_helper crct10dif_generic usbcore intel_lpss_pci 
i2c_hid_acpi aesni_intel scsi_mod i2c_i801 i2c_hid video crct10dif_pclmul 
crypto_simd intel_lpss crc64 cryptd drm e1000e i2c_smbus rtsx_pci 
crct10dif_common scsi_common idma64 usb_common
[114708.274507]  hid battery wmi button
[114708.274511] CPU: 0 PID: 80864 Comm: kworker/0:0 Tainted: G   X  
 6.1.0-17-amd64 #1  Debian 6.1.69-1
[114708.274514] Hardware name: Dell Inc. Precision 7530/0C1D71, BIOS 1.29.1 
07/05/2023
[114708.274516] Workqueue: events cfg80211_rfkill_block_work [cfg80211]
[114708.274576] RIP: 0010:__sta_info_destroy_part2+0x12e/0x160 [mac80211]
[114708.274631] Code: bb d4 00 00 00 00 0f 84 71 ff ff ff 45 31 c0 b9 01 00 00 
00 48 89 da 4c 89 e6 48 89 ef e8 2a 94 ff ff 85 c0 0f 84 53 ff ff ff <0f> 0b e9 
4c ff ff ff be 03 00 00 00 48 89 df e8 be e9 ff ff 85 c0
[114708.274634] RSP: 0018:ac53c6e879b8

Bug#1060089: isc-dhcp: install dhclient into /usr/sbin, with DEP17 M18 diversions

2024-01-23 Thread Helmut Grohne

On Tue, Jan 23, 2024 at 01:29:51AM +0100, Chris Hofstaedtler wrote:
> Attached is an improved patch, that avoids the temporary file loss
> that could occur in the old version. This is mostly based on work by
> Helmut Grohne.

Thank you.

Reviewed-by: Helmut Grohne 

I could not identify issues. The begin-remove-after markup feels
slightly inconsistent as it partially cleans up the mitigation, but
cleaning up the part in -ddns using this simple markup is non-trivial
and keeping those snippets a little longer shall not cause breakage, so
while this isn't perfect, I think it's good to go as is.

I also locally built this change and performed bootstrap testing with
debootstrap, cdebootstrap and mmebstrap (which include isc-dhcp-client
in the larger variants).

> Please consider this version of the patch.

I second this request. I appreciate to have this resolved by the end of
February. Preferrably, we have this change in experimental for a few
days before transitioning to unstable to allow for more QA.

Helmut

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

2024-01-23 Thread David Bremner

Matthias Geiger  writes:

> * Package name: rust-toml2json
>   Version : 1.3.1
>   Upstream Contact: woodruffw
> * URL : https://github.com/woodruffw/toml2json
> * License : MIT
>   Programming Lang: Rust
>   Description : A very small CLI for converting TOML to JSON
>
> Filing on behalf on bremner. Since src: reserialize provides a toml2json
> binary it would have to be renamed. All its dependencies are in debin
> so this would be easy to package.

I inherited this "wish" from a private upstream project. I'm not sure
it's strictly needed or if I can use the one from "reserialize" with
some work. I did notice some grumbling about reserialize (don't
know/remember the specifics) and that the rust toml2json supports a -p
for pretty-print option, while reserialize apparently does not support
pretty-printing.

Bug#1061370: gcc-14 ftbfs on armel

2024-01-23 Thread Wookey

On 2024-01-23 09:01 +0100, Matthias Klose wrote:
> Package: src:gcc-14
> Version: 14-20240121-1
> Severity: important
> Tags: sid trixie ftbfs
> X-Debbugs-CC: debian-...@lists.debian.org
> 
> gcc-14 ftbfs on armel.  This is a long standing, re-occurring issue which
> never has been forwarded and committed by the armel ports to GCC upstream.
> Please do it.

Why do you want the armel porters to forward this bug upstream, when
forwarding bugs upstream is normally the package maintainers job?

I mean sure someone could do that, but it's probably not been done so
far becuase they thought you would.

Is your point that actually it's not just a matter of formwarding -
some armel-specific investigation is needed first to work out what's actually 
wrong?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

signature.asc
Description: PGP signature

Bug#1059915: [Pkg-shadow-devel] Bug#1059915: DEP17: move login and shadowconfig to /usr

2024-01-23 Thread Serge E. Hallyn

Hi,

fwiw this looks good to me.

thanks,
-serge

On Wed, Jan 03, 2024 at 02:59:32PM +0100, Helmut Grohne wrote:
> Source: shadow
> Version: 1:4.13+dfsg1-3
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
> 
> Hi,
> 
> We want to finalize the /usr-merge transition via DEP17 by moving all
> files to /usr. shadow is involved at this time, because login is
> installed by debootstrap. I'm attaching a patch that moves both login
> and shadowconfig. It seems fairly harmless to me and I think it can go
> to unstable directly. This patch should not be included in
> bookworm-backports or earlier. If you want to support backports, please
> use dh_movetousr instead.
> 
> Helmut

> diff --minimal -Nru shadow-4.13+dfsg1/debian/changelog 
> shadow-4.13+dfsg1/debian/changelog
> --- shadow-4.13+dfsg1/debian/changelog2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/changelog2024-01-03 11:41:32.0 
> +0100
> @@ -1,3 +1,10 @@
> +shadow (1:4.13+dfsg1-3.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * DEP17: Move login and shadowconfig to /usr. (Closes: #-1)
> +
> + -- Helmut Grohne   Wed, 03 Jan 2024 11:41:32 +0100
> +
>  shadow (1:4.13+dfsg1-3) unstable; urgency=medium
>  
>* Team upload
> diff --minimal -Nru shadow-4.13+dfsg1/debian/login.install 
> shadow-4.13+dfsg1/debian/login.install
> --- shadow-4.13+dfsg1/debian/login.install2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/login.install2024-01-03 11:00:47.0 
> +0100
> @@ -4,4 +4,4 @@
>  usr/bin/faillog
>  usr/bin/lastlog
>  usr/bin/newgrp
> -bin/login
> +bin/login usr/bin
> diff --minimal -Nru shadow-4.13+dfsg1/debian/passwd.install 
> shadow-4.13+dfsg1/debian/passwd.install
> --- shadow-4.13+dfsg1/debian/passwd.install   2023-10-15 19:10:52.0 
> +0200
> +++ shadow-4.13+dfsg1/debian/passwd.install   2024-01-03 11:01:01.0 
> +0100
> @@ -1,5 +1,5 @@
>  debian/default/useradd etc/default
> -debian/shadowconfig sbin
> +debian/shadowconfig usr/sbin
>  usr/bin/chage
>  usr/bin/chfn
>  usr/bin/chsh
> diff --minimal -Nru shadow-4.13+dfsg1/debian/rules 
> shadow-4.13+dfsg1/debian/rules
> --- shadow-4.13+dfsg1/debian/rules2023-10-15 19:10:52.0 +0200
> +++ shadow-4.13+dfsg1/debian/rules2024-01-03 11:00:01.0 +0100
> @@ -42,7 +42,7 @@
>   dh_install -a
>  ifeq ($(DEB_HOST_ARCH_OS),hurd)
>   # /bin/login is provided by the hurd package.
> - rm -f debian/login/bin/login
> + rm -f debian/login/usr/bin/login
>  endif
>  
>  override_dh_installpam:

> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#1061388: sbuild doesn't support autotpkgest-virt-incus: Error: mkdir /sbuild-nonexistent: permission denied

2024-01-23 Thread stefanor

Hi Debian (2024.01.23_13:41:47_+)
> D: Running command: incus exec autopkgtest-lxd-ltsezo -- strace -f -A -o 
> /tmp/strace.log env LC_ALL=C.UTF-8 LANG=en_US.UTF-8 HOME=/sbuild-nonexistent 
> DEB_BUILD_OPTIONS=parallel=16 SHELL=/bin/sh sh -c cd / && exec "$@" exec perl 
> -e

Err there was some debugging stuff in there, obviously :)

> This seems to be because "incus exec" is trying to write
> ~/.config/incus, but HOME has been set to /sbuild-nonexistent outside
> it.

Filed an incus upstream bug about handling this situation more
gracefully: https://github.com/lxc/incus/issues/422

Stefano

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

Bug#1061389: kstart: expired tickets after suspend/resume

2024-01-23 Thread Dietrich Clauss

Package: kstart
Version: 4.3-1
Severity: normal

Hi,

I use nslcd with sasl_mech GSSAPI to connect to an LDAP server.  nslcd
therefore invokes k5start to obtain a kerberos ticket and keep it alive
using the command line:

| /usr/bin/k5start -b -p /run/nslcd/k5start_nslcd.pid -o nslcd -g nslcd -m 600 
-f /etc/krb5.keytab -K 60 -u host/myhost.mydomain.mytld -k 
/var/run/nslcd/nslcd.tkt

which looks fine to me.  k5start wakes up every 60 minutes and renews
the ticket if necessary.

When the machine goes to sleep (suspend to ram and/or disk), the ticket
may expire nevertheless.  After resume, it takes up to 60 minutes until
k5start wakes up, notices that the ticket has expired and obtains a new
one.

One could now use a smaller value for the "-K" on machines which use the
suspend functionality, or restart nslcd on each resume, but I'd consider
these are only workarounds.

In my opinion kstart is responsible here.  It should provide a service
that triggers on resume and wakes up all running instances of k5start so
they can immediately check their tickets.

Thanks,
- Dietrich

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

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

Versions of packages kstart depends on:
ii  libc6 2.36-9+deb12u3
ii  libkeyutils1  1.6.3-2
ii  libkrb5-3 1.20.1-2+deb12u1

kstart recommends no packages.

kstart suggests no packages.

-- no debconf information

Bug#1060401: ITP: python-scooby -- A lightweight tool for easily reporting your Python environment's package versions and hardware resources

2024-01-23 Thread Andreas Tille

Hi,

Am Tue, Jan 23, 2024 at 12:24:33PM +0100 schrieb Francesco Ballarin:
> thanks for your offer to help.
> 
> I have a first draft at
> https://salsa.debian.org/python-team/packages/python-scooby/-/merge_requests/1
> can you (alongside Drew) review that and suggest any change I need to make 
> before the MR can be accepted?

I consider the MR process as an unnecessary additional step which I have
never seen before.  While it is fine for me I'd say feel free to push
directly to the default packaging branch.

I've did some nitpicking changes and sponsored the package to new.

Thanks a lot for your work on this
   Andreas. 

-- 
http://fam-tille.de

Bug#1061388: sbuild doesn't support autotpkgest-virt-incus: Error: mkdir /sbuild-nonexistent: permission denied

2024-01-23 Thread Stefano Rivera

Package: sbuild
Version: 0.85.4
Severity: normal

I have been successfully using sbuild with lxd (installed from snap) for
a couple of years now, via the autopkgtest build backend.

Migrating to incus broke sbuild, resulting in:

D: Running command: incus exec autopkgtest-lxd-ltsezo -- strace -f -A -o 
/tmp/strace.log env LC_ALL=C.UTF-8 LANG=en_US.UTF-8 HOME=/sbuild-nonexistent 
DEB_BUILD_OPTIONS=parallel=16 SHELL=/bin/sh sh -c cd / && exec "$@" exec perl -e
...
Error: mkdir /sbuild-nonexistent: permission denied
D: Error run_chroot_session(): Error locking chroot session: skipping 
beautifulsoup4Keeping session: /tmp/autopkgtest.f2BSkb
D: Setting Session=undef
D: Error run_chroot(): Error locking chroot session: skipping beautifulsoup4E: 
Error locking chroot session: skipping beautifulsoup4
D: Setting Pkg Status=failed
D: Setting Pkg Fail Stage=lock-session

This seems to be because "incus exec" is trying to write
~/.config/incus, but HOME has been set to /sbuild-nonexistent outside
it.

https://github.com/lxc/incus/blob/e5690705e842d3961d8a1d18c0ec002c25345af8/cmd/incus/main_aliases.go#L162-L175

I think Sbuild could not set HOME as part of the environment when
calling the autopkgtest backend. It is explicitly set via the env
command in the arguments to the backend, so it souldn't be set outside
it too.

There are also other ways this could be hacked around...
Locally, I'll set INCUS_CONF, to override the HOME.

Stefano

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
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 sbuild depends on:
ii  adduser 3.137
ii  libsbuild-perl  0.85.4
ii  perl5.38.2-3

Versions of packages sbuild recommends:
ii  autopkgtest  5.32
ii  debootstrap  1.0.134
ii  schroot  1.6.13-3+b3
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.47.0-2+b1
ii  kmod   31-1
ii  wget   1.21.4-1+b1

-- no debconf information

Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates

2024-01-23 Thread Maytham Alsudany

Hi Drew,

On Tue, 2024-01-23 at 11:24 +0100, Drew Parsons wrote:
> > > Hi Maytham, I can upload it.  But note how pkcs11 is failing on 32 bit
> > > arches.  That needs to be sorted out.  I had been waiting for that
> > > before uploading enterprise-certificate-proxy.
> > 
> > https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/merge_requests/2
> > 
> > go-pkcs11 builds successfully and passes autopkgtest, lintian, and 
> > piuparts on
> > both amd64 and i386.
> 
> The problem is on debci. See the failing tests at
>   https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/
> 
> summarised also at 
> https://tracker.debian.org/pkg/golang-github-google-go-pkcs11

I'm aware, and the PR I've linked is a fix, please have a look.

You can look at the patch file itself at [1] (have a look at the description to
understand what the PR/patch does).

Kind regards,
Maytham

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/blob/ca5af6f1b97697193ea53318225ca4f9e43da292/debian/patches/use-uint-for-32-bit-builds.patch


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

Bug#1061387: Assumes dark background

2024-01-23 Thread Stéphane Glondu

Package: debgpt
Version: 0.4.94
Severity: wishlist

Dear Maintainer,

It seems that debgpt assumes a terminal with dark background: it
prints stuff in yellow, which is barely readable with a light
background. It would be nice if there were a light background mode
(and/or a no-color mode).


Cheers,

-- 
Stéphane


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

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

Versions of packages debgpt depends on:
ii  python3 3.11.4-5+b1
ii  python3-bs4 4.12.2-2
ii  python3-openai  1.6.1-2
ii  python3-prompt-toolkit  3.0.43-1
ii  python3-requests2.31.0+dfsg-1
ii  python3-rich13.3.1-2
ii  python3-tomli   2.0.1-2

Versions of packages debgpt recommends:
ii  git  1:2.43.0-1
ii  man-db   2.12.0-3
ii  python3-zmq  24.0.1-5+b1
pn  tldr 

Versions of packages debgpt suggests:
pn  python3-torch | python3-torch-cuda | python3-torch-rocm  
pn  python3-transformers 

-- no debconf information

Bug#1061386: libxtensor-dev: Fails to install for arm64 arch on amd64

2024-01-23 Thread Tomeu Vizoso

Package: libxtensor-dev
Version: 0.24.3-1
Severity: important
X-Debbugs-Cc: to...@tomeuvizoso.net

Dear Maintainer,

I'm not able to install the package for architecture arm64 on amd64:

+ apt-get install -y --no-remove libxtensor-dev:arm64 xtl-dev
Reading package lists...
Building dependency tree...
Reading state information...
xtl-dev is already the newest version (0.7.2-2.1).
xtl-dev set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 libxtensor-dev:arm64 : Depends: xtl-dev:arm64 (>= 0.7.0~) but it is not 
installable
Depends: xtl-dev:arm64 (< 0.8) but it is not installable
E: Unable to correct problems, you have held broken packages.

Guess it is related to xtl-dev being Architecture:all, but
libxtensor-dev being architecture-specific.

-- System Information:
(snip: not sending from the system that reproduces the problem)

Versions of packages libxtensor-dev depends on:
ii  nlohmann-json3-dev  3.11.3-1
ii  xtl-dev 0.7.5-3

libxtensor-dev recommends no packages.

Versions of packages libxtensor-dev suggests:
pn  xtensor-doc  

-- debconf-show failed

Bug#1060705: grub-pc: Symbol grub_env_get not found

2024-01-23 Thread Julian Andres Klode

Control: tag -1 moreinfo

On Sat, Jan 13, 2024 at 11:48:21AM +0100, Bastian Germann wrote:
> Package: grub-pc
> Severity: grave
> Version: 2.12~rc1-12+b1
> 
> Hi,
> 
> Booting my i386 sid installation after an update fails because grub cannot 
> find one of its symbols.
> I cannot even boot to an initramfs but I can run a grub shell.
> 
> I guess this is an issue introduced by the recent binNMU because I think 
> before I have updated to 2.12~rc1-12.
> Thanks for any hint.

This is missing grub-install log that triggers the bug at the
very least. I wouldn't know why this would happen in a binNMU,
it sounds like your install is messed up somehow, like the core.img
rebuilt but not modules or something.

Does 2.12~rc1-13 work? Does 2.12-1 work which I just uploaded? 

If I don't hear other reports this week I'll have to assume that's a
fluke on your end - weird things happen sometimes - and close it.

testing is still at 2.06, and that's an untenable situation and we
do not have the means to go debug every single machine out there.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1052826: Broken entrypoints package: actually a pybuild issue?

2024-01-23 Thread julien . puydt

Hi,

I found the source of the breakage for the entrypoints package: its
tests/samples/ directory contains a few files describing mock Python
packages, and the tests consist in running functions on those and check
the answers match what is expected.

Alas, something (and I suspect pybuild) removes the *.egg-info
directories there, so of course results don't match.

I see two ways out:

(1) configure something so tests/samples/ doesn't get touched ;

(2) patch the tests to adapt them to the modified directories.


Solution (2) is pretty fast, pretty easy and extremely dirty: it will
need an update for each upstream change and that basically means the
tests don't actually test anything.

Solution (1) is much more reliable, but I neither know if it's possible
nor how - can someone lend a hand?

Thanks!

J.Puydt

PS: the patch would be that ugly:

Description: fix bug #1052826 (broken tests)
Author: Julien Puydt
Forwarded: not needed
--- entrypoints.orig/tests/test_entrypoints.py
+++ entrypoints/tests/test_entrypoints.py
@@ -19,31 +19,31 @@
 
 def test_iter_files_distros():
 result = entrypoints.iter_files_distros(path=sample_path)
-# the sample_path has 4 unique items so iter_files_distros returns
4 tuples
-assert len(list(result)) == 4
+# the sample_path has 3 unique items so iter_files_distros returns
3 tuples
+assert len(list(result)) == 3
 
 # testing a development, egg aka installed with pip install -e .
 # these don't have version info in the .egg-info directory name
 # (eg dev-0.0.1.egg-info)
 path_with_dev = [osp.join(samples_dir, 'packages4')]
 result = entrypoints.iter_files_distros(path=path_with_dev)
-assert len(list(result)) == 1
+assert len(list(result)) == 0
 
 # duplicate dev versions should still return one result
 path_with_dev_duplicates = path_with_dev * 2
 result =
entrypoints.iter_files_distros(path=path_with_dev_duplicates)
-assert len(list(result)) == 1
+assert len(list(result)) == 0
 
 def test_get_group_all():
 group = entrypoints.get_group_all('entrypoints.test1',
sample_path)
 print(group)
-assert len(group) == 5
-assert {ep.name for ep in group} == {'abc', 'rew', 'opo', 'njn'}
+assert len(group) == 3
+assert {ep.name for ep in group} == {'abc', 'rew', 'njn'}
 
 def test_get_group_named():
 group = entrypoints.get_group_named('entrypoints.test1',
sample_path)
 print(group)
-assert len(group) == 4
+assert len(group) == 3
 assert group['abc'].module_name == 'foo'
 assert group['abc'].object_name == 'abc'

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

2024-01-23 Thread Julian Andres Klode

Control: severity -1 important

On Sat, Nov 25, 2023 at 05:36:41PM -0500, Nicolas Haller wrote:
> Package: grub-efi-amd64
> Version: 2.06-13
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> My old laptop (Lenovo 11e) runs Sid and all was right before I updated
> it the other day (I don't do that very often). After that upgrade, GRUB
> wasn't able to load any kernel with the pretty much generic error
> "Error: can't load image". The version of GRUB was 2.12~rc1-12.
> If I try to boot again, GRUB tells me that I need to load the image
> first (I guess it somehow ignores the linux command and sends that when
> trying to load the initrd).

I'm downgrading this bug severity, as a single system regressing in
boot ability is not release critical. It is not possible for us to
ensure that grub continues working on every single device out there,
this grub will work for more hardware than previous grubs, and blocking
the transition to testing because it doesn't work on your 11e is not
helping anyone.

We have now also uploaded 2.12-1 and of course we welcome any patches,
but an old Lenovo 11e is not a priority, and we don't have any to test
ourselves.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1059828: colourised crontab -l output is unreadable

2024-01-23 Thread Stéphane Blondon

Le dim. 21 janv. 2024 à 17:16, Georges Khaznadar
 a écrit :
> Can users easily customize their color preferences with batcat?

Yes, `bat` provides several themes (shown with `bat --list-themes`).

It's also possible to create its own theme:
https://github.com/sharkdp/bat#adding-new-themes


Regards,
-- 
Stéphane

Bug#1061366: python3.12: Python3.12 segfaults on python-xarray testsuite

2024-01-23 Thread Julian Gilbey

reassign 1061366 python3-xarray
thanks

On Tue, Jan 23, 2024 at 07:19:35AM +, Alastair McKinstry wrote:
> Package: python3.12
> Version: 3.12.1-2
> Severity: serious
> Justification: 4
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
> 
> Python3.12 segfaults on the unittest suite for python-xarray
> (2024.01.0, head of tree in debian/latest)
> Unfortunately I cannot get a core dump yet to be more specific; this is on 
> arm64 at least.
> 
> 
> 
> -- System Information:
> Debian Release: 12.4
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#1060270: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17

2024-01-23 Thread Guilhem Moulin

Hi,

On Tue, 23 Jan 2024 at 10:15:02 +0100, Raphael Hertzog wrote:
> when do you plan to upload a cryptsetup moving the files to /usr?

I can have a look after the week-end or in early February.  There are
other issues I'd like to fix in the next upload.

| I see that this may sound scary. We'll get past this mess together. If
| things break, I'll keep the pieces and I've done so for molly-guard
| already.

Thanks!  It looks specially scary indeed with the several iterations of
the attached patch :-)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1043240: transition: pandas 1.5 -> 2.1

2024-01-23 Thread Julian Gilbey

On Mon, Jan 22, 2024 at 08:50:55PM +, Rebecca N. Palmer wrote:
> On 22/01/2024 11:51, Julian Gilbey wrote:
> > Please could we wait until the "Python 3.12 is a supported version"
> > transition is completed?
> 
> How are you defining that?  python3-defaults 3.11.6+ in testing?  (I was
> previously told 3.12-supporting pandas and numpy in testing, which has
> happened.  I don't think any of these 25 packages are on
> https://qa.debian.org/excuses.php?package=python3-defaults , but I haven't
> checked carefully, and at least influxdb-python and tqdm do have what I
> suspect are Python 3.12 related issues.)

https://release.debian.org/transitions/html/python3.12-add.html

We're nearly there (the transition page says it's 99% done), and when
this transition is complete, then python3-defaults 3.11.6+ will be
able to migrate to testing.

I don't fully understand the problem with transitions, but there was a
request to hold back with significant upgrades until a
python3.12-supporting python3-defaults has reached testing.

> > Adding another 25 or so RC bugs at this
> > point will just slow down that transition.
> 
> What exactly do you want not done until then?   Just not uploading pandas
> 2.x to unstable, or is it also a problem to have these bugs marked as RC in
> the BTS?  (In all 22 cases that are in testing at all, the bug is also
> present in the version in testing, so it being RC shouldn't block
> migration.)

Yes - please don't upload it to unstable yet.  Uploading to
experimental is fine.

> > (Unless pandas 1.5 is
> > preventing the transition, that is.)
> 
> It isn't.

Good!

   Julian

Bug#1061282: gtk crashes (fixed)

2024-01-23 Thread Daniel Suchy


I can confirm version 3.24.40-2 fixes this issue for me.

Bug#1061385: golang-github-google-go-pkcs11: tests fail on 32 bit architectures

Source: golang-github-google-go-pkcs11
Version: 0.3.0+dfsg-1
Severity: serious
Justification: debci
Control: block 1024276 by -1

go-pkcs11 tests are failing on 32-bit architectures (armel, armhf, i386),
see https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/

This is preventing migration to testing,
see https://tracker.debian.org/pkg/golang-github-google-go-pkcs11
and therefore blocking processing of
golang-github-googleapis-enterprise-certificate-proxy

Excerpt from the test log for i386 reports

 ...
 79s crypto/x509
 79s github.com/google/go-pkcs11/pkcs11
 82s # github.com/google/go-pkcs11/pkcs11
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:300:33: cannot use 
(_Ciconst_sizeof_CK_UTF8CHAR) * _Ctype_ulong(len(s)) (value of type 
_Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc)
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1019:38: cannot use 
_Ctype_ulong(n) (value of type _Ctype_ulong) as _Ctype_uint value in argument 
to (_Cfunc__CMalloc)
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1100:33: cannot use 
attrs[0].ulValueLen * (_Ciconst_sizeof_CK_BYTE) (value of type _Ctype_ulong) as 
_Ctype_uint value in argument to (_Cfunc__CMalloc)
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1104:33: cannot use 
attrs[1].ulValueLen (variable of type _Ctype_ulong) as _Ctype_uint value in 
argument to (_Cfunc__CMalloc)
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1137:37: cannot use 
attrs[0].ulValueLen (variable of type _Ctype_ulong) as _Ctype_uint value in 
argument to (_Cfunc__CMalloc)
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1141:37: cannot use 
attrs[1].ulValueLen (variable of type _Ctype_ulong) as _Ctype_uint value in 
argument to (_Cfunc__CMalloc)
 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1440:35: cannot use 
_Ctype_ulong(n) (value of type _Ctype_ulong) as _Ctype_uint value in argument 
to (_Cfunc__CMalloc)
 82s dh_auto_build: error: cd _build && go install -trimpath -v -p 2 
github.com/google/go-pkcs11/pkcs11 returned exit code 1

Bug#1060401: ITP: python-scooby -- A lightweight tool for easily reporting your Python environment's package versions and hardware resources


On 2024-01-23 12:20, Andreas Tille wrote:

Hi,

I've seen your commits to DPT on salsa.  Do you need any help to
create a debian/ dir which does not exist yet?

Kind regards
   Andreas.



Hi Andreas, Francesco has prepared a debian dir in an MR on salsa.
Would be great if you could review the MR and merge
(for my part it looks fine to me)


Drew

Bug#1060401: ITP: python-scooby -- A lightweight tool for easily reporting your Python environment's package versions and hardware resources

2024-01-23 Thread Francesco Ballarin

Hi Andreas,
thanks for your offer to help.

I have a first draft at
https://salsa.debian.org/python-team/packages/python-scooby/-/merge_requests/1
can you (alongside Drew) review that and suggest any change I need to make 
before the MR can be accepted?

Cheers,
Francesco


On Tue, Jan 23, 2024 at 12:21 PM Andreas Tille 
mailto:andr...@an3as.eu>> wrote:
Hi,

I've seen your commits to DPT on salsa.  Do you need any help to
create a debian/ dir which does not exist yet?

Kind regards
   Andreas.

--
http://fam-tille.de
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg]

Bug#1061384: acl2: add support for loongarch64

2024-01-23 Thread zhangdandan


Source: acl2
Version: 8.5dfsg-5
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Maybe we need to add LoongArch support in 
books/kestrel/x86/parsers/parse-pe-file.lisp.

Refer to riscv64, please consider the patch I have attached.
If you have better modification suggestions, please help us fix this patch.

I would like to remind you that the compilation dependency of acl2 is 
not yet satisfied. Depends on the gcl ( >= 2.6.14-1) package when 
compiling acl2.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

Description: Add PE header machine type for LoongArch
Last-Update: 2024-01-23

--- acl2-8.5dfsg.orig/books/kestrel/x86/parsers/parse-pe-file.lisp
+++ acl2-8.5dfsg/books/kestrel/x86/parsers/parse-pe-file.lisp
@@ -93,6 +93,8 @@
 (#xebc . :IMAGE_FILE_MACHINE_EBC)
 (#x14c . :IMAGE_FILE_MACHINE_I386)
 (#x200 . :IMAGE_FILE_MACHINE_IA64)
+(#x6232 . :IMAGE_FILE_MACHINE_LOONGARCH32)
+(#x6264 . :IMAGE_FILE_MACHINE_LOONGARCH64)
 (#x9041 . :IMAGE_FILE_MACHINE_M32R)
 (#x266 . :IMAGE_FILE_MACHINE_MIPS16)
 (#x366 . :IMAGE_FILE_MACHINE_MIPSFPU)

Bug#1060401: ITP: python-scooby -- A lightweight tool for easily reporting your Python environment's package versions and hardware resources

2024-01-23 Thread Andreas Tille

Hi,

I've seen your commits to DPT on salsa.  Do you need any help to
create a debian/ dir which does not exist yet?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1055779: manuskript: Crash selecting templates

2024-01-23 Thread Miriam Ruiz

Hi,

I uploaded 0.16.1 to Debian yesterday. I can confirm that I can
replicate the bug you're describing in my setup with 0.15.0-1, but it
doesn't seem to happen with 0.16.1-1.

Can you confirm if the newer version fixes it for you too?

Thanks,
Miry

El sáb, 11 nov 2023 a las 13:15, Fenix F. () escribió:
>
> Package: manuskript
> Version: 0.15.0-1
> Severity: normal
> X-Debbugs-Cc: fenix...@gmail.com
>
> Dear Maintainer,
>
>* What led up to the situation?
>
>1) Open Manuskript.
>2) Select one template, for example, Empty Fiction.
>3) Select another template, for example, Short Story.
>4) Select Empty Fiction again.
>
>Manuskript crash with this log:
>
> ---
> CRITICAL> An unhandled exception has occurred!
> Traceback (most recent call last):
>   File "/usr/share/manuskript/manuskript/ui/welcome.py", line 260, in
> changeTemplate
> self.updateTemplate()
>   File "/usr/share/manuskript/manuskript/ui/welcome.py", line 329, in
> updateTemplate
> self.updateWordCount()
>   File "/usr/share/manuskript/manuskript/ui/welcome.py", line 370, in
> updateWordCount
> self.template[1][templateIndex][1])
> ^^^
> IndexError: list index out of range
> ---
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages manuskript depends on:
> ii  libqt5svg5  5.15.10-2
> ii  python3 3.11.4-5+b1
> ii  python3-enchant 3.2.2-1
> ii  python3-lxml4.9.3-1
> ii  python3-markdown3.4.4-1
> ii  python3-pyqt5   5.15.10+dfsg-1
> ii  python3-pyqt5.qtwebkit  5.15.10+dfsg-1
> ii  zlib1g  1:1.2.13.dfsg-3
>
> Versions of packages manuskript recommends:
> ii  pandoc  2.17.1.1-3
>
> Versions of packages manuskript suggests:
> pn  texlive-latex-recommended  
>
> -- no debconf information

Bug#1056906: debuild: cannot disable lintian

2024-01-23 Thread Fabio Pedretti

Please close this issue. Thanks.

Bug#1061174: src:gmsh: fails to migrate to testing for too long: causes timeout of pygmsh autopkgtest on i386

2024-01-23 Thread Francesco Ballarin

Package: gmsh
Followup-For: Bug #1061174
X-Debbugs-Cc: francesco.balla...@unicatt.it

Dear Paul Gevers,
we fixed the timeout of pygmsh autopkgtest on i386 with pygmsh 7.1.17-4,
as confirmed by https://ci.debian.net/packages/p/pygmsh/testing/i386/42002594/

Cheers,
Francesco Ballarin

Bug#1061383: Fwd: [Podman] Podman v4.9.0 Released

2024-01-23 Thread Reinhard Tartler

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Ashley Cui 
Date: Mon, Jan 22, 2024, 21:00
Subject: [Podman] Podman v4.9.0 Released
To: , 


We’re excited to announce that Podman v4.9.0 has been released! Here's
what's new:

Features

   - The podman farm suite of commands for multi-architecture builds is now
   fully enabled and documented.
   - Add a network recovery service to Podman Machine VMs using the QEMU
   backend to detect and recover from an inoperable host networking issues
   experienced by Mac users when running for long periods of time.

Bugfixes

   - Fixed a bug where the HyperV provider for podman machine did not
   forward the API socket to the host machine.
   - Fixed a bug where improperly formatted annotations passed to podman
   kube play could cause Podman to panic.
   - Fixed a bug where podman system reset could fail if non-Podman
   containers (e.g. containers created by Buildah) were present.

Misc

   - Containers run in podman machine VMs now default to a PID limit of
   unlimited, instead of 2048.

 Try it out and let us know what you think!


-- 
Ashley Cui
___
Podman mailing list -- pod...@lists.podman.io
To unsubscribe send an email to podman-le...@lists.podman.io

Bug#1059104: rust-toml: please upgrade to v0.8

2024-01-23 Thread Peter Green

preliminary analysis.

rdeps of rust-toml-0.7:

elan
uses 0.5 upstream, can presumablly go back to 0.5 if going forward is not
possible.

precious
uses 0.8 upstream, debian is currently downpatching

rust-cargo
uses 0.8 upstream, debian is currently some way behind upstream, but upstream
did not make any code changes when bumping dep.

rust-cargo-c
uses 0.8 upstream, debian is currently some way behind upstream, but upstream
did not make any code changes when bumping dep.

rust-cargo-config2
latest upstream has moved from toml to toml-edit which will be updated as
part of this task. Latest upstream tested and uploaded to experimental.

rust-cargo-mutants
uses 0.8 upstream, debian is currently some way behind upstream, but upstream
did not make any code changes when bumping dep.

rust-cargo-outdated
still on 0.7 upstream, builds and tests ok with the new version, upstream
issue opened (but I may still go ahead without them if they don't respond).
https://github.com/kbknapp/cargo-outdated/issues/382

rust-debcargo
still on 0.7 upstream, builds and tests ok with the new version, "upstream"
issue opened.
https://salsa.debian.org/rust-team/debcargo/-/issues/65

rust-ntpd
allows versions 0.5 through 0.7 upstream. upstream issue opened,
not in testing. Test situation seems no worst with dependency bumped
I've filed an upstream issue but I probablly won't wait for this.
https://github.com/pendulum-project/ntpd-rs/issues/1307

rust-parsec-service
upstream uses 0.8, Debian is currently downpatching.

rust-repro-env
upstream uses 0.8, Debian is currently downpatching.

rust-sniffglue
upstream uses 0.8, Debian is currently downpatching.

rust-system-deps
upstream uses 0.8, Debian is currently downpatching.

rust-tree-sitter-cli
uses 0.5 upstream, build-time dependency only. can presumablly go back to 0.5
if going forward is not possible.

rust-version-sync
jonas package, still on 0.7 upstream, optional dependency that does not seem
to be used by anything in Debian.

rust-toml-edit reverse dependencies

btm
bumped to 0.21 in upstream git, upstream bumped with no code changes.
jonas already acked update in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053955#17

python-maturin
uses 0.21 upstream, debian package currently has no upper limit and builds
succesfully
with 0.21. No autopkgtests.

rust-cargo
uses 0.20 upstream, did not make any code changes when bumping from 0.19 to
0.20

rust-gst-plugin-version-helper
uses 0.20 in latest upstream release. Upstream git uses 0.21, upstream
dependency bump involved no code changes but did involve a feature change

https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/commit/a8205d5b5d1178873ad0ba4d1cfa2c71ae922a3a

rust-rstest-test
uses 0.19 upstream, only used as a test crate for rust-rstest-*. builds
and tests ok with dependency bumped.

rust-trycmd
upstream uses 0.21, dependency is already relaxed in Debian.

Bug#159838: [Bug debug/7853] gcc reports multiple symbol definitions on the wrong line

2024-01-23 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.2.1, 4.3.4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Richard Biener  ---
Fixed.  I can't reproduce, not even with stabs (where I don't see any line info
but probably due to too recent gdb).  With dwarf it's also correct with GCC
4.3.

-- 
You are receiving this mail because:
You reported the bug.

Bug#1061382: jitterplot: missing rt dep to python3-pandas

2024-01-23 Thread Felix Moessbauer

Package: jitterdebugger-utils
Version: 0.3.1+git20200117.b90ff3a-4
Severity: important

Dear Maintainer,

the jitterplot utility needs python pandas. By that, the dependency to
python3-pandas needs to be added. A fix is provided in [1]

[1] https://salsa.debian.org/debian/jitterdebugger/-/merge_requests/1

Best regards,
Felix Moessbauer
Siemens AG

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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 jitterdebugger-utils depends on:
ii  gir1.2-gtk-3.0  3.24.38-2~deb12u1
ii  libc6   2.36-9+deb12u3
ii  python3 3.11.2-1+b1
ii  python3-matplotlib  3.6.3-1+b1

Versions of packages jitterdebugger-utils recommends:
ii  jitterdebugger  0.3.1+git20200117.b90ff3a-4

jitterdebugger-utils suggests no packages.

-- no debconf information

Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates

On 2024-01-23 11:08, Maytham Alsudany wrote:

Hi Drew,

On Tue, 2024-01-23 at 09:12 +0100, Drew Parsons wrote:

On 2024-01-23 07:51, Maytham Alsudany wrote:
> Hi Drew,
>
> Now that golang-github-google-go-pkcs11 has been uploaded and accepted,
> is it
> possible for you to now upload
> golang-github-googleapis-enterprise-certificate-
> proxy?
>

Hi Maytham, I can upload it.  But note how pkcs11 is failing on 32 bit
arches.  That needs to be sorted out.  I had been waiting for that
before uploading enterprise-certificate-proxy.

https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/merge_requests/2

go-pkcs11 builds successfully and passes autopkgtest, lintian, and 
piuparts on

both amd64 and i386.

The problem is on debci. See the failing tests at
 https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/

summarised also at 
https://tracker.debian.org/pkg/golang-github-google-go-pkcs11

Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates

2024-01-23 Thread Maytham Alsudany

Hi Drew,

On Tue, 2024-01-23 at 09:12 +0100, Drew Parsons wrote:
> On 2024-01-23 07:51, Maytham Alsudany wrote:
> > Hi Drew,
> > 
> > Now that golang-github-google-go-pkcs11 has been uploaded and accepted, 
> > is it
> > possible for you to now upload 
> > golang-github-googleapis-enterprise-certificate-
> > proxy?
> > 
> 
> Hi Maytham, I can upload it.  But note how pkcs11 is failing on 32 bit 
> arches.  That needs to be sorted out.  I had been waiting for that 
> before uploading enterprise-certificate-proxy.

https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/merge_requests/2

go-pkcs11 builds successfully and passes autopkgtest, lintian, and piuparts on
both amd64 and i386.


Kind regards,
Maytham


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

Bug#1061381: rust-subtle: please update to v2.5.0