Bug#684425: closed by Vincent Cheng (Re: conky-std: please implement an alternative way to distinguish among hwmon devices)

[Francesco Poli]

On Mon, 29 Apr 2024 01:15:03 + Debian Bug Tracking System wrote:

> Version: 1.11.6-1
> 
> Closing since upstream has implemented this [1], as mentioned earlier by Jmkr.
> 
> [1] https://github.com/brndnmtthws/conky/commit/14e3b80c45254743e962f88d

Yes, sorry for not following up: I [said] I was testing this new way to
specify the hwmon device, but then I forgot to announce that the tests
went well.

[said]: <https://bugs.debian.org/684425#29>

Thanks for closing the bug report.
Bye!   :-)


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


pgppn6wK0L14m.pgp
Description: PGP signature

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

[Francesco Poli]

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

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

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

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

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

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

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

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

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

Looking forward to hearing back from you.



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


pgpxDwakspPHn.pgp
Description: PGP signature

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

[Francesco Poli (wintermute)]

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

Hello there!
Thanks for maintaining this package in Debian.

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

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

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

The panel is attached to the bottom screen edge.

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

Thanks for your time!
Bye.



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

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

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

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#1069751: gvfs-daemons: gvfsd-network fills the logs with errors

[Francesco Potortì]

Ok, thanks

Bug#1069751: gvfs-daemons: gvfsd-network fills the logs with errors

[Francesco Potortì]

Package: gvfs-daemons
Version: 1.53.90-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

I keep having tons of these in syslog

2024-04-23T04:55:28.315700+02:00 tucano gvfsd-network[318402]: GFileInfo 
created without standard::content-type
2024-04-23T04:55:28.315722+02:00 tucano gvfsd-network[318402]: file 
../../../gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should not 
be reached
2024-04-23T04:55:28.315743+02:00 tucano gvfsd-network[318402]: 
g_ref_string_new_intern: assertion 'str != NULL' failed
 [ the above three lines are repeated 63 times in the space of 50 ms ]
2024-04-23T04:21:41.887252+02:00 tucano gvfsd-wsdd[1507271]: Failed to spawn 
the wsdd daemon: Failed to execute child process “wsdd” (No such file or 
directory)
2024-04-23T04:21:41.887324+02:00 tucano gvfsd-network[318402]: Couldn't create 
directory monitor on wsdd:///. Error: Automount failed: Failed to spawn the 
underlying wsdd daemon.
2024-04-23T04:21:41.891620+02:00 tucano gvfsd-network[318402]: 
g_ref_string_release: assertion 'str != NULL' failed
 [ the above line is repeated 64 times in the space of 15 ms ]

The above sequence is repeated every 15 s

This has gone on for 6 days, until I killed the gvfsd-network process.  Six 
days ago I had
rebooted the machine after some months running because I could not stop it and 
I suspected some
library needing reboot, but apparently this is not the case.

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - CNR, Pisa, ItalyWeb:http://fly.isti.cnr.it


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

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

Versions of packages gvfs-daemons depends on:
ii  gvfs-common 1.53.90-2
ii  gvfs-libs   1.53.90-2
ii  libbluray2  2:1.3.4-dmo2
ii  libc6   2.37-15
hi  libglib2.0-02.78.4-1
ii  libgudev-1.0-0  238-3
ii  libsecret-1-0   0.21.4-1
ii  libsystemd0 255.4-1
ii  libudisks2-02.10.1-5
ii  lsof4.95.0-1
ii  udisks2 2.10.1-5

Versions of packages gvfs-daemons recommends:
ii  dbus  1.14.10-4
ii  gvfs  1.53.90-2

Versions of packages gvfs-daemons suggests:
ii  gvfs-backends  1.53.90-2

-- no debconf information

Bug#1069746: connman: cannot configure a wifi network to forget credentials

[Francesco Poli (wintermute)]

Package: connman
Version: 1.42-5
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this package in Debian!

