Search results for

[opensuse-factory] Tumbleweed snapshot question

by Roger Oberholtzer

I have been using Tumbleweed on a couple of machines, and it is working great. I like having a machine that is rather current. I am wondering about the best strategy to keep Tumbleweed up-to-date. When we get the automated e-mail that there is a new snapshot, a new ISO is also created. Obviously, a fresh install will have the packages as described in the e-mail. All packages in the ISO pass QA. This is fine for a new Tumbleweed install. On an existing Tumbleweed, if I do a zypper dup, isn't it the case that I would get the packages described in the latest e-mail about a snapshot - as well as any packages that have been updated and are perhaps destined for the next snapshot. That is, a zypper dup is not limited to the packages in the last Tumbleweed snapshot that have passed QA. These Tumbleweed packages that have been published in OBS may not pass an eventual Tumbleweed snapshot QA to be in the snapshot, right? So I could possibly install a Tumbleweed package that is in OBS that will fail Tumbleweed QA? It won't be in the snapshot, but it may be in OBS. If this is the case, what would be the best way to keep Tumbleweed up-to-date without the risk of installing these OBS packages with an unknown QA status? Am I making sense? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 3 months

[opensuse-factory] RFC: How to report issues after "New Tumbleweed snapshot <date> released"

by Johannes Meixner

Hello, I noticed that issues with a particular Tumbleweed snapshot are sometimes/often? reported as replies to the "New Tumbleweed snapshot <date> released" announcement. I would like to suggest to report issues with a particular Tumbleweed snapshot as new separated mails with individual meaningful mail subjects like "FooApp fails since Tumbleweed snapshot <date>" I think this way it is both clear to what Tumbleweed snapshot the issue report belongs and it is clear what the issue is about. Or is there a good reason why issues can/should? be reported as replies to the announcement mail? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 7 months

Re: [opensuse-factory] RFC: How to report issues after "New Tumbleweed snapshot <date> released"

by Michal Kubecek

On Tuesday 20 of October 2015 14:35:49 Johannes Meixner wrote: > > I noticed that issues with a particular Tumbleweed snapshot > are sometimes/often? reported as replies to the > "New Tumbleweed snapshot <date> released" announcement. > > I would like to suggest to report issues with a particular > Tumbleweed snapshot as new separated mails with individual > meaningful mail subjects like > "FooApp fails since Tumbleweed snapshot <date>" > > I think this way it is both clear to what Tumbleweed snapshot > the issue report belongs and it is clear what the issue is about. > > Or is there a good reason why issues can/should? be reported > as replies to the announcement mail? These are not exclusive: there is also the option to send a reply but change its subject. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 7 months

Re: Problems during first boot after upgrade [was: Re: New Tumbleweed snapshot 20201212 released!]

by Bjoern Voigt

Simon Lees wrote: > Unfortunately that is not the purpose of this list Sorry, but replying to the automated "New Tumbleweed snapshot" e-mails is a common practice in this list. Many users have done this too until now. And probably often users look into the "New Tumbleweed snapshot" e-mails and into the replies before or after updating their systems. I often found good information about problems and solutions for updating Tumbleweed. Bugzilla is also a good source of information, but it takes more time to find the relevant information about potential problems of a specific TW snapshot. I like the support mailing list, but sometimes users believe, that their problem is directly related to a specific TW snaptshot. Would it be Okay to reply to the "New Tumbleweed snapshot" e-mails with only support(a)lists.opensuse.org as recipient? Greetings, Björn

3 years, 5 months

[opensuse-factory] Announcing Tumbleweed Snapshots Official Hosting

by Jimmy Berry

