[01:31] PR snapcraft#2212 closed: tests: add spread suite for ruby plugin [01:34] PR snapcraft#2213 opened: Revert "ci: disable osx tests until a new pyyaml is released" [02:22] PR snapd#5645 opened: tests: new test for udisks2 interface === chihchun_afk is now known as chihchun [05:05] PR snapd#5341 closed: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key [05:06] morning [05:23] PR snapd#5646 opened: cmd/snap-confine: extend security tag validation to cover instance names [05:30] mvo: hey [05:38] mborzecki: hey hey [05:38] mvo: simple review for you #5646 :) [05:39] PR #5646: cmd/snap-confine: extend security tag validation to cover instance names [05:45] mborzecki: on it [05:45] mvo: thanks [05:46] mborzecki: funny, we allow a regexp here - is this run without privs? [05:48] mvo: iirc it's run after the initial snap name validation, but with privs [05:50] mvo: no, it's without privs at this point [05:51] mborzecki: aha, ok [05:51] mborzecki: makes sense [05:51] mvo: heh, only gid is dropped, uid is still 0 [05:53] hm, hm [05:55] Is there a way to create a snap that installs in jailmode by default (without needing "snap install --jailmode name")? === Nafallo_ is now known as Nafallo [06:17] mborzecki: I wonder if we can merge the shellcheck PR with just a single review. this time around it looks very straightforward. [06:31] mvo: yeah, i suppose we can [06:32] mborzecki: we are over 50 again [06:32] mborzecki: thanks! can't wait for the next part of the shellcheck saga [06:32] mborzecki: how many are left? i.e. how many more to come? [06:33] PR snapd#5630 closed: tests: shellchecks part 6 [06:35] mvo: 126 files to go [06:35] mvo: i can put more in the next batch, say 30? [06:36] mborzecki: sounds good [06:42] PR snapd#5629 closed: debian: add tzdata to build-dep to ensure snapd builds correctly [06:49] good morning! [06:49] I will be with you all shortly, just need to take the dog out for a moment [06:59] zyga: hey, great report [06:59] mvo: next batch coming up in a minute, looks uncontroversial too [06:59] Thank you [07:00] mborzecki: good stuff [07:00] zyga: yeah, enjoyed reading it [07:01] zyga: even though I'm fully done yet :/ [07:01] PR snapd#5647 opened: tests: shellchecks part 7 [07:01] Did he hook fragment in the mail made you read the rest? === pstolowski_ is now known as pstolowski [07:08] running our tests on armhf in cosmic is incredible slow, I wonder what is going on there, jsut the compile takes forever (not even finished yet) [07:08] zyga: heh, that runtimes part indeed sounds complicated, but coming from yocto background, building an sdk and giving people a stable rootfs to use is something i did more than once :) [07:10] zyga: actually the odd thing is that it's for the same arch, normally i did that for other arches, you'd build an sdk for some crazy ass arm/mips target, hand the sdk + runtime to people to work with [07:25] mborzecki: yeah, the distribution should be the sdk because that what developers are familiar with [07:37] review for 5641 should be an easy win [07:47] PR snapd#5641 closed: interfaces: miscellaneous policy updates [07:47] PR snapd#5642 closed: interfaces: miscellaneous policy updates - 2.35 [08:09] zyga: just finished reading your report, great read and good job indeed! [08:09] thank you :) [08:20] fun, it looks like 69692a broke the armhf(!) tests, the hookManagerSuite.TestHookTaskCanKillHook hangs forever with it [08:20] * mvo scratches head [08:20] mvo: what is 69692a? [08:20] zyga: a git change we landed a while ago [08:20] ah, that's a git commit id [08:20] * zyga looks [08:20] zyga: and it seems like its breaking things in bionic/armhf [08:23] PR snapd#5637 closed: udev: skip TestParseUdevEvent on ppc [09:01] hmm I suspect that snap-update-ns is not built as a static library on opensuse with our current packaging [09:01] i'm hitting the same segfault bug i saw on friday in parallel-install tests on opensuse [09:04] aand it is wrong indeed [09:05] zyga: have you synced opensuse obs packaging with our in-tree one? [09:07] Mornings [09:08] hey niemeyer, good morning! [09:08] mvo: Heya! Beautiful indeed [09:08] ... and warm [09:09] niemeyer: hey [09:14] hey hey :) [09:15] mborzecki: yes I did [09:15] mborzecki: but perhaps some bugs just crept in [09:15] mborzecki: I can look after I'm done with travel paperwork [09:15] mborzecki: (50% done now, whee) [09:15] niemeyer: hey :) [09:15] zyga: yeah, i'll fix the spec [09:15] niemeyer: I recommend you to read the report I sent [09:16] zyga: we should probably plan to add leap to our test suite [09:16] uh leap 15 [09:16] mborzecki: yeah [09:21] * zyga scans the second pile of paper now === chihchun is now known as chihchun_afk [09:22] zyga: Thanks, will definitely read [09:41] jdstrand: we've been missing each other (aww), so I wrote out what I see as a problem with our hostname-control interface over on the pr that's failing because of it: https://github.com/snapcore/snapd/pull/5593#issuecomment-412812808 [09:41] PR #5593: tests: new test for hostname-control interface [09:43] jdstrand: I don't know if the failure is specific to 18.04, or if it's just more likely in 18.04: I've seen failures in 14.04 that look similar but haven't been able to reproduce consistently enough to get a shell and poke around [09:48] PR snapd#5648 opened: hookstate: simplify some hook tests [09:49] pedronis: ^- thats probably something for you, I wonder if we need to do more than just fixing the test [09:51] mvo: seems you wrote those tests like that with goroutines, do you remember why? [09:53] pedronis: the problematic CanKillHook is quite old, unless I misread git blame it was written by kyle in 2016 [09:54] mvo: anyway I don't have a quick answer, I need to carefully re-read them [09:54] pedronis: yeah, the other two are mine, probably silly cargo culting :( [09:54] pedronis: yeah, the tests are not so much the issue, its more that potentially we can deadlock when calling StateEngine.Wait() at the wrong moment, then StateEngine.Ensure never gets a chance to run [09:55] pedronis: I can reproduce this reliable on an armhf system here fwiw [10:01] mvo: I'm not sure I understand the explanation, we do release the lock around each tomb.Wait [10:01] which lock are we talking about [10:03] pedronis: StateEngine.mgrLock is acquired in StateEngine.Wait() but only relased when all se.managers finish their Wait() [10:03] pedronis: that seems to be the high level issue [10:04] ah [10:04] pedronis: that this does not finish until Ensure() was run [10:09] mvo: ok, now I see how it's related to my single taskrunner changes [10:13] pedronis: great, keen to hear your ideas if/what we need to do beside fixing the test [10:14] mvo: so a couple didn't need the 2nd Ensure either? [10:15] 100% of expenses done, now some more paperwork [10:16] mvo: the fix seems alright now that I understand, still not sure why it was using a goroutine, Wait doesn't trigger anything on its own, it just waits [10:16] * pedronis lunch [10:16] pedronis: yeah, the other two I think simply took the TestHookTaskCanKillHook and removed the s.change.Abort() [10:17] pedronis: so the whole ensure,lock,unlock,ensure dance is cargo cult it seems [10:17] pedronis: enjoy lunch, ttfn [10:33] 2018/08/14 12:31:51.850100 hotplug.go:66: DEBUG: HotplugDeviceAdded: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/ttyUSB0/tty/ttyUSB0 (default key: "0403:6001:AH06W0EQ", devname /dev/ttyUSB0, subsystem: tty) [10:33] 2018/08/14 12:31:51.850905 hotplug.go:132: Added hotplug slot "serial-port-4527" (serial-port) for device key "0403:6001:AH06W0EQ" [10:33] :) [10:33] wooot :) [10:33] crazy ! [10:33] that's so cool pawel :) [10:33] * zyga hugs pstolowski [10:33] zyga: still many holes, but.. [10:34] pfft ... holes ... just ship some buckets along [10:34] $ snap interfaces ... [10:34] :serial-port-4527 - [10:36] nice [10:36] snap interface serial-port -a [10:36] show me the attributes :) [10:37] pstolowski: nice job! [10:38] zyga: $ snap interface serial-port --attrs [10:38] name: serial-port [10:38] summary: allows accessing a specific serial port [10:38] slots: [10:38] - system:serial-port-4527: [10:38] path: /dev/ttyUSB0 [10:38] pawel@mordor ~/gocode/src/github.com/snapcore/snapd/osutil/udev (hotplug-ifacemgr*) $ [10:38] pstolowski: so nice :) [10:38] pstolowski: do you think we could start using label? [10:38] pstolowski: I mean, if the hot plug code can provide any form of useful label [10:39] pstolowski: (label doesn't have to be unique) [10:39] label would be displayed there [10:39] can you think of any udev data that could be a good fit? [10:39] zyga: we can use any name as long as it can be derived from the data (i.e. udev event attributes) [10:41] pstolowski: is there anything that has a useful value for your device? [10:43] https://www.irccloud.com/pastebin/MYiAtyU7/ [10:44] zyga: so there is some room for creativity.. e.g. derive it from cleaned-up vendor name etc [10:44] zyga: with fallbacks of course, as any of that may be missing for clones i guess [10:46] * zyga has completed all of the paperwork now [10:47] zyga: if you in the mood for reviews, i've 3 udev-related PRs that would be nice to land to unblock more interesing stuff [10:48] PR snapd#5649 opened: packaging/opensuse: fix static build of snap-update-ns and snap-exec [10:48] zyga: ^^ [10:50] mborzecki: looking [10:50] mborzecki: I should be able to, I will look at reviews now [10:51] (well, after a small snack) [10:51] mborzecki: that's neat [10:51] mborzecki: where did you try it? [10:52] mborzecki: I recall now that it didn't work (compile) on some versions of suse [10:52] zyga: opensuse debug shell ;) [10:52] mborzecki: I will grab some food and then ensure it builds on the oldest supported leap (42.x) [10:52] mborzecki: if it builds then that's great :) [10:52] mvo: btw we don't use Wait anywhere but tests, and daemon use Stop on overlord wich waits first for the loop, so I don't think any similar issue affects prod code [10:53] zyga: they have a quite byzantine rpm go integration, there's a script /usr/lib/rpm/golang.sh which wraps all go commands [10:53] yeah I know, before that it used to be ruby [10:53] a golang SIG was formed at flock and suse is supposedly going to join as well [10:53] heh, so maybe someone thought that shell is less arcane :P === pstolowski is now known as pstolowski|lunch [10:53] because packaging across the two is totally different [10:54] it'd be nice to see some consistency [10:55] aand parallel install tests work now on opensuse once again [10:56] zyga: if you could https://github.com/snapcore/snapd/pull/5646 [10:56] PR #5646: cmd/snap-confine: extend security tag validation to cover instance names [11:07] mvo: when is 2.35.0? is that now already? [11:13] hmmm there appears to be no real input validation when installing many snaps, so `snap install '' bar` has funny side effect [11:13] error: cannot install "", "bar": internal error: action without instance name [11:14] so it went down to store.SnapAction() and stopped there :) [11:14] mborzecki: I think there are various bugs about error handling in multi-install, apparently is not a very used feature, so we mostly find them by playing on our own [11:15] mborzecki: also not sure it's relevant to what you are doing but we should change it to be like UpdateMany and do a single store request at the start [11:15] pedronis: I hope the change in task conflict you're working on will make this tend to work well more often [11:15] pedronis: i found it by accident with shellchecks, incorrectly added quoting of flags, those when empty ended up being a '' positional argument [11:16] niemeyer: not sure this is related to conflicts [11:18] otoh that change to make it more like UpdateMany would help conflict/concurrency work [11:19] it's on my todo list, I know it would fix some of error handling issues as well [11:19] not this one, or not sure about this one though [11:22] Lunch, biab === cachio_ is now known as cachio [11:27] Chipaca, hey, do you remember the permissions error that I sent you yesterday [11:27] it is happening in the refresh scenatio [11:27] scenario [11:28] when we start from the factory release image and we refresh the core from beta [11:37] cachio: hey. I checked the thing you asked about yesterday. With current master there is no error. I believe this situation is just because edge is currently not really edge but a release candidate build [11:37] zyga, hey [11:37] I am testing beta [11:37] cachio: so all should be fine once edge starts tracking master again [11:38] zyga, do you mean some PRs were not included as part of this beta? [11:38] so we should wait for 2.36 for the fix? [11:39] cachio: I think it's a version problem more than branch problem; the PR that included the test and the fix _passed_ [11:39] I think 2.35.1 [11:39] mvo: are we still in a situation where when we do a ~pre1 release for 35 we will have disabled reexec for people who track edge? [11:39] zyga, ok [11:40] mvo: I'm trying to understand why exactly edge is breaking while master rebuild works ok [11:40] zyga: I'm not sure I understand the question, we are that 2.35~pre1 [11:40] mvo: do you know if the fix for fedora29 was included in 2.35 [11:40] mvo: ok, another way, which branch contains 2.35~pre1? [11:41] zyga: I don't know but I can check, release/2.35 [11:41] * zyga checks [11:41] mvo: thanks, let me look [11:41] zyga: thats the branch that contains the 2.35~pre1 - I can/will do a ~pre2 or ~rc1 RSN [11:42] cachio: fake store, or actual store? [11:42] ah, I see [11:42] so 2.35 release branch has the fix [11:42] but yet the build in edge doesn't work [11:42] hmm? [11:42] pedronis: yeah, its just test code that uses stop [11:42] Chipaca, the actual one [11:42] * zyga is confused now [11:42] but the build from master works (and it has the same fix) [11:42] zyga: maybe edge is behind [11:42] mvo: edge is at ~pre1 [11:43] zyga: and the snapd-vendor git tree is broken [11:43] zyga: *grumpf* [11:43] not sure, I don't understand yet [11:43] I could build a dpkg from release/2.35 [11:43] zyga: there is a bug [11:43] and see what's the output [11:43] zyga, we here we are using a core image created using ubuntu-image, and in google we build it manually from ubuntu 16.04-64, could that affect in some way? [11:44] cachio: it depends, is the package updated inside those environments? [11:44] cachio: as in, is snapd really up to date? [11:44] zyga: snapd-vendor-daily ppa builds are broken, I'm looking into this now [11:45] mvo: ahh [11:45] thank you! [11:45] cachio: perhaps that explains it [11:45] zyga: I triggered a rebuild, lets see [11:45] mvo: thank you [11:45] mvo, I see snapd-vendor-sync in green [11:46] mvo, ahh, the ppa builder [11:51] cachio: do you have the pastebin (from the permissions error) handy? [11:52] Chipaca, https://paste.ubuntu.com/p/FJVhj5H2H7/ [11:53] Chipaca, the snaps which are before the core is updated are with wrong permissions [11:54] cachio: were those snaps put there by hand? [11:54] Chipaca, no [11:54] cachio: by what then? [11:54] I just refreshed the core [11:54] and then ran the snapd test suite [11:54] cachio: right [11:54] cachio: but the snaps in seed/ [11:54] cachio: have the wrong permissions [11:55] Chipaca, yes [11:55] wait, and the refreshed ones do as well? [11:55] Chipaca, those are the ones that come with the factory release [11:56] cachio: I mean pc-kernel_126.snap and pc-kernel_45.snap both have the wrong permissions [11:57] Chipaca, yes [11:58] cachio: they're both in the factory release? [11:58] Chipaca, pc, pc-kernel and core have wrong permissions [11:58] Chipaca, I think so [11:58] and the refreshed snapd also have wrong permission [11:59] Chipaca, I don't know if the core snap shol fix that, or it is ok? [11:59] * Chipaca sings "everything is awesome" but with more realistic lyrics [11:59] cachio: it sounds like a regression to me [11:59] cachio: but also maybe a bug in ubuntu-image [12:00] Chipaca, ok [12:02] cachio: where can I get this image from? [12:03] * Chipaca thinks prepositions are dandy things to end sentences with [12:04] Chipaca, cheching [12:05] Chipaca, http://cdimage.ubuntu.com/ubuntu-core/16/stable/20170323/ubuntu-core-16-amd64.img.xz [12:05] Chipaca, I think this is the one I used [12:05] Chipaca, it is an old one [12:05] getting [12:05] ah [12:05] zyga: and all builds are failing, oh well [12:05] cachio: how old? [12:05] zyga: anyway, on it [12:05] cachio: that explains it [12:05] thank you [12:06] I'm slowly getting back into production mode [12:06] cachio: that, on its own i mean, could explain it [12:06] I managed to clean a pile of paper from my desk [12:06] cachio: this permissions thing is not old [12:06] Chipaca, ah, so I sholud skiip this test on the refresh sncenario? [12:06] Chipaca, when I am using this image? [12:07] cachio: the commit that made downloads be 0600 is from Jul 10 [12:07] Chipaca, ok [12:07] cachio: not sure what release it landed it, this one might be the first with this check [12:07] cachio: so, yeah [12:09] Chipaca, ok, I'll skip it [12:09] Chipaca, thanks [12:11] cachio: everything after snapd restarted is 0600 so all is well === pstolowski|lunch is now known as pstolowski [12:16] zyga: fun! fb730e1 broke snap building, the tests fail to run now when no snapd is running, I'm looking into the details, just a heads up. [12:18] mvo: thanks, I found a small bug in snap-confine, patches soon, just fixing tests [12:35] PR snapd#5650 opened: snap: fix mocking of systemkey in snap-run tests [12:35] hm in some daemon tests we call postSnap directly, passing it a newly built http.Request, but inside it calls mux.Vars() which then tries to use the request's context to obtain the list of registeres uris, which is obviously empty at this point, so any attempts to recover vars from urls are useless [12:36] mborzecki: that's why some tests mysteriously do .daemon() [12:37] daemon test would need love, there's a bunch of style and cargo cultinting there [12:37] *styles [12:37] but is never on top of anybody's list [12:37] Chipaca: this one does too, but unless the request is enriched with the context (or goes through gorilla's handler) mux.Vars won't work as expected [12:38] mborzecki: set .vars? [12:38] mborzecki: d := s.daemon(c) [12:38] s.vars = map[string]string{"name": "foo"} [12:38] etc etc [12:38] pfff [12:39] * mborzecki facepalms [12:39] need more coffee clearly [12:39] mborzecki: and then [12:39] req, err := http.NewRequest("GET", "/v2/snaps/foo", nil) [12:39] works [12:39] mborzecki: it's all mocks, all the way down [12:39] yeah. s.vars is what's missing [12:39] and tons of lines of tests [12:39] some do what you want [12:39] just a matter of finding them :( [12:41] niemeyer: we need to agree on a the better name for "disconnect-interfaces" task in #4767 ; that's the only point that i haven't addressed in the PR [12:41] PR #4767: interfaces: disconnect hooks

