-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/03/2015 05:37 AM, Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Stephan Kulow :

...

Hi,

I have a new topic ;)

As the bootstraping of openSUSE:42 is almost done (already looking forward to do the same from scratch with openSUSE:$NEWNAME) I wonder how we go from there.

I would like simple (to enforce) submission rules. So submission from openSUSE:Factory or SUSE:SLE-12:Update only (:Update overshadows SLE-12:GA, so it has all sle12 packages). Then we would test compile the submissions in a staging project light (in IRC we did some brain storming and Staging:adi:<NR> was the best suggestion so far) to see if the submitted packages compile in 42 and accept.

I think this is a fair 'first rule', but I can imagine exceptions, like 'just changed build flags', changed feature set which we would want in :42, but the package in TW might have progressed much more than just that.

Shouldn't the package from SUSE:SLE-12:Update be 'automatically' considered for :42? I guess a bot submitting those changes should do as well (if something was good for SLE, it should be good for :42 - unless it reverts something that moved already a bit further ahead)

As a practical example for where an exception of submissions only from TW might be needed: Xorg in :42 is currently at version 1.15.2, Tumbleweed is at 1.17.1 yet, I need X configured with --enable-systemd-logind; this corresponds to Submit request https://build.opensuse.org/request/show/287362 that was done against TW 4 months ago.

Alternatively, of course, the SLE package might receive an 'update' with the new build flags; but that sounds very unrealistic as an update.

Sadly, with OBS, it is not possible to 'cherry pick' such changes, so whoever is going to submit that fix for TW needs to have a way to except from 'only submissions from openSUSE:Factory' are allowed.

And I'm sure there are more such cases where we'd see small variations, but the TW version diverged too much already.

I agree. It appears that we'd need some kind of easily identifiable marker in the GUI and on the command line output that tells us something about the origin of the package. Otherwise one will have to dig around or depend on custom scripts that are known to one or two people. If we stick with X as the example. Maybe the decision is made that X from TW is a better fit for Leap then everyone should be able to look at the package in OBS either WEB UI or via osc command and immediately get information about the package origin, TW in this case. If the source of a package originates from SLE_12:Updates it should also be evident. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVmm0lAAoJEE4FgL32d2UkSFcH/2sYtHUxHfnThrHyWjAv5lfD N2b5FLFMVPJD6vY0PFPAgFtoIgnHXgSKLFKmVadO/ywQmYBwRFuwCq+hJPIMbFH1 OGX5MxjIpX0OV0duRw/zme8zNahBO/JTYwUoyXgQdWGNjx5C4BaqiJOk46V2UgJX egS5A6QfWwQKXeYvNehGDtOme3F4KLpC/apVDH6MUH/1+54ePlPvJVncbgGGJkpK V3EBBuobArNQtfA5GrREA8tBngmUELEUSevv5IW66wAmqfgJv4InA6JffB6W3nj8 /1/S535VIPDdRRZZATwRlmcUzi3UrMnd+DgX9nD/H+efJ56hkh8X029wh0fkG0M= =drvH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/03/2015 05:50 AM, Mathias Homann wrote:

Hi,

I guess I didn't pay too much attention until now:

Well that is a bit of a problem at this point in the discussion.

