openSUSE Leap 15.3: some packages inherited from SLE are (probably) not rebuildable

newer
New Tumbleweed snapshot 20210127...

Matwey V. Kornilov

20 Jan 2021 20 Jan '21

19:31

Hi, I've just faced an interesting issue. As anybody knows, openSUSE Leap 15.3 partially inherits ready binary packages from SUSE Linux Enterprise, and partially has its own packages building from sources at OBS. This bundle is called openSUSE Leap 15.3 distro, and both binary rpms and source rpms ( http://download.opensuse.org/source/distribution/leap/15.3/ is empty now, but I suppose something eventually will appear here) are provided to end users. Lots was discussed about it. Now, let me please introduce the following simple experiment. Create an empty OBS subproject and assign openSUSE:Leap:15.3/standard as a repo to it. Then link e2fsprogs package from openSUSE:Leap:15.3 to your new empty home subproject: osc linkpac openSUSE:Leap:15.3 e2fsprogs home:matwey:x In other words, let's just rebuild e2fsprogs from Leap 15.3 against Leap 15.3. There is a little sense to do this because we expect that the result will be the same. So, wait for rebuilding and... see the error. I left a link to my version of the log: https://build.opensuse.org/build/home:matwey:x/openSUSE_Leap_15.3/x86_64/e2f... [ 52s] autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION [ 52s] ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer supported. [ 52s] configure.ac:857: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd [ 52s] aclocal.m4:69: AM_GNU_GETTEXT is expanded from... [ 52s] configure.ac:857: the top level [ 53s] configure:6517: error: possibly undefined macro: AM_INTL_SUBDIR [ 53s] If this token and others are legitimate, please use m4_pattern_allow. [ 53s] See the Autoconf documentation. [ 53s] autoreconf: /usr/bin/autoconf failed with exit status: 1 [ 53s] error: Bad exit status from /var/tmp/rpm-tmp.eU0KwE (%build) So, now we have a binary package (e2fsprogs) and sources for it, and we cannot rebuild the binary from the sources. The reason is that gettext 0.20 is currently supplied by openSUSE:Leap:15.3, but at some point in the SLE's past it was 0.19. And I bet that e2fsprogs was built against gettext 0.19 when the AM_GNU_GETTEXT macro worked without an error. But it came from SLE and we don't have the build logs (or have we?) However, the only we can see as a Leap 15.3 is a 'snapshot' of packages. So I expect the same behaviour when some end user will obtain the srpm for e2fsprogs and will try to rebuild it on his/her own box. Unfortunately, I don't know if e2fsprogs is a single one such case. This kind of inconsistency has a negative impact on having ports for non-SLE architectures (like armv7l), complicates end-user impact on debugging and modifying(?) stuff, and smells not quite well when we are talking about 'open source principles'. So, my question is how to avoid such issues and eventually have self-consistent Leap 15.3. -- With best regards, Matwey V. Kornilov

Attachments:

attachment.htm (text/html — 3.3 KB)

Show replies by date

Bernhard M. Wiedemann

20 Jan 20 Jan

20:36

On 20/01/2021 20.31, Matwey V. Kornilov wrote:

...

This kind of inconsistency has a negative impact on having ports for non-SLE architectures (like armv7l), complicates end-user impact on debugging and modifying(?) stuff, and smells not quite well when we are talking about 'open source principles'.

So, my question is how to avoid such issues and eventually have self-consistent Leap 15.3.

I checked, and the package is inherited from https://build.opensuse.org/package/show/SUSE:SLE-15:Update/e2fsprogs so it is indeed built there with the old https://build.opensuse.org/package/show/SUSE:SLE-15:Update/gettext-runtime And the new version is an overlay in https://build.opensuse.org/package/show/openSUSE:Leap:15.3/gettext-runtime It is probably not easy to solve that. Maybe one could avoid overlays of SLE packages in the main Leap repo and have extra repos for stuff that needs those overlays to build. Increases complexity even more...

Richard Biener

21 Jan 21 Jan

07:42

On Wed, 20 Jan 2021, Bernhard M. Wiedemann wrote:

...

On 20/01/2021 20.31, Matwey V. Kornilov wrote:

