Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

On 15/11/2023 13:47, Bálint Réczey wrote:

Hi Colin,

There are a few upstream source files licensed under GPL.
Please update debian/copyright to cover all the used licenses.


Updated and uploaded -3 to mentors

Thanks for the prompt review feedback. Much appreciated.

Colin



You can run 'cme update dpkg-copyright' in the source directory or any 
other tool from https://wiki.debian.org/CopyrightReviewTools 
 to help with the manual 
labor.


Cheers,
Balint

On 2023. Nov 15., Wed at 10:27, Bálint Réczey > wrote:


Hi Colin,

Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
nov. 14., K, 17:58):
 >
 > Hi Balint,
 >
 > I've uploaded 0.4.0-2 with the suggested fixes.
 >
 > reply inlined below:
 >
 > On 09/11/2023 16:23, Bálint Réczey wrote:
 > > Hi Colin,
 > >
 > > Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
 > > nov. 7., K, 15:18):
 > >>
 > >> Hi Balint,
 > >>
 > >> Thanks for responding with the review. I was waiting for the
upstream
 > >> project to release a 0.4 with some minor fixes before
re-uploading to
 > >> mentors.
 > >>
 > >> I've addressed the issues you found as below:
 > >
 > > Please see my observations below.
 > >
 > >> On 22/10/2023 22:38, Bálint Réczey wrote:
 > >>> Hi Colin,
 > >>>
 > >>> I've checked the second upload at [1].
 > >>> As you can see in the Lintian warnings there is a .git
directory which
 > >>> is not ideal for a source package.
 > >>> I suggest using the most widely used git-buildpackage based
workflow
 > >>> where the gbp command takes care of exporting the source package
 > >>> without the .git dir from the packaging repository.
 > >>> I'd be happy to set up a packaging repo for you at
 > >>> https://salsa.debian.org/debian/libtypec
 and add you as a maintainer
 > >>> as described in [2]
 > >
 > > I still hold up my offer about setting up a git repo for
packaging on
 > > Salsa. That comes with the benefit of automated fixes from Debian
 > > Janitor and I could also comment on changes right where they
happened.
 >
 > Thank you for your kind offer; I definitely think this is a good
idea,
 > please can you set this up for me. Much appreciated!

I've created the repo at https://salsa.debian.org/debian/libtypec
 and
added you as a maintainer.
I've also set up CI, thus when you push your branches the pipelines
will start.

You may already be familiar with
https://dep-team.pages.debian.net/deps/dep14/
 , but if not, please
check it before pushing your packaging repository.

...

 > > I think my comment here was misleading, sorry for that.
 > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
dir as a
 > > result of specifying .../libtypec.pc as the target dir in the
.install
 > > file was not desired. It was even patched to have the right
content.
 > > Please ship the .pc file in the -dev package.
 >
 > Fixed.

The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch.

...

 > > * As you switched back to use upstream's 0.4.0 SO version the
.symbols
 > > file became wrong  not matching the shipped SO version. Please fix
 > > that and also switch to the libtypec0 package name since it
needs to
 > > match upstream's major SO version
 >
 > Fixed.

The .symbols file's first line should be:
  libtypec.so.0 libtypec0 #MINVER#

See deb-symbols(5) for more details.

 > .
 > >
 > > * I'd recommend asking upstream to switch to semantic SO versioning
 > > instead of using the project's version and switching to major
version
 > > 1 when the API stabilized.
 >
 > Good idea. Will do when API changes and stabilizes.

Great!

Cheers,
Balint

 > Colin
 >
 > >
 > > Cheers,
 > > Balint
 > >
 > >> Kind regards,
 > >>
 > >> Colin
 > >>
 > >>
 > >>> Cheers,
 > >>> Balint
 > >>>
 > >>> [1] https://mentors.debian.net/package/libtypec/

 > >>> [2]
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group 

 > >>>
 > >>> On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 > >>> mailto:colin.i.k...@gmail.com>> wrote:
 >  Hi,
 > 
 >  I've uploaded a fixed package that addresses these 

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Paul Gevers]

Hi,

On Thu, 12 Oct 2023 06:36:05 +0200 Jonas Smedegaard  wrote:

Quoting Scott Talbert (2023-10-12 02:33:45)
> It looks like pandoc can be updated to v3.0.1 and be compatible with the 
> dependencies that are in unstable currently (LTS 21).  Can you please let 
> us know if there are any dependencies still missing?



I will look at it soon - probably this upcoming weekend.


Is there any progress with fixing this bug? It seems that this issue is 
one of the last blocking issues in the haskell transition. src:pandoc is 
a key package, we can't easily remove it from testing to "fix" the blockage.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052277: Bumping severity to important, 2 weeks till RC

[Luca Boccassi]

Control: severity -1 important

Hi,

As requested by Helmut, bumping severity of these bugs to important.
systemd.pc will be changed to point to /usr in 2 weeks (November 30th),
at which point the severity will be bumped again to RC for all these
bugs.

-- 
Kind regards,
Luca Boccassi


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

Bug#1056050: mate-power-manager: Non-installable on hurd-i386

[Svante Signell]

Source: mate-power-manager
Version: 1.26.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

mate-power-manager is not installable on hurd-i386 due to dependencies on
polkitd, pkexec, and systemd or elogind which are only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!







--- a/debian/control	2023-11-15 12:36:26.0 +0100
+++ b/debian/control	2023-11-15 12:26:19.0 +0100
@@ -26,7 +26,7 @@
libxrandr-dev,
mate-common (>= 1.24.0-1~),
pkg-config,
-   polkitd,
+   polkitd [linux-any],
xmlto,
yelp-tools,
 Standards-Version: 4.6.2
@@ -40,8 +40,8 @@
 Depends: default-dbus-session-bus | dbus-session-bus,
  mate-notification-daemon | notification-daemon,
  mate-power-manager-common (= ${source:Version}),
- polkitd, pkexec,
- systemd | elogind | consolekit,
+ polkitd [linux-any] , pkexec [linux-any],
+ systemd [linux-any] | elogind [linux-any] | consolekit,
  upower,
  ${misc:Depends},
  ${shlibs:Depends},

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Vincent Lefevre]

Package: reportbug
Version: 12.0.0
Severity: normal

In it search for newer versions of the package, reportbug outputs

  Checking for newer versions at madison and 
https://ftp-master.debian.org/new.html

However, /usr/lib/python3/dist-packages/reportbug/checkversions.py
has

NEWQUEUE_URL = 'http://ftp-master.debian.org/new.822'

In the strace output, I can see

193537 connect(45, {sa_family=AF_INET, sin_port=htons(80), 
sin_addr=inet_addr("192.91.235.231")}, 16) = -1 EINPROGRESS (Operation now in 
progress)
193537 poll([{fd=45, events=POLLOUT|POLLERR}], 1, 6) = 1 ([{fd=45, 
revents=POLLOUT}])
193537 getsockopt(45, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
193537 poll([{fd=45, events=POLLOUT}], 1, 6) = 1 ([{fd=45, 
revents=POLLOUT}])
193537 sendto(45, "GET /new.822 HTTP/1.1\r\nHost: 
ftp-master.debian.org\r\nUser-Agent: reportbug/12.0.0 
(Debian)\r\nAccept-Encoding: gzip;q=1.0, deflate;q=0.9, 
identity;q=0.5\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n", 190, 0, NULL, 
0) = 190
193537 ioctl(45, FIONBIO, [1])  = 0
193537 poll([{fd=45, events=POLLIN}], 1, 6) = 1 ([{fd=45, revents=POLLIN}])
193537 recvfrom(45, "HTTP/1.1 301 Moved Permanently\r\nDate: Tue, 14 Nov 2023 
14:11:18 GMT\r\nServer: Apache\r\nX-Content-Type-Options: 
nosniff\r\nX-Frame-Options: sameorigin\r\nReferrer-Policy: 
no-referrer\r\nX-Xss-Protection: 1\r\nPermissions-Policy: 
interest-cohort=()\r\nLocation: 
https://ftp-master.debian.org/new.822\r\nContent-Length: 316\r\nKeep-Alive: 
timeout=5, max=100\r\nConnection: Keep-Alive\r\nContent-Type: text/html; 
charset=iso-8859-1\r\n\r\n\n\n301 Moved 
Permanently\n\nMoved Permanently\nThe document 
has moved https://ftp-master.debian.org/new.822\;>here.\n\nApache
 Server at ftp-master.debian.org Port 80\n\n", 8192, 0, 
NULL, NULL) = 727

So this URL gives a 301 Moved Permanently with
https://ftp-master.debian.org/new.822 as the new URL,
and reportbug does not attempt to use this new URL.

So there are several issues:

1. The NEWQUEUE_URL URL is obsolete (this seems to have been fixed
in Git, but even unstable is still affected).

2. In the output, https://ftp-master.debian.org/new.html does not match
what is actually used (or is this on purpose in case this has the same
contents?).

3. The "301 Moved Permanently" is ignored. If this is on purpose,
I think that a warning should be output in order to be aware of the
issue, in case of a future move.

-- Package-specific info:
** Environment settings:
EDITOR="/home/vinc17/bin/eclient"
PAGER="less -Lis"
VISUAL="/home/vinc17/bin/eclient"
EMAIL="vinc...@vinc17.net"
INTERFACE="text"

** /home/vinc17/.reportbugrc:
reportbug_version "2.10"
mode advanced
ui text
realname "Vincent Lefevre"
email "vinc...@vinc17.net"
mua mutt
cc
timeout 20

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=POSIX, LC_CTYPE=C.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 reportbug depends on:
ii  apt2.6.1
ii  python33.11.2-1+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.82
ii  debsums 3.0.2.1
ii  dlocate 1.12
ii  emacs-bin-common1:28.2+1-15
ii  file1:5.44-3
ii  gnupg   2.2.40-1.1
ii  postfix [mail-transport-agent]  3.7.6-0+deb12u2
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.1
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information

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

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58

Cheers,
Balint

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 11:22):
>
> On 15/11/2023 13:47, Bálint Réczey wrote:
> > Hi Colin,
> >
> > There are a few upstream source files licensed under GPL.
> > Please update debian/copyright to cover all the used licenses.
>
> Updated and uploaded -3 to mentors
>
> Thanks for the prompt review feedback. Much appreciated.
>
> Colin
>
> >
> > You can run 'cme update dpkg-copyright' in the source directory or any
> > other tool from https://wiki.debian.org/CopyrightReviewTools
> >  to help with the manual
> > labor.
> >
> > Cheers,
> > Balint
> >
> > On 2023. Nov 15., Wed at 10:27, Bálint Réczey  > > wrote:
> >
> > Hi Colin,
> >
> > Colin King (gmail)  > > ezt írta (időpont: 2023.
> > nov. 14., K, 17:58):
> >  >
> >  > Hi Balint,
> >  >
> >  > I've uploaded 0.4.0-2 with the suggested fixes.
> >  >
> >  > reply inlined below:
> >  >
> >  > On 09/11/2023 16:23, Bálint Réczey wrote:
> >  > > Hi Colin,
> >  > >
> >  > > Colin King (gmail)  > > ezt írta (időpont: 2023.
> >  > > nov. 7., K, 15:18):
> >  > >>
> >  > >> Hi Balint,
> >  > >>
> >  > >> Thanks for responding with the review. I was waiting for the
> > upstream
> >  > >> project to release a 0.4 with some minor fixes before
> > re-uploading to
> >  > >> mentors.
> >  > >>
> >  > >> I've addressed the issues you found as below:
> >  > >
> >  > > Please see my observations below.
> >  > >
> >  > >> On 22/10/2023 22:38, Bálint Réczey wrote:
> >  > >>> Hi Colin,
> >  > >>>
> >  > >>> I've checked the second upload at [1].
> >  > >>> As you can see in the Lintian warnings there is a .git
> > directory which
> >  > >>> is not ideal for a source package.
> >  > >>> I suggest using the most widely used git-buildpackage based
> > workflow
> >  > >>> where the gbp command takes care of exporting the source package
> >  > >>> without the .git dir from the packaging repository.
> >  > >>> I'd be happy to set up a packaging repo for you at
> >  > >>> https://salsa.debian.org/debian/libtypec
> >  and add you as a maintainer
> >  > >>> as described in [2]
> >  > >
> >  > > I still hold up my offer about setting up a git repo for
> > packaging on
> >  > > Salsa. That comes with the benefit of automated fixes from Debian
> >  > > Janitor and I could also comment on changes right where they
> > happened.
> >  >
> >  > Thank you for your kind offer; I definitely think this is a good
> > idea,
> >  > please can you set this up for me. Much appreciated!
> >
> > I've created the repo at https://salsa.debian.org/debian/libtypec
> >  and
> > added you as a maintainer.
> > I've also set up CI, thus when you push your branches the pipelines
> > will start.
> >
> > You may already be familiar with
> > https://dep-team.pages.debian.net/deps/dep14/
> >  , but if not, please
> > check it before pushing your packaging repository.
> >
> > ...
> >
> >  > > I think my comment here was misleading, sorry for that.
> >  > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
> > dir as a
> >  > > result of specifying .../libtypec.pc as the target dir in the
> > .install
> >  > > file was not desired. It was even patched to have the right
> > content.
> >  > > Please ship the .pc file in the -dev package.
> >  >
> >  > Fixed.
> >
> > The .pc file is now at the right location, but contains multiarch
> > strings which will differ across architectures.
> > I suggest hardcoding the paths in the patch.
> >
> > ...
> >
> >  > > * As you switched back to use upstream's 0.4.0 SO version the
> > .symbols
> >  > > file became wrong  not matching the shipped SO version. Please fix
> >  > > that and also switch to the libtypec0 package name since it
> > needs to
> >  > > match upstream's major SO version
> >  >
> >  > Fixed.
> >
> > The .symbols file's first line should be:
> >   libtypec.so.0 libtypec0 #MINVER#
> >
> > See deb-symbols(5) for more details.
> >
> >  > .
> >  > >
> >  > > * I'd recommend asking upstream to switch to semantic SO versioning
> >  > > instead of using the project's version and switching to major
> > version
> >  > > 1 when the API stabilized.
> >  >
> >  > Good idea. Will do when API changes and stabilizes.
> >
> > 

Bug#1055567: Error: gscan2pdf fails to compile

[Soumyanath Chatterjee]

Please find the responses in red.


On 16/11/23 02:22, jeff wrote:

On 15/11/2023 12:19, Soumyanath Chatterjee wrote:

I find line 8 is commented out


I take it, therefore, that you didn't comment out the line yourself 
sometime in the past?


How did you install gscan2pdf?



I am not very sure. I think I installed it from ubuntu repository or 
might have taken it from sourceforge






ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1
lrwxrwxrwx 1 root root 17 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1-> libsane.so.1.0.29


What about

ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1.0.29 



-rw-r--r-- 1 root root 92232 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1.0.29

Bug#1056048: Memory leak in dcm2json

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.8~git20231027.1549d8c-2

Looks like there is a memory leak using the new citrus/oficonv lib:

curl -O https://dclunie.com/images/charset/charsettests.20070405.tar.bz2
tar xf charsettests.20070405.tar.bz2
valgrind  --leak-check=full --show-leak-kinds=all dcm2json
charsettests/SCSARAB  output.json

I cannot reproduce the symptoms using default glibc/iconv (dcmtk 3.6.7-9).

Reports:

