| === attente_ is now known as attente | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === stevebis1uit is now known as stevebiscuit | ||
| didrocks | good morning! | 06:24 |
|---|---|---|
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| noizer | Hi guys | 08:20 |
| noizer | I have just a question for my boss. when will Snappy be released on the raspberry pi 3? | 08:21 |
| jamiebennett | Hi noizer, you can roll your own image today using our tools. There was a post about this recently on the mailing list - https://lists.ubuntu.com/archives/snapcraft/2016-May/000021.html | 08:41 |
| jamiebennett | noizer: Official images will come later | 08:41 |
| noizer | jamiebennett: But is it officialy released because its to know when we can go in production | 08:43 |
| jamiebennett | noizer: Official releases are not available yet, we are still working on solidifying the apis | 08:44 |
| noizer | But i just needs a average date (month) when it will be official | 08:45 |
| jamiebennett | noizer: At the moment we are still putting a lot into the images. Something more stable will be available at the end of the month but we will continue to work on them beyond that. | 08:48 |
| jamiebennett | noizer: What is the device you are taking to production? | 08:49 |
| jamiebennett | noizer: Feel free to shoot me an email if you want to discuss specifics | 08:49 |
| jamiebennett | jamie.bennett@canonical.com | 08:49 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| wligtenberg | Hi, I have created a snap, from a package. I have installed it, but how do I run it? (I also have the same application installed normally on my system) | 09:12 |
| wligtenberg | Do I run it by the name of the snap, or the exported command, or the name of the application in apps: ... (in the snapcraft.yaml)? | 09:15 |
| gouchi | wligtenberg: according to the article app.command https://developer.ubuntu.com/en/desktop/examples | 09:36 |
| matteo | hi | 09:55 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| davidcalle | gouchi: wligtenberg , one thing that's not mentioned yet on this doc: if "app"=="command", you only need to run app, to run the app.command. | 10:06 |
| wligtenberg | davidcalle, thanks that is where I got confused. | 10:07 |
| wligtenberg | It is running the right command now, but that currently has an issue. Thanks! | 10:07 |
| davidcalle | wligtenberg: np :) | 10:09 |
| gouchi | davidcalle: thank you for the info | 10:25 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === oparoz_ is now known as oparoz | ||
| === oparoz is now known as Guest42276 | ||
| === oparoz_ is now known as oparoz | ||
| === yofel_ is now known as yofel | ||
| _morphis | jdstrand: ping | 13:23 |
| ogra_ | pitti, i'm poking around with locales in snaps since the weekend ... do you have an idea why http://paste.ubuntu.com/16925059/ works in trusty but not in xenial (doesnt seem like the bindtextdomain function changed in gettext, so i dont get why it stopped working) | 13:27 |
| jdstrand | _morphis: hi! | 13:28 |
| _morphis | jdstrand: you had time to get the modem-manager interface another review round? | 13:29 |
| pitti | ogra_: not off the top of my head; xenial has a much newer glibc version, perhaps LOCALEDIR doesn't exist any more? it doesn't appear in strings libc.so.6 at least | 13:29 |
| jdstrand | _morphis: oh, I thought we were waiting on the ppp interface... is there more for me to review as it stands? | 13:29 |
| _morphis | abeato: as I said, deadlock :-) | 13:30 |
| ogra_ | pitti, well, the preloading of the bindtextdomain.so binary should simplay add it | 13:30 |
| _morphis | jdstrand: abeato is currently adding that but can you look at the other parts already? | 13:30 |
| ogra_ | it replaces the gettext function dues to the perloading | 13:30 |
| pitti | ah, it's from that | 13:30 |
| ogra_ | *pre | 13:30 |
| jdstrand | _morphis: ok | 13:31 |
| * ogra_ glares at his fingers | 13:31 | |
| _morphis | jdstrand: thanks | 13:31 |
| jdstrand | mvo: hi! iirc, you marked snapd 2.0.6 as verification-failed (for the systemd timer issue I think) | 13:40 |
| jdstrand | mvo: I don't believe 2.0.6 had home autoconnect in place (at least, I didn't see it in the changelog) | 13:41 |
| jdstrand | mvo: not sure what your plan was for the next xenial upload, but whatever it is, can you include the home autoconnect commit? | 13:41 |
| jdstrand | niemeyer_: fyi ^ | 13:42 |
| mvo | jdstrand: the plan is to do a new 2.0.7 today that fixes the systemd unit and also fixes an issue with nvidia | 13:46 |
| jdstrand | mvo: cool, so that sounds like it will have the commit since it was in last week. thanks! :) | 13:50 |
| mvo | jdstrand: yeah, once I get my two bugfix branches in I'm ready to release | 13:51 |
| niemeyer_ | jdstrand, mvo: +1 | 14:34 |
| mvo | jdstrand: do you remember if there was a bug associcated with home autoconnect | 14:41 |
| jdstrand | mvo: I don't think so. let me check something though | 14:43 |
| mvo | jdstrand: ta | 14:43 |
| jdstrand | ah there was | 14:43 |
| jdstrand | mvo: bug 1588886 | 14:44 |
| ubottu | bug 1588886 in Snappy "no indication that a user needs to connect the home Plug to the home Slot to make a snap access files in the homedir" [High,Fix committed] https://launchpad.net/bugs/1588886 | 14:44 |
| mvo | jdstrand: \o/ | 14:44 |
| === Aria22 is now known as Aria22|away | ||
| === Aria22|away is now known as Aria | ||
| didrocks | sergiusens: elopio: hey! I guess you saw that I fixed the unit tests btw! | 14:59 |
| elopio | didrocks: haven't seen that yet, but yay. I'll take a look after the meeting. | 14:59 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | didrocks yes, I'm still trying to get an archive admin to accept 2.10 into xenial-proposed though (I am a one thread person) :-P | 15:03 |
| didrocks | sergiusens: one thread? so much disappointment :) | 15:06 |
| ysionneau | Hi | 15:06 |
| sergiusens | didrocks yes, bureaucracy makes me go single thread ;-) | 15:06 |
| sergiusens | didrocks thanks btw | 15:07 |
| ysionneau | I'm trying to use "kernel-initrd-firmware" for kernel snaps | 15:07 |
| ysionneau | tldr: the firmwares do not end up being embedded in initrd | 15:07 |
| didrocks | sergiusens: yw! :-) | 15:08 |
| ogra_ | ysionneau, siunds like a bug in the kernel plugin | 15:09 |
| ogra_ | ysionneau, why do you need the firmware in the initrd though ... the initrd should only make sure you find your rootfs | 15:09 |
| ysionneau | http://pastebin.com/zV2Q8i31 <= | 15:09 |
| ogra_ | do you actually need any extra firmware for your disk controller ? | 15:09 |
| ysionneau | ogra_: my kernel seems to need the usb host controller FW very early | 15:10 |
| ysionneau | it doesn't work if it's in the rootfs | 15:10 |
| ysionneau | it works when it'sin the initrd | 15:10 |
| ysionneau | that's what we do on our proprietary firmware | 15:10 |
| ysionneau | s/on/in. | 15:10 |
| ogra_ | hmm | 15:10 |
| sergiusens | ysionneau this should just work, have you seen my 96boards example? | 15:11 |
| ogra_ | well, first of all, file a bug ... | 15:11 |
| ogra_ | looking at your paste it seems that some fw is actually installed | 15:11 |
| ysionneau | yes | 15:12 |
| ysionneau | I added some print() for shutil.copy | 15:12 |
| ysionneau | it's copied somewhere, but definetely not in the initrd | 15:12 |
| ysionneau | btw, the snapcraft.yaml http://pastebin.com/baN37dPF | 15:14 |
| ysionneau | maybe I should just stop using kernel-initrd-firmware and use the tar or copy plugin like sergiusens in 96boards ? | 15:14 |
| sergiusens | ysionneau all it does is select firmware already built and puts it in initrd | 15:15 |
| === Aria is now known as Aria22 | ||
| ogra_ | sergiusens, but does it copy full paths ? | 15:16 |
| ysionneau | weird because I've used the correct relative path and it does not end up in initrd | 15:16 |
| ogra_ | looks like ysionneau tries that in his snapcraft.yaml | 15:16 |
| sergiusens | ogra_ not full paths | 15:16 |
| ogra_ | right, thats what i thought | 15:16 |
| ysionneau | ah, ok I guess I understand, because of my ../../.. prefix, the fw don't end up in the correct destination directory | 15:17 |
| ysionneau | and don't get embedded | 15:17 |
| ysionneau | right? | 15:17 |
| netphreak | Hi, guys! when is snapd 2.0.6 ready for test? | 15:17 |
| sergiusens | ysionneau it should be relative to the part's installdir | 15:18 |
| ysionneau | sergiusens: I mean, my path is indeed a relative one, and it is indeed pointing to the correct files | 15:19 |
| ysionneau | so I should be OK | 15:19 |
| ysionneau | but I'm not :o | 15:19 |
| sergiusens | ysionneau yeah, relative as in 'firmware/bcm43602' | 15:19 |
| ysionneau | and by reading the code I understand why : https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/kernel.py#L248 | 15:20 |
| ysionneau | by looking at how dst is constructed | 15:20 |
| sergiusens | ysionneau or else we need to introduce a new key to say source->destination | 15:20 |
| sergiusens | ysionneau right now it is implied for the path in that list and that is where it lands | 15:20 |
| ysionneau | should I file a bug? or am I just doing things not supposed to work at all? | 15:20 |
| sergiusens | ysionneau you can log a bug if you manage to tell me how that firmware file is supposed to make it in initrd into the correct path within initrd | 15:22 |
| sergiusens | ysionneau I would use the organize keyword I guess | 15:22 |
| sergiusens | ysionneau or is this unmanaged source? | 15:22 |
| sergiusens | th organize keyword seems to be the way to go | 15:22 |
| alm_ | why am i SOL with my PI 3 without a 64bit ARM? | 15:22 |
| ogra_ | "SOL" ? | 15:24 |
| alm_ | Sh*t Outof Luck | 15:26 |
| dougb | Hello All--On BeagleBone Black, only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy? | 15:26 |
| ysionneau | sergiusens: I honestly don't know, or maybe by using the "copy plugin" like syntax | 15:28 |
| ogra_ | alm_, the only arm64 builds we have today are for the 96boards dragonboard ... and afaik not even broadcom plans to actually support arm64 on the pi3, you can use ubuntu-device-flash to roll armhf pi3 images today though | 15:28 |
| ysionneau | ogra_: you want to use arm64 kernel + armhf user space ? :) | 15:28 |
| ogra_ | ysionneau, what would be the benefit of that ? | 15:30 |
| sergiusens | ysionneau we want to kill the copy plugin syntax in favor of organize | 15:30 |
| ysionneau | sergiusens: I don't know what that is :/ | 15:30 |
| ogra_ | sergiusens, but everybody *loves* the copy plugin ! | 15:30 |
| sergiusens | ysionneau it shuffles bits around | 15:30 |
| sergiusens | ogra_ the plugin is staying, the syntax is going to be deprecated | 15:30 |
| ogra_ | (just teasing ;) ) | 15:31 |
| alm_ | yes and no - i need to install apache Cassandra db and found it challenging to say the least. Someone told me that i have to wait for a new kernel to be compiled for armel | 15:31 |
| elopio | fgimenez: can we skip today? | 15:31 |
| ysionneau | ogra_: dunno, rpi3 comes with armhf kernel when you buy it? | 15:31 |
| ogra_ | ysionneau, i think so, yes | 15:31 |
| fgimenez | elopio, sure, np | 15:31 |
| elopio | thanks. | 15:32 |
| === olli| is now known as olli | ||
| ogra_ | ysionneau, the only area where arm64 would actually be helpful would be if you have >3GB RAM really ... | 15:32 |
| ogra_ | or if you have to use binary blob drivers that are arm64 only ... | 15:33 |
| ogra_ | effectively 64bit binaries will be bigger and consumke more ram though ... so it is only helpful if you actually *have* more ram :) | 15:33 |
| ogra_ | (armhf can handle up to 3GB just fine) | 15:34 |
| alm_ | yes i see the point about ram..and since i don't have the >3GB..but i have been trying for 2 weeks to get it working trying every distro and ugh | 15:35 |
| ysionneau | so far we only compile our nvidia kernel as arm64, never tested as armhf | 15:35 |
| ysionneau | dunno if it even works :o | 15:35 |
| ysionneau | it's not upstream, it's nvidia code release | 15:35 |
| ysionneau | so most likely crappy code | 15:35 |
| ogra_ | i dont think the kernel cares actually | 15:36 |
| ysionneau | if the nvidia SoC device code is not 64/32 bit proof I guess you can have surprises | 15:37 |
| ogra_ | your userspace would fall over if you tried arm64 on an armhf only kernel, but never the other way round | 15:37 |
| ysionneau | note, I'm only talking about kernel here | 15:37 |
| ogra_ | right, whatever gets you booting :) | 15:37 |
| ysionneau | I know that I can use armhf user space, that's what I'm using in fact | 15:37 |
| ysionneau | but i'm just saying I never tried an armhf-toolchain compiled kernel on my 64 bit soc | 15:38 |
| ogra_ | :) | 15:38 |
| alm_ | going to try one more time tonight - and try snappy core - see if works | 15:39 |
| ogra_ | well, i dont think tegh kernel is actually picky in any way in that regard | 15:39 |
| ogra_ | alm_, well, there is no arm64 for the pi3 in snappy ... so you will have to live with armhf | 15:39 |
| alm_ | ya that's the trouble | 15:40 |
| * ogra_ doesnt get why | 15:40 | |
| alm_ | cause everytime i go to install says will not support the arch | 15:41 |
| ogra_ | "go to install" | 15:41 |
| ogra_ | what exactly do you try to install ? | 15:41 |
| ysionneau | alm_: do you use an arm64 kernel snap with an armhf ubuntu-core with ubuntu-device-flash ? | 15:41 |
| alm_ | yes - ysionneau - i dl from ubuntu..dont have all the info here as i am at work | 15:43 |
| alm_ | orga - the apache cassandra db | 15:43 |
| ysionneau | alm_: please, paste what you're doing, with the error message | 15:43 |
| ogra_ | well, you would have to create snap packages of that first if you want to use it under snappy | 15:43 |
| ogra_ | an armhf image that can run on the pi3 is at http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz | 15:44 |
| ogra_ | just uncompress it and dd it to an SD card ... then boot the board | 15:44 |
| ogra_ | (ignore the pi2 in the name, it runs fine on the pi3) | 15:44 |
| ogra_ | but then youz will still need to produce a cassandra/apache snap package for it to use it | 15:45 |
| ogra_ | (there is no apt or dpkg in snappy) | 15:45 |
| alm_ | dont have error or would post..somthing like can not find armhf arch.. | 15:46 |
| alm_ | thanks for this though..got to go | 15:47 |
| ogra_ | just come back again if you sit near the board :) | 15:47 |
| ogra_ | ah ... there he goes | 15:47 |
| ysionneau | sergiusens: so, I guess that if I use this https://github.com/ubuntu-core/snapcraft/blob/master/demos/96boards-kernel/snapcraft.yaml#L29 , it won't end up in initrd, right? :( | 15:48 |
| sergiusens | ysionneau no it would not | 15:49 |
| ysionneau | hmmm maybe I can just copy my firmware directory inside linux-x1/firmware | 15:50 |
| ysionneau | and use the normal kernel fw mechanism | 15:51 |
| sergiusens | elopio you are not on #ubuntu-release | 15:51 |
| elopio | I didn't know that was a thing. | 15:52 |
| === Aria22 is now known as Aria22|away | ||
| ogra_ | ysionneau, well, i think "kernel-initrd-firmware:" will just work if you give it the right options (full path to .bin files instead of declaring directories) | 15:59 |
| ogra_ | your issue is simply that you dont define the files but directories | 16:00 |
| ysionneau | ogra_: hmmm I don't think so, I've just tried, it does the same | 16:08 |
| ysionneau | the ../../.. prefix makes my file end up out of the initrd-staging directory | 16:08 |
| ysionneau | here is the os.link log : | 16:08 |
| ysionneau | os.link(/home/fallen/dev/packages/paros_kernel/parts/kernel/install/../../../firmware/tegra21x_xusb_firmware, /home/fallen/dev/packages/paros_kernel/parts/kernel/build/initrd-staging/../../../firmware/tegra21x_xusb_firmware) | 16:09 |
| ogra_ | ysionneau, and tegra21x_xusb_firmware is actually a file ? | 16:14 |
| ogra_ | also, where exactly does the firmware end up in your kernel snap (default path is /lib/firmware) | 16:15 |
| ysionneau | ogra_: yes | 16:19 |
| ysionneau | right now, the fw does not end up at all in the kernel snap | 16:19 |
| gnosys | hi all | 16:35 |
| gnosys | looking for a good discussion of environment variable configuration in the snapcraft.yaml file | 16:36 |
| gnosys | trying to work on building a snap for gimp-git as an alternative to the gimp-edge ppa | 16:36 |
| sethj | mhall119, is the snappy playpen today or tomorrow? The blog post says tomorrow, but the Google calendar on the G+ post you shared says today. | 16:52 |
| mhall119 | sethj: it is tomorrow | 16:55 |
| mhall119 | the calendar might be having timezone fun | 16:55 |
| sethj | Okay. Probably can't make it then :/ | 16:55 |
| sethj | mhall119, hah, must be. Although how it made that jump is beyond me. | 16:55 |
| mhall119 | hmm, it shows today for me too | 16:56 |
| mhall119 | I wonder if dholbach set it for midnight his time | 16:58 |
| mhall119 | is CET UTC+2? | 16:58 |
| mhall119 | yeah, I bet that's it | 17:00 |
| mhall119 | sethj: what time does it show for you? | 17:01 |
| sethj | mhall119, June 6th, 1500. | 17:01 |
| mhall119 | it shows 6pm today for me, which is 0:00 CEST | 17:01 |
| sethj | I'm in GMT-8 (or -7, I can't remember 'cause DST) | 17:01 |
| mhall119 | yeah, that looks to be what's happening | 17:02 |
| rharper | if one wanted to grant a snap access to a system dir in say var, is there a way to express that in snapcraft.yaml ? any examples would be helpful to this snapcraft noob | 17:43 |
| sethj | rharper, sounds like a job for an interface, but you might have to write your own. Take a read through zyga's nice 3 part blog series on them: Zygmunt Krynicki | 17:46 |
| sethj | oops, copy paste fail. Here's the link: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html | 17:46 |
| rharper | sethj: cool, I'll give that a read and see how far I get | 17:47 |
| rharper | sethj: thanks, I think the key for me was --devmode runs complain mode, but won't help a user do let's say root things. for example, I'll looking to read/write to a var dir which is owned by the system; are there any plans to work on an interface for those sorts of things? | 17:53 |
| sergiusens | rharper there is a content sharing interface in the pipeline, kyrofa I think will be working on it | 17:56 |
| sergiusens | rharper but I am not so sure this is intended for "writing" | 17:56 |
| rharper | right; I guess this would be more a long the lines of say firewall-control which would delegate some system level config to a trusted snap | 17:57 |
| kyrofa | sergiusens, rharper indeed, I agree, I'm not sure on the writing aspect, though it's not yet been spec'd | 17:57 |
| sergiusens | rharper then the matter gets interesting as in, are you looking into writing to a classic system (desktop) or the core snap itself | 17:57 |
| rharper | sergiusens: I'm playing around with cloud-init; which is already part of the os snap IIUC, which runs and inits some stuff; if it were to run as a snap and called via hooks, then it would be confined as a snap rather than running in the system | 17:58 |
| rharper | so I'm trying to poke on the various points in the system that cloud-init would like to (as it's current written) to muck with etc. all to help tease out which sorts of interfaces we might want to have for other "system config" style snaps that would have hooks called | 17:59 |
| sergiusens | rharper so cloud-init as a snap to run on a regular server install is what you are trying to do? | 18:00 |
| rharper | sergiusens: yeah, for now; | 18:00 |
| rharper | http://paste.ubuntu.com/17065056/ is as far as it goes, which runs into non-root wanting to poke at /var/lib/cloud/data | 18:00 |
| sergiusens | rharper if this is to get the seeds in place, have you considered being able to provide an alternate path for that? | 18:00 |
| rharper | cloud-init expects to run as root | 18:00 |
| rharper | sergiusens: that's possible, the cloud-init code owns that path but it could be changed if needed; | 18:01 |
| sergiusens | it can run as root, well, at least it believes it does, we're are slowly making our ways to the "root" role solaris once had | 18:02 |
| rharper | interesting | 18:02 |
| sergiusens | rharper if it can check for $SNAP_DATA it would be free to dump anything there | 18:02 |
| rharper | sergiusens: right; I think the integration might need to be deeper than that; rather, think of this as a gadget or os snap delegating configuration control to this snap; the data it generates likely wants to be retained in the gadget or os snap independent of the delegated snap itself | 18:03 |
| rharper | for example if you wanted to switch out the snap that runs the delegated hook for "configure networking" or whatever that hook may be | 18:04 |
| sergiusens | rharper yeah, that I cannot answer as lightly as the previous question :-) | 18:04 |
| sergiusens | rharper there's an interface for snapd management which could hook you into all that but I am far away from that problem space these days | 18:05 |
| rharper | yeah; I didn't expect there is an answer yet; I suppose next I'm wondering how much further one can explore on the snap app side | 18:06 |
| sergiusens | rharper I think Chipaca should be your goto person there, but he's off for today to bbq some meat I've been told | 18:06 |
| rharper | mmm, bbq | 18:06 |
| rharper | best excuse ever | 18:06 |
| sgclark | Hi all. I am making good progress on kde snaps, but I am haing issues with apparmor failures and home plug. Is there some good doc on how plugs actually work? I was under the impression home plug would allow acces the /home/user but that does not appear to be case. | 18:29 |
| sergiusens | sgclark it does indeed allow access to $HOME | 18:31 |
| sergiusens | sgclark what it doesn't do today but should be added soon is autoconnection | 18:31 |
| sergiusens | sgclark you can run `snap interfaces` to see what is currently connected | 18:31 |
| sgclark | ahh ok. | 18:32 |
| sergiusens | then just run `<snap>:<plug> <snap>:<slot>` | 18:32 |
| sgclark | it seems to create a snap directory in home but like for example digikam cannot access Pictures in home so I am confused | 18:33 |
| sergiusens | err `snap connect ...` | 18:33 |
| sgclark | ok | 18:33 |
| sergiusens | sgclark yeah, it is rather confusing, the only thing the app can see by default now (without home) is $HOME/snaps/<snap-name>/<snap-revision> | 18:34 |
| kyrofa | sgclark, that $HOME/snaps/<snapname>/<revision> directory is the $SNAP_USER_DATA environment variable for the snap | 18:35 |
| sgclark | ok but with home it should be able to see Pictures? what did I do wrong? | 18:35 |
| kyrofa | sgclark, can you pastebin the output of `snap interfaces` ? | 18:36 |
| jdstrand | sgclark: if you haven't yet, run: sudo snap connect <your snap name>:home ubuntu-core:home | 18:37 |
| jdstrand | and if that doesn't work, yes, give the output of 'snap interfaces' | 18:38 |
| sgclark | ok will do, thanks all | 18:38 |
| sgclark | Ok so that worked.. | 18:41 |
| sgclark | but expecting users to do that... lol | 18:41 |
| sgclark | anyway to auto achieve that? | 18:41 |
| kyrofa | sgclark, yeah it's in progress | 18:42 |
| sgclark | cool :) I accept that answer. | 18:44 |
| kyrofa | jdstrand, do the review tools currently allow spaces, colons, periods, or underscores in the app names? | 19:16 |
| jdstrand | nope | 19:16 |
| kyrofa | Nice, okay. That's what I was trying to ask in that bug-- same page now | 19:17 |
| jdstrand | kyrofa: http://bazaar.launchpad.net/~store-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/sr_common.py#L165 | 19:18 |
| jdstrand | that is for snap name, the next function is for app name | 19:19 |
| jdstrand | snapd and the review tools should definitely be made to agree on this point :) | 19:19 |
| kyrofa | Nice, okay that's pretty close | 19:19 |
| kyrofa | snapd won't allow a trailing hyphen (or two hyphens), nor will it allow a + | 19:20 |
| kyrofa | Actually the package name isn't quite right either | 19:20 |
| jdstrand | kyrofa: in either? | 19:20 |
| kyrofa | Indeed | 19:21 |
| jdstrand | ok, I can fix that | 19:21 |
| kyrofa | jdstrand, package name: ^[a-z](?:-?[a-z0-9])*$ | 19:21 |
| kyrofa | jdstrand, app name: ^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$ | 19:22 |
| jdstrand | ok | 19:22 |
| mhall119 | jdstrand: have you seen this before? File: /usr/bin/scmp_sys_resolver (read) | 19:29 |
| mhall119 | Suggestions: | 19:29 |
| mhall119 | * adjust snap to ship 'scmp_sys_resolver' | 19:29 |
| mhall119 | * adjust program to use relative paths if the snap already ships 'scmp_sys_resolver' | 19:29 |
| jdstrand | mhall119: snappy-debug? | 19:29 |
| jdstrand | mhall119: what is generating that? | 19:30 |
| mhall119 | jdstrand: plank, the Elementary dock | 19:32 |
| mhall119 | and yes, that output is from snappy-debug | 19:32 |
| mhall119 | Log: apparmor="ALLOWED" operation="file_mprotect" profile="snap.snappy-debug.security//null-/usr/bin/scmp_sys_resolver" name="/usr/bin/scmp_sys_resolver" pid=1589 comm="scmp_sys_resolv" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 19:33 |
| jdstrand | mhall119: that isn't plank | 19:34 |
| jdstrand | mhall119: profile="snap.snappy-debug.security... | 19:34 |
| mhall119 | oh, hmmm | 19:34 |
| jdstrand | mhall119: you can filter by specifying: snappy-debug scanlog plank | 19:35 |
| jdstrand | er | 19:35 |
| jdstrand | snappy-debug.security scanlog plank | 19:35 |
| jdstrand | mhall119: once 2.0.7 lands, log-observe will be fixed for snappy-debug btw (ie, you can run it without --devmode) | 19:36 |
| mhall119 | ok | 19:36 |
| mhall119 | jdstrand: ok, on to the next one: | 19:41 |
| mhall119 | Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1688" (uid=1000 pid=8133 comm="/snap/plank/100009/bin/plank ") interface="org.freedesktop.DBus" member="RequestName" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus) | 19:41 |
| mhall119 | also, is there any interface or setting that will let it read files from /usr/share/icons/? | 19:42 |
| jdstrand | mhall119: /usr/share/icons is allowed by unity7 | 19:51 |
| jdstrand | mhall119: the other denial is that it is trying to be a dbus service. that isn't allowed without creating an interface. I think this is likely it trying to create a well-known name for other apps to connect to it, but again, that isn't allowed. please file a bug with snapd-interface, but I don't know how that will be fixed in a generic way | 19:53 |
| jdstrand | mhall119: (what the app is doing is at odds with what the system design allows-- it is trying to create a session service for anything to use. snappy is about isolating apps and letting them connect in controlled ways) | 19:54 |
| jdstrand | there might be something we can do with attributes... please file a bug | 19:55 |
| qengho | Hi. Suppose I have a upstream that doesn't need building, just unpacking. How can I include that? | 19:56 |
| qengho | "nil" doesn't take a source. "copy" overwrites source to ".". | 19:56 |
| popey | qengho: see my flightgear fgdata part http://bazaar.launchpad.net/~popey/+junk/flightgear/view/head:/snapcraft.yaml | 19:57 |
| popey | should be able to put source: http://example.com/foo.tgz | 19:57 |
| popey | I _think_ | 19:57 |
| popey | maybe with source-type tar | 19:57 |
| qengho | Tar has a big warning that tells me I'm likely to be eaten by a grue. | 19:58 |
| qengho | tar contents plugin, that is. | 19:58 |
| popey | jdstrand: oh. | 19:58 |
| popey | er, qengho oh | 19:58 |
| qengho | I like tar_contents. It does what I think it should. | 19:59 |
| popey | jdstrand: for you though... http://paste.ubuntu.com/17071527/ - udev one first - is there anything I can do there, or does it really need patching in the upstream program? The pulse one I imagine is fixed in snapd at some point? | 19:59 |
| qengho | I get that un-tarring is built in to ever source: line, though. It's orthogonal. But JUST UNTAR sounds like "nil" functionality, and that hates source lines. | 20:00 |
| mhall119 | jdstrand: does the unity7 interface also give access to /usr/share/applications/? | 20:02 |
| jdstrand | popey: the first one is problematic. can you file a bug against the opengl interface adding the snapd-interface tag? | 20:03 |
| jdstrand | popey: with snapd 2.0.7 you can add 'pulseaudio' to your plugs | 20:03 |
| jdstrand | mhall119: no, that is almost always non-fatal though | 20:04 |
| popey | jdstrand: looking forward to that! | 20:06 |
| jdstrand | popey: I suspect your udev access may be non-fatal as well | 20:07 |
| popey | well, the app segfaults | 20:07 |
| popey | but I don't know why | 20:07 |
| jdstrand | that might be because of pulseaudio denials | 20:08 |
| popey | ah | 20:08 |
| popey | where do you want the bug filed? | 20:08 |
| popey | https://bugs.launchpad.net/snappy ? | 20:08 |
| jdstrand | the pulseaudio denials are fixed in 2.0.7 when you plugs: [ pulseaudio ] | 20:08 |
| popey | ok | 20:08 |
| jdstrand | for opengl, yes, https://bugs.launchpad.net/snappy | 20:09 |
| jdstrand | popey: are you on yakkety or xenial? | 20:09 |
| popey | xenial | 20:09 |
| jdstrand | yeah, 2.0.7 isn't in xenial-proposed yet | 20:09 |
| popey | k | 20:10 |
| jdstrand | let me get you some rules to workaround it | 20:10 |
| popey | done https://bugs.launchpad.net/snappy/+bug/1589671 | 20:10 |
| ubottu | Launchpad bug 1589671 in Snappy "apparmor failure on udev with opengl interface" [Undecided,New] | 20:10 |
| mhall119 | jdstrand: yeah, plank is a bit of an edge case, since it's a dock | 20:10 |
| jdstrand | popey: add this to /var/lib/snapd/apparmor/profiles/snap.your.app: http://paste.ubuntu.com/17071856/ (in between the {}) | 20:11 |
| jdstrand | popey: then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app | 20:12 |
| popey | ok | 20:12 |
| popey | jdstrand: ok, progress, no errors, but still segfaults :) | 20:16 |
| jdstrand | popey: then my job is done! :P | 20:19 |
| jdstrand | popey: note I left a question for you in the bug | 20:20 |
| jdstrand | popey: does mame work with --devmode? | 20:20 |
| jdstrand | this may be related to the opengl issues mvo and zyga have been working on (iirc) | 20:21 |
| popey | jdstrand: will i have to undo what you suggested I do to apparmor to test that? | 20:22 |
| jdstrand | popey: no. just do that from a terminal outside of the snap | 20:23 |
| jdstrand | popey: you are talking about the 'cat' command, right? | 20:23 |
| popey | no, you asked me if it works with --devmode | 20:23 |
| popey | not looked at the question on the bug | 20:23 |
| jdstrand | ah | 20:24 |
| jdstrand | popey: you have to uninstall, then install with --devmode | 20:24 |
| jdstrand | popey: if you do that, it will remove those changes, yes | 20:24 |
| popey | okay | 20:24 |
| popey | doing | 20:24 |
| popey | jdstrand: well, i get no errors now with --devmode | 20:26 |
| popey | (but still the segfault ㋛ ) | 20:27 |
| popey | jdstrand: added output of cat to bug | 20:31 |
| jdstrand | right, so it is probably the opengl issue that mvo and zyga are (I think) working through | 20:31 |
| jdstrand | (as a guess) | 20:31 |
| popey | sweet | 20:31 |
| * popey leaves that with you | 20:32 | |
| sabdfl | hello all | 20:51 |
| sabdfl | great to see 200 folks here :) | 20:51 |
| vejmarie | good evening everybody, I just have a quick question does snap distribution is integrated within ubuntu-software GUI ? | 21:41 |
| vejmarie | Or does the GUI is still "deb" dependant | 21:41 |
| kallisti5 | "Building images for ubuntu-core 16.04 will be supported by this tool soon. | 22:41 |
| kallisti5 | :-D | 22:41 |
| kallisti5 | any preview versions of the tool that supports making an ubuntu-core image | 22:41 |
| kallisti5 | https://people.canonical.com/~mvo/all-snaps/ | 22:44 |
| kallisti5 | :-DF | 22:44 |
| ayan | is there a way to write a plugin that extends an existing plugin (like nil or copy)? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!