From arekm at maven.pl  Mon Feb  5 10:14:41 2018
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Mon, 5 Feb 2018 10:14:41 +0100
Subject: libexec and multi-arch
Message-ID: <201802051014.41182.arekm@maven.pl>


What's the approach for problems like:

error: Install/Erase problems:
        file /usr/libexec/getconf/POSIX_V6_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
        file /usr/libexec/getconf/POSIX_V7_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
        file /usr/libexec/getconf/XBS5_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32

?

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From baggins at pld-linux.org  Mon Feb  5 10:36:34 2018
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 5 Feb 2018 10:36:34 +0100
Subject: libexec and multi-arch
In-Reply-To: <201802051014.41182.arekm@maven.pl>
References: <201802051014.41182.arekm@maven.pl>
Message-ID: <20180205093634.GB4108@home>

On Mon, 05 Feb 2018, Arkadiusz Mi?kiewicz wrote:

> 
> What's the approach for problems like:
> 
> error: Install/Erase problems:
>         file /usr/libexec/getconf/POSIX_V6_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>         file /usr/libexec/getconf/POSIX_V7_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>         file /usr/libexec/getconf/XBS5_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
> 
> ?

Use the --force, Luke.

I haven't find anything smarter yet.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From jajcus at jajcus.net  Mon Feb  5 10:47:32 2018
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 5 Feb 2018 10:47:32 +0100
Subject: libexec and multi-arch
In-Reply-To: <20180205093634.GB4108@home>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
Message-ID: <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>

On 2018-02-05 10:36, Jan R?korajski wrote:
> On Mon, 05 Feb 2018, Arkadiusz Mi?kiewicz wrote:
> 
>>
>> What's the approach for problems like:
>>
>> error: Install/Erase problems:
>>         file /usr/libexec/getconf/POSIX_V6_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>>         file /usr/libexec/getconf/POSIX_V7_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>>         file /usr/libexec/getconf/XBS5_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>>
>> ?
> 
> Use the --force, Luke.
> 
> I haven't find anything smarter yet.

Using lib/lib64/libx32 instead of libexec was much smarter in this case.
Are we dropping multi-arch support in PLD all together?

Jacek


From gotar at polanet.pl  Mon Feb  5 16:06:43 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 5 Feb 2018 16:06:43 +0100
Subject: libexec and multi-arch
In-Reply-To: <201802051014.41182.arekm@maven.pl>
References: <201802051014.41182.arekm@maven.pl>
Message-ID: <20180205150643.GA24069@polanet.pl>

On Mon, Feb 05, 2018 at 10:14:41 +0100, Arkadiusz Mi?kiewicz wrote:
> 
> What's the approach for problems like:
> 
> error: Install/Erase problems:
>         file /usr/libexec/getconf/POSIX_V6_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>         file /usr/libexec/getconf/POSIX_V7_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>         file /usr/libexec/getconf/XBS5_ILP32_OFFBIG conflicts between attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
> 
> ?

The same as in the getconf binary itself:

$ rpm -qpilv glibc-2.27-2.i686.rpm glibc-2.27-2.x86_64.rpm  | grep /usr/bin/getconf
-rwxr-xr-x    7 root    root            21988 Feb  5 11:55 /usr/bin/getconf
-rwxr-xr-x    4 root    root            30968 Feb  5 11:56 /usr/bin/getconf

- they apparently differ, so which one do you want to have/use? How is
THIS problem resolved?

They should be either separated to subpackages that are not subject of
multiarch installations, or handled/colored/whatever by package manager
during the install process.

-- 
Tomasz Pala <gotar at pld-linux.org>


From gotar at polanet.pl  Mon Feb  5 16:13:32 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 5 Feb 2018 16:13:32 +0100
Subject: libexec and multi-arch
In-Reply-To: <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
Message-ID: <20180205151332.GB24069@polanet.pl>

On Mon, Feb 05, 2018 at 10:47:32 +0100, Jacek Konieczny wrote:

