| === tsimonq2alt is now known as tsimonq2 | ||
| mup | PR snapd#1651 opened: More create-user fixes <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1651> | 02:18 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1652 opened: Correct interface connection JSON documentation (used an object inste… <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1652> | 03:34 |
| mup | PR snapd#1653 opened: Correct documentation on refresh action (referred to an old update ac… <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1653> | 03:54 |
| mup | PR snapd#1654 opened: Fix typo mutlipart -> multipart <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1654> | 04:47 |
| === hikiko_ is now known as hikiko | ||
| mup | PR snapd#1654 closed: Fix typo mutlipart -> multipart <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1654> | 06:47 |
| mup | PR snapd#1652 closed: Correct interface connection JSON documentation (used an object inste… <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1652> | 06:50 |
| zyga | good morning | 06:53 |
| cpaelzer | good morning zyga | 07:08 |
| cpaelzer | I wonder is there a way to refer to snap paths like $SNAP_DATA from the snapcraft yaml when specifying commands | 07:11 |
| cpaelzer | I have a forking daemon, and wonder if I could modify it's "command" to include such | 07:12 |
| cpaelzer | that would allow to avoid a lot of glue-code just to pass the right config file directory | 07:12 |
| cpaelzer | I have seen in snappy-playpen others used a launcher.sh to pickup the path | 07:12 |
| cpaelzer | but there could (should?) be a way to do e.g. | 07:12 |
| cpaelzer | command: usr/local/sbin/ntpd -c $SNAP_DATA/etc/ntpd.conf | 07:12 |
| cpaelzer | maybe just the right amount of escaping ... | 07:13 |
| cpaelzer | the given example above resolves to just /etc/ntpd.conf for now | 07:13 |
| cpaelzer | hmm - just wondered about the ML archives - was the snappy-devel list discontinued for the snapcraft list? | 07:29 |
| cpaelzer | "Please use https://lists.ubuntu.com/mailman/listinfo/snapcraft instead." | 07:30 |
| cpaelzer | ah yes, ok | 07:30 |
| zyga | cpaelzer: hey | 07:34 |
| zyga | cpaelzer: the command field of each app should be able to resolve environment variables (they are just copied and eventually are resolved by the shell) | 07:35 |
| zyga | cpaelzer: hmm | 07:35 |
| zyga | cpaelzer: can you look at the prime directory and see if it is resolved early? My point is that it should be present there verbatim, as you spelled it above | 07:36 |
| cpaelzer | yeah I just examined the systemd service | 07:36 |
| cpaelzer | it is just referring to its "usual" warpper | 07:36 |
| zyga | cpaelzer: and it doesn't contain $SNAP_DATA? | 07:36 |
| cpaelzer | it does | 07:36 |
| cpaelzer | so the wrapper is "good" | 07:37 |
| cpaelzer | let me check all of this for typos and such | 07:37 |
| cpaelzer | exec "$SNAP/usr/local/sbin/ntpd" -c $SNAP_DATA/etc/ntpd.conf "$@" | 07:37 |
| zyga | cpaelzer: hmm cna you pastebin the systemd unit? | 07:37 |
| cpaelzer | sure, just a sec | 07:37 |
| cpaelzer | systemd http://paste.ubuntu.com/22782806/ wrapper http://paste.ubuntu.com/22782810/ | 07:37 |
| cpaelzer | uh that is nice | 07:38 |
| cpaelzer | zyga: I found it | 07:38 |
| cpaelzer | it is actually an application issie I think | 07:38 |
| cpaelzer | service snap.ntpsec.ntpd status reports 30780 /snap/ntpsec/x1/usr/local/sbin/ntpd -c /var/snap/ntpsec/x1/etc/ntpd.conf | 07:38 |
| cpaelzer | so it did resolve | 07:38 |
| zyga | yes, it looks correct | 07:38 |
| cpaelzer | I was tricked by seeing that in journal for it "getconfig: Couldn't open </etc/ntp.conf>: No such file or directory" | 07:39 |
| cpaelzer | so it is more an app bug to ignore its arg for whatever reason | 07:39 |
| dragly | Tried building and installing the ubuntu-clock-app example with snapcraft + snap install now. I get the following errors: "libGL error: failed to load driver: swrast" "Unrecognized OpenGL version". | 07:39 |
| cpaelzer | anyway it was good to go down the snap-systemd unit -> wrapper -> command path at least once | 07:39 |
| dragly | Should this work with the current version of snapcraft and snap? | 07:39 |
| cpaelzer | zyga: thanks | 07:39 |
| zyga | dragly: does the old version from the store work? | 07:40 |
| dragly | what's the name in the store? | 07:41 |
| zyga | dragly: ubuntu-calculator-app | 07:41 |
| dragly | can't find anything with that name in Ubuntu Software nor with apt | 07:43 |
| dragly | I'm running Ubuntu 16.04 | 07:43 |
| dragly | the one I tested was from https://github.com/ubuntu/snappy-playpen | 07:45 |
| cpaelzer | dragly: snap find clock gives me "ubuntu-clock-app" from the store | 07:48 |
| cpaelzer | trying to install now on my16.40 just to check | 07:49 |
| cpaelzer | dragly: fetch & install from store worked fine - was your issue that the one from playpen didn't build or install ? | 07:52 |
| dragly | ah, sorry, I forgot that snap install != apt install | 07:52 |
| dragly | cpaelzer: it both builds and installs, but when running I get the OpenGL errors | 07:53 |
| netphreak | hi, guys! | 07:53 |
| dragly | same with the one from "snap install ubuntu-clock-app" | 07:53 |
| cpaelzer | running the one from store http://paste.ubuntu.com/22783564/ (works) | 07:54 |
| netphreak | Anynews on Ubuntu core and RPI3? | 07:54 |
| dragly | cpaelzer: doesn't work here, seems to be the same issue as others are reporting: https://askubuntu.com/questions/759647/opengl-error-in-snaps-ubuntu-16-04/760096#760096 | 07:54 |
| dragly | I had the same issue previously, but thought it was fixed | 07:55 |
| dragly | I think there is a bug report on it somewhere. Let me see if I can dig it up. | 07:56 |
| dragly | cpaelzer https://bugs.launchpad.net/snappy/+bug/1574851 | 07:57 |
| mup | Bug #1574851: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851> | 07:57 |
| dragly | I haven't tried to workaround, but will be distributing an app to others with Nvidia machines, so I'm wondering if there's anything I can do without having to ask the users to copy the nvidia libGL.so to /var/lib/snapd/lib/gl ? | 07:59 |
| mvo | dragly: can you please try to install "snap-confine ubuntu-core-launcher" from xenial-proposed? that should fix the nvidia problem | 08:05 |
| seb128 | mvo, hey | 08:05 |
| zyga | mvo: I understand that there are some regressions that are blocking the update out of the SRU proposed pocket, correct? | 08:05 |
| mvo | hey seb128 | 08:05 |
| mvo | zyga: yes, however I think those got all resolved by now, I think its good to go now | 08:06 |
| zyga | mvo: including the one you pinged me about last week, the X11 one? | 08:07 |
| seb128 | mvo, attente, unsure when/where snapd-xdg-open was discussed but I would like to start a discussion about removing the whitelist, filed https://github.com/ubuntu-core/snapd-xdg-open/pull/12 for that but maybe a mailing list would be better? can you do suggestions? | 08:07 |
| mup | PR ubuntu-core/snapd-xdg-open#12: don't restrict the urls that are handled <Created by seb128> <https://github.com/ubuntu-core/snapd-xdg-open/pull/12> | 08:07 |
| mvo | zyga: yes, this no longer happens with snapd 2.11 and I think its was adt artifcat | 08:08 |
| mvo | seb128: iirc gustavo suggested to put this in place, he is probably the best one to discuss how to ease/remove it | 08:09 |
| zyga | mvo: that's good to know, thank you | 08:12 |
| seb128 | mvo, ok, thanks, I'm unsure what we protect against and ideally we are going to want to let apps open the urls they handle, like skype handles x-scheme-handler urls and you are going to want that to work without us having to patch the helper to know about every application on earth | 08:13 |
| seb128 | x-scheme-handler/skype I meant | 08:13 |
| mwhudson_ | mvo: did you get the "add to whitelist" syntax wrong on https://github.com/snapcore/snapd/pull/1651 ? | 08:16 |
| mup | PR snapd#1651: More create-user fixes <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1651> | 08:16 |
| mvo | mwhudson_: I did, thanks! should be fixed now | 08:17 |
| zyga | mwhudson_: congratulations to your family :) | 08:17 |
| mwhudson_ | zyga: thanks :) | 08:17 |
| mwhudson_ | mvo: i'm hacking on adding --sudoer and --yaml flags now | 08:18 |
| mwhudson_ | the 'details' link on the test results on my PR isn't working for me | 08:29 |
| mwhudson_ | "162.213.35.179 took too long to respond" | 08:29 |
| zyga | mwhudson_: on integration tests? | 08:32 |
| mwhudson_ | yeah | 08:32 |
| zyga | mwhudson_: that's over VPN | 08:32 |
| mwhudson_ | oh | 08:32 |
| zyga | mwhudson_: aka annoying ylink | 08:32 |
| mwhudson_ | not very community? | 08:33 |
| mwhudson_ | but not too bad for me :) | 08:33 |
| mwhudson_ | ah duh | 08:34 |
| mwhudson_ | zyga, mvo: what does snappy think about rebasing? | 08:34 |
| zyga | mwhudson_: doesn't like it much | 08:36 |
| zyga | mwhudson_: merges are more welcome | 08:36 |
| mwhudson_ | zyga: well my PR fails a test | 08:37 |
| zyga | mwhudson_: merge with master to fix it (if that fixes it) | 08:37 |
| mwhudson_ | zyga: i could rebase and fix the problem, or push a new commit | 08:37 |
| mwhudson_ | it's a real problem :) | 08:37 |
| zyga | oh, just push a new fixing commit then | 08:37 |
| mwhudson_ | ok | 08:38 |
| mwhudson_ | related | 08:38 |
| mwhudson_ | can i run the integration tests locally easily | 08:38 |
| mwhudson_ | ? | 08:38 |
| zyga | mwhudson_: sure | 08:38 |
| zyga | mwhudson_: with the exception of magic version of ubuntu-device-flash you should just be able to run run-tests --integration | 08:39 |
| zyga | mwhudson_: it's tad slow though | 08:39 |
| mvo | the u-d-f from http://people.canonical.com/~mvo/all-snaps/16/ should work with this | 08:39 |
| zyga | mwhudson_: maybe something has changed since I first looked, fgimenez knows this part better than I do | 08:39 |
| zyga | mwhudson_: so just staick that in your $PATH and you should be ok | 08:39 |
| zyga | s/staick/stick/ | 08:39 |
| mwhudson_ | ok | 08:40 |
| zyga | my link is laggy today, downloading some stuff for work later | 08:40 |
| imexil | Hi, is there a quick way to get out of "error: cannot remove "X": snap "ipe" has changes in progress" limbo | 08:42 |
| imexil | I already tried to restart snapd but that did not help | 08:42 |
| * mwhudson_ lols at the ascii art "crushing failure and despair" | 08:46 | |
| zyga | imexil: can you tell me what does "snap changes" say | 08:47 |
| imexil | well I cancelled an install with CTRL+C and that's what it is still doing. | 08:48 |
| zyga | imexil: unlike apt or yum, snapd remembers and retries requests | 08:48 |
| dragly | mvo: Sorry, I managed to overlook your message earlier. Installed snap-confine ubuntu-core-launcher now. | 08:48 |
| imexil | zyga: 123 Doing 2016-08-09T08:14:25Z - Install "ipe" snap from file "ipe_7.2.5_amd64.snap | 08:48 |
| dragly | Now ubuntu-clock-app.clock returns "multiple nvidia drivers detected, this is not supported. errmsg: No such file or directory" | 08:48 |
| zyga | imexil you just quit the front end, the backend (snapd) is still doing what you asked it to do | 08:48 |
| zyga | dragly: can you report a bug on snap-confine | 08:49 |
| zyga | dragly: with all the details you can add | 08:49 |
| imexil | zyga: so how do I kill the backend? | 08:49 |
| mvo | dragly: and pastebin "ls -d /usr/lib/nvidia*" please? | 08:49 |
| zyga | dragly: especially output of /usr/lib/nvidia-[1-9][0-9][0-9] | 08:50 |
| zyga | imexil: you don't have to | 08:50 |
| dragly | zyga: Sure! Do you happen to know what returns the error message so that I can try to figure out why it detects multiple versions? | 08:50 |
| dragly | I get /usr/lib/nvidia/ /usr/lib/nvidia-352/ /usr/lib/nvidia-361/ /usr/lib/nvidia-361-prime/ | 08:50 |
| zyga | imexil: what do you want toarchive? | 08:50 |
| zyga | *achieve | 08:50 |
| zyga | dragly: yes, I wrote that code :/ | 08:50 |
| dragly | The install on this machine is an upgrade, could that be why I have multiple nvidia versions in that folder? | 08:51 |
| imexil | zyga: well I can't do anything since it just sits there in limbo for 30 mins or more now | 08:51 |
| zyga | dragly: can you try rmeomving all except the one you actually want to use | 08:51 |
| zyga | imexil can you do this: snap abort 123 | 08:51 |
| zyga | (123 i the identifier of the task) | 08:51 |
| zyga | s/task/change/ | 08:51 |
| fgimenez | zyga, mwhudson_, mvo yep, with the new udf all should be fine to run the remaining integration tests (most of them have been ported to spread) | 08:51 |
| zyga | you can salso see snap change 123 | 08:51 |
| zyga | for details | 08:51 |
| imexil | zyga: Thanks! | 08:51 |
| imexil | That worked | 08:52 |
| === om26er__ is now known as om26er | ||
| zyga | imexil: note that if you had killed snapd it would just restart the next time and resumed the whole activity | 08:52 |
| imexil | I see. | 08:53 |
| mwhudson_ | i think http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/4144/console is going to make me very upset with adduser(1) | 08:55 |
| dragly | zyga: I tried to remove the nvidia-352 with "sudo apt remove nvidia-352" and also checked dpkg --get-selections for any other nvidia packages. However, the folder still remains. I'll remove it manually now, but I suspect the script might need to verify if multiple packages are really installed. | 08:56 |
| zyga | dragly: what is inside? | 08:56 |
| dragly | I currently only find libnvidia-fbc.so.1@ libnvidia-wfb.so.1 in the folder | 08:56 |
| dragly | two dead symlinks to libnvidia-fbc.so.352.63 and libnvidia-wfb.so.352.63 | 08:56 |
| zyga | dragly: you can use dpkg -S to find which package puts stuff inside that folder | 08:57 |
| zyga | dragly: yeah, please try to remove them | 08:57 |
| mwhudson_ | uh | 08:57 |
| dragly | seems like noone is taking responsibility for those files | 08:57 |
| mwhudson_ | how _do_ you add a user to a group with extrausers | 08:58 |
| zyga | dragly: then they must be created by postinstall scripts | 08:58 |
| dragly | now I'm back to the "libGL error: failed to load driver: swrast" | 08:59 |
| zyga | dragly: hmm | 09:00 |
| dragly | trying to update all packages with xenial-proposed now | 09:00 |
| dragly | I guess snapd should be updated too? | 09:00 |
| zyga | dragly: snapd doesn't affect this but sure | 09:02 |
| zyga | dragly: you can update it | 09:02 |
| zyga | dragly: I think someone with nvidia hardware of the same / similar era should be able to explore this bug in detail | 09:02 |
| mwhudson_ | can i d/l an ubuntu-core image yet? | 09:04 |
| mwhudson_ | oh, http://people.canonical.com/~mvo/all-snaps/16/ | 09:06 |
| dragly | zyga: Sure. I would also be happy to explore it further myself. Should any links have automatically been created in /var/lib/snapd/lib/gl/ with the above packages installed? Currently this folder is empty. | 09:07 |
| mwhudson_ | uh does libnss-extrausers just not support supplementary groups at all | 09:31 |
| dragly | Tried the workaround by copying the files from nvidia-* to /var/lib/snapd/lib/gl, but that didn't work either. | 09:33 |
| ogra_ | mvo, so i'm a bit desparate with my kernel snap creation ... whatever i try with u-d-f i can not get any working arm images (funnily kvm works, even if the kernel package isnt built correctly) ... when i mount a pi2 or dragonboard image after dd'ing i end up with: | 09:51 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/ | 09:51 |
| ogra_ | unset | 09:51 |
| zyga | dragly: re, sorry I was on a call | 09:52 |
| zyga | dragly: it is a bit magic, you need to read this to understand what is going on | 09:52 |
| zyga | dragly: http://www.zygoon.pl/2016/08/snap-execution-environment.html | 09:52 |
| zyga | dragly: the only way to see the actual environment is to experience it at runtime, try the hello world snap or anything that includes bash (I use snapd-hacker-toolbelt snap) | 09:53 |
| zyga | dragly: then you can see what the /var/lib/snapd/lib/gl folder really contains | 09:53 |
| zyga | dragly: you should also, after you get familiar with the ideas, look at github.com/snapcore/snap-confine | 09:53 |
| zyga | dragly: there's src/mount-support-nvidia.c there that does all the nvidia work | 09:54 |
| zyga | dragly: so please explore that and get in touch when you have some ideas | 09:54 |
| mvo | ogra_: is this a sideloaded kernel? | 09:54 |
| ogra_ | yes | 09:54 |
| ogra_ | i didnt want to upload potentially broken ones to the store | 09:54 |
| om26er | I am running snappy on my RPi2 after a while, seems there is no longer enable-classic command ? Was that removed or is that another way for that ? | 09:55 |
| ogra_ | (and currently my kernel build script is broken wrt pi2 so i cant quickly give you something to test) | 09:56 |
| mvo | ogra_: aha, ok. I think that is the issue, i.e. a bug in that code path | 09:56 |
| om26er | downloaded from https://people.canonical.com/~mvo/all-snaps/16/ | 09:56 |
| ogra_ | ah, phew | 09:56 |
| ogra_ | mvo, another thing ... did you ever try to reboot a kvm image 3-4 times ? | 09:56 |
| zyga | hey ogra_ how are you doing? :-) | 09:56 |
| ogra_ | about the 3rd time it wipes the grub variables | 09:57 |
| zyga | ogra_: magic broken grub thing? | 09:57 |
| mvo | ogra_: I have a vague idee what it is, I can give you something in maybe 1h or so, just ping me when you have your script ready again | 09:57 |
| ogra_ | yeah | 09:57 |
| ogra_ | mvo, ok | 09:57 |
| mvo | om26er: please try "snap install classic" | 09:57 |
| mvo | ogra_: uh :( does it happen if you randomly reboot in the middle of the boot process? | 09:57 |
| mvo | ogra_: or normal reboots? | 09:57 |
| ogra_ | normal reboots | 09:57 |
| ogra_ | fresh install, do the first boot and check you can log in ... reboot ... do that again ... grub dead | 09:58 |
| mvo | ogra_: ta, I have a look | 09:58 |
| ogra_ | i forgot if it is the second or third time ... but it is reliably reproducable | 09:58 |
| mvo | ta | 09:58 |
| * zyga recalls checkbox reboot stress test (just 30 reboots) | 09:58 | |
| om26er | mvo, says snap not found | 09:59 |
| ogra_ | yeah, that would have hit it quickly | 09:59 |
| mvo | om26er: sorry, "sudo snap install --devmode classic" | 09:59 |
| ogra_ | om26er, --devmode --edge | 09:59 |
| om26er | ogra_, does --edge give me yakketty ? | 09:59 |
| mwhudson_ | uh uh is /etc/sudoers.d supposed to be writable? | 10:00 |
| ogra_ | mvo, also, if you check the store ... ubuntu-core auto-uploads work ... i talked to jdstrand_ about getting an exception into the review tools to auto-publish (i was hoping it was done today, seems not... i should have turned off auto-build :) ) | 10:00 |
| ogra_ | mwhudson_, yes, cloud-init needs to put a file in there | 10:00 |
| dragly | zyga: Ok, thanks. I'll try to package a bash script and see what I can figure out. | 10:01 |
| ogra_ | om26er, no, yakkerty is dead beef ... all channels are xenial ... edge is just the test channel | 10:01 |
| mwhudson_ | oh right | 10:01 |
| * mwhudson_ was being dumb | 10:01 | |
| zyga | dragly: you can use my snapd-hacker-toolbelt snap | 10:02 |
| zyga | dragly: just install it and run snapd-hacker-toolbelt.busybox sh | 10:02 |
| zyga | dragly: then explore | 10:02 |
| === hikiko is now known as hikiko|ln | ||
| dragly | Great! | 10:07 |
| === mwhudson_ is now known as mwhudson | ||
| morphis | ogra_: do I have to change any configuration file to enable the pi3 serial console with your image? | 10:33 |
| ogra_ | morphis, nope, serial is the default | 10:34 |
| morphis | hm | 10:34 |
| ogra_ | works here ... | 10:34 |
| morphis | 115200 8n1? | 10:34 |
| ogra_ | yeah | 10:34 |
| ogra_ | (i just use screen for that: screen /dev/ttyUSB0 115200) | 10:35 |
| morphis | let me verify my pin connection | 10:36 |
| ogra_ | third pin is ground ... | 10:36 |
| morphis | ogra_: following https://www.element14.com/community/servlet/JiveServlet/previewBody/73950-102-10-339300/pi3_gpio.png?01AD=3qQ4vBf_OyjHCgCsVfVCaOLElbWZscIAIt5xnDSIb_jh1EytwTHJ-Ag&01RI=4BD464EBE91DD68&01NA=na | 10:36 |
| ogra_ | yeah | 10:36 |
| morphis | and https://www.sparkfun.com/products/9873 | 10:39 |
| ogra_ | ah, i just use a cable ... | 10:42 |
| morphis | hm | 10:45 |
| === jibel_ is now known as jibel | ||
| morphis | ogra_: works | 10:48 |
| morphis | my fault | 10:48 |
| ogra_ | phew | 10:48 |
| mup | PR snapd#1655 opened: integration-tests: look for ubuntu-device-flash on PATH before calling sudo <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1655> | 10:48 |
| morphis | ogra_: ok, a manual ifdown/ifup makes ethernet working | 10:59 |
| ogra_ | yeah, there is some race that mwhudson filed a bug about (cant find it atm) | 11:00 |
| zyga | Son_Goku: hey, I cracked the go-xgettext issue | 11:01 |
| zyga | Son_Goku: I pushed the package to github.com/zyga/snapcore-fedora, just doing local builds in mock to ensure it is good | 11:05 |
| === hikiko|ln is now known as hikiko | ||
| Son_Goku | zyga, sweet | 11:20 |
| zyga | Son_Goku: morning :) | 11:34 |
| === chihchun is now known as chihchun_afk | ||
| zyga | Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1359802#c9 | 11:45 |
| ogra_ | sergiusens, marking bugs as inclomplete but not asking for and info ? (bug 1608432) | 11:45 |
| mup | Bug #1608432: snaps with type: os should allow publishing of .manifest files <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432> | 11:45 |
| ogra_ | s/and/any/ | 11:46 |
| Son_Goku | zyga, approved | 11:49 |
| zyga | Son_Goku: woot, thank you, looking at snap-confine now | 11:51 |
| Son_Goku | you should go ahead and import go-xgettext and prepare the bodhi things now | 11:52 |
| Son_Goku | Bodhi has now been activated for F25, too | 11:52 |
| zyga | yep, I read the mail today | 11:53 |
| zyga | I see a few things that rpmlint reports on snap-confine, I'll do as you said and then return to snap-confine | 11:53 |
| === DanChapman_ is now known as DanChapman | ||
| * zyga returned from small lunch :-) | 12:20 | |
| zyga | Son_Goku: package requested, focusing on snap-confine now | 12:23 |
| morphis | ogra_: what are you building the pi3 kernel snap from? is there a snapcraft.yaml? | 12:23 |
| zyga | Son_Goku: someone finally updated pkgdb code to select rpms by default (instead of the docker images) :-) | 12:24 |
| Son_Goku | yeah | 12:24 |
| Son_Goku | that drop down is going to be get really annoying | 12:24 |
| Son_Goku | especially once we have modules :/ | 12:24 |
| Son_Goku | and if the snapcraft stuff gets done, snaps too | 12:25 |
| zyga | I heard about modules last week but I didn't dig into it, what are they? | 12:25 |
| Son_Goku | zyga, they're some abstract definition of a collection of software that provide a specific capability | 12:29 |
| Son_Goku | for now, a module is a definition that pulls in a bunch of RPMs and generates a self-contained repository of them | 12:30 |
| Son_Goku | and when you install a module, it installs all of the repository | 12:30 |
| Son_Goku | I'm not entirely sure why we're doing this, since (to me) it looks like it's the same thing as the comps groups (composition groups) | 12:30 |
| zyga | Son_Goku: looks like old package collections | 12:31 |
| * Son_Goku shrugs | 12:31 | |
| Son_Goku | https://fedoraproject.org/wiki/Modularity | 12:31 |
| ogra_ | morphis, it is the pi2 kernel actually (same thing, just additional FW for the pi3 is needed) | 12:35 |
| ogra_ | morphis, this is the (currently still broken) attempt to roll automated kernel snaps https://code.launchpad.net/~ogra/+junk/kernel-test-snap ... https://code.launchpad.net/~ogra/+snap/kernel-test-snap | 12:36 |
| ogra_ | the original code for this lives in livecd-rootfs in the live-build/auto/build script | 12:37 |
| sergiusens | ogra_ I did reply to that | 12:38 |
| sergiusens | ogra_ hmm, didn't make it through :-/ | 12:38 |
| zyga | Son_Goku: does this look sensible http://pastebin.ubuntu.com/22798002/ | 12:39 |
| zyga | Son_Goku: I see the setuid bit, the setgroups that is actually desired in this case (I checked with the security team) and the script in /lib/udev/ | 12:39 |
| Son_Goku | does snap-confine not support using capabilities in-place of setuid? | 12:40 |
| zyga | Son_Goku: capabilities? | 12:40 |
| Son_Goku | https://fedoraproject.org/wiki/Features/RemoveSETUID | 12:40 |
| zyga | Son_Goku: well, I'm not sure | 12:40 |
| zyga | Son_Goku: let me check | 12:41 |
| zyga | oh, I see | 12:41 |
| zyga | cool, let me try | 12:41 |
| zyga | it *probably* is enough | 12:41 |
| zyga | though snap-confine still checks for uid == 0 | 12:41 |
| zyga | I think that check is obsolete when capabilities are in use | 12:42 |
| Son_Goku | if it supports using file capabilities instead of needing setuid/setgid bits, then you should probably adjust the build system to offer the choice | 12:43 |
| Son_Goku | both SUSE and Fedora prefer caps over setuid/setgid | 12:43 |
| zyga | Son_Goku: upstream code doesn't support this yet but it seems easy enough to implement | 12:44 |
| Son_Goku | cool | 12:44 |
| zyga | Son_Goku: where are the authoritative caps I can use? | 12:44 |
| zyga | I see Invalid capability: cap_setuid,cap_dac_override,cap_sys_admin | 12:45 |
| zyga | +%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin) %{_libexecdir}/snap-confine | 12:45 |
| Son_Goku | I think file caps are documented in the capabilities manpage | 12:45 |
| Son_Goku | man 7 capabilities | 12:45 |
| zyga | thanks | 12:45 |
| Son_Goku | zyga, also, it should be /usr/libexec/snapd | 12:47 |
| Son_Goku | err | 12:47 |
| Son_Goku | ... /usr/libexec/snapd/snap-confine | 12:47 |
| Son_Goku | snap-confine needs to be in a folder in /usr/libexec | 12:47 |
| zyga | noted, let me change that | 12:48 |
| Son_Goku | it's essentially the same rule as in debian, except we actually use /usr/libexec for helper programs | 12:49 |
| Son_Goku | instead of stuffing them into /usr/lib | 12:49 |
| Son_Goku | honestly don't know why debian hasn't adopted it, especially since it's now part of the FHS spec as an optional component | 12:49 |
| timothy | libexec is not present in hier anymore | 12:49 |
| Son_Goku | yes it is | 12:49 |
| Son_Goku | FHS 3.0 includes it | 12:49 |
| timothy | drizzt@liara ~ % man hier | grep libexec | 12:50 |
| timothy | drizzt@liara ~ % | 12:50 |
| Son_Goku | https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html | 12:50 |
| * zyga tries to guess the %caps() syntax | 12:51 | |
| timothy | To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself. | 12:51 |
| Son_Goku | timothy, yes, I know | 12:52 |
| Son_Goku | hence "optional" | 12:52 |
| timothy | for example systemd uses /usr/lib/systemd by default :) | 12:52 |
| zyga | Son_Goku: https://fedoraproject.org/wiki/How_to_create_an_RPM_package talks about %caps(cap_net_admin=pe) FOO.BAR | 12:53 |
| zyga | Son_Goku: do you know what =pe is for? | 12:53 |
| Son_Goku | nope | 12:53 |
| Son_Goku | we're getting into weird stuff now :) | 12:53 |
| Son_Goku | one sec | 12:53 |
| * zyga googles | 12:53 | |
| Son_Goku | dwalsh is online on #fedora-devel | 12:53 |
| Son_Goku | you could ask him | 12:53 |
| zyga | yep, let's try that | 12:53 |
| Ursinha | where do I report issues with the docs? in tour instructions, to be precise | 12:53 |
| Son_Goku | he's usually the guy to turn to on these things | 12:53 |
| mup | Bug #1611287 opened: provide canonical way to install templates and configuration files into $SNAP_* dirs <Snapcraft:New> <Snappy:New> <snappy (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611287> | 12:54 |
| renatu | I am trying to create a snap for EDS and I am using "plugin: autotools configflags: [..]". It is running configure with the correct flags. But looks like it is trying to use the configflags as gcc arg as well. | 12:55 |
| renatu | Which is causing problems | 12:55 |
| renatu | like that: gcc-5.real: error: unrecognized command line option ‘--sysconfdir=/etc’ | 12:55 |
| renatu | How I can solve that? | 12:55 |
| timothy | renatu: i's not an autoconfig configure | 12:56 |
| renatu | timothy, what you mean? | 12:58 |
| zyga | renatu: maybe it is a configure script but it is not a real autoconf configure script | 12:59 |
| zyga | renatu: but a hand-written one | 13:00 |
| renatu | zyga, timothy, I am using the same flags that I found in debian/rules: DEB_CONFIGURE_EXTRA_FLAGS += [...] | 13:04 |
| timothy | renatu: as CFLAGS or what? | 13:04 |
| renatu | I did not see any special case | 13:05 |
| renatu | this is the full log: http://paste.ubuntu.com/22799750/ | 13:05 |
| timothy | yes, you are passing configure flags as CFLAGS | 13:06 |
| renatu | timothy, how I can avoid that? | 13:07 |
| timothy | what is you yaml file? | 13:07 |
| renatu | timothy, http://paste.ubuntu.com/22799877/ | 13:07 |
| dpb1 | hey guys: anyone know the story here: https://bugs.launchpad.net/snappy/+bug/1611078 installing snaps in containers needs some more tricks? | 13:11 |
| mup | Bug #1611078: could not install hello-world snap in lxd container <landscape> <Snappy:New> <https://launchpad.net/bugs/1611078> | 13:11 |
| ogra_ | cjwatson, do you have an opinion about bug 1608432 ? (specifically about sergiusens' comment) | 13:15 |
| mup | Bug #1608432: snaps with type: os should allow publishing of .manifest files <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432> | 13:15 |
| === JanC is now known as Guest75507 | ||
| === JanC_ is now known as JanC | ||
| cjwatson | ogra_: it would make more sense to do it in launchpad-buildd, since that has the build tree right there | 13:18 |
| ogra_ | cjwatson, ok, any preference for the location or the naming ? | 13:20 |
| ogra_ | (do you want me to sort the full naming scheme and just put it in meta/ so you can just blindly cp *.manifest) | 13:21 |
| cjwatson | ogra_: well, could be even simpler | 13:21 |
| cjwatson | ogra_: can you just write another file to the same output directory that the .snap is written to? | 13:21 |
| cjwatson | ogra_: (it would certainly be best if launchpad-buildd didn't have to have a pile of naming logic in it) | 13:22 |
| ogra_ | i can try to, yes (the files already exist i think. live-build hasnt changed in that regard and i dont explicitly remove them) | 13:22 |
| qengho | Cool if that manifest had a checksum in it too. | 13:22 |
| cjwatson | ogra_: launchpad-buildd would have to whitelist the file too | 13:22 |
| cjwatson | if entry.endswith(".snap") and not os.path.islink(path): | 13:22 |
| cjwatson | self._slave.addWaitingFile(path) | 13:22 |
| Son_Goku | timothy, systemd was granted an exception back in 2012 in Fedora | 13:23 |
| Son_Goku | it's not allowed without good reason | 13:23 |
| timothy | claro | 13:24 |
| ogra_ | hmm, i see: | 13:24 |
| ogra_ | [2016-08-08 04:33:53] lb_binary_manifest | 13:24 |
| ogra_ | P: Begin creating manifest... | 13:24 |
| cjwatson | Son_Goku: Debian never adopted /usr/libexec basically because it would have been a ton of work for negligible benefit | 13:24 |
| ogra_ | but i dont see the .manifest file anywhere (i thought i had some "ls" in the build to show the output dir) | 13:24 |
| ogra_ | i need to check that | 13:24 |
| Son_Goku | what work? even debhelper still sets it by default | 13:24 |
| cjwatson | it's hardly that simple | 13:25 |
| Son_Goku | the debian maint stuff overrides that explicitly | 13:25 |
| cjwatson | lots of little details of hardcoded paths etc. | 13:25 |
| cjwatson | and nobody felt it was important | 13:25 |
| fginther | Is there an official snappy app store? | 13:26 |
| fginther | a browsable URL? | 13:27 |
| ogra_ | fginther, only https://uappexplorer.com/apps?sort=relevance&type=snappy | 13:27 |
| fginther | ogra_, thanks | 13:28 |
| ogra_ | (semi official ... (i.e. even linked from official pages but run by a community member) | 13:28 |
| ogra_ | ) | 13:28 |
| Ursinha | ogra_: that says is unofficial | 13:28 |
| ahasenack | where does it get its data from? API calls to the snap store? | 13:28 |
| ogra_ | Ursinha, and it is ... but we link to it from i.e. snapcraft.io because we have no better alternative | 13:29 |
| qengho | fginther: $ snap find ... | 13:29 |
| ogra_ | Ursinha, thus "semi official" :) | 13:29 |
| qengho | fginther: It reproduces the search queries that "snap find" uses. There's a RESTy API for the store. | 13:30 |
| ogra_ | well, snap find wont give you anything if you dont use a query string | 13:30 |
| ogra_ | so getting all snaps available is currently impossible via snap find | 13:30 |
| Ursinha | ogra_: right | 13:31 |
| * Ursinha tcpdumps to find the actual API call | 13:31 | |
| Ursinha | :) | 13:31 |
| ogra_ | lol | 13:31 |
| stokachu | how can you specify the SNAP_USER_DATA in the snapcraft.yaml so that built files can be placed there | 13:32 |
| stokachu | and accessed during runtime | 13:32 |
| ogra_ | i dont think you can | 13:33 |
| ogra_ | (in snapcraft.yaml at least) | 13:33 |
| ogra_ | you can use it in a wrapper script for your binary though | 13:33 |
| stokachu | so the issue is we're building some dll's with dotnet that gets created during build | 13:33 |
| stokachu | but we need to have the lockfile writeable when someone runs our snap and that happens in the same directory as our build | 13:34 |
| zyga | stokachu: you cannot because that happens at runtime not at build time | 13:35 |
| zyga | stokachu: just use a wrapper for your apps/services that copy data there if missing | 13:35 |
| stokachu | ok | 13:35 |
| zyga | stokachu: SNAP_USER_DATA is not a part of the snap | 13:36 |
| zyga | stokachu: it's not in the squashfs file | 13:36 |
| zyga | stokachu: so you cannot place anything there at build time | 13:36 |
| stokachu | ok, makes sense | 13:36 |
| mup | PR snapcraft#716 opened: Add Waf plugin (LP: #1611335) <Created by cpaelzer> <https://github.com/snapcore/snapcraft/pull/716> | 13:37 |
| balloons | is a new release planned soon? | 13:45 |
| la_juyis | hi popey, for compiling mono would you recommend a plugin different than autotools? | 13:45 |
| mup | Bug #1611384 opened: Change detection not working, have to "snapcraft clean" between builds when modifying snap contents <Snappy:New> <https://launchpad.net/bugs/1611384> | 13:49 |
| sergiusens | balloons fighting adt and yakkety even as worthless as it is to release to yakkety for us | 13:49 |
| sergiusens | same old same old fighting build systems for days | 13:49 |
| * sergiusens cannot wait for snapcraft to be released as a snap | 13:49 | |
| sergiusens | but work needs to happen for that to be viable | 13:49 |
| balloons | sergiusens, yuck. I'm sorry to hesar that. I know all about | 13:49 |
| ogra_ | sergiusens, is it actually worthless for snapcraft ? (i imagine yakket users might want to roll snaps too) | 13:50 |
| ogra_ | it likely is useless for snapd | 13:50 |
| sergiusens | ogra_ snaps that might or might not work as the base is different | 13:51 |
| ogra_ | well, you'd have to add libc to stage-packages for sure | 13:52 |
| ogra_ | but the rest should still work i imagine | 13:52 |
| jamespage | o/ | 13:55 |
| mup | PR snapd#1656 opened: snap: do not sort the result of `snap find` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1656> | 13:56 |
| zyga | sergiusens: hey, what are your plans to let snapcraft consume RPMs? | 13:57 |
| popey | la_juyis: I haven't built any mono things yet, sorry | 13:59 |
| ogra_ | popey only builds stereo :) | 13:59 |
| matteo | don't worry, be snappy ;) | 14:00 |
| ogra_ | ! | 14:00 |
| dpb1 | I don't want that song in my head | 14:00 |
| dpb1 | :) | 14:00 |
| matteo | LOL | 14:00 |
| jamespage | ok folks - so I did a simple bit of openstack and snapped the nova compute control plane services - that works OK | 14:01 |
| jamespage | going for the harder one now - specifically nova-compute - which will have to interface to libvirt or lxd and openvswitch or <insert sdn choice here> | 14:01 |
| jamespage | anyone looked at snapping libvirt yet? | 14:01 |
| jamespage | nova would need to access the local libvirt socket, and allow libvirt to consume qcow2 disk files that its sourced and setup | 14:02 |
| ogra_ | jamespage, well, there would have to be an interface that provides libvirt access for your snap | 14:04 |
| ogra_ | (you can not access anything outside of your snap without an interface) | 14:05 |
| jamespage | yeah got that bit - so something like 'libvirt-manage' or suchlike | 14:06 |
| jamespage | maybe 'libvirt-control' inline with other interfaces | 14:06 |
| zyga | dpb1: let it snow, let it snap ;-) | 14:08 |
| mup | PR snapd#1657 opened: tests: add udev rules spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1657> | 14:08 |
| mup | PR snapd#1658 opened: partition: fix cleaning of the boot variables on the second good boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/1658> | 14:08 |
| sergiusens | zyga they are plans; it will happen when I get kyrofa back | 14:10 |
| sergiusens | so I can dive into that and not fix all the minor problems everyone runs into | 14:10 |
| zyga | sergiusens: understood, thanks | 14:11 |
| mvo | ogra_: the bug about cleaning the boot vars is fixed (well, PR is up) | 14:14 |
| jamespage | ogra_, is there an existing interface that allows a snap to share a directory with other snaps? | 14:17 |
| jamespage | so nova-compute could expose a slot to allow libvirt to access its qcows2's for example | 14:17 |
| zyga | jamespage: content | 14:19 |
| jamespage | zyga, ta | 14:19 |
| zyga | jamespage: but it cannot be used to share anything in $SNAP_DATA yet | 14:19 |
| zyga | jamespage: but AFAIK that is the plan, for now it can only be used to share $SNAP | 14:19 |
| zyga | jamespage: (or a fraction of $SNAP) | 14:20 |
| jamespage | zyga, it would need to be the writable area that was sshared | 14:20 |
| jamespage | so $SNAP_COMMON I think for this instance | 14:20 |
| jamespage | as the data is not specific to a version of the snap | 14:20 |
| zyga | jamespage: I see, in both cases it would require new code in snapd | 14:21 |
| ogra_ | mvo, great, thanks ! | 14:21 |
| * zyga focuses on snap-confine capabilities | 14:25 | |
| jamespage | stgraber, do you have a lxd snap yet? | 14:28 |
| camako | folks, in the yaml, is there a way to copy a file under multiple names? Something like this ---> http://pastebin.ubuntu.com/22805771/ | 14:29 |
| jdstrand_ | zyga: you'll need to think through using fscaps. the fs needs to support xattrs. snaps are typically built with -no-xattrs. the core snap may or may not be (I don't know), but if it is, the fscaps will be stripped for all snaps | 14:29 |
| jdstrand_ | zyga: s/all snaps/all snap systems/ | 14:30 |
| === jdstrand_ is now known as jdstrand | ||
| zyga | jdstrand: this is just for fedora (and perhaps suse) when snap-confine is packaged in the distribution-native format | 14:33 |
| zyga | jdstrand: I'm trying to wrap my head around https://lwn.net/Articles/528542/ | 14:33 |
| mup | PR snapd#1653 closed: docs: fix references to refresh action <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1653> | 14:33 |
| === matiasb1 is now known as matiasb | ||
| zyga | jdstrand: nothing I'm doing is changing snap-confine anywhere else | 14:34 |
| zyga | jdstrand: and I must say, the way caps work makes me want to shout and run :) | 14:35 |
| zyga | jdstrand: I will build a test app that shows all capabilities set and see how it behave | 14:35 |
| zyga | *behaves | 14:35 |
| camako | dholbach, thanks for reviewing the mesa-demos snap. I see that it failed for you. What GPU do you have? | 14:36 |
| dholbach | camako, i915 | 14:37 |
| dholbach | in an x220 if that matters | 14:37 |
| camako | dholbach, hmm interesting... Also, I'm not sure why this dir doesn't exist in your snap --> /snap/mesa-demos/x1/egl/opengles2 | 14:39 |
| camako | do you at least have /snap/mesa-demos/x1 ? | 14:39 |
| dholbach | camako, http://paste.ubuntu.com/22806726/ | 14:40 |
| cjwatson | ogra_: so I can easily enough do http://paste.ubuntu.com/22806674/, but let me know first if you manage to get something spitting out the file to the right place | 14:40 |
| === ycheng is now known as ycheng-ark | ||
| camako | dholbach, I think I'm missing egl/gles packages in the snap... I'm assuming the gl apps worked for you (mesa-demos.{gears|teapot})? | 14:43 |
| dholbach | they do! :) | 14:44 |
| stgraber | jamespage: kinda | 14:44 |
| stgraber | jamespage: snap install --edge --devmode lxd | 14:44 |
| stgraber | jamespage: that will work, but we still need to sort out the interface we need and get some bits done on the snapd side (socket activation and group management at least) | 14:44 |
| jamespage | stgraber, ack | 14:45 |
| jamespage | stgraber, 'lxd-control' type or something I guess | 14:45 |
| jamespage | stgraber, just thinking about a nova-compute snap | 14:45 |
| jamespage | :) | 14:45 |
| stgraber | jamespage: yeah, so we'll have a lxd interface which will both allow lxd to do all that it needs and will allow other snaps to connect to it | 14:46 |
| stgraber | jamespage: it's not going to auto-connect for obvious security reasons, so you'll have to install the nova-compute snap, and then use "snap connect" to attach to the lxd interface so you can drive it | 14:47 |
| jamespage | stgraber, I was making that assumption | 14:47 |
| jamespage | good | 14:48 |
| mup | PR snapcraft#717 opened: fix checker errors to let runtests.sh pass again <Created by cpaelzer> <https://github.com/snapcore/snapcraft/pull/717> | 14:52 |
| ogra_ | cjwatson, i can surely get it there (might need some test builds, but effectively it is just the builddir) | 15:10 |
| elopio | mhall119: do you have a project that fails because of https://github.com/snapcore/snapcraft/pull/688 ? | 15:12 |
| mup | PR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/688> | 15:12 |
| elopio | well, that failed before your patch. | 15:12 |
| sergiusens | elopio the arduino thing | 15:12 |
| sergiusens | look at his g+ | 15:12 |
| mup | PR snapd#1659 opened: wrappers: ensure services have a valid SNAP_USER_DATA dir <Created by mvo5> <https://github.com/snapcore/snapd/pull/1659> | 15:12 |
| SamYaple | https://github.com/snapcore/snapcraft/pull/657 | 15:13 |
| mup | PR snapcraft#657: Add constraints to python2 plugin <Created by SamYaple> <Conflict> <https://github.com/snapcore/snapcraft/pull/657> | 15:13 |
| SamYaple | im goign to assume 5 days to complete teh tests is not normal... | 15:14 |
| SamYaple | how do i trigger a recheck? | 15:14 |
| sergiusens | SamYaple let me check | 15:16 |
| sergiusens | SamYaple oh, travis even | 15:17 |
| sergiusens | SamYaple can you do a noop commit --amend and push to trigger? travis didn't even assign it a job to retrigger | 15:17 |
| SamYaple | okie dokie. will do. ill get it going again | 15:18 |
| elopio | sergiusens: https://gist.github.com/elopio/a749810edd9a80517b46ace63d45b166 This is the testing for the SRU. | 15:21 |
| elopio | ppisati: can you give me please the steps you are following to build the kernel snaps? | 15:22 |
| ppisati | elopio: e.g. git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial | 15:24 |
| ppisati | elopio: git checkout master-next (beucase it contains the snapcraft.yaml file) | 15:25 |
| ppisati | elopio: and then execute snapcraft | 15:25 |
| ppisati | elopio: bear in my mind that you need *at least* one patch | 15:25 |
| ppisati | elopio: to cope with the vmlinuz -> kernel.img rename | 15:25 |
| ppisati | elopio: http://paste.ubuntu.com/22810646/ | 15:26 |
| ppisati | this is the snapcraft patch | 15:26 |
| ppisati | with this, it won't boot at all | 15:26 |
| ppisati | nonetheless, it'll hang during the initrd phase ATM, i'm trying to debug why | 15:26 |
| elopio | thank you! | 15:27 |
| ppisati | i need to compare the snap created using the snapcraft's plugin vs ogra's kernel snap | 15:28 |
| ppisati | ogra's kernel work are ok, snapcraft's kernel plugin hangs @ initrd | 15:28 |
| ogra_ | weird | 15:28 |
| ppisati | ogra_: indeed | 15:28 |
| ppisati | ogra_: do you have a kernel snap somewhere that i can use? | 15:28 |
| ogra_ | did you try just dumping my initrd into your sanp ? | 15:28 |
| ppisati | ogra_: if i can get my hand on your snap, yes | 15:29 |
| ppisati | i mean, i'll do | 15:29 |
| ogra_ | ppisati, i think this pone worked | 15:29 |
| ppisati | ogra_: which one? | 15:30 |
| ogra_ | lol | 15:31 |
| ogra_ | https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2559 | 15:31 |
| ppisati | k, me tris that | 15:31 |
| ppisati | *tries | 15:31 |
| mup | Bug #1611424 opened: Additional "lts" channel or support for upstream series <lxd> <Snappy:New> <https://launchpad.net/bugs/1611424> | 15:31 |
| ogra_ | sorry, pasted the url into the terminal instead of the irc client :P | 15:31 |
| ali1234 | how do i write new interfaces? | 15:31 |
| ogra_ | i'm trying alongside ... | 15:32 |
| ogra_ | ali1234, zyga had a series of blog posts about that somewhere | 15:32 |
| mhall119 | elopio: yes, it was arduino | 15:32 |
| elopio | mhall119: can I get the link to the snapcraft please? | 15:32 |
| ali1234 | i need a bunch of sysfs access | 15:32 |
| ali1234 | gpio, backlight, maybe iio | 15:33 |
| ali1234 | and i2c-dev | 15:33 |
| ogra_ | gpio is in the works | 15:33 |
| ali1234 | and spidev | 15:33 |
| mhall119 | elopio: https://github.com/ubuntu/snappy-playpen/tree/arduino/arduino | 15:33 |
| ogra_ | (and i think i2c as well) | 15:33 |
| elopio | ty. | 15:33 |
| ali1234 | also i need device tree overlays working | 15:33 |
| ali1234 | bug 1607447 | 15:34 |
| mup | Bug #1607447: Please install device tree overlays <apport-bug> <armhf> <xenial> <linux-meta-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1607447> | 15:34 |
| ogra_ | thats a problem until we can make them fully work in uboot (for which i currently dont have the time) | 15:34 |
| ali1234 | just let the blob load them and don't mess with it | 15:34 |
| ogra_ | (i know there was upstream work for generic overlay support) | 15:34 |
| ogra_ | the overlays are in the pi2-kernel snap | 15:35 |
| ali1234 | cool | 15:35 |
| ali1234 | is that usable yet? | 15:35 |
| ogra_ | but you still need to copy them around manually | 15:35 |
| ogra_ | (they have always been there) | 15:35 |
| ali1234 | they aren't in the classic image | 15:35 |
| ogra_ | ah, classic | 15:35 |
| ogra_ | yeah, never touched that :P | 15:35 |
| ali1234 | unless they are really well hidden | 15:35 |
| ogra_ | under lib/firmware/device-tree | 15:36 |
| ogra_ | that is where i drag them from in the snap creation | 15:37 |
| ogra_ | ppisati, tested again., that snap boots here | 15:37 |
| ali1234 | well that's not very much use. they need to be on the fat partition or the bootloader can't see them | 15:38 |
| elopio | fgimenez: do we have the hubot deployed somewhere? | 15:38 |
| ogra_ | ppisati, that was built using https://code.launchpad.net/~ogra/+junk/kernel-test-snap rev 36 | 15:38 |
| ogra_ | ali1234, so you need to copy them there | 15:39 |
| ogra_ | not different to the snap image | 15:39 |
| ali1234 | that directory doesn't exist on the classic image, what package do they belong to? | 15:39 |
| ogra_ | just a different location to copy from | 15:39 |
| ogra_ | they shoould be in the linux-image-raspi2 | 15:39 |
| ali1234 | they aren't | 15:39 |
| ogra_ | or linux-image-$version-raspi2 rather | 15:40 |
| ogra_ | well, i pull them from there | 15:40 |
| ppisati | ah! | 15:40 |
| ppisati | ogra_: ok, i installed your vanilla pc-kernel snap | 15:40 |
| ppisati | ogra_: same exact problem upon boot | 15:40 |
| ali1234 | how can linux-image install things in /lib/firmware? everything in it needs to be versioned? | 15:41 |
| ogra_ | ali1234, http://paste.ubuntu.com/22812010/ | 15:41 |
| fgimenez | elopio, not currently, we had it while testing a not landed PR, whith the last wipeouts of the cluster it went away | 15:41 |
| ogra_ | thats the code that copies them in livecd-rootfs | 15:41 |
| balloons | is there a snapcraft whomai command? in other words, what's my login creds? | 15:41 |
| ogra_ | ppisati, what u-d-f and what channel do you use ? | 15:41 |
| fgimenez | elopio, this should be enough to redeploy it https://github.com/ubuntu-core/snappy-jenkins/pull/164/files | 15:41 |
| mup | PR ubuntu-core/snappy-jenkins#164: hubot <Created by fgimenez> <Conflict> <https://github.com/ubuntu-core/snappy-jenkins/pull/164> | 15:41 |
| ppisati | ogra_: i'm using mvo's all-snaps-amd64 img, scp the snap over and installing it | 15:42 |
| elopio | fgimenez: awesome, thanks. | 15:42 |
| sergiusens | balloons no, but that warrants a wishlist bug ;-) | 15:42 |
| ogra_ | ppisati, oh ... not sure that works | 15:42 |
| balloons | sergiusens, ack, filing | 15:42 |
| ogra_ | ppisati, i always build a fresh iimage | 15:42 |
| ogra_ | sudo ./ubuntu-device-flash core 16 --channel edge --kernel pc-kernel_4.4.0-31_amd64.snap --gadget pc --os ubuntu-core -o test.img | 15:42 |
| sergiusens | balloons right now you can check in .local/share/snapcraft if really needed | 15:42 |
| ogra_ | with the last u-d-f from mvo's dir | 15:42 |
| * ppisati tries to build a new image, can you try to install your pc-kernel snap like a regular snap pkg? | 15:43 | |
| ali1234 | okay so they are actually in /lib/firmware/4.4.0-1009-raspi2/device-tree/ - ie it is versioned | 15:43 |
| ogra_ | ah, right | 15:44 |
| * ogra_ is spoiled by the handy find command :) | 15:44 | |
| balloons | sergiusens, I see a headers.yaml and parts.yaml in there. | 15:44 |
| ogra_ | ppisati, i can, but i doubt that works correctly | 15:44 |
| ogra_ | ppisati, since the magic for the bootloader wont kick in | 15:44 |
| balloons | sergiusens, I know I asked earlier, but I realized I can't have lp build my snap until the godeps plugin is released. So now I really am curious when it might land :-) | 15:45 |
| elopio | balloons: yakkety today, xenial as soon as the SRU process is done. | 15:47 |
| balloons | elopio, can you land the SRU on a one day turnaround? | 15:48 |
| balloons | do you have an exception to do so? | 15:48 |
| ppisati | ogra_: guess what if i create an img instead of trying to install a new kernel on it? | 15:49 |
| elopio | balloons: yes. I takes me like a couple of hours to test it, and then it's a matter of finding a free person with permissions. | 15:49 |
| ppisati | it works | 15:49 |
| ogra_ | indeed :) | 15:49 |
| mup | PR snapd#1660 opened: add vim swap files to gitignore <Created by tych0> <https://github.com/snapcore/snapd/pull/1660> | 15:49 |
| ogra_ | i dont think sideloading kernels is actually supported atm ... ask mvo though | 15:49 |
| balloons | elopio, as soon as it's in proposed, let me know. That's enough to get the lp builders working for me | 15:49 |
| elopio | balloons: I think you could do a trick to get it earlier. The launchpad page has a ppa textfield, I wonder what happens if you put https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily in there. | 15:50 |
| ppisati | the kernel.img patch for snapcraft is still needed, so i'll fill a bug for that | 15:50 |
| balloons | elopio, hmm. good idea, I'll try | 15:50 |
| ali1234 | what should i put in the version field in my snaps? | 15:50 |
| ali1234 | the version of the software i am snapping? something else? | 15:50 |
| ogra_ | ppisati, that should be tied to "type: kernel" not actually too the kernel plugin though ... (then it helps me too) | 15:52 |
| ogra_ | ali1234, whatever you want ... its just a string after all and does not have any effect | 15:52 |
| ali1234 | anything at all? | 15:52 |
| ogra_ | i think you need something in there, else snapcraft complains | 15:52 |
| ali1234 | is the version used for anything? | 15:53 |
| ogra_ | but you could put "foobar" in | 15:53 |
| ogra_ | no | 15:53 |
| ali1234 | like does it have to always be increasing? | 15:53 |
| ogra_ | no | 15:53 |
| ali1234 | if i make a newer release how does it know? | 15:53 |
| ogra_ | the store (or snapd for sideloaded snaps) cares for that via the revision | 15:53 |
| ogra_ | in case of sideloading it just is $current_revision+1 ... | 15:53 |
| ali1234 | so i can just leave it on version 0 forever? | 15:53 |
| ogra_ | in case of store packages the revision gets created at snap upload time | 15:54 |
| ogra_ | yeah | 15:54 |
| ali1234 | can i make snapcraft automatically fill the version field with something from the build? | 15:54 |
| ogra_ | not atm | 15:54 |
| ali1234 | okay, 0 it is then | 15:54 |
| ogra_ | i think there is work being done that you can use the version from snapcraft.yaml inside your build | 15:54 |
| ali1234 | that's not very helpful | 15:54 |
| ogra_ | (so the other way around) | 15:54 |
| ogra_ | it totally is :) | 15:54 |
| balloons | elopio, that works for me, ty :-) | 15:55 |
| ogra_ | for me at least | 15:55 |
| ali1234 | the build knows what version it is | 15:55 |
| elopio | balloons: cool. Remember to remove it after the release :) | 15:55 |
| ogra_ | i.e. building a kernel snap i need the version in certain moments ... today i have to grep snapcraft.yaml for that | 15:55 |
| ali1234 | i don't know before i run snapcraft what revision it is going to pull from git... or the repo | 15:55 |
| ogra_ | having a var for it is massively helpful here | 15:55 |
| ogra_ | right | 15:55 |
| ogra_ | in that case it isnt | 15:55 |
| ogra_ | as i said, the other way around than what would be helpful for you | 15:56 |
| ali1234 | what is the proper syntax for multiline texts in yaml? | 15:57 |
| ppisati | sergiusens: lp1611435 | 15:58 |
| ppisati | bug1611435 | 15:58 |
| ppisati | bah | 15:58 |
| ali1234 | nvm found it | 15:58 |
| ogra_ | bug 1611435 | 15:59 |
| mup | Bug #1611435: kernel plugin: hard link vmlinuz to kernel.img <Snapcraft:New> <https://launchpad.net/bugs/1611435> | 15:59 |
| ogra_ | :) | 15:59 |
| ogra_ | ppisati, just confirming, sideloading my kernel snap in the working image gets me the initrd prompt on reboot | 16:01 |
| ppisati | ogra_: that's the stuff i was hitting today | 16:06 |
| ogra_ | yeah | 16:06 |
| ogra_ | not sure if it is a bug though | 16:06 |
| ogra_ | assertions might make sideloading kernels impossible by design | 16:07 |
| ogra_ | (they havent landed yet) | 16:07 |
| ppisati | ogra_: and how do i test a new kernel? from a developer POV | 16:07 |
| ogra_ | you have to ask the core team | 16:07 |
| ogra_ | you build an image | 16:07 |
| ogra_ | probably niemeyer or pedronis can chime in here ... they are the assertion masters and can tell if sideloading kernels will be possible in the future | 16:08 |
| ogra_ | (i would assume not, but that you can always build a local image using your local kernel snap instead ... for testing) | 16:09 |
| ali1234 | is there a plugin that dumps a text fragment from the yaml into a file? | 16:09 |
| ali1234 | like copy except without needing a separate file | 16:09 |
| ali1234 | would be handy for the one-line wrappers that literally everything seems to need | 16:09 |
| * ogra_ would just use the make plugin and a makefile | 16:09 | |
| balloons | kyrofa, can you take a look at this error lp got trying to build juju using the godeps plugin? https://launchpadlibrarian.net/277983664/buildlog_snap_ubuntu_xenial_amd64_juju_BUILDING.txt.gz | 16:09 |
| ali1234 | a makefile is an external file | 16:10 |
| kyrofa | balloons, looking now | 16:10 |
| kyrofa | balloons, eww | 16:10 |
| kyrofa | balloons, I have no clue what that means. Do we have any bzr people around here? | 16:11 |
| kyrofa | sergiusens, you're a bzr pro, aren't you? | 16:11 |
| niemeyer | ogra_, ppisati: Loading of custom kernel snaps will definitely possible.. we'll probably tweak settings to account for the fact the kernel is unknown, but the system should boot fine | 16:11 |
| ogra_ | niemeyer, ok | 16:11 |
| ogra_ | ppisati, then it is a bug, please file one | 16:12 |
| sergiusens | kyrofa balloons feels like a proxy issue, cjwatson might now better | 16:12 |
| kyrofa | balloons, looks like cjwatson and ogra_ may have had a conversation about this already | 16:13 |
| balloons | it feels like it's something to do with the builder | 16:13 |
| cjwatson | kyrofa: no, that was entirely unrelated | 16:13 |
| ogra_ | kyrofa, about what exactly ? | 16:13 |
| niemeyer | ogra_, ppisati: Note that I'm literally reviewing mvo 's prepare-image *today*, so the fact you even have an image is surprising! ;) | 16:13 |
| ogra_ | niemeyer, we have a hacked up u-d-f that mvo provided last week | 16:14 |
| ogra_ | (which is supposed to give us everything but model assertions afaik) | 16:14 |
| cjwatson | balloons: can you make it use lp:tomb etc. rather than https://launchpad.net/tomb ? | 16:14 |
| ogra_ | (with a ton of hardcoding atm) | 16:14 |
| niemeyer | ogra_: I know, I'm half-joking.. just pointing out there are obviously missing pieces, and we're working on fundamental parts of that problem still | 16:15 |
| ogra_ | :) | 16:15 |
| cjwatson | ah, or in fact ogra_ and I did talk about this some days ago I think | 16:15 |
| balloons | cjwatson, umm, yes I can do that, assuming nothing breaks | 16:15 |
| kyrofa | ogra_, cjwatson bug #1606203 | 16:15 |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203> | 16:15 |
| kyrofa | balloons, ^^ | 16:15 |
| ogra_ | niemeyer, that is why i summoned you since i wasnt sure it is desired behaviour ;) | 16:15 |
| cjwatson | yeah, I remember now | 16:15 |
| niemeyer | ogra_: I don't think it gives you everything either, but mvo would know more | 16:15 |
| ogra_ | yeah | 16:15 |
| ogra_ | it fakes a lot | 16:15 |
| cjwatson | so I don't remember whether lp: will actually help | 16:16 |
| balloons | hmm | 16:16 |
| cjwatson | this is basically a bzr bug but there's a not very difficult workaround possible in snapcraft | 16:16 |
| ogra_ | by just using git ? :) | 16:17 |
| kyrofa | ogra_, hahaha | 16:17 |
| cjwatson | oh, hmm | 16:17 |
| cjwatson | in this case bzr is being called via godeps, right? | 16:17 |
| balloons | get those dependencies out of launchpad | 16:17 |
| balloons | cjwatson, yes | 16:17 |
| cjwatson | so unsetting https_proxy would be problematic | 16:17 |
| cjwatson | who said out of launchpad? we have git suppor t:P | 16:17 |
| cjwatson | *support | 16:18 |
| balloons | ohh true.. | 16:18 |
| ogra_ | :D | 16:18 |
| * balloons notes it's building from a git repo on lp | 16:18 | |
| cjwatson | I don't really know what to do here; maybe somebody has to spend a few days fixing bzr | 16:18 |
| cjwatson | you might be able to bribe vila perhaps | 16:18 |
| mup | Bug #1611444 opened: Cannot share a namespace between apps in a SNAP <Snappy:New> <https://launchpad.net/bugs/1611444> | 16:20 |
| balloons | I'm guessing I can get those maintainers to host outside of bzr. But I suppose we should update the bug report with the latest thoughts | 16:21 |
| === davidcalle|afk is now known as davidcalle | ||
| niemeyer | joc_: one last comment on snapd#1644 and we can merge it | 16:34 |
| mup | PR snapd#1644: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1644> | 16:34 |
| mup | PR snapcraft#714 closed: Release changelog for 2.14 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/714> | 16:34 |
| morphis | ogra_: installing my own kernel snap always gives me : https://paste.ubuntu.com/22818250/ | 16:41 |
| morphis | is that expected? | 16:41 |
| mvo_ | ogra_: sorry, I miss a bit of context here, whats the issue? that sideloading kernels fails currently? I think this is just a bug ("just" ;) | 16:51 |
| ogra_ | mvo_, sideloading kernels on amd64 works but leaves you with a broken boot on reboot | 16:52 |
| ogra_ | what morphis sees above is presumably the same issue you fixed today and unrelated to what ppisati has | 16:53 |
| morphis | ogra_, mvo_: so that is expected :-) | 16:53 |
| ogra_ | morphis, there was a bug in general with arm kernels that left me with broken images ... mvo_ fixed that one today ... | 16:54 |
| morphis | ogra_: in snapd or u-d-f? | 16:54 |
| ogra_ | snapd | 16:54 |
| ogra_ | (but thats the same here ... ) | 16:55 |
| morphis | :-) | 16:55 |
| morphis | means building a new core snap with new snapd or do we have daily's already? | 16:55 |
| SamYaple | sergiusens: https://github.com/snapcore/snapcraft/pull/657 | 16:57 |
| mup | PR snapcraft#657: Add constraints to python2 plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/657> | 16:57 |
| SamYaple | it really doesnt like that PR, tests still havent run | 16:57 |
| mup | PR snapd#1657 closed: tests: add udev rules spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1657> | 16:58 |
| mup | PR snapd#1659 closed: wrappers: ensure services have a valid SNAP_USER_DATA dir <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1659> | 16:58 |
| ogra_ | morphis, i dont think the fix was released yet | 16:58 |
| morphis | ogra_: I really had waiting for things .. | 16:59 |
| morphis | mvo_: https://people.canonical.com/~mvo/all-snaps/16/ubuntu-device-flash is the latest u-d-f to generate images? | 16:59 |
| ogra_ | yep | 16:59 |
| mvo_ | morphis: yeah, anything missing or not working? | 17:00 |
| morphis | mvo_: no, just trying it :-) | 17:00 |
| morphis | ogra_: you have the cmdline handy you use for the all-snap pi3 image? | 17:00 |
| ogra_ | mvo_, do we have a snapd with your fix for the arm kernels yet ? | 17:00 |
| morphis | ogra_: did this https://bazaar.launchpad.net/~morphis/+junk/pi2-kernel-snap/revision/38 dirty thing to include the wifi firmware now | 17:01 |
| ogra_ | udo ../ubuntu-device-flash core 16 --channel edge --kernel pi2-kernel --gadget pi3 --os ubuntu-core -o test.img | 17:01 |
| ogra_ | something like that | 17:01 |
| ogra_ | heh | 17:01 |
| ogra_ | you could just unsquashfs ... cp the files in there and run snapcraft snap squashfs-root | 17:02 |
| morphis | yeah | 17:02 |
| joc_ | niemeyer: thanks, made the change | 17:03 |
| niemeyer | joc_: Just saw it, thanks! | 17:03 |
| niemeyer | joc_: Just waiting for tests to go green | 17:03 |
| morphis | ogra_: getting: cannot use "pi3", must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" "pi2" "canonical-dragon" "dragonboard" "beagleblack"] | 17:04 |
| morphis | looks like my u-d-f version isn't correct | 17:04 |
| mvo_ | morphis: hm, i may need to build an update | 17:05 |
| ogra_ | weird | 17:05 |
| ogra_ | oh | 17:05 |
| ogra_ | right, you telegrammed me the fixed version | 17:06 |
| morphis | ah :-) | 17:06 |
| morphis | suspected sth like this | 17:06 |
| morphis | mvo_: you should create a devmode snap with that u-d-f version | 17:06 |
| sergiusens | SamYaple travis is just busy this time it seems | 17:06 |
| mvo_ | morphis: heh, good idea | 17:08 |
| morphis | mvo_: if you don't have time let me do that | 17:08 |
| morphis | but that would semi-solve this situation :-) | 17:09 |
| morphis | mvo_: if you have a branch somewhere we can build from that | 17:09 |
| mup | PR snapd#1405 closed: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <Closed by jocave> <https://github.com/snapcore/snapd/pull/1405> | 17:10 |
| mvo_ | morphis: excellent idea | 17:13 |
| morphis | mvo_: so if you want I can cerate a snapcraft.yaml quickly tomorrow morning | 17:13 |
| morphis | mvo_: https://code.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image is the right one? | 17:14 |
| mvo_ | morphis: sounds great, if there is no ubuntu-device-flash by tomorrow then that is very welcome | 17:14 |
| mvo_ | morphis: sorrect | 17:14 |
| mvo_ | morphis: correct | 17:14 |
| ahasenack | hm, does it make sense to include manpages in a snap? | 17:15 |
| ahasenack | the system-wide man command obviously can't see them | 17:15 |
| lazyPower | ahasenack - i dont think so, i would think we want the snaps to be as slim as possible, especially considering the system man command cannot find the shipping manpages | 17:17 |
| lazyPower | its extra bits on disk with no use unless you're bundling man with your snap | 17:17 |
| ahasenack | yeah | 17:17 |
| ahasenack | how do I include some files that "make install" didn't install? using filesets? | 17:20 |
| kyrofa | ahasenack, essentially create a new part that uses the same source and use the copy plugin to get them where you want them | 17:21 |
| ahasenack | ok, let me try that | 17:22 |
| morphis | mvo_: ok, created it now | 17:28 |
| morphis | just one issue: | 17:28 |
| morphis | simon@nirvana ~/Work/ubuntu/snappy/hwe/ubuntu-device-flash (master*) $ ubuntu-device-flash.run | 17:28 |
| morphis | Unknown command `/snap/ubuntu-device-flash/x1/bin/ubuntu-device-flash'. Please specify one command of: core, personal, query or touch | 17:28 |
| mvo_ | morphis: woah! | 17:28 |
| mvo_ | morphis: \o/ | 17:28 |
| morphis | somehow the flags parser gets sth wrong | 17:28 |
| morphis | the problem are not the wrapper scripts | 17:28 |
| morphis | if I take just the binary I get the same problem | 17:28 |
| mvo_ | morphis: sounds like its in the code :/ | 17:28 |
| morphis | $ prime/bin/ubuntu-device-flash | 17:28 |
| morphis | Unknown command `prime/bin/ubuntu-device-flash'. Please specify one command of: core, personal, query or touch | 17:28 |
| mvo_ | morphis: what ubuntu-core snap do you have? the latest from edge? | 17:29 |
| morphis | mvo_: https://code.launchpad.net/~morphis/+git/ubuntu-device-flash/+ref/master | 17:30 |
| morphis | mvo_: you mean on my desktop? | 17:30 |
| morphis | mvo_: fetching the newest now | 17:30 |
| morphis | mvo_: but that one doesn't fix the "unknown command" problem | 17:32 |
| mvo_ | morphis: I have a look after dinner | 17:34 |
| morphis | mvo_: thanks | 17:34 |
| morphis | mvo_: same result with a manual: go build -v -a launchpad.net/goget-ubuntu-touch/ubuntu-device-flash | 17:35 |
| mvo_ | morphis: it rings a bell, it smeels like a bug in snap-exec, but I'm not sure right now why its happening, this got fixed a while ago | 17:35 |
| stokachu | so im getting a failure attempting to create a directory in $SNAP_DATA | 17:35 |
| stokachu | https://www.irccloud.com/pastebin/8XM5AilK/ | 17:35 |
| stokachu | not sure why since $SNAP_DATA should be writeable | 17:35 |
| ogra_ | stokachu, for daemons ... | 17:36 |
| ogra_ | (which run as root by default) | 17:36 |
| morphis | mvo_: possible just an old version of the flags GO lib? | 17:36 |
| SamYaple | sergiusens: for the python plugins, requirements.txt and constraints.txt can both be http url addresses rather than files. I can write a quick'n'dirty check to not run it through os.path.join if it begins with http[s]:// , does that seem useful? | 17:36 |
| ogra_ | stokachu, do you try to use it for a binary a user runs manually ? | 17:36 |
| SamYaple | or do we not want http[s]:// addresses? | 17:36 |
| mvo_ | morphis: maybe, if you share your snapcraft.yaml (or create a PR) I will debug | 17:36 |
| stokachu | ogra_: would be nice if the docs mentioned that | 17:37 |
| stokachu | ogra_: yes this is a binary | 17:37 |
| * mvo_ dinner | 17:37 | |
| ogra_ | stokachu, for user invoked binaries you want $SNAP_USER_DATA instead | 17:37 |
| * ogra_ takes a bit from mvo_ to check if he actually tastes like dinner | 17:37 | |
| ogra_ | *bite | 17:38 |
| morphis | mvo_: https://code.launchpad.net/~morphis/+git/ubuntu-device-flash/+ref/master | 17:38 |
| stokachu | so the frontpage on snapcraft.io doesn't mentioned SNAP_DATA being for daemons only | 17:38 |
| ogra_ | stokachu, well, it is under /var/snap... | 17:38 |
| morphis | mvo_: do you think we're ok with uploading the snap as canonical? | 17:38 |
| stokachu | ogra_: why does that matter if the app is self contained? | 17:38 |
| mvo_ | thanks morphis | 17:38 |
| morphis | or do we want to keep it personal to not make it official? | 17:38 |
| mvo_ | morphis: a good question, its probably ok for now and has the advantage that we can collaborate on it easily | 17:39 |
| morphis | yeah | 17:39 |
| ogra_ | stokachu, well, /var is usually not writable for normal users ... | 17:39 |
| stokachu | ogra_: but the app is self contained | 17:39 |
| ogra_ | nno matter what the snap does in a subdir there | 17:39 |
| stokachu | lol that is so confusing | 17:40 |
| ogra_ | even with confinement the normal filesystem permissions apply | 17:40 |
| stokachu | if the app is self contained why do we care where it is | 17:40 |
| lazyPower | is there something special I have to do to set the GOPATH and GOROOT tha ti'm not seeing? http://paste.ubuntu.com/22824346/ - heres my snapcraft.yaml, and it looks pretty straight forward, however my build fails gloriously | 17:40 |
| stokachu | ogra_: so you're saying the app is not fully self contained? | 17:40 |
| ogra_ | stokachu, now thats a question for someone from the core snap team :) it could indeed be anywhere (theoretically) | 17:40 |
| ogra_ | wht does the confinement have to do with it ? | 17:41 |
| stokachu | if the app is confined why does it matter where the "host" allows you to write data | 17:41 |
| ogra_ | if you invoke a snap binary as stokachu, it runs under your system credentials ... if you have permission to write to a dir the binary will too | 17:41 |
| mmcc | hi ogra_: re stokachu's question about SNAP_DATA, I think the distinction wrt SNAP_USER_DATA needs to be clarified in the docs on snapcraft.io - mind if I try to paraphrase you in a bug on that site? | 17:41 |
| ogra_ | if you dont, the binary wont either | 17:41 |
| ogra_ | mmcc, sure. go ahead | 17:42 |
| stokachu | ogra_: wouldnt i have permission to write to /var in a snap? | 17:42 |
| ogra_ | (feel free to just copy/paste the conversation above ) | 17:42 |
| stokachu | isn't it just /var with regards to the snap itself? | 17:42 |
| ogra_ | stokachu, try "touch /var/foo.txt" ... what do you get ? | 17:42 |
| stokachu | that fails obviously | 17:43 |
| ogra_ | well, and why would a binary you run as stokachu on your machine have any more permissions on /var ? | 17:43 |
| stokachu | why is snap trying to access /var on the host system?? | 17:43 |
| ogra_ | (unless it would be suid root) | 17:43 |
| stokachu | rather than within it's confined space | 17:43 |
| ogra_ | because it needs to store stuff in some writable space | 17:44 |
| ogra_ | for processes that run with high enough permissions variable data goes to /var | 17:44 |
| lazyPower | http://paste.ubuntu.com/22824864/ -- here's the build log from my attempt to build with the snapcraft.yaml from above ^ | 17:44 |
| ogra_ | for processes that run under user permissions such data usually goes to some place in /hoem/$USER | 17:44 |
| ogra_ | *home | 17:44 |
| ogra_ | snappy doesnt change that fundamental setup ... | 17:45 |
| ogra_ | you cnt write in /snap/$yourapp ... simply because that is a readonly squashfs | 17:46 |
| stokachu | yea i just figured you would keep it all within /snap | 17:47 |
| ogra_ | so you need places where your variable data can go ... which is either $HOME/snap/$yourapp for user related data ... or /var/snap/$yourapp for system related data | 17:47 |
| lazyPower | and since i biffed on the OG paste, here's a re-paste with all the build log info i was trying to send in teh first place: http://pastebin.ubuntu.com/22825168/ | 17:47 |
| mup | PR snapcraft#495 closed: Add in command to list-parts, this could be useful to further enhance… <Created by cwayne18> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/495> | 17:49 |
| ogra_ | lazyPower, perhaps someone with some go background can help you here ... i.e. kyrofa ? | 17:49 |
| kyrofa | Sad... I'm known as the guy with the go background? | 17:50 |
| kyrofa | Where has my life gone? | 17:50 |
| ogra_ | lol | 17:50 |
| * ogra_ hugs kyrofa | 17:51 | |
| * kyrofa hugs ogra_ back | 17:51 | |
| kyrofa | Okay lazyPower what's going on here... | 17:51 |
| lazyPower | kyrofa - we're looking into snapping up kubectl, the kubernetes client side application to communicate with a k8s api server | 17:51 |
| lazyPower | kyrofa - i'm not a gopher, but i'll give it a whirl :) I'm not sure if this is due in part to a misconfigured go workspace, or if i need to send some additional love to the snapcraft yaml to get it to properly fetch those godeps | 17:52 |
| kyrofa | lazyPower, offhand the yaml looks fine | 17:53 |
| kyrofa | Let me look at this project a little closer | 17:53 |
| ahasenack | I'm kind of regretting adding perl to my snap, but now I'm curious why this isn't working: http://pastebin.ubuntu.com/22825810/ | 17:53 |
| ahasenack | the file seems to be there at the right place | 17:53 |
| ahasenack | the only interesting thing maybe is that the 5.22 component of that path is a symlink: | 17:54 |
| ahasenack | lrwxrwxrwx 1 root root 6 Mar 13 08:54 /snap/bip/x4/usr/lib/x86_64-linux-gnu/perl/5.22 -> 5.22.1 | 17:54 |
| ahasenack | are there issues following symlinks? Maybe something security related? | 17:54 |
| ogra_ | ahasenack, heh | 17:54 |
| ogra_ | https://code.launchpad.net/~ogra/+junk/ircproxy | 17:55 |
| ogra_ | (i havent found the time to port it to series 16 yet ... there is a 15.04 snap in the store) | 17:55 |
| ahasenack | ogra_: I'm using this as a learning experiment | 17:56 |
| ogra_ | if you want to use perl, you need to bend the module paths and stuff | 17:56 |
| ahasenack | why? Because of the symlink? | 17:56 |
| ahasenack | or something deeper | 17:57 |
| * ogra_ digs ... my very first snap from two years ago actually did that but i dont have a public branch | 17:57 | |
| kyrofa | lazyPower, sorry, I made the poor choice of working from a remote cabin this week. The power just went off for a few seconds so the router had to reboot :P | 17:58 |
| lazyPower | \o/ power issues | 17:58 |
| kyrofa | lazyPower, anyway, this looks like it's due to the use of absolute imports, which means you need to use the go-importpath | 17:59 |
| lazyPower | if its any consolation, i found that snapcraft fetch would tank my network connection from my VM, so i'm now doing this in the cloud | 17:59 |
| kyrofa | Hahaha | 17:59 |
| lazyPower | kyrofa - ok, that go-importpath that i have commented in teh yaml doesn't look correct? | 17:59 |
| lazyPower | everything i'ms eeing from the dump of errors is referencing k8s.io | 17:59 |
| kyrofa | lazyPower, indeed, that's odd eh? | 18:00 |
| kyrofa | lazyPower, but yeah, check this out: https://github.com/kubernetes/kubernetes/blob/master/cmd/kubectl/kubectl.go | 18:00 |
| kyrofa | lazyPower, so try making go-importpath: k8s.io/kubernetes | 18:00 |
| lazyPower | 1 sec, standup, sorry | 18:01 |
| kyrofa | lazyPower, no problem, give that a try when you're able and get back to me | 18:01 |
| ogra_ | ahasenack, phew, that took some digging http://paste.ubuntu.com/22826676/ | 18:01 |
| ogra_ | ahasenack, look at the "start: " line | 18:02 |
| ogra_ | nowadays you would prefix perl/ with $SNAP ... but that should give you an idea | 18:02 |
| ahasenack | I see | 18:03 |
| ahasenack | thanks | 18:03 |
| ogra_ | (the perl installation in that snap obviously lived under perl/ ... so "perl/usr/bin/perl -I perl/usr/lib/arm-linux-gnueabihf/perl/5.20.1 -I perl/usr/share/perl/5.20.1" execs the interpreter with the -I paths for modules) | 18:03 |
| ogra_ | hmm, i should actually re-vive that snap and finally control my heating with it | 18:04 |
| ogra_ | (and replace the 10 year old fhem machine that does it today with a snap based one) | 18:04 |
| lazyPower | kyrofa - aha! new errors, much progress, such excitement | 18:12 |
| mmcc | hi folks, simple question - the first body paragraph of snapcraft.io currently describes snaps as "secure, sandboxed, *containerised* applications" -- does anyone else think that saying "containerised" might be confusing for people new to snaps, who might know more about docker/lxd containers? | 18:12 |
| qengho | Docker doesn't own containerhood. | 18:15 |
| qengho | The bug in that sentence is the missplled "containerised". | 18:16 |
| SamYaple | qengho: "Docker doesn't own containerhood." | 18:16 |
| SamYaple | that gave me a good chuckle | 18:16 |
| SamYaple | i want to paste that in #docker | 18:17 |
| SamYaple | mmcc: saying something is "containerised" is refering to the linux tech behind containers (namespaces) which snappy absoletly does use. | 18:18 |
| SamYaple | i agree though, it tends to feel more like packaging than "containers" if you are familiar with docker | 18:18 |
| qengho | We need a de-brainwashing paragraph, maybe. | 18:19 |
| SamYaple | i wont argue with that qengho | 18:20 |
| mvo_ | morphis: I can reproduce it, checking but it smells like the binary is broken for some reason, running /snap/ubuntu-device-flash/x1/bin/ubuntu-device-flash directly gives the same error | 18:20 |
| mmcc | SamYaple: thanks - I should've looked further into how the confinement was implemented. I just skimmed some of the snapd core docs, but didn't see references to user namespaces | 18:21 |
| sergiusens | qengho isn't containerised correct in the UK? Kind of like color colour? | 18:21 |
| qengho | sergiusens: Yes, okay in the UK. At least, no one will send you to gaol. | 18:22 |
| SamYaple | mmcc: im not sure if user namespaces are actually | 18:22 |
| stokachu | https://www.irccloud.com/pastebin/2EcZeSdH/ | 18:23 |
| stokachu | anyone seen anything similar to ^? | 18:23 |
| stokachu | if i try to load the yaml outside of the snap it loads just fine | 18:23 |
| mmcc | As far as placing a claim on the term 'containerised', I will just say that if you want to describe it that way, it might be best to clarify it in contrast to LXD and docker containers. | 18:24 |
| kyrofa | stokachu, any chance that has something to do with locales? | 18:24 |
| SamYaple | mmcc: and lxc and rkt? what about openvz? | 18:24 |
| SamYaple | mmcc: a comparison page seems useful, but its certainly not a requiremetn everytime you say "container" | 18:25 |
| stokachu | https://www.irccloud.com/pastebin/YylwY9Rq/ | 18:26 |
| stokachu | kyrofa: ^ is my locales inside the snap | 18:26 |
| stokachu | maybe i need to force LC_ALL? | 18:26 |
| mmcc | SamYaple: sure, I wouldn't want to include a big feature comparison matrix in the first paragraph. If the consensus here is that it's not confusing, I won't push it further | 18:27 |
| kyrofa | stokachu, I suspect you've hit bug #1576411 | 18:28 |
| mup | Bug #1576411: UTF-8 is not very well supported inside snaps <xenial> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1576411> | 18:28 |
| kyrofa | Which isn't titled all that well | 18:28 |
| mup | PR snapcraft#718 opened: Fix bug lp:1586546 allowing setup.py to work on some projects <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/718> | 18:28 |
| kyrofa | stokachu, essentially, the environment in which your snap runs says it wants en_US. The desktop has the en_US locale, but the environment in which the snap runs does not | 18:28 |
| stokachu | ah ok | 18:29 |
| kyrofa | stokachu, there are some workarounds on the bug | 18:29 |
| stokachu | yea im going to try those now | 18:30 |
| kyrofa | stokachu, in one of my snaps I work around it by setting LC_ALL=C.UTF-8 | 18:30 |
| kyrofa | stokachu, but obviously that's a limited "fix"... | 18:30 |
| stokachu | yea im going to start with a wrapper that has that in there | 18:31 |
| stokachu | see if it gets us passed this | 18:31 |
| === faenil_ is now known as faenil | ||
| sergiusens | josepht seems something went wrong with your merge/rebase https://github.com/snapcore/snapcraft/pull/658 | 18:36 |
| mup | PR snapcraft#658: parser - Return non-zero code for wiki errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/658> | 18:36 |
| josepht | sergiusens: argh! I'll fix it. | 18:39 |
| mup | PR snapd#1658 closed: partition: fix cleaning of the boot variables on the second good boot <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1658> | 18:43 |
| ahasenack | is there the concept of applying patches or fixes to a source tarball in snappy, before building? | 18:43 |
| ahasenack | or running a simple command, that would also work | 18:45 |
| lazyPower | kyrofa : I think that sorted me, there's additional work to be don ehere, like not building the whole k8s ecosystem in this snap, but that fully sorted me. Can i ask how you came ot the conclusion thats what i needed to do? | 18:45 |
| kyrofa | lazyPower, excellent! | 18:47 |
| kyrofa | lazyPower, I knew because of the errors you were getting-- complaining about not being able to find itself, but in a different path | 18:48 |
| kyrofa | lazyPower, particularly one that wasn't github was easy to spot | 18:48 |
| josepht | sergiusens: that PR should be fixed now | 18:51 |
| lazyPower | ah ok, so this really is golang internals | 18:51 |
| * lazyPower makes a note to read a book on go | 18:52 | |
| kyrofa | lazyPower, indeed. go directly maps import "foo/bar/baz" to filepath positions: $GOPATH/foo/bar/baz | 18:52 |
| mup | PR snapd#1644 closed: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1644> | 19:00 |
| niemeyer | joc_: ^^^ | 19:00 |
| dpb1 | ahasenack: I'm interested as well, did you find anything out? | 19:03 |
| lazyPower | kyrofa - any chance we can pass extra env vars during the build? i'm not seeing that outlined in the tour | 19:04 |
| ahasenack | no, not yet | 19:04 |
| lazyPower | kyrofa - we should be able to pair this down with a WHAT=kubectl, then firing off the go build, and i think that sorts it | 19:04 |
| ahasenack | dpb1: so far I'm leaning towards forking the tarball, and shippig the files I need as I need them | 19:04 |
| ahasenack | shipping* | 19:04 |
| dpb1 | :( | 19:04 |
| kyrofa | lazyPower, no, no build environment yet, but it's on the roadmap | 19:05 |
| dpb1 | that sounds less than ideal | 19:05 |
| ahasenack | maybe "organize" in my case | 19:05 |
| ahasenack | a fancy name for "rename" | 19:05 |
| === faenil is now known as faenil_ | ||
| kyrofa | ahasenack, no, no concept of patching yet. But it's pretty easy to create your own local plugin for snapcraft to use if you want to go down that path | 19:06 |
| sergiusens | elopio 2.14 is in -proposed https://launchpad.net/ubuntu/+source/snapcraft/2.14 | 19:12 |
| elopio | sergiusens: ok. I'll it while it syncs in the archive | 19:13 |
| elopio | *eat :D | 19:13 |
| ahasenack | the copy plugin, looks like it doesn't create directories | 19:15 |
| kyrofa | ahasenack, it should be. How are you using it? | 19:20 |
| ahasenack | kyrofa: I have a conf file at the same directory level as my snapcraft file, I want it to land in etc/squid-deb-proxy/squid-deb-proxy.conf | 19:22 |
| ahasenack | ah, let me try something | 19:22 |
| kyrofa | ahasenack, try: | 19:23 |
| kyrofa | files: | 19:23 |
| kyrofa | conf-file: etc/squid-deb-proxy/ | 19:23 |
| kyrofa | I suppose that would actually be: | 19:23 |
| kyrofa | files: | 19:23 |
| kyrofa | squid-deb-proxy.conf: etc/squid-deb-proxy/ | 19:23 |
| ahasenack | it worked now, but I might still be doing it wrong | 19:23 |
| ahasenack | files: | 19:24 |
| ahasenack | squid-deb-proxy.conf: /etc/squid-deb-proxy/squid-deb-proxy.conf | 19:24 |
| ahasenack | before I had | 19:24 |
| ahasenack | files: | 19:24 |
| ahasenack | squid-deb-proxy.conf: /etc/squid-deb-proxy | 19:24 |
| ahasenack | and that just created the file under that other name | 19:24 |
| ahasenack | maybe because I missed an ending / | 19:24 |
| ahasenack | let me try with an ending / | 19:24 |
| wililupy|travel | Is the snappy store down? | 19:26 |
| === wililupy|travel is now known as wililupy | ||
| stokachu | kyrofa: yea putting LC_ALL=C.UTF-8 in a wrapper fixed the encoding error | 19:31 |
| kyrofa | stokachu, good deal. That's annoying, I'm sorry. Please say something on that bug | 19:31 |
| stokachu | will do, thanks | 19:31 |
| ahasenack | I'm getting a file not found error at the and of the snapcraft run, yet the file seems to be right where it needs to be | 19:33 |
| ahasenack | [Errno 2] No such file or directory: '/usr/sbin/squid' | 19:33 |
| ahasenack | http://pastebin.ubuntu.com/22836747/ | 19:33 |
| kyrofa | ahasenack, seems it's actually looking in /usr/sbin/squid (on the system) | 19:34 |
| ahasenack | yeah, I feared that | 19:34 |
| kyrofa | ahasenack, is there a symlink pointing there perhaps? | 19:35 |
| ahasenack | here I was trying to use squid as a run-time dependency (stage-packages), instead of building it as part of the snap | 19:35 |
| ahasenack | since this snap is really just a set of config files for squid (squid-deb-proxy) | 19:35 |
| ahasenack | kyrofa: no, no symlink | 19:35 |
| kyrofa | ahasenack, hmm... odd that it's happening in prime, then | 19:36 |
| kyrofa | ahasenack, all that happens there is file migration and ldd crawling | 19:36 |
| kyrofa | ahasenack, do me a favor and run snapcraft -d | 19:36 |
| ahasenack | sure | 19:36 |
| kyrofa | ahasenack, so you can get a trace | 19:36 |
| * ahasenack cleans first | 19:36 | |
| kyrofa | No no | 19:36 |
| kyrofa | Just the prime would be fine, you don't need to clean completely | 19:36 |
| kyrofa | Though it doesn't hurt anything | 19:37 |
| ahasenack | yeah, it's quick | 19:37 |
| kyrofa | Good deal | 19:37 |
| ahasenack | kyrofa: it's during ldd of sorts: http://pastebin.ubuntu.com/22837387/ | 19:38 |
| kyrofa | ahasenack, mind if I take a quick look at your yaml? | 19:39 |
| ahasenack | not at all | 19:39 |
| ahasenack | but keep in mind it's super work in progress, I'm trying things | 19:39 |
| ahasenack | building it step by step | 19:40 |
| kyrofa | ahasenack, haha, don't worry, I won't judge ;) | 19:40 |
| kyrofa | ahasenack, you should see some of mine | 19:40 |
| ahasenack | kyrofa: http://pastebin.ubuntu.com/22837563/ | 19:40 |
| kyrofa | There it is | 19:40 |
| ahasenack | it needs to be a daemon, etc | 19:40 |
| kyrofa | ahasenack, your command is specifically trying to call /usr/sbin/squid | 19:40 |
| kyrofa | ahasenack, which doesn't exist | 19:41 |
| ahasenack | hm | 19:41 |
| ahasenack | how do I reference it, should I drop the first /? | 19:41 |
| ahasenack | or just let PATH sort it out? | 19:42 |
| kyrofa | Sure, try that. Most of the bins are added onto the PATH by snapcraft, but I'm not sure it'll grab the sbin | 19:42 |
| kyrofa | sergiusens, should snapcraft add the sbin directories to PATH as well? | 19:42 |
| kyrofa | I don't think it does, but should it? | 19:42 |
| Ursinha | ahasenack: what I'm doing is to define the command as only foo if foo can be found in the path (in the case /snap/bin) | 19:43 |
| ahasenack | kyrofa: dropping the starting / worked | 19:43 |
| ahasenack | kyrofa: thx | 19:44 |
| kyrofa | ahasenack, good deal, though it might break when you actually run it since it may depend upon cwd | 19:44 |
| ahasenack | yeah | 19:44 |
| kyrofa | ahasenack, worst case, you ship a shell script that runs $SNAP/usr/sbin/squid | 19:44 |
| ahasenack | kyrofa: I will need a shell script anyway I think, because squid needs to create those cache directories when first started on a fresh system | 19:45 |
| kyrofa | Ah yes | 19:45 |
| ahasenack | kyrofa: something the deb initscript does | 19:45 |
| kyrofa | Then do that. And put it in bin | 19:45 |
| ahasenack | kyrofa: here I will have to adapt | 19:45 |
| kyrofa | Then make your command just call that (it'll be in PATH) | 19:45 |
| mup | Bug #1611068 opened: 401 when trying to install hello-world <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611068> | 19:45 |
| kyrofa | ahasenack, I'm still lobbying for an install hook that can be used to setup that initial stuff | 19:46 |
| ahasenack | kyrofa: I missed a way to patch or run commands pre-build time (from the top of my huge 1,5 day experience with snappy) | 19:48 |
| mup | Bug #1611493 opened: No TTY in snaps. <landscape> <Snappy:New> <https://launchpad.net/bugs/1611493> | 19:48 |
| ahasenack | but it's an experiment, and I don't want to be biased by the deb packaging world | 19:48 |
| ahasenack | which is much harder I think | 19:49 |
| mbruzek | Can anyone help me with how to install snapcraft from source? | 19:51 |
| mbruzek | I found this url: https://github.com/snapcore/snapcraft/blob/master/HACKING.md | 19:51 |
| mbruzek | I ran ./setup.py install without any luck. | 19:52 |
| mbruzek | That step failed | 19:54 |
| mbruzek | error: The 'requests' distribution was not found and is required by snapcraft | 19:54 |
| kyrofa | mbruzek, you can just run it: <snapcraft>/bin/snapcraft | 19:55 |
| kyrofa | mbruzek, no need to install | 19:55 |
| mbruzek | kyrofa: I installed in in a virtual env, and when I run $snapcraft build, I got an error that "yaml" could not be imported | 19:56 |
| mbruzek | so pip3 install pyyaml | 19:56 |
| mbruzek | then I ran snapcraft build again | 19:56 |
| mbruzek | jsonschema was missing | 19:56 |
| mbruzek | pip3 install jsonschema | 19:57 |
| mbruzek | now I get the following | 19:57 |
| mbruzek | http://pastebin.ubuntu.com/22839534/ | 19:57 |
| mbruzek | I tried it another way and got an import error on progress bar: http://pastebin.ubuntu.com/22839680/ | 20:00 |
| mbruzek | When running it from the github cloned location | 20:00 |
| lazyPower | mbruzek - i took the liberty of filing: https://bugs.launchpad.net/snapcraft/+bug/1611498 | 20:01 |
| mup | Bug #1611498: snapcraft fails install using virtualenv instructions <Snapcraft:New> <https://launchpad.net/bugs/1611498> | 20:01 |
| stokachu | mbruzek: you have python3-progressbar installed? | 20:01 |
| mbruzek | stokachu: Yes. I tried to show that in the pastebin | 20:02 |
| stokachu | mbruzek: you aren't running a venv or anything are you? | 20:02 |
| mbruzek | stokachu: Yes I was trying to keep this in a virtualenv, following the HACKING.md instructions | 20:03 |
| stokachu | mbruzek: try pip install progressbar2 | 20:03 |
| stokachu | pip3 | 20:04 |
| mbruzek | stokachu: Yep, I got past that one now, but ImportError: No module named 'magic' | 20:04 |
| stokachu | hmmmm | 20:05 |
| mbruzek | There are a ton of magic packages, not sure which one | 20:05 |
| stokachu | yea hmm | 20:06 |
| mbruzek | You know I _already_ did "pip3 install -r requirements" | 20:06 |
| stokachu | mbruzek: try pip3 install pymagic | 20:06 |
| kyrofa | stokachu, mbruzek sorry, internet flaked again. Anyway yeah, the setup.py needs some love. We don't typically use it (we just run straight from src) | 20:07 |
| mbruzek | Could not find a version that satisfies the requirement pymagic (from versions: ) | 20:07 |
| mbruzek | No matching distribution found for pymagic | 20:07 |
| mbruzek | How can I install from source? | 20:07 |
| kyrofa | mbruzek, you don't need to-- you can run straight from it | 20:07 |
| kyrofa | mbruzek, just run the bin/snapcraft executable | 20:07 |
| kyrofa | Add it to your PATH if you want | 20:07 |
| stokachu | kyrofa: he's in a venv and missing some modules it seems | 20:07 |
| sergiusens | kyrofa maybe, but we will be adding the environment keyword soon | 20:07 |
| mbruzek | kyrofa: I __changed__ the code and want to run with some modifications | 20:08 |
| stokachu | mbruzek: oh pip3 install libmagic | 20:08 |
| mbruzek | stokachu: That install worked, but still getting the same import error | 20:09 |
| mbruzek | ImportError: No module named 'magic' | 20:09 |
| kyrofa | mbruzek, I'm not sure where we're missing each other, here :P . If you run bin/snapcraft it'll use your changes | 20:09 |
| stokachu | mbruzek: try python-libmagic and python-magic | 20:09 |
| mbruzek | kyrofa: Yep I get that. | 20:09 |
| mbruzek | kyrofa: I am running it this way.... | 20:09 |
| mbruzek | (matt3) mbruzek@warhorse:~/workspace/snapcraft/kubectl$ ~/workspace/git/snapcraft/bin/snapcraft build | 20:09 |
| mbruzek | ~/workspace/git/snapcraft/bin/snapcraft is giving me these import error | 20:10 |
| mbruzek | s | 20:10 |
| stokachu | mbruzek: s/and/or | 20:10 |
| kyrofa | mbruzek, _not_ in the venv? Just install the stuff in debian/control | 20:10 |
| mbruzek | and pollute my development system? | 20:10 |
| mbruzek | kyrofa: I thought the beauty of python was we could use virtualenvs | 20:11 |
| mbruzek | Plus the HACKING.md file told me to | 20:11 |
| stokachu | mbruzek: maybe it's one of these? :X https://www.irccloud.com/pastebin/Vi90hD8i/ | 20:12 |
| mbruzek | stokachu: yeah I found a ton of them when searching too | 20:12 |
| mbruzek | which is why I am asking here | 20:13 |
| kyrofa | mbruzek, just trying to give some suggestions. Please feel free to develop with whatever setup you desire | 20:13 |
| mbruzek | kyrofa: Not trying to be critical, I am just following the instructions | 20:14 |
| mbruzek | stokachu: http://pastebin.ubuntu.com/22841208/ the install of the python magic worked, or maybe it did not | 20:14 |
| stokachu | mbruzek: :( | 20:15 |
| stokachu | couldnt we just make a snap out of snapcraft? :) | 20:16 |
| mbruzek | stokachu: Wouldn't that be nice | 20:16 |
| sergiusens | kyrofa does this ring a bell http://paste.ubuntu.com/22841604/ ? | 20:16 |
| kyrofa | sergiusens, sounds like some environment variables aren't being set correctly | 20:17 |
| kyrofa | sergiusens, to redirect it | 20:17 |
| kyrofa | sergiusens, rosdep init isn't being run with sudo since it should be writing into parts/foo/rosdep or something like that | 20:18 |
| sergiusens | kyrofa I did not touch the catkin plugin though | 20:18 |
| kyrofa | sergiusens, looking a little closer | 20:18 |
| kyrofa | sergiusens, huh... yeah ROSDEP_SOURCE_PATH is set in _Rosdep._run | 20:20 |
| kyrofa | sergiusens, from what I've seen so far, I have no explanation why your branch is causing that to be weird | 20:20 |
| kyrofa | sergiusens, and you can duplicate locally? | 20:21 |
| sergiusens | kyrofa with my branch, yes | 20:25 |
| sergiusens | kyrofa the paste is from a local run | 20:25 |
| sergiusens | well define local ;-) | 20:26 |
| kyrofa | sergiusens, and what you've pushed is up-to-date? | 20:26 |
| kyrofa | sergiusens, heh, not adt :P | 20:26 |
| sergiusens | kyrofa yes, up2date | 20:26 |
| kyrofa | Well, CI-driven, I guess | 20:26 |
| kyrofa | sergiusens, okay let me take another pass here... | 20:26 |
| sergiusens | kyrofa and working off of a server lately | 20:26 |
| kyrofa | sergiusens, yeah | 20:26 |
| lazyPower | kyrofa - i don tknow what sorcery you have lead us to, but that bin/snapcraft does do what you claim it does despite my best efforts at being a skeptic | 20:27 |
| kyrofa | lazyPower, hahaha | 20:27 |
| kyrofa | sergiusens, dude, this makes no sense | 20:28 |
| kyrofa | sergiusens, let me try this myself... | 20:28 |
| === faenil_ is now known as faenil | ||
| kyrofa | sergiusens, ... this works for me ... | 20:32 |
| kyrofa | sergiusens, that was a pull, right? | 20:32 |
| kyrofa | sergiusens, right at the beginning of the pull? | 20:32 |
| sergiusens | kyrofa yes, pull indeed | 20:33 |
| kyrofa | sergiusens, yeah... it works here | 20:33 |
| kyrofa | But you're seeing that in CI as well? | 20:33 |
| sergiusens | kyrofa yeah | 20:34 |
| kyrofa | sergiusens, x, right? Not y? | 20:34 |
| sergiusens | yeah, always X, x-men here | 20:35 |
| sergiusens | although I think I am generation y | 20:35 |
| kyrofa | :P | 20:36 |
| sergiusens | kyrofa so my branch works for you? | 20:36 |
| kyrofa | sergiusens, oh... wait I'm stupid | 20:36 |
| sergiusens | kyrofa why is that? | 20:37 |
| kyrofa | sergiusens, testing again | 20:37 |
| sergiusens | not running from the branch? | 20:37 |
| kyrofa | sergiusens, maaaybe | 20:37 |
| kyrofa | sergiusens, there it is | 20:38 |
| sergiusens | kyrofa the solution to the problem? | 20:40 |
| sergiusens | official word was we could break this before it spread | 20:41 |
| cwayne | sergiusens: hey, would i need to be part of any specific team to add a part to the wiki? | 20:41 |
| sergiusens | but getting everyone on the same page might be worthwhile | 20:41 |
| kyrofa | sergiusens, you're far too optimistic. No, but now I can see the breakage at least :P | 20:41 |
| sergiusens | cwayne logged in and an ubuntu member I guess | 20:41 |
| sergiusens | cwayne if you want to be on the good side of things, don't use subparts | 20:41 |
| sergiusens | cwayne https://github.com/snapcore/snapcraft/pull/705 | 20:42 |
| mup | PR snapcraft#705: parser - Remove namespacing and subparts <Created by josepht> <https://github.com/snapcore/snapcraft/pull/705> | 20:42 |
| cwayne | didn't even know subparts was a thing | 20:42 |
| sergiusens | cwayne keep it that way! | 20:43 |
| cwayne | will do :) | 20:44 |
| qengho | SUBPARTS WAT? | 20:49 |
| kyrofa | sergiusens, does this change any of the apt params other than the caching one? | 20:52 |
| jhobbs | this python application i'm trying to snap wants to play in "/home/jason/.testrepository" - is there some interface to allow this? or will the application need to be changed to work elsewhere? | 20:52 |
| sergiusens | kyrofa there are no apt params changed really | 20:56 |
| sergiusens | jhobbs does it repect xdg? | 20:57 |
| jhobbs | i don't know | 20:58 |
| kyrofa | sergiusens, something is clearing out the rosdep folder in your branch | 21:00 |
| kyrofa | sergiusens, I suspect https://github.com/snapcore/snapcraft/pull/677/files#diff-e8d25d56f5ed513cad7c55002a709f32R178 | 21:03 |
| mup | PR snapcraft#677: playing with caching <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/677> | 21:03 |
| kyrofa | sergiusens, that directory is used for more than just debs in the case of rosdep | 21:03 |
| sergiusens | kyrofa ah, that can be it, let me refine this | 21:04 |
| kyrofa | sergiusens, we might be able to change that a bit on the catkin side, too | 21:04 |
| kyrofa | sergiusens, but yeah | 21:04 |
| ahasenack | I have maybe a basic question, | 21:05 |
| sergiusens | kyrofa no, deleting rootdir was an experimental shortcut (well I assumed the directory was private to this, but fine ;-) ) | 21:05 |
| ahasenack | but for the app inside the snap, it's not in a chroot, right? | 21:05 |
| ahasenack | I mean, /etc/foo for the app is the real /etc/foo in the system where it's running, if referenced like that? | 21:06 |
| kyrofa | sergiusens, heh | 21:06 |
| kyrofa | ahasenack, indeed | 21:06 |
| ahasenack | kyrofa: hm | 21:06 |
| ahasenack | kyrofa: that can get interesting in the case of a config file that includes other config files | 21:06 |
| ahasenack | using absolute paths | 21:06 |
| kyrofa | ahasenack, indeed, absolute paths means it makes some assumptions about how it's packaged | 21:07 |
| ahasenack | kyrofa: is the absolute path that begins with /snap "stable", as long as it uses the "current" symlink? Is that a reasonable alternative? | 21:07 |
| ahasenack | like /snap/squid-deb-proxy/current/etc/squid-deb-proxy/squid-deb-proxy.conf | 21:08 |
| kyrofa | ahasenack, I'm probably not the best person to ask, there. zyga and slangasek probably have some feelings on that matter | 21:08 |
| ahasenack | that conf file includes other conf files in that directory, I'm not sure I can use relative paths | 21:08 |
| ahasenack | kyrofa: cool, thx | 21:08 |
| kyrofa | ahasenack, and these conf files are dynamically generated? Or do you ship them yourself? | 21:09 |
| ahasenack | I ship them | 21:09 |
| kyrofa | ahasenack, can they accept environment variables? | 21:09 |
| ahasenack | doubtful | 21:09 |
| ahasenack | maybe in my script that starts the service I could generate them dynamically, if it comes to that | 21:10 |
| ahasenack | adjust paths according to some $SNAP_var, then start the service | 21:10 |
| ahasenack | sounds overkill at first | 21:10 |
| ahasenack | but I'm new here :) | 21:10 |
| kyrofa | ahasenack, hmm. Yeah I had to do that for redis, check this out: https://github.com/kyrofa/nextcloud-snap/blob/master/src/redis/scripts/start-redis-server | 21:10 |
| ahasenack | SNAP_DATA is the versioned system-wide writable directory, right? | 21:11 |
| ahasenack | not the user one, and not the common one that is unversioned | 21:11 |
| * ahasenack getting used to these names | 21:11 | |
| kyrofa | ahasenack, indeed this might be helpful: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data | 21:11 |
| ahasenack | kyrofa: I see you had to do that exactly because it's versioned, so it's kept on upgrades | 21:12 |
| ahasenack | and indeed, I will have to do that too, if I want to preserve config files during upgrades | 21:12 |
| kyrofa | ahasenack, nah, I did that because I didn't want to write the config file anywhere | 21:12 |
| ahasenack | kyrofa: but there is a current symlink in there too | 21:12 |
| ahasenack | /var/snap/<name>/current | 21:12 |
| kyrofa | ahasenack, indeed, that is SNAP_DATA | 21:13 |
| ahasenack | hm, no, my SNAP_DATA uses the revision | 21:13 |
| ahasenack | export SNAP_DATA="/var/snap/squid-deb-proxy/x3" | 21:13 |
| ahasenack | (from the bin script) | 21:14 |
| kyrofa | ahasenack, right, current points to the currently active revision | 21:14 |
| kyrofa | ahasenack, you shouldn't need to care about that though, no? | 21:14 |
| ahasenack | but there is no var with "current" in it | 21:14 |
| kyrofa | ahasenack, true. Why do you need that? | 21:14 |
| kyrofa | Oh, to write to config files? | 21:15 |
| ahasenack | kyrofa: I hope not. I hit this now because (I think) I added squid to the snap by installing the package in stage-packages, instead of building it | 21:15 |
| ahasenack | I think when I build it with snapcraft, it will take care to put the config files in the right places, but I'm not there yet | 21:15 |
| ahasenack | via ./configure --things I mean | 21:15 |
| kyrofa | ahasenack, snapcraft won't put anything in SNAP_DATA and its ilk | 21:16 |
| ahasenack | that got me thinking about config files | 21:16 |
| ahasenack | hm, not even --sysconfdir=DIR | 21:16 |
| ahasenack | so that will be /etc by default | 21:17 |
| ahasenack | in my mind, SNAP_DATA would be the place for system-wide configuration files that you want preserved across upgrades, among other things | 21:17 |
| ahasenack | stuff that would normally be in /etc | 21:17 |
| ahasenack | and SNAP_USER_DATA for files that are usually ~/.something | 21:18 |
| ahasenack | because the script generated by snapcraft does export HOME="$SNAP_USER_DATA" | 21:18 |
| * ahasenack reads that askubuntu question now | 21:19 | |
| ahasenack | yeah, that's it | 21:20 |
| ahasenack | it just doesn't mention /etc specifically, or system config files in general | 21:20 |
| kyrofa | ahasenack, it's impossible for snaps to pollute other snaps, so you can really use those directories for whatever you wish | 21:23 |
| kyrofa | ahasenack, but people use them differently, and they're runtime-specific things, so snapcraft doesn't deal with them | 21:23 |
| kyrofa | snapcraft just gives you a squashfs image | 21:23 |
| slangasek | ahasenack, kyrofa, zyga: my feeling is that for the cross-distro story, /snap is a bit of a time bomb because it's not in the FHS, it's unrealistic to think it'll be in the FHS before the heat death of the universe, and there have already been examples given of it conflicting with local usage | 21:25 |
| kyrofa | slangasek, agreed | 21:25 |
| kyrofa | ahasenack, so probably try to avoid if at all possible | 21:26 |
| ahasenack | slangasek: so how should I best handle config files? Where should they live? | 21:26 |
| slangasek | ahasenack: I assume they live in the snap and you should locate them relative to the $SNAP_* variables? | 21:27 |
| ahasenack | slangasek: that's doable, but SNAP_* has the revision in it, not "current" | 21:27 |
| ahasenack | slangasek: am I fine in using "current" instead of the revision? | 21:27 |
| slangasek | I don't have a convenient solution for this for software that has to hard-code a path at build time | 21:27 |
| ahasenack | slangasek: yeah, sorry, I'm just looking for best practices | 21:28 |
| slangasek | hmm, I think by definition the running instance is always "current" | 21:28 |
| slangasek | in which case, "yes" that should work :) | 21:28 |
| slangasek | however, current is always a symlink to the revision one | 21:28 |
| ahasenack | I just checked the vars set by the /snap/bin/foo wrapper, they have the revisions | 21:28 |
| slangasek | so if you're resolving the variable at runtime, that should also still work? | 21:28 |
| ahasenack | slangasek: my specific problem is a config file that includes other config files by absolute path | 21:28 |
| slangasek | ah | 21:28 |
| ahasenack | slangasek: yeah, but I will have to regenerate that config then | 21:28 |
| ahasenack | everytime I start the service | 21:28 |
| slangasek | I see | 21:28 |
| slangasek | yes, I think "current" is doable there | 21:29 |
| ahasenack | unless "current" was stable enough, then I could just use "current" in the path | 21:29 |
| ahasenack | but still, I would then have /snap/foo/bar in there, hardcoded... | 21:29 |
| ahasenack | not pleasant | 21:29 |
| sergiusens | kyrofa just for the kicks, look at distutils.file_util.copy_file ;-) | 21:29 |
| jhobbs | is there a way to provide a file by default in /home/<user>/snap/<snap>/<rev> ? | 21:29 |
| kyrofa | sergiusens, I've seen it, but didn't want to introduce another dependency | 21:30 |
| sergiusens | kyrofa could get rid of link_or_copy and is part of the stdlib already | 21:30 |
| kyrofa | sergiusens, I seem to remember people saying to avoid distutils for some reason... | 21:31 |
| ahasenack | slangasek: kyrofa thanks guys | 21:32 |
| kyrofa | Yeah slangasek thanks for jumping in | 21:39 |
| mup | Bug #1611526 opened: temp directories not deleted when snap fails to start <lxd> <Snappy:New> <https://launchpad.net/bugs/1611526> | 21:43 |
| mup | Bug #1611530 opened: can't install devmode snap from store <landscape> <Snappy:New> <https://launchpad.net/bugs/1611530> | 21:49 |
| jdstrand | noise][: hi! can someone a store pull for review tools r705? fyi, I'm going to have another commit tomorrow morning, but r705 has (among other things) the update to allow the tools to not block uploads of the ubuntu-core snap | 21:58 |
| jdstrand | cc ogra_ ^ | 21:58 |
| jdstrand | noise][: I guess it is fairly urgent due to auto-uploads | 21:59 |
| noise][ | jdstrand: EOD here, but i'll see if there's anyone that can pick that up | 22:14 |
| noise][ | jdstrand: likely will be tomorrow morning though | 22:16 |
| EAbdel | Hi | 22:38 |
| EAbdel | IS there any one ? | 22:38 |
| EAbdel | please i have an issue | 22:39 |
| EAbdel | about snapcrafts | 22:39 |
| EAbdel | hiiiiii | 22:43 |
| qengho | That solved itself. | 22:57 |
| sergiusens | kyrofa yes, you should use setuptools, https://docs.python.org/3/library/distutils.html | 22:57 |
| === evanmeag_ is now known as evanmeagher | ||
| === evanmeagher is now known as evnmar | ||
| EAbdel | Hi please, is there any one i can talk to ? | 23:05 |
| mup | PR snapd#1661 opened: Remove documentation on a 'private' flag to /v2/find that doesn't see… <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1661> | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