...
This kind of inconsistency has a negative impact on having ports for non-SLE architectures (like armv7l), complicates end-user impact on debugging and modifying(?) stuff, and smells not quite well when we are talking about 'open source principles'.

So, my question is how to avoid such issues and eventually have self-consistent Leap 15.3.

I checked, and the package is inherited from https://build.opensuse.org/package/show/SUSE:SLE-15:Update/e2fsprogs so it is indeed built there with the old https://build.opensuse.org/package/show/SUSE:SLE-15:Update/gettext-runtime

And the new version is an overlay in https://build.opensuse.org/package/show/openSUSE:Leap:15.3/gettext-runtime

It is probably not easy to solve that. Maybe one could avoid overlays of SLE packages in the main Leap repo and have extra repos for stuff that needs those overlays to build. Increases complexity even more...

I think the solution is to spot such issues and try to fix the package so it builds against both SLE-15:Update and SP3 / 15.3 and submit it as update to SLE-15:Update. Of course it's a very bad idea to overlay packages like gettext-runtime in Leap 15.3 without verifying that this doesn't break the build of existing packages. Don't we have stagings for that? Alternatively we'd have to mirror the SLE repo layout, exposing :Update, SP1:Update and SP2:Update binary packages as well as which project the binary package that was aggregated was built against. Even with the new setup in Leap 15.3 the product layout is sufficiently different to be a pain in the ass. Re-using binary packages doesn't change that fact. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Stephan Kulow

09:46

Am 21.01.21 um 08:42 schrieb Richard Biener:

...

Of course it's a very bad idea to overlay packages like gettext-runtime in Leap 15.3 without verifying that this doesn't break the build of existing packages. Don't we have stagings for that?

We have stagings to verify SP3 packages don't break existing SP3 packages. We don't rebuild old service packs with new packages. Not in production, not in staging. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh

Richard Biener

10:30

On Thu, 21 Jan 2021, Stephan Kulow wrote:

...

Am 21.01.21 um 08:42 schrieb Richard Biener:

...
Of course it's a very bad idea to overlay packages like gettext-runtime in Leap 15.3 without verifying that this doesn't break the build of existing packages. Don't we have stagings for that?

We have stagings to verify SP3 packages don't break existing SP3 packages. We don't rebuild old service packs with new packages. Not in production, not in staging.

But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?). Wishful thinking of course ;) Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Stephan Kulow

10:36

Am 21.01.21 um 11:30 schrieb Richard Biener:

...

But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you? Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh

Lubos Kocman

12:47

Hello Richard, I do have some bad and also kind of good news for you. We can't really ensure rebuildability of inherited binary packages from SLE in openSUSE Leap 15.3 (or rather Backports) buildroot. The good news at least in this direction (rebuildability): Dirk, Guillaume and Adrian are now working on how can we rebuild ARMv7. So we're very much aware of the problem. So far the approach to start try to bootstrap (just intel in the first wave to make it more simple) on SLE-15:Updates has moved effort tiny-bit further. If you really care about rebuildability of something "close" to Leap 15.3, then I recommend you to reach out to Dirk or Adrian and get involved in the effort. Hope it helps On Thu, 2021-01-21 at 11:36 +0100, Stephan Kulow wrote:

...

Am 21.01.21 um 11:30 schrieb Richard Biener:

...
But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you?

Greetings, Stephan

-- Lubos Kocman Release Manager openSUSE Leap SUSE LINUX, s.r.o. Krizikova 148/34 tel: +49 173 5876850 186 00 Praha 8 http://www.suse.com Czech Republic

Matwey V. Kornilov

24 Jan 24 Jan

15:23

21.01.2021 15:47, Lubos Kocman пишет:

...

Hello Richard,

I do have some bad and also kind of good news for you.

We can't really ensure rebuildability of inherited binary packages from SLE in openSUSE Leap 15.3 (or rather Backports) buildroot.

The good news at least in this direction (rebuildability):

Dirk, Guillaume and Adrian are now working on how can we rebuild ARMv7. So we're very much aware of the problem. So far the approach to start try to bootstrap (just intel in the first wave to make it more simple) on SLE-15:Updates has moved effort tiny-bit further.