> Using lib/lib64/libx32 instead of libexec was much smarter in this case.

No, it only hidden the problem behind getconf binary being handled
_somehow_. I once even wondered how this is done, apparently rpm is
trying to be way too smart.

> Are we dropping multi-arch support in PLD all together?

Multi-arch means ability to install multiple libraries, not binaries -
there is no /usr/bin64 for getconf using /usr/lib64/getconf files.


Anyway, our multi-arch usually requires the same versions of packages
due to various man pages or locales shipped with the libraries. Just
like in case of glibc.

-- 
Tomasz Pala <gotar at pld-linux.org>


From n3npq at me.com  Mon Feb  5 21:20:55 2018
From: n3npq at me.com (Jeff Johnson)
Date: Mon, 05 Feb 2018 15:20:55 -0500
Subject: libexec and multi-arch
In-Reply-To: <20180205151332.GB24069@polanet.pl>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
Message-ID: <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>



> On Feb 5, 2018, at 10:13 AM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
>> On Mon, Feb 05, 2018 at 10:47:32 +0100, Jacek Konieczny wrote:
>> 
>> Using lib/lib64/libx32 instead of libexec was much smarter in this case.
> 
> No, it only hidden the problem behind getconf binary being handled
> _somehow_. I once even wondered how this is done, apparently rpm is
> trying to be way too smart.
> 

RPM implements arch specific content generally as:
  Libraries on different paths.
  Executables on same path.
This requires a resolution to a preferred arch (usually x86_64) when installing executables onto identical paths.

Whether RPM is too smart or the requested implementation is insufficiently general is arguable. For example, one might desire the ability for per-file-path configurable choice of architecture rather than per-system confIguration.

73 de Jeff

From ngompa13 at gmail.com  Mon Feb  5 21:23:25 2018
From: ngompa13 at gmail.com (Neal Gompa)
Date: Mon, 5 Feb 2018 15:23:25 -0500
Subject: libexec and multi-arch
In-Reply-To: <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
Message-ID: <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>

On Mon, Feb 5, 2018 at 3:20 PM, Jeff Johnson <n3npq at me.com> wrote:
>
>
>> On Feb 5, 2018, at 10:13 AM, Tomasz Pala <gotar at polanet.pl> wrote:
>>
>>> On Mon, Feb 05, 2018 at 10:47:32 +0100, Jacek Konieczny wrote:
>>>
>>> Using lib/lib64/libx32 instead of libexec was much smarter in this case.
>>
>> No, it only hidden the problem behind getconf binary being handled
>> _somehow_. I once even wondered how this is done, apparently rpm is
>> trying to be way too smart.
>>
>
> RPM implements arch specific content generally as:
>   Libraries on different paths.
>   Executables on same path.
> This requires a resolution to a preferred arch (usually x86_64) when installing executables onto identical paths.
>
> Whether RPM is too smart or the requested implementation is insufficiently general is arguable. For example, one might desire the ability for per-file-path configurable choice of architecture rather than per-system confIguration.
>

I'd probably argue that libexec should have the same multi-arch
handling that (s)bin does (primary arch "wins" and secondary arches
are ignored), though last I checked this isn't specific to paths and
should Just Work(TM).



-- 
?????????/ Always, there's only one truth!


From gotar at polanet.pl  Mon Feb  5 23:46:09 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 5 Feb 2018 23:46:09 +0100
Subject: libexec and multi-arch
In-Reply-To: <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
Message-ID: <20180205224609.GA25569@polanet.pl>

On Mon, Feb 05, 2018 at 15:20:55 -0500, Jeff Johnson wrote:

>> No, it only hidden the problem behind getconf binary being handled
>> _somehow_. I once even wondered how this is done, apparently rpm is
>> trying to be way too smart.
> 
> RPM implements arch specific content generally as:
>   Libraries on different paths.
>   Executables on same path.

