[00:02] PR snapd#4199 opened: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch [00:12] elopio, are you suuuuure that adt installs squashfuse? [00:13] Because it doesn't look like it is. Can you point me to where it should be doing that? [00:13] elopio, it's not in debian/tests/control, for example [00:49] kyrofa that's done on run_lxd_container.sh [01:48] PR snapcraft#1726 opened: schema: sources should not have defaults [01:48] got my .snap files uploaded to my server for testing, buuuut [01:48] it does require the snapd patches ive put in today [01:49] and also requires --devmode --dangerous.. [01:56] kyrofa: you are right, it is not installed, I see it failing on my WIP branch. [02:00] you can add --setup-commands [03:04] PR snapd#4200 opened: Return snap-not-installed error in more cases [03:05] Bug #1659106 changed: snap refresh/enable/disable doesn't return snap-not-installed error, returns generic 400 instead [04:27] PR snapcraft#1724 closed: tests: use the common base handler on the fake snapd server === JoshStrobl|zzz is now known as JoshStrobl [06:21] morning guys [06:27] hey mborzecki, good morning [06:30] mvo: o/ [06:30] did you hear back from lenovo? [06:31] mborzecki: my machine needs to be send in, will take ~5-7 days or so [06:32] mborzecki: until then I'm with my crufty old t400 [06:32] (and my desktop which is decently powerful) [06:32] 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] hahah [06:34] is your desktop one of the ryzen builds? [06:38] hmm,2017-11-09 15:44:32 Failed project prepare: 1 [06:38] - linode:fedora-25-64:project [06:39] mborzecki: the desktop is a whitebox that I built from custom parts, but its not very fancy [06:39] 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] /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 14: fw_printenv: command not found [06:40] this sounds like a u-boot command [06:41] mborzecki: yes, that is strange that it would use that on a regular machine [06:42] hm found nother one that failed like this [06:45] `if command -v grub-editenv >/dev/null; then` this line failed on fedora [06:46] maybe we're missing some bit in fedora cloud image [06:46] is there any reason why inside my snap a .so file might appear to be a directory when shared from home..? [06:46] this seems .. slightly bizarre. [06:48] ikey: probably a question for zyga-solus, my bet is on some bind mount logic that got it wrong [06:48] ty [06:49] ok this time its not a directory.. [06:49] last time it was [06:49] o_O [06:49] heisenbug [06:49] lol [06:51] mvo: hm there's no grub-editenv in fedora, it's named grub2-editenv there [06:51] Early hellos [06:52] niemeyer: hi, isn't that like a midnight at your place? [06:53] mborzecki: Almost 5am.. crashed a bit earlier yesterday [06:54] pedronis: About the open PRs, yeah, I really need to get into reviews.. will send up the board shortly [06:55] niemeyer: woah, good morning [06:57] ok it wasnt a snap issue incidentally [06:57] its a weird feral thing [06:58] mborzecki: hm, wonder why the fedora machine suddenly starts failing, but maybe just an update [07:01] mvo: Moin! [07:02] ikey: what did you do? [07:02] oh i didnt [07:02] so the game has "bin/libpdf.so" and "lib/libpdf.so" [07:02] and "bin/libpdf.so" is actually a directory [07:02] confused the hell out of me [07:02] and the linker was like "nope i dont even" [07:06] 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] then, the offending lines in boot.sh were last touched in 2016 [07:08] i'll try to fix this [07:20] PR snapd#4201 opened: tests/lib: handle distro specific grub-editenv naming [07:22] 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] mborzecki: thank you [07:23] ok, talk to you later [07:27] * zyga-solus -> quick late breakfast [07:27] sorry, kids were very stubborn today and were late for school [07:28] oh, breakfast [07:28] not a bad idea [07:29] * zyga-solus eats what kids left behind ^_^ [07:29] :D [07:36] * mvo shakes fist at nvidia driver, its in a gdm3 restart loop rightnow [07:36] https://forum.snapcraft.io/t/review-sprint-4/2765 [07:37] mvo: wrong driver [07:37] mvo: did you install it just now or update? [07:37] niemeyer: thank you! [07:37] zyga-solus: np, that part was easy :P [07:37] zyga-solus: happend out of the blue which is very strange [07:38] zyga-solus: when I started this morning [07:38] mvo: woah [07:38] can you ssh into the machine? [07:38] syslog has the details of why x cannot start [07:38] for me it had something like "bla bla bla, use legacy driver, bla bla bla" [07:41] zyga-solus: yeah, it just says "nvidai: cannot load module", no worries, I will figure it out, its just super annoying [07:41] I haven't seen that one [07:41] zyga-solus: google is very light on it as well [07:43] zyga-solus: going back to nvidia-340 "fixed" it [07:43] mvo: from 37x? [07:43] from 384 [07:53] mvo: woah, 2.29.3 has plenty of things that are not in master [07:53] zyga-solus: yes [07:53] zyga-solus: its very annoying, we need to fix this [07:53] I see I will have some merges to do in the full udev hooks branch [07:54] zyga-solus: should apply cleanly, no? [07:54] mvo: not really, I did extra changes after jdstrand's desire to change formatting of udev rules [07:54] mvo: mostly just annoying stuff in tests (extra comments and order changes) [07:54] zyga-solus: but all on top of the exiting commits? [07:54] but that's ok [07:54] ay [07:54] yes [07:54] that should merge cleanly! [07:54] I didn't think about that [07:54] yeah, fingers crossed :) [07:55] I wonder why is travis so red today [07:55] 50 open PRs, sounds like work today [07:55] mvo: hmmm [07:55] mvo: 2.29.3 has failing unit tests [07:55] zyga-solus: there was a grub-editenv issue on fedora that ma looked into earlier [07:55] zyga-solus: wuut? [07:55] mvo: looks real :/ [07:56] 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] mvo: no idea how [07:56] zyga-solus: hm, that build in the ppa so it can't be universal [07:56] mvo: maybe ungreen PR was merged into 2.29 [07:56] * mvo looks [07:57] 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] very confusing then [07:57] mvo: let's see if I can reproduce [07:59] mvo: yep [07:59] real failure [07:59] looking at which part is right [07:59] zyga-solus: can you pastebin it please? [07:59] sure [08:00] http://pastebin.ubuntu.com/25930345/ [08:01] 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] yep [08:01] looks genuinely buggy [08:01] test is right, code is wrong [08:01] * zyga-solus wonders [08:01] maybe misaligned something [08:01] I didn't do that [08:01] I did mvo/release-2.29.3 [08:01] I recall those usb interface number PRs were recent [08:02] maybe cross-merged badly [08:02] zyga-solus: oh, indeed [08:02] zyga-solus: that is probably it [08:02] gah [08:02] there I see it as well [08:02] 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] ikey: is this a feature I'm not aware of [08:03] mvo: wait, so what is in 2.29.3? [08:03] mvo: because this is _pre_ merge [08:03] mvo: (heart attack may need to come back) [08:04] mvo: and this is not right for sure [08:05] zyga-solus, mutter borkified all sane notions of reserved struts :( [08:10] mvo: I pushed a patch to that PR [08:10] mvo: please look [08:10] 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] mvo: but I'm worried how is this possible [08:10] mvo: aha [08:11] * ikey agrees with the C udev thingy fwiw [08:11] mvo: can you look if the 2.29 release has the other usb-interface-num patches? [08:11] is that a feature in this release? [08:11] 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] mvo: I don't recall adding that, it may have come from master [08:12] 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] mvo: let me look at the history to find this patch [08:13] mvo: I see it in b2991126738db2e9bf041a5da014cadc436e5ae2 [08:13] mvo: which is not in release/2.29 [08:13] 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] zyga-solus: all good then :) [08:13] mvo: but how is it in 2.29.3 PR? [08:14] mvo: if you released from that branch it's going to be bogus and will fail adt [08:14] zyga-solus: its 2.29.3 plus master (to fix the conflicts, i.e. to make it mergable into master) [08:15] ahhh [08:15] 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] ok [08:15] all good [08:15] yes [08:15] uff [08:15] exactly [08:20] * ikey ponders how he'd go about stracing a process inside of a snap.. [08:20] ha [08:21] we need to add snap run --strace [08:21] it's a common request [08:21] it's not super easy unfortunately [08:21] didn't you have some magical super invocation? [08:22] * ikey searches forum [08:22] no, because it requires doing a few steps [08:22] the profile of the app has to change to allow that [08:22] ah yep ive pissed it off [08:26] ok yeah need to exclude pselect6 too [08:35] oh, nice, autopkgtests are gone now [08:35] mvo: do we have a way to trigger them manually? [08:36] zyga-solus: sort of, cachio is looking into it [08:37] great === __chip__ is now known as Chipaca [08:58] PR snapd#4187 closed: tests: fix xdg-open-compat [09:05] PR snapd#4180 closed: interfaces/many: misc policy updates for browser-support, cups-control and network-status [09:11] anyone got experience with running chrome/cef stuff under snap? [09:11] if i install with --classic - cef works (i.e. feral games like Hitman) [09:11] yet if i use --devmode, it doesn't [09:11] get execvp errors with empty argv[0] [09:15] ikey: no, sorry [09:15] what is cef? [09:15] like chrome-based apps [09:15] aha [09:15] spotify and such [09:15] all have a libcef.so [09:16] 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] PR snapd#4157 closed: add spread test for connecting all interfaces (excepting gadget slots) [09:18] 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] mborzecki: morning sir. What is, in your view, the plan for group lookup? [09:34] niemeyer: hi and ack [09:34] hellp [09:34] *hello [09:36] hey pedronis and Chipaca - good morning [09:36] zyga-ubuntu: your udev PR looks fine, once tests are green it can go in I think [09:36] pedronis: yo [09:40] mvo: I though pstolowski requested some test tweaks for it in the 2.29 variant [09:40] *I thought [09:41] for which PR? [09:41] PR snapd#3994 closed: tests: fix revert test when a new core image is pushed [09:41] 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] PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules [09:42] mvo: good morning sir [09:42] 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] ah, udev pr [09:42] mborzecki: i think cgo is only a potential problem in snapd, which is long-lived; the others shouldn't be as concerned [09:43] mborzecki: so 4188 goes away? [09:43] #4188 [09:43] PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user [09:44] i'd leave it open for now, and once the bits i needed are merged i'll close it [09:46] Chipaca: does that sound ok to you? [09:46] 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] pstolowski: yes, I put a link to them in the non-2.29 one [09:47] beyond being in review sprint mode (ie reviews before code) [09:47] mvo: what's up with #4122? two +1's and not merged. Just waiting for green? [09:47] PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError [09:47] Chipaca: fair point, let's close it for now then, we can always reopen it if needed [09:48] pedronis, thanks [09:48] 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] Chipaca, mborzecki: Avoiding cgo in snap-seccomp is probably impossible with the current design [09:50] Ah, sorry, not seccomp [09:50] snap-update-ns [09:50] PR snapd#4188 closed: osutil: replace cgo bits with non-cgo, vendored os/user [09:51] Chipaca, mborzecki: Ah, and snap-seccomp too, for different reasons (libseccomp) [09:51] niemeyer: good morning to you too :-) have you even slept? [09:51] Chipaca: Sorry, good morning :) [09:52] niemeyer: ah, i didn't mean it in that way, but it works :-D [09:52] Chipaca: Yeah, I have.. went to bed earlier than usual yesterday, so started earlier today still, and will probably stop earlier too :) [09:52] Chipaca: i only needed looking up a group name using its gid, but we have a workaround for this now [09:52] niemeyer: fair enough [09:52] Chipaca: Still wondering about the cgo issue.. [09:53] niemeyer: pedronis has flagged you for some reviews i see, so you've got your work cut out :-) [09:53] Chipaca: Yeah, we've got the review board too, not sure if you've seen the message earlier today [09:54] Chipaca, mborzecki: As for cgo, I'm on the fence between suggesting dropping and making that interaction more awkward vs. the benefits [09:54] We cannot drop glibc completely from the snapd environment due to the external tools we need [09:55] So the sole benefit would be a more bullet proof snapd [09:55] niemeyer: yet :) [09:55] niemeyer: the apparmor_parser thing could run in a tiny tiny tiny base snap [09:55] zyga-ubuntu: Without further information that's a bit of wishful thinking [09:55] niemeyer: going down the review board is how i saw you flagged in some [09:55] niemeyer: yeah, just saying it's not ultimately impossible [09:56] zyga-ubuntu: Yeah, but we're not able to do that any time soon [09:56] agreed [09:56] 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] so from that pov i don't see the benefit [09:56] Chipaca: That's a bit of a different thing [09:56] ok :-) [09:56] Chipaca: systemd will be in the base [09:57] niemeyer: uh, no? [09:57] how? [09:57] Chipaca: uh, hopefully yes? :) [09:57] niemeyer: so you can't have more than one base? [09:57] or there is a base that's special and different? [09:57] Chipaca: Consider this: which systemd is used when the host system is Ubuntu 16.04 [09:58] niemeyer: not the one in the base [09:58] Chipaca: Not the one in any snap [09:58] quite [09:59] Chipaca: Right.. so this is not actually a fundamental dependency of the snapd-carrying nsap [09:59] snap [09:59] niemeyer: consider this: what systemd starts snapd in core? [09:59] Chipaca: The one in the base ;) [09:59] niemeyer: which base? [09:59] in a special base that's baser than the rest? [09:59] the base of the snapd snap [09:59] Chipaca: Exactly.. I'm describing the goal [10:00] the snapd snap will have a base? [10:00] so we force solus to have a ubuntu 16 base even if none of their snaps use ubuntu 16? [10:00] Chipaca, mvo: We can have a specific base snap that is the one mounted as the root filesystem on core devices [10:00] ah [10:00] no i got it [10:00] ok [10:01] Chipaca: yeah, maybe not, probably more something implicit [10:01] so snapd doesn't have a base, but ubuntu core is a special base [10:01] fedora core would be a different special base [10:01] solus core would just be ikey, punching donkeys [10:01] Chipaca: It might have a base, but it might not be the one that Ubuntu Core requires [10:02] 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] The status quo of base snaps is that we did not yet do the split of core [10:02] * mvo nods [10:02] yep [10:02] This is the second part, and it's independent of support for bases in app snaps [10:03] '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] So we haven't yet firmly made such decisions, and we also haven't closed any of those doors yet [10:03] Chipaca: Yeah, and np, the conversation is healthy [10:04] mvo: hmm [10:04] ● snap-repair.timer not-found failed failed snap-repair.timer [10:04] mvo: this is from vanilla 16.04 install [10:04] we're shipping the repair timer? [10:04] ah, sorry, zesty [10:04] /lib/systemd/system/snapd.snap-repair.service [10:04] /lib/systemd/system/snapd.snap-repair.timer [10:04] it seems we are [10:04] mvo: is this really desirable? [10:04] zyga-ubuntu: it is disabled, no? [10:04] it's failed [10:04] not disabled [10:04] zyga-ubuntu: it makes packaging simpler, it has a condition [10:05] zyga-ubuntu: systemctl status snap-repair.timer ? [10:05] mvo: if you make it an assertion instead of a condition it works the same, but logs the reason [10:05] zyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.service [10:05] ● snapd.snap-repair.service - Automatically fetch and run repair assertions [10:05] Loaded: loaded (/lib/systemd/system/snapd.snap-repair.service; static; vendor preset: enabled) [10:05] Active: inactive (dead) [10:05] zyga-ubuntu: it should be in "condition failed" state which is not an error (even if it sounds like one) [10:05] Docs: man:snap(1) [10:05] zyga@gracik:/etc/systemd/network$ systemctl status snapd.snap-repair.timer [10:05] ● snapd.snap-repair.timer - Timer to automatically fetch and run repair assertions [10:05] Loaded: loaded (/lib/systemd/system/snapd.snap-repair.timer; enabled; vendor preset: enabled) [10:05] Active: inactive (dead) [10:05] mvo: it's showing the machine as in degraded status [10:05] Chipaca: aha, interessting [10:06] zyga-ubuntu: could you please pastebin it? my irc client garbled it [10:06] sure [10:06] zyga-ubuntu: it's snap-repair.timer, not snapd.snap-repair.timer i think? [10:06] zyga-ubuntu: it should not make the machine degraded [10:06] http://pastebin.ubuntu.com/25930918/ [10:06] at least here it is -- which might mean my local install is messed up :-) dunno [10:06] http://pastebin.ubuntu.com/25930922/ [10:07] zyga-ubuntu: and systemctl --failed please [10:07] zyga-ubuntu: systemctl list-timers [10:07] zyga-ubuntu: aha, sorry you did that already [10:07] zyga-ubuntu: it looks like you might have leftover files from an old deb? [10:07] zyga-ubuntu: or maybe everyone has these (which would be bad) [10:08] mvo: no, they are part of the package [10:08] mvo: note: zesty [10:08] mvo: this is my router, not devbox [10:08] so no locally built magic files [10:08] I just noticed because I'm about to shut it down [10:09] 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] zyga-ubuntu: or is this 2.27.6 still? [10:09] strange i seem to have a mix of snapd.snap-repair.timer and snap-repair.timer. Probably need a restart sometime soon? [10:09] mvo: checking [10:09] zyga-ubuntu: apt list snapd [10:10] 2.28.5+17.04 [10:10] curious [10:10] yeah, let me try in my VM [10:10] snapd/zesty-updates,now 2.28.5+17.04 amd64 [zainstalowany] [10:10] zainstalowany is installed [10:11] * zyga-ubuntu moves the final network part now, I'll be offline briefl [10:11] actually not much === zyga-ubu1tu is now known as zyga-ubuntu [10:12] zyga-ubuntu: fresh 17.04 does not have the issue, let me try if I upgrade from 2.27 to 2.28 [10:16] zyga-ubuntu: no luck with 2.27 -> 2.28 either on zesty. hmmm [10:18] PR snapd#4202 opened: cmd: use a preinit_array function rather than parsing /proc/self/cmdline [10:21] jamesh: ouch! brand new pr with conflicts [10:24] Chipaca: gar. I thought I'd pulled master. Let me rebase it [10:25] jamesh: ta [10:29] jdstrand: did i understand you right yesterday, that in #4185 we don't actually need the group name? ie g: works just as well as g:? [10:29] PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules [10:30] Chipaca: afaik it's g: or [10:30] Chipaca: fixed. [10:31] mborzecki: ah. any reason not to do it that way? [10:32] 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] or seccomp [10:32] jamesh: thanks [10:32] jamesh: and good night :-) [10:35]