Do I understand right that the next openSUSE enduser desktop release will be based on the latest SLES (which I'd understand to be SLES12)?

Does this mean that the next openSUSE enduser desktop release in some parts will use older components than the current openSUSE 13.2 (for example the kernel)?

Yes, not necessarily, and no. If one just looks at the version number (kernel for example) then the answer is yes, for gcc the answer is no. However, if one cares about what is actually inside the package then the answer is not necessarily. As I pointed out in one e-mail the kernel carries some 5000+ patches. Many of those backport features from kernels with a version number that is greater than the version number of the kernel that is in openSUSE 13.2. Other parts of the kernel are older. What is not yet clear is how things that are not of interest to SUSE for SLE would get backported. As Leap has an older kernel base backporting does become more difficult as time passes. Anyway, we all have to see how this plays out, there are many unanswered questions that will only get answered as Leap develops and we'll see how the SLE sources evolve. Maybe SUSE will deliver new kernel sources every other service pack and maybe SUSE will manage to deliver a new service pack every year. No one knows at this point, no announcements or commitments have been made.

All in all I hope this article is "full of sh*t": http://www.heise.de/newsticker/meldung/OpenSuse-setzt-mit-42-auf-Unter

bau-von-Suse-Linux-Enterprise-2731743.html

The article basically doesn't make "42" look very good. Less drivers, older software, less software than the current 13.2.

Well if one just looks at the version number that is certainly the conclusion one can draw. However, just a bit below the surface a different picture presents itself. How to communicate this will certainly be an interesting challenge for the marketing and messaging of Leap. However, this discussion is really way of topic and we should stop this part of the thread. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVmnCJAAoJEE4FgL32d2Uk9b4IAKFgYxBGUQNvy8N0wsV9v7qO OZuiqUAZkNiwSNRDgy4w1pSVDrQw6c8kiaY1enffsjfdJWJc/PeEAk9SsN5iNM6f 5ISmmBQE78AmWBoV3OMiPC7/vvPo8lTCY0pi4CfaJp1z4b1TrhQhzor0edfTpsoA DpNU8RHr0Yw2sQV5zjc4XWnMq6hRsMjSNBe0tNMknTsXbR8ROm8EfKHnmEHwItRe UoRaAoIN3VimlLNaqPWuGZy7/ApfpJc9kINXwTJDtc+voPegiH1Oogn42A9LaYC6 CQd5NICHBFt2gr35Iej8weEakB70z4DQI1m2/gcqY8ysPtShVC+p+akTP8QOj8E= =9r1R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6 July 2015 at 14:55, Takashi Iwai wrote:

Well, speaking of kernel, the biggest problem to take SLE12 version is the lack of hardware support, particularly the graphics. If you have a laptop younger than two or three years old, you have little chance to make it running with 42 in native graphics. Similarly, most of new WiFi chips won't work with 42.

How hard would it be to backport fixes to resolve that? Surely SUSE need to also get SLED 12 working on hardware that new? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 06.07.2015 um 15:01 schrieb Richard Brown:

On 6 July 2015 at 14:55, Takashi Iwai wrote:

...

Well, speaking of kernel, the biggest problem to take SLE12 version is the lack of hardware support, particularly the graphics. If you have a laptop younger than two or three years old, you have little chance to make it running with 42 in native graphics. Similarly, most of new WiFi chips won't work with 42.

How hard would it be to backport fixes to resolve that? Surely SUSE need to also get SLED 12 working on hardware that new?

How many SLED subscriptions have been sold? Since probably nobody is really using it, no backports are needed. I would personally suggest to just always use Kernel:Stable for the openSUSE release. The current Kernel is supposed to be stable. And kernel hackers (not only SUSE's kernel hackers) will support us. After it is known that we (as openSUSE community) are not able to maintain our own kernel version (see the mess that 13.2 is), and we probably don't have the manpower to make the SLES12 kernel work well for our target audience, we should just use resort to using always the latest upstream version. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2015-07-07 11:54, Takashi Iwai wrote:

Even with this model, it remains as an open question whether we switch to yet another kernel some time later. And when and which version. IMO, it depends on the release schedule, and we can pick up the latest LTS kernel at that time.

Well, gregkh mentioned 4.1 will be LTS, so let's get it on already. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2015-07-07 12:41, Takashi Iwai wrote:

At Tue, 7 Jul 2015 12:13:20 +0200 (CEST), Jan Engelhardt wrote:

...

On Tuesday 2015-07-07 11:54, Takashi Iwai wrote:

...

Even with this model, it remains as an open question whether we switch to yet another kernel some time later. And when and which version. IMO, it depends on the release schedule, and we can pick up the latest LTS kernel at that time.

Well, gregkh mentioned 4.1 will be LTS, so let's get it on already.

I meant the status after that, say, in 2016 or 2017. Should we keep using 4.1.x?

Probably not, as (i) 4.1 LTS would then be about a third through the lifetime that I predict for it, and we need the LTS's remaining life for the remainder of Leap 42.1. (ii) a new LTS branch will likely have been started that would be more suitable for 42.2/42.3. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, July 6, 2015 14:55, Takashi Iwai wrote:

At Mon, 06 Jul 2015 08:11:53 -0400, Robert Schweikert wrote:

...

On 07/03/2015 05:50 AM, Mathias Homann wrote:

...

Hi,

I guess I didn't pay too much attention until now:

Well that is a bit of a problem at this point in the discussion.

...

Do I understand right that the next openSUSE enduser desktop release will be based on the latest SLES (which I'd understand to be SLES12)?

Does this mean that the next openSUSE enduser desktop release in some parts will use older components than the current openSUSE 13.2 (for example the kernel)?

Yes, not necessarily, and no.

If one just looks at the version number (kernel for example) then the answer is yes, for gcc the answer is no. However, if one cares about what is actually inside the package then the answer is not necessarily. As I pointed out in one e-mail the kernel carries some 5000+ patches. Many of those backport features from kernels with a version number that is greater than the version number of the kernel that is in openSUSE 13.2. Other parts of the kernel are older.

Well, speaking of kernel, the biggest problem to take SLE12 version is the lack of hardware support, particularly the graphics. If you have a laptop younger than two or three years old, you have little chance to make it running with 42 in native graphics. Similarly, most of new WiFi chips won't work with 42.

exactly my point... by the way, how is upgrading from 13.2 to Leap supposed to work? 13.2 is running a way newer kernel than what leap looks to be running... ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-07 13:22, Richard Brown wrote:

On 7 July 2015 at 13:13, Mathias Homann wrote:

...

exactly my point... by the way, how is upgrading from 13.2 to Leap supposed to work? 13.2 is running a way newer kernel than what leap looks to be running...

So far, in all my tests, zypper dup works surprisingly well ;)

If it aint broke....

What with the DVD? Boot the DVD, choose upgrade? AKA offline system upgrade? Or traditional upgrade, since ever? Upgrade from 13.1 (Evergreen) and 13.2 have both to be considered. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWbt5QACgkQja8UbcUWM1z8VgEAniY13L0QfLOId7AWRgZ54kgz t4dFi8hLruSTRJ8wenIA/2djfUz+d0znzT+oYvEQPFhtaJ6+8I6UMlUWw61IBGsB =1aqB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-07 13:40, Richard Brown wrote:

On Tue, 2015-07-07 at 13:27 +0200, Carlos E. R. wrote:

I've done them using DVD, offline upgrade and with zypper dup

Things I expected to break (like XFS complaining about the change in kernel version) did not happen, which is why I've been telling people that I think many of the concerns regarding the kernel version are not nearly as serious as they think.

Good :-)

...

Upgrade from 13.1 (Evergreen) and 13.2 have both to be considered.

Do you have a look at what we do in openQA for Tumbleweed?

Not recently, no.

For Leap 42.1 we will be doing at least the same before any release, so that will mean, _at the very least_

Offline Upgrade (From DVD) from 13.1 with gnome Offline Upgrade (From DVD) from 13.1 with kde Offline Upgrade (From DVD) from 13.2 zypper dup Upgrade from 13.1 with gnome zypper dup Upgrade from 13.1 with kde zypper dup Upgrade from 13.2

zypper dup across two releases is actually tested? This is totally new to me. The official documentation web page says that it is not supported at all, and that's what we have been saying people for years. Otherwise, I'm very glad that all those scenarios are tested.

We'll probably throw a few extra scenarios in that for the fun of it... 'upgrading from SLES 12' would be interesting to see ;)

Quite. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWb2c8ACgkQja8UbcUWM1yWwgD/VDJHFmM+glKhwIhDobb8XEaI zAfW3p8yxjruYNR+06QBAII6Ylat5WPnvLh3ARhPjYI0oZ8W6vJOkU+ES6byvmHf =fli9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03.07.2015 12:16, Guido Berhoerster wrote:

Why should package submission be optional, why not take everything that is in Factory and not yet in:42? It has always been the deal that by submitting a package to Factory one implicitly agrees to maitain it for supported releases as well. In the past releases also were maintained for

Because 42 is not Factory and sometimes it needs porting and testing.

longer, after that the Evergreen approach also worked well for 11.4. Why should that be any different now? Having both less drivers and less packages just makes it less and less attractive. If you want to spend time on bringing more of Factory to 42, you're invited to do so.

...

And remember 42 is maintained for longer, so if the software is already out of maintenance now, better don't submit it.

How's that any different from the situation we had with Evergreen? And sooner or later you'll run into the issue anyway that you can't update to the latest KDE, GNOME, Xfce because systemd, upower, GTK, Qt etc. are too old.

I know. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le vendredi 03 juillet 2015 à 12:16 +0200, Guido Berhoerster a écrit :

How's that any different from the situation we had with Evergreen? And sooner or later you'll run into the issue anyway that you can't update to the latest KDE, GNOME, Xfce because systemd, upower, GTK, Qt etc. are too old.

In general, it could be a problem. But the truth is, for desktop, it shouldn't be: - desktops only rely on logind, which has been fairly stable API wise: no new API has been added there for quite a while: there is no need for a new systemd - We were careful to ship with upower 0.99.1 on SLE12 (which is identical to 1.0, API wise), because we knew it would better to have the latest API available for SLE12 lifecycle. So, no issue there either. - GTK3 is "part" of GNOME and API/ABI backward compatible, so upgrading it (and glib2) won't be a problem. When I did some experiments 6 months ago to try to bring up GNOME 3.14 on top of SLE12, it didn't cause any issue. - Qt5 is probably in the same situation as GTK3: it is supposed to be API and ABI compatible (except for private API, which shouldn't be used anyway). -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

