Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #109494 > unrolled thread

Please test apt-listchanges 4.0 in experimental

Back to article view | Back to linux.debian.devel

Contents

  Please test apt-listchanges 4.0 in experimental Jonathan Kamens <jik@kamens.us> - 2023-10-08 17:30 +0200
    Re: Please test apt-listchanges 4.0 in experimental Jonathan Kamens <jik@kamens.us> - 2023-10-10 15:50 +0200
    Re: Please test apt-listchanges 4.0 in experimental Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-10-11 09:40 +0200
      Re: Please test apt-listchanges 4.0 in experimental Jonathan Kamens <jik@kamens.us> - 2023-10-11 15:00 +0200
        Re: Please test apt-listchanges 4.0 in experimental Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-10-11 21:40 +0200

#109494 — Please test apt-listchanges 4.0 in experimental

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#109516

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#109525

Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens <jik@kamens.us> 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.


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


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

I see that testing of apt-listchanges would benefit from having
python3-debconf typed first.

I personally find annotations very usefull when handing over old, big codebases
to some new team who doesn't have the expected input type of function
in their head.
It also helps clean-up things that were jurry rigged for python2+3
compatibility. (bytes/str...)


I'm tempted to add for myself a RSS generator to apt-listchanges
on a private branch and see where it goes,
but would first would like it to be typed.

Greetings

[toc] | [prev] | [next] | [standalone]

#109528

[Multipart message — attachments visible in raw view] — view raw

On 10/11/23 03:37, Alexandre Detiste wrote:
> Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens<jik@kamens.us>  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

[toc] | [prev] | [next] | [standalone]

#109530

Le mer. 11 oct. 2023 à 14:54, Jonathan Kamens <jik@kamens.us> a écrit :
> Can you confirm that this occurred with 4.0 rather than 4.1?
I'm a bit messy & forgetful these times.
But you have #1053812 against 4.1 already.

> > Can annotations/mypy testing be considered now "best practices" for
> > Debian native packages ?
>
> Best practice? Sure. Requirement? Not so much.

Of course it's not a requirement;
and it can be done iteratively.


> 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 see it, and it's nice work.

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

This is why I propose to do it.

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

There's a first MR pending.

There's another one against python3-debconf with 100% "mypy --strict" coverage.

I just don't  know how to handle the "py.typed" there: it's a flag
file, contents doesn't matter.
It could be a "touch" in debian/rules, I just don't know what is the
prefered way.

Greetings

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web