User1: 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>
User1: 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>
User1: 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>
User1: 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>
User2: 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?
User3: 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
User1: PR snapd#7923 closed: snap-bootstrap: mount filesystems after creation <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7923>
User4: morning
User3: hey mborzecki
User4: User3 hey
User3: User4 how are you?
User4: User3 good, i see you've been landind stuff since 6am? :)
User3: User4 yeah, deadlines :/
User3: User4 but good progress, so I'm quite happy
User1: PR snapd#7930 opened: run-checks: complain about MATCH -v <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7930>
User3: User4 \o/
User1: 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>
User1: PR snapd#7931 opened: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
User3: User4 hahaha - 7930 seems to be working!
User3: User4 it's *failing* and it looks like the failure is real \o/
 * mvo hugs mborzecki
User4: User3 hah, looks like i haven't updated my master before pushing the branch
User4: at least we know it works ;)
User3: User4 it's a new thing, I think it got pulled in last night/yesterday
User3: User4 so really cool that we already found a new incorrect use of this
User1: 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>
User1: 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>
User1: PR snapd#7932 opened: devicestate: request reboot after successful doSetupRunSystem() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7932>
User3: I think that was the last uc20 PR to make seeding work
 * mvo double checks with the WIP branch
User5: morning
User3: hey pstolowski
User6: User3 hi, ah, you closed 7913,  do we still need to extract the kernel?
User3: User6 not for the cheat we do
User3: User6 when we go all the way to uc20 single-kernel name we just revert https://github.com/snapcore/snapd/pull/7931
User1: PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
User6: User3 what grub.cfg do we use now?
User6: for run
User3: User6 the one from uc16
User3: User6 with updated label, it's in the 20/edge channel of pc
User6: ah
User3: User6 https://github.com/snapcore/pc-amd64-gadget/blob/20/grub.cfg-normal
User6: that's the part I didn't understand, we use the new label?
User3: User6 correct, we use "set label=ubuntu-data"
User3: User6 and we also set snapd_recovery_mode=run
User6: ok
User3: User6 beside that it's unchanged because we can reuse the grubenv
User6: User3 I actually made good progress refactoring boot but there was some preexisting messiness that also needs to be cleaned up
User6: also I (re)discovered but BootParticipant probably only need SetNextBoot
User6: our current code is kind of slightly silly in various ways
User3: User6 heh, great!
User3: User6 I also have good news, xnox saw a fully seeding system last night
User3: User6 with my core20-wip branch based snapd snap
User6: great
User6: User3 btw, when it doesn't annoy current PRs can we move MakeBootable etc to mkbootable.go
User3: User6 sounds great
User6: boot.go is not big, but is a bit of a kitchen sink atm
User3: User6 lol - it surely is!
User6: and I'm adding more to it in my PRs
User4: User5 User6 hey
User4: https://github.com/snapcore/snapd/pull/7906 needs a 2nd review and we can land it
User1: PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
User1: PR snapd#7907 closed: snap-bootstrap: append new partitions <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7907>
User1: 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>
User3: ok - that was really the last one I think
User2: 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?
User4: User2 is that a wayland session?
User2: User4 no, x11 kde
User2: looks the same in gnome, though.
User4: User2 you can try that for the fonts https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484/24
User4: User2 but the cursor thing is weird, probably some trouble accessing the x11 cursor or it's not picking up dpi correctly
User2: 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.
User4: User2 sounds like this problem: https://forum.snapcraft.io/t/small-cursor-in-snap-apps-on-hidpi-display/5220 maybe the snap was not fixed
User2: User4 deleting the fontcache didnât fix the fonts. fonts have loaded for me, but its an unexpected monospace font everywhere.
User4: User2 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)
User2: User4 /var/lib/snapd/snap/firefox/287/bin/desktop-launch does not contain this line https://github.com/ubuntu/snapcraft-desktop-helpers/commit/da4d8f878eaeb40c1788789cd034b7142f7d6749
User2: so it appears not to have received that fix.
User2: User4 what does --shell do? should I get a new shell or something to run the second command?
User4: User8 ^^ anyone can file this with mozilla?
User4: User2 it starts a new shell with the same system view as snap has
User5: looking at https://github.com/snapcore/snapd/pull/7906
User1: PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
User2: User4 I donât see anything opening other than firefox when I run it.
User4: User2 duh, `snap run --shell firefox` sry
User2: User4 running it in that shell I get "bash: fc-match: command not found". works in the normal shell and returns DejaVu Sans.
User2: User4 fc<tab> in the Snap shell suggests "fc fc-cache-v6  fc-cache-v7"
User1: 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>
User6: User5 ^
User5: User6 thank you
User5: #7906 +1
User1: PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
User6: thx
User4: User2 had to do some local tweaking, try this in the snap shell: https://paste.ubuntu.com/p/wTw2SG4Pgz/
User4: User2 returns the same font inside and outside of snap shell here on arch
User2: User4  no go, $SNAP is empty
User2: oh, /var/lib/snapd/snap/
User4: User2 you need to do `snap run --shell firefox` and then run those lines inside that shell
User4: User2 outside of snap shell you can simply run `fc-match <your-typeface>`
User1: 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>
User2: User4 I just realized that. different output. one sec
User2: User4 FreeMono.ttf: "FreeMono" "Regular"
User2: User4 plus these errors https://paste.ubuntu.com/p/Smsh2ZP9sT/
User2: User4 outside snap shell itâs: DejaVuSans.ttf: "DejaVu Sans" "Book"
User6: User7 I looked at your last tweaks to the intro to Assertions, +1, thank you
User6: User7 as I said we should also port that to the glossary
User7: User6 will do, thanks for the review.
User8: User4 I'd ping kenvandine or oSoMoN for Mozilla things
User4: heh, firefox has no contact info either, no clue where users can report any problems
User4: oSoMoN: User10 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 ?
User4: User2 can you run fc-match inside the snap shell but with FC_DEBUG=4 this time and post the output somewhere?
User2: User4 here you go https://paste.ubuntu.com/p/t995Sm9H8G/
User4: User2 hm that's surprisingly short, can you run `ls /usr/share/fonts/TTF/Deja*` inside the snap shell? does it list anything?
User2: User4 no, but `/usr/share/fonts/dejavu/*` does.
User2: User4 here is `ls /usr/share/fonts/*/*` https://paste.ubuntu.com/p/4X3VyqKF43/
User3: 7918 needs a second review, should be a simple one
User4: User2 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?
User2: User4 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
User4: User2 and if you run fc-cache -f -v ?
User2: User4 https://paste.ubuntu.com/p/dpz4x3Q2VS/
User4: User2 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
User4: perhaps someone from the desktop team will have ideas
User2: User4 I tried `sudo setenforce 0` on a hunch, but made no difference. `$HOME/.config/fontconfig` is also empty outside the snap shell.
User4: User2 afaik selinux wouldn't matter, you're probably running as unconfined_t anyway
User4: User3  little tweak in https://github.com/snapcore/snapd/pull/7918#discussion_r359275116
User1: PR #7918: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7918>
User2: User4 thanks for all your time and troubleshooting help!
User4: User2 np, these desktop things are ridiculously fragile
User3: User4 in a meeting right now, feel free to tweak and push
User1: 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>
User6: User3 User4 Chipac: ^
User6: User9 ^ (sorry)
User9: User6 ack
User6: User9 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
User3: User6 yay!
User9: User6 nice
User6: User3 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
User3: User6 ok, I will look at it today
User3: User6 my uc20 bits are all proposed now so I should have time
User3: (still want to start with spread stuff though)
User6: User3 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
User3: User6 amazing! let's aim for this before CPT
User3: User6 should I add uc20 to 7935?
User6: User3 yes
User3: done
 * pstolowski lunch