libexec directory should be treated as binaries, not libraries (even if
technically some of the contents are libraries, like plugins) nor data,
as the purpose of this is to carry private helpers of the binaries, not
any shared code.

> This requires a resolution to a preferred arch (usually x86_64) when installing executables onto identical paths.

How is rpm recognizing files that are subject to this special-handling
as same-path-executables?
How to extend this to all the files inside libexecdir?
How to extend this to all the files in mandir maybe?

> Whether RPM is too smart or the requested implementation is insufficiently general is arguable. For example, one might desire the ability for per-file-path configurable choice of architecture rather than per-system confIguration.

Or - to always use preferred arch, for ANY file that is overlapping in
packages that differ only in arch, e.g. /etc or anything inside datadir.

Currently, if such files exist, they need to have identical content for
the packages to be installed simultaneously, or be separated into
respective subpackages, which is unnecessary maintenance burden.

-- 
Tomasz Pala <gotar at pld-linux.org>


From gotar at polanet.pl  Mon Feb  5 23:48:52 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 5 Feb 2018 23:48:52 +0100
Subject: libexec and multi-arch
In-Reply-To: <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
Message-ID: <20180205224852.GB25569@polanet.pl>

On Mon, Feb 05, 2018 at 15:23:25 -0500, Neal Gompa wrote:

>>> _somehow_. I once even wondered how this is done, apparently rpm is
>>> trying to be way too smart.
[...]
> I'd probably argue that libexec should have the same multi-arch
> handling that (s)bin does (primary arch "wins" and secondary arches
> are ignored), though last I checked this isn't specific to paths and
> should Just Work(TM).

Well, if not specific to paths, but autodetected per-file type, this
fulfils my definition of 'trying to be too smart'.
Because libexec files might be in fact of any type.

-- 
Tomasz Pala <gotar at pld-linux.org>


From n3npq at me.com  Mon Feb 12 03:50:32 2018
From: n3npq at me.com (Jeff Johnson)
Date: Sun, 11 Feb 2018 21:50:32 -0500
Subject: libexec and multi-arch
In-Reply-To: <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
Message-ID: <2997F249-127C-49B3-B215-1E8FE435E833@me.com>



> On Feb 5, 2018, at 3:23 PM, Neal Gompa <ngompa13 at gmail.com> wrote:
> 
> I'd probably argue that libexec should have the same multi-arch
> handling that (s)bin does (primary arch "wins" and secondary arches
> are ignored), though last I checked this isn't specific to paths and
> should Just Work(TM).
> 
> 

And then there is the /usr/lib/rpm path to "probably argue" about.

Truly the best way out of all these discussions is to complete the 10+ year transition from 32bit to 64bit and stop the endless discussions and fiddle up retrofits.

73 de Jeff


From n3npq at me.com  Mon Feb 12 04:10:44 2018
From: n3npq at me.com (Jeff Johnson)
Date: Sun, 11 Feb 2018 22:10:44 -0500
Subject: libexec and multi-arch
In-Reply-To: <20180205224609.GA25569@polanet.pl>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <20180205224609.GA25569@polanet.pl>
Message-ID: <24CA682B-3556-4D27-B8A1-6C100B2806A1@me.com>



> On Feb 5, 2018, at 5:46 PM, Tomasz Pala <gotar at polanet.pl> wrote:
> 
> On Mon, Feb 05, 2018 at 15:20:55 -0500, Jeff Johnson wrote:
> 
>>> No, it only hidden the problem behind getconf binary being handled
>>> _somehow_. I once even wondered how this is done, apparently rpm is
>>> trying to be way too smart.
>> 
>> RPM implements arch specific content generally as:
>>  Libraries on different paths.
>>  Executables on same path.
> 
> libexec directory should be treated as binaries, not libraries (even if
> technically some of the contents are libraries, like plugins) nor data,
> as the purpose of this is to carry private helpers of the binaries, not
> any shared code.
> 
>> This requires a resolution to a preferred arch (usually x86_64) when installing executables onto identical paths.
> 
> How is rpm recognizing files that are subject to this special-handling
> as same-path-executables?

