[00:00] yeah that's what I thought, too [00:00] you might be right that it's due to unpacking the stage packages but it takes an inordinately long time [00:01] something seems screwey because a single cpu core is pegged at 100% usage (not parallelised in any way) [00:04] Well, it uses the apt python API, so yeah, that sounds right [00:26] kyrofa: hey can i talk to you about patchelf? :) [01:26] PR snapcraft#2060 opened: package: ensure all relevant files are in for sdist [05:12] morning [05:17] hey hey [05:17] good morning [05:17] there's going to be a thunderstorm this evening :) [05:17] I cannot wait for that, I really missed them [05:19] yeah, relaly can't wait for the first power outage this year [05:21] ouch, do you think it will come to that? [05:21] I was used to power outages in Spain when it was raining [05:21] but not used to them here even when there's a very fierce storm [05:21] right where i live there's an outage almost every time there's a thunderstorm [05:22] otoh living in deep suburbs/almost country has some benefits too [05:23] someone raised a really nice idea in the forum: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/102 [05:23] yes, that's a nice idea [05:23] mobile data == restrict downloads [05:24] need to look at the implementation, whether the setting is exposed over dbus and if so which bus it is [05:24] mvo: morning [05:24] mborzecki: it's dconf/gconf most likely [05:24] good morning mvo [05:24] zyga: looks like networkmanager https://bug792608.bugzilla-attachments.gnome.org/attachment.cgi?id=366968 [05:25] or libnm for that matter [05:26] * zyga goes to make breakfast for the kids [05:28] that's nice, if it's nm, then we could poke it through dbus [05:30] hey mborzecki and zyga ! good morning [05:39] PR snapd#5017 closed: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket (2.32) [06:08] * zyga needs to pay some taxes but will be back to work shortly [06:25] mvo: hey [06:26] PR snapd#5019 closed: data/selinux: Give snapd access to more aspects of the system (2.32) [06:27] mvo: about 2.32.4, it seems we have some number of PRs open [06:27] is the goal to land that today? [06:36] pedronis: you mentioned the snap roadmap page on the forum was a bit outdated/confusing, I updated it now, let me know if there is anything left that looks inconsistent or wrong [06:36] zyga: not necessarily today but I think it would be good to prepare a 2.32.4 soon. we need to wait a little bit with the new api merge until we are sure that we don't need a .4 for .3 [06:37] zyga: (if that makes sense) [06:37] hehe, Yes [06:43] anyone wants to take a quick look at #5003, trivial change [06:43] PR #5003: cmd/snap-seccomp: graceful handling of non-multilib host [06:44] ? [06:45] mborzecki: sure [06:45] it'd be great if we could put it in .4 too, would allow me to drop a patch in the packacing [06:45] mvo: thanks :) [06:50] zyga: what is the version of fontconfig that breaks compatibility? [06:55] hmm btrfs on 4.14.26-54.32.amzn2.x86_64, shutting down lxc container produces this: kernel https://paste.ubuntu.com/p/kp842QyGng/ [07:00] mborzecki: 2.13 [07:00] mborzecki: I'm going afk now (dog) but once back I can give you a reference to thebug report [07:00] hm i have local/fontconfig 2.13.0+10+g58f5285-1 here [07:01] zyga: heh, see what you mean, https://paste.ubuntu.com/p/cyxSH6cwVB/ saw that earlier and assumed that it's something with spotify snap [07:03] zyga: it's not 'crashing' though === pstolowski|afk is now known as pstolowski [07:11] morning [07:15] PR snapd#5020 opened: errtracker: check for whoopsie.service instead of reading /etc/whoopsie [07:16] good morning o/ [07:21] hey kalikiana [07:25] Mborzecki: the reporter on one arch derivative saw crashes [07:25] Hey kalikiana [07:25] zyga: maybe it's some specific snap, spotify seems to work [07:26] Perhaps [07:26] I’m still outside, I’ll sit in a coffee shop soon [07:41] PR snapd#5014 closed: overlord/snapstate: introduce envvars to control the channels for bases and prereqs [07:55] moin moin [07:56] Hey hey John [08:04] PR snapd#5021 opened: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) [08:04] mvo: I created a backport of the envvars branch ^ [08:05] #5018 needs a 2nd review [08:05] PR #5018: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps [08:11] mvo: about roadmap: I see a formatting problem with USB hotplug status emoji ... also in 2.32 feeding cloud-init and CDN aware are the same I think [08:11] re [08:15] pedronis: I'll review 5018 next [08:16] zyga: checking for metered connection should be easy, just loooking at this prop on the main nm object https://developer.gnome.org/NetworkManager/unstable/gdbus-org.freedesktop.NetworkManager.html#gdbus-property-org-freedesktop-NetworkManager.Metered [08:17] mborzecki: should snapd do that check directly? [08:18] zyga: yeah, that's there it makes most sense probably [08:18] what would happen on a core device that uses network-manager for networking [08:19] snapd would have to understand that that endpoint is down when the n-m snap is inactive for instance [08:19] zyga: the values of NMMeteres are somewhat funny https://developer.gnome.org/NetworkManager/unstable/nm-dbus-types.html#NMMetered, NM_METERED_GUESS_NO, heh [08:19] (or that a device may be only and always on metered connection) [08:19] we would need some gadget config or core config to ignore this [08:19] also there might be no NM as well [08:20] no NM is easy to handle [08:20] I wonder how it determines the guess [08:21] anyway it sounds like it needs a design forum post [08:21] yes, definitely [08:22] feels like a "snap set system refresh.metered = "always | priority | never" thing [08:22] with gadget control as well [08:23] `connection.metered: unknown`, that's for my wifi connection [08:24] but i can explicitly mark it as metered [08:24] zyga: are you on a modem now? [08:24] mwhudson: yo [08:24] yes [08:25] Chipaca: hello [08:25] mwhudson: my go snap auto-refreshed and now sigsegvs [08:25] mborzecki: do you want me to check? [08:25] zyga: can you do 'nmcli c show --active', the pick the uuid and `nmcli c show `, look for connection.metered [08:25] sure [08:25] Chipaca: refresh again and it should break [08:25] *unbreak [08:25] mwhudson: ok :-) how so? [08:25] Chipaca: patchelf is bad? [08:25] Chipaca: https://forum.snapcraft.io/t/patchelf-broke-my-binary/4928 [08:26] mwhudson: sigh. ok. [08:26] mborzecki: it's a bit dumb [08:26] it'll unbreak just because i published the old version again [08:26] nmcli being dumb about metered https://www.irccloud.com/pastebin/UbF7cxGb/ [08:26] mborzecki: I wonder if it is in any way confused by the presence of the LXD bridge [08:26] mwhudson: except now the store is timing out [08:27] (╯°□°）╯︵ ┻━┻ [08:27] mborzecki: I don't see any way to mark the connection as metered from the gui [08:27] zyga: hm, aren't you on gnome 3.28? [08:27] mborzecki: and I don't see why it would not be marked as metered, pretty much all GSM/3G/4G/LTE is metered some way [08:28] mborzecki: I'm on bionic now [08:28] that's 3.28 [08:28] zyga: hm `nmcli c modify connection.metered true` should mark it [08:28] hmm, something's going on in the dc [08:28] pedronis: ok, thanks, I will fix that [08:29] yeah canonical irc is flapping [08:29] hmm [08:29] (process:14018): libnmc-CRITICAL **: 10:29:11.195: file clients/common/nm-meta-setting-desc.c: line 765 (): should not be reached [08:29] that + the assertions endpoint timing out [08:29] mborzecki: ^ that's from "show" [08:29] mborzecki: after the manual change [08:30] metered connection (after manually tweaking the value) https://www.irccloud.com/pastebin/lBCN8dLI/ [08:30] zyga: woow ;) [08:30] zyga: can you do `busctl --system introspect org.freedesktop.NetworkManager /org/freedesktop/NetworkManager` and look for .Metered ? [08:30] sure [08:30] so i have this binary in stage, it works, the one in prime breaks [08:30] oh, busctl is a new thing to me [08:31] Chipaca: is connectivity, I think they are making it worse to make it better, but it got worse than unexpected [08:31] *than expected [08:31] systemd :0 [08:31] or `busctl --system get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered` [08:31] if i take the staged one and run strip --remove-section .note.go.buildid and patchelf --set-interpreter /snap/core/current/lib64/ld-linux-x86-64.so.2 it still works [08:31] wtf is going on [08:31] I wait for malware that is called something like ${crap}ctl to seem like another part of systemd [08:31] zyga: yeah, but it's easier to use than dbus-send [08:31] ah snapcraft does RPATH things as well [08:32] zyga@t470:~$ busctl --system introspect org.freedesktop.NetworkManager /org/freedesktop/NetworkManager | grep Metered [08:32] .Metered property u 1 emits-change [08:32] zyga: at least UX wise, just seems to do the right thing [08:32] mborzecki: yeah, no doubt about that [08:32] mborzecki: it's pretty nice [08:32] mborzecki: we could subscribe to changes of that property [08:32] mborzecki: read it [08:32] mborzecki: and then carry on [08:32] mborzecki: it feels like connectivty manager in overlord [08:32] ok, so now it's showing metered = 1 -> NM_METERED_YES according to the NM dbus spec [08:32] mborzecki: it could also monitor offline/online status [08:33] ok can repro [08:33] zyga: yes [08:33] and eventually it could understand the set of snaps responsible for network being up [08:33] zyga: i've actually used it in that camera boards i've shown you the photos of ;) [08:33] and expose that to snapmgr [08:33] yeah [08:34] mborzecki: ok, let me know if you need any more testing [08:34] mborzecki: as an intereseting use case [08:34] mborzecki: all off office.zygoon.pl is on a metered connection [08:34] mborzecki: from a router that has metered wifi [08:34] ha, wonder how it figured that out [08:34] well, the wifi/lan is metered as it is routerd through the LTE [08:35] mborzecki: nothing figures that out yet [08:35] but there's some part of the wifi spec that can convey this fact [08:35] perhaps through DHCP but I really don't know [08:35] but I read that gnome or maybe androind wants to support that [08:35] mborzecki: if you want to play on my office LAN I can make an account for you [08:35] (if it touches any of IEEE standards then it's better not to know) [08:36] zyga: thanks but no need for now ;) just wanted to get the general picture [08:37] sure :) [08:37] zyga: btw. i've updated #4989 [08:37] PR #4989: tests: add arch to CI [08:37] I'll finish review of 5018 and then start chopping my WIP user mounts branch [08:37] mborzecki: thanks, I'll check soon [08:43] http://omgfoss.com/install-spotify-linux-ubuntu-debian-fedora/ [08:43] this is cute :) [08:44] https://www.irccloud.com/pastebin/kAgEqb8f/ [08:46] zyga: funny how they skipped the 'snap install spotify' step [08:47] oh [08:47] indeed [08:47] hahaa [08:47] that's even more silly [08:48] :) [08:48] pedronis: was playing with the performance of unserialising an entry of a json object last night [08:48] pedronis: I've got another reason to move to go 1.7+ [08:48] :-) [08:48] * zyga found the "chronic" utility from moreutils [08:57] Caelum: I added LEAP 15 to https://build.opensuse.org/project/show/system:snappy [08:58] fmt.Println("baz == other type", foo["zed"] == "dez") [08:58] w8, but spotify is not a classic snap, no need for the symlink [08:58] aand copy pasted some random sample with comparing interfaces i was preparing for jdstrand's review :) [08:59] no, but if you're installing snapd for the first time, you might want to do that for future classic snaps you may install [08:59] zyga: can we land #4980? [08:59] PR #4980: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" [08:59] mborzecki: yes [08:59] let's [09:00] this unblocks cachio's work on fedora-on-google [09:00] PR snapd#4980 closed: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" [09:05] pedronis: reviewed 5018 [09:27] thx, I expended the comments a bit [09:32] heh, expanded [09:34] pedronis: thank you [09:35] how can I interrupt/restart travis job that's stuck somewhere since yesterday? https://github.com/snapcore/snapd/pull/4940 [09:35] PR #4940: RFC: added UDevMonitor for future hotplug support [09:42] Chipaca: well that was fun to chase down https://github.com/NixOS/patchelf/issues/146 [09:43] pstolowski: let me look [09:43] ah [09:44] that's more interesting, there's no link [09:44] mwhudson: nice spelunking [09:44] looks like travis broke there [09:44] can you se that branch via travis itself? [09:45] Chipaca: patchelf is .... interesting [09:46] mwhudson: do I want to know [09:47] :-) [09:47] /* !!! Why do we stop after a .dynstr section? I can't [09:47] remember! */ [09:47] for example [09:48] loose specs and faulty memory [09:48] mwhudson: /* yolo */ [09:48] Chipaca: pretty much [09:49] pedronis: not so much "loose specs" as "it works on my machine" :/ [09:49] mwhudson: well to be fair I expect elf and how it's used by compilers to be said, it worked with the binaries from baz [09:49] s/to be said/to be loose/ [09:49] i wonder what patchelf would do with burneye and things like that [09:54] maybe that's unfair though , and is not as bad as dwarf [09:55] we should all go back to a.out [09:55] :-) [09:58] zyga: ah, right, i can get to the branch/build from travis directly. the missing link confused me. thanks [10:09] pedronis: i've never had the courage to learn much about DWARF === chihchun_afk is now known as chihchun [10:10] mwhudson: well it's extensible, as usual if extensible format don't have way to convey this you can ignore or not, writing stable tooling is a nightmare [10:11] mvo: zyga: we are getting handshake errors from linode, it means landing stuff to 2.32 is not easy, I wonder if we should back port the switch to gcloud [10:12] otoh it might be travis network issues [10:12] I can try [10:12] anyway: this is not fun: https://travis-ci.org/snapcore/snapd/builds/364488153?utm_source=github_status&utm_medium=notification [10:14] PR snapd#5018 closed: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps [10:18] so backporting 5018 requires the new api stuff, or a rework of the backend_test changes [10:25] pedronis: new api because of tests [10:27] pedronis: ? or because of the functionality? === pstolowski is now known as pstolowski|lunch === chihchun is now known as chihchun_afk [10:53] PR snapcraft#2061 opened: go: only use Go build package if not using the snap [11:06] mvo: because of tests [11:06] mvo: backend_test.go is very different [11:07] * mvo nods [11:10] mvo: given that the plan is still to land the new api, I will prepare a backport on top of 5002 , instead of a direct one [11:10] mvo: anyway we have troubles atm with tests on 2.32 because they still use linode and there seems to be travis->linode or linode problems [11:13] pedronis: yeah, porting to google seems like a good idea [11:14] zyga I got a report about snapd leaking threads, apparently for longer running snapd on bionic "ps -eTf|grep snapd" report very high numbers (in the 400s) for some people on bionic when it runs for ~2-3 days - you run bionic as well, is this something you see too? [11:14] mvo, CE has approved 32.3 to stable [11:14] Oh [11:15] cachio: brilliant! [11:15] No but i restart snapd for testing [11:15] cachio: so once the store is ready lets push it out :) [11:15] PR snapd#5022 opened: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps (2.32) [11:15] cachio: and fingers crossed for tihs version [11:15] mvo, sure [11:15] zyga: yeah, same here [11:15] pedronis: thanks for this PR! [11:17] zyga: no worries, I try to gather more data [11:18] mvo: I'll try to make a PR for 2.32 with just the systems stanza from master, not sure if we need other changes [11:19] I mean backends [11:19] pedronis: +1 [11:21] is snapcraft.io down? [11:22] thresh: looks like it [11:22] hopefully nothing serious then [11:23] thresh: i've pinged a sysadmin [11:23] * mwhudson goes to bed [11:23] many thanks! [11:24] https://status.snapcraft.io/ is handy fwiw [11:24] (I firstly assumed it's the nation-wide firewall that blocks the way here, but oh well) [11:32] PR snapd#5023 opened: spread.yaml: try to switch to run tests on gcloud [11:33] let's see ^ [11:33] pedronis: thank you [11:33] sorry for not doing it before, I just got home now [11:33] I need to file some time off for today [11:33] the vet visit and other stuff was more walking than working [11:34] it might not work [11:34] I don't know if it we have other changes that were needed [11:34] we'll see [11:35] pedronis: hmm, perhaps something in run-tests.sh? [11:35] I don't know [11:36] ah true [11:36] actually run-checks [11:36] spread google: linode: [11:36] wrote a test to check if the logging through journal stream sockets works correctly, and it's failing radomly because the journal is not flushed yet :/ [11:36] that's closer to master now [11:36] mvo: is there a report for the thread leak issue? [11:37] mvo: on my artful desktop I see this: [11:37] zyga@fyke:~/go/src/github.com/snapcore/snapd$ ps -eLf | grep '[s]napd' | wc -l => 23 [11:40] mvo: I am seeing this on my bionic laptop [11:40] zyga@t470:~/go/src/github.com/snapcore/snapd/cmd$ ps -eLf | grep '[s]napd' | wc -l => 122 [11:40] over 100 more threads [11:40] even though the deskop is a 8 core machine and the laptop is a 2 core machine [11:46] PR snapd#5024 opened: systemd: add helper for opening stream file descriptors to the journal [11:48] zyga: ps -eLf | grep '[s]napd' | wc -l => 36 on CPU(s): 16 [11:49] mborzecki: on arch or ubuntu? [11:49] oh snap, lunch [11:49] arch [11:49] interesting, that's golang 1.10? [11:49] 1.10.1 [11:50] package version is 2.32.2.r508.g629585a3f-1, let me rebuild the latest master [11:50] Chipaca: there's a meeting in 10 minutes [11:50] same as in bionic (apart from probable patches) [11:50] pedronis: standup @ 3pm right? [11:50] pedronis: yeah. running. [11:50] mborzecki: yeah, meeting is about epochs [11:50] mborzecki: yes, this is something else [11:50] okok [11:50] ah [11:50] uff :) [11:52] * Son_Goku groans to life === pstolowski|lunch is now known as pstolowski [11:55] zyga, you should be able to re-enable fedora in CI now [11:55] Son_Goku: we already enabled and merged it [11:57] mborzecki: reviewed [11:57] zyga: thanks [11:58] heh, gofmt -s did not catch this [12:00] mborzecki: 5003 reviewed [12:01] zyga: ta :) [12:05] off to pick up the kids, be back for standup [12:09] cachio, mvo: 2.32.3 stable today? [12:14] * zyga installed the new "communitheme" snap [12:14] it's pretty neat, so the snap is a dumb data carrier [12:14] and something in the desktop is picking up the snap's presence [12:16] zyga, yes [12:17] It should [12:24] mvo: interestingly the number of threads is pretty stable, after reboot I see 114 [12:30] reading snapstore docs [12:30] why is "sudo snapstore config store.domain=""" used over "snap set snapstore store.domain=... [12:32] zyga: 114? I just have 12 here, let me try in a clean VM [12:32] mvo: yes, this is vanilla beta [12:32] er, sorry, that's vanilla edge [12:33] zyga: I will try chocolate edge then [12:33] I wish golang tweaked each thread cmdline buffer to indicate what is going on [12:42] PR snapd#5025 opened: interfaces/shutdown: allow calling SetWallMessage [12:43] PR snapd#5012 closed: snap: fix `snap advise-snap --command` output to match spec [12:57] niemeyer, not sure if we have something like this on any snapd TODO yet ... (would be nice to have) https://forum.snapcraft.io/t/support-ask-for-reboot-via-sapcraft-yaml-and-snapd [13:00] niemeyer, heh, i guess we can merge that one with https://forum.snapcraft.io/t/allow-automatic-reboots-when-refreshing-a-snap/4935 (seems abeato and I had the same idea ) [13:01] * Chipaca will be a couple of minutes late to the standup (previous meeting overrun and I need a technical stop) [13:04] Chipaca: ack [13:04] jdstrand: are we going to use the stash directory approach [13:04] jdstrand: or shall we go for the better option directly? [13:06] zyga: I think that is based in part on release timing. that said, since this didn't make 2.32, why not just go for the non-stash approach since it is approved [13:07] jdstrand: yeah, that sounds good to me, thank you [13:07] jdstrand: and I can use this immediately then [13:08] jdstrand: actually, can I merge both [13:09] I think it's just worth preserving in history [13:09] I'll merge the 1st approach [13:09] resolve conflicts [13:09] and merge the 2nd approach [13:09] if you don't mind I'd prefer that [13:11] zyga: I don't mind at all. it makes sense to me [13:11] perfect, thank you [13:14] It's quite unbelievable.. I just spent more than 10 minutes trying to join the meeting from an Android phone.. no go [13:15] Any hangout links send me to the application.. the application doesn't know what to do with it [13:15] zyga: How did you manage to join yesterday? === chihchun_afk is now known as chihchun [13:15] Anyway.. see you soon [13:16] niemeyer: I have an iPhone [13:16] niemeyer: maybe we can dial you in with good old phone number [13:16] one sec [13:17] zyga: That's even more ironic [13:17] zyga: Can you send me a direct invite maybe? [13:17] niemeyer: I tried to dial you in from the hangout [13:17]