Development start of Leap 16.0
Hello everyone! (Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/) I'd like to announce the start of development and the public availability of what we currently refer to as Leap 16.0 pre-Alpha. Since this is a pre-Alpha version, significant changes may occur, and the final product may look very different in the Alpha, Beta, Release Candidate, or General Availability stages. The installer will *currently* offer you Base, GNOME, and KDE. Users can get our new Agama install images from https://get.opensuse.org/leap/16.0. The installer will *currently* offer you Base, GNOME, and KDE installation. Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025. We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they're used to from previous releases. Further details are available on our https://en.opensuse.org/openSUSE:Roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes. Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase. There is no plan to make a Leap 15.7, however, we still need to deliver previously released community packages from Leap 15 via Package HUB for the upcoming SLES 15 SP7. This is why there are openSUSE:Backports:SLE-15-SP7 project and 15.7 repos in OBS. **Who should get it?** This is a pre-alpha product that is not intended to be installed as your daily driver. I highly recommend starting with the installation in a virtual machine and becoming familiar with the online installer Agama. The target audience for pre-Alpha are early adopters and contributors who would like to actively be part of this large effort. Adopters should consider booting Agama Media from time to time just to check compatibility with their hardware. For non-contributor users, I highly recommend waiting until we have a Beta, which is expected in the late Spring of 2025. **How to report bugs?** I'd like to kindly ask you to check https://en.opensuse.org/openSUSE:Known_bugs_16.0 before reporting a new issue. If you find a new issue that is likely to affect users, please feel free to add it to the page. Specifically for Agama I highly recommend using https://github.com/agama-project/agama/issues and collaborating with the YaST team on suggestions and incorporating any changes. For the rest of the components, the workflow isn't changing; just select version 16.0. Details in https://en.opensuse.org/openSUSE:Submitting_bug_reports#Regular_release_prod.... **Feature requests** All changes to packages inherited from SLES 16 need to be requested via our public feature request workflow https://code.opensuse.org/leap/features. Feature requests will be reviewed every Monday at a feature review meeting, see calendar.opensuse.org, where we'll convert code-o-o requests into JIRA requests used by SUSE Engineering where applicable. The factory-auto bot will reject all code submit requests against SLES packages with a pointer to code-o-o. You can get a list of all SLFO/SLES packages simply by running `osc ls SUSE:SLFO:1.1:Build`. Just for clarification SLFO, SUSE Linux Framework One, is the source pool for SLES 16 and SL Micro 6.X. I highly recommend using code-o-o to coordinate larger community efforts such as Xfce enablement, where we will likely need to update some of SLES dependencies. This allows us to share the larger story and better reasoning for related SLES update requests. The list of features is also extremely valuable for the Release article. **Where to submit packages, how is it built, and where is it tested?** Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can [mirror](https://en.opensuse.org/Portal:Jump:OBS:SRMirroring) SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests. For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group https://openqa.opensuse.org/group_overview/129. Later, we plan to rework the existing Leap 16.0 Images job group https://openqa.opensuse.org/group_overview/126 for testing the remaining appliance images. The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+). Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers for Leap 16.0 enablement https://progress.opensuse.org/issues/164141 and upgrade from 15.6 https://progress.opensuse.org/issues/166562. Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we'd like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over. **Involvement in branding and marketing efforts** I'm very proud to announce fresh branding efforts and want to thank all the people who helped give Leap and Tumbleweed a new look. We plan to publish an article or a video about the changes, and further plans as we still have a surprise or two in our pocket. Do you want to help us on this front? Spread the news and feel free to join the #openSUSE_Marketing Telegram channel https://t.me/openSUSE_Marketing! Details at https://en.opensuse.org/openSUSE:Marketing_team Many thanks to all who helped us to reach this point. Lubos Kocman on behalf of the openSUSE Release team
On 2024-10-07 14:01, Lubos Kocman via openSUSE Factory wrote:
Hello everyone!
(Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/)
404 Not Found nginx Maybe you mean https://news.opensuse.org/2024/10/07/leap-16-0-prealpha/ ? -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Ah yes, the preview link was from when I hoped it could have been out on 3rd sorry. https://news.opensuse.org/2024/10/07/leap-16-0-prealpha/ Lubos On Mon, Oct 7, 2024 at 9:10 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-10-07 14:01, Lubos Kocman via openSUSE Factory wrote:
Hello everyone!
(Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/)
404 Not Found
nginx
Maybe you mean
https://news.opensuse.org/2024/10/07/leap-16-0-prealpha/
?
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
-- Best regards Luboš Kocman openSUSE Leap Release Manager
Translated the get. site to Swedish now Den mån 7 okt. 2024 kl 14:02 skrev Lubos Kocman via openSUSE Factory <factory@lists.opensuse.org>:
Hello everyone!
(Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/)
I'd like to announce the start of development and the public availability of what we currently refer to as Leap 16.0 pre-Alpha. Since this is a pre-Alpha version, significant changes may occur, and the final product may look very different in the Alpha, Beta, Release Candidate, or General Availability stages. The installer will *currently* offer you Base, GNOME, and KDE.
Users can get our new Agama install images from https://get.opensuse.org/leap/16.0. The installer will *currently* offer you Base, GNOME, and KDE installation.
Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.
We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they're used to from previous releases.
Further details are available on our https://en.opensuse.org/openSUSE:Roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.
Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.
There is no plan to make a Leap 15.7, however, we still need to deliver previously released community packages from Leap 15 via Package HUB for the upcoming SLES 15 SP7. This is why there are openSUSE:Backports:SLE-15-SP7 project and 15.7 repos in OBS.
**Who should get it?** This is a pre-alpha product that is not intended to be installed as your daily driver. I highly recommend starting with the installation in a virtual machine and becoming familiar with the online installer Agama.
The target audience for pre-Alpha are early adopters and contributors who would like to actively be part of this large effort. Adopters should consider booting Agama Media from time to time just to check compatibility with their hardware.
For non-contributor users, I highly recommend waiting until we have a Beta, which is expected in the late Spring of 2025.
**How to report bugs?**
I'd like to kindly ask you to check https://en.opensuse.org/openSUSE:Known_bugs_16.0 before reporting a new issue. If you find a new issue that is likely to affect users, please feel free to add it to the page.
Specifically for Agama I highly recommend using https://github.com/agama-project/agama/issues and collaborating with the YaST team on suggestions and incorporating any changes.
For the rest of the components, the workflow isn't changing; just select version 16.0. Details in https://en.opensuse.org/openSUSE:Submitting_bug_reports#Regular_release_prod....
**Feature requests**
All changes to packages inherited from SLES 16 need to be requested via our public feature request workflow https://code.opensuse.org/leap/features.
Feature requests will be reviewed every Monday at a feature review meeting, see calendar.opensuse.org, where we'll convert code-o-o requests into JIRA requests used by SUSE Engineering where applicable.
The factory-auto bot will reject all code submit requests against SLES packages with a pointer to code-o-o. You can get a list of all SLFO/SLES packages simply by running `osc ls SUSE:SLFO:1.1:Build`.
Just for clarification SLFO, SUSE Linux Framework One, is the source pool for SLES 16 and SL Micro 6.X.
I highly recommend using code-o-o to coordinate larger community efforts such as Xfce enablement, where we will likely need to update some of SLES dependencies. This allows us to share the larger story and better reasoning for related SLES update requests. The list of features is also extremely valuable for the Release article.
**Where to submit packages, how is it built, and where is it tested?**
Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can [mirror](https://en.opensuse.org/Portal:Jump:OBS:SRMirroring) SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.
For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group https://openqa.opensuse.org/group_overview/129. Later, we plan to rework the existing Leap 16.0 Images job group https://openqa.opensuse.org/group_overview/126 for testing the remaining appliance images.
The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).
Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers for Leap 16.0 enablement https://progress.opensuse.org/issues/164141 and upgrade from 15.6 https://progress.opensuse.org/issues/166562.
Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we'd like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.
**Involvement in branding and marketing efforts**
I'm very proud to announce fresh branding efforts and want to thank all the people who helped give Leap and Tumbleweed a new look. We plan to publish an article or a video about the changes, and further plans as we still have a surprise or two in our pocket.
Do you want to help us on this front? Spread the news and feel free to join the #openSUSE_Marketing Telegram channel https://t.me/openSUSE_Marketing! Details at https://en.opensuse.org/openSUSE:Marketing_team
Many thanks to all who helped us to reach this point.
Lubos Kocman on behalf of the openSUSE Release team
I like Leap 15.6 . . . and I do like "developmental" distros . . . sometimes "pre-alpha" is almost like "beta" . . . but sometimes it is like "Sid" . . . which these days has become very stable, but was known for blowing up. Usually I move up in iteration by editing the repos, changing the "15.6" to "16" . . . and then just go with the changes . . . sometimes that results in the system blowing up, like my Slow Roll install just imploded on itself leaving an empty partition of smoking data . . . . So, I have become a tad less enthusiastic in that my time is more critical than the system . . . but running "multiboot" generally gives me options . . . meaning that my Leap install is "experimental." But, question, here you are recommending "virtual" install, and I think traditionally openSUSE doesn't offer "live" iso's?? Is that the case here as well, or there will be a live option to test out for compatibility with machine??
But, question, here you are recommending "virtual" install, and I think traditionally openSUSE doesn't offer "live" iso's?? Is that the case here as well, or there will be a live option to test out for compatibility with machine??
Leap hasn't had a live iso for someetime. Tumbleweed offers live isos, but not Leap, which can be found on the downloads tab below the "Download"s buttons that said "We also have Minimal Virtual Machine, Live images. Check out Alternative Downloads!"
Hello Fritz I recommend what's currently available plus Agama is the preferred way to get Leap 16. Live isos will come later. Regarding editing repos check what I came up with as a solution for Leap Micro migration. I'd like to advertise the same for Leap 15.6 -> Leap 16.0 migration. https://en.opensuse.org/SDB:System_upgrade_to_LeapMicro_6.0#2._Fetch_new_rep... new keys were already introduced to openSUSE as part of the openSUSE-build-key update, so that step shall not be necessary. Long story short I'd prefer if there would be no need to edit repos manually, which would allow us to keep upgrade instructions on one or two lines. Lubos On Tue, Oct 8, 2024 at 1:45 AM Fritz Hudnut <non.space.1@gmail.com> wrote:
I like Leap 15.6 . . . and I do like "developmental" distros . . . sometimes "pre-alpha" is almost like "beta" . . . but sometimes it is like "Sid" . . . which these days has become very stable, but was known for blowing up.
Usually I move up in iteration by editing the repos, changing the "15.6" to "16" . . . and then just go with the changes . . . sometimes that results in the system blowing up, like my Slow Roll install just imploded on itself leaving an empty partition of smoking data . . . . So, I have become a tad less enthusiastic in that my time is more critical than the system . . . but running "multiboot" generally gives me options . . . meaning that my Leap install is "experimental."
But, question, here you are recommending "virtual" install, and I think traditionally openSUSE doesn't offer "live" iso's?? Is that the case here as well, or there will be a live option to test out for compatibility with machine??
-- Best regards Luboš Kocman openSUSE Leap Release Manager
LK: Thanks for the reply . . . replies inline: On Tue, Oct 8, 2024 at 1:05 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
Hello Fritz
I recommend what's currently available plus Agama is the preferred way to get Leap 16. Live isos will come later.
I have not checked out Agama yet . . . so I don't know if that is something like #zypper in agama and that will add that to my Leap 15.6 and that will be a work in progress as Leap 16 is developed?? Or, that is a fresh install?
Regarding editing repos check what I came up with as a solution for Leap Micro migration. I'd like to advertise the same for Leap 15.6 -> Leap 16.0 migration. https://en.opensuse.org/SDB:System_upgrade_to_LeapMicro_6.0#2._Fetch_new_rep... new keys were already introduced to openSUSE as part of the openSUSE-build-key update, so that step shall not be necessary. Long story short I'd prefer if there would be no need to edit repos manually, which would allow us to keep upgrade instructions on one or two lines.
Similar question here, also haven't played with Micro . . . but the instructions you linked to are showing the repos set to Micro 6?? Or that would be edited to "Leap 16"??? It seems like the new Leap 16 in a sense is not exactly a step up from the bones of 15.6, but is a hybrid combo of Micro6 + Agama??? I did take a look at the "manual" repo data . . . which doesn't exactly look like what is seen in the YaSt GUI repo info . . . ??? Meaning that, what, there are just 4 or so repo lines for the new Leap iteration?? The thing I like about editing the existing repos is, it is very "clear" when I change "15.6" to "16" and then let zypper work its magic on them . . . . Seems like the sage advice is to not go that way, but seems like running the commands would switch the repos to Micro 6 as the first step?? And then go from there by spinning Agama into it?? I like to have a bit more clarity before I roll my dice . . . in my world it's all about "luck" . . . . : - ))) F
Lubos
On Tue, Oct 8, 2024 at 1:45 AM Fritz Hudnut <non.space.1@gmail.com> wrote:
I like Leap 15.6 . . . and I do like "developmental" distros . . . sometimes "pre-alpha" is almost like "beta" . . . but sometimes it is like "Sid" . . . which these days has become very stable, but was known for blowing up.
Usually I move up in iteration by editing the repos, changing the "15.6" to "16" . . . and then just go with the changes . . . sometimes that results in the system blowing up, like my Slow Roll install just imploded on itself leaving an empty partition of smoking data . . . . So, I have become a tad less enthusiastic in that my time is more critical than the system . . . but running "multiboot" generally gives me options . . . meaning that my Leap install is "experimental."
But, question, here you are recommending "virtual" install, and I think traditionally openSUSE doesn't offer "live" iso's?? Is that the case here as well, or there will be a live option to test out for compatibility with machine??
--
Best regards
Luboš Kocman openSUSE Leap Release Manager
Hello Fritz Based on what I hear and the fact that you're already asking about zypper dup, these questions should wait until we're closer for at least Beta (late spring 2025). What we're discussing here is something in a preAlpha state, where we're in the early testing on any migration steps which are not fully written in the stone yet. If you want to quickly see how the distro and install experience looks then please check the Leap 16.0 review https://www.youtube.com/watch?v=i6vmC-BpfLA or test it in a VM as suggested in the announcement. Thank you Lubos On Tue, Oct 8, 2024 at 4:33 PM Fritz Hudnut <non.space.1@gmail.com> wrote:
LK:
Thanks for the reply . . . replies inline:
On Tue, Oct 8, 2024 at 1:05 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
Hello Fritz
I recommend what's currently available plus Agama is the preferred way to get Leap 16. Live isos will come later.
I have not checked out Agama yet . . . so I don't know if that is something like #zypper in agama and that will add that to my Leap 15.6 and that will be a work in progress as Leap 16 is developed?? Or, that is a fresh install?
Regarding editing repos check what I came up with as a solution for Leap Micro migration. I'd like to advertise the same for Leap 15.6 -> Leap 16.0 migration. https://en.opensuse.org/SDB:System_upgrade_to_LeapMicro_6.0#2._Fetch_new_rep... new keys were already introduced to openSUSE as part of the openSUSE-build-key update, so that step shall not be necessary. Long story short I'd prefer if there would be no need to edit repos manually, which would allow us to keep upgrade instructions on one or two lines.
Similar question here, also haven't played with Micro . . . but the instructions you linked to are showing the repos set to Micro 6?? Or that would be edited to "Leap 16"??? It seems like the new Leap 16 in a sense is not exactly a step up from the bones of 15.6, but is a hybrid combo of Micro6 + Agama???
I did take a look at the "manual" repo data . . . which doesn't exactly look like what is seen in the YaSt GUI repo info . . . ??? Meaning that, what, there are just 4 or so repo lines for the new Leap iteration?? The thing I like about editing the existing repos is, it is very "clear" when I change "15.6" to "16" and then let zypper work its magic on them . . . . Seems like the sage advice is to not go that way, but seems like running the commands would switch the repos to Micro 6 as the first step?? And then go from there by spinning Agama into it??
I like to have a bit more clarity before I roll my dice . . . in my world it's all about "luck" . . . . : - )))
F
Lubos
On Tue, Oct 8, 2024 at 1:45 AM Fritz Hudnut <non.space.1@gmail.com> wrote:
I like Leap 15.6 . . . and I do like "developmental" distros . . . sometimes "pre-alpha" is almost like "beta" . . . but sometimes it is like "Sid" . . . which these days has become very stable, but was known for blowing up.
Usually I move up in iteration by editing the repos, changing the "15.6" to "16" . . . and then just go with the changes . . . sometimes that results in the system blowing up, like my Slow Roll install just imploded on itself leaving an empty partition of smoking data . . . . So, I have become a tad less enthusiastic in that my time is more critical than the system . . . but running "multiboot" generally gives me options . . . meaning that my Leap install is "experimental."
But, question, here you are recommending "virtual" install, and I think traditionally openSUSE doesn't offer "live" iso's?? Is that the case here as well, or there will be a live option to test out for compatibility with machine??
--
Best regards
Luboš Kocman openSUSE Leap Release Manager
-- Best regards Luboš Kocman openSUSE Leap Release Manager
LK: Thanks for the "wait and see" advice . . . might take that advice. I probably could figure it out by following the wiki, but, these days time is more precious than gold, and I would want to set the repos **one time** and then go from there. Based upon the Slow Roll roll out, where it seemed like repos were changing every couple of days . . . . Don't have time for that noise these days. I do like "bleeding edge" . . . but, with a controlled "late Alpha" style bleed . . . not arterial blood spurting all over the place like in a Kurosawa film . . . . : - 0
I have a TW install . . . a Sid . . . a Manjaro . . . a Trixie . . . a few others . . . . I also have a Leap 15.6 . . . which I would plan to move to 16 . . . don't think there is a need for two Leap installs. As mentioned previously in the thread, I did have a Slow Roll, thinking it would "split the dif" between the semi-volatile TW and the generally more stable Leap . . . but Slow Roll smoked itself in a dup perhaps between repo changes . . . . Nuked the install and went to LMDE . . . to mixed results on my ancient '12 Mac Pro . . . . We'll see, if I get some spare time to fiddle with the pre-Alpha of 16, I will . . . having a live iso option makes that much easier to do.
Righto, as I said before I recommend waiting until Beta based on having a rough idea about your plans. I'm sure live images will come later. Cheers Lubos On Wed, Oct 9, 2024 at 5:57 PM Fritz Hudnut <non.space.1@gmail.com> wrote:
I have a TW install . . . a Sid . . . a Manjaro . . . a Trixie . . . a few others . . . . I also have a Leap 15.6 . . . which I would plan to move to 16 . . . don't think there is a need for two Leap installs.
As mentioned previously in the thread, I did have a Slow Roll, thinking it would "split the dif" between the semi-volatile TW and the generally more stable Leap . . . but Slow Roll smoked itself in a dup perhaps between repo changes . . . . Nuked the install and went to LMDE . . . to mixed results on my ancient '12 Mac Pro . . . .
We'll see, if I get some spare time to fiddle with the pre-Alpha of 16, I will . . . having a live iso option makes that much easier to do.
-- Best regards Luboš Kocman openSUSE Leap Release Manager
Fritz, zypper has a feature that lets you substitute variable $releasever for the hard-coded release.version (e.g. 15.6) in your /etc/zypp/repos.d/ files, allowing you to dist-upgrade with zypper --releasever=16.0 ... etc., so no more manual editing of repository URLs is necessary. See https://en.opensuse.org/SDB:System_upgrade#2._Update_the_repos for details. Leslie On 2024-10-07 18:42:49 Fritz Hudnut wrote:
I like Leap 15.6 . . . and I do like "developmental" distros . . . sometimes "pre-alpha" is almost like "beta" . . . but sometimes it is like "Sid" . . . which these days has become very stable, but was known for blowing up.
Usually I move up in iteration by editing the repos, changing the "15.6" to "16" . . . and then just go with the changes . . . sometimes that results in the system blowing up, like my Slow Roll install just imploded on itself leaving an empty partition of smoking data . . . . So, I have become a tad less enthusiastic in that my time is more critical than the system . . . but running "multiboot" generally gives me options . . . meaning that my Leap install is "experimental."
But, question, here you are recommending "virtual" install, and I think traditionally openSUSE doesn't offer "live" iso's?? Is that the case here as well, or there will be a live option to test out for compatibility with machine??
-- Platform: Linux Distribution: openSUSE Leap 15.6 - x86_64
@J Leslie T: Well, that looks interesting, looks basic enough that even I could follow how to do it . . . . My question is if that relates to the Leap 15xx series . . . but there might be some issue with using that for getting to Leap 16?? In that 16 seems to be a hybrid of distros . . .??? If, traditionally it has been so simple as to just edit the repos to get from say 15.4 to 15.5, as could be done . . . why now was the guidance to either do fresh install, or wait until Beta, and so forth??? But, if indeed it is so straightforward as to use #zypper --releasever=16.0 to get the repos tuned up in what looks like should be a TTY, then that could be helpful to getting into Leap 16 in the Alpha phases of its growing process . . . a time saver, etc. F
Hello Leslie, you do need to touch repo files (even with a zypper call) if we add / remove repositories in a new release and you want to upgrade. There bumping of the releasever will not help you, you have to add/repos too. This is where openSUSE-repos help. The releasever and bunch of new variables like DIST_ARCH for ports are already part of openSUSE-repo definitions. Cheers Lubos
Hi Lubos, Am 14.10.24 um 10:21 schrieb Lubos Kocman via openSUSE Factory:
This is where openSUSE-repos help. The releasever and bunch of new variables like DIST_ARCH for ports are already part of openSUSE-repo definitions.
I had a look at the openSUSE-repos-Tumbleweed package and was surprised (in a positive way!). The last time I had to do with SUSE-managed repos was during some Leap update (maybe when Leap15 switched to SLES sources), which left my system with a horrible list of unreasonably named repos (the names were about two screen lines long, making "zypper lr" unreadable etc). I never looked back after that and just the suggestion of "have someone at (open)SUSE curate my repos" was an idea making me shudder and immediately reject it ;-) Now the idea of having just some metafile (the repoindex.xml) that describes the repos seems like a good one. I still don't dare installing it on one of my systems, because I don't know what it will do. * Will it generate "virtual repo files" on the fly? If yes: * where does it note down if I enable e.g. debug or source repos * Will it generate real repo files? If yes: * will they overwrite for example my own repo-oss.repo? I did already find https://en.opensuse.org/openSUSE:Standards_Repository_Index_Service and the link from there to the libzypp documentation, however they did not answer my questions. A look at the %pre/post scripts of openSUSE-repos-Tumbleweed only confirmed that the package does interfere with my old repo files. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Lubos, Am 07.10.24 um 14:01 schrieb Lubos Kocman via openSUSE Factory:
Hello everyone!
(Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/)
[...]
Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.
We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they're used to from previous releases.
Further details are available on our https://en.opensuse.org/openSUSE:Roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.
Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.
I see that there is only a bare minimum of packages in https://build.opensuse.org/project/show/openSUSE:Leap:16.0 How is the policy of adding packages to Leap 16? Will there be an automatic import of all Leap 15.x packages into Leap 16? Is the intention to keep the number of packages small, or shall there be as many packages (or more) in Leap 16 as in former Leap editions? Do maintainers need to take actions to get their packages into Leap 16? Sorry for these many questions, but I think some guidance is needed at this point. I see that you described some thoughts about package submission below, but for me this is not really concrete enough. Thanks, Manfred PS: and I really hope there will be some way to bypass the SLES-induced package blockage all over the place.
**Where to submit packages, how is it built, and where is it tested?**
Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can [mirror](https://en.opensuse.org/Portal:Jump:OBS:SRMirroring) SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.
For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group https://openqa.opensuse.org/group_overview/129. Later, we plan to rework the existing Leap 16.0 Images job group https://openqa.opensuse.org/group_overview/126 for testing the remaining appliance images.
The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).
Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers for Leap 16.0 enablement https://progress.opensuse.org/issues/164141 and upgrade from 15.6 https://progress.opensuse.org/issues/166562.
Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we'd like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.
Lubos Kocman on behalf of the openSUSE Release team
Hello Manfred Max Lin will be mass-adding ~6k packages. But we should not just showel packages around, these should be also somehow tested. And our https://openqa.opensuse.org/group_overview/129 is rather limited now thanks to the new installer. Just submit packages that you use/need/miss to openSUSE:Leap:16.0, submissions will have to be reviewed by the maintainer anyway. I am especially interested in feedback such as "don't add mlocate since we already have plocate" etc, this is extremely useful and keeps our project fresh. Lubos On Tue, Oct 15, 2024 at 12:05 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Lubos,
Am 07.10.24 um 14:01 schrieb Lubos Kocman via openSUSE Factory:
Hello everyone!
(Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/)
[...]
Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.
We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they're used to from previous releases.
Further details are available on our https://en.opensuse.org/openSUSE:Roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.
Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.
I see that there is only a bare minimum of packages in https://build.opensuse.org/project/show/openSUSE:Leap:16.0
How is the policy of adding packages to Leap 16? Will there be an automatic import of all Leap 15.x packages into Leap 16?
Is the intention to keep the number of packages small, or shall there be as many packages (or more) in Leap 16 as in former Leap editions?
Do maintainers need to take actions to get their packages into Leap 16?
Sorry for these many questions, but I think some guidance is needed at this point. I see that you described some thoughts about package submission below, but for me this is not really concrete enough.
Thanks, Manfred
PS: and I really hope there will be some way to bypass the SLES-induced package blockage all over the place.
**Where to submit packages, how is it built, and where is it tested?**
Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can [mirror](https://en.opensuse.org/Portal:Jump:OBS:SRMirroring) SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.
For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group https://openqa.opensuse.org/group_overview/129. Later, we plan to rework the existing Leap 16.0 Images job group https://openqa.opensuse.org/group_overview/126 for testing the remaining appliance images.
The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).
Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers for Leap 16.0 enablement https://progress.opensuse.org/issues/164141 and upgrade from 15.6 https://progress.opensuse.org/issues/166562.
Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we'd like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.
Lubos Kocman on behalf of the openSUSE Release team
-- Best regards Luboš Kocman openSUSE Leap Release Manager
On Tue, Oct 15, 2024 at 7:19 PM Lubos Kocman via openSUSE Factory <factory@lists.opensuse.org> wrote:
Hello Manfred
Max Lin will be mass-adding ~6k packages. But we should not just showel packages around, these should be also somehow tested. And our https://openqa.opensuse.org/group_overview/129 is rather limited now thanks to the new installer.
I'm ready to trigger updater script to submit packages to Leap 16.0 from Factory in case package has a successfully build on the pretest-project[1], package maintainer should received a review request for each created ones. And please note that, there is a limited list of package exist in pretest proejct[1], only package has been updated in last 1000 days to openSUSE:Factory project. If your maintained package(or your needs) does not submit to openSUSE:Leap:16.0 project via our script, you're welcomed to submit it to openSUSE:Leap:16.0 from openSUSE:Factory project. [1] https://build.opensuse.org/project/show/openSUSE:Leap:16.0:FactoryCandidates Regards, Max
Just submit packages that you use/need/miss to openSUSE:Leap:16.0, submissions will have to be reviewed by the maintainer anyway. I am especially interested in feedback such as "don't add mlocate since we already have plocate" etc, this is extremely useful and keeps our project fresh.
Lubos
On Tue, Oct 15, 2024 at 12:05 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Lubos,
Am 07.10.24 um 14:01 schrieb Lubos Kocman via openSUSE Factory:
Hello everyone!
(Also available in html https://news.opensuse.org/2024/10/03/leap-16-0-prealpha/)
[...]
Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.
We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they're used to from previous releases.
Further details are available on our https://en.opensuse.org/openSUSE:Roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.
Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.
I see that there is only a bare minimum of packages in https://build.opensuse.org/project/show/openSUSE:Leap:16.0
How is the policy of adding packages to Leap 16? Will there be an automatic import of all Leap 15.x packages into Leap 16?
Is the intention to keep the number of packages small, or shall there be as many packages (or more) in Leap 16 as in former Leap editions?
Do maintainers need to take actions to get their packages into Leap 16?
Sorry for these many questions, but I think some guidance is needed at this point. I see that you described some thoughts about package submission below, but for me this is not really concrete enough.
Thanks, Manfred
PS: and I really hope there will be some way to bypass the SLES-induced package blockage all over the place.
**Where to submit packages, how is it built, and where is it tested?**
Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can [mirror](https://en.opensuse.org/Portal:Jump:OBS:SRMirroring) SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.
For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group https://openqa.opensuse.org/group_overview/129. Later, we plan to rework the existing Leap 16.0 Images job group https://openqa.opensuse.org/group_overview/126 for testing the remaining appliance images.
The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).
Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers for Leap 16.0 enablement https://progress.opensuse.org/issues/164141 and upgrade from 15.6 https://progress.opensuse.org/issues/166562.
Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we'd like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.
Lubos Kocman on behalf of the openSUSE Release team
--
Best regards
Luboš Kocman openSUSE Leap Release Manager
participants (10)
-
Axel Braun -
Carlos E. R. -
ddemaio openSUSE -
Fritz Hudnut -
J Leslie Turriff -
Lubos Kocman -
Luna Jernberg -
Manfred Schwarb -
Max Lin -
Stefan Seyfried