RPM reads elf headers and sets a per file color flag in metadata:
    0==no arch or not elf
    1==elf32
    2==elf64
    4== mostly unused, except on big endian mips
Bits were used instead of an enum in case some idiot decided to put both elf32 and elf64 in the same static archive.

Choosing between multiple files with different flags but identical paths is computed during install, and the preferred arch is used while other files are marked "wrong color" and not installed

> How to extend this to all the files inside libexecdir?

There's nothing to extend: the confusion comes from mixtures of libraries/modules/executables in libexecdir, not anything else.

> How to extend this to all the files in mandir maybe?
> 

There are no elf files in mandir, so an extension of what rpm does makes no sense.

Meanwhile there are many conventions to extend man pages, in subdirectories, and with suffixes, that can be used if necessary.

>> Whether RPM is too smart or the requested implementation is insufficiently general is arguable. For example, one might desire the ability for per-file-path configurable choice of architecture rather than per-system confIguration.
> 
> Or - to always use preferred arch, for ANY file that is overlapping in
> packages that differ only in arch, e.g. /etc or anything inside datadir.
> 

That is essentially what is implemented in rpm for files from different arch (technically "color" as in elf32 or elf64) that are on the same path.

> Currently, if such files exist, they need to have identical content for
> the packages to be installed simultaneously, or be separated into
> respective subpackages, which is unnecessary maintenance burden.
> 

Um, I'm not sure how rpm is responsible for packaging policies (like separated into sub packages) or maintenance burden.

hth

73 de Jeff
> -- 
> Tomasz Pala <gotar at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


From gotar at polanet.pl  Mon Feb 12 07:42:07 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 12 Feb 2018 07:42:07 +0100
Subject: libexec and multi-arch
In-Reply-To: <2997F249-127C-49B3-B215-1E8FE435E833@me.com>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
 <2997F249-127C-49B3-B215-1E8FE435E833@me.com>
Message-ID: <20180212064207.GA11030@polanet.pl>

On Sun, Feb 11, 2018 at 21:50:32 -0500, Jeff Johnson wrote:

> And then there is the /usr/lib/rpm path to "probably argue" about.

Not much to argue here until there are any _practical_ problems with
this location. Although for the sake of good order you might consider
using libexec here.

> Truly the best way out of all these discussions is to complete the 10+ year transition from 32bit to 64bit and stop the endless discussions and fiddle up retrofits.

Be my guest and just convert all the binary-only programs to 64 bit.
Including the commercial ones.

-- 
Tomasz Pala <gotar at pld-linux.org>


From gotar at polanet.pl  Mon Feb 12 07:55:34 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 12 Feb 2018 07:55:34 +0100
Subject: libexec and multi-arch
In-Reply-To: <24CA682B-3556-4D27-B8A1-6C100B2806A1@me.com>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <20180205224609.GA25569@polanet.pl>
 <24CA682B-3556-4D27-B8A1-6C100B2806A1@me.com>
Message-ID: <20180212065534.GB11030@polanet.pl>

On Sun, Feb 11, 2018 at 22:10:44 -0500, Jeff Johnson wrote:

>> How is rpm recognizing files that are subject to this special-handling
>> as same-path-executables?
> 
> RPM reads elf headers and sets a per file color flag in metadata:
>     0==no arch or not elf
>     1==elf32
>     2==elf64
>     4== mostly unused, except on big endian mips
> Bits were used instead of an enum in case some idiot decided to put both elf32 and elf64 in the same static archive.

OK, so it is really just being too smart. If it happens, that there
are some simple sh-scripts in %_bindir, they won't be colored and
so the multilib would require general-rules approach (the same file
content or prepare for conflict).

