Bug#1070031: heimdal-kdc: fails to install if /usr/bin/kadmin is not Heimdal kadmin

[Brian May]

Ryan Tandy  writes:

> # update-alternatives --display kadmin
> kadmin - auto mode
>   link best version is /usr/bin/kadmin.mit
>   link currently points to /usr/bin/kadmin.mit
>   link kadmin is /usr/bin/kadmin
>   slave kadmin.1.gz is /usr/share/man/man1/kadmin.1.gz
> /usr/bin/kadmin.heimdal - priority 23
>   slave kadmin.1.gz: /usr/share/man/man1/kadmin.heimdal.1.gz
> /usr/bin/kadmin.mit - priority 30
>   slave kadmin.1.gz: /usr/share/man/man1/kadmin.mit.1.gz

I am wondering if maybe kadmin should not be using update-alternatives.

I think it is policy - although I can't find it right now - that update
alternatives should only be used for similar commands, i.e. similiar
command line parsing, does the same thing, etc.

But I don't think any of this applies for kadmin. It could be very
confusing if you are kadmin by hand, not realizing you are running the
wrong command.

Any thoughts?

Maybe I should ask the MIT kerberos maintainer for opinions here also.
-- 
Brian May @ Debian

Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects

[Thorsten Glaser]

Jay Berkenbilt dixit:

>How's that?

That explains it very well and not ambiguous to nōn-native
speakers (I hope).

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1070034: ITP: gnome-shell-extension-blur-my-shell -- Extension that adds a blur look to different parts of the GNOME Shell

[Marcelo Jorge Vieira]

Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira 

* Package name    : gnome-shell-extension-blur-my-shell
  Version : 61
  Upstream Author : Aurélien Hamy
* URL : https://github.com/aunetx/blur-my-shell/
* License : GPL-3.0
  Programming Lang: JavaScript
  Description : Extension that adds a blur look to different parts
of the GNOME Shell


A GNOME Shell extension that adds a blur look to different parts of the
GNOME Shell, including the top panel, dash and overview.


-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
https://metaldot.alucinados.com



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

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Vincent Lefevre]

On 2024-04-29 03:05:50 +0200, Guillem Jover wrote:
> I don't think dpkg is at fault here, I assume something else is either
> getting activated in the middle of the transaction while the package
> manager frontend driving dpkg has released the lock (which it should
> not), or the package manager frontend driving dpkg is performing the
> locking dance incorrectly.

Isn't dpkg able to install/uninstall a set of packages in an atomic
way (where dpkg itself would set a lock at the beginning and release
the lock once every install/uninstall has been done, so that a lock
failure would not be possible in the middle of the installation)?

> > > with fdisk.
> > 
> > I see no evidence of that in the log.
> 
> Right, it seems to me, like when dpkg fails due to the already held
> lock, then the frontend is not recomputing the transaction and keeps
> as if nothing had gone incorrectly, until it then notices later on.

Alternatively, if this is too complicated, it could abort and let
the user fix things (which is currently needed anyway).

> In any case, given that dpkg is not being very helpful in diagnosing
> this, I'll implement support to print the process name in addition to
> the pid, as this has also hit me, and it's never clear what was the
> actual culprit. So that's why I'm leaving this assigned to dpkg, but
> with a lower severity. If you'd like to file this elsewhere, then
> please clone and reassign that.

It seems that the "dpkg frontend lock is locked by another process"
error almost always occurs with the same packages: either util-linux
or apt. See bugs

* 95

Unpacking util-linux (2.34-0.1) over (2.33.1-0.1) ...
dpkg: error: dpkg frontend lock is locked by another process

Setting up apt (2.6.1) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 4191235

* 940961

Unpacking apt (1.8.4) over (1.8.3) ...
dpkg: error: dpkg frontend lock is locked by another process

* 1069183

Setting up util-linux-extra (2.38.1-5+deb12u1) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 1064194

* 1070027 (this bug)

Setting up util-linux (2.40-8) ...
fstrim.service is a disabled or a static unit not running, not starting it.
dpkg: error: dpkg frontend lock was locked by another process with pid 58569

I'm wondering whether there could be a reason...

But there's also bug 1062190:

Unpacking locales (2.36-9+deb12u4) over (2.36-9+deb12u3) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 567573

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

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Elliott Mitchell]

Package: libgnutls30
Version: 3.7.9-2+deb12u2
Severity: important

Long story to finding this one.  Trying to get LDAP setup on this
network.  As a recent deployment it seemed appropriate to use IPv6.

>From `nslcd` on clients I was getting the message:
nslcd[12345]: [1a2b3c]  failed to bind to LDAP server 
ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: The TLS 
connection was non-properly terminated.: Resource temporarily unavailable

Running `nslcd` in debug mode failed to yield any additional useful
information.

Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// ldapi:///'
is two arguments, the ldaps and ldapi are a single argument).  I got
traces from `slapd`: (serial numbers filed off)

tls_read: want=5, got=5
  :  16 03 01 01 8f

tls_read: want=399, got=399
  0160:fd12  
  0170::3456:7890:abcd:  
  0180::3.-.@.   
TLS: can't accept: A disallowed SNI server name has been received..
connection_read(13): TLS accept failure error=-1 id=1005, closing

Further tracing of the error message appears to point to the function
`_gnutls_dnsname_is_valid()` in gnutls/lib/str.h.  Seems libgnutls30 is
incompatible with numeric IPv6 addresses.

While IPv6-only hosts are presently uncommon, there is now quite a bit of
IPv6 traffic in many places.  I think this is worthy of having a severity
of "critical" as "bookworm" may remain as "stable" past when there is
more IPv6 traffic than IPv4 traffic.  For "trixie" this seems very
likely.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1069450: socket_wrapper and the time_t 64-bit is hard

[Andrew Bartlett]

Just a warning that trying to brute force a fix for this is likely to
end badly.  A lot of developer time was spent to get to this current
delicate situation, which relied on the narrow behaviour that is now
eliminated by the Debian time_t 64 transition rules. 

Socket-wrapper starts with:

/*
 * Make sure we do not redirect (f)open(at)() or fcntl() to their 64bit
 * variants
 */
#undef _FILE_OFFSET_BITS

This was added in 
https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa

Setting  -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so
break Samba's tests. 

I don't know if there is a good fix for this actually.  

Andrew Bartlett

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Guillem Jover]

Control: severity -1 normal

Hi!

On Mon, 2024-04-29 at 00:01:02 +0200, Chris Hofstaedtler wrote:
> Control: reassign -1 dpkg
> 
> * Vincent Lefevre  [240428 22:33]:
> > Package: fdisk
> > Version: 2.40-8
> > Severity: serious
> ...
> > Setting up util-linux (2.40-8) ...
> > fstrim.service is a disabled or a static unit not running, not starting it.
> > dpkg: error: dpkg frontend lock was locked by another process with pid 58569
> > Note: removing the lock file is always wrong, can damage the locked area
> > and the entire system. See .
> > ==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) 
> > ==
> > 
> > -  Show old opportunities as well as new ones: how-can-i-help --old  
> > -
> > E: Sub-process /usr/bin/dpkg returned an error code (2)
> > Setting up bsdextrautils (2.40-8) ...
> > dpkg: dependency problems prevent configuration of fdisk:
> >  fdisk depends on libfdisk1 (= 2.40-8); however:
> >   Version of libfdisk1:amd64 on system is 2.40-6.
> > 
> > dpkg: error processing package fdisk (--configure):
> >  dependency problems - leaving unconfigured
> > Setting up eject (2.40-8) ...
> > Setting up perl-modules-5.38 (5.38.2-4) ...
> > Setting up mount (2.40-8) ...
> > Setting up libperl5.38t64:amd64 (5.38.2-4) ...
> > Setting up util-linux-extra (2.40-8) ...
> > Setting up perl (5.38.2-4) ...
> > Processing triggers for libc-bin (2.37-19) ...
> > Processing triggers for man-db (2.12.1-1) ...
> > Processing triggers for mailcap (3.70+nmu1) ...
> > Errors were encountered while processing:
> >  fdisk
> > 
> > There seem to be 2 issues: one with the dpkg lock (which may be
> > bug 1069183 in aptitude) and one

> Possible.

I don't think dpkg is at fault here, I assume something else is either
getting activated in the middle of the transaction while the package
manager frontend driving dpkg has released the lock (which it should
not), or the package manager frontend driving dpkg is performing the
locking dance incorrectly.

> > with fdisk.
> 
> I see no evidence of that in the log.

Right, it seems to me, like when dpkg fails due to the already held
lock, then the frontend is not recomputing the transaction and keeps
as if nothing had gone incorrectly, until it then notices later on.


In any case, given that dpkg is not being very helpful in diagnosing
this, I'll implement support to print the process name in addition to
the pid, as this has also hit me, and it's never clear what was the
actual culprit. So that's why I'm leaving this assigned to dpkg, but
with a lower severity. If you'd like to file this elsewhere, then
please clone and reassign that.

Thanks,
Guillem

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Vincent Lefevre]

Hi,

On 2024-04-28 19:21:18 -0300, Facundo Gaich wrote:
> Today I upgraded one of my unstable machines and saw several instances of
> something I believe is the same bug. The resolver seems to be failing to
> choose to upgrade certain dependencies. What's more, in the aptitude GUI
> I can see the rightmost "latest available version" column change on the fly
> when I select certain packages for upgrade.
> 
> For example, I currently have libnm0 and libnm0:i386 installed at 1.46.0-1
> and I can see the latest version is 1.46.0-2. If I go into the GUI and
> choose
> to "Install" libnm0, the latest version column for libnm0:i386 will change
> from 1.46.0-2 to 1.46.0-1. Choosing "Install" on libnm0:i386 will then
> effectively
> do a keep of libnm0 at 1.46.0-1. To fix this, I can either go into
> libnm0:i386 and
> explicitly choose the newest version or I can restart the GUI and then it
> will
> list and choose the latest version correctly when I do Install libnm0:i386.
> 
> aptitude version: 0.8.13-6

This is not the same bug. In my case, the resolver chose to do exactly
what I was asking to. This is also what appears in the aptitude logs.
However, what really happened is something completely different:
libmtp-common was attempted to be removed while no such removal was
shown on the aptitude side (not even in its debug logs). This is not
an issue with the resolver, but what happens somewhere between aptitude
and dpkg.

The "the latest version column for libnm0:i386 will change from
1.46.0-2 to 1.46.0-1" with the TUI corresponds to

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979186

which I had reported 3 years ago and still occurs regularly.

Concerning the buggy dependency resolutions (showing that aptitude
does not favor the most obvious solutions, whether the TUI is used
or not):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064969

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

Bug#949969: transmission-gtk uses 100% of a CPU core

[Francois Gouget]

On Fri, 26 Apr 2024, Alexandre Rossi wrote:
[...]
> Do you see other unsual CPU usage than can be linked with very low
> transfer rates? If not, I guess we can close this.

Getting low transfer rates is not easy.
I downloaded the Ubuntu 24.04 ISO and got ~50MB/s transfer rates and the 
CPU usage changed between 50 and 98%. So CPU usage seems to be lower 
with lower transfer rates.

Once transfers slow down transmission does not take much CPU.
CPU usage seems to bottom out at about 5% for slow uploads (2-4 MB/s).
So I guess this can be closed.


-- 
Francois Gouget   http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene 
Wigner

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Vincent Lefevre]

Here's the /var/log/apt/history.log part that corresponds to this
upgrade:

