Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Sat, 27 Jul 2024 17:54:34 +0200 Francesco Poli wrote:

[...]
> I reiterate the request to people from the Debian Kernel Team: could
> someone please step in, test the three files, and share his/her insight
[...]
> ?

Dear Debian Kernel Team,
this bug needs love, could some of you please spend a little time to
address it?

I provided [three files] that work for me™, I would be happy to see them
integrated into the linux-cpupower binary package (they are released
under the terms of the GNU GPL license v2 or later), so that other
users may benefit from them, without having to manually copy them.

[three files]: <https://bugs.debian.org/894906#17>

Could you please test them, possibly share your thoughts and/or propose
enhancements, and then include them into the Debian package?

Or otherwise, if you think there's something wrong with them, could you
please explain what is wrong? Maybe there's a way to fix them...

I really hope this bug can soon be solved once and for all.
Thanks for your understanding!


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


pgpAZ4gmcaQXu.pgp
Description: PGP signature

Bug#1057695: debian-goodies: checkrestart gives SyntaxWarning messages with python3.12

[Francesco Poli]

Control: tags -1 + patch


N.B.: Sorry, my previous message did not come out well (I am not sure
  why), let's try again...


On Tue, 2 Jul 2024 10:24:17 +0200 Vincent Lefevre  wrote:

> On 2023-12-07 09:19:06 +0100, richardn wrote:
> > python3.12 starts giving SyntaxWarning messages for invalid escape
> > sequences in the checkrestart python script. With python3.11 these
> > were only DeprecationWarning messages, not shown by default.
> 
> Any news?
> 
> Now that python3.12 is the default, this bug becomes much more visible.

Hello debian-goodies package maintainer(s),
I am another user who would love to see this bug fixed.

I therefore prepared a patch for checkrestart.

The patch just applies the conversion to raw strings suggested in the
second bullet of the [Other Language Changes] section of the What's New
In Python 3.12 document.

And it only applies this conversion to the regular expressions that
triggered SyntaxWarnings.

[Other Language Changes]: 
<https://docs.python.org/3/whatsnew/3.12.html#other-language-changes>

I think the patch is so trivial that it is not even copyrighted.
Should this turn out to be not true, I hereby release the patch under
the same terms as checkrestart (that is to say: GNU GPL v2 or later).

The patch is attached, please apply it to checkrestart.

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


checkrestart_syntaxwarning.diff.gz
Description: application/gzip


pgpki8Ir27vC3.pgp
Description: PGP signature

Bug#1057695: debian-goodies: checkrestart gives SyntaxWarning

[Francesco Poli]

 messages with python3.12
Message-Id: <20240831124813.bacaee7377634378d1dd4...@paranoici.org>
In-Reply-To: <20240702082417.ga113...@qaa.vinc17.org>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart=_Sat__31_Aug_2024_12_48_13_+0200_1T24GTk9XT+3TsF6"


--Multipart=_Sat__31_Aug_2024_12_48_13_+0200_1T24GTk9XT+3TsF6
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Control: tags -1 + patch


On Tue, 2 Jul 2024 10:24:17 +0200 Vincent Lefevre 
wrote:

> On 2023-12-07 09:19:06 +0100, richardn wrote:
> > python3.12 starts giving SyntaxWarning messages for invalid escape
> > sequences in the checkrestart python script. With python3.11 these
> > were only DeprecationWarning messages, not shown by default.
>=20
> Any news?
>=20
> Now that python3.12 is the default, this bug becomes much more visible.

Hello debian-goodies package maintainer(s),
I am another user who would love to see this bug fixed.

I therefore prepared a patch for checkrestart.

The patch just applies the conversion to raw strings suggested in the
second bullet of the [Other Language Changes] section of the What=E2=80=99s=
 New
In Python 3.12 document.
And it only applies this conversion to the regular expressions that
triggered SyntaxWarnings.

[Other Language Changes]: <https://docs.python.org/3/whatsnew/3.12.html#oth=
er-language-changes>

I think the patch is so trivial that it is not even copyrighted.
Should this turn out to be not true, I hereby release the patch under
the same terms as checkrestart (that is to say: GNU GPL v2 or later).

The patch is attached, please apply it to checkrestart.

Thanks a lot for your time and dedication!


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

--Multipart=_Sat__31_Aug_2024_12_48_13_+0200_1T24GTk9XT+3TsF6
Content-Type: application/gzip;
 name="checkrestart_syntaxwarning.diff.gz"
Content-Disposition: attachment;
 filename="checkrestart_syntaxwarning.diff.gz"
Content-Transfer-Encoding: base64

H4sICGPx0mYAA2NoZWNrcmVzdGFydF9zeW50YXh3YXJuaW5nLmRpZmYArVdtb9s2EP4c/4qD00FS
ZSu281Z7yJCt6boBQzGgK/YhTgtapBwusqSRVNNg3X/fHSnFkqy8bJhQlBF1dzzePc/dmcskgbEq
3wE7iK9FfKOENkwZWLVeB+PxuCOxN5vMZuPJfDydwGS6mOK/o2hSPxBOZpPJIAzDjiVSOxpPXo0P
pzCdLaani+lx9Ork+HQ+OZrNK7XzcxjPpvPRKYRuOT8fQPORCWS5AW/hgcwglZlYtAXoifPMyKwU
AxiMm/sbOAMlog0z8bXvfeTys1Ba5hms7sBfvg8D8BOVb76aPFiAH70MXngje0YwCB+0o/6doe5t
Nj3+03a0VnlZ+LMAzs7AI2tejyQ99nQjODpVax0GNpKH82OKpFsokrsG9uF7zkEaMDmYa4FOagN5
AlykgmwmMhWaHKKPhRKfZV5q/KpjJQuTqz6Lt0zDxZtfIFeQarS1YepG0xlM13bbeanujCGN802B
J/pD1B8GkRZMYYhTpk1A5poSS7+ytQy2kpwZ1iNZMHONeMm5OLucjOdX4TJ40VFatFP8X1xSz/dJ
Pdep3owXKo+F1pFNTsSKQmTcKbTlRar76LEPvwtEjY6Z4g/lVQPLOHCVF5g4C6aj2eloimiq1i4x
E7xgwomUuY4IRVwq3zsgVw88CKGQHP/3DhLu9V0LY416FJJIamTKTb+ufU34Q4FJMrYRyAM0pQTj
T9vZxWFP4pe6kddGiuxpfcDZtaGeNNJ7HxfYMuOtTDuVrYb4EovCdEw0auD93j68FaZF843Y5OoO
GYqWa7KXWmZr0HfaiA0U+GnQ8EVBXpqiNJRoW90/uXf/0iNRLHMY5Ksg4iJGYPtCKcTS2VCus1wJ
unWRSkOVUPt46Vb0CcCusFoh31vqEO05+5E2CEzcy7xgBIedgtxVVY/rdhOViqxiKdbao55cJGic
BC4Pr56sXA8m+ukS8whKHkT8LjqCZsqr223FAvgOpgvH6JPpaHqIjHZrk9GFkpnxh5cXb3748PYK
XlOmCRVojqzANxpWIs2ztabGwbI7KFh8w9ZiCN9AUkV4H36UCnFmcVL3EKsuviD+9KD2kDp6zX73
yV543LiED0lkxwh9Kw0274NUrg48W1Y7H0qt6o+BLWKt5EQ6v1zy6CrE4Dby8b+doLpH3IcUo0EN
Ua4UUxJpZq6ZAZ7by9tLU3gyMEhHDGmpBTA0vC5TpvA7lmhtJwzygSSbhnVOFaG583O2PWmEXOUi
ozwwxWKDo4o7PM7LlFd5tGnsOy+hFLZBnziqbYMaElDLlf1rROl/VLwZH6eGO9HLZ2guo/uDIice
PiKuto6pe88eV3jUtSfOirZnVc61iYpinzC+GFpU/U2VjXx1+vQ+XDhYxCxNgRc36/GfpUBcNCmk
5aZI7xBACKUthLAqbyVsBbdMP55PaRB0S83zfViVMuUVFixHLbgsDMhNhAS2lrTkAnK0qraETSKs
NBUdoC5YQauxK2FKlcHUZbRbI58Yfu5r5U59fIbirgt1VEXCytQsaBSVOOC0hly4RcIpgaaRIPiL
RdAsM2jboVCeHL2iULrFzdQxDoMa3t/pX91chi7sKfGpmkUa/nvvcGuxNO4XAYKdxErJdUfsg+Qk
teRh0LuQbtivq56lDHvVCClI/a+/cYOLBNY4HfjYvymIe3tYiVyfOD2x6HFLd+6rn0zcYl10s5ct
5H/kMvPrFxwGKRyueFIXduJBf6ulPo5M8j5a6ZGT3aWUy6ptVTB8fc2yNbUo8gKRO8QBr/IpxBdM
KaUed5NvLRRW5ZrEtwWnynJ9tg+NTvw1sixEe0H0En/Led6oWRDaquo5ulWLpqjTLHbhpH8SaSGU
r0XaAjJJuNnsDC6vBv8ASzmD4bsPAAA=