> Choosing between multiple files with different flags but identical paths is computed during install, and the preferred arch is used while other files are marked "wrong color" and not installed
> 
>> How to extend this to all the files inside libexecdir?
> 
> There's nothing to extend: the confusion comes from mixtures of libraries/modules/executables in libexecdir, not anything else.

I would explain this to you, but having a history of conversations in
mind I know this is pointless. So thank you for response to all my
questions.

> That is essentially what is implemented in rpm for files from different arch (technically "color" as in elf32 or elf64) that are on the same path.

I just wanted the colors to be used without elf headers.

But I guess this is simply another misdesign choice for the colors to be
inheritly connected with specific _file_ architecture, not entire
_package_ architecture (at least as a fallback), so for non-ELF files rpm is simply not going to
be a help.

>> Currently, if such files exist, they need to have identical content for
>> the packages to be installed simultaneously, or be separated into
>> respective subpackages, which is unnecessary maintenance burden.
> 
> Um, I'm not sure how rpm is responsible for packaging policies (like separated into sub packages) or maintenance burden.

Who says about responsibility? It simply doesn't help solving such cases.
And since they are happening frequently, this enforces to create some
decent packaging policy. It would be much better to solve this in some
single central tool, but there is no good package manager for Linux for
now, so we have to use what we have. I hope there would be some 21st
century package manager some day, handling ACLs, xattrs, file-versioning
etc.

-- 
Tomasz Pala <gotar at pld-linux.org>


From jajcus at jajcus.net  Mon Feb 12 09:04:07 2018
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 12 Feb 2018 09:04:07 +0100
Subject: RFC: x86-runtime packages (was: Re: libexec and multi-arch)
In-Reply-To: <20180212064207.GA11030@polanet.pl>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
 <2997F249-127C-49B3-B215-1E8FE435E833@me.com>
 <20180212064207.GA11030@polanet.pl>
Message-ID: <7a56c218-805f-f58e-7919-2ccd4e834e72@jajcus.net>

On 2018-02-12 07:42, Tomasz Pala wrote:
>> Truly the best way out of all these discussions is to complete the 10+ year transition from 32bit to 64bit and stop the endless discussions and fiddle up retrofits.
> 
> Be my guest and just convert all the binary-only programs to 64 bit.
> Including the commercial ones.

I was thinking about some other solution: Make some '32bit runtime'
packages which would be built from our i686 packages and contain only
the libraries and other necessary files needed to run x86 apps on x86_64
system.

This packages would be explicitly made not to conflict with anything
from x86_64 packages and installing .i686 packages in x86_64 system
would not be needed any more.

The packages could be:

x86-runtime-basesystem (glibc, libstdc++ with dependencies)
x86-runtime-X11 (X11 libraries, maybe with the popular toolkits)
x86-runtime-SDL (SDL_* ? mostly for games)
etc.

'Source*' in those specs would point to .i686.rpm files built by our
i686 builders.

Updating of the spec files could be partially automated.


Jacek


From mike at altlinux.org  Wed Feb 14 13:52:08 2018
From: mike at altlinux.org (Michael Shigorin)
Date: Wed, 14 Feb 2018 15:52:08 +0300
Subject: RFC: x86-runtime packages (was: Re: libexec and multi-arch)
In-Reply-To: <7a56c218-805f-f58e-7919-2ccd4e834e72@jajcus.net>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
 <2997F249-127C-49B3-B215-1E8FE435E833@me.com>
 <20180212064207.GA11030@polanet.pl>
 <7a56c218-805f-f58e-7919-2ccd4e834e72@jajcus.net>
Message-ID: <20180214125208.GB16406@imap.altlinux.org>

On Mon, Feb 12, 2018 at 09:04:07AM +0100, Jacek Konieczny wrote:
> >> Truly the best way out of all these discussions is to
> >> complete the 10+ year transition from 32bit to 64bit and
> >> stop the endless discussions and fiddle up retrofits.
> > Be my guest and just convert all the binary-only programs to 64 bit.
> > Including the commercial ones.
> I was thinking about some other solution: Make some '32bit runtime'
> packages which would be built from our i686 packages and
> contain only the libraries and other necessary files needed to
> run x86 apps on x86_64 system.

