| nacc | stokachu: np | 02:28 |
|---|---|---|
| mup | Bug # changed: 1627893, 1632124, 1632306, 1642257 | 04:18 |
| mup | PR snapd#2740 closed: releasing snapd version 2.22 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2740> | 07:18 |
| mup | PR snapd#2738 closed: spread: remove state tar on project restore <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2738> | 07:29 |
| mup | PR snapd#2691 closed: tests: allow to install snapd debs from a ppa instead of building them <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2691> | 07:35 |
| mup | PR snapd#2693 closed: cmd: rename mountinfo to sc_mountinfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2693> | 08:17 |
| mup | PR snapd#2742 opened: tests: fix typo in systems name <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2742> | 08:39 |
| mup | PR snapd#2676 closed: cmd: collect string utilities in one module, add missing tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2676> | 09:59 |
| zyga | good morning | 10:11 |
| zyga | sorry for joinling late, forgot I turned my server off | 10:11 |
| popey | http://askubuntu.com/questions/877850/error-cannot-deliver-device-serial-request-unexpected-status-400 <- any snappy people can help this person out? | 10:12 |
| zyga | popey: hey | 10:13 |
| zyga | popey: most of the time when this happens is when people build their own model | 10:13 |
| zyga | popey: or use a board outside of the supported set | 10:13 |
| mup | PR snapd#2742 closed: tests: fix typo in systems name <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2742> | 10:20 |
| mup | PR snapd#2713 closed: cmd: fix issues uncovered by valgrind <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2713> | 10:25 |
| mup | PR snapd#2416 closed: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2416> | 10:26 |
| mup | PR snapd#2739 closed: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2739> | 10:26 |
| mup | PR snapd#2698 closed: asserts,interfaces/policy: add support for $SLOT()/$PLUG()/$MISSING in *-attributes constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2698> | 11:00 |
| mup | PR snapd#2743 opened: debian: move the snap-confine packaging into snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2743> | 11:02 |
| === hikiko is now known as hikiko|ln | ||
| mup | Bug #1648777 changed: writing a (3GB sized) x86 image to a 3GB SD card makes the filesystem resizing being skipped <Snappy:Invalid> <initramfs-tools-ubuntu-core (Ubuntu):Invalid by ogra> <https://launchpad.net/bugs/1648777> | 12:15 |
| === hikiko|ln is now known as hikiko | ||
| mup | PR snapd#2658 closed: cmd: add mount / unmount helpers <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2658> | 12:44 |
| kalikiana | Hrm | 13:01 |
| kalikiana | Cannot find the definition for part 'desktop-ubuntu-app-platform'. | 13:01 |
| kalikiana | It may be a remote part, run snapcraft update to refresh the remote parts cache. | 13:01 |
| kalikiana | ^^ This seems to be a regression? Cloud parts used to be pulled in automatically | 13:02 |
| kalikiana | I was quite confused and it took me a bit to realize the part name wasn't wrong | 13:02 |
| didrocks | ogra_: hey! what do you think about adding a configure/install hook on the classic snap running apt update to initialize the apt database for the user? | 13:04 |
| ogra_ | didrocks, not much since that forces you to be online | 13:05 |
| ogra_ | didrocks, well, we could add it with an online check i guess ... but the whole thing is designed so that you can also use it witouth being online at all | 13:06 |
| didrocks | ogra_: well, when you install the snap, you are online already, correct? :) | 13:10 |
| ogra_ | true indeed | 13:10 |
| didrocks | and it we can try to make it ran only at that time? | 13:11 |
| didrocks | I'm happy to have a shot at it | 13:11 |
| didrocks | (not today) | 13:11 |
| didrocks | but just wanted to know if you were +1 first on it | 13:11 |
| ogra_ | sure, the script that gets executed is actually shipped in the core snap | 13:11 |
| ogra_ | and is only executed the first time you run "sudo classic" | 13:11 |
| icey | seems like a snap installed app can't read from the keyboard? | 13:11 |
| didrocks | ah, I was more thinking as a hook in the classic snap itself | 13:12 |
| icey | also, can't click on a link in the snapped app and open it in the system browser | 13:12 |
| ogra_ | "read from the keyboard" ? | 13:12 |
| ogra_ | do you have a camera attached ? :P | 13:12 |
| ogra_ | didrocks, nah, it should just become part of the setup script ... the classic snap only calls this | 13:12 |
| didrocks | ogra_: ok, do you have the repo reference handy? If not, no worry, I'll have a shot later anyway | 13:13 |
| ogra_ | no repo ... it is part of the livecd-rootfs package in the image PPA | 13:13 |
| icey | ogra_: copying text into a snapped app is weird | 13:13 |
| didrocks | ogra_: ok, which ppa? (if you prefer to do it yourself, feel free ;)) | 13:14 |
| ogra_ | didrocks, http://paste.ubuntu.com/23893526/ | 13:14 |
| ogra_ | didrocks, from https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 13:15 |
| didrocks | ogra_: excellent! Thanks a lot :) | 13:15 |
| ogra_ | (note that the pasted one is outdated, use the actual one from the PPA) | 13:15 |
| didrocks | yeah, I'll be able to find it, I'm sure :) | 13:17 |
| jdstrand | davidcalle: ping re security whitepaper (I asked a question probably after your eod on friday) | 13:35 |
| zyga | jdstrand: hey | 14:11 |
| jdstrand | zyga: hey :) | 14:11 |
| zyga | jdstrand: I'm working on the kernel bug and also on the string changes you suggested | 14:12 |
| zyga | jdstrand: I think the outcome will be much safer, thanks for that! | 14:12 |
| jdstrand | zyga: gret! :) | 14:13 |
| jdstrand | great even! | 14:13 |
| davidcalle | jdstrand: I'm on it today, pdf is live already | 14:19 |
| jdstrand | davidcalle: hi! :) ok, so is https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ the correct url for the whitepaper? it is out of date, but the pdf it links to is up to date | 14:26 |
| davidcalle | jdstrand: indeed, I've uploaded the new pdf, updating the page as we speak (will be live in a short moment) | 14:28 |
| jdstrand | davidcalle: ah, I see. ok, thanks! :) | 14:28 |
| om26er | what should I do if I want some feedback from the user once a snap is installed ? I am working on a selenium based twitter bot that is going to run on xvfb. For twitter login I need to request username/password from the user to login. | 14:46 |
| om26er | is there probably a way to run a script once a snap is installed ? | 14:46 |
| mup | PR snapd#2558 closed: snapstate: move refresh from a systemd timer to the inernal snapstate Ensure() <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2558> | 14:53 |
| kirkland | sergiusens: is that perhaps why my snap isn't showing up in the store? because it's classicly confined? | 14:59 |
| mup | PR snapd#2744 opened: move configstate.Transaction stuff into configstate.transaction <Created by mvo5> <https://github.com/snapcore/snapd/pull/2744> | 15:01 |
| stokachu | kirkland, snap find conjure-up works though it returns a bunch of results | 15:04 |
| kirkland | stokachu: can you "snap find hollywood"? | 15:04 |
| stokachu | snap find hollywood | 15:05 |
| stokachu | The search "hollywood" returned 0 snaps | 15:05 |
| stokachu | kirkland, is our snap published/public in the webui? | 15:05 |
| stokachu | your* | 15:05 |
| kirkland | stokachu: yes, it looks like it | 15:06 |
| stokachu | kirkland, not sure if this helps but here is what mine looks like from the webui: http://imgur.com/a/pEiEp | 15:11 |
| stokachu | kirkland, oh do you have a stable snap published? | 15:12 |
| stokachu | i have at least one stable | 15:12 |
| kirkland | stokachu: ah, maybe that's it? | 15:13 |
| kirkland | stokachu: so, I need to change "grade: devel" to "grade: stable" in snapcraft.yaml? | 15:14 |
| kirkland | stokachu: rebuild, reupload? | 15:14 |
| stokachu | kirkland, try just releasing it to stable channel from the webui | 15:15 |
| stokachu | jdstrand, is kirkland's hollywood snap not showing up in the snap search results b/c it hasn't been approved? | 15:27 |
| kirkland | <jdstrand> 00:40:01> kirkland: done. approved but you'll need to release it | 15:28 |
| kirkland | I got that on Friday | 15:28 |
| kirkland | and then I did release it | 15:28 |
| stokachu | kirkland, ah ok | 15:38 |
| jdstrand | stokachu: it is in beta and edge. 'stable' is the only channel 'snap find' will give results for | 15:38 |
| jdstrand | kirkland: fyi, I see 1.12 is uploaded but not released anywhere | 15:39 |
| kirkland | 1 kirkland@x250:/tmp/sandbox.hwgfBlQv/hollywood/snapā« snapcraft release hollywood 1 stable | 15:39 |
| kirkland | Revision 1 (classic) cannot target a stable channel (stable, grade: devel) | 15:39 |
| kirkland | aha! | 15:39 |
| kirkland | now that worked | 15:39 |
| kirkland | (bumped the rev) | 15:39 |
| stokachu | kirkland, \o/ | 15:40 |
| jdstrand | kirkland: you seem to have specified 'grade: devel' which means it will never go to stable | 15:40 |
| jdstrand | kirkland: ah, you fixed that in 1.12 | 15:40 |
| jdstrand | and snap find now finds it | 15:41 |
| stokachu | kirkland, haha nice snap | 15:42 |
| qengho | What does hollywood do, kirkland? | 15:50 |
| kirkland | qengho: https://www.youtube.com/watch?v=rVMn3xk5mcY | 15:50 |
| qengho | Ah! I remember this. | 15:50 |
| qengho | This reminds me of a tool I remember from my early unix days, when I was just an egg. Our auditory processing is as good or better than visual attention. An app would convert network traffic into sound. You'd start it and maybe hear that something seems a little off today. | 15:55 |
| cos- | what's the trick to create a desktop launcher with snap? i have desktop: entry in app: but no icon appears in menu | 15:55 |
| cos- | a working example would be nice | 15:56 |
| zyga | cos-: it's tricky, ask sergiusens | 16:04 |
| cos- | also having a desktop in setup/gui doesn't seem to work, as examplified here https://github.com/ubuntu-core/snapcraft-examples/blob/master/03-hello-world-desktop-devmode/setup/gui/hello-world-desktop.desktop | 16:04 |
| ogra_ | cjwatson, hey ... we need some expert opinion ... in the core images we used to use a profile.d snippet to extend the PATH with /snap/bin (we do that in classic still), for remote ssh commands without login shell that didnt work, so we moved the /snap/bin to the global PATH in /etc/environment ... now it turned out that some tests actually use su ... | 16:04 |
| mup | PR snapd#2745 opened: cmd: add sc_must_stpcpy <Created by zyga> <https://github.com/snapcore/snapd/pull/2745> | 16:05 |
| zyga | jdstrand: hey, could you please have a look at this pull request: ^^ this is the safe stpcpy we've discussed. | 16:05 |
| ogra_ | cjwatson, i remember you being opposed to change ENV_SUPATH (and i'm slightly reluctant to touch login.defs at all) ... should we or should we not change it there ? | 16:06 |
| zyga | jdstrand: my only comment was to perhaps use memmove just to be super paranoid safe | 16:06 |
| ogra_ | cjwatson, or rather ... what would be the drawbacks | 16:06 |
| cjwatson | ogra_: just /etc/environment is supposed to work for su as well; this is basically https://wiki.ubuntu.com/OneTruePath | 16:06 |
| kirkland | stokachu: okay, we're there now :-) | 16:07 |
| ogra_ | ah, i didnt find the wikipage | 16:07 |
| cos- | and for qt5 app should i have after: desktop/qt5, desktop-qt5 or qt5conf? all are used in different examples | 16:07 |
| cjwatson | ogra_: I don't think you should change it there, but rather you should chase down why su's use of pam_env apparently isn't working? | 16:07 |
| stokachu | kirkland, cool man | 16:07 |
| ogra_ | cjwatson, well, it seems it doesnt | 16:07 |
| kirkland | stokachu: thanks for your help | 16:07 |
| cjwatson | ogra_: I'm not arguing with that, but from the config file on my system it seems that it should | 16:07 |
| stokachu | np anytime | 16:07 |
| cjwatson | ogra_: so that seems worth tracking down rather than working around and forgetting | 16:07 |
| ogra_ | ok, thanks | 16:07 |
| mup | PR snapcraft#1092 opened: meta: properly get the icon extension from splitted name <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1092> | 16:18 |
| cos- | sergiusens: i'd appreciate any help with creating a .desktop launcher. my current code is here https://github.com/vranki/siilihai-client | 16:24 |
| ogra_ | cjwatson, hmm, are you actually sure su should use pam_env for PATH ? the manpage sounds like some vars wont be read from there http://paste.ubuntu.com/23894355/ | 16:26 |
| cos- | hmm, maybe the used files should be in the git repository and having them in the build directory isn't enough.. i'll try recreating the package with files in git | 16:26 |
| ogra_ | cjwatson, note the "Other" in there | 16:26 |
| cjwatson | ogra_: see /etc/pam.d/su | 16:28 |
| cjwatson | I see no reason to assume the manual page is up to date with the intended PAM configuration :-) | 16:29 |
| ogra_ | lol | 16:29 |
| ogra_ | ok | 16:29 |
| mup | PR snapcraft#1093 opened: python plugin: do the right thing with classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1093> | 16:54 |
| === petevg is now known as petevg_noms | ||
| stokachu | sergiusens, ^ will that fix classic install on trusty? | 17:17 |
| elopio | ogra_: you are scheduled for the linaro open hours on feb 23th, 8am pacific time. | 17:18 |
| ogra_ | elopio, ok, i'll add that to my calendar | 17:18 |
| elopio | Chipaca: zyga: would you like to join them for an episode and talk about ubuntu core 101? it would be feb 16th. | 17:18 |
| elopio | ogra_: thanks. Robert will send you an email with the details. | 17:19 |
| ogra_ | great | 17:19 |
| Chipaca | elopio, can i think about it? | 17:19 |
| zyga | elopio: yes, gladly | 17:19 |
| elopio | Chipaca: yes, and you can also say no :) This is the thing: http://www.96boards.org/OpenHours/ | 17:19 |
| zyga | elopio: can you please send me an invite? I forget everything otherwise :) | 17:19 |
| elopio | thanks zyga. | 17:20 |
| ogra_ | elopio, huh, saying no is an option ?!? | 17:20 |
| ogra_ | :P | 17:20 |
| elopio | ogra_: it was an option for you last week. Not anymore :p | 17:20 |
| ogra_ | haha | 17:20 |
| elopio | kgunn: are you around now? I'm not sure if you got my ping, maybe email is better. | 17:21 |
| elopio | jamiebennett: and this is the thing you signed up for: https://www.youtube.com/watch?v=P1_HjzcnJ-s | 17:22 |
| kgunn | elopio: what's up | 17:22 |
| elopio | you will be the main panelist on the march 9th. | 17:22 |
| kgunn | about to go for a run....but at least i got your most recent ping | 17:22 |
| jamiebennett | elopio: I did ;) | 17:23 |
| jamiebennett | ogra_: is also going so maybe we can tag team | 17:23 |
| elopio | kgunn: hello! go and run. I'm sending you an email to see if you want to show the kiosk on linaro openhours and ubuntu testing days. | 17:23 |
| kgunn | ah, elopio ok.... cc AlbertA ;) | 17:23 |
| elopio | will do. | 17:24 |
| elopio | jamiebennett: ogra_: Robert said rsalveti will be in the panel too. I can only imagine the party afterwards :D | 17:25 |
| ogra_ | elopio, lol | 17:25 |
| ogra_ | and i know in which bar it will happen ! | 17:25 |
| zyga | elopio: my pleasure :-) | 17:27 |
| zyga | elopio: lol :) | 17:27 |
| rsalveti | o/ | 17:27 |
| ogra_ | hah, the lurker ! | 17:28 |
| zyga | rsalveti: hey :) | 17:28 |
| zyga | rsalveti: how are you doing? | 17:28 |
| rsalveti | good :-) | 17:28 |
| rsalveti | who are going to be at connect? | 17:29 |
| ogra_ | o/ | 17:29 |
| zyga | rsalveti: I think only ogra_ | 17:29 |
| rsalveti | how are things at the snappy land :-) | 17:30 |
| zyga | connect is in US so I cannot go :/ | 17:30 |
| rsalveti | ogra_: oh! that would be awesome | 17:30 |
| ogra_ | rsalveti, it will !!! | 17:30 |
| ogra_ | zyga, huh ? budapest i thought ... | 17:30 |
| zyga | rsalveti: reliable little by little | 17:30 |
| zyga | ogra_: oh | 17:30 |
| zyga | ogra_: the vegas thing confused me | 17:30 |
| zyga | then I could go | 17:30 |
| zyga | (if someone would want me there) | 17:30 |
| ogra_ | i guess the US is dead territory for conferences for the next 4 years | 17:30 |
| rsalveti | hahah, indeed | 17:31 |
| rsalveti | ogra_: going to drive there? | 17:31 |
| ogra_ | nah | 17:31 |
| rsalveti | don't remember if you did that last time | 17:31 |
| ogra_ | i did | 17:32 |
| rsalveti | right, I had some good memories :-) | 17:32 |
| zyga | ogra_: or 16 | 17:32 |
| ogra_ | but i largely gave up on cars ... so it would be rental or train ... | 17:32 |
| zyga | ogra_: 4 + 4 then after the war with canada and mexico is over ;) | 17:32 |
| ogra_ | its a lovely ride thogh ... | 17:32 |
| ogra_ | zyga, if it is only canada and mexico, yeah | 17:32 |
| rsalveti | get a new porsche | 17:32 |
| ogra_ | nah, i still need to get rid of the three others :P | 17:33 |
| zyga | ogra_: then china invades and all connects will be in china ;-) | 17:33 |
| ogra_ | you mean "berlin - china" or "paris -china" ? | 17:33 |
| ogra_ | :) | 17:33 |
| zyga | ogra_: just bejning east, west, central, etc... | 17:33 |
| ogra_ | lol ... | 17:34 |
| zyga | ogra_: on the upside, aliexpres will ship locally | 17:34 |
| ogra_ | everywhere | 17:34 |
| zyga | from the moon :D | 17:34 |
| ogra_ | apart from UK though ... because of brexit | 17:35 |
| zyga | I still wait fo brexit for electricity, to stop the immigration of electrons from mainland | 17:35 |
| ogra_ | haha | 17:35 |
| zyga | UK could switch to 100VCD | 17:35 |
| === petevg_noms is now known as petevg | ||
| mup | PR snapd#2712 closed: interfaces/builtin: refine the content interface rules using $SLOT <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2712> | 18:41 |
| blackboxsw | sergiusens | 19:16 |
| blackboxsw | sorry my bad. was search the responses in the irc term | 19:17 |
| blackboxsw | was searching* | 19:17 |
| blackboxsw | was looking for hints as to why "service snap" namespace in trusty doesn't seem to map to a given snap running snap. For example, "sudo service snapd status" works on xenial, but not on trusty | 19:19 |
| mup | PR snapd#2746 opened: interfaces: remove some syscalls already in the default policy plus comment cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2746> | 20:10 |
| mup | PR snapd#2747 opened: interfaces/mount-observe: add quotactl with arg filtering (LP: #1626359) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2747> | 20:33 |
| mup | PR snapd#2748 opened: seccomp-support.c: add PF_* domains which can be used instead of AF_* <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2748> | 20:38 |
| zyga | jdstrand: hey, still around? | 20:46 |
| mwhudson | wtf, i think i've found a glibc bug | 20:48 |
| zyga | mwhudson: hey | 20:49 |
| zyga | mwhudson: long time, how are you? | 20:49 |
| mwhudson | zyga: ok! | 20:49 |
| mwhudson | zyga: well right now i am in a rabbit hole but otherwise :) | 20:49 |
| zyga | mwhudson: what are you up to? do you need a garden elf assistant? :) | 20:50 |
| mwhudson | zyga: i'll have a bug comment in a minute | 20:50 |
| mwhudson | zyga: i hope you didn't say 'elf' there by accident | 20:51 |
| zyga | hehehe | 20:51 |
| zyga | such a versatile word :) works both ways | 20:51 |
| mwhudson | oh heh i commented by email so i can't show it to you yet | 20:53 |
| mwhudson | zyga: it will be here in a few minutes: https://bugs.launchpad.net/snapd/+bug/1657504/comments/18 | 20:54 |
| mup | Bug #1657504: asciinema 1.3.0 snap is segfaulting on 14.04 <Snapcraft:In Progress by sergiusens> <snapd:New> <https://launchpad.net/bugs/1657504> | 20:54 |
| mcphail | I could never get dlopen() to work in a snap I was making | 20:55 |
| mwhudson | zyga: it's there now | 20:56 |
| mwhudson | mcphail: a classic or strict snap? | 20:56 |
| mcphail | mwhudson: strict | 20:56 |
| mwhudson | mcphail: probably something a bit different from this then, i think | 20:57 |
| mcphail | mwhudson: aah, OK | 20:57 |
| zyga | mwhudson: oh, intereting | 20:57 |
| zyga | mwhudson: looking | 20:57 |
| zyga | I was working on that part so very keen to get to the bottom ofthat | 20:58 |
| mwhudson | zyga: the code in glibc is around here https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a5318f9c8d1d42745a254479cf6bb1cd2acd516f;hb=HEAD#l2035 | 20:59 |
| mwhudson | zyga: DT_RUNPATH is only like 15 years old, of course there are still loads of obscure bugs when you try to use it | 20:59 |
| zyga | mwhudson: do you know if nss works by loading modules into the process or by doing IPC to something that loads the modules? | 20:59 |
| mwhudson | zyga: it just calls dlopen | 21:00 |
| mwhudson | this is one of the reasons static linking with glibc don't work good | 21:00 |
| mwhudson | zyga: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nsswitch.c;h=0a65f6ad0c640ae144cbe9d7c2edf9d67e67a245;hb=HEAD#l358 | 21:01 |
| zyga | mwhudson: that makes sense, I recall a warrning from the linker when one does that to name resolution functions | 21:01 |
| zyga | mwhudson: so what should we do to have libc load the nss modules from the core snap? | 21:02 |
| mwhudson | zyga: fix glibc to look at DT_RUNPATH in the executable, i think | 21:02 |
| mwhudson | zyga: which is of course going to be loads of fun | 21:02 |
| mwhudson | zyga: you could also try turning off the flags that make ld emit RUNPATH vs RPATH | 21:03 |
| zyga | mwhudson: and good fun of work | 21:03 |
| zyga | fun kind of work :) | 21:03 |
| mwhudson | well at least you don't have to argue with mr drepper any more | 21:03 |
| zyga | mwhudson: actually I don't know why I suggested to use the newer version of those flags | 21:03 |
| zyga | mwhudson: for the initial experiment rpath worked just as well | 21:03 |
| mwhudson | zyga: if you use RPATH, LD_LIBRARY_FLAGS is ignored | 21:04 |
| zyga | mwhudson: but AFAIK we don't need LD_LIBRARY_FLAGS for classic snaps | 21:04 |
| zyga | mwhudson: (for those that are linked properly) | 21:04 |
| mwhudson | oh heh this dude found the same thing as me http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/ | 21:04 |
| mwhudson | (and i'd read that post before too) | 21:05 |
| zyga | mwhudson: question: would it be possible to invoke the dnyamic linker to ask it to load an executable without rpath/dtrunpath? | 21:05 |
| zyga | mwhudson: e.g. to load /bin/true from the core snap that is just vanilla /bin/true in an odd location | 21:05 |
| mwhudson | zyga: i don't understand, sorry | 21:07 |
| mwhudson | zyga: you don't feel like writing something that adds DT_RUNPATH (and edits the ELF interpreter) to all binaries in the core snap? :) | 21:08 |
| mwhudson | (i presume in strict snaps the core snap is available at both / and /snap/core/current ?) | 21:09 |
| zyga | mwhudson: that's the problem actually, it's not | 21:09 |
| zyga | mwhudson: and we want one core snap, not two (one for classic and one for strict confinement) | 21:09 |
| zyga | mwhudson: in strict confinement core snap is / and you cannot read /snap/core/* | 21:09 |
| mwhudson | zyga: ah | 21:09 |
| mwhudson | zyga: fun times | 21:09 |
| zyga | mwhudson: in classic confinememt core snap is /snap/core/* and you can read anything | 21:09 |
| zyga | mwhudson: goal: make it possible to run stuff from the core snap in both cases | 21:10 |
| zyga | mwhudson: I was thinking about having snap-exec run the dynamic linker (even patched one since it's the one from the core snap) | 21:10 |
| mwhudson | zyga: don't see how that's possible | 21:10 |
| zyga | mwhudson: and load the application with some fancy defaults | 21:10 |
| mwhudson | oh | 21:10 |
| mwhudson | something like that might work | 21:10 |
| zyga | mwhudson: but that breaks down when we exec something from the core snap (e.g. we run bin/sh but then we run bin/ls) | 21:10 |
| zyga | mwhudson: because then the system (wrong) linker gets used | 21:11 |
| mwhudson | yeah | 21:11 |
| zyga | mwhudson: I don't know of a way to force "gimme that linker" somehow | 21:11 |
| zyga | mwhudson: unless | 21:11 |
| zyga | mwhudson: we do some hackery around exec in the libc that ships in the core snap | 21:11 |
| zyga | mwhudson: then it might just work allright | 21:11 |
| zyga | mwhudson: it'd be a simple case of path comparison, if starts with /snap -> use fancy linker mode | 21:11 |
| zyga | mwhudson: crazy? certainly! possible? maybe | 21:12 |
| mwhudson | can you bind mount something over /lib/ld-linux.so.2? | 21:12 |
| mwhudson | uh not that one | 21:12 |
| zyga | mwhudson: no, because in confinement: classic mode we don't have a mount namespace so everything in the system would sere that | 21:12 |
| zyga | mwhudson: we can but that's hurt us | 21:12 |
| mwhudson | yeah | 21:12 |
| zyga | mwhudson: and distros would be looking at us carefully if we bind mount over /lib for eveyone to see just to run | 21:12 |
| zyga | mwhudson: I think we need some linker work to make this play ball | 21:13 |
| mup | PR snapd#2749 opened: interfaces/default: allow mknod for regular files, pipes and sockets <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749> | 21:13 |
| mwhudson | i think so too | 21:13 |
| zyga | mwhudson: at the very least to fix nss issue | 21:13 |
| mwhudson | well also this running /snap/core/bin/ls uses the host elf interp thing | 21:14 |
| zyga | mwhudson: hmmm | 21:14 |
| mwhudson | no? | 21:14 |
| zyga | mwhudson: yes | 21:14 |
| zyga | mwhudson: that's true | 21:14 |
| mwhudson | this is all very confusing | 21:14 |
| zyga | mwhudson: unless we never allow that to happen | 21:14 |
| zyga | mwhudson: remember that we control all entry points | 21:14 |
| mwhudson | zyga: you mean, just don't let classic snaps exec things from the core snap? | 21:14 |
| zyga | mwhudson: snap-run -> snap-exec: we can run a patched dynamic linker at that stage | 21:14 |
| zyga | mwhudson: exec: we can use a patched glibc that uses an alternate linker if the target is in the core snap | 21:15 |
| zyga | mwhudson: I think we should not restrict what classic confinement snaps can run | 21:15 |
| zyga | mwhudson: it would limit their usefunless heavily IMHO | 21:15 |
| mwhudson | yeah it's a pretty blunt instrument | 21:15 |
| jdstrand | zyga: hey, yes | 21:16 |
| zyga | mwhudson: do you see any alternative ideas? | 21:16 |
| zyga | jdstrand: hey :) | 21:16 |
| zyga | jdstrand: I just commented on your PR :) | 21:16 |
| mwhudson | zyga: seccomp-bpf? :) | 21:16 |
| mwhudson | zyga: anyway, i think the nss issue is easier than the interpreter issue | 21:17 |
| zyga | mwhudson: hmmm, curious | 21:17 |
| mwhudson | zyga: "just" patch libc (well libdl) in the core snap to respect RUNPATH in the executable, like the docs say | 21:17 |
| zyga | mwhudson: how would that work? we'd attach a seccomp profile that patches exec? | 21:17 |
| mwhudson | zyga: yeah | 21:17 |
| mwhudson | zyga: i have no idea if that's easily possible | 21:18 |
| mwhudson | er -easily | 21:18 |
| mwhudson | zyga: i worry about statically linked go binaries :) | 21:18 |
| zyga | mwhudson: but taht profile carries across exec right? would it not clash if someone wanted to run something that already uses seccomp for other things? | 21:18 |
| zyga | mwhudson: oh, interesting | 21:18 |
| zyga | mwhudson: don't those use their own name resolver stack? | 21:18 |
| mwhudson | zyga: for the elf interpreter stuff i mean | 21:19 |
| zyga | jdstrand: if you could give me some feedback on the sc_must_stpcpy branch I would really appreciate it | 21:19 |
| zyga | mwhudson: mmmm | 21:19 |
| zyga | mwhudson: wait, what's the problem there? there are no libaries to cause issues | 21:19 |
| zyga | mwhudson: and and golang's dlopen just needs to be fixed somehow (if broken) | 21:19 |
| zyga | I must be missing something | 21:20 |
| zyga | jdstrand: is that branch changing our dependency on base seccomp version in any way? (both in kernel and in the userspace) | 21:20 |
| mwhudson | zyga: it's possible i am | 21:20 |
| mwhudson | zyga: this is all very confusing, and you've spent longer thinking about it than i | 21:21 |
| zyga | mwhudson: (offtopic, I find it funny that I just opened IRC by accident and joked about "garden elf" and here we are talking about this issue that's currently also close to my heart as I was working with sergiusens earlier trying to figure out what's going on) | 21:21 |
| zyga | mwhudson: (any) statically compiled binary will work OK (or not) but is beyond our control, if it includes a dynamic linker inside we also have no way to influence it | 21:22 |
| zyga | mwhudson: I was thinking about extending the auxilliary vector to set a bit that indicates a given process uses classic confinement | 21:23 |
| zyga | mwhudson: and that would change how linker behaves | 21:23 |
| blackboxsw | hi folks, question out of left field. I'm on trusty, how do I check the status of the snapd process and my snaps. I was accustomed to using systemd w/ "service snapd status" and "service snap.<snap_name> status" on xenial. | 21:24 |
| mwhudson | zyga: and what behaviour would it change ? | 21:24 |
| zyga | mwhudson: I think we could use it to change default search path | 21:24 |
| zyga | mwhudson: my goal would be to leverage that to have pre-compiled software (e.g. debs) work as classic confinement snaps | 21:25 |
| blackboxsw | I see snapd package on trusty pulls in systemd as a dependency, I'm just not sure how that shakes out as far as checking ths snap processes via tools like services, initctl etc. I *could* check ps easily enough, but I wondered what expected behavior is. | 21:25 |
| mwhudson | zyga: oh, so you wouldn't need to set DT_RUNPATH in the binaries in a classic snap? | 21:25 |
| zyga | blackboxsw: on 14.04 we have a deputy systemd | 21:25 |
| mwhudson | zyga: just the elf interpreter ? | 21:25 |
| zyga | mwhudson: exactly | 21:25 |
| zyga | mwhudson: because we probably cannot just (not sure) easily rewrite a random executable to have it "gain" runpath and a different dynamic linker path | 21:26 |
| mwhudson | well not even the elf interpreter, because you jam a custom interperter in via snap-exec | 21:26 |
| zyga | mwhudson: the dynamic linker path is also problematic but if we do it upstream it could work elsewhere too | 21:26 |
| zyga | mwhudson: yes, that's true | 21:26 |
| zyga | blackboxsw: and you should be able to use regular systemd commands to control services | 21:27 |
| mwhudson | and you'd also have a hook in exec that does if exe_path.startswith("/snap/core"): jam_custom_interp_in() | 21:27 |
| zyga | blackboxsw: there might be some bits missing; I don't know if journald is wired, for example | 21:27 |
| zyga | mwhudson: yes | 21:28 |
| mwhudson | zyga: well sounds crazy, and not inherently impossible | 21:28 |
| zyga | mwhudson: the idea with the extra bit in auxv is to have clean transitions from snaps to classic world | 21:28 |
| zyga | mwhudson: but perhaps we can do that with snap-exec each time and this is not required | 21:28 |
| zyga | mwhudson: (all transitions are out of snap world, snap-exec brings us back) | 21:29 |
| mwhudson | zyga: not if the classic snap just invokes /snap/core/bin/python3 directly? | 21:29 |
| zyga | mwhudson: that's true, I forgot about side-stepping the apps system | 21:30 |
| zyga | mwhudson: then we need patched glibc | 21:30 |
| zyga | mwhudson: or seccomp-bfp | 21:30 |
| zyga | mwhudson: I think that we will either 1) spec this and JFDI or 2) reconsider classic confinement | 21:30 |
| zyga | mwhudson: as right now the edges feel pretty sharp :/ | 21:31 |
| blackboxsw | zyga, thanks for the suggestion. yeah, what I'm seeing from trusty-proposed seems like it's missing a little bit of glue. I'll try digging a bit more, but running "service snapd status" errors with "unrecognized service" though I see /lib/systemd/system/snapd.service defined | 21:31 |
| zyga | blackboxsw: I think you want to talk to tvoss, he was working on this feature | 21:32 |
| mwhudson | zyga: yeah, in some ways the "mixed world" of classic snaps is trickier than isolated snaps | 21:32 |
| zyga | mwhudson: if we do the magic right it will seem easier | 21:33 |
| zyga | mwhudson: but I totally agree with what it is today | 21:33 |
| blackboxsw | good reference zyga thanks will continue the conversation with him. | 21:34 |
| tvoss | blackboxsw: o/ | 21:35 |
| blackboxsw | tvoss, isn't it 22:35? | 21:36 |
| sergiusens | mwhudson: zyga well I fixed all env var leaking for classic snaps (even PATH), use a little shebang trick to chose the right interp and added a way to provide your own python in stage for the plugin to use | 21:36 |
| tvoss | blackboxsw: so for snapd itself and services from snaps, systemctl should do the right thing | 21:36 |
| tvoss | blackboxsw: yup, it's 22:35 | 21:36 |
| blackboxsw | yowsa. | 21:36 |
| tvoss | blackboxsw: so systemd is not running as pid 1 on trusty, upstart is still the init system | 21:37 |
| tvoss | blackboxsw: so using sudo service will end up querying upstart, instead of systemd | 21:37 |
| blackboxsw | tvoss, ahh got it! thanks, looks like I needed "sudo" on trusty too | 21:37 |
| blackboxsw | without sudo it gives things like "No such interface" etc. | 21:37 |
| tvoss | hmmm, I can give that a spin tomorrow my morning, on my tablet right now | 21:38 |
| tvoss | I'll take a note, thanks for testing it out | 21:38 |
| blackboxsw | thanks for the response. tvoss. solved my initial hurdle | 21:39 |
| tvoss | blackboxsw: cool, later then :) | 21:39 |
| tvoss | o/ | 21:39 |
| blackboxsw | \o | 21:39 |
| sergiusens | mwhudson: if it helps http://paste.ubuntu.com/23895943/ | 21:40 |
| mup | PR snapd#2750 opened: interfaces/default: don't allow TIOCSTI ioctl <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2750> | 22:16 |
| mup | PR snapcraft#1091 closed: tests: add ubuntu user to sudoers on every adt platform <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1091> | 22:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!