User1: 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>
User6: User4 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)
User1: PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
User4: User6 the travis job is already running, but i can open a follow-up PR adding those tests
User6: User4 there are tests
User6: User4 that link points to tests
User6: am I super confused ?
User6: mvo added them
User3: User6 uh, maybe I mixed something up
User4: User6 right, thought you're referencing to the comment i made about special casing when there's no base in the model
 * mvo will check later, lunch first
User6: User4 ah, I misunderstood
User6: User4 at test would be good for that
User6: User4 I thought you were referring the whole function
User4: User6 no worries, if the current job is successful we may land it and i'll open a PR adding that missing bit
User4: User5 can you take a look at https://github.com/snapcore/snapd/pull/7930 ?
User1: PR #7930: run-checks: complain about MATCH -v <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7930>
User4: User5 and while at it, maybe this one too: https://github.com/snapcore/snapd/pull/7922
User1: PR #7922: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>
User1: PR snapd#7936 opened: tests: unmount automounted snap-bootstrap devices <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7936>
User10: mborzecki, popey, oSoMoN:  that should be fixed in beta
User4: User10 good to know, thanks!
User4: User2 ^^
User10: Mozilla has updated the snap to use the gnome-3-28 extension in beta
User10: and core18
User10: i haven't tried it yet though
User4: hm maybe the fonts problem will go away too then
User5: 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
User11: mvo, hey, are proxy settings actually applied for 'snap download'? It seems to work for 'snap install', but not when downloading
User5: User4 will do
User1: PR snapd#7930 closed: run-checks: complain about MATCH -v <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7930>
User4: User5 thanks
User1: 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>
User12: morning folks
User1: 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>
User12: 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>"
User5: User12 Gustavo
User12: User13 can you change the links that mup outputs for new github issues filed? see my previous comment above, thanks
User12: thanks pstolowski
 * cachio lunch