ALT did it through rpmrebuild and arepo (and rpmrebuild-arepo):
https://lists.altlinux.org/pipermail/devel/2012-April/193781.html
http://altlinux.org/biarch
(both links in Russian)

-- 
?---- WBR, Michael Shigorin / http://altlinux.org
??------ http://opennet.ru / http://anna-news.info


From gotar at polanet.pl  Wed Feb 14 15:23:51 2018
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 14 Feb 2018 15:23:51 +0100
Subject: RFC: x86-runtime packages (was: Re: libexec and multi-arch)
In-Reply-To: <7a56c218-805f-f58e-7919-2ccd4e834e72@jajcus.net>
References: <201802051014.41182.arekm@maven.pl> <20180205093634.GB4108@home>
 <e2ef7710-1060-9efa-9116-c2d9e6efb0e0@jajcus.net>
 <20180205151332.GB24069@polanet.pl>
 <574661AD-90A6-4EFE-BEBC-44401143C893@me.com>
 <CAEg-Je9HiYzxgC=wNWuahZ70YOzg3fRtmCye91da7CpH1kkLvQ@mail.gmail.com>
 <2997F249-127C-49B3-B215-1E8FE435E833@me.com>
 <20180212064207.GA11030@polanet.pl>
 <7a56c218-805f-f58e-7919-2ccd4e834e72@jajcus.net>
Message-ID: <20180214142351.GA24600@polanet.pl>

On Mon, Feb 12, 2018 at 09:04:07 +0100, Jacek Konieczny wrote:

> I was thinking about some other solution: Make some '32bit runtime'
> packages which would be built from our i686 packages and contain only
> the libraries and other necessary files needed to run x86 apps on x86_64
> system.
[...]
> Updating of the spec files could be partially automated.

If doing any magic on spec files, one could as well make them pure libs
(no other contents, except maybe for %_docdir) and the problem is solved.
However, this is not what should be done manually these days - I would
expect the package manager to either - build such pure libs subpackage
automatically (at most marking the spec files with some macro) or ignore
the conflicting contents during the install.

> This packages would be explicitly made not to conflict with anything
> from x86_64 packages and installing .i686 packages in x86_64 system
> would not be needed any more.

This is only part of the problem - there are other cases:
- installing multiple versions of some library in single arch (for legacy
  software),
- installing 32-bit apps in 64-bit environment - this MIGHT require
  installing other than pure-libs packages from 32-bit tree,
- installing packages from other distros, a PLD lacks MANY of useful
  software these days, or has some very old versions. I am really tired
  of compiling everything I want to use from sources, especially when
  time is a matter.

I am also tired of manually creating libs/devel/static subpackages (with 
dumb "%{name} devel files" descriptions and %post ldconfig repating all
over again) in spec files - this is SO automatable... Such development
is doomed.

> The packages could be:
> 
> x86-runtime-basesystem (glibc, libstdc++ with dependencies)
> x86-runtime-X11 (X11 libraries, maybe with the popular toolkits)
> x86-runtime-SDL (SDL_* ??? mostly for games)
> etc.

LDAP, kerberos, SASL, all-the-databases...? In fact, most of the
32-bit libs might be required.

This is much work for something, that should be handled by single tool.
What we need is some SysV->systemd-like transition for rpm, which is not
doing it's job. It was fine in '90s, but the world has changed.
Especially when there is appropriate code in core of rpm (colouring),
but the trivial solution is rejected by stucked in his own flat world
maintainer. Relying on such software has no future without tons of
package-maintainers.

-- 
Tomasz Pala <gotar at pld-linux.org>


