Search results for

Re: VOTE ON SLOWROLL NAME

by Joe Salmeri

On 9/25/23 15:37, Paul Lipps via openSUSE Factory wrote: > >> On Sep 25, 2023, at 2:23 PM, Arjen de Korte <suse+build(a)de-korte.org> >> wrote: >> >> Citeren Paul Lipps via openSUSE Factory <factory(a)lists.opensuse.org>: >> >>> This would be a great opportunity to consolidate folks on >>> Tumbleweed. If you don’t like the frequency of updates, then simply >>> don’t update as often. >> >> This only works if one doesn't want to install additional packages. >> More often than not, additional packages will have dependencies that >> can no longer be satisfied if you're several updates behind. > > > Then that would be the time to update. When you are ready to install > new packages, update. That’s hardly unreasonable even for slow folks. > Anyway, this ship has already sailed. No going back now. Slowroll is > here to stay, but it clearly needs a better name. > > > Paul Lipps > > "Anyone who is unwilling to learn is entitled to absolutely nothing." > - graysonf Another option us to use tumbleweed-cli which allows you to lock yourself to one of the last 20 builds. Generally that would allow you 1 month ( or a little less ) where you could install additional packages because you are pointed to a specific release. I have been using it for several years now and it works great. I generally update in the 2 - 4 week range depending on the results at openqa as well as where it fits into whatever projects I am working on. -- Regards, Joe

1 year, 2 months

Re: vote on Slowroll name

by Knurpht-openSUSE

Op woensdag 20 september 2023 20:35:48 CEST schreef Eric Schwarzenbach: > I would just like to offer some criteria to consider for choosing a name. > > 1) Either build on the familiarity of existing names, or make the name > completely descriptive, so the name already suggests something about what > it is. "Tumbleweed-Stable" is an example of this, as is Slowroll. Whereas > something like "Descent" is only meaningful once someone reads about it. > > 2) Keep to words with positive associations, not negative. "Stable" is a > positive and really the actual goal here I think. "Slow" is only a positive > from the perspective of "Tumbleweed moves too fast". For a new user "slow" > may not sound very positive. (Nor does "sleepy", "stumble", "sloth", etc. > This survey has lots of terrible names I wish I could vote against.) If not > positive, neutral like "roll". > > 3) Don't create confusion with other distros. For example "Gecko" appears in > some of the names in the survey. There is already a GeckoLinux > (http://geckolinux.github.io/) which is a distro that is basically an > alternate installer and set of customizations of OpenSUSE (both Tumbleweed > and Leap). > > I hope this survey is just a first round to weed down the unweildy list > presented there, and there will be a future round or rounds with a smaller > list, and ideally, ranked-choice voting. > > Cheers, > Eric Doesn't "Interval" cover all that ? -- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team

1 year, 2 months

Re: Is it possible for Slowroll to officially support the integrity of NVidia and VMWare modules?

by Andrei Borzenkov

On 27.09.2023 22:23, Malcolm wrote: > My understanding for the nvidia rpm's use dkms to rebuild for the > kernel in use? > No, they do not.

1 year, 2 months

Re: slowroll

by Jan Engelhardt

On Thursday 2023-09-14 15:49, Larry Len Rainey wrote: >I keep forgetting that for reasons that do not make sense Then maybe reread https://kubic.opensuse.org/blog/2019-12-05-usr-etc/ ?

1 year, 2 months

Re: Development start of Leap 16.0

by Axel Braun

Am Dienstag, 8. Oktober 2024, 17:16:27 MESZ schrieb Fritz Hudnut: > I do like "bleeding edge" . . . Then you should go for TW...or Slowroll

1 month, 2 weeks

Re: Slowroll kernel signing key changed to openSUSE:ALP?

by Andrei Borzenkov

