[00:07] wililupy, is there a switchdev version of your code? [00:08] sabdfl: no. This is all based on OpenNSL and OpenNetworkLinux.org kernel source. [00:09] ok, if there are generally-useful modules we will carry them in the common kernel, otherwise making your own kernel snap is pretty easy [00:09] * ahoneybun bangs head on desk [00:09] ahoneybun, its very satisfying when you get to full confinement :) [00:09] I'm just getting started with snappy. Can someone explain this to me? http://pastebin.com/yMDSMNZv [00:10] sabdfl, it's not past even opening up yet [00:10] no devmode is whole different beast [00:10] leftyfb, what's in /snap/bin/ ? [00:11] sabdfl: as, so there it is. I guess I have to add /snap/bin to $PATH? [00:11] yes, i'm trying to figure out why i never had to do anything special for that [00:12] sabdfl, can't even find why it runs on my machine but not the snap [00:12] basically, snapd parses the snap metadata (snap.yaml) and it creates things in /snap/bin/ so you get them on your $PATH [00:12] leftyfb: where were you installing it? 16.04? [00:12] nacc: yes [00:12] nacc: recently upgraded from 14.04 [00:13] leftyfb, I have /snap/bin/ as the last item in $PATH but i'm not sure where that is set [00:14] i know the recend sudo update added it for the sudo case [00:14] sabdfl: usually ~/.bashrc and/or ~/.profile [00:14] looks to be /etc/profile.d/apps-bin-path.sh [00:14] from snapd package [00:14] thanks nacc [00:15] ahoneybun, as you can see you are better off with nacc's help than mine :) [00:15] sabdfl: np, wondered the same thing myself :) [00:15] I think I throw nacc off too lol [00:15] the libs are there [00:15] no idea if the snap is looking in the wrong place or what [00:15] leftyfb: odd that your profile isn't sourcing that, wonder if it's a quirk of the upgrade [00:15] ahoneybun, what's the name of the snap? [00:16] Pithos [00:16] the pandora player client [00:16] trying to snap the new 1.2.1 build [00:16] nacc: any idea where that should be sourced? Something in /etc/ * assume [00:16] i think there is a way to get a shell with the same confinement.... 'snap run --shell pithos' perhaps? [00:16] leftyfb: iirc, /etc/profile sources any .sh files [00:17] leftyfb, what's your $SHELL? [00:17] ooh Pithos would be a great snap :) [00:17] I love it [00:17] tsimonq2, if I could get it to start at all [00:17] sabdfl: bash [00:17] leftyfb, oh well if you want to go using weird stuff like... [00:17] * ahoneybun found a inkscape snap today [00:18] ahoneybun: let me know :) [00:18] know what? [00:18] when you get it working [00:18] o/ sabdfl, how are you? :) [00:18] that might be the 1.2.3.... or on release ll [00:18] ahoneybun, can you stick a bin/bash in your snap? then the snap run --shell cmd will work iirc [00:18] tsimonq2, good thanks, you? [00:18] what sabdfl ? [00:19] great sabdfl :) [00:19] yeah, it's odd. It looks like I'm not sourcing /etc/profile.d/apps-bin-path.sh even when logging out and back in [00:19] ahoneybun, are you the author of this snap, or just consuming it? [00:19] tsimonq2, I think gi.repository is a python thing [00:19] sabdfl, I did not write the app, just trying to make it a snap [00:19] not in store so I assume you are making the snap? [00:19] right [00:20] you can add a command to the snap, which is a shell [00:20] but what help does that give me? [00:20] i think you basically can just copy /bin/bash into your snap at bin/bash [00:20] leftyfb: very strange, is this in your /etc/profile ? http://paste.ubuntu.com/23071877/ [00:20] i think it will let us debug things more easily [00:20] aiui you have a problem with python not finding a lib [00:20] ahoneybun: it would let you drop into the snap's env and then you can try to figure out what your snap's executable is seeing [00:21] I don't get the error on my machine so it must be missing a package [00:21] nacc: yes [00:21] ahoneybun: or in this , not seeing :) [00:21] that will be easier to debug if we can pretend to be python and go looking for it [00:21] mm go on sabdfl ;) [00:21] leftyfb: really strange! [00:21] basically, each snap runs in its own little world where it sees glimpses of what other snaps provide [00:21] how do I add this? [00:21] it sees a glimpse of the core snap ("ubuntu-core") and it sees its own files [00:22] and it may see things from other snaps too (thats what plugs and slots do) [00:22] those pieces are arranged so that the snap can get on and do what it does but not taint any other snap [00:22] ahoneybun: you'd add another 'app', i think, say 'pithos-shell' which just runs bash, and add a part that copies your system's /bin/bash into the snap, i believe [00:22] nacc, we should definitely make this a built-in thing so you don't need the boilerplate [00:23] sabdfl: absolutely, esp. in devmode :) [00:23] nacc: yep. I've noticed a few things with the upgrade. terminator crashes more often then I would like. Shutdown takes longer than it should. The notifications indicator doesn't always start on boot. And I have to restart NM in order for vpn item in NM to not be greyed out for me to click it. [00:23] sabdfl: given one could assume you're developing then :) [00:23] https://github.com/snapcore/snapcraft/blob/master/tour/00-SNAPCRAFT/02-parts/snapcraft.yaml [00:24] that's a fairly blunt example (haven't tried it) which actually looks like it builds bash [00:24] I might be missing a full steps [00:24] a simpler one would just COPY it in [00:24] but the point is if you add that you can run pithos.bash [00:24] and THEN you have a shell which sees the same slices of reality that your python app does [00:24] i.e. the filesystems and kernel permissions etc are the same [00:24] including in particular, in this case, if that gi modules is present [00:25] then you can just poke around and more easily see what is really going on [00:25] ahoneybun, pastebin your snapcraft.yaml [00:25] or snap.yaml if you are doing things the heroic manual way [00:26] http://pastebin.ubuntu.com/23071882/ [00:26] yea I just broke things trying that bash thing [00:27] tsimonq2, the inkscape snap has access to the HUD too [00:27] which is super cool [00:28] ahoneybun: can you pastebin the output of `unsquashfs -l pithos_ahoneybun_1.2.0_amd64.snap`? [00:28] err, pithos-ahoneybun, sorry [00:29] no such file or dir [00:29] sorry, i was sort of guessing on the resulting snap's name; it'd be something.snap in the same directory you ran `snapcraft build` in [00:30] the .snap you mean? [00:30] let me build the snap again [00:31] ahoneybun: yeah, the resulting .snap (which is just a squashfs fs) [00:35] sabdfl: filed LP: #1615163 [00:35] Bug #1615163: shell boilerplate could be automatically added when building in devmode [00:38] nacc, http://paste.ubuntu.com/23071892/ [00:38] sorry about the wait [00:38] god I love pastebinit tsimonq2 [00:38] ahoneybun, try this part in your snapcraft.yaml: [00:38] bash: [00:38] plugin: copy [00:38] source: bin/ [00:38] files: [00:38] bash: bin/bash [00:39] erk sorry meant to pastebin that [00:39] you will need to make a bin/ directory in your snap source tree and copy /bin/bash into that [00:40] then add this to your apps: stanza in snapcraft.yaml [00:40] bash: [00:40] command: bin/bash [00:40] I *think* that will get you a bin/bash in your snap [00:40] ahoneybun: np, looking at it now [00:41] sabdfl, going to see what nacc and I can get from that other way first [00:41] ok [00:42] ahoneybun: for my own edification, is /snap/pithos-ahoneybun/x1/usr/bin/pithos a python script? [00:42] i'm testing here on my own snap and it seems to work [00:42] the net effect is I can then run snapname.bash [00:42] sabdfl: yeah that should work, agreed (note that copy is deprecated in favor of dump :) [00:42] and i am in the sandbox that the snap lives in [00:42] nacc, yeah, i couldn't figure out the help text for dump :p [00:42] ahoneybun: (note the x<#> may vary depending on if you've done more revisions since the paste) [00:43] x# is code for "local revision #" [00:43] sabdfl: :) i had the same issue, hence my bug report says i'm not entirely sure if it works as written :) [00:43] I don't see that file nacc [00:44] ok, i'm retiring for the day, nice to meet you ahoneybun i look forward to trying your snap. yours too wililupy [00:44] ahoneybun: when you run the app now, doesn't it say something like "File ..., line 8, in " in the traceback? [00:44] it's in /bin now [00:44] need to go [00:44] have a great evening sabdfl [00:48] ahoneybun: me too, will try and be around next week [01:13] PR snapd#1693 closed: tests: add qemu to our spread.yaml and update README [01:13] PR snapd#1693 closed: tests: add qemu to our spread.yaml and update README [01:30] PR snapd#1711 opened: tests: disable unity test [01:31] c [01:31] oops :) [02:01] PR snapd#1711 closed: tests: disable unity test [02:07] PR snapd#1706 closed: tests: add process-control interface spread test [03:03] ahoneybun: you around? I figured out your problem [03:09] ahoneybun: unfortunately it won't get you very far, pithos looks to be a mess of hardcoded paths [03:12] the file is in the right place [03:12] that's what's weird [03:12] ls prime/share/pithos/ [03:12] pithos.gresource [03:15] ahoneybun: the problem is your #! line in ${SNAP}/bin/pithos is telling it to use the system python, not the snap's python [03:16] ahoneybun: change your snapcraft app command to this: [03:16] command: desktop-launch python3 ${SNAP}/bin/pithos [03:16] that will use the snap's python3, so it will find gi.repository [03:16] it found that now [03:16] but it will fail a little further down, when it's using more hardcoded paths to load files [03:16] that part [03:16] Ihttp://pastebin.ubuntu.com/23072018/ [03:16] http://pastebin.ubuntu.com/23072018/ [03:17] funny that the file is in the right place and name [03:17] so it gets to this part of bin/pithos resource = Gio.resource_load(os.path.join(pkgdatadir, 'pithos.gresource')) [03:19] and pkgdatadir is /share/pithos [03:19] which is not the right directory [03:19] it is [03:20] pithos-ahoneybun/x1/share/pithos/ [03:20] which is not the same as /share/pithos [03:20] mm [03:20] your snap isn't a chroot [03:20] in a snap means / on your machine [03:21] I COULD change the pkgdatadir or something to ${SNAP} but it would brake with every release [03:21] or something similar [03:23] yeah, really upstream should be using XDG_DATA_DIRS or something like that, rather than hardcoded paths [03:24] so pointless snap idea then? [03:24] depends on how willing upstream is to take patches from you to improve it [03:24] no idea how to make it better [03:25] it's on github so it is possible to do requests [03:25] I know someone was workign on some runtime hack to redirect attempts to read from /usr/share/ to account for things like this, but I don't know how far along that is [03:25] I'd rather avoid hacks tbh [03:29] funny someone made a flatpak [03:31] flatpaks are chroots, or containers, or something more separate from the host machine than snaps are [03:32] mm [03:32] ack [03:35] snapcraft is so picky on spacing [03:36] spacing? [03:36] yea [03:36] found character '\t' that cannot start any token on [03:37] about to give up man [03:37] just keeps yelling about it [03:37] ahoneybun: don't give up, give up for the day, sure, but Pithos snap... :O [03:37] tsimonq2, that one is not going to work [03:38] atm I'm messing with Geary [03:38] oh [03:46] yep [03:49] can snap deal with deb files? [04:39] ahoneybun: that's probably yaml, not snapcraft [04:39] well [04:39] it handles .git fine [04:39] nice to know [04:39] trying to snap otter-browser atm [04:39] really rare to see you up mhall119 [04:40] https://github.com/OtterBrowser/otter-browser [04:40] yeah, I've been trying to find a way to make pithos work without patching it.......spent too long on it [04:40] mhall119, sorry about that [04:40] don't worry about it [04:40] first time very rarely works on anything [04:40] not your fault, I just can't turn away from a challenge :) [04:41] I kinda can [04:41] hitting a xcb error atm [04:42] added libqt5gui5 but no dice [04:45] mhall119, trying to find *something* that I can snap right lol === chihchun_afk is now known as chihchun === JanC is now known as Guest65624 === JanC_ is now known as JanC === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === beisner- is now known as beisner === mup_ is now known as mup === diddledan__ is now known as diddledan === tvoss_ is now known as tvoss === mariogrip_ is now known as mariogrip === braderhart_ is now known as braderhart === Tristit1a is now known as Tristitia [08:32] PR snapd#1609 closed: overlord/devicestate: first pass at device registration logic === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [11:06] ahoneybun, mhall119, didya crack it? [11:31] So I've got quassel-core installed on my Raspberry Pi. Should make me a little more connected to IRC again. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [13:08] PR snapd#1712 opened: asserts/sysdb: embed the new format official root/trusted assertions [13:39] PR snapd#1713 opened: tests: start teaching the fakestore about assertions === JanC_ is now known as JanC === chihchun_afk is now known as chihchun [14:29] \HELP [14:32] Hello guys. How to do snap app to open URL retranslating to the system browser or the system application (like evince for PDF)? [14:41] eldarkg: I don't think it can. You can not expect any browser or PDF viewer to exist, unless it's provided by your snap. [14:43] qengho_: What about xdg-open to open file if mime exist? === qengho_ is now known as qengho [14:44] qengho: What about this https://bugs.launchpad.net/snappy/+bug/1580740 ? [14:44] Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link

