=== devil is now known as Guest194 === genious is now known as genios === chihchun_afk is now known as chihchun === Guest194 is now known as devil_ [07:39] is there no "snap update" command, or will it update automagically? [07:40] svij: it's snap refresh [07:41] ah I see, is there no command to update all snaps, rather than one single with refresh? (I don't need it right now, just curious) [07:43] svij: it will be refresh, just not implemented yet [07:43] zyga: ah okay [07:43] thx [07:57] kyrofa, sergiusens: once you're both up, can we chat about the snapcraft sessions at UOS and get them scheduled? [08:02] jdstrand, zyga, about SDL2 failling with UDEV for Initialization of INIT_Joystick. That happens when calling "udev_monitor_new_from_netlink", and apparmor says : audit: type=1400 audit(1461830101.683:1127): apparmor="DENIED" operation="create" profile="snap.MyApp.app" pid=11228 comm="MyApp" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create" [08:02] (maybe I need to use the plug network ?) [08:02] slvn: I suspect that will stay denied for a while unless netlink support in apparmor is improved, for now I'd compile joystick support out [08:03] zyga, it's not blocking anyway.. joystick is just not initialized.. just report the issue [08:03] ah, ok [08:06] zyga, also audio was failing, but it's not *killing* the apps, it just stays not initialized. [08:13] zyga, just correcting myself, in fact, audio pulse if really failling (.shm_open() failed: Permission denied). So I need to desactivate it. [08:17] slvn: we know about audio, we'll get something supported, if you check the backlog we discussed this issue last night [08:17] slvn: there are still a few things to decide before that can happen but we do know about it [08:19] zyga, ok [08:45] about Mark shuttleworth's email : what's "GA" ? [08:48] ysionneau: general release? [08:48] A for Release ? :o [08:51] availability? :) [08:54] globally awesome release :) [08:55] hehe we also discussed the meaning of "GA" here :) [08:59] :) [09:00] General Availability [09:05] thanks [09:29] latest allsnaps: sudo snap remove trionet error: can't remove "trionet": cannot find mounted snap "trionet" at revision 100001 [09:29] :( [09:31] did work before, but at one time complained about: sudo snap remove trionet [-] Remove snap "trionet" from the system error: cannot perform the following tasks: - Remove snap "trio [09:31] and after reboot I am stuck [09:32] Gunther_: it's known broken for now [09:32] Gunther_: will be fixed with the next SRU [09:32] Gunther_: you can use my script to reset snap state: github.com/zyga/devtools [09:33] Gunther_: look at reset-state [09:33] ok thanks [09:33] Sorry for the bad experience [09:33] no problem, I am developer myself [09:38] zyga: worked great ;-) all snaps removed including the kernel (ooops) [09:38] Gunther_: ooops [09:38] Gunther_: this was tested on the desktop [09:39] Gunther_: it would need some love on devices [09:39] Gunther_: can you look at what would be needed to make it work there and fix it please [09:39] zyga: I ll try [09:40] oh, I just discovered a nice snap trick: https://bugs.launchpad.net/snappy/+bug/1574829/comments/1 [09:40] Launchpad bug 1574829 in Snappy "snappy install requires root or login, but doesn't tell you so" [Wishlist,Triaged] [09:40] snap without sudo [09:53] pitti: where is the rename of wlan0 to wlxXXXXXX done? I couldnt find the matching rule in udev [09:54] asac: in xenial release it is still /lib/systemd/network/90-mac-for-usb.link [09:55] ahh... /me was already thinking maybe its in systemd [09:55] asac: however, that will change soon (also in xenial) to /lib/udev/rules.d/73-special-net-names.rules due to bug 1574483 [09:55] bug 1574483 in systemd (Ubuntu Xenial) "assigns MAC-based names for devices with locally administered MAC address" [High,In progress] https://launchpad.net/bugs/1574483 [09:55] ok gotcha... let me study the .link file a bit though so i know how that works [09:56] asac: see /usr/share/doc/udev/README.Debian.gz [09:56] that still refers to a wrong name (01- instead of 90-) [09:57] My gnome-disks UI looks pretty hilarious after using snappy for a while. [10:53] _morphis: hey, you should be able to rebase n-m interface on top of https://github.com/ubuntu-core/snappy/pull/1078 now [10:53] <_morphis> zyga: awesome! [10:53] <_morphis> will do, thanks a lot for that! [10:54] _morphis: https://github.com/ubuntu-core/snappy/pull/1078/files#diff-939866a2238749d2c6989a8a757f430f [10:54] Hi, I use ubuntu since last 5 years. I came across about the snappy. I have dev embedded board, and i have a question now. Is it possible to get ubuntu core into the this embedded device ? [10:55] keestu: yes, you need a kernel that works there and a supported bootloader [10:55] keestu: though right now devices (boards) are in rapid development after 16.04 release so expect a lot of changes in the next few weeks [10:56] zyga, thanks, my knowledge is petty limited to this. I have a board, where we port android, linux with qt, how snappy is going to be different ? [10:57] keestu: if you have a working kernel, it should be not much different [10:57] keestu: the only requirement is a supported arch, what SoC [10:57] keestu: (you don't build snappy entirely from source,) [10:58] keestu: you just buld the kernel and gadget snaps, the rest is stock and shared by all devices [10:58] so, snappy is a way to get the customized desktop feel in embedded device ? [10:58] keestu: snappy has no desktop feel [10:58] keestu: anyway, please familiarize yourself with the documentation on snappy that's available on ubuntu.com now [10:59] zyga, i am looking at the business perspective. We see the customers demanding porting android to our embedded device. [10:59] zyga, sure. [11:00] * zyga -> lunch [11:00] :) === oparoz_ is now known as oparoz [11:00] bon appetit [11:15] zyga, another issue snap+SDL2+x11. At first install (after reset-state), it doesn't connect to x11. I need to remove the snap, then reinstall it. then it can connect to x11. The syslog error was "apparmor="DENIED" operation="connect" profile="snap.MyApp.app" pid=22559 comm="MyApp" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" [11:15] peer="unconfined" [11:20] ppisati, have you seen bug 1574103 ? [11:20] bug 1574103 in Snappy "Raspberry Pi 2 image LEDs are swapped." [Medium,New] https://launchpad.net/bugs/1574103 [11:20] and bug 1574075 might also be interesting [11:20] bug 1574075 in Snappy "Snappy does not detect Sagem wifi dongle" [Medium,New] https://launchpad.net/bugs/1574075 [12:03] dholbach I will have to rain check on that and ask for it to be in a couple of hours; both kyrofa and myself are unavailable right now [12:08] sergiusens, can parts/files have dynamic values? [12:08] like "somelib: /usr/lib/$(ARCH)/somelib"? [12:08] sergiusens, hey btw :-) [12:19] slvn: fyi, you need to plugs either unity7 or x11. did it not autoconnect? [12:25] jdstrand, both are in the plugs list (and also opengl) of the snapcraf.yaml file [12:26] maybe the reset-state script is incomplete ? [12:26] slvn: would you mind filing a bug for that? show your snapcraft.yaml, how you installed, the denial and the policy in /var/lib/snapd/apparmor/profiles/snap.MyApp.app [12:27] first install -> x11 doesn't work. then remove, and install again. it works [12:27] slvn: and please add that detail :) [12:28] jdstrand, yep. I go away now, but I will re-try that later and fill a report. [12:28] slvn: thanks. others have seen this but I don't think there is a bug [12:29] jdstrand, if first install always fail to launch, it's kind of problematic for me :) [12:29] slvn: very much indeed :) [12:29] can I package an erlang app with snappy and do hot code upgrade? [12:30] jdstrand, but i'll double check later and let you know! ++ [12:30] upgrade the code while the app is till running? [12:30] sergiusens, I'll have to leave at 16:00 or 16:15 UTC today - it'd be good if we could talk about it before [12:42] slvn: you can always connect manually but I'm wondering why auto-connect did not work [12:42] slvn: thanks, I'll investigate this [13:05] Snapcraft Q: is there a variable representing the install stage path that I can, for example, pass to a makefile to tell the target where to install into [13:05] ? [13:07] zyga: just confirm, if i change something in snap, go build it and snapd, copy over and fire up snapd...i should see the change i made in snap? [13:08] * kgunn swears he saw this before, hopes he's not going crazy [13:08] kgunn: in a meeting, you need to copy snapd (and restart it, devtools helps) [13:08] kgunn: for security changes disconnect and reconnect [13:08] zyga: was doing pkill -9 snapd, then starting [13:08] wesleymason, $SNAPCRAFT_STAGE [13:09] not really [13:09] kgunn: try github.com/zyga/devtools [13:09] there are more bits and magic there [13:09] and it's all made for this use case [13:09] oparoz: great, cheers [13:09] zyga: ok [13:09] so i can't just go build snap/snapd, copy over? [13:10] you can but you need more, devtools does all that [13:10] and more :-) [13:10] try it [13:10] ok, i may need help, cause my vm i use for mir isn't the standard one [13:10] syure [13:10] sure* [13:10] mainly ssh config i suppose [13:11] Is there a recommended way to use start-stop-daemon in init scripts? Default policy doesn't allow scripts to call it [13:12] first of all you would have to ship it in your snap :) [13:13] (and then i dont think it would be accepted or used at all in the end ... given we use systemd in snappy ) [13:14] ogra_, I get "access denied", so it must be there, just not allowed. The way I understand it is that systemd calls whatever start script is given to it, so it shouldn't be an issue to call this command, no? [13:15] zyga: actually...i got it....devtools talking to my vm, i see devtools.snap in there :) [13:15] relying on magic now [13:15] oparoz, it is a tool from sysvinit scripts ... it should really not be used at all in systemd envs [13:16] jdstrand, zyga, is there a recommended way to do service logging in snappy? My location-service snap is trying to create /var/log/location-service which obviously isn't going to work [13:16] kgunn: cool, just use refresh-bits (it has --help and is trivial to read) [13:16] ssweeny: I don't think there is one, maybe just let systemd manage logging [13:16] ssweeny: but I don't really know [13:16] zyga, ok, thanks [13:16] ssweeny, "snappy service logs" used to do that ... [13:16] kgunn: I will gladly take patches for new features [13:16] zyga: hmmm, with latest tools...do i have to sudo snap for such things as "snap list" ? [13:16] i would expect that to be back once the snap service command comes back [13:16] kgunn: yes, because the socket is root-owned [13:17] kgunn: or chmod 666 /path/to/socket (/var/snapd.socket AFAIR) [13:17] kgunn: it's not handled by devtools because I was always lazy and using sudo [13:17] that's right...i see a note [13:17] ok, fully relying on devtools...and i still don't see my mod [13:17] kgunn: if you get it supported, just send me a patch please, I was annoyed by this once and there was one bug hidden by this already [13:17] kgunn: what's the mod about? policy change? [13:18] kgunn: you should connect/disconnect or remove/install the snap because there is no logic that detects interface implementation changes yet [13:18] kgunn: you should also check generated profiles (/var/lib/snapd/{apparmor,seccomp}/profiles [13:19] ssweeny: if you want your own log, you need to change the path to somewhere in SNAP_DATA [13:19] jdstrand, yeah that was my other thought [13:20] jdstrand: hey, gustavo recommended that we work on making n-m interface supported on the desktop; it would also unblock a bunch of prospective snaps; can you tell me if the current policy there is safe for desktop use? [13:20] ssweeny: (if you don't want systemd to handle it-- with systemd it will capture stdout and stderr and you can use journalctl to see the output from your service) [13:20] jdstrand: isn't there a command line to list interfaces? [13:20] jdstrand: (just comment on the pull request anytime you have a moment to look at it) [13:20] i thot i recalled that...couldn't find the email [13:20] kgunn: snap interfaces [13:20] dang it...soo simple [13:20] shoulda guessed [13:20] :-) [13:21] does anyone know if parts/files have dynamic values? [13:21] like "somelib: /usr/lib/$(ARCH)/somelib"? [13:21] jdstrand, ah so I can just change logging to stdout and stderr and systmd will take care of it for me? cool [13:21] seb128: I don't think they do [13:21] :-( [13:21] seb128, kyrofa: or sergiusens would know [13:21] seb128: what are you trying to build? [13:21] they are not around though [13:21] a GTK app [13:21] seb128: you can use $SNAP_ARCH [13:21] seb128: it's an env variable we set [13:21] to install thing? [13:21] ssweeny: note, it will also show up in syslog, but yes [13:21] seb128: you'd have to do a wrapper for it though [13:21] (or patch gtk) [13:21] at build time? [13:21] seb128: no, at runtime [13:22] that doesn't interet me [13:22] seb128: for build-time i don't know [13:22] (I'm hacking on the other side) [13:22] seb128: I'd recommend starting with amd64, then working with snapcraft hackers to generalize [13:22] zyga: re nm-- we had a rather lengthy discussion on that at the eod yesterday but I didn't think we came to a conclusion. but to specifically answer your queston, no, the nm policy is not safe for confined apps-- it grants too much privilege [13:23] seb128: for the runtime part I think we should perhaps explore patching some bits to understand snap runtime layout [13:23] jdstrand: ok, could we do a simple version for now that still works on the desktop and land that, iterating on a broader one using some other ways (attributes, more ifaces) [13:23] zyga, I'm on i386 so starting with amd64 is not going to work for me :p [13:23] jdstrand: I think the key is to ensure that we don't leave the desktop as we progress [13:24] seb128: oh, sorry [13:24] seb128: i386 is fine though, it's just a suggestion to try to solve the simpler problem first [13:24] right [13:24] well I've the arch coded [13:24] but I wanted to push that so jdstrand and others can play with it [13:24] zyga: I feel like I am missing context. we left it yesterday that we need more discussion for the desktop case [13:24] but it sucks if everyone needs to sed the arch before building [13:25] jdstrand: I just talked about this in the standup, gustavo recommended that we ensure it works on the desktop before it lands [13:25] well, then I need to understand the direction [13:25] zyga: did niemeyer_ comment in the pr? [13:25] jdstrand: checking [13:27] jdstrand: nope [13:27] there's the community sync in 3 minutes [13:27] let's continue that after if you have time, otherwise let's do it by email [13:28] zyga: email is probably best so everyone has context [13:31] did anyone look at snap and translations? [13:31] what would be the right place to discuss the topic/put notes? [13:31] list? launchpad pad? spec? === chihchun is now known as chihchun_afk [13:34] seb128, UOS ? :) [13:39] ogra_: ack [13:40] ogra_, right, because that's going to be useful if nobody of the snappy team is interested and joining [13:41] is there any plan to mount some part of the snaps to normal system locations? [13:41] rather than trying to make everything reallocatable? [13:42] mvo, hey, do you know if it somebody discussed making locales part of the core image before? [13:43] i think that was discussed and deemed to be to space hungry [13:44] (given it was designed for embedded without actual users) [13:44] seb128: I doub't that [13:44] (not relocatable) [13:44] zyga, :-( [13:44] seb128, i suspect we're moving into -pd territory ... [13:44] ogra_, are such gaps documented somewhere? launchpad bugs? [13:44] not that i know of ... [13:45] seb128: I think that would be against the idea of snappy [13:45] but i personally wouldnt see locales as something to have in core ... [13:45] ogra_, you would see each application needing to ship the libc locale definition? [13:46] + to patch glib to allow relocating those [13:47] hi there, i am snapping a system monitor tool and i wonder what plugs would be necessary to access /proc/vmstat and a given /etc file like /etc/mtab... is there one? [13:49] seb128, well, a snap *has to be* completely inependend from the core system,. they always need to be separately upgradeable ... [13:49] thats one of the base definitions of snappy [13:50] ogra_, with, snaps don't have to ship their own libc, do they? [13:50] they can [13:50] but don"t have to? [13:50] thats the one thing they could use ... but nothing stops you to ship your own [13:51] well, shipping your translations, fine [13:51] having to ship the glibc locale definitions [13:51] I doubt it's something any appdev is going to want [13:51] also glibc doesn't support relocating those [13:52] well, but shipping them in core means you add a dependency [13:52] depends to what? [13:52] snaps depends on the core anywhy [13:52] anyway [13:52] between the system and the snap [13:53] i.e. what if glibc locale handling code changes in incompatible ways in the system snap [13:53] you would need something liek a versioned dependency [13:59] ogra_, you are saying "what if glibc changed in an incompatible way", but that's already an issue since you don't force snaps to ship a copy of glibc [14:00] sure [14:01] if you have this stance it's fine, but then be consistent and force snaps to include a libc copy [14:01] niemeyer, which time between 14 and 20 UTC would work for you for an interface session next week (3-5 May)? [14:01] zyga, ^ too [14:01] if you allow them to rely on the core one there is no point to say that can only be for some parts of libc [14:02] dholbach: any except standups but I'm flexible [14:02] seb128, right, the "it is useless on headless IoT systems without users" thing is still valid though ... [14:02] we'd need two core setups [14:02] unsure [14:03] you might want your ls, etc to be in german [14:03] which ls ? [14:03] your commands on the core [14:03] on my router i only have that web UI :P [14:03] well, you might want that webui in german [14:03] on my drone i even only have that mobnile app that talks to it [14:03] * zyga checks backlog [14:04] sure, but for that i dont need glibc locales necessarily [14:04] right [14:04] we need frameworks :p [14:04] good idea ! [14:04] seb128: though ogra was spot on on pocket-desktop area, I think on personal the core snap could provide you with a gtk runtime interface [14:04] uh [14:04] seb128: so if you want that runtime to be something you depend on, great, but I don't know if that's exactly what we want to do with gkt [14:04] a whiole runtime is to much imho [14:04] seb128: perhaps for SDK runtime first [14:05] seb128: we don't need frameworks, we need interfaces [14:05] seb128: anything that a framework could do is doable with a new interface [14:05] can an interface snap add files to /var and /lib in your snap mount? [14:06] seb128: an interface can let a snap do this [14:06] seb128: we still don't have hooks, when we get them from new state engine we'll be able to react to all actions (connect, etc) [14:06] seb128: if you tell me more about the problem perhaps I could suggest a solution [14:07] zyga, trying to get translations working in my snap [14:07] which requires to have locales generated in /usr/lib/locale/locale-archive [14:08] that can be relocated [14:08] by then gettext tries to read from /usr/share/locale:/usr/share/langpack-locale [14:08] which can't be relocated [14:08] but as an appdev I don't want to have to learn how to generate libc locales [14:09] seb128: the appdev part should be solved with snapcraft support [14:09] I guess we could teach snapcraft to generate those though [14:09] that still doesn't solve the fact that glibc doesn't let you relocate/specify another dir to load the .mo [14:10] out of patching glibc's code and rebuilding glibc as part of your snap [14:10] seb128: doesn't textdomaindir do that? [14:10] no [14:10] it works only for the gettext command line [14:10] I mean [14:10] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114461 [14:10] Debian bug 114461 in gettext "gettext: there is no way to control where message catalogs are found at run time" [Normal,Open] [14:10] bindtextdomain [14:10] zyga, no [14:10] why not? it seems to do just that? [14:11] (assuming you build an app from source) [14:11] well [14:11] right, I'm repackaging a deb [14:11] ah, right [14:11] but then if you do that [14:11] for deb-repacking I agree [14:11] what if need also strings from libc [14:11] +you [14:11] what is the domain used by libc? [14:11] this feels like a SDK runtime problem [14:11] locale generation is perhaps more subtle [14:12] libc.mo [14:12] SDK sort of [14:12] but I think a snap developer should just end up with a bunch of .mo files [14:12] that they can even filter out if they want [14:12] gettext() is not specific to a SDK [14:12] yes, but SDK should just solve it for people [14:12] for just fishing parts of binary debs, it feels tricky [14:12] it could [14:12] so back to interfaces [14:12] we could design an interface that lets you do bind mounts and other magic [14:13] I just wonder if that's a solution (it doesn't feel like one) [14:14] yeah, maybe not [14:14] maybe we just make those part of pd [14:14] and declare that core users can't have translations [14:14] basic locales? I would say yes [14:14] core users will probably use webapps [14:14] and if not, they can bundle the world if they want a custom kiosk localized GUI [14:15] well, I guess as long as we provide easy tools to help them to bundle the world... [14:15] it still feels to me that locales are a base feature of the OS and shouldn't have to be bundle [14:15] I think we should explore both sides, patching sources to understand snap runtime layout and environment variables and reach for low-hanging fruit [14:15] but it's a good point that they take space and are not needed on a core [14:16] eventually I would hope that all important upstream projects have a getenv("SNAP") somewhere [14:16] is having the deb repackaging case working a goal [14:16] and that they just work [14:16] or just something hacking we play with? [14:16] that depends on if the upstreams support snap internally :) === _morphis is now known as morphis [14:16] yeah, I don't agree with that [14:17] I think our patches to n-m weren't merged [14:17] projects shouldn't have to getenv for platform specifc hacks [14:17] but if they were ,you could repackage nm (or be closer to) instead of having to build it [14:17] seb128: I somewhat disagree, this is a big shift [14:17] seb128: relocatability [14:17] seb128: nothing really supports that out of the box yet [14:17] perhaps it is not SNAP, perhaps SNAP Is in some common platform glue [14:17] sergiusens: ping [14:18] but patching upstreams for native relocatability would be worth-while IMHO [14:22] Spin up a new autopkgtest machine that uses "dpkg --instdir=/relocated/" to install. [14:24] jdstrand: I have an app doing "Bad system call" inside a snap, in dmesg I see an apparmor failure with sig=31 arch=40000003 syscall=45 compat=1 ip=0xf77e3547 code=0x0 - is this something I can work around, a bug, or something else? [14:24] * zyga looks [14:24] Oh, popey. So innocent. [14:25] wat wat wat [14:25] that's shmctl [14:25] scmp_sys_resolver 45 [14:25] run that [14:25] popey: on the device do 'scmp_sys_resolver 45' [14:25] Hey seb128 dholbach I'm around now [14:25] zyga, how do you know ? it varies between arches ;) [14:25] popey: it must be on the device/vm [14:25] ogra_: yes, true, I checked for amd64 [14:26] jdstrand: inside the snap? [14:26] brb [14:26] :) [14:26] this is on my laptop [14:26] zyga, it is brk on armhf [14:26] zyga, ogra_: note the syscall numbers are different depending on the arch [14:26] (amd64) [14:26] popey: ok, on amd64 that should be recvfrom [14:26] yes [14:27] popey: you need to plug one of network, x11 or unity7 [14:27] popey: if you are, autoconnecting isn't working for you [14:27] I have all 3 [14:27] plugs: [x11, network, network-bind, unity7, opengl] [14:27] popey: right, my understanding is that removing and installing again will get it to connect [14:27] popey: otherwise you can manually connect [14:28] zyga: I asked slvn to file a bug for that, but I think he had to step away. do you have a bug for this? ^ is it known to you? [14:28] jdstrand: removing "it" as in, the snap? [14:28] popey: yes [14:29] jdstrand, that's 32 bits code on amd64, unsure if that makes a difference? [14:29] zyga: in other news, I figured out why the unintended bluez change ended up in my branch and have adjusted my processes [14:29] if I understood popey correctly [14:29] seb128: I think you just confused me :) [14:29] he had a seccomp denial [14:30] right, I'm just saying that he's multiarching [14:30] so I just asked that he run scmp_sys_resolver on whatever architecture logged the denial [14:30] k [14:30] multiarch doesn't matter [14:30] I was mentioning in case [14:30] thanks [14:30] np [14:31] bah! got into the state where I have to nuke and pave again :( [14:31] :-( [14:31] hey kyrofa [14:32] is there a way to tell snapcraft to rebuild without wipping out the deb cache? [14:32] seb128: I ended up installing apt-cacher-ng on my laptop [14:32] popey, :-( [14:32] seb128: feel free to point your apt at my laptop as a proxy ㋛ [14:32] but thanks for the tip [14:32] seb128, you can clean individual steps of the lifecycle-- would that help? [14:33] (I appreciate you may not want to) [14:33] seb128, instead of cleaning the pull, just clean back to build [14:33] kyrofa, I ended up reworking my yaml but that feels like a workaround [14:33] kyrofa, oh ok [14:33] seb128, essentially instead of cleaning everything, you say "don't wipe out the pulled stuff." [14:33] I ended up having 2 parts [14:33] and cleaning only one [14:34] I didn't know that my issue was due to "cleaning the pull" [14:34] or that was a thing [14:34] thanks [14:34] seb128, no problem! Yeah try `snapcraft clean -s build` (by default it cleans everything, including the pull step) [14:34] that sounds like a poor default :p [14:34] kyrofa, thanks! [14:36] kyrofa, thanks... I was wondering if sergiusens, you and I could pick dates/times for the snapcraft UOS sessions [14:37] we're still very much free to pick times between 14 and 20 UTC on 3-5 May [14:37] dholbach, yeah sounds good. sergiusens is running a few errands right now and I have a meeting in a few minutes, but after that I'm free all day [14:43] Argh, "sudo snap install mylocalfoo.snap" on a clean box will download ubuntu core, fail to install it, fail to download my local snap from the store, but install my local one anyway, without ubuntu-core. So next time I try something it tries to download ubuntu-core again! [14:43]