Leap 15 status update 20171110

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Leap 15 status update 20171110

Ludwig Nussel
Hi,

Two months after my last status update¹ Leap 15 is almost rolling.
Following SLE 15 I'd like to aim for a release in April.

Current status

- The project builds with only a few unresolvable/failed². Right
   now Leap 15 is more or less only the base system from SLE with
   GNOME plus KDE though.
- Staging projects are up and working³
- openQA tests the builds⁴. Builds would even be released
   automatically if they were more green.
- The leaper bot and update crawler keep Leap 15 in sync with SLE and Factory
- online repos are available on download.opensuse.org and there are
   even installable ISOs (manually released bypassing openQA).

If you followed the links you see lots of red, main reasons are

- yast switched to a new partitioning backing ("storage-ng") which
   is not complete yet and some openQA tests are not yet adopted
   either. That's why the RAID test fails in staging.
- Pattern or package dependency changes pull in X in a server
   install and the minimalX install installs GNOME (boo#1067477).
- The way kiwi files for DVD builds are generated has changed.
   Rather than a mechanism built into OBS it's now an external
   service (obs-service-product_converter). The scripts around that
   are not finished yet⁵, so the DVD lacks packages, supplements are
   not handled yet and neither are localization packages. Also,
   dropped packages are not yet listed as obsolete in the metadata so
   upgrades don't work properly.

Overall Leap 15 doesn't look broken though. Since I know of at least
one person who installed 15 already on his Laptop, I'd call this
Alpha state :-)

Next steps

- Fix the openQA test failures. Means adjust test case and submit
   missing packages. Help appreciated with that.
- Submit all packages that were in 42, are still in Factory and
   build for 15 from Factory to 15 (up to ~7500 packages). A script will
   do that when we're green enough. In order to avoid spamming too much
   there will be no explicit maintainer ACK. It will still be possible to
   file delete requests afterwards.
- Submit all remaining packages that build for 15 from Factory (up
   to ~1700 packages). Same mechanism as with 42. Package resp devel
   project maintainers will need to give their ok via reviews in the
   submit requests.
- Integrate a new Leap 15 branding. Right now we still have the
   Tumbleweed one.
- Maintainers of ports to architectures other than x86_64 may want to
   start looking into Leap 15.

cu
Ludwig

[1] https://lists.opensuse.org/opensuse-factory/2017-09/msg00140.html
[2] https://build.opensuse.org/project/status/openSUSE:Leap:15.0
     https://build.opensuse.org/project/monitor/openSUSE:Leap:15.0
[3] https://build.opensuse.org/project/dashboard/openSUSE:Leap:15.0
[4] https://openqa.opensuse.org/group_overview/50
[5] https://github.com/openSUSE/osc-plugin-factory/blob/master/pkglistgen.py

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Jan Engelhardt-4

On Friday 2017-11-10 11:18, Ludwig Nussel wrote:
>
> - Maintainers of ports to architectures other than x86_64 may want to
>  start looking into Leap 15.

So how do I get started with an i586 port, then?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Ludwig Nussel
Jan Engelhardt wrote:
>
> On Friday 2017-11-10 11:18, Ludwig Nussel wrote:
>>
>> - Maintainers of ports to architectures other than x86_64 may want to
>>   start looking into Leap 15.
>
> So how do I get started with an i586 port, then?

I think the first task would be to get an i586 kernel config into
the kernel package.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Larry Finger
In reply to this post by Ludwig Nussel
On 11/10/2017 04:18 AM, Ludwig Nussel wrote:

> Hi,
>
> Two months after my last status update¹ Leap 15 is almost rolling.
> Following SLE 15 I'd like to aim for a release in April.
>
> Current status
>
> - The project builds with only a few unresolvable/failed². Right
>    now Leap 15 is more or less only the base system from SLE with
>    GNOME plus KDE though.

One of those failed packages is VirtualBox, which I maintain. When trying builds
through the Factory => Leap 15 path, debugging is very slow when you find one
failure at a time. For that reason, I created a new package in
home:lwfinger:branches:openSUSE:Leap:15.0/virtualbox so that I could find and
fix the problems more quickly. With that package, osc builds fail with hundreds
of failures that say "liblua5.3.so.5: cannot open shared object file: No such
file or directory". How would I fix that problem?

Thanks,

Larry

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Stefan Seyfried
Am 10.11.2017 um 17:43 schrieb Larry Finger:
> that I could find and fix the problems more quickly. With that package,
> osc builds fail with hundreds of failures that say "liblua5.3.so.5:
> cannot open shared object file: No such file or directory". How would I
> fix that problem?

