Bug#1016957: kbd-chooser: please add support for riscv64

[Paul Gevers]

Hi Bastian,

On Sat, 9 Sep 2023 19:03:07 +0200 Bastian Germann  wrote:

Control: severity -1 serious


Can you please elaborate? I'm not seeing anything serious in this bug 
report.



On Wed, 10 Aug 2022 21:42:34 +0200 Holger Wansing  wrote:
> kbd-chooser is no longer in use, I think.
> Or am I missing something?

I am raising severity to serious then so that it can be autoremoved from 
testing.


This package is a key package (because of debian-installer), so it can't 
be autoremoved.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069330: Control: retitle 1069330 'ITP: apt-transport-oci -- OCI transport plugin for apt-get (i.e., apt-get over ghcr.io)'

[Jianfeng Liu]

Control: retitle 1069330 ITP: apt-transport-oci -- OCI transport
plugin for apt-get (i.e., apt-get over ghcr.io)

Bug#1069330: Control: retitle 1069330 ITP: apt-transport-oci -- OCI transport plugin for apt-get (i.e., apt-get over ghcr.io)

[Jianfeng Liu]

Control: retitle 1069330 ITP: apt-transport-oci -- OCI transport
plugin for apt-get (i.e., apt-get over ghcr.io)

Bug#1070348: pipewire: pipewire-pulse: warningin syslog every second for snap_get_audio_permissions

[Michael Welsh Duggan]

Package: pipewire
Version: 1.0.5-1+b3
Severity: normal
X-Debbugs-Cc: none, Michael Welsh Duggan 

Dear Maintainer,

After updating my linux kernel to 6.7.12-1, I keep getting the following
message in my syslog, once a second:

pipewire-pulse[]: default: snap_get_audio_permissions: kernel lacks
'fine grained unix mediation'; snap audio permissions won't be honored.

It seems to work despite the messages, though there was a massive
timeout the first time I tried to use the microphone after the reboot.
This message from the ubuntu lists is a little old, but might be urbane:

https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2051454

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

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

Versions of packages pipewire depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66
ii  libpipewire-0.3-modules  1.0.5-1+b3
ii  pipewire-bin 1.0.5-1+b3

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#1070347: GitHub not mentioned in documentation directory

[Dan Jacobson]

Package: bash-completion
Version: 1:2.11-8

In https://github.com/scop/bash-completion/issues/1175
we see GitHub is missing from Debian's bash-completion docs.

Bug#1067946: dietlibc: Includes non-free Sun RPC

[Thorsten Glaser]

Hi Bastian,

>I have already informed upstream about it.

did you do that on a mailing list? Do you have a link?
What did upstream say?

Still unconvinced,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………

Bug#1036908: expect: Broken use of \c in man page

[Marco d'Itri]

On May 29, Helge Kreutzmann  wrote:

> The usage of \c is in mkpasswd(1) is incorrect. It fails when trying
> to use po4a to provide translations of the man pages. Im currently
> "patching around this" in manpages-l10n.
> 
> For a full explanation of the problem (the man page is different, but
> the problem is the same) see Debian #1036826 and the explanations by
I have read #1036826 and tested multiple proposed solutions but I could 
not managed to reproduce the original output.
Are you able to propose a patch which does not change the generated man 
page?

> Bjarni, especially in message #25.
That solution has been rejected by Branden.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1070346: how to activate the module "pcspkr" (PC speaker)

[Bjarni Ingi Gislason]

Package: beep
Version: 1.4.9-1.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   No sound with "beep -e $(tty)"

-.-

  I (as root) do not get any sound from

1) tput bel

2) beep -e $(tty) 

[root503]:~# beep --debug -e $(tty)

beep: Verbose: evdev driver_detect 0x563df6280700 /dev/tty2
beep: Verbose: b-lib: opened /dev/tty2 as 3
beep: Verbose: evdev: 3 does not implement EV_SND API
beep: Verbose: console driver_detect 0x563df62806a0 /dev/tty2
beep: Verbose: b-lib: opened /dev/tty2 as 4
beep: Verbose: beep: using driver 0x563df62806a0 (name=console, fd=4, 
dev=/dev/tty2)
beep: Verbose: 1 times 200 ms beeps (100 ms delay between, 0 ms delay after) @ 
440 Hz
beep: Verbose: console driver_begin_tone 0x563df62806a0 440
beep: Verbose: console driver_end_tone 0x563df62806a0
beep: Verbose: console driver_end_tone 0x563df62806a0
beep: Verbose: console driver_fini 0x563df62806a0

-.-

lsmod:

pcspkr 12288  0

-.-

/etc/modprobe.d/pcspkr-beep.conf contains

alias platform:pcspkr pcspkr

-.-

[root565]:/etc/modprobe.d# modprobe --first-time pcspkr
modprobe: ERROR: could not insert 'pcspkr': Module already in
kernel

-.-

