=== Aria22 is now known as Aria22|away
[02:17] <sergiusens> elopio are you around?
[02:40] <elopio> sergiusens: yup.
[02:40] <sergiusens> elopio can you look at the last PR comment I made (the tour one)
[02:41] <sergiusens> elopio and for your branches. It may be late, but I want to land them :-)
[02:41] <elopio> sure, the night is young.
[02:43] <elopio> there's a duplicated line in there :/
[02:50] <sergiusens> elopio should we land #551?
[03:15] <croepha> so... been looking at snapcraft.yaml examples, it looks all of them are building from source... can you not simply say, install xyz packages from apt?
[03:41] <elopio> sergiusens: yes, we can move to the common setup in a different branch.
[03:45] <elopio> hum, the all-snaps servers are not working.
[03:52] <sgclark> mhall119: sergiusens: in regards to https://bugs.launchpad.net/snapcraft/+bug/1590599 I have been working on that snapcraft.yaml and it seems faster. Unfortunately, that one I did much experimenting and it had some cruft.
[03:52] <ubottu> Launchpad bug 1590599 in Snapcraft "snapcraft prerequites are slow to resolve" [Undecided,New]
[03:53] <sgclark> I will commit my changegs by the end of my night. Which of course should have been hours ago.
[03:53] <sgclark> snappy is addicting as I thought it would be :)
[04:35] <elopio> sgclark: I'm so glad you are enjoying it :)
[04:39] <sgclark> :)
[05:11] <sgclark> erg nope, still lots of qt4 going across and I am tired! I will sort this out tomorrow.
[05:23] <dougb> On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
=== Aria22|away is now known as Aria
=== Aria is now known as Aria|away
=== Aria|away is now known as Aria
[09:30] <ogra_> mvo, the new dir you added in livecd-rootfs ... is that supposed to become the mountpoint ?
[09:30] <mvo> ogra_: its for zyga
[09:30] <mvo> ogra_: its a confusing name
[09:30] <mvo> ogra_: it should probably be "hostsystem" or something
[09:30] <ogra_> why didnt you call it "zygas-dir" then :P
[09:30] <mvo> ogra_: :)
[09:31] <ogra_> ah,, k ... other way around then
[09:31] <ogra_> yeah, "host" or "hostfs" would be clearer
[09:33] <mvo> ogra_: lets rename it then, i will tell zyga
[09:33] <ogra_> sounds good :)
[09:33] <jennym> Hi, I am trying out some java projects in snapcraft. I would like to build two separate jar files from two java files, one of which depends on the other. I have a wrapper script which invokes java : java -cp HelloWorld-helper.jar:HelloWorld.jar oata.HelloWorld. However this doesn't run under snappy. I get a Error: Could not find or load main class error. It looks like I shouldn't set the classpath in the script like this. Any suggest
[09:36] <ogra_> jennym, there are maven and jdk plugins for snapcraft (i guess you could use the latter)
[09:37] <ogra_> there is a "java-hello-world" demo package at https://github.com/ubuntu-core/snapcraft/tree/master/demos, that might be of help
[09:38] <jennym> ogra_, thanks. I am using the ant plugin which works fine for a single source file/single jar file example.
[09:44] <jennym> ogra_, Yes my example is based on that but I extended it by making a src2 directory which resulted in a second jar being generated.
[09:45] <ogra_> and you modified the makefile and build.xml to take that into account ?
[09:49] <jennym> Yes. I also modified the wrapper script.
[09:53] <ogra_> didrocks, didnt you package java stuff before ^^^ ?
[09:53]  * ogra_ didnt
[09:55] <didrocks> elopio: sergiusens: once you are around, I think the "tour" part is done for next release. There are 3 related PR (note that the examples tests are failing in the image creation): https://github.com/ubuntu-core/snapcraft/pull/551, https://github.com/ubuntu-core/snapcraft/pull/558 and https://github.com/ubuntu-core/snapcraft/pull/559)
[09:55] <didrocks> jamiebennett: FYI, those are the 3 we need in next snapcraft release ^
[09:55] <didrocks> ogra_: I didn't, what's up?
[09:55] <ogra_> didrocks, well, just looking for someone who can help jennym
[09:56] <didrocks> hum, classpath and so on, I'm afraid I don't know enough java about this
[09:56] <jamiebennett> didrocks, OK, I presume sergiusens is well aware of these?
[09:56] <ogra_> yeah, same here ...
[09:56] <didrocks> maybe sergiusens or kyrofa may help (as they wrote the plugin) once around?
[09:56] <ogra_> yeah
[09:56] <didrocks> jamiebennett: with the above ping (the first PR was from some days ago, the last 2 from this morning)
[09:57] <jamiebennett> didrocks, OK
[09:57] <didrocks> jamiebennett: better if you double check as I guess we'll talk about release time and such, I didn't bother him with this yet
=== _morphis is now known as morphis
=== hikiko is now known as hikiko|ln
[10:52] <didrocks> jamiebennett: FYI, sergiusens is awake (but hiding) ;) first PR merged!
[10:52] <jamiebennett> didrocks, Ah
[10:52] <jamiebennett> :)
[11:02] <ogra_> didrocks, he is just sleepwalking
[11:02] <ogra_> s/walking/merging/
[11:02] <didrocks> heh
[11:02] <didrocks> I guess that's it, inded
[11:03] <didrocks> indeed*
[11:17] <sergiusens> jamiebennett didrocks yes, I always hide in the mornings ;-)
[11:19] <didrocks> ;)
[11:19] <didrocks> the silent merger!
[11:20] <sergiusens> didrocks ogra_ I think lool or mvo or mterry wrote those maven and ant plugins fwiw
[11:20] <sergiusens> didrocks well if it is all good, what noise is there to make :-)
[11:20] <ogra_> didrocks, probably with a quiet snoring ;)
[11:20] <didrocks> sergiusens: indeed :) keep me posted on the next 2 PR btw
[11:21] <didrocks> so that we can get 2.11 with the tour released and done
[11:22] <sergiusens> didrocks don't worry, if you EOD, we will do what we always do ;-)
[11:24] <didrocks> sergiusens: ah nice, seems that it can recreate now the vm (I retried it already this morning, it couldn't)
[11:25]  * didrocks does the same on the other PR
[11:26] <jennym> didrocks, sergiusens, ogra_ : I have solved my problem. Actually I didn't need to change the wrapper script (this is in reference to the original java-hello-world example). When there are two jar files generated by the ant task, the are both added to the classpath by snapcraft.
[11:26] <sergiusens> didrocks yeah, we run out of instances fast, at least the jobs fail fast
[11:26] <ogra_> jennym, cool !
[11:26] <didrocks> jennym: excellent! so default are good! :)
[11:27] <didrocks> sergiusens: ah, ok, that's the reason
[11:27] <sergiusens> oh, sorry jennym I didn't even read what your problem was. I was just stating a fact that I didn't write the plugin. It does add every jar it builds to CLASSPATH indeed
[11:28] <jennym> By adding a -cp argument to the java command in the wrapper script I was probably upsetting the previously set classpath.
[11:29] <jennym> I am now going to try another extension to the example by including a jar file which is built externally. So I might get back about that. Thanks all.
[11:32] <gouchi_> hi
[11:32] <gouchi_> any tips how to fix this apparmor denied access http://www.hastebin.com/unuyijupiy.vhdl ?
[11:33] <ogra_> gouchi_, i think popey filed a bug for exactly that
[11:34]  * ogra_ cant find the number atm
[11:37] <ogra_> gouchi_, bug 1589671
[11:37] <ubottu> bug 1589671 in Snappy "apparmor failure on udev with opengl interface" [Undecided,Confirmed] https://launchpad.net/bugs/1589671
[11:37] <gouchi_> ogra_: thank you
=== hikiko|ln is now known as hikiko
[11:44] <dholbach> seb128, attente: have you seen anything like this already? https://files.gitter.im/ubuntu/snappy-playpen/9taf/ristretto.png
[11:44] <dholbach> that's with https://github.com/ubuntu/snappy-playpen/tree/ristretto/ristretto
[11:57] <seb128> dholbach, seems like fonts missing
[11:57] <seb128> do you have the fontconfig hacks in your wrapper?
[11:57] <seb128> # Font Config
[11:57] <seb128> export FONTCONFIG_PATH=$SNAP/etc/fonts/config.d
[11:57] <seb128> export FONTCONFIG_FILE=$SNAP/etc/fonts/fonts.conf
[11:57] <seb128> seems you have
[11:57] <seb128> any command line error?
[11:58] <ogra_> dont you need to generate a font cache too ?
[11:58] <ogra_> or am i living in the past
[11:59] <ogra_> iirc there used to be a command
[11:59] <didrocks> seb128: that was exactly my answer gitter :p
[12:00] <ogra_> update-fonts-dir ...
[12:00] <ogra_> that was the one
[12:00] <ogra_> and -alias
[12:02] <ogra_> hmm
[12:03] <ogra_> or was it fc-cache
[12:05] <seb128> ogra_, unsure, it works for other gtk and qt apps with no extra update command
=== vejmarie_ is now known as vejmarie
[12:17] <ogra_> lundmar, bug 1566604
[12:17] <ubottu> bug 1566604 in Snappy "the snap command has no autocompletion" [Medium,Triaged] https://launchpad.net/bugs/1566604
[12:19] <lundmar> ogra_: not quite the same issue.
[12:20] <ogra_> well, then file a new bug :)
[12:20] <lundmar> snap is installed using apt and I assume its completion script is installed the convetional way.
[12:20] <dholbach> ogra_, I copied the bits from the galculator snap
[12:20] <lundmar> The questions is, how do we support enablement of completion scripts included in snaps?
[12:21] <lundmar> question*
[12:21] <ogra_> dholbach, right,, and i dont see any font cache generatin in that script ... thats why i mentioned it
[12:21] <dholbach> ok
[12:21] <lundmar> I've just create the "tio" snap. However, the system does not pick up on the completion script that the snap installs?
[12:21] <ogra_> lundmar, ah, you mean /snap/bin binaries ?
[12:21] <lundmar> created*
[12:22] <lundmar> ogra_: exactly
[12:22] <ogra_> well, it works for the binaries in there
[12:22] <ogra_> ogra@styx:~$ free<tab><tab>
[12:22] <ogra_> free             freecad.FreeCAD  freetype-config
[12:23] <ogra_> freecad.FreeCAD is from a snap
[12:23] <seb128> dholbach, do you want me to have a look to the font thing?
[12:23] <dholbach> I think that was fixed in your version of the snap
[12:23] <lundmar> sure, but the actual app completion is not working because the system only sources the apt installed completion scripts
[12:23] <dholbach> I just filed https://github.com/ubuntu/snappy-playpen/issues/46 for this
[12:23] <ogra_> (it cant autocomplete options though)
[12:23] <dholbach> I'll try to fix it in both snaps
[12:24] <ogra_> lundmar, well, file a bug :)
=== JanC is now known as Guest27912
=== JanC_ is now known as JanC
[12:24] <lundmar> ogra_: will do .)
[12:25] <ogra_> :)
[12:25] <lundmar> source /snap/*/current/usr/share/bash-completion/completions/*
[12:26] <ogra_> well, i doubt we want it *that* generic
[12:26] <lundmar> well, thats the gist of it :)
[12:26] <ogra_> rather have snapd bind-mount /snap/*/current/usr/share/bash-completion/completions/ content to some system dir to de-couple it
[12:27] <ogra_> i think that goes into the same category as manpages ... iirc jdstrand discussed the security side yesterday somewhere
[12:27] <ogra_> (for manpages that is)
[12:30] <lundmar> its kind of a layering issue, probably completion scripts or even man pages intalled by system (apt) should take precedence.
[12:31] <kyrofa> mhall119, nice bug, thank you!
[12:31] <lundmar> in my case I've just created a snap "tio" which includes a completion script. Would be nice if the completion script could be automatically enabled.
[12:37] <ogra_> lundmar, well, the thing is that the snap itself doesnt not actually run on your system but inside the ubuntu-core snap ... all logic to hook something up to the outside world needs to happen in snapd and under special security observation
[12:37] <ogra_> does not
[12:38] <lundmar> it runs as a container?
[12:39] <ogra_> no
[12:39] <ogra_> but with the core snap as execution environment
[12:40] <ogra_> or s/execution environment/rootfs/ ... however you want to put it :)
[12:41] <lundmar> well, I did discover the snap is basically a squashfs so I did learn that haha
[12:41] <lundmar> so snaps gets mounted and run by snapd within its own environment.
[12:41] <lundmar> got it
[12:42] <ogra_> yeah ... and interfaces allow them to talk to the outside world (or to specific acpects of the core snap)
[12:42] <ogra_> aspects
[12:42] <lundmar> still, the current completion system is outside. So I would figure this case simply requires and exception to the rule
[12:44] <ogra_> indeed, but you also want to prevent a malicious snap from shipping some completion rule that can exploit some security issue in the bash-completion system to take over  your host system
[12:44] <ogra_> so this needs very careful crafting
[12:44] <lundmar> true
[12:46] <lundmar> maybe the solution would be to qualify snaps somehow but that would kind of go against the agility of snaps I guess.
[12:50] <lundmar> https://bugs.launchpad.net/snappy/+bug/1590767
[12:50] <ubottu> Launchpad bug 1590767 in Snappy "Support snap installed completion scripts" [Undecided,New]
[12:52] <ogra_> good
[12:54] <lundmar> since it is pre-runtime it is difficult to see a solution that does not somehow require trusting that the application completion script is good.
[12:56] <jdstrand> container/not container... ehh... it isn't a doc container. it is a snappy container if you will-- we use a bunch of things from the container world and then wrap it in apparmor (which can be thought of as a container) and seccomp
[12:56] <jdstrand> s/doc/docker/
[12:56] <jdstrand> basically, we use whatever we can to make things secure :)
[12:56] <lundmar> ok, so simple a process with limited resources ^^
[12:56] <ogra_> :)
[12:56] <lundmar> simply*
[12:58] <jdstrand> lundmar: bash completion is an interesting problem. I'm not sure if you saw the 'Man-pages in snaps' thread on snapcraft@, but ogra is right. hooking into completion means there is a way to execute code outside of the snap's confinement
[12:59] <jdstrand> lundmar: can you file a bug and add the snapd-interface tag?
[12:59] <ogra_> unlike man this isnt easily solvable by having a snapped binary in this case though
[12:59] <lundmar> I figure it is kind of the same issue, maybe worse for completion but both are outside the reach of containers
[12:59] <jdstrand> I can imagine ways to possibly do this
[12:59] <jdstrand> ogra_: right
[12:59] <jdstrand> lundmar: yes-- since it is a script
[12:59] <lundmar> exactly
[13:00] <jdstrand> but imagine we had a new executable: snap-completion
[13:00] <lundmar> so, how to trust the completion script?
[13:00] <jdstrand> imagine that runs under a restrictive apparmor profile
[13:00] <jdstrand> bash is modified to call snap-completion <script> if <script> is in say //var/lib/snapd/completion
[13:01] <jdstrand> or something
[13:01] <jdstrand> basically, we get bash to run the script confined
[13:01] <jdstrand> I'm not saying that is the way we would do it, but I think there are possibilities for making it work
[13:03] <lundmar> bash ro to run the script confied? what does that mean? in the end the completion script will reside in the memory of the running bash session right?
[13:03] <lundmar> confined*
[13:04] <lundmar> I mean, once the bash completion script is sourced by the bash session it can do whatever it likes, just like the system installed scripts.
[13:05] <ogra_> but your confined script would parse it first (under heavy restrictions)... and also run some content checks before it gets to bash
[13:07] <lundmar> I think the question is, how safe are regular completion scripts and should snap comletion scripts be safer?
[13:08] <lundmar> you can make checks if you like but any safeguards I suspect will be easy to circumvent
[13:12] <lundmar> it is a tough seurity problem but snaps without man pages and completion scripts quickly gets painful I think.
=== JanC_ is now known as JanC
[13:12] <lundmar> security*
[13:13] <ogra_> well
[13:13] <ogra_> that really depends on the target audience
[13:14] <ogra_> i guess 98% of computer users in the world do not know what a manpage is
[13:15] <lundmar> sure, and for the point and click end users it is a non-issue.
[13:16] <lundmar> but for experienced users it is
[13:16] <lundmar> I figure snap caters for both
[13:19] <ogra_> well, curretly snap focuses on attracting developers by making their life as easy as possible ... long term i think the point and click users are the target ...
[13:19] <ogra_> but for the first we need to give the devs a comfortable way to ship manpages and completion scripts ... so it definitely is part of it
[13:19] <ogra_> even if both features will pprehaps never be used by the final target audience
[13:20] <lundmar> wouldnt be a proper package system without it ;)
[13:20] <ogra_> *perhaps
[13:20] <ogra_> well, i think since a long time that documentation should not be part of a package :)
[13:20] <davidcalle> sergiusens: can you join us in 10-ish minutes on a hangout to talk about the blog post? (if not, that's alright, email will do)
[13:21] <ogra_> but thats personal opinion
[13:21] <lundmar> well, it is a set that needs to match so decoupling those is troublesome.
[13:23] <ogra_> not if your packaging system would for example have an automated way to turn your shipped docs into versioned online docs and simply rip them out from the package
[13:24] <lundmar> you cant trust online to be "online", bad idea - you can always trust man :)
[13:25] <ogra_> i often enough find myself googling for a manpage instead of using my terminal ... and in the end read it on manpages.ubuntu.com
[13:26] <ogra_> (though in the majority of cases where i need docs --help is even enough and that doesnt need any special system)
[13:26] <lundmar> tsk tsk, and the you find an out of date man page and you don't even notice it.
[13:26] <lundmar> then*
[13:26] <ogra_> manpages are kind of and intersection between --help and a proper hwto
[13:26] <ogra_> *howto
[13:29] <lundmar> man pages are much more complete while --help is more or less just a listing.
[13:29] <ogra_> yes, thats what i meant with "intersection"
[13:30] <lundmar> I wouldn't do without manpages
[13:30] <lundmar> neither completion scripts ^^
[13:30] <ogra_> :)
[13:36] <lundmar> anyway, I've created the bug report. I don't expect to see a solution due to the potential security issues.
[13:36] <jdstrand> and I commented
[13:37] <jdstrand> I think there might be a way to do it, but it would require a bit of design and engineering (and would need to be prioritiezed)
[13:42] <lundmar> it surely requires some bash magic and maybe even internals changes
[13:44]  * jdstrand nods
[13:45] <lundmar> I guess if you could use a pipe to somehow bridge the normal bash session with a confined bash session running the actual completion function that might do the trick
[13:45] <lundmar> but jez, it would take time to dig into that crusty ol code base of bash ^^
[13:47] <lundmar> only problem is, what if the string feed is malicious?
[13:47] <lundmar> tricky tricky tricky :)
[13:49] <jdstrand> indeed
[13:50] <seb128> what does "no handler to manage source" mean from snapcraft?
[13:50] <jdstrand> we'd probably have to have an aggressive output filter, but I would think legitimate completion commands would pass that filter easily
[13:51] <lundmar> jdstrand: probaly filtering out non-readable chars would solve the problem of malicious feed from the confined session
[13:51] <lundmar> jdstrand: oh, we thought the same hehe
[13:51] <jdstrand> non-readable, shell metachars
[13:51] <jdstrand> yep
[13:52] <lundmar> so, in the end it will depend on the state of bash internals ^^
[13:58] <kgunn> jdstrand: i finally got round to a pr for mir
[13:58] <kgunn> https://github.com/snapcore/snapd/pull/1299
[13:58] <kgunn> i see zyga is out...
[14:00] <kyrofa> seb128, it means you put something in the `source` key that snapcraft can't figure out
[14:00] <kyrofa> seb128, or it uses a version control system that it doesn't currently support (e.g. svn)
[14:02] <seb128> kyrofa, thanks, the error could be more descriptive :-)
[14:03] <lundmar> what, snapcraft doesn't support CVS?? :D
[14:03] <kyrofa> seb128, please log a bug! You're right, it could be more helpful
[14:03] <seb128> kyrofa, I had "source: https://git.gnome.org/browse/gucharmap" works with "source-type: git"
[14:04] <kyrofa> seb128, ah, yeah autodiscovery problem
[14:04] <kyrofa> seb128, it doesn't hit the URL and figure it out, it does it by pattern on the source itself
[14:04] <kyrofa> seb128, the only way it figures git out without `source-type` is if it ends in .git
[14:04] <seb128> kyrofa, if the url contains "git" it could assume it's a git repo
[14:05] <seb128> but fair enough
[14:05] <kyrofa> seb128, also fair
[14:05] <seb128> at least the message could state "can't figure source type, please specify one using source-type:"
[14:05] <kyrofa> seb128, agreed
[14:06] <ogra_> lundmar, write a plugin, patches accepted !
[14:08] <lundmar> CVS is an abomination to be left behind.
[14:09] <lundmar> chocked to still dicsover foss projects using it
[14:09] <seb128> kyrofa, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590797
[14:09] <ubottu> Launchpad bug 1590797 in snapcraft (Ubuntu) ""no handler to manage source" is not an helpful error" [Undecided,New]
[14:09] <seb128> kyrofa, unsure if I should open another one for the " if the url starts with "http(s)://git" it could probably be autoguessed as being a git source" part?
[14:11] <seb128> kyrofa, I would probably got as far as 'if contains "git"' but I guess 'start with http://git..." is a safe bet
[14:11] <seb128> if you provide a svn repo on a git.something url you are asking for issues :p
[14:21] <croepha> anyone here having trouble running docker containers under privileged mode? im getting `Error response from daemon: Cannot start container test: open /dev/dri: permission denied` I already tried chmod a+rwx /dev/dri  with no avail... any suggestions?
[14:26] <ogra_> oooh
[14:26] <didrocks> jdstrand: hey! in case you didn't notice, I asked a contributor to open a bug he's having on neovim: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1590720
[14:26]  * ogra_ just noticed the "Price" column in snap find output
[14:26] <ubottu> Launchpad bug 1590720 in snapd (Ubuntu) "neovim snap package freezes when saving a file (fchown)" [Undecided,New]
[14:27] <ogra_> heh, old topic
[14:31] <zyga> o/
[14:31] <zyga> hello snappers :)
[14:31] <ogra_> yo
[14:33] <didrocks> hey zyga!
[14:41] <dougb> Good morning all
[14:41] <dougb> On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
[14:45] <didrocks> ogra_: do you know? ^
[14:46] <ogra_> didrocks, i dont, sorry ...
[14:46] <ogra_> seems you need to set a kernel cmdline var
[14:47] <ogra_> hmm or not ... that seems to only work with hacked kernels that suppport capemgr
[14:48] <ogra_> ours kernel is plain mainline without these patches
[14:49] <croepha> so, is the snap that is a part of the 15.04 ubuntu core release the same snap that is part of the ubuntu 16.04 (non core) release?
[14:50] <dougb> ogra_:Does that mean we’ll have to wait for built-in functionality to be able to connect through the other serial ports?
[14:51] <ogra_> dougb, well, i fear you would need a different kernel ... or find out how to enable UARTs on a non capemgr kernel
[14:54] <dougb> That sounds like there are currently no plans for implementing this.
[14:54] <ogra_> well, someone should probably create an rcn-ee kernel for the beaglebone
[14:54] <ogra_> based off his tree
[14:55] <ogra_> (building a kernel snap is rather trivial ... )
[14:56] <croepha> im just jumping in here mid conversation, but if there is a kernel that works you can diff the configs to find out what you need to customize, might make thing easier
[14:57] <ogra_> well, this is more about patch sets than configs
[14:57] <ogra_> the beaglebone uses a patchset that has never made it upstream
[14:57] <croepha> ahh ok
[14:58] <ogra_> the only kernel we have in the store for beagle is rather close to mainline (the ubuntu generic kernel built for armhf actually ... )
[14:59] <ogra_> so someone would have to roll a kernel with the capemanager patches specifically for the beaglebone and push it to the store
[14:59] <jkridner> ogra_: those patches have gotten pretty small now that device tree overlays are mainline.
[15:01] <croepha> so, is the snappy that is part of the 16.04 desktop release significantly newer than what is available in the latest core release? (15.04)
[15:02] <ogra_> jkridner, ah, but i guess not in 4.4
[15:02] <jkridner> not completely.
[15:02] <ogra_> croepha, yes, there were no core images for 16 yet
[15:03] <ogra_> they are about to happen soon
[15:03] <ogra_> everyone focuses on desktop atm so people can create snaps ... images come once desktop has all the basics
[15:04] <croepha> ogra_, I can wait, im just trying to understand the current state of things, would like to play around, but was confused by the differences between desktop and core
[15:04] <ogra_> well, 15.04 was rather a first shot ...
[15:05] <ogra_> the 16 series is the real thing ... and will be around for 5 years
[15:10] <jdstrand> didrocks: responded
[15:10] <didrocks> jdstrand: thanks a bunch! :)
[15:12] <jdstrand> np
[15:12] <dougb> ogra_: and the rest, thanks for the feedback. I’ll let you know what we come up with.
[15:12] <ogra_> if you need any help, dont hold back your questions ;)
[15:12] <dougb> Great!
[15:13] <croepha> it seems like docker is missing from "snap find" on 16.04
[15:13] <ogra_> yep
[15:13] <croepha> haven't gotten to that one yet?
[15:13] <ogra_> yeah, i guess ...
[15:13] <ogra_> not sure who does it ...
[15:14] <ogra_> lxc and lxd are also missing
[15:21] <didrocks> elopio: hey! I don't see other command integration tests in integration_tests/* (apart from the lifecycle ones, but nothing about build and so on…), am I looking at the right directory to add it?
[15:24] <aatchison> Hmm, I canna get ubuntu-core to run on the pi 2 or 3 right now...
[15:25] <aatchison> Are there any crazy daily builds or ultimate unstable beta images I could get my hands on? :D
[15:25] <ogra_> aatchison, http://people.canonical.com/~mvo/all-snaps/ ... a bit outdated though
[15:26] <ogra_> you can also use the ubuntu-device-flash from there to create more recent images
[15:26] <aatchison> awesome! Thanks
[15:26] <ogra_> note though that the gadget and kernel stuff is in flux ... so you will likely have to re-flash before we release the first official images
[15:28] <aatchison> That's quite alright. I'm developing on the edge of chaos as well
[15:29] <ogra_> :D
[15:29] <croepha> so, in a snapcraft.yaml, is there a way to simply say, "install these apt packages" ?
[15:30] <ogra_> yeah, stage-packages
[15:30] <croepha> cool, thanks
[15:37] <mhall119> sergiusens: I'm not the only one who's been bit by https://bugs.launchpad.net/snapcraft/+bug/1590834
[15:37] <ubottu> Launchpad bug 1590834 in Snapcraft "cleanbuild leaves abandoned LXC containers" [Undecided,New]
[15:39] <ogra_> mhall119, shhh ... dont reveal our secret contracts with seagate to trick people into buying larger disks fast !
[15:40] <mhall119> also, is snapd supposed to remove old versions of snaps?
[15:40] <ogra_> it does if you snap remove
[15:40] <mhall119> but what if I'm just installing new versions?
[15:40] <ogra_> it seems to not do it when you manually sideload snaps over and over
[15:40] <mhall119> I currently have 5 versions of plank loop-mounted
[15:40] <ogra_> right
[15:40] <ogra_> i think thats a bug
[15:41] <mhall119> ogra_: will it at least do it if you install updates from the store?
[15:41] <ogra_> no idea, i know they are all wiped if you snap remove
[15:41] <mhall119> yeah, but that's not ideal :)
[15:41] <ogra_> i think if you have the store invlved you will always only have two revisions installed
[15:41] <ogra_> (ICBW though)
[15:42] <davidcalle> Well, first you collect planks, then you build cubes, then houses...
[15:42] <mhall119> ogra_: https://bugs.launchpad.net/snapcraft/+bug/1590842 for that one
[15:42] <ubottu> Launchpad bug 1590842 in Snapcraft "snapcrafting eats up disk space /dev/loop" [Undecided,New]
[15:42] <davidcalle> Oh sorry, it's the snapcraft channel, not minecraft :p
[15:43] <mhall119> davidcalle: :-P
[15:43] <sgclark> yeah I have been snapcrafting tons, and I woke up this morning to a very cranky hard drive
[15:44] <ogra_> we can probably get you a discount at seagate for a nice little raid array :)
[15:44] <sgclark> lol
[15:44] <ogra_> :)
[15:44] <sgclark> I am eying a partition I do not use much anymore haha
[15:47] <didrocks> elopio: I went ahead and added one in the integration_tests/ dir
[15:52] <kyrofa> sgclark, the bug you just logged-- that's from `snap try`, yes?
[15:52] <sgclark> no, have not heard of snap try
[15:52] <sgclark> that is snap install
[15:53] <kyrofa> sgclark, oh *cough* ignore me
[15:53] <sgclark> what is snap try?
[15:53]  * sgclark tries snap try next build
[15:53] <kyrofa> So you're just installing the built snaps and finding that they stick around forever essentially?
[15:53] <sgclark> yes
[15:54] <sgclark> remove does indeed clear that all up, I am starting to get me disk space back lol
[15:54] <kyrofa> sgclark, `snap try` will let you run directly out of the snap/ directory
[15:54] <sgclark> ah ok
[15:54] <kyrofa> sgclark, but it's not perfect yet-- if you `snap try` something and then `snapcraft clean` it up, snapd barfs all over you
[15:54] <sgclark> oh haha
[15:55] <kyrofa> sgclark, snapd will automatically clean that up soon, but for now, be aware: if `snap try`ing, `snap remove` it before `snapcraft clean`ing
[15:55] <sgclark> would not be my first barf, but noted :)
[15:55] <sgclark> k
[15:55] <kyrofa> Regarding the snaps hanging around forever, that surprises me a little. I swear I saw code that only kept three revisions
[15:56] <kyrofa> But maybe that doesn't apply to sideloaded snaps
[15:56] <ogra_> kyrofa, well, has that landed in xenial yet ?
[15:56] <kyrofa> ogra_, snap try?
[15:56] <ogra_> the cleanup code
[15:56] <sgclark> oh yeah I am in xenia;
[15:56] <sgclark> xenial*
[15:56] <kyrofa> ogra_, heh, sorry, which cleanup code? Cleaning up snap try, or cleaning up old revisions?
[15:57] <ogra_> old revisions
[15:57] <ogra_> :)
[15:57] <sgclark> ok all cleaned up lol
[15:57] <kyrofa> ogra_, I saw it like a month ago, so I'd say yes. But it may have been removed since then :P
[15:57] <ogra_> heh, or renamed and nobody knew :)
[15:58] <kyrofa> Maybe. I'll check
[15:59] <kyrofa> Anyway, sgclark thanks for the report
[15:59] <sgclark> np, happy to help
[16:04] <kyrofa> ogra_, sgclark sounds like I saw old code that didn't apply anymore. It's planned though. I'm going to reassign the bug to snapd
[16:04] <ogra_> yeah, i knew it was planned and i saw it discussed ... but it is definitely still here :)
[16:05] <aatchison> Ok. I'm going to dig in as deep as I can here. I want to get my launch pad stuff all set up, including building debs.
[16:08] <kyrofa> Hey aatchison!
[16:08] <aatchison> hey!
[16:15] <ogra_> hmm ... why dont we have a wine plugin yet ...
[16:16] <ogra_> having such a thing would open up a completely new world for delivering windows apps to users :)
[16:16] <sgclark> ooh indeed
[16:16] <ogra_> (but also a can of legal worms most likely )
[16:17] <sgclark> lol
[16:17] <sgclark> there is that
[16:25] <popey> i tried packaging wine itself
[16:26] <popey> it almost works, might play again over the weekend
[16:31] <ogra_> yeah, having it as a template to actually bundle apps might be interesting
[16:31] <ogra_> you can bundle the actually working wine version then
[16:41] <croepha> is there an online search for the snappy store?
[16:57] <sergiusens> seb128 thanks for those bug reports, really helpful stuff!
[16:58] <seb128> sergiusens, yw!
[17:03] <wililupy> Question: Is there a way to build a kernel snap from a deb package?
=== Aria is now known as Aria|away
=== Aria|away is now known as Aria
=== Aria is now known as Aria22
[19:47] <jdstrand> niemeyer: hi! would you mind commenting on https://bugs.launchpad.net/snappy/+bug/1590679/comments/6 ? I don't need it this second but would like to work on it tomorrow
[19:48] <ubottu> Launchpad bug 1590679 in snapd (Ubuntu) "Apps can't own session bus names (unity7 interface)" [High,Confirmed]
[19:49] <niemeyer> jdstrand: Will have a look later today
[19:49] <jdstrand> awesome, thanks
[19:49] <niemeyer> jdstrand: I need to step out now or will miss the window of sun :)
[19:49] <jdstrand> get some vitamin D! :)
[19:55] <sergiusens> elopio should this work `super(snapcraft.BasePlugin, self).build()` ?
[20:07] <elopio> sergiusens: I'm wondering about the arguments of super in there. I suppose you are adding that because you are not in the snapcraft.BasePlugin class ?
[20:11] <elopio> anyway, if you are not in the build method, and you can't just call it super().build(), it will probably do weird things. It might work for what you need, but I doubt it's a good idea.
[20:12] <sergiusens> elopio I inherited a plugin for most of what it does, but I want to skip the parent's implementation and call the grandparent directly
[20:16] <elopio> super().super().build()
[20:17] <elopio> sergiusens: it's not so good either, you should doubt about your inheritance tree at this moment, because it's not a tree. But should work.
[20:29] <sergiusens> elopio so I'll just copy then
[20:38] <josepht> sergiusens: if you can modify the parent code you could add a method that invokes the grandparent's build() and nothing else
[20:46] <sergiusens> josepht as super_build() :-)
[20:46] <sergiusens> josepht feels dirty, but I guess that works
[20:51] <sgclark> hi all, I see this quite often http://paste.ubuntu.com/17155796/ and I have network and network-bind plug, what am I missing?
[20:52] <sgclark> most of our stuff has a newstuff feature for addons and the like
[21:01] <sergiusens> elopio kyrofa https://github.com/ubuntu-core/snapcraft/pull/561
[21:01] <sergiusens> sgclark that is dbus, right? network-* won't solve that, but jdstrand can
[21:01] <sergiusens> :-)
[21:02] <sgclark> lol
[21:02] <sgclark> and yes
[21:02] <sgclark> dbus
[21:02] <sergiusens> sgclark for now I guess devmode is the fastrack path
[21:02] <sgclark> yeah that works
[21:33] <wililupy> How do I get ethtool and bridge-utils to be native? Should I add an app: section to my yaml to allow me to run these? also does snappy not look for other network devices other than ethx?
[21:34] <wililupy> I added a udev rule to the system, but it doesn't seem to be working.
=== eriow is now known as erio
[22:43] <jdstrand> sgclark: you need to specify 'plugs: [ network-manager ]' and after install do: sudo snap connect <snapname>:network-manager ubuntu-core:network-manager
[22:44] <sgclark> jdstrand: ok thank you
[22:44] <jdstrand> sure thing
[22:44] <jdstrand> I'm stepping away now, but I read backscroll
=== wililupy is now known as wililupy|away
=== wililupy|away is now known as wililupy