[01:52] <mup> PR snapcraft#2545 closed: catkin plugin: use build-packages for compilers <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2545>
[02:39] <wadedy> Anyone have any experience with nextcloud on ubuntu server 18?
[06:03] <mup> PR snapd#6809 closed: snapcraft.yaml: fix links ld-linux-x86-64.so.2/ld64.so.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6809>
[06:39] <pedronis> mvo: morning
[06:51] <mup> PR snapd#6812 opened: snapcraft: also include ld.so.conf from libc in the snapcraft.yml <Created by mvo5> <https://github.com/snapcore/snapd/pull/6812>
[07:08] <pedronis> mvo: on the systems where we do repack_snapd we could also build with snapcraft, no ? are we just trying to avoid the double build?
[07:13] <mvo> pedronis: we avoid the double build
[07:13] <mvo> pedronis: its slow
[07:13] <mvo> pedronis: like really slow
[07:14] <mvo> pedronis: we could look into cheating somehow, i.e. build the snap from a binary deb
[07:15] <pedronis> mvo: but the slow parts are probably not snapd, no? they are likely building the font cache stuff?
[07:15] <pedronis> just installing the fc build deps takes forever
[07:16] <mvo> pedronis: good point, I have no looked at what part takes how long. but that sounds plausible
[07:19] <mvo> pedronis: another part of the problem is that for a realisitic test the snapd test has to be build in a 16.04 environment (gcc/toolchain etc). however then it needs to run on all distros
[07:19] <mvo> pedronis: we could try with snapcraft cleanbuild or similar
[07:21] <pedronis> mvo: so the build on LP takes 10 minutes (for amd64)
[07:21] <pedronis> if I'm looking right: https://code.launchpad.net/~snappy-dev/+snap/snapd-master/+build/546252
[07:24] <mvo> pedronis: yeah, the travis log tells a similar story, about 10min
[07:26] <pedronis> also indeed we do build it anyway, in the snapd-snap test
[07:28] <pedronis> mvo: our quick tests take 6 mins
[07:30] <pedronis> mvo: there is some argument to be made that maybe it would make sense to build our most used deb and the snap in the quick phase
[07:30] <pedronis> and then use it in the integration stage
[07:30] <mvo> pedronis: yeah, that sounds very reasonable
[07:32] <mvo> pedronis: we would have to have some external mechanism for the data sharing, I guess we can just GCE for this (?)
[07:32] <mvo> pedronis: but I like this a lot, two jobs that build deb/snap and then pass it on to the integration stage
[07:32] <pedronis> there are probably multiple options
[07:33] <pedronis> also I think if we had a 16.04 prepared image with the right packages
[07:33] <pedronis> that 10 minutes would go down a bit
[07:35]  * mvo nods
[07:41] <mvo> pedronis: I poked a bit, it looks like we need sergio and/or gustavo to setup a GCS bucket to upload the builds into but then this looks doable
[07:41] <mvo> (a bit of work though)
[07:41] <pedronis> mvo: yes, and yes it's some work
[07:42] <pedronis> but the build can be run by spread I suppose
[07:43] <pedronis> it's basically the snapd-snap test
[07:43] <mvo> pedronis: indeed
[07:43] <pedronis> plus putting the build somewhere
[07:43] <pedronis> and using a dedicated system/image
[07:43] <mvo> pedronis: this way we can optimize the build-deps and give it a machine with lots of horse-power(?)
[07:43] <pedronis> don't know about the latter
[07:43] <pedronis> but for sure we can have a build image
[07:43] <pedronis> with more packages
[07:43] <mvo> +1
[07:44] <mvo> pedronis: this will be super nice because for 6 workers we don't need to build snapd 6 times anymore :)
[07:44]  * mvo is a bit excited
[07:46] <pedronis> heh
[07:46] <pedronis> it's more complexity, so not so excited, but also the current approach is fragile, which is my main worry here
[07:46] <mvo> yeah
[07:47] <pedronis> I mean fragile in the sense that tests pass and shouldn't
[07:47] <pedronis> mvo: I need to revert snapd edge again
[07:47] <mvo> indeed, thats how I understood it
[07:47] <mvo> pedronis: I thought I had done this already, if not I have it in my history
[07:47] <pedronis> it gets build again
[07:48] <mvo> pedronis: so can run it now
[07:48] <pedronis> I have done it
[07:48] <mvo> thanks
[07:48] <pedronis> also I think the version you mention on TG were a bit off
[07:48] <mvo> 6812 should *finally* fix it
[07:48] <mvo> pedronis: oh? was I wrong there, sorry for that
[07:48] <pedronis> one was from a different tag
[07:49] <pedronis> I'm using the revisions for 2.38.1+git1331.gc314589
[07:49] <pedronis> 3211-3216
[07:51] <mvo> ta
[08:26] <mup> PR snapd#6812 closed: snapcraft: also include ld.so.conf from libc in the snapcraft.yml <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6812>
[08:40] <Chipaca> pedronis: got a question about 'snap refresh --list --cohort=xyzzy a_snap'
[08:53] <pedronis> Chipaca: yes?
[08:53] <Chipaca> pedronis: two things: one, that's doubly-specifying a thing (right?), and two, we don't even support 'snap refresh --list a_snap' today
[08:54] <Chipaca> the a_snap will get quietly ignored and you'll get a list of everything
[08:54] <pedronis> what is doubly specified?
[08:54] <Chipaca> in fact, because for hysterical reasons 'snap refresh --list' is actually 'snap find --select=refresh', there isn't a good way to specify snaps to limit it to
[08:55] <Chipaca> pedronis: because cohort implies snap name
[08:55] <pedronis> Chipaca: it doesn't for us
[08:55] <pedronis> nor for the store really
[08:55] <pedronis> you need to send the name and the cohort
[08:55] <pedronis> can't just send the cohort
[08:55] <ackk> hi, is there a way to include a deb not from the archive in a snap, similarly to what stage-packages do?
[08:56] <Chipaca> pedronis: sigh, ok. But still, there isn't a good way to send anything.
[08:56] <Chipaca> pedronis: I could add client-side filtering to 'snap refresh --list'
[08:56] <Chipaca> if that is what we want
[08:57] <Chipaca> actually a_snap is not quietly ignored: you get 'error: --list does not accept additional arguments'
[08:57] <pedronis> Chipaca:  to be quite frank I'm not sure why we though implementing snap refresh --list
[08:57] <pedronis> as part of find
[08:57] <pedronis> was a good idea
[08:57] <Chipaca> pedronis: i totally agree
[08:57] <Chipaca> i'd much rather it were dry-run, on the refresh endpoint
[08:58] <pedronis> yea
[08:58] <pedronis> so we can do that
[08:58] <Chipaca> not as part of cohorts work though
[08:58] <pedronis> (and maybe at some point deprecate the other thing)
[08:58] <Chipaca> i'll leave this bit of wrk for after this refactor
[08:58] <Chipaca> and move on with the rest
[08:58] <pedronis> Chipaca: yes
[08:59] <pedronis> we'll need to update the docs to say not yet implemented though
[09:01]  * Chipaca hands pedronis the Red Seal of Not Implemented
[09:02] <mvo> looks like the snapd snap is finally happy again for cmd.CommandFromSystemSnap (yay)
[09:03] <degville> (I've just got to head out to vote in a local council election (thought I was registered for postal, but it appears not)).
[09:04] <mvo> degville: thanks for letting us know
[09:04]  * Chipaca agrees degville should avoid going postal
[09:06]  * degville has been going postal for around 3 years now.
[09:36] <Chipaca> oh dear
[09:37]  * Chipaca LARTs pedronis 
[09:37]  * Chipaca also LARTs github for not highlighting this
[09:37] <pedronis> Chipaca: ?
[09:37] <Chipaca> pedronis: commit message with lines that are … dunno, 200+ chars long?
[09:37] <Chipaca> 'git log' is now a mess
[09:38] <Chipaca> 329 characters long
[09:38] <Chipaca> wide i mean
[10:03] <pedronis> that is a workflow problem on my side, so I should fix it, but hard
[10:15] <Chipaca> pedronis: what'd be a good name for a struct with all options of snapstate.Update? going with snapstate.UpdateSpec as a strawman (it contains everything in current update args plus cohort, except state and user)
[10:15] <Chipaca> Update explodes the test a lot less than Install does so i'm going with the refactor inline
[10:18] <Chipaca> hmmm, otoh it explodes the helpers
[10:19] <Chipaca> but that might be unavoidable
[10:19] <Chipaca> hmm, hmm, hmm
[10:19]  * Chipaca hmms more
[10:19]  * Chipaca goes for coffee
[10:42] <pedronis> Chipaca: not a big fan of Spec, but we use it elsewhere
[10:42] <pedronis> so seems ok
[10:43] <pedronis> Chipaca: in the client code the same thing is just called SnapOptions though fwiw
[10:47] <Chipaca> pedronis: but that's because it's not update-specific (tho why not UpdateOptions)
[11:15] <pedronis> Chipaca: yes, that was more my point, most of things are Options
[11:17] <mup> PR snapd#6813 opened: data: update XDG_DATA_DIRS via the systemd environment.d mechanism too <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6813>
[11:19] <Chipaca> yep, going with that
[11:19] <Chipaca> hoping it doesn't explode in my face now :-)
[11:19] <Chipaca> i need to take a break, go for a walk, and have lunch
[11:19] <Chipaca> ttfn
[11:50] <pedronis> Chipaca: mvo: will automatic snapshots be in 2.39 ?
[11:50] <pedronis> or is it 2.40 ?
[11:55] <Chipaca> pedronis: it's tagged 2.39
[11:55] <Chipaca> pedronis: e.g. #6669
[11:55] <mup> PR #6669: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6669>
[11:56] <Chipaca> pedronis: there's some related PRs that weren't tagged 2.39 but they merged earlier than that one
[11:56] <Chipaca> e.g. #6727
[11:56] <mup> PR #6727: data/selinux: allow snapd to execute runuser under snappy_t <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6727>
[11:56] <Chipaca> without that ^ snapshots on selinux are wonky
[11:57] <pedronis> Chipaca: thanks, will try to understand more at the standup
[11:57] <Chipaca> ok
[11:58] <Chipaca> i might be a bit late for the standup, i need to pick up the dog from the vet and the timing is a little close
[11:59]  * Chipaca ⇝ runch
[12:00]  * Chipaca steals ideas from twom
[12:20] <cmatsuoka> mvo: is https://github.com/snapcore/snapd/blob/master/parts/plugins/x_builddeb.py#L27 still working? I think we'll be able to drop that using base: core
[12:23] <mup> PR snapcraft#2550 opened: storeapi: move from details (v1) to info (v2) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2550>
[12:23] <sergiusens> cmatsuoka: what, the entire idea behind build-aux was to be able to drop that :-)
[12:24] <cmatsuoka> sergiusens: yes, but currently snapcraft doesn't like build-aux/snap/plugins, mind if I fix that?
[12:25] <cmatsuoka> (i.e. it gets snapcraft.yaml from build-aux/snap, but plugins are still loaded from snap/plugins)
[12:25] <sergiusens> cmatsuoka: yes, please do
[12:25] <cmatsuoka> okeydokey
[13:10] <mvo> cmatsuoka: x-builddeb is still working
[13:42] <wis> Hey, does the ubuntu core support wifi on RPI2, by adding wireless adapter interfaces of a wifi adapter?
[13:47] <wis> how can I connect to wifi with a wifi adapter on Ubuntu Core on RPI2?
[13:51] <Chipaca> wis: i'd ask ogra :-)
[14:03] <ogra> wis, the kernel is the same as the one for classic ubuntu pi images, all wifi usb plugs that one supports are also supported by core
[14:03] <mup> PR snapd#6814 opened: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) - 2.39 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6814>
[14:06] <mup> PR snapd#6755 closed: overlord/snapstate: tweak autorefresh logic if network is not available <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6755>
[14:10] <mup> PR snapd#6638 closed: interfaces: add support for the snapd snap in the dbus backend  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6638>
[14:11] <mup> PR snapd#6802 closed: overlord/ifacestate: update static attributes of "content" interface <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6802>
[14:12] <Chipaca> I was so, so wrong about a change to Update's arity breaking less tests
[14:12]  * Chipaca perseveres
[14:17] <mvo> Chipaca: while I wait for some spread run - did we agree to pass the user-agent via a context? I heard yes just wanted to double check
[14:17] <Chipaca> mvo: I heard yes, in that it's not the ideal but it's ok
[14:18] <Chipaca> but maybe pedronis can confirm
[14:18] <Chipaca> (ideal is when it's the same layer stuffing and unpacking the values
[14:18] <Chipaca> )
[14:18] <mvo> Chipaca: excellent, I think that is what he said as well
[14:19] <pedronis> they can be the same layer
[14:19] <pedronis> it depends on details
[14:19] <pedronis> :)
[14:20] <Chipaca> pedronis: i think we're looking for a yes/no answer
[14:21] <pedronis> it's possible, I'm still unclear where/who do make this contexts
[14:22] <Chipaca> pedronis: this would be: daemon creates the context, stuffs it with a value for the ua, and then store.Find takes a context, and unstuffs the value
[14:22] <pedronis> ok
[14:22] <Chipaca> pedronis: alternative approach would be to add the ua to store.Search
[14:22] <pedronis> it's not only for search
[14:23] <pedronis> anyway atm only UpdateMany takes a context
[14:23] <Chipaca> pedronis: in both cases, with a mind on this being the pattern we'd also use later from the sync bits of refresh/install/info/etc
[14:23] <Chipaca> pedronis: yes it's not only search, search is just the first one
[14:23] <Chipaca> (search also covers 'snap info' fwiw)
[14:23] <wis> orga: I noticed that by ls ing the /lib/firmware and my device's firmware is there (ath9k_htc, Chipset: Atheros AR7010 & AR9287)
[14:24] <Chipaca> mvo: ^ that means daemon's search hits store.Find and store.SnapInfo fwiw
[14:26] <mvo> Chipaca: ok, I will look at the context then
[14:26]  * mvo pokes hard at some tests first
[14:27] <wis> orga: but it's not being listed by: $ nmcli d wifi list and $ ip a show's it's (wlan0)'s state is down
[14:30] <pedronis> Chipaca: mvo: to be clear it will be the same layer talking to itself because we probably want a helper in store that takes a request and makes a context
[14:30] <wis> I followed these docs: docs.ubuntu.com/core/en/stacks/network/network-manager/docs/configure-wifi-connections and wiki.debian.org/WiFi/HowToUse#WPA-PSK_and_WPA2-PSK
[14:30] <mvo> pedronis: aha, that makes sense
[14:31] <pedronis> store.UseContext(request (can be nil)) context.Context
[14:31] <pedronis> or something like that
[14:33] <ogra> wis, well, i never use NM on core ... you dont see the device inn console-conf ? (the UI that comes up on first boot and lets you set up the user and netwrok config)
[14:37] <wis> orga, I did, and configured the wifi by selecting the ssid and entering the passhphrase (although I'm not sure if correctly because I did't see what I was typing carefully and there was no option to show the characters)
[14:37] <ogra> well, then it should be properly set up already
[14:38] <ogra> if you were able to advance to the user creation your network should be properly set up
[14:38] <wis> it's connected to ethernet too
[14:38] <ogra> console-conf uses the network connecion when creating the user ... so if that worked your wlan worked too
[14:38] <wis> is there a way to redo the console-conf after first boot?
[14:39] <ogra> ah, try to do the initial config without plugged in ethernet then
[14:39] <wis> I'll need to reinstall to do that?
[14:39] <ogra> you can try "sudo console-conf" when logged in via ssh ... but be aware that it does not allow you to ctrl-C it, you can not get out anymore if you do not finish it properly
[14:40] <wis> okay I'll do it over ssh and If it fails I don't mind reinstalling at this point.
[14:41] <ogra> and indeed if you ssh you can not easily cancel the ethernet ... since you need to use it ... the easier alternative is surely a re-install
[14:41] <ogra> after all re-installing core is pretty quick
[14:41] <wis> oh right.. I need ethernet for ssh
[14:42] <Chipaca> wis: or you could use serial
[14:42] <ogra> in any case, if you see a wlan0 device during console-conf your wlan should theoretically work.., at least from the kernel/driver side
[14:42] <ogra> if you want to use serial, make sure to set a password for the user .. do: "sudo passwd $USER" to set one (and use the $USER variable there)
[14:43] <ogra> else you wont get a login prompt ... local consoles are only enabled if a password exists
[14:43] <ogra> (and serial is considered a local console)
[14:52] <wis> it looks like serial requires a USB to serial adapter which I don't have, so i'll just reinstall.
[14:56] <Chipaca> wis: keyboard and screen? :-)
[14:56] <Chipaca> wis: or just reinstall :-)
[15:00] <wis> same way I did it the first time, flash sd card, plug keyboard, hdmi and boot, only with ethernet disconnected, .. and more careful typing.
[15:00] <wis> :D
[15:13] <mup> PR snapd#6778 closed: snapstate: auto-install snapd when needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6778>
[15:23] <wis> I can't enter a forward slash (/) in the subnet mask field, only numbers and dots, despite requiring it in CIDR format
[15:23]  * cachio lunch
[15:25] <wis> the good news is that with ethernet disconnected my routers SSID displayed and I selected it, that means the wifi adapter is working.
[15:26] <ogra> yup, it should ... you will definitely know it if your user creation worked
[15:27] <ogra> the forward slash is probably a bug with console-conf input filtering (most people simply use DHCP and dont fiddle with the netmasks, so it is likely that nobody did hit that issue yet)
[15:29] <wis> good to know that I helped find a bug, I'll use dhcp for now and do a nmap scan to find the RPi's ip each time it changes, to be able to ssh
[15:30] <wis> on a second though I think I can just use the raspberry.local hostname
[15:31] <mup> PR snapd#6815 opened: snapstate: auto-install snapd when needed (2.39) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6815>
[15:36] <Chipaca> pedronis: i'm going to push the updates pr, which is nominally done, but i haven't gone over it to make sure it doesn't have any think'os
[15:36] <Chipaca> so quality might be iffy
[15:36] <Chipaca> but, maybe it's fine :-D
[15:38] <Chipaca> and then, *then*, I'm going to EOW
[15:39] <Chipaca> like a BOSS
[15:45] <Chipaca> pedronis: vvv
[15:46] <mup> PR snapd#6816 opened: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
[15:46]  * Chipaca soft-EODs, getting ready to leave but still paying some attention to IRC
[15:50] <wis> wohoo, ping cern.org returns results with ethernet disconnected. Linux always surprises for good with out-of-box drivers.
[15:54] <wis> although the default (non-cloudflare) dns was concerningly slow
[16:09] <mup> PR snapd#6817 opened: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/6817>
[16:16] <pedronis> mvo: ^
[16:20] <wis> after reinstalling and installing snap available memory is 770MB. I know that core is a stripped down server. how does the baseline memory consumption compare?
[16:20] <wis> installing htop*
[16:21] <Chipaca> pedronis: I'm off, see you wednesday!
[16:21] <Chipaca> pedronis: (but telegram in emergencies)
[16:21] <pedronis> Chipaca: bye, have fun
[16:32] <jdstrand> mvo: hey, so, I'm not done testing yet (it has so far been going fine), but libseccomp 2.4 has a performance regression: https://github.com/seccomp/libseccomp/issues/153
[16:33] <jdstrand> mvo: 'real0m0.083s' with 2.38 template policy and 2.3.1 vs 'real0m0.242s' with 2.38 policy and 2.4.1
[16:34] <mvo> jdstrand: uh, that will make a difference I suppose, snap debug timings should give us some data here
[16:34] <jdstrand> mvo: I mention this as an fyi since the security team plans to push libseccomp 2.4.1 out to fix the CVE and bad bpf generation anyway
[16:35] <jdstrand> mvo: ie, even if you skip it now and forego the daemon user feature, you'd get it in your next sru
[16:35] <jdstrand> mvo: that said, people seem keen to fix it, so we could always sru those changes when they mature
[16:36] <mvo> jdstrand: ok
[16:36]  * mvo needs to get some dinner 
[16:36] <jdstrand> mvo: enjoy :)
[17:32] <mup> PR snapd#6818 opened: snapshotstate: disable automatic snapshots on core for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6818>
[17:38] <mup> PR snapcraft#2547 closed: [legacy] catkin spread test: allow python2 as well as python <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2547>
[18:12]  * cachio afk
[19:28] <cmatsuoka> niemeyer: hi, any news on the extension review?
[19:30] <niemeyer> cmatsuoka: Sorry, got distracted elsewhere.. I'll get to it first thing in the morning tomorrow
[19:32] <cmatsuoka> niemeyer: thanks! sorry for being annoying about that, but it's in our plans for lyon to have these properly merged :)
[19:33] <niemeyer> cmatsuoka: Not annoying at all.. I apologize as I should have done it earlier in the week
[21:12] <mup> PR snapcraft#2546 closed: [legacy] catkin plugin: ensure cxxflags are consistent <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2546>