[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