I've found the initial issue when was doing basically the same "just for fun". Now I see that glibc 2.31 from Leap 15.3 is too new to build bison, coreutils, findutils, m4, sed, and probably many other Leap 15.3 packages. All this guys bundle the gnulib sources that are incompatible with glibc

...

2.28.

Now I am bit more skeptical that ARMv7 rebuild will succeed...

...

If you really care about rebuildability of something "close" to Leap 15.3, then I recommend you to reach out to Dirk or Adrian and get involved in the effort.

Hope it helps

On Thu, 2021-01-21 at 11:36 +0100, Stephan Kulow wrote:

...
Am 21.01.21 um 11:30 schrieb Richard Biener:

...
But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you?

Greetings, Stephan

Guillaume Gardet

25 Jan 25 Jan

08:14

...

-----Original Message----- From: Matwey V. Kornilov Sent: 24 January 2021 16:23 To: factory@lists.opensuse.org Subject: Re: openSUSE Leap 15.3: some packages inherited from SLE are (probably) not rebuildable

21.01.2021 15:47, Lubos Kocman пишет:

...
Hello Richard,

I do have some bad and also kind of good news for you.

We can't really ensure rebuildability of inherited binary packages from SLE in openSUSE Leap 15.3 (or rather Backports) buildroot.

The good news at least in this direction (rebuildability):

Dirk, Guillaume and Adrian are now working on how can we rebuild ARMv7. So we're very much aware of the problem. So far the approach to start try to bootstrap (just intel in the first wave to make it more simple) on SLE-15:Updates has moved effort tiny-bit further.

I've found the initial issue when was doing basically the same "just for fun".

Now I see that glibc 2.31 from Leap 15.3 is too new to build bison, coreutils, findutils, m4, sed, and probably many other Leap 15.3 packages.

All this guys bundle the gnulib sources that are incompatible with glibc

...
2.28.

Now I am bit more skeptical that ARMv7 rebuild will succeed...

It will not be trivial, for sure! Let's see if we can sort this out, on time. Guillaume

...

...
If you really care about rebuildability of something "close" to Leap 15.3, then I recommend you to reach out to Dirk or Adrian and get involved in the effort.

Hope it helps

On Thu, 2021-01-21 at 11:36 +0100, Stephan Kulow wrote:

...
Am 21.01.21 um 11:30 schrieb Richard Biener:

...
But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you?

Greetings, Stephan

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Richard Biener

08:46

On Sun, 24 Jan 2021, Matwey V. Kornilov wrote:

...

21.01.2021 15:47, Lubos Kocman пишет:

...
Hello Richard,

I do have some bad and also kind of good news for you.

We can't really ensure rebuildability of inherited binary packages from SLE in openSUSE Leap 15.3 (or rather Backports) buildroot.

The good news at least in this direction (rebuildability):

Dirk, Guillaume and Adrian are now working on how can we rebuild ARMv7. So we're very much aware of the problem. So far the approach to start try to bootstrap (just intel in the first wave to make it more simple) on SLE-15:Updates has moved effort tiny-bit further.

I've found the initial issue when was doing basically the same "just for fun".

Now I see that glibc 2.31 from Leap 15.3 is too new to build bison, coreutils, findutils, m4, sed, and probably many other Leap 15.3 packages.

Note that such issues might also hit SLE customers so I still think that at least _knowing_ this effect on re-buildability should be a must (just costs some extra build power). That said, not being able to re-build a openSUSE distribution is bad and it should warrant some public documentation on how to eventually bootstrap it starting from say a Leap 15.1 build env. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Richard Biener

22 Jan 22 Jan

08:59

On Thu, 21 Jan 2021, Stephan Kulow wrote:

...

Am 21.01.21 um 11:30 schrieb Richard Biener:

...
But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you?

Yes. I'm questioning the technical setup and criteria as to when Jump and SLE differ (which I understand from the original message in this thread is the case for gettext?) Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Stephan Kulow

11:00

Am 22.01.21 um 09:59 schrieb Richard Biener:

...

On Thu, 21 Jan 2021, Stephan Kulow wrote:

...
Am 21.01.21 um 11:30 schrieb Richard Biener:

...
But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you?

Yes. I'm questioning the technical setup and criteria as to when Jump and SLE differ (which I understand from the original message in this thread is the case for gettext?)

