| frickler | juliank: the phased update issue now has returned, current jammy cloud images are affected. what did become of your idea to fix apt? | 08:18 |
|---|---|---|
| frickler | https://paste.opendev.org/show/bHolx6HtT6RhR9A0Vrbv/ | 08:18 |
| juliank | we have a new approach | 08:18 |
| juliank | I need to write it | 08:19 |
| juliank | It was a huge issue past couple days with libssl | 08:19 |
| juliank | Oh my fix is incomplete | 08:22 |
| juliank | But it's going to suffice in practice | 08:22 |
| juliank | frickler: So essentially, I'll apply phasing only when doing the upgrade code paths, but not in general for install and stuff | 08:23 |
| frickler | juliank: that sounds like it may not be enough like in my systemd case above | 08:25 |
| frickler | ah, wait, I think I read that the wrong way around | 08:26 |
| frickler | so new installs will always get the most recent version, that sounds reasonable | 08:27 |
| juliank | it will force upgrades to not fully released versions which is meh | 08:29 |
| juliank | I really want things to be consistent | 08:29 |
| frickler | well then we are back to having to teach chroot and other image creation tools to be smarter | 08:32 |
| juliank | APT will deal with those scenarios as well | 08:32 |
| juliank | But that requires launchpad changes first | 08:32 |
| juliank | Essentially if all available versions > installed versioned are phasing, phasing is ignored | 08:33 |
| juliank | so if you have x=1.2 installed, and want to install x-dev=1.6, it would upgrade you to x-dev=1.6 | 08:33 |
| juliank | it would actually upgrade you to x-dev=1.5 because it would still be kept around by launchpad, but you get the idea | 08:34 |
| juliank | well | 08:34 |
| juliank | apt install x-dev would install x-dev=1.5, upgrade x=1.5 | 08:34 |
| juliank | if you already had x=1.6 installed, it would install x-dev=1.6 | 08:34 |
| juliank | The algorithm I had previously was incomplete, it only handled the latter case for the current launchpad setup | 08:35 |
| juliank | because it said, you have x=1.6 installed, so x-dev=1.6 is allowed too | 08:36 |
| juliank | so when you had x=1.5 installed, it would not have allowed x-dev=1.5 | 08:36 |
| juliank | If installed version >= latest available version without phasing -> allow more versions by ignoring phasing | 08:38 |
| juliank | might actually work | 08:38 |
| juliank | I need to write test cases | 08:39 |
| juliank | I'm going to use 1, 1.1, and 1.2 as versions that are release pocket, previous update, and phasing update and then figure out the scenarios and after I have the tests just hack on the code until they work | 08:40 |
| juliank | I think that's the best approach rather than thinking about this first :D | 08:40 |
| juliank | I need to consider the cases where 1.1 is no longer available, and is still available | 08:41 |
| juliank | there are 3x2 cases I think {1 installed, 1.1 installed, 1.2 installed} x {1.1 still available, 1.1 no longer available} | 08:41 |
| juliank | or I guess I should have a 1.3 that's phasing and a 1.2 other update that is still available | 08:42 |
| philroche | juliank: Until this is in place, should disabling of phased updates in cloud images be discussed? | 09:12 |
| juliank | I think people upgrade those, so I don't think that's super helpful anyway | 09:12 |
| schopin | LocutusOfBorg: do you remember by any chance why you explicitly made GHC s390x builds "unregisterized"? The git logs don't tell me much... https://salsa.debian.org/haskell-team/DHG_packages/-/commit/2bc1dfc118c858269360c66f653e466efdf7864e | 09:13 |
| ubottu | Commit 2bc1dfc in haskell-team/DHG_packages "ghc: apply patch only on s390x architecture for now" | 09:13 |
| juliank | like if the image has a version 1.1 installed, you upgrade to 1.2, and then 1.3 is phasing, and you want to install a dev package, you end up in the same problem of it trying to install it from the release pocket (1) | 09:13 |
| juliank | Docker images would benefit more I'd assume as you don't upgrade those usually and come back weeks later and install something else | 09:14 |
| juliank | and you don't want to end up without bug fixes in the cloud images either | 09:15 |
| LocutusOfBorg | schopin, https://buildd.debian.org/status/logs.php?pkg=ghc&arch=s390x | 09:15 |
| LocutusOfBorg | 8.10.6-1~exp3 (experimental) Maybe-Successful 2021-08-26 19:22:17 zandonai 2h 34m 11.7 GB | 09:15 |
| LocutusOfBorg | 8.10.6-1~exp2 (experimental) Maybe-Failed 2021-08-25 05:36:29 zandonai 51m 1.96 GB | 09:15 |
| LocutusOfBorg | 8.10.6-1~exp1 (experimental) Maybe-Failed 2021-08-24 13:35:21 zandonai 51m | 09:15 |
| LocutusOfBorg | so I had to do that to fix the build I would say? | 09:15 |
| * schopin bookmarks this page. | 09:16 | |
| philroche | juliank: "I think people upgrade those" I understood they can only upgrade to what is available via phased updates? 1.2 installed 1.3 is phasing and I try upgrade I will likely not get 1.3 and will remain on 1.2 | 09:21 |
| juliank | philroche: well 1.2 got replaced by 1.3 in updates pocket, but it's still phasing, so you'd get 1 | 09:21 |
| juliank | philroche: but previously you got 1.2 when you updated because it was done phasing | 09:22 |
| juliank | this annoyance will be solved when launchpad preserves the previous update while the new one is phasing | 09:22 |
| juliank | allowing you to build images with 1.2, and people to install packages built from 1.2 | 09:22 |
| juliank | Essentially at the moment from apt's perspective, releasing 1.3 to updates (starting phasing) is equivalent to pulling the 1.2 update | 09:23 |
| juliank | because it disappears from Packages file | 09:23 |
| philroche | Ah. I was not aware of this | 09:24 |
| philroche | juliank: So in frickler's example https://paste.opendev.org/show/bHolx6HtT6RhR9A0Vrbv/ Are the solutions 1. disable phased updates 2. fix in apt 3. fix in launchpad so launchpad preserves the previous update while the new one is phasing ? | 09:30 |
| juliank | not entirely | 09:31 |
| juliank | 1. you set that always-include-phased-updates option, reverting apt to previous behavior | 09:31 |
| juliank | 2. there's a partial apt fix coming that solves this, but not upgrading and installing at the same time | 09:31 |
| juliank | 3. the fix for launchpad will not solve that instance, as presumably 3.2 would be in the archive, not 3.1; but with another change to apt it would then work | 09:32 |
| philroche | Sorry yes this is what I meant for 1. `echo "APT::Get::Always-Include-Phased-Updates \"true\";" | sudo tee --append /etc/apt/apt.conf.d/99-disable-phased-updates` | 09:33 |
| juliank | just don't call it disable-phased-updates :D | 09:34 |
| philroche | ack | 09:34 |
| juliank | like it's always-include not disable | 09:34 |
| juliank | but you don't really want to do that for a week of cloud images, that would be odd | 09:34 |
| philroche | Why a week only? I had in mind that we would include phased updates until the apt fixes were complete | 09:42 |
| juliank | Like if I SRU the change for 2 (the partial fix that fixes all practical problems as much as we can without launchpad) that takes a week to publish? | 09:44 |
| juliank | goal is to have an update out first week of July | 09:44 |
| philroche | ack. Good stuff | 09:45 |
| juliank | so in proposed by next monday :) | 09:45 |
| philroche | for all supported Ubuntu releases? | 09:45 |
| juliank | well it only affect impish+ | 09:45 |
| philroche | 👍 | 09:46 |
| juliank | it doesn't even affect kinetic because there's simply no phasing happening | 09:46 |
| juliank | * yet | 09:46 |
| LocutusOfBorg | schopin, I might have done also some test builds on s390x on my ppa btw | 10:08 |
| LocutusOfBorg | e.g. this one https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/22014936 | 10:09 |
| LocutusOfBorg | was good | 10:09 |
| LocutusOfBorg | you can try disable unregistered and upload in ppa? | 10:09 |
| schopin | Yeah, that's my plan, but I'll wait 'til I have some time to debug stuff if it fails :D | 10:10 |
| LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/24106365 | 10:31 |
| LocutusOfBorg | schopin, ^^ | 10:31 |
| jbicha | juliank: I'm concerned about how phased-updates handles multiple source packages that depend on each other. For instance, every new version of evolution depends on the new version of evolution-data-server | 11:51 |
| jbicha | if evolution is phased first, what is the user experience? is it an uninstallable upgrade? | 11:51 |
| jbicha | or what if someone wants to install evolution & they don't have it installed currently. It is installable? | 11:52 |
| jbicha | I've usually sidestepped this issue by just updating the dependency first (wait for e-d-s to fully phase before letting evolution in to jammy-updates) | 11:53 |
| jbicha | https://launchpad.net/ubuntu/+source/mutter/42.1-0ubuntu1 was fun because it added Breaks so I definitely wanted to make sure gtk3 & gtk4 were fully phased first, to be safe | 11:56 |
| juliank | jbicha: we know, the phased update groups proposal do conflict a bit with the other fixes I'm not sure how to tie that all together. | 12:03 |
| seb128 | ginggs, hey, could you retry bolt/kinetic/armhf on that recent archive rebuild? the build log suggests a connectivity issue to the archive | 12:03 |
| jbicha | juliank: that's fine. Do you want me to file issues for these test case ideas somewhere? | 12:04 |
| seb128 | ginggs, and fftw3/ppc64el, it's the dh_strip call which fails and I wonder if a retry would work | 12:04 |
| seb128 | ginggs, and libsoup3/amd64 | 12:04 |
| LocutusOfBorg | schopin, and it failed | 12:43 |
| schopin | LocutusOfBorg: might it be because llvm-13 is only a B-D on [arm64 armel armhf]? | 12:47 |
| LocutusOfBorg | and here another with added llvm https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/24106681 | 12:51 |
| schopin | I'm wondering why amd64 doesn't need llvm-13 to build the LLVM backend... | 12:52 |
| xnox | rbasak: i've set it to canonical-foundations now. i think it is probably because i registered repo & then renamed it to ubuntu-core-dev owner and it inherited me as reviewer. I don't recall ever explicitely setting it to myself. Even when I took over systemd maintainance from pitti. | 13:52 |
| ginggs | seb128: bolt,fftw3,libsoup3 given back | 14:03 |
| seb128 | ginggs, thanks! | 14:05 |
| rbasak | xnox: yeah that's probably it. Thanks! | 14:17 |
| LocutusOfBorg | schopin, and failed again | 16:43 |
| LocutusOfBorg | but really really after | 16:43 |
| LocutusOfBorg | make[3]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Paths_haddock.dyn_o] Illegal instruction (core dumped) | 16:43 |
| enr0n | Can a core dev please trigger the PPA autopkgtests listed here https://paste.ubuntu.com/p/fgtypGBt8k/ | 18:55 |
| enr0n | TIA | 18:55 |
| ginggs | enr0n: doing... | 19:50 |
| enr0n | ginggs: thanks! | 19:53 |
| === mmikowski_ is now known as mmikowski | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!