On Sat, Sep 02, 2023 at 10:49:51AM +0200, Richard Brown wrote:

On Sat, 2023-09-02 at 10:43 +0200, Michal Suchánek wrote:

...

Hello,

why do you think that Slowroll would require more packaging effort than Leap?

Just as Leap derives from SLE, Slowroll derives from Tumbleweed.

I could even argue that Slowroll would require less effort when all packages come from Tumbleweed while Leap is built on top of SLE and has a large number of packages of its own.

Because, unlike Leap where maintenance for SLE packages is effectively 'automatic' (ie. taken care as part of the daily business of SLE), and unlike Tumbleweed where it's also effectively 'automatic' ('just throw a new version at it), Slowroll will likely require old-fashioned maintenance (CVE bumps, backports, narrow-fixes) for packages in Slowroll but not-yet-ready to be copied from Tumbleweed

It depends on the criteria for 'ready' and the distance between Slowroll and Tumbleweed. If a new version of a library fixes a CVE and does not look problematic otherwise it can be just declared 'ready' - there is about as much risk of breakage from upgrading as there is from backporting a fix. Then there are times when it's more problematic - upgrading to a new KDE version to fix a CVE is somewhat dodgy. Thanks Michal

et al: Just responding over here, as someone who did take the survey . . . as always the questions steer the taker in certain predetermined directions . . . which then lead to conclusions. As an older GUI user of various linux distros I "like" Leap, for a "stable" release option in the openSUSE paradigm. I don't recall if there was a question on "keep Leap going as it is???" but I would have clicked that option . . . . I think the questions were, "If you came to a fork in the road, would you choose 'linarite' or would you choose 'slowroll'?" In that choice I said "slowroll" which would be more like Manjaro, where a small number of packages gets upgraded every few weeks . . . which would be closer to what Leap has been. I do "like" "fresh horsies" in my OSs . . . newer kernels seem to be faster handling . . . but, at times the "total and complete rebuild of every nook and cranny" of TW does require more processor time, and that is where Leap offers "systematic stability" that for many end users is a good choice for a daily driver. I think there are a fair number of openSUSE users who would opt for the stable release offering of Leap. And that follows the Debian model of providing, "unstable," "testing," and finally "stable" release offerings, to provide different user needs with something close to their style.

On Sat, 2 Sep 2023 10:20:46 -0500 Larry Len Rainey wrote:

I think the easy way to "slow roll" would be like this.

Tumbleweed - would stay the same.

Leap would be "last weeks stable Tumbleweed" except for kernel CVE's they would go out ASAP. Any Bugzilla confirms would go into a grep -v list to be done in to prevent them from updating.

My thoughts with the given choices of "slow roll" and the rest was just to use tumbleweed-cli and to use "known good" snapshots. The "known good" is the tricky part. Maybe something like - solves bugs and security issues (from the snapshot announcement, problematic for this is that the announcement only contains the packages from the DVD), - does not introduce serious new issues. For this it would be helpful to know the number of downloads of a snapshot and the bugs opened for the snapshot. And the openQA results of course. Kind regards, Dieter

On 2023-09-02 12:22, Matěj Cepl wrote:

On Sat Sep 2, 2023 at 10:19 AM CEST, Richard Brown wrote:

...

I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros.

Wouldn’t no-support-free-as-in-beer-ALP (whether such thing will exist is another question) be effectivelly Slowroll maintained without the community effort?

I don’t think so The lifecycle of various ALP products has not yet been locked down, but there’s some assumptions we can consider as highly likely - different ALP products will have different lifecycles (eg like we already see with SLE Micro moving faster than SLE) - some ALP products may move in a rolling fashion, some may not - even the fastest most rolling ALP products are likely to be slower than where I expect Slowroll to end up If we do Slowroll I think the benefit to the community will be the ability to set a pace that suits the community and only the community. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

And yes, the idea of micro-host-system with flatpaks is a good one. Just make that host system slower to update (flatpaks are already too fast). Something like openSUSE/SLE Micro-based Leap?

Leap Micro 5 is the name, to avoid confusion

On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <[robin.listas@gmx.es](mailto:On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <<a href=)> wrote:

On 2023-09-02 04:19, Richard Brown wrote:

...

The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.

Speaking for myself, it is not "will", but being unable to.

You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.

(I find OBS terribly obscure and difficult)

-- Cheers / Saludos,

Carlos E. R.

(from openSUSE 15.5 (Laicolasse))

Hi - Have you tried this link? https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory

On Sat 02 Sep 2023 12:12:24 PM CDT, Carlos E. R. wrote:

On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:

...

On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:

...

On 2023-09-02 04:19, Richard Brown wrote:

...

The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.

Speaking for myself, it is not "will", but being unable to.

You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.

(I find OBS terribly obscure and difficult)

...

Hi - Have you tried this link?

https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory

That's a far cry from "OBS for dummies" training sessions :-)

And I would not contribute to Factory, that's way too fast.

