| 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> | 01:52 |
|---|---|---|
| wadedy | Anyone have any experience with nextcloud on ubuntu server 18? | 02:39 |
| 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:03 |
| pedronis | mvo: morning | 06:39 |
| 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> | 06:51 |
| 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:08 |
| mvo | pedronis: we avoid the double build | 07:13 |
| mvo | pedronis: its slow | 07:13 |
| mvo | pedronis: like really slow | 07:13 |
| mvo | pedronis: we could look into cheating somehow, i.e. build the snap from a binary deb | 07:14 |
| 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:15 |
| mvo | pedronis: good point, I have no looked at what part takes how long. but that sounds plausible | 07:16 |
| 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:19 |
| 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:21 |
| mvo | pedronis: yeah, the travis log tells a similar story, about 10min | 07:24 |
| pedronis | also indeed we do build it anyway, in the snapd-snap test | 07:26 |
| pedronis | mvo: our quick tests take 6 mins | 07:28 |
| 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:30 |
| 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:32 |
| 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:33 |
| * mvo nods | 07:35 | |
| 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:41 |
| pedronis | but the build can be run by spread I suppose | 07:42 |
| 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:43 |
| 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:44 | |
| 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:46 |
| 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:47 |
| 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:48 |
| pedronis | I'm using the revisions for 2.38.1+git1331.gc314589 | 07:49 |
| pedronis | 3211-3216 | 07:49 |
| mvo | ta | 07:51 |
| 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:26 |
| Chipaca | pedronis: got a question about 'snap refresh --list --cohort=xyzzy a_snap' | 08:40 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| pedronis | we'll need to update the docs to say not yet implemented though | 08:59 |
| * Chipaca hands pedronis the Red Seal of Not Implemented | 09:01 | |
| mvo | looks like the snapd snap is finally happy again for cmd.CommandFromSystemSnap (yay) | 09:02 |
| 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:03 |
| mvo | degville: thanks for letting us know | 09:04 |
| * Chipaca agrees degville should avoid going postal | 09:04 | |
| * degville has been going postal for around 3 years now. | 09:06 | |
| Chipaca | oh dear | 09:36 |
| * 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:37 |
| Chipaca | 329 characters long | 09:38 |
| Chipaca | wide i mean | 09:38 |
| pedronis | that is a workflow problem on my side, so I should fix it, but hard | 10:03 |
| 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:15 |
| Chipaca | hmmm, otoh it explodes the helpers | 10:18 |
| Chipaca | but that might be unavoidable | 10:19 |
| Chipaca | hmm, hmm, hmm | 10:19 |
| * Chipaca hmms more | 10:19 | |
| * Chipaca goes for coffee | 10:19 | |
| === hunterk_ is now known as hunterk | ||
| === lfaraone_ is now known as lfaraone | ||
| pedronis | Chipaca: not a big fan of Spec, but we use it elsewhere | 10:42 |
| pedronis | so seems ok | 10:42 |
| pedronis | Chipaca: in the client code the same thing is just called SnapOptions though fwiw | 10:43 |
| Chipaca | pedronis: but that's because it's not update-specific (tho why not UpdateOptions) | 10:47 |
| pedronis | Chipaca: yes, that was more my point, most of things are Options | 11:15 |
| 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:17 |
| 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:19 |
| pedronis | Chipaca: mvo: will automatic snapshots be in 2.39 ? | 11:50 |
| pedronis | or is it 2.40 ? | 11:50 |
| === ricab is now known as ricab|lunch | ||
| 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:55 |
| 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:56 |
| pedronis | Chipaca: thanks, will try to understand more at the standup | 11:57 |
| Chipaca | ok | 11:57 |
| 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:58 |
| * Chipaca ⇝ runch | 11:59 | |
| * Chipaca steals ideas from twom | 12:00 | |
| 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:20 |
| 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:23 |
| cmatsuoka | sergiusens: yes, but currently snapcraft doesn't like build-aux/snap/plugins, mind if I fix that? | 12:24 |
| 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 | 12:25 |
| === ricab|lunch is now known as ricab | ||
| === stgraber_ is now known as stgraber | ||
| mvo | cmatsuoka: x-builddeb is still working | 13:10 |
| wis | Hey, does the ubuntu core support wifi on RPI2, by adding wireless adapter interfaces of a wifi adapter? | 13:42 |
| wis | how can I connect to wifi with a wifi adapter on Ubuntu Core on RPI2? | 13:47 |
| Chipaca | wis: i'd ask ogra :-) | 13:51 |
| 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:03 |
| 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:06 |
| 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:10 |
| 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:11 |
| Chipaca | I was so, so wrong about a change to Update's arity breaking less tests | 14:12 |
| * Chipaca perseveres | 14:12 | |
| 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:17 |
| 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:18 |
| pedronis | they can be the same layer | 14:19 |
| pedronis | it depends on details | 14:19 |
| pedronis | :) | 14:19 |
| Chipaca | pedronis: i think we're looking for a yes/no answer | 14:20 |
| pedronis | it's possible, I'm still unclear where/who do make this contexts | 14:21 |
| 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:22 |
| 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:23 |
| Chipaca | mvo: ^ that means daemon's search hits store.Find and store.SnapInfo fwiw | 14:24 |
| mvo | Chipaca: ok, I will look at the context then | 14:26 |
| * mvo pokes hard at some tests first | 14:26 | |
| 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:27 |
| 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:30 |
| pedronis | store.UseContext(request (can be nil)) context.Context | 14:31 |
| pedronis | or something like that | 14:31 |
| 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:33 |
| 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:37 |
| 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:38 |
| 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:39 |
| wis | okay I'll do it over ssh and If it fails I don't mind reinstalling at this point. | 14:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| wis | it looks like serial requires a USB to serial adapter which I don't have, so i'll just reinstall. | 14:52 |
| Chipaca | wis: keyboard and screen? :-) | 14:56 |
| Chipaca | wis: or just reinstall :-) | 14:56 |
| 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:00 |
| 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:13 |
| 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:23 | |
| 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:25 |
| ogra | yup, it should ... you will definitely know it if your user creation worked | 15:26 |
| 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:27 |
| 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:29 |
| wis | on a second though I think I can just use the raspberry.local hostname | 15:30 |
| mup | PR snapd#6815 opened: snapstate: auto-install snapd when needed (2.39) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6815> | 15:31 |
| 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:36 |
| Chipaca | and then, *then*, I'm going to EOW | 15:38 |
| Chipaca | like a BOSS | 15:39 |
| Chipaca | pedronis: vvv | 15:45 |
| 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:46 | |
| wis | wohoo, ping cern.org returns results with ethernet disconnected. Linux always surprises for good with out-of-box drivers. | 15:50 |
| wis | although the default (non-cloudflare) dns was concerningly slow | 15:54 |
| === sarnold_ is now known as sarnold | ||
| 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:09 |
| pedronis | mvo: ^ | 16:16 |
| 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:20 |
| Chipaca | pedronis: I'm off, see you wednesday! | 16:21 |
| Chipaca | pedronis: (but telegram in emergencies) | 16:21 |
| pedronis | Chipaca: bye, have fun | 16:21 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| mvo | jdstrand: ok | 16:36 |
| * mvo needs to get some dinner | 16:36 | |
| jdstrand | mvo: enjoy :) | 16:36 |
| mup | PR snapd#6818 opened: snapshotstate: disable automatic snapshots on core for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6818> | 17:32 |
| 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> | 17:38 |
| * cachio afk | 18:12 | |
| cmatsuoka | niemeyer: hi, any news on the extension review? | 19:28 |
| niemeyer | cmatsuoka: Sorry, got distracted elsewhere.. I'll get to it first thing in the morning tomorrow | 19:30 |
| cmatsuoka | niemeyer: thanks! sorry for being annoying about that, but it's in our plans for lyon to have these properly merged :) | 19:32 |
| niemeyer | cmatsuoka: Not annoying at all.. I apologize as I should have done it earlier in the week | 19:33 |
| 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> | 21:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!