[01:52] PR snapcraft#2545 closed: catkin plugin: use build-packages for compilers [02:39] Anyone have any experience with nextcloud on ubuntu server 18? [06:03] PR snapd#6809 closed: snapcraft.yaml: fix links ld-linux-x86-64.so.2/ld64.so.2 [06:39] mvo: morning [06:51] PR snapd#6812 opened: snapcraft: also include ld.so.conf from libc in the snapcraft.yml [07:08] 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] pedronis: we avoid the double build [07:13] pedronis: its slow [07:13] pedronis: like really slow [07:14] pedronis: we could look into cheating somehow, i.e. build the snap from a binary deb [07:15] mvo: but the slow parts are probably not snapd, no? they are likely building the font cache stuff? [07:15] just installing the fc build deps takes forever [07:16] pedronis: good point, I have no looked at what part takes how long. but that sounds plausible [07:19] 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] pedronis: we could try with snapcraft cleanbuild or similar [07:21] mvo: so the build on LP takes 10 minutes (for amd64) [07:21] if I'm looking right: https://code.launchpad.net/~snappy-dev/+snap/snapd-master/+build/546252 [07:24] pedronis: yeah, the travis log tells a similar story, about 10min [07:26] also indeed we do build it anyway, in the snapd-snap test [07:28] mvo: our quick tests take 6 mins [07:30] 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] and then use it in the integration stage [07:30] pedronis: yeah, that sounds very reasonable [07:32] pedronis: we would have to have some external mechanism for the data sharing, I guess we can just GCE for this (?) [07:32] pedronis: but I like this a lot, two jobs that build deb/snap and then pass it on to the integration stage [07:32] there are probably multiple options [07:33] also I think if we had a 16.04 prepared image with the right packages [07:33] that 10 minutes would go down a bit [07:35] * mvo nods [07:41] 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] (a bit of work though) [07:41] mvo: yes, and yes it's some work [07:42] but the build can be run by spread I suppose [07:43] it's basically the snapd-snap test [07:43] pedronis: indeed [07:43] plus putting the build somewhere [07:43] and using a dedicated system/image [07:43] pedronis: this way we can optimize the build-deps and give it a machine with lots of horse-power(?) [07:43] don't know about the latter [07:43] but for sure we can have a build image [07:43] with more packages [07:43] +1 [07:44] 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] heh [07:46] it's more complexity, so not so excited, but also the current approach is fragile, which is my main worry here [07:46] yeah [07:47] I mean fragile in the sense that tests pass and shouldn't [07:47] mvo: I need to revert snapd edge again [07:47] indeed, thats how I understood it [07:47] pedronis: I thought I had done this already, if not I have it in my history [07:47] it gets build again [07:48] pedronis: so can run it now [07:48] I have done it [07:48] thanks [07:48] also I think the version you mention on TG were a bit off [07:48] 6812 should *finally* fix it [07:48] pedronis: oh? was I wrong there, sorry for that [07:48] one was from a different tag [07:49] I'm using the revisions for 2.38.1+git1331.gc314589 [07:49] 3211-3216 [07:51] ta [08:26] PR snapd#6812 closed: snapcraft: also include ld.so.conf from libc in the snapcraft.yml [08:40] pedronis: got a question about 'snap refresh --list --cohort=xyzzy a_snap' [08:53] Chipaca: yes? [08:53] 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] the a_snap will get quietly ignored and you'll get a list of everything [08:54] what is doubly specified? [08:54] 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] pedronis: because cohort implies snap name [08:55] Chipaca: it doesn't for us [08:55] nor for the store really [08:55] you need to send the name and the cohort [08:55] can't just send the cohort [08:55] hi, is there a way to include a deb not from the archive in a snap, similarly to what stage-packages do? [08:56] pedronis: sigh, ok. But still, there isn't a good way to send anything. [08:56] pedronis: I could add client-side filtering to 'snap refresh --list' [08:56] if that is what we want [08:57] actually a_snap is not quietly ignored: you get 'error: --list does not accept additional arguments' [08:57] Chipaca: to be quite frank I'm not sure why we though implementing snap refresh --list [08:57] as part of find [08:57] was a good idea [08:57] pedronis: i totally agree [08:57] i'd much rather it were dry-run, on the refresh endpoint [08:58] yea [08:58] so we can do that [08:58] not as part of cohorts work though [08:58] (and maybe at some point deprecate the other thing) [08:58] i'll leave this bit of wrk for after this refactor [08:58] and move on with the rest [08:58] Chipaca: yes [08:59] 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] looks like the snapd snap is finally happy again for cmd.CommandFromSystemSnap (yay) [09:03] (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] 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] oh dear [09:37] * Chipaca LARTs pedronis [09:37] * Chipaca also LARTs github for not highlighting this [09:37] Chipaca: ? [09:37] pedronis: commit message with lines that are … dunno, 200+ chars long? [09:37] 'git log' is now a mess [09:38] 329 characters long [09:38] wide i mean [10:03] that is a workflow problem on my side, so I should fix it, but hard [10:15] 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] Update explodes the test a lot less than Install does so i'm going with the refactor inline [10:18] hmmm, otoh it explodes the helpers [10:19] but that might be unavoidable [10:19] hmm, hmm, hmm [10:19] * Chipaca hmms more [10:19] * Chipaca goes for coffee === hunterk_ is now known as hunterk === lfaraone_ is now known as lfaraone [10:42] Chipaca: not a big fan of Spec, but we use it elsewhere [10:42] so seems ok [10:43] Chipaca: in the client code the same thing is just called SnapOptions though fwiw [10:47] pedronis: but that's because it's not update-specific (tho why not UpdateOptions) [11:15] Chipaca: yes, that was more my point, most of things are Options [11:17] PR snapd#6813 opened: data: update XDG_DATA_DIRS via the systemd environment.d mechanism too [11:19] yep, going with that [11:19] hoping it doesn't explode in my face now :-) [11:19] i need to take a break, go for a walk, and have lunch [11:19] ttfn [11:50] Chipaca: mvo: will automatic snapshots be in 2.39 ? [11:50] or is it 2.40 ? === ricab is now known as ricab|lunch [11:55] pedronis: it's tagged 2.39 [11:55] pedronis: e.g. #6669 [11:55] PR #6669: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) [11:56] pedronis: there's some related PRs that weren't tagged 2.39 but they merged earlier than that one [11:56] e.g. #6727 [11:56] PR #6727: data/selinux: allow snapd to execute runuser under snappy_t [11:56] without that ^ snapshots on selinux are wonky [11:57] Chipaca: thanks, will try to understand more at the standup [11:57] ok [11:58] 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] 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] PR snapcraft#2550 opened: storeapi: move from details (v1) to info (v2) [12:23] cmatsuoka: what, the entire idea behind build-aux was to be able to drop that :-) [12:24] sergiusens: yes, but currently snapcraft doesn't like build-aux/snap/plugins, mind if I fix that? [12:25] (i.e. it gets snapcraft.yaml from build-aux/snap, but plugins are still loaded from snap/plugins) [12:25] cmatsuoka: yes, please do [12:25] okeydokey === ricab|lunch is now known as ricab === stgraber_ is now known as stgraber [13:10] cmatsuoka: x-builddeb is still working [13:42] Hey, does the ubuntu core support wifi on RPI2, by adding wireless adapter interfaces of a wifi adapter? [13:47] how can I connect to wifi with a wifi adapter on Ubuntu Core on RPI2? [13:51] wis: i'd ask ogra :-) [14:03] 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] PR snapd#6814 opened: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) - 2.39 [14:06] PR snapd#6755 closed: overlord/snapstate: tweak autorefresh logic if network is not available [14:10] PR snapd#6638 closed: interfaces: add support for the snapd snap in the dbus backend [14:11] PR snapd#6802 closed: overlord/ifacestate: update static attributes of "content" interface <⚠ Critical> [14:12] I was so, so wrong about a change to Update's arity breaking less tests [14:12] * Chipaca perseveres [14:17] 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] mvo: I heard yes, in that it's not the ideal but it's ok [14:18] but maybe pedronis can confirm [14:18] (ideal is when it's the same layer stuffing and unpacking the values [14:18] ) [14:18] Chipaca: excellent, I think that is what he said as well [14:19] they can be the same layer [14:19] it depends on details [14:19] :) [14:20] pedronis: i think we're looking for a yes/no answer [14:21] it's possible, I'm still unclear where/who do make this contexts [14:22] 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] ok [14:22] pedronis: alternative approach would be to add the ua to store.Search [14:22] it's not only for search [14:23] anyway atm only UpdateMany takes a context [14:23] 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] pedronis: yes it's not only search, search is just the first one [14:23] (search also covers 'snap info' fwiw) [14:23] 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] mvo: ^ that means daemon's search hits store.Find and store.SnapInfo fwiw [14:26] Chipaca: ok, I will look at the context then [14:26] * mvo pokes hard at some tests first [14:27] 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] 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] 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] pedronis: aha, that makes sense [14:31] store.UseContext(request (can be nil)) context.Context [14:31] or something like that [14:33] 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] 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] well, then it should be properly set up already [14:38] if you were able to advance to the user creation your network should be properly set up [14:38] it's connected to ethernet too [14:38] console-conf uses the network connecion when creating the user ... so if that worked your wlan worked too [14:38] is there a way to redo the console-conf after first boot? [14:39] ah, try to do the initial config without plugged in ethernet then [14:39] I'll need to reinstall to do that? [14:39] 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] okay I'll do it over ssh and If it fails I don't mind reinstalling at this point. [14:41] 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] after all re-installing core is pretty quick [14:41] oh right.. I need ethernet for ssh [14:42] wis: or you could use serial [14:42] 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] 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] else you wont get a login prompt ... local consoles are only enabled if a password exists [14:43] (and serial is considered a local console) [14:52] it looks like serial requires a USB to serial adapter which I don't have, so i'll just reinstall. [14:56] wis: keyboard and screen? :-) [14:56] wis: or just reinstall :-) [15:00] 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] :D [15:13] PR snapd#6778 closed: snapstate: auto-install snapd when needed [15:23] 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] 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] yup, it should ... you will definitely know it if your user creation worked [15:27] 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] 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] on a second though I think I can just use the raspberry.local hostname [15:31] PR snapd#6815 opened: snapstate: auto-install snapd when needed (2.39) [15:36] 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] so quality might be iffy [15:36] but, maybe it's fine :-D [15:38] and then, *then*, I'm going to EOW [15:39] like a BOSS [15:45] pedronis: vvv [15:46] PR snapd#6816 opened: daemon, overlord: support for cohort-key in refresh and switch [15:46] * Chipaca soft-EODs, getting ready to leave but still paying some attention to IRC [15:50] wohoo, ping cern.org returns results with ethernet disconnected. Linux always surprises for good with out-of-box drivers. [15:54] although the default (non-cloudflare) dns was concerningly slow === sarnold_ is now known as sarnold [16:09] PR snapd#6817 opened: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate [16:16] mvo: ^ [16:20] 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] installing htop* [16:21] pedronis: I'm off, see you wednesday! [16:21] pedronis: (but telegram in emergencies) [16:21] Chipaca: bye, have fun [16:32] 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] 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] jdstrand: uh, that will make a difference I suppose, snap debug timings should give us some data here [16:34] 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] mvo: ie, even if you skip it now and forego the daemon user feature, you'd get it in your next sru [16:35] mvo: that said, people seem keen to fix it, so we could always sru those changes when they mature [16:36] jdstrand: ok [16:36] * mvo needs to get some dinner [16:36] mvo: enjoy :) [17:32] PR snapd#6818 opened: snapshotstate: disable automatic snapshots on core for now [17:38] PR snapcraft#2547 closed: [legacy] catkin spread test: allow python2 as well as python [18:12] * cachio afk [19:28] niemeyer: hi, any news on the extension review? [19:30] cmatsuoka: Sorry, got distracted elsewhere.. I'll get to it first thing in the morning tomorrow [19:32] niemeyer: thanks! sorry for being annoying about that, but it's in our plans for lyon to have these properly merged :) [19:33] cmatsuoka: Not annoying at all.. I apologize as I should have done it earlier in the week [21:12] PR snapcraft#2546 closed: [legacy] catkin plugin: ensure cxxflags are consistent