--Multipart=_Sat__31_Aug_2024_12_48_13_+0200_1T24GTk9XT+3TsF6--


pgpoPCcVV_Mdk.pgp
Description: PGP signature

Bug#1078590: apt-listbugs: [L10N,DE] apt-listbugs_0.1.42: german translation

[Francesco Poli]

On Tue, 13 Aug 2024 09:16:51 +0200 Christoph Brinkhaus wrote:

[...]
> Dear Maintainer,
> 
> please find attached the po file with the german translation.
> Please consider to apply it to the package.

Dear Christoph,
thank you so much for the updated translation (wow! without even having
to ask for it!).
I will look at it, as soon as I can (probably in 2 or 3 weeks).

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


pgpocRGhTM5s6.pgp
Description: PGP signature

Bug#1077273: mpv: fails to seek within YouTube videos (played via yt-dlp)

[Francesco Poli]

Control: reassign -1 yt-dlp 2024.07.16-1


On Sat, 27 Jul 2024 20:23:53 +0200 Francesco Poli (wintermute) wrote:

[...]
> However, even if the cause may be in YouTube, this should be fixed (or worked
> around) in mpv (or maybe in yt-dlp, please re-assign the bug report, if
> this is the case).
[...]

I've just upgraded yt-dlp (from version 2024.07.16-1 to version
2024.07.25-1) and this bug has vanished.

I am reassigning the bug report to yt-dlp with the intention of closing
it (for yt-dlp version 2024.07.25-1).


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


pgpwpA9rY_oSl.pgp
Description: PGP signature

Bug#1077273: mpv: fails to seek within YouTube videos (played via yt-dlp)

[Francesco Poli (wintermute)]

Package: mpv
Version: 0.38.0-1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this great package in Debian!

One of the very useful features of mpv is that it is able to use
yt-dlp behind the scenes, in order to play YouTube videos (and videos
from other platforms, as well).

Unfortunately, since last Tuesday or Wednesday (23 or 24 July 2024),
mpv has stopped being able to seek within YouTube videos.

I mean that, if I issue a command such as:

  $ mpv https://www.youtube.com/watch?v=$VIDEO

or:

  $ mpv --volume=84 --fullscreen https://www.youtube.com/watch?v=$VIDEO

I can watch the whole video from the beginning to the end, as usual.

But, if I attempt to skip to a given chapter (with the » or « buttons)
or to a given time instant (by clicking on the progress bar) within
the video, the video freezes (still image and no audio) and mpv fails
to fill the cache with the appropriate segment of the video, despite
downloading a bunch of data (I see downstream traffic on the network
interface).

This began to happen all of a sudden (in the middle of the week, as I said),
without any upgrade of mpv or yt-dlp on my Debian testing box.
I do not see any other relevant package upgrade in the days when this
began to happen. I may be wrong, but I suspect that something has changed
in YouTube, rather than in yt-dlp or mpv.

However, even if the cause may be in YouTube, this should be fixed (or worked
around) in mpv (or maybe in yt-dlp, please re-assign the bug report, if
this is the case).

Please fix this 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.9.10-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  libarchive13t643.7.2-2.1
ii  libasound2t64  1.2.12-1
ii  libass91:0.17.3-1
ii  libavcodec-extra60 [libavcodec60]  7:6.1.1-5+b1
ii  libavdevice60  7:6.1.1-5+b1
ii  libavfilter-extra9 [libavfilter9]  7:6.1.1-5+b1
ii  libavformat60  7:6.1.1-5+b1
ii  libavutil587:6.1.1-5+b1
ii  libbluray2 1:1.3.4-1+b1
ii  libc6  2.39-4
ii  libcaca0   0.99.beta20-4+b1
ii  libcdio-cdda2t64   10.2+2.0.2-1
ii  libcdio-paranoia2t64   10.2+2.0.2-1
ii  libcdio19t64   2.1.0-4.2
ii  libdrm22.4.121-2
ii  libdvdnav4 6.1.1-3
ii  libegl11.7.0-1+b1
ii  libgbm124.1.3-2
ii  libjack-jackd2-0 [libjack-0.125]   1.9.21~dfsg-3+b3
ii  libjpeg62-turbo1:2.1.5-3
ii  liblcms2-2 2.14-2+b1
ii  liblua5.2-05.2.4-3+b2
ii  libmujs3   1.3.3-3+b2
ii  libpipewire-0.3-0t64   1.2.1-1
ii  libplacebo338  6.338.2-2
ii  libpulse0  16.1+dfsg1-5.1
ii  librubberband2 3.3.0+dfsg-2+b2
ii  libsdl2-2.0-0  2.30.5+dfsg-1
ii  libsixel1  1.10.3-3+b1
ii  libswresample4 7:6.1.1-5+b1
ii  libswscale77:6.1.1-5+b1
ii  libuchardet0   0.0.8-1+b1
ii  libva-drm2 2.22.0-1
ii  libva-wayland2 2.22.0-1
ii  libva-x11-22.22.0-1
ii  libva2 2.22.0-1
ii  libvdpau1  1.5-3
ii  libvulkan1 1.3.283.0-1
ii  libwayland-client0 1.22.0-2.1+b1
ii  libwayland-cursor0 1.22.0-2.1+b1
ii  libwayland-egl11.22.0-2.1+b1
ii  libx11-6   2:1.8.7-1+b1
ii  libxext6   2:1.3.4-1+b1
ii  libxkbcommon0  1.6.0-1+b1
ii  libxpresent1   1.0.1-1
ii  libxrandr2 2:1.5.4-1
ii  libxss11:1.2.3-1+b1
ii  libxv1 2:1.0.11-1.1+b1
ii  libzimg2   3.0.5+ds1-1+b1
ii  zlib1g 1:1.3.dfsg+really1.3.1-1

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

Versions of packages mpv suggests:
pn  libcuda1  

-- no debconf information

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Mon, 22 Jul 2024 17:49:13 +0300 jim_p  wrote:

[...]
> Sunday report... on Monday afternoon because I forgot about it. Like with the
> previous change, adding "After=remote-fs.target" did not change much. It still
> fails like half the times, like it does with the other parameter or with
> neither of the two.
[...]

Then I really cannot understand what's going on in your system... I am
sorry...   :-(

Is there anyone else who has tested the three files I sent?
Does anyone else have issues with them?

I reiterate the request to people from the Debian Kernel Team: could
someone please step in, test the three files, and share his/her insight
about why they seem to work for me, but not for jim_p?


P.S.: Please Cc me, in case you want me to see the replies earlier;
I am not subscribed to the bug, I just see comments on the web bug log,
when I am not in Cc...

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


pgpZOo1vFfgxv.pgp
Description: PGP signature

Bug#1076640: wtmpdb: last gets the dates wrong on i386 architecture

[Francesco Poli]

On Sat, 27 Jul 2024 00:35:33 +0200 Bernhard Übelacker wrote:

[...]
> Hello,

Hi there!
Thanks for following up on my bug report.   :-)