[14:46] eldarkg: Yes? What about it? [14:48] qengho: I failed === chihchun is now known as chihchun_afk [15:12] sabdfl: we fixed one problem, but pithos has so many hardcoded paths that it will take quite a bit of patching to make it work [15:13] eldarkg: it's being worked on, if not already working [15:14] the tl;dr is that your snap will need to call a special version of xdg-open that will pass the URI over to the real thing [15:15] using a trusted mediator that will let it open the webbrowser outside of your snap's confinement [15:18] mhall119: Where I can to get information about how to configure my snap? [15:19] mhall119: or example snap? [15:21] eldarkg: to open urls externally, or in general? [15:22] http://snapcraft.io is good for general info on snapping [15:22] judging by the bug report you posted above, I don't think the new snap-xdg-open stuff is landed yet [15:24] mhall119: I snap kicad. Kicad have documentation in html format that opened from kicad that retranslated to web-browser. [15:25] so that's what this snap-xdg-open project is going to fix, it will pass the documentation file URI outside of your snap's environment so it can be opened in the system browser [15:28] I thought may be exist another ways to solve this problem [15:36] you could possibly include xdg-open and a lightweight browser in your snap, but I'm not sure to tell xdg-open how to find the in-snap browser [15:42] mhall119: Thank you. But I don't want to include browser in snap [15:45] eldarkg: that's going to be the best long-term anyway, check back here on Monday and see if attente or elopio are give you an ETA on when snap-xdg-open will be available [15:45] mhall119: ok === chihchun_afk is now known as chihchun [16:21] Bug #1615248 opened: ubuntu-core-launcher nvidia driver detection is bogus [16:23] mhall119, what's the best way to uncerstand wrapper commands? [16:23] understand, even [16:23] i'm snapping up something cloudy and snapcraft made me a command-foo.wrapper [16:23] but i want to make a custom one, where to put it? === chihchun is now known as chihchun_afk [16:24] sabdfl, that wrapper is always there to set up the snap env ... just create a wrapper.sh (or omit the .sh) that does what you want and define it as the executable in your apps entry [16:25] sabdfl, here is a very simple example https://github.com/ogra1/laidout [16:26] thanks folks [16:29] is $SNAP_COMMON the unversioned system directory? [16:29] data directory [16:30] yep [16:30] ogra@anubis:~/datengrab/devel/branches/dragonboard-kernel-snap$ hello-world.env |grep COMMON [16:30] SNAP_USER_COMMON=/home/ogra/snap/hello-world/common [16:30] SNAP_COMMON=/var/snap/hello-world/common === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [16:51] oh this is exciting [17:00] ogra_, does it make sense to use $SNAP_COMMON if run as root, $SNAP_USER_DATA otherwise? [17:00] and... how do I test if I am root in the wrapper? [17:12] sergiusens, who do i need to ask about registering a name that i think is already reserved? [17:24] if [ "$(id -u)" = "0" ]; then [17:24] echo "i'm root" [17:24] fi [17:26] sabdfl, i guess the $SNAP_USER_DATA vs $SNAP_COMMON is personal preference ... if it is some actual enduser tool i'd use $SNAP_USER_DATA though ... if it is something for i.e. system management/maintenance i'd pick a system dir like $SNAP_COMMON [17:28] it's an interesting one [17:28] it usually runs as a daemon as root [17:28] which suggests to use the system writable dirs [17:28] but you can also run it as a user [17:29] in which case, in the classic world, it just writes wherever you are or where you tell it to [17:29] which feels more like $SNAP_USER_DATA [17:29] yeah [17:29] so $SNAP_COMMON for system ... $SNAP_USER_DATA for non-root sounds logical [17:56] is there a convenient interface for sending messages to the systemd journal? [17:56] pitti, ^? [18:08] sabdfl, there's socket and dbus interfaces for it [18:08] and I believe go bindings as well, so you could craft a custom interface [18:09] https://github.com/coreos/go-systemd [18:14] thanks Son_Goku [18:15] the app i am snapping up may well be using that code [18:17] sabdfl, if I may ask, what are you snapping? [18:17] Son_Goku, etcd [18:18] then it is very likely using that code [18:18] i think i just need a tiny interface added to snapd [18:18] :) yes [18:18] small world huh [18:18] heh [18:21] now i've got to dive into the make-a-smll-new-interface rabbit hole :) [18:21] jdstrand, could you look at https://bugs.launchpad.net/snappy/+bug/1615262 ? [18:21] Bug #1615262: Cannot send message to systemd-journald [18:21] Bug #1615262 opened: Cannot send message to systemd-journald [18:23] Son_Goku, i have a test snap, want to try it out? [18:23] 3.0.6-master [18:23] why not? :P [18:23] give me a tick to get my Linux machine [18:23] pffst [18:23] I was curious if anyone has pointers on getting spread tests to work in linode. I've tried using the stock Ubuntu 16 image with custom kernel (ie, one that supports AppArmor), but have had no luck in running through the tests. Are there any additional customizations I would need to make to the image in order for tests to run successfully? Thx [18:24] jaymell, niemeyer is a linode user and also mr spread, so a good person to ask [18:29] .... [18:29] I'm getting this error when trying to search for snaps: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported" [18:30] oh, I'm so stupid [18:30] Son_Goku, fwiw i have not uploaded to the store yet [18:31] I have to be root to do stuff with snap [18:31] sabdfl, so where do I get your snap? [18:31] Son_Goku, you can 'snap login email@foo.com' using your Ubuntu SSO email address (LP email I think) [18:32] then you can do stuff as your user iirc [18:32] ah [18:33] still broken [18:34] Son_Goku, are you up to date? [18:34] snap find working fine here [18:35] snapd-2.12 [18:39] that's the latest release as of 9 days ago [18:39] snap refresh ? [18:40] sabdfl for reserved names either ev, noise][, nessita or cprov [18:40] aka, store folk ;-) [18:40] coolio thanks sergiusens [18:42] jaymell: It just needs a custom image that has the upstream Ubuntu kernel rather than Linode's as you point out, and as documented in Linode [18:42] Son_Goku, i can email it to you [18:42] sabdfl, okay, cool [18:42] jaymell: You'll need to name the image as expected by the tests [18:43] ubuntu-16.04-64-grub, for the 64bit one [18:44] jaymell: That grub suffix is a hack that is already obsolete, and will be dropped next week.. spreads but those images with the GRUB 2 "kernel" of Linode.. now this is more explicit.. it will be just [18:45] ubuntu-16.04-64: [18:45] kernel: GRUB 2 [18:45] niemeyer, does the go plugin to snapcraft handle setting up GOPATH nicely? [18:46] sabdfl: Yeah, works out of the box.. ley me give you a link.. [18:47] sabdfl: https://github.com/niemeyer/snaps/blob/master/mup/mup-plugins/snapcraft.yaml [18:48] niemeyer: Thanks, I think I got all that working -- I'm just getting a lot of random errors in the tests themselves. It sounds like I'm on the right track, though, let me see if I need to go back and fix some of the hacking I did to spread.yaml [18:49] jaymell: Ohh, wait.. [18:49] jaymell: When was your spread and snapd code last updated? [18:50] Should be latest as of last evening for both -- maybe I should be using a particular version of spread rather than the latest? [18:50] jaymell: I released a new incompatible spread release overnight, and merged fixes on snapd itself at the same time [18:51] jaymell: Sent a note to snapcraft@ ML about the fact this was coming, and pinged the thread once it was in [18:52] niemeye: Ok, just did a pull in both repos, do you think using the latest in both will likely resolve things? [18:53] niemeyer: In any case, I'll give things a try again later this evening. I was more worried that I was doing something fundamentally wrong, but it sounds like I just need to dig a bit more into the errors I'm getting. Thanks for the info! [18:53] PR snapd#1714 opened: many: hook in start of code to fetch/check assertions when installing snap from store [18:58] jaymell: Well, I hope so.. Travis is passing with master [18:58] jaymell: If it doesn't , just ping me [18:59] sabdfl: can I trouble you to fill out https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ ? [19:01] ev sure, if you can tell me what a developer namespace is really for :) [19:02] jaymell: This is tip of snapd, runs against Linode: https://travis-ci.org/snapcore/snapd/jobs/153754133 [19:05] sabdfl: we’re moving that over to proper SSO usernames, but it’s further down in the backlog. I was never a fan, but other priorities win out. [19:09] ev so i should say 'sabdfl' ? [19:09] yes please [19:10] ev done, thanks for the pointer :) [19:11] anytime! [19:32] funny how everyone is around on a saturday :) [19:39] ogra_ I am not, I just happen to be on and off ;-) [19:40] sergiusens, if you are on again briefly, can you remind me how to make a custom plugin, or point me at one? [19:40] iirc it's call it x-foo and stick it somewhere specific? [19:41] sergiusens, heh, same here i have "fix the heating while susie is away" weekend :) ... so i'm procastinating instead of cleaning the oli furnace ;) [19:41] *oil [19:41] :P [19:41] (not freudian ... promised) [19:41] olli will be relieved :) [19:42] * ogra_ spent most of his day with half his body in that thing ... scratching oil coal off the walls ... i look like a chimney sweep [19:50] sabdfl: a custom plugin that's snap-specific? [19:51] sabdfl: or a global plugin to go into Snapcraft? [19:51] tsimonq2, yes, i have an upstream that has a build command of its own (not a Makefile or anything standard) [19:51] i just want to set an environment variable and run that command [19:52] well, worst case you can always cheat and just wrap a makefile around it [19:52] sabdfl: here's an example in the Snappy Playpen: https://github.com/ubuntu/snappy-playpen/tree/master/atom [19:52] Snappy Playpen to the rescue! \o/ [19:53] sabdfl: or this is without a wrapper if it makes things easier to read :) https://github.com/ubuntu/snappy-playpen/tree/master/idea [19:56] sabdfl: what are you snapping? :) [19:56]