=== devil is now known as Guest61712
example6Well, 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
qenghoexample6: You only need "snapcraft" unless you want the process to end prematurely at some stage.00:27
qenghoexample6: I bet "strace -e trace=file -f snapcraft" will show you what you're doing wrong.00:29
qenghoexample6: 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 @qengho00:35
=== Aria22 is now known as Aria22|away
example6So 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_
zygakgunn: re06:42
svijI've snapped a cli-tool07:50
svijhow can I open the man pages of a snap?07:50
zygasvij: there's a bug open on this, currently man pages are not supported07:58
zygasvij: it's also non-obvious how it should behave07:58
svijzyga: alright07:58
zygasvij: e.g. what should be the man page name? $snap.$app07:59
zygasvij: original?07:59
zygasvij: should non-command man pages be alloweD?07:59
zygasvij: etc, ideas welcome, we honestly don't know yet07:59
svijzyga: that what I wondered too07: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
ysionneauif 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
cjwatsonzyga: 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 PATH09:45
cjwatsonstuff other than section 1/8 is indeed trickier09:45
zygaysionneau: what interface is the plug?09:45
zygacjwatson: hmm, how does that work?09:45
zygacjwatson: $PATH/../man/ or something?09:46
cjwatsonzyga: basically09:46
zygacjwatson: interesting, thanks for this idea!09:46
cjwatsonzyga: also $element/../share/man09:46
zygaysionneau: can you please share your snapcraft.yaml09:50
ysionneauzyga: sure! thanks a bunch :) http://pastebin.com/ZK8nRftb09:53
slvnHey ! 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
slvnI mean, the same webpage display release of click and snap, is this normal ?09:59
zygaysionneau: looking10:06
zygaysionneau: old security is gone10:06
zygaysionneau: the plug is parsed and thein ignored10:06
zygaysionneau: you cannot run unconfined with old securiry anymore10:06
davmor2JamesTait: ^ slvn you might be able to answer10:09
slvnsomehow, based on the naming, .snap package are added under on the same package of my .clik packages10:10
pmpis there a way to have snapcraft syntax check my .yamls?10:10
slvnIt actually makes sense! don't know wheter this is wanted or not10:10
JamesTaitI'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
slvnalso, my click package are targetted to ubuntu phones (ARM), wherease the .snap are Amd6410:12
JamesTaitSounds like a bug to me.10:13
slvnJamesTait, then my account is a little screwed-up now ..10:14
slvnJamesTait, do you have some kind of admin account to see what's going on ?10:15
slvnI confirm that on my dev page, I see under "Overview" both revision of click and snap10:15
JamesTaitHmm... 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
slvnJamesTait, it's based on the naming, my apps that have the same name are merged when published for the first time10:17
JamesTaitslvn, can you point me to an example package?10:18
JamesTaitI 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
slvnJamesTait, https://myapps.developer.ubuntu.com/dev/click-apps/773/10:19
slvna mahjong game10:19
slvnsnap is not published, click is published months ago10:20
slvnboth are merge ..10:20
=== Aria|away is now known as Aria
JamesTaitslvn, looking into it for you.10:21
slvnthanks ...10:23
JamesTaitslvn, OK, there's another user seeing the same thing, so it's not just a problem with your account.10:24
slvnJamesTait, ok ...10:25
JamesTaitslvn, we're looking into the root cause - could you file a bug for it in the meantime? https://bugs.launchpad.net/software-center-agent/+filebug10:28
slvnJamesTait, here it is: https://bugs.launchpad.net/software-center-agent/+bug/157771710:32
ubottuLaunchpad bug 1577717 in Software Center Agent "Published snap package appears under the list of click packages" [Undecided,New]10:32
JamesTaitThanks, slvn, we're on it.10:33
slvnok great !10:33
=== Aria is now known as Aria|away
=== Aria|away is now known as Aria
=== Aria is now known as Aria22
zygajdstrand: https://github.com/ubuntu-core/snappy/pull/111711:03
ysionneauzyga: how do we run unconfined now?11:03
zygaysionneau: http://www.zygoon.pl/2016/04/snap-install-devmode.html11:04
ysionneauzyga : ah thanks!11:12
jdstrandzyga: ack but it will be a little while11:26
* jdstrand -> long meeting11:26
zygajdstrand: sure11:26
noizerHi guys11:28
noizerI have a problem with an library that i want to use.11:28
noizerThe library does only support Soft float on my raspberry pi 311:28
noizerIs there any possibility to change snappy from Hard float to Soft Float?11:29
zyganoizer: snappy doesn't care about binaries you run11:30
zyganoizer: does that library run without snappy?11:30
noizerzyga: No I tried to install it on a raspberry pi with ubuntu mate. But there I had a problem with hard floating :s11:32
zyganoizer: can you be more specific?11:33
noizerzyga:  i'm not familiar with hard and soft floating11:33
zyganoizer: can you pastebin anything?11:33
noizerzyga: Do you know Nuance the tts egine. They support only there library on ARM processors with soft floating11:34
zyganoizer: nope11:34
ogra_i doubt it will work11:34
kyrofaGood morning11:34
ogra_you might be able to ship a complete armel chroot inside your snap ... perhaps ...11:34
zygasoftfloat 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
zygathough if you want to link to it with a armhf gcc you won't have luck11:35
ogra_zyga, you cant exec armel binaries on armhf systems11:35
zyganoizer: ask Nuance to rebuild11:35
zygaogra_: are you sure? why not?11:35
ogra_yes i'm sure11:35
zygaogra_: curious, why is that?11:36
ogra_you can multiarch ...11:36
ogra_but that means *all* libs11:36
zygawell, that's okay I was just curious11:36
zygaright that's exactly what I expected11:36
zygait's just a different abi11:36
ogra_and it means you cant use ubuntu11:36
zygaright, so you *can* execute but you need to bag all the bit you need11:36
zygathe cpu won't care11:36
ogra_cpu and kernel wont care (if it is a hardfloat capable cpu) ...11:37
ogra_but you need to ship a full chroot inside your snap11:37
zyganoizer: long story short I'd recommend really asking those folks for a build11:37
ogra_(and all this is 100% theoretical ... i dont think anyone ever actually tesetd this)11:38
noizerzyga: We asked for it but it will cost us 250 000 euro for a rebuild with all the features we want11:38
zyganoizer: for an armhf rebuild?11:38
zygawow they are picky :)11:38
noizerzyga: yes11:38
ogra_wow ... thats like ... a lot of money for 5min of work11:38
zyganoizer: unless they hand coded that with assembly that's typically "make" on an ubuntu install :/11:38
* zyga smeslls marketing BS (not noizer's in any way) 11:39
zyganoizer: quick idea11:39
noizerzyga I don't know how they builded it but yeah it is very expensive to rebuild11:39
zyganoizer: get a raspberry pi 1 image, put it on your pi2's home directory11:40
zygaand chroot11:40
zygaif that works we can snap it11:40
zyganoizer: 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
zygaogra_: we even have nice cross toolchains packaged11:40
zygaso they don't even need a board11:41
ogra_depends on the depends ;)11:41
* zyga will start charging $0.25M for his python rebuilds now ;)11:41
zygaogra_: yeah true11:41
ogra_(you really wouldnt want to cross build a gui app that uses a lot of libs ... )11:41
ogra_wxgtk ;)11:41
noizerzyga how does it works then with the image of rpi 111:42
zyganoizer: pi1 is using an older cpu11:42
zyganoizer: e.g. a raspian image is compiled for armel11:43
noizerzyga ok then put it on my rpi3 and compile and install it on that image?11:44
zyganoizer: compile everything on your pi111:46
zyganoizer: make sure it works there11:46
zyganoizer: then grab the whole sd card and tarball it11:46
zyganoizer: then put that tarball on a pi311:46
zyganoizer: unpack it, you may need to tweak some things (bind mount /proc etc)11:46
zyganoizer: then chroot11:47
zyganoizer: check that it still works11:47
zyganoizer: if you get that far we should be able to snap it11:47
* zyga looks forward to "enterprise" software11:47
ogra_if the above doesnt work you should always be able to use a real container11:48
ogra_lxc or docker ...11:48
noizerSo what will docker do then?11:49
zyganoizer: don't worry about docker11:49
zyganoizer: try what I said11:49
noizerps Is there not a way to make snappy Soft floating?11:49
noizerzyga 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 snap11:52
ogra_*same snap11:52
ogra_(geez ... /me curses freud)11:53
noizerDamn thats very hard then :s11:53
ogra_(in a year from now the above sentence will be "snap snap, snap snap snap, snap !" .... )11:54
zyganoizer: why is that hard?11:54
zyganoizer: it's not pretty, essentially shiping a foreign distro in a snap11:55
zyganoizer: but since the CPU itself allows this it would not be much different from running raspbian natively11:55
zyganoizer: 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 amd6411:56
* zyga curses timezones 11:57
zygais UOS starting in two hours from now?11:57
kyrofazyga, indeed11:59
zygathanks kyrofa11:59
kyrofazyga, plenary opening in two hours, sessions start in three12:00
kyrofaHey 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
kyrofaogra_, is that just a difference between ubuntu core and the desktop?12:06
noizerzyga Ok I will try it tomorrow because then I got my rpi1 with me12:06
zyganoizer: good luck12:07
noizerzyga 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
zyganoizer: i'll be attending UOS  but I can try12:07
noizerUOS? what does that mean?12:07
ogra_noizer, ubuntu online summit12:07
kyrofanoizer, http://summit.ubuntu.com/12:08
zygaI just tried to install a snap12:08
zygasudo snap -i ...12:08
ogra_usually the place weher we do planning for the next release ...12:08
zygaold habits die hard12:08
ogra_fix that 112:08
ogra_(by adding -i  ;) )12:08
zygaogra_: maybe I'll implement -i as a hidden command12:08
zygaalso printing "we feel your pain" ;-)12:08
ogra_yeah :)12:08
kyrofaogra_, 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-812:11
ogra_there is no additional locale handling in the rootfs ... you have to do that inside the snap itself if needed12:12
kyrofaogra_, 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
kyrofaI don't know why it's not working though, which is frustrating12:13
ogra_kyrofa, yeah12:13
kyrofaStupid boost and its cryptic errors12:13
kyrofaMorning sergiusens :)12:15
* zyga triaged https://bugs.launchpad.net/snappy/+bug/157747212:17
ubottuLaunchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete]12:17
zygaogra_: 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
zygaogra_: I'm asking because it seems to stop as soon as I run a snap12:18
zyga(not all snaps, but hello world seems to be affected)12:18
ogra_hopefully all snaps :)12:18
zyganot all snaps :)12:18
ogra_oh ?12:18
zygaogra_: build this https://bugs.launchpad.net/snappy/+bug/157747212:19
ubottuLaunchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete]12:19
zygaogra_: (snapcraft.yaml inline)12:19
zygaogra_: that snap still works!12:19
zygaas in I get ł12:19
ogra_we explicitly do not chip any locale support, keymaps or console fonts12:19
ogra_(that would likely easily triple the size of the rootfs )12:19
zygaogra_: but how does it work, gnome-terminal is from the classic ubuntu side12:19
zygaogra_: so it has the fonts12:19
zygaogra_: I don't know how input handling works12:19
ogra_but not the locale info12:20
zygabut I suspect it's also on the teminal side12:20
zygalocale, right I get how locale works12:20
ogra_we only support C.UTF-812:20
zygabut it doesn't affect keyboard input12:20
ogra_it affects the representation of the key code12:20
zygahmm? how does that work? I suspect that the shell puts the tty into raw mode12:21
zygabut what happens next?12:21
zygaand how is that affected by snappy12: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_have a look at that12:21
zygaI see locales there12:22
ogra_if you want your snap to have support for more than C.UTF-8, you have to ship this set of packages12:22
zygaI don't think that answers my question12:22
zygaI'm specifically asking about how input handling works12:22
zygaand why one snap behaves differently than another one12:22
zygathe snap I made has busybox-static12:22
ogra_a keycode is sent ... it gets processed and a char is printed :P12:22
zygaI see12:23
zygaprocessed, that's where locales go in12:23
ogra_if your font doesnt have the char, it cant be printed (and you get little squares)12:23
zygaI guess that busybox just accepts and echoes everything that's not a special control character clearly12:23
zygaand bash is is doing it "properly" and hence I get nothing12:23
zyga(properly == through locale)12:23
zygathat makes sense12:24
zygaI forgot about raw mode12:24
zygaconsole echo can be deceiving :)12:24
ogra_if you ship locales and console-setup-linux you should be able to get around that12:24
zyganah, I was just curious how it works12:25
zygaI don't really need it for anything now12:25
zygaI'd love if someone made locale that's tiny12:25
zygaand is not shipping translation12:25
zygatiny as in ~50Kb max12:25
ogra_locale and tiny dont really fit into the same sentence12:25
zygawhat's in locale anyway?12:25
zygawhat'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
zygafonts = not really12:26
zyga(not on classic)12:26
zyganot in webapps12:26
zygatermcap = not in webapps12:26
ogra_just ship the locales package12:27
zygaand outside, man just ship one for xterm and ignore the rest :P we have two termcap packages, one normal and one kitchen-sink one12:27
zygaI see a billion charmaps12:27
zygaperhaps 90% of them are useless today12:28
zygaor 100%-112:28
zygaman what a load of garbage :)12:28
zygaand the actual locale definitions should be easily under 50KB compiled12:28
zygaeven the charmaps are tiny12:29
zyga(obsolete but small)12:29
zygathough locales get some processing12:29
zyga(which is also super slow) on install time12:29
zygado you know what that does?12:30
ogra_it creates the binaries12:30
ogra_from the locale definitions12:30
zygadoes that have to run at install time?12:30
ogra_(simply calls locale-gen i think)12:30
zygacan we compile all locales on snap build time?12:31
* zyga reading the script now12:31
ogra_if you want to use the locales, they have to be up to date against whats on the system, yes12:31
zygajust shell, no perl :)12:31
zygaagainst what's on the system? what does that mean?12:31
zygaare they self contained or not?12:31
ogra_if they were self contained you would have to generate them at install time ;)12:32
zygaso what do they need from the system on install time?12:32
* zyga reads the script12:32
ogra_have a look under /usr/share/locale12:32
zygaI see just .mo files12:33
zygaanything I'm missing12:33
zygamo files are built at compile time12:33
zygaI don't suspect locale-gen needs gettext to run12:33
ogra_and locales are built from the mo files12:33
zygabut they contain keymaps12:34
zygahow is that related to translations12:34
ogra_LC_MESSAGES is part of your locale12:34
zygakeymaps and charmaps12:34
zygayes but the question is: why do we need to generate anything on install time12:34
ogra_to be in sync with the binaries on the system12:35
zygaI don't understand, in sync with what12:35
ogra_(better ask infinity for details)12:35
ogra_buit afaik there is no way to ship "small" locales pre-created12:35
zygaif I update, say, the translation catalogue for something, do I need to rebuild locale data?12:35
zygado you know why?12:36
ogra_out prob is really that we do not enforce C.UTF-8 ebverywhere yet12:36
zygathat's not a solution to apps wanting to have locale support really12:37
ogra_you dont really want country specifric locales, but you want full UTF-8 support12:37
ogra_which a LOCALE=C default doesnt give you12:37
zygaI'm trying to understand how locale works today12:37
zygaI know that12:37
zygaI disagree about country specific locale, it depends on an app12:37
ogra_but half of snappy uses C ... the other half uses C.UTF-812:37
zygahmm? 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-812:38
zygaI'm still puzzled by what you said earlier:12:38
ogra_C is the fallback12:38
mvozyga: we even have a bug about the ł issue: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/157641112:38
ubottuLaunchpad bug 1576411 in snapd (Ubuntu) "UTF-8 is not very well supported inside snaps" [High,Triaged]12:38
zygazygaif I update, say, the translation catalogue for something, do I need to rebuild locale data?12:38
ogra_if nothing is set12:38
ogra_mvo, yeah, i just commented on that :)12:38
zygaright, I saw that bug12:38
ogra_zyga, the issue is that we need to eliminate the places where C is still used12:39
mvoaha, nice12:39
mvosorry,I looked at this yesterday haven't seen all the followups :)12:39
zygaogra_: I still want to understand locale better12:39
ogra_zyga, infinity is your man :)12:39
* zyga thinks this is a nice moment to take a lunch break12:40
=== JanC is now known as Guest52941
=== JanC_ is now known as JanC
sergiusenskyrofa I have one for you https://bugs.launchpad.net/snapcraft/+bug/157775012:59
ubottuLaunchpad bug 1577750 in Snapcraft "Search for libraries for 16.10 cause a build failure" [Critical,In progress]12:59
sergiusenskyrofa better yet https://github.com/ubuntu-core/snapcraft/pull/49612:59
kyrofasergiusens, ah!12:59
sergiusenskyrofa yeah, ah describes it perfectly ;-)13:03
kyrofasergiusens, 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
kgunnzyga: hey, so from y'day discussing with jamie, looks like my interface is not "connecting" .... i added autoconnect true, but didn't seem to help13:18
zygakgunn: that's expected, the problem here is that auto-connect is only affecting the OS snap13:20
niemeyerdholbach: ping13:21
zygakgunn: see http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html (the 2nd to last header)13:21
zygakgunn: it will not connect anything to a slot on the mir snap, we need to discss how this should work before we enable it13:21
kgunnzyga: @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 slot13:26
zygakgunn: connect will connect anything compatible13:26
zygakgunn: that's still a TBD, how we want this to work, it's related to assertions as well13:26
zygakgunn: 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 policy13:27
kgunnzyga: ok, i'll migrate to a connected slot today.... that should keep me busy :)13:29
kgunni need to clean up client yaml too13:29
zygakgunn: cool, ask me anything if you are blocked13:29
zygadholbach: do you want me to prepare anything about interfaces?13:35
zygadholbach: or should I just join various sessions and answer questions/talk13:35
sergiusenskyrofa yes, but we need to implement the `release` tag in snapcraft.yaml to know what we are targetting ;-)13:40
kyrofasergiusens, okay, same page then13:40
kyrofasergiusens, so for now we're assuming the same release as host?13:40
sergiusenskyrofa yeah :-) I want to play ball as if yakkety did not exist yet though13:40
sergiusenskyrofa yup13:41
sergiusenskyrofa and cleanbuild always assumes xenial13:41
kyrofasergiusens, +113:41
sergiusenskyrofa we are xenial centric for now; I don't think we want to start supporting building from yakkety just yet13:42
kyrofasergiusens, I agree, seems like a safe assumption13:42
kyrofasergiusens, problems occur when targeting a release older than host. libc symbols and whatnot13:43
sergiusensogra_ you are missing on the "other" network. Are you off today?13:43
ogra_sergiusens, brunching :)13:43
sergiusensogra_ and you have a game to watch today I guess ;-)13:44
zygajdstrand: 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 though13:45
dholbachzyga, 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
kyrofasergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/49713:50
zygagreat, that's a plan then13:50
niemeyerdholbach: Heya13:50
dholbachhey niemeyer13:50
niemeyerdholbach: Can we move the two core sessions we have at 15UTC to 17UTC?13:50
dholbachhttp://summit.ubuntu.com/uos-1605/2016-05-03/ is the schedule for today :)=13:51
niemeyerdholbach: I think the 17UTC slot is open on that track on both days13:51
dholbachwe announced the schedule already, so some might have planned their days according to this13:51
dholbach17 UTC today is the lunch slot13:51
dholbachand the 15 UTC session today is about python313:51
dholbachso led by somebody in the foundations team13:52
ysionneauzyga: read_paths / write_paths still exists ?13:53
zygaysionneau: no it does not13:53
zygaysionneau: that was a part of old-security13:53
ysionneauwhat is the modern way?13:54
zygaysionneau: to come up with a new interface13:54
zygaysionneau: what do you need access to?13:54
dholbachniemeyer, ^ did you see my reply?13:54
niemeyerdholbach: Okay, sounds good, thanks13:55
ysionneauok maybe let me copy paste all the warnings I get (in --devmode) zyga13:55
dholbachniemeyer, cool13:55
zygaysionneau: please do!13:55
ysionneauzyga: http://paste.ubuntu.com/16201687/13:56
zygaysionneau: ah, /dev/shm, we're looking into making that easier13:56
zygaysionneau: currently you can access /dev/shm but just in weird locations13:56
ysionneauyeah I've seen the mailing list posts13:57
sergiusenskyrofa https://github.com/ubuntu-core/snapcraft/pull/49814:00
sergiusenskyrofa about locale, I have ideas :-)14:00
kyrofasergiusens, good deal. Should we hold off on that catkin PR, then?14:00
* zyga tunes into UOS14:01
sergiusenskyrofa just until standup which is when UOS ends :-)14:02
kyrofasergiusens, sounds good14:03
pmpis there somewhere an snapcraft.yaml-example (up-to-date) which shows how to request a syscall permission?!14:12
sergiusenspmp 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
zygapmp: o/14:16
sergiusenspersonally I am hit by it a bit too as I can't easily get things out of the way14:16
dholbachUOS sessions today: http://summit.ubuntu.com/uos-1605/2016-05-03/14:20
zygapmp: which system call are you missing?14:21
pmpsend - for a test I removed all plugs-sections of my apps - now added network14:26
zygapmp: send for a test? can you elaborate on that?14:27
pmpthe missing syscall was 'test' (289 on arm)14:27
pmpnot test - 'send'14:27
pmpplugging my app to network fixed14:28
zygapmp: ah, cool :)14:28
zygapmp: so you don't need any interfaces beyond network?14:28
pmpzyga: not for the moment14:28
zygapmp: cheers, good luck :)14:28
kyrofasergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/450 has been rebased14:31
pmpzyga: well, I just got another syscall missing 241, which is sched_setaffinity14:37
sergiusenspmp you can start out by logging a bug and tagging it like https://bugs.launchpad.net/snappy/+bugs?field.tag=snapd-interface14:39
pmpsergiusens: where (in snappy) is the mapping done between syscalls and interfaces?14:41
sergiusenspmp in https://github.com/ubuntu-core/snappy14:41
sergiusensexact location I would need to check for14:41
sergiusensoh, top level interfaces in there14:42
noizerzyga short question what OS should i run on the rpi1 for the soft-float problem14:42
zyganoizer: rasbian should be easiest to work with14:43
zyganoizer: the default pi os14:43
noizerok will it be automatically soft float?14:43
noizerbecause i dont know mutch of floating etc14:43
noizermay it be the latest rasbian?14:44
zyganoizer: all of pi1 is like that14:44
zyganoizer: yes, any version will work14:44
noizerzyga ok14:45
noizermaybe for good understanding14:45
noizerzyga i just need to build an application for the soft floating14:45
noizeron rpi114:45
zyganoizer: https://wiki.debian.org/ArmHardFloatPort (for some back-story)14:45
noizerwhat should i do then?14:46
zyganoizer: install rasbian, build your app there14:47
zyganoizer: test your app14:47
zyganoizer: look at the list I gave eaarlier, ask questions if you get stuck14:47
noizerzyga: then i need to chroot and build it in a snap?14:48
zyganoizer: then you need to take that whole rasbian install and stick it in your home directory on a pi3 system runnning ubuntu 16 series14:49
zyganoizer: then we can see if it works there if you chroor inside14:49
zyganoizer: we can look at snapping that, if it works, at the very end14:49
noizerhopefully will it work14:50
zyga(or pi2, I don't know if pi3 works yet)14:50
zygaogra_: does pi3 work btw?14:50
zygawith the pi2 image14:50
noizerI can start first with the pi214:51
ogra_zyga, yes ... though i'd suggest to build your own image using the pi3 gadget14:51
zygaogra_: ah, nice, let me try that14:51
ogra_i will roll back the pi2 one to pi2 only very soon14:51
zygaI recall mvo did some changes to gadget support14:52
zygawonder if that affects ip314:52
ogra_which would leave you with an unbootable image14:52
noizerogra_: oooh ok14:52
ogra_the pi2 and 3 gadgets are identical ... apart from uboot.bin14:52
ogra_so as long as the pi2 one works, the pi3 one will too14:52
pmpogra_: well the pi2 still behaves "not as before" - terminal via uart still doesn't work and the red-led is behaving strangly14:55
ogra_pmp, yes, on my TODO14:55
pmpbut it works14:56
pmpI mean snap is working nicely - ideal for my tests14:56
ogra_feel free to help testing this ;)14:56
ysionneauit 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
zygaysionneau: all of those are coming from snappy14:56
ogra_(thats my pending upload for the gadget snap that should restore the old UART behaviour14:56
zygaysionneau: I can show you where it is in the code if you want14:57
zygaysionneau: the core snap could, but is not currently, defining any interfaces14:57
zygaysionneau: in the snappy source tree look at snap/implicit.go14:57
zygaysionneau: all of the interfaces are defined in interfaces/builtin/14:57
ysionneauso far I looked at https://github.com/ubuntu-core/snappy/tree/5324816c114757ed1b8641a63a84d6bd3a6edb66/interfaces/builtin14:58
ysionneauok lemme have a look at implicit.go :)14:58
zygaysionneau: there's also my post that describes a bit about how interfaces look like: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html14:58
ysionneauah I see.14:58
ysionneauzyga: oh, I didn't see this one, did you post it on the ML?14:59
pmpogra_: 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
zygaysionneau: actually no14:59
zygaysionneau: I have a biiig one after this, just need a moment to finish some last bits14:59
ogra_pmp, not really ... we are working on a porting guide soon15:00
ysionneausomething 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
zygaogra_: I suspect we'll need to decide on gadget/assertions transition next week15:01
ogra_thats my expectation15:02
ogra_(that we come out of the week and know how kernel and gadget will look like)15:02
pmpis there a possibility to create an interface on my system, which actually provides more syscalls or other protected things via a snap?15:10
zygapmp: yes but you will have to contribute that interface to snappy to actually be able to distribute your snap in any way15:10
zygapmp: you cannot do that with a 3rd party snap15:11
zygapmp: all interfaces are defined in snappy source code15:11
zygapmp: and this is the basis of security of the whole architecture (along with reviews in the store when restricted interfaces are used)15:11
pmpzyga: how will this work with a branded store? Where we will most likely need customized interfaces.15:15
zygapmp: that's an excellent question for the sprint15:16
zygapmp: wrote it down now15:16
pmpzyga: thank you15:17
zygapmp: 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
pmpzyga: no problem, via mail it will be easier15:19
zygapmp: do you know how to contact me?15:19
pmpzyga: I have your address15:19
zygajdstrand: add https://bugs.launchpad.net/snappy/+bug/1577471 to your TODO (To read) list please15:37
ubottuLaunchpad bug 1577471 in Snappy "Snap applications cannot access the user's normal XDG directories" [Undecided,Confirmed]15:37
jdstrandzyga: 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 later15:39
jdstrandzyga: so it is that, pr 1117 and 1118 that you need?15:40
zygajdstrand: yes though the purpose of the home interface is to let them access other files15:40
zygajdstrand: anyway, thanks :)15:40
jdstrandother non-hidden files15:40
jdstrandbut sure, we can discuss in the bug15:40
jdstrandI mean we can do whatever, I just want to make sure we are doing what we agreed to15:40
zygajdstrand: I reviewed the seccomp argument filtering branch btw15:41
zygajdstrand: 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 executable15:41
roadmrhey 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
jdstrandzyga: it has to parse it, it sets up the seccomp sandbox15:44
zygaroadmr: not at the moment, is that a desktop snap, a cli snap, a service?15:44
zygajdstrand: no, it has to setup the sandbox, doesn't mean that has to parse text :)15:44
roadmrzyga: it installs a ssh server listening on port 8022 (see, I'd like to at least document the port)15:45
zygajdstrand: we could parse it into a binary format that is far easier to load15:45
=== chihchun is now known as chihchun_afk
jdstrandzyga: how else is it going to setup the seccomp sandbox?15:45
zygaroadmr: we don't have anything that would support that today15:45
zygajdstrand: the same way, just read the description from the binary file15:45
roadmrzyga: 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
jdstrandzyga: then we are parsing binary in a setuid executable15:45
roadmrzyga: ok, gotcha... I'll find a workaround :) thanks!15:45
zygajdstrand: yes, that's far easier to validate15:45
zygajdstrand: load a header, load a bunch of structures, look at the data for sanity checking15:46
jdstrandzyga: the kernel doesn't have an interface like apparmor for loading a binary blob15:46
zygajdstrand: yes but that can all be local to u-c-l15:46
zygajdstrand: the binary interface15:46
jdstrandI think there are bigger fish to fry15:46
zygajdstrand: e,g, we could even exec the parser and read from it, after dropping root15:46
zygajdstrand: sure, I just wanted to point that out15:46
* jdstrand notes that the parsing is happening after dropping root15:47
zygajdstrand: it feels like something that will grow and get more complicated15:47
zygaI didn't notice that! sorry for that then15:47
jdstrandgranted, it isn't permanently dropped due to nnp (which is unfortunate, but the state of things atm15:47
jdstrandthere is a comment in the code if you want to know more about it15:48
zygaI see15:48
jdstrandbut, seccomp is quite limited-- there isn't terribly much more we can do15:48
roadmrcan I build my snap for e.g. arm or arm64 on an x86_64 host?15:48
zygajdstrand: is the reason we're adding seccomp argument filtering because how apparmor and seccomp differ as to when they are inspected?15:49
zygaroadmr: use launchpad15:49
zygaroadmr: otherwise probably not15:49
roadmrzyga: oh yay! I'll look into it. Not a big deal, really, it's a toy snap15:49
jdstrandzyga: we are adding it for things like setpriority15:49
zygaapparmor cannot inspect the arguments but seccomp can, right/15:50
jdstrandzyga: with setpriority there are values that are ok (eg, >0) but other values that are not15:50
roadmrzyga: thanks for your help, I know you're busy, much appreciated :)15:50
* roadmr goes for nooms15:50
jdstrandzyga: apparmor doesn't do syscall filtering or inspection at this time15:50
jdstrandapparmor uses the LSM15:51
zygajdstrand: right, thanks for hand holding me with all my questions :-)15:51
jdstrandand 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
gblanchard4How do I set the logging level when using the snapcraft commands?16:01
sergiusenselopio what's our status on adt for the "other" arches?16:11
elopiosergiusens: 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
elopiomy hope is that they'll give us access while jenkaas is ready for us. Waiting for reply...16:14
sergiusenselopio right, but all our tests error out in the archive's adt run, so wondering if there is an easy fix there16:15
elopiosergiusens: 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
elopiopitti: is there a way I can get the same armhf container autopkgtests are using?16:17
sergiusenselopio fair answer :-)16:17
sergiusenselopio as a follow up, that was about pivoting on arches, we should also add adt for yakkety if possible in our tests16:18
elopiosergiusens: that one is easy, I added it to my TODO. Do you want it run in every PR?16:19
sergiusenselopio yes please, we need to ensure we keep compatibility both ways (ensure APIs we choose work on both)16:19
sergiusenselopio if possible enable that ASAP :-) Already going down the third dput that fails on infra ;-)16:21
elopiosergiusens: on it...16:26
pittielopio: sure, just use adt-build-{lxc,lxd}, those are exactly what production uses16:30
pittioh, almost16:31
pittiwe apply this --setup-command on every test:16:31
pittied -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.service16:31
pittielopio: sorry, of course you don't need the apt source mangling to ftpmaster.internal, that only works in the DC16:31
pittielopio: but you might want the ln -s /dev/null /etc/systemd/system/bluetooth.service, some tests fail otherwise16:32
pitti(apt-get install bluez fails in a container)16:32
elopiopitti: thanks, OD!I'll try soon.16:35
elopioignore the OD, it's hard to type these days.16:35
sergiusenspitti 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
sergiusenswell maybe not python apt could be something else16:39
pittisergiusens: eek; haven't seen this yet, but this actually looks like apt itself (libapt)16:40
sergiusenspitti so the path forward is I should wait for a tentative fix there and then click on "rerun"?16:41
pittisergiusens: where did you see this?16:41
sergiusenspitti https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapcraft/20160503_064449@/log.gz16:41
sergiusenspitti we use python apt where what fails are seen (only on y)16:42
pittisergiusens: oh, this isn't new -- http://autopkgtest.ubuntu.com/packages/s/snapcraft/yakkety/amd64/ history reaches back to all of yakkety indeed16:42
sergiusenspitti I haven't seen this on xenial though (which gets adt runs on every code drop)16:44
sergiusensin the process of adding yakkety now16:44
pittiright, xenial seems fine16:44
sergiusensbut I have no idea what is going on given the archive is rather new I think infra problems but I may be totally off track16:45
Paddy_NIIs there a way of browsing the currently available snaps?16:47
sergiusensmvo can I ask you being the apt expert?16:48
sergiusensmvo maybe I can expand that to "software package" delivery expert ;-)16:48
elopiosergiusens: kyrofa: after Sergio's suggestion, this one is ready to go: https://github.com/ubuntu-core/snapcraft/pull/48116:49
sergiusenselopio I am afraid of running any of this in yakkety now given the above breakage :-P16:50
=== kissiel-afk is now known as kissiel
sborovkovHello. 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
elopiosergiusens: 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
elopioso, feel free to leave it in the queue.16:58
sergiusenselopio just want to get the apt issue solve first16:58
zygasborovkov: excellent question, let me look16:58
zygasborovkov: ah, sorry  shm_open is  not the same as /dev/shm16:59
sborovkovzyga: is not it used for creating shared memory anyways16:59
zygasborovkov: AFAIR the memory allocated with dev_shm is not visiable in the filesystem16:59
sergiusenszyga the man page seems to illustrate it otherwise17:00
zygasborovkov: for /dev/shm/stuff, I'm not sure but AFAIR it is just a tmpfs so you can just open files there17:00
* zyga reads17:00
sergiusensshm_open(const char *name, ...) where name is of the form of a path17:00
zygasergiusens: yes, but I'm not sure that is an actual file, I'm almost sure it's not, though I could be wrong17:01
sergiusenszyga maybe correct, but I guess if you use shm_open you avoid this apparmor problem17:01
sborovkovsergiusens: how do you avoid this problem?17:01
zygasergiusens: right, this is a different system call17:01
sergiusenszyga 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 X17:01
zygasergiusens: though AFAIR shm_open is terrible and discouraged17:01
zygasergiusens: as there'es no good value for name17:01
sborovkovargh, webkit's using it. Oh well.17:02
sergiusenssborovkov you should be able to just open("/run/shm/$SNAP/$REVISION")17:02
zygasergiusens: 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
sergiusenssborovkov but yeah, you'd need to patch webkit; is it of the form "org.chromium.Chromium.XXX"?17:03
sergiusensthat's my current blocker issue today fwiw17:03
zygasborovkov: if it's easy to patch, do it17:03
sborovkovsergiusens: sorry, what do you mean about the form "..."?17:03
zygasborovkov: we're definitely going to change what is allowed (to make it more liberal) though jdstrand knows the details17:03
sergiusenszyga it really isn't which is why I wanted my proposal to mount in a new namespace to fly :-)17:04
zygasergiusens: I think that's a sensible idea17:04
sergiusenszyga jdstrand and about pulseaudio, if hardlinking is supported, I'd just hard link into that path created by the launcher ;-)17:04
zygasergiusens: a fork bomb snap would still work so I would not worry much about how shm quotas should work now17:04
zygasergiusens: I'm not familiar with pulseaudio issues17:05
sergiusensbut if pulseaudio requires accessing shared memory, I'd say the architecture for pulseaudio is somewhat broken as well ;-)17:05
zygasergiusens: why?17:05
zygasergiusens: it use buffers to share between clients17:05
sergiusenszyga look at my email exchange with jamie ;-)17:05
zygasergiusens: where is the excchange?17:05
sergiusenszyga yeah, but I could write to other locations and inject into other apps, right?17:06
sergiusenszyga mailing list of course, don't you read email anymore? ;-)17:06
zygasergiusens: nah, I'm just not fully up to my inbox zero goal :)17:06
sborovkovzyga: 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
zygasergiusens: I moved 500 emails out of the way today17:07
zygasborovkov: one sec17:07
sergiusenssborovkov I cannot recommend anything, I am blocked ;-)17:07
zygaso I just checked17:10
sborovkovzyga: 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
zygaI just made a demo snap17:17
zygaone sec let me publish this17:17
zygaI may have a nice solution17:20
zygafor all apps17:20
zygagive me 10 more minutes, ok17:20
sborovkovzyga: sure, thanks for assistance :-)17:24
jdstrandsergiusens, 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
jdstrandas for dealing with chromium-- still thinking that through17:29
jdstrandsergiusens: note, your proposal is not to mount in a new namespace. it is to bind mount (there is a big technological difference)17:30
sergiusensjdstrand you are most likely right :-)17:31
sborovkovzyga: alright, I gotta go now, I will ask you tomorrow about your solution then17:41
zygaalmost done :)17:43
zyganow for the grand finale17:45
zygalet it work with any precompiled app :)17:45
* zyga loves C17:45
=== charles_ is now known as charles
zygajdstrand: quick question18:11
zygajdstrand: I made shm_open work magically18:12
zygajdstrand: as a LD_PRELOAD or link-time .o18:12
zygajdstrand: but it seems that apps cannot actually create /dev/shm/$SNAP_NAME/$SNAP_REVISION today :)18:12
zygajdstrand: it feels like the launcher should do that18:12
zygajdstrand: do you agree?18:12
jdstrandlet me double check18:12
zygathank you18:12
zygasergiusens: ^^ if this is fixed I can give you a part that fixes anything18:13
zygasergiusens: using shm_open18:13
jdstrandbut I think that is right (like with ~/snap/name/version, it was the launcher's job to do that18:13
jdstrandbut, we can fix that18:13
zygajdstrand: rigth, that's my feeling18:13
sergiusenszyga it doesn't use shm_open (chromium, I told you exactly the opposite)18:13
zygasergiusens: oh, I'm sorry what does it use then?18:13
sergiusenszyga open18:13
zygasergiusens: ah, directly?!18:13
zygaboo :)18:13
zygawell, better than nothing :)18:14
zygaI'll share my stuff after this session18:14
jdstrandzyga: 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
jdstrandzyga: but something will still need to create /{dev,run}/shm/snap18:15
jdstrandwe could do:18:16
jdstrand/{dev,run}/shm/snap/@{SNAP_NAME}/ r,18:16
jdstrandand have the launcher create /{dev,run}/shm/snap/@{SNAP_NAME}18:16
zygajdstrand: /dev/shm/snap/$SNAP_NAME or /dev/shm/$SNAP_NAME18:16
zygajdstrand: I'll work on this18:16
jdstrandzyga: ok18:16
zygajdstrand: how soon can we release a launcher that does /snapname/snaprevision18:16
zygajdstrand: this would work with new snaps (using my trick) without a release of snappy proper18:17
sergiusenszyga 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#14418:17
sergiusenszyga so mkstemp18:17
zygasergiusens: glibc has a way to customize shm_open18:18
zygasergiusens: so too bad it's not used here18:18
zygasergiusens: this will have to be patched :/18:18
zygaanyway, one problem at a time18:18
zygasergiusens: thanks for sharing this18:18
sergiusenszyga it is not that simple though18:19
jdstrandzyga: 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-tape18:19
sergiusenszyga as this code base is spread out in many projects and many projects use their own variant build/fork18:19
zygajdstrand: we should get the blank-ish check though18:19
zygaas more and more things will be released18:19
zygajdstrand: but for now I agree18:19
jdstrandtyhicks: do you have a feeling for when the seccomp arg filtering will be reviewed?18:19
jdstrandzyga: yes (and I requested that for the launcher)18:20
jdstrandwell, I asked that someone else ask for it18:20
jdstrandI think that happened18:20
tyhicksjdstrand: hopefully by the end of this week18:21
tyhicksjdstrand: is that soon enough?18:22
jdstrandtyhicks: cool, thanks18:22
zygajdstrand: 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=100018:34
zygajdstrand: should this be denied today?18:34
zygaah, I see /dev/shm/snap/18:38
zygasorry for bugging you :)18:38
zygajdstrand: ^ I'll hack u-c-l and snappy to do what you suggested earlier18:42
jdstrandzyga: /dev/shm/shm-open-demo/100001/demo should be denied today. I forgot /dev/shm/*snap*/18:47
zygayep, I noticed that :)18:47
jdstrandah, yes you did :)18:47
zygajdstrand: I patched it to have /snap/ there too18:47
zygajdstrand: one thing I realized is that the launcher doesn't know $SNAP_NAME or $SNAP_REVISION today18:48
zygajdstrand: (it might just use getenv but feels wrong, I'd really just want to know $SNAP_NAME and act on that18:48
zygajdstrand: (to mkdir bits)18:48
zygajdstrand: ah, it seems it does use environment variables, so I guess that's not an issue18:49
zygathough that feels wrong :)18:49
sergiusenszyga create a part, put it on the wiki18:50
zygasergiusens: good idea18:50
qenghoComputer: "cannot get discharge macaroon from store"    Me: "Oh, right. Of course"19:26
* zyga still doesn't know what discarge there means19:27
qenghoMy new band name is DISCHARGE MACAROÖN.19:28
mvoqengho: could you please check if there was maybe a typo in the username/password?19:31
mvoqengho: and yeah, the error message needs some love19:31
ogra_Just rename it to 'boom!'... Has about the same amount of info, but is funnier19:33
=== gene_ is now known as gblanchard4_
gblanchard4_Can you expose multiple commands in the snapcraft.yaml?19:59
sergiusensyes gblanchard4_20:00
qenghoSure. New sections.20:00
sergiusensit is a a dict20:00
qenghoI was making a snap in one place. I disconnected. Resumed at home. Now, running the snap says "Bad system call20:02
qengho". I can't think of any other change than the network in use.20:02
qenghoI know that sounds crazy.20:02
qenghoThat 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
qenghoI haven't updated snap deb in the last week or so.20:05
qenghoCould it be some problem with the seccomp filter not being fully un-installed or something, between "snap remove/install" runs?20:06
zygaqengho: probably one of the bugs in 2.0.220:07
zygaqengho: I hope we release 2.0.3 soon (today?)20:07
zygaqengho: also there's a known bug in 2.0.2 when you install a snap a few times (during development)20:08
qenghozyga: I think I've been careful to remove first. I think that avoids it.20:09
gblanchard4qengho: Thanks, I will give it a try!20:10
qenghoNext question: Can I find out what syscall failed?20:24
Kamilionqengho: sysdig can probably drill down to answer that for you.20:26
sergiusensqengho dmesg | grep <snap>20:26
sergiusensqengho scmp_sys_resolver against sig20:26
Kamilionyou'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
qenghosergiusens: I only see apparmor lines, no seccomp.20:27
Kamilionthen drill down to failed system calls and look which processes are unhappy20:27
sergiusensqengho are you maybe looking at old logs then?20:27
qenghofresh out of "dmesg"20:27
sergiusensor you may have been hit by kernel rate limiting20:27
qenghoEh, no.20:28
sergiusensqengho ph plain "Bad system call", maybe binary from a different arch?20:28
jdstrandsergiusens, qengho: note bug #1567597. if you are using --devmode there is no logging of seccomp violations20:28
ubottubug 1567597 in Snappy "implement 'complain mode' in seccomp for developer mode with snaps" [Medium,Confirmed] https://launchpad.net/bugs/156759720:28
qenghosergiusens: I built it here, no special flags or compiler.20:29
qenghojdstrand: Not using devmode.20:29
zygajdstrand: is there a way to get a core file from a crashing app?20:30
zygausing pulse in snappy (even with --devmode) crashes all the stuff I try20:30
qenghoI think I can make it go somewhere with proc core pattern.20:30
sergiusenszyga ulimit -c unlimited20:30
zygaI got a game working20:30
zygathough without sound for now :)20:30
zygagot it :-)20:31
qenghoI swear, this started its "Bad system call" when I moved locations.20:31
qenghoI'm renaming package to see what happens.20:32
zyga#0  __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:6020:33
zyga#1  0x00007fc06ed8d4ce in __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:198720:33
qenghozyga: Athlon?20:33
zygano :)20:33
zygacore i720:33
zygasame binary works outside20:34
zyga(this is scummvm)20:34
Kamilionah, I was wondering. Interesting.20:34
zygaI suspect a null pointer somewhere20:34
jdstrandzyga: I don't know. I do know mvo had gdb, etc working in snaps at one point20:34
zygaI'll build scummvm from source with debug20:34
zygajdstrand: hmm, you just gave me an idea :)20:35
zygamy idea is to go to sleep for a change20:35
yofelso, 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
josharensonIs there an https server available as a snap?20:36
jdstrandzyga: 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
nealmcbI 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
qenghonealmcb: I don't think there are any good rpi images right now.20:45
nealmcbqengho: i.e. 15.04 is the latest good one?  Or even it isn't good?20:46
nealmcband what is the story for the raspberry pi 3?20:47
qenghonealmcb: 16.04 could be good, theoretically, but I don't think any current image is. Just a fluke today.20:47
nealmcbwhat sort of fluke today?20:48
=== blr_ is now known as blr
josharensonnealmcb: I installed snappy (as opposed to 16.04 server) on my pi2 last night just fine20:49
josharensonnealmcb: ah qengho makes an interesting point20:49
nealmcbjosharenson: which image?  The one I pointed to?20:49
Kamilionnealmcb: 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
jdstrandkgunn: I read your bug report for slot connect. are you at least able to manually connect the permanent slot side?20:50
josharensonnealmcb: No its a 15.04 image20:50
KamilionI know snapd has one available20:50
josharensonnealmcb: ubuntu-15.04-snappy-armhf-raspi2.img.xz20:50
jdstrandkgunn: or is it basically not being added until a connection with a client?20:50
Kamilion(for xenial)20:50
zygaKamilion: xenial core images are not finished yet20:51
zygaKamilion: I think we will offer developer preview images soon but I think this will only take shape next week20:52
ogra_There are experimental ones for all arches but you will have to wipe them soon20:52
Kamilionso then what's ubuntu-core 16.04+20160419.20-55 ?20:52
Kamilionah, okay20:52
zygaKamilion: where did you get it from?20:52
Kamilionthanks, ogra_20:52
ogra_so it isn't rally worth releasing them until they are upgradeabl20:53
Kamilionzyga: snapd?20:53
zygaKamilion: that's the core snap20:53
zygaKamilion: that's not the whole image, the whole image has a kernel and a gadget20:53
zygaKamilion: we're still working on those parts20:53
zygaKamilion: on 16.04 you are using the kernel from the classic ubuntu20:53
Kamilionyes, I am20:53
zygaKamilion: 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 now20:54
Kamilionand only the pi2 and 3's CPU will be supported, ARM7 yadda yadda20:54
zygaright now we only have previews that may need to be re-flashed entirely sometimes20:54
ogra_there are the experimental ones... But you will have to re-flash...20:54
Kamilionno 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 bbb20:55
Kamilionare the images going to be available before the first point release of xenial in juneish?20:55
ogra_pi2 will be officially supporte20:56
Kamilionoh, I've got a BBB, I should give that a shot.20:56
zygaKamilion: juneish?20:56
ogra_around 16.04.120:56
zygaKamilion: anyway, I think we will have images "in a few weeks"20:56
ogra_I guess20:56
zygaso weeks, not months20:56
zyga16.04.1 is released after 16.1020:56
ogra_well, 8weeks are two months :)20:56
Kamilionlast I heard from #ubuntu-release during the 20th to 25th when I was paying attention, the first point release was supposed to be june20:56
zygaogra_: hush ;)20:56
ogra_zyga huh?20:56
zygaogra_: still I hope this will be less than two months :)20:57
zygaogra_: just kidding, sorry20:57
ogra_.1 will definitelyvrelease before 16.1020:57
qenghoJuly, I think.20:57
ogra_unless the release schedule got totally changed20:57
zygaKamilion: perhaps I remember incorrectly but 14.04.1 was done after 14.1020:57
zygaanyway, sorry, I may be wrong here20:57
ogra_should be in july20:57
ogra_and I guess stablebsnapoy will be broad the same time20:58
Kamilionzyga: yes, that was the case, 14.xx's point releases were far between20:58
zyga(and it containled LTS enablement packages)20:58
ogra_stable snappy20:58
KamilionI think 16.04 is getting more rapid updates20:58
zygaah, I wasn't aware of that20:58
Kamilionor at least an early point release to deal with some post-release problems20:58
ogra_.1 is always early20:58
Kamilionlike the llvm-3.8 issues20:58
ogra_usually hew comez with .220:58
ogra_god !!!!20:58
ogra_the auto correction is killing me20:59
nealmcb 20:59
Kamilionwow, fun, ZNC with a bunch of clients, just like me. heh.20:59
nealmcbGreat - thanks folks!20:59
kgunnjdstrand: well, i just cleaned up my client project...and was working on pushing aroud the i/f to be "connected" slot vs permanent21:00
zygakgunn: how do you setup your VM, perhaps I can reproduce your setup and aid you somehow?21:01
kgunnzyga: https://developer.ubuntu.com/en/snappy/guides/mir-snaps/21:01
edsiperogra_, what's the procedure to flash de Dragonboard ?21:01
kgunnthanks for attempting, and let me know if you have questions21:02
zygakgunn: huh, that's nothing special?21:02
zygakgunn: does qemu work?21:03
zygakgunn: I should be able to run this with regular devtools setup with a simple tweak21:03
kgunnyeah, i hadn't tried with any other vm's...so it might be fine21: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 go21:03
zygakgunn: which vm software are you using there libvirt uses kvm inside?21:04
zygakgunn: anyway, I'll check that tomorrow, I suspect this can be x10 easier and faster with devtools-based setup and ephemeral VMs it is using21:05
kgunnzyga: info says hypervisor:kvm emulator:/usr/bin/kvm-spice21:05
zygathat's great then21:05
edsiperogra_, is this one functional ? http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz21:05
zygawill work just as well with qemu :-)21:05
zygakgunn: I'll ping you tomorrow, for now I have to look after my kids21:05
ogra_should  be, yes ... you will need to create a wlan0 file etc21:06
kgunno/ enjoy zyga21:06
ogra_(to get ssh access)21:06
qenghobefore: 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
zygasergiusens: do you have any hints on stage-packages and -dbg packages for symbols22:11
zygasergiusens: should I build libsdl myself and just overwrite the bits in snap/ manually for hacking (like I did with scummvm executable)22:11
zygasergiusens: or is the a better magic way to get non-stripped libraries22:11
gblanchard4Are underscores and periods not allowed in the YAML? i.e. in the apps section22:13
zygagblanchard4: they are not allowed22:16
zygagblanchard4: juse use dashes, most apps don't use dots and we use them internally so they are reserved22:17
gblanchard4zyga: Okay, thanks for the information. I was trying to figure out why my yaml failed validation.22:20
zygagblanchard4: snapcraft should also check that, I think22:21
gblanchard4zyga: 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.py22:22
zygagblanchard4: remember how snap apps are exposed22:22
zygagblanchard4: in general each app is named: $snap.$app (e.g. biosoftware.something)22:23
zygagblanchard4: when you have many scripts you can improve their names based on this knowledge22:23
zygagblanchard4: you can run print_config.py from a command called print-config22:23
zygagblanchard4: the command name is not the same as the file / command it runs22:24
gblanchard4zyga: Thats a great point!22:24
zygagblanchard4: 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
zygagblanchard4: so if there's any "main" program in your snap that would be the way to expose it22:25
gblanchard4zyga: Ha, I learned that the hard way by accident. It's really a collection of python scripts, no "main".22:27
zygagblanchard4: are they CLI tools?22:27
gblanchard4zyga: yes22:27
gblanchard4zyga: 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
zygadefinitely pulseaudio related22:53
zygathe crash is in #2  0x00007f0a75f17fe6 in PULSE_SetCaption (this=0x22b3460, str=0x0) at ./src/audio/pulse/SDL_pulseaudio.c:39422:53
qenghoOh man, no "source:" for merely downloading a file? Ugh.22:55
zygathe root cause is null pointer coming from         SDL_WM_GetCaption(&title, NULL);22:55
zygawhich smells X related22:55
zygafound the root cause :)22:57
zygaheh /proc related (obviously)22:57
zygaand also a bug in sdl1.223:06
zygajust last build before EOD23:06
zygaI have a working snap for flight of the amazon queen23:24
zygasergiusens: I fixed a bug in sdl that probably (99%) affects each SDL game23:24
zygaresulting in a crash23:24
ZenHarbingerI 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-swing23:29
ZenHarbingernamely, it doesn't run23:29
zygaZenHarbinger: hey, I replied to your question23:29
zygaZenHarbinger: can you pastebin snap interfaces please23:30
ZenHarbingeryou mean the output?23:30
ZenHarbingerfrom snap interfaces?23:30
ZenHarbingerI listed it at the link:23:31
zygaah, I see now23:31
zygacan you look at syslog and pastebin the DENIED lines23:32
zygaI suspect this is getpeername or something like that I fixed this for 2.0.3 already23:32
zygabut let's see23:32
qengho"snap justlikeapportcollect23:32
zygaZenHarbinger: just pastebin the whole syslog if you don't know what to look for23:35
ZenHarbingersorry, had to run it23:36
zygaZenHarbinger: https://bugs.launchpad.net/snappy/+bug/157452623:37
ubottuLaunchpad bug 1574526 in Snappy "x11 plug doesn't allow getsockname, breaks xeyes" [High,Fix committed]23:37
zygathis is already fixed23:37
ZenHarbingerawesome, so just wait? ok.23:37
qengho(Note, not "Fix released")23:37
zygamvo will release 2.0.323:37
zygathen you will need to reinstall (or disconnect and reconnect x11) the snap23:38
zygaand it should work23:38
ZenHarbingerGreat! Thanks guys!23:38
zygaZenHarbinger: (please update the question on ask ubuntu if you can)23:41
zygasergiusens: https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/157798623:46
ubottuLaunchpad bug 1577986 in libsdl1.2 (Ubuntu) "SDL 1.2 crashes on snappy, breaks scummvm" [Undecided,New]23:46
qenghozyga: 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
zygaqengho: v2 of what?23:50
zygaqengho: snapd 2.0.2 was released on the 21st or something close to that23:51
qenghoWell, whatever we release as snappy. Not "2", but "come, all, snappy is ready for you". The number is not important.23:51
zygaqengho: ah, I see23:51
zygaqengho: sprint topic23:51
zygaqengho: I don't have any lists yet though I actually proposed we run with one :)23:51
zygaqengho: for desktop apps and some unspefied use cases for devices23:52
qenghoIf you want one that's ambitious and not quite crazy, I will upload my "Kodi" snap branch.23:52
qenghozyga: Go offline already! :)23:53
zygaqengho: 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 apps23:54
zygaqengho: but also remember that some desktop things are very hard because everything is closely coupled23:54
qenghoDon't I know it.23:54
zygaqengho: so I don't know if we'll succeed quickly23:54
zyga(with kodi :)23:54
zygaanyway, afk :)23:54
zygagood night23:54
qenghoGood 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!