From glen at delfi.ee  Fri Feb 16 11:58:39 2018
From: glen at delfi.ee (Elan Ruusamae)
Date: Fri, 16 Feb 2018 12:58:39 +0200
Subject: et_EE.UTF-8 locale gen broken
Message-ID: <9a9ff621-1a3d-ab9d-2bfd-2024b8e8289a@delfi.ee>

$ localedb-gen --locales et_EE.UTF-8/UTF-8 -d .
Generating et_EE.UTF-8 using charset UTF-8... failed to set locale!
[error] LC_COLLATE: missing `reorder-end' keyword
failed to set locale!
[error] no output file produced because errors were issued

DONE.

$ rpm -q glibc
glibc-2.27-3.x86_64

and why it's not even erroring out if command clearly got an error? i 
guess it's reason why pre-built version is also broken?



From glen at delfi.ee  Mon Feb 19 12:05:09 2018
From: glen at delfi.ee (Elan Ruusamae)
Date: Mon, 19 Feb 2018 13:05:09 +0200
Subject: et_EE.UTF-8 locale gen broken
In-Reply-To: <9a9ff621-1a3d-ab9d-2bfd-2024b8e8289a@delfi.ee>
References: <9a9ff621-1a3d-ab9d-2bfd-2024b8e8289a@delfi.ee>
Message-ID: <10621ca5-0b37-8dbd-a02a-15c2b9bf0ed4@delfi.ee>

reported upstream:

https://sourceware.org/bugzilla/show_bug.cgi?id=22861

fixed in pld


https://github.com/pld-linux/glibc/commit/8b435bd17628a5c73f5cfded06dbfa2d78680063 


https://github.com/pld-linux/glibc/commit/e54f46e702827b008db74edfa238621e18bd0cd9 



On 2/16/18 12:58 PM, Elan Ruusamae wrote:
> $ localedb-gen --locales et_EE.UTF-8/UTF-8 -d .
> Generating et_EE.UTF-8 using charset UTF-8... failed to set locale!
> [error] LC_COLLATE: missing `reorder-end' keyword
> failed to set locale!
> [error] no output file produced because errors were issued
>
> DONE.
>
> $ rpm -q glibc
> glibc-2.27-3.x86_64
>
> and why it's not even erroring out if command clearly got an error? i 
> guess it's reason why pre-built version is also broken?
>



From lukaszgl at post.pl  Mon Feb 19 14:34:37 2018
From: lukaszgl at post.pl (lukaszgl post.pl)
Date: Mon, 19 Feb 2018 14:34:37 +0100 (CET)
Subject: kmail issues after glibc update
Message-ID: <1459706810.4466458.1519047277722@poczta.home.pl>

Hi,

After last update of glibc kmail stopped to sending/receiving the e-mail with an error:

Cannot load library /usr/lib64/kde4/kio_pop3.so: (/lib64/libcrypt.so.1: symbol __open_nocancel, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference)
klauncher(1601)/kio (KLauncher) KLauncher::processRequestReturn: "kio_pop3"  failed.

?ukasz


From arekm at maven.pl  Mon Feb 19 16:00:21 2018
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Mon, 19 Feb 2018 16:00:21 +0100
Subject: kmail issues after glibc update
In-Reply-To: <1459706810.4466458.1519047277722@poczta.home.pl>
References: <1459706810.4466458.1519047277722@poczta.home.pl>
Message-ID: <201802191600.22027.arekm@maven.pl>

On Monday 19 of February 2018, lukaszgl post.pl wrote:
> Hi,
> 
> After last update of glibc kmail stopped to sending/receiving the e-mail
> with an error:
> 
> Cannot load library /usr/lib64/kde4/kio_pop3.so: (/lib64/libcrypt.so.1:
> symbol __open_nocancel, version GLIBC_PRIVATE not defined in file
> libc.so.6 with link time reference) klauncher(1601)/kio (KLauncher)
> KLauncher::processRequestReturn: "kio_pop3"  failed.

restart kde

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )