| mup | Bug #1611083 changed: Users without xenial-updates/universe can't get snapcraft version 2.11 tour. <Snappy:Invalid> <https://launchpad.net/bugs/1611083> | 00:12 |
|---|---|---|
| mup | Bug #1611080 changed: snapcraft.io says snap find has --broad, but it doesn't <Snappy:Invalid> <https://launchpad.net/bugs/1611080> | 00:21 |
| mup | Bug #1611094 changed: http://snapcraft.io/create/ mentions readmes in each tour subdirectory, they are missing <landscape> <Snapcraft:Triaged by didrocks> <Snappy:Invalid> <https://launchpad.net/bugs/1611094> | 00:21 |
| mup | Bug #1611098 changed: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611098> | 00:24 |
| mup | Bug #1611099 changed: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611099> | 00:27 |
| mup | Bug #1611108 changed: snap install without sudo asks to login to snap store <apport-bug> <i386> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1611108> | 00:34 |
| lpotter | a debian build plugin would be nice | 01:17 |
| === stokachu_ is now known as stokachu | ||
| === mjl_ is now known as mjl | ||
| === chihchun_afk is now known as chihchun | ||
| === davidcalle|afk is now known as davidcalle | ||
| === hikiko is now known as hikiko|afk | ||
| === cydizen_ is now known as cydizen | ||
| tealeg | Hey, anyone about? I have a question. | 08:38 |
| zyga | jdstrand: https://github.com/snapcore/snap-confine/pull/99 | 08:38 |
| mup | PR snap-confine#99: Disable owner checks for 14.04-style private home <Created by zyga> <https://github.com/snapcore/snap-confine/pull/99> | 08:38 |
| tealeg | Is there an easy way to pass environment variables into the environment of an app delivered by a snap? | 08:44 |
| tealeg | I've done this currently by wrapping the binary in a shell script that is the publicly available app | 08:45 |
| tealeg | ... but that seems to leave the binary itself without the permissions provided by the plugs I associated with the wrapper script. | 08:45 |
| tealeg | (that's my hypothesis at least) | 08:45 |
| zyga | tealeg: can you give me a practical example | 08:46 |
| tealeg | zyga: sure. | 08:46 |
| zyga | tealeg: what you are doing works very well and is used by many apps already | 08:46 |
| tealeg | zyga: I have an emacs snap | 08:46 |
| zyga | tealeg: there's upcoming upstream support for defining environment in snapcraft.yaml but it's a long way to go (arguably very little works remains but it took as a while to get there) | 08:47 |
| tealeg | zyga: when I run emacs from the snap, it cannot read files in my HOME directory, though the wrapper script has the home plug defined | 08:47 |
| tealeg | zyga: (with strict confinement turned on, of course) | 08:48 |
| zyga | tealeg: how do you determine that it cannot read files in the home directory? | 08:48 |
| zyga | tealeg: do you see apparmor denials? | 08:48 |
| tealeg | zyga: it tells me that - I try to open a file there, and it says it can't read it | 08:48 |
| tealeg | zyga: I can look, just a mo | 08:48 |
| zyga | tealeg: can you run 'journalctl -f' and try that now? | 08:48 |
| tealeg | zyga: so, yes, apparmour is denying it | 08:49 |
| tealeg | zyga: shall I paste the lines someplace? | 08:50 |
| zyga | tealeg: yes, please | 08:50 |
| zyga | one line should be enouh | 08:50 |
| zyga | enough * | 08:50 |
| zyga | tealeg: please also pastebin your snapcraft.yaml if you can | 08:50 |
| tealeg | zyga: ok.. | 08:50 |
| tealeg | zyga: here's the apparmour: http://pastebin.com/wtxPkVTh | 08:51 |
| zyga | ok, that's enough | 08:51 |
| zyga | you cannot open dotfiles | 08:51 |
| zyga | even with the home plug connected | 08:51 |
| tealeg | zyga: oh? | 08:52 |
| zyga | there's an ongoing discussion about this on the mailing list and on launchpad bug reports | 08:52 |
| tealeg | zyga: let me try a non-dotfile :-) | 08:52 |
| tealeg | zyga: yup, that's it! | 08:52 |
| tealeg | zyga: thanks. OK, I'll accept that as something ongoing for now. Thanks for your time. | 08:53 |
| ogra_ | mvo, wow, you keep the builders busy today :) | 08:53 |
| zyga | ogra_: ? :) | 08:54 |
| mvo | ogra_: yes, created a candidate ubuntu-core for the next stable update of ubuntu-core | 08:54 |
| mvo | ogra_: (the snap) | 08:54 |
| ogra_ | yay | 08:54 |
| mvo | ogra_: its all in the candidate channel now, needs QA testing next | 08:54 |
| ogra_ | k | 08:54 |
| ogra_ | well, the arm builds are still sitting there (as usual since a week) | 08:55 |
| mvo | ogra_: I will do one-off uploads for pi2 and dragonboard kernels that make kernel.img/initrd.img real files, this is important to unbreak ubuntu-image. just fyi | 09:03 |
| morphis | ogra_: ok, building kernel snaps with your build scripts doesn't really work, no I get: Warning: no boot file name; using 'C0A8B2C8.img' | 09:04 |
| ogra_ | mvo, plkeas only dragonboard, i'm in the middle of setting up the auto-build for pc-kernel and pi2-kernel | 09:04 |
| ogra_ | *please | 09:04 |
| ogra_ | morphis, are you on the lates ? | 09:04 |
| ogra_ | t | 09:04 |
| ogra_ | morphis, they work fine on LP | 09:04 |
| mvo | ogra_: if that is ready today thats good enough, otherwise I will just do it, its not much work and will unbreak people | 09:04 |
| morphis | ogra_: hm, let me try that then | 09:05 |
| ogra_ | mvo, pc-kernel is ready in 10min or so | 09:05 |
| mvo | ogra_: \o/ | 09:05 |
| ysionneau | zyga: hmmm your refresh-bits script says I don't have systemd but I do :/ | 09:06 |
| ysionneau | it searches for systemd-activate but indeed I don't seem to have it | 09:06 |
| ogra_ | mvo, do we want a pc-kernel-i386 or should i just build two arches under the same name ? | 09:06 |
| zyga | ysionneau: are you on yakkety? | 09:06 |
| ysionneau | I'm on Debian testing :o | 09:06 |
| mvo | ogra_: pi2-kenrel is actually the one where this matters (the filename) and the dragonboard one of course | 09:06 |
| zyga | ysionneau: or debian testing, yes | 09:06 |
| mvo | ogra_: two under the same name seems ok, unless I hear otherwise | 09:07 |
| zyga | ysionneau: i didn;'t have time to figure that out yet, how do you run socket activated services in more recent versions of systemd | 09:07 |
| mvo | ogra_: its not clear yet if i386 will be "pc" as well for the gadget name | 09:07 |
| zyga | ysionneau: if you figure it out please send me a patch | 09:07 |
| zyga | ysionneau: that's something systemd changed upstream, maybe they just renamed the command | 09:07 |
| ogra_ | mvo, well, pi3 also ises pi2-kernel, so i dont think the gadget name is that important | 09:07 |
| ysionneau | zyga: to do that I usually just do a .service with a ListenStream part | 09:08 |
| ysionneau | one unit file for the socket (WantedBy=sockets.target) and one unit file for the service | 09:08 |
| ysionneau | ah to actually run it | 09:09 |
| zyga | ysionneau: :) | 09:09 |
| ysionneau | systemd-socket-activate <= | 09:09 |
| ysionneau | this binary | 09:09 |
| ysionneau | https://www.freedesktop.org/software/systemd/man/systemd-socket-activate.html | 09:09 |
| ogra_ | mvo, i'm picking 4.4.0-35-1 as the version. so we can bump the last part for package specific changes (the branch is set up for auto-build on commits, so if a new kernel lands we bump the version and it auto-builds (later i'll automate that and watch the linux-meta package in -updates) | 09:11 |
| ogra_ | is the versioning ok with you ? | 09:11 |
| ogra_ | (this is pc-kernel) | 09:12 |
| zyga | ysionneau: please try to patch refresh-bits to use this | 09:12 |
| ysionneau | anyway I don't seem to need this since I will run on a target | 09:12 |
| zyga | ysionneau: as I said, I'd love to have the patch, I'm just hacking on something eles now (snap-confine) | 09:12 |
| ysionneau | so I guess I'll just comment it since I'm in a hurry | 09:12 |
| zyga | ysionneau: there's a bug in --host where it still looks for systemd-activate on the host | 09:12 |
| ysionneau | yep no problem I'll comment the code | 09:13 |
| zyga | ysionneau: thanks! | 09:15 |
| ogra_ | mvo, https://code.launchpad.net/~snappy-dev/+snap/pc-kernel ---> to build you do: bzr branch lp:pc-kernel-snap -> bump the version in snapcraft.yaml, commit -> bzr push lp:pc-kernel-snap ... go to the url and watch it build for i386 and amd64 :) | 09:17 |
| mvo | ogra_: neat | 09:18 |
| ogra_ | (or just request a manual build on the page if you dont want to bump the version) | 09:18 |
| ogra_ | now setting up the same for pi2-kernel | 09:18 |
| ogra_ | note that this comes all from the same branch, they just differ in their snapcraft.yaml | 09:19 |
| ogra_ | (we should keep the Makefile in the branches in sync between them) | 09:20 |
| ysionneau | zyga: very cool ! your script succeeded in building snapd o/ Thanks! One small remark, you base your detection on the user space arch by using uname -m on the target, which does not work in case your kernel is aarch64 and user space is armhf. I hardcoded armv7l to make it work | 09:20 |
| ogra_ | now the exciting moment ... | 09:20 |
| * ogra_ watches the snaps being uploaded to the store | 09:21 | |
| ogra_ | (havent tested that yet) | 09:21 |
| zyga | ysionneau: interesting, please feel free to report thos bugs so that at least the problem is not lost | 09:22 |
| zyga | ysionneau: (straight on github) | 09:22 |
| zyga | ysionneau: and if you have time please send pull requests | 09:22 |
| mvo | ogra_: a pi2 kernel upload will not break anything, right? this unblocks my new u-d-f (and ubuntu-image) so I'm keen to put it into the store for testing | 09:22 |
| ogra_ | mvo, well, how do you build it | 09:23 |
| mvo | ogra_: manual, snapcraft snap | 09:23 |
| mvo | ogra_: I just need to fix the symlinks | 09:23 |
| mvo | (as a one-off build) | 09:23 |
| mvo | (its trivial) | 09:23 |
| ogra_ | mvo, btw, we need store people to remove the review tools block for kernel for pc-kernel https://myapps.developer.ubuntu.com/dev/click-apps/5507/ (can you approve them = | 09:23 |
| ogra_ | ?) | 09:23 |
| ysionneau | zyga will do the reporting at least, thanks | 09:24 |
| mvo | ogra_: I can approve them, one sec | 09:24 |
| ogra_ | mvo, well, i would prefer we use the new way right away to test the symlinks there too :) but if you need it right now, go for it ... my set up takes still 10-15min | 09:24 |
| ogra_ | (thogh given the state of armhf builders it might end up being 3-4h) | 09:25 |
| mvo | ogra_: 10,15min is fine, then I won't waste enegery on it, thank you | 09:25 |
| mvo | ogra_: heh :) if 3-4h I may become too impatient ;) | 09:25 |
| ogra_ | mvo, can you bump build scores if needed ? | 09:25 |
| mvo | ogra_: but its fine, its literally 5min work for me | 09:25 |
| mvo | ogra_: unfortunately I can't :/ | 09:25 |
| ogra_ | k, lets see ... | 09:26 |
| mvo | ogra_: I think we should get auto-high-score just like for the old image builds | 09:26 |
| ogra_ | yeah | 09:26 |
| mvo | ogra_: kenrels approved | 09:31 |
| ogra_ | thx | 09:31 |
| ogra_ | mvo, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel ... i asked for a score bump | 09:37 |
| mvo | ogra_: ta | 09:37 |
| ogra_ | mvo, for that ... same procedure as above ... either bump the version and commit/push ... or do a manual build through LP | 09:37 |
| mvo | ogra_: neat | 09:38 |
| ogra_ | for dragonboard i'll do a build in my own test branch since i cant really set up the snap package under the snappy-dev name when i dont have the correct name (i dont want to create cruft there) | 09:39 |
| mvo | ogra_: +1 | 09:39 |
| ysionneau | when creating an interface, if I want to allow a snap to connect to a unix socket, do I just pretend it's like a file and I just give rw access to the file path ? | 09:41 |
| ysionneau | or does it need some other special rights since it's not really "just" a file? | 09:42 |
| zyga | ysionneau: yes | 09:42 |
| zyga | ysionneau: it's just a file | 09:42 |
| zyga | ysionneau: you will also need to add appropriate system calls like connect and what not | 09:42 |
| zyga | ysionneau: but those are easy to add in a whack-a-mole fashion, just keep editing the generated apparmor and seccomp profiles until both sides work | 09:43 |
| zyga | (plug and slot side) | 09:43 |
| ysionneau | yes but then I guess I can just use the network interfaces in the snap? | 09:43 |
| zyga | ysionneau: did you see my artice about how to create new interfaces from scratch? | 09:43 |
| ysionneau | or is it cleaner if the "pimp" (that's my interface name) interface dierctly authorizes the network functions? | 09:43 |
| zyga | ysionneau: that's subtly different, it's better to be explicit, over time the network interface may only work for AF_INET and AF_INET6 | 09:43 |
| ysionneau | zyga: nop, but so far it seems pretty simple | 09:44 |
| zyga | ysionneau: so don't use it because it gives you extra thnigs you need, put the extra needs into your own iface | 09:44 |
| zyga | ysionneau: zygoon.pl | 09:44 |
| zyga | ysionneau: do read it please :) | 09:44 |
| zyga | ysionneau: feedback is welcome and appreciated | 09:44 |
| zyga | http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html | 09:44 |
| zyga | ysionneau: if it is real "connect to ip network" then do use the existing network/network-bind interfaces | 09:45 |
| zyga | ysionneau: if it is something else, put it into the interface you are creating | 09:45 |
| ysionneau | 11:44 < zyga> ysionneau: do read it please :) < ok I will! | 09:45 |
| ysionneau | btw I created the "issue" on github for your script | 09:46 |
| ysionneau | and added information on the already existing issue about systemd activated sockets | 09:46 |
| ysionneau | zyga: ok then yes I need to add the syscalls in my interface since it's just for the unix socket | 09:47 |
| zyga | ysionneau: note that we can now do partial argument filtering via seccomp | 09:47 |
| ysionneau | "partial" ? | 09:47 |
| zyga | ysionneau: https://github.com/snapcore/snap-confine#seccomp | 09:47 |
| ysionneau | like only putting a requirement on arg1 and not arg2 ? | 09:47 |
| jdstrand | well, when snap-confine finally is SRUd | 09:48 |
| zyga | ysionneau: (only integeres, we cannot ever see through pointers) | 09:48 |
| ysionneau | yep I know I've played with seccomp a bit in the past | 09:48 |
| zyga | jdstrand: hello :) | 09:48 |
| jdstrand | which I think has been a good decision-- we'd have to adjust the Depends of snapd to be a version of snap-confine and that would've stopped snapd uploads :) | 09:49 |
| jdstrand | zyga: hi! :) | 09:49 |
| ogra_ | jdstrand, do i have to poke you to get a package exception for "(NEEDS REVIEW) type 'kernel' not allowed lint-snap-v2_snap_type_redflag " for https://myapps.developer.ubuntu.com/dev/click-apps/5507/ ? the builds now come from automatic LP builds (like ubuntu-core) | 09:51 |
| ogra_ | or is that a store people thing ? | 09:51 |
| ogra_ | (builds now come from https://code.launchpad.net/~snappy-dev/+snap/pc-kernel ) | 09:53 |
| ysionneau | I see stuff like that in some apparmor profile : http://pastebin.com/cuynSmmR | 09:53 |
| ysionneau | what is it? is this for unix sockets? | 09:53 |
| jdstrand | ogra_: you do for the moment but my patch for ubuntu-core can easily be updated for the kernel (and gadget) snaps | 10:02 |
| jdstrand | ogra_: do you have a list of registered core, kernel and gadget names that you want me to add? | 10:02 |
| ogra_ | jdstrand, cool, i'll give you a list later today | 10:02 |
| jdstrand | ok | 10:03 |
| ogra_ | currently pi2-kernel and pc-kernel ... i have some hope we'll get a proper name for the dragonboard soon ... thats the last one in the list | 10:03 |
| mvo | jdstrand: hey, do you have a ecryptfs home system and a spare moment to test something? sudo snap intsall --devmode --edge ubuntu-device-flash and sudo DEBUG_DISK=1 /snap/bin/ubuntu-device-flash core 16 --kernel canonical-snapdragon-linux --gadget canonical-dragon --os ubuntu-core --channel=edge -o $(pwd)/dragon.img gives me an an permission denied error on my ecryptfs system but not on my other system. plus no denias in dmesg and I'm a bit lost | 10:06 |
| mvo | and wonder if its reproducable on other ecryptfs systems | 10:06 |
| jdstrand | mvo: what's the denial? note zyga just committed something to snap-confine yesterday for that | 10:07 |
| mvo | jdstrand: no denial that is the "funny" part | 10:07 |
| jdstrand | mvo: I can test in a vm easily enough | 10:08 |
| jdstrand | mvo: xenial system? | 10:08 |
| mvo | jdstrand: strace shows me stat("dragon.img") gets a permissions denied, but only if I run it with snap-confine, if I run the binary directly its fine | 10:08 |
| mvo | jdstrand: yeah, xenial | 10:08 |
| mup | Bug #1612595 opened: 'Bad system call' when running python3 snap in strict mode <Snappy:New> <https://launchpad.net/bugs/1612595> | 10:10 |
| jdstrand | mvo: you said snap-confine-- is this the package from proposed? | 10:13 |
| mvo | jdstrand: ups, sorry, ubuntu-core-launcher is the same | 10:13 |
| mvo | jdstrand: I meant, when its running under confinement or bind mount stuff | 10:14 |
| jdstrand | ok | 10:14 |
| mvo | jdstrand: its not clear if its the confinment, probably not as no denials, but its something and I suspect it has to do with ecryptfs | 10:14 |
| jdstrand | pulling in -updates now and then will run the command | 10:14 |
| mvo | thanks | 10:14 |
| mvo | jdstrand: and sorry for hijacking you in your morning :) | 10:15 |
| jdstrand | it's fine. almost done confirming | 10:15 |
| jdstrand | mvo: failed to create user data directory. errmsg: Permission denied | 10:17 |
| jdstrand | mvo: is that what you are seeing? | 10:17 |
| jdstrand | mvo: I see that with ecryptfs. without ecryptfs is works. I do have a denial: sec-xenial-amd64 kernel: [ 463.066552] audit: type=1400 audit(1470997002.687:24): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/testuser/.Private/" pid=13878 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=0 ouid=1001 | 10:18 |
| ogra_ | mvo, ok, both kernels are building now ... https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel | 10:18 |
| jdstrand | mvo: perhaps you are hitting kernel rate limiting? | 10:18 |
| ogra_ | i'll ping you when they are ready for store approval | 10:18 |
| jdstrand | mvo: let me see if zyga's commit yesterday fixed that | 10:18 |
| ogra_ | bah, crap FTBFS | 10:19 |
| mvo | ogra_: yay | 10:20 |
| jdstrand | mvo: yes, see 450b660ac91d4ced15185dbdbd2b547ae74fdcec | 10:20 |
| mvo | jdstrand: this is not what I am seeing, htis error is fixed with the version in -proposed | 10:20 |
| jdstrand | is it? | 10:20 |
| mvo | jdstrand: sorry, I should have mentioned this | 10:20 |
| jdstrand | proposed still has .4 | 10:20 |
| mvo | jdstrand: well, in the latest snap confine upload | 10:20 |
| jdstrand | it isn't fixed there | 10:21 |
| mvo | jdstrand: its also in the ppa:snappy-dev/image ppa | 10:21 |
| mvo | jdstrand: yeah, its not accepted yet | 10:21 |
| jdstrand | I can try that ppa | 10:21 |
| mvo | jdstrand: ppa:snappy-dev/image is the one | 10:22 |
| mvo | jdstrand: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/6798247/+listing-archive-extra | 10:22 |
| jdstrand | .7's yeah, I'm there. trying with .7 | 10:22 |
| ogra_ | hmm, looks like snappy-dev can not builod from a branch owned by ~ogra ... | 10:22 |
| jdstrand | mvo: upgrading to .7 it works fine | 10:24 |
| jdstrand | mvo: perhaps you are hitting rate limiting *and* your profile in /etc/apparmor.d/usr.lib.snapd.snap-confine didn't get updated? | 10:24 |
| jdstrand | (it's a conffile) | 10:25 |
| mvo | jdstrand: oh, it works fine, the u-d-f is creating a dragon image? | 10:27 |
| jdstrand | mvo: oh wait, I mispoke | 10:27 |
| mvo | (i.e. downloading stuff etc) | 10:27 |
| jdstrand | Error creating /home/testuser/dragon.img of size 3899999744 to stage image onto | 10:28 |
| ogra_ | mvo, https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/4/ ready for approval | 10:28 |
| mvo | jdstrand: woah, thats a differnt error than the one I got, vm size limitation maybe? | 10:28 |
| mvo | ogra_: done | 10:29 |
| ogra_ | cool | 10:29 |
| ogra_ | i'll build a test image :) | 10:29 |
| jdstrand | mvo: it worked outside of ecryptfs | 10:29 |
| ogra_ | (while waiting for the dragonboard kernel) | 10:29 |
| mvo | jdstrand: oh, interessting | 10:30 |
| mvo | jdstrand: the error is different than the one I got though, still interessting | 10:30 |
| jdstrand | Aug 12 05:31:26 sec-xenial-amd64 kernel: [ 1346.914860] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28] | 10:31 |
| jdstrand | Aug 12 05:31:26 sec-xenial-amd64 kernel: [ 1346.914868] ecryptfs_write: Error encrypting page; rc = [-28] | 10:31 |
| jdstrand | mvo: that is my issue ^ | 10:31 |
| zyga | jdstrand: you ran out of space | 10:33 |
| zyga | ENOSPC | 10:33 |
| jdstrand | it looks like I did | 10:33 |
| jdstrand | yeah | 10:33 |
| jdstrand | that's weird | 10:34 |
| jdstrand | it completes in the non-ecryptfs | 10:34 |
| jdstrand | which has the same 'not enough space' | 10:34 |
| jdstrand | 2198480 | 10:34 |
| * jdstrand tries to free up some space | 10:34 | |
| mvo | hrm, 4gb is the minimium right now :/ which is silly, 2 is probably fine | 10:35 |
| jdstrand | gimme a few minutes | 10:36 |
| mvo | sure, no rush, I might consider lunch in the meantime :) fwiw, the error I get is "Error: Could not stat device /home/egon/tmp/10/dragon.img - Permission denied." (and strace shows that its indeed parted doing a stat() on that file and gets a permission denied error) | 10:38 |
| ogra_ | mvo, before you go, please approve https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/10/ | 10:39 |
| mvo | ogra_: sure thing | 10:40 |
| ogra_ | ubuntu@localhost:~$ snap list | 10:40 |
| ogra_ | Name Version Rev Developer Notes | 10:40 |
| ogra_ | pi2-kernel 4.4.0-1019-raspi2-1 4 canonical - | 10:40 |
| ogra_ | pi3 16.04-0.1 1 canonical - | 10:40 |
| ogra_ | ubuntu-core 16.04.1 215 canonical - | 10:40 |
| ogra_ | ubuntu@localhost:~$ | 10:40 |
| ogra_ | \o/ | 10:40 |
| ogra_ | pi3 works fine, testing pi2 and dragonboard now | 10:40 |
| jdstrand | mvo: /home/egon/tmp is an interesting path | 10:41 |
| mvo | jdstrand: :) | 10:43 |
| mvo | ogra_: nice! | 10:43 |
| ogra_ | mvo, fyi, once i know all images boot and run, i'll rip out all kernel code from livecd-rootfs, that will massively speed up ubuntu-core builds ... | 10:44 |
| ogra_ | (a build should be below/around 5min then) | 10:44 |
| mvo | neat! | 10:45 |
| ogra_ | happy lunching :) | 10:45 |
| jdstrand | ok | 10:49 |
| jdstrand | Error: Could not stat device /home/testuser/dragon.img - Permission denied. | 10:49 |
| === hikiko|afk is now known as hikiko | ||
| ogra_ | ubuntu@localhost:~$ snap list | 10:57 |
| ogra_ | Name Version Rev Developer Notes | 10:57 |
| ogra_ | pi2 16.04-0.7 12 canonical - | 10:57 |
| ogra_ | pi2-kernel 4.4.0-1019-raspi2-1 4 canonical - | 10:57 |
| ogra_ | ubuntu-core 16.04.1 219 canonical - | 10:57 |
| ogra_ | ubuntu@localhost:~$ | 10:57 |
| ogra_ | pi2 looks good as well ... | 10:57 |
| jdstrand | mvo: ok, I can confirm the issue. stat("/home/testuser/dragon.img", 0x7ffe650b4c40) = -1 EACCES (Permission denied) | 11:01 |
| jdstrand | mvo: I don't know why it is doing that | 11:02 |
| jdstrand | the file exists | 11:03 |
| jdstrand | but no denial in the logs suggests DAC | 11:03 |
| mvo | jdstrand: thanks for confirming, its super confusing - and outside of ecryptfs it does work for you, right? i.e. in /root ? | 11:04 |
| jdstrand | yes, outside of ecryptfs it works fine | 11:05 |
| jdstrand | I thought it might've had something to do with the directory perms of the user since ecryptfs uses 700 for $HOME. that wasn't it | 11:06 |
| mvo | jdstrand: utterly confusing, also working fine when I run it without ubuntu-core-launcher on ecryptfs | 11:07 |
| * mvo really lunches now | 11:07 | |
| jdstrand | mvo: feel free to lunch-- just trying some stuff. I get the same issue if I 'apparmor_parser -R /etc/apparmor.d/usr.lib.snapd.snap-confine | 11:08 |
| ogra_ | ubuntu@localhost:~$ snap list | 11:09 |
| ogra_ | Name Version Rev Developer Notes | 11:09 |
| ogra_ | canonical-snapdragon-linux 4.4.0-1022-1 10 canonical - | 11:09 |
| ogra_ | dragonboard 16.04-0.3 2 canonical - | 11:09 |
| ogra_ | ubuntu-core 16.04.1 218 canonical - | 11:09 |
| ogra_ | ubuntu@localhost:~$ | 11:09 |
| ogra_ | and here we go, dragonboard fine as well | 11:10 |
| * ogra_ dances | 11:10 | |
| morphis | ogra_: can you give me again the link to your latest pi3 kernel snap? | 11:15 |
| ogra_ | morphis, it is in the store (auto-submitted now) | 11:18 |
| ysionneau | zyga: I didn't follow your blog post yet but so far I just duplicated home.go builtin interface and modified it, but I don't see my interface when doing "snap interfaces". I added my interface in all.go | 11:18 |
| morphis | ogra_: yeah, looking for a download link | 11:18 |
| ogra_ | morphis, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel | 11:20 |
| morphis | thanks! | 11:20 |
| zyga | ysionneau: follow my whoole series please, it's lal documented | 11:24 |
| * zyga has laggy link today | 11:25 | |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | mvo: sorry, I think we need tyhicks | 11:45 |
| ogra_ | mvo, http://paste.ubuntu.com/23049201/ ... 300 lines dropped \o/ | 11:48 |
| ogra_ | (well, actually more like 250 lines ... but still :) ) | 11:50 |
| morphis | mvo, niemeyer: can you guys merge https://github.com/snapcore/snapd/pull/1502 today? | 11:51 |
| mup | PR snapd#1502: Add an interface for tpm <Reviewed> <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502> | 11:51 |
| jdstrand | tyhicks: http://paste.ubuntu.com/23049207/ . Note, depending on the diskspace you might need to rm the dragon.img between switching backing and forth from /home/testuser and /home/foo | 11:53 |
| mvo | jdstrand: thanks so much | 12:07 |
| ysionneau | zyga: yeahh I forgot to add my interface to snap/implicit.go :' good it works now | 12:09 |
| mup | PR snapd#1502 closed: Add an interface for tpm <Reviewed> <Created by jessesung> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1502> | 12:28 |
| ogra_ | mvo, i'm building an ubuntu-core with the above livecd-rootfs change now, please dont publish this set until i did some basic local testing with it | 12:30 |
| danwest | just got a messages from 2.14 that the 'copy' plugin was being deprecated in favor for the 'dump' plugin | 12:32 |
| danwest | but dump does not seem to be documented on http://snapcraft.io/docs/reference/plugins | 12:32 |
| popey | danwest: perhaps file an issue at https://github.com/ubuntudesign/snapcraft.io/issues | 12:36 |
| danwest | popey, so I can do that but do we not have any notes, hints or something? looks like the syntax is completely different than 'copy' | 12:39 |
| popey | sure, one moment | 12:39 |
| popey | here's an example of a snapcraft.yaml which has been updated, linked to this so you can see the diff https://github.com/ubuntu/snappy-playpen/issues/216 | 12:40 |
| stokachu | zyga: if a snap requires an interface, does that interface get automatically installed? | 12:40 |
| popey | copy -> dump, files -> organize, basically | 12:40 |
| zyga | stokachu: interfaces are not installed, they are a part of snapd | 12:40 |
| zyga | stokachu: plugs and slots exits on specific snaps | 12:40 |
| zyga | stokachu: except for the core snap that has some implicitly defined slots, those are also defined by snapd | 12:41 |
| stokachu | so if there is a juju plug do i need to make sure juju snap is installed | 12:41 |
| zyga | stokachu: or anything else that provides juju slot | 12:41 |
| stokachu | like is there a way to tell my snap that it has dependencies on juju | 12:41 |
| zyga | stokachu: but yes | 12:41 |
| stokachu | how would a user of my snap know to install juju as well? | 12:41 |
| zyga | stokachu: not at present | 12:41 |
| zyga | stokachu: if the interface name is just juju this could be documented somewhere (or your snap could detect this and recommend something) | 12:42 |
| zyga | stokachu: though right now that is not implemented as interface hooks are not yet implemented | 12:42 |
| stokachu | doesn't having dependencies on other snaps defeat the purpose? | 12:43 |
| zyga | stokachu: it's not a dependency on a snap, it is a plug that is disconnected | 12:43 |
| ogra_ | mvo, ok, a build after the change takes 5-12 min now (fastest arch is 5 min, slowest (s390x) is 13), just amd64 is done in 6min | 12:43 |
| zyga | stokachu: that's a *big* differene | 12:43 |
| zyga | *difference* | 12:43 |
| stokachu | zyga: right but you still have to install another snap to make the plug connected? | 12:44 |
| zyga | stokachu: and connect it as well | 12:44 |
| stokachu | so the only way a user would know that is if they readme some documentation after installing my snap? | 12:44 |
| zyga | stokachu: yes | 12:44 |
| zyga | stokachu: later on your snap can detect this properly and advise the user | 12:44 |
| stokachu | would it just install it automatically? | 12:45 |
| zyga | stokachu: snapd? not at present; I cannot comment on future features that are not planned at this time | 12:45 |
| zyga | stokachu: I would recomemnd that you raise this issue on the mailing list as it is an interesting use case | 12:45 |
| zyga | stokachu: and I see how it would be interesting to offer more streamlined integration | 12:45 |
| stokachu | well it's basically doing what apt does | 12:46 |
| danwest | popey, thanks | 12:46 |
| zyga | stokachu: I disagree, there's a big importand difference here; your snap doesn't need juju, it needs what the juju interface provides, a socket, maybe there are many versions of juju | 12:46 |
| stokachu | my snap does need juju though | 12:47 |
| zyga | stokachu: or a very popular fork of juju called, say, fufu | 12:47 |
| stokachu | i see | 12:47 |
| zyga | stokachu: no, it needs juju *socket*, not some juju libraries or executables (as it cannot use those) | 12:47 |
| stokachu | but if i need to bootstrap i need to run juju executable | 12:48 |
| zyga | stokachu: you have to include that in your snap, you cannot use executables from other snaps | 12:48 |
| zyga | stokachu: that executable can use a juju socket from the juju interface to talk to some juju (or over the network to talk to anything) | 12:48 |
| mup | PR snapd#1550 closed: tests: base security spread tests <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1550> | 12:48 |
| stokachu | ok | 12:48 |
| stokachu | that clears it up, thanks | 12:49 |
| zyga | stokachu: not all the concepts from classic packages and dependencies map to snaps in obvious ways but I strongly believe we're building something better here; | 12:49 |
| stokachu | zyga: so do you think my snap is worth being a snap? i have to call out to other executables like lxc, juju, tail, etc | 12:50 |
| popey | danwest: no problem | 12:51 |
| zyga | stokachu: yes | 12:51 |
| zyga | jdstrand: I looked at 14.04 support and it seems that some prctl arguments are not supported | 12:52 |
| zyga | jdstrand: do you think it would be sensible to just not support them and not generate / use them in our seccomp profiles? | 12:52 |
| mup | PR snapd#1299 closed: create mir interface <Reviewed> <Created by kgunnfront> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1299> | 12:53 |
| jdstrand | zyga: hrmm, that is problematic. note that 14.04 also doesn't have apparmor unix mediation | 12:55 |
| jdstrand | zyga: at least with apparmor we can update the tools and they will ignore unix rules on an old kernel | 12:55 |
| jdstrand | zyga: I'm not sure how to do that with seccomp. I guess check for them at compile time and conditionally add them? | 12:56 |
| mup | PR snapd#1671 opened: spread: Use /home/gopath in spread.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/1671> | 13:07 |
| stokachu | need some help with snapcraft, http://paste.ubuntu.com/23049396/ is packaging files twice, see line: 412 | 13:10 |
| stokachu | and here is my snapcraft.yaml http://paste.ubuntu.com/23049400/, notice that usr/share still exists in the snap even though i have it to be removed under no-docs | 13:11 |
| mup | Bug #1612654 opened: snap interfaces cmd should allow printing of detailed plug/slot info <Snappy:New> <https://launchpad.net/bugs/1612654> | 13:12 |
| stokachu | sergiusens: ^ | 13:13 |
| roadmr | hey folks! What's the interface I need for being able to use the setpriority syscall? (the application has a nice() call). Is it process-control IIRC? When will that be available? (it's not on my snapd 2.11) | 13:14 |
| zyga | jdstrand: yep, we can do that | 13:15 |
| zyga | jdstrand: for 14.04, we can update userspace too I guess (along with the kernel) | 13:15 |
| zyga | jdstrand: so maybe the idea is to do nothing :) | 13:15 |
| jdstrand | zyga: well, with prctl, I think that is libc. I doubt we want to update that | 13:15 |
| zyga | ah I see | 13:16 |
| zyga | hmmm, you are right | 13:16 |
| zyga | though if it's just libc, we can hardcode the missing defines (somewhat iffy but it'd probably work) | 13:16 |
| jdstrand | so apparmor should be fine-- SRU the tools and they'll work fine | 13:17 |
| jdstrand | but yeah, will have to come up with something for snap-confine | 13:17 |
| jdstrand | zyga: we could just distro patch snap-confine on trusty | 13:18 |
| joc_ | roadmr: looks like it is in 2.12 which is somewhere in sru | 13:18 |
| roadmr | thanks joc_ ! | 13:18 |
| jdstrand | zyga: pull out the ones that don't exist there. it is cheap | 13:18 |
| kalikiana | stokachu: you need to remove it in the part it came from. the no-docs part doesn't contain any files | 13:18 |
| === JanC is now known as Guest34729 | ||
| === JanC_ is now known as JanC | ||
| stokachu | kalikiana: dont i have to define what to include as well if imove it up to the conjure part? | 13:19 |
| zyga | jdstrand: yep, but what I'm doing now allows us to do it pretty easily | 13:19 |
| zyga | s/but/and/ | 13:19 |
| stokachu | kalikiana: what about the duplicate files? | 13:24 |
| stokachu | ah the python plugin is pulling in those files | 13:31 |
| stokachu | boo | 13:31 |
| jdstrand | ogra_: fyi, finally circled around to adding pc-kernel and pi2-kernel to the review tools whitelist and it is in r708. I've not requested a store pull yet cause you said there was one more to add | 13:34 |
| jdstrand | ogra_: so, ping me when ready | 13:35 |
| ogra_ | jdstrand, well, we should probably add that in a separate commit, i'm not sure when niemeyer can actually get hold of sabdfl to finish the dragonboard kernel naming decision | 13:35 |
| ogra_ | (but now i poked them both ;) ) | 13:36 |
| jdstrand | roadmr (cc noise][): hey, can you pull r708 of the review tools. it isn't urgent for before the weekend, but sometime next week would be good | 13:36 |
| roadmr | jdstrand: sure, checking... | 13:37 |
| jdstrand | roadmr (cc noise][): there might be an exceedingly small r709 based on what ogra_ just said | 13:37 |
| roadmr | jdstrand: zise maters not, we do or do not :) | 13:38 |
| jdstrand | hehe, yeah :) | 13:38 |
| roadmr | jdstrand: ok, I'll pull 708 now so it's in the queue | 13:38 |
| jdstrand | thanks | 13:38 |
| roadmr | jdstrand: any rough ETA on possible 709? so I can remember to ping you $WHENEVER | 13:38 |
| ogra_ | roadmr, btw, this is awesome ... having the snaps auto-land ... but ... is there a chance that we can also have the publishing automated some day (for now my morning task will be to go to myapps.d.u.c and click publish for all of the nightly builds, would be nice to not have to do that) | 13:39 |
| jdstrand | roadmr: no-- it is based on others deciding what to name something | 13:39 |
| roadmr | jdstrand: ok no problem, I'll just lurk here then :) | 13:40 |
| jdstrand | roadmr: I'll ping you-- you don't have to poll here | 13:40 |
| roadmr | jdstrand: awesome, thanks! | 13:40 |
| jdstrand | np | 13:40 |
| mup | PR snapd#1672 opened: tests: add serial-port interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1672> | 13:40 |
| roadmr | ogra_: hm let me poke a bit at publish behavior. So this is a new revision of an existing snap, right? | 13:41 |
| ogra_ | roadmr, yeah, daily builds of ubuntu-core | 13:41 |
| roadmr | ogra_: (I vaguely remember those should be auto-published but I'm sure I'm wrong) | 13:41 |
| ogra_ | at least for edge they should get auto publishing ... | 13:42 |
| ogra_ | the other channels can stay on manual | 13:42 |
| jdstrand | I thought that was a flag that was toggleable by the publisher (ie, ogra) | 13:43 |
| ogra_ | i wouldnt knwo where to toggle it then | 13:44 |
| jdstrand | the store interface has changed since I last toggled that on something, so not sure it is still there | 13:44 |
| ogra_ | perhaps it is at the "create new snap" page ... but ubuntu-core was created ages ago | 13:46 |
| ogra_ | i definitely dont see such an option anywhere in the current UI for the existing package | 13:46 |
| roadmr | ogra_: ok "There used to be an option to auto-publish - it's gone now" | 13:47 |
| roadmr | on the store that is | 13:47 |
| ogra_ | yep | 13:48 |
| roadmr | ogra_: but cjwatson tells me there's an auto-publish thing on Launchpad | 13:48 |
| ogra_ | yes, that is what we already use | 13:48 |
| roadmr | oh and doesn't that do what you need? Colin says "(intended mainly for use for daily builds and such that publish to edge, but I'm sure there are other uses)" | 13:49 |
| ogra_ | well, it is "Automatically Upload" | 13:49 |
| cjwatson | there are two things | 13:49 |
| ogra_ | and that works fine | 13:49 |
| cjwatson | automatically upload and automatically publish | 13:49 |
| mvo | jdstrand: I have an update for #1460 for you, I hope with my trivial changes it is now ready for merge | 13:49 |
| mvo | jdstrand: (I'm cleaning out old PRs currently) | 13:49 |
| cjwatson | on the edit page, it's the "Store channels:" widget | 13:50 |
| cjwatson | so that is absolutely intended to be automatable right now and I believe that's in use | 13:50 |
| ogra_ | i dont see any publish related bit here | 13:50 |
| ogra_ | not sure if you have powers enough to see https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+edit ? | 13:50 |
| cjwatson | it's spelled "release" there actually | 13:50 |
| cjwatson | I think because that's what the terminology is eventually intended to be, though right now it's inconsistent | 13:51 |
| jdstrand | mvo: I'll take a look. sorry I didn't circle back to it; it got deprioritized based on sprint outcomes so didn't get back yet | 13:51 |
| cjwatson | look under "Automatically upload to store", there's "Store channels" with several checkboxes | 13:51 |
| ogra_ | nothing about release on that page for me either | 13:51 |
| ogra_ | there is one checkbox per channel | 13:51 |
| cjwatson | right, and under that it says "Channels to release this snap package to after uploading it to the store." | 13:51 |
| ogra_ | (and only edge is checked, since we dont want to auto-upload to the others) | 13:51 |
| ogra_ | nope | 13:52 |
| cjwatson | right, so that is auto-publishing | 13:52 |
| mvo | jdstrand: sure, totally fine, should be good now with my PR | 13:52 |
| cjwatson | I'm looking at it right now on prod | 13:52 |
| cjwatson | albeit a different page | 13:52 |
| cjwatson | ogra_: screenshot | 13:52 |
| mvo | jdstrand: (conflict resolved and review feedback addressed) | 13:52 |
| cjwatson | ogra_: so are you saying that this isn't auto-publishing to edge right now, despite you having checked that box? | 13:52 |
| ogra_ | cjwatson, http://imgur.com/a/A29SS and http://imgur.com/a/qQPIj | 13:53 |
| ogra_ | i get the thumbs up icon but still have to go to the specific revision, scroll to the bottom and click the publish button | 13:54 |
| cjwatson | ogra_: the text that you say isn't there is in fact there in your screenshot | 13:54 |
| cjwatson | ogra_: "Channels to release this snap package to after uploading it to the store.", right under the "Edge" checkbox | 13:54 |
| ogra_ | ah, i thought there should be another set of checkboxes along with it | 13:55 |
| cjwatson | that is what those checkboxes do | 13:55 |
| ogra_ | ok, well, it only uploads then ... as you can see in the other screenshot | 13:55 |
| roadmr | ogra_: tip: the sliding thingy at the top right also allows you to flip publish status, no need to scroll to bottom | 13:56 |
| roadmr | "Publish your application", it will read if it's not published | 13:56 |
| cjwatson | ogra_: what am I looking at in that screenshot that indicates that? it says "Package status is Published" | 13:57 |
| ogra_ | roadmr, http://imgur.com/a/pfVa7 ... no sliding thing there :) | 13:57 |
| ogra_ | cjwatson, published are the geen box icons | 13:57 |
| ogra_ | cjwatson, reviewed and "ready to publish" are the tumbs up ones | 13:58 |
| roadmr | ogra_: it's right there... "Package status is Published" followed by "Unpublish". That package *is* published | 13:58 |
| roadmr | ogra_: if it were unpublished (actually, do try it; click on "unpublish") you'd get a "Pubish your application" clickable thingy right htere | 13:58 |
| ogra_ | roadmr, the upload isnt | 13:58 |
| ogra_ | roadmr, see what revision is selected on the left | 13:59 |
| cjwatson | ogra_: how long are you leaving it before you click publish? because I'm seeing LP hitting the snap-release endpoint in our logs | 13:59 |
| roadmr | ogra_: right, I see that... | 13:59 |
| ogra_ | if i scoll down now, there is a publish button at the end of the page | 13:59 |
| ogra_ | cjwatson, dunno, the last onse were in that state for about 1h or so | 13:59 |
| ogra_ | *ones | 13:59 |
| cjwatson | ogra_: next time this happens for that snap, please could you not hit Publish and ask me to look at it first? | 14:00 |
| ogra_ | i yep | 14:00 |
| ogra_ | -i | 14:00 |
| cjwatson | AFAICS LP is doing everything it should | 14:00 |
| jdstrand | mvo: oh, neat! I didn't know you could access a private method from the test.go files with builtin.FooPrivateThing | 14:01 |
| tedg | So I have a public snap that is published, but I'm getting a 401 unauthorized when trying to install it. | 14:01 |
| mvo | jdstrand: yeah, that is the export_test.go pattern, make stuff public *only* for the tests this way | 14:01 |
| jdstrand | I wanted to do that with something else (that I fixed differently) | 14:01 |
| cjwatson | and we're getting 200 back, so the store is *claiming* that it all worked | 14:02 |
| ogra_ | ok | 14:02 |
| tedg | - Download snap "inkscape" (14) from channel "candidate" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/tIrcA87dMWthuDORCCRU0VpidK5SBVOc_14.snap) | 14:02 |
| mvo | jdstrand: its really convinient in a lot of situations | 14:02 |
| kalikiana | tedg: 'snap login' again | 14:02 |
| jdstrand | mvo: yes :) | 14:02 |
| jdstrand | mvo: thanks doubly for the PR-- I wouldn't have known that :) | 14:02 |
| * jdstrand -> door | 14:02 | |
| tedg | kalikiana: Ah, cool. That worked. Does it expire or something? | 14:03 |
| tedg | I wouldn't have thought a public published snap would require a login. | 14:04 |
| roadmr | tedg: it's not the snap's fault | 14:04 |
| roadmr | tedg: at some point you did login, so you have auth creds stored somewhere... | 14:04 |
| roadmr | tedg: but those go stale, that's why you get the 401 | 14:04 |
| tedg | roadmr: Ah, I see. | 14:04 |
| roadmr | tedg: if you ever logged in, snapd would send the creds regardless of the snap's freeosity | 14:04 |
| roadmr | tedg: so 1) snap login fixes it now by manually updating the creds | 14:05 |
| roadmr | tedg: soon snapd will take care of refreshing things in the background so you don't have to reauth | 14:05 |
| roadmr | tedg: 3) sorry about that :( | 14:05 |
| zyga | mwhudson, jdstrand: can I please have commit access to //anonscm.debian.org/collab-maint/snap-confine.git | 14:08 |
| zyga | to the writable side | 14:09 |
| ogra_ | mvo, hmm, seems snap refresh for ubuntu-core on the pi2 breaks uboot.env | 14:13 |
| mvo | ogra_: in what way? | 14:13 |
| ogra_ | after a frefrsh i just had the device sit at the uboot prompt ... a reset got it back booting | 14:13 |
| mvo | ogra_: the very first image had a bug that would kill all vars on the first reboot (you reported that iirc). its not this issue, is it? that got fixed | 14:14 |
| ogra_ | but after this http://paste.ubuntu.com/23049560/ ... so it worked then ... i have to check what happened with uboot when we have a new ubuntu-core to upgrade to ... i was to slow with attaching screen to see what happened | 14:15 |
| ogra_ | mvo, no, then it wouldnt work fine after an extra reset | 14:15 |
| ogra_ | i didnt see what actually happened, but fater the reset i saw it writing uboot.env before it attepted the boot ... so there was a saveenv somewhere happeneing | 14:16 |
| ogra_ | s/fater/after/ | 14:16 |
| ogra_ | anyway, with that one obstacle, upgrades seem to work | 14:17 |
| ogra_ | the system behaves fine | 14:17 |
| ogra_ | bah | 14:18 |
| ogra_ | next reboot is broken agan | 14:18 |
| ogra_ | http://paste.ubuntu.com/23049567/ | 14:18 |
| mvo | ogra_: this looks like snap_core/kernel is unset | 14:19 |
| ogra_ | and boots fine again after a reset | 14:19 |
| mvo | ogra_: can you dump the environment? | 14:19 |
| ogra_ | (and the writing uboot.env is a red herring, it does that every boot) | 14:19 |
| mvo | ogra_: I suspect it boots back to the previous core? or is it actually booting the write one? | 14:19 |
| ogra_ | it boots to the new core ... seems all fine after calling a reset | 14:19 |
| ogra_ | gime a sec while it finished the succesful boot | 14:20 |
| jdstrand | zyga: I'm not a Debian dev (always been on my list, but alas) | 14:20 |
| ogra_ | *finishes | 14:20 |
| * ogra_ reboots | 14:20 | |
| ogra_ | bah, and now it doesnt fail | 14:20 |
| ogra_ | how weird | 14:20 |
| ogra_ | this seems to be random | 14:21 |
| * ogra_ reboots franticly | 14:22 | |
| DrZ | Hi All | 14:24 |
| ogra_ | mvo, could it be that when we update ubuntu-core we update the snap_core var but unset snap_kernel or some such ? | 14:25 |
| mvo | ogra_: I don't know, the dump of the environment (or a copy of the uboot.env file for me) would be great | 14:25 |
| mvo | ogra_: than I can debug | 14:25 |
| ogra_ | mvo, yeah, but it now boots reliably | 14:26 |
| mvo | lol | 14:26 |
| ogra_ | so the dump wouldnt help | 14:26 |
| mvo | totally random? | 14:26 |
| mvo | crazy! | 14:26 |
| ogra_ | it did that in two boots after the update | 14:26 |
| DrZ | Does anyone find the whole parts thing really confusing?? | 14:26 |
| ogra_ | and since then the last 5 just worked | 14:26 |
| DrZ | I don't understand it | 14:26 |
| ogra_ | and i'm on the right ubuntu-core (230) | 14:26 |
| mup | PR snapd#1671 closed: spread: Use /home/gopath in spread.yaml <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1671> | 14:27 |
| ogra_ | mvo, oh, i'm worng it actually switched back to 219 ... so let me try that again ... | 14:27 |
| * ogra_ snap refreshes ubuntu-core | 14:27 | |
| DrZ | How do I know what mystical keywords to use for parts? | 14:28 |
| ogra_ | mvo, eeek ... it now refreshes to the last stable ubuntu-core (the image was built with edge) ... so it goes backwards | 14:29 |
| DrZ | Do I use the deb package name in stage-packages? | 14:29 |
| ogra_ | DrZ, yes | 14:29 |
| DrZ | I want to depend on libgraphicsmagick but I don't know how | 14:29 |
| mvo | ogra_: yeah, the switching back is expected, if it fails to boot it will revert to the previous one | 14:29 |
| mvo | ogra_: that smells like snap_try_core was not setup | 14:29 |
| ogra_ | mvo, right, but in my case it actually first booted to 2330 | 14:29 |
| ogra_ | err | 14:30 |
| ogra_ | 230 | 14:30 |
| ogra_ | gimme a sec, refreshing with --channel edge | 14:30 |
| ogra_ | ok, rebooting now | 14:30 |
| ogra_ | or wait ... | 14:30 |
| DrZ | @ogra Thanks! | 14:30 |
| nothal | DrZ: No such command! | 14:30 |
| ogra_ | snap_core=ubuntu-core_219.snap | 14:30 |
| ogra_ | snap_kernel=pi2-kernel_4.snap | 14:30 |
| ogra_ | snap_mode=try | 14:30 |
| ogra_ | snap_try_core=ubuntu-core_230.snap | 14:30 |
| ogra_ | mvo, ^^ | 14:30 |
| ogra_ | from fw_printenv before reboot | 14:30 |
| mvo | ogra_: oh, that is the issue | 14:31 |
| mvo | ogra_: thanks, I work on a fix | 14:31 |
| ogra_ | mvo, do you notice the issue ? | 14:31 |
| ogra_ | :) | 14:31 |
| mvo | ogra_: yes | 14:31 |
| ogra_ | oh, how i love that we can now quickly build ubuntucore for quick update testing ... :) | 14:32 |
| DrZ | Unknown plugin for sample ? | 14:32 |
| roadmr | hey folks! the copy plugin says it's deprecated, replace with dump, but dump is not a drop-in replacement and I'm not finding any docs or examples on how to use it. Any pointers? | 14:36 |
| DrZ | Oh I use this as the plugin for my Qt5 app "desktop/qt5" ? | 14:36 |
| DrZ | Unknown plugin desktop/qt5 =/ | 14:37 |
| mup | PR snapd#1673 opened: partition: Revert "clear snap_try_{kernel,core} on success" <Created by mvo5> <https://github.com/snapcore/snapd/pull/1673> | 14:40 |
| DrZ | http://pastebin.com/DAWbwUK5 Anyone have a min? | 14:42 |
| DrZ | Source property doesn't match required schema | 14:43 |
| DrZ | I give up. This just isn't easy to understand. | 14:49 |
| stokachu | DrZ: hi | 14:53 |
| stokachu | you need to set keys for each part | 14:53 |
| DrZ | Oh hi | 14:53 |
| stokachu | DrZ: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml | 14:53 |
| DrZ | Keys? | 14:53 |
| stokachu | look at mine for example | 14:53 |
| mup | PR snapd#1674 opened: Interfaces: Builtin: add Udisks2 and Pluggable Storage <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1674> | 14:54 |
| jdstrand | mvo: ok, I merged it. the integration tests are failing but in a way that looks unrelated | 14:54 |
| jdstrand | mvo: other tests are still running | 14:54 |
| mvo | jdstrand: yes, there is a regression with snap-confine | 14:54 |
| DrZ | Which part is the keys/ | 14:55 |
| DrZ | ? | 14:55 |
| DrZ | The conjure directly under parts: | 14:56 |
| DrZ | Is that a key? | 14:56 |
| stokachu | yea | 14:56 |
| stokachu | conjure:, juju: | 14:56 |
| stokachu | those define each section of your parts | 14:56 |
| stokachu | you can name them whatever you want | 14:56 |
| DrZ | Oh so my desktop/qt5 is wrong then | 14:56 |
| stokachu | looks like your tabbing is off | 14:57 |
| stokachu | everything under desktop/qt5 should be indented | 14:57 |
| DrZ | Omg its doing something! | 14:58 |
| ogra_ | magic ! | 14:58 |
| === oparoz is now known as Guest45987 | ||
| === oparoz_ is now known as oparoz | ||
| DrZ | So it downloaded some stuff then tried to build desktop/qt5 | 15:01 |
| DrZ | Then failed because no make file | 15:01 |
| DrZ | or targets | 15:01 |
| DrZ | Not sure how to proceed. | 15:02 |
| ogra_ | DrZ, try https://gitter.im/ubuntu/snappy-playpen ... they are perhaps better at helpning with snap building | 15:03 |
| DrZ | Thanks ogra. | 15:04 |
| DrZ | Sorry for filling up the place with my spam. xP | 15:04 |
| DrZ | I'll let myself out. x) | 15:05 |
| ogra_ | no, it is fine here, we're all just overly busy today it seems | 15:05 |
| ogra_ | this channel is correct ... but your chances are today better in the playpen gitter channel i guess | 15:06 |
| elopio | didrocks: re https://github.com/ubuntu/snappy-playpen/pull/195#issuecomment-238778585 I need more permissions on the ubuntu org in order to use it in docker hub | 15:06 |
| mup | PR ubuntu/snappy-playpen#195: Add docker files for testing the playpen snaps <Created by elopio> <Merged by didrocks> <https://github.com/ubuntu/snappy-playpen/pull/195> | 15:06 |
| DrZ | Its alright I should get busy too.. since im currently at work. Trying to create a snap today on teh side. :) | 15:06 |
| mup | PR snapd#1635 closed: interfaces: builtin: add pluggable storage interface <Created by ssweeny> <Closed by ssweeny> <https://github.com/snapcore/snapd/pull/1635> | 15:07 |
| mup | PR snapcraft#725 opened: Support having the snapcraft.yaml in a subdir <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/725> | 15:07 |
| DrZ | Chat later! | 15:07 |
| mhall119 | sergiusens: didrocks: is snapcraft cleanbuild completely broken for anything that uses a desktop launcher? | 15:08 |
| mhall119 | 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) | 15:08 |
| mhall119 | Command '['lxc', 'exec', 'snapcraft-ethologically-animistic-corrinne', '--', 'snapcraft', 'snap', '--output', 'arduino_1.6.9_amd64.snap']' returned non-zero exit status 1 | 15:08 |
| mhall119 | every time | 15:08 |
| ogra_ | mhall119, there is a bug open for that | 15:09 |
| mhall119 | which means that it's broken | 15:09 |
| ogra_ | bug 1607015 | 15:09 |
| mup | Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015> | 15:09 |
| mhall119 | reported by Alan Pope on 2016-07-27 | 15:10 |
| mup | PR snapcraft#645 closed: If "source: .." do not copy the current directory into itself <Created by evandandrea> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/645> | 15:10 |
| mhall119 | which means it's been broken for at least 15 days now | 15:10 |
| kalikiana | mhall119: for anything using remote parts | 15:10 |
| mhall119 | is there a work-around, or is that whole part of our developer story just completely blocked right now? | 15:10 |
| mup | Bug #1611638 opened: snap upgrade hook <Snappy:In Progress by kyrofa> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1611638> | 15:13 |
| mhall119 | didrocks: can we rename the remote parts to something without a / ? | 15:18 |
| stokachu | in my snap: section can i do - usr/bin/binary and then - -usr/bin? | 15:20 |
| stokachu | so that it only includes that one binary and forgets the rest? | 15:20 |
| ogra_ | mhall119, iirc thats in the works as well | 15:21 |
| mhall119 | stokachu: you might need to do it in the opposite order, -usr/bin and then add usr/bin/binary back | 15:22 |
| * mhall119 is real sure how the plugin resolves them | 15:22 | |
| mhall119 | but it should be possible, yes | 15:22 |
| stokachu | mhall119: ok lemme try that | 15:22 |
| stokachu | mhall119: doesn't work :( | 15:25 |
| mhall119 | stokachu: doesn't work either way? | 15:25 |
| stokachu | lemme retry the original way i had it | 15:25 |
| stokachu | mhall119: yea doesn't work either way | 15:26 |
| mhall119 | sergiusens: didrocks: popey: ^^ can you help stokachu with his snap including only select files? | 15:27 |
| mhall119 | I've reached the extent of my knowledge on it | 15:28 |
| stokachu | like i just want to pull something like /usr/bin/tail from coreutils but not the rest of the binaries in that package | 15:28 |
| popey | i haven't used this method to remove files, but I am sure some of the examples in the playpen do | 15:29 |
| didrocks | mhall119: you probably want josepht, he did care of the transition | 15:29 |
| mhall119 | and you're doing this in the stage: section? or snap: (which is prime now, I think) | 15:29 |
| stokachu | in the snap: | 15:29 |
| stokachu | should i try stage:? | 15:29 |
| didrocks | mhall119: but we can't rename older/remove without a /, that breaks backward compability | 15:29 |
| popey | duplicate? | 15:29 |
| mhall119 | stokachu: yes, stage would be the place to do it I think | 15:29 |
| popey | well, we broke backwards compatibility when we went from copy -> dump... | 15:29 |
| popey | (didn't we?) | 15:30 |
| didrocks | elopio: which kind of perm do you want? | 15:30 |
| kalikiana | stokachu: you want "snap:", that should get you only the files/folders you specify | 15:30 |
| roadmr | \o/ | 15:30 |
| didrocks | popey: yeah, but I don't want to add more | 15:30 |
| didrocks | popey: see the ML discussion | 15:30 |
| popey | ah okay | 15:30 |
| popey | sure. | 15:30 |
| kalikiana | stokachu: note that you'll have to whitelist any libs needed in that case | 15:30 |
| stokachu | kalikiana: ok so only define what i want and the rest is dropped automatically | 15:30 |
| didrocks | seems like josepht had a plan to avoid breaking it, I'munsure why it doesn't work at all though | 15:30 |
| kalikiana | stokachu: yeah | 15:30 |
| mhall119 | didrocks: backwards compatibility is alredy broken | 15:30 |
| stokachu | kalikiana: so usr/lib won't get pulled in | 15:30 |
| mhall119 | literally breaks | 15:30 |
| didrocks | mhall119: and I don't think it's nice for our users | 15:30 |
| didrocks | mhall119: but the desktop launcher is shipping now with a /, with a - and with short name | 15:31 |
| mhall119 | it's not, but it's also already happened | 15:31 |
| didrocks | ( so 3 parts for each flavor :( ) | 15:31 |
| kalikiana | stokachu: right. check ldd or run the bin from the snap to see if any libs are missing | 15:31 |
| didrocks | so not sure what you want to do in the git repo? | 15:31 |
| didrocks | seems like something needs to happen on the importer side | 15:31 |
| stokachu | kalikiana: ok | 15:31 |
| didrocks | elopio: which kind of power do you need for the ubuntu org? | 15:32 |
| stokachu | kalikiana: is there a way to just still pull in everything from lib and usr/lib while just including the binaries i want? | 15:33 |
| stokachu | problem i have is there are 7 binaries i need to use | 15:33 |
| kalikiana | stokachu: http://paste.ubuntu.com/23049706/ | 15:35 |
| stokachu | ok cool | 15:35 |
| kalikiana | the ones with a leading - will be removed | 15:35 |
| josepht | didrocks, mhall119: we should be able to have entries in the wiki now for each of the non-namespaced versions of the desktop helpers. | 15:37 |
| josepht | mhall119: which one are you using? | 15:37 |
| mup | PR snapcraft#568 closed: New plugin: grunt <Created by mariogrip> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/568> | 15:37 |
| mhall119 | josepht: josepht desktop/gtk2 | 15:38 |
| arges | Is there a 'snappy' place to write data that I want to persist even after the snap gets removed? | 15:38 |
| elopio | didrocks: I am not sure. I just know that I can't see it in my Users/Organizations in docker hub. | 15:42 |
| stokachu | arges: google photos | 15:42 |
| kalikiana | :-D | 15:42 |
| josepht | mhall119: can you switch to using 'desktop-gtk2' and do a 'snapcraft update' please? | 15:42 |
| elopio | didrocks: "Automated Builds currently require read and write access since Docker Hub needs to set up a GitHub service hook." | 15:43 |
| arges | stokachu: hah perfect | 15:43 |
| stokachu | :P | 15:43 |
| elopio | didrocks: also: https://docs.docker.com/docker-hub/github/#/github-organizations | 15:44 |
| jacekn | where can I find example uses of "dump" plugin? | 15:44 |
| didrocks | elopio: on dockerhub, I only have ubuntucore and my name | 15:44 |
| didrocks | ah, let me try this | 15:44 |
| didrocks | elopio: it seems the ubuntu org was already created but I can't access it either | 15:45 |
| didrocks | that's why I told you I didn't know this dockerhub shared org worked… | 15:46 |
| mup | PR snapcraft#593 closed: git demo snap update - Bug 1595229 <Created by stub42> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/593> | 15:46 |
| elopio | didrocks: I'm talking about the organization in github, not in dockerhub, right? | 15:46 |
| didrocks | elopio: I meant, if I had enough power on the ubuntu org in github, I should be able to access the dockerhub one, right? | 15:46 |
| elopio | what I'm missing is this, I think: "The organization’s administrators may need to go to the Organization’s “Third party access” screen in “Settings” to grant or deny access to the Docker Hub Registry application. This change will apply to all organization members." | 15:46 |
| lazyPower | we've set this up on our jujusolutions projects for charmbox, and i have quite a few others | 15:47 |
| didrocks | ah ok | 15:47 |
| didrocks | let me try | 15:47 |
| lazyPower | if you are not an admin, you cannot setup the automated build, its pretty cut and dry | 15:47 |
| mhall119 | josepht: appears to be working | 15:47 |
| lazyPower | s/admin/admin in both cases/ | 15:47 |
| elopio | didrocks: no, the github ubuntu org is a different thing. The one I control is called "ubuntu-core", and is not linked in any way with the "ubuntu-core" team in github. | 15:47 |
| elopio | I think it's okay to use this dockerhub ubuntu-core org. The ubuntu one might be too official. | 15:48 |
| josepht | mhall119: great | 15:48 |
| tyhicks | mvo, jdstrand: that eCryptfs bug is a "fun" one | 15:49 |
| didrocks | elopio: but you need to create an access request first, right? | 15:49 |
| jdstrand | tyhicks: oh-- I was wondering what you found out | 15:49 |
| tyhicks | mvo, jdstrand: I'm not sure what's happening there and I can't find a simplified reproducer | 15:49 |
| jdstrand | tyhicks: I did notice it was parted | 15:50 |
| tyhicks | jdstrand: there are very few operations on the dragon.img file and its opened file descriptors so I thought it'd be easy to do | 15:50 |
| jdstrand | tyhicks: like, create the image, do parted and it barfs | 15:50 |
| * jdstrand didn't do that, and that is hardly a simple reproducer | 15:51 | |
| tyhicks | jdstrand: it looks like an openat() -> ftruncate() -> close() -> lstat() sequence would do the trick but it isn't | 15:52 |
| tyhicks | ecryptfs only returns EACCES in one place so I'll see if that's the location of the failure or if it is somewhere in the VFS | 15:52 |
| jdstrand | huh | 15:53 |
| blackboxsw_ | when running my built gtk-based snap for workrave, I get Gtk-WARNING **: Locale not supported by C library. | 15:56 |
| blackboxsw_ | Using the fallback 'C' locale. | 15:56 |
| blackboxsw_ | do I need to pass LC_ALL="en.utf-8" somehow into the snap build process maybe | 15:57 |
| blackboxsw_ | ? | 15:57 |
| blackboxsw_ | I know that question is coming way out of left field. I didn't see any example snaps in the snappy-playpen that do any locale setting magic | 15:58 |
| blackboxsw_ | I'm referring to some of the same symtoms as #1584357 | 16:00 |
| mup | Bug #1584357: Snappy GTK applications <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1584357> | 16:00 |
| === danwest_ is now known as danwest | ||
| mup | Bug #1584456 changed: apparmor denial using ptmx char device <apparmor> <Snappy Launcher:In Progress by jdstrand> <linux (Ubuntu):Confirmed for tyhicks> <https://launchpad.net/bugs/1584456> | 16:25 |
| mup | PR snapd#1633 closed: many: move to purely hash based key lookup and to new key/signature format (v1) <Critical> <Reviewed> <Created by emgee> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1633> | 16:30 |
| mup | PR snapcraft#726 opened: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726> | 16:43 |
| sabdfl | ogra_, niemeyer, i can chat shortly if you want | 16:47 |
| niemeyer | sabdfl: Heya | 16:50 |
| niemeyer | What's the topic again? I probably missed the preamble | 16:52 |
| sabdfl | i saw a comment referencing you and me, and dragonboard naming | 16:58 |
| tsimonq2 | o/ sabdfl :) | 16:59 |
| mup | PR snapcraft#727 opened: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <https://github.com/snapcore/snapcraft/pull/727> | 17:13 |
| mup | PR snapd#1617 closed: many: move to purely hash based key lookup and to new key/signature format (v1) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1617> | 17:15 |
| niemeyer | sabdfl: I need to catch up with the kernel team to sort this out I think.. if we need to unblock this today, I'd just go with dragonboard and dragonboard-kernel.. | 17:18 |
| niemeyer | sabdfl: The question is whether this kernel is more generic, which might hint at a snapdragon-kernel.. | 17:19 |
| mvo | tyhicks: please keep me updated on this bug, its very interessting (and head scratching) indeed :) | 17:22 |
| mup | PR snapd#1675 opened: spread: use snap-confine from ppa:snappy-dev/image for the tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1675> | 17:27 |
| zyga | jdstrand: +1 to merge https://github.com/snapcore/snap-confine/pull/99 | 17:46 |
| mup | PR snap-confine#99: Disable owner checks for 14.04-style private home <Created by zyga> <Conflict> <https://github.com/snapcore/snap-confine/pull/99> | 17:46 |
| zyga | ? | 17:46 |
| jdstrand | zyga: yes, commented in PR | 17:49 |
| zyga | ah, thanks | 17:50 |
| jdstrand | zyga: no, I only *just* did it :) | 17:51 |
| jdstrand | ok, I'm time-shifting today so out now | 17:51 |
| jdstrand | have a nice weekend :) | 17:51 |
| zyga | jdstrand: likewise! | 17:54 |
| jcastro | what are my options for managing storage in a snap? I am making a snap for snapraid which needs access to disks and arbritrary directories. | 17:56 |
| jcastro | So no one is confused snapraid is completely unrelated to snappy. | 17:57 |
| ogra_ | sabdfl, we need the final na,me for the dragonboard kernel and it was not sure if it should be "dragonborad-kernel" or "snapdragon-kernel" (as niemeyer explained, there was desire from the kerel team to make it generically usable laster, just via different device trees) ... with the new build setuo i need the name in advance to create an LP project for the snap package | 17:59 |
| mup | Bug #1612757 opened: getpid system call is blocked by seccomp under confinement <Snappy:New> <https://launchpad.net/bugs/1612757> | 18:02 |
| mup | Bug #1612759 opened: fchown system call is blocked by seccomp under confinement <Snappy:New> <https://launchpad.net/bugs/1612759> | 18:05 |
| rbasak | Where should I file bugs against the docs? | 18:14 |
| rbasak | There's "Report a bug on this site" at the bottom, but when I did that for Juju, it didn't end up in the right place. | 18:14 |
| rbasak | (see https://github.com/juju/docs/issues/716) | 18:15 |
| niemeyer | ogra_: I suggest unblocking that by naming it dragonboard-kernel.. that's the platform we care about today, and are promising proper support | 18:22 |
| ogra_ | niemeyer, ack | 18:22 |
| niemeyer | We can review these details later, if/when necessary | 18:22 |
| niemeyer | cc sabdfl | 18:22 |
| ogra_ | mvo, still around ? can you crate a dragonboard-kernel package with the shared account ? (i'll care for the rest (populationetc) | 18:22 |
| mup | PR snapd#1659 closed: wrappers: ensure services have a valid SNAP_USER_DATA dir <Reviewed> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1659> | 18:24 |
| mup | PR snapd#1674 closed: Interfaces: Builtin: add Udisks2 and Pluggable Storage <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1674> | 18:24 |
| mvo | ogra_: sure | 18:25 |
| mvo | ogra_: so thats the aggreed name? | 18:25 |
| ogra_ | thanks (i dont really want to hold you back from starting your WE though) | 18:25 |
| ogra_ | mvo, the name that niemeyer and i just agreed on :) | 18:26 |
| ogra_ | worst case we can still change/drop it | 18:26 |
| sabdfl | niemeyer, ogra_ +1 | 18:27 |
| ogra_ | cool | 18:27 |
| mvo | ogra_: name is there, do you have a snap? I think we need a snap so that I can give you collab rights, however I can just tweak the existing canonical-dragon-linux | 18:27 |
| ogra_ | mvo, oh, gimme 10mins to set up an LP project then | 18:27 |
| mvo | ogra_: ok | 18:27 |
| ogra_ | mvo, https://code.launchpad.net/~snappy-dev/+snap/dragonboard-kernel ... (i hope the 39min are a lie there) | 18:34 |
| ogra_ | oh, they were ... (it said 339min til it starts) | 18:35 |
| ogra_ | *39 | 18:35 |
| ogra_ | should take ~10min | 18:36 |
| mvo | ogra_: neato | 18:39 |
| dobey | hmm, why do i need to use sudo to install a local snap package? | 18:39 |
| ogra_ | dobey, why do you need sudo to install a local deb package ? | 18:39 |
| dobey | ogra_: i don't need sudo to install a click | 18:40 |
| ogra_ | (its a matter of filesystem permissions) | 18:40 |
| dobey | ogra_: and i'm sure snap install doesn't install files into the snappy snap itself :) | 18:40 |
| ogra_ | it installs to /snap | 18:40 |
| dobey | ogra_: and what does logging into a u1 account have to do with filesystem permissions? | 18:41 |
| dobey | ogra_: ie, why do i not need root if i log in and install something from the store, but i do need root otherwise? | 18:41 |
| ogra_ | which is a system level dir without special permissions (unlike the /opt tree we use for clisk) | 18:41 |
| ogra_ | dobey, click packages dont install system wide, they are bound to the user | 18:41 |
| arges | mvo: thanks for the review of https://github.com/snapcore/snapd/pull/1602. I've pushed updates but I can't seem to get the travis-ci test to pass. It doesn't look like a failure on my part. Will that affect merging? | 18:41 |
| mup | PR snapd#1602: interfaces: add kernel-module interface for module insertion <Reviewed> <Created by arges> <https://github.com/snapcore/snapd/pull/1602> | 18:41 |
| ogra_ | snap packages dont | 18:41 |
| dobey | ogra_: /opt tree doesn't have special permissions either. non-root works because pkcon | 18:41 |
| ogra_ | dobey, so they effectively use root too ... just through a suid binary managed by pkcon ;) | 18:42 |
| dobey | ogra_: that doesn't explain why i don't need root if i log into the app store with snap | 18:42 |
| dobey | http://www.ubuntu.com/desktop/snappy <- no sudo | 18:43 |
| dobey | http://snapcraft.io/create/ <- sudo | 18:43 |
| ogra_ | dobey, you can use snap login | 18:43 |
| ogra_ | at any time | 18:43 |
| ogra_ | afaik then sudo isnt needed | 18:43 |
| dobey | so when will snappy use the credentials from online accounts? | 18:44 |
| ogra_ | mvo, snap is done, grab it while its hot :) | 18:44 |
| mvo | ogra_: already downloading ;) | 18:44 |
| ogra_ | heh | 18:44 |
| ogra_ | it is all so fast now :) | 18:44 |
| mvo | indeed, really nice | 18:45 |
| ogra_ | yeah, the best move we ever did | 18:45 |
| ogra_ | (regarding builds at least :) ) | 18:45 |
| dobey | ogra_: i'm asking this because i need to figure out how to integrate installing of snaps in the store scope for ubuntu personal/phone stuff. "open a terminal and do snap login first" is not an acceptable solution :) | 18:45 |
| ogra_ | you could embed a vte widget in your scope then :P | 18:46 |
| ogra_ | (jk) | 18:46 |
| ali1234 | what does snap login log you in to? | 18:46 |
| * dobey files a bug against unity8: no terminal widget avaialble for scopes | 18:46 | |
| ogra_ | dobey, not my area of expetise i fear ... you need the snappy core team or the store guys | 18:47 |
| ogra_ | +r | 18:47 |
| dobey | ali1234: it's your ubuntu one account credentials | 18:47 |
| dobey | ogra_: well that's why i joined #snappy :) | 18:47 |
| ogra_ | right | 18:47 |
| ali1234 | so as long as i'm logged in to U1 then i can side load anything without sudo? | 18:48 |
| dobey | i think i have most of the store stuff figured out | 18:48 |
| dobey | just trying to find a way to install a snap without having to do too much extra work, now | 18:48 |
| ali1234 | can i build an all-snap image with my own snaps baked in? | 18:49 |
| mvo | ogra_: you have mail | 18:50 |
| ogra_ | yay | 18:50 |
| ali1234 | also what exactly is a gadget snap? | 18:50 |
| ogra_ | mvo, interesting ... twice actually (same link twice) | 18:51 |
| ogra_ | ok, set up for auto-submission ... | 18:52 |
| * ogra_ triggers another build to test that works as desired | 18:52 | |
| ogra_ | jdstrand, so it is pc-kernel, pi3-kernel and dragonboard-kernel now | 18:54 |
| mvo | ogra_: how can you set it to auto-publish? it seems that works for ubuntu-core somehow? | 18:55 |
| mvo | ogra_: no pi2-kernel? | 18:55 |
| ogra_ | eeek ! | 18:55 |
| ogra_ | jdstrand, not pi3-kernel, but pi2-kernel | 18:55 |
| ogra_ | mvo, uufff, thanks ! | 18:56 |
| ogra_ | mvo, we need jamies magic, then it should just work | 18:56 |
| mvo | ogra_: aha! | 18:56 |
| mvo | ogra_: I build a dragonboard image now (unless you are already on that) | 18:56 |
| ogra_ | mvo, no, just go ahead | 18:57 |
| ogra_ | i'm waiting for LP to regonize the branch change to actually start an auto-build now | 18:57 |
| ogra_ | to see the thing works from start to end | 18:57 |
| ogra_ | but LP doesnt seem to see my change or i'm in limbo between some scheduler runs | 18:58 |
| ali1234 | is it possible to have the writable partition be a ramdisk? | 19:08 |
| ogra_ | ali1234, tricky, give that your readonly bits sit init | 19:08 |
| ali1234 | not if they are baked into the initial image, surely? | 19:09 |
| ogra_ | ? | 19:09 |
| mvo | ogra_: could you please check http://people.canonical.com/~mvo/all-snaps/16/all-snaps-dragonboard.img.xz and check if that works on your dragonboard | 19:09 |
| ogra_ | mvo, will do | 19:09 |
| ogra_ | (i have to do some RL stuff for about 15min though, but will then ...) | 19:10 |
| mvo | ogra_: ta! | 19:11 |
| === faenil_ is now known as faenil | ||
| dobey | if i filed a bug agaisnt snapd package in ubuntu should i also have it affects snappy project? | 20:02 |
| ogra_ | dobey, yes please | 20:07 |
| ogra_ | not sure how well snapd package bugs are actually monitored | 20:07 |
| mup | Bug #1612783 opened: snapd requires U1 account to install local packages <Canonical System Image:New> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1612783> | 20:08 |
| ahasenack | hm, I'm still confused about config files in snaps | 20:15 |
| ahasenack | I thought I could use SNAP_DATA for config files | 20:15 |
| ahasenack | but the snap itself can't ship files in there, right. That's a place for the snap to store files once it's running | 20:15 |
| ahasenack | so I should copy the config files to $SNAP_DATA on the first run if they are not there yet? | 20:16 |
| kyrofa | ahasenack, indeed, that's how to do it right now | 20:17 |
| kyrofa | ahasenack, I'm hoping for an install hook that will make that easier | 20:18 |
| ahasenack | ok | 20:18 |
| ali1234 | is it safe to use /tmp/ in a snap? | 20:23 |
| kyrofa | ali1234, yes, it's not the system-wide /tmp though | 20:25 |
| kyrofa | ali1234, i.e. /tmp to the snap is actually /tmp/snap.foo.bar/ on the system | 20:25 |
| ali1234 | thats fine as long as it works | 20:25 |
| kyrofa | ali1234, indeed | 20:25 |
| ahasenack | the new dump plugins, it's not documented yet, is it? | 20:27 |
| ahasenack | I don't see it in http://snapcraft.io/docs/reference/plugins | 20:27 |
| ahasenack | s/plugins/plugin/ | 20:27 |
| ahasenack | snapcraft help dump didn't help much, it's just a pointer to other docs | 20:27 |
| ali1234 | okay so i've snapped a QML app for raspberry pi eglfs, who wants to try it? | 20:29 |
| ali1234 | it needs devmode to access vchiq | 20:29 |
| kyrofa | ahasenack, happy to help | 20:31 |
| ahasenack | just replacing "copy" with "dump" didn't work, so I stayed with "copy" for now :) | 20:31 |
| kyrofa | ahasenack, the dump plugin takes the complete source you gave it and copied it into the root of the snap. If you want to filter files out, you can do so using the stage or snap keywords (available to every plugin). If you want to move files around, use the organize keyword (also available to every plugin) | 20:33 |
| ahasenack | I have 3 config files at the root of my snapcraft directory, alongside the yaml. I want thse copied to specific paths inside the snap | 20:33 |
| ahasenack | I have been using copy's "files" key for that | 20:34 |
| ahasenack | like | 20:34 |
| ahasenack | files: | 20:34 |
| ahasenack | squid-deb-proxy.conf: /usr/share/config/squid-deb-proxy/ | 20:34 |
| kyrofa | ahasenack, indeed. Here, let me paste something for you | 20:34 |
| ahasenack | hm, stage and prime directories are empty after a build | 20:38 |
| kyrofa | ahasenack, http://pastebin.com/kugi0fRV . Sorry for using pastebin, paste.ubuntu.com is undergoing maintenance right now | 20:39 |
| ahasenack | is this new in snapcraft? | 20:39 |
| ahasenack | ah, organize | 20:39 |
| kyrofa | ahasenack, no, nothing has changed in that regard. What is your definition of "build"? `snapcraft build`? Or a complete run of `snapcraft`? | 20:40 |
| ahasenack | just "snapcraft" | 20:40 |
| ahasenack | running again with the dump plugin now | 20:40 |
| kyrofa | ahasenack, then no, stage and prime should not be empty, or the snap will be empty as well | 20:41 |
| ahasenack | snap was 19Mb big | 20:41 |
| ahasenack | checking things | 20:41 |
| ahasenack | maybe it failed to build and that was just the previous version | 20:41 |
| ahasenack | yeah, that was it | 20:41 |
| ahasenack | new error, haven't seen it before. debugging | 20:42 |
| ahasenack | [Errno 39] Directory not empty: '/home/andreas/snaps/snap-squid-deb-proxy/parts/squid-deb-proxy/install' | 20:42 |
| kyrofa | ahasenack, please run with snapcraft -d and paste the output | 20:43 |
| ahasenack | ugh, pastebin is awful :) | 20:46 |
| ahasenack | kyrofa: http://pastebin.com/TV0tHCj9 | 20:47 |
| kyrofa | ahasenack, no kidding | 20:47 |
| ali1234 | pastebinit supports paste.debian.net i believe | 20:48 |
| kyrofa | ahasenack, ugh, that's a big in the dump plugin... sorry :( . To workaround, `rm -rf parts/squid-deb-proxy/install` | 20:49 |
| kyrofa | ahasenack, I'll fix that right now | 20:49 |
| ahasenack | do the rm -rf and then what, snapcraft again? | 20:49 |
| kyrofa | ahasenack, indeed | 20:51 |
| ahasenack | ok | 20:51 |
| ahasenack | it just happens again | 20:51 |
| ahasenack | I guess I would need to specifically ask for an intermediary step, not the whole snapcraft run | 20:52 |
| kyrofa | ahasenack, ah, bug #1611827 | 20:53 |
| mup | Bug #1611827: dump plugin with stage-packages fails <Snapcraft:New> <https://launchpad.net/bugs/1611827> | 20:53 |
| kyrofa | ahasenack, is that it? | 20:53 |
| ahasenack | ok, I'll subscribe | 20:53 |
| ahasenack | yes, I have stage-packages | 20:54 |
| kyrofa | ahasenack, workaround for now: put the stage packages on a part that uses the nil plugin | 20:56 |
| ahasenack | ok | 20:57 |
| ahoneybun | https://fuchsia.googlesource.com/third_party/snappy/ | 21:02 |
| ahasenack | is usr/sbin/ from inside the snap in $PATH? | 21:08 |
| ahasenack | export PATH="$SNAP/bin:$SNAP/usr/bin:$PATH" | 21:08 |
| ahasenack | no :/ | 21:09 |
| ahasenack | so I need to move my binary from usr/sbin to usr/bin post-build | 21:12 |
| kyrofa | ahasenack, or write a wrapper that adds sbin to the path | 21:18 |
| kyrofa | ahasenack, that will get less painful soon when we add environment support | 21:19 |
| ahasenack | the revision of the snap is part of PATH | 21:19 |
| ahasenack | I think I got it working with "organize" | 21:19 |
| ahasenack | yeah | 21:21 |
| ahasenack | now it's that known problem of lack dropping privileges | 21:21 |
| mup | PR snapcraft#720 closed: Start the fake parts server only in the tests that need it <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/720> | 21:22 |
| kyrofa | ahasenack, you should be able to use the $SNAP* environment variables | 21:24 |
| ahasenack | kyrofa: thx, have a nice weekend | 21:27 |
| * ahasenack -> EOW | 21:27 | |
| mup | PR snapcraft#728 opened: Use link_or_copy instead of just hard-links for deb cache <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/728> | 21:58 |
| mup | PR snapcraft#723 closed: Set owner/group for directories in stage and prime <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/723> | 22:22 |
| === evnmar_ is now known as evnmar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!