[15:27] <slyon> \o
[15:28] <eslerm_> o/
[15:28] <slyon> c_paelzer is currently away (at the airport). He asked me to run the meeting today.
[15:29] <slyon> #startmeeting Weekly Main Inclusion Requests status
[15:29] <meetingology> Meeting started at 15:29:21 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:29] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:29] <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold c_paelzer jamespage eslerm
[15:30] <slyon> #topic current component mismatches
[15:30] <slyon> Mission: Identify required actions and spread the load among the teams
[15:30] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:30] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:30] <slyon> Let's start with -proposed (it's pretty crowded)
[15:30] <joalif> o/
[15:30] <eslerm_> good morning o/
[15:31] <slyon> devscripts: I created a draft MIR for libdigest-md5-file-perl to hand it out to the foundations team
[15:31] <jamespage> o/
[15:31] <sarnold> good morning
[15:31] <slyon> devscripts: libswitch-perl has been in main in the past
[15:31] <slyon> I wonder if we can just re-propote it? It's looking pretty healty from a quick sanity check
[15:31] <slyon> bug #785607
[15:31] -ubottu:#ubuntu-meeting- Bug 785607 in libswitch-perl (Ubuntu) "[MIR] new perl-modules recommendations" [Undecided, Fix Released] https://launchpad.net/bugs/785607
[15:32] <didrocks> hey
[15:32] <slyon> I guess this is a question for didrocks, jamespage or maybe sarnold if we did have some precendene on that in the past? (see my latest comment on that bug)
[15:32] <didrocks> so, in the past, that was a repromotion without question
[15:33] <didrocks> but now, we have stricter requirements
[15:33] <didrocks> in term of testing and so on
[15:33] <slyon> testing is covered for this one
[15:33] <didrocks> so, I would reask for a template + a full review if the package was promoted before those requirements
[15:33] <slyon> OK
[15:33] <didrocks> just for a sanity check
[15:33] <slyon> I will hand it out to the team then.
[15:33] <slyon> thanks
[15:33] <didrocks> yw
[15:33] <slyon> continuting with c-m-p
[15:33] <slyon> logcheck and the seeds are false-positives
[15:34] <slyon> libsub-quote-perl: I dropped that recommend an hour ago, so it should vanish from the report
[15:34] <sarnold> \o/
[15:34] <slyon> ceilometer: looking good, I think we can promote python-xmltodict. But we'll talk about that in our "updates" section
[15:35] <slyon> cups-browserd: boths deps pending security review
[15:35] <slyon> flashrom: I dropped the new libjaylink dependency/functionality (until somebody in Ubuntu actually wants to use it). So it should vanish, too
[15:36] <slyon> jaraco.text: this is with the openstack-team to fix things (cc jamespage)
[15:36] <slyon> netplan.io: mdurl & mardown-it-py are pending security review
[15:36] <jamespage> ack re jaraco.text
[15:36] <slyon> rich: this should be tagged for security review, too (cc sarnold, eslerm_) - see my latest comment on the bug
[15:37] <slyon> pkgconf: looking good, ready for promotion. I prepared a seed change eralier today, to switch pkg-config -> pkgconf. Pending review from my teammates
[15:37] <slyon> licensecheck: pending MIR by a collegue of mine
[15:37] <slyon> policykit-1: pending sec-review
[15:38] <slyon> for c-m: nothing new. libsub-quote-perl got resolved in -proposed as stated earlier
[15:38] <slyon> #topic New MIRs
[15:38] <slyon> Mission: ensure to assign all incoming reviews for fast processing
[15:38] <slyon> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[15:38] <didrocks> \o/
[15:38] <sarnold> slyon: we may have skipped non-proposed
[15:39] <slyon> Nothing \o/ (we might still have some work left from last week)
[15:39] <didrocks> (and yes)
[15:39] <slyon> sarnold: "for c-m: nothing new. libsub-quote-perl got resolved in -proposed as stated earlier" (see above)
[15:39] <sarnold> oh! I see it now
[15:39] <slyon> #topic Incomplete bugs / questions
[15:39] <slyon> Mission: Identify required actions and spread the load among the teams
[15:39] <slyon> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[15:39] <slyon> bug #2007279
[15:40] -ubottu:#ubuntu-meeting- Bug 2007279 in devscripts (Ubuntu) "[MIR] libdigest-md5-file-perl (dependency of devscripts)" [Undecided, Triaged] https://launchpad.net/bugs/2007279
[15:40] <slyon> (draft to be handed out to the foundations team to fill the template)
[15:40] <slyon> bug #2003083
[15:40] -ubottu:#ubuntu-meeting- Bug 2003083 in libstring-license-perl (Ubuntu) "[MIR] libstring-license-perl" [Undecided, Incomplete] https://launchpad.net/bugs/2003083
[15:40] <slyon> draft to be filled by the foundations team (tracking update)
[15:40] <slyon> bug #2002576
[15:40] -ubottu:#ubuntu-meeting- Bug 2002576 in python-xmltodict (Ubuntu) "[MIR] python-xmltodict" [Undecided, In Progress] https://launchpad.net/bugs/2002576
[15:40] <slyon> This got security ACK
[15:41] <slyon> and MIR ACK. it's being pulled in already by ceilometer
[15:41] <slyon> openstack team is subscribed
[15:41] <slyon> so I think it's ready for promotion
[15:41] <slyon> didrocks: could you handle this?
[15:41] <sarnold> ack
[15:41] <didrocks> sure
[15:41] <slyon> thx!
[15:41] <slyon> and that's all for recent updates
[15:42] <slyon> #topic MIR related Security Review Queue
[15:42] <slyon> Mission: Check on progress, do deadlines seem doable?
[15:42] <slyon> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[15:42] <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[15:42] <slyon> sarnold: how are things looking?
[15:42] <sarnold> mm, is log4cplus overlooked / neglected?
[15:43] <sarnold> https://bugs.launchpad.net/ubuntu/+source/log4cplus/+bug/2003549  -- currently unassigned, I'm wondering if this ought to be back on the server team
[15:43] -ubottu:#ubuntu-meeting- Launchpad bug 2003549 in log4cplus (Ubuntu) "[MIR] promote log4cplus to main as a isc-kea dependency" [Undecided, Incomplete]
[15:43] <slyon> log4cplus is older than last week's meeting.
[15:43] <slyon> (and pending input from the MIR reporter)
[15:43] <sarnold> athos: ^^ https://bugs.launchpad.net/ubuntu/+source/log4cplus/+bug/2003549
[15:43] <sarnold> there we go, now my conscience is clean :)
[15:44] <slyon> sarnold: nice. I've also assigned the bug accordingly
[15:44] <sarnold> so, security queue, I'm feeling good with our current position; this is the closest we've bbeen to getting things done before feature freeze, ever :)
[15:44] <slyon> that's very nice to hear. Kudos to the security team!
[15:44] <sarnold> there's enough on our plate that I don't think *everything* will be done before feature freeze, but it's hard to guess where exactly the misses might be :(
[15:44] <didrocks> yes, this is great to hear :)
[15:45] <sarnold> anyway, this feels good. thanks everyone for the help :)
[15:45] <slyon> could we get this into the security queue: https://bugs.launchpad.net/ubuntu/+source/rich/+bug/2003570 ?
[15:45] -ubottu:#ubuntu-meeting- Launchpad bug 2003570 in rich (Ubuntu) "[MIR] rich" [Undecided, New]
[15:45] <slyon> (still fine post-ff, but should be this cycle)
[15:45] <didrocks> sarnold: just be informed that I’m assigning the cups* transition to the security. I feel the first promotion to main were done before the MIR process was created. There are quite some gaps and some components are quite critical (running as root, setuid, parsing data format)
[15:46] <eslerm_> maybe, could you review SEC-1640 privately in JIRA?
[15:46] <didrocks> even if it’s monitored for CVE, I think it’s the right time for a re-review
[15:47] <sarnold> hmm, I wonder if we should re-poke upstream, how long ago was that?
[15:47] <eslerm_> almost a week now
[15:48] <eslerm_> I could assign CVEs and move on with review
[15:48] <eslerm_> pcs is taking my priority currently though
[15:48] <sarnold> didrocks: with a project that mature and (i'm guessing underresourced) it might be a challenge to get sweeping architectural changes of the sort that we'd expect from projects these days :( setuid executables parsing things isj ust a horrible feeling..
[15:49] <sarnold> I've gotten the impression completing the pcs stack is our top priority at the moment, I think that should continue
[15:49] <sarnold> but a quick re-poke of upstream is cheap enough / easy enough
[15:49] <eslerm_> can do
[15:49] <slyon> who will do that poking of upstream?
[15:49] <slyon> thank you!
[15:50] <slyon> #topic Any other business?
[15:50] <sarnold> rich https://warthogs.atlassian.net/browse/SEC-1694
[15:50] <sarnold> none here
[15:50] <slyon> sarnold: thanks!
[15:51] <didrocks> nothing here, thanks!
[15:51] <joalif> none
[15:51] <eslerm_> none either
[15:51] <slyon> alright folks, that's all for today :) o/
[15:51] <slyon> #endmeeting
[15:51] <meetingology> Meeting ended at 15:51:50 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-02-14-15.29.moin.txt
[15:51] <sarnold> thanks slyon, all :)
[15:51] <joalif> thanks slyon, all :)
[15:51] <didrocks> thanks
[15:52] <eslerm_> thanks slyon, bye all o/
[15:56] <athos> sarnold, slyon: I adressed the log4cplus required TODOs a week ago. I am waiting ofr a team review before uploading it (https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/log4cplus/+git/log4cplus/+merge/437047). In the mean time, we are addressing th kea TODOs
[15:56] <athos> sorry for the lack of communication in the bug though :) I linked the MP there
[15:59] <slyon> thanks for the update athos!
[15:59] <sarnold> athos: aha, good good :) I was afraid this fell through the cracks, but this sounds like happy progress noises :)
[16:00] <sarnold> oh wow, c++ symbol stuff, not the easiest to manage
[16:01] <athos> nah! We are almost done with the kea TODOs now as well. I will poke some teammates for reviews on the log4cplus one. We are uploading kea in debian today or tomorrow, then I will sync it (symbols file pending, those filters....)
[16:01] <sarnold> and nice tests, too :D
[16:02] <sarnold> oh sweet
[16:02] <sarnold> good luck, I hope it goes smoothly :)
[16:02] <athos> :)
[16:02] <athos> thx!
[16:14] <jbicha> slyon: is pkgconf ready for promotion from the MIR team side?
[16:15] <jbicha> oh sorry, I saw your comment on the bug
[16:35] <slyon> jbicha: yep. Needs a seed change (any maybe more?) feel free to give your review on the MR if you have any context
[16:39] <jbicha> slyon: Archive Admins expect the bug to be set to Fix Committed once the MIR team is done with their review
[16:40] <slyon> jbicha: well.. we usually do "In Progress" -> do seed/dependency change -> "Fix Committed" (https://github.com/canonical/ubuntu-mir#process-states)
[16:41] <slyon> but apparently it's better to do it the other way around in this case (see MR), and I just set it to fix committed
[16:41] <slyon> we should wait for it to migrate to lunar-release, tho
[16:41] <jbicha> I believe the seed change is done already; otherwise it wouldn't be on mismatches-proposed
[16:42] <slyon> I proposed it here, today: https://code.launchpad.net/~slyon/ubuntu-seeds/+git/platform/+merge/437267 (it's not yet merged)
[16:42] <slyon> maybe something else is pulling it in, too
[19:58]  * vorlon waves
[19:58] <amurray> o/
[20:00] <vorlon> so, wiki says rbasak is chair; but also he's declined this meeting as "out of office".  Not sure if that's just an autodecline and he plans to attend
[20:01] <vorlon> ummm also that invite hasn't been updated with current members of the TB?!
[20:01]  * amurray will have to leave early - in 30 mins - to drop kids at school early for sports training
[20:01] <amurray> oh
[20:01] <amurray> heh it might just be the two of us vorlon
[20:02] <seb128> hey
[20:02] <vorlon> also the wiki has the date wrong and says the meeting is on the 15th in UTC ;)
[20:02] <vorlon> seb128: hello!
[20:02] <amurray> oh hey seb128
[20:02] <vorlon> currently it's just the three of us
[20:03] <vorlon> per established practice, if rbasak isn't joining then it would be up to seb128 to chair
[20:04] <seb128> should we wait a bit more for others to maybe join or get started?
[20:04] <vorlon> 5 minutes after, if they were going to join they should be here by now
[20:04] <amurray> lets get started
[20:05] <seb128> alright
[20:06] <seb128> sorry I'm struggling with logs ... when was the previous meeting?
[20:07] <vorlon> Jan 24
[20:07] <seb128> I was checking for the log to get some guidance on the steps
[20:07] <vorlon> 3 weeks ago instead of 2, sorry
[20:07] <seb128> ah
[20:07] <seb128> right
[20:07] <seb128> #startmeeting Ubuntu Technical Board
[20:07] <meetingology> Meeting started at 20:07:46 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[20:07] <meetingology> Available commands: action, commands, idea, info, link, nick
[20:07] <seb128> #topic Apologies
[20:08] <vorlon> sil2100 and rbasak absent but I saw no apologies on the list
[20:08] <seb128> no email on the list that I can see
[20:09] <seb128> k, let's move on
[20:09] <seb128> #topic Action review
[20:09] <seb128> ACTION: amurray to propose amended Ubuntu Backporters Team Charter
[20:10] <seb128> there was some activity in https://lists.ubuntu.com/archives/technical-board/2023-February/002711.html
[20:10] <vorlon> I'm happy with what amurray has proposed, and persuaded by his arguments in response to Dan
[20:10] <amurray> so I am still discussing this with the backports team - waiting on a response
[20:10] <seb128> but no reply yet, it feels like that's not really actionable yet?
[20:10] <amurray> yep not actionable - lets defer
[20:10] <vorlon> but yes, agreed that at this point it's reasonable to wait for further input
[20:11] <amurray> i'll keep prodding it along in the meantime and hopefully will have something more specific to report back next meeting
[20:11] <seb128> ACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps
[20:12] <seb128> sorry, it's still on my list but I didn't get to it yet
[20:12] <seb128> ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
[20:12] <seb128> same, Lukasz isn't around, unless amurray made progress there I think we need to carry over to the next meeting
[20:12] <amurray> sorry I hadn't made any start on that either
[20:13] <seb128> ACTION: rbasak to raise any on-going blockers with third-party seeded snap security policy
[20:13] <seb128> that's a carry over as well
[20:13] <seb128> ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step
[20:14] <seb128> and that one
[20:14] <seb128> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[20:14] <seb128> and that one
[20:14] <seb128> ACTION: rbasak to create initial bugs against the LP techboard project to track third party repo and DMB expiration policies
[20:14] <seb128> and that one afaik...
[20:15] <seb128> ACTION: vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.
[20:15] <vorlon> I think I did this
[20:15] <seb128> and that one?
[20:15] <seb128> ah
[20:15] <vorlon> https://lists.ubuntu.com/archives/technical-board/2023-January/002709.html
[20:15] <seb128> ah, right
[20:15] <vorlon> and on the release team side I'm taking point to shepherd it and have some MPs in progress from Eickmeyer
[20:15] <amurray> lgtm
[20:16] <seb128> k, so we are waiting for Erich to follow up now
[20:17] <seb128> so do I need to tell the bot that this one is to remove?
[20:18] <Eickmeyer> Do you need me to send an email that it's "in progress"?
[20:18] <seb128> Eickmeyer, I don't think so, you altready said that in your reply
[20:18] <amurray> seb128: no the bot wont have recorded anything - you need to use the #action prefix to get it to do that afaik
[20:19] <Eickmeyer> 👍
[20:19] <vorlon> ^ right (wrt bot)
[20:19] <seb128> #action remove 'ACTION: vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.'  item as done now
[20:19] <meetingology> ACTION: remove 'ACTION: vorlon to reply to the Edubuntu ML thread with a description of what we need from Erich before we can proceed.'  item as done now
[20:20] <seb128> I will do that, sorry forgot to add my name
[20:20] <seb128> ACTION: sil2100 to follow up with the release team to establish consensus on Joshua's official flavour status for Cinammon.
[20:20] <seb128> does anyone know if Lukasz did that?
[20:20] <amurray> sorry no
[20:20] <ItzSwirlz> Sorry to jump in but release team responded and they approved of the seed
[20:20] <ItzSwirlz> (if that info helps you)
[20:22] <vorlon> yes, sil2100 did this
[20:22] <vorlon> MPs in progress there also
[20:22] <seb128> great
[20:23] <seb128> #action seb128 remove the item about the flavour status of cinammon
[20:23] <meetingology> ACTION: seb128 remove the item about the flavour status of cinammon
[20:24] <seb128> #topic mailing list archives
[20:24] <seb128> nothing new to discuss on the list I think
[20:25] <seb128> #topic Check up on community bugs (standing item)
[20:25] <seb128> nothing new here?
[20:26] <seb128> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
[20:26] <seb128> vorlon, can you do the next one?
[20:27] <vorlon> I can
[20:27] <vorlon> fwiw the historical practice has been to record a chair and a backup chair in the wiki page, and if the indicated chair is absent they continue to be the chair for the next meeting
[20:28] <vorlon> so you don't get out of being chair for a rotation by being absent ;)
[20:28] <vorlon> but we don't have to be bound by that convention
[20:28] <amurray> sounds like rbasak is still in the hot seat then ;)
[20:28] <rbasak-mobile> 👍
[20:28] <seb128> wfm, let's do rbasak-mobile and vorlon  as a backup
[20:28] <seb128> #topic AOB
[20:29] <seb128> any other topic?
[20:29] <vorlon> nothing from me
[20:29] <amurray> nothing from me
[20:29] <ItzSwirlz> I again apologize to jump in, but as I have to run in the next minute, if I may?
[20:29] <seb128> nor from me
[20:29] <seb128> ItzSwirlz, yes?
[20:29] <ItzSwirlz> If any action wants to be taken on UCR for flavor status I suggest it be done real quickly or over ML because feature freeze is next thursday. That's all
[20:30] <ItzSwirlz> I'm okay with more discussion on ML - that's it, hopefully 23.04 can be official so 24.04 can be an official lts
[20:30] <vorlon> fwiw feature freeze will not be a barrier for flavor inclusion in the release
[20:30] <ItzSwirlz> oh ok :D thanks
[20:30] <vorlon> you do have to make the beta however!
[20:30]  * ItzSwirlz puts it on the *later* list
[20:31] <ItzSwirlz> okay toodles!
[20:31] <seb128> anything else?
[20:32] <amurray> nothing from me (sorry I gotta run anyway but looks like we are about done) - thanks folks
[20:33] <vorlon> thanks all!
[20:33] <seb128> #endmeeting
[20:33] <meetingology> Meeting ended at 20:33:28 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-02-14-20.07.moin.txt
[20:33] <seb128> thanks!


