[08:18] <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:19] <juliank> I need to write it
[08:19] <juliank> It was a huge issue past couple days with libssl
[08:22] <juliank> Oh my fix is incomplete
[08:22] <juliank> But it's going to suffice in practice
[08:23] <juliank> frickler: So essentially, I'll apply phasing only when doing the upgrade code paths, but not in general for install and stuff
[08:25] <frickler> juliank: that sounds like it may not be enough like in my systemd case above
[08:26] <frickler> ah, wait, I think I read that the wrong way around
[08:27] <frickler> so new installs will always get the most recent version, that sounds reasonable
[08:29] <juliank> it will force upgrades to not fully released versions which is meh
[08:29] <juliank> I really want things to be consistent
[08:32] <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:33] <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:34] <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:35] <juliank> The algorithm I had previously was incomplete, it only handled the latter case for the current launchpad setup
[08:36] <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:38] <juliank> If installed version >= latest available version without phasing -> allow more versions by ignoring phasing
[08:38] <juliank> might actually work
[08:39] <juliank> I need to write test cases
[08:40] <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:41] <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:42] <juliank> or I guess I should have a 1.3 that's phasing and a 1.2 other update that is still available
[09:12] <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:13] <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:14] <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:15] <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:16]  * schopin bookmarks this page.
[09:21] <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:22] <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:23] <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:24] <philroche> Ah. I was not aware of this
[09:30] <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:31] <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:32] <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:33] <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:34] <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:42] <philroche> Why a week only? I had in mind that we would include phased updates until the apt fixes were complete
[09:44] <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:45] <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:46] <philroche> 👍
[09:46] <juliank> it doesn't even affect kinetic because there's simply no phasing happening
[09:46] <juliank> * yet
[10:08] <LocutusOfBorg> schopin, I might have done also some test builds on s390x on my ppa btw
[10:09] <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:10] <schopin> Yeah, that's my plan, but I'll wait 'til I have some time to debug stuff if it fails :D
[10:31] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/24106365
[10:31] <LocutusOfBorg> schopin, ^^
[11:51] <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:52] <jbicha> or what if someone wants to install evolution & they don't have it installed currently. It is installable?
[11:53] <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:56] <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
[12:03] <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:04] <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:43] <LocutusOfBorg> schopin, and it failed
[12:47] <schopin> LocutusOfBorg: might it be because llvm-13 is only a B-D on [arm64 armel armhf]?
[12:51] <LocutusOfBorg> and here another with added llvm https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/24106681
[12:52] <schopin> I'm wondering why amd64 doesn't need llvm-13 to build the LLVM backend...
[13: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.
[14:03] <ginggs> seb128: bolt,fftw3,libsoup3 given back
[14:05] <seb128> ginggs, thanks!
[14:17] <rbasak> xnox: yeah that's probably it. Thanks!
[16:43] <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)
[18:55] <enr0n> Can a core dev please trigger the PPA autopkgtests listed here https://paste.ubuntu.com/p/fgtypGBt8k/
[18:55] <enr0n> TIA
[19:50] <ginggs> enr0n: doing...
[19:53] <enr0n> ginggs: thanks!
=== mmikowski_ is now known as mmikowski