[09:04] <LocutusOfBorg> tjaalton, intel-media-driver-non-free intel-media-driver intel-gmmlib sync post eoan?
[09:05] <LocutusOfBorg> I'm trying to figure out if the delta can be dropped or not, just as a learning opportunity :)
[09:10] <tjaalton> LocutusOfBorg: there's no real delta, so yes
[09:30] <LocutusOfBorg> thanks for confirming, I don't know if they can be syncd before release or not...
[09:30] <LocutusOfBorg> they look like seeded...
[09:30] <LocutusOfBorg> so no
[09:30] <LocutusOfBorg> :D
[09:33] <Unit193> Maybe for Feisty Fawn.
[09:43] <cjwatson> Fawning Fist
[09:43] <cjwatson> Maybe not
[09:45] <Unit193> Flailing Falcon.
[09:45] <RikMills> Flacid Frog
[09:52] <mwhudson> farty fruitbat
[09:53] <LocutusOfBorg> Millenium Falcon :/
[09:53] <LocutusOfBorg> oops
[10:25] <tarzeau> Faboulous Ferryman
[12:01] <cpaelzer> rbasak: ahasenack: good news for haproxy and openssl
[12:02] <cpaelzer> there is a patch that works to gain back control of the key size
[12:02] <rbasak> o/
[12:02] <rbasak> \o/
[12:02] <cpaelzer> needs a while to tickle through upstream for sure, but I confirmed it working in an experimental build
[12:48] <rbasak> ddstreet: how is progress on bug 1847242? Would it be worth releasing this at the same time as your previous autopkgtest SRU, or do you really want to release the current one first?
[12:50] <ddstreet> rbasak i can roll that in and reupload if you'd like
[12:52] <ddstreet> it's hardly the only flaky/failing autopkgtest for systemd on xenial (or other releases) though - i'm working from the top down (upstream, debian, then ubuntu) on correcting all that, so xenial was basically at the bottom of my list
[12:53] <ddstreet> ah sorry this is for autopkgtest itself
[12:53] <rbasak> Yeah
[12:54] <rbasak> Also I just noticed that vorlon marked it block-proposed-disco when he accepted the Disco upload, but sil2100 perhaps didn't notice that when accepting Xenial and Bionic?
[12:54] <rbasak> AFAICT, there is no reason for the status to be different.
[12:54] <rbasak> So perhaps we should mark it to hold for all three.
[12:54] <rbasak> Also I need to document what that tag means.
[12:55] <ddstreet> yeah, it's actually *more* of a problem in disco, since people get the lxd snap there (which has the new behavior causing failure), while on bionic most people probably have the lxd deb, which is an older version and doesn't cause the failure (yet)
[12:59] <ddstreet> rbasak so i have the patch ready in my git and i can upload it for x now, but the new upload will have only the test fix (plus the fix that's in -proposed)
[13:00] <ddstreet> doesn't matter to me either way really, if we wait then i'll include the test fix in my next autopkgtest upload to x whenever that might be
[13:07] <rbasak> ddstreet: "...but the new upload will have only" -> why do you say "but"? Isn't that a good thing?
[13:07] <rbasak> Though
[13:07] <ddstreet> rbasak i just mean the new upload will only fix an autopkgtest; it won't include any new actual bug fix
[13:08] <rbasak> Perhaps it would be better if I didn't make any decisions here, actually, as I'd be the third SRU team member touching it and maybe that would just confuse things.
[13:08] <rbasak> ddstreet: understood, thanks.
[13:09] <rbasak> I think it makes sense for you to upload, for use to add block-proposed-<series> for all outstanding stable series for that bug.
[13:09] <rbasak> However let's wait for vorlon or sil2100 to confirm.
[13:09] <rbasak> for *you
[13:09] <rbasak> or maybe I meant us
[13:09] <rbasak> Anyway, I hope that makes sense
[13:24] <sil2100> rbasak: so I only accepted it into -proposed for bionic and xenial, I saw no reason for why not to include there with the block-proposed tag
[13:24] <sil2100> rbasak: ah, right, but we switched to using per-series ones only afterwards
[13:25] <sil2100> So the only thing I missed was actually switching the tags, yes
[13:42] <rbasak> sil2100: thanks. So let's re-add those and get ddstreet to upload his next branch on top now then?
[13:46] <sil2100> Yes, added those
[13:47] <Laney> cyphermox: ahoy, I just bounced you an update translation tarball for ubiquity - could you integrate it quickly please?
[13:47] <Laney> none of us here know how to do that /o\
[13:47] <Laney> and we're planning an upload
[13:47] <cyphermox> yup yup
[13:47] <cyphermox> sil2100 just pinged me about it
[13:48] <cyphermox> I was just wondering how come I had mail addressed to you
[13:48] <cyphermox> tbh, it's nothing more than dropping the files on top of the existing ones, and renaming appropriately
[13:51] <cyphermox> should I look for a newly translated string in particular?
[13:52] <sil2100> cyphermox: not sure, I think the ZFS ones might have been additionally translated, but we just wanted to refresh the translations anyway since we're uploading a new ubiquity
[13:53] <cyphermox> at least _Skip is translated in fr.po now
[14:00] <sil2100> cyphermox: \o/
[14:00] <cyphermox> updated.
[14:00] <cyphermox> should I upload too?
[14:00] <sil2100> cyphermox: yes please
[14:00] <cyphermox> ack
[14:19] <rbasak> rafaeldtinoco: reviewing your simplestreams Xenial SRU, I'm not sure I follow why an SRU is necessary for about half of these bugs - relating to v3 support
[14:20] <rbasak> I'm not aware that we usually backport new features to old LTSes due to new features/deprecations in future OpenStack releases - that's what I thought the cloud archive was for.
[14:20] <rbasak> Am I wrong, or is this case exceptional somehow?
[14:20] <rafaeldtinoco> rbasak: it was a seg request
[14:21] <rafaeldtinoco> because of a charm
[14:21] <rafaeldtinoco> let me open the lps
[14:21] <rbasak> So a statement like "The OpenStack Keystone charm supports v3 only since Queens and later" doesn't help me - why doesn't the charm support the older version?
[14:21] <rafaeldtinoco> ok.. so, with xenial, the keystone charm has to use simplestreams from a ppa in order to make it work whenever updating openstack
[14:22] <rafaeldtinoco> the upgrade procedure needs v3 support for not to brake
[14:22] <rafaeldtinoco> because of the ordering (services)
[14:22] <rafaeldtinoco> but i must confess Im relying mostly on freyes feedback
[14:22] <rafaeldtinoco> freyes: ^ do you have something else to add for rbasak  ?
[14:23] <freyes> rbasak, >=Queens OpenStack dropped support for Keystone v2
[14:23] <rbasak> freyes: and the cloud archive provides Queens against Xenial as a backport, correct?
[14:24] <freyes> rbasak, correct
[14:24] <rbasak> OK, so shouldn't this simplestreams v3 support to into the cloud archive, and not the Ubuntu Xenial archive, to solve that problem?
[14:24] <rbasak> go
[14:26] <freyes> rbasak, the cloud archive doesn't carry the simplestreams package, and if there is an intention to do it for newer releases it won't help with this bug
[14:27] <rbasak> I don't think that "doesn't carry the simplestreams package" automatically means that an SRU is justified, though the SRU team might conclude that it's OK if no other solution makes sense.
[14:28] <rbasak> But I don't understand why the package couldn't just be added to the cloud archive
[14:28] <rbasak> Just because it's not there right now doesn't mean it can't be added right now.
[14:28] <rbasak> It'd bump users up, but that's what you'd be doing with the SRU anyway.
[14:31] <freyes> another reason why we may want to fix the package in distro is because simplestreams being a client, it could be that someone just wants to talk to a cloud that runs keystone v3, so in the case you propose, they would need to add a cloud archive repo (pulling a lot of new packages)
[14:31] <freyes> I see pros and cons on both ways
[14:31] <rbasak> That's the same situation for any network protocol client in Xenial though, OpenStack or not.
[14:32] <rafaeldtinoco> a question that triggers me is..
[14:32] <rafaeldtinoco> instead of a SRU to cloud archive
[14:32] <rbasak> We expect such clients to use a newer release, or a snap, or some backport PPA, etc.
[14:32] <rafaeldtinoco> we would have to have the backport instead
[14:32] <rafaeldtinoco> so there is a 1:1 relation with newer fixes
[14:32] <rbasak> (or run in a container of a newer release; the list goes on)
[14:33] <freyes> rbasak, true, disregard my last thought
[14:33] <rbasak> rafaeldtinoco: yes - that's a decision for the cloud archive maintainers, but I agree that a backport would make more sense.
[14:33] <rbasak> However, the downside is that it's quite late to be doing such a backport - it might be more than you want to bump existing stable users (same concern as an SRU backport).
[14:34] <rafaeldtinoco> jamespage: ^ can we have simplestreams included in cloud-archive ? this way the following SRU is not needed and, instead, the resolution would be to add the cloud-archive in order for xenial glance (>= queens) to support keystone v3 ?
[14:35] <rafaeldtinoco> i would document that in all those LPs and end user would have a place where to look if ever facing this need.
[14:35] <freyes> it would be add the simplestreams in bionic to the xenial-queens archive
[14:36] <jamespage> simplestreams in bionic does not work with keystone in bionic outside of any charm context due to the drop of the v2 API at queens release, which is what's in bionic
[14:36] <jamespage> tl;dr its broken in distro
[14:37] <jamespage> rafaeldtinoco, rbasak: ^^
[14:39] <rbasak> jamespage: that might just mean that we need to fix Bionic in an SRU first though - I don't think it affects my proposal for a resolution in Xenial?
[14:39] <rafaeldtinoco> fixing simplestreams in Bionic and having it available in cloud-archive for xenial (this is current suggest, right ?)
[14:40] <rbasak> That's what I'm suggesting, yes
[14:40] <jamespage> oh right - sorry i missed that context - yeah fix it in bionic, and we will include it in the UCA for xenial/queens
[14:40] <rafaeldtinoco> good.
[14:40]  * jamespage needs new glasses (or new eyes)
[14:40] <rafaeldtinoco> freyes: i can backport same patches to bionic and have u reviewing them if you're ok
[14:40] <freyes> rafaeldtinoco, I'm cool with that ;-)
[14:40] <rafaeldtinoco> and then we ask jamespage (tks) to include it in cloud-archive
[14:40] <rbasak> OK, thanks!
[14:40] <rafaeldtinoco> tku all!
[14:41] <freyes> rafaeldtinoco, appreciated for chasing this
[16:03] <rbasak> xnox: are you aware of bug 1846787, and do you have any opinion on this one please? I'm thinking that your review would be better than mine on this one.
[18:28] <Pharaoh_Atem> cyphermox: can you please take a look at this for xenial? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1824245
[18:29] <Pharaoh_Atem> I've included an updated patch for the ubuntu grub2 packaging following what cjwatson asked me a month ago...
[18:36] <cyphermox> Pharaoh_Atem: as soon as I have a bit of time to context switch back to grub2, I will
[18:44] <Pharaoh_Atem> cyphermox: any idea when that will be?
[19:34] <cyphermox> sorry, not really. for now I really need to focus on netplan
[19:34] <cyphermox> there is another SRU to land for xenial, so once I hear from it I'll try to make sure this patch lands alongside it
[20:06] <tomreyn> did something change about which crashes whoopsie on 18.04 would (not) report, or which of them are shown at https://errors.ubuntu.com/user/$(sudo cat /var/lib/whoopsie/whoopsie-id) ?
[20:07] <tomreyn> the last report i see listed for this desktop system is from august, but i have certainly subbmitted additional crash reports since.
[20:08] <tomreyn> s/august/july/
[20:10] <tomreyn> anyone running 18.04 lts, that is
[20:11] <tomreyn> scratch (just) the last line, i meant to post this to #ubuntu-discuss
[22:32] <popey> from an enthusiastic user who just installed 19.10...
[22:32] <popey> "Tell everyone they are doing amazing work with this release and it's highly appreciated"
[22:32] <popey> Just thought I'd pass that on.
[22:37] <Unit193> I shift in the shadows, poking at the things most people don't care about.  It's not meeeeee. :3
[23:06] <infinity> popey: It's not the guy who emails us every time he downloads a new ISO, is it?
[23:52] <popey> No :)