Bug#1071407: lintian: please highlight tags which result in automatic FTP master rejects

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.117.0
Severity: wishlist
X-Debbugs-Cc: invernom...@paranoici.org

Hello!

Lintian has the very useful option -F (--ftp-master-rejects) for running
only the checks that issue tags that result in automatic rejects
from the Debian upload queue.
This is great, but requires a separate invocation of lintian in order
to be used as a QA check.

I mean, if I run lintian without the -F option, I may obtain a number of
tags for the analyzed package, but there does not seem to be any explicit
hint on which of the issued tags are also FTP master auto rejection tags.
In other words, unless I manually compare the tags with the list
of [auto-reject tags], I cannot tell whether any of the tags is deemed
grave enough to warrant an automatic reject from the Debian upload queue,
and which one is.

[auto-reject tags]: 

Maybe I can explain myself better with an example.

I made the following experiment: I took a package source tree and deliberately
removed its debian/copyright file. I rebuilt the package and checked it with

  $ lintian -viF $CHANGES_FILE
  N:
  E: ${PACKAGE}: no-copyright-file
  N:
  N:   Each binary package has to include a plain file
  N:   /usr/share/doc/*pkg*/copyright
  N:
  N:   Please refer to Copyright information (Section 12.5) in the Debian Policy
  N:   Manual for details.
  N:
  N:   Visibility: error
  N:   Show-Always: no
  N:   Check: debian/copyright
  N:

Good: as expected, lintian found a missing copyright file in the Debian
binary package and complained with the "no-copyright-file" tag, which is
in the list of [auto-reject tags].

But what if I want to check a lot of things in the package (not only
the ones that may result in automatic rejects)?
If this is the case, I can check the package with

  $ lintian -EviIL +pedantic $CHANGES_FILE
  N:
  E: ${PACKAGE}: no-copyright-file
  N:
  N:   Each binary package has to include a plain file
  N:   /usr/share/doc/*pkg*/copyright
  N:
  N:   Please refer to Copyright information (Section 12.5) in the Debian Policy
  N:   Manual for details.
  N:
  N:   Visibility: error
  N:   Show-Always: no
  N:   Check: debian/copyright
  N:
  N:
  W: ${PACKAGE} source: no-debian-copyright-in-source
  N:
  N:   Every package must include the file /usr/share/doc/*pkg*/copyright. A 
copy
  N:   of this file should be in debian/copyright in the source package.
  N:
  N:   Please refer to Copyright information (Section 12.5) in the Debian Policy
  N:   Manual for details.
  N:
  N:   Visibility: warning
  N:   Show-Always: no
  N:   Check: debian/copyright
  N:   Renamed from: no-debian-copyright
  N:

This lintian run issues two tags, but it's not clear which one will result
in an automatic reject, if any.
Since I also ran "lintian -viF" separately, I know that the first one
will result in an automatic reject, while the second one won't.
But in order to be aware of this, I had to run lintian twice
(or manually search the tags in the list of [auto-reject tags], which
is really inconvenient).

I think it would be really great, if lintian highlighted which tags
(among the ones it emits) will also result in an automatic reject.
Maybe with something like:

  N:   Visibility: error
  N:   Show-Always: no
  N:   FTP-master-reject: yes
  N:   Check: debian/copyright

This additional piece of information could be enabled by a dedicated
option.
This new option could perhaps be called "--show-ftp-master-rejects",
or something similar...
Having this option would allow me to run lintian only once, as in:

  $ lintian -EviIL +pedantic --show-ftp-master-rejects $CHANGES_FILE

Wouldn't it be great?   ;-)

I hope you agree with this feature request!
Please implement it.

Thanks for your time and dedication!
Bye.

Bug#899000: piuparts: allow running tests in lxc and VM backends

[Francesco Poli]

On Fri, 18 May 2018 14:07:07 +0200 Balint Reczey  
wrote:
> Package: piuparts
> Version: 0.86
> Severity: wishlist
> 
> Dear Maintainers,
> 
> 
> Piuparts checks many package operations in a chroot, but since in the
> chroot there are no running services service uprades and similar parts
> of the mainitainer scripts are not tested.
> 
> We already have autopktests using lxc/VM backends thus simple
> installation tests of services can be implemented easily, but for
> service upgrade tests piuparts seems to be the best place where they
> could be added.
> 
> The added backends would also excersice the parts of maintainer
> scripts where a running init system is assumed.

This looks like a really good idea!

I run autopkgtest on a QEMU virtual machine testbed with:

  $ autopkgtest $OTHER_OPTIONS \
-- qemu --boot=efi --overlay-dir /dev/shm \
   unstable-autopkgtest-amd64.img

It would be really great, if I could also use the same QEMU virtual
machine image to run piuparts!

Please, pretty please, implement this new feature in piuparts!


-- 
 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


pgpufV_HpLwuA.pgp
Description: PGP signature

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Francesco Poli]

On Sun, 12 May 2024 23:10:14 +0200 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (wintermute) (2024-05-12 21:06:24)
[...]
> > Please note that my current setup with pbuilder does not have this issue:
> > pdebuild generates a .changes file with 'Distribution: UNRELEASED'
> > and with the latest changelog entry correctly quoted (with 'UNRELEASED'
> > after the version number parenthesis), and hence lintian is happy...
> 
> Wait... how is Lintian happy with UNRELEASED as the changelog entry?

After digging Lintian code for a while (sorry, my Perl knowledge is
just a smattering, and it is also a bit rusty at the time of writing!),
I found the following [code]

# issue only when not mentioned in the Distribution field
if ((any { $_ eq 'UNRELEASED' } @changesdists)
&& none { $_ eq 'UNRELEASED' } @distributions) {
$self->hint('unreleased-changes');
return;
}

[code]: 
<https://salsa.debian.org/lintian/lintian/-/blob/69b9209b02ab1a9e2d40d83931541ab6629f9226/lib/Lintian/Check/Fields/Distribution.pm#L135>

It seems to me that the 'unreleased-changes' tag is issued, if the
distribution found in the Changes field is 'UNRELEASED' and the
distribution found in the Distribution field is not 'UNRELEASED'.
Or am I completely off-track?

[...]
> The only difference between sbuild and pbuilder should be this:
> 
> >   W: $PKG_NAME: changelog-distribution-does-not-match-changes-file 
> > unreleased != unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]
> 
> The reason for that difference is, that sbuild-qemu calls sbuild with the -d
> option and that overwrites the distribution field. Christian, why does
> sbuild-qemu use the -d option?
> 
> But this lintian error should also be present with pbuilder:
> 
> >   E: $PKG_NAME changes: unreleased-changes
> 
> Can you clarify?

I checked by running lintian again on the .changes file generated by
pdebuild:

  $ lintian ${PKG_NAME}_${VERSION}_${ARCH}.changes
  
  $ lintian -EviIL +pedantic ${PKG_NAME}_${VERSION}_${ARCH}.changes

These commands produce no output.

Assuming the above analysis of what the Perl code of Lintian actually
does is correct, it seems the reason is that both Distribution and
Changes have 'UNRELEASED' as distribution:

  $ grep UNRELEASED ${PKG_NAME}_${VERSION}_${ARCH}.changes
  Distribution: UNRELEASED
   $PKG_NAME ($VERSION) UNRELEASED; urgency=medium


-- 
 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


pgpEAWsli8qCJ.pgp
Description: PGP signature

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Francesco Poli (wintermute)]

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

Hello!

I am still trying to set up sbuild-qemu to build (and check/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;
  $run_lintian = 1;
  $lintian_require_success = 0;
  $run_piuparts = 1;
  $piuparts_root_args = '';
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $autopkgtest_root_args = '';
  $autopkgtest_require_success = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

I can update the virtual machine:

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

and I can build a package from within the unpacked source tree:

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm

However, when I do so, I am not necessarily planning to upload the
Debian package to the Debian archive: it could be still in development
(not yet ready for an upload) and I just want to check that it can be
built and perform the usual checks on it, namely lintian (first of all!),
followed by piuparts and autopkgtest.
If this is the case, my latest changelog entry will read 'UNRELEASED' in the
distribution field, but, at the same time, I want to build the package
with the 'unstable-autopkgtest-amd64.img' VM image (to build it for
unstable).

What happens here? It turns out that sbuild-qemu modifies the Distribution
field in the .changes file and sets it to 'unstable', despiting reading
'UNRELEASED' in the latest changelog entry.
Hence lintian complains with an error:

  [...]
  Running lintian...
  E: $PKG_NAME changes: unreleased-changes
  W: $PKG_NAME: changelog-distribution-does-not-match-changes-file unreleased 
!= unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]
  
  E: Lintian run failed (runtime error)
  [...]

How can I fix this issue?
Shouldn't it work out of the box?