See release-tools.opensuse.org post [1] for an HTML version. Tumbleweed Snapshots, fixed repositories containing previously released versions of Tumbleweed, are now officially hosted on download.opensuse.org [2]! For those not familiar with the Tumbleweed Snapshots concept please see the short introduction video [3] and the presentation I gave at oSC18 [4]. The overall concept is to allow Tumbleweed to be consumed as short-lived distributions that can be utilized after a new snapshot is published. The two primary benefits are not having to update just to install new packages and being able to sit on an older snapshot when avoiding problematic package updates. The latter working best with snapper rollbacks as it allows for normal system operation after rolling back. Given the proper method for updating between snapshots is `zypper dup` instead of `zypper up` which is normally reserved for updating between major releases of the distribution, like Leap, keeping the previous repositories and switching between them with the use of `dup` is quite natural. Given the latest snapshot is accessible and `zypper` operates normally there are no down-sides to this approach while providing some important advantages. If you have not already tried them I would encourage you to do so. Many users are already updating Tumbleweed once a week and thus perfectly align with the design of snapshots. The installation step and basic usage is documented in the `tumbleweed-cli` README [5]. No additional resources are utilized on the local machine. If for whatever reason you want to go back just run `tumbleweed uninit` to restore the default repository setup. If you are already using Tumbleweed Snapshots and would like to switch to the official hosting a migration command is provided in `tumbleweed-cli` `0.3.0` which will be included in Tumbleweed shortly [6]. As a side-note, bash completion is also provided! Once running version `0.3.0` (run `tumbleweed --version` to see which is installed), simply run `tumbleweed migrate`. Keep in mind the official hosting only provides `10` snapshots while my personal hosting on S3 provides `50`. The count will hopefully be increased in the future, but given how long it has taken to get this far it may be some time. Additionally, my AWS hosting has a CDN setup and will likely remain faster until mirrors decide to host the snapshots. Based on feedback and how things progress I will decide when to stop hosting on AWS, but it will be announced and the `tumbleweed-cli` will be changed to auto-migrate. For those interested, the difference in storage usage can be compared on metrics.opensuse.org [7]. - Official hosting [8] - Un-official hosting [9] Making Tumbleweed Snapshots the default is likely worth considering once everything settles and an appropriate level of adoption by mirrors is reached. It is encouraging to see the enthusiastic discussions about Tumbleweed Snapshots in IRC and e-mails. Enjoy! [1] http://release-tools.opensuse.org/2018/09/18/Tumbleweed-Snapshots-Official.… [2] http://download.opensuse.org/history/ [3] https://www.youtube.com/watch?v=CSXRreUjiIc [4] https://www.youtube.com/watch?v=CRszp1p47BM [5] https://github.com/boombatower/tumbleweed-cli [6] https://build.opensuse.org/request/show/636472 [7] https://metrics.opensuse.org [8] https://metrics.opensuse.org/d/osrt_history/osrt-history [9] https://metrics.opensuse.org/d/osrt_tumbleweed_snapshots/tumbleweed-snapsho… -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 years, 8 months

[opensuse-factory] Tumbleweed snapshot repositories prototype

by Jimmy Berry