Start-Date: 2024-04-28  22:05:30
Upgrade: libsmartcols1:amd64 (2.40-6, 2.40-8), libvpx8:amd64 (1.13.1-2, 
1.13.1-2+b1), libltdl7:amd64 (2.4.7-7, 2.4.7-7+b1), libpaper1:amd64 (1.1.29, 
1.1.29+b1), libnftnl11:amd64 (1.2.6-2, 1.2.6-2+b1), asymptote:amd64 
(2.87+ds-1+b1, 2.89+ds-1), va-driver-all:amd64 (2.20.0-2, 2.20.0-2+b1), 
libdevel-size-perl:amd64 (0.83-2+b3, 0.84-1), libxrender1:amd64 (1:0.9.10-1.1, 
1:0.9.10-1.1+b1), util-linux-locales:amd64 (2.40-6, 2.40-8), libglvnd0:amd64 
(1.7.0-1, 1.7.0-1+b1), perl:amd64 (5.38.2-3.2+b2, 5.38.2-4), libx11-xcb1:amd64 
(2:1.8.7-1, 2:1.8.7-1+b1), libxshmfence1:amd64 (1.3-1, 1.3-1+b1), 
libxml2-dev:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), 
libmatch-simple-xs-perl:amd64 (0.001-4, 0.002-1), libunwind8:amd64 (1.6.2-3, 
1.6.2-3+b1), libldap-common:amd64 (2.5.16+dfsg-2, 2.5.17+dfsg-1), 
libxml2-utils:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), libxkbfile1:amd64 
(1:1.1.0-1, 1:1.1.0-1+b1), libfile-mimeinfo-perl:amd64 (0.34-1, 0.35-1), 
xsltproc:amd64 (1.1.35-1, 1.1.35-1+b1), libpciaccess0:amd64 (0.17-3, 
0.17-3+b1), libxcursor1:amd64 (1:1.2.1-1, 1:1.2.1-1+b1), codespell:amd64 
(2.2.6-1, 2.2.6-2), libmime-tools-perl:amd64 (5.514-1, 5.515-1), libglx0:amd64 
(1.7.0-1, 1.7.0-1+b1), vim-common:amd64 (2:9.1.0199-1, 2:9.1.0377-1), 
libsigsegv2:amd64 (2.14-1, 2.14-1+b1), libmaa4:amd64 (1.4.7-1, 1.4.7-1+b1), 
libva-x11-2:amd64 (2.20.0-2, 2.20.0-2+b1), libgsm1:amd64 (1.0.22-1, 
1.0.22-1+b1), libmount1:amd64 (2.40-6, 2.40-8), libxau6:amd64 (1:1.0.9-1, 
1:1.0.9-1+b1), libxcomposite1:amd64 (1:0.4.5-1, 1:0.4.5-1+b1), 
libxs-parse-keyword-perl:amd64 (0.39-1+b2, 0.41-1), libatasmart4:amd64 (0.19-5, 
0.19-5+b1), libdevel-callchecker-perl:amd64 (0.008-2+b2, 0.009-1), 
libxdamage1:amd64 (1:1.1.6-1, 1:1.1.6-1+b1), libsepol2:amd64 (3.5-2, 3.5-2+b1), 
libmnl0:amd64 (1.0.5-2, 1.0.5-2+b1), libxml2:amd64 (2.9.14+dfsg-1.3+b2, 
2.9.14+dfsg-1.3+b3), util-linux:amd64 (2.40-6, 2.40-8), libvdpau1:amd64 (1.5-2, 
1.5-2+b1), util-linux-extra:amd64 (2.40-6, 2.40-8), libldap-2.5-0:amd64 
(2.5.16+dfsg-2, 2.5.17+dfsg-1), libgav1-1:amd64 (0.19.0-2, 0.19.0-2+b1), 
libgpg-error0:amd64 (1.47-3, 1.47-3+b1), libxss1:amd64 (1:1.2.3-1, 
1:1.2.3-1+b1), libxcvt0:amd64 (0.1.2-1, 0.1.2-1+b1), libassuan-dev:amd64 
(2.5.6-1, 2.5.6-1+b1), libcompress-raw-lzma-perl:amd64 (2.211-1, 2.212-1), 
libcdr-0.1-1:amd64 (0.1.7-1, 0.1.7-1+b1), fdisk:amd64 (2.40-6, 2.40-8), 
libgles2:amd64 (1.7.0-1, 1.7.0-1+b1), libyaml-0-2:amd64 (0.2.5-1, 0.2.5-1+b1), 
libxxf86dga1:amd64 (2:1.1.5-1, 2:1.1.5-1+b1), libxfont2:amd64 (1:2.0.6-1, 
1:2.0.6-1+b1), libfdisk1:amd64 (2.40-6, 2.40-8), libassuan0:amd64 (2.5.6-1, 
2.5.6-1+b1), libsoxr0:amd64 (0.1.3-4, 0.1.3-4+b1), eject:amd64 (2.40-6, 
2.40-8), libltdl-dev:amd64 (2.4.7-7, 2.4.7-7+b1), libxkbcommon0:amd64 (1.6.0-1, 
1.6.0-1+b1), libxtst6:amd64 (2:1.2.3-1.1, 2:1.2.3-1.1+b1), 
vdpau-driver-all:amd64 (1.5-2, 1.5-2+b1), libnet-dns-sec-perl:amd64 (1.23-1+b2, 
1.24-1), libuuid1:amd64 (2.40-6, 2.40-8), libvisual-0.4-0:amd64 (0.4.2-2, 
0.4.2-2+b1), libjpeg62-turbo:amd64 (1:2.1.5-2+b2, 1:2.1.5-3), libgcrypt20:amd64 
(1.10.3-2, 1.10.3-2+b1), python3-numpy:amd64 (1:1.26.4+ds-6, 1:1.26.4+ds-8), 
perl-doc:amd64 (5.38.2-3.2, 5.38.2-4), vim-tiny:amd64 (2:9.1.0199-1, 
2:9.1.0377-1), xcvt:amd64 (0.1.2-1, 0.1.2-1+b1), libice6:amd64 (2:1.0.10-1, 
2:1.0.10-1+b1), liburing2:amd64 (2.5-1, 2.5-1+b1), libid3tag0:amd64 
(0.15.1b-14, 0.15.1b-14+b1), asymptote-doc:amd64 (2.87+ds-1, 2.89+ds-1), 
libopengl0:amd64 (1.7.0-1, 1.7.0-1+b1), libxslt1.1:amd64 (1.1.35-1, 
1.1.35-1+b1), libglu1-mesa:amd64 (9.0.2-1.1, 9.0.2-1.1+b1), 
librevenge-0.0-0:amd64 (0.0.5-3, 0.0.5-3+b1), libogg0:amd64 (1.3.5-3, 
1.3.5-3+b1), libxinerama1:amd64 (2:1.1.4-3, 2:1.1.4-3+b1), mount:amd64 (2.40-6, 
2.40-8), perl-base:amd64 (5.38.2-3.2+b2, 5.38.2-4), libpaper-utils:amd64 
(1.1.29, 1.1.29+b1), libjaylink0:amd64 (0.3.1-1, 0.3.1-1+b1), ed:amd64 
(1.20.1-1.1, 1.20.2-2), libblkid1:amd64 (2.40-6, 2.40-8), libxvmc1:amd64 
(2:1.0.12-2, 2:1.0.12-2+b1), libva-drm2:amd64 (2.20.0-2, 2.20.0-2+b1), 
perl-modules-5.38:amd64 (5.38.2-3.2, 5.38.2-4), libgl1:amd64 (1.7.0-1, 
1.7.0-1+b1), libegl1:amd64 (1.7.0-1, 1.7.0-1+b1), libx11-6:amd64 (2:1.8.7-1, 
2:1.8.7-1+b1), libperl5.38t64:amd64 (5.38.2-3.2+b2, 5.38.2-4), 
libxkbcommon-x11-0:amd64 (1.6.0-1, 1.6.0-1+b1), liblz1:amd64 (1.14-1, 
1.15~pre1-1), libemf1:amd64 (1.0.13-7, 1.0.13-7+b1), libwpg-0.3-3:amd64 
(0.3.4-3, 0.3.4-3+b1), libgpg-error-dev:amd64 (1.47-3, 1.47-3+b1), 
libedit2:amd64 (3.1-20230828-1, 3.1-20230828-1+b1), bsdutils:amd64 (1:2.40-6, 
1:2.40-8), libsm6:amd64 (2:1.2.3-1, 2:1.2.3-1+b1), libva2:amd64 (2.20.0-2, 
2.20.0-2+b1), bsdextrautils:amd64 (2.40-6, 2.40-8), libxfixes3:amd64 
(1:6.0.0-2, 1:6.0.0-2+b1), libxdmcp6:amd64 (1:1.1.2-3, 1:1.1.2-3+b1), 
libxv1:amd64 (2:1.0.11-1.1, 2:1.0.11-1.1+b1), libutempter0:amd64 (1.2.1-3, 
1.2.1-3+b1), libspectre1:amd64 (0.2.12-1, 0.2.12-1+b1), libevdev2:amd64 
(1.13.1+dfsg-1, 

Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels

[Samuel Thibault]

Joseph Carter, le dim. 28 avril 2024 16:21:06 -0700, a ecrit:
> Even so, could you try to include a DejaVuSansMonoBold font as well?

It's also included in my change.

Samuel

Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels

[Joseph Carter]

My apologies for missing the existing bug scrolling through the list. There 
were a lot of them to sift through. I may see if some of them have been 
incidentally fixed as far as I can tell.

I understand the eventual goal for the kernel folks is to rid themselves of 
CONFIG_VT all together, so I realize this is a stopgap. Even so, could you try 
to include a DejaVuSansMonoBold font as well? I'd appreciate it if it's 
possible as I can personally read a smaller heavyweight font and it'd really 
help debugging servers with my portable display.

Obviously the long-term solution is some userspace alternative that does the 
same thing probably using cage and some restricted tabbed terminal maybe? Hmm. 
I dunno if that's even on anybody's radar any sooner than forky.

Joseph

On Fri, Apr 26, 2024, at 10:11, Samuel Thibault wrote:
> Control: forcemerge -1 816111
>
> Hello,
>
> T. Joseph Carter, le mer. 24 avril 2024 13:25:22 -0700, a ecrit:
>> Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This
>> is probably aimed at "more than 4k" monitors, but for accessibility
>> reasons it would be really useful to have larger sizes available sooner
>> for those of us already have 4k sorts of screens.
>
> Yes, that was the points in adding the support in the kernel :)
>
>> Perhaps this might best be done by putting those huge-sized fonts in an
>> appropriately named -huge fonts package? I'll leave the implementation
>> details to you, this is just a request for the fonts to be created.
>
> We already had the request in #816111, also #595696 was about possibly
> generalizing to using rasterized fonts.
>
> I gave a try at converting terminus.ttf to bdf with otf2bdf:
>
> otf2bdf -c C -p 32 -r 72 
> /usr/share/fonts/truetype/terminus/TerminusTTF-4.46.0.ttf > 
> /tmp/terminus.bdf
> bdf2psf --fb  /tmp/terminus.bdf /usr/share/bdf2psf/standard.equivalents 
> ascii.set 256   /tmp/terminus.psf /tmp/terminus.sfm
>
> but the baseline is not coherent. Using DejaVuSansMono seems to be
> working better:
>
> otf2bdf -c C -p 32 -r 100 
> /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf > 
> /tmp/DejaVuSansMono.bdf
> bdf2psf --fb --width 32 /tmp/DejaVuSansMono.bdf 
> /usr/share/bdf2psf/standard.equivalents ascii.set 256 
> /tmp/DejaVuSansMono.psf /tmp/DejaVuSansMono.sfm
>
> (I'm adding a new --width parameter to bdf2psf to specify the expected
> width since AVERAGE_WIDTH as set by otf2bdf doesn't really tell)
>
> Samuel

Bug#1070032: elogind: add NEWS for 255.4.1, suspend now default to s2idle instead of s2ram

[Lorenzo Puliti]

Package: elogind
Version: 255.4.1-1debian2
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Hi,

Elogind 255 changed the implicit default for suspend;
it was 'deep' until 252, now it's 's2idle'.
This is documented nowhere, except if one reads Yamakuzure
reply in https://github.com/elogind/elogind/issues/280
and it took me a while [1] to understand that the state where
the screen goes black but power led is still on and fans
keep spinning is not a bug in elogind.

I think this change is worth a NEWS entry, with an example
that explains how to revert to the previous default.
I suggest something like

  This version of elogind changes the default Mode for suspend,
  before elogind 255 it was suspend2ram, now it's suspend2idle.
  To revert to the previous default you can add a line with
  SuspendMode=deep
  in elogind's sleep.conf; for example
  cat /etc/elogind/sleep.conf.d/20-suspend.conf 
  
  [Sleep]
  SuspendMode=deep

Best,
Lorenzo

[1] https://docs.kernel.org/admin-guide/pm/sleep-states.html


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages elogind depends on:
ii  dbus 1.14.10-4+b1
ii  debconf  1.5.86
ii  init-system-helpers  1.66
ii  libacl1  2.3.2-1
ii  libc62.37-18
ii  libcap2  1:2.66-5
ii  libmount12.40-6
ii  libpam0g 1.5.3-7
ii  libselinux1  3.5-2+b2
ii  libsystemd0  255.5-1
ii  libudev1 255.5-1

Versions of packages elogind recommends:
ii  libpam-elogind  255.4.1-1debian2
ii  polkitd 124-2

elogind suggests no packages.

-- no debconf information

Bug#1070031: heimdal-kdc: fails to install if /usr/bin/kadmin is not Heimdal kadmin

[Ryan Tandy]

Package: heimdal-kdc
Version: 7.8.git20221117.28daf24+dfsg-5
Severity: normal

Dear Maintainer,

I noticed that if the package krb5-user is installed, then heimdal-kdc 
fails to install, because /usr/bin/kadmin is the wrong one:

# apt install krb5-user
[...]
# ls -l /etc/alternatives/kadmin
lrwxrwxrwx 1 root root 19 Mar 27 03:42 /etc/alternatives/kadmin -> 
/usr/bin/kadmin.mit
# apt install heimdal-kdc
[...]
Setting up heimdal-kdc (7.8.git20221117.28daf24+dfsg-5+b1) ...
kstash: writing key to `/var/lib/heimdal-kdc/m-key'
kadmin: invalid option -- 'l'
Usage: kadmin [-r realm] [-p principal] [-q query] [clnt|local args]
  [command args...]
clnt args: [-s admin_server[:port]] [[-c ccache]|[-k [-t keytab]]]|[-n] 
[-O | -N]
local args: [-x db_args]* [-d dbname] [-e "enc:salt ..."] [-m] [-w 
password] where,
[-x db_args]* - any number of database specific arguments.
Look at each database documentation for supported 
arguments
dpkg: error processing package heimdal-kdc (--configure):
 installed heimdal-kdc package post-installation script subprocess returned 
error exit status 1

The MIT alternative has a slightly higher priority (30 vs 
heimdal-clients 23), so update-alternatives prefers it.

# update-alternatives --display kadmin
kadmin - auto mode
  link best version is /usr/bin/kadmin.mit
  link currently points to /usr/bin/kadmin.mit
  link kadmin is /usr/bin/kadmin
  slave kadmin.1.gz is /usr/share/man/man1/kadmin.1.gz
/usr/bin/kadmin.heimdal - priority 23
  slave kadmin.1.gz: /usr/share/man/man1/kadmin.heimdal.1.gz
/usr/bin/kadmin.mit - priority 30
  slave kadmin.1.gz: /usr/share/man/man1/kadmin.mit.1.gz

I guess the Heimdal maintainer scripts should call kadmin.heimdal 
explicitly. I have not checked whether any other commands are affected.

thank you,
Ryan

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Guilherme Puida Moreira]

Hi Miguel,

On Sun, Apr 28, 2024 at 10:54:54PM +0100, Miguel Landaeta wrote:
> Can you also reach out to upstream and send your man page contribution
> there, so you can gather feedback and other users can benefit if they
> decide to merge it?

Will do. Thanks for the ping!

By the way, you mentioned that you had a preliminary hare package on
#1058645. If you need any help, just let me know.

Thanks,

--puida

Bug#1070030: RM: erfs -- ROM; no longer functional

[Daniel Echeverri]

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

Hello

The erfs service was shut down and this tool is no longer functional. It
should be removed.

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Facundo Gaich]

Hi,

Today I upgraded one of my unstable machines and saw several instances of
something I believe is the same bug. The resolver seems to be failing to
choose to upgrade certain dependencies. What's more, in the aptitude GUI
I can see the rightmost "latest available version" column change on the fly
when I select certain packages for upgrade.

For example, I currently have libnm0 and libnm0:i386 installed at 1.46.0-1
and I can see the latest version is 1.46.0-2. If I go into the GUI and
choose
to "Install" libnm0, the latest version column for libnm0:i386 will change
from 1.46.0-2 to 1.46.0-1. Choosing "Install" on libnm0:i386 will then
effectively
do a keep of libnm0 at 1.46.0-1. To fix this, I can either go into
libnm0:i386 and
explicitly choose the newest version or I can restart the GUI and then it
will
list and choose the latest version correctly when I do Install libnm0:i386.

aptitude version: 0.8.13-6

Best,
Facundo

Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

On 28/04/24 22:50, Chet Ramey wrote:

On 4/28/24 3:07 PM, Gioele Barabucci wrote:

 $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

 /bin/bash
 /usr/bin/bash-static
 -bash-static


So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').

Then when you get to setting $BASH, this code gets executed:

   if ((login_shell == 1) && RELPATH(shell_name))
     {
   if (current_user.shell == 0)
     get_current_user_info ();
   name = savestring (current_user.shell);
     }

which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?


The bash manual defines $BASH as follows:


Expands to the full filename used to invoke this instance of bash.

So, either the code or the manual should be changed.

I see why changing such an old behavior for the sake of correctness may 
not be worth the risk of breaking somebody's workflow. But at the same 
time it is hard to believe that anybody may be relying on "$BASH 
contains the user shell set up in /etc/passwd when read from a login shell".


In my case, I intended to use $BASH to make sure that the right binary 
was picked up by a certain test. I assume I'm not the only one using it 
in that way.


Regards,

--
Gioele Barabucci

Bug#1069952: Resolved

[Shmerl]

Actually I was able to resolve it after the recent updates, so it looks all
good now.

Regards,
Shmerl.

Bug#1065241: O: pylint -- Python 3 code static checker and UML diagram generator

[Alexandre Detiste]

Hi,

I've seen your ITA of course, consider this as only an intermediate
upload to untangle astroid;
but it's not yet done

The autopkgtest is failing
   https://tracker.debian.org/pkg/pylint
   https://tracker.debian.org/pkg/astroid

I only discovered pylint recently and would like to try  the automatic
graph system tomorrow at work

Before that is was merely a faint nuisance on my radar;
https://salsa.debian.org/detiste-guest/python-debian/-/commits/master
and random package from morph's list

Le dim. 28 avr. 2024 à 23:56, Daniel Echeverri  a écrit :
> Hello
>
> I have seen that you recently uploaded the new version of pylint and added 
> yourself as an uploader.
> I had become the owner of this bug because I was working on the package,
> and I was waiting to solve the tests that had been failing, (I see that you 
> solved it by removing the tests that are failing).

> (I  am not sure if it's the best way)
I think that not neither, help is still welcome

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Chris Hofstaedtler]

Control: reassign -1 dpkg

* Vincent Lefevre  [240428 22:33]:
> Package: fdisk
> Version: 2.40-8
> Severity: serious
...
> Setting up util-linux (2.40-8) ...
> fstrim.service is a disabled or a static unit not running, not starting it.
> dpkg: error: dpkg frontend lock was locked by another process with pid 58569
> Note: removing the lock file is always wrong, can damage the locked area
> and the entire system. See .
> ==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) 
> ==
> 
> -  Show old opportunities as well as new ones: how-can-i-help --old  -
> E: Sub-process /usr/bin/dpkg returned an error code (2)
> Setting up bsdextrautils (2.40-8) ...
> dpkg: dependency problems prevent configuration of fdisk:
>  fdisk depends on libfdisk1 (= 2.40-8); however:
>   Version of libfdisk1:amd64 on system is 2.40-6.
> 
> dpkg: error processing package fdisk (--configure):
>  dependency problems - leaving unconfigured
> Setting up eject (2.40-8) ...
> Setting up perl-modules-5.38 (5.38.2-4) ...
> Setting up mount (2.40-8) ...
> Setting up libperl5.38t64:amd64 (5.38.2-4) ...
> Setting up util-linux-extra (2.40-8) ...
> Setting up perl (5.38.2-4) ...
> Processing triggers for libc-bin (2.37-19) ...
> Processing triggers for man-db (2.12.1-1) ...
> Processing triggers for mailcap (3.70+nmu1) ...
> Errors were encountered while processing:
>  fdisk
> 
> There seem to be 2 issues: one with the dpkg lock (which may be
> bug 1069183 in aptitude) and one
Possible.

> with fdisk.

I see no evidence of that in the log.

C

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

Hi folks,

I apologize I took me this long to work on qbe upload.

Guilherme, thanks for contributing a man page for qbe. I just included
it in the package.
Can you also reach out to upstream and send your man page contribution
there, so you can gather feedback and other users can benefit if they
decide to merge it?

Amin, I took some bias for action and I just uploaded the latest
changes in debian/latest to the archive. However, my upload just got
rejected because I forgot to include the source changes and did only a
binary upload. I don't have time today to fix that and retry so I'll
do that tomorrow unless you do it first (if you want or if you have
more changes pending that you want to include in the first upload).

I'll paste a link to this package NEW queue entry later so other users
can have visibility on the progress.

Thanks for your contributions!
Cheers,

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1065241: O: pylint -- Python 3 code static checker and UML diagram generator

[Daniel Echeverri]

retitle 1065241 RFA: pylint -- Python 3 code static checker and UML diagram
generator
noowner 1065241 !
thanks

Hello

I have seen that you recently uploaded the new version of pylint and added
yourself as an uploader. I had become the owner of this bug because I was
working on the package, and I was waiting to solve the tests that had been
failing, (I see that you solved it by removing the tests that are failing).
(I  am not sure if it's the best way) Anyway, you can be de maintainer,
just go ahead

Regards


-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#409444: logcheck: ignore "last line repeated $n times" if prevline matched

[Richard Lewis]

On Sat, 03 Feb 2007 10:29:38 +0100 Jonas Koelker  wrote:

> I (think I) want to see how many times the messages I care about are
> repeated.  This means I can't ignore "last line repeated $n times"
> messages (obviously).  But since those can also occur after messages
> that are ignored, I can't _not_ ignore them either.  So, I lose.
>

rsyslog has disabled the "feature" which produces this message, see
https://www.rsyslog.com/doc/configuration/action/rsconf1_repeatedmsgreduction.html

so this bug from 2007 can, i think, be closed.

Bug#1069101: libdbd-oracle-perl: requires rebuild for time_t transition

[Sebastian Ramacher]

Hi Alex

On 2024-04-28 22:36:01 +0200, Alex Muntada wrote:
> > libdbd-oracle-perl depends on libaio1
> 
> It turns out that it's oracle-instantclient-basic that needs
> libaio.so.1. I'm not sure what could be done to address this
> issue, since the soname renaming to libaio.so.1t64 is Debian
> specific.

Unfortunately libaio did not follow the pattern that was used for
everything else. Depending on how much you care about the future of
libdbd-oracle-perl in Debian, the issue is best discussed with the
libaio maintainer.

> If libdbd-oracle-perl needs to be removed from testing for the
> transition to proceed, so be it. In fact, there's no need to
> wait until May 15; feel free to remove it sooner.

Hint added.

Cheers
-- 
Sebastian Ramacher

Bug#1067034: RE: dhcpcd-gtk: fails to see wireless networks and to let me enter passphrases

[Francesco Poli]

On Fri, 22 Mar 2024 19:02:46 -0300 Leandro Cunha  
wrote:
> Hi,

Hello,
please Cc me on replies, I am not subscribed to the bug reports I
file... Thanks.

[...]
> This package, when tested, worked normally with WiFi networks without
> needing to do any configuration, just install and use.

What do you mean?
Do you mean that you just install dhcpcd-gtk, start it and see the list
of WiFi networks, choose one, enter the passphrase and connect to it?

Without even having to set update_config=1 in wpa_supplicant.conf, as
stated in the dhcpcd-gtk(8) man page???

> As you ask for
> help to use it, I will insert the newcomer tag, understanding that you
> have just arrived and want to report a problem you have encountered.

That is to say? Do you mean that this bug has a known solution that
some new Debian contributor could easily implement?
Which known solution do you have in mind?

> I will investigate what is happening with the package and check for any
> problems in the future.
> 
> Please keep any new information up to date on this bug and thanks!

So you are willing to investigate: good, thanks a lot for this.
Please try to reproduce the bug and tell me whether you need me to
perform some other test.

Looking forward to hearing back from you.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpxDwakspPHn.pgp
Description: PGP signature

Bug#1069978: bash: incorrect value of $BASH for login shells

[Chet Ramey]

On 4/27/24 6:23 PM, Gioele Barabucci wrote:

Package: bash
Version: 5.2.21-2
X-Debbugs-CC: bug-b...@gnu.org

Hi,

bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as 
the login shell:


     $ apt install bash-static
     $ getent passwd $USER | cut -d: -f 7
     /bin/bash

     $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; 
true'

     /usr/bin/bash-static
     /usr/bin/bash-static

     $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

     /bin/bash
     /usr/bin/bash-static

(bash-static is not a link to bash)


What does `su' pass to bash in argv[0]?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070007: sbuild/unshare: writing to /dev/stdout denied

[Johannes Schauer Marin Rodrigues]

Quoting Aurelien Jarno (2024-04-28 15:57:29)
> When running sbuild in unshare chroot mode, it is not possible to write to
> /dev/stdout:
> 
> | echo test > /dev/stdout
> | sh: 1: cannot create /dev/stdout: Permission denied
> 
> This is the reason of the FTBFS of at least clisp and supervisor when using
> the unshare chroot mode of sbuild.

This works in podman. So somehow it's possible to connect /dev/stdout in a way
which preserves its intended functionality. Probably it would be useful to find
out how podman does this. For what its worth, mmdebstrap itself suffers from
the same problem, so whatever fix is used in sbuild should probably also be
added to mmdebstrap.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1069978: bash: incorrect value of $BASH for login shells

[Chet Ramey]

On 4/28/24 3:07 PM, Gioele Barabucci wrote:

     $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

     /bin/bash
     /usr/bin/bash-static
     -bash-static


So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').

Then when you get to setting $BASH, this code gets executed:

  if ((login_shell == 1) && RELPATH(shell_name))
{
  if (current_user.shell == 0)
get_current_user_info ();
  name = savestring (current_user.shell);
}

which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062205: Crashes desktop when attempting to make a network display

[Bernhard Übelacker]

On Fri, 2 Feb 2024 00:58:31 -0800 Josh Triplett  wrote:


Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 
05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 
47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f



Hello,
I am not involved in maintaining this package, just looking through some crash 
reports.

My attempt to resolve the dmesg lines from the crash to a source line 
information led me here:

  clutter_paint_context_get_redraw_clip at 
../clutter/clutter/clutter-paint-context.c:140

  
https://sources.debian.org/src/mutter/44.8-3.1/clutter/clutter/clutter-paint-context.c/#L140
  137 const cairo_region_t *
  138 clutter_paint_context_get_redraw_clip (ClutterPaintContext 
*paint_context)
  139 {
  140   return paint_context->redraw_clip;
  141 }

This function name leads to following bug report, which sounds interesting:
  https://gitlab.gnome.org/GNOME/mutter/-/issues/2876

And which got fixed by this merge request:
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3283

First upstream release containing this fix would be 45.1,
unfortunately not yet in unstable or testing.


But a proper backtrace might still help to confirm, if this crash is
really the same which is described in the mentioned mutter bug report.
  https://wiki.debian.org/HowToGetABacktrace
Simplest version could be to install systemd-coredump
and inspecting the journal after a crash.

Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062205
https://wiki.debian.org/HowToGetABacktrace
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 
d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa 
<48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f


error 4 == 0b0100:
 *   bit 0 ==0: no page found
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access
.





# 2024-04-28 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt build-dep libmutter-12-0

apt install systemd-coredump gdb libmutter-12-0 libmutter-12-0-dbgsym 
coreutils-dbgsym



mkdir /home/benutzer/source/libmutter-12-0/orig -p
cd/home/benutzer/source/libmutter-12-0/orig
apt source libmutter-12-0



echo -n "find /b ..., ..., 0x" && \
echo "c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 05 00 48 8d 3d 4e 
f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 20 c3 0f 1f 80 
00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q 
set width 0
set pagination off
file /usr/bin/true
tb main
run
call 
dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102)
pipe info target | grep "\.text.*libmutter-clutter"
find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 0x00, 
0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 0x7e, 
0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2, 0xfa, 
0xff, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 0xfa, 0x48, 0x8b, 
0x47, 0x20, 0xc3, 0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 
0xfa, 0x48, 0x8b, 0x47, 0x28, 0xc3, 0x0f
b * (0x77d3eeda + 42)
info b
disassemble /r 0x77d3eeda, 0x77d3eeda + 62
directory /home/benutzer/source/libmutter-12-0/orig/mutter-44.8/clutter



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/true
Reading symbols from /usr/bin/true...
Reading symbols from 
/usr/lib/debug/.build-id/04/6669aefa60ba9f99cc1c829bf6aac6e0d05d4c.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x2310: file src/true.c, line 56.
(gdb) run
Starting program: /usr/bin/true 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe488) at src/true.c:56
56  src/true.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call 
dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102)
$1 = (void *) 0xe340
(gdb) pipe info target | grep "\.text.*libmutter-clutter"
0x77cf0f30 - 0x77d7a6de is .text in 
/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0
(gdb) find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 
0x00, 0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 
0x7e, 0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2, 