> I just tried to debug the issue and found this is caused by the line below.
> 
>src/wtmpdb.c:
>365   uint64_t login_t = strtoul(argv[3], &endptr, 10);
>366   if ((errno == ERANGE && login_t == UINT64_MAX)
> 
> Unfortuantely returns the strtoul an overflow error which gets
> through unnoticed because strtoul returns ULONG_MAX instead of UINT64_MAX.

Good, so there is something to be fixed in the program, as I suspected.

> 
> And found this issue got reported already upstream
> and it got fixed a few hours ago using strtoull by this commit (and new 
> release v0.13.0):
> 
>
> https://github.com/thkukuk/wtmpdb/commit/f3ca146227ecca42ec1562d60fa4856fbc0ca4af

I am happy there's a fix (although I admit that I do not fully
understand it...). Thanks for informing me, looking forward to seeing
the fixed version packaged and uploaded to Debian unstable.


P.S.: If anyone is curious about what I do not fully understand, here's
my naive reasoning: the strtoull(3) man page states that strtoull
returns an 'unsigned long long' (which is guaranteed to be at least 64
bit wide, but could be wider than 64 bit on some architectures, in
principle...); but the returned value is assigned to a variable of type
'uint64_t' (which is always exactly 64 bit wide); what happens on an
(existing or hypothetical) architecture where the width of 'unsigned
long long' is greater than 64 bit? is the returned value converted from
'unsigned long long' to 'uint64_t'? if this is the case, how can
login_t ever be equal to ULLONG_MAX, on architectures where ULLONG_MAX
is strictly greater than UINT64_MAX ?


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


pgpcuKPHO2Vkc.pgp
Description: PGP signature

Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

On Wed, 24 Jul 2024 21:30:00 +0300 Imre Deak wrote:

[...]
> Thanks for the logs.

Thanks to you for looking into them!
By the way, I have just upgraded the Linux kernel, but the
issue stays the same:

  $ uname -srvmo
  Linux 6.9.10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.10-1 (2024-07-19) x86_64 
GNU/Linux

> The VBT claims that the laptop has 1 USB-C

which I think it has (and dmidecode seems to see it)...

> and 3 legacy DP connectors (the latter 3 being a bit odd on a laptop,
> even if not impossible).

Do you mean that I should see 3 external DisplayPort connectors?
I really cannot spot them.
I cannot see any set of three identical connectors on the "outer
surface" of the laptop case, actually.

However, the graphics software stack sees them, as confirmed by
the output of 'xrandr' (attached).

Could they be internal (unused) connectors?

Or maybe they are not really present in the hardware, and the Linux
kernel wrongly thinks they are there, because of some bug...?
Could this happen?!?

> The DMI in BIOS says:
> 
> DMI: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023
> 
> for which I can't find the particular system to check the actual
> configuration. Could you point to the laptop vendor/model's page or
> describe what are the connectors on it?

The label on the bottom of the laptop case says:

  MODEL: NL41PU

and

  PRODUCT CODE: NL41PU2

According to the same label, the brand should be [Clevo].

[Clevo]: <https://clevo-computer.com/en/>

I bought the laptop from an Italian shop which, among other things,
assembles customized laptops, that can be configured through
a web [configurator] (unfortunately, it seems that the website
is in Italian only...).

[configurator]: <https://syspack.com/configuratoreNotebook.php>

The notebook that I selected (along with other components) is
identified as "Work14 i5-1235U DDR4 M.2 14" FullHD"
The provided description (translated into English by me) is attached.

I think the Clevo NL41PU laptop is the same as the one
described [here].

[here]: <https://laptopwithlinux.com/product/clevo-nl41/>

> 
> Could you check if there is a BIOS upgrade available?

Following from the Clevo [support] site, I think I found
the relevant download server [folder], but it seems to me that
there is no upgrade later than "1.07.09 11/17/2023"...
Actually, I cannot even see that version, which is awkward.
Maybe I am misunderstanding something...   :-(
Or maybe not: I have also asked the shop about possible BIOS upgrades,
and they replied to me that there are no BIOS upgrades yet for that
model, as far as they can tell.

[support]: <https://clevo-computer.com/en/support-drivers>
[folder]: 
<https://my.hidrive.com/share/yze8mg-wf8#$/BIOS%20and%20EC%20Firmware/CLEVO/N_Series/NLxxx/NLxxPxx/NL4xPUx>

> Please follow up
> on the gitlab issue as Jani suggested.

I had reported the bug to the Debian BTS (Bug Tracking System), where
I was told to report the bug upstream, by contacting developers/mailing
lists.
Now on this mailing list, I am being told to report the issue on
gitlab.freedesktop.org (which requires to register an account, in order
to report issues)... Having to jump through all these hoops is beginning
to be a little time consuming...   :-(


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


xrandr.out.gz
Description: application/gzip


work14_description.txt.gz
Description: application/gzip


pgpBtQaSGeQ9H.pgp
Description: PGP signature

Bug#1076640: wtmpdb: last gets the dates wrong on i386 architecture

[Francesco Poli (wintermute)]

Package: wtmpdb
Version: 0.12.0-3
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello Chris,
thanks for maintaining this package, which ships command 'last' (as a
symlink).

I installed it on a number of amd64 Debian boxes, without any major
issue.

Then I installed it on the i386 Debian box described below:

  # aptitude install wtmpdb
  [...]
  # exit

Right after having installed it, I have again logged in (through ssh) and:

  $ last
  $USERssh  $REMOTE_IP   Thu Jan  1 02:11 - still logged in
  reboot   system boot  6.9.9-686Thu Jan  1 02:11 - still running
  
  /var/lib/wtmpdb/wtmp.db begins Thu Jan  1 02:11:34 1970

Dates and times seem to be completely wrong, but the system clock is OK:

  $ date -R
  Sat, 20 Jul 2024 16:52:00 +0200

What is funny (or maybe not?!?) is that it seems that it reads all timestamp
as a fixed value. If I log out and then back in, I get:

  $ last
  $USERssh  $REMOTE_IP   Thu Jan  1 02:11 - still logged in
  $USERssh  $REMOTE_IP   Thu Jan  1 02:11 - 02:11  (00:00)
  reboot   system boot  6.9.9-686Thu Jan  1 02:11 - still running
  
  /var/lib/wtmpdb/wtmp.db begins Thu Jan  1 02:11:34 1970

In other words, wtmpdb seems to think that everything happens "compressed"
in a single instant at 02:11:34 of January, the 1st, 1970, as in some weird
sci-fi story!   ;-)

Other tools seem to be well aware that we are not living in that weird
sci-fi universe:

  $ who
  $USERpts/02024-07-20 17:09 ($REMOTE_IP)

There must be some bug related with the time_t reading, maybe related to
the fact that i386 has been [excluded] from the 64-bit time_t transition,
thus remaining with the 32-bit time_t...

[excluded]: 


Please fix this bug and/or forward the bug report upstream, as
appropriate.
Thanks for your time (or for your time_t !!!).


P.S.: I would like to see this bug fixed before Thu Jan  1 02:11:34 1970
  ;-p


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

Kernel: Linux 6.9.9-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 wtmpdb depends on:
ii  libaudit11:3.1.2-4+b1
ii  libc62.38-14
ii  libsystemd0  256.2-1
ii  libwtmpdb0   0.12.0-3

Versions of packages wtmpdb recommends:
ii  libpam-wtmpdb  0.12.0-3

wtmpdb suggests no packages.

-- no debconf information

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Thu, 18 Jul 2024 12:31:59 +0300 jim_p  wrote:

[...]
> Then I discovered linux-cpupower, which I used by running "cpupower
> frequency-set -g powersave" on every boot.

Hi!

How did you use to run "cpupower frequency-set -g powersave" ?
Manually?
Or did you drop that line in some script executed at boot (such as the
deprecated rc.local)?

If I understand correctly, it was working, without failing, when you
followed this strategy.

> 
> I was also annoyed by the lack of a systemd service and a config file in
> debian, until I tried the attached files here.

Thanks for testing them!   :-)