User1: 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>
User1: PR snapcraft#2848 opened: common: generate run scripts which can execute independently <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2848>
User6: User4 User3 +1 to #7921 but the extra suite field is probably not needed
User1: PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
User13: User12 Ah, sure, thanks. Do you have a sample message?
User12: User13 sure I saw one yesterday I think, let me look
User12: 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>
User1: Issue pc-amd64-gadget#30: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
User12: User13 ^
User13: Thanks!
User12: np, happy to help
User13: pc-amd64-gadget#30
User1: Issue pc-amd64-gadget#30: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
User3: User6 thanks! I can kill it
User4: User3 maybe land the PR and cleanup in a followup?
User4: (it's green right now)
User3: matiasb_: works for me
User3: User4 works for me
User3: matiasb_: sorry, wrong tab-complete
User3: User4 in a meeting right now, feel free to take it if its trivial and you have cycles otherwise I will in a bit
User6: User3 +1 to #7931 with some comments, let me know if they are unclear
User1: PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
User3: User6 thanks! looking
User5: User6 updated #7686
User1: PR #7686: systemd: handle preseed mode <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
User6: User5 thx, I'll try to look at it in a bit
User1: PR snapd#7921 closed: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7921>
User3: User6 comments make sense I think, will fix in a wee bit
User1: PR snapd#7938 opened: devicestate: advoid adding mockModel to deviceMgrInstallModeSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7938>
User1: 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>
User1: PR snapd#7939 opened: boot,o/devicestate: refactor MarkBootSuccessful over bootState <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
User6: mmh, conflicts
User14: anyone else getting schedule test errors in master?
User14: 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
User14: lunch, bbi30min
User6: User5 did anohter pass on #7686, some small issues
User1: PR #7686: systemd: handle preseed mode <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
User5: User6 thanks. yes, i can't believe pre-bake was still lurking, grr
User3: 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
User3: hm, maybe my spread git is too old
 * mvo update to latest master
User3: User15 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?
User15: mvo, I'll read a bit the documentation
User3: ta
User15: so far uefi should not be enabled
User3: User15 ok
User3: User15 will enable require a spread change?
User15: mvo, I think we will need to update spread
User15: mvo, yes
User15: the change is simple because it is a parameter when the instance is created
User15: I'll imeplmeent the change, is is a new parameter in the system
User5: User6 updated, thanks again
User3: User15 ta
User15: mvo, there is also a way to create the image with that enabled by default
User15: I think this option is betetr
User3: User15 nice!
User3: User15 I did something hackish for qemu https://github.com/snapcore/spread/compare/master...mvo5:spread-with-uefi?expand=1
User3: User15 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
User15: mvo, on gce there are 2 ways
User15: for customized images like ours
User15: it is possible to define is during their creation
User3: User15 cool
User15: for predefined images during creation of the instance
User3: User15 I get dinner now, will check back in a bit
User15: sure
User3: User15 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
 * mvo is really off now
User15: mvo, is it needed virtualization enabled on that image?
User5: eod. happy holidays pedronis !
User6: User5 thx
User5: cu
User1: 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>
User3: User15 this does not need anything special beside uefi, it's the same style of test as uc16/uc18 in spread
User15: mvo, I am creating an image
User3: User15 cool! thanks
User15: mvo, ubuntu 18.04
User15: should be ready in 5/10 minutes
User3: User15 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
User3: but not that much tonight
User1: 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>
User15: mvo, you can use image: ubuntu-1604-64-uefi-enabled
User3: User15 \o/ thanks
User15: do you need an image for xenial as well?
User15: mvo, sorry
User15: hte image is -> image: ubuntu-1804-64-uefi-enabled
User15: xenial is not created yet
User3: User15 ubuntu-18.04-64 or 1804 ?
User3: User15 I don't need the 1604 I think
User15: mvo, you should add this to the spread.yaml
User15: - ubuntu-18.04-64-uefi-enabled:
User15: image: ubuntu-1804-64-uefi-enabled
User15: that works for me
User3: User15 cool, trying now
User3: User15 it may hang on reboot, so be prepared to kill a machine :/
User15: mvo, nice
User3: User15 I don't think the reboot stuff is fully debugged yet
User15: mvo, no problem
User3: User15 ta
User15: do you have a name?
User15: for the instance?
User15: mvo, I can share the serial output
User3: User15 one sec, let me find it
 * cmatsuoka very curious about the results
User15: mvo, did it work?
User1: PR snapd#7940 opened: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
User3: User15 no, it looks like it does not connect
User15: mvo, I could connect
User15: and open a shell device
User15: there
User3: User15 is it still in 18.04?
User3: User15 I asked it to reboot to reflash
User15: mvo, https://paste.ubuntu.com/p/VkXVV9s38J/
User15: this is that validation which I ddi
User15: did
User3: User15 aha, ok
User15: - ubuntu-18.04-64-uefi-enabled:
User15: image: ubuntu-1804-64-uefi-enabled
User15: using this configuration in the spread.yaml
User3: User15 yeah, this works, just my core20 test is not yet working
User3: User15 you may need to kill the instance
User3: User15 aha, I think it got killed now
User3: User15 spread timed out
User15: do you have the name of the instance?
User15: mvo, it is automatically killed after 1h30m aprox
User15: in case it is not automatically discarded
User15: be spread
User3: ok
User3: thanks
User1: PR snapd#7932 closed: devicestate: request reboot after successful doSetupRunSystem() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7932>
 * cachio afk
User1: 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>
User1: 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>
User14: my link is very spotty this afternoon :(
User14: couldn't reach github, let's see if it's stable now...
User3: User14 once it's back would be great if you could check if we regressed since this morning
User3: User14 re uc20
User3: User14 with master+PR#7931 it should still work
User14: User3 will check that now, just a sec
User3: User14 no rush
User3: User14 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
User3: User14 but it needs the kernel on edge first
User14: I want to check out that branch before I lose internet again :)
User3: User14 and we need 7931 in master
User3: User14 and then *maybe* it will work in google (qemu backend needs a patch in spread)
User3: User14 meh, it won't work because xnox needs to finish shutdown first, that hangs right now
User3: User14 but we are kinda close :)
User3: (ish)
User3: maybe close is overstating it
User14: Pft, "This site canât be reached - github.com refused to connect."
User14: It looks like some cgnat proxy mess, but it affects two different ISPs
User14: very strange
User14: ok, #7931 checked out
User1: PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
User1: PR snapd#7942 opened: Nvidia driver microversion <Created by zhuker> <https://github.com/snapcore/snapd/pull/7942>
 * cachio afk
