[00:02] <mup> PR snapd#4199 opened: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4199>
[00:12] <kyrofa> elopio,  are you suuuuure that adt installs squashfuse?
[00:13] <kyrofa> Because it doesn't look like it is. Can you point me to where it should be doing that?
[00:13] <kyrofa> elopio, it's not in debian/tests/control, for example
[00:49] <sergiusens> kyrofa that's done on run_lxd_container.sh
[01:48] <mup> PR snapcraft#1726 opened: schema: sources should not have defaults <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1726>
[01:48] <ikey> got my .snap files uploaded to my server for testing, buuuut
[01:48] <ikey> it does require the snapd patches ive put in today
[01:49] <ikey> and also requires --devmode --dangerous..
[01:56] <elopio> kyrofa: you are right, it is not installed, I see it failing on my WIP branch.
[02:00] <elopio> you can add --setup-commands
[03:04] <mup> PR snapd#4200 opened: Return snap-not-installed error in more cases <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4200>
[03:05] <mup> Bug #1659106 changed: snap refresh/enable/disable doesn't return snap-not-installed error, returns generic 400 instead <snapd:Fix Committed> <https://launchpad.net/bugs/1659106>
[04:27] <mup> PR snapcraft#1724 closed: tests: use the common base handler on the fake snapd server <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1724>
[06:21] <mborzecki> morning guys
[06:27] <mvo> hey mborzecki, good morning
[06:30] <mborzecki> mvo: o/
[06:30] <mborzecki> did you hear back from lenovo?
[06:31] <mvo> mborzecki: my machine needs to be send in, will take ~5-7 days or so
[06:32] <mvo> mborzecki: until then I'm with my crufty old t400
[06:32] <mvo> (and my desktop which is decently powerful)
[06:32] <mvo> mborzecki: but funny (or not) enough my desktop does not boot this morning, just hangs in the bios which is rather unfortunate. the physical world is a pain :/
[06:34] <mborzecki> hahah
[06:34] <mborzecki> is your desktop one of the ryzen builds?
[06:38] <mborzecki> hmm,2017-11-09 15:44:32 Failed project prepare: 1
[06:38] <mborzecki>     - linode:fedora-25-64:project
[06:39] <mvo> mborzecki: the desktop is a whitebox that I built from custom parts, but its not very fancy
[06:39] <mvo> mborzecki: meh, fedora failed? what in particular? its often a bit unstable in itself, or maybe -25 is eol finally and we need to bump it
[06:39] <mborzecki> /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 14: fw_printenv: command not found
[06:40] <mborzecki> this sounds like a u-boot command
[06:41] <mvo> mborzecki: yes, that is strange that it would use that on a regular machine
[06:42] <mborzecki> hm found nother one that failed like this
[06:45] <mborzecki> `if command -v grub-editenv >/dev/null; then` this line failed on fedora
[06:46] <mborzecki> maybe we're missing some bit in fedora cloud image
[06:46] <ikey> is there any reason why inside my snap a .so file might appear to be a directory when shared from home..?
[06:46] <ikey> this seems .. slightly bizarre.
[06:48] <mborzecki> ikey: probably a question for zyga-solus, my bet is on some bind mount logic that got it wrong
[06:48] <ikey> ty
[06:49] <ikey> ok this time its not a directory..
[06:49] <ikey> last time it was
[06:49] <ikey> o_O
[06:49] <mborzecki> heisenbug
[06:49] <ikey> lol
[06:51] <mborzecki> mvo: hm there's no grub-editenv in fedora, it's named grub2-editenv there
[06:51] <niemeyer> Early hellos
[06:52] <mborzecki> niemeyer: hi, isn't that like a midnight at your place?
[06:53] <niemeyer> mborzecki: Almost 5am.. crashed a bit earlier yesterday
[06:54] <niemeyer> pedronis: About the open PRs, yeah, I really need to get into reviews.. will send up the board shortly
[06:55] <mvo> niemeyer: woah, good morning
[06:57] <ikey> ok it wasnt a snap issue incidentally
[06:57] <ikey> its a weird feral thing
[06:58] <mvo> mborzecki: hm, wonder why the fedora machine suddenly starts failing, but maybe just an update
[07:01] <niemeyer> mvo: Moin!
[07:02] <zyga-solus> ikey: what did you do?
[07:02] <ikey> oh i didnt
[07:02] <ikey> so the game has "bin/libpdf.so" and "lib/libpdf.so"
[07:02] <ikey> and "bin/libpdf.so" is actually a directory
[07:02] <ikey> confused the hell out of me
[07:02] <ikey> and the linker was like "nope i dont even"
[07:06] <mborzecki> mvo: so there's a commit from Simon Fels done in may, that adds a workaround for grub2-editenv for fedora/suse in lib/prepare.sh
[07:06] <mborzecki> then, the offending lines in boot.sh were last touched in 2016
[07:08] <mborzecki> i'll try to fix this
[07:20] <mup> PR snapd#4201 opened: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4201>
[07:22] <mborzecki> mvo: l got to take care of something so I'll be afk for ~2h, opened an early PR ^^ to see if this will fix the problem
[07:22] <mvo> mborzecki: thank you
[07:23] <mborzecki> ok, talk to you later
[07:27]  * zyga-solus -> quick late breakfast
[07:27] <zyga-solus> sorry, kids were very stubborn today and were late for school
[07:28] <ikey> oh, breakfast
[07:28] <ikey> not a bad idea
[07:29]  * zyga-solus eats what kids left behind ^_^
[07:29] <ikey> :D
[07:36]  * mvo shakes fist at nvidia driver, its in a gdm3 restart loop rightnow
[07:36] <niemeyer> https://forum.snapcraft.io/t/review-sprint-4/2765
[07:37] <zyga-solus> mvo: wrong driver
[07:37] <zyga-solus> mvo: did you install it just now or update?
[07:37] <zyga-solus> niemeyer: thank you!
[07:37] <niemeyer> zyga-solus: np, that part was easy :P
[07:37] <mvo> zyga-solus: happend out of the blue which is very strange
[07:38] <mvo> zyga-solus: when I started this morning
[07:38] <zyga-solus> mvo: woah
[07:38] <zyga-solus> can you ssh into the machine?
[07:38] <zyga-solus> syslog has the details of why x cannot start
[07:38] <zyga-solus> for me it had something like "bla bla bla, use legacy driver, bla bla bla"
[07:41] <mvo> zyga-solus: yeah, it just says "nvidai: cannot load module", no worries, I will figure it out, its just super annoying
[07:41] <zyga-solus> I haven't seen that one
[07:41] <mvo> zyga-solus: google is very light on it as well
[07:43] <mvo> zyga-solus: going back to nvidia-340 "fixed" it
[07:43] <zyga-solus> mvo: from 37x?
[07:43] <mvo> from 384
[07:53] <zyga-solus> mvo: woah, 2.29.3 has plenty of things that are not in master
[07:53] <mvo> zyga-solus: yes
[07:53] <mvo> zyga-solus: its very annoying, we need to fix this
[07:53] <zyga-solus> I see I will have some merges to do in the full udev hooks branch
[07:54] <mvo> zyga-solus: should apply cleanly, no?
[07:54] <zyga-solus> mvo: not really, I did extra changes after jdstrand's desire to change formatting of udev rules
[07:54] <zyga-solus> mvo: mostly just annoying stuff in tests (extra comments and order changes)
[07:54] <mvo> zyga-solus: but all on top of the exiting commits?
[07:54] <zyga-solus> but that's ok
[07:54] <zyga-solus> ay
[07:54] <zyga-solus> yes
[07:54] <zyga-solus> that should merge cleanly!
[07:54] <zyga-solus> I didn't think about that
[07:54] <mvo> yeah, fingers crossed :)
[07:55] <zyga-solus> I wonder why is travis so red today
[07:55] <mvo> 50 open PRs, sounds like work today
[07:55] <zyga-solus> mvo: hmmm
[07:55] <zyga-solus> mvo: 2.29.3 has failing unit tests
[07:55] <mvo> zyga-solus: there was a grub-editenv issue on fedora that ma looked into earlier
[07:55] <mvo> zyga-solus: wuut?
[07:55] <zyga-solus> mvo: looks real :/
[07:56] <zyga-solus> mvo: https://s3.amazonaws.com/archive.travis-ci.org/jobs/299817751/log.txt?X-Amz-Expires=30&X-Amz-Date=20171110T075518Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171110/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=7dd8a954e140304cfb8fce57b546497414a8a6a4488ec760644b075ff5e54d23
[07:56] <zyga-solus> mvo: no idea how
[07:56] <mvo> zyga-solus: hm, that build in the ppa so it can't be universal
[07:56] <zyga-solus> mvo: maybe ungreen PR was merged into 2.29
[07:56]  * mvo looks
[07:57] <mvo> zyga-solus: https://travis-ci.org/snapcore/snapd/branches show 2.29.3.1 is green and beside fedora packaging its identical
[07:57]  * mvo looks deeper
[07:57] <zyga-solus> very confusing then
[07:57] <zyga-solus> mvo: let's see if I can reproduce
[07:59] <zyga-solus> mvo: yep
[07:59] <zyga-solus> real failure
[07:59] <zyga-solus> looking at which part is right
[07:59] <mvo> zyga-solus: can you pastebin it please?
[07:59] <zyga-solus> sure
[08:00] <zyga-solus> http://pastebin.ubuntu.com/25930345/
[08:01] <mvo> zyga-solus: strange, just trying to reproduce (via git checkout upstream/release/2.29) it is ok for me, let me dig deeper
[08:01] <zyga-solus> yep
[08:01] <zyga-solus> looks genuinely buggy
[08:01] <zyga-solus> test is right, code is wrong
[08:01]  * zyga-solus wonders
[08:01] <zyga-solus> maybe misaligned something
[08:01] <zyga-solus> I didn't do that
[08:01] <zyga-solus> I did mvo/release-2.29.3
[08:01] <zyga-solus> I recall those usb interface number PRs were recent
[08:02] <zyga-solus> maybe cross-merged badly
[08:02] <mvo> zyga-solus: oh, indeed
[08:02] <mvo> zyga-solus: that is probably it
[08:02] <zyga-solus> gah
[08:02] <mvo> there I see it as well
[08:02] <zyga-solus> ikey: I plugged a 2nd monitor to my solus box and now the "dock" at the bottom overlaps windows
[08:02]  * mvo recovers from a brief heart attack
[08:03] <zyga-solus> ikey: is this a feature I'm not aware of
[08:03] <zyga-solus> mvo: wait, so what is in 2.29.3?
[08:03] <zyga-solus> mvo: because this is _pre_ merge
[08:03] <zyga-solus> mvo: (heart attack may need to come back)
[08:04] <zyga-solus> mvo: and this is not right for sure
[08:05] <ikey> zyga-solus, mutter borkified all sane notions of reserved struts :(
[08:10] <zyga-solus> mvo: I pushed a patch to that PR
[08:10] <zyga-solus> mvo: please look
[08:10] <mvo> zyga-solus: I just looked at https://github.com/snapcore/snapd/blob/release/2.29/interfaces/builtin/serial_port_test.go and the snippet4 is missing there, i.e. we don't test this condition
[08:10] <zyga-solus> mvo: but I'm worried how is this possible
[08:10] <zyga-solus> mvo: aha
[08:11]  * ikey agrees with the C udev thingy fwiw
[08:11] <zyga-solus> mvo: can you look if the 2.29 release has the other usb-interface-num patches?
[08:11] <zyga-solus> is that a feature in this release?
[08:11] <mvo> zyga-solus: so it looks like this was added in your PR for master later and not backported to 2.29 - does that mean that theere is also a fix missing?
[08:11] <zyga-solus> mvo: I don't recall adding that, it may have come from master
[08:12] <mvo> zyga-solus: aha, it looks like 2.29 does not have the usb-interface-num, at least I can't find it in there
[08:12] <zyga-solus> mvo: let me look at the history to find this patch
[08:13] <zyga-solus> mvo: I see it in b2991126738db2e9bf041a5da014cadc436e5ae2
[08:13] <zyga-solus> mvo: which is not in release/2.29
[08:13] <mvo> zyga-solus: I did a "git grep usb-interface-n" in the release/2.29 tree and nothing there so it looks like we are good
[08:13] <mvo> zyga-solus: all good then :)
[08:13] <zyga-solus> mvo: but how is it in 2.29.3 PR?
[08:14] <zyga-solus> mvo: if you released from that branch it's going to be bogus and will fail adt
[08:14] <mvo> zyga-solus: its 2.29.3 plus master (to fix the conflicts, i.e. to make it mergable into master)
[08:15] <zyga-solus> ahhh
[08:15] <mvo> zyga-solus: the release/2.29 branch does not contain this snippet, its a new test that was added in master but now fails with the udev snippet work for 2.29
[08:15] <zyga-solus> ok
[08:15] <zyga-solus> all good
[08:15] <mvo> yes
[08:15] <zyga-solus> uff
[08:15] <mvo> exactly
[08:20]  * ikey ponders how he'd go about stracing a process inside of a snap..
[08:20] <zyga-solus> ha
[08:21] <zyga-solus> we need to add snap run --strace
[08:21] <zyga-solus> it's a common request
[08:21] <zyga-solus> it's not super easy unfortunately
[08:21] <ikey> didn't you have some magical super invocation?
[08:22]  * ikey searches forum
[08:22] <zyga-solus> no, because it requires doing a few steps
[08:22] <zyga-solus> the profile of the app has to change to allow that
[08:22] <ikey> ah yep ive pissed it off
[08:26] <ikey> ok yeah need to exclude pselect6 too
[08:35] <zyga-solus> oh, nice, autopkgtests are gone now
[08:35] <zyga-solus> mvo: do we have a way to trigger them manually?
[08:36] <mvo> zyga-solus: sort of, cachio is looking into it
[08:37] <zyga-solus> great
[08:58] <mup> PR snapd#4187 closed: tests: fix xdg-open-compat <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4187>
[09:05] <mup> PR snapd#4180 closed: interfaces/many: misc policy updates for browser-support, cups-control and network-status <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4180>
[09:11] <ikey> anyone got experience with running chrome/cef stuff under snap?
[09:11] <ikey> if i install with --classic - cef works (i.e. feral games like Hitman)
[09:11] <ikey> yet if i use --devmode, it doesn't
[09:11] <ikey> get execvp errors with empty argv[0]
[09:15] <zyga-solus> ikey: no, sorry
[09:15] <zyga-solus> what is cef?
[09:15] <ikey> like chrome-based apps
[09:15] <zyga-solus> aha
[09:15] <ikey> spotify and such
[09:15] <ikey> all have a libcef.so
[09:16] <ikey> relevant strace portion https://hastebin.com/raw/refijimafu
[09:16]  * mborzecki is back
[09:16]  * ikey can't help but notice the EPERM
[09:18] <mup> PR snapd#4157 closed: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4157>
[09:18] <zyga-ubuntu> mvo: thank you for merging that test, I will merge master into the big udev branch now
[09:26]  * ikey checks 4180 on the magical off chance it fixes the issue
[09:32] <Chipaca> mborzecki: morning sir. What is, in your view, the plan for group lookup?
[09:34] <pedronis> niemeyer: hi and ack
[09:34] <pedronis> hellp
[09:34] <pedronis> *hello
[09:36] <mvo> hey pedronis and Chipaca - good morning
[09:36] <mvo> zyga-ubuntu: your udev PR looks fine, once tests are green it can go in I think
[09:36] <niemeyer> pedronis: yo
[09:40] <pedronis> mvo: I though pstolowski requested some test tweaks for it in the 2.29 variant
[09:40] <pedronis> *I thought
[09:41] <pstolowski> for which PR?
[09:41] <mup> PR snapd#3994 closed: tests: fix revert test when a new core image is pushed <Created by sergiocazzolato> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3994>
[09:41] <mborzecki> Chipaca: i'm not strongly biased against cgo (I suppose that's the real root of the problem), and with #4185 we have a fine chance of avoiding group lookups in the code that ends up in `snapd` binary
[09:41] <mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
[09:42] <Chipaca> mvo: good morning sir
[09:42] <mborzecki> at this point what's left with cgo is snap-seccomp, and probably some tests, though I have some PRs open that try to workaround this
[09:42] <pstolowski> ah, udev pr
[09:42] <Chipaca> mborzecki: i think cgo is only a potential problem in snapd, which is long-lived; the others shouldn't be as concerned
[09:43] <Chipaca> mborzecki: so 4188 goes away?
[09:43] <Chipaca> #4188
[09:43] <mup> PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
[09:44] <mborzecki> i'd leave it open for now, and once the bits i needed are merged i'll close it
[09:46] <mborzecki> Chipaca: does that sound ok to you?
[09:46] <Chipaca> mborzecki: i'm not sure what the purpose of leaving it open is if we're not going to merge it, but i don't mind too much
[09:47] <pedronis> pstolowski: yes, I put a link to them in the non-2.29 one
[09:47] <Chipaca> beyond being in review sprint mode (ie reviews before code)
[09:47] <Chipaca> mvo: what's up with #4122? two +1's and not merged. Just waiting for green?
[09:47] <mup> PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
[09:47] <mborzecki> Chipaca: fair point, let's close it for now then, we can always reopen it if needed
[09:48] <pstolowski> pedronis, thanks
[09:48] <Chipaca> mborzecki: if i were to remove all uses of os/user and SnapDataHomeGlob in favour of a new thing, what would you need from the new thing?
[09:50] <niemeyer> Chipaca, mborzecki: Avoiding cgo in snap-seccomp is probably impossible with the current design
[09:50] <niemeyer> Ah, sorry, not seccomp
[09:50] <niemeyer> snap-update-ns
[09:50] <mup> PR snapd#4188 closed: osutil: replace cgo bits with non-cgo, vendored os/user  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4188>
[09:51] <niemeyer> Chipaca, mborzecki: Ah, and snap-seccomp too, for different reasons (libseccomp)
[09:51] <Chipaca> niemeyer: good morning to you too :-) have you even slept?
[09:51] <niemeyer> Chipaca: Sorry, good morning :)
[09:52] <Chipaca> niemeyer: ah, i didn't mean it in that way, but it works :-D
[09:52] <niemeyer> Chipaca: Yeah, I have.. went to bed earlier than usual yesterday, so started earlier today still, and will probably stop earlier too :)
[09:52] <mborzecki> Chipaca: i only needed looking up a group name using its gid, but we have a workaround for this now
[09:52] <Chipaca> niemeyer: fair enough
[09:52] <niemeyer> Chipaca: Still wondering about the cgo issue..
[09:53] <Chipaca> niemeyer: pedronis has flagged you for some reviews i see, so you've got your work cut out :-)
[09:53] <niemeyer> Chipaca: Yeah, we've got the review board too, not sure if you've seen the message earlier today
[09:54] <niemeyer> Chipaca, mborzecki: As for cgo, I'm on the fence between suggesting dropping and making that interaction more awkward vs. the benefits
[09:54] <niemeyer> We cannot drop glibc completely from the snapd environment due to the external tools we need
[09:55] <niemeyer> So the sole benefit would be a more bullet proof snapd
[09:55] <zyga-ubuntu> niemeyer: yet :)
[09:55] <zyga-ubuntu> niemeyer: the apparmor_parser thing could run in a tiny tiny tiny base snap
[09:55] <niemeyer> zyga-ubuntu: Without further information that's a bit of wishful thinking
[09:55] <Chipaca> niemeyer: going down the review board is how i saw you flagged in some
[09:55] <zyga-ubuntu> niemeyer: yeah, just saying it's not ultimately impossible
[09:56] <niemeyer> zyga-ubuntu: Yeah, but we're not able to do that any time soon
[09:56] <zyga-ubuntu> agreed
[09:56] <Chipaca> we need glibc in the core snap anyway because otherwise we'd have to link systemd against musl or something equally undersupported by upstream systemd
[09:56] <Chipaca> so from that pov i don't see the benefit
[09:56] <niemeyer> Chipaca: That's a bit of a different thing
[09:56] <Chipaca> ok :-)
[09:56] <niemeyer> Chipaca: systemd will be in the base
[09:57] <Chipaca> niemeyer: uh, no?
[09:57] <Chipaca> how?
[09:57] <niemeyer> Chipaca: uh, hopefully yes? :)
[09:57] <Chipaca> niemeyer: so you can't have more than one base?
[09:57] <Chipaca> or there is a base that's special and different?
[09:57] <niemeyer> Chipaca: Consider this: which systemd is used when the host system is Ubuntu 16.04
[09:58] <Chipaca> niemeyer: not the one in the base
[09:58] <niemeyer> Chipaca: Not the one in any snap
[09:58] <Chipaca> quite
[09:59] <niemeyer> Chipaca: Right.. so this is not actually a fundamental dependency of the snapd-carrying nsap
[09:59] <niemeyer> snap
[09:59] <Chipaca> niemeyer: consider this: what systemd starts snapd in core?
[09:59] <niemeyer> Chipaca: The one in the base ;)
[09:59] <Chipaca> niemeyer: which base?
[09:59] <Chipaca> in a special base that's baser than the rest?
[09:59] <mvo> the base of the snapd snap
[09:59] <niemeyer> Chipaca: Exactly.. I'm describing the goal
[10:00] <Chipaca> the snapd snap will have a base?
[10:00] <Chipaca> so we force solus to have a ubuntu 16 base even if none of their snaps use ubuntu 16?
[10:00] <niemeyer> Chipaca, mvo: We can have a specific base snap that is the one mounted as the root filesystem on core devices
[10:00] <Chipaca> ah
[10:00] <Chipaca> no i got it
[10:00] <Chipaca> ok
[10:01] <mvo> Chipaca: yeah, maybe not, probably more something implicit
[10:01] <Chipaca> so snapd doesn't have a base, but ubuntu core is a special base
[10:01] <Chipaca> fedora core would be a different special base
[10:01] <Chipaca> solus core would just be ikey, punching donkeys
[10:01] <niemeyer> Chipaca: It might have a base, but it might not be the one that Ubuntu Core requires
[10:02] <niemeyer> Chipaca: Not having a base might make the model simpler, though.. so this particular bit is one we still need to decide on
[10:02] <niemeyer> The status quo of base snaps is that we did not yet do the split of core
[10:02]  * mvo nods
[10:02] <Chipaca> yep
[10:02] <niemeyer> This is the second part, and it's independent of support for bases in app snaps
[10:03] <Chipaca> 's fine, i think we've discussed this "some bases can be root of core some can't" before and i forgot it
[10:03] <niemeyer> So we haven't yet firmly made such decisions, and we also haven't closed any of those doors yet
[10:03] <niemeyer> Chipaca: Yeah, and np, the conversation is healthy
[10:04] <zyga-ubuntu> mvo: hmm
[10:04] <zyga-ubuntu> ● snap-repair.timer not-found failed failed snap-repair.timer
[10:04] <zyga-ubuntu> mvo: this is from vanilla 16.04 install
[10:04] <zyga-ubuntu> we're shipping the repair timer?
[10:04] <zyga-ubuntu> ah, sorry, zesty
[10:04] <zyga-ubuntu> /lib/systemd/system/snapd.snap-repair.service
[10:04] <zyga-ubuntu> /lib/systemd/system/snapd.snap-repair.timer
[10:04] <zyga-ubuntu> it seems we are
[10:04] <zyga-ubuntu> mvo: is this really desirable?
[10:04] <mvo> zyga-ubuntu: it is disabled, no?
[10:04] <zyga-ubuntu> it's failed
[10:04] <zyga-ubuntu> not disabled
[10:04] <mvo> zyga-ubuntu: it makes packaging simpler, it has a condition
[10:05] <Chipaca> zyga-ubuntu: systemctl status snap-repair.timer ?
[10:05] <Chipaca> mvo: if you make it an assertion instead of a condition it works the same, but logs the reason
[10:05] <zyga-ubuntu> zyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.service
[10:05] <zyga-ubuntu> ● snapd.snap-repair.service - Automatically fetch and run repair assertions
[10:05] <zyga-ubuntu>    Loaded: loaded (/lib/systemd/system/snapd.snap-repair.service; static; vendor preset: enabled)
[10:05] <zyga-ubuntu>    Active: inactive (dead)
[10:05] <mvo> zyga-ubuntu: it should be in "condition failed" state which is not an error (even if it sounds like one)
[10:05] <zyga-ubuntu>      Docs: man:snap(1)
[10:05] <zyga-ubuntu> zyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.timer
[10:05] <zyga-ubuntu> ● snapd.snap-repair.timer - Timer to automatically fetch and run repair assertions
[10:05] <zyga-ubuntu>    Loaded: loaded (/lib/systemd/system/snapd.snap-repair.timer; enabled; vendor preset: enabled)
[10:05] <zyga-ubuntu>    Active: inactive (dead)
[10:05] <zyga-ubuntu> mvo: it's showing the machine as in degraded status
[10:05] <mvo> Chipaca: aha, interessting
[10:06] <mvo> zyga-ubuntu: could you please pastebin it? my irc client garbled it
[10:06] <zyga-ubuntu> sure
[10:06] <Chipaca> zyga-ubuntu: it's snap-repair.timer, not snapd.snap-repair.timer i think?
[10:06] <mvo> zyga-ubuntu: it should not make the machine degraded
[10:06] <zyga-ubuntu> http://pastebin.ubuntu.com/25930918/
[10:06] <Chipaca> at least here it is -- which might mean my local install is messed up :-) dunno
[10:06] <zyga-ubuntu> http://pastebin.ubuntu.com/25930922/
[10:07] <mvo> zyga-ubuntu: and systemctl --failed please
[10:07] <Chipaca> zyga-ubuntu: systemctl list-timers
[10:07] <mvo> zyga-ubuntu: aha, sorry you did that already
[10:07] <mvo> zyga-ubuntu: it looks like you might have leftover files from an old deb?
[10:07] <mvo> zyga-ubuntu: or maybe everyone has these (which would be bad)
[10:08] <zyga-ubuntu> mvo: no, they are part of the package
[10:08] <zyga-ubuntu> mvo: note: zesty
[10:08] <zyga-ubuntu> mvo: this is my router, not devbox
[10:08] <zyga-ubuntu> so no locally built magic files
[10:08] <zyga-ubuntu> I just noticed because I'm about to shut it down
[10:09] <mvo> zyga-ubuntu: interessting, let me try in a fresh vm. fwiw, I see the "expected" condition failed and nothing in systemctl --failed on my box (but its artful)
[10:09] <mvo> zyga-ubuntu: or is this 2.27.6 still?
[10:09] <Chipaca> strange i seem to have a mix of snapd.snap-repair.timer and snap-repair.timer. Probably need a restart sometime soon?
[10:09] <zyga-ubuntu> mvo: checking
[10:09] <mvo> zyga-ubuntu: apt list snapd
[10:10] <zyga-ubuntu> 2.28.5+17.04
[10:10] <zyga-ubuntu> curious
[10:10] <mvo> yeah, let me try in my VM
[10:10] <zyga-ubuntu> snapd/zesty-updates,now 2.28.5+17.04 amd64 [zainstalowany]
[10:10] <zyga-ubuntu> zainstalowany is installed
[10:11]  * zyga-ubuntu moves the final network part now, I'll be offline briefl
[10:11] <zyga-ubu1tu> actually not much
[10:12] <mvo> zyga-ubuntu: fresh 17.04 does not have the issue, let me try if I upgrade from 2.27 to 2.28
[10:16] <mvo> zyga-ubuntu: no luck with 2.27 -> 2.28 either on zesty. hmmm
[10:18] <mup> PR snapd#4202 opened: cmd: use a preinit_array function rather than parsing /proc/self/cmdline <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4202>
[10:21] <Chipaca> jamesh: ouch! brand new pr with conflicts
[10:24] <jamesh> Chipaca: gar.  I thought I'd pulled master.  Let me rebase it
[10:25] <Chipaca> jamesh: ta
[10:29] <Chipaca> jdstrand: did i understand you right yesterday, that in #4185 we don't actually need the group name? ie g:<gid> works just as well as g:<group name>?
[10:29] <mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
[10:30] <mborzecki> Chipaca: afaik it's g:<group-name> or <gid>
[10:30] <jamesh> Chipaca: fixed.
[10:31] <Chipaca> mborzecki: ah. any reason not to do it that way?
[10:32] <Chipaca> it doesn't buy us much, beyond not having to look up the name (i assume apparmor has to then look up the gid from the name again)
[10:32] <Chipaca> or seccomp
[10:32] <Chipaca> jamesh: thanks
[10:32] <Chipaca> jamesh: and good night :-)
[10:35] <pedronis> Chipaca: we are the one compiling seccomp, I don't think it can do runtime group lookup I suspect (not sure)
[10:36] <mvo> yeah, seccomp bpf is not very smart at all :)
[10:36] <mborzecki> Chipaca: #4185 does that, the rule is sent as fchown u:root <gid>
[10:36] <mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
[10:37] <mborzecki> we could push a little bit and use 'fchown 0 <gid>` as root user supposedly has uid 0 always
[10:37] <Chipaca> mborzecki: gah, i got confused then, sorry
[10:52] <mborzecki> damn, got an 'hr introduction' call in 10
[10:58] <mup> PR snapd#4178 closed: asserts/assertstest:  fix use of hardcoded value when the passed  or default keys should be used <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4178>
[11:08] <mup> PR snapd#4190 closed: cmd/snap-seccomp: do not use group 'shadow' in tests <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4190>
[11:09] <mup> PR snapd#4179 closed: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4179>
[11:12] <mup> PR snapd#4203 opened: tests/set-proxy-store: exclude ubuntu-core-16 via systems: key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4203>
[11:13] <pedronis> mvo: I was about to do the change requests by cachio to #4179
[11:13] <mup> PR #4179: tests:  add a spread test for proxy.store setting together with store assertion <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4179>
[11:13] <mup> PR snapd#4198 closed: release: 2.29.3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4198>
[11:13] <pedronis> mvo: ah, you made a PR but there is more tor remove
[11:14] <mvo> pedronis: uh, sorry
[11:14] <mvo> pedronis: too trigger happy. shall I close my followup then?
[11:14] <pedronis> mvo: no, let me try to push the proper fix into it
[11:14] <mvo> pedronis: thank you!
[11:19] <pedronis> mvo: done
[11:23] <mvo> pedronis: thanks again
[11:32] <mvo> pstolowski: 4152 has two (optional) comments from me, I'm inclined to merge it as it is as its really nice but please check and either merge yourself or update
[11:34] <pstolowski> mvo, thanks for the review, if there is no pressure i'll address them later today. currently debugging some other issue
[11:34] <mvo> pstolowski: no pressure at all
[11:46] <zyga-ubuntu> mvo: hey
[11:46] <zyga-ubuntu> mvo: I'm back, sorry, was fighting systemd
[11:47] <mup> PR snapd#4122 closed: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4122>
[11:47] <zyga-ubuntu> mvo: I just noticed you worked on that huge conflict
[11:47] <zyga-ubuntu> mvo: and pushed earlier than I did
[11:47] <zyga-ubuntu> mvo: I just reslved the same conflicts
[11:49] <mvo> zyga-ubuntu: hey, meh, I wanted to talk about it first but you not being on irc made me assume you are at lunch
[11:49] <mvo> zyga-ubuntu: sorry for that
[11:51] <zyga-ubuntu> mvo: no worries, sorry for dragging you into this
[11:51] <zyga-ubuntu> mvo: I painfully found out which features are not enabled in systemd in xenial
[11:51] <zyga-ubuntu> :/
[11:51] <mvo> zyga-ubuntu: uh, what is missing?
[11:51] <zyga-ubuntu> mvo: lunch sounds like a good idea but I have to go out to eat something
[11:51] <zyga-ubuntu> mvo: iptables
[11:51] <zyga-ubuntu> mvo: I'm building a local version that supports that
[11:52] <zyga-ubuntu> mvo: I moved my router from old PC to smaller old PC and decided to stick to LTS
[11:52] <zyga-ubuntu> mvo: and network routing broke
[11:52] <zyga-ubuntu> in the end I found a thread where debian disabled this to save 3500KB
[11:52] <mvo> oh, woah
[11:53] <zyga-ubuntu> it was fixed later and that's why it worked on zesty
[11:53] <zyga-ubuntu> (this lets me remove a cable that runs across the house)
[11:53] <zyga-ubuntu> well, hopefulyl
[11:53] <zyga-ubuntu> it's building
[11:57] <mup> PR snapd#4189 closed: interfaces/builtin/lxd_support: allow discovering of host's os-release <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4189>
[12:03] <mup> PR snapd#4159 closed: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation <Created by jdstrand> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4159>
[12:08] <mup> PR snapd#4200 closed: daemon,overlord/snapstate: return snap-not-installed error in more cases <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4200>
[12:12] <pstolowski> mvo, pedronis can you take another look at #4177?
[12:12] <mup> PR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177>
[12:14] <zyga-ubuntu> mborzecki: https://github.com/snapcore/snapd/pull/4201 ?
[12:14] <mup> PR #4201: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4201>
[12:15] <mborzecki> looking
[12:16] <cachio> mvo, hey
[12:16] <cachio> did you see the email I sent yesterday?
[12:17] <mborzecki> zyga-ubuntu: can you take a look at https://github.com/bboozzoo/snapd/commits/bboozzoo/tests-grub-editenv-wip ? i haven't pushed the last 3 commits for review yet though
[12:18] <mborzecki> basically replaces `$GRUB_EDITENV list` with `bootenv` as the latter is supposed to dump bootloader env
[12:19] <zyga-ubuntu> mborzecki: aha, thanks
[12:20]  * Chipaca ~> lunch
[12:23] <pstolowski> zyga-ubuntu, can you take another look at #4152 ?
[12:23] <mup> PR #4152: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152>
[12:25] <zyga-ubuntu> pstolowski: I merged and de-conflicted https://github.com/snapcore/snapd/pull/4120
[12:25] <mup> PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
[12:25] <zyga-ubuntu> pstolowski: I'll merge udev hook fixes as well but won't push until that lands in master
[12:25] <zyga-ubuntu> pstolowski: then I'll look at cookies
[12:29] <pstolowski> zyga-ubuntu, thanks for pushing 4120!
[12:30] <zyga-ubuntu> pstolowski: let's land fix/udev-hooks first, I already merged the de-conflicted version locally so that it will let your PR land without conflicts soon thereafter
[12:30] <mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/4191#pullrequestreview-75471258 not sure I follow, there is no quick return path in XSnapdGID in this case
[12:30] <mup> PR #4191: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4191>
[12:32] <pstolowski> mborzecki, yeah, co my concern is if you change XSnapGID function to match on some other x-snapd string by mistake, you will hit the quick return path instead and test will be happy
[12:33] <pstolowski> root is just kinda special
[12:33] <mborzecki> ok, i see what you mean
[12:34] <pstolowski> in other words, we don't know if we hit the right code path if we ask for roo
[12:34] <pstolowski> *root
[12:35] <pstolowski> zyga-ubuntu, do you need anything from me re udev? I think i approved your PRs
[12:36] <zyga-ubuntu> pstolowski: I think we are waiting for tests now
[12:36] <zyga-ubuntu> pstolowski: today is a review day, I'll do as little coding as I can :)
[12:37] <pstolowski> mborzecki, any other common user we could rely on in this test?
[12:37] <mborzecki> no, don't think so
[12:37] <mborzecki> we need a well known gid
[12:39] <mborzecki> otoh, it's just a test, there should be no harm in calling osutil.FindGid()
[12:39] <mborzecki> so if we'd rather not use 'root' there, we'll just have to try nogroup and nobody and fine which one exists
[12:39] <mborzecki> s/fine/find/
[12:41] <zyga-ubuntu> darn
[12:41] <zyga-ubuntu> my daughter forgot her towel at the swimming pool at school
[12:41] <zyga-ubuntu> AFK
[12:45] <pstolowski> zyga-ubuntu, my daughter is notorius for forgetting stuff at school ;). happy seeking
[12:53] <pstolowski> mborzecki, commented on xsnapgid PR
[12:56] <mborzecki> pstolowski: thanks, right, i've cherry picked 2 commits, missed a 3rd one :/
[12:57] <pstolowski> good ;)
[13:01] <Chipaca> niemeyer: stand up
[13:02] <Chipaca> pedronis: you too
[13:03] <niemeyer> Chipaca: Trying to join
[13:03] <niemeyer> (and not working)
[13:04] <mborzecki> pstolowski: pushed a fix, hopefully a last one :)
[13:08] <mborzecki> pstolowski: thanks for the review
[13:10] <zyga-ubuntu> [   30.633917] audit: type=1400 audit(1489520905.019:12): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/dev/urandom" pid=1508 comm="5" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[13:10] <pstolowski> mborzecki, yw
[13:15] <diddledan> ooh ooh ooh. I got gimp beta compiled
[13:18] <mup> PR snapd#4192 closed: osutil: add helper for obtaining group ID of given file path <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4192>
[13:19] <mup> PR snapd#4149 closed: tests: new tests for network setup control and observe interfaces <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4149>
[13:19] <zyga-ubuntu> niemeyer: https://forum.snapcraft.io/t/systemd-in-ubuntu-16-04-core-snap-doesnt-support-iptables/2768
[13:22] <jdstrand> Chipaca: what I said yesterday is one can use '<gid>' (note, no 'g;') can be used instead of 'g:<group>'
[13:22] <Chipaca> jdstrand: yeah, mborzecki cleared me up on that, thank you
[13:22] <jdstrand> np
[13:28] <mup> PR snapd#4203 closed: tests/set-proxy-store: exclude ubuntu-core-16 via systems: key <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4203>
[13:49] <pedronis> mvo: do we have stuff that can be untagged in your upcoming,  or it's all still in progress for 2.29?
[13:49] <pedronis> *do you
[13:52] <mvo> pedronis: let me check
[13:56] <Chipaca> niemeyer: could you re-run the review sprint generating script magic thing?
[13:56] <Chipaca> niemeyer: (assuming it's cheap for you to do so)
[13:56]  * Chipaca <- lazy
[13:56] <niemeyer> Chipaca: Of course, churning right now
[13:56] <Chipaca> ta
[13:57] <niemeyer> Chipaca: Done
[14:01] <mup> PR snapd#4144 closed: interfaces: fix udev tagging for hooks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4144>
[14:04] <zyga-ubuntu> pstolowski: pushed, can you look at https://github.com/snapcore/snapd/pull/4120/files to ensure it's sane
[14:04] <mup> PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
[14:05] <zyga-ubuntu> jdstrand: I need 2nd review for https://github.com/snapcore/snapd/pull/4163
[14:05] <mup> PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163>
[14:05] <pstolowski> zyga-ubuntu, will do
[14:06] <zyga-ubuntu> pstolowski: and some comments on https://github.com/snapcore/snapd/pull/4108
[14:06] <mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
[14:06] <mup> PR snapd#4129 closed: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4129>
[14:08] <pstolowski> zyga-ubuntu, thank you for both
[14:08] <pedronis> mvo: did you remove some mvo tags but not the upcoming tag ?  or I'm just confused
[14:08] <Chipaca> siiiigh
[14:08] <zyga-ubuntu> mvo: some failures to address here https://github.com/snapcore/snapd/pull/4063
[14:08] <mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
[14:08] <zyga-ubuntu> Chipaca: it's Frida
[14:08] <Chipaca> yaml's support for sexagesimal numbers is awesome
[14:08] <mvo> pedronis: meh, sorry, wrong way around, I need a cup of tea I think
[14:08] <zyga-ubuntu> Chipaca: cannot be that bad
[14:09] <pedronis> mvo: seems so :)
[14:09] <pedronis> it's probably me but I feel we have realistically too many things marked as upcoming
[14:10] <pedronis> or upcoming means in the next 6 month, which maybe is ok, but then we need one more tag or something
[14:10] <zyga-ubuntu> building systemd on atom is ... painful
[14:11] <mborzecki> anythin on atom is painful
[14:11] <mborzecki> it's a broken CPU to begin with
[14:12] <Chipaca> mborzecki: how so?
[14:13] <zyga-ubuntu> mborzecki: it's not very superscalar AFAIR, like old ARMs
[14:13] <Chipaca> mvo: is #4049 on your plate, or should i pester somebody else?
[14:13] <mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
[14:14] <mvo> Chipaca: me but I'm currently busy and can only look at it next week again
[14:14] <Chipaca> mvo: ¯\_(ツ)_/¯
[14:14] <Chipaca> mvo: for the record, i'm fine with that :-)
[14:15] <pedronis> pstolowski: are install/remove hooks in 2.29 or 2.28 ?
[14:16] <mborzecki> zyga-ubuntu: never lived up to the hype, the only advantage bing a familiar instruction set, but performance and power consumption wise it's not very appealing
[14:17] <zyga-ubuntu> mborzecki: no disagreements there :)
[14:17] <mborzecki> could have been worse though, recall quarks :P
[14:17] <zyga-ubuntu> mborzecki: quarks aka, that thing running inside ME
[14:18] <mborzecki> this was a nice addition to the gallery of SoC oddities: https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug
[14:19] <mborzecki> iirc that's why they were stuck with some ancient kernels too
[14:19] <pstolowski> pedronis, yes, they landed in 2.27
[14:20] <zyga-ubuntu> mborzecki: not cute embedded nonsense hacks (aka intel)
[14:21] <mborzecki> this is new 'Cannot allocate linode:opensuse-42.2-64: no powered off servers in Linode account exceed halt-timeout'
[14:22] <zyga-ubuntu> mborzecki: EAGAIN
[14:22] <mborzecki> ok
[14:23] <zyga-ubuntu> too many things in flihg
[14:23] <sergiusens> hello everyone! Just getting started here, rough night last night
[14:23] <zyga-ubuntu> *flight
[14:23] <zyga-ubuntu> sergiusens: he
[14:23] <zyga-ubuntu> sergiusens: what's happened?
[14:25] <sergiusens> zyga-ubuntu food sickness...
[14:26] <zyga-ubuntu> sergiusens: ouch, I'm sorry
[14:26] <sergiusens> stlll dealing with it, but I now have the energy to get up
[14:26] <sergiusens> yeah, me too :-P
[14:29] <cachio> mvo, https://paste.ubuntu.com/25932196/
[14:29] <cachio> this is what I see after refresh on db
[14:31] <cachio> the dmesg is the same I sent before
[14:34] <mvo> cachio: this is very strange "Mar 14 19:48:44 localhost.localdomain systemd[1]: Stopping Snappy daemon...". it almost looks like something outside is stopping snapd on purpose
[14:36] <cachio> mvo, I ran the test suite to reproduce it
[14:36] <cachio> I could make it manual
[14:36] <pedronis> pstolowski: we don't have pre-refresh, right?
[14:36] <cachio> the suite is the not stopping it
[14:36] <pedronis> pstolowski: is it planned?
[14:36] <cachio> an it is the same suite we run for pi2 and 3
[14:37] <cachio> mvo, perhaps it is a problem in the this old stable image
[14:38] <pstolowski> pedronis, correct, we don't have it. i've it implemented but got stuck on that issue we discussed on the last sprint where I'm getting tasks in wrong order in the test
[14:38] <pedronis> ah
[14:39] <jdstrand> zyga-ubuntu: ack
[14:39] <pstolowski> i've spent a good chunk of time looking at it during the sprint but didn't get to the bottom
[14:39] <zyga-ubuntu> jdstrand: thank you :)
[14:39] <zyga-ubuntu> jdstrand: that's just a refactor but I wanted to make sure you see it
[14:39] <jdstrand> zyga-ubuntu: this isn't for 2.29, right?
[14:40] <zyga-ubuntu> jdstrand: no, for master
[14:40] <zyga-ubuntu> jdstrand: 2.29.x is closed I think (yay)
[14:40] <zyga-ubuntu> jdstrand: there's also a PR on top that explains why this refactor is needed
[14:40] <zyga-ubuntu> (or useful)
[14:40] <pedronis> pstolowski: is something you will look at again at some point?
[14:40] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4169
[14:40] <mup> PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
[14:41] <pstolowski> pedronis, yes
[14:41] <jdstrand> zyga-ubuntu: ok. fyi, I have a couple things ahead of it to clear my desk for these reviews. possible I won't review til monday, but I'll try for today
[14:42] <jdstrand> zyga-ubuntu: I've been collecting your requests. 4163, 4166, 4169 and 4170
[14:42] <zyga-ubuntu> jdstrand: thank you, we are trying to close the review sprint (well, eventually, not today) and getting those refactors merged would unblock me on more features :)
[14:42] <jdstrand> zyga-ubuntu: are there others I should add to the list for next week or just wait for you to ping me?
[14:43]  * kalikiana hopping on a train, back in a bit
[14:43] <zyga-ubuntu> jdstrand: no, that's the only one, next week is fine
[14:43] <zyga-ubuntu> kalikiana: stay safe :)
[14:44] <kalikiana> zyga-ubuntu: Always. I sit on the roof of the car so nothing inside can harm me :-P
[14:45] <zyga-ubuntu> hahaha
[14:45] <zyga-ubuntu> well
[14:45]  * zyga-ubuntu would not be surprised
[14:49] <zyga-ubuntu> mborzecki: https://forum.snapcraft.io/t/brave-and-other-apps-dont-launch-on-arch/2770/2
[14:49] <zyga-ubuntu> mborzecki: something for you :)
[14:55] <mup> PR core#63 opened: 25-create-generic-initrd.chroot: use symlink instead of copy <Created by mvo5> <https://github.com/snapcore/core/pull/63>
[14:55] <zyga-ubuntu> mborzecki: one more review on https://github.com/snapcore/snapd/pull/4185
[14:55] <mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
[14:55] <elopio> jdstrand: thanks a lot for your comments in the classic request. I have a question, if I run the yarn snap as classic, is it the same as if I download a yarn binary and run it with sudo?
[14:56] <mvo> cachio: sorry for the delay. maybe, what is confusing to me is is that it looks like something stoped snapd via systemctl stop. there is no setup magic somewhere in our scripts that does that and just forgot to start it again?
[14:57] <zyga-ubuntu> mvo: review for yuor core pr
[14:57] <zyga-ubuntu> conflict on https://github.com/snapcore/core/pull/58
[14:57] <mup> PR core#58: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
[14:57] <sergiusens> mariogrip added a testing bit to your PR snapcraft#1723
[14:57] <mup> PR snapcraft#1723: sources: workaround for ZipFile.extractall not preserving permissions <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723>
[14:57] <sergiusens> elopio care to take a look? ^
[14:58] <cachio> mvo, I just executed manually and made the reboot manually and snapd service was running after that the
[14:58] <cachio> now I am leaving that to autoreboot to see
[15:00] <cachio> mvo, I'll have results in 10 minutes
[15:00] <cachio> if it works I'll make the promotion
[15:00] <mvo> cachio: thank you
[15:01] <mvo> zyga-ubuntu: heh
[15:01] <mvo> zyga-ubuntu: so the snapctl internal configure-core
[15:01] <mvo> zyga-ubuntu: will be changed to "rm -f"
[15:01] <mvo> zyga-ubuntu: because we now really do the configure internally
[15:02] <zyga-ubuntu> mvo: good :)
[15:02] <zyga-ubuntu> rm -rf on snap set harakiri
[15:02] <zyga-ubuntu> ;-)
[15:11] <mup> PR snapd#4197 closed: cmd/snap-confine: Support bash as base runtime entry <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4197>
[15:19] <Chipaca> niemeyer: in spread, is SPREAD_REBOOT reset when entering the debug shell?
[15:20] <cachio> mvo, core 2.29.3 promoted to candidate
[15:20] <mvo> cachio: yay, thank you
[15:21] <cachio> mvo, now we just need confirmation from qa
[15:21] <cachio> hopefully on monday we willl be ready
[15:21] <cachio> to go to stable
[15:21] <cachio> :)
[15:22] <niemeyer> Chipaca: Yes, the reboot loop happens entirely inside the client abstraction, which means any snippet at all can reboot, and it also means we can't hook into intermediate state
[15:24] <zyga-ubuntu> I cannot believe my machine is _still_ building systemd
[15:26] <zyga-ubuntu> mborzecki: +1, thanks :)
[15:26] <zyga-ubuntu> mborzecki: not sure which snaps you have installed but the more you have the better testing we get
[15:26] <Chipaca> mvo: question for you about #4063: was there anything you expected of pc-kernel storeside for it to pass?
[15:26] <mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
[15:26] <zyga-ubuntu> mborzecki: I'm always using telegram as my 1st snap on any system
[15:26] <Chipaca> mvo: i mean: seems like it'd need different kernels in edge and stable, and that's not the case
[15:27] <zyga-ubuntu> mborzecki: I'm also using ohmygiraffe for casual GL-works tests
[15:27] <Chipaca> zyga-ubuntu: strange, for most people it's 'core'
[15:27] <mborzecki> node-red and brave seem to work :) (where work means starts and either a window shows up or i can connect to some web ui)
[15:27] <Chipaca> :-P
[15:27] <zyga-ubuntu> Chipaca: nah, you just have to be very quick
[15:27] <zyga-ubuntu> Chipaca: or have autofire on your keyboard
[15:27] <mvo> Chipaca: yes, it needs that (the test) and it was the case sme days ago :/
[15:27] <mvo> Chipaca: thanks for this feedback
[15:28] <Chipaca> mvo: yeah, now they're all the same :-/
[15:29] <mborzecki> zyga-ubuntu: ohmygiraffe looks like fun
[15:31] <mborzecki> no warnings/erorrs popup with LIBGL_DEBUG
[15:31] <zyga-ubuntu> mborzecki: nice :)
[15:32] <elopio> popey or flexiondotorg: can you please fork this into snapcrafters? https://github.com/elopio/yarn
[15:33] <mvo> pedronis: the new configure-snapd task has an interessting twist (regarding backwards compat): https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774/1
[15:34] <mvo> Chipaca: its something I will contemplate on monday I think
[15:34] <pedronis> mvo: ok
[15:35] <mvo> pedronis: looks like we need to think a bit about a fix before doing 2.30
[15:36] <mvo> pedronis: I will make a cup of tea and ponder a bit
[15:36] <pedronis> it's a bit of a general problem, I mean we need to solve it here but I think we never thought true what unknown tasks means vs revert
[15:36] <pedronis> *thought through
[15:37] <mvo> pedronis: yeah, very good point
[15:39] <zyga-ubuntu> mborzecki: more posts about arch from popey
[15:39] <popey> :D
[15:39] <pedronis> mvo: anyway is the last thing the revert needs to do, no?
[15:39] <popey> elopio: doing now
[15:39] <zyga-ubuntu> popey: thank you for reporting those!
[15:40] <popey> np
[15:40] <zyga-ubuntu> popey: I think we need to be really loud about the new package
[15:40] <pedronis> mvo: after a week the change will go away, but you cannot do anything with core in that week
[15:40] <zyga-ubuntu> popey: and if we cannot update the community package, burn it with fire
[15:40] <popey> zyga-ubuntu: totally, assuming it works :D
[15:41] <popey> are you saying it's _impossible_ to update the existing snapd package?
[15:41] <popey> That seems like Arch is designed for Awesome.
[15:42] <mborzecki> popey: did you manage to build the package?
[15:42] <zyga-ubuntu> popey: last time I looked the package was abandoned
[15:42] <popey> mborzecki: i haven't tried yet.
[15:42] <mborzecki> ack
[15:42] <zyga-ubuntu> popey: and to even remark that we need a monthly process initiated by a trusted user
[15:42] <popey> also had to fix my suse install which broke when I updated it :(
[15:42] <zyga-ubuntu> popey: and then more time to maybe replace the package
[15:42] <mborzecki> fwiw, trying to install nextcloud now
[15:42] <zyga-ubuntu> popey: flexiondotorg knows more
[15:42] <popey> ya
[15:42] <zyga-ubuntu> popey: yeah, I noticed
[15:43] <zyga-ubuntu> popey: I killed that snapper tool (whatever it does) as I ran out of space myself
[15:43] <popey> elopio: https://github.com/snapcrafters/yarn
[15:44] <popey> elopio: do we need to get the name moved over in the store? If so, can you request it>
[15:44] <popey> >
[15:44] <popey> gah, ?
[15:47] <niemeyer> pstolowski: #4108 reviewed
[15:47] <mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
[15:47] <mborzecki> uhh nextcloud, php-fpm, redis, mysql, apache, omg
[15:47] <niemeyer> pstolowski: Let me know if you want to talk about it so you're unblocked
[15:48] <elopio> popey: yes, I will request the transfer. But wanted to wait on the classic assignment first.
[15:48] <elopio> there's a bit of discussion there.
[15:49] <popey> ok, great
[15:49] <mvo> pedronis: its revert and refresh. yeah, things will heal after a week which is great
[15:50] <pstolowski> niemeyer, thanks for the review!
[15:51] <pedronis> mvo: mmh, it will be aborted first which will undo the revert, that's not great
[15:51] <niemeyer> pstolowski: np
[15:51] <pedronis> mvo: why are we getting a revert btw?
[15:51] <mvo> pedronis: we are not getting a revert, sorry, my post is not clear about this. it just hangs forever on refresh/revert when the configure-snapd task is there
[15:52] <pedronis> mvo: it hanges on refresh?
[15:52] <pedronis> why does it hang on refresh?
[15:53] <mvo> pedronis: when going from a snapd that add the configure-snapd task to a snapd that does not understand this task after the reboot (second phase of security setup) the task will be in "Do" state but never run by the "old" snapd because it does not know what to do with it (c.f.  https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting )
[15:54] <mvo> pedronis: so what happend was that edge had a core with configure-snapd support, the snapd 2.29.3 got built which does not know about configure-snapd but landed in edge
[15:54] <mvo> pedronis: so people refreshing during the time that 2.29.3 was in edge and had a 2.29+git version with configure core strange things happend
[15:55] <pedronis> mvo: ah, it's a strange case
[15:55] <mvo> pedronis: does that vaguely make sense?
[15:55] <niemeyer> It does :(
[15:55] <mvo> pedronis: but its also happening when doing "sudo snap refresh --edge; sudo snap refresh --candiate" for core
[15:55] <pedronis> yes, I understand
[15:56] <mvo> pedronis: just wanted to share it with you, its not omg-criticial as so far only edge is affected but but :)
[15:56] <pedronis> as I said we have a concrete problem but also a general question here
[15:56] <mvo> indeed
[15:57] <pedronis> it's also an internal design thing, because we have many taskrunners, nothing really takes care of tasks that aren't registered by anything
[16:02] <zyga-ubuntu> pedronis: maybe we need a sanity check "manager" that aborts unclaimed tasks in some way?
[16:04] <mborzecki> zyga-ubuntu: https://github.com/snapcore/snapd/pull/4185#discussion_r150254354 'internal' as in do it in init(), keep the error around and return it in SecCompConnectedPlut or just panic() in init()?
[16:04] <mup> PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185>
[16:05] <zyga-ubuntu> mborzecki: returning the error feels better
[16:05] <zyga-ubuntu> mborzecki: panic can bring down snapd in cases we may not want to
[16:06] <ppisati> sergiusens: any ETA for 2.35?
[16:08] <zyga-ubuntu> sergiusens: we should plan to sync numbers :)
[16:08] <zyga-ubuntu> sergiusens: it'd be awesome if snapd and snapcraft were in sync
[16:10] <zyga-ubu1tu> man
[16:10] <zyga-ubu1tu> systemd built :D
[16:12]  * zyga-ubu1tu EODs for now, I'll push one more PR for layouts but I need to eat something first :)
[16:17] <niemeyer> pedronis, mvo: And that's a bit by design.. there are three things we can do: ignore, fail, or wait
[16:18] <niemeyer> Ignore feels like a non-starter
[16:18] <pedronis> yea, it's not clear what we should do
[16:18] <pedronis> at the moment basically we chose fail (just slowly)
[16:18] <niemeyer> Fail is probably the best option
[16:18] <niemeyer> pedronis: We choose wait..
[16:18] <niemeyer> pedronis: Fail after a week
[16:18] <pedronis> well the task will be aborted
[16:19] <niemeyer> Yeah, but after a week, which for human purposes is really waiting
[16:19] <pedronis> no, abort is 24h
[16:19] <pedronis> I think
[16:19] <pedronis> prune is a week
[16:19] <niemeyer> It's the opposite.. pruning is faster than aborting
[16:19] <niemeyer> IIRC at least
[16:19] <pedronis> ah, yes, sorry
[16:20]  * pedronis is doing too many things at the same time
[16:21] <niemeyer> We'll require some more info to change this, though..
[16:21] <niemeyer> As task runners are really an independent thing today
[16:21] <niemeyer> IOW, there's no global knowledge of all handlers available
[16:22] <pedronis> yea
[16:22] <pedronis> there's no global registry of all known task kinds
[16:22] <niemeyer> We might cheat and track at a package level every known handler
[16:22] <niemeyer> and only abort those
[16:22] <niemeyer> That might be cheap
[16:22] <niemeyer> only abort those not known at all, obviously
[16:23] <niemeyer> There is a bit of danger in doing even that, though, as it becomes racy
[16:24] <niemeyer> Another option that might be cheap and saner is timing out based on how long the task is waiting to run without an available handler
[16:26] <niemeyer> IOW, try to run it, if there's no handler right now, abort it right away or after N minutes/hours
[16:26] <niemeyer> Again, a bit of care needs to be taken as we've never been worrying about delays between the main loop running and the handler being available
[16:27] <niemeyer> Since we wait..
[16:27] <niemeyer> mvo, pedronis: So.. do we need to do something right now?
[16:31] <mvo> niemeyer: I think we need something for 2.30, I think it would be unfortunate if "snap revert core" would basilcy force a 24h wait until the task times out (and then it would undo the revert)
[16:31] <mvo> (or am I missing something?)
[16:31] <niemeyer> mvo: You are missing that it's actually a week.. :D
[16:32] <mvo> niemeyer: *cough* thats not making it better ;)
[16:32] <mvo> niemeyer: the other thing is that 2.29 cannot be retro-fitted with whatever we come up with
[16:33] <niemeyer> mvo: Exactly what I was thinking..
[16:33] <mvo> niemeyer: I mean, ideally whatever we do would work on a previous snapd :/
[16:33] <niemeyer> mvo: Even if we change the behavior of 2.30, that won't be fixed unless we get away with the new task altogether
[16:33] <mvo> niemeyer: indeed
[16:34] <niemeyer> mvo: Oh, kind of
[16:34]  * mvo listens
[16:34] <niemeyer> mvo: Where is the new task being introduced? 2.30?
[16:34] <mvo> niemeyer: correct
[16:34] <mvo> niemeyer: 2.29.3+git to be pedantic
[16:35] <niemeyer> mvo: So only tasks generated in 2.30 would present the issue
[16:35] <mvo> niemeyer: yes
[16:35] <niemeyer> mvo: That means an explicit revert of the update itself would not present the issue, at least
[16:36] <mvo> niemeyer: yes, from 2.30 we could revert/refresh and generate appropriate tasks, i.e. if we know we go backwards we could DTRT
[16:37] <niemeyer> mvo: Right.. we might actually change the behavior of snapd so that we never generate configure-snapd on operations of core itself
[16:37] <niemeyer> mvo: As it's a bit silly anyway
[16:38] <niemeyer> mvo: We can always reconfigure the core because.. well.. the code is running in the first place :)
[16:39] <mvo> niemeyer: heh, I see (I think)
[16:39] <mvo> niemeyer: so refresh/revert etc does not generate configure-core tasks. but when snapd starts it does the configure automatically every time? and of course snap set core would trigger the task, did I get this right?
[16:40] <mborzecki> ok guys, i need to wrap it up for today
[16:40] <mborzecki> enjoy your weekend everyone
[16:41] <niemeyer> mvo: We may not even trigger the configure automatically for now
[16:41] <niemeyer> mvo: We literally have the actual code running.. we can always fix data or do whatever else live in the appropriate places
[16:42] <niemeyer> mvo: Instead of expecting ourselves to call ourselves to reconfigure
[16:42] <niemeyer> mvo: Sounds like a win in terms of stability, overall, given our experience in core to core updates
[16:42] <mvo> niemeyer: I was thinking pushing it into a task is nice as its observable from the outside and it may take some seconds to run potentially at least
[16:42] <mvo> niemeyer: but yeah, happy to go taskless :)
[16:43] <niemeyer> mvo: But what exactly is observable? :)
[16:43] <pedronis> well  snap set needs a task because of the API
[16:43] <niemeyer> pedronis: Yeah, no changes there
[16:44] <niemeyer> pedronis: This is specifically about snap operations on snapd
[16:44] <niemeyer> Or core, for now
[16:47] <mvo> niemeyer: I think you are right, we don't really do anything in corecfg.Run() that takes time. I was thinking it might be nice to be able to see that configure core is hanging
[16:47] <mvo> niemeyer: but it should never do that and we can internally add safety for that
[16:48] <mvo> niemeyer: I like the outcome! will you followup in the forum or shall I try to summarize?
[16:48] <niemeyer> mvo: Yeah, and if there's no configure core, we won't ever see it hanging :P
[16:49] <mvo> lol
[16:49] <niemeyer> mvo: I mean unless you really want it.. we can always add a sleep like the old days..
[16:50]  * niemeyer still remembers of a previous life where folks added a sleep to slow down rsync, on customer request
[16:50] <niemeyer> *inside* rsync
[16:51] <niemeyer> mvo: Do we have a topic for this already?
[16:51] <mvo> niemeyer: yes https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774
[16:51] <mvo> niemeyer: we found it because ondra actually hit the issue
[16:52] <niemeyer> mvo: I'm summarizing the preliminary discussion and agreements
[16:53] <pedronis> mvo: I thought we were requesting "base" to the store, is that not the case yet?
[16:53] <mvo> niemeyer: brilliant,thank you
[16:54] <mvo> pedronis: I thought so as well, I even downloaded some bases
[16:54] <mvo> pedronis: eh, uploaded
[16:54] <pedronis> mvo: I don't see it in the code
[16:54] <mvo> pedronis: in our code?
[16:54] <pedronis> yes
[16:55] <pedronis> mvo: sorry, I mean the field, not the type
[16:56] <pedronis> mvo: did you implement the bits needing it, but didn't add the store/ parts yet?
[16:58] <mvo> pedronis: it looks like it, let me look at the details
[17:02] <niemeyer> mvo, pedronis: Hopefully I captured it well
[17:10] <pedronis> we need to be a bit careful with firstboot code
[17:12] <pedronis> I added a note in the topic
[17:16] <ikey> so ehm
[17:16] <ikey> how would i go about publishing snaps and controlling channels
[17:16] <ikey> without snapcraft?
[17:17]  * ikey would like to get his snaps out for edge testing this weekend
[17:19] <Chipaca> ikey: you should be able to do most of it via the web as well i think
[17:19] <niemeyer> ikey: snapcraft is just calling the store APIs, but we have no docs for that.. and those APIs are also a bit ancient so please don't expect a polished API at this time
[17:19] <ikey> sure
[17:19] <Chipaca> ikey: you used to, but i haven't checked if that's changed
[17:19] <ikey> but snapcraft is unusable for me
[17:19] <ikey> and i aint switching to ubuntu just to use it
[17:19] <niemeyer> ikey: You can build the snap without snapcraft, and use snapcraft just to push it
[17:20] <ikey> i built it without snapcraft
[17:20] <ikey> https://bugs.launchpad.net/snapcraft/+bug/1731478
[17:20] <mup> Bug #1731478: Snap of snapcraft fails to run on Solus and openSUSE <Snapcraft:New> <https://launchpad.net/bugs/1731478>
[17:20] <niemeyer> ikey: Yeah, so you can just snapcraft push
[17:20] <ikey> ain't that easy
[17:20] <ikey> its hardwired to debuntu
[17:20] <Chipaca> niemeyer: snapcraft won't start for him (see bug)
[17:20] <Chipaca> ikey: i expect that to get fixed soonish, but, have you tried the web?
[17:20] <niemeyer> Wat?
[17:20] <ikey> i haven't
[17:21] <ikey> niemeyer, solus != ubuntu
[17:21] <Chipaca> ikey: dashboard.snapcraft.io
[17:21] <niemeyer> ikey: I know, I just didn't expect snapcraft to be unable to work at all
[17:21] <ikey> oh lol
[17:21] <ikey> "This should be a snap for Ubuntu Core; upload will begin as soon as a valid file is selected."
[17:21] <ikey> eh.
[17:22] <niemeyer> nessita: ^
[17:22] <ikey> oh thats another thing btw
[17:22] <ikey> snapd absolutely mandates the presence of core
[17:22] <ikey> even if you don't need it
[17:22] <ikey> so if you install solus-runtime-gaming you have to install core
[17:23] <Chipaca> ikey: with bases, we're going to split core into actual core and an ubuntu base, and then things will be happier
[17:23] <Chipaca> ikey: still on our TODO though
[17:23] <ikey> right but i mean - it still won't need any kind of core
[17:23] <niemeyer> ikey: That traceback seem related to snapcraft being run in packaging mode
[17:23] <niemeyer> ikey: Is snapcraft push --help working for you?
[17:23] <Chipaca> ikey: at that point you still need core, to have snapd inside snaps, but you dont need the rest
[17:23] <ikey> we dont support reexec on solus
[17:23] <ikey> so we don't actually need core
[17:24] <Chipaca> ikey: ah
[17:24] <ikey> its a subtle nuance but i figured id bring it up :)
[17:24] <ikey> niemeyer, https://hastebin.com/vaparusuha.sql
[17:24] <Chipaca> ikey: well, it'll get at least a little better when we split core, even if we continue to pretend everybody reexecs
[17:24] <ikey> even --help doesn't work
[17:24] <ikey> Chipaca, sure
[17:25] <Chipaca> but, fair point
[17:25] <ikey> on the plus side:
[17:25] <ikey> 2.7M	linux-steam-integration_0.6_amd64.snap
[17:25] <ikey> 287M	solus-runtime-gaming_0.0.0_amd64.snap
[17:26] <niemeyer> ikey: Have you tried to just comment out apt_pkg.init()?
[17:26] <ikey> its in a ready only snap
[17:26] <ikey> think about it :p
[17:26] <niemeyer> ikey: mount --bind?
[17:27]  * ikey blinks
[17:27] <ikey> its a .snap file
[17:27] <ikey> read only squashfs
[17:27] <niemeyer> ikey: You can bind mount a file into a read-only file
[17:27] <sergiusens> ikey your bug should be fixed in 2.36
[17:27] <ikey> niemeyer, im not sure you're following here
[17:27] <ikey> the snap is already read-only
[17:27] <ikey> i can't edit the files inside it
[17:27] <ikey> the only way for me to "fix" this is to manually install snapcraft
[17:27] <niemeyer> ikey: You can literally bind mount a file into a mounted read-only filesystem
[17:28] <niemeyer> ikey: It doesn't matter if it's zfs or squashfs
[17:28] <ikey> still not getting it
[17:28] <ikey> k
[17:28] <niemeyer> ikey: Okay, nm.. 2.36 sounds like an easier target.. :)
[17:28] <ikey> i dont have any of the debian support
[17:28] <ikey> so apt_pkg.init is just one call im gonna have to fart with
[17:28] <niemeyer> ikey: snapcraft should not need any debian support at all to push a snap
[17:28] <ikey> thats deep in debian/debian_support.py
[17:28] <ikey> i know :P
[17:29] <niemeyer> ikey: It sounds like a silly leftover initialization that shouldn't be running until obviously necessary
[17:29] <ikey> yea
[17:29] <niemeyer> (and which is already fixed)
[17:29] <ikey> is there an edge snap i can move to? :P
[17:29] <ikey> ah crap
[17:29] <ikey> im on edge
[17:29] <niemeyer> snap info snapcraft says 2.34
[17:29] <ikey> 2.34+git97.af78689
[17:29] <ikey> hmph
[17:29] <niemeyer> sergiusens: How come?
[17:29] <ikey> lol
[17:30] <sergiusens> niemeyer changing that legacy choice is a refactor away
[17:30] <niemeyer> sergiusens: No snapcraft edge?
[17:30] <sergiusens> wait, what?
[17:31] <sergiusens> https://pastebin.ubuntu.com/25933068/
[17:32] <niemeyer> sergiusens: Yeah?
[17:32] <sergiusens> ikey wth, we are delayed with the release on the wait of the 40 4 hour each snapd tests on adt; I'll just fix it now
[17:32] <niemeyer> sergiusens: None of those 2.34 look like 2.36..? :)
[17:33] <ikey> xD
[17:33] <niemeyer> sergiusens: Any reason why edge releases aren't happening daily automatically?
[17:33] <sergiusens> niemeyer they happen daily
[17:34] <sergiusens> https://pastebin.ubuntu.com/25933087/
[17:35] <niemeyer> sergiusens: That's not 2.36..
[17:35] <sergiusens> no, no code for 2.36 exists in a merged state
[17:35] <sergiusens> we don't branch out like you guys do
[17:36] <niemeyer> sergiusens: I'm clearly missing something.. what do you release daily on edge then?
[17:36] <sergiusens> niemeyer master
[17:36] <niemeyer> sergiusens: Sure.. but clearly master doesn't contain the new things that are being merged..?
[17:37] <sergiusens> niemeyer it exactly contains that
[17:37] <niemeyer> sergiusens: Okay, I misunderstood what you meant all along then
[17:37] <niemeyer> sergiusens: There's no 2.36 release, and there's no fix yet
[17:38] <sergiusens> oh, I said I would fix it for 2.36, not that it is fixed in 2.36 :-)
[17:38] <niemeyer> sergiusens: You actually said it should be fixed in 2.36, and both me and ikey went looking for that
[17:39]  * ikey grins at confuzzlement
[17:39] <ikey> while reading up on opengl apis -_-
[17:39] <niemeyer> Anyway, we understand it now..
[17:39] <sergiusens> ah, should is a vague word I used; should (pun) have said shall
[17:39] <ikey> xD
[17:39] <ikey> friday, right.
[17:40] <niemeyer> sergiusens: "will" is the one you're looking for :)
[17:40] <sergiusens> will also works
[17:41] <cjwatson> ikey: it would work if apt_pkg were entirely absent, just not when present but broken
[17:41]  * ikey blinks
[17:41] <ikey> i don't have any kind of apt_pkg
[17:41] <cjwatson> I guess it must be in the snapcraft snap
[17:41] <ikey> yea
[17:42] <cjwatson> I'm mostly just vocalising my "hmm, I was sure apt_pkg was optional in python-debian" train of thought
[17:42] <ikey> yea
[17:42] <ikey> in theory apt_pkg is present in a broken state
[17:42] <ikey> because of "missing /etc/apt.d"
[17:42] <ikey> or apt/something.d i dk
[17:42] <ikey> i haven't deb'd in a long time :p
[17:44] <niemeyer> ikey: One possibility is grabbing the snapcraft source code and yanking half of its logic until push works.. in theory push should really not care about anything about the host system at all.. only the snap file is relevant
[17:44] <ikey> that certainly is one possibility
[17:44] <ikey> one id rather avoid
[17:44] <ikey> getting python out of all the nooks on your system again after is like tryna get bird cack out of your hair
[17:44] <ikey> you just know its still there somewhere
[17:45] <ikey> and id rather follow the snap package in future, without host conflicts
[17:45] <niemeyer> ikey: If the web works, that's the easiest.. otherwise spending 5-10 minutes on this might be fruitful.. even more considering you know the upstream will fix the issue for you soon
[17:45] <ikey> (y'all can keep that mental image for free)
[17:45] <niemeyer> ikey: Haha, yeah
[17:45] <ikey> what does series 16 mean on the dashboard..?
[17:46] <sergiusens> ikey you shouldn't need apt at all; this is related to an if 'linux' as a whole
[17:46] <Chipaca> ikey: how about this: grab the snapcraft .snap, unsquashfs, enter, and use 'snap try' to have a rw snap
[17:46] <mup> PR snapcraft#1654 closed: autotools: cross-compile using --host instead of env <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1654>
[17:46] <ikey> sergiusens, eehhhhhhh
[17:46] <ikey> don't get me started on that one mate :P
[17:46] <ikey> "linux == ubuntu"
[17:46] <ikey> nope.
[17:46] <ikey> not while im around :P
[17:46]  * Chipaca hugs ikey 
[17:46] <niemeyer> or me
[17:47] <ikey> lolz
[17:47] <sergiusens> ikey it was from way way way before we started trying to get snapcraft work on different distros; also, there is no if linux, we have "if win" and "if osx"
[17:47] <ikey> *snort*
[17:47] <Chipaca> ikey: did the web work?
[17:47] <niemeyer> sergiusens: You're not making it any better
[17:47] <niemeyer> sergiusens: saying apt_pkg == linux support is waaaaay too much of a stretch
[17:47] <ikey> Chipaca, oh im not gonna upload it immediately immediately, was gonna do it in a few hours once i apply some basic polish to it
[17:47] <sergiusens> niemeyer for linux we check os release, but went into a whitelist mode
[17:48] <sergiusens> for apt we check os release
[17:48] <ikey> my problem is nobody can really *use* the snap without having minimum 2.29.2 + my last 2 patches
[17:48] <ikey> is there a way for a snap to say "oi i need this many versions"
[17:48] <ikey> like minimum snapd version
[17:49] <Chipaca> there is, but no idea how to use it. niemeyer?
[17:49] <sergiusens> assumes
[17:49] <Chipaca> yah
[17:49] <sergiusens> but I don't know what the keywords are
[17:49] <Chipaca> assumes: more-magic
[17:49] <ikey> lol?
[17:50] <ikey> oh jdstrand re: dynamic hotplugging..
[17:50] <cjwatson> if the web works> AIUI the web upload option is due to be removed soon in favour of snapcraft, so perhaps best not to get used to relying on it ...
[17:50] <niemeyer> assumes: snapdX.Y
[17:50] <niemeyer> Sorry
[17:50] <niemeyer> It's a list
[17:50] <ikey> do we have plans for allowing udev rules within snaps ?
[17:50] <niemeyer> assumes: [snapdX.Y]
[17:50] <ikey> cjwatson, ah i wondered as much, the dashboard looks a bit uhm
[17:50] <ikey> well. tired.
[17:51] <ikey> niemeyer, so assumes: [ snapd2.29.4 ] for example?
[17:51] <cjwatson> it's a codebase with a storied history.  there's some UI rerefresh work going on
[17:51] <cjwatson> *refresh
[17:51] <niemeyer> ikey: I don't think it supports micros.. need to double check
[17:51] <ikey> ah k
[17:52] <niemeyer> Double checking
[17:52] <ikey> cjwatson, well it seems to look/talk about core a lot so i assumed it was from the Old Period
[17:52] <ikey> and snapcraft being the new snapd specific sexy
[17:52] <ikey> vs.. "core"
[17:52] <cjwatson> that wouldn't be very surprising, indeed
[17:52] <ikey> still i do *like* me some some CLI sexy
[17:53] <sergiusens> is there a solus image fox lxd?
[17:53] <ikey> so i can wait
[17:53] <niemeyer> ikey: It does support micros
[17:53] <ikey> niemeyer, oo shiny
[17:53] <ikey> so i can have a built-in please-dont-even-no-stop
[17:53] <niemeyer> Yeah, that was the idea all along
[17:53] <ikey> i like
[17:54] <ikey> i just dont wanna put up with the flood of bugs about the runtime
[17:54] <Chipaca> i think it's a late warning, but it's better than nothing
[17:54] <ikey> OMG DOESNT WORK ON MY ARCH LOONEXISES
[17:54] <Chipaca> ie it's at validation time, once the download is done
[17:54] <ikey> sergiusens, ive never made an lxd image
[17:54] <ikey> but like, if one is wanted, i could figure out how to cook one
[17:54]  * ikey doesn't use lxd 
[17:55] <ikey> i just have a "make boot" command for all my ISOs in qemu and thats the extent of my virtualisation work
[17:56] <sergiusens> ikey I wouldn't mind one :-) if you don't mind, I guess stgraber wouldn't mind adding it to the image repo
[17:56] <niemeyer> Alright.. I'll go out for some exercising while the sun still shines
[17:56] <niemeyer> See you soon
[17:56] <Chipaca> I'm going to EOW now
[17:56] <ikey> you have sun?
[17:56] <Chipaca> niemeyer: o/
[17:56] <niemeyer> Chipaca: Have a good one
[17:56] <ikey> 17:56 here and black as a pint of the good stuff
[17:56] <Chipaca> ikey: he's in brazil; if he doesn't have sun, we dead
[17:56] <ikey> oh lol
[17:57] <niemeyer> ROTFL
[17:57]  * ikey likes that way of putting it :P
[17:57] <cjwatson> ikey: eh, they call it the emerald isle for a reason, right?  never stops raining
[17:57] <ikey> pretty much
[17:57] <ikey> other countries have rumours of ghosts, girls hit by cars and such
[17:57] <ikey> we have rumours of dry children walking the streets
[17:57] <ikey> horrific stuff
[18:03] <sergiusens> elopio have time for a quick hangout?
[18:18] <elopio> sergiusens: I was finishing your review to go out and find lunch. I can delay that, but I'm a little hungry. Is it urgent? or can we talk by chat?
[18:20] <sergiusens> elopio after your lunch
[18:21] <elopio> sergiusens: I'll ping you.
[18:21] <sergiusens> k
[18:51] <jdstrand> ikey: re udev rules in snaps> there aren't plans (currently) to ship udev rules in app snaps. the udev interfaces backend is meant to be used for that (eg, the modem-manager interface creates the udev rules for modems when a snap implementing the slot is installed)
[18:51] <ikey> hm ok
[18:51] <ikey> so the "issue" that i have is steam ships udev rules
[18:51] <ikey> and thats mostly for the steam controller
[18:52] <ikey> and htc vive
[18:52] <ikey> so right now with the steam snap they'd be bork
[18:52] <jdstrand> ikey: we could think that through, but the joystick interface could be updated and the steam snap could slot it, or we can create a steam slot
[18:53] <ikey> ah thats a good point
[18:53] <ikey> fwiw i do realise this is a fairly specialist case and i dont wanna be unfair on you guys
[18:53] <ikey> but i do suspect the steam snap will be ... somewhat popular
[18:53] <jdstrand> or we create a game-controller interface that ships all the different controller udev rules, or something
[18:53] <ikey> yeah
[18:54] <jdstrand> this wouldn't be difficult at at all. the hard part would be to decide the name and how to organize the controllers. that would be a great forum topic
[18:54] <ikey> ok
[18:54] <ikey> for me i just wanna finally *solve* steam, and i think snap is the best way to accomplish this..
[18:54] <ikey> and i think its some brownie points for snapd too :P
[18:54] <jdstrand> that would be awesome
[18:54] <jdstrand> :)
[18:55] <ikey> we've been doing this stuff for like 2 years now, its actually remarkable seeing it all (literally) squashed down into these two snap files
[18:55] <jdstrand> once the design is in place, I could whip something up for 2.30
[18:55] <jdstrand> (for the controller)
[18:55] <ikey> yeah
[18:55] <jdstrand> controllers*
[18:55] <ikey> it'd also allow feral to have their udev rules in snapd too
[18:56] <ikey> for the wheels and such
[18:56] <ikey> centralising it would be nice
[18:56]  * jdstrand nods
[18:57] <ikey> i used to be annoyed with the game porters because of the state of linux gaming, but honestly these days i get it and i feel sorry for them. they didn't ask for the state of the runtime..
[18:57] <ikey> whats the right way to go about doing a call for testing for a snap?
[18:57] <ikey> given that mine requires patches to snapd
[18:57] <jdstrand> yeah. 'linux' is a thousand different things to a thousand different people
[18:57] <ikey> mm
[18:58] <ikey> the "actual" steam runtime is painful to look at, ubuntu 12.04 libs and such
[18:58] <jdstrand> but like you said, snaps has the very real potential to fix that
[18:58] <ikey> pre C++ ABI breaks
[18:58] <ikey> yeah
[18:58] <ikey> its why i ran away from appimage and such
[18:58] <ikey> they don't solve ABI problems
[18:59] <ikey> (plus the appimage code leaves much to be desired to be frank)
[18:59] <jdstrand> I always wondered why the steam ppa was still on an old release
[18:59] <ikey> i get the distinct impression valve trapped themselves
[18:59] <ikey> with their own runtime
[18:59] <ikey> which, tbf, back in the day it worked
[18:59] <jdstrand> huh
[18:59] <ikey> and then everything changed
[18:59] <ikey> and they never *designed* the runtime
[19:00] <ikey> nowadays if you designed it, you'd design ABI profiles
[19:00] <ikey> in this version we have blahblah
[19:00] <ikey> and you'd avoid host contamination
[19:00] <ikey> it doesn't have any of that
[19:00] <jdstrand> eww
[19:00] <ikey> so we're left with the only conclusion
[19:00] <ikey> replace the runtime *and* the host
[19:00] <ikey> make them one
[19:01] <ikey> much of LSI is 2 libraries which use LD_AUDIT to hijack the dynamic linker to make things point at system libs all the time, and LD_PRELOAD to unbreak game breaking bugs
[19:01] <ikey> but it still needs the distro work
[19:01] <ikey> like all the libs + emul32 cruft
[19:01] <ikey> its really hard to integrate LSI :)
[19:02] <ikey> case in point, look at all these deps: https://dev.solus-project.com/source/steam/browse/master/package.yml
[19:02] <ikey> they were all enabled just for steam, and their chains..
[19:03] <jdstrand> what, no wayland?
[19:03]  * jdstrand ducks
[19:03] <ikey> XD
[19:03] <ikey> actually we did try
[19:03] <ikey> but the SDL client has X11 specific calls
[19:04] <ikey> we use Steam with our own SDL to alleviate client issues (broken videos etc)
[19:04] <ikey> if you use SDL_VIDEO_DRIVER=wayland it craps out :p
[19:04] <jdstrand> heh
[19:04] <ikey> we now have specialist snapd support in LSI btw
[19:04] <ikey> https://github.com/solus-project/linux-steam-integration/blob/master/src/intercept/snapd.c
[19:04] <jdstrand> not surprised. some day. I mean, I'm using wayland, but it is far from perfect even for my limited use
[19:04] <ikey> you can get an idea of what the rest of LSI does just looking at that
[19:05] <ikey> yeah wayland has a ways to go
[19:18] <mup> PR snapd#4174 closed: packaging/arch: packaging update <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4174>
[19:24] <mup> PR snapd#4204 opened: store: enable "base" field from the store <Created by mvo5> <https://github.com/snapcore/snapd/pull/4204>
[19:37] <sslb> I'm having an issue with all snaps on my system - rocketchat-server.rocketchat-mongo[1086]: cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
[19:37] <sslb> When trying to run the "hello-world" snap it is giving me the same error
[19:37] <sslb> Running everything as root
[19:46] <mup> PR snapcraft#1723 closed: sources: workaround for ZipFile.extractall not preserving permissions <Created by mariogrip> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1723>
[20:01] <zyga-ubuntu> re
[20:01] <zyga-ubuntu> mvo: I noticed you are still working, how can I help?
[20:11] <ikey> jdstrand, i decided to be "responsible" (ew) and create a forum topic about the controller thing per your suggest
[20:11] <ikey> (obviously doesn't demand immediate attn, EOW and all that)
[20:13]  * ikey leaves the channel with a tune to start the weekend to
[20:13] <ikey> https://www.youtube.com/watch?v=YR5ApYxkU-U
[20:20] <elopio> sergiusens: back
[20:21] <sergiusens> elopio going for a walk now, in an hour?
[20:22] <elopio> sergiusens: I'll be here.
[20:30] <sergiusens> elopio let's do it now; my family gets home soon at it is a lot louder
[20:30] <sergiusens> walk canceled
[20:38] <mup> PR snapcraft#1645 closed: ruby plugin: new stable release 2.4.2 <enhancement> <Created by nathanhaines> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1645>
[20:39] <ikey> ok this is mighty interesting
[20:39] <ikey> i can "sorta" get steam client working with strict confinement
[20:40] <zyga-ubuntu> ikey: yeah?
[20:40] <ikey> https://hastebin.com/gofometume.vbs
[20:40] <zyga-ubuntu> ikey: (disclaimer) I'm a bit drained and I plan to debug 14.04 issues early next week but I can look at steam and definitely mvo and me can help with base snaps
[20:40] <mup> Bug #14: There is no link to the bugtrackers config page <iso-testing> <lp-bugs> <Launchpad itself:Fix Released> <https://launchpad.net/bugs/14>
[20:41] <zyga-ubuntu> what is that sysfs resource thing?
[20:41] <zyga-ubuntu> pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.3/resource: Permission denied
[20:41] <mup> PR snapcraft#1530 closed: tests: share the cache dir in the integration suite <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1530>
[20:41] <ikey> this is steam tryna find pci devices
[20:41] <ikey> i.e. GPUs
[20:41] <zyga-ubuntu> aah
[20:41] <zyga-ubuntu> I see
[20:41] <zyga-ubuntu> that should be ok, it should get access to gpus but not to random stuff
[20:41] <zyga-ubuntu> unless it breaks it :)
[20:42] <ikey> yea
[20:42] <ikey> we'll find out
[20:42] <ikey> but
[20:42] <ikey> but
[20:43] <ikey> its only breaking parts of the client
[20:43] <ikey> so the web portion is bork obviously
[20:43] <ikey> but ill need to consult other cef/chromium snaps to see how they do it
[20:43] <ikey> games *work*
[20:43] <zyga-ubuntu> :)
[20:43] <zyga-ubuntu> I think chromium sandbox is the thing
[20:43] <ikey> yea
[20:43] <jdstrand> ikey: thanks!
[20:43] <zyga-ubuntu> it requires privilege to setup
[20:43] <ikey> and i think im missing XDG crap
[20:43] <zyga-ubuntu> hey jdstrand :)
[20:43] <ikey> but looky https://ibin.co/3gqknFqXOwQo.png
[20:43] <zyga-ubuntu> xdg crap?
[20:44] <ikey> yeah XDG vars
[20:44] <ikey> because "/u1000-" path
[20:44] <zyga-ubuntu> aha
[20:44] <ikey> but hey i mean this is mahusive progress
[20:44] <ikey> we know we *can* have strict confinement steam
[20:44] <ikey> which makes me vury happy because outdated libs that LSI mightn't catch
[20:45] <zyga-ubuntu> ikey: I think it's very very desirable
[20:45] <zyga-ubuntu> especially for for-profit random binary outdated libs
[20:45] <ikey> yeah
[20:45] <ikey> well LSI actually does some utter voodoo to alleviate that
[20:45] <ikey> we ban vendored ssl, curl, curl-gnutls, etc
[20:46] <ikey> games just can't use them
[20:46] <ikey> and even for games now using libressl, we have a special shim package and LSI redirects linking to libssl-libressl.so, libcrypto-libressl.so, etc
[20:46] <ikey> so if they're using libs we don't yet handle, we actually forcibly break them
[20:46] <zyga-ubuntu> yeah but "mr spongebob and adventures in lalaland can spy on $HOME
[20:46] <ikey> until we have a rule to handle their security libs
[20:46] <ikey> true
[20:46] <ikey> or a game could capture credentials
[20:46] <ikey> etc
[20:47] <zyga-ubuntu> it's a process but getting steam inside the sandbox is a big step in the right direction
[20:47] <ikey> yeah
[20:47] <ikey> this way we dont need to convince valve to sandbox games or use snaps for games
[20:47] <ikey> we snap the entire execution environment and all children
[20:47] <ikey> so they don't do anything but everyone profits
[20:48] <ikey> (except me. this shit costs a lot of money)
[20:49]  * zyga-ubuntu hugs ikey :)
[20:49] <zyga-ubuntu> I wish gog were a bit more serious about their dosbox games on linux
[20:49] <zyga-ubuntu> but I guess ENOMARKET
[20:49] <ikey> yea
[20:50] <zyga-ubuntu> well, little by little
[20:52] <ikey> well, im quite happy with the progress made on this whole steam thing in the last few days
[20:52] <ikey> my apologies for being stressy about the whole zenity thing :p
[20:52] <ikey> ive got some minor startup bugs to alleviate too like its reliance on zenity + lsb_release
[20:52] <ikey> but i can have modified versions of both in the snap
[20:52] <ikey> so that they don't try to access /etc/lsb_release
[20:53] <zyga-ubuntu> ikey: no apologies necessary
[20:53] <zyga-ubuntu> ikey: thank you for trusting us with snaps and pushing forward :)
[20:53] <ikey> well i figured it was high time i stopped talking about it and actually did it :D
[20:56] <ikey> btw posted to https://plus.google.com/+Solus-Project/posts/NUChGnTk29M if you wanna social medias it or anything
[20:56] <ikey> re the confinement
[20:56] <jdstrand> roadmr: hi! can you sync r939 of the review tools?
[20:59] <zyga-ubuntu> ikey: oh :)
[21:01] <zyga-ubuntu> ikey: shared :)
[21:02] <mup> PR snapd#4205 opened: add spread test for allocating TUN/TAP devices with network-control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4205>
[21:04] <ikey> ta :D
[21:07] <zyga-ubuntu> ikey: also on twitter
[21:10] <zyga-ubuntu> jdstrand: reviewing
[21:15] <zyga-ubuntu> done
[21:15] <zyga-ubuntu> jdstrand: sorry for the nits, I can address those if you want me to
[21:18] <jdstrand> I can do it
[21:19] <zyga-ubuntu> jdstrand: this is not super important in small scripts but I try to encourage everything to pass mypy strict validation
[21:20]  * zyga-ubuntu reads https://lwn.net/Articles/738694/
[21:20] <jdstrand> mypy? I do use pyflakes3 and pep8
[21:22] <zyga-ubuntu> jdstrand: I find them orthogonal in many ways
[21:23] <zyga-ubuntu> jdstrand: mypy is great at giving python a static language feeling
[21:23] <zyga-ubuntu> with that rarely running else statement also being type checked
[21:25] <ikey> zyga-ubuntu, ta :)
[21:26] <ikey> oh clever tweet too
[21:26] <zyga-ubuntu> (especially for things that are small and not tested other than the hard way :)
[21:26] <zyga-ubuntu> ikey: clickbait at its best
[21:26] <ikey> love it
[21:26]  * jdstrand doesn't usually like tracecbacks for error output, but rolls with SystemExit
[21:27] <zyga-ubuntu> jdstrand: oh, system exit doesnt traceback
[21:27] <zyga-ubuntu> AFAIR
[21:27]  * zyga-ubuntu checks
[21:27] <zyga-ubuntu> yep
[21:27] <zyga-ubuntu> no TB
[21:29] <nacc> https://docs.python.org/3.6/library/exceptions.html#SystemExit
[21:29] <nacc> specifically mentioned in the docs :)
[21:30] <zyga-ubuntu> nice
[21:30] <jdstrand> it did here with:
[21:30] <jdstrand> except PermissionError as e:
[21:31] <jdstrand>     raise SystemExit(e)
[21:31] <jdstrand> you recommended 'raise SystemExit(...)'
[21:31]  * zyga-ubuntu looks
[21:31] <nacc> jdstrand: in the docs
[21:31] <nacc> if it has another type (such as a string), the object’s value is printed and the exit status is one.
[21:32] <nacc> so i thikn it's printing hte exception object
[21:32] <zyga-ubuntu> jdstrand: do you see a traceback?
[21:32] <nacc> imo, you want 'raise SystemExit from e'
[21:32] <jdstrand> yes
[21:32] <jdstrand> http://paste.ubuntu.com/25934287/
[21:32] <zyga-ubuntu> I hmm
[21:32] <zyga-ubuntu> zyga@fyke:~$ cat foo.py
[21:32] <zyga-ubuntu> raise SystemExit(ValueError("omg"))
[21:32] <zyga-ubuntu> zyga@fyke:~$ python3 foo.py
[21:32] <zyga-ubuntu> omg
[21:33] <nacc> that's not from the raise, though
[21:33] <nacc> (afaict)
[21:33]  * nacc doens't know the code he's looking at, admittedly :)
[21:33] <jdstrand> you're right. I didn't catch this one
[21:33] <jdstrand> nm
[21:34] <zyga-ubuntu> could that be contextlib.contextmanager
[21:34] <jdstrand> no
[21:34] <nacc> jdstrand: ah ok
[21:34] <jdstrand> it is fcntl.ioctl
[21:34] <nacc> jdstrand: yeah it just looks like an unhandled PermissionError
[21:35] <zyga-ubuntu> funky :)
[21:35] <zyga-ubuntu> jdstrand: in my spare time I used to love adding bindings go glibc
[21:35] <jdstrand> what I am saying is that I thought that the raise SystemExit() caused it. it did not. it was actually an unhandled PermissionError
[21:35] <zyga-ubuntu> to expose each interesting bit in python
[21:38] <zyga-ubuntu> jdstrand: except Exception: raise ?
[21:39] <zyga-ubuntu> jdstrand: isn't that a no-op really?
[21:39] <zyga-ubuntu> jdstrand: valid_device_name is not annotated
[21:39] <jdstrand> well, it isn't a no-op, but it isn't strictly required, sure
[21:40] <zyga-ubuntu> jdstrand: I mean, in absence of this code we raise anyway
[21:40] <zyga-ubuntu> jdstrand: so it seems there's no way to observe that this code is or isn't there
[21:40] <zyga-ubuntu> (am I missing something?)
[21:41] <jdstrand> zyga-ubuntu: that's what I meant. I'll just remove it
[21:41] <jdstrand> zyga-ubuntu: if a function returns bool, what should I use in the annotation?
[21:41] <zyga-ubuntu> (nitpick) closing_fd could be annotated as (closing_fd(fd: int) -> Iterable[int]
[21:41] <zyga-ubuntu> -> bool
[21:42] <jdstrand> you are nitpicking your nitpick now :P
[21:42] <zyga-ubuntu> jdstrand: I just realized that :)
[21:42] <zyga-ubuntu> hehe
[21:42] <zyga-ubuntu> must be Friday
[21:43] <jdstrand> ameError: name 'Iterable' is not defined
[21:43] <zyga-ubuntu> from typing import Iterable
[21:43] <zyga-ubuntu> it's a part of stdlib now
[21:43] <jdstrand> what do I need to import for that?
[21:43] <jdstrand> ok
[21:47] <zyga-ubuntu> https://twitter.com/michaelklishin/status/929096325056081920
[21:48] <jdstrand> heh
[21:57] <roadmr> jdstrand: hi! sure, I'll put that in the pipeline
[22:02] <gps1539> Maybe hard to ask for help over irc, but here goes.
[22:02] <gps1539> I have a topic on https://forum.snapcraft.io/t/how-to-call-dependencies-in-snapcraft-yaml/2726/9
[22:02] <sergiusens> zyga-ubuntu I started using mypy last week myself; best next thing to not being able to compile
[22:03] <zyga-ubuntu> sergiusens: I agree :)
[22:03] <gps1539> but it got flagged when I posted my yaml file and setup.py
[22:03] <zyga-ubuntu> sergiusens: it's worth tracking upstream releases
[22:03] <gps1539> where can I go for help>
[22:03] <zyga-ubuntu> sergiusens: follow jukka on twitter
[22:05] <sergiusens> gps1539 look in the prime directory; most likely it is in bin/treepass
[22:08] <gps1539> grep -r trespass come up blank, nothing under prime
[22:08] <ikey> heh figured out my ugly zenity issue
[22:08] <ikey> convert the build to gresource..
[22:10] <gps1539> can folks see the topic on the forum? I can not so not sure if it got pulled
[22:12] <gps1539> pip install trespass works fine although it installs to /usr/local/bin/trespass and not /usr/bin/trespass (which is does on Arch)
[22:12] <gps1539> Any clues to what I'm missing in my yaml
[22:40] <sergiusens> that was a short stay, oh well
[22:59] <elopio> snappy-m-o autopkgtest 1657 xenial:armhf
[22:59] <snappy-m-o> elopio: I've just triggered your test.
[23:53] <elopio> snappy-m-o autopkgtest 1716 xenial:armhf
[23:53] <snappy-m-o> elopio: I've just triggered your test.