On 01.10.2023 11:34, Bernhard M. Wiedemann wrote: > > > On 01/10/2023 09.02, Andrei Borzenkov wrote: >> warning: kernel-default-6.4.12-1.13.x86_64.rpm: Header V3 RSA/SHA256 >> Signature, key ID 1cbb508c: NOKEY >> /etc/uefi >> /etc/uefi/certs >> /etc/uefi/certs/FFF96EF6.crt >> bor@bor-Latitude-E5450:~/tmp$ rpm -qlp >> kernel-default-6.4.11-1.1.x86_64.rpm | grep /etc/ >> warning: kernel-default-6.4.11-1.1.x86_64.rpm: Header V3 RSA/SHA512 >> Signature, key ID 29b700a4: NOKEY >> /etc/uefi >> /etc/uefi/certs >> /etc/uefi/certs/1F673297.crt >> bor@bor-Latitude-E5450:~/tmp$ >> >> It is expected for the future? > > No, it will change once we move out of the openSUSE:ALP namespace. > I guess the actual question was - why RPMs are rebuilt at all? Was not the idea to use Tumbleweed binaries? At least, that is how I understood it so far. >> I tried to understand how packages actually get into slowroll, but >> failed. If someone could provide an overview how it works I would >> certainly appreciate it. > > So far, I use > https://github.com/bmwiedemann/slowroll-tools > and run > DRYRUN=0 make daily > and later > make release > There is no "release" target in Makefile. > > The first checks for what updates were released in Tumbleweed and > submits a selection into > https://build.opensuse.org/project/show/openSUSE:ALP:Experimental:Slowroll:… > Nor is there any reference to Staging in sources. > After everything was built and published there, openQA testing is still > missing, because the product-builder does not work with OBS' > download-on-demand method we use for the TW-snaphot base repo. So we > don't have an install-DVD or working Net-install there. > > > Then `make release` uses `osc release` to publish updates into The only osc invocation I can find is "osc copypac". I was not aware of "osc release", but that explains why build log is completely missing. Same situation as with Leap - binaries just pop up in repository without any way to see how they were built. My feeling is that it does not help to attract contributors. It is already the problem with Leap where you have to be SUSE employee to actually see what's going on. But here everything is on OBS ... or so I naively expected. Is it possible to see build logs for packages moved from Staging to the main (or, better, update) repository? > https://build.opensuse.org/project/show/openSUSE:ALP:Experimental:Slowroll > > If Factory binaries are deemed equivalent by build-compare, those are > published instead. I might drop this part later and not re-use any > TW/Factory binaries. > We also need something like the install-check to ensure we include > required updates of dependencies. > > > > Ciao > Bernhard M.

1 year, 1 month

Re: Testers Wanted: longterm kernel

by Joe Salmeri

On 2/2/24 12:18, Robert Frohl wrote: > Hi all, > > small update for the longterm kernel: > > earlier today the last 6.1 update reached the test repo (6.1.76) and I > have a version for 6.6 ready. I am hoping that the new longterm kernel > (specifically 6.6.15) will reach the test repo [0] on Sunday morning. > > I wanted to give a heads up in case some people do not want to update > right away. From my POV there is nothing problematic that I am aware > of, never the less it is the first major longterm kernel update that I > am doing. > > Cheers, > Robert > Are there any plans to have the LT kernel packages available in TW ? > > > On 19.12.23 14:07, Robert Frohl wrote: >> Hi all, >> >> I am looking for feedback on a side project that I have been working >> on the last couple of months: Introducing a rolling longterm kernel >> package to Factory. >> >> >> # Motivation >> >> The previous distribution I used as my daily driver offered a LTS >> variant of the kernel and that always served me well, if some change >> in kernel development broke a feature that I was relying on. When I >> moved to Tumbleweed I felt that this was missing, but because of >> snapper and file system rollback, the impact was never so severe. >> >> With the announcement of slowroll I had the feeling that having a >> longterm kernel might fill a gap, for more stable workloads or >> software packages that have a dependency onto the kernel, but can not >> keep up with new kernel versions. Therefor I started to look into how >> feasible it would be to have a longterm kernel in Factory. >> >> >> # General vision >> >> Having a longterm kernel package that follows the rolling release >> model and will track the latest longterm kernel, once the stable >> kernel has moved to a higher version number. The configuration should >> be as similar as possible to the stable kernel. The kernel packaging >> should use existing infrastructure and processes that are used for >> the stable kernel, to avoid re-inventing the wheel. >> >> >> # Current state and open points >> >> I have a longterm kernel version (6.1.68) available for x86_64 under >> [0]. This version is using the existing systems and processes. I am >> now at a state where I think further feedback would be helpful. >> >> Known open points that I want to take care of before trying to get >> into Factory: >> >> - Move to the new longterm version (6.6) to get a grasp of the >> process and see what potential fallout the update might have for users >> - Find out if external kernel modules would have a problem with >> different kernel versions and if so find a solution [1] >> >> >> Where this will go is not clear at the moment, I talked with Bernhard >> and dimstar if there is general interest for a longterm kernel in >> Factory. It might be an option as a base for slowroll. But there has >> been no decision on how to proceed. Currently just evaluating if the >> longterm kernel is feasible for Factory, if openSUSE users would be >> interested and if a community maintainer can handle the workload, as >> I am not a kernel developer in my day job. >> >> >> If someone has a use case that does not depend on external kernel >> modules and some time over the holidays, I would really appreciate >> feedback, be it improvements or any other type (also if things work >> out ok and there are no complaints ;) ). >> >> Cheers, >> Robert >> >> >> p.s: without the help and support of others, this little experiment >> would have been impossible to do, I would like to specifically thank >> a couple of people for their support and patience with my questions: >> Michal, Takashi, Jiri and Marcus. >> I would also like to thank SUSE for the time they make available >> during hackweek, as I spend some of my time on the longterm kernel. >> >> >> p.p.s: you can install the longterm kernel by: >> > zypper addrepo >> http://download.opensuse.org/repositories/Kernel:/slowroll/standard/Kernel:… >> > zypper refresh >> > zypper install kernel-longterm >> >> [0] http://download.opensuse.org/repositories/Kernel:/slowroll/standard/ >> [1] https://bugzilla.suse.com/show_bug.cgi?id=1217824 > -- Regards, Joe

