Re: Mini-DebConf in Cambridge, UK - October 10-13 2024

[Jonathan Kamens]

Tone-policing people who complain about transphobia is inappropriate and 
makes the community less welcoming for trans and other marginalized people.


It is noteworthy that you complained about the author's tone but said 
nothing about the transphobia.


If you don't know enough about the situation to comment about the 
transphobia, then you should also refrain from comment about the tone.


On 6/24/24 6:59 AM, Alexandru Mihail wrote:

will not be attending Debcamp/Debconf at all this year last week of July/first 
week of August as I am tired of drama in the Debian community right now and 
sledge was being an asshole and banned me from OFTC for a month like the 
transphobic pig he is, however will be attending as an online visitor at GUADEC 
2024 in mid-July and resume my engagement in GNOME after this will also 
participate Online at Fedora's conference in the second week of August (but 
have no energy to fly to them on site this year in the USA) will however help 
at the openSUSE conference in Germany in 1 week and go to the guy in England in 
August, but 3-30th July I will be at home in Sweden and chill

Let's keep the discussion civil shall we ? You're sending mail to the Debian 
devel list which is read and parsed by many, many people and bots in a plethora 
of environments. This is not the right place for profanity. Take care

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

[Jonathan Kamens]

On 9/1/24 6:22 AM, Philip Hands wrote:

If you look at the repo on Salsa, and find:

   Settings > CI/CD > General Pipelines > CI/CD configuration file

you'll see it's set to:

   recipes/debian.yml@salsa-ci-team/pipeline

which is how the pipeline gets it's configuration.

The documentation is here:

   https://salsa.debian.org/salsa-ci-team/pipeline/

Even for the simplest configurations, I've concluded that it's better to
use the approach where one creates a `debian/salsa-ci.yml` file, and
points to it in the above mentioned setting.


I would be delighted to make this change, but I cannot, because for 
whatever reason Russ Allberry opted to make me a Developer on the 
project instead of a Maintainer so I can't see or modify its settings.


(This is also why I was unable to figure out where the pipeline setting 
was coming from: as a Developer, I can't see it.)


Over to you, Russ. ;-)

In any case, thank you to everyone who responded to my request for 
assistance. I was able to fix this Salsa pipeline problem by adding 
pybuild-plugin-pyproject to Build-Depends as suggested by Colin Watson.


However, the pipeline is still failing, now in reprotest. For example 
. 
Perhaps this is because I haven't yet finalized the changelog for the 
upcoming release so the trailer line is badly formatted. :shrug:


  jik

Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

[Jonathan Kamens]

Hey folks,

I had to step away from working on apt-listchanges 
 for quite a while 
(nearly a year), and upon stepping back into it today and pushing some 
changes to Salsa, I discovered that the build pipeline—which is 
configured outside my Salsa project so as far as I know I am unable to 
modify it—is failing. See, for example, this job 
, 
in particular (note the line in bold):


   ...
   |dh clean --with python3 --buildsystem=pybuild dh_auto_clean
   -O--buildsystem=pybuild I: pybuild base:311: python3.12 setup.py
   clean /usr/lib/python3/dist-packages/setuptools/__init__.py:88:
   _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are
   deprecated. !!
   

   Requirements should be satisfied by a PEP 517 installer. If you are
   using pip, you can try `pip install --use-pep517`.
   

   !! dist.fetch_build_eggs(dist.setup_requires) */usr/bin/python3.12:
   No module named pip* Traceback (most recent call last): ...|

Both debuild and sbuild work fine when I run this build locally, it's 
just the Salsa pipeline that's failing.


Any advice about what to do here to fix this?

Thanks,

jik


|
|||

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

[Jonathan Kamens]

On 9/2/24 4:09 AM, IOhannes m zmölnig (Debian GNU|Linux) wrote:

On 9/2/24 03:19, Jonathan Kamens wrote:
However, the pipeline is still failing, now in reprotest. For example 
<https://salsa.debian.org/debian/apt-listchanges/-/jobs/6215633#L1650>. 
Perhaps this is because I haven't yet finalized the changelog for the 
upcoming release so the trailer line is badly formatted. :shrug:




nope.
it's failing, because the .deb files are not identical.


I understand that.

I was suggesting that perhaps the root cause of /why/ the .deb files are 
not identical is because if there's no timestamp in the trailer line of 
the top changelog entry, that impacts the contents of the .deb.


And indeed, I just confirmed that theory. It appears that when there is 
a timestamp in the trailer line, the build process uses that timestamp 
as the modification time of all the files in the .deb, but if there's no 
timestamp, it uses the time when the build is run, so the timestamps are 
obviously going to be different for two sequentially run builds.


So I don't need about reprotest failing until I've finalized the 
changelog for release.


   jik

P.S. Wow, diffoscope has a /lot/ of dependencies. I understand why, but 
still... wow.

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

[Jonathan Kamens]

On 9/2/24 11:47 AM, Colin Watson wrote:

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote:

