[00:05] <mwhudson> kyrofa: is there a snapcraft policy on rebasing / squashing commits?
[00:08] <mwhudson> kalikiana: is there a snapcraft policy on rebasing / squashing commits?
[00:23] <elopio> mwhudson: we try to keep one commit per pull request. But for external contributors, we can always click the squash button.
[00:24] <mwhudson> elopio: oh ok
[00:24]  * mwhudson squashes away then
[00:24] <elopio> thanks.
[05:54] <mborzecki> morning guys
[06:32] <mborzecki> pushed 2 extra patches to #4153, think it's good to go
[06:32] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[07:03] <zyga-ubuntu> o/
[07:03] <mborzecki> zyga-ubuntu: hi there
[07:03] <zyga-ubuntu> hi
[07:03] <mvo> hey zyga-ubuntu  and mborzecki
[07:04] <mborzecki> another cold and rainy day, damn i hate atumn
[07:05] <zyga-ubuntu> mborzecki: I was thinking "man, what a gloomy morning"
[07:07] <mborzecki> at least it's not below 0 yet :/
[07:09] <zyga-ubuntu> mborzecki: did you see what's in zakopane this week?
[07:09] <mborzecki> nope, is it 2-3m of snow?
[07:10] <zyga-ubuntu> mborzecki: looks like sub-zero temps during daytime
[07:10] <zyga-ubuntu> so, some good progress on tests yesterday
[07:11] <zyga-ubuntu> I have some more to go but I think I can carve out a chunk now and send a PR
[07:15] <zyga-ubuntu> mborzecki: interesting failure in https://github.com/snapcore/snapd/pull/4153 - there's a missing break in a switch statement
[07:15] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[07:16] <mborzecki> yup
[07:17] <mborzecki> is that intentional?
[07:18] <zyga-ubuntu> no, except for the one that is explicitly commented as such
[07:19] <mborzecki> ok
[07:22] <zyga-ubuntu> school run
[07:27] <mborzecki> any idea where I can get debian-9-64 image that was used in this test?
[07:37] <mborzecki> 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] <zyga-ubuntu> re
[07:45] <zyga-ubuntu> mborzecki: debian-9 is confusing
[07:45] <zyga-ubuntu> 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] <zyga-ubuntu> mborzecki: images can be made with adt-buildvm-.. family of scripts but not sure if those would work on arch
[07:46] <zyga-ubuntu> mborzecki: I can build a pair of fresh images and upload
[07:47] <mborzecki> that'd be great, thanks
[07:49] <mborzecki> btw. and what do you use for builiding fedora/opensuse images? packer?
[07:49] <zyga-ubuntu> I don't
[07:50] <zyga-ubuntu> I don't have opensuse images and fedora image was made by someone who's no longer here
[07:50] <zyga-ubuntu> note that debian image is a tweaked cloud image
[07:50] <zyga-ubuntu> same with ubuntu
[07:50] <zyga-ubuntu> so it's "just" a matter of scripting something around a given distribution's cloud image
[07:51] <mborzecki> afaik arch has none :)
[07:53] <zyga-ubuntu> builds are in progress
[07:53] <mborzecki> great
[07:53] <zyga-ubuntu> note that they are not quite reliable and sometimes the "magic" hangs and needs to be retried
[07:53] <zyga-ubuntu> I haven't investigated that, it's a can of worms
[07:54] <zyga-ubuntu> but I should be able to upload some soon
[07:56] <mborzecki> 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] <zyga-ubuntu> oh, wow
[08:22] <mborzecki> yay, travis passing now
[08:26] <zyga-ubuntu> refreshed ubuntu images are uploading, I'll make debian images now
[08:26] <zyga-ubuntu> I also fixed the SSL cert
[08:28] <zyga-ubuntu> man, I should have paid for more than 10GB of disk
[08:50] <mborzecki> thanks
[09:12] <pedronis> mvo: I just noticed that becaused configstate.Manager was strange when you turned into a manger Overlord code wasn't completely adjusted
[09:12] <pedronis> and hi
[09:14] <pedronis> mvo: I added a comment about that to #4122
[09:15] <mup> PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
[09:18] <mborzecki> any idea how to convince go that file tagged with `+build !cgo` should not be built when building with cgo enabled?
[09:19] <zyga-ubuntu> hmm, nope
[09:19] <zyga-ubuntu> we have some custom tags
[09:20] <zyga-ubuntu> maybe we could use that as a way to solve the issue?
[09:20] <zyga-ubuntu> like we can build the store with either production or test keys
[09:21] <mborzecki> 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] <mvo> pedronis: good morning! thank you, I have a look
[09:22] <mborzecki> and i'd really like to avoid using function pointers and registering those in init()
[09:22] <pedronis> mvo: let me know if it's not clear
[09:23] <mvo> pedronis: makes sense so far, I get right to it. thanks again!
[09:26] <pedronis> mborzecki: are you disabling it with CGO_ENABLED=0
[09:27] <pedronis> ?
[09:27] <mborzecki> yes, so I have 3 files, group.go (no build tags), group_stubs.go (+build !go) and cgo_group.go (+build cgo)
[09:28] <mborzecki> CGO_ENABLED=0 builds group.go and group_stubs.go (as expected)
[09:28] <mborzecki> CGO_ENABLED=1 builds group.go, cgo_group.go and group_stubs.go (and this is where i get symbol redeclaration)
[09:29] <mborzecki> s/!go/!cgo/
[09:29] <pedronis> that seems odd?  are you sure +build is put in the correct in that file?
[09:29] <pedronis> *correct place
[09:30] <pedronis> go is failry picky where +build should go or it will ignore it
[09:30] <mborzecki> yup, it's right below the license header
[09:31] <pedronis> I never put it there
[09:31] <pedronis> it's eay to get it wrong
[09:32] <pedronis> mborzecki: see for example  asserts/sysdb/testkeys.go  for where we tend to put it
[09:32] <mborzecki> pedronis: damn it, you're right
[09:33] <mborzecki> it was right below /* ... */ license header, apparently go doesn't like that
[09:34] <mborzecki> pedronis: thanks, fixed now, works like charm
[09:34] <pedronis> they need a empty line after (and only blank lines/comments before)
[09:34] <mborzecki> i really really hate go tooling sometimes
[09:35] <pedronis> 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] <pedronis> mvo: thanks
[09:44] <Chipaca> pedronis: good morning
[09:45] <Chipaca> 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] <pedronis> Chipaca: yes
[09:46] <pedronis> bit unclear what to do with that until we have warnings though
[09:46] <Chipaca> yes, but
[09:46] <Chipaca> pedronis: on armhf that would be rather prohibitive
[09:46] <pedronis> also expensive
[09:47] <Chipaca> pedronis: the io is bad enough, but our signature makes things worse
[09:47] <Chipaca> pedronis: we're also still doing the double signature check on download+install, which is also not optimal
[09:48] <pedronis> Chipaca: is there a part of this that gets to something we *should* do soon?
[09:48] <Chipaca> 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] <Chipaca> 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] <Chipaca> to not lose it
[09:48] <Chipaca> before we want it again
[09:49] <pedronis> we still have sha256 from the store afaik
[09:49] <pedronis> don't think it was killed
[09:49] <Chipaca> it seems it might be sha512
[09:49] <Chipaca> still, ok
[09:50] <pedronis> Chipaca: yes, is sha512
[09:50] <pedronis> not sha256
[09:50] <Chipaca> pedronis: if the above sounds sane to you, could you (or can i) mention it to store people lest we forget it?
[09:50] <Chipaca> the other alternative would be to calculate a cheaper checksum on install and use that
[09:53] <Chipaca> anyway, that's enough future-pondering for me. back to the trench!
[09:57] <mvo> 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] <mvo> 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] <mvo> (huii, that was long)
[09:58] <Chipaca> mvo: does squashfs have anything like this?
[09:58] <mvo> (not a hash-tree more like a hash-flatmap)
[09:59] <mvo> Chipaca: I don't think so, its major work
[09:59] <Chipaca> yeah
[09:59] <mvo> Chipaca: also because it involves the kernel which will have to know about this and do the checking :/
[09:59] <Chipaca> yep
[09:59] <mvo> Chipaca: I think its cool but not short term
[09:59] <Chipaca> ah, no
[10:00] <Chipaca> 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] <mvo> Chipaca: :) yes
[10:04] <mvo> zyga-ubuntu: a second review for 4150 would be great, hopefully easy
[10:05] <zyga-ubuntu> ak
[10:07] <zyga-ubuntu> done :)
[10:11] <pedronis> Chipaca: I haven't heard discussions about dropping it (sha512) tbh
[10:14] <mup> PR snapd#4158 opened: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
[10:15] <mup> PR snapd#4150 closed: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4150>
[10:16] <pedronis> 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] <Chipaca> ackk: reviewed (made it all the way through!). This is so close!
[10:21] <mvo> pedronis: interessting. always 14.04, right?
[10:21] <pedronis> possibly yes, not 100% sure
[10:22] <mvo> 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] <pstolowski> mvo, you mean Plug.Connections?
[10:25] <mvo> pstolowski: maybe, that, did that change?
[10:25] <mvo> pstolowski: I used to have code like "repo.Plug(snapName, plugName).Connection > 0" to figure out if the plug is connected
[10:28] <pedronis> mvo: well repo is quite in flux
[10:28] <mvo> pstolowski: aha, I see, repo is now handing out PlugInfo instead of Plug, hmm
[10:28] <pstolowski> mvo, indeed
[10:29] <mvo> 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] <pstolowski> mvo, let me see
[10:29] <Chipaca> 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] <mborzecki> Chipaca: thanks for reviewing
[10:30] <Chipaca> mborzecki: give me a shout when you have it, so that i can give it a last once-over
[10:30] <mvo> pstolowski: aha! I think I found it
[10:30] <mborzecki> ack
[10:30] <Chipaca> 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] <pstolowski> mvo, are you thinking about repo.Connected(..)?
[10:31] <mvo> pstolowski: yes
[10:31] <pstolowski> mvo, i
[10:31] <mvo> pstolowski: or is this misleading?
[10:32] <pstolowski> mvo, i'm wondering if it's good, it takes plugOrSlot
[10:32] <pstolowski> mvo, we could have a "precise" helpe
[10:32] <pstolowski> r
[10:33] <mvo> pstolowski: thanks, its ok for now, I will dig a bit more but this unblocks me. thanks for your help
[10:36] <pstolowski> 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] <pstolowski> s/true/bool/
[10:45] <Chipaca> mvo: in your review of #4153, did you forget to +1?
[10:45] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[10:45] <Chipaca> mvo: i see a lot of \o/'s and no /o\ and no +1
[11:05] <mvo> 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] <Chipaca> mvo: I don't like it, but C is C -- if i liked it i'd write more of the stuff
[11:06] <mvo> pstolowski: thanks, I think its fine for now, but if I need something more targeted I will keep it in mind
[11:06] <mvo> Chipaca: heh, fair point
[11:06] <cjwatson> oh I could tell you stories about weird stuff caused by omitting void there
[11:06] <Chipaca> cjwatson: part of me wants you to
[11:06] <Chipaca> cjwatson: the other part is already a block away, screaming
[11:08] <mvo> cjwatson, Chipaca: heh :)
[11:08] <cjwatson> 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] <mvo> 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] <mborzecki> mvo: c-unit-tests-gcc failed on debian unstable
[11:11] <mborzecki> as a result of enabling -Wextra warnings
[11:11] <mvo> mborzecki: aha, nice. so it noticed that this was probably unintentional? thats smart
[11:11] <mborzecki> and the CI builds will fail on warnings now :)
[11:12] <mvo> mborzecki: and if there is a "fall-though" comment that is the magic to make it pass?
[11:12] <mvo> mborzecki: (i.e. the line below)?
[11:13] <mborzecki> yes, gcc/clang will match that agains some built-in regexes that cover different variations of 'fall through'
[11:13] <mvo> mborzecki: neat
[11:13] <mup> PR snapd#4141 closed: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4141>
[11:13] <mup> PR snapd#4153 closed: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4153>
[11:22]  * zyga-ubuntu takes a longer break to check if he can work today, 
[11:22] <zyga-ubuntu> I don't feel good
[11:23]  * sergiusens is going to be on and off today; off according to the records
[11:49] <mborzecki> 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] <mborzecki> i would assume the idea is to converge all distros to having a single package?
[11:56] <zyga-ubuntu> yes
[11:59] <cjwatson> 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] <zyga-ubuntu> cjwatson: no, I don't think we did
[12:00] <zyga-ubuntu> cjwatson: unless it's udev tagging, we use device cgroups more than before
[12:00] <cjwatson> 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] <cjwatson> it seems like a surprising category of problems to be new, though
[12:02] <zyga-ubuntu> 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] <cjwatson> if udev is now mandatory then I think snapd is missing a dependency on it
[12:03] <cjwatson> yeah, that's believeable
[12:03] <cjwatson> where does that configure hook live?
[12:06]  * cjwatson installs udev and tries again
[12:07] <zyga-ubuntu> cjwatson: for core it's a bit special, I honestly don't know
[12:09] <ogra_> 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] <cjwatson> ta
[12:11] <niemeyer> Hellos
[12:11] <niemeyer> mborzecki: Just sent the invite into the GH org
[12:12] <ogra_> Hellos like greece ? :)
[12:12] <mborzecki> niemeyer: thx
[12:13] <cjwatson> 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] <niemeyer> 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] <niemeyer> 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] <niemeyer> mborzecki: Are you missing anything else infra-wise?
[12:51]  * zyga-ubuntu -> school, I need to help my daughter 
[12:52] <zyga-ubuntu> I'm not much of help today anyway
[12:52] <Chipaca> i just threw my back out doing physio :-(
[12:53] <Chipaca> on the upside, we now know a bit more about what makes it go out
[12:53] <Chipaca> on the downside, FUCKIN' OUCH
[12:53] <mvo> niemeyer: maybe your wrote down linode key?
[12:53] <mvo> Chipaca: /o\ get well!
[12:54] <Chipaca> mvo: that's what i go to phisio for!
[12:54] <Chipaca> physio*
[12:54] <niemeyer> 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] <niemeyer> Chipaca: What was it?
[12:57] <Chipaca> niemeyer: a when my hips go to about 90 degrees pushing, something twangs
[12:57] <Chipaca> but only with my knees at a particular angle
[12:58] <niemeyer> Chipaca: Wow, that must have been pretty hard to "debug", so to speak
[12:59] <Chipaca> niemeyer: some days i wish i had a debugger
[13:00] <Chipaca> of preference one more like smalltalk's
[13:00] <Chipaca> ie that i didn't need to die for it to work
[13:00] <niemeyer> LOL
[13:01] <niemeyer> Chipaca: corpse would be a much better name for those core dumps
[13:28] <cachio> cwayne, hey, any news?
[13:32] <cwayne> cachio: havent heard from QA yet, waiting on Alex to start so I can get you access to that bug
[13:57] <mup> PR snapd#4156 closed: overlord/devicestate: switch to the new endpoints for registration <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4156>
[13:58] <pedronis> I need 2nd reviews for #4121 and #4125
[13:58] <mup> PR #4121: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/4121>
[13:58] <mup> PR #4125: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4125>
[14:03] <popey> jdstrand: do you know of any snap which successfully uses the mpris plug?
[14:05] <popey> jdstrand: specifically an audio player which can be controlled via the buttons in the sound menu on ubuntu
[14:05] <diddledan> I think gradio hooks it, whether successful or not I'm unaware
[14:06] <popey> not successful, i have it playing here and see no reference in the sound menu
[14:07] <diddledan> :-(
[14:07] <diddledan> booo
[14:08] <popey> 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] <zyga-ubuntu> pedronis: done
[14:08] <popey> I guess I should post on the forum. The problem is the documentation doesn't really cover it from a developer pov
[14:08] <davidcalle> popey gradio
[14:09] <popey> does it work for you davidcalle ?
[14:09] <davidcalle> popey: I did a fresh install last week, so I can't re-check right away, but it worked fine afair
[14:10] <popey> on 17.10?
[14:10] <davidcalle> popey: that's what I'm giving a try now
[14:11] <popey> ok, works on 17.10
[14:12] <davidcalle> popey: works fine on 17.10
[14:12] <popey> not on 16.04 unity
[14:20] <mborzecki> i'm done for today, till tomorrow
[14:22] <mup> PR snapd#4159 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4159>
[14:26] <mup> PR snapd#4160 opened: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4160>
[14:30] <jdstrand> 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] <jdstrand> s/those/those ^/
[14:31] <mvo> thank you jdstrand
[14:32] <mvo> 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] <jdstrand> mvo: cool (that is what i was thinking)
[14:32] <jdstrand> 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] <jdstrand> 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] <mvo> 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] <jdstrand> mvo: I also wanted you to be aware of https://github.com/snapcore/snapd/pull/4157
[14:34] <mup> PR #4157: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157>
[14:34] <jdstrand> mvo: it isn't ready to commit yet (it found a bug in firewall-control :)
[14:34] <Chipaca> popey: I don't know about successful, but: google-play-music-desktop-player, vlc, gradio (from a quick search)
[14:35] <mvo> jdstrand: yeah, thats really nice, I looked at it this morning briefly
[14:35] <popey> i tried copying the gradio mpris config but it barfs when i install the snap
[14:35] <mvo> jdstrand: thanks for that!
[14:35] <popey> https://www.irccloud.com/pastebin/vhbIilEC/
[14:35] <jdstrand> 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] <jdstrand> mvo: ah cool
[14:35] <mvo> yes
[14:36] <jdstrand> 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] <jdstrand> not uhid. the network-control one
[14:37] <jdstrand> anyway, it is finding things :)
[14:37] <jdstrand> s/back/backend/
[14:38] <jdstrand> mvo: fyi, there may be one more cgroup fixup PR (something I need to investigate for ondra)
[14:42] <mvo> jdstrand: ok, so I will wait a bit before jumping to any 2.29.3
[14:43] <jdstrand> mvo: fyi I was just passing through 4040 and it may be ready
[14:44] <jdstrand> (I didn't look at it, just saw the comments from the submitter)
[14:46] <mvo> jdstrand: looking at it now
[14:46] <popey> \o/ mpris success
[14:46] <jdstrand> popey: oh, I missed your comment, but glad you got it working :)
[14:47] <popey> works on 17.10 but not on 16.04 :(
[14:47] <popey> (is that expected?)
[14:47] <mup> PR snapd#4040 closed: interfaces: add USB interface number attribute in udev rule for serial-port interface <Created by musicguitar> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4040>
[14:53] <popey> 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] <jdstrand> popey: no. dbus and mpris access I can just handle, unless it is weird and I'd request discussion in the forum
[14:56] <popey> ok
[14:57] <jdstrand> popey: actually, why are you using both?
[14:58] <jdstrand> popey: cause there are two names it is known by?
[15:09] <popey> hm
[15:10] <popey> good question!
[15:10] <popey> lemme fix it
[15:10] <Odd_Bloke> 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] <popey> source: ./*  ?
[15:15] <jdstrand> mvo: I am seeing this:
[15:15] <jdstrand> Running vet
[15:15] <jdstrand> overlord/ifacestate/helpers.go:358: arg plug for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Plug
[15:15] <jdstrand> overlord/ifacestate/helpers.go:398: arg slot for printf verb %s of wrong type: *github.com/snapcore/snapd/interfaces.Slot
[15:15] <jdstrand> mvo: I'm up to date on master and looked at upcoming PRs, but don't see fixes
[15:15] <Odd_Bloke> popey: "ValueError: local source (./*) is not a directory"
[15:16] <popey> :(
[15:17] <Odd_Bloke> .tox in particular is a problem because something breaks when snapcraft tries to copy from it.
[15:17] <zyga-ubuntu> jdstrand: I saw that too, I think it's a vet bug honestly
[15:17] <zyga-ubuntu> jdstrand: unless not the same thing
[15:17] <Chipaca> jdstrand: it's a pluginfo, so it has a String(), so %s works
[15:17] <jdstrand> that's all fine. what I'm hearing is everyone is currently just ignoring the vet error?
[15:18] <jdstrand> or do I need to redo godeps or something?
[15:18] <zyga-ubuntu> jdstrand: I just ignore it
[15:19] <mvo> jdstrand: let me check
[15:19] <mvo> jdstrand: I have not seen it, it seems like the go vet on linode is less strict
[15:19] <jdstrand> huh
[15:20] <mup> PR snapd#4113 closed: tests: test for desktop interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4113>
[15:20] <Chipaca> why does it think it's a Plug and not a PlugInfo?
[15:20] <popey> jdstrand: looks like it needs both, yes
[15:21] <jdstrand> popey: do you have snappy-debug output I can see?
[15:21] <popey> sure, one moment
[15:21] <popey> oh, when it fails, or when it succeeds?
[15:21] <mvo> Chipaca, jdstrand might be a recent merge that broke it, I'm looking now
[15:22] <jdstrand> popey: because the dbus one is doing what the mpris interface is supposed to do, but with a different name
[15:22] <jdstrand> popey: does mpris with 'name: auryo' and another mpris with 'name: auryo-player' work?
[15:23] <popey> the one that's in the store works on 17.10
[15:23] <jdstrand> popey: (ie, you create two slots and slots both)
[15:23] <popey> sorry, can you gimmie a pastebin? I don't fully understand
[15:23] <ogra_> 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] <popey> http://paste.ubuntu.com/25911480/ is what it looks like currently
[15:24] <ogra_> jdstrand, (yes/no is enough as answer)
[15:24] <popey> (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] <popey> so mine is based on the gradio snap which is in the store
[15:24] <jdstrand> popey: http://paste.ubuntu.com/25911484/
[15:24] <popey> lemme try that
[15:24] <mvo> 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] <jdstrand> ogra_: execution of binaries is allowed. the trick is getting all the libs to work, etc
[15:25] <ogra_> jdstrand, ok, thanks ...
[15:25] <jdstrand> ogra_: but the security policy allows it
[15:26] <Chipaca> mvo: my 16.04 vet on master throws that error
[15:26] <jdstrand> ogra_: (mrwklix used for write and mrkix for read)
[15:26] <ogra_> ok
[15:27] <mvo> Chipaca: how strange, let me look harder
[15:27] <ogra_> Mr. Kix and Mr. Wklix :)
[15:27] <jdstrand> mvo: fyi, I'm seeing this with run-checks in a 16.04 lxd container
[15:27] <jdstrand> ogra_: hehe :)
[15:28] <jdstrand> mvo: (host is 17.10, logged into 16.04 container, running go vet)
[15:29] <jdstrand> mvo: do you need more info than that?
[15:30] <mvo> jdstrand: no, must be something on my side then, checking
[15:30] <mvo> checking why I don't see the error
[15:31] <Chipaca> waait
[15:31] <Chipaca> jdstrand: can you remove pkg and try again?
[15:33] <jdstrand> Chipaca: remove pkg? (sorry if I'm dense)
[15:33] <jdstrand> oh in gopath
[15:33] <Chipaca> jdstrand: rm "${GOPATH%%:*}/pkg"
[15:33] <Chipaca> -r
[15:34] <jdstrand> that worked
[15:34] <jdstrand> mvo: ^
[15:34] <mvo> aha!
[15:34] <mvo> thanks Chipaca
[15:34] <Chipaca> np
[15:34] <popey> jdstrand: that worked, thanks. uploaded a new auryo
[15:34] <jdstrand> popey: cool :)
[15:35] <jdstrand> Chipaca, mvo: I need to keep a list of things to try. removing pkg, govendor, ...
[15:35] <diddledan> what should I try snapping next?
[15:36] <popey> diddledan: want suggestions? :)
[15:36] <diddledan> please :-)
[15:36] <popey> was gonna suggest nba-go but you already fixed it ;)
[15:36] <diddledan> lol
[15:37] <diddledan> I've got supertuxkart working. I need to get it in the store
[15:37] <popey> diddledan: how about https://forum.snapcraft.io/t/audacity-2-2-0-snap-issues/2719 ? :)
[15:37]  * diddledan goes looksee
[15:41] <Chipaca> diddledan: simcity :-)
[15:43] <jdstrand> popey: ok, done. please snap install it from the store and verify it does what you want
[15:43] <popey> doing now
[15:46] <kyrofa> kalikiana, did you hear about the BlockingIOError discoveries?
[15:46] <kyrofa> I know you were hitting those as well
[15:46] <popey> jdstrand: works as expected (on 17.10), thank you!
[15:46] <popey> will start a thread about 16.04 on the forum
[15:47] <jdstrand> popey (cc flexiondotorg): also, not sure if you saw, but I recommend snappy-debug be used now instead of raw logs. I fixed a bunch of issues with it based on sprint feedback
[15:47] <popey> awesome, will do that
[15:48] <jdstrand> most notably, it doesn't skip dbus any more
[15:48] <popey> i noticed it gave some (more) helpful output when I ran it earlier, good job, thanks!
[15:48] <jdstrand> awesome :)
[15:48] <jdstrand> yw
[15:50] <jdstrand> popey: note that auryo has an executable stack:
[15:50] <jdstrand>  - functional-snap-v2:execstack
[15:50] <jdstrand> 	Found files with executable stack. This adds PROT_EXEC to mmap(2) during mediation which may cause security denials. Either adjust your program to not require an executable stack, strip it with 'execstack --clear-execstack ...' or remove the affected file from your snap. Affected files: opt/Auryo/auryo
[15:51] <jdstrand> 	https://forum.snapcraft.io/t/snap-and-executable-stacks/1812
[15:51] <jdstrand> ./auryo_2.snap: FAIL
[15:51] <jdstrand> why didn't the store notice that...
[15:51]  * jdstrand will look into it
[15:52]  * popey shrugs
[15:52] <popey> it's an electron app
[15:52] <popey> I imagine this is not the only app which has this issue - maybe look at discord and yakyak as other examples
[15:52] <popey> (they're snapped identically)
[15:52] <jdstrand> popey: I mentioned it to the discord guys
[15:53] <jdstrand> popey: I haven't to yakyak (didn't know about it)
[15:53] <jdstrand> popey: is this using electron builder? if so, perhaps it can be made to clear the execstack
[15:53] <popey> no
[15:54] <popey> all three are just dumping their pre-built stuff into a snap
[15:54] <popey> two are proprietary, so we don't have visibility of the source to build
[15:55] <jdstrand> ok, then them clearing it as part of their process is the way to go
[15:55] <jdstrand> I'll see why the store isn't detecting it. it might be a 16.04 vs 17.10 thing
[15:56]  * zyga-ubuntu feels better and starts coding again
[15:59] <zyga-ubuntu> feeling better is still better than feeling worse
[16:00] <mup> PR snapd#4161 opened: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
[16:02] <kyrofa> elopio, the autopkgtest I spun up yesterday morning still hasn't run :(
[16:04] <elopio> kyrofa: no, I'm waiting since saturday :(
[16:04] <kyrofa> elopio, no way
[16:04] <kyrofa> Really?
[16:04] <kyrofa> Gosh
[16:04] <popey> there was a big queue last week but it cleared
[16:05] <popey> (I saw leo complain about the builders queue previously I think) ?
[16:05] <nacc> a bunch of things are going through today, it seems like
[16:05] <nacc> (from uploads i did last week, as well)
[16:05] <popey> still only 40 min queue
[16:05] <nacc> one of my snap LP builds took 48 hours to run :)
[16:06] <kalikiana> kyrofa: discoveries?
[16:07] <kyrofa> kalikiana, still don't know why Travis is tossing the BlockingIOError, but it's masking actual test failures-- run the test that's failing locally, and you'll see them
[16:07] <mup> PR snapd#4162 opened: interfaces/kmod: treat failure to load module as non-fatal <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4162>
[16:07] <elopio> cachio: most of the queue is snapd. Do you really need to run autopkgtests on every pr?
[16:08] <popey> diddledan: how about calibre? They rev frequently. Something which builds a calibre snap which updates frequently would be nice. Popular app too
[16:09] <kalikiana> kyrofa: last time I double checked one of those locally it was passing - are you talking about a particular one?
[16:09] <diddledan> ok, so on my todo then: audacity, simcity/lincity, and calibre
[16:09] <kyrofa> kalikiana, all the ones where it has happened to me :)
[16:10] <diddledan> hah someone said the word calibre in the ubuntu podcast telegram. jinx!
[16:11] <ogra_> calibre totally doesnt fit in that list ! ... the the others are cities !
[16:11] <kalikiana> kyrofa: right. Just wondering if it's the same from your description
[16:11] <diddledan> lol
[16:11] <diddledan> calibrecity?
[16:11] <Odd_Bloke> Hey folks, just posted about a problem with creating a snap I'm having: https://forum.snapcraft.io/t/creating-a-snap-with-a-bunch-of-python-scripts/2735
[16:11] <ogra_> approved !
[16:11] <Odd_Bloke> Input appreciated. :)
[16:12] <nacc> Odd_Bloke: for classic snaps (at least), you're goign to want to build python in your snnap
[16:13] <nacc> Odd_Bloke: fyi, otherwise you'll almost certainly get segfaults
[16:13] <nacc> (well, ont almost certainly, but you might :)
[16:13] <Odd_Bloke> nacc: The scripts don't even end up pointing at the Python in the snap.
[16:13] <nacc> Odd_Bloke: even with the shebang rewriting?
[16:14] <Odd_Bloke> nacc: Well, I think the problem is that I can't get snapcraft to get the scripts in there using the python plugin.
[16:14] <kyrofa> shebang rewrites don't happen with the dump plugin
[16:14] <Odd_Bloke> So I'm not getting the shebang rewrites.
[16:14] <kyrofa> Odd_Bloke, your shebangs wouldn't need to be rewritten if they used /usr/bin/env
[16:14] <nacc> Odd_Bloke: i thinkn you'd need to either use env, or have wrappers
[16:15] <Odd_Bloke> Uh, they are using /usr/bin/env.
[16:15] <Odd_Bloke> Let me double-check what's going on.
[16:16] <Odd_Bloke> Oh, this may be a Python 2 vs 3 issue.
[16:17] <elopio> kyrofa: do you know of a snaps that builds python? I need python3.6.
[16:18] <nacc> elopio: https://git.launchpad.net/usd-importer/tree/snap/snapcraft.yaml
[16:18] <nacc> elopio: we build python2 and 3
[16:23] <elopio> thanks nacc. I had something similar but was getting  "libpython3.6m.so.1.0: cannot open shared object file: No such file or directory"
[16:24] <elopio> I'll try copying some parts from yours
[16:25] <nacc> elopio: that is a classic snap, but i don't thinkn it should matter for building
[16:25] <elopio> nacc: no, I think my problem was the missing --prefix.
[16:26] <nacc> elopio: ah sure
[16:28] <diddledan> popey: regarding audacity, I've sent a tempdir patch upstream: https://github.com/audacity/audacity/pull/211
[16:28] <mup> PR audacity/audacity#211: Update defaultTempDir path in AudacityApp.cpp <Created by diddledan> <https://github.com/audacity/audacity/pull/211>
[16:29] <diddledan> still getting problems with it beyond those issues tho
[16:29] <popey> nice
[16:31] <diddledan> in jailmode audacity gets nuked by seccomp: Log: auid=1000 uid=1000 gid=1000 ses=5 pid=24254 comm="audacity" exe="/snap/audacity/x3/usr/bin/audacity" sig=31 arch=c000003e 50(listen) compat=0 ip=0x7f2d2ad911d7 code=0x0
[16:31] <diddledan> I'm wondering what it's listening on
[16:33] <diddledan> in devmode we're getting a different segfault: audacity: src/hostapi/alsa/pa_linux_alsa.c:1454: BuildDeviceList: Assertion `devIdx < numDeviceNames' failed.
[16:33] <kalikiana> lool: You mentioned in you had a snap that snapcore/snapcraft#1654 was making work, that didn't build before?
[16:33] <mup> PR snapcraft#1654: autotools: cross-compile using --host instead of env <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1654>
[16:34] <lool> kalikiana: Yes
[16:34] <lool> kalikiana: just do a simple autotools snap with e.g. gnu hello
[16:34] <lool> when trying to cross-build for e.g. armhf, it will pass --host=armhf instead of --host=arm-linux-gnueabihf and it will fail to find compilers and bail out at configure
[16:35] <elopio> nacc: it works! Thank you :)
[16:35] <popey> diddledan: yeah, i had same, dunno what it's doing.
[16:36] <popey> diddledan: used snappy-debug.security scanlog?
[16:36] <diddledan> yup
[16:36] <diddledan> in devmode the only denials are for xdg-user-dirs
[16:36] <diddledan> Log: apparmor="ALLOWED" operation="open" profile="snap.audacity.audacity" name="/etc/xdg/user-dirs.conf" pid=25382 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16:37] <diddledan> and Log: apparmor="ALLOWED" operation="open" profile="snap.audacity.audacity" name="/etc/default/nss" pid=25382 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16:37] <diddledan> those are the only two messages in devmode with my tmpdir patch
[16:38] <kalikiana> lool: Okay, will try that. I noticed it made no difference in our autotools hello world so I'm looking to fix that
[16:38] <kalikiana> Thanks
[16:39] <jdstrand> diddledan: the first should be fixed in 2.29
[16:39] <kalikiana> ha, doesn't even configure, nice
[16:43] <nacc> elopio: yw
[16:43] <popey> jdstrand: diddledan i don't believe it is fixed in 2.29 - I'm on 2.29 here and I still see it
[16:44] <kalikiana> kyrofa: seems like our autotools-hello sucks as a test case, if you agree I'll replace it in your --host PR so it actually passes only with your fix
[16:49] <kyrofa> kalikiana, agreed
[16:50] <kyrofa> Sorry, lost power here, didn't realize my modem was plugged into one of the "surge only" outlets of the UPS
[16:50] <kyrofa> Hopefully that lasts for a while
[16:50] <kyrofa> Coding by Candlelight baby
[16:50] <ogra_> romantic !
[16:53] <kalikiana> kyrofa: ouch. hope nothing got lost
[16:53] <kyrofa> Nah
[16:53] <cjwatson> popey: builders and autopkgtests are very separate queues FWIW, even though they share clouds
[16:53] <popey> ah okay :)
[16:54] <jdstrand> popey: https://github.com/snapcore/snapd/commit/acc3eadfb5fb1e6c7553104646cb128646ac2d50 (2.29.2)
[16:55] <popey> k
[17:09] <kalikiana> kyrofa: Hrmmm how do your strange "subfolders" in git work? `git push kyrofa autotools_cross_host` doesn't work... I don't know how to specify the "bugfix" component
[17:10] <kalikiana> need to change location, getting kicked out of the coffee shop, back in a bit
[17:20] <kyrofa> kalikiana, it's part of the branch name. bugfix/<bugref>/description
[17:21] <mup> PR snapd#4163 opened: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
[17:27] <zyga-ubuntu> jdstrand: hey
[17:28] <zyga-ubuntu> jdstrand: not sure if you have energy for reviews today
[17:28] <zyga-ubuntu> Pharaoh_Atem: hey
[17:28] <zyga-ubuntu> guess which OS I'm running?
[17:29] <jdstrand> zyga-ubuntu: I need to look into an issue for ondra first, but feel free to give me the list on irc
[17:30] <zyga-ubuntu> jdstrand: I'm chopping new features into PRs, adding tests as needed, I just one have 4163
[17:30] <zyga-ubuntu> jdstrand: I'm not well today
[17:33] <jdstrand> zyga-ubuntu: sorry to hear that. hope you feel better
[17:34] <zyga-ubuntu> jdstrand: thank you, I'm slightly better now
[17:36] <popey> jdstrand: just noticed a minor typo in snappy-debug... "If have dropped messages, use:"
[17:37]  * diddledan have dropped message
[17:39] <Pharaoh_Atem> zyga-ubuntu: Ubuntu?
[17:40] <zyga-ubuntu> Pharaoh_Atem: MINIX 3 :D
[17:40]  * zyga-ubuntu has some humor back
[17:52] <kalikiana> kyrofa: Whatever I try I get doesn't exist or permission denied... how is it supposed to work?
[17:52] <kyrofa> kalikiana, well, what exactly are you trying?
[17:54] <kalikiana> kyrofa: Trying to push, like I said, doesn't work...
[17:54] <kalikiana> `git push kyrofa bugfix/autotools_cross_host` gives me "src refspec [...] does not match any.."
[17:55] <kyrofa> kalikiana, what is the `kyrofa` remote?
[17:56] <kalikiana> kyrofa: »   url = https://github.com/kyrofa/snapcraft.git
[17:56] <kalikiana> »   pushurl = git@github.com:kyrofa/snapcraft.git
[17:56] <kalikiana> »   fetch = +refs/heads/*:refs/remotes/kyrofa/*
[17:57] <kalikiana> This pattern normally works for any branch from another user or project
[17:57] <kyrofa> kalikiana, and the branch is checked out locally as `bugfix/autotools_cross_host` ?
[17:58] <kalikiana> kyrofa: it's called autotools_cross_host - so bugfix should be part of the name?
[17:58] <kyrofa> kalikiana, it means you're trying to push a branch you don't have
[17:58] <kyrofa> kalikiana, try `git push kyrofa autotools_cross_host:bugfix/autotools_cross_host`
[18:00] <kalikiana> oh
[18:00] <kalikiana> that worked
[18:00] <kalikiana> kyrofa: Thanks!
[18:02] <kalikiana> clearly a dwim version without twice redundant arguments would be boring
[18:02]  * kalikiana wipes a tear for bzr
[18:03] <mup> PR snapd#4164 opened: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4164>
[18:05] <mup> PR snapd#4165 opened: interfaces/raw-usb: match on SUBSYSTEM, not SUBSYSTEMS <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4165>
[18:06] <jdstrand> mvo: those are the last of the known udev tagging fallout fixes ^. That is the fix for ondra I mentioned. I milestoned the second for 2.29
[18:13] <zyga-ubuntu> jdstrand: do you think we should parse udev rules?
[18:14] <zyga-ubuntu> jdstrand: and have you seen https://github.com/snapcore/snapd/pull/4144
[18:14] <mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
[18:14] <jdstrand> zyga-ubuntu: I have a spread test up for review that would catch stuff like this
[18:15] <jdstrand> jeez, no I did not see that
[18:17] <kalikiana> kyrofa: btw mind having another look at snapcraft#1412 which you reviewed before?
[18:17] <mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
[18:18] <zyga-ubuntu> jdstrand: I'll merge master to fix the conflicts
[18:18] <zyga-ubuntu> jdstrand: but review is very much welcome
[18:20] <mup> PR snapd#4166 opened: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/4166>
[18:21] <cachio> elopio, there is a plan to remove that to nightly
[18:21] <cachio> elopio, it is comming soon
[18:21] <cachio> I need some confirmation before removing this
[18:21] <cachio> jdstrand, https://paste.ubuntu.com/25912364/
[18:22] <cachio> jdstrand, any idea what I need to plug to avoid this error
[18:23] <jdstrand> cachio: the security policy does't like that you are connecting from unconfined. if you have a snap that plugs network-status, I think it would work
[18:23] <jdstrand> that said, that would be a bug in network-status
[18:24] <jdstrand> I'll take a look at that (added to todo for next batch of policy updates, but not for today)
[18:25] <cachio> jdstrand, sure, thanks
[18:27] <elopio> thanks cachio
[18:27] <elopio> cachio: also, you could run the tests for amd64 in travis with adt-lxd. We are close to get that working.
[18:31] <cachio> elopio, well, we are using linode to do that, do you how much you pay for test machines in travis? does it provide any 32 bits machines?
[18:38] <zyga-ubuntu> jdstrand: I merged master into https://github.com/snapcore/snapd/pull/4144
[18:38] <mup> PR #4144: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
[18:38] <zyga-ubuntu> if you have udev energy in you left please have a look
[18:38] <zyga-ubuntu> I can polish that based on your and pawel's feedback
[18:38] <zyga-ubuntu> and it can go into .3 (I suspect we have to)
[18:41] <jdstrand> ack
[18:41] <zyga-ubuntu> jdstrand: thank you, I guess you can ignore the non-udev PRs for now
[18:41] <zyga-ubuntu> (bigger fire)
[19:15] <mup> PR snapd#4167 opened: cmd/snap-update-ns: fix golint and some stale comments <Created by zyga> <https://github.com/snapcore/snapd/pull/4167>
[19:27] <mup> PR snapd#4168 opened: cmd/snap-update-ns: add new helpers for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4168>
[19:40] <ikey> zyga-ubuntu, i saw you on here as zyga-solus a few times, were you doing anythings there that i could be tripping over?
[19:40] <ikey> wanna get solus snapd rebased and integrated
[19:46]  * elopio goes to the bank before the rain
[19:47] <elopio> cachio: we are using the travis free account, and it doesn't provide 32 machines.
[19:47] <zyga-ubuntu> ikey: no, I didn't do anything more I'm afraid
[19:47] <zyga-ubuntu> ikey: go ahead and rebase, note that we'll have 2.29.3 soon
[19:47] <zyga-ubuntu> (with more fixes)
[19:47] <ikey> is 29 stable or unstable?
[19:47] <zyga-ubuntu> but those should be clean for solus
[19:47] <zyga-ubuntu> unstable still with udev fixes incoming
[19:48] <zyga-ubuntu> but if you rebase for .2 you should be ready for .3 soon
[19:48] <ikey> right
[19:48] <ikey> so it makes sense to get us on the unstable branch
[19:48] <ikey> gonna be a massive pita working out the pending status of existing fixes otherwise
[19:48] <ikey> ok ill make a tarball of snapd 2.29.2
[19:48]  * ikey has a magic script somewhere
[19:50] <ikey> snapd-2.29.2.tar.xz ready, heh
[19:50] <ikey> https://dev.solus-project.com/source/common/browse/master/Scripts/goget.sh <- abomination
[19:50] <mup> PR snapd#4169 opened: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
[19:50] <ikey> but "works"
[19:53]  * zyga-ubuntu pushed a few PRs for upcoming layouts
[19:55] <zyga-ubuntu> I _guess_ I'm done for today
[19:55] <zyga-ubuntu> painkillers and other "meds" made 2nd half of my day useful but I'm far from being good
[19:56] <ikey> :/
[19:56] <ikey> "get well soon" ?
[19:56] <zyga-ubuntu> thanks :)
[19:56] <zyga-ubuntu> just bad luck with my back and the weather sucks :/
[19:56] <zyga-ubuntu> I want back to Spain :(
[19:56] <ikey> ah
[19:57] <zyga-ubuntu> I have a few more bits of code I could share but I think this is more than enough for now
[19:57] <zyga-ubuntu> well...
[19:57] <zyga-ubuntu> well
[19:57] <zyga-ubuntu> I could share one more function
[19:57] <ikey> lol
[19:57] <zyga-ubuntu> but we have 43 PRs already
[19:57] <zyga-ubuntu> damn it... :D
[19:57] <ikey> damn
[19:58] <zyga-ubuntu> and I have steam open just now
[19:58]  * ikey too
[19:58] <zyga-ubuntu> btw, does steam work on solus with amd GPus?
[19:58] <ikey> yeah
[19:58] <zyga-ubuntu> I have a pair of ...
[19:58]  * zyga-ubuntu checks
[19:58] <ikey> testing a regression with hitman here
[19:58]  * ikey also has steam open lol
[19:58] <ikey> just put out LSI 0.6
[19:58] <ikey> im hoping the next major will be the snap
[19:58] <ikey> and we can start ripping steam out of solus itself
[19:58] <zyga-ubuntu> AMD R9 280X (AFAIK)
[19:59] <ikey> should be good after full updates
[19:59] <ikey> so that amdgpu kicks in properly
[19:59] <ikey> (on 4.13)
[19:59] <zyga-ubuntu> I'll install solus on a 2nd HDD and see what works
[19:59] <zyga-ubuntu> I'm kind of curious
[19:59] <ikey> we're a few weeks out yet from a release and im getting my headline features together
[19:59] <ikey> can't just do refreshed ISOs anymore
[19:59] <zyga-ubuntu> it's a budget gaming box, with amd x4 845 and a pair of old used GPus
[20:00] <ikey> LSI will make sure the open source drivers at the very least
[20:00] <ikey> and the steam package depends on LSI and a buttload of libs
[20:00] <ikey> to make sure all the games work
[20:00] <zyga-ubuntu> yeah, I was curious about how that works
[20:00] <zyga-ubuntu> that's why I want to try
[20:00] <ikey> *open source drivers work
[20:00] <ikey> so for that we blacklist libstdc++ vendoring in LSI
[20:00] <ikey> which is how it magically works
[20:01] <ikey> https://github.com/solus-project/linux-steam-integration/blob/master/src/intercept/main.c#L108
[20:01] <ikey> ^^
[20:02] <ikey> can't have our users doing obscure `find | xargs rm -rf` commands..
[20:02] <zyga-ubuntu> :D
[20:02] <ikey> todays change was slightly terrifying
[20:02] <ikey> new games are shipping with vendored libressl..
[20:03] <ikey> very, very old libressl
[20:03] <ikey> so i had to teach the intercept module to redirect versioned libssl/libcrypto to a lib{ssl,crypto}-libressl.so on the fly..
[20:03] <ikey> cuz security. -_-
[20:03] <ikey> (some of them are shipping 5+ year old openssls, old curls, etc.)
[20:04] <zyga-ubuntu> that's pretty interesting
[20:04] <zyga-ubuntu> we have one problem with libc and shm_open
[20:04] <ikey> o?
[20:04] <zyga-ubuntu> I wonder if we coudl capture and redirect that function to something snap-aware (but context aware too)
[20:04] <zyga-ubuntu> some calls need to be left as-is
[20:04] <ikey> you could but only for non-setuid binaries
[20:05] <ikey> lsi is using LD_AUDIT for this
[20:05] <ikey> and LD_PRELOAD for the other portion
[20:05] <zyga-ubuntu> some should be tweaked so that the created /dev/shm thing is scoped to the snap
[20:05] <ikey> basically we hijack c lib
[20:05] <zyga-ubuntu> yeah,
[20:05] <ikey> and linker..
[20:05] <zyga-ubuntu> I think we may need to as well
[20:05] <zyga-ubuntu> I'll need to read your code :)
[20:05] <ikey> please do - i tried to keep it simple enough and functional
[20:05] <zyga-ubuntu> but first...
[20:05] <ikey> lol ya
[20:05] <zyga-ubuntu> some gameing :)
[20:05] <ikey> enjoy!
[20:05] <zyga-ubuntu> I'm re-playing wolf games before looking at new colossus
[20:06] <ikey> :D
[20:07] <ikey> "/home/ufee1dead/.local/share/Steam/steamapps/common/Hitman™/bin/libffmpegsumo.so"
[20:07]  * ikey dies inside
[20:07] <ikey> TM in a path
[20:09] <zyga-ubuntu> oh wow
[20:09] <zyga-ubuntu> someone was NACKed by legal :D
[20:13] <kalikiana> clobrano: hey
[20:13] <kalikiana> clemensv:  can you respond to my comment here snapcraft#1648 ?
[20:13] <mup> PR snapcraft#1648: sources: get svn revision with --show-item flag <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1648>
[20:15]  * kalikiana going to wrap up in a bit... long day
[20:17] <c-lobrano> kalikiana: hey, sure, just give me a minute
[20:17] <kalikiana> no rush
[20:23] <cachio> elopio, and how many machines does it provide within the free account?
[20:24] <cachio> elopio, I'll take a look to travis infra
[20:24] <cachio> that could be a good alternative
[20:27] <kyrofa> cachio, Travis? 5, I think
[20:28] <Pharaoh_Atem> ikey: I'm impressed something didn't explode over that
[20:29] <ikey> lol
[20:30] <cachio> kyrofa, good, thanks
[20:30] <zyga-ubuntu> darn
[20:31] <zyga-ubuntu> drat
[20:32] <zyga-ubuntu> I was supposed not to do this
[20:32] <zyga-ubuntu> jdstrand: one PR to look at
[20:33] <mup> PR snapd#4170 opened: cmd/snap-update-ns: add designWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4170>
[20:33] <zyga-ubuntu> this is the tmpfs designer
[20:33] <zyga-ubuntu> I have a good number of prerequisite branches
[20:34] <zyga-ubuntu> but this PR just adds one function for conceptually doing things and contains the most important logic
[20:34] <zyga-ubuntu> I requested you as a reviewer
[20:34]  * zyga-ubuntu really EODs now
[20:36] <cachio> zyga-ubuntu, hey
[20:36] <cachio> enjoy your EOD :)
[20:36] <zyga-ubuntu> o/
[21:36] <mwhudson> github reviews still suck for stacked PRs right
[21:37] <mup> PR snapd#4171 opened: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171>
[22:42] <dwbrite> Hello, just wanted to pop in and mention that GogLand has been renamed to GoLand, so should be updated in the Featured Snaps section of snapcraft.io
[22:45] <kyrofa> jdstrand, am I correct that a snap using the kernel-module-control plug will not be denied installation?
[22:45] <kyrofa> *sigh* WILL be denied installation
[22:49] <jdstrand> kyrofa: without a snap decl, yes
[22:49] <kyrofa> jdstrand, how do we expect people to experiment with such interfaces?
[22:49] <kyrofa> jdstrand, I've suggested people look into it instead of rolling their own kernel, but then they can't
[22:49] <jdstrand> kyrofa: if you install with --dangerous it works fine
[22:49] <kyrofa> Oh, really? Did that change recently?
[22:50] <jdstrand> no. long time ago for the reason you mentioned
[22:50] <kyrofa> Oh, whew, excellent
[22:50] <kyrofa> It's been a while then
[22:50] <jdstrand> kyrofa: if it doesn'
[22:50] <jdstrand> t work the way I described, it's a bug
[22:50] <jdstrand> but it should. people do this all the time :)