grep -F pcspkr /lib/modules/* :

6.6.15-amd64/modules.dep:kernel/drivers/input/misc/pcspkr.ko.xz:
6.6.15-amd64/modules.order:kernel/drivers/input/misc/pcspkr.ko
6.6.15-amd64/modules.alias:alias platform:pcspkr pcspkr
6.7.12-amd64/modules.dep:kernel/drivers/input/misc/pcspkr.ko.xz:
6.7.12-amd64/modules.order:kernel/drivers/input/misc/pcspkr.ko
6.7.12-amd64/modules.alias:alias platform:pcspkr pcspkr

-.-.

>From /boot:

config-6.6.15-amd64
config-6.7.12-amd64
grub
initrd.img-6.6.15-amd64
initrd.img-6.7.12-amd64
System.map-6.6.15-amd64
System.map-6.7.12-amd64
vmlinuz-6.6.15-amd64
vmlinuz-6.7.12-amd64

-.-

alsamixer -c 1 shows for "beep"

Card: HDA ATI SB
Chip: Realtek ALC C887-VD

Beep [dB gain: 4.50, 4.50]

-.-

  There is no '/proc/sys/dev/input' directory.

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages beep depends on:
ii  libc6  2.37-19

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Bug#1070345: kodi-data: Symlink for Roboto font is still for hinted version

[Christer Mjellem Strand]

Package: kodi-data
Version: 2:20.5+dfsg-2
Severity: minor

Dear Maintainer,

Following #922950, the dependency was updated from fonts-roboto-hinted to 
fonts-roboto-unhinted.
However, the symlink using it was not updated accordingly:

% ls -la /usr/share/kodi/addons/skin.estuary/fonts/Roboto-Thin.ttf 
lrwxrwxrwx 1 root root 56 Mar 31 20:36 
/usr/share/kodi/addons/skin.estuary/fonts/Roboto-Thin.ttf -> 
../../../../fonts/truetype/roboto/hinted/Roboto-Thin.ttf

Please also update this accordingly from hinted to unhinted, so it matches.

Thanks.

Bug#1036382: dillo: doesn't recognize XHTML 1.1 as HTML

[Rodrigo Arias]

Hi,

On Sun, May 21, 2023 at 11:14:58AM +0200, José Luis González wrote:

On Sun, 21 May 2023 05:34:16 +0200
José Luis González  wrote:


All I ask you is to confirm the bug was not coming from a
Debian patch and forward the full report to upstream. That's all.


Sorry Andrey, I mistook you for the maintainer. You can overlook this,
obviously :)



Thanks for the report José, both bugs have been fixed in PR 140[1].

[1]:https://github.com/dillo-browser/dillo/pull/140

It will be included in Dillo 3.1.0 release.

Regarding the meta tag:





The content type "text/xhtml" have never been standardized and
"application/xhtml+xml" should be used instead (Doxygen still uses it).
There was already a quirk to correct this problem, which was not working
well but is fixed now. If you want to look into the details, take a look
at the patches[2] and/or this thread[3].

[2]:https://patch-diff.githubusercontent.com/raw/dillo-browser/dillo/pull/140.patch
[3]:https://lists.mailman3.com/hyperkitty/list/dillo-...@mailman3.com/thread/7GJ4AAMFFPEHOIYEOH4NHVMSXMJDFYXG/?noscript

Best,
Rodrigo.

Bug#1070344: gmsh: please enable CGNS support

[Francesco Poli (wintermute)]

Package: gmsh
Version: 4.12.2+ds1-1
Severity: wishlist
X-Debbugs-Cc: invernom...@paranoici.org


Hello and thanks for maintaining this package in Debian!

I noticed that, if I start it with:

  $ gmsh -format cgns

in order to select CGNS as output mesh format, and then I try to
click on 'save', gmsh tells me that it was compiled without CGSN
support.

Could you please enable CGNS (by adding appropriate Build-Dependencies
and passing the appropriate configure flag, of course)?

Thanks for your time and dedication!


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (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 gmsh depends on:
ii  libc6   2.37-18
ii  libgmsh4.12t64  4.12.2+ds1-1

Versions of packages gmsh recommends:
ii  gmsh-doc  4.12.2+ds1-1

gmsh suggests no packages.

-- no debconf information

Bug#1070343: openfortivpn: stopped working after today's upgrade in Debian testing

[Francesco Poli (wintermute)]

Package: openfortivpn
Version: 1.22.0-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: invernom...@paranoici.org

Hello!
Thanks a lot for maintaining this useful package in Debian.
I use it often to connect to a Fortinet VPN.

Unfortunately, after today's (many) upgrades in Debian testing,
it stopped working (same configuration file that has worked fine
up to yesterday).

Now it does:

  # openfortivpn -c /etc/openfortivpn/MYNETWORK
  VPN account password:
  INFO:   Connected to gateway.
  INFO:   Authenticated.
  INFO:   Remote gateway has allocated a VPN.
  Using interface ppp0
  Connect: ppp0 <--> /dev/pts/7
  INFO:   Got addresses: [192.168.240.2], ns [X.Y.Z.A, X.Y.Z.B]
  INFO:   Negotiation complete.
  INFO:   Negotiation complete.
  Peer refused to agree to his IP address
  Connect time 0.1 minutes.
  Sent 1101 bytes, received 1081 bytes.

and remains stuck, seemingly doing nothing, until I hit [Ctrl+C]:

  ^CINFO:   Cancelling threads...
  INFO:   Cleanup, joining threads...
  Hangup (SIGHUP)
  Modem hangup
  Connection terminated.
  INFO:   pppd: The link was terminated by the modem hanging up.
  INFO:   Terminated pppd.
  INFO:   Closed connection to gateway.
  INFO:   Logged out.

I tried to downgrade to openfortivpn/1.21.0-2, but this didn't help.
I cannot understand what's wrong.
Could it be the ugrade of libc6?

  [UPGRADE] libc6:amd64 2.37-18 -> 2.37-19
  [UPGRADE] libc6-dbg:amd64 2.37-18 -> 2.37-19
  [UPGRADE] libc6-dev:amd64 2.37-18 -> 2.37-19

Looks unlikely...

Please note that I can connect to the same Fortinet VPN with
openconnect, and it works.

Please investigate and fix this bug as soon as possible.
Thanks a lot for your time and dedication!


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

Kernel: Linux 6.7.12-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 openfortivpn depends on:
ii  libc62.37-19
ii  libssl3t64   3.2.1-3
ii  libsystemd0  255.5-1
ii  ppp  2.5.0-1+2

openfortivpn recommends no packages.

Versions of packages openfortivpn suggests:
pn  resolvconf  

-- Configuration Files:
/etc/openfortivpn/config [Errno 13] Permission denied: 
'/etc/openfortivpn/config'

-- no debconf information

Bug#1070342: ASoC: no backend DAIs enabled for Audio Port

[maqiang]

Package: alsa-ucm-conf
Version: 1.2.8-1
Severity: normal
X-Debbugs-Cc: hamasa_y...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation?
after installing Debian 12 to my Asus x205ta, i the sound was not working, i
got dummy sink
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
i have installed the package (firmware-intel-sound
)
   * What was the outcome of this action?
sound works now, but i have 2 error messages when i run "dmesg"
i get the following errors:
[   14.350152]  Audio Port: ASoC: error at dpcm_fe_dai_prepare on Audio Port:
-22
[   14.350722]  Audio Port: ASoC: no backend DAIs enabled for Audio Port

   * What outcome did you expect instead?

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


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

Kernel: Linux 6.1.0-20-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 alsa-ucm-conf depends on:
ii  libasound2  1.2.8-1+b1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

Bug#1030231: hugs: toInteger (minBound :: Int) incorrect on 64bit

[Petter Reinholdtsen]

[Claude Heiland-Allen 2023-02-01]
> The problem is in src/bignums.c, because -INT_MIN == INT_MIN.
> 
> Attached patch fixes the problem for me on aarch64 and x86_64.

Currently hugs98 is orphaned in Debian.  Your fix seem like a
patch for upstream.  Did you try to submit it to the upstream
project?
-- 
Happy hacking
Petter Reinholdtsen

Bug#1070074: workaround: exec bash

[Dan Jacobson]

Temporary workaround:
$ exec bash

Bug#1070341: dublin-traceroute: Please remove build-dependency on libtins4.5

[Sudip Mukherjee]

Source: dublin-traceroute
Version: 0.4.2-2
Severity: wishlist
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

The package already has a build dependency on libtins-dev which will 
automatically
pull the relevant libtins and there is no need to add an explicit build
dependency on libtins4.5.

So, next time there is an update to libtins, dublin-traceroute will only need a
bin-nmu as part of the libtins transition and there wont be any need to update
dublin-traceroute.

-- 
Regards
Sudip

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Christoph Biedl]

Preuße, Hilmar wrote...

> On 03.05.2024 22:29, Christoph Biedl wrote:
> > Hilmar Preusse wrote...

> > > * Bump Standards and dh compat version, no changes needed.
> >
> > I'm a little surprised why you would change that in a NMU.
> >
> Well, this was reported by lintian. As they were no further changes needed,
> I though it would be a good idea.

Likely there are different opinions here - I prefer to make changes in an NMU
as small as possible. And was about to break my own rule by suggesting
an autopkgtest in #1038937.

> > > * Add "Conflicts: fq".
> >
> > We have a problem. Conflicts: is not enough, with both nq and fq
> > providing /usr/bin/fq, they are in violation of policy 10.1:
> >
> > | Two different packages must not install programs with different
> > | functionality but with the same filenames.
> >
>
> Thanks for pointing this out. The solution in the pull request (which
> introduced the Conflict) looked weird, but in the end #1005961 was solved
> the same (wrong) way, hence I thought it would be OK.

Yeah, to be honest, earlier I had assumed Conflicts: was sufficient to
deal with such a file name clash, too. Only to learn it the hard way in
#919697 policy is pretty straight in that regard.

And I'm not sure policy is the best way to handle this but changing it
is a different story.

> As I'm not the maintainer of either of these package I don't really feel
> responsible to solve the conflict. At first I'd reopen the bug above and
> state it as wrongly solved quoting the policy entry.

That would be necessary - although I don't know how to solve this in a
sensible way.

Sorry for disturbing your best intentions to bring nq back in shape -
but this problem will not disappear by ignoring it.

Christoph


signature.asc
Description: PGP signature

Bug#1070340: imagemagick: Bug CVE-2023-34151 was not properly closed in imagemagick from Bookworm for mvg

[Sergei Semin]

Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.6+deb12u1
Severity: important
Tags: security upstream
X-Debbugs-Cc: syominser...@gmail.com, Debian Security Team 


Hello!
Bug CVE-2023-34151 was not properly closed in imagemagick from Bookworm for mvg.
Version of imagemagick is 8:6.9.11.60+dfsg-1.6+deb12u1.
You can see instructions how to reproduce it here:
https://docs.google.com/document/d/1zjM5MvfFYC317PEPY4_4WRi0hOdpM766FyqpvOmeE90/edit?usp=sharing
I have discussed this problem with upstream developers here:
https://github.com/ImageMagick/ImageMagick/issues/6341#issuecomment-2063607226
They approved and fixed bug for imagemagick7, but for some reasons they didn't 
approve bug for imagemagick6. But I think it is still exists and could be 
reproduced in Debian Bookworm environment as described.
p.s. I tried to send message to 1036...@bugs.debian.org, but I received error 
'550 Unknown or archived bug', so I decided to open new bug.


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

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

Bug#1070304: util-linux: Please build and provide the cal binary

[Jörg Behrmann]

On Fri, May 03, 2024 at 08:38:27PM +0200, Michael Meskes wrote:
> > I think that ship has sailed already, since e.g. -m in the ncal
> > version
> > specifies the month (a bit superfluously), whereas in the util-linux
> > version it
> > sets the beginning of the week to Monday.
> 
> Not sure why specifying the month is superfluous.
>

I'm sorry, that was a bit tongue in cheek. I'm sure there are valid uses for
this, but since cal can take the month as first argument, when given two
numeric arguments, there are multiple ways of achieving the same goal.

> > An alternative I could see would be to drop cal from the ncal package
> > and only
> > provide cal from util-linux.
> > 
> > Nothing would be lost, since ncal can act as cal with the -C option,
> > so users
> > wanting that specific cal could use a function
> > 
> >     cal() {
> >     ncal -C $@
> >     }
> > 
> > and the rest would get a cal that can show week numbers and set the
> > beginning of
> > the Monday.
> 
> Now I'm confused. Is the reason for this proposal to have a cal that
> shows week numbers and forces the start of the week to Monday? Well,
> ncal does both of this, so why don't you just use something like "ncal
> -wMb" as cal? Not that ncal needs "-M", it is able to get this from
> your locale.
> 

The example was to show how people could achieve using ncal to get cal, if the
ncal package would not ship a cal binary.

This is *not* about forcing Monday, util-linux cal takes that from the locale as
well, but when working in mixed locale settings or on a machine with just
C.UTF-8, it is nice to be able to change it and the obvious "cal -M" fails for
the ncal version, as does "cal -w". Requiring the use of ncal (instead of cal)
and an option documented as "Use oldstyle format for ncal output" seems highly
non-obvious to me.

> The question is does it offer all the other features? Or would we be
> better of switching to something like gcal instead?

That depends on what all the necessary features are? The differences as far as I
can see them at this moment are

- util-linux cal doesn't provide the date of Easter, unlike ncal cal
- util-linux cal supports beginning of week and week number switches for cal,
  which do not work with ncal cal
- util-linux cal supports years after 
- util-linux cal supports month names as strings instead of the -m argument
- ncal cal has -B and -A arguments for before and after, util-linux cal has a
  --months (-n) switch for the number of months and they can be cented around a
  given month with the --span (-S) option

gcal supports more different calendars and more holidays, but this seems to go
beyond the basic calendar functionality of either util-linux' and ncal's
implementation.


signature.asc
Description: PGP signature

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Preuße]

On 03.05.2024 22:29, Christoph Biedl wrote:

Hilmar Preusse wrote...


Hi Christoph,


Changes since the last upload:

  nq (0.5-0.1) unstable; urgency=medium
  .
* Non-maintainer upload.
  .
* New upstream version (Closes: #1038937).



* Bump Standards and dh compat version, no changes needed.


I'm a little surprised why you would change that in a NMU.

Well, this was reported by lintian. As they were no further changes 
needed, I though it would be a good idea.



* Add upstream metadata file.
* Add "Conflicts: fq".


We have a problem. Conflicts: is not enough, with both nq and fq
providing /usr/bin/fq, they are in violation of policy 10.1:

| Two different packages must not install programs with different
| functionality but with the same filenames.



Thanks for pointing this out. The solution in the pull request (which 
introduced the Conflict) looked weird, but in the end #1005961 was 
solved the same (wrong) way, hence I thought it would be OK.


As I'm not the maintainer of either of these package I don't really feel 
responsible to solve the conflict. At first I'd reopen the bug above and 
state it as wrongly solved quoting the policy entry.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070338: FTBFS: libadios2_serial_evpath.so.2.10.0: undefined reference to `cmfabric_add_static_transport'

[Drew Parsons]

Source: adios2
Version: 2.10.0+dfsg1-1
Severity: normal
Tags: ftbfs
Control: forwarded -1 https://github.com/ornladios/ADIOS2/issues/4156

Building the debian package for adios 2.10.0 (in experimental) fails with 
"libadios2_serial_evpath.so.2.10.0: undefined reference to 
`cmfabric_add_static_transport'":

[228/329] : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/projects/adios2=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_
FORTIFY_SOURCE=2 -Wl,-z,relro 
source/adios2/toolkit/remote/CMakeFiles/adios2_remote_server.dir/remote_server.cpp.o
 
source/adios2/toolkit/remote/CMakeFiles/adios2_remote_server.dir/remote_common.cpp.o
 -o bin/adio
s2_remote_server.serial  lib/x86_64-linux-gnu/libadios2_serial_evpath.so.2.10.0 
 lib/x86_64-linux-gnu/libadios2_serial_core.so.2.10.0  
lib/x86_64-linux-gnu/libadios2_serial_ffs.so.2.10.0  lib/x86_64-linux-gnu/li
badios2_serial_atl.so.2.10.0  -ldl  
-Wl,-rpath-link,/projects/adios2/build-serial/lib/x86_64-linux-gnu && :
FAILED: bin/adios2_remote_server.serial 
: && /usr/bin/c++ -g -O2 -ffile-prefix-map=/projects/adios2=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SO
URCE=2 -Wl,-z,relro 
source/adios2/toolkit/remote/CMakeFiles/adios2_remote_server.dir/remote_server.cpp.o
 
source/adios2/toolkit/remote/CMakeFiles/adios2_remote_server.dir/remote_common.cpp.o
 -o bin/adios2_remote_
server.serial  lib/x86_64-linux-gnu/libadios2_serial_evpath.so.2.10.0  
lib/x86_64-linux-gnu/libadios2_serial_core.so.2.10.0  
lib/x86_64-linux-gnu/libadios2_serial_ffs.so.2.10.0  
lib/x86_64-linux-gnu/libadios2_se
rial_atl.so.2.10.0  -ldl  
-Wl,-rpath-link,/projects/adios2/build-serial/lib/x86_64-linux-gnu && :
/usr/bin/ld: lib/x86_64-linux-gnu/libadios2_serial_evpath.so.2.10.0: undefined 
reference to `cmfabric_add_static_transport'
collect2: error: ld returned 1 exit status

Bug#1070334: libnet-frame-device-perl needs network access during build

[Étienne Mollier]

Control: tags -1 + confirmed

Jochen Sprickerhof, on 2024-05-03:
> libnet-frame-device-perl fails to build with no network connection:
> 
> 1..1
> # Running under perl version 5.038002 for linux
> # Current time local: Sat Apr 27 12:53:04 2024
> # Current time GMT:   Sat Apr 27 12:53:04 2024
> # Using Test.pm version 1.31
> ok 1 # skip Test::Pod 1.00 required for testing
> ok
> Net::Frame::Device: updateFromDefault: unable to get dnet
> 
> This can be tested with the sbuild unshare backend.

Interesting, the test suite looks to expect to find non loopback
interfaces being configured, at least one I assume.  If I run
the build in chroot-mode schroot, it captures details of the
network configuration of the interface:

$VAR1 = {
  'subnet6' => 'fe80::/64',
  'gatewayMac6' => undef,
  'target6' => undef,
  'gatewayIp6' => 'fe80::1234:56ff:fe78:9abc',
  'ip6' => 'fe80::cba9:87ff:fe65:4321',
  'mac' => 'cb:a9:87:65:43:21',
  'gatewayMac' => '12:34:56:67:9a:bc',
  'target' => undef,
  'dev' => 'enp1s0',
  'subnet' => '192.168.1.0/24',
  '_dnet' => undef,
  'gatewayIp' => '192.168.1.254',
  'ip' => '192.168.1.1'
};

instead of the error below, which I also witnessed on my end in
chroot-mode unshare:

Net::Frame::Device: updateFromDefault: unable to get dnet

I don't really have any good suggestion apart from not running
the affected tests at build time:

t/04-new-default.t (Wstat: 25856 (exited 101) Tests: 0 Failed: 0)
  Non-zero exit status: 101
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
t/05-new-target.t  (Wstat: 25856 (exited 101) Tests: 0 Failed: 0)
  Non-zero exit status: 101
  Parse errors: Bad plan.  You planned 1 tests but ran 0.

Has someone an idea of better approach?

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: Steve Hackett - The Cinema Show (Live at Hamme…


signature.asc
Description: PGP signature

Bug#1066278: xnee: FTBFS: xnee_fake.c:809:15: error: implicit declaration of function ‘xnee_check_key’; did you mean ‘xnee_check_true’? [-Werror=implicit-function-declaration]

[Andreas Beckmann]

Followup-For: Bug #1066278
Control: tag -1 patch pending

Hi,

I've imported the patch from Ubuntu and together with some minor fixes
uploaded it as a NMU to DELAYED/2. Please let me know if I should delay
it longer.

All changes have been pushed to the salsa.d.o repository.
(changelog finalization and tag will follow after the package was
accepted)


Andreas

Bug#1064121: Upload pending soon

[Patrick Winnertz]

tags 1064121 + pending
thanks

Hey,
I've incorporated your changes into the new upload and hope to fix that 
issue soon.


Thanks for your patch!

With best regards
Patrick

Bug#1070335: samba-dev: missing Breaks+Replaces: libwbclient-dev (<< 2:4.20)

[Andreas Beckmann]

On 03/05/2024 22.27, Michael Tokarev wrote:

The move has happened in 4.19.6-2 which were uploaded a couple days ago.
The version in experimental (4.20) uploaded *before* the version in sid
(4.19.6) - I uploaded new upstream version to experimental to see how it
will work.


I didn't check the timing of the uploads ...
Ususally such changes happen with new upstreams in experimental ;-)


For the real 4.20 upload, I'll rebase it on top of current sid version,
4.19.6-2, which does have proper breaks/replaces but in the opposite
direction.


Sounds like no action is needed to fix this experimental-only bug. Just 
close it with the upload of 4.20 to sid.


Andreas

Bug#1069958: Acknowledgement (503 Server reports unexpected range)

[Masked Witch]

It randomly resolved itself. I don't know what changed, but it's
working now.

Bug#1053411: sra-sdk: FTBFS with re2 >= 20230601 (which requires abseil)

[Stefano Rivera]

Control: severity -1 important

6 months later, raising the severity. Pinning an ancient upstream
version of a library is a problem.

Stefano

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

Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding

[Vincent Bernat]

Hello Helge,

Couldn't the patch be pushed upstream? And maybe there should be an else 
branch with the encoding of the other NaN?


On 2024-04-27 17:35, Helge Deller wrote:

Source: libcbor
Version: 0.10.2-1.2
Tags: ftbfs
X-Debbugs-Cc: del...@debian.org

libcbor fails to build from source on the hppa and mips architectures.
Reason is, that a testcases which checks the binary representation
of NaN fails on those architectures, because they use a different binary
encoding of the bytes.
See the "encoding" section at https://en.wikipedia.org/wiki/NaN for 
details.


Failure except:
20: [ RUN  ] test_float
20: [  ERROR   ] --- difference at offset 2 0xffbf 0xffc0
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: 3 bytes of 0x1739c and 0xfa001b57 differ
20: [   LINE   ] --- ./test/float_ctrl_encoders_test.c:150: error: Failure!
20: [  FAILED  ] test_float
20: [ RUN  ] test_double
20: [  ERROR   ] --- difference at offset 2 0xfff7 0xfff8
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: difference at offset 5 0x 0x00
20: difference at offset 6 0x 0x00
20: difference at offset 7 0x 0x00
20: difference at offset 8 0x 0x00
20: 7 bytes of 0x1739c and 0xfa001b63 differ
20: [   LINE   ] --- ./test/float_ctrl_encoders_test.c:177: error: Failure!

The attached patch avoids this test on hppa and thus building libcbor 
succeeds.

I did not test the patch on mips yet.

Helge

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Christoph Biedl]

Hilmar Preusse wrote...

> Changes since the last upload:
> 
>  nq (0.5-0.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>  .
>* New upstream version (Closes: #1038937).

>* Bump Standards and dh compat version, no changes needed.

I'm a little surprised why you would change that in a NMU.

>* Add upstream metadata file.
>* Add "Conflicts: fq".

We have a problem. Conflicts: is not enough, with both nq and fq
providing /usr/bin/fq, they are in violation of policy 10.1:

| Two different packages must not install programs with different
| functionality but with the same filenames.

Christoph


signature.asc
Description: PGP signature

Bug#1070335: samba-dev: missing Breaks+Replaces: libwbclient-dev (<< 2:4.20)

[Michael Tokarev]

03.05.2024 23:16, Andreas Beckmann wrote:

Package: samba-dev
Version: 2:4.20.0+dfsg-1~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.


Hm. I'm not sure what to do here, it's a bit interesting.

The move has happened in 4.19.6-2 which were uploaded a couple days ago.
The version in experimental (4.20) uploaded *before* the version in sid
(4.19.6) - I uploaded new upstream version to experimental to see how it
will work.

For the real 4.20 upload, I'll rebase it on top of current sid version,
4.19.6-2, which does have proper breaks/replaces but in the opposite
direction.

So in order to fix this bug, current version of samba should be *removed*
from experimental, instead of adding backwards-facing breaks/replaces.

I don't plan to do another upload of 4.20 to experimental at this time,
and the next upload will be to sid (hopefully) with proper history et
al.  So current version in experimental is sort of orphan right now.

Or are you suggesting I should perform another upload to experimental
just to fix this bug report?  I'd rather avoid another rebase..

Thanks,

/mjt

Bug#1066579: Fixed by upstream in 2.27

[Patrick Winnertz]

tags 1066579 + pending
thanks

The new upstream version 2.27 will fix this ftbfs. It's currently 
prepared within the git.


With best regards
Patrick

Bug#1070337: lilypond: autopkgtest fails w/ TL2024

[Hilmar Preusse]

Package: lilypond
Version: 2.24.3-1
Severity: important
Control: affects -1 src:texlive-base

Dear Maintainer,

I recently uploaded TL 2024 to Debian experimental. I just noticed that the
autopkgtex test of your package fails w/ TL 2024. Currently I have no time
frame for the upload of TL 2024 to experimental, nevertheless it would be a
good idea to look at the issue soon.

Thanks,
  Hilmar

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.6.28+rpt-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lilypond depends on:
ii  ghostscript10.0.0~dfsg-11+deb12u3
pn  guile-2.2  
pn  guile-2.2-libs 
ii  libc6  2.36-9+rpt2+deb12u6
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
pn  libgc1 
ii  libglib2.0-0   2.74.6-2
pn  libpango-1.0-0 
pn  libpangoft2-1.0-0  
ii  libstdc++6 12.2.0-14
pn  lilypond-data  
ii  python33.11.2-1+b1

Versions of packages lilypond recommends:
ii  texlive-latex-base  2022.20230122-3

Versions of packages lilypond suggests:
pn  lilypond-doc  
pn  python3-lxml  


signature.asc
Description: PGP signature

Bug#1070336: avahi-utils: avahi-resolve-address returns success exit code on failure

[Ernesto Alfonso]

Package: avahi-utils
Version: 0.8-10
Severity: minor
Tags: upstream
X-Debbugs-Cc: erjoa...@gmail.com

Dear Maintainer,

avahi-resolve-address and avahi-resolve --address should return a non-zero exit 
code on failure:

if avahi-resolve-address 192.162.1.99; then
echo success;
else
echo failure;
fi

Failed to resolve address '192.162.1.99': Timeout reached
success

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

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

Versions of packages avahi-utils depends on:
ii  avahi-daemon  0.8-10
ii  libavahi-client3  0.8-10
ii  libavahi-common3  0.8-10
ii  libc6 2.36-9+deb12u3
ii  libgdbm6  1.23-3

avahi-utils recommends no packages.

avahi-utils suggests no packages.

-- no debconf information

Ernesto

Bug#1070335: samba-dev: missing Breaks+Replaces: libwbclient-dev (<< 2:4.20)

[Andreas Beckmann]

Package: samba-dev
Version: 2:4.20.0+dfsg-1~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../samba-dev_2%3a4.20.0+dfsg-1~exp2_amd64.deb ...
  Unpacking samba-dev:amd64 (2:4.20.0+dfsg-1~exp2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/samba-dev_2%3a4.20.0+dfsg-1~exp2_amd64.deb (--unpack):
   trying to overwrite '/usr/include/samba-4.0/core/doserr.h', which is also in 
package libwbclient-dev:amd64 2:4.19.6+dfsg-3
  Errors were encountered while processing:
   /var/cache/apt/archives/samba-dev_2%3a4.20.0+dfsg-1~exp2_amd64.deb

The following headers moved from libwbclient-dev to samba-dev:

usr/include/samba-4.0/core/doserr.h
usr/include/samba-4.0/core/error.h
usr/include/samba-4.0/core/hresult.h
usr/include/samba-4.0/core/ntstatus.h
usr/include/samba-4.0/core/ntstatus_gen.h
usr/include/samba-4.0/core/werror.h
usr/include/samba-4.0/core/werror_gen.h


cheers,

Andreas


libwbclient-dev=2:4.19.6+dfsg-3_samba-dev=2:4.20.0+dfsg-1~exp2.log.gz
Description: application/gzip

Bug#1070334: libnet-frame-device-perl needs network access during build

[Jochen Sprickerhof]

Source: libnet-frame-device-perl
Version: 1.12-1
Severity: serious
Justification: Policy 4.9
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

libnet-frame-device-perl fails to build with no network connection:

1..1
# Running under perl version 5.038002 for linux
# Current time local: Sat Apr 27 12:53:04 2024
# Current time GMT:   Sat Apr 27 12:53:04 2024
# Using Test.pm version 1.31
ok 1 # skip Test::Pod 1.00 required for testing
ok
Net::Frame::Device: updateFromDefault: unable to get dnet

This can be tested with the sbuild unshare backend.

Cheers Jochen

Bug#1070330: [Pkg-libvirt-maintainers] Bug#1070330: libvirt: CVE-2024-4418: stack use-after-free in virNetClientIOEventLoop()

[Salvatore Bonaccorso]

Hi Guido,

On Fri, May 03, 2024 at 09:47:30PM +0200, Guido Günther wrote:
> control: -1 +pending
> 
> Hi,
> On Fri, May 03, 2024 at 09:10:23PM +0200, Salvatore Bonaccorso wrote:
> > Source: libvirt
> > Version: 10.2.0-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for libvirt.
> > 
> > CVE-2024-4418[0]:
> > | stack use-after-free in virNetClientIOEventLoop()
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> See https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/220

Ah, very nice. Thanks!

Regards,
Salvatore

Bug#1059852: transition: glibc 2.38

[Aurelien Jarno]

Hi,

On 2024-01-02 13:23, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: gl...@packages.debian.org
> Control: affects -1 + src:glibc
> 
> Dear release team,
> 
> I would like to get a transition slot for glibc 2.38. It has been
> available in experimental for a few months and does not have any known
> issue anymore. It has been built successfully on all release
> architectures and most ports architectures, and the experimental
> pseudo-excuses look good overall.
> 
> As glibc is using symbol versioning, there is no soname change. That
> said a few packages are using libc internal symbols and have to be
> rebuilt for this transition. Here is the corresponding ben file:
> 
>   title = "glibc";
>   is_affected = .depends ~ /libc[0-9.]* \(<   is_good = .depends ~ /libc[0-9.]* \(<< 2.39\)/;
>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/;
> 
> The main symbol related changes in this version are the addition of
> strlcat and strlcpy and related functions, coming from the BSD world. A
> few packages have their own implementation exported in their symbols
> file. With glibc 2.38 starting to provide those functions, the packages
> stops providing compatibility functions and the associated symbols,
> causing them to FTBFS. Many of them have been identified thanks to the
> hurd-amd64 bootstrap and have been fixed. The known remaining ones are:
>  - #1055297 ruby3.1: fails to build against glibc 2.38
>  - #1055316 heimdal: fails to build against glibc 2.38
> 
> Other than that a few symbols have been added to support the C2X binary
> constant handling in scanf family of functions. There are unlikely to be
> widely used at this point and thus that new packages start to use them,
> blocking their migration to testing during the transition.
> 
> Thanks for considering.

As discussed on IRC, I just uploaded it.

Regards
Aurelien

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

Bug#1070333: python-eventlet fails to build with an empty /etc/resolv.conf

[Jochen Sprickerhof]

Source: python-eventlet
Version: 0.35.1-1
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

python-eventlet fails to build with no nameserver specified in
/etc/resolv.conf:

=== FAILURES ===
_ TestProxyResolver.test_clear _

self = 

def test_clear(self):
rp = greendns.ResolverProxy()
assert rp._cached_resolver is None
>   resolver = rp._resolver

tests/greendns_test.py:304:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
eventlet/support/greendns.py:347: in _resolver
self.clear()
eventlet/support/greendns.py:355: in clear
self._resolver = dns.resolver.Resolver(filename=self._filename)
/usr/lib/python3/dist-packages/dns/resolver.py:944: in __init__
self.read_resolv_conf(filename)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 
f = <_io.TextIOWrapper name='/etc/resolv.conf' mode='r' encoding='UTF-8'>

def read_resolv_conf(self, f: Any) -> None:
"""Process *f* as a file in the /etc/resolv.conf format.  If f is
a ``str``, it is used as the name of the file to open; otherwise it
is treated as the file itself.

Interprets the following items:

- nameserver - name server IP address

- domain - local domain name

- search - search list for host-name lookup

- options - supported options are rotate, timeout, edns0, and ndots

"""

nameservers = []
if isinstance(f, str):
try:
cm: contextlib.AbstractContextManager = open(f)
except OSError:
# /etc/resolv.conf doesn't exist, can't be read, etc.
raise NoResolverConfiguration(f"cannot open {f}")
else:
cm = contextlib.nullcontext(f)
with cm as f:
for l in f:
if len(l) == 0 or l[0] == "#" or l[0] == ";":
continue
tokens = l.split()

# Any line containing less than 2 tokens is malformed
if len(tokens) < 2:
continue

if tokens[0] == "nameserver":
nameservers.append(tokens[1])
elif tokens[0] == "domain":
self.domain = dns.name.from_text(tokens[1])
# domain and search are exclusive
self.search = []
elif tokens[0] == "search":
# the last search wins
self.search = []
for suffix in tokens[1:]:
self.search.append(dns.name.from_text(suffix))
# We don't set domain as it is not used if
# len(self.search) > 0
   elif tokens[0] == "options":
for opt in tokens[1:]:
if opt == "rotate":
self.rotate = True
elif opt == "edns0":
self.use_edns()
elif "timeout" in opt:
try:
self.timeout = int(opt.split(":")[1])
except (ValueError, IndexError):
pass
elif "ndots" in opt:
try:
self.ndots = int(opt.split(":")[1])
except (ValueError, IndexError):
pass
if len(nameservers) == 0:
>   raise NoResolverConfiguration("no nameservers")
E   dns.resolver.NoResolverConfiguration: no nameservers

/usr/lib/python3/dist-packages/dns/resolver.py:1038: NoResolverConfiguration


This fails in sbuild with the unshare backend.

Cheers Jochen

Bug#1070332: designate fails to build with no nameserver specified in /etc/resolv.conf

[Jochen Sprickerhof]

Source: designate
Version: 1:18.0.0-1
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

designate fails to build with no nameserver specified in
/etc/resolv.conf:

==
FAIL: designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib/python3.12/unittest/mock.py", line 1390, in patched
return func(*newargs, **newkeywargs)
   ^
  File "/<>/designate/tests/unit/mdns/test_handler.py", line 79, 
in test_notify
self.assertEqual(dns.rcode.NOERROR, tuple(response)[0].rcode())
^^^
  File "/<>/designate/mdns/handler.py", line 142, in _handle_notify
resolver = dns.resolver.Resolver()
   ^^^
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 944, in __init__
self.read_resolv_conf(filename)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1038, in 
read_resolv_conf
raise NoResolverConfiguration("no nameservers")
dns.resolver.NoResolverConfiguration: no nameservers


This fails in sbuild with the unshare backend. Please disable the
failing tests:

designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify_same_serial

Cheers Jochen

Bug#1070330: [Pkg-libvirt-maintainers] Bug#1070330: libvirt: CVE-2024-4418: stack use-after-free in virNetClientIOEventLoop()

[Guido Günther]

control: -1 +pending

Hi,
On Fri, May 03, 2024 at 09:10:23PM +0200, Salvatore Bonaccorso wrote:
> Source: libvirt
> Version: 10.2.0-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for libvirt.
> 
> CVE-2024-4418[0]:
> | stack use-after-free in virNetClientIOEventLoop()
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

See https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/220

Cheers,
 -- Guido

> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2024-4418
> https://www.cve.org/CVERecord?id=CVE-2024-4418
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2278616
> [2] 
> https://gitlab.com/libvirt/libvirt/-/commit/8074d64dc2eca846d6a61efe1a9b7428a0ce1dd1
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
> 

Bug#1038937: nq package out of date with upstream, 0.5 was released more than a year ago

[Christoph Biedl]

Control: tags 1038937 pending

E Harris wrote...

> nq 0.5 was released March 26, 2022 and contains several bug fixes and 
> improvements.
> nq 0.3.1 was released March 7, 2018, and is what is in all of stable, 
> testing, and unstable.
> Please update this package.

Upon request by upstream and following the statements given in
,
also there's the LowNMU flag ... I'll upload 0.5-0.1 in the next days.
To improve quality and as it was a no-brainer, I'll also add an autopkgtest.

Christoph



signature.asc
Description: PGP signature

Bug#1067169: gnome-control-center: Disable location services?

[Jeremy Bícha]

On Thu, Apr 18, 2024 at 10:33 AM Arnaud Ferraris  wrote:
> TBH I would prefer it if those services were kept enabled in Debian, as
> those are useful to mobile users. Moreover, it seems an alternative to
> MLS is being worked on, although I don't know what its current status
> is, nor whether it'll be live before MLS goes down. But if it's ready
> soon enough (that's a big "if", granted), then g-c-c will likely need a
> small patch to switch to it, without user-visible disruption.

Thank you for your reply. After further consideration, both Ubuntu
24.04 LTS and Fedora 40 have re-enabled location service settings in
gnome-control-center for now. Therefore, I have kept location services
enabled in Debian Unstable too.

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/3032

Jeremy Bícha

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Hilmar Preusse]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nq":

 * Package name : nq
   Version  : 0.5-0.1
   Upstream contact : Leah Neukirchen 
 * URL  : https://git.vuxu.org/nq/about/
 * License  : CC0-1.0
 * Vcs  : https://salsa.debian.org/debian/nq
   Section  : utils

The source builds the following binary packages:

  nq - Lightweight queue system

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/nq/

Alternatively, you can download the package with 'dget' using this command:

  dget -x https://mentors.debian.net/debian/pool/main/n/nq/nq_0.5-0.1.dsc

Changes since the last upload:

 nq (0.5-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
 .
   * New upstream version (Closes: #1038937).
   * Bump Standards and dh compat version, no changes needed.
   * Add upstream metadata file.
   * Add "Conflicts: fq".

The package is marked as LowNMU (https://wiki.debian.org/LowThresholdNmu).

Regards,
-- 
  Hilmar Preusse


signature.asc
Description: PGP signature

Bug#1070330: libvirt: CVE-2024-4418: stack use-after-free in virNetClientIOEventLoop()

[Salvatore Bonaccorso]

Source: libvirt
Version: 10.2.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libvirt.

CVE-2024-4418[0]:
| stack use-after-free in virNetClientIOEventLoop()


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-4418
https://www.cve.org/CVERecord?id=CVE-2024-4418
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2278616
[2] 
https://gitlab.com/libvirt/libvirt/-/commit/8074d64dc2eca846d6a61efe1a9b7428a0ce1dd1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1066397: lgeneral: FTBFS: ../config.h:566:12: fatal error: direct.h: No such file or directory

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 13:03:23 +0100, Lucas Nussbaum wrote:
> Source: lgeneral
> Version: 1.4.4-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie

> Relevant part (hopefully):
> > gcc -DHAVE_CONFIG_H -DDATADIR=\"/usr/share/games\" -DPREFIX=\"/usr\" -I. 
> > -I..   -I.. -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection -Wall -std=gnu89 -O0 -g -c -o 
> > portability.o portability.c
> > In file included from localize.h:31,
> >  from localize.c:27:
> > ../config.h:566:12: fatal error: direct.h: No such file or directory
> >   566 | #  include 
> >   |^~
> > In file included from portability.c:27:
> > ../config.h:566:12: fatal error: direct.h: No such file or directory
> >   566 | #  include 
> >   |^~
> > compilation terminated.
> > compilation terminated.
> > make[3]: *** [Makefile:418: portability.o] Error 1

The attached patch should workaround this problem. From the patch
description:

  Fix missing declaration for mkdir(2)

  The header where mkdir(2) is declared is  not ,
  which means that with new compilers that default to set
  -Werror=implicit-function-declaration, the configure check fails and
  causes the code to try to include a  header that does not·
  exist on the system
  .
  We currently need to only change the generated configure because
  the package disables the autoreconf sequence, due to the upstream
  build system being out-of-date and failing to autoreconf cleanly.
  To fix this properly the build system should get updated, then the
  sequence re-enabled, and the change from here applied to the
  configure.ac instead.

Thanks,
Guillem
diff -Nru lgeneral-1.4.4/debian/patches/implicit-decls.patch lgeneral-1.4.4/debian/patches/implicit-decls.patch
--- lgeneral-1.4.4/debian/patches/implicit-decls.patch	1970-01-01 01:00:00.0 +0100
+++ lgeneral-1.4.4/debian/patches/implicit-decls.patch	2024-05-03 20:54:06.0 +0200
@@ -0,0 +1,31 @@
+Description: Fix missing declaration for mkdir(2)
+ The header where mkdir(2) is declared is  not ,
+ which means that with new compilers that default to set
+ -Werror=implicit-function-declaration, the configure check fails and
+ causes the code to try to include a  header that does not 
+ exist on the system
+ .
+ We currently need to only change the generated configure because the
+ package disables the autoreconf sequence, due to the upstream build system
+ being out-of-date and failing to autoreconf cleanly. To fix this properly
+ the build system should get updated, then the sequence re-enabled, and the
+ change from here applied to the configure.ac instead.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: not-needed
+
+---
+ configure |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/configure
 b/configure
+@@ -5667,7 +5667,7 @@ $as_echo_n "checking if mkdir rejects pe
+ ac_mkdir_perm_broken=yes
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h.  */
+-#include 
++#include 
+ int
+ main ()
+ {
diff -Nru lgeneral-1.4.4/debian/patches/series lgeneral-1.4.4/debian/patches/series
--- lgeneral-1.4.4/debian/patches/series	2023-02-25 17:55:55.0 +0100
+++ lgeneral-1.4.4/debian/patches/series	2024-05-03 20:43:31.0 +0200
@@ -1 +1,2 @@
 fix_desktop_file_encoding.patch
+implicit-decls.patch

Bug#1067285: whitakers-words: FTBFS: make[2]: *** [Makefile:40: commands] Error 4

[Nicolas Boulenguez]

Source: whitakers-words
Followup-For: Bug #1067285

Hello.
This failure is caused by new compiler warnings, either because of the
switch to gnat-13 or because of changes in Debian options.
Anyway, I suggest to add the following two lines in debian/rules,
somewhere before the inclusion of /usr/share/*.mk.

# Disable the -gnatwe upstream flags during Debian builds.
DEB_ADAFLAGS_MAINT_APPEND := -gnatwn

Bug#1070329: [borg mount] fuse: failed to exec fusermount3: No such file or directory

[David Mandelberg]

Package: borgbackup
Version: 1.2.4-1

When I tried to use `borg mount`, it gave the error "fuse: failed to 
exec fusermount3: No such file or directory". The package recommends 
fuse, but installing fuse3 instead seemed to fix the error. Should the 
package recommend fuse3 instead of fuse?

Bug#1070304: util-linux: Please build and provide the cal binary

[Michael Meskes]

> I think that ship has sailed already, since e.g. -m in the ncal
> version
> specifies the month (a bit superfluously), whereas in the util-linux
> version it
> sets the beginning of the week to Monday.

Not sure why specifying the month is superfluous.

> An alternative I could see would be to drop cal from the ncal package
> and only
> provide cal from util-linux.
> 
> Nothing would be lost, since ncal can act as cal with the -C option,
> so users
> wanting that specific cal could use a function
> 
>     cal() {
>     ncal -C $@
>     }
> 
> and the rest would get a cal that can show week numbers and set the
> beginning of
> the Monday.

Now I'm confused. Is the reason for this proposal to have a cal that
shows week numbers and forces the start of the week to Monday? Well,
ncal does both of this, so why don't you just use something like "ncal
-wMb" as cal? Not that ncal needs "-M", it is able to get this from
your locale.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org


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

Bug#1066466: rlinetd: FTBFS: ../../src/cleanups.c:27:49: error: implicit declaration of function ‘pmap_unset’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:56:21 +0100, Lucas Nussbaum wrote:
> Source: rlinetd
> Version: 0.9.3-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > /bin/bash ../libtool  --tag=CC   --mode=link 
> > /<>/debian/gcc-wrapper gcc -I../.. -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection -Wall -Wextra  -Wwrite-strings 
> > -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes 
> > -Wstrict-prototypes -Wmissing-declarations -Wnested-externs -Wcast-align 
> > -Winline -Wshadow -Wredundant-decls -export-dynamic -Wl,-z,relro -Wl,-z,now 
> > -o rlinetd buffer.o bytecode.o connect.o db.o error.o engine.o main.o 
> > stack.o strings.o signals.o -ldl  ../port/libport.a -lcap
> > ../../src/cleanups.c: In function ‘rlp_cleanup’:
> > ../../src/cleanups.c:27:49: error: implicit declaration of function 
> > ‘pmap_unset’ [-Werror=implicit-function-declaration]
> >27 | 
> > pmap_unset(rlcu->prog, nl->num);
> >   | ^~
> > ../../src/cleanups.c:27:49: warning: nested extern declaration of 
> > ‘pmap_unset’ [-Wnested-externs]
> > cc1: some warnings being treated as errors
> > make[4]: *** [Makefile:603: cleanups.lo] Error 1

This is the symptom, but the actual problem is from the rpc code
having been removed from glibc, and packages now needing to link
against libtirpc instead. The attached patch solves this. Although for
upstream submission this should be done in configure.ac instead.

Thanks,
Guillem
diff -Nru rlinetd-0.9.3/debian/control rlinetd-0.9.3/debian/control
--- rlinetd-0.9.3/debian/control	2024-01-26 00:37:24.0 +0100
+++ rlinetd-0.9.3/debian/control	2024-05-03 20:30:29.0 +0200
@@ -7,6 +7,7 @@
debhelper-compat (= 13),
flex,
libcap2-dev [linux-any],
+   libtirpc-dev,
libwrap0-dev
 Rules-Requires-Root: no
 Homepage: https://salsa.debian.org/debian/rlinetd
diff -Nru rlinetd-0.9.3/debian/rules rlinetd-0.9.3/debian/rules
--- rlinetd-0.9.3/debian/rules	2024-01-26 00:37:24.0 +0100
+++ rlinetd-0.9.3/debian/rules	2024-05-03 20:34:21.0 +0200
@@ -7,7 +7,9 @@
 DESTDIR := $(CURDIR)/debian/$(shell dh_listpackages)
 
 DEB_BUILD_MAINT_OPTIONS := hardening=+all
+DEB_CPPFLAGS_MAINT_APPEND := $(shell pkgconf --cflags libtirpc)
 DEB_CFLAGS_MAINT_APPEND := $(shell getconf LFS_CFLAGS)
+DEB_LDFLAGS_MAINT_APPEND := $(shell pkgconf --libs libtirpc)
 DPKG_EXPORT_BUILDFLAGS  := 1
 
 include /usr/share/dpkg/buildflags.mk

Bug#1070328: libopenscap-perl misbuilds during cross build: wrong multiarch directory

[Helmut Grohne]

Source: openscap
Version: 1.3.10+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Cross building openscap successfully results in a broken
libopenscap-perl. It uses the build architecture multiarch directory.
When building a perl extension, you should Build-Depends: perl-xs-dev
rather than libperl-dev these days and then you can pass a suitable
PERL5LIB supplying the cross configuration. I'm attaching a patch for
your convenience.

Helmut
diff --minimal -Nru openscap-1.3.10+dfsg/debian/changelog 
openscap-1.3.10+dfsg/debian/changelog
--- openscap-1.3.10+dfsg/debian/changelog   2024-04-05 07:40:35.0 
+0200
+++ openscap-1.3.10+dfsg/debian/changelog   2024-05-03 08:23:56.0 
+0200
@@ -1,3 +1,12 @@
+openscap (1.3.10+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix cross misbuild: (Closes: #-1)
++ Build-Depends: perl-xs-dev for building a perl extension.
++ Supply a cross PERL5LIB.
+
+ -- Helmut Grohne   Fri, 03 May 2024 08:23:56 +0200
+
 openscap (1.3.10+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru openscap-1.3.10+dfsg/debian/control 
openscap-1.3.10+dfsg/debian/control
--- openscap-1.3.10+dfsg/debian/control 2024-04-05 07:40:35.0 +0200
+++ openscap-1.3.10+dfsg/debian/control 2024-05-03 08:23:55.0 +0200
@@ -18,7 +18,6 @@
libldap2-dev,
libopendbx1-dev,
libpcre2-dev,
-   libperl-dev,
libpopt-dev,
libpython3-all-dev,
librpm-dev,
@@ -29,6 +28,7 @@
libxmlsec1-dev,
libxslt1-dev,
libyaml-dev,
+   perl-xs-dev,
pkgconf,
python3-all-dev:native,
python3-pytest ,
diff --minimal -Nru openscap-1.3.10+dfsg/debian/rules 
openscap-1.3.10+dfsg/debian/rules
--- openscap-1.3.10+dfsg/debian/rules   2024-04-05 07:40:35.0 +0200
+++ openscap-1.3.10+dfsg/debian/rules   2024-05-03 08:23:56.0 +0200
@@ -6,6 +6,14 @@
 
 export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 
+include /usr/share/dpkg/architecture.mk
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
+PERL5LIB := /usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(PERLVER)$(if 
$(PERL5LIB),:$(PERL5LIB))
+export PERL5LIB
+endif
+
 PYVERS=$(shell py3versions --supported --version)
 CMAKE_OPTS = \
 -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \

Bug#1070327: libauparse0t64 fails piuparts: missing postrm for /usr-move mitigation

[Helmut Grohne]

Source: audit
Version: 1:3.1.2-2.1
Severity: serious
Justification: fails piuparts, blocks testing migration
Tags: patch
X-Debbugs-Cc: z...@debian.org

Hi,

I looked into why audit fails to migrate and noticed that it fails
piuparts as it leaves diversions behind after purge. The patch provided
by the /usr-move team failed to account for package removal and lacks
the postrm bit. I'm attaching a patch that fixes this problem. It also
removes the manual interpolation in favour of relying on dh_installdeb's
builtin interpolation. I'd appreciate a timely upload, because audit is
one of the last missing pieces moving forward with the /usr-move. Would
you mind a NMU?

Helmut
diff --minimal -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
--- audit-3.1.2/debian/changelog2024-02-28 04:02:13.0 +0100
+++ audit-3.1.2/debian/changelog2024-05-03 07:49:46.0 +0200
@@ -1,3 +1,10 @@
+audit (1:3.1.2-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix piuparts failure arising from /usr-move mitigation. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 May 2024 07:49:46 +0200
+
 audit (1:3.1.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.lintian-overrides 
audit-3.1.2/debian/libauparse0t64.lintian-overrides
--- audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-02-28 
03:58:37.0 +0100
+++ audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-05-03 
07:49:46.0 +0200
@@ -1 +1,2 @@
 libauparse0t64: package-name-doesnt-match-sonames libauparse0
+libauparse0t64: remove-of-unknown-diversion lib/* [postrm:*]
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.postrm 
audit-3.1.2/debian/libauparse0t64.postrm
--- audit-3.1.2/debian/libauparse0t64.postrm1970-01-01 01:00:00.0 
+0100
+++ audit-3.1.2/debian/libauparse0t64.postrm2024-05-03 07:49:40.0 
+0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+   remove|disappear)
+   for file in libauparse.so.0 libauparse.so.0.0.0; do
+   dpkg-divert --package libauparse0t64 --no-rename \
+   --remove --divert \
+   "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" 
\
+   "/lib/#DEB_HOST_MULTIARCH#/$file"
+   done
+   ;;
+esac
+
+#DEBHELPER#
+
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst 
audit-3.1.2/debian/libauparse0t64.preinst
--- audit-3.1.2/debian/libauparse0t64.preinst   1970-01-01 01:00:00.0 
+0100
+++ audit-3.1.2/debian/libauparse0t64.preinst   2024-05-03 07:49:46.0 
+0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+   install)
+   for file in libauparse.so.0 libauparse.so.0.0.0; do
+   dpkg-divert --package libauparse0t64 --no-rename \
+   --add --divert \
+   "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" 
\
+   "/lib/#DEB_HOST_MULTIARCH#/$file"
+   done
+   ;;
+esac
+
+#DEBHELPER#
+
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst.in 
audit-3.1.2/debian/libauparse0t64.preinst.in
--- audit-3.1.2/debian/libauparse0t64.preinst.in2024-02-28 
04:02:11.0 +0100
+++ audit-3.1.2/debian/libauparse0t64.preinst.in1970-01-01 
01:00:00.0 +0100
@@ -1,17 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case $1 in
-   install)
-   for file in libauparse.so.0 libauparse.so.0.0.0; do
-   dpkg-divert --package libauparse0t64 --no-rename \
-   --divert \
-   /lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged \
-   /lib/#DEB_HOST_MULTIARCH#/$file
-   done
-   ;;
-esac
-
-#DEBHELPER#
-
diff --minimal -Nru audit-3.1.2/debian/rules audit-3.1.2/debian/rules
--- audit-3.1.2/debian/rules2024-02-28 04:02:11.0 +0100
+++ audit-3.1.2/debian/rules2024-05-03 07:47:04.0 +0200
@@ -109,11 +109,6 @@
chgrp adm debian/auditd/var/log/audit
chmod -R o-rwx debian/auditd/etc/audit debian/audispd-plugins/etc/audit
 
-override_dh_installdeb:
-   sed -e"s/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/" \
-   debian/libauparse0t64.preinst.in > debian/libauparse0t64.preinst
-   dh_installdeb
-
 get-orig-source:
-uscan --upstream-version 0
 

Bug#1070326: kexec-tools: move aliased files to /usr for DEP17

[Helmut Grohne]

Package: kexec-tools
Version: 1:2.0.27-1.1
Severity: important
Tags: patch

Hi,

kexec-tools is part of the /usr-move (DEP17) migration due to installing
files into /sbin, which is an aliased location. We want to eliminate
(bad) aliasing effects by not installing any aliased files anymore.
Hence, kexec-tools also needs to move and since it doesn't use dh, it
cannot be moved using dh-sequence-movetousr. Therefore, I'm attaching a
patch to perform the move manualy. Note that this patch must not be
backported to bookworm-backports or earlier. kexec-tools isn't usually
backported, so this likely is not a problem.

Helmut
diff --minimal -Nru kexec-tools-2.0.27/debian/changelog 
kexec-tools-2.0.27/debian/changelog
--- kexec-tools-2.0.27/debian/changelog 2024-04-27 14:49:56.0 +0200
+++ kexec-tools-2.0.27/debian/changelog 2024-05-03 12:35:57.0 +0200
@@ -1,3 +1,10 @@
+kexec-tools (1:2.0.27-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr for DEP17. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 May 2024 12:35:57 +0200
+
 kexec-tools (1:2.0.27-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru kexec-tools-2.0.27/debian/kexec-tools.dirs 
kexec-tools-2.0.27/debian/kexec-tools.dirs
--- kexec-tools-2.0.27/debian/kexec-tools.dirs  2023-08-22 18:53:02.0 
+0200
+++ kexec-tools-2.0.27/debian/kexec-tools.dirs  2024-05-03 12:34:38.0 
+0200
@@ -1,2 +1,2 @@
-sbin
+usr/sbin
 etc/default/kexec.d
diff --minimal -Nru kexec-tools-2.0.27/debian/patches/coldreboot.patch 
kexec-tools-2.0.27/debian/patches/coldreboot.patch
--- kexec-tools-2.0.27/debian/patches/coldreboot.patch  2023-09-17 
19:09:53.0 +0200
+++ kexec-tools-2.0.27/debian/patches/coldreboot.patch  2024-05-03 
12:35:21.0 +0200
@@ -57,7 +57,7 @@
 +
 +/bin/rm -f $NOKEXECFILE
 +touch $NOKEXECFILE
-+/sbin/reboot $*
++/usr/sbin/reboot $*
 --- /dev/null
 +++ b/kexec/coldreboot.8
 @@ -0,0 +1,25 @@
diff --minimal -Nru kexec-tools-2.0.27/debian/patches/systemd-support.patch 
kexec-tools-2.0.27/debian/patches/systemd-support.patch
--- kexec-tools-2.0.27/debian/patches/systemd-support.patch 2023-10-04 
18:22:02.0 +0200
+++ kexec-tools-2.0.27/debian/patches/systemd-support.patch 2024-05-03 
12:35:38.0 +0200
@@ -121,7 +121,7 @@
 +}
 +
 +load_kernel () {
-+  test -x /sbin/kexec || exit 0
++  test -x /usr/sbin/kexec || exit 0
 +  test "x`cat /sys/kernel/kexec_loaded`y" = "x1y" && exit 0
 +
 +  if [ -f $NOKEXECFILE ]
@@ -138,9 +138,9 @@
 +  echo "Loading new kernel image into memory"
 +  if [ -z "$INITRD" ]
 +  then
-+  /sbin/kexec -l "$KERNEL_IMAGE" --append="$REAL_APPEND"
++  /usr/sbin/kexec -l "$KERNEL_IMAGE" --append="$REAL_APPEND"
 +  else
-+  /sbin/kexec -l "$KERNEL_IMAGE" --initrd="$INITRD" 
--append="$REAL_APPEND"
++  /usr/sbin/kexec -l "$KERNEL_IMAGE" --initrd="$INITRD" 
--append="$REAL_APPEND"
 +  fi
 +  echo "kexec kernel loaded"
 +}
diff --minimal -Nru kexec-tools-2.0.27/debian/rules 
kexec-tools-2.0.27/debian/rules
--- kexec-tools-2.0.27/debian/rules 2023-10-04 19:59:38.0 +0200
+++ kexec-tools-2.0.27/debian/rules 2024-05-03 12:34:51.0 +0200
@@ -27,7 +27,7 @@
dh_testdir
dh_update_autotools_config
dh_autoreconf
-   CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell 
dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" 
dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/sbin 
--mandir=/usr/share/man --datadir=/usr/share
+   CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell 
dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" 
dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/usr/sbin 
--mandir=/usr/share/man --datadir=/usr/share
touch configure-stamp
 
 build: build-arch build-indep
@@ -63,7 +63,7 @@
[ ! -f 
$(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static ] || 
strip $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static
 endif
 
-   install -D -m 0755 debian/kexec-tools/sbin/kexec 
debian/kexec-tools-udeb/sbin/kexec
+   install -D -m 0755 debian/kexec-tools/usr/sbin/kexec 
debian/kexec-tools-udeb/usr/sbin/kexec
 
 binary-indep: build install
 

Bug#1070304: util-linux: Please build and provide the cal binary

[Michael Meskes]

> 
> > Unfortunately the command line switches
> > are not compatible and util-linux cal cannot display the date of
> > Easter, so it
> > is not drop-in compatible. It would nevertheless be great if e.g.
> > an
> > alternatives selection for util-linux cal could be provided.

The question is does it offer all the other features? Or would we be
better of switching to something like gcal instead?

> I'm somewhat open to shipping util-linux's cal, but not if that
> involves update-alternatives.

Agreed.

> Could you maybe work with upstream, so that util-linux's cal becomes
> a drop-in replacement, and can work as both cal and ncal?
> 
> Also, quite obviously is this something we want to do as Debian?
> Michael, as the maintainer of the current ncal package, what is your
> opinion here?

I wouldn't mind getting rid of the old bsd code base. The package is
heavily patched, which makes maintaining it a lot of work. I would not
like to lose too many features, though. The main reason for keeping
cal, however, namely having a version fully output compatible to the
original one, might not be that valid anymore. After all it's 2024
already.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Bug#1070325: fails to build without a non local IP

[Jochen Sprickerhof]

Source: servefile
Version: 0.5.4-3
Severity: normal
Tags: patch
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

servefile fails to build when self.getIPs() does not return an IP:

Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File 
"/<>/.pybuild/cpython3_3.12_servefile/build/servefile/__main__.py",
 line 3, in 
servefile.main()
  File 
"/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py",
 line 1289, in main
server.serve()
  File 
"/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py",
 line 1008, in serve
self.server.append(self._createServer(self.handler))
   
  File 
"/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py",
 line 982, in _createServer
self.genKeyPair()
  File 
"/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py",
 line 927, in genKeyPair
for ip in self.getIPs() + ["127.0.0.1", "::1"]:
  ~~^~
TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'


This fails in sbuild with the unshare backend. A simple fix would be:

--- servefile-0.5.4.orig/servefile/servefile.py
+++ servefile-0.5.4/servefile/servefile.py
@@ -890,7 +890,7 @@ class ServeFile():
 ips = [ip for ip in ips if ':' in ip]

 return ips
-return None
+return []

 def setSSLKeys(self, cert, key):
 """ Set SSL cert/key. Can be either path to file or pyopenssl 
X509/PKey object. """


Cheers Jochen

Bug#1070286: pipx: The ‘list’ command falsely claims “nothing has been installed with pipx ”

[Manny]

> Maybe something to do with setting a weird PIPX_HOME ?

Good catch. As root:

===8<
$ PIPX_HOME=${prefix:-/opt/}/pipx PIPX_BIN_DIR=${prefix:-/usr/local}/bin pipx 
list
venvs are in /opt/pipx/venvs
apps are exposed on your $PATH at /usr/local/bin
   package argostranslate 1.9.6, installed using Python 3.11.2
- argos-translate
- argospm
===8<

As user:
===8<
$ PIPX_HOME=${prefix:-/opt/}/pipx PIPX_BIN_DIR=${prefix:-/usr/local}/bin pipx 
list
Traceback (most recent call last):
  File "/usr/lib/python3.11/logging/config.py", line 562, in configure
handler = self.configure_handler(handlers[name])
  ^^
  File "/usr/lib/python3.11/logging/config.py", line 747, in configure_handler
result = factory(**kwargs)
 ^
  File "/usr/lib/python3.11/logging/__init__.py", line 1181, in __init__
StreamHandler.__init__(self, self._open())
 
  File "/usr/lib/python3.11/logging/__init__.py", line 1213, in _open
return open_func(self.baseFilename, self.mode,
   ^^^
PermissionError: [Errno 13] Permission denied: 
'/opt/pipx/logs/cmd_2024-05-03_20.14.46.log'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/pipx", line 8, in 
sys.exit(cli())
 ^
  File "/usr/lib/python3/dist-packages/pipx/main.py", line 814, in cli
setup(parsed_pipx_args)
  File "/usr/lib/python3/dist-packages/pipx/main.py", line 753, in setup
setup_logging("verbose" in args and args.verbose)
  File "/usr/lib/python3/dist-packages/pipx/main.py", line 745, in setup_logging
logging.config.dictConfig(logging_config)
  File "/usr/lib/python3.11/logging/config.py", line 812, in dictConfig
dictConfigClass(config).configure()
  File "/usr/lib/python3.11/logging/config.py", line 569, in configure
raise ValueError('Unable to configure handler '
ValueError: Unable to configure handler 'file'
===8<

Which is discussed here:

  https://github.com/pypa/pipx/issues/754#issuecomment-1181082995

I granted read access to /opt/pipx/logs/ for users and it made no
difference. I’ll just have to use root to list pkgs and call it good
enough for me. But certainly it’s a bug for pipx to crash and give a
stack dump. In the very least it should give a specific user-readable
error msg.

Bug#1070324: fails to build when no local ssh server is running

[Jochen Sprickerhof]

Source: python-scrapli
Version: 2023.7.30-2
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

python-scrapli has a test that tries to connect to localhost port 22:

https://sources.debian.org/src/python-scrapli/2023.7.30-2/tests/unit/transport/base/test_base_socket.py/#L6

This fails in sbuild with the unshare backend:


=== FAILURES ===
 test_socket_open_close_isalive 

self = 
socket_address_families = {}

def _connect(self, socket_address_families: Set["socket.AddressFamily"]) -> 
None:
"""
Try to open socket to host using all possible address families

It seems that very occasionally when resolving a hostname (i.e. 
localhost during functional
tests against vrouter devices), a v6 address family will be the first 
af the socket
getaddrinfo returns, in this case, because the qemu hostfwd is not 
listening on ::1, instead
only listening on 127.0.0.1 the connection will fail. Presumably this 
is something that can
happen in real life too... something gets resolved with a v6 address 
but is denying
connections or just not listening on that ipv6 address. This little 
connect wrapper is
intended to deal with these weird scenarios.

Args:
socket_address_families: set of address families available for the 
provided host
really only should ever be v4 AND v6 if providing a hostname 
that resolves with
both addresses, otherwise if you just provide a v4/v6 address 
it will just be a
single address family for that type of address

Returns:
None

Raises:
ScrapliConnectionNotOpened: if socket refuses connection on all 
address families
ScrapliConnectionNotOpened: if socket connection times out on all 
address families

"""
for address_family_index, address_family in 
enumerate(socket_address_families, start=1):
self.sock = socket.socket(address_family, socket.SOCK_STREAM)
self.sock.settimeout(self.timeout)

try:
>   self.sock.connect((self.host, self.port))
E   ConnectionRefusedError: [Errno 111] Connection refused

scrapli/transport/base/base_socket.py:82: ConnectionRefusedError

The above exception was the direct cause of the following exception:

socket_transport = 

def test_socket_open_close_isalive(socket_transport):
"""Test socket initialization/opening"""
assert socket_transport.host == "localhost"
assert socket_transport.port == 22
assert socket_transport.timeout == 10.0

>   socket_transport.open()


Please disable those tests tests:

tests/unit/transport/base/test_base_socket.py::test_socket_open_close_isalive
tests/unit/transport/base/test_base_socket.py::test_socket_bool

Cheers Jochen

Bug#1064459: refining DEP17 patches for glibc and base-files

[Santiago Vila]

Hi.

Since the t64 transition has not finished completely yet (and also
I'd like the dust to settle a little bit after it finish), I've made
another release with minor changes.

The rebased branch is now wip-20240504-usrmerge.

I've also created a rebased branch with changelog called 
wip-20240504-usrmerge-rc.

If you use such rc branch and just change "unreleased" to "unstable"
then I'm ok with you making the upload (no need to send you signed changes),
as I've introduced a little hack to preserve the timestamps of the
common-licenses (this was a prerequisite which I set for myself before
I would switch to git).

Thanks.

Bug#1070323: RM: gnome-shell-extension-bluetooth-quick-connect -- RoM; unmaintained, obsolete with gnome-shell 45

[Jeremy Bícha]

The  new upstream project is
https://github.com/Extensions-Valhalla/gnome-bluetooth-quick-connect

Thank you,
Jeremy Bícha

Bug#1052090: gnome-shell-extension-bluetooth-quick-connect: needs update for GNOME Shell 45

[Jeremy Bícha]

On Sun, Sep 17, 2023 at 9:33 AM Simon McVittie  wrote:
> I don't intend to put time into this change myself, because I no longer
> use this extension (see #1043008), so I'm marking this as serious already
> (justification: "in the package maintainer's opinion, makes the package
> unsuitable for release"). If anyone else in the GNOME team wants to see
> this extension stay available in Debian, now is your chance to take over
> the package, at which point the severity of this bug becomes your choice.
>
> If nobody steps up to maintain it, I will ask for this extension to be
> removed when we are ready for the GNOME Shell 45 transition.

Simon, I filed the removal bug. I haven't really seen complaints
during the 6 months that the extension was removed from Testing.

The upstream project was archived. However I noted in the removal bug,
that there is a fork:
https://github.com/Extensions-Valhalla/gnome-bluetooth-quick-connect
But the fork switched to TypeScript which might make it difficult to
package for Debian main.

Thank you,
Jeremy Bícha

Bug#1070323: RM: gnome-shell-extension-bluetooth-quick-connect -- RoM; unmaintained, obsolete with gnome-shell 45

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc:gnome-shell-extension-bluetooth-quick-conn...@packages.debian.org
Control: affects -1 src:gnome-shell-extension-bluetooth-quick-connect

Please remove gnome-shell-extension-bluetooth-quick-connect from
Debian. It is no longer maintained upstream:
https://github.com/bjarosze/gnome-bluetooth-quick-connect

Its functionality has basically been incorporated into GNOME Shell 45
which we intend to land in Unstable soon after the t64 transition
completes.

There does happen to be a forked version but it uses TypeScript. I've
not looked closely at that version but in my experience, GNOME
Typescript packages are difficult to package for Debian main.

On behalf of the Debian GNOME Maintainers,
Jeremy Bícha

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

# splt up the LO and kio parts properly

clone 1069835 -1

reassign -1 kio

retitle -1 kio: Don't leak existing file handles to newly spanwed KIO 
workers


block 1069835 by -1

# LOs part is done, at least for this one.

close 1069835 4:24.2.2-1

thanks


Am 03.05.24 um 10:54 schrieb Andreas B. Mundt:

On Fri, May 03, 2024 at 10:18:22AM +0200, Sune Stolborg Vuorela wrote:

On Friday, May 3, 2024 10:06:27 AM CEST you wrote:

On Thu, May 02, 2024 at 04:37:30PM +0200, Sune Stolborg Vuorela wrote:

[…]

If it works for you, I'll ask the debian kde maintainers to fix it.


It looks like it fixes the libreoffice issue (no modifications applied
to libreoffice).  With a patched kio package I was not able to
reproduce the issue.  Replacing just the kio binary package seems to
be sufficient.  We are going to test a bit more on other setups too.

Tested with libreoffice from bookworm-backports:  Fixed.

Cool. So that means we don't even need the LO part here?

The changes needed to libreoffice are already in Debian ( https://
gerrit.libreoffice.org/c/core/+/162935 ) - also by Kevin Ottens who also
authored this patch.

Great!


Yes, that is the one mentioned earlier and fixed in 24.2.2.


Cleaning those bugs up and making an own one for kio.


Regards,


Rene

Bug#1066470: kxl: FTBFS: KXLsound.c:75:9: error: implicit declaration of function 'read'; did you mean 'fread'? [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:52:04 +0100, Lucas Nussbaum wrote:
> Source: kxl
> Version: 1.1.7-17
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> >  gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"KXL\" 
> > -DVERSION=\"1.1.7\" -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
> > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
> > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
> > -DHAVE_FCNTL_H=1 -DHAVE_MALLOC_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 
> > -DHAVE_LINUX_JOYSTICK_H=1 -DHAVE_LINUX_SOUNDCARD_H=1 -DTIME_WITH_SYS_TIME=1 
> > -DRETSIGTYPE=void -DHAVE_SELECT=1 -I. -I. -Wdate-time -D_FORTIFY_SOURCE=2 
> > -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > -c KXLjoystick.c  -fPIC -DPIC -o .libs/KXLjoystick.o
> > KXLmisc.c: In function 'KXL_ReadU16':
> > KXLmisc.c:196:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   196 |   fread(c, 1, 2, fp);
> >   |   ^~
> > KXLmisc.c: In function 'KXL_ReadU32':
> > KXLmisc.c:209:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   209 |   fread(c, 1, 4, fp);
> >   |   ^~
> > KXLsound.c: In function 'KXL_SoundServer':
> > KXLsound.c:75:9: error: implicit declaration of function 'read'; did you 
> > mean 'fread'? [-Werror=implicit-function-declaration]
> >75 | if (read(KXL_SoundData.Pipe[0], ,sizeof(Command)) != 
> > sizeof(Command))
> >   | ^~~~
> >   | fread
> > KXLsound.c:165:9: error: implicit declaration of function 'write'; did you 
> > mean 'fwrite'? [-Werror=implicit-function-declaration]
> >   165 | write(KXL_SoundData.Device, KXL_SoundData.PBuff, 
> > fragment_size);
> >   | ^
> >   | fwrite
> > KXLimage.c: In function 'KXL_ReadBitmapHeader':
> > KXLimage.c:112:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   112 |   fread(hed->magic, 1, 2, fp);
> >   |   ^~~
> > KXLimage.c:166:7: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   166 |   fread(&(hed->data[i * hed->w]), hed->w, 1, fp);
> >   |   ^~
> > KXLsound.c: In function 'KXL_InitSound':
> > KXLsound.c:262:7: error: implicit declaration of function 'pipe' 
> > [-Werror=implicit-function-declaration]
> >   262 |   if (pipe(KXL_SoundData.Pipe) < 0) {
> >   |   ^~~~
> > KXLsound.c:267:27: error: implicit declaration of function 'fork' 
> > [-Werror=implicit-function-declaration]
> >   267 |   if ((KXL_SoundData.ID = fork()) < 0) {
> >   |   ^~~~
> > KXLsound.c:273:5: error: implicit declaration of function 'close'; did you 
> > mean 'pclose'? [-Werror=implicit-function-declaration]
> >   273 | close(KXL_SoundData.Pipe[1]);
> >   | ^
> >   | pclose
> > KXLsound.c: In function 'KXL_LoadSound':
> > KXLsound.c:213:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   213 |   fread(dummy, sizeof(Uint8), 40, file);
> >   |   ^
> > KXLsound.c:216:3: warning: ignoring return value of 'fread' declared with 
> > attribute 'warn_unused_result' [-Wunused-result]
> >   216 |   fread(new.Data, sizeof(Uint8), new.Length, file);
> >   |   ^~~~
> > KXLjoystick.c: In function 'KXL_CloseJoystick':
> > KXLjoystick.c:43:5: error: implicit declaration of function 'close'; did 
> > you mean 'pclose'? [-Werror=implicit-function-declaration]
> >43 | close(KXL_joydev);
> >   | ^
> >   | pclose
> > KXLjoystick.c: In function 'KXL_ReadJoystick':
> > KXLjoystick.c:55:9: error: implicit declaration of function 'read'; did you 
> > mean 'fread'? [-Werror=implicit-function-declaration]
> >55 | if (read(KXL_joydev, my, JS_RETURN) == JS_RETURN) {
> >   | ^~~~
> >   | fread
> >  gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"KXL\" 
> > -DVERSION=\"1.1.7\" -DHAVE_SYS_TYPES_H=1 

Bug#1070304: util-linux: Please build and provide the cal binary

[Jörg Behrmann]

On Fri, May 03, 2024 at 05:38:46PM +0200, Chris Hofstaedtler wrote:
> > Unfortunately the command line switches
> > are not compatible and util-linux cal cannot display the date of Easter, so 
> > it
> > is not drop-in compatible. It would nevertheless be great if e.g. an
> > alternatives selection for util-linux cal could be provided.
> 
> I'm somewhat open to shipping util-linux's cal, but not if that
> involves update-alternatives.
> 
> Could you maybe work with upstream, so that util-linux's cal becomes
> a drop-in replacement, and can work as both cal and ncal?
>

I think that ship has sailed already, since e.g. -m in the ncal version
specifies the month (a bit superfluously), whereas in the util-linux version it
sets the beginning of the week to Monday.

> Also, quite obviously is this something we want to do as Debian?
> Michael, as the maintainer of the current ncal package, what is your
> opinion here?
> 

An alternative I could see would be to drop cal from the ncal package and only
provide cal from util-linux.

Nothing would be lost, since ncal can act as cal with the -C option, so users
wanting that specific cal could use a function

cal() {
ncal -C $@
}

and the rest would get a cal that can show week numbers and set the beginning of
the Monday.


signature.asc
Description: PGP signature

Bug#1070286: pipx: The ‘list’ command falsely claims “nothing has been installed with pipx ”

[Stefano Rivera]

Hi Manny (2024.05.03_09:47:23_+)
>   $ PIPX_HOME=${prefix:-/opt/}/pipx PIPX_BIN_DIR=${prefix:-/usr/local}/bin 
> pipx install --verbose argostranslate

...

> The argostranslate app runs fine. So it’s unclear why pipx would lose
> track of it right away.

Maybe something to do with setting a weird PIPX_HOME ?

Stefano

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

Bug#983606: base-files: umask is not set for superuser

[Santiago Vila]

El 27/2/21 a las 9:48, g1 escribió:

Package: base-files
Version: 10.3+deb10u8
Severity: normal

In /usr/share/base-files/dot.bashrc (which is copied to /root/.bashrc
at package installation) the umask command is commented out, with this
explanation:

 # Note: PS1 and umask are already set in /etc/profile. You should not
 # need this unless you want different defaults for root.

That's not true anymore: umask is not set in /usr/share/base-files/profile
(copied to /etc/profile) or in /usr/share/base-files/dot.profile (copied
to /root/.profile).

As a result, umask for the superuser is never set explicitly, just
inherited, perhaps from an unprivileged shell.  Which can have unpleasant
effects:
[...]


Changing the umask for root might be controversial, and I prefer not to,
as I'm not convinced that a different umask is necessarily better in
all aspects.

The message that the comment was trying to convey was that you only need
to cnange PS1 or umask if you don't like the defaults (regardless of
where those defaults come from). So, I'll update the default message
so that it tells the truth again (i.e. the default umask is set in login.defs).

Thanks.

Bug#1066671: geki3: FTBFS: boss.c:205:11: error: implicit declaration of function ‘CreateEnemyBomb’; did you mean ‘CreateEnemyShot’? [-Werror=implicit-function-declaration]

[Guillem Jover]

Hi!

On Fri, 2024-05-03 at 12:57:21 +0200, Guillem Jover wrote:
> The attached patch should fix this FTBFS

Sorry, please use the attached patch instead which fixes some typos in
the patch description.

Thanks,
Guillem
diff --git c/debian/patches/020_headers.diff i/debian/patches/020_headers.diff
index 106a56b..23dfadb 100644
--- c/debian/patches/020_headers.diff
+++ i/debian/patches/020_headers.diff
@@ -1,22 +1,19 @@
-Index: geki3-1.0.3/src/ranking.c
-===
 geki3-1.0.3.orig/src/ranking.c 2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/ranking.c  2006-05-09 20:38:01.0 +0200
-@@ -1,4 +1,5 @@
- #include 
-+#include 
- #include "geki3.h"
- #include "extern.h"
- 
-Index: geki3-1.0.3/src/geki3.h
-===
 geki3-1.0.3.orig/src/geki3.h   2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/geki3.h2006-05-09 20:38:01.0 +0200
-@@ -9,6 +9,7 @@
+---
+ src/geki3.h |3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/src/geki3.h
 b/src/geki3.h
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include "KXL.h"
+ 
diff --git c/debian/patches/020_implicit-decl.patch 
i/debian/patches/020_implicit-decl.patch
new file mode 100644
index 000..ba22660
--- /dev/null
+++ i/debian/patches/020_implicit-decl.patch
@@ -0,0 +1,59 @@
+Description: Add and fix function declarations
+ With the compiler setting -Werror=implicit-function-declaration by default,
+ we need to properly declare all functions in the relevant headers.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+---
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.h |2 +-
+ src/your.h|2 ++
+ 4 files changed, 5 insertions(+), 2 deletions(-)
+
+--- a/src/your.h
 b/src/your.h
+@@ -6,9 +6,11 @@ void CreateItem(Sint16 x, Sint16 y, PixD
+ RcHitEnum HitEnemyToBall(CharacterData *my, CharacterData *your);
+ 
+ /** Bomb **/
++void CreateEnemyBomb(Sint16 x, Sint16 y, Uint16 direction, Uint16 speed);
+ RcHitEnum MoveBomb(CharacterData *my);
+ RcHitEnum HitEnemyToBomb(CharacterData *my, CharacterData *your);
+ RcHitEnum MoveEnemyBomb(CharacterData *my);
++void CreateMissile(CharacterData *my, Sint16 x, Sint16 y);
+ RcHitEnum MoveMissile(CharacterData *my);
+ void CreateEnemyShot(Sint16 x, Sint16 y, Uint16 direction, Uint16
+speed, Uint8 sel);
+--- a/src/load.c
 b/src/load.c
+@@ -221,7 +221,7 @@ void LoadStageData(void)
+ /**
+   ���ơǡ��
+  **/
+-void UnLoadStageData()
++void UnLoadStageData(void)
+ {
+   Uint16 bossmax[] = {3, 6, 4, 4};
+ 
+--- a/src/load.h
 b/src/load.h
+@@ -9,5 +9,6 @@ void UnLoadPixmaps(PixData **my, Uint16
+ void CreatePixmap(void);
+ void DeletePixmap(void);
+ void LoadStageData(void);
++void UnLoadStageData(void);
+ 
+ #endif
+--- a/src/ranking.h
 b/src/ranking.h
+@@ -1,7 +1,7 @@
+ #ifndef _RANKING_H_
+ #define _RANKING_H_
+ 
+-void RankingScore(void);
++int ScoreRanking(void);
+ void ReadScore(void);
+ void WriteScore(void);
+ 
diff --git c/debian/patches/020_score_path.diff 
i/debian/patches/020_score_path.diff
index 313a0c2..b3b2dab 100644
--- c/debian/patches/020_score_path.diff
+++ i/debian/patches/020_score_path.diff
@@ -1,8 +1,10 @@
-Index: geki3-1.0.3/src/ranking.c
-===
 geki3-1.0.3.orig/src/ranking.c 2006-05-09 20:42:06.0 +0200
-+++ geki3-1.0.3/src/ranking.c  2006-05-09 20:42:55.0 +0200
-@@ -38,7 +38,7 @@
+---
+ src/ranking.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/src/ranking.c
 b/src/ranking.c
+@@ -37,7 +37,7 @@ void ReadScore(void)
FILE *fp;
Uint16 i;
  
@@ -11,7 +13,7 @@ Index: geki3-1.0.3/src/ranking.c
  fscanf(fp, "%"SCNu32, &(Root->HiScore));
  for (i = 0; i < 5; i ++)
fscanf(fp, "%"SCNu32" %"SCNu8" %"SCNu8" %s",
-@@ -70,7 +70,7 @@
+@@ -69,7 +69,7 @@ void WriteScore(void)
FILE *fp;
Uint16 i;
  
diff --git c/debian/patches/020_shot_keys.diff 
i/debian/patches/020_shot_keys.diff
index cb35fe5..02b54f8 100644
--- c/debian/patches/020_shot_keys.diff
+++ i/debian/patches/020_shot_keys.diff
@@ -1,8 +1,12 @@
-Index: geki3-1.0.3/src/main.c
-===
 geki3-1.0.3.orig/src/main.c2002-08-05 12:35:58.0 +0200
-+++ geki3-1.0.3/src/main.c 2006-05-09 20:39:45.0 +0200
-@@ -23,6 +23,7 @@
+---
+ src/geki3.h   |2 ++
+ src/main.c|2 ++
+ src/opening.c |4 ++--
+ 3 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/src/main.c
 b/src/main.c
+@@ -23,6 +23,7 @@ void MainLoop(void)
case KXL_EVENT_KEY_PRESS: /*��*/
  switch (KXL_GetKey()) {
  case KeyShot:  Root->Key |= KShot;  break;

Bug#1066549: geki2: FTBFS: misc.c:127:7: error: implicit declaration of function ‘ScoreRanking’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Hi!

On Fri, 2024-05-03 at 13:06:21 +0200, Guillem Jover wrote:
> Actually, the attached debdiff should be better (properly split
> patches).

Hrmmf, sorry, please use the attached patch, which fixes some typos in
the patch description. :)

Thanks,
Guillem
diff -Nru geki2-2.0.3/debian/patches/020_headers.diff 
geki2-2.0.3/debian/patches/020_headers.diff
--- geki2-2.0.3/debian/patches/020_headers.diff 2018-05-13 16:22:49.0 
+0200
+++ geki2-2.0.3/debian/patches/020_headers.diff 2024-05-03 13:00:11.0 
+0200
@@ -4,29 +4,25 @@
 
 ===
 ---
- src/geki2.h   | 1 +
- src/ranking.c | 1 +
- 2 files changed, 2 insertions(+)
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
 
-diff --git a/src/geki2.h b/src/geki2.h
-index 938d760..b293afb 100644
 --- a/src/geki2.h
 +++ b/src/geki2.h
-@@ -9,6 +9,7 @@
+@@ -7,9 +7,12 @@
+ #ifndef _GEKI2_H_
+ #define _GEKI2_H_
  
++#include 
  #include 
  #include 
 +#include 
  #include 
++#include 
  #include 
  #include 
-diff --git a/src/ranking.c b/src/ranking.c
-index a6683c5..4e3df6c 100644
 a/src/ranking.c
-+++ b/src/ranking.c
-@@ -1,4 +1,5 @@
- #include 
-+#include 
- #include "geki2.h"
- #include "extern.h"
  
diff -Nru geki2-2.0.3/debian/patches/020_implicit-decl.patch 
geki2-2.0.3/debian/patches/020_implicit-decl.patch
--- geki2-2.0.3/debian/patches/020_implicit-decl.patch  1970-01-01 
01:00:00.0 +0100
+++ geki2-2.0.3/debian/patches/020_implicit-decl.patch  2024-05-03 
12:59:08.0 +0200
@@ -0,0 +1,47 @@
+Description: Add and fix function declarations
+ With the compiler setting -Werror=implicit-function-declaration by default,
+ we need to properly declare all functions in the relevant headers.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+===
+---
+ src/geki2.h   |3 +++
+ src/load.c|2 +-
+ src/load.h|1 +
+ src/ranking.c |1 +
+ src/ranking.h |2 +-
+ 5 files changed, 7 insertions(+), 2 deletions(-)
+
+--- a/src/load.c
 b/src/load.c
+@@ -237,7 +237,7 @@ void LoadStageData(void)
+ /**
+   ���ơǡ��
+  **/
+-void UnLoadStageData()
++void UnLoadStageData(void)
+ {
+   Uint8 bossmax[] = {2, 3 * 2, 1 * 2, 1 * 2, 1 * 2, 1 * 2};
+   Uint8 backmax[] = {7, 16, 20, 8, 18, 15};
+--- a/src/load.h
 b/src/load.h
+@@ -9,5 +9,6 @@ void UnLoadPixmaps(PixData **my, int max
+ void CreatePixmap(void);
+ void DeletePixmap(void);
+ void LoadStageData(void);
++void UnLoadStageData(void);
+ 
+ #endif
+--- a/src/ranking.h
 b/src/ranking.h
+@@ -1,7 +1,7 @@
+ #ifndef _RANKING_H_
+ #define _RANKING_H_
+ 
+-void RankingScore(void);
++int ScoreRanking(void);
+ void ReadScore(void);
+ void WriteScore(void);
+ 
diff -Nru geki2-2.0.3/debian/patches/020_scanf.diff 
geki2-2.0.3/debian/patches/020_scanf.diff
--- geki2-2.0.3/debian/patches/020_scanf.diff   2018-05-13 16:22:49.0 
+0200
+++ geki2-2.0.3/debian/patches/020_scanf.diff   2024-05-03 13:03:10.0 
+0200
@@ -4,12 +4,10 @@
 
 ===
 ---
- src/load.c| 2 +-
- src/ranking.c | 4 ++--
+ src/load.c|2 +-
+ src/ranking.c |4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)
 
-diff --git a/src/load.c b/src/load.c
-index e771eca..284ed8f 100644
 --- a/src/load.c
 +++ b/src/load.c
 @@ -216,7 +216,7 @@ void LoadStageData(void)
@@ -21,11 +19,9 @@
 &(StageDatas[Root->StageMax]->Time),
 &(StageDatas[Root->StageMax]->CreateNo),
 &(StageDatas[Root->StageMax]->Max),
-diff --git a/src/ranking.c b/src/ranking.c
-index 4e3df6c..2ed04af 100644
 --- a/src/ranking.c
 +++ b/src/ranking.c
-@@ -39,9 +39,9 @@ void ReadScore(void)
+@@ -38,9 +38,9 @@ void ReadScore(void)
Uint16 i;
  
if ((fp = fopen(DATA_PATH "/.score", "r"))) {
diff -Nru geki2-2.0.3/debian/patches/020_score_path.diff 
geki2-2.0.3/debian/patches/020_score_path.diff
--- geki2-2.0.3/debian/patches/020_score_path.diff  2018-05-13 
16:22:49.0 +0200
+++ geki2-2.0.3/debian/patches/020_score_path.diff  2024-05-03 
13:03:13.0 +0200
@@ -4,14 +4,12 @@
 
 ===
 ---
- src/ranking.c | 4 ++--
+ src/ranking.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
-diff --git a/src/ranking.c b/src/ranking.c
-index 2ed04af..fe3f4fc 100644
 --- a/src/ranking.c
 +++ b/src/ranking.c
-@@ -38,7 +38,7 @@ void ReadScore(void)
+@@ -37,7 +37,7 @@ void ReadScore(void)
FILE *fp;
Uint16 i;
  
@@ -20,7 +18,7 @@
  fscanf(fp, "%"SCNu32, &(Root->HiScore));
  for (i = 0; i < 5; i ++)
fscanf(fp, "%"SCNu32" %"SCNu8" %"SCNu8" %s",
-@@ -70,7 +70,7 @@ void WriteScore(void)
+@@ -69,7 +69,7 @@ void WriteScore(void)

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Santiago Vila]

[ Replying to both ]

Richard Lewis wrote:

On Thu, 18 Apr 2024, 23:18 Santiago Vila, mailto:sanv...@debian.org>> wrote:
(I'd like to avoid spamming the users with non-important information)

[...]

- NEWS.Debian is "opt-in": if you install apt-listchanges you'll see 
NEWS.Debian, but that package isnt installed by the default. Even fewer users will read 
the changelog (although apt-listchanges can email that as well)


Thanks a lot for the detailed investigation!

I think the item I've quoted is key: I was afraid of spamming the users via
NEWS.Debian but as you point out, NEWS.Debian is an established channel for
exactly this kind of things.

Vincent Lefevre wrote:

As a user of both Debian/stable and Debian/unstable machines,
I have apt-listchanges installed on all machines, but this is
most useful for Debian/unstable (I also have a quick look at
the changelog). I don't remember about the release notes with
stable upgrades.

BTW, during the package upgrade, if there are /etc/profile.d files
that were sourced but that will no longer be, I think that the user
should specifically be warned about them.

I'm also wondering whether some message should be output on the
standard error if there are *.sh files that do not satisfy the
regexp (but run-parts cannot do that).


The last two items seem overkill to me, considering that we never promised
any given behaviour at all. In fact, the current behaviour is actually
undefined, we can't even tell for sure what is exactly what the user would
get (see #1069279 for details).

So, I'm going to try with NEWS.Debian first, and if that's not enough,
we'll ask release-notes editors to add a very small note about this.

Thanks.

Bug#1070321: transition: nginx ABI change: nginx-abi-1.24.0-1 -> nginx-abi-1.26.0-1

[Jan Mojzis]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: ng...@packages.debian.org
Control: affects -1 + src:nginx

Hi,

a new version 1.26.0 of nginx has been released.

I have uploaded version 1.26.0-1~exp1 to the experimental and
would like to upload the new nginx 1.26.0-1 version to the unstable.

And with the upload of 1.26.0-1 nginx to unstable,
the nginx ABI version changes at the same time. Previous ABI 
nginx-abi-1.24.0-1, new ABI nginx-abi-1.26.0-1.

Therefore, we would also need to rebuild all 3rd party nginx modules 
(libnginx-mod-* packages)
which depends on nginx. Hence the transition request.

Furthermore, this upload/rebuild solves the problem that arises at time_t 64 
transition:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069997


Ben file:

title = "nginx";
is_affected = .build-depends ~ /nginx-dev/;
is_good = .depends ~ /nginx-abi-1.26.0-1/;
is_bad = .depends ~ /nginx-abi-1.24.0-1/;


Please when the nginx 1.26.0-1 arives to the unstable,
can You schedule binNMUs for the above mentioned packages in unstable on all 
architectures.

Thanks
Jan

PS: ABI versioning is a relatively new feature in nginx, so this is the first 
transition request.
And any ideas how to automate the transitions are welcome

Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command

[Stefano Rivera]

Hi Manny (2024.05.03_09:01:10_+)
> I would report upstream if the bug tracker were hosted in a more open
> and neutral place. Microsoft venues are places I will not go to
> interact, apart from searching to see if a report already exists.
> Github in particular has access problems.

I can understand and respect that. But at the same time, I am not your
bug proxy. So this bug will just sit here, and not be much use to
anyone.

BTW, there is a #pip on the PyPA discord, if you want to interact with
Pip upstream, off GitHub.

> Debian shelters users with this bug reporting policy¹:
> 
>   “Don't file bugs upstream
> 
>If you file a bug in Debian, don't send a copy to the upstream
>software maintainers yourself, as it is possible that the bug
>exists only in Debian. If necessary, the maintainer of the package
>will forward the bug upstream.”

I generally think that's a bad policy. There are situations where that
makes sense. But in most cases, filing the bug upstream is the best way
to get it fixed.

Stefano

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

Bug#1066390: gravitywars: FTBFS: misc.c:6:9: error: implicit declaration of function ‘keyboard_update’ [-Werror=implicit-function-declaration]

[Guillem Jover]

Control: tag -1 patch

Hi!

On Wed, 2024-03-13 at 12:51:07 +0100, Lucas Nussbaum wrote:
> Source: gravitywars
> Version: 1.102-35
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > cc -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> > -DUSE_SDL -DUSE_JOYSTICK `pkg-config sdl --cflags` -Wdate-time 
> > -D_FORTIFY_SOURCE=2  -c -o blocks.o blocks.c
> > misc.c: In function ‘waitanykey’:
> > misc.c:6:9: error: implicit declaration of function ‘keyboard_update’ 
> > [-Werror=implicit-function-declaration]
> > 6 |   while(keyboard_update())
> >   | ^~~
> > misc.c:7:5: error: implicit declaration of function ‘vga_waitretrace’ 
> > [-Werror=implicit-function-declaration]
> > 7 | vga_waitretrace();
> >   | ^~~
> > misc.c: In function ‘doPanic’:
> > misc.c:18:3: error: implicit declaration of function ‘printf’ 
> > [-Werror=implicit-function-declaration]
> >18 |   printf("--\n"
> >   |   ^~
> > misc.c:1:1: note: include ‘’ or provide a declaration of ‘printf’
> >   +++ |+#include 
> > 1 | /* GravityWars 1.1,  (C) Sami Niemi -95 */
> > misc.c:18:3: warning: incompatible implicit declaration of built-in 
> > function ‘printf’ [-Wbuiltin-declaration-mismatch]
> >18 |   printf("--\n"
> >   |   ^~
> > misc.c:18:3: note: include ‘’ or provide a declaration of ‘printf’
> > misc.c:21:3: error: implicit declaration of function ‘keyboard_close’ 
> > [-Werror=implicit-function-declaration]
> >21 |   keyboard_close();
> >   |   ^~
> > misc.c:22:3: error: implicit declaration of function ‘mouse_close’ 
> > [-Werror=implicit-function-declaration]
> >22 |   mouse_close();
> >   |   ^~~
> > misc.c:23:3: error: implicit declaration of function ‘exit’ 
> > [-Werror=implicit-function-declaration]
> >23 |   exit(1);
> >   |   ^~~~
> > misc.c:1:1: note: include ‘’ or provide a declaration of ‘exit’
> >   +++ |+#include 
> > 1 | /* GravityWars 1.1,  (C) Sami Niemi -95 */
> > misc.c:23:3: warning: incompatible implicit declaration of built-in 
> > function ‘exit’ [-Wbuiltin-declaration-mismatch]
> >23 |   exit(1);
> >   |   ^~~~
> > misc.c:23:3: note: include ‘’ or provide a declaration of ‘exit’
> > hole.c: In function ‘OLDmakehole’:
> > hole.c:30:3: error: implicit declaration of function ‘vga_setpage’ 
> > [-Werror=implicit-function-declaration]
> >30 |   vga_setpage(page);
> >   |   ^~~
> > hole.c: In function ‘makehole’:
> > hole.c:68:3: error: implicit declaration of function ‘getbox’ 
> > [-Werror=implicit-function-declaration]
> >68 |   getbox(x,y,tmpmix);
> >   |   ^~
> > hole.c:80:3: error: implicit declaration of function ‘changeblocks’ 
> > [-Werror=implicit-function-declaration]
> >80 |   changeblocks(x,y,tmpmix);
> >   |   ^~~~
> > pixel.c: In function ‘setpixel’:
> > pixel.c:11:3: error: implicit declaration of function ‘vga_setpage’ 
> > [-Werror=implicit-function-declaration]
> >11 |   vga_setpage(adr >> 16);
> >   |   ^~~
> > bullet.c: In function ‘setbullet’:
> > bullet.c:17:3: error: implicit declaration of function ‘vga_setpage’ 
> > [-Werror=implicit-function-declaration]
> >17 |   vga_setpage(page);
> >   |   ^~~
> > cc1: some warnings being treated as errors
> > make[2]: *** [: misc.o] Error 1

The attached debdiff patch should fix this.

I pondered creating a single header and including all declarations
there to have a smaller delta, but decided to follow the existing
pattern in the project. If you'd prefer to see a single header,
instead of all new headers, I'm happy to rework the patch.

Thanks,
Guillem
diff -Nru gravitywars-1.102/debian/patches/implicit-decls.patch gravitywars-1.102/debian/patches/implicit-decls.patch
--- gravitywars-1.102/debian/patches/implicit-decls.patch	1970-01-01 01:00:00.0 +0100
+++ gravitywars-1.102/debian/patches/implicit-decls.patch	2024-05-03 18:57:53.0 +0200
@@ -0,0 +1,412 @@
+Description: Add function declarations
+ With the compiler setting -Werror=implicit-function-declaration by default,
+ we need to properly declare all functions in the relevant headers.
+ .
+ Create one header per C file to match the existing code patterns, even
+ though those where very partially implemented.
+Author: Guillem Jover 
+Origin: vendor

Bug#990451: apt: the --no-all-versions option not working as documented

[Manny]

> I think you meant All*Versions*, not Names.

Oh, right.. must have been a copy-paste error.

> fwiw: I don't know about aptitude and if you think it should get some
> feature I suppose you should report it there, but for apt(-get) I have
> to note that both display "download size" as the size of all *.deb
> files to be downloaded from non-local (that mostly means non-file:/)
> sources…

Thanks!  That’s useful indeed.

> Not sure about the later "each source location"… that can turn out to be
> a lot of details for not that much gain: a typical Debian stable has
> 'normal', 'updates' and 'security'. You could add 'proposed' and e.g.
> 'backports' and a random set of 3rd parties like the typical Ubuntu user
> with seemingly 42+ PPAs added. That is 3+X counters useless even to you
> as you were just interested in the data coming from your local mirror
> vs. others. And that would assume that all mirrors are complete and
> available, no retries, no fallbacks, no redirects.

Indeed the cloud vs. local counts are the most useful. I was thinking
in terms of luxury. Many different sources being fetched in parallel
would give the expectation of a fast fetch. And if some are fetched
over tor or a slow host, it would also give an indication of time. And
if something comes from a Tor source and your in a place that blocks
Tor, that’s marginally useful information.  But indeed the effort
would not be justfied with apt and apt-get already giving what’s
needed.

>From there, I suppose my use-case does not justify making
--no-all-versions function. But the man page should at least reflect
reality.

Bug#1070320: slurm-wlm-contrib: libpmix-dev only available on 64-bit architectures

[Bas Couwenberg]

Source: slurm-wlm-contrib
Version: 23.11.4-1
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: block 1070316 by -1

Dear Maintainer,

Your package unconditionally build depends on libpmix-dev which is now only 
available on 64-bit architectures.

You should limit the architectures like slurm-wlm does:

 libpmix-dev [amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 
ppc64 sparc64],

Kind Regards,

Bas

Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures

[Samuel Thibault]

Hello,

This has been posing migration issues for quite some time, I have
uploaded the attached fix to delayed/0.

Samuel
diff -Nru openmpi-4.1.6/debian/changelog openmpi-4.1.6/debian/changelog
--- openmpi-4.1.6/debian/changelog  2024-04-27 18:37:26.0 +0200
+++ openmpi-4.1.6/debian/changelog  2024-05-03 18:53:52.0 +0200
@@ -1,3 +1,10 @@
+openmpi (4.1.6-13.1) unstable; urgency=medium
+
+  * Non-maintainer Upload
+  * Also install pmix components on 32-bit systems. Closes: #1070300
+
+ -- Samuel Thibault   Fri, 03 May 2024 18:53:52 +0200
+
 openmpi (4.1.6-13) unstable; urgency=medium
 
   * Move pmix help files to libopenmpi3t64, not openmpi3-common
diff -Nru openmpi-4.1.6/debian/rules openmpi-4.1.6/debian/rules
--- openmpi-4.1.6/debian/rules  2024-04-27 18:37:26.0 +0200
+++ openmpi-4.1.6/debian/rules  2024-05-03 18:49:28.0 +0200
@@ -287,7 +287,8 @@
if $(DO_OWN_PMIX); then \
echo "PMIX: install " ;  \
dh_install -p libopenmpi3t64 
$(LIBDIR)/openmpi/lib/libpmix.so.2.2.35 $(LIBDIR) ; \
-   dh_install -p libopenmpi3t64 /usr/share/pmix/* ; \
+   dh_install -p libopenmpi3t64 /usr/share/pmix ; \
+   dh_install -p libopenmpi3t64 
/usr/lib/$(DEB_HOST_MULTIARCH)/openmpi/lib/pmix ; \
dh_link -p libopenmpi3t64 $(LIBDIR)/libpmix.so.2.2.35 
$(LIBDIR)/libpmix.so.2  ; \
dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2
$(LIBDIR)/openmpi/lib/libpmix.so ; \
dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2
$(LIBDIR)/libpmix.so ; \

Bug#1070317: fails to build without a non lo IP address

[Jochen Sprickerhof]

* Jochen Sprickerhof  [2024-05-03 18:55]:

This fails in sbuild with the chroot backend:


I mean the unshare backend.


signature.asc
Description: PGP signature

Bug#1070319: fails to build without a non lo IP address

[Jochen Sprickerhof]

Source: google-guest-agent
Version: 2026.00-6
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

google-guest-agent has a test that depends on having an IP address
available in the build environment:

https://sources.debian.org/src/google-guest-agent/2026.00-6/google_guest_agent/wsfc_test.go/#L206

This fails in sbuild with the unshare backend:

=== RUN   TestWsfcRunAgentE2E
wsfc_test.go:207: health check failed with , got = , want 1
wsfc_test.go:209: EOF
--- FAIL: TestWsfcRunAgentE2E (1.00s)

Cheers Jochen

Bug#1023405: unrar-free: Removed licenses/copyright in new upstream version

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this and the other open 
issues.
Please find the debdiff attached.

unrar-free_0.3.0-0.1.debdiff
Description: Binary data

Bug#1070318: mpich: libpmix-dev only available on 64-bit architectures

[Bas Couwenberg]

Source: mpich
Version: 4.2.0-5.1
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: block 1070316 by -1

Dear Maintainer,

Your package unconditionally build depends on libpmix-dev which is now only 
available on 64-bit architectures.

You should limit the architectures like openmpi does:

 libpmix-dev [amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 
ppc64 sparc64],

Kind Regards,

Bas

Bug#1070316: RM: pmix [i386 armel armhf] -- RoQA; 32-bit architectures no longer supported

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: p...@packages.debian.org
Control: affects -1 + src:pmix
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove pmix from the 32-bit release architectures where it's no longer 
built.

Bug#1070317: fails to build without a non lo IP address

[Jochen Sprickerhof]

Source: golang-github-likexian-gokit
Version: 0.25.9-3
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org


Hi,

golang-github-likexian-gokit has a test that depends on having an IP
address available in the build environment:

https://sources.debian.org/src/golang-github-likexian-gokit/0.25.9-3/xip/xip_test.go/#L213

This fails in sbuild with the chroot backend:

=== RUN   TestGetEthIPv4
assert.go:197: 
/<>/obj-x86_64-linux-gnu/src/github.com/likexian/gokit/xip/xip_test.go:213
assert.go:172: ! expected true, but got false
--- FAIL: TestGetEthIPv4 (0.00s)

Cheers Jochen

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim,

reviewing your new package:

- d/changelog
  - generally documents only changes to the packaging, not "upstream" changes
(the entry "Fixed logrotate conf user name" is an upstream change.)
There are exceptions, like if it a very noteworthy change, but this
is one isn't in that category.
  - When packaging a new upstream version, you say so in the changelog.
(Like first changelog entry: 
 * New upstream version.
)
  - There are undocumented changes, for example the change to the
Standard-Version. 

A nitpick on d/rules:
 I'm a fan of declarative syntax, so I'd replace the dh_clean override
 with specifing the file to be deleted in the file d/clean. (If you feel
 different about this, it is ok to ignore my nitpicking)

Remarks on Readme.md: 
  - It cointains only information not relevant when the user is
installing the binary package (like how to build, how to install and
where to find the packages), so it should not be installed into
the binary package.
  - "Debian" is written with a captial "D".
  - The sentence "Unfortunately Debian armhf packages do not 
run on Raspberry Pi 1 although the architecture on the RPi is named armhf.
Using Raspian armhf packages fixes that." is a bit hard to parse, a
bit off:
- Raspberry Pi 1 is supported by the Debian armel architecture, so people
  running (real) Debian on the Pi 1 need to use "armel" not "armhf".
- Paspian has been renamed to Raspberry Pi OS, so the naming should
  maybe be also updated.

Maybe this should be separated into a Debian and Raspberry Pi OS
section? (They are different distributions anyways…)

  
Some parts already mentioned for the previous upload, would be great if
you could start tackling them:

As you are involved with upstream:
The manpage, initfile, systemd service file should probably be included in the
upstream part, it is not only useful for Debian alone.

Linitian: (I've pre-filtered them a bit already on those that should be
investigaged. If harderning is working now, override the linitian I: tag.)
I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:15]
I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger]
I: vzlogger: systemd-service-file-missing-documentation-key 
[usr/lib/systemd/system/vzlogger.service]
P: vzlogger source: trailing-whitespace [debian/changelog:10]
P: vzlogger source: trailing-whitespace [debian/changelog:4]
P: vzlogger source: trailing-whitespace [debian/control:17]
P: vzlogger source: trailing-whitespace [debian/control:40]
P: vzlogger source: trailing-whitespace [debian/rules:45]
X: vzlogger: systemd-service-file-missing-hardening-features 
[usr/lib/systemd/system/vzlogger.service]
X: vzlogger source: upstream-metadata-file-is-missing


-- 
Cheers,
tobi

On Fri, Apr 26, 2024 at 10:37:26PM +0200, Joachim Zobel wrote:
> Package: sponsorship-requests  
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "vzlogger":
> 
> * Package name : vzlogger  
> Version  : 0.8.5-1  
> Upstream contact : Joachim Zobel   
> * URL  : 
> http://wiki.volkszaehler.org/software/controller/vzlogger  
> * License  : GPL-3.0-or-later 
> * Vcs  : https://github.com/volkszaehler/vzlogger/tree/debian  
> Section  : net
> 
> The source builds the following binary packages:
> 
> vzlogger - program for logging measurements of smart meters
> 
> To access further information about this package, please visit the following 
> URL:
> 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc
> 
> Changes since the last upload:
> 
>   * Fixed logrotate conf user name
>   * Fixed passing of hardening flags to cmake 
> 
> Regards,  
> --  
> Joachim Zobel
> 


signature.asc
Description: PGP signature

Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."

[Mark Hindley]

Lorenzo,

Thanks for the reminder.

On Fri, May 03, 2024 at 03:10:57PM +0200, Lorenzo wrote:
> Is this is a duplicate of #950986?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950986
> I bet the patch there would fix this bug too

Embarrassingly, that is my patch which I clearly have no recollection of! :-|

Now I look, we have been shipping a variation on it in Devuan since 2020[1].

Mark

[1]  
https://git.devuan.org/devuan/cgroupfs-mount/commit/ff91abfaf3a5c5633744ea552084125ec6c68ce5

Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc

[Martin]

On 2024-05-03 16:43, Sean Whitton wrote:
> Yes, the source package would need to be emacs-casual.  I still think it
> should be suggested upstream.

Yes, different names in Debian and upstream can be confusing.
But I'll leave that to whoever might like to package it.

Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc

[Sean Whitton]

Hello,

On Fri 03 May 2024 at 03:18pm GMT, Martin wrote:

> On 2024-05-03 10:28, Sean Whitton wrote:
>> Hmm, have you considered asking upstream to rename it?  "casual-calc"
>> being the obvious, much less generic choice.
>
> It didn't occur to me, that the name is pretty generic, indeed. OTOH,
> I'm not aware of any other (existing or requested) package named
> "*casual*". And the fact, that the name is not really telling what
> it is about, is common among almost all Debian and Emacs packages :-(
>
> If I were to package this, I would now consider naming the source
> package "emacs-casual{-calc}" and the binary package
> "elpa-casual{-calc}", but I guess, it is easy enough to find by the
> short description anyway, which mentions "Emacs Calc".

Yes, the source package would need to be emacs-casual.  I still think it
should be suggested upstream.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1070304: util-linux: Please build and provide the cal binary

[Chris Hofstaedtler]

Control: tags -1 moreinfo

Hello,

* Jörg Behrmann  [240503 16:39]:
> Upstream util-linux provides a cal binary, that is, in my opinion, superior to
> the cal provided by the ncal package, since the output is much more flexible.
[..]

> Unfortunately the command line switches
> are not compatible and util-linux cal cannot display the date of Easter, so it
> is not drop-in compatible. It would nevertheless be great if e.g. an
> alternatives selection for util-linux cal could be provided.

I'm somewhat open to shipping util-linux's cal, but not if that
involves update-alternatives.

Could you maybe work with upstream, so that util-linux's cal becomes
a drop-in replacement, and can work as both cal and ncal?

Also, quite obviously is this something we want to do as Debian?
Michael, as the maintainer of the current ncal package, what is your
opinion here?

Chris

Bug#1070315: python3-build: Please package version 1.2.0/1.2.1 for verbose builds

[Michael R. Crusoe]

Package: python3-build
Version: 1.1.1-1
Severity: normal
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

Please update the python-build package to version 1.2.0 (or the latest, 1.2.1), which adds the 
"--verbose" / "-v" command line option. This is helpful during (Debian) package 
building for very running long builds, such as those which use mypyc to compile.

If you wish, I can make a team upload myself.

Cheers,



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067784: Doesn't contain libpmix.so.2

[Andrey Rakhmatullin]

On Fri, Apr 05, 2024 at 11:23:32AM +0200, Drew Parsons wrote:
> Looks like 5.0.2-2 annihilated the symlink fix made in 5.0.2-1.1
Simply because 5.0.2-2 doesn't include the 5.0.2-1.1 changes.
Alastair, please fix your workflows so that NMUs don't get ignored and
overwritten.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults

[Guilhem Moulin]

Package: release-notes
Severity: wishlist

Hi,

cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain
mode when relying on defaults cipher and password hashing algorithm.

The change affects users upgrading from bookworm to trixie.  Plain mode
is generally advised against but it still makes sense to include the
NEWS entry into the release notes.

--8<->8--

  Default cipher and password hashing for plain mode have respectively
  been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256
  resp. ripemd160).

  The new values matches what is used for LUKS, but the change does NOT
  affect LUKS volumes.

  This is a backward incompatible change for plain mode when relying on
  the defaults, which (for plain mode only) is strongly advised against.
  For many releases the Debian wrappers found in the ‘cryptsetup’ binary
  package have spewed a loud warning for plain devices from crypttab(5)
  where ‘cipher=’ or ‘hash=’ are not explicitly specified.  The
  cryptsetup(8) executable now issue such a warning as well.

--8<->8--

(Original text from 
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/latest/debian/cryptsetup-bin.NEWS
 )

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc

[Martin]

On 2024-05-03 10:28, Sean Whitton wrote:
> Hmm, have you considered asking upstream to rename it?  "casual-calc"
> being the obvious, much less generic choice.

It didn't occur to me, that the name is pretty generic, indeed. OTOH,
I'm not aware of any other (existing or requested) package named
"*casual*". And the fact, that the name is not really telling what
it is about, is common among almost all Debian and Emacs packages :-(

If I were to package this, I would now consider naming the source
package "emacs-casual{-calc}" and the binary package
"elpa-casual{-calc}", but I guess, it is easy enough to find by the
short description anyway, which mentions "Emacs Calc".

Cheers

Bug#1070188: python3-spyder: uninstallable in unstable due to pylint

[Julian Gilbey]

On Fri, May 03, 2024 at 02:14:36PM +0200, Roland Mas wrote:
> Le 02/05/2024 à 06:07, Julian Gilbey a écrit :
> > On Wed, May 01, 2024 at 03:04:56PM +0200, Roland Mas wrote:
> > > Package: python3-spyder
> > > Version: 5.5.1+ds-1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > python3-spyder is no longer installable in sid; it depends (and
> > > build-depends) on pylint (< 3.1~) but pylint is currently 3.1.0-1 in
> > > unstable.
> > > 
> > > Loosening the versioned dependency is enough to allow spyder to build,
> > > but I don't know whether that introduces runtime changes or not.
> > Dear Roland,
> > 
> > That would be a reasonable thing to do.  Version 5.5.4 depends on
> > pylint >= 3.1.  I don't have time to do this right now, unfortunately,
> > so if someone else would like to make the required changes and upload
> > a patched version of 5.5.1 in the meantime, please feel free to do
> > so.
> 
> I guess I could do that, but is there any reason not to upgrade to 5.5.4
> directly? Maybe I'm fooled by only the "micro" part of the version number
> changing, but it doesn't sound like a big upgrade…
> 
> Roland.

Several other dependencies would also need to be upgraded.  Because of
this, generally takes a while to do even minor version upgrades and to
investigate any newly failing tests in the process.  I am currently
quite overloaded in my Day Job, and have some other RC bugs to address
as well, so I won't realistically be able to do that until at least
June.

Best wishes,

   Julian

Bug#1070313: firmware-amd-graphics: current versions in stable, testing, and sid do not allow RX7800XT usage

[Julien-Benjamin]

Package: firmware-amd-graphics
Version: 20230210-5
Severity: important

Dear Maintainer,

The current versions of this packages, be it in stable (20230210-5), testing 
(20230625-2) 
or sid (20230625-2) prevent RX7800XT GPUs to be used with Debian.

The latest version (20240410) allows RX7800XT GPUs to work properly in stable, 
testing, and sid,
please consider packaging a newer version of firmware.

-- 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.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1064869: nmu: golang-github-cowsql-go-cowsql

[Mathias Gibbens]

Control: retitle -1 nmu: golang-github-cowsql-go-cowsql
Control: affects -1 - src:cowsql


  I've backported a newer version of cowsql, which resolves the need
for a binNMU of that package.

  A binNMU is still requested for golang-github-cowsql-go-cowsql in
bookworm-backports.

Mathias


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

Bug#1070312: O: zdbsp -- node builder library for OpenGL-based Doom-style games

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: j...@debian.org

Jonathan Dowland has essentially orphaned zdbsp with 
https://salsa.debian.org/debian/zdbsp/-/commit/b37655b0ffeab5ba2d8519ecec141f0f0a1d6061

Bug#1070311: O: poco -- C++ Portable Components

[Bastian Germann]

Package: wnpp

Christopher Knadle has orphaned the package with revision 1.11.0-4.

Bug#1070308: O: libextractor -- extracts meta-data from files

[Bastian Germann]

Package: wnpp

Daniel Baumann has orphaned this package with revision 1:1.13-3.

Bug#1070310: O: libextractor-java -- Java bindings for GNU libextractor

[Bastian Germann]

Package: wnpp

Daniel Baumann has orphaned this package with revision 1.0.0-7.

Bug#1070309: O: libextractor-python -- extracts meta-data from files (Python bindings)

[Bastian Germann]

Package: wnpp

Daniel Baumann has orphaned the package with revision 1:0.6-14.

Bug#1070252: reassign 1070252 to python3-mpv

[Louis-Philippe Véronneau]

reassign 1070252 python3-mpv 1.0.4-1
retitle 1070252 python3-mpv: playback broken by libmpv 0.38
tags 1070252 fixed-upstream
thanks

It seems this is caused by the python3-mpv package and has been fixed 
upstream.


I'll make an upload as soon as I find the time.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1070307: O: gnunet-gtk -- peer-to-peer networking (GTK+ client)

[Bastian Germann]

Package: wnpp

With revision 0.20.0-3, Daniel Baumann has orphaned this package.

Bug#1070306: O: gnunet-fuse -- peer-to-peer framework (fuse filesystem client)

[Bastian Germann]

Package: wnpp

With revision 0.20.0-3, Daniel Baumann has orphaned this package.