Bug#334773: kguitar crashes after startup if compiled with libtse3

[Petter Reinholdtsen]

[Tommaso Moroni 2005-10-19]
> While ackaging kguitar I found that, if I compile it 
> with libtse3 support, kguitar crashes after startup, while
> the same package compiled without libtse3 works normally.

Thank you for the bug geport.

> If there's anything I can do to help you, just ask!

Perhaps you can try to run it using valgrind, to see where and why it
crashes?  The crash seem to be heap related.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1067821: bookworm-pu: package nvidia-graphics-drivers/535.161.08-2~deb12u1

[Adam D. Barratt]

On Sun, 2024-04-28 at 13:43 +0200, Andreas Beckmann wrote:
> Please reject nvidia-graphics-drivers/535.161.08-1~deb12u1, nvidia-
> driver-full is uninstallable on ppc64el (but that was hidden by the
> other t64 transition blockers).

Done, thanks for letting us know.

Regards,

Adam

Bug#1069101: libdbd-oracle-perl: requires rebuild for time_t transition

[Alex Muntada]

Control: owner -1 !
Control: tags -1 upstream help

Hi Sebastian,

> libdbd-oracle-perl depends on libaio1

It turns out that it's oracle-instantclient-basic that needs
libaio.so.1. I'm not sure what could be done to address this
issue, since the soname renaming to libaio.so.1t64 is Debian
specific.

If libdbd-oracle-perl needs to be removed from testing for the
transition to proceed, so be it. In fact, there's no need to
wait until May 15; feel free to remove it sooner.

Cheers!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#1021169: libglx-mesa0: Still present in 24.1.0~rc1-1

[Dan Merillat]

Package: libglx-mesa0
Version: 24.1.0~rc1-1
Followup-For: Bug #1021169

Dear Maintainer,

I'm still seeing this invalid path in the binary:

/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri

and when attempting to load libglx_mesa0 I get the following error:

MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: cannot open 
shared object file: No such file or directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)

strace confirms that it is searching in nonsense paths:
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/radeonsi_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/radeonsi_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)


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

Kernel: Linux 6.6.10 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libglx-mesa0 depends on:
ii  libc62.37-18
ii  libdrm2  2.4.120-2
ii  libexpat12.6.2-1
ii  libgl1-mesa-dri  24.1.0~rc1-1
ii  libglapi-mesa24.1.0~rc1-1
ii  libx11-6 2:1.8.7-1+b1
ii  libx11-xcb1  2:1.8.7-1+b1
ii  libxcb-dri2-01.17.0-1
ii  libxcb-dri3-01.17.0-1
ii  libxcb-glx0  1.17.0-1
ii  libxcb-present0  1.17.0-1
ii  libxcb-randr01.17.0-1
ii  libxcb-shm0  1.17.0-1
ii  libxcb-sync1 1.17.0-1
ii  libxcb-xfixes0   1.17.0-1
ii  libxcb1  1.17.0-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2+b1
ii  libxshmfence11.3-1+b1
ii  libxxf86vm1  1:1.1.4-1+b2

libglx-mesa0 recommends no packages.

libglx-mesa0 suggests no packages.

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils7.7+8+b1
ii  xkb-data 2.41-2
ii  xserver-xorg-core2:21.1.12-1
ii  xserver-xorg-input-evdev [xorg-driver-input] 1:2.10.6-2+b3
ii  xserver-xorg-input-kbd [xorg-driver-input]   1:1.9.0-1+b3
ii  xserver-xorg-input-libinput [xorg-driver-input]  1.4.0-1
ii  xserver-xorg-input-mouse [xorg-driver-input] 1:1.9.3-1+b1
ii  xserver-xorg-video-amdgpu [xorg-driver-video]23.0.0-1

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  24.1.0~rc1-1
pn  xserver-xorg-legacy  

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration  1.226
ii  libaudit1   1:3.1.2-2
ii  libc6   2.37-18
ii  libdbus-1-3 1.14.10-4+b1
ii  libdrm2 2.4.120-2
ii  libegl1 1.7.0-1+b1
ii  libepoxy0   1.5.10-1+b2
ii  libgbm1 24.1.0~rc1-1
ii  libgcrypt20 1.10.3-2+b1
ii  libgl1  1.7.0-1+b1
ii  libpciaccess0   0.17-3+b1
ii  libpixman-1-0   0.42.2-1+b1
ii  libselinux1 3.5-2+b2
ii  libsystemd0 255.5-1
ii  libudev1255.5-1
ii  libunwind8  1.6.2-3+b1
ii  libxau6 1:1.0.9-1+b1
ii  libxcvt00.1.2-1+b1
ii  libxdmcp6   1:1.1.2-3+b1
ii  libxfont2   1:2.0.6-1+b1
ii  libxshmfence1   1.3-1+b1
ii  udev255.5-1
ii  xserver-common  2:21.1.12-1

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  24.1.0~rc1-1
ii  libpam-systemd [logind]  255.5-1
ii  xcvt 0.1.2-1+b1

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi1:1.0.5
ii  xfonts-75dpi 1:1.0.5
ii  xfonts-scalable  1:1.0.3-1.3

-- no debconf information

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Vincent Lefevre]

Package: fdisk
Version: 2.40-8
Severity: serious

During an upgrade with aptitude 0.8.13-6, I got:

Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 417244 files and directories currently installed.)
Preparing to unpack .../bsdutils_1%3a2.40-8_amd64.deb ...
Unpacking bsdutils (1:2.40-8) over (1:2.40-6) ...
Setting up bsdutils (1:2.40-8) ...
(Reading database ... 417244 files and directories currently installed.)
Preparing to unpack .../libperl5.38t64_5.38.2-4_amd64.deb ...
Unpacking libperl5.38t64:amd64 (5.38.2-4) over (5.38.2-3.2+b2) ...
Preparing to unpack .../perl_5.38.2-4_amd64.deb ...
Unpacking perl (5.38.2-4) over (5.38.2-3.2+b2) ...
Preparing to unpack .../perl-base_5.38.2-4_amd64.deb ...
Unpacking perl-base (5.38.2-4) over (5.38.2-3.2+b2) ...
Setting up perl-base (5.38.2-4) ...
(Reading database ... 417241 files and directories currently installed.)
Preparing to unpack .../0-perl-modules-5.38_5.38.2-4_all.deb ...
Unpacking perl-modules-5.38 (5.38.2-4) over (5.38.2-3.2) ...
Preparing to unpack .../1-eject_2.40-8_amd64.deb ...
Unpacking eject (2.40-8) over (2.40-6) ...
Preparing to unpack .../2-bsdextrautils_2.40-8_amd64.deb ...
Unpacking bsdextrautils (2.40-8) over (2.40-6) ...
Preparing to unpack .../3-util-linux-extra_2.40-8_amd64.deb ...
Adding 'diversion of /sbin/ctrlaltdel to /sbin/ctrlaltdel.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/fsck.cramfs to /sbin/fsck.cramfs.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/fsck.minix to /sbin/fsck.minix.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/mkfs.bfs to /sbin/mkfs.bfs.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/mkfs.cramfs to /sbin/mkfs.cramfs.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/mkfs.minix to /sbin/mkfs.minix.usr-is-merged by 
util-linux-extra'
Unpacking util-linux-extra (2.40-8) over (2.40-6) ...
Preparing to unpack .../4-fdisk_2.40-8_amd64.deb ...
Unpacking fdisk (2.40-8) over (2.40-6) ...
Preparing to unpack .../5-libsmartcols1_2.40-8_amd64.deb ...
Unpacking libsmartcols1:amd64 (2.40-8) over (2.40-6) ...
Setting up libsmartcols1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../libblkid1_2.40-8_amd64.deb ...
Unpacking libblkid1:amd64 (2.40-8) over (2.40-6) ...
Setting up libblkid1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../libmount1_2.40-8_amd64.deb ...
Unpacking libmount1:amd64 (2.40-8) over (2.40-6) ...
Setting up libmount1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../mount_2.40-8_amd64.deb ...
Unpacking mount (2.40-8) over (2.40-6) ...
Preparing to unpack .../libuuid1_2.40-8_amd64.deb ...
Unpacking libuuid1:amd64 (2.40-8) over (2.40-6) ...
Setting up libuuid1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../util-linux_2.40-8_amd64.deb ...
Unpacking util-linux (2.40-8) over (2.40-6) ...
Setting up util-linux (2.40-8) ...
fstrim.service is a disabled or a static unit not running, not starting it.
dpkg: error: dpkg frontend lock was locked by another process with pid 58569
Note: removing the lock file is always wrong, can damage the locked area
and the entire system. See .
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -
E: Sub-process /usr/bin/dpkg returned an error code (2)
Setting up bsdextrautils (2.40-8) ...
dpkg: dependency problems prevent configuration of fdisk:
 fdisk depends on libfdisk1 (= 2.40-8); however:
  Version of libfdisk1:amd64 on system is 2.40-6.

dpkg: error processing package fdisk (--configure):
 dependency problems - leaving unconfigured
Setting up eject (2.40-8) ...
Setting up perl-modules-5.38 (5.38.2-4) ...
Setting up mount (2.40-8) ...
Setting up libperl5.38t64:amd64 (5.38.2-4) ...
Setting up util-linux-extra (2.40-8) ...
Setting up perl (5.38.2-4) ...
Processing triggers for libc-bin (2.37-19) ...
Processing triggers for man-db (2.12.1-1) ...
Processing triggers for mailcap (3.70+nmu1) ...
Errors were encountered while processing:
 fdisk

There seem to be 2 issues: one with the dpkg lock (which may be
bug 1069183 in aptitude) and one with fdisk.

It is not clear whether they are related. At least, bug 1069183
shouldn't be the cause of a bad ordering between package unpacking
and setup, which would rather be due to a dependency problem, as
indicated by the dpkg error message.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 

Bug#1070028: aptitude: Extremely alarming warning when pkgs for a foreign architecture will be removed (2 or 3 bugs)

[Manny]

Package: aptitude
Version: 0.8.13-3
Severity: normal
X-Debbugs-Cc: debbug.aptit...@sideload.33mail.com

Aptitude gives a quite extreme warning if it is tasked with removing
packages from a foreign architecture. Packages for i386 were
originally installed to support wine32. The following transcript shows
an upgrade from Bullseye to Bookworm.

===8<
$ aptitude full-upgrade --show-resolver-actions

The following NEW packages will be installed:
  …
The following packages will be REMOVED:
  …
The following packages will be upgraded:
  …
The following packages are RECOMMENDED but will NOT be installed:
  e2fsprogs-l10n exfatprogs laptop-detect libatm1 libnss-systemd libpam-cap 
os-prober thin-provisioning-tools
2130 packages upgraded, 384 newly installed, 451 to remove and 0 not upgraded.
Need to get 0 B/5,556 MB of archives. After unpacking 1,720 MB will be used.
The following packages have unmet dependencies:
  virtualbox : Depends: python3 (< 3.10) but 3.11.2-1+b1 is to be installed
  asymptote : Depends: libgsl27 (>= 2.7.1) but it is not going to be installed
  python3-virtualenv : Depends: python3-pip-whl but it is not going to be 
installed
   Depends: python3-setuptools-whl but it is not going to 
be installed
  filezilla : Depends: libfilezilla34 (>= 0.41.0) but it is not going to be 
installed
  libsemanage1 : Depends: libsemanage-common (= 3.1-1) but 3.4-1 is to be 
installed
The following actions will resolve these dependencies:

  Remove the following packages:
1)  libsemanage1 [3.1-1+b2 (now)]
2)  virtualbox [6.1.26-dfsg-3 (now)]
3)  virtualbox-ext-pack [6.1.26-1 (now)]
4)  virtualbox-qt [6.1.26-dfsg-3 (now)]

  Install the following packages:
5)  libfilezilla-common [0.41.0-2 (stable)]
6)  libfilezilla34 [0.41.0-2 (stable)]
7)  libgsl27 [2.7.1+dfsg-5 (stable)]
8)  python3-pip-whl [23.0.1+dfsg-1 (stable)]
9)  python3-setuptools-whl [66.1.1-1 (stable)]

  Upgrade the following packages:
10) libgslcblas0 [2.6+dfsg-2 (now) -> 2.7.1+dfsg-5 (stable)]

  Leave the following dependencies unresolved:
11) virtualbox-dkms recommends virtualbox (>= 6.1.26-dfsg-3)
12) virtualbox-guest-additions-iso recommends virtualbox (>= 6.1.22)



Accept this solution? [Y/n/q/?] y

The following NEW packages will be installed:
  …
The following packages will be REMOVED:
  …
The following packages will be upgraded:
  …
The following packages are RECOMMENDED but will NOT be installed:
  e2fsprogs-l10n exfatprogs laptop-detect libatm1 libnss-systemd libpam-cap 
os-prober thin-provisioning-tools
2130 packages upgraded, 389 newly installed, 464 to remove and 0 not upgraded.
Need to get 0 B/5,560 MB of archives. After unpacking 1,526 MB will be used.
Do you want to continue? [Y/n/?] y

The following ESSENTIAL packages will be REMOVED!
  libcrypt1:i386 libgcc-s1:i386

WARNING: Performing this action will probably cause your system to break!
 Do NOT continue unless you know EXACTLY what you are doing!
To continue, type the phrase "I am aware that this is a very bad idea": yikes!

$ aptitude remove wine32:i386; # I would have liked to keep this to manage a 
Garmin satnav but it’s apparently causing the extreme messaging

$ aptitude full-upgrade --show-resolver-actions
  …
  WARNING: Performing this action will probably cause your system to break!
   Do NOT continue unless you know EXACTLY what you are doing!
  To continue, type the phrase "I am aware that this is a very bad idea": wtf

$ aptitude why libcrypt1:i386
i A libcrypt1:i386 Depends libc6:i386 (>= 2.25)
i A libc6:i386 Depends libgcc-s1:i386

$ aptitude why libgcc-s1:i386
i   libwine:i386 Depends libc6:i386 (>= 2.29)
i A libc6:i386   Depends libgcc-s1:i386

$ aptitude why libwine:i386
Manually installed, current version 5.0.3-3, priority optional
No dependencies require to install libwine:i386

$ aptitude remove libwine:i386

$ aptitude why libcrypt1:i386
Automatically installed, current version 1:4.4.18-4, priority optional
No dependencies require to install libcrypt1:i386

$ aptitude why libc6:i386
Automatically installed, current version 2.31-13+deb11u8, priority optional
No dependencies require to install libc6:i386

$ aptitude why zlib1g:i386
Automatically installed, current version 1:1.2.11.dfsg-2+deb11u2, priority 
required
No dependencies require to install zlib1g:i386

$ aptitude why libgcc-s1:i386
Automatically installed, current version 10.2.1-6, priority optional
No dependencies require to install libgcc-s1:i386

$ aptitude remove libcrypt1:i386 libc6:i386 zlib1g:i386 libgcc-s1:i386
The following packages will be REMOVED:
  libc6:i386 libcom-err2:i386{u} libcrypt1:i386 libgcc-s1:i386{u} 
libgssapi-krb5-2:i386{u} libidn2-0:i386{u} libk5crypto3:i386{u} 
libkeyutils1:i386{u} libkrb5-3:i386{u} libkrb5support0:i386{u}
  libnsl2:i386{u} libnss-nis:i386{u} libnss-nisplus:i386{u} libssl1.1:i386{u} 
libtirpc3:i386{u} 

Bug#781212: bash: please document the different behaviour for FCEDIT

[Gioele Barabucci]

Control: found -1 5.2.21-2

On Thu, 26 Mar 2015 04:40:09 +0100 Christoph Anton Mitterer 
 wrote:

Debian seems to behave differently than upstream regarding the
value of FCEDIT.
This is fine, but could you please document it appropriately in
the manpage?


For the record, the difference referenced here is the default value of 
FCEDIT.


d/patches/bash-default-editor.diff changes the default value of FCEDIT 
from `vi`, `ed`, `emacs` to `command -v editor`, with a fallback to 
`vi`, `ed`, `emacs`.


--
Gioele Barabucci

Bug#1070025: mesaflash FTCBFS: multiple reasons

[Helmut Grohne]