Hi Carlos Factory can be as fast or slow as you, the maintainer want it to be ;) Anyway, do you use Slack? Or IRC #opensuse-packaging? You can always ask questions at the above.... happy to help if I can. -- Cheers Malcolm °¿° (Linux Counter #276890) Tumbleweed 20230828 | GNOME Shell 44.3 | 6.4.11-1-default HP Z440 | Xeon E5-2695 V4 X36 @ 2.10GHz | Quadro T400/Tesla P4 up 3 days 15:59, 3 users, load average: 0.16, 0.15, 0.10

------- Original Message ------- On Saturday, September 2nd, 2023 at 12:59 PM, Chuck Payne wrote:

On Sat, Sep 2, 2023 at 12:12 PM Carlos E. R. wrote:

...

On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:

...

On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:

...

On 2023-09-02 04:19, Richard Brown wrote:

...

The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.

Speaking for myself, it is not "will", but being unable to.

You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.

(I find OBS terribly obscure and difficult)

...

Hi - Have you tried this link?

https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory

That's a far cry from "OBS for dummies" training sessions :-)

And I would not contribute to Factory, that's way too fast.

-- Cheers / Saludos,

Carlos E. R.

(from openSUSE 15.5 (Laicolasse))

--

Terror PUP a.k.a Chuck "PUP" Payne ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Register Linux Userid: 155363

So, I know my opinion won't matter, but this why I been wondering moving away from Leap to ALP, It didn't make sense.

Leap is great, now with Red Hat cut offline access, there needs to be an Enterprise version of Linux. Ubuntu will never be that, openSUSE Leap is it, now is the time for us to move back in. I can see why many move to Ubuntu, openSUSE packages have growning less. Why did I move from Red Hat in the late 90's to SuSE, PACKAGES!!! No offence, have you play with RHEL 9.0, they have less that us. It's like IBM wants to kill RH. So, more packages would be a plus. Stable to keep the enterprise level would be great.

Sorry to rag on ALP, no ever explained it well, and still like another version of MicroOS, and when you try to ask they got very defensive. So I stopped acting.

Tumbleweed is great for those that want to help test and make sure the next very of LEAP is going to be great.

So keep just

Leap Tumbleweed MicroOS

So try to create things people don't want. Focus on add thing to what we have to make them great again.

openSUSE Community Member since 2008.

Just to clarify, you mention that there needs to be an Enterprise version of Linux. That is SUSE's job, is it not? Their current product is SLE and the umpteen variations they produce, their future product is <things based off of> ALP. openSUSE's "job" is to be a community-built, community-used Linux distro, right? (I don't see much of an overlap between anywhere RHEL would be used and anywhere openSUSE products would be used?) So it's whatever the community wants it to be, ideally using the unique strengths that the openSUSE project possesses. As I see it, those unique strengths are 1) the Tumbleweed production model, including openQA and 2) access to the exact 1:1 enterprise product from SUSE, so a product can be put together for similar-to-enterprise use cases. It would seem - to me intuitively, and based on the survey results to at least a plurality of others - that the most common "community" need would be for up-to-date software in a coherent package, plain and simple. That's Tumbleweed. If you want "a distro similar to what SUSE produces for enterprise", that will still be around, although likely with less desktop/end-user-oriented software available than what was in SLE/Leap since enterprises presumably don't actually want to pay that much for such software to exist on Linux desktops. If you want a point release model, end-user-oriented, non-enterprise distro that is still based on the SUSE enterprise code base...it seems like the option would be to rally together a group of folks to produce and maintain that - knowing that it will include not just initial production, but the years upon years of work required to monitor thousands of upstream packages and pick, choose and implement downstream patches to keep the whole distribution at some level of security/operability. Sorry if this is irrelevant / inaccurate / unhelpful, but from a relative outsider's perspective it seems like there is still some confusion that could be cleared up?

On 9/3/23 15:54, Richard Brown wrote:

On 2023-09-03 02:45, Simon Lees wrote:

...

So I've seen enough from the granite discussions along with enough user and developer interest (which didn't have to be much) to want to work on / build a Granite++ I.E. Rather then just doing a 1:1 rebuild, having an additional repo similar to openSUSE_Backports for Leap and allowing contributors to submit whichever packages they feel they'd like on top.

I think that this will be a sustainable approach in that Granite gives us a good base OS and we will only be adding on top of it the stuff that people care enough about to contribute and to the people who do contribute it will be more useful then plane granite plus keeping a bunch of there own packages in there home repo's. At some point I should probably also talk to the package hub team, because if they are interested in a package hub concept for ALP its likely we could also share some effort.

Will it be functionally comparable with Leap, probably not will it be comparable enough to be marketed as a Leap replacement at this stage who knows. Will it be a useful standalone distro that's worth doing in my opinion yes. If it reaches the contributor and user level of something like MicroOS then i'd be willing to call it a working success.

