[SOLVED] Question - Update from debian, an old bug ?

P

pengu1n

Member
Apr 19, 2022
64
5
13
I know it is an odd title.
PVE 8.4.1with kernel Linux 6.8.12-10-pve (2025-04-18T07:39Z).
Only pve-no-subscription and bookworm repositories enabled.
I came to check for updates, and there are some, only from Debian. All pretty normal. But I normally do at least a cursory few spot-checks on the updates for any that look like need attention before downbloading and applying. This is how this caught my attention. Top of the changelogs for a couple of examples:
Code: 
Changelog: bash
bash (5.2.15-2) unstable; urgency=medium

  * Remove one more pdf file without source. Closes: #1024598.

 -- Matthias Klose <doko@debian.org>  Mon, 02 Jan 2023 13:06:21 +0100

bash (5.2.15-1) unstable; urgency=medium

  * New patch release.

 -- Matthias Klose <doko@debian.org>  Sat, 31 Dec 2022 16:40:30 +0100

bash (5.2-3) unstable; urgency=medium

  * Apply upstream patches 003 - 015.
  * Repack to get rid of non-source PDF (Bastian Germann). Closes: #1024598.
  * d/watch: Update to v4 and add repack options.
  * d/copyright: Convert to machine-readable format, adding missing info.
    Closes: #1024602.
  * Enable all hardening flags (Christian Göttsche). Closes: #1021082.
  * Fix build on musl (Helmut Grohne). Closes: #1023053.

 -- Matthias Klose <doko@debian.org>  Sat, 31 Dec 2022 11:32:01 +0100
Code: 
Changelog: busybox (1:1.35.0-4) unstable; urgency=medium

  * static build: disable blkid applet (CONFIG_BLKID, #1023501)

    Since static build has CONFIG_FEATURE_PREFER_APPLETS=y, enabling
    any utility which is also provided by the system in other ways
    can be risky, since busybox shell will choose its applet version
    instead of running the actual utility, even if that utility file
    exists in $PATH. After enabling blkid, we effectively overwrote
    blkid from libblkid as used in initramfs. The result was non-
    working udev rules for block devices (not creating /dev/disk/by-*/),
    and the system's unbootable.

    Disable it for now at least on static build.
    Closes: 1023501

  * d/rules: recognize "terse" in $DEB_BUILD_OPTIONS to disable verbose build

 -- Michael Tokarev <mjt@tls.msk.ru>  Sun, 06 Nov 2022 11:27:04 +0300
So the question is, is it pretty normal to get these seemingly old bug fixes?.
Looking at one in the Debian bug tracker in case it was an erroneous changelog, it seems indeed an old bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024598
Or perhaps I have a misconfiguration that is making me be on old code?
I don't have a problem asking what might appear as a daft question.
 
janus57 said:
So yes, it's normal to get old bugfixe since the version is old.
Click to expand...
I don't think you've dealt with the OP's question as to why he should be receiving that update NOW - when it was released on bash - 02 Jan 2023 & busybox - 06 Nov 2022.

Something that strikes me is the unstable in both those changelogs. Which repos is the OP on? Does he not have only main ?
Maybe somehow those updates have only now been incorporated in stable - but the changelog shows the original unstable ones? IDK.

I decided to check my bash & busybox versions (on a fully updated (early morning) PVE with Debian bookworm main & PVE no-subscription):
Code: 
bash --version
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
So I'm the release before yours!

Code: 
~# busybox --help
BusyBox v1.35.0 (Debian 1:1.35.0-4+b4) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
So here I "appear" to have the same.


pengu1n said:
I don't have a problem asking what might appear as a daft question.
Click to expand...
I don't think it is daft at all - as a matter of fact; I'm not sure what the authoritative & exact answer to your question is!

I would really like to see the OP's exact repos with:
Code: 
find /etc/apt/sources* -type f -exec cat {} +

Maybe someone else can indulge us.
 
Hi,
the new bash version was just a rebuild and binary upload (that is what the +b# suffix indicates see here), because a library it depends on got updated, which can be seen in the following changelog /usr/share/doc/bash/changelog.Debian.amd64.gz (thanks to @fabian for pointing me there!):
Code: 
bash (5.2.15-2+b8) bookworm; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild for outdated Built-Using (glibc/2.36-9+deb12u5)

 -- all / amd64 / i386 Build Daemon (x86-conova-01) <buildd_amd64-x86-conova-01@buildd.debian.org>  Fri, 18 Apr 2025 22:47:34 +0000
 
  • Like
Reactions: Neobin, Johannes S and gfngfn256
gfngfn256 said:
Something that strikes me is the unstable in both those changelogs. Which repos is the OP on? Does he not have only main ?
Maybe somehow those updates have only now been incorporated in stable - but the changelog shows the original unstable ones? IDK.
Click to expand...

the Debian release process works like this:

packages are uploaded to Debian unstable (hence they have "unstable" in their changelog entries)
after passing some checks, they migrate to testing

before a stable release is cut, testing gets increasingly frozen
then testing is declared stable, and testing is unfrozen again

only uploads specificially targetting stable after it has been released will have that stable release (or some variant) in their changelog entries. this mostly means security fixes or fixes for stable point releases. binNMUs are a special kind of update where the source doesn't actually change, the package is just rebuilt to pick up other changes. in that case.

you can easily observe this history by looking at the changelog of a package:

"apt changelog openssl"

you will see a lot of version bumps aimed at bookworm or bookworm-security, up until 3.0.9-1, which was uploaded to unstable before the bookworm release happened. sometimes you will also see entries for experimental inbetween, this is also normal.
 
  • Like
Reactions: Neobin, Johannes S and gfngfn256
@gfngfn256 - thanks for articulating my query. @janus57 thank you too.
I'm only on stable I think, with my sources being main.
root@pve2:~# find /etc/apt/sources* -type f -exec cat {} +
deb http://ftp.uk.debian.org/debian bookworm main contrib

deb http://ftp.uk.debian.org/debian bookworm-updates main contrib

# security updates
deb http://security.debian.org bookworm-security main contrib

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

deb http://ftp.uk.debian.org/debian bullseye main contrib

deb http://ftp.uk.debian.org/debian bullseye-updates main contrib

# security updates
deb http://security.debian.org bullseye-security main contrib

deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription

# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

# deb https://enterprise.proxmox.com/debian/pve bullseye pve-enterprise

@fiona @fabian - thank you both for your explanation. I now have a better grasp of it, especially for future ones.
For these, I feel confident to proceed with the upgrades.
 
Thanks to both fiona & fabian!
This is the awesome thing about this forum - in the end you get expert & authoritative advice from the best.
Kudos to all.
 
gfngfn256 said:
You are welcome. Your repos appear similar to mine.

The only thing - that still interests me - is what version of bash you have?

What is your output for:
Code: 
bash --version
Click to expand...
Ah. I missed the message prior to applying the update, so can only show my current.
Code: 
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
You seem to be on a different one. Different repos myabe?
 
You must log in or register to reply here.
Top Bottom