> I am having the following issue.
> The service sometimes fails to start on boot.

What do you mean by "sometimes"?
Do you mean that it works on some boots and fails on some other boots,
in a seemingly unpredictable manner?
Or did you identify some pattern in these success/error cases?

> I added the -x parameter and
> removed the "> /dev/null || ESTATUS=1" from line 20 of /usr/libexec/cpupower 
> so
> as to get a better error output, but all I get is this
> 
> $ sudo journalctl -b -u cpupower.service
> Jul 14 19:50:41 pc systemd[1]: Starting cpupower.service - Apply cpupower
> configuration...
> Jul 14 19:50:41 pc cpupower[337]: + ESTATUS=0
> Jul 14 19:50:41 pc cpupower[337]: + test  !=
> Jul 14 19:50:41 pc cpupower[337]: + PARS= -g powersave
> Jul 14 19:50:41 pc cpupower[337]: + PARS= -g powersave
> Jul 14 19:50:41 pc cpupower[337]: + test  -g powersave !=
> Jul 14 19:50:41 pc cpupower[337]: + cpupower frequency-set -g powersave
> Jul 14 19:50:41 pc cpupower[343]: Setting cpu: 0
> Jul 14 19:50:41 pc cpupower[343]: Error setting new values. Common errors:
> Jul 14 19:50:41 pc cpupower[343]: - Do you have proper administration rights?
> (super-user?)
> Jul 14 19:50:41 pc cpupower[343]: - Is the governor you requested available 
> and
> modprobed?
> Jul 14 19:50:41 pc cpupower[343]: - Trying to set an invalid policy?
> Jul 14 19:50:41 pc cpupower[343]: - Trying to set a specific frequency, but
> userspace governor is not available,
> Jul 14 19:50:41 pc cpupower[343]:for example because of hardware which
> cannot be set to a specific frequency
> Jul 14 19:50:41 pc cpupower[343]:or because the userspace governor isn't
> loaded?
> Jul 14 19:50:41 pc cpupower[337]: + PARS=
> Jul 14 19:50:41 pc cpupower[337]: + test  !=
> Jul 14 19:50:41 pc cpupower[337]: + exit 0
> Jul 14 19:50:41 pc systemd[1]: Finished cpupower.service - Apply cpupower
> configuration.
> 
> Any ideas?

Not many, unfortunately, at least on my side.

It works for me™, which, I acknowledge, doesn't mean much...

Of course you installed cpupower.service into /usr/lib/systemd/system/,
hence we can assume that systemd is executing the /usr/libexec/cpupower
script as root.
And anyway, it must be so, otherwise it would *always* fail...

Maybe the systemd service sometimes gets started too early in your
system, but I don't understand how it could be: as far as I can see,
cpupower only needs to be able to load kernel modules... so how can it
be too early?!?
People from the Debian Kernel Team will sure understand these things
much better than me: could someone please step in and share his/her
insight?

In the meanwhile, let's try to add

  After=systemd-modules-load.service

to the [Unit] section of cpupower.service, as in the attached file.

Or maybe

  After=remote-fs.target

?

Could you please test this modification and see whether it cures your
issue?



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


cpupower.service
Description: Binary data


pgptFClZZMl8X.pgp
Description: PGP signature

Bug#1076476: mmdebstrap-autopkgtest-build-qemu asks to install libarchive13, but should ask for libarchive13t64

[Francesco Poli]

On Wed, 17 Jul 2024 00:48:20 +0200 Johannes Schauer Marin Rodrigues
wrote:

[...]
> This was not an ABI transition from libarchive but an artificial one from
> Debian. The last time libarchive bumped the SONAME was a decade ago.

Yes, that's clear, even though it caused a binary package name change
anyway...

> 
> The proper fix is this:
> 
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/98b3c7f2cdeb42c0fdf71bef28423cded83b7516
> 
> Thanks!

Thanks to you!   :-)
I've just applied that patch and tried again:
mmdebstrap-autopkgtest-build-qemu now seems to work correctly.

Hence, I can confirm that the proper fix is the patch you mentioned.

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


pgp5nJiygw9H7.pgp
Description: PGP signature

Bug#1076476: mmdebstrap-autopkgtest-build-qemu asks to install libarchive13, but should ask for libarchive13t64

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.5.2-1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello,
I tried to run mmdebstrap-autopkgtest-build-qemu, but now it fails:

  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
   --size=25G --boot=efi sid unstable-autopkgtest-amd64.img
  please install libarchive13

I already had that package on my system, except that, due to the
t64 transition, it is now called 'libarchive13t64':

  $ aptitude search libarchive13
  v   libarchive13-
  i A libarchive13t64 - Multi-format archive [...]

and it only provides 'libarchive13' as a virtual package...

[t64]: 

I think the check at line 283 of mmdebstrap-autopkgtest-build-qemu
should be changed from:

  for pkg in autopkgtest dosfstools e2fsprogs fdisk mount mtools passwd uidmap 
libarchive13; do
  test_installed "$pkg"
  done

to the following:

  for pkg in autopkgtest dosfstools e2fsprogs fdisk mount mtools passwd uidmap 
libarchive13t64; do
  test_installed "$pkg"
  done


Is there a better strategy (that doesn't force you to modify that line in
mmdebstrap-autopkgtest-build-qemu each time an ABI transition happens
in src:libarchive ) ?


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

Kernel: Linux 6.9.8-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.9.6
ii  perl 5.38.2-5
ii  python3  3.12.3-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-17
ii  fakeroot 1.33-1
ii  gpg  2.2.43-7
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.6
ii  mount2.40.2-1
ii  uidmap   1:4.15.3-2

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor   
ii  apt-utils   2.9.6
ii  bzip2   1.0.8-5.1
ii  ca-certificates 20240203
ii  debootstrap 1.0.136
ii  distro-info-data0.62
ii  dpkg-dev1.22.6
ii  e2fsprogs   1.47.1-1
pn  genext2fs   
ii  libarchive13t64 [libarchive13]  3.7.2-2.1
pn  lz4 
pn  lzop
pn  ncompress   
ii  perl-doc5.38.2-5
pn  qemu-user   
pn  qemu-user-static
pn  squashfs-tools-ng   
ii  systemd 256.2-1
ii  xz-utils5.6.2-2
ii  zstd1.5.6+dfsg-1

-- no debconf information

Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

Hi all,
on a laptop where I installed Debian testing some 6 months ago,
I noticed that the logs are continuously flooded with call traces
like the attached snippet (taken from /var/log/kern.log ).

It seems to me that it also used to happen with previous versions
of the Linux kernel, but I am under the impression that, with Linux
kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel
version 6.9.8 (provided by the distro, Debian testing, as I said), but
the bug is still reproducible:

  $ uname -srvmo
  Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 
GNU/Linux

I see at least 12 of these call traces just after boot, before even
starting X (with 'startx').
More of these call traces are sent to the logs after starting X, or
after invoking 'xrandr', or after locking the X session (with
XScreenSaver), ...
I always see these call traces (I mean the bug is always reproducible:
each time I boot, each time I call xrandr, ...).

They seem to correspond to no actual issue, as far as I can tell,
but they are flooding the logs with a significant flow of text...
which is worrying by itself.


What's wrong?
How can I stop this log-filling flood?
Should I black-list some module, for instance?


The outputs of

  # lspci -vnn -d :*:0300

and of

  # dmidecode