==1688197== Memcheck, a memory error detector
==1688197== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1688197== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1688197== Command: dcm2json charsettests/SCSARAB output.json
==1688197==
==1688197==
==1688197== HEAP SUMMARY:
==1688197== in use at exit: 1,562 bytes in 18 blocks
==1688197==   total heap usage: 80,067 allocs, 80,049 frees, 2,124,652
bytes allocated
==1688197==
==1688197== 8 bytes in 1 blocks are still reachable in loss record 1 of 18
==1688197==at 0x48455EF: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4F594EA: _citrus_UTF8_stdenc_init
(citrus_stdenc_template.h:84)
==1688197==by 0x4F4E301: _citrus_stdenc_open (citrus_stdenc.c:118)
==1688197==by 0x4F55A69: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:374)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1688197==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1688197==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1688197==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1688197==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1688197==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1688197==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1688197==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465)
==1688197==
==1688197== 15 bytes in 1 blocks are still reachable in loss record 2 of 18
==1688197==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4E037F9: strdup (strdup.c:42)
==1688197==by 0x4F56F9F: _citrus_mapper_open (citrus_mapper.c:370)
==1688197==by 0x4F5C6F1: _citrus_csmapper_open.constprop.0
(citrus_csmapper.c:411)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283)
==1688197==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:382)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1688197==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1688197==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1688197==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1688197==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1688197==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1688197==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1688197==
==1688197== 24 bytes in 1 blocks are still reachable in loss record 3 of 18
==1688197==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4F4E2EA: _citrus_stdenc_open (citrus_stdenc.c:112)
==1688197==by 0x4F55A69: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:374)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197== 

Bug#1056049: consolekit2: Not buildable on hurd-i386

[Svante Signell]

Source: consolekit2
Version: 1.2.6-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

consolekit is not buildable on hurd-i386 due to a dependency on libevdev-dev
which is only available for GNU/Linux.

A patch enabling a successful build on GNU/Hurd is attached:
debian_control.patch

Thanks!







--- a/debian/control	2023-11-07 18:27:10.0 +0100
+++ b/debian/control	2023-11-15 12:39:55.0 +0100
@@ -14,7 +14,7 @@
libselinux1-dev [linux-any],
libudev-dev [linux-any],
libacl1-dev [linux-any],
-   libevdev-dev,
+   libevdev-dev [linux-any],
libpam0g-dev,
xsltproc,
xmlto,

Bug#1056038: python-thinc ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:python-thinc
Version: 8.1.7-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-thinc ftbfs with Python 3.12 (and cython 3.0.5):

[...]
Error compiling Cython file:

...
dims = table.shape[1]

cdef np.ndarray output
if reals2d_ft is float2d_t:
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:448:32: Cannot assign type 'saxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, float, const float *, int, float *, int) except * nogil'.


Error compiling Cython file:

...
dims = table.shape[1]

cdef np.ndarray output
if reals2d_ft is float2d_t:
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:448:32: Cannot assign type 'saxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, float, const float *, int, float *, int) except * nogil'.


Error compiling Cython file:

...
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