User14: User3 is master+7931 supposed to work to the end of install stage without manual intervention?
User14: User3 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
User14: (using current core, gadget and kernel snaps)
User14: let's see what's in 7931...
User16: how is parallel installs for classic snaps coming along?
User1: PR snapcraft#2849 opened: rust plugin: split RUSTUP_HOME and CARGO_HOME <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2849>
User12: User16 o/ it should be working in edge at least, possibly even stable IIRC
User12: still experimental however
User16: User12 oh!
User1: PR snapd#7938 closed: devicestate: avoid adding mockModel to deviceMgrInstallModeSuite <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7938>
User12: User16 ah actually looks like it will be next stable I think, so 2.43
User16: User12 so snap refresh --beta core and i can try it?
User12: User16 yes
User12: I have been using it the past few weeks with your go snap to much delight :-)
User12: note that aliases don't work, so you need to unalias things before the go snap specifically works
User16: User12 heh that's why i was asking
User16: ah
User16: i wanted to tweet about installing go 1.14 beta in parallel to stable
User16: is there a plan for making aliases work more smoothly?
User12: User16 https://github.com/snapcore/snapd/pull/7302#pullrequestreview-310225458
User1: 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>
User12: not on the immediate roadmap unfortunately
User16: ok
User12: 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
User16: yeah i didn't actually think about it at all before asking that question :)
User12: :-)
User16: User12 https://twitter.com/mwhudson/status/1207413478404673536
User12: User16 nice ð
User16: ah ffs typo
User12: ahhh haha
User12: I see it now too
User16: deleted and reposted
User12: User16 did you try with beta core? or only edge?
User12: AFAIK it should be in beta
User16: User12 yeah, beta
User16: oh i put edge in the tweet
User16: oh well
User16: not going to delete it again for that :)
 * ijohnson feels nervous having folks switch to snapd edge but it's just twitter so oh well
User6: User16 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
User16: User6 yeah just not setting up aliases for the non-default one seems reasonable on the face of it
User17: User12  i've been on edge channel for months now, since had to work on uc20 =/
User1: 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>
 * ijohnson pours one out for xnox's computer 
 * ijohnson also builds a monument to xnox's computer for all the hard work on uc20 :-)
 * cmatsuoka frustrated with the unstable internet here today, maybe it's better after dinner...
User14: bbl
snappy
Ubuntu IRC