[00:05] kyrofa: is there a snapcraft policy on rebasing / squashing commits? [00:08] kalikiana: is there a snapcraft policy on rebasing / squashing commits? [00:23] mwhudson: we try to keep one commit per pull request. But for external contributors, we can always click the squash button. [00:24] elopio: oh ok [00:24] * mwhudson squashes away then [00:24] thanks. === jero is now known as Guest11527 === JoshStrobl|zzz is now known as JoshStrobl [05:54] morning guys [06:32] pushed 2 extra patches to #4153, think it's good to go [06:32] PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits [07:03] o/ [07:03] zyga-ubuntu: hi there [07:03] hi [07:03] hey zyga-ubuntu and mborzecki [07:04] another cold and rainy day, damn i hate atumn [07:05] mborzecki: I was thinking "man, what a gloomy morning" [07:07] at least it's not below 0 yet :/ [07:09] mborzecki: did you see what's in zakopane this week? [07:09] nope, is it 2-3m of snow? [07:10] mborzecki: looks like sub-zero temps during daytime [07:10] so, some good progress on tests yesterday [07:11] I have some more to go but I think I can carve out a chunk now and send a PR [07:15] mborzecki: interesting failure in https://github.com/snapcore/snapd/pull/4153 - there's a missing break in a switch statement [07:15] PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits [07:16] yup [07:17] is that intentional? [07:18] no, except for the one that is explicitly commented as such [07:19] ok [07:22] school run [07:27] any idea where I can get debian-9-64 image that was used in this test? [07:37] yeah, no wonder the error wasn't picked up on my arch laptop, I don't have apparmor, but it's weird that gcc test passed on debian-9 image that I pulled from zyga-ubuntu's site :/ [07:45] re [07:45] mborzecki: debian-9 is confusing [07:45] mborzecki: we have a "bug" so that debian refers to either sid or stretch in spread, depending on the backend linode vs qemu [07:46] mborzecki: images can be made with adt-buildvm-.. family of scripts but not sure if those would work on arch [07:46] mborzecki: I can build a pair of fresh images and upload [07:47] that'd be great, thanks [07:49] btw. and what do you use for builiding fedora/opensuse images? packer? [07:49] I don't [07:50] I don't have opensuse images and fedora image was made by someone who's no longer here [07:50] note that debian image is a tweaked cloud image [07:50] same with ubuntu [07:50] so it's "just" a matter of scripting something around a given distribution's cloud image [07:51] afaik arch has none :) [07:53] builds are in progress [07:53] great [07:53] note that they are not quite reliable and sometimes the "magic" hangs and needs to be retried [07:53] I haven't investigated that, it's a can of worms [07:54] but I should be able to upload some soon [07:56] i pushed a patch that should fix that failure, the 'case EPERM:' is in theory covered by a comment, there's some magic in both gcc and clang that will happily accept a fallthrough case if there's a comment that matches a predefined regex [07:58] oh, wow [08:22] yay, travis passing now [08:26] refreshed ubuntu images are uploading, I'll make debian images now [08:26] I also fixed the SSL cert [08:28] man, I should have paid for more than 10GB of disk [08:50] thanks [09:12] mvo: I just noticed that becaused configstate.Manager was strange when you turned into a manger Overlord code wasn't completely adjusted [09:12] and hi [09:14] mvo: I added a comment about that to #4122 [09:15] PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError [09:18] any idea how to convince go that file tagged with `+build !cgo` should not be built when building with cgo enabled? [09:19] hmm, nope [09:19] we have some custom tags [09:20] maybe we could use that as a way to solve the issue? [09:20] like we can build the store with either production or test keys [09:21] Chipaca suggested adding stubs for group calls when doing a static build, that's what I'm trying to do, but the no-cgo is picked up when building with cgo anyway :/ [09:22] pedronis: good morning! thank you, I have a look [09:22] and i'd really like to avoid using function pointers and registering those in init() [09:22] mvo: let me know if it's not clear [09:23] pedronis: makes sense so far, I get right to it. thanks again! [09:26] mborzecki: are you disabling it with CGO_ENABLED=0 [09:27] ? [09:27] yes, so I have 3 files, group.go (no build tags), group_stubs.go (+build !go) and cgo_group.go (+build cgo) [09:28] CGO_ENABLED=0 builds group.go and group_stubs.go (as expected) [09:28] CGO_ENABLED=1 builds group.go, cgo_group.go and group_stubs.go (and this is where i get symbol redeclaration) [09:29] s/!go/!cgo/ [09:29] that seems odd? are you sure +build is put in the correct in that file? [09:29] *correct place [09:30] go is failry picky where +build should go or it will ignore it [09:30] yup, it's right below the license header [09:31] I never put it there [09:31] it's eay to get it wrong [09:32] mborzecki: see for example asserts/sysdb/testkeys.go for where we tend to put it [09:32] pedronis: damn it, you're right [09:33] it was right below /* ... */ license header, apparently go doesn't like that [09:34] pedronis: thanks, fixed now, works like charm [09:34] they need a empty line after (and only blank lines/comments before) [09:34] i really really hate go tooling sometimes [09:35] in general though it's better to put far from keywords, otherwise it's easy for somebody later to break that rule [09:36] * kalikiana coffee [09:40] mvo: thanks [09:44] pedronis: good morning [09:45] pedronis: you know how alan a little while ago had an issue where a snap somehow got corrupted over a reboot? and that made people think maybe snapd should check the signature of installed snaps on startup as well as on install? [09:45] Chipaca: yes [09:46] bit unclear what to do with that until we have warnings though [09:46] yes, but [09:46] pedronis: on armhf that would be rather prohibitive [09:46] also expensive [09:47] pedronis: the io is bad enough, but our signature makes things worse [09:47] pedronis: we're also still doing the double signature check on download+install, which is also not optimal [09:48] Chipaca: is there a part of this that gets to something we *should* do soon? [09:48] pedronis: so this had me revisiting the idea of using two signatures, a cheaper "is the file sane" and a more expensive "is this what we signed" [09:48] pedronis: we used to have two signatures (sha256 was the other i think), and i wanted to check with you before chasing people to see if we still had that [09:48] to not lose it [09:48] before we want it again [09:49] we still have sha256 from the store afaik [09:49] don't think it was killed [09:49] it seems it might be sha512 [09:49] still, ok [09:50] Chipaca: yes, is sha512 [09:50] not sha256 [09:50] pedronis: if the above sounds sane to you, could you (or can i) mention it to store people lest we forget it? [09:50] the other alternative would be to calculate a cheaper checksum on install and use that [09:53] anyway, that's enough future-pondering for me. back to the trench! [09:57] Chipaca: I was also wondering about this recently. I'm kind of afraid about the io overhead if we do this but maybe we can make it an optional feature, for some systems we really need it. one really cool alternative would be to use something like a hash-tree so instead of having one global hash for the entire file, have a hash for each block (size to be determined) and on each read we could verify the block only - we would need a trusted hash of [09:57] this block/hash thing but that should be ok. but tradeoffs of course, i.e. each snap would grow or the store would have to send the data oob. anyway just idle thoughts for now [09:57] (huii, that was long) [09:58] mvo: does squashfs have anything like this? [09:58] (not a hash-tree more like a hash-flatmap) [09:59] Chipaca: I don't think so, its major work [09:59] yeah [09:59] Chipaca: also because it involves the kernel which will have to know about this and do the checking :/ [09:59] yep [09:59] Chipaca: I think its cool but not short term [09:59] ah, no [10:00] mvo: short term i just wanted to check we weren't going to throw away the second signature, if we then were going to want to use it :-) [10:01] Chipaca: :) yes [10:04] zyga-ubuntu: a second review for 4150 would be great, hopefully easy [10:05] ak [10:07] done :) [10:11] Chipaca: I haven't heard discussions about dropping it (sha512) tbh [10:14] PR snapd#4158 opened: snapctl: don't error out on start/stop/restart from configure hook during install or refresh [10:15] PR snapd#4150 closed: ifacestate: make interfaces.Repository available via state cache [10:16] mvo: got again one of those /var/lib/snapd changes while tar-ing in 14.04: https://travis-ci.org/snapcore/snapd/builds/298088866?utm_source=github_status&utm_medium=notification [10:20] ackk: reviewed (made it all the way through!). This is so close! [10:21] pedronis: interessting. always 14.04, right? [10:21] possibly yes, not 100% sure [10:22] pstolowski: hm, what happend to PlugInfo.Connections ? iirc we had that some days ago and in master it appears to be gone. what is the replacement to see if a plug is connected? [10:23] mvo, you mean Plug.Connections? [10:25] pstolowski: maybe, that, did that change? [10:25] pstolowski: I used to have code like "repo.Plug(snapName, plugName).Connection > 0" to figure out if the plug is connected [10:28] mvo: well repo is quite in flux [10:28] pstolowski: aha, I see, repo is now handing out PlugInfo instead of Plug, hmm [10:28] mvo, indeed [10:29] pstolowski: ok, what I need is to answer the question: "is this (snapName, plugName) pair connected"? I am happy to dig into this myself, was mostly wondering if you have suggestions/plans [10:29] mvo, let me see [10:29] mborzecki: your pr is very close to a +1; normally i would've +1'ed it leaving you to tidy up the things i point out [10:30] Chipaca: thanks for reviewing [10:30] mborzecki: give me a shout when you have it, so that i can give it a last once-over [10:30] pstolowski: aha! I think I found it [10:30] ack [10:30] mborzecki: github hate a comment i made on an commit, i think -- i made the same point in the pr itself just in case [10:31] * zyga-ubuntu feels so so [10:31] mvo, are you thinking about repo.Connected(..)? [10:31] pstolowski: yes [10:31] mvo, i [10:31] pstolowski: or is this misleading? [10:32] mvo, i'm wondering if it's good, it takes plugOrSlot [10:32] mvo, we could have a "precise" helpe [10:32] r [10:33] pstolowski: thanks, its ok for now, I will dig a bit more but this unblocks me. thanks for your help [10:36] mvo, I think Connected(..) is not very effective, a simpler helper could just look at slotPlugs or plugSlots maps and return true without all that logic [10:40] s/true/bool/ [10:45] mvo: in your review of #4153, did you forget to +1? [10:45] PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits [10:45] mvo: i see a lot of \o/'s and no /o\ and no +1 [11:05] Chipaca: I'm slightly unhappy about the need to write f(void) instead of f() - I understand the reason but I could not bring myself over it yesterday, if I'm the only one who does not like it I'm +1 [11:06] mvo: I don't like it, but C is C -- if i liked it i'd write more of the stuff [11:06] pstolowski: thanks, I think its fine for now, but if I need something more targeted I will keep it in mind [11:06] Chipaca: heh, fair point [11:06] oh I could tell you stories about weird stuff caused by omitting void there [11:06] cjwatson: part of me wants you to [11:06] cjwatson: the other part is already a block away, screaming [11:08] cjwatson, Chipaca: heh :) [11:08] actually thinking about it my best such story was from generated code that said (void) when it actually wasn't, coupled with varargs [11:09] mborzecki: silly question, I am looking at 4135 again and there is a new "break" in apparmor-support.c. I wonder why this is added here, it looks correct but how was it discovered? [11:10] mvo: c-unit-tests-gcc failed on debian unstable [11:11] as a result of enabling -Wextra warnings [11:11] mborzecki: aha, nice. so it noticed that this was probably unintentional? thats smart [11:11] and the CI builds will fail on warnings now :) [11:12] mborzecki: and if there is a "fall-though" comment that is the magic to make it pass? [11:12] mborzecki: (i.e. the line below)? [11:13] yes, gcc/clang will match that agains some built-in regexes that cover different variations of 'fall through' [11:13] mborzecki: neat [11:13] PR snapd#4141 closed: snap-update-ns: add missing unit test for desired/current profile handling [11:13] PR snapd#4153 closed: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits [11:22] * zyga-ubuntu takes a longer break to check if he can work today, [11:22] I don't feel good [11:23] * sergiusens is going to be on and off today; off according to the records [11:49] i'm looking at packaging, and it's a bit weird, debian/ubuntu has just one 'snapd' package, fedora has it split into snapd and snap-confine, opensuse has a single package again, arch, depending on which files you look at, is either one package (packaging/arch) or 2 packages (one in the repos) or one pacake again (when using PKGBUILD from releases page) [11:50] i would assume the idea is to converge all distros to having a single package? [11:56] yes [11:59] hmm, what changed recently that would have caused the core snap to be uninstallable in launchpad-buildd's containers? did we start doing more security setup on the core snap maybe? [11:59] cjwatson: no, I don't think we did [12:00] cjwatson: unless it's udev tagging, we use device cgroups more than before [12:00] I can get apparmor working by granting the mac_admin and mac_override capabilities (but I think I remember there being some reason we didn't do that before - will need to dig), and then I run into it wanting udevadm to exist. I'm sure I managed to avoid all this before [12:00] it seems like a surprising category of problems to be new, though [12:02] cjwatson: since we use udev tagging more than before now it is possible that the core snap's configure hook is trying to set something up that was not happening before [12:03] if udev is now mandatory then I think snapd is missing a dependency on it [12:03] yeah, that's believeable [12:03] where does that configure hook live? [12:06] * cjwatson installs udev and tries again [12:07] cjwatson: for core it's a bit special, I honestly don't know [12:09] zyga-ubuntu, cjwatson the source is at https://github.com/snapcore/core/blob/master/hooks/configure ... though mvo is just re-working the world, not sure it stays like that [12:09] ta [12:11] Hellos [12:11] mborzecki: Just sent the invite into the GH org [12:12] Hellos like greece ? :) [12:12] niemeyer: thx [12:13] OK, grant mac_admin and mac_override caps and install udev, and all seems to be well again. Will need to test all the things though ... [12:18] mborzecki: There was a third thing I promised you yesterday during our meeting but my notes on it were unfortunate to say the least [12:19] mborzecki: I wrote down "forum key", but I'm thinking that this is about the monthly scheduling.. that's what I get for writing down while speaking :) [12:19] mborzecki: Are you missing anything else infra-wise? [12:51] * zyga-ubuntu -> school, I need to help my daughter [12:52] I'm not much of help today anyway [12:52] i just threw my back out doing physio :-( [12:53] on the upside, we now know a bit more about what makes it go out [12:53] on the downside, FUCKIN' OUCH [12:53] niemeyer: maybe your wrote down linode key? [12:53] Chipaca: /o\ get well! [12:54] mvo: that's what i go to phisio for! [12:54] physio* [12:54] mvo: I had both in the notes.. I think it was really about the monthly scheduling, and I mixed up my writing as we spoke over the linode keys [12:55] Chipaca: What was it? [12:57] niemeyer: a when my hips go to about 90 degrees pushing, something twangs [12:57] but only with my knees at a particular angle [12:58] Chipaca: Wow, that must have been pretty hard to "debug", so to speak [12:59] niemeyer: some days i wish i had a debugger [13:00] of preference one more like smalltalk's [13:00] ie that i didn't need to die for it to work [13:00] LOL [13:01] Chipaca: corpse would be a much better name for those core dumps [13:28] cwayne, hey, any news? [13:32] cachio: havent heard from QA yet, waiting on Alex to start so I can get you access to that bug [13:57] PR snapd#4156 closed: overlord/devicestate: switch to the new endpoints for registration [13:58] I need 2nd reviews for #4121 and #4125 [13:58] PR #4121: overlord/snapstate: toggle ignore-validation as needed as we do for channel [13:58] PR #4125: corecfg: support setting proxy.store if there's a matching store assertion [14:03] jdstrand: do you know of any snap which successfully uses the mpris plug? [14:05] jdstrand: specifically an audio player which can be controlled via the buttons in the sound menu on ubuntu [14:05] I think gradio hooks it, whether successful or not I'm unaware [14:06] not successful, i have it playing here and see no reference in the sound menu [14:07] :-( [14:07] booo [14:08] i made a snap of auryo (a soundcloud client) and it doesn't work here either. But I don't know if I got the config in the yaml right or not [14:08] pedronis: done [14:08] I guess I should post on the forum. The problem is the documentation doesn't really cover it from a developer pov [14:08] popey gradio [14:09] does it work for you davidcalle ? [14:09] popey: I did a fresh install last week, so I can't re-check right away, but it worked fine afair [14:10] on 17.10? [14:10] popey: that's what I'm giving a try now [14:11] ok, works on 17.10 [14:12] popey: works fine on 17.10 [14:12] not on 16.04 unity [14:20] i'm done for today, till tomorrow [14:22] PR snapd#4159 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation [14:26] PR snapd#4160 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation [14:30] mvo: hi! fyi, those are for a similar udev tagging issue. this wasn't reported by a customer but from the field via the forum. I suggest that it be included in 2.29 so I created a branch, but that is up to you [14:30] s/those/those ^/ [14:31] thank you jdstrand [14:32] jdstrand: i have a look and see what we can do, probably 2.29.3 as 2.30 is still some time away [14:32] mvo: cool (that is what i was thinking) [14:32] mvo: for that framebuffer issue, I think I'll try to use a different interface that will be available in more places (eg, time-control, for /dev/rtc) [14:33] mvo: I think it is fine to commit the PR you did if you haven't already. I'll just send a followup [14:33] jdstrand: it got only a single +1 so far, but I think its useful becaue it validates the code on devices with a framebuffer [14:34] mvo: I also wanted you to be aware of https://github.com/snapcore/snapd/pull/4157 [14:34] PR #4157: add spread test for connecting all interfaces (excepting gadget slots) [14:34] mvo: it isn't ready to commit yet (it found a bug in firewall-control :) [14:34] popey: I don't know about successful, but: google-play-music-desktop-player, vlc, gradio (from a quick search) === heber_ is now known as heber [14:35] jdstrand: yeah, thats really nice, I looked at it this morning briefly [14:35] i tried copying the gradio mpris config but it barfs when i install the snap [14:35] jdstrand: thanks for that! [14:35] https://www.irccloud.com/pastebin/vhbIilEC/ [14:35] mvo: but the idea is to have a spread test that connects every interface. this will catch things like apparmor syntax issues, the udev_enumerate issue, seccomp policy issues, modules not loading, etc. just a high level test that connects the interface like a user would [14:35] mvo: ah cool [14:35] yes [14:36] mvo: this technique is what helped me find the uhid issue and the kmod back issues (where the interface fails to connect if the module can't be loaded-- I'll be sending a pr for that) [14:37] not uhid. the network-control one [14:37] anyway, it is finding things :) [14:37] s/back/backend/ [14:38] mvo: fyi, there may be one more cgroup fixup PR (something I need to investigate for ondra) [14:42] jdstrand: ok, so I will wait a bit before jumping to any 2.29.3 [14:43] mvo: fyi I was just passing through 4040 and it may be ready [14:44] (I didn't look at it, just saw the comments from the submitter) [14:46] jdstrand: looking at it now [14:46] \o/ mpris success [14:46] popey: oh, I missed your comment, but glad you got it working :) [14:47] works on 17.10 but not on 16.04 :( [14:47] (is that expected?) [14:47] PR snapd#4040 closed: interfaces: add USB interface number attribute in udev rule for serial-port interface [14:53] jdstrand: do i have to request mpris access on the forum? I have just uploaded auryo. https://dashboard.snapcraft.io/dev/snaps/8645/rev/1/ [14:56] popey: no. dbus and mpris access I can just handle, unless it is weird and I'd request discussion in the forum [14:56] ok [14:57] popey: actually, why are you using both? [14:58] popey: cause there are two names it is known by? [15:09] hm [15:10] good question! [15:10] lemme fix it [15:10] I want to dump the top-level of my repo in to a snap, but using "source: ." means that my .tox and .git directories are included; how can I stop that from happening? [15:11] source: ./* ? [15:15] mvo: I am seeing this: [15:15] Running vet [15:15] overlord/ifacestate/helpers.go:358: arg plug for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Plug [15:15] overlord/ifacestate/helpers.go:398: arg slot for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Slot [15:15] mvo: I'm up to date on master and looked at upcoming PRs, but don't see fixes [15:15] popey: "ValueError: local source (./*) is not a directory" [15:16] :( [15:17] .tox in particular is a problem because something breaks when snapcraft tries to copy from it. [15:17] jdstrand: I saw that too, I think it's a vet bug honestly [15:17] jdstrand: unless not the same thing [15:17] jdstrand: it's a pluginfo, so it has a String(), so %s works [15:17] that's all fine. what I'm hearing is everyone is currently just ignoring the vet error? [15:18] or do I need to redo godeps or something? [15:18] jdstrand: I just ignore it [15:19] jdstrand: let me check [15:19] jdstrand: I have not seen it, it seems like the go vet on linode is less strict [15:19] huh [15:20] PR snapd#4113 closed: tests: test for desktop interface [15:20] why does it think it's a Plug and not a PlugInfo? [15:20] jdstrand: looks like it needs both, yes [15:21] popey: do you have snappy-debug output I can see? [15:21] sure, one moment [15:21] oh, when it fails, or when it succeeds? [15:21] Chipaca, jdstrand might be a recent merge that broke it, I'm looking now [15:22] popey: because the dbus one is doing what the mpris interface is supposed to do, but with a different name [15:22] popey: does mpris with 'name: auryo' and another mpris with 'name: auryo-player' work? [15:23] the one that's in the store works on 17.10 [15:23] popey: (ie, you create two slots and slots both) [15:23] sorry, can you gimmie a pastebin? I don't fully understand [15:23] jdstrand, quick question ... if i added a content interface bit to my wine snap, could i start snapping random windows exe's that use that content interface as backend to run them via wine (or is execution of binaries blocked ?) [15:23] http://paste.ubuntu.com/25911480/ is what it looks like currently [15:24] jdstrand, (yes/no is enough as answer) [15:24] (I had to play around a lot to get this working, only got that working by copy/pasting and fiddling the gradio one) [15:24] so mine is based on the gradio snap which is in the store [15:24] popey: http://paste.ubuntu.com/25911484/ [15:24] lemme try that [15:24] jdstrand: hm, could you please check if the go vet thing is something local? I just checked out upstream/master and my 17.10 go vet seems to be happy. or are you on bionic already? [15:25] ogra_: execution of binaries is allowed. the trick is getting all the libs to work, etc [15:25] jdstrand, ok, thanks ... [15:25] ogra_: but the security policy allows it [15:26] mvo: my 16.04 vet on master throws that error [15:26] ogra_: (mrwklix used for write and mrkix for read) [15:26] ok [15:27] Chipaca: how strange, let me look harder [15:27] Mr. Kix and Mr. Wklix :) [15:27] mvo: fyi, I'm seeing this with run-checks in a 16.04 lxd container [15:27] ogra_: hehe :) [15:28] mvo: (host is 17.10, logged into 16.04 container, running go vet) [15:29] mvo: do you need more info than that? [15:30] jdstrand: no, must be something on my side then, checking [15:30] checking why I don't see the error [15:31] waait [15:31] jdstrand: can you remove pkg and try again? [15:33] Chipaca: remove pkg? (sorry if I'm dense) [15:33] oh in gopath [15:33] jdstrand: rm "${GOPATH%%:*}/pkg" [15:33] -r [15:34] that worked [15:34] mvo: ^ [15:34] aha! [15:34] thanks Chipaca [15:34] np [15:34] jdstrand: that worked, thanks. uploaded a new auryo [15:34] popey: cool :) [15:35] Chipaca, mvo: I need to keep a list of things to try. removing pkg, govendor, ... [15:35] what should I try snapping next? [15:36] diddledan: want suggestions? :) [15:36] please :-) [15:36] was gonna suggest nba-go but you already fixed it ;) [15:36]