| === Aria22 is now known as Aria22|away | ||
| sergiusens | elopio are you around? | 02:17 |
|---|---|---|
| elopio | sergiusens: yup. | 02:40 |
| sergiusens | elopio can you look at the last PR comment I made (the tour one) | 02:40 |
| 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:41 |
| elopio | there's a duplicated line in there :/ | 02:43 |
| sergiusens | elopio should we land #551? | 02:50 |
| 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:15 |
| elopio | sergiusens: yes, we can move to the common setup in a different branch. | 03:41 |
| elopio | hum, the all-snaps servers are not working. | 03:45 |
| 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:52 |
| 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 :) | 03:53 |
| elopio | sgclark: I'm so glad you are enjoying it :) | 04:35 |
| sgclark | :) | 04:39 |
| sgclark | erg nope, still lots of qt4 going across and I am tired! I will sort this out tomorrow. | 05:11 |
| dougb | On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy? | 05:23 |
| === Aria22|away is now known as Aria | ||
| === Aria is now known as Aria|away | ||
| === Aria|away is now known as Aria | ||
| 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:30 |
| ogra_ | ah,, k ... other way around then | 09:31 |
| ogra_ | yeah, "host" or "hostfs" would be clearer | 09:31 |
| 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:33 |
| ogra_ | jennym, there are maven and jdk plugins for snapcraft (i guess you could use the latter) | 09:36 |
| 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:37 |
| jennym | ogra_, thanks. I am using the ant plugin which works fine for a single source file/single jar file example. | 09:38 |
| 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:44 |
| ogra_ | and you modified the makefile and build.xml to take that into account ? | 09:45 |
| jennym | Yes. I also modified the wrapper script. | 09:49 |
| ogra_ | didrocks, didnt you package java stuff before ^^^ ? | 09:53 |
| * ogra_ didnt | 09:53 | |
| 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:55 |
| 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:56 |
| 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 | 09:57 |
| === _morphis is now known as morphis | ||
| === hikiko is now known as hikiko|ln | ||
| didrocks | jamiebennett: FYI, sergiusens is awake (but hiding) ;) first PR merged! | 10:52 |
| jamiebennett | didrocks, Ah | 10:52 |
| jamiebennett | :) | 10:52 |
| 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:02 |
| didrocks | indeed* | 11:03 |
| sergiusens | jamiebennett didrocks yes, I always hide in the mornings ;-) | 11:17 |
| didrocks | ;) | 11:19 |
| didrocks | the silent merger! | 11:19 |
| 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:20 |
| didrocks | so that we can get 2.11 with the tour released and done | 11:21 |
| sergiusens | didrocks don't worry, if you EOD, we will do what we always do ;-) | 11:22 |
| didrocks | sergiusens: ah nice, seems that it can recreate now the vm (I retried it already this morning, it couldn't) | 11:24 |
| * didrocks does the same on the other PR | 11:25 | |
| 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:26 |
| 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:27 |
| jennym | By adding a -cp argument to the java command in the wrapper script I was probably upsetting the previously set classpath. | 11:28 |
| 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:29 |
| gouchi_ | hi | 11:32 |
| gouchi_ | any tips how to fix this apparmor denied access http://www.hastebin.com/unuyijupiy.vhdl ? | 11:32 |
| ogra_ | gouchi_, i think popey filed a bug for exactly that | 11:33 |
| * ogra_ cant find the number atm | 11:34 | |
| 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 | 11:37 |
| === hikiko|ln is now known as hikiko | ||
| 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:44 |
| 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:57 |
| ogra_ | dont you need to generate a font cache too ? | 11:58 |
| ogra_ | or am i living in the past | 11:58 |
| ogra_ | iirc there used to be a command | 11:59 |
| didrocks | seb128: that was exactly my answer gitter :p | 11:59 |
| ogra_ | update-fonts-dir ... | 12:00 |
| ogra_ | that was the one | 12:00 |
| ogra_ | and -alias | 12:00 |
| ogra_ | hmm | 12:02 |
| ogra_ | or was it fc-cache | 12:03 |
| seb128 | ogra_, unsure, it works for other gtk and qt apps with no extra update command | 12:05 |
| === vejmarie_ is now known as vejmarie | ||
| 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:17 |
| lundmar | ogra_: not quite the same issue. | 12:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| ogra_ | lundmar, well, file a bug :) | 12:24 |
| === JanC is now known as Guest27912 | ||
| === JanC_ is now known as JanC | ||
| lundmar | ogra_: will do .) | 12:24 |
| ogra_ | :) | 12:25 |
| lundmar | source /snap/*/current/usr/share/bash-completion/completions/* | 12:25 |
| 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:26 |
| 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:27 |
| lundmar | its kind of a layering issue, probably completion scripts or even man pages intalled by system (apt) should take precedence. | 12:30 |
| 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:31 |
| 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:37 |
| lundmar | it runs as a container? | 12:38 |
| ogra_ | no | 12:39 |
| ogra_ | but with the core snap as execution environment | 12:39 |
| ogra_ | or s/execution environment/rootfs/ ... however you want to put it :) | 12:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| lundmar | maybe the solution would be to qualify snaps somehow but that would kind of go against the agility of snaps I guess. | 12:46 |
| lundmar | https://bugs.launchpad.net/snappy/+bug/1590767 | 12:50 |
| ubottu | Launchpad bug 1590767 in Snappy "Support snap installed completion scripts" [Undecided,New] | 12:50 |
| ogra_ | good | 12:52 |
| 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:54 |
| 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:56 |
| 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:58 |
| 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 | 12:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| ogra_ | but your confined script would parse it first (under heavy restrictions)... and also run some content checks before it gets to bash | 13:05 |
| lundmar | I think the question is, how safe are regular completion scripts and should snap comletion scripts be safer? | 13:07 |
| lundmar | you can make checks if you like but any safeguards I suspect will be easy to circumvent | 13:08 |
| lundmar | it is a tough seurity problem but snaps without man pages and completion scripts quickly gets painful I think. | 13:12 |
| === JanC_ is now known as JanC | ||
| lundmar | security* | 13:12 |
| ogra_ | well | 13:13 |
| ogra_ | that really depends on the target audience | 13:13 |
| ogra_ | i guess 98% of computer users in the world do not know what a manpage is | 13:14 |
| lundmar | sure, and for the point and click end users it is a non-issue. | 13:15 |
| lundmar | but for experienced users it is | 13:16 |
| lundmar | I figure snap caters for both | 13:16 |
| 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:19 |
| 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:20 |
| ogra_ | but thats personal opinion | 13:21 |
| lundmar | well, it is a set that needs to match so decoupling those is troublesome. | 13:21 |
| 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:23 |
| lundmar | you cant trust online to be "online", bad idea - you can always trust man :) | 13:24 |
| 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:25 |
| 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:26 |
| 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:29 |
| lundmar | I wouldn't do without manpages | 13:30 |
| lundmar | neither completion scripts ^^ | 13:30 |
| ogra_ | :) | 13:30 |
| 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:36 |
| 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:37 |
| lundmar | it surely requires some bash magic and maybe even internals changes | 13:42 |
| * jdstrand nods | 13:44 | |
| 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:45 |
| lundmar | only problem is, what if the string feed is malicious? | 13:47 |
| lundmar | tricky tricky tricky :) | 13:47 |
| jdstrand | indeed | 13:49 |
| 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:50 |
| 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:51 |
| lundmar | so, in the end it will depend on the state of bash internals ^^ | 13:52 |
| 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... | 13:58 |
| 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:00 |
| seb128 | kyrofa, thanks, the error could be more descriptive :-) | 14:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| ogra_ | lundmar, write a plugin, patches accepted ! | 14:06 |
| lundmar | CVS is an abomination to be left behind. | 14:08 |
| 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:09 |
| 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:11 |
| 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:21 |
| 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:26 |
| ogra_ | heh, old topic | 14:27 |
| zyga | o/ | 14:31 |
| zyga | hello snappers :) | 14:31 |
| ogra_ | yo | 14:31 |
| didrocks | hey zyga! | 14:33 |
| 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:41 |
| didrocks | ogra_: do you know? ^ | 14:45 |
| ogra_ | didrocks, i dont, sorry ... | 14:46 |
| ogra_ | seems you need to set a kernel cmdline var | 14:46 |
| ogra_ | hmm or not ... that seems to only work with hacked kernels that suppport capemgr | 14:47 |
| ogra_ | ours kernel is plain mainline without these patches | 14:48 |
| 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:49 |
| 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:50 |
| ogra_ | dougb, well, i fear you would need a different kernel ... or find out how to enable UARTs on a non capemgr kernel | 14:51 |
| 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:54 |
| ogra_ | (building a kernel snap is rather trivial ... ) | 14:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 14:59 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| ogra_ | the 16 series is the real thing ... and will be around for 5 years | 15:05 |
| jdstrand | didrocks: responded | 15:10 |
| didrocks | jdstrand: thanks a bunch! :) | 15:10 |
| 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:12 |
| 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:13 |
| ogra_ | lxc and lxd are also missing | 15:14 |
| 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:21 |
| aatchison | Hmm, I canna get ubuntu-core to run on the pi 2 or 3 right now... | 15:24 |
| 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:25 |
| 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:26 |
| aatchison | That's quite alright. I'm developing on the edge of chaos as well | 15:28 |
| ogra_ | :D | 15:29 |
| croepha | so, in a snapcraft.yaml, is there a way to simply say, "install these apt packages" ? | 15:29 |
| ogra_ | yeah, stage-packages | 15:30 |
| croepha | cool, thanks | 15:30 |
| 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:37 |
| ogra_ | mhall119, shhh ... dont reveal our secret contracts with seagate to trick people into buying larger disks fast ! | 15:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| didrocks | elopio: I went ahead and added one in the integration_tests/ dir | 15:47 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| kyrofa | Maybe. I'll check | 15:58 |
| kyrofa | Anyway, sgclark thanks for the report | 15:59 |
| sgclark | np, happy to help | 15:59 |
| 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:04 |
| 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:05 |
| kyrofa | Hey aatchison! | 16:08 |
| aatchison | hey! | 16:08 |
| ogra_ | hmm ... why dont we have a wine plugin yet ... | 16:15 |
| 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:16 |
| sgclark | lol | 16:17 |
| sgclark | there is that | 16:17 |
| popey | i tried packaging wine itself | 16:25 |
| popey | it almost works, might play again over the weekend | 16:26 |
| 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:31 |
| croepha | is there an online search for the snappy store? | 16:41 |
| sergiusens | seb128 thanks for those bug reports, really helpful stuff! | 16:57 |
| seb128 | sergiusens, yw! | 16:58 |
| wililupy | Question: Is there a way to build a kernel snap from a deb package? | 17:03 |
| === Aria is now known as Aria|away | ||
| === Aria|away is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| 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:47 |
| ubottu | Launchpad bug 1590679 in snapd (Ubuntu) "Apps can't own session bus names (unity7 interface)" [High,Confirmed] | 19:48 |
| 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:49 |
| sergiusens | elopio should this work `super(snapcraft.BasePlugin, self).build()` ? | 19:55 |
| 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:07 |
| 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:11 |
| 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:12 |
| elopio | super().super().build() | 20:16 |
| 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:17 |
| sergiusens | elopio so I'll just copy then | 20:29 |
| josepht | sergiusens: if you can modify the parent code you could add a method that invokes the grandparent's build() and nothing else | 20:38 |
| sergiusens | josepht as super_build() :-) | 20:46 |
| sergiusens | josepht feels dirty, but I guess that works | 20:46 |
| 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:51 |
| sgclark | most of our stuff has a newstuff feature for addons and the like | 20:52 |
| 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:01 |
| 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:02 |
| 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:33 |
| wililupy | I added a udev rule to the system, but it doesn't seem to be working. | 21:34 |
| === eriow is now known as erio | ||
| jdstrand | sgclark: you need to specify 'plugs: [ network-manager ]' and after install do: sudo snap connect <snapname>:network-manager ubuntu-core:network-manager | 22:43 |
| sgclark | jdstrand: ok thank you | 22:44 |
| jdstrand | sure thing | 22:44 |
| jdstrand | I'm stepping away now, but I read backscroll | 22:44 |
| === wililupy is now known as wililupy|away | ||
| === wililupy|away is now known as wililupy | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
