| beuno | sergiusens, soon, but orthogonal to ssl/tls | 02:25 |
|---|---|---|
| dstokes | is there any way to install packages from file, without having to upload to canonical? | 03:27 |
| miken | dstokes: yes, you can side-load... let me find the relevant docs | 04:28 |
| tedg | dstokes, Yes, you just need to set --allow-unauthenticated to avoid it checking for the store key. | 04:29 |
| dstokes | tedg: what's the command / args for installing? cant find anything in the docs | 04:29 |
| miken | snappy-remote --url=ssh://you@device install ./hello-world_1.0.5_all.snap | 04:29 |
| miken | tedg: Is that correct? ^^ That's what I used, from | 04:30 |
| miken | https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ | 04:30 |
| tedg | I haven't used remote, but on the image it's just "snappy install --allow-unauthenticated foo.snap" | 04:30 |
| tedg | Well, sudo | 04:30 |
| dstokes | oic | 04:31 |
| dholbach | good morning | 07:00 |
| miken | Morning dholbach | 07:00 |
| fgimenez | good morning | 07:03 |
| dholbach | hi miken | 07:04 |
| dholbach | mvo_, sergiusens, rsalveti: do you think anyone of you can reply to seb128's mail on snappy-devel? he's still looking for a way to boot | 07:18 |
| seb128 | dholbach, thanks! yeah, still failing to boot snappy on that uefi machine | 07:18 |
| seb128 | which blocks me for working on the new unity8 desktop snappy iso | 07:19 |
| mvo_ | seb128: I'm not sure what the status here is, we have wily images since yesterday that might help, but in any case I create a card and try to find if I have a machien with uefi bios | 07:29 |
| seb128 | mvo_, hey! where can I get the wily image? I'm happy to try that | 07:31 |
| mvo_ | seb128: sudo ubuntu-device-flash core rolling --channel edge --output wily.img | 07:31 |
| mvo_ | seb128: that should be dd-able | 07:32 |
| mvo_ | seb128: and I added a trello card | 07:32 |
| seb128 | mvo_, ok, great, I'm going to give that a try in a bit and let you know how that works | 07:32 |
| seb128 | thanks! | 07:32 |
| mvo_ | yw | 07:34 |
| zyga | good morning | 07:50 |
| === c-nv-s_ is now known as c-nv-s | ||
| beowulf | morning | 08:06 |
| === erkules_ is now known as erkules | ||
| elopio | good morning. | 08:33 |
| JamesTait | Good morning all; happy Leave the Office Earlier Day! 😃 | 09:09 |
| ogra_ | lol | 09:09 |
| tbr | good moaning | 09:13 |
| dholbach | ogra_, in the node-snapper example it looks like the tool gets stuck in some point during the installation | 09:13 |
| * tbr starts to write a brief blog post on how to make snappy work on real x86 embedded hardware | 09:13 | |
| dholbach | ogra_, http://pastebin.ubuntu.com/11516722/ | 09:13 |
| ogra_ | dholbach, it compiles | 09:14 |
| dholbach | then it's compiling for a very long time :) | 09:14 |
| ogra_ | therr should be a spinner in the bottom left though | 09:14 |
| ogra_ | tbr, wheee ! | 09:14 |
| dholbach | no spinner here | 09:14 |
| ogra_ | then kill it and start over | 09:14 |
| dholbach | http://pastebin.ubuntu.com/11516757/ - I guess something is happening | 09:15 |
| ogra_ | it uses qemu-arm-static, thats sometimes a little rough | 09:15 |
| ogra_ | whats your host release ? | 09:15 |
| dholbach | 15.04 | 09:16 |
| ogra_ | (qemu-arm-static stability sadly varies ... it is rock solid in trusty, i saw issues sometimes in utopic and havent built under vivid yet) | 09:16 |
| ogra_ | so if you dont see a spinner, kill it and start over i'd say | 09:17 |
| ogra_ | (we should note that in the doc) | 09:17 |
| tbr | ogra_: luckily it's fairly simple. install version >x of toos, build image, boot image manually (or by adding startup.nsh), use efibootmgr to set boot order properly (and check on every boot) | 09:20 |
| dholbach | ogra_, now it succeeds :-/ | 09:22 |
| ogra_ | dholbach, right ... | 09:22 |
| dholbach | Chipaca, mvo_, do you have an idea what's happening here? http://pastebin.ubuntu.com/11516932/ | 09:27 |
| dholbach | ogra_, https://code.launchpad.net/~dholbach/node-snapper/not-world-writable/+merge/260806 | 09:31 |
| dholbach | Chipaca, mvo_: http://pastebin.ubuntu.com/11516978/ | 09:32 |
| Chipaca | yep | 09:32 |
| ogra_ | dholbach, cool., thanks ... i also noticed yesterday that snappy nor kills the symlinks in $arch/bin/ ... need to find a fix for that one (start-service.sh points to $arch/bin/node which is a symlink to $arch/bin/nodejs) | 09:32 |
| ogra_ | s/nor/now/ | 09:32 |
| Chipaca | dholbach: remember how we don't support things that are apps becoming frameworks, or viceversa? | 09:33 |
| Chipaca | dholbach: bottom line, remove the old webdm and install the new one, until we fix that | 09:33 |
| dholbach | ok | 09:34 |
| ogra_ | for me "snappy update webdm" (on the 15.04 release kvm image) just works | 09:34 |
| dholbach | I can't quite remember which image it was I used back then | 09:35 |
| dholbach | "Tags are free form, but some can gain special use, such as an external/ui one which would be picked up by the webdm and used to open the application through the web." | 09:40 |
| dholbach | ^ is the above true right now? | 09:40 |
| beowulf | dholbach: what's the source? | 09:44 |
| beowulf | dholbach: as of this minute, webdm doesn't provide links to external ui, but i don't know what tags are | 09:45 |
| beowulf | s/but/and | 09:46 |
| dholbach | beowulf, that's in https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ | 09:48 |
| dholbach | (just search for webdm) | 09:48 |
| beowulf | dholbach: ah right, so the 'ui' tag isn't working right now | 09:49 |
| dholbach | ok | 09:49 |
| beowulf | dholbach: it will be by end of today, and then it'll be available on the next version of webdm | 09:49 |
| dholbach | <3 | 09:49 |
| elopio | fgimenez: ping, I can start the exploratory now. Are you ready? | 09:49 |
| beowulf | dholbach: that's much easier to read now :) | 09:50 |
| beowulf | dholbach: do you know why the icon section says "only SVG"? | 09:50 |
| dholbach | no, I don't | 09:51 |
| dholbach | davidcalle, ^ do you know why the icon section on https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ says "only SVG"? | 09:51 |
| beowulf | the store converts SVG to PNG, and I don't think we should allow SVG | 09:51 |
| fgimenez | elopio, yup, ready! | 09:52 |
| elopio | fgimenez: do you use firefox? want to try meeting using hello? | 09:53 |
| dholbach | ogra_, can you pull from lp:~dholbach/+junk/chatroom? | 09:53 |
| dholbach | (can't create an MP for a +junk branch) | 09:53 |
| davidcalle | dholbach, probably because the branch doc (eg. https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md) specify the svg format for icons (line25) | 09:53 |
| fgimenez | elopio, not tried yet, let me set it up | 09:54 |
| dholbach | davidcalle, ah ok... sorry - it says that in the 15.04 branch as well, just not as "only svg" which I couldn't find in there | 09:55 |
| dholbach | beowulf, looks like it's currently spec'ed that way, cf https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md and https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md | 09:55 |
| elopio | getting some water here and finding a good place. Give me a couple of minutes. | 09:56 |
| davidcalle | dholbach, beowulf, the doc itself is not from snappy trunk, it's one of the first doc uploaded with the initial snappy announcement, afair it has been reviewed to be kind-of up-to-date with the latest release | 09:56 |
| davidcalle | I don't know if snappy actually cares about the format, though :) | 09:58 |
| davidcalle | beowulf, do you know what the plan is for high-res screens and the store? Do we need (or will we need) several png sizes? | 09:59 |
| elopio | fgimenez: https://hello.firefox.com/zAxKYb3AqB8 | 10:03 |
| fgimenez | elopio, ok give me a second.. | 10:04 |
| beowulf | davidcalle: i don't know what the plan is, but the current icon size is 256x256, that's quite large already | 10:07 |
| elopio | fgimenez: http://pad.ubuntu.com/testing-snappy | 10:10 |
| ogra_ | dholbach, oh, didnt i push that yet ? (i have the same on disk and in the store) .... | 10:12 |
| davidcalle | beowulf, thanks, can confirm, just tried at 3200x1800, various scalings, looking sharp :) | 10:12 |
| elopio | fgimenez and I will be doing exploratory testing on snappy here, in case somebody wants to join: https://hello.firefox.com/zAxKYb3AqB8 | 10:12 |
| dholbach | ogra_, apparently not :) | 10:19 |
| Chipaca | mvo_: you around? | 10:22 |
| mvo_ | Chipaca: yes | 10:22 |
| Chipaca | mvo_: hiya! | 10:22 |
| mvo_ | Chipaca: good morning! | 10:22 |
| Chipaca | mvo_: what happens if a service has no description? | 10:22 |
| Chipaca | currently we're using the second line of the readme for that | 10:22 |
| mvo_ | Chipaca: a good question - using that is probably not a great idea :/ | 10:23 |
| Chipaca | but we're only storing it in the click manifest (and in the systemd service file) | 10:23 |
| Chipaca | until i got to that, i had high hopes of making things work without reverting the "limit click manifest use" branch | 10:23 |
| mvo_ | Chipaca: maybe we should just generate something like "service for {pkgname} - {servicename}" or something | 10:23 |
| Chipaca | mvo_: "service {servicename} of {qualified name}"? | 10:24 |
| mvo_ | Chipaca: yeah, much better | 10:25 |
| ogra_ | dholbach, pushed this and other changes | 10:25 |
| Chipaca | k | 10:25 |
| dholbach | ogra_, and the node-snapper MP? | 10:27 |
| ogra_ | dholbach, no, chatroom | 10:27 |
| Chipaca | mvo_: not qualified name; we don't know the origin in build :) | 10:28 |
| mvo_ | Chipaca: my brain is still on this gccgo senfile failure, but I think I nailed it now, I feel a bit silly for not spotting the real problem earlier | 10:28 |
| Chipaca | mvo_: that's good, right? | 10:28 |
| mvo_ | Chipaca: indeed you are right | 10:28 |
| mvo_ | Chipaca: its good that its fixed, not good that I feel silly, but I guess I should relax and celebrate the fix instead :) | 10:29 |
| ogra_ | dholbach, doing node-snapper now ... i'm just totally distracted by http://people.canonical.com/~alan/ogra_loading.gif | 10:29 |
| Chipaca | mvo_: feeling silly is good | 10:29 |
| Chipaca | mvo_: because it only happens *after* the "aha" | 10:29 |
| mvo_ | lol | 10:29 |
| mvo_ | very true | 10:29 |
| dholbach | ogra_, yes, I can imagine | 10:29 |
| elopio | fgimenez: still 10 minutes to download, it doesn't go down :( | 10:29 |
| dholbach | ogra_, take your time :) | 10:29 |
| elopio | and makes the video choppy. I'll go and get more water and the charger... | 10:29 |
| fgimenez | elopio, np, the video is frozen for me.. ping me when ready | 10:31 |
| ogra_ | dholbach, merged and pushed | 10:31 |
| dholbach | ogra_, cool, I'll do another test run now | 10:32 |
| ogra_ | wait one sec, i have another change | 10:32 |
| * dholbach waits | 10:32 | |
| ogra_ | dholbach, done | 10:33 |
| elopio | fgimenez: 2 mins. | 10:33 |
| ogra_ | mvo_, http://bazaar.launchpad.net/~ogra/node-snapper/trunk/revision/7 ... why do my symlinks vanish when packaging the snap ? is that intentional ? | 10:34 |
| elopio | fgimenez: I can see you, but you can't hear me. | 10:34 |
| elopio | the download is ready. | 10:34 |
| elopio | I'll rejoin... | 10:35 |
| fgimenez | elopio, nope, and you are frozen | 10:35 |
| mvo_ | ogra_: I suspect need a update version of snappy, symlinks got fixed by Chipaca some days ago | 10:35 |
| * ogra_ guesses that kind of goes against de-duplication :) | 10:35 | |
| ogra_ | ah, cool | 10:35 |
| mvo_ | it was a silly bug | 10:35 |
| * mvo_ notices that its silly to use silly all the time | 10:35 | |
| * ogra_ will revert that change once that migrated everywhere then ... | 10:35 | |
| elopio | fgimenez: can you kick me or something? | 10:35 |
| elopio | It says I can't rejoin. | 10:36 |
| Chipaca | mvo_: giving up, reverting the manifest thing | 10:36 |
| fgimenez | elopio, i'm alone in the conversation | 10:36 |
| mvo_ | Chipaca: meh, let me know if I can help in any way :( | 10:36 |
| Chipaca | unless... | 10:37 |
| elopio | fgimenez: crazy shit. Now I'm alone in the conversation :) | 10:39 |
| elopio | fgimenez: lets go to hangouts, this doesn't seem ready: https://plus.google.com/hangouts/_/grwijm4jm7pbk5vu6fg5dgiknaa?hl=es | 10:39 |
| mvo_ | Chipaca: btw, if we ever decide to backport the cp_linux thing to 15.04 you will need to remind me that we need to port the upstream gccgo fix as well | 10:40 |
| Chipaca | mvo_: or, or, we could make the default non-cp_linux implementation be the fallback | 10:40 |
| Chipaca | mvo_: but then we'd never find these bugs :) | 10:40 |
| Chipaca | unless we printed a big fat warning before calling the fallback | 10:41 |
| mvo_ | : | 10:43 |
| mvo_ | :) | 10:43 |
| dholbach | ogra_, looks like chatroom doesn't start up after installation - do you know how I can debug this? | 10:50 |
| ogra_ | dholbach, syslog ... and you can hack the start script "export NODE_DEBUG=*" | 10:51 |
| elopio | rsalveti: why is the image in http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ older than the one you get with ubuntu-device-flash? | 10:51 |
| ogra_ | dholbach, did you use the start script unmodified ? | 10:52 |
| ogra_ | dholbach, it might point to node ... if you didnt re-run node-snapper with the last change thats a dead symlink | 10:52 |
| ogra_ | point the script to nodejs instead | 10:52 |
| dholbach | ogra_, let me check | 10:56 |
| dholbach | ogra_, still no dice | 11:00 |
| dholbach | ogra_, how can I emulate the startup of the service? | 11:00 |
| ogra_ | dholbach, show me your start-service.sh | 11:02 |
| dholbach | ./chatroom.sideload/current/start-service.sh: 27: ./chatroom.sideload/current/start-service.sh: /amd64/bin/nodejs: not found | 11:03 |
| ogra_ | uh | 11:03 |
| dholbach | ogra_, could it be that "./amd64.." would help there? | 11:03 |
| ogra_ | it uses $SNAPP_APP_PATH/$ARCH/bin/node $MY_EXECUTABLE | 11:04 |
| ogra_ | try dropping a P there | 11:04 |
| === sabdfl_ is now known as sabdfl | ||
| ogra_ | seems something changed in the ubuntu-core-launcher that doesnt set the variable anymore | 11:04 |
| ogra_ | (i thought we'd keep that for backwards compatibility ... hmm) | 11:05 |
| dholbach | ./amd64/bin/nodejs: error while loading shared libraries: libcares.so.2: cannot open shared object file: No such file or directory | 11:06 |
| ogra_ | geez | 11:06 |
| ogra_ | what did you do | 11:06 |
| ogra_ | you see that in syslog when starting it via systemctl ? | 11:06 |
| * ogra_ pushes a change for SNAPP vs SNAP to the branch | 11:08 | |
| sergiusens | beowulf: dholbach yes, tags are true, if a package uses that, webdm will hint it in the package payload | 11:11 |
| dholbach | ogra_, does it work for you? | 11:12 |
| dholbach | no... I ran this: | 11:12 |
| dholbach | (amd64)ubuntu@localhost:/apps/chatroom.sideload/current$ ./amd64/bin/nodejs current/site/server.js | 11:12 |
| Chipaca | mvo_: do we still support setting apparmor in Integration? | 11:12 |
| dholbach | not sure if that was the wrong way to do it | 11:12 |
| ogra_ | dholbach, i uploaded it to the store yesterday, yes | 11:12 |
| ogra_ | dholbach, the path to the server.js is wrong ... drop the "current/" there | 11:12 |
| mvo_ | Chipaca: I think we do, we could kill it | 11:13 |
| ogra_ | dholbach, but you cant just run it withouth the ubuntu-core-launcher environment ... use systemctl and syslog | 11:13 |
| mvo_ | i think | 11:13 |
| Chipaca | mvo_: meh. i've made a note. | 11:13 |
| dholbach | ogra_, ok, I'll have another look | 11:13 |
| ogra_ | dholbach, also, show me your start-service.sh | 11:14 |
| dholbach | ogra_, I'll start from scratch - I was just following your instructions | 11:14 |
| ogra_ | me too yesterday :) | 11:14 |
| dholbach | ogra_, it works! :) | 11:19 |
| dholbach | shipit! | 11:20 |
| ogra_ | haha | 11:20 |
| ogra_ | note it wonly works properly with chromium | 11:20 |
| * ogra_ just added that info to readme.md | 11:21 | |
| Chipaca | mvo_: still needs tests, but http://bazaar.launchpad.net/~chipaca/snappy/mangle/revision/482?start_revid=482 fixes it; could you take a look and see if the approach seems sane to you? | 11:22 |
| Chipaca | mvo_: at question is whether i hate clickManifest too much :) | 11:23 |
| mvo_ | Chipaca: looking | 11:28 |
| mvo_ | Chipaca: oh, you can kill the createion of .snappy-systemd in handleServices entirely | 11:30 |
| === tvoss is now known as tvoss|lunch | ||
| mvo_ | Chipaca: looks like a good approach, I assume you fix the names ;) ? we should probably do deprecation warnings if we encounter stuff we need to mangle | 11:32 |
| Chipaca | mvo_: i can? kill snappy-systemd i mean | 11:37 |
| mvo_ | Chipaca: yes, that is only used by the snappy-systemd hook which is no longer in use at all | 11:37 |
| Chipaca | mvo_: so binaries and services look identical :) | 11:39 |
| mvo_ | heh :) thats good, right? | 11:39 |
| Chipaca | yep | 11:39 |
| zyga | hey, is there an api for snappy | 11:55 |
| zyga | so that I can get stuff like 'snappy list' programmatically without screen-scraping | 11:55 |
| dholbach | ogra_, I guess there's no way around editing start-service.sh as root, right? | 11:59 |
| ogra_ | dholbach, only by editing it before rolling the snap :) | 11:59 |
| dholbach | ogra_, the file is owned by root | 11:59 |
| dholbach | before the rolling of the snap, because node-snapper runs as root | 12:00 |
| ogra_ | ah,. we can change that indeed | 12:00 |
| zyga | anyone? | 12:01 |
| zyga | (I'm just after a yes / no answer) | 12:02 |
| beuno | zyga, yes* | 12:02 |
| beuno | * sergiusens can tell you more | 12:02 |
| zyga | beuno: thanks! | 12:02 |
| zyga | sergiusens: any links on where I can find snappy API? | 12:03 |
| zyga | sergiusens: (for apps that want to talk to snappy and get data from it) | 12:03 |
| nessita | beuno, o/ so I mentioned to Sergio the goal to have every request to the store being oauth signed, and he replied that we should first decide on the ssl/tls front | 12:04 |
| nessita | Chipaca, o/ yes, for snappy | 12:04 |
| beuno | nessita, I think he's mixing topics | 12:04 |
| ogra_ | zyga, there is work for some REST api ... not sure thats snappy itself or a webdm thing | 12:06 |
| zyga | ogra_: isn't webdm optional? | 12:06 |
| zyga | ogra_: I'm looking for alternative to parsing snappy list output | 12:06 |
| ogra_ | zyga, it is optional .. for a remote API you need a webserver though ... which webdm conveniently ships | 12:07 |
| zyga | ogra_: is app-to-app IPC constrained? | 12:07 |
| beuno | zyga, the plan is for snappy to provide a rest api, which everything that wants to display data will use | 12:07 |
| zyga | ogra_: can I write an app that talks to webdm and it will not be broken down the line? | 12:07 |
| zyga | ok | 12:07 |
| ogra_ | zyga, ask sergio, he designs that :) | 12:07 |
| beuno | webdm, the cli. etc | 12:07 |
| zyga | ogra_: will do, thanks! | 12:08 |
| zyga | sergiusens: I'll be the inner voice in your head | 12:08 |
| zyga | sergiusens: asking you questions ;) | 12:08 |
| zyga | ogra_: why is python2.7 on the snappy image btw? is it so that 2.7 webapps can be deployed easily or is there another reason? | 12:08 |
| ogra_ | zyga, by accident ... cloud-init isnt fully ported yet | 12:09 |
| zyga | ogra_: ah, I see | 12:09 |
| ogra_ | (final target is to get rid of languages ) | 12:09 |
| zyga | ogra_: and down the line, do you see it becoming a framework of sorts, so that people can do 2.7 webapps? | 12:09 |
| ogra_ | (in the core) | 12:09 |
| zyga | ogra_: or will it be killed | 12:09 |
| zyga | ogra_: I see | 12:09 |
| zyga | ogra_: so all runtimes (perl, pythons) go away and maybe move to frameworks | 12:10 |
| ogra_ | i assume it can be a framework ... or you can just bundle it | 12:10 |
| zyga | ogra_: are frameworks well defined? is it okay for a framework to ship a language runtime? | 12:11 |
| ogra_ | i'm not so sure :) | 12:12 |
| * ogra_ still hasnt looked at the exact framework definition | 12:12 | |
| zyga | ogra_: is that discussion happening somewhere? | 12:12 |
| dholbach | ogra_, how do you want to change the permissions? | 12:12 |
| zyga | ogra_: who makes the calls? | 12:12 |
| ogra_ | in hangouts :P | 12:12 |
| zyga | ogra_: ok, I'll start showing up in yours | 12:12 |
| dholbach | ogra_, or shall I just go and write the docs so people use 'sudo' to edit the file? | 12:13 |
| ogra_ | dholbach, oh, i see why that happens, because you chaned world writability :) | 12:13 |
| ogra_ | we could chown the dir to $USER i guess ... shouldnt do harm to the final snap | 12:13 |
| ogra_ | (for the tarball contents and the start script) | 12:14 |
| ogra_ | (snappy chowns everything to the clickpkg user at install time) | 12:14 |
| dholbach | ogra_, ah yes, that's right :) | 12:16 |
| dholbach | ogra_, so maybe just change it to $USER once node-snapper is done? | 12:17 |
| ogra_ | yeah, for the arch tarballs before they get tarred up and for the three final files | 12:18 |
| ogra_ | so that the user has all permissionns in case he wants to edit something inside these tarballs manually | 12:18 |
| dholbach | ogra_, https://developer.ubuntu.com/en/snappy/tutorials/node-to-snap/ - looking good? :) | 12:51 |
| ogra_ | dholbach, in a meeting, gimme a bit | 12:53 |
| dholbach | ogra_, sure | 12:54 |
| dholbach | ogra_, I'll hold off of blogging about it for a bit | 12:54 |
| sturmflut2 | https://i.imgur.com/rntFSWS.jpg Awww | 12:55 |
| beowulf | dholbach: the last paragraph hasn't formatted with a <p> | 12:55 |
| ogra_ | sturmflut2, thats what you get with the intel snap ? | 12:55 |
| ogra_ | cute :) | 12:55 |
| sturmflut2 | ogra_: Yes, a webserver on port 8888 hosting a lot of JavaScript, and I think there's more | 12:56 |
| sturmflut2 | I have to say it was surprisingly painless to boot the Snappy KVM image and install the package | 12:57 |
| dholbach | thanks beowulf - I'm not sure if I fixed the right way now(?) | 12:57 |
| ogra_ | dholbach, i dont really like the hack in point 6 (where i mv the contents of chatroom/*) ... i wonder if we could make that more elegant | 12:57 |
| beowulf | dholbach: yep, fixed now :) | 12:58 |
| ogra_ | (that was just a quick hack when elopio found an issue with the original howto, i never cleaned that up) | 12:58 |
| ogra_ | dholbach, but thats only cosmetic, looks great otherwise ! | 12:58 |
| dholbach | thanks beowulf | 12:59 |
| dholbach | ogra_, let me think about it | 12:59 |
| ogra_ | it would need some serious re-ordering so we branch into package/ | 13:00 |
| ogra_ | not sure thats worth it | 13:00 |
| davidcalle | dholbach, do you mind if I make a small layout tweak to your tuto? | 13:02 |
| dholbach | davidcalle, I'd be happy if you'd do that :-D | 13:02 |
| davidcalle | dholbach, specifically code -> twelve-col | 13:02 |
| dholbach | <3 | 13:03 |
| * dholbach writes a quick blog entry | 13:03 | |
| jdstrand | Chipaca, mvo_: fyi, I made it so the review tools error when finding integration in the yaml. that will be in the 0.28 version I am preparing | 13:04 |
| Chipaca | niiice :) | 13:04 |
| jdstrand | so +1 on removing it from snappy | 13:04 |
| zyga | sergiusens: what is snapcraft?> | 13:08 |
| ogra_ | zyga, a magic wand | 13:09 |
| ogra_ | zyga, you want to interview tedg or mterry about it ;) | 13:10 |
| zyga | ogra_: I tried googling for it but the name kind of hits minecraft instead | 13:10 |
| tedg | It's a dream :-) | 13:10 |
| zyga | what is is, in one line? | 13:10 |
| ogra_ | zyga, a magic wand | 13:10 |
| tedg | zyga, It's the tool we're working on to make building snaps really easy. | 13:10 |
| ogra_ | (in one line ... no wraps) | 13:10 |
| tedg | zyga, Handle things like pulling in a runtime and packaging it along with your app. | 13:11 |
| zyga | ah, so ubuntu component store for snappy, kind of? | 13:11 |
| tedg | Eh, kinda. More like allowing you to use the component stores you're already happy with. Be it PIP or apt or npm. | 13:11 |
| zyga | sergiusens: quick question for the "by design", I get that security is there by design, I don't disupte that, I'm looking for what the recommendation is for us, should we just ignore confinement and run entirely unconfined or should we seek some options to work within the confinement? | 13:12 |
| zyga | tedg: is it reasonable to use snapcraft to pull in pulseaudio | 13:12 |
| zyga | tedg: and make it really work | 13:12 |
| zyga | tedg: (with hardware access and all the permissions) | 13:12 |
| zyga | tedg: so that my app can have some sound? | 13:12 |
| ogra_ | sure | 13:12 |
| tedg | zyga, No, pulse should really be a framework. It's something that shares hardware. | 13:12 |
| ogra_ | no need for snapcraft to do that | 13:13 |
| zyga | ok | 13:13 |
| ogra_ | https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ | 13:13 |
| Chipaca | zyga: for a hardware testing tool, i'd expect it to be unconstrained or have a custom apparmor profile | 13:13 |
| ogra_ | that has some hints about HW access | 13:13 |
| tedg | zyga, Frameworks are more about services that multiplex HW. | 13:13 |
| zyga | Chipaca, tedg: that both makes sense, thanks | 13:13 |
| ogra_ | orm for system tests you might actually want unconfined, yeah | 13:13 |
| zyga | I have a feeling we should help drive this so that eg. pulse exists as a framework and we and use it for testing, that python exists as a framework and we can use it (or that snapcraft can bundle it) | 13:14 |
| ogra_ | the latter will be what will happen | 13:14 |
| zyga | one other idea I had is to have a flag day and rewrite _everything_ on top of some qt api | 13:14 |
| ogra_ | (snapcraft bundling stuff for you) | 13:15 |
| zyga | but I don't know if that's a good solution even if we did it (does qt really have an API for everything?) | 13:15 |
| Chipaca | zyga: just to be sure you understand it, frameworks are for hardware access, not for sharing libraries | 13:15 |
| Chipaca | zyga: having a library in a framework will not enable things that depend on that framework to use that library | 13:15 |
| zyga | Chipaca: yes, I get that, it's just not clear to me exactly if there will be exactly zero non-hardware frameworks as this seems to be up in the air a little | 13:16 |
| zyga | Chipaca: ok | 13:16 |
| davidcalle | dholbach, hah, nevermind, this break numbered lists... ¯\_(ツ)_/¯ | 13:16 |
| zyga | Chipaca: is snapcraft something that I can try now? | 13:16 |
| mterry | zyga, no | 13:17 |
| Chipaca | zyga: snapcraft is in the design phase right now. Or vapourware if you will. | 13:17 |
| zyga | I see | 13:17 |
| zyga | so while python exists on the image it's not so critical | 13:17 |
| zyga | it's more important to understand what's down the line and how the roadmap looks like | 13:18 |
| ogra_ | zyga, but if you use some mechanism to bundle your stuff, let the two guys know so they can take that into account in snapcraft :) | 13:18 |
| zyga | and to know how we plan to fit in | 13:18 |
| zyga | mterry, tedg: one mechanism we do use now, is to just have a package in a PPA or in the archive (and use known tooling for building it) and to extract bits and pieces from it (.so files) so that we don't have to worry about cross-compilation or daily builds | 13:19 |
| zyga | as there are no "ppas" for clicks or snaps and many people are working on the project we do rely on some kind of automatic build process | 13:20 |
| zyga | and limiting that to "run this script and it fetches and repackages stuff from the archive" does simplify it for us | 13:20 |
| * dholbach hugs davi | 13:20 | |
| * dholbach hugs davidcalle | 13:20 | |
| zyga | obviously we could rewrite that to build our stuff but then it's a bit more complicated (cross compiling) and time consuming | 13:20 |
| tedg | zyga, So basically our goal is to make the cross compiling and pulling in dependencies easy. So then you can do that all the time. | 13:22 |
| zyga | tedg: how do you plan on achieving that? | 13:23 |
| * ogra_ hugs dholbach | 13:25 | |
| tedg | zyga, magic wand :-) | 13:25 |
| zyga | tedg: and in reality? :-) | 13:25 |
| zyga | tedg: one thing I'm interested in is this use case | 13:25 |
| zyga | tedg: you pip install somethig | 13:25 |
| zyga | tedg: that builds a .so file | 13:25 |
| zyga | tedg: how do you make that cross-compilable? | 13:25 |
| tedg | zyga, We plan on doing it by you providing us with a yaml file describing what you want and providing plugins that understand those cases and install them into a snap. | 13:26 |
| tedg | zyga, We build two of them in and put them in directories appropriate for the architecture they're built for. | 13:26 |
| zyga | tedg: hmm? | 13:26 |
| zyga | tedg: I mean, pip, do you plan to patch pip and python to make that work? | 13:27 |
| * dholbach hugs ogra_ back | 13:27 | |
| zyga | tedg: I know theory that it can work, I want to understand if you have any concrete plans for specific cases | 13:27 |
| zyga | tedg: all python extension build natively so far | 13:27 |
| zyga | tedg: and it does seem like patch-the-world problem to me | 13:27 |
| tedg | zyga, We have concrete plans to make that work, we started writing code for it yesterday. | 13:27 |
| zyga | tedg: without a solution like qemu-arm-static or simiar | 13:28 |
| zyga | similar* | 13:28 |
| mterry | zyga, we plan to cross compile in chroots like the sdk does yeah | 13:28 |
| tedg | zyga, I'm hoping we don't have to patch pip, but if so, we'll work with upstream to make it handle cross-compiling better. | 13:28 |
| tedg | Honestly, I think that multi-architecture support is something everyone wants (upstreams too) but no one has the time to work on it. It's a priority for us. | 13:29 |
| zyga | mterry, tedg: I'd love to dogfood anything you can share, my use cases are stuff like python3-lxml2 | 13:29 |
| zyga | tedg: I agree | 13:29 |
| === rickspencer3_ is now known as rickspencer3 | ||
| zyga | tedg: it's ironic that only debian did it in any sensible capacity | 13:29 |
| tedg | zyga, Cool, we'll probably harass you in a couple weeks after we start to get things off the ground. We're working with simpler use cases right now to get the basics together. | 13:30 |
| zyga | tedg: gnu hello? :) | 13:30 |
| tedg | BSD Hello, we're not handling complex licensing yet ;-) | 13:32 |
| zyga | haha | 13:33 |
| zyga | tedg: note that an eula is hardly needed for gnu hello | 13:33 |
| zyga | tedg: no license needed | 13:33 |
| dholbach | ogra_, our names are put next to python tutorial thing - is that on your list of things to do right now? | 13:40 |
| ogra_ | python tutorial ? nope | 13:41 |
| ogra_ | i thought barry did one | 13:41 |
| barry | ogra_: hello? :) | 13:41 |
| ogra_ | i'll have tzo take care for the RPi image for the rest of the week | 13:41 |
| dholbach | ogra_, barry: I was looking at barry's blog post, but it looks like asac preferred ricmm's approach (https://code.launchpad.net/~ricmm/+junk/example-python-snap/) and we wouldn't have to require python 3.5 | 13:44 |
| barry | dholbach: python 3.5 isn't required for my approach, it just enables some fancy debugging and hackery | 13:45 |
| barry | has ricmm published any articles or docs on his approach? | 13:47 |
| barry | (his is py27 based; i'm firmly py3 :) | 13:47 |
| barry | also, mine is more of a framework for providing py3 snaps, rather than just an example of one | 13:47 |
| dholbach | ok... I wasn't siding with any solution, just trying to figure out where to go next | 13:51 |
| barry | dholbach: sure. let many flowers bloom :) happy to help | 13:51 |
| asac | dholbach: yes ricmms approach is trivial... works everwhere, doesnt solve everything though, but for getting started its absolutely fine imo | 13:57 |
| asac | it solves the problem: how to assemble a complete python dependency tree easily. it doesnt solve the native libs etc. parts | 13:57 |
| asac | or the how to include the intepreter | 13:57 |
| asac | but since we have python in OS image having that approach as the _simple_ way of getting started sounds good | 13:58 |
| ogra_ | asac, not at all ... if the interpreter is gone from the system all packages that foillowed such a howto will break | 14:01 |
| ogra_ | asac, the point dholbach tries to solve if giving developers something in their hands right now | 14:02 |
| ogra_ | so we either take barry's approach or actually finish ricmm's to pull in the interpreter etc | 14:02 |
| beowulf | @reviewlist | 14:10 |
| nothal | https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old) | 14:10 |
| nothal | https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old) | 14:10 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old) | 14:10 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old) | 14:10 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old) | 14:10 |
| dholbach | barry, ^ not sure if you saw the discussion above... | 14:19 |
| barry | dholbach: nope, thanks | 14:26 |
| ogra_ | beowulf, does the description in webdm come from thr redme.md now (it used to come from the store UI description before) | 14:26 |
| ogra_ | *the | 14:26 |
| barry | ogra_: that's why i emphasized py3 because it probably will be a while before it disappears, although if mvo_ does port the entire system-image infrastructure to the store + a new client, that will change of course | 14:27 |
| barry | plus...py2 blech | 14:28 |
| ogra_ | yeah, i wouldnt suggest to anyone to rely on interpreters in the core image | 14:28 |
| ogra_ | we should have a tool that bundles it properly for your snap | 14:28 |
| barry | ogra_: certainly that's the right long term solution. plus it lets app developers ship whatever crazy configuration that's different than ubuntu's crazy configuration of their interpreter they want | 14:29 |
| barry | ogra_: there have been *lots* of upstream discussion around this approach | 14:29 |
| ogra_ | i think it should also be the short term solution ... | 14:29 |
| barry | as it's not just applicable to snappy of course | 14:29 |
| barry | maybe | 14:29 |
| ogra_ | if we once start allowin such a habit (relying on core bits) it will be really hard to get that gone again | 14:30 |
| barry | ogra_: it's just that i'd like to see upstream work continue. i'd like us to drive that so our needs are addressed, but in a fashion that's generally useful, rather than we bake our on solution that's different than everyone elses | 14:31 |
| ogra_ | well, i dont see a problem with that ... for the time being we should have a tool that fulfills the purpose, then gets merged into snapcraft as a plugin and once upstream work is done we can replace the plugin | 14:32 |
| ogra_ | i just dont want to encourage using core components, thats all | 14:33 |
| beowulf | ogra_: still store, afaik | 14:35 |
| ogra_ | hmm | 14:35 |
| beowulf | ogra_: maybe sergiusens looks in the readme if there's nothing in the store? | 14:36 |
| ogra_ | well, there is a lot in the store for chatroom | 14:36 |
| ogra_ | (like a full paragraph) | 14:36 |
| beowulf | ogra_: yes, so i see | 14:36 |
| ogra_ | and i dont find the line that webdm displays in the sotre at all | 14:36 |
| ogra_ | *store | 14:36 |
| beowulf | ogra_: yup, let me check what's happening there | 14:37 |
| jdstrand | beuno: fyi, r473 of the review tools is the *one* (aka, I'm cutting 0.28 now) :) feel free to pull that whenever | 14:38 |
| beowulf | sergiusens: hey, is 'description' in snappy/webdm package api coming from? (and if readme.ms, is it possible it's being truncated on the first newline)? | 14:42 |
| beowulf | sergiusens: *where | 14:42 |
| sergiusens | beowulf: ogra_ this is from early snappy days, beuno and mvo_ are the intellectual authors for readme.md; I think the store reads the first line and it's supposed to be char limited | 14:56 |
| sergiusens | in any case, I think it's bad that the store let's you override anything from package.yaml | 14:56 |
| ogra_ | sergiusens, hmm, thats pretty bad now that we dont have a "click" way to get to the used ports | 14:56 |
| sergiusens | it should either be free form or part of the package | 14:56 |
| dholbach | asac, barry, ogra_: where do we go from here regarding the python tutorial? Jamie also added his suggestion to https://trello.com/c/vbQTdIYQ/5-development-snappy-tutorial-for-python-2-3 | 14:57 |
| sergiusens | ogra_: there is a click way, beowulf just needs to hook to the ui, ogra_ did you add the 'ui' port? | 14:57 |
| ogra_ | i.e. hos is the user supposed to know chatroom runs on port 6565 and only works under chrome/chromium | 14:57 |
| ogra_ | *how | 14:57 |
| ogra_ | sergiusens, yep, i did | 14:57 |
| beowulf | sergiusens: ogra_: https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | 14:57 |
| ogra_ | external ui ... | 14:57 |
| ogra_ | ah, ood | 14:58 |
| sergiusens | ogra_: great, then http://webdm.local:4200/api/v2/packages/chatroom.ogra will have ui_port (I see it here) | 14:58 |
| ogra_ | *good even | 14:58 |
| sergiusens | ogra_: just need to hook up in the js side which I guess is what beowulf's MP is all about | 14:58 |
| beowulf | ogra_: the only bit missing is the description to tell the user it's chromium only | 14:59 |
| beowulf | ogra_: which you have in the store | 14:59 |
| ogra_ | beowulf, right | 14:59 |
| sergiusens | beowulf: ogra_ I guess we can add a http://webdm.local:4200/api/v2/packages/chatroom.ogra/documentation that exposes the readme.md | 14:59 |
| ogra_ | +1 | 15:00 |
| beowulf | sergiusens: why not the store description? | 15:00 |
| beowulf | oh, i know | 15:00 |
| barry | dholbach: not sure, but i subscribed to that card so i can follow the discussions. | 15:00 |
| ogra_ | dholbach, i guess thats something for tomorrows community sync meeting | 15:01 |
| sergiusens | beowulf: 2 reasons; when you upload an app, readme.md pre fills the store description (it shouldn't allow you to change it IMO); second one is to use the installed resource instead of going over the web | 15:02 |
| beowulf | sergiusens: yeah, no 2 came back to my mind as i hit return | 15:02 |
| beowulf | sergiusens: on 1, the store needs to be able to set a description per store | 15:02 |
| barry | ogra_, dholbach should i attend that meeting? | 15:04 |
| ogra_ | if you feel like ... 14:00 UTC (if my math isnt wrong) | 15:04 |
| barry | ogra_: that's doable. where is it? | 15:05 |
| dholbach | sent you an invitation | 15:07 |
| dholbach | barry, ^ | 15:09 |
| barry | dholbach: awesome, thanks | 15:10 |
| zyga | it seems that name/executable are not working quite well and assumptions are made that name is identical to executable | 15:24 |
| beowulf | what are 'caps'? https://developer.ubuntu.com/en/snappy/guides/security-policy/ are they described somewhere? | 15:26 |
| asac | dholbach: is there a proposed text already? | 15:28 |
| asac | for the tutorial i mean | 15:28 |
| dholbach | asac, I was starting to work from http://www.wefearchange.org/2015/04/creating-python-snaps.html | 15:32 |
| dholbach | asac, for ricmm's example we basically just have the code | 15:33 |
| asac | dholbach: that thing is far too complex imo | 15:33 |
| asac | super hard and not working for everything but 3.5... its clearly the future, but not the short term solution | 15:33 |
| asac | we should put out as the easy way to get started | 15:33 |
| ogra_ | asac, right, but we should definitely not suggest to people to rely on the py interpreter in core | 15:34 |
| dholbach | asac, barry just clarified: the 3.5 bits are for additional debugging | 15:34 |
| jdstrand | beowulf: they are not documented yet (this is a todo). we want something like this: https://developer.ubuntu.com/en/publish/security-policy-groups/ for snappy | 15:35 |
| jdstrand | beowulf: well, they are sorta documented | 15:35 |
| jdstrand | let me get that | 15:35 |
| zyga | ogra_: why is /tmp restricted when we can just make /tmp private to the application? | 15:35 |
| ogra_ | zyga, it sitn restricted ... you have /tmp/snaps/<appname> for your own convenience afaik | 15:36 |
| jdstrand | dholbach: curious-- is there a trello card for the docs team to do the tutorial I mentioned on the list and something for ^ | 15:36 |
| ogra_ | *isnt | 15:36 |
| zyga | ogra_: it seems pretty broken to make /tmp read only (and teach everything not to use it) if we can just put it in a private namespace | 15:36 |
| zyga | ogra_: well, it sure seems to be: | 15:36 |
| zyga | ogra_: FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/apps/stubbox.sideload/0.21.2'] | 15:36 |
| zyga | ogra_: now I can patch that but I feel I should not have to | 15:36 |
| ogra_ | zyga, only the toplevel is restricted, but TMPDIR always points to the app dir anyway | 15:36 |
| zyga | ogra_: yes, and that's what I'm talking about | 15:36 |
| seb128 | mvo_, the command you gave me earlier, it complains that there is no channel named "edge"? | 15:36 |
| ogra_ | the launcher should create it | 15:36 |
| zyga | ogra_: well, my question stands | 15:37 |
| ogra_ | iirc there was a bug in older images with that, but i think that has been fioxed quite recently | 15:37 |
| zyga | ogra_: since we are using containers making a app-private /tmp seems obvious | 15:37 |
| ogra_ | zyga, for more details ask the security team :) | 15:37 |
| jdstrand | beowulf: https://developer.ubuntu.com/en/snappy/guides/security-policy/ has quite a bit of detail. there are two caps now: network-client (which can also be referred to as 'networking') and 'network-service' | 15:37 |
| mvo_ | seb128: oh, what version of ubuntu-device-flash are you using? | 15:37 |
| ogra_ | zyga, who uses containers ? | 15:37 |
| zyga | ogra_: how many libraries need patches to make non-writable /tmp work? | 15:37 |
| * ogra_ hasnt used a container since he started playing with snappy | 15:37 | |
| seb128 | mvo_, I've vivid + the ppa updated on friday | 15:38 |
| zyga | ogra_: don't we use namespace for devices already? | 15:38 |
| jdstrand | beowulf: if you don't specify caps at all, you get 'networking' (aka, client networking) | 15:38 |
| beowulf | jdstrand: thanks, we should link the first 'caps' to one of this doc | 15:38 |
| zyga | ogra_: s/containers/namespaces/ (which is mostly the same thing) | 15:38 |
| seb128 | mvo_, I need wily? | 15:38 |
| ogra_ | zyga, container means to me its an independent system ... | 15:38 |
| ogra_ | closer to a VM | 15:38 |
| jdstrand | fyi, we aren't using full blown containers | 15:38 |
| mvo_ | seb128: hm, that should be ok - give me a sec to double check | 15:38 |
| jdstrand | nither a system container nor an app container | 15:39 |
| jdstrand | ie, we aren't reinventing docker. if you need an app container, use docker on snappy | 15:39 |
| mvo_ | seb128: could you pastebin the ubuntu-device-flash version you are using? | 15:39 |
| jdstrand | we do use a few containery techniques though | 15:39 |
| seb128 | mvo_, how do I get it? | 15:39 |
| dholbach | jdstrand, sorry, which tutorial? | 15:39 |
| * jdstrand ->meeting | 15:39 | |
| zyga | ogra_: nomenclature aside, it is broken | 15:39 |
| jdstrand | dholbach: let me forward you the email in a bit | 15:39 |
| seb128 | mvo_, oh, there is an update, let me try that | 15:39 |
| dholbach | thanks jdstrand | 15:39 |
| seb128 | mvo_, sorry and I guess you meant package version, I though it was a binary bundled with other things ;-) | 15:40 |
| ogra_ | zyga, talk to the security team ... i'm sure there is a rationale | 15:40 |
| * zyga looks at why python crashes there, it does seem to look at TMPDIR | 15:41 | |
| * ogra_ would be surprised if it didnt | 15:42 | |
| barry | dholbach: i'm not sure what's "too complex" about it. i tried to make it super easy for people | 15:42 |
| zyga | jdstrand: a non-writable /tmp is rather harsh, is there a rationale for it? | 15:42 |
| zyga | jdstrand: (understanding app separation) | 15:42 |
| mvo_ | seb128: no worries | 15:43 |
| seb128 | mvo_, k, still not working | 15:43 |
| dholbach | barry, I didn't say it was "too complex" | 15:43 |
| jdstrand | zyga, ogra_: I didn't read all backscroll, but see the change to the launcher in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages | 15:43 |
| barry | sure, we want to not rely on the base interpreter, but that's tractable i think | 15:43 |
| barry | dholbach: oh, sorry, i think asac might have | 15:43 |
| seb128 | mvo_, it gives me "Channel edge not found on server http://system-image.ubuntu.com" | 15:43 |
| seb128 | mvo_, version is 0.20snappy7-0ubuntu1.2 | 15:43 |
| jdstrand | zyga: the app is supposed to have a writable tmp area. that is why TMPDIR was set. apps should not be able to read each others temp files, so they are in different dirs. the change to the launcher now creates a private mount namespace for /tmp | 15:44 |
| zyga | ogra_: TEMPDIR is set but TMPDIR is not | 15:44 |
| zyga | it's set but doens't make it through | 15:44 |
| ogra_ | sounds liek a bug | 15:44 |
| zyga | ogra_: yep | 15:44 |
| ogra_ | file it then :) | 15:45 |
| zyga | lp:snappy? | 15:45 |
| ogra_ | https://bugs.launchpad.net/snappy | 15:45 |
| ogra_ | (as the topic says) | 15:45 |
| zyga | thanks | 15:45 |
| ogra_ | though i guess its a launcher bug | 15:45 |
| mvo_ | seb128: confusing http://paste.ubuntu.com/11523152/ seems to work for me - maybe I had a typo in my earlier command? | 15:47 |
| zyga | https://bugs.launchpad.net/snappy/+bug/1461146 | 15:47 |
| ubottu | Ubuntu bug 1461146 in Snappy "TMPDIR is set by the generated launcher, doesn't make it to executable" [Undecided,New] | 15:47 |
| jdstrand | zyga: is that for a systemd service or a cli command? | 15:48 |
| zyga | jdstrand: cli | 15:48 |
| ogra_ | looks like cli | 15:48 |
| jdstrand | ok | 15:48 |
| zyga | jdstrand: I can give you the snap if you want to | 15:48 |
| jdstrand | no, that's ok | 15:48 |
| seb128 | mvo_, http://paste.ubuntu.com/11523181/ here :-( | 15:48 |
| seb128 | mvo_, do you use the same server? | 15:49 |
| jdstrand | I was thinking it might be another bug but if it is cli, then it isn't | 15:49 |
| mvo_ | sergiusens: are there multiple 0.20snappy7-0ubuntu1.2 ubuntu-device-flash versions around :/ ? | 15:49 |
| ogra_ | looks simply like a typoed var | 15:49 |
| mvo_ | sergiusens: see seb128 question | 15:49 |
| beowulf | @reviewlist | 15:50 |
| nothal | https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old) | 15:50 |
| nothal | https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old) | 15:50 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old) | 15:50 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old) | 15:50 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old) | 15:50 |
| beowulf | mvo_: :) | 15:50 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260111 | No reviews (6 days old) | 15:50 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (12 days old) | 15:50 |
| nothal | https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (41 days old) | 15:50 |
| seb128 | mvo_, sergiusens, sorry, it works now after the upgrade | 15:50 |
| mvo_ | ok | 15:50 |
| seb128 | mvo_, sergiusens, I had the previous binary copied over to try something and I forgot about it :-/ | 15:51 |
| seb128 | mvo_, thanks and sorry again ;-) | 15:51 |
| mvo_ | beowulf: bad luck, dinner time here | 15:51 |
| mvo_ | seb128: no worries | 15:51 |
| seb128 | mvo_, no luck with the wily iso, boots ok on an old laptop but is not recognized by my uefi laptop config | 16:18 |
| * zyga hopes snappy adopts git | 16:26 | |
| zyga | bzr changes are pretty hard to follow | 16:27 |
| * tbr never really grok'd bzr nor hg | 16:27 | |
| zyga | bzr/hg/git aside, readable patches are relevant | 16:28 |
| mvo_ | seb128: meh | 16:30 |
| seb128 | mvo_, yeah :-/ | 16:32 |
| mvo_ | seb128: maybe worth talking to slangasek about this, I might misremember but I think he created uefi bootable image before for snappy | 16:47 |
| seb128 | mvo_, k, thanks | 16:47 |
| seb128 | slangasek, hey, do you have hints about how to get a snappy iso to boot on an uefi/secure boot laptop config? the standard iso seems to not do the job | 16:47 |
| slangasek | iso? | 16:49 |
| slangasek | seb128: iso, or disk image? | 16:50 |
| slangasek | seb128: assuming it's a disk image that you're booting from USB, my first question would be, what version of udf did you use to master the image. The second question (assuming you're using a suitably recent udf with UEFI support) is what the contents of partition 2 are | 16:54 |
| seb128 | slangasek, I created an iso today using u-d-f 0.20snappy7-0ubuntu1.2 calling udf core rolling --channel edge -o img and dd-ed that to an usb stick | 17:00 |
| slangasek | ok, so... not an iso | 17:00 |
| seb128 | k, "image" | 17:00 |
| seb128 | sorry ;-) | 17:00 |
| Chipaca | what's the "official" url for meta.md ? | 17:01 |
| seb128 | you want details about one of the partitions? | 17:01 |
| zyga | sergiusens: https://lists.launchpad.net/checkbox-dev/msg00298.html | 17:01 |
| zyga | ogra_: quick question about shared libraries | 17:01 |
| zyga | ogra_: with rpath it's almost easy to get this to wrok | 17:01 |
| zyga | ogra_: but .sideload vs non-sideload thing makes it problematic to hard-code /apps/$name/current/lib as rpath | 17:02 |
| slangasek | seb128: I'm checking the changelog for 0.20snappy7-0ubuntu1.2 now, but to my knowledge, support for UEFI lands in ubuntu-device-flash 0.21 | 17:02 |
| zyga | ogra_: I know $ORIGIN exists, I need to see if I can use it (will it be /usr/bin/ or /apps/$name/current (?) | 17:02 |
| zyga | sergiusens: that's plainbox on snappy | 17:02 |
| zyga | I kind of like snappy | 17:02 |
| zyga | I just wish it was 5 years later, when it's all mature | 17:03 |
| zyga | and tooling is good | 17:03 |
| zyga | :-) | 17:03 |
| seb128 | slangasek, k, I'm using vivid + the ppa, maybe that's not uptodate enough | 17:03 |
| slangasek | seb128: confirmed, the last update to goget-ubuntu-touch in the production ppas was April 23, and UEFI support landed on May 8 | 17:04 |
| slangasek | so the snappy team needs to update goget-ubuntu-touch in the beta and 15.04 ppas | 17:04 |
| seb128 | mvo_, ^ | 17:04 |
| slangasek | seb128: if you need it for testing, you can use the version in the tools ppa: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/ | 17:05 |
| seb128 | slangasek, k, I'm going to try that, thanks | 17:06 |
| mvo_ | sergiusens: -^ | 17:06 |
| mvo_ | thanks slangasek and sorry for the noise | 17:06 |
| slangasek | mvo_: no worries :) | 17:07 |
| mvo_ | sergiusens: tl;dr - could you please release ubuntu-device-flash with the uefi support? or is somethng blocking and if so, how can I help :) | 17:09 |
| mvo_ | ? | 17:09 |
| sergiusens | mvo_: I was going to release it as soon as someone approved an MP I created on Saturday, it's unreviewed still | 17:26 |
| sergiusens | mvo_: also, I'm really scared of rebuilding now if we deviate from 15.04 compatibility in trunk | 17:27 |
| sergiusens | Chipaca: can you review https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/properDeviceFiltering/+merge/260646 ? | 17:33 |
| Chipaca | sergiusens: yes | 17:34 |
| Chipaca | sergiusens: no tests in this, no? | 17:35 |
| sergiusens | Chipaca: no | 17:37 |
| Chipaca | ok, off to make dinner for me | 17:37 |
| Chipaca | o/ | 17:37 |
| mvo_ | sergiusens: thanks and sorry for the lack of reviews | 17:59 |
| * rsalveti finally reads backlog | 19:28 | |
| tedg | jdstrand, So it seems that by default we give access to sed but not xargs, which one of this is the mistake? :-) | 19:55 |
| jdstrand | tedg: xargs is the mistake. can you file a bug against ubuntu-core-security? | 19:56 |
| jdstrand | tedg: is this blocking you? | 19:56 |
| jdstrand | I mean, I know it literally is blocking access, but, I'd like to know how fast you need it | 19:57 |
| tedg | jdstrand, Naw, I'll just copy it into my package. | 19:57 |
| * tedg *snaps* | 19:58 | |
| jdstrand | hehe | 19:58 |
| tedg | jdstrand, bug 1461243 | 19:58 |
| ubottu | bug 1461243 in ubuntu-core-security (Ubuntu) "Get DENIED for xargs" [Undecided,New] https://launchpad.net/bugs/1461243 | 19:58 |
| jdstrand | great, thanks! | 19:59 |
| tedg | jdstrand, Is there a way we could give a utility access to a specific directory? | 20:04 |
| tedg | jdstrand, The use case is that we have this snapcraft tool which will call other plugins for a language. But they need to access the user's home directory for what they're building. | 20:04 |
| tedg | jdstrand, It'd be nice if we didn't have to give them full access to everything, but instead snapcraft could say "oh, now this guy can have this" | 20:05 |
| tedg | (for this run) | 20:05 |
| sergiusens | zyga: I don't really follow your email, but I may need to read it with more time to grab some context | 20:30 |
| sergiusens | zyga: and we will switch to git once we have a nice tarmac replacement (no need for fancy stuff, can be polling based even as tarmac is today) | 20:31 |
| * sergiusens isn't sure what the ETA for webhooks is | 20:31 | |
| * sergiusens isn't sure the launchpad api can list MPs for git branches | 20:31 | |
| zyga | sergiusens: tarmac/git is in progress | 20:47 |
| zyga | sergiusens: the mail is just my ramblings, sorry for making it hard to read | 20:47 |
| zyga | sergiusens: I just wanted to show you plainbox snappyified :) | 20:47 |
| zyga | sergiusens: and ask if the $name.sideload vs $name could be resolved somehow | 20:48 |
| zyga | sergiusens: so that libraries can be used by using rpath | 20:48 |
| zyga | sergiusens: webhooks are not needed, AFAIR the git stuff is not exposed in the api yet | 20:48 |
| zyga | sergiusens: have a nice evening, bye :-) | 20:50 |
| sergiusens | zyga: not really; you shoulnd't rely on that path not changing | 20:50 |
| sergiusens | bye | 20:51 |
| jdstrand | tedg: if the snapcraft tool were confined, it would be possible, yes | 20:56 |
| jdstrand | tedg: or, the snapcraft tool could be apparmor aware and change to a profile for the plugin | 20:56 |
| tedg | jdstrand, I was figuring the snapcraft tool would call a binary registered by the plugin. | 20:58 |
| tedg | jdstrand, So that'd be effectively confined by the core launcher | 20:59 |
| jdstrand | hmm, I may not understand how the snapcraft tool is supposed to work. it might make sense to schedule a meeting with me and tyhicks | 20:59 |
| tedg | Czech Stop in West ? | 21:00 |
| jdstrand | heh. that would be nice :) | 21:01 |
| tedg | jdstrand, I think we're determining how it could work. So, if you think it shouldn't work like that, it's fine. | 21:01 |
| * tyhicks was there 2 days ago | 21:01 | |
| tyhicks | :) | 21:01 |
| tedg | I think that the thing we want is "super easy to make snaps" everything else is negotiable :-) | 21:01 |
| tedg | But I was thinking the language plugins could be "apps" in the traditional sense. | 21:04 |
| tedg | Hoping they'll have to be as little special as possible. | 21:04 |
| tyhicks | tedg: is there a design doc for snapcraft at this point? | 21:06 |
| tedg | tyhicks, We have more of an ideas document: https://docs.google.com/document/d/166fzfKp6YIZ839KyeNj2rO976ahLxWM35_fodwbPo1U/edit#heading=h.sta78u24yxr7 | 21:06 |
| tyhicks | tedg: thanks - I'll read up on it | 21:07 |
| rsalveti | elopio: we're not yet automatically updating the image published at http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ (which I have an action to check why) | 21:14 |
| rsalveti | sergiusens: I should know more about webhooks in a few days, when we get stakeholders meeting for launchpad | 21:36 |
| rsalveti | zyga: who is porting tarmac to git? | 21:37 |
| rsalveti | zyga: and for python, kind of the idea we had is that we'd have a devpack (that gets consumed when creating your snap) that would bundle the interpreter (but you could as well bring your own interpreter) | 21:38 |
| rsalveti | zyga: we don't want to use interpreters as frameworks necessarily | 21:38 |
| rsalveti | sergiusens: is there any sort of incompatibility with current ubuntu-device-flash related with 15.04 and rolling? | 21:53 |
| rsalveti | sergiusens: saw you pushed to wily, wonder if that will get stuck in proposed since we got a ftbfs for powerpc | 21:54 |
| sergiusens | @reviewlist | 23:07 |
| nothal | https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old) | 23:07 |
| nothal | https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old) | 23:07 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old) | 23:07 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old) | 23:07 |
| nothal | https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old) | 23:07 |
| sergiusens | rsalveti: yeah, it's stuck http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 23:07 |
| sergiusens | rsalveti: oh, and no, there's incompat today yet... key word, yet ;-) | 23:33 |
| rsalveti | sergiusens: right :-) | 23:33 |
| rsalveti | good making the release anyway since it's easier to tell people that they should be using a more recent version | 23:34 |
| sergiusens | rsalveti: right, I'm not sure I should be just using the ppa, most of the people we care about are on trusty | 23:51 |
| rsalveti | sergiusens: right, but they are all using the ppa, right? | 23:52 |
| sergiusens | rsalveti: and I guess all the uefi confusion was because we never migrated to the beta ppa | 23:52 |
| sergiusens | rsalveti: yup, they all use the ppa | 23:52 |
| rsalveti | right | 23:52 |
| rsalveti | yeah, I'll fix this ppa confusion soon | 23:52 |
| sergiusens | rsalveti: do you know wha the ETA is on powerpc? Or can we just blanket it through? | 23:53 |
| rsalveti | sergiusens: it seems doko/foundations doesn't have the time to fix the ppc builds atm, so I believe we should just ask for an override for it | 23:54 |
| rsalveti | so it's not blocked in proposed | 23:54 |
| sergiusens | rsalveti: great, so is that #ubuntu-release or #ubuntu-devel? | 23:54 |
| rsalveti | sergiusens: #ubuntu-release should work | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