are attached.
Also, I booted with kernel parameters
'drm.debug=0xe log_buf_len=4M ignore_loglevel' and
logged in as root right after the boot.
The output of

  # dmesg

is attached.

Some additional information may be found on the [Debian bug] report I had 
previously filed.

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


N.B.:
Please Cc me and the Debian bug address <1075...@bugs.debian.org>
on replies, so that the interested parties (including me!) are kept
in the loop.
Thanks a lot for your time and for any help you may provide!


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


snip_kern.log
Description: Binary data


dmesg.out.gz
Description: application/gzip


dmidecode.out.gz
Description: application/gzip


lspci.out.gz
Description: application/gzip


pgpVDomXmeNV8.pgp
Description: PGP signature

Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

On Sat, 13 Jul 2024 20:56:08 +0200 Salvatore Bonaccorso wrote:

[...]
> On Sat, Jul 13, 2024 at 07:10:08PM +0200, Francesco Poli wrote:
[...]
> > Wouldn't it be so much easier, if you just forward my bug report
> > upstream?
> 
> You are directly affected and we cannot reproduce the issue on our
> own, so we gave you guidance on where exactly to report it. If you
> directly report it you get the direct interaction with upstream, as
> you might be the only one providing additional feedback on question.
> 
> But sure if you do not want to report it, I can forward to the
> maintainers with similar effect, just let me know if you prefer to not
> write on your own to upstream.

OK, I'll try, but, depending on which feedback I am asked to provide,
I could need some help 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


pgpRoPowl7XVK.pgp
Description: PGP signature

Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

On Sat, 13 Jul 2024 15:04:49 +0200 Salvatore Bonaccorso wrote:

[...]
> We discussed your case in the last kernel-team meeting and came to the
> conclusion that if possible you report your issue upstream and keep us
> here in the loop about progressm. I was not clear though if you need
> some guidance to do so.
[...]

Wouldn't it be so much easier, if you just forward my bug report
upstream?


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


pgpFHfhuXiZtO.pgp
Description: PGP signature

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Thu, 4 Jul 2024 23:21:32 +0200 Francesco Poli wrote:

> On Sat, 15 Jun 2024 16:48:58 +0200 Francesco Poli wrote:
[...]
> > Once again, please accept the "patch" and incorporate the files (or
> > further enhanced versions of them) into linux-cpupower.
> 
> Have you had a chance to take a look at the three files I sent?
> Could you test them?
> 
> I really hope they can soon be incorporated into the official
> linux-cpupower Debian package...

Another version of linux-cpupower (along with the other binary packages
from src:linux, of course) migrated to Debian testing.

Still, no feedback about the three files I sent to address this bug
(#894906)...
Please take a look at the files, test them, and incorporate them into
the official linux-cpupower Debian package.
Or, if there's something that is not right about them, please let me
know, and help me to improve them.

Package cpufrequtils has been [removed] from Debian on 16 June 2024,
and the three files I sent are the only missing piece (as far as I
know) for linux-cpupower to be a perfect replacement.
I guess many users are waiting for this feature.

[removed]: 
<https://tracker.debian.org/news/1537421/removed-008-2-from-unstable/>

Let's fill this gap once and for all!

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


pgpjyZvW7kuJS.pgp
Description: PGP signature

Bug#894462: closed by Drew Parsons (reply to dpars...@debian.org) (Re: Bug#894462 paraview: edges are blotted [regression])

[Francesco Poli]

On Mon, 08 Jul 2024 09:24:05 + Debian Bug Tracking System wrote:

> There is no "Endpoint Search Iterations" option in the Render View 
> settings for paraview 5.12.1.
> Perhaps the issue has already been considered upstream.

As I have previously said, you can access the FXAA parameters by
clicking on the "Toggle advanced properties" button (the little button
with a gear icon in it) in the "Render View" tab of
the Settings dialog window.
There you should find (I've just checked with paraview/5.12.1+dfsg-3)
the parameters I was talking about.

> 
> In any case, the FXAA implementation is made by upstream, debian can't 
> directly alter it.

We are talking about Free Software, the Debian packagers can modify
whatever they see fit.
What you mean is that you prefer not to deviate from upstream on
algorithm implementation or default parameter values, in a way that
would affect obtained results.

> 
> If the antialiasing continues not to work as desired, then please raise 
> an issue upstream at
> https://gitlab.kitware.com/paraview/paraview/-/issues

The results of my tests are still the same with paraview/5.12.1+dfsg-3

I am still convinced that better default values for the FXAA parameters
could be set by the upstream developers.
Please reopen this bug report and forward it upstream.

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


pgpAgcravv7zt.pgp
Description: PGP signature

Bug#1075873: apt-listbugs: [INTL:nl] Dutch translation for the apt-listbugs package

[Francesco Poli]

On Sun, 07 Jul 2024 22:39:19 +0200 Frans Spiesschaert wrote:

[...]
> Francesco Poli schreef op zo 07-07-2024 om 16:50 [+0200]:
[...]
> > Please let me know, in case you indeed prefer this second possibility.
> 
> Yes, please fix it this way.

Perfect, I've just done so.
It will be part of the next package upload to unstable!

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


pgpYqoMZ6TBbs.pgp
Description: PGP signature

Bug#1075873: apt-listbugs: [INTL:nl] Dutch translation for the apt-listbugs package

[Francesco Poli]

On Sat, 06 Jul 2024 22:54:42 +0200 Frans Spiesschaert wrote:

[...] 
> Dear Maintainer,

Hi Frans,
nice to read you!

>  
>  
> Please find attached the updated Dutch po file for the apt-listbugs
> package.

Wow, without even having to ask for it!   ;-)
Thank you so much!

> A draft has been posted to the debian-l10n-dutch mailing list allowing for
> review. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 

I have a little question.

#: ../lib/aptlistbugs/logic.rb:62
msgid ""
" -H : Hostname of Debian Bug Tracking System\n"
"(for http, deprecated).\n"
msgstr ""
" -H : Computernaam van Debian Bug Tracking System "
"(bugvolgsysteem\n"
"(voor http, ontraden).\n"


There seems to be a unbalanced parentheses here.
I am fixing it as follows:

#: ../lib/aptlistbugs/logic.rb:62
msgid ""
" -H : Hostname of Debian Bug Tracking System\n"
"(for http, deprecated).\n"
msgstr ""
" -H : Computernaam van Debian Bug Tracking System "
"(bugvolgsysteem)\n"
"(voor http, ontraden).\n"


But, maybe, you prefer to drop the explanation completely, as in:

#: ../lib/aptlistbugs/logic.rb:62
msgid ""
" -H : Hostname of Debian Bug Tracking System\n"
"(for http, deprecated).\n"
msgstr ""
" -H : Computernaam van Debian Bug Tracking System\n"
"(voor http, ontraden).\n"

taking into account that the meaning of 'Bug Tracking System' has just
been explained in the immediately preceding online-help
option-description.
Please let me know, in case you indeed prefer this second possibility.

Thanks again!


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


pgpuFWHrOOd1A.pgp
Description: PGP signature

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Sat, 15 Jun 2024 16:48:58 +0200 Francesco Poli wrote:

[...]
> Please find attached the three updated files.
> 
> Tested on one of my systems, where I purged cpufrequtils and installed
> linux-cpupower and then I issued the following commands:
> 
>   # install -m 644 cpupower.default /etc/default/cpupower
>   # install -m 755 cpupower.sh /usr/libexec/cpupower
>   # install -m 644 cpupower.service /usr/lib/systemd/system/
>   # systemctl daemon-reload
>   # systemctl enable cpupower.service
> 
> The systemd service runs at boot and sets everything needed with
> cpupower (as configured in /etc/default/cpupower ).

I am now using these three files on two distinct systems: they work as
intended, with no issues at all.

> 
> Once again, please accept the "patch" and incorporate the files (or
> further enhanced versions of them) into linux-cpupower.

Have you had a chance to take a look at the three files I sent?
Could you test them?

I really hope they can soon be incorporated into the official
linux-cpupower Debian package...

> 
> Thanks for your time and dedication!
> Bye.

Again thanks for reading so far and for your consideration.


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


pgpIz092QQPIk.pgp
Description: PGP signature

Bug#1075770: linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli (wintermute)]

Package: src:linux
Version: 6.9.7-1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello,
on a laptop where I installed Debian testing some 6 months ago,
I noticed that the logs are continuously filled with call traces
like the attached snippet (taken from /var/log/kern.log ).

It seems to me that it also used to happen with previous versions
of the Linux kernel, but I am under the impression that, with linux/6.9.7-1,
it got worse.

I see 12 of these call traces just after boot, before even starting X
(with 'startx').
More of these call traces are sent to the logs after starting X, or
after invoking 'xrandr', or after locking the X session (with
XScreenSaver), ...

They seem to correspond to no actual issue, as far as I can tell,
but they are filling the logs with a significant flow of text...
which is worrying by itself.

What's wrong?
How can I stop this log-filling flood?


-- Package-specific info:
** Version:
Linux version 6.9.7-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.3.0-1) 13.3.0, GNU ld (GNU Binutils for 
Debian) 2.42.50.20240625) #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 (2024-06-27)