It works pretty well for most cases (except for the case described
in bug report [#1066128]). I have now found another case where
connman should work better.

[#1066128]: 

I have added a configuration file '/var/lib/connman/eduroam.config',
as documented in the connman-service.config(5) manpage, in order
to connect to eduroam (which, as you may know, is a University wifi
network, which uses security type ieee8021x and EAP type peap).

It works: I am able to connect to eduroam, by using my University
single-sign-on credentials (username and password).

However these credentials (especially the password) are stored
(in cleartext!) into a subdirectory under /var/lib/connman/
and are remembered for future use.
Subdirectories under /var/lib/connman/ are only readable by root,
but the connman daemon has access to them and makes their data
usable by other unprivileged users of the box (even a laptop
may have more than one regular user...).

This can be convenient, but has some important drawbacks:

 * storing passwords in cleartext files (only readable by root) can
   be considered acceptable for psk wifi networks, where the passphrase
   is basically a shared secret (known by a number of people), but
   becomes definitely more troublesome for eduroam wifi network, where the
   access credentials may be the single-sign-on credentials used to
   access many other services of one's own University

 * making eduroam access credentials of one user usable by other users
   of the system may be considered inappropriate, since eduroam access
   credentials are personal

For these reasons, I would like to configure connman, so that it forgets
the eduroam access credentials: connman should ask me to re-enter username
and password each time I connect to eduroam, without storing these
credentials for future use.
This should be configurable on a per-network basis, by setting some
appropriate option in '/var/lib/connman/eduroam.config'.

I failed to find any relevant option in the documentation.
Am I missing anything important?

Can this be done for one specific network (eduroam)?

If not, please forward my bug report upstream as a feature request.

Thanks for your time, bye!


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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (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 connman depends on:
ii  dbus 1.14.10-4
ii  init-system-helpers  1.66
ii  iptables 1.8.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libglib2.0-0 2.78.4-1
ii  libgnutls30  3.8.3-1
ii  libreadline8 8.2-3+b1
ii  libxtables12 1.8.10-3

Versions of packages connman recommends:
ii  bluez  5.71-1
pn  ofono  
ii  wpasupplicant  2:2.10-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host

[Francesco Poli]

Control: severity -1 wishlist


On Fri, 12 Apr 2024 19:57:23 +0200 Johannes Schauer Marin Rodrigues
wrote:

[...]
> Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
[...]
> > I can update the virtual machine (if I create a symlink, see bug 
> > [#1061816]):
> >
> >   $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img
> > 
> > [#1061816]: <https://bugs.debian.org/1061816#98>
> 
> I think 1061816 was fixed with 0.85.7 and the changelog was just missing the
> "closes" entry:
> 
> https://tracker.debian.org/news/1518576/accepted-sbuild-0857-source-into-unstable/

Yes, I have just tested sbuild-qemu/0.85.7 from unstable, and I can
confirm that the symlink is no longer needed.
I have just sent a message to close bug report #1061816 ...

> 
> > But, when I try to build a package from withing the unpacked source
> > tree:
[...]
> > Error reading configuration: PIUPARTS binary 'piuparts' does not exist or 
> > is not executable at /usr/share/perl5/Sbuild/Conf.pm line 76.
> > 
> > Now, piuparts is indeed not installed on the host:
[...]
> > However, I thought that setting $run_piuparts = 1 in ~/.sbuildrc caused
> > piuparts to be run inside the virtual machine guest system, not on the
> > host system!
> 
> What made you think that? Is the error message above not clear enough? Do you
> think it should be improved to make things clearer? Do you have suggestions 
> for
> a message that would've better explained that piuparts needs to be installed 
> on
> the host system?

My point is not that the error message should be improved.
Actually, I think the error message clearness is basically OK.

> 
> > Hence, I thought that piuparts was going to be automatically installed
> > and executed on the guest system (actually on the throw-away overlay).
> > And I thought that the same was going to happen for $run_autopkgtest = 1
> > and for $run_lintian = 1 ...
> > 
> > Am I completely off-track?
> > What did I fail to understand?
> > 
> > Why does sbuild-qemu insist that piuparts be installed on the *host*
> > system?
> 
> Because it needs to be installed on the host. In the same way as autopkgtest
> needs to be on the host. What can sbuild improve?

My point is that sbuild{,-qemu} should install piuparts inside the build
environment (chroot or VM guest system) and run it from within the
build environment, if this is possible.

Does sbuild{,-qemu} do so for lintian? I think this is even more
important for lintian: if the host system runs Debian testing (or maybe
even Debian stable) and the package is being built for Debian unstable
(as upload target), then the package should be checked by the version
of lintian which is currently in Debian unstable. If it were checked by
the version of lintian from Debian testing (or even from Debian
stable), many undeserved "unknown Policy version" complaints could pop
up...

Do you agree with the reasoning?

Thanks for your time and patience!   :-)

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


pgpli10LtTDY8.pgp
Description: PGP signature

Bug#1068813: parallel: no way of silencing Parallel with --halt

[Francesco Potortì]

Package: parallel
Version: 20240222+ds-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

When using
 parallel --halt soon,done=43
I get two lines of output for each completed job, like this:

parallel: This job finished:
get_data_from_csv arg1 arg2 arg3

and I find no way to silence them, as my job does its logging by itself.  No 
problem if --halt is not used.

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - CNR, Pisa, ItalyWeb:http://fly.isti.cnr.it

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

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

Versions of packages parallel depends on:
ii  perl 5.38.2-3
ii  procps   2:4.0.4-4
ii  sysstat  12.7.5-2

parallel recommends no packages.

Versions of packages parallel suggests:
pn  csh 
pn  fish
ii  ksh 20240113
ii  ksh93u+m [ksh]  1.0.8-1
ii  tcsh6.24.10-4
pn  zsh 

-- no debconf information

Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host

[Francesco Poli (wintermute)]

Package: sbuild-qemu
Version: 0.85.6
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hi!

I am trying to set up sbuild-qemu to build (and test) Debian packages.

After creating the virtual machine image:

  $ mkdir -p ~/.cache/sbuild/build
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid unstable-autopkgtest-amd64.img
  $ mv -i unstable-autopkgtest-amd64.img ~/.cache/sbuild/

I prepared the following configuration file:

  $ cat ~/.sbuildrc 
  $source_only_changes = 1;
  $autopkgtest_require_success = 1;
  $lintian_require_success = 0;
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $run_lintian = 1;
  $run_piuparts = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

I can update the virtual machine (if I create a symlink, see bug [#1061816]):

  $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img

[#1061816]: 

But, when I try to build a package from withing the unpacked source
tree:

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm
  sbuild --dist unstable --purge-build=never --purge-deps=never 
--chroot-mode=autopkgtest --autopkgtest-virt-server=qemu 
--autopkgtest-virt-server-opt --overlay-dir=/dev/shm 
--autopkgtest-virt-server-opt --qemu-architecture=x86_64 
--autopkgtest-virt-server-opt --ram-size=2048 --autopkgtest-virt-server-opt 
--cpus=2 --autopkgtest-virt-server-opt --boot=efi --autopkgtest-virt-server-opt 
/home/$USER/.cache/sbuild/unstable-autopkgtest-amd64.img 
--bd-uninstallable-explainer apt
Error reading configuration: PIUPARTS binary 'piuparts' does not exist or is 
not executable at /usr/share/perl5/Sbuild/Conf.pm line 76.

Now, piuparts is indeed not installed on the host:

  $ apt policy piuparts
  piuparts:
Installed: (none)
Candidate: 1.4.1
Version table:
   1.4.1 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  500 http://deb.debian.org/debian unstable/main amd64 Packages

However, I thought that setting $run_piuparts = 1 in ~/.sbuildrc caused
piuparts to be run inside the virtual machine guest system, not on the
host system!
Hence, I thought that piuparts was going to be automatically installed
and executed on the guest system (actually on the throw-away overlay).
And I thought that the same was going to happen for $run_autopkgtest = 1
and for $run_lintian = 1 ...

Am I completely off-track?
What did I fail to understand?

Why does sbuild-qemu insist that piuparts be installed on the *host*
system?

Please clarify and/or fix this issue.
Thanks for your kind assistance!


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

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

Versions of packages sbuild-qemu depends on:
ii  autopkgtest  5.34
ii  python3  3.11.6-1
ii  python3-pexpect  4.9-2
ii  python3-psutil   5.9.8-2
ii  qemu-system-x86  1:8.2.1+ds-2
ii  qemu-utils   1:8.2.1+ds-2
ii  sbuild   0.85.6
ii  vmdb20.28-2

Versions of packages sbuild-qemu recommends:
ii  qemu-system-arm [qemu-system-arm]  1:8.2.1+ds-2
ii  qemu-system-ppc [qemu-system-ppc]  1:8.2.1+ds-2

sbuild-qemu suggests no packages.

-- no debconf information

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Thu, 28 Mar 2024 17:50:34 +0100 Christian Kastner wrote:

[...]
> Though if I understand #1061816 correctly, then this should probably be
> a separate bug, right? (Wanted to check before I clone)

Why?

I unarchived and reopened this bug report, since I found another
reason why sbuild-qemu-update cannot update a VM image created with
mmdebstrap-autopkgtest-build-qemu.

I think this bug report can be closed, once sbuild-qemu-update is able
to update such a VM image.
I don't think there's any need to clone any bug report here...


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


pgptijtSQz_7B.pgp
Description: PGP signature

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Thu, 28 Mar 2024 10:05:53 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Could you temporarily add a symlink from OVMF_CODE.fd to OVMF_CODE_4M.fd and
> check if it still works?

Well, apparently it works:

  # ln -s /usr/share/OVMF/OVMF_CODE_4M.fd /usr/share/OVMF/OVMF_CODE.fd
  # exit
  $ sbuild-qemu-update --boot=efi ~/var/cache/sbuild/sid-amd64.img
  qemu-system-x86_64 -enable-kvm -drive 
if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE.fd 
-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
user,model=virtio -m 1024 -smp 1 -nographic 
/home/frx/var/cache/sbuild/sid-amd64.img
  root
  Linux host 6.7.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.9-2 (2024-03-13) 
x86_64
  
  The programs included with the Debian GNU/Linux system are free software;
  the exact distribution terms for each program are described in the
  individual files in /usr/share/doc/*/copyright.
  
  Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  permitted by applicable law.
  root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet update
  DEBIAN_FRONTEND=noninteractive apt-get --quiet update
  Get:1 http://deb.debian.org/debian sid InRelease [198 kB]
  [...]
  DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes autoremove
  Reading package lists...
  Building dependency tree...
  Reading state information...
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  root@host:~# sync
  sync
  root@host:~# sleep 1
  sleep 1
  root@host:~# shutdown -h now



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


pgp0xEUTcoqGC.pgp
Description: PGP signature

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Thu, 28 Mar 2024 09:32:01 +0100 Johannes Schauer Marin Rodrigues wrote:

> On 2024-03-28 08:26, Francesco Poli wrote:
[...]
> >   before (last 100 chars): "/share/OVMF/OVMF_CODE.fd: Could not open
> > '/usr/share/OVMF/OVMF_CODE.fd': No such file or directory\r\n"
> 
> But your system does not have /usr/share/OVMF/OVMF_CODE.fd?

Where should it be?

Debian package [search says] it should be in package 'ovmf'.
However, the [file list] seems to disagree...

[search says]: 
<https://packages.debian.org/search?searchon=contents=OVMF_CODE.fd=path=testing=any>
[file list]: <https://packages.debian.org/trixie/all/ovmf/filelist>

Maybe it's a dynamically created symlink or something?

I have package 'ovmf' installed:

  $ apt policy ovmf
  ovmf:
Installed: 2024.02-2
Candidate: 2024.02-2
Version table:
   *** 2024.02-2 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  500 http://deb.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status

But not the file under consideration:

  $ dpkg -L ovmf | grep -c OVMF_CODE.fd
  0
  $ ls /usr/share/OVMF/OVMF_CODE.fd
  ls: cannot access '/usr/share/OVMF/OVMF_CODE.fd': No such file or directory




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


pgp5GXHGA7jXR.pgp
Description: PGP signature

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

Control: found -1 sbuild/0.85.6

Hello,
I finally got around to testing this new feature.

But it seems to fail:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

  $ sbuild-qemu-update --boot=efi \
  ~/var/cache/sbuild/sid-amd64.img 1> update.out 2> update.err
  $ echo $?
  1
  $ cat update.out 
  qemu-system-x86_64 -enable-kvm -drive 
if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE.fd 
-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
user,model=virtio -m 1024 -smp 1 -nographic 
/home/${USER}/var/cache/sbuild/sid-amd64.img
  $ cat update.err
  Traceback (most recent call last):
File "/usr/bin/sbuild-qemu-update", line 282, in 
  main()
File "/usr/bin/sbuild-qemu-update", line 275, in main
  update_interaction(child, parsed_args.quiet)
File "/usr/bin/sbuild-qemu-update", line 166, in update_interaction
  child.expect('host login: ')
File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 354, in 
expect
  return self.expect_list(compiled_pattern_list,
 ^^^
File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 383, in 
expect_list
  return exp.expect_loop(timeout)
 
File "/usr/lib/python3/dist-packages/pexpect/expect.py", line 179, in 
expect_loop
  return self.eof(e)
 ^^^
File "/usr/lib/python3/dist-packages/pexpect/expect.py", line 122, in eof
  raise exc
  pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
  
  command: /usr/bin/qemu-system-x86_64
  args: [b'/usr/bin/qemu-system-x86_64', b'-enable-kvm', b'-drive', 
b'if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE.fd', 
b'-object', b'rng-random,filename=/dev/urandom,id=rng0', b'-device', 
b'virtio-rng-pci,rng=rng0,id=rng-device0', b'-device', b'virtio-serial', 
b'-nic', b'user,model=virtio', b'-m', b'1024', b'-smp', b'1', b'-nographic', 
b'/home/${USER}/var/cache/sbuild/sid-amd64.img']
  buffer (last 100 chars): ''
  before (last 100 chars): "/share/OVMF/OVMF_CODE.fd: Could not open 
'/usr/share/OVMF/OVMF_CODE.fd': No such file or directory\r\n"
  after: 
  match: None
  match_index: None
  exitstatus: None
  flag_eof: True
  pid: 99474
  child_fd: 5
  closed: False
  timeout: 600
  delimiter: 
  logfile: None
  logfile_read: None
  logfile_send: None
  maxread: 2000
  ignorecase: False
  searchwindowsize: None
  delaybeforesend: 0.05
  delayafterclose: 0.1
  delayafterterminate: 0.1
  searcher: searcher_re:
  0: re.compile('host login: ')


What's wrong? What did I fail to understand?


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


pgpCUzMLY9N0H.pgp
Description: PGP signature

Bug#1067085: nanobind-dev not in python path and without distribution info

[Francesco Ballarin]

Package: nanobind-dev
Version: 1.9.2-1
Severity: normal
X-Debbugs-Cc: francesco.balla...@unicatt.it, dpars...@debian.org

Dear Maintainer,

I would like to ask two questions related on usage of nanobind-dev from
python:

1) The user guide at 
https://nanobind.readthedocs.io/en/latest/building.html#finding-nanobind
states that the downstream user should query
python3 -m nanobind --cmake_dir
to determine where nanobind is installed. However, this is not currently
possible with nanobind-dev, since the file __init__.py is not installed
among the standard python paths. To make this work, one has to use
PYTHONPATH=/usr/share python3 -m nanobind --cmake_dir

2) Downstream users or packages may have a pyproject.toml file which
contains

[build-system]
requires = ["nanobind"]

When building with --no-build-isolation, this requires the
nanobind-*.dist-info folder to be present. Currently either
pip3 show nanobind
or
PYTHONPATH=/usr/share pip3 show nanobind
show
WARNING: Package(s) not found: nanobind
while nanobind installed from pypi.org would show something like

Name: nanobind
Version: 1.9.2
Summary: nanobind: tiny and efficient C++/Python bindings
Home-page: https://github.com/wjakob/nanobind
Author: Wenzel Jakob
Author-email: wenzel.ja...@epfl.ch
License: BSD
Location: /usr/local/lib/python3.11/dist-packages
Requires:
Required-by:
=
The next version of fenics-dolfinx, to be packaged in Debian upon
release, will require --no-build-isolation and nanobind.

Thanks,
Francesco





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

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages nanobind-dev depends on:
ii  libeigen3-dev  3.4.0-4
ii  robin-map-dev  1.2.1-1

nanobind-dev recommends no packages.

nanobind-dev suggests no packages.

-- no debconf information

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

[Francesco Poli (wintermute)]

Package: dhcpcd-gtk
Version: 0.7.9-5
Severity: important
X-Debbugs-Cc: invernom...@paranoici.org

Hello!
Thanks for maintaining this Debian package.

I gave it a try on a laptop, in order to manage dhcpcd, but I cannot
seem to make it work for wireless networks.

I did the following:

  # echo 'update_config=1' > /etc/wpa_supplicant/wpa_supplicant.conf
  # echo 'ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev' >> 
/etc/wpa_supplicant/wpa_supplicant.conf
  # chmod 0600 /etc/wpa_supplicant/wpa_supplicant.conf
  # systemctl restart wpa_supplicant.service
  # systemctl restart dhcpcd.service

Then, as a regular user (belonging to group netdev) within my X session,
I issued the following command:

  $ dhcpcd-gtk &

An icon appeared on my systray (in lxpanel), but it corresponds to
"no network" (see attachment).
Hovering on the icon shows a tip that says that no network is associated
(see second attachment).
Right-clicking on the icon shows a menu with "Preferences", "About", and
"Quit" entries.
I cannot find any list of available wireless networks, I cannot click
on one of them in order to connect, enter passphrase, disconnect, ...

What's wrong or missing?
What did I fail to understand?

Please clarify, thanks for your time!



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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (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 dhcpcd-gtk depends on:
ii  dhcpcd [dhcpcd]  1:10.0.6-1
ii  libc62.37-15
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-0   3.24.41-1
ii  libnotify4   0.8.3-1

Versions of packages dhcpcd-gtk recommends:
ii  wpasupplicant  2:2.10-21

dhcpcd-gtk suggests no packages.

-- no debconf information

Bug#1066843: util-linux: --delete option does not work

[Francesco Potortì]

>
>Control: tags -1 + moreinfo
>
>On Thu, Mar 14, 2024 at 11:11:30AM +0100, Francesco Potortì wrote:
>> The man page for findmnt lists a --delete option which is necessary to me.  
>> Unfortunately, findmnt says it does not have such option, s (I resorted to 
>> using mount for that.
>> 
>> Either --delete should work for findmnt, or the man page should be amended 
>> to remove the --delete option and ideally suggest using mount for those 
>> needing it.
>
>The man page I have says nothing about --delete.
>It however lists --deleted (note the extra d).

Sure, sorry for the typo.  It is --deleted:

# findmnt --deleted 
   
findmnt: unrecognized option '--deleted'
Try 'findmnt --help' for more information.

Bug#1066843: util-linux: --delete option does not work

[Francesco Potortì]

Package: util-linux
Version: 2.39.3-6
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 
File: /usr/bin/findmnt

The man page for findmnt lists a --delete option which is necessary to me.  
Unfortunately, findmnt says it does not have such option, s (I resorted to 
using mount for that.

Either --delete should work for findmnt, or the man page should be amended to 
remove the --delete option and ideally suggest using mount for those needing it.

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

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

Versions of packages util-linux depends on:
ii  libblkid1  2.39.3-6
ii  libc6  2.37-15
ii  libcap-ng0 0.8.4-2
ii  libcrypt1  1:4.4.36-4
ii  libmount1  2.39.3-6
ii  libpam0g   1.5.2-9.1+b1
ii  libselinux13.5-2
ii  libsmartcols1  2.39.3-6
ii  libsystemd0255.4-1
ii  libtinfo6  6.4+20240113-1
ii  libudev1   255.4-1
ii  libuuid1   2.39.3-6
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.22

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.6.4-2
ii  util-linux-extra2.39.3-6
pn  util-linux-locales  

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

Bug#1066128: connman: fails to take multiple search domains into account

[Francesco Poli (wintermute)]

Package: connman
Version: 1.42-5
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this package in Debian!
I have used it for quite some time, and I can say that it works pretty
well for most cases.

However, I have recently encountered a case where connman could work
better...
The case is a network where the DHCP server sends two domains as
"search domains" (let's call them MYDOMAIN and OTHERDOMAIN). These
two search domains are sent by the DHCP server in the
domain search list (DHCP Option 119).

If I don't use connman and configure the Ethernet network with
ifupdown (through a stanza in /etc/network/interfaces ), the DHCP
client (dhcpcd-base) writes the two search domains to /etc/resolv.conf
and everything works as intended.

If instead I use connman to connect to the Ethernet (or Wireless) network,
/etc/resolv.conf is not overwritten, since connman implements an internal
name server. Hence, the dynamically generated resolv.conf is:

  $ cat /run/connman/resolv.conf
  # Generated by Connection Manager
  nameserver ::1
  nameserver 127.0.0.1

That would be OK as /etc/resolv.conf (which could be a symlink to
/run/connman/resolv.conf ), as long as connman is aware of the two
search domains. But connman does not seem to take the two search
domains into account. In the network-specific settings of the GUI,
I see MYDOMAIN as the only domain in the "Domains" tab. However,
if I try to use non-fully-qualified host names, they are not resolved
into IP addresses:

  $ ping -c 3 HOST
  ping: HOST: Name or service not known
  $ ping -c 3 HOST.MYDOMAIN
  PING HOST.MYDOMAIN (192.168.0.143) 56(84) bytes of data.
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=1 ttl=64 time=3.81 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=2 ttl=64 time=4.99 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=3 ttl=64 time=4.79 ms
  
  --- HOST.MYDOMAIN ping statistics ---
  3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.807/4.527/4.987/0.515 ms

Moreover, this network needs

  options single-request-reopen

in /etc/resolv.conf , in order to avoid slow name server replies
(see resolv.conf(5) for more details on this option).
How can I add this option with connman?
It would be great, if connman could be configured to use this option
(globally, or, even better, on a per-network basis).
Can this be done?

Currently, I have the following /etc/resolv.conf (not a symlink):

  $ cat /etc/resolv.conf
  # Generated by dhcpcd
  options single-request-reopen
  # /etc/resolv.conf.tail can replace this line

which was left by dhcpcd-base and has the needed option.
Using this together with connman seems to work (in the sense that
it avoids the slow name server reply), but, as I said, connman does
not take the two search domains into account.


I think connman should be improved, so that it can take the two search
domains into account and it can be configured to add options to the
dynamically generated /run/connman/resolv.conf .

Another strategy could be to delegate all the DHCP client stuff to
an external DHCP client (such as dhcpcd-base, which would manage
/etc/resolv.conf directly).
Is that already possible?


Am I misunderstanding anything?

Please clarify and/or enhance the connman Debian package and/or forward
my bug report upstream, as appropriate.

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.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (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 connman depends on:
ii  dbus 1.14.10-4
ii  init-system-helpers  1.66
ii  iptables 1.8.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libglib2.0-0 2.78.4-1
ii  libgnutls30  3.8.3-1
ii  libreadline8 8.2-3+b1
ii  libxtables12 1.8.10-3

Versions of packages connman recommends:
ii  bluez  5.71-1
pn  ofono  
ii  wpasupplicant  2:2.10-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1065110: ypbind-mt: FTBFS: missing build-dep on libnsl-dev

[Francesco P. Lovergine]

On Thu, Feb 29, 2024 at 10:03:53PM +0100, Aurelien Jarno wrote:


This could be fixed by adding an explicit Build-Depends on libnsl-dev.
The glibc change will likely be reverted in the short term, but given
its a change we want to do for Trixie, this will only lower the severity
of the bug.

Regards
Aurelien



Thanks, this seems the less impacting solution.

--
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1064783: apt-listbugs: installs same filename to both bin and sbin

[Francesco Poli]

Control: tags -1 - moreinfo
Control: severity -1 wishlist


On Mon, 26 Feb 2024 11:08:29 + ca...@allfreemail.net wrote:

> Source: apt-listbugs
> Followup-For: Bug #1064783
> 
> > The command 'apt-listbugs' is installed to /usr/bin and a symbolic link
> > to it is installed to /usr/sbin .
> 
> You are correct, and on a filesystem where those locations are the same
> it causes unpacking errors.

Yes, that's clear.

> 
> > This layout is not currently supported by Debian, as far as I can tell.
> 
> It is not yet supported on debian, but using debootstrap instead of
> debian-installer makes it possible to create such a filesystem layout.
> This is currently useful for testing how adding /usr/sbin to default
> user $PATH would break, and how merging /usr/sbin and /usr/bin would
> break.
> 
> > Which distributions?
> 
> Archlinux has had merged bin and sbin for a number of years. Fedora is
> going in that direction soon and made a nice writeup on 
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

An interesting read, although some of the considerations do not seem to
apply to Debian.

For instance, as far as I can see, in Debian the superuser (root) gets
a different default $PATH (which includes sbin directories), with
respect to regular users (who, by default, do not have sbin directories
in their $PATH). Hence, I would say that the distinction between /bin
and /sbin is not meaningless in Debian...

> 
> > I am not aware of any plans in Debian to move in that direction.
> 
> So far it has been briefly discussed in the -devel channel on IRC and
> the idea has been received mostly well. There are bigger problems with
> it, such as different packages having undeclared file conflicts if the
> sbinmerge happenen, however it is a nice low-hanging fruit to first fix
> the few packages where the one package unpacks the same file (or
> symlink) to both bin and sbin.

I see, but I am a bit worried of breaking scripts with hardcoded paths.

> 
> > See the [usrmerge FAQ], which includes, in part:
> 
> You are correct, this is not about the current usrmerge. It could be called
> usrmerge2.0 or sbinmerge or some other term.

OK, let's call it sbinmerge, then.

> 
> > Could you please elaborate a bit more on why you think this feature of
> > the apt-listbugs Debian package could be an issue?
> 
> On a filesystem where bin and sbin are merged, it causes an unpacking
> error during installation of the package, due to the symlink trying to
> overwrite the real file, or the real file overwriting the symlink. It is
> in a way a file conflict - it can be silenced by passing the right flags
> to the commands, but it is better to fix it properly.

Sorry, I wasn't clear: I understand why unpacking conflicting files
across /sbin and /bin causes issues on a system where /sbin and /bin
are the same directory.

I was asking you to elaborate on why this could be an issue in Debian,
which does not currently support a layout where /sbin and /bin are the
same directory.
And the answer (judging from the rest of your reply) is basically
"because some people in Debian are considering the possibility to
merge /sbin and /bin in some unspecified future, and it would be nice,
if as few packages as possible hampered this possible transition".

> 
> > Which other distributions (Debian-derivatives or otherwise) include
> > apt-listbugs?
> 
> I don't know of any.
> 
> > I am a bit hesitant to do so (risking to break random custom scripts),
> > unless there's a good reason.
> 
> The idea of merging bin and sbin is exactly to help with random custom
> scripts, because if bin and sbin are the same directory, then it doesn't
> matter if only bin or only sbin is in $PATH, or if the executable is
> called directly using hardcoded /usr/bin/apt-listbugs or /usr/sbin/listbugs,
> because both ways will then work instead of giving "command not found"
> errors.
> 
> However I agree that in the meantime some random script somewhere could
> break, and so such a change might warrant a NEWS entry.

Exactly, I am a bit worried about the meantime.

However, you replied to my questions (that's why I am dropping the
'moreinfo' tag).
It's now clear to me, that you are not asking me to modify apt-listbugs
for other distributions, but to simplify a possible future sbinmerge in
Debian.
That sounds like a legitimate feature request (hence severity
'wishlist').

I will think about it.
Bye!


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


pgpGJRNrIwPsh.pgp
Description: PGP signature

Bug#1064783: apt-listbugs: installs same filename to both bin and sbin

[Francesco Poli]

Control: tags -1 + moreinfo


On Sun, 25 Feb 2024 21:36:44 + ca...@allfreemail.net wrote:

[...]
> Dear Maintainer,
> 
> your package installs the filename apt-listbugs to both bin and sbin as 
> opposed to just one of those locations.

Hello,
thanks for your bug report.

The command 'apt-listbugs' is installed to /usr/bin and a symbolic link
to it is installed to /usr/sbin .

A long time ago, the package used to only install the command
to /usr/sbin , but apt-listbugs may be useful for unprivileged users
too (for some of its functionalities), hence it was moved to /usr/bin ,
with a symlink from /usr/sbin for backward compatibility (to avoid
breaking possible custom scripts with the full path hardcoded...).

> 
> This causes a problem on a filesystem layout where bin and sbin are merged 
> into a single real directory, typically by sbin being a symlink to bin.

This layout is not currently supported by Debian, as far as I can tell.

> Such a filesystem layout has become standard on some distributions now, and 
> others are moving onto in their next releases.

Which distributions?

I am not aware of any plans in Debian to move in that direction.

See the [usrmerge FAQ], which includes, in part:

[...]
| Is this about merging /usr/bin/ and /usr/sbin/?
|
| No, there are no plans to do that.
[...]

[usrmerge FAQ]: <https://wiki.debian.org/UsrMerge>


Could you please elaborate a bit more on why you think this feature of
the apt-listbugs Debian package could be an issue?

Which other distributions (Debian-derivatives or otherwise) include
apt-listbugs?
Without massive modifications, apt-listbugs can only be useful for
APT-based distributions with a debbugs-based bug tracking system.
As far as I know, there are no other such distributions beyond Debian.
Do you happen to know any?

> 
> Please pick one location and install it only there. /usr/bin is preferred 
> over any other location.

I am a bit hesitant to do so (risking to break random custom scripts),
unless there's a good reason.

If you explain which distributions are or could be affected by this
feature of apt-listbugs, I will think about it.
Otherwise, I can close this bug report, since what you are reporting
does not seem to be an actual issue for Debian.

> 
> Thank you for maintaining software in debian.

You're welcome.
Thanks to you for caring about apt-listbugs!



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


pgpWZUaklR6aJ.pgp
Description: PGP signature

Bug#684425: conky-std: please implement an alternative way to distinguish among hwmon devices

[Francesco Poli]

On Fri, 16 Feb 2024 20:22:58 +0100 (CET) Jmkr wrote:

> This bug could probably be closed as it is now possible to use device names 
> instead of numbers for "${hwmon ...}". I tested that it works when I did my 
> build of Conky 1.19.6-1 from Debian Sid. It was implemented in the Conky 
> commit "https://github.com/brndnmtthws/conky/commit/14e3b80c45254743e962f88d
> 027a7ea37bf59ee6".

Wow!
I was not aware that a feature (almost) identical to the one I
requested in 2012 (!) has been finally implemented.

I am really happy about it, thanks for the great news!

I am currently testing this new way to specify the hwmon device in
conky.conf, and it seems to work on one host (but I haven't yet
rebooted...). Let's see how it goes in the following weeks and on other
hosts...

Thanks again for the heads up!:-)

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


pgpF9o5V_3HjY.pgp
Description: PGP signature

Bug#1061816: Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

Control: notfixed 1061636 sbuild/0.85.5


On Mon, 12 Feb 2024 23:19:40 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (2024-02-12 22:46:29)
[...]
> > If not, I think this bug report (#1061816) should be marked as pending.
> 
> Done.
> 
> > And probably mentioned in some debian/changelog entry. Or in some
> > commit message, if you generate debian/changelog from commit messages...
> 
> Christian is probably going to do this on the next upload.

Yes, he has just done so, but he apparently closed the original bug
report (which was against mmdebstrap and was already closed), rather
than the cloned bug report.

The above control commands should rectify the situation for the
original bug report, if I am not mistaken...

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


pgpsS9xwNplsC.pgp
Description: PGP signature

Bug#1061816: Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Mon, 29 Jan 2024 21:07:52 +0100 Francesco Poli wrote:

[...]
> Yes, I think it makes sense to have a separate bug report, so that I
> can be easily notified, once it becomes pending and once it gets closed.
> 
> Thanks!

Hello!
I see that [MR 54] has been merged.

[MR 54]: <https://salsa.debian.org/debian/sbuild/-/merge_requests/54>

Is there anything else that needs to be fixed/enhanced in sbuild-qemu,
in order for sbuild-qemu-update to be able to update
mmdebstrap-autopkgtest-build-qemu VM images?

If not, I think this bug report (#1061816) should be marked as pending.
And probably mentioned in some debian/changelog entry. Or in some
commit message, if you generate debian/changelog from commit messages...

Please let me know, thanks for your time!


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


pgpzCEW0fkUtn.pgp
Description: PGP signature

Bug#1063663: dh-make: dh_make with python package type does not add by default --with python3

[Francesco Ballarin]

Package: dh-make
Version: 2.202304
Severity: minor
X-Debbugs-Cc: francesco.balla...@unicatt.it, dpars...@debian.org

Dear Maintainer,

Hi,
I am relatively new to debian packaging, and I am mainly using dh_make with 
python libraries.

I noticed that the dh call produced by default when initializating a new
python project with dh_make is

dh $@ --buildsystem=pybuild


Is there a specific reason why the default line is not

dh $@ --with python3 --buildsystem=pybuild

instead? Is --with python3 implicitly enabled? If not, is not adding it by 
default done on purpose?

There is a comment stating

# If you need to rebuild the Sphinx documentation:
# Add sphinxdoc to the dh --with line.

but there is no suggestion to add python3 to the --with arguments.

As a beginner, the source of my confusion is that dh_make seems to
automatically handle all requirements written in the "quick guide for 
maintainers" at
https://manpages.debian.org/testing/dh-python/dh_python3.1.en.html
(notably, the first and the last bullet), except for adding the --with argument.


Simple script to reproduce is reported below.

Thanks,
Francesco






# Create a mock python library
$ mkdir my_python_library
$ touch my_python_library/__init__.py
$ tar -czvf archive.tar.gz my_python_library

# Run dh_make
$ dh_make -p my-python-library_0.0.1 -f archive.tar.gz
# select p when asked "Type of package"

$ cat debian/rules

#!/usr/bin/make -f

# See debhelper(7) (uncomment to enable).
# Output every command that modifies files on the build system.
#export DH_VERBOSE = 1

export PYBUILD_NAME=my-python-library

%:
dh $@ --buildsystem=pybuild


# If you need to rebuild the Sphinx documentation:
# Add sphinxdoc to the dh --with line.
#
# And uncomment the following lines.
#execute_after_dh_auto_build-indep: export http_proxy=127.0.0.1:9
#execute_after_dh_auto_build-indep: export https_proxy=127.0.0.1:9
#execute_after_dh_auto_build-indep:
#   PYTHONPATH=. python3 -m sphinx -N -bhtml \
#   docs/ build/html # HTML generator
#   PYTHONPATH=. python3 -m sphinx -N -bman \
#   docs/ build/man # Manpage generator











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

Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages dh-make depends on:
ii  debhelper  13.13
ii  dpkg-dev   1.22.4
ii  make   4.3-4.1
ii  python33.11.6-1

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  12.10

-- no debconf information

Bug#1063517: ITP: adios4dolfinx -- ADIOS2Wrappers for DOLFINx

[Francesco Ballarin]

Package: wnpp
Severity: wishlist
Owner: Francesco Ballarin 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org, 
francesco.balla...@unicatt.it

* Package name: adios4dolfinx
  Version : 0.7.3
  Upstream Contact: Jørgen S. Dokken 
* URL : http://jsdokken.com/adios4dolfinx/
* License : MIT
  Programming Lang: Python
  Description : ADIOS2Wrappers for DOLFINx

adios4dolfinx is an extension for DOLFINx to checkpoint meshes, meshtags
and functions using ADIOS2.

The code uses the adios2 Python-wrappers to write DOLFINx objects to file,
supporting N-to-M (recoverable) and N-to-N (snapshot) checkpointing.

For scalability, the code uses MPI Neighbourhood collectives for communication
across processes.

The package will be maintained within the Debian Science team, in
collaboration with Drew Parsons.

Bug#1062831: guitarix: segfaults, when creating a preset bank

[Francesco Poli (wintermute)]

Package: guitarix
Version: 0.44.1+dfsg1-3+b1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining Guitarix in Debian!

I would like to save some presets.
I click on the "Preset:" button and then on "New Bank": a new field appears,
where I should enter the name of the new bank. If, instead, I just click
on this field, guitarix segfaults.

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

Thanks for your time!


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

Kernel: Linux 6.5.0-5-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 guitarix depends on:
ii  fonts-roboto  2:0~20170802-3
ii  guitarix-common   0.44.1+dfsg1-3
ii  guitarix-ladspa   0.44.1+dfsg1-3+b1
ii  guitarix-lv2  0.44.1+dfsg1-3+b1
ii  libatkmm-1.6-1v5  2.28.3-2+b1
ii  libavahi-common3  0.8-13+b1
ii  libavahi-gobject0 0.8-13+b1
ii  libbluetooth3 5.71-1
ii  libboost-iostreams1.83.0  1.83.0-2+b2
ii  libc6 2.37-15~deb13u1
ii  libcairomm-1.0-1v51.14.5-1
ii  libcurl3-gnutls   8.5.0-2
ii  libfftw3-single3  3.3.10-1
ii  libgcc-s1 13.2.0-10
ii  libglib2.0-0  2.78.3-2
ii  libglibmm-2.4-1v5 2.66.6-2
ii  libgtk-3-03.24.40-2
ii  libgtkmm-3.0-1v5  3.24.8-2
ii  libgxw0   0.44.1+dfsg1-3+b1
ii  libgxwmm0 0.44.1+dfsg1-3+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  liblilv-0-0   0.24.22-1
ii  liblrdf0  0.6.1-4
ii  libpangomm-1.4-1v52.46.3-1
ii  libsigc++-2.0-0v5 2.12.1-1
ii  libsndfile1   1.2.2-1
ii  libstdc++613.2.0-10
ii  libzita-convolver44.0.3-2
ii  libzita-resampler11.11.2-1

Versions of packages guitarix recommends:
pn  gvfs-backends  
ii  jack-capture   0.9.73-4
pn  lame   
ii  vorbis-tools   1.4.2-1+b1

guitarix suggests no packages.

-- no debconf information

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

Control: clone -1 -2
Control: reassign -2 sbuild-qemu 0.85.4
Control: reopen -2


On Mon, 29 Jan 2024 08:38:59 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (2024-01-29 00:12:27)
> > Maybe this bug report should cloned and reassigned to sbuild-qemu?
> 
> if you like (for example because you want to subscribe to it and notified when
> it gets closed) then feel free to clone it.
[...]

Yes, I think it makes sense to have a separate bug report, so that I
can be easily notified, once it becomes pending and once it gets closed.

Thanks!

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


pgpGkab6ypWyU.pgp
Description: PGP signature

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Francesco Poli]

On Mon, 29 Jan 2024 10:21:29 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> With that said, I think mmdebstrap-autopkgtest-build-qemu should keep 
> using raw images.

OK, after reading these opinions, I can agree that it makes sense to go
on with raw images.
Thank you so much for taking the time to consult the experts!

Bye.

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


pgpafCugnhaHa.pgp
Description: PGP signature

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Francesco Poli]

On Mon, 29 Jan 2024 08:34:15 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> I now have this locally. Is this attribution (name/email) correct?
> 
> From 8410dc6636817c4e02cf9eba090a70051c494c48 Mon Sep 17 00:00:00 2001
> From: Francesco Poli 
> Date: Mon, 29 Jan 2024 08:28:53 +0100
> Subject: [PATCH] mmdebstrap-autopkgtest-build-qemu: fix octal mode computation
> 
> ---
>  mmdebstrap-autopkgtest-build-qemu | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mmdebstrap-autopkgtest-build-qemu 
> b/mmdebstrap-autopkgtest-build-qemu
> index 5684cbe..1ed14db 100755
> --- a/mmdebstrap-autopkgtest-build-qemu
> +++ b/mmdebstrap-autopkgtest-build-qemu
> @@ -357,7 +357,7 @@ echo "mmdebstrap $*"
>  mmdebstrap "$@" || die "mmdebstrap failed"
>  
>  unshare -U -r --map-groups=auto chown 0:0 "$IMAGE"
> -chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"
> +chmod "$(printf %o "$(( 0666 & ~0$(umask) ))")" "$IMAGE"
>  
>  echo "root=LABEL=autopkgtestvm rw console=ttyS0" > "$WORKDIR/cmdline"
>  
> -- 
> 2.39.2

Yes, the attribution looks correct.
Thanks for accepting the suggestion so promptly and for converting it
into an actual patch!


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


pgphGXH0eDhg7.pgp
Description: PGP signature

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Sun, 28 Jan 2024 17:22:32 +0100 Johannes Schauer Marin Rodrigues
wrote:

[...]
> you found bugs in both sbuild as well as in mmdebstrap.

Well, actually *you* found the bugs, I have just attempted to run a
command and reported that it didn't work...
Credit where credit is due!:-)

> The fixes for sbuild are in this MR:
> 
> https://salsa.debian.org/debian/sbuild/-/merge_requests/54
> 
> Feel free to comment and improve on the code as well to get this forward.

I am not familiar with the sqbuild code base, so I won't comment on the
code style.
I am confident that the MR will fix the bug.

Thanks for preparing it!

Maybe this bug report should cloned and reassigned to sbuild-qemu?

> 
> The mmdebstrap bug is fixed here:
> 
> 
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/3e233e10dfe414e43b31d328eecb0c776afc2ec3
> 
> Thanks!

Good to see that this other bug is going to be fixed, as well.

I am looking forward to seeing all these changes uploaded to Debian.
Thanks a lot!


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


pgpJrtUhyHl1U.pgp
Description: PGP signature

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Francesco Poli]

On Sun, 28 Jan 2024 00:33:06 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (wintermute) (2024-01-27 19:20:08)
[...]
> > My comments / suggestions for improvements:
> > 
> >   * I had to manually fix the permissions, since the image file was
> > originally created with the following weird ones:
> > 
> >   $ ls -l --si sid-amd64.img 
> >   -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img
> 
> those are some funny permission bits. When I run
> mmdebstrap-autopkgtest-build-qemu I get:
> 
> $ ls -lha disk.img
> -rw-r--r-- 1 josch josch 26G Jan 28 00:03 disk.img
> 
> Looks fine to me.

What's *your* umask? Is it Debian default (022), by chance?

> 
> > I think the file permissions should be set (possibly at the end of the
> > mmdebstrap-autopkgtest-build-qemu run) as they would "naturally" result
> > from the user's umask:
> > 
> >   $ cd /dev/shm
> >   $ touch foo
> >   $ ls -l --si foo 
> >   -rw-rw 1 $USER $USER 0 Jan 27 19:00 foo
> 
> They are set, taking the user's umask into account. What is your umask?

Mine is James Bond's umask: 007 ;-)

  $ umask 
  0007

> 
> > That's why I manually changed the permissions at the end:
> > 
> >   $ chmod 660 sid-amd64.img
> >   $ ls -l --si sid_amd64.img
> >   -rw-rw 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img
> > 
> > I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
> > automatically.
> 
> Lets first understand the problem before adding a workaround.
> mmdebstrap-autopkgtest-build-qemu runs this command to set the permissions:
> 
> chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"

This seems to work with Debian default umask (022):

  $ printf '%o\n' "$(( 0666 - 00022 ))"
  644

but fails whenever a umask includes an octal digit equal to 7, due to
the carryover:

  $ printf '%o\n' "$(( 0666 - 7 ))"
  657

Shouldn't this use the bitwise AND combined with the bitwise NOT?

  $ umask
  0007
  $ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
  660
  $ umask 022
  $ umask
  0022
  $ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
  644

I would think that mmdebstrap-autopkgtest-build-qemu should run:

  chmod "$(printf %o "$(( 0666 & ~0$(umask) ))")" "$IMAGE"

Does it make sense to you?

> 
> Could you add some debugging output to the script to figure out what went 
> wrong
> and where?

Feel free to suggest any further debug that could be useful, in case
the above reasoning is not enough to shed some light on what happened.

> 
> >   * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:
> > 
> >   $ cd /dev/shm
> >   $ ls -l -h sid-amd64.img
> >   -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> >   $ df -h .
> >   Filesystem  Size  Used Avail Use% Mounted on
> >   tmpfs   7.7G  765M  7.0G  10% /dev/shm
> > 
> > Well, the mystery is solved by looking at the allocated size:
> > 
> >   $ ls -l -h -s sid-amd64.img 
> >   662M -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> > 
> > Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
> > .qcow2 images?
> 
> I don't understand why sparse files are confusing to you.

I am clearly not very used to seeing files where the allocated size
greatly differs from the total size:

  $ ls -n --si -s sid-amd64.img 
  694M -rw-rw 1 1000 1000 27G Jan 27 17:48 sid-amd64.img

I am more used to seeing files where the two sizes are approximately
equal:

  $ ls -n --si -s sid-autopkgtest-amd64.qcow2 
  950M -rw-r--r-- 1 1000 1000 950M Dec 30 17:55 sid-autopkgtest-amd64.qcow2

Not exactly equal, agreed:

  $ ls -n -s sid-autopkgtest-amd64.qcow2 
  927604 -rw-r--r-- 1 1000 1000 949878784 Dec 30 17:55 
sid-autopkgtest-amd64.qcow2
  $ calc '927604*1024'
  949866496

but very similar, indeed...

> Why would qcow images be less confusing?

Because it seems to me that their total and allocated sizes tend to be
more similar...

> Can you list some reasons why qcow2 should be preferred over
> raw images?

I was under the impression that the qcow2 format was the recommended
one for QEMU/KVM virtual machine images. At least, qemu-img(1)
describes it as "the most versatile format"...

Anyway, if you think that the raw format is a better choice for
autopkgtest and sbuild VM images, I take your word for it.

> Compression comes to mind but that is at the cost of doing that
> compression in the first place and it is not obvious to me whet

Bug#1001105: can I help with pyvista packaging?

[Francesco Ballarin]

A first version is available at
https://salsa.debian.org/science-team/python-pyvista
in case you want to have a look before I/we change it from UNRELEASED
to unstable.

autopkgtest passes.
test-crossbuild-arm64 is failing, but is allowed to do so, not sure if
it is relevant.

As agreed, interactive plotting within jupyter is not considered for now.

Cheers,
Francesco


On Sat, Jan 27, 2024 at 7:08 PM Andreas Tille  wrote:
>
> Am Sat, Jan 27, 2024 at 06:28:14PM +0100 schrieb Francesco Ballarin:
> > OK Andreas, I'll push to master. Let me take the lead on that, and I'll 
> > come back to you and Drew with progress and questions.
>
> Perfectly fine for me.
>
> > I think I have some ideas on how to get started on the basic package.
> >
> > The full package (i.e., all optional components that one can install with 
> > "pip install pyvista[all]") will be much more complex, because it depends 
> > on trame, which comes split in five interdependent packages
> > 
> > trame3.2.4
> > trame-client 2.11.2
> > trame-server 2.11.7
> > trame-vtk2.5.8
> > trame-vuetify2.3.1
> > 
> > and who knows how many dependencies each one of those have.
>
> Sounds complex and I'd love to stay in background given that I need to
> care for >1000 packages.
>
> > Down the line I'd want to have that too, because that's what I actually 
> > need for plotting within jupyter notebooks in my libraries, see for instance
> > https://viskex.github.io/tutorials/01_introduction/tutorial_plot_subdomains_3d_dolfinx.html
> > but let's start with a less ambitious goal ;)
>
> +1
>
> > I think that the error you see is because python3-vtk9 is only built for 
> > python 3.11, but unit tests are getting run with python 3.12.
> > At the moment, I'd like to disable that part adding an empty 
> > override_dh_auto_test-indep and run tests with autopkgtest only, so that I 
> > can have a clearer idea on the difference between dependencies required for 
> > building the package vs dependencies required for testing it, because I 
> > know from experience that there are a few packages that are only needed for 
> > testing pyvista.
>
> Perfectly fine for me.  Feel free to turn the RFP in ITP and I can
> sponsor the upload if needed.
>
> Thanks a lot for your help
> Andreas.
>
> --
> http://fam-tille.de
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
<https://www.unicatt.it/uc/5xmille>

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello again Johannes!

As I said in bug report [#1061634], I've been able to create a QEMU/KVM
virtual machine image for autopkgtests:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ chmod 660 sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

[#1061634]: 

It works for autopkgtests, but I wanted to use the same virtual machine
image to build Debian packages with sbuild-qemu.
The first thing I tested is the update of the VM image with
sbuild-qemu-update:

  $ sbuild-qemu-update --arch=amd64 sid-amd64.img
  qemu-system-x86_64 -enable-kvm -object 
rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
user,model=virtio -m 1024 -smp 1 -nographic sid-amd64.img

This command does not seem to work: it uses 100 % of one CPU core and
seemingly does nothing, until I interrupt it by pressing [Ctrl+C].

Is there any special tweak or configuration needed to use
sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images?
Where is this documented?

Otherwise, if this is an actual bug, please fix
mmdebstrap-autopkgtest-build-qemu
or help sbuild-qemu developers to fix sbuild-qemu-update.

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.5.0-5-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 mmdebstrap depends on:
ii  apt  2.7.10
ii  perl 5.38.2-3
ii  python3  3.11.6-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.33-1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-6
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.10
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.38.2-3
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-4

-- no debconf information

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello Johannes!

I've been able to create a QEMU/KVM virtual machine image for autopkgtests:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ chmod 660 sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

It is able to run autopkgtests:

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out \
--summary./${SRCPKG}_autopkgtest.summary \
--apt-upgrade -B ./${SRCPKG}_amd64.changes -- \
qemu --boot=efi --overlay-dir /dev/shm \
~/var/cache/sbuild/sid-amd64.img

My comments / suggestions for improvements:

  * I had to manually fix the permissions, since the image file was
originally created with the following weird ones:

  $ ls -l --si sid-amd64.img 
  -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

I think the file permissions should be set (possibly at the end of the
mmdebstrap-autopkgtest-build-qemu run) as they would "naturally"
result from the user's umask:

  $ cd /dev/shm
  $ touch foo
  $ ls -l --si foo 
  -rw-rw 1 $USER $USER 0 Jan 27 19:00 foo

That's why I manually changed the permissions at the end:

  $ chmod 660 sid-amd64.img
  $ ls -l --si sid_amd64.img
  -rw-rw 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
automatically.

  * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:

  $ cd /dev/shm
  $ ls -l -h sid-amd64.img
  -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
  $ df -h .
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   7.7G  765M  7.0G  10% /dev/shm

Well, the mystery is solved by looking at the allocated size:

  $ ls -l -h -s sid-amd64.img 
  662M -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img

Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
.qcow2 images?


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

Kernel: Linux 6.5.0-5-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 mmdebstrap depends on:
ii  apt  2.7.10
ii  perl 5.38.2-3
ii  python3  3.11.6-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.33-1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-6
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.10
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.38.2-3
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-4

-- no debconf information

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Thu, 25 Jan 2024 13:32:00 +0100 Johannes Schauer Marin Rodrigues wrote:

> Hi Francesco,

Hello Johannes!

> 
> Quoting Johannes Schauer Marin Rodrigues (2024-01-23 08:56:24)
[...]
> > Amongst other improvements, if "$IMAGE" cannot be accessed by the unshared
> > user, it will error out early with a (hopefully) helpful error message.
> 
> this has now been uploaded as mmdebstrap 1.4.1.

Sorry, I haven't got around to testing it before the upload...

I've just tested it, after upgrading to mmdebstrap/1.4.1-1 from Debian
sid.

> Are you satisfied with the resolution?

That's certainly a significant improvement over the previous state of
affairs!

> Do you have other remarks? I'm going to make another bugfix release
> very soon, so if you like some more changes to be included, now is the time to
> speak up. :)

Yes, I have other remarks.   :-)
But maybe I should include them in brand new bug reports...


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


pgp3FJnMWKjNt.pgp
Description: PGP signature

Bug#892293: closed by Drew Parsons (reply to dpars...@debian.org) (Re: Bug#892293 paraview: errors when saving animations as AVI files [regression])

[Francesco Poli]

On Thu, 04 Jan 2024 11:15:03 + Debian Bug Tracking System wrote:

> Control: fixed 892293 5.11.0+dfsg-1
> 
> Looks like this has been fixed now.
> The .avi animation file is generated fine in paraview 5.11

Yes, I can confirm that the .avi animation is correctly saved by
paraview/5.11.2+dfsg-4 and it is even in the format that is most
portable in my experience (mjpeg yuv420p).

Thanks for checking this bug report!

Bye.

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


pgp8walXfa8Zk.pgp
Description: PGP signature

Bug#1061417: RFS: pusimp/0.1.0-1 [ITP] -- prevent user-site imports (python3)

[Francesco Ballarin]

Adding (again) debian-pyt...@lists.debian.org in cc: dear DPT members,
please see my RFS quoted below.

Hopefully this time it will work and it won't be filtered by the spam
filter: in contrast to the previous attempt I am now a member of the
debian-python mailing list and I am sending this email as plain text.


On Wed, Jan 24, 2024 at 7:39 AM Francesco Ballarin
 wrote:
>
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-Cc: francesco.balla...@unicatt.it
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pusimp":
>
>  * Package name : pusimp
>Version  : 0.1.0-1
>Upstream contact : Francesco Ballarin 
>  * URL  : https://github.com/python-pusimp/pusimp
>  * License  : MIT
>  * Vcs  : https://salsa.debian.org/python-team/packages/pusimp
>Section  : python3
>
> The source builds the following binary packages:
>
>   python3-pusimp -- prevent user-site imports (Python 3)
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/pusimp/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/p/pusimp/pusimp_0.1.0-1.dsc
>
> pusimp is a python library to prevent user-site imports of specific
> dependencies of a package. The typical scenario for using pusimp is
> in combination with a system manager (e.g., apt for Debian), to prevent
> dependencies from being loaded from user-site instead of the location
> provided by the system manager.
>
> We designed pusimp with in mind the specific use case of the FEniCS
> project. It happens often that users post messages at the FEniCS discourse
> forum asking why their ubuntu/debian installation is not working correctly,
> and several times this is due to the presence of user-made installation
> attempts in user-site locations. For whatever reason, this happens
> somewhat frequently, see for instance
> https://fenicsproject.discourse.group/t/installation-trouble/13029/16
> https://fenicsproject.discourse.group/t/hdf5-update-didnt-work/13323/4
> https://fenicsproject.discourse.group/t/ubuntu-18-04-importerror-cannot-import-name-sub-forms-by-domain/4257/14
> https://fenicsproject.discourse.group/t/unknown-ufl-object-type-vectorelement-error/13145/2
> https://fenicsproject.discourse.group/t/importerror-cannot-import-name-abstractfiniteelement-from-ufl-finiteelement/13154/2
> for five examples of users who made this same mistake in the last 30
> days.
>
> We thus initially plan to use pusimp in the python3-dolfin and
> python3-dolfinx packages, but the logic behind pusimp is purposely
> simple and general and could also be used for other packages which have
> similar issues.
> See
> https://salsa.debian.org/science-team/fenics/dolfin/-/merge_requests/4
> for an example of some error messages that pusimp would produce for the
> python3-dolfin package.
>
> This RFS will close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060805
>
> Cheers,
> Francesco Ballarin
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
<https://www.unicatt.it/uc/5xmille>

Bug#1061417: RFS: pusimp/0.1.0-1 [ITP] -- prevent user-site imports (python3)

[Francesco Ballarin]

Adding debian-pyt...@lists.debian.org<mailto:debian-pyt...@lists.debian.org> in 
cc


On Wed, Jan 24, 2024 at 7:39 AM Francesco Ballarin 
mailto:francesco.balla...@unicatt.it>> wrote:
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: 
francesco.balla...@unicatt.it<mailto:francesco.balla...@unicatt.it>

Dear mentors,

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

 * Package name : pusimp
   Version  : 0.1.0-1
   Upstream contact : Francesco Ballarin 
mailto:francesco.balla...@unicatt.it>>
 * URL  : https://github.com/python-pusimp/pusimp
 * License  : MIT
 * Vcs  : https://salsa.debian.org/python-team/packages/pusimp
   Section  : python3

The source builds the following binary packages:

  python3-pusimp -- prevent user-site imports (Python 3)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pusimp/pusimp_0.1.0-1.dsc

pusimp is a python library to prevent user-site imports of specific
dependencies of a package. The typical scenario for using pusimp is
in combination with a system manager (e.g., apt for Debian), to prevent
dependencies from being loaded from user-site instead of the location
provided by the system manager.

We designed pusimp with in mind the specific use case of the FEniCS
project. It happens often that users post messages at the FEniCS discourse
forum asking why their ubuntu/debian installation is not working correctly,
and several times this is due to the presence of user-made installation
attempts in user-site locations. For whatever reason, this happens
somewhat frequently, see for instance
https://fenicsproject.discourse.group/t/installation-trouble/13029/16
https://fenicsproject.discourse.group/t/hdf5-update-didnt-work/13323/4
https://fenicsproject.discourse.group/t/ubuntu-18-04-importerror-cannot-import-name-sub-forms-by-domain/4257/14
https://fenicsproject.discourse.group/t/unknown-ufl-object-type-vectorelement-error/13145/2
https://fenicsproject.discourse.group/t/importerror-cannot-import-name-abstractfiniteelement-from-ufl-finiteelement/13154/2
for five examples of users who made this same mistake in the last 30
days.

We thus initially plan to use pusimp in the python3-dolfin and
python3-dolfinx packages, but the logic behind pusimp is purposely
simple and general and could also be used for other packages which have
similar issues.
See
https://salsa.debian.org/science-team/fenics/dolfin/-/merge_requests/4
for an example of some error messages that pusimp would produce for the
python3-dolfin package.

This RFS will close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060805

Cheers,
Francesco Ballarin
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
<https://www.unicatt.it/uc/5xmille>

Bug#1061417: RFS: pusimp/0.1.0-1 [ITP] -- prevent user-site imports (python3)

[Francesco Ballarin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: francesco.balla...@unicatt.it

Dear mentors,

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

 * Package name : pusimp
   Version  : 0.1.0-1
   Upstream contact : Francesco Ballarin 
 * URL  : https://github.com/python-pusimp/pusimp
 * License  : MIT
 * Vcs  : https://salsa.debian.org/python-team/packages/pusimp
   Section  : python3

The source builds the following binary packages:

  python3-pusimp -- prevent user-site imports (Python 3)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pusimp/pusimp_0.1.0-1.dsc

pusimp is a python library to prevent user-site imports of specific
dependencies of a package. The typical scenario for using pusimp is
in combination with a system manager (e.g., apt for Debian), to prevent
dependencies from being loaded from user-site instead of the location
provided by the system manager.

We designed pusimp with in mind the specific use case of the FEniCS
project. It happens often that users post messages at the FEniCS discourse
forum asking why their ubuntu/debian installation is not working correctly,
and several times this is due to the presence of user-made installation
attempts in user-site locations. For whatever reason, this happens
somewhat frequently, see for instance
https://fenicsproject.discourse.group/t/installation-trouble/13029/16
https://fenicsproject.discourse.group/t/hdf5-update-didnt-work/13323/4
https://fenicsproject.discourse.group/t/ubuntu-18-04-importerror-cannot-import-name-sub-forms-by-domain/4257/14
https://fenicsproject.discourse.group/t/unknown-ufl-object-type-vectorelement-error/13145/2
https://fenicsproject.discourse.group/t/importerror-cannot-import-name-abstractfiniteelement-from-ufl-finiteelement/13154/2
for five examples of users who made this same mistake in the last 30
days.

We thus initially plan to use pusimp in the python3-dolfin and
python3-dolfinx packages, but the logic behind pusimp is purposely
simple and general and could also be used for other packages which have
similar issues.
See
https://salsa.debian.org/science-team/fenics/dolfin/-/merge_requests/4
for an example of some error messages that pusimp would produce for the
python3-dolfin package.

This RFS will close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060805

Cheers,
Francesco Ballarin

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

[Francesco Ballarin]

Hi Andreas,
thanks for your offer to help.

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

Cheers,
Francesco


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

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

Kind regards
   Andreas.

--
http://fam-tille.de
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
<https://www.unicatt.it/uc/5xmille>

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

[Francesco Ballarin]

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

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

Cheers,
Francesco Ballarin

Bug#1052376: lxpanel: no longer obeys its geometry settings

[Francesco Poli]

On Thu, 21 Sep 2023 09:26:30 +0200 Francesco Poli wrote:

> On Thu, 21 Sep 2023 08:49:04 +0200 Francesco Poli (wintermute) wrote:
> 
> > Downgrading/reinstalling the following packages:
> > 
> >   libwnck-common (2.30.7-6)
> >   libwnck22 (2.30.7-6+b1)
> >   libkeybinder0 (0.3.1-2.1)
> >   libfm4 (1.3.2-1)
> >   libfm-gtk4 (1.3.2-1)
> >   lxpanel-data (0.10.1-2) ...
> >   lxpanel (0.10.1-2)
> > 
> > is enough to restore the normal (sane) behavior.
> 
> I also had to downgrade the following package:
> 
>   libfm-modules (1.3.2-1)
> 
> and to purge the following packages:
> 
>   libfm-gtk3-4
>   libkeybinder-3.0-0
>   libwnck-3-0
>   libwnck-3-common

Hello,
just a gentle ping about this bug report: any progress?

I see that several other users are experiencing the same issues I
reported. Is there any plan to fix them soon?

Thanks for your time and dedication!



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


pgpw0xPq2IK1G.pgp
Description: PGP signature

Bug#1061195: ITP: libgeo-wkt-simple-perl -- Simple utils to parse/build Well Known Text(WKT) format string

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libgeo-wkt-simple-perl
  Version : 0.05
  Upstream Contact: Yuto KAWAMURA 
* URL : https://metacpan.org/release/KAWAMURAY/Geo-WKT-Simple-0.05
* License : Perl
  Programming Lang: Perl
  Description : Simple utils to parse/build Well Known Text(WKT) format 
string

 This module can parse/build WKT format string into/from pure Perl data
 structure. It is simpler than Geo::WKT and does not depend on the Proj
 library, and even support MULTI(LINE|STRING|POLYGON) objects.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli]

On Fri, 19 Jan 2024 00:26:08 +0100 Francesco Poli wrote:

> On Thu, 18 Jan 2024 07:56:08 -0500 James McCoy wrote:
> 
> [...]
> > The latest upload has already fixed this.  It should migrate to testing
> > as part of the ongoing Perl transition.
> 
> Thanks a lot for your very prompt reply!
> I'll wait for the Perl transition to be completed and then I'll see.
[...]

I've just upgraded vim-runtime (along with many other
Perl-transition-related packages) and I can confirm that Fortran syntax
highlighting works again!

Thanks again for dealing with this bug report.
Bye!:-)


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


pgpp50ocSG06P.pgp
Description: PGP signature

Bug#799392: closed by Debian FTP Masters (reply to Martin Buck ) (Bug#799392: fixed in calc 2.15.0.4-1)

[Francesco Poli]

On Fri, 19 Jan 2024 02:39:14 + Debian Bug Tracking System wrote:

[...]
>* New upstream version 2.15.0.4
>  Closes: #799392 - document the need to use '-p' in scripts, see
>  https://github.com/lcn2/calc/issues/133 for details).
[...]

Thank you so much for checking and closing the bug report!

The following script works correctly:

  $ cat calc_script.cal 
  #!/usr/bin/calc -q -p -f

  n = eval(prompt("Enter a number: ")) ;
  printf("%r\n", n+1) ;


So it just needed the '-p' option to be added to the shebang...
Nice!

Thanks again and bye!   :-)


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


pgpdVMr80YrTL.pgp
Description: PGP signature

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli]

On Thu, 18 Jan 2024 07:56:08 -0500 James McCoy wrote:

[...]
> The latest upload has already fixed this.  It should migrate to testing
> as part of the ongoing Perl transition.

Thanks a lot for your very prompt reply!
I'll wait for the Perl transition to be completed and then I'll see.

Bye!

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


pgpinQ_uCDSbK.pgp
Description: PGP signature

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli (wintermute)]

Package: vim-runtime
Version: 2:9.1.0-1
Severity: normal

Hello!

I have recently noticed a regression.
Since one of the latest package upgrades (in Debian testing),
vim began to highlight some Fortran keywords, even when they appear
as part of identifiers. This is incorrect, since a keyword should
be highlighted only where it is actually a keyword, and not where
it appears as a part of an identifier.

Please see the attached 'test.f90' Fortran example program
and a screenshot of how vim highlights its syntax.

Please forward this bug report upstream and/or fix the regression,
as appropriate.

Thanks for your time.


P.S.: I believe that 'test.f90' is so trivial that it is not copyrighted.
Should it turn out to be copyrighted in some jurisdiction, I hereby release
it under the terms of the [Expat licence].

[Expat licence]: http://www.jclark.com/xml/copying.txt


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

Kernel: Linux 6.5.0-5-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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim 2:9.1.0-1
ii  vim-gtk3 [vim]  2:9.1.0-1
ii  vim-tiny2:9.1.0-1

vim-runtime suggests no packages.

-- no debconf information
program test

integer :: mycalli
integer :: myifi
integer :: myendifi
integer :: mystopi
integer :: mycasei

integer :: myselecti
integer :: mywherei

integer :: myclassi

read(*,*) mycalli, myifi, myendifi, mystopi, mycasei, &
  myselecti, mywherei, myclassi

write(*,*) mycalli + myifi + myendifi + mystopi + mycasei + &
   myselecti + mywherei + myclassi

end

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Sun, 14 Jan 2024 20:27:58 +0100 Helmut Grohne wrote:

> On Sun, Jan 14, 2024 at 06:36:29PM +0100, Francesco Poli wrote:
> > Of course, I have!   ;-)
> > 
> > For privacy reasons: I don't want other users to be able to enter my
> > home directory and to read any file within it that I might have
> > forgotten with world-readable permissions!
> 
> I agree that this is good practice. It's just that working with
> namespaces tends to make this annoying. We're still in search for a more
> satisfying solution. For now, I'm happy to have identified the cause of
> your failure.

Indeed!
Without understanding the cause of the failure, nobody can find a
(good) fix. Hence, identifying the cause is the first step.

> 
> > the final touches to sid_amd64.img will be put with the file in its
> > intended destination directory, which is /home/${USER}/mysubdir, since
> > the command-line argument was "sid_amd64.img", a relative path to a
> > file directly within the current working directory (~/mysubdir).
> 
> That command that fails is mkfs.ext4. This command is run inside the
> user namespace that mmdebstrap creates for constructing the chroot. The
> uids 0 to 65535 inside the user namespace correspond to your first
> subuid range that is large enough. The mkfs.ext4 operation is performed
> by the root user inside the user namespace. In the initial namespace
> that root user is your first subuid. In particular, it is not your user
> but a different user and this user has no permission to access your
> output image.

Why is my first subuid not my user, but a different user?
Is it by design?
Or can my first subuid be forced to become my user?

[...]
> Let me suggest
> some alternatives. One is storing the output image outside $HOME. If you
> put it into /tmp and the move it from /tmp into your home, that should
> work as well.

I attempted to do this by running mmdebstrap-autopkgtest-build-qemu
from within /dev/shm (and it works, more on this below...).

[...]
> The available options to improve this are not super nice. A simple
> workaround is creating the output image as a temporary file inside the
> namespace and then copying it out. This will perform a 1GB copy
> operation that we'd like to avoid (and rather construct the filesystem
> in-place) for performance reasons, but maybe usability beats
> performance?

Well, performance was not an issue here.
The copy of

  $ ls -lFs --si sid_amd64.img 
  690M -rw-r-xrwx 1 $USER $USER 2.3G Jan 15 23:26 sid_amd64.img*

was really quick.

Maybe it's because my home directory is on an SSD...

However, even on a mechanical hard disk drive, I would be more than
willing to spend some more time in the copy operation. After all, if I
understand correctly, the image will only be created once, and then kept
up-to-date with "sbuild-qemu-update" (which does not require superuser
privileges, does it?).

> I'm also not sure how mmdebstrap downloads sparse files. It
> might make them un-sparse and that'd be quite bad for this use case as
> you'd write 25GB of zeros.

I still have to test with a --size=25G (which is the default size):
a file with actual allocated size of 25 GiB would not fit within
my /dev/shm, but the above-mentioned test with --size=2G produced an
image with an allocated size of about 690 MB, so maybe it can work even
with --size=25G ?!?

Would the use of the .qcow2 format even further help in this?

[...]
> > It looks like it worked, but, unfortunately, it (again) fails to be
> > usable with autopkgtest:
> > 
> >   $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
> > ./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes 
> > -- qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
> >   autopkgtest [18:24:23]: starting date and time: 2024-01-14 18:24:23+0100
> >   autopkgtest [18:24:23]: version 5.32
> >   autopkgtest [18:24:23]: host ${HOST}; command line: /usr/bin/autopkgtest 
> > --output-dir './${SRCPKG}_autopkgtest.out' --summary 
> > './${SRCPKG}_autopkgtest.summary' --apt-upgrade -B 
> > './${SRCPKG}_amd64.changes' -- qemu --overlay-dir /dev/shm 
> > ${HOME}/Downloads/sid_amd64.img
> >   qemu-system-x86_64: terminating on signal 15 from pid 115770 
> > (/usr/bin/python3)
> >   : failure: timed out waiting for 'login prompt on serial 
> > console'
> >   autopkgtest [18:25:24]: ERROR: testbed failure: unexpected eof from the 
> > testbed
> > 
> > 
> > What did I fail to understand?
> 
> The difficulty resides in making a bootable image with no root
> privileges. mmdebstrap-autopkgtest-build-qemu is not fully compatible
> with autopkgtest-build-qemu. It specifically required you to pass
> --boot=efi, right? On amd64, autop

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Sat, 13 Jan 2024 22:09:22 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34)
[...]
> > The problem occurs for Francesco when
> > using either /tmp or /dev/shm as a temporary directly. By default, those two
> > locations should have the desired permission bits set. Lets check whether
> > world-execute permissions are set for all directories up until root. I have
> > this:
> > 
> > $ stat -c "%a %n" / /dev /dev/shm /tmp
> > 755 /
> > 755 /dev
> > 1777 /dev/shm
> > 1777 /tmp
> > 
> > Francesco, what are the world execute permissions on all path components up
> > to /tmp and /devv/shm in your case?

Just like yours:

  $ stat -c "%a %n" / /dev /dev/shm /tmp
  755 /
  755 /dev
  1777 /dev/shm
  1777 /tmp


> 
> scratch what I said in your last mail. Your problem is with the creation of 
> the
> image and not with the temporary chroot directory. What Helmut said is likely
> correct and exactly the problem you are facing. To verify, you could run the
> command you posted initially inside your $HOME directory and show us the
> permission bits of your $HOME. Mine are these:
> 
> stat -c "%a %n" $HOME
> 711 /home/josch
> 
> I assume in your case, you have a 0 at the end of the octal permissions?

Of course, I have!   ;-)

For privacy reasons: I don't want other users to be able to enter my
home directory and to read any file within it that I might have
forgotten with world-readable permissions!

So, the answer to your question is that I indeed have 0 at the end of
the octal permissions:

  $ stat -c "%a %n" $HOME
  700 /home/$USER


OK, please let me understand.

mmdebstrap-autopkgtest-build-qemu creates a chroot within the temporary
directory (TMPDIR=/dev/shm, in my case), but then performs some further
operations (such as mkfs.ext4) on the image file, which is being
created in the directory the user wanted it to be.

Hence, if the user issues the command

  $ cd ~/mysubdir
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--boot=efi sid sid_amd64.img

the final touches to sid_amd64.img will be put with the file in its
intended destination directory, which is /home/${USER}/mysubdir, since
the command-line argument was "sid_amd64.img", a relative path to a
file directly within the current working directory (~/mysubdir).

And these final touches require all parent directories (up to the root
directory) to be world-executable.
In other words, the user would need:

  $ stat -c "%a %n" ~/mysubdir ~ /home /
  771 /home/${USER}/mysubdir
  701 /home/${USER}
  755 /home
  755 /

rather than:

  $ stat -c "%a %n" ~/mysubdir ~ /home /
  770 /home/${USER}/mysubdir
  700 /home/${USER}
  755 /home
  755 /

Is that correct?
Or am I completely off-track?


I tried to do everything within /dev/shm, with:

  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=2G --boot=efi sid sid_amd64.img
  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.hhjurdQFhk/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.hhjurdQFhk/initrd'
  I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' exec 
/dev/shm/mmdebstrap.PeOPcJxciV
  I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" 
"$1/mnt/dev"' exec /dev/shm/mmdebstrap.PeOPcJxciV
  I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'2G'' exec /dev/shm/mmdebstrap.PeOPcJxciV
  mke2fs 1.47.0 (5-Feb-2023)
  Creating filesystem with 524288 4k blocks and 131072 inodes
  Filesystem UUID: 6d0afa2d-5ee5-4a45-b2ef-1bdb74315ad7
  Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912
  
  Allocating group tables: done
  Writing inode tables: done
  Creating journal (16384 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done 
  
  I: running --customize-hook in shell: sh -c 'umount --lazy "$1/mnt"' exec 
/dev/shm/mmdebstrap.PeOPcJxciV
  I: cleaning package lists and apt cache...
  done
  done
  I: removing tempdir /dev/shm/mmdebstrap.PeOPcJxciV...
  I: success in 120.0573 seconds
  determined efi vma alignment as 0x0001000
  determined minimum efi vma offset as 5603221504
  mkfs.fat 4.2 (2021-01-31)
  Checking that no-one is using this disk right now ... OK
  
  Disk sid_amd64.img: 2.13 GiB, 2281718784 bytes, 4456482 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector 

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Fri, 12 Jan 2024 23:39:34 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> could you try applying this patch and then try again:
> 
> --%<-
> --- a/mmdebstrap-autopkgtest-build-qemu
> +++ b/mmdebstrap-autopkgtest-build-qemu
> @@ -302,17 +302,12 @@ if test -n "$SCRIPT"; then
> '--customize-hook=rm -f "$1/userscript"'
>  fi
>  
> -EXT4_OFFSET_BYTES=$(( (FAT_OFFSET_SECTORS + FAT_SIZE_SECTORS) * 512))
> -EXT4_OPTIONS="offset=$EXT4_OFFSET_BYTES,assume_storage_prezeroed=1"
>  set -- "$@" \
> "--customize-hook=download vmlinuz '$WORKDIR/kernel'" \
> "--customize-hook=download initrd.img '$WORKDIR/initrd'" \
> -   '--customize-hook=mount --bind "$1" "$1/mnt"' \
> -   '--customize-hook=mount --bind "$1/mnt/mnt" "$1/mnt/dev"' \
> -   '--customize-hook=/sbin/mkfs.ext4 -d "$1/mnt" -L autopkgtestvm -E 
> '"'$EXT4_OPTIONS' '$IMAGE' '$SIZE'" \
> -   '--customize-hook=umount --lazy "$1/mnt"' \
> +   --format=ext2 \
> "$RELEASE" \
> -   /dev/null
> +   "$IMAGE"
>  
>  test -n "$MIRROR" && set -- "$@" "$MIRROR"
>  test -n "$KEYRING" && set -- "$@" "--keyring=$KEYRING"
> @@ -320,6 +315,9 @@ test -n "$KEYRING" && set -- "$@" "--keyring=$KEYRING"
>  echo "mmdebstrap $*"
>  mmdebstrap "$@" || die "mmdebstrap failed"
>  
> +EXT4_OFFSET_BYTES=$(( (FAT_OFFSET_SECTORS + FAT_SIZE_SECTORS) * 512))
> +fallocate --insert-range --offset=0 --length=$EXT4_OFFSET_BYTES "$IMAGE"
> +
>  unshare -U -r --map-groups=auto chown 0:0 "$IMAGE"
>  chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"
>  
> -->%-

I have just tried.

But the result is not clear to me.
The image generation seems to succeed:

  $ cd ~/Downloads
  $ TMPDIR=/dev/shm ./test/mmdebstrap-autopkgtest-build-qemu \
--size=2G --boot=efi sid sid_amd64.img 
  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.3NxJ7PeIpL/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.3NxJ7PeIpL/initrd'
  I: cleaning package lists and apt cache...
  done
  done
  I: approximating disk usage...
  I: creating tarball...
  copying from tar archive -
  I: done
  I: removing tempdir /dev/shm/mmdebstrap.Dgp1UFANSi...
  I: success in 125.7682 seconds
  determined efi vma alignment as 0x0001000
  determined minimum efi vma offset as 5603221504
  mkfs.fat 4.2 (2021-01-31)
  Checking that no-one is using this disk right now ... OK
  
  Disk sid_amd64.img: 638.58 MiB, 669594624 bytes, 1307802 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  
  >>> Script header accepted.
  >>> Script header accepted.
  >>> Created a new GPT disklabel (GUID: EEDDF652-1EF3-4E3D-9994-1FD7E76B640A).
  sid_amd64.img1: Created a new partition 1 of type 'EFI System' and of size 
127 MiB.
  sid_amd64.img2: Created a new partition 2 of type 'Linux filesystem' and of 
size 510 MiB.
  Partition #2 contains a ext2 signature.
  sid_amd64.img3: Done.
  
  New situation:
  Disklabel type: gpt
  Disk identifier: EEDDF652-1EF3-4E3D-9994-1FD7E76B640A
  
  Device  Start End Sectors  Size Type
  sid_amd64.img1   2048  262143  260096  127M EFI System
  sid_amd64.img2 262144 1306623 1044480  510M Linux filesystem
  
  The partition table has been altered.
  Syncing disks.
  $ echo $?
  0
  $ ls -lF --si sid_amd64.img 
  -rw-r-xrwx 1 $USER $USER 670M Jan 14 17:21 sid_amd64.img*

However, if I attempt to use the resulting image, autopkgtest
fails:

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes -- 
qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
  autopkgtest [17:27:29]: starting date and time: 2024-01-14 17:27:29+0100
  autopkgtest [17:27:29]: version 5.32
  autopkgtest [17:27:29]: host ${HOST}; command line: /usr/bin/autopkgtest 
--output-dir './${SRCPKG}_autopkgtest.out' --summary 
'./${SRCPKG}_autopkgtest.summary' --apt-upgrade -B './${SRCPKG}_amd64.changes' 
-- qemu --overlay-dir /dev/shm ${HOME}/Downloads/sid_amd64.img
  qemu-system-x86_64: terminating on signal 15 from pid 115770 
(/usr/bin/python3)
  : failure: timed out waiting for 'login prompt on serial console'
  autopkgtest [17:28:29]: ERROR: testbed failure: unexpected eof from the 
testbed


Was it just a test to investigate further?
Or did it have a chance to produce a usable image?


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


pgp3i3hxNJ1Ye.pgp
Description: PGP signature

Bug#1060805: ITP: pusimp -- prevent user-site imports

[Francesco Ballarin]

Package: wnpp
Severity: wishlist
Owner: Francesco Ballarin 
X-Debbugs-Cc: debian-de...@lists.debian.org, francesco.balla...@unicatt.it

* Package name: pusimp
  Version : 0.1.0
  Upstream Contact: Francesco Ballarin 
* URL : https://github.com/python-pusimp/pusimp
* License : MIT
  Programming Lang: Python
  Description : prevent user-site imports

pusimp is a python library to prevent user-site imports of specific
dependencies of a package. The typical scenario for using pusimp is
in combination with a system manager (e.g., apt for Debian), to prevent
dependencies from being loaded from user-site instead of the location
provided by the system manager.

We designed pusimp with in mind the specific use case of the FEniCS
project. It happens often that users post messages at the FEniCS discourse
forum https://fenicsproject.discourse.group/ asking why their ubuntu/debian
installation is not working correctly, and several times this is due to the
presence of user-made installation attempts in user-site locations.
We thus initially plan to use pusimp in the python3-dolfin and
python3-dolfinx packages, but the logic behind pusimp is purposely
simple and general.

The package will be maintained at 
https://salsa.debian.org/python-team/packages/pusimp
in collaboration with my sponsor Drew Parsons and the Debian Python Team

Bug#1060757: ITP: libdata-find-perl -- Find data in arbitrary data structures

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libdata-find-perl
  Version : 0.03
  Upstream Contact: Andy Armstrong 
* URL : https://github.com/AndyA/Data--Find
* License : Perl
  Programming Lang: Perl
  Description : Find data in arbitrary data structures

  A simple module to navigate a Perl data structure with
  three exported subroutines (diter, dfind and dwith) 
  and find data occurrences.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Thu, 11 Jan 2024 21:04:16 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Do you see yourself debugging this further by yourself? You probably 
> understand
> that it's hard for me to investigate something that I cannot test myself.

Well, you wrote the script, together with Helmut Grohne (who reads us
in Cc).
I rather see myself helping the two of you in debugging it...   :-)

I've just performed another test, setting a much smaller size for the
image to be created:

  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=2G --boot=efi sid sid_amd64.img

but the result was the same exact error that I have previously reported
in the original [bug] report.

[bug]: <https://bugs.debian.org/1060416>

Hence, it seems to me that the issue is not with the size of the
filesystem where the temporary directory is created.

Indeed, the error does not seem to have anything to do with a "No space
left on device" failure:

[...]
  mke2fs 1.47.0 (5-Feb-2023)
  mkfs.ext4: Permission denied while trying to determine filesystem size
  E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'
[...]

What can cause mkfs.ext4 to fail with a "Permission denied" error?



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


pgpwrRkROgULm.pgp
Description: PGP signature

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Thu, 11 Jan 2024 00:45:50 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Interesting! I'm unable to reproduce either of these issues and I'm also
> puzzled why you get this "permission denied" error. On my system, I'm able run
> your command with the default (in /tmp) as well as in /dev/shm. Here is the
> free space each:
> 
> $ df --si /tmp /dev/shm
> Filesystem  Size  Used Avail Use% Mounted on
> tmpfs   8.6G  4.1k  8.6G   1% /tmp
> tmpfs   2.0G  418k  2.0G   1% /dev/shm

So 2.0 GB should be enough.
And yet, it fails for me with 8.2 GB available on /dev/shm ...  :-(

> 
> Maybe something is mounted in a funny way? Both my /tmp and my /dev/shm are
> tmpfs. The former is mounted with
> rw,nosuid,nodev,relatime,size=8388608k,inode64 and the latter with
> rw,nosuid,nodev,inode64.

  $ mount | grep '/tmp\|shm'
  tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
  /dev/md3 on /tmp type ext4 (rw,relatime,discard)

> 
> I doubt that it fails for lack of system memory unless you have less than 3.7
> GB of RAM.

  $ free --giga
 totalusedfree  shared  buff/cache   
available
  Mem:  16   2  12   0   2  
14
  Swap: 17   0  17

> 
> Maybe permissions are somehow whacky? Both my /tmp and my /dev/shm are set to
> drwxrwxrwt (so there is a sticky bit set) and owned by root:root.

  $ ls -ld /tmp /dev/shm
  drwxrwxrwt  3 root root  200 Jan 11 08:25 /dev/shm
  drwxrwxrwt 13 root root 4096 Jan 11 08:36 /tmp

> 
> What happens with other locations for TMPDIR?

Which other locations?
I cannot use anything within my home directory, as you may recall from
our past [discussions]

[discussions]: <https://bugs.debian.org/944485#216>

And indeed, anything within my home directory is still unusable:

  $ cd ~/Downloads
  $ mkdir TEMP
  $ TMPDIR=./TEMP mmdebstrap-autopkgtest-build-qemu \
  --boot=efi sid sid_amd64.img
  [...]
  E: cannot create /home/$USER/Downloads: Permission denied; cannot create 
/home/$USER/Downloads/TEMP: Permission denied; cannot create 
/home/$USER/Downloads/TEMP/mmdebstrap.XSbRetZNZV: Permission denied; cannot 
create /home/$USER/Downloads/TEMP/mmdebstrap.XSbRetZNZV//etc: Permission 
denied; cannot create 
/home/$USER/Downloads/TEMP/mmdebstrap.XSbRetZNZV//etc/apt: Permission denied; 
cannot create 
/home/$USER/Downloads/TEMP/mmdebstrap.XSbRetZNZV//etc/apt/apt.conf.d: 
Permission denied
  W: hooklistener errored out: E: received eof on socket
  
  I: main() received signal PIPE: waiting for setup...
  I: removing tempdir /home/$USER/Downloads/TEMP/mmdebstrap.XSbRetZNZV...
  env: cannot change directory to 
'/home/$USER/Downloads/TEMP/mmdebstrap.XSbRetZNZV': Permission denied
  E: rm failed: 32000
  E: remove_tree failed
  mmdebstrap failed


So, what's left?!?
I think /dev/shm is the only possible choice (without root privileges).

> 
> > By the way, the old script that used guestfish (with all its limitations)
> > was able to create a QEMU image in .qcow2 format and my /dev/shm was
> > enough for it to work correctly.
> 
> It should be enough. Your /dev/shm is 8G large and it works with my 2G.
> 
> > Why does the current mmdebstrap-autopkgtest-build-qemu create a QEMU
> > image in .img format? Isn't the .qcow2 format better?
> 
> Maybe. It's currently .img because it's easier to debug stuff and use kpartx
> with it without having to extract it first. :)

Do I understand correctly that you intend to switch to .qcow2 in the future?
Or otherwise, what's your plan?

> 
> > Please clarify and/or improve mmdebstrap-autopkgtest-build-qemu .
> > Thanks for your time!
> 
> Thanks for your bug! Lets hope we get to the bottom of this.

You're welcome.

Looking forward to hearing back from you!


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


pgpCrk8PurQoy.pgp
Description: PGP signature

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli]

On Tue, 09 Jan 2024 11:41:09 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> So... mmdebstrap-autopkgtest-build-qemu might be what you want *if* you 
> don't care about ppc64el or mips. The latter was (I think) never 
> supported my autopkgtest-qemu because there is no good option for a 
> bootloader. In case of ppc64el, there is ieee1275 booting but that is 
> not supported by mmdebstrap-autopkgtest-build-qemu.

Well, ppc64el or mips would be nice, but not a must.

I hope mips will be supported autopkgtest-qemu in the future.

As far as ppc64el is concerned, I hope a good solution for booting with
mmdebstrap-autopkgtest-build-qemu can be found, but first I would like
to see mmdebstrap-autopkgtest-build-qemu work correctly for the
supported architectures...

> 
> Could you give mmdebstrap-autopkgtest-build-qemu a try and see if it 
> does what you want? I'm preparing another mmdebstrap release and if you 
> find any issues with that script I can incorporate fixes in the next 
> release.

I have just filed bug report [#1060416].
Thanks for being willing to improve the script!

[#1060416]: <https://bugs.debian.org/1060416>


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


pgpyQ_zHw_dqA.pgp
Description: PGP signature

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.0-1
Severity: normal

Hello,
I am giving mmdebstrap-autopkgtest-build-qemu a try.

The following command fails:

  $ mmdebstrap-autopkgtest-build-qemu --boot=efi sid sid_amd64.img

during some package installation with "no space left on device" error,
since I have /tmp on a somewhat small physical partition:

  $ df --si /tmp/
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/md3868M   99k  806M   1% /tmp

I tried with a TMPDIR in system memory:

  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--boot=efi sid sid_amd64.img

but it again fails with the following (final chunk of) output:

  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.uNRUbVgiOu/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.uNRUbVgiOu/initrd'
  I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' exec 
/dev/shm/mmdebstrap.IXehDNUWIf
  I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" 
"$1/mnt/dev"' exec /dev/shm/mmdebstrap.IXehDNUWIf
  I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'' exec /dev/shm/mmdebstrap.IXehDNUWIf
  mke2fs 1.47.0 (5-Feb-2023)
  mkfs.ext4: Permission denied while trying to determine filesystem size
  E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'
  W: hooklistener errored out: E: received eof on socket
  
  I: main() received signal PIPE: waiting for setup...
  I: removing tempdir /dev/shm/mmdebstrap.IXehDNUWIf...
  E: mmdebstrap failed to run
  mmdebstrap failed

Does it fail because I do not have enough system memory?

  $ df --si /dev/shm/
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   8.3G  108M  8.2G   2% /dev/shm

Is this the explanation?
Otherwise, what went wrong?

By the way, the old script that used guestfish (with all its limitations)
was able to create a QEMU image in .qcow2 format and my /dev/shm was
enough for it to work correctly.
Why does the current mmdebstrap-autopkgtest-build-qemu create a QEMU
image in .img format? Isn't the .qcow2 format better?

Please clarify and/or improve mmdebstrap-autopkgtest-build-qemu .
Thanks for your time!


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

Kernel: Linux 6.5.0-5-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 mmdebstrap depends on:
ii  apt  2.7.6
ii  perl 5.36.0-10+b1
ii  python3  3.11.4-5+b1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.32.2-1+b1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-2
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.6
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.36.0-10
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-3

-- no debconf information

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

[Francesco Ballarin]

Package: wnpp
Severity: wishlist
Owner: Francesco Ballarin 
X-Debbugs-Cc: debian-de...@lists.debian.org, francesco.balla...@unicatt.it

* Package name: python-scooby
  Version : 0.9.2
  Upstream Contact: Bane Sullivan 
* URL : https://github.com/banesullivan/scooby
* License : MIT
  Programming Lang: Python
  Description : A lightweight tool for easily reporting your Python 
environment's package versions and hardware resources

This package is a dependency of pyvista, see bug #1001105
The package will be maintained at 
https://salsa.debian.org/python-team/packages/python-scooby
in collaboration with my sponsor Drew Parsons and the Debian Python Team

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli]

On Mon, 4 Dec 2023 08:39:32 +0200 Martin-Éric Racine wrote:

[...]
> > As far as I understand, isc-dhcp-client is EOL and will be removed from
> > Debian in the near future.
> 
> Which is completely irrelevant to this bug.

Please forget about isc-dhcp-client.

I am experiencing an issue with dhcpcd in Debian.
In a network where the DHCP server provides two search domains (through
DHCP option 119), I do not get the two search domains written
to /etc/resolv.conf .

Other operating systems with other DHCP clients correctly obtain
the two search domains.

Could you please help me in debugging this issue with dhcpcd in Debian?
Could you please forward my bug report upstream, if you think this is
an upstream issue?

Thank you for your time.


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


pgp_iiVqkoQn_.pgp
Description: PGP signature

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli]

On Tue, 31 Oct 2023 11:25:43 +0100 Francesco Poli wrote:

> On Mon, 26 Jun 2023 21:20:15 +0200 Johannes Schauer Marin Rodrigues
> wrote:
> 
> [...]
> > Quoting Francesco Poli (2023-06-26 20:20:47)
> > > If I may share my thoughts (daydreams?!?) about this issue, I was hoping 
> > > to
> > > see a (relatively) simple command able to create a QEMU/KVM image for
> > > autopkgtest without requiring superuser privileges. An image that could be
> > > easily upgraded after creation (without the need to re-create it from
> > > scratch). Bonus, if the image can then be used also for interactive 
> > > testing
> > > of packages and for package building.
> > > 
> > > Basically, I was hoping to see [sbuild-qemu-create] drop the requirement
> > > of superuser privileges (thus dropping the behind-the-scenes use of
> > > vmdb2 and switching to some other backend)...
> > > 
> > > [sbuild-qemu-create]: <https://anarc.at/blog/2022-04-27-sbuild-qemu/>
> > > 
> > > I am not sure I clearly understand whether this may happen or whether
> > > this is actually going to happen soon...
> > 
> > this is not a daydream and I think we have nearly all building blocks in 
> > place
> > to make all of this happen very soon!
> [...]
> > Of course once either MR !236 or !237 get merged
> [...]
> > So I don't think it's a daydream.
> [...]
> > So stay tuned! :D
> 
> 
> Hello!   :-)
> 
> I stayed tuned and I saw that mmdebstrap/1.4.0-1 ships a
> mmdebstrap-autopkgtest-build-qemu that does not require superuser
> privileges (according to its man page).
> 
> Do I understand correctly that this new script is one of the building
> blocks that can make the above-summarized "daydream" come true?
> 
> Could you please give me a status update on the "daydream"?
> 
> Looking forward to hearing back from you.
> Thanks for all the good stuff!


Hello again,
a gentle ping about the above-quoted daydream.

Has anyone received my message?
Could someone please reply?

Thanks a lot for your time and patience.



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


pgplIkuJzcy6q.pgp
Description: PGP signature

Bug#1059325: bash: printf does not recognise numeric constants with explicit base 10

[Francesco Potortì]

Package: bash
Version: 5.2.21-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

$ bash --version
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ echo $((10#08))
8

pot@pot:~$ printf %d\\n 10#08
bash: printf: 10#08: invalid number
10

This is clearly a bug: printf should print no error, and just print 8 followed 
by newline.  However, this only happens on one of my two boxes with Debian 
testing.  The other one does not exhibit the bug, and printf just prints 8 
followed by newline.

I tried with bash --login --noprofile, but nothing changes.

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it
(gate 20, 1st floor, room C71) ISPIN:  https://ieee-jispin.org/


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

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

Versions of packages bash depends on:
ii  base-files   13
ii  debianutils  5.14
ii  libc62.37-12
ii  libtinfo66.4+20231209-1

Versions of packages bash recommends:
ii  bash-completion  1:2.11-8

Versions of packages bash suggests:
ii  bash-doc  5.2.21-2

-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
  PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi
if [ -x /usr/lib/command-not-found -o -x 
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
   /usr/lib/command-not-found -- "$1"
   return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
   /usr/share/command-not-found/command-not-found -- "$1"
   return $?
else
   printf "%s: command not found\n" "$1" >&2
   return 127
fi
}
fi
alias ls='ls --color=auto '
set -o emacs
eval "$(lessfile)"


-- no debconf information

Bug#1058929: Warning at install time could be fixed and will become errors in future versions

[Francesco Paolo Lovergine]

Package: python3-wxgtk4.0
Version: 4.2.0+dfsg-3
Severity: minor

While updating:

Setting up python3-wxgtk4.0 (4.2.1+dfsg-2) ...
/usr/lib/python3/dist-packages/wx/lib/docview.py:1026: SyntaxWarning: invalid 
escape sequence '\*'
  """
/usr/lib/python3/dist-packages/wx/lib/layoutf.py:135: SyntaxWarning: invalid 
escape sequence '\s'
  rexp1 = re.compile('^\s*([tlrbhwxy])\s*([!\?\*])\s*(\d*)\s*$')
/usr/lib/python3/dist-packages/wx/lib/layoutf.py:136: SyntaxWarning: invalid 
escape sequence '\s'
  rexp2 = 
re.compile('^\s*([tlrbhwxy])\s*([=%<>^_])\s*([tlrbhwxy]?)\s*(\d*)\s*#(\d+)\s*$')
/usr/lib/python3/dist-packages/wx/lib/wxpTag.py:17: SyntaxWarning: invalid 
escape sequence '\*'
  '''
/usr/lib/python3/dist-packages/wx/tools/pywxrc.py:524: SyntaxWarning: invalid 
escape sequence '\S'
  subclass = re.sub("^\S+\.", "", subclass)
/usr/lib/python3/dist-packages/wx/tools/pywxrc.py:763: SyntaxWarning: invalid 
escape sequence '\ '
  """

Note that Puthon 3.12 changelog reports:

A backslash-character pair that is not a valid escape sequence now generates a
SyntaxWarning, instead of DeprecationWarning. For example,
re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an invalid escape
sequence, use raw strings for regular expression: re.compile(r"\d+\.\d+")). In a
future Python version, SyntaxError will eventually be raised, instead of
SyntaxWarning. (Contributed by Victor Stinner in gh-98401.)

So, this is something which can be easily fixed and reported upstream, just in
case.

-cheers


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

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

Versions of packages python3-wxgtk4.0 depends on:
ii  libc6 2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libwxbase3.2-13.2.2+dfsg-2
ii  libwxgtk-gl3.2-1  3.2.2+dfsg-2
ii  libwxgtk3.2-1 3.2.2+dfsg-2
ii  python3   3.11.2-1+b1
ii  python3-numpy 1:1.24.2-1
ii  python3-pil   9.4.0-1.1+b1
ii  python3-six   1.16.0-4

python3-wxgtk4.0 recommends no packages.

Versions of packages python3-wxgtk4.0 suggests:
pn  wx3.2-doc  

-- no debconf information

Bug#1056834: pyfuse3: ftbfs with cython 3.0.x

[Francesco P. Lovergine]

On Mon, Dec 11, 2023 at 12:30:24PM +0100, Sebastiaan Couwenberg wrote:

On 12/11/23 12:04, Francesco P. Lovergine wrote:
Unfortunately pyfuse3 is currently not more actively developedi (see 
it's github page), I wonder if it makes sense maintaining it in 
Debian, even considering the Python

life cycle which far from being slow and could render the whole thing
strongly obsolete even at mid-term.

Removing the package because it's dead upstream makes sense.

The rdeps will need to be updated before it can be removed:

# Broken Depends:
s3ql: s3ql

# Broken Build-Depends:
borgbackup: python3-pyfuse3
borgbackup2: python3-pyfuse3
s3ql: python3-pyfuse3 (3.2.0 >=)
  python3-pyfuse3 (4.0.0 <)



For borg it's a pure recommends. About S3ql it strictly depends
on pyfuse3 which is the async Trio based implementation of the
fuse library. The current status of the whole fuse-in-Python
is quite confused and I guess for such kind of things soon
we will see a general shift to other more performant ecosystems,
such as rust. At the time, I hoped that things would evolve for
the best in the Python ecosystem, but I was too much optimistic...

--
Francesco P. Lovergine

Bug#1056834: pyfuse3: ftbfs with cython 3.0.x

[Francesco P. Lovergine]

Hi folks,

Unfortunately pyfuse3 is currently not more actively developedi (see it's github page), 
I wonder if it makes sense maintaining it in Debian, even considering the Python

life cycle which far from being slow and could render the whole thing
strongly obsolete even at mid-term.

On Sun, Dec 10, 2023 at 10:04:19AM +0100, Sebastiaan Couwenberg wrote:

Control: tags -1 patch

On Sun, 26 Nov 2023 10:06:00 + Matthias Klose wrote:

If the package cannot be built with cython 3.0.5, please change the
build dependency from cython3 to cython3-legacy (available now in
unstable).  There is no replacement for cython3-dbg.


The attached patch switches to cython3-legacy as the short term workaround.

The package still fails to build due to #1042652.

Kind Regards,

Bas

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



diff -Nru pyfuse3-3.2.1/debian/changelog pyfuse3-3.2.1/debian/changelog
--- pyfuse3-3.2.1/debian/changelog  2022-10-17 04:54:25.0 +0200
+++ pyfuse3-3.2.1/debian/changelog  2023-12-10 09:59:51.0 +0100
@@ -1,3 +1,10 @@
+pyfuse3 (3.2.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to cython3-legacy.
+
+ -- Bas Couwenberg   Sun, 10 Dec 2023 09:59:51 +0100
+
pyfuse3 (3.2.1-2) unstable; urgency=medium

  [ Debian Janitor ]
diff -Nru pyfuse3-3.2.1/debian/control pyfuse3-3.2.1/debian/control
--- pyfuse3-3.2.1/debian/control2022-10-17 04:54:25.0 +0200
+++ pyfuse3-3.2.1/debian/control2023-12-10 09:59:50.0 +0100
@@ -4,7 +4,7 @@
Maintainer: Debian Python Team 
Uploaders: Nikolaus Rath ,
   Francesco Paolo Lovergine 
-Build-Depends: cython3,
+Build-Depends: cython3-legacy,
   debhelper-compat (= 13),
   dh-python,
   fuse3,



--
Francesco P. Lovergine

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli]

On Sun, 3 Dec 2023 08:06:52 +0200 Martin-Éric Racine wrote:

[...]
> This is the dhcpcd package. Looking for Rocky changes to ISC is irrelevant.

That's exactly what I thought: that is why I initially hadn't pointed
you to any ISC patches... But then you said "That's not what I asked"...

Anyway.

> 
> If you experience issue with dhclient, reassign this bug to isc-dhcp-client.

Please re-read the bug log: I am experiencing an issue on Debian with
both isc-dhcp-client and dhcpcd-base.

Since isc-dhcp-client is EOL and will be removed from Debian in the
near future, I don't think there's any point in investing time on
fixing it.

On the other hand, dhcpcd-base is declared to be a "substitute for ISC
DHCP Client": I would really like to see it fixed and capable of
correctly managing DHCP option 119.
Please forward my bug report upstream, if you think this is an upstream
issue.

Thanks for your time.
Bye.


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


pgpskbyzUeo8z.pgp
Description: PGP signature

Bug#1055147: seahorse-adventures: No keypress recognised

[Francesco Ariis]

Dear Markus,

Il 03 dicembre 2023 alle 15:31 Markus Koschany ha scritto:
> I could not reproduce your problem. The keys work as expected and I can
> navigate the menu and the game without any problems.

Before submitting the bug report I was also able to reproduce the bug
with another person in libera.chat/#debian (alas I forgot the handle
and the channel is not logged).
See also [1].

[1] https://bugs.launchpad.net/ubuntu/+source/seahorse-adventures/+bug/2038853

I don’t know what to do to help debug, but this fork [2] works on my machine
with `python3 run_game.py -full -scale2x`.

[2] https://github.com/dulsi/seahorse-adventures

Bug#1055147: seahorse-adventures: No keypress recognised

[Francesco Ariis]

Il 03 dicembre 2023 alle 17:14 Markus Koschany ha scritto:
> I spoke too soon. Tested the wrong Debian release. So it appears the 
> underlying
> problem is in python3-pygame which changed significantly between Bullseye and
> Bookworm but I'm not sure how I can fix this in seahorse-adventures right 
> now. 

I managed to get keydown working like this:
- in /usr/share/games/seahorse-adventures/lib/menu.py
- go to line 119
- substitute
if e.type is USEREVENT and e.action == 'down':
  with
if e.type == USEREVENT and e.action == 'down':
- keydown will work again

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli]

On Mon, 27 Nov 2023 11:12:45 +0200 Martin-Éric Racine wrote:

> On Sat, 25 Nov 2023 00:38:25 +0100 Francesco Poli
>  wrote:
> > On Thu, 23 Nov 2023 14:00:12 +0200 Martin-Éric Racine wrote:
[...]
> > > You might wanna check whether Rocky Linux has patched their DHCP
> > > clients or altered their default dhcpcd.conf to make this succeed. If
> > > that's the case, please point me to the relevant changes.
> >
> > AFAICT, the Rocky Linux machine has the ISC DHCP client
> > and /etc/resolv.conf is written by a script /usr/sbin/dhclient-script,
> > which obtains data from the ISC DHCP client.
> 
> That's not what I asked.

I am sorry, if I misunderstood your request.
I thought you were asking to be pointed to changes relevant to dhcpcd.
Since the DHCP client I tested on Rocky Linux is the ISC DHCP client, I
considered any patches for that client as irrelevant to dhcpcd (which
is not a fork of the ISC DHCP client, is it?).

Anyway, I tried to search for the Rocky Linux ISC DHCP client source
package. I am no Rocky Linux (Red Hat Enterprise Linux) expert, but I
think it's
<https://rockylinux.pkgs.org/9/rockylinux-baseos-x86_64/dhcp-client-4.4.2-19.b1.el9.x86_64.rpm.html>
The distro-specific patches seem to be collected in
<https://git.rockylinux.org/staging/rpms/dhcp/-/tree/r9/SOURCES>

Maybe the following patch is relevant?
<https://git.rockylinux.org/staging/rpms/dhcp/-/blob/r9/SOURCES/0005-Change-default-requested-options.patch>
I am not sure.

What I am sure is that dhcpcd (but also isc-dhcp-client) in Debian
failed to get the two search domains provided by the DHCP server in the
domain search list (DHCP option 119), while a Rocky Linux ISC DHCP
client and a Windows client correctly got the two search domains.

As far as I understand, isc-dhcp-client is EOL and will be removed from
Debian in the near future. So I would like to see dhcpcd-base fixed and
able to correctly handle DHCP option 119...

Please forward my bug report upstream, if this is an upstream issue.
Thanks for your kind assistance!

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


pgpjVgLXqF3VG.pgp
Description: PGP signature

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli]

On Thu, 23 Nov 2023 14:00:12 +0200 Martin-Éric Racine wrote:

> On Thu, 23 Nov 2023 09:01:34 +0100 "Francesco Poli (wintermute)"
>  wrote:
[...]
> > When I use dhcpcd-base as a DHCP client
[...]
> > This lacks the two search domains I was expecting.
> > To be honest, the isc-dhcp-client Debian package
> > behaves similarly (somehow failing to write OTHERDOMAIN as
> > second search domain).
> >
> > But Rocky Linux clients (on the same network, with the ISC
> > DHCP client and ifup/ifdown mechanism) correctly set the
> > resolv.conf with the two search domains
[...]
> > Even Windows clients (on the same network) correctly obtain
> > the two search domains...
> 
> You might wanna check whether Rocky Linux has patched their DHCP
> clients or altered their default dhcpcd.conf to make this succeed. If
> that's the case, please point me to the relevant changes.

AFAICT, the Rocky Linux machine has the ISC DHCP client
and /etc/resolv.conf is written by a script /usr/sbin/dhclient-script,
which obtains data from the ISC DHCP client.

But, as I said, the Debian GNU/Linux machine seems to be unable to
write the two search domains to /etc/resolv.conf, even with
isc-dhcp-client
I was hoping to solve this issue by switching to dhcpcd-base, but no
luck... Hence I filed this bug report, in the hope to see the issue
fixed in dhcpcd-base.

> 
> > Why cannot I have the two search domains on Debian?
> 
> The dhcpcd client shipped by Debian is, except for recent patches
> towards fixing the build on Hurd (missing includes, etc.), whatever
> upstream ships. If that fails to set more than one search domain, I
> would suspect an upstream issue.
> 
> https://github.com/NetworkConfiguration/dhcpcd/issues

You certainly know dhcpcd and the corresponding Debian package much
better than me (since you maintain the Debian package!).
If you think that this is an upstream issue, I take your word for that.

Please forward my bug report upstream and let's see what the upstream
developer(s) will say about it.

Thanks a lot for your time and dedication!



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


pgpCTDZyI6Zlk.pgp
Description: PGP signature

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli (wintermute)]

Package: dhcpcd-base
Version: 1:10.0.5-2
Severity: normal

Hello and thanks for maintaining this package in Debian!

I am giving it a try (inside a virtual machine), as a drop-in
replacement for isc-dhcp-client (with the ifupdown package).

It seems to work pretty well, just like isc-dhcp-client, but
I noticed an issue in a network where the DHCP server sends
two domains as "search domains" (let's call them MYDOMAIN
and OTHERDOMAIN).

When I use dhcpcd-base as a DHCP client, I get the following
resolv.conf file:

  $ cat /etc/resolv.conf
  # Generated by dhcpcd from enp0s3.dhcp
  # /etc/resolv.conf.head can replace this line
  domain MYDOMAIN
  nameserver 192.168.0.1
  # /etc/resolv.conf.tail can replace this line

This lacks the two search domains I was expecting.
To be honest, the isc-dhcp-client Debian package
behaves similarly (somehow failing to write OTHERDOMAIN as
second search domain).

But Rocky Linux clients (on the same network, with the ISC
DHCP client and ifup/ifdown mechanism) correctly set the
resolv.conf with the two search domains:

  $ cat /etc/resolv.conf
  ; generated by /usr/sbin/dhclient-script
  search MYDOMAIN. OTHERDOMAIN.
  nameserver 192.168.0.1

Even Windows clients (on the same network) correctly obtain
the two search domains...

Why cannot I have the two search domains on Debian?

What's wrong?
What did I fail to understand?
Shouldn't this work out of the box?

Please let me know, thanks for your time.


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/1 CPU thread; 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 dhcpcd-base depends on:
ii  adduser   3.137
ii  libc6 2.37-12
ii  libssl3   3.0.11-1
ii  libudev1  254.5-1

dhcpcd-base recommends no packages.

Versions of packages dhcpcd-base suggests:
pn  resolvconf | openresolv | systemd-resolved  

-- no debconf information

Bug#1055531: apt-listbugs: Fails with Input/output error when current working directory is not available

[Francesco Poli]

Control: affects -1 apt-listbugs

[...]
> On Wed, 8 Nov 2023 23:07:41 +0100 Francesco Poli wrote:
[...]
> The above command should merge the two bug reports.

I forgot to re-add the affects tag...

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


pgpQfznx_cuaG.pgp
Description: PGP signature

Bug#1055531: apt-listbugs: Fails with Input/output error when current working directory is not available

[Francesco Poli]

Control: forcemerge 943714 -1


On Wed, 8 Nov 2023 23:07:41 +0100 Francesco Poli wrote:

[...]
> It's probably reasonable to merge these two bug reports...

The above command should merge the two bug reports.


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


pgpFaVdxrV10_.pgp
Description: PGP signature

Bug#1055531: apt-listbugs: Fails with Input/output error when current working directory is not available

[Francesco Poli]

Control: reassign -1 ruby-gettext 3.3.3-2
Control: affects -1 apt-listbugs


On Tue, 07 Nov 2023 20:49:03 +0100 Jochen Spieker wrote:

> Package: apt-listbugs
> Version: 0.1.41
> Severity: minor
> 
> Dear Maintainer,

Hello Jochen,
thanks for your bug report.

>
> on my laptop running sid I am often using an NFS mount that is only available
> when I am at home.
> 
> Today I had the NFS filesystem mounted when I suspended my laptop, moved it
> somewhere else and woke it up again. My shell still had the NFS (unavailable)
> mount as the current working directory. Then I ran 'apt upgrade'.

An unusual use case, although an interesting one...

> The upgrade failed like this:
[...]
> :220:in `glob': Input/output error - ./locale (Errno::EIO)
> from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:64:in `block in 
> default_path_rules'
> from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:63:in `select'
> from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:63:in 
> `default_path_rules'
> from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:80:in 
> `initialize'
> from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:52:in `new'
> from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:52:in 
> `initialize'
> from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:226:in 
> `new'
> from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:226:in 
> `create_or_find_text_domain'
> from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:71:in 
> `bind_to'
> from /usr/lib/ruby/vendor_ruby/gettext.rb:73:in `bindtextdomain_to'
> from /usr/lib/ruby/vendor_ruby/gettext.rb:54:in `bindtextdomain'
> from /usr/bin/apt-listbugs:428:in `'
> E: Sub-process /usr/bin/apt-listbugs apt returned an error code (1)
> E: Failure running script /usr/bin/apt-listbugs apt

It seems that a simple call to  GetText::bindtextdomain()  caused a
search inside a ./locale directory, from within the ruby-gettext
library, but ./ was not accessible, since it belonged to a
non-responding NFS mount.
Hence the I/O error.

> 
> 
> It would be great if a problem with the current working directory could be
> handled more gracefully. It took me a few minutes to find out what the 
> problem was.

I agree that this kind of problems could be handled better, even though
we are talking about a quite unusual situation.

However, apt-listbugs is just making ruby-gettext library calls in the
correct manner (or in what I believe is the correct manner).
I think it is the responsibility of the library to make sure that
unforeseen filesystem accessibility issues are handled gracefully.

I am therefore reassigning your bug report to package 'ruby-gettext': I
hope it will be handled there, possibly by forwarding it upstream.
Actually, I see that there's already another bug report about the same
issue: [#943714]

[#943714]: <https://bugs.debian.org/943714>

It's probably reasonable to merge these two bug reports...

> 
> Thanks,
> Jochen

Thanks to you, bye!


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


pgpd7_3gPP8s6.pgp
Description: PGP signature

Bug#1055221: qemu-system is not compiled with pipewire audio support

[Francesco C]

> Personally I don't see value in pw support in qemu for now.

I didn't even know that qemu has introduced pipewire support in the
latest version.
I discovered it while trying to find an alternative for the audiodev
driver because of the issue I've experienced :

- pulse+vga , pulse+virgl , pulse without graphics -> audio stream
loses samples ( probably because of my low end hardware )

- the same with sdl

- alsa doesn't work for any reason

- dbus,jack not viable

- spice works perfectly but I have to use qxl driver for graphics that
suffers of a nasty bug on the host side that leads to an unrecoverable
crash of the guest graphics since a couple of months ("failed to
allocate VRAM BO"
:https://groups.google.com/g/linux.kernel/c/w7Ee-j9YonY ).

- pulse+spice the same as above

That's it.

Regards.

Bug#1055221: qemu-system is not compiled with pipewire audio support

[Francesco C]

Package: qemu-system
Version: 1:8.1.2+ds-1
Severity: normal

Dear Maintainer,

Qemu mainline version 8.1.2 claims supporting pipewire audio as host
audio driver , but debian packages is not compiled with that feature :

> qemu-system-amd64 -audiodev help
Available audio drivers:
none
alsa
dbus
jack
oss
pa
sdl
spice
wav

The changelog in the main site explains that pipewire support is
enabled when the build system detects libpipewire installed on the
system.

Debian package should (build-)depends on libpipewire-*-dev to enable
pipewire audio host support.

Bug#1055147: seahorse-adventures: No keypress recognised

[Francesco Ariis]

Package: seahorse-adventures
Version: 1.1+dfsg-6
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,

to replicate:

1. Launch `seahorse-adventures`
2. Now you are in the menu.
3. Press any direction key
3. The grey indicator in the menu does not move. It seems that keypresses
   are not recognised. The game is thus unplayable.


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

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

Versions of packages seahorse-adventures depends on:
ii  fonts-aenigma  0.0.20080511+dfsg-4
ii  fonts-dejavu-core  2.37-6
ii  python33.11.2-1+b1
ii  python3-pygame 2.1.2+dfsg-5+b1

seahorse-adventures recommends no packages.

seahorse-adventures suggests no packages.

-- no debconf information

Bug#1055114: nethack-console: nethack does not handle some terminals

[Francesco Ariis]

Package: nethack-console
Version: 3.6.6-3+b2
Severity: normal
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,

  when I try to run nethack, I get this error:

f@x270:~$ nethack
Unknown terminal type: screen-it.

But the terminal type `screen-it` is present in the terminal capability
database ~/.terminfo

f@x270:~$ ls .terminfo/s/screen-it
.terminfo/s/screen-it

Expected: `nethack` to run without fuss.
Actual: I have to invoke nethack as `TERM=screen nethack`.


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

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

Versions of packages nethack-console depends on:
ii  libc6   2.36-9+deb12u3
ii  libncurses6 6.4-4
ii  libtinfo6   6.4-4
ii  nethack-common  3.6.6-3+b2

nethack-console recommends no packages.

nethack-console suggests no packages.

-- no debconf information

Bug#1028398: snapd: both Telegram-desktop and Skype cannot load and save files

[Francesco Potortì]

Sorry for not following up sooner.

I cannot see this bug any more, it should be closed

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it
(gate 20, 1st floor, room C71) ISPIN:  https://ieee-jispin.org/

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli]

On Mon, 26 Jun 2023 21:20:15 +0200 Johannes Schauer Marin Rodrigues
wrote:

[...]
> Quoting Francesco Poli (2023-06-26 20:20:47)
> > If I may share my thoughts (daydreams?!?) about this issue, I was hoping to
> > see a (relatively) simple command able to create a QEMU/KVM image for
> > autopkgtest without requiring superuser privileges. An image that could be
> > easily upgraded after creation (without the need to re-create it from
> > scratch). Bonus, if the image can then be used also for interactive testing
> > of packages and for package building.
> > 
> > Basically, I was hoping to see [sbuild-qemu-create] drop the requirement
> > of superuser privileges (thus dropping the behind-the-scenes use of
> > vmdb2 and switching to some other backend)...
> > 
> > [sbuild-qemu-create]: <https://anarc.at/blog/2022-04-27-sbuild-qemu/>
> > 
> > I am not sure I clearly understand whether this may happen or whether
> > this is actually going to happen soon...
> 
> this is not a daydream and I think we have nearly all building blocks in place
> to make all of this happen very soon!
[...]
> Of course once either MR !236 or !237 get merged
[...]
> So I don't think it's a daydream.
[...]
> So stay tuned! :D


Hello!   :-)

I stayed tuned and I saw that mmdebstrap/1.4.0-1 ships a
mmdebstrap-autopkgtest-build-qemu that does not require superuser
privileges (according to its man page).

Do I understand correctly that this new script is one of the building
blocks that can make the above-summarized "daydream" come true?

Could you please give me a status update on the "daydream"?

Looking forward to hearing back from you.
Thanks for all the good stuff!


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


pgpxDDUrEBwZA.pgp
Description: PGP signature

Bug#1054229: libcgns-dev: please also ship src/cgns_f.F90 to support Fortran compilers beyond gfortran

[Francesco Poli (wintermute)]

Package: libcgns-dev
Version: 3.4.0-3
Severity: wishlist

Hello and thanks for maintaining this useful library in Debian!

The CGNS library may be used from C/C++ programs/libraries and also
from Fortran programs/libraries.

In order to use the library from Fortran code, the

  use cgns

statement is required, which requires access to the 'cgns.mod' module
file, correctly shipped in package libcgns-dev as /usr/include/cgns.mod .

This works like a charm, as long you compile your own Fortran
program/library with the same Fortran compiler which was used to
generate the 'cgns.mod' module file.
But it may fail, when the two compilers are different, since,
unfortunately!, Fortran module files are [not portable] across
different compilers. 

[not portable]: 

Obviously, the 'cgns.mod' module file shipped in package libcgns-dev as
/usr/include/cgns.mod was compiled with gfortran.
As a consequence, if you also compile your own Fortran program/library
with gfortran, there's no issue at all in using libcgns-dev.

But, if you want to support compilation of your own Fortran program/library
with more than one compiler (for instance gfortran and the Intel 'ifort'
Fortran compiler), you cannot use the official Debian package libcgns-dev.

Well, I seem to have found a strategy to work around this issue.

I downloaded the 'src/cgns_f.F90' source file (from the libcgns Debian
source package, same exact version as the installed Debian binary package)
and compiled it with the incompatible Fortran compiler (e.g.: the Intel
'ifort' Fortran compiler), thus obtaining a 'cgns.mod' module file
compatible with the used Fortran compiler. Among the options passed to
the compiler, there were the following:

  -I/usr/include -c

Then I compiled my own Fortran program source files with the previously
obtained 'cgns.mod' module file in the same directory.
Again with:

  -I/usr/include -c

among the compiler options.
Finally, I linked my own Fortran program .o object files together, with the
following:

  -lcgns

among the passed options.

The strategy works and produces an executable, which is dynamically linked
(among other libraries) to the CGNS library:

  $ ldd my_own_fortran_program | grep cgns
libcgns.so.3.4 => /lib/x86_64-linux-gnu/libcgns.so.3.4 
(0x7f3a4e9f3000)

The executable works correctly.



In conclusion, I would like to suggest to also ship the 'src/cgns_f.F90'
source file in package libcgns-dev, so that the CGNS library in Debian
becomes usable with Fortran compilers other than gfortran.

This would be highly useful, as it would increase the cross-compiler
compatibility of the CGNS library, as shipped in Debian!
And this would just require to ship one more file (less than 200 kbyte)
simply copied from the source Debian package to the libcgns-dev binary
Debian package.

Please consider accepting this proposal.
Thanks for your time and your dedication!

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 libcgns-dev depends on:
ii  libcgns3.4  3.4.0-3

libcgns-dev recommends no packages.

libcgns-dev suggests no packages.

-- no debconf information

Bug#1053644: apt-listbugs: Question about confirming update not accept "Y"

[Francesco Poli]

Control: tags -1 + unreproducible


On Sat, 07 Oct 2023 21:32:00 +0200 lukasz wrote:

> Package: apt-listbugs
> Version: 0.1.40
> Severity: minor
> X-Debbugs-Cc: thel...@gmail.com
> 
> Dear Maintainer,

Hello and thanks for your bug report!

> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>   - What led up to the situation?
>Found 2 bugs in firefox package and asked me about confirming my 
> installation.
>   - What exactly did you do (or not do) that was effective (or ineffective)?
>I typed "Y" as the prompt asked me for.
>   - What was the outcome of this action?
>The package apt-listbugs prompted help menu for me informing that "y" is 
> the correct option, but not "Y"
>   - What outcome did you expect instead? 
>Confirm installation with "Y"as the prompt asked me.

I cannot reproduce the behavior you are reporting.

What I see is that both 'y' and 'Y' are equivalent answers:

  Are you sure you want to install/upgrade the above packages? [Y/n/?/...] Y

and

  Are you sure you want to install/upgrade the above packages? [Y/n/?/...] y

lead to the same result.

And there's a reason for that: there's code that converts the answers
to lower case, whatever the user entered.
See /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:492

  answer = a.downcase

Maybe you added some blank character, before or after the 'Y' answer?
Could this explain what you experienced?
Please let me know.

If this is the case, well, maybe I could change that line into:

  answer = a.downcase.strip

I will think about this possibility...



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


pgp0Be5Mjkss1.pgp
Description: PGP signature

Bug#1053604: ITP: libgeo-gdal-ffi-perl -- foreign function interface for GDAL/OGR binding

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libgeo-gdal-ffi-perl
  Version : 0.1
  Upstream Contact: Ari Jolma 
* URL : https://metacpan.org/release/Geo-GDAL-FFI
* License : Artistic-2.0
  Programming Lang: Perl
  Description : foreign function interface for GDAL/OGR binding

 This is a foreign function interface (FFI) to the GDAL/OGR geospatial data 
access
 library. 
 .
 The FFI interface is based on the C API for GDAL/OGR as defined in version 3.5+
 and replaces the deprecated Geo::GDAL interface based on XS.

-- 
Francesco P. Lovergine

Bug#1052446: msktutil: invalid argument unwrapping for AUTOUPDATE_OPTIONS

[Francesco]

Package: msktutil
Version: 1.2-2


bug fix for issue #1009904 doesn't look good for me:

"/etc/cron.daily/msktutil:
Error: unknown parameter: -N -h ldap-pp-01.example.org --service host 
--computer-name ldap-pp-01


For help, try running msktutil --help

run-parts: /etc/cron.daily/msktutil exited with return code 1"

On my Debian GNU/Linux 12 (bookworm) the following script update works:

$ cat /etc/cron.daily/msktutil
#!/bin/sh

test -x /usr/sbin/msktutil || exit 0

# These options are overridden in /etc/default/msktutil.
# Edit there, not here.
AUTOUPDATE_ENABLED="false"
AUTOUPDATE_OPTIONS=""

[ -r /etc/default/msktutil ] && . /etc/default/msktutil

[ "$AUTOUPDATE_ENABLED" = "true" ] || exit 0
cmd="/usr/sbin/msktutil --auto-update ${AUTOUPDATE_OPTIONS}"

exec $cmd

regards,

François

Bug#1052376: lxpanel: no longer obeys its geometry settings

[Francesco Poli]

On Thu, 21 Sep 2023 08:49:04 +0200 Francesco Poli (wintermute) wrote:

> Downgrading/reinstalling the following packages:
> 
>   libwnck-common (2.30.7-6)
>   libwnck22 (2.30.7-6+b1)
>   libkeybinder0 (0.3.1-2.1)
>   libfm4 (1.3.2-1)
>   libfm-gtk4 (1.3.2-1)
>   lxpanel-data (0.10.1-2) ...
>   lxpanel (0.10.1-2)
> 
> is enough to restore the normal (sane) behavior.

I also had to downgrade the following package:

  libfm-modules (1.3.2-1)

and to purge the following packages:

  libfm-gtk3-4
  libkeybinder-3.0-0
  libwnck-3-0
  libwnck-3-common



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


pgpixjqaCDIZ5.pgp
Description: PGP signature

Bug#1052376: lxpanel: no longer obeys its geometry settings

[Francesco Poli (wintermute)]

Package: lxpanel
Version: 0.10.1-4
Severity: grave
Justification: renders package unusable

Hello!

I have just upgraded lxpanel:

  [UPGRADE] lxpanel:amd64 0.10.1-2 -> 0.10.1-4
  [UPGRADE] lxpanel-data:amd64 0.10.1-2 -> 0.10.1-4

and not it behaves insanely.

My settings are as follows:
in the "Geometry" tab, choose Edge "Bottom", Alignment "Right",
set Margin "275", choose Monitor "1", set Width "100" "% Percent",
Height "28" "Pixels", Icon size "24" Pixels.
In the "Panel Applets" tab, I have a number of plugins,
among which a Task Bar with 'Stretch' checked.

For a complete description of my settings, see my documentation
[page].

[page]: 


Until lxpanel/0.10.1-2, this resulted in a fixed width panel,
that was as large as the screen minus 275 pixels. The panel
spanned from the left edge of the screen to a point 275 pixels
from the right edge of the screen. Various plugins were shown
from left to right, with the Task Bar that was as large as possible,
but leaving enough space for the other plugins on its left and on
its right. Everything was really good.

Now, with lxpanel/0.10.1-4, the behavior seems to have gone crazy.
The only shown plugins are the ones on the left of the Task Bar,
and the Task Bar itself. The panel spans from the left edge of
the screen to a point which moves to the left or to the right,
depending on how many windows have to be represented in the Task Bar!
With enough windows, it is even possible to see the panel become
larger than the screen!
The plugins that should appear to the right of the Task Bar are
only partially shown, and only if the panel grows beyond some
mysterious point...

In other words lxpanel has become unusable.

Downgrading/reinstalling the following packages:

  libwnck-common (2.30.7-6)
  libwnck22 (2.30.7-6+b1)
  libkeybinder0 (0.3.1-2.1)
  libfm4 (1.3.2-1)
  libfm-gtk4 (1.3.2-1)
  lxpanel-data (0.10.1-2) ...
  lxpanel (0.10.1-2)

is enough to restore the normal (sane) behavior.


Please fix this bug as soon as possible (and please do not
downgrade the severity of this bug report!).

Thanks for your time and dedication!
Bye.


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

Kernel: Linux 6.4.0-4-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 lxpanel depends on:
ii  libasound2   1.2.9-2
ii  libc62.37-8
ii  libcairo21.17.8-3
ii  libcurl3-gnutls  8.2.1-2
ii  libfm-gtk3-4 1.3.2-4
ii  libfm-modules1.3.2-4
ii  libfm4   1.3.2-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-1
ii  libgtk-3-0   3.24.38-5
ii  libiw30  30~pre9-14
ii  libkeybinder-3.0-0   0.3.2-1.1
ii  libmenu-cache3   1.1.0-1.1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.6-1
ii  libxml2  2.9.14+dfsg-1.3
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.1-4

Versions of packages lxpanel recommends:
ii  libnotify-bin  0.8.2-1
ii  notification-daemon3.20.0-4+b1
pn  pavucontrol | gnome-alsamixer  
ii  xkb-data   2.38-2
ii  xterm [x-terminal-emulator]384-1

Versions of packages lxpanel suggests:
ii  chromium [www-browser] 116.0.5845.140-1
ii  falkon [www-browser]   23.08.0-1
ii  firefox-esr [www-browser]  115.2.1esr-1
ii  w3m [www-browser]  0.5.3+git20230121-2

-- no debconf information

Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"

[Francesco Paolo Lovergine]

On Mon, Sep 04, 2023 at 10:10:05PM +0200, Jeremy Lecour wrote:

Package: proftpd-core
Version: 1.3.8+dfsg-4+deb12u1
Severity: normal

Dear Maintainer,

After upgrading to Debian 12, my SFTP client stopped working with errors when 
connecting.

I've opened a GitHub issue and the problem has been solved.
https://github.com/proftpd/proftpd/issues/1694

It will even be backported to the 1.3.8 branch, so I hope that it might be 
available in an upcoming update in Debian 12.



Nice catch, thanks. A PU can be prepared, but of course it requires a go by 
SRMs.

--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Wed, Sep 20, 2023 at 10:29:49AM +0200, Francesco P. Lovergine wrote:


The resulting package needs to be arch:any to create a correct 
internal Geo::GDAL::gdal.pm module per arch,


Err, not required if depending on libgdal-dev, indeed.

--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 06:36:13PM +0200, Francesco P. Lovergine wrote:

On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote:

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
  dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())



Mmmm, let me see. The chain I used was to impact minimally on changes for the 
module
taken from CPAN. I would be happy to minimize the use of all that stuff, I was 
not exactly
enthusiastic about the new course at the time.



Ok, it seems that the solution is much more easy than the prospected. The 
implementation is smart
enough to keep the gdal.so in the right place, something I oversight before. The resulting 
package needs to be arch:any to create a correct internal Geo::GDAL::gdal.pm module per arch,

but it seems working. That said, I would try to patch to avoid the 
Platypus::Declare use
which is currently discouraged/deprecated: I would avoid to read other 
complains by gregor :-D

Thanks a lot for the hints.


--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote:

On Tue, 19 Sep 2023 17:48:41 +0200, Francesco P. Lovergine wrote:


> Sorry to be a pain again :) but: Do we really need this?

Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
https://wiki.debian.org/BookwormGdalPerl
which is my main goal to avoid to mantain an unofficial repo for the rest
of time.


You mean because of Alien::gdal?

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
   dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())



Mmmm, let me see. The chain I used was to impact minimally on changes for the 
module
taken from CPAN. I would be happy to minimize the use of all that stuff, I was 
not exactly
enthusiastic about the new course at the time.


--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 05:39:12PM +0200, gregor herrmann wrote:

On Tue, 19 Sep 2023 11:37:29 +0200, Francesco P. Lovergine wrote:


Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-base-modulebuild-perl

…

 .
 This module is in maintenance mode, use Alien::Build for new stuff.


Sorry to be a pain again :) but: Do we really need this?

Alien::Build is already questionable¹, although I admit that patching
the requirement out can be a bit cumbersome -- but a subclass that
says "This module is in maintenance mode, use Alien::Build for new
stuff." looks a bit like a candidate for not-packaging to me …



Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
https://wiki.debian.org/BookwormGdalPerl
which is my main goal to avoid to mantain an unofficial repo for the rest
of time. 


--
Francesco P. Lovergine

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-base-modulebuild-perl
  Version : 1.17
  Upstream Contact: Joel A Berger 
* URL : https://metacpan.org/release/Alien-Base-ModuleBuild
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : subclass of Module::Build for building Alien:: modules and 
their libraries

 This is a subclass of Module::Build, that with Alien::Base allows for easy
 creation of Alien distributions. Alien::Base::ModuleBuild is used during the
 build step of your distribution. When properly configured it will
 use pkg-config to find and use the system version of the library
 download, build and install the library if the system does not provide it.
 .
 This module is in maintenance mode, use Alien::Build for new stuff.

-- 
Francesco P. Lovergine

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco P. Lovergine]

On Mon, Sep 18, 2023 at 02:40:50PM +0200, Francesco P. Lovergine wrote:

I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?




Yep indeed. Maybe a wrapper could be tought for packages that have some 
optional dep on that?



I would simply patch Mozilla::CA to have SSL_ca_file() returning the Debian directory 
/usr/share/ca-certificates/mozilla instead of the cacert.pem file. That would avoid to patch 
third-parties code that eventually use explicitly the modules. 
This is compatible with the IO::Socket::SSL module.


Does it make sense? 


--
Francesco P. Lovergine

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco P. Lovergine]

On Mon, Sep 18, 2023 at 02:33:18PM +0200, gregor herrmann wrote:

On Mon, 18 Sep 2023 14:29:08 +0200, gregor herrmann wrote:


> * Package name: libmozilla-ca-perl

We don't package Mozilla::CA in Debian because we have
ca-certificates with the same certs.


I see that you have already uploaded the package:
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html

May I suggest that you ask ftp-masters to REJECT it?




Yep indeed. Maybe a wrapper could be tought for packages that have some 
optional dep on that?

--
Francesco P. Lovergine

Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format

[Francesco Paolo Lovergine]

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

* Package name: libmozilla-ca-perl
  Version : 20230821-1
  Upstream Contact: Gisle Aas 
* URL : https://github.com/libwww-perl/Mozilla-CA
* License : MPL-2.0
  Programming Lang: Perl
  Description : Mozilla's CA cert bundle in PEM format

  Mozilla::CA provides a copy of Mozilla's bundle of Certificate Authority
  certificates in a form that can be consumed by modules and libraries
  based on OpenSSL.
  The module provide a single function:
  SSL_ca_file()
  Returns the absolute path to the Mozilla's CA cert bundle PEM file.

Bug#1043124: zfs-dkms: module fails to build for Linux 6.5: None of the expected "bops->release()" interfaces were detected.

[Francesco C]

>(Completely unrelated, but browsing the issues it popped up that encryption is
>very broken above 6.3,
>and it has been somewhat broken on older kernels too; not one people lost their
>data due to upgrading
> beyond 6.3, so beware.

"Encryption is very broken" seems too generic : it seems (to me) that
the reported issue affects zfs "native" encryption , not luks with
[(plain) zfs].

Bug#967324: eboard: depends on deprecated GTK 2

[Francesco Poli]

On Mon, 14 Aug 2023 13:22:13 +0200 Bastian Germann 
wrote:

> There are many alternatives for eboard in Debian. Maybe
> it is time to remove this package.

Fine, could you please name those many alternatives for eboard in
Debian?

After a quick search, I found

  xboard <https://packages.debian.org/sid/xboard>

and maybe

  tagua <https://packages.debian.org/sid/tagua>
  scid <https://packages.debian.org/sid/scid>

Any other?

Which ones may be used to play chess with package 'stockfish'?
Possibly through 'polyglot'?

Please let me know.
Thanks for your time and patience!



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


pgpf0s57v_MGD.pgp
Description: PGP signature

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Francesco Poli]

On Thu, 31 Aug 2023 15:28:44 +0200 Preuße, Hilmar  wrote:

[...]
> This issue 
> should have been solved in texlive-base_2023.20230311.66589-3, which as 
> finally uploaded to unstable.

Hello,
I am another user who experienced the issue.

I can confirm that upgrading to texlive-base/2023.20230613-3 from
unstable (which pulls some 3 GB of other packages, in my installation)
seems to fix the configuration error.

I think this kind of mismatches should be prevented with slightly
tighter package relationships (Breaks, Depends, ...).
I hope this can be done, so that users who track Debian testing will no
longer be affected.

Thanks for your time and dedication!



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


pgp43MAN8PpMK.pgp
Description: PGP signature

Bug#1050932: wget2: -X and --exclude-directories do not work

[Francesco Potortì]

Package: wget2
Version: 1.99.1-2.2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

$ wget2 -X /cache evaal.aaloa.org
Unknown option '-X'

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

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

Versions of packages wget2 depends on:
ii  libc6 2.37-7
ii  libgpgme111.18.0-3+b1
ii  libpcre2-8-0  10.42-3
ii  libwget0  1.99.1-2.2

Versions of packages wget2 recommends:
ii  ca-certificates  20230311

wget2 suggests no packages.

-- no debconf information

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

On Wed, 30 Aug 2023 00:19:51 +0200 Vincent Lefevre wrote:

> On 2023-08-29 22:45:40 +0200, Francesco Poli wrote:
> > On Sun, 2 Apr 2023 23:18:57 +0200 Vincent Lefevre wrote:
[...]
> > > But then, how can one get the error messages (which are still
> > > important) in the terminal?
> > 
> > Maybe the following could achieve this goal:
> > 
> >   DPkg::Pre-Install-Pkgs {"/usr/bin/bash -c '/usr/bin/apt-listbugs -d apt 
> > 2> >(/usr/bin/tee /tmp/apt-listbugs.err)'";};
> >   DPkg::Tools::Options::/usr/bin/bash "";
> >   DPkg::Tools::Options::/usr/bin/bash::Version "3";
> >   DPkg::Tools::Options::/usr/bin/bash::InfoFD "20";
> 
> I don't see how this would separate the debug messages from the
> error messages. I recall that I do *not* want the debug data on
> the screen.

Sorry, I must have misunderstood your request.

So you want the debug output (which is currently sent to stderr)
to be redirected to a file, while the normal output (which is sent to
stdout) and any error messages (which are sent to stderr)
should still be sent to the controlling terminal.
Is this correct?

I don't know how to achieve this, without modifying apt-listbugs.
Oh well, maybe I should modify apt-listbugs and add an option to
specify a file for the debug output...

I'll think about it.


In the meanwhile, could you please tell me whether you have experienced
this bug (#1019732) again, since the time when you originally reported
it?
Is it still reproducible on an up-to-date Debian testing/unstable box
(although sporadically)?
Or should I close the bug report as unreproducible?

Thanks for your time and patience!



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


pgpzwUKtoExcH.pgp
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

On Sun, 2 Apr 2023 23:18:57 +0200 Vincent Lefevre wrote:

> On 2023-04-02 17:32:29 +0200, Francesco Poli wrote:
> > On Thu, 30 Mar 2023 01:02:00 +0200 Vincent Lefevre wrote:
> > 
> > > On 2023-03-29 14:25:23 -0300, Antonio Terceiro wrote:
> > [...]
> > > > If anyone can still see this bug, it would be nice to configure
> > > > apt-listbugs in debug mode, e.g. setting
> > > > 
> > > > DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt";};
> > > > 
> > > > in /etc/apt/apt.conf.d/10apt-listbugs (i.e. adding the `-d` option), so
> > > > that when it happens we have a trace of the requests/reponses.
> > > 
> > > Is it possible to redirect (only) the debug data to a file?
> > > Otherwise that's too invasive.
> > 
> > All (well, almost all) debug output goes to stderr, so, yes, it should
> > be possible to redirect only the debug data to a file.
> > 
> > I think that
> > 
> >   DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt 2> 
> > /tmp/apt-listbugs.err";};
> > 
> > should achieve that goal.
> 
> But then, how can one get the error messages (which are still
> important) in the terminal?

Maybe the following could achieve this goal:

  DPkg::Pre-Install-Pkgs {"/usr/bin/bash -c '/usr/bin/apt-listbugs -d apt 2> 
>(/usr/bin/tee /tmp/apt-listbugs.err)'";};
  DPkg::Tools::Options::/usr/bin/bash "";
  DPkg::Tools::Options::/usr/bin/bash::Version "3";
  DPkg::Tools::Options::/usr/bin/bash::InfoFD "20";

I tried it in a chroot, and it seems to work as intended.
Inspiration from
<https://unix.stackexchange.com/questions/333198/bash-redirect-stderr-to-file-and-stdout-stderr-to-screen>


By the way, has anyone experienced this bug again, recently?
Or should I close it as unreproducible?

Please let me know, thanks!


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


pgpXC0tOrylVg.pgp
Description: PGP signature