[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Show new changelog entries from Debian package archives



Hi,

On Wed, Jun 30, 2021 at 06:13:14PM -0500, Brian Thompson wrote:
>   * Fix error message being thrown when choosing not to proceed on
>     confirmation (closes: #989496).

If I understand your fix correctly, you have broken the "no"
functionality as the Pre-Install-Pkgs hook has to fail for apt to
actually stop… if they are successful apt will continue with what it was
initially told to do, which seems not inline with what "no" was supposed
to accomplish… could you clarify?

(I don't know apt-listchanges code nor do I use the confirmation
 functionality of it, so I could easily be entirely wrong)

(That seems more like we should have a way for the hooks to tell apt to
 gracefully wind down, but that doesn't exist so far)


>   * Update maintainer to myself (closes: #981890).

Could I interest you in joining the apt-team and maintain listchanges as
part of it? I am personally not much help than it comes to python, but
Julian might. Mailing list is deity@lists.debian.org and/or you can join
our IRC channel #debian-apt.


I also note that your changelog targets unstable, which might be fine if
you want to fix the mentioned bug and consider it RC (I am not so sure),
but the churn in the package (= reflow of the pt.po and pot file) will
make the release team unhappy.


Looking at your git history, all this should not be in one single commit
either – individual commits with proper titles and metadata will help
you even: You wrote the changelog by hand, git-buildpackage can do this
for you if you had e.g. a commit ala:
>>>>>
Update maintainer to myself

Closes: #981890
<<<<<
As a bonus, a week later looking at the history you will still know at
a glance what happened without remembering (or looking up) cryptic
bugreport numbers first – not to mention others. With the data in place
you could then also add a hook to salsa which automatically sets
bugreports to pending after a push of the related commit and many more
fun stuff.

(It is of course not required, even many upstream projects use "fix #42"
 as commit message and are happy and successful. So if that works for
 you fine, I am just trying to nudge you to try an alternative which
 works better for me, many others and perhaps also you)


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: