=== devil is now known as Guest61712 [00:25] 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:27] example6: You only need "snapcraft" unless you want the process to end prematurely at some stage. [00:29] example6: I bet "strace -e trace=file -f snapcraft" will show you what you're doing wrong. [00:31] example6: And/or, "snapcraft --debug" [00:35] --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 === Aria22 is now known as Aria22|away [01:00] 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? === Guest61712 is now known as devil_ [06:42] kgunn: re [07:50] hello! [07:50] I've snapped a cli-tool [07:50] how can I open the man pages of a snap? [07:58] svij: there's a bug open on this, currently man pages are not supported [07:58] svij: it's also non-obvious how it should behave [07:58] zyga: alright [07:59] svij: e.g. what should be the man page name? $snap.$app [07:59] svij: original? [07:59] svij: should non-command man pages be alloweD? [07:59] svij: etc, ideas welcome, we honestly don't know yet [07:59] zyga: that what I wondered too === 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 [09:35] hi [09:36] 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] (because right now it's not :o) [09:45] 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] stuff other than section 1/8 is indeed trickier [09:45] ysionneau: what interface is the plug? [09:45] cjwatson: hmm, how does that work? [09:46] cjwatson: $PATH/../man/ or something? [09:46] zyga: basically [09:46] cjwatson: interesting, thanks for this idea! [09:46] zyga: also $element/../share/man [09:50] ysionneau: can you please share your snapcraft.yaml [09:53] zyga: sure! thanks a bunch :) http://pastebin.com/ZK8nRftb [09:59] 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] I mean, the same webpage display release of click and snap, is this normal ? [10:06] ysionneau: looking [10:06] ysionneau: old security is gone [10:06] ysionneau: the plug is parsed and thein ignored [10:06] ysionneau: you cannot run unconfined with old securiry anymore [10:09] JamesTait: ^ slvn you might be able to answer [10:10] somehow, based on the naming, .snap package are added under on the same package of my .clik packages [10:10] is there a way to have snapcraft syntax check my .yamls? [10:10] It actually makes sense! don't know wheter this is wanted or not [10:12] 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] also, my click package are targetted to ubuntu phones (ARM), wherease the .snap are Amd64 [10:13] Sounds like a bug to me. [10:14] JamesTait, then my account is a little screwed-up now .. [10:15] JamesTait, do you have some kind of admin account to see what's going on ? [10:15] I confirm that on my dev page, I see under "Overview" both revision of click and snap [10:16] 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:17] JamesTait, it's based on the naming, my apps that have the same name are merged when published for the first time [10:18] slvn, can you point me to an example package? [10:19] 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] JamesTait, https://myapps.developer.ubuntu.com/dev/click-apps/773/ [10:19] a mahjong game [10:20] snap is not published, click is published months ago [10:20] both are merge .. [10:20] 'd === Aria|away is now known as Aria [10:21] slvn, looking into it for you. [10:23] thanks ... [10:24] slvn, OK, there's another user seeing the same thing, so it's not just a problem with your account. [10:25] JamesTait, ok ... [10:28] 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:32] JamesTait, here it is: https://bugs.launchpad.net/software-center-agent/+bug/1577717 [10:32] Launchpad bug 1577717 in Software Center Agent "Published snap package appears under the list of click packages" [Undecided,New] [10:33] Thanks, slvn, we're on it. [10:33] ok great ! === Aria is now known as Aria|away === Aria|away is now known as Aria === Aria is now known as Aria22 [11:03] jdstrand: https://github.com/ubuntu-core/snappy/pull/1117 [11:03] zyga: how do we run unconfined now? [11:04] --devmode [11:04] ysionneau: http://www.zygoon.pl/2016/04/snap-install-devmode.html [11:12] zyga : ah thanks! [11:26] zyga: ack but it will be a little while [11:26] * jdstrand -> long meeting [11:26] jdstrand: sure [11:28] Hi guys [11:28] I have a problem with an library that i want to use. [11:28] The library does only support Soft float on my raspberry pi 3 [11:29] Is there any possibility to change snappy from Hard float to Soft Float? [11:30] noizer: snappy doesn't care about binaries you run [11:30] noizer: does that library run without snappy? [11:32] 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:33] noizer: can you be more specific? [11:33] zyga: i'm not familiar with hard and soft floating [11:33] noizer: can you pastebin anything? [11:34] zyga: Do you know Nuance the tts egine. They support only there library on ARM processors with soft floating [11:34] noizer: nope [11:34] i doubt it will work [11:34] Good morning [11:34] you might be able to ship a complete armel chroot inside your snap ... perhaps ... [11:35] softfloat means that floating point is emulated, so it should work anywhere (slowly) [11:35] (but you would need to use a dristro that even provides armel ... armel is dead in ubuntu since 9.04 or so) [11:35] though if you want to link to it with a armhf gcc you won't have luck [11:35] zyga, you cant exec armel binaries on armhf systems [11:35] noizer: ask Nuance to rebuild [11:35] ogra_: are you sure? why not? [11:35] yes i'm sure [11:36] ogra_: curious, why is that? [11:36] you can multiarch ... [11:36] ah [11:36] but that means *all* libs [11:36] well, that's okay I was just curious [11:36] right that's exactly what I expected [11:36] it's just a different abi [11:36] and it means you cant use ubuntu [11:36] right, so you *can* execute but you need to bag all the bit you need [11:36] the cpu won't care [11:37] cpu and kernel wont care (if it is a hardfloat capable cpu) ... [11:37] right [11:37] but you need to ship a full chroot inside your snap [11:37] noizer: long story short I'd recommend really asking those folks for a build [11:38] (and all this is 100% theoretical ... i dont think anyone ever actually tesetd this) [11:38] yep [11:38] zyga: We asked for it but it will cost us 250 000 euro for a rebuild with all the features we want [11:38] noizer: for an armhf rebuild? [11:38] wow they are picky :) [11:38] zyga: yes [11:38] wow ... thats like ... a lot of money for 5min of work [11:38] noizer: unless they hand coded that with assembly that's typically "make" on an ubuntu install :/ [11:39] yeah [11:39] * zyga smeslls marketing BS (not noizer's in any way) [11:39] noizer: quick idea [11:39] zyga I don't know how they builded it but yeah it is very expensive to rebuild [11:40] noizer: get a raspberry pi 1 image, put it on your pi2's home directory [11:40] and chroot [11:40] if that works we can snap it [11:40] noizer: that's total BS they just want money :) [11:40] yeah, it is definitely just "rebuild with ubuntu toolchain" [11:40] i.e pull your source tree onto an ubuntu armhf and build it ... [11:40] ogra_: we even have nice cross toolchains packaged [11:41] so they don't even need a board [11:41] yeah [11:41] well [11:41] depends on the depends ;) [11:41] * zyga will start charging $0.25M for his python rebuilds now ;) [11:41] ogra_: yeah true [11:41] (you really wouldnt want to cross build a gui app that uses a lot of libs ... ) [11:41] wxgtk ;) [11:42] zyga how does it works then with the image of rpi 1 [11:42] noizer: pi1 is using an older cpu [11:43] noizer: e.g. a raspian image is compiled for armel [11:44] zyga ok then put it on my rpi3 and compile and install it on that image? [11:46] noizer: compile everything on your pi1 [11:46] noizer: make sure it works there [11:46] noizer: then grab the whole sd card and tarball it [11:46] noizer: then put that tarball on a pi3 [11:46] noizer: unpack it, you may need to tweak some things (bind mount /proc etc) [11:47] noizer: then chroot [11:47] noizer: check that it still works [11:47] noizer: if you get that far we should be able to snap it [11:47] * zyga looks forward to "enterprise" software [11:48] if the above doesnt work you should always be able to use a real container [11:48] lxc or docker ... [11:49] So what will docker do then? [11:49] noizer: don't worry about docker [11:49] noizer: try what I said [11:49] ps Is there not a way to make snappy Soft floating? [11:51] zyga Ok how will it works then with my other software because my software needs to connect with the libaray. [11:52] you would have to ship it as softfloat too ... likely in the snap snap [11:52] *same snap [11:53] (geez ... /me curses freud) [11:53] Damn thats very hard then :s [11:54] (in a year from now the above sentence will be "snap snap, snap snap snap, snap !" .... ) [11:54] noizer: why is that hard? [11:55] noizer: it's not pretty, essentially shiping a foreign distro in a snap [11:55] noizer: but since the CPU itself allows this it would not be much different from running raspbian natively [11:56] noizer: I guess it depends on what you want? prove that it's possible for a demo? use it "in production" [11:56] yeah, not m,uch different from running i386 chroots on amd64 [11:56] yeah [11:57] * zyga curses timezones [11:57] is UOS starting in two hours from now? [11:59] zyga, indeed [11:59] thanks kyrofa [12:00] zyga, plenary opening in two hours, sessions start in three [12:05] 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:06] ogra_, is that just a difference between ubuntu core and the desktop? [12:06] zyga Ok I will try it tomorrow because then I got my rpi1 with me [12:07] noizer: good luck [12:07] zyga If i have some troubles can you help me out then? [12:07] kyrofa, we ship no locales at all on the image ... [12:07] noizer: i'll be attending UOS but I can try [12:07] UOS? what does that mean? [12:07] noizer, ubuntu online summit [12:08] heh [12:08] noizer, http://summit.ubuntu.com/ [12:08] I just tried to install a snap [12:08] sudo snap -i ... [12:08] usually the place weher we do planning for the next release ... [12:08] old habits die hard [12:08] fix that 1 [12:08] ! [12:08] (by adding -i ;) ) [12:08] ogra_: maybe I'll implement -i as a hidden command [12:08] also printing "we feel your pain" ;-) [12:08] yeah :) [12:11] ogra_, that explains the C then, I suppose. Right? [12:11] right, we ship whatever libc includes by default ... which is C and C.UTF-8 [12:12] there is no additional locale handling in the rootfs ... you have to do that inside the snap itself if needed [12:13] 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] (we also dont ship keymaps or fonts that support UTF8 ) [12:13] I don't know why it's not working though, which is frustrating [12:13] kyrofa, yeah [12:13] Stupid boost and its cryptic errors [12:15] morning [12:15] Morning sergiusens :) [12:17] * zyga triaged https://bugs.launchpad.net/snappy/+bug/1577472 [12:17] Launchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete] [12:18] 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] ogra_: I'm asking because it seems to stop as soon as I run a snap [12:18] (not all snaps, but hello world seems to be affected) [12:18] hopefully all snaps :) [12:18] not all snaps :) [12:18] oh ? [12:19] ogra_: build this https://bugs.launchpad.net/snappy/+bug/1577472 [12:19] Launchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete] [12:19] ogra_: (snapcraft.yaml inline) [12:19] ogra_: that snap still works! [12:19] as in I get ł [12:19] we explicitly do not chip any locale support, keymaps or console fonts [12:19] (that would likely easily triple the size of the rootfs ) [12:19] ogra_: but how does it work, gnome-terminal is from the classic ubuntu side [12:19] ogra_: so it has the fonts [12:19] ogra_: I don't know how input handling works [12:20] but not the locale info [12:20] but I suspect it's also on the teminal side [12:20] locale, right I get how locale works [12:20] we only support C.UTF-8 [12:20] but it doesn't affect keyboard input [12:20] it affects the representation of the key code [12:21] hmm? how does that work? I suspect that the shell puts the tty into raw mode [12:21] but what happens next? [12:21] and how is that affected by snappy [12:21] (I'm trying to understand why it doesn't work in hello-world but works in the small example I made) [12:21] http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml [12:21] have a look at that [12:22] I see locales there [12:22] if you want your snap to have support for more than C.UTF-8, you have to ship this set of packages [12:22] I don't think that answers my question [12:22] I'm specifically asking about how input handling works [12:22] and why one snap behaves differently than another one [12:22] the snap I made has busybox-static [12:22] a keycode is sent ... it gets processed and a char is printed :P [12:23] hmmm [12:23] right [12:23] I see [12:23] processed, that's where locales go in [12:23] if your font doesnt have the char, it cant be printed (and you get little squares) [12:23] I guess that busybox just accepts and echoes everything that's not a special control character clearly [12:23] and bash is is doing it "properly" and hence I get nothing [12:23] (properly == through locale) [12:24] right [12:24] thanks! [12:24] that makes sense [12:24] I forgot about raw mode [12:24] console echo can be deceiving :) [12:24] if you ship locales and console-setup-linux you should be able to get around that [12:25] nah, I was just curious how it works [12:25] I don't really need it for anything now [12:25] I'd love if someone made locale that's tiny [12:25] lol [12:25] and is not shipping translation [12:25] translations* [12:25] tiny as in ~50Kb max [12:25] locale and tiny dont really fit into the same sentence [12:25] what's in locale anyway? [12:26] what's the big part? [12:26] (is it just glibc doing crazy correct huge thing or is it an intrinsict problem of locale data) [12:26] (i mean, the locale itself perhaps ... but you need all tghe surroundings like termcap/curses ... fonts etc etc ) [12:26] fonts = not really [12:26] (not on classic) [12:26] not in webapps [12:26] termcap = not in webapps [12:27] just ship the locales package [12:27] 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] I see a billion charmaps [12:28] perhaps 90% of them are useless today [12:28] or 100%-1 [12:28] man what a load of garbage :) [12:28] and the actual locale definitions should be easily under 50KB compiled [12:29] even the charmaps are tiny [12:29] (obsolete but small) [12:29] though locales get some processing [12:29] (which is also super slow) on install time [12:30] do you know what that does? [12:30] it creates the binaries [12:30] from the locale definitions [12:30] does that have to run at install time? [12:30] (simply calls locale-gen i think) [12:31] can we compile all locales on snap build time? [12:31] * zyga reading the script now [12:31] if you want to use the locales, they have to be up to date against whats on the system, yes [12:31] just shell, no perl :) [12:31] against what's on the system? what does that mean? [12:31] are they self contained or not? [12:32] if they were self contained you would have to generate them at install time ;) [12:32] so what do they need from the system on install time? [12:32] * zyga reads the script [12:32] have a look under /usr/share/locale [12:33] I see just .mo files [12:33] anything I'm missing [12:33] mo files are built at compile time [12:33] I don't suspect locale-gen needs gettext to run [12:33] and locales are built from the mo files [12:34] !? [12:34] but they contain keymaps [12:34] how is that related to translations [12:34] LC_MESSAGES is part of your locale [12:34] keymaps and charmaps [12:34] yes but the question is: why do we need to generate anything on install time [12:35] to be in sync with the binaries on the system [12:35] I don't understand, in sync with what [12:35] (better ask infinity for details) [12:35] buit afaik there is no way to ship "small" locales pre-created [12:35] if I update, say, the translation catalogue for something, do I need to rebuild locale data? [12:36] yes [12:36] do you know why? [12:36] out prob is really that we do not enforce C.UTF-8 ebverywhere yet [12:37] that's not a solution to apps wanting to have locale support really [12:37] you dont really want country specifric locales, but you want full UTF-8 support [12:37] which a LOCALE=C default doesnt give you [12:37] I'm trying to understand how locale works today [12:37] I know that [12:37] I disagree about country specific locale, it depends on an app [12:37] but half of snappy uses C ... the other half uses C.UTF-8 [12:38] hmm? do we set locale to C anywhere explicitly? [12:38] we're not consistent yet ... i.e. the launcher needs to enforce C.UTF-8 [12:38] I'm still puzzled by what you said earlier: [12:38] no [12:38] C is the fallback [12:38] zyga: we even have a bug about the ł issue: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576411 [12:38] Launchpad bug 1576411 in snapd (Ubuntu) "UTF-8 is not very well supported inside snaps" [High,Triaged] [12:38] zyga if I update, say, the translation catalogue for something, do I need to rebuild locale data? [12:38] if nothing is set [12:38] ogra_ yes [12:38] mvo, yeah, i just commented on that :) [12:38] right, I saw that bug [12:39] zyga, the issue is that we need to eliminate the places where C is still used [12:39] aha, nice [12:39] sorry,I looked at this yesterday haven't seen all the followups :) [12:39] ogra_: I still want to understand locale better [12:39] zyga, infinity is your man :) [12:39] thanks! [12:40] * zyga thinks this is a nice moment to take a lunch break === JanC is now known as Guest52941 === JanC_ is now known as JanC [12:59] kyrofa I have one for you https://bugs.launchpad.net/snapcraft/+bug/1577750 [12:59] Launchpad bug 1577750 in Snapcraft "Search for libraries for 16.10 cause a build failure" [Critical,In progress] [12:59] kyrofa better yet https://github.com/ubuntu-core/snapcraft/pull/496 [12:59] sergiusens, ah! [13:03] kyrofa yeah, ah describes it perfectly ;-) [13:12] 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:18] 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] thots? [13:20] kgunn: that's expected, the problem here is that auto-connect is only affecting the OS snap [13:21] dholbach: ping [13:21] kgunn: see http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html (the 2nd to last header) [13:21] 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:26] 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] kgunn: connect will connect anything compatible [13:26] kgunn: that's still a TBD, how we want this to work, it's related to assertions as well [13:27] 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:29] zyga: ok, i'll migrate to a connected slot today.... that should keep me busy :) [13:29] i need to clean up client yaml too [13:29] kgunn: cool, ask me anything if you are blocked [13:35] dholbach: do you want me to prepare anything about interfaces? [13:35] dholbach: or should I just join various sessions and answer questions/talk [13:40] kyrofa yes, but we need to implement the `release` tag in snapcraft.yaml to know what we are targetting ;-) [13:40] sergiusens, okay, same page then [13:40] sergiusens, so for now we're assuming the same release as host? [13:40] kyrofa yeah :-) I want to play ball as if yakkety did not exist yet though [13:41] kyrofa yup [13:41] kyrofa and cleanbuild always assumes xenial [13:41] sergiusens, +1 [13:42] kyrofa we are xenial centric for now; I don't think we want to start supporting building from yakkety just yet [13:42] sergiusens, I agree, seems like a safe assumption [13:43] sergiusens, problems occur when targeting a release older than host. libc symbols and whatnot [13:43] ogra_ you are missing on the "other" network. Are you off today? [13:43] sergiusens, brunching :) [13:44] ogra_ and you have a game to watch today I guess ;-) [13:44] jdstrand: https://github.com/ubuntu-core/snappy/pull/1118 (for later) [13:45] sergiusens, bayern atletico ? yeah, i watched the first one ... wasnt that exciting though [13:50] 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] sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/497 [13:50] great, that's a plan then [13:50] dholbach: Heya [13:50] hey niemeyer [13:50] dholbach: Can we move the two core sessions we have at 15UTC to 17UTC? [13:51] http://summit.ubuntu.com/uos-1605/2016-05-03/ is the schedule for today :)= [13:51] :-) [13:51] dholbach: I think the 17UTC slot is open on that track on both days [13:51] hohum [13:51] we announced the schedule already, so some might have planned their days according to this [13:51] 17 UTC today is the lunch slot [13:51] and the 15 UTC session today is about python3 [13:52] so led by somebody in the foundations team [13:53] zyga: read_paths / write_paths still exists ? [13:53] ysionneau: no it does not [13:53] ysionneau: that was a part of old-security [13:54] what is the modern way? [13:54] ysionneau: to come up with a new interface [13:54] ysionneau: what do you need access to? [13:54] niemeyer, ^ did you see my reply? [13:55] dholbach: Okay, sounds good, thanks [13:55] ok maybe let me copy paste all the warnings I get (in --devmode) zyga [13:55] niemeyer, cool [13:55] ysionneau: please do! [13:56] zyga: http://paste.ubuntu.com/16201687/ [13:56] ysionneau: ah, /dev/shm, we're looking into making that easier [13:56] ysionneau: currently you can access /dev/shm but just in weird locations [13:57] yeah I've seen the mailing list posts [14:00] kyrofa https://github.com/ubuntu-core/snapcraft/pull/498 [14:00] kyrofa about locale, I have ideas :-) [14:00] sergiusens, good deal. Should we hold off on that catkin PR, then? [14:01] * zyga tunes into UOS [14:02]