| robru | anybody around to help me troubleshoot a snap? | 00:30 |
|---|---|---|
| mup | Bug #1623279 opened: [Errno 2] No such file or directory: '/home/robru/src/bileto.snap/stage/usr/share/locale/ku' <Snappy:New> <https://launchpad.net/bugs/1623279> | 00:48 |
| === mup_ is now known as mup | ||
| mup | PR snapcraft#793 closed: Unify python plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/793> | 02:25 |
| mup | PR snapcraft#794 closed: Improve lifecycle execution of steps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/794> | 02:49 |
| mup | PR snapcraft#797 opened: Use --dangerous when installing snaps in yakkety <Created by elopio> <https://github.com/snapcore/snapcraft/pull/797> | 05:52 |
| mup | PR snapd#1902 opened: tests: add new SNAP_IGNORE_SUDO_USER and set it for the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1902> | 06:12 |
| zyga | mvo: oh, you closed that already | 06:13 |
| zyga | mvo: quick question about qemu/spread, can we just use su instead? | 06:13 |
| mvo | zyga: yeah, currently thinking about fixing it directly in spread | 06:13 |
| mvo | zyga: sure, fire | 06:13 |
| zyga | mvo: so that linode and qemu behave the same way | 06:13 |
| mup | PR snapd#1902 closed: tests: add new SNAP_IGNORE_SUDO_USER and set it for the spread tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1902> | 06:14 |
| mvo | zyga: qemu and linode should behave the same, its just adhoc that is different | 06:14 |
| zyga | ah, I see | 06:14 |
| zyga | how are we using adhoc today? | 06:15 |
| mvo | zyga: inside the autopkgtest, its running the tests against localhost basicly | 06:15 |
| zyga | ah, I see | 06:17 |
| zyga | mvo: offtopic, do you know how can I get a yakkety image for the qemu backend easily? | 06:19 |
| mvo | zyga: yes | 06:21 |
| mvo | zyga: sudo apt install autopkgtest/xenial-backports | 06:21 |
| mvo | zyga: and adt-buildvm-ubuntu-cloud -r yakkety | 06:21 |
| zyga | ah, thanks | 06:21 |
| mvo | yw | 06:25 |
| dholbach | hey hey | 06:45 |
| * zyga zeros on the test breaks the remainder of the testing cycle | 07:09 | |
| mup | PR snapd#1903 opened: tests: ensure SUDO_{USER,GID} is unset in the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1903> | 07:40 |
| mup | PR snapd#1904 opened: tests: add debug out put to ubuntu-core-update-rollback-stresstest: <Created by mvo5> <https://github.com/snapcore/snapd/pull/1904> | 07:41 |
| mup | PR snapcraft#796 closed: Only discover dependencies once per file <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/796> | 07:58 |
| mup | PR snapd#1905 opened: snap: (re)add --force-dangerous compat option <Created by mvo5> <https://github.com/snapcore/snapd/pull/1905> | 08:12 |
| mup | PR snapd#1903 closed: tests: ensure SUDO_{USER,GID} is unset in the spread tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1903> | 08:17 |
| mup | PR snapd#1906 opened: CONTRIBUTING.md: remove integration-tests, include spread <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1906> | 08:28 |
| ogra_ | mvo, ok... expired key error fixed ... what a silly thing | 08:46 |
| ogra_ | mvo, do we know how long assetrtion keys are actually valid, this could really bite us for released images given that fixrtc sets the clock to the image creation date while it can not sync to a timeserver | 08:48 |
| ogra_ | if the expiration time is to shart they key might be expired | 08:48 |
| ogra_ | *short | 08:48 |
| mup | PR snapd#1907 opened: asserts: basic support for validation assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/1907> | 08:55 |
| mup | PR snapd#1905 closed: snap: (re)add --force-dangerous compat option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1905> | 08:56 |
| ogra_ | mwhudson, FYI, i just invalidated Bug #1623119 | 09:05 |
| mup | Bug #1623119: wlan setup done by console-conf not persistent <Snappy:Invalid> <nplan (Ubuntu):Invalid> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1623119> | 09:05 |
| mup | Bug #1623119 changed: wlan setup done by console-conf not persistent <Snappy:Invalid> <nplan (Ubuntu):Invalid> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1623119> | 09:06 |
| mwhudson | ogra_: ok, although i think the snapd behaviour is a bit unhelpful too | 09:09 |
| ogra_ | well, i dont think the job runs if it finished successfully | 09:10 |
| mwhudson | ogra_: https://github.com/snapcore/snapd/pull/1901 | 09:10 |
| mup | PR snapd#1901: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1901> | 09:10 |
| mwhudson | ogra_: true, will leave it to mvo to decide :-) | 09:10 |
| ogra_ | but your fix at least looks like a good safety net | 09:11 |
| mwhudson | ogra_: wow https://bugs.launchpad.net/snappy/+bug/1623125 looks like heaps of fun | 09:12 |
| mup | Bug #1623125: fixrtc script does not catch "Last mount time: n/a" string <Snappy:Triaged by ogra> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <https://launchpad.net/bugs/1623125> | 09:12 |
| * zyga finally figured out what is going on with snap-confine | 09:12 | |
| ogra_ | mwhudson, yeah, who would have thought that the ext4 devs put some useful thing in that field one day :P | 09:13 |
| ogra_ | it used to be the epoch or empty in the past ... the script deals with both ... just not with a funny string | 09:14 |
| ogra_ | fun fact "n/a" translates to Feb 11 (no idea which year) if handed to that date command call :) | 09:15 |
| mup | PR snapd#1908 opened: tests/lib/prepare.sh: test that classic does not setting bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/1908> | 09:16 |
| ogra_ | BOOO ! | 09:17 |
| ogra_ | console-conf doesnt see my wlan device on the pi3 ! | 09:18 |
| ogra_ | yeah, even after a reboot ... :( | 09:20 |
| ogra_ | mvo, hmm, this is an interesting one: http://paste.ubuntu.com/23177205/ ... i'm greeted with a reboot message on first login ... there were no updates though | 09:27 |
| mup | PR snapd#1748 closed: asserts: basic support for validation assertion <Created by ralsina> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1748> | 09:28 |
| mup | PR snapcraft#798 opened: Replace uses of copy with dump <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/798> | 09:28 |
| mup | PR snapd#1837 closed: asserts: add refresh-control header to snap-declaration assertion <Created by ralsina> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1837> | 09:44 |
| mup | PR snapd#1909 opened: snap: fix SNAP* environment merging in `snap run` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1909> | 09:50 |
| ogra_ | hmpf | 09:51 |
| ogra_ | and this time i'm dropped into console-conf after reboot even though the system was already configured fine | 09:51 |
| ogra_ | lol ... and now i get wlan config as an option | 09:51 |
| ogra_ | wow this is buggy | 09:52 |
| ogra_ | oh man | 09:53 |
| ogra_ | and console-conf wants to re-create the already existing user ... no way to skip the user part | 09:53 |
| mvo | ogra_: iz fine, just add me to your machine ,) | 09:53 |
| ogra_ | haha | 09:53 |
| ogra_ | error: bad user result: cannot create user "ogra@ubuntu.com": Get | 09:54 |
| ogra_ | https://login.ubuntu.com/api/v2/keys/ogra%40ubuntu.com: dial tcp: lookup | 09:54 |
| ogra_ | login.ubuntu.com: no such host | 09:54 |
| ogra_ | oh, lovely | 09:54 |
| ogra_ | and even though console-conf told me it configured the wlan it seems it didnt | 09:54 |
| ogra_ | ok, so i get a console-conf on second boot and cant get out of it anymore | 09:55 |
| ogra_ | heh | 09:56 |
| ogra_ | and i can log in with the user creasted at the former boot | 09:57 |
| ogra_ | seems console-conf really doesnt get along with two interfaces | 10:00 |
| mup | PR snapd#1910 opened: spread.yaml: don't assume LANG is set <Created by chipaca> <https://github.com/snapcore/snapd/pull/1910> | 10:00 |
| ogra_ | now the network config constantly times out ... it seems to try to use the wired NIC even though that was set to "dont use" | 10:02 |
| ogra_ | ok, switching back to wired and completely turning off wlan now gets me to | 10:05 |
| ogra_ | error: bad user result: cannot create user ogra: adduser failed with | 10:05 |
| ogra_ | exit status 1: adduser: The user `ogra' already exists. | 10:05 |
| ogra_ | and no way to ever get out of it again | 10:05 |
| ogra_ | cancel just gets me back to the start page of console-conf | 10:05 |
| ogra_ | crazyly broken | 10:06 |
| * ogra_ takes a break to go crying in a corner | 10:07 | |
| === oSoMoN_ is now known as oSoMoN | ||
| mup | PR snapd#1900 closed: interfaces: miscellaneous policy updates for default, browser-support and camera <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1900> | 10:21 |
| mup | PR snapd#1897 closed: snap: run all tests with gpg2 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1897> | 10:25 |
| mup | PR snapd#1907 closed: asserts: basic support for validation assertion and refresh-control <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1907> | 10:25 |
| mup | PR snapd#1911 opened: snap: add additional checks for snap run symlinks <Created by mvo5> <https://github.com/snapcore/snapd/pull/1911> | 10:32 |
| zyga | woooot | 10:38 |
| zyga | \\o | 10:38 |
| zyga | o// | 10:38 |
| zyga | \o/ | 10:38 |
| mup | PR snapd#1908 closed: tests/lib/prepare.sh: test that classic does not setting bootvars <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1908> | 10:38 |
| abeato | mvo, is there any reason for which a devmode snap would get ECONNREFUSED when trying to connect to a UNIX socket? | 11:03 |
| popey | How would one snap an application which has both python requirements.txt, but is also a node app? have two parts referencing the same source, one python2 plugin, one nodejs plugin? | 11:06 |
| mup | PR snapd#1904 closed: tests: add debug out put to ubuntu-core-update-rollback-stresstest: <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1904> | 11:08 |
| zyga | mvo: https://github.com/snapcore/snap-confine/pull/141/files | 11:09 |
| mup | PR snap-confine#141: Ensure that parent is alive after installing PR_SET_PDEATHSIG <Created by zyga> <https://github.com/snapcore/snap-confine/pull/141> | 11:09 |
| zyga | mvo: I fixed ns-sharing to work in spread now, I'll propose a few separate fixes for review | 11:09 |
| zyga | mvo: this is the first one, feedback welcome1 | 11:09 |
| zyga | jdstrand, tyhicks: ^^ | 11:10 |
| mup | PR snapd#1901 closed: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1901> | 11:10 |
| mup | PR snapd#1891 closed: doscs: add create-user documentation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1891> | 11:12 |
| mup | PR snapd#1896 closed: cmd/snap: match UX document for message when buying without login <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1896> | 11:12 |
| zyga | https://github.com/snapcore/snap-confine/pull/142 | 11:21 |
| mup | PR snap-confine#142: Add sanity timeouts <Created by zyga> <https://github.com/snapcore/snap-confine/pull/142> | 11:21 |
| zyga | https://github.com/snapcore/snap-confine/pull/143 | 11:28 |
| mup | PR snap-confine#143: Don't assume /run/snapd/ns can be removed <Created by zyga> <https://github.com/snapcore/snap-confine/pull/143> | 11:28 |
| zyga | https://github.com/snapcore/snap-confine/pull/144 | 11:29 |
| mup | PR snap-confine#144: Ensure that snap-confine is dead after each test terminates <Created by zyga> <https://github.com/snapcore/snap-confine/pull/144> | 11:29 |
| zyga | tyhicks, jdstrand: around? :) | 11:31 |
| zyga | spread-in-qemu and local http proxy saved me 7GB of traffic over the last 24 hours :) | 11:37 |
| mup | PR snapd#1912 opened: cmd/snap: do runtime linting of descriptions <Created by chipaca> <https://github.com/snapcore/snapd/pull/1912> | 11:48 |
| ogra_ | mvo, ugh ... | 12:12 |
| ogra_ | mvo, just testing your re-compressed pi3 image here ... | 12:13 |
| ogra_ | mvo, did you actually only re-compress it or is this a complete new ubuntu-image build ? | 12:13 |
| ogra_ | mvo, regardless ... it seems broken | 12:15 |
| jdstrand | zyga: hi! | 12:23 |
| zyga | jdstrand: hey | 12:27 |
| zyga | jdstrand: I managed to get ns-sharing to work on in spread now | 12:27 |
| zyga | jdstrand: I posted some patches | 12:27 |
| jdstrand | nice! | 12:27 |
| jdstrand | I tried to respond to one of them when I was out. curous what github did with it :) | 12:28 |
| jdstrand | curious even | 12:28 |
| zyga | jdstrand: it did the right thing | 12:29 |
| zyga | jdstrand: I saw that reply, github is pretty good at this stuff | 12:29 |
| zyga | jdstrand: this is the essential one: https://github.com/snapcore/snap-confine/pull/141 | 12:30 |
| mup | PR snap-confine#141: Ensure that parent is alive after installing PR_SET_PDEATHSIG <Created by zyga> <https://github.com/snapcore/snap-confine/pull/141> | 12:30 |
| zyga | jdstrand: if this lands I can propose the real thing and it should be green | 12:30 |
| zyga | jdstrand: debugging this I also implemented https://github.com/snapcore/snap-confine/pull/142 | 12:30 |
| mup | PR snap-confine#142: Add sanity timeouts <Created by zyga> <https://github.com/snapcore/snap-confine/pull/142> | 12:30 |
| zyga | jdstrand: though I don't believe the use of this patch (and a separate tiny patch that puts it arounf flock() is really required | 12:31 |
| zyga | jdstrand: still it is a 'death man hand' kind of failsafe | 12:31 |
| zyga | jdstrand: I added qemu spread support so if you have recent spread (not installed as a snap) this makes testing far better | 12:34 |
| ogra_ | cprov, the publishing bug in the store doesnt seem to actually be related to a long revision history, i did re-builds of pi2-kernel and dragonboard-kernel yesterday which both have only seen a few revisions yet (pi2 is at 14, dragonboard at 9) ... and had to do the unpublish/publish dance to make them seen | 12:43 |
| cprov | ogra_: you are right, the problem is on the snap-release endpoint itself | 12:44 |
| ogra_ | ah, so already known by you ? then its fine ... | 12:44 |
| * ogra_ just wanted to report the new data point | 12:44 | |
| cprov | ogra_: the fix is on its way, I've literally just isolated it | 12:44 |
| mup | PR snapd#1899 closed: store: don't discard error body from request device session call <Created by emgee> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1899> | 12:45 |
| ogra_ | i just had not seen it on other packages before ... | 12:45 |
| cprov | ogra_: thanks for adding more info on this (what a nightmare bug!) | 12:45 |
| ogra_ | heh, yeah | 12:45 |
| mup | PR snapd#1906 closed: CONTRIBUTING.md: remove integration-tests, include spread <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1906> | 12:46 |
| * ogra_ points mvo to his ping from 30min ago ... | 12:49 | |
| zyga | jdstrand: can I merge 141 | 12:49 |
| * ogra_ feels ignored today :( | 12:50 | |
| zyga | ogra_: o/ | 12:50 |
| ogra_ | :D | 12:50 |
| jdstrand | zyga: it's funny that I read 141 before your alarm branch and I came to the same conclusion :) | 12:50 |
| zyga | jdstrand: :-) there is some nice tricky code around | 12:51 |
| jdstrand | zyga: so, if you are going to do the alarm, what is the benefit of doing the pid check since it is slightly flawed? | 12:51 |
| jdstrand | ie, why isn't the alarm check enough? | 12:52 |
| zyga | jdstrand: it's an early warning system where the parent just dies right away, the timeout is 3 seconds | 12:52 |
| mvo | ogra_: broken it what way? | 12:52 |
| mvo | ogra_: its a new build but its still based on the same beta images | 12:52 |
| zyga | jdstrand: it's not *so* flawed, AFAIR the pid namespace would have to overflow before the kernel would recycle process IDs | 12:52 |
| ogra_ | mvo, did you re-build it from scratch using a newer ubuntu-image ? | 12:52 |
| mvo | ogra_: beta channel content | 12:52 |
| zyga | jdstrand: so the check is immediate and good enough | 12:52 |
| zyga | (as in, not broken totally, but not sufficient( | 12:53 |
| jdstrand | zyga: I guess there is no harm if the pid is reused. that process won't send the signal and then the alarm will hit | 12:53 |
| mvo | ogra_: its a fresh build | 12:53 |
| zyga | jdstrand: I wonder if there's a way to avoid that altogether with a pipe, after all, we'd get EPIPE on the read instantly | 12:53 |
| ogra_ | mvo, right, but you used the new ubuntu-image for it ... so the rootfs doesnt get loop mounted and has now the same fixrtc bug that i fixed tonight | 12:53 |
| zyga | jdstrand: (and eventfd had one task, make the use of the pipe obsolete, eh :-( | 12:53 |
| jdstrand | pipe goes back farther too.. | 12:54 |
| mvo | ogra_: oh, I see, hm, hm. what is the fix? a new initramfs-tools in the beta channel? | 12:54 |
| ogra_ | mvo, either you re-build using an ubuntu-image from before the mtools fix landed or we promote the new kernel to beta and do a re-build ... the current image on cdimage will fall over | 12:54 |
| fgimenez | zyga, could you please take a look at https://github.com/snapcore/snapd/pull/1640 when you have a minute? it seems that i'm approaching gsettings interface testing the wrong way | 12:54 |
| mup | PR snapd#1640: tests: add gsettings interface spread test <Decaying> <Reviewed> <Created by fgimenez> <Conflict> <https://github.com/snapcore/snapd/pull/1640> | 12:54 |
| zyga | fgimenez: I saw that but I didn't reply yet, I'll make sure to reply today | 12:54 |
| ogra_ | mvo, right, new initrd is in all the kernel snaps in edge already ... since thats the only change i think we can just promote them | 12:54 |
| mvo | ogra_: lets do a new image with a new kernel then and we also reduce the image size | 12:54 |
| fgimenez | zyga, cool thanks! :) | 12:54 |
| jdstrand | zyga: I don't think you need to move to pipe, at least not for this and not today. I'll comment in the PR | 12:55 |
| mvo | ogra_: yeah, lets do it, could you please delete the pi3 image from nusakan and trigger the mirror sync? | 12:55 |
| ogra_ | doing so | 12:55 |
| ogra_ | done | 12:56 |
| ogra_ | mvo, both kernels published to beta | 12:58 |
| jdstrand | zyga: commented | 12:58 |
| === chihchun is now known as chihchun_afk | ||
| zyga | jdstrand: thank you, will do | 13:00 |
| mup | PR snapcraft#799 opened: Load project information in one location <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/799> | 13:04 |
| sitter | ahoy ahoy | 13:11 |
| sitter | I am currently wondering how, if at all, one would share compiled artifacts across snaps at build time. example of the day: we make a kde-frameworks content snap, we'd then want to build an app using that snap. the problem is at build time we'd have to have access to the content to use headers and libraries. | 13:13 |
| mhall119 | zyga: kyrofa ^^ can you help sitter please? | 13:22 |
| * zyga looks | 13:29 | |
| zyga | sitter: hey | 13:29 |
| popey | sergiusens: do you have an ETA for snapcraft 2.17 in Xenial? | 13:29 |
| zyga | sitter: I believe sergiusens has an idea about this, he was working on the design | 13:29 |
| popey | (morning btw) | 13:29 |
| popey | zyga: could sitter push his compiled artifacts to a ppa/repo and just pull that in as a build-package in snaps? | 13:33 |
| popey | as an interim | 13:33 |
| zyga | popey: there are many ideas that are possible, sergiusens spent a lot of time on the design of this (as it affects snapcraft) and I believe he's the right person to talk to | 13:34 |
| popey | okay | 13:35 |
| zyga | jdstrand: this is the key branch, if this lands I'll be supper happy: https://github.com/snapcore/snap-confine/pull/145 | 13:44 |
| mup | PR snap-confine#145: Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/145> | 13:44 |
| mup | PR snapcraft#800 opened: LP: #1623509 fix to install of deps in package.json <Created by jonathon-love> <https://github.com/snapcore/snapcraft/pull/800> | 13:49 |
| mup | Bug #1574851 changed: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851> | 13:50 |
| mhall119 | popey: zyga: are build-packages copied into stage and prime directories? | 14:00 |
| mhall119 | if not, then that is a solution | 14:00 |
| zyga | mhall119: stage-packages are copied, build-packages are just installed on the host AFAIR | 14:00 |
| popey | indeed | 14:01 |
| mhall119 | sitter: ^^ would that work for you? | 14:01 |
| mhall119 | basically include your -dev packages from the archives or PPA in build-packages in your snapcraft.yaml, that way your application's build-time process can see them, but they won't put anything into your snap | 14:02 |
| sitter | mhall119, zyga: thanks that could work | 14:04 |
| sitter | I'll give it a stab tomorrow | 14:04 |
| zyga | jdstrand: refreshed https://github.com/snapcore/snap-confine/pull/142 | 14:10 |
| mup | PR snap-confine#142: Add sanity timeouts <Created by zyga> <https://github.com/snapcore/snap-confine/pull/142> | 14:10 |
| zyga | jdstrand: if it goes green let's land and use it :) | 14:10 |
| jdstrand | zyga: fyi, I've started looking at 145. I really want to tear it apart though and I have an appoint in 30 minutes, but I will be looking at this with top priority after that | 14:12 |
| zyga | jdstrand: I need to leave in an hour | 14:13 |
| zyga | jdstrand: if you can tighten the profile that would help me a lot | 14:13 |
| zyga | jdstrand: I can propose a small branch on top of the sanity timeout branch that actually uses it in three places | 14:14 |
| zyga | jdstrand: then I think we are good to seriously consider landing 145 | 14:14 |
| zyga | jdstrand: I'll be back in the evening (~5 hours from now) so I think we can still sync today | 14:14 |
| jdstrand | zyga: in my tear-apart I'll look at the profile | 14:15 |
| zyga | jdstrand: thank you | 14:15 |
| zyga | jdstrand: as an extra thing to think about, what about cgroups (nothing tests that today) | 14:15 |
| zyga | jdstrand: I'll add a pile of spread tests before this is relased but I didn't want to clutter the pull request with them | 14:16 |
| jdstrand | zyga: I added spread tests for that some time ago? did you mean something else? | 14:16 |
| zyga | jdstrand: I mean spread tests for ns sharing specifically | 14:16 |
| zyga | jdstrand: I have one simple test and I have some more in the works (e.g. a stress test that runs lots of concurrent copies of snap confine and checks that they all finish with the same NS identifier | 14:16 |
| jdstrand | I'm sorry, I'm having a hard time changing gears | 14:17 |
| zyga | jdstrand: hmm? | 14:17 |
| jdstrand | what is the interaction with cgroups you are concerned about? | 14:17 |
| jdstrand | because the sysfs is mounted in there? | 14:17 |
| dbarth | hey guys, i'm having issues doing a "snap login" without sudo (snapd from edge, running on xenial) | 14:18 |
| zyga | jdstrand: I don't really know but my point is that there's little testing for ns sharing *and* cgroup usage, which is not default | 14:18 |
| zyga | jdstrand: e.g. one process has a cgroup and another doesn't but they share the ns, does the order in which they start matter? | 14:18 |
| jdstrand | I see. I'll take a look at that too | 14:19 |
| kyrofa | sitter, zyga mhall119 indeed, I believe sergiusens's plan is to provide a way to make a "-dev" snap that can be used to build against | 14:29 |
| kgunn | kyrofa: so i was reading up on | 14:29 |
| kgunn | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1586465 | 14:29 |
| mup | Bug #1586465: Add support for hooks <Canonical Click Reviewers tools:New> <Snapcraft:New> <snapd (Ubuntu):Fix Committed by kyrofa> <https://launchpad.net/bugs/1586465> | 14:29 |
| kgunn | kyrofa: do you consider that "done" enough that in next release u8 app folk could attempt to use for their own hooks? | 14:30 |
| kyrofa | Hey kgunn! | 14:33 |
| kyrofa | Yeah, the machinery is all there, add away! | 14:34 |
| kyrofa | kgunn, that's what I'm working on at the moment, too | 14:34 |
| kgunn | kyrofa: that==? | 14:34 |
| kyrofa | Finally adding a hook | 14:34 |
| kgunn | actually trying to use? | 14:34 |
| kgunn | ah noice! | 14:35 |
| kyrofa | kgunn, I'll see if I can add some documentation about adding hooks | 14:39 |
| kgunn | tedg: ^ | 14:39 |
| kgunn | thanks kyrofa | 14:40 |
| kyrofa | Good to know there's interest | 14:40 |
| tedg | Cool, docs would be great. | 14:41 |
| qengho | jdstrand: is there a bug report tracking the refresh-while-running problem? | 14:49 |
| mup | PR snapd#1913 opened: daemon,store: move store login user logic to store <Created by matiasb> <https://github.com/snapcore/snapd/pull/1913> | 14:54 |
| kyrofa | kgunn, tedg: pstolowski has been learning that as well | 14:55 |
| tedg | kyrofa: Snapcraft support? I don't see anything in the snapcraft.yaml schema: https://github.com/snapcore/snapcraft/blob/master/schema/snapcraft.yaml | 14:57 |
| kyrofa | tedg, yeah that's missing at the moment. Probably my next task | 14:57 |
| kyrofa | tedg, but it's not too bad to get working without | 14:58 |
| tedg | kyrofa: Sure without docs is harder than without snapcraft support ;-) | 14:59 |
| kyrofa | tedg, yeah I'll make a PR with the spec as well as a tutorial today | 15:00 |
| tedg | kyrofa: Great, thanks! | 15:00 |
| kyrofa | Thanks for asking! | 15:00 |
| mup | PR snapcraft#758 closed: Add an integration test for parts with filesets <Created by jocave> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/758> | 15:02 |
| mup | PR snapcraft#797 closed: Use --dangerous when installing snaps in yakkety <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/797> | 15:02 |
| pstolowski | kgunn, tedg yeah i'm learning that as well, working on my first hooks | 15:05 |
| mup | Bug #1623279 changed: [Errno 2] No such file or directory: '/home/robru/src/bileto.snap/stage/debian/source' <Snapcraft:New> <https://launchpad.net/bugs/1623279> | 15:15 |
| zyga | jdstrand: https://github.com/snapcore/snap-confine/pull/146/files enables sanity timeouts | 15:19 |
| mup | PR snap-confine#146: Use sanity timeouts around blocking operations <Created by zyga> <https://github.com/snapcore/snap-confine/pull/146> | 15:19 |
| zyga | jdstrand: I need to leave now | 15:19 |
| zyga | jdstrand: please ping me on telegram for urgent stuff | 15:19 |
| zyga | jdstrand: I'll talk to you later :-) | 15:19 |
| mup | PR snapd#1909 closed: snap: fix SNAP* environment merging in `snap run` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1909> | 15:49 |
| kgunn | jdstrand: hey, are you free enough to have a discussion on something interesting i'm experiencing with denials and mir ? | 16:07 |
| mup | PR snapd#1877 closed: many: maintain all snap configurations in state <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1877> | 16:28 |
| mup | PR snapd#1910 closed: spread.yaml: don't assume LANG is set <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1910> | 16:48 |
| kgunn | zyga: is it expected for devtools to have issue with arm64 ? | 17:26 |
| kgunn | or is it just me lacking arm64 gcc path on my host... | 17:27 |
| kgunn | ogra_: ^ ? | 17:27 |
| kgunn | workflow on snapd hacking on dragon | 17:27 |
| jdstrand | qengho: https://bugs.launchpad.net/snappy/+bug/1616650 | 17:30 |
| mup | Bug #1616650: snap refresh while command is running may cause issues <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616650> | 17:30 |
| jdstrand | kgunn: sorry, was afk | 17:30 |
| jdstrand | kgunn: what's up? | 17:31 |
| mup | PR snapcraft#799 closed: Load project information in one location <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/799> | 17:32 |
| jdstrand | kgunn: hey, did you see: | 17:45 |
| jdstrand | 12:30 < jdstrand> kgunn: sorry, was afk | 17:45 |
| jdstrand | 12:31 < jdstrand> kgunn: what's up? | 17:45 |
| mup | PR snapcraft#751 closed: python3 plugin: run setup.py in source subdir if such option exists <Created by yphus> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/751> | 17:47 |
| pmcgowan_ | if I fix one build dependency is there a way to avoid a full clean? | 17:55 |
| === magicalt1out is now known as magicaltrout | ||
| sergiusens | pmcgowan_ build dependencies should go in `build-packages` and if they are, then you should be mostly good | 17:59 |
| pmcgowan_ | sergiusens, they are but if I change that, it doesnt pick up the change and says the pull already ran | 18:00 |
| sergiusens | pmcgowan_ are you confusing `stage-packages` and `build-packages` by any chance? | 18:01 |
| pmcgowan_ | sergiusens, maybe | 18:02 |
| pmcgowan_ | the issue is the link doesnt find a lib it needs, and I am not sure why | 18:02 |
| pmcgowan_ | sergiusens, how do I see what libs are available | 18:03 |
| sergiusens | pmcgowan_ I don't parse that, what do you mean? | 18:03 |
| pmcgowan_ | sergiusens, does stage/usr/lib/x86_64-linux-gnu/ contain the libs available for the linker | 18:05 |
| pmcgowan_ | sergiusens, essentially, the package I spec'd is in the download dir, but the lib it provides isnt being found, trying to understand why | 18:11 |
| kgunn | jdstrand: hey, so here's my current experience....so we landed mir interface, all is well... | 18:19 |
| kgunn | i recently tested the mir-server snap on dragonboard and it worked fine, circa aug15 | 18:20 |
| kgunn | even confined | 18:20 |
| kgunn | however, i was testing in the last couple of days using the beta images | 18:20 |
| kgunn | on amd64..still works as expected, i mean i do see a sys_admin denial in syslog, but mir-server and mir-client can be connected and work just fine | 18:21 |
| kgunn | but on arm64...i now get denials when i install mir-server and it tries to run | 18:21 |
| kgunn | jdstrand: this is the output | 18:21 |
| kgunn | http://pastebin.ubuntu.com/23178449/ | 18:21 |
| kgunn | ...and yes, if i uninstall and re-install with devmode it works fine | 18:22 |
| mup | PR snapcraft#801 opened: In the busybox test, use the last installed data dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/801> | 18:23 |
| sergiusens | pmcgowan_ I might need to see your snapcraft.yaml; but yes stage/usr/lib/x86_64-linux-gnu/ is a library path available for the next part to build depending on it | 18:23 |
| pmcgowan_ | sergiusens, I think the qmake file may be wrong, but I still dont see the installed lib there | 18:24 |
| sergiusens | oh, qmake, pmcgowan_ heh, jhodapp came by with a very similar qmake problem | 18:26 |
| jhodapp | pmcgowan_, a qt-based app? | 18:28 |
| pmcgowan_ | jhodapp, yeah | 18:28 |
| pmcgowan_ | the build line doesnt look right to me | 18:28 |
| mup | PR snapcraft#790 closed: Reduces download time of `git clone` fetching just a single branch <Created by ehbello> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/790> | 18:29 |
| pmcgowan_ | jhodapp, I cant find the libs I should have for my stage-packages | 18:30 |
| jhodapp | pmcgowan_, have you seen the other qt-based examples out there? | 18:31 |
| pmcgowan_ | jhodapp, yeah some | 18:32 |
| jhodapp | pmcgowan_, ok...let me point you to mediaplayer-app's snapcraft.yaml I just did last week: https://code.launchpad.net/~phablet-team/mediaplayer-app/snap-it-up/+merge/305045 | 18:32 |
| elopio | joc_: plainbox tries to write to ~/.cache, and that fails in yakkety. Could you take a look? | 18:36 |
| elopio | https://bugs.launchpad.net/snapcraft/+bug/1623623 | 18:37 |
| mup | Bug #1623623: plainbox demo test fails in yakkety: Permission denied: '/home/ubuntu/.cache/plainbox/sessions' <Snapcraft:New> <https://launchpad.net/bugs/1623623> | 18:37 |
| elopio | I don't really understand why that works in xenial, should fail too. | 18:37 |
| jdstrand | kgunn: dac_override is almost always a result of a directory with incorrect permissions. eg, a root process trying to add a file to a non-root owned directory that doesn't have 'other' access (eg, 0755). ie, traditional unix permissions wouldn't allow it because the users don't match but because it's root and has CAP_DAC_OVERRIDE, the operation is allowed | 18:53 |
| jdstrand | kgunn: but the LSMs (ie, apparmor) mediate it | 18:54 |
| kgunn | jdstrand: so are you suggesting permissions changed on the fs between images? | 18:55 |
| jdstrand | kgunn: simple answer-- make sure that the process is running as the user you expect it to be and make sure the directories/files are all setup right for mir. comparing amd64 and arm64 images and running the commands in parallel should show the problem. strace would get you right there | 18:55 |
| jdstrand | kgunn: I am | 18:56 |
| jdstrand | or maybe on the arm64 core snap it is wrong but it is right on amd64 | 18:56 |
| jdstrand | or something | 18:56 |
| mup | Bug #1623626 opened: syslog messages include ubuntu-core-launcher instead of command name <Snappy:New> <https://launchpad.net/bugs/1623626> | 19:01 |
| kgunn | kgunn> jdstrand: i plan to do the strace exercise with amd64 vs arm64....but just sharing another data point | 19:20 |
| kgunn | so i added dac_override just to test on dragonboard, mir-server came up graphically...but mouse not responding | 19:21 |
| kgunn | b/c i also get other/new denials | 19:21 |
| kgunn | around run/udev/data | 19:22 |
| kgunn | http://pastebin.ubuntu.com/23179211/ | 19:22 |
| jdstrand | kgunn: we'll need to add these rules to the PermanentSlot for apparmor: | 19:23 |
| jdstrand | /run/udev/data/c13:[0-9]* r, | 19:23 |
| jdstrand | /run/udev/data/+input:input[0-9]* r, | 19:23 |
| kgunn | jdstrand: again, i'm just really surprised this worked a few weeks back | 19:24 |
| jdstrand | it's interesting because the c13 udev accesses came up in another thread | 19:24 |
| jdstrand | I wonder if something changed in one of the staged libraries | 19:25 |
| dobey | how exactly do updates work for snaps? i don't see any way to list/install updates with snap cli | 19:40 |
| awe | dobey, snap refresh? | 19:48 |
| awe | not sure if there's a way to list available updates first though? | 19:48 |
| dobey | ah | 19:49 |
| dobey | i guess all the terms for snappy have to be different from every other thing that came before, just because | 19:50 |
| pedronis | snap refresh --list | 19:51 |
| pedronis | lists available updates | 19:51 |
| === drizztbsd is now known as timothy | ||
| mup | PR snapcraft#802 opened: Add the TEST_STORE environment variable to the travis script <Created by elopio> <https://github.com/snapcore/snapcraft/pull/802> | 20:11 |
| mup | PR snapd#1914 opened: docs: add a little documentation on hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1914> | 20:47 |
| kyrofa | tedg, kgunn that ^^ is the basic spec | 20:51 |
| kgunn | thanks! | 20:51 |
| kyrofa | i.e. what you'd do from the snap developer perspective to take advantage of them | 20:51 |
| kyrofa | tedg, kgunn still working on the snapd developer side tutorial | 20:51 |
| tedg | kyrofa: By snapd, do you mean the slot or the plug side? | 20:52 |
| tedg | I guess we need to be able to do each of those. | 20:53 |
| tedg | Not sure there's a "snapd" side? | 20:53 |
| kyrofa | tedg, by snapd, I mean adding support for new hooks within snapd | 20:53 |
| kyrofa | tedg, as opposed to utilizing them within snaps | 20:53 |
| kyrofa | tedg, I suspect you need both | 20:53 |
| tedg | I don't think we need them in snapd, we just need them on both sides of the interface. | 20:54 |
| tedg | So like one would be in unity8 snap, and one would be in teh app snap. | 20:54 |
| kyrofa | tedg, ah, so all you care about are interface hooks? Then yeah, those are being worked on | 20:54 |
| kyrofa | By pstolowski (not sure if I got that right without tab completion :P ) | 20:54 |
| kyrofa | He's adding support for them within snapd, so that doc ^^ is really what you need then. Nice | 20:55 |
| tedg | Ah, okay, yeah that's more what we need. | 20:55 |
| kyrofa | He's also adding snapctl subcommands to get interface attributes | 20:55 |
| kyrofa | As he makes progress I'll make sure that document is updated | 20:55 |
| tedg | kyrofa: Is there any doc on the lifecycle of the various hooks? Like when they run with regards to the snap being marked active, for instance. | 20:55 |
| kyrofa | tedg, that's what I hope that document will be, once we actually have the hooks implemented in snapd | 20:56 |
| tedg | kyrofa: Okay, cool. | 20:56 |
| tedg | That's what I'm worried about, as that was really sadly missed in Juju | 20:56 |
| kyrofa | tedg, yeah, the interface hooks are again still a work in progress | 20:57 |
| tedg | kyrofa: Then on the snapcraft side I imagine we'll hook a command up to a hook in someway? | 20:57 |
| kyrofa | brb, someone at the door | 20:57 |
| awe | anybody know if there's a way to get snapcraft autotools to automatically use "-g" and "-O2" or do I need to hack my Makefile? | 21:00 |
| tedg | awe: snapcraft help autotools, lists configureflags | 21:01 |
| tedg | Sorry, configflags | 21:01 |
| awe | yup | 21:02 |
| awe | I need CFLAGS | 21:02 |
| awe | ;)- | 21:02 |
| awe | discussing on rocket atm | 21:02 |
| tedg | awe: Usage: ./configure [OPTION]... [VAR=VALUE]... | 21:03 |
| elopio | lool: these avahi tests need a lot of work. | 21:03 |
| lool | elopio: well the new impl is much shorter, so the tests ought to be much shorter too; the initial impl knew too much about mdns | 21:04 |
| mup | PR snapd#1915 opened: tests: add http_proxy to /etc/environment in the autopkgtest environment <Created by mvo5> <https://github.com/snapcore/snapd/pull/1915> | 21:04 |
| lool | elopio: but yes, they need as much work as the original file unfortunately | 21:04 |
| elopio | lool: yes, they were wrong to start with. But I don't know enough avahi to understand where to fake and what to check. | 21:05 |
| lool | elopio: so personally, I would ditch them all and add just a test for the gethostname logic | 21:06 |
| lool | elopio: to ensure localhost -> snapweb and .domain part is removed | 21:06 |
| lool | elopio: ideally, we'd also have an *integration* test setting up the network and making sure mdns starts when no multicast and works when intf comes up | 21:07 |
| lool | elopio: but frankly, if you look at avahi.go, you'll see we call two functions: mdns.NewMDNS() on startup, and _mdns.ScanInterfaces() regularly | 21:08 |
| lool | essentially consuming the whole mdns impl | 21:08 |
| lool | rather than knowing about 224., 127., ipv6 and what not | 21:08 |
| elopio | ideally, it's the Init function the one we test. And either msdn is easy to replace with a fake, or it can be run safely in unit tests. | 21:09 |
| elopio | I suppose we will go with a fake. Then that needs changes on the code. | 21:09 |
| kyrofa | tedg, yeah, I figured snapcraft will treat hooks as just special apps | 21:10 |
| awe | thanks tedg | 21:10 |
| awe | that works! | 21:10 |
| awe | ;D | 21:10 |
| lool | elopio: why would we want to build a testsuite for third-party code? | 21:11 |
| lool | oh you mean our Init? | 21:11 |
| elopio | yes. | 21:11 |
| tedg | np | 21:11 |
| tedg | kyrofa: Yeah, I think that makes sense, we just don't want to have magic directories so that we can build them with the same tools and reference the paths. | 21:12 |
| kyrofa | Yep | 21:12 |
| tsimonq2 | can you confirm with the lxqt package lynorian ? | 21:21 |
| tsimonq2 | whoops | 21:21 |
| tsimonq2 | sorry | 21:21 |
| mup | PR snapd#1912 closed: cmd/snap: do runtime linting of descriptions <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1912> | 21:23 |
| zyga | jdstrand: hey, did you have a chance to look at the namespace sharing branch? | 21:28 |
| zyga | ohh, cool, I see a comment 14 minutes ago :) | 21:28 |
| jdstrand | zyga: I've made a number of comments | 21:28 |
| zyga | jdstrand: I'll reproduce your observations on "ip netns add testnet" but I was wondering if you know what is the source of the permission denied error; Is it the kernel refusing to do something (like we had with the unshare -U as non-root user) or the process not having permission to do something using regular DAC | 21:31 |
| jdstrand | zyga: I don't know otoh, but I ran it as root and non-root. Note that 'ip netns add testnet' worked at one point. I just tried again here and see that it doesn't work with snap-confine 1.0.38-0ubuntu0.16.04.8 and snapd 2.14.2~16.04 on classic | 21:46 |
| jdstrand | zyga: I updated my comment in the PR to reflect that ^ | 21:48 |
| zyga | thank you | 21:51 |
| jdstrand | zyga: based on the dates in the bug, I'm going to guess this 'ip netns add testnet' stopped working when we switched to snap-confine | 21:51 |
| jdstrand | zyga: would it help if I downgraded to ubuntu-core-launcher? | 21:51 |
| jdstrand | zyga: test and let you know if it worked? | 21:52 |
| zyga | jdstrand: hmmm, you'd have to downgrade quite a bit | 21:52 |
| zyga | jdstrand: I guess it might be related to the particular directory | 21:52 |
| zyga | jdstrand: and before the major difference was in lack of chroot/pivot_root | 21:52 |
| jdstrand | yeah | 21:52 |
| zyga | jdstrand: doesn't the netns thing simply create a new net namespace and saves it, just like we do, somewhere in the filesystem? | 21:53 |
| jdstrand | that is what I was thinking might be it | 21:53 |
| zyga | jdstrand: perhaps it is simply saving it in a read-only location | 21:53 |
| zyga | jdstrand: a simple strace would answer that | 21:53 |
| jdstrand | zyga: it is in /run | 21:53 |
| jdstrand | zyga: /run/netns | 21:53 |
| zyga | so that *should* be okay | 21:53 |
| jdstrand | eg, on classic outside of any snaps | 21:53 |
| zyga | right, but /run is bind-mounted | 21:53 |
| jdstrand | sudo ip netns add testnet | 21:54 |
| jdstrand | $ ls -l /run/netns/ | 21:54 |
| jdstrand | total 0 | 21:54 |
| jdstrand | -r--r--r-- 1 root root 0 Sep 14 16:54 testnet | 21:54 |
| jdstrand | sorry, was just trying to show you what it does on classic | 21:54 |
| jdstrand | note that if I run that command without sudo: | 21:55 |
| zyga | right, I understand | 21:55 |
| jdstrand | $ ip netns add testnet | 21:55 |
| jdstrand | mount --make-shared /var/run/netns failed: Operation not permitted | 21:55 |
| zyga | I will need to experiment to see what the root cause is | 21:55 |
| zyga | jdstrand: could it be a capability that's missing? | 21:55 |
| zyga | er | 21:55 |
| zyga | jdstrand: is there any apparmor denial? | 21:55 |
| zyga | (I assume this is in devmode shell) | 21:56 |
| jdstrand | this is devmode | 21:56 |
| zyga | curious | 21:56 |
| zyga | ok, checking now | 21:56 |
| jdstrand | the open("/proc/self/ns/net"): Permission denied I'm guessing is another kernel gotcha that we didn't see yet | 21:57 |
| jdstrand | (ie, something non/under-documented) | 21:58 |
| zyga | jdstrand: the namespaces(7) manual page gives a false sense of completeness | 21:59 |
| jdstrand | yeah :( | 21:59 |
| zyga | I see the same thing | 22:00 |
| jdstrand | zyga: that said, I think there is a pretty solid clue in that without this PR, it still doesn't work with xenial-updates | 22:00 |
| jdstrand | so maybe all the namespaces bits are ok and it is pivot_root/mount options/shared vs private/etc thing | 22:01 |
| zyga | perhaps | 22:01 |
| zyga | I'll read the kernel code for nsfs | 22:01 |
| zyga | quick question: wrz 15 00:00:14 tower kernel: audit: type=1400 audit(1473890414.074:130): apparmor="ALLOWED" operation="file_mprotect" profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/unshare" name="/usr/bin/unshare" pid=13886 comm="unshare" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 22:02 |
| zyga | what is ouid=0? | 22:02 |
| jdstrand | owner uid | 22:02 |
| jdstrand | zyga: it is the process uid used for comparing with fsuid which is the file owner | 22:03 |
| tyhicks | jdstrand: fsuid is the fsuid of the current task | 22:07 |
| tyhicks | https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/security/apparmor/file.c#n61 | 22:08 |
| * zyga hugs cscope | 22:09 | |
| jdstrand | mey, I flipped it around | 22:10 |
| jdstrand | meh | 22:10 |
| zyga | if (!ns_capable(net->user_ns, CAP_SYS_ADMIN) || | 22:10 |
| zyga | !ns_capable(current_user_ns(), CAP_SYS_ADMIN)) | 22:10 |
| zyga | return -EPERM; | 22:10 |
| jdstrand | ouid is object uid (the file), and fsuid is the the uid used to check access to the fs | 22:11 |
| jdstrand | I've done that before. maybe this time it will stick :) | 22:11 |
| tyhicks | ouid is hard to remember | 22:12 |
| zyga | that's the only EPERM I can quickly see | 22:12 |
| jdstrand | jeez, I downgraded ubuntu-core-launcher and it isn't working :\ | 22:14 |
| * zyga has an idea | 22:16 | |
| zyga | jdstrand: so I can "unshare -n" from devmode snapd-hacker-toolbelt.busybox | 22:16 |
| zyga | (as root) | 22:17 |
| zyga | jdstrand: but it fails if I try to preserve the ns | 22:18 |
| jdstrand | zyga: fyi with ubuntu-core-launcher 1.0.27.1: http://paste.ubuntu.com/23179927/ | 22:20 |
| zyga | interesting | 22:21 |
| zyga | I guess at this point the kernel is our manual | 22:21 |
| jdstrand | I'm really surprised it isn't working with ubuntu-core-launcher since I very clearly had a working test case | 22:21 |
| zyga | jdstrand: are you sure that this was the test case? | 22:22 |
| zyga | jdstrand: hmm, I think I read something that may contain hints | 22:22 |
| jdstrand | zyga: https://bugs.launchpad.net/snappy/+bug/1611444/comments/8 | 22:23 |
| mup | Bug #1611444: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP <Snappy Launcher:In Progress by zyga> <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1611444> | 22:23 |
| zyga | hmm | 22:24 |
| zyga | interesting | 22:24 |
| * jdstrand reboots into an older kernel | 22:24 | |
| * zyga reads through util-linux source | 22:25 | |
| mup | PR snapcraft#803 opened: Do not run the bootstrap directory as a script (autotools plugin) <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/803> | 22:29 |
| jdstrand | booting into the release kernel didn't do it | 22:29 |
| jdstrand | (meaning, a kernel update didn't cause this) | 22:29 |
| zyga | right | 22:30 |
| zyga | jdstrand: is there any difference between "ip netns add testnet" and "unshare -n /run/$something/testnet" | 22:30 |
| jdstrand | zyga: I don't understand that command. /run/$something/testnet isn't a program | 22:33 |
| zyga | I mean "unshare -n /path/to/saved/net/ns" | 22:33 |
| zyga | if (!ns_capable(net->user_ns, CAP_SYS_ADMIN) || | 22:33 |
| zyga | !ns_capable(current_user_ns(), CAP_SYS_ADMIN)) | 22:33 |
| zyga | return -EPERM; | 22:33 |
| zyga | er, sorry | 22:33 |
| zyga | -n, --net[=file] | 22:33 |
| zyga | Unshare the network namespace. If file is specified then persistent namespace is created by | 22:33 |
| zyga | bind mount. | 22:33 |
| jdstrand | but the unshare program takes an program argument | 22:33 |
| zyga | Is it anything fundamentally different? | 22:33 |
| zyga | right but you can pass "true" | 22:33 |
| jdstrand | ok, let me just do bash | 22:34 |
| zyga | and it will just unshare that space and quit | 22:34 |
| jdstrand | sure | 22:34 |
| jdstrand | zyga: ok, so I did: | 22:35 |
| zyga | jdstrand: then we can use nsenter/unshare instead of the (probably more complex) ip netns as a test tool | 22:35 |
| jdstrand | sudo ip netns add testnet | 22:35 |
| jdstrand | sudo hello-world.sh # installed in devmode | 22:35 |
| jdstrand | unshare --net=/run/netns/testnet true || echo yes | 22:35 |
| jdstrand | yes | 22:35 |
| jdstrand | is that what you wanted to test? | 22:36 |
| zyga | yes :-( | 22:36 |
| zyga | do you have any theory or ideas as to why the kernel is rejecting this? | 22:36 |
| jdstrand | no | 22:37 |
| jdstrand | I'd like to identify the point at which things were working with my test case | 22:37 |
| zyga | yes, that would be very useful | 22:37 |
| zyga | jdstrand: I wonder if vanilla 16.04 install works | 22:38 |
| zyga | that might be easy to test from a live media and a vm | 22:38 |
| zyga | if it wasn't past midnight I'd check that | 22:38 |
| jdstrand | yeah, you should go to bed | 22:41 |
| jdstrand | I have a school thing in a few minutes anyway | 22:42 |
| zyga | I'll catch you tomorrow; I'll keep experimenting tomorrow | 22:42 |
| jdstrand | I wonder if I was doing this in an old all snaps vm | 22:43 |
| zyga | hmm | 22:43 |
| zyga | so no pivot root | 22:43 |
| zyga | that's "easy" to check | 22:43 |
| zyga | I wonder if pivot vs chroot matters as well | 22:43 |
| jdstrand | I have a vm from june 24 here | 22:44 |
| * jdstrand tries | 22:44 | |
| zyga | jdstrand: one thing that might be a factor is that /run is now a shared bind mount | 22:48 |
| zyga | jdstrand: instead of the vanilla /run which is ... | 22:48 |
| jdstrand | so, I'm totally not crazy: https://www.mail-archive.com/snapcraft@lists.ubuntu.com/msg00546.html | 22:48 |
| jdstrand | yet, open("/proc/self/ns/net"): Permission denied | 22:49 |
| zyga | did systemd change? | 22:49 |
| zyga | 23 25 0:19 / /run rw,nosuid,noexec,relatime shared:5 - tmpfs tmpfs rw,size=818576k,mode=755 | 22:49 |
| zyga | so even on the "outside" /run is shared with something | 22:49 |
| jdstrand | this is on an image from months ago | 22:49 |
| * zyga never knows how to find *all* mount entries | 22:50 | |
| zyga | (i.e. what is "5" from the quote above) | 22:50 |
| wililupy | Question: Make sure I have this right for using ubuntu-image. If I need to build an image with a custom kernel snap, I can create a new assertion model .json, point the kernel parameter to that, sign it, and all is good? | 22:50 |
| wililupy | Also, if I want to add other snaps to the image, is there a value for the assertion model for that? | 22:51 |
| zyga | jdstrand: so at some point in time this worked | 22:51 |
| jdstrand | zyga: I came across this the other day: findmnt -o+PROPAGATION | 22:51 |
| jdstrand | zyga: yes, and not just cause I remember it this way :) | 22:51 |
| zyga | omg | 22:51 |
| zyga | the things I find out :) | 22:51 |
| zyga | jdstrand: but that still doesn't show me mount entry with id 5 | 22:52 |
| zyga | in fact, my current shell process doesn't have that entry | 22:52 |
| zyga | but it still exists and perahs one of the processes has acess to it | 22:52 |
| jdstrand | zyga: '5' is the peer group | 22:52 |
| zyga | peer group or peer id? | 22:52 |
| zyga | I mean, should I match this against the 1st column of mountinfo? | 22:52 |
| jdstrand | no | 22:53 |
| jdstrand | well, let me double check that | 22:53 |
| jdstrand | https://www.kernel.org/doc/Documentation/filesystems/proc.txt | 22:53 |
| zyga | jdstrand: this is also in mountinfo.h in snap-confine btw | 22:54 |
| jdstrand | those are the mount ID and parent IDs | 22:54 |
| jdstrand | that are different than the peer group in column 7 | 22:54 |
| jdstrand | https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt, section 5a | 22:54 |
| zyga | ah, interesting | 22:55 |
| jdstrand | I suspect the findmnt command is looking at the perr group to organize things | 22:55 |
| kallisti5 | so.. any timeline on being able to generate new snappy core images? | 22:56 |
| kallisti5 | last I checked the tool gave a neat "someday" response :P | 22:56 |
| zyga | (*) X is the closest dominant peer group under the process's root. If | 22:57 |
| zyga | X is the immediate master of the mount, or if there's no dominant peer | 22:57 |
| zyga | group under the same root, then only the "master:X" field is present | 22:57 |
| zyga | and not the "propagate_from:X" field. | 22:57 |
| * tsimonq2 bets elopio saw an nginx-related tweet and decided to snap it | 22:59 | |
| elopio | tsimonq2: even better, I met somebody that works at nginx. | 23:04 |
| tsimonq2 | gosh darnit | 23:04 |
| tsimonq2 | :P | 23:04 |
| * zyga -> EOD | 23:09 | |
| jdstrand | bye zyga :) | 23:10 |
| mup | PR snapcraft#801 closed: In the busybox test, use the last installed data dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/801> | 23:17 |
| mup | PR snapcraft#798 closed: Replace uses of copy with dump <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/798> | 23:29 |
| wililupy | How do I use snapcraft to delete a key I registered? | 23:41 |
| wililupy | I'm getting a weird error when I sign my assertion, and I think its due that I forgot to branch 2.17 for snapcraft and used it to register my key... :/ | 23:47 |
| wililupy | snapcraft revoke-key default does not work | 23:54 |
| wililupy | This is the error I'm getting: error: cannot assemble assertion model: "timestamp" header is not a RFC3339 date: parsing time "$(date -Iseconds --utc)" as "2006-01-02T15:04:05Z07:00": cannot parse "$(date -Iseconds --utc)" as "2006" | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!