I found bug report [#934721], which, however, seems to advocate that
this is the right behavior ?!? Or am I misinterpreting it?

[#934721]: 

How can I run lintian on a still-in-developed UNRELEASED package (with
sbuild-qemu)?

Please note that my current setup with pbuilder does not have this issue:
pdebuild generates a .changes file with 'Distribution: UNRELEASED'
and with the latest changelog entry correctly quoted (with 'UNRELEASED'
after the version number parenthesis), and hence lintian is happy...

It has to work out of the box with sbuild-qemu, as well!

Please fix the issue and/or explain what's wrong.

Thanks for your time and patience.


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

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

Versions of packages sbuild-qemu depends on:
ii  autopkgtest  5.34
ii  python3  3.11.8-1
ii  python3-pexpect  4.9-2
ii  python3-psutil   5.9.8-2
ii  qemu-system-x86  1:8.2.3+ds-2
ii  qemu-utils   1:8.2.3+ds-2
ii  sbuild   0.85.8
ii  vmdb20.40-1

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

sbuild-qemu suggests no packages.

-- no debconf information

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

[Francesco Poli]

On Sat, 13 Apr 2024 14:50:05 +0200 Francesco Poli wrote:

[...]
> On Fri, 12 Apr 2024 19:57:23 +0200 Johannes Schauer Marin Rodrigues
> wrote:
[...] 
> > Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
[...]
> > > 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.

If this is possible for piuparts, could you please explain why
sbuild-qemu does not do so?

Otherwise, if this is not possible, could please explain why?

> 
> Does sbuild{,-qemu} do so for lintian?
[...]

I checked: sbuild-qemu (temporarily) installs lintian inside the build
environment and runs it from within the build environment.
I think this is the best strategy, especially for lintian, as I have
previously explained.
That reinforces my opinion that the same strategy should probably be
followed for piuparts, as well...


Anyway, I am having issues in running piuparts, even after installing
it on the host.

I tried to run

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm

with 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;

It builds the package successfully, but, once it reaches the piuparts
step, sudo asks for my (host system) regular user's password.
My understanding is that it should not need to use sudo, since it should
use the QEMU virtual machine image (where it has root access).
Is that right? Or am I misunderstanding something?

The same thing happens at the autopkgtest step, where, again, sudo asks
for my regular user's password. Once again, this should not be needed:
autopkgtest should use the QEMU virtual machine as a testbed.
At least, when I manually run autopkgtest, I can use the QEMU virtual
machine and no password is asked for.

I tried to modify the configuration file:

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

It no longer asks for passwords, but fails to run piuparts:

  piuparts
  

  You need to be root to use piuparts.

  E: Piuparts run failed.

And it also fails to run autopkgtest:

  autopkgtest
  ---
  
  autopkgtest [19:56:04]: starting date and time: 2024-05-11 19:56:04+0200
  [...]
  autopkgtest [19:56:05]: test unit_test: preparing testbed
  autopkgtest [19:56:05]: ERROR: "sh -ec
type apt-ftparchive >/dev/null 2>&1 || DEBIAN_FRONTEND=noninteractive 
apt-get install -y apt-utils 2>&1
(cd /tmp/autopkgtest.jrHchc/binaries; apt-ftparchive packages . > Packages; 
apt-ftparchive release . > Release)
printf 'Package: *\nPin: origin ""\nPin-Priority: 1002\n' > 
/etc/apt/preferences.d/90autopkgtest
echo "deb [ trusted=yes ] file:///tmp/autopkgtest.jrHchc/binaries /" 
>/etc/apt/sources.list.d/autopkgtest.list
if [ "x`ls /var/lib/dpkg/updates`" != x ]; then
  echo >&2 "/var/lib/dpkg/updates contains some files, aargh"; exit 1
fi
apt-get --quiet --no-list-cleanup -o 
Dir::Etc::sourcelist=/etc/apt/sources.list.d/autopkgtest.list -o 
Dir::Etc::sourceparts=/dev/null update 2>&1
cp /var/lib/dpkg/status /tmp/autopkgtest.jrHchc/1-apt-update.out
" failed with stderr "sh: 4: cannot create 
/etc/apt/preferences.d/90autopkgtest: Permission denied
  "
  autopkgtest [19:56:05]: Binaries: resetting testbed apt configuration
  Reading package lists...
  E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission 
denied)
  E: Unable to lock directory /var/lib/apt/lists/
  [...]
  E: Autopkgtest run failed.

It seems to me that autopkgtest is not using the QEMU virtual machine
as testbed, or am I wrong?


Why isn't all this working out of the box?
Is there any missing setting in ~/.sbuildrc ?
If this is the case, why isn't sbuild-qemu passing those needed options
by default?

Please explain.
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


pgp1PXbWEgVnH.pgp
Description: PGP signature

Bug#1062831: closed by Debian FTP Masters (reply to Dennis Braun ) (Bug#1062831: fixed in guitarix 0.46.0+dfsg-1)

[Francesco Poli]

On Fri, 29 Mar 2024 19:45:05 + Debian Bug Tracking System wrote:

[...]
>* New upstream version 0.46.0+dfsg
>  + Fix segfaults, when creating a preset bank (Closes: #1062831)
[...]

Thanks a lot, I can confirm that this bug is fixed.   :-)

Bye and keep up the good work!


-- 
 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


pgpcsAoMh7AVF.pgp
Description: PGP signature

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

[Francesco Poli]

On Tue, 23 Apr 2024 17:12:54 +0300 jim_p  wrote:
[...]
> 
> Since there is no interest from the maintainers in fixing a 6+ month old grave
> bug, I want to ask. Has anyone moved away from lxpanel or even lxde?
[...]

Hello!

I am the original submitter of this bug report.

I have recently moved away from lxpanel: I have switched to xfce4-panel.

I had to adjust my setup a little, but, overall, I am quite happy with
what I could achieve.

My current setup (within a desktop based on Fluxbox) is described in my
documentation [page].

[page]: 
<https://www.inventati.org/frx/doc/nanodocs/testing_workstation_desktopconf.html#panel>

I hope this helps.
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


pgpQ5Z0KZS1Kv.pgp
Description: PGP signature

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

[Francesco Poli]

Control: severity -1 important
Control: retitle -1 please warn users about the option --pppd-accept-remote 
needed for ppp >= 2.5.0


On Sat, 04 May 2024 00:23:32 +0200 Francesco Poli (wintermute) wrote:

[...]
>   Peer refused to agree to his IP address
[...]

I tried to downgrade ppp to version 2.4.9-1+1.1+b1 and openfortivpn is
working again.

By searching the web, I found openfortigui issue [#194], which mentions
the new option --pppd-accept-remote that has to be used with
openfortvpn, when ppp version >= 2.5.0 ...

[#194]: <https://github.com/theinvisible/openfortigui/issues/194>

I actually added

  pppd-accept-remote = true

to my /etc/openfortivpn/MYNETWORK and now openfortivpn works again
(with ppp/2.5.0-1+2).

I am therefore lowering the severity of this bug report.

I am not closing it, though, since I believe that such an important
behavior change (the need to add an option, if ppp version >= 2.5.0)
should really be communicated to the users of the openfortivpn Debian
package users.
Maybe a NEWS.Debian file in /usr/share/doc/openfortivpn could be added
to document this new need?
I really believe that users should be warned about this!




-- 
 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


pgpZHMqUG_HMM.pgp
Description: PGP signature

Bug#1070344: gmsh: please enable CGNS support

[Francesco Poli (wintermute)]

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


Hello and thanks for maintaining this package in Debian!

I noticed that, if I start it with:

  $ gmsh -format cgns

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

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

Thanks for your time and dedication!


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

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

Versions of packages gmsh depends on:
ii  libc6   2.37-18
ii  libgmsh4.12t64  4.12.2+ds1-1

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

gmsh suggests no packages.

-- no debconf information

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

[Francesco Poli (wintermute)]

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

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

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

Now it does:

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

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

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

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

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

Looks unlikely...

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

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


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

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

Versions of packages openfortivpn depends on:
ii  libc62.37-19
ii  libssl3t64   3.2.1-3
ii  libsystemd0  255.5-1
ii  ppp  2.5.0-1+2

openfortivpn recommends no packages.

Versions of packages openfortivpn suggests:
pn  resolvconf  

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

-- no debconf information

Bug#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#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#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#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#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#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#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#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#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#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]

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: 39BDEF0B-9FF8-4DB9-921B-FA7A6C2CDB54).
  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 2 GiB.
  Partition #2 contains a ext4 signature.
  sid_amd64.img3: Done.
  
  New situation:
  Disklabel type: gpt
  Disk identifier: 39BDEF0B-9FF8-4DB9-921B-FA7A6C2CDB54
  
  Device  Start End Sectors  Size Type
  sid_amd64.img1   2048  262143  260096  127M EFI System
  sid_amd64.img2 262144 4456447 41943042G Linux filesystem
  
  The partition table has been altered.
  Syncing disks.
  $ echo $?
  0
  $ ls -lF --si sid_amd64.img 
  -rw-r-xrwx 1 $USER $USER 2.3G Jan 14 18:17 sid_amd64.img*
  $ mv -i sid_amd64.img ~/Downloads/

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?


-- 
 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


pgp7NUqyXoPnf.pgp
Description: PGP signature

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#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#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#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#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#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#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#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#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

Bug#1042714: closed by Debian FTP Masters (reply to Chris Hofstaedtler ) (Bug#1042714: fixed in util-linux 2.39.2-1)

[Francesco Poli]

On Sun, 20 Aug 2023 21:15:03 + Debian Bug Tracking System wrote:

[...]
>  * libmount: Fix regression when mounting with atime (Closes: #1042714)
[...]

I've just checked libmount1/2.39.2-1 (from unstable) and I can confirm
that the regression has been fixed.

Thanks to all the people involved with the resolution of this
issue!   :-)

Now, it would be great, if this version (2.39.2-1) could migrate to
testing soon...

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


pgpOT_ijcOFTM.pgp
Description: PGP signature

Bug#1042714: libmount1: fails to mount vfat filesystem on USB mass storage device with pmount

[Francesco Poli (wintermute)]

Package: libmount1
Version: 2.39.1-3
Severity: important

Hello, thanks for maintaining util-linux in Debian!

After upgrading to version 2.39.1-3, I experienced the following
issue. When I try to use 'pmount' to mount a vfat filesystem on
a USB mass storage device (a digital photocamera, in the present case)
I get a weird error message, claiming that the NTFS signature is missing.
Well, it's a vfat filesystem, so no surprise it's missing NTFS
features...

  $ pmount sdb1 camera
  NTFS signature is missing.
  Failed to mount '/dev/sdb1': Invalid argument
  The device '/dev/sdb1' doesn't seem to have a valid NTFS.
  Maybe the wrong device is used? Or the whole disk instead of a
  partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
  NTFS signature is missing.
  Failed to mount '/dev/sdb1': Invalid argument
  The device '/dev/sdb1' doesn't seem to have a valid NTFS.
  Maybe the wrong device is used? Or the whole disk instead of a
  partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

If I use 'mount' (as the root user) and explicitly specify the
filesystem type, the partition is correctly mounted:

  # mount -t vfat /dev/sdb1 /mnt

However, this is impractical, as it requires root privileges.

As soon as I downgrade package libmount1 (and package mount) to
version 2.38.1-6, everything works again as usual:

  $ pmount sdb1 camera
  $ df --si /media/camera
  FilesystemSize  Used Avail Use% Mounted on
  /dev/sdb1 512M  7.0M  506M   2% /media/camera

What's going on?
Has libmount1/2.39.1-3 lost the capability to recognize vfat
filesystems?

Please investigate and fix this bug as soon as possible.
Thanks for your time and for any help you may provide!



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

Kernel: Linux 6.4.0-1-amd64 (SMP w/2 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 libmount1 depends on:
ii  libblkid12.39.1-3
ii  libc62.37-6
ii  libselinux1  3.5-1

libmount1 recommends no packages.

Versions of packages libmount1 suggests:
pn  cryptsetup-bin  

-- no debconf information

Bug#1036424: sylpheed: replying to an email you sent doesn't set account accordingly

[Francesco Poli]

On Wed, 14 Jun 2023 16:00:12 +0900 Hideki Yamane  wrote:
[...]
>  As I wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036388,
>  please describe your environment and reproducible way step by step.

Hello,
I am another user of Sylpheed (in Debian).

Personally, I can reproduce the reported issue, but with a difference.

In order to reproduce, configure at least two e-mail accounts in
Sylpheed.
Let's call them:

  * Albert AtWork
  * Bert BeachBum

Let's say that "Albert AtWork" is the default account.

Send an e-mail message from "Bert BeachBum" to your friend "Frank
Friend".
Now reply to your own e-mail message, with the intent to write again
from "Bert BeachBum" to "Frank Friend".

The original bug reporter claims that the reply is prepared from the
default account "Albert AtWork", instead of from the previously used
account "Bert BeachBum".

What I experience personally, is that the reply is prepared from the
currently selected account (not necessarily from the default account).
If you select "Bert BeachBum" (menu entry 'Configuration' → 'Change
current account'), and then use the 'Reply' command, the reply will be
prepared from "Bert BeachBum", as intended.
On the other hand, if you select "Albert AtWork" as current account,
the reply will be prepared from "Albert AtWork".

Well, this may make sense, after all.
If I have selected an account as current, I mean that I want to send
e-mail messages from that account.

On the other hand, when I reply to an e-mail message sent to one of my
accounts (for instance from "Frank Friend" to "Bert BeachBum"), that
account is automatically selected, when I use the 'Reply' command, even
if it was not the current account.

Hence, what the original bug reporter is asking may be considered as
useful feature.
But I would not consider it as a bug of severity "grave".
Maybe the severity should be set to "important" or "normal", or even
"wishlist"...

I hope this helps.
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


pgp6IrIKT23_e.pgp
Description: PGP signature

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

[Francesco Poli]

On Mon, 26 Jun 2023 08:33:09 +0200 Johannes Schauer Marin Rodrigues wrote:

> Francesco, you initially reported this issue. Do you share my conclusion that
> debvm solves the problem you raised about creating autopktest disk images
> without superuser privileges?
> 
> Thanks!

Hi Johannes,
thanks for following up on this bug report!

I really appreciate all the investigation and development work done by
you and others, but I must confess that I somewhat lost track of all
the details.:-p

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...



-- 
 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


pgp6NOd08LU3d.pgp
Description: PGP signature

Bug#1036388: sylpheed: account is reset when mail is checked

[Francesco Poli]

Control: fixed -1 sylpheed/3.8.0~beta1-1


On Sat, 20 May 2023 14:17:43 +0200 José Luis González
 wrote:

[...]
> It turns out the bug doesn't happen when email is received, but rather
> when it was checked by sylpheed, which makes it even more grave, since
> it's resetting it every X minutes, 10 in my case.

Hello,
I am another user of Sylpheed (in Debian).

For what is worth, I do not experience this bug.
I would at least say that the bug is not present in an up-to-date
Debian testing system.

But, to be honest, I do not remember to have ever experienced this bug,
not even when sylpheed/3.7.0-8 was installed on my boxes...

I have more than one e-mail account configured in Sylpheed and I
usually check them all (with the "Get all" button or with the "Get from
all account" systray icon context menu entry).
The currently selected account does not change.
Not even when I receive e-mail messages from different accounts.

I even tried to enable the e-mail auto-check (which I usually keep
disabled) and to select an account other than the first one.
Still, the selected account did not change, until I explicitly selected
another one...

Maybe there's something weird with your Sylpheed configuration?
I am not familiar enough with Sylpheed internals to be able to help you
in debugging the issue, but I wanted to speak up, since I am not able
to reproduce the bug.

Bye and good luck!


-- 
 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


pgpKXt5_ZbcPN.pgp
Description: PGP signature

Bug#1035308: jackd2: missing man page for alsa_in/alsa_out (alsa_io)

[Francesco Poli (wintermute)]

Package: jackd2
Version: 1.9.21~dfsg-2
Severity: minor

Hello!

I've recently found out about alsa_in and alsa_out, which seem to be
useful tools to support additional sound cards.

But where's the man page for these two tools?
There seems to be [one] in Debian/bullseye (jackd2/1.9.17~dfsg-1)

[one]: 

But, apparently, package jackd2 somehow lost this man page since the
time bullseye was released as stable...

Was this man page intentionally dropped?
Why? I cannot find any trace in /usr/share/doc/jackd2/changelog.Debian.gz

Or was the man page dropped by accident?
If so, please re-enable it. The man page seems to be included in
the [source] package, but not in the binary package:

  $ dpkg -L jackd2 | grep man/
  /usr/share/man/man1
  /usr/share/man/man1/jackd.1.gz

[source]: 


I am not sure whether this fix is considered an [appropriate] change during
the hard freeze: maybe it is a documentation fix?!?
In case it is not, it's anyway OK, if you fix this bug after bookworm is out.

[appropriate]: 



Thanks for your time and dedication!


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

Kernel: Linux 6.1.0-7-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 jackd2 depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libasound2 1.2.8-1+b1
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libexpat1  2.5.0-1
ii  libgcc-s1  12.2.0-14
ii  libjack-jackd2-0   1.9.21~dfsg-2
ii  libopus0   1.3.1-3
ii  libreadline8   8.2-1.3
ii  libsamplerate0 0.2.2-3
ii  libsndfile11.2.0-1
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.6-1
ii  libzita-alsa-pcmi0 0.6.1-1
ii  libzita-resampler1 1.8.0-2
ii  python33.11.2-1+b1
ii  python3-dbus   1.3.2-4+b1

Versions of packages jackd2 recommends:
pn  jackd2-firewire  
ii  libpam-modules   1.5.2-6
ii  qjackctl 0.9.9-1

Versions of packages jackd2 suggests:
pn  jack-tools   
pn  meterbridge  

-- debconf information excluded

Bug#1033595: closed by Debian FTP Masters (reply to Sebastian Ramacher ) (Bug#1033595: fixed in mpv 0.35.1-2)

[Francesco Poli]

On Fri, 31 Mar 2023 19:09:05 + Debian Bug Tracking System wrote:

[...]
>* debian/patches: Apply upstream patches for yt-dlp 2023.03.04 
> compatibility
>  (Closes: #1033595, #1033609)

Hello!

Thanks a lot for cherry-picking the patches.
I can confirm that mpv/0.35.1-2 fixes the issues and works like a charm!

Please remember to apply for an unblock, so that the fixed version may
migrate from unstable to testing, despite the freeze.

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


pgpxkK5U0H6sB.pgp
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

On Sun, 2 Apr 2023 09:42:54 -0300 Antonio Terceiro wrote:

> On Sat, Apr 01, 2023 at 08:28:28PM +0200, Francesco Poli wrote:
[...]
> > Hi Antonio,
> > is there a better alternative SOAP client library for Ruby in Debian?
[...]
> I have no idea, I never worked on anything that needed to support SOAP,
> except the occasional patch for apt-listbugs itself. savon looks more
> active, having a release last December. But maybe just updating soap4r
> based on that fork (which seems abandoned in 2018) is good enough? I
> don't know.

Antonio,
do you think it makes sense, if I reassign the bug report to
ruby-soap4r?

The circumstantial evidence collected during the investigation that you
and Vincent have carried out seems to suggest that the issue is
probably due to ruby-soap4r, although we do not have conclusive
evidence...

Having the bug report reassigned to ruby-soap4r may serve as a reminder
to try to update the Debian package to a more active (or a less-long
abandoned!) fork of soap4r. Not now, of course, but after bookworm
has been released.

Please let me know if you agree with this plan.


-- 
 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


pgpXpbiv0Mtbh.pgp
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

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.

-- 
 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


pgpB4Hl3Cs8Kf.pgp
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

On Wed, 29 Mar 2023 14:25:23 -0300 Antonio Terceiro wrote:

> On Wed, Mar 29, 2023 at 03:40:21AM +0200, Vincent Lefevre wrote:
> > On 2023-03-28 20:37:56 -0300, Antonio Terceiro wrote:
> > > Still, I see no evidence that this is caused by the Ruby interpreter.
> > > For example apt-listbugs uses a SOAP library that is severely
> > > unmaintained upstream and has been on life support for some time now.
[...]

Hi Antonio,
is there a better alternative SOAP client library for Ruby in Debian?

Searching [the] [web], I've seen some people recommending [Savon], but I
cannot find it in Debian, not even in an ITP or RFP bug report...

[the]: 
<https://stackoverflow.com/questions/40273/whats-the-best-way-to-use-soap-with-ruby>
[web]: 
<https://medium.com/@victoria.huang/setting-up-a-ruby-soap-client-2237fc46170a>
[Savon]: <https://www.savonrb.com/>

Any other alternative?

More maintained forks of ruby-soap4r?
Maybe [rubyjedi's fork], but that is also not too alive (last commit in
2018...).

[rubyjedi's fork]: <https://github.com/rubyjedi/soap4r>




-- 
 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


pgpSIpvT_oa1G.pgp
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

Control: reassign -1 ruby 1:3.0+1
Control: affects -1 + apt-listbugs


On Fri, 24 Mar 2023 00:40:41 +0100 Francesco Poli wrote:

[...]
> What you saw seems to be another case where some text from the source
> (a line taken from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb, in
> this instance) is treated as a String by the Ruby interpreter and its
> `default' method is invoked. But the String class has no `default'
> method, which causes the error.
> 
> This seems to happen sporadically and cannot be easily reproduced.
> 
> I cannot understand what's going on.
> I am more and more persuaded that this bug report should be reassigned
> to another package (probably package ruby), in order to ask for an
> investigation by people more knowledgeable than me...


Dear Debian Ruby Team,
I am reassigning this [bug] to package ruby, since a couple of users
are experiencing awkward and sporadic behaviors that I really cannot
understand and do not seem due to the code of apt-listbugs or of the
libraries.

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

Could you please investigate these sporadic issues?
Refer to the [bug] log for more detailed information.

Thanks for your time and dedication!
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


pgp05090y1bHF.pgp
Description: PGP signature

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Francesco Poli]

On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:

[...]
> On Sun, 26 Mar 2023, Francesco Poli (wintermute) wrote:
[...]
> This actually "only" happens when you use bestvideo, other formats such as 
> '22' still work.
> 
> Eg, `mpv --ytdl-format=22 https://www.youtube.com/watch?v=RZAq-_gz_W8`

Does this require to examine which formats are available, by issuing
the command

  yt-dlp --list-formats https://www.youtube.com/watch?v=

for each video you want to play?

[...]
> > Please fix this issue as soon as possible, or revert to the previous
> > version (yt-dlp/2023.02.17-1), until this behavior has been properly
> > investigated and solved.
> 
> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
> is a workaround for the aforementioned throttling, to revert would mean to 
> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
> utilize yt-dlp with the default quality option.
> 
> If we weren't so close to the freeze I'd say the right option would be to 
> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
> an option anymore either.

Why not?

The [freeze policy] states that, even in full freeze, fixes for
important bugs are appropriate, as long as they can be done via unstable
(as it is currently the case for mpv).

[freeze policy]: <https://release.debian.org/bookworm/freeze_policy.html>

I have just filed bug [#1033595], in order to request that the patches
you cited are applied to mpv.

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

I hope this can be the way to go.


-- 
 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


pgp0CAov214DF.pgp
Description: PGP signature

Bug#1033595: mpv: fails to play YouTube videos after yt-dlp upgrade to version 2023.03.04-1

[Francesco Poli (wintermute)]

Package: mpv
Version: 0.35.1-1
Severity: important

Hi and thanks for maintaining mpv in Debian!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1,
mpv is no longer able to use yt-dlp to play YouTube videos.

This seems to be due to a change in yt-dlp to solve widespread, severe 
throttling. According to yt-dlp Debian package maintainer, mpv needs
[two] little [patches], in order to adapt to the new yt-dlp version.

[two]: 

[patches]: 


For more details, see bug [#1033517].

[#1033517]: 


Now, I am well aware that bookworm is currently in hard freeze, but I
believe that this bug is important (very important, I would say!) and
should be fixed, even during the freeze.
According to the [freeze policy], even in full freeze, fixes for
important bugs are appropriate, as long as they can be done via unstable
(as it is currently the case for mpv).

[freeze policy]: 

Please, please consider cherry-picking the above [two] [patches] to
mpv Debian package and applying for an unblock, as described in
the [freeze policy].

Thanks for your time and dedication!
Bye.


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

Kernel: Linux 6.1.0-6-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 mpv depends on:
ii  libarchive13 3.6.2-1
ii  libasound2   1.2.8-1+b1
ii  libass9  1:0.17.1-1
ii  libavcodec-extra59 [libavcodec59]7:5.1.2-3
ii  libavdevice597:5.1.2-3
ii  libavfilter8 7:5.1.2-3
ii  libavformat-extra59 [libavformat59]  7:5.1.2-3
ii  libavutil57  7:5.1.2-3
ii  libbluray2   1:1.3.4-1
ii  libc62.36-8
ii  libcaca0 0.99.beta20-3
ii  libcdio-cdda210.2+2.0.1-1
ii  libcdio-paranoia210.2+2.0.1-1
ii  libcdio192.1.0-4
ii  libdrm2  2.4.114-1+b1
ii  libdvdnav4   6.1.1-1
ii  libegl1  1.6.0-1
ii  libgbm1  22.3.6-1+deb12u1
ii  libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-2
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  liblua5.2-0  5.2.4-3
ii  libmujs2 1.3.2-1
ii  libpipewire-0.3-00.3.65-3
ii  libplacebo2084.208.0-3
ii  libpulse016.1+dfsg1-2+b1
ii  librubberband2   3.1.2+dfsg0-1
ii  libsdl2-2.0-02.26.4+dfsg-1
ii  libsixel11.10.3-3
ii  libswresample4   7:5.1.2-3
ii  libswscale6  7:5.1.2-3
ii  libuchardet0 0.0.7-1
ii  libva-drm2   2.17.0-1
ii  libva-wayland2   2.17.0-1
ii  libva-x11-2  2.17.0-1
ii  libva2   2.17.0-1
ii  libvdpau11.5-2
ii  libvulkan1   1.3.239.0-1
ii  libwayland-client0   1.21.0-1
ii  libwayland-cursor0   1.21.0-1
ii  libwayland-egl1  1.21.0-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxkbcommon01.5.0-1
ii  libxpresent1 1.0.0-2+b10
ii  libxrandr2   2:1.5.2-2+b1
ii  libxss1  1:1.2.3-1
ii  libxv1   2:1.0.11-1.1
ii  libzimg2 3.0.4+ds1-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages mpv recommends:
ii  xdg-utils  1.1.3-4.1
ii  yt-dlp 2023.03.04-1

Versions of packages mpv suggests:
pn  libcuda1  

-- no debconf information

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Francesco Poli (wintermute)]

Package: yt-dlp
Version: 2023.03.04-1
Severity: grave
Justification: renders package unusable

Hello and thanks for maintaining this useful package!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1, mpv
is no longer able to use yt-dlp to play YouTube videos:

  $ mpv https://www.youtube.com/watch?v=...
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=251=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=audio%2Fwebm=yes=2393695=146.021=1565382960171852=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIgK694JvtFcYR2CD8XvmJn6i09Q9lraFGyVhAMcpRX-UICIQCCGeSN6JZGoxj5dZMwNp-qBqRmJ11_PZLZI2eZCTLkhg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-2393695;'
 has unknown duration.
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=248=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=video%2Fwebm=yes=8861743=146.000=1565383003479714=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIhAKRzV0x6RiHkG_vxxixrOMea0A9COXLNQKnMXZMH-JjoAiBflw-hlwAKQUe_kv1e7oI91GhJbXwXdDtknxSqJXSdVg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-8861743;'
 has unknown duration.
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  No video or audio streams selected.
  
  Exiting... (Errors when loading file)

Instead, if I manually download the YouTube video:

  $ yt-dlp -o test https://www.youtube.com/watch?v=...
  [youtube] Extracting URL: https://www.youtube.com/watch?v=...
  [youtube] ...: Downloading webpage
  [youtube] ...: Downloading android player API JSON
  [info] ...: Downloading 1 format(s): 248+251
  [dashsegments] Total fragments: 1
  [download] Destination: test.f248.webm
  [download] 100% of8.45MiB in 00:00:00 at 8.71MiB/s
  [dashsegments] Total fragments: 1
  [download] Destination: test.f251.webm
  [download] 100% of2.28MiB in 00:00:00 at 6.66MiB/s
  [Merger] Merging formats into "test.webm"
  Deleting original file test.f251.webm (pass -k to keep)
  Deleting original file test.f248.webm (pass -k to keep)

I obtain a 'test.webm' file, that can later be played with mpv:

  $ mpv test.webm
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (2%) A-V:  0.000
  
  Exiting... (Quit)


If I downgrade yt-dlp to version 2023.02.17-1, everything works again:

  $ mpv https://www.youtube.com/watch?v=...
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (3%) A-V:  0.000 Cache: 141s/15MB
  
  Exiting... (Quit)


What's wrong?

Did yt-dlp change API? If this is the case, the new version of yt-dlp
Debian package should wait for an updated mpv Debian package, before
migrating to testing...

Or is it a bug in yt-dlp that shows up only when yt-dlp is called by mpv
behind the scenes, and not when it is directly invoked from the user's
command line?

Please fix this issue as soon as possible, or revert to the previous
version (yt-dlp/2023.02.17-1), until this behavior has been properly
investigated and solved.

Thanks for your time and patience!


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

Kernel: Linux 6.1.0-6-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 yt-dlp depends on:
ii  python33.11.2-1
ii  python3-brotli 1.0.9-2+b6
ii  python3-certifi2022.9.24-1
ii  python3-mutagen 

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

On Thu, 23 Mar 2023 16:31:50 +0100 Jochen Sprickerhof wrote:

> Hi,

Hello Jochen,
thanks for your comment.

> 
> I just had this error:
> 
> root@fenchel:~# aptitude -u
> Performing actions...
> E: undefined method `default' for "if /proxy_detect='(.*)'/ =~ 
> `apt-config \#{@apt_conf} shell proxy_detect 
> acquire::http::proxy-auto-detect`\n":String
> 
> $stdout.print " " * Unicode.width(@old)
>^^
> E: Unterprozess /usr/bin/apt-listbugs apt hat Fehlercode zurückgegeben (1)
> E: Failure running script /usr/bin/apt-listbugs apt
> Press Return to continue, 'q' followed by Return to quit.
> 
> Running apt again did not reproduce it.

The mystery deepens.

What you saw seems to be another case where some text from the source
(a line taken from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb, in
this instance) is treated as a String by the Ruby interpreter and its
`default' method is invoked. But the String class has no `default'
method, which causes the error.

This seems to happen sporadically and cannot be easily reproduced.

I cannot understand what's going on.
I am more and more persuaded that this bug report should be reassigned
to another package (probably package ruby), in order to ask for an
investigation by people more knowledgeable than me...


-- 
 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


pgpg2H1WjeZGv.pgp
Description: PGP signature

Bug#1030249: "prefclean output on ..." emails

[Francesco Poli]

On Wed, 22 Mar 2023 11:42:19 -0700 andy wrote:

> i have also started receiving email notifications from apt-listbugs and
> am +1'ing the suggestion for a knob to turn off all emails.

Hello,
thanks for your comments, I am taking notice.

> 
> in my case it seems related to an Acquire::http::Proxy setting.
>  * when waking from sleep in a location where the apt-proxy is
>reachable, about 1/2 the time (from a small sample size of 1 laptop
>over a few days) it apparently tries to run before the network is
>available and emails "E: getaddrinfo: Name or service not known
>[...]" (perhaps related to #964438).

Taking what you describe into account, it really seems that you are
experiencing bug #964438 .
Unfortunately, my attempt to report a wishlist bug against systemd was
not really successful...   :-(

>  * when in a location where the apt-proxy is not reachable, i receive
>emails every so often re: "E: Connection refused - Connection
>refused".  while a valid complaint this is a known issue that i
>don't need to hear about and would like to be able to turn off.

Why do you use a proxy for HTTP in apt?
Are you forced to use a proxy (because direct HTTP connections are
disabled in your network), or do you just prefer to use a proxy
(perhaps in order to benefit from caching and similar features)?

If direct HTTP are allowed on your network, you could consider
disabling the use of the proxy for apt-listbugs, by setting

  Acquire::http::Proxy::bugs.debian.org "DIRECT";

in /etc/apt/apt.conf.d/10apt-listbugs

This should make apt-listbugs bypass the proxy for its BTS queries.
Please see the apt-listbugs(1) man page.

> 
> i am uncertain why these emails seems to have just started in the past
> few days. afaik the only possibly relevant change i made was to update
> Acquire::http::Proxy to a fqdn. please let me know if you would prefer
> a new bug report as this may be only tangentially related to this
> particular bug (while solution of an "off switch" is the same).

No need for a separate bug report, at least for the time being.

> 
> thanks in advance.

You are welcome!


-- 
 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


pgp36Ee49Biit.pgp
Description: PGP signature

Bug#1026961: openconnect: fails to restore previous network configuration

[Francesco Poli]

On Sat, 25 Feb 2023 18:48:30 + Luca Boccassi wrote:

[...]
> On Sat, 24 Dec 2022 19:36:39 +0100 "Francesco Poli (wintermute)"
>  wrote:
[...]
> > At the end of the session, I expected openconnect to automatically
> > restore the network configuration as it had found it at the beginning
> > of the session.
[...]
> > Please fix this issue and/or forward this bug report upstream, as
> > appropriate.
> 
> Please report this upstream

Dear Luca,
I tried, but it seems that I would need to create a gitlab.com account
just to report this bug.

You probably already have an account there: could you please be so kind
and forward my bug report upstream, instead of closing it?

Doing so would have a number of advantages: you could tag this bug
report as forwarded and it would keep track of the upstream bug status;
moreover, keeping my Debian bug report open (until a fix has landed in
Debian) would inform other Debian users that the bug is already known,
thus avoiding that other Debian bug reports are filed in the future
about the same issue...

I hope you agree with my reasoning.

Bye and 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


pgpECDww1b7fg.pgp
Description: PGP signature

Bug#982099: lxpanel: randomly fails to display one of the configured launchers

[Francesco Poli]

On Sun, 9 May 2021 12:04:38 +0200 Francesco Poli wrote:

[...]
> Hello again,
> any news on bug [#982099]?
> 
> [#982099]: <https://bugs.debian.org/982099>
[...]

For anyone else who is experiencing this same bug, I seem to have found
a workaround: the trick is to create one separate Application Launch
Bar for each application launcher you need to define.

After applying this trick, each configured launcher seems to be always
displayed, without any issues...

The resulting panel configuration is something like:

  $ cat ~/.config/lxpanel/default/panels/panel 
  # lxpanel  config file. Manually editing is not recommended.
  # Use preference dialog in lxpanel to adjust config when you can.
  
  Global {
edge=bottom
allign=left
margin=275
widthtype=percent
width=100
height=28
transparent=1
tintcolor=#dcdad5
alpha=255
setdocktype=1
setpartialstrut=1
usefontcolor=1
fontcolor=#10394d
usefontsize=0
fontsize=10
background=0
backgroundfile=/usr/share/lxpanel/images/background.png
align=right
  }
  Plugin {
type=launchbar
Config {
  Button {
id=uxterm-start-login.desktop
  }
}
  }
  Plugin {
type=launchbar
Config {
  Button {
id=xscreensaver-lock-screen.desktop
  }
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=pager
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=taskbar
Config {
  ShowAllDesks=0
  MaxTaskWidth=150
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=tray
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=dclock
Config {
  ClockFmt=%R
  TooltipFmt=%a, %d %b %Y
  BoldFont=1
  IconOnly=0
  CenterText=1
}
  }
  Plugin {
type=space
Config {
  Size=5
}
  }


-- 
 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


pgpVjUI2yMSOZ.pgp
Description: PGP signature

Bug#1030249: unexpected "prefclean output on ..." emails since bookworm upgrade

[Francesco Poli]

On Thu, 02 Feb 2023 20:57:16 -0500 Antoine Beaupré wrote:

> On 2023-02-01 23:35:09, Francesco Poli wrote:
> > On Wed, 01 Feb 2023 10:25:21 -0500 Antoine Beaupre wrote:
> 
> [...]
> 
> > I must admit that I am somewhat surprised that you see all these mail
> > notifications about fixed packages as something new.
> > apt-listbugs has notified root by (local) mail about fixed packages for
> > ages. Through the cron job mechanism and, starting from 2019, through
> > the manually-implemented mailing in the systemd timer.
> >
> > So, I wonder what has changed in your box, when you began to see these
> > mail notifications...
> 
> I am not sure. I recently deployed unattended-upgrades on all my
> machines, and recently upgraded them to bookworm, which might have
> triggered more of those warnings. 2019 is not that long ago though, was
> this part of bullseye?

Yes, the mail notifications have been present for ages.
Before 2019, just because cron/anacron sends the output by (local) mail
by default. Starting from 2019, also because they are manually
implemented in the systemd timer (for systemd-running boxes).
This implementation was done in 2019 and was part of bullseye (which
was released in 2021).

However, what you say made me think about a couple of things.
Under unattended-upgrades, apt-listbugs automatically pins all buggy
packages, see the corresponding [FAQ]
in /usr/share/doc/apt-listbugs/FAQ.md.gz .

[FAQ]: 
<https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/FAQ.md#how-can-i-use-apt-listbugs-in-unattended-installationsupgrades>

But, unfortunately, this automatic pinning was broken in bullseye, due
to a bug introduced by me in 2020 and then fixed in 2022 (see bug
[#1021289]).

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

In bookworm, this bug is fixed and the automatic pinning should work
correctly.

This should explain why you suddenly began to see the notifications
under unattended-upgrades, after migrating to bookworm.

[...]
> > In the meanwhile, you could try the attached patch as temporary
> > workaround for your specific case (the "I do not want any mail
> > notifications" case).
> > Please let me know whether it works as intended.
> 
> Ah well, I thought I could write something like this on my own of
> course, but I didn't want to diverge from upstream and forget I had that
> patch lying around. I suspect it might just work, indeed, as the caller
> checks to see if there's any output beforing firing off that email...
> 
> Thanks for the patch!

You are welcome.


-- 
 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


pgpPgIPYGCRiD.pgp
Description: PGP signature

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Francesco Poli]

On Tue, 31 Jan 2023 21:41:04 +0100 Lucas Nussbaum wrote:

> I updated lintian on the worker. The results will get updated over the
> next few days (probably 3 to 5 days).

Thanks a lot!   :-)

[...]
> I'll check again in a few days and close when the data is migrated.

Sounds good.
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


pgptDEl_TuB7Y.pgp
Description: PGP signature

Bug#1030249: unexpected "prefclean output on ..." emails since bookworm upgrade

[Francesco Poli]

Control: severity -1 wishlist


On Wed, 01 Feb 2023 10:25:21 -0500 Antoine Beaupre wrote:

> Package: apt-listbugs
> Version: 0.1.40
> Severity: minor

Hello Antoine!
Thanks for your bug report.   :-)

> 
> Since I'm running bookworm, apt-listbugs started pestering me with
> emails that look like this:
> 
> Date: Wed, 01 Feb 2023 07:25:20 -0500
> From: apt-listbugs timer 
> To: r...@anarc.at
> Subject: prefclean output on curie
> 
> /usr/libexec/apt-listbugs/prefclean:
>  Paquets corrigés : breeze kactivitymanagerd ksshaskpass kwayland-integration 
> polkit-kde-agent-1
> 
> That "Paquets corrigés" string there means "Fixed packages" in
> english.

Yes, it's in the French translation catalog of messages.

> I've traced it down to /usr/libexec/apt-listbugs/aptcleanup,
> itself called from /usr/libexec/apt-listbugs/prefclean which
> specifically makes a point of explicitely writing an email if you're
> running under systemd.

It does so, in order to provide an equivalent functionality with
respect to the cron.daily job, which runs if you are _not_ running
under systemd.
By default, cron jobs have their output sent by (local) mail, if any
output is produced.
When I implemented the equivalent systemd timer, I had to manually
implement the output-mailing feature...

I must admit that I am somewhat surprised that you see all these mail
notifications about fixed packages as something new.
apt-listbugs has notified root by (local) mail about fixed packages for
ages. Through the cron job mechanism and, starting from 2019, through
the manually-implemented mailing in the systemd timer.

So, I wonder what has changed in your box, when you began to see these
mail notifications...

> 
> I'd love a way to turn that stuff off or, preferably, have it logged
> normally in syslog/journald. I don't need to be told when those things
> are fixed: I'm assuming apt-listbugs will do its job correctly unless
> otherwise noted. In other words, this is not a failure condition, it's
> actually a *success* condition, and I don't really need to be told
> about those.

Well, it's the first time that someone complains about these mail
notifications.

Personally, I like to be informed, when a bug that I feared has been
fixed, and the fixed package can finally be upgraded on my box.

Anyway, that's a matter of preference, I must admit.
Hence, it may make sense to implement an option to silence those
notifications...

> 
> Could we make this a knob at least? It looks like aptcleanup looks at
> the apt preferences to that might be a good place, but prefclean is
> where the decision is actually mean on how to treat the aptclean
> output, so I'm not sure how best this could be done...

I think that the best place where I can implement the option is
probably an APT preference to be read (via 'apt-config') by aptcleanup,
which would suppress its " Fixed packages:" output.

But I am afraid that this is not the right time to implement that for
bookworm.
I won't introduce such a change during the freeze.
I will probably do so for trixie, after bookworm is released.

In the meanwhile, you could try the attached patch as temporary
workaround for your specific case (the "I do not want any mail
notifications" case).
Please let me know whether it works as intended.

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


bug1030249_tempworkaround.diff.xz
Description: application/xz


pgpcMgs0FKmxm.pgp
Description: PGP signature

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Francesco Poli]

On Mon, 30 Jan 2023 21:14:53 +0100 Lucas Nussbaum wrote:

> Hi Francesco,

Hi Lucas!   :-)

> 
> On 30/01/23 at 20:45 +0100, Francesco Poli (wintermute) wrote:
[...]
> > Why is UDD outdated w.r.t. the lintian version?
> > Shouldn't UDD be aware of the version currently in testing, or maybe
> > even in unstable?
[...]
> 
> The update to a newer lintian version on the UDD lintian worker is a
> manual process.

Ah, I wasn't aware of that.

> I'll do that soon, but I have some other Debian stuff
> queued up that looks more important.
> Any reason in particular you need the latest version?

Well, one reason is that lintian/2.115.3 is incorrectly complaining
about [many packages], stating that they declare compatibility with a
non-existing Debian Policy version.
This obviously happens, because a new Policy version (4.6.2) has been
released after lintian/2.115.3, and all the updated packages are seen
by lintian/2.115.3 as wrong...

[many packages]: 
<https://udd.debian.org/lintian-tag.cgi?tag=newer-standards-version>


-- 
 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


pgpHhkZgebtFh.pgp
Description: PGP signature

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Francesco Poli (wintermute)]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

In the [UDD Lintian report] for my package, I read:

[...]
| The most recent lintian version known by UDD is 2.115.3
[...]

[UDD Lintian report]: 

However, there are more recent versions of lintian in both unstable
and testing:

  $ rmadison lintian | grep 'unstable\|testing'
  lintian| 2.116.1 | testing| source, all
  lintian| 2.116.2 | buildd-unstable| source, all
  lintian| 2.116.2 | unstable   | source, all

Why is UDD outdated w.r.t. the lintian version?
Shouldn't UDD be aware of the version currently in testing, or maybe
even in unstable?

What's missing?
Did I fail to understand anything?

Please make UDD use the latest lintian version from testing or
unstable, or otherwise clarify my misunderstanding.

Thanks for your time and dedication!
Bye.

Bug#1025375: hydrogen-doc: documentation binary package is almost empty, should it be dropped entirely?

[Francesco Poli]

On Mon, 23 Jan 2023 20:56:49 -0500 Nicholas D Steeves wrote:

> Control: forwarded -1 
> https://github.com/hydrogen-music/documentation/issues/73
> 
> Dear Francesco,
> 
> I've enjoyed reading and learning from your analyses on debian-legal,
> and I'm happy it was you who noticed this issue and filed this bug!

Wow, thanks for the kind words!   :-)

> [edit: sorry for the delay, it seems I forgot to send this draft 22 Dec
> 2022]

Oh well...

> 
> There is hope, and GPL2+ licensed docs are pending, but upstream may not
> be able to meet our deadlines.  I suspect a statement of yours upstream
> may expedite the process ;) tldr: It looks to me like the remaining two
> old contributors contributed documentation under GPL2+ and that there
> isn't any need to rubber-stamp the new documentation subproject, because
> their contributions remain inherently GPL2+ licensed, because that
> license could not have been legally stripped by moving their work from
> the GPL2+ Hydrogen project to the accidentally license-less period of the
> Hydrogen/Documentation subproject.

OK, let me understand. If I read the Github issue correctly, the SVN
repository was split into two separate Git ones (one for the program
and one for the documentation), but the license was not copied to the
documentation Git repository by mistake.

Hence, all the documentation contributions that were made before the
repository split are under the license of the program (GPL-2+).
All the documentation contributions made after the split are in a legal
limbo. But almost all the corresponding contributors sent their consent
to license their contributions under GPL-2+, except for two of them,
who have not yet showed up...

This two MIA contributors are @jeremyz (former member of the
development team, active before and after the split and still
occasionally online) and @thijz (former member of the development team,
active only after the split, but currently vanished).

Is this a reasonably accurate summary?

Assuming it is, I think the only problem left is due to these two
contributors. Ideally they could be tracked down and asked for their
consent to the explicit licensing of the documentation.

If this cannot be done, what is the extent of their (post-split)
contributions to the documentation?
I mean: can the documentation do without their (post-split)
contributions? Some of their contributions could have already been
replaced by material written by others. Those contributions that are
still present in the current documentation could be dropped entirely
and replaced by something else.
Would it be too hard? 

[...]
> I'd be totally OK with you (or someone else) taking up the baton for
> these two interrelated bugs. (1025375 and 1020936)

I am really sorry, but I lack the spare time to take care of
this...  :-(



-- 
 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


pgpHtcQR6vF04.pgp
Description: PGP signature

Bug#1029570: sc-im: debian/copyright file seems to be inaccurate

[Francesco Poli (wintermute)]

Package: sc-im
Version: 0.8.3+ds-1
Severity: serious
Justification: Policy 4.5

Hello!
Thanks for packaging this interesting program.

I noticed that the [debian/copyright] file seems to be inaccurate
with respect to the [upstream license].

The [debian/copyright] file states:

  [...]
  Files: *
  Copyright: 2013-2021, Andrés Martinelli 
  License: BSD-4-Clause
  [...]

which looks accurate, but then the documented license text
is not a verbatim copy of the [upstream license].

Most notably, clause 3 (out of 4) is missing.
Other minor differences are present.

Please fix the debian/copyright file by including the
correct verbatim copy of the upstream license text.

[debian/copyright]: 

[upstream license]: 


Please note that clause 3 is the infamous "obnoxious advertising
clause" [OAC], which, unfortunately, makes the 4-clause BSD license
GPL-incompatible.

[OAC]: 

As a consequence, I would also recommend to not license
debian/* files under GPL-2+, since having two incompatible
licenses in the same package is risky (it could lead to
a legally undistributable package, unless much care is
taken to never mix the two parts up...).
Maybe debian/* files could be relicensed under the terms
of some non-copyleft permissive license (such as
the Expat license or maybe the 3-clause BSD license...),
if the copyright holder (Joshua Peisach) agrees.


In the meanwhile, it would be really nice, if upstream could
be persuaded to drop the [OAC], thus relicensing the program
under the terms of the 3-clause BSD license.
Why? Because the 4-clause BSD license is a deprecated license,
which causes many GPL-compatibility troubles in the rare cases
where it is still used.
Since the upstream program copyright is currently held by one
sole person, it is still pretty easy to switch to a better
license: only one guy to be persuaded!   :-)

Please try and get in touch with upstream about this.

Thanks for your time and dedication!
Bye.

Bug#1028962: isc-dhcp-client: -x option no longer works (looks like apparmor configuration prevents it from having any effect)

[Francesco Poli]

Control: tags -1 + unreproducible


On Mon, 16 Jan 2023 14:28:05 +0100 Santiago Ruano Rincón wrote:

[...]
> I am not able to reproduce this with my current setup.

Nor am I! :-o

> I can successfully run dhclient -x and it stops the related process.

I tried again today and now I can also use the "-x" option and the
"ifdown" command, as well, without any unexpected behavior.

That's really awkward.
What's different in my box, with respect to yesterday?!?

There have been other package upgrades, of course, but no one looks
related to AppArmor or to isc-dhcp-client.

There has been a poweroff and a boot (well, actually, two of them, if I
recall correctly), but we are talking about Debian GNU/Linux here, not
about That Other Operating System™ that needs to be rebooted for each
and every little trifle!;-)
Hence I would be a little surprised, if it turned out that the reboot
helped...

What else could have changed the result?

> 
> Anyway, could you please test the attached patch?

Thanks for preparing the patch, but I am not going to test it for the
time being, since I am currently unable to reproduce the bug...

[...]
> > Moreover, even the first strategy (ifdown/ifup) now seems to fail to
> > work perfectly. After issueing the following command:
> > 
> >   # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE
> ...
> 
> Do you see the same apparmor DENIED messages?

Yes, I saw the same AppArmor error message in /var/log/kern.log, when I
tried ifdown yesterday.

Somehow everything seems to work flawlessly today.

Hence, I am tagging this bug report as 'unreproducible' and leaving the
'moreinfo' tag.
If I don't come back with additional information for some time, please
feel free to close the bug report.

And many thanks for your prompt and kind reply!
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


pgpOiLCsblQOQ.pgp
Description: PGP signature

Bug#1028962: isc-dhcp-client: -x option no longer works (looks like apparmor configuration prevents it from having any effect)

[Francesco Poli (wintermute)]

Package: isc-dhcp-client
Version: 4.4.3-P1-1.1
Severity: important

Hello and thanks for maintaining ISC DHCP in Debian!

After upgrading packages ('isc-dhcp-client' itself or other libraries),
it may happen that

  # checkrestart

(from the 'debian-goodies' package) tells me that an instance of dhclient
should be restarted.

One option is bringing down the corresponding network interface and then
bringing it up again:

  # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE

This works (well, used to work, see below...), but has some drawbacks:
it leaves the box briefly without network, if all goes well; if something
goes wrong, it leaves the box without network, until something else is
done to fix the issue (and it could be troublesome, if you are
administering the box through an SSH session from a distant remote host...);
it may cut existing network connections down; and so forth...

A long time ago, I found what seems to be a better strategy.
First of all, figure out the exact command line for dhclient:

  # ps aux | grep dhclien[t]
  root 738  0.0  0.0   5868  3604 ?Ss   09:37   0:00 
/sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s25.pid -lf 
/var/lib/dhcp/dhclient.enp0s25.leases -I -df 
/var/lib/dhcp/dhclient6.enp0s25.leases enp0s25

Then, stop dhclient without releasing the current lease (as documented in
the dhclient(8) man page):

  # /sbin/dhclient -x -pf /run/dhclient.enp0s25.pid

Finally start dhclient again with the previously found command line:

  # /sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s25.pid -lf 
/var/lib/dhcp/dhclient.enp0s25.leases -I -df 
/var/lib/dhcp/dhclient6.enp0s25.leases enp0s25

This used to work without any network down-time, looked more failsafe and
even quicker.


Unfortunately, this second strategy no longer seems to work.
When I issue the dhclient command with the "-x" option, nothing happens
and dhclient goes on running.

I noticed the following line in /var/log/kern.log :

  2023-01-15T11:29:18.045334+01:00 $HOSTNAME kernel: [ 6692.708089] audit: 
type=1400 audit(1673778558.040:25): apparmor="DENIED" operation="signal" 
profile="/{,usr/}sbin/dhclient" pid=7192 comm="dhclient" requested_mask="send" 
denied_mask="send" signal=term peer="unconfined"

It seems to me that the AppArmor configuration in /etc/apparmor.d/sbin.dhclient
is preventing the "-x" option from having any useful effect.

I am not familiar with AppArmor, but I think that this operation should
be somehow possible, otherwise the AppArmor configuration makes the "-x"
option (almost) completely useless.

Moreover, even the first strategy (ifdown/ifup) now seems to fail to
work perfectly. After issueing the following command:

  # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE

I see that two dhclient istances are running (the previously existing
one, and a new one). And I see the same error in /var/log/kern.log .
Hence, I have to manually kill the previous instance:

  # kill -TERM $OLD_DHCLIENT_PID


All this seems to be extremely annoying and inconvenient.

Please note that I set severity "important" for this bug report,
but one could even claim that this is "grave". Especially taking
into account that ifdown does not stop the running DHCP client...


Please fix the AppArmor configuration or suggest an alternative strategy
to stop the DHCP client without releasing the current lease.
And anyway, please fix the package, so that ifdown works correctly!

Bye and thanks for your time and dedication!




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

Kernel: Linux 6.0.0-6-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 isc-dhcp-client depends on:
ii  debianutils  5.7-0.4
ii  iproute2 6.1.0-1
ii  libc62.36-8

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.3-P1-1.1

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#1027441: cups-client: prints on one side, even when the default is two-sided-long-edge or an explicit option is passed to lpr

[Francesco Poli (wintermute)]

Package: cups-client
Version: 2.4.2-1+b2
Severity: important

Hello Debian Printing Team (and Season's Greetings!).

I am experiencing a bug with CUPS: at some point in time in the past
(unfortunately I do not remember exactly with which version, sorry,
I do not print stuff on a daily basis...) CUPS began ignoring the
sides= option value and began printing on one side only.

I remember seeing this issue on other Debian testing boxes with
other printers, but let's focus on the box I am writing this bug
report from.
The printer is an HP LaserJet 1320 printer connected via USB cable,
but I don't think the make and model makes too much of a difference...

The following options are set as default:

  $ lpoptions -p lj
  copies=1 device-uri=usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9 
finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 
job-sheets=none,none marker-change-time=0 media=A4 number-up=1 
pdftops-renderer=pdftops pdftops-renderer-default=pdftops 
print-color-mode=monochrome 
printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='HP 
LaserJet 1320' printer-is-accepting-jobs=true printer-is-shared=true 
printer-is-temporary=false printer-location=local printer-make-and-model='HP 
LaserJet 1320 Foomatic/pxlmono (recommended)' printer-state=3 
printer-state-change-time=1569079565 printer-state-reasons=none 
printer-type=8564756 printer-uri-supported=ipp://localhost:631/printers/lj 
sides=two-sided-long-edge

Please note that the default is 'sides=two-sided-long-edge'.
However, if I print any multi-page document:

  $ lpr -P lj foo.pdf

I obtain one document page per sheet of paper, that is to say, a one-sided
print, which is almost always *not* what I want (in order to reduce the
waste of paper, the environmental impact, and so forth...).

Even passing explicit options changes nothing:

  $ lpr -P lj -o sides=two-sided-long-edge foo.pdf
  $ lpr -P lj -o fit-to-page -o sides=two-sided-long-edge foo.pdf

It seems that the sides= option is completely ignored.

I have browsed the Debian BTS and found other bug reports that seem
to be related.
Bug [#994395] is similar, but the bug report submitter sees a
'sides=one-sided' default with lpoptions, which is different from
the behavior I am experiencing.
Bug [#1008175] looks much more similar, but was closed as due to
a printer firmware bug. This sounds very awkward to me, but anyway,
in the case of my printer, I am sure I haven't updated its firmware
for ages (and it's not connected to the network, so it cannot even
have auto-updated its own firmware without asking me). This means
that, if the firmware is buggy, it has been buggy for a long time,
and it was buggy even when CUPS was perfectly able to print two-sided.
In other words, if a buggy firmware is to be blamed, CUPS used to
be able to work around this firmware bug and is now no longer able
to do so. So, in any case, there's something that needs to be fixed
in CUPS...

[#994395]: 
[#1008175]: 

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

Thanks for your time and patience!



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: i386 (i586)

Kernel: Linux 6.0.0-6-686 (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 cups-client depends on:
ii  adduser  3.129
ii  cups-common  2.4.2-1
ii  libc62.36-7
ii  libcups2 2.4.2-1+b2

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.4.2-1+b2
ii  cups-bsd   2.4.2-1+b2
pn  smbclient  

-- no debconf information

Bug#1027002: vim-runtime: please add syntax highlighting and indentation support for the Nim language

[Francesco Poli]

On Fri, 30 Dec 2022 19:26:39 -0500 James McCoy wrote:

> On Fri, Dec 30, 2022 at 12:26:06PM +0100, Francesco Poli wrote:
[...]
> > Maybe nim.vim could be packaged as a Vim addon, as documented in the
> > Debian Packaging [Policy for Vim]. Is this possible?
> > 
> > [Policy for Vim]: <https://vim-team.pages.debian.net/vim/>
> 
> Yes, if someone wanted to create a new package for the files in that
> repo, they could do that and package it as an addon.

OK, thanks for confirming.
I have just filed a RFP bug [#1027431] for nim.vim...

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

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


pgpFOGFMtXcSY.pgp
Description: PGP signature

Bug#1027431: RFP: vim-nim -- Nim language support for Vim

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-nim
  Version : 1.1.2+git2021.a15714f (or persuade upstream to
   tag releases more often...)
  Upstream Contact: Zahary Karadjov 
* URL : https://github.com/zah/nim.vim
* License : Expat (MIT)
  Programming Lang: Vim (+ Python)
  Description : Nim language support for Vim

nim.vim provides:
 * Syntax highlighting
 * Auto-indent
 * Build/jump to errors within Vim
 * Project navigation and Jump to Definition (cgats or
   compiler-assisted idetools)
for the Nim programming language.



I think this package may be useful, since there is currently
no Vim support for the Nim language in Debian, see bug [#1027002],
not even for syntax highlighting.

[#1027002]: 

I hope someone is willing to package this addon soon.
Thanks to anyone volunteering to do so and maintain it in Debian!

Bug#1027002: vim-runtime: please add syntax highlighting and indentation support for the Nim language

[Francesco Poli]

On Wed, 28 Dec 2022 11:41:12 -0500 James McCoy wrote:

> Control: tag -1 + upstream
> 
> On Sun, Dec 25, 2022 at 11:37:23PM +0100, Francesco Poli (wintermute) wrote:
> > Hello!
> > Do I understand correctly that there's no syntax highlighting or indentation
> > support for the [Nim] programming language in package vim-runtime?
> 
> The filetype itself is detected, but no one has added the other support.
> 
> > I think it would be a useful addition, perhaps taken from [nim.vim]...
> > 
> > [nim.vim]: <https://github.com/zah/nim.vim>
> 
> Then zah needs to be convinced to send the files upstream to vim, since
> they will be the one that needs to respond to bugs or feature requests,
> as well as sending updates to Bram.

Yeah, it makes sense.

> 
> That's not something that I would add specifically to the Debian
> packaging.

That's understandable.
Is there an alternative strategy to have that support in Debian?

Maybe [nim.vim] could be packaged as a Vim addon, as documented in the
Debian Packaging [Policy for Vim]. Is this possible?

[Policy for Vim]: <https://vim-team.pages.debian.net/vim/>


-- 
 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


pgpwBdEvsIyqv.pgp
Description: PGP signature

Bug#1017064: lintian: incorrectly complains about adopted-extended-field XB-Ruby-Versions

[Francesco Poli]

On Sun, 9 Oct 2022 19:29:30 +0200 Francesco Poli wrote:

[...]
> This bug is still present in the lintian version currently in sid.
> Please fix it.

Hello again,
XS-Ruby-Versions and XB-Ruby-Versions are now deprecated, see the
changelog entry for package [gem2deb/2.1].

[gem2deb/2.1]: 
<https://tracker.debian.org/news/1392420/accepted-gem2deb-21-source-into-unstable/>

As a consequence, I think that lintian should no longer point out that
either of those two fields is adopted (which is not the case), but, if
anything, it should point out that those two fields are deprecated and
need to be dropped...

Do you agree? Please let me know.

Thanks for your time and patience.
Bye (and Season's Greetings!).


-- 
 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


pgpWjtOo7t7Ge.pgp
Description: PGP signature

Bug#1027002: vim-runtime: please add syntax highlighting and indentation support for the Nim language

[Francesco Poli (wintermute)]

Package: vim-runtime
Version: 2:9.0.0813-1
Severity: wishlist

Hello!
Do I understand correctly that there's no syntax highlighting or indentation
support for the [Nim] programming language in package vim-runtime?

[Nim]: 

I think it would be a useful addition, perhaps taken from [nim.vim]...

[nim.vim]: 

Please add the relevant files to package vim-runtime and/or forward
my wishlist bug report upstream, as appropriate.

Thanks for your time, bye (and Season's Greetings!).


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

Kernel: Linux 6.0.0-6-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.0.0813-1+b1
ii  vim-gtk3 [vim]  2:9.0.0813-1+b1
ii  vim-tiny2:9.0.0813-1+b1

vim-runtime suggests no packages.

-- no debconf information