upgrading to mageia 9

[Robert Marshall]

Last week I upgraded to mageia 9 via

dnf system-upgrade --releasever 9 download --allowerasing

this failed giving me a number of conflicts - with .h files
which I found strange - a text file preventing an upgrade.
To the best of my knowledge I hadn't touched those files.

In order to upgrade I had to remove a number of packages e.g.
libpcre-devel-8.44-1.1.mga8.i586

Once thta was done, the upgrade suceeded

(in case this is of help to anyone, couldn't find
anything helpful via web searches)

Robert

[Jim]

Post by Robert Marshall
Last week I upgraded to mageia 9 via
dnf system-upgrade --releasever 9 download --allowerasing
this failed giving me a number of conflicts - with .h files
which I found strange - a text file preventing an upgrade.
To the best of my knowledge I hadn't touched those files.
In order to upgrade I had to remove a number of packages e.g.
libpcre-devel-8.44-1.1.mga8.i586
Once thta was done, the upgrade suceeded
(in case this is of help to anyone, couldn't find
anything helpful via web searches)

You cite a problem involving an i586 32-bit package,
and I speculate an obsolete piece of software may be involved.

If so, the problem will eventually go away, as Mageia
will not support 32-bit for Mageia 10.

Cheers!

jim b.

[David W. Hodgins]

On Tue, 16 Apr 2024 10:30:27 -0400, Jim <***@verizon.net> wrote:
<snip>

Post by Jim
If so, the problem will eventually go away, as Mageia
will not support 32-bit for Mageia 10.

Mageia 10 will continue to support 32 bit systems.

What's changing is that i586 will no longer be supported. Instead i686 will
be the minimum. The difference is the cpu must have sse2 support, which
true i586 systems do not have.

Regards, Dave Hodgins

[Markus Robert Kessler]

Post by David W. Hodgins
<snip>

If so, the problem will eventually go away, as Mageia will not support
32-bit for Mageia 10.

Mageia 10 will continue to support 32 bit systems.

Yes and no. Former example regarding chromium browser shows, that support
for a certain 32-bit package may be dropped without notifying the user.
Hence, you trust that every package is bugfixed whenever needed, but
indeed, in some cases, it is not. While some other packages are updated,
so it looks like everything is ok.

I understand that the effort is huge since chromium's sources is around
3.2 Gigabyte in size, and I estimate that compiling and packaging will
take several hours, but it is not ok to just drop support for it.
They recommend to use firefox instead, but many web applications are
terribly slow on firefox, and some apps like video conferencing do not run
properly at all on top of firefox

Post by David W. Hodgins
What's changing is that i586 will no longer be supported. Instead i686
will be the minimum. The difference is the cpu must have sse2 support,
which true i586 systems do not have.

Where can this be looked up? In the BIOS?

Thanks!

Best regards,

Markus

[Markus Robert Kessler]

Post by Markus Robert Kessler

Post by David W. Hodgins
<snip>

If so, the problem will eventually go away, as Mageia will not support
32-bit for Mageia 10.

Mageia 10 will continue to support 32 bit systems.

Yes and no. Former example regarding chromium browser shows, that
support for a certain 32-bit package may be dropped without notifying
the user. Hence, you trust that every package is bugfixed whenever
needed, but indeed, in some cases, it is not. While some other packages
are updated, so it looks like everything is ok.
I understand that the effort is huge since chromium's sources is around
3.2 Gigabyte in size, and I estimate that compiling and packaging will
take several hours, but it is not ok to just drop support for it.
They recommend to use firefox instead, but many web applications are
terribly slow on firefox, and some apps like video conferencing do not
run properly at all on top of firefox

Post by David W. Hodgins
What's changing is that i586 will no longer be supported. Instead i686
will be the minimum. The difference is the cpu must have sse2 support,
which true i586 systems do not have.

Where can this be looked up? In the BIOS?

Wait, I found it. It's part of the processor flags:

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
[...]
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx bts cpuid est tm2 pti

Best regards,

Markus

[David W. Hodgins]

On Wed, 17 Apr 2024 10:35:28 -0400, Markus Robert Kessler <***@dipl-ing-kessler.de> wrote:
<snip>

Post by Markus Robert Kessler
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
[...]
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx bts cpuid est tm2 pti