No, the gettext fork comes from SP3 Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh

Richard Biener

11:21

On Fri, 22 Jan 2021, Stephan Kulow wrote:

...

Am 22.01.21 um 09:59 schrieb Richard Biener:

...
On Thu, 21 Jan 2021, Stephan Kulow wrote:

...
Am 21.01.21 um 11:30 schrieb Richard Biener:

...
But this is a Leap 15.3 "overlay" of gettext-runtime and Leap 15.3 includes all packages (it's not a service pack ontop of Leap 15.2) so I would expect that _Leap_ verifies, when adding an "overlay", that it can rebuild SLE inherited packages(?).

The news of Jump reached you?

Yes. I'm questioning the technical setup and criteria as to when Jump and SLE differ (which I understand from the original message in this thread is the case for gettext?)

No, the gettext fork comes from SP3

Oh, I see, then my comments do not apply and it's the ususal SLE "problem". Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Matthias G. Eckermann

23:51

On 2021-01-22 T 12:21 +0100 Richard Biener wrote:

...

Oh, I see, then my comments do not apply and it's the ususal SLE "problem".

Other people would say "SLE value" of stability. SCNR:-) Enjoy the weekend and stay healthy! So long - MgE -- Matthias G. Eckermann, Director Product Management Linux Platforms SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

Stefan Seyfried

23 Jan 23 Jan

08:31

On 23.01.21 00:51, Matthias G. Eckermann wrote:

...

On 2021-01-22 T 12:21 +0100 Richard Biener wrote:

...
Oh, I see, then my comments do not apply and it's the ususal SLE "problem".

Other people would say "SLE value" of stability. SCNR:-)

Don't get me started. Config changes in a base package (LVM2) breaking SUSE's very own tools for everyone, with a bug reference that's (of course, as always) non-public. "Stability?" "SLES?" Whom are you kidding here? Obviously this thing has gone out with zero QA testing. Nowadays I'm really not sure if "more and more SLES in Leap" brings benefits or only pain and seriously consider switching my private servers to Tumbleweed. If I report an error against Tumbleweed, it will at least be publicly visible and often be fixed timely. P.S: The lvm2 changelog entry * Di Jan 05 2021 heming.zhao@suse.com - lvm2 should use 'external_device_info_source="udev"' by default (bsc#1179691) - change lvm.conf item external_device_info_source from none to udev The kiwi issue I had to solve to get my SLES15-SP2 images to build again: https://github.com/OSInside/kiwi/issues/1665 I don't even dare to report the issue to our DSE to get a fix for kiwi in SLES as I'm building my own version anyway. Sorry for the rant, but SLE management being totally out of sync with reality and then spreading "alternative facts" just makes me angry. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Michael Ströder

10:05

On 1/23/21 9:31 AM, Stefan Seyfried wrote:

...

Nowadays I'm really not sure if "more and more SLES in Leap" brings benefits or only pain and seriously consider switching my private servers to Tumbleweed. If I report an error against Tumbleweed, it will at least be publicly visible and often be fixed timely.

I'm running Tumbleweed everywhere and it's just fine. Moreover I can fix/update things in Tumbleweed myself more easily. The server software packages I care about are nearly all maintained in SLE. So all my update submissions for Leap were rejected in the past. I will never ever try to contribute to Leap again. Ciao, Michael.

Matwey V. Kornilov

20:17

23.01.2021 11:31, Stefan Seyfried пишет:

...

On 23.01.21 00:51, Matthias G. Eckermann wrote:

...
On 2021-01-22 T 12:21 +0100 Richard Biener wrote:

...
Oh, I see, then my comments do not apply and it's the ususal SLE "problem".

Other people would say "SLE value" of stability. SCNR:-)

Don't get me started. Config changes in a base package (LVM2) breaking SUSE's very own tools for everyone, with a bug reference that's (of course, as always) non-public.

"Stability?" "SLES?" Whom are you kidding here? Obviously this thing has gone out with zero QA testing.

Nowadays I'm really not sure if "more and more SLES in Leap" brings benefits or only pain and seriously consider switching my private servers to Tumbleweed. If I report an error against Tumbleweed, it will at least be publicly visible and often be fixed timely.