I was suggesting that perhaps the root cause of /why/ the .deb files are not
identical is because if there's no timestamp in the trailer line of the top
changelog entry, that impacts the contents of the .deb.

IMO your debian/changelog should be syntactically well-formed (per
https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog)
even when you haven't finalized it.  The exact value of the timestamp
isn't very important (you can let "dch" pick something when you first
add something to the unreleased changelog, and "dch -r" will update it
when you're ready to make an upload), but it should be present.  Leaving
it empty isn't the usual practice among other developers as far as I've
seen, and it's just making trouble for yourself.


I leave it empty exactly because the build scripts complain when I do 
that, so that I'll remember to finalize it with the correct date before 
I put out a release.


I also leave it empty to remind me to review the commit history and make 
sure there isn't anything I forgot to add to the changelog before I do 
the release.


If I put a placeholder date in it then the odds are that I'll forget to 
update it and the changelog will ship with a date that isn't what I 
wanted to ship with.


"isn't the usual practice among other developers" <-🤷 I've been doing 
this whole open source software maintenance thing for nearly 40 years. 
I'm kind of OK with sometimes doing things my own way rather than the 
way most other people do it.


"making trouble for yourself" <- It's the good kind of trouble, IMO. YMMV.

  jik

Kudos to everyone who has worked on the Debian build & packaging infrastructure

[Jonathan Kamens]

Hi all,

I set out this weekend to get up to speed on maintaining and packaging 
Debian packages and spent many hours reading documentation and playing 
around with the tooling surrounding building packages.


This prompted me to drop in here to say just how darned impressive 
everything is. The documentation is both helpful and extensive, and the 
tooling is just amazing. I could give example after example of the 
things that impressed me, but I'll spare your inboxes and mention just a 
few:


1) Debmake's ability to produce a mostly working control information 
file set from any random source tarball seems nearly magical.


2) It's amazing how easy it is to set up a chroot'd build environment 
and use it to test package builds, which is incredibly essential if for 
no other reason than because it makes it trivially easy to figure out 
what dependencies you need to list in your control file.


3) Lintian's ability to find and flag most of the issues that detract 
from package quality and may prevent it from being accepted is both 
impressive and useful.


I've been maintaining free software for 30 years so I've got a lot of 
experience with a lot of different tools, and I've rarely encountered 
anything that is as comprehensive and well-documented as all this stuff is.


To be sure, there's a huge amount to learn! But to me, at least, it 
doesn't seem like that's because there's a lot of cruft. On the 
contrary, the stuff that's there seems absolutely necessary to maintain 
high quality in Debian.


Thank you so much to everyone who has worked on this.

Regards,

Jonathan Kamens

Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag 
all at once by sending my explanation to ###-d...@bugs.debian.org with 
"Control: tags ### wontfix" as the first line of my message body. The 
bug was closed but the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer 
encoded the text/plain MIME body part with base64 because I had pasted 
into the body a quote from a web site that used non-ASCII quotation 
marks (d'oh). Is that why BTS failed to process the "Control:" command?


If yes, then is this a known thing that's not going to change that I 
should just live with ;-), or should I file a bug about it?


If no, then can anyone tell me what else I did wrong to cause the 
"Control:" command not to be processed?


Thanks,

jik

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?


On 9/25/23 09:06, Peter B wrote:

On 25/09/2023 12:16, Jonathan Kamens wrote:


Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag 
all at once by sending my explanation to ###-d...@bugs.debian.org 
with "Control: tags ### wontfix" as the first line of my message 
body. The bug was closed but the tags command wasn't processed.


Looking at the raw message file that I sent, I see that my mailer 
encoded the text/plain MIME body part with base64 because I had 
pasted into the body a quote from a web site that used non-ASCII 
quotation marks (d'oh). Is that why BTS failed to process the 
"Control:" command?


If yes, then is this a known thing that's not going to change that I 
should just live with ;-), or should I file a bug about it?


If no, then can anyone tell me what else I did wrong to cause the 
"Control:" command not to be processed?


Thanks,

jik



see
https://www.debian.org/Bugs/server-refcard

It should be
tags bugnumber + wontfix

sent to cont...@bugs.debian.org

best to have
package foo

on the first line in case of typos in the bug number!

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

According to https://www.debian.org/Bugs/server-control#tag the plus is 
optional.


Once again, my question was, should a valid Control: header on the first 
line of an email message sent to ###-d...@bug.debian.org work, and if 
so, is the reason why it didn't work in my case because the MIME part it 
was included in was base64-encoded, and if not, what other reason could 
explain why it didn't work?


I did find this here <https://wiki.debian.org/HowtoUseBTS> after I 
emailed the list:


   QUESTION: Can you do all the control-server actions by using fields
   in a pseudo header in an email to bugnumber@b.d.o
   <mailto:bugnumber@b.d.o> or do you need to use control@b.d.o
   <mailto:control@b.d.o>?

   ANSWER: You need to use the explicit control@ mail copy, automatic
   parsing isn't done. From what I understood it's worked on but it
   might take a bit to make it reliable and not catch something it
   shouldn't.