That is an i686 cpu. When upgrading from Mageia 9 to 10, the i586 packages
will be replaced with i686 packages.

Intel stopped making i586 cpus in 2006.

Regards, Dave Hodgins

[David W. Hodgins]

Post by Markus Robert Kessler

Post by David W. Hodgins
<snip>

If so, the problem will eventually go away, as Mageia will not support
32-bit for Mageia 10.

Mageia 10 will continue to support 32 bit systems.

Yes and no. Former example regarding chromium browser shows, that support
for a certain 32-bit package may be dropped without notifying the user.
Hence, you trust that every package is bugfixed whenever needed, but
indeed, in some cases, it is not. While some other packages are updated,
so it looks like everything is ok.
I understand that the effort is huge since chromium's sources is around
3.2 Gigabyte in size, and I estimate that compiling and packaging will
take several hours, but it is not ok to just drop support for it.
They recommend to use firefox instead, but many web applications are
terribly slow on firefox, and some apps like video conferencing do not run
properly at all on top of firefox

Post by David W. Hodgins
What's changing is that i586 will no longer be supported. Instead i686
will be the minimum. The difference is the cpu must have sse2 support,
which true i586 systems do not have.

Where can this be looked up? In the BIOS?

"lscpu|grep Flags:" will show which instruction sets the cpu supports.

For example on my 12 year old amd desktop system ...
$ lscpu|grep Flags:
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt fma4 nodeid_msr topoext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb vmmcall arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

The sse2 instruction set was first added with the Intel Pentium 4 in 2000.

Regarding dropping 32 bit versions of some packages, that happens upstream.
In the case of chromium-browser, google chose to make changes that are
extremely difficult to port to 32 bit. IIRC compiling chromium takes around
12 hours.

Dropping 32 bit support for a package is only done after discussions in the
dev ml where others will step in and try to figure out how not to drop it.
It's only when the packagers agree they don't have the time and expertise to
get it working that the package gets dropped from the 32 bit arch.

The aarch64 cpu on my rpi 4b does not have any version of sse supported, so
chromium-browser has never been supported on it.

Regards, Dave Hodgins

[Markus Robert Kessler]

On Wed, 17 Apr 2024 09:13:24 -0400, Markus Robert Kessler

Post by Markus Robert Kessler

Post by David W. Hodgins
<snip>

If so, the problem will eventually go away, as Mageia will not
support 32-bit for Mageia 10.

Mageia 10 will continue to support 32 bit systems.

Yes and no. Former example regarding chromium browser shows, that
support for a certain 32-bit package may be dropped without notifying
the user. Hence, you trust that every package is bugfixed whenever
needed, but indeed, in some cases, it is not. While some other packages
are updated, so it looks like everything is ok.
I understand that the effort is huge since chromium's sources is around
3.2 Gigabyte in size, and I estimate that compiling and packaging will
take several hours, but it is not ok to just drop support for it.
They recommend to use firefox instead, but many web applications are
terribly slow on firefox, and some apps like video conferencing do not
run properly at all on top of firefox

Post by David W. Hodgins
What's changing is that i586 will no longer be supported. Instead i686
will be the minimum. The difference is the cpu must have sse2 support,
which true i586 systems do not have.

Where can this be looked up? In the BIOS?

"lscpu|grep Flags:" will show which instruction sets the cpu supports.
For example on my 12 year old amd desktop system ...
Flags: fpu vme de pse tsc msr pae mce cx8
apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht
syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl
nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3
cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic
cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt
fma4 nodeid_msr topoext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb
vmmcall arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean
flushbyasid decodeassists pausefilter pfthreshold
The sse2 instruction set was first added with the Intel Pentium 4 in 2000.
Regarding dropping 32 bit versions of some packages, that happens upstream.
In the case of chromium-browser, google chose to make changes that are
extremely difficult to port to 32 bit. IIRC compiling chromium takes

Meaning, though up to version 120 there was 1 SRPM, this would force to
have 2 different SRPM files, one for i586 and one for x86_64 binary?

Thanks,

best regards,

Markus

[David W. Hodgins]

Post by Markus Robert Kessler
Meaning, though up to version 120 there was 1 SRPM, this would force to
have 2 different SRPM files, one for i586 and one for x86_64 binary?