** Command line:
BOOT_IMAGE=/vmlinuz-6.9.7-amd64 root=/dev/mapper/ol-root ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Notebook
product_name: NLxxPUx
product_version: Not Applicable
chassis_vendor: No Enclosure
chassis_version: N/A
bios_vendor: INSYDE Corp.
bios_version: 1.07.09
board_vendor: Notebook
board_name: NLxxPUx
board_version: Not Applicable

** Loaded modules:
8021q
garp
stp
mrp
llc
iptable_nat
nf_nat
nf_conntrack
cmac
nf_defrag_ipv6
nf_defrag_ipv4
algif_hash
libcrc32c
algif_skcipher
iptable_mangle
af_alg
snd_hda_codec_hdmi
iptable_filter
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
snd_sof_pci_intel_tgl
fat
snd_sof_intel_hda_common
soundwire_intel
snd_sof_intel_hda_mlink
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
snd_soc_hdac_hda
snd_soc_acpi_intel_match
soundwire_generic_allocation
snd_soc_acpi
soundwire_bus
snd_soc_avs
snd_soc_hda_codec
snd_hda_ext_core
btusb
i915
btrtl
snd_soc_core
btintel
btbcm
btmtk
snd_compress
iwlmvm
intel_uncore_frequency
intel_uncore_frequency_common
snd_pcm_dmaengine
bluetooth
x86_pkg_temp_thermal
snd_hda_intel
mac80211
intel_powerclamp
snd_intel_dspcfg
uvcvideo
coretemp
snd_intel_sdw_acpi
snd_usb_audio
processor_thermal_device_pci
videobuf2_vmalloc
kvm_intel
snd_hda_codec
processor_thermal_device
drm_buddy
snd_usbmidi_lib
uvc
processor_thermal_wt_hint
libarc4
sha3_generic
drm_display_helper
snd_hda_core
snd_rawmidi
videobuf2_memops
processor_thermal_rfim
kvm
jitterentropy_rng
snd_hwdep
snd_seq_device
cec
videobuf2_v4l2
iwlwifi
intel_rapl_msr
processor_thermal_rapl
snd_pcm
drbg
rc_core
iTCO_wdt
videodev
intel_rapl_common
rapl
mei_pxp
mei_hdcp
processor_thermal_wt_req
ttm
intel_pmc_bxt
ansi_cprng
snd_timer
cfg80211
jc42
intel_cstate
processor_thermal_power_floor
intel_pmc_core
videobuf2_common
iTCO_vendor_support
drm_kms_helper
mei_me
snd
ecdh_generic
int3403_thermal
processor_thermal_mbox
int3400_thermal
intel_uncore
pmt_telemetry
pcspkr
watchdog
mc
ee1004
i2c_algo_bit
ecc
mei
rfkill
soundcore
intel_vsec
igen6_edac
int340x_thermal_zone
joydev
evdev
acpi_thermal_rel
pmt_class
intel_hid
acpi_pad
sparse_keymap
ac
button
hid_multitouch
serio_raw
efi_pstore
configfs
nfnetlink
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
nvme
nvme_core
usbhid
t10_pi
crc32_pclmul
crc32c_intel
crc64_rocksoft_generic
crc64_rocksoft
hid_generic
ahci
ghash_clmulni_intel
crc_t10dif
sha512_ssse3
xhci_pci
libahci
r8169
crct10dif_generic
i2c_hid_acpi
rtsx_pci_sdmmc
sha512_generic
xhci_hcd
libata
realtek
crct10dif_pclmul
i2c_hid
intel_lpss_pci
mmc_core
sha256_ssse3
mdio_devres
crc64
scsi_mod
i2c_i801
usbcore
intel_lpss
drm
psmouse
sha1_ssse3
libphy
video
rtsx_pci
crct10dif_common
i2c_smbus
scsi_common
idma64
usb_common
battery
hid
wmi
aesni_intel
crypto_simd
cryptd

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Alder Lake-U15 Host and DRAM 
Controller [8086:4601] (rev 04)
Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: igen6_edac
Kernel modules: igen6_edac

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP3 GT2 
[UHD Graphics] [8086:4628] (rev 0c) (prog-if 00 [VGA controller])
Subsystem: CLEVO/KAPOK Computer Device [1558:4150]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Francesco Poli]

On Fri, 21 Jun 2024 00:42:21 +0200 Christian Kastner wrote:

> Hi,

Hello Christian,
nice to read you.

Thanks for following up.

> 
> On 2024-06-17 08:34, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Francesco Poli (wintermute) (2024-06-16 19:09:08)
[...]
> >> Now the allocated size is 832 MB, instead of 705 MB !!!
> 
> In this particular case, one factor would be that the update caused new
> APT lists to be downloaded, which have tens of MB.

How so?

As I said in the [original] bug report, I tried to run
sbuild-qemu-update on the image that I had just regenerated from
scratch. It seems that it found nothing to update, not even the APT
repository lists (which were already up-to-date, as expected). Please
take a look at the output of sbuild-qemu-update in the [original] bug
report...

[original]: <https://bugs.debian.org/1073509#5>

[...]
> I guess clever stuff could be done but honestly, it's probably simpler
> to occasionally regenerate an image.

It's clearly simpler to periodically regenerate the image and ditch the
previous one, I agree. Simpler from the developer's standpoint, but
less convenient from the user's standpoint.

Come on, I am sure you are clever enough to figure out a good strategy
to automatically prevent the image allocated size from growing
indefinitely!
I have faith in you!   ;-)

> 
> A hacky solution would be to use the --snapshot option to
> sbuild-qemu-update on first run. In future runs, you could reset the
> image to that snapshot using qemu-img. That would be a tradeoff though
> as with time, updates would take longer and longer.
[...]

I think this strategy would make sbuild-qemu-update less and less
useful: it would almost become more convenient to regenerate the image
from scratch each time (or anyway, often) with
mmdebstrap-autopkgtest-build-qemu ...

I still hope that something can be implemented within
sbuild-qemu-update, in order to "clean up" the unused blocks and allow
the host system to see them as non-allocated in the sparse file.
I guess I am not using the correct terms, due to plain ignorance, but I
think you understand what I mean... 


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


pgpPVqOhb1Mfi.pgp
Description: PGP signature

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Francesco Poli]

On Mon, 17 Jun 2024 08:34:27 +0200 Johannes Schauer Marin Rodrigues wrote:

