| mup | PR snapcraft#2212 closed: tests: add spread suite for ruby plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2212> | 01:31 |
|---|---|---|
| mup | PR snapcraft#2213 opened: Revert "ci: disable osx tests until a new pyyaml is released" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2213> | 01:34 |
| mup | PR snapd#5645 opened: tests: new test for udisks2 interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5645> | 02:22 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#5341 closed: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5341> | 05:05 |
| mborzecki | morning | 05:06 |
| mup | PR snapd#5646 opened: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5646> | 05:23 |
| mborzecki | mvo: hey | 05:30 |
| mvo | mborzecki: hey hey | 05:38 |
| mborzecki | mvo: simple review for you #5646 :) | 05:38 |
| mup | PR #5646: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5646> | 05:39 |
| mvo | mborzecki: on it | 05:45 |
| mborzecki | mvo: thanks | 05:45 |
| mvo | mborzecki: funny, we allow a regexp here - is this run without privs? | 05:46 |
| mborzecki | mvo: iirc it's run after the initial snap name validation, but with privs | 05:48 |
| mborzecki | mvo: no, it's without privs at this point | 05:50 |
| mvo | mborzecki: aha, ok | 05:51 |
| mvo | mborzecki: makes sense | 05:51 |
| mborzecki | mvo: heh, only gid is dropped, uid is still 0 | 05:51 |
| mvo | hm, hm | 05:53 |
| ChaiTRex | Is there a way to create a snap that installs in jailmode by default (without needing "snap install --jailmode name")? | 05:55 |
| === Nafallo_ is now known as Nafallo | ||
| mvo | mborzecki: I wonder if we can merge the shellcheck PR with just a single review. this time around it looks very straightforward. | 06:17 |
| mborzecki | mvo: yeah, i suppose we can | 06:31 |
| mvo | mborzecki: we are over 50 again | 06:32 |
| mvo | mborzecki: thanks! can't wait for the next part of the shellcheck saga | 06:32 |
| mvo | mborzecki: how many are left? i.e. how many more to come? | 06:32 |
| mup | PR snapd#5630 closed: tests: shellchecks part 6 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5630> | 06:33 |
| mborzecki | mvo: 126 files to go | 06:35 |
| mborzecki | mvo: i can put more in the next batch, say 30? | 06:35 |
| mvo | mborzecki: sounds good | 06:36 |
| mup | PR snapd#5629 closed: debian: add tzdata to build-dep to ensure snapd builds correctly <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5629> | 06:42 |
| zyga | good morning! | 06:49 |
| zyga | I will be with you all shortly, just need to take the dog out for a moment | 06:49 |
| mborzecki | zyga: hey, great report | 06:59 |
| mborzecki | mvo: next batch coming up in a minute, looks uncontroversial too | 06:59 |
| zyga | Thank you | 06:59 |
| mvo | mborzecki: good stuff | 07:00 |
| mvo | zyga: yeah, enjoyed reading it | 07:00 |
| mvo | zyga: even though I'm fully done yet :/ | 07:01 |
| mup | PR snapd#5647 opened: tests: shellchecks part 7 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5647> | 07:01 |
| zyga | Did he hook fragment in the mail made you read the rest? | 07:01 |
| === pstolowski_ is now known as pstolowski | ||
| mvo | 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 |
| mborzecki | 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:08 |
| mborzecki | 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:10 |
| zyga | mborzecki: yeah, the distribution should be the sdk because that what developers are familiar with | 07:25 |
| mvo | review for 5641 should be an easy win | 07:37 |
| mup | PR snapd#5641 closed: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5641> | 07:47 |
| mup | PR snapd#5642 closed: interfaces: miscellaneous policy updates - 2.35 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5642> | 07:47 |
| pstolowski | zyga: just finished reading your report, great read and good job indeed! | 08:09 |
| zyga | thank you :) | 08:09 |
| mvo | fun, it looks like 69692a broke the armhf(!) tests, the hookManagerSuite.TestHookTaskCanKillHook hangs forever with it | 08:20 |
| * mvo scratches head | 08:20 | |
| zyga | mvo: what is 69692a? | 08:20 |
| mvo | zyga: a git change we landed a while ago | 08:20 |
| zyga | ah, that's a git commit id | 08:20 |
| * zyga looks | 08:20 | |
| mvo | zyga: and it seems like its breaking things in bionic/armhf | 08:20 |
| mup | PR snapd#5637 closed: udev: skip TestParseUdevEvent on ppc <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5637> | 08:23 |
| mborzecki | hmm I suspect that snap-update-ns is not built as a static library on opensuse with our current packaging | 09:01 |
| mborzecki | i'm hitting the same segfault bug i saw on friday in parallel-install tests on opensuse | 09:01 |
| mborzecki | aand it is wrong indeed | 09:04 |
| mborzecki | zyga: have you synced opensuse obs packaging with our in-tree one? | 09:05 |
| niemeyer | Mornings | 09:07 |
| mvo | hey niemeyer, good morning! | 09:08 |
| niemeyer | mvo: Heya! Beautiful indeed | 09:08 |
| niemeyer | ... and warm | 09:08 |
| mborzecki | niemeyer: hey | 09:09 |
| zyga | hey hey :) | 09:14 |
| zyga | mborzecki: yes I did | 09:15 |
| zyga | mborzecki: but perhaps some bugs just crept in | 09:15 |
| zyga | mborzecki: I can look after I'm done with travel paperwork | 09:15 |
| zyga | mborzecki: (50% done now, whee) | 09:15 |
| zyga | niemeyer: hey :) | 09:15 |
| mborzecki | zyga: yeah, i'll fix the spec | 09:15 |
| zyga | niemeyer: I recommend you to read the report I sent | 09:15 |
| mborzecki | zyga: we should probably plan to add leap to our test suite | 09:16 |
| mborzecki | uh leap 15 | 09:16 |
| zyga | mborzecki: yeah | 09:16 |
| * zyga scans the second pile of paper now | 09:21 | |
| === chihchun is now known as chihchun_afk | ||
| niemeyer | zyga: Thanks, will definitely read | 09:22 |
| Chipaca | 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 |
| mup | PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593> | 09:41 |
| Chipaca | 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:43 |
| mup | PR snapd#5648 opened: hookstate: simplify some hook tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/5648> | 09:48 |
| mvo | pedronis: ^- thats probably something for you, I wonder if we need to do more than just fixing the test | 09:49 |
| pedronis | mvo: seems you wrote those tests like that with goroutines, do you remember why? | 09:51 |
| mvo | pedronis: the problematic CanKillHook is quite old, unless I misread git blame it was written by kyle in 2016 | 09:53 |
| pedronis | mvo: anyway I don't have a quick answer, I need to carefully re-read them | 09:54 |
| mvo | pedronis: yeah, the other two are mine, probably silly cargo culting :( | 09:54 |
| mvo | 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:54 |
| mvo | pedronis: I can reproduce this reliable on an armhf system here fwiw | 09:55 |
| pedronis | mvo: I'm not sure I understand the explanation, we do release the lock around each tomb.Wait | 10:01 |
| pedronis | which lock are we talking about | 10:01 |
| mvo | pedronis: StateEngine.mgrLock is acquired in StateEngine.Wait() but only relased when all se.managers finish their Wait() | 10:03 |
| mvo | pedronis: that seems to be the high level issue | 10:03 |
| pedronis | ah | 10:04 |
| mvo | pedronis: that this does not finish until Ensure() was run | 10:04 |
| pedronis | mvo: ok, now I see how it's related to my single taskrunner changes | 10:09 |
| mvo | pedronis: great, keen to hear your ideas if/what we need to do beside fixing the test | 10:13 |
| pedronis | mvo: so a couple didn't need the 2nd Ensure either? | 10:14 |
| zyga | 100% of expenses done, now some more paperwork | 10:15 |
| pedronis | 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 | |
| mvo | pedronis: yeah, the other two I think simply took the TestHookTaskCanKillHook and removed the s.change.Abort() | 10:16 |
| mvo | pedronis: so the whole ensure,lock,unlock,ensure dance is cargo cult it seems | 10:17 |
| mvo | pedronis: enjoy lunch, ttfn | 10:17 |
| pstolowski | 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 |
| pstolowski | 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 |
| pstolowski | :) | 10:33 |
| zyga | wooot :) | 10:33 |
| ogra | crazy ! | 10:33 |
| zyga | that's so cool pawel :) | 10:33 |
| * zyga hugs pstolowski | 10:33 | |
| pstolowski | zyga: still many holes, but.. | 10:33 |
| ogra | pfft ... holes ... just ship some buckets along | 10:34 |
| pstolowski | $ snap interfaces ... | 10:34 |
| pstolowski | :serial-port-4527 - | 10:34 |
| mborzecki | nice | 10:36 |
| zyga | snap interface serial-port -a | 10:36 |
| zyga | show me the attributes :) | 10:36 |
| mvo | pstolowski: nice job! | 10:37 |
| pstolowski | zyga: $ snap interface serial-port --attrs | 10:38 |
| pstolowski | name: serial-port | 10:38 |
| pstolowski | summary: allows accessing a specific serial port | 10:38 |
| pstolowski | slots: | 10:38 |
| pstolowski | - system:serial-port-4527: | 10:38 |
| pstolowski | path: /dev/ttyUSB0 | 10:38 |
| pstolowski | pawel@mordor ~/gocode/src/github.com/snapcore/snapd/osutil/udev (hotplug-ifacemgr*) $ | 10:38 |
| zyga | pstolowski: so nice :) | 10:38 |
| zyga | pstolowski: do you think we could start using label? | 10:38 |
| zyga | pstolowski: I mean, if the hot plug code can provide any form of useful label | 10:38 |
| zyga | pstolowski: (label doesn't have to be unique) | 10:39 |
| zyga | label would be displayed there | 10:39 |
| zyga | can you think of any udev data that could be a good fit? | 10:39 |
| pstolowski | zyga: we can use any name as long as it can be derived from the data (i.e. udev event attributes) | 10:39 |
| zyga | pstolowski: is there anything that has a useful value for your device? | 10:41 |
| pstolowski | https://www.irccloud.com/pastebin/MYiAtyU7/ | 10:43 |
| pstolowski | zyga: so there is some room for creativity.. e.g. derive it from cleaned-up vendor name etc | 10:44 |
| pstolowski | zyga: with fallbacks of course, as any of that may be missing for clones i guess | 10:44 |
| * zyga has completed all of the paperwork now | 10:46 | |
| pstolowski | 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:47 |
| mup | PR snapd#5649 opened: packaging/opensuse: fix static build of snap-update-ns and snap-exec <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5649> | 10:48 |
| mborzecki | zyga: ^^ | 10:48 |
| zyga | mborzecki: looking | 10:50 |
| zyga | mborzecki: I should be able to, I will look at reviews now | 10:50 |
| zyga | (well, after a small snack) | 10:51 |
| zyga | mborzecki: that's neat | 10:51 |
| zyga | mborzecki: where did you try it? | 10:51 |
| zyga | mborzecki: I recall now that it didn't work (compile) on some versions of suse | 10:52 |
| mborzecki | zyga: opensuse debug shell ;) | 10:52 |
| zyga | mborzecki: I will grab some food and then ensure it builds on the oldest supported leap (42.x) | 10:52 |
| zyga | mborzecki: if it builds then that's great :) | 10:52 |
| pedronis | 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:52 |
| mborzecki | 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 |
| zyga | yeah I know, before that it used to be ruby | 10:53 |
| zyga | a golang SIG was formed at flock and suse is supposedly going to join as well | 10:53 |
| mborzecki | heh, so maybe someone thought that shell is less arcane :P | 10:53 |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | because packaging across the two is totally different | 10:53 |
| mborzecki | it'd be nice to see some consistency | 10:54 |
| mborzecki | aand parallel install tests work now on opensuse once again | 10:55 |
| mborzecki | zyga: if you could https://github.com/snapcore/snapd/pull/5646 | 10:56 |
| mup | PR #5646: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5646> | 10:56 |
| zyga | mvo: when is 2.35.0? is that now already? | 11:07 |
| mborzecki | hmmm there appears to be no real input validation when installing many snaps, so `snap install '' bar` has funny side effect | 11:13 |
| mborzecki | error: cannot install "", "bar": internal error: action without instance name | 11:13 |
| mborzecki | so it went down to store.SnapAction() and stopped there :) | 11:14 |
| pedronis | 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:14 |
| pedronis | 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 |
| niemeyer | pedronis: I hope the change in task conflict you're working on will make this tend to work well more often | 11:15 |
| mborzecki | pedronis: i found it by accident with shellchecks, incorrectly added quoting of flags, those when empty ended up being a '' positional argument | 11:15 |
| pedronis | niemeyer: not sure this is related to conflicts | 11:16 |
| pedronis | otoh that change to make it more like UpdateMany would help conflict/concurrency work | 11:18 |
| pedronis | it's on my todo list, I know it would fix some of error handling issues as well | 11:19 |
| pedronis | not this one, or not sure about this one though | 11:19 |
| niemeyer | Lunch, biab | 11:22 |
| === cachio_ is now known as cachio | ||
| cachio | Chipaca, hey, do you remember the permissions error that I sent you yesterday | 11:27 |
| cachio | it is happening in the refresh scenatio | 11:27 |
| cachio | scenario | 11:27 |
| cachio | when we start from the factory release image and we refresh the core from beta | 11:28 |
| zyga | 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 |
| cachio | zyga, hey | 11:37 |
| cachio | I am testing beta | 11:37 |
| zyga | cachio: so all should be fine once edge starts tracking master again | 11:37 |
| cachio | zyga, do you mean some PRs were not included as part of this beta? | 11:38 |
| cachio | so we should wait for 2.36 for the fix? | 11:38 |
| zyga | cachio: I think it's a version problem more than branch problem; the PR that included the test and the fix _passed_ | 11:39 |
| zyga | I think 2.35.1 | 11:39 |
| zyga | 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 |
| cachio | zyga, ok | 11:39 |
| zyga | mvo: I'm trying to understand why exactly edge is breaking while master rebuild works ok | 11:40 |
| mvo | zyga: I'm not sure I understand the question, we are that 2.35~pre1 | 11:40 |
| zyga | mvo: do you know if the fix for fedora29 was included in 2.35 | 11:40 |
| zyga | mvo: ok, another way, which branch contains 2.35~pre1? | 11:40 |
| mvo | zyga: I don't know but I can check, release/2.35 | 11:41 |
| * zyga checks | 11:41 | |
| zyga | mvo: thanks, let me look | 11:41 |
| mvo | zyga: thats the branch that contains the 2.35~pre1 - I can/will do a ~pre2 or ~rc1 RSN | 11:41 |
| Chipaca | cachio: fake store, or actual store? | 11:42 |
| zyga | ah, I see | 11:42 |
| zyga | so 2.35 release branch has the fix | 11:42 |
| zyga | but yet the build in edge doesn't work | 11:42 |
| zyga | hmm? | 11:42 |
| mvo | pedronis: yeah, its just test code that uses stop | 11:42 |
| cachio | Chipaca, the actual one | 11:42 |
| * zyga is confused now | 11:42 | |
| zyga | but the build from master works (and it has the same fix) | 11:42 |
| mvo | zyga: maybe edge is behind | 11:42 |
| zyga | mvo: edge is at ~pre1 | 11:42 |
| mvo | zyga: and the snapd-vendor git tree is broken | 11:43 |
| mvo | zyga: *grumpf* | 11:43 |
| zyga | not sure, I don't understand yet | 11:43 |
| zyga | I could build a dpkg from release/2.35 | 11:43 |
| mvo | zyga: there is a bug | 11:43 |
| zyga | and see what's the output | 11:43 |
| cachio | 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:43 |
| zyga | cachio: it depends, is the package updated inside those environments? | 11:44 |
| zyga | cachio: as in, is snapd really up to date? | 11:44 |
| mvo | zyga: snapd-vendor-daily ppa builds are broken, I'm looking into this now | 11:44 |
| zyga | mvo: ahh | 11:45 |
| zyga | thank you! | 11:45 |
| zyga | cachio: perhaps that explains it | 11:45 |
| mvo | zyga: I triggered a rebuild, lets see | 11:45 |
| zyga | mvo: thank you | 11:45 |
| cachio | mvo, I see snapd-vendor-sync in green | 11:45 |
| cachio | mvo, ahh, the ppa builder | 11:46 |
| Chipaca | cachio: do you have the pastebin (from the permissions error) handy? | 11:51 |
| cachio | Chipaca, https://paste.ubuntu.com/p/FJVhj5H2H7/ | 11:52 |
| cachio | Chipaca, the snaps which are before the core is updated are with wrong permissions | 11:53 |
| Chipaca | cachio: were those snaps put there by hand? | 11:54 |
| cachio | Chipaca, no | 11:54 |
| Chipaca | cachio: by what then? | 11:54 |
| cachio | I just refreshed the core | 11:54 |
| cachio | and then ran the snapd test suite | 11:54 |
| Chipaca | cachio: right | 11:54 |
| Chipaca | cachio: but the snaps in seed/ | 11:54 |
| Chipaca | cachio: have the wrong permissions | 11:54 |
| cachio | Chipaca, yes | 11:55 |
| Chipaca | wait, and the refreshed ones do as well? | 11:55 |
| cachio | Chipaca, those are the ones that come with the factory release | 11:55 |
| Chipaca | cachio: I mean pc-kernel_126.snap and pc-kernel_45.snap both have the wrong permissions | 11:56 |
| cachio | Chipaca, yes | 11:57 |
| Chipaca | cachio: they're both in the factory release? | 11:58 |
| cachio | Chipaca, pc, pc-kernel and core have wrong permissions | 11:58 |
| cachio | Chipaca, I think so | 11:58 |
| cachio | and the refreshed snapd also have wrong permission | 11:58 |
| cachio | 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 | |
| Chipaca | cachio: it sounds like a regression to me | 11:59 |
| Chipaca | cachio: but also maybe a bug in ubuntu-image | 11:59 |
| cachio | Chipaca, ok | 12:00 |
| Chipaca | cachio: where can I get this image from? | 12:02 |
| * Chipaca thinks prepositions are dandy things to end sentences with | 12:03 | |
| cachio | Chipaca, cheching | 12:04 |
| cachio | Chipaca, http://cdimage.ubuntu.com/ubuntu-core/16/stable/20170323/ubuntu-core-16-amd64.img.xz | 12:05 |
| cachio | Chipaca, I think this is the one I used | 12:05 |
| cachio | Chipaca, it is an old one | 12:05 |
| Chipaca | getting | 12:05 |
| Chipaca | ah | 12:05 |
| mvo | zyga: and all builds are failing, oh well | 12:05 |
| Chipaca | cachio: how old? | 12:05 |
| mvo | zyga: anyway, on it | 12:05 |
| Chipaca | cachio: that explains it | 12:05 |
| zyga | thank you | 12:05 |
| zyga | I'm slowly getting back into production mode | 12:06 |
| Chipaca | cachio: that, on its own i mean, could explain it | 12:06 |
| zyga | I managed to clean a pile of paper from my desk | 12:06 |
| Chipaca | cachio: this permissions thing is not old | 12:06 |
| cachio | Chipaca, ah, so I sholud skiip this test on the refresh sncenario? | 12:06 |
| cachio | Chipaca, when I am using this image? | 12:06 |
| Chipaca | cachio: the commit that made downloads be 0600 is from Jul 10 | 12:07 |
| cachio | Chipaca, ok | 12:07 |
| Chipaca | cachio: not sure what release it landed it, this one might be the first with this check | 12:07 |
| Chipaca | cachio: so, yeah | 12:07 |
| cachio | Chipaca, ok, I'll skip it | 12:09 |
| cachio | Chipaca, thanks | 12:09 |
| Chipaca | cachio: everything after snapd restarted is 0600 so all is well | 12:11 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | 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:16 |
| zyga | mvo: thanks, I found a small bug in snap-confine, patches soon, just fixing tests | 12:18 |
| mup | PR snapd#5650 opened: snap: fix mocking of systemkey in snap-run tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/5650> | 12:35 |
| mborzecki | 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:35 |
| Chipaca | mborzecki: that's why some tests mysteriously do .daemon() | 12:36 |
| pedronis | daemon test would need love, there's a bunch of style and cargo cultinting there | 12:37 |
| pedronis | *styles | 12:37 |
| pedronis | but is never on top of anybody's list | 12:37 |
| mborzecki | 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:37 |
| Chipaca | mborzecki: set .vars? | 12:38 |
| Chipaca | mborzecki: d := s.daemon(c) | 12:38 |
| Chipaca | s.vars = map[string]string{"name": "foo"} | 12:38 |
| Chipaca | etc etc | 12:38 |
| mborzecki | pfff | 12:38 |
| * mborzecki facepalms | 12:39 | |
| mborzecki | need more coffee clearly | 12:39 |
| Chipaca | mborzecki: and then | 12:39 |
| Chipaca | req, err := http.NewRequest("GET", "/v2/snaps/foo", nil) | 12:39 |
| Chipaca | works | 12:39 |
| Chipaca | mborzecki: it's all mocks, all the way down | 12:39 |
| mborzecki | yeah. s.vars is what's missing | 12:39 |
| pedronis | and tons of lines of tests | 12:39 |
| pedronis | some do what you want | 12:39 |
| pedronis | just a matter of finding them :( | 12:39 |
| pstolowski | 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 |
| mup | PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767> | 12:41 |
| niemeyer | pstolowski: Cool, let's talk on the stand up | 12:42 |
| pstolowski | great | 12:42 |
| * zyga coffee break | 12:46 | |
| mup | PR snapd#5651 opened: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651> | 12:46 |
| cachio | mvo, https://paste.ubuntu.com/p/sDRd5txDsd/ | 12:48 |
| cachio | I saw this error on an amazon linux instance | 12:48 |
| cachio | on google | 12:48 |
| cachio | mvo, could be related to the other issue in the forum? | 12:49 |
| mvo | 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:50 |
| mup | PR snapd#5652 opened: cmd/snap, daemon: error out if trying to install a snap using empty name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5652> | 12:51 |
| mborzecki | Chipaca: ^^ | 12:51 |
| Chipaca | mborzecki: is the client also erroring out? | 12:53 |
| mborzecki | Chipaca: yeah, both sides do the checking now | 12:54 |
| Chipaca | mborzecki: I'll look in a bit, need caffeine (but sounds good) | 12:54 |
| popey | 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 |
| popey | (other OS's show the version) | 12:54 |
| mborzecki | 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 |
| Chipaca | popey: /etc/os-release | 12:56 |
| pedronis | we send both the ID and VersionID | 12:56 |
| pedronis | so it's more of a question how they are used | 12:56 |
| popey | the stats page don't show the versionid bit | 12:57 |
| mvo | 5648 is an easy win (and will fix armhf builds!) | 12:57 |
| mvo | cachio: 5635 is probably interessting for you | 12:58 |
| popey | ID=neon | 12:58 |
| popey | VERSION_ID="16.04" | 12:58 |
| popey | but store just shows "neon". is this a bug in snapd or the store? | 12:58 |
| pedronis | popey: I'm saying snapd sends it, so it's a matter of store side processing here | 12:58 |
| pedronis | afaiu | 12:58 |
| cachio | mvo, nice | 12:58 |
| zyga | mborzecki: one question on 5652 | 12:58 |
| pedronis | unless something else is breaking down | 12:58 |
| Chipaca | popey: sorry, are you talking about the user-agent? | 12:59 |
| popey | i am talking about pages where we look at stats for installs of snaps | 12:59 |
| pedronis | afaik that's the only place we send that info through | 12:59 |
| popey | hover your mouse over the metrics and hit gives you blobs with version name/number | 12:59 |
| Chipaca | popey: do you have a neon to poke at? | 12:59 |
| popey | linux mint shows as "linuxmint" and zorin is "zorin", but Ubuntu is "ubuntu 16.04" or "ubuntu 18.04" | 13:00 |
| popey | i am sat at neon now | 13:00 |
| pedronis | I wonder what's different | 13:01 |
| popey | https://snapcraft.io/account/snaps/<snapname>/metrics?active-devices=os is the graph I am talking about | 13:01 |
| pedronis | seeing the User-Agent might help | 13:01 |
| pedronis | I don't see code that would treat ubuntu specially | 13:02 |
| popey | https://usercontent.irccloud-cdn.com/file/XnIsCGMj/This%20graph | 13:02 |
| pedronis | or it might be some store postprocessing | 13:03 |
| pedronis | popey: asking under a store topic in the forum might be best | 13:03 |
| Chipaca | popey: what does 'snap version' show? | 13:05 |
| === chihchun_afk is now known as chihchun | ||
| popey | https://pastebin.com/AFtMrKAN | 13:06 |
| popey | Ok, I'll ask on the forum. | 13:08 |
| Chipaca | popey: when you start snapd, what's the "started snapd/<blah blah>" log line? | 13:08 |
| === chihchun is now known as chihchun_afk | ||
| popey | uhm | 13:09 |
| popey | when *I* start snapd? | 13:09 |
| Chipaca | popey: journalctl -u snapd | grep started | 13:09 |
| popey | Aug 12 13:37:22 KinkPad-K450 snapd[4018]: daemon.go:343: started snapd/2.35~pre1 (series 16; classic) neon/16.04 (amd64) linux/4.15.0-30-generic. | 13:09 |
| Chipaca | popey: that's the user agent we're sending | 13:09 |
| popey | Ok, thanks :) | 13:10 |
| popey | I'll include that. | 13:10 |
| Chipaca | popey: ubuntu's is: 2018/08/14 14:10:23.065715 daemon.go:343: started snapd/2.34+git209.g9c5287393.dirty (series 16; classic; testing) ubuntu/16.04 (amd64) linux/4.4.0-131-generic. | 13:10 |
| Chipaca | well, not the dirty testing bit | 13:10 |
| Chipaca | 2018/08/14 14:11:11.274478 daemon.go:343: started snapd/2.34.3 (series 16; classic) ubuntu/16.04 (amd64) linux/4.4.0-131-generic. | 13:11 |
| pedronis | yea, os should be parsed by the store as 'neon/16.04' so there should be some postprocessing | 13:12 |
| pedronis | aggregating | 13:12 |
| popey | https://forum.snapcraft.io/t/why-does-neon-16-04-show-as-neon-in-the-store/6868 | 13:13 |
| mup | PR snapd#5643 closed: interfaces/builtin: addtl network-manager resolved DBus fix <Created by tonyespy> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5643> | 13:20 |
| mup | PR snapd#5649 closed: packaging/opensuse: fix static build of snap-update-ns and snap-exec <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5649> | 13:28 |
| mup | PR snapd#5650 closed: snap: fix mocking of systemkey in snap-run tests <Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5650> | 14:04 |
| mup | PR snapd#5646 closed: cmd/snap-confine: extend security tag validation to cover instance names <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5646> | 14:32 |
| mup | PR snapd#5648 closed: hookstate: simplify some hook tests <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5648> | 15:01 |
| mup | PR snapd#5652 closed: cmd/snap, daemon: error out if trying to install a snap using empty name <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5652> | 15:25 |
| mup | PR snapd#5647 closed: tests: shellchecks part 7 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5647> | 15:27 |
| mup | PR snapd#5639 closed: snapcraft: set version information for the snapd snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5639> | 15:36 |
| ogra | mvo, no unified pi gadget then ? *snoff* | 15:42 |
| ogra | *sniff* even | 15:42 |
| * ogra had high hopes | 15:42 | |
| ogra | (reading your core18 models proposal) | 15:43 |
| mvo | ogra: the unified vs non-unified pi was discussed with niemeyer and the conclusion was that if we ever need to "unbunble" them again we will be in a world of pain | 15:45 |
| ogra | why would *we* unbundle them for the reference image ... | 15:47 |
| ogra | customers would likely build single-pi ones | 15:47 |
| ogra | doing QA on 4 images vs 1 is definitely a massive cost factor | 15:47 |
| ogra | but well ... niemeyers decision then :/ | 15:48 |
| niemeyer | ogra: Because until a few days ago we needed different images.. they did a change that allows having a single image.. tomorrow they can do a change that requires different images again | 15:49 |
| niemeyer | ogra: When that happens, we're in deep trouble, because the systems will update to the merged snaps regardless | 15:49 |
| niemeyer | ogra: These devices are very unlike each other.. doesn't seem wise | 15:49 |
| ogra | niemeyer, my proposal is a month old (admittedly only added to the forum 2 weeks ago) ... the name could be simply "pi" and if you want separate images you'd still ahve pi2, pi3, cm3 (and soon pi3b+) | 15:58 |
| niemeyer | ogra: The age of the proposal is not in general something we account for :) | 15:59 |
| ogra | niemeyer, this proposal was spoecifically for core18 only and the devices are identical on the SoC level, use the same kernel and will only differ by peripherials | 15:59 |
| ogra | core18 only -> new installs | 15:59 |
| ogra | niemeyer, that age comment was about your "until few days ago" :) | 15:59 |
| niemeyer | ogra: I also don't understand your point.. it sounds like this is what we debated, and replied to above? | 15:59 |
| niemeyer | ogra: it doesn't matter if it was 10 days ago or 10 months ago.. the exact same point holds | 16:00 |
| ogra | a system installed with the pi2 snap will not upgrade to a new "pi" (without 2) gadget | 16:00 |
| ogra | so this would only affect new installs of core 18 | 16:00 |
| niemeyer | ogra: Exactly, which is why this is all a bad idea | 16:00 |
| niemeyer | ogra: We don't want a pi3 using a pi2 snap | 16:01 |
| niemeyer | ogra: We need a way to upgrade the pi3 to a pi3-specific snap | 16:01 |
| ogra | and we could phase out the old separate gadgets once core 16 goes out of support | 16:01 |
| ogra | which we cant do if we keep that schema | 16:01 |
| ogra | there is really no reason to have separate gadgets at all for mostly identical HW | 16:02 |
| niemeyer | ogra: This is *not* mostly identical hardware.. the pi3 and pi2 have completely different chips | 16:02 |
| ogra | upstream specifically offers the separation in the config to account for the different peripherials and we should be good downstreams and simply follw their guide here | 16:02 |
| ogra | but whateverm, the decision has happened and i have a meeting ... i just tried to be a good citizen towards downstream, save us money and maintenance work and have a future plan for post 18 times ... anyway, i'll live with it | 16:04 |
| niemeyer | ogra: It's not an arbitrary decision.. I've explained exactly why this is necessary, and pointed out that the devices are not the same | 16:05 |
| niemeyer | ogra: THis is not "whatever".. this is a decision we are taking because there's a reason | 16:05 |
| niemeyer | ogra: When you run out of bad arguments, please just be understanding | 16:05 |
| ogra | niemeyer, just note that upstream offers a unified bootloader for all pi's from the same binary ... it was us that added an artificial separation here that i tried to overcome ... | 16:05 |
| niemeyer | ogra: Instead of dismissive | 16:05 |
| niemeyer | ogra: Thank you | 16:06 |
| ogra | niemeyer, well, the decision is made, why should i still argue ... | 16:06 |
| mup | PR snapd#5653 opened: release: 2.35~pre3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5653> | 16:10 |
| mvo | zyga: just fyi, edge core is back | 16:11 |
| mup | PR snapd#5617 closed: overlord/devicestate: DTRT w/a snap proxy to reach a serial vault <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5617> | 16:20 |
| pedronis | mborzecki: hi, sorry, had a bit of an afternoon of meetings, I will look again at your parallel installs PR in the morning | 16:27 |
| mborzecki | sure, thanks,, just fyi i'm off tomorrow so will do the fixes on thursday | 16:28 |
| mborzecki | pedronis: ^^ | 16:28 |
| pedronis | mborzecki: np, I remember correctly it was quite close | 16:31 |
| pedronis | *if I remember | 16:31 |
| mborzecki | pedronis: i've pushe some fixes based on comments form pstolowski and Chipaca | 16:31 |
| pedronis | ok | 16:31 |
| mup | PR snapd#5654 opened: cmd/snap-confine: establish snap directory mappings for parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5654> | 16:35 |
| mborzecki | zyga: jdstrand: something for you guys ^^ :) | 16:36 |
| mborzecki | ok, back to fixing the flow heater | 16:37 |
| === pstolowski is now known as pstolowski|afk | ||
| rbasak | I've registered my GitHub repository against build.snapcraft.io to automatically build my certbot snap. It's building it now. I have some tests I want to run against the installed snap. Is there any infrastructure that will help me with this (eg. Travis), or do I need to set something up myself? The key thing is that I want to CI the snap itself, rather than the code in the upstream repos (since they | 16:50 |
| rbasak | already do that). | 16:50 |
| ogra | rbasak, despite being old (and IIRC also unfinished) https://forum.snapcraft.io/t/new-tutorial-ready-for-review-continuous-delivery-with-travis-ci/135 might help | 16:57 |
| ogra | (or at least give some ideas) | 16:58 |
| rbasak | Thanks! | 16:59 |
| rbasak | Looks like those instructions will allow me to do exactly what build.snapcraft.io is doing for me, but in Travis. | 17:01 |
| rbasak | I might be able to extend them though to further actually test the snap once built, which I don't think I can do on build.snapcraft.io currently. | 17:01 |
| rbasak | There's quite some crossover here with https://forum.snapcraft.io/t/launchpad-post-build-pre-upload-testing/5545/3 | 17:03 |
| rbasak | AFAICT, nobody has thought about how to actually CI snaps themselves? | 17:03 |
| rbasak | Separately, I can't seem to find a way to get build.snapcraft.io to build on a timer :-/ | 17:04 |
| rbasak | This is problematic since I'm not actually upstream so my webhook won't ever really fire (unless I change snapcraft.yaml) | 17:04 |
| cachio | Chipaca, hey, what do yuou suggest to do with #5593 | 17:14 |
| mup | PR #5593: tests: new test for hostname-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593> | 17:14 |
| cachio | with the errors you found there? | 17:14 |
| om26er | Hello! is there a way to have latest Qt with desktop-qt5 part ? | 17:35 |
| om26er | We are snapping a PySide2 app and it requires Qt 5.11 | 17:35 |
| ogra | just clone it and make your own ? | 17:36 |
| om26er | Where does it live ? | 17:37 |
| ogra | https://wiki.ubuntu.com/snapcraft/parts is wheer snapcraft pulls the info from ... | 17:39 |
| ogra | mvo, this 1:30 snapd timeout on shutdown gets really annoying, did you manage to find where it comes from ? | 17:39 |
| ogra | (after auto-refreshes of core) | 17:40 |
| mup | PR snapd#5655 opened: snap,snap-exec: support command-chain for hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5655> | 17:47 |
| kyrofa | Chipaca, if you have a few, that ^ should look very familiar | 17:47 |
| mup | PR snapd#5653 closed: release: 2.35~pre3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5653> | 17:50 |
| mvo | ogra: hm, I have not. could you please remind me tomorrow morning and we can dig into it | 17:58 |
| ogra | vmo, sure | 18:00 |
| ogra | bah | 18:00 |
| om26er | I am building a snap in Ubuntu 18.04 container, but it complains https://paste.ubuntu.com/p/H74sHhGkgH/ | 18:16 |
| om26er | is there a way around that (instead of shipping libc6) | 18:17 |
| mcphail | om26er: Won't you need core18 to avoid that? | 18:19 |
| om26er | mcphail: is that possible ? | 18:25 |
| mup | PR snapd#5656 opened: debian: add missing breaks on comisc <Created by mvo5> <https://github.com/snapcore/snapd/pull/5656> | 18:33 |
| sergiusens | mvo there might be a small issue here https://paste.ubuntu.com/p/VmvrgGmNhC/ | 18:45 |
| mup | PR snapcraft#2214 opened: sentry: support disabling error reporting <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2214> | 18:47 |
| mup | PR snapd#5657 opened: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5657> | 18:49 |
| mup | PR snapd#5658 opened: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5658> | 18:52 |
| jdstrand | zyga: hey, would you mind taking a look at ^. this is part of our L1TF response and would be nice to have in 2.35 | 18:52 |
| mcphail | om26er: yes, although i don't think the store is ready for snaps requiring core18 yet | 18:54 |
| om26er | mcphail: in my case, I'll probably end up building Qt 5.9 myself to fix that above issue. | 18:55 |
| om26er | Though still not there yet. | 18:55 |
| mcphail | om26er: i think it is safe to say core18 is eagerly anticipated | 18:56 |
| ogra | jdstrand, shiny !! what about access to the thermal, cpufreq and cpuidle nodes ? | 19:12 |
| jdstrand | ogra: not opposed to adding those with specific use cases | 19:12 |
| ogra | (or would these go into separate interfaces) | 19:12 |
| jdstrand | thermal maybe separate? | 19:12 |
| ogra | yeah | 19:12 |
| jdstrand | cpufreq and idle probably in cpu-control | 19:13 |
| ogra | yeah, i think that makes sense | 19:13 |
| ogra | (i dont really have a use case yer apart from someone packaging up cpufreq-utils in a snap or some such ) | 19:13 |
| ogra | s/yer/yet/ | 19:13 |
| ogra | but i think being able to access them through such an interface makes a lot of sense | 19:14 |
| mup | PR snapcraft#2189 closed: project_loader: add basic template support <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2189> | 19:35 |
| om26er | ogra: who maintains for desktop-qt5 cloud part ? | 19:41 |
| mup | PR snapd#5609 closed: tests: new test for juju client observe interface <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5609> | 19:54 |
| ogra | om26er, sould be noted in the wiki entry | 19:59 |
| ogra | *should | 19:59 |
| ogra | (there is surely a GH link there from wher the code is pulled) | 20:00 |
| om26er | right, it links to https://github.com/ubuntu/snapcraft-desktop-helpers | 20:02 |
| om26er | and the qt directory was last touched over a year ago, though the snapcraft.yaml there doesn't really make much sense ;-) | 20:04 |
| om26er | apparently kde-frameworks-5 snap have a slot kde-frameworks-5-45-qt-5-9-ubuntu-1604 maybe I could try "plugging" into it, before going for a custom Qt build. | 20:09 |
| jdstrand | popey: hey, can you add https://forum.snapcraft.io/t/tio-request-for-classic-confinement/6209/15 to your list? | 20:11 |
| jdstrand | popey: hey, this one too if you don't mind: https://forum.snapcraft.io/t/classic-confinement-for-minizinc/6529/4 | 20:52 |
| mup | PR snapcraft#2196 closed: build providers: better injection logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2196> | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!