Bug#994069: age: Update versions of age
> since v1.0.0-rc.3 This was meant to be v1.0.0-rc.1, the version in the Debian repositories now.
Bug#994069: age: Update versions of age
Package: age Version: 1.0.0~rc1-2+b3 Severity: important X-Debbugs-Cc: fili...@ml.filippo.io Dear Maintainer, We recently published upstream v1.0.0 of age. There are some important changes since v1.0.0-rc.3: a bug was fixed that would cause a percentage of armored files to become corrupted; ssh-rsa keys too small to be secure are now rejected; a limit on the number of recipients in a file has been lifted; and a few more. The release also includes comprehensive manual pages. We'd like to see v1.0.0 imported into testing, but would also like to see the important bugs fixed in Debian 11.1. These bugs can cause data loss or significant confusion since the version of age in Debian would refuse to decrypt valid files. We prepared a branch of backports for Debian 11.1, in case v1.0.0 is deemed too large a change to import. https://github.com/FiloSottile/age/commits/debian/11 Thank you, Filippo -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.10.47-linuxkit (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages age depends on: ii libc6 2.31-13 age recommends no packages. age suggests no packages. -- no debconf information
Bug#986144: age: version number not set at build time
Package: age X-Debbugs-Cc: ni...@debian.org, jfle...@arcaik.net Version: 1.0.0~rc1-1 Severity: important Dear Maintainer, The age binary is currently built without version information. # age --version (unknown) This should be fixed by adding arguments like the following to the "go build" invocation. -ldflags "-X main.Version=v1.0.0-rc.1" Flagging as important because version information is a critical part of debugging and reporting issues. Thank you, Filippo
Bug#985028: Bug#981413: age: New upstream version (1.0.0~beta6)
2021-03-17 17:33 GMT+01:00 Shengjing Zhu mailto:zhsj%40debian.org>>: > On Thu, Mar 18, 2021 at 12:06 AM Filippo Valsorda <mailto:filippo%40ml.filippo.io>> wrote: > > > > 2021-03-17 16:19 GMT+01:00 nicoo > <mailto:nicoo%40debian.org>>: > > > This is currently blocked on golang-filippo-edwards25519 getting into > > > testing, which didn't happen because of the whole issue with NEW requiring > > > binary uploads and transition requiring source-only ones. > > > > Thank you for packaging age and for picking up this upload! > > > > I dropped the golang-filippo-edwards25519 dependency in v1.0.0-rc.1 to > > make it easier to get that version into Bullseye. > > > > Let me know if it's fine to add it back in a later v1.0, or if it would > > block bugfixes from making it into Bullseye during the cycle, and I > > should wait for v1.1. > > > > It depends on what version of age wants to be included in Bullseye. > As per Bullseye freeze policy[1], golang-filippo-edwards25519 is out > of luck to be included in Bullseye(No new package since 2/12). But it > will be included in the next release of cause. > Currently age v1.0.0-rc1 seems fine for Bullseye, it will migrated > from Unstable to Bullseye after 20 days. v1.0.0-rc.1 is definitely ok for the Bullseye release. I was wondering if I should delay the golang-filippo-edwards25519 dependency to v1.1.0 to allow v1.0.x bugfixes into later Bullseye point releases, or if the bar for those is so high that it doesn't matter anyway.
Bug#981413: age: New upstream version (1.0.0~beta6)
2021-03-17 16:19 GMT+01:00 nicoo : > This is currently blocked on golang-filippo-edwards25519 getting into > testing, which didn't happen because of the whole issue with NEW requiring > binary uploads and transition requiring source-only ones. Thank you for packaging age and for picking up this upload! I dropped the golang-filippo-edwards25519 dependency in v1.0.0-rc.1 to make it easier to get that version into Bullseye. Let me know if it's fine to add it back in a later v1.0, or if it would block bugfixes from making it into Bullseye during the cycle, and I should wait for v1.1.
