=== diddledan4 is now known as diddledan [05:03] PR snapd#7917 closed: snap-bootstrap: trigger udev for new partitions [05:32] PR snapd#7919 closed: snapstate: do not try up update bootloader in ephemeral mode [05:32] PR snapd#7920 closed: snapstate: do not try to detect rollback in ephemeral modes [05:32] PR snapd#7929 opened: boot: always return the trivial boot participant in ephemeral mode [05:53] 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] 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] PR snapd#7923 closed: snap-bootstrap: mount filesystems after creation [06:33] morning [06:41] hey mborzecki [06:46] mvo: hey [06:46] mborzecki: how are you? [06:46] mvo: good, i see you've been landind stuff since 6am? :) [06:46] mborzecki: yeah, deadlines :/ [06:46] mborzecki: but good progress, so I'm quite happy [07:03] PR snapd#7930 opened: run-checks: complain about MATCH -v [07:03] mborzecki: \o/ [07:13] PR snapd#7928 closed: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot [07:23] PR snapd#7931 opened: boot: write compat UC16 bootvars in makeBootable20RunMode [07:24] mborzecki: hahaha - 7930 seems to be working! [07:25] mborzecki: it's *failing* and it looks like the failure is real \o/ [07:25] * mvo hugs mborzecki [07:26] mvo: hah, looks like i haven't updated my master before pushing the branch [07:26] at least we know it works ;) [07:26] mborzecki: it's a new thing, I think it got pulled in last night/yesterday [07:26] mborzecki: so really cool that we already found a new incorrect use of this [07:28] PR snapd#7913 closed: boot,bootloader: extract kernel in makeBootable20RunMode <⛔ Blocked> [07:50] PR snapd#7908 closed: [RFC] boot,devicestate: update modenv and extract kernel [08:01] PR snapd#7932 opened: devicestate: request reboot after successful doSetupRunSystem() [08:04] I think that was the last uc20 PR to make seeding work [08:04] * mvo double checks with the WIP branch [08:05] morning [08:05] hey pstolowski [08:07] mvo: hi, ah, you closed 7913, do we still need to extract the kernel? [08:09] pedronis: not for the cheat we do [08:10] pedronis: when we go all the way to uc20 single-kernel name we just revert https://github.com/snapcore/snapd/pull/7931 [08:10] PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode [08:10] mvo: what grub.cfg do we use now? [08:10] for run [08:11] pedronis: the one from uc16 [08:11] pedronis: with updated label, it's in the 20/edge channel of pc [08:11] ah [08:11] pedronis: https://github.com/snapcore/pc-amd64-gadget/blob/20/grub.cfg-normal [08:11] that's the part I didn't understand, we use the new label? [08:11] pedronis: correct, we use "set label=ubuntu-data" [08:12] pedronis: and we also set snapd_recovery_mode=run [08:12] ok [08:12] pedronis: beside that it's unchanged because we can reuse the grubenv [08:12] mvo: I actually made good progress refactoring boot but there was some preexisting messiness that also needs to be cleaned up [08:13] also I (re)discovered but BootParticipant probably only need SetNextBoot [08:13] our current code is kind of slightly silly in various ways [08:13] pedronis: heh, great! [08:13] pedronis: I also have good news, xnox saw a fully seeding system last night [08:14] pedronis: with my core20-wip branch based snapd snap [08:14] great [08:14] mvo: btw, when it doesn't annoy current PRs can we move MakeBootable etc to mkbootable.go [08:14] pedronis: sounds great [08:14] boot.go is not big, but is a bit of a kitchen sink atm [08:15] pedronis: lol - it surely is! [08:15] and I'm adding more to it in my PRs [08:19] pstolowski: pedronis: hey [08:20] https://github.com/snapcore/snapd/pull/7906 needs a 2nd review and we can land it [08:20] PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check [08:21] PR snapd#7907 closed: snap-bootstrap: append new partitions [08:39] PR snapd#7933 opened: snapd.core-fixup.sh: do not run on UC20 at all [08:39] ok - that was really the last one I think [08:44] 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] ctOS: is that a wayland session? [08:48] mborzecki: no, x11 kde [08:48] looks the same in gnome, though. [08:51] 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] ctOS: but the cursor thing is weird, probably some trouble accessing the x11 cursor or it's not picking up dpi correctly [08:53] 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] 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] mborzecki: deleting the fontcache didn’t fix the fonts. fonts have loaded for me, but its an unexpected monospace font everywhere. [08:58] 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] 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] so it appears not to have received that fix. [09:02] mborzecki: what does --shell do? should I get a new shell or something to run the second command? [09:04] popey: ^^ anyone can file this with mozilla? [09:04] ctOS: it starts a new shell with the same system view as snap has [09:05] looking at https://github.com/snapcore/snapd/pull/7906 [09:05] PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check [09:06] mborzecki: I don’t see anything opening other than firefox when I run it. [09:07] ctOS: duh, `snap run --shell firefox` sry [09:08] 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] mborzecki: fc in the Snap shell suggests "fc fc-cache-v6 fc-cache-v7" [09:11] PR snapd#7934 opened: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect [09:12] pstolowski: ^ [09:12] pedronis: thank you [09:16] #7906 +1 [09:16] PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check [09:16] thx [09:16] ctOS: had to do some local tweaking, try this in the snap shell: https://paste.ubuntu.com/p/wTw2SG4Pgz/ [09:17] ctOS: returns the same font inside and outside of snap shell here on arch [09:18] mborzecki: no go, $SNAP is empty [09:19] oh, /var/lib/snapd/snap/ [09:20] ctOS: you need to do `snap run --shell firefox` and then run those lines inside that shell [09:21] ctOS: outside of snap shell you can simply run `fc-match ` [09:21] PR snapd#7906 closed: o/devicestate,o/snapstate: move the gadget.yaml check [09:21] mborzecki: I just realized that. different output. one sec [09:22] mborzecki: FreeMono.ttf: "FreeMono" "Regular" [09:23] mborzecki: plus these errors https://paste.ubuntu.com/p/Smsh2ZP9sT/ [09:23] mborzecki: outside snap shell it’s: DejaVuSans.ttf: "DejaVu Sans" "Book" [09:25] degville: I looked at your last tweaks to the intro to Assertions, +1, thank you [09:26] degville: as I said we should also port that to the glossary [09:26] pedronis: will do, thanks for the review. [09:32] mborzecki: I'd ping kenvandine or oSoMoN for Mozilla things [09:34] heh, firefox has no contact info either, no clue where users can report any problems [09:36] 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] ctOS: can you run fc-match inside the snap shell but with FC_DEBUG=4 this time and post the output somewhere? [09:41] mborzecki: here you go https://paste.ubuntu.com/p/t995Sm9H8G/ [09:48] 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] mborzecki: no, but `/usr/share/fonts/dejavu/*` does. [09:52] mborzecki: here is `ls /usr/share/fonts/*/*` https://paste.ubuntu.com/p/4X3VyqKF43/ [09:53] 7918 needs a second review, should be a simple one [09:54] 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] 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] ctOS: and if you run fc-cache -f -v ? [10:03] mborzecki: https://paste.ubuntu.com/p/dpz4x3Q2VS/ [10:05] 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] perhaps someone from the desktop team will have ideas [10:12] 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] ctOS: afaik selinux wouldn't matter, you're probably running as unconfined_t anyway [10:47] mvo: little tweak in https://github.com/snapcore/snapd/pull/7918#discussion_r359275116 [10:47] PR #7918: boot: copy kernel/base to data partition in makeBootable20RunMode [10:47] mborzecki: thanks for all your time and troubleshooting help! [10:48] ctOS: np, these desktop things are ridiculously fragile [10:59] mborzecki: in a meeting right now, feel free to tweak and push [11:03] PR snapd#7935 opened: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot [11:04] mvo: mborzecki: Chipac: ^ [11:04] Chipaca: ^ (sorry) [11:04] pedronis: ack [11:05] 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] pedronis: yay! [11:08] pedronis: nice [11:08] 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] pedronis: ok, I will look at it today [11:09] pedronis: my uc20 bits are all proposed now so I should have time [11:09] (still want to start with spread stuff though) [11:10] 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] pedronis: amazing! let's aim for this before CPT [11:15] pedronis: should I add uc20 to 7935? [11:22] mvo: yes [11:24] done [11:29] * pstolowski lunch [11:50] 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] https://hg.mozilla.org/mozilla-central/rev/606408df5b4d712c7bf4e80621dd145f1cd82940 [11:53] 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] mborzecki: also bugs in ff snap should go to bugzilla afaik [12:20] PR snapd#7929 closed: boot: always return the trivial boot participant in ephemeral mode [12:23] 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] PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem [12:27] pedronis: the travis job is already running, but i can open a follow-up PR adding those tests [12:27] mborzecki: there are tests [12:27] mborzecki: that link points to tests [12:27] am I super confused ? [12:27] mvo added them [12:28] pedronis: uh, maybe I mixed something up [12:28] 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] mborzecki: ah, I misunderstood [12:29] mborzecki: at test would be good for that [12:29] mborzecki: I thought you were referring the whole function [12:29] 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] pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7930 ? [12:45] PR #7930: run-checks: complain about MATCH -v [12:46] pstolowski: and while at it, maybe this one too: https://github.com/snapcore/snapd/pull/7922 [12:46] PR #7922: packaging, tests: stop services in prerm [12:55] PR snapd#7936 opened: tests: unmount automounted snap-bootstrap devices [13:10] mborzecki, popey, oSoMoN: that should be fixed in beta [13:10] kenvandine: good to know, thanks! [13:10] ctOS: ^^ [13:11] Mozilla has updated the snap to use the gnome-3-28 extension in beta [13:11] and core18 [13:11] i haven't tried it yet though [13:11] hm maybe the fonts problem will go away too then [13:12] 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] mvo, hey, are proxy settings actually applied for 'snap download'? It seems to work for 'snap install', but not when downloading [13:16] mborzecki: will do [13:18] PR snapd#7930 closed: run-checks: complain about MATCH -v [13:20] pstolowski: thanks [13:53] PR snapd#7937 opened: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information [13:57] morning folks [14:00] PR snapd#7858 closed: tests: also check nested lxd container === ricab is now known as ricab|lunch [14:57] 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///issue/" when it should be "github.com///issues/" [14:59] ijohnson: Gustavo [15:00] niemeyer: can you change the links that mup outputs for new github issues filed? see my previous comment above, thanks [15:00] thanks pstolowski [15:02] * cachio lunch [15:06] PR snapd#7918 closed: boot: copy kernel/base to data partition in makeBootable20RunMode [15:11] PR snapcraft#2848 opened: common: generate run scripts which can execute independently [15:23] mborzecki: mvo: +1 to #7921 but the extra suite field is probably not needed [15:23] PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem [15:24] ijohnson: Ah, sure, thanks. Do you have a sample message? [15:24] niemeyer: sure I saw one yesterday I think, let me look [15:25] mup> Mup Pet Issue pc-amd64-gadget#30 opened: Git tags and versioning [15:25] Issue pc-amd64-gadget#30: Git tags and versioning [15:25] niemeyer: ^ [15:27] Thanks! [15:28] np, happy to help [15:29] pc-amd64-gadget#30 [15:29] Issue pc-amd64-gadget#30: Git tags and versioning [15:32] pedronis: thanks! I can kill it [15:34] mvo: maybe land the PR and cleanup in a followup? [15:34] (it's green right now) [15:38] matiasb_: works for me [15:38] mborzecki: works for me [15:38] matiasb_: sorry, wrong tab-complete [15:39] 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] mvo: +1 to #7931 with some comments, let me know if they are unclear [15:48] PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode === ricab|lunch is now known as ricab [15:51] pedronis: thanks! looking [15:52] pedronis: updated #7686 [15:52] PR #7686: systemd: handle preseed mode [15:52] pstolowski: thx, I'll try to look at it in a bit [15:52] PR snapd#7921 closed: devicestate: run boot.MakeBootable in doSetupRunSystem [15:53] pedronis: comments make sense I think, will fix in a wee bit [16:03] PR snapd#7938 opened: devicestate: advoid adding mockModel to deviceMgrInstallModeSuite [16:06] PR snapd#7936 closed: tests: unmount automounted snap-bootstrap devices [16:20] PR snapd#7939 opened: boot,o/devicestate: refactor MarkBootSuccessful over bootState [16:20] mmh, conflicts [16:22] anyone else getting schedule test errors in master? [16:23] 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] lunch, bbi30min [16:42] pstolowski: did anohter pass on #7686, some small issues [16:42] PR #7686: systemd: handle preseed mode [16:43] pedronis: thanks. yes, i can't believe pre-bake was still lurking, grr [16:46] 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] hm, maybe my spread git is too old [16:47] * mvo update to latest master [16:49] 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] mvo, I'll read a bit the documentation [16:58] ta [16:58] so far uefi should not be enabled [17:02] cachio: ok [17:02] cachio: will enable require a spread change? [17:02] mvo, I think we will need to update spread [17:02] mvo, yes [17:03] the change is simple because it is a parameter when the instance is created [17:04] I'll imeplmeent the change, is is a new parameter in the system [17:06] pedronis: updated, thanks again [17:06] cachio: ta [17:17] mvo, there is also a way to create the image with that enabled by default [17:18] I think this option is betetr [17:21] cachio: nice! [17:21] cachio: I did something hackish for qemu https://github.com/snapcore/spread/compare/master...mvo5:spread-with-uefi?expand=1 [17:22] 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] mvo, on gce there are 2 ways [17:22] for customized images like ours [17:22] it is possible to define is during their creation [17:22] cachio: cool [17:23] for predefined images during creation of the instance [17:23] cachio: I get dinner now, will check back in a bit [17:23] sure [17:26] 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] mvo, is it needed virtualization enabled on that image? [17:35] eod. happy holidays pedronis ! [17:35] pstolowski: thx [17:36] cu [17:47] PR pc-amd64-gadget#31 opened: grub.cfg: switch to new style kernel_status failover handling [17:52] cachio: this does not need anything special beside uefi, it's the same style of test as uc16/uc18 in spread [17:53] mvo, I am creating an image [17:53] cachio: cool! thanks [17:53]