[...]
> as you suspected this is because of how sparse files work. Whenever you 
> upgrade
> something in your image, data gets deleted and new data gets added. The
> filesystem driver in the kernel does not zero-out those parts that it deletes
> and even if it would, qemu has no idea which blocks of the underlying image
> file it should now mark "sparse".
> 
> One tool that should reduce size again is e2image from e2fsprogs:
> 
> $ e2image -rap old.img new.img
> 
> But this requires copying the actual file data.

Would that be quicker than regenerating the image from scratch?
Maybe, but, as you yourself note, it requires copying the data and then
removing the old image...

By the way, the .img file contains two partitions (the EFI system
partition and one ext2 partition): does e2image automatically handle
this mixed filesystem situation?

> I didn't try it out, but there
> is also the "discard" extended option of e2fsck:
> 
> $ e2fsck -E discard your.img

Same question as above about the mixed filesystem.

> 
> Lastly, I do not know if the zerofree tool has support for sparse files? Maybe
> try running it on your FS and see what happens. :)

According to its description, zerofree is intended to be run from
GNU/Linux systems installed as guest OSes inside a virtual machine.
Hence, I should run from withing the QEMU VM.
Could you please tell me how to properly do that?
Would the following work well?

  $ sbuild-qemu-boot --boot=efi --read-write unstable-autopkgtest-amd64.img
  root@image # apt install zerofree

But then I should remount the root filesystem of the VM in read-only
mode, shouldn't I?
How can I do so _within_ the running VM?

What other tool should I use to shrink the image from the host system,
after running zerofree from the guest system?



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


pgpcUj5GUV_5s.pgp
Description: PGP signature

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Francesco Poli]

On Mon, 17 Jun 2024 14:46:52 +0200 Johannes Schauer Marin Rodrigues wrote:

[...[
> follow-up question: are you on bookworm or on trixie?

I am running trixie.

> If the latter, would you mind testing an improved version of
> mmdebstrap-autopkgtest-build-qemu which is able to create bit-by-bit
> identical disk images?

Is it for the Reproducible Build project?

Well, if the test is not too complicated, I am willing to help.
But, unfortunately, not immediately: I will probably be unable to
perform the test in the following two weeks.
I will hopefully be able to test the improved version on July.

If you need to see the outcome of the test real soon now, then I cannot
help, sorry about that...

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


pgpXAWFdPwHx3.pgp
Description: PGP signature

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Francesco Poli (wintermute)]

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

Hello!

I've just found out something worrying about sbuild-qemu-update.

I noticed that my image allocated size was bigger than I remembered:

  $ cd ~/.cache/sbuild/
  $ ls -alrtFs --si OLD_unstable-autopkgtest-amd64.img
  3.6G -rw-rw 1 $USER $USER 27G Jun  9 22:00 
OLD_unstable-autopkgtest-amd64.img

Then, I tried to regenerate it from scratch:

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

And I checked again:

  $ cd ~/.cache/sbuild/
  $ ls -altrFs --si
  total 4.3G
  4.1k drwx-- 37 $USER $USER 4.1k May  4 16:03 ../
  4.1k drwxrwx---  2 $USER $USER 4.1k May 13 23:19 build/
  3.6G -rw-rw  1 $USER $USER  27G Jun  9 22:00 
OLD_unstable-autopkgtest-amd64.img
  705M -rw-rw  1 $USER $USER  27G Jun 16 18:22 
unstable-autopkgtest-amd64.img
  4.1k drwxrwx---  3 $USER $USER 4.1k Jun 16 18:26 ./

What? The allocated size is 705 MB for the newly generated image, while
it is 3.6 GB for the old one ???

OK, using the image to test packages with autopkgtest or to build
packages with sbuild-qemu should not touch the image (just create
epheremal overlays, is that correct?).
Hence, it must be sbuild-qemu-update that increases the allocated size...

I tried to run sbuild-qemu-update on the newly generated image.
Of course it found nothing to update:

  $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img
  qemu-system-x86_64 -enable-kvm -drive 
if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE_4M.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/.cache/sbuild/unstable-autopkgtest-amd64.img
  root
  Linux host 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) 
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
  Hit:1 http://deb.debian.org/debian sid InRelease
  Reading package lists...
  root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes 
dist-upgrade
  DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes dist-upgrade
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Calculating upgrade...
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes clean
  DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes clean
  root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes 
autoremove
  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

But, the allocated size has significantly grown:

  $ cd ~/.cache/sbuild/
  $ ls -altrFs --si
  total 4.4G
  4.1k drwx-- 37 $USER $USER 4.1k May  4 16:03 ../
  4.1k drwxrwx---  2 $USER $USER 4.1k May 13 23:19 build/
  3.6G -rw-rw  1 $USER $USER  27G Jun  9 22:00 
OLD_unstable-autopkgtest-amd64.img
  4.1k drwxrwx---  3 $USER $USER 4.1k Jun 16 18:26 ./
  832M -rw-rw  1 $USER $USER  27G Jun 16 18:26 
unstable-autopkgtest-amd64.img

Now the allocated size is 832 MB, instead of 705 MB !!!
That could explain how I had reached 3.6 GB, one run of sbuild-qemu-update
after the other...

But why does the allocated size increase?
Maybe there's something about sparse file support that I do not
fully understand.

Is there anything that can be done inside sbuild-qemu-update to prevent
the allocated size from growing indefinitely?
Apart from periodically regenerating the image from scratch, I mean...

Please let me know.
Thanks again for developing sbuild-qemu.


-- 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.35
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.4+ds-1
ii 

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

On Wed, 12 Jun 2024 22:09:10 +0200 Francesco Poli wrote:

[...]
> Is there room for improvement?
> Yes, I think there is.
> For instance, the script /usr/libexec/cpupower could be translated to
> POSIX shell, getting rid of its bashisms.

Here we go, I modified the script by translating it to POSIX shell,
dropping a couple of options that seem to no longer exist in cpupower,
and by making ignore all other frequency options, if FREQ is set.

I correspondingly modified the defaults file.

Please find attached the three updated files.

Tested on one of my systems, where I purged cpufrequtils and installed
linux-cpupower and then I issued the following commands:

  # install -m 644 cpupower.default /etc/default/cpupower
  # install -m 755 cpupower.sh /usr/libexec/cpupower
  # install -m 644 cpupower.service /usr/lib/systemd/system/
  # systemctl daemon-reload
  # systemctl enable cpupower.service

The systemd service runs at boot and sets everything needed with
cpupower (as configured in /etc/default/cpupower ).

Once again, please accept the "patch" and incorporate the files (or
further enhanced versions of them) into linux-cpupower.

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


cpupower.default
Description: Binary data


cpupower.service
Description: Binary data
#!/bin/sh
# Copyright © 2012, Sébastien Luttringer
# Copyright © 2024, Francesco Poli
# SPDX-License-Identifier: GPL-2.0-or-later

ESTATUS=0

# parse CPU clock frequency options
if test "$FREQ" != ""
then
PARS="${FREQ:+ -f $FREQ}"
else
PARS="${GOVERNOR:+ -g $GOVERNOR}"
PARS="${PARS}${MIN_FREQ:+ -d $MIN_FREQ}${MAX_FREQ:+ -u $MAX_FREQ}"
fi

# apply CPU clock frequency options
if test "$PARS" != ""
then
cpupower frequency-set$PARS > /dev/null || ESTATUS=1
fi

# parse CPU policy options
PARS="${PERF_BIAS:+ -b $PERF_BIAS}"

# apply CPU policy options
if test "$PARS" != ""
then
cpupower set$PARS > /dev/null || ESTATUS=1
fi

exit $ESTATUS


pgpBGFri_2WMG.pgp
Description: PGP signature

Bug#1072977: apt-listbugs 0.1.42 is broken

[Francesco Poli]

On Wed, 12 Jun 2024 21:25:37 +0200 Karine Crèvecœur wrote:

[...]
> So, there is no problem with the tls certificate of bugs.debian.org.
> Well, I think I should follow step by step what apt-lisbugs is doing
> when it retrieves bugs. Unfortunately, I don't how to proceed. If you
> give the steps, I can try.