P.S: The lvm2 changelog entry * Di Jan 05 2021 heming.zhao@suse.com - lvm2 should use 'external_device_info_source="udev"' by default (bsc#1179691) - change lvm.conf item external_device_info_source from none to udev

Yes, this references to "private" bugs are also full of fun :-) Once somebody even sent me a submit request to erlang package fixing such a bug, which I could not even read :-)

...

The kiwi issue I had to solve to get my SLES15-SP2 images to build again: https://github.com/OSInside/kiwi/issues/1665 I don't even dare to report the issue to our DSE to get a fix for kiwi in SLES as I'm building my own version anyway.

Sorry for the rant, but SLE management being totally out of sync with reality and then spreading "alternative facts" just makes me angry.

Simon Lees

24 Jan 24 Jan

10:47


On 1/24/21 6:47 AM, Matwey V. Kornilov wrote:
> 23.01.2021 11:31, Stefan Seyfried пишет:
>> On 23.01.21 00:51, Matthias G. Eckermann wrote:
>>> On 2021-01-22 T 12:21 +0100 Richard Biener wrote:
>> P.S:
>> The lvm2 changelog entry
>> * Di Jan 05 2021 heming.zhao@suse.com
>> - lvm2 should use 'external_device_info_source="udev"' by default
>> (bsc#1179691)
>>   - change lvm.conf item external_device_info_source from none to udev
> 
> Yes, this references to "private" bugs are also full of fun :-)
> 
> Once somebody even sent me a submit request to erlang package fixing
> such a bug, which I could not even read :-)

In cases such as this (an openSUSE contributor needing access to private
bugs to perform there duties such as maintainership) you can email
bugshare@lists.opensuse.org and i'll sort something out longer term I
believe people are still working on a better plan.

-- 
Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Stefan Seyfried

11:14

On 24.01.21 11:47, Simon Lees wrote:

...

In cases such as this (an openSUSE contributor needing access to private bugs to perform there duties such as maintainership)

This is not only "to perform their(!) duties such as maintainership". People just might want to know *why* their systems had been broken deliberately for no visible gain.

...

you can email bugshare@lists.opensuse.org

this has not worked out well in the past. I sent around 20 requests and not a single bug was opened IIRC. I sometimes got very general summaries of the bug content, but nothing remotely useful, so I just gave up. *ALL* bugzilla entries for openSUSE packages need to be public.

...

and i'll sort something out longer term I believe people are still working on a better plan.

I don't believe this. There were no status update for 2½ years. So my guess is that this "project" has just silently been dropped. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Simon Lees

11:41

On 1/24/21 9:44 PM, Stefan Seyfried wrote:

...

On 24.01.21 11:47, Simon Lees wrote:

...
In cases such as this (an openSUSE contributor needing access to private bugs to perform there duties such as maintainership)

This is not only "to perform their(!) duties such as maintainership". People just might want to know *why* their systems had been broken deliberately for no visible gain.

No this was created as a temporary workaround for this issue to allow openSUSE contributors to perform there contributions. Due to the manual nature of the workaround it isn't scalable to provide information to all users.

...

...
you can email bugshare@lists.opensuse.org

this has not worked out well in the past. I sent around 20 requests and not a single bug was opened IIRC. I sometimes got very general summaries of the bug content, but nothing remotely useful, so I just gave up.

Yes as previously said this wasn't designed to scale to this kind of level.

...

*ALL* bugzilla entries for openSUSE packages need to be public.

I strongly agree with this statement and have raised it at every opportunity possible.

...

...
and i'll sort something out longer term I believe people are still working on a better plan.

I don't believe this. There were no status update for 2½ years. So my guess is that this "project" has just silently been dropped.

I also hoped that it would take less then 2.5 years to migrate away from our dated bugzilla instance to something else. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Matwey V. Kornilov

11:21

