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
--
Robert Marshall he/him twiX: @rajm
Mastodon https://mastodon.world/@rajm

On Tue, 16 Apr 2024 10:23:02 +0100, Robert Marshall wrote:

> 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.

--
UNIX is not user-unfriendly, it merely
expects users to be computer friendly.

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.

> Reply-To: robert@capuchin.co.uk

> 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

On Tue, 16 Apr 2024 05:23:02 -0400, Robert Marshall <spam@capuchin.co.uk> wrote:

> 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

On Tue, 16 Apr 2024 10:30:27 -0400, Jim <jim.beard@verizon.net> wrote:
<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.

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

On Tue, 16 Apr 2024 11:55:03 -0400 David W. Hodgins wrote:

> On Tue, 16 Apr 2024 10:30:27 -0400, Jim <jim.beard@verizon.net> wrote:
> <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

> 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

On Tue, 16 Apr 2024 11:55:03 -0400, David W. Hodgins wrote:

> On Tue, 16 Apr 2024 10:30:27 -0400, Jim <jim.beard@verizon.net> wrote:
> <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.
>
> 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.

--
UNIX is not user-unfriendly, it merely
expects users to be computer friendly.

On Wed, 17 Apr 2024 13:13:24 -0000 (UTC) Markus Robert Kessler wrote:

> On Tue, 16 Apr 2024 11:55:03 -0400 David W. Hodgins wrote:
>
>> On Tue, 16 Apr 2024 10:30:27 -0400, Jim <jim.beard@verizon.net> wrote:
>> <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
>
>> 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

On Wed, 17 Apr 2024 09:13:24 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:

> On Tue, 16 Apr 2024 11:55:03 -0400 David W. Hodgins wrote:
>
>> On Tue, 16 Apr 2024 10:30:27 -0400, Jim <jim.beard@verizon.net> wrote:
>> <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
>
>> 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

On Wed, 17 Apr 2024 10:35:28 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
<snip>
> 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

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

On Wed, 17 Apr 2024 11:17:28 -0400 David W. Hodgins wrote:

> On Wed, 17 Apr 2024 09:13:24 -0400, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
>
>> On Tue, 16 Apr 2024 11:55:03 -0400 David W. Hodgins wrote:
>>
>>> On Tue, 16 Apr 2024 10:30:27 -0400, Jim <jim.beard@verizon.net> wrote:
>>> <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
>>
>>> 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

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

On Wed, 17 Apr 2024 15:09:09 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
> 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

On Wed, 17 Apr 2024 18:43:39 -0400 David W. Hodgins wrote:

> On Wed, 17 Apr 2024 15:09:09 -0400, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
>> 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

On Tue, Apr 16 2024, "David W. Hodgins" <dwhodgins@nomail.afraid.org> wrote:

> On Tue, 16 Apr 2024 05:23:02 -0400, Robert Marshall <spam@capuchin.co.uk> wrote:
>
>> 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

On Thu, 18 Apr 2024 03:57:07 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:
> 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

On Thu, 18 Apr 2024 12:39:38 -0400 David W. Hodgins wrote:

> On Thu, 18 Apr 2024 03:57:07 -0400, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
>> 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