OK, let's begin with a super-simple Ruby script (almost an example
code, so short and non-creative that I think it is not even
copyrighted...) that uses ruby-soap4r library to access the Debian BTS
SOAP interface.

See the attached file.

Please run it with:

  $ ruby test_bts_soap.rb

The output should be similar to:

  {1072977=>#""} {}archived=0 
{}found_date=[] {}subject="apt-listbugs 0.1.42 is broken" 
{}log_modified=1718220426 {}fixed_versions=[] {}severity="grave" {}affects="" 
{}source="apt-listbugs" {}id=1072977 {}outlook="" {}tags="moreinfo 
unreproducible" {}last_modified=1718220426 {}fixed_date=[] 
{}fixed=# {}found_versions=["apt-listbugs/0.1.42"] 
{}blockedby="" {}forwarded="" {}unarchived="" {}location="db-h" {}summary="" 
{}keywords="moreinfo unreproducible" {}date=1718095142 {}pending="pending" 
{}msgid="" 
{}package="apt-listbugs">}

Also try to enable the debug output with:

  $ ruby -d test_bts_soap.rb > bts_soap.log

and send me the "bts_soap.log" file.


Let's see if we can figure out what's going on!


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


test_bts_soap.rb
Description: application/ruby


pgpu2VGGh2sxU.pgp
Description: PGP signature

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[Francesco Poli]

Control: tags -1 + patch


On Thu, 05 Apr 2018 14:38:37 +0200 Pavel Kreuzt  wrote:
[...]
> linux-cpupower should be run at boot time, but no systemd service
> is installed, nor default config file is present in /etc/default.
> At least an example config should be provided as in cpufrequtils package.

Dear Debian Kernel Team,
cpufrequtils is going to be removed from Debian, and linux-cpupower is
a good replacement, see the comment in bug [#877016].

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

The only missing piece in linux-cpupower seems to be a systemd service
unit and a configuration file in /etc/default/ .

I took a look at how this is done in the [Arch Linux package]

[Arch Linux package]: 
<https://gitlab.archlinux.org/archlinux/packaging/packages/linux-tools>

It seems to me that three files (released under "GPL-2.0-or-later"
terms) can be used with trivial modifications.

The attached files are working fine on my system, where I purged
cpufrequtils and installed linux-cpupower and then I issued the
following commands:

  # cp cpupower.default /etc/default/cpupower
  # chown root:root /etc/default/cpupower
  # chmod 644 /etc/default/cpupower
  # cp cpupower.systemd /usr/libexec/cpupower
  # chown root:root /usr/libexec/cpupower
  # chmod 755 /usr/libexec/cpupower
  # cp cpupower.service /usr/lib/systemd/system/ 
  # chown root:root /usr/lib/systemd/system/cpupower.service
  # chmod 644 /usr/lib/systemd/system/cpupower.service
  # systemctl daemon-reload
  # systemctl enable cpupower.service

The systemd service runs at boot and sets everything needed with
cpupower (as configured in /etc/default/cpupower ).


Is there room for improvement?
Yes, I think there is.
For instance, the script /usr/libexec/cpupower could be translated to
POSIX shell, getting rid of its bashisms.
However, even with room for improvement, I think it's better than
nothing.

I believe it's time to fill this gap for good.
Please accept the "patch" and incorporate the files (or enhanced
versions of them) into linux-cpupower.

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


cpupower.default
Description: Binary data


cpupower.service
Description: Binary data


cpupower.systemd
Description: Binary data


pgpt69QGoeqKQ.pgp
Description: PGP signature

Bug#1072977: apt-listbugs 0.1.42 is broken

[Francesco Poli]

On Wed, 12 Jun 2024 10:53:15 +0200 Karine Crèvecœur wrote:

> On Wed, Jun 12, 2024 at 12:49:39AM GMT, Francesco Poli wrote:
[...]
> > For instance, if you have a web browser installed on the same system,
> > can you visit https://www.debian.org/ with your browser, without TLS
> > certificate issues?
> 
>  Yes, it works. I use https almost all of the time.I can ever donwload
>  index.html with:
>wget https://www.debian.org
> 
> It is very odd.

And can you visit (with a web browser) or download (with wget) this
very bug [log]?

[log]: <https://bugs.debian.org/1072977>



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


pgpC4Sln_vlZ0.pgp
Description: PGP signature

Bug#1072977: apt-listbugs 0.1.42 is broken

[Francesco Poli]

Control: tags -1 + unreproducible moreinfo


On Tue, 11 Jun 2024 10:27:33 +0200 Karine Crèvecœur wrote:

> Package: apt-listbugs
> Version: 0.1.42
> Severity: grave
> 
> 
> Hi,

Hello Karine,
thanks for caring about apt-listbugs!

> 
> Since the upgrade to version 0.1.42, apt-listbugs doesn't work anymore.

That's unfortunate.

However, I have tested apt-listbugs/0.1.42 for months, without ever
experiencing any issue like this.
And I am currently unable to reproduce the issue.

> 
> As examplen the command
> apt-listbugs list apt-lisbugs
> gave the error:
> 
> Retrieving bug reports... 0% Fail
> Error retrieving bug reports from the server with the following error message:
> E: SSL_connect returned=1 errno=0 
> peeraddr=[2605:bc80:3010:b00:0:deb:166:212]:443 state=error: certificate 
> verify failed (unable to get local issuer certificate)
> It could be because your network is down, or because of broken proxy servers, 
> or the BTS server itself is down. Check network configuration and try again

This command works on my boxes:

  $ apt-listbugs -v
  0.1.42
  $ apt-listbugs list apt-listbugs
  Retrieving bug reports... Done
  Parsing Found/Fixed information... Done
  grave bugs of apt-listbugs (→ ) 
   b1 - #1072977 - apt-listbugs 0.1.42 is broken
  Summary:
   apt-listbugs(1 bug)

> 
> 
> I downgrade apt-listbugs to the version 0.1.41-nmu1, it works just fine.
[...]
> I don't figure out why this issue occurs.

It seems that your system is unable to verify the TLS certificate of
https://bugs.debian.org

apt-listbugs/0.1.42 switched to https by default, that's why it now
needs to connect to the SOAP server via https.

Can you think of a reason why your system fails to verify the TLS
certificate of https://bugs.debian.org ?

You should have package 'ca-certificates' installed:

  $ apt policy ca-certificates
  ca-certificates:
Installed: 20240203
Candidate: 20240203
Version table:
   *** 20240203 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

I say that you should, since there's the following dependency chain:
apt-listbugs → ruby → ruby3.1 → rubygems-integration → ca-certificates

Are you able to verify other TLS certificates, when accessing other
sites via https?
For instance, if you have a web browser installed on the same system,
can you visit https://www.debian.org/ with your browser, without TLS
certificate issues?

Please let me know, so that we can try to debug the issue.


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


pgpNULiGv60DM.pgp
Description: PGP signature

Bug#1070343: closed by Debian FTP Masters (reply to Daniel Echeverri ) (Bug#1070343: fixed in openfortivpn 1.22.0-2)

[Francesco Poli]

On Thu, 16 May 2024 14:51:04 + Debian Bug Tracking System wrote:

[...]
>  openfortivpn (1.22.0-2) unstable; urgency=medium
>  .
>[ Bastian Germann ]
>* Disable legacy-pppd (Closes: #1070343)
[...]

Many thanks!   :-)
I can confirm that openfortivpn/1.22.0-2 works without any need to add
options to the pre-pppd-v2.5 configuration.

This is very appreciated.
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


pgp615DjVW0LR.pgp
Description: PGP signature

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&keywords=OVMF_CODE.fd&mode=path&suite=testing&arch=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 

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

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

[Francesco Poli]

: 2.13 GiB, 2281718784 bytes, 4456482 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: 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