| === ikey is now known as ikey|zzz | ||
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| mup | PR snapcraft#1608 opened: tests: fix the duplicate plainbox test scenarios <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1608> | 04:27 |
|---|---|---|
| zyga-solus | o/ | 05:03 |
| zyga-ubuntu | it seems another 2.28 point release is ahead | 05:16 |
| mup | PR snapcraft#1609 opened: tests: remove the duplicate nodejs integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1609> | 05:55 |
| * zyga-ubuntu fires spread to debug snap-update-ns issue | 06:29 | |
| mup | PR snapcraft#1610 opened: tests: reenable the cleanbuild integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1610> | 06:34 |
| zyga-ubuntu | mvo: good morning | 06:37 |
| zyga-ubuntu | mvo: guess what day is it today? | 06:37 |
| zyga-ubuntu | mvo: release day | 06:37 |
| mvo | zyga-ubuntu: excited! and good morning | 06:38 |
| mvo | zyga-ubuntu: I have release day every month ;) | 06:38 |
| zyga-ubuntu | mvo: pedronis sent a PR for 2.28 | 06:38 |
| zyga-ubuntu | mvo: looks like something we need to spin .5 for | 06:38 |
| mvo | oh nos | 06:38 |
| * mvo looks | 06:38 | |
| zyga-ubuntu | mvo: I've added debugging for the bug I found in snap-update-ns and I'm waiting for the debug shell to show up | 06:38 |
| mvo | zyga-ubuntu: aha, nice | 06:40 |
| * zyga-ubuntu learns that logger.Noticef doesn't just work :/ | 06:42 | |
| mvo | zyga-ubuntu: hu? | 06:43 |
| zyga-ubuntu | mvo: well, in a CLI program it does nothing at all | 06:45 |
| zyga-ubuntu | mvo: I noticed it is also not working early in initialization of snapd | 06:46 |
| zyga-ubuntu | mvo: it is "enabled" somewhere during startup | 06:46 |
| zyga-ubuntu | I'll look but for now I swapped that for fmt.Printf | 06:46 |
| zyga-ubuntu | I think I solved the bug now, I'll spend an extra moment to link output from snap-update-ns to task log | 06:53 |
| zyga-ubuntu | and look at that noticef thing | 06:53 |
| mvo | zyga-ubuntu: aha, thank you. just read up on the background for 4026, looks like we need a .5 | 07:01 |
| zyga-ubuntu | mvo: I didn't read upon it but I trusted the 2.28 tag | 07:02 |
| zyga-ubuntu | ok, one more run on fedora and I'll push | 07:12 |
| mvo | could someone do a second review of 4026 please? | 07:20 |
| zyga-ubuntu | mm | 07:21 |
| zyga-ubuntu | mvo: what is the back story? | 07:22 |
| zyga-ubuntu | there's nothing on the PR | 07:22 |
| mvo | zyga-ubuntu: backchannel, let me forward | 07:22 |
| mvo | zyga-ubuntu: check your mail | 07:23 |
| zyga-ubuntu | k | 07:23 |
| mvo | (please) | 07:23 |
| zyga-ubuntu | thank you | 07:23 |
| * zyga-ubuntu reviews this now | 07:24 | |
| zyga-ubuntu | mvo: silly question, which store is used on the generic model when UBUNTU_STORE_ID is unset? | 07:25 |
| zyga-ubuntu | mvo: should we not return mod.Store() if UBUNTU_STORE_ID is unset? | 07:26 |
| mvo | zyga-ubuntu: hm, good point | 07:27 |
| zyga-ubuntu | (nothing like silly questions) | 07:27 |
| zyga-ubuntu | mvo: let's tweak that test to have a case like that | 07:27 |
| zyga-ubuntu | if the outcome is sensible then +1 but I think it may be a missing cae | 07:27 |
| zyga-ubuntu | *case | 07:27 |
| mvo | zyga-ubuntu: looks like the generic model is not defining a store so the end result is the same, but I agree with you, it seems cleaner to not rely on this | 07:28 |
| mup | PR snapd#4027 opened: spread: allow setting SPREAD_DEBUG_EACH=0 to disable debug-each section <Created by zyga> <https://github.com/snapcore/snapd/pull/4027> | 07:33 |
| mup | PR snapd#4028 opened: interfaces/mount: don't generate legacy per-hook/per-app mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4028> | 07:33 |
| zyga-ubuntu | mvo: ok, I can work on that now | 07:34 |
| mup | PR snapd#4029 opened: packaging: remove .mnt files on removal <Created by zyga> <https://github.com/snapcore/snapd/pull/4029> | 07:34 |
| zyga-ubuntu | mvo: I pushed a few trivial branches up and I'm working on the extra test case and tweak in behavior | 07:40 |
| zyga-ubuntu | mvo: maybe you could review the three I pushed | 07:40 |
| zyga-ubuntu | mvo: it seems we should not actually tweak the logic there | 07:48 |
| mvo | zyga-ubuntu: I reviewed the first already, will do the others in a bit | 07:49 |
| zyga-ubuntu | mvo: I pushed a test case, let me know if this is sensible | 07:49 |
| zyga-ubuntu | thank you! | 07:49 |
| mvo | zyga-ubuntu: not tweak it, why not? | 07:49 |
| zyga-ubuntu | mvo: not sure how to tweak it | 07:50 |
| zyga-ubuntu | mvo: if the variable is unset, should we use the model? | 07:50 |
| zyga-ubuntu | mvo: the test at least shows us current behavior, maybe it's right, maybe not | 07:50 |
| zyga-ubuntu | mvo: if you tweak the condition now look at what happens to the tests there | 07:50 |
| zyga-ubuntu | mvo: I don't know what the correct behavior is here | 07:51 |
| mvo | zyga-ubuntu: aha, ok. lets wait for pedronis then | 07:51 |
| mvo | zyga-ubuntu: did you ask you question in the PR? | 07:51 |
| zyga-ubuntu | mvo: I pasted our conversation there | 07:53 |
| zyga-ubuntu | I'll look at bridging snap-update-ns logs with the task that uses it now | 07:54 |
| mvo | ok | 07:54 |
| mvo | I will tweak my caching branch based on the nice feedback from pstolowski and then move to squashfs-fuse | 07:55 |
| zyga-ubuntu | ok | 07:56 |
| zyga-ubuntu | squashfs-fuse? | 07:56 |
| mup | PR snapd#4023 closed: tests: fix econnreset scenario when the iptables rule was not created <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4023> | 07:59 |
| Chipaca | moin moin | 08:03 |
| Chipaca | ogra_: question for you: all pi zeros are As, right? i mean, armel and all that? | 08:03 |
| ogra_ | Chipaca, if you mean armv6, afaik yes ... i think popey and flexiondotorg own them (for moe detail) | 08:04 |
| ogra_ | *more | 08:04 |
| zyga-ubuntu | Chipaca: hey | 08:09 |
| Chipaca | ogra_: AFAIK they appear spontaneously in geek kit | 08:10 |
| Chipaca | a friend just told me he suddenly found he had 5 of them | 08:10 |
| Chipaca | he's never bought one | 08:10 |
| ogra_ | heh | 08:10 |
| ogra_ | thats funny | 08:10 |
| Chipaca | :-) | 08:10 |
| Chipaca | OTOH this is the guy that managed to install ubuntu with no x, by just clicking 'next' | 08:11 |
| Chipaca | also he thought he'd installed ubuntu on one of the zeros (which i was pretty sure wasn't possible) | 08:11 |
| zyga-ubuntu | Chipaca: huh, how did he get them? | 08:11 |
| Chipaca | zyga-ubuntu: tech shows and the like | 08:11 |
| Chipaca | zyga-ubuntu: in the uk they come in magazines | 08:12 |
| ogra_ | are you sure it's a zero ? | 08:12 |
| zyga-ubuntu | Chipaca: nice | 08:12 |
| zyga-ubuntu | Chipaca: if you are interested in a review, https://github.com/snapcore/snapd/pull/4008 is juicy | 08:12 |
| mup | PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008> | 08:12 |
| Chipaca | ogra_: that's what he said :-) | 08:12 |
| zyga-ubuntu | (and very important to me) | 08:12 |
| ackk | mvo, hi, is there something utterly wrong with my PR or is CI having issues on https://github.com/snapcore/snapd/pull/3916 ? | 08:12 |
| mup | PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916> | 08:12 |
| zyga-ubuntu | ackk: looking | 08:12 |
| ackk | zyga-ubuntu, thanks | 08:12 |
| zyga-ubuntu | Formatting wrong in following files: | 08:13 |
| zyga-ubuntu | /tmp/static-unit-tests/src/github.com/snapcore/snapd/wrappers/services_gen_test.go | 08:13 |
| zyga-ubuntu | /tmp/static-unit-tests/src/github.com/snapcore/snapd/snap/validate_test.go | 08:13 |
| zyga-ubuntu | go fmt is your friend | 08:13 |
| zyga-ubuntu | I recommend good editor integration (ask for advice if you use vim) | 08:13 |
| mvo | ackk: what zyga-ubuntu said, we can help you by pushing to your branch if you want | 08:19 |
| ackk | zyga-ubuntu, I do have linting, must have missed it | 08:20 |
| ackk | lemme fix it | 08:20 |
| ackk | uhm "buffer is already go-fmt'd" | 08:21 |
| ackk | indeed go fmt doesn't report anything | 08:21 |
| zyga-ubuntu | ackk: maybe gofmt -s ? | 08:21 |
| zyga-ubuntu | maybe save/diff | 08:21 |
| ackk | ah | 08:21 |
| zyga-ubuntu | I can look if you want | 08:21 |
| ackk | zyga-ubuntu, where do you run linting (to check how you run it) | 08:22 |
| zyga-ubuntu | ackk: run-checks --static I believe | 08:22 |
| zyga-ubuntu | ackk: we use gofmt (not go fmt) and pass the -s (simplify expressions) flag | 08:22 |
| zyga-ubuntu | ackk: I suspect it is that, it bit me a few times | 08:22 |
| ackk | ah, that's probably why | 08:23 |
| ackk | go-mode uses go fmt | 08:23 |
| ackk | why are there even two things for the same job? :) | 08:23 |
| zyga-ubuntu | because it's perl^Hgo | 08:23 |
| zyga-ubuntu | ;-) | 08:23 |
| ackk | heh | 08:25 |
| ackk | zyga-ubuntu, mvo should be fixed now, thanks | 08:25 |
| zyga-ubuntu | great, thank you :) | 08:27 |
| Chipaca | zyga-ubuntu: did a bit of it | 08:28 |
| zyga-ubuntu | thank you! | 08:32 |
| zyga-ubuntu | Chipaca: do you think I should split it into more PRs? | 08:32 |
| zyga-ubuntu | Chipaca: I can take the secure mkdir bits out | 08:32 |
| Chipaca | zyga-ubuntu: my brain is swimming in the sweet molasses of sleep, still | 08:33 |
| Chipaca | zyga-ubuntu: it's quite possible the pr is fine as it stands; wait a bit for me to be properly awake? | 08:34 |
| zyga-ubuntu | sure :) | 08:34 |
| zyga-ubuntu | we woke up before 6 today; stark contrast from 8:30 in spain | 08:34 |
| zyga-ubuntu | plus the fact that it's dark outside | 08:35 |
| Chipaca | zyga-ubuntu: my checkpoint was because you're obviously active on the pr, so i didn't want to have 20 questions for you in two hours instead of 5 now and 5 later | 08:35 |
| * zyga-ubuntu nods | 08:35 | |
| ackk | does snapcraft validate the yaml file entirely via yaml schema or is there also programmatic validation for some cases? | 08:46 |
| mup | PR snapcraft#1611 opened: plainbox-provider plugin: init PROVIDERPATH <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1611> | 08:46 |
| * zyga-ubuntu -> break for light meal and tea | 09:04 | |
| popey | huh, irccloud-desktop snap no longer works since I updated to 2.28 and rebooted. | 09:25 |
| popey | alan@hal:~$ irccloud-desktop | 09:25 |
| popey | udev_enumerate_scan failed | 09:25 |
| popey | No apparmor denials | 09:25 |
| ackk | popey, maybe related to https://forum.snapcraft.io/t/weird-udev-enumerate-error/2360 ? | 09:26 |
| popey | magic, thanks | 09:27 |
| ackk | it seems it's fixed in artful https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1713536 | 09:28 |
| mup | Bug #1713536: udev: boot script does not trigger subsystem coldplug <architecture-s39064> <bugnameltc-158070> <severity-medium> <targetmilestone-inin1604> <verification-done> <verification-done-xenial> <verification-done-zesty> <Ubuntu on IBM z Systems:Fix Committed by canonical-foundations> | 09:28 |
| mup | <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Committed> <systemd (Ubuntu Zesty):Fix Committed> <systemd (Ubuntu Artful):Fix Released> <https://launchpad.net/bugs/1713536> | 09:28 |
| zyga-ubuntu | popey: does it happen again? | 09:28 |
| popey | i replied on the forum | 09:29 |
| zyga-ubuntu | ta | 09:29 |
| popey | it happens every time i try and launch irccloud-desktop | 09:29 |
| zyga-ubuntu | hmm hmm hmm | 09:29 |
| popey | ooh | 09:29 |
| zyga-ubuntu | ? | 09:29 |
| popey | other snaps fail too | 09:29 |
| zyga-ubuntu | yes, this is generic udev code path | 09:30 |
| popey | ok | 09:30 |
| zyga-ubuntu | no denials at all? | 09:30 |
| zyga-ubuntu | (not even for snap-confine?) | 09:30 |
| zyga-ubuntu | do you have nvidia on this box? | 09:30 |
| popey | no denials, yes, nvidia | 09:30 |
| zyga-ubuntu | man, /o\ | 09:31 |
| zyga-ubuntu | popey: which driver are you using? I wonder if this is related to anything we saw yesterday | 09:31 |
| popey | ii nvidia-375 375.66-0ubuntu0.16.04.1 amd64 NVIDIA binary driver - version 375.66 | 09:32 |
| popey | apparently | 09:32 |
| zyga-ubuntu | popey: can you use gdb to put some breakpoints and see where it fails? | 09:32 |
| popey | uhhhh | 09:32 |
| zyga-ubuntu | or can you open that 2nd laptop and see if it happens there | 09:32 |
| zyga-ubuntu | I can do it remotely | 09:32 |
| zyga-ubuntu | (note: I tweaked stuff there so you may need to apt-get install --reinstall snapd | 09:32 |
| popey | it doesn't happen on my 17.10 intel laptop | 09:32 |
| zyga-ubuntu | (and replace any conffile changes) | 09:32 |
| zyga-ubuntu | yeah, I suspect this will also tell us something else | 09:33 |
| popey | can dig that machine out again and boot it up, sure | 09:33 |
| zyga-ubuntu | why we had to add those apparmor rules that jdstrand didn't expect | 09:33 |
| zyga-ubuntu | or why we got a denial | 09:33 |
| zyga-ubuntu | we didn't get to the bottom of that | 09:33 |
| popey | so you want me to do that? | 09:33 |
| zyga-ubuntu | popey: if you coupld please check out if it affects that other machine I will gladly investigate remotely | 09:33 |
| popey | kk | 09:33 |
| popey | doing now | 09:33 |
| zyga-ubuntu | thank you | 09:34 |
| popey | remember it's running artful, and ackk says its fixed there? | 09:35 |
| zyga-ubuntu | ah, and your machine that is affected? | 09:36 |
| zyga-ubuntu | is it also artful? | 09:36 |
| popey | The machine that is affected is my 16.04 nvidia machine | 09:37 |
| ogra_ | it was 16.04 for me too | 09:37 |
| popey | ^ monster main laptop which got rebooted last night | 09:37 |
| popey | My secondary (thinkpad, intel) 17.10 laptop does not see the issue | 09:37 |
| ogra_ | and nvidia .... | 09:38 |
| popey | booting the slow old desktop you had access to, to test that | 09:38 |
| zyga-ubuntu | k | 09:39 |
| popey | (which is 17.10 nvidia) | 09:39 |
| popey | Grr. This machine has basically locked up doing "apt remove snapd" | 09:45 |
| zyga-solus | hmm | 09:45 |
| zyga-solus | can you move to a VT? | 09:45 |
| popey | (it's a deb installed locally by you, not from the repo, so I can't --reinstall, I have to remove/reinstall) | 09:46 |
| popey | i can ssh in | 09:46 |
| popey | (as can you) :D | 09:46 |
| zyga-solus | oh, right | 09:46 |
| * zyga-solus looks | 09:46 | |
| zyga-ubuntu | popey: locked up as in UI is frozen? | 09:47 |
| popey | yeah | 09:47 |
| popey | seems apt has finished removing | 09:48 |
| zyga-ubuntu | feel free to reboot it if that helps | 09:48 |
| popey | doing | 09:48 |
| zyga-ubuntu | it is back now | 09:51 |
| zyga-ubuntu | I'm installing snapd | 09:51 |
| popey | kk | 09:52 |
| mup | PR snapd#4030 opened: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4030> | 09:53 |
| zyga-ubuntu | popey: that machine is not affected :/ | 09:55 |
| popey | I can install 16.04 on it | 09:55 |
| zyga-ubuntu | mvo: you don't happen to have 16.04 on your desktop? | 09:55 |
| zyga-ubuntu | popey: if that's not a burden, please | 09:56 |
| popey | I'll make it dual boot | 09:56 |
| zyga-ubuntu | popey: I think I should find myself an nvidia box | 09:56 |
| zyga-ubuntu | thanks | 09:56 |
| popey | also, thanks for introducing me to ubuntu-drivers --autoinstall :D | 09:56 |
| popey | I had never seen that before! | 09:56 |
| zyga-ubuntu | situation demands creative solutions :) | 09:58 |
| mvo | zyga-ubuntu: I have access to a 16.04 machine but its not my main machine, why? | 09:59 |
| mvo | zyga-ubuntu: or do you need a 16.04 nvivida machine? that is more complicated, I can do a live-usb stick run on that | 10:00 |
| zyga-ubuntu | mvo: popey is preparing dual-boot on a machine with nvidia GPU | 10:02 |
| popey | installing now... | 10:02 |
| zyga-ubuntu | mvo: and I'll look at what udev is doing to and what may make it fail this way | 10:02 |
| mvo | ok | 10:03 |
| mvo | zyga-ubuntu: let me know if I should dig out a livecd | 10:03 |
| zyga-ubuntu | thank you | 10:05 |
| ogra_ | zyga-ubuntu, oooh https://forum.snapcraft.io/t/call-for-testing-gimp/1281 see third last post | 10:17 |
| ogra_ | another one | 10:17 |
| zyga-ubuntu | ogra_: I suspect it's something we, ahem, did for nvidia | 10:25 |
| zyga-ubuntu | digging | 10:25 |
| mvo | zyga-ubuntu: oh, do you have a theory about this failure? | 10:26 |
| ogra_ | up to now it seems all users hitting it also use nvidia | 10:27 |
| zyga-ubuntu | mvo: no but it is clearly related | 10:27 |
| zyga-ubuntu | mvo: curiosuly it only affects 16.04 | 10:27 |
| zyga-ubuntu | mvo: or at least I hope | 10:27 |
| ackk | how can I have a field in the snapcraft schema that's either a string or an integer? | 10:27 |
| zyga-ubuntu | mvo: if it does affect 17.04 and popey's machine was just unaffected (for whatever reason) we're in deeper waste water | 10:28 |
| zyga-ubuntu | ackk: snapcraft schema is just json schema | 10:28 |
| mvo | zyga-ubuntu: fwiw, I don't see any of this on my 17.10 | 10:29 |
| ackk | there doesn't seem to be similar cases at the moment | 10:29 |
| mvo | zyga-ubuntu: I can try on a 16.04 now, installing gimp, right? | 10:29 |
| zyga-ubuntu | ackk: http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.25 | 10:29 |
| zyga-ubuntu | ackk: type: [int, string] | 10:29 |
| zyga-ubuntu | (sorry, integer) | 10:29 |
| ackk | oh | 10:29 |
| mvo | zyga-ubuntu: also - hiri appears to be not working still for the reporter in the forum :/ | 10:29 |
| ackk | I thought it could be just one of them | 10:29 |
| ackk | thanks zyga-ubuntu | 10:29 |
| zyga-ubuntu | ackk: you can use richer syntax if you want to put different constraints on both | 10:29 |
| zyga-ubuntu | ackk: e.g. specific range of ints or specific set of strings | 10:30 |
| ackk | zyga-ubuntu, that's cool | 10:30 |
| zyga-ubuntu | mvo: so my theory is some of the nvidia changes coupled to specific behavior in udev cause us not to see what udev expects to see (perhaps some data in /run) and then things go belly up | 10:31 |
| zyga-ubuntu | mvo: my hope is that with popey's machine and gdb I can see what's the culprit easily | 10:31 |
| ackk | zyga-ubuntu, do you have a link on how to do that (type-based constraints)? | 10:31 |
| zyga-ubuntu | mvo: I'm also scavenging for HDDs to install 16.04 on an old laptop I have | 10:31 |
| zyga-ubuntu | ackk: no, sorry, I think they removed that from the schema, let me look for one more moment | 10:34 |
| mup | PR snapcraft#1382 closed: rust plugin: make libc configurable <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382> | 10:34 |
| ackk | zyga-ubuntu, ah, I think I found it https://cswr.github.io/JsonSchema/spec/multiple_types/ | 10:34 |
| mvo | zyga-ubuntu: does the udev_enumerate error happens only on nvidia? did ogra_ have a nvidia on the machine he hit it with? | 10:35 |
| ogra_ | mvo, yes i did | 10:36 |
| zyga-ubuntu | ackk: ah, I'm wrong | 10:36 |
| zyga-ubuntu | ackk: http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.28 | 10:36 |
| zyga-ubuntu | ackk: you can use oneOf to define schema that applies | 10:36 |
| zyga-ubuntu | ackk: so oneOf: [{type: "integer"}, {type: "string"}] | 10:37 |
| zyga-ubuntu | ackk: and then you can put extra constraints in each | 10:37 |
| zyga-ubuntu | mvo: it looks like it | 10:37 |
| mup | PR snapcraft#1512 closed: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512> | 10:37 |
| zyga-ubuntu | mvo: unfortunately following udev source dry is a bit hard as it's doing a whole lot of things | 10:37 |
| zyga-ubuntu | not that many things can fail though so I think we can find it | 10:38 |
| mvo | zyga-ubuntu: ok, I create a 16.04 disk now too, just in case, looks really important | 10:39 |
| popey | zyga-ubuntu: sorry for the delay, seems you can't just install 16.04 on a system which already has 17.10 - ext4 extended attributes cause 16.04 to freak and shit the bed | 10:40 |
| zyga-ubuntu | popey: you can disable them | 10:40 |
| popey | i booted to 17.10 to resize the partition | 10:40 |
| zyga-ubuntu | popey: boot to 17.04 and use tune2fs | 10:40 |
| popey | re-rebooting to 16.04 to install | 10:40 |
| zyga-ubuntu | popey: tune2fs -O^metadata_csum | 10:41 |
| zyga-ubuntu | that will fix it | 10:41 |
| zyga-ubuntu | (been there done that) | 10:41 |
| popey | hah | 10:41 |
| popey | thanks | 10:41 |
| zyga-ubuntu | popey, mvo: there's a logging feature | 10:41 |
| zyga-ubuntu | we can enable it | 10:41 |
| zyga-ubuntu | just one sec | 10:41 |
| ogra_ | geez, really ?!?! we do incompatible filesystem changes between two releases ? | 10:42 |
| ogra_ | thats insane | 10:42 |
| zyga-ubuntu | popey: on your affected machine | 10:42 |
| popey | maybe i have an old 16.04 iso on my stick | 10:43 |
| zyga-ubuntu | popey: export SYSTEMD_LOG_LEVEL=verbose_debug | 10:43 |
| zyga-ubuntu | popey: for now that's it, try running it again | 10:44 |
| popey | where will i expect more logging to appear? | 10:44 |
| zyga-ubuntu | no idea yet | 10:45 |
| zyga-ubuntu | that part of the code is generated on compile time | 10:45 |
| zyga-ubuntu | I'm trying to see | 10:45 |
| zyga-ubuntu | there's SYSTEMD_LOG_TARGET= | 10:45 |
| zyga-ubuntu | but not sure what the values are :/ | 10:45 |
| zyga-ubuntu | popey: try also setting SYSTEMD_LOG_TARGET=console | 10:48 |
| zyga-ubuntu | popey: (you can try journal or syslog as well) | 10:48 |
| zyga-ubuntu | popey: then run snap that fails to start | 10:48 |
| popey | nothing in journalctl if i set those vars and run a snap | 10:49 |
| zyga-ubuntu | and no denials either? | 10:50 |
| popey | correct | 10:51 |
| popey | (16.04 installing finally) | 10:51 |
| ogra_ | zyga-ubuntu, you could try "udevadm monitor" | 10:56 |
| ogra_ | popey, ^^ | 10:57 |
| popey | no output | 10:58 |
| ogra_ | :( | 10:58 |
| ogra_ | well, thats exactly what i observed too ... no log output anywhere ... neither dmesg, nor journald nor syslog | 10:58 |
| zyga-ubuntu | I'll patch snap-confine to enable udev logging | 10:59 |
| zyga-ubuntu | or not, this is not doing anything anymore | 11:02 |
| * zyga-ubuntu looks deeper | 11:02 | |
| zyga-ubuntu | popey: can it be reproduced on your other machine? | 11:02 |
| popey | other is 17.10/intel, no | 11:02 |
| popey | ooh, i have another other other machine which is 16.04 intel | 11:03 |
| * popey tries on that | 11:03 | |
| zyga-ubuntu | popey: and on the one with 16.04 and nvidia? | 11:04 |
| zyga-ubuntu | does it fail there? | 11:04 |
| popey | stil installing on that one | 11:05 |
| popey | fails on my main laptop, which is 16.04 nvidia of course | 11:05 |
| zyga-ubuntu | ah, ok | 11:05 |
| popey | tested on intel 16.04 laptop, don't see the issue here | 11:16 |
| popey | (however, ogra_ said it was 'solved' with a reboot, so dunno if I just havent triggered the issue on this laptop yet) | 11:17 |
| ogra_ | yeah, i cant reproduce it since that reboot | 11:18 |
| popey | huh, this clean 16.04 install is offering me an upgrade to 17.04 | 11:18 |
| popey | i thought we only did lts to lts offers on lts releases | 11:18 |
| ogra_ | is that 16.04 or 16.04.x ? | 11:19 |
| ogra_ | might be the original 16.04 allows that | 11:19 |
| popey | not sure, lsb_release shows 16.04.3 now | 11:20 |
| popey | but I'm mid dist-upgrade which probably changed that | 11:20 |
| ogra_ | hm, weird | 11:20 |
| ogra_ | better ask in #ubuntu-release if thats desired | 11:20 |
| popey | ya | 11:20 |
| * zyga-ubuntu has some annoying back pain :/ | 11:28 | |
| zyga-ubuntu | popey: can you reproduce the issue on your machine? | 11:28 |
| popey | back pain!? Yes, I have that too! Shall i file a bug? | 11:29 |
| * Chipaca goes for a run | 11:32 | |
| ogra_ | yes, please, i'll happily confirm | 11:32 |
| ogra_ | (or rather un-happily ....) | 11:33 |
| ogra_ | heh | 11:35 |
| ogra_ | seems https://launchpad.net/spine actually exists | 11:35 |
| kalikiana | :-D | 11:37 |
| kalikiana | nice one | 11:37 |
| zyga-ubuntu | popey: any luck | 11:44 |
| zyga-ubuntu | ? | 11:44 |
| popey | just dist upgrade finished and its rebooting | 11:45 |
| popey | you should have ssh access, but not tested snaps yet | 11:45 |
| popey | took ages to dist-upgrade 700+ packages | 11:45 |
| popey | zyga-ubuntu: just installing a test snap on it now | 11:47 |
| ogra_ | popey, makes you really want an ubuntu core based desktop eh ? :) | 11:48 |
| popey | hah | 11:48 |
| zyga-ubuntu | popey: I still get connection refused | 11:48 |
| popey | huh | 11:48 |
| popey | oh, not installed ssh server | 11:48 |
| popey | one mo | 11:48 |
| popey | it doesnt have the nvidia driver yet | 11:49 |
| popey | but you should be able to get in now? | 11:49 |
| zyga-ubuntu | logged in, thanks | 11:50 |
| popey | its set to auto login, and boot to 16.04 so feel free to reboot or whatever | 11:50 |
| zyga-ubuntu | thank you | 11:54 |
| zyga-ubuntu | popey: I launched the giraffe, I'm afraid it works | 11:55 |
| popey | you're not on binary nvidia driver tho | 11:56 |
| zyga-ubuntu | popey: aah | 11:56 |
| zyga-ubuntu | thanks! | 11:56 |
| zyga-ubuntu | installing now | 11:57 |
| zyga-ubuntu | but this is excellent | 11:57 |
| zyga-ubuntu | if it fails after installation we'll have clear evidence that the relationship is real | 11:57 |
| popey | good point | 11:57 |
| zyga-ubuntu | rebooting | 12:00 |
| popey | zyga-ubuntu: desktop is up | 12:02 |
| zyga-ubuntu | reproduced! | 12:02 |
| zyga-ubuntu | ok | 12:02 |
| zyga-ubuntu | thank you for setting this up!!! | 12:02 |
| popey | np | 12:02 |
| jdstrand | zyga-ubuntu: ohh | 12:05 |
| jdstrand | zyga-ubuntu: artful without nvidia: /snap/bin/test-policy-app.network-control: udev_enumerate_scan failed | 12:06 |
| zyga-ubuntu | jdstrand: that's just wonky | 12:07 |
| zyga-ubuntu | jdstrand: I'll focus on 16.04 now | 12:07 |
| zyga-ubuntu | jdstrand: but ... wonky! | 12:07 |
| ogra_ | zyga-ubuntu, you should probably add the word "nvidia" somewhere to your post ... nothing in the thread talks about it yet | 12:07 |
| ogra_ | "the binary driver" could be anything :) | 12:08 |
| zyga-ubuntu | +1 | 12:08 |
| zyga-ubuntu | done | 12:08 |
| jdstrand | zyga-ubuntu: zyga-ubuntu it's repeatable. I suspect something wrong with that interface. gimme a sec | 12:09 |
| ogra_ | thx | 12:09 |
| zyga-ubuntu | jdstrand: network-control? I see this on opengl and ohmygiraffe | 12:09 |
| zyga-ubuntu | jdstrand: I'm on artful and I never reproduced it here FYI | 12:10 |
| mcphail | My giraffe is dead on 16.04 o/ | 12:11 |
| popey | mcphail: do you get the udev error message on the command line? | 12:11 |
| zyga-ubuntu | we're working on reviving it | 12:11 |
| mcphail | Yep. Using nvidia drivers | 12:11 |
| mcphail | zyga-ubuntu: :) | 12:12 |
| zyga-ubuntu | jdstrand: side note, terrible C apis without any error information | 12:13 |
| zyga-ubuntu | "I failed but beats me why" | 12:13 |
| jdstrand | yes | 12:13 |
| jdstrand | zyga-ubuntu: seriously | 12:13 |
| jdstrand | network-control is messed up | 12:14 |
| jdstrand | zyga-ubuntu: udev doesn't like this line: KERNEL=="tun[0-9]*", TAG+="snap_test-policy-app_network-control" | 12:15 |
| zyga-ubuntu | jdstrand: interesting | 12:16 |
| zyga-ubuntu | jdstrand: I don't use that interface here but opengl has SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="snap_ohmygiraffe_ohmygiraffe" | 12:16 |
| zyga-ubuntu | if it's the regexp it looks just the same | 12:17 |
| zyga-ubuntu | jdstrand: how do you know it doesn't like it? | 12:17 |
| jdstrand | there's a lot of regexes that look fine. opengl works fine here | 12:17 |
| ogra_ | https://github.com/snapcore/snapd/pull/4018/files | 12:17 |
| mup | PR #4018: interfaces: fix udev rules for tun <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4018> | 12:17 |
| ogra_ | there was a recent change ^^ | 12:17 |
| jdstrand | zyga-ubuntu: because I commented it out of /etc/udev/rules.d/snap.test-policy-app then did: sudo udevadm trigger && for i in /snap/bin/test-policy-app.* ; do echo -n "$i: " && $i -c "echo ok" ; done 2>&1 | grep -v ok | 12:18 |
| ogra_ | (not sure it is realted, but it changed the line right befor the tun[0-9] one) | 12:18 |
| zyga-ubuntu | aha | 12:18 |
| * zyga-ubuntu returns to gdb | 12:19 | |
| jdstrand | gimp does not have network-control | 12:19 |
| jdstrand | ogra_: you are seeing this today? | 12:20 |
| ogra_ | no, i have never seen it again | 12:20 |
| jdstrand | popey: you are seeing this now? | 12:20 |
| ogra_ | (but i also did not reboot my desktop since i reported it) | 12:21 |
| popey | "this"? | 12:21 |
| * jdstrand is going to have to change rooms soon | 12:21 | |
| jdstrand | popey: udec scan issue | 12:21 |
| jdstrand | udev | 12:21 |
| ogra_ | jdstrand, popey can reliably reproduce it and zyga-ubuntu is remotely logged in to the machine | 12:21 |
| popey | i am unable to run some snaps on my 16.04 system, yes. | 12:21 |
| jdstrand | ok | 12:21 |
| jdstrand | popey: ok, nm I'll work with zyga-ubuntu | 12:21 |
| popey | kk | 12:21 |
| popey | he has access to an nvidia 16.04 desktop on my desk here | 12:22 |
| jdstrand | zyga-ubuntu: do you have KERNEL=="nvidia*", TAG+="..." in your /etc/udev/rules.d/* file? | 12:22 |
| zyga-ubuntu | stepping over now | 12:23 |
| zyga-ubuntu | yes | 12:23 |
| zyga-ubuntu | this is 2.28.1 still | 12:23 |
| zyga-ubuntu | SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="snap_ohmygiraffe_ohmygiraffe" | 12:23 |
| zyga-ubuntu | KERNEL=="nvidia*", TAG+="snap_ohmygiraffe_ohmygiraffe" | 12:23 |
| zyga-ubuntu | KERNEL=="vchiq", TAG+="snap_ohmygiraffe_ohmygiraffe" | 12:23 |
| jdstrand | zyga-ubuntu: if you comment out the nvidia one, does it stop? | 12:24 |
| jdstrand | ie, does the scan work? | 12:24 |
| jdstrand | zyga-ubuntu: you need to udevadm trigger | 12:25 |
| jdstrand | zyga-ubuntu: changing rooms. brb | 12:25 |
| jdstrand | zyga-ubuntu: I'm back. did it work? all you need to do is 'snap run --shell ohmygiraffe' I think | 12:31 |
| jdstrand | eg, edit /etc/udev/rules.d/70-snap.ohmygiraffe.rules, sudo oudevadm trigger ; snap run --shell ohmygiraffe | 12:33 |
| zyga-ubuntu | jdstrand: I didn't try yet, I'm in gdb going down to the place where it fails | 12:37 |
| zyga-ubuntu | I think I found it | 12:38 |
| jdstrand | zyga-ubuntu: well, the point is with nvidia that this is more fallout from not including the my nvidia fix in 2.28. ie, nvidia should be fixed with yesterdays hotfix | 12:39 |
| zyga-ubuntu | it fails in enumerator_scan_devices_tags | 12:39 |
| zyga-ubuntu | specifically this call inside: r = enumerator_scan_devices_tag(enumerator, tag); | 12:39 |
| jdstrand | that doesn't surprise me. nvidia* isn't a thing (the sysfs issue) | 12:40 |
| zyga-ubuntu | jdstrand: checking without the nvidia tag now | 12:40 |
| zyga-ubuntu | jdstrand: it still fails | 12:41 |
| zyga-ubuntu | zyga@zyga-P55A-UD3:~/systemd-229/src$ ls /run/udev/tags/snap_ohmygiraffe_ohmygiraffe -l | 12:41 |
| zyga-ubuntu | total 0 | 12:41 |
| zyga-ubuntu | -r--r--r-- 1 root root 0 Oct 12 13:01 +drivers:nvidia | 12:41 |
| zyga-ubuntu | -r--r--r-- 1 root root 0 Oct 12 13:01 +module:nvidia | 12:41 |
| zyga-ubuntu | -r--r--r-- 1 root root 0 Oct 12 13:01 +module:nvidia_uvm | 12:41 |
| zyga-ubuntu | -r--r--r-- 1 root root 0 Oct 12 13:41 c226:0 | 12:41 |
| zyga-ubuntu | I think this is not right | 12:41 |
| jdstrand | zyga-ubuntu: dude, it isn't :) | 12:42 |
| jdstrand | zyga-ubuntu: udev tagging requires things to be exposed in sysfs | 12:42 |
| zyga-ubuntu | I understand, I mean that I removed that line and re-triggered udev | 12:43 |
| jdstrand | zyga-ubuntu: nvidia is not GPL so it isn't in there. this is the whole reason I did the PR in snap-confine for nvidia | 12:43 |
| jdstrand | ok | 12:43 |
| jdstrand | so, did the scan fail even though the line was not in there? | 12:43 |
| zyga-ubuntu | yes | 12:43 |
| zyga-ubuntu | and after the scan I expected those files in /run/udev/tags/../ to go away | 12:44 |
| jdstrand | hmm | 12:44 |
| zyga-ubuntu | after removing them it works okay (the tags) | 12:44 |
| jdstrand | zyga-ubuntu: I suspect that the subsystem drm one above might be the problem then | 12:45 |
| kalikiana | brb, coffee break | 12:45 |
| jdstrand | zyga-ubuntu: oh | 12:45 |
| zyga-ubuntu | aha, interesting | 12:45 |
| jdstrand | actually, that might be ok | 12:45 |
| zyga-ubuntu | note, they were not added back after running trigger again ( | 12:45 |
| zyga-ubuntu | (after removing them) | 12:45 |
| jdstrand | zyga-ubuntu: so, now that the tags are removed, with the nvidia one commented out and udevadm trigger done, does it work? | 12:46 |
| jdstrand | ok good | 12:46 |
| zyga-ubuntu | yes | 12:46 |
| jdstrand | so *yes*, the pr yesterday fixes it at least after a reboot | 12:46 |
| zyga-ubuntu | well | 12:46 |
| zyga-ubuntu | ... | 12:46 |
| zyga-ubuntu | I spoke too soon | 12:46 |
| zyga-ubuntu | I removed the tags | 12:46 |
| zyga-ubuntu | and I was running /bin/true | 12:46 |
| zyga-ubuntu | real app fails | 12:46 |
| zyga-ubuntu | :// | 12:47 |
| jdstrand | does the real app have the new tags? | 12:47 |
| zyga-ubuntu | jdstrand: I was running snap-confine manually (instead of the real app) | 12:47 |
| zyga-ubuntu | oddly enough after re-adding that nvidia tag to udev rules I don't get the files in /run/udev/tags/.../ back | 12:48 |
| zyga-ubuntu | is udevadm trigger really the right thing? | 12:48 |
| jdstrand | ok. can we back up. can you removed the tags, make sure that nvidia is commented out of the /etc/udev/rules.d for that app, run udevadm trigger, then snap run --shellapp | 12:48 |
| jdstrand | s/app/ app/ | 12:49 |
| zyga-ubuntu | I'll run what we really do for udev | 12:49 |
| jdstrand | there might be bugs in udev trying to tag nvidia since it isn't sysfs compatible | 12:49 |
| jdstrand | I suspect it is partially doing things | 12:50 |
| jdstrand | so we need a clean state | 12:50 |
| zyga-ubuntu | one se | 12:51 |
| zyga-ubuntu | c | 12:51 |
| zyga-ubuntu | jdstrand: ok, with the nvidia udev rule commented out, I ran udevadm control --reload-rules, followed by udevadm trigger | 12:53 |
| zyga-ubuntu | I don't see the nvidia device tags | 12:53 |
| zyga-ubuntu | trying to run the app | 12:53 |
| zyga-ubuntu | I cannot create GL context, it fails | 12:53 |
| jdstrand | that's different from the scan issue | 12:53 |
| zyga-ubuntu | let me reboot that machine | 12:53 |
| zyga-ubuntu | yes | 12:53 |
| jdstrand | that is because snap-confine doesn't add the nvidia devices to the cgroup | 12:53 |
| zyga-ubuntu | I suspect now it doesn't crash from udev things | 12:53 |
| zyga-ubuntu | aahh | 12:53 |
| zyga-ubuntu | right | 12:53 |
| zyga-ubuntu | that makes sense | 12:54 |
| jdstrand | ie, you aren't running s snapd with yesterday's fix | 12:54 |
| zyga-ubuntu | let me try with updated snap-confine from the branch | 12:54 |
| zyga-ubuntu | so what does it tell us? all is fine and we need to roll out .4? | 12:54 |
| zyga-ubuntu | (fingers crossed) | 12:54 |
| jdstrand | zyga-ubuntu: all you need is --beta | 12:54 |
| zyga-ubuntu | ok | 12:54 |
| jdstrand | zyga-ubuntu: nvidia is fine with .4 | 12:54 |
| zyga-ubuntu | I'll refresh to beta | 12:54 |
| jdstrand | Imean, feel free to test again | 12:54 |
| jdstrand | but, I found a problem with network-control. I'm testing that againmyself | 12:55 |
| zyga-ubuntu | aha | 12:55 |
| zyga-ubuntu | jdstrand: it works now | 12:56 |
| zyga-ubuntu | popey: thank you for setting this up and allowing us to test this | 12:56 |
| jdstrand | ok, good | 12:56 |
| zyga-ubuntu | jdstrand: I'll go to the standup now | 12:57 |
| zyga-ubuntu | jdstrand: let us know if we need a .5 | 12:57 |
| zyga-ubuntu | (I mean, mvo will do a .5 anyway) | 12:57 |
| zyga-ubuntu | for another issue | 12:57 |
| zyga-ubuntu | but we'd like to know if we can pull in a fix from you | 12:57 |
| mvo | zyga-ubuntu: yeah, we need one anyway, we just need to know if we need one more fix in it or not | 12:57 |
| zyga-ubuntu | right | 12:58 |
| zyga-ubuntu | mvo: tests unhappy about squasfuse | 12:59 |
| zyga-ubuntu | because of silly stuff like | 12:59 |
| zyga-ubuntu | imported/squashfuse/m4/pkg.m4:89:22: "occurence" is a misspelling of "occurrence" | 12:59 |
| zyga-ubuntu | /o\ | 12:59 |
| ackk | mhm, shellcheck errors in snapd master for me | 13:00 |
| ackk | zyga-ubuntu, what shellcheck version should I be using? | 13:00 |
| zyga-ubuntu | ackk: post 16.04 | 13:01 |
| zyga-ubuntu | or remove it | 13:01 |
| zyga-ubuntu | (shellcheck) | 13:01 |
| zyga-ubuntu | and re-configure | 13:01 |
| ackk | zyga-ubuntu, fails on artful | 13:01 |
| ackk | with 0.4.6 | 13:02 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| mup | PR snapcraft#1608 closed: tests: fix the duplicate plainbox test scenarios <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1608> | 13:04 |
| mup | PR snapcraft#1611 closed: plainbox-provider plugin: init PROVIDERPATH <bug> <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1611> | 13:04 |
| zyga-ubuntu | ackk: what's the failure? | 13:06 |
| ackk | zyga-ubuntu, http://paste.ubuntu.com/25726179/ | 13:07 |
| ackk | they seem legit | 13:07 |
| mup | PR snapcraft#1599 closed: Fixed StoreReleaseError format for BAD REQUEST error <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1599> | 13:07 |
| c-lobrano | \0/ | 13:08 |
| zyga-ubuntu | ah, they are really legit | 13:08 |
| zyga-ubuntu | feel free to fix those if you want | 13:08 |
| mup | PR snapcraft#1601 closed: snapcraft.yaml: don't re-use build dir <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1601> | 13:10 |
| mup | PR snapd#4031 opened: interfaces/network-control: remove incorrect rule for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031> | 13:13 |
| jdstrand | mvo, zyga-ubuntu: https://github.com/snapcore/snapd/pull/4031 should fix the udev scan error with netwrk-control. I'm a bit puzzled why spread tests didn't reveal this, since we are testing network-control connections. perhaps it is becahse the tun module isn't loaded in spread? unfortunately, I'm very booked today, so I cannot deeply test that pr or investigate why spread didn't catch it | 13:15 |
| mup | PR #4031: interfaces/network-control: remove incorrect rule for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031> | 13:15 |
| ackk | zyga-ubuntu, and now I get http://paste.ubuntu.com/25726221/ | 13:16 |
| ackk | which seems somewhat worse :) | 13:16 |
| kalikiana | re | 13:16 |
| ackk | wait, why is GOPATH a list? | 13:17 |
| ackk | oh, TIL it's not a single dir | 13:18 |
| ogra_ | jdstrand, hmm,. wont that break tun devices (given there is allways numbering on the actual device) | 13:19 |
| jdstrand | ogra_: no. tun[0-9]* are virtual devices like other network devices. they don't show up in /dev, so don't need to be added to the device cgroup, so don't need to be tagged | 13:21 |
| ogra_ | jdstrand, then shoulldnt we do the same for tap ? o do they actually ceate dev nodes ? | 13:21 |
| jdstrand | maybe | 13:22 |
| jdstrand | let me see how they work (I verified tun0 as virtual) | 13:22 |
| ogra_ | it just looked inconsistent to me when checking your PR | 13:22 |
| jdstrand | A TUN/TAP driver does provide a virtual network interface ... | 13:24 |
| jdstrand | yes, I'll remove that. good catch | 13:24 |
| zyga-ubuntu | jdstrand: question: why does it cause havok when we have a rule like that? | 13:25 |
| zyga-ubuntu | jdstrand: I would have assumed udev will just find nothing to do | 13:27 |
| mvo | zyga-ubuntu: re /usr/lib/nvidia : no such file or directory | 13:33 |
| ackk | zyga-ubuntu, https://github.com/snapcore/snapd/pull/4032 fwiw | 13:34 |
| mup | PR #4032: fix shell errors from shellcheck <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4032> | 13:34 |
| mup | PR snapd#4032 opened: fix shell errors from shellcheck <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4032> | 13:34 |
| ogra_ | mvo, it is usuallly versioned | 13:34 |
| ogra_ | ah, no, i'm lying | 13:35 |
| ogra_ | ls -d /usr/lib/nvidia* | 13:35 |
| ogra_ | /usr/lib/nvidia /usr/lib/nvidia-361 /usr/lib/nvidia-367 /usr/lib/nvidia-375 /usr/lib/nvidia-375-prime | 13:35 |
| zyga-ubuntu | mvo: sorry, one of those that ogra_ mentioned | 13:37 |
| zyga-ubuntu | ackk: thank you! | 13:37 |
| jdstrand | zyga-ubuntu: re question> seems like a bug. no idea | 13:38 |
| zyga-ubuntu | jdstrand: thank you for confirming that, I feel the same | 13:39 |
| zyga-ubuntu | jdstrand: I had a, perhaps, related case while exploring systemd network config | 13:39 |
| zyga-ubuntu | jdstrand: when I input wrong matching filter (I had a typo) | 13:39 |
| zyga-ubuntu | jdstrand: the match would target *all* devices | 13:39 |
| zyga-ubuntu | jdstrand: and rename all network interfaces to the same name in some random order, ending terribly | 13:39 |
| zyga-ubuntu | jdstrand: could it be that udev sees something it doesn't like, ignores that condition and then blats the assignments to everything it knows about? | 13:40 |
| ogra_ | slangasek, did you see my llast comment on bug 1707888 (i think there is still one subiquity issue there) | 13:40 |
| mup | Bug #1707888: ethernet defaults for unconnected device are wrong <subiquity:New> <https://launchpad.net/bugs/1707888> | 13:40 |
| slangasek | ogra_: so your argument is that we should have a different default netplan config for console-conf? | 13:50 |
| slangasek | I'm not convinced this is what's expected for ubuntu-core in generall | 13:50 |
| slangasek | I understand that for certain devices we might want to be able to specify which interfaces are dhcp by default vs not | 13:51 |
| slangasek | so I'm fine to un-dupe | 13:51 |
| ackk | zyga-ubuntu, np, thanks for looking at the PR | 13:51 |
| ogra_ | slangasek, well, my argument is that a nic config i never touched should not leave me with some unwanted configuration for that nic | 13:51 |
| slangasek | ogra_: "that you've never touched" - you mean when you acked the screen saying that console-conf sees the device, and will try to do dhcp on it? | 13:52 |
| ogra_ | slangasek, IMHO a first boto of a core device should come up with all NICs off by default and only afte i configured one it should be used | 13:52 |
| slangasek | ogra_: that is not a generally applicable rule. | 13:53 |
| ogra_ | slangasek, well, yes and no ... if i manually configure wlan on a pi3 (which has wlan0 and eth0 ) but never touch anything else, then my ack will still leave me with a full configured eth0 that i did not configure | 13:53 |
| slangasek | I can accept that individual devices might need to specify a different default policy per NIC. I do not agree that this is a sensible default policy for all ubuntu-core devices. | 13:53 |
| ogra_ | what is the use for it ? | 13:54 |
| slangasek | you know console-conf is an optional setup step? | 13:54 |
| slangasek | not all devices are going to have console-conf as the first boot experience. some have to be non-interactive. | 13:55 |
| ogra_ | you *need* to either go through subiquity, cloud-init or apply some assertion to actually get a poper network config | 13:55 |
| slangasek | non-interactive + no network by default == expensive doorstop | 13:55 |
| ogra_ | withooout either of these you should noot suddenly have the device online | 13:55 |
| slangasek | I've never heard assertions mentioned in the context of network config, are there docs on this? | 13:55 |
| ogra_ | welll, you can somehoow suplly a netplan yaml ... not sure how that works though | 13:56 |
| ogra_ | in any case what does the DHCP by default gain you apart fom insecurity if you dont have a poperlly configued rest of the system ? | 13:56 |
| slangasek | it gains you... the ability to talk to the store and actually come up as a snappy system | 13:57 |
| ogra_ | (and 2min hangs oon boot if you actualy do not configure eth0) | 13:57 |
| ogra_ | also note that eth0 *only* works because we foce the new naming schemes off via the kernel cmdlline | 13:57 |
| jdstrand | mvo, zyga-ubuntu: I want to be very clear that https://github.com/snapcore/snapd/pull/4031 needs to be in 2.28.5 | 13:58 |
| mup | PR #4031: interfaces/network-control: remove incorrect rules for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031> | 13:58 |
| ogra_ | (by setting net.ifnames=0 ... it wont work at all when you drop that) | 13:58 |
| zyga-ubuntu | jdstrand: noted | 13:58 |
| mvo | jdstrand: I targeted it for 2.28.5 | 13:58 |
| * jdstrand is worried about net infrastructure snaps | 13:58 | |
| ogra_ | (you just end up with a brooken hardcoded eth0 device in netplan.yaml) | 13:58 |
| zyga-ubuntu | jdstrand: you have a unit test failure now | 14:00 |
| ogra_ | slangasek, to talk to the store ? without having the device configured ? | 14:00 |
| ogra_ | (you want an account and keys and all ...) | 14:01 |
| mvo | zyga-ubuntu: any ideas how to further debug the hiri&nvidia-384 issue? if I strace it I see a mmap() before it dies | 14:01 |
| ogra_ | (which you get via the assertion or manual config) | 14:01 |
| zyga-ubuntu | mvo: strace the outside of snap copy | 14:01 |
| zyga-ubuntu | mvo: and strace the one inside | 14:01 |
| zyga-ubuntu | mvo: it's super tedious though :/ | 14:01 |
| zyga-ubuntu | mvo: does devmode help? | 14:03 |
| zyga-ubuntu | mvo: and one more idea | 14:03 |
| zyga-ubuntu | mvo: nsenter into the mount namespace | 14:03 |
| zyga-ubuntu | mvo: and see if *that* works | 14:03 |
| zyga-ubuntu | mvo: then you have no seccomp, no apparmor, no cgroups | 14:03 |
| zyga-ubuntu | mvo: is it our layout or is it something else | 14:04 |
| mvo | zyga-ubuntu: devmode helps with the debugging but still fails | 14:04 |
| mvo | zyga-ubuntu: I can `snap run --shell hiri`, thats fine, but when I try to run it boom | 14:04 |
| zyga-ubuntu | mvo: no, not like that | 14:05 |
| zyga-ubuntu | mvo: just nsenter | 14:05 |
| zyga-ubuntu | mvo: I'll see if 16.04 + hiri work on my system, I found a HDD I can swap inside | 14:06 |
| mvo | zyga-ubuntu: just nsenter -m... has the same problem | 14:07 |
| zyga-ubuntu | mvo: that's good to know | 14:07 |
| mvo | zyga-ubuntu: crash in libnvidia-glcore.so. | 14:08 |
| zyga-ubuntu | mvo: so it's not our confinement | 14:08 |
| zyga-ubuntu | mvo: just our laoyut | 14:08 |
| zyga-ubuntu | *layout | 14:08 |
| zyga-ubuntu | mvo: hmmmm | 14:08 |
| zyga-ubuntu | mvo: a view of /proc/pid/maps inside and out could help | 14:10 |
| zyga-ubuntu | mvo: run hiri on the outside and pastebin a copy | 14:10 |
| === ikey|zzz is now known as ikey | ||
| zyga-ubuntu | ikey: hey | 14:17 |
| zyga-ubuntu | ikey: I tried to add indent to solus a few days ago | 14:17 |
| zyga-ubuntu | ikey: but I failed miserably | 14:17 |
| mvo | zyga-ubuntu: actually I think it is the confinement in some way, I managed to run it from inside the namespace now | 14:18 |
| zyga-ubuntu | mvo: can you look at /sys/fs/crgroup/devices/.../devices.list? | 14:19 |
| mvo | zyga-ubuntu: sure: "a *:* rwm" | 14:20 |
| zyga-ubuntu | that's "all devices" | 14:20 |
| zyga-ubuntu | (AFAIK) | 14:20 |
| zyga-ubuntu | hmm, that's odd, I would expect a concrete list | 14:20 |
| zyga-ubuntu | maybe this snap is not using opengl? | 14:21 |
| zyga-ubuntu | (as the interface) | 14:21 |
| mvo | zyga-ubuntu: it is using opengl, I'm in devmode right now for easier debugging | 14:22 |
| jdstrand | zyga-ubuntu (cc mvo): unit test fixed | 14:22 |
| zyga-ubuntu | thanks! | 14:22 |
| mvo | zyga-ubuntu: nsenter, setup the right library path> hiri launches. `snap run hiri` -> not | 14:22 |
| mvo | thanks jdstrand | 14:22 |
| zyga-ubuntu | mvo: may I ask what did you tweak to make it work inside the namespace? | 14:23 |
| mvo | zyga-ubuntu: I just setup the LD_LIBRARY_PATH | 14:24 |
| mvo | zyga-ubuntu: I think that was all | 14:24 |
| mvo | zyga-ubuntu: I will try again | 14:24 |
| zyga-ubuntu | mvo: did you get any seccomp kill? | 14:24 |
| mvo | zyga-ubuntu: I think not | 14:24 |
| zyga-ubuntu | mvo: those are not DENIED (the message is different) | 14:24 |
| mvo | I check, I just got a machine crash | 14:24 |
| zyga-ubuntu | mvo: so you made it work inside nsentere'd namespace with some LD_LIBRARY_PATH tricks | 14:24 |
| zyga-ubuntu | but not inside the devmode confinement, right? | 14:25 |
| mup | PR snapcraft#1612 opened: cross compile: enable cross compilation of i386 kernel on x86-64 hosts <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1612> | 14:29 |
| kalikiana | sergiusens: wrt https://github.com/snapcore/snapcraft/pull/1568 the problem is that x revisions are arbitrary, so installing the same snap on two systems may lead to different filenames - different filenames won't ever be compared with my code... now, after some rubber ducking, I realize, I could try to query the snap in use in the container: except, it'll be ugly, `snap info` can't be parsed nicely, `file -b` sort of works... | 14:30 |
| kalikiana | pondering what to do here | 14:30 |
| mup | PR snapcraft#1568: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568> | 14:30 |
| mvo | zyga-ubuntu: correct | 14:30 |
| zyga-ubuntu | mvo: you could disable apparmor/seccomp/cgroup initialzation and see if that makes it work | 14:31 |
| zyga-ubuntu | mvo: and then re-enable until you find the one that breaks it | 14:31 |
| zyga-ubuntu | once we know which of the backends it is we can look at it more closely | 14:32 |
| mvo | zyga-ubuntu: thanks, thats a good one - its setup_devices_cgroup() | 14:35 |
| kalikiana | sergiusens: I'm thinking to go with `file -b` in all cases, since hypothetically you could also have a revision from the store that's not being used... | 14:36 |
| mvo | zyga-ubuntu: well, or snappy_udev_init() | 14:36 |
| zyga-ubuntu | mvo: ha | 14:37 |
| zyga-ubuntu | mvo: so... | 14:37 |
| zyga-ubuntu | mvo: disable devmode please | 14:37 |
| zyga-ubuntu | mvo: restart the thing and look at devices.list again | 14:37 |
| zyga-ubuntu | mvo: we can add stuff there, one by one, | 14:37 |
| mvo | ok | 14:37 |
| mvo | on it | 14:37 |
| zyga-ubuntu | mvo: and you can start the app (from a snap run --shell session) | 14:37 |
| zyga-ubuntu | mvo: just don't restart the app as it will re-configure the cgroup | 14:38 |
| zyga-ubuntu | mvo: let's start with a list of devices you get, as a baseline | 14:38 |
| zyga-ubuntu | mvo: then let's look at /dev/nv* on the outside and look for missing things | 14:38 |
| * zyga-ubuntu hugs mvo who fights this tirelessly | 14:38 | |
| slangasek | ogra_: 2 minute hang on boot is a separate question, and that is in progress with an extension to the netplan schema | 14:40 |
| itsfemme[m] | wishlist item: setting per snap VPN/tor configs | 14:41 |
| ogra_ | slangasek, what about the hardcoded NIC name ? if we ever drop the net.ifnames=0 it willl be boken anyway | 14:43 |
| ogra_ | *broken | 14:43 |
| ogra_ | it only works today because there is an actual eth0 ... which do dont have anymore once you enable "predictable NIC names" | 14:44 |
| mvo | zyga-ubuntu: ha! | 14:44 |
| mvo | zyga-ubuntu: looks like /dev/nvidia-modset was missing | 14:44 |
| mvo | zyga-ubuntu: and nvidia-uvm has a different major number for me than in hte source. I will push a PR shortly. this was a PITA | 14:45 |
| mvo | zyga-ubuntu: thank you so much for your help | 14:45 |
| zyga-ubuntu | mvo: can you amend the forum post with the numbers of each of those? I'll cross check with the kernel docs and with my machine | 14:46 |
| zyga-ubuntu | mvo: and compare (if you can) to 17.10 machine on same HW) | 14:46 |
| zyga-ubuntu | mvo: last thing I want is a per-kernel-version if statement | 14:47 |
| mvo | zyga-ubuntu: meh, looks like nvidia-uvm gets its major number somewhat dynamically :( | 14:47 |
| zyga-solus | mvo: ok, we can stat it and add a code path that does the right thing | 14:47 |
| slangasek | ogra_: subiquity does not hard code the name eth0, only ubuntu-core does that | 14:49 |
| ogra_ | slangasek, i think netplan does | 14:49 |
| slangasek | no | 14:49 |
| ogra_ | we dont apply a default yaml i think | 14:49 |
| ogra_ | hmm | 14:49 |
| mvo | zyga-solus: yeah, looking at this next | 14:50 |
| mup | PR snapd#4033 opened: snap-confine: add support for handling /dev/nvidia-modeset <Created by mvo5> <https://github.com/snapcore/snapd/pull/4033> | 14:50 |
| ogra_ | ubuntu-core-config (0.6.40+ppa11) xenial; urgency=medium | 14:51 |
| ogra_ | * etc/netplan/00-snapd-config.yaml: | 14:51 |
| ogra_ | - add default network config | 14:51 |
| ogra_ | -- Michael Vogt <michael.vogt@ubuntu.com> Fri, 30 Sep 2016 19:26:34 +0200 | 14:51 |
| ogra_ | slangasek, ok, you are right :) | 14:51 |
| ogra_ | so it is actually self inflicted pain .. but shouldnt subiquity completely overwrite that ? | 14:53 |
| slangasek | ogra_: "overwrite" it how? netplan brings up the network devices however they've been pre-configured, then subiquity (console-conf) gives the user the option to reconfigure... that's it | 14:54 |
| ogra_ | slangasek, well, subiquity calls netplan generate and netplan apply at the end, or doesnt it ? | 14:54 |
| ogra_ | i would expect the generate to actually generate a new config | 14:55 |
| slangasek | well, it does, no? | 14:55 |
| zyga-ubuntu | mvo: reviewed | 14:56 |
| ogra_ | the question is, does it pick up that dhcp setting from the former file or is that something thats a default inside subiquity (for eth0) | 14:56 |
| mvo | zyga-ubuntu: thanks, working on it. funny, was what I wanted to do in a followup anyway :) | 15:01 |
| zyga-ubuntu | mvo: if you stat you can drop the constants | 15:01 |
| zyga-ubuntu | just stat the filename and apply that | 15:01 |
| zyga-ubuntu | it should be tiny and if jdstrand reviews we can get this in quickly | 15:02 |
| mvo | zyga-ubuntu: it is tiny | 15:02 |
| mvo | zyga-ubuntu: is it ok for me to amend the commit? for easier cherry picking? | 15:03 |
| zyga-ubuntu | mvo: yes | 15:04 |
| * zyga-ubuntu always rebases if nobody looks | 15:04 | |
| zyga-ubuntu | mvo: I'm checking kernel tree for 254 | 15:04 |
| zyga-ubuntu | it's not defined as a static number in admin-guide.txt but it might be just stale | 15:04 |
| mvo | zyga-ubuntu: no worries, I use major/minor now everywhere | 15:05 |
| === cachio is now known as cachio_lunch | ||
| Chipaca | anybody have systemd.unit(5) from trusty to hand? | 15:07 |
| zyga-ubuntu | Chipaca: one sec | 15:08 |
| zyga-ubuntu | http://manpages.ubuntu.com/cgi-bin/search.py?q=systemd.unit&op=&cx=003883529982892832976%3A5zl6o8w6f0s&cof=FORID%3A9&ie=UTF-8 | 15:08 |
| mvo | pedronis: do you think you have a moment to answer the question that zyga-ubuntu has in 4026 ? | 15:08 |
| zyga-ubuntu | Chipaca: :-( | 15:08 |
| zyga-ubuntu | Chipaca: let me boot my vm | 15:08 |
| om26er | Hi! Which Ubuntu Core image shall I be using for reliable bluez support ? | 15:10 |
| zyga-ubuntu | om26er: hey, ubuntu core doesn't ship bluez, there's a bluez snap and the kernel you use for a device provides the needed bits | 15:10 |
| zyga-ubuntu | om26er: short answer: it's complicated | 15:10 |
| om26er | zyga-ubuntu: I installed the bluez snap, didn't know about a special kernel | 15:11 |
| om26er | I am on edge channel currently | 15:11 |
| om26er | ...of Ubuntu Core. | 15:11 |
| zyga-ubuntu | om26er: which kernel snap are you using now? | 15:12 |
| om26er | zyga-ubuntu: pi2-kernel 4.4.0.1074.74 42 canonical kernel | 15:12 |
| zyga-ubuntu | ah | 15:13 |
| zyga-ubuntu | so you are talkin about raspberry pi :) | 15:13 |
| om26er | yeah | 15:13 |
| zyga-ubuntu | for that I think ppisati or ogra_ can give better advice, I would also recommend discussing this in a thread on forum.snapcraft.io so that others can reuse the knowledge | 15:13 |
| ogra_ | om26er, you still need some hackery to power up the BT devices on the pi | 15:18 |
| ogra_ | om26er, https://bugs.launchpad.net/snappy/+bug/1674509/comments/30 | 15:18 |
| mup | Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509> | 15:18 |
| om26er | oh, I was kind of looking to use UbuntuCore+bluez in a production level software. | 15:19 |
| om26er | android <--> BLE | 15:19 |
| zyga-ubuntu | mvo: reviewed | 15:20 |
| om26er | ogra_: which Ubuntu Core image shall I be using ? | 15:20 |
| ogra_ | om26er, the edge one | 15:20 |
| om26er | I would prefer Stable but WiFi is broken on that one badly. | 15:20 |
| om26er | even the edge image crashed for me once, while setting up wifi | 15:21 |
| om26er | ...had to run the setup again. | 15:21 |
| ogra_ | om26er, well, you need the edge gadget and a kernel newer than stable ... so install from edge, switch coe to stable and the kernel snap to beta or so | 15:21 |
| ogra_ | s/coe/core/ | 15:21 |
| zyga-ubuntu | mvo: reviewed (again) | 15:22 |
| mvo | zyga-ubuntu: \o/ | 15:23 |
| om26er | who maintains the bluez snap ? | 15:23 |
| ogra_ | om26er, koza | 15:23 |
| zyga-ubuntu | koza: ^ | 15:23 |
| om26er | koza: when will bluez 5.47 graduate to stable ? | 15:23 |
| om26er | also is there a python example for talking to bluez(snap) in another confined snap ? | 15:25 |
| zyga-ubuntu | mvo: can you review https://github.com/snapcore/snapd/pull/4031 please | 15:25 |
| mup | PR #4031: interfaces/network-control: remove incorrect rules for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031> | 15:25 |
| koza | om26er, snap or deb? | 15:26 |
| om26er | koza: snap | 15:26 |
| ogra_ | koza, we should prehaps schedule some time at the sprint to get that pi3 bluez stuff finished ;) | 15:28 |
| zyga-ubuntu | mvo: it looks like this week, while bumpy, is also very much relevant for getting important (and long standing) bugs fixed | 15:28 |
| koza | om26er, it is currently in edge, do not have a date in my mind; do you need it for something? | 15:28 |
| ogra_ | (there is still the hciattach script we need etc) | 15:28 |
| koza | ogra_, yes we should | 15:29 |
| om26er | koza: nothing specific, though I was building it from source on raspbian and the latest there was 5.47, so wanted to make sure I was using similar stack. | 15:29 |
| koza | om26er, snap is at 5.44 and you should be fine with it until the 5.47 lands. i have landing card for it already but not a fixed date ahead of me. cannot do it over night as testing takes time | 15:32 |
| om26er | koza: ok no problem. is BLE/GATT working fine on that release ? | 15:33 |
| om26er | 5.44 I mean. | 15:33 |
| koza | om26er, it is working well | 15:34 |
| koza | om26er, it gets better with every bluez release however 5.44 isitself is solid | 15:35 |
| ikey | when does the "base snap" functionality land properly? | 15:35 |
| * ikey has plans for them | 15:35 | |
| zyga-ubuntu | ikey: we're working on them still but basics are available in 2.28.x | 15:35 |
| ikey | ok | 15:35 |
| zyga-ubuntu | ikey: we need tooling around building and using them though | 15:35 |
| zyga-ubuntu | ikey: and there are still some hard-coded assumptions (like /proc, /sys and perhaps some we like less) | 15:36 |
| ikey | well for my needs its basically i pre-prepare a root and point at it | 15:36 |
| ikey | well, /proc /sys aren't so bad i dont think | 15:36 |
| zyga-ubuntu | :) | 15:36 |
| zyga-ubuntu | yep | 15:36 |
| ikey | but multiarch assumptions might be a slap in the face | 15:36 |
| ikey | if they exist | 15:36 |
| ikey | though relative ../ symlinks can solve that | 15:36 |
| zyga-ubuntu | mvo has a minimal base snap | 15:36 |
| zyga-ubuntu | I think it has very little inside | 15:36 |
| om26er | koza: sounds great. If you could share some working examples that would be really helpful. Even a basic pair, ping/pong would suffice. | 15:37 |
| ikey | can a base snap be run? or just exposed as a dependency? | 15:37 |
| ikey | ideally id want a self contained snap, but if its not possible then fine | 15:37 |
| zyga-ubuntu | https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-base-bare | 15:37 |
| zyga-ubuntu | that's a base snap | 15:37 |
| ikey | oh | 15:37 |
| zyga-ubuntu | you can just start from that | 15:37 |
| ikey | so id build that with snapcraft? | 15:37 |
| zyga-ubuntu | and we'll gladly resolve issues | 15:37 |
| zyga-ubuntu | yep | 15:37 |
| ikey | ok | 15:38 |
| mup | PR core#61 opened: Also "mask" services when disabling them <Created by mvo5> <https://github.com/snapcore/core/pull/61> | 15:38 |
| zyga-ubuntu | as you find them :) | 15:38 |
| ikey | and is snapcraft going to punch me in the face for using a peasant OS? | 15:38 |
| ikey | and not having dpkg? | 15:38 |
| zyga-ubuntu | :/ | 15:38 |
| zyga-ubuntu | probably | 15:38 |
| zyga-ubuntu | but | 15:38 |
| ikey | lol | 15:38 |
| zyga-ubuntu | it's just a snap pack thing | 15:38 |
| * om26er will be doing websockets(actually WAMP) over BLE. | 15:38 | |
| zyga-ubuntu | so you don't need snapcraft for this | 15:38 |
| zyga-ubuntu | just mksquashfs | 15:38 |
| ikey | aha | 15:38 |
| ikey | ok thats good | 15:38 |
| zyga-ubuntu | we added a new "snap pack" command in master | 15:38 |
| koza | om26er, start with our documentation to bluez snap and bluez itself: https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/index | 15:38 |
| koza | om26er, any bluez example will work with core, DBus interfaces are the same | 15:39 |
| mvo | zyga-ubuntu, ikey I don't know most of the context but I will comment anyway. there is a "bare" base snap that can be used. it has *nothing* inside except for directory mount-points. no libc, no content | 15:39 |
| ikey | thats good, no libc | 15:39 |
| ikey | ok ill give you context, cant keep this quiet long | 15:39 |
| ikey | make it easier :P | 15:39 |
| ikey | im going to make a solus derived runtime that caters exclusively to steam | 15:40 |
| om26er | ogra_: where to get hciattach for this: https://bugs.launchpad.net/snappy/+bug/1674509/comments/30 | 15:40 |
| mup | Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509> | 15:40 |
| ikey | and ship a strict linux-steam-integration entry point in it | 15:40 |
| ikey | so it'll be a build of steam that actually doenst suck, and will work the same on any distro | 15:40 |
| ikey | even distros that cant multilib | 15:40 |
| ikey | it'll fix the various performance and functionality issues with the existing steam stuff | 15:41 |
| mvo | ikey: woah, that sounds pretty specacular! | 15:41 |
| ikey | i had *originally* planned to do this in flatpak land a long time ago but it suffers design deficiencies | 15:41 |
| ikey | notably the layering and driver functionality | 15:41 |
| ikey | the driver stuff in snapd for nvidia is much better | 15:41 |
| ikey | (because we can trust nvidia proprietary driver C ABI) | 15:41 |
| zyga-ubuntu | ikey: I'd like to understand your insight into that to avoid such issues in snapd in the future | 15:42 |
| ikey | zyga-ubuntu, flatpak tries to strongly discourage new root imagery | 15:42 |
| ikey | so you inherit from another all the time | 15:42 |
| ikey | even the KDE runtime does this | 15:42 |
| * zyga-ubuntu hugs mvo who fixed nvidia for a lot of people just now :) | 15:42 | |
| ikey | they also use glvnd inside the flatpak runtimes | 15:42 |
| ikey | and dynamically download/install a related series.. | 15:42 |
| ikey | doesnt *actually* use the host driver | 15:42 |
| mvo | zyga-ubuntu: a busy day, one more fix (xdg-open) and then I call it a day and get a big beer^Wtea | 15:43 |
| ikey | its.. ya. its wrong. | 15:43 |
| ikey | also the flatpak system is using flatpak-builder (json, seriously?), with yocto derived images | 15:43 |
| ikey | i had to poke them forever before they started using any secure cflags anywhere, but theres no optimisation at all | 15:43 |
| ikey | so any flatpak app is going to run like a spud. | 15:43 |
| ikey | the runtime is just a meta distro, not a real distro | 15:44 |
| ikey | so my steam snap would be a solus derived runtime that can also make additional tweaks to cover full abi compatibility for steam runtime & games.. | 15:44 |
| ikey | and take the pressure off the distros finally. | 15:44 |
| zyga-ubuntu | ikey: wow, that's pretty darn cool | 15:44 |
| ikey | https://github.com/ikeydoherty/runtime-abi-check <- also working on this in parallel so we can assert a full runtime compatibility check | 15:45 |
| zyga-ubuntu | ikey: do you think you could be more vocal about it, I'm sure many people will want to hear this | 15:45 |
| ikey | zyga-ubuntu, well id tried to keep it under wraps at first but ive a big mouth :P | 15:45 |
| ikey | cats out of the bag first and even people on reddit have sussed out what im up to | 15:45 |
| ikey | s/first/now/ | 15:45 |
| * ikey unbraintwitches | 15:45 | |
| zyga-ubuntu | ikey: let us know if we can help | 15:46 |
| ikey | certainly - this is basically what my vague snapcraft post was about the other day btw :P | 15:46 |
| * ikey goes to spill the beans properly on G+ | 15:46 | |
| ogra_ | om26er, it comes with the snap | 15:47 |
| zyga-ubuntu | ogra_: thank you for testing https://github.com/snapcore/core/pull/61#pullrequestreview-68970473 !!! | 15:49 |
| mup | PR core#61: Also "mask" services when disabling them <Created by mvo5> <https://github.com/snapcore/core/pull/61> | 15:49 |
| ogra_ | zyga-ubuntu, waiting for travis and willl merge then too | 15:50 |
| zyga-ubuntu | mvo: I assume you want that for the new core | 15:50 |
| ogra_ | we definitely do | 15:50 |
| ogra_ | (breaks a customer) | 15:50 |
| mup | PR core#61 closed: Also "mask" services when disabling them <Created by mvo5> <Merged by ogra1> <https://github.com/snapcore/core/pull/61> | 15:53 |
| zyga-ubuntu | Chipaca: can you do a quck 2nd on https://github.com/snapcore/snapd/pull/4027 | 15:53 |
| mup | PR #4027: spread: allow setting SPREAD_DEBUG_EACH=0 to disable debug-each section <Created by zyga> <https://github.com/snapcore/snapd/pull/4027> | 15:53 |
| Chipaca | probably | 15:53 |
| mup | PR snapd#4029 closed: packaging: remove .mnt files on removal <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4029> | 15:54 |
| === cachio_lunch is now known as cachio | ||
| Chipaca | zyga-ubuntu: +1 | 15:55 |
| zyga-ubuntu | thank you | 15:55 |
| mup | PR snapd#4027 closed: spread: allow setting SPREAD_DEBUG_EACH=0 to disable debug-each section <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4027> | 15:56 |
| ikey | https://plus.google.com/+Solus-Project/posts/ZL8C2wBqbfg | 15:56 |
| * ikey has let knowledge slip | 15:56 | |
| zyga-ubuntu | ikey: :heart: (I wish IRC did this)_ | 15:57 |
| ikey | :D | 15:58 |
| ikey | fwiw i once wrote an IRC client in java years ago (Called it Dave2) - and I thought the best way to implement smilies would be to use a web view. And it worked fantastically | 15:58 |
| ikey | That is, until the other guys on the channel figured out a flaw in my plan. And started sending <img src=... | 15:59 |
| zyga-ubuntu | goatse on IRC never looked the same | 15:59 |
| ikey | lol | 15:59 |
| zyga-ubuntu | :> | 15:59 |
| mup | PR snapcraft#1612 closed: cross compile: enable cross compilation of i386 kernel on x86-64 hosts <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1612> | 15:59 |
| ikey | p much | 15:59 |
| popey | zyga-ubuntu: what irc client do you use? | 15:59 |
| zyga-ubuntu | popey: irssi on ubuntu, hexchat on solus, polari on fedora and suse | 15:59 |
| * ikey still holds a stupid preference to xchat over hexchat for old timey sake | 16:00 | |
| popey | file:///home/alan/Pictures/Screenshot%20from%202017-10-12%2016-59-24.png https://usercontent.irccloud-cdn.com/file/yPkV6ROY/Looks%20great%20in%20irccloud%20%3A) | 16:00 |
| ikey | like i have some irrational grudge against hexchat | 16:00 |
| zyga-ubuntu | I'd like to write an IRC client one day, would be a good way to learn about socket APIs (in C obviously) | 16:00 |
| ogra_ | zyga-ubuntu, pfft C ... kool kids write it in shell ! | 16:01 |
| ikey | zyga-ubuntu, sooo i did an evil with that once | 16:02 |
| ogra_ | shell with whiptail UI | 16:02 |
| ikey | a malloc-free IRC client in C | 16:02 |
| ikey | (CLI only) | 16:02 |
| ikey | i say this one thing and you cry: variable length arrays | 16:02 |
| zyga-ubuntu | ogra_: "would you like to send a message" dialog window in ncurses? | 16:02 |
| ogra_ | yeah ! | 16:03 |
| zyga-ubuntu | ikey: alloca? | 16:03 |
| zyga-ubuntu | ikey: malloc free is a noble goal | 16:03 |
| ikey | VLAs, like | 16:03 |
| ikey | argument of size in function definition | 16:03 |
| zyga-ubuntu | ikey: I really have a lot of respect for reliable software that can function as a finite state machine and have no memory allocation | 16:03 |
| ikey | then: char blob[n]; from function parameter | 16:03 |
| ikey | thats a special kind of evil lol | 16:03 |
| zyga-ubuntu | ikey: right, all stack based, allowed by modern C (well, as of C99) | 16:03 |
| ikey | sure | 16:03 |
| ikey | but should be killed with fire :P | 16:03 |
| ikey | (quite easy to kill them) | 16:04 |
| popey | zyga-ubuntu: should I switch to core edge channel in anticipation of exciting fixes coming down the pipe soon? :) | 16:17 |
| popey | </hopeful> | 16:17 |
| zyga-solus | popey: yes, later today when mvo rebuilds new core | 16:20 |
| popey | super | 16:20 |
| zyga-solus | mvo: but I think you can keep beta | 16:20 |
| zyga-solus | er | 16:20 |
| zyga-solus | popey: ^ | 16:20 |
| popey | oh ok | 16:20 |
| zyga-solus | because it will go there for cachio to test | 16:20 |
| * kalikiana hopping on a train, will check back in a bit later | 16:21 | |
| kalikiana | elopio: perhaps also interesting for you, I may have found a way to make those x revisions match... will push later after I can test it properly | 16:23 |
| kalikiana | it occurred to me the 'current' snap makes more sense than the exact filename | 16:23 |
| mup | PR snapd#4034 opened: dbus: ensure io.snapcraft.Launcher.service is created on re-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/4034> | 16:27 |
| mvo | popey: yeah, later today, some things have no landed yet, but some good fixes on the way | 16:28 |
| mvo | zyga-ubuntu: I would like to merge 4026 even with the open questions, wdyt? | 16:35 |
| mup | PR snapd#4031 closed: interfaces/network-control: remove incorrect rules for tun <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4031> | 16:35 |
| mvo | Chipaca: you mentioned earlier you are ready for reviews - 4034 needs one | 16:36 |
| zyga-solus | mvo: mmm | 16:38 |
| zyga-solus | mvo: can you telegram gustavo? maybe pedronis is around and can give a quick yes/no | 16:38 |
| zyga-solus | (please) | 16:38 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| ikey | soo uhm | 16:39 |
| ikey | whats developer namespace? | 16:39 |
| ikey | on snapcraft form | 16:39 |
| zyga-solus | ikey: your developer nickname | 16:40 |
| zyga-solus | ikey: when you snap install foo it is "foo from developer bar" | 16:40 |
| zyga-solus | where bar is the namespace | 16:40 |
| ikey | oh | 16:40 |
| ikey | so ikey | 16:40 |
| ikey | lol | 16:40 |
| zyga-solus | and foo is the snap name | 16:40 |
| zyga-solus | yep | 16:40 |
| zyga-solus | :D | 16:40 |
| ikey | cheers :D | 16:40 |
| zyga-solus | but | 16:40 |
| ikey | ya idk why this wants my address, not getting it :p | 16:40 |
| zyga-solus | you can make it "solus" or something like that if youwant | 16:40 |
| ikey | nah we'll have more solus devs over there in future | 16:40 |
| zyga-solus | ok | 16:40 |
| ikey | my ego isnt this large :P | 16:40 |
| zyga-solus | eventually you should be able to have a solus account and many people publishing there | 16:41 |
| zyga-solus | there are simple ways of doing that now | 16:41 |
| ikey | probably put Solus in company name..? | 16:41 |
| zyga-solus | ^_^ no idea | 16:41 |
| ikey | should i call my snap "linux-steam-integration" or just "lsi" ? | 16:42 |
| ikey | more thinking in case valve gets uppity | 16:42 |
| zyga-solus | Lovely Startup Interface | 16:42 |
| ikey | linux-steam-integration it is | 16:42 |
| ikey | and im guessing Ubuntu (public) | 16:43 |
| ikey | oh wow, the dashboard is so unity 8 | 16:43 |
| zyga-solus | oh? | 16:44 |
| zyga-solus | in what way/ | 16:44 |
| zyga-solus | I haven't looked at it in a long time | 16:44 |
| ikey | icons etc | 16:44 |
| ikey | https://ibin.co/3dY4toqN8qV8.png | 16:44 |
| ikey | lol | 16:44 |
| zyga-solus | ah, indeed :) | 16:44 |
| zyga-solus | is that dashboard.snapcraft.io? | 16:44 |
| ikey | yeah | 16:45 |
| zyga-solus | yeah :) | 16:45 |
| zyga-solus | I think it needs some UX love | 16:45 |
| zyga-solus | (probably already in some pipe) | 16:45 |
| ikey | aye | 16:45 |
| ikey | so normally i can just do snap register i guess? | 16:45 |
| ikey | ah snapcraft register | 16:45 |
| ikey | makes sense - context n all | 16:45 |
| zyga-solus | yes | 16:45 |
| zyga-solus | log in | 16:45 |
| zyga-solus | then register | 16:45 |
| * ikey thinks he might be at the point of no return now | 16:46 | |
| ikey | lol | 16:46 |
| zyga-solus | terrible stuff sucks but great stuff sucks all the time :) | 16:47 |
| ikey | hah nice | 16:47 |
| ikey | oh one thing i didnt figure earlier zyga-solus | 16:49 |
| ikey | can a base snap run? or must it be split as app + base | 16:49 |
| Chipaca | mvo: +1 with two Qs | 16:49 |
| zyga-solus | ikey: it depends on what you mean | 16:49 |
| zyga-solus | ikey: I don't think we tried apps on base snaps yet | 16:49 |
| ikey | ok so ill keep it simple and have a split runtime | 16:49 |
| zyga-solus | ikey: but you can certainly ship executables inside | 16:50 |
| ikey | basically ill make linux-steam-integration depend on solus-gaming-runtime or something | 16:50 |
| zyga-solus | ikey: I think we'll find dragons, I'll gladly fix anything you run into | 16:50 |
| ikey | thinking more from the delta perspective if i need hotfixes in LSI its likely better to split them | 16:50 |
| zyga-solus | oh, indeed | 16:50 |
| ikey | *registers new snap* | 16:51 |
| ikey | lol | 16:51 |
| zyga-solus | for base snaps you will run into "stale base snap bug" so you may need to unmount /run/snapd/ns/foo.mnt (where foo is the app snap) from time to time | 16:51 |
| ikey | ah ok | 16:51 |
| ikey | hm ill call it solus-runtime-gaming - we might end up expanding this stuff, who knows | 16:51 |
| ikey | nice having a common basename | 16:51 |
| mcphail | i'm loving the sound of this | 16:52 |
| ikey | well from my perspective its about time solus shared its toys | 16:52 |
| ikey | our pride and joy is our steam gaming lol | 16:52 |
| zyga-suse | darn | 16:52 |
| ikey | darn because you suddenly realised you're on suse? | 16:53 |
| ikey | or..? | 16:53 |
| zyga-suse | I suspended my laptop because I was looking for something on the other side of the lid and I just closed it (a little) | 16:53 |
| ikey | ow | 16:53 |
| zyga-suse | trying to resume it | 16:53 |
| ikey | xD | 16:53 |
| zyga-suse | hmm | 16:53 |
| zyga-suse | so mouse works | 16:53 |
| zyga-suse | but keyboard input does not | 16:54 |
| zyga-suse | .... | 16:54 |
| ikey | o_O | 16:54 |
| zyga-suse | I can move to VT and log in there | 16:54 |
| zyga-suse | but I cannot get any input in the desktop session | 16:55 |
| zyga-suse | I see a lot of "gdk_device_update_tool: assertion `GDK_IS_DEVICE (device)` failed | 16:56 |
| * ikey thinks hard reboot | 16:56 | |
| zyga-suse | I'll reboot, too tired to debug another thing today | 16:56 |
| zyga-suse | I think I was fully up-to-date | 16:57 |
| zyga-suse | I'll check in a sec | 16:57 |
| zyga-solus | hmm | 16:59 |
| zyga-solus | I thought hexchat remembers my config | 16:59 |
| zyga-solus | odd | 16:59 |
| * Chipaca EODs (mostly) | 16:59 | |
| zyga-solus | see you tomorrow john! | 17:00 |
| zyga-solus | ikey: you know | 17:03 |
| zyga-solus | one bit of complaint (or just observation perhaps) | 17:03 |
| ikey | ? | 17:03 |
| zyga-solus | playing with all the distros | 17:03 |
| zyga-solus | and updating them on a regular basis | 17:03 |
| zyga-solus | pacman has the most silly command to use | 17:03 |
| ikey | -Syu | 17:03 |
| ikey | lol | 17:03 |
| zyga-solus | "pacman -Suy" (maybe --soy-milk) | 17:03 |
| ikey | XD | 17:03 |
| Pharaoh_Atem | pacman has the dumbest syntax in the world | 17:04 |
| zyga-solus | solus has a nice UI tool | 17:04 |
| ikey | we have derpy "eopkg" which is so easy to typo | 17:04 |
| zyga-solus | but "eopkg it" is more like "freud id" in my head | 17:04 |
| zyga-solus | why not "install" | 17:04 |
| ikey | you can eopkg install | 17:04 |
| zyga-solus | ah | 17:04 |
| ikey | `it` is just a shorthand | 17:04 |
| ikey | it supports both | 17:04 |
| zyga-solus | man, I didn't notice :) | 17:04 |
| ikey | :D | 17:04 |
| ikey | `eopkg help` will sort you right out | 17:04 |
| zyga-solus | yeah, I just typed that | 17:05 |
| ikey | fwiw that command will change one day | 17:05 |
| zyga-solus | and I'm fully up-to-date | 17:05 |
| ikey | it was eopkg because evolve os | 17:05 |
| zyga-solus | ah | 17:05 |
| ikey | yeah sync window is tomorrow | 17:05 |
| zyga-solus | I was wondering what "e" stands for | 17:05 |
| zyga-solus | btw, I had a package to share | 17:05 |
| zyga-solus | unfinished | 17:05 |
| ikey | gnome 3.26, systemd 235, etc | 17:05 |
| ikey | oh ok | 17:05 |
| zyga-solus | but maybe you can do it | 17:05 |
| mvo | Chipaca: \o/ | 17:05 |
| Pharaoh_Atem | zyga-solus: Evolve OS | 17:05 |
| Pharaoh_Atem | eopkg was forked from PiSi from Pardus | 17:06 |
| ikey | many moons ago | 17:06 |
| ikey | fwiw we didnt originally fork it, we continued the development of it as pardus abandoned it | 17:06 |
| ikey | but then pardus anka got pissy with us for calling it pisi still | 17:06 |
| Pharaoh_Atem | Solus OS (deb) became Evolve OS (pisi), which became Solus again | 17:06 |
| ikey | so we renamed it | 17:06 |
| ikey | Ehm | 17:06 |
| Pharaoh_Atem | did I miss a step? | 17:06 |
| ikey | SolusOS 2 (pisi) became Evolve OS (pisi) | 17:07 |
| zyga-solus | ikey: https://gist.github.com/zyga/754d14715963ecc8b72f6d39059ffa1b | 17:07 |
| Pharaoh_Atem | ah | 17:07 |
| Pharaoh_Atem | whoops | 17:07 |
| ikey | yeah its complex :P | 17:07 |
| zyga-solus | ikey: I wanted to build it but man, that indent program is old shit | 17:07 |
| ikey | xD | 17:07 |
| zyga-solus | ikey: I had to use the debian .orig tarball which is unofficial but has fixes | 17:07 |
| ikey | oh sweet holy jesus | 17:07 |
| zyga-solus | ikey: and even with.. | 17:07 |
| zyga-solus | yeah | 17:07 |
| zyga-solus | and it doesn't build :-( | 17:07 |
| ikey | -Wno-implicit-int | 17:07 |
| zyga-solus | but I wanted to use it | 17:07 |
| zyga-solus | ikey: it's all old crap | 17:07 |
| Pharaoh_Atem | fuck eww | 17:07 |
| zyga-solus | I wanted to share in case you can make it magically work | 17:08 |
| zyga-solus | and get a first package into solus :) | 17:08 |
| * ikey has a lookie | 17:08 | |
| zyga-solus | ikey: it fails on docs now | 17:08 |
| zyga-solus | ikey: the --sections option grew into two and I got stuck trying to unf*** that and regen autotools | 17:08 |
| ikey | lol | 17:08 |
| zyga-solus | ikey: I think it's one of those old unloved packages and GNU folks still demand dead tree signature mailed to US somewhere | 17:09 |
| zyga-solus | so debian forked it but nobody loves still | 17:09 |
| zyga-solus | love is hard when it's GNU/Love | 17:09 |
| ikey | all you need is gnu... | 17:10 |
| * ikey cooks a patch | 17:11 | |
| zyga-solus | ikey: I'd love to see what happens next, where does this package go to end up on my laptop | 17:11 |
| ikey | [Package] Creating /home/build/work/indent-dbginfo-2.2.11-1-1-x86_64.eopkg ... | 17:12 |
| ikey | [Package] Creating /home/build/work/indent-2.2.11-1-1-x86_64.eopkg ... | 17:12 |
| ikey | [Package] Building complete | 17:12 |
| ikey | so basically i stole some fedora/arch packages from arch repo | 17:12 |
| zyga-solus | you make it look too easy | 17:12 |
| ikey | and added one new patch | 17:12 |
| zyga-solus | I spent a few hours on this | 17:12 |
| ikey | https://hastebin.com/raw/xokonixera | 17:12 |
| zyga-solus | ^_^ | 17:12 |
| ikey | so yeah in terms of our pipeline | 17:13 |
| ikey | it ends up in our phabricator git "at some point" | 17:13 |
| ikey | we issue "make publish" which creates a git tag, and tells the build controller the tag and source name | 17:13 |
| ikey | build server asks build controller for a job, told to check out indent @ certain tag | 17:13 |
| ikey | (immutable git repos too) | 17:13 |
| ikey | builder checkouts the tag, builds the guy local, lets the build controller know how it went | 17:14 |
| ikey | uploads logs to log server via ssh pubkey, and uploads eopkg to ferryd on package server incoming directory on pubkey ssh | 17:14 |
| ikey | the builds are done with solbuild which use light container chroots | 17:14 |
| ikey | no networking allowed, etc | 17:14 |
| ikey | ferryd sees some incoming files turn up (fsnotify), and scans the .tram file | 17:14 |
| ikey | it describes the full payload and sha256sums | 17:15 |
| ikey | (and the target, i.e. "unstable") | 17:15 |
| ikey | then if its legit, and passes initial inspection, ferryd will create a job to include it into unstable | 17:15 |
| ikey | which is about 8 seconds after hitting the incoming directory | 17:15 |
| zyga-solus | and stable? | 17:15 |
| ikey | it also spawns off background jobs to see if it can delta it | 17:15 |
| zyga-solus | is that waiting for another stable release? | 17:15 |
| ikey | stable is a weekly sync | 17:15 |
| ikey | we stabilise the entire repo over the course of one week | 17:16 |
| zyga-solus | ah, wow, speedy! | 17:16 |
| ikey | and we sync it on a friday now | 17:16 |
| ikey | so ill literally do: ferryctl pull unstable shannon | 17:16 |
| ikey | ~10s later the repo is synced | 17:16 |
| ikey | and the index is updated, letting the updates out | 17:16 |
| ikey | in the background it'll be off checking the delta mappings and creating new deltas for this upgrade path | 17:16 |
| ikey | later on i check ferryctl status to see if its complete, tell it to reindex, and bam, delta path is available too | 17:16 |
| ikey | realistically unstable is the "real" distro, and shannon is a lagging snapshot release of unstable | 17:17 |
| ikey | meaning we do a full solus release once a week | 17:17 |
| ikey | just without ISOs | 17:17 |
| ikey | for this week we've gone from systemd 218 to 235, gnome 3.24 to gnome 3.26, new gstreamer, etc. we're ballsy :P | 17:17 |
| zyga-solus | how do you test it? | 17:18 |
| ikey | initially we'll do local ISOs | 17:18 |
| ikey | which is basically: cd Solus/solus-image-budgie; make | 17:18 |
| ikey | then "make boot" | 17:18 |
| ikey | once we're happy with our ISO and VM testing, we'll upgrade our own systems on the unstable repos and test the changes | 17:19 |
| zyga-solus | make boot just boots it? | 17:19 |
| ikey | yep | 17:19 |
| zyga-solus | is that manual or automatic? | 17:19 |
| ikey | it just calls out to qemnu | 17:19 |
| zyga-solus | e.g. if gnome is f***d, how do you know? | 17:19 |
| ikey | *qemu | 17:19 |
| ikey | we test it | 17:19 |
| ikey | like we manually check the ISO | 17:20 |
| ikey | ive seen what a reliance on openQA does :) | 17:20 |
| ikey | im also running the gnome 3.26 stack right now | 17:20 |
| ikey | same as all contributors | 17:20 |
| ikey | we dogfood | 17:20 |
| ikey | we also check our logs (dmesg/journalctl) and we have some early warning systems for "you're in trouble) | 17:20 |
| ikey | f.e. we use abireport on all of our repos | 17:21 |
| zyga-solus | I'm interested because of our, *ahem*, issue this week | 17:21 |
| zyga-solus | we need to re-visit our testing policy | 17:21 |
| ikey | aah | 17:21 |
| ikey | so every change in solus looks something like this: | 17:21 |
| ikey | https://dev.solus-project.com/R2955:370f0e60dcbc5db67249eb42384dfafaeeac3748 | 17:21 |
| ikey | as you can imagine, it gives us a really clear heads up | 17:22 |
| ikey | we only do the package.yml, but the abireport + pspec stuff is all automatic | 17:22 |
| ikey | combine that with the sync approach + cadence, it actually solves an awful lot of problems before they can happen | 17:23 |
| ikey | whereas distinct waterfall channels tend to make things too complicated :) | 17:23 |
| mup | PR snapcraft#1613 opened: cross compilation: enable cross compilation of i386 kernel on x86-64 … <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1613> | 17:26 |
| mup | PR snapd#4035 opened: Fix econnreset test when the download needs a retry <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4035> | 17:40 |
| mup | PR snapd#4032 closed: fix shell errors from shellcheck <Created by albertodonato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4032> | 17:41 |
| kyrofa | Hey elopio, how hard would it be to run a suite of snapd tests on a trusty lxc? | 17:43 |
| elopio | kyrofa: Easy. Just add an argument to the lxd launch script. And a new entry in travis.yml. | 17:50 |
| elopio | How well snapcraft runs in trusty from source , no clue. | 17:51 |
| kyrofa | Badly. Exactly why I want tests covering it once I fix it | 17:52 |
| kyrofa | elopio, actually, what I really care about is ensuring that the snapcraft _snap_ runs there. Which is sort of a different problem entirely, huh | 17:53 |
| kyrofa | elopio, do we have any tests that ensure the snap works? | 17:53 |
| elopio | We have the spread tests. And once we finish the branch from sergiusens for pushing the snap for every PR, I want to switch all the integration tests to run from the snap. | 17:54 |
| kyrofa | Are the spread tests run from travis? | 17:56 |
| kyrofa | Or elsewhere? | 17:56 |
| elopio | Yes, but on the daily travis cron | 17:56 |
| kyrofa | elopio, do we need to actually publish the snap in order to test it? We could build it and cache it | 17:57 |
| kyrofa | Then follow-on stages could use it | 17:57 |
| kyrofa | But yeah okay, I'll add spread tasks for this since I believe they have trusty machines available | 17:58 |
| elopio | According to the Travis docs, we should share it using an external service. aws or ftp. But, we can't use credentials on PRs. | 17:59 |
| elopio | I think it's better to push to the store, and dog food our own process. | 18:00 |
| elopio | +1 on the spread test. | 18:03 |
| kyrofa | elopio, alright. Note that we might hit a few minutes of store caching | 18:11 |
| mup | PR snapd#4033 closed: snap-confine: add support for handling /dev/nvidia-modeset <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4033> | 18:35 |
| AlbertA | jdstrand: we have consolidated mir-libs into mir-kiosk... so the mir-kiosk snap is now the provider of mir-libs content i/f slot... can we ask to enable autoconnection of mir-libs plug (similar to what we had for mir-libs snap) for mir-kiosk? | 18:40 |
| mvo | zyga-solus: the world is conspiring again - tests for 4034 take forever to even start | 18:53 |
| * ikey is back to being the antichrist on reddit | 18:54 | |
| mvo | zyga-solus: once those are finisehd I'm keen to merge 4026 too even if we don't get a reply, I would love to push out 2.28.5 tonight but given the state of tests, maybe tomorrow | 18:54 |
| jdstrand | AlbertA: it is good that you are asking this cause things have changed a bit in the process that I've been meaning to circle back to you on. Can you add a formal request using https://forum.snapcraft.io/t/process-for-reviewing-aliases-auto-connections-and-track-requests/455? | 18:56 |
| AlbertA | jdstrand: sure thanks! | 18:56 |
| kyrofa | elopio, the plugins integration tests are reliably running over in Travis. I'd like to split them. Any opinion on a logical split? | 18:57 |
| jdstrand | AlbertA: I haven't looked at the snap, but just a heads up, as part of the conversation you may be asked to change the value of the 'content' attribute (again, maybe you won't need to. we can discuss on the list) | 18:57 |
| elopio | kyrofa I don't want to split them, I would like to make the Ruby and cargo plugins faster. Give me a minute... | 18:59 |
| mup | PR snapd#4026 closed: overlord/auth: continue for now supporting UBUNTU_STORE_ID if the model is generic-classic <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4026> | 19:00 |
| kyrofa | elopio, alright, let me know. I'll move to testing ROS on artful. But those tests running over is starting to stand in the way of things landing | 19:00 |
| elopio | https://gist.github.com/elopio/db8adee5a0ab4505835e0dc85ffcc105 | 19:00 |
| elopio | It seems to me that 3 minutes for a hello world snap is too much. | 19:00 |
| kyrofa | elopio, I mean... you're building ruby from source | 19:02 |
| elopio | And I proposed two PRs yesterday to remove 4 tests. That's 4-6 minutes less. A little time to get real fixes in place. | 19:02 |
| AlbertA | jdstrand: ok, is this good? https://forum.snapcraft.io/t/mir-kiosk-mir-libs-auto-connection/2452 | 19:02 |
| elopio | kyrofa: yes, I'm thinking about a ruby snap. Does that make sense? | 19:03 |
| kyrofa | elopio, well, the plugin explicitly supports multiple versions of ruby | 19:03 |
| kyrofa | elopio, what are your plans there? | 19:03 |
| kyrofa | elopio, that would also require the ruby to be staged | 19:03 |
| kyrofa | elopio, so, stage-snaps | 19:03 |
| elopio | Multiple snaps or tracks. And fall back to build from source | 19:04 |
| === JanC_ is now known as JanC | ||
| elopio | Right, stage snaps. To me, that's the solution for our slow tests. Not more splits. | 19:05 |
| kyrofa | elopio, that's an 18.04 task | 19:05 |
| kyrofa | How long are we gonna wait? :P | 19:05 |
| elopio | And the other thing is parallelization. Yesterday I finally got the nested containers working. | 19:05 |
| elopio | But, we need to build the snap first, to test he same thing in the container. | 19:06 |
| kyrofa | elopio, also, that raises a lot of questions. Who will maintain all these ruby snaps? Will we also need to start maintaining ros2 snaps? | 19:06 |
| kyrofa | How about rust? | 19:06 |
| elopio | 18.04 starts next week 😃 | 19:06 |
| elopio | I think us and snapcrafters, if upstream doesn't accept them. | 19:07 |
| elopio | And yes, ros snaps, snaps for everything that makes our hello worlds slow. Or well, that's my idea. If we don't go that path, the split. | 19:07 |
| elopio | One suite for python, one for Ruby, one for cargo. | 19:08 |
| jdstrand | AlbertA: yes, the request looks fine. thanks! | 19:08 |
| kyrofa | So to be clear: in order to make tests pass that are failing today, you want to 1) develop stage-snaps, 2) develop ruby-snaps that are good enough to upstream, and 3) find a home for them? | 19:08 |
| kyrofa | elopio, not everything will work well within a snap, too. Gems will be fun. ros2 will be more fun | 19:09 |
| kyrofa | I'm not sure we should put all our eggs in that basket just yet | 19:09 |
| elopio | First, remove duplication. That's ready today. Then parallelization, we only need to send the snap somewhere. | 19:10 |
| elopio | Then, make the plugins faster. | 19:10 |
| elopio | If all else fails, mark the tests as slow and live with them. | 19:11 |
| zyga-solus | re | 19:44 |
| zyga-solus | mvo: I agree about 2.28.5 | 19:44 |
| zyga-solus | mvo: let me look at PRs now | 19:44 |
| mvo | zyga-solus: just one left, pedronis merged his | 19:46 |
| zyga-solus | yep, I see | 19:47 |
| zyga-solus | reading it now | 19:47 |
| zyga-solus | added a comment | 19:48 |
| zyga-solus | reading rest | 19:48 |
| zyga-solus | mvo: +0.5, not sure about that condition I indicated | 19:50 |
| zyga-solus | mvo: I'll check back | 19:54 |
| kyrofa | elopio, figured out the ROS failure | 20:00 |
| kyrofa | elopio, fix coming | 20:00 |
| cachio | zyga-solus, there? | 20:00 |
| kyrofa | elopio, due to new python3-apt | 20:00 |
| cachio | zyga-solus, in pi 2 and 3 when I set and unset a var for the core like in the test snapctl-configure-core | 20:01 |
| zyga-solus | yes | 20:01 |
| cachio | in the config file it is being removed the new line at the end of the file | 20:02 |
| cachio | it is making the test fail | 20:02 |
| cachio | and I think it is kind of bug | 20:02 |
| cachio | but the core works well | 20:02 |
| cachio | zyga-solus, any idea why it could be happenning just for the pi's? | 20:03 |
| elopio | tx kyrofa | 20:06 |
| zyga-solus | I think there are pi specific implementations of coreconfig | 20:06 |
| zyga-solus | maybe a bug there? is that a regression? | 20:06 |
| zyga-solus | I'm honestly too tired to debug this tonight | 20:06 |
| cachio | zyga-solus, yes, it is a regression but it comes from like a month | 20:06 |
| zyga-solus | aha | 20:06 |
| zyga-solus | mvo: ^ let's dalay for tomorrow | 20:06 |
| zyga-solus | mvo: I'll prepare pi2 and pi3 and we can iterate | 20:06 |
| zyga-solus | cachio: please drop a thread with description of the problem | 20:07 |
| cachio | zyga-solus, sure | 20:07 |
| zyga-solus | thank you, sorry, just too tired + back pain (kids decided to invade us last night and we slept like fish in a can) | 20:08 |
| zyga-solus | I'm AFK now | 20:08 |
| mvo | zyga-solus: hm, just a \n missing? | 20:08 |
| cachio | mvo, yes | 20:10 |
| cachio | mvo https://paste.ubuntu.com/25728285/ | 20:11 |
| cachio | that is the error | 20:11 |
| mvo | zyga-solus: hm, hm, I'm too tired tonight, but we can look tomorrow early | 20:14 |
| mvo | cachio: thanks | 20:14 |
| cachio | mvo, sure, no hurry, I'll write a forum post | 20:15 |
| mvo | ta | 20:15 |
| mvo | I wait for tests for 4034 and then call it a day | 20:15 |
| cachio | mvo, are you gonna include that in 28.5? | 20:17 |
| mup | PR snapcraft#1614 opened: apt repo: allow insecure repos <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1614> | 20:20 |
| kyrofa | elopio, that's for you ^^ | 20:21 |
| elopio | kyrofa: I'm on holidays today. I'll review it tomorrow. | 20:40 |
| kyrofa | elopio, oh! I'm sorry, I didn't know, I wouldn't have been bothering you! | 21:04 |
| elopio | Don't worry. I would have told you to stop bothering me if you were :) | 21:07 |
| kyrofa | Good :) | 21:15 |
| kyrofa | elopio, what are you up to, then? Just hangin out? | 21:15 |
| === jkridner|pd is now known as jkridner_ | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapcraft#1615 opened: schema: improve invalid app, hook, and part errors <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1615> | 22:54 |
| mup | PR snapcraft#1616 opened: store: guide to account creation upon login <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1616> | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