9 months, 3 weeks

Re: Testers Wanted: longterm kernel

by Nikolai Nikolaevskii

IMHO useful thing for Nvidia GPUs, Intel network drivers, etc. Possibly it will be usable with Leap 15.6 after glibc upgrade. Forum topic: https://forums.opensuse.org/t/testers-wanted-longterm-kernel-for-tw-slowrol…

11 months, 1 week

Re: VOTE ON SLOWROLL NAME

by Carlos E. R.

On 2023-09-25 23:50, Patrick Shanahan wrote: > * Carlos E. R. <robin.listas(a)telefonica.net> [09-25-23 17:11]: >> On 2023-09-25 21:38, Patrick Shanahan wrote: >>> * Arjen de Korte <suse+build(a)de-korte.org> [09-25-23 15:26]: >>>> Citeren Paul Lipps via openSUSE Factory <factory(a)lists.opensuse.org>: >>>> >>>>> This would be a great opportunity to consolidate folks on Tumbleweed. If >>>>> you don’t like the frequency of updates, then simply don’t update as >>>>> often. >>>> >>>> This only works if one doesn't want to install additional packages. More >>>> often than not, additional packages will have dependencies that can no >>>> longer be satisfied if you're several updates behind. >>> >>> with that in mind, the same will apply for "slowroll". >>> >>> haven't you noticed the number of posts asking why such-and-such newer >>> version of xxx is not available in the leap packages? >> >> Leap was not the choice many of us wanted, but simply the only available >> choice we had (within the openSUSE ecosystem). > > you could have chosen tumbleweed. Not for my life. > >> And it has been there way longer than we expected. > > > > -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

1 year, 2 months

Re: Slowroll: package stats + thoughts

by Bernhard M. Wiedemann

On 17/05/2024 14.57, Richard Brown wrote: > On 2024-05-17 12:54, Bernhard M. Wiedemann wrote: > >> Maybe I should reduce the rate of updates for unreproducible packages... > > Wouldn't this be effectively conceding that Slowroll users will be more > vulnerable for those packages that are not reproducible? No, I would implement it as a factor on the delay and CVE-updates have a base-delay of 0. Though, it would mean, that users have to wait some days extra for other updates and bugfixes (that might bring new bugs, too). This is about approx 160 of 15401 packages. [1] > I'm also curious as to your opinion about whether using the longterm > kernel makes sense in the face of research like this from CIQ? > https://ciq.com/whitepaper/vendor-kernels-bugs-stability/ ? > > Looking at your numbers I'm finding myself worrying you're doing a ton > of really detailed work for less gains than we hoped when we first > talked about this concept There are many reasons to see things more positively: a) the article is about Redhat's 4.18 kernel, while kernel-longterm switched from 6.1.x to 6.6.x this year. 6.1 first appeared 2022-12-12 6.6 first appeared 2023-10-30 4.1 first appeared 2018-08-xx so we are much closer to master, which makes backports easier and more reliable. b) Also, this is not a vendor-kernel, but one with shared upstream long-term-maintenance. Including a public git tree. c) Additionally, just like in Tumbleweed, users can choose between kernel-default and kernel-longterm as they see fit. kernel-default remains the default. Ciao Bernhard M. [1] https://rb.zq1.de/compare.factory/build-compare-differed-builds.txt

6 months, 1 week

openSUSE Factory search results for query "Slowroll"