[00:00] <Nafallo> Rinchen: I can see about 70 in my flat damnit :-P
[00:00] <beuno> bac, btw, your tweaks to the apache conf worked very well in accessing from other PCs on the network, thanks  :)
[00:00] <Rinchen> My favourite pastime at the office is turning on service discovery applet and looking at everyone's machines and devices.
[00:01] <Nafallo> and I can see the O2 wifi from the datacenter, and that's on the other side of the Thames :-P
[00:01] <Nafallo> Rinchen: wow. you must have a boring life :-)
[00:02] <Nafallo> my favorite pastime is drinking coke and talking with people :-)
[00:05] <Rinchen> Nafallo, well, no, but I do get a kick of trying to match machine names to individuals
[00:06] <wgrant> Ubiquity makes that easy.
[00:06] <Rinchen> there are some mighty interesting names out there
[00:06] <wgrant> Lots of people just accept the default machine names.
[00:06] <wgrant> I see that a lot at uni.
[00:07] <Nafallo> Rinchen: haven't matched mine yet, have you? ;-)
[00:09] <Rinchen> Nafallo, um yeah, that's how I knew who you were when you introduced yourself at dinner to me a few weeks ago ;-)
[00:12] <Nafallo> ehrm... based on my laptop's hostname? :-)
[00:12] <Nafallo> I'm not my laptop fwiw :-)
[03:09] <Hobbsee> so, we've got diffs between packages now.  When will we get diffs between what's in the queues, and the most recent package for that distroseries?
[03:46] <tlf1138> Can somebody give me some launchpad support?
[03:49] <Hobbsee> depends.
[03:49] <Hobbsee> !ask
[03:51] <tlf1138> I have a Lenovo X200 that I am trying to install Intrepid Ibex on. I have found some bugs, and for some reason my launchpad account does not work and I can't report them. Many of them are showstoppers for the X200, and some of them are show stoppers for the entire release.
[03:51] <wgrant> !doesn't work
[03:52] <spm> tlf1138: ie can you even browse to LP? have you tried various browsers? Does your user account "page" come up at all?
[03:52] <tlf1138> The time setting program in the installer reports the wrong time, the disk partitioner reports things that are not there, and the installation process frequently crashes.
[03:53] <wgrant> tlf1138: What's the problem with your Launchpad account?
[03:53] <tlf1138> I can't log in.
[03:53] <wgrant> With which message does it reject you?
[03:53] <tlf1138> No errors, just no way to log in. I consulted a buddy of mine who works for canonical and he said that this was a good place to ask about access.
[03:54] <Hobbsee> probably not on a weekend, it isn't, but yes ;)
[03:54] <wgrant> What do you mean "no way to log in"?
[03:54] <tlf1138> I simply get bounced back to the beginning screen.
[03:54] <wgrant> Ensure that you have cookies enabled.
[03:55] <tlf1138> I do cookies manually.
[03:55] <wgrant> Hm?
[03:55] <tlf1138> Lemme open another window and try to get in.
[03:57] <tlf1138> Okay.. it works now.... some cron job causing the delay? I dunno. thanks.
[03:57] <spm> tlf1138: there are no cron jobs delaying logins
[03:57] <tlf1138> Just guessing.
[03:57] <tlf1138> Thx.
[03:59] <spm> I did enjoy the call to irrelevant authority: "a buddy of mine... " Evil Chuckle. >:)
[04:00] <wgrant> Heh.
[04:41] <Hobbsee> hmmm.  in the advanced search, if you put in the wrong field,there's no indication at the top of the page that there was an error.
[04:42]  * Hobbsee argh!
[04:42]  * Hobbsee smashes launchpad bug searching with a brick.
[04:42] <Hobbsee> i need to file that bug, too.
[05:27] <wgrant> You know, I could really do with some extra PPAs for my user right now :(
[05:28] <wgrant> I hope they get to that feature soon.
[06:50] <lifeless> wgrant: just create a couple of groups
[06:52] <wgrant> lifeless: That seems to be the recommended solution until we have multiple archives, but that's ugly and a waste.
[06:53] <wgrant> I just cleared my PPA for this, and I'll put the old contents back later...
[11:36] <RainCT> Hi
[11:38] <RainCT> If someone is around, I've some questions about Launchpad's OpenID... First, why is the e-mail address send if it's requested from revu.ubuntuwire.com but not if it's requested from localhost (with exactly the same code)?
[11:43] <wgrant> RainCT: REVU was granted special privileges a couple of days ago.
[11:43] <bac> beuno: glad it worked.  we should document that...
[11:45] <RainCT> wgrant: ah, so only authorized hosts get additional data?
[11:45] <wgrant> RainCT: Yes.
[11:47] <RainCT> Well, and question two: is the e-mail address always send? (or, eg, isn't it if it's marked as private)
[15:17] <njpatel> need some help: how do I register a release with the new UI? Specifically I want to make tarballs available for download
[15:19] <njpatel> oh nvm, found it
[16:03] <_Andrew> What's the address to view the latest revision of a bzr repository? For example project/trunk/files/28?file_id=  If I update my code 28 won't be the latest revision so what do I put instead to ensure the link is always up to date
[16:11] <persia> _Andrew, revision -1
[16:13] <_Andrew> awesome, thanks
[16:15] <_Andrew> That's not working..
[16:15] <_Andrew> http://bazaar.launchpad.net/~hardwar/hardwar/trunk/files/28?file_id=trunk-20080128121747-hzzwhqny0rrrlrhe-1
[16:16] <_Andrew> How do I use -1 correct on this address?
[16:32] <persia> I'm not sure, but I'm guessing you replace the 28 with -1, rather than sticking it at the end.
[16:32]  * persia is suggesting -1 based on memories of past answers to questions, rather than real knowledge
[16:44] <_Andrew> oh
[16:46] <_Andrew> nevermind it's not that important
[16:55] <beuno> _Andrew, http://bazaar.launchpad.net/~hardwar/hardwar/trunk/files/head:?file_id=trunk-20080128121747-hzzwhqny0rrrlrhe-1
[16:55] <beuno> replace the revision number with head:
[16:57] <_Andrew> oh ok thanks
[17:36] <b24> hi, I want to help to translate. How can I find projects that need translation?
[17:40] <beuno> b24, https://translations.launchpad.net/ubuntu
[17:41] <b24> beuno: thanks :)
[17:42] <beuno> b24, enjoy!
[18:10] <logari81> yesterday "I" uploaded a virus as an attachment to a bug report. accordingly to this log:
[18:10] <logari81> https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/240615/+activity
[18:10] <logari81> offcourse it wasn't me
[18:12] <logari81> the attachment "unnamed" scaned by clamav gives the following:
[18:12] <logari81> unnamed: Worm.SomeFool.P FOUND
[18:13] <logari81> I am wondering how could that happen
[18:51] <nedko> i've got remote bzr repo locked, can someone help me?
[18:52] <LarstiQ> nedko: bzr break-lock <url/to/locked/branch>
[18:56] <nedko> that removed lock but now i'm at first step, bzr push freezing. Last time i pressed ctrl-c and got exception abd remote repo locked
[18:57] <nedko> nevermind, it was just *extremely* slow
[18:57] <nedko> repo with 10 revisions
[18:57] <nedko> argh :(
[20:29] <nedko> can i force rebuild of source package?
[22:07] <Flare183> How do I get help with a project?
[22:07] <beuno> Flare183, what's the problem?
[22:08] <Flare183> beuno: I need some help with developing/programming a project
[22:08] <Flare183> I can't do it all by myself
[22:09] <beuno> Flare183, ah, I see. This probably isn't the channel to ask then  :)
[22:10] <Flare183> beuno: Any suggestions on what channel I should ask in? I mean, this project is going to based on Ubuntu but will run on something else.
[22:10] <beuno> Flare183, I wouldn't know
[22:11] <Flare183> beuno: Oh ok, thanks anyway
[22:15] <mrooney> Does Launchpad Janitor work on non-Ubuntu projects? Specifically the (LP: #123456) syntax in bzr commit messages?
[22:15] <mrooney> Or, does it not actually work like that.
[22:15] <beuno> mrooney, you can set it per-project
[22:15] <beuno> if you want it to expire things or not
[22:18] <mrooney> beuno: okay, but I can't set it to parse commit messages of certain branches, to mark linked bugs fix committed, for example?
[22:19] <beuno> mrooney, no, we don't have that feature yet
[22:19] <wgrant> mrooney: You can commit with --fixes.
[22:19] <wgrant> That will link the branch to the bug.
[22:20] <wgrant> But it won't change the status, as that would probably be wrong.
[22:20] <mrooney> wgrant: ahh, so that's how you do that part of it
[22:20] <wgrant> Although it could be a bit more intelligent if it sees the fix in the trunk for a series.
[22:20] <mrooney> Okay so the launchpad janitor aspect that marks as fix released is ubuntu only magic?
[22:20] <wgrant> mrooney: Ubuntu doesn't get bugs closed by marking fixes in bzr. It's a special field in the changesfile that we upload.
[22:24] <persia> wgrant, Just as a counter-use-case : ubuntu-jp-improvement would like uploads to Ubuntu to close bugs (and Ubuntu doesn't want ubuntu-jp-improvement bugs)
[22:25] <beuno> I agree having that feature would be interesting
[22:25] <persia> The project might be an abuse of LP though.
[22:25] <wgrant> persia: ubuntu-jp-improvement should probably be a tag.
[22:25] <beuno> being able to change bug statuses through bzr
[22:25] <persia> wgrant, All the bugs are in Japanese.
[22:25] <wgrant> beuno: Since branches are now able to associate with a series, it should be possible.
[22:26] <persia> beuno, Doesn't that already work?
[22:26] <beuno> persia, no AFAIK
[22:26] <beuno> *not
[22:26] <wgrant> No.
[22:26] <wgrant> Because I might commit to some random branch which has no real association with the project.
[22:26] <persia> Oh.  I guess the people who merge my branches are just effective then.
[22:27] <beuno> wgrant, well, we can maybe just limit it to the mainline
[22:27] <persia> wgrant, I meant commits-to-registered-trunk
[22:27] <beuno> that's it  :)
[22:27] <wgrant> beuno: Or other series.
[22:28] <beuno> wgrant, right, that too
[22:28] <Nafallo> ehrm...
[22:28] <Nafallo> wgrant is here but not there...
[22:29] <Nafallo> weird.
[22:29]  * beuno blinks
[22:29] <Nafallo> beuno: hehe. just getting him to login to jabber ;-)
[22:29] <wgrant> Nafallo: Blah.
[22:35] <mrooney> You could have it branch specific, right? A setting like: "When bugs are referenced in [drop down of branches], change status to [Fix Committed / Fix Released]"
[22:36] <beuno> well, yes, but it sounds too complex
[22:36] <wgrant> It only makes sense to have the status change for the series when it's committed to the series branch.
[22:36] <beuno> I think just making it work on trunk or series would work pretty well
[22:36] <wgrant> So I think Launchpad already has all required information.
[22:37] <mrooney> yes, quite possibly
[23:54] <persia> Are packages autorejected (e.g. wrong signer) archived anywhere accessible to the public?
[23:55] <wgrant> persia: No. There is a bug open about that.
[23:55] <wgrant> An archive admin *might* be able to tell you.
[23:55] <persia> Hrm.
[23:57] <persia> Not worth chasing  Patch was "uploaded" for linux-rt about half an hour ago, and the patch author went to bed.  I can recover when the sun reaches Europe again, and nobody's on archive-admin duty today.
[23:58] <wgrant> Ah. Unfortunate.


[16:04] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Make Desktop Shortcuts for AppImages with this Tool @ https://www.omgubuntu.co.uk/2022/10/appimagelauncher-install-on-ubuntu (by Joey Sneddon)
[20:09] <Bashing-om> UWN: Issue756 up for review and final edits, Note the over kill for Ubuntu Pro - move to summarize or as a podcast ??
[20:12] <krytarik> Bashing-om: On the Akademy posts, "BoFs" needs escaping.
[20:16] <krytarik> And on the Ubuntu Pro one, I'm not sure why every single blog post about it should be listed, but I'd agree summarizing it would be nice - maybe even in the General News section as an exception.
[20:19] <krytarik> And whichever blog posts (or even all) you decide to keep on it, "Canonical launches free version of Ubuntu Pro for small businesses – Computer – News" got a few bits too many to the right.
[20:21] <Bashing-om> krytarik: ack - will work on ^ when finished stuffing into my pie hole :D
[20:22] <krytarik> And since the included video is an official one, indeed I'd also agree to move it to the Audio and Video section.
[20:23] <krytarik> Hmm, now I would like some pie.. >_<
[20:24] <krytarik> And something is wrong with the links in the Meeting Reports section. :3
[20:29] <krytarik> https://lists.debian.org/debian-devel-announce/2022/10/msg00001.html - btw, I've been thinking of including this one in e.g. Community News, but we'd yet have to find a proper article about it because there is no official one.. :3
[21:42] <Bashing-om> krytarik: I found no fault with the links in the Meeting Reports section (?) ... as to Debian - Our Sister and we are free to report on issues that affect our ecosystem :) Making up something now for our letter.
[21:46] <krytarik> "https://discourse.ubuntu.com/t/desktop-team-updates-monday-10th October-2022/31003" - is one of them, notice the space in it, and of course on the wiki the first part is made an actual link while the latter one is just dangling about as text that follows it.
[21:47] <krytarik> And since "October" is uppercase, it's maybe more than just a missing hyphen.
[21:57] <Bashing-om> krytarik: ack ^ fixing :D
[22:16] <Bashing-om> guiverc: Note in our WIKI of the changes from Gdoc - moved the Ubuntu Pro notices about and added one from debian. See that you agree that all is golden.
[22:23] <krytarik> Bashing-om: "– Computer – News" - is still there though (Ubuntu Pro links).
[22:24] <krytarik> Wow, they were silly enough to actually put that in the post title, but still.. :3
[22:26] <Bashing-om> krytarik: I got no heart burn to pretty the title up with the removal " – Computer – News".
[22:27] <krytarik> Taking a peek into the actual post, it also looks rather besides the point and poorly written though.. :3
[22:27] <krytarik> Which is why I'd suggest dropping it entirely.
[22:28] <Bashing-om> krytarik: will do the drop - :D
[23:30] <guiverc> Bashing-om, suggest s/, Optional/, optional/ or is Optional intended to be upper case for a reason, reads out of place   (ubuntu Pro or first summary) ... also s/links For/links for/ later in that summary
[23:31] <Bashing-om> guiverc: ^ just scatter brained me - I fix !
[23:31]  * guiverc hasn't marked in gdoc  (not gone there, but can if helpful)
[23:32] <guiverc> that's as far as I've got, ie. just started, so no hurry
[23:35] <Bashing-om> guiverc: typos repaired in Ubuntu Pro summary - will leave the WIKI open for any other edits :)
[23:38] <guiverc> Bashing-om, completed read thru; that was all i noted. looks good
[23:41] <Bashing-om> guiverc: Logging out then - I sure had the oooppps today in making up our WIKI :(


[05:03] <mup> PR snapd#7917 closed: snap-bootstrap: trigger udev for new partitions <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7917>
[05:32] <mup> PR snapd#7919 closed: snapstate: do not try up update bootloader in ephemeral mode <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7919>
[05:32] <mup> PR snapd#7920 closed: snapstate: do not try to detect rollback in ephemeral modes <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7920>
[05:32] <mup> PR snapd#7929 opened: boot: always return the trivial boot participant in ephemeral mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7929>
[05:53] <ctOS> Hi. I’ve installed Firefox via Snap on Fedora 31. I’ve go a 4K display. The mouse cursor is really small inside the Firefox window and the UI font is monospace. Any ideas on how to fix it?
[05:58] <mvo> hey ctOS, we have some people that might be able to help but it's a bit early in their timezone, the should be around in 2-3h here, might be worth checking in again then
[06:12] <mup> PR snapd#7923 closed: snap-bootstrap: mount filesystems after creation <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7923>
[06:33] <mborzecki> morning
[06:41] <mvo> hey mborzecki
[06:46] <mborzecki> mvo: hey
[06:46] <mvo> mborzecki: how are you?
[06:46] <mborzecki> mvo: good, i see you've been landind stuff since 6am? :)
[06:46] <mvo> mborzecki: yeah, deadlines :/
[06:46] <mvo> mborzecki: but good progress, so I'm quite happy
[07:03] <mup> PR snapd#7930 opened: run-checks: complain about MATCH -v <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7930>
[07:03] <mvo> mborzecki: \o/
[07:13] <mup> PR snapd#7928 closed: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7928>
[07:23] <mup> PR snapd#7931 opened: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
[07:24] <mvo> mborzecki: hahaha - 7930 seems to be working!
[07:25] <mvo> mborzecki: it's *failing* and it looks like the failure is real \o/
[07:25]  * mvo hugs mborzecki
[07:26] <mborzecki> mvo: hah, looks like i haven't updated my master before pushing the branch
[07:26] <mborzecki> at least we know it works ;)
[07:26] <mvo> mborzecki: it's a new thing, I think it got pulled in last night/yesterday
[07:26] <mvo> mborzecki: so really cool that we already found a new incorrect use of this
[07:28] <mup> PR snapd#7913 closed: boot,bootloader: extract kernel in makeBootable20RunMode  <UC20> <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7913>
[07:50] <mup> PR snapd#7908 closed: [RFC] boot,devicestate: update modenv and extract kernel <UC20> <Created by cmatsuoka> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7908>
[08:01] <mup> PR snapd#7932 opened: devicestate: request reboot after successful doSetupRunSystem() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7932>
[08:04] <mvo> I think that was the last uc20 PR to make seeding work
[08:04]  * mvo double checks with the WIP branch
[08:05] <pstolowski> morning
[08:05] <mvo> hey pstolowski
[08:07] <pedronis> mvo: hi, ah, you closed 7913,  do we still need to extract the kernel?
[08:09] <mvo> pedronis: not for the cheat we do
[08:10] <mvo> pedronis: when we go all the way to uc20 single-kernel name we just revert https://github.com/snapcore/snapd/pull/7931
[08:10] <mup> PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
[08:10] <pedronis> mvo: what grub.cfg do we use now?
[08:10] <pedronis> for run
[08:11] <mvo> pedronis: the one from uc16
[08:11] <mvo> pedronis: with updated label, it's in the 20/edge channel of pc
[08:11] <pedronis> ah
[08:11] <mvo> pedronis: https://github.com/snapcore/pc-amd64-gadget/blob/20/grub.cfg-normal
[08:11] <pedronis> that's the part I didn't understand, we use the new label?
[08:11] <mvo> pedronis: correct, we use "set label=ubuntu-data"
[08:12] <mvo> pedronis: and we also set snapd_recovery_mode=run
[08:12] <pedronis> ok
[08:12] <mvo> pedronis: beside that it's unchanged because we can reuse the grubenv
[08:12] <pedronis> mvo: I actually made good progress refactoring boot but there was some preexisting messiness that also needs to be cleaned up
[08:13] <pedronis> also I (re)discovered but BootParticipant probably only need SetNextBoot
[08:13] <pedronis> our current code is kind of slightly silly in various ways
[08:13] <mvo> pedronis: heh, great!
[08:13] <mvo> pedronis: I also have good news, xnox saw a fully seeding system last night
[08:14] <mvo> pedronis: with my core20-wip branch based snapd snap
[08:14] <pedronis> great
[08:14] <pedronis> mvo: btw, when it doesn't annoy current PRs can we move MakeBootable etc to mkbootable.go
[08:14] <mvo> pedronis: sounds great
[08:14] <pedronis> boot.go is not big, but is a bit of a kitchen sink atm
[08:15] <mvo> pedronis: lol - it surely is!
[08:15] <pedronis> and I'm adding more to it in my PRs
[08:19] <mborzecki> pstolowski: pedronis: hey
[08:20] <mborzecki> https://github.com/snapcore/snapd/pull/7906 needs a 2nd review and we can land it
[08:20] <mup> PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
[08:21] <mup> PR snapd#7907 closed: snap-bootstrap: append new partitions <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7907>
[08:39] <mup> PR snapd#7933 opened: snapd.core-fixup.sh: do not run on UC20 at all <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7933>
[08:39] <mvo> ok - that was really the last one I think
[08:44] <ctOS> Hi. I’ve installed Firefox via Snap on Fedora 31. I’ve go a 4K display. The mouse cursor is really small inside the Firefox window and the UI font is monospace. Any ideas on how to fix it?
[08:47] <mborzecki> ctOS: is that a wayland session?
[08:48] <ctOS> mborzecki: no, x11 kde
[08:48] <ctOS> looks the same in gnome, though.
[08:51] <mborzecki> ctOS: you can try that for the fonts https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484/24
[08:52] <mborzecki> ctOS: but the cursor thing is weird, probably some trouble accessing the x11 cursor or it's not picking up dpi correctly
[08:53] <ctOS> the mouse cursor looks different (like the default one on Windows, schmaybe) but its also half the normal size (which is more of a problem.
[08:54] <mborzecki> ctOS: sounds like this problem: https://forum.snapcraft.io/t/small-cursor-in-snap-apps-on-hidpi-display/5220 maybe the snap was not fixed
[08:56] <ctOS> mborzecki: deleting the fontcache didn’t fix the fonts. fonts have loaded for me, but its an unexpected monospace font everywhere.
[08:58] <mborzecki> ctOS: you can try to run this: `snap run firefox --shell` and then `fc-match 'sans serif'` (or what is the kind of typeface that you expect)
[08:59] <ctOS> mborzecki: /var/lib/snapd/snap/firefox/287/bin/desktop-launch does not contain this line https://github.com/ubuntu/snapcraft-desktop-helpers/commit/da4d8f878eaeb40c1788789cd034b7142f7d6749
[08:59] <ctOS> so it appears not to have received that fix.
[09:02] <ctOS> mborzecki: what does --shell do? should I get a new shell or something to run the second command?
[09:04] <mborzecki> popey: ^^ anyone can file this with mozilla?
[09:04] <mborzecki> ctOS: it starts a new shell with the same system view as snap has
[09:05] <pstolowski> looking at https://github.com/snapcore/snapd/pull/7906
[09:05] <mup> PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
[09:06] <ctOS> mborzecki: I don’t see anything opening other than firefox when I run it.
[09:07] <mborzecki> ctOS: duh, `snap run --shell firefox` sry
[09:08] <ctOS> mborzecki: running it in that shell I get "bash: fc-match: command not found". works in the normal shell and returns DejaVu Sans.
[09:09] <ctOS> mborzecki: fc<tab> in the Snap shell suggests "fc fc-cache-v6  fc-cache-v7"
[09:11] <mup> PR snapd#7934 opened: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
[09:12] <pedronis> pstolowski: ^
[09:12] <pstolowski> pedronis: thank you
[09:16] <pstolowski> #7906 +1
[09:16] <mup> PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
[09:16] <pedronis> thx
[09:16] <mborzecki> ctOS: had to do some local tweaking, try this in the snap shell: https://paste.ubuntu.com/p/wTw2SG4Pgz/
[09:17] <mborzecki> ctOS: returns the same font inside and outside of snap shell here on arch
[09:18] <ctOS> mborzecki:  no go, $SNAP is empty
[09:19] <ctOS> oh, /var/lib/snapd/snap/
[09:20] <mborzecki> ctOS: you need to do `snap run --shell firefox` and then run those lines inside that shell
[09:21] <mborzecki> ctOS: outside of snap shell you can simply run `fc-match <your-typeface>`
[09:21] <mup> PR snapd#7906 closed: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7906>
[09:21] <ctOS> mborzecki: I just realized that. different output. one sec
[09:22] <ctOS> mborzecki: FreeMono.ttf: "FreeMono" "Regular"
[09:23] <ctOS> mborzecki: plus these errors https://paste.ubuntu.com/p/Smsh2ZP9sT/
[09:23] <ctOS> mborzecki: outside snap shell it’s: DejaVuSans.ttf: "DejaVu Sans" "Book"
[09:25] <pedronis> degville: I looked at your last tweaks to the intro to Assertions, +1, thank you
[09:26] <pedronis> degville: as I said we should also port that to the glossary
[09:26] <degville> pedronis: will do, thanks for the review.
[09:32] <popey> mborzecki: I'd ping kenvandine or oSoMoN for Mozilla things
[09:34] <mborzecki> heh, firefox has no contact info either, no clue where users can report any problems
[09:36] <mborzecki> oSoMoN: kenvandine: can you ping mozilla to include the fix for cursors: https://forum.snapcraft.io/t/small-cursor-in-snap-apps-on-hidpi-display/5220/6 ?
[09:37] <mborzecki> ctOS: can you run fc-match inside the snap shell but with FC_DEBUG=4 this time and post the output somewhere?
[09:41] <ctOS> mborzecki: here you go https://paste.ubuntu.com/p/t995Sm9H8G/
[09:48] <mborzecki> ctOS: hm that's surprisingly short, can you run `ls /usr/share/fonts/TTF/Deja*` inside the snap shell? does it list anything?
[09:51] <ctOS> mborzecki: no, but `/usr/share/fonts/dejavu/*` does.
[09:52] <ctOS> mborzecki: here is `ls /usr/share/fonts/*/*` https://paste.ubuntu.com/p/4X3VyqKF43/
[09:53] <mvo> 7918 needs a second review, should be a simple one
[09:54] <mborzecki> ctOS: ok, can you run `$SNAP/usr/bin/fc-cache -v` inside the snam the same way you ran fc-match (same LD_LIBRARY_PATH exports), check whether it picked up /usr/share/fonts/dejavu and run fc-match again?
[09:57] <ctOS> mborzecki: Re-scanning /usr/share/fonts: /usr/share/fonts: error scanning \n /var/cache/fontconfig: not cleaning unwritable cache directory \n /snap/firefox/287/usr/bin/fc-cache: failed
[10:00] <mborzecki> ctOS: and if you run fc-cache -f -v ?
[10:03] <ctOS> mborzecki: https://paste.ubuntu.com/p/dpz4x3Q2VS/
[10:05] <mborzecki> ctOS: not sure why it's not building the cache in $HOME/.config/fontconfig, but this is as far as my fontconfig knowledge goes, i would suggest opening a forum topic on https://forum.snapcraft.io with a screenshot, make sure to include the output from fc-match
[10:06] <mborzecki> perhaps someone from the desktop team will have ideas
[10:12] <ctOS> mborzecki: I tried `sudo setenforce 0` on a hunch, but made no difference. `$HOME/.config/fontconfig` is also empty outside the snap shell.
[10:13] <mborzecki> ctOS: afaik selinux wouldn't matter, you're probably running as unconfined_t anyway
[10:47] <mborzecki> mvo:  little tweak in https://github.com/snapcore/snapd/pull/7918#discussion_r359275116
[10:47] <mup> PR #7918: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7918>
[10:47] <ctOS> mborzecki: thanks for all your time and troubleshooting help!
[10:48] <mborzecki> ctOS: np, these desktop things are ridiculously fragile
[10:59] <mvo> mborzecki: in a meeting right now, feel free to tweak and push
[11:03] <mup> PR snapd#7935 opened: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7935>
[11:04] <pedronis> mvo: mborzecki: Chipac: ^
[11:04] <pedronis> Chipaca: ^ (sorry)
[11:04] <Chipaca> pedronis: ack
[11:05] <pedronis> Chipaca: it touches policy, also with new InUse internals it should be easier to attack the TODO in policy about it, I haven't done so yet though
[11:06] <mvo> pedronis: yay!
[11:08] <Chipaca> pedronis: nice
[11:08] <pedronis> mvo: there is more to it (wip), but that's already quite big and slightly convuluted, though I think the direction is good, apart some complexity a bit not related to the main changes
[11:09] <mvo> pedronis: ok, I will look at it today
[11:09] <mvo> pedronis: my uc20 bits are all proposed now so I should have time
[11:09] <mvo> (still want to start with spread stuff though)
[11:10] <pedronis> mvo: I think if the plan works as I see it, implementing boot state for run for UC20 on top of this, once we understand what we want and grub.cfg, should be a couple of days
[11:11] <mvo> pedronis: amazing! let's aim for this before CPT
[11:15] <mvo> pedronis: should I add uc20 to 7935?
[11:22] <pedronis> mvo: yes
[11:24] <mvo> done
[11:29]  * pstolowski lunch
[11:50] <vidal72[m]> mborzecki: fyi there was a lot of changes done to firefox like update to core18 recently however they are available only in beta channel atm and probably will be in 72 stable release
[11:50] <vidal72[m]> https://hg.mozilla.org/mozilla-central/rev/606408df5b4d712c7bf4e80621dd145f1cd82940
[11:53] <vidal72[m]> pstolowski: what security implications? User can install snap with --dangerous, devmode, can disable apparmor on system but can't add permission to snap...
[11:56] <vidal72[m]> mborzecki: also bugs in ff snap should go to bugzilla afaik
[12:20] <mup> PR snapd#7929 closed: boot: always return the trivial boot participant in ephemeral mode <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7929>
[12:23] <pedronis> mborzecki: https://github.com/snapcore/snapd/pull/7921/commits/46fe5b30aba428f85c94f77e659c7aa508b12e00  also UC20 is not a reason not to have unit tests if they make sense (we might have UC20 todos about going incremental, but testing is important)
[12:23] <mup> PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
[12:27] <mborzecki> pedronis: the travis job is already running, but i can open a follow-up PR adding those tests
[12:27] <pedronis> mborzecki: there are tests
[12:27] <pedronis> mborzecki: that link points to tests
[12:27] <pedronis> am I super confused ?
[12:27] <pedronis> mvo added them
[12:28] <mvo> pedronis: uh, maybe I mixed something up
[12:28] <mborzecki> pedronis: right, thought you're referencing to the comment i made about special casing when there's no base in the model
[12:28]  * mvo will check later, lunch first
[12:29] <pedronis> mborzecki: ah, I misunderstood
[12:29] <pedronis> mborzecki: at test would be good for that
[12:29] <pedronis> mborzecki: I thought you were referring the whole function
[12:29] <mborzecki> pedronis: no worries, if the current job is successful we may land it and i'll open a PR adding that missing bit
[12:45] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7930 ?
[12:45] <mup> PR #7930: run-checks: complain about MATCH -v <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7930>
[12:46] <mborzecki> pstolowski: and while at it, maybe this one too: https://github.com/snapcore/snapd/pull/7922
[12:46] <mup> PR #7922: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>
[12:55] <mup> PR snapd#7936 opened: tests: unmount automounted snap-bootstrap devices <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7936>
[13:10] <kenvandine> mborzecki, popey, oSoMoN:  that should be fixed in beta
[13:10] <mborzecki> kenvandine: good to know, thanks!
[13:10] <mborzecki> ctOS: ^^
[13:11] <kenvandine> Mozilla has updated the snap to use the gnome-3-28 extension in beta
[13:11] <kenvandine> and core18
[13:11] <kenvandine> i haven't tried it yet though
[13:11] <mborzecki> hm maybe the fonts problem will go away too then
[13:12] <pstolowski> vidal72[m]: hey, i meant people trying to connect random slots to get such snap working, copying random snap connect receipes from the internet without realizing what they are doing etc. snap can be broken in many ways, missing slot is just one of them. if publisher is not cooperating and fixing/keeping his snaps updated, then it's a bad publisher. but feel free to open a forum topic, it's just my personal view
[13:15] <abeato> mvo, hey, are proxy settings actually applied for 'snap download'? It seems to work for 'snap install', but not when downloading
[13:16] <pstolowski> mborzecki: will do
[13:18] <mup> PR snapd#7930 closed: run-checks: complain about MATCH -v <Simple 😃> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7930>
[13:20] <mborzecki> pstolowski: thanks
[13:53] <mup> PR snapd#7937 opened: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information <Created by pedronis> <https://github.com/snapcore/snapd/pull/7937>
[13:57] <ijohnson> morning folks
[14:00] <mup> PR snapd#7858 closed: tests: also check nested lxd container <Test Robustness> <Created by anonymouse64> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7858>
[14:57] <ijohnson> who manages mup? I noticed the other day that when a new issue is created in a github issue such as in pc-amd64-gadget repo, the link that mup posts is wrong, it has "github.com/<org>/<repo>/issue/<num>" when it should be "github.com/<org>/<repo>/issues/<num>"
[14:59] <pstolowski> ijohnson: Gustavo
[15:00] <ijohnson> niemeyer: can you change the links that mup outputs for new github issues filed? see my previous comment above, thanks
[15:00] <ijohnson> thanks pstolowski
[15:02]  * cachio lunch
[15:06] <mup> PR snapd#7918 closed: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7918>
[15:11] <mup> PR snapcraft#2848 opened: common: generate run scripts which can execute independently <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2848>
[15:23] <pedronis> mborzecki: mvo: +1 to #7921 but the extra suite field is probably not needed
[15:23] <mup> PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
[15:24] <niemeyer> ijohnson: Ah, sure, thanks. Do you have a sample message?
[15:24] <ijohnson> niemeyer: sure I saw one yesterday I think, let me look
[15:25] <ijohnson> mup> Mup Pet Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
[15:25] <mup> Issue pc-amd64-gadget#30: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
[15:25] <ijohnson> niemeyer: ^
[15:27] <niemeyer> Thanks!
[15:28] <ijohnson> np, happy to help
[15:29] <niemeyer> pc-amd64-gadget#30
[15:29] <mup> Issue pc-amd64-gadget#30: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
[15:32] <mvo> pedronis: thanks! I can kill it
[15:34] <mborzecki> mvo: maybe land the PR and cleanup in a followup?
[15:34] <mborzecki> (it's green right now)
[15:38] <mvo> matiasb_: works for me
[15:38] <mvo> mborzecki: works for me
[15:38] <mvo> matiasb_: sorry, wrong tab-complete
[15:39] <mvo> mborzecki: in a meeting right now, feel free to take it if its trivial and you have cycles otherwise I will in a bit
[15:48] <pedronis> mvo: +1 to #7931 with some comments, let me know if they are unclear
[15:48] <mup> PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
[15:51] <mvo> pedronis: thanks! looking
[15:52] <pstolowski> pedronis: updated #7686
[15:52] <mup> PR #7686: systemd: handle preseed mode <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
[15:52] <pedronis> pstolowski: thx, I'll try to look at it in a bit
[15:52] <mup> PR snapd#7921 closed: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7921>
[15:53] <mvo> pedronis: comments make sense I think, will fix in a wee bit
[16:03] <mup> PR snapd#7938 opened: devicestate: advoid adding mockModel to deviceMgrInstallModeSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7938>
[16:06] <mup> PR snapd#7936 closed: tests: unmount automounted snap-bootstrap devices <Simple 😃> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7936>
[16:20] <mup> PR snapd#7939 opened: boot,o/devicestate: refactor MarkBootSuccessful over bootState <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[16:20] <pedronis> mmh, conflicts
[16:22] <cmatsuoka> anyone else getting schedule test errors in master?
[16:23] <cmatsuoka> invalid  distance for schedule "mon1-tue2,10:00" with last refresh "2017-02-06 10:00", now "2017-02-07 11:00", expected 647h-647h, got 648h0m0s, date 2017-03-06 10:00:00 -0300 -03
[16:26] <cmatsuoka> lunch, bbi30min
[16:42] <pedronis> pstolowski: did anohter pass on #7686, some small issues
[16:42] <mup> PR #7686: systemd: handle preseed mode <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
[16:43] <pstolowski> pedronis: thanks. yes, i can't believe pre-bake was still lurking, grr
[16:46] <mvo> very silly question - I'm writing a spread test right now and I get dropped into a debug/fail shell in spread when I run "REBOOT" with exitcode 213
[16:46] <mvo> hm, maybe my spread git is too old
[16:47]  * mvo update to latest master
[16:49] <mvo> cachio: we will need to drive google vms very soon in a way that enables uefi (maybe it is already enabled even?). do you think you could have a look what (if anything) we need to do to get a machine that has uefi enabled?
[16:58] <cachio> mvo, I'll read a bit the documentation
[16:58] <mvo> ta
[16:58] <cachio> so far uefi should not be enabled
[17:02] <mvo> cachio: ok
[17:02] <mvo> cachio: will enable require a spread change?
[17:02] <cachio> mvo, I think we will need to update spread
[17:02] <cachio> mvo, yes
[17:03] <cachio> the change is simple because it is a parameter when the instance is created
[17:04] <cachio> I'll imeplmeent the change, is is a new parameter in the system
[17:06] <pstolowski> pedronis: updated, thanks again
[17:06] <mvo> cachio: ta
[17:17] <cachio> mvo, there is also a way to create the image with that enabled by default
[17:18] <cachio> I think this option is betetr
[17:21] <mvo> cachio: nice!
[17:21] <mvo> cachio: I did something hackish for qemu https://github.com/snapcore/spread/compare/master...mvo5:spread-with-uefi?expand=1
[17:22] <mvo> cachio: and here is my hackish https://github.com/snapcore/snapd/commit/747d06a62deb5069a5ea695b03615a29d2e8bba9 (it's part of https://github.com/snapcore/snapd/compare/master...mvo5:core20-wip-2-spread?expand=1 which merges all of my uc20 prs) but it's not working yet but might be interessting to run against a google backend with uefi (not working because of qemu spread backend
[17:22] <cachio> mvo, on gce there are 2 ways
[17:22] <cachio> for customized images like ours
[17:22] <cachio> it is possible to define is during their creation
[17:22] <mvo> cachio: cool
[17:23] <cachio> for predefined images during creation of the instance
[17:23] <mvo> cachio: I get dinner now, will check back in a bit
[17:23] <cachio> sure
[17:26] <mvo> cachio: also very strane, looks like the ubuntu-16.04-64 image does not boot in my uefi qemu, so I changed the core20 base (that does the reflash) to 18.04 locally
[17:26]  * mvo is really off now
[17:31] <cachio> mvo, is it needed virtualization enabled on that image?
[17:35] <pstolowski> eod. happy holidays pedronis !
[17:35] <pedronis> pstolowski: thx
[17:36] <pstolowski> cu
[17:47] <mup> PR pc-amd64-gadget#31 opened: grub.cfg: switch to new style kernel_status failover handling <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/31>
[17:52] <mvo> cachio: this does not need anything special beside uefi, it's the same style of test as uc16/uc18 in spread
[17:53] <cachio> mvo, I am creating an image
[17:53] <mvo> cachio: cool! thanks
[17:53] <cachio> mvo, ubuntu 18.04
[17:53] <cachio> should be ready in 5/10 minutes
[17:53] <mvo> cachio: once you have a name, please let me know and I update my spread config. no rush, I will probably work on this full steam in my morning
[17:54] <mvo> but not that much tonight
[17:58] <mup> PR snapd#7933 closed: snapd.core-fixup.sh: do not run on UC20 at all <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7933>
[17:58] <cachio> mvo, you can use image: ubuntu-1604-64-uefi-enabled
[17:58] <mvo> cachio: \o/ thanks
[17:58] <cachio> do you need an image for xenial as well?
[17:59] <cachio> mvo, sorry
[17:59] <cachio> hte image is -> image: ubuntu-1804-64-uefi-enabled
[17:59] <cachio> xenial is not created yet
[17:59] <mvo> cachio: ubuntu-18.04-64 or 1804 ?
[17:59] <mvo> cachio: I don't need the 1604 I think
[18:00] <cachio> mvo, you should add this to the spread.yaml
[18:00] <cachio>             - ubuntu-18.04-64-uefi-enabled:
[18:00] <cachio>                 image: ubuntu-1804-64-uefi-enabled
[18:00] <cachio> that works for me
[18:00] <mvo> cachio: cool, trying now
[18:01] <mvo> cachio: it may hang on reboot, so be prepared to kill a machine :/
[18:01] <cachio> mvo, nice
[18:01] <mvo> cachio: I don't think the reboot stuff is fully debugged yet
[18:01] <cachio> mvo, no problem
[18:01] <mvo> cachio: ta
[18:03] <cachio> do you have a name?
[18:03] <cachio> for the instance?
[18:04] <cachio> mvo, I can share the serial output
[18:04] <mvo> cachio: one sec, let me find it
[18:06]  * cmatsuoka very curious about the results
[18:19] <cachio> mvo, did it work?
[18:20] <mup> PR snapd#7940 opened: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
[18:40] <mvo> cachio: no, it looks like it does not connect
[18:43] <cachio> mvo, I could connect
[18:43] <cachio> and open a shell device
[18:43] <cachio> there
[18:43] <mvo> cachio: is it still in 18.04?
[18:43] <mvo> cachio: I asked it to reboot to reflash
[18:44] <cachio> mvo, https://paste.ubuntu.com/p/VkXVV9s38J/
[18:44] <cachio> this is that validation which I ddi
[18:44] <cachio> did
[18:44] <mvo> cachio: aha, ok
[18:45] <cachio>             - ubuntu-18.04-64-uefi-enabled:
[18:45] <cachio>                 image: ubuntu-1804-64-uefi-enabled
[18:45] <cachio> using this configuration in the spread.yaml
[18:46] <mvo> cachio: yeah, this works, just my core20 test is not yet working
[18:46] <mvo> cachio: you may need to kill the instance
[18:46] <mvo> cachio: aha, I think it got killed now
[18:46] <mvo> cachio: spread timed out
[18:46] <cachio> do you have the name of the instance?
[18:47] <cachio> mvo, it is automatically killed after 1h30m aprox
[18:47] <cachio> in case it is not automatically discarded
[18:47] <cachio> be spread
[18:48] <mvo> ok
[18:48] <mvo> thanks
[18:48] <mup> PR snapd#7932 closed: devicestate: request reboot after successful doSetupRunSystem() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7932>
[19:21]  * cachio afk
[19:22] <mup> PR snapd#6108 closed: many: apparmor support for non-AA rpm distros <:birthday:> <Decaying ☢> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
[19:58] <mup> PR snapd#7941 opened: snap-bootstrap: read only stdout when parsing the sfdisk json <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7941>
[19:58] <cmatsuoka> my link is very spotty this afternoon :(
[19:59] <cmatsuoka> couldn't reach github, let's see if it's stable now...
[20:15] <mvo> cmatsuoka: once it's back would be great if you could check if we regressed since this morning
[20:15] <mvo> cmatsuoka: re uc20
[20:15] <mvo> cmatsuoka: with master+PR#7931 it should still work
[20:16] <cmatsuoka> mvo: will check that now, just a sec
[20:16] <mvo> cmatsuoka: no rush
[20:16] <mvo> cmatsuoka: with https://github.com/snapcore/snapd/compare/master...mvo5:core20-wip-2-spread?expand=1 eventually (still a lot of open issues) we can automate this
[20:17] <mvo> cmatsuoka: but it needs the kernel on edge first
[20:17] <cmatsuoka> I want to check out that branch before I lose internet again :)
[20:17] <mvo> cmatsuoka: and we need 7931 in master
[20:17] <mvo> cmatsuoka: and then *maybe* it will work in google (qemu backend needs a patch in spread)
[20:18] <mvo> cmatsuoka: meh, it won't work because xnox needs to finish shutdown first, that hangs right now
[20:18] <mvo> cmatsuoka: but we are kinda close :)
[20:18] <mvo> (ish)
[20:18] <mvo> maybe close is overstating it
[20:19] <cmatsuoka> Pft, "This site can’t be reached - github.com refused to connect."
[20:20] <cmatsuoka> It looks like some cgnat proxy mess, but it affects two different ISPs
[20:20] <cmatsuoka> very strange
[20:23] <cmatsuoka> ok, #7931 checked out
[20:24] <mup> PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
[20:44] <mup> PR snapd#7942 opened: Nvidia driver microversion <Created by zhuker> <https://github.com/snapcore/snapd/pull/7942>
[20:46]  * cachio afk
[20:48] <cmatsuoka> mvo: is master+7931 supposed to work to the end of install stage without manual intervention?
[20:49] <cmatsuoka> mvo: does it also require changes in the initramfs side? because for me it worked like the previous one, i.e. needs help to create partitions
[20:49] <cmatsuoka> (using current core, gadget and kernel snaps)
[20:49] <cmatsuoka> let's see what's in 7931...
[20:51] <mwhudson> how is parallel installs for classic snaps coming along?
[21:12] <mup> PR snapcraft#2849 opened: rust plugin: split RUSTUP_HOME and CARGO_HOME <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2849>
[21:19] <ijohnson> mwhudson: o/ it should be working in edge at least, possibly even stable IIRC
[21:20] <ijohnson> still experimental however
[21:20] <mwhudson> ijohnson: oh!
[21:20] <mup> PR snapd#7938 closed: devicestate: avoid adding mockModel to deviceMgrInstallModeSuite <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7938>
[21:23] <ijohnson> mwhudson: ah actually looks like it will be next stable I think, so 2.43
[21:23] <mwhudson> ijohnson: so snap refresh --beta core and i can try it?
[21:24] <ijohnson> mwhudson: yes
[21:24] <ijohnson> I have been using it the past few weeks with your go snap to much delight :-)
[21:24] <ijohnson> note that aliases don't work, so you need to unalias things before the go snap specifically works
[21:24] <mwhudson> ijohnson: heh that's why i was asking
[21:24] <mwhudson> ah
[21:25] <mwhudson> i wanted to tweet about installing go 1.14 beta in parallel to stable
[21:25] <mwhudson> is there a plan for making aliases work more smoothly?
[21:25] <ijohnson> mwhudson: https://github.com/snapcore/snapd/pull/7302#pullrequestreview-310225458
[21:25] <mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7302>
[21:25] <ijohnson> not on the immediate roadmap unfortunately
[21:25] <mwhudson> ok
[21:26] <ijohnson> it's the kind of thing I think is a bit difficult to "do the right thing" automatically, but it's at least a known limitation
[21:26] <mwhudson> yeah i didn't actually think about it at all before asking that question :)
[21:27] <ijohnson> :-)
[21:33] <mwhudson> ijohnson: https://twitter.com/mwhudson/status/1207413478404673536
[21:33] <ijohnson> mwhudson: nice 👍
[21:33] <mwhudson> ah ffs typo
[21:33] <ijohnson> ahhh haha
[21:33] <ijohnson> I see it now too
[21:34] <mwhudson> deleted and reposted
[21:34] <ijohnson> mwhudson: did you try with beta core? or only edge?
[21:34] <ijohnson> AFAIK it should be in beta
[21:34] <mwhudson> ijohnson: yeah, beta
[21:35] <mwhudson> oh i put edge in the tweet
[21:35] <mwhudson> oh well
[21:35] <mwhudson> not going to delete it again for that :)
[21:35]  * ijohnson feels nervous having folks switch to snapd edge but it's just twitter so oh well
[21:49] <pedronis> mwhudson: we discussed the idea that for things that are not the main instance, they would install --unaliased by default. We would also add snap install --prefer to force using the aliases if one wants to
[21:50] <mwhudson> pedronis: yeah just not setting up aliases for the non-default one seems reasonable on the face of it
[23:17] <xnox> ijohnson:  i've been on edge channel for months now, since had to work on uc20 =/
[23:29] <mup> PR snapd#7931 closed: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7931>
[23:33]  * ijohnson pours one out for xnox's computer
[23:39]  * ijohnson also builds a monument to xnox's computer for all the hard work on uc20 :-)
[23:54]  * cmatsuoka frustrated with the unstable internet here today, maybe it's better after dinner...
[23:54] <cmatsuoka> bbl


[00:00] <vans163> yup configs are working now with no problems..
[00:00] <vans163> Can anyone confirm if setting a weak passwords locks all users from being able to login?
[00:07] <vans163> okay strange password 12345678 works too now
[00:07] <vans163> anyways in conclusion i dont know wtf happen
[00:08] <vans163> maybe a rogue space or linebreak
[00:08] <vans163> broke the formatting i dont know