About a month ago I sent out a proposal titled "Tumbleweed snapshot repositories" [1]. Since then I spent some time building a basic prototype that could use some interested folks to play around with it. For those not interested in reading my updates on the implementation and considerations the following are the relevant links. - https://github.com/boombatower/tumbleweed-cli/wiki/Installation-and-usage - https://github.com/boombatower/tumbleweed-cli - https://github.com/boombatower/tumbleweed-snapshot As of the time of this writing there are only two snapshots available. - 20161201 - 20161129 The snapshot script is set to automatically check for the publishing of a new snapshot and should create them automatically. Some open items from the proposal which have been decided in prototype are: - directory structure: placement of snapshot identifier in URL - location for code: modify OBS / kiwi, etc. - mirror load: concerns about extra size and load on mirrors The snapshot identifier is placed at the root level of the URL for a number of reasons. 1) does not require several URL patterns 2) works for all repo types 3) easily provides an entirely separate file tree for separate mirror network For example: /tumbleweed/repo/oss/ Becomes: /20161129/tumbleweed/repo/oss/ Given the different structures of the main openSUSE Tumbleweed product repo vs a home/devel repo structure this avoid unnecessary complications. /repositories/home:/boombatower:/snapshot/openSUSE_Tumbleweed/ Becomes: /20161129/repositories/home:/boombatower:/snapshot/openSUSE_Tumbleweed/ Instead of: /repositories/home:/boombatower:/snapshot/openSUSE_Tumbleweed/20161129/ /repositories/home:/boombatower:/snapshot/openSUSE_Tumbleweed_snapshot/ 20161129/ This structure also pairs well with the code strategy since it ended up making sense to keep the code out of the existing publishing workflows. As such the code does not have the context to understand the directory structure and it does not need to with this method. Since the snapshots are essentially backups of the published repositories it really does not make sense to mix into existing workflows. Additionally, in order to save space and implement the symlink strategy the script needs to compare the current snapshot against a previous snapshot which really does not fit in publishing workflow. As mentioned, there are concerns about mirror load in terms of the extra space required to store the snapshots. Given a separate and complete directory tree is available it can be sync'd using a completely separate rysnc module or similar. A stub is provided for the current snapshot which redirects to the standard mirror infrastructure to avoid serving the files directly. Once the snapshot is no longer current it automatically falls back to serving the snapshotted files. This approach achieves the design goals while utilizing the existing infrastructure. For example: - 20161201 is released and redirects to standard mirrors - 20161202 is released and redirects to standard mirrors - 20161201 serves snapshotted content The end user URLs can thus always include the snapshot identifier without suffering from reduced performance (aside from the redirect). The script looks at the openSUSE:Factory/snapshot repo for updates to the _product:openSUSE-release package [2]. Once detected the sync'd repo tree is snapshotted (against previous snapshot) and the new snapshot is redirect to the standard mirrors. By using this as the trigger the snapshot is triggered before the rsync tree is updated so the snapshot contains the newest published packages before the new snapshot was published. This strategy also works for devel/home repos which may begin rebuilding as a result of the new snapshot or updates from maintainers. The rsync tree is continually sync'd inbetween snapshotting to ensure the latest versions are available when the snapshot is triggered. Obviously, this process could run on the same infrastructure as OBS to avoid the need to sync the tree. Having the trigger work completely outside of OBS itself means that third-party repositories can also be snapshotted without those parties having to set things up. The Tumbleweed update repository is not snapshotted since it is intended to override snapshot packages. Obviously, in rare instances this could cause issues just as it can in normal operation. The update repo could be snapshotted and simply not utilized by default but available in the case users had issues and needed to utilize it. The secondary goal of "locking" the repository or indicating when a repo is in flux is not currently achieved for the latest repo, but obviously works naturally for the snapshot repos. Based on some of the ideas in the proposal and additional thinking I have done on the subject it seems achievable, but focusing on the basic snapshot functionality first seems prudent. A sidenote, the tumbleweed/iso/ directory is currently snapshotted as it can be handy to have older installation media for the times when they break. Given the limited resources of the server hosting the prototype I may disable it since it adds a couple tens of GB to each snapshot. For those interesting in experimenting inside a controlled environment I'd recommend a docker container. The official opensuse:tumbleweed images is infrequently updated and as such will typically require a sizable update to get into the neighborhood of recent snapshots. Alternatively, my boombatower/opensuse:tumbleweed is rebuilt once weekly and as such should provide a recent starting point. docker run -it boombatower/opensuse:tumbleweed /bin/bash Add --rm if you would like it to automatically disappear after exiting. I will be updating one of my machines using this prototype and should notice issues, but feel free to file issues on the github repos or respond to mail. [1] https://lists.opensuse.org/opensuse-factory/2016-10/msg00591.html [2] https://build.opensuse.org/package/binaries/openSUSE:Factory/ _product:openSUSE-release?repository=snapshot Have fun! -- Jimmy

7 years, 5 months

Re: [opensuse-factory] Re: Update Tumbleweed snapshot to pick up boost 5.8