To answer your final two questions, I still plan to go ahead with these efforts once the ALP repo's are successfully synced back into OBS at least to the point of starting to get some of the packages I care about working. As for a timeframe personally i'm not planning on doing too much until Granite is a little more fleshed out and more of the package set starts being added to ALP. Otherwise it will probably lead to a bunch of duplicated effort.

Finally I think slowroll is a fun concept and I look forward to seeing the results if people keep playing with the idea.

Thanks for sharing your plans Simon

But like you seem to accept, they may not exactly equate to a viable Leap replacement

With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released

Well from my maths a 15.6 mid 2024 + 18 months of support lands us at the end of 2025 and while now is probably too early to work on something I'd hope that we'd be able to work on something in parallel with granite development through 2025 so that we have something viable by the end of 2025, As long as all the key components of Granite are in place I also wouldn't rule out trying to release something a little before the granite release maybe within the Beta period if it helps with time frames. This might not meet every need of every existing Leap user but it would certainly be my goal to meet the needs of as many as we reasonably can so there is atleast some choice for people who don't wish to move to full tumbleweed. Of course from these numbers we might not get the general 6 months we have for migration between current point releases but unless Granite releases in December of 2025 hopefully we can get more then a month. If toward the end of 2025 we look like we have a viable replacement but might ideally need a little more time for migration then i'd certainly consider getting the board to approach SUSE about maybe the possibility of moving from 18 months of support to maybe 21 for 15.6. But either way at this stage i'm certainly not seeing a period where there'd be a year or two of completely unsupported systems. Given how similar the planned approach is to Leap and the fact we were able to put together a prototype in a week based off just the Marble codebase the design is mostly there and really all we are waiting for is some up to date ALP sources to hit OBS it doesn't really need to be all of Granite either if we just start working with a smaller subset of packages until the core of ALP starts to land and we build more on top of it. -- 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 9/4/23 15:36, Richard Brown wrote:

On 2023-09-04 04:09, Simon Lees wrote:

...

On 9/3/23 15:54, Richard Brown wrote:

...

On 2023-09-03 02:45, Simon Lees wrote: With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released

Well from my maths a 15.6 mid 2024 + 18 months of support lands us at the end of 2025 and while now is probably too early to work on something I'd hope that we'd be able to work on something in parallel with granite development through 2025 so that we have something viable by the end of 2025, As long as all the key components of Granite are in place I also wouldn't rule out trying to release something a little before the granite release maybe within the Beta period if it helps with time frames. This might not meet every need of every existing Leap user but it would certainly be my goal to meet the needs of as many as we reasonably can so there is atleast some choice for people who don't wish to move to full tumbleweed.

Of course from these numbers we might not get the general 6 months we have for migration between current point releases but unless Granite releases in December of 2025 hopefully we can get more then a month. If toward the end of 2025 we look like we have a viable replacement but might ideally need a little more time for migration then i'd certainly consider getting the board to approach SUSE about maybe the possibility of moving from 18 months of support to maybe 21 for 15.6. But either way at this stage i'm certainly not seeing a period where there'd be a year or two of completely unsupported systems.

Given how similar the planned approach is to Leap and the fact we were able to put together a prototype in a week based off just the Marble codebase the design is mostly there and really all we are waiting for is some up to date ALP sources to hit OBS it doesn't really need to be all of Granite either if we just start working with a smaller subset of packages until the core of ALP starts to land and we build more on top of it.

There are teams (including one with your dayjobs Teamlead) looking at topics for Granite like:

- reducing the packages delivered in Granite to make it more sustainably supportable - “compartmentalising” software stacks so SUSE may use different versions of stuff from the users, enabling different lifecycles either for SUSE or the users over the lifespan of Granite

Of this i'm well aware given that I have also been involved in both workgroups (although not always in the meetings due to timezones).

Neither of the above will apply to Marble.

On the contrary compared to what I was expecting when I did my prototype and basing of marble, every discussion around package selection was working around a significantly smaller and harder package set to deal with then what's being discussed for Granite currently. Yes how we work with compartmentalization long term is a challenge that still needs to be addressed, however I highly suspect for atleast the initial release of Granite there will probably only be one of most stacks. But yes how we tell a project which packages to ignore is something to solve in the next 18 months. Ideally we will be able to start pulling openSUSE packages from Tumbleweed at the same time or a similar time as they are so the "Factory First" if Factory works so does everything else still applies. But there maybe some things that need addressing yes.

If either of these efforts has any impact on the Granite codebase then I expect your proposed timeline above to be utterly infeasible.

I expect both efforts to have a dramatic impact on the internals of Granite even if the end goal is that users won’t see much of a difference compared to a SLES major release.

I really do not share your optimism at all that the openSUSE Project will have the time, resources or capability to design, build, and make a reliable new distro based on Granite before the end of life of Leap 15.6

