[03:05] hey anyone here have any luck with rocket chat irc federation ? [06:21] morning [06:23] o/ [06:23] hey mborzecki [06:35] already up zyga ?! :) [06:35] yes [06:36] how are you Pierre? :) [07:11] zyga, good good! And you? [07:11] it's finally getting cold here in Taipei :) [07:20] really? [07:20] it was 22C yesterday [07:21] weather anomaly like nothing before [07:21] today it is colder but not anywhere near being really cold yet [07:27] well... it's 19 °C [07:27] I have to put something on top of my t-shirt, that's my definition of "cold" :) [07:29] haha, yes, that's Spain-level cold :) [07:47] hmm would like to get https://github.com/snapcore/snapd/pull/5696 to a state where it can be landed [07:47] PR #5696: interfaces/opengl: add additional accesses for cuda [07:50] damn, cuda-samples from ijohnson is huuge [07:55] and fedora 29 is out, the mirrors are down :/ [07:57] hmmm [07:57] mborzecki: heh, yes [07:57] I'm pulling 29 to try [07:57] mborzecki: did you see my suggestion on 5696 [07:57] maybe we should just drop that part [07:58] and even hardcode the mknod in snap-confine? [07:58] golang question: [07:58] I have a struct with another struct inside [07:58] the inner struct is defined inline, that is, it has no type name [07:58] how do I make literals of that type? [07:59] zyga: yeah, i want to check if you can precreate the node and if stuff continues to work then we should be fine [07:59] zyga: iirc it used to work like this in early cuda versions, you had to create the node manually and so on [08:00] I think it must work [08:00] after all, cuda creates the nodea [08:00] and then it is there [08:00] so ... [08:00] if it is a fixed major/minor [08:01] let's just do it [08:02] zyga: i'm installing a snap from ian, if it works, then i'll update the PR and we can land it [08:02] ok [08:02] cool :) [08:03] heyas [08:03] zyga: there was a topic about cuda and ubuntu core, left a note there, https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/45 maybe you have some ideas [08:03] pstolowski: hey [08:04] hey pawel [08:05] PR snapd#6068 closed: ifacestate/helpers: findConnsForHotplugKey helper [08:05] mborzecki: interesting [08:06] mborzecki: based on what you said I'd say the most stable, long term solution for loading firmware would be where snapd would run an internal helper in the main mount namespace [08:06] and that helper would arrange for the firmware to be loaded [08:06] to both detach from the need for granting apps the permission [08:06] and to be in control of the mount namespace [08:07] zyga: mhm, something like that [08:07] zyga: snapctl request-firmware :) [08:07] and dd that to sys node [08:07] could be just snapd doing it itself [08:08] we may not really need a new command [08:08] if it is really an ioctl and dd [08:13] * zyga installs F29 now [08:19] zyga: yup, seems to work with manually created node [08:19] another hack in Nvidia land [08:19] but ... whatever :) [08:19] perhaps it should be a part of the mount profile? [08:20] we can create symlinks [08:20] we could create device nodes [08:22] PR snapd#6077 opened: overlord/ifacestate: use map[string]*connState when passing conns around [08:23] zyga: we'd need to teach snap-update-ns to create nodes [08:23] yeah but that's not difficult in the current architecture [08:23] mhm [08:23] it's really a minor bump over symlinks [08:24] wow, the tests are really slow on my gt1030 [08:31] o/ [08:31] hey Chipaca [08:31] mborzecki: what does the test entail? [08:31] morning Chipaca! [08:32] zyga: heh, i think it's stuck [08:33] I'm seeing red today [08:33] and not in a berserker kind of way [08:38] Chipaca: fedora got a new release :) [08:39] heh maybe we should start putting fedora on manual ahead of the release [08:40] mborzecki: I'm seeing failures in ubuntu things that shouldn't be failing [08:40] bah [08:41] yesterday the new core release meant the store was unusable from tests for a few hours [08:41] then the travis osx image stopped shipping ruby -> no homebrew -> red osx test [08:41] the ubuntu thing hadn't properly resolved before I had to sleep, at ~1am [08:42] and now travis is fixed, and the store seems to be fine, but I'm still seeing some failures that make no sense unless the store is not fine [08:42] tests/regression/lp-1693042 in particular [08:44] regression tests are useful [08:44] well [08:44] interesting day [08:45] * zyga needs coffee [09:03] re [09:10] * zyga got a dentist appointment at 14:30 [09:10] but I can do the standup on the go [09:25] I finally got x2goclient snap working, thanks for the help. After I worked around the bug in libssh x2go tried to open /tmp/.X11-unix/X0 and failed, I didn't spend anytime on looking into it as I figured there's no way around it other than classic mode, and it worked in classic mode so I'm happy. cheers [09:36] :3043 [09:36] ups, wrong window [09:37] chesty: do you have the x11 interface? [09:39] i do, yes [09:40] i don't have desktop or desktop-legacy [09:40] chesty: the x11 interface allows access to /tmp/.X11/X0 [09:41] also /tmp/.X11-unix/X0 [09:41] (first one was a typo) [09:41] weird, I just double checked, I definitely had and still have the x11 plug [09:41] *also* /tmp/.X11-unix/X12345676543234567654345676543456765432345678 [09:41] :-) [09:42] zyga: mborzecki: who's best for looking into ^ x11 socket denials? [09:42] i only have 12345676543234567654345676543456765432345677 xservers running, so I don't require 12345676543234567654345676543456765432345678 [09:43] chesty: ah, that's your issue, 12345676543234567654345676543456765432345677 is prime [09:43] * Chipaca hasn't really checked [09:43] hehe, don't worry, I'm on the internet so I believe everything I read [09:44] I've now forwarded to all my facebook friends and they believe it too [09:44] * Chipaca becomes president of the american mathematical society [09:44] Chipaca: /tmp/.X11-unix/X12345676543234567654345676543456765432345678 as in nvidia prime? [09:46] and further more I didn't see any apparmor denies [09:46] or warnings, it was in devmode [09:46] alas, 12345676543234567654345676543456765432345677 = 7×13×1305511×602162345977×172575591847420434324601 (5 distinct prime factors) [09:46] chesty: wait [09:46] FAKE NEWS [09:47] chesty: if it's in devmode, nothing is blocking your x11 [09:47] Chipaca: unless it's x itself [09:47] chesty: and obviously x11 apps work snapped, you don't need classic for that [09:47] exactly [09:47] xhost + ? [09:47] no :-( [09:47] no xhost + [09:47] bad mborzecki [09:48] hehe :) [09:48] bad! [09:48] chesty: but, look at things that are not (strictly) snappy, for that denial [09:48] x2goclient worked, I could see its GUI, but I think it spawns nxproxy which couldn't open /tmp/.X11-unix [09:49] chesty: what happens without devmode? [09:50] I don't understand, I might have my terms mixed up, is devmode a confinement? [09:51] chesty: things are set up as in strict, but apparmor and seccomp use the unconfined profiles [09:51] * Chipaca thinks he got the terms right there [09:52] so when you say without devmode, I have to replace it with either strict or classic? [09:53] chesty: strict, is what i meant [09:53] classic is a different kettle of fish [09:54] ok, I'm rebuilding with strict. it's take a few minutes so I'll ping you when it's done [09:55] ok [09:56] pstolowski: conflicts in https://github.com/snapcore/snapd/pull/6071 [09:56] PR #6071: ifacestate/hotplug: updateDevice helper [09:56] chesty: also, you can snap install snappy-debug, then run "snappy-debug.security scanlog" in a terminal when you run your snap to see what it thinks is missing in your interfaces [09:56] mborzecki: thanks! will fix in a moment [09:56] chesty: https://docs.snapcraft.io/debugging-building-snaps/6274 [09:56] cheers popey, I actually stumbled on that last night [09:56] previously I was looking at dmesg [09:58] has anyone written a book yet on snapcraft? possibly hard to do atm being newish with lots of exciting changes, but I think I learn better from reading a book from page 1 to page 300. then I learn all the things I didn't know I needed to learn [10:00] chesty: ssh, don't say that too loud or degville might hear you and get ideas [10:00] being newish totally helps with that ... take notes on the side and once you are not "newish" anymore, write the book from the notes ;) [10:00] or what ogra said! [10:01] ah, son of a gun, I need to rebuild it with desktop-launch, I have no fonts atm. I'll pastebin my yaml while I'm at it [10:03] https://pastebin.com/Zc9zPw6M [10:03] I would make that command: desktop-launch $SNAP/bin/x2goclient (or whatever the path is to the executable) [10:04] chesty: you don't need an empty . in the description, in yaml [10:05] PR snapd#6078 opened: ifacestate/ifacemgr: don't reload hotplug-gone connections on startup [10:05] chesty: also your last two lines of the description are indented more than the first line, which might look odd [10:06] another weird thing I found after working around libssh was I was getting a message about libXcomp.so.5: file not found the file was there so I figured it was a shared library that was missing, I ran ldd on libXcomp and I added a bunch of debs explicitly in package-stage that made sure all the libraries were present that were listed in ldd and it f [10:06] ixed that problem [10:07] i wrote a simple script which turns the output of ldd into a list of debs if that's any use? [10:08] https://gist.github.com/85644e69b4e55eed782908a79d9ed208#file-lddtostage [10:08] just point it at a binary and it will spit out a bunch of deb names [10:17] I just had a black out. I'm back. thanks for the yaml tip Chipaca, the only reason I'm doing this is because x2goclient in 18.04 segfaults, and no one has responded to my bug report. I hadn't intended to upload it to the snap store, I'm just going to use it at work [10:18] chesty: got a link to the bug? [10:20] here's the one against the package in ubuntu I filed. https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1799849 [10:20] Bug #1799849: segfault when starting new session [10:20] I also send a message, not a bug report, to x2go people, last I check I hadn't got a reply [10:22] I think something changed in libssh threading, not sure though [10:30] I got a DENIED on /home/michaelc/.ssh/known_hosts but I didn't have the ssh plug listed, rebuilding [10:45] I love the "snap isn't working form me on WSL, what am I doing wrong?" bug report [10:45] guess what we'll need to do someday =) [10:45] Chipaca: +1 [10:45] the answer is "buy microsoft", if you were wondering [10:46] lots of DENIED messages https://gist.github.com/chesty/428ed208c467f7f4e20c1244cfc3210a there were more than these, this is just the last. the gui still loads with these messages [10:48] huh, i wonder why libuuid is blocked [10:48] doesn't make sense for those libs to be blocked [10:50] I added 2 entries regarding writing to known_hosts at the top of the file [10:52] I'll gist my current yaml, I'm doing something wrong with the plugs, they are being ignored https://gist.github.com/chesty/903cc48cca629ccab4d5447bae4091d4 [11:03] you are building this on 16.04, right chesty ? [11:04] in the docker image snapcore/snapcraft [11:05] DISTRIB_RELEASE=16.04 [11:05] ah okay [11:06] groovy [11:15] and I'm running it on DISTRIB_RELEASE=18.04 snap 2.36+git987.40fc2bf~ubuntu16.04.1 [11:15] I just noticed snap 2.36+git987.40fc2bf~ubuntu16.04.1 says ubuntu-16.04.1 but maybe that's right [11:20] * pstolowski lunch [11:25] oh traivs, y u so travis [11:25] Hey! I won't hear a bad word said about my mate travis! [11:26] * ogra senses a custard-pie battle dawning [11:38] Chipaca: is there any particular reason there is no --quiet option for snap install? [11:51] PR snapd#6079 opened: [RFC] `snap connections` command [11:51] low tech `snap connections`, RFC before I spend more time on it ^^ [11:55] mborzecki: nice! [11:56] i'll start looking into cross snap service ordering if nobody minds? [11:57] Chipaca: ^^ or is it something you wanted to look at? [11:58] mborzecki: it looks very promising [11:59] mborzecki: some ideas to think about: [11:59] mborzecki: add --system to show system connections, hide those by default [12:00] mborzecki: add "manual" note for non-auto connected stuff [12:00] mborzecki: add "never" note for manually disconnected stuff [12:01] mborzecki: add "content(foo)" note for content connections [12:01] mborzecki: add interface(foo) if plug or slot name doesn't match interface name, remove the interface column [12:01] zyga: manual is wip, some changes in the backend needed, i like the idea of adding 'never' for autoconnected but disconnected manually [12:01] mborzecki: that's all for quick ideas [12:02] mborzecki: some color coding or ordering could be tweaked for usability once we have a better feeling [12:02] but I think this is super nice [12:02] i'm sure Chipaca will have ideas about that :) [12:02] mborzecki: perhaps also add --gadget or similar for IOT devices [12:02] (like --system) [12:02] or a note about the fact that it was made by the gadget [12:03] zyga: right, connection made gadget is something we have in the backend too [12:05] mborzecki: some more ideas [12:05] allow showing attributes [12:06] including labels [12:06] and static / dynamic attributes [12:08] niemeyer: hey, did you ever get around to trying a fresh login to google for spread? [12:09] Hi snappy people, something is not right with snapd on debian 9. Just oppened forum topic https://forum.snapcraft.io/t/snapd-not-apt-installing-properly-on-debian-9/8240 [12:09] kjackal: thank you, we will check it out [12:09] zyga: Do we have an eta on the release of core? [12:09] kjackal: core snap? [12:09] yes [12:10] There is a fix on apparmor profiles that allows the deployment of kubeflow on microk8s [12:11] kjackal: is that 2.36? I think this is coming in ~2 weeks [12:12] In about two weeks, thank you zyga [12:12] kjackal: the problem you are experiencing is as follows [12:12] snapd in debian is very old but supports re-executing [12:12] if you install core it will automatically allow snapd to run a newer version of itself [12:13] if you install a snap by itself it will not work correctly because old snapd schedules the installation [12:13] well, if core was never installed before shouldnt the first snap trigger the core install first ? [12:13] I don't think we can fix this without updating snapd in Debian 9 [12:13] that doesnt seem to happen here [12:13] ogra: it does [12:13] ogra: but it doesn't mean new core will finish the installation [12:13] and this is what happens here [12:13] old core runs hooks [12:13] and things mishbehave [12:14] ah [12:14] zyga: Ok, so there are no plans in fixing this anytime soon? [12:14] well, i dont see anything mentioning the installation of core after the "sudo snap install microk8s --classic" ... usually it prints something about core when it pulls that in [12:15] kjackal: not that I know of [12:15] kjackal: you must first install core [12:15] kjackal: can you post "snap changes" [12:15] in that thread please [12:17] Done, on the thread and here: https://pastebin.ubuntu.com/p/HCzBFppdBs/ [12:18] zyga: should I try to address this on the snap side? Will this problem be present in other outdated distros? [12:18] kjackal: I don't believe you can do anything about that yourself from within a snap [12:19] ogra: ^ core is installed [12:19] zyga, well, in change 5 ... after a manual "snap install core" it seems [12:20] but not triggered by the installation of the microk8s snap [12:21] that's weird, [12:21] well, still [12:21] change #1 should normally trigger the installation of core ... at least it does on my systems when i set up something that never had snapd [12:21] we cannot do anything about old snapd [12:21] i bet it is the --classic switch that makes it not do that (but only guessing) [12:22] possibly [12:22] * zyga quick lunch ahead of dentist [12:31] Do we have other outdated distros? [12:42] mborzecki: hadn't we fixed the '(ssssa{ss})', does not match expected type '(sssa{sv}a{ss})' thing? [12:46] * Chipaca realises the time and rushes to make lunch [12:46] nope [12:46] kjackal: I think Debian 9 is special in this regard [12:47] cool, good to know [12:54] I wonder what /proc/version is on WSL [12:54] Chipaca: no, we switched to using busctl to get saner error messages [12:54] Chipaca: is it happening on 2.36 branch? [12:56] yes [12:57] i'll prep a pr with cherry pick of that change [12:58] (as it went away magically too) [13:00] mborzecki: standup? [13:01] and my speedup version thing broke the build somehow. possible the benchmark thing [13:01] cachio: ? [13:05] PR snapd#6080 opened: tests/main/interfces-accounts-service: switch to busctl, more debugging (2.36) [13:05] Chipaca: ^^ [13:16] mborzecki: kthx [13:20] mborzecki: I ticked the "allow edits from maintainers" box on my CUDA PR so you should be able to push to it. If you have time to take over that CUDA PR, go for it, I unfortunately haven't had time past few weeks. But I'm happy to run any tests in the background if you like, I have a few different NVIDIA cards I can test with [13:20] ijohnson: thanks, let me try pushing the branch now [13:21] ijohnson: aand pushed, yay! [13:22] ijohnson: was cuda test suite super slow for you when you ran it? [13:23] mborzecki: eh it takes maybe 10 minutes on my GTX 1050 but only took like 3 minutes on my titan X :P [13:23] but it shouldn't hang anywhere, do you know which test it was hanging on for you? [13:24] ijohnson: well, it appears stuck on my gt1030 :) [13:25] ijohnson: it runs a couple of tests and appears stuck, maybe it's still crunching some numbers though it must be doing that really slow [13:26] hmm that's unfortunate, but yes some of the tests are fairly intensive, but a 1030 should still be able to finish in a reasonablish amount of time. let me look at my test script and see how to make it more verbose on which test it's running so you can see which test it gets stuck [13:27] oh actually it should say which sample it's running by default: https://github.com/anonymouse64/cuda-samples-snap/blob/master/bin/test-cuda.sh#L110 [13:29] ijohnson: it does, and i'm apparently not smart enough to figure out that you should close the window that popped up :/ [13:30] ah yeah that's a thing you do have to close the windows it opens, I wasn't able to figure out how to automatically close the windows [13:31] ijohnson: anyways, loading nvidia-uvm and creating /dev/nvidia-uvm before i ran the samples did the trick [13:32] mborzecki: good to know, thanks for testing [13:36] Chipaca: so debian build also calls go generate then? [13:36] mborzecki: yes [13:37] mborzecki: export DH_GOLANG_GO_GENERATE=1 [13:37] mborzecki: in debian/rules [13:37] Chipaca: interesting [13:37] PR snapd#6081 opened: overlord/ifacestate: mark connections disconnected by hotplug with hotplug-gone [13:38] heh, go geneate ./... and i learned about snap blame [13:38] so it then runs this monster of a command [13:38] mborzecki: look for 'go generate' in https://api.travis-ci.org/v3/job/448506794/log.txt [13:39] Chipaca: wow, looks like `go generate $(go list ./...)` [13:39] mborzecki: you didn't know about snap blame? :) [13:39] mborzecki: with extra pie [13:40] Chipaca: no i didn't, but now snap blame told me it's my fault :) [13:40] mborzecki: it's obviously working correctly [13:40] Chipaca: i know [13:40] grah, another 2.36 failure: https://api.travis-ci.org/v3/job/448204858/log.txt [13:41] Chipaca: hm some people appear to me more at fault than others, though my N=20something [13:41] mborzecki: shocking [13:41] zyga: another report re https://forum.snapcraft.io/t/cant-connect-interfaces-so-cant-run-snaps/8123/15 , can you comment on the fix? [13:56] mborzecki: more pain from the generator :-( [13:56] Chipaca: uhh, logs? [13:56] dh_install: usr/bin/chrorder exists in debian/tmp but is not installed to anywhere [13:56] oh, wow so it also does go install ./... ? [13:56] yar [13:57] mborzecki: do any of the other distros? [13:57] not that i've seen [13:57] Chipaca: fedora, arch and suse call go build -o ... [13:59] Chipaca: it'd be fun to package a project with multiple small development tools [14:00] I don't know how to tell dh_install to ignore this file [14:00] hmm [14:00] can yuu remove it afterwards? [14:00] ah got it [14:00] we're already removing several [14:00] mborzecki: look at override_dh_install in debian/rules fwiw [14:02] Chipaca: mhm, we do some cleanup there already [14:03] Re [14:04] pstolowski: looking [14:06] Done [14:08] thanks [14:08] off to pick up the kids [14:27] * cachio afk [14:31] * Chipaca afk [14:32] cachio: FYI, Fedora 29 is out [15:49] PR snapd#6082 opened: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots [15:56] PR snapd#6080 closed: tests/main/interfces-accounts-service: switch to busctl, more debugging (2.36) [16:02] PR snapd#6073 closed: strutil: let MatchCounter work with a nil regexp [16:03] * Chipaca <- dumb [16:03] forgot to apply the delta to 1404 rules [16:15] zyga: I changed #6060 to use the new nil regexp support in MatchCounter, if you could give it a second look sometime [16:15] PR #6060: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 [16:18] rbasak: hey! You done with your SRU work for today? [16:18] Eeek, wrong channel [16:18] (please ignore) [16:22] Saviq, hi, I alerady created the fedora 29 image [16:22] I am fixing some issues araoung this now [16:22] but you can try it [16:30] Chipaca +1 [16:30] approved :) [16:37] cachio: thanks, I'll try and add it to our CI - still can't try locally, couldn't get the right login credentials (or I've not enough privileges - Gustavo was looking into that) [16:50] https://github.com/snapcore/snapd/pull/6074/files#r229779158 ? [16:50] Chipaca: ^ [16:50] PR #6074: strutil: make VersionCompare faster [16:50] zyga: we usually do, yes [16:50] usually? [16:50] do we have any other files that we commit and generate? [16:51] zyga: in all other cases where the file is generated, it's committed, afaik [16:51] hmmm [16:51] I don't suppose this file will change [16:51] but I find it odd [16:51] it's generated for a reason, why keep it in VCS? [16:51] perhaps excepting cmd/version_generated.go [16:52] drat, I have to go now [16:52] sorry, I'll pick up reviews later [16:52] zyga: what do you think about #6077 ? [16:52] PR #6077: overlord/ifacestate: use map[string]*connState when passing conns around [16:54] zyga: one reason for committing generated files is that without it you can't 'go get' the repo [16:55] unless the code has been prepared for it (in this case it hasn't) [16:55] zyga: what cmd/version_generated.go is populate a variable that's set elsewhere, so that one's ok [16:55] zyga: if you don't have the generated file, you get version "unknown" [16:57] pstolowski: approved, thank you [16:57] thanks! [16:57] Interesting Chipaca, I didn’t know that [16:57] It makes sense to commit based on this information [16:59] grah [16:59] debian now fails on 'systemctl restart snapd.socket' for no reason [17:01]