So, if this is correct, then I apparently what I tried to do just 
doesn't work. :shrug:


On 9/25/23 09:44, Peter B wrote:

On 25/09/2023 14:25, Jonathan Kamens wrote:


So putting a Control: line in the pseudo-header of a message sent to 
###-d...@bugs.debian.org doesn't work at all?




It should work if the syntax is correct. The + character was missing.

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

...and I just successfully used a Control: header in an email to 
###@bugs.debian.org, so the only question remaining in my mind is 
whether the one that didn't work failed because it was sent to ###-done, 
or failed because of the base64 encoding. I can't think of any other 
reasons why the Control: header would have been ignored.

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Thank you! A canonical answer at last.

On 9/25/23 10:53, Andrey Rakhmatullin wrote:

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:

I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.debian.org with "Control:
tags ### wontfix" as the first line of my message body. The bug was closed
but the tags command wasn't processed.

It doesn't work for NNN-done@ according to
https://www.donarmstrong.com/posts/control_at_submit/

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

Closed bugs are available for direct search for 30 days after they're 
closed.


After that you can still search them by selecting either "Archived" or 
"Archived and Unarchived" under "Misc Options" on the search page.


All that aside, in this particular case I closed the bug because it 
wasn't actually a bug, but rather a PEBKAC issue (user complaining that 
a program wasn't respecting his locale when he had LC_ALL set to "C" so 
he was essentially telling the program to ignore his locale).


  jik

On 9/25/23 12:13, Marvin Renich wrote:

* Jonathan Kamens  [230925 07:17]:

Hi all,

I recently tried to close a bug, explain why, and set a "wontfix" tag all at
once by sending my explanation to ###-d...@bugs.debian.org with "Control:
tags ### wontfix" as the first line of my message body. The bug was closed
but the tags command wasn't processed.

I've seen differing opinions about closing "wontfix" bugs, but as a
user, I appreciate when they are left open.  Whether it is a simple
wishlist feature request or a crash when the user abuses the software,
if I go to file the same or similar bug at a later time, if the bug is
closed I will not see it and file a duplicate.  If it is left open, I
can see the maintainer has already thought about it and intentionally
decided not to fix it, so I can save the trouble of refiling.  Also, I
might gain some insight about the circumstances.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Jonathan Kamens]

The documentation you inked to does not specify a tag that can be used 
specifically to mark something as not actually a bug.