by greg.freemyer＠gmail.com

On June 4, 2015 8:45:19 PM EDT, Jimmy Berry <jimmy(a)boombatower.com> wrote: >Based on that explanation I am confused how this situation could have >arose. As I understand it the following would have had to occur for >boost to be updated in tumblweed. > >- factory snapshot created >- automated tests run against factory snapshot >- tests passed and tumbleweed snapshot released > >As such how could the network repository be compiling against factory >snapshot that does not contain updated boost like tumbleweed? > ><path project="openSUSE:Factory" repository="snapshot"/> > >Either way, just looking to get this resolved. Also would it not make >more sense for the tumbleweed repository in network to actually build >against tumbleweed as seems to be the default configuration if >creating a new project. > ><repository name="openSUSE_Tumbleweed"> > <path project="openSUSE:Tumbleweed" repository="standard"/> > ... ></repository> Changing the "tumbleweed" repo in network to actually be the tumbleweed repo is the right thing to do. The tumbleweed repo only came to exist 6 or 7 months ago and not everything has been redirected to the relatively new tumbleweed repo yet. I don't have the credentials to do that. I suggest you open a new thread asking for that to be done. If you're subscribed to -buildservice that might be a more productive list for that request than -factory. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 11 months

Re: Announcement list for new TW snapshots?

by John Kizer

Manfred Hollstein wrote: > On Sun, 23 Jul 2023, 17:36:25 +0200, Pablo Sanchez wrote: > > Hi everyone, > > Perhaps my mailing list searching -fu is not up to snuff .. I'm searching > > for an announcement-only mailing list for new Tumbleweed snapshots. > > If no such list exists, can we create one? The list would only allow the > > following posts (from Dimstar .. :): > > > > New Tumbleweed snapshot ... > > Tumbleweed - Review of the week .. > > > > What do people think? > > +1 > > > > Pablo > > Cheers. > l8er > manfred May I suggest using RSS instead/in addition? Dimstar posts to the forums.opensuse.org Discourse server for each new snapshot, and a feed that effectively represents a "Tumbleweed snapshots" feed can therefore be obtained by using this RSS link: https://forums.opensuse.org/u/dimstar/activity.rss Just thinking that is an existing mechanism that doesn't require any more infrastructure work to be done?

10 months, 1 week

Announcement list for new TW snapshots?

by Pablo Sanchez

Hi everyone, Perhaps my mailing list searching -fu is not up to snuff .. I'm searching for an announcement-only mailing list for new Tumbleweed snapshots. If no such list exists, can we create one? The list would only allow the following posts (from Dimstar .. :): * New Tumbleweed snapshot ... * Tumbleweed - Review of the week .. What do people think? --- Pablo

10 months, 1 week

[opensuse-factory] Tumbleweed - Review of the week 2018/36

by Dominique Leuenberger / DimStar

Dear Tumbleweed users and hackers, This week was not a record when it comes to the number of snapshots, but there was a steady flow. There were just a couple days where none of the staging projects was in a state to be merged into Tumbleweed – which in turn means we also did not produce a new snapshot to throw at openQA daily. So, with this in mind, the three snapshots (0831, 0903 and 0905) released during this week is actually a good number. One snapshot (0904) was discarded. Changes that are in the delivered snapshots: * dbus 1.12.10 * ucode-intel 20180807a * hexchat2.14.2 * PHP 7.2.9 * Virtualbox 5.2.18 There are still a good number of interesting changes upcoming: * glibc 2.28; the split of libxcrypt causes some build failures * OpenSSL 1.1.1 * Boost 1.68 * python 3.7 * ncurses 6.1-20180707: breaks Xen (deprecations added, Xen builds with -Werror) * Usage of the new System Role selection instead of the legacy ‘desktop selection’ Cheers, Dominique PS: for the next two weeks, Max Lin will be taking care of Tumbleweed

5 years, 8 months

openSUSE Factory search results for query "New Tumbleweed snapshot"