With the change in model I think that is a reasonable approach. As a maintainer I would complain if I automatically would get signed up to follow the Leap model. This is a situation where asking is definitely very important, IMHO. Well, you weren't asked if it's ok if the Evergreen team prolonged the

On 06.07.2015 14:27, Robert Schweikert wrote: maintenance time. So if more people feel we should scale up 42 to TW's dimension, we need a group of people: a) trying to mass build Factory packages against 42 and b) if they fail to build, do some %if magic and submit to devel project c) if they are fine, inform the maintainers about the Leap inclusion. I guess most would be fine with that. In case of a veto, we have to find alternatives - either living without the package or without the maintainer But as I mentioned before, we can't clone Factory as is. Hands up anyone? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Am 06.07.2015 um 15:20 schrieb Robert Schweikert:

On 07/06/2015 08:44 AM, Stephan Kulow wrote:

...

On 06.07.2015 14:27, Robert Schweikert wrote:

...

...

With the change in model I think that is a reasonable approach. As a maintainer I would complain if I automatically would get signed up to follow the Leap model. This is a situation where asking is definitely very important, IMHO. Well, you weren't asked if it's ok if the Evergreen team prolonged the maintenance time.

Correct, I also didn't commit to maintain my packages in Evergreen.

No, and I didn't care since I was set to maintain them myself if required (which was the default expectation). Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op 06-07-15 om 12:43 schreef Stephan Kulow:

Make sure calibre requires the Qt version it was compiled with, so the broken dependency can be detected

That's already the case. Thanks, Cor -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 06.07.2015 14:39, Robert Schweikert wrote:

On 07/03/2015 05:13 AM, Stephan Kulow wrote:

...

Hi,

...

I have a new topic ;)

...

As the bootstraping of openSUSE:42 is almost done (already looking forward to do the same from scratch with openSUSE:$NEWNAME) I wonder how we go from there.

Are we close enough to turn Leap on as a build target for Devel: project s?

I would think so. 42 has 2005 succeeded packages.

I think that would be a fair starting point for maintainers to see how their packages behave when built against Leap.

Yes, good idea.

...

I would like simple (to enforce) submission rules. So submission from openSUSE:Factory or SUSE:SLE-12:Update only (:Update overshadows SLE-12:GA, so it has all sle12 packages).

Hmm, that's fair enough for now. But moving forward we probably have to consider that this may be insufficient. While I hate to optimize for corner cases, or keep doors open for hypothetical reasons, this beast is so complex that we might consider creating one or more special Devel projects that can feed Leap. At least the "rules" should, IMHO not shut the door on this.

Sure, but we need extra reviews for this case then. That's the only addition IMO. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org