[12:42] pstolowski: Cool, let's talk on the stand up [12:42] great [12:46] * zyga coffee break [12:46] PR snapd#5651 opened: cmd/libsnap: unify detection of core/classic with go [12:48] mvo, https://paste.ubuntu.com/p/sDRd5txDsd/ [12:48] I saw this error on an amazon linux instance [12:48] on google [12:49] mvo, could be related to the other issue in the forum? [12:50] cachio: maybe but the error looks different, the stuff in the forum is more about excessively slow machines (at least it looks like this from the outside) [12:51] PR snapd#5652 opened: cmd/snap, daemon: error out if trying to install a snap using empty name [12:51] Chipaca: ^^ [12:53] mborzecki: is the client also erroring out? [12:54] Chipaca: yeah, both sides do the checking now [12:54] mborzecki: I'll look in a bit, need caffeine (but sounds good) [12:54] Where does snapd get the host OS name from? neon shows in the store as "neon", but that's neon 16.04. With neon 18.04 coming, it will still only show "neon" which doesn't help differentiate the two releases. [12:54] (other OS's show the version) [12:56] 2018-08-14 12:47:57 Cannot allocate google:ubuntu-16.04-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout [12:56] popey: /etc/os-release [12:56] we send both the ID and VersionID [12:56] so it's more of a question how they are used [12:57] the stats page don't show the versionid bit [12:57] 5648 is an easy win (and will fix armhf builds!) [12:58] cachio: 5635 is probably interessting for you [12:58] ID=neon [12:58] VERSION_ID="16.04" [12:58] but store just shows "neon". is this a bug in snapd or the store? [12:58] popey: I'm saying snapd sends it, so it's a matter of store side processing here [12:58] afaiu [12:58] mvo, nice [12:58] mborzecki: one question on 5652 [12:58] unless something else is breaking down [12:59] popey: sorry, are you talking about the user-agent? [12:59] i am talking about pages where we look at stats for installs of snaps [12:59] afaik that's the only place we send that info through [12:59] hover your mouse over the metrics and hit gives you blobs with version name/number [12:59] popey: do you have a neon to poke at? [13:00] linux mint shows as "linuxmint" and zorin is "zorin", but Ubuntu is "ubuntu 16.04" or "ubuntu 18.04" [13:00] i am sat at neon now [13:01] I wonder what's different [13:01] https://snapcraft.io/account/snaps//metrics?active-devices=os is the graph I am talking about [13:01] seeing the User-Agent might help [13:02] I don't see code that would treat ubuntu specially [13:02] https://usercontent.irccloud-cdn.com/file/XnIsCGMj/This%20graph [13:03] or it might be some store postprocessing [13:03] popey: asking under a store topic in the forum might be best [13:05] popey: what does 'snap version' show? === chihchun_afk is now known as chihchun [13:06] https://pastebin.com/AFtMrKAN [13:08] Ok, I'll ask on the forum. [13:08] popey: when you start snapd, what's the "started snapd/" log line? === chihchun is now known as chihchun_afk [13:09] uhm [13:09] when *I* start snapd? [13:09] popey: journalctl -u snapd | grep started [13:09]