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
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)
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)
If so, the problem will eventually go away, as Mageia
will not support 32-bit for Mageia 10.
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.
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.
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?
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
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?
On Wed, 17 Apr 2024 15:09:09 -0400, Markus Robert Kessler <no_reply@dipl-ing-kessler.de> wrote:glibc.spec?revision=2056206&view=markup
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/
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.
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."
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?
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 35:36:33 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,387 |