[00:35] <Unit193> Howdy!  I heard there was a plan to deprecate/remove indicator-* stuff, is that accurate?
[07:25] <cpaelzer> rbasak: hiho, you added a delta to mediawiki for mysql8
[07:25] <cpaelzer> rbasak: it seems that Debian has accepted that in 1:1.31.5-1
[07:25] <cpaelzer> Could you check this and trigger a sync if you agree?
[07:25] <cpaelzer> that also would give us 3 upstream minor releases and a CVE fix
[07:26] <cpaelzer> I ran into that by checking postgres dependncies currently having issues, but since it is your delta I thought you might just give it a quick look and sync it
[07:28] <cpaelzer> oh wait IIRC you said you won't be around this morning right?
[07:28] <cpaelzer> I'll check and sync it if identical, but leave it to you if there are differences
[07:30] <cpaelzer> ok, changes are 100% identical - I'll call syncpackage
[10:31] <rafaeldtinoco> morning o/
[12:31] <LocutusOfBorg> doko, I opened another RC bug for the armhf build failure
[12:43] <doko> LocutusOfBorg: that's not because of different OpenGL/OpenGLes defaults?
=== ricab is now known as ricab|lunch
[13:06] <LocutusOfBorg> doko, it fails on Debian too
[13:07] <LocutusOfBorg> but aren't the defaults in sync with Debian now?
[13:07] <LocutusOfBorg> I see there is no qtbase delta anymore...
[13:07] <LocutusOfBorg> mitya57? ^^
[13:16] <LocutusOfBorg> paraview on armhf might fail differently in Debian, since it fails hours before the Ubuntu failure
[13:16] <LocutusOfBorg> meh
[13:23] <doko> may I remove paraview from -proposed for now?
[13:27] <LocutusOfBorg> for sure :D
[13:27] <LocutusOfBorg> double rc bug, if no rdepends, who cares
[13:27] <LocutusOfBorg> so I can see what else is missing for vtk and friends to migrate
[13:45] <ginggs> LocutusOfBorg: last paraview armhf attempt was a month ago, i gave it back now to see if anything changes
[13:52] <LocutusOfBorg> ginggs, problem is that we have to disable parallel building to avoid ENOMEM
[13:52] <LocutusOfBorg> but another machine might have more ram
[14:12] <ahasenack> rafaeldtinoco: do you still have the tags locally for https://code.launchpad.net/~ubuntu-server-ha/ubuntu/+source/resource-agents/+git/resource-agents/+merge/375322 ?
[14:12] <ahasenack> logical, split, etc?
[14:12] <ahasenack> if yes, can you push please?
[14:12] <rafaeldtinoco> sure
[14:13] <rafaeldtinoco> ahasenack: done
[14:13] <rafaeldtinoco> will do for crmsh also, forgot
=== ricab|lunch is now known as ricab
[14:20] <coreycb> infinity: xnox: some answers regarding openstack ussuri release alignment with focal. the reasoning for the change in release timing is simply based on the time between OSF summits. the timing was raised with the CEO, COO, and board, and they basically apologized, said that they hadn’t thought about the impact to distros.  They recognized that it is an important impact and they will coordinate and communicate
[14:20] <coreycb> better and with consideration in the future. but the ussuri release isn't changing at this point.
[14:23] <ahasenack> rafaeldtinoco: quick needs-fixing for resource-agents, at the beginning of the process, so it will affect the remaining commits, so I'll wait
[14:24] <rafaeldtinoco> ah u found it
[14:24] <rafaeldtinoco> ahasenack: i thought it had came from debian or something was wrong
[14:24] <rafaeldtinoco> let me fix it
[14:39] <ahasenack> rafaeldtinoco: let me know when pushed please
[14:51] <rafaeldtinoco> k, having a quick bite and will do right away
[15:15] <xnox> coreycb:  they made it 30 weeks long which is shooting themselves in the foot really
[15:23] <mitya57> LocutusOfBorg: not sure what you are asking me about. There is no major qtbase delta since Disco. Disco and Eoan had only some cherry-picks on top of Debian packaging.
[15:25] <coreycb> xnox: well, yes. I think it's unfortunate as well and I really hope it will be better aligned in the future. it sounds like it will be.
[15:27] <coreycb> xnox: for focal though we need to weigh whether the one month slip is a deal breaker or if we can work with it. the schedule for the current release isn't going to change.
[15:32] <xnox> coreycb:  we need to request them to change the schedule harder
[15:33] <xnox> coreycb:  and like have an earlier point release (do they do those?)
[15:34] <coreycb> xnox: we can snapshot releases at any point in time
[15:34] <coreycb> xnox: they only do point releases for stable support post-release
[15:38] <infinity> coreycb: I'd like to know what "coordinate [...] in future" is actually going to look like.  I'm okay with a 1-time "yeah, we can make this wonky schedule work, I guess", but I don't want it to become a habit.  If they can commit to their next cycle being short and getting back on cadence, then alright, they screwed up once, oh well.
[15:39] <infinity> coreycb: Also, the current cycle is still salvageable if they toss us a few bones via their own release policy.  Like, say, strongly discourage (or flat out disallow) changing of dependencies in components N weeks before release, for instance, as that's the most annoying change for distros to deal with post-release.
[15:40] <infinity> Code is just code, but changing the package selections on end-user machines is never pleasant (sometimes because they use tools wrong, eg "apt-get upgrade" versus "apt-get dist-upgrade", sometimes because certain deployment strategies are just flat-out paranoid about stuff like "why is a new package needed and suddenly you say this one isn't?)
[15:41] <infinity> "
[15:42] <coreycb> infinity: agreed I think we need to get a better idea of coordinate in future.. something we can hold them to
[15:43] <infinity> coreycb: I mean, a good start is knowing that for literally 15 (well, ish) years now, Fedora, Ubuntu, and GNOME have all managed to have a matching cadence (and some other projects tag along for fun).
[15:43] <infinity> They could just.... Do That. :P
[15:43] <coreycb> infinity: the dependencies are frozen 13 days prior to focal release so it would be bug fixes only beyond that
[15:43] <infinity> And we don't really coordinate that, we just know how to count to 6.
[15:44] <coreycb> infinity: hah
[15:44] <infinity> coreycb: Okay, if the deps are frozen before release *and* the dep-frozen RCs can all make it into release, I'm less wary of this plan.
[15:45] <LocutusOfBorg> mitya57, I remember some eglfs being enabled on arm64 or armhf or differently between debian and ubuntu
[15:45] <mitya57> It is not the case since Disco. And it was arm64, not armhf.
[15:45] <LocutusOfBorg> nice thanks
[15:46] <infinity> coreycb: There's nothing scarier to paranoid "but you said it was a *stable* release" users than an upgrade saying "You now need python3-soundsscary, and you no longer need python3-soundsimportant, press Y to break everything."
[15:46] <LocutusOfBorg> so, the failure should be reproducible in Debian too
[15:46] <coreycb> infinity: mostly it would be that way. the upstream rc1 deadline (core projects) is one day after focal release so we would plan to snapshot core projects as late as possible for focal, maybe a week prior to release to not disturb things release week.
[15:58] <infinity> coreycb: Alright, formally replied on-list.  Thanks for the back-and-forth.
[16:01] <coreycb> infinity: alright, thank you
[16:22] <infinity> ahasenack: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1851858
[16:22] <ubottu> Launchpad bug 1851858 in ubuntu-advantage-tools (Ubuntu) "adds ESM to sources.list.d unconditionally, despite it being x86-only" [Undecided,New]
[16:23] <infinity> ahasenack: I'll let you argue with the security/ESM team about who's at fault, but the situation is definitely broken.
[16:24] <ahasenack> hm, I didn't know esm was x86 only
[16:24] <sbeattie> ugh
[16:25] <teward> just to fact-check myself, when we say x86 we also include amd64 in that yes? (x86_64)
[16:25] <infinity> teward: Yes.
[16:25] <teward> good, the lack of coffee is making my brain fail :)
[16:25] <teward> thanks infinity
[16:26] <infinity> As noted in the bug, I'd prefer if it wasn't x86-only, but that's a policy change I'm probably not in a position to make.
[16:27] <tyhicks> infinity: it is *64-bit* x86 only: https://ubuntu.com/legal/ubuntu-advantage-service-description#uasd-subscription
[16:28] <infinity> tyhicks: The archive has binary-i386
[16:28] <infinity> tyhicks: So from the POV of this bug, it's x86-only.
[16:28] <infinity> tyhicks: https://esm.ubuntu.com/ubuntu/dists/trusty-infra-security/main/
[16:29] <tyhicks> hmm, I wonder if that's an artifact of the new trusty-infra-security
[16:30] <infinity> tyhicks: Nah, precise was both arches too.
[16:30] <infinity> tyhicks: It's probably just that IS filtered to those two arches (being the same two we publish on archive.u.c) and no one questioned them.
[16:30] <infinity> tyhicks: Since the PPA has all arches, and they had to pick a filter for the mirror.
[16:31] <mdeslaur> precise had both probably because precise builds the all arch on i386, no?
[16:31] <infinity> mdeslaur: That doesn't mean i386 would need to be mirrored.
[16:32] <mdeslaur> true
[16:32] <cjwatson> Also, that's true of trusty too
[16:32] <cjwatson> $ curl -s https://api.launchpad.net/devel/ubuntu/trusty | jq -r .nominatedarchindep_link
[16:32] <cjwatson> https://api.launchpad.net/devel/ubuntu/trusty/i386
[16:32] <infinity> Now, that said, there are other reasons you might want i386, like multiarch libraries.
[16:33] <cjwatson> (It changed with vivid)
[16:33] <infinity> Cause if you ESM a library that people have installed multi-arch, the version skew will tear it out if they can't get all arches.
[16:33] <mdeslaur> ah, that would be a good reason to have it :)
[16:34] <infinity> But that's also an argument for why we should publish all arches and just turn off !amd64 builds for packages we really don't want to support (the kernel?).
[16:34]  * infinity shrugs.
[16:34] <infinity> At any rate, the u-a-t bug is real and causing pain right now.  Any solution is better than none.
[16:37]  * genii runs a hose from the coffeepot to teward's desk
[16:38] <gQuigs> would anyone mind approving systemd in the upload queues (bionic/disco)?  got several customers who are looking forward to further testing when it hits -proposed  (https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd)
[17:03] <rbalint> gQuigs, it is more of an #ubuntu-release question
[17:04] <rbalint> gQuigs, try pinging SRU team members, the daily vanguards are listed at: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[17:09] <gQuigs> rbalint: thanks! will do