Well i'm the sort of person that will take the goal of having a distro based on Granite before the end of 15.6 and push my hardest to resolve the issues to get there and if come September / October 2025 that is looking unlikely i'd start to look at temporary work arounds to bridge the gap. This could include asking SUSE nicely if they'd consider a one off extension to 15.6 support to help "Bridge the Gap", or maybe it could involve a "temporary rolling setup" based on the current state of where we get to that people may chose to use until we get to the point of being able to coin a stable release. Yes these options are less then ideal and the first might not even be possible but personally for my own needs i'd happily take less then ideal over nothing.

If I thought that was a viable option I absolutely wouldn’t be doing what I have been trying to bring folk together to build a Leap replacement.

And I'm aiming to bring people together to work on proving that it is a viable option. Or atleast enough of a viable option to meet the needs of those willing to contribute. The History of Leap shows that even if we can achieve that standard for a small number of contributors we can come up with something that is quite useful for users. -- 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 2023-09-04 08:34, Michal Suchánek wrote:

...

With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released

And why is there no plan for LEap 15.7?

Because of several reasons - the general agreement of Leaps use of SLE sources was with the condition that openSUSE would always transition to the next Enterprise codebase when it exists. Now ALP is here, it exists. The fact that it exists in a different scope than previous Enterprise codebases is a fact that openSUSE needs to rise to address - this is proving hard already - making a 15.7 will just make that harder. - the folk that SUSE contributes to make Leap are also the same folk you’ll need to make and support a 15.7. We could really use their help to build a Leap replacement. So if I were to push for a 15.7, that would mean we’d have to find even more new folk to lead, release manage, build and maintain a Leap replacement. I’d rather see the Leap pros working on a platform that has a future in the Project rather than losing them for a year or two maintaining a platform with no future. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

On 2023-09-04 10:04, Michal Suchánek wrote:

On Mon, Sep 04, 2023 at 08:47:19AM +0200, Richard Brown wrote:

...

On 2023-09-04 08:34, Michal Suchánek wrote:

...

...

With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released

And why is there no plan for LEap 15.7?

Because of several reasons

- the general agreement of Leaps use of SLE sources was with the condition that openSUSE would always transition to the next Enterprise codebase when it exists. Now ALP is here, it exists. The fact that it exists in a different scope than previous Enterprise codebases is a fact that openSUSE needs to rise to address - this is proving hard already - making a 15.7 will just make that harder.

- the folk that SUSE contributes to make Leap are also the same folk you’ll need to make and support a 15.7. We could really use their help to build a Leap replacement. So if I were to push for a 15.7, that would mean we’d have to find even more new folk to lead, release manage, build and maintain a Leap replacement. I’d rather see the Leap pros working on a platform that has a future in the Project rather than losing them for a year or two maintaining a platform with no future.

Not really. Moving from Leap 15.6 to ALP means moving to ALP when it does not exist yet. There is a prototype but not a finished thing.

Moving from Leap 15.7 to ALP means that the new codebase to move to is available to move to.

I thought I said this clearly enough, but I'll say it very bluntly If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7 We don't have any extra hands from SUSE to work on this - for example, some people have suggested I'll be building the Leap replacement. I won't, my involvement here is purely as an Architect, trying to help design whatever next. Given the poll clearly shows that we're doing this with, at best, luke-warm interest from the community to contribute, we absolutely need as much SUSE-sponsored help as we can get It's my very strong opinion, based on the enthusiasm shown so far for a Leap replacement, that if I were to persuade SUSE to sponsor the work for a 15.7, that 15.7 will not just be the last Leap release, but we'll almost certainly have no replacement going forward. Maybe thats a good way forward, maybe that's where we'll end up, but I was approaching this problem with a view to having a solution that will last beyond 2026, so I don't favour this option. Regards, -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

On 2023-09-04 10:37, Michal Suchánek wrote:

On Mon, Sep 04, 2023 at 10:13:43AM +0200, Richard Brown wrote:

...

On 2023-09-04 10:04, Michal Suchánek wrote:

...

I thought I said this clearly enough, but I'll say it very bluntly

If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7

And how does that change between 15.6 and 15.7?

Won't people be busy with 15.6 at 15.6 time as much as they would be busy with 15.7 at 15.7 time?

The difference is only on the ALP side - at 15.7 time it will be much more mature base to build on.