table.shape[0], dims, rows, indices.shape[1])
else:
output = self.xp.zeros((rows, dims), dtype="float64")
cpu_gather_add(daxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:452:32: Cannot assign type 'daxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, double, const double *, int, double *, int) except * 
nogil'.


Error compiling Cython file:

...
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

table.shape[0], dims, rows, indices.shape[1])
else:
output = self.xp.zeros((rows, dims), dtype="float64")
cpu_gather_add(daxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:452:32: Cannot assign type 'daxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, double, const double *, int, double *, int) except * 
nogil'.




complete build log at
https://launchpadlibrarian.net/697893737/buildlog_ubuntu-noble-amd64.python-thinc_8.1.7-1build1_BUILDING.txt.gz

Bug#1041519: transmission: contains prebuilt javascript without source

[Alexandre Rossi]

> The source package contains:
> 
> web/public_html/index.html
> web/public_html/transmission-app.js
> 
> These files are copied into the binary package as:
> 
> /usr/share/transmission/public_html/index.html
> /usr/share/transmission/public_html/transmission-app.js
> 
> Those files should be built from source with no network connection.

Hi,

I gave it a try and published my current status. Advice will
be appreciated.

https://salsa.debian.org/debian/transmission/-/merge_requests/16

Thanks,

Alex

Bug#1054508: Connman: breaks connections, uses 1 CPU core, and trashes disk space

[Vignesh Raman]

Hi,

On 16/11/23 11:26, программист некто wrote:

Hello. I will try to test it, but it may be difficult. Because, I got the issue 
with Wi-Fi that located in another city.
I never got this issue with home Wi-Fi.


Thank you. I will reduce the severity of this bug from critical to 
important since it is only observed with a particular Wi-Fi network.


Regards,
Vignesh

Bug#1056046: pyregion ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:pyregion
Version: 2.2.0-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

pyregion ftbfs with Python 3.12 (and cython 3.0.5):

[...]
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:381: 
FutureWarning: Cython directive 'language_level' not set, using '3str' 
for now (Py3). This has changed from earlier releases! File: 
/<>/pyregion/_region_filter.pyx

  tree = Parsing.p_module(s, pxd, full_module_name)

Error compiling Cython file:

...

cdef extern from "stdlib.h":
pass


cimport  c_numpy
 ^


pyregion/_region_filter.pyx:9:9: 'c_numpy.pxd' not found

Error compiling Cython file:

...
cdef extern from "stdlib.h":
pass


cimport  c_numpy
from c_numpy cimport npy_bool
^


pyregion/_region_filter.pyx:10:0: 'c_numpy/npy_bool.pxd' not found

Error compiling Cython file:

...
pass


cimport  c_numpy
from c_numpy cimport npy_bool
cimport c_python
^


pyregion/_region_filter.pyx:11:8: 'c_python.pxd' not found

Error compiling Cython file:

...
return RegionAnd(self, o)

def __or__(self, RegionBase o):
return RegionOr(self, o)

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:103:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...
ny = c_python.PySequence_GetItem(shape, 0)
nx = c_python.PySequence_GetItem(shape, 1)

return self._mask(nx, ny)

cdef c_numpy.ndarray _mask(self, c_numpy.npy_intp nx, 
c_numpy.npy_intp ny):

 ^


pyregion/_region_filter.pyx:134:9: 'ndarray' is not a type identifier

Error compiling Cython file:

...
ny = c_python.PySequence_GetItem(shape, 0)
nx = c_python.PySequence_GetItem(shape, 1)

return self._mask(nx, ny)

cdef c_numpy.ndarray _mask(self, c_numpy.npy_intp nx, 
c_numpy.npy_intp ny):

 ^


pyregion/_region_filter.pyx:134:37: 'npy_intp' is not a type identifier

Error compiling Cython file:

...
ny = c_python.PySequence_GetItem(shape, 0)
nx = c_python.PySequence_GetItem(shape, 1)

return self._mask(nx, ny)

cdef c_numpy.ndarray _mask(self, c_numpy.npy_intp nx, 
c_numpy.npy_intp ny):

  ^


pyregion/_region_filter.pyx:134:58: 'npy_intp' is not a type identifier

Error compiling Cython file:

...
cdef RegionBase child_region

def __init__(self, RegionBase child_region):
self.child_region = child_region

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:246:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...

cdef class RegionOrList(RegionList):
"""
>>> r = RegionOrList(r1, r2, r3, r4, ...)
"""
cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:286:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...
cdef class RegionAndList(RegionList):
"""
>>> r = RegionAndList(r1, r2, r3, r4, ...)
"""

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:305:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...

cdef int _transform(self, double x, double y, double *xp, double *yp):
xp[0] = x
yp[0] = y

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:365:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...
def __init__(self, double xc, double yc, double radius,

Bug#1055516: Ongoing work

[Thomas Goirand]

Hi,

FYI, to package latest version, I need python-jsonschema-specifications 
that I started packaging, but now this one needs the latest version of 
python3-referencing. As per here:


https://github.com/python-jsonschema/referencing/commit/fdc8ab0116c82622a1ed0cd642e51237788ad1eb

version 0.31.0 of referencing add 
"referencing.jsonschema.EMPTY_REGISTRY" that jsonschema-specifications 
uses (at least during tests, maybe more...).


Roland, can you upgrade referencing to 0.31.0 then?

Cheers,

Thomas Goirand (zigo)

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

On 16.11.23 10:44, Ole Streicher wrote:

Hi Matthias,

There is a new version of yt, which should resolve this. However, it 
can't be uploaded due to the missing cython-3 in Debian. If you have 
packaged cython-3.0.5, maybe you can make it available?


yes, we will make it available in experimental soon, and also document 
an upgrade path.

Bug#1053955: rust-toml: please update to v0.7.8

[Peter Green]

Please update to (at least) newer upstream release v0.7.8.


toml itself is not semver-breaking, but it's closely coupled dependency
toml_edit is.

Relavent parts of the upstream changelog.


0.21.0 - 2023-11-06
Breaking Change

Split default-features=false APIs into parse and display features



0.20.0 - 2023-09-13
Compatibility

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


0.20->0.21 looks low risk to me, but 0.19->0.20 looks potentially riskier.

With that in mind lets look at the reverse dependencies.

btm - still on 0.19 upstream.
python-maturin - uses 0.21 upstream, did not make any code changes when bumping 
from 0.19 to 0.21, already broken and not in testing.
rust-cargo - uses 0.20 upstream, did not make any code changes when bumping 
from 0.19 to 0.20
rust-rstest-test - uses 0.19 upstream, not in testing, no rdeps
rust-trycmd - uses 0.20 upstream

My overall conclusion is that btm is the main blocker. Jonas, btm is one
of your packages, can you work with upstream to prepare and test an update?

Updated versions of toml_edit and toml are availble in experimental for
you to test with.

Bug#1056032: Dependency missing - "ModuleNotFoundError: No module named 'PyQt5.QtMultimedia'"

[Philipp Marek]

To: Debian Bug Tracking System <>
Package: qtqr
Version: 2.1~bzr47-1
Severity: important
X-Debbugs-Cc: phil...@marek.priv.at


qtqr seems to be missing a dependency:

$ qtqr
Traceback (most recent call last):
  File "/usr/bin/qtqr", line 17, in 
from PyQt5.QtMultimedia import QCameraInfo
ModuleNotFoundError: No module named 'PyQt5.QtMultimedia'
$

After installing python3-pyqt5.qtmultimedia it works as expected.

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

Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qtqr depends on:
ii  python3  3.11.4-5+b1
ii  python3-pyqt55.15.10+dfsg-1
ii  python3-qrtools  2.1~bzr47-1

qtqr recommends no packages.

qtqr suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: can't check qtqr file /usr/share/doc/qtqr/changelog.Debian.gz 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/bookmark.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/email-address.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/email-message.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/geo.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/mms.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/phonebook.png (Wide character in subroutine 
entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/sms.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/telephone.png (Wide character in subroutine 
entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/text-non-ascii.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/text-plain.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/url.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/man/man1/qtqr.1.gz (Wide 
character in subroutine entry)
debsums: can't check qtqr file /usr/share/pixmaps/qtqr.png (Wide 
character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_de_DE.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_en_GB.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_es.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_es_AR.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_fr.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_is_IS.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_it_IT.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_ja.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_ru.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_zh_CN.qm 
(Wide character in subroutine entry)

Bug#1036165: ITP: atuin -- Rich shell history using a SQLite database with optional encrypted sync

[Arturo Borrero Gonzalez]

On Tue, 16 May 2023 18:01:52 +0800 Blair Noctis  wrote:

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng

* Package name: atuin
  Version : 14.0.1
  Upstream Contact: Ellie Huxtable 
* URL : https://atuin.sh/
* License : MIT
  Programming Lang: Rust
  Description : Rich shell history replacement using SQLite with optional
encrypted sync server



Hi there,

thanks for working on this.

Do you have a repository where you are developing this?

regards.

Bug#1056036: python-aiohttp ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-aiohttp
Version: 3.8.6-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-aiohttp ftbfs with Python 3.12:

[...]
building 'aiohttp._websocket' extension
creating build
creating build/temp.linux-x86_64-cpython-312
creating build/temp.linux-x86_64-cpython-312/aiohttp
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 
-Wall -g -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/python-aiohttp-3.8.6-1build1 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.12 -c 
aiohttp/_websocket.c -o 
build/temp.linux-x86_64-cpython-312/aiohttp/_websocket.o
aiohttp/_websocket.c: In function 
‘__pyx_pf_7aiohttp_10_websocket__websocket_mask_cython’:
aiohttp/_websocket.c:1475:3: warning: ‘Py_OptimizeFlag’ is deprecated 
[-Wdeprecated-declarations]

 1475 |   if (unlikely(!Py_OptimizeFlag)) {
  |   ^~
In file included from /usr/include/python3.12/Python.h:48,
 from aiohttp/_websocket.c:6:
/usr/include/python3.12/cpython/pydebug.h:13:37: note: declared here
   13 | Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_OptimizeFlag;
  | ^~~
aiohttp/_websocket.c: In function ‘__Pyx_get_tp_dict_version’:
aiohttp/_websocket.c:2680:5: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]

 2680 | return likely(dict) ? __PYX_GET_DICT_VERSION(dict) : 0;
  | ^~
In file included from /usr/include/python3.12/dictobject.h:90,
 from /usr/include/python3.12/Python.h:61:
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_get_object_dict_version’:
aiohttp/_websocket.c:2692:5: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]
 2692 | return (dictptr && *dictptr) ? 
__PYX_GET_DICT_VERSION(*dictptr) : 0;

  | ^~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_object_dict_version_matches’:
aiohttp/_websocket.c:2696:5: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]
 2696 | if (unlikely(!dict) || unlikely(tp_dict_version != 
__PYX_GET_DICT_VERSION(dict)))

  | ^~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_CLineForTraceback’:
aiohttp/_websocket.c:2741:9: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]

 2741 | __PYX_PY_DICT_LOOKUP_IF_MODIFIED(
  | ^~~~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c:2741:9: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]

 2741 | __PYX_PY_DICT_LOOKUP_IF_MODIFIED(
  | ^~~~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_PyInt_As_long’:
aiohttp/_websocket.c:3042:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3042 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c:3097:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3097 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c: In function ‘__Pyx_PyInt_As_int’:
aiohttp/_websocket.c:3238:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3238 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c:3293:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3293 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c: In function ‘__Pyx_PyIndex_AsSsize_t’:
aiohttp/_websocket.c:3744:45: error: ‘PyLongObject’ {aka ‘struct 

Bug#1056037: python-sqt ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-sqt
Version: 0.8.0-6
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-sqt ftbfs with Python 3.12:

[...]
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
pybuild --clean -i python{version} -p "3.12 3.11"
I: pybuild base:310: python3.12 setup.py clean
/<>/versioneer.py:485: SyntaxWarning: invalid escape 
sequence '\s'

  LONG_VERSION_PY['git'] = '''
Traceback (most recent call last):
  File "/<>/setup.py", line 95, in 
version = versioneer.get_version(),
  
  File "/<>/versioneer.py", line 1473, in get_version
return get_versions()["version"]
   ^^
  File "/<>/versioneer.py", line 1406, in get_versions
cfg = get_config_from_root(root)
  ^^
  File "/<>/versioneer.py", line 412, in get_config_from_root
parser = configparser.SafeConfigParser()
 ^
AttributeError: module 'configparser' has no attribute 
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
E: pybuild pybuild:395: clean: plugin distutils failed with: exit 
code=1: python3.12 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11" 
returned exit code 13

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[Ray Kinsella]

On Wed, 15 Nov 2023 at 22:30, James Addison  wrote:

> On Wed, 15 Nov 2023 at 21:57, Ray Kinsella 
> wrote:
> >
> > Thanks for this - you are kind to look at this issue.
>
> You're welcome - I enjoyed learning a bit about the Quark hardware,
> and the esoteric lock bug.  A shame I didn't learn about it five years
> ago I suppose, but there we are.
>
>
I spent a not insignificant amount of time devising this solution, to get
"Debian Support"
After a few false starts and missteps, eventually I came up with LibX1000
which was a pretty effective fix IMHO.

When I started sharing it around with the Debian & Kernel folks - the
response was pretty clear.
"This is a mess, Intel should just fix the bug ... " - which honestly in
retrospect was the right thing to do.


> > It's been a long time since Intel manufactured the X1000 / Quark, I am
> not sure how many are left in the wild.
> > Do you think this is something that Debian might want to package and
> ship?
>
> I should admit that I'm not a Debian maintainer or developer, just a
> passerby who attempts to make progress on bugs that interest to me
> (possibly to the annoyance of actual DMs/DDs), so my opinion is
> somewhat external (i.e.: take with a grain of salt).


Thrilled that you reached out about it.


> It's entirely
> possible that the maintenance for an additional package wouldn't be
> worthwhile -- and in general, 32-bit x86 support in Debian does tend
> to be dwindling.  Basically: someone has to be motivated about it
> enough to be responsible for the package.
>

[SNIP]


> Do you know whether Intel shipped many Quark units?  I see that
> manufacturing stopped in Y2019, which isn't too long ago, but I don't
> know much about how widely-adopted they were.


There were a few micro[processors,controllers] shipped under Quark.
My memory is that the X1000 didn't last long beyond 2017.
I remember seeing stacks of them (Galileo Boards) sitting gathering dust in
Frys and Maplin.
So I couldn't say how many are in the wild being used.

It was the
> energy-efficiency focus of them that gathered my interest in the first
> place, FWIW.
>
>
Boards like the Up-board (https://up-board.org/) and its successors really
filled this gap more effectively


> > On Wed, 15 Nov 2023 at 12:27, James Addison  wrote:
> >>
> >> Followup-For: Bug #738575
> >> X-Debbugs-Cc: raykinsell...@gmail.com
> >>
> >> If I understand correctly, then Ray's libx1000 library[1] provides a
> way to
> >> work around this in software.  It uses some LD_PRELOAD magic, and from
> what I
> >> remember, it's worth being careful when using that approach.
> >>
> >> I opened an RFP[2] for libx1000 earlier this year, and took another
> look at the
> >> Debian packaging metadata in the codebase today, resulting in a few
> suggested
> >> edits as a pull request on GitHub - cc'ing you to notify you about
> that, Ray.
> >> I'm unsure whether some of the proposed postinst steps are required,
> and will
> >> ask you about those upstream too.
> >>
> >> [1] -
> http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html
> >>
> >> [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037070
>

Bug#1056034: systemd: some services don't start after systemd update

[antonio]

Package: systemd
Version: 255~rc2-1
Severity: normal
X-Debbugs-Cc: antde...@gmail.com

Dear Maintainer,
after updating "systemd" to version "255~rc2-1" some services do not start:

- systemd-resolved.service:

nov 16 08:57:37 SAT (resolved)[1183]: systemd-resolved.service: Failed to set
up special execution directory in /run: Invalid argument

- systemd-timesyncd.service:

nov 16 08:57:37 SAT systemd[1]: Failed to start systemd-timesyncd.service -
Network Time Synchronization.
nov 16 08:57:37 SAT (imesyncd)[1249]: systemd-timesyncd.service: Failed to set
up special execution directory in /run: Invalid argument

- wpa_supplicant.service:

nov 16 08:57:38 SAT (pplicant)[1943]: wpa_supplicant.service: Failed to set up
special execution directory in /run: Invalid argument
nov 16 08:57:38 SAT systemd[1]: Failed to start wpa_supplicant.service
nov 16 08:58:46 SAT NetworkManager[1453]:  [1700121526.2236] device
(wlan0): Couldn't initialize supplicant interface: Failed to D-Bus activate
wpa_supplicant service

- systemd-tmpfiles

nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/snd/seq failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/snd/timer failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/loop-control
failed: Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/net/tun failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/fuse failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/vfio/vfio failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/vhost-net failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/vhost-vsock failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/snd/seq failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/snd/timer failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/loop-control
failed: Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/net/tun failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/fuse failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/vfio/vfio failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/vhost-net failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/vhost-vsock failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/dbus/containers
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/php failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/rpcbind failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/screen failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/systemd/netif
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/run/systemd/netif/links failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/run/systemd/netif/leases failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/systemd/netif/lldp
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/utmp failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/tpm2-tss/eventlog
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/log/journal
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/sys/kernel/security/tpm0/binary_bios_measurements failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/sys/kernel/security/ima/binary_runtime_measurements failed: Invalid argument

---

also note the truncated keywords "(pplicant)", "(imesyncd)"

what has changed?

Thanks,
Antonio


-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libapparmor1   3.0.12-1
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-6
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1

Bug#1056039: ros-geometry2 ftbfs with Python 3.12 (amd64 only)

[Matthias Klose]

Package: src:ros-geometry2
Version: 0.7.7-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

ros-geometry2 ftbfs with Python 3.12 (amd64 only), on other 
architectures the tests pass. Tests also pass with 3.11.


[...]
I: pybuild base:310: dh_auto_test --buildsystem=cmake 
--builddirectory=/<>/.pybuild/cpython3_3.12/build --
I: pybuild pybuild:340: catkin_test_results 
/<>/.pybuild/cpython3_3.12/build
test_results/tf2_geometry_msgs/rostest-test_test.xml: 1 tests, 1 errors, 
0 failures, 0 skipped
test_results/tf2_kdl/rostest-test_test.xml: 1 tests, 1 errors, 0 
failures, 0 skipped
test_results/tf2_ros/rostest-test_message_filter_test.xml: 1 tests, 1 
errors, 0 failures, 0 skipped
test_results/tf2_ros/rostest-test_transform_listener_time_reset_test.xml: 
1 tests, 1 errors, 0 failures, 0 skipped
test_results/tf2_ros/rostest-test_transform_listener_unittest.xml: 1 
tests, 1 errors, 0 failures, 0 skipped

Summary: 95 tests, 5 errors, 0 failures, 0 skipped
E: pybuild pybuild:395: test: plugin cmake failed with: exit code=1: 
catkin_test_results /<>/.pybuild/cpython3_3.12/build

Bug#1056042: xrayutilities ftbfs with Python 3.12

[Matthias Klose]

Package: src:xrayutilities
Version: 1.7.4-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

some tests fail with:

[...]
/usr/lib/python3.12/subprocess.py:571: CalledProcessError
- Captured stderr call 
-

Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_xrayutilities/build/examples/simpack_xrr_SiO2_Ru_CoFe_IrMn_Al2O3.py", 
line 20, in 

import lmfit
  File "/usr/lib/python3/dist-packages/lmfit/__init__.py", line 38, in 


from .confidence import conf_interval, conf_interval2d
  File "/usr/lib/python3/dist-packages/lmfit/confidence.py", line 10, 
in 

from .minimizer import MinimizerException
  File "/usr/lib/python3/dist-packages/lmfit/minimizer.py", line 41, in 


from .parameter import Parameter, Parameters
  File "/usr/lib/python3/dist-packages/lmfit/parameter.py", line 10, in 


from uncertainties import correlated_values, ufloat
  File "/usr/lib/python3/dist-packages/uncertainties/__init__.py", line 
225, in 

from .core import *
  File "/usr/lib/python3/dist-packages/uncertainties/core.py", line 22, 
in 

from past.builtins import basestring
  File "/usr/lib/python3/dist-packages/past/builtins/__init__.py", line 
54, in 

from past.builtins.misc import (apply, chr, cmp, execfile, intern, oct,
  File "/usr/lib/python3/dist-packages/past/builtins/misc.py", line 45, 
in 

from imp import reload
ModuleNotFoundError: No module named 'imp'

complete build log at
https://launchpadlibrarian.net/697894338/buildlog_ubuntu-noble-amd64.xrayutilities_1.7.4-1build2_BUILDING.txt.gz

Bug#1056045: healpy ftbfs with Python 3.12

[Matthias Klose]

Package: src:healpy
Version: 1.16.1-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

healpy ftbfs with Python 3.12, although it also fails the same way with 
3.11.  Probably you need to wait until we have built all the depending 
modules when adding 3.12.



[...]
= test session starts 
==
platform linux -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0 -- 
/usr/bin/python3.11

cachedir: .pytest_cache
hypothesis profile 'default' -> 
database=DirectoryBasedExampleDatabase(PosixPath('/<>/.pybuild/cpython3_3.11_healpy/build/.hypothesis/examples'))

rootdir: /<>
configfile: setup.cfg
plugins: cov-4.1.0, doctestplus-1.0.0, arraydiff-0.5.0, 
hypothesis-6.88.1, cython-0.1.1, mock-3.11.1, astropy-header-0.2.2, 
filter-subpackage-0.1.2, remotedata-0.4.1, astropy-0.11.0

collecting ... collected 0 items / 1 error

 ERRORS 

 ERROR collecting test session 
_
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:641: in 
_importconftest

mod = import_path(conftestpath, mode=importmode, root=rootpath)
/usr/lib/python3/dist-packages/_pytest/pathlib.py:567: in import_path
importlib.import_module(module_name)
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1204: in _gcd_import
???
:1176: in _find_and_load
???
:1126: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1204: in _gcd_import
???
:1176: in _find_and_load
???
:1126: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1204: in _gcd_import
???
:1176: in _find_and_load
???
:1147: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
:940: in exec_module
???
:241: in _call_with_frames_removed
???
healpy/__init__.py:90: in 
from ._query_disc import query_disc, query_strip, query_polygon, 
boundaries

healpy/src/_query_disc.pyx:10: in init healpy._query_disc
???
E   ModuleNotFoundError: No module named '_pixelfunc'
=== short test summary info 


ERROR ../../.. - ModuleNotFoundError: No module named '_pixelfunc'
 Interrupted: 1 error during collection 

=== 1 error in 0.28s 
===
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=2: 
cd /<>/.pybuild/cpython3_3.11_healpy/build; python3.11 -m 
pytest --doctest-modules

Bug#1056047: python-skbio ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:python-skbio
Version: 0.5.8-4
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-skbio ftbfs with Python 3.12 (and cython 3.0.5):

[...]
dh_auto_configure
I: pybuild base:310: python3.12 setup.py config
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:381: 
FutureWarning: Cython directive 'language_level' not set, using '3str' 
for now (Py3). This has changed from earlier releases! File: 
/<>/skbio/alignment/_ssw_wrapper.pyx

  tree = Parsing.p_module(s, pxd, full_module_name)

Error compiling Cython file:

...
else:
matrix = self._convert_dict2d_to_matrix(substitution_matrix)
# Set up our mask_length
# Mask is recommended to be max(query_sequence/2, 15)
if mask_auto:
self.mask_length = len(query_sequence) / 2
   ^


skbio/alignment/_ssw_wrapper.pyx:584:51: Cannot assign type 'double' to 
'int32_t'

[1/6] Cythonizing skbio/alignment/_ssw_wrapper.pyx
Traceback (most recent call last):
  File "/<>/setup.py", line 129, in 
extensions = cythonize(extensions, force=True)
 ^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1154, in cythonize

cythonize_one(*args)
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: skbio/alignment/_ssw_wrapper.pyx
E: pybuild pybuild:395: configure: plugin distutils failed with: exit 
code=1: python3.12 setup.py config

Bug#1056034: systemd: some services don't start after systemd update)

[Antonio]

You are not using a Debian kernel, so we cannot offer you support.
Someone with the same broken kernel reported a similar issue upstream,
and was redirected to the kernel supplier:

https://github.com/damentz/liquorix-package/issues/147


I checked and in fact there are no problems with the latest version of 
the Debian kernel.


Thanks for the information,
I have reported it to the Liquorix maintainers.

https://techpatterns.com/forums/about3055.html 



Antonio

Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.7-1
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

As discussed in private, here is a patch which fixes the arch detection for
sparc64 in cabal. Previously, cabal treated "sparc64" as an alias for 32-bit
sparc which results in the GHC build process not being able to find the built
binaries as these are stored in a $ARCH-$OS subfolder.

The patch has already been pushed upstream, approved and should be merged within
the next hours after some more waiting [1].

The attached patch is a backported version of the patch which applies to GHC 
9.4.7.

Thanks,
Adrian

> [1] https://github.com/haskell/cabal/pull/9445

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- ghc-9.4.6.orig/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs
+++ ghc-9.4.6/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs
@@ -158,19 +158,17 @@ buildOS = classifyOS Permissive System.I
 -- 
 
 -- | These are the known Arches: I386, X86_64, PPC, PPC64, Sparc,
--- Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa, Rs6000,
--- M68k, Vax, JavaScript and Wasm32.
---
+-- Sparc64, Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa,
+-- Rs6000, M68k, Vax, JavaScript and Wasm32.
 -- The following aliases can also be used:
 --* PPC alias: powerpc
 --* PPC64 alias : powerpc64, powerpc64le
---* Sparc aliases: sparc64, sun4
 --* Mips aliases: mipsel, mipseb
 --* Arm aliases: armeb, armel
 --* AArch64 aliases: arm64
 --
 data Arch = I386  | X86_64  | PPC  | PPC64 | Sparc
-  | Arm   | AArch64 | Mips | SH
+  | Sparc64 | Arm   | AArch64 | Mips | SH
   | IA64  | S390| S390X
   | Alpha | Hppa| Rs6000
   | M68k  | Vax
@@ -185,7 +183,7 @@ instance NFData Arch where rnf = generic
 
 knownArches :: [Arch]
 knownArches = [I386, X86_64, PPC, PPC64, Sparc
-  ,Arm, AArch64, Mips, SH
+  ,Sparc64 ,Arm, AArch64, Mips, SH
   ,IA64, S390, S390X
   ,Alpha, Hppa, Rs6000
   ,M68k, Vax
@@ -197,7 +195,6 @@ archAliases Strict _   = []
 archAliases Compat _   = []
 archAliases _  PPC = ["powerpc"]
 archAliases _  PPC64   = ["powerpc64", "powerpc64le"]
-archAliases _  Sparc   = ["sparc64", "sun4"]
 archAliases _  Mips= ["mipsel", "mipseb"]
 archAliases _  Arm = ["armeb", "armel"]
 archAliases _  AArch64 = ["arm64"]
--- ghc-9.4.6.orig/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs
+++ ghc-9.4.6/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs
@@ -717,6 +717,7 @@ platformDefines lbi =
   PPC -> ["powerpc"]
   PPC64   -> ["powerpc64"]
   Sparc   -> ["sparc"]
+  Sparc64 -> ["sparc64"]
   Arm -> ["arm"]
   AArch64 -> ["aarch64"]
   Mips-> ["mips"]

Bug#1056035: mirror submission for mirror.matnetwrk.net

[Mathieu Mafille]

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

Submission-Type: new
Site: mirror.matnetwrk.net
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mathieu Mafille 
Country: CH Switzerland
Location: Saint-Imier / Switzerland
Sponsor: MATNETWRK https://matnetwrk.net




Trace Url: http://mirror.matnetwrk.net/debian/project/trace/
Trace Url: 
http://mirror.matnetwrk.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.matnetwrk.net/debian/project/trace/mirror.matnetwrk.net

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Emanuele Rocca]

Hi Rafael,

On 2023-11-16 08:42, Rafael Laboissière wrote:
> Control: forwarded -1 https://sourceforge.net/p/plplot/bugs/206/
> 
> * Rafael Laboissière  [2023-11-16 07:51]:
> 
> > My guess is that the bug is in PLplot and not in gfortran, but this is
> > just a guess. I will eventually inform the PLplot upstream authors about
> > the issue.
> 
> Done !

Thank you!

To be honest I think it's safe to close 1055750 (gfortran) and mark
1055228 (plplot) as forwarded upstream though, I don't think we have any
reasons to believe the compiler is at fault really.

  Emanuele

Bug#1056040: ros-image-common ftbfs with Python 3.12

[Matthias Klose]

Package: src:ros-image-common
Version: 1.12.0-12
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

ros-image-common ftbfs with Python 3.12:

[...]
[Testcase: testunit_test] ... ERROR!
ERROR: 'RosTest' object has no attribute 'assert_'
  File "/usr/lib/python3.12/unittest/case.py", line 58, in testPartExecutor
yield
  File "/usr/lib/python3.12/unittest/case.py", line 636, in run
self._callTestMethod(testMethod)
  File "/usr/lib/python3.12/unittest/case.py", line 589, in _callTestMethod
if method() is not None:
   
  File "/usr/lib/python3/dist-packages/rostest/runner.py", line 113, in fn
self.assert_(self.test_parent is not None, "ROSTestParent 
initialization failed")




[ROSTEST]---


SUMMARY
 * RESULT: FAIL
 * TESTS: 0
 * ERRORS: 1
 * FAILURES: 0

Bug#1056041: tombo ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:tombo
Version: 1.5.1-4
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

tombo ftbfs with Python 3.12 (and cython 3.0.5):

[...]
[1/1] Cythonizing tombo/_c_dynamic_programming.pyx
Traceback (most recent call last):
  File "/<>/setup.py", line 55, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
107, in setup

return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 185, in setup

return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 201, in run_commands

dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 969, in run_commands

self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", 
line 131, in run

self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 318, in run_command

self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File 
"/usr/lib/python3/dist-packages/setuptools/command/build_ext.py", line 
88, in run

_build_ext.run(self)
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 345, in run

self.build_extensions()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 467, in build_extensions

self._build_extensions_serial()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 493, in _build_extensions_serial

self.build_extension(ext)
  File 
"/usr/lib/python3/dist-packages/setuptools/command/build_ext.py", line 
249, in build_extension

_build_ext.build_extension(self, ext)
  File "/usr/lib/python3/dist-packages/Cython/Distutils/build_ext.py", 
line 130, in build_extension

new_ext = cythonize(
  ^^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1154, in cythonize

cythonize_one(*args)
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: tombo/_c_dynamic_programming.pyx
E: pybuild pybuild:395: build: plugin distutils failed with: exit 
code=1: /usr/bin/python3.12 setup.py build

I: pybuild base:310: /usr/bin/python3 setup.py build

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:yt
Version: 4.2.2-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

yt ftbfs with Python 3.12 (and cython 3.0.5):

[...]
Error compiling Cython file:

...
# Compute number of fields to skip. This should be 31 in 3 dimensions
skip_len = (1  # father index
+ 2*ndim   # neighbor index
+ 2**ndim  # son index
+ 2**ndim  # cpu map
+ 2**ndim  # refinement map
^


yt/frontends/ramses/io_utils.pyx:48:16: Cannot assign type 'double' to 
'INT64_t'


Error compiling Cython file:

...
nlevelmax = headers['nlevelmax']
n_levels = nlevelmax - min_level
ncpu = headers['ncpu']

ncpu_and_bound = nboundary + ncpu
twotondim = 2**ndim
 ^


yt/frontends/ramses/io_utils.pyx:103:17: Cannot assign type 'double' to 
'INT64_t'


Error compiling Cython file:

...
cdef str field
cdef INT64_t twotondim
cdef int ilevel, icpu, ifield, nfields, nlevels, nc, ncpu_selected
cdef np.ndarray[np.uint8_t, ndim=1] mask

twotondim = 2**ndim
 ^


yt/frontends/ramses/io_utils.pyx:157:17: Cannot assign type 'double' to 
'INT64_t'

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1345, in cythonize_one_helper

return cythonize_one(*m)
   ^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: yt/frontends/ramses/io_utils.pyx

Error compiling Cython file:

...
@cython.cdivision(True)
@cython.boundscheck(False)
@cython.wraparound(False)
cdef np.int64_t bitrange(np.int64_t x, np.int64_t width,
 np.int64_t start, np.int64_t end):
return x >> (width-end) & ((2**(end-start))-1)
^


yt/utilities/lib/geometry_utils.pyx:92:28: Invalid operand types for '&' 
(int64_t; double)


Error compiling Cython file:

...
@cython.boundscheck(False)
@cython.wraparound(False)
cdef np.int64_t rrot(np.int64_t x, np.int64_t i, np.int64_t width):
i = i%width
x = (x>>i) | (xwidth-i)
return x&(2**width-1)
^


yt/utilities/lib/geometry_utils.pyx:108:12: Invalid operand types for 
'&' (int64_t; double)


Error compiling Cython file:

...
@cython.cdivision(True)
@cython.boundscheck(False)
@cython.wraparound(False)
cdef np.int64_t setbit(np.int64_t x, np.int64_t w, np.int64_t i, 
np.int64_t b):

if b == 1:
return x | 2**(w-i-1)
 ^


yt/utilities/lib/geometry_utils.pyx:129:17: Invalid operand types for 
'|' (int64_t; double)


Error compiling Cython file:

...
@cython.wraparound(False)
cdef np.int64_t setbit(np.int64_t x, np.int64_t w, np.int64_t i, 
np.int64_t b):

if b == 1:
return x | 2**(w-i-1)
elif b == 0:
return x & ~2**(w-i-1)
   ^


yt/utilities/lib/geometry_utils.pyx:131:19: Invalid operand type for '~' 
(double)

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1345, in cythonize_one_helper

return cythonize_one(*m)
   ^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: yt/utilities/lib/geometry_utils.pyx
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/lib/python3.11/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
^^^
  File "/usr/lib/python3.11/multiprocessing/pool.py", line 48, in mapstar
return 

Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry

[Thomas Goirand]

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

* Package name: python-jsonschema-specifications
  Version : 2023.11.1
  Upstream Contact: Julian Berman 
* URL : 
https://github.com/python-jsonschema/jsonschema-specifications
* License : Expat
  Programming Lang: Python
  Description : JSON Schema meta-schemas and vocabularies, exposed as a 
Registry

 This package contains JSON support files from the JSON Schema Specifications
 (metaschemas, vocabularies, etc.), packaged for runtime access from Python as
 a referencing-based Schema Registry.

Note: This package is needed to update python-jsonschema to the latest
upsteram release.

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Ole Streicher]

Hi Matthias,

There is a new version of yt, which should resolve this. However, it 
can't be uploaded due to the missing cython-3 in Debian. If you have 
packaged cython-3.0.5, maybe you can make it available?


Best

Ole

Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640

[Ben Mesman]

Package: src:linux
Version: 6.1.55-1
Severity: important
X-Debbugs-Cc: b...@sparknarrowcasting.nl

If the HP t640 (I tried 2 different systems) runs this kernel, a 
'reboot' will result in the BIOS reporting that the disk is missing. 
After a cold reboot (turning the device off and on again) the disk wil 
be detected and the system will boot as expected. The next reboot will 
again trigger this bug.


Other HP thin-clients from similar series (t620, t630, t655) do not have 
the same problem.


Debian bullseye (kernel 5.10) does not have this problem, but upgrading 
to 6.1.0 (through bulleye-backports) will trigger this bug. Upgrading 
bookworm to a 6.5 kernel (through bookworm-backports) does not solve the 
bug.


Because the installer uses the same kernel, after the installation is 
complete and does the reboot, the bug will be triggered.



-- Package-specific info:
** Version:
Linux version 6.1.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 
root=UUID=3b7b05fe-9cdc-49e7-9416-319125d9858e ro quiet


** Not tainted

** Kernel log:
[    0.00] Linux version 6.1.0-13-amd64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU 
ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 
6.1.55-1 (2023-09-29)
[    0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 
root=UUID=3b7b05fe-9cdc-49e7-9416-319125d9858e ro quiet

[    0.00] BIOS-provided physical RAM map:
[    0.00] BIOS-e820: [mem 0x-0x0009] usable
[    0.00] BIOS-e820: [mem 0x000a-0x000f] 
reserved

[    0.00] BIOS-e820: [mem 0x0010-0x09df] usable
[    0.00] BIOS-e820: [mem 0x09e0-0x09ffdfff] 
reserved

[    0.00] BIOS-e820: [mem 0x09ffe000-0x0a1f] usable
[    0.00] BIOS-e820: [mem 0x0a20-0x0a20afff] 
ACPI NVS

[    0.00] BIOS-e820: [mem 0x0a20b000-0x7a88dfff] usable
[    0.00] BIOS-e820: [mem 0x7a88e000-0x7a980fff] 
reserved
[    0.00] BIOS-e820: [mem 0x7a981000-0x7a9b5fff] 
ACPI data
[    0.00] BIOS-e820: [mem 0x7a9b6000-0x7af20fff] 
ACPI NVS
[    0.00] BIOS-e820: [mem 0x7af21000-0x7c96bfff] 
reserved
[    0.00] BIOS-e820: [mem 0x7c96c000-0x7ca04fff] 
type 20

[    0.00] BIOS-e820: [mem 0x7ca05000-0x7dff] usable
[    0.00] BIOS-e820: [mem 0x7e00-0x7fff] 
reserved
[    0.00] BIOS-e820: [mem 0xf800-0xfbff] 
reserved
[    0.00] BIOS-e820: [mem 0xfd00-0xfdff] 
reserved
[    0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfed8-0xfed8] 
reserved
[    0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] 
reserved
[    0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfee0-0xfeef] 
reserved
[    0.00] BIOS-e820: [mem 0xff00-0x] 
reserved

[    0.00] BIOS-e820: [mem 0x0001-0x00015eff] usable
[    0.00] BIOS-e820: [mem 0x00015f00-0x00017eff] 
reserved

[    0.00] BIOS-e820: [mem 0x00017f00-0x00017f33] usable
[    0.00] BIOS-e820: [mem 0x00017f34-0x00017fff] 
reserved

[    0.00] NX (Execute Disable) protection: active
[    0.00] efi: EFI v2.70 by American Megatrends
[    0.00] efi: TPMFinalLog=0x7aed8000 ACPI 2.0=0x7a998000 
ACPI=0x7a998000 SMBIOS=0x7c82 SMBIOS 3.0=0x7c81f000 
MEMATTR=0x790b6298 ESRT=0x790c0698

[    0.00] secureboot: Secure boot disabled
[    0.00] SMBIOS 3.2.1 present.
[    0.00] DMI: HP HP t640 Thin Client/8523, BIOS M43 v01.04 10/29/2019
[    0.00] tsc: Fast TSC calibration using PIT
[    0.00] tsc: Detected 2395.458 MHz processor
[    0.000628] e820: update [mem 0x-0x0fff] usable ==> reserved
[    0.000631] e820: remove [mem 0x000a-0x000f] usable
[    0.000644] last_pfn = 0x17f340 max_arch_pfn = 0x4
[    0.001139] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP UC- WT
[    0.001351] e820: update [mem 0x8000-0x] usable ==> reserved
[    0.001361] last_pfn = 0x7e000 max_arch_pfn = 0x4
[    0.006355] esrt: Reserving ESRT space from 0x790c0698 to 
0x790c06d0.

[    0.006369] e820: update [mem 

Bug#1056056: Acknowledgement (linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640)

[Ben Mesman | Spark Narrowcasting]

Control: merge 1056055 1056056


Van: Debian Bug Tracking System 
Verzonden: donderdag 16 november 2023 14:21
Aan: Ben Mesman | Spark Narrowcasting 
Onderwerp: Bug#1056056: Acknowledgement (linux-image-6.1.0-13-amd64: After a 
'warm' reboot the disk is missing (not detected by the bios) on a HP t640)

[U ontvangt vaak geen e-mail van ow...@bugs.debian.org. Informatie over waarom 
dit belangrijk is op https://aka.ms/LearnAboutSenderIdentification]

LET OP: Deze e-mail is afkomstig van buiten de organisatie. Klik niet op links 
en open geen bijlagen tenzij je de afzender kent en weet dat de inhoud veilig 
is. Bij twijfel neem, altijd contact op met de Servicedesk.

CAUTION: This email was sent from an external source. Do not click on links or 
open attachments unless you know the sender and the content is safe. When in 
doubt, please contact the Servicedesk.


Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1056056: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056056.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  b...@sparknarrowcasting.nl
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 Debian Kernel Team 

If you wish to submit further information on this problem, please
send it to 1056...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1056056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056056
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1055919: python-ansible-pygments: please make the build reproducible

[Chris Lamb]

Stuart Prescott wrote:

> I think there's a subtle bug about altering `dirs` while
> inside a loop from `os.walk`:

I'm quite impressed that you managed to hunt this down — that's very
nice work. :)

> Which item is not processed in the next iteration by dh_python3 now 
> depends on the order in which `os.walk` lists the directories. That is 
> presumably dependent on all manner of things (filesystem? collation? 
> luck?).

It will be dependent entirely on the filesystem being used because
`os.walk` merely passes on the underlying filesystem ordering. (The
same is true for GNU find as you later query.)

Entirely anecdotally, ext4 will be "more orderful", whilst btrfs,
possibly due to the way it rebalances its tree data structures, tends
to be less so. I raise it only because it can help explain why
different folks will get different results locally despite using the
same building tools. Building under tmpfs will have different
properties as well.

Anyway, thank you again. Once this is addressed in dh-python (even as
a proposed patch), I'll go through the last few months of bugs that
I've filed and see whether they can be closed.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Vincent Lefevre]

Control: retitle -1 reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved 
Permanently

On 2023-11-16 12:34:17 +0100, Vincent Lefevre wrote:
> So this URL gives a 301 Moved Permanently with
> https://ftp-master.debian.org/new.822 as the new URL,
> and reportbug does not attempt to use this new URL.

Sorry, it actually seems to be used (the information is now encrypted
in the strace output, hence the confusion).

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

Bug#1054302: add support for loongarch

[liuxiang]

patch attached

Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 python-greenlet (2.0.2-1.loong64) UNRELEASED; urgency=medium
 .
   * Add support for loongarch.
Author: Xiang Liu 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2023-11-16

--- python-greenlet-2.0.2.orig/setup.py
+++ python-greenlet-2.0.2/setup.py
@@ -58,6 +58,7 @@ if (
 #
 # Adding the -Os flag fixes the problem.
 or (is_linux and plat_machine == "riscv64")
+or (is_linux and plat_machine == "loongarch64")
 ):
 global_compile_args.append("-Os")
 
--- /dev/null
+++ python-greenlet-2.0.2/src/greenlet/platform/switch_loongarch64_linux.h
@@ -0,0 +1,31 @@
+#define STACK_REFPLUS 1
+
+#ifdef SLP_EVAL
+#define STACK_MAGIC 0
+
+#define REGS_TO_SAVE "s0", "s1", "s2", "s3", "s4", "s5", \
+ "s6", "s7", "s8", "fp", \
+		 "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"
+
+static int
+slp_switch(void)
+{
+  register int ret;
+  register long *stackref, stsizediff;
+  __asm__ volatile ("" : : : REGS_TO_SAVE);
+  __asm__ volatile ("move %0, $sp" : "=r" (stackref) : );
+  {
+  SLP_SAVE_STATE(stackref, stsizediff);
+  __asm__ volatile (
+ "add.d $sp, $sp, %0\n\t"
+ : /* no outputs */
+ : "r" (stsizediff)
+ );
+  SLP_RESTORE_STATE();
+  }
+  __asm__ volatile ("" : : : REGS_TO_SAVE);
+  __asm__ volatile ("move %0, $zero" : "=r" (ret) : );
+  return ret;
+}
+
+#endif
--- python-greenlet-2.0.2.orig/src/greenlet/slp_platformselect.h
+++ python-greenlet-2.0.2/src/greenlet/slp_platformselect.h
@@ -38,6 +38,8 @@ extern "C" {
 #include "platform/switch_s390_unix.h"	/* Linux/S390 */
 #elif defined(__GNUC__) && defined(__s390x__) && defined(__linux__)
 #include "platform/switch_s390_unix.h"	/* Linux/S390 zSeries (64-bit) */
+#elif defined(__GNUC__) && defined(__loongarch64) && defined(__linux__)
+#include "platform/switch_loongarch64_linux.h"	/* Linux/LoongArch64 */
 #elif defined(__GNUC__) && defined(__arm__)
 #ifdef __APPLE__
 #include 

Bug#1055989: emacs-gtk: emacs rejects font preference, falls back to "Purisa" font

[David Bremner]

Control: tag -1 confirmed

Christoph Reichenbach  writes:

> * What exactly did you do (or not do) that was effective (or ineffective)?
>
> Executing the following steps:
>
> - (customize-face 'default)
>   - Font Family: setting "Terminus (TTF)"
>   - Font Foundry: setting "PfEd"
>   - Optionally (does not affect outcome):
> - Weight: setting "medium"
> - Disabling any font attributes (inlcuding Weight)
>   - [Apply]
[snip]
> * What was the outcome of this action?
>
> Emacs used the "Purisa" font as default font.  This font has the same Font
> Foundry as "Terminus (TTF)" but is a "Comic Sans"-like special-purpose font
> and unsuitable for normal operations.
>

For me, it is Fantasque Sans Mono, but I agree it is not selecting the correct
font. The selected font seems non-deterministic, possibly state
dependent. After some various choices of Mono font, I ended up with 

Can you duplicate the problem for other fonts?  I tried 4 or 5 other
monospaced fonts and they all seemed to work, at least in a fresh "emacs
-Q".

I observed that choosing some non-existing font name (e.g. FooBar) had
more or less the same effect. So maybe the issue is just that emacs
cannot find "Terminus (TTF)". A wild guess would be the parens in the
name causing the problem.

Apologies if this is covered already in your extensive report.

Bug#1024079: uvloop FTBFS on IPV6-only buildds

[Dale Richards]

As promised, please find attached the updated patch. This patch allows the 
package to build and test successfully on hosts that are IPv4-only, IPv6-only 
or dual-stack.

Best regards,
Dale Richards

ipv6-fix-tests.patch
Description: Binary data

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Sat, Nov 04, 2023 at 10:38:32AM -0300, Antonio Terceiro wrote:
> On Fri, Nov 03, 2023 at 09:07:49PM -0300, Antonio Terceiro wrote:
> > On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> > > Package: python3-textual
> > > Severity: normal
> > > X-Debbugs-Cc: 
> > > 
> > > Dear maintainer,
> > > 
> > > The current version of python3-textual in Debian is quite out of date,
> > > and it's not possible to run newer textual apps with it anymore.,
> > > Please upgrade to the latest upstream version (currenly (0.40.0) so
> > > that this package can be useful again.
> > 
> > I have a textual locally updated to the latest upstream version:
> > https://salsa.debian.org/terceiro/textual
> > 
> > I had to disable a few tests due to either missing dependencies, of
> > mismatching expectations between the versions in Debian and the ones
> > assumed by upstream (poetry.lock). There is still some work to do, e.g.
> > converting the autopkgtest to use autopkgtest-pkg-pybuild.
> 
> This is now done.
> 
> BTW there is a new build dependency, python3-time-machine, which is in
> NEW right now:
> 
> https://salsa.debian.org/python-team/packages/python-time-machine

FWIW this package has passed NEW and is even already in testing.


signature.asc
Description: PGP signature

Bug#819341: [unison] Please build unison-fsmonitor

[Damian Lukowski]

Please consider 
https://salsa.debian.org/ocaml-team/unison/-/merge_requests/2

Bug#1056052: Subject: ITP: wasix-libc -- wasix libc implementation for WebAssembly

[daichi1.fukui]

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

* Package name: wasix-libc
  Version : 0.0~git20230922.d0362cb
  Upstream Author : Johnathan Sharratt 
* URL : https://github.com/wasix-org/wasix-libc
* License : Apache-2.0 and Apache-2.0-with-LLVM-Exceptions and Expat
  Programming Lang: C
  Description : wasix libc implementation for WebAssembly

Reason for ITP:
wasix-libc is the libc implementation for WebAssembly (WASM) with POSIX 
conformance.
WASIX is a superset on top of WASI, so wasix-libc incorporates POSIX-compliant 
extentions
such as support for sockets, which are not available in wasi-libc.
With this package, we will be able to build a C source code with POSIX 
interfaces into a WASM module.

A git repository will be created on salsa:
https://salsa.debian.org/dfukui/wasix-libc

Maintenance plan:
Because I have less experience in debian packaging, I would like to
ask Debian developers to review my upload. I need a sponsor too.
Report will be sent to Debian Bug Tracking System 

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Jonas Smedegaard]

Quoting Paul Gevers (2023-11-16 11:22:45)
> On Thu, 12 Oct 2023 06:36:05 +0200 Jonas Smedegaard  wrote:
> > Quoting Scott Talbert (2023-10-12 02:33:45)
> > > It looks like pandoc can be updated to v3.0.1 and be compatible with the 
> > > dependencies that are in unstable currently (LTS 21).  Can you please let 
> > > us know if there are any dependencies still missing?
> 
> > I will look at it soon - probably this upcoming weekend.
> 
> Is there any progress with fixing this bug? It seems that this issue is 
> one of the last blocking issues in the haskell transition. src:pandoc is 
> a key package, we can't easily remove it from testing to "fix" the blockage.

Thanks for pinging/nudging, Paul.

Upstream project has restructured to now be organized as multiple
projects to be built as dependencies of each other.

I had hoped to be able to orchestrate such chain-of-builds internally in
the single source package, but the Haskell build helper tools seem to be
in too bad shape for that: Apparently all Haskell packages use CDBS
which is quite cumbersome to use for "looping" subtasks, and both of the
two available non-CDBS debhelper tools existing in Debian are broken.

I therefore give up on that approach, and see no other way forward than
to introduce the libraries of Pandoc as a new source package, and then
have the existing src:pandoc package depend on that to build the binary.

I will now file an RFP for that new dependent package, in the hope that
the Haskell team can adopt maintenance of that.


 - 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#1056053: debci-worker: QEMU backend arguments cannot contain quoted arguments

[Christian Kastner]

Package: debci-worker
Version: 3.7
Severity: normal

3.7 added this nice feature where arguments can be passed to backends. However,
the --qemu-options parameter of the QEMU backend cannot be used with the
current implementation because its argument usually contains spaces, and these
get misinterpreted during expansion of "$@".

For example, given the following setting,

debci_autopkgtest_args_qemu"--ram-size 32768 --cpus 4 --qemu-options='--cpu 
host'"

running a test will tmpfail with

autopkgtest-virt-qemu: error: unrecognized arguments: host'

because |--qemu-options='--cpu| and |host'| get interpreted as two words,
rather than one.


A POSIXly solution doesn't immediately jump to my mind, but I'd thought I'd
report it for now, just to track the issue.

I don't think the other backends are affected, they don't have similar
parameters.

Best,
Christian

Bug#1056049: consolekit2: Not buildable on hurd-i386

[Mark Hindley]

Control: tags -1 pending

Svante,

Many thanks for this. Queued for upload.

Best wishes

Mark

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[James Addison]

On Thu, 16 Nov 2023 at 09:57, Ray Kinsella  wrote:
>
> On Wed, 15 Nov 2023 at 22:30, James Addison  wrote:
>>
>> On Wed, 15 Nov 2023 at 21:57, Ray Kinsella  wrote:
> [...]
> I spent a not insignificant amount of time devising this solution, to get 
> "Debian Support"
> After a few false starts and missteps, eventually I came up with LibX1000 
> which was a pretty effective fix IMHO.
>
> When I started sharing it around with the Debian & Kernel folks - the 
> response was pretty clear.
> "This is a mess, Intel should just fix the bug ... " - which honestly in 
> retrospect was the right thing to do.

Yep; frustrating though it can be, pushing back to figure out the
origins of bugs and resolve them there is likely the way to free up
enough developer and maintainer time, and to improve hardware and
software quality enough, to reach Reliable Technology Utopia.. should
be any day now :)

>> > It's been a long time since Intel manufactured the X1000 / Quark, I am not 
>> > sure how many are left in the wild.
>> > Do you think this is something that Debian might want to package and ship?
>>
>> I should admit that I'm not a Debian maintainer or developer, just a
>> passerby who attempts to make progress on bugs that interest to me
>> (possibly to the annoyance of actual DMs/DDs), so my opinion is
>> somewhat external (i.e.: take with a grain of salt).
>
>
> Thrilled that you reached out about it.

I've been thinking more about how to improve the chances that the
package could be accepted into Debian -- my suggestion would be to
rebuild it and upload it to the mentors[1] portal, where it can
(hopefully) receive review.  I've considered uploading it myself, but
I don't have hardware to test the results on, so I'd be navigating
without a way to test the results.  From personal experience
attempting packaging: the mentoring guidelines and making sure to run
lintian checks are both worthwhile.

Even so there'd be no guarantee of review or upload acceptance -- and
unfortunately the same test-hardware limitation probably applies to
most reviewers -- so I don't know whether it'd be worth your time, but
in my mind it's possible that someone attempts to install Debian on an
X1000 platform in future, learns of this bug, and then in a
hypothetical future _might_ find libx1000 in the archive, and then be
grateful for the availalble fix.

(after re-reading your blog-post, I think that there could technically
still be rare cases where the bug appears despite the package being
installed -- the mention of 98% of cases handled -- but even so, a
mostly-usable system compared to a completely useless one seems like a
big improvement)

[1] - https://mentors.debian.net/

Bug#1056054: openmpi-doc: /usr/share/man/man1/pterm.1.gz is already shipped by pterm

[Andreas Beckmann]

Package: openmpi-doc
Version: 5.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Unpacking openmpi-doc (5.0.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/openmpi-doc_5.0.0-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/pterm.1.gz', which is also in 
package pterm 0.79-1
  Errors were encountered while processing:
   /var/cache/apt/archives/openmpi-doc_5.0.0-1_all.deb

cheers,

Andreas


pterm=0.79-1_openmpi-doc=5.0.0-1.log.gz
Description: application/gzip

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi again Balint,

On 16/11/2023 11:35, Bálint Réczey wrote:

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58


You mentioned:

"The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch."

I'm not quite sure what is incorrect here, this file is patched already 
via debian/patches/0001-fix-libtypec-libdir.patch


For an i386 build, the .pc file in usr/share/pkgconfig contains:

prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/i386-linux-gnu
includedir=${prefix}/include/i386-linux-gnu
..

For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/x86_64-linux-gnu
..

For an arm64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/aarch64-linux-gnu
includedir=${prefix}/include/aarch64-linux-gnu
..

..so I'm a bit confused. Do you mind clarifying for me.

Colin

Bug#1056057: bumps-private-libs: please add arm64 to the list of supported architectures

[Emanuele Rocca]

Package: bumps-private-libs
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: arm64

Hi!

bumps-private-libs builds fine on arm64. Please add arm64 to the
Architecture field in debian/control.

Thanks,
  Emanuele

Bug#1055526: efibootmgr: output broken and shows hex dump after update (can be fixed with -u, which is documented as unrelated)

[наб]

On Tue, Nov 07, 2023 at 09:12:39PM +0100, наб wrote:
> Package: efibootmgr
> Version: 18-1
> Severity: normal
> 
> -- >8 --
> $ efibootmgr
> Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  
> HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64)69006e0069007400720064003d005c006b006c00610070006b0069005c00370033003100620036003900660030006400610063003100340037006500660061006400660065006400390032006600310032003700310032003700330036005c0036002e0031002e0030002d0039002d0061006d006400360034005c0069006e0069007400720064002e0069006d0067002d0036002e0031002e0030002d0039002d0061006d00640036003400200072006f006f0074003d007a00660073003a004100550054004f0020006600620063006f006e003d0072006f0074006100740065003a003300200069006e00740065006c005f0069006f006d006d0075003d006f006e0020007a00660073002e007a00660073005f006100720063005f006d00610078003d003100320038003800340039003000310038003800380020007100750069006500740020006d006f00640075006c0065002e007300690067005f0065006e0066006f007200630065003d003100
> -- >8 --
> 
> Previous versions did something like this:
> -- >8 --
> Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  
> HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64).i.n.i.t.r.d.=.\.k.l.a.p.k.i.\.7.3.1.b.6.9.f.0.d.a.c.1.4.7.e.f.a.d.f.e.d.9.2.f.1.2.7.1.2.7.3.6.\.6...1...0.-.9.-.a.m.d.6.4.\.i.n.i.t.r.d...i.m.g.-.6...1...0.-.9.-.a.m.d.6.4.
>  .r.o.o.t.=.z.f.s.:.A.U.T.O. .f.b.c.o.n.=.r.o.t.a.t.e.:.3. 
> .i.n.t.e.l._.i.o.m.m.u.=.o.n. 
> .z.f.s...z.f.s._.a.r.c._.m.a.x.=.1.2.8.8.4.9.0.1.8.8.8. .q.u.i.e.t. 
> .m.o.d.u.l.e...s.i.g._.e.n.f.o.r.c.e.=.1.
> -- >8 --
> which was suboptimal but still okay (as-in "readable").

And efibootdump still does!
-- >8 --
$ efibootdump Boot0005
Boot0005: * Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64 
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64)i.n.i.t.r.d.=.\.k.l.a.p.k.i.\.7.3.1.b.6.9.f.0.d.a.c.1.4.7.e.f.a.d.f.e.d.9.2.f.1.2.7.1.2.7.3.6.\.6...1...0.-.9.-.a.m.d.6.4.\.i.n.i.t.r.d...i.m.g.-.6...1...0.-.9.-.a.m.d.6.4.
 .r.o.o.t.=.z.f.s.:.A.U.T.O. .f.b.c.o.n.=.r.o.t.a.t.e.:.3. 
.i.n.t.e.l._.i.o.m.m.u.=.o.n. 
.z.f.s...z.f.s._.a.r.c._.m.a.x.=.1.2.8.8.4.9.0.1.8.8.8. .q.u.i.e.t. 
.m.o.d.u.l.e...s.i.g._.e.n.f.o.r.c.e.=.1.
-- >8 --
so what's the deal with this?

I tried to build upstream to bisect this
but it just fundamentally refuses to build, so.

Best,
наб


signature.asc
Description: PGP signature

Bug#1056058: libavcodec-extra60: Segmentation fault in vlc 3.0.20-1+b1 attempting to play DVB-T stream

[Arthur Marsh]

Package: libavcodec-extra60
Version: 7:6.1-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Upgrading ffmpeg related packages
ffmpeg (7:6.1-2) over (7:6.0-9+b1)

>From gdb:

Thread 25 "vlc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa4dff6c0 (LWP 16147)]
0x7fff9dcad5a3 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.60
(gdb) bt
#0  0x7fff9dcad5a3 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#1  0x7fff9e02784e in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#2  0x7fff9e02ae3f in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#3  0x7fff9dfec504 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#4  0x7fff9dfecb35 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#5  0x7fff9dcaad65 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#6  0x7fff9dcab364 in avcodec_send_packet ()
at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#7  0x7fffa4c3b2c2 in  ()
at /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libavcodec_plugin.so
#8  0x77b3b377 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#9  0x77b3af42 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#10 0x77b3b7a4 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#11 0x77c8932c in start_thread (arg=)
at ./nptl/pthread_create.c:444
#12 0x77d0a428 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) bt full
#0  0x7fff9dcad5a3 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#1  0x7fff9e02784e in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#2  0x7fff9e02ae3f in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#3  0x7fff9dfec504 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#4  0x7fff9dfecb35 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#5  0x7fff9dcaad65 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#6  0x7fff9dcab364 in avcodec_send_packet ()
at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#7  0x7fffa4c3b2c2 in  ()
at /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libavcodec_plugin.so
#8  0x77b3b377 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#9  0x77b3af42 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#10 0x77b3b7a4 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#11 0x77c8932c in start_thread (arg=)
at ./nptl/pthread_create.c:444
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737350504560, 
-7686621085864270227, -120, 0, 140736566969536, 140735958478848, 
7686777490886911597, 7686603636391044717}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#12 0x77d0a428 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78


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

Tried different video outputs with no change, downgrading packages resulted
in successful DVB-T stream playback

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.0-rc1+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libavcodec-extra60 depends on:
ii  libaom3 3.7.0-1
ii  libaribb24-01.0.3-2
ii  libavutil58 7:6.1-2
ii  libc6   2.38-3
ii  libcairo2   1.18.0-1
ii  libcodec2-1.2   1.2.0-2
ii  libdav1d7   1.3.0-2
ii  libglib2.0-02.78.1-4
ii  libgsm1 1.0.22-1
ii  libjxl0.7   0.7.0-10.2
ii  liblzma55.4.4-0.1
ii  libmp3lame0 3.100-6
ii  libopencore-amrnb0  0.1.6-1
ii  libopencore-amrwb0  0.1.6-1
ii  libopenjp2-72.5.0-2
ii  libopus01.4-1
ii  librav1e0   0.6.6-3
ii  librsvg2-2  2.54.7+dfsg-2
ii  libshine3   3.1.1-2
ii  libsnappy1v51.1.10-1
ii  libspeex1   1.2.1-2
ii  libsvtav1enc1d1 1.7.0+dfsg-2
ii  libswresample4  7:6.1-2
ii  libtheora0  1.1.1+dfsg.1-16.1+b1
ii  libtwolame0 0.4.0-2
ii  libva2  2.20.0-2
ii  libvo-amrwbenc0 0.1.3-2
ii  libvorbis0a 1.3.7-1
ii  libvorbisenc2   1.3.7-1
ii  libvpl2 2023.3.0-1
ii  libvpx8 1.13.1-2
ii  libwebp71.3.2-0.3
ii  libwebpmux3 1.3.2-0.3
ii  libx264-164 2:0.164.3095+gitbaee400-3+b1
ii  libx265-199 3.5-2+b1
ii  libxvidcore42:1.3.7-1
ii  libzvbi00.2.42-1
ii  zlib1g  1:1.2.13.dfsg-3

Bug#1056063: RFP: haskell-crypton-connection -- simple and easy network connections API

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Haskell Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: haskell-crypton-connection
  Version : 0.3.1
  Upstream Contact: Vincent Hanquez 
* URL : https://hackage.haskell.org/package/crypton-connection
* License : BSD-3-Clause
  Programming Lang: Haskell
  Description : simple and easy network connections API

 Simple network library for all your connection need.
 .
 Features: Really simple to use, SSL/TLS, SOCKS.
 .
 This library provides a very simple api
 to create sockets to a destination
 with the choice of SSL/TLS, and SOCKS.

This library is needed to upgrade pandoc.

I would appreciate if the Haskell team could care for this library
package.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVWOcUACgkQLHwxRsGg
ASFwPw/+I0FuWksz49lR4Et/OiXxk+HaFRUJNKvFcs5ZraIGlOWI+slwdcYiONdn
uJEJ+you/YJ5Zh0OfXzjkMvykQEU13QdNQjWHO6oQMW2zqVnW+jeBCIe6VS+ND7Z
kdAz9eOaD87V/0XVAyEhqdgPOot+9otlVtsLDp8NBHSQDlnPUCnLEIOSoO15iuv8
uHiPDJReMc2KD83Zo7Er1BpBzartxlwjRxcHHdKdxW1j55ajHRxmmC2S6brFGJmL
1BuA/ABPwcpPcs/SGtNFb5dUnrNDZ7xgpsMCu54ZtgkFk3ZM3IEkBMl6BhrL6yOx
Q7/e4m0bDvaTX5D1/cJMvJ67PV7W5SNpJceC76Wb7nNlqegyL8r7OnDDUvxB8U45
4Xd0VWkQw20zZwNVE1SHHaNPXGvBEEj1Ce14Jj3uUuEpJnZUfjC2PmvtZaObwZ1r
L6G6onuiPNqO5rXwZHbZZxn4aYWpmXjIFKjrWKT/pihfTlr6XdB1Yz59hww86khs
N34Imey8LcJArIlNPe7V0tHa2fPbSCuH/ChloSzupPB6IkNLIMnbQsTjJ0UoYkrj
016qA5KKN628VjRxP+WF0LMeC0uJf4Rvwc2+G+2Mw83POO1B3RXBAGRQbstDJtv9
0tCVSsjsXAQjgwQXuNpaCP2VDzzuQ1RPNk8cdwoHwZu3sYao3/4=
=M/n1
-END PGP SIGNATURE-

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 14:00):
>
> Hi again Balint,
>
> On 16/11/2023 11:35, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Thanks for the quick response.
> > Please check my other observations, too, in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58
>
> You mentioned:
>
> "The .pc file is now at the right location, but contains multiarch
> strings which will differ across architectures.
> I suggest hardcoding the paths in the patch."
>
> I'm not quite sure what is incorrect here, this file is patched already
> via debian/patches/0001-fix-libtypec-libdir.patch
>
> For an i386 build, the .pc file in usr/share/pkgconfig contains:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/i386-linux-gnu
> includedir=${prefix}/include/i386-linux-gnu
> ..
>
> For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/x86_64-linux-gnu
> includedir=${prefix}/include/x86_64-linux-gnu
> ..
>
> For an arm64 build, the .pc file in usr/share/pkgconfig contains:
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/aarch64-linux-gnu
> includedir=${prefix}/include/aarch64-linux-gnu
> ..
>
> ..so I'm a bit confused. Do you mind clarifying for me.

I'm sorry, my comment was a bit vague, indeed.
So the problem is having the multiarch string in the .pc file, while
the file is not in a multiarch location.
Lintian throws an error about it, that would cause an auto-reject when
uploading the package:

E: libtypec-dev: pkg-config-multi-arch-wrong-dir full text contains
architecture specific dir x86_64-linux-gnu
[usr/share/pkgconfig/libtypec.pc]
N:
N:   The arch all pkg-config file contains a reference to a multi-arch path.
N:
N:   This can be usually be fixed by moving this file to a multi-arch path.
N:
N:   Another likely cause is using debhelper 9 or newer (thus enabling
multi-arch paths
N:   by default) on a package without multi-arch support. The usual
cure in this case is
N:   to update it for multi-arch.
N:
N:   Last but not least, this file could contain a reference to a
cross architecture
N:   (like for instance an x86_64-linux-gnu pkg-config file referencing an
N:   i386-linux-gnu file). In this case the usual cure is to fix this path.
N:
N:   Visibility: error
N:   Show-Always: no
N:   Check: files/pkgconfig

Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
 prefix=/usr
 exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

 Name: libtypec
 Description: USB-Type C and USB Power Delivery class devices
 Version: 0.4.0

 Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec

Cheers,
Balint



> Colin
>

Bug#1056065: transition: spdlog

[Andrius Merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: cru...@debian.org

Hello,

I would like to request a transition slot for spdlog (experimental -> 
unstable) due to soname bump. Ben tracker was not set up automatically, 
thus its file should look like this:


is_affected = .depends ~ 
/\b(libspdlog\-dev|libspdlog1\.10|libspdlog1\.12)\b/;

is_good = .depends ~ /\b(libspdlog\-dev|libspdlog1\.12)\b/;
is_bad = .depends ~ /\b(libspdlog1\.10)\b/;

I have ratt-rebuilt all reverse dependencies with all of them building 
successfully except nmodl (FTBFS with catch2, #1054683) and the 
following packages which are not in sid due to other reasons:


* kodi (seems to be affected by spdlog API change)
* gr-dab (unrelated CMake problems)
* vast (problem with "Flatbuffers")
* purify - FTBFS eigen3 (#1001528, not in sid)

Best,
Andrius

Bug#1056072: RFP: eww A widget system written in Rust

[Lucas Cruz dos Reis]

Package: eww
Severity: wishlist
X-Debbugs-Cc: lcr.e...@gmail.com

Dear Maintainer,
I would like to suggest eww (Elkowars Wacky Widgets)
to be packaged for Debian. which provides ways for Window Manager
users to define their own widgets.

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

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

Bug#1056091: ITP: golang-github-prometheus-community-pgbouncer-exporter -- Prometheus exporter for PgBouncer

[Lena Voytek]

Package: wnpp
Severity: wishlist
Owner: Lena Voytek 
X-Debbugs-Cc: debian-de...@lists.debian.org, l...@voytek.dev

* Package name: golang-github-prometheus-community-pgbouncer-exporter
  Version : 0.7.0
  Upstream Author : Prometheus Monitoring Community
* URL : https://github.com/prometheus-community/pgbouncer_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for PgBouncer

PgBouncer Exporter extracts data and metrics from pgbouncer for
monitoring using Prometheus tools. It provides a useful
connection between PostgreSQL databases and the Prometheus
ecosystem. For more information on Prometheus exporters see
https://prometheus.io/docs/instrumenting/exporters/

I intend to actively maintain this package within the Debian Go
Packaging team.

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Sven Joachim]

Package: systemd
Version: 255~rc2-1
Severity: important

After upgrading systemd from 254.5-1 and rebooting, rsyslog failed to
start on my system.  These messages appear in the journal:

,
| Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
Logging Service...
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create destination mount 
point node '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file 
system
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount /dev/xconsole to 
/run/systemd/mount-rootfs/dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed to set up 
mount namespacing: /dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process exited, 
code=exited, status=226/NAMESPACE
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
'exit-code'.
| Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
System Logging Service.
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart job, 
restart counter is at 1.
`

This gets repeated a few times, and after five restart attempts systemd
gives up.

It should be noted that I have enabled forwarding messages to xconsole
according to the the "Logging to xconsole" section in
/usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
"BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
lets rsyslog start, but recreates the problem of #1053913.


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/4 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)

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libapparmor1   3.0.12-1
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-6
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.4-0.1
ii  libmount1  2.39.2-6
ii  libpam0g   1.5.2-9.1
ii  libseccomp22.5.4-2
ii  libselinux13.5-1
ii  libssl33.0.12-2
ii  libsystemd-shared  255~rc2-1
ii  libsystemd0255~rc2-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.2-6
ii  systemd-dev255~rc2-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-3
ii  systemd-timesyncd [time-daemon]  255~rc2-1

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1+b1
ii  libip4tc2 1.8.9-2
ii  libp11-kit0   0.25.0-5
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  polkitd   123-3
ii  python3   3.11.4-5+b1
pn  python3-pefile
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-3
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 255~rc2-1
ii  libpam-systemd 255~rc2-1
ii  udev   255~rc2-1

-- no debconf information

Bug#1055881: virtualbox-dkms: Linux 6.7-rc1 throws "invalid opcode" during module loading

[Ingo Saitz]

retitle 1055881 Linux 6.7-rc1 / Linux 6.6.1 UBSan errors
forwarded 1055881 https://www.virtualbox.org/ticket/21877
thanks

I found the "invalid opcode" was caused by CONFIG_UBSAN_TRAP=y, that was
set by the hardening.config from linux 6.7-rc1. Using the same options I
can reproduce the bug on 6.6.1, too.

This is also reported upstream as https://www.virtualbox.org/ticket/21877

Changing CONFIG_UBSAN_TRAP to no shows these errors in the log (see
attachment.

Sorry for the wrong noise, but I suggest to keep this bug open, since
there is no similar bug reported.

Ingo
-- 
const_cast(Λ)
[   17.127943] vboxdrv: loading out-of-tree module taints kernel.
[   17.132074] vboxdrv: Found 2 processor cores/threads
[   17.133888] 

[   17.134091] UBSAN: array-index-out-of-bounds in 
/var/lib/dkms/virtualbox/7.0.12/build/vboxdrv/common/log/log.c:1791:41
[   17.134304] index 1 is out of range for type 'uint32_t [1]'
[   17.134521] CPU: 1 PID: 1988 Comm: modprobe Tainted: G   O   
6.6.1-pinguin20231116 #1
[   17.134755] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   17.135004] Call Trace:
[   17.135259]  
[   17.135516]  dump_stack_lvl+0x32/0x40
[   17.135782]  __ubsan_handle_out_of_bounds+0xc3/0x100
[   17.136055]  VBoxHost_RTLogGroupSettings+0x472/0x490 [vboxdrv]
[   17.136347]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.136573]  VBoxHost_RTLogCreateExV+0x27a/0x480 [vboxdrv]
[   17.136800]  VBoxHost_RTLogCreate+0x6a/0x90 [vboxdrv]
[   17.137030]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.137263]  supdrvInitDevExt+0x54/0x320 [vboxdrv]
[   17.137498]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   17.137738]  ? 0xc05f5000
[   17.137962]  do_one_initcall+0x8e/0x2c0
[   17.138190]  do_init_module+0x7d/0x230
[   17.138423]  init_module_from_file+0x81/0xc0
[   17.138658]  idempotent_init_module+0x119/0x230
[   17.138897]  __x64_sys_finit_module+0x4d/0x80
[   17.139140]  do_syscall_64+0x56/0xb0
[   17.139385]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   17.139636] RIP: 0033:0x7fb8a591eee9
[   17.139888] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   17.140183] RSP: 002b:7fff225703a8 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.140496] RAX: ffda RBX: 555e4ea0e600 RCX: 7fb8a591eee9
[   17.140814] RDX:  RSI: 555e4d89598b RDI: 0003
[   17.141137] RBP:  R08: 0060 R09: 555e4ea0f340
[   17.141464] R10: 0038 R11: 0246 R12: 555e4d89598b
[   17.141794] R13: 0004 R14: 555e4ea0e680 R15: 
[   17.142130]  
[   17.142471] 

[   17.142843] 

[   17.143196] UBSAN: array-index-out-of-bounds in 
/var/lib/dkms/virtualbox/7.0.12/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:399:33
[   17.143561] index 1 is out of range for type 'page *[1]'
[   17.143933] CPU: 1 PID: 1988 Comm: modprobe Tainted: G   O   
6.6.1-pinguin20231116 #1
[   17.144313] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   17.144703] Call Trace:
[   17.145097]  
[   17.145495]  dump_stack_lvl+0x32/0x40
[   17.145902]  __ubsan_handle_out_of_bounds+0xc3/0x100
[   17.146311]  rtR0MemObjLinuxAllocPages+0x325/0x340 [vboxdrv]
[   17.146746]  rtR0MemObjNativeAllocCont+0x5a/0x110 [vboxdrv]
[   17.147183]  supdrvGipCreate+0x59/0xc30 [vboxdrv]
[   17.147623]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.148068]  supdrvInitDevExt+0x148/0x320 [vboxdrv]
[   17.148516]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   17.148966]  ? 0xc05f5000
[   17.149401]  do_one_initcall+0x8e/0x2c0
[   17.149839]  do_init_module+0x7d/0x230
[   17.150280]  init_module_from_file+0x81/0xc0
[   17.150725]  idempotent_init_module+0x119/0x230
[   17.151177]  __x64_sys_finit_module+0x4d/0x80
[   17.151621]  do_syscall_64+0x56/0xb0
[   17.152065]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   17.152510] RIP: 0033:0x7fb8a591eee9
[   17.152951] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   17.153431] RSP: 002b:7fff225703a8 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.153925] RAX: ffda RBX: 555e4ea0e600 RCX: 7fb8a591eee9
[   17.154416] RDX:  RSI: 555e4d89598b RDI: 0003
[   17.154904] RBP:  R08: 0060 R09: 555e4ea0f340
[   17.155388] R10: 0038 R11: 0246 

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi Balint,


Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
  prefix=/usr
  exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

  Name: libtypec
  Description: USB-Type C and USB Power Delivery class devices
  Version: 0.4.0

  Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec



Ah, good idea. I've refreshed package with this change. Also updated the 
.symbols file and uploaded a -4 to mentors.


Colin

Bug#1056071: acpi-support: When lid closed, a loop of lid closed/lid opened events cause 100%cpu usage

[Florence Birée]

Package: acpi-support
Version: 0.143-5.1
Severity: normal
X-Debbugs-Cc: flore...@biree.name

Dear Maintainer,

Since a week or two, in my Debian Unstable, my CPU has an high usage
when the laptod lid is closed (working with my external screen via my
dock station, by example).

This seems to be caused by a loop of Lid closed/Lid opened events, as
show in this journalctl -f output:

nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid closed.

... and so on.

But the state in /proc/acpi/button/lid/LID/state seems to be OK

This only occur when the lid is closed, when it is opened, I got only
one LID open event, which is the correct behavior.

I disabled all lid events in /etc/apci/events/lidbtn to prevent this
loop of events to run actions, and so to avoid the 100% cpu problem
(caused by the lid actions), but I would prefer to have this action
working correctly as before.

My laptop is a lenovo thinkpad x250.

I hop you will have an idea of the source of this problem...

Thanks for your work,
Florence

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 acpi-support depends on:
ii  acpi-support-base  0.143-5.1
ii  acpid  1:2.0.34-1
ii  sysvinit-utils [lsb-base]  3.08-3
ii  x11-xserver-utils  7.7+10

Versions of packages acpi-support recommends:
pn  acpi-fakekey  
ii  rfkill2.39.2-6

Versions of packages acpi-support suggests:
pn  radeontool   
pn  vbetool  
pn  xinput   
pn  xscreensaver | gnome-screensaver | kscreensaver | xautolock | xlock  
 | xtrlock | i3lock | cinnamon-screensaver

-- Configuration Files:
/etc/acpi/events/lidbtn changed:
event=button[ /]lid XXX
action=/etc/acpi/lid.sh


-- no debconf information

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Ilias Tsitsimpis]

Hi Jonas,

On Thu, Nov 16, 2023 at 01:28PM, Jonas Smedegaard wrote:
> Upstream project has restructured to now be organized as multiple
> projects to be built as dependencies of each other.
> 
> I had hoped to be able to orchestrate such chain-of-builds internally in
> the single source package, but the Haskell build helper tools seem to be
> in too bad shape for that: Apparently all Haskell packages use CDBS
> which is quite cumbersome to use for "looping" subtasks, and both of the
> two available non-CDBS debhelper tools existing in Debian are broken.

I would suggest packaging these libraries as distinct packages in
Debian, not only because our tooling doesn't support the other way, but
also because these are distinct packages in Hackage, with different
versions/releases. Essentially treat Hackage as the source of truth, and
not the git (mono-) repo.

> I therefore give up on that approach, and see no other way forward than
> to introduce the libraries of Pandoc as a new source package, and then
> have the existing src:pandoc package depend on that to build the binary.
> 
> I will now file an RFP for that new dependent package, in the hope that
> the Haskell team can adopt maintenance of that.

Please let me know of any missing libraries, and I will package them
ASAP. I thought we had everything in Debian until now. See also my
message here [1], where I point to the new pandoc-cli package, and the
fact that Lua support is currently broken, and maybe it's best to
disable it for now.

Let me know how I can help.

[1] https://lists.debian.org/debian-haskell/2023/11/msg4.html

Best,

-- 
Ilias

Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64

[Ilias Tsitsimpis]

Hi Adrian,

On Thu, Nov 16, 2023 at 09:13AM, John Paul Adrian Glaubitz wrote:
> The attached patch is a backported version of the patch which applies to GHC 
> 9.4.7.

Thanks for working on this. I fear that applying this patch will change
the ABI for Cabal, and hence we will have to rebuild every Haskell
package in Debian. Because of that, I plan on waiting for the current
transition to finish, and then include this patch in the next GHC
upload.

Best,

-- 
Ilias

Bug#1053686: pandoc: cannot fulfill the build dependencies

[John MacFarlane]

Removing lua support would be most unfortunate!  If you need help from upstream 
in getting things to work, let me know.

Bug#1056101: gst-plugins-bad1.0: CVE-2023-44446: MXF demuxer use-after-free

[Salvatore Bonaccorso]

Source: gst-plugins-bad1.0
Version: 1.22.4-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gst-plugins-bad1.0.

CVE-2023-6[0]:
| MXF demuxer use-after-free


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-6
https://www.cve.org/CVERecord?id=CVE-2023-6
[1] https://gstreamer.freedesktop.org/security/sa-2023-0010.html
[2] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5635
[3] 
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/7dfaa57b6f9b55f17ffe824bd8988bb71ae11353

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056074: libreoffice: FTBFS: boost1.83 transition

[Anton Gladky]

Hi Rene,

thanks for the deep analysis. We did a full rebuild of related
packages and it looks like libreoffice was false negative.

Let's keep the bug open for now, till we switch to a newer
version and if all is OK, the bug will be closed.

Best regards

Anton

Bug#1056090: Link update

[Anton Gladky]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/aegisub_3.2.2+dfsg-7_unstable_boost181.log

Thanks

Anton

Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor

[Matteo Settenvini]

Package: dracut
Version: 059-4
Severity: important

Dear Maintainer,

dracut will fail to produce a booting initrd since systemd 255 in Debian trixie.

The reason is that /usr/lib/systemd/systemd-executor is missing from the initrd 
image.
The corresponding patch is: https://github.com/dracutdevs/dracut/pull/2535/files

This can also be worked around by creating 
/etc/dracut.conf.d/99-systemd-dracut-bug.conf:

install_items+=" /usr/lib/systemd/systemd-executor "

... and then running dpkg-reconfigure dracut again.

$ apt show systemd
Package: systemd
Version: 255~rc2-1

Thanks!
Matteo Settenvini

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 dracut depends on:
ii  dracut-core  059-4

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1055931: apt ignores bullseye-backports

[Nis Martensen]

Hi Vincent,

On 14.11.2023 15.17, Vincent Lefevre wrote:
>> Checking for newer versions at madison and 
>> https://ftp-master.debian.org/new.html
>>
>> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
>> date.
>> The following newer release(s) are available in the Debian archive:
>>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1

> So I'm wondering where this information comes from.

I can find "6.1.55+1~bpo11+1" in https://ftp-master.debian.org/new.822
so it must come from there.

You looked for the binary package in the new queue, that's why you did
not see it. However, reportbug looks for the source package
corresponding to your binary package:
https://sources.debian.org/src/reportbug/12.0.0/reportbug/checkversions.py/?hl=37#L268

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Nis Martensen]

control: tags -1 pending

On 16.11.2023 12.48, Vincent Lefevre wrote:
> Control: retitle -1 reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved 
> Permanently
> 
> On 2023-11-16 12:34:17 +0100, Vincent Lefevre wrote:
>> So this URL gives a 301 Moved Permanently with
>> https://ftp-master.debian.org/new.822 as the new URL,
>> and reportbug does not attempt to use this new URL.

It will in the next version. This was fixed in git already:
https://salsa.debian.org/reportbug-team/reportbug/-/commit/7fef65e8bf41a9946eb416597c39408a77aa3f56

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Vincent Lefevre]

On 2023-11-16 17:34:57 +0100, Nis Martensen wrote:
> On 16.11.2023 12.48, Vincent Lefevre wrote:
> > Control: retitle -1 reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved 
> > Permanently
> > 
> > On 2023-11-16 12:34:17 +0100, Vincent Lefevre wrote:
> >> So this URL gives a 301 Moved Permanently with
> >> https://ftp-master.debian.org/new.822 as the new URL,
> >> and reportbug does not attempt to use this new URL.
> 
> It will in the next version. This was fixed in git already:
> https://salsa.debian.org/reportbug-team/reportbug/-/commit/7fef65e8bf41a9946eb416597c39408a77aa3f56

I think that the URL given in the reportbug output should
be corrected too. It says

  Checking for newer versions at madison and 
https://ftp-master.debian.org/new.html

but the URL will actually be https://ftp-master.debian.org/new.822
and the contents are different from new.html! See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055931#34

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

Bug#1055716: python-mapnik ftbfs with Python 3.12

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 11/10/23 11:03, Sebastiaan Couwenberg wrote:

On 11/10/23 10:49, Matthias Klose wrote:
src/python_grid_utils.cpp:108:26: error: there are no arguments to 
‘PyUnicode_FromUnicode’ that depend on a template parameter, so a 
declaration of ‘PyUnicode_FromUnicode’ must be available [-fpermissive]
   108 |  PyUnicode_FromUnicode(line.get(), 
array_size;

   |  ^
src/python_grid_utils.cpp:108:26: note: (if you use ‘-fpermissive’, 
G++ will accept your code, but allowing the use of an undeclared name 
is deprecated)


Upstream is aware that PyUnicode_FromUnicode was deprecated but has not 
acted on that yet. Upstream development is pretty much dead, someone 
will have to provide a patch to port python-mapnik away from 
PyUnicode_FromUnicode.


Fedora has a patch for this which we now use too.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1056067: ITP: node-sass-loader -- css loader module for webpack

[Alexandre Rossi]

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

* Package name: node-sass-loader
  Version : 13.3.2
  Upstream Contact: J. Tangelder
* URL : https://github.com/webpack-contrib/sass-loader
* License : MIT
  Programming Lang: Javascript
  Description : css loader module for webpack

Webpack takes code targeted at node.js and makes it run in the browser.
Node.js comes with API of its own that is not available in the browsers.
Webpack exposes this code to programs that are unaware they are running
in a browser.

Sass is a CSS preprocessor to include features that don’t exist in CSS yet
like nesting, mixins, inheritance, and other nifty goodies that help
write robust, maintainable CSS.

This package is enables webpack to include and compile Sass files
into a web application bundle.

Node.js is an event-based server-side JavaScript engine.

This is required to build some webapps.

I'll be seeking a sponsor for this.

Thanks,

Alex

Bug#1056067: ITP: node-sass-loader -- css loader module for webpack

[Alexandre Rossi]

Hi,

Package is awaiting sponsorship at 
https://mentors.debian.net/package/node-sass-loader/

Packaging is available at https://salsa.debian.org/niol/node-sass-loader

Thanks,

Alex

Bug#1056099: node-axios: CVE-2023-45857

[Salvatore Bonaccorso]

Source: node-axios
Version: 1.5.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/axios/axios/issues/6006
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-axios.

CVE-2023-45857[0]:
| An issue discovered in Axios 1.5.1 inadvertently reveals the
| confidential XSRF-TOKEN stored in cookies by including it in the
| HTTP header X-XSRF-TOKEN for every request made to any host allowing
| attackers to view sensitive information.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-45857
https://www.cve.org/CVERecord?id=CVE-2023-45857
[1] https://github.com/axios/axios/issues/6006
[2] 
https://github.com/axios/axios/commit/96ee232bd3ee4de2e657333d4d2191cd389e14d0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056089: Link update

[Anton Gladky]

Please use this link for logs

qa-logs.debian.net/2023/10/26/autodock-vina_1.2.5-1_unstable_boost181.log

thanks

Anton

Bug#1056061: gnome-console: Left-click selecting text down does not work. Only up.

[szcl]

Package: gnome-console
Version: 43.0-2
Severity: important
X-Debbugs-Cc: sazamor...@gmail.com


Dear Maintainer,


   * What led up to the situation?
Selecting text down.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Selecting text down does not advance towards the remaining text.
It works only up.

   * What was the outcome of this action?
Not able to select all text in one action as usual.

   * What outcome did you expect instead?
Left click select and scroll down to select all remaining text.


-- System Information:
Debian Release: 12.2
  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-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_CL:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-console depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gsettings-desktop-schemas43.0-1
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u3
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libgtop-2.0-11   2.40.0-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libvte-2.91-gtk4-0   0.70.6-2~deb12u1

gnome-console recommends no packages.

gnome-console suggests no packages.

-- no debconf information

Bug#1056070: hibiscus: Please package new version

[Martin Dosch]

Package: hibiscus
Version: 2.10.12+dfsg-1
Severity: wishlist

Dear Jochen,

could you please consider updating hibiscus to the current upstream 
version?

I checked out the git repo from salsa and locally built 2.10.15 without 
any issue so it should be easy to update the version in the debian 
repos.

Best regards,
Martin

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 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 hibiscus depends on:
ii  jameica   2.10.4+dfsg-1
ii  libeclipse-swtchart-java  0.13.0-4
ii  libguava-java 32.0.1-1
ii  libhbci4j-core-java   3.1.67+dfsg-1
ii  libitext5-java5.5.13.3-2
ii  libobantoo-java   2.1.12+ds1-4
ii  libpostgresql-jdbc-java   42.6.0-2
ii  libqrcodegen-java 1.8.0-1.2
ii  libsuper-csv-java 2.4.0-4

hibiscus recommends no packages.

hibiscus suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Ilias Tsitsimpis]

Hi John,

On Thu, Nov 16, 2023 at 10:25AM, John MacFarlane wrote:
> Removing lua support would be most unfortunate!  If you need help from 
> upstream in getting things to work, let me know.

We are currently tracking the latest Stackage LTS, and Lua support is
not enabled for Pandoc there (see also [1]).

It would help if you can give us a list of packages/versions we need to
use in order to compile pandoc-cli with Lua support using the latest
Stackage LTS.

[1] 
https://github.com/commercialhaskell/stack/issues/6260#issuecomment-1751302985

Thanks,

-- 
Ilias

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Am 16.11.23 um 17:17 schrieb Sven Joachim:

Package: systemd
Version: 255~rc2-1
Severity: important

After upgrading systemd from 254.5-1 and rebooting, rsyslog failed to
start on my system.  These messages appear in the journal:

,
| Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
Logging Service...
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create destination mount 
point node '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file 
system
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount /dev/xconsole to 
/run/systemd/mount-rootfs/dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed to set up 
mount namespacing: /dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process exited, 
code=exited, status=226/NAMESPACE
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
'exit-code'.
| Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
System Logging Service.
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart job, 
restart counter is at 1.
`

This gets repeated a few times, and after five restart attempts systemd
gives up.

It should be noted that I have enabled forwarding messages to xconsole
according to the the "Logging to xconsole" section in
/usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
"BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
lets rsyslog start, but recreates the problem of #1053913.


It appears, that PrivateTmp=yes was locked down further and is now 
remounted read-only (thanks bluca for the reference):

https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade

We basically have two options as I see it:

a/ Drop PrivateDevices=yes from rsyslog.service

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in 
/etc/tmpfiles.d/ and /etc/rsyslog.d/


They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole ----   /run/xconsole

Conceptually, moving the named pipe out of /dev and into /run is the 
cleaner solution I think. The /dev/xconsole symlink should make it 
reasonably backwards compatible.


Thoughts?


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Am 16.11.23 um 18:12 schrieb Michael Biebl:

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in 
/etc/tmpfiles.d/ and /etc/rsyslog.d/


They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
 news.err;\
 *.=debug;*.=info;\
 *.=notice;*.=warn    |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole -    -    -    -   /run/xconsole


And you need to drop BindPaths=-/dev/xconsole from rsyslog.service again.







OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Hello,

On 16/11/2023 18:14, Jonas Smedegaard wrote:

Upstream project consist of multiple crates released in sync - which is
a pattern that is only inefficiently handled by the Rust team (by
needlessly packaging each individual crate as a separate Debian source
package).

Unless you particularly are asking the Rust team for help here, then I
can offer to help: I have experience with handling this type of Rust
source code structure, and would be happy for this opportunity to
collaborate more closely with you, Andrej.


Yes, I’m aware of that, that’s why I packaged it separately from the 
debcargo-conf-managed packages. Nevertheless, the dependencies can be 
managed using debcargo-conf workflow (and that’s what I did when I still 
had energy to spend on this package).


In any case, I’ll be happy with any help that can be had with this 
package, whether it’s updating/packaging build dependencies as separate 
packages or by following the debcargo-conf workflow, and from anyone — 
you, Jonas, included :)


Thanks!

--
Cheers,
  Andrej

Bug#1055758: opensmtpd: OpenSMTPD release in stable (bookworm) is useless due to #1037359

[Ryan Kavanagh]

On Fri, Nov 10, 2023 at 10:06:11AM -0800, Mike Swanson wrote:
> Due to the bug mentioned in the subject (#1037359), OpenSMTPD fails to
> utilize TLS certificates with OpenSSL >= 3.0.0.  As such, the program
> is a total non-starter for any internet-facing mail solution (perhaps
> an internal mail server without encryption would be fine).  While the
> issue has been resolved upstream and in the sid and trixie
> repositories, it remains unusable in bookworm.

Indeed, OpenSMTPD in Debian stable is currently (only?) useful as a
local smarthost (my own use case for OpenSMTPD on Debian).
Unfortunately, a fix for #1037359 was not available in time for
bookworm.

I plan on uploading OpenSMTPD 7.4.0p2 to Debian backports in the near
future. This should at least provide a working version of OpenSMTPD for
those using bookworm.

Ryan

Bug#1053955: rust-toml: please update to v0.7.8

[Jonas Smedegaard]

Quoting Peter Green (2023-11-16 10:55:33)
> > Please update to (at least) newer upstream release v0.7.8.
> 
> toml itself is not semver-breaking, but it's closely coupled dependency
> toml_edit is.
[...] 
> My overall conclusion is that btm is the main blocker. Jonas, btm is one
> of your packages, can you work with upstream to prepare and test an update?
> 
> Updated versions of toml_edit and toml are availble in experimental for
> you to test with.

Please go ahead without waiting for btm: Upstream has swiftly responded
with an uncomplicated change.

Thanks for looking into this,

 - 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#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Sven Joachim]

On 2023-11-16 18:12 +0100, Michael Biebl wrote:

> Am 16.11.23 um 17:17 schrieb Sven Joachim:
>> Package: systemd
>> Version: 255~rc2-1
>> Severity: important
>> After upgrading systemd from 254.5-1 and rebooting, rsyslog failed
>> to
>> start on my system.  These messages appear in the journal:
>> ,
>> | Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
>> Logging Service...
>> | Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create
>> | destination mount point node
>> | '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file
>> | system
>> | Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount
>> | /dev/xconsole to /run/systemd/mount-rootfs/dev/xconsole: No such
>> | file or directory
>> | Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed
>> | to set up mount namespacing: /dev/xconsole: No such file or
>> | directory
>> | Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process 
>> exited, code=exited, status=226/NAMESPACE
>> | Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
>> 'exit-code'.
>> | Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
>> System Logging Service.
>> | Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart 
>> job, restart counter is at 1.
>> `
>> This gets repeated a few times, and after five restart attempts
>> systemd
>> gives up.
>> It should be noted that I have enabled forwarding messages to
>> xconsole
>> according to the the "Logging to xconsole" section in
>> /usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
>> the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
>> "BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
>> lets rsyslog start, but recreates the problem of #1053913.
>
> It appears, that PrivateTmp=yes was locked down further and is now
> remounted read-only (thanks bluca for the reference):
> https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade

Thanks, I had suspected something along these lines.

> We basically have two options as I see it:
>
> a/ Drop PrivateDevices=yes from rsyslog.service
>
> b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink
>
>
> The latter b/ will require updates to the local copies in
> /etc/tmpfiles.d/ and /etc/rsyslog.d/
>
> They would look like this now:
>
> $ cat /etc/rsyslog.d/xconsole.conf
> daemon.*;mail.*;\
>   news.err;\
>   *.=debug;*.=info;\
>   *.=notice;*.=warn   |/run/xconsole
>
> $ cat /etc/tmpfiles.d/xconsole.conf
> # Type Path Mode UID  GID  Age Argument
> p /run/xconsole 0640 root adm
> L /dev/xconsole ----   /run/xconsole
>
> Conceptually, moving the named pipe out of /dev and into /run is the
> cleaner solution I think. The /dev/xconsole symlink should make it
> reasonably backwards compatible.
>
> Thoughts?

I think b/ and an appropriate debian/NEWS entry in rsyslog are
preferable to softening security, even if it means some disruption for
the minority of users who still monitor logs via xconsole.  But there
may be more complaints once the changes arrive in testing.

Personally I have made your proposed changes, and after restarting
rsyslog and xconsole everything works fine again.

Cheers,
   Sven

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

[Jelle Haandrikman]

Package: audacious
Version: 4.3.1-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: jha...@freedom.nl

Dear Maintainer,


   * What led up to the situation?
Installed Audacious and opened it in QT mode in KDE plasma desktop

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The application does show the media buttons with the GTK interface.
Changing the KDE theme does not work.

   * What was the outcome of this action?
The media buttons (previous/ Pause / Stop/ Next / Repeat / Shuffle )  are
replaced with text versions.

   * What outcome did you expect instead?
Icons of the media buttons.



-- 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-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages audacious depends on:
ii  audacious-plugins 4.3.1-2
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-3
ii  dbus-x11 [dbus-session-bus]   1.14.10-3
ii  libaudcore5   4.3.1-2
ii  libc6 2.37-12
ii  libgcc-s1 13.2.0-5
ii  libglib2.0-0  2.78.1-2
ii  libstdc++613.2.0-5

Versions of packages audacious recommends:
ii  unzip  6.0-28

audacious suggests no packages.

-- no debconf information

Bug#1056060: gnome-text-editor: left-click selecting text down does not work. Only up.

[szcl]

Package: gnome-text-editor
Version: 43.2-1
Severity: important
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Selecting text down.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Selecting text down does not advance towards the remaining text.
It works only up.

   * What was the outcome of this action?
Not able to select all text in one action as usual.

   * What outcome did you expect instead?
Left click select and scroll down to select all remaining text.



-- System Information:
Debian Release: 12.2
  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-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_CL:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-text-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libeditorconfig0 0.12.6-0.1
ii  libenchant-2-2   2.3.3-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libgtksourceview-5-0 5.6.2-1
ii  libicu72 72.1-3
ii  libpango-1.0-0   1.50.12+ds-1

gnome-text-editor recommends no packages.

gnome-text-editor suggests no packages.

-- no debconf information

Bug#1056062: coq: FTBFS in sid (dune update?)

[Gianfranco Costamagna]

Source: coq
Version: 8.17.0+dfsg-1
Severity: serious

Hello,

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/coq.html

As said here, there is a build failure due to probably new dune or something 
similar.

I can reproduce locally, but not always, looks some concurrency issue but also 
running dune with -j1 doesn't fix the issue.

$ (cd _build/default && /usr/bin/bash -e -u -o pipefail -c 
'doc/stdlib/make-library-index doc/stdlib/index-list.html doc/stdlib/hidden-files')
Building file index-list.prehtml... Error: none of doc/stdlib/index-list.html 
and doc/stdlib/hidden-files mention theories/Arith/Between.v
grep: tmp: No such file or directory
grep: tmp: No such file or directory

This is probably the culprit of the issue, but I don't really understand why 
this is not found

and also why running it manually works
bash -e -u -o pipefail -c 'doc/stdlib/make-library-index 
doc/stdlib/index-list.html doc/stdlib/hidden-files'
Building file index-list.prehtml...
Done


Sorry for not providing a patch, but I really don't have much knowledge about 
this build system, and despite my efforts I'm still failing

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056064: RFP: haskell-typst -- parsing and evaluating typst syntax

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Haskell Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: haskell-typst
  Version : 0.3.2.1
  Upstream Contact: John MacFarlane 
* URL : https://hackage.haskell.org/package/typst
* License : BSD-3-Clause
  Programming Lang: Haskell
  Description : parsing and evaluating typst syntax

 A library for parsing and evaluating typst syntax.
 Typst is a document layout and formatting language.
 This library targets typst 0.7
 and currently offers only partial support.

This library is needed for upgrading pandoc.

I would appreciate if the Haskell team could care for packaging this.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVWOqQACgkQLHwxRsGg
ASHpbQ//fLTEkhCjf8gkr1XtHTaKU6JDjYEkZPm8PG0bpP/xnkZJlUHiuxr76dC/
13Kkdg+ij+jecqRVWju5kTPI0S69R7ZThuGn4Zv/P5R+gtHN49BuvK8kzDYU5tne
EryTheMXFeN5yPd1grawzyPoSSddcgD2dY1FlvvprQ4n0gVgJD15KID+xoyQ+iJf
oVPqMUVWmKn/fzee/x4+wkH1aPyQJJ3xO+EH4yaQEiUHxHXWDyJIbGQrn6sjDCk3
ZaRSA/21LDwMj58JwMfnM759oiKFIMCkWL/ViAP1YVQI1FUOb7baV9xr6uKiBmVP
+3k8yuhE1RtXh1/C5Gpaivp2gqVaPNlm2gApVgYcXUljZ/0wdBklmmfoTDuYg2by
S7LP16hmL3W7pTFnzFwdArxSHo6qNAHoOWB5dahZdAun3cIlY0Po7kXiwDTSRC09
cf6YwG3c/qeLTGnBDVK39jBhkYqdsEn2jLXLvT3ES8NTLtqgIGAyOdKvRIGGDwuE
6YSUW7/kaID/SMFdbo46kDZITV2VKmLP7rhEPITV7OyHEdBU+DxAGBsmIytlWlzK
lASTIznj8oEdxQwrJjIWHAQLu3b+u8qzsmS1XFM21T6FZWemW+29DH8lYXxWNZPv
Jq56l0KcYIZH73Y0O7Zjs7MBS6i3hq/bw08Wn/DQwxOnrPJFUW4=
=xirR
-END PGP SIGNATURE-

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 17:46):
>
> Hi Balint,
> >
> > Since libtypec installs include files and libs to the standard
> > locations actually there is no need to set those paths.
> > I think I would use the following patch:
> >
> > --- a/libtypec.pc.in
> > +++ b/libtypec.pc.in
> > @@ -1,12 +1,9 @@
> >   prefix=/usr
> >   exec_prefix=/usr
> > -libdir=${exec_prefix}/lib/x86_64-linux-gnu
> > -includedir=${prefix}/
> >
> >   Name: libtypec
> >   Description: USB-Type C and USB Power Delivery class devices
> >   Version: 0.4.0
> >
> >   Requires:
> > -Libs: -L${libdir} -llibtypec
> > -Cflags: -I${includedir}
> > +Libs: -llibtypec
> >

I think this patch application did not work out as intended, please
check the patched file.

The symbols file's first line is also still off and now the symbos
have debian package revisions.

Those are issues automatically detected by Lintian. I suggest running
lintian on the built binary packages' .changes file or populating the
packaging repository on Salsa where CI runs include lintian and many
other checks.

Cheers,
Balint

> Ah, good idea. I've refreshed package with this change. Also updated the
> .symbols file and uploaded a -4 to mentors.
>
> Colin

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Jonas Smedegaard]

Quoting John MacFarlane (2023-11-16 19:25:17)
> Removing lua support would be most unfortunate!  If you need help from 
> upstream in getting things to work, let me know.

I agree: Pandoc with its core scripting language disabled is a severely
crippled Pandoc.


 - 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#1056102: gst-plugins-bad1.0: CVE-2023-44429: AV1 codec parser buffer overflow

[Salvatore Bonaccorso]

Source: gst-plugins-bad1.0
Version: 1.22.4-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gst-plugins-bad1.0.

CVE-2023-44429[0]:
| AV1 codec parser buffer overflow


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-44429
https://www.cve.org/CVERecord?id=CVE-2023-44429
[1] https://gstreamer.freedesktop.org/security/sa-2023-0009.html
[2] 
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/b76a801f57353b893c344025cac56413140fca6d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056087: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/bali-phy_3.6.1+dfsg-1_unstable_boost181.log

Thanks

Anton

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: re...@packages.debian.org, debian-de...@lists.debian.org, Rust 
Maintainers 
Control: affects -1 + src:resvg

Hi all,

resvg is a command-line SVG renderer which I introduced to Debian back
in 2019. Unfortunately, very soon after the initial upload the upstream
has rewritten substantial parts of resvg, which resulted in it requiring
build dependencies that were missing from Debian at that point. I tried
to update resvg and upload the missing dependencies, but ultimately
never completed that work, and resvg was removed from bookworm.

Unfortunately, I cannot invest any more time into resvg at the moment,
so I have to officially request assistance with maintaining the resvg package.

To the Debian Rust team: if you can, please adopt this package.

Thank you.

The package description is:
 resvg is a command-line utility to render SVG files based on a static
 SVG Full 1.1 subset. It is a fast, small, portable, multiple
 backend SVG library designed for edge-cases.
 .
 resvg supports Cairo and Qt backends.

Bug#1056069: php-memcache: Upstream does not support php8.2 (version 4.x supports php 7.0-7.4)

[Gerardo Esteban Malazdrewicz]

Package: php-memcache
Version: 8.0+4.0.5.2+3.0.9~20170802.e702b5f9+-8
Severity: minor
X-Debbugs-Cc: gera...@malazdrewicz.com.ar

Dear Maintainer,

Upstream Release notes ( at https://pecl.php.net/package/memcache/8.2) say:
Version 8.2 (stable)
- Version 8.x support PHP 8.x
- Version 4.x supports PHP 7.0-7.4.

No lack of functionality observed though, but deprecation notices are 
generated, like:
PHP Deprecated:  Creation of dynamic property Memcache::$connection is 
deprecated in ...
generated since 8.2.


Would be possible to upgrade php-memcache to 8.2 in a future update?

Thanks for all your work, including php.

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages php-memcache depends on:
ii  php-common   2:93
ii  php8.2-memcache  8.0+4.0.5.2+3.0.9~20170802.e702b5f9+-8

php-memcache recommends no packages.

Versions of packages php-memcache suggests:
pn  memcached  

-- no debconf information

Bug#1051296: freecad: appimage file with version 0.21 works fine

[Leonardo Canducci]

Package: freecad
Version: 0.20.2+dfsg1-10
Followup-For: Bug #1051296

Dear Maintainer,

I've made some tests to get FreeCAD running correctly on my gome+wayland
sid system. First of all version 20.2 runs fine on XFCE and X. It
chashes on gnome+wayland when opening a file or creating a new project.
With the suggested fix (export COIN_GL_NO_CURRENT_CONTEXT_CHECK=1)
FreeCAD runs but its still very slow compared to XFCE (just open some
STL file and try panning or rotating the view). Tu sum up the suggested
fix improves things but doesn't completely solve the problem here.

I've tried the latest version (0.21.1) downloading the appimage file and 
it works fine with wayland. All is fine also with the 0.20.2 appimage
file so I guess the problem is related to the debian packaged version
only or its dependencies.

Regards,
Leonardo

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-10

Versions of packages freecad recommends:
ii  calculix-ccx2.20-1
ii  graphviz2.42.2-7+b3
ii  python3-opencamlib  2023.01.11-4

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1055931: apt ignores bullseye-backports

[Vincent Lefevre]

Hi Nis,

On 2023-11-16 17:31:13 +0100, Nis Martensen wrote:
> On 14.11.2023 15.17, Vincent Lefevre wrote:
> >> Checking for newer versions at madison and 
> >> https://ftp-master.debian.org/new.html
> >>
> >> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
> >> date.
> >> The following newer release(s) are available in the Debian archive:
> >>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
> 
> > So I'm wondering where this information comes from.
> 
> I can find "6.1.55+1~bpo11+1" in https://ftp-master.debian.org/new.822
> so it must come from there.

Thanks. I had first looked at

  https://ftp-master.debian.org/new.html

(as output by reportbug), and it doesn't appear on this page
(I searched for both "linux" and "6.1.55"). Note that clicking
on "Click to toggle all/binary-NEW packages" does not make this
kernel appear either.

FYI, I later looked at https://ftp-master.debian.org/new.822 too
(as I could see it in the strace output), but only searched for
linux-image there, explaining that I didn't find it either (it
actually appears as linux-signed-amd64).

At the bottom of the new.html page:
"You can also look at the RFC822 version."

But why are the contents different? (linux-signed-amd64 appears
only in the RFC822 version.)

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

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Quoting Andrej Shadura (2023-11-16 18:02:10)
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: re...@packages.debian.org, debian-de...@lists.debian.org, Rust 
> Maintainers 
> Control: affects -1 + src:resvg
> 
> Hi all,
> 
> resvg is a command-line SVG renderer which I introduced to Debian back
> in 2019. Unfortunately, very soon after the initial upload the upstream
> has rewritten substantial parts of resvg, which resulted in it requiring
> build dependencies that were missing from Debian at that point. I tried
> to update resvg and upload the missing dependencies, but ultimately
> never completed that work, and resvg was removed from bookworm.
> 
> Unfortunately, I cannot invest any more time into resvg at the moment,
> so I have to officially request assistance with maintaining the resvg package.
> 
> To the Debian Rust team: if you can, please adopt this package.

Upstream project consist of multiple crates released in sync - which is
a pattern that is only inefficiently handled by the Rust team (by
needlessly packaging each individual crate as a separate Debian source
package).

Unless you particularly are asking the Rust team for help here, then I
can offer to help: I have experience with handling this type of Rust
source code structure, and would be happy for this opportunity to
collaborate more closely with you, Andrej.


Kind regards,

- Jonas

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

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

signature.asc
Description: signature