=== JoshStrobl is now known as JoshStrobl|zzz [06:00] good morning [06:01] hey mvo :) [06:01] pedronis: fwiw, the errors during build are "settle is not converging" so your theory about the time being too low seems to be correct (for the armhf build failure) [06:03] hey zyga-ubuntu [06:05] PR snapd#3909 opened: daemon: remove unused installSnap var [06:08] PR snapd#3910 opened: snap-repair: fix test failure in TestRepairHitsTimeout [06:50] PR snapd#3911 opened: many: add logger.MockLogger() and use it in the tests [07:09] * mwhudson o/ [07:10] hey mwhudson [07:17] * zyga-ubuntu has a sad face at ext4 corruption on his artful box [07:19] in other news seagate disks are still seagate [07:22] hey pstolowski [07:23] zyga-ubuntu, morning! [07:46] PR snapd#3900 closed: snap-seccomp: manually resolve socket() call in tests [07:48] PR snapd#3891 closed: daemon: reach for Overlord.Loop less thanks to overlord.Mock [08:15] * zyga-ubuntu -> quick walk === JoshStrobl|zzz is now known as JoshStrobl [08:42] pedronis, zyga-ubuntu hey guys, do you have a moment for quick HO? [08:43] popey: Hi! Mind taking a look at https://dashboard.snapcraft.io/dev/snaps/8349/rev/1/ ? [08:43] it just uses the snapd-control interface [08:44] pstolowski: yes [08:49] let's wait for zyga-ubuntu [08:50] pstolowski: yes [08:51] pedronis, zyga-ubuntu https://hangouts.google.com/call/IDjZPuXPNW1dCKRuMO8sAAkI === chihchun_afk is now known as chihchun [08:54] PR core#59 opened: fix object path used by usr/bin/xdg-open in core [09:01] * Son_Goku gurgles awake [09:02] zyga-ubuntu, can you *please* test the new snapd in Fedora? [09:02] https://bodhi.fedoraproject.org/updates/FEDORA-2017-4546b9dd38 (F27) [09:02] https://bodhi.fedoraproject.org/updates/FEDORA-2017-8ef8c9e6c2 (F26) [09:03] https://bodhi.fedoraproject.org/updates/FEDORA-2017-d699df2619 (F25) [09:07] zyga-ubuntu: I've got the docs update waiting for it: https://github.com/CanonicalLtd/snappy-docs/pull/103 [09:07] PR CanonicalLtd/snappy-docs#103: Update Fedora snapd to 2.27.6 [09:12] Son_Goku: hey [09:13] zyga-ubuntu: I've also got hughsie waiting for it because GNOME Software things [09:13] Son_Goku: yes, I'll test them immediately [09:13] Son_Goku: I also saw the golang import was changed in the repos [09:13] Son_Goku: so we might be able to test that and land your other branch [09:13] it's in updates-testing, yes [09:13] well, my current stuff is landed [09:13] because the CI was going to fail going forward anyway :) [09:21] niemeyer: thank you for the review on #3866! good stuff [09:21] PR #3866: many: implement fetching sections and package names periodically [09:31] Son_Goku: updating F26 now, I'll test it when it is ready [09:33] PR snapd#3912 opened: asserts: add empty values check in HeadersFromPrimaryKey [09:52] mvo, hi, any chance your PR can be merged today? :) [09:52] Son_Goku: ok, testing F26 now [09:57] ackk: #3908 has one review already, if e.g. Chipaca does another one it can go in. there is an open question about a small detail raised by niemeyer but I think the overall direction is good so hopefully it lands today [09:57] PR #3908: snap-seccomp, osutil: use osutil.AtomicFile in snap-seccomp [09:58] nice, thanks [10:07] Chipaca: hi, #3908 seems something you could review [10:07] PR #3908: snap-seccomp, osutil: use osutil.AtomicFile in snap-seccomp [10:07] pedronis: sorry, can't review things twice :-p [10:07] (i _just_ did it) [10:09] PR snapd#3909 closed: daemon: remove unused installSnap var [10:09] mvo: are we sure in #3910 that 100ms is enough ? [10:09] PR #3910: snap-repair: fix test failure in TestRepairHitsTimeout [10:10] pedronis: no, this is just a guestimate, I figured 10x than before is hopefullyok [10:10] hopefully ok even [10:15] hmm, gnome shell crashes sometimes :/ [10:16] PR snapd#3912 closed: asserts: add empty values check in HeadersFromPrimaryKey [10:25] * ogra_ gllares at https://github.com/snapcore/core/pull/59 and wonders why it works for him even without that change [10:25] PR core#59: fix object path used by usr/bin/xdg-open in core [10:28] mvo, seeing that, it shouldnt work at all for me, should it ? [10:29] * ogra_ is confused [10:30] ogra_: yes, it should not work if you have the 2.28 debs === ShalokShalom_ is now known as ShalokShalom [10:30] ogra_: does it work with those? [10:30] it wrks with the 2.27 debs and yoour test core from candidate [10:30] ogra_: the fallback (snapd-xdg-open) launcher will work [10:31] ah ! [10:31] ok [10:31] ogra_: yeah, that is ok, then you are using the fallback [10:31] thats clears my cooonfusion :) [10:31] ogra_: tests ftw :) [10:31] * mvo will write some more today [10:31] :) [10:37] wrz 13 12:37:26 fyke gnome-shell[1591]: Failed to apply DRM plane transform 0: Brak dostępu [10:37] hmmm [10:37] Brak dostępu = no access/permission denied [10:45] is repowerd nuts? [10:45] wrz 13 12:44:21 fyke sudo[24161]: pam_unix(sudo:session): session opened for user root by (uid=0) [10:45] wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(c1,/org/freedesktop/login1/session/c1) [10:45] wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: activate_session(c1) [10:45] wrz 13 12:44:38 fyke sudo[24161]: pam_unix(sudo:session): session closed for user root [10:45] wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(13,/org/freedesktop/login1/session/_313) [10:45] uhm, I'm getting "AttributeError: /home/ack/virtualenv/snapcraft/bin/python: undefined symbol: archive_errno" in snapcraft master [10:45] wrz 13 12:44:38 fyke repowerd[940]: LogindSessionTracker: activate_session(13) [10:45] every time I close my root shell it does this [10:57] Son_Goku: send F26 feedback [11:16] PR snapd#3910 closed: snap-repair: fix test failure in TestRepairHitsTimeout [11:18] mvo, popey: can you have a look at https://forum.snapcraft.io/t/auto-connecting-interfaces-for-easy-openvpn-snap/2029/3 and give +1 if you're fine? saw you're listed as store reviewer [11:18] * popey looks [11:24] mvo: on zesty with wayland I don't get gnome shell to find any snap desktop files [11:25] mvo: not sure if regression but annoying [11:25] mvo: /home/zyga/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/ [11:25] this is XDG_DATA_DIRS [11:25] zyga-ubuntu: is it this, or related? https://forum.snapcraft.io/t/desktop-file-names/2096/2 [11:25] zyga-ubuntu, isnt the PR fr that still open ? [11:25] how come flatpak is there but snapd is not [11:26] hmm https://github.com/snapcore/snapd/pull/3398 says merged [11:26] PR #3398: env: set XDG_DATA_DIRS for wayland et.al [11:26] pedronis: also annoying but does not seem related [11:27] ah, zesty though?  not artful? [11:27] does it work on artful? [11:27] do we even support walyand officially on zesty? [11:28] pedronis: yes [11:28] pedronis: it works but I'm on xorg there due to GPU [11:28] pedronis: so s/yes/maybe/ [11:28] it's in the environment for sure but I'm running xorg, not wayland [11:28] well, the above PR fixes it ... but i'm not sure it is anywhere else but master yet [11:29] ogra_: I'm running master [11:29] ogra_: maybe I need to tweak something [11:29] * zyga-ubuntu looks [11:29] I probably didn't install data files [11:29] well, you should have a snapd.sh in /etc/profile.d [11:30] (are you running the master *deb* ?) [11:30] I have apps-bin-path.sh [11:30] ogra_: no, that's the problem [11:30] :) [11:30] just create the .sh file from the PR [11:30] (and re-login indeed) [11:31] ok, tweaked [11:31] yep [11:31] brb [11:31] my open terminals :'(( [11:31] yeah ... we should really have a "save session per terminal" feature :) [11:31] I used :mks in vim [11:31] but not other places [11:31] gnome used to have this but then nobody did it correctly so it was removed [11:31] that still only gives you one bash histroy :) [11:32] (and ironically then apple did it) [11:32] so maybe gnome will do it now again [11:32] well [11:32] brb [11:32] i want each term pop up where it closed ... with the same histry it had [11:33] well, that worked [11:33] :) [11:35] heh ... https://massdrop-s3.imgix.net/product-images/massdrop-x-oblotzky-sa-oblivion-custom-keycap-set/sa_oblivion_kit_04_git_modifiers_20170828131112.png?auto=format&fm=jpg&fit=crop&w=924&dpr=1 [11:35] Chipaca: what did I do wrong: "snap refresh -> all snaps are up to date"; "snap refresh core -> working on core refresh" [11:35] Chipaca: bug? feature? [11:36] stop using core in devmode ? :P [11:36] what ogra_ said [11:36] Chipaca: and core was in devmode for ? reasons [11:36] how is that possible [11:36] (i was joking ! ) [11:36] zyga-ubuntu: wasn't it? [11:36] (this is on debian) [11:36] zyga-ubuntu: without seeing what we told the store and what the store replied i have no idea [11:37] Chipaca: where is devmode listed [11:37] snap list [11:37] Chipaca: I bet this is local and the fact that core was in devmode [11:37] zyga-ubuntu: you have debug logs on, right? [11:37] zyga-ubuntu: if core is in devmode it's because you installed it in devmode [11:37] core was auto-pulled on 1st snap [11:38] then it shouldn't be in devmode [11:38] zyga-ubuntu: show me the logs [11:38] Chipaca: https://paste.gnome.org/paaya4wqy [11:38] (does core in devmode even make any sense ?) [11:38] I haven't got more than this so far [11:38] zyga-ubuntu: journalctl -u snapd ? [11:39] https://paste.gnome.org/psr27grjj [11:40] zyga: zyga-ubuntu: why aren't you running with debug :-( [11:40] hold on, https://paste.gnome.org/pjorsj5aj [11:40] Chipaca: because I just booted that, sorry, [11:40] zyga: turn on debug and try to reproduce? [11:41] zyga: in particular i need the SNAPD_DEBUG_HTTP=7 as well as SNAPD_DEBUG=1 [11:41] while you do that, i'm going to lunch [11:42] Chipaca: reproduced [11:42] https://paste.gnome.org/pbsnaw5lx [11:42] I reverted, set the environment, restarted snapd, did refresh (all) again [11:46] zyga: so that's just for 'snap refresh', right? [11:48] does network-bind also allow to create unix sockets? [11:50] zyga: what revision of core do you have? [11:50] zyga: nm, i see it in the other paste [11:50] zyga: so, the store is very clearly telling us to refresh core [11:51] zyga: we're saying we have rev 2774, it's saying there's 2844 available, and here is the delta for going from 2774 to 2844 [11:52] now for real, i need to go make lunch [11:52] zyga: (just in case i wasn't clear: BUG IN SNAPD) [11:52] :-) [11:52] * Chipaca lunch [11:55] Chipaca: thank you! [11:57] * zyga-ubuntu -> lunch [12:32] PR snapd#3913 opened: tests: add test that ensures that all core services are working [12:37] Pharaoh_Atem: https://taskotron.fedoraproject.org/artifacts/all/f04e1f84-9873-11e7-89a8-525400817a8f/task_output/snapd-2.27.6-1.fc26.log ? [12:37] exit [12:38] meh === jdstrand_ is now known as jdstrand [12:38] jdstrand: :) [12:58] jdstrand, have you seen https://forum.snapcraft.io/t/hdmi-audio-on-db410c-not-working/2106 ? (i wonder if the alsa interface needs to support sockets or if alsa-utils needs network interface support ... though i'm not sure if that has any influence on the functionality) [13:00] zyga-ubuntu: the f27 update needs karma: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4546b9dd38 [13:00] aha [13:00] I'll try to test it too [13:03] f25 has the same problem: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d699df2619 :) [13:03] yep, I have that too [13:08] Hi all, after noticing an error in systemd journal about snap-repair, I looked at https://git.launchpad.net/snapd/tree/data/systemd/snapd.snap-repair.service.in and noticed that is already fixed in git by adding ConditionKernelCommandLine=snap_core to the unit file. So all good in that respect. Just wanted to report a possible typo in the same file. Last line (10) mentions "Environment=SNAP_REAPIR_FROM_TIMER=1", which I assume is meant t [13:08] o be "Environment=SNAP_REPAIR_FROM_TIMER=1" instead? [13:08] oh [13:09] glimcoil: yes that looks like a typo [13:09] mvo, pedronis: ^ [13:09] seemed a bit silly to file a bug report on a typo, thought I would mention it here first [13:10] unless its a super hidden acronym [13:10] like.. Rest Easy As Paddy Invokes Republicanism [13:11] * ikey had little to go on. :P [13:11] ikey: possibly, I'm not at all familiar with the code [13:11] looks typo-y [13:12] nor with Republicanism :p .. but that's a minefield I'm not getting into [13:12] xD [13:20] we'll just fix the oxford dictionary and add an alias ! [13:39] cachio: if you have a working aarch64 sysstem, could you please paste me the output of "SNAP_SECCOMP_DEBUG=1 /usr/lib/snapd/snap-seccomp compile <(echo mknod) /tmp/xxx" (or anyone else with an arm64 system) [13:40] mvo, one minute [13:40] cachio: no rush, thanks a lot! [13:45] pstolowski: btw, I was thinking that maybe it's easier to split switching from PlugInfo to PlugData, in two parts, first part Plug/SlotData has the same definition as Plug/SlotInfo (only difference is we make a deep copy of attrs when we make PlugData), so in a lot of places is just a rename, 2nd phase we give PlugData its real interface [13:48] mvo, https://paste.ubuntu.com/25527599/ [13:48] cachio: \o/ thank you so much [13:48] mvo, np [13:49] cachio: oh, this is amd64, right? I need it for arm - aarch64, the dragonboard [13:50] ahh, one minute [13:51] mvo: I thought we had fixed the issue of quoting on "snap info" [13:51] niemeyer: I thought so too, let me look [13:51] mvo: But it seems that 2.27.6 is still quoting all summaries.. [13:52] niemeyer: that was pr 3610 [13:52] PR #3610: snap: do not always quote the snap info summary [13:53] niemeyer: let me check what is going on [13:53] mvo: hi! hey so - check an api response to https://api.snapcraft.io/api/v1/snaps/details/$SOME_SNAP. We're now exposing "contact" - the field was renamed in the web UI to "Contact URL" (can be either http{,s} or mailto url) [13:54] roadmr: nice! [13:54] mvo: so for now and for backward-compatiblity it has the same info as support_url, but that'll eventually be deprecated [13:54] roadmr: sounds good, thanks for adding this [13:54] note though the API response's field is called simply "contact", not "contact_url" [13:54] mvo: thank matiasb_, he did it all :) [13:54] * mvo thanks matiasb_ [13:56] mvo: Yeah, clearly recall discussing this in the sprint and looking at that code [13:56] It's even tested.. wtf [13:56] niemeyer: I have exactly the same feeling [13:57] niemeyer: looks like 2.27 does not have it yet [13:57] niemeyer: if you switch to edge it seems to be ok [13:58] mvo: Wow.. wat [13:58] niemeyer: yeah, huge latency :( [13:59] ogra_: do you know if we have a git branch for initramfs-tools-ubuntu-core? [13:59] mvo: Yeah, I hadn't realized (or internalized) that the dots were not really catching up [13:59] mvo, under core-build [14:00] niemeyer: I am surprised about the delay too, we need to get to 2.28 to be vaguely back on track [14:00] ogra_: ta [14:01] mvo, https://paste.ubuntu.com/25527679/ [14:01] mvo, on my db [14:02] cachio: thank you, that is very interessting [14:02] mvo, yaw [14:07] re [14:07] Chipaca: FYI the debug logs above were not useful because we had reverted, earlier change where the core did not refresh is real but we don't have a case for reproducing that yet [14:10] jdstrand: hey, just a quick note, I'm still going through the review, using code from libsnap-confine-private in snap-update-ns bootstrap.go is rather painful because of how linking in go build works [14:14] jdstrand: any code sharing between is in general a global pain [14:15] PR core-build#20 opened: ubuntu-core-rootfs: deal with (broken) symlink in sync_dirs [14:20] mvo, approved ... (needs a manual deb build and PPA upload) [14:20] oh ... and a kernel snap rebuild too indeed [14:21] mvo: for testing, you _might_ explore the initramfs test tools I wrote [14:21] mvo: but it could be time consuming to learn how to use it initially [14:22] * ogra_ looks forward to split-initrd ... that will save so much timt [14:22] *time [14:22] (just waiting to get my splash PRs all approved before landing that one) [14:24] mvo: let me know if you want to try that and need a hand [14:24] pedronis, that could make things a little bit easier, but I'm not too keen on that. anyway, thanks for the suggestion [14:27] * zyga-ubuntu is hungry-ish and considers breaking now, doing some office manintenance and then sitting with jdstrand for a quick chat about bootstrap.c [14:27] jdstrand: would you have some time to discuss those points? [14:28] zyga-ubuntu: I have an appt and about to step out [14:28] jdstrand: are you going to be back today? [14:28] zyga-ubuntu: yes, in ~3 hours [14:28] PR snapd#3914 opened: snap-seccomp: skip mknod syscall on arm64 [14:28] zyga-ubuntu: was there a contentious point in my feedback? [14:33] jdstrand: not sure, I think I just want to chat about each and explain what happened [14:33] jdstrand: and discuss possible approaches [14:33] jdstrand: mainly that reusing code from other parts is hard [14:33] jdstrand: but anyway [14:33] jdstrand: my wife just called me and I need to break for ~3 hours too [14:33] so let's talk later :) [14:36] zyga-ubuntu: note, I wasn't blocking on that [14:36] but sure, 3 hours [14:41] jdstrand: if those are not blocking can we land and iterate? [14:42] there was a lot more to my comments than code factoring [14:42] but if you do those things, sure [14:42] * jdstrand -> appt [14:42] k [14:45] niemeyer, it seems ubuntu.rocket.com has an expired cert [14:45] Err, other way... you get the idea. No coffee yet [14:46] kyrofa: :) [14:46] kyrofa: I can't fix that one I think.. but let me look [14:48] Since we use HSTS, I can't even add an exception for it [14:48] i just clicked on "yes" when the question about the cert popped up [14:49] didnt you get that popup ? [14:49] (that should add the exception client side) [14:50] (/me notes that kyrofa perhaps doesnt use the rocket client snap though) [14:51] ogra_, no, firefox [14:51] ah [14:51] yeah, that might treat it different indeed [14:51] The fact that the client doesn't obey HSTS probably isn't a good thing [14:52] yeah [14:55] kyrofa: Yeah, I can't do much about it [14:55] niemeyer, is that IS? [14:56] kyrofa: I have only admin access to the software, but not to the system, and I think the cert is done via nginx [14:56] kyrofa: yeah, I would try there first.. [14:56] kyrofa: They will at least know how runs it [14:56] who [14:56] It was sabdfl originally, but I'd be surprised if it was still there [15:04] oh, actually, the rocket desktop client only works half now after restarting it [15:05] no graphics at all [15:05] Interesting [15:05] hmm, a second restart fixed it [15:05] weird === cachio is now known as cachio_lunch [15:45] ogra_ retrying enough made it work for me [15:45] and yes, the cert expired at ~noon utc today [15:45] yeah, it works here as well again === chihchun is now known as chihchun_afk [16:08] ogra_, in the gadget snap would not it make sense to pin down specific revisions for the components that are built from source? [16:09] sborovkov_, we do that ... [16:10] git clone --depth=1 https://github.com/raspberrypi/firmware.git -b "1.20170515" .... [16:10] source: git://git.denx.de/u-boot.git [16:10] + source-branch: v2017.05 [16:10] in https://github.com/snapcore/cm3-gadget/pull/1/files [16:10] PR cm3-gadget#1: build uboot from source, pull blobs from upstream, use dtbs from archive [16:11] ogra_, not for psplash though? [16:11] well, psplash doesnt really change in the tree we pull it from (and i'm not sure they even use tags or branches) [16:11] but yeah, one could do that [16:14] the prob is that psplash doesnt really have any upstream anymore ... poky itself is dead and got merged into yocto [16:15] we could as well, just fork it into a GH tree [16:15] Ah ok. Just to make sure it does not actually point to something else [16:15] as it uses master [16:17] http://git.yoctoproject.org/cgit/cgit.cgi/psplash [16:17] there are hHEAD and master ... but they are identical [16:18] ogra_ yeah but repo is alive, last commit from 12 days ago. So something might get broken at one point [16:18] long term it probably makes sense to carry our own tree but i dont think it is super important [16:19] did you have any issues building ? === cachio_lunch is now known as cachio [16:19] no :-) I am just being bothered by people on code review who want to pin every possible thing down to specific version :-( [16:22] zyga-suse: how does arch define what files get removed when you remove a package? [16:25] sborovkov_, https://github.com/ogra1/psplash ... i promise i wont change it :P [16:26] sborovkov_, you can use the 09.2017 tag in your gadget now [16:30] zyga-suse: also, is %dir documented anywhere? i guess it does what i want but i'm just guessing [16:30] ogra_ ok thanks === JanC is now known as Guest39146 === JanC_ is now known as JanC [16:59] zyga-suse: o/ [16:59] zyga-ubuntu: or you :-) o/ [17:00] 2.28~rc3 in the beta channel now and rc3 builds in xenial,zesty,artful,trusty everywhere so yay progress [17:01] \o/ [17:01] mvo: Thanks! [17:01] zyga-suse: karma for Fedora updates? [17:01] I only see F26 [17:02] I need some for F25 and F27 [17:03] mvo, did you add the fixes for failover and install-store tests? [17:04] cachio: if there were tagged with 2.28 then yes, if not then no :) if there were not tagged, could you please give me the PR numbers and I can look at this in my morning [17:04] sure [17:05] mvo, let me search forthem [17:07] Chipaca: hey [17:07] zyga-ubuntu: dunno if you saw my questions to your alter ego [17:07] Pharaoh_Atem: soon, I had to go out [17:07] zyga-ubuntu: does arch have a way of saying what needs to be done to remove the package? I can't see it [17:07] Chipaca: no, but if you sent them to zyga-suse then I can see them in 2 minutes [17:07] Chipaca: just pulling over now [17:07] zyga-ubuntu: and the second question was whether opensuse's %dir was documented anywhere [17:08] Chipaca: I suspect so [17:08] one sec [17:08] i'm guessing at opensuse needing a "%dir /var/cache/snapd" [17:08] Chipaca: https://en.opensuse.org/openSUSE:Packaging_guidelines [17:08] look for %dir [17:10] zyga-ubuntu: yeah, i'd gotten to this page on my own, but it doens't really tell me if %dir means the directory will be cleaned up on remove [17:10] Chipaca: I think so but let me do an experiment [17:11] Chipaca: I just need to put the groceries where they belong [17:11] zyga-suse: and i need to get the fish to hug the broccoli [17:11] zyga-suse: but i'll leave this on and read it when i get back [17:12] if the directory is created by snapd package, it'll be removed by it, if there's no contents inside [17:12] http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DIR-DIRECTIVE [17:13] Pharaoh_Atem: and if it has contents? [17:14] Chipaca: fine [17:15] PR snapd#3911 closed: many: add logger.MockLogger() and use it in the tests [17:17] Chipaca: I think it will not remove it [17:18] though I'm not sure [17:18] it may choose to delete it since it doesn't know what's in it [17:29] PR snapd#3915 opened: cmd/snap: return empty document if snap has no configuration === JanC_ is now known as JanC [18:11] hey snappers, should i be able to share $SNAP_USER_foo with the content interface? my slot can define "read: $SNAP" and a plug works as expected.. but when i use "read: $SNAP_USER_COMMON", i get this, as if $SNAP_USER_COMMON is being taken literally: [18:11] $ snap run --shell pig [18:11] cannot perform operation: mount --bind -o ro,nosuid,nodev /snap/hadoop/x1/$SNAP_USER_COMMON /snap/pig/x1/hadoop: No such file or directory [18:13] just use the home interface, it should have access to all non dot dirs in your home already [18:14] (SNAP_USER_COMMON in the above case is ~/snap/pig/common ) [18:16] oooh! gotcha ogra_. /snap/hadoop/x1/$SNAP_USER_COMMON threw me off, but it makes sense that it's USER_blah in the context of the pig snap. [18:16] thanks! [18:18] if you have a hadoop snap and want to access the user specific data, the home interface should give you access to ~/snap/hadoop/current (or ~/snap/hadoop/common) as long as no hidden dir is involved [18:19] yup, +1 [18:31] PR snapcraft#1540 closed: plugins: extract python finder functions [18:39] PR snapd#3913 closed: tests: add test that ensures that all core services are working [18:46] PR snapcraft#1547 opened: plugins: extract sitecustomize logic from python [18:55] does Ubuntu Core have dbus ? [19:04] jdstrand: howdy, click-reviewer-tools r930 is now live [19:09] niemeyer, in the configure hook, is there any way to compare new values to old? Or is it still always new? [19:10] kyrofa: Still always new.. [19:10] kyrofa: Really want to do something about that [19:10] Ideally with deltas rather than just what's new and what's old [19:10] Config has a lot of love to receive still [19:10] Indeed [19:10] Alright, thanks! [19:13] roadmr: woo, thanks! [19:14] roadmr: kenvandine fyi, that has the desktop and desktop-legacy interfaces ^ [19:14] jdstrand: hehe you lucked out as usual, not many changes to deploy [19:14] PR snapd#3880 closed: tests: add trivial canonical-livepatch test to ensure we do not break it [19:14] roadmr: I'm curious now what we'll see with those occasional unexpected outputs [19:14] \o/ [19:15] jdstrand: yeah... not sure :( if it doesn't have the thing in the json that causes the store to consider it failed, it'll likely just be noted as another test and stored in the output [19:16] jdstrand, woot [19:30] roadmr: it will show up as an error, which will flag manual review, so I'll see it [19:31] roadmr: that is for anything that calls error(). if we see 'unexpected output' after this, there are only a couple of things it could be [19:33] jdstrand: ah! I get it now. [19:48] kyrofa: anything i can do to help move along https://bugs.launchpad.net/snapcraft/+bug/1686481 ? [19:48] Bug #1686481: stage-packages doesn't respect architectures [19:49] this bug prevents us from getting snap builds in upstream kubernetes [19:51] Not directly, we've been revamping that part of the codebase, I need to test again with the new changes [19:51] om26er, you have a dbus interface, see https://snapcraft.io/docs/reference/interfaces [19:51] om26er, does it work for you? [20:01] tvansteenburgh, it would be helpful if you're able to test with the newest snapcraft, if you're able, v2.34. It's in artful, and -proposed for z and x [20:01] Huh, I don't think I could have written that sentence worse [20:01] Changed gears partway through apparently === nacc_ is now known as nacc [20:08] kyrofa: okay thanks [20:15] cachio: yes that interface does work. My need was only related to getting the machine-id [20:15] and it seems I can just read /etc/machine-id even in a confined snap. [20:22] PR snapcraft#1541 closed: tests: fix the TEST_STORE environment variable === JoshStrobl is now known as JoshStrobl|zzz