| === rfm_ is now known as rfm | ||
| === chris14_ is now known as chris14 | ||
| === chris14_ is now known as chris14 | ||
| nibbon_ | o/ | 09:26 |
|---|---|---|
| nibbon_ | does Ubuntu have a rolling release version? | 09:27 |
| ogra_ | nibbon_, yes, it is called UbuntuCore ... beyond this snap packages all are rolling on top of the underlying distro | 11:46 |
| ogra_ | (by design) | 11:46 |
| Quark | I thought Ubuntu Core was streamlined Linux for IoTs. | 12:30 |
| ogra_ | it is also used in industrial, automtive, robotics, digital signage, medical devices, clouds and even servers | 12:36 |
| Odd_Bloke | Yeah, Ubuntu Core is not what someone is looking for if they're asking that question in #ubuntu-server. | 12:36 |
| ogra_ | well, it is used on throusands of servers out there so i would not say that | 12:36 |
| Odd_Bloke | There is not a rolling release version of Ubuntu Server. | 12:36 |
| Quark | That's were I was getting. Closer you get is using dev channel. | 12:38 |
| ogra_ | well, ubuntu core isnt bound to anything like there are likely tons of ubuntu servers out there that have been created using debootstrap | 12:38 |
| ogra_ | would you say that these are also not "ubuntu servers" | 12:39 |
| Quark | s/were/where | 12:39 |
| Odd_Bloke | And besides that, base snaps are based on Ubuntu releases so they are not rolling. | 12:42 |
| ogra_ | they are definitely rolling within their base ... and you can also make the OS itself roll even the base sanps via remodelling | 12:43 |
| Odd_Bloke | You are describing updates, not a rolling release. All versions of Ubuntu support receiving updates. | 12:48 |
| ogra_ | well, whatever ... snaps and ubuntu core are currently the only rolling ubuntu you can get ... | 12:49 |
| Odd_Bloke | No, they aren't. You can't get rolling Ubuntu. | 12:49 |
| Odd_Bloke | Please stop misinforming people. | 12:50 |
| ogra_ | snaps are clearly rolling | 12:50 |
| ogra_ | and core is made of snaps ... | 12:50 |
| Odd_Bloke | No, they receive updates: that is not the same as a rolling release of a distribution. | 12:50 |
| ogra_ | geez | 12:51 |
| ogra_ | i have 80 snaps in the store 2/3 of them are constantly rolling upstream builds | 12:51 |
| Odd_Bloke | OK, and are any of those Ubuntu releases? Because that was the request. | 12:52 |
| ogra_ | they are being used on ubuntu servers/desktops or industrial devices ... on top of a rolling ubuntu core ... | 12:52 |
| Odd_Bloke | The closest you can get, which is _completely_ unsupported, is the `devel` release which is updated to point at the current devel release and therefore receives new packages as soon as they pass autopkgtests and migrate. | 12:52 |
| nibbon_ | ogra_ I must agree with Odd_Bloke; what he described is actually what I'm looking for | 13:10 |
| nibbon_ | Ubuntu core doesn't fit the bill, especially because I distribute the software with .deb still | 13:11 |
| nibbon_ | this bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1728616 doesn't look promising when it comes to the use of devel release :/ | 13:13 |
| -ubottu:#ubuntu-server- Launchpad bug 1728616 in apt (Ubuntu) "using 'devel' in sources.list causes apt-get update to fail" [Wishlist, Opinion] | 13:13 | |
| ogra_ | nibbon_, well, core is the compromise between what you get from arch as rolling release and what you get from ubuntu archive as stable release ... if you want *some* stability there has tio be a line, so i stand to my words here that ubuntu core is the only ubuntu rolling release today (at least if you want to use something in prod.) | 13:18 |
| nibbon_ | ogra_: do you confirm that Ubuntu core is snap only? | 13:19 |
| ogra_ | yes, it has to be since the rolling factor is implemented on a package level | 13:21 |
| Odd_Bloke | Again, a rolling Ubuntu release would involve getting new _distro_ packages on a rolling basis: Ubuntu Core has the same model as regular Ubuntu for distro packages, which is that you get a new set of them as a batch on a regular cadence (i.e. every two years there is a new coreNN snap). | 13:27 |
| ogra_ | you need to build against something to gain stability ... but what you build against doesnt tell anything about what you use for runtime or where you did build from (i.e. upstrems directly) ... i own snaps that build *everything* from source, even all libs and they are fully rolling | 13:29 |
| ogra_ | the design of snap packages has been made exactly for this from day one | 13:29 |
| ogra_ | all the core snaps give you is a stable/non-moving libc and nothing more | 13:31 |
| Odd_Bloke | I'm not sure why you keep talking about packaging individual pieces of software in the context of "a rolling Ubuntu release" which consists of many pieces of software. | 13:31 |
| Odd_Bloke | But I know that I'm going to stop talking about this now. :) | 13:32 |
| ogra_ | good 🙂 | 13:32 |
| ogra_ | i guess we simply just disagree what rolling means and i cant get you the concept across we designed when starting with snaps | 13:32 |
| Quark | I think ogra_ wants https://rhinolinux.org/. | 14:41 |
| Quark | Always charging forward with its magic horn. | 14:42 |
| ogra_ | Quark, not really 🙂 i like stable things | 14:42 |
| Quark | Ok then. | 14:42 |
| Quark | LOL. | 14:42 |
| nibbon_ | Quark: I looked at it, but it does sound like an Ubuntu derivative, no? | 14:43 |
| Quark | nibbon_: yes. | 14:43 |
| Quark | Based on Ubuntu. | 14:43 |
| ogra_ | it is what Odd_Bloke described above ... outcome of an old discussion on discourse.ubuntu.com | 14:43 |
| ogra_ | https://discourse.ubuntu.com/t/ubuntu-as-rolling-release/14751 | 14:44 |
| Odd_Bloke | Quark: Oh, I hadn't seen that before: TIL, thanks! | 14:44 |
| * Quark saves the link to the "Read later... maybe" directory. :-P | 14:44 | |
| ogra_ | (it is essentialyl just defaulting all your sources.list entries to the "devel" distro ... so it breaks in hilarious ways every time a new cycle starts) | 14:46 |
| Quark | Well, we would run Linux if we didn't like broken things every once and then. Hehehe. | 14:47 |
| nibbon_ | ogra_: that would work for me because I would derive a snapshot that undergo several testing before being declared prod ready | 15:08 |
| nibbon_ | but I could also follow release cycles although might be less convenient - works well with Debian testing and we would like to replicate the same approach with Ubuntu | 15:09 |
| ogra_ | well, ubuntu doesnt have that concept (experimental, unstable, testing, stable) so what you get is usually unstable quality, slowly stabilizing as the release nears | 15:12 |
| === chris14_ is now known as chris14 | ||
| JanC | nibbon_: I would say staying on the latest release early during a release cycle and then switching to the development version during the later part of a development cycle is less likely to break things than following devel all the time also | 15:33 |
| JanC | if you want to make your own "test distro" | 15:33 |
| nibbon_ | JanC: that sounds reasonable; is there an API/Web page I can call to see the release cycle(s)? | 15:35 |
| nibbon_ | s/see/track | 15:35 |
| JanC | every 6 months there is a release in late April (.04) & late October (.10) normally | 15:37 |
| JanC | e.g. not long after the release of 24.04 in April they will pull in lots of new stuff from Debian all at once, so the risk for breakage is relatively high then :) | 15:39 |
| ogra_ | every time a new cycle starts pretty much the whole of debian unstable is copied over, so if you want to switch you might want to wait til the initial breakage settled a bit | 15:39 |
| ogra_ | release cycle points are published on the release schedule on discourse.ubuntu.com | 15:40 |
| ogra_ | so you could i.e. wait til "debian import freeze" to not get all the inherited breakage | 15:40 |
| nibbon_ | so, let's say I'll start with Noble (24.04) I can switch to Devel after 6 months, which should bring me to October, then switch to Whateverisgonnabethenext, and so on | 15:41 |
| ogra_ | (and then slowly watch ubuntu stabilize) | 15:41 |
| JanC | if you wait 6 months you will get a new stable release :) | 15:41 |
| ogra_ | yeah 🙂 you'D get 24.10 | 15:41 |
| JanC | not an LTS release, but stable for as long as it lasts | 15:42 |
| JanC | if your software only targets LTS releases, that might also be an option, I guess... | 15:43 |
| ogra_ | here is a typical release schedule https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 | 15:43 |
| nibbon_ | fair enough, so probably I can wait 3 months before switching to Devel | 15:43 |
| nibbon_ | but wait for "debian import freeze" might work, too | 15:44 |
| JanC | after the import freeze updates to new versions would require special exceptions usually | 15:45 |
| nibbon_ | JanC: how do you mean? | 15:46 |
| JanC | after the "import freeze" developers need special permission to bring in new versions of software that aren't just bug fixes, so it's much less likely that things break after that date | 15:49 |
| JanC | https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649#planned-and-potentially-disruptive-archive-wide-activities-2 also lists when they expect breaking changes | 15:51 |
| nibbon_ | oic | 15:54 |
| nibbon_ | but if I switch to devel after the "debian import freeze" don't I take chances to pull random stuff coming from Debian (unstable/testing)? | 16:00 |
| JanC | after the freeze that would require a "import freeze exception", so would not really be "random" | 16:09 |
| JanC | they need the last 7 weeks or so of a cycle for making sure that what's already there works well together | 16:10 |
| nibbon_ | okay, I think I have enough information to build a strategy which requires tests and fine tuning | 16:20 |
| nibbon_ | thanks for the insightful conversation | 16:20 |
| MTecknology | I thought "ubuntu core" was a random collection of scripts and obsolete tech ... | 16:35 |
| MTecknology | (dumped into a snap container) | 16:37 |
| MTecknology | (obsolete --> pam_tally2) | 16:40 |
| Odd_Bloke | On the above discussion, it's worth noting that Debian packages are copied and built into devel-proposed, and they won't migrate to devel if they are breaking any reverse dependencies' tests or causing installability issues. | 16:49 |
| MTecknology | basically like how debian unstable migrates to debian testing? | 16:57 |
| Odd_Bloke | I don't recall the criteria for testing migration, but it's along those lines, yeah. (One difference is that devel-proposed -> proposed doesn't have an aging period: ~no-one is running devel-proposed because it _is_ very broken all the time, so leaving it there wouldn't garner significant additional testing.) | 17:40 |
| === JanC_ is now known as JanC | ||
| MTecknology | ... heh?? | 20:58 |
| MTecknology | dbungert: Where does /swap.img come from?? | 20:58 |
| dbungert | curtin will create it if it thinks that makes sense. swap.img creation can be turned off if it not desired. https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html#action-based-configuration has a sample | 21:00 |
| MTecknology | oh ... I read in a couple places that swap: conflicted with manual layout options. I guess it's a separate thing entirely. | 21:02 |
| MTecknology | thanks again! | 21:02 |
| MTecknology | dbungert: ah, you mentioned "updates: all" will install regular updates in addition to security; but I don't see "updates" | 21:07 |
| * MTecknology sighs ... now I do | 21:08 | |
| dbungert | on the swap thing, it looks like this was fixed in Subiquity version 22.12.1 | 21:09 |
| dbungert | so yes, in older versions there was a conflict but that's fixed at this point | 21:09 |
| MTecknology | easy enough :) https://dpaste.com/7TT984XMH | 21:14 |
| MTecknology | I guess swapoff would also be wise, but it'll effectively happen at first reboot. | 21:14 |
| MTecknology | I guess technically second reboot, but first reboot after firstboot is executed | 21:15 |
| MTecknology | ah, rm failed without swapoff :P | 21:17 |
| MTecknology | dbungert: for what it's worth, network is a very serious problem here, so "update the installer snap" is not trivial; I would need to set up the mirror and ensure the mirror updates only within approved change control windows. Doing that for regular packages is enough of a headache ... that looks much more difficult with snaps. | 21:22 |
| MTecknology | OMG! I finally basically mostly almost have feature compatibility with debian! ... inside of a VM. Next up, on hardware. | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!