[06:59] <sahid> jamespage, coreycb: I'm currently rebasing horizon stein, but i can't remember how to refresh xstatic
[09:49] <enyc> LocutusOfBorg: I can confirm bionic-proposed  virtualbox 5.2.32  works at least as well as 5.2.18 was, for me!
[10:32] <enyc> LocutusOfBorg: i'm having weird lockups and radeon errors in dmesg  ... going to rty to get it all going on  intel-gpu  or difeent machine!
[11:48] <LocutusOfBorg> enyc, can you please update the bug report too?
[11:48] <LocutusOfBorg> thanks!
[12:29] <ahasenack> sil2100: hi, good morning/afternoon, could you give me some hint about what happened with this billeto run? https://bileto.ubuntu.com/excuses/3763/eoan.html
[12:29] <ahasenack> sil2100: I've been seeing these kind of results (still running, always failed) in all my eoan runs
[12:30] <ahasenack> I see it running for a while in that /running url, with logs and all, and then it just disappears, but the state in the eoan.html page isn't updated
[12:36] <coreycb> sahid: check out debian/README.source
[12:37] <sahid> coreycb: the problem is not about to build th tarbal it's about to include it
[12:38] <coreycb> sahid: you'll need to use debuild if you're not using it
[12:39] <sahid> i tried but that does not look to work, can you confirm the args i should pass to debuild?
[12:39] <sahid> coreycb: ^
[12:40] <coreycb> sahid: i use debuild -S -sa
[12:40] <coreycb> sahid: are both tarballs in the parent directory?
[12:43] <sahid> coreycb: yep both tarballs, orig.tar.gz and orig-xstatic.tar.gz
[12:43] <sahid> but pehrpas the problem is somewhere else
[12:44] <sahid> looks like there are diff related to local_seetings.py.example
[13:16] <sil2100> ahasenack: let me get back to you in a minute
[13:19] <ahasenack> sil2100: thanks
[13:50] <sil2100> ahasenack: ok, so all the logs for those runs were gone, so I couldn't really figure out what happened
[13:50] <sil2100> ahasenack: I re-set the QA field to trigger another britney run and now the updated results have been uploaded
[13:51] <sil2100> ahasenack: it's hard for me to figure out what happened - I can only assume that for some strange reason britney reported all test results as 'always failed', so bileto decided that it makes no sense to run britney on it ever again
[13:53] <sil2100> ahasenack: if you notice such situation ever again, please poke me - but if you want to get some test results in such a moment, you can try the 'workaround' of toggling the QA field to possibly tigger britney to run again
[13:53] <ahasenack> just a sec, otp
[13:54] <sil2100> Of couse best if you could just poke me, then maybe we can still get some logs from the britney run that considered the tests as always failing and, therefore, as passing validation
[13:54] <sil2100> But here this happened somewhere around the 26th
[13:54] <sil2100> We only keep logs like around 12h back or something?
[13:55] <ahasenack> back
[13:56] <ahasenack> sil2100: ok, I see passes now
[13:57] <ahasenack> weird, and it was super quick
[13:57] <ahasenack> sil2100: I'll to the qa flip trick if this happens again, and ping you as well
[13:57] <ahasenack> sil2100: thanks for the help!
[14:00] <rbasak> juliank: https://paste.ubuntu.com/p/jryp4CfNHs/ - "apt update" returns success even with no connectivity. Is this a bug?
[14:00] <sil2100> ahasenack: yeah, so what was happening that all the tests have started and finished in timely fashion, but since bileto saw britney at the first run reporting as all the tests as 'always failed', it switched the ticket's status to 'ADT passed' and not ran britney ever again for it
[14:01] <juliank> rbasak: it's a feature
[14:01] <sil2100> ahasenack: so the tests passed but a britney run was needed to actually update the results
[14:01] <ahasenack> sil2100: I see
[14:01] <rbasak> juliank: it means that if I do things in a fresh container too early (eg. adding -proposed), then apt update fails, the subsequent apt install loses the race and succeeds, and I get non-proposed packages installed.
[14:01] <rbasak> And upgrading up changes behaviour in my case because the upgrade path is different from the fresh install path :-/
[14:02] <juliank> rbasak: true, it's always been like this, because the idea was to not break scripts because of temporary failures
[14:02] <rbasak> :-(
[14:03] <rbasak> Those scripts should use ; and not && IMHO
[14:03] <rbasak> The script authors get to pick, but returning success means that I can't pick the latter :(
[14:03] <juliank> rbasak: I want to add two more error handling modes
[14:04] <juliank> So you can configure what causes a failure
[14:04] <rbasak> And then we can set Ubuntu to default to sensible behaviour? :-P
[14:04] <sil2100> Laney: hey! Would you be able to find some cycles this week to check out the SRU ADT messages MP? No hurry on that one, just a bit sad about not annoying people with ADT regression comments ;)
[14:04] <rbasak> Anyway, thank you for the explanation. I've registered my use case with you, and I'll leave the decisions to you :-)
[14:05] <juliank> rbasak: apt-gets behaviour won't change, but I gotta figure out stable CLI for the apt command
[14:05] <rbasak> juliank: that doesn't help with script users, who are not supposed to use apt directly!
[14:06] <rbasak> For apt, outside scripting, the exit value hardly matters anyway?
[14:06] <juliank> That's why I said I want to figure out stable CLI for them
[14:06] <juliank> So we can fully deprecate apt-*
[14:06] <rbasak> I see, OK
[14:07] <juliank> Probably not the best time to think about it now, as I just landed like 2 hours ago coming from Rio to Frankfurt ;)
[14:10] <rbasak> Put your laptop away then :-P
[14:11] <rbasak> BTW, would you like a bug for this?
[14:18] <juliank> rbasak: probably got a few bugs already (definitely in Debian)
[14:19] <juliank> rbasak: also typing on my phone in a train on flaky connection, not my laptop. Can't relax during train ride anyway
[14:19] <juliank> :D
[14:19] <rbasak> :)
[14:35] <ahasenack> tjaalton: hi, thoughts about sssd 2.2? They jumped from 1.16 to 2.0, 2.1 and now 2.2? is that experimental?
[14:48] <tjaalton> ahasenack: hi, shouldn't be too experimental now with the most obvious (packaging) bugs fixed
[14:48] <ahasenack> tjaalton: any idea why upstream was jumping versions like this?
[14:48] <tjaalton> 2.0 deprecated some features
[14:49] <ahasenack> and 2.1 -> 2.2? No 2.1 point releases that I can see
[14:49] <ahasenack> do you know if they have a concept of lts releases, and if 1.16 is one of those?
[14:49] <tjaalton> it was
[14:50] <tjaalton> i thinl
[14:50] <tjaalton> think
[14:50] <ahasenack> LTM
[14:51] <ahasenack> that's 1.13.x actually (long term maintenance)
[14:51] <ahasenack> for major version 2, they call it 2.x series, not even 2.1.x or 2.2.x, just 2.x
[14:51] <ahasenack> ok, I'll put it on my merge list
[15:00] <tjaalton> cool
[15:02] <rbasak> !dmb-ping
[15:15] <milloni> hi, is anyone here involved in work on security features?
[15:16] <milloni> https://wiki.ubuntu.com/Security/Features
[15:18] <nacc> milloni: not sure but you may want to try #ubuntu-hardened?
[15:18] <rbasak> milloni: try #ubuntu-hardened, but you should actually ask your question - people don't generally volunteer themselves for a mystery convesration
[15:18] <milloni> isn't ubuntu-hardened a separate project
[15:19] <milloni> rbasak: i know :) i didn't get an answer directly last time so i thought i would reach try to find people directly involved in that
[15:19] <rbasak> #ubuntu-hardened is the security channel of the Ubuntu project.
[15:19] <milloni> but if anyone here knows - my question is - is there a reason you're not using mcheck for heap hardening
[15:19] <rbasak> cpaelzer, rafaeldtinoco: #debian-mysql on OFTC for MySQL discussion
[15:19] <milloni> i'm eyeballing https://wiki.ubuntu.com/Security/Features#heap-protector
[15:20] <rbasak> Ask in #ubuntu-hardened please.
[15:20] <milloni> okay
[15:20] <milloni> thanks
[20:57] <mwhudson> good morning