Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

75%
+4 −0
Q&A Retrieve changes that closed a Debian bug

If a Debian bug number is referenced in the changelog of an uploaded package, it is automatically closed with a generic message: We believe that the bug you reported is fixed in the latest versi...

2 answers  ·  posted 1y ago by Quasímodo‭  ·  last activity 10mo ago by tripleee‭

Question debian
#3: Post edited by user avatar Quasímodo‭ · 2022-09-29T18:19:54Z (over 1 year ago)
Add reference for bug closure syntax
  • If a Debian bug number is referenced in the changelog of an uploaded package, it is automatically closed with a generic message:
  • > We believe that the bug you reported is fixed in the latest version of
  • [package], which is due to be installed in the Debian FTP archive:
  • [Random example](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528167).
  • This message also contains the new changelog entries, which helps having an idea of what was fixed, but is not as insightful as seeing the whole changes under `debian/`, especially if a patch was created or updated.
  • Is there a convenient way to get the full changes that caused a given bug to be closed?
  • The only solution I could think of is going to https://snapshot.debian.org/package/poppler (using `poppler` as a package example), picking the corresponding two versions' debian.tar.xz files, unpacking them and comparing the directories, which looks quite cumbersome.
  • If a Debian bug number is referenced in the changelog of an uploaded package, it is [automatically closed](https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-bugfix) with a generic message:
  • > We believe that the bug you reported is fixed in the latest version of
  • [package], which is due to be installed in the Debian FTP archive:
  • [Random example](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528167).
  • This message also contains the new changelog entries, which helps having an idea of what was fixed, but is not as insightful as seeing the whole changes under `debian/`, especially if a patch was created or updated.
  • Is there a convenient way to get the full changes that caused a given bug to be closed?
  • The only solution I could think of is going to https://snapshot.debian.org/package/poppler (using `poppler` as a package example), picking the corresponding two versions' debian.tar.xz files, unpacking them and comparing the directories, which looks quite cumbersome.
#2: Post edited by user avatar Quasímodo‭ · 2022-09-28T17:40:00Z (over 1 year ago)
Provide example
  • If a Debian bug number is referenced in the changelog of an uploaded package, it is automatically closed with a generic message:
  • > We believe that the bug you reported is fixed in the latest version of
  • [package], which is due to be installed in the Debian FTP archive:
  • This message also contains the new changelog entries, which helps having an idea of what was fixed, but is not as insightful as seeing the whole changes under `debian/`, especially if a patch was created or updated.
  • Is there a convenient way to get the full changes that caused a given bug to be closed?
  • The only solution I could think of is going to https://snapshot.debian.org/package/poppler (using `poppler` as a package example), picking the corresponding two versions' debian.tar.xz files, unpacking them and comparing the directories, which looks quite cumbersome.
  • If a Debian bug number is referenced in the changelog of an uploaded package, it is automatically closed with a generic message:
  • > We believe that the bug you reported is fixed in the latest version of
  • [package], which is due to be installed in the Debian FTP archive:
  • [Random example](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528167).
  • This message also contains the new changelog entries, which helps having an idea of what was fixed, but is not as insightful as seeing the whole changes under `debian/`, especially if a patch was created or updated.
  • Is there a convenient way to get the full changes that caused a given bug to be closed?
  • The only solution I could think of is going to https://snapshot.debian.org/package/poppler (using `poppler` as a package example), picking the corresponding two versions' debian.tar.xz files, unpacking them and comparing the directories, which looks quite cumbersome.
#1: Initial revision by user avatar Quasímodo‭ · 2022-09-28T17:35:30Z (over 1 year ago)
Retrieve changes that closed a Debian bug
If a Debian bug number is referenced in the changelog of an uploaded package, it is automatically closed with a generic message:

> We believe that the bug you reported is fixed in the latest version of
[package], which is due to be installed in the Debian FTP archive:

This message also contains the new changelog entries, which helps having an idea of what was fixed, but is not as insightful as seeing the whole changes under `debian/`, especially if a patch was created or updated.

Is there a convenient way to get the full changes that caused a given bug to be closed?

The only solution I could think of is going to https://snapshot.debian.org/package/poppler (using `poppler` as a package example), picking the corresponding two versions' debian.tar.xz files, unpacking them and comparing the directories, which looks quite cumbersome.