| miken | bitpushr: Hi there. I was just investigating a question you had earlier about ssh access. | 00:25 |
|---|---|---|
| miken | bitpushr: afaict, once the first-boot script completes successfully, it's not possible to re-trigger the ssh import. | 00:25 |
| miken | bitpushr: Re-flashing so you can re-run the first-boot process is the only option I'm aware of, sorry :/ ( mwhudson may know more, but he's on leave atm). | 00:26 |
| mup | Bug #1572038 opened: snap find doesn't find partial names <Snappy:New> <https://launchpad.net/bugs/1572038> | 00:39 |
| mup | Bug #1606539 opened: handler errors from `snap create-user` gracefully <Snappy:New> <https://launchpad.net/bugs/1606539> | 00:39 |
| mup | Bug #1572038 changed: snap find doesn't find partial names <Snappy:Fix Released> <https://launchpad.net/bugs/1572038> | 00:42 |
| mup | Bug #1593989 opened: snap installed .desktops collide with .deb installed .desktops in unity7 <Snappy:New> <https://launchpad.net/bugs/1593989> | 00:42 |
| lutostag | hey all, ran into an issue installing lxd on core-16. I can't create the lxd group that it needs | 00:48 |
| lutostag | any way to do that? | 00:48 |
| mup | PR snapcraft#941 opened: Support symlinks within deb sources <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/941> | 00:51 |
| mup | PR snapcraft#930 closed: parser: support remote dependencies <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/930> | 01:51 |
| mup | PR snapcraft#932 closed: cli: implement `enable-ci travis --refresh` command <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/932> | 02:06 |
| mup | PR snapcraft#939 closed: Replace coveralls with codecov <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/939> | 02:15 |
| mup | PR snapcraft#942 opened: store: return specific error when already owned <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/942> | 03:03 |
| mup | PR snapd#2397 opened: interfaces: add iio <Created by lpotter> <https://github.com/snapcore/snapd/pull/2397> | 03:54 |
| foxmask | bonjello | 07:05 |
| dholbach | hey hey | 07:37 |
| seb128 | hey dholbach! | 07:39 |
| dholbach | hey seb128 | 07:39 |
| seb128 | dholbach, happy friday! | 07:39 |
| dholbach | and the same to you :) | 07:40 |
| didrocks | happy Friday dholbach :) | 07:40 |
| dholbach | hey guys :) | 07:40 |
| zyga | tvoss: hey | 08:03 |
| zyga | tvoss: just finishing something on the arg parsing side and then going back to feedback from reviews | 08:03 |
| tvoss | zyga: good morning :) sounds good to me | 08:03 |
| jibel | fgimenez, morning, did you look into the autopkgtest failure of snapd on zesty/ppc64el? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd | 08:08 |
| fgimenez | hi jibel, nope, i think that mvo has been tackling it | 08:10 |
| jibel | fgimenez, and is he looking into the failures in xenial too? | 08:12 |
| jibel | fgimenez, we'd need 2.18 in proposed if there is a release of 2.19 next week | 08:13 |
| fgimenez | jibel, not sure but i think so, he can confirm | 08:13 |
| mup | PR snapcraft#943 opened: Replace subTests with TestScenarios <Created by elopio> <https://github.com/snapcore/snapcraft/pull/943> | 08:39 |
| gerry_ | hello, My app is in gnome software but today I log on there and there are two versions of my app on there is it something I have done wrong? | 09:33 |
| zyga | gerry_: can you look at /var/lib/snapd/desktop/applications/ | 09:34 |
| zyga | gerry_: are there multiple desktop files for your app there? | 09:34 |
| gerry_ | zyga: no just one but it has the icon of the one that appeared in gnome-software today | 09:37 |
| zyga | gerry_: I suspect that what you see then is a glitch in the gnome-software then | 09:38 |
| zyga | gerry_: can you report that and attach some screenshots perhaps | 09:38 |
| zyga | gerry_: maybe you see your app in the store and your app locally installed | 09:38 |
| zyga | gerry_: and those are separate for some reason (no idea really, not my area of expertise) | 09:38 |
| zyga | morphis__: hey | 09:39 |
| zyga | morphis__: how's projects? | 09:39 |
| * zyga fixed some tests and runs spread to verify | 09:39 | |
| zyga | gerry_: for gnome-software you want to find robert ancel AFAIK | 09:40 |
| morphis__ | zyga: hey! | 09:42 |
| morphis__ | zyga: you mean any specific ones :-) | 09:42 |
| gerry_ | zyga: ok thank you very much for your help | 09:42 |
| zyga | morphis__: in general, are things going OK? | 09:43 |
| zyga | gerry_: his IRC nickname is robert_ancell | 09:43 |
| zyga | (double l, sorry for getting that wrong earlier) | 09:44 |
| zyga | gerry_: you may have better luck finding him earlier though as he is from new zeland | 09:44 |
| morphis__ | zyga: yeah, so far everything is fine :-) | 09:45 |
| morphis__ | zyga: you got the problem with the content itnerface fixed already? | 09:45 |
| zyga | morphis__: do you mean the multiple entries or something else? | 09:46 |
| zyga | morphis__: the content interface is not broken AFAIK but needs new features to support some interesting use cases | 09:46 |
| zyga | morphis__: that bug you spoke about at a call a while ago is fixed | 09:47 |
| zyga | morphis__: (and the other one as well, I updated LP bugs) | 09:47 |
| gerry_ | zyga: just one thing the one that has appeared today has "*3rd party" on it where as the my entry does not have that? | 09:47 |
| morphis__ | zyga: ah good, yeah especially the use case to share a local socket was of interest for us | 09:48 |
| morphis__ | zyga: which snapd/snap-confine do we need to get that working? | 09:48 |
| zyga | gerry_: that's a gnome-software tag, I would recommend that you file bugs on snappy / gnome-software for each of those that feels wrong to you; some are missing features, some are OK but need to be explained (bugs can be converted to questions that can show up in a FAQ on launchpad) | 09:48 |
| zyga | morphis__: that should work, I didn't try it myself but the code looks fine | 09:49 |
| zyga | morphis__: I think .44 | 09:49 |
| zyga | morphis__: maybe earlier but I'd have to check tags | 09:49 |
| morphis__ | zyga: ok, so nothing which is in stable yet, right? | 09:50 |
| zyga | morphis__: actually | 09:50 |
| zyga | morphis__: it's a snapd fix and it might be out now | 09:51 |
| * zyga looks | 09:51 | |
| zyga | because that side was in snapd | 09:51 |
| zyga | morphis__: can you just try, use $SNAP_DATA as described there: https://github.com/snapcore/snapd/wiki/Content-Interface | 09:53 |
| morphis__ | zyga: ah ok, let me try that then | 09:53 |
| zyga | morphis__: and feel free to edit that wiki | 09:57 |
| zyga | morphis__: really, it is very useful if you do | 09:58 |
| morphis__ | zyga: oh I see, I can do that | 09:58 |
| morphis__ | zyga: can everyone? | 09:58 |
| zyga | morphis__: yes | 10:00 |
| zyga | :) | 10:00 |
| zyga | it's a wiki! | 10:00 |
| morphis__ | good :-) | 10:00 |
| zyga | morphis__: I should link it to the interfaces page | 10:00 |
| zyga | morphis__: I'll do that shortly | 10:00 |
| morphis__ | ok | 10:00 |
| morphis__ | zyga: btw. you saw my replies on https://bugs.launchpad.net/snappy/+bug/1646415 ? | 10:00 |
| mup | Bug #1646415: cannot run configure hook <Snappy:Invalid> <https://launchpad.net/bugs/1646415> | 10:00 |
| * zyga looks | 10:02 | |
| zyga | no, not yet | 10:02 |
| zyga | hmm, odd | 10:02 |
| zyga | I looked at the code and we parse hooks in meta/snap.yaml | 10:02 |
| zyga | I bet you really need that hook to be defined there | 10:02 |
| zyga | maybe something is out of sync | 10:02 |
| zyga | I'll check with gustavo | 10:03 |
| zyga | or maybe | 10:03 |
| zyga | pstolowski: ^^ do you know?] | 10:03 |
| zyga | the person who is on the hook about hooks :) | 10:03 |
| pstolowski | :) | 10:04 |
| pstolowski | looking | 10:04 |
| seb128 | hum | 10:07 |
| seb128 | are launchpad snap builds on yakkety know to be buggy? | 10:07 |
| seb128 | "W:GPG error: http://ppa.launchpad.net/snappy-dev/tools/ubuntu yakkety InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F1831DDAFC42E99D, E:The repository 'http://ppa.launchpad.net/snappy-dev/tools/ubuntu yakkety InRelease' is not signed." | 10:07 |
| seb128 | cjwatson, ^ you might know? | 10:08 |
| ogra_ | seb128, at the start of the build ? thats normal iirc | 10:08 |
| ogra_ | (the build finishes properly, right ? ) | 10:09 |
| seb128 | ogra_, no, the build errors out on that after trying to install the build-packages | 10:09 |
| seb128 | https://launchpadlibrarian.net/295822697/buildlog_snap_ubuntu_yakkety_amd64_ghex-udt_BUILDING.txt.gz | 10:09 |
| seb128 | ogra_, ^ | 10:09 |
| ogra_ | well, if you look at the top of the log you see the exact same which passes | 10:11 |
| seb128 | that same branch was building fine on xenial | 10:11 |
| pstolowski | morphis, zyga the hook-example looks good. having meta/hooks/configure is enough. we have similar spread tests | 10:11 |
| seb128 | I just tried to change to yakkety and now got that | 10:11 |
| seb128 | ogra_, do you know if I'm doing something wrong there and what? | 10:12 |
| ogra_ | i guess because not all packages are in the PPA for yakkety | 10:12 |
| seb128 | but I'm not building using a ppa | 10:12 |
| seb128 | I selected to build from the archive | 10:12 |
| seb128 | so I guess it's a launchpad setup issue? | 10:12 |
| ogra_ | yeah, i wonder what it tries to pull from there | 10:14 |
| pstolowski | morphis, zyga I can look at this later today | 10:24 |
| zyga | pstolowski: thank you, if you are right then snap.Info may lie sometimes :/ | 10:26 |
| pstolowski | zyga, i think we would see these spread tests fail. so not sure what's wrong | 10:27 |
| zyga | pstolowski: spread test may not fail even if what I said is true | 10:36 |
| pstolowski | zyga, hmm why not? | 10:38 |
| mup | PR snapcraft#942 closed: store: return specific error when already owned <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/942> | 10:39 |
| zyga | pstolowski: if the hook manager is not using hook info from snap info, for example | 10:40 |
| Trevinho | ralsina: hey, when do you think this commit https://github.com/snapcore/snapcraft/commit/6c012194bde will hit the snapcraft server (or, can it backported now ;-))? | 10:43 |
| ralsina | Trevinho: I don't work on snapcraft :-) | 10:44 |
| ralsina | Trevinho: so, I hope soon, if you need it! | 10:44 |
| Trevinho | ralsina: yeah, but.... Didn't you manage that server or what (IIRC some days ago you got pinged to restart the job)? | 10:45 |
| Trevinho | and I don't know how the server-side is managed (if it's just using zeisty or a snapcraft ppa) | 10:45 |
| * zyga hugs dholbach | 10:58 | |
| ralsina | Trevinho: not really | 11:05 |
| Trevinho | oh, ok... so sorry. | 11:06 |
| ralsina | Trevinho: but I can ping the right people. What's the change server side? That link points to snapcraft code | 11:06 |
| Trevinho | ralsina: that commit should be included | 11:06 |
| ralsina | Trevinho: you showed a link to a PR in snapcraft, that's client-side code, not server-side | 11:07 |
| Trevinho | ralsina: no, it's not... | 11:07 |
| Trevinho | ralsina: it's all shared code | 11:07 |
| ralsina | Trevinho: the store is lp:software-center-agent, it's a whole different project | 11:08 |
| * ralsina -> school run bbl | 11:09 | |
| Trevinho | ralsina: oh, wait... I meant a different thing then... this: https://parts.snapcraft.io/v1/parts.yaml | 11:10 |
| Trevinho | (the generator of that) | 11:10 |
| cjwatson | seb128: https://bugs.launchpad.net/launchpad/+bug/1626739 | 11:19 |
| mup | Bug #1626739: Snapcraft build failing in Yakkety for unauthenticated stage-packages <launchpad> <snap> <Launchpad itself:New> <https://launchpad.net/bugs/1626739> | 11:19 |
| * dholbach hugs zyga back | 11:21 | |
| zyga | dholbach: visit spain sometimes, great places to see, great food, great weather, sun and no snow :) | 11:24 |
| dholbach | :-) | 11:25 |
| mup | PR snapcraft#938 closed: store: return specific error when already owned <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/938> | 11:27 |
| ralsina | Trevinho: ahhhhh parts, no idea about that, never touched it | 11:29 |
| Trevinho | ralsina: sorry for bothering you then... :-) | 11:30 |
| ralsina | Trevinho: np | 11:30 |
| sergiusens | Trevinho that was roadmr | 11:37 |
| Trevinho | sergiusens: yeah, I figured just two seconds after... :-D | 11:39 |
| ralsina | hahaha | 11:39 |
| Trevinho | I remembered the nickanme started with "r"... :-P | 11:40 |
| Trevinho | and since I know ralsina does serverside stuff.... :-P | 11:40 |
| * Trevinho is terrible with names... Sorry :-) | 11:40 | |
| ralsina | Trevinho: it happens :-) | 11:41 |
| zyga | mv roadmr r-server-side-stuff | 11:41 |
| zyga | mv ralsina r-server-side-stuff | 11:41 |
| zyga | aww, clash | 11:41 |
| Trevinho | lol | 11:41 |
| Trevinho | no, we're in a snappy world... That can't happen! | 11:41 |
| ralsina | Hell, I do touch some server-side-stuff so I just assumed I had forgotten about it | 11:41 |
| zyga | maybe you want a round-robin queue? | 11:41 |
| nottrobin | I get pinged every time someone mentions round-robin | 11:42 |
| nottrobin | I didn't even know what it was to start with | 11:42 |
| nottrobin | :D | 11:42 |
| nottrobin | as you were | 11:42 |
| Elleo | snapcraft's failing for me with an error about held broken packages when it tries to fetch the stage packages; is there any way to get it be more verbose and tell me which packages are causing the issue? running with -d didn't help | 12:50 |
| zyga | Elleo: while this is totally different from what you may expect try opening a second terminal and run forkstat there | 12:50 |
| zyga | the output should tell you what apt is doing and may give you a hint of what is going wrong | 12:51 |
| seb128 | cjwatson, thanks, am I reading correctly that there is no workaround suggestion atm? | 12:51 |
| Elleo | zyga: okay, thanks | 12:51 |
| cjwatson | seb128: I don't think I have anything at the moment, unfortunately, short of not using stage-packages | 12:54 |
| cjwatson | (which is not really a workaround!) | 12:55 |
| seb128 | cjwatson, right, I was going to say that I kind of need those... | 12:55 |
| mup | PR snapd#2398 opened: cmd/snap: change terms accept URL following UX review <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2398> | 12:55 |
| seb128 | well, back on using xenial for now I guess, I might try to backport things to a ppa on top to workaround | 12:55 |
| cjwatson | I forget quite why it only affected yakkety | 12:56 |
| cjwatson | or post-xenial I guess | 12:56 |
| Elleo | zyga: nothing obvious there, it does a bunch of stuff with apt-key presumably checking signatures when updating, starts a few apt/method/http threads and then stops | 12:56 |
| zyga | well, it was a long shot | 12:57 |
| Elleo | zyga: I don't get any errors installing other packages on the host system normally, but it looks like oxide is being held for some reason | 12:57 |
| === hikiko is now known as hikiko|ln | ||
| cjwatson | seb128: it's definitely fixable, just a bit complicated because we need to bite the bullet and finally start sending public key material to builders; chances of me getting to it this year are low :-/ | 12:58 |
| seb128 | cjwatson, don't worry, it would be nice if it worked but it's not really blocking anything that needs to land from our side, we just wanted to try to provide gtk apps based on the yakkety gtk version to xenial users, but we can backport the new gtk to xenial in a ppa for that | 12:59 |
| ogra_ | cjwatson, why is that PPA enabled at all ? there is nothing relevant in it | 13:01 |
| ogra_ | (neither for xenial nor for yakkety) | 13:01 |
| ogra_ | imho we could just completely drop it and be done | 13:02 |
| cjwatson | ogra_: until the next time we need it | 13:05 |
| ogra_ | hmm | 13:05 |
| cjwatson | it was definitely needed pre-xenial | 13:05 |
| ogra_ | seems the last time was in 2015 | 13:05 |
| ogra_ | (looking at the packages in there) | 13:06 |
| cjwatson | and it's very useful to have that kind of facility available | 13:06 |
| ogra_ | true indeed | 13:06 |
| cjwatson | right, it was absolutely necessary pre-xenial because the archive didn't have snapcraft | 13:06 |
| cjwatson | in the future y'all might well decide that you want a newer version of snapcraft used by LP regardless of what's in the distribution | 13:06 |
| cjwatson | this is how we do that kind of thing | 13:06 |
| ogra_ | yeah, understood | 13:07 |
| mup | PR snapd#2399 opened: Add /dev/uhid to bluetooth-control interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2399> | 13:19 |
| zyga | morphis__: hey, remember that configure bug, can you tell me whicih version of snap-exec you have in you core | 13:28 |
| zyga | which* | 13:28 |
| zyga | morphis__: is that in a core or classic system? | 13:28 |
| zyga | morphis__: gustavo just made me realise that without sufficiently up-to-date core snap and snap-exec you won't get it to work | 13:29 |
| renato__ | jdstrand, could you approve camera-app package? https://myapps.developer.ubuntu.com/dev/click-apps/5990 vr 7 and 8 | 13:33 |
| mup | PR snapcraft#926 closed: sources: add current dir to ignore list if we're iterating on parent <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/926> | 13:36 |
| zyga | jdstrand: hey | 13:38 |
| zyga | jdstrand: we will deny --jailmode or --devmode when --classic is passed | 13:38 |
| zyga | jdstrand: I'll make the patch after lunch | 13:38 |
| zyga | jdstrand: classic confinement seems to work for me locally :) | 13:38 |
| zyga | jdstrand: I could use a few reviews, I think it can all land toda | 13:39 |
| === DanielLlewellyn[ is now known as diddledan__ | ||
| === hikiko|ln is now known as hikiko | ||
| morphis__ | zyga: I am using 2.18 here from the core snap from candidate | 14:01 |
| morphis__ | its a classic system with SNAP_REEXEC | 14:01 |
| zyga | morphis__: in a core system or on classic? | 14:01 |
| morphis__ | zyga: however lorn was trying it with 2.17.1 from the ubuntu image ppa on classic | 14:01 |
| zyga | morphis__: ah, snap-exec doesn't use reexec | 14:01 |
| zyga | that's one of the things we'll fix later | 14:02 |
| morphis__ | zyga: but for me with SNAP_REEXEC and 2.18 the configure hook is working well | 14:02 |
| morphis__ | zyga: just for lorn it is 2.17.1 from the ppa without SNAP_REXEC and there it isn't working | 14:03 |
| jdstrand | roadmr: hi! fyi, r807 supports classic. I've got another unrelated bug I'd like to fix, but feel free to pull 807 if that works for you timing-wise | 14:12 |
| zyga | jdstrand: we have a streak of holidays and release next week, could you have a look at one essential part of snap-confine that's there for classic quickly | 14:13 |
| jdstrand | tedg, renato__: fyi, that ^ also has the unity8 workaround you asked for | 14:13 |
| tedg | jdstrand: Great! | 14:14 |
| zyga | jdstrand: essentially this: https://github.com/snapcore/snap-confine/commit/43f5041deb8ed061f8a38f4342a5c3065b8ec3cf | 14:14 |
| jdstrand | zyga: are those what you asked for earlier today? | 14:14 |
| tedg | Is anyone else able to build snaps on LP? | 14:14 |
| tedg | Seems I'm getting parts update errors. | 14:14 |
| zyga | jdstrand: it's piled up there, I didn't open PRs since github makes those uber long when stacking branches | 14:14 |
| renato__ | tedg, I built camera some minutes ago | 14:14 |
| zyga | jdstrand: but this is the essence, regardless of argument parsing changes (if we do the cheap way or if we do the full way) | 14:14 |
| renato__ | tedg, try again. I got that in one of the builds but worked nice on the second try | 14:15 |
| jdstrand | zyga: can you give me a prioritized list of what must be reviewed today? | 14:15 |
| renato__ | jdstrand, thanks. I am happy to not disturb you with reviews :D | 14:15 |
| zyga | jdstrand: this is the essential patch, everything else is optional | 14:15 |
| jdstrand | ok | 14:15 |
| renato__ | jdstrand, btw. My eds/unity8-pim is ready for review :D | 14:16 |
| zyga | jdstrand: if you +1 I'll land it without the intermediate argument parsing and error improvements | 14:16 |
| jdstrand | renato__: ack (I have it on my list already, might be today but maybe early next week) | 14:16 |
| renato__ | jdstrand, thanks, | 14:16 |
| jdstrand | renato__: approved | 14:16 |
| jdstrand | zyga: fyi, the commit message is not quite right. I think you mean "to essentially switch the sandbox off entirely" | 14:19 |
| zyga | jdstrand: yes, good catch | 14:20 |
| zyga | jdstrand: I'll correct that before it lands | 14:20 |
| roadmr | jdstrand: oh awesome! sure, I'll put that in the pipeline (but not smoke it) (pretty sure I've used this joke before) | 14:23 |
| jdstrand | roadmr: hehe | 14:25 |
| jdstrand | zyga: this is totally unimportant and unrelated to this PR, but in snap-confine.c you have | 14:26 |
| jdstrand | #ifdef HAVE_SECCOMP | 14:26 |
| jdstrand | sc_load_seccomp_context(seccomp_ctx); | 14:26 |
| jdstrand | #endif | 14:26 |
| jdstrand | zyga: but for apparmor you have: | 14:26 |
| jdstrand | sc_maybe_aa_change_onexec(&apparmor, security_tag); | 14:26 |
| jdstrand | zyga: and the ifdef for HAVE_APPARMOR is in sc_maybe_aa_change_onexec() | 14:27 |
| jdstrand | zyga: why not just: | 14:27 |
| jdstrand | zyga: why not just in snap-confine.c: | 14:27 |
| jdstrand | #ifdef HAVE_APPARMOR | 14:27 |
| jdstrand | sc_aa_change_onexec(...) | 14:27 |
| jdstrand | #endif | 14:27 |
| jdstrand | ? | 14:27 |
| jdstrand | zyga: basically, the 'maybe' caught me eye while doing the review :) | 14:28 |
| jdstrand | my* | 14:28 |
| mup | PR snapd#2400 opened: snap: support for parsing and exposing on snap.Info aliases <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2400> | 14:30 |
| mup | PR snapcraft#943 closed: Replace subTests with TestScenarios <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/943> | 14:33 |
| zyga | jdstrand: because that gets rid of the extra ifdef | 14:37 |
| zyga | jdstrand: and maybe apparmor is not enabled on boot | 14:38 |
| jdstrand | zyga: I'm not saying get rid of the ifdef. I'm asking why it isn't in hte same place as the seccomp one | 14:38 |
| jdstrand | zyga: or, why not put the seccomp one in sc_maybe_load_seccomp_context(...) | 14:39 |
| jdstrand | ? | 14:39 |
| zyga | jdstrand: because seccomp leaks the types around, I may return to it and to the same though | 14:40 |
| zyga | jdstrand: I wasn't touching seccomp lately :) | 14:40 |
| zyga | jdstrand: I plan to unify the code when we have more review time | 14:40 |
| jdstrand | zyga: it isn't important. I just thought it odd that the ifdef was in one place for seccomp and in another for apparmor | 14:40 |
| * zyga -> quick break for lunch | 14:40 | |
| * zyga nods | 14:40 | |
| jdstrand | zyga: what is important is I reviewed the patch you asked me to :) | 14:40 |
| jdstrand | zyga: just a request for a comment. also thanks for the --devmode/--jailmode update :) | 14:41 |
| mup | PR snapd#2401 opened: snap: abort install with ctrl+c <Created by stolowski> <https://github.com/snapcore/snapd/pull/2401> | 14:48 |
| tedg | cjwatson: sergiusens: Seeing some build errors that looks like snapcraft can't update its parts. Happening on other snaps too, but here's an example: https://code.launchpad.net/~ted/+snap/unity8-session-xmir-preload | 14:49 |
| tedg | I can update parts locally, so I don't think that's an issue. | 14:50 |
| tedg | Not sure what else to try to debug it. | 14:50 |
| cjwatson | Hm, I wonder why that would have changed. | 14:54 |
| cjwatson | Actually, I'm not sure that has anything to do with parts. | 14:55 |
| cjwatson | tedg: The actual error is from apt. I think it's just that a parts update happened to be right before it. | 14:55 |
| cjwatson | My guess would be that the set of packages pulled by the unity8 part is in fact not coinstallable when pulled from that PPA. | 14:56 |
| cjwatson | It's a little hard to tell, but hopefully cleanbuild would reproduce the same thing if you gave it an appropriate set of apt sources. | 14:57 |
| tedg | Oh, I figured it was a generic error message left over from converting things over to snap building :-) | 14:57 |
| tedg | Hmm, okay. I'm not sure what could have happened there, but a lot of people pushing into that PPA. | 14:58 |
| tedg | Thanks cjwatson ! | 14:58 |
| zyga | jdstrand: thank you, checking now | 14:58 |
| zyga | jdstrand: wooooot | 14:58 |
| zyga | jdstrand: thanks :) | 14:58 |
| bartbes | quick question, are the XDG_* environment variables already set based upon SNAP_USER_DATA, or do I have to make sure I do that myself? | 14:58 |
| ogra_ | easy answer: .... it depends | 14:59 |
| ogra_ | :) | 14:59 |
| bartbes | I'll just set it myself, then :P | 14:59 |
| ogra_ | there are desktop launcher parts you can use ... | 14:59 |
| ogra_ | if you use them, they set these vars | 14:59 |
| ogra_ | if you dont, you need to set them yourself ... | 15:00 |
| ogra_ | you can check whats set by installing hello-world | 15:00 |
| ogra_ | and then running hello-world.env | 15:00 |
| ogra_ | it will print the default environment the hello-world binary sees | 15:00 |
| ogra_ | your snap would see something similar | 15:01 |
| bartbes | right | 15:01 |
| zyga | bartbes: you don't have to do anything, we set $HOME and software correctly derives the rest | 15:04 |
| bartbes | well, if XDG_DATA_HOME is unset, yes | 15:04 |
| ogra_ | zyga, well, we dont explicitly set XDG_ vars, do we ? | 15:05 |
| jdstrand | zyga: fyi, all the 'pc' gadget uploads you did are approved and just need you to press the publish button | 15:05 |
| ogra_ | only the desktop launchers do | 15:05 |
| jdstrand | zyga: I also fixed the issue in the review tools that made it get hung up (requested a store pull, but that probably won't happen til next week) | 15:05 |
| bartbes | ogra_: the spec says it's derived from HOME if it isn't set | 15:06 |
| ogra_ | well, all i know is that the launchers set it based on $HOME, i wasnt aware it is set by something else now | 15:07 |
| ogra_ | (if it actually is) | 15:07 |
| jdstrand | bartbes: that's right. as such you don't need to set them. HOME is set to ~/snap/$SNAP_NAME/$REVISION and so your snap will use ~/snap/$SNAP_NAME/$REVISION/.config, ~/snap/$SNAP_NAME/$REVISION/.cache, etc | 15:07 |
| bartbes | ogra_: no, applications need to default to $HOME/.local/share themselves if $XDG_DATA_HOME isn't set | 15:08 |
| ogra_ | jdstrand, how if the XDG_ vards arent filled at all and the app looks for them | 15:08 |
| jdstrand | we will start setting XDG_RUNTIME_DIR in snapd | 15:08 |
| ogra_ | ah | 15:08 |
| jdstrand | ogra_: because the toolkits follow the spec | 15:08 |
| bartbes | jdstrand: you know, if they weren't set to begin with, anyway, I want it to be $SNAP_DATA_COMMON, since the information isn't version-specific | 15:08 |
| bartbes | so it doesn't matter, I need to write a wrapper anyway | 15:09 |
| jdstrand | bartbes: well, perhaps, but we wouldn't want to diverge from the spec I don't think (that was a conscious decision). we could arguably set HOME to SNAP_USER_COMMON, but that feels a little weird. you are always free to set XDG_... to SNAP_USER_COMMON if that is appropriate for your snap | 15:11 |
| bartbes | that's perfectly sensible | 15:11 |
| bartbes | I'm doing something weird anyway | 15:12 |
| zyga | ogra_: we don't but software should not set it either as libraries typically do that | 15:20 |
| zyga | jdstrand: the store issue that affected the pc gadget snap? | 15:20 |
| ogra_ | aha | 15:21 |
| ogra_ | (and i thought desktop envs usually set it on startup :) ) | 15:21 |
| attente | elopio: hey, could you take a look at why the clone is failing on this integration test on github c-i? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-snapcraft-daily/zesty/amd64/s/snapcraft/20161201_214708_59c43@/log.gz | 15:22 |
| barry | hi all. is there documentation on snap recipes in launchpad? i'm having a hard time finding it on help.launchpad.net or snapcraft.io | 15:22 |
| zyga | jdstrand: this is something I mentioned before a few times; the CE team would love if this landed for their devmode testing snaps. Can you eyeball it quickly (the function has like five syscalls inside) and give me some feedback. I didn't tweak the apparmor profile yet. https://github.com/snapcore/snap-confine/commit/b36fe6c334ca70166a7def06ba4418a764af492e | 15:26 |
| zyga | cwayne: ^^ | 15:27 |
| cwayne | zyga: <3 | 15:27 |
| cwayne | zyga: jdstrand: this is actually pretty critical to testing our projects | 15:28 |
| zyga | cwayne: sorry for starving it for so long | 15:28 |
| cwayne | zyga: no worries, totally understand how swamped you guys are :) | 15:29 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| jdstrand | zyga: I don't know what store issue you are referring to. I saw that the pc gadget snap was stuck in manual review. I approved it and fixed the review tools trunk so that won't happen again, but that hasn't landed in the store just yet | 15:32 |
| zyga | jdstrand: yes, that's what I was thinking about with the pc gadget snap | 15:33 |
| zyga | jdstrand: thank you for fixing that! | 15:33 |
| zyga | jdstrand: (those are auto built now as you probably know :) | 15:33 |
| zyga | jdstrand: the store issue was that the gadget snap required to have i386 elf binaries for i386 and I believe this is what you fixed | 15:38 |
| mup | PR snapd#2402 opened: debian: disable autopkgtests on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/pull/2402> | 15:38 |
| barry | the question i am trying to find documentation on is whether we can target zesty as the primary archive for automatic launchpad builds. i am building ubuntu-image, but i remember reading somewhere (that i can't find now) that only xenial is supported, but that won't work for us because we need e2fsprogs from >=yakkety | 15:40 |
| renato__ | sergiusens, would be nice if the "apps" section of the snapcraft file we could set environment variables to each app. Something like environment:"OXIDE_NO_SANDBOX=1;MY_APP_VAR=True" | 15:41 |
| renato__ | this will avoid create a wrapper file just to export vars | 15:41 |
| zyga | renato__: I believe you already can | 15:42 |
| zyga | renato__: we spent lots of time connecting the docs to make that owrk | 15:42 |
| zyga | renato__: may be disabled but we technically can now | 15:42 |
| zyga | I don't remember, sorry | 15:42 |
| renato__ | zyga, \o/ this is great, just need to figure out which syntax I should try | 15:44 |
| zyga | renato__: disclaimer, it may not be enabled at some layer yet but we definitely planned this for a long time so ask sergiusens | 15:47 |
| renato__ | zyga, thanks | 15:48 |
| zyga | jdstrand: hmmm, snap confine oopses the kernel | 15:48 |
| zyga | jdstrand: I guess we're pushing the boundaries | 15:48 |
| zyga | jdstrand: https://pastebin.canonical.com/172640/ | 15:48 |
| zyga | jjohansen: ^ | 15:49 |
| tyhicks | zyga: that's a bad strlen call so just a plain ol' bug (not pushing any limits) | 15:51 |
| tyhicks | zyga: can you file a bug with reproducer instructions? | 15:51 |
| zyga | tyhicks: against the kernel package? | 15:52 |
| tyhicks | zyga: yes, the linux source package | 15:52 |
| zyga | ay, will do | 15:52 |
| pmcgowan | should there be a direct mapping between implicitClassicSlots and what is marked transitional on the interfaces page? as there is not and I cannot grok the criteria | 15:53 |
| * zyga doesn't kow | 15:54 | |
| zyga | know* | 15:54 |
| jdstrand | tyhicks: hey, is that something that is known? ^ | 15:55 |
| tyhicks | jdstrand: I've not seen it before - does it look familiar to you? | 15:55 |
| jdstrand | no | 15:55 |
| pmcgowan | jamiebennett, any idea on my interfaces query above | 15:59 |
| mup | Bug #1646881 opened: Enable pre-caching of snaps in a classic chroot <cpc> <Snappy:New> <https://launchpad.net/bugs/1646881> | 16:00 |
| zyga | jdstrand: how can I discard any profile I may currently have? | 16:00 |
| pmcgowan | perhaps its that the interfaces will be provided by other snaps in all snaps world so its not transitional | 16:00 |
| zyga | jdstrand: I think that oops above is related to the fact that snap-confine is invoked from snap-confine | 16:00 |
| zyga | Dec 02 16:51:13 xenial-server audit[78188]: AVC apparmor="ALLOWED" operation="capable" profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine//null-mount-namespace-capture-helper" pid=78188 comm="snap-confine" capability=19 capname="sys_ptrace" | 16:00 |
| zyga | this shows up just before the oops | 16:01 |
| zyga | the "null"s there seem wrong | 16:01 |
| gerry_ | hi all, I uploaded a screenshot to " my apps" but it does not appear in gnome software ? | 16:01 |
| zyga | gerry_: I believe there's a bug about that already | 16:02 |
| bartbes | I installed a snap in devmode, but it still can't connect to either my x session or to opengl, do I need to do anything special, except list the plugs? | 16:02 |
| zyga | bartbes: no, you should be fine, what is the error you are seeing and how are you launching your app? | 16:03 |
| gerry_ | zyga: oh ok sorry to bother you all | 16:03 |
| bartbes | it's an error by the application itself, from sdl: "No available video device" | 16:04 |
| zyga | gerry_: no worries | 16:04 |
| bartbes | and it happens both when using snap run, or launching it using the /snap/bin file | 16:04 |
| bartbes | though it doesn't without any sandboxing, because if I run it directly it does work | 16:05 |
| bartbes | it doesn't need to contain a libGL does it? | 16:05 |
| zyga | bartbes: are you using nvidia propietary drivers? | 16:06 |
| bartbes | can I attach a debugger, or get a shell, maybe? | 16:06 |
| bartbes | yes | 16:06 |
| zyga | bartbes: interesting | 16:06 |
| zyga | bartbes: can you look at: snap run --shell snap.app (replace with the right stuff) | 16:06 |
| bartbes | on arch, I should probably mention | 16:06 |
| zyga | bartbes: and look at /var/lib/snapd/lib/gl | 16:06 |
| zyga | bartbes: do you see libGL there? | 16:06 |
| zyga | ah | 16:06 |
| zyga | on arch... hmm hmm | 16:06 |
| zyga | I think that's a known issue for arch and certain version of the driver | 16:07 |
| zyga | can you look at that directory | 16:07 |
| zyga | and report which driver version you have | 16:07 |
| bartbes | yeah, it's empty | 16:07 |
| zyga | in any case, report a bug on snap-confine on launchpad | 16:07 |
| bartbes | and the shell is kind of hard to use if I don't even have ls :P | 16:07 |
| bartbes | it's version 375.20-3 | 16:08 |
| zyga | bartbes: exit that shell and look at /sys/module/nvidia/version | 16:08 |
| zyga | bartbes: is it there? what does it contain? | 16:08 |
| bartbes | that contains 375.20, unsurprisingly | 16:08 |
| zyga | bartbes: when it runs outside of a snap, where is libGL.so | 16:09 |
| zyga | bartbes: unfortunately distros differ on how they package nvidia drivers and there's some code that has to be maintained for each distro | 16:09 |
| zyga | bartbes: the arch code is different from ubuntu entirely | 16:10 |
| zyga | bartbes: perhaps something changed since and it needs updating | 16:10 |
| zyga | bartbes: if oyu want to hack I can help you get started, maybe it's better now and something has been unified | 16:10 |
| zyga | bartbes: maybe it's just a path that needs updating | 16:10 |
| zyga | bartbes: nvidia support code is not under CI | 16:10 |
| bartbes | /usr/lib/libGL.so is a symlink to /usr/lib/libGL.so.1 is a symlink to /usr/lib/nvidia/libGL.so.1 is a symlink to libGL.so.1.0.0 | 16:10 |
| zyga | bartbes: (on any distro) | 16:10 |
| zyga | ah | 16:11 |
| zyga | interesting | 16:11 |
| zyga | that's different and indeed that would explain why it fails | 16:11 |
| zyga | can you grab snap-confine source | 16:11 |
| zyga | and patch one line | 16:11 |
| bartbes | sure | 16:11 |
| zyga | go to mount-support-nvidia.c | 16:11 |
| zyga | and jump to line 49 | 16:11 |
| zyga | oh, | 16:11 |
| zyga | and mabe as a second idea, compile snap-confine with --enable-nvidia-ubuntu | 16:12 |
| zyga | just as a quick test | 16:12 |
| zyga | as for recompiling with the same options as in current arch packaging please look at adding some globs there on line 49 | 16:12 |
| zyga | :/ | 16:12 |
| zyga | I'm sorry for this, my nvidia box is not usable lately and I don't test this actively on arch as a side effect | 16:13 |
| ZenHarbinger | Quick question: I know that work is/was done for xdg-open on yakkety. I've installed the snapd-xdg-open deb, but how do I call xdg-open from my snap? I get that it is not found (in the PATH). | 16:13 |
| bartbes | doesn't it follow the symlink? | 16:13 |
| zyga | ZenHarbinger: you should just call xdg-open, I believe the shim xdg-open is in the core snap | 16:13 |
| bartbes | or does it copy the symlink but not its target? | 16:14 |
| zyga | ah, it seems not to be the case | 16:14 |
| sborovkov | what's going on with ubuntu store? anyone knows? last few days it's super unresponsive. I constanly get 504 timouts when trying to publish new revision | 16:14 |
| zyga | bartbes: can you report a bug on snapd for this please | 16:14 |
| * zyga needs a break or a beer | 16:16 | |
| zyga | long day | 16:16 |
| bartbes | oh, so it isn't snap-confine? | 16:16 |
| jdstrand | zyga: discard a profile you already have? you don't want to do that | 16:18 |
| jdstrand | zyga: I'm going to refer you to tyhicks on why the nulls are in that ALLOWED log entry. iirc, there were some bugs jj was looking at in this area, but I'm not up on the issue | 16:19 |
| tyhicks | zyga: and I'm going to refer you to jjohansen - I'm not sure why they'd be there | 16:20 |
| tyhicks | jjohansen: if you are too swamped to triage it today, let me know and I can dig through the code | 16:21 |
| tyhicks | zyga: I think the most important thing we need from you is a reproducer | 16:21 |
| bartbes | zyga: so what should I mention in my report, that I'm running arch with nvidia and /var/lib/snapd/lib/gl/ is empty? | 16:23 |
| zyga | tyhicks: this is not urgent for today | 16:27 |
| zyga | tyhicks: we can have a call to discuss this next week, perhaps faster than irc | 16:27 |
| zyga | bartbes: yes, and the driver version and the location of the GL files in the tree | 16:27 |
| zyga | bartbes: sorry I meant to reply to ZenHarbinger earlier | 16:28 |
| bartbes | alright | 16:28 |
| zyga | ZenHarbinger: can you report a bug on missing xdg-open in the core snap please | 16:28 |
| zyga | tyhicks: the reproducer will take some time to create, I don't quite know what I did to make this happen (yet) | 16:28 |
| zyga | I see two different versions of s-c being invoked (one from my tree, one from the core snap) | 16:29 |
| tyhicks | zyga: ok, the stacktrace might be sufficient since I suspect that it is most likely strlen() being called on a bad address or an unterminated string | 16:30 |
| tyhicks | zyga: in other words, don't spend personal time working on it | 16:31 |
| zyga | ok :) | 16:31 |
| zyga | tyhicks: looking there everything seems to be testing for non-NULL values but maybe it's just garbage, not null | 16:34 |
| bartbes | zyga: oh, I just noticed /usr/lib/nvidia/libGL* is in libglvnd, which the snap-confine source claims is unsupported, so this is a known issue? | 16:34 |
| zyga | bartbes: yes :-( | 16:34 |
| zyga | bartbes: I failed to find a way to support that | 16:34 |
| zyga | bartbes: if you can spend some cycles on this then this would be really appreciated | 16:34 |
| bartbes | why doesn't it work? | 16:35 |
| bartbes | isn't the libGL.so.1 that's pointed to just a valid libGL? | 16:35 |
| zyga | bartbes: the lib-gl-vendor library is a shim that does dlopen on the real library based on some condition | 16:36 |
| zyga | bartbes: you'd have to see what it does internally and what it takes to make the sandbox work with this | 16:36 |
| zyga | bartbes: the glvendor thing feels like a good idea but just is more complicated to support | 16:38 |
| bartbes | I hadn't heard of it before today | 16:38 |
| bartbes | so I don't know how it got installed :P | 16:38 |
| zyga | welcome to linux plumbing :) | 16:38 |
| zyga | bartbes: it's a part of the nvidia driver stack now | 16:38 |
| zyga | bartbes: and thank you for using snappy ::) | 16:41 |
| bartbes | can't you just.. copy the entire thing? | 16:42 |
| zyga | bartbes: you can do a few things but you have to make libglvndr find what it expects in the right spot | 16:42 |
| zyga | bartbes: TBH nvidia support is one of the more hairy part of snap-confine | 16:42 |
| zyga | tyhicks: yeah, looks like it explodes because of strlen | 16:44 |
| zyga | tyhicks: but that implies the non-null pointer is garbage somehow | 16:44 |
| * zyga is tempted to build a kernel with an extra printk | 16:44 | |
| zyga | it's friday and I could have my first kernel patch; | 16:45 |
| bartbes | it looks like it just dlopens libGLX_<vendor>.so | 16:45 |
| zyga | bartbes: the key question is -- where from | 16:45 |
| zyga | bartbes: look at what the symlinks do | 16:45 |
| zyga | bartbes: maybe what we need is to symlink the right /usr/lib/nvidia content, not sure | 16:46 |
| bartbes | from the standard path, I managed to get it to load from somewhere else using LD_LIBRARY_PATH | 16:46 |
| zyga | bartbes: remember that snaps don't run in the typical environment | 16:46 |
| zyga | bartbes: snap-confine does lots of magic | 16:46 |
| bartbes | oh, the "normal" one is in /usr/lib/libGLX_nvidia.so.0 | 16:46 |
| zyga | bartbes: one of thoe is pivot_root | 16:46 |
| zyga | those* | 16:46 |
| zyga | and / is different (it is the core snap or the ubuntu-core snap) | 16:46 |
| bartbes | well, technically what it points to, which is the versioned one, but it loads the .0 using dlopen | 16:47 |
| zyga | and your old / is in /var/lib/snapd/hostfs | 16:47 |
| zyga | so the nvidia support code for arch puts a tmpfs in /var/lib/snapd/lib/gl | 16:47 |
| zyga | and drops a bag of symlinks from there to /var/lib/snapd/hosfs/usr/lib/nvidia* | 16:47 |
| zyga | the globs control those | 16:47 |
| zyga | does that make sense? | 16:47 |
| zyga | at runtime snapcraft-made wrapper file adds SNAP_LIBRARY_PATH to LD_LIBRARY_PATH | 16:48 |
| zyga | and SNAP_LIBRARY_PATH contains /var/lib/snapd/lib/gl | 16:48 |
| zyga | (and that's end of the magic) | 16:48 |
| bartbes | I see | 16:50 |
| bartbes | I've been poking about some more and I'm even more confused now | 16:51 |
| zyga | bartbes: I'll gladly help if you have a question | 16:51 |
| bartbes | so it turns out "both" "vendors" point to the same libGLX in the end | 16:51 |
| * bartbes sighs | 16:52 | |
| bartbes | that said, it does look like it uses dlopen without a fixed path | 16:52 |
| zyga | yeah, there's hope | 16:52 |
| zyga | its just requires someone to follow the trail of calls to the end | 16:52 |
| zyga | strace helps | 16:52 |
| bartbes | aha, I figured out why it doesn't load | 16:53 |
| bartbes | I tried to force it with LD_PRELOAD: | 16:53 |
| bartbes | /bin/sh: error while loading shared libraries: libnvidia-tls.so.375.20: cannot open shared object file: No such file or directory | 16:53 |
| zyga | ah | 16:53 |
| bartbes | no wait, that may be because the preload is before library path | 16:53 |
| zyga | "/usr/lib/libnvidia-tls.so*", | 16:53 |
| zyga | that's probably handled | 16:53 |
| bartbes | anyway, it's time to eat dinner, I'll look into it some more afterwards | 16:53 |
| zyga | thanks! stay in touch please | 16:54 |
| === JanC is now known as Guest2425 | ||
| === JanC_ is now known as JanC | ||
| kalikiana | zyga: Still there? | 17:20 |
| kalikiana | I added rules for my fake /usr/bin as we talked about earlier this week, and it's mounted - but I can't execute anything from it | 17:21 |
| kalikiana | Was wondering if you'd have some hint, I feel like I'm missing something | 17:21 |
| kalikiana | /etc/apparmor.d/usr.lib.snapd.snap-confine: mount options=(ro bind exec) /snap/*/** -> /usr/**, /usr/bin/** ixr, | 17:22 |
| kalikiana | /var/lib/snapd/mount/snap.ubuntu-sdk-ide.ubuntu-sdk-ide.fstab: /snap/ubuntu-sdk-ide/x14/bin /usr/bin none bind,ro,exec 0 0 | 17:22 |
| zyga | kalikiana: yes | 17:23 |
| zyga | kalikiana: when you say you cannot execute anything, can you be more specific please | 17:24 |
| kalikiana | In "snap run --shell" I can see my fake /usr/bin, but I get "bash: /usr/bin/pkexec: Permission denied" | 17:24 |
| zyga | kalikiana: ah, right, that would be the base confinement not letting you run that specific executable | 17:24 |
| zyga | kalikiana: some are allowed, some are not | 17:24 |
| kalikiana | ls /usr/bin confirms that the files are there | 17:24 |
| zyga | kalikiana: you won't get out of the sandbox with pkexec btw | 17:24 |
| zyga | kalikiana: if you tell me more what you need to do I may be able to help you better | 17:25 |
| zyga | kalikiana: yes but the process is confined and the confinement doesn't allow to run that particular binary | 17:25 |
| zyga | kalikiana: you can look at dmesg | grep DENIED to confirm this | 17:25 |
| kalikiana | zyga: That is fine, I just need to deal with the app "expecting" /usr/bin/pkexec but I don't actually need the functionality to be equivalent | 17:25 |
| zyga | kalikiana: unfortunately you won't be able to do it this way but maybe there's a way | 17:25 |
| zyga | kalikiana: put a symlink over /usr/bin/pkexec | 17:26 |
| zyga | and make that symlink point to something benine that is allowed by the policy, e.g. /bin/true or maybe /snap/yoursnapname/current/fake-pkexec | 17:26 |
| zyga | symlinks are "transparent" to apparmor, apparmor really only cares about the final path | 17:26 |
| zyga | give that a try | 17:26 |
| kalikiana | zyga: I don't get DENIED for pkexec | 17:27 |
| zyga | kalikiana: maybe it's silent then, interesting | 17:27 |
| zyga | kalikiana: give that a try though | 17:27 |
| kalikiana | Hmmm not sure if I follow | 17:27 |
| * zyga should rest a littlet | 17:27 | |
| zyga | little | 17:27 |
| kalikiana | zyga: The pkexec is a shell script in my snap | 17:27 |
| zyga | I'll be back in a few hours to check if my kernel built, if you leave me a message I'll respond | 17:27 |
| zyga | kalikiana: right, the point is that your overlaid /usr/bin/pkexec _must_ be a symlink to something in $SNAP | 17:28 |
| === devil is now known as Guest90793 | ||
| zyga | kalikiana: or something that is already allowed to execute | 17:28 |
| kalikiana | zyga: How could I create that? I can't snap a symlink before I know the real path with its version.. | 17:29 |
| zyga | kalikiana: you can use current | 17:30 |
| zyga | kalikiana: the symlink can be "/snap/$SNAP_NAME/current/fake-usr-bin/fake-pkexec" | 17:30 |
| zyga | kalikiana: just put the snap name for real | 17:30 |
| mup | Bug #1642581 opened: Livepatch checkState: check-failed <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1642581> | 17:31 |
| zyga | kalikiana: then adjust the fstab file to bind mount fake-usr-bin over /usr/bin | 17:31 |
| kalikiana | Okay, that makes sense. Will try that | 17:33 |
| kalikiana | Thanks | 17:33 |
| bartbes | so that was fun, I figured out I was missing some X libraries | 17:39 |
| bartbes | copied them over.. "*** stack smashing detected ***" | 17:39 |
| zyga | bartbes: interesting, might be incompatiblity between libc in arch and the one in the core snap | 17:40 |
| zyga | bartbes: would be good to check if the version are compatible and if there are any funny patches | 17:40 |
| bartbes | and the system I built the binaries on, debian oldstable | 17:40 |
| zyga | the way the userspace library that that is the "driver" sharing works is always at risk that this would happen | 17:41 |
| zyga | ideally libc is stable and compatible but ... well | 17:41 |
| zyga | it's all FOSS and patches | 17:41 |
| bartbes | right, I presume this would be the arch nvidia driver, linked against the arch libc, and the libc available in the snap, which is the ubuntu core one | 17:41 |
| bartbes | I wonder.. if I copy the new libc in.. | 17:41 |
| zyga | no but ... you can bind mount the arch libc | 17:42 |
| zyga | as a quick test | 17:42 |
| zyga | sudo mount --bind /lib/glibc-something-something /snap/ubuntu-core/current/lib/glibc-something-something | 17:42 |
| zyga | replace ubuntu-core with core if you have that, or do both to be safe | 17:42 |
| === Guest90793 is now known as devil_ | ||
| bartbes | same result | 17:44 |
| bartbes | oh well, at least I tried | 17:44 |
| * zyga hugs bartbes | 17:45 | |
| zyga | thank you! | 17:45 |
| bartbes | it's good to see you took the hard problem of portable binaries | 17:49 |
| bartbes | and added confinement to it :P | 17:49 |
| mup | Bug #1646912 opened: Snaps after an update disappear from the launcher <Snappy:New> <https://launchpad.net/bugs/1646912> | 17:52 |
| zyga | bartbes: well, confinement is actually not a factor in this prolem | 17:56 |
| bartbes | not in this particular problem | 17:56 |
| zyga | bartbes: (of only nvidia didn't need a proprietary driver) | 17:56 |
| zyga | bartbes: you were joking perhaps but I just wanted to clarify that | 17:56 |
| zyga | bartbes: it's perectly possible to make this work but we'd have to put the driver into a snap | 17:56 |
| zyga | bartbes: and assuming the kernel is OK, id all work | 17:57 |
| zyga | bartbes: I was thinking about prototyping this but didn't have the time | 17:57 |
| bartbes | I don't think you can put the driver in a snap, since they are tied to the kernel module versions | 17:57 |
| zyga | bartbes: are they? | 17:57 |
| zyga | bartbes: AFAIK the module is but not the userspace lib | 17:57 |
| zyga | bartbes: the userspace lib is not something we rebuild and that's the problematic part | 17:58 |
| bartbes | not sure, but when I update the drivers (both sides) and try to run something using gl after I tend to get version mismatch errors | 17:58 |
| zyga | bartbes: interesting, maybe they share some cookie | 17:58 |
| zyga | bartbes: it'd be good to have someone from nvidia to work with us on this | 17:58 |
| * zyga gets back to resting, not looking at irc | 17:59 | |
| cjwatson | elopio: did you ever get a chance to check whether the firewall fix from https://portal.admin.canonical.com/97657 improved matters for you? | 18:26 |
| kalikiana | Hrm. I guess the symlink isn't possible, absolute or relative (../usr/bin): './parts/stubs/build/pkexec' is a broken symlink pointing outside the snap | 18:33 |
| mup | PR snapd#2402 closed: debian: disable autopkgtests on ppc64el <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2402> | 18:48 |
| larryprice | i'm attempting to use X from the lxd snap, but doing so generally requires bind-mounting /tmp/.X11-unix from the host to the container | 19:07 |
| larryprice | however there is no /tmp/.X11-unix in my snap's fs | 19:07 |
| larryprice | is something mounting over /tmp so an unconfined snap can't access? is there any way around this? | 19:08 |
| bartbes | to the former: yes | 19:26 |
| jjohansen | zyga: have you opened a bug for your strlen oops yet? | 19:38 |
| larryprice | bartbes, thanks for the confirmation. so there's no way to access anything in /tmp on the system from a snap? | 19:43 |
| bartbes | I'm not sure, I only found this out during debugging earlier | 19:43 |
| ali1234 | i have a question | 19:58 |
| ali1234 | if you make a snap containing a web app, how do you use it on a vhost? | 19:59 |
| ali1234 | for example wordpress | 20:01 |
| ssweeny | you'd probably want something like nginx in front of it acting as a proxy | 20:03 |
| ali1234 | so that is not automated? | 20:03 |
| ssweeny | it depends on the packager what they include | 20:04 |
| ssweeny | you could include a copy of nginx or use the distro version | 20:04 |
| ssweeny | or a separate snap of nginx that points to your wp snap :) | 20:05 |
| ali1234 | including a copy of nginx doesn't help | 20:05 |
| ali1234 | suppose i have bought three domain names, foo.com, bar.com, baz.com | 20:05 |
| ali1234 | i want to run separate wordpress instances on foo.com and bar.com, and rocket chat on baz.com | 20:05 |
| ali1234 | and i only have one dedicated server | 20:05 |
| ali1234 | how do i do that, using snaps? | 20:06 |
| ssweeny | see for example how nextcloud does it: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml | 20:06 |
| ssweeny | they include apache and everything needed to run nc on its own | 20:07 |
| nacc | ali1234: snaps are very different in this regard, IMO | 20:07 |
| ssweeny | you could on top of that have something like nginx proxying requests to that apache instance | 20:07 |
| nacc | and you'd probably need something like that, to handle the port issues you run into with having multiple webservers running (potentially) | 20:08 |
| nacc | *that being what ssweeny is describing | 20:08 |
| ali1234 | yes | 20:08 |
| ali1234 | so i would end up needing multiple apache installs | 20:08 |
| nacc | well, each app would have its own | 20:08 |
| ali1234 | then i would have to manually configure nginx to proxy them all? | 20:08 |
| ssweeny | that's one way to do it | 20:08 |
| ssweeny | easy enough if not terribly efficient | 20:09 |
| ali1234 | is there a way to do it where all i have to do is install things and then it just works? | 20:09 |
| ssweeny | you could also roll your own snap with wp, rocket.chat, and apache with the apache config set | 20:09 |
| ali1234 | that doesn't seem like it would have any benefit over just installing it the old way | 20:10 |
| ssweeny | confined apache alone seems worth it :) | 20:10 |
| ali1234 | not really, not if it is the only thing running on the server | 20:10 |
| nacc | ali1234: i think you misunderstand what confinement gets you, potentially | 20:10 |
| nacc | ali1234: it doesn't matter that there are or aren't other things running on the server, really | 20:11 |
| ali1234 | confinement isn't the problem i am trying to solve though | 20:12 |
| ali1234 | the problem i am trying to solve is that every web app has different weird requirements that conflict with each other | 20:12 |
| nacc | which snaps help solve :) | 20:12 |
| ali1234 | but only if you put each thing into a different snap | 20:12 |
| ssweeny | right | 20:12 |
| nacc | ali1234: not sure what you're arguing is the alternative? | 20:13 |
| ali1234 | it's not the alternative. what i do now is instal things from source in /usr/local | 20:13 |
| ali1234 | it ends up a huge mess | 20:13 |
| ssweeny | right so snaps will still help there since you only have to build each piece once and they won't interfere with each other | 20:14 |
| ali1234 | yeah | 20:15 |
| ssweeny | there's just a bit of configuration on top to get them to cooperate, which can't be harder than what you're doing now | 20:15 |
| ali1234 | so what i would like to do is install web app snaps and then use "snap connect" to connect them all to my web proxy snap (which might be nginx, or might be something else) | 20:15 |
| ali1234 | through a standard interface | 20:16 |
| ali1234 | rather than manually writing an nginx config file | 20:16 |
| ali1234 | this kind of crosses over with juju at this point | 20:17 |
| ali1234 | but this is something juju never really seemed to be able to do either | 20:17 |
| nacc | ali1234: well, your web proxy snap would then have that config file, basically, or understand how to handle `snap connects` to it sslots? | 20:17 |
| ali1234 | yes | 20:17 |
| ali1234 | the web proxy snap would have a config file which lists all the domains/vhosts | 20:17 |
| ali1234 | then from that it would auto generate a list of interfaces | 20:18 |
| ssweeny | a "web-proxy" slot would be interesting I think but I don't know if there's anything close to that implemented now | 20:18 |
| ali1234 | and i'd connect the web apps to them | 20:18 |
| ssweeny | close to that conceptually I mean | 20:18 |
| ali1234 | yeah that's it | 20:18 |
| ssweeny | mostly what interfaces do now is mediate access to files and dbus communication | 20:18 |
| nacc | you'd also have to give that connection more information | 20:19 |
| nacc | like what port to proxy to what port, etc | 20:19 |
| ali1234 | no | 20:19 |
| ali1234 | it would proxy whatever you connect it to | 20:19 |
| nacc | ok, that could be the plug you defined | 20:19 |
| ali1234 | the only information you would give it on the nginx side is what domain name and port to listen on | 20:19 |
| ali1234 | yes | 20:19 |
| nacc | ali1234: i think you took me too literally, i mean you'd have to define that as part of the connect-interface | 20:20 |
| ali1234 | the port that the web app internally runs on should be dynamically chosen to avoid conflicts | 20:20 |
| ali1234 | i see, yes | 20:20 |
| nacc | ali1234: aiui, everything you're saying doesn't exist yet, but I've not tried recently | 20:20 |
| ali1234 | can you connect multiple snaps to the same mysql snap? | 20:23 |
| ali1234 | that seems like a similar problem, if the mysql snap has a configurable port | 20:23 |
| nacc | ali1234: again, i don't think that's how connect works currently | 20:24 |
| nacc | ali1234: e.g., nextcloud bundles its own mysql in the snap | 20:25 |
| nacc | ali1234: also, putting those connections between snaps, i wonder, if it runs a bit contrary to avoiding dependency hell. What happens when the mysql snap gets updated? How do you know your app is compatible? | 20:25 |
| nacc | (just thinking out loud0 | 20:26 |
| ali1234 | um... because its mysql | 20:26 |
| ali1234 | can you install two copies of the same snap at the same time, with different configuration? | 20:26 |
| ssweeny | right, currently if your app is tightly coupled to another piece of software you're better off including it | 20:26 |
| ali1234 | mysql has a well defined interface, it is not tightly coupled | 20:27 |
| nacc | ali1234: you can't install 'two copies' of a snap on the same system | 20:27 |
| nacc | afaik | 20:27 |
| ssweeny | there is some effort going on now with "framework" snaps like Qt, but it's still early days | 20:27 |
| nacc | ssweeny: cmiiw, please! | 20:27 |
| ssweeny | right, one snap one version | 20:28 |
| nacc | ali1234: so it feels like maybe you thought snaps were solving a different problem than they are? | 20:28 |
| ali1234 | i thought they were solving all problems :) | 20:29 |
| ssweeny | eventually :) | 20:29 |
| ali1234 | but this is one problem i have now | 20:30 |
| ali1234 | and it's really annoying | 20:30 |
| ali1234 | i'd like to try out rocket chat | 20:30 |
| ssweeny | right, so for now you can get some benefit from snapping but there is still some manual config needed | 20:30 |
| ali1234 | but i can't install it on my server | 20:30 |
| ssweeny | the rocket chat snap works pretty well | 20:30 |
| ali1234 | and many other web apps | 20:30 |
| ali1234 | but my server already has a horrible mess of vhost configs | 20:31 |
| ali1234 | also it is running 14.04 | 20:31 |
| nacc | ali1234: yes, sorry -- i should have 'had solved a different problem than they have' :) | 20:33 |
| ali1234 | at the moment it is running about 6 wordpress instances, some wiki software, a bug reporting app, a couple of joomlas | 20:33 |
| ali1234 | i think there's a gitlab install as well | 20:33 |
| ssweeny | multiple wordpress instances is going to be the big hurdle | 20:34 |
| ali1234 | they are the easiest to deal with currently because they don't need any funny dependencies like ruby on rails or node | 20:34 |
| ssweeny | maybe leaving them alone is the way to go then | 20:34 |
| ali1234 | just unzip it in the htdocs and that is it | 20:34 |
| ssweeny | since you still need a central nginx then you could still install the rocket snap | 20:35 |
| ali1234 | but i don't need a central nginx currently? | 20:35 |
| ali1234 | i just use apache vhosts | 20:35 |
| ssweeny | same difference :) | 20:36 |
| ssweeny | apache has a mod_proxy that'll let you do the same thing | 20:36 |
| ali1234 | hmmmmm | 20:36 |
| ssweeny | I just thought all the kids were using nginx these days | 20:36 |
| ali1234 | only because they are using five separate virtual machines to run one copy of wordpress | 20:37 |
| ssweeny | says the guy who set up a webserver like 6 years ago and is afraid to change it | 20:37 |
| ssweeny | running lighttpd no less because at the time the VPS had very limited RAM | 20:38 |
| ali1234 | this server moved off a VPS because of stupid ram limits | 20:38 |
| ali1234 | the provider placed a limit of like 8MB of non-swappable kernel memory | 20:39 |
| ali1234 | so we had like 1GB of RAM, but things were getting OOM killed because they opened too many files | 20:39 |
| ali1234 | took us ages to figure it out as well | 20:40 |
| larryprice | bartbes, fyi after installing in devmode i found some of my /tmp folders in `source=/var/lib/snapd/hostfs/tmp/` in the container | 20:41 |
| bartbes | when I tried to open that it was empty | 20:42 |
| bartbes | and that's in devmode | 20:42 |
| larryprice | hmm weird... mine only show up when i ask for the specific directory i'm looking for | 20:50 |
| jdstrand | renato__: if you click 'manual review' I'll approve https://myapps.developer.ubuntu.com/dev/click-apps/4632/rev/17/ | 21:09 |
| === ahoneybun_ is now known as ahoneybun | ||
| mup | Bug #1644058 changed: Different behaviour in MPRIS interface with local install vs store install <Snappy:Invalid> <https://launchpad.net/bugs/1644058> | 21:29 |
| mup | Bug #1646415 opened: cannot run configure hook <Snappy:New> <https://launchpad.net/bugs/1646415> | 21:56 |
| mup | PR snapcraft#937 closed: Incorporate all part properties into state tracking <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/937> | 23:24 |
| mup | PR snapcraft#944 opened: Release changelog for 2.23 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/944> | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!