Leap 15.6 is being bootstrapped right now (https://build.opensuse.org/project/show/openSUSE:Leap:15.6) It will be completed and off the desk of the majority of the SUSE-paid Leap folk in time for them to get something like Slowroll in place and well established by the end of Leap 15.6's end of life If we do a 15.7, they'll be spending their time on that instead. Meanwhile ALP will not magically become a 'more mature base to build on' openSUSE Leap is a very Desktop-centric distribution. None of SUSE's planned ALP products have any intention of being a Desktop-centric offering. If openSUSE doesn't start the work now, then ALP will never be ready for the Desktop use cases we currently enjoy with Leap. (the Server use cases should be well served by the 1:1 copies of SUSE's ALP products we'll be doing) If we choose to kick the can down the road, all we end up with is the same mountain to climb and more tired legs for spending another year building Leap. If that is our collective desire, I think that would be an utter waste of our time so you can expect me to step back and leave that challenge to someone else to make sense out of. There's plenty more interesting things for me to work on. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblic

On 9/4/23 19:04, Richard Brown wrote:

On 2023-09-04 10:37, Michal Suchánek wrote:

...

On Mon, Sep 04, 2023 at 10:13:43AM +0200, Richard Brown wrote:

...

On 2023-09-04 10:04, Michal Suchánek wrote:

...

...

I thought I said this clearly enough, but I'll say it very bluntly

If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7

And how does that change between 15.6 and 15.7?

Won't people be busy with 15.6 at 15.6 time as much as they would be busy with 15.7 at 15.7 time?

The difference is only on the ALP side - at 15.7 time it will be much more mature base to build on.

Leap 15.6 is being bootstrapped right now (https://build.opensuse.org/project/show/openSUSE:Leap:15.6)

It will be completed and off the desk of the majority of the SUSE-paid Leap folk in time for them to get something like Slowroll in place and well established by the end of Leap 15.6's end of life

If we do a 15.7, they'll be spending their time on that instead.

Meanwhile ALP will not magically become a 'more mature base to build on'

openSUSE Leap is a very Desktop-centric distribution.

None of SUSE's planned ALP products have any intention of being a Desktop-centric offering.

If openSUSE doesn't start the work now, then ALP will never be ready for the Desktop use cases we currently enjoy with Leap. (the Server use cases should be well served by the 1:1 copies of SUSE's ALP products we'll be doing)

I actually aimed to start on this a good few weeks back, but at the time SUSE's ALP packages weren't being synced to the public build service, has there been any change there? because really that's all i'm waiting on to start spending some time here. -- 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

Bernhard M. Wiedemann composed on 2023-09-04 09:55 (UTC+0200):

https://en.opensuse.org/openSUSE:Slowroll

PoC is up for testing.

Current base snapshot is TW-20230822

My first choice for a switch turned out to be 20230823, so instead I chose a UEFI 15.5 to dup from. It includes Plasma, IceWM and instead of SDDM, KDM3. Libdvdcss: Use TW, or latest Leap? openh264: same? For the time being, no need for Packman here, but eventually, and others, ..... Whatever mirror CDN is providing for FL, USA is distinctly unimpressive. Unfortunately I forgot to time the -d step. Actual installation time for 1148 packages, including several selection stops for fonts I don't allow to waste resources: ... Executing %posttrans scripts ..........................................................................................................................................................[done] warning: Found NDB Packages.db database while attempting bdb backend: using ndb backend. CommitResult (total 1148, done 1148, error 0, skipped 0, updateMessages 0) Checking for running processes using deleted libraries... warning: Found NDB Packages.db database while attempting bdb backend: using ndb backend. There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs. real 2m33.846s user 0m48.026s sys 0m20.259s # zypper -v dup Verbosity: 2 Initializing Target Checking whether to refresh metadata for Non-OSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update ... Computing upgrade... Problem: the installed libldap-2_4-2-2.4.46-150200.14.17.1.x86_64 requires 'libldap-data = 2.4.46-150200.14.17.1', but this requirement cannot be provided deleted providers: libldap-data-2.4.46-150200.14.17.1.noarch Solution 1: Following actions will be done: deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64 Solution 2: keep obsolete libldap-data-2.4.46-150200.14.17.1.noarch Solution 3: break libldap-2_4-2-2.4.46-150200.14.17.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 2 ... # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | grep -Ev '32bit|debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort # zypse libldap i | libldap-2_4-2 | package | 2.4.46-150200.14.17.1 | x86_64 | (System Packages) i | libldap2 | package | 2.6.4-2.3 | x86_64 | OSS i | libldapcpp0 | package | 2.6.4-2.2 | x86_64 | OSS i+ | libldap-data | package | 2.4.46-150200.14.17.1 | noarch | (System Packages) v | libldap-data | package | 2.6.4-2.3 | noarch | OSS # Is there expected to be a KDE3 repo for Slowroll? Should I use TW's for the time being? Just keep old libldap* as long as allowed? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On 06/09/2023 05.20, Felix Miata wrote:

Solution 1: Following actions will be done: > deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64

That seems to be the sane way out there. I don't think we want to keep supporting KDE3 when 13.2 was the last release to ship it. EOL 6y ago. Slowroll is just meant to be a variant of TW/Factory that moves slower to hopefully cause less bugs along the way, but it won't magically support things that TW doesn't. Ciao Bernhard M.

On 9/7/23 17:36, Felix Miata wrote:

Bernhard M. Wiedemann composed on 2023-09-07 08:26 (UTC+0200):

...

Felix Miata wrote:

...

...

Solution 1: Following actions will be done: deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64

...

That seems to be the sane way out there. I don't think we want to keep supporting KDE3 when 13.2 was the last release to ship it. EOL 6y ago.

...

Slowroll is just meant to be a variant of TW/Factory that moves slower to hopefully cause less bugs along the way, but it won't magically support things that TW doesn't.

Somebody is providing KDE3 for Leap and TW in oSBS[*]. :-D My current primary is 15.5, running KDE3 ever since I started using SUSE with 8.0. I have 12 64bit KDE3 installations on TW, a smaller bunch on 32bit, and 6 TW/Plasma installations using KDM3 instead of that SDDM crippler that I suffer on 2 TW/Plasmas. As was with Leap Alpha/Beta, I'll have close to half my two-dozen+ 15.6s with KDE3 by the time of 15.6 GM. These are all on hardware multiboot, no VMs except for running DOS SVGA text mode on OS/2.

They'd also need to build that repo against slowroll, anything else is likely to have issues.

[*] http://download.opensuse.org/repositories/KDE:/KDE3/15.4/ http://download.opensuse.org/repositories/KDE:/KDE3/15.5/ http://download.opensuse.org/repositories/KDE:/KDE3/15.6/ http://download.opensuse.org/repositories/KDE:/KDE3/16.0/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.1/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.2_ARM/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ (I'm wondering if 16.0 might be intended for Slowroll, locally nicked sslo.)

Nope it was for an ALP based prototype -- 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

Bernhard M. Wiedemann composed on 2023-09-04 09:55 (UTC+0200):

https://en.opensuse.org/openSUSE:Slowroll

PoC is up for testing.

Current base snapshot is TW-20230822 with the next bump expected end of September

On the ToDo list: - proper repo setup (e.g. in openSUSE:Slowroll) - staging + openQA setup - own install / VM / container images - script a consideration for package dependencies - find a solution for missing unpublished -bootstrap packages [1]

If you want to help, feel free to email me.

Just finished a successful and uneventful 1200 transaction zypper dup from tw20230708 with the following: # zypper lr | grep Yes 1 | FCLunst | Yes | ( p) Yes | http://silk.apana.org.au/rpm-unstable-dev 2 | KDE3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ 3 | Non-OSS | Yes | (r ) Yes | http://cdn.opensuse.org/repositories/openSUSE:/ALP:/Experimental:/Slowroll/b... 4 | OSS | Yes | (r ) Yes | http://cdn.opensuse.org/repositories/openSUSE:/ALP:/Experimental:/Slowroll/b... 5 | Update | Yes | (r ) Yes | http://cdn.opensuse.org/repositories/openSUSE:/ALP:/Experimental:/Slowroll/s... 6 | openh264 | Yes | (r ) Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/ # rpm -qa | grep -E 'lasm|kdm|ddm|tdm|xdm' | grep -v randi | sort kdebase3-kdm-3.5.10.1-379.1.x86_64 libKF5Plasma5-5.109.0-1.1.x86_64 plasma-framework-5.109.0-1.1.x86_64 plasma-framework-components-5.109.0-1.1.x86_64 plasma5-desktop-5.27.7.1-1.2.x86_64 plasma5-integration-plugin-5.27.7-1.1.x86_64 plasma5-session-5.27.7-3.1.noarch plasma5-workspace-5.27.7-3.1.x86_64 plasma5-workspace-libs-5.27.7-3.1.x86_64 xdm-1.1.14-4.3.x86_64 # inxi -Saz --vs --zl --hostname inxi 3.3.29-00 (2023-08-15) System: Host: gb970 Kernel: 6.4.12-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1 clocksource: tsc available: hpet,acpi_pm parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 noresume consoleblank=0 preempt=full mitigations=off Desktop: KDE Plasma v: 5.27.7 tk: Qt v: 5.15.10 wm: kwin_x11 dm: 1: KDM 2: XDM Distro: openSUSE Tumbleweed 20230822 # inxi -CGnz CPU: Info: quad core model: AMD Phenom II X4 965 bits: 64 type: MCP cache: L2: 2 MiB Speed (MHz): avg: 3423 min/max: N/A cores: 1: 3423 2: 3423 3: 3423 4: 3423 Graphics: Device-1: NVIDIA GF108 [GeForce GT 630] driver: nouveau v: kernel Display: x11 server: X.Org v: 21.1.8 driver: X: loaded: modesetting dri: nouveau gpu: nouveau resolution: 1: 1680x1050~60Hz 2: 1920x1200~60Hz API: OpenGL v: 4.3 Mesa 23.1.5 renderer: NVC1 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> # :) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Hello, On Mon, Sep 11, 2023 at 09:40:10AM -0400, Joe Salmeri wrote:

On 9/11/23 05:26, Gus Fos wrote:

...

An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.

It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out.

technically there is nothing preventing shipping a LTS kernel as part of Tumbleweed. However, to do so somebody needs to maintian the kernel-lts package. Also the kernel-lts package needs to go through QA increasing the workload on the QA side. Thanks Michal

On Tue, Sep 12, 2023 at 11:27:48AM -0400, Joe Salmeri wrote:

On 9/11/23 09:47, Michal Suchánek wrote:

...

Hello,

On Mon, Sep 11, 2023 at 09:40:10AM -0400, Joe Salmeri wrote:

...

On 9/11/23 05:26, Gus Fos wrote:

...

An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage. It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out. technically there is nothing preventing shipping a LTS kernel as part of Tumbleweed.

However, to do so somebody needs to maintian the kernel-lts package. Also the kernel-lts package needs to go through QA increasing the workload on the QA side.

Thanks

Michal

I think that would be a good idea and useful to have.

/etc/zypp/zypp.conf support multi kernel versions

multiversion.kernels = latest,latest-1,latest-2,running

However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.

Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.

I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.

This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.

There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them. Thanks Michal

On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote:

On 9/12/23 11:34, Michal Suchánek wrote:

...

There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.

Thanks

Michal

Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed.

The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the previous one.

None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version.

It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available.

There is the Tumbleweed archive with historical kernels which you can install to test if the problem is caused by the kernel long after it has been removed from Tumbleweed if you really need to.

Compiling and managing myself is something that I'd rather not have to do.

Also so far the people maintaining the Tumbleweed kernel figured that maintaining an additional kernel is something they would rather not do, and favor fixing bugs in the one kernel Tumbleweed has. As said, if somebody wants to maintain a LTS kernel they can. Nobody has stepped up to do it, though. Thanks Michal

On Tue, Sep 12, 2023 at 12:31:35PM -0400, Joe Salmeri wrote:

On 9/12/23 12:17, Michal Suchánek wrote:

...

...

On 9/12/23 11:34, Michal Suchánek wrote:

...

There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.

Thanks

Michal Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the

On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote: previous one.

Right but that does not address the issue where all the installed kernel versions are from the same X.Y version, which is why I will occasionally add a specific kernel to zypp.conf to make sure that it is kept.

It does address the problem of keeping the previous version, whether it's the same X.Y version or not does not matter. When you find a problem you can go to the earlier version with which the problem was not observed.

...

...

None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version.

It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available. There is the Tumbleweed archive with historical kernels which you can install to test if the problem is caused by the kernel long after it has been removed from Tumbleweed if you really need to.

Are you talking about the historical builds that are used by tumbleweed-cli located here

https://download.opensuse.org/history/

Which have 6.4 kernels while Tumbleweed has 6.5 Also see https://download.opensuse.org/repositories/home:/tiwai:/kernel:/ Thanks Michal

On Tue, Sep 12, 2023 at 12:54:52PM -0400, Joe Salmeri wrote:

On 9/12/23 12:41, Michal Suchánek wrote:

...

...

On 9/12/23 12:17, Michal Suchánek wrote:

...

...

On 9/12/23 11:34, Michal Suchánek wrote:

...

There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.

Thanks

Michal Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the

On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote: previous one. Right but that does not address the issue where all the installed kernel versions are from the same X.Y version, which is why I will occasionally add a specific kernel to zypp.conf to make sure that it is kept. It does address the problem of keeping the previous version, whether it's the same X.Y version or not does not matter. When you find a

On Tue, Sep 12, 2023 at 12:31:35PM -0400, Joe Salmeri wrote: problem you can go to the earlier version with which the problem was not observed.

It DOES matter if it is the same X.Y version because if one does frequent TW updates they could easily end up with all the kernel versions they have installed being the same X.Y version which has the problem.

The version number is overrated - sometimes a problem is introduced by major version update, sometimes by stable release, sometimes by configuration change. If you missed the problem for long enough that the good kernel is gone with multiversion it's unlikely to be so critical that you would not be able to look for the older versions online. There is no guarantee that a kernel with different X.Y version would not have the problem - it depends very much on the specifics. Thanks Michal

Joe Salmeri composed on 2023-09-12 11:45 (UTC-0400):

Michal Suchánek wrote:

...

There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.

Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea.

Why? # zypper ll | grep kern 25 | kernel-az* | package | (any) | 26 | kernel-de* | package | (any) | 27 | kernel-kv* | package | (any) | 28 | kernel-pree* | package | (any) | 29 | kernel-rt* | package | (any) | 30 | kernel-sy* | package | (any) | # All my Leap installations have the above. My TWs only lock kernel-de*. This general practice is well over a decade old. I decide when is the right time another kernel is appropriate to install. That doesn't happen unless I expect a soon reboot.

I also would not want to add more manual effort to cleanup older kernels that are no longer needed.

Trivial, and only occasional, unless disk space is too precious. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On 9/13/23 15:55, Neal Gompa wrote:

On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri wrote:

...

I think that would be a good idea and useful to have.

/etc/zypp/zypp.conf support multi kernel versions

multiversion.kernels = latest,latest-1,latest-2,running

However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.

Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.

I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.

This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.

There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.

This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.

Not sure what you mean.   I have multiple kernels installed including the last LTS version that was in TW. drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug  2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default Regards, Joe

On 9/13/23 16:15, Neal Gompa wrote:

On Wed, Sep 13, 2023 at 4:09 PM Joe Salmeri wrote:

...

On 9/13/23 15:55, Neal Gompa wrote:

On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri wrote:

I think that would be a good idea and useful to have.

/etc/zypp/zypp.conf support multi kernel versions

multiversion.kernels = latest,latest-1,latest-2,running

However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.

Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.

I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.

This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.

There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.

This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.

Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW.

drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default

But you don't have 6.4.12-1.1 or 6.4.12-1.2. The build counter is chopped off and finagled to make it look like it's not there.

Especially when compiler upgrades and such occur (which are represented by increasing the build counter), this can be annoying.

More likely it is because I don't update to ever new build that is published and therefore when I do update it is already to a newer x.y.z version. Regards, Joe

On Wed, Sep 13, 2023 at 04:15:01PM -0400, Neal Gompa wrote:

On Wed, Sep 13, 2023 at 4:09 PM Joe Salmeri wrote:

...

On 9/13/23 15:55, Neal Gompa wrote:

On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri wrote:

I think that would be a good idea and useful to have.

/etc/zypp/zypp.conf support multi kernel versions

multiversion.kernels = latest,latest-1,latest-2,running

However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.

Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.

I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.

This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.

There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.

This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.

Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW.

drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default

But you don't have 6.4.12-1.1 or 6.4.12-1.2. The build counter is chopped off and finagled to make it look like it's not there.

Especially when compiler upgrades and such occur (which are represented by increasing the build counter), this can be annoying.

Besides compiler upgrades the OBS may decide to do spurious rebuild for no apparent reason, or the build may fail because the worker goes down, and is retriggered. And then we have multiple packages like kernel-source and kernel-default that need to match, and that is the reason for chopping off the build counter. That's not ideal for Factory that does get major compiler upgrades. Still spurious rebuilds are considered more of a problem than major compiler upgrades so far. Thanks Michal

On Monday 2023-09-11 11:26, Gus Fos wrote:

Personally, I would rather see Tumbleweed turn into Slowroll

That is not going to change anything really. The package maintainer decides when to make an update, and to what version. E.g. cdecl gets updated every milestone, but vulkan-loader is only updated every ~10 milestones. The determination can and does happen independently of the target [Tumbleweed/Slowroll/Leap].

if I need to wait a month or two for a new software feature to land in distro, I gladly take that tradeoff if it gives me better stability.

Delaying the availability to people only means people see the bugs (which exist in any case) belatedly: Given 60000 TW users and a .01% daily chance to hit some bug, within ~12 days, the chance for a bug report to come about has passed 50%. (says some web calculator - anyone with powers in statitics should cross-check). If you take away 80% of TW users by moving them to Slowroll (full 30d delivery delay implied), time to 50% existence chance is ~36 days I think. That new vs. stable trade isn't performed at 1:1, nor linearly, and there is something to be said about diminishing returns.

On Wed, 2023-09-13 at 11:03 +0200, Jiri Slaby wrote:

On 11. 09. 23, 11:26, Gus Fos wrote:

...

Personally, I would rather see Tumbleweed turn into Slowroll

I would not.

I also would not. I am academically interested in Slowroll and am curious as to whether the approach brings any practical benefits at all. I am open to the possibility that it might, but I also suspect that it will not. The best maintained code is always going to be the one that's best maintained, most recently maintained, most actively maintained, and that's always going to be Tumbleweed.

...

which should have been completely skipped in my opinion.

If we skipped 6.4, you would see the issues in 6.5. What sense does it make?

Exactly, problems will always occur, software development is never perfect. But Tumbleweed is continually the platform with the shortest time window between issues found and issues fixed. That makes it the best-working platform we have most of the time, and when it isn't any disruption is for a minimal time easily coasted by rollbacks. Slowroll may be less scary than Tumbleweed but I think it's inevitable that it will have issues just like any distribution, and those issues will be harder to fix and hang around for longer because of its slower- by-design model.

...

An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.

Everyone is open to maintain the kernel and fix the bugs ;).

-- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

On 13. 09. 23, 21:34, Joe Salmeri wrote:

On 9/13/23 05:03, Jiri Slaby wrote:

...

On 11. 09. 23, 11:26, Gus Fos wrote:

...

Personally, I would rather see Tumbleweed turn into Slowroll

I would not.

...

Lately there have been a lot of issues in Tumbleweed and especially related to the known issues with kernel 6.4,

What known issues?

...

which should have been completely skipped in my opinion.

If we skipped 6.4, you would see the issues in 6.5. What sense does it make?

Hi Jiri,

Just an FYI, that VMWare is broken with the 6.5 kernel as the modules will no longer compile.

Hi, please talk to VMWare. Before every release, they have enough weeks to fix their modules. If they are unable to do so, you still can use something which keeps up and is opensource (like qemu). thanks, -- js suse labs