| wililupy | I usually do that latter with sudo ./ubuntu-device-flash core 16 --channel=edge --gadget=canonical-pc --kernel=canonical-pc-linux --os=ubuntu-core -o ubuntu-core-16.img | 00:01 |
|---|---|---|
| qengho | wililupy: It sounds like your "su" method to become root is not running as a login shell, and so not reading /etc/profile to set PATH to find snaps. | 00:01 |
| qengho | wililupy: compare $PATH from two environments. | 00:02 |
| wililupy | Thanks qengho. I started digging into it some more and I have some other issues with the snap as well. Upstart seems to not like it either and it's not loading the services properly. | 00:02 |
| qengho | It? snapd? | 00:02 |
| wililupy | the snap has a service that runs for console redirection and ASIC driver communication with kernel drivers. | 00:03 |
| wililupy | When I run the console command to get into the ASIC programming console, I get an error Unable to connect to Upstart: Failed to connect to socket com/ubuntu/upstart: Connection Refused | 00:05 |
| wililupy | If I try to run sudo snap.console it says command not found, but if I run it from /snap/bin I get the above error about Upstart and a missing file that I have never heard of. | 00:06 |
| wililupy | ...Gremlins.... | 00:06 |
| qengho | wililupy: what file? | 00:10 |
| fusion809 | My atom-fusion package still doesn't seem to be publicly available for download. I uploaded it to the store 16 hours ago. Anyone have any ideas how I can make it available? I took a screenshot of its publish history if that helps http://i.imgur.com/gYJWbap.png | 00:12 |
| qengho | fusion809: installing from same machine as where you built it? | 00:14 |
| fusion809 | Installing it isn't the problem, it's getting the package available from the official snap repository. | 00:14 |
| fusion809 | I am installing it just fine, and I'm working on Arch Linux so that's a feet in itself. | 00:15 |
| fusion809 | feat^ | 00:15 |
| qengho | fusion809: yep. Are you installing on the same machine as where you built? | 00:16 |
| fusion809 | I built it in a Docker container (for Ubuntu 16.04) that I'm running on the same machine as where I installed it. | 00:17 |
| qengho | fusion809: is that the same architecture? Not amd64 vs i486? | 00:17 |
| fusion809 | AMD64, I'm pretty sure Docker doesn't even run on 32-bit platforms, nor does it provide containers for 32-bit systems | 00:18 |
| qengho | fusion809: what's the name? | 00:18 |
| qengho | "atom-fusion" | 00:19 |
| qengho | ? | 00:19 |
| fusion809 | Exact snap package name is atom-fusion_1.8.0_amd64.snap. So yeah atom-fusion is the package's name | 00:19 |
| qengho | fusion809: it can take a few minutes to publish, but there could be something wrong. At bottom, file a bug report. | 00:24 |
| fusion809 | It's been 16 hours, so yeah probably need a bug report. | 00:24 |
| wililupy | qengho: /usr/sbin/console.fp | 00:35 |
| fusion809 | Done reporting the bug https://bugs.launchpad.net/snapcraft/+bug/1594622 | 00:37 |
| ubottu | Launchpad bug 1594622 in Snapcraft "Package Uploaded via web browser not being added to public repository" [Undecided,New] | 00:37 |
| wililupy | qengho: I'm going to try rebuilding my snap with confinement: devmode to see if I can get more logs. | 00:37 |
| wililupy | qengho: Thank you so much! | 00:38 |
| qengho | wililupy: Are you acessing $SNAP/usr/bin/console.fp? | 00:40 |
| qengho | wililupy: I think that's your problem. /something instead of $SNAP/something . | 00:49 |
| johnsel | hey | 01:15 |
| johnsel | anyone around? | 01:15 |
| tsimonq2 | o/ | 01:16 |
| tsimonq2 | !help | johnsel | 01:16 |
| ubottu | johnsel: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience | 01:16 |
| tsimonq2 | :) | 01:16 |
| johnsel | alright, fair enough | 01:16 |
| johnsel | ./openvpn: error while loading shared libraries: libpkcs11-helper.so.1: cannot open shared object file: No such file or directory, any clues? | 01:17 |
| johnsel | it's in the snap itself | 01:17 |
| johnsel | at ./usr/lib/x86_64-linux-gnu/libpkcs11-helper.so.1 | 01:17 |
| tsimonq2 | hmm weird | 01:18 |
| tsimonq2 | johnsel: stick around, maybe someone else has a better answer :) | 01:18 |
| johnsel | I will, meanwhile I'm going to try and compile it from source | 01:18 |
| johnsel | See if that helps | 01:18 |
| sergiusens | elopio hey, what is the easiest way to debug the fake servers? Seeing this https://github.com/ubuntu-core/snapcraft/pull/584 | 02:20 |
| === zeroedout_ is now known as zeroedout | ||
| elopio | sergiusens: could you paste the error? | 02:31 |
| tsimonq2 | elopio: could you look at my PR again? | 02:38 |
| elopio | tsimonq2: I can review it tomorrow. | 02:54 |
| tsimonq2 | elopio: thank you :) | 02:57 |
| qengho | tsimonq2: are you running the tests locally, for your subversion patch? | 03:47 |
| tsimonq2 | qengho: yeah, but I can't figure it out | 03:50 |
| tsimonq2 | qengho: see anything I'm missing? | 03:52 |
| === cpaelzer_ is now known as cpaelzer | ||
| === chihchun_afk is now known as chihchun | ||
| seb128 | hey there | 06:42 |
| seb128 | does anyone know if it's possible to tell snapcraft to stage some packages from a ppa or a local dir? | 06:43 |
| qengho | seb128: not possible, last time I checked. | 06:48 |
| seb128 | qengho, thanks, I'm going to file a bug against snapcraft I guess | 06:49 |
| qengho | seb128: while you're at it, please ask for APT-like source semantics. foo=version, foo/release, with whatever you think is best for PPA and whatnot. Maybe "foo@ppadescription" | 06:54 |
| didrocks | hum, if I remember some discussion, snapcraft was supposed to take your source.list | 06:54 |
| didrocks | and so, yours ppa | 06:54 |
| didrocks | instead of rewriting it | 06:54 |
| didrocks | that was in february | 06:54 |
| didrocks | (however, that ofc, won't work in cleanbuild or launchpad, which is an issue) | 06:54 |
| qengho | It does, didrocks, but that only works for your machine. the yaml isn't very portable. | 06:54 |
| didrocks | right! | 06:55 |
| seb128 | good enough for today, I'm going to play with that, but first coffee | 06:56 |
| zyga | o/ | 07:12 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | hey hey | 07:22 |
| tsimonq2 | hey it's dholbach! o/ | 07:23 |
| tsimonq2 | dholbach: how are you? | 07:23 |
| dholbach | hey hey - doing well - how about you? :-) | 07:24 |
| tsimonq2 | qengho: do we have a Chromium snap? | 07:24 |
| tsimonq2 | dholbach: awesome :) | 07:24 |
| qengho | tsimonq2: Yes. Its security policies are almost available, and it works pretty well in devmode. | 07:26 |
| tsimonq2 | qengho: do you have code somewhere that I could take a peek at? | 07:28 |
| seb128 | hey dholbach | 07:32 |
| dholbach | salut seb128 | 07:32 |
| qengho | tsimonq2: Well, the recent parts will be in snapd, but the snapcraft that uses it will be something like https://code.launchpad.net/~chromium-team/chromium-browser/snappy-packaging | 07:36 |
| tsimonq2 | oh cool, thanks qengho :) | 07:44 |
| ogra_ | hmm, whern i use the mak plugin, shouldnt snapcfat clean call make clean ? | 09:14 |
| ogra_ | *snapcraft | 09:14 |
| zyga | ogra_: make clean make :) | 09:15 |
| zyga | my faviourite solution to WTF issues | 09:15 |
| ogra_ | zyga, well, i want snapcraft to clean up when i call clean | 09:15 |
| zyga | yeah | 09:16 |
| === iahmad is now known as iahmad_ | ||
| === iahmad_ is now known as iahmad | ||
| qengho | hmm, is discarding the build dir enough? | 09:24 |
| tsimonq2 | !info python-magic | 09:41 |
| ubottu | python-magic (source: file): File type determination library using "magic" numbers (Python bindings). In component universe, is extra. Version 1:5.25-2ubuntu1 (xenial), package size 5 kB, installed size 53 kB | 09:41 |
| tsimonq2 | \o/ | 09:41 |
| matteo | hiall | 10:00 |
| tsimonq2 | hello matteo :) | 10:01 |
| tsimonq2 | !info gplugin | 10:10 |
| ubottu | Package gplugin does not exist in xenial | 10:10 |
| tsimonq2 | !info gplugin-dev | 10:11 |
| ubottu | Package gplugin-dev does not exist in xenial | 10:11 |
| tsimonq2 | :( | 10:11 |
| tsimonq2 | !info help2man | 10:26 |
| ubottu | help2man (source: help2man): Automatic manpage generator. In component universe, is optional. Version 1.47.3 (xenial), package size 108 kB, installed size 420 kB | 10:26 |
| tsimonq2 | \o/ | 10:26 |
| tsimonq2 | !info gobject-introspection-1.0 | 10:32 |
| ubottu | Package gobject-introspection-1.0 does not exist in xenial | 10:32 |
| tsimonq2 | !info gobject-introspection' | 10:32 |
| ubottu | gobject-introspection (source: gobject-introspection): Generate interface introspection data for GObject libraries. In component main, is optional. Version 1.46.0-3ubuntu1 (xenial), package size 261 kB, installed size 1412 kB | 10:32 |
| tsimonq2 | !info default-mta | 10:47 |
| ubottu | Package default-mta does not exist in xenial | 10:47 |
| tsimonq2 | !info mail-transport-agent | 10:47 |
| ubottu | Package mail-transport-agent does not exist in xenial | 10:47 |
| tsimonq2 | grr | 10:47 |
| tsimonq2 | !info urlview | 10:47 |
| ubottu | urlview (source: urlview): Extracts URLs from text. In component universe, is optional. Version 0.9-20 (xenial), package size 19 kB, installed size 65 kB | 10:47 |
| tsimonq2 | !info aspell | 10:47 |
| ubottu | aspell (source: aspell): GNU Aspell spell-checker. In component main, is optional. Version 0.60.7~20110707-3build1 (xenial), package size 77 kB, installed size 360 kB | 10:47 |
| === hikiko is now known as hikiko|ln | ||
| tsimonq2 | mvo: hey, I'm trying to make a mutt snap and I'm getting thrown a build error, would you be able to test if my snap works locally? dholbach says that you use mutt. https://github.com/ubuntu/snappy-playpen/pull/98 | 11:28 |
| === chihchun is now known as chihchun_afk | ||
| mvo | tsimonq2: mutt! | 11:45 |
| mvo | tsimonq2: \o/ | 11:45 |
| ogra_ | heh | 11:46 |
| tsimonq2 | mvo: I'm going to bed, weird sleep schedules, so if you have any suggestions, comment on the PR | 11:47 |
| tsimonq2 | but yes, mutt! \o/ | 11:47 |
| tsimonq2 | :P XD | 11:47 |
| tsimonq2 | o/ | 11:47 |
| mvo | tsimonq2: will do. mutt! I'm excited :) I love my mutt | 11:47 |
| seb128 | is that known that a "cp -a" triggers an invalid syscall under restricted snaps? | 11:47 |
| === hikiko|ln is now known as hikiko | ||
| kyrofa | seb128, yeah, chown I think | 11:54 |
| seb128 | kyrofa, is that a bug or a feature? | 11:55 |
| kyrofa | seb128, I assumed a feature, but jdstrand would know more | 11:55 |
| seb128 | k | 11:55 |
| seb128 | kyrofa, thanks for your replies on the channel btw ;-) | 11:57 |
| kyrofa | seb128, haha, of course! | 11:58 |
| ogra_ | kyrofa, do you have an idea why snapcraft clean doesnt trigger a make clean call when using the make plugin ? | 11:59 |
| kyrofa | Who's stealing all the armhf and arm64 launchpad builders!? | 11:59 |
| ogra_ | i kind of expected it would | 11:59 |
| ogra_ | kyrofa, doko most likely | 11:59 |
| kyrofa | ogra_, because it's not the smart :( | 11:59 |
| kyrofa | ogra_, remember make isn't the only build system it supports | 11:59 |
| ogra_ | ah | 11:59 |
| kyrofa | ogra_, its version of cleaning the source is to blow it away | 12:00 |
| kyrofa | ogra_, since that was the shortest path to success | 12:00 |
| ogra_ | right ... my makefile copies something to ../src | 12:00 |
| kyrofa | ogra_, I full intend on making that better | 12:00 |
| kyrofa | fully* | 12:00 |
| ogra_ | which i would like to clean along | 12:00 |
| kyrofa | Agreed. It would also be awesome if it actually noticed changes to the source | 12:00 |
| kyrofa | And just ran make again | 12:00 |
| ogra_ | yeah | 12:00 |
| kyrofa | But I need to come up with a generic way to do that for all build systems | 12:01 |
| kyrofa | Something that can be extending via local plugins | 12:01 |
| seb128 | is there a way to do the pull/build again on some parts and not others? | 12:01 |
| kyrofa | seb128, yeah, but the inconsistency would be confusing | 12:01 |
| seb128 | like to not redo a full source build everytime just because you changed the wrapper or the stage packages | 12:01 |
| matteo | anyone here with a 32 bit distro? | 12:01 |
| ogra_ | stop building that giant stuff :P | 12:01 |
| seb128 | matteo, _o/ | 12:02 |
| matteo | seb128: http://pastebin.ubuntu.com/17638846/ | 12:02 |
| matteo | can you run this? | 12:02 |
| kyrofa | seb128, yeah that should be possible. You have to rebuild the part on which you changed the stage packages though... no way around that I don't think | 12:02 |
| kyrofa | seb128, if you have stage packages on a part that's building something, and it doesn't actually need or use the stage packages, you might be better off putting those stage packages in their own part, even if using the nil plugin | 12:03 |
| seb128 | kyrofa, right, that's fine, it's "deb" part ... how do I do that? how do I tell it to repull the debs part only? | 12:03 |
| kyrofa | seb128, yeah it's not that fine-grained. The stage packages are pulled during the pull step | 12:04 |
| kyrofa | Along with the source code | 12:04 |
| seb128 | can I pull only one part? | 12:04 |
| kyrofa | seb128, so you might want to have them in separate parts | 12:04 |
| kyrofa | seb128, oh certainly! | 12:04 |
| kyrofa | seb128, `snapcraft pull <part>` | 12:04 |
| kyrofa | seb128, that applies to all steps: `snapcraft build <part>` | 12:04 |
| kyrofa | seb128, `snapcraft clean <part> --step=build` | 12:04 |
| seb128 | ah | 12:05 |
| kyrofa | seb128, note that "snap" is not a valid step though, since it's what creates the image. i.e. `snapcraft snap <part>` is not a valid command | 12:05 |
| seb128 | kyrofa, thanks, seems obvious now the mention it, I sort of got lost between the steps and parts for some reason | 12:06 |
| kyrofa | seb128, heh, no problem. Our `help` could probably use a little love | 12:07 |
| seb128 | matteo, is there anything specific you are looking for/any error you hit? that's just on a normal system or under snappy? xenial? | 12:08 |
| matteo | seb128: does it download the whole file? | 12:10 |
| matteo | normal system | 12:10 |
| matteo | seb128: I get this: http://pastebin.ubuntu.com/17639303/ | 12:12 |
| killua99 | snappy on arc isn't full supported yet, right ? | 12:30 |
| ogra_ | killua99, zyga should be able to tell you | 12:31 |
| killua99 | I mean the arc aur package did install. I did just install krita over snap, but I can't find the app :D | 12:32 |
| ogra_ | you might need to re-login after installing snapd ... it ships an /etc/profile.d snippet to enhance your PATH | 12:33 |
| ogra_ | though krita also has a .desktop file, if you use some desktop with menu, it should show up there too | 12:33 |
| kyrofa | killua99, indeed, as ogra mentioned /snap/bin needs to be in your PATH | 12:33 |
| ogra_ | ogra@styx:~$ which krita | 12:34 |
| ogra_ | /snap/bin/krita | 12:34 |
| ogra_ | thats what i get on ubuntu | 12:34 |
| ogra_ | i would assume arch does something like that too | 12:34 |
| ogra_ | unless zyga didnt finish up that part yet | 12:34 |
| killua99 | aha, re-login might be the missing part. Thanks ogra_ I'll try that later ;D | 12:34 |
| jdstrand | ayan (and Chipaca): re seccomp syscall-- yes, in 2.0.9 | 12:35 |
| * Chipaca hugs jdstrand | 12:35 | |
| Chipaca | wb dude | 12:35 |
| sergiusens | good morning | 12:37 |
| jdstrand | tedg: snap-confine-- that is precisely it. 1.0.30 in yakkety will have all the fixes. xenial will once zyga/mvo transitions to snap-confine. I think that is imminent | 12:37 |
| Chipaca | hey sergiusens, 'sup | 12:37 |
| seb128 | matteo, seems to always return 64823296 here compiled or not | 12:38 |
| jdstrand | seb128, kyrofa: chown is bug #1581310. will be fixed with seccomp arg filtering | 12:38 |
| ubottu | bug 1581310 in snapd (Ubuntu) "ubuntu-core doesn't allow sed -i (fchown syscall)" [Medium,Triaged] https://launchpad.net/bugs/1581310 | 12:38 |
| jdstrand | well, fixed for many apps | 12:39 |
| kyrofa | jdstrand, excellent, thank you :) . How far out is argument filtering, by the way? That will solve many issues | 12:39 |
| sergiusens | didrocks qengho seb128 launchpad builders allow you to setup PPAs for the build | 12:39 |
| seb128 | jdstrand, ah ok, thanks | 12:39 |
| sergiusens | and yes, ppa support for cleanbuild is the only thing really missing | 12:39 |
| === dpm_ is now known as dpm | ||
| kyrofa | Morning sergiusens! | 12:39 |
| seb128 | sergiusens, k, good to know, I didn't even know that snapcraft was using the system config | 12:40 |
| seb128 | sergiusens, is there any way to give it a specific apt config? | 12:40 |
| jdstrand | kyrofa: waiting for (hopefully) final review from tyhicks. things got pushed back due to holidays and sprint | 12:43 |
| Chipaca | matteo: can you also print err in that program? ie the last line, make it fmt.Printf("%d copied; %v\n", n, err) | 12:43 |
| kyrofa | jdstrand, awesome :) | 12:43 |
| sergiusens | seb128 not today; I went back and forwars with Colin on this some time ago and we agreed to make it an out of snapcraft thing | 12:43 |
| sergiusens | although for cleanbuild it would need to be supported | 12:44 |
| jdstrand | seb128: there is a workaround. snappy-debug tells you to do: cp -r --preserve=mode | 12:44 |
| * jdstrand hugs Chipaca back :) | 12:46 | |
| sergiusens | kyrofa how is it going? | 12:46 |
| kyrofa | sergiusens, not bad, how was the extended weekend? | 12:47 |
| ogra_ | have you been fathering a lot ? | 12:49 |
| seb128 | jdstrand, thanks, I don't know about snappy-debug, I should give it a try :-) | 12:49 |
| jdstrand | sudo snap install snappy-debug | 12:49 |
| jdstrand | sudo /snap/bin/snappy-debug.security scanlog | 12:50 |
| jdstrand | that will tail /var/log/syslog, dereference syscalls and make suggestions | 12:50 |
| seb128 | k | 12:50 |
| jdstrand | (and first run will tell you the proper snap connect command to run | 12:50 |
| jdstrand | ) | 12:50 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | kyrofa turns out I had the flu for 2 weeks and did not notice until the weekend when some dry coughing kicked in :-P | 12:54 |
| kyrofa | sergiusens, blech, so a lovely extended weekend then | 12:55 |
| sergiusens | it was good still ;-) | 12:55 |
| ayan | jdstrand: sorry -- what do you mean by 'yes'? | 12:59 |
| jdstrand | ayan: yesterday someone asked if the seccomp syscall is allowed. the answer is 'yes' in 2.0.9 | 13:00 |
| ayan | jdstrand: ah, okay. is 2.0.9 available now? | 13:00 |
| jdstrand | ayan: it is released, yes. If you are using Ubuntu, it is in xenial-proposed | 13:01 |
| jdstrand | https://launchpad.net/ubuntu/+source/snapd/2.0.9 | 13:01 |
| matteo | Chipaca: it's nil | 13:02 |
| matteo | Chipaca: sorry | 13:03 |
| matteo | 34651558 copied, err: unexpected EOF | 13:03 |
| Chipaca | matiasb: there you go | 13:04 |
| matteo | but, why EOF? | 13:07 |
| seb128 | jdstrand, mvo, do you know if anyone gave some consideration on letting snaps claiming mimetypes and how that could work? | 13:26 |
| joc_ | zyga: hi, can you provide any advice for debugging an interface which includes udev snippets? are the snippets stored in a file somewhere when they are registered? | 13:27 |
| jdstrand | seb128 (and mvo): I think someone mentioned it at some point as something we'd want to support in the future. I think that needs proper design. I can sort of see it as an extension to interfaces, but we'd likely need to coordinate with tvoss or others from personal since they have something similar in url-dispatcher | 13:28 |
| seb128 | jdstrand, mvo, would you see an objection on running update-desktop-database on /var/lib/snapd/desktop/applications so applications show as handler in e.g nautilus on unity7? maybe as a temporary thing until we figure out something better | 13:30 |
| jdstrand | seb128: otoh, I would, yes. that is too automagical since the snaps could take over mime handling and that should be an explicit choice. I suspect I'll be overruled on that | 13:32 |
| jdstrand | that gets back to design | 13:32 |
| zyga | joc_: hi | 13:33 |
| jdstrand | the design should involve discussion regarding how to transition to the new system | 13:33 |
| zyga | joc_: yes, they end up in /etc/udev/rules.d | 13:33 |
| seb128 | jdstrand, the mailing list would be the right place to start that discussion I guess? | 13:33 |
| jdstrand | seb128: I'm not sure. I guess. it depends on if people feel it should be an interface. I guess the mailing list and then someone might ask to file a bug | 13:34 |
| seb128 | k, thanks | 13:34 |
| jdstrand | seb128: you might want to wait for mvo to respond though | 13:34 |
| seb128 | I'm getting close from a working evince | 13:35 |
| jdstrand | I'm not necessarily up on all the latest decisions | 13:35 |
| seb128 | like I've it opening pdf even in restricted mode | 13:35 |
| jdstrand | nice | 13:35 |
| seb128 | but it's a bit less useful if you can't double click on documents | 13:35 |
| seb128 | like if you need to start evince from the dash and then browse to the file you want | 13:35 |
| Chipaca | seb128: well, there is the xdg-open thing | 13:37 |
| Chipaca | seb128: which is a toe in the water | 13:37 |
| seb128 | Chipaca, the xdg-open things is the other way around though, right? | 13:38 |
| Chipaca | seb128: ah! | 13:38 |
| seb128 | having code from inside the snap calling e.g your system browser | 13:38 |
| Chipaca | seb128: that's what happens when i skim the backlog and try to be helpful :-) | 13:38 |
| seb128 | lol | 13:38 |
| seb128 | thanks for the reply though ;-) | 13:38 |
| joc_ | zyga: the system /etc/udev/rules.d i.e. not just from the confined app's perspective? | 13:39 |
| zyga | joc_: yep, the real one | 13:40 |
| zyga | joc_: if we put udev rules in place we reload udev and re-trigger the rules | 13:40 |
| zyga | joc_: so you should see stuff happening | 13:41 |
| joc_ | hmm, not sure why i'm not seeing anything | 13:44 |
| === chihchun is now known as chihchun_afk | ||
| seb128 | jdstrand, so mime handling would be nice, but my real blocker is dconf atm I think ... do you still have that one on your todolist? | 14:05 |
| mvo | seb128: sounds ok | 14:05 |
| jdstrand | seb128: I am not actively working on that. there are 3 parts: 1) create a global gsettings interface that allows access to the global db by the sandbox (assigned to me, I did that) 2) gsettings apparmor backend-- multiple teams, in progress, behind a couple other things wrt security team) 3) making a snap find and use gsettings at all (ie, the HOME issue) | 14:07 |
| jdstrand | seb128: '3' is what you need. that seems to me to be a snappy team and/or desktop team thing (ie, it has nothing to do with the sandbox and I have no insight as to the proper fix) | 14:08 |
| jdstrand | maybe it is a snapcraft thing | 14:08 |
| seb128 | jdstrand, I can figure 3 out but we also need access to the system XDG_RUNTIME_DIR | 14:08 |
| * jdstrand isn't sure | 14:08 | |
| seb128 | jdstrand, which is where I'm blocking | 14:09 |
| seb128 | I don't even know if it's ok from a security point of view | 14:09 |
| jdstrand | are you saying the sandbox is blocking access to the XDG_RUNTIME_DIR? is there a bug for the system XDG_RUNTIME_DIR? | 14:09 |
| jdstrand | what is that dir? | 14:09 |
| seb128 | jdstrand, XDG_RUNTIME_DIR=/run/user/1000 | 14:11 |
| seb128 | jdstrand, I get a permission denied when I try to access /run in a confined snap | 14:11 |
| jdstrand | seb128: what is the apparmor denial? | 14:11 |
| seb128 | l[30316.913854] audit: type=1400 audit(1466518291.070:296): apparmor="DENIED" operation="open" profile="snap.gnome-logs-udt.gnome-logs-udt" name="/run/user/1000/" pid=9158 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 14:11 |
| jdstrand | well, that is for 'ls' | 14:12 |
| jdstrand | but what is the denial when you use gsettings? | 14:12 |
| jdstrand | becuase we allow access to /{,var/}run/user/*/dconf/user already in the gsettings plug | 14:13 |
| didrocks | jdstrand: hey! Small question/remark/needs your brain. We are thinking about introducing best practices for shaping snapcraft.yaml for our developers via some rules set (order of stenzas, and so on). This tool would be a linter which may be extended as an helper for IDE for autocomplete as well. | 14:13 |
| didrocks | so it means it needs to be fast to execute (as autocomplete on temporary file in the IDEs) and work on snapcraft.yaml source | 14:14 |
| seb128 | jdstrand, ok, I think I just got confused and assumed that if I couldn't ls to it it was not available, I see no deny | 14:14 |
| seb128 | jdstrand, I'm going to try to figure out 3) then, sorry for the nois | 14:14 |
| seb128 | jdstrand, and thanks for the replies! | 14:14 |
| jdstrand | seb128: np | 14:14 |
| didrocks | I was first thinking about about the click-reviewer-tools (that we will integrate on package built from the ide ofc), but I'm a little bit more vary on using/extending it for snapcraft.yaml + introducing our best practice rule then | 14:14 |
| didrocks | having some experience on linter written in python integrated in IDE and their speed… wdyt? | 14:15 |
| jdstrand | didrocks: I think the tools could be extended to read a specific snapcraft.yaml on the fs and run fast enough | 14:16 |
| didrocks | jdstrand: so you would probably be in favor of us going that road instead of trying to get something in go? | 14:16 |
| jdstrand | didrocks: the thing that can be slow now is unpacking the snap, going through all the files, etc. just parsing snapcraft.yaml would be fast | 14:17 |
| jdstrand | didrocks: yes-- otherwise the test will diverge and maintenance would be a problem | 14:17 |
| jdstrand | tests* | 14:17 |
| didrocks | jdstrand: yeah, but it means for every character typed in the IDE, the python interpretor would be executed by the IDE plugin | 14:17 |
| didrocks | (for autocomplete for instance) | 14:17 |
| jdstrand | it is already hard enough keeping snapcraft and the tools in sync. adding another thing would be hard | 14:17 |
| didrocks | yeah, that's why I prefer talking about it to you beforehand :) | 14:18 |
| jdstrand | didrocks: hmmm, for every character? that sounds slow now matter how you do it. I mean, if you could keep the interpreter running, then it would be fast, but invoking the interpreter over and over will likely be too slow | 14:18 |
| didrocks | jdstrand: I'm afraid that out extending most of IDEs are working though | 14:19 |
| didrocks | that's* how | 14:19 |
| didrocks | but in theory, you have nothing against us extending the click-reviewer-tool for those functionality? (parsing snapcraft.yaml + introducing autocomplete) | 14:19 |
| didrocks | functionalities* | 14:20 |
| jdstrand | I do not-- it has a ton of lint tests already | 14:20 |
| didrocks | jdstrand: great! the LP project is still the main branch, right ? (nothing on github?) | 14:21 |
| jdstrand | how to integrate would be the interesting bit | 14:21 |
| jdstrand | all LP | 14:21 |
| didrocks | yeah, I'll have a look on some ides and how this works, but from a quick look, it's similar to what you do with the tool already: returning some json (where you have the line number…) | 14:22 |
| jdstrand | you'd need to extend that part. we don't track line number-- we track by key/value | 14:22 |
| didrocks | yeah, but I think it's another binary anyway | 14:23 |
| jdstrand | (not that line number would be difficult to add) | 14:23 |
| didrocks | as it's not meta.yaml | 14:23 |
| didrocks | by another file, with other rules (some are commons) | 14:23 |
| jdstrand | you might want to create a 4th category-- 'bestproactice' or something. error, warn and info are likely not enough for what you need (something between info and warn) | 14:23 |
| didrocks | indeed | 14:24 |
| didrocks | I'll have a look in the next days and keep you posted! | 14:24 |
| didrocks | thanks for your feedback :) | 14:24 |
| jdstrand | np | 14:24 |
| matteo | zyga: maybe I have found the download issue | 14:37 |
| zyga | matteo: yes? what is it? | 14:40 |
| matteo | the connection is resetted when the network is faster than the disk | 14:41 |
| swartzr | I'm trying to run a snappy app as a service account but get the following message: failed to create user data directory. errmsg: Permission denied. Anybody have a workaround? | 14:48 |
| zyga | re | 14:55 |
| zyga | swartzr: re | 14:55 |
| zyga | swartzr: so can you tell me more about your issue | 14:56 |
| swartzr | zyga: installed a snap that I built on one of our servers although the service account that will run it (jenkins) throws that error message when it tries to run it. | 14:57 |
| swartzr | I looked in jenkin's home directory and i see a snap directory so I assume it is created successfully | 14:58 |
| === ratliff_ is now known as ratliff | ||
| joc_ | abeato: i take it you tested that the udev rules were definitely be created for modem-manager? | 15:03 |
| abeato | joc_, yep | 15:03 |
| zyga | swartzr: can you tell me what the error is in more detail | 15:06 |
| zyga | swartzr: what is the host? (where does snapd run) | 15:06 |
| joc_ | abeato: do you have an amd64 snap i can install? looks like your recent builds failed | 15:08 |
| abeato | hmm, weird | 15:09 |
| swartzr | zyga: The host is an ubuntu server 16.04 x86_64 when i run the snap via /snap/bin/ftptransfer I get the message: "failed to create user data directory. errmsg: Permission denied" nothing more | 15:10 |
| swartzr | zyga: the snap is also installed in devmode | 15:11 |
| abeato | joc_, http://people.canonical.com/~abeato/snappy/modem-manager_1.4.0-1_amd64.snap | 15:11 |
| kyrofa | swartzr, do you have an encrypted home directory? | 15:13 |
| joc_ | abeato: boo, yours works here too :p | 15:15 |
| abeato | joc_, lol | 15:15 |
| swartzr | kyrofa: no although it is in a different spot than normal /var/lib/jenkins | 15:15 |
| kyrofa | swartzr, interesting. Any chance $HOME/snap is owned by root? | 15:16 |
| swartzr | zyga: Actually I forgot to look at syslog. I have a apparmor deny does this help? http://paste.ubuntu.com/17646112/ | 15:16 |
| swartzr | kyrofa: no it is owned by the user jenkins | 15:17 |
| kyrofa | swartzr, yep, that'll do it | 15:17 |
| swartzr | kyrofa should it be owned by root? | 15:17 |
| kyrofa | swartzr, it's the denial. The profile under which u-c-l runs won't let it create $HOME/snap if $HOME is in /var | 15:17 |
| kyrofa | At least, that's what it looks like | 15:17 |
| kyrofa | jdstrand, can you take a look at that? ^^ | 15:18 |
| jdstrand | which that? | 15:18 |
| jdstrand | the /var/ denial is likely from zyga's recent changes | 15:18 |
| jdstrand | and so it would need to be allowed | 15:18 |
| kyrofa | jdstrand, $HOME is /var/lib/jenkins, getting http://paste.ubuntu.com/17646112/ and permission denied when creating user data directory | 15:18 |
| kyrofa | Ah | 15:18 |
| kyrofa | swartzr, ^^ | 15:19 |
| zyga | hmm | 15:19 |
| zyga | hmm | 15:19 |
| * jdstrand is assuming the flipped mounts work is causing that ^ | 15:19 | |
| zyga | swartzr: home has to be in /home/$foo, or apparmor will have a few issues | 15:20 |
| zyga | jdstrand: which changes are you referring to? | 15:20 |
| swartzr | zyga: ok I might have to change the way I'm deploying this then | 15:20 |
| zyga | jdstrand: ubuntu still ships the old ubuntu-core-launcher | 15:20 |
| zyga | swartzr: quick idea | 15:20 |
| zyga | swartzr: vm /var/lib/jenkins /home/jenkins | 15:20 |
| zyga | er | 15:21 |
| zyga | mv | 15:21 |
| zyga | then ln -s it back | 15:21 |
| zyga | and try | 15:21 |
| zyga | so the real home is /home/jenkins | 15:21 |
| zyga | and /varlib/jenkins is a symlink to /home/jenkins | 15:21 |
| jdstrand | zyga: if this is in the old code, then the profile is lacking the rules to create HOME dir for daemons. That said, I thought something else was creating that directory in /var/lib | 15:22 |
| zyga | jdstrand: my memory is hazy | 15:25 |
| zyga | jdstrand: AFAIR the per-user thing is created by the launcher | 15:25 |
| zyga | jdstrand: and the /var/snap/$SNAP_NAME thing is created on install by snapd | 15:25 |
| swartzr | zyga let me look at that. I have to make sure that it won't mess anything else up first. | 15:27 |
| swartzr | zyga: Thank you | 15:27 |
| jdstrand | zyga: if /var/snap/$SNAP_NAME is created on install, then the launcher arguably shouldn't be creating dirs in there even if HOME is set to /var/snap/... | 15:30 |
| zyga | jdstrand: I think the launcher was doing the $HOME-derived (SNAP_USER_DATA) one | 15:32 |
| jdstrand | zyga: but they said that home was /var/lib/jenkins. I think I' confused now | 15:33 |
| jdstrand | how was HOME set to /var/lib/jenkins? | 15:33 |
| jdstrand | that isn't right in any scheme | 15:33 |
| zyga | jdstrand: I suspect jenkins package does that | 15:33 |
| zyga | jdstrand: it's not a snap, jenkins is just a regular package | 15:33 |
| jdstrand | I'm really confused now. why is the launcher getting denials for launching something that isn't a snap? | 15:34 |
| zyga | jdstrand: jenkins runs a snap | 15:34 |
| zyga | jdstrand: and the snap has a non-default HOME | 15:34 |
| zyga | jdstrand: and that falls out of the policy | 15:34 |
| zyga | jdstrand: that's how I understand it | 15:34 |
| jdstrand | how does the snap have a non-default HOME? | 15:34 |
| * zyga wonders if "falls out of sth" means anything | 15:35 | |
| jdstrand | how is that even possible? | 15:35 |
| zyga | jdstrand: I mean the user running the snap doesn't have a normal home | 15:35 |
| zyga | jdstrand: that particular user happens to be jenkins | 15:35 |
| zyga | jdstrand: cat /etc/passwd and look for home directories | 15:35 |
| jdstrand | I see what you're saying now | 15:35 |
| jdstrand | this seems like a failing of the jenkins job that runs the snap | 15:36 |
| jdstrand | it should set HOME to something else | 15:36 |
| zyga | jdstrand: like? | 15:37 |
| ogra_ | hmm, how can i tell snap find to show me snaps from beta | 15:39 |
| ogra_ | seems it doesnt accept a --channel arch | 15:40 |
| ogra_ | *arg | 15:40 |
| jdstrand | zyga: the user it is running the snap as | 15:42 |
| zyga | jdstrand: it is running as the jenkins user | 15:42 |
| zyga | jdstrand: not as anyone else, jenkis isn't root | 15:42 |
| jdstrand | I'm saying that isn't a valid test | 15:43 |
| * zyga is confused | 15:43 | |
| jdstrand | cause no one is the jenkins user | 15:43 |
| zyga | why do you say that? jenkins runs as jenkins :) | 15:43 |
| jdstrand | this is for the testsuite, right? it should run the tests as a user that is not special | 15:43 |
| zyga | no, this is for whatever someone is using jenkins for | 15:43 |
| zyga | it runs some jobs (arbitrary) | 15:43 |
| zyga | that run commands | 15:44 |
| zyga | some of which come from snaps | 15:44 |
| jdstrand | this seems too arbitrary | 15:44 |
| zyga | what is? | 15:44 |
| jdstrand | of course we could just allow the launcher to create any directory on the system | 15:44 |
| zyga | I know this isn't great | 15:44 |
| zyga | but this is the reality :) | 15:44 |
| jdstrand | it isn't though | 15:45 |
| jdstrand | it may be the reality of jenkins | 15:45 |
| jdstrand | but jenkins is a test runner | 15:45 |
| jdstrand | or script runner | 15:45 |
| jdstrand | or whatever | 15:45 |
| zyga | yes | 15:45 |
| zyga | I know | 15:45 |
| jdstrand | that isn't a normal user | 15:45 |
| zyga | I wonder if we should make the launcher ... | 15:45 |
| zyga | well | 15:45 |
| zyga | no :/ | 15:45 |
| zyga | it'd have to use a policy that understands $HOME | 15:46 |
| MichaelTunnell | so snapcore doesnt accept issues on github. What is the best branch in launchpad to submit a bug for issues with Snappy's CLI actions and responses? | 15:46 |
| jdstrand | and for the test to be valid, the test should reflect how things are actually run | 15:46 |
| zyga | is that doable in apparmor? | 15:46 |
| zyga | MichaelTunnell: please report it on launchpad.net/snappy | 15:46 |
| jdstrand | the policy cannot interrogate the env for adjust policy no. that would allow trivial escapes | 15:46 |
| MichaelTunnell | that makes sense . . . assumed it would be more specific than that :) thanks | 15:46 |
| zyga | jdstrand: right | 15:47 |
| jdstrand | zyga: you also need to consider that if we allowed this access, what is the next step? | 15:47 |
| zyga | jdstrand: we could make a trusted helper :), that runs as the user (not setuid) that just mkdir's the right thing | 15:47 |
| zyga | jdstrand: and that would not be confined | 15:47 |
| jdstrand | zyga: ie, we get snap denial because @{HOME} doesn't match /var/lib/jenkins | 15:47 |
| zyga | right | 15:47 |
| zyga | (I get that) | 15:47 |
| jdstrand | as it happens, there are ways around that with apparmor, by dropping a file into /etc/apparmor.d/tunables/home.d | 15:48 |
| jdstrand | but I think the underlying assumption that we should change policy is wrong. we should change the test env to reflect what real users are doing | 15:48 |
| jdstrand | looking at the policy, to make jenkins work we probably only need: '/var/ r, /var/lib/ r,' then I think the jenkins specific stuff isn't needed | 15:50 |
| zyga | jdstrand: can you tell me more about tunables? | 15:50 |
| jdstrand | but I maintain jenkins should have a proper home and not a special home | 15:51 |
| zyga | jdstrand: I agree that we can solve jenkins easily by allowing /var/lib in addition to home | 15:51 |
| zyga | jdstrand: /var/lib is debian policy | 15:51 |
| jdstrand | zyga: there is no Debian policy for running snaps :) | 15:51 |
| jdstrand | we have daemons and commands | 15:51 |
| zyga | jdstrand: look at your /etc/password | 15:52 |
| jdstrand | daemons run as root. commands as the user. the user in snappy has been defined as a login user | 15:52 |
| zyga | jdstrand: most of those are not /home | 15:52 |
| zyga | jdstrand: I mean for jenkins | 15:52 |
| zyga | jdstrand: jenkins is a valid thing | 15:52 |
| jdstrand | zyga: I know what is in /etc/passwd | 15:52 |
| jdstrand | we're talking past each other | 15:52 |
| zyga | jdstrand: remember that jenkins is not a snap here, anything can be running snaps | 15:52 |
| jdstrand | I know what jenkins does | 15:52 |
| zyga | jdstrand: I'm sorry, I didn't mean that | 15:52 |
| jdstrand | I know Debian policy | 15:52 |
| zyga | my point was that I think this is normal and we should find a solution that works in general | 15:53 |
| jdstrand | I'm talking about how to properly run tests | 15:53 |
| croepha | are you supposed to run snapcraft clean between each revision of snapcraft.yaml ? | 15:53 |
| jdstrand | what is another example of a deb running a snap? | 15:53 |
| zyga | jdstrand: cron | 15:53 |
| zyga | jdstrand: anything really | 15:53 |
| jdstrand | zyga: and cron sets HOME to the user's HOME | 15:53 |
| jdstrand | cron is about running stuff as a specific user | 15:54 |
| jdstrand | zyga: as for tunables, see /etc/apparmor.d/tunables/home and /etc/apparmor.d/tunables/home.d/ubuntu | 15:54 |
| * zyga looks | 15:55 | |
| zyga | ah, so it is a compile-time mechanism | 15:55 |
| jdstrand | I'm not sure why it is so contentious to run snaps as a login user since that is what we defined cli commands for | 15:56 |
| jdstrand | and that is the best way to ensure the tests are testing real-world scenarios | 15:56 |
| jdstrand | changing the policy for jenkins just makes sure it runs for jenkins | 15:56 |
| zyga | mmm | 15:57 |
| zyga | yep | 15:57 |
| zyga | I agree | 15:57 |
| zyga | swartzr: what is your use case? were you using jenkins to test your snap or were you using the snap as a part of some jenkins flow? | 15:57 |
| ehbello | hello! I have a question... hoy can I build a gadget snap? I followed the 'Gadget snappy package' guide but after run snapcraft 2.11 I get an error because I does not recognize the gadget type :-/ | 16:01 |
| ehbello | s/hoy/how/ | 16:01 |
| zyga | ehbello: can you share the URL of the guide you read? | 16:02 |
| zyga | ehbello: gadget snaps are not finalized and are prone to change | 16:02 |
| ehbello | zyga: https://developer.ubuntu.com/en/snappy/guides/gadget/ | 16:02 |
| zyga | ehbello: in fact, they are changing very much right now | 16:02 |
| zyga | oh | 16:02 |
| zyga | mhall119, dholbach: ^^ | 16:02 |
| dholbach | zyga, ok... maybe file a bug on https://bugs.launchpad.net/developer-ubuntu-com/+filebug for anything more specific? | 16:05 |
| dholbach | I'm not quite sure what to do now | 16:06 |
| zyga | dholbach: we should not have a guide for gadgets | 16:06 |
| zyga | dholbach: gadgets don't exist yet | 16:06 |
| zyga | dholbach: anyone following that is wasting their time working on moving base | 16:06 |
| dholbach | ok | 16:06 |
| dholbach | can you file a bug and we'll remove it? | 16:06 |
| zyga | yep | 16:06 |
| dholbach | thanks | 16:06 |
| dholbach | it'd be good to have a paper trail for this | 16:07 |
| dholbach | so I know what to respond when people ask me why we deleted it :-) | 16:07 |
| zyga | ehbello: we can work with you but you have to understand that image building and gadget semantis is not finalized yet | 16:07 |
| dholbach | thanks zyga | 16:07 |
| dholbach | ok, need to run now | 16:07 |
| dholbach | see you tomorrow! | 16:07 |
| ehbello | zyga: I understand. I just want to develop applications and gadgets for "snapd" and that my work is useful for the future. So I'm working on ubuntu-core 16 all-snap images and reading the latest documentation possible. | 16:15 |
| zyga | ehbello: so depending on what your gadget snap is doing you may or may not be affected by those changes | 16:17 |
| zyga | ehbello: we're iterating on ubuntu-image, the tool to make images, and the responsibilities of gadget snaps are changing in result | 16:18 |
| zyga | ehbello: also some things will be added to support assertions | 16:18 |
| zyga | ehbello: for now it's best to stick around and ask around on IRC/mailing list to know where things are heading | 16:18 |
| zyga | ehbello: you will find that some things are not perfectly documented | 16:18 |
| zyga | ehbello: but we're friendly so we'll gladly help you out :) | 16:18 |
| ehbello | zyga: thank you ^^ | 16:21 |
| dusty_ | Hi :) is there a way to point python interpreter (made from autotools) to include a list of python-packages brought in from python3 plugin? | 16:29 |
| zyga | dusty_: hmm | 16:32 |
| zyga | dusty_: can you rephrase that? | 16:32 |
| kyrofa | dusty_, yeah I'm not quite sure what you're asking there either | 16:32 |
| zyga | dusty_: you have a python (say python 3) binary built from source | 16:32 |
| zyga | dusty_: and some python projects (say like those you can find on pypi) | 16:32 |
| zyga | dusty_: and you want them to see each other? | 16:32 |
| dusty_ | okay, from kyrofa's integration tests - https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pip-requirements-list/snapcraft.yaml | 16:36 |
| dusty_ | is there a way to have a python binary (say 2.6) include those packages as part of its path? | 16:37 |
| dusty_ | I hope that made more sense :\ | 16:37 |
| dusty_ | not sure if that would have to do with environment variables? | 16:39 |
| kyrofa | dusty_, probably using PYTHONPATH | 16:40 |
| zyga | dusty_: set PYTHONPATH and | 16:40 |
| zyga | ;:) | 16:40 |
| ehbello | zyga: I guess of your words I should download the latest version of snapcraft from github to work with the development version of ubuntu-core, right? | 16:40 |
| zyga | ehbello: no, snapcraft doesn't support gadget snaps much | 16:41 |
| zyga | ehbello: for those are hand-made | 16:41 |
| zyga | ehbello: we're working on tooling around that and stock gaget snaps in source form to fork as a base | 16:41 |
| zyga | ehbello: the thing you will run into is that soon ubuntu-image will replace ubuntu-device-flash and the gadget will have to have additional data to be built | 16:42 |
| dusty_ | kyrofa, zyga: alright thanks | 16:46 |
| zyga | slangasek: snap-confine synced to yakkety from debian | 16:49 |
| zyga | slangasek: and now we get upgrade bugs because it somehow conflicts with ubuntu-core-launcher | 16:49 |
| zyga | slangasek: can you please release snap-confine 1.0.33 to debian | 16:49 |
| zyga | slangasek: and use the rules as they are spelled out in the package today | 16:49 |
| zyga | slangasek: (!legacy mode) | 16:49 |
| zyga | slangasek: please ping mvo to ack this | 16:50 |
| zyga | slangasek: If you want I can make the package but I need a sponsor | 16:50 |
| swartzr | zyga: Sorry was out to lunch. My use case is that the jenkins job is running the snap as part of a workflow. More specifically the snap is downloading files over SFTP (with some custom logic) which then the rest of the job will load the files onto a file share | 16:54 |
| zyga | swartzr: thanks | 16:54 |
| zyga | jdstrand: ^^ | 16:54 |
| zyga | jdstrand: so it's not about testing the snap | 16:54 |
| zyga | swartzr: make sure this is reported on launchpad.net/snappy and we'll get it fixed | 16:54 |
| kyrofa | jdstrand, it's easy to validate that an apparmor profile was loaded correctly by checking /sys/kernel/security/apparmor/profiles. Is there anything similar for seccomp filters? | 16:55 |
| zyga | kyrofa: seccomp filters are loaded each time | 16:55 |
| kyrofa | zyga, alright, I'll just check for file presence then | 16:55 |
| kyrofa | zyga, thanks :) | 16:56 |
| zyga | kyrofa: there might be something in /proc but I'm not sure (in the particular pid) | 16:56 |
| ehbello | zyga: ouch... so, snapcraft lost support for gadgets since snappy tool? | 17:03 |
| zyga | ehbello: officially it never really had support | 17:03 |
| zyga | ehbello: I'm sure snapcraft will support gadgets | 17:04 |
| zyga | ehbello: it's just that right now that's not being used so it might not work in practice | 17:04 |
| zyga | ehbello: there are a few things that are unique to gadget snaps | 17:04 |
| ehbello | zyga: ok, I understand | 17:05 |
| swartzr | zyga: Bug is reported at https://bugs.launchpad.net/snappy/+bug/1594904 | 17:08 |
| ubottu | Launchpad bug 1594904 in Snappy "Snaps fail to run when user's home directory is not under /home" [Undecided,New] | 17:08 |
| zyga | thanks! | 17:08 |
| zyga | swartzr: I'll see if we can get it fixed for 2.0.10 | 17:08 |
| sgclark | hi all, I am having a terrible time getting sound to work, any tricks I need to be aware of? | 17:08 |
| jdstrand | kyrofa: re seccomp> no. the launcher loads them into the kernel and there is nothing to introspect that afaik | 17:10 |
| kyrofa | jdstrand, alrighty, I'll just check for the file then. Thanks! | 17:10 |
| jdstrand | kyrofa: as was mentioned, use the files in /var/lib/snapd/seccomp/profiles | 17:11 |
| jdstrand | right, yes :) | 17:11 |
| swartzr | zyga: in the meantime is the best workaround to mv the directory to /home and then symlink it? Or is there a better workaround that you found in my absense? | 17:11 |
| zyga | swartzr: I think that will work | 17:12 |
| zyga | try it | 17:12 |
| swartzr | zyga: Will do thank you so much. | 17:12 |
| ehbello | zyga: do you know where are the sources of beagleblack and canonical-* gadget snaps? | 17:21 |
| zyga | ehbello: I think so | 17:22 |
| * zyga checks | 17:22 | |
| zyga | http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files | 17:23 |
| ehbello | zyga: thanks! =D | 17:24 |
| slangasek | zyga: snap-confine 1.0.33> this package can't be in sync between Debian and Ubuntu because of the changes to the build for confinement being on or off | 17:29 |
| zyga | slangasek: oh, good point | 17:29 |
| zyga | slangasek: what should we do then? | 17:29 |
| zyga | slangasek: I mean, we can . /etc/os-release | 17:29 |
| zyga | slangasek: and then do it conditionally | 17:30 |
| zyga | slangasek: would that be sensible? | 17:30 |
| zyga | slangasek: (then it could sync okay) | 17:30 |
| slangasek | zyga: I assumed that the team would continue uploading directly to Ubuntu and that I would pick them up from there for merging back to Debian | 17:30 |
| slangasek | zyga: however, if we do want it in sync, the way to do it is using dpkg-vendor in debian/rules to manipulate the build | 17:30 |
| zyga | slangasek: right now we have a problem, I don't know what the solution is, the problem is that the version we have in yakkety apparently synced from debian and fails to upgrade | 17:31 |
| slangasek | zyga: that's version 1.0.30 in yakkety-proposed? | 17:31 |
| slangasek | or which version? | 17:32 |
| zyga | slangasek: hmm, I see upgrade bugs that cite the +2 version | 17:32 |
| zyga | and +2 AFAIK only went into debian | 17:32 |
| zyga | maybe I'm mis-iterpreting things and that is not true | 17:32 |
| slangasek | zyga: ok. +2 made it into yakkety-proposed; then I removed it knowing that it would be a problem | 17:32 |
| slangasek | so it's no longer in Ubuntu | 17:32 |
| slangasek | and I've blacklisted it from syncing because of the confinement issue | 17:33 |
| zyga | ah, that's good | 17:33 |
| zyga | thanks for explaining that | 17:33 |
| slangasek | but if we decide to get it into sync, we can drop the blacklist | 17:33 |
| zyga | slangasek: I'll discuss with mvo, ideally using the vendor thing might mean we have less maintenance to do | 17:34 |
| zyga | slangasek: as snap-confine is gaining new essential features quickly | 17:34 |
| zyga | slangasek: thanks :) | 17:36 |
| slangasek | zyga: well, how much do we care about having up-to-date snapd+snap-confine in yakkety, currently? Because to date, we haven't had a version of snapd since 2.0.2 clear proposed-migration due to test failures | 17:36 |
| slangasek | if that's a temporary blip and we want current snapd in yakkety, then we might also not want the delays of uploading to Debian + syncing to Ubuntu (which is always at least a 6 hour delay because of the Debian publisher cycle) | 17:37 |
| zyga | slangasek: ideally we'd be able to release it easily to all the various distributions as cheaply as possible, yakkety is not special here, I think that right now it is not critical but we should be keeping it in sync as the release date closes | 17:37 |
| zyga | s/closes/approaches/ | 17:37 |
| zyga | slangasek: I think it will stabilize over time | 17:37 |
| zyga | slangasek: there's a finite set of features we want there | 17:38 |
| wililupy | Is there a quick reference to snap environment variables? | 17:38 |
| zyga | wililupy: some, I can also guide you :) | 17:38 |
| * zyga looks | 17:38 | |
| wililupy | Like $SNAP_DATA? | 17:38 |
| zyga | wililupy: that's writable data that's not specific to a user | 17:39 |
| wililupy | I'm thinking my snap may be using old snap environment variables that no longer being used. | 17:39 |
| wililupy | Sorry, not my snap, my code. | 17:39 |
| zyga | (this is not documented) | 17:40 |
| wililupy | I have a script that runs as a daemon, if it doesn't find the correct directory structure, it creates it by mkdir -p ${SNAP_DATA}/mnt/fastpath | 17:41 |
| slangasek | zyga: ok; so we certainly need to settle on a version scheme for the packages in all of this, if we're going to be possibly syncing from Debian | 17:41 |
| zyga | slangasek: do you think we should de-couple packaging? | 17:41 |
| zyga | slangasek: and do upstream releases | 17:41 |
| zyga | (as we started to for the past 5-or-so) | 17:42 |
| zyga | slangasek: then release to debian (and optionally ubuntu if required urgently) and other distros | 17:42 |
| slangasek | zyga: having an upstream tarball separate from the Debian packaging makes the Debian packaging part easier, but I'm not sure if there are other factors to consider | 17:43 |
| zyga | slangasek: note that this is how fedora/arch/gentoo packaging is done today | 17:44 |
| slangasek | which way? | 17:45 |
| zyga | slangasek: as a typical package with decoupled upstream tarabll and downstream packaging | 17:45 |
| slangasek | ok | 17:45 |
| zyga | slangasek: eg. https://github.com/snapcore/snap-confine/releases/download/1.0.33/snap-confine-1.0.33.tar.gz | 17:45 |
| zyga | that's an autotools "make dist" tarball | 17:46 |
| slangasek | zyga: so, if we were to exclude debian/ from the 'make dist' target, and change debian/source/format to 3.0 (quilt), that should all work just fine for me | 17:47 |
| zyga | slangasek: release tarballs don't ship debian/ | 17:47 |
| zyga | slangasek: so I guess I could make a branch that makes packaging separate | 17:47 |
| zyga | slangasek: do you want to keep it in the repository? | 17:47 |
| slangasek | zyga: it should be kept in the repository, and I already have a separate branch that's authoritative for the Debian packaging | 17:48 |
| zyga | slangasek: do you want me to propose a pull request that switches to non-native packaging then? | 17:48 |
| zyga | slangasek: and I'll let you do the rest? | 17:48 |
| slangasek | zyga: I can work through that today along with the other packaging changes needed to have it syncable | 17:49 |
| zyga | slangasek: thank you | 17:49 |
| zyga | slangasek: so I'll do nothing and I'll keep doing upstream releases and downstream releases in other distros | 17:50 |
| slangasek | zyga: zyga and that tarball is now called 'snap-confine' instead of 'ubuntu-core-launcher' - previously there was a rename of the binary package but not the source package? | 17:50 |
| zyga | slangasek: we backed that out from debian/{changelog,control} because it would be easier to ship at the time, the package should be called snap-confine upstream as ubuntu-core-launcher is going to be removed entirely soon (likely next week, pull requests for this are pending) | 17:51 |
| zyga | slangasek: when that happens snap-confine won't have any executables in bin | 17:51 |
| === JanC is now known as Guest79667 | ||
| === JanC_ is now known as JanC | ||
| kyrofa | zyga, jdstrand I want to write a test verifying that dbus .conf files are placed correctly for plugs, but it seems the only interface that would do such a thing is location-control/observe. Do either of you know of any snaps that provide those slots? | 17:53 |
| zyga | kyrofa: mmm, network manager | 17:53 |
| zyga | kyrofa: try it, it should have a policy | 17:53 |
| kyrofa | zyga, ah very good, checking now | 17:54 |
| kyrofa | zyga, wait, you mean the interface network manager? | 17:54 |
| zyga | kyrofa: yes | 17:54 |
| zyga | kyrofa: the network-manager interface | 17:54 |
| zyga | kyrofa: you can stick it on a dummy snap | 17:54 |
| kyrofa | zyga, no, it seems that's only for a slot | 17:54 |
| zyga | kyrofa: just to show that it is used | 17:54 |
| zyga | kyrofa: ahh | 17:55 |
| zyga | kyrofa: no wait | 17:55 |
| zyga | kyrofa: for plugs too | 17:55 |
| zyga | kyrofa: you just have to connect it | 17:55 |
| kyrofa | zyga, perhaps I'm misunderstanding, but both `*PlugSnippet` functions return nil,nil for dbus | 17:55 |
| zyga | hmm | 17:55 |
| * zyga looks | 17:55 | |
| zyga | (that's odd btw) | 17:56 |
| kyrofa | zyga, indeed, I wonder if that's broken :P | 17:56 |
| kyrofa | Or perhaps unfinished? | 17:56 |
| zyga | ah | 17:56 |
| zyga | sorry | 17:56 |
| zyga | no | 17:56 |
| zyga | plug side is handled with apparmor | 17:57 |
| zyga | because that's how we can see and use the apparmor labels | 17:57 |
| zyga | plug side won't be used by dbus much I think | 17:57 |
| kyrofa | Ahh, oay | 17:57 |
| kyrofa | okay* | 17:57 |
| zyga | if you really want a test, you'd have to create a dummy interface | 17:57 |
| kyrofa | I guess I don't want a test that bad ;) | 17:57 |
| kyrofa | It's already unit tested with dummies | 17:58 |
| zyga | yep | 17:58 |
| kyrofa | Hey zyga, would you mind adding your thoughts here? It's regarding the APP_NAME variable question I asked you last week https://github.com/snapcore/snapd/pull/1373#discussion-diff-67917045 | 17:59 |
| slangasek | zyga: fyi https://github.com/vorlonofportland/snap-confine/tree/debian (will move soon to alioth.debian.org) | 18:00 |
| zyga | slangasek: thank you | 18:00 |
| slangasek | zyga: do you think we need mvo to weigh in on the native v. non-native packaging question, or should I JFDI from here? | 18:02 |
| kyrofa | jdstrand, it doesn't seem that APP_NAME is being used in any of the interfaces today. Do you envision a use-case for it? | 18:03 |
| JohnAgosta | Hi, i have a newbee question... I have a bzr branch that I can successfully 'snapcraft build' into a part. There is a script in the part's /src that I would like to expose as an app in the snap. How do I do that? I can't seen to get the snapcraft to copy it to the /install tree. | 18:03 |
| ehbello | zyga: how can I build this beagleblack snap and others? | 18:04 |
| jdstrand | kyrofa: I can imagine it being used. I don't have something otoh | 18:06 |
| kyrofa | jdstrand, so if the hooks being developed also have apparmor profiles, would you suggest having a HOOK_NAME variable as well? Or perhaps we should generalize to EXECUTABLE_NAME (just throwing ideas out there)? | 18:07 |
| kyrofa | jdstrand, but if we have no use-cases, there's a case to be made for dropping it all together | 18:07 |
| kyrofa | jdstrand, your thoughts would be appreciated here if you have a minute: https://github.com/snapcore/snapd/pull/1373#discussion-diff-67917045 | 18:08 |
| jdstrand | kyrofa: I'll add it to my list of things to look at. I can say we used APP_NAME extensively on touch and may with personal. I'd prefer not to drop it until we know we don't need it, and I can't say we won't for personal | 18:11 |
| jdstrand | kyrofa: but may not get to that review today (trying to get the mpris interface in order) | 18:11 |
| kyrofa | jdstrand, alright, thank you | 18:12 |
| sergiusens | elopio why are all our tests broken/ | 18:26 |
| sergiusens | ? | 18:26 |
| swartzr | zyga: moving the home directory still results in the same behavior and the same error in syslog. I'm going to try reconfiguring jenkins to look to the home directory. Unless you have any other ideas? | 18:33 |
| kyrofa | jdstrand, how is APP_NAME used on touch? | 18:41 |
| jdstrand | kyrofa: to differentiate between apps in the same package so they may have different policy. this is all changing for snappy but I can't predict how | 18:45 |
| kyrofa | jdstrand, interesting... they aren't separate files as they are on snappy? | 18:46 |
| kyrofa | niemeyer1, FYI ^^ | 18:47 |
| kyrofa | niemeyer, is niemeyer1 also you? :P | 18:48 |
| niemeyer | kyrofa: Yeah, we're a family | 18:48 |
| jdstrand | kyrofa: they are separate files. but for example scopes and gui apps aren't supposed to share data. this is because network scopes aren't supposed to have access to the filesystem since the scopes infrastructure can't prevent data theft | 18:48 |
| niemeyer | jdstrand: We already differentiate interfaces based on app, right? | 18:48 |
| jdstrand | yes | 18:48 |
| jdstrand | that isn't what I'm talking about | 18:48 |
| * niemeyer misses the "Typing..." note :) | 18:49 | |
| jdstrand | I'm talking about using @{APP_NAME} in the policy. we don't (yet) in snappy. we do in click. without designing the migration of click to snaps and what policy would look like now, I can't predict that we will never use @{APP_NAME} in snappy | 18:50 |
| niemeyer | jdstrand: Well, how's that not what I just said? | 18:50 |
| jdstrand | I thought you were talking about the file name | 18:50 |
| jdstrand | which was kyrofa's previous question | 18:50 |
| jdstrand | we are talking about template_vars.go, right? | 18:51 |
| kyrofa | jdstrand, indeed | 18:51 |
| niemeyer | jdstrand: I'm talking about your point that we may want to use the app name in policy to differentiate apps in the same package | 18:51 |
| niemeyer | jdstrand: We already do that for several interfaces | 18:51 |
| niemeyer | jdstrand: Practical example: | 18:51 |
| niemeyer | peer=(label=###SLOT_SECURITY_TAGS###), | 18:52 |
| jdstrand | in the various existing interfaces code we don't rely on template_vars.go for @{APP_NAME} | 18:52 |
| jdstrand | yes | 18:52 |
| niemeyer | This is binding to a particular name | 18:52 |
| niemeyer | So my theory about why we're not seeing the application name is because we have something better | 18:52 |
| jdstrand | but that doesn't mean we won't *ever* use @{APP_NAME} in the apparmor policy | 18:52 |
| jdstrand | maybe | 18:52 |
| jdstrand | like I said. we haven't designed the touch migration | 18:52 |
| jdstrand | and I can't predict we will *never* need it since all the touch policy needs to be converted to interfaces for personal | 18:53 |
| niemeyer | jdstrand: Well, I also can't say we won't *ever* use something :) | 18:53 |
| kyrofa | Can we add them when we need them? | 18:53 |
| jdstrand | so I'm just playing it safe | 18:53 |
| jdstrand | it sounds like you want to use it for hook name | 18:53 |
| jdstrand | which is not the app name | 18:54 |
| kyrofa | jdstrand, I don't care one way or the other-- we could also add HOOK_NAME | 18:54 |
| niemeyer | Can we please drop it? We have the whole context inside the interface to cook whatever we want when we need to | 18:54 |
| jdstrand | so removing it now to add it to be used by hook name to possibly add it later sounds weird to me | 18:54 |
| niemeyer | We are already using security tags on interfaces, which is effectiely *exactly* the app name | 18:54 |
| niemeyer | snap.<snap>.<APP NAME> | 18:55 |
| niemeyer | Except it's properly namespaced, which means better | 18:55 |
| jdstrand | sure, but app name might be used for other things, like file paths | 18:55 |
| niemeyer | jdstrand: WE have the app name too.. | 18:55 |
| niemeyer | jdstrand: We have both the plug and the slot | 18:55 |
| niemeyer | jdstrand: and in fact.. I suspect APP_NAME will likely not work as we want it to | 18:56 |
| jdstrand | look, it can be removed. people asked my opinion. I would prefer to not remove it cause I don't know the migration path since we aren't anywhere near migrating to personal. it seems harmless to leave it | 18:56 |
| niemeyer | jdstrand: Because it doesn't consider the problem of aggregating the several app names | 18:56 |
| jdstrand | I wasn't suggesting we use APP_NAME in security labels. we do that fine in interfaces | 18:57 |
| jdstrand | I'm talking about other policy in the filesystem | 18:57 |
| jdstrand | where perhaps we want to differentiate between apps. we had a need for that on touch. I don't know if that need (or others) goes away yet | 18:58 |
| swartzr | zyga: moving the home directory still results in the same behavior and the same error in syslog. I'm going to try reconfiguring jenkins to look to the home directory. Unless you have any other ideas? | 18:58 |
| zyga | swartzr: hmm | 18:59 |
| zyga | swartzr: no, I don't have any ideas | 18:59 |
| zyga | swartzr: did you restart jenkins? | 18:59 |
| zyga | swartzr: and perhaps also change the home in /etc/passwd | 18:59 |
| zyga | swartzr: then restart jenkins | 18:59 |
| zyga | swartzr: (set it to /home/jenkins for example0 | 18:59 |
| niemeyer | jdstrand: Okay, thank you.. the context is indeed appreciated | 19:00 |
| jdstrand | zyga: can you enlighten me on something. I'm looking at all.go and all_test.go. Why do some interfaces have New with DeepContains and others lack New, use &builtin and use Contains? | 19:00 |
| kyrofa | Indeed, thank you jdstrand | 19:00 |
| niemeyer | jdstrand: I'd prefer to remove it though, based exactly on security concerns.. we have hooks and apps, and we don't know the right thing to put there because we don't have a use case | 19:00 |
| niemeyer | jdstrand: This may easily be a serious bug, with a string that should be filled ending up empty, or having a name that conflicts with a real app | 19:01 |
| niemeyer | jdstrand: So, on that basis, let's remove and re-add when we know more | 19:01 |
| jdstrand | if it is better to remove-- that's fine. it seems clear that so far on snappy we haven't needed it. I'd prefer that we not conflate hook name with the app name though | 19:01 |
| zyga | jdstrand: that's just a go thing, some of those use a NewFoo method to create an instance while others have no state at all and are just a simple object | 19:01 |
| niemeyer | jdstrand: Removing is dropping one line, and that variable cannot be used without also changing the code, so no real damage | 19:02 |
| zyga | jdstrand: for the former you have to use DeepContains, for the latter you can use Contains | 19:02 |
| zyga | jdstrand: maps, slices and pointers want you to use DeepContains AFAIR | 19:02 |
| niemeyer | jdstrand: Right, precisely.. the names are not conflated, except for that one case | 19:02 |
| niemeyer | jdstrand: They have different security tags, different paths in the FS, different entries in snap.yaml | 19:02 |
| niemeyer | jdstrand: On this case we don't know what to do because there's no use case for that variable | 19:03 |
| jdstrand | zyga: interesting. what is also interesting is that it seems to correspond to os supplied interfaces and slot-providing snaps | 19:03 |
| zyga | jdstrand: thats just accidental today | 19:03 |
| jdstrand | ok | 19:03 |
| jdstrand | zyga: thanks! | 19:03 |
| zyga | just depends on what the type has inside | 19:03 |
| zyga | jdstrand: deep contains works always | 19:04 |
| jdstrand | :w | 19:04 |
| jdstrand | meh | 19:04 |
| zyga | jdstrand: I saw your comments on the interfaces, I'm currently taking my evening slack but I'll go around and update and merge the two new interfaces | 19:07 |
| jdstrand | zyga: cool. I'm working on mpris | 19:09 |
| swartzr | zyga: I'll try that thanks | 19:09 |
| swartzr | zyga: and yes I did restart jenkins | 19:09 |
| jdstrand | so far it seems it closer to a slot side and plug side thing. working through those details | 19:10 |
| zyga | jdstrand: I thought that mpris coudl be a new interface | 19:10 |
| jdstrand | yes | 19:10 |
| zyga | jdstrand: e.g. a front-panel device that does mpris slot | 19:10 |
| jdstrand | that is what I am thinking | 19:11 |
| zyga | jdstrand: classic exposing mpris | 19:11 |
| zyga | etc | 19:11 |
| zyga | and apps would do auto-connectable plugs | 19:11 |
| jdstrand | the is the player side (slot) and the controller side (plugs) | 19:11 |
| zyga | jdstrand: note that we have a nice way to change auto-connect candidates | 19:11 |
| zyga | jdstrand: hmm | 19:11 |
| zyga | jdstrand: actually I was thinking the reverse | 19:11 |
| zyga | jdstrand: but to be hones, this feels that it can be any | 19:12 |
| zyga | honest* | 19:12 |
| * zyga cannot type | 19:12 | |
| jdstrand | well, let me continue my investigation and we can discuss in the PR | 19:12 |
| zyga | jdstrand: anyway, the point about auto-connect is for later :) | 19:12 |
| zyga | jdstrand: but we could even auto-connect to any viable target if there's no slot (or plug) on the core snap | 19:12 |
| elopio | sergiusens: I don't really know what else to do with the microphone, it worked this morning. Want to talk about registration here? | 19:13 |
| sergiusens | elopio so about jenkins, can you take over making sure trunk passes? | 19:14 |
| sergiusens | elopio about registration, just wondering what you meant by simple | 19:14 |
| sergiusens | kyrofa a review of this would be nice https://github.com/ubuntu-core/snapcraft/pull/588/files (aside from josepht) | 19:15 |
| jdstrand | zyga: I think you had a patch for this, but fyi: this still doesn't work: sudo /tmp/snap connect vlc:mount-observe :mount-observe | 19:17 |
| jdstrand | zyga: I mention it cause this works: sudo /tmp/snap connect vlc:mount-observe ubuntu-core:mount-observe | 19:18 |
| elopio | sergiusens: yes, I'm updating the parts and waiting for the last two jobs to restart. And about simple, I mean that the branch only registers or fails. The full workflow involves to error when trying to upload an unregistered snap, to provide nice feedback when the name is reserved, and the private flag which I don't yet know what is for. | 19:18 |
| jdstrand | zyga: and 'ubuntu-core' is not cross-distro-friendly. perhaps that becomes core:mount-observe? anyway-- not blocked. fyi | 19:18 |
| swartzr | zyga: That worked! Thank you so much! I can now scrap this "Yeah this isn't going to work" email to my boss. | 19:21 |
| sergiusens | elopio oh, that's fine, we can create wishlist bugs for those | 19:23 |
| zyga | swartzr: sweet, thank you for your patience! | 19:28 |
| zyga | jdstrand: yep, I know | 19:29 |
| zyga | jdstrand: it will be just core and : | 19:29 |
| zyga | (name not required) | 19:29 |
| ehbello | zyga: before you disconnected, I asked you.... what tool or version of snapcraft I need to build this beagleblack snap and others? | 19:36 |
| zyga | ehbello: I think those are not built with snapcraft | 19:51 |
| zyga | ehbello: just look at the source, they are built with the raw lower level tools | 19:51 |
| mhall119 | sergiusens: are you still around? | 19:52 |
| sergiusens | mhall119 yes | 19:56 |
| mhall119 | sergiusens: I'm stuck on pkg-config stuff with https://github.com/ubuntu/snappy-playpen/tree/pantheon-mail/pantheon-mail | 19:56 |
| mhall119 | tl;dr, the latest Pantheon Mail client needs Granite 0.4, but the archives only have 0.3, so I build 0.4 from upstream source and need the "mail" part to find it, but it doesn't | 19:57 |
| zyga | mhall119: pantheon mail snap?! :) | 19:59 |
| mhall119 | zyga: well that depends on whether or not sergiusens can help me :) | 19:59 |
| mhall119 | zyga: if he can, I'll be proposing a new interface for snapd later | 19:59 |
| sergiusens | mhall119 can't you build pkg-config from source? | 20:00 |
| mhall119 | sergiusens: build pkg-config itself? | 20:00 |
| sergiusens | as a part that gets staged | 20:00 |
| sergiusens | yeah | 20:00 |
| mhall119 | sergiusens: it's not that I'm missing pkg-config, it's that when pkg-config runs on the "mail" part it doesn't find libgranite 0.4 what is built in the "granite" part | 20:00 |
| mhall119 | so ./configure on the "mail" part fails saying it needs libgranite | 20:01 |
| zyga | mhall119: ignore pkg-config, you don't need any newer verion, you need granite itself | 20:01 |
| mhall119 | yes | 20:02 |
| sergiusens | mhall119 oh, ic, I thought you needed a newer pkg-config | 20:02 |
| mhall119 | I need the version of granite built by the part | 20:02 |
| mhall119 | sergiusens: no, well I hope not anyway, I just need it to look in the right places | 20:02 |
| mhall119 | sergiusens: run that snapcraft.yaml in a cleanbuild and you'll see | 20:02 |
| mhall119 | granite appears to build fine and get installed into ./stage/ | 20:02 |
| mhall119 | then when it moves on to the "mail" part it fails saying pkg-config can't find the granite dependency | 20:03 |
| zyga | mhall119: how is granite configured | 20:04 |
| mhall119 | if I add the 0.3 granite into build-packages instead of building 0.4 in a part, everything builds fine but panteon-mail crashes when run because it needs the newer version | 20:04 |
| zyga | mhall119: is --prefix=/usr | 20:04 |
| zyga | mhall119: if not you won't find pkg-config information file in the right spot | 20:04 |
| mhall119 | zyga: -DCMAKE_BUILD_TYPE=Release, -DCMAKE_INSTALL_PREFIX=/usr, -DCMAKE_INSTALL_LIBDIR=/usr/lib | 20:04 |
| zyga | mhall119: oh, cmake (/me barfs) | 20:04 |
| zyga | mhall119: anyway, look where the .pc file is | 20:05 |
| sergiusens | zyga yeah -DCMAKE_INSTALL_PREFIX=/usr | 20:05 |
| zyga | mhall119: and check where snapcraft sets PKG_CONFIG_SYSROOT_DIR | 20:05 |
| sergiusens | mhall119 is that required btw ^? | 20:05 |
| mhall119 | zyga: PKG_CONFIG_SYSROOT_DIR was /root/stage/ I believe | 20:05 |
| mhall119 | sergiusens: is what required? | 20:05 |
| sergiusens | zyga no need, mhall119 run ./parts/<part-name>/bin/pkg-config <options> <module-name> | 20:06 |
| sergiusens | mhall119 if setting the install prefix is required | 20:06 |
| mhall119 | sergiusens: I don't know if it is or isn't | 20:06 |
| sergiusens | mhall119 you know that once in the snap it won't be at that prefix, right? | 20:06 |
| mhall119 | yes | 20:06 |
| mhall119 | let me re-run so I can see where the files are | 20:06 |
| mhall119 | sergiusens: but if you run it you will be able to see it faster | 20:07 |
| mhall119 | sergiusens: ./stage/usr/lib/pkgconfig/granite.pc | 20:10 |
| sergiusens | mhall119 you have high expectations of me working in "convergence" mode on the tablet ;-) | 20:13 |
| sergiusens | sure, I'll look | 20:13 |
| sergiusens | also, my bandwith is 3Mbps ;-) | 20:13 |
| zyga | sergiusens: \o/ | 20:13 |
| sergiusens | mhall119 the build just fails for me | 20:26 |
| sergiusens | http://pastebin.ubuntu.com/17661758/ | 20:26 |
| mhall119 | huh, doesn't do that for me.... | 20:33 |
| mhall119 | sergiusens: try a cleanbuild? | 20:33 |
| sergiusens | elopio so how long do we wait for the jenkins bring up? | 20:35 |
| mhall119 | sergiusens: http://paste.ubuntu.com/17662567/ is the error I get, btw | 20:42 |
| mhall119 | sergiusens: I've also pushed a new version of the yaml to github, it removes some package dependencies that weren't really needed | 20:43 |
| mhall119 | http://paste.ubuntu.com/17662693/ is the .pc file in ./stage/ | 20:44 |
| mhall119 | sergiusens: I assume that it's something wrong in my snapcraft.yaml but for the life of me I can't figure out what | 20:46 |
| sergiusens | mhall119 maybe not, pkg-config isn't the best thing when it comes to multiple sysroots | 20:48 |
| croepha | what do you put for "Project contact" in the contributor agreement? | 20:48 |
| elopio | sergiusens: it is up. I'm monitoring the first run. | 20:50 |
| mhall119 | croepha: which project are you contributing to? | 20:51 |
| croepha | snapcraft | 20:52 |
| mhall119 | croepha: put Jamie Bennett then | 20:53 |
| mhall119 | jamiebennett: ^^ is that correct? | 20:53 |
| * mhall119 notes it's 10pm his local time, so he's probably not going to respond | 20:53 | |
| jamiebennett | mhall119, Sure | 20:53 |
| * mhall119 notes his surprise that he's still online | 20:53 | |
| jamiebennett | (I'm in a different TZ this week) | 20:53 |
| mhall119 | oh, are you in Boston? | 20:54 |
| jamiebennett | yes | 20:54 |
| * mhall119 waves from down south | 20:54 | |
| croepha | cool, thanks | 20:54 |
| mhall119 | croepha: thank you for contributing :) | 20:54 |
| croepha | no prob :) | 20:54 |
| croepha | is there a requirements.txt for dev? | 20:56 |
| croepha | nvm, its in the travis file | 20:57 |
| sergiusens | croepha is this snapcraft? We are waiting to discover why it kills our packaging (to add a install_requires entry) | 21:03 |
| croepha | yes for snapcraft | 21:04 |
| sergiusens | croepha great, can't wait to see what you propose | 21:05 |
| croepha | it looks like there already is install_requires in setup.py, but thats the run time deps, I was hoping there was a quickstart guide for development, but the travis.yaml file looks like its got all the info on how to get tests running | 21:06 |
| sergiusens | croepha I just do `sudo mk-build-deps -i` | 21:06 |
| sergiusens | which creates a fake deb with all the deps | 21:07 |
| croepha | ahh, nice trick | 21:07 |
| sergiusens | mhall119 ok, my cleanbuild is stuck pulling granite | 21:08 |
| mhall119 | stuck? | 21:08 |
| sergiusens | mhall119 yes, bzr ftw ;-) | 21:09 |
| sergiusens | going to leave it there for a bit | 21:09 |
| sergiusens | mhall119 in the meantime here is a thought; if this .pc file for granite depends on other .pc files they need to all live under the same sysroot | 21:09 |
| mhall119 | oh, really? | 21:10 |
| sergiusens | mhall119 as I said, pkg-config is sort of dumb in this aspect and cannot handle multiple sysroots | 21:10 |
| mhall119 | so, um, how do I accomplish that with separate parts? | 21:10 |
| sergiusens | mhall119 if it is all in parts it is mostly fine, the problem comes more so when those .pc files come from the main installation (build-packages) | 21:11 |
| sergiusens | so if you are keen on using ubuntu, a start would be to transform those to either proper parts built from source or to change them to stage-packages (the `-dev` ones and use filesets so your snap doesn't get huge) | 21:12 |
| mhall119 | sergiusens: make the -dev packages stage-packages in which, the granite or the mail part? | 21:13 |
| tedg | sergiusens: If I want to use an organize rule for my desktop file in the snap should it go in setup or meta? | 21:13 |
| sergiusens | mhall119 the one that provides the .pc files as it probably needs them for building anyways | 21:13 |
| sergiusens | tedg `organize` cannot touch meta nor setup | 21:13 |
| mhall119 | sergiusens: the granite part provides the granite.pc, the rest were being pulled in the mail part's build-packages | 21:14 |
| tedg | sergiusens: Hmm, so how do I get the snap to use the desktop file after translations have been merged? | 21:14 |
| sergiusens | tedg I am inclined to remove all the "by convention" stuff in snapcraft (which was to follow a snap/d trend) and just go and make it all declarative | 21:14 |
| sergiusens | tedg you cannot do that today | 21:15 |
| sergiusens | tedg unless your snapcraft.yaml lives in the root of the sources, therefore you could link to setup | 21:15 |
| sergiusens | mhall119 can I see granite.pc? | 21:15 |
| mhall119 | sergiusens: http://paste.ubuntu.com/17662693/ | 21:17 |
| sergiusens | mhall119 try stage-packaging all of these cairo gee-0.8 glib-2.0 gio-unix-2.0 gobject-2.0 gthread-2.0 gdk-3.0 gdk-pixbuf-2.0 gtk+-3.0 in the granite part | 21:18 |
| mhall119 | sergiusens: those packages, or their -dev equiv? | 21:18 |
| sergiusens | mhall119 the -dev's | 21:19 |
| tedg | sergiusens: Reread that twice, and I'm confused :-) I agree that it shouldn't be by convention. While I do have my snapcraft.yaml in the root of the source, I don't know how that changes things. | 21:19 |
| sergiusens | tedg is the desktop file generation a build time thing? | 21:19 |
| tedg | I'd also agree that snapd shouldn't copy them to a random directory, but that's another story :-) | 21:19 |
| sergiusens | or is it already there comitted to source? | 21:19 |
| tedg | sergiusens: Yes, merges with the po files. Starts as desktop.in | 21:19 |
| sergiusens | oh, then my subtle suggestion won't work | 21:20 |
| mhall119 | tedg: https://bugs.launchpad.net/snapcraft/+bug/1588359 mark it as affecting you :) | 21:20 |
| ubottu | Launchpad bug 1588359 in Snapcraft "No way to add setup files at build time" [Undecided,New] | 21:20 |
| tedg | sergiusens: FWIW, I think everyone with a desktop file merges it at build time with translations. | 21:20 |
| sergiusens | tedg what is a translation? | 21:21 |
| sergiusens | :-) | 21:21 |
| * sergiusens jokes | 21:21 | |
| tedg | sergiusens: It's how we make people in Texas use the phone. | 21:21 |
| tedg | ;-) | 21:21 |
| tedg | mhall119: Done and added a comment about the desktop file. | 21:22 |
| sergiusens | tedg by declaration I hope ;-) | 21:23 |
| tedg | Gun point, like everything in Texas. | 21:23 |
| mhall119 | sergiusens: ok, I've a whole mess of .pc files in ./stage/usr/share/pkgconfig/ now, but still getting the same error | 21:42 |
| mhall119 | including a .pc file for everything listed in the Requires line of the granite.pc | 21:44 |
| mhall119 | sergiusens: http://paste.ubuntu.com/17665800/ | 21:46 |
| sergiusens | elopio want tp update https://github.com/ubuntu-core/snapcraft/pull/586 ? | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