24.01.2021 13:47, Simon Lees пишет:
> 
> 
> On 1/24/21 6:47 AM, Matwey V. Kornilov wrote:
>> 23.01.2021 11:31, Stefan Seyfried пишет:
>>> On 23.01.21 00:51, Matthias G. Eckermann wrote:
>>>> On 2021-01-22 T 12:21 +0100 Richard Biener wrote:
>>> P.S:
>>> The lvm2 changelog entry
>>> * Di Jan 05 2021 heming.zhao@suse.com
>>> - lvm2 should use 'external_device_info_source="udev"' by default
>>> (bsc#1179691)
>>>   - change lvm.conf item external_device_info_source from none to udev
>>
>> Yes, this references to "private" bugs are also full of fun :-)
>>
>> Once somebody even sent me a submit request to erlang package fixing
>> such a bug, which I could not even read :-)
> 
> In cases such as this (an openSUSE contributor needing access to private
> bugs to perform there duties such as maintainership) you can email
> bugshare@lists.opensuse.org and i'll sort something out longer term I
> believe people are still working on a better plan.
> 

Good to know this. Thanks.

Martin Wilck

25 Jan 25 Jan

23:58

On Sat, 2021-01-23 at 09:31 +0100, Stefan Seyfried wrote:

...

The lvm2 changelog entry * Di Jan 05 2021 heming.zhao@suse.com - lvm2 should use 'external_device_info_source="udev"' by default (bsc#1179691) - change lvm.conf item external_device_info_source from none to udev

I'm sorry if this caused trouble. Heming did this on my request. It solves a bunch of nasty problems with LVM2 and multipath (as a matter of fact, LVM2 and multipath can't work reliably together without it), and neither Heming or I nor anyone involved in the QA/maintenance process noticed regressions. If it broke something for you, I'd appreciate a bug report. Martin

Martin Wilck

26 Jan 26 Jan

00:29

On Tue, 2021-01-26 at 00:58 +0100, Martin Wilck wrote:

...

On Sat, 2021-01-23 at 09:31 +0100, Stefan Seyfried wrote:

...
The lvm2 changelog entry * Di Jan 05 2021 heming.zhao@suse.com - lvm2 should use 'external_device_info_source="udev"' by default (bsc#1179691) - change lvm.conf item external_device_info_source from none to udev

I'm sorry if this caused trouble. Heming did this on my request. It solves a bunch of nasty problems with LVM2 and multipath (as a matter of fact, LVM2 and multipath can't work reliably together without it), and neither Heming or I nor anyone involved in the QA/maintenance process noticed regressions.

If it broke something for you, I'd appreciate a bug report.

So, you were referencing the Kiwi issue (https://github.com/OSInside/kiwi/issues/1665) It's unfortunate that this happened, perhaps there should be more coverage of kiwi applications in QA. However, in the usual SLE environment (and TW/Leap likewise I'd say), the configuration change improves stability a lot. In short, the background is that with "external_device_info_source=none", LVM commands can't determine reliably whether or a given device is going to be part of a multipath device or an MD device. LVM can only detect this after the fact, i.e. if the device has already been made part of a multipath map or an MD array by multipathd or mdadm, which makes the setup procedure during boot highly racy and error-prone. "external_device_info_source=udev" eliminates this by using the same logic that systemd and all other system components use to determine these device properties. Regards Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer

Dirk Müller

28 Jan 28 Jan

11:00

HI Matwey, Am Mi., 20. Jan. 2021 um 20:31 Uhr schrieb Matwey V. Kornilov :

...

This kind of inconsistency has a negative impact on having ports for non-SLE architectures (like armv7l), complicates end-user impact on debugging and modifying(?) stuff, and smells not quite well when we are talking about 'open source principles'.

Yeah, you only discovered the tip of the iceberg. there are several problems of that nature. For the last couple of weeks I've been trying to get SLE rebuilt from sources under devel:ARM:SUSE:SLE-15-SP3/SP2/SP1 etc. There are also fun topics like "there is no kernel to build". your help in troubleshooting is greatly appreciated there. we're coordinating work via #opensuse-arm. Greetings, Dirk

1183

Age (days ago)

1191

Last active (days ago)

List overview

Download

23 comments

13 participants

participants (13)

Bernhard M. Wiedemann
Dirk Müller
Guillaume Gardet
Lubos Kocman
Martin Wilck
Martin Wilck
Matthias G. Eckermann
Matwey V. Kornilov
Michael Ströder
Richard Biener
Simon Lees
Stefan Seyfried
Stephan Kulow

openSUSE Leap 15.3: some packages inherited from SLE are (probably) not rebuildable

tags

participants (13)