This sounds like a build root setup problem.
Try "osc build --clean"
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Roman Bysh-5
On 10/11/17 02:35 PM, Stefan Seyfried wrote:
> Am 10.11.2017 um 17:43 schrieb Larry Finger:
> > that I could find and fix the problems more quickly. With that package,
> > osc builds fail with hundreds of failures that say "liblua5.3.so.5:
> > cannot open shared object file: No such file or directory". How would I
> > fix that problem?
>
> This sounds like a build root setup problem.
> Try "osc build --clean"
>
Perhaps I missed the thread. Is Leap 15 using Plasma 5.11, 5.12 or 5.8.7?

--
Cheers!

Roman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Roman Bysh-5
On 10/11/17 04:28 PM, Roman Bysh wrote:

> On 10/11/17 02:35 PM, Stefan Seyfried wrote:
> > Am 10.11.2017 um 17:43 schrieb Larry Finger:
> > > that I could find and fix the problems more quickly. With that package,
> > > osc builds fail with hundreds of failures that say "liblua5.3.so.5:
> > > cannot open shared object file: No such file or directory". How would I
> > > fix that problem?
> >
> > This sounds like a build root setup problem.
> > Try "osc build --clean"
> >
> Perhaps I missed the thread. Is Leap 15 using Plasma 5.11, 5.12 or 5.8.7?
>
I found out that it is 5.11.2.

--
Cheers!

Roman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Larry Finger
In reply to this post by Stefan Seyfried
On 11/10/2017 01:35 PM, Stefan Seyfried wrote:
> Am 10.11.2017 um 17:43 schrieb Larry Finger:
>> that I could find and fix the problems more quickly. With that package,
>> osc builds fail with hundreds of failures that say "liblua5.3.so.5:
>> cannot open shared object file: No such file or directory". How would I
>> fix that problem?
>
> This sounds like a build root setup problem.
> Try "osc build --clean"

That was the problem. The build is now started.

Thanks,

Larry

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Luca Beltrame
In reply to this post by Roman Bysh-5
Il giorno Fri, 10 Nov 2017 16:28:34 -0500
Roman Bysh <[hidden email]> ha scritto:

> Perhaps I missed the thread. Is Leap 15 using Plasma 5.11, 5.12 or
> 5.8.7?

It's going to have 5.12 when it's out, which will be another LTS
release.

--
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Felix Miata-3
In reply to this post by Ludwig Nussel
Ludwig Nussel composed on 2017-11-10 11:18 (UTC+0100):

> Overall Leap 15 doesn't look broken though.
Very broken for me. No zypper is very bad:
https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
Is there any possibility to fix what I have rather than starting all over (and
arriving in the same place unless first something is fixed)?
--
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Jan Engelhardt-4
In reply to this post by Ludwig Nussel
On Friday 2017-11-10 13:21, Ludwig Nussel wrote:

> Jan Engelhardt wrote:
>>
>> On Friday 2017-11-10 11:18, Ludwig Nussel wrote:
>>>
>>> - Maintainers of ports to architectures other than x86_64 may want to
>>>   start looking into Leap 15.
>>
>> So how do I get started with an i586 port, then?
>
> I think the first task would be to get an i586 kernel config into
> the kernel package.

That one already exists (config/i386/).

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Roman Bysh-5
In reply to this post by Luca Beltrame
On 10/11/17 07:00 PM, Luca Beltrame wrote:
> Il giorno Fri, 10 Nov 2017 16:28:34 -0500
> Roman Bysh <[hidden email]> ha scritto:
>
>> Perhaps I missed the thread. Is Leap 15 using Plasma 5.11, 5.12 or
>> 5.8.7?
>
> It's going to have 5.12 when it's out, which will be another LTS
> release.
>

Great! I don't see plymouth working yet. Are we going to see a new theme
and a newer openSUSE Plasma theme?

--
Cheers!

Roman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Basil Chupin-2
In reply to this post by Felix Miata-3
On 11/11/17 16:59, Felix Miata wrote:
> Ludwig Nussel composed on 2017-11-10 11:18 (UTC+0100):
>
>> Overall Leap 15 doesn't look broken though.
> Very broken for me. No zypper is very bad:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
> Is there any possibility to fix what I have rather than starting all over (and
> arriving in the same place unless first something is fixed)?


Zypper is working perfectly for me.


BC

