| === devil is now known as Guest61712 | ||
| example6 | Well, I learned that I need to do 'snapcraft assemble' to build the actual .snap, but when I do filesets to copy my binaries from stage/ to snap/ I keep getting an "Operation not Permitted" | 00:25 |
|---|---|---|
| qengho | example6: You only need "snapcraft" unless you want the process to end prematurely at some stage. | 00:27 |
| qengho | example6: I bet "strace -e trace=file -f snapcraft" will show you what you're doing wrong. | 00:29 |
| qengho | example6: And/or, "snapcraft --debug" | 00:31 |
| example6 | --debug doesn't seem to be available for me, but the trace showed me that it had been looking for my files in parts/test/install which they never were copied to. I have successfully made a snap now which is pretty much all I need. Thanks @qengho | 00:35 |
| === Aria22 is now known as Aria22|away | ||
| example6 | So in my snapcraft.yaml I specified daemon: simple and a command: property hoping that this would be registered as a snappy service and start automatically, but that seems not to be happening. Am I missing something big here? | 01:00 |
| === Guest61712 is now known as devil_ | ||
| zyga | kgunn: re | 06:42 |
| svij | hello! | 07:50 |
| svij | I've snapped a cli-tool | 07:50 |
| svij | how can I open the man pages of a snap? | 07:50 |
| zyga | svij: there's a bug open on this, currently man pages are not supported | 07:58 |
| zyga | svij: it's also non-obvious how it should behave | 07:58 |
| svij | zyga: alright | 07:58 |
| zyga | svij: e.g. what should be the man page name? $snap.$app | 07:59 |
| zyga | svij: original? | 07:59 |
| zyga | svij: should non-command man pages be alloweD? | 07:59 |
| zyga | svij: etc, ideas welcome, we honestly don't know yet | 07:59 |
| svij | zyga: that what I wondered too | 07:59 |
| === Trevinho_ is now known as Trevinho | ||
| === Aria22|away is now known as Aria | ||
| === JamesTait is now known as Guest96415 | ||
| === Guest96415 is now known as JamesTait | ||
| === Aria is now known as Aria|away | ||
| === vrruiz_ is now known as rvr | ||
| ysionneau | hi | 09:35 |
| ysionneau | if I declare a plug in my snapcraft.yaml which I use directly in the same snap : after installation is the plug supposed to be printed by "snap interfaces" command? | 09:36 |
| ysionneau | (because right now it's not :o) | 09:36 |
| cjwatson | zyga: man pages> I would say that the name should not be mangled; instead, rely on man-db's existing support for inferring MANPATH based on PATH | 09:45 |
| cjwatson | stuff other than section 1/8 is indeed trickier | 09:45 |
| zyga | ysionneau: what interface is the plug? | 09:45 |
| zyga | cjwatson: hmm, how does that work? | 09:45 |
| zyga | cjwatson: $PATH/../man/ or something? | 09:46 |
| cjwatson | zyga: basically | 09:46 |
| zyga | cjwatson: interesting, thanks for this idea! | 09:46 |
| cjwatson | zyga: also $element/../share/man | 09:46 |
| zyga | ysionneau: can you please share your snapcraft.yaml | 09:50 |
| ysionneau | zyga: sure! thanks a bunch :) http://pastebin.com/ZK8nRftb | 09:53 |
| slvn | Hey ! I have some issue with the ubuntu "myapps" : "Core" vs "Personnal". I have .click packages for ubuntu phones, and I am also publishing some snap package. seems click and snap got merged ... | 09:59 |
| slvn | I mean, the same webpage display release of click and snap, is this normal ? | 09:59 |
| zyga | ysionneau: looking | 10:06 |
| zyga | ysionneau: old security is gone | 10:06 |
| zyga | ysionneau: the plug is parsed and thein ignored | 10:06 |
| zyga | ysionneau: you cannot run unconfined with old securiry anymore | 10:06 |
| davmor2 | JamesTait: ^ slvn you might be able to answer | 10:09 |
| slvn | somehow, based on the naming, .snap package are added under on the same package of my .clik packages | 10:10 |
| pmp | is there a way to have snapcraft syntax check my .yamls? | 10:10 |
| slvn | It actually makes sense! don't know wheter this is wanted or not | 10:10 |
| JamesTait | I'm not aware of any merge... it wouldn't really make sense, with the package file formats being different (.deb for clicks, squashfs for snaps). | 10:12 |
| slvn | also, my click package are targetted to ubuntu phones (ARM), wherease the .snap are Amd64 | 10:12 |
| JamesTait | Sounds like a bug to me. | 10:13 |
| slvn | JamesTait, then my account is a little screwed-up now .. | 10:14 |
| slvn | JamesTait, do you have some kind of admin account to see what's going on ? | 10:15 |
| slvn | I confirm that on my dev page, I see under "Overview" both revision of click and snap | 10:15 |
| JamesTait | Hmm... I see snaps under my Ubuntu Core tab and clicks under my Ubuntu Personal tab, but there's also a snap package that was shared with me on the Ubuntu Personal tab. So something's not right. | 10:16 |
| slvn | JamesTait, it's based on the naming, my apps that have the same name are merged when published for the first time | 10:17 |
| JamesTait | slvn, can you point me to an example package? | 10:18 |
| JamesTait | I have limited access, so won't be able to fix anything, but might be able to shed light on it for those who do. | 10:19 |
| slvn | JamesTait, https://myapps.developer.ubuntu.com/dev/click-apps/773/ | 10:19 |
| slvn | a mahjong game | 10:19 |
| slvn | snap is not published, click is published months ago | 10:20 |
| slvn | both are merge .. | 10:20 |
| slvn | 'd | 10:20 |
| === Aria|away is now known as Aria | ||
| JamesTait | slvn, looking into it for you. | 10:21 |
| slvn | thanks ... | 10:23 |
| JamesTait | slvn, OK, there's another user seeing the same thing, so it's not just a problem with your account. | 10:24 |
| slvn | JamesTait, ok ... | 10:25 |
| JamesTait | slvn, we're looking into the root cause - could you file a bug for it in the meantime? https://bugs.launchpad.net/software-center-agent/+filebug | 10:28 |
| slvn | JamesTait, here it is: https://bugs.launchpad.net/software-center-agent/+bug/1577717 | 10:32 |
| ubottu | Launchpad bug 1577717 in Software Center Agent "Published snap package appears under the list of click packages" [Undecided,New] | 10:32 |
| JamesTait | Thanks, slvn, we're on it. | 10:33 |
| slvn | ok great ! | 10:33 |
| === Aria is now known as Aria|away | ||
| === Aria|away is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/1117 | 11:03 |
| ysionneau | zyga: how do we run unconfined now? | 11:03 |
| ogra_ | --devmode | 11:04 |
| zyga | ysionneau: http://www.zygoon.pl/2016/04/snap-install-devmode.html | 11:04 |
| ysionneau | zyga : ah thanks! | 11:12 |
| jdstrand | zyga: ack but it will be a little while | 11:26 |
| * jdstrand -> long meeting | 11:26 | |
| zyga | jdstrand: sure | 11:26 |
| noizer | Hi guys | 11:28 |
| noizer | I have a problem with an library that i want to use. | 11:28 |
| noizer | The library does only support Soft float on my raspberry pi 3 | 11:28 |
| noizer | Is there any possibility to change snappy from Hard float to Soft Float? | 11:29 |
| zyga | noizer: snappy doesn't care about binaries you run | 11:30 |
| zyga | noizer: does that library run without snappy? | 11:30 |
| noizer | zyga: No I tried to install it on a raspberry pi with ubuntu mate. But there I had a problem with hard floating :s | 11:32 |
| zyga | noizer: can you be more specific? | 11:33 |
| noizer | zyga: i'm not familiar with hard and soft floating | 11:33 |
| zyga | noizer: can you pastebin anything? | 11:33 |
| noizer | zyga: Do you know Nuance the tts egine. They support only there library on ARM processors with soft floating | 11:34 |
| zyga | noizer: nope | 11:34 |
| ogra_ | i doubt it will work | 11:34 |
| kyrofa | Good morning | 11:34 |
| ogra_ | you might be able to ship a complete armel chroot inside your snap ... perhaps ... | 11:34 |
| zyga | softfloat means that floating point is emulated, so it should work anywhere (slowly) | 11:35 |
| ogra_ | (but you would need to use a dristro that even provides armel ... armel is dead in ubuntu since 9.04 or so) | 11:35 |
| zyga | though if you want to link to it with a armhf gcc you won't have luck | 11:35 |
| ogra_ | zyga, you cant exec armel binaries on armhf systems | 11:35 |
| zyga | noizer: ask Nuance to rebuild | 11:35 |
| zyga | ogra_: are you sure? why not? | 11:35 |
| ogra_ | yes i'm sure | 11:35 |
| zyga | ogra_: curious, why is that? | 11:36 |
| ogra_ | you can multiarch ... | 11:36 |
| zyga | ah | 11:36 |
| ogra_ | but that means *all* libs | 11:36 |
| zyga | well, that's okay I was just curious | 11:36 |
| zyga | right that's exactly what I expected | 11:36 |
| zyga | it's just a different abi | 11:36 |
| ogra_ | and it means you cant use ubuntu | 11:36 |
| zyga | right, so you *can* execute but you need to bag all the bit you need | 11:36 |
| zyga | the cpu won't care | 11:36 |
| ogra_ | cpu and kernel wont care (if it is a hardfloat capable cpu) ... | 11:37 |
| zyga | right | 11:37 |
| ogra_ | but you need to ship a full chroot inside your snap | 11:37 |
| zyga | noizer: long story short I'd recommend really asking those folks for a build | 11:37 |
| ogra_ | (and all this is 100% theoretical ... i dont think anyone ever actually tesetd this) | 11:38 |
| zyga | yep | 11:38 |
| noizer | zyga: We asked for it but it will cost us 250 000 euro for a rebuild with all the features we want | 11:38 |
| zyga | noizer: for an armhf rebuild? | 11:38 |
| zyga | wow they are picky :) | 11:38 |
| noizer | zyga: yes | 11:38 |
| ogra_ | wow ... thats like ... a lot of money for 5min of work | 11:38 |
| zyga | noizer: unless they hand coded that with assembly that's typically "make" on an ubuntu install :/ | 11:38 |
| ogra_ | yeah | 11:39 |
| * zyga smeslls marketing BS (not noizer's in any way) | 11:39 | |
| zyga | noizer: quick idea | 11:39 |
| noizer | zyga I don't know how they builded it but yeah it is very expensive to rebuild | 11:39 |
| zyga | noizer: get a raspberry pi 1 image, put it on your pi2's home directory | 11:40 |
| zyga | and chroot | 11:40 |
| zyga | if that works we can snap it | 11:40 |
| zyga | noizer: that's total BS they just want money :) | 11:40 |
| ogra_ | yeah, it is definitely just "rebuild with ubuntu toolchain" | 11:40 |
| ogra_ | i.e pull your source tree onto an ubuntu armhf and build it ... | 11:40 |
| zyga | ogra_: we even have nice cross toolchains packaged | 11:40 |
| zyga | so they don't even need a board | 11:41 |
| ogra_ | yeah | 11:41 |
| ogra_ | well | 11:41 |
| ogra_ | depends on the depends ;) | 11:41 |
| * zyga will start charging $0.25M for his python rebuilds now ;) | 11:41 | |
| zyga | ogra_: yeah true | 11:41 |
| ogra_ | (you really wouldnt want to cross build a gui app that uses a lot of libs ... ) | 11:41 |
| ogra_ | wxgtk ;) | 11:41 |
| noizer | zyga how does it works then with the image of rpi 1 | 11:42 |
| zyga | noizer: pi1 is using an older cpu | 11:42 |
| zyga | noizer: e.g. a raspian image is compiled for armel | 11:43 |
| noizer | zyga ok then put it on my rpi3 and compile and install it on that image? | 11:44 |
| zyga | noizer: compile everything on your pi1 | 11:46 |
| zyga | noizer: make sure it works there | 11:46 |
| zyga | noizer: then grab the whole sd card and tarball it | 11:46 |
| zyga | noizer: then put that tarball on a pi3 | 11:46 |
| zyga | noizer: unpack it, you may need to tweak some things (bind mount /proc etc) | 11:46 |
| zyga | noizer: then chroot | 11:47 |
| zyga | noizer: check that it still works | 11:47 |
| zyga | noizer: if you get that far we should be able to snap it | 11:47 |
| * zyga looks forward to "enterprise" software | 11:47 | |
| ogra_ | if the above doesnt work you should always be able to use a real container | 11:48 |
| ogra_ | lxc or docker ... | 11:48 |
| noizer | So what will docker do then? | 11:49 |
| zyga | noizer: don't worry about docker | 11:49 |
| zyga | noizer: try what I said | 11:49 |
| noizer | ps Is there not a way to make snappy Soft floating? | 11:49 |
| noizer | zyga Ok how will it works then with my other software because my software needs to connect with the libaray. | 11:51 |
| ogra_ | you would have to ship it as softfloat too ... likely in the snap snap | 11:52 |
| ogra_ | *same snap | 11:52 |
| ogra_ | (geez ... /me curses freud) | 11:53 |
| noizer | Damn thats very hard then :s | 11:53 |
| ogra_ | (in a year from now the above sentence will be "snap snap, snap snap snap, snap !" .... ) | 11:54 |
| zyga | noizer: why is that hard? | 11:54 |
| zyga | noizer: it's not pretty, essentially shiping a foreign distro in a snap | 11:55 |
| zyga | noizer: but since the CPU itself allows this it would not be much different from running raspbian natively | 11:55 |
| zyga | noizer: I guess it depends on what you want? prove that it's possible for a demo? use it "in production" | 11:56 |
| ogra_ | yeah, not m,uch different from running i386 chroots on amd64 | 11:56 |
| zyga | yeah | 11:56 |
| * zyga curses timezones | 11:57 | |
| zyga | is UOS starting in two hours from now? | 11:57 |
| kyrofa | zyga, indeed | 11:59 |
| zyga | thanks kyrofa | 11:59 |
| kyrofa | zyga, plenary opening in two hours, sessions start in three | 12:00 |
| kyrofa | Hey ogra_ I've been investigating the ROS failure on xenial-- the one that was due to locale settings. On Ubuntu Core, at least the image I have, LANG=C.UTF-8. However, on Xenial LANG=en_US.UTF-8. ROS runs fine with C.UTF-8 but errors out with en_US.UTF-8 (like this: http://pastebin.ubuntu.com/16200846/ ) | 12:05 |
| kyrofa | ogra_, is that just a difference between ubuntu core and the desktop? | 12:06 |
| noizer | zyga Ok I will try it tomorrow because then I got my rpi1 with me | 12:06 |
| zyga | noizer: good luck | 12:07 |
| noizer | zyga If i have some troubles can you help me out then? | 12:07 |
| ogra_ | kyrofa, we ship no locales at all on the image ... | 12:07 |
| zyga | noizer: i'll be attending UOS but I can try | 12:07 |
| noizer | UOS? what does that mean? | 12:07 |
| ogra_ | noizer, ubuntu online summit | 12:07 |
| zyga | heh | 12:08 |
| kyrofa | noizer, http://summit.ubuntu.com/ | 12:08 |
| zyga | I just tried to install a snap | 12:08 |
| zyga | sudo snap -i ... | 12:08 |
| ogra_ | usually the place weher we do planning for the next release ... | 12:08 |
| zyga | old habits die hard | 12:08 |
| ogra_ | fix that 1 | 12:08 |
| ogra_ | ! | 12:08 |
| ogra_ | (by adding -i ;) ) | 12:08 |
| zyga | ogra_: maybe I'll implement -i as a hidden command | 12:08 |
| zyga | also printing "we feel your pain" ;-) | 12:08 |
| ogra_ | yeah :) | 12:08 |
| kyrofa | ogra_, that explains the C then, I suppose. Right? | 12:11 |
| ogra_ | right, we ship whatever libc includes by default ... which is C and C.UTF-8 | 12:11 |
| ogra_ | there is no additional locale handling in the rootfs ... you have to do that inside the snap itself if needed | 12:12 |
| kyrofa | ogra_, right, I have the opposite problem-- the locale on the xenial desktop is busting me. So I guess I should just set C.UTF-8 in my snap, huh? | 12:13 |
| ogra_ | (we also dont ship keymaps or fonts that support UTF8 ) | 12:13 |
| kyrofa | I don't know why it's not working though, which is frustrating | 12:13 |
| ogra_ | kyrofa, yeah | 12:13 |
| kyrofa | Stupid boost and its cryptic errors | 12:13 |
| sergiusens | morning | 12:15 |
| kyrofa | Morning sergiusens :) | 12:15 |
| * zyga triaged https://bugs.launchpad.net/snappy/+bug/1577472 | 12:17 | |
| ubottu | Launchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete] | 12:17 |
| zyga | ogra_: btw, do you perhaps know what compells gnome-terminal (or shell running inside it) to interpret, e.g. alt+l as ł (on my locale) | 12:18 |
| zyga | ogra_: I'm asking because it seems to stop as soon as I run a snap | 12:18 |
| zyga | (not all snaps, but hello world seems to be affected) | 12:18 |
| ogra_ | hopefully all snaps :) | 12:18 |
| zyga | not all snaps :) | 12:18 |
| ogra_ | oh ? | 12:18 |
| zyga | ogra_: build this https://bugs.launchpad.net/snappy/+bug/1577472 | 12:19 |
| ubottu | Launchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete] | 12:19 |
| zyga | ogra_: (snapcraft.yaml inline) | 12:19 |
| zyga | ogra_: that snap still works! | 12:19 |
| zyga | as in I get ł | 12:19 |
| ogra_ | we explicitly do not chip any locale support, keymaps or console fonts | 12:19 |
| ogra_ | (that would likely easily triple the size of the rootfs ) | 12:19 |
| zyga | ogra_: but how does it work, gnome-terminal is from the classic ubuntu side | 12:19 |
| zyga | ogra_: so it has the fonts | 12:19 |
| zyga | ogra_: I don't know how input handling works | 12:19 |
| ogra_ | but not the locale info | 12:20 |
| zyga | but I suspect it's also on the teminal side | 12:20 |
| zyga | locale, right I get how locale works | 12:20 |
| ogra_ | we only support C.UTF-8 | 12:20 |
| zyga | but it doesn't affect keyboard input | 12:20 |
| ogra_ | it affects the representation of the key code | 12:20 |
| zyga | hmm? how does that work? I suspect that the shell puts the tty into raw mode | 12:21 |
| zyga | but what happens next? | 12:21 |
| zyga | and how is that affected by snappy | 12:21 |
| zyga | (I'm trying to understand why it doesn't work in hello-world but works in the small example I made) | 12:21 |
| ogra_ | http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml | 12:21 |
| ogra_ | have a look at that | 12:21 |
| zyga | I see locales there | 12:22 |
| ogra_ | if you want your snap to have support for more than C.UTF-8, you have to ship this set of packages | 12:22 |
| zyga | I don't think that answers my question | 12:22 |
| zyga | I'm specifically asking about how input handling works | 12:22 |
| zyga | and why one snap behaves differently than another one | 12:22 |
| zyga | the snap I made has busybox-static | 12:22 |
| ogra_ | a keycode is sent ... it gets processed and a char is printed :P | 12:22 |
| zyga | hmmm | 12:23 |
| zyga | right | 12:23 |
| zyga | I see | 12:23 |
| zyga | processed, that's where locales go in | 12:23 |
| ogra_ | if your font doesnt have the char, it cant be printed (and you get little squares) | 12:23 |
| zyga | I guess that busybox just accepts and echoes everything that's not a special control character clearly | 12:23 |
| zyga | and bash is is doing it "properly" and hence I get nothing | 12:23 |
| zyga | (properly == through locale) | 12:23 |
| ogra_ | right | 12:24 |
| zyga | thanks! | 12:24 |
| zyga | that makes sense | 12:24 |
| zyga | I forgot about raw mode | 12:24 |
| zyga | console echo can be deceiving :) | 12:24 |
| ogra_ | if you ship locales and console-setup-linux you should be able to get around that | 12:24 |
| zyga | nah, I was just curious how it works | 12:25 |
| zyga | I don't really need it for anything now | 12:25 |
| zyga | I'd love if someone made locale that's tiny | 12:25 |
| ogra_ | lol | 12:25 |
| zyga | and is not shipping translation | 12:25 |
| zyga | translations* | 12:25 |
| zyga | tiny as in ~50Kb max | 12:25 |
| ogra_ | locale and tiny dont really fit into the same sentence | 12:25 |
| zyga | what's in locale anyway? | 12:25 |
| zyga | what's the big part? | 12:26 |
| zyga | (is it just glibc doing crazy correct huge thing or is it an intrinsict problem of locale data) | 12:26 |
| ogra_ | (i mean, the locale itself perhaps ... but you need all tghe surroundings like termcap/curses ... fonts etc etc ) | 12:26 |
| zyga | fonts = not really | 12:26 |
| zyga | (not on classic) | 12:26 |
| zyga | not in webapps | 12:26 |
| zyga | termcap = not in webapps | 12:26 |
| ogra_ | just ship the locales package | 12:27 |
| zyga | and outside, man just ship one for xterm and ignore the rest :P we have two termcap packages, one normal and one kitchen-sink one | 12:27 |
| zyga | I see a billion charmaps | 12:27 |
| zyga | perhaps 90% of them are useless today | 12:28 |
| zyga | or 100%-1 | 12:28 |
| zyga | man what a load of garbage :) | 12:28 |
| zyga | and the actual locale definitions should be easily under 50KB compiled | 12:28 |
| zyga | even the charmaps are tiny | 12:29 |
| zyga | (obsolete but small) | 12:29 |
| zyga | though locales get some processing | 12:29 |
| zyga | (which is also super slow) on install time | 12:29 |
| zyga | do you know what that does? | 12:30 |
| ogra_ | it creates the binaries | 12:30 |
| ogra_ | from the locale definitions | 12:30 |
| zyga | does that have to run at install time? | 12:30 |
| ogra_ | (simply calls locale-gen i think) | 12:30 |
| zyga | can we compile all locales on snap build time? | 12:31 |
| * zyga reading the script now | 12:31 | |
| ogra_ | if you want to use the locales, they have to be up to date against whats on the system, yes | 12:31 |
| zyga | just shell, no perl :) | 12:31 |
| zyga | against what's on the system? what does that mean? | 12:31 |
| zyga | are they self contained or not? | 12:31 |
| ogra_ | if they were self contained you would have to generate them at install time ;) | 12:32 |
| zyga | so what do they need from the system on install time? | 12:32 |
| * zyga reads the script | 12:32 | |
| ogra_ | have a look under /usr/share/locale | 12:32 |
| zyga | I see just .mo files | 12:33 |
| zyga | anything I'm missing | 12:33 |
| zyga | mo files are built at compile time | 12:33 |
| zyga | I don't suspect locale-gen needs gettext to run | 12:33 |
| ogra_ | and locales are built from the mo files | 12:33 |
| zyga | !? | 12:34 |
| zyga | but they contain keymaps | 12:34 |
| zyga | how is that related to translations | 12:34 |
| ogra_ | LC_MESSAGES is part of your locale | 12:34 |
| zyga | keymaps and charmaps | 12:34 |
| zyga | yes but the question is: why do we need to generate anything on install time | 12:34 |
| ogra_ | to be in sync with the binaries on the system | 12:35 |
| zyga | I don't understand, in sync with what | 12:35 |
| ogra_ | (better ask infinity for details) | 12:35 |
| ogra_ | buit afaik there is no way to ship "small" locales pre-created | 12:35 |
| zyga | if I update, say, the translation catalogue for something, do I need to rebuild locale data? | 12:35 |
| ogra_ | yes | 12:36 |
| zyga | do you know why? | 12:36 |
| ogra_ | out prob is really that we do not enforce C.UTF-8 ebverywhere yet | 12:36 |
| zyga | that's not a solution to apps wanting to have locale support really | 12:37 |
| ogra_ | you dont really want country specifric locales, but you want full UTF-8 support | 12:37 |
| ogra_ | which a LOCALE=C default doesnt give you | 12:37 |
| zyga | I'm trying to understand how locale works today | 12:37 |
| zyga | I know that | 12:37 |
| zyga | I disagree about country specific locale, it depends on an app | 12:37 |
| ogra_ | but half of snappy uses C ... the other half uses C.UTF-8 | 12:37 |
| zyga | hmm? do we set locale to C anywhere explicitly? | 12:38 |
| ogra_ | we're not consistent yet ... i.e. the launcher needs to enforce C.UTF-8 | 12:38 |
| zyga | I'm still puzzled by what you said earlier: | 12:38 |
| ogra_ | no | 12:38 |
| ogra_ | C is the fallback | 12:38 |
| mvo | zyga: we even have a bug about the ł issue: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576411 | 12:38 |
| ubottu | Launchpad bug 1576411 in snapd (Ubuntu) "UTF-8 is not very well supported inside snaps" [High,Triaged] | 12:38 |
| zyga | zygaif I update, say, the translation catalogue for something, do I need to rebuild locale data? | 12:38 |
| ogra_ | if nothing is set | 12:38 |
| zyga | ogra_yes | 12:38 |
| ogra_ | mvo, yeah, i just commented on that :) | 12:38 |
| zyga | right, I saw that bug | 12:38 |
| ogra_ | zyga, the issue is that we need to eliminate the places where C is still used | 12:39 |
| mvo | aha, nice | 12:39 |
| mvo | sorry,I looked at this yesterday haven't seen all the followups :) | 12:39 |
| zyga | ogra_: I still want to understand locale better | 12:39 |
| ogra_ | zyga, infinity is your man :) | 12:39 |
| zyga | thanks! | 12:39 |
| * zyga thinks this is a nice moment to take a lunch break | 12:40 | |
| === JanC is now known as Guest52941 | ||
| === JanC_ is now known as JanC | ||
| sergiusens | kyrofa I have one for you https://bugs.launchpad.net/snapcraft/+bug/1577750 | 12:59 |
| ubottu | Launchpad bug 1577750 in Snapcraft "Search for libraries for 16.10 cause a build failure" [Critical,In progress] | 12:59 |
| sergiusens | kyrofa better yet https://github.com/ubuntu-core/snapcraft/pull/496 | 12:59 |
| kyrofa | sergiusens, ah! | 12:59 |
| sergiusens | kyrofa yeah, ah describes it perfectly ;-) | 13:03 |
| kyrofa | sergiusens, I may have updated my comment as you were replying. But shouldn't the exclusion list be for the target rather than the host? | 13:12 |
| kgunn | zyga: hey, so from y'day discussing with jamie, looks like my interface is not "connecting" .... i added autoconnect true, but didn't seem to help | 13:18 |
| kgunn | thots? | 13:18 |
| zyga | kgunn: that's expected, the problem here is that auto-connect is only affecting the OS snap | 13:20 |
| niemeyer | dholbach: ping | 13:21 |
| zyga | kgunn: see http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html (the 2nd to last header) | 13:21 |
| zyga | kgunn: it will not connect anything to a slot on the mir snap, we need to discss how this should work before we enable it | 13:21 |
| kgunn | zyga: @will connect anything...you mean that expresses a mir plug in their yaml right? i would've thought that would be the prevention, e.g. manual review for anyone wanting the mir-server slot | 13:26 |
| zyga | kgunn: connect will connect anything compatible | 13:26 |
| zyga | kgunn: that's still a TBD, how we want this to work, it's related to assertions as well | 13:26 |
| zyga | kgunn: I think you should focus on getting the interface to work for mir proper and for mir client apps and we'll iterate on connection policy | 13:27 |
| kgunn | zyga: ok, i'll migrate to a connected slot today.... that should keep me busy :) | 13:29 |
| kgunn | i need to clean up client yaml too | 13:29 |
| zyga | kgunn: cool, ask me anything if you are blocked | 13:29 |
| zyga | dholbach: do you want me to prepare anything about interfaces? | 13:35 |
| zyga | dholbach: or should I just join various sessions and answer questions/talk | 13:35 |
| sergiusens | kyrofa yes, but we need to implement the `release` tag in snapcraft.yaml to know what we are targetting ;-) | 13:40 |
| kyrofa | sergiusens, okay, same page then | 13:40 |
| kyrofa | sergiusens, so for now we're assuming the same release as host? | 13:40 |
| sergiusens | kyrofa yeah :-) I want to play ball as if yakkety did not exist yet though | 13:40 |
| sergiusens | kyrofa yup | 13:41 |
| sergiusens | kyrofa and cleanbuild always assumes xenial | 13:41 |
| kyrofa | sergiusens, +1 | 13:41 |
| sergiusens | kyrofa we are xenial centric for now; I don't think we want to start supporting building from yakkety just yet | 13:42 |
| kyrofa | sergiusens, I agree, seems like a safe assumption | 13:42 |
| kyrofa | sergiusens, problems occur when targeting a release older than host. libc symbols and whatnot | 13:43 |
| sergiusens | ogra_ you are missing on the "other" network. Are you off today? | 13:43 |
| ogra_ | sergiusens, brunching :) | 13:43 |
| sergiusens | ogra_ and you have a game to watch today I guess ;-) | 13:44 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/1118 (for later) | 13:44 |
| ogra_ | sergiusens, bayern atletico ? yeah, i watched the first one ... wasnt that exciting though | 13:45 |
| dholbach | zyga, feel free to join any of them - for the interfaces session, I guess niemeyer and you can start talking about interfaces generally and then we can move on to questions, workflow, etc. | 13:50 |
| kyrofa | sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/497 | 13:50 |
| zyga | great, that's a plan then | 13:50 |
| niemeyer | dholbach: Heya | 13:50 |
| dholbach | hey niemeyer | 13:50 |
| niemeyer | dholbach: Can we move the two core sessions we have at 15UTC to 17UTC? | 13:50 |
| dholbach | http://summit.ubuntu.com/uos-1605/2016-05-03/ is the schedule for today :)= | 13:51 |
| dholbach | :-) | 13:51 |
| niemeyer | dholbach: I think the 17UTC slot is open on that track on both days | 13:51 |
| dholbach | hohum | 13:51 |
| dholbach | we announced the schedule already, so some might have planned their days according to this | 13:51 |
| dholbach | 17 UTC today is the lunch slot | 13:51 |
| dholbach | and the 15 UTC session today is about python3 | 13:51 |
| dholbach | so led by somebody in the foundations team | 13:52 |
| ysionneau | zyga: read_paths / write_paths still exists ? | 13:53 |
| zyga | ysionneau: no it does not | 13:53 |
| zyga | ysionneau: that was a part of old-security | 13:53 |
| ysionneau | what is the modern way? | 13:54 |
| zyga | ysionneau: to come up with a new interface | 13:54 |
| zyga | ysionneau: what do you need access to? | 13:54 |
| dholbach | niemeyer, ^ did you see my reply? | 13:54 |
| niemeyer | dholbach: Okay, sounds good, thanks | 13:55 |
| ysionneau | ok maybe let me copy paste all the warnings I get (in --devmode) zyga | 13:55 |
| dholbach | niemeyer, cool | 13:55 |
| zyga | ysionneau: please do! | 13:55 |
| ysionneau | zyga: http://paste.ubuntu.com/16201687/ | 13:56 |
| zyga | ysionneau: ah, /dev/shm, we're looking into making that easier | 13:56 |
| zyga | ysionneau: currently you can access /dev/shm but just in weird locations | 13:56 |
| ysionneau | yeah I've seen the mailing list posts | 13:57 |
| sergiusens | kyrofa https://github.com/ubuntu-core/snapcraft/pull/498 | 14:00 |
| sergiusens | kyrofa about locale, I have ideas :-) | 14:00 |
| kyrofa | sergiusens, good deal. Should we hold off on that catkin PR, then? | 14:00 |
| * zyga tunes into UOS | 14:01 | |
| sergiusens | kyrofa just until standup which is when UOS ends :-) | 14:02 |
| kyrofa | sergiusens, sounds good | 14:03 |
| pmp | is there somewhere an snapcraft.yaml-example (up-to-date) which shows how to request a syscall permission?! | 14:12 |
| sergiusens | pmp that is not possible anymore, now it is required to do it through interfaces (no surprises for end users). Talk to zyga or jdstrand (or attend the UOS session about it today!) | 14:16 |
| zyga | pmp: o/ | 14:16 |
| sergiusens | personally I am hit by it a bit too as I can't easily get things out of the way | 14:16 |
| dholbach | UOS sessions today: http://summit.ubuntu.com/uos-1605/2016-05-03/ | 14:20 |
| zyga | pmp: which system call are you missing? | 14:21 |
| pmp | send - for a test I removed all plugs-sections of my apps - now added network | 14:26 |
| zyga | pmp: send for a test? can you elaborate on that? | 14:27 |
| pmp | the missing syscall was 'test' (289 on arm) | 14:27 |
| pmp | not test - 'send' | 14:27 |
| pmp | plugging my app to network fixed | 14:28 |
| zyga | pmp: ah, cool :) | 14:28 |
| zyga | pmp: so you don't need any interfaces beyond network? | 14:28 |
| pmp | zyga: not for the moment | 14:28 |
| zyga | pmp: cheers, good luck :) | 14:28 |
| kyrofa | sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/450 has been rebased | 14:31 |
| pmp | zyga: well, I just got another syscall missing 241, which is sched_setaffinity | 14:37 |
| sergiusens | pmp you can start out by logging a bug and tagging it like https://bugs.launchpad.net/snappy/+bugs?field.tag=snapd-interface | 14:39 |
| pmp | sergiusens: where (in snappy) is the mapping done between syscalls and interfaces? | 14:41 |
| sergiusens | pmp in https://github.com/ubuntu-core/snappy | 14:41 |
| sergiusens | exact location I would need to check for | 14:41 |
| sergiusens | oh, top level interfaces in there | 14:42 |
| noizer | zyga short question what OS should i run on the rpi1 for the soft-float problem | 14:42 |
| zyga | noizer: rasbian should be easiest to work with | 14:43 |
| zyga | noizer: the default pi os | 14:43 |
| noizer | ok will it be automatically soft float? | 14:43 |
| noizer | because i dont know mutch of floating etc | 14:43 |
| noizer | may it be the latest rasbian? | 14:44 |
| zyga | noizer: all of pi1 is like that | 14:44 |
| zyga | noizer: yes, any version will work | 14:44 |
| noizer | zyga ok | 14:45 |
| noizer | maybe for good understanding | 14:45 |
| noizer | zyga i just need to build an application for the soft floating | 14:45 |
| noizer | on rpi1 | 14:45 |
| zyga | noizer: https://wiki.debian.org/ArmHardFloatPort (for some back-story) | 14:45 |
| noizer | what should i do then? | 14:46 |
| zyga | noizer: install rasbian, build your app there | 14:47 |
| zyga | noizer: test your app | 14:47 |
| zyga | noizer: look at the list I gave eaarlier, ask questions if you get stuck | 14:47 |
| noizer | zyga: then i need to chroot and build it in a snap? | 14:48 |
| zyga | noizer: then you need to take that whole rasbian install and stick it in your home directory on a pi3 system runnning ubuntu 16 series | 14:49 |
| zyga | noizer: then we can see if it works there if you chroor inside | 14:49 |
| zyga | noizer: we can look at snapping that, if it works, at the very end | 14:49 |
| noizer | Ok | 14:49 |
| noizer | hopefully will it work | 14:50 |
| zyga | (or pi2, I don't know if pi3 works yet) | 14:50 |
| zyga | ogra_: does pi3 work btw? | 14:50 |
| zyga | with the pi2 image | 14:50 |
| noizer | I can start first with the pi2 | 14:51 |
| ogra_ | zyga, yes ... though i'd suggest to build your own image using the pi3 gadget | 14:51 |
| zyga | ogra_: ah, nice, let me try that | 14:51 |
| ogra_ | i will roll back the pi2 one to pi2 only very soon | 14:51 |
| zyga | I recall mvo did some changes to gadget support | 14:52 |
| zyga | wonder if that affects ip3 | 14:52 |
| ogra_ | which would leave you with an unbootable image | 14:52 |
| noizer | ogra_: oooh ok | 14:52 |
| zyga | pi3 | 14:52 |
| ogra_ | the pi2 and 3 gadgets are identical ... apart from uboot.bin | 14:52 |
| ogra_ | so as long as the pi2 one works, the pi3 one will too | 14:52 |
| pmp | ogra_: well the pi2 still behaves "not as before" - terminal via uart still doesn't work and the red-led is behaving strangly | 14:55 |
| ogra_ | pmp, yes, on my TODO | 14:55 |
| pmp | but it works | 14:56 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/canonical-pi2_3.3_all.snap | 14:56 |
| pmp | I mean snap is working nicely - ideal for my tests | 14:56 |
| ogra_ | feel free to help testing this ;) | 14:56 |
| ysionneau | it seems interfaces like network and network-bind are "builtin" in github/ubuntu-core/snappy . But I have other interfaces when I do "snap interfaces", I guess those are defined by ubuntu-core? Where is ubuntu-core code repo? | 14:56 |
| zyga | ysionneau: all of those are coming from snappy | 14:56 |
| ogra_ | (thats my pending upload for the gadget snap that should restore the old UART behaviour | 14:56 |
| zyga | ysionneau: I can show you where it is in the code if you want | 14:57 |
| ogra_ | ) | 14:57 |
| zyga | ysionneau: the core snap could, but is not currently, defining any interfaces | 14:57 |
| zyga | ysionneau: in the snappy source tree look at snap/implicit.go | 14:57 |
| zyga | ysionneau: all of the interfaces are defined in interfaces/builtin/ | 14:57 |
| ysionneau | so far I looked at https://github.com/ubuntu-core/snappy/tree/5324816c114757ed1b8641a63a84d6bd3a6edb66/interfaces/builtin | 14:58 |
| ysionneau | ok lemme have a look at implicit.go :) | 14:58 |
| ysionneau | thx | 14:58 |
| zyga | ysionneau: there's also my post that describes a bit about how interfaces look like: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html | 14:58 |
| ysionneau | ah I see. | 14:58 |
| ysionneau | zyga: oh, I didn't see this one, did you post it on the ML? | 14:59 |
| pmp | ogra_: I'd love to get more insights, but it is hard to find the bits and pieces - how to build a u-d-f for example, how to make a gadget-snap for rpi? Is there something available which might help? | 14:59 |
| zyga | ysionneau: actually no | 14:59 |
| zyga | ysionneau: I have a biiig one after this, just need a moment to finish some last bits | 14:59 |
| ogra_ | pmp, not really ... we are working on a porting guide soon | 15:00 |
| ysionneau | awesome! | 15:00 |
| ysionneau | something that snappy really lack right now is documentation, and it's really cool to see that it is coming up those days :) | 15:00 |
| ogra_ | (the prob is that it will be completely re-defined what a gadget snap is ... so we have to wait til that definition stands) | 15:00 |
| zyga | ogra_: I suspect we'll need to decide on gadget/assertions transition next week | 15:01 |
| ogra_ | yes | 15:01 |
| ogra_ | thats my expectation | 15:02 |
| ogra_ | (that we come out of the week and know how kernel and gadget will look like) | 15:02 |
| pmp | l | 15:07 |
| pmp | is there a possibility to create an interface on my system, which actually provides more syscalls or other protected things via a snap? | 15:10 |
| zyga | pmp: yes but you will have to contribute that interface to snappy to actually be able to distribute your snap in any way | 15:10 |
| zyga | pmp: you cannot do that with a 3rd party snap | 15:11 |
| zyga | pmp: all interfaces are defined in snappy source code | 15:11 |
| zyga | pmp: and this is the basis of security of the whole architecture (along with reviews in the store when restricted interfaces are used) | 15:11 |
| pmp | zyga: how will this work with a branded store? Where we will most likely need customized interfaces. | 15:15 |
| zyga | pmp: that's an excellent question for the sprint | 15:16 |
| zyga | pmp: wrote it down now | 15:16 |
| pmp | zyga: thank you | 15:17 |
| zyga | pmp: I think it would be good to know some extra details, can you share more with me in private? | 15:17 |
| === shadeslayer_ is now known as shadeslayer | ||
| pmp | zyga: no problem, via mail it will be easier | 15:19 |
| zyga | pmp: do you know how to contact me? | 15:19 |
| pmp | zyga: I have your address | 15:19 |
| zyga | jdstrand: add https://bugs.launchpad.net/snappy/+bug/1577471 to your TODO (To read) list please | 15:37 |
| ubottu | Launchpad bug 1577471 in Snappy "Snap applications cannot access the user's normal XDG directories" [Undecided,Confirmed] | 15:37 |
| jdstrand | zyga: yes, though we discussed that before-- niemeyer asserted that snaps should access ~/snap/name/version and not all those. that said, I'll read and comment in the bug a bit later | 15:39 |
| jdstrand | zyga: so it is that, pr 1117 and 1118 that you need? | 15:40 |
| zyga | jdstrand: yes though the purpose of the home interface is to let them access other files | 15:40 |
| zyga | jdstrand: anyway, thanks :) | 15:40 |
| jdstrand | other non-hidden files | 15:40 |
| jdstrand | but sure, we can discuss in the bug | 15:40 |
| jdstrand | I mean we can do whatever, I just want to make sure we are doing what we agreed to | 15:40 |
| zyga | jdstrand: I reviewed the seccomp argument filtering branch btw | 15:41 |
| zyga | jdstrand: I was wondering if we should do that in u-c-l, it feels like apparmor_parser like problem where we don't have to parse text in a setuid executable | 15:41 |
| roadmr | hey folks, what's a good place to document my snap? i.e. people install it, then how do they learn more about how it works? is there a discoverable place for a README or something? | 15:43 |
| jdstrand | zyga: it has to parse it, it sets up the seccomp sandbox | 15:44 |
| zyga | roadmr: not at the moment, is that a desktop snap, a cli snap, a service? | 15:44 |
| zyga | jdstrand: no, it has to setup the sandbox, doesn't mean that has to parse text :) | 15:44 |
| roadmr | zyga: it installs a ssh server listening on port 8022 (see, I'd like to at least document the port) | 15:45 |
| zyga | jdstrand: we could parse it into a binary format that is far easier to load | 15:45 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | zyga: how else is it going to setup the seccomp sandbox? | 15:45 |
| zyga | roadmr: we don't have anything that would support that today | 15:45 |
| zyga | jdstrand: the same way, just read the description from the binary file | 15:45 |
| roadmr | zyga: so I'd say it's a service. I can always put a "ssh to port 8022 and poke around" in the description :) | 15:45 |
| jdstrand | zyga: then we are parsing binary in a setuid executable | 15:45 |
| roadmr | zyga: ok, gotcha... I'll find a workaround :) thanks! | 15:45 |
| zyga | jdstrand: yes, that's far easier to validate | 15:45 |
| zyga | jdstrand: load a header, load a bunch of structures, look at the data for sanity checking | 15:46 |
| jdstrand | zyga: the kernel doesn't have an interface like apparmor for loading a binary blob | 15:46 |
| zyga | jdstrand: yes but that can all be local to u-c-l | 15:46 |
| zyga | jdstrand: the binary interface | 15:46 |
| jdstrand | ehh | 15:46 |
| jdstrand | I think there are bigger fish to fry | 15:46 |
| zyga | jdstrand: e,g, we could even exec the parser and read from it, after dropping root | 15:46 |
| zyga | jdstrand: sure, I just wanted to point that out | 15:46 |
| * jdstrand notes that the parsing is happening after dropping root | 15:47 | |
| zyga | jdstrand: it feels like something that will grow and get more complicated | 15:47 |
| zyga | oh | 15:47 |
| zyga | I didn't notice that! sorry for that then | 15:47 |
| jdstrand | granted, it isn't permanently dropped due to nnp (which is unfortunate, but the state of things atm | 15:47 |
| jdstrand | ) | 15:47 |
| zyga | nnp? | 15:47 |
| jdstrand | NO_NEW_PRIVS | 15:47 |
| jdstrand | there is a comment in the code if you want to know more about it | 15:48 |
| zyga | I see | 15:48 |
| zyga | thanks | 15:48 |
| jdstrand | but, seccomp is quite limited-- there isn't terribly much more we can do | 15:48 |
| roadmr | can I build my snap for e.g. arm or arm64 on an x86_64 host? | 15:48 |
| zyga | jdstrand: is the reason we're adding seccomp argument filtering because how apparmor and seccomp differ as to when they are inspected? | 15:49 |
| zyga | roadmr: use launchpad | 15:49 |
| zyga | roadmr: otherwise probably not | 15:49 |
| roadmr | zyga: oh yay! I'll look into it. Not a big deal, really, it's a toy snap | 15:49 |
| jdstrand | zyga: we are adding it for things like setpriority | 15:49 |
| zyga | apparmor cannot inspect the arguments but seccomp can, right/ | 15:50 |
| jdstrand | zyga: with setpriority there are values that are ok (eg, >0) but other values that are not | 15:50 |
| roadmr | zyga: thanks for your help, I know you're busy, much appreciated :) | 15:50 |
| * roadmr goes for nooms | 15:50 | |
| jdstrand | zyga: apparmor doesn't do syscall filtering or inspection at this time | 15:50 |
| jdstrand | apparmor uses the LSM | 15:51 |
| zyga | jdstrand: right, thanks for hand holding me with all my questions :-) | 15:51 |
| jdstrand | and the LSM hooks, which don't support syscall filtering (that is what seccomp is for). apparmor may, one day, allow setting a seccomp filter as part of its policy syntax (and therefore all the seccomp stuff could be removed from the launcher), but that is all future work (unprioritized) | 15:52 |
| gblanchard4 | How do I set the logging level when using the snapcraft commands? | 16:01 |
| sergiusens | elopio what's our status on adt for the "other" arches? | 16:11 |
| elopio | sergiusens: IS doesn't want to give us the access to the regions with other arches. We'll have to try again to use jenkaas, which is probably not ready for all the features we need. | 16:13 |
| elopio | my hope is that they'll give us access while jenkaas is ready for us. Waiting for reply... | 16:14 |
| sergiusens | elopio right, but all our tests error out in the archive's adt run, so wondering if there is an easy fix there | 16:15 |
| elopio | sergiusens: without access to the same machine adt is running, I can only guess at fixes. Which means we'll know if they worked only when you put the new version in proposed. | 16:16 |
| elopio | pitti: is there a way I can get the same armhf container autopkgtests are using? | 16:17 |
| sergiusens | elopio fair answer :-) | 16:17 |
| sergiusens | elopio as a follow up, that was about pivoting on arches, we should also add adt for yakkety if possible in our tests | 16:18 |
| elopio | sergiusens: that one is easy, I added it to my TODO. Do you want it run in every PR? | 16:19 |
| sergiusens | elopio yes please, we need to ensure we keep compatibility both ways (ensure APIs we choose work on both) | 16:19 |
| sergiusens | elopio if possible enable that ASAP :-) Already going down the third dput that fails on infra ;-) | 16:21 |
| elopio | sergiusens: on it... | 16:26 |
| pitti | elopio: sure, just use adt-build-{lxc,lxd}, those are exactly what production uses | 16:30 |
| pitti | oh, almost | 16:31 |
| pitti | we apply this --setup-command on every test: | 16:31 |
| pitti | ed -i "s/ports.ubuntu.com/ftpmaster.internal/; s/ubuntu-ports/ubuntu/" /etc/apt/sources.list `ls /etc/apt/sources.list.d/*.list 2>/dev/null || true`; ln -s /dev/null /etc/systemd/system/bluetooth.service | 16:31 |
| pitti | elopio: sorry, of course you don't need the apt source mangling to ftpmaster.internal, that only works in the DC | 16:31 |
| pitti | elopio: but you might want the ln -s /dev/null /etc/systemd/system/bluetooth.service, some tests fail otherwise | 16:32 |
| pitti | (apt-get install bluez fails in a container) | 16:32 |
| elopio | pitti: thanks, OD!I'll try soon. | 16:35 |
| elopio | ignore the OD, it's hard to type these days. | 16:35 |
| sergiusens | pitti do you know if python apt is broken in the archives? I am seeing lots of this in adt now http://paste.ubuntu.com/16204372/ | 16:39 |
| sergiusens | well maybe not python apt could be something else | 16:39 |
| pitti | sergiusens: eek; haven't seen this yet, but this actually looks like apt itself (libapt) | 16:40 |
| sergiusens | pitti so the path forward is I should wait for a tentative fix there and then click on "rerun"? | 16:41 |
| pitti | sergiusens: where did you see this? | 16:41 |
| sergiusens | pitti https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapcraft/20160503_064449@/log.gz | 16:41 |
| sergiusens | pitti we use python apt where what fails are seen (only on y) | 16:42 |
| pitti | sergiusens: oh, this isn't new -- http://autopkgtest.ubuntu.com/packages/s/snapcraft/yakkety/amd64/ history reaches back to all of yakkety indeed | 16:42 |
| sergiusens | pitti I haven't seen this on xenial though (which gets adt runs on every code drop) | 16:44 |
| sergiusens | in the process of adding yakkety now | 16:44 |
| pitti | right, xenial seems fine | 16:44 |
| sergiusens | but I have no idea what is going on given the archive is rather new I think infra problems but I may be totally off track | 16:45 |
| Paddy_NI | Is there a way of browsing the currently available snaps? | 16:47 |
| sergiusens | mvo can I ask you being the apt expert? | 16:48 |
| sergiusens | mvo maybe I can expand that to "software package" delivery expert ;-) | 16:48 |
| elopio | sergiusens: kyrofa: after Sergio's suggestion, this one is ready to go: https://github.com/ubuntu-core/snapcraft/pull/481 | 16:49 |
| sergiusens | elopio I am afraid of running any of this in yakkety now given the above breakage :-P | 16:50 |
| === kissiel-afk is now known as kissiel | ||
| sborovkov | Hello. Implementation question, may be someone did this before. So snap has access to /dev/shm/snap/snap-name/snap-revision. How do I make shm_open use that location? I see that that shm_open takes name that starts with `/` and it should be single `/` according to docs. | 16:55 |
| elopio | sergiusens: well, this now seems stable enough. I can work on the yakkety run and I'm almost confident this one won't suddenly break :) | 16:57 |
| elopio | so, feel free to leave it in the queue. | 16:58 |
| sergiusens | elopio just want to get the apt issue solve first | 16:58 |
| zyga | sborovkov: excellent question, let me look | 16:58 |
| zyga | sborovkov: ah, sorry shm_open is not the same as /dev/shm | 16:59 |
| sborovkov | zyga: is not it used for creating shared memory anyways | 16:59 |
| zyga | sborovkov: AFAIR the memory allocated with dev_shm is not visiable in the filesystem | 16:59 |
| sergiusens | zyga the man page seems to illustrate it otherwise | 17:00 |
| zyga | sborovkov: for /dev/shm/stuff, I'm not sure but AFAIR it is just a tmpfs so you can just open files there | 17:00 |
| * zyga reads | 17:00 | |
| sergiusens | shm_open(const char *name, ...) where name is of the form of a path | 17:00 |
| zyga | sergiusens: yes, but I'm not sure that is an actual file, I'm almost sure it's not, though I could be wrong | 17:01 |
| sergiusens | zyga maybe correct, but I guess if you use shm_open you avoid this apparmor problem | 17:01 |
| sborovkov | sergiusens: how do you avoid this problem? | 17:01 |
| zyga | sergiusens: right, this is a different system call | 17:01 |
| sergiusens | zyga I am just going by the chromium source I read earlier where they don't use shm_open and create a file in /dev/shm instead due to the fact the shm_open is sort of limited on OS X | 17:01 |
| zyga | sergiusens: though AFAIR shm_open is terrible and discouraged | 17:01 |
| zyga | sergiusens: as there'es no good value for name | 17:01 |
| sborovkov | argh, webkit's using it. Oh well. | 17:02 |
| sergiusens | sborovkov you should be able to just open("/run/shm/$SNAP/$REVISION") | 17:02 |
| zyga | sergiusens: right, because then the name is at least somewhat meaningful and you can control permissions to the file and what not, I'm not sure how it works on osx (/dev/shm) | 17:02 |
| sergiusens | sborovkov but yeah, you'd need to patch webkit; is it of the form "org.chromium.Chromium.XXX"? | 17:03 |
| sergiusens | that's my current blocker issue today fwiw | 17:03 |
| zyga | sborovkov: if it's easy to patch, do it | 17:03 |
| sborovkov | sergiusens: sorry, what do you mean about the form "..."? | 17:03 |
| zyga | sborovkov: we're definitely going to change what is allowed (to make it more liberal) though jdstrand knows the details | 17:03 |
| sergiusens | zyga it really isn't which is why I wanted my proposal to mount in a new namespace to fly :-) | 17:04 |
| zyga | sergiusens: I think that's a sensible idea | 17:04 |
| sergiusens | zyga jdstrand and about pulseaudio, if hardlinking is supported, I'd just hard link into that path created by the launcher ;-) | 17:04 |
| zyga | sergiusens: a fork bomb snap would still work so I would not worry much about how shm quotas should work now | 17:04 |
| zyga | sergiusens: I'm not familiar with pulseaudio issues | 17:05 |
| sergiusens | but if pulseaudio requires accessing shared memory, I'd say the architecture for pulseaudio is somewhat broken as well ;-) | 17:05 |
| zyga | sergiusens: why? | 17:05 |
| zyga | sergiusens: it use buffers to share between clients | 17:05 |
| sergiusens | zyga look at my email exchange with jamie ;-) | 17:05 |
| zyga | sergiusens: where is the excchange? | 17:05 |
| sergiusens | zyga yeah, but I could write to other locations and inject into other apps, right? | 17:06 |
| sergiusens | zyga mailing list of course, don't you read email anymore? ;-) | 17:06 |
| zyga | sergiusens: nah, I'm just not fully up to my inbox zero goal :) | 17:06 |
| sborovkov | zyga: sergiusens: so hm can you recommend what calls I should use to replace shm_open with. What's the recommended way (did not deal with lol level IPC for a long time) | 17:06 |
| zyga | sergiusens: I moved 500 emails out of the way today | 17:07 |
| zyga | sborovkov: one sec | 17:07 |
| sergiusens | sborovkov I cannot recommend anything, I am blocked ;-) | 17:07 |
| zyga | so I just checked | 17:10 |
| sborovkov | zyga: Hmm. From stackoverflow: It just happens that GLIBC places all shared memory objects in /dev/shm or /var/run/shm by prepending the path to the object name and calling open() on the resulting name. That won't create subdirectories though I guess. | 17:17 |
| zyga | yeah | 17:17 |
| zyga | I just made a demo snap | 17:17 |
| zyga | one sec let me publish this | 17:17 |
| zyga | I may have a nice solution | 17:20 |
| zyga | for all apps | 17:20 |
| zyga | give me 10 more minutes, ok | 17:20 |
| zyga | s/nice/hackybutworking/ | 17:21 |
| sborovkov | zyga: sure, thanks for assistance :-) | 17:24 |
| jdstrand | sergiusens, zyga and sborovkov: the detail zyga is referring to for making it more liberal is to drop SNAP_REVISION and just use /run/shm/$SNAP/... | 17:29 |
| jdstrand | as for dealing with chromium-- still thinking that through | 17:29 |
| jdstrand | sergiusens: note, your proposal is not to mount in a new namespace. it is to bind mount (there is a big technological difference) | 17:30 |
| sergiusens | jdstrand you are most likely right :-) | 17:31 |
| sborovkov | zyga: alright, I gotta go now, I will ask you tomorrow about your solution then | 17:41 |
| zyga | almost done :) | 17:43 |
| zyga | ha | 17:45 |
| zyga | works | 17:45 |
| zyga | now for the grand finale | 17:45 |
| zyga | let it work with any precompiled app :) | 17:45 |
| * zyga loves C | 17:45 | |
| Chipaca | hiya | 17:59 |
| === charles_ is now known as charles | ||
| zyga | jdstrand: quick question | 18:11 |
| jdstrand | shoot | 18:11 |
| zyga | jdstrand: I made shm_open work magically | 18:12 |
| zyga | jdstrand: as a LD_PRELOAD or link-time .o | 18:12 |
| zyga | jdstrand: but it seems that apps cannot actually create /dev/shm/$SNAP_NAME/$SNAP_REVISION today :) | 18:12 |
| zyga | jdstrand: it feels like the launcher should do that | 18:12 |
| jdstrand | no | 18:12 |
| zyga | jdstrand: do you agree? | 18:12 |
| jdstrand | let me double check | 18:12 |
| zyga | thank you | 18:12 |
| zyga | sergiusens: ^^ if this is fixed I can give you a part that fixes anything | 18:13 |
| zyga | sergiusens: using shm_open | 18:13 |
| jdstrand | but I think that is right (like with ~/snap/name/version, it was the launcher's job to do that | 18:13 |
| jdstrand | but, we can fix that | 18:13 |
| zyga | jdstrand: rigth, that's my feeling | 18:13 |
| sergiusens | zyga it doesn't use shm_open (chromium, I told you exactly the opposite) | 18:13 |
| zyga | sergiusens: oh, I'm sorry what does it use then? | 18:13 |
| sergiusens | zyga open | 18:13 |
| zyga | sergiusens: ah, directly?! | 18:13 |
| zyga | boo :) | 18:13 |
| zyga | well, better than nothing :) | 18:14 |
| zyga | I'll share my stuff after this session | 18:14 |
| jdstrand | zyga: so, I'm ok with having these rules: | 18:14 |
| jdstrand | /{dev,run}/shm/snap/@{SNAP_NAME}/ rw, | 18:15 |
| jdstrand | /{dev,run}/shm/snap/@{SNAP_NAME}/** mrwlkix, | 18:15 |
| jdstrand | zyga: but something will still need to create /{dev,run}/shm/snap | 18:15 |
| jdstrand | we could do: | 18:16 |
| jdstrand | /{dev,run}/shm/snap/@{SNAP_NAME}/ r, | 18:16 |
| jdstrand | and have the launcher create /{dev,run}/shm/snap/@{SNAP_NAME} | 18:16 |
| zyga | jdstrand: /dev/shm/snap/$SNAP_NAME or /dev/shm/$SNAP_NAME | 18:16 |
| zyga | +1 | 18:16 |
| zyga | jdstrand: I'll work on this | 18:16 |
| jdstrand | zyga: ok | 18:16 |
| zyga | jdstrand: how soon can we release a launcher that does /snapname/snaprevision | 18:16 |
| zyga | jdstrand: this would work with new snaps (using my trick) without a release of snappy proper | 18:17 |
| sergiusens | zyga jdstrand https://chromium.googlesource.com/chromium/src.git/+/master/base/files/file_util_posix.cc#157 and https://chromium.googlesource.com/chromium/src.git/+/master/base/files/file_util_posix.cc#144 | 18:17 |
| sergiusens | zyga so mkstemp | 18:17 |
| zyga | sergiusens: glibc has a way to customize shm_open | 18:18 |
| zyga | sergiusens: so too bad it's not used here | 18:18 |
| zyga | sergiusens: this will have to be patched :/ | 18:18 |
| zyga | anyway, one problem at a time | 18:18 |
| zyga | sergiusens: thanks for sharing this | 18:18 |
| sergiusens | zyga it is not that simple though | 18:19 |
| jdstrand | zyga: if we are going to sru that, I'd like to have the seccomp arg filtering as part of that sru to cut down on sru red-tape | 18:19 |
| sergiusens | zyga as this code base is spread out in many projects and many projects use their own variant build/fork | 18:19 |
| zyga | jdstrand: we should get the blank-ish check though | 18:19 |
| zyga | as more and more things will be released | 18:19 |
| zyga | jdstrand: but for now I agree | 18:19 |
| jdstrand | tyhicks: do you have a feeling for when the seccomp arg filtering will be reviewed? | 18:19 |
| jdstrand | zyga: yes (and I requested that for the launcher) | 18:20 |
| jdstrand | well, I asked that someone else ask for it | 18:20 |
| jdstrand | I think that happened | 18:20 |
| tyhicks | jdstrand: hopefully by the end of this week | 18:21 |
| tyhicks | jdstrand: is that soon enough? | 18:22 |
| jdstrand | tyhicks: cool, thanks | 18:22 |
| zyga | jdstrand: maj 03 20:34:13 zyga-thinkpad-w510 kernel: audit: type=1400 audit(1462300453.710:78): apparmor="DENIED" operation="mknod" profile="snap.shm-open-demo.demo-builtin" name="/dev/shm/shm-open-demo/100001/demo" pid=8044 comm="demo-builtin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 | 18:34 |
| zyga | jdstrand: should this be denied today? | 18:34 |
| zyga | ah, I see /dev/shm/snap/ | 18:38 |
| zyga | sorry for bugging you :) | 18:38 |
| zyga | https://github.com/zyga/snappy-runtime-helper/blob/master/snappy.c | 18:42 |
| zyga | jdstrand: ^ I'll hack u-c-l and snappy to do what you suggested earlier | 18:42 |
| jdstrand | zyga: /dev/shm/shm-open-demo/100001/demo should be denied today. I forgot /dev/shm/*snap*/ | 18:47 |
| zyga | yep, I noticed that :) | 18:47 |
| jdstrand | ah, yes you did :) | 18:47 |
| zyga | jdstrand: I patched it to have /snap/ there too | 18:47 |
| zyga | jdstrand: one thing I realized is that the launcher doesn't know $SNAP_NAME or $SNAP_REVISION today | 18:48 |
| zyga | jdstrand: (it might just use getenv but feels wrong, I'd really just want to know $SNAP_NAME and act on that | 18:48 |
| zyga | jdstrand: (to mkdir bits) | 18:48 |
| zyga | jdstrand: ah, it seems it does use environment variables, so I guess that's not an issue | 18:49 |
| zyga | though that feels wrong :) | 18:49 |
| sergiusens | zyga create a part, put it on the wiki | 18:50 |
| zyga | sergiusens: good idea | 18:50 |
| qengho | Computer: "cannot get discharge macaroon from store" Me: "Oh, right. Of course" | 19:26 |
| * zyga still doesn't know what discarge there means | 19:27 | |
| qengho | My new band name is DISCHARGE MACAROÖN. | 19:28 |
| mvo | qengho: could you please check if there was maybe a typo in the username/password? | 19:31 |
| mvo | qengho: and yeah, the error message needs some love | 19:31 |
| ogra_ | Just rename it to 'boom!'... Has about the same amount of info, but is funnier | 19:33 |
| === gene_ is now known as gblanchard4_ | ||
| gblanchard4_ | Can you expose multiple commands in the snapcraft.yaml? | 19:59 |
| sergiusens | yes gblanchard4_ | 20:00 |
| qengho | Sure. New sections. | 20:00 |
| sergiusens | it is a a dict | 20:00 |
| qengho | I was making a snap in one place. I disconnected. Resumed at home. Now, running the snap says "Bad system call | 20:02 |
| qengho | ". I can't think of any other change than the network in use. | 20:02 |
| qengho | I know that sounds crazy. | 20:02 |
| qengho | That is, I moved my laptop from one place to another. Same machine. The "wget" run in my snap package fails now with "Bad system call". | 20:04 |
| qengho | I haven't updated snap deb in the last week or so. | 20:05 |
| qengho | Could it be some problem with the seccomp filter not being fully un-installed or something, between "snap remove/install" runs? | 20:06 |
| zyga | qengho: probably one of the bugs in 2.0.2 | 20:07 |
| zyga | qengho: I hope we release 2.0.3 soon (today?) | 20:07 |
| zyga | qengho: also there's a known bug in 2.0.2 when you install a snap a few times (during development) | 20:08 |
| qengho | zyga: I think I've been careful to remove first. I think that avoids it. | 20:09 |
| gblanchard4 | qengho: Thanks, I will give it a try! | 20:10 |
| zyga | yes | 20:10 |
| qengho | Next question: Can I find out what syscall failed? | 20:24 |
| Kamilion | qengho: sysdig can probably drill down to answer that for you. | 20:26 |
| sergiusens | qengho dmesg | grep <snap> | 20:26 |
| sergiusens | qengho scmp_sys_resolver against sig | 20:26 |
| Kamilion | you'd need dkms and root access to the machine for sysdig; however. csysdig is the curses frontend, switch to the system call view. | 20:26 |
| qengho | sergiusens: I only see apparmor lines, no seccomp. | 20:27 |
| Kamilion | then drill down to failed system calls and look which processes are unhappy | 20:27 |
| sergiusens | qengho are you maybe looking at old logs then? | 20:27 |
| qengho | fresh out of "dmesg" | 20:27 |
| sergiusens | or you may have been hit by kernel rate limiting | 20:27 |
| qengho | Eh, no. | 20:28 |
| sergiusens | qengho ph plain "Bad system call", maybe binary from a different arch? | 20:28 |
| sergiusens | s/from/for/ | 20:28 |
| jdstrand | sergiusens, qengho: note bug #1567597. if you are using --devmode there is no logging of seccomp violations | 20:28 |
| ubottu | bug 1567597 in Snappy "implement 'complain mode' in seccomp for developer mode with snaps" [Medium,Confirmed] https://launchpad.net/bugs/1567597 | 20:28 |
| qengho | sergiusens: I built it here, no special flags or compiler. | 20:29 |
| qengho | jdstrand: Not using devmode. | 20:29 |
| jdstrand | ok | 20:29 |
| zyga | hmm | 20:29 |
| zyga | jdstrand: is there a way to get a core file from a crashing app? | 20:30 |
| zyga | using pulse in snappy (even with --devmode) crashes all the stuff I try | 20:30 |
| qengho | I think I can make it go somewhere with proc core pattern. | 20:30 |
| sergiusens | zyga ulimit -c unlimited | 20:30 |
| zyga | (pulseaudio) | 20:30 |
| zyga | thanks! | 20:30 |
| zyga | I got a game working | 20:30 |
| qengho | Oh. | 20:30 |
| zyga | though without sound for now :) | 20:30 |
| zyga | got it :-) | 20:31 |
| qengho | I swear, this started its "Bad system call" when I moved locations. | 20:31 |
| qengho | I'm renaming package to see what happens. | 20:32 |
| zyga | hmm | 20:33 |
| zyga | #0 __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:60 | 20:33 |
| zyga | #1 0x00007fc06ed8d4ce in __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:1987 | 20:33 |
| qengho | zyga: Athlon? | 20:33 |
| zyga | no :) | 20:33 |
| zyga | core i7 | 20:33 |
| zyga | same binary works outside | 20:34 |
| zyga | (this is scummvm) | 20:34 |
| Kamilion | ah, I was wondering. Interesting. | 20:34 |
| zyga | I suspect a null pointer somewhere | 20:34 |
| jdstrand | zyga: I don't know. I do know mvo had gdb, etc working in snaps at one point | 20:34 |
| zyga | I'll build scummvm from source with debug | 20:34 |
| zyga | jdstrand: hmm, you just gave me an idea :) | 20:35 |
| zyga | actually | 20:35 |
| zyga | my idea is to go to sleep for a change | 20:35 |
| yofel | so, I started looking at https://developer.ubuntu.com/en/snappy/build-apps/get-started/, but apt tells me "E: Unable to locate package snappy-tools" - what am I looking for instead? | 20:36 |
| josharenson | Is there an https server available as a snap? | 20:36 |
| jdstrand | zyga: I like that idea :) | 20:39 |
| zyga | (and here I am, replying to email) | 20:39 |
| almejo_ | Hi every one. I need help packaging an app. My app is packaged and installed. But the app does not start. It onlly throws "XmbTextListToTextProperty result code -2" in the console. Is a python qml app. | 20:39 |
| nealmcb | I want to put snappy ubuntu core on my raspberry pi 2. but at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ I see instructions for 15.04. Should I ignore that and use e.g. http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz ? | 20:39 |
| almejo_ | I forgot to tell exactly the problem. The app does not appears. I have no gui :( | 20:44 |
| qengho | nealmcb: I don't think there are any good rpi images right now. | 20:45 |
| nealmcb | qengho: i.e. 15.04 is the latest good one? Or even it isn't good? | 20:46 |
| nealmcb | and what is the story for the raspberry pi 3? | 20:47 |
| qengho | nealmcb: 16.04 could be good, theoretically, but I don't think any current image is. Just a fluke today. | 20:47 |
| nealmcb | what sort of fluke today? | 20:48 |
| === blr_ is now known as blr | ||
| josharenson | nealmcb: I installed snappy (as opposed to 16.04 server) on my pi2 last night just fine | 20:49 |
| josharenson | nealmcb: ah qengho makes an interesting point | 20:49 |
| nealmcb | josharenson: which image? The one I pointed to? | 20:49 |
| Kamilion | nealmcb: I think flexiondotorg was working on various pi images, but I don't think there's any ubuntu-core images that I'm aware of for xenial at the moment. | 20:50 |
| jdstrand | kgunn: I read your bug report for slot connect. are you at least able to manually connect the permanent slot side? | 20:50 |
| josharenson | nealmcb: No its a 15.04 image | 20:50 |
| Kamilion | I know snapd has one available | 20:50 |
| josharenson | nealmcb: ubuntu-15.04-snappy-armhf-raspi2.img.xz | 20:50 |
| jdstrand | kgunn: or is it basically not being added until a connection with a client? | 20:50 |
| Kamilion | (for xenial) | 20:50 |
| zyga | Kamilion: xenial core images are not finished yet | 20:51 |
| zyga | Kamilion: I think we will offer developer preview images soon but I think this will only take shape next week | 20:52 |
| ogra_ | There are experimental ones for all arches but you will have to wipe them soon | 20:52 |
| Kamilion | so then what's ubuntu-core 16.04+20160419.20-55 ? | 20:52 |
| Kamilion | ah, okay | 20:52 |
| zyga | Kamilion: where did you get it from? | 20:52 |
| Kamilion | thanks, ogra_ | 20:52 |
| ogra_ | so it isn't rally worth releasing them until they are upgradeabl | 20:53 |
| ogra_ | e | 20:53 |
| Kamilion | zyga: snapd? | 20:53 |
| zyga | Kamilion: that's the core snap | 20:53 |
| zyga | Kamilion: that's not the whole image, the whole image has a kernel and a gadget | 20:53 |
| Kamilion | ah | 20:53 |
| zyga | Kamilion: we're still working on those parts | 20:53 |
| Kamilion | gotcha | 20:53 |
| zyga | Kamilion: on 16.04 you are using the kernel from the classic ubuntu | 20:53 |
| Kamilion | yes, I am | 20:53 |
| ogra_ | http://people.canonical.com/~mvo/all-snaps/ | 20:54 |
| zyga | Kamilion: on a board like the raspberry pi 2 you would need a complete snap-based image and those will be available in a few weeks from now | 20:54 |
| Kamilion | and only the pi2 and 3's CPU will be supported, ARM7 yadda yadda | 20:54 |
| zyga | right now we only have previews that may need to be re-flashed entirely sometimes | 20:54 |
| ogra_ | there are the experimental ones... But you will have to re-flash... | 20:54 |
| Kamilion | no pi1, that's for rasbian to deal with, basically. (as far as I can tell) | 20:55 |
| ogra_ | pi3 will get a community supported image, like the bbb | 20:55 |
| Kamilion | are the images going to be available before the first point release of xenial in juneish? | 20:55 |
| ogra_ | pi2 will be officially supporte | 20:56 |
| Kamilion | oh, I've got a BBB, I should give that a shot. | 20:56 |
| zyga | Kamilion: juneish? | 20:56 |
| ogra_ | around 16.04.1 | 20:56 |
| zyga | Kamilion: anyway, I think we will have images "in a few weeks" | 20:56 |
| ogra_ | I guess | 20:56 |
| zyga | so weeks, not months | 20:56 |
| zyga | 16.04.1 is released after 16.10 | 20:56 |
| ogra_ | well, 8weeks are two months :) | 20:56 |
| Kamilion | last I heard from #ubuntu-release during the 20th to 25th when I was paying attention, the first point release was supposed to be june | 20:56 |
| zyga | ogra_: hush ;) | 20:56 |
| ogra_ | zyga huh? | 20:56 |
| zyga | ogra_: still I hope this will be less than two months :) | 20:57 |
| zyga | ogra_: just kidding, sorry | 20:57 |
| ogra_ | .1 will definitelyvrelease before 16.10 | 20:57 |
| qengho | July, I think. | 20:57 |
| ogra_ | unless the release schedule got totally changed | 20:57 |
| zyga | Kamilion: perhaps I remember incorrectly but 14.04.1 was done after 14.10 | 20:57 |
| ogra_ | yeah | 20:57 |
| zyga | anyway, sorry, I may be wrong here | 20:57 |
| ogra_ | should be in july | 20:57 |
| ogra_ | and I guess stablebsnapoy will be broad the same time | 20:58 |
| Kamilion | zyga: yes, that was the case, 14.xx's point releases were far between | 20:58 |
| zyga | (and it containled LTS enablement packages) | 20:58 |
| ogra_ | stable snappy | 20:58 |
| Kamilion | I think 16.04 is getting more rapid updates | 20:58 |
| zyga | ah, I wasn't aware of that | 20:58 |
| zyga | thanks! | 20:58 |
| Kamilion | or at least an early point release to deal with some post-release problems | 20:58 |
| ogra_ | .1 is always early | 20:58 |
| Kamilion | like the llvm-3.8 issues | 20:58 |
| ogra_ | usually hew comez with .2 | 20:58 |
| ogra_ | hwe | 20:58 |
| ogra_ | god !!!! | 20:58 |
| ogra_ | the auto correction is killing me | 20:59 |
| nealmcb | 20:59 | |
| Kamilion | wow, fun, ZNC with a bunch of clients, just like me. heh. | 20:59 |
| nealmcb | Great - thanks folks! | 20:59 |
| kgunn | jdstrand: well, i just cleaned up my client project...and was working on pushing aroud the i/f to be "connected" slot vs permanent | 21:00 |
| zyga | kgunn: how do you setup your VM, perhaps I can reproduce your setup and aid you somehow? | 21:01 |
| kgunn | zyga: https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ | 21:01 |
| edsiper | ogra_, what's the procedure to flash de Dragonboard ? | 21:01 |
| kgunn | thanks for attempting, and let me know if you have questions | 21:02 |
| zyga | kgunn: huh, that's nothing special? | 21:02 |
| zyga | kgunn: does qemu work? | 21:03 |
| zyga | kgunn: I should be able to run this with regular devtools setup with a simple tweak | 21:03 |
| kgunn | yeah, i hadn't tried with any other vm's...so it might be fine | 21:03 |
| ogra_ | edsiper: just uncompress and dd to an sd card ... flick the SD switch on the bottom of the board and you should be good to go | 21:03 |
| zyga | kgunn: which vm software are you using there libvirt uses kvm inside? | 21:04 |
| zyga | kgunn: anyway, I'll check that tomorrow, I suspect this can be x10 easier and faster with devtools-based setup and ephemeral VMs it is using | 21:05 |
| kgunn | zyga: info says hypervisor:kvm emulator:/usr/bin/kvm-spice | 21:05 |
| zyga | that's great then | 21:05 |
| edsiper | ogra_, is this one functional ? http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz | 21:05 |
| zyga | will work just as well with qemu :-) | 21:05 |
| edsiper | great | 21:05 |
| zyga | kgunn: I'll ping you tomorrow, for now I have to look after my kids | 21:05 |
| ogra_ | should be, yes ... you will need to create a wlan0 file etc | 21:06 |
| kgunn | o/ enjoy zyga | 21:06 |
| ogra_ | (to get ssh access) | 21:06 |
| qengho | before: https://pastebin.canonical.com/155727/ after: https://pastebin.canonical.com/155726/ | 21:21 |
| === tsimonq2alt is now known as tsimonq2 | ||
| * zyga has a real backtrace | 22:08 | |
| zyga | https://paste.gnome.org/pp7ej1hyn | 22:08 |
| zyga | sergiusens: do you have any hints on stage-packages and -dbg packages for symbols | 22:11 |
| zyga | sergiusens: should I build libsdl myself and just overwrite the bits in snap/ manually for hacking (like I did with scummvm executable) | 22:11 |
| zyga | sergiusens: or is the a better magic way to get non-stripped libraries | 22:11 |
| gblanchard4 | Are underscores and periods not allowed in the YAML? i.e. in the apps section | 22:13 |
| zyga | gblanchard4: they are not allowed | 22:16 |
| zyga | gblanchard4: juse use dashes, most apps don't use dots and we use them internally so they are reserved | 22:17 |
| gblanchard4 | zyga: Okay, thanks for the information. I was trying to figure out why my yaml failed validation. | 22:20 |
| zyga | gblanchard4: snapcraft should also check that, I think | 22:21 |
| gblanchard4 | zyga: I am trying to port some python based bioinformatics software to alleviate dependency hell. I was trying to make it as seamless as possible. Most of the scripts use the underscore convention i.e. print_config.py | 22:22 |
| zyga | gblanchard4: remember how snap apps are exposed | 22:22 |
| zyga | gblanchard4: in general each app is named: $snap.$app (e.g. biosoftware.something) | 22:23 |
| zyga | gblanchard4: when you have many scripts you can improve their names based on this knowledge | 22:23 |
| zyga | gblanchard4: you can run print_config.py from a command called print-config | 22:23 |
| zyga | gblanchard4: the command name is not the same as the file / command it runs | 22:24 |
| gblanchard4 | zyga: Thats a great point! | 22:24 |
| zyga | gblanchard4: also note that if the app name is the same as snap name we don't do foo.foo, the resulting executable is just "foo" | 22:25 |
| zyga | gblanchard4: so if there's any "main" program in your snap that would be the way to expose it | 22:25 |
| gblanchard4 | zyga: Ha, I learned that the hard way by accident. It's really a collection of python scripts, no "main". | 22:27 |
| zyga | gblanchard4: are they CLI tools? | 22:27 |
| gblanchard4 | zyga: yes | 22:27 |
| gblanchard4 | zyga: I use a lot of python based CLI tools. The are currently all in separate virtualenvs, but many rely on more than just python (usually some R packages too). I think snaps are a great idea to help me keep everything separate. | 22:31 |
| zyga | https://paste.gnome.org/piq8y6ony | 22:53 |
| zyga | definitely pulseaudio related | 22:53 |
| zyga | the crash is in #2 0x00007f0a75f17fe6 in PULSE_SetCaption (this=0x22b3460, str=0x0) at ./src/audio/pulse/SDL_pulseaudio.c:394 | 22:53 |
| qengho | Oh man, no "source:" for merely downloading a file? Ugh. | 22:55 |
| zyga | the root cause is null pointer coming from SDL_WM_GetCaption(&title, NULL); | 22:55 |
| zyga | which smells X related | 22:55 |
| zyga | ha | 22:57 |
| zyga | found the root cause :) | 22:57 |
| zyga | heh /proc related (obviously) | 22:57 |
| zyga | and also a bug in sdl1.2 | 23:06 |
| zyga | just last build before EOD | 23:06 |
| zyga | woot | 23:24 |
| zyga | I have a working snap for flight of the amazon queen | 23:24 |
| zyga | sergiusens: I fixed a bug in sdl that probably (99%) affects each SDL game | 23:24 |
| zyga | resulting in a crash | 23:24 |
| ZenHarbinger | I have a question about running a Java Swing application deployed via snap: https://askubuntu.com/questions/764496/developing-a-snap-package-for-a-project-using-java-swing | 23:29 |
| ZenHarbinger | namely, it doesn't run | 23:29 |
| zyga | ZenHarbinger: hey, I replied to your question | 23:29 |
| zyga | ZenHarbinger: can you pastebin snap interfaces please | 23:30 |
| ZenHarbinger | you mean the output? | 23:30 |
| ZenHarbinger | from snap interfaces? | 23:30 |
| qengho | Yes. | 23:31 |
| ZenHarbinger | I listed it at the link: | 23:31 |
| zyga | ah, I see now | 23:31 |
| zyga | can you look at syslog and pastebin the DENIED lines | 23:32 |
| zyga | I suspect this is getpeername or something like that I fixed this for 2.0.3 already | 23:32 |
| zyga | but let's see | 23:32 |
| qengho | "snap justlikeapportcollect | 23:32 |
| zyga | ZenHarbinger: just pastebin the whole syslog if you don't know what to look for | 23:35 |
| ZenHarbinger | http://pastebin.com/incCe8d0 | 23:35 |
| ZenHarbinger | sorry, had to run it | 23:36 |
| zyga | ZenHarbinger: https://bugs.launchpad.net/snappy/+bug/1574526 | 23:37 |
| ubottu | Launchpad bug 1574526 in Snappy "x11 plug doesn't allow getsockname, breaks xeyes" [High,Fix committed] | 23:37 |
| zyga | this is already fixed | 23:37 |
| ZenHarbinger | awesome, so just wait? ok. | 23:37 |
| qengho | (Note, not "Fix released") | 23:37 |
| zyga | mvo will release 2.0.3 | 23:37 |
| zyga | then you will need to reinstall (or disconnect and reconnect x11) the snap | 23:38 |
| zyga | and it should work | 23:38 |
| ZenHarbinger | Great! Thanks guys! | 23:38 |
| zyga | :-) | 23:40 |
| zyga | ZenHarbinger: (please update the question on ask ubuntu if you can) | 23:41 |
| zyga | sergiusens: https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/1577986 | 23:46 |
| ubottu | Launchpad bug 1577986 in libsdl1.2 (Ubuntu) "SDL 1.2 crashes on snappy, breaks scummvm" [Undecided,New] | 23:46 |
| qengho | zyga: Do we have a list of "tentpole" apps that we expect to be able to snap as a prerequisite for declaring v2 released? | 23:50 |
| zyga | qengho: v2 of what? | 23:50 |
| zyga | qengho: snapd 2.0.2 was released on the 21st or something close to that | 23:51 |
| qengho | Well, whatever we release as snappy. Not "2", but "come, all, snappy is ready for you". The number is not important. | 23:51 |
| zyga | qengho: ah, I see | 23:51 |
| zyga | qengho: sprint topic | 23:51 |
| qengho | Ah. | 23:51 |
| zyga | qengho: I don't have any lists yet though I actually proposed we run with one :) | 23:51 |
| qengho | Agreed. | 23:52 |
| zyga | qengho: for desktop apps and some unspefied use cases for devices | 23:52 |
| qengho | If you want one that's ambitious and not quite crazy, I will upload my "Kodi" snap branch. | 23:52 |
| qengho | zyga: Go offline already! :) | 23:53 |
| zyga | qengho: desktop will see ongoing progress, I'd say that the idea is we will release new interfaces (and updated interfaces) each fortnight to remove blockers from snapping some high-profle apps | 23:54 |
| zyga | qengho: but also remember that some desktop things are very hard because everything is closely coupled | 23:54 |
| qengho | Don't I know it. | 23:54 |
| zyga | qengho: so I don't know if we'll succeed quickly | 23:54 |
| zyga | (with kodi :) | 23:54 |
| zyga | anyway, afk :) | 23:54 |
| zyga | good night | 23:54 |
| qengho | Good night. | 23:54 |
| zyga | (I said that three times already) | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!