Source: mesaflash
Version: 3.4.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mesaflash fails to cross build from source for multiple reasons. The
immediate failure is misdetections due to using the build architecture
pkg-config as it is hard coded in the upstream Makefile. Turning it
substitutable helps a bit, but only dh_auto_build provides a
substitution by default so clean fails unless exporting it for all
targets. Beyond that, MESAFLASH_IO detection relies on uname, which will
produce wrong results during cross builds, so provide a result for it.
I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru mesaflash-3.4.6/debian/changelog 
mesaflash-3.4.6/debian/changelog
--- mesaflash-3.4.6/debian/changelog2022-11-05 19:38:09.0 +0100
+++ mesaflash-3.4.6/debian/changelog2024-04-28 21:16:32.0 +0200
@@ -1,3 +1,13 @@
+mesaflash (3.4.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Seed MESAFLASH_IO as the Makefile misdetects it.
++ Export PKG_CONFIG for all targets as clean needs it.
+
+ -- Helmut Grohne   Sun, 28 Apr 2024 21:16:32 +0200
+
 mesaflash (3.4.6-1) unstable; urgency=medium
 
   * Add new Mesa boards: 7C81, 7I96S, 7I92T
diff --minimal -Nru mesaflash-3.4.6/debian/patches/cross.patch 
mesaflash-3.4.6/debian/patches/cross.patch
--- mesaflash-3.4.6/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ mesaflash-3.4.6/debian/patches/cross.patch  2024-04-28 21:16:32.0 
+0200
@@ -0,0 +1,43 @@
+--- mesaflash-3.4.6.orig/Makefile
 mesaflash-3.4.6/Makefile
+@@ -25,6 +25,7 @@
+ RM = rm -f
+ AR = ar
+ RANLIB = ranlib
++PKG_CONFIG ?= pkg-config
+ 
+ OWNERSHIP ?= --owner root --group root
+ 
+@@ -46,25 +47,25 @@
+ CFLAGS += -std=c99
+ 
+ ifeq ($(TARGET),linux)
+-$(shell which pkg-config > /dev/null)
++$(shell which $(PKG_CONFIG) > /dev/null)
+ ifeq ($(.SHELLSTATUS), 1)
+ $(error "can't find pkg-config")
+ endif
+ 
+-$(shell pkg-config --exists libpci > /dev/null)
++$(shell $(PKG_CONFIG) --exists libpci > /dev/null)
+ ifeq ($(.SHELLSTATUS), 1)
+ $(error "pkg-config can't find libpci")
+ endif
+ 
+-$(shell pkg-config --exists libmd > /dev/null)
++$(shell $(PKG_CONFIG) --exists libmd > /dev/null)
+ ifeq ($(.SHELLSTATUS), 1)
+ $(error "pkg-config can't find libmd")
+ endif
+ 
+-LIBPCI_CFLAGS := $(shell pkg-config --cflags libpci)
+-LIBPCI_LDFLAGS := $(shell pkg-config --libs libpci)
+-LIBMD_CFLAGS := $(shell pkg-config --cflags libmd)
+-LIBMD_LDFLAGS := $(shell pkg-config --libs libmd)
++LIBPCI_CFLAGS := $(shell $(PKG_CONFIG) --cflags libpci)
++LIBPCI_LDFLAGS := $(shell $(PKG_CONFIG) --libs libpci)
++LIBMD_CFLAGS := $(shell $(PKG_CONFIG) --cflags libmd)
++LIBMD_LDFLAGS := $(shell $(PKG_CONFIG) --libs libmd)
+ BIN = mesaflash
+ LDFLAGS = -lm $(LIBPCI_LDFLAGS) $(LIBMD_LDFLAGS)
+ CFLAGS += -D_GNU_SOURCE $(LIBPCI_CFLAGS) $(LIBMD_CFLAGS) 
-D_FILE_OFFSET_BITS=64
diff --minimal -Nru mesaflash-3.4.6/debian/patches/series 
mesaflash-3.4.6/debian/patches/series
--- mesaflash-3.4.6/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ mesaflash-3.4.6/debian/patches/series   2024-04-28 21:10:03.0 
+0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru mesaflash-3.4.6/debian/rules mesaflash-3.4.6/debian/rules
--- mesaflash-3.4.6/debian/rules2022-01-15 20:13:35.0 +0100
+++ mesaflash-3.4.6/debian/rules2024-04-28 21:16:27.0 +0200
@@ -1,6 +1,13 @@
 #!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
 include /usr/share/dpkg/pkg-info.mk
 
+# Makefile uses uname, which is wrong for cross builds.
+MESAFLASH_IO:=$(if $(wildcard /usr/include/$(DEB_HOST_MULTIARCH)/asm/io.h),1,0)
+export MESAFLASH_IO
+
 %:
dh $@
 

Bug#1056192: slirp4netns: allow reusing an existing tap file descriptor

[Helmut Grohne]

On Mon, Mar 25, 2024 at 07:53:22AM +0100, Helmut Grohne wrote:
> In the mean time, I've sent the patch upstream.

I note that upstream released version 1.3.0 including this change.

Helmut

Bug#1070026: ifupdown-ng FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: ifupdown-ng
Version: 0.12.1-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ifupdown-ng fails to cross build from source, because debian/rules hard
codes the build architecture pkg-config and thus fails locating libbsd.
This happens to be a silent failure and thus manifests in
-Werror=implicit-function-declaration. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru ifupdown-ng-0.12.1/debian/changelog 
ifupdown-ng-0.12.1/debian/changelog
--- ifupdown-ng-0.12.1/debian/changelog 2024-03-13 15:56:58.0 +0100
+++ ifupdown-ng-0.12.1/debian/changelog 2024-04-28 13:15:51.0 +0200
@@ -1,3 +1,10 @@
+ifupdown-ng (0.12.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 28 Apr 2024 13:15:51 +0200
+
 ifupdown-ng (0.12.1-4) unstable; urgency=medium
 
   * Fix FTBFS due to libbsd header location change (Closes: #1066707)
diff --minimal -Nru ifupdown-ng-0.12.1/debian/rules 
ifupdown-ng-0.12.1/debian/rules
--- ifupdown-ng-0.12.1/debian/rules 2024-03-13 15:54:18.0 +0100
+++ ifupdown-ng-0.12.1/debian/rules 2024-04-28 13:15:50.0 +0200
@@ -1,13 +1,14 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/buildtools.mk
 SHELL := /bin/bash
 
 %:
dh $@
 
 MAKE_VARS := \
-   LIBBSD_CFLAGS="$(shell pkg-config --cflags libbsd-overlay)" \
-   LIBBSD_LIBS="$(shell pkg-config --cflags --libs libbsd-overlay)"
+   LIBBSD_CFLAGS="$(shell $(PKG_CONFIG) --cflags libbsd-overlay)" \
+   LIBBSD_LIBS="$(shell $(PKG_CONFIG) --cflags --libs 
libbsd-overlay)"
 
 override_dh_auto_build:
# Compatiblity glue for libbsd (strlcpy 'n friends)

Bug#1070024: Rebuild for cmake 3.29 compatibility fix

[textshell]

Package: ksyntax-highlighting
X-Debbugs-CC: c...@istoph.de
Severity: important

(this is a follow-up to #1069972)

Please rebuild libkf5syntaxhighlighting-dev using
extra-cmake-modules 6.1.0-1 or newer.

As far as i understand this needs a sourceful upload as
libkf5syntaxhighlighting-dev is a arch any binary package.
(not sure if it needs a versioned build depends to pick up the
new version of extra-cmake-modules)

Since cmake 3.29 entered sid, the files created by ECMAddQch.cmake from
extra-cmake-modules < 6.1.0-1 (as the libkf5syntaxhighlighting-dev
currently in sid) cause warnings or errors (with CMP0160 set to NEW).

Furthermore when libkf5syntaxhighlighting-dev is consumed in packages
build using meson, the build fails as the meson cmake compat code
always sets cmake_minimum_required to the current cmake version and
thus CMP0160 is alway set to NEW which makes the code generated
before the fix an hard error.

For example the package chr now no longer builds in sid because of
this.

-- Configuring incomplete, errors occurred!
ERR:
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/KF5SyntaxHighlighting/KF5SyntaxHighlightingQchTargets.cmake:6
 (set_target_properties):
  IMPORTED property is read-only for target("KF5SyntaxHighlighting_QCH")
Call Stack (most recent call first):
  
/usr/lib/x86_64-linux-gnu/cmake/KF5SyntaxHighlighting/KF5SyntaxHighlightingConfig.cmake:42
 (include)
  CMakeLists.txt:20 (find_package)

(for a full log see https://salsa.debian.org/chr/chr/-/jobs/5651154 )

Regards,
 - Martin

Bug#1070023: dict-freedict-eng-jpn: Failure to stop dictd.service on purge even if unit is not loaded

[inasprecali]

Package: dict-freedict-eng-jpn
Version: 2022.12.07-2
Severity: normal
X-Debbugs-Cc: inasprec...@disroot.org

Dear Maintainer,

when uninstalling (purging) the package, I got the following error message:

Failed to stop dictd.service: Unit dictd.service not loaded.
invoke-rc.d: initscript dictd, action "stop" failed.

Apt reports that the subprocess returned error code 5 (five).

I did not have dictd running as a service, so this error was unexpected,
but I got it regardless.  The package seems to have been purged successfully
anyway.  Thus, it is only a minor annoyance, but the post-build script should
check properly whether dictd.service is actually running before attempting
to stop it.

-- System Information:
Debian Release: 12.5
  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-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

dict-freedict-eng-jpn depends on no packages.

dict-freedict-eng-jpn recommends no packages.

Versions of packages dict-freedict-eng-jpn suggests:
pn  dict | kdict | gnome-dictionary | goldendict  
pn  dictd | dicod 

Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

On 28/04/24 20:01, Chet Ramey wrote:

On 4/27/24 6:23 PM, Gioele Barabucci wrote:
bash 5.0 and 5.2 do not set $BASH to the right value when bash is used 
as the login shell:


 $ apt install bash-static
 $ getent passwd $USER | cut -d: -f 7
 /bin/bash

 $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

 /usr/bin/bash-static
 /usr/bin/bash-static

 $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

 /bin/bash
 /usr/bin/bash-static

(bash-static is not a link to bash)


What does `su' pass to bash in argv[0]?



$ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

/usr/bin/bash-static
/usr/bin/bash-static
bash-static

$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

/bin/bash
/usr/bin/bash-static
-bash-static

Regards,

--
Gioele Barabucci

Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects

[Jay Berkenbilt]

(Sorry for the duplicate -- I inadvertently failed to cc the bug report on my 
private reply.)

On Sun, Apr 14, 2024, at 1:50 PM, Thorsten Glaser wrote:
> Jay Berkenbilt dixit:
> 
> >As it happens, I am upstream.
> 
> Oh, nice ☻ in that case, thanks for qpdf.
> 
> >---
> >It is not generally practical to remove objects from QDF files without
> >messing up object numbering, but if you remove all indirect references
> >to an object (without removing the object itself), this will leave the
> >object unreferenced. Then you can run qpdf on the file (after running
> >:command:`fix-qdf`), and qpdf will omit the now-orphaned object.
> >---
> 
> That fixes the ambiguity but leaves the reader¹ wondering, on two
> reading passes, what other references than indirect there are.
> The reader who has not digested the PDF spec in and out, at least.
> 
> If you s/ indirect//, would it still be correct? That would be
> less possibly-ambiguous, I think.

If it triggers this thought in you, it will trigger it in others. New wording:

It is not generally practical to remove objects from QDF files without
messing up object numbering, but if you remove all references to an
object without removing the object itself (by removing all indirect
objects that point to it), this will leave the object unreferenced.
Then you can run qpdf on the file (after running :command:`fix-qdf`),
and qpdf will omit the now-orphaned object.

> bye,
> //mirabilos
> ① or at least me right now
> -- 
>  Beware of ritual lest you forget the meaning behind it.
>  yeah but it means if you really care about something, don't
> ritualise it, or you will lose it. don't fetishise it, don't
> obsess. or you'll forget why you love it in the first place.
> 

Bug#1064808: Accepted node-sanitize-html 2.13.0+~2.11.0-1 (source) into unstable

[Salvatore Bonaccorso]

Source: node-sanitize-html
Source-Version: 2.13.0+~2.11.0-1

On Sun, Apr 28, 2024 at 02:40:18PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 28 Apr 2024 17:48:12 +0400
> Source: node-sanitize-html
> Built-For-Profiles: nocheck
> Architecture: source
> Version: 2.13.0+~2.11.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers 
> 
> Changed-By: Yadd 
> Changes:
>  node-sanitize-html (2.13.0+~2.11.0-1) unstable; urgency=medium
>  .
>* Team upload
>* Update lintian override info format in d/source/lintian-overrides
>  on line 4-5
>* Declare compliance with policy 4.7.0
>* New upstream release (Closes: CVE-2024-21501)
>* Unfuzz patches
> Checksums-Sha1: 
>  fcf4b0215aafdcede7959494b0da422d54e1cfb5 2729 
> node-sanitize-html_2.13.0+~2.11.0-1.dsc
>  582d8c72215c0228e3af2be136e40e0b531addf2 2828 
> node-sanitize-html_2.13.0+~2.11.0.orig-types-sanitize-html.tar.gz
>  ae75ec4d6145dabd57328e9ab0cbddcf5a59830b 45951 
> node-sanitize-html_2.13.0+~2.11.0.orig.tar.gz
>  e5ba4b5c3f17715597b63a7566a44b31e268cdd2 3736 
> node-sanitize-html_2.13.0+~2.11.0-1.debian.tar.xz
> Checksums-Sha256: 
>  248588aadd03932b4a6f8c7545127894e5058379706d361fc77d0e7786860c49 2729 
> node-sanitize-html_2.13.0+~2.11.0-1.dsc
>  c0f4ed19e9f1dd0a53fbe204e803e73008d760a549116cd98f3ec67a7d434ad7 2828 
> node-sanitize-html_2.13.0+~2.11.0.orig-types-sanitize-html.tar.gz
>  f50aec59bb5de24115864a852bccc2bd7033b3459f4087910f2173f4e9bf3e54 45951 
> node-sanitize-html_2.13.0+~2.11.0.orig.tar.gz
>  9790307661157f4a9c2b24d76a9c646f0c6b64e6cc8396cfd1234a0226176f57 3736 
> node-sanitize-html_2.13.0+~2.11.0-1.debian.tar.xz
> Files: 
>  357330bee53c034e00803a83216f1062 2729 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0-1.dsc
>  11a9538eda02816f35805a34e88eb09d 2828 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0.orig-types-sanitize-html.tar.gz
>  d8cb51cb238cc377e69d1a651be83435 45951 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0.orig.tar.gz
>  7486b0a164aa88b192c0300022070e7f 3736 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0-1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYuVCcACgkQ9tdMp8mZ
> 7um/qQ/+OjkDvMLLDu2JQLHsZh0OvuKFfjUgFdnhXdRZeS2kg1IVZd9xVUu864Ri
> quHE88QVy+4Ak5TxChEhYZxl8GAXXCpoe5oirHRIJlhw1FS4B7Uf2i50ccTm9OfE
> K22lr6VBgxhP8XzkDE4yLVfUyXS2NjbVW7olTYqL6GFzAllA2Xu6EFC+u25C3ruH
> drCg/MO33NZRal68qBUSNEenDmT9IEpfHUNOLxrukSSx1512DlcCJvw8EqAPMCwR
> wsJwvvJb6ryh7BouE6qsELG+DnwOHARx00I3iir48mWjAjNV46haj1y5Rc3+TIQm
> vC2Dsr7aWdtucAlyRWxl4X+E+15WUkOollbG3y5cLExHFUpXqu5SbSYqBqDepdYm
> xf1Oc/nSAv5/1mtDgT6nl72lr5OeGEGc+eDN9yEyy7cxwHMttI7IM/iZ/nd6l9Ie
> l1e1ySCJqO/D2Vcg7HOWWq8v8hj/ZVZnllaT3+d9Q22SGtwNuQIJfyq8GOHuxjli
> 8SnBemEUB4xEsbJpNz+d5woh3Uvf/0Z4Pk9UK1F4Rz0VeDGuhkHuyVLFxcPm20el
> 7E1WJ63zN4xg8B0zCWfJ3TJLRgWhJnzPF0IkoQiovXU6ha368TmAouuQRa2Pzy4Z
> D/jNaOxb1OqPdwtjfZ40fNu+9VaLjsFiIRRs2Eueaa/nMuy5r2k=
> =+7g+
> -END PGP SIGNATURE-
> 

Bug#1063535: Accepted node-ip 2.0.1+~1.1.3-1 (source) into unstable

[Salvatore Bonaccorso]

Source: node-ip
Source-Version: 2.0.1+~1.1.3-1

On Sun, Apr 28, 2024 at 02:40:08PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 28 Apr 2024 17:44:01 +0400
> Source: node-ip
> Architecture: source
> Version: 2.0.1+~1.1.3-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers 
> 
> Changed-By: Yadd 
> Changes:
>  node-ip (2.0.1+~1.1.3-1) unstable; urgency=medium
>  .
>* Team upload
>* Declare compliance with policy 4.7.0
>* New upstream version (Closes: CVE-2023-42282)
>* Unfuzz patches
> Checksums-Sha1: 
>  c951a3237457516c4932de97e6b040eb590e1945 2302 node-ip_2.0.1+~1.1.3-1.dsc
>  5d8634b3514a51768adda5e17c91a11cdb2e5247 2392 
> node-ip_2.0.1+~1.1.3.orig-types-ip.tar.gz
>  497fb529449bf1db7734ffb9f26ec18db0553267 35824 
> node-ip_2.0.1+~1.1.3.orig.tar.gz
>  18ada04f9e27e8b73408cc5857b9105c72752094 3536 
> node-ip_2.0.1+~1.1.3-1.debian.tar.xz
> Checksums-Sha256: 
>  155a2eff41959eb5ac609794197da71c85fa2563cc2d2cc8a2441f8b33a056d7 2302 
> node-ip_2.0.1+~1.1.3-1.dsc
>  5dae9ca606ec5b95e21c78609c8c9ceef7808b36592258766a40a9aeade753b5 2392 
> node-ip_2.0.1+~1.1.3.orig-types-ip.tar.gz
>  ee8b0634c671b58d135a07fcfb70b41d7d9c9e457db6ade06982f7c38df526d3 35824 
> node-ip_2.0.1+~1.1.3.orig.tar.gz
>  d54aea7b8f3bf090547c1792e659eec9568b9eae4d18a4c7a42f83e5275d2540 3536 
> node-ip_2.0.1+~1.1.3-1.debian.tar.xz
> Files: 
>  9fc45e1089a79918b594c09a71f33198 2302 javascript optional 
> node-ip_2.0.1+~1.1.3-1.dsc
>  d937a8472e46d87f5a6928bc92599ff9 2392 javascript optional 
> node-ip_2.0.1+~1.1.3.orig-types-ip.tar.gz
>  f4f085a822f61608dac1de6bdf1377fb 35824 javascript optional 
> node-ip_2.0.1+~1.1.3.orig.tar.gz
>  a9a1508cc10542a3d1751143ed098ec2 3536 javascript optional 
> node-ip_2.0.1+~1.1.3-1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYuUssACgkQ9tdMp8mZ
> 7ukK1RAAnntmtKJD/wR6EU/ELjRRQEbQOYf+WQ0Uek09Sv5fKlC/tpbQT8uHFJAc
> ibBb85CIo0gzCd4+k1BZzXQwCt1eoaqTfNITjHIjyFIEu+KKQP4HVCkxxqRz1MNE
> 9WHWHEyH+Qfy60zVVwPgaDz7L16J4Pf//KwdROJMLLPDT4sa9VZjyp/nDsGTtZTp
> 6oBpWrvpVmfEVKl4ovx6jSPzGSd7s/MTcP9HqIy+v39fyMxCdyMHigf4T+hZNgi1
> 0sa6kaXjMicDEdyCfdz8ZMGagO0hyGadJnxguIm9yz0svz5ykk2JnDGKEWJ76h0H
> smDXP1BW9SSpPfPyERDev2V4jjGdgy2XsJOAQ3H6RzQCvAD4lAK95Ca6shoPU6/y
> ZNmVwbZaueRJfSYZNbOVBSJEup2UenGkb34Wge00gd7IlJFo/Ts6b0TOl1BApGuI
> N2IbB00Q7h7Dg+4YdOyVROi74sXXzn8V0Ehv1vdimr8+qr1X+a+/lbYBBqoPiUSS
> S0xcgzJ8UmJDVp3C6CjSJifANi0SIrdT1IDqSmNxATyXAszQ+7WTbzJDUKclxASa
> g7+Vd/piIaO4nd3pv2SsyFdoW/pe+o9Wkqb9HAnQ9UIpaJrJVbGLcGiRN1xt1Dtj
> naAhta0leuGeHvgJqr9NtFQEypSuPlMZD7Agm50dS0k3Jag9mmI=
> =Bygl
> -END PGP SIGNATURE-
> 

Bug#1064933: Accepted node-es5-ext 0.10.64+dfsg1+~1.1.0-1 (source) into unstable

[Salvatore Bonaccorso]

Source: node-es5-ext
Source-Version: 0.10.64+dfsg1+~1.1.0-1

On Sun, Apr 28, 2024 at 02:39:58PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 28 Apr 2024 17:42:38 +0400
> Source: node-es5-ext
> Architecture: source
> Version: 0.10.64+dfsg1+~1.1.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers 
> 
> Changed-By: Yadd 
> Changes:
>  node-es5-ext (0.10.64+dfsg1+~1.1.0-1) unstable; urgency=medium
>  .
>* Team upload
>* Declare compliance with policy 4.7.0
>* New upstream version (CLoses: CVE-2024-27088)
> Checksums-Sha1: 
>  00ac9a9cc333a9591819f29f9dc201a44b86ed39 2502 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.dsc
>  47adcb21fae6891d7ee7361925cd9271b17014d8 4000 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig-next-tick.tar.xz
>  a14349957458b4c3a550ddc89a8eb46d3ac55060 98820 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig.tar.xz
>  b66861c5b13af54d9f17fb848bf2ef97bc05f010 4368 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.debian.tar.xz
> Checksums-Sha256: 
>  56f461199b70efb68d0a7b6fc1933dccd192682112334c404fd0af77b4ca729b 2502 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.dsc
>  4b88466e757b6cddefed1275407b4aced0f9379c1caec88fc0dbd737f218ea67 4000 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig-next-tick.tar.xz
>  73eefa5ace80aa1ca02c4e8d941c892c92d511ecc90186313bcef739f0e960a5 98820 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig.tar.xz
>  f70ca85871aa3c5c8a6eaf8d4bf1d5789fdd46e08511d3230bf87057b359a306 4368 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.debian.tar.xz
> Files: 
>  96882f12a6df1d1e5cbd19205a4b2c85 2502 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.dsc
>  503a8a5ea72aeab3a8f9af621752bb1e 4000 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig-next-tick.tar.xz
>  ecbd763c6d41f64d0a4b762d3e5fb921 98820 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig.tar.xz
>  a12714528ad453fe2de55bcf011c2b15 4368 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYuUrgACgkQ9tdMp8mZ
> 7ulscA//fdH9BrZjJRz5yrUIEJBIQPGwmjbLgv0pYfOBXCcchb6jlt2eCGrZhocQ
> sUju3+bf3XwsOhPiESJ8crt50VhQrF4ymGFlYZKxpAURFcQYFJ0s2+BAybwo6o60
> JOa1+rvcU/qFUm+yvECRFgH4rO67uWkIYfdxPYRiW5Q9+Elu/BqBqVW778sxzXai
> n/auHL6v0yWh002ATorJWN0BqcVDTIvc+O9dX8WjWquNb0xylTnCv8xIMrskaIOj
> g2yu7Wpd2n7d4FsF7RNcauUHRb+tUl1b3uDrfLjf/twH6BEfNa6u0ASIdrPNNtw5
> z7Nn2JlbdQuoSjPfQXNHJ6u9ihRfEuHKfV2CLorxt/yS5QrrpxyaEIPRE1KbhO/L
> +SAlM5PfLg2boMxSoWXjTL3emamsFa46P6BdzpEQQl/6uhKYjTCQucP8NAAgoPUx
> G4QKE0kkgBF08dxn4e7WKmkkMfP1xeJ3hFVC9qD8BcCmKij0kCU9SAMmm9rEMsKD
> MEJnho+7kqO+Y3owwjrMFaKkLR0dXNiox81CF/gtVwK77Mka/sX95sSrS4A2mecb
> /jCMmc4JRJ8tuLcrnb3AMC/EAkPCnd36T3OEez3gWD/qYOR/afirNN2h5EhSrNcH
> qMRuG6IHhBvRLeUd9L1R2TA7KdPGr431cOVQr/ojsRnA2I5gTaM=
> =UP4E
> -END PGP SIGNATURE-

Bug#1069960: passwordsafe: (regression) pwsafe crashes after supplying master password

[devel]

On Sat, Apr 27, 2024 at 05:51:38PM +0200, Manny wrote:
> 
> After upgrading from Bullseye to Bookworm, pwsafe crashes after
> supplying the master password. Terminal output shows:


Hi, thanks for your report.

If you have the ability to test 1.17 from testing/unstable, or 1.18 from
upstream, it would be helpful to know if you do/don't see the same
assertion failure with those.

In the mean time, I'll try to look at it and see if I can figure out
what's causing it.


> It’s worth noting that my DB file was originally created by Bruce
> Schneier’s “pwsafe” CLI tool. That package died for some reason and as

This is a common misconception.

Bruce's original PasswordSafe was a (windows-only) GUI application, and
the GUI version we're shipping in Debian is a direct descendant of that
original code [1].

The CLI-only version was a unix-compatible clone from another developer [2]
(towards the bottom, "pwsafe password database" for Unix) that got
popular because there was no official Linux version at that time.

That developer was unresponsive for several years, and the package was
dropped from Debian [3] [4].  The author has since resurfaced [5], but has
stated that he doesn't plan on supporting the current database version
(v3) [6].

Not that any of that changes the issue you're having.

[1] https://www.schneier.com/academic/passsafe/
[2] http://pwsafe.org/relatedprojects.shtml
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601300
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619704
[5] https://github.com/nsd20463/pwsafe
[6] https://github.com/nsd20463/pwsafe/issues/13#issuecomment-328247430


> However, it was only compatible in terms of *reading* the DB. Edits
> result in corruption (yikes!). So I was crippled with version
> 1.12.0+dfsg-1 but at least I could /read/ my DB. Of course this crash
> in version 1.16.0+dfsg-4 is a total show stopper.

Assuming this corruption is similar to what was reported upstream [7],
the database itself should be unchanged, and the corrupted changes you see
should only be in the GUI.  That doesn't really make it any more useable for
you, but at least it hopefully shouldn't be trashing your data.

That said, v3 was released in 2006, and v1 and v2 have been deprecated
for quite a while. So if you want to continue using PasswordSafe, you'll want
to import your v2 database, then save it as v3 in order to edit it going
forward [8]. Of course, in doing that, you won't be able to open it in the
old CLI any more, since it doesn't support v3.

[7] https://github.com/pwsafe/pwsafe/issues/367
[8] https://github.com/pwsafe/pwsafe/issues/180


Also, if CLI is a sticking point for you, upstream has been working on a
CLI-based version for a while, but we're not currently shipping it as
part of the Debian package. I can look into adding that if it would be
helpful.  Though I haven't used it, so I can't speak to how it is.


Best regards,
Bill

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sun, Apr 28, 2024 at 01:02:26PM +0100, Alberto Bertogli wrote:
The problem seems to be that some of the functions that have 64-bit 
variants (e.g. pread64, pwrite64) have an assembler name declared for 
the regular variant in the header; while other platforms don't do that 
and have the two functions declared separately.


https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html

For example, this is the declaration of pread and pwrite in a 
post-preprocessed file, diff between x86_64 (without the bug, '-') and 
armel (with the bug, '+'):


```
@@ -1068,18 +,14 @@
extern ssize_t write (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
-__off_t __offset)
-__attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pread64")
+__attribute__ ((__access__ (__write_only__, 2, 3)));
+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pwrite64")
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,
- __off_t __offset)
__attribute__ ((__access__ (__read_only__, 2, 3)));
# 422 "/usr/include/unistd.h" 3 4
extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```

That's why it's the assembler (and not linking) stage that's 
complaining, because that means both functions end up named as the 
64-bit variant. This can be seen in the assembly file. Continuing to 
use pread/pread64 as an example, there is no definition for pread(), 
only pread64() twice: once for pread and one for pread64.


It's tricky to support this in a generic way, because it's difficult 
to detect this is even happening, as the assembler name operates at a 
compiler level so we can't just undo it.


More things that make this interesting.

This program:

```
#include 
#include 
#include 

int main() {
printf("pread: %p\n", pread);
printf("pread64: %p\n", pread64);
printf("pread64 is pread: %b\n", pread == pread64);

void *lib = dlopen(NULL, RTLD_NOW);
void *l_pread = dlsym(lib, "pread");
void *l_pread64 = dlsym(lib, "pread64");

printf("l_pread: %p\n", l_pread);
printf("l_pread64: %p\n", l_pread64);
printf("l_pread64 is l_pread: %b\n", l_pread == l_pread64);
}
```

Built with:
  cc -save-temps=obj -D_XOPEN_SOURCE=600 -D_LARGEFILE64_SOURCE=1  -std=c99 
-Wall demo.c

Prints this on x86_64 Debian testing (which does not show this bug):

```
pread: 0x7fc1970f0c10
pread64: 0x7fc1970f0c10
pread64 is pread: 1
l_pread: 0x7fc1970f0c10
l_pread64: 0x7fc1970f0c10
l_pread64 is l_pread: 1
```

And prints this on the armel chroot:

```
pread: 0xf7da6a90
pread64: 0xf7da6a90
pread64 is pread: 1
l_pread: 0xf7da68f8
l_pread64: 0xf7da6a90
l_pread64 is l_pread: 0
```

So on x86_64 both pread() and pread64() are the same function, yet the 
headers allow us to declare them individually.


But on armel, even though there is a separate implementation of pread() 
on libc, the headers prevent us from declaring them separately (because 
of the asm name declaration in unistd.h).


Just putting this here in case it helps someone else debug a similar 
problem in the future.


I'm still trying to find a reasonable workaround.

Thanks,
Alberto

Bug#935905: bash: ":?xxx" filename broken on autocomplete

[Chet Ramey]

On 4/27/24 5:46 PM, Kerin Millar wrote:

On Sat, 27 Apr 2024 23:28:49 +0200
Gioele Barabucci  wrote:


Control: found -1 5.2.21-2

On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek 
wrote:

the autocompletion is broken on filenames or directories with ":?" at the
beginning.

 # mkdir ':?aa'
 # rmdir :

gives me

 # rmdir :\:\?

which doesn't match the filename; I can finish completion by entering "aa",
but then "rm" rejects this name.


In bash 5.2.21(1) the filename is now fully completed, but the stray ":"
at the beginning is still produced:

  $ mkdir ':?aa'
  $ rmdir :
  $ rmdir :\:\?aa/


In the course of trying this in bash-5.3-alpha, I noticed something else. If ':?aa' is not the only entry in the current working directory, readline behaves as if : is an ambiguous completion. 


The word being completed is "".

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#935905: bash: ":?xxx" filename broken on autocomplete

[Chet Ramey]

On 4/27/24 5:28 PM, Gioele Barabucci wrote:

Control: found -1 5.2.21-2

On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek  
wrote:
the autocompletion is broken on filenames or directories with ":?" at the 
beginning.


    # mkdir ':?aa'
    # rmdir :

gives me

    # rmdir :\:\?

which doesn't match the filename; I can finish completion by entering 
"aa", but then "rm" rejects this name.


In bash 5.2.21(1) the filename is now fully completed, but the stray ":" at 
the beginning is still produced:


     $ mkdir ':?aa'
     $ rmdir :
     $ rmdir :\:\?aa/


`:' is one of the characters in the default value of COMP_WORDBREAKS, which
is how bash exposes the set of characters readline uses to break words for
completion.

The word being completed here is "". If you want to complete a filename
starting with `:', quote it with a backslash.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070016: quake4: hard-coded dependencies on pre-t64 libraries

[Simon McVittie]

On Sun, 28 Apr 2024 at 17:27:21 +0200, Sebastian Ramacher wrote:
> quake4 has hard-coded dependencies on shared libraries (at least
> libasound2) that were renamed as part of the t64 transition. Please
> update the dependencies accordingly.

quake4 is i386-only, and i386 has Provides for the old names and no real
ABI break, so I don't think this is necessarily RC - although updating
quake4 in src:game-data-packager might help apt to choose better upgrade
paths, so it's a valid bug.

(The i386 binaries referenced by quake4 - really in the quake4-bin package
produced by game-data-packager - are proprietary and non-modifiable,
and target the pre-t64 ABI.)

smcv

Bug#1070020: autopkgtest: (unrelated) packages not found

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Chris Hofstaedtler (2024-04-28 18:30:56)
> the autopkgtests for mmdebstrap as part of migration tests for testing/amd64
> fail with apt reporting 'Not found' errors.
> 
> As an example, for this scenario:
> mmdebstrap 1.4.3-6
> util-linux/2.40-8 gdm3/46.0-2 sssd/2
> src:util-linux from unstable
> src:gdm3 from unstable
> src:sssd from unstable
> https://ci.debian.net/packages/m/mmdebstrap/testing/amd64/46033215/
> 
> 1085s Err:22 http://127.0.0.1/debian unstable/main amd64 libssl3 amd64 3.1.5-1
> 1085s   404  File not found [IP: 127.0.0.1 80]
> ...
> 1085s Err:41 http://127.0.0.1/debian unstable/main amd64 libdb5.3 amd64 
> 5.3.28+dfsg2-4+b1
> 1085s   404  File not found [IP: 127.0.0.1 80]
> ...
> 1085s Err:73 http://127.0.0.1/debian unstable/main amd64 libgdbm6 amd64 
> 1.23-5+b1
> 1085s   404  File not found [IP: 127.0.0.1 80]
> 1085s Err:74 http://127.0.0.1/debian unstable/main amd64 libgdbm-compat4 
> amd64 1.23-5+b1
> 1085s   404  File not found [IP: 127.0.0.1 80]
> 
> This looks like a pinning problem or some other issue. Given libssl3 is
> a problem here, which is NOT a package considered for migration in this
> test, I don't see how the test failure is actually related to the
> involved packages.
> If this is a transient situation, please detect it and exit with status 77.

unfortunately, this problem is not transient but reproducible. The problem is,
that the involved libraries which are 404 have alternative 64bit time_t
versions in unstable:

libssl3 -> libssl3t64
libdb5.3 -> libdb5.3t64
libgdbm6 -> libgdbm6t64
libgdbm-compat4 -> libgdbm-compat4t64

And apt chooses to satisfy the (virtual) dependencies on those differently,
depending on the surrounding dependency satisfaction problem. Related,
debootstrap is also broken by the virtual providers of libssl3: #1069787

Feel free to tell the release team to ignore these failures if necessary. They
will go away once the 64bit time_t transition is finished.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1070022: libretro-beetle-psx FTBFS on mips64el with -Werror=implicit-function-declaration

[Adrian Bunk]

Source: libretro-beetle-psx
Version: 0.9.38.6+git20151019-3
Severity: serious
Tags: ftbfs patch trixie sid

https://buildd.debian.org/status/fetch.php?pkg=libretro-beetle-psx=mips64el=0.9.38.6%2Bgit20151019-3%2Bb1=1714231581=0

...
libretro-common/rthreads/rthreads.c: In function ‘scond_wait_timeout’:
libretro-common/rthreads/rthreads.c:410:4: error: implicit declaration of 
function ‘gettimeofday’ [-Werror=implicit-function-declaration]
  410 |gettimeofday(, NULL);
  |^~~~
cc1: some warnings being treated as errors
make[2]: *** [Makefile:264: libretro-common/rthreads/rthreads.o] Error 1

Bug#1070021: libretro-beetle-pce-fast FTBFS on mips64el with -Werror=implicit-function-declaration

[Adrian Bunk]

Source: libretro-beetle-pce-fast
Version: 0.9.38.7+git20160609-2
Severity: serious
Tags: ftbfs patch trixie sid
Forwarded: 
https://github.com/libretro/libretro-common/commit/20a43ba79fe6b4ec094b3b20b7bc88f4cfe916fa

https://buildd.debian.org/status/fetch.php?pkg=libretro-beetle-pce-fast=mips64el=0.9.38.7%2Bgit20160609-2%2Bb1=1714231411=0

...
libretro-common/rthreads/rthreads.c: In function ‘scond_wait_timeout’:
libretro-common/rthreads/rthreads.c:423:4: error: implicit declaration of 
function ‘gettimeofday’ [-Werror=implicit-function-declaration]
  423 |gettimeofday(, NULL);
  |^~~~
cc1: some warnings being treated as errors
make[2]: *** [Makefile:332: libretro-common/rthreads/rthreads.o] Error 1

Bug#1070018: ausweisapp: Mising dependency to libqt6svg6

[John Paul Adrian Glaubitz]

Hello Juergen,

On Sun, 2024-04-28 at 18:09 +0200, Juergen Bausa wrote:
> I run ausweisapp backport on bookworm. However, it doesnt display an icon in 
> the control panel of KDE. 
> Ausweisapp2 (which is actually a slightly older version) did display an icon. 
> While ausweisapp2 depended 
> on libqt6svg6, ausweisapp does not. Aftre installing libqt6svg6 manually the 
> icon is displayed in ausweisapp
> also. So I think the dependency on libqt6svg6 is just missing in ausweisapp.

This is a known issue and a result of a potential bug in Qt6 which results in 
dpkg-shlibdeps not adding
the runtime dependency for libqt6svg6 during build. While I could hardwire 
libqt6svg6 as a runtime
dependency into debian/control, this would cause problems when the ABI of the 
Qt6 SVG library is being
bumped resulting in the library package being renamed from libqt6svg6 to 
libqt6svg7.

Currently, the workaround is to install the missing libqt6svg6 package manually.

> In addition it seems to me that the window of AusweisApp looks extremely 
> clean (just white background).
> Ausweisapp2 was much more colourful. I guess that another lib is missing for 
> ausweisapp to display
> the intended look.

No, this is by design. The upstream developers have decided to make the user 
interface as minimalistic
as possible. I'm not such a fan of the new design either, but that's just how 
it looks now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070020: autopkgtest: (unrelated) packages not found

[Chris Hofstaedtler]

Source: mmdebstrap
Version: 1.4.3-6
Severity: serious
X-Debbugs-Cc: debian-rele...@lists.debian.org

Hi,

the autopkgtests for mmdebstrap as part of migration tests for
testing/amd64 fail with apt reporting 'Not found' errors.

As an example, for this scenario:
mmdebstrap 1.4.3-6
util-linux/2.40-8 gdm3/46.0-2 sssd/2
src:util-linux from unstable
src:gdm3 from unstable
src:sssd from unstable
https://ci.debian.net/packages/m/mmdebstrap/testing/amd64/46033215/

1085s Err:22 http://127.0.0.1/debian unstable/main amd64 libssl3 amd64 3.1.5-1
1085s   404  File not found [IP: 127.0.0.1 80]
...
1085s Err:41 http://127.0.0.1/debian unstable/main amd64 libdb5.3 amd64 
5.3.28+dfsg2-4+b1
1085s   404  File not found [IP: 127.0.0.1 80]
...
1085s Err:73 http://127.0.0.1/debian unstable/main amd64 libgdbm6 amd64 
1.23-5+b1
1085s   404  File not found [IP: 127.0.0.1 80]
1085s Err:74 http://127.0.0.1/debian unstable/main amd64 libgdbm-compat4 amd64 
1.23-5+b1
1085s   404  File not found [IP: 127.0.0.1 80]

This looks like a pinning problem or some other issue. Given libssl3 is
a problem here, which is NOT a package considered for migration in this
test, I don't see how the test failure is actually related to the
involved packages.
If this is a transient situation, please detect it and exit with status
77.

Chris

Bug#1070019: udisks2: autopkgtest failure: fsconfig system call failed: /dev/sr1: Can't open blockdev

[Chris Hofstaedtler]

Source: udisks2
Version: 2.10.1-6
Severity: serious

Hi,

udisks2's autopkgtest fails when tried together with util-linux 2.40. An
example can be seen here:
https://ci.debian.net/packages/u/udisks2/testing/amd64/46012968/

537s ==
537s FAIL: test_ext4 (__main__.FS.test_ext4)
537s fs: ext4
537s --
537s Traceback (most recent call last):
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 1107, in _do_udisks_check
537s cd_fs.call_mount_sync(ro_options, None)
537s gi.repository.GLib.GError: udisks-error-quark: 
GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sr1 at 
/media/root/41b1acb1-744c-422a-9071-2dba5368a683: fsconfig system call failed: 
/dev/sr1: Can't open blockdev (0)
537s 
537s During handling of the above exception, another exception occurred:
537s 
537s Traceback (most recent call last):
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 725, in test_ext4
537s self._do_fs_check('ext4')
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 894, in _do_fs_check
537s self._do_udisks_check(fs_type)
537s   File "/tmp/autopkgtest.btnhgm/build.cz4/src/src/tests/integration-test", 
line 1112, in _do_udisks_check
537s self.fail('Mounting read-only device with \'rw\' option failed'
537s AssertionError: Mounting read-only device with 'rw' option failedwith an 
unexpected error.
537s Got: udisks-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: 
Error mounting /dev/sr1 at /media/root/41b1acb1-744c-422a-9071-2dba5368a683: 
fsconfig system call failed: /dev/sr1: Can't open blockdev (0)
537s Expected: 'is write-protected but explicit read-write mode requested' or 
'is write-protected but `rw' option given'

I do not understand what this error means, or what the underlying problem is.
Please investigate.

Chris

Bug#1070017: google-android-installers: depends on pre-64 libraries

[Fab Stz]

Hello,

I already had a look at this and IMHO there is nothing to do as the package is 
amd64 only and as libasound2 will pull in the correct t64 anyway. Moreover the 
package doesn't build any binary, it is a wrapper that downloads upstreams 
binary, so nothing ca be changed here I think.

Unless further notice or advice on how to fix that, I will close this in some 
time.

Regards
Fab

On Sun, 28 Apr 2024 17:35:23 +0200 Sebastian Ramacher  
wrote:
> Source: google-android-installers
> Version: =1710437545-4
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> google-android-installers builds binary packages that depend on shared
> libraries (at least libasound2) that were renamed as part of the t64
> transition. Please update the dependencies accordingly.
> 
> Cheers
> -- 
> Sebastian Ramacher
> 
> 

Bug#1052009: Provide compiler-rt builtins for windows/mingw-64

[Sylvestre Ledru]

Hello


Le 16/09/2023 à 00:29, Norbert Lange a écrit :

Package: libclang-rt-16-dev
Version: 1:16.0.6-3
Severity: wishlist
X-Debbugs-Cc: nolang...@gmail.com

Adding the compiler-rt library for windows / mingw-64 would allow ease building
mingw-64 tools,
the builtins seem to be pretty universal for any windows target.

There is a project providing a full mingw toolchain for reference:
https://github.com/mstorsjo/llvm-mingw

I am able to create the builtins just with the mingw-w64-common package and
debians llvm/clang like this:


Sorry but I am not a windows user (or interested by this space), could 
you please provide a MR to implement this?


Thanks

S

Bug#1070005: mirror submission for mirrors.hostico.ro

[Awesome Projects]

  Hello,

i apologize. I completely forgot about the reply and just checked the 
mirror listing.


---
  Regards,
  Sebastian Bobriuc

On 4/28/24 17:56, Adam D. Barratt wrote:

On Sun, 2024-04-28 at 13:28 +, Hostico wrote:

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

Submission-Type: new
Site: mirrors.hostico.ro

This is *not* a new submission. Please do not submit duplicate details
for already listed mirrors.

You were already advised two days ago to allow a few days for your
mirror to automatically return to the published listing and that you
did not need to resubmit. That advice has not changed in the meantime.

If the intent was to change some details, the submission form has an
"update" option; highlighting which details you believe have changed
via a comment helps in such cases.

Regards,

Adam

Bug#1070018: ausweisapp: Mising dependency to libqt6svg6

[Juergen Bausa]

Package: ausweisapp
Version: 2.0.1-1~bpo12+1
Severity: normal
X-Debbugs-Cc: juergen.ba...@online.de

Dear Maintainer,

I run ausweisapp backport on bookworm. However, it doesnt display an icon in 
the control panel of KDE. 
Ausweisapp2 (which is actually a slightly older version) did display an icon. 
While ausweisapp2 depended 
on libqt6svg6, ausweisapp does not. Aftre installing libqt6svg6 manually the 
icon is displayed in ausweisapp
also. So I think the dependency on libqt6svg6 is just missing in ausweisapp.

In addition it seems to me that the window of AusweisApp looks extremely clean 
(just white background).
Ausweisapp2 was much more colourful. I guess that another lib is missing for 
ausweisapp to display
the intended look.

Regards,
Jürgen


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

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

Versions of packages ausweisapp depends on:
ii  libc6   2.36-9+deb12u6
ii  libhttp-parser2.9   2.9.4-5
ii  libpcsclite11.9.9-2
ii  libqt6core6 6.4.2+dfsg-10
ii  libqt6gui6  6.4.2+dfsg-10
ii  libqt6network6  6.4.2+dfsg-10
ii  libqt6qml6  6.4.2+dfsg-1
ii  libqt6quick66.4.2+dfsg-1
ii  libqt6quickcontrols2-6  6.4.2+dfsg-1
ii  libqt6statemachine6 6.4.2-2
ii  libqt6websockets6 [qt6-websockets-abi]  6.4.2-1
ii  libqt6widgets6  6.4.2+dfsg-10
ii  libssl3 3.0.13-1~deb12u1
ii  libstdc++6  12.2.0-14
ii  libudev1252.23-1~deb12u1
ii  qml6-module-qt-labs-platform6.4.2+dfsg-1
ii  qml6-module-qtqml   6.4.2+dfsg-1
ii  qml6-module-qtqml-models6.4.2+dfsg-1
ii  qml6-module-qtqml-statemachine  6.4.2-2
ii  qml6-module-qtqml-workerscript  6.4.2+dfsg-1
ii  qml6-module-qtquick-controls6.4.2+dfsg-1
ii  qml6-module-qtquick-layouts 6.4.2+dfsg-1
ii  qml6-module-qtquick-templates   6.4.2+dfsg-1
ii  qml6-module-qtquick-window  6.4.2+dfsg-1

Versions of packages ausweisapp recommends:
ii  pcsc-tools  1.6.2-1
ii  pcscd   1.9.9-2

ausweisapp suggests no packages.

-- no debconf information

Bug#1062071: [Debian-med-packaging] Bug#1062071: genometools: NMU diff for 64-bit time_t transition

[Étienne Mollier]

Hi Steve,

NMU for genometools 1.6.5+ds-2.1 acknowledged in the VCS, with a
minor change to un-shadow Lukas Märdian experimental NMU earlier
this year.  Thanks for your work on the hairy time_t transition!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/0, please excuse my verbosity
   `-on air: Laurent Garnier - Last tribute from the 20th c…


signature.asc
Description: PGP signature

Bug#1061743: Gramps in Debian

[Dr. Tobias Quathamer]

Hi Ross,

I'd like to get gramps back into Debian, and from my (very limited) 
research it seems that gramps v5.2.1 fixed the build failure on Debian.


Are you planning to update the package? Or is there another blocker 
which I didn't spot?


Thanks for taking care of gramps in Debian!

Regards,
Tobias


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070017: google-android-installers: depends on pre-64 libraries

[Sebastian Ramacher]

Source: google-android-installers
Version: =1710437545-4
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

google-android-installers builds binary packages that depend on shared
libraries (at least libasound2) that were renamed as part of the t64
transition. Please update the dependencies accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1070016: quake4: hard-coded dependencies on pre-t64 libraries

[Sebastian Ramacher]

Package: quake4
Version: 77
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

quake4 has hard-coded dependencies on shared libraries (at least
libasound2) that were renamed as part of the t64 transition. Please
update the dependencies accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1070015: haskel-pandoc: FTBFS on armel: Couldn't match expected type: WriterState -> m a

[Sebastian Ramacher]

Source: haskell-pandoc
Version: 3.1.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=haskell-pandoc=armel=3.1.3-1%2Bb1=1713911741=0

[162 of 212] Compiling Text.Pandoc.Writers.Muse

src/Text/Pandoc/Writers/Muse.hs:85:25: error:
• Couldn't match expected type: WriterState -> m a
  with actual type: Set.Set Text
• Possible cause: ‘($)’ is applied to too many arguments
  In the expression: evalStateT $ runReaderT document env
  In an equation for ‘evalMuse’:
  evalMuse document env = evalStateT $ runReaderT document env
• Relevant bindings include
document :: Muse m a
  (bound at src/Text/Pandoc/Writers/Muse.hs:85:10)
evalMuse :: Muse m a -> WriterEnv -> WriterState -> m a
  (bound at src/Text/Pandoc/Writers/Muse.hs:85:1)
   |
85 | evalMuse document env = evalStateT $ runReaderT document env
   | 

src/Text/Pandoc/Writers/Muse.hs:85:38: error:
• Couldn't match expected type ‘WriterState’
  with actual type ‘StateT WriterState m a’
• In the second argument of ‘($)’, namely ‘runReaderT document env’
  In the expression: evalStateT $ runReaderT document env
  In an equation for ‘evalMuse’:
  evalMuse document env = evalStateT $ runReaderT document env
• Relevant bindings include
document :: Muse m a
  (bound at src/Text/Pandoc/Writers/Muse.hs:85:10)
evalMuse :: Muse m a -> WriterEnv -> WriterState -> m a
  (bound at src/Text/Pandoc/Writers/Muse.hs:85:1)
   |
85 | evalMuse document env = evalStateT $ runReaderT document env
   |  ^^^

src/Text/Pandoc/Writers/Muse.hs:233:11: error:
• Couldn't match expected type: ReaderT
  WriterEnv (StateT WriterState m) a2
  with actual type: Int -> Set.Set Text -> Bool -> WriterState
• Probable cause: ‘($)’ is applied to too few arguments
  In a stmt of a 'do' block: modify $ \ st -> st {stUseTags = False}
  In the expression:
do modify $ \ st -> st {stUseTags = False}
   hang 2 "- " <$> blockListToMuse item
  In an equation for ‘bulletListItemToMuse’:
  bulletListItemToMuse item
= do modify $ \ st -> ...
 hang 2 "- " <$> blockListToMuse item
• Relevant bindings include
bulletListItemToMuse :: [Block] -> Muse m (Doc Text)
  (bound at src/Text/Pandoc/Writers/Muse.hs:232:9)
|
233 |   modify $ \st -> st { stUseTags = False }
|   

src/Text/Pandoc/Writers/Muse.hs:233:20: error:
• Couldn't match expected type: [[Block]]
  with actual type: WriterState -> WriterState
• The lambda expression ‘\ st -> ...’ has one value argument,
but its type ‘[[Block]]’ has none
  In the second argument of ‘($)’, namely
‘\ st -> st {stUseTags = False}’
  In a stmt of a 'do' block: modify $ \ st -> st {stUseTags = False}
|
233 |   modify $ \st -> st { stUseTags = False }
|^^^

src/Text/Pandoc/Writers/Muse.hs:243:11: error:
• Couldn't match expected type: ReaderT
  WriterEnv (StateT WriterState m) a3
  with actual type: Int -> Set.Set Text -> Bool -> WriterState
• Probable cause: ‘($)’ is applied to too few arguments
  In a stmt of a 'do' block: modify $ \ st -> st {stUseTags = False}
  In the expression:
do modify $ \ st -> st {stUseTags = False}
   label' <- local
   (\ env -> env {envOneLine = True, envAfterSpace = True})
   $ inlineListToMuse' label
   let ind = offset' label'
   hang ind (nowrap label') . vcat <$> mapM descriptionToMuse defs
  In an equation for ‘definitionListItemToMuse’:
  definitionListItemToMuse (label, defs)
= do modify $ \ st -> ...
 label' <- local
 (\ env -> env {envOneLine = True, envAfterSpace = 
True})
 $ inlineListToMuse' label
 let ind = ...
 
where
offset' d
  = maximum (0 :| map T.length (T.lines $ render Nothing d))
• Relevant bindings include
definitionListItemToMuse :: ([Inline], [[Block]])
-> Muse m (Doc Text)
  (bound at src/Text/Pandoc/Writers/Muse.hs:242:9)
|
243 |   modify $ \st -> st { stUseTags = False }
|   

src/Text/Pandoc/Writers/Muse.hs:243:20: error:
• Couldn't match expected type: [[Block]]
   

Bug#1070010: Acknowledgement (dpkg: po: Fix typos)

[Peter Krefting]

Tags: patch

After sending the email I of course immediately found a few more 
typos. I also removed the date change for the header, to avoid merge 
issues.


Also available at 
https://github.com/nafmo/dpkg-l10n-sv/commit/b8167199488d92e65a88130a67c2698d55f3



From b8167199488d92e65a88130a67c2698d55f3 Mon Sep 17 00:00:00 2001

From: Peter Krefting 
Date: Sun, 28 Apr 2024 14:19:38 +0100
Subject: [PATCH] po: Fix typos

Signed-off-by: Peter Krefting 
---
 man/po/sv.po | 16 
 scripts/po/sv.po |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/man/po/sv.po b/man/po/sv.po
index bd7cfc0f7..3f0e4d6ae 100644
--- a/man/po/sv.po
+++ b/man/po/sv.po
@@ -4350,7 +4350,7 @@ msgid ""
 "This file contains the list of artifacts that are to be distributed via the "
 "B<.changes> control file."
 msgstr ""
-"Den här filen innehåller listan över artifakter som skall distribueras genom "
+"Den här filen innehåller listan över artefakter som skall distribueras genom "
 "styrfilen B<.changes>."

 #. type: textblock
@@ -4366,7 +4366,7 @@ msgstr "I I I [ 
I ]"
 #. type: textblock
 #: deb-src-files.pod
 msgid "I is the name of the artifact to distribute."
-msgstr "I är namnet på artifakten som ska distribueras."
+msgstr "I är namnet på artefakten som ska distribueras."

 #. type: textblock
 #: deb-src-files.pod
@@ -9160,7 +9160,7 @@ msgid ""
 msgstr ""
 "Flera kommandoradsflaggor (beskrivna nedan) kan användas för att hjälpa till "
 "att optimera den skapade binären (sedan dpkg 1.21.0). B: om "
-"B aktiveras kan dessa flaggor leda till binärartifakter som inte kan "
+"B aktiveras kan dessa flaggor leda till binärartefakter som inte kan "
 "reproduceras."

 #. type: =item
@@ -10979,7 +10979,7 @@ msgid ""
 "referenced in the file (since dpkg 1.17.6).  The command should take the B<."
 "changes> pathname as an argument. This command will usually be B."
 msgstr ""
-"Kommando som kontrollerar själva B<.changes>-filen och byggda artifakter som "
+"Kommando som kontrollerar själva B<.changes>-filen och byggda artefakter som "
 "refereras i filen (sedan dpkg 1.17.6). Kommandot ska ta sökvägen till B<."
 "changes> som argument. Kommandot är normalt B."

@@ -11124,7 +11124,7 @@ msgstr "B<--buildinfo-file=>I"
 msgid ""
 "Set the I for the generated B<.buildinfo> file (since dpkg 1.21.0)."
 msgstr ""
-"Ange I att använda för den skapade B<.buildinfo>-filen (sedam dpkg "
+"Ange I att använda för den skapade B<.buildinfo>-filen (sedan dpkg "
 "1.21.0)."

 #. type: =item
@@ -11244,7 +11244,7 @@ msgid ""
 "Note: For security reasons the I is best kept locked with a "
 "password."
 msgstr ""
-"Observera: Av säkerhetsskäl är det bäst att håll I låst med ett "
+"Observera: Av säkerhetsskäl är det bäst att hålla I låst med ett "
 "lösenord."

 #. type: =item
@@ -11265,7 +11265,7 @@ msgstr "B<-ui>, B<--unsigned-buildinfo>"
 #. type: textblock
 #: dpkg-buildpackage.pod
 msgid "Do not sign the B<.buildinfo> file (since dpkg 1.18.19)."
-msgstr "Signera inte B<.buildinfo>-filen (sedam dpkg 1.18.19)."
+msgstr "Signera inte B<.buildinfo>-filen (sedan dpkg 1.18.19)."

 #. type: =item
 #: dpkg-buildpackage.pod
@@ -13341,7 +13341,7 @@ msgid ""
 msgstr ""
 "B läser information från ett uppackat och byggt "
 "Debiankällkodsträd och från de filer det har genererat, och genererar en "
-"styrfil som beskriver byggmiljön och byggartifakterna (B<.buildinfo>-filen)."
+"styrfil som beskriver byggmiljön och byggartefakterna (B<.buildinfo>-filen)."

 #. type: textblock
 #: dpkg-genbuildinfo.pod
diff --git a/scripts/po/sv.po b/scripts/po/sv.po
index 7fc16ce0a..c6d34f358 100644
--- a/scripts/po/sv.po
+++ b/scripts/po/sv.po
@@ -853,7 +853,7 @@ msgstr ""

 #: scripts/dpkg-genbuildinfo.pl
 msgid "binary build with no binary artifacts found; .buildinfo is meaningless"
-msgstr "binärbygge utan binära artifakter upptäckt; .buildinfo är meningslös"
+msgstr "binärbygge utan binära artefakter upptäckt; .buildinfo är meningslös"

 #: scripts/dpkg-genbuildinfo.pl
 #, perl-format
@@ -974,7 +974,7 @@ msgstr "endast binär insändning (inkluderar ej källkod)"

 #: scripts/dpkg-genchanges.pl
 msgid "binary build with no binary artifacts found; cannot distribute"
-msgstr "binärbygge utan binära artifakter upptäckt; kan inte distribuera"
+msgstr "binärbygge utan binära artefakter upptäckt; kan inte distribuera"

 #: scripts/dpkg-genchanges.pl
 #, perl-format
--
2.39.2

Bug#1070014: libwibble: FTBFS on arm{64,el}: (7/36) Fs: ../wibble/sys/fs.test.h: 72: assertion `i.ischr()' failed;

[Sebastian Ramacher]

Source: libwibble
Version: 1.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libwibble=arm64=1.1-3%2Bb1=1714230781=0

make[5]: Entering directory '/<>/debian/build'
cd /<>/debian/build/wibble && sh -c 
"LD_LIBRARY_PATH=/<>/debian/build/wibble  
/<>/debian/build/wibble/wibble-test"
(1/36) Regexp: .. 6/6 ok
(2/36) Process: .. 2/2 ok
(3/36) Range: ... 11/11 ok
(4/36) Buffer: . 5/5 ok
(5/36) CommandlineEngine: .. 10/10 ok
(6/36) Consumer: ... 3/3 ok
(7/36) Fs: ../wibble/sys/fs.test.h: 72: assertion `i.ischr()' failed;
--> FAILED: (1/11) directoryIsdir (caught signal 6)
(7/36) Fs: . 10/11 ok

Cheers
-- 
Sebastian Ramacher

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Sebastian Ramacher]

Control: reassign -1 aptitude 0.8.13-6 

On 2024-03-07 16:34:45 +0100, Vincent Lefevre wrote:
> On 2024-03-07 16:00:35 +0100, Vincent Lefevre wrote:
> > Will install 11 packages, and remove 3 packages.
> > 8192 B of disk space will be used
> > 
> > [...]
> > [HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3
> > [...]
> > [INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1
> > [INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1
> > [INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1
> > [REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2
> > [REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2
> > [REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3
> > [...]
> > [UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3
> > [UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3
> > [UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3
> > [UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3
> > [UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3
> > [UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3
> > [UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1
> > [UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.1
> > 
> 
> Note that libmtp-common:amd64 1.1.21-3.1 was available, but for
> some unknown reason, aptitude did not propose its upgrade.

This looks like another instance of 1065626. Reassigning to aptitude.

Cheers
-- 
Sebastian Ramacher

Bug#1070013: should not ship with trixie

[Sébastien Villemot]

Source: atlas
Version: 3.10.3-14
Severity: serious
User: debian-scie...@lists.debian.org
Usertags: atlas-rm

atlas is obsolete and scheduled to be removed from Debian, ideally by the
trixie release. See the following thread on the Debian Science list for more
details:

 
https://lists.debian.org/msgid-search/4311acc16afb473599c79bd5b17a8b734c2f8d2b.ca...@debian.org

This bug prevents it from migrating back to testing.

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1070005: mirror submission for mirrors.hostico.ro

[Adam D. Barratt]

On Sun, 2024-04-28 at 13:28 +, Hostico wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirrors.hostico.ro

This is *not* a new submission. Please do not submit duplicate details
for already listed mirrors.

You were already advised two days ago to allow a few days for your
mirror to automatically return to the published listing and that you
did not need to resubmit. That advice has not changed in the meantime.

If the intent was to change some details, the submission form has an
"update" option; highlighting which details you believe have changed
via a comment helps in such cases.

Regards,

Adam

Bug#1070012: keyutils: testsuite wrongly assumes that user 0 always exists

[Aurelien Jarno]

Source: keyutils
Version: 1.6.3-3
Severity: important
Tags: patch upstream ftbfs
X-Debbugs-Cc: debian-wb-t...@lists.debian.org
Usertags: unshare

Dear maintainer,

keyutils fails to build from source when built inside a container:

| === /<>/tests/keyctl/newring/bad-args/test.out ===
| ./runtest.sh: line 13: [: 4096: unary operator expected
| +++ CHECK MAXLEN DESC FAILS WITH EDQUOT
| FAILED
| FAILED
| +++ CHECK OVERLONG DESC
| +++ CHECK EMPTY KEYRING NAME
| +++ CHECK BAD KEY ID
| make[3]: *** [Makefile:41: run] Error 1
| make[3]: Leaving directory '/<>/tests'
| make[2]: *** [Makefile:253: test] Error 2
| make[2]: Leaving directory '/<>'
| dh_auto_test: error: make -j4 test 
PATH=/<>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LD_LIBRARY_PATH=/<> SKIPROOTREQ=yes SKIPINSTALLREQ=yes returned 
exit code 2
| make[1]: *** [debian/rules:25: override_dh_auto_test] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:10: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

The "unary operator expected" issue is because maxsquota is undefined.
Indeed it is defined by looking at /proc/key-users for user 0 (root),
however this user does necessary not exists in a container. In addition
as the testsuite is run as non-root (contrary to what upstream
recommends), I believe the returned values are incorrect. At least on my
system they are quite different between root and normal users.

This simple one-liner fixes the issue, and should still work fine with
the testsuite run as root:

--- keyutils-1.6.3.orig/tests/toolbox.inc.sh
+++ keyutils-1.6.3/tests/toolbox.inc.sh
@@ -45,7 +45,7 @@ fi
 
 maxcall=$fullpage
 
-maxsquota=`grep '^ *0': /proc/key-users | sed s@.*/@@`
+maxsquota=`grep "^ *$UID": /proc/key-users | sed s@.*/@@`
 
 key_gc_delay_file="/proc/sys/kernel/keys/gc_delay"
 if [ -f $key_gc_delay_file ]; then

Regards
Aurelien

Bug#1069915: file: wrong Breaks/Replaces in libmagic-mgc

[Christoph Biedl]

Control: tags 1069915 pending

Steve Langasek wrote...

> The time_t transition automation scripts incorrectly changed the versioned
> Breaks/Replaces against old libmagic1 to point to libmagic1t64, which
> clearly never had a package version (<< 1:5.28-4~).

... and your fellow maintainer didn't notice either.

> The attached patch fixes this mistake, although since the version in
> oldoldstable is 1:5.35-4+deb10u2, perhaps you would prefer to drop the
> fields instead.

Indeed, this was needed in 2016, will remove it in the next upload.

Christoph


signature.asc
Description: PGP signature

Bug#1070011: dpkg: po: Update Swedish translation (main branch)

[Peter Krefting]

Package: dpkg
Version: 1.22.6
Tags: l10n patch
Severity: wishlist

This updates the Swedish translation to match the main branch of 
https://git.dpkg.org/git/dpkg/dpkg.git as of today. It also contains 
the fixes posted in bug 1070010, so that merge errors can be ignored.


The files can also be downloaded from 
https://github.com/nafmo/dpkg-l10n-sv/commit/af826701112dd17c2fa0abd12c97e8e6da7a2726



From af826701112dd17c2fa0abd12c97e8e6da7a2726 Mon Sep 17 00:00:00 2001

From: Peter Krefting 
Date: Sun, 28 Apr 2024 15:36:33 +0100
Subject: [PATCH] po: Update Swedish translations

Signed-off-by: Peter Krefting 
---
 man/po/sv.po | 324 +--
 po/sv.po |  34 ++---
 scripts/po/sv.po |  45 +++
 3 files changed, 146 insertions(+), 257 deletions(-)

diff --git a/man/po/sv.po b/man/po/sv.po
index 97b3b98b5..8f8032435 100644
--- a/man/po/sv.po
+++ b/man/po/sv.po
@@ -1,15 +1,14 @@
 # Translation of dpkg-man to Swedish
-# Copyright 1999-2023 Software in the Public Interest
+# Copyright 1999-2024 Software in the Public Interest
 # This file is distributed under the same license as the dpkg package.
-#
-# Peter Krefting , 1999-2023.
+# Peter Krefting , 1999-2024.
 #
 msgid ""
 msgstr ""
 "Project-Id-Version: dpkg-man 1.22.0\n"
 "Report-Msgid-Bugs-To: debian-d...@lists.debian.org\n"
 "POT-Creation-Date: 2024-03-10 20:21+0100\n"
-"PO-Revision-Date: 2024-03-08 23:45+0100\n"
+"PO-Revision-Date: 2024-04-28 15:33+0100\n"
 "Last-Translator: Peter Krefting \n"
 "Language-Team: Svenska \n"
 "Language: sv\n"
@@ -4404,7 +4403,7 @@ msgid ""
 "This file contains the list of artifacts that are to be distributed via the "
 "B<.changes> control file."
 msgstr ""
-"Den här filen innehåller listan över artifakter som skall distribueras genom "
+"Den här filen innehåller listan över artefakter som skall distribueras genom "
 "styrfilen B<.changes>."

 #. type: textblock
@@ -4420,7 +4419,7 @@ msgstr "I I I [ 
I ]"
 #. type: textblock
 #: deb-src-files.pod
 msgid "I is the name of the artifact to distribute."
-msgstr "I är namnet på artifakten som ska distribueras."
+msgstr "I är namnet på artefakten som ska distribueras."

 #. type: textblock
 #: deb-src-files.pod
@@ -9121,15 +9120,6 @@ msgstr "B<--query-features> I"

 #. type: textblock
 #: dpkg-buildflags.pod
-#, fuzzy
-#| msgid ""
-#| "Print the features enabled for a given area (since dpkg 1.16.2).  If the "
-#| "feature is handled (even if only on some architectures) as a builtin "
-#| "default by the compiler, then a B field is printed (since dpkg "
-#| "1.21.14).  The only currently recognized areas on Debian and derivatives "
-#| "are B, B, B, B and B, see "
-#| "the B section for more details.  Exits with 0 if the area "
-#| "is known otherwise exits with 1."
 msgid ""
 "Print the features enabled for a given area (since dpkg 1.16.2).  If the "
 "feature is handled (even if only on some architectures) as a builtin default "
@@ -9139,11 +9129,9 @@ msgid ""
 msgstr ""
 "Skriv ut funktioner aktiverade för ett givet område (sedan dpkg 1.16.2). Om "
 "funktionen hanteras (även om bara av några arkitekturer) som ett inbyggt "
-"förval av kompilatorn visas fältet B (sedan dpkg 1.21.14). De enda "
-"för närvarande kända områdena på Debian och dess derivat är B, "
-"B, B, B och B, se avsnittet "
-"B för fler detaljer. Avslutar med 0 om området är känt, "
-"avslutar annars med 1."
+"förval av kompilatorn visas fältet B (sedan dpkg 1.21.14). Se "
+"avsnittet B för fler detaljer om de områden som är kända "
+"för  närvarande. Avslutar med 0 om området är känt, avslutar annars med 1."

 #. type: textblock
 #: dpkg-buildflags.pod
@@ -9466,6 +9454,8 @@ msgid ""
 "Feature areas are currently vendor specific, and the ones described below "
 "are only recognized on Debian and derivatives."
 msgstr ""
+"Funktionsområden är för närvarande återförsäljarspecifika, och de som "
+"beskrivs nedan är de enda som är kända på Debian och dess derivat."

 #. type: textblock
 #: dpkg-buildflags.pod
@@ -9481,6 +9471,16 @@ msgid ""
 "specifiers are split across multiple space-separated feature area settings "
 "for the same area."
 msgstr ""
+"Varje områdesfunktion kan aktiveras och inaktiveras i miljövariablerna "
+"B och B:s områdesvärde med "
+"ändringsvärdena ”B<+>” och ”B<->”. Genom att följa den allmänna syntaxen för "
+"dessa variabler (som beskriven i L) kan flera "
+"funktionsområden anges avdelade med blanksteg, där var och en får "
+"funktionsangivelser som nödvändiga parametrar efter ett likhetstecken "
+"(”B<=>”). Funktionsangivelserna är kommaavdelade och tolkas från vänster "
+"till höger, där inställningarna inom samma funktionsangivelse överskriver de "
+"tidigare, även om funktionsangivelserna delas över flera blankstegsavdelade "
+"funktionsområdeinställningar för samma område."

 #. type: textblock
 #: dpkg-buildflags.pod
@@ -9488,18 +9488,17 @@ msgid ""
 "For example, to enable the B “pie” feature and disable the "
 "“fortify” feature 

Bug#1070010: dpkg: po: Fix typos

[Peter Krefting]

Package: dpkg
Version: 1.21.22
Tags: l10n
Severity: wishlist

I spotted a couple of typos in my Swedish translation. The following 
patch applies on top of the "bookworm" branch from 
https://git.dpkg.org/git/dpkg/dpkg.git and can also be found here: 
https://github.com/nafmo/dpkg-l10n-sv/commit/bd899d3a9026ee44ea25e2cea829f00b4e9fc795



From bd899d3a9026ee44ea25e2cea829f00b4e9fc795 Mon Sep 17 00:00:00 2001

From: Peter Krefting 
Date: Sun, 28 Apr 2024 14:19:38 +0100
Subject: [PATCH] po: Fix typos

Signed-off-by: Peter Krefting 
---
 man/po/sv.po | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/man/po/sv.po b/man/po/sv.po
index bd7cfc0f7..13a6dc6b2 100644
--- a/man/po/sv.po
+++ b/man/po/sv.po
@@ -7,7 +7,7 @@ msgstr ""
 "Project-Id-Version: dpkg-man 1.21.19\n"
 "Report-Msgid-Bugs-To: debian-d...@lists.debian.org\n"
 "POT-Creation-Date: 2023-01-10 17:46+\n"
-"PO-Revision-Date: 2023-01-28 17:19+0100\n"
+"PO-Revision-Date: 2024-04-28 14:19+0100\n"
 "Last-Translator: Peter Krefting \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -11124,7 +11124,7 @@ msgstr "B<--buildinfo-file=>I"
 msgid ""
 "Set the I for the generated B<.buildinfo> file (since dpkg 1.21.0)."
 msgstr ""
-"Ange I att använda för den skapade B<.buildinfo>-filen (sedam dpkg "
+"Ange I att använda för den skapade B<.buildinfo>-filen (sedan dpkg "
 "1.21.0)."

 #. type: =item
@@ -11244,7 +11244,7 @@ msgid ""
 "Note: For security reasons the I is best kept locked with a "
 "password."
 msgstr ""
-"Observera: Av säkerhetsskäl är det bäst att håll I låst med ett "
+"Observera: Av säkerhetsskäl är det bäst att hålla I låst med ett "
 "lösenord."

 #. type: =item
@@ -11265,7 +11265,7 @@ msgstr "B<-ui>, B<--unsigned-buildinfo>"
 #. type: textblock
 #: dpkg-buildpackage.pod
 msgid "Do not sign the B<.buildinfo> file (since dpkg 1.18.19)."
-msgstr "Signera inte B<.buildinfo>-filen (sedam dpkg 1.18.19)."
+msgstr "Signera inte B<.buildinfo>-filen (sedan dpkg 1.18.19)."

 #. type: =item
 #: dpkg-buildpackage.pod
--
2.39.2

Bug#1070009: r-cran-data.table: Update to current upstream

[Dirk Eddelbuettel]

Package: r-cran-data.table
Version: 1.14.10+dfsg-1
Severity: normal

data.table had a release 1.15.0 in January -- the first new one in three
years! -- and two follow-ups since bringing it 1.15.4 at CRAN.

Please update the Debian package to the current upstream version.

This should likely reduce some autopkgtest noise too in both data.table
itself and some of the packages depending on it.

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070008: xfce4-panel: fails to reserve space (in fluxbox)

[Francesco Poli (wintermute)]

Package: xfce4-panel
Version: 4.18.4-1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello there!
Thanks for maintaining this package in Debian.

I am trying xfce4-panel as a panel for my fluxbox based desktop:
I start it with the following command

  $ xfce4-panel --disable-wm-check --sm-client-disable &

It works well, except for one issue.
If, in the Panel Properties, I choose to "Never" automatically hide the
panel and I check "Reserve space on screen edges for the panel", I
fail to see the intended effect. I mean: maximized windows still cover
the area behind the panel.

The panel is attached to the bottom screen edge.

Please investigate and fix the bug and/or forward my bug report upstream,
as appropriate.

Thanks for your time!
Bye.



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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils   4.18.0-1+b1
ii  libatk1.0-0 2.50.0-1+b1
ii  libc6   2.37-18
ii  libcairo2   1.18.0-1+b1
ii  libdbusmenu-gtk3-4  18.10.20180917~bzr492+repack1-3.1
ii  libexo-2-0  4.18.0-1+b1
ii  libgarcon-1-0   4.18.1-1+b1
ii  libgarcon-gtk3-1-0  4.18.1-1+b1
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3
ii  libglib2.0-0t64 [libglib2.0-0]  2.78.4-7
ii  libgtk-3-0  3.24.41-1
ii  libpango-1.0-0  1.52.1+ds-1
ii  libpangocairo-1.0-0 1.52.1+ds-1
ii  libwnck-3-0 43.0-3
ii  libx11-62:1.8.7-1+b1
ii  libxext62:1.3.4-1+b1
ii  libxfce4panel-2.0-4 4.18.4-1
ii  libxfce4ui-2-0  4.18.4-1
ii  libxfce4util7   4.18.1-2+b1
ii  libxfconf-0-3   4.18.1-1+b2

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#1070007: sbuild/unshare: writing to /dev/stdout denied

[Aurelien Jarno]

Package: sbuild
Version: 0.85.8
Severity: normal


When running sbuild in unshare chroot mode, it is not possible to write
to /dev/stdout:

| echo test > /dev/stdout
| sh: 1: cannot create /dev/stdout: Permission denied

This is the reason of the FTBFS of at least clisp and supervisor when
using the unshare chroot mode of sbuild.

Bug#1070006: debian-cd: daily arm64 netinst image: GRUB not started in graphical mode

[Roland Clobus]

Package: debian-cd
Version: 3.2.1
Severity: minor
User: debian...@lists.debian.org
Usertags: openqa

Hello maintainers of the netinst image,

The issue:
As seen on openQA [1], the GRUB menu for the arm64 netinst image (taken 
from the daily builds [2]) does not use the graphical mode, but text 
mode instead.


Some sub-menus assume that the graphical mode is active, but issue an 
error message: 'error: no video mode activated.' (e.g. 'Accessible dark 
contrast installer menu...')


Expected:
GRUB uses the graphical version of the boot menu.


During the miniDebCamp 2024 in Hamburg, ema showed that (at least for 
the live-build images) GRUB is able to use the graphical mode correctly.
As a side note, the graphical installer also shows properly, so there 
appears to be no problem in using the graphical mode.


With kind regards,
Roland Clobus

---
[1] https://openqa.debian.net/tests/25
[2] 
https://get.debian.org/images/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065637: pmbootstrap: postmarketOS project broke compatibility with v2.1.0

[Vivek K J]

Hey,

pmbootstrap 2.2.1 is now available in unstable and testing.

Closing this bug report
-- 
Regards,

Vivek K J
Debian Maintainer
---
 .''`.
Personal Website:  https://vivekkj.in   : :'  :
GPG Key: D017 9263 E202 0E40 7157  4073 A5FF 4BB3 EA53 C5DF `. `'`
  `-

OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070005: mirror submission for mirrors.hostico.ro

[Hostico]

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

Submission-Type: new
Site: mirrors.hostico.ro
Archive-architecture: amd64
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Hostico 
Country: RO Romania
Location: Bucharest
Sponsor: Hostico https://hostico.ro




Trace Url: http://mirrors.hostico.ro/debian/project/trace/
Trace Url: http://mirrors.hostico.ro/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.hostico.ro/debian/project/trace/mirrors.hostico.ro

Bug#491295: latencytop can run only on i386 and amd64 only, not any

[Boyuan Yang]

Control: tags -1 +wontfix

On Fri, 07 Aug 2009 10:54:14 +0200 "Giacomo A. Catenazzi"
 wrote:
> The new kernels support also other architectures.
> 
>  From latest kernel sources:
> 
> arch/powerpc/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> arch/sparc/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> arch/arm/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> arch/sh/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> arch/s390/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> arch/x86/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> arch/parisc/Kconfig:config HAVE_LATENCYTOP_SUPPORT
> 
> unlike powertop, latencytop don't requires hardware support,
> but it collects statistics from scheduler, so i expect
> newer kernel will support more architectures.
> 
> So I'll retitle the bug:
> latencytop can run only on Linux

The latencytop upstream designed the tool to be linux-only, which
is expected. Obviously it cannot be ported to other OS kernels.
As a result, marking this bug as wontfix. I will close it in the
next upload marking the package to be linux-any.

Thanks,
Boyuan Yang


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

Bug#1070004: ruby-sidekiq: CVE-2024-32887

[Salvatore Bonaccorso]

Package: ruby-sidekiq
Version: 7.2.1+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

The following vulnerability was published for ruby-sidekiq.

It only affects the experimental version, as the issue was introduced
in 7.2.0 an fixed upstream in 7.2.4. Should not land into unstable, so
filling with RC severity.

CVE-2024-32887[0]:
| Sidekiq is simple, efficient background processing for Ruby. Sidekiq
| is reflected XSS vulnerability. The value of substr parameter is
| reflected in the response without any encoding, allowing an attacker
| to inject Javascript code into the response of the application.  An
| attacker could exploit it to target users of the Sidekiq Web UI.
| Moreover, if other applications are deployed on the same domain or
| website as Sidekiq, users of those applications could also be
| affected, leading to a broader scope of compromise. Potentially
| compromising their accounts, forcing the users to perform sensitive
| actions, stealing sensitive data, performing CORS attacks,
| defacement of the web application, etc. This issue has been patched
| in version 7.2.4.


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-2024-32887
https://www.cve.org/CVERecord?id=CVE-2024-32887
[1] https://github.com/sidekiq/sidekiq/security/advisories/GHSA-q655-3pj8-9fxq

Regards,
Salvatore

Bug#1070003: sbuild/unshare: bind mounting individual /dev entries causes inconsistent readdir results

[Aurelien Jarno]

Package: sbuild
Version: 0.85.7
Severity: normal

When running sbuild in unshare chroot mode, /dev is provided by creating
all the entries as regular files, and then the entries from the host
/dev are bind-mounted to the container. This causes readdir(), which
maps to the getdents64 syscall, to return the underlying files in the
/dev directory instead of the bind-mounted files. Although the names are
correct, the d_ino, d_off and d_type values are incorrect. For instance
/dev/null is reported as regular file instead of a character device.

This can be demonstrated by this simple C code:

| #include 
| #include 
| #include 
| 
| int main()
| {
|   struct dirent *entry;
|   DIR *dp;
| 
|   dp = opendir("/dev");
|   if (dp == NULL) { 
| perror("opendir");
| return -1;
|   }
| 
|   while((entry = readdir(dp))) {
| printf("%s: type %d\n", entry->d_name, entry->d_type);
|   }
| 
|   closedir(dp);
| 
|   return 0;
| }

This is the reason of the FTBFS of at least glibc and libwibble when
using the unshare chroot mode of sbuild.

That said, this seems to be the standard way to provide /dev entries on
a non-privileged user namespace, for instance podman has the same issue.
Docker does not have the issue, but on the other hand requires root.

There might be no way to fix the issue, in that case we should consider
this a limitation of the unshare chroot mode, document it, and add
debian specific workarounds to the affected packages.

Bug#1069808: perftest: please add support for loong64

[wuruilong]

在 2024/4/25 下午7:42, Tzafrir Cohen 写道:

Hi,

Looks good. I guess that it works (I don't have the hardware to test it.
But it won't break any other arch).

Any chance you could post this fix to Upstream?

   https://github.com/linux-rdma/perftest

If not, I'll forward it.

It should get accepted, I guess, like the hppa support:

   https://github.com/linux-rdma/perftest/pull/261

A new upstream release is expected in July (roughly in time for
DebConf).

-- Tzafrir


Hi,

Thank you for your suggestion, upstream has been submitted and merged at 
the following link: https://github.com/linux-rdma/perftest/pull/261.


I hope you will merge this patch.

-- wuruilong

Bug#1070002: rust-alsa FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: rust-alsa
Version: 0.8.1-3
Severity: serious
Tags: ftbfs
Control: affects -1 src:rust-cpal

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/rust-alsa.html
https://buildd.debian.org/status/fetch.php?pkg=rust-cpal=armhf=0.15.2-3%2Bb1=1714250098=0

...
error: cannot construct `timespec` with struct literal syntax due to private 
fields
--> /usr/share/cargo/registry/alsa-0.8.1/src/pcm.rs:1113:21
 |
1113 | let mut h = timespec {tv_sec: 0, tv_nsec: 0};
 | 
 |
 = note: ... and other private field `__pad` that was not provided

error: cannot construct `timespec` with struct literal syntax due to private 
fields
--> /usr/share/cargo/registry/alsa-0.8.1/src/pcm.rs:1119:21
 |
1119 | let mut h = timespec {tv_sec: 0, tv_nsec: 0};
 | 
 |
 = note: ... and other private field `__pad` that was not provided

error: cannot construct `timespec` with struct literal syntax due to private 
fields
--> /usr/share/cargo/registry/alsa-0.8.1/src/pcm.rs:1125:21
 |
1125 | let mut h = timespec {tv_sec: 0, tv_nsec: 0};
 | 
 |
 = note: ... and other private field `__pad` that was not provided

error: could not compile `alsa` due to 3 previous errors
...

Bug#1038882: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Martin-Éric Racine]

ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > > I hereby propose bin:dhcpcd-base:
> > >
> > > 1) already supported by ifupdown.
> > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> > > separation.
> > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > configure both stacks.
> > >
> >
> > why not switch to systemd-networkd + networkmanager for gui installs?
>
> NM already is pulled by most desktop environments.
>
> Meanwhile a bare minimal system needs a non-GUI solution and swaping
> which DHCP client gets pulled by ifupdown is the simplest, least
> disruptive way of accomplishing this.

This bug is almost one year old. Are we going ahead with this or not?

Martin-Éric

Bug#1070001: rust-net2 FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: rust-net2
Version: 0.2.37-1
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/fetch.php?pkg=rust-net2=armhf=0.2.37-1%2Bb1=1714277125=0

...
error[E0308]: mismatched types
   --> src/ext.rs:902:22
|
902 | tv_usec: (d % 1000) as suseconds_t,
|  ^ expected `i64`, found `i32`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `net2` due to previous error
...

Bug#1070000: rust-time-0.1 FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: rust-time-0.1
Version: 0.1.44-2
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/fetch.php?pkg=rust-time-0.1=armhf=0.1.44-2%2Bb1=1714295931=0

...
error: cannot construct `timespec` with struct literal syntax due to private 
fields
   --> src/sys.rs:521:26
|
521 | let mut tv = libc::timespec { tv_sec: 0, tv_nsec: 0 };
|  ^^
|
= note: ... and other private field `__pad` that was not provided

error: cannot construct `timespec` with struct literal syntax due to private 
fields
   --> src/sys.rs:527:26
|
527 | let mut ts = libc::timespec { tv_sec: 0, tv_nsec: 0 };
|  ^^
|
= note: ... and other private field `__pad` that was not provided

error: cannot construct `timespec` with struct literal syntax due to private 
fields
   --> src/sys.rs:555:24
|
555 | t: libc::timespec {
|^^
|
= note: ... and other private field `__pad` that was not provided

error: could not compile `time` due to 3 previous errors
...

Bug#1069999: rust-unix-socket FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: rust-unix-socket
Version: 0.5.0-2
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/fetch.php?pkg=rust-unix-socket=armhf=0.5.0-2%2Bb1=1714298139=0

...
error[E0308]: mismatched types
   --> src/lib.rs:122:30
|
122 | tv_usec: usecs,
|  ^ expected `i64`, found `i32`

For more information about this error, try `rustc --explain E0308`.
warning: `unix_socket` (lib) generated 31 warnings
error: could not compile `unix_socket` due to previous error; 31 warnings 
emitted
...

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sat, Apr 20, 2024 at 10:30:20AM +0100, Alberto Bertogli wrote:

On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:

I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.


Oohhh this is good to know, I didn't know that was a viable option.  
Thank you for the suggestion!


I will try to reproduce it this way, I'll let you know how it goes.


I managed to reproduce this the way you suggested, on a Hetzner VM and 
an armel chroot.


The problem seems to be that some of the functions that have 64-bit 
variants (e.g. pread64, pwrite64) have an assembler name declared for 
the regular variant in the header; while other platforms don't do that 
and have the two functions declared separately.


https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html

For example, this is the declaration of pread and pwrite in a 
post-preprocessed file, diff between x86_64 (without the bug, '-') and 
armel (with the bug, '+'):


```
@@ -1068,18 +,14 @@
 
 extern ssize_t write (int __fd, const void *__buf, size_t __n)

 __attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
-__off_t __offset)
-__attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pread64")
 
 
+__attribute__ ((__access__ (__write_only__, 2, 3)));

+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__ 
("" "pwrite64")
 
 
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,

- __off_t __offset)
 __attribute__ ((__access__ (__read_only__, 2, 3)));
 # 422 "/usr/include/unistd.h" 3 4
 extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```

That's why it's the assembler (and not linking) stage that's 
complaining, because that means both functions end up named as the 
64-bit variant. This can be seen in the assembly file. Continuing to use 
pread/pread64 as an example, there is no definition for pread(), only 
pread64() twice: once for pread and one for pread64.


It's tricky to support this in a generic way, because it's difficult to 
detect this is even happening, as the assembler name operates at a 
compiler level so we can't just undo it.


I'll keep trying to find a viable workaround for this.

Thanks,
Alberto

Bug#1069996: d2x-rebirth: Static audio during audio playback with SDL_Mixer in Descent 2

[James Carthew]

I've build the upstream version of the package and can confirm that this
issue has been fixed upstream. Can we cut a new package for Debian Trixie?

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Sean Whitton]

Hello,

On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:

> From afac52fa956087eb737c123682f634fc739c7e20 Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Tue, 27 Feb 2024 23:37:06 +0100
> Subject: [PATCH] =?UTF-8?q?Add=20references=20to=20=C2=ABdpkg-buildtree=20?=
>  =?UTF-8?q?clean=C2=BB=20for=20debian/{substvars,files}?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> These files are generated by dpkg tools (and in some cases by helpers),
> but the maintainer was responsible for cleaning them up. There is now
> a new command that will take care of cleaning these (and any other
> future) files that the dpkg suite might end up generating, making their
> introduction easier as the responsibility to remove them shifts back
> where it belongs.
> ---
>  policy/ch-source.rst | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 4307e89..2fb05cd 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -685,7 +685,7 @@ variables are also available.
>
>  The ``debian/substvars`` file is usually generated and modified
>  dynamically by ``debian/rules`` targets, in which case it must be
> -removed by the ``clean`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
>
>  See :manpage:`deb-substvars(5)` for full details about source variable
>  substitutions, including the format of ``debian/substvars``.
> @@ -725,8 +725,9 @@ building packages to record which files are being 
> generated.
>
>  It should not exist in a shipped source package, and so it (and any
>  backup files or temporary files such as ``files.new``)  [#]_ should be
> -removed by the ``clean`` target. It may also be wise to ensure a fresh
> -start by emptying or removing it at the start of the ``binary`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
> +It may also be wise to ensure a fresh start by emptying or removing it at the
> +start of the ``binary`` target.
>
>  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
>  to ``debian/files`` for the ``.deb`` file that will be created when

Seconded.

It seems prudent to get reference to this tool into Policy as soon as
possible, even if we're not yet sure how it relates to debhelper.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069998: rust-datetime FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: rust-datetime
Version: 0.5.2-5
Severity: serious
Tags: ftbfs trixie sid
Control: affects -1 src:rust-zoneinfo-compiled

https://buildd.debian.org/status/fetch.php?pkg=rust-datetime=armhf=0.5.2-5%2Bb1=1714252645=0

...
error: cannot construct `timespec` with struct literal syntax due to private 
fields
  --> src/system.rs:74:18
   |
74 | let mut tv = libc::timespec { tv_sec: 0, tv_nsec: 0 };
   |  ^^
   |
   = note: ... and other private field `__pad` that was not provided
...

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Sean Whitton]

Hello,

On Sat 20 Apr 2024 at 09:00pm +02, Guillem Jover wrote:

> Hi!
>
> On Thu, 2024-03-28 at 09:58:29 +0800, Sean Whitton wrote:
>> On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:
>> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> > index 4307e89..2fb05cd 100644
>> > --- a/policy/ch-source.rst
>> > +++ b/policy/ch-source.rst
>> > @@ -685,7 +685,7 @@ variables are also available.
>> >
>> >  The ``debian/substvars`` file is usually generated and modified
>> >  dynamically by ``debian/rules`` targets, in which case it must be
>> > -removed by the ``clean`` target.
>> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
>> > clean``).
>> >
>> >  See :manpage:`deb-substvars(5)` for full details about source variable
>> >  substitutions, including the format of ``debian/substvars``.
>> > @@ -725,8 +725,9 @@ building packages to record which files are being 
>> > generated.
>> >
>> >  It should not exist in a shipped source package, and so it (and any
>> >  backup files or temporary files such as ``files.new``)  [#]_ should be
>> > -removed by the ``clean`` target. It may also be wise to ensure a fresh
>> > -start by emptying or removing it at the start of the ``binary`` target.
>> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
>> > clean``).
>> > +It may also be wise to ensure a fresh start by emptying or removing it at 
>> > the
>> > +start of the ``binary`` target.
>> >
>> >  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
>> >  to ``debian/files`` for the ``.deb`` file that will be created when
>>
>> Instead of "It may also be wise ..." can you use one of the sets of
>> magic words from Policy 1.1, please?
>
> This text was already part of policy and the proposed patch did not
> really touch it, except for wrapping it into a new line. I think
> modifying it feels a bit out-of-scope for this request? But if you
> think it's relevant, and the sentence should be improved as part of
> this, then I'll try to provide some wording. :)

Ah yes, sorry, that is indeed out-of-scope.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067821: bookworm-pu: package nvidia-graphics-drivers/535.161.08-2~deb12u1

[Andreas Beckmann]

Control: retitle -1 bookworm-pu: package 
nvidia-graphics-drivers/535.161.08-2~deb12u1

On 29/03/2024 19.40, Adam D. Barratt wrote:

On Thu, 2024-03-28 at 18:40 +0100, Andreas Beckmann wrote:

The whole nvidia stack has now been uploaded,
src:nvidia-graphics-drivers is sitting in NEW.


It's now in stable-new.


Please reject nvidia-graphics-drivers/535.161.08-1~deb12u1, nvidia-
driver-full is uninstallable on ppc64el (but that was hidden by the
other t64 transition blockers).


We have a bit of an issue in terms of accepting / shipping the 535
bookworm stack, however. The upload of 535 to unstable is blocked from


Looks like there is now some progress and if 535.161.08-2 (just
uploaded) migrates to testing, we can revisit this pu stack.

Incremental debdiff 535.161.08-1..535.161.08-2 attached.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 7e6f2e315..cf2d8c680 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+nvidia-graphics-drivers (535.161.08-2) unstable; urgency=medium
+
+  * nvidia-driver-full: libnvidia-fbc1 and libnvidia-rtcore are not available
+on ppc64el.
+  * Add autopkgtest testing the installation of the full driver suite.
+
+ -- Andreas Beckmann   Sun, 28 Apr 2024 13:28:15 +0200
+
 nvidia-graphics-drivers (535.161.08-1) unstable; urgency=medium
 
   * New upstream Tesla branch release 535.161.08 (2024-03-18).
diff --git a/debian/control b/debian/control
index c01198f98..538524ed7 100644
--- a/debian/control
+++ b/debian/control
@@ -80,10 +80,10 @@ Depends:
  lib${nvidia}-encode1 (= ${binary:Version}),
  ${nvidia}-vulkan-icd (= ${binary:Version}),
  lib${nvidia}-allocator1 (= ${binary:Version}),
- lib${nvidia}-rtcore (= ${binary:Version}),
+ lib${nvidia}-rtcore (= ${binary:Version}) [amd64 ${arch:arm64}],
  ${nvidia}-smi (= ${binary:Version}),
  lib${nvidia-if-variant}cudadebugger1 (= ${binary:Version}),
- lib${nvidia}-fbc1 (= ${binary:Version}),
+ lib${nvidia}-fbc1 (= ${binary:Version}) [amd64 ${arch:arm64}],
  lib${nvidia-if-variant}nvoptix1 (= ${binary:Version}) [amd64 ${arch:arm64}],
  lib${nvidia}-opticalflow1 (= ${binary:Version}),
  lib${nvidia}-ngx1 (= ${binary:Version}) [amd64],
diff --git a/debian/control.in b/debian/control.in
index 9c19a6c02..bc9f61dcd 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -79,10 +79,10 @@ Depends:
  lib${nvidia}-encode1 (= ${binary:Version}),
  ${nvidia}-vulkan-icd (= ${binary:Version}),
  lib${nvidia}-allocator1 (= ${binary:Version}),
- lib${nvidia}-rtcore (= ${binary:Version}),
+ lib${nvidia}-rtcore (= ${binary:Version}) [amd64 ${arch:arm64}],
  ${nvidia}-smi (= ${binary:Version}),
  lib${nvidia-if-variant}cudadebugger1 (= ${binary:Version}),
- lib${nvidia}-fbc1 (= ${binary:Version}),
+ lib${nvidia}-fbc1 (= ${binary:Version}) [amd64 ${arch:arm64}],
  lib${nvidia-if-variant}nvoptix1 (= ${binary:Version}) [amd64 ${arch:arm64}],
  lib${nvidia}-opticalflow1 (= ${binary:Version}),
  lib${nvidia}-ngx1 (= ${binary:Version}) [amd64],
diff --git a/debian/control.md5sum b/debian/control.md5sum
index 361efa496..b9e101228 100644
--- a/debian/control.md5sum
+++ b/debian/control.md5sum
@@ -1,5 +1,5 @@
-bc10d759d2eb2349dc7e680acf66292a  debian/control
-c7413097130730ca439b199809dd468c  debian/control.in
+2157da7b2be9063b142d96b9c5fdb963  debian/control
+0bfa7c4c3f1e01a3629ab367ce3d343c  debian/control.in
 8489c83cfe0171c9de6d052c01a6d19b  debian/gen-control.pl
 f874047700ddfc1543f70d430f0f8110  debian/rules
 7f525d302e0e76e1de1f4e6cce0efbe8  debian/rules.defs
diff --git a/debian/tests/control b/debian/tests/control
index a53e52825..e83896aef 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -18,3 +18,12 @@ Depends:
  nvidia-detect,
 Restrictions:
  superficial,
+
+Test-Command: true
+Features: test-name=full-install
+Architecture: amd64 arm64 ppc64el
+Depends:
+ nvidia-driver-full,
+ linux-headers-generic,
+Restrictions:
+ superficial,
diff --git a/debian/tests/control.in b/debian/tests/control.in
index c8184ac22..d771e7694 100644
--- a/debian/tests/control.in
+++ b/debian/tests/control.in
@@ -18,3 +18,12 @@ Depends:
  nvidia-detect,
 Restrictions:
  superficial,
+
+Test-Command: true
+Features: test-name=full-install
+Architecture: #AUTOPKGTEST_ARCH_LIST#
+Depends:
+ #NVIDIA#-driver-full,
+ linux-headers-generic,
+Restrictions:
+ superficial,

Bug#1069997: nginx: NGX_MODULE_SIGNATURE has changed on 32-bit t64 architectures, but the ${nginx:abi} substvar has not

[Andreas Beckmann]

Source: nginx
Version: 1.24.0-2
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Sebastian Ramacher , Steve Langasek 

Control: block 1069482 with -1

While looking into #1069482 (libnginx-mod-http-lua: FTBFS on armhf) I
noticed that nginx has a NGX_MODULE_SIGNATURE string which is required
to match between server and modules. This string has been changed by the
t64 transition, but the substvar ${nginx:abi} describing the abi for
package relationships has not been changed.

nginx_1.24.0-2+b1_armhf.deb -> 4,4,4,0001011100
nginx_1.24.0-2+b2_armhf.deb -> 4,4,8,0001011100
(I used 'strings usr/sbin/nginx | grep 111' to get them from the
binaries)

NGX_MODULE_SIGNATURE is defined in src/core/ngx_module.h and starts with
ngx_value(NGX_PTR_SIZE) ","   \
ngx_value(NGX_SIG_ATOMIC_T_SIZE) ","  \
ngx_value(NGX_TIME_T_SIZE) ","

I'd suggest bumping the substvar in debian/libnginx-mod.abisubstvars to
e.g. nginx-abi-1.24.0-1t64 and rebuilding all modules. Maybe that's
already sufficient for fixing #1069482.


Andreas

PS: could something automatically generated from $(DEB_VERSION_UPSTREAM)
and NGX_MODULE_SIGNATURE (s/,/-/g) (and maybe an optional suffix) be
used for the abi substvar?

Bug#1069996: d2x-rebirth: Static audio during audio playback with SDL_Mixer in Descent 2

[James Carthew]

Package: d2x-rebirth
Version: 0.58.1-1.3
Severity: important
X-Debbugs-Cc: jcart...@gmail.com

Dear Maintainer,

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

Installed D2X-XL in /usr/share/games/d2x-rebirth
Ran the game normally, get static sounds during mve playback and after each
sound effect plays ingame. E.g when shooting weapons. Audio should play without
static noise.
Using Pipewire for audio.

This looks like it might be fixed in upstream. The Debian packages are out of
date. 0.61 is the current version in the upstream github repository.


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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 d2x-rebirth depends on:
ii  libc6   2.37-18
ii  libgl1  1.7.0-1+b1
ii  libglu1-mesa [libglu1]  9.0.2-1.1+b1
ii  libphysfs1  3.0.2-6+b1
ii  libsdl-mixer1.2 1.2.12-17+b3
ii  libsdl1.2debian 1.2.68-2

Versions of packages d2x-rebirth recommends:
ii  freepats  20060219-4
ii  timidity  2.14.0-8.1

d2x-rebirth suggests no packages.

-- no debconf information

Bug#1069995: VCSWatch: underlaying system doesn't support TLS1.3

[Daniel Baumann]

Package: qa.debian.org
Severity: wishlist

Hi,

I've switched off TLS1.2 on my git server (to see what would be 
brocken), one of them is VCSWatch:


Error: fatal: unable to access 
'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/': 
gnutls_handshake() failed: Error in protocol version


It would be nice if the qa.debian.org system (I assume) could be updated 
to bullseye or newer which supports TLS1.3.


Regards,
Daniel