| ali1234 | there's a generated wrapper in the mix too | 00:01 |
|---|---|---|
| ali1234 | my command line in the snapcraft is : desktop-launch infodump --platform eglfs | 00:01 |
| ali1234 | okay infodump is completely absent from the snap... wat | 00:06 |
| ali1234 | oh wait, no it isn't | 00:06 |
| ali1234 | it is at /snap/infodump/x1/home/ubuntu/snaps/infodump-test/parts/infodump | 00:06 |
| ali1234 | /home/ubuntu/snaps/infodump-test is of course the directory with the snapcraft.yaml | 00:07 |
| ali1234 | command-infodump.wrapper has: exec "desktop-launch" infodump -platform eglfs "$@" | 00:11 |
| ali1234 | so of course infodump is not on the part | 00:11 |
| ali1234 | *path | 00:11 |
| ali1234 | hmm i see a snapcraft upgrade on desktop | 00:20 |
| ali1234 | maybe i can't reproduce it because it is a regression | 00:20 |
| stokachu | whats your snapcraft.yaml look like ali1234 | 00:37 |
| ali1234 | http://paste.ubuntu.com/22975659/ | 00:37 |
| stokachu | ali1234: i think the infodump under parts: is what is confusing snappy | 00:38 |
| stokachu | call it like infodump-copy | 00:38 |
| stokachu | ali1234: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml thats mine | 00:38 |
| stokachu | i had the same problem with my binary 'conjure-up' | 00:39 |
| ali1234 | i have another one | 00:39 |
| stokachu | had to make sure the keys didn't overlap | 00:39 |
| ali1234 | http://paste.ubuntu.com/22975816/ | 00:39 |
| ali1234 | this one works fine | 00:39 |
| stokachu | ah ok | 00:39 |
| stokachu | may not be the same problem i had then | 00:39 |
| ali1234 | aaaaaaargh | 00:41 |
| ali1234 | found the problem :/ | 00:41 |
| ali1234 | target.path = build in the stupid qmake file | 00:41 |
| stokachu | ah | 00:41 |
| ali1234 | i thought i fixed that | 00:41 |
| stokachu | well at least you know the issue now :) | 00:42 |
| ali1234 | yeah. i wonder why it reverted | 00:42 |
| ali1234 | probably forgot to commit the change on git | 00:42 |
| stokachu | ive spent several days trying ot get my stuff packaged | 00:43 |
| stokachu | i feel your pain | 00:43 |
| ali1234 | i keep running into walls tbh | 00:43 |
| ali1234 | missing interfaces mainly | 00:43 |
| stokachu | yea same here | 00:43 |
| stokachu | im just pulling everything i need into a single snap | 00:43 |
| stokachu | makes it bloated but works | 00:43 |
| ali1234 | i'm making something for embedded use... at the moment i need: sysfs gpio, i2c-dev, sysfs backlight, uinput, videocore... and a patched Qt | 00:45 |
| ali1234 | oh and pulseaudio in the all-snap | 00:45 |
| === JanC is now known as Guest62829 | ||
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| === Michaela is now known as Mikaela | ||
| === mpontillo_ is now known as mpontillo | ||
| === CrazyMelon is now known as CrazyLemon | ||
| === tgm4883_ is now known as tgm4883 | ||
| === lfaraone_ is now known as lfaraone | ||
| === elijah_ is now known as elijah | ||
| pbek | For some reason I get a "Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop/qt5'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache" again when building a snap with Launchpad or locally with snapcraft. It worked 12h ago. | 06:56 |
| pbek | I locally have snapcraft 2.14 installed. | 06:57 |
| didrocks | pbek: hey, did the issue just happened? | 06:57 |
| didrocks | I wonder if the transition plan from josepht didn't work as expected | 06:57 |
| pbek | yes, just now. worked 12h ago | 06:57 |
| pbek | https://launchpadlibrarian.net/278346021/buildlog_snap_ubuntu_xenial_amd64_qownnotes_BUILDING.txt.gz | 06:57 |
| didrocks | ok, can you try replacing it with desktop-qt5 and check if it works? | 06:57 |
| didrocks | josepht: sergiusens: seems like something is wrong on the transition plan for / in parts, see ^ | 06:59 |
| jcjordyn120 | go join #thelinuxgeekcommunity | 06:59 |
| pbek | didrocks: I still get "Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop-qt5'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache" | 07:00 |
| didrocks | did you run snapcraft update as indicated? | 07:00 |
| didrocks | (I think you did, but just checking ;)) | 07:00 |
| pbek | yes, I did | 07:00 |
| didrocks | argh | 07:00 |
| pbek | (it's part of my build script) ;) | 07:01 |
| didrocks | I don't remember the API endpoint… is it urgent, like, can this wait for josepht to show up online to debug with him? | 07:01 |
| didrocks | I can give you a quick workaround, but I think you will not be the only one to get this | 07:01 |
| didrocks | (but then, please stay online and revert the workaround to ensure we get to the bottom of this :)) | 07:01 |
| pbek | wgrant from the launchpad channel mentioned: https://parts.snapcraft.io/v1/parts.yaml's desktop part looks weird. I wonder if something's changed around subparts. | 07:02 |
| didrocks | yeah, subparts changed | 07:02 |
| didrocks | see the ML and my concerns about it :) | 07:02 |
| didrocks | yeah, no dekstop/* or desktop-* entry here | 07:02 |
| didrocks | that's why it's failing | 07:03 |
| pbek | It's not urgent, I there are not many snap users yet... | 07:03 |
| didrocks | pbek: I think they will be up in ~5-6h, mind pinging them then? | 07:03 |
| pbek | https://code.launchpad.net/~pbek/+snap/qownnotes | 07:03 |
| pbek | didrocks: I think I'll be gone by then... | 07:04 |
| pbek | this is the repository I use: https://git.launchpad.net/~pbek/qownnotes-snap/tree/ | 07:05 |
| didrocks | pbek: perfect, I was going to ask you for the repo :) I'll ensure we have a look at it so that we can fix this. Sorry for the trouble | 07:05 |
| pbek | snapcraft is software... always evolving :) | 07:06 |
| didrocks | pbek: heh, I have a tab opened with your tree as a reminder :) | 07:07 |
| pbek | *giggle* | 07:07 |
| didrocks | pbek: btw, I think source-type isn't necessary in your snapcraft.yaml. Autodetection from extension should work | 07:08 |
| didrocks | (if not, we can fix it) | 07:08 |
| pbek | I will remove it in the next release, thank you | 07:09 |
| didrocks | yw! | 07:11 |
| pbek | I love snaps, I hope my last issues I have with the QOwnNotes snap will be gone some day (or I find a workaround). | 07:13 |
| pbek | issues: https://github.com/ubuntu/snappy-playpen/issues/145 (on the bottom) | 07:14 |
| didrocks | pbek: the home issue changing is more a feature than an issue, what's the pb with it? | 07:14 |
| didrocks | Qt theme -> we have a plan with platform/runtime snaps for this :) | 07:15 |
| pbek | QOwnNotes did detect the home directory and stored that as setting for the note folder (like `/home/omega/snap/qownnotes/13`), but after an update the folder wasn't accessible any more because the revision changed ;) | 07:17 |
| pbek | I worked around the problem by cutting out the `/snap/qownnotes/\d+` part | 07:18 |
| didrocks | ahhhhhh, you save the folder to not really on env variable afterward, interesting | 07:20 |
| didrocks | you could as well replace this version number with current/ | 07:20 |
| didrocks | scratch that, doesn't work for SNAP_USER_DATA | 07:21 |
| pbek | I got that directory from QDir::homePath() ;) but in the case of QOwnNotes I wanted the real home directory of the user because ownCloud will be syncing with that anyway, so my workaround is ok | 07:23 |
| pbek | the character set problems and the languages are more bothering... | 07:23 |
| didrocks | yeah, there has been discussions on the ML. There are some ideas to explore to fix those | 07:24 |
| pbek | +1 :) | 07:27 |
| mup | PR snapd#1668 opened: tests: prevent restore error on test failure <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1668> | 07:58 |
| liuxg | when I try to remove a snap from the system, it complains "error: cannot remove "tomcat-webapp-demo": snap "tomcat-webapp-demo" has changes in progress". is there any way to force to remove it from my system? thanks | 08:17 |
| ogra_ | sergiusens, kyrofa, josepht, bah, the final version of the "type: os" fix doesnt work, something you changed since the initial commit seems to have broken it ... (the snapcraft i used in the PPA had the initial patch only) | 08:21 |
| ogra_ | ubuntu@localhost:~$ ls -lh /home/ | 08:21 |
| ogra_ | total 4.0K | 08:21 |
| ogra_ | drwxr-xr-x 3 root root 4.0K Aug 11 08:17 ubuntu | 08:21 |
| ogra_ | ubuntu@localhost:~$ | 08:21 |
| === chihchun is now known as chihchun_afk | ||
| === popey_ is now known as popey | ||
| === hikiko is now known as hikiko|ln | ||
| zyga | ogra_: http://www.cnx-software.com/2016/08/11/u-boot-now-supports-uefi-on-32-bit-and-64-bit-arm-platforms/?utm_campaign=shareaholic&utm_medium=google_plus&utm_source=socialnetwork | 10:16 |
| ogra_ | zyga, yeah, awful | 10:17 |
| timothy | lol | 10:17 |
| ogra_ | zyga, oh, idmap ! thats indeed a good idea | 10:23 |
| * ogra_ just read the bug | 10:23 | |
| ogra_ | s/bug/comment/ | 10:23 |
| ogra_ | though that operates on a filesystem level | 10:24 |
| ogra_ | so you would have to hook iinto squashfs | 10:25 |
| zyga | ogra_: you can either idmap all the snaps so that they look consistent or idmap the hostfs so that it looks consistent for running snap apps | 10:32 |
| ogra_ | well, doesnt that need support on the FS side ? | 10:33 |
| zyga | ogra_: but yeah, I just don't know if idmap is available outside of nfs | 10:33 |
| ogra_ | (does it work with other filesystems than NFS) | 10:33 |
| zyga | yeah | 10:33 |
| zyga | well, just a kernel patch (rolls eyes) | 10:33 |
| ogra_ | but see my bug comment, seems squashfs actually creates a caching table for the uids | 10:34 |
| * mwhudson reads macaroon code, feels his brain dribble out of his ears | 10:34 | |
| ogra_ | so if something like idmap could hook in there and simply cheat them to the correct value, that could work | 10:34 |
| zyga | ogra_: as for uefi on uboot, I think that's pretty useful :) | 10:35 |
| * ogra_ hands mwhudson two cups for his ears | 10:35 | |
| ogra_ | zyga, i dont ... but yeah, some cloud people might like it | 10:35 |
| * ogra_ finds it as useful as chainloading grub from uboot ... :P | 10:35 | |
| ogra_ | (just added useless complexity) | 10:35 |
| ogra_ | (since you need to hand the dtbs from one bootloader implementation to the next on the boards we use) | 10:36 |
| mwhudson | ogra_: would you like some acpi too? | 10:37 |
| ogra_ | hahaha | 10:37 |
| * mwhudson gets LEG flashbacks | 10:37 | |
| ogra_ | heh, yeah, though didnt acpi for arm64 server boards actually happen in the end ? | 10:38 |
| mwhudson | define 'happen' | 10:38 |
| ogra_ | well, being implemented ... | 10:38 |
| mwhudson | i think there is support in the kernel at last, not sure about shipping hw actually using it... | 10:38 |
| ogra_ | i think there are some server boards | 10:38 |
| ogra_ | doing uefi and acpi ... so you dont need to adjust the cloud SW that runs on top | 10:39 |
| mwhudson | i don't think ubuntu is supported on any of them using acpi though | 10:39 |
| mwhudson | (might be wrong, i sort of agressively stopped paying attention a while ago) | 10:39 |
| ogra_ | yeah, that was a jonmasters thing ... i guess fedora supports it | 10:40 |
| zyga | ogra_: if you think of it ubuntu-core is just like that cloud software, whatever you or I think about acpi or uefi, consistency is useful | 10:46 |
| zyga | mwhudson, jdstrand, mvo: https://github.com/snapcore/snap-confine/pull/98/files | 10:46 |
| mup | PR snap-confine#98: Move apparmor profile for snap-confine to src/ <Created by zyga> <https://github.com/snapcore/snap-confine/pull/98> | 10:46 |
| zyga | this is a simple but tricky change, I just want to ensure that all the packaging gets it right downstream | 10:46 |
| mwhudson | zyga: i certainly support the intent | 10:47 |
| ogra_ | hmpf ... linux-meta in proposed is out of sync ... that nicely made tonights ubuntu-core amd64 builds explode | 10:49 |
| ogra_ | mwhudson, seems you havhe e to wait a day longer for the netplan fix :( | 10:50 |
| mwhudson | ogra_: it's ok, we're making our own snaps anyway still | 10:51 |
| ogra_ | err, so i can revert the writable dir ? | 10:51 |
| mwhudson | well no, we'll need it sooner or later | 10:53 |
| ogra_ | ok | 10:53 |
| mwhudson | just the failure of builds today is not a problem | 10:53 |
| ogra_ | good | 10:53 |
| ogra_ | i hope i have the separate kernel snap builds done today ... then i can rip out all the breaking code from the ubuntu-core builds | 10:54 |
| ogra_ | oh, bah ... dear LP ... dont show me timeouts on the request-builds page and still run the builds ... grrr ... now i have two builds going in a row | 10:55 |
| zyga | mvo, mwhudson: where do we keep snap-confine packaging for xenial and yakkety? I'm looking for something like a git repo that can be maintained and that is used the next time an upstream release has to be packaged | 10:56 |
| zyga | I asking because I'm working on removal of stale debian/ from snap-confine source tree so that spread tests are ran against the source tree and current state of downstream packaging | 10:57 |
| mwhudson | zyga: i haven't done any ubuntu specific stuff for snap-confine | 10:57 |
| zyga | so that eventually we know if we can release now and if it really works as intended | 10:57 |
| mwhudson | zyga: but, take the branch on alioth, push it to github or launchpad or something? | 10:57 |
| zyga | debian is in the same boat but I want to start with ubuntu because all the tests are passing there | 10:58 |
| zyga | mwhudson: yeah, that makes sense, I'm just asking if there's a branch like that already, I'll wait for mvo to reply | 10:58 |
| mvo | zyga: I just use the packaging from the archive and apply the individual fixes for now | 10:59 |
| * mwhudson zzz | 11:00 | |
| zyga | mvo: ok, would you oopse if I take the packaging form the archive and upload it to launchpad/github | 11:01 |
| zyga | mvo: and so that the next time we do a release that packaging is combined with the upstream tarball to form a release | 11:01 |
| zyga | mvo: my intent is to ensure that *tested* (during usual spread CI) code is released and packaged *as tested* | 11:01 |
| mvo | zyga: sure, thats fine | 11:03 |
| zyga | mvo: great, thanks! | 11:03 |
| zyga | mvo: I will document everything in the upstream tree | 11:04 |
| mvo | zyga: new snap-confine is uploaded to xenail-proposed, thanks for the fix. I also uploaded it to the ppa so I can test it with spread | 11:11 |
| jdstrand | zyga: probably the easiest thing to do there would be a make install to /usr and then diff the resulting profile with what we had before. do the same to /usr/local and see it the correct parts change | 11:11 |
| ogra_ | mvo, so where do we stand with the kernel sideloading fix ? (i got new kernel snaps but yesterday the pi2-kernel was still not sideloadable) | 11:13 |
| mvo | ogra_: do you have r4 for ubuntu-device-flash? | 11:13 |
| mvo | ogra_: sudo snap refresh --devmode ubuntu-device-flash | 11:14 |
| ogra_ | yes, that was the one i had upgrade issues with ... i remved/reinstalled it yesterday to make it work again | 11:14 |
| mvo | ogra_: ok, you got a zimage failure, iirc, could you please run "file" on the kernel.img and initrd.img | 11:15 |
| mvo | ogra_: I wonder if something got corrupted | 11:15 |
| ogra_ | let me try a fresh build ... | 11:16 |
| mvo | ogra_: it might be some corruption issue | 11:19 |
| zyga | mvo: thank you | 11:20 |
| zyga | jdstrand: good idea, I will do that in a second, just writing some documentation | 11:21 |
| ogra_ | ok, fresh build ... | 11:29 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/ | 11:29 |
| ogra_ | unset | 11:29 |
| ogra_ | err | 11:29 |
| pbek | didrocks: 'desktop/qt5' reminder ;) | 11:30 |
| ogra_ | mvo, http://paste.ubuntu.com/23014754/ seems to be all fine | 11:31 |
| zyga | jdstrand: I just checked, the profiles are identical except for the new features that were added (nothing is broken by the branch I linked to) | 11:38 |
| zyga | jdstrand: if you can comment on https://github.com/snapcore/snap-confine/pull/98 that would give me more confidence in merging this | 11:38 |
| mup | PR snap-confine#98: Move apparmor profile for snap-confine to src/ <Created by zyga> <https://github.com/snapcore/snap-confine/pull/98> | 11:38 |
| ogra_ | mvo, and along with the above paste http://paste.ubuntu.com/23015149/ thats the snap.yaml that snapcraft created for it | 11:38 |
| mvo | ogra_: and if you boot that? | 11:39 |
| ogra_ | well, see the "unset" in the first paste ... the snap doesnt even end up on the image ... so i'm pretty sure it cant boot ... but let my try anyway | 11:40 |
| ogra_ | reading pi2-kernel_x1.snap/kernel.img | 11:40 |
| ogra_ | ** Unable to read file pi2-kernel_x1.snap/kernel.img ** | 11:40 |
| ogra_ | reading pi2-kernel_x1.snap/initrd.img | 11:40 |
| ogra_ | ** Unable to read file pi2-kernel_x1.snap/initrd.img ** | 11:40 |
| ogra_ | Bad Linux ARM zImage magic! | 11:40 |
| ogra_ | Scanning mmc 0:1... | 11:40 |
| ogra_ | there you go | 11:40 |
| zyga | mvo: how can I apt-get source from the proposed pocket? | 11:40 |
| ogra_ | zyga, by adding a deb-src line to your sources.list for it | 11:41 |
| ogra_ | (and update ...) | 11:41 |
| mvo | ogra_: uh, its not on the image - hm, what commandline did you use? | 11:41 |
| mvo | ogra_: I will try to reproduce | 11:41 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ sudo /snap/bin/ubuntu-device-flash core 16 --channel edge --gadget pi3 --kernel pi2-kernel_4.4.0-1019_armhf.snap --os ubuntu-core -o test-pi3.img | 11:41 |
| zyga | oh, nice, Ican use deb-src without deb, thanks | 11:41 |
| ogra_ | mvo, the snap i use is at https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2670 | 11:42 |
| zyga | will any apt-pinning get in the way? | 11:42 |
| ogra_ | mvo, this is the equivalent amd64 snap from the same build (with adjusted name/version in snapcraft.yaml) https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2681 which works fine in kvm | 11:43 |
| ogra_ | it is definitely uboot related | 11:43 |
| ogra_ | (or non-amd64 related ... however you want to put it) | 11:43 |
| mvo | ogra_: hm, must be something subtle, I got a booting pi2 yesterday, lets see | 11:44 |
| ogra_ | mvo, from a local kernel snap ? | 11:44 |
| mvo | ogra_: so I assume your system-boot does not have unpacked kernel subdir? | 11:44 |
| mvo | ogra_: yes, local sideloaded kernel | 11:44 |
| ogra_ | nope | 11:44 |
| ogra_ | let me try with a kernel from the store again .... but i tried that yesterday with the same result ... | 11:45 |
| ogra_ | ... just to be sure | 11:45 |
| zyga | timothy: did you get your spread key? | 11:45 |
| mvo | ogra_: no need to try, I strongly suspect a bug somewhere in u-d-f | 11:45 |
| * ogra_ tries to find some lünch | 12:07 | |
| jdstrand | zyga: I plan to | 12:10 |
| mvo | zyga: hm, looks like with snap-confine with the mkdir change the "failed to create user data directory. errmsg: Permission denied" is back on ecryptfs systems :( | 12:15 |
| zyga | mvo: oh, drat | 12:26 |
| zyga | mvo: we don't test that in spread :-( | 12:26 |
| zyga | mvo: encryptfs is the thing where the home directory is encrypted | 12:27 |
| mvo | yes | 12:27 |
| zyga | mvo: or when the whole / is encrypted? | 12:27 |
| zyga | jdstrand: ^^ can you please help us out? | 12:27 |
| mvo | zyga: just home | 12:27 |
| zyga | mvo: I don't have any test environment for that, I can try to install ubuntu in a VM with encrypted home but this will take me a while | 12:27 |
| zyga | mvo: I assumed that during the sprint in leiden, when some people encountered this, the proposed version of snap-confine already fixed this | 12:28 |
| zyga | mvo: do you have the apparmor denial? | 12:28 |
| zyga | who might know about ecryptfs and how to set that up for a single test user? | 12:30 |
| mvo | zyga: http://paste.ubuntu.com/23018211/ | 12:30 |
| mvo | zyga: tyhicks or jdstrand know about ecryptfs, afaik its possible to create it for a new user just for testing | 12:31 |
| zyga | mvo: I want to have a spread test that has this, otherwise it will just break again :/ | 12:32 |
| mvo | ogra_: fwiw, I got the same error 10 today on my system when upgrading from r4 to r5 of u-d-f | 12:42 |
| ogra_ | crap | 12:42 |
| josepht | ogra_: hrm, I'll take a look | 12:42 |
| ogra_ | mvo, seems to only happen for the --edge --devmode combo though | 12:43 |
| ogra_ | (or --beta --devmode) | 12:43 |
| didrocks | josepht: hey, did you see the discussion we had with pbek earlier? | 12:46 |
| didrocks | josepht: seems the transition doesn't work as expected (please scrollback) | 12:47 |
| josepht | didrocks: looking | 12:47 |
| mvo | ogra_: ha! I have a kernel OOPS | 12:47 |
| ogra_ | aha ! | 12:47 |
| ogra_ | apparmor ? | 12:47 |
| ogra_ | or squashfs ? | 12:47 |
| mvo | jdstrand: I got an apparmor oops :/ | 12:47 |
| mvo | ogra_: apparmor | 12:47 |
| josepht | didrocks: I just replied to my PR, we need the plain version of the desktop sub-parts in the snapcraft-desktop-helpers repo. Want me to file another PR? | 12:48 |
| didrocks | josepht: sure, please do! | 12:49 |
| didrocks | josepht: I don't know about the plain version as "gtk2", those never existed | 12:49 |
| didrocks | people are using either desktop/gtk2 or desktop-gtk2, right? | 12:49 |
| didrocks | now, if we look at the API, there is only "desktop" and that's it | 12:49 |
| josepht | didrocks: right, but in the snapcraft.yaml for the origin they are just 'gtk2', etc | 12:49 |
| didrocks | oki, trusting that would work :) | 12:50 |
| mvo | ogra_: can you please try r5 of u-d-f from the store? I suspect it was snapcraft playing tricks with me | 12:51 |
| mvo | ogra_: I will test in a sec too, but the oops killed my machine | 12:51 |
| ogra_ | i know what you mean :) | 12:51 |
| * ogra_ snap removes and snap installs instead | 12:51 | |
| ogra_ | WOAH ! | 12:52 |
| jdstrand | mvo: that's no good. can you file a bug with a reproducer? jj is off today, but he can perhaps look at it tomorrow (or perhaps tyhicks sooner) | 12:52 |
| ogra_ | mvo, jdstrand http://paste.ubuntu.com/23019578/ | 12:53 |
| josepht | didrocks: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/6 | 12:53 |
| mup | PR ubuntu/snapcraft-desktop-helpers#6: Add back the original parts as well so older versions of snapcraft-parser works <Created by josepht> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/6> | 12:53 |
| ogra_ | thins time even after a remove/install run | 12:53 |
| ogra_ | (i got a kernel updated today and havent rebooted yet though) | 12:53 |
| ogra_ | http://paste.ubuntu.com/23019750/ | 12:55 |
| ogra_ | and also a kernel oops | 12:55 |
| jdstrand | mvo: (cc tyhicks) that seems to be the same trace as bug #1579135 | 12:55 |
| mup | Bug #1579135: kernel BUG on snap disconnect from within a snap <apparmor (Ubuntu):Incomplete> <https://launchpad.net/bugs/1579135> | 12:55 |
| josepht | didrocks: I just re-ran the parser and the desktop/xxx parts are back | 12:56 |
| jdstrand | mvo (cc tyhicks): jj (and to some extent I) tried to get a reliable reproducer for that but were unable to | 12:56 |
| josepht | pbek: can you try again after doing another 'snapcraft update' please? | 12:56 |
| mvo | jdstrand: I commted with how it happend to me, I can try to reproduce but will need to reboot first, looks like apparmor_parser is hanging | 12:57 |
| tealeg | hmmm... the desktop remote part seems to have been corrupted somehow | 12:58 |
| ogra_ | mvo, same here ... i tried to install it again but it doesnt move anymore | 12:59 |
| josepht | tealeg: can you try 'snapcraft update' and see if they are fixed now? | 12:59 |
| tealeg | josepht: yes! | 12:59 |
| tealeg | josepht: ha.. I've been fiddling for 20 minutes, and the moment I come here it's fixed ;-) | 12:59 |
| tealeg | josepht: cheers! | 13:00 |
| josepht | tealeg: just good timing, I made a mistake in a PR to get ready for the removal of namespacing | 13:00 |
| ogra_ | hmpf ... and it seems the hanging apparmor_parser made my shutdown go stuck | 13:03 |
| zyga | hanging? | 13:05 |
| ogra_ | yeah | 13:05 |
| ogra_ | see above | 13:05 |
| ogra_ | kernel oops on snap refresh .. after that the parser hangs | 13:06 |
| didrocks | josepht: nice! :) | 13:07 |
| josepht | ogra_: which livecd-rootfs package? | 13:07 |
| morphis | mvo: I still have problems with the latest u-d-f: https://paste.ubuntu.com/23020975/ | 13:12 |
| ogra_ | josepht, ? | 13:12 |
| liuxg | kyrofa, ping | 13:12 |
| ogra_ | josepht, what do you mean | 13:12 |
| kyrofa | liuxg, pong | 13:13 |
| josepht | ogra_: to test the os snap ownership issue; there are three versions of livecd-rootfs. I assume the latest? | 13:13 |
| ogra_ | josepht, ah, it is the one in the snappy image PPA | 13:13 |
| liuxg | kyrofa, in China, a customer is trying to package mysql, tomcat into a snap. I refer to your owncloud example for the mysql part. it is a great example. I want to understand whether your mysql listens to port 3306 or just a socket? | 13:14 |
| josepht | ogra_: here right? https://launchpad.net/~snappy-dev/+archive/ubuntu/image | 13:14 |
| ogra_ | josepht, you can do a local build using lp:ubuntu-core-snap (needs sudo for the snapcraft call since it creates a bunch stacked of chroots) | 13:14 |
| ogra_ | and yes, then locally install that livecd-rootfs package first | 13:14 |
| ogra_ | (just wget and dpkg -i the deb) | 13:15 |
| kyrofa | liuxg, just a socket, certainly | 13:15 |
| jdstrand | ogra_: istr you saying you had an sshfs snap. would you mind sharing it with me? | 13:15 |
| kyrofa | liuxg, but it requires the use of the my.cnf shipped in the snap, too | 13:15 |
| kyrofa | liuxg, skip-networking, specifically | 13:15 |
| ogra_ | jdstrand, sadly i only tried to create one ... i didnt finish it | 13:15 |
| liuxg | kyrofa, if I want to change it to listen to the 127.0.0.1:3306, how can I change it? https://github.com/kyrofa/owncloud-snap | 13:16 |
| jdstrand | ogra_: would you mind sharing what you have? | 13:16 |
| ogra_ | i'll try to find the time before EOW | 13:16 |
| kyrofa | liuxg, are you using that config file? | 13:16 |
| liuxg | kyrofa, the customer is using jsp to develop the webserver. | 13:16 |
| jdstrand | ogra_: I'm looking into the fuse interface and wanted to play with different things | 13:17 |
| liuxg | kyrofa, yeah, I am trying to understand your code, or I just stage-package from the standard ubuntu archive? | 13:17 |
| kyrofa | liuxg, you'll run into issues with using the stage-package: https://kyrofa.com/posts/snapping-nextcloud-mysql | 13:18 |
| kyrofa | liuxg, but yeah, try just removing the skip-networking stanza in the config flag | 13:18 |
| kyrofa | config file rather | 13:18 |
| ogra_ | jdstrand, http://paste.ubuntu.com/23021415/ | 13:18 |
| kyrofa | No coffee yet | 13:18 |
| ogra_ | jdstrand, you want to rip out the zenity bits though ... doesnt work | 13:18 |
| ogra_ | oh, and i dont have the sshfs bits in there anymore (and have no history) | 13:19 |
| liuxg | kyrofa, thanks for sharing the article. do you have any links on how to configure it? | 13:19 |
| ogra_ | essentialyl you want to replace the ssh exec call with an sshfs mount call there | 13:19 |
| jdstrand | ogra_: ack, thanks! | 13:22 |
| liuxg | kyrofa, so removing skip-networking is the only place I need to change, do I need to set the IP address and port number there in the my.cnf file. thanks | 13:22 |
| kyrofa | liuxg, try bind-address=127.0.0.1 | 13:23 |
| * ogra_ sighs and reboots his PC too ... same apparmor_parser hang and oops | 13:23 | |
| kyrofa | liuxg, I think you can also use port=<whatever> | 13:24 |
| liuxg | kyrofa, thanks. other than this, it should be fine. do I need to change anything there in the mysql.server file? | 13:25 |
| ogra_ | and indeed same hard hang on shutdown | 13:25 |
| === hikiko|ln is now known as hikiko | ||
| morphis | ogra_: did the new u-d-f work for you with a local kernel snap? | 13:26 |
| liuxg | kyrofa, I have seen that you are using mysql.sock in the file mysql.server. | 13:26 |
| ogra_ | morphis, well, i could have tested it if the snap refresh call had not killed all my machines | 13:26 |
| morphis | ogra_: oh, did apparmor crash on the kernel side? | 13:27 |
| ogra_ | yes | 13:27 |
| morphis | ogra_: saw the same here | 13:28 |
| kyrofa | liuxg, yeah I used the mysql.server file to put things in the right place | 13:32 |
| jdstrand | huh | 13:33 |
| pbek | josepht: I rebuilt QOwnNotes on https://code.launchpad.net/~pbek/+snap/qownnotes and it worked great! Thanks a lot! | 13:34 |
| josepht | pbek: great! you're welcome | 13:34 |
| josepht | pbek: ... and sorry for the trouble :) | 13:34 |
| jdstrand | mvo, morphis, ogra_: if all of you are seeing the crash, can you give detailed instructions on how you are triggering it in bug #1579135. we weren't able to do it. eg, if using all snaps system include the core, kernel, gadget snaps used to create it (or where to fetch the image), the commands needed to trigger it, etc | 13:35 |
| mup | Bug #1579135: kernel BUG on snap disconnect from within a snap <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1579135> | 13:35 |
| jdstrand | it sounds like all of you have stumbled upon a reliable reproducer | 13:35 |
| ogra_ | yeah, i just need to snap remove/install the u-d-f package on my desktop PC to trigger it | 13:36 |
| liuxg | kyrofa, do I need to change it if I use localhost:3306? I found that you replaced it with your own. I am thinking whether I just use the original one without replacing it. thanks | 13:36 |
| pbek | josepht: that's the beauty of free open source, problems can be found and fixed fast :) | 13:36 |
| Ursinha | hi all, I created a snap that uses the camera interface but after I install it "snap interfaces" doesn't show ":camera" as being used, like other interfaces: http://paste.ubuntu.com/23022501/ | 13:37 |
| Ursinha | am I missing something or this is a bug? | 13:37 |
| mvo | ogra_: did you had a chance to test u-d-f r5? if not I will do it now | 13:37 |
| kyrofa | liuxg, you'll need to figure out some way of making mysql use $SNAP and $SNAP_DATA, then | 13:37 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ ls -l /media/ogra/system-boot/pi2-kernel_x1.snap/ | 13:37 |
| ogra_ | insgesamt 9464 | 13:37 |
| ogra_ | drwxr-xr-x 2 ogra ogra 512 Aug 11 11:54 dtbs | 13:37 |
| ogra_ | -rw-r--r-- 1 ogra ogra 3029303 Aug 11 11:54 initrd.img | 13:37 |
| ogra_ | -rw-r--r-- 1 ogra ogra 6660128 Jul 23 00:35 kernel.img | 13:37 |
| mvo | ogra_: oh, that looks promising | 13:38 |
| ogra_ | mvo, looks very good, havent tried to boot it yet ... gimme a bit i need to re-setup all my serial terminals again (rebooting sucks !!!) | 13:38 |
| kyrofa | liuxg, you _might_ be able to do that all in the config file. But then I'm not sure why I didn't (this was a while ago, now). Maybe I couldn't get environment variables in there | 13:38 |
| morphis | jdstrand: yeah, mvo already put in what I did too | 13:38 |
| liuxg | kyrofa, yeah, right. I saw that in your code. you did change the directory paths there in the file due to security. | 13:39 |
| jdstrand | ok, cool. maybe now that we have something more reliable jj can track down the bug (tyhicks and ratliff, fyi ^) | 13:39 |
| liuxg | kyrofa, do you mean in the my.cnf file? maybe I can have a try. thanks! | 13:40 |
| kyrofa | liuxg, indeed | 13:40 |
| liuxg | kyrofa, it seems that we can do the configuration in the file my.cnf according to the article at http://www.cyberciti.biz/tips/how-do-i-enable-remote-access-to-mysql-database-server.html | 13:40 |
| kyrofa | liuxg, not security just so much as to make it work in the snap period :) | 13:41 |
| ogra_ | [ 97.091705] cloud-init[2602]: Cloud-init v. 0.7.7 running 'init-local' at Thu, 11 Aug 2016 13:40:53 +0000. Up 93.42 seconds. | 13:41 |
| ogra_ | [ OK ] Started Initial cloud-init job (pre-networking). | 13:41 |
| ogra_ | [ **] A start job is running for Run snap...boot setup (1min 21s / no limit) | 13:41 |
| jdstrand | kgunn: couple small things for the mir PR | 13:41 |
| ogra_ | mvo, it boots, but i get the above | 13:41 |
| ogra_ | (network connected etc) | 13:41 |
| mvo | ogra_: aha, interessting | 13:41 |
| ogra_ | now it timed out and slowly moves on mounting the snap units | 13:42 |
| kyrofa | liuxg, unfortunately that doesn't help you: https://serverfault.com/questions/476924/environment-varibales-in-mysql-configuration-file | 13:42 |
| ogra_ | but each of them seems to take ~30sec | 13:42 |
| kyrofa | liuxg, unless you want to hardcode those paths, which I recommend against | 13:42 |
| ogra_ | ubuntu@localhost:~$ snap list | 13:43 |
| ogra_ | Name Version Rev Developer Notes | 13:43 |
| ogra_ | pi2-kernel 4.4.0-1019 x1 - | 13:43 |
| ogra_ | pi3 16.04-0.1 1 canonical - | 13:43 |
| ogra_ | ubuntu-core 16.04.1 182 canonical - | 13:43 |
| ogra_ | ubuntu@localhost:~$ | 13:43 |
| ogra_ | \o/ | 13:43 |
| mvo | cool | 13:43 |
| ogra_ | yeah,., looks fine | 13:43 |
| ogra_ | that was a pi3 btw :) | 13:43 |
| liuxg | kyrofa, ok. I understand you. the variables cannot be used in the my.cnf file. that is the purpose doing it in your mysql.server file, right? | 13:44 |
| kyrofa | liuxg, indeed | 13:44 |
| ogra_ | and i can finally verify my kernels ... and they work | 13:44 |
| liuxg | kyrofa, do I need to change anything if I do not socket to connect to the database. I have not studied your mysql.server file too much yet. | 13:45 |
| kyrofa | If you disable the socket then yeah, you'll probably want to remove the --socket param and related code | 13:46 |
| jdstrand | zyga: fyi, https://github.com/snapcore/snapd/pull/1502 is tagged 'Reviewed' so I think it falls off people's radar, but it has my +1 (see my comment from a moment ago) | 13:46 |
| mup | PR snapd#1502: Add an interface for tpm <Reviewed> <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502> | 13:46 |
| jdstrand | zyga: I might also mention that the team's use of 'Reviewed' is awkward since it then disappears from lists that people look at and people may not see the changes that the requestor makes. perhaps I don't understand the process you guys are using for that | 13:47 |
| ogra_ | sergiusens, kyrofa, so when building a snap with "type: kernel" in my snapcraft.yaml, but nmot using the kernel plugin itself, snapcraft populated snap.-yaml with "kernel: vmlinuz" as a default value ... mvo told me yesterday soon only kernel.img will be allowed for that entry, can we make snapcraft default to that (do you need a bug ?) | 13:48 |
| liuxg | kyrofa, thanks. I will have a try. | 13:48 |
| morphis | mvo: do you saw my paste from above? | 13:49 |
| mvo | ogra_: this entry can go away entirely | 13:49 |
| morphis | mvo: https://paste.ubuntu.com/23020975/ it is | 13:49 |
| ogra_ | mvo, does u-d-f/u-image ignore it (i.e. is it harmless) ? | 13:50 |
| mvo | ogra_: yes | 13:50 |
| mvo | morphis: hm | 13:50 |
| ogra_ | ah, then it is just cosmetics anyway | 13:50 |
| * ogra_ doesnt care about lipstick :P | 13:50 | |
| mvo | morphis: ls -l kernel.img please? maybe a broken symlink? | 13:50 |
| morphis | its a symlink but a valid one | 13:51 |
| mvo | ogra_: yeah, it should still not be there | 13:51 |
| ogra_ | morphis, are you still using my branch ? | 13:51 |
| morphis | ah wait | 13:51 |
| josepht | kyrofa: it seems shutil.copystat doesn't do what I wanted/expected wrt ownership | 13:51 |
| ogra_ | i switched the kernel.img stuff yesterday | 13:51 |
| morphis | ogra_: yes | 13:51 |
| ogra_ | probably re-sync then | 13:51 |
| ogra_ | (save your snapcraft.yaml somewhere, i cahnge that one all the time) | 13:51 |
| kyrofa | josepht, ugh, darn. I saw that bug re-opened, wondered about that | 13:51 |
| ogra_ | so pi2-kernel and pc-kernel are good to go ... only dragonboard missing now ... then i can drop 200 lines (or so) from livecd-rootfs :D | 13:52 |
| ogra_ | lovely day that is :) | 13:53 |
| mup | Bug #1612260 opened: My package is published but not showing up in the store <Snappy:New> <https://launchpad.net/bugs/1612260> | 13:53 |
| jdstrand | mvo: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/21 | 13:53 |
| mup | Bug #1579135: kernel BUG on snap disconnect from within a snap <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1579135> | 13:53 |
| kyrofa | josepht, does it not work at all, or just not the way we expected? | 13:54 |
| josepht | kyrofa: it doesn't preserve owner/group | 13:55 |
| josepht | kyrofa: everything else though | 13:55 |
| kyrofa | josepht, ah, just the mode bits? | 13:55 |
| kyrofa | Basically everything we don't need? | 13:55 |
| kyrofa | josepht, ogra_ that's my mistake, I'm sorry | 13:55 |
| ogra_ | no worries | 13:56 |
| ogra_ | i just rolled back the PPA snapcraft | 13:56 |
| josepht | kyrofa: nah, I should've caught that | 13:56 |
| ogra_ | once the full fix lands i can drop it again | 13:56 |
| kyrofa | josepht, another reason I wish we could figure out a way to have an integration test for this | 13:56 |
| ogra_ | luckily thats super easy to do | 13:56 |
| kyrofa | josepht, even when we do it right, we're wrong! :P | 13:57 |
| mvo | jdstrand: its not so straightforward it seems, but i try some more | 13:58 |
| liuxg | kyrofa, just confirm one thing, the database "owncloud" user is "root", and it has no password, right? thanks | 13:58 |
| kyrofa | liuxg, I'm afraid it's far more complicated ;) . See https://github.com/kyrofa/nextcloud-snap/blob/master/src/mysql/start_mysql | 13:59 |
| mvo | jdstrand: I'm trying it with a different version upgrade now (r3 -> r5) but hit a store issue | 14:02 |
| liuxg | kyrofa, yes, it looks very complicated. it is random. In fact, I use "mysql-client", and I can create tables for owncloud. but it needs to have root proivilege to do it. | 14:04 |
| mup | PR snapd#1668 closed: tests: prevent restore error on test failure <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1668> | 14:05 |
| kyrofa | liuxg, yeah you can do it that way. But yeah, with the way the snap is configured all those files are stored in SNAP_DATA which is only readable by root | 14:05 |
| kyrofa | (with the permissions I set, I mean) | 14:05 |
| liuxg | kyrofa, so, it does not need to have a password in the sense? | 14:06 |
| kyrofa | liuxg, it does actually. That's part of what's generated in start_mysql, and it's saved in a .ini in $SNAP_DATA/mysql | 14:07 |
| kyrofa | liuxg, check out the mysql-client as setup in the snap | 14:07 |
| kyrofa | You'll see it using that file | 14:07 |
| liuxg | kyrofa, yes, it uses the root.ini file. I got it thanks. | 14:08 |
| tyhicks | zyga: did you get an answer about how to set up an encrypted home user? | 14:29 |
| tyhicks | zyga: on a classic system, `adduser --encrypt-home <username>` will work | 14:30 |
| zyga | tyhicks: nope | 14:33 |
| zyga | tyhicks: I popped up a new VM :) | 14:34 |
| zyga | tyhicks: thanks, this will be valuable for spread | 14:34 |
| tyhicks | zyga: it'll be a bit of a pain because you'll have to do an actual login and provide a password before the encrypted home directory will be mounted | 14:37 |
| zyga | tyhicks: that's okay, for now I just want to do a one-off fix | 14:37 |
| tyhicks | ok | 14:38 |
| kgunn | jdstrand: hey so i do want the mir interface to work for actually 3 configs a kiosk/all-snaps, u8-system/all-snaps & u8-system/classic | 14:44 |
| kgunn | knowing that....what would be the best category in implicit | 14:45 |
| kgunn | ? | 14:45 |
| kgunn | other than the name implying it....how do those implicit lists get treated differently by snapd? | 14:45 |
| kgunn | zyga: ^ ? | 14:46 |
| kgunn | @implicitClassic vs just implicit | 14:46 |
| nothal | kgunn: No such command! | 14:46 |
| zyga | kgunn: sorry I don't understand what you mean by that | 14:50 |
| kgunn | zyga: so when adding a slot to the system you also add the interface to the list in | 14:52 |
| kgunn | https://github.com/snapcore/snapd/blob/master/snap/implicit.go#L30 | 14:52 |
| kgunn | one list is implying Classic in the name | 14:52 |
| kgunn | just wondering...do those interfaces get treated differently by snapd? or is it just convention that we're keeping seperate lists? | 14:52 |
| SamYaple | sergiusens: ok. just to be clear, the approach i will take regarding refactor of python modules is a _new_ module called python, combine everything in like the qt module did with qt4 and qt5, then change the python2, python3 modules to super the python module for backawards compat | 15:00 |
| SamYaple | then i guess we deperate python2 and python3? maybe? | 15:01 |
| SamYaple | i guess we dont have to even | 15:01 |
| zyga | jdstrand: hey, can you weigh your opinion on https://bugs.launchpad.net/snap-confine/+bug/1612291 | 15:02 |
| mup | Bug #1612291: cannot create $SNAP_USER_DATA when using ecryptfs and sudo <Snappy Launcher:New> <https://launchpad.net/bugs/1612291> | 15:02 |
| zyga | kgunn: ah, I see, they are treated differently | 15:03 |
| zyga | kgunn: based on release.OnClassic one of the lists is not used | 15:03 |
| zyga | kgunn: classic being anything but an all-snap image | 15:03 |
| tyhicks | zyga: why can't 'owner' be used? are there files being written to those directories that aren't owned by the user? | 15:06 |
| zyga | tyhicks: because of sudo, I presume | 15:06 |
| zyga | tyhicks: I just tested this | 15:06 |
| zyga | tyhicks: the owner check probably checks euid | 15:07 |
| tyhicks | zyga: that change allows snaps to read the encrypted files of any user | 15:07 |
| zyga | tyhicks: with sudo | 15:09 |
| zyga | tyhicks: or with services | 15:09 |
| zyga | tyhicks: do you have any other suggestion? | 15:09 |
| zyga | tyhicks: currently this is a blocker for SRU according to what mvo said | 15:09 |
| tyhicks | zyga: that's the best that can be done in policy | 15:10 |
| tyhicks | jdstrand: have any additional thoughts? | 15:11 |
| zyga | mvo: ^^ | 15:11 |
| mvo | zyga: I wonder if we should bite the bullet and just not do it in snap-confine and land all the other fixes instead to avoid that this is needed | 15:11 |
| mvo | zyga: seems its a can of worms :/ | 15:11 |
| liuxg | kyrofa, I just tried to remove the option "--socket="$SNAP_DATA/mysql/mysql.sock"" in the mysql.server, and the mysqld failed to get started. I found that "root.ini" file has only one field "password=xxxxxx". is there any switch to turn off the "socket" besides that option there in the file? thanks | 15:12 |
| jcastro | what component do I log a bug against for the store/login/auth piece? | 15:12 |
| === matiasb1 is now known as matiasb | ||
| zyga | tyhicks: wait, I disagree, this is just for snap-confine, per-app policy already should allow this to make :home work | 15:12 |
| tyhicks | oh | 15:13 |
| zyga | tyhicks: this is just for snap-confine to setup the data directory, after that we switch the apparmor profile to one that already works OK | 15:13 |
| tyhicks | I missed that this was a change for the snap-confine profile | 15:13 |
| zyga | mvo: ^^ maybe not all is lost :) | 15:13 |
| mvo | zyga: :) | 15:13 |
| mvo | puhh | 15:13 |
| tyhicks | zyga, mvo, jdstrand: since this is for snap-confine's profile, I'm fine with the change | 15:14 |
| morphis | ogra_: ok, its your script creating incorrect symlinks: kernel.img -> vmlinuz-4.4.0-1019-raspi2-* | 15:15 |
| mvo | morphis: ha! I suspected its a broken symlink :) | 15:16 |
| morphis | :-) | 15:17 |
| * mvo feels smug now | 15:17 | |
| zyga | tyhicks: thanks, I'll take that as an approval to make the change | 15:17 |
| tyhicks | that's fine | 15:18 |
| balloons | zyga, remember our bash completion discussion in Leiden? I thought there was a bug report for it, but it seems there isn't. I'd like to file one now, under snapcraft I think, as a request for a bash completion interface. Does that make sense? | 15:18 |
| zyga | balloons: under launchpad.net/snappy plase | 15:19 |
| zyga | please* | 15:19 |
| balloons | zyga, do you think it's something snappy itself has to solve? that too was my initial thought, but then I wondered if framing it as an interace request made more sense | 15:19 |
| jdstrand | zyga, tyhicks: that change is fine for snap-confine imo | 15:20 |
| zyga | balloons: yes | 15:20 |
| balloons | zyga, ack. I'll file requesting support. Thanks! | 15:20 |
| jdstrand | zyga: I noticed that the /usr/src and /var/log changes aren't in xenial-proposed. can the next upload to xenial-proposed include those? | 15:20 |
| jdstrand | zyga: not sure if you saw, I acked the .in PR just now | 15:21 |
| zyga | balloons: I'm not sure, mvo is handling SRU in a custom way to make things effectively land; I'm working on upstream changes and on making testing reliable now | 15:26 |
| zyga | balloons: that change will be in 1.0.40 upstram | 15:26 |
| zyga | upstream | 15:26 |
| zyga | jdstrand: thanks! | 15:26 |
| mup | Bug #1612303 opened: Snaps don't support bash autocompletion <Snappy:New> <https://launchpad.net/bugs/1612303> | 15:27 |
| balloons | zyga, are you saying the autocompletion is coming? | 15:27 |
| jdstrand | balloons (and zyga): that is a dupe of bug #1590767 | 15:29 |
| mup | Bug #1590767: Support snap installed completion scripts <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1590767> | 15:29 |
| balloons | jdstrand, bah I was looking and looking for the dupe bug. I swore I'd seen it | 15:29 |
| mup | Bug #1612303 changed: Snaps don't support bash autocompletion <Snappy:New> <https://launchpad.net/bugs/1612303> | 15:30 |
| zyga | balloons: no :) | 15:34 |
| zyga | balloons: It's probabyl very hard or impossible for untrusted snaps | 15:34 |
| zyga | balloons: and even if the actual runtime may require changes to existing completion support | 15:34 |
| zyga | balloons: but you asked :) | 15:34 |
| jdstrand | zyga: I actually outlined a way to pull it off in the bug | 15:36 |
| zyga | jdstrand: oh, interesting, I'll read that with interest then | 15:36 |
| kgunn | jdstrand: so based on what zyga's answer was, i think mir actually is an implicitslot (not classic) | 15:39 |
| zyga | kgunn: is't mir a slot on the mir snap? | 15:40 |
| zyga | kgunn: or on the core snap on classic when mir is a package | 15:40 |
| zyga | mvo: can you please comment on https://github.com/snapcore/snap-confine/pull/97 so that I can land it | 15:41 |
| mup | PR snap-confine#97: Restore creation of $SNAP_USER_DATA <Created by zyga> <https://github.com/snapcore/snap-confine/pull/97> | 15:41 |
| ogra_ | morphis, did you update to the latest ? | 15:41 |
| ogra_ | morphis, i fixed that yesterday morning | 15:41 |
| tgm4883 | What's the process for getting something added as an interface? I don't see an interface that would give access to what I need | 15:43 |
| tgm4883 | Looking at http://snapcraft.io/docs/reference/interfaces | 15:43 |
| zyga | tgm4883: file a bug, work on a patch, discuss this, read http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html | 15:44 |
| liuxg | skip-networking | 15:44 |
| tgm4883 | zyga: ah cool, thanks | 15:44 |
| kgunn | zyga: so it's actually kind of all of the above.... mir is a snap on core, mir is a package on u8-classic, mir will be part of some-os-snap for u8-personal | 15:47 |
| zyga | kgunn: so the interface is the same in both cases, just the decision if classic should get the mir slot should be dynamic, based on availability of mir as a classic package | 15:48 |
| zyga | kgunn: i'd start simple | 15:48 |
| zyga | kgunn: make mir a snap, ignore the classic package | 15:48 |
| kgunn | zyga: in which case, it should be an implicitslot right? | 15:48 |
| kgunn | also fwiw, mir is in main, so technically all classic ubuntu will have it | 15:49 |
| jdstrand | kgunn: you're goal is to have it be implicit on classic aiui. that's fine but it won't work as is since on unity8 classic mir will be unconfined and installed via debs. like I said, that can be fixed in a future. I suggest moving to implicitClassic then. that way the slot doesn't show up on all-snap systems unless the snap is installed and shows up on classic | 15:49 |
| jdstrand | kgunn: or if you are keeping it simple now, just remove it from implicit altogether | 15:50 |
| kgunn | jdstrand: but what about u8-personal? | 15:51 |
| jdstrand | kgunn: you said that is an all snaps system | 15:51 |
| kgunn | yes, all snaps | 15:51 |
| jdstrand | kgunn: which means either it is installed as a snap | 15:51 |
| jdstrand | kgunn: or there is a different 'core' image that has it preinstalled | 15:51 |
| kgunn | yes | 15:51 |
| jdstrand | kgunn: since that different core image doesn't exist today, don't pretend it does | 15:52 |
| jdstrand | kgunn: therefore, leave out of implicit | 15:52 |
| kgunn | ok | 15:52 |
| jdstrand | when the landscape changes, we can adjust that | 15:52 |
| kgunn | alright, was just trying to plan ahead | 15:52 |
| jdstrand | it sounds like we may need some detection logic on whether or not it is implicit. again, future stuff | 15:52 |
| kgunn | jdstrand: or would there be yet-another implicit list? | 15:53 |
| jdstrand | maybe | 15:53 |
| kgunn | like is implicit really just ubuntu-core? | 15:53 |
| kgunn | implicit today that is | 15:53 |
| jdstrand | well, afaik no one has blessed an alternative core for personal as a thing | 15:53 |
| jdstrand | so it's not all thought through | 15:54 |
| jdstrand | it could easily be implicitPersonal or something | 15:54 |
| kgunn | jdstrand: oh i see, so you could say....it just shows up as part of some-other-snap-on-top-of-core | 15:54 |
| jdstrand | or there could be detection | 15:54 |
| kgunn | right, that's what i was thinking implicitPersonal | 15:54 |
| jdstrand | kgunn: it depends on how personal is put together. is it core as it exists today plus a bunch of snaps or is it a fat alternative core | 15:55 |
| kgunn | jdstrand: one last thing, you are right that today mir is on classic...in which case, i should move it back to classic | 15:55 |
| kgunn | jdstrand: per the Heidelberg sprint I believe everyone wants core-as-today + another-snap-with-u8-on-top | 15:56 |
| kgunn | niemeyer: ^ right ? | 15:56 |
| jdstrand | afaik that question has never been answered. people have expressed opinions, but until we know the answer it is hard to implement for it. but this is minor/easy stuff to implement. I like zyga's advice of sticking with just as a snap for now and we adjust later | 15:56 |
| zyga | ++ | 15:57 |
| ogra_ | geez ... using apt (instead of apt-get) on a serial console ends in a large mess of chars on my screen | 15:57 |
| jdstrand | kgunn: well, mir on classic... eh, it is possible there, but it isn't by default | 15:57 |
| jdstrand | kgunn: ie, debs have to be installed and you have to be running the unity8 session | 15:57 |
| jdstrand | kgunn: so it really shouldn't simply be offered on classic I don't think, cause most classic systems today don't actually have it (hence the detection idea) | 15:58 |
| kgunn | jdstrand: no...that's not right, mir is there, you don't have to be logged in | 15:59 |
| kgunn | mir can run on X too in u7 | 15:59 |
| kgunn | it's a tinker-toy....it can do a lot of differnt things | 15:59 |
| kgunn | *logged into u8 | 15:59 |
| jdstrand | I'd really prefer to land this PR as is and work through the classic user cases in a separate PR | 16:00 |
| kgunn | jdstrand: ok, no prob...so i remove from implicit altogether for the moment | 16:00 |
| jdstrand | kgunn: I think that is best. once landed if in another PR you want to update the manual testing instructions for all the user stories on classic then we can advise on how to implement the policy changes | 16:01 |
| kgunn | k | 16:02 |
| joc_ | zyga: interface question - should i be able to test the number of attrs on plug with len(plug.Attrs) in my SanitizePlug function? | 16:02 |
| jdstrand | kgunn: based on your comment of core snap + u8 snap, it sounds like what would be committed today would work there. mir is either an installed snap or it is bundled in u8 and u8 slots: [mir] | 16:03 |
| jdstrand | kgunn: so all good | 16:03 |
| kgunn | yep | 16:03 |
| * jdstrand suspects the nicest dev experience would be mir bundled in u8, so then clients could simply plugs: [unity8] | 16:04 | |
| jdstrand | anyhoo | 16:04 |
| jdstrand | that's for another day :) | 16:04 |
| zyga | joc_: yes but you have to remember about the type | 16:04 |
| zyga | joc_: interface{} has no len() | 16:04 |
| zyga | joc_: you have to type-assert | 16:04 |
| zyga | joc_: (that can fail) | 16:04 |
| zyga | joc_: then you can check the length | 16:04 |
| ogra_ | mvo, just FYI, all kernel snaps built from my new branchs work fine and sideload fine, tested on all boards and kvm (tomorrow morning i'll rip out everything unneeded from livecd-rootfs) | 16:05 |
| * jdstrand is really not terribly excited that we aren't chdir()ing to some snap-specific dir | 16:06 | |
| zyga | jdstrand: hmm, that would break git/bzr/hg as a snap | 16:06 |
| jdstrand | I realize that none of the options are perfect, but not doing it results in weird behavior | 16:06 |
| jdstrand | zyga: well, every snap I do ends up in a dir that isn't accessible | 16:06 |
| jdstrand | *every* | 16:07 |
| joc_ | zyga: something like len(plug.Attrs.(string)) ? | 16:07 |
| jdstrand | why can't the git/bzr/hg snap developers do a chdir($OLDHOME) or something? | 16:07 |
| zyga | joc_: no, because type assertion should be handled by an assignment to a pair | 16:07 |
| zyga | joc_: look at how we extract stuff out of attrs in bool-file or serial-port | 16:08 |
| jdstrand | the "don't do a chdir()" only makes any sense at all if you plugs home | 16:08 |
| jdstrand | the home interface sucks | 16:08 |
| zyga | anway, I have to go AFK now, sorry | 16:08 |
| jdstrand | we shouldn't be pushing people towards using it | 16:08 |
| zyga | jdstrand: I think we will have more interfaces later and doing this chdir would just break the world, plus there's devmode and we want people to feel at home with snaps | 16:08 |
| jdstrand | zyga: how is: $ ls | 16:09 |
| jdstrand | ls: cannot open directory '.': Permission denied | 16:09 |
| jdstrand | feeling at home? | 16:09 |
| jdstrand | you are forcing anyone who doesn't use 'home' to do the chdir | 16:09 |
| zyga | jdstrand: more than ls / | 16:09 |
| joc_ | zyga: i understand how to get a particular attribute but just knowing how many there are of any type i'm not sure | 16:09 |
| zyga | jdstrand: or /home/foo/stuff $ ls | 16:09 |
| zyga | jdstrand: that prints stuff that's in another directory | 16:10 |
| jdstrand | zyga: my point is if I don't plugs home I'm in a dir I can't do anything with. that is poor | 16:10 |
| ogra_ | [ 9037.726155] audit: printk limit exceeded | 16:10 |
| ogra_ | oh, lovely | 16:10 |
| jdstrand | so devs will be conditioned to plugs: home | 16:10 |
| * zyga needs to run now | 16:10 | |
| zyga | sorry joc jdstrand, let's talk later | 16:10 |
| jdstrand | which is really bad security-wise | 16:10 |
| jdstrand | that's fine. I'm mostly ranting | 16:10 |
| jdstrand | though I would prefer to see this handled better | 16:11 |
| jdstrand | ogra_: sudo sysctl -w kernel.printk_ratelimit=0 | 16:11 |
| ogra_ | i think we really need to turn off the "ALLOWED" spam on all-snap images ... since you can only use the classic shell in devmode that makes the logs go crazy | 16:11 |
| ogra_ | jdstrand, ah, that should perhaps become a default firstboot setting on all-snaps | 16:12 |
| ogra_ | unless there are plans to quieten apparmor in --devmode | 16:12 |
| ogra_ | oh | 16:13 |
| ogra_ | now that one is actually more interesting | 16:13 |
| ogra_ | (classic)ubuntu@localhost:~/kernel-test-snap$ sudo cat snapcraft.yaml | 16:13 |
| ogra_ | cat: standard output: Permission denied | 16:13 |
| ogra_ | heh | 16:13 |
| jdstrand | the whole point of --devmode is to log what is against policy | 16:13 |
| jdstrand | --devmode with no logging is just unconfined | 16:13 |
| ogra_ | well, then we probably need an additional "mode" | 16:14 |
| jdstrand | ogra_: why is it noisy? | 16:14 |
| ogra_ | like --unconfined ;) | 16:14 |
| jdstrand | we should fix the noisy accesses | 16:14 |
| * jdstrand notes that it shouldn't log something that is allowed by the policy, only something that is not allowed by the policy | 16:14 | |
| ogra_ | jdstrand, well, i'm building packages inside a classic chroot ... and the classic snap uses the chroot command ... so nearly every action i do causes a line | 16:15 |
| ogra_ | though i'm more curious why i dont have access to stdout in the dragonboard classic shell | 16:16 |
| ogra_ | (classic)ubuntu@localhost:~/kernel-test-snap$ ls -l /dev/std* | 16:17 |
| ogra_ | lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stderr -> /proc/self/fd/2 | 16:17 |
| ogra_ | lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stdin -> /proc/self/fd/0 | 16:17 |
| ogra_ | lrwxrwxrwx 1 root root 15 Jan 1 1970 /dev/stdout -> /proc/self/fd/1 | 16:17 |
| ogra_ | hmm, interesting date | 16:17 |
| ogra_ | (classic)ubuntu@localhost:~/kernel-test-snap$ ls /proc/self/fd/0 | 16:17 |
| ogra_ | ls: cannot access '/proc/self/fd/0': Permission denied | 16:17 |
| jdstrand | ogra_: classic chroot on all snaps hasn't been a focus yet for devmode. I suggest talking to tyhicks about the issues you are seeing. but it does seem that the classic snap is a very special case | 16:17 |
| ogra_ | it definitely is | 16:18 |
| jdstrand | (tyhicks is working on various logging things related to devmode) | 16:18 |
| ogra_ | we should perhaps just makes it as special package with special apparmor profile | 16:18 |
| jdstrand | classic chroot isn't really --devmode | 16:18 |
| ogra_ | it isnt urgent, i'm just playing around with the new images to see what works and what doesnt | 16:18 |
| jdstrand | ogra_: that is what I was thinking | 16:18 |
| ogra_ | well, it moved into a snap | 16:19 |
| jdstrand | sure | 16:19 |
| jdstrand | and devmode was there so people used it | 16:19 |
| ogra_ | which we havent done before | 16:19 |
| jdstrand | but that isn't disigned | 16:19 |
| ogra_ | yeah | 16:19 |
| jdstrand | designed | 16:19 |
| * ogra_ scratches head | 16:20 | |
| ogra_ | (classic)ubuntu@localhost:~$ cat kernel-test-snap/snapcraft.yaml | 16:20 |
| ogra_ | cat: standard output: Permission denied | 16:20 |
| ogra_ | (classic)ubuntu@localhost:~$ cat kernel-test-snap/snapcraft.yaml |head -1 | 16:20 |
| ogra_ | name: canonical-snapdragon-linux | 16:20 |
| ogra_ | so if the output goes through a pipe first i can write to stdout ... how weird is that | 16:21 |
| ogra_ | (this only happens on dragonboard) | 16:21 |
| jdstrand | I bet it has to do with a bug I saw | 16:22 |
| * jdstrand goes to find it | 16:22 | |
| jdstrand | ogra_: could it be bug #1611493 | 16:23 |
| mup | Bug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493> | 16:23 |
| ogra_ | ah ! | 16:23 |
| ogra_ | yeah, that could be it | 16:24 |
| * ogra_ lets the boards build their test kernels and goes afk for a bit | 16:25 | |
| jdstrand | kgunn: sigh, github removed a '*' in my suggestion :\ | 16:31 |
| jdstrand | kgunn: https://github.com/snapcore/snapd/pull/1299/files#r74456003 | 16:31 |
| mup | PR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299> | 16:31 |
| jdstrand | kgunn: apologies | 16:31 |
| kgunn | jdstrand: weird i tested it manually and it worked! | 16:32 |
| jdstrand | kgunn: it would work for /dev/tty0-9 but tty10 it would not | 16:32 |
| jdstrand | kgunn: this is future proofing | 16:32 |
| kgunn | k | 16:32 |
| kgunn | i didn't think that looked right, i should've asked | 16:34 |
| mvo | ogra_: cool, are they auto-uploaded yet ? | 16:37 |
| mvo | ogra_: I see that core is now auto-accepted and auto-published, neat | 16:39 |
| mvo | ogra_: is that all the chagnes in the review scripts? | 16:39 |
| ogra_ | mvo, kernels arent auto-uploaded yet i'lll get that going tomorrow | 16:49 |
| ogra_ | core is though ... | 16:50 |
| ogra_ | mvo, i cant tell what the review scripts will say about the LP build kernels yet | 16:51 |
| ogra_ | (but given that it takes weeks between kernel changes i'll happily go on doing them manually til everything is sorted ... core was more important due to daily builds | 16:52 |
| ogra_ | ) | 16:52 |
| mup | PR snapd#1548 closed: many: add new `snap prepare-image` command for ubuntu-image <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1548> | 17:06 |
| mup | PR snapd#1664 closed: integration-tests: add update-rollback stress tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1664> | 17:06 |
| powersj | Does the ant plugin allow parameters today so I can specify `ant exejar`? | 17:32 |
| mup | PR snapcraft#721 opened: Set owner/group for directories in stage and prime <Created by josepht> <https://github.com/snapcore/snapcraft/pull/721> | 17:33 |
| josepht | powersj: it doesn't look like it from scanning the plugin source | 17:36 |
| powersj | josepht, is this what you were looking at: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/ant.py | 17:37 |
| josepht | powersj: yes | 17:37 |
| powersj | josepht, thanks | 17:37 |
| josepht | powersj: if it's something you need please file a bug so we don't forget about it. :) | 17:38 |
| mup | PR snapd#1669 opened: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669> | 17:42 |
| powersj | josepht, will do shortly, thanks! was trying to snap up weka | 17:44 |
| mup | PR snapcraft#722 opened: Set owner/group for directories in stage and prime <Created by josepht> <https://github.com/snapcore/snapcraft/pull/722> | 17:48 |
| mup | PR snapcraft#722 closed: Set owner/group for directories in stage and prime <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/722> | 17:51 |
| mup | PR snapd#1670 opened: osutil: do not error if the SUDO_USER can not be looked up <Created by mvo5> <https://github.com/snapcore/snapd/pull/1670> | 17:56 |
| mup | PR snapcraft#721 closed: Set owner/group for directories in stage and prime <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/721> | 17:57 |
| mup | PR snapcraft#723 opened: Set owner/group for directories in stage and prime <Created by josepht> <https://github.com/snapcore/snapcraft/pull/723> | 17:57 |
| mhall119 | zyga: kyrofa: where do we have good documentation on the snap store API for publishing snaps? | 18:06 |
| kyrofa | mhall119, like the API used by snapcraft to upload snaps to the store and release to channels? | 18:11 |
| mhall119 | yeah | 18:12 |
| mhall119 | http://snapcraft.io/docs/reference/snapcraft lists "upload" still, but not "push" | 18:12 |
| niemeyer | kgunn, jdstrand: Yes, I've been hoping since we first talked about this that we'd have a single core snap | 18:36 |
| niemeyer | In the last sprint, there were indications that this will indeed be the direction we'll move towards | 18:36 |
| niemeyer | As in, not have a personal-ubuntu-core | 18:37 |
| niemeyer | But just the one and true | 18:37 |
| kyrofa | mhall119, this is the only one I know about: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex | 18:38 |
| kgunn | jdstrand: so now that tests have passed...do i need to do anything? or will it eventually just get merged | 18:56 |
| arges | sergiusens: hey. during the build phase of snapcraft, where does the snapcraft.yaml file go? | 18:58 |
| arges | I have some code that parses version strings like so: VERSION=$(shell git describe --tags 2>/dev/null || grep ^version snapcraft.yaml | cut -f 2 -d ' ') | 18:59 |
| mup | PR snapd#1670 closed: osutil: do not error if the SUDO_USER can not be looked up <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1670> | 18:59 |
| kyrofa | arges, nowhere-- snapcraft generates the snap.yaml, and only reads the snapcraft.yaml to do that | 18:59 |
| arges | kyrofa: could I read the snap.yaml during the build phase? Mostly a trick for me to parse a version string | 19:00 |
| kyrofa | arges, no. The snap.yaml isn't actually generated until prime | 19:00 |
| kyrofa | arges, also, during the build phase each part is built in what is intended to be an internal directory whose path could change, so we don't recommend hard-coding relative paths to get back to the snapcraft.yaml either | 19:01 |
| arges | kyrofa: ok. i'll adjust looks like the .git directory is in the build | 19:01 |
| arges | so I could parse things there | 19:02 |
| kyrofa | arges, indeed, that could work | 19:02 |
| arges | kyrofa: thanks | 19:02 |
| jdstrand | kgunn: nothing you or I need to do. zyga or someone else will merge it | 19:22 |
| jdstrand | kgunn: thanks for all the hard work on it! :) | 19:23 |
| kgunn | cool, and thanks jdstrand for all the help and pateince...i learned a ton | 19:23 |
| mhall119 | kyrofa: it's for krita, who already use snapcraft, so I'll stick with it's interface | 19:23 |
| jdstrand | glad to hear :) you're welcome | 19:23 |
| arges | hi is there a good snapcraft example of handling sockets exposed in /var/run ? | 19:50 |
| arges | i take it i'll have to move my socket from /var/run? | 19:52 |
| kyrofa | arges, I put mine in $SNAP_DATA | 19:58 |
| arges | kyrofa: yea that seems reasonable | 19:58 |
| kyrofa | arges, if /var/run is writable (not sure), it's probably /var/run/snap.<snapname>/ or something similar | 19:58 |
| arges | i didn't see the later grepping through the source. but I could be missing something | 20:00 |
| jdstrand | ogra_: fyi, this isn't really more than what you had, but in the interest of sharing: lp:~jdstrand/+junk/snap-sshfs.jdstrand | 20:01 |
| powersj | Is there a command to see all available parts? or is the wiki the primary list? | 20:58 |
| === icey is now known as icey|vacation | ||
| popey | powersj: snapcraft search | 21:23 |
| powersj | popey, oh it finds parts as well? | 21:23 |
| popey | thats only what snapcraft search does | 21:24 |
| powersj | ah, I was getting snap find and snapcraft search crossed in my head. | 21:37 |
| blackboxsw | hmm, I'm getting ascii encode errors when I attempt to add after: [desktop/gtk2] to my snap. it hangs on the slash any tips? | 21:51 |
| blackboxsw | 'ascii' codec can't encode character '\u29f8' in position 38: ordinal not in range(128) | 21:51 |
| blackboxsw | tried copying directly from snappy-playpen as other examples just worked and seem to have the same content | 21:52 |
| mup | Bug #1612440 opened: Full systemd socket activation support <lxd> <Snappy:New> <https://launchpad.net/bugs/1612440> | 22:05 |
| mup | Bug #1612441 opened: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441> | 22:11 |
| mup | Bug #1612441 changed: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441> | 22:39 |
| mup | Bug #1612453 opened: `snap connect` requires me to type ubuntu-core <Snappy:New> <https://launchpad.net/bugs/1612453> | 23:03 |
| mup | PR snapcraft#724 opened: In travis, install the static checkers with pip <Created by elopio> <https://github.com/snapcore/snapcraft/pull/724> | 23:15 |
| mup | Bug #1612459 opened: SM should by default point valid kickstart file if nothing is given <Snappy:New for sgurumurthy> <https://launchpad.net/bugs/1612459> | 23:18 |
| mup | Bug #1612459 changed: SM should by default point valid kickstart file if nothing is given <Juniper Openstack:New for nitishk> <https://launchpad.net/bugs/1612459> | 23:21 |
| === evnmar_ is now known as evnmar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!