Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
4 views
Skip to first unread message
Martin-Éric Racine
Mar 16, 2023, 6:00:06 PM3/16/23
to
Package: release-notes
Severity: important
Severity: important
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The release notes for i386 should specify the minimum CPU requirements.
While a kernel compiled for Geode LX (essentially a basic i686 without the optional CPU features) still ships in Debian, many packages enforce CPU flags that barf on anything older than 686-PAE.
One such package is 'sudo' (Bug #1004894) where upstream unilaterally enabled -fcf-protection and the Debian maintainer refuses to comment out the corresponding ./configure macros.
Additionally, other packages apparently disregard build-essentials' GCC defaults and instead configure flags to match the CPU features of the build host, which produces binaries that segfault on a Geode.
Martin-Éric
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmQTa+AACgkQrh+Cd8S0
17YqHRAAtsb991JnECg5MgWkkH2XwYoGgSh2N15aPOta1Gt/MqP2pdYjfDEPvsqm
Mxsq8Q+OMdNXd/i5ZglqRbpRWUO8TGOQzL+keD3U3RBss9zhFqSiv47S6eZM6R1N
RefspxicGI/7WmMUW8tdnU6pmtnEiw1czjLlZ2WICZ1kYB3MknTxlLpxp8IxnDEX
cPyKbVPd/jtdzOysNILfPZiFFsPBcOsPzYSgLxvZRZk0XzoLQQLXK5ZNb306Z8hv
wDW47WB+iHBVNd0WiZaFod8fJMELIdqzcLUgv6I1fHzB0VnwkuECdr0RFSG+vuL8
C6APU+63p9C3Py9gmwI1fRfThBdX4c1qgKCY+kDxoAf8CGjma0vgdS65bJb7Lfes
JwpyxXX5SXqdHGWuqd3pqVYO523cKOzZSWoFiwhFaopyjxLWrTMqvVXuWLl7Mawp
oqrkjWdgogyPiZGWa/xTqccuKDjqClUQM3ZjcEPKx4/R4m2iMVMTsbqZfMgRlU/H
Z5zTQUleGH4EsE0XnTF0R2gf2OCJrlxT2xyqEx72c1/edZwKfQdekXraFOv+TudZ
JKgL43lbqem90+0+QoIjWDl2PV9Uy1R1PEg0ouHrinW6ZpZlJN9M4JTTvfXg6JEJ
RHvV/8wEx4UpUOlx9Zw2mkruHKKEwo8NfvhU63nGVeJbiMsPEtM=
=uw4a
-----END PGP SIGNATURE-----
James Addison
Mar 17, 2023, 5:10:05 PM3/17/23
to
Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: 100...@bugs.debian.org
Control: affects 1005863 net-tools
Control: tags -1 moreinfo
> While a kernel compiled for Geode LX (essentially a basic i686 without the optional CPU features) still ships in Debian, many packages enforce CPU flags that barf on anything older than 686-PAE.
Possibly a naive question: could you provide a command/script to check input
binaries (such as those in the i386 archive) to see whether they are likely to
be affected by this?
(my thinking there is: if that flags a small _number_ of packages then
individual patches could make sense while we await upstream activity.
conversely, if it's a high _percentage_ of packages, then there is an important
decision to make)
I don't have a sense for what proportion of Debian's i386 installs could be on
Geode systems, but i386 is our second-most-widely deployed architecture
(between amd64 and arm64) today according to popcon.
Followup-For: Bug #1033065
X-Debbugs-Cc: 100...@bugs.debian.org
Control: affects 1005863 net-tools
Control: tags -1 moreinfo
> While a kernel compiled for Geode LX (essentially a basic i686 without the optional CPU features) still ships in Debian, many packages enforce CPU flags that barf on anything older than 686-PAE.
binaries (such as those in the i386 archive) to see whether they are likely to
be affected by this?
(my thinking there is: if that flags a small _number_ of packages then
individual patches could make sense while we await upstream activity.
conversely, if it's a high _percentage_ of packages, then there is an important
decision to make)
I don't have a sense for what proportion of Debian's i386 installs could be on
Geode systems, but i386 is our second-most-widely deployed architecture
(between amd64 and arm64) today according to popcon.
James Addison
Mar 18, 2023, 7:40:22 PM3/18/23
to
Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: martin-er...@iki.fiFollowup-For: Bug #1033065
Hi Martin-Éric - I intended to send my previous comment to you, but forgot to
add you to on carbon-copy.
Roughly speaking: I'm wondering whether there is a way that we can scan i386
architecture packages in (bookworm only?) archives to figure out the scale of
the problem.
James Addison
Mar 19, 2023, 12:50:05 PM3/19/23
to
I've used the following commands to confirm that the i386 sudo/1.9.9-1 package
contains the bugreport-relevant NOPL opcode:
# obtain an archived copy of the affected binary package
$ wget2 http://snapshot.debian.org/archive/debian/20220202T154459Z/pool/main/s/sudo/sudo_1.9.9-1_i386.deb
# unpack the contents of the package into a corresponding directory name
$ dpkg -x sudo_1.9.9-1_i386.deb sudo_1.9.9-1_i386
# iterate over each executable file extracted from the package
# - print each filename so that we can identify potentially-affected files
# - check for the 'NOPL' opcode in all i386 code sections of the file
$ while IFS= read -r -d '' file; do
> echo "$file"
> objdump --architecture=i386 --disassemble-all "$file" | grep -w "nopl"
> done < <(find . -type f -executable -print0)
It should be possible to generalise this further to scan a larger set of
packages.
The 'grep' for the word 'nopl' seems potentially fragile. If there's a
more-precise and/or less-false-positive-prone way to check whether each file
contains the 'nopl' opcode (and I'd expect that there is), then that'd be a
welcome improvement.
contains the bugreport-relevant NOPL opcode:
# obtain an archived copy of the affected binary package
$ wget2 http://snapshot.debian.org/archive/debian/20220202T154459Z/pool/main/s/sudo/sudo_1.9.9-1_i386.deb
# unpack the contents of the package into a corresponding directory name
$ dpkg -x sudo_1.9.9-1_i386.deb sudo_1.9.9-1_i386
# iterate over each executable file extracted from the package
# - print each filename so that we can identify potentially-affected files
# - check for the 'NOPL' opcode in all i386 code sections of the file
$ while IFS= read -r -d '' file; do
> echo "$file"
> objdump --architecture=i386 --disassemble-all "$file" | grep -w "nopl"
> done < <(find . -type f -executable -print0)
It should be possible to generalise this further to scan a larger set of
packages.
The 'grep' for the word 'nopl' seems potentially fragile. If there's a
more-precise and/or less-false-positive-prone way to check whether each file
contains the 'nopl' opcode (and I'd expect that there is), then that'd be a
welcome improvement.
Paul Gevers
Mar 19, 2023, 3:10:09 PM3/19/23
to
Hi Martin-Éric,
On 16-03-2023 20:20, Martin-Éric Racine wrote:
> The release notes for i386 should specify the minimum CPU requirements.
Thanks for letting us know. If we raise the baseline, historically we
mention it in the release notes. I (as a member of the release team)
wasn't aware we might have done so until now.
> Additionally, other packages apparently disregard build-essentials' GCC defaults and instead configure flags to match the CPU features of the build host, which produces binaries that segfault on a Geode.
Those are in principle all RC bugs and don't only impact Geode. Please
file bugs when you find them.
Paul (who is trying to get some more background on the topic)
On 16-03-2023 20:20, Martin-Éric Racine wrote:
> The release notes for i386 should specify the minimum CPU requirements.
mention it in the release notes. I (as a member of the release team)
wasn't aware we might have done so until now.
> Additionally, other packages apparently disregard build-essentials' GCC defaults and instead configure flags to match the CPU features of the build host, which produces binaries that segfault on a Geode.
file bugs when you find them.
Paul (who is trying to get some more background on the topic)
Martin-Éric Racine
Mar 19, 2023, 3:50:04 PM3/19/23
to
On Sun, Mar 19, 2023 at 9:02 PM Paul Gevers <elb...@debian.org> wrote:
> On 16-03-2023 20:20, Martin-Éric Racine wrote:
> > The release notes for i386 should specify the minimum CPU requirements.
>
> Thanks for letting us know. If we raise the baseline, historically we
> mention it in the release notes. I (as a member of the release team)
> wasn't aware we might have done so until now.
I purposely filed a bug for this because a number of Debian
> On 16-03-2023 20:20, Martin-Éric Racine wrote:
> > The release notes for i386 should specify the minimum CPU requirements.
>
> Thanks for letting us know. If we raise the baseline, historically we
> mention it in the release notes. I (as a member of the release team)
> wasn't aware we might have done so until now.
maintainers seem to be under the impression that Geode LX hasn't been
supported for a couple of Debian releases. Pointing out that the -686
kernel is build for exactly that doesn't seem to convince them. I
therefore feel that this needs to be made more explicit in the release
notes.
$ grep MGEODE_LX /boot/config-6.1.0-6-686
CONFIG_MGEODE_LX=y
> > Additionally, other packages apparently disregard build-essentials' GCC defaults and instead configure flags to match the CPU features of the build host, which produces binaries that segfault on a Geode.
>
> Those are in principle all RC bugs and don't only impact Geode. Please
> file bugs when you find them.
Martin-Éric
Paul Wise
Mar 20, 2023, 1:40:04 AM3/20/23
to
On Sun, 2023-03-19 at 16:44 +0000, James Addison wrote:
> The 'grep' for the word 'nopl' seems potentially fragile. If there's a
> more-precise and/or less-false-positive-prone way to check whether each file
> contains the 'nopl' opcode (and I'd expect that there is), then that'd be a
> welcome improvement.
Broadly speaking, detecting non-baseline instruction usage isn't
> The 'grep' for the word 'nopl' seems potentially fragile. If there's a
> more-precise and/or less-false-positive-prone way to check whether each file
> contains the 'nopl' opcode (and I'd expect that there is), then that'd be a
> welcome improvement.
possible without false positives, because the program could use runtime
instruction selection based on the current CPU to avoid currently
unavailable instructions, while the binary would still contain those
instructions for use on other CPUs.
https://wiki.debian.org/InstructionSelection
Of course you could do the scanning and then use autopkgtests or manual
tests to find out if the found programs work on the relevant CPUs.
Perhaps lintian could add classification tags for the relevant CPU
instructions and then the i386 port could have extra autopkgtest nodes
that only process the packages detected by lintian.
--
bye,
pabs
https://wiki.debian.org/PaulWise
James Addison
Mar 20, 2023, 8:12:26 AM3/20/23
to
Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: pa...@debian.org, ball...@debian.orgFollowup-For: Bug #1033065
Dear Maintainer and Éric-Martin (with Bill on carbon copy),
Please find linked below a previous release note from Debian 9.0 (stretch)
that we could use to provide relevant user guidance:
(I discovered this while reading a 2019 mailing list discussion[1])
On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote:
> Broadly speaking, detecting non-baseline instruction usage isn't
> possible without false positives, because the program could use runtime
> instruction selection based on the current CPU to avoid currently
> unavailable instructions, while the binary would still contain those
> instructions for use on other CPUs.
>
> https://wiki.debian.org/InstructionSelection
>
> Of course you could do the scanning and then use autopkgtests or manual
> tests to find out if the found programs work on the relevant CPUs.
Thank you, that makes sense.
I've run some ad-hoc script analysis[2] on a recent mirror of the bookworm i386
archive, and it appears that ~20% or so of packages are potentially affected in
that (so, in all likelihood, Debian is currently uninstallable and/or unusable
on Geode LX).
In theory I would like to run a comparative analysis against the snapshot
archives from previous points in time, but am not sure whether I'll get around
to doing that.
On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote:
> Perhaps lintian could add classification tags for the relevant CPU
> instructions and then the i386 port could have extra autopkgtest nodes
> that only process the packages detected by lintian.
That's not a bad idea. Are there any reasons that that might _not_ be a good
idea before filing a wishlist bug? (performance, implications of scanning
binary packages, ...)
[1] - https://lists.debian.org/debian-user/2019/04/msg01091.html
[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005863#48
James Addison
Mar 20, 2023, 3:30:04 PM3/20/23
to
Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: elb...@debian.org
Followup-For: Bug #1033065
Control: severity -1 serious
Increasing this bug's severity to a release-critical, based on mailing list
discussion[1].
Paul: bug #1005863 has most of the relevant context for Debian, although I'd
recommend the following wiki page as a more concise, purpose-written summary:
https://www.jookia.org/wiki/Nopl
[1] - https://lists.debian.org/debian-doc/2023/03/msg00012.html
Paul Wise
Mar 20, 2023, 10:33:11 PM3/20/23
to
On Mon, 2023-03-20 at 12:05 +0000, James Addison wrote:
> That's not a bad idea. Are there any reasons that that might _not_ be a good
> idea before filing a wishlist bug? (performance, implications of scanning
> binary packages, ...)
binutils isn't security supported, so using objdump in lintian probably
> That's not a bad idea. Are there any reasons that that might _not_ be a good
> idea before filing a wishlist bug? (performance, implications of scanning
> binary packages, ...)
isn't a good idea, especially since it is run on ftp-master.debian.org.
In addition disassembling binaries is going to have an impact on the
performance of lintian, especially for larger packages.
James Addison
Apr 2, 2023, 6:00:05 PM4/2/23
to
Followup-For: Bug #1033065
X-Debbugs-Cc: ball...@debian.org, pa...@debian.org
On Mon, 20 Mar 2023 13:31:37 +0800, Paul Wise wrote:
> > > Perhaps lintian could add classification tags for the relevant CPU
> > > instructions and then the i386 port could have extra autopkgtest nodes
> > > that only process the packages detected by lintian.
> This seems logistically problematic.
> Is lintian actually ran on i386 binaries anymore ?
> lintian.debian.org only lists reports for amd64 packages.
Yep, some i386 binary package analysis does still take place I believe, based
on running an UDD query[1] that found results with a recent version of lintian
(since 2023-02-05) including some i386 shared libraries in the output.
The data on lintian.debian.org (detagtive) appears out-of-date, though. There
is an existing issue report[2] about that.
> I am not sure it is worth the trouble, frankly. I do not see what this would
> bring us.
A lintian check could help to notify maintainers about architecture baseline
compatibility issues. Running autopkgtests for those could help to (although
is not guaranteed to) confirm whether the identified packages are broken,
without rerunning tests across all packages.
[1] - https://udd.debian.org/lintian/?email1=&email2=&email3=&packages=gcc-12-cross&ignpackages=&format=html<_information=on&lintian_tag=static-library-has-unneeded-sections#all
[2] - https://salsa.debian.org/lintian/detagtive/-/issues/22
X-Debbugs-Cc: ball...@debian.org, pa...@debian.org
On Mon, 20 Mar 2023 13:31:37 +0800, Paul Wise wrote:
> > > Perhaps lintian could add classification tags for the relevant CPU
> > > instructions and then the i386 port could have extra autopkgtest nodes
> > > that only process the packages detected by lintian.
On Mon, 20 Mar 2023 12:05:24 +0000, James Addison wrote:
> > That's not a bad idea. Are there any reasons that that might _not_ be a good
> > idea before filing a wishlist bug? (performance, implications of scanning
> > binary packages, ...)
On Mon, 20 Mar 2023 20:58:28 +0100, Bill Allombert wrote:
> > That's not a bad idea. Are there any reasons that that might _not_ be a good
> > idea before filing a wishlist bug? (performance, implications of scanning
> > binary packages, ...)
> This seems logistically problematic.
> Is lintian actually ran on i386 binaries anymore ?
> lintian.debian.org only lists reports for amd64 packages.
Yep, some i386 binary package analysis does still take place I believe, based
on running an UDD query[1] that found results with a recent version of lintian
(since 2023-02-05) including some i386 shared libraries in the output.
The data on lintian.debian.org (detagtive) appears out-of-date, though. There
is an existing issue report[2] about that.
> I am not sure it is worth the trouble, frankly. I do not see what this would
> bring us.
A lintian check could help to notify maintainers about architecture baseline
compatibility issues. Running autopkgtests for those could help to (although
is not guaranteed to) confirm whether the identified packages are broken,
without rerunning tests across all packages.
[1] - https://udd.debian.org/lintian/?email1=&email2=&email3=&packages=gcc-12-cross&ignpackages=&format=html<_information=on&lintian_tag=static-library-has-unneeded-sections#all
[2] - https://salsa.debian.org/lintian/detagtive/-/issues/22
Lucas Nussbaum
Apr 3, 2023, 1:30:04 AM4/3/23
to
Hi,
On 02/04/23 at 22:51 +0100, James Addison wrote:
> On Mon, 20 Mar 2023 20:58:28 +0100, Bill Allombert wrote:
> > This seems logistically problematic.
> > Is lintian actually ran on i386 binaries anymore ?
> > lintian.debian.org only lists reports for amd64 packages.
>
> Yep, some i386 binary package analysis does still take place I believe, based
> on running an UDD query[1] that found results with a recent version of lintian
> (since 2023-02-05) including some i386 shared libraries in the output.
>
> The data on lintian.debian.org (detagtive) appears out-of-date, though. There
> is an existing issue report[2] about that.
I confirm that the UDD implementation of lintian runs checks on all
architectures.
Lucas
On 02/04/23 at 22:51 +0100, James Addison wrote:
> On Mon, 20 Mar 2023 20:58:28 +0100, Bill Allombert wrote:
> > This seems logistically problematic.
> > Is lintian actually ran on i386 binaries anymore ?
> > lintian.debian.org only lists reports for amd64 packages.
>
> Yep, some i386 binary package analysis does still take place I believe, based
> on running an UDD query[1] that found results with a recent version of lintian
> (since 2023-02-05) including some i386 shared libraries in the output.
>
> The data on lintian.debian.org (detagtive) appears out-of-date, though. There
> is an existing issue report[2] about that.
architectures.
Lucas
Paul Gevers
May 11, 2023, 2:30:06 PM5/11/23
to
Control: tags -1 patch pending
Hi,
Please review my proposal here:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
Paul
Hi,
Please review my proposal here:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
Paul
Paul Gevers
May 28, 2023, 11:41:06 AM5/28/23
to
Hi,
On 11-05-2023 20:20, Paul Gevers wrote:
> Please review my proposal here:
>
> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
The release notes now document that the baseline has been bumped.
Paul
On 11-05-2023 20:20, Paul Gevers wrote:
> Please review my proposal here:
>
> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
Paul
Martin-Éric Racine
May 28, 2023, 1:10:06 PM5/28/23
to
On Sun, May 28, 2023 at 7:15 PM Martin-Éric Racine
<martin-er...@iki.fi> wrote:
> Please note that I never received the previous message you quoted.
> Anyhow, I commented. on Salsa.
See my other comments in the same thread on Salsa.
This should be made more explicit. Merely stating "something with
NOPL" really won't help anyone who isn't familiar with the intricacies
of x86 variants.
If the expected baseline nowadays is hardware that can run the
-686-pae kernel, it should be explicitly stated in the release notes.
I'm not sure of whether there is any way to grep /proc/cpuinfo to
check whether a host meets the minimal requirement for Bookwormor not,
let alone which package should perform that check, before allowing a
dist-upgrade, but this definitely needs to be implemented now before
Bookworm is released.
Anyhow, given the baseline bump, it appears that the last of the Geode
processors is no longer supported on i386 (even though -686 is
configured for MGEODE and stil ships with Bookworm). Oh well. It was
fun while it lasted.
Martin-Éric
<martin-er...@iki.fi> wrote:
> Anyhow, I commented. on Salsa.
See my other comments in the same thread on Salsa.
This should be made more explicit. Merely stating "something with
NOPL" really won't help anyone who isn't familiar with the intricacies
of x86 variants.
If the expected baseline nowadays is hardware that can run the
-686-pae kernel, it should be explicitly stated in the release notes.
I'm not sure of whether there is any way to grep /proc/cpuinfo to
check whether a host meets the minimal requirement for Bookwormor not,
let alone which package should perform that check, before allowing a
dist-upgrade, but this definitely needs to be implemented now before
Bookworm is released.
Anyhow, given the baseline bump, it appears that the last of the Geode
processors is no longer supported on i386 (even though -686 is
configured for MGEODE and stil ships with Bookworm). Oh well. It was
fun while it lasted.
Martin-Éric
Martin-Éric Racine
Jun 4, 2023, 3:40:04 PM6/4/23
to
On Mon, 29 May 2023 06:52:22 +0200 Paul Gevers <elb...@debian.org> wrote:
> header.
As commented both on Salsa and in response to your previous e-mail, I
still don't think that the release notes adequately describe the
updated baseline for i386.
As previously stated, the Geode LX (but not older Geodes) does fulfill
the baseline requirement for i686. NOPL, PAE and others were marked by
Intel as optional features. If what the new Debian baseline really
means is something that can run the -686-pae kernel, the release notes
should explicitly say so.
On a related issue, something in dpkg or apt should check the CPU
features and refuse to perform an upgrade/dist-upgrade on an host
whose CPU doesn't meet the new baseline requirements.
Martin-Éric
> On 28-05-2023 17:32, Paul Gevers wrote:
> > On 11-05-2023 20:20, Paul Gevers wrote:
> >> Please review my proposal here:
> >>
> >> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
> >
> > The release notes now document that the baseline has been bumped.
>
> I ment this message to close the bug, but I failed to adjust the mail To
> > On 11-05-2023 20:20, Paul Gevers wrote:
> >> Please review my proposal here:
> >>
> >> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
> >
> > The release notes now document that the baseline has been bumped.
>
> header.
As commented both on Salsa and in response to your previous e-mail, I
still don't think that the release notes adequately describe the
updated baseline for i386.
As previously stated, the Geode LX (but not older Geodes) does fulfill
the baseline requirement for i686. NOPL, PAE and others were marked by
Intel as optional features. If what the new Debian baseline really
means is something that can run the -686-pae kernel, the release notes
should explicitly say so.
On a related issue, something in dpkg or apt should check the CPU
features and refuse to perform an upgrade/dist-upgrade on an host
whose CPU doesn't meet the new baseline requirements.
Martin-Éric
Paul Gevers
Jun 4, 2023, 3:40:06 PM6/4/23
to
Hi Martin-Éric,
On 04-06-2023 21:28, Martin-Éric Racine wrote:
> As previously stated, the Geode LX (but not older Geodes) does fulfill
> the baseline requirement for i686. NOPL, PAE and others were marked by
> Intel as optional features. If what the new Debian baseline really
> means is something that can run the -686-pae kernel, the release notes
> should explicitly say so.
I believe you are more aware of the problems with the Geode than I, as
it were your bugs that lead to the update in the release notes. If I
understand correctly the kernel still runs fine, but a bunch of
important binaries use NOPL and hence fail on the Geode. We could add a
check for NOPL, like I mentioned in the MR.
> On a related issue, something in dpkg or apt should check the CPU
> features and refuse to perform an upgrade/dist-upgrade on an host
> whose CPU doesn't meet the new baseline requirements.
Please file a bug with the respective packages. Mentioning it in a bug
against the release notes isn't going to achieve that feature.
Paul
On 04-06-2023 21:28, Martin-Éric Racine wrote:
> As previously stated, the Geode LX (but not older Geodes) does fulfill
> the baseline requirement for i686. NOPL, PAE and others were marked by
> Intel as optional features. If what the new Debian baseline really
> means is something that can run the -686-pae kernel, the release notes
> should explicitly say so.
it were your bugs that lead to the update in the release notes. If I
understand correctly the kernel still runs fine, but a bunch of
important binaries use NOPL and hence fail on the Geode. We could add a
check for NOPL, like I mentioned in the MR.
> On a related issue, something in dpkg or apt should check the CPU
> features and refuse to perform an upgrade/dist-upgrade on an host
> whose CPU doesn't meet the new baseline requirements.
against the release notes isn't going to achieve that feature.
Paul
Paul Gevers
Jun 5, 2023, 3:30:06 PM6/5/23
to
Hi,
On 05-06-2023 04:38, Martin-Éric Racine wrote:
>>> On a related issue, something in dpkg or apt should check the CPU
>>> features and refuse to perform an upgrade/dist-upgrade on an host
>>> whose CPU doesn't meet the new baseline requirements.
>>
>> Please file a bug with the respective packages. Mentioning it in a bug
>> against the release notes isn't going to achieve that feature.
>
> Oh, totally. I'm just not sure of which one typically handles this.
> Last time the baseline was raised from 586 to 686 (before that from
> 486 to 586), something in the upgrade process performed the CPU check
> and loudly aborted the proceedings. Something similar was done when
> the baseline was raised on SPARC ages ago; upgrade aborted early if
> the host hardware didn't meet the new baseline.
I wasn't aware of that. I *think* dpkg just installs what apt feeds it,
so from those two, I'd guess apt. However, it's too late for bookworm to
add that now. I thought you meant this mostly as a future enhancement.
Paul
On 05-06-2023 04:38, Martin-Éric Racine wrote:
>>> On a related issue, something in dpkg or apt should check the CPU
>>> features and refuse to perform an upgrade/dist-upgrade on an host
>>> whose CPU doesn't meet the new baseline requirements.
>>
>> Please file a bug with the respective packages. Mentioning it in a bug
>> against the release notes isn't going to achieve that feature.
>
> Last time the baseline was raised from 586 to 686 (before that from
> 486 to 586), something in the upgrade process performed the CPU check
> and loudly aborted the proceedings. Something similar was done when
> the baseline was raised on SPARC ages ago; upgrade aborted early if
> the host hardware didn't meet the new baseline.
I wasn't aware of that. I *think* dpkg just installs what apt feeds it,
so from those two, I'd guess apt. However, it's too late for bookworm to
add that now. I thought you meant this mostly as a future enhancement.
Paul
Martin-Éric Racine
Jun 5, 2023, 4:10:05 PM6/5/23
to
Sorry, but a baseline bump really has to be better planned and better
documented than this. Merely deciding to update the release notes at
the last minute because everyone is too lazy to fix the 20% of
packages or so that --configure NOPL or some more recent flag really
won't do.
Martin-Éric
0 new messages