No. One source rpm is used for all arches. Which arches have rpm pkgs generated
and what rpm packages are generated is controlled by the spec file (part of the
source rpm) that includes the steps needed to compile/link the source to create the
packages.

Each of the rpm packages is compiled once for each supported architecture. Which
arch the package is being compiled for is controlled by flags passed to the compiler
such as gcc in the spec file. For noarch packages (no programs that need to be
compiled), the rpm package is generated on one arch and copied to the others.

If you take a look at svn, which is used to generate the srpm packages, the spec
file can be seen.

For example, glibc was rebuilt on cauldron 8 days ago. The spec file is available
at
https://svnweb.mageia.org/packages/cauldron/glibc/current/SPECS/glibc.spec?revision=2056206&view=markup

In that file it has conditional statements such as ...
1326 %if %isarch i386
1327 %{_slibdir}/ld-linux.so.2
1328 %endif

1329 %if %isarch %arm
1330 %if %isarch armv7hl
1331 %{_slibdir}/ld-linux-armhf.so.3
1332 %endif

1335 %if %isarch x86_64
1336 %{_slibdir}/ld-linux-x86-64.so.2
1337 %endif

So it generates differently named rpm packages depending on the target arch.
Note that i386 is defined elsewhere in the build system to now actually be the
flags used for i686, for Mageia 10, and still be i586 for Mageia 9.

The three rpm packages are built in parallel by different nodes in the build
system.

Regards, Dave Hodgins

[Markus Robert Kessler]

On Wed, 17 Apr 2024 15:09:09 -0400, Markus Robert Kessler

Post by Markus Robert Kessler
Meaning, though up to version 120 there was 1 SRPM, this would force to
have 2 different SRPM files, one for i586 and one for x86_64 binary?

No. One source rpm is used for all arches. Which arches have rpm pkgs
generated and what rpm packages are generated is controlled by the spec
file (part of the source rpm) that includes the steps needed to
compile/link the source to create the packages.
Each of the rpm packages is compiled once for each supported
architecture. Which arch the package is being compiled for is controlled
by flags passed to the compiler such as gcc in the spec file. For noarch
packages (no programs that need to be compiled), the rpm package is
generated on one arch and copied to the others.
If you take a look at svn, which is used to generate the srpm packages,
the spec file can be seen.
For example, glibc was rebuilt on cauldron 8 days ago. The spec file is
available at
https://svnweb.mageia.org/packages/cauldron/glibc/current/SPECS/

glibc.spec?revision=2056206&view=markup

In that file it has conditional statements such as ...
1326 %if %isarch i386 1327 %{_slibdir}/ld-linux.so.2 1328 %endif
1329 %if %isarch %arm 1330 %if %isarch armv7hl 1331
%{_slibdir}/ld-linux-armhf.so.3 1332 %endif
1335 %if %isarch x86_64 1336 %{_slibdir}/ld-linux-x86-64.so.2 1337
%endif
So it generates differently named rpm packages depending on the target arch.
Note that i386 is defined elsewhere in the build system to now actually
be the flags used for i686, for Mageia 10, and still be i586 for Mageia
9.
The three rpm packages are built in parallel by different nodes in the
build system.

OK, undestood. Thanks!
Well, I was never forced to use that in rpm building this excessively, but
it reminds me somehow of some #ifdef structures in c/c++.

But, if so, one could look if someone else has already solved this
challenge, and, let's say, take the source from debian, do a 'deb2spec'
conversion and check if this builds?

Thanks again,
best regards,

Markus

[David W. Hodgins]

Post by Markus Robert Kessler
But, if so, one could look if someone else has already solved this
challenge, and, let's say, take the source from debian, do a 'deb2spec'
conversion and check if this builds?

The variations in the coding of the spec files means that the spec files can
not be copied, as is, between distributions, other then some with extremely
simple spec files (usually only for noarch packages that have no dependencies).

Even between rpm based distributions, there are variations in the naming
standards for packages that are listed as dependencies, so manual fixing
is almost always required.

The program "alien" can be usually be used to install dpkg files on an rpm
based distro, and vice-versa, but dependencies must be handled manually.

Regards, Dave Hodgins

[Markus Robert Kessler]

On Thu, 18 Apr 2024 03:57:07 -0400, Markus Robert Kessler

Post by Markus Robert Kessler
But, if so, one could look if someone else has already solved this
challenge, and, let's say, take the source from debian, do a 'deb2spec'
conversion and check if this builds?

