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/e2…
[ 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
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...
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:
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 <rguenther(a)suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
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... 
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
10:30
On Thu, 21 Jan 2021, Stephan Kulow wrote:
Am 21.01.21 um 08:42 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(?).
Wishful thinking of course ;)
Richard.
--
Richard Biener <rguenther(a)suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
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.
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
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:
--
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
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
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
>>
>
25 Jan
25 Jan
08:14
-----Original Message-----
From: Matwey V. Kornilov <matwey.kornilov(a)gmail.com>
Sent: 24 January 2021 16:23
To: factory(a)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 пишет:
It will not be trivial, for sure!
Let's see if we can sort this out, on time.
Guillaume
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
>>
>
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.
08:46
On Sun, 24 Jan 2021, Matwey V. Kornilov wrote:
21.01.2021 15:47, Lubos Kocman пишет:
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 <rguenther(a)suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
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.
22 Jan
22 Jan
08:59
On Thu, 21 Jan 2021, Stephan Kulow wrote:
Am 21.01.21 um 11:30 schrieb Richard Biener:
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 <rguenther(a)suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
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?
11:00
Am 22.01.21 um 09:59 schrieb Richard Biener:
On Thu, 21 Jan 2021, Stephan Kulow wrote:
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
Am 21.01.21 um 11:30 schrieb Richard Biener:
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?)
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?
11:21
On Fri, 22 Jan 2021, Stephan Kulow wrote:
Am 22.01.21 um 09:59 schrieb Richard Biener:
Oh, I see, then my comments do not apply and it's the ususal SLE
"problem".
Richard.
--
Richard Biener <rguenther(a)suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Thu, 21 Jan 2021, Stephan Kulow wrote:
No, the gettext fork comes from SP3 Am 21.01.21 um 11:30 schrieb Richard Biener:
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?)
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? 
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
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:
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(a)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
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:-) 
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.
20:17
23.01.2021 11:31, Stefan Seyfried пишет:
On 23.01.21 00:51, Matthias G. Eckermann wrote:
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.
On 2021-01-22 T 12:21 +0100 Richard Biener
wrote:
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(a)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 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:-) 
24 Jan
24 Jan
10:47
On 1/24/21 6:47 AM, Matwey V. Kornilov wrote:
23.01.2021 11:31, Stefan Seyfried пишет:
In cases such as this (an openSUSE contributor needing access to private
bugs to perform there duties such as maintainership) you can email
bugshare(a)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
On 23.01.21 00:51, Matthias G. Eckermann wrote:
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 :-) On 2021-01-22 T 12:21 +0100 Richard Biener wrote:
P.S:
The lvm2 changelog entry
* Di Jan 05 2021 heming.zhao(a)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
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(a)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
11:41
On 1/24/21 9:44 PM, Stefan Seyfried wrote:
Yes as previously said this wasn't designed to scale to this kind of level.
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
On 24.01.21 11:47, Simon Lees wrote:
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.
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(a)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.
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.
11:21
24.01.2021 13:47, Simon Lees пишет:
On 1/24/21 6:47 AM, Matwey V. Kornilov wrote:
Good to know this. Thanks.
23.01.2021 11:31, Stefan Seyfried пишет:
In cases such as this (an openSUSE contributor needing access to private
bugs to perform there duties such as maintainership) you can email
bugshare(a)lists.opensuse.org and i'll sort something out longer term I
believe people are still working on a better plan.
On 23.01.21 00:51, Matthias G. Eckermann wrote:
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 :-) On 2021-01-22 T 12:21 +0100 Richard Biener wrote:
P.S:
The lvm2 changelog entry
* Di Jan 05 2021 heming.zhao(a)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 
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(a)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
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:
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 <mwilck(a)suse.com>om>, Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix Imendörffer
The lvm2 changelog entry
* Di Jan 05 2021 heming.zhao(a)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. 
28 Jan
28 Jan
11:00
HI Matwey,
Am Mi., 20. Jan. 2021 um 20:31 Uhr schrieb Matwey V. Kornilov
<matwey.kornilov(a)gmail.com>om>:
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
79
days inactive
87
days old
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