[06:20] <cpaelzer> bryce: nice to hear that so many things that we touched yesterday already migrated
[06:20] <cpaelzer> I've checked the new tests of the list you sent - half of them fail still
[06:20] <cpaelzer> the other half didn't run yet
[06:21] <cpaelzer> I'll take look later once all are complete if they have a single root cause we could address
[06:46] <mwhudson> good morning
[06:48] <JackFrost> Heya.
[08:20] <eoli3n> xnox: so there will be some default packages installed as snap packages in futur release ?
[08:21] <eoli3n> because i didn't explictly installed any snap packages, so i should not have any /snap dir, am i right ?
[08:23] <eoli3n> snapd is defaultly installed, i purged it
[08:34] <doko> ricab_: source-higlight uploaded
[08:39] <ricab_> doko: ?
[08:57] <doko> ricab_, no ricotz
[08:58] <ricab> right
[09:00] <ricotz> doko, thx
[09:02] <bdmurray> seb128: Do you have any plans for bug 1781597 as it is assigned to you?
[09:02] <ubottu> bug 1781597 in network-manager (Ubuntu Bionic) "[SRU] WoWLAN settings are not supported" [Wishlist,Triaged] https://launchpad.net/bugs/1781597
[11:17] <leaves> Hello, version 2.11.0~beta2-2 of my package opendkim is only now on its way into Debian testing. I see that the import freeze was end of February, does that mean my package has definitely missed the window to be in the LTS 20.04?
[11:29] <juliank> leaves: well it needs manual sync now, and possibly a feature freeze exception first
[11:31] <leaves> juliank: oh well. It was a bit of a milestone this version, but not that important at the end of the day. But thanks for the info.
[13:45] <xnox> sil2100:  do you know who can review template import https://translations.launchpad.net/ubuntu/focal/+source/subiquity/+imports ?
[13:45] <xnox> sil2100:  it should be imported into Template "subiquity" in Ubuntu Focal package "subiquity"
[13:45] <xnox> sil2100:  not sure why it's not done automatically
[13:46] <xnox> also not sure who uploaded that at 10am today
[13:48] <xnox> but also they are the same
[13:49] <xnox> vorlon:  did you upload subiquity.pot at 10:05am today?
[13:50] <xnox> oooooh
[13:50] <xnox> i think the imported one is by the build in focal-proposed
[13:50] <xnox> and the second one is from proposed-migration
[13:50]  * xnox ponders if we have tonnes of Needs Review template imports from all the package copies
[14:05] <rbasak> I've started tagging every bug that seems somehow entangled with the openssl 1.0/1.1/TLS 1.3 stuff in Bionci with bionic-openssl-1.1.
[14:05] <rbasak> ahasenack: ^
[14:05] <rbasak> Since there are so many of them now, I thought it better to draw a wider net so we can find them all again than worry about exactly what the tag means.
[14:06]  * ahasenack fetches 6
[14:06] <rbasak> I'm also including resolved bugs because they might still be helpful in analysis/retrospective.
[14:22] <xnox> rbasak:  i don't understand the meaning of the tag. is it about 1.1.0 or 1.1.1 series? for example why https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1794589 was tagged with that bug?
[14:22] <ubottu> Launchpad bug 1794589 in openssl1.0 (Ubuntu Bionic) "libssl1.0-dev conflicts libssl-dev" [Medium,Won't fix]
[14:22] <xnox> rbasak:  note that libssl1.0-dev has always conflicted with libssl-dev 1.1.x series (an in both 1.1.0 series and 1.1.1 series) and nothing was changed with the 1.1.1 sru
[14:23] <xnox> rbasak:  which series is the bug about? 1.0.2, 1.1.0, 1.1.1, or certain combinations?
[14:29] <ogra> sil2100, https://github.com/snapcore/pi-gadget/pull/33 (sorry for the many commits and reverts, i worked with a custoer on this and had to clean up the customer specific hacks to make it upstreamable)
[14:32] <rbasak> xnox: I'm using it to track every complication related to there being two OpenSSLs in Bionic.
[14:33] <rbasak> xnox: whether valid or not
[14:34] <xnox> rbasak:  makes sense! "whether valid or not" => chuckle
[14:34] <xnox> rbasak:  and like "whether it is actionable or not" i agree it is a bit of a mess for certain stacks, but equally not sure we can do anything about it. Apart from like backporting new nodejs 12
[14:34] <xnox> LTS
[14:35] <rbasak> not sure we can do anything> agreed
[14:36] <rbasak> My thought is that by having all possible relevant bugs tagged, if there is some pattern or action we decide later, we can check it for applicability. Or also avoid missing something when we're documenting or doing any kind of retrospective, etc.
[15:04] <bdmurray> marcustomlinson: What are you doing to bugs?
[15:04] <bdmurray> marcustomlinson: I'm not appreciating all the email / changes to apport bugs.
[15:10] <marcustomlinson> bdmurray: when you’re sitting on 1000 open bugs, is human triaging honestly possible anymore
[15:10] <marcustomlinson> I'm trying to do 2 things:
[15:10] <marcustomlinson> 1. reduce the backlog to something remotely manageable by humans.
[15:11] <marcustomlinson> 2. ping old bugs to allow those effected to respond and put their bug back on the radar.
[15:14] <bdmurray> marcustomlinson: you are making an assumption that things are fixed and from some of the bugs I've seen I know that are still not fixed
[15:15] <marcustomlinson> bdmurray: I'm not assuming anything, I'm asking
[15:15] <bdmurray> marcustomlinson: what set of criteria are you using to find bugs to ping?
[15:15] <marcustomlinson> before 16.04 existed
[15:17] <bdmurray> marcustomlinson: Bugs with status New and reported before April 2016?
[15:17] <marcustomlinson> before october 2015
[15:18] <bdmurray> and are you doing this for the whole distro?
[15:18] <marcustomlinson> no just the 4 worst here: https://docs.google.com/spreadsheets/d/e/2PACX-1vRDHPxGBHqM6XkT_S8ggtYfD0xchKSUD_z9PopNVE3G1rU05fVSnxDGcDsEstl7gu7N-tzCU6mLUp2V/pubchart?oid=254968654&format=interactive
[15:19] <bdmurray> How did apport end up on a desktop bugs list?
[15:20] <bdmurray> The desktop team isn't subscribed to that package.
[15:20] <marcustomlinson> that is a good question, and if that's the case, I'm very sorry
[15:20] <marcustomlinson> I didn't know I was overstepping my team's packages
[15:21] <bdmurray> If you could stop for apport that would be great and I'd reconsider changing a bug from Triaged to Incomplete.
[15:22] <marcustomlinson> bdmurray: yeah I've stopped
[15:22] <bdmurray> I can understand doing New but I think for Triaged bugs the burdern should be on us as developers not the reporter.
[15:23] <marcustomlinson> fair point
[15:58] <vorlon> xnox: I did not upload anything subiquity today, no
=== ben_r_ is now known as ben_r