[00:39] <fusion809> Hi, I'm attempting to build (using snapcraft) the Atom package in the snappy-playpen repo of Ubuntu (https://github.com/ubuntu/snappy-playpen/tree/master/atom) on Arch Linux but I'm getting the error message: 'Loaded local plugin for nodejs
[00:39] <fusion809> Could not find a required package in 'build-packages': "The cache has
[00:39] <fusion809> no package named 'fakeroot'"'
[00:39] <fusion809> Guessing it's related to my OS. Do I have to adjust the dependencies in snapcraft.yaml to the corresponding ones on Arch Linux?
[00:42] <fusion809> I know I can download the finished snap package for Atom and without a need for building it manually, but I'm attempting to build this package to get some practise in building snaps
[00:53] <qengho> fusion809: fakeroot is indeed a Debian-specific package. That cross-distro package-name problem is still in progress, so I'm sad to say you might have to use a tweaked YAML to build on various systems. Sorry.
[00:55] <fusion809> I tweaked the package names from Ubuntu -> Arch package names and now I'm getting the error: 'Loaded local plugin for nodejs
[00:55] <fusion809> Could not find a required package in 'build-packages': "The cache has
[00:55] <fusion809> no package named 'npm'"'
[00:55] <fusion809> even though npm is a valid Arch package
[00:55] <fusion809> in the [community] repo
[00:56] <fusion809> it doesn't seem to be downloading packages to the cache
[01:22] <fusion809> I set up a Ubuntu 16.04 Docker container and tried out building it and it's working fine. So I think that snapcraft is having difficulty working with pacman to download dependencies
[01:43] <tsimonq2> fusion809: weird, I'll play with it when I have the time
[02:48] <samerY> hello! how does one include an older release of python as part of a snap that runs a simple python program?
[02:49] <samerY> would I need to create a separate plugin (aside from python2 & python3)?
[02:52] <fusion809> I also have a query. How do I run sed and otherwise modify (or in other words, prepare for the build) source files before building from them in a snapcraft.yaml? The only way of doing this I have come up with is by adding lines like self.run('prepare.sh') to a plugin script in parts/plugin so that a shell script called 'prepare.sh' is run before th
[02:53] <fusion809> e build. In this prepare.sh file I would have my sed commands
[03:04] <tsimonq2> samerY: what release?
[03:05] <tsimonq2> fusion809: what are you trying to modify?
[03:05] <fusion809> Well I'm working on the Atom package still and I want to edit its package.json file. There's so many different package versions listed there that it would be impractical for me to use a patch
[03:06] <fusion809> so it's more efficient to use sed
[03:18] <tsimonq2> fusion809: I honestly don't know how you would go about doing that, it would be wise to wait around for someone tomorrow to answer that question :)
[03:37] <fusion809> tsimonq2: Thanks, I may be able to solve this myself, but do you know if I can specify more than one source? If I can specify a shell script as a second source I may be able to get somewhere with this.
[06:00] <jaygeeth> hello
[06:50] <dholbach> hey hey
[07:02] <fusion809> I just created my first snap package, atm the only way I can make it publicly available for download is using a file storage service / GitHub. So I chose to store it on GitHub https://github.com/fusion809/snapcraft/releases
[07:02] <fusion809> How else can I share it? Is it possible to contribute these packages to the official snappy repo?
[07:04] <dholbach> Yes
[07:04] <dholbach> and it's actually quite easy: https://developer.ubuntu.com/en/snappy/build-apps/upload-your-snap/ :-)
[07:06] <fusion809> Ah. I already tried that method (sorry I should have said, I was just assuming the method I was using had to not be the official one, but now I see this guide I see I was using the official method rofl) and it gave the error https://gist.github.com/fusion809/c7f14595e29af20d3c422a3e4638029f
[07:07] <fusion809> It is a 165MB snap though. Maybe that's too large for it?
[07:25] <dholbach> No it should be fine
[07:25] <dholbach> can you go to https://myapps.developer.ubuntu.com/dev/account/?
[07:25] <dholbach> and set something in "Developer namespace"
[07:41] <zyga> good morning
[07:42] <Doc_> was hoping someone could stupify the explanation of snap by telling me if in broad terms a snap and an .exe on windows are teh same .... ish o.O
[07:44] <fusion809> dholbach: Just set something and now I'm getting a different error: https://gist.github.com/fusion809/0ae01640ea318dbff8c93834e4c17006
[07:45] <dholbach> Doc_, no, they're not - a snap would be more like a special .zip file
[07:45] <zyga> Doc_: snaps are compressed, read only filesystems that contain one or more application and services and run in a special environment that is not tightly coupled with the host distribution
[07:45] <dholbach> fusion809, we're getting closer
[07:46] <dholbach> fusion809, can you go to https://myapps.developer.ubuntu.com/dev/click-apps/register-name/?
[07:46] <dholbach> I think there's a bug open for the store/snapcraft to give you better instructions about this
[07:47] <dholbach> the doc could be more explicit here too
[07:47] <dholbach> let me file a bug for this
[07:48] <dholbach> I filed https://bugs.launchpad.net/snapcraft/+bug/1594273 if you want to subscribe to it
[07:50] <fusion809> Is there any temporary workaround for this problem? Like is it possible to upload the snap in the web browser
[07:50] <Doc_> sweet thank you for the concise explanation dholbach
[07:51] <dholbach> fusion809, yes, you can upload it there too
[07:51] <dholbach> fusion809, just register the name of the app
[07:52] <fusion809> How? Which website do I go to in order to do this?
[07:52] <fusion809> https://uappexplorer.com/?
[07:52] <fusion809> https://uappexplorer.com/ ?
[07:59] <fusion809> dholbach if https://uappexplorer.com/ is the URL then I keep getting redirected to https://uappexplorer.com/me and this is what I see there http://i.imgur.com/g88rhUx.png. I'm working on Arch Linux (running snapcraft in a Docker container for 16.04 Ubuntu) and from what I can tell I can't get Caxton
[07:59] <fusion809> on Arch
[07:59] <dholbach> I have no idea what Caxton is
[07:59] <dholbach> ^ can anyone else help?
[07:59] <dholbach> Ah no..
[08:00] <dholbach> it's https://myapps.developer.ubuntu.com/dev/ - sorry
[08:00] <dholbach> myapps, always myapps
[08:00] <dholbach> uappexplorer is a 3rd party site which just lists all the available click and snap apps
[08:00] <fusion809> Thanks
[08:01] <zyga> fusion809: o/ -- it is great to see snaps originating from the arch community!
[08:06] <fusion809> Yeah. My current PC is a HP Envy 17 laptop with two HDDs, one has Arch installed and the other has Ubuntu 16.04 installed. Ubuntu was the first distro I ever used (and I started in mid 2012), but Arch is my favourite.
[08:07] <fusion809> Solus OS uses a similar build file to snapcraft's yaml file.
[08:11] <Chipaca> morning all
[08:11] <hamiltino> can somone help me i installed snap hello but when i run the command hello it says command not found
[08:11] <fusion809> Aha, just published my first snap package https://myapps.developer.ubuntu.com/dev/click-apps/5248/
[08:12] <zyga> woot!
[08:12] <Chipaca> hamiltino, can you pastebin the output of "snap list"?
[08:12] <zyga> fusion809: tha'ts something that only you can see
[08:12] <zyga> fusion809: what is the name of the snap?
[08:13] <hamiltino> yes here
[08:13] <hamiltino> http://pastebin.com/iW6YBNQB
[08:13] <fusion809> atom-fusion is its name.
[08:14] <Chipaca> hamiltino, what distro are you on?
[08:14] <hamiltino> debian
[08:14] <Chipaca> hamiltino, have you logged in since you installed snapd?
[08:14] <hamiltino> jessie but added sid repo and installed snapd
[08:14] <Chipaca> hamiltino, otherwise /snap/bin might not be in your path
[08:15] <Chipaca> hamiltino, if starting a new shell, or logging in again, doesn't end up with /snap/bin in your path, then we need to figure out why :-)
[08:16] <zyga> hamiltino: which shell do you use?
[08:16] <Chipaca> ah, good q
[08:18] <hamiltino> hey i just added /snap/bin to /etc/profile and then ran source /etc/profile. Its working now thanks
[08:18] <Chipaca> hamiltino, the snapd package should have done that already
[08:18] <Chipaca> hamiltino, via /etc/profile.d
[08:18] <Chipaca> hamiltino, /etc/profile.d/apps-bin-path.sh in particular
[08:19] <Chipaca> bah, that's what it is in ubuntu; in debain it might be /etc/profile.d/snapd ? not sure
[08:19] <Chipaca> hamiltino, dpkg -L snapd | grep profile
[08:20] <hamiltino> yeah i see apps-bin-path.sh
[08:20] <hamiltino> it has PATH=$PATH:/snap/bin
[08:20] <hamiltino> wonder why it didn't work
[08:25] <zyga> hamiltino: are you running bash or some other shell?
[08:25] <hamiltino> gnome-terminal
[08:25] <zyga> hamiltino: echo $SHELL
[08:26] <hamiltino> yea running bash
[08:26] <zyga> ok
[08:26] <zyga> hmmmm
[08:26] <zyga> can you please source /etc/profile.d/apps-bin-path.sh (. /etc/profile.d/apps-bin-path.sh )
[08:27] <zyga> and then try to run any of the snaps you've installed
[08:27] <hamiltino> ok
[08:29] <hamiltino> ahh that works thaks
[08:29] <hamiltino> thanks
[09:09] <fusion809> Is my atom-fusion package published now cause I think it is
[09:14] <tsimonq2> fusion809: you made an Atom snap? :)
[09:16] <fusion809> Yeah, but I had to use an inpractical method see I created a fork of the official Atom repo to https://github.com/fusion809/atom-1/ and applied my edits to it so I could create a source code tarball for it.
[09:17] <fusion809> It's impractical as everytime a new release comes out it'll be a bit of a nuisance to update.
[09:17] <fusion809> But hopefully someone will come up with a way of sedding the source
[09:31] <zyga> fusion809: I don't think it is yet
[09:31] <zyga> fusion809: I just did a lookup with 'snap find atom' and only found atom-cwayne
[09:31] <fusion809> Ah, thanks.
[09:32] <zyga> fusion809: double check the myapps website
[09:32] <zyga> fusion809: last time I looked there was a publish button at the bottom but afair the UI changed
[09:38] <fusion809> I published it, it says "Package status is Published".
[09:39] <fusion809> Been published for an hour or more.
[09:39] <matteo> hi all
[09:39] <matteo> hi zyga
[09:40] <matteo> zyga: I have a problem with download from the store
[09:42] <zyga> matteo: what kind of proble
[09:42] <matteo> http://pastebin.ubuntu.com/17586014/
[09:43] <zyga> fusion809: did you publish it to the 16 series?
[09:43] <zyga> fusion809: and if so, to which channel?
[09:43] <zyga> fusion809: I cannot download it yet
[09:43] <zyga> matteo: hmm, not sure, maybe cdn issue
[09:43] <zyga> matteo: are you using a proxy?
[09:43] <1JTAAFARK> Hi - I want to try delta updates. Is there a resource where I can read up on them?
[09:44] <matteo> zyga: no proxies
[09:45] <fusion809> http://i.imgur.com/4DSzVP6.png
[09:45] <fusion809> That screenshot hopefully answers that question
[09:46] <zyga> OK
[09:46] <pandaadb> (managed to rename myself to something normal) - don't know if I missed it. I wanted to read up on delta updates for snappy packages if someone can point me to a resource :)
[09:47] <zyga> pandaadb: today snaps are not using delta updates, given the snap architecture this is very natural and we have some experiments but this is not released yet
[09:47] <matteo> zyga: how can we know if it's a CDN issue?
[09:47] <matteo> it happens every time
[09:48] <zyga> matteo: no idea really, I'll ask around
[09:48] <pandaadb> zyga, ah okay. I was reading an article mentioning that that feature exists. Next update then :)
[09:48] <pandaadb> thanks!
[09:49] <pandaadb> For completeness, that's what I've been reading: http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-lts-snap-packages
[09:57] <slvn> Hello, I have tried to add the interface "pulseaudio" to my snap, but it doesn't seem to play sound
[09:57] <slvn> I have message from app armor
[09:57] <ogra_> does it play if you install the snap with --devmode ?
[09:59] <slvn> \me is trying ...
[09:59] <ogra_> just to verify it works at all :)
[10:00] <slvn> yes
[10:00] <slvn> it's working with --devmode
[10:00] <ogra_> good, then it is definitely an interface problem ...
[10:01] <slvn> in fact there is two issues (for me), I need to add the stage-package "libpulse0" to have acces to the libpulse, then it's blocked by app armor ...
[10:02] <slvn> it tries to open/mknod the file /dev/shm/pulse-shm-1888657987 according to the log
[10:03]  * ogra_ sees bug 1593558
[10:05] <zyga> pandaadb: I think there are some misconceptions about this, we never announced it yet
[10:05] <pandaadb> That's interesting. I also saw that info on some answers on stackexchange
[10:06] <pandaadb> well actually, they just link to the article so that makes sense
[10:07] <zyga> pandaadb: since snaps are read only squashfs files that are always present on the device all you need is an xdelta to get get another revision
[10:08] <zyga> pandaadb: we'll release it when everything is ready
[10:08] <pandaadb> Sounds great :)
[10:09] <zyga> slvn: currently pulseaudio gives you the followng permission:
[10:09] <zyga> /{run,dev}/shm/pulse-shm-* rk,
[10:09] <zyga> so you cannot create buffers there
[10:09] <zyga> svij: can you please do a small tweak, edit /var/lib/snapd/apparmor/profiles/snap.$snap.$app
[10:10] <zyga> svij: and patch a line that looks like the one I pasted above
[10:10] <zyga> svij: to read
[10:10] <zyga> svij:  /{run,dev}/shm/pulse-shm-* rwk,
[10:10] <zyga> slvn: then run sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.$snap.$app
[10:11] <svij> zyga: ?
[10:11] <zyga> svij: sorry, I meant slvn
[10:11] <svij> ah ok
[10:11] <zyga> slvn: ^^ then see if your app works
[10:11] <slvn> ok I try!
[10:12] <zyga> slvn: and report a bug wiht this information please, we should be able to fix it quickly
[10:19] <slvn> zyga, I have less message from app armor, but it's still doesn't work:
[10:19] <slvn> I have this message
[10:20] <slvn> Jun 20 12:17:47 jupiter kernel: [14994.957426] audit: type=1326 audit(1466417867.433:1620): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=12090 comm="PulseHotplug" exe="/snap/mahjong/x1/bin/Mahjong" sig=31 arch=c000003e syscall=141 compat=0 ip=0x7efe3a8ed4a7 code=0x0
[10:21] <slvn> syscall 141= 	setpriority	sys_setpriority ?
[10:21] <slvn> also an access to "/etc/timidity/freepats.cfg"
[10:22] <slvn> not sure if it's pulse audio, or SDL2 which access to this ..
[10:23] <zyga> slvn: that's setpriority
[10:23] <zyga> slvn: that will only work after syscall argument filtering works :/
[10:23] <zyga> slvn: if you want to ship timidity in your snap you will have to change its configuration to look at some other place
[10:23] <zyga> slvn: timidity is the midi thing
[10:25] <slvn> I don't use midi, so probably no needed for me
[10:26] <slvn> so I open a bug for the pulse app armor configuration ?
[10:27] <slvn> it wont work, but it's needed ..
[10:28] <matteo> zyga: I've added a line in snapcraft
[10:28] <matteo> print ("Downloading from" + package['download_url'])
[10:28] <matteo> before downloading the snap
[10:29] <matteo> now I'll try to download it to see if it's a CDN issue
[10:34] <slvn> zyga, https://bugs.launchpad.net/snapcraft/+bug/1594318
[10:41] <zyga> slvn: thanks
[10:43] <zyga> jdstrand: hey
[10:43] <zyga> jdstrand: ^^ if you agree with the proposed policy change I will make it happen
[10:49] <slvn> zyga, also I need to add to my snapcraft.yaml the line "stage-packages: [libpulse0]" to have access to libpulse0
[10:49] <slvn> whereas I could be granted to have acces to the system lib
[10:56] <slvn> libs are : /usr/lib/x86_64-linux-gnu/libpulse.so and /usr/lib/x86_64-linux-gnu/libpulse-simple.so ( I guess)
[10:56] <centy> Hi all
[10:57] <centy> Whats a good resource to understand how snap works? - I would like to see what it would take to make it work on CentOS.
[10:58] <zyga> slvn: can you report that as a bug, I'll add this to the pulseaudio interface documentation
[10:58] <zyga> centy: hey
[10:58] <zyga> centy: I'd love to get snappy on centos
[10:58] <zyga> centy: I can help you out
[10:59] <centy> zyga: I'm targeting more like Cent5 not sure if that is even possible.
[11:00] <centy> Thanks
[11:00] <zyga> centy: so snappy has two components, snap-confine that's written in C and snapd that's written in go
[11:00] <zyga> centy: I have a bunch of spec files for fedora, I think they can be a good starting point for centos and EL distros
[11:01] <zyga> centy: one thing I dind't figure out is how to proceed with snapd and go in that environment
[11:01] <zyga> centy: should I use something that provides golang-go, what does software like docker do/
[11:02] <slvn> https://bugs.launchpad.net/snapcraft/+bug/1594324
[11:02] <zyga> slvn: thanks
[11:03] <matteo> zyga: while : ; do [ "$(curl -sL https://public.apps.ubuntu.com/anon/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_123.snap |sha512sum)" = '44752755393319233917bfbd6c7802c3c3810ddb3f94091acf16f8ca0c9afaf6c6746eb33f3911d1aaaad52d2045bf9ba6af8e25b49cf5bc3d413d8d13046b45  -' ] && echo correct || echo fail; done
[11:03] <matteo> I have this running for a while
[11:04] <matteo> never had a fail until now in about 30 downloads
[11:04] <centy> zyga: I guess go would need a runtime installed, but what kind of kernel support (if any) would snap need (stuff like cgroups and things?)
[11:04] <seb128> mvo, hey, did you see my message the other day about i386 snaps still not working?
[11:05] <zyga> centy: snappy can run in two modes, in devmode, that is easy to get up and running and in non-devmode
[11:05] <zyga> centy: for devmode pretty much nothing special is required
[11:05] <zyga> centy: for non-devmode you need seccomp and apparmor
[11:06] <zyga> centy: snappy is modular and it is possible to add a selinux backend but nobody started this work yet
[11:06] <zyga> centy: I would suggest starting with devmode and then looking at how to either enable apparmor or what needs to happen in snapd to enable selinux
[11:07] <centy> zyga: I guess I'm looking for some documentation on how it accomplishes sandboxing to see even if that is possible on my target platform
[11:07] <zyga> centy: it is but full selinux support will not happen overnight
[11:08] <zyga> centy: AFAIR centos ships with selinux and apparmor is not available along with selinux
[11:08] <zyga> centy: without apparmor you can still enable seccomp but some part of the confinement will not work
[11:08] <zyga> centy: all of the confinement bits are defined in snapd source code, in the interfaces/ directory
[11:08] <zyga> centy: look at interfaces/apparmor/template.go and at particular interfaces/builtin/*.go files
[11:09] <zyga> centy: each interface defines confinement and other security details for a given backend
[11:09] <zyga> centy: there are numerous backends, most interfaces use seccomp and apparmor today
[11:09] <zyga> centy: note that none of this affects actual snaps, if you have a snap that declares it needs networking, it can be made to work just by patching snapd
[11:10] <centy> zyga: looks like I'll just have to read through the code and figure this out. I'm more on the administration side and not very in to c/go coding. I was mainly interested in the ability to package newer apps using snapd and deploy to hundreds of existing cent5 system.
[11:10] <zyga> centy: I can work with you on this
[11:10] <zyga> centy: but I'm not very used to centos, if you can help me with packaging
[11:10] <zyga> centy: I can help you out with the security bits
[11:11] <zyga> centy: does centos5 have docker?
[11:11] <zyga> centy: and if so, are those spec files for docker available anywhere to read?
[11:11] <centy> zyga: what kind of help you need with packaging? Building RPMs?
[11:11] <zyga> centy: mostly figuring out how to support go on centos/rhel
[11:11] <zyga> centy: the snap-confine .spec for feodora is here;
[11:11] <zyga> https://github.com/zyga/snapcore-fedora/blob/master/snap-confine.spec
[11:12] <zyga> centy: the same repository has a few other specs files that were prerequisties for snapd and the snapd.spec itself
[11:12] <zyga> centy: I've also created where I'd like to put spec files for centos https://github.com/zyga/snapcore-centos
[11:13] <zyga> centy: I also have a copr repo that works for fedora 23 and 24 at https://copr.fedorainfracloud.org/coprs/zyga/snapcore/packages/
[11:13] <centy> zyga: apparently go isn't supported on Cent5 http://dave.cheney.net/2013/06/18/how-to-install-go-1-1-on-centos-5
[11:14] <zyga> centy: since snapd is just one binary, it would be possible to ship a copy built on fedora for centos
[11:14] <zyga> centy: does centos5 have systemd?
[11:15] <zyga> centy: reading the article I see that it might be difficult to support because of older userspace and kernel
[11:19] <centy> zyga: apparently lost my connection - sorry
[11:19] <zyga> no worries, this is irc ;)
[11:24] <ogra_> zyga, does the home interface not auto-connect when sideloading a snap ?
[11:25] <zyga> ogra_: it should, are you on yakkety by any chance, AFAIR we didn't release anything there yet because of unrelated regression
[11:25] <ogra_> zyga, i got a gitter snap that works fine in devmode ... but dropping it i get http://paste.ubuntu.com/17588690/
[11:25] <ogra_> and no, i'm on xenial
[11:25] <zyga> ogra_: dconf, hmmm, looks like gsettings interface to me
[11:26] <zyga> ogra_: if you remove the snap entirey and reinstall it, does it auto-connect
[11:26] <ogra_> oh, wiat, snap interfaces shows all gitter connections
[11:27] <ogra_> seems i'm missing some interface
[11:27] <zyga> hmm?
[11:28] <ogra_> well, home, x11 and network and network-bind are apparently not enough :)
[11:28]  * ogra_ rebuilds with more added
[11:31] <ogra_> hmm, still not starting ... but the set of errors changed
[11:42] <willcooke> Hi gang, the snap I'm working on hosts some of its data in Github which then needs to be cloned and copied in to (I think) $SNAP_USER_DIR.  Can I do this with existing plugins or will it need a custom one?
[11:43]  * ogra_ would use a launch-wrapper for that 
[11:44] <zyga> willcooke: you can also copy it to $SNAP_DATA btw
[11:45] <willcooke> zyga, $SNAP_DATA is not writable by the user is it?  The app updates its data from github on some cadence so would need to be writable
[11:45] <zyga> hmm, AFAIR snaps can write there
[11:47] <ogra_> servers ... but can the UID ?
[11:53] <willcooke> ah, yeah, SNAP_DATA should be writable, and is a better location
[11:54] <willcooke> so question remains; whats the correct way to get files from Github -> $SNAP_DATA.  Really I only want to do this once at build time, then the app takes care of keeping it up to day
[11:54] <willcooke> *date
[11:56] <zyga> hmmm
[11:56] <zyga> willcooke: that's not sensible
[11:56] <zyga> willcooke: that's a snapcraft side (building)
[11:56] <zyga> willcooke: do you want the app to download stuff at runtime?
[11:57] <willcooke> indeed it is a snapcraft thing.  The app does download things during its lifecycle, that's just how it works.
[11:57] <didrocks> why wouldn't the app proceed the first download?
[11:57] <didrocks> (when it starts)
[11:57] <zyga> willcooke: so snapcraft, not sure, write a makefile, write a custom plugin, in either case that's not $SNAP_DATA becausethat only exists at runtime
[11:58] <willcooke> zyga, ahh!  I see,  I'll have a play.  thanks zyga
[11:59] <didrocks> willcooke: see my question about first download on first service start
[12:15] <mvo> seb128: still not working at all? what example snap? or not working for network? or network-bind?
[12:21] <seb128> mvo, not working for snaps not using the network plug since that's where you defined socketcall
[12:22] <seb128> or maybe I should make my snap use that
[12:32] <mvo> seb128: so this also affect snaps that do not use the network  :/ ?
[12:32] <ogra_> well, loopback network is also network :)
[12:32] <seb128> mvo, let me redo a round of testing, but I think I tried to start bash on friday
[12:33] <seb128> which wasn't working
[12:33] <seb128> but maybe that requires the network?
[12:38] <mvo> seb128: heh, that would be odd :)
[12:39] <mvo> seb128: its more a jdstrand or tyhicks question really, I'm not sure I fully grasp the implications of opening this syscall up
[12:41] <seb128> mvo, yeah, ideally somebody needs to fix bug #1576066
[12:45] <Perry____> hi,there, can you guys know how to install snappy to x86 machine? from the official site, only try through USB.
[12:46] <croepha> snapcraft.io not loading
[12:46] <croepha> :(
[12:46] <didrocks> croepha: it does here :) (but layout broken)
[12:47] <didrocks> Perry____: if you have Ubuntu desktop 16.04 LTS, it's already installed
[12:47] <didrocks> Perry____: you can have a look at http://snapcraft.io/ for other distros (mind the layout, temporarly broken for now)
[12:48] <croepha> what is snapcraft.io resolving to for you guys? for me its 162.213.33.140, 162.213.33.142
[12:50] <Perry____> didrocks do you means snappy tool? or snappy os?
[12:50] <croepha> nevermind, now mine is loading
[12:50] <didrocks> Perry____: snapd
[12:50] <didrocks> croepha: ah, was transient
[12:50] <didrocks> Perry____: which is to install/use snappy technology
[12:51] <croepha> didrocks, yep, YAY! now I can snap all the things
[12:51] <didrocks> sweeet! :)
[12:51] <Perry____> ubuntu also have a IoT OS snappy
[12:52] <didrocks> Perry____: there is no release 16 images available yet though, you can use a server image and install snapd on it
[12:52] <didrocks> to experiment
[12:53] <ogra_> i think snapd is actually seeded on server images
[12:53] <ogra_> so you dont need to separately install it
[12:53] <Perry____> didrocks ok, thank you
[12:53] <didrocks> yw ;)
[12:53] <didrocks> ogra_: oh, you're right
[12:53] <ogra_> :)
[12:54] <Perry____> i just wanna try the IoT :)
[13:10] <carif> now that several other distros might adopt snap as a packaging format, does that mean they will run their own app stores?
[13:10] <ogra_> perhaps
[13:12] <croepha> There are going to be multiple stores, even if the distros don't want their own
[13:16] <carif> I've always been somewhat hazy on this, does a store mean a different snap repository? or some "segment" of the official canonical one? the wisdom when last I looked was that you "sideloaded" your own snaps otherwise you installed from the one official place
[13:18] <ogra_> thats still the case ... until someone implements another store ...
[13:18] <ogra_> the APi is open and i would expect that other distros prefer to have their own, so it is likely you see more stores at some point
[13:20] <zyga> joc_: hey
[13:20] <zyga> joc_: do you plean to make any changes to https://github.com/snapcore/snapd/pull/1301/files
[13:20] <joc_> zyga: no plans to, unless you have anything that needs to change
[13:25] <zyga> joc_: I left a few comments that I don't think you've addressed
[13:26] <zyga> ah, wait
[13:26] <zyga> stale tab, thanks
[13:26]  * zyga reads for real :)
[13:27] <joc_> hehe, phew :)
[13:40] <pstolowski> zyga, hey
[13:41] <carif> ogra_, can a company run its own snap repo internally? does snappy have something like /etc/apt/sources.list.d/?
[13:42] <zyga> joc: joc_ https://github.com/snapcore/snapd/pull/1301/files#r67690850
[13:42] <zyga> pstolowski: hey
[13:42] <zyga> pstolowski: how can I help you? :)
[13:42] <didrocks> kyrofa: FYI, I just tried integration_tests/snaps/simple-make-filesets, which is using organize:, snap:
[13:43] <didrocks> kyrofa: typed snapcraft stage
[13:43] <didrocks> changed stage/new/dir2/file1 and append something
[13:43] <didrocks> then "snapcraft"
[13:43] <didrocks> prime/new/dir2/file1 contains my changes
[13:43] <kyrofa> didrocks, indeed, files are pulled from stage
[13:43] <didrocks> so it really seems that prime is pulling files from stage
[13:43] <didrocks> wasn't the contrary you were telling with seb128 the other day?
[13:43] <kyrofa> didrocks, but fileSETS (i.e. WHAT it pulls) is determined from each part
[13:43] <pstolowski> zyga, thanks for your comments to scopes as snapps doc! can you help me understand point #1 a little better?
[13:44] <kyrofa> didrocks, no, but I perhaps wasn't explaining it well
[13:44] <zyga> pstolowski: sure
[13:44] <didrocks> kyrofa: you mean, before organize, the reference?
[13:44] <didrocks> ah
[13:44] <didrocks> so, if in snap: I'm using fileset
[13:44] <pstolowski> zyga, actually, HO would be best. do you have a moment now?
[13:44] <didrocks> that would be from install/ ?
[13:44] <zyga> yep, lets do it
[13:45] <kyrofa> didrocks, so: a file travels from parts/foo/install -> stage -> prime
[13:45] <kyrofa> didrocks, however, the WAY it travels is not "copy from parts/foo/install -> stage -> prime"
[13:46] <kyrofa> didrocks, instead snapcraft keeps track of all files provided by part foo, and moves them from parts/foo/install -> stage, and then moves them from stage -> prime
[13:46] <ogra_> carif, no, not atm
[13:46] <kyrofa> didrocks, that makes it possible to UNstage or UNprime something with snapcraft clean -s stage|prime
[13:46] <kyrofa> didrocks, but it means that if you move files around in stage, snapcraft won't be able to find the collection of files it expects
[13:46] <pstolowski> zyga, https://hangouts.google.com/call/mvw6y5n4wnf6titz4hjodeyldee
[13:47] <kyrofa> Because it pulls the files themselves from stage, but uses what the part provided in parts/foo/install to determine what it's supposed to migrate from stage -> prime
[13:47] <didrocks> kyrofa: ok, I see what you mean, but if we only use the snapcraft feature, with organize and such, those moves/renamed are tracked as expected
[13:47] <kyrofa> didrocks, indeed
[13:47] <didrocks> but yeah, messing directly with the stage/ dir won't reflect the change if files are added or move/renamed
[13:48] <didrocks> that makes sense :)
[13:48] <kyrofa> You got it
[13:48] <didrocks> thanks for clearing that up kyrofa!
[13:48] <kyrofa> didrocks, hey any time. I still think at the very least the `snap` keyword should by default inherit the `stage` keyword
[13:48] <didrocks> I wonder if we have cases with new files created into stage/ that we want to ship
[13:48] <didrocks> as per another build
[13:48] <didrocks> yeah
[13:49] <didrocks> we need to find a real use case for this though
[13:49] <didrocks> kyrofa: however, so, if snap: is refering to a filesets
[13:49] <kyrofa> didrocks, well that means whatever is creating those files is totally bypassing the snapcraft lifecycle of putting things in parts/foo/install first
[13:49] <didrocks> and you renamed those via organize
[13:49] <didrocks> that's going to be difficult if you copy directly from stage/
[13:49] <didrocks> like, what should it refer to?
[13:50] <didrocks> kyrofa: correct
[13:50] <kyrofa> didrocks, first, a warning: you've probably used organize and filesets more than I have
[13:51] <croepha> carif: by looking at the code, it looks like you can specify a store via environmental variables (https://github.com/snapcore/snapd/blob/edc1296463ab8e12c464f7c436d390bbeb5dc117/store/store.go) but I cant find any documentation, so its off the beaten path
[13:51] <kyrofa> didrocks, but I believe organize happens first, then the stage or snap keywords are applied, which means they should refer to the organized named
[13:51] <kyrofa> names*
[13:53] <didrocks> kyrofa: indeed, I just mean: if we have snap referring to stage/ directory, and you set snap: - $fileset1, then this filesets1 (source) doesn't exist
[13:53] <didrocks> only the dest
[13:54] <kyrofa> didrocks, heh, sorry, I need more coffee-- you lost me :P
[13:54] <kyrofa> didrocks, man this is complicated
[13:54] <kyrofa> didrocks, "snap referring to stage/ directory" isn't making sense to me
[13:55] <didrocks> kyrofa: I need to head out
[13:55] <didrocks> will be back in 30s
[13:55] <didrocks> I'll take an example :)
[13:55] <didrocks> get your coffee meanwhile!
[13:55] <kyrofa> didrocks, yeah good idea!
[13:55] <didrocks> ;)
[13:55] <kyrofa> didrocks, oh I am ;)
[13:55] <didrocks> :p
[13:58] <mhall119> no sergio today?
[13:59] <kyrofa> mhall119, I believe he's on holiday until tomorrow
[14:00] <kyrofa> mhall119, can I help you with something? Or are you still stuck on pkg-config stuff?
[14:00] <mhall119> kyrofa: still the pkg-config stuff, can't figure it out for the life of me, but I'm pretty sure it has something to do with the PKG_CONFIG* env variables that snapcraft is using
[14:01] <kyrofa> mhall119, yeah I suspect it's something related as well
[14:01] <mhall119> I can *almost* get it to find the right packages if I manually muck with those
[14:01] <kyrofa> Haha, it fails less badly?
[14:03] <mhall119> well, it fails differently, and I *think* further down the road
[14:03] <mhall119> it fails on trying to find different dependencies anyway
[14:04] <matteo> what differs go from gccgo?
[14:16] <hguant> kyrofa, some one said yesterday that you were the person to ask about building custom plugins/where to find docs on such a thing
[14:16] <kyrofa> hguant, hey there! I am indeed
[14:16] <kyrofa> hguant, this should get you started: https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md
[14:17] <kyrofa> hguant, I also have many examples for you to check out if you're interested, though you should be able to also refer to the plugins included within snapcraft itself
[14:17] <hguant> kyrofa nifty! Thanks very much
[14:17] <kyrofa> hguant, which are here: https://github.com/ubuntu-core/snapcraft/tree/master/snapcraft/plugins
[14:17] <kyrofa> hguant, no problem, please let me know if you have any questions
[14:18] <hguant> kyrofa will do, thanks again. be back after I read through all this
[14:18] <samerY> kyrofa - thanks also!
[14:19] <kyrofa> hguant, samerY any time
[14:30] <kgunn> zyga: hey, made significant changes to my PR
[14:30] <kgunn> https://github.com/snapcore/snapd/pull/1299
[14:30] <kgunn> might be ready for another pass
[14:30] <didrocks> kgunn: ohhhh, organize is actually applied in parts/part/install
[14:30] <didrocks> sorry
[14:31] <didrocks> kyrofa: ^
[14:31] <kgunn> :)
[14:31] <didrocks> kyrofa: so, it would work, even if snap: only refers to stage/
[14:31] <kyrofa> didrocks, ah, that makes sense
[14:31] <kyrofa> didrocks, indeed
[14:31] <didrocks> yeah, I don't know why it doesn't then, it's counter-intuitive, and I don't see good reason for not doing it that way
[14:35] <zyga> kgunn: I'll review them today, thank you for iterating on it
[14:35] <kgunn> zyga: thank you for your patience !
[14:36] <croepha> btw, I was having some wierd issues that I think were related to running snapcraft in a network mounted dir, I moved it out, and now im getting much more sensible errors :) I filed a bug (https://bugs.launchpad.net/snapcraft/+bug/1594374) with some ideas
[15:08] <jdstrand> seb128, mvo: we'll fix 1576066 but it is prioritzed after other work since people should be unblocked now that we added socketcall
[15:09] <seb128> jdstrand, we added it only to the network interface though
[15:09] <seb128> jdstrand, should we add network to the plugs in i386 even when not needed as a workaround?
[15:10] <jdstrand> zyga: re bug #1594318, that was the small pulseaudio change I mentioend over the weekend
[15:12] <jdstrand> seb128: I would prefer to add it to the default template as a work around by why is it so onerous to add "plugs: [ network ]"? are you sure it doesn't actually need network?
[15:12] <jdstrand> if it actually needs it, then adding to default policy with a huge comment makes more sense
[15:15] <seb128> jdstrand, I'm rebuilding with a modified wrapper to test, but I think it was hitting the bad syscall even when trying to start bash
[15:15] <seb128> jdstrand, it's not onerous to add network, just a non obvious workaround to make your snap work
[15:17] <jdstrand> snappy-debug would tell you to do so. if the app actually doesn't need network except for socketcall, then yes, it should be in template.go
[15:18] <elopio> ogra_: mvo: is this OK for you? https://github.com/ubuntu-core/snappy-jenkins/pull/179/files
[15:18] <jdstrand> I'm actually off today, so feel free to comment in backscroll and I'll get back to you
[15:18] <seb128> jdstrand, k, no worry, I hope you had a nice travel back, enjoy your day off!
[15:18] <mvo> elopio: yes, this actually makes more sense
[15:18] <seb128> jdstrand, you are back to work tomorrow?
[15:18] <mvo> elopio: sorry that I did not propose/catch this earlier
[15:18] <jdstrand> thanks!
[15:18] <ogra_> elopio, yeah, that looks a lot better
[15:18] <jdstrand> yes back tomorrow
[15:18] <seb128> jdstrand, I want to talk to you about getting dconf to work if we can
[15:18] <seb128> great
[15:19] <seb128> talk to you tomorrow then :-)
[15:19] <elopio> mvo: not your fault, at all. /me updates the live job.
[15:20] <elopio> beowulf: do you have some time for me today? :)
[15:20] <beowulf> elopio: what's up? :)
[15:21] <beowulf> elopio: have you seen https://github.com/snapcore/snapweb/pull/17
[15:21] <elopio> beowulf: you are too fast for me!
[15:21] <elopio> thanks!!!
[15:21] <beowulf> elopio: np
[15:21] <beowulf> elopio: check it does what you want first though :)
[15:21] <seb128> jdstrand, mvo, yeah, verified, /bin/bash fails to start on i386 without the network plug, hiting the syscall error, adding socketcall fixes it
[15:21] <jdstrand> seb128: if there isn'
[15:21] <elopio> I will try, but looks way better than mine already.
[15:22] <jdstrand> t a bug, file it, add snap-interface tag, mark it Triaged and assign to me please
[15:22] <seb128> jdstrand, k
[15:22] <jdstrand> I'll have a PR tomorrow then
[15:22] <seb128> and on that I let you to your day off work ;-)
[15:23] <seb128> thanks
[15:23] <pdurbin> https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ is interesting. It was linked from http://irclog.perlgeek.de/crimsonfu/2016-06-20
[15:23] <elopio> ogra_: There's now new package in there: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge
[15:28] <ogra_> elopio, perfect, and all of a sudden it is newer :)
[15:34] <matteo> where the snap t
[15:35] <matteo> download is actually done?
[15:49] <croepha> you guys are really trying to sell the "package for any Linux platform" feature, but I think the real boon is transactional updates and delta transfers...  The benefit for snappy that I see, is that I can (hopefully) be able to push apps to devices without having to worry about issues related heterogeneous states of those devices
[15:51] <ogra_> there are many strong points about snappy ... indeed transactional updates fall into that catregory too
[15:52] <ogra_> like rollbacks do
[15:52] <croepha> yea
[15:53] <joc_> zyga: hey, i made a change for your last comment and pushed, the checks appear to have failed but with some error related to access to go repositories
[15:55] <zyga> joc_: hmm
[15:55] <zyga> joc_: looking
[16:00] <samerY> hello, how does one include an older release of python to run a simple python program?
[16:01] <samerY> I've been able to unpack release with copy plugin
[16:02] <croepha> samerY: what version of python?
[16:02] <samerY> say 2.6.9
[16:02] <zyga> samerY: I guess you could look at "oldsnakes" ppa
[16:02] <zyga> samerY: and perhaps somehow use that
[16:02] <zyga> samerY: ideally someone would make a part for each version of python
[16:02] <zyga> samerY: that is built straight from upstream tarballs
[16:03] <croepha> can you specify a PPA for a stage-packages?
[16:05] <zyga> croepha: I don't know but I know there's a way to use your host PPA settings somehow
[16:05] <zyga> croepha: ask kyrofa; maybe he knows
[16:05] <croepha> kk, thanks
[16:05] <croepha> ill dig some more
[16:05] <kyrofa> zyga, croepha indeed, snapcraft will by default use your host settings
[16:06] <kyrofa> samerY, did you download debs then and copy them in via the copy plugin?
[16:07] <samerY> kyrofa: yes, I've been able to do that
[16:08] <kyrofa> samerY, does it not work?
[16:08] <samerY> oh wait, I feel like I'm overcomplicating this.. let me see
[16:10] <samerY> never mind..
[16:11] <samerY> I guess my next problem is how would I build Python2.6.9
[16:12] <samerY> as on host computer, I'd have to run "./configure" and then run make to produce interpreter
[16:12] <kyrofa> samerY, wait... why are you building it? I thought you got it from debs?
[16:15] <samerY> I'm not sure.. I assume to run a python file, I need to have python executable produced by building it
[16:15] <zyga> cwayne, joc: https://github.com/snapcore/snapd/pull/1301 merged :)
[16:15] <samerY> all I have are the 2.6.9 files from tarball?
[16:16] <cwayne> zyga <3
[16:16] <cwayne> joc_: ^
[16:17] <zyga> I'm sorry it took so long
[16:17] <zyga> let's do another :)
[16:19] <cwayne> zyga: no need to apologize, thanks for getting it done (and sorry for bugging you so much :P)
[16:19] <cwayne> zyga: joc's workin' on the next one already :)
[16:19] <joc_> thanks zyga
[16:19] <matteo> zyga: is possible to build snap with gccgo?
[16:20] <ayan> it is possible for a program to properly call seccomp() from within a snap?
[16:28] <Chipaca> jdstrand, do you know the answer to ayan's question without going and testing it?
[16:28] <Chipaca> jdstrand, he's trying to package the tor browser i think? (not 100% sure)
[18:02] <croepha> being able to run a shell in the same context of snapcraft stage would be useful for debugging
[18:04] <mhall119> hi all, is there a generic gtk-launch script like we have for qt?
[18:12] <Beornmar> Is there any way to get snapd on a Debian system other than downloading the source and building it?
[18:13] <josepht> Beornmar: there's a version in universe for sid: https://packages.debian.org/sid/snapd
[18:14] <Beornmar> josepht: Thanks!
[18:14] <josepht> Beornmar: np
[19:05] <croepha> is snappy-remote still a thing?
[19:24] <croepha> so, is current snapcraft incompatible wth 15.04 snappy ?
[19:28] <svij> croepha: yes
[19:28] <croepha> ok, thanks, that explains some things :)
[19:32] <croepha> if I wanted an updated (16) version of ubuntu core to test my snapcraft images, would I want to use ubuntu-device-flash with these files: http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/20160620/ ?
[19:56] <ehbello> where is `snappy service [start|restart|stop|etc]` command in last snapd???
[20:03] <mhall119> kyrofa: do you know how I can get a Gtk snap to send it's window menu over dbus to unity7?
[20:03] <kyrofa> mhall119, e.g. for the global menu?
[20:03] <Trevinho> mhall119: indeed it can
[20:03] <Trevinho> mhall119: just ensure you've proper libs in it and unity-gtk-menu lib installed
[20:04] <Trevinho> mhall119: check the hello-unity/calculator snaps
[20:04] <mhall119> Trevinho: ah, ok, and if I include that in the snap, will it be smart enough not to use is when running in non-unity DEs?
[20:04] <Trevinho> mhall119: sure
[20:05] <Trevinho> mhall119: it's up to u-p-s to enable or disable that
[20:06] <mhall119> ok
[20:12] <tedg> jdstrand: I'm getting a weird error that I think is coming from snap-confine
[20:12] <tedg> jdstrand: It is "failed to create user data directory. errmsg: Permission denied"
[20:13] <tedg> jdstrand: Could it be because of my encrypted home directory?
[20:13] <tedg> jdstrand: Jun 20 15:11:29 roku kernel: [195193.397698] audit: type=1400 audit(1466453489.213:95): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/ted/.Private/" pid=28973 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
[20:15] <tyhicks> tedg: see bug #1592696
[20:15] <tyhicks> tedg: a workaround is listed in the comments
[20:16]  * tedg is reading
[20:18] <swartzr> Snapcraft seems to be manipulating my shebang line at the start of a script, hardcoding my home directory into it. Am I missing something or is this not supposed to be happening?
[20:19] <swartzr> Is preventing my snap from running on other systems
[20:20] <tedg> tyhicks: Cool, that works for me. Thanks!
[20:21] <tyhicks> np
[20:31] <croepha> ubuntu-device-flash says it cant make an image for 16... any workarounds?
[21:13] <ehbello> croepha: https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
[21:25] <croepha> ehbello: Thanks very much!
[21:26] <ehbello> croepha: np ;)
[21:51] <johnsel> hello everyone
[21:53] <johnsel> i want to ship a device with an openvpn client + configuration
[21:53] <johnsel> what would be the high level tasks to integrate it?
[21:54] <johnsel> I see there's a gadget snap that supposedly can do system configuration
[21:54] <johnsel> not sure how i should approach it though
[22:13] <example6> Hi all -- I was wondering what would be the best way to connect to a wireless network from the command line, since /etc/network/interfaces seems to be on a readonly mount. I've read up a bit on wpa_supplicant, but am not sure where the best place to keep the file would be
[22:29] <zyga> example6: /etc/network/interfaces.d
[22:29] <zyga> example6: put a file in there
[22:29] <zyga> example6: it looks like typical ifupdown file
[22:38] <ehbello> I have a question... can we put a source block to build boot files inside a gadget snap package?
[23:53] <wililupy> Question--Has anyone seen this before? When I type my command for my snap, I get the proper command line output, but the command needs to run as sudo, so when I try that, it says it can't find the command. Any ideas?
[23:56] <kirkland> where can I find a beta image of Ubuntu Core 16, for 64-bit intel?
[23:56] <kirkland> to download
[23:56] <kirkland> basically, I want the latest test image of Ubuntu 16 equivalent, of http://people.canonical.com/~platform/snappy/ubuntu-core-15.04-intel-nuc.img.xz
[23:56] <wililupy> kirkland: you look in http://people.canonical.com/~mvo/all-snaps?
[23:57] <wililupy> kirkland: or you can build it with ubuntu-device-flash from the same location