The variations in the coding of the spec files means that the spec files
can not be copied, as is, between distributions, other then some with
extremely simple spec files (usually only for noarch packages that have
no dependencies).
Even between rpm based distributions, there are variations in the naming
standards for packages that are listed as dependencies, so manual fixing
is almost always required.
The program "alien" can be usually be used to install dpkg files on an
rpm based distro, and vice-versa, but dependencies must be handled
manually.

Alien is a good tool to "re-package" binary RPMs, as long as they do not
use fancy dependencies. Indeed.

I have made heavy use of it to port the most important synthesizer plugins
to RPM / MGA. So, now I have Dexed DX7, OxeFM, Surge, and many more on
MGA9-x64 to finally have a nice little home studio, and even on MGA9-i686
some of them I got to work.

It looks as if they are mostly statically compiled, so re-packaging
worked.

Best regards,

Markus

[Jim]

Post by David W. Hodgins
<snip>

Post by Jim
If so, the problem will eventually go away, as Mageia
will not support 32-bit for Mageia 10.

Mageia 10 will continue to support 32 bit systems.
What's changing is that i586 will no longer be supported. Instead i686 will
be the minimum. The difference is the cpu must have sse2 support, which
true i586 systems do not have.

Thank you for the correction.

I was not aware of the exact destinction for i686.

Cheers!

jim b.

[Vincent Coen]

Hello Robert!

Tuesday April 16 2024 10:23, Robert Marshall wrote to All:

I must admit I use the rpm processes and not dnf which I have found to be
flaky and not as up to date as the rpm process.

Regardless be very careful about removing so called orphans (dead packages)
as the system is often wrong and even more so if you have added packages
outside of the normal process of using rpm, urpm or dnf.

Do not the auto-orphan process as you can easily end up with a broken
system.

Of course if you have plenty of free disk spaces this is not a problem as
the space taken up is usually not that high i.e., well below 1Gb.

Post by Robert Marshall
Last week I upgraded to mageia 9 via
dnf system-upgrade --releasever 9 download --allowerasing
this failed giving me a number of conflicts - with .h files
which I found strange - a text file preventing an upgrade.
To the best of my knowledge I hadn't touched those files.
In order to upgrade I had to remove a number of packages e.g.
libpcre-devel-8.44-1.1.mga8.i586
Once thta was done, the upgrade suceeded
(in case this is of help to anyone, couldn't find
anything helpful via web searches)
Robert

Vincent

[David W. Hodgins]

Post by Robert Marshall
Last week I upgraded to mageia 9 via
dnf system-upgrade --releasever 9 download --allowerasing
this failed giving me a number of conflicts - with .h files
which I found strange - a text file preventing an upgrade.
To the best of my knowledge I hadn't touched those files.
In order to upgrade I had to remove a number of packages e.g.
libpcre-devel-8.44-1.1.mga8.i586
Once thta was done, the upgrade suceeded
(in case this is of help to anyone, couldn't find
anything helpful via web searches)

That's normal when devel packages have been installed, as devel packages
can not have both a 32 bit and a 64 bit version installed at the same time.

From https://wiki.mageia.org/en/How_to_choose_the_right_Mageia_upgrade_method#Preparations
"A 64 bit system must have any 32 bit development libraries uninstalled."

Regards, Dave Hodgins

[Robert Marshall]

Post by David W. Hodgins

Post by Robert Marshall
Last week I upgraded to mageia 9 via
dnf system-upgrade --releasever 9 download --allowerasing
this failed giving me a number of conflicts - with .h files
which I found strange - a text file preventing an upgrade.
To the best of my knowledge I hadn't touched those files.
In order to upgrade I had to remove a number of packages e.g.
libpcre-devel-8.44-1.1.mga8.i586
Once thta was done, the upgrade suceeded
(in case this is of help to anyone, couldn't find
anything helpful via web searches)

That's normal when devel packages have been installed, as devel packages
can not have both a 32 bit and a 64 bit version installed at the same time.
From https://wiki.mageia.org/en/How_to_choose_the_right_Mageia_upgrade_method#Preparations
"A 64 bit system must have any 32 bit development libraries uninstalled."

Thanks for that pointer, I must have carelessly skim read that page - and
tries to remember when I installed devel packages!

Robert