--
"You should never argue about politics or religion. Or anything else
if you're going to come out with crap like that."
                                              Anonymous circa 2013

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Felix Miata-3
In reply to this post by Ludwig Nussel
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):

> Felix Miata wrote:

>> Very broken for me. No zypper is very bad:
>> https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
>> Is there any possibility to fix what I have rather than starting all over (and
>> arriving in the same place unless first something is fixed)?

> Zypper is working perfectly for me.

On a freshly made upgrade from 42.x like I tried to do? If yes, with which DE(s)?
I had to remove a number of packages to be able to get past unresolvable deps,
and allow more than one to be "broken".
--
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Simon Lees-3


On 13/11/17 13:34, [hidden email] wrote:

> Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
>
>> Felix Miata wrote:
>
>>> Very broken for me. No zypper is very bad:
>>> https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
>>> Is there any possibility to fix what I have rather than starting all over (and
>>> arriving in the same place unless first something is fixed)?
>
>> Zypper is working perfectly for me.
>
> On a freshly made upgrade from 42.x like I tried to do?
But why are you doing it like that? its not meant to work zypper isn't
built against static libs instead we make sure the old one is perfectly
capable of upgrading to a new version. Running "ldd
/usr/lib64/libzypp.so.1600 will give you a list of some of the other
libraries that zypper requires you'd have to update all these as well.

> If yes, with which DE(s)?
> I had to remove a number of packages to be able to get past unresolvable deps,
> and allow more than one to be "broken".
>

Ludwig also said that currently its for the most part only the core
packages from SLE + KDE and that all the other packages that come from
factory / Leap haven't been imported yet so if you use lots of openSUSE
specific apps and a desktop other then Gnome / KDE / icewm you will be
missing things (but you were warned) if you want to see where your
packages come from look for them here "osc -A https://api.opensuse.org
cat openSUSE:Leap:42.3:Update 00Meta lookup.yml"

--

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


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: upgrade packaging not statically built (was: Leap 15 status update 20171110)

Felix Miata-3
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):

> Felix Miata wrote:

>> Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):

>>> Felix Miata wrote:

>>>> Very broken for me. No zypper is very bad:
>>>> https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
>>>> Is there any possibility to fix what I have rather than starting all over (and
>>>> arriving in the same place unless first something is fixed)?

>>> Zypper is working perfectly for me.

>> On a freshly made upgrade from 42.x like I tried to do?

> But why are you doing it like that?

Long before I discovered SuSE, urpmi would upgrade itself and its deps, then
restart before installing everything unrelated to package management. It made
sense then, and still did when I learned how to use zypper many moons ago.

I thought I was emulating this urpmi safety feature via an emulating script.
This was the first time it failed me after too many years to remember of working
as expected with distribution releases, Factory, and TW.

Why it makes sense is pretty simple, bad stuff happens, so avoid whatever
avoidable bad stuff you can. For these situations, I've been counting on rpm's
dependency competence. If everything package management related isn't completely
installed prior to an unplanned interrupting reboot, then restarting is likely
to irrecoverably fail. Where I live, power outages that outlast the UPS
batteries are almost as common as extended Internet interruptions, which is to
say too common.

> its not meant to work zypper isn't built against static libs