That documentation does say the following about the "wontfix" tag 
(*/emphasis/* added by me):


   |wontfix|
   This bug won't be fixed. Possibly because this is a choice
   between two arbitrary ways of doing things and the maintainer
   and submitter prefer different ways of doing things, possibly
   because changing the behaviour will cause other, worse, problems
   for others, or */possibly for other reasons./*

"I don't consider this a bug" seems, to me, to fit under "other reasons."

Is there some harm that is done by marking a bug that falls into this 
category with "wontfix"?


  jik

On 9/25/23 13:40, Andrey Rakhmatullin wrote:

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote:

All that aside, in this particular case I closed the bug because it wasn't
actually a bug, but rather a PEBKAC issue (user complaining that a program
wasn't respecting his locale when he had LC_ALL set to "C" so he was
essentially telling the program to ignore his locale).

wontfix is a wrong tag for such bugs according to
https://www.debian.org/Bugs/Developer#tags  though.

sbuild can't find piuparts even when it's listed in build dependencies

[Jonathan Kamens]

I'm trying to use sbuild to build my package, and it's failing to find 
piuparts:


| Post Build   |
+--+


piuparts


sudo: piuparts: command not found

E: Piuparts run failed.

I tried adding it to Build-Depends but that didn't help.

My best guess is that the issue here is that piuparts is installed in 
/sbin and /sbin isn't in the default sudo path, but that would imply 
that there's a bug in the build tools rather than that I'm doing 
something wrong, and I think the latter is more likely. ;-)


I'm on Bookworm.

Any tips?

Thanks.

Re: sbuild can't find piuparts even when it's listed in build dependencies

[Jonathan Kamens]

On 9/26/23 10:24, Johannes Schauer Marin Rodrigues wrote:

piuparts is run outside the build chroot, not inside of it.

Thanks, that's useful info.

My best guess is that the issue here is that piuparts is installed in /sbin
and /sbin isn't in the default sudo path, but that would imply that there's a
bug in the build tools rather than that I'm doing something wrong, and I
think the latter is more likely. ;-)

I'm on Bookworm.

Any tips?

do you have piuparts installed outside the chroot?

Yes. Still not working.

If you are having problems with sbuild, you can also always file a bug against
sbuild in the BTS.


Yes, but I would rather first make sure I'm not doing something stupid 
before I clutter BTS with what would turn out to be a "support ticket" 
rather than a bug if in fact this is user error.


But I suppose that's what I will have to do if no one on this list can 
tell me why sbuild is failing to find piuparts.


  jik

Please test apt-listchanges 4.0 in experimental

[Jonathan Kamens]

Hello friends,

I've adopted apt-listchanges and pushed a new version, 4.0, to 
experimental, with a bunch of fixes in it. Given how extensive the 
changes are, I'd appreciate some testing from folks here before it gets 
promoted to unstable. This package is widely used so it's kind of 
important for us to get this right. ;-)


You can view the changelog.Debian.gz in the deb itself or here 
<https://salsa.debian.org/debian/apt-listchanges/-/blob/4.0/debian/changelog>.


One thing you may notice is that because the method of tracking which 
changelogs the user has already seen (see here 
<https://salsa.debian.org/debian/apt-listchanges/-/blob/4.0/doc/design_notes/what_to_display.md> 
or /usr/share/doc/apt-listchanges/what_to_display.html in the deb for 
details), the database needs to be populated with data for existing 
packages during upgrades, so the first time a package is upgraded after 
the switch to the new method, it will be slightly slower. I have a plan 
for addressing that but it hasn't been implemented yet (and indeed, 
requires advice from folks here for me to get it right, so I'll be 
sending another message after this one to ask for that advice).


Also, I'm still waiting on some translations, so you may notice some 
English strings in foreign locales. There is no need to report this to 
me, I'm aware.


Please file bugs, reply in this thread, or email me privately with any 
feedback as you deem appropriate. If you try it out and everything's 
fine and you can take a moment to email me and let me know that as well, 
I'd appreciate it, since that'll give me confirmation that it's gone 
through some testing by people other than me.


Thank you,

Jonathan Kamens

What's the best way to run a background check after package installation?

[Jonathan Kamens]

For the new changelog filtering logic in apt-listchanges, I'd like to 
run a background job after the package finishes installing to populate 
the seen database with the most recent current changelog and NEWS 
entries for all installed packages, so they don't have to be populated 
at package upgrade time. This will significantly improve the user 
experience in terms of reducing the time it takes to display changes 
during upgrades. It should only need to be run once on any system.


I don't want this to run synchronously during installation because it'll 
take a long time and there's no need.


The simplest solution is to launch the job in postinst and daemonize it 
so it keeps running even after the upgrade finishes. However, that's not 
correct since if the user reboots after the upgrade it'll kill the job.


The other idea I had was to install and enable a systemd timer that 
attempts to run the job hourly after installation, and then have the job 
disable the timer when it completes successfully.


Is there a better / different / "Debian standard" way to accomplish this?

Thanks,

Jonathan Kamens

P.S. Just for the record, the background job will checkpoint its 
progress periodically so it doesn't have to redo all the work if it gets 
killed in the middle, and it'll checkpoint and pause whenever the load 
average goes above 1 to minimize its performance impact on the system.

Is there a generic canonical way for a package script to check network connectivity?

[Jonathan Kamens]

I need to be able to tell from one of my package scripts whether the 
host has networking connectivity.


I know I can call `nmcli networking connectivity` but that's only valid 
if NetworkManager is in use. How reasonable is it for me to assume that 
NetworkManager is in use? Is there a more generic, canonical way to do 
this check?


Thanks,

Jonathan Kamens

Re: Is there a generic canonical way for a package script to check network connectivity?

[Jonathan Kamens]

Thanks to everyone for the useful feedback. Some additional info and 
comments:


I'm well aware that this is a hard problem and that just calling nmcli 
is not an adequate solution. I was asking whether the problem has 
already been solved in a Debian-canonical way, since there are lots of 
other problems of this sort which do have such canonical solutions. 
Judging from the responses, it appears that the answer to that question 
is no.


Regarding what I'm trying to accomplish, as part of the revamp of 
apt-listchanges I need to rebuild the database that apt-listchanges uses 
to determine which changelog and NEWS entries it has already shown to 
the user. This can mostly be done from files installed on the local 
machine, but not for packages which don't ship a changelog.Debian file 
and instead expect the user to fetch it over the network with "apt 
changelog". Ideally I would be able to run a script in the background 
which gradually fetches these and adds them to apt-listchanges's database.


Ideally I would be able to simply attempt to fetch the each required 
changelog over the network and distinguish between "The fetch failed 
because there is no network changelog for this package" and "The fetch 
failed because it's not accessible over the network right now", but I 
can't make that distinction because neither apt nor python3-apt informs 
the user about what went wrong in any way that the caller can use reliably.


I've come up with a different workaround for this edge case which will 
do the right thing most of the time, but there are still going to be a 
few cases where, because I can't populate the database in advance, when 
the user goes to update a package they're going to end up getting shown 
the entire network changelog rather than just the new entries, because 
apt-listchanges can't reliably determine which entries they've already seen.


  jik

Re: Is there a generic canonical way for a package script to check network connectivity?

[Jonathan Kamens]

I would be delighted to punt the network changelog fetching 
functionality from apt-listchanges entirely, but I want to make 100% 
certain there's no context in which it's needed before I do that.


Here's the NEWS entry from when this functionality was added in 2017:

apt-listchanges (3.14) unstable; urgency=low

  When displaying changelogs during upgrades is enabled, but no changelog
  file is provided by any of binary packages being processed together, then
  apt-listchanges will call `apt-get changelog' command to retrieve changes
  over network.  (Similar functionality has existed in Ubuntu for ages, and
  was incorporated into Debian a few versions ago.)

  If for some reason, like limited network connectivity, this behavior
  is undesirable, it can be now disabled with the new `--no-network' option
  that can be also set using debconf interface:

 dpkg-reconfigure apt-listchanges


  Additionally the debconf interface was improved to manage a few older
  configuration options, for example `--email-format'.

 -- Robert Luberda   Sun, 09 Jul 2017 09:55:48 +0200

So, the question is: is there something Russ said below that's true now 
but wasn't true back in 2017, such that this functionality was necessary 
then but isn't now; or were we mistaken back in 2017 when we thought 
this functionality was necessary; or is there something Russ said below 
that doesn't hold up such that actually we still need this?


What about providers of Debian packages and apt repositories other than 
Debian itself? Don't we need to worry that there may be packages and 
repositories out there that provide network changelogs but don't include 
them in their packages? I don't think we want to simply not display 
changelogs for such packages, do we?


  jik

On 10/9/23 16:39, Russ Allbery wrote:

Jonathan Kamens  writes:


Regarding what I'm trying to accomplish, as part of the revamp of
apt-listchanges I need to rebuild the database that apt-listchanges uses
to determine which changelog and NEWS entries it has already shown to the
user. This can mostly be done from files installed on the local machine,
but not for packages which don't ship a changelog.Debian file and instead
expect the user to fetch it over the network with "apt changelog".

Based on some other private conversation, I think there may be an
underlying misunderstanding here, which is quite inobvious if you're just
looking at Debian packages without having read all the previous
discussions that got us here.

Either that, or I have some incorrect assumptions, and someone should
correct me.  :)

I believe that the following statements are true:

Every Debian package either ships changelog.Debian or symlinks its doc
directory to another package that ships changelog.Debian.  In the latter
case, that is a declaration that the package has no unique changelog
entries and its changelog is always and exactly the changelog of the other
package.  (This is used to deduplicate files among packages that are
always built together from the same source and are usually installed
together.)  So there are no packages in Debian that expect the user to
fetch the changelog over the network; the changelog is always guaranteed
to be part of the content installed on disk.  It can just be indirected
through another package (if the packages follow some strict limitations).

What *does* happen is that some packages (well, all packages that have
been rebuilt with current debhelper, I think) have *truncated* changelogs,
in order to prevent the changelog from wasting a lot of disk space with
old entries, and the *full* changelog is only available via the network.
But the guarantee for truncated changelogs is that all entries newer than
the release date of oldstable are retained, so since Debian doesn't
support skip-version upgrades, apt-listchanges should never need the
content that is dropped by truncation.

In other words, the intent is to guarantee that all the information that
apt-listchanges needs is present on disk, but it would have to deal with
the /usr/share/doc symlinks.

apt-listchanges: appropriate heuristic for ignoring sub-packages with symlinked /usr/share/doc directories

[Jonathan Kamens]

As Russ noted in his recent message, it may be safe to optimize 
apt-listchanges by having it ignore packages which don't install any 
actual files in /usr/share/doc and which create a /usr/share/doc symlink 
pointing at another package.


I am therefore am considering adding the following heuristic to the 
program: ignore a package in apt-listchanges if it meets the following 
conditions:


 * binary package name different from source name
 * deb contains no changelog or NEWS files in /usr/share/doc
 * creates a symlink in /usr/share/doc with the binary package name as
   its name, pointing at another directory in /usr/share/doc

It is possible that this heuristic will fail to ignore some packages 
which we could have safely ignored, but I think it'll catch most of 
them, and my primary goal is that whatever heuristic it uses should 
/not/ ignore a package that should have been checked for entries to show 
the user. I.e., it's more important for the program to show the user 
everything they should see than for it to do less work.


I'm interested in any feedback that anyone has about whether this is a 
safe heuristic to use.


I did a quick analysis of what's in /usr/share/doc on my machine, and 
based on that analysis the following packages that create only links in 
/usr/share/doc would be ignored under this heurstic: binutils-multiarch, 
binutils-x86-64-linux-gnu, bogofilter, bogofilter-bdb, 
console-setup-linux, cpp-12, cpp-13, cups-bsd, db5.3-util, debconf-i18n, 
debconf-utils, default-jdk-headless, default-jre, emacs-gtk, 
firebird3.0-common, firebird3.0-server-core, firebird3.0-utils, g++, 
g++-12, g++-12-multilib, g++-13, g++-13-multilib, g++-multilib, gcc, 
gcc-12-multilib, gcc-13-multilib, gcc-multilib, gfortran, gfortran-12, 
gfortran-13, grub-pc, grub-pc-bin, grub2-common, iamerican, ibritish, 
klibc-utils, lib32asan8, lib32atomic1, lib32gcc-12-dev, lib32gcc-13-dev, 
lib32gcc-s1, lib32gomp1, lib32itm1, lib32quadmath0, lib32stdc++-12-dev, 
lib32stdc++-13-dev, lib32stdc++6, lib32ubsan1, libasan8, libatomic1, 
libbinutils, libbz2-dev, libcc1-0, libctf0, libdatrie-dev, libfbclient2, 
libffi-dev, libgcc-12-dev, libgcc-13-dev, libgcc-s1, libgccjit0, 
libgfortran-12-dev, libgfortran-13-dev, libgfortran5, libgomp1, 
libgprofng0, libhwasan0, libib-util, libitm1, liblsan0, libltdl-dev, 
libncurses-dev, libncurses6, libncursesw6, libobjc-13-dev, libobjc4, 
libparted-fs-resize0, libprotobuf-dev, libpython3-all-dev, 
libpython3.11, libpython3.11-dev, libpython3.11-stdlib, libquadmath0, 
libreadline-dev, libstdc++-12-dev, libstdc++-13-dev, libstdc++6, 
libthai-dev, libtsan2, libubsan1, libvirt-clients, libvirt-l10n, 
libx32asan8, libx32atomic1, libx32gcc-12-dev, libx32gcc-13-dev, 
libx32gcc-s1, libx32gomp1, libx32itm1, libx32quadmath0, 
libx32stdc++-12-dev, libx32stdc++-13-dev, libx32stdc++6, libx32ubsan1, 
linux-headers-amd64, linux-image-amd64, manpages-dev, 
openjdk-17-jdk-headless, openjdk-17-jre, openssh-server, 
openssh-sftp-server, p11-kit-modules, p7zip-full, python3-all, 
python3-all-dev, python3-debconf, python3-dev, python3-venv, 
python3-yubikey-manager, python3.11-dev, python3.11-venv, 
qemu-system-x86, r-base-dev, r-recommended, task-desktop, task-english, 
task-gnome-desktop, task-kde-desktop, task-laptop, task-ssh-server, 
tasksel-data, tlp-rdw, tre-agrep


The following packages which create a symlink and nothing else in 
/usr/share/doc would /not/ be ignored:


 * Binary package name not different from source: console-setup,
   gcc-12, gcc-13, groff, kmod, node-source-map, node-sprintf-js,
   parted, v4l-utils
 * Link name different from package name: wpasupplicant

Thanks,

jik

Re: apt-listchanges: appropriate heuristic for ignoring sub-packages with symlinked /usr/share/doc directories

[Jonathan Kamens]

On 10/10/23 02:18, Simon Richter wrote:

On 10/10/23 06:24, Jonathan Kamens wrote:


  * binary package name different from source name
  * deb contains no changelog or NEWS files in /usr/share/doc
  * creates a symlink in /usr/share/doc with the binary package name as
    its name, pointing at another directory in /usr/share/doc


I'd go an easier way: if the changelog is a symlink, its target is the 
changelog to use, so the same changelog (with the same file name) will 
be used by multiple packages, and all that's left is to deduplicate 
this list.


The new version of apt-listchanges already deduplicates. The main point 
of the logic revamp I did was to add such deduplication instead of 
relying on version numbers to determine what to show the user.


Having said that, it doesn't make sense to do what you're proposing. If 
a package doesn't have any changelog files in it, but rather just a 
symlink to another package's changelog files, then those changelog files 
will have already been parsed by apt-listchanges and displayed to the 
user when the package that owns them was installed. As far as I can see 
the only thing that would be accomplished by doing what you suggest 
would be to make apt-listchanges slower, since it would have to locate 
and reparse all those changelog files, only to discover that their 
contents have already been displayed to the user.


  jik

Re: Please test apt-listchanges 4.0 in experimental

[Jonathan Kamens]

N.B. apt-listchanges has been upgraded to 4.1 in experimental with some 
significant fixes, so if you're testing 4.0, please upgrade to 4.1, and 
if you're not testing yet, what are you waiting for? ;-)


Thanks to everyone who has tested and helped identify the issues fixed 
in 4.1!


Thanks,

jik

On 10/8/23 11:27, Jonathan Kamens wrote:


Hello friends,

I've adopted apt-listchanges and pushed a new version, 4.0, to 
experimental, with a bunch of fixes in it. Given how extensive the 
changes are, I'd appreciate some testing from folks here before it 
gets promoted to unstable. This package is widely used so it's kind of 
important for us to get this right. ;-)


You can view the changelog.Debian.gz in the deb itself or here 
<https://salsa.debian.org/debian/apt-listchanges/-/blob/4.0/debian/changelog>.


One thing you may notice is that because the method of tracking which 
changelogs the user has already seen (see here 
<https://salsa.debian.org/debian/apt-listchanges/-/blob/4.0/doc/design_notes/what_to_display.md> 
or /usr/share/doc/apt-listchanges/what_to_display.html in the deb for 
details), the database needs to be populated with data for existing 
packages during upgrades, so the first time a package is upgraded 
after the switch to the new method, it will be slightly slower. I have 
a plan for addressing that but it hasn't been implemented yet (and 
indeed, requires advice from folks here for me to get it right, so 
I'll be sending another message after this one to ask for that advice).


Also, I'm still waiting on some translations, so you may notice some 
English strings in foreign locales. There is no need to report this to 
me, I'm aware.


Please file bugs, reply in this thread, or email me privately with any 
feedback as you deem appropriate. If you try it out and everything's 
fine and you can take a moment to email me and let me know that as 
well, I'd appreciate it, since that'll give me confirmation that it's 
gone through some testing by people other than me.


Thank you,

Jonathan Kamens

Re: Please test apt-listchanges 4.0 in experimental

[Jonathan Kamens]

On 10/11/23 03:37, Alexandre Detiste wrote:

Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens  a écrit :

I'd appreciate some testing from folks here before it gets promoted to unstable.

I got important NEWS from libx11 from  2006 (?)
so far so good for the rest.
Can you confirm that this occurred with 4.0 rather than 4.1? There's a 
bug-fix for at least one case of this in 4.1, but if you encountered 
this with 4.1 then perhaps there is another bug with the same symptoms 
that hasn't been fixed yet.

the database needs to be populated with data for existing packages during 
upgrades

Having a "solid" .timer forever for a single-time task seems a bit too much.
Could this be done a different way with "systemd-run"
or a .timer generated in /run/systemd/system ?
I believe both of these don't persist past a reboot. This needs to 
persist after reboot since rebooting immediately after an upgrade is common.

* Code cleanup and improvement, including `flake8' and `pylint'
   compatibility, (some) unit tests, and adherence to newer standards and
   best practices.

Can annotations/mypy testing be considered now "best practices" for
Debian native packages ?


Best practice? Sure. Requirement? Not so much.

Regarding apt-listchanges in particular, I have already spent countless 
hours getting ready for this new release, including the addition of a 
substantial unit-test suite where there were no tests before. I do not 
have the bandwidth to add type hints as well, and I do not think this 
should be a blocker to releasing the new version to the public.


I am happy to consider a MR if someone else wants to add typing to the 
code-base.


  jik

apt-listchanges testers: new version (4.2) is available, please note these changes

[Jonathan Kamens]

Version 4.2 of apt-listchanges is now available in experimental. Please 
test.


Three important notes:

1) There was a bug in 4.1 that caused corruption in the database of 
previously seen changelog entries (sorry!). The bug has been fixed, but 
the corruption was too complex to be recoverable, so 4.2 erases the 
database and starts from scratch. It will work just fine, but if you 
want to speed up future updates you can run "systemctl start 
apt-listchanges.timer" after upgrading to 4.2 to force it to rebuild the 
database from installed packages in the background. Make sure to keep 
your computer running for a couple hours, though if you do need to 
reboot you can just start it again afterward since it's idempotent.


2) I want to give a shout-out to Alexandre Detiste for his help starting 
to add typing hints to the apt-listchanges code-base, which is how the 
aforementioned bug was found.


3) To facilitate easier future debugging of issues like the one that was 
introduce in 4.1, 4.2 introduces a new snapshot feature which is only 
live in experimental builds. Each time apt-listchanges runs it captures 
a snapshot of a few data files (e.g., its database at the beginning and 
end of the run, /var/lib/dpkg/status, the news and changelog entries 
that were displayed to the user, the list of debs that were parsed for 
changelog entries). Up to the last 7 snapshots are saved. If you end up 
running into an issue I may ask you to send me the relevant snapshots to 
help me troubleshoot. If you prefer you can disable the snapshots by 
setting capture_snapshots to false in /etc/apt/listchanges.conf. 
However, if you leave it set to "auto", which is the value it will get 
by default, then it will automatically be removed from the config file 
and the old snapshots purged when you upgrade to a non-experimental 
version of apt-listchanges.


Please let me know if you have any questions or concerns or run into any 
issues.


Thanks!

jik

New apt-listchanges in experimental, please test

[Jonathan Kamens]

Version 4.4 of apt-listchanges is now available for testing in 
experimental (N.B., we released 4.3 and 4.4 a day apart because 
something came up last-minute, so make sure to `apt update` before 
installing so you get 4.4). It has both functional changes and bug fixes 
in it.


Most notably, we've added version-number-based filtering of changelog 
entries for local changelog files, whereas before it was being used only 
for network changelogs. (Note that the version-number-based filtering in 
this version of apt-listchanges is more cautious than the filtering in 
3.27, to minimize the likelihood of failing to show the user something 
they should have seen.)


In addition, there is a performance improvement when displaying both 
news and changelogs.


Other changes are documented in the package's changelog.Debian.gz should 
you wish to review them.


I am hoping this release is stable enough to build/release to unstable 
after some end-user testing without any additional changes. We'll see!


Thank you,

Jonathan Kamens

Re: What would help the most?

[Jonathan Kamens]

Hello Lucas,

I think the reason why people are puzzled and hesitant to reply is that 
your inquiry seemingly came out of nowhere and you've offered no context 
for it. Why is this question being asked? Why are you the person asking 
it? What are you going to do with the responses?


People are understandably suspicious when someone asks somewhat weird 
questions out of the blue with no explanation for why.


If you want people to answer, I suggest you explain better what's going 
on here.


  jik

On 10/30/23 16:10, Lukasz Szybalski wrote:





Paul, Marc, Andrey
Thanks for replying.


To narrow it down:


This is a serious question and I would like a serious response.

Look back on the last 3 months of work you did @ debian or in salsa or 
bts or lists, and ask yourself.
What would be the minimal thing that would help you accomplish or make 
an even bigger impact at Debian but for you? (the Debian Developer)

What would it be?


Thank you
Lucas Szybalski
from Chicago IL
https://www.linkedin.com/in/lucas-szybalski/


*Vision of Debian:*
Create a free operating system, freely available for everyone.

*Goal:*
Coding and Maintaining Packages 
Testing and Bug Squashing 

/In these 2 goals:/
What is the minimum most valuable thing that would help YOU
accomplish your goals for Debian ?


Thanks
Lucas

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Jonathan Kamens]

I think even "ssh-h3" is a confusing and frankly impudent name. The creator of 
this new package appears to be intentionally trying to use the ubiquity of the 
ssh "brand" to their benefit. This brand confusion can only harm end users and 
I do not think Debian should facilitate it.

Even something as simple as naming it h3sh would have avoided the brand 
confusion while communicating the purpose of the package. This does not appear 
to be a case of "unknowing infringement." It appears to be intentional.

Regardless of whether or not that's so, it is harmful and should be fixed.

Jik

On December 30, 2023 2:02:56 PM EST, Marvin Renich  wrote:
>* Simon Josefsson  [231230 11:54]:
>> One alternative that was suggested was to call the package something
>> else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
>> as long as the 'ssh3' name is in there.
>
>There is no reason the package (source and binary) can't be named ssh-h3
>even if the binary is not renamed.  I would not keep the "ssh3" part in
>the package name.
>
>...Marvin
>

-- 
Sent from my phone. Please excuse brevity and autocorrect errors.

Re: Teléfono Samsung: no puedo borrar el idioma Alemán

[Jonathan Kamens]

I don't want to exacerbate the off-topic-message problem, but I'm hoping 
that by saying the following I may perhaps be able to prevent further 
messages to the list about this.


First, can we please be very careful, when we're throwing around talk 
about banning people from lists, to make it clear whom we're referring 
to? Holger, I assume you were referring to José Luis González, but you 
left that vague, and the message you were replying to was from someone 
different, Jose Luis Alarcon Sanchez, who has done nothing to merit banning.


Second, if you have concerns with the conduct of someone on the list, 
and you don't believe it would be necessary or appropriate to raise 
those conerns with them directly (and I agree, in this particular case 
it probably is not), the right thing to do is not to raise your concerns 
on the list, but rather to reach out to the Debian community team 
 at commun...@debian.org.


Thank you.

On 4/21/24 16:53, Holger Wansing wrote:

Could this guy be blacklisted from Debian lists, please?



Am 21. April 2024 22:23:10 MESZ schrieb Jose Luis Alarcon 
Sanchez:

On abr. 21 2024, at 10:02 pm, José Luis González González
  wrote:


En mi teléfono móvil Samsung Galaxy A13 no puedo borrar ahora el
idioma Alemán del telclado y la corrección ortográfica.
  

Y que puede tener esto que ver con Debian o con Linux???. Llévalo a un
punto de Servicio Técnico de Samsung.

Re: spurious autoremovals due to python3-nose

[Jonathan Kamens]

Can you clarify why you are describing these autoremoves as "spurious"? Isn't 
this just the dependency system working the way it is supposed to?

jik

On September 27, 2024 4:07:07 AM EDT, Alexandre Detiste 
 wrote:
>Hi,
>
>"nose" is RC buggy. It was until a few days ago in the "key packages set".
>
>After recent upload of piuparts, nose dropped out of the key package set,
>as expected.
>
>What was not expected is that nose started the autoremoval counter of
>seemingly ~700 unrelated packages.
>
>https://udd.debian.org/cgi-bin/autoremovals.cgi
>
>How this does work :-| ?
>
>Greetings,
>
>Alexandre

-- 
Sent from my phone. Please excuse brevity and autocorrect errors.

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

[Jonathan Kamens]

On 12/27/24 7:34 AM, Geert Stappers wrote:

Yeah, it feels wrong that dpkg gets file system code, gets code for one
particular file system.


I disagree. If there is a significant optimization that dpkg can 
implement that is only available for btrfs, and if enough people use 
btrfs that there would be significant communal benefit in that 
optimization being implemented, and if it is easiest to implement the 
optimization within dpkg as seems to be the case here (indeed, it may 
/only/ be possible to implement the optimization within dpkg), then it 
is perfectly reasonable to implement the optimization in dpkg. Dpkg is a 
low-level OS-level utility, it is entirely reasonable for it to have 
OS-level optimizations implemented within it.


  jik