Package management first is a safety feature built into urpmi that's apparently
been found unnecessary by zypper devs, at least, not yet. :-(

> instead we make sure the old one is perfectly
> capable of upgrading to a new version. Running "ldd
> /usr/lib64/libzypp.so.1600 will give you a list of some of the other
> libraries that zypper requires you'd have to update all these as well.

So I guess my two line script could benefit from a study of ldd's 43 line
output, if I were capable of digesting it.

Thanks for your reply!
--
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: upgrade packaging not statically built

Simon Lees-3


On 13/11/17 15:04, Felix Miata wrote:

> Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
>
>> Felix Miata wrote:
>
>>> Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
>
>>>> Felix Miata wrote:
>
>>>>> Very broken for me. No zypper is very bad:
>>>>> https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
>>>>> Is there any possibility to fix what I have rather than starting all over (and
>>>>> arriving in the same place unless first something is fixed)?
>
>>>> Zypper is working perfectly for me.
>
>>> On a freshly made upgrade from 42.x like I tried to do?
>
>> But why are you doing it like that?
>
> Long before I discovered SuSE, urpmi would upgrade itself and its deps, then
> restart before installing everything unrelated to package management. It made
> sense then, and still did when I learned how to use zypper many moons ago.
>
> I thought I was emulating this urpmi safety feature via an emulating script.
> This was the first time it failed me after too many years to remember of working
> as expected with distribution releases, Factory, and TW.
>
> Why it makes sense is pretty simple, bad stuff happens, so avoid whatever
> avoidable bad stuff you can. For these situations, I've been counting on rpm's
> dependency competence. If everything package management related isn't completely
> installed prior to an unplanned interrupting reboot, then restarting is likely
> to irrecoverably fail. Where I live, power outages that outlast the UPS
> batteries are almost as common as extended Internet interruptions, which is to
> say too common.
>
>> its not meant to work zypper isn't built against static libs
>
> Package management first is a safety feature built into urpmi that's apparently
> been found unnecessary by zypper devs, at least, not yet. :-(
>
>> instead we make sure the old one is perfectly
>> capable of upgrading to a new version. Running "ldd
>> /usr/lib64/libzypp.so.1600 will give you a list of some of the other
>> libraries that zypper requires you'd have to update all these as well.
>
> So I guess my two line script could benefit from a study of ldd's 43 line
> output, if I were capable of digesting it.
Note this may not be the complete list, you also need to check the
zypper and rpm binaries as well, once the list gets long enough you
might find things that are pre install requirements as well.

--

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


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Leap 15 status update 20171110

Takashi Iwai
In reply to this post by Jan Engelhardt-4
On Sat, 11 Nov 2017 12:02:59 +0100,
Jan Engelhardt wrote:

>
> On Friday 2017-11-10 13:21, Ludwig Nussel wrote:
>
> > Jan Engelhardt wrote:
> >>
> >> On Friday 2017-11-10 11:18, Ludwig Nussel wrote:
> >>>
> >>> - Maintainers of ports to architectures other than x86_64 may want to
> >>>   start looking into Leap 15.
> >>
> >> So how do I get started with an i586 port, then?
> >
> > I think the first task would be to get an i586 kernel config into
> > the kernel package.
>
> That one already exists (config/i386/).

Not for openSUSE-15.0 branch.


Takashi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: upgrade packaging not statically built

Stefan Seyfried
In reply to this post by Simon Lees-3
On 13.11.2017 06:50, Simon Lees wrote:
> On 13/11/17 15:04, Felix Miata wrote:
>> Simon Lees composed on 2017-11-13 14:04 (UTC+1030):

>>> instead we make sure the old one is perfectly
>>> capable of upgrading to a new version. Running "ldd

Would be interesting to know how you handle today that zypper will always work with future versions.
A built-in DeLorean?

>>> /usr/lib64/libzypp.so.1600 will give you a list of some of the other
>>> libraries that zypper requires you'd have to update all these as well.
>>
>> So I guess my two line script could benefit from a study of ldd's 43 line
>> output, if I were capable of digesting it.
>
> Note this may not be the complete list, you also need to check the
> zypper and rpm binaries as well, once the list gets long enough you
> might find things that are pre install requirements as well.

"zypper up zypper" will just handle all that.
Afterwards, "zypper -v dup --no-r" should upgrade everything else.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: upgrade packaging not statically built (was: Leap 15 status update 20171110)

Martin Pluskal-2
In reply to this post by Felix Miata-3
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:

> Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
>
> > Felix Miata wrote:
> > > Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
> > > > Felix Miata wrote:
> > > > > Very broken for me. No zypper is very bad:
> > > > > https://bugzilla.opensuse.org/show_bug.cgi?id=1067737
> > > > > Is there any possibility to fix what I have rather than
> > > > > starting all over (and
> > > > > arriving in the same place unless first something is fixed)?
> > > > Zypper is working perfectly for me.
> > > On a freshly made upgrade from 42.x like I tried to do?
> > But why are you doing it like that?
>
> Long before I discovered SuSE, urpmi would upgrade itself and its
> deps, then
> restart before installing everything unrelated to package management.
> It made
> sense then, and still did when I learned how to use zypper many moons
> ago.
>
> I thought I was emulating this urpmi safety feature via an emulating
> script.
> This was the first time it failed me after too many years to remember
> of working
> as expected with distribution releases, Factory, and TW.
>
> Why it makes sense is pretty simple, bad stuff happens,
Hi

It seems that bad stuff that happened here is triggered somewhere
between chair and display.

Also note that for regulary maintained releases, zypper patch will
update package management stack (zypper, libzypp, rpm) befor installing
other updates. This does not make sense for dist upgrade where exactly
stuff that happened to you would happen - but hey I guess you know
better then developers of distribution.

Good luck with shooting yourself in leg (and I hope that you will keep
us updated)

Martin

signature.asc (849 bytes) Download Attachment
123