=== arosales_ is now known as arosales === coreycb_ is now known as coreycb === plars_ is now known as plars === oh4_ is now known as oh4 === chihchun is now known as chihchun_afk === internethulksvij is now known as svij [06:23] PR snapcraft#1413 opened: core: minimal windows support === chihchun_afk is now known as chihchun [06:59] PR snapcraft#1414 opened: cmake plugin: call the cmake using build dir as source [07:49] jjohansen: hey [07:49] jjohansen: I'm working on a larger tool patch for for aa-binary-policy-inspector [07:49] jjohansen: should be out by the end of the week [07:49] jjohansen: I sent some smallish patches to the ML and you acked one (thank you!) [07:50] jjohansen: if you have a moment could you look at the remaining two please? [07:50] * zyga-ubuntu wonders where Chipaca might be [07:51] fgimenez: hey [07:51] I have a thing I'd like to discuss with you [07:52] hi zyga-ubuntu [07:52] fgimenez: last night we had a PR that was fixing a bug in nested re-exec [07:52] fgimenez: and I saw the upgrade/basic test fail on debian [07:52] fgimenez: it failed a few times in a row [07:53] fgimenez: the error was about /usr/lib/snapd/snap-update-ns not being there (it's not a part of the stable package in debian) [07:53] fgimenez: the test just passed on both qemu and linode today [07:53] fgimenez: without any changes in the PR [07:53] zyga-ubuntu: sounds bad [07:53] fgimenez: and here's the question, do you know of any store quirks that could explain this? [07:53] fgimenez: (normally we should execute snap-update-ns from the core snap) [07:54] zyga-ubuntu: nope afaik, do we have a log of the failed builds? [07:54] fgimenez: I'm running it again a few more times just to be sure it's not a race [07:54] fgimenez: (well, to be more convinced, not sure) [07:54] fgimenez: let me check, but I think I killed it :/ [07:54] yeah, I killed it [07:54] zyga-ubuntu: i'll try to reproduce too, not sure if upgrade/basic has been always enabled for debian [07:54] let's see if it passes now [07:54] it has [07:55] remember that refresh --beta core thing we did just for debian? [07:55] zyga-ubuntu: np, let's see if we can get it to fail again [07:55] when the stable channel was somewhat broken there? [07:55] zyga-ubuntu: ah yep [07:55] I'm trying to understand what changed since last evening [07:55] and since the branch did not, it could point towards the store [07:56] zyga-ubuntu: makes sense, is there an apt upgrade in the upgrade/basic test? maybe the debian unstable repo could have changed too [07:57] fgimenez: ah, interesting question, let me check [07:58] fgimenez: according to https://packages.debian.org/sid/snapd it seems to be the exact same version we have uploaded ages ago [07:58] fgimenez: 2.21-2+b1 [07:59] fgimenez: (which is also surprising because I would have assumed we'd keep sid updated frequently) [07:59] mwhudson: hey ^ is debian snapd updated for each release? are you still the one doing those updates? [08:20] zyga-ubuntu: i've just reproduced the upgrade/basic issue on debian http://paste.ubuntu.com/25117441/ [08:21] zyga-ubuntu: the session is open in case you want to have a look [08:22] there's a /usr/lib/snapd/snap-discard-ns but not /usr/lib/snapd/snap-update-ns... [08:28] fgimenez: excellent, please keep it [08:29] fgimenez: thank you, please keep the session [08:30] fgimenez: can you share credentials to mvo [08:30] fgimenez: so that we can ssh and explore [08:30] zyga-ubuntu: sure, 1sec [08:31] fgimenez: how many times did you run it? [08:31] fgimenez: I'm at my ~6th iteration locally and on linode [08:31] it's clearly a race somewhere [08:31] zyga-ubuntu: it failed on the 2nd execution, running on linode [08:31] fgimenez: interesting, thank you! [08:31] fgimenez: we're with mvo looking at the code there onw [08:31] now* [08:53] fgimenez: thanks for the credentials [08:53] zyga-ubuntu: np :) [08:57] hi folks newb when i run a script inside a snap installed in devmode and reference /etc is that /etc on the host or the snap? [08:57] it seems to be the host [09:46] okay crickets on that one lets try this question instead [09:46] I have a config that includes a sub config file: include: file:///etc/openldap/schema/core.ldif [09:47] but I can't put env vars in there, is there anything in snappy that lets me define a concrete path? [09:49] or something relative [09:49] i don't care partiulcarly it just needs to be able to find the file [10:34] PR snapd#3599 opened: Fix/clasic schizofrenia bug [10:38] PR snapd#3600 opened: many: expose service status in 'snap info' [10:38] wooo PR #3600 [10:38] where is my cake [10:38] zyga-ubuntu: ^ you were making noises about reviewing the services thing, here's your chance :-D [10:39] magicaltrout: I think you'll be luckier on the forum [10:39] magicaltrout: IRC is too synchronous [10:39] magicaltrout: the people that could properly answer your questions are sprinting and won't be listening on here for much of this week [10:41] no probs Chipaca i cross posted anyway thanks [10:54] Chipaca: hey [10:54] Chipaca: haha, good one :) [10:54] Chipaca: I'lll do my best [10:58] fgimenez: did you run the whole suite or just that specific test? [11:01] zyga-ubuntu: just that test [11:08] fgimenez: thank you! [11:08] * zyga-ubuntu scratches head :) [11:08] we've been running that test all day without failure (locally and in linode) [11:09] we'd like to test a theory but for whatever reason it won't break now [11:11] * Chipaca shakes his fist at interfaces-avahi-observe === chihchun is now known as chihchun_afk [11:47] is spread being funny, or am I being unlucky? [11:48] * Chipaca restarts the run [11:52] Chipaca: what are you seeing? [11:52] Chipaca: we're chasing a heisenbug all morning [11:52] zyga-ubuntu: failed prepares [11:52] Chipaca: I saw that once [11:52] Chipaca: we're really chasing tests/upgrade/basic on debian [11:52] nice === ahasenac` is now known as ahasenack === ahasenack is now known as Guest49405 [12:18] third's the charm, or something [13:23] Chipaca: hey [13:23] Chipaca: how do you feel like looking at release-critical https://github.com/snapcore/snapd/pull/3598 [13:23] PR snapd#3598: cmd,tests: fix classic confinement confusing re-execution code [13:24] Chipaca: it's green now and we'd like to land it and release it === chihchun_afk is now known as chihchun [13:24] and please hold for merging as we want to squash merge === JanC is now known as Guest76357 [13:26] * Chipaca on it [13:26] fgimenez: I logged out of the linode machine, I think we can recycle it now [13:27] Chipaca: thanks [13:27] zyga-ubuntu: great thanks! [13:27] Chipaca: I'll get to your branches ASAP but not sure if I can sneak out of kubernetes talk ;) [13:27] the snap info services [13:29] zyga-ubuntu: +1 [13:29] zyga-ubuntu: https://copr-be.cloud.fedoraproject.org/results/ngompa/snapd-prerel-fedora/fedora-rawhide-i386/00579417-snapd/build.log.gz ? [13:31] zyga-ubu1tu: you also get a +1 [13:35] thank you [13:39] Chipaca: I learned a new thing just now [13:39] zyga-ubu1tu: go on [13:40] Chipaca: var *stuff; stuff.CalledOnNil() [13:40] mhmm [13:40] queer :) [13:40] zyga-ubu1tu: we've corrected some of those in review of your code, fwiw :-) [13:41] where something could be nil and you weren't checking it [13:45] Chipaca: I was expecting the compiler to complain [13:46] Chipaca: I did some python lately and I just fell in love with mypy's static type checks and also, more importantly, None checks, so Optional[T] [13:46] zyga-ubu1tu: that's probably the work of a friend of mine :-) [13:47] Chipaca: jukka? [13:47] * zyga-ubu1tu might be doing a disservice to the mypy developer [13:47] (I know mypy is improved by lots of people now) [13:47] ah, no, my friend is into bringing mypy to django [13:47] https://2017.djangocon.eu/schedule/using-type-checking-in-django-projects-with-mypy/ [13:48] ah [13:48] I was doing just plain CLI stuff [13:48] Chipaca: I found it hard to publish a pypi package with type introspection data though [13:51] PR snapd#3598 closed: cmd,tests: fix classic confinement confusing re-execution code [13:57] PR snapd#3601 opened: cmd,tests: fix classic confinement confusing re-execution code [14:02] Chipaca: half review up === zyga-ubu1tu is now known as zyga-ubuntu === kjackal_ is now known as kjackal [14:51] cachio: Heya [14:51] cachio: Thanks for the changes in snadp#3483.. [14:52] cachio: Not sure if we talked about this before: we try hard not to rebase after a pull request is up [14:53] cachio: It removes the ability to follow through changes during the review process [14:54] cachio: "We went looking everywhere, but couldn’t find those commits." [14:54] Changing history is fine before the PR is pushed up, though [14:56] niemeyer, ok [14:56] niemeyer, first time you mention that [14:56] cachio: Cool, np [14:56] cachio: The PR looks good, thanks again for the changes [14:57] cachio: We just a second review on it.. [14:57] Any takers? [14:57] niemeyer, great, thanks [15:01] niemeyer: I recently explicitly asked for a rebase on a PR [15:01] niemeyer: it hadn't had any reviews and was a mess, very very hard to follow as it stood [15:01] (talking something like 50 commits in there) [15:01] Chipaca: That's the exception that validates the rule :) [15:02] :-) [15:09] cachio: +1'ed [15:09] cachio: niemeyer: is that one to be squashed as well? [15:11] Chipaca: Yeah, definitely [15:11] We've been squashing pretty much every merge [15:26] Chipaca, tx [15:46] PR snapd#3601 closed: cmd,tests: fix classic confinement confusing re-execution code === Guest49405 is now known as ahasenack [16:25] PR snapd#3589 closed: tests: remove unneeded check for re-exec in InternalToolPath() [16:28] Chipaca, ahey, any idea about why gpg 2 in opensuse is not getting the passphrase from the fake pinentry to export a key? [16:28] cachio: no [16:29] Chipaca, do you knowin which other systems are we using gpg 2? [16:29] zyga-ubuntu, https://forum.snapcraft.io/t/core-2381-breaks-ld-linux-so-2/1362 smells like some snap-confine/seccomp/namespaces issue (i dont think the linker or either of the two libc's we ship in core has changed recently) [16:29] cachio: does it look for the pinentry in the same place? [16:30] cachio: that is, the first thing I'd suspect is that for whatever reason it isn't even looking at ~/.snap/gnupg/gpg-agent.conf [16:31] ogra_: looking [16:31] cachio: second thing I'd suspect is that they don't have the pinentry-program option in their gpg2 [16:31] Chipaca, I'll check that [16:32] zyga-ubuntu, i actually wonder if we have any testing for the i386 libc we ship in the amd64 core for multiarch support [16:32] * ogra_ bets we dont [16:32] ogra_: replied on the forum, thank you [16:32] thanks ! [16:36] Chipaca, I think pinentry is used starting on gpg 2.1 [16:37] and in opensuse we have 2.0.8 [16:37] cachio: you think, or you know? :-) [16:38] Chipaca, based on the doc [16:38] Unattended passphrase [16:38] Starting with GnuPG 2.1.0 the use of gpg-agent and pinentry is required, which may break backwards compatibility for passphrases piped in from STDIN using the --passphrase-fd 0 commandline option. In order to have the same type of functionality as the older releases two things must be done: [16:39] cachio: something broke with gpg upgrade? [16:39] do we actually talk to running instance of gpg or do we just link to some libraries? [16:40] zyga-ubuntu, I understand we actually talk to running instance, but not totally sure [16:43] ouch, that would be unnice [16:43] cachio: are you trunning tumbleweed or leap? [16:45] zyga-ubuntu, in leap [16:47] cachio: thanks, interesting [16:48] zyga-ubuntu, I'll research a bit more [16:48] after lunch === cachio is now known as cachio_lunch [16:50] zyga-ubuntu: we run gpg [16:50] it's in asserts/gpgkeypairmgr.go [16:50] somewhat convoluted because gpg1 vs gpg2 [16:51] yes [16:51] zyga-ubuntu: we "talk to running instance" in the sense that we exec it and read its output :-) [16:52] this isn't bidirectional communication :-) [16:56] * ogra_ sees the linker issue in the forum is actually around a 64bit classic snap executing 32bit binaries and runs away screaming :P [16:57] classic snaps should die ! === chihchun is now known as chihchun_afk [16:57] * ogra_ will show up with a sign on a stick saying that at the next sprint :P [17:02] Chipaca: I'm surprised you're not using gpgme [17:04] there's a go binding for it: https://github.com/proglottis/gpgme [17:06] Pharaoh_Atem: is it pure go? [17:06] answer: nope [17:06] Pharaoh_Atem: so that's probably a chunk of why not [17:08] of course, we could still use it as a helper, but it's not like we don't have other things to do :-) [17:10] ogra_: hello [17:10] zyga-ubuntu, yo [17:10] ogra_: do oyu have a armv7 device around? [17:11] ogra_: one that rhymes with erry [17:11] ogra_: we need a hand [17:11] well, remote [17:11] ogra_: put rasbian on one [17:11] ogra_: and install snapd [17:11] oh [17:11] ogra_: and tell us what breaks when you install core [17:11] ogra_: I think there's a syscall missing [17:11] can that wait til tomorrow morning ? [17:11] ogra_: but my hardware is at home and I cannot check [17:12] (i'mm also not near the HW ... testing stuff remotely isnt a prob but physical access is a bit bad tonight) [17:12] ogra_: ok, I think we can do that tomorrow [17:12] ok [17:12] ogra_: I have a pi at home I can test but I'm at the sprint hotel [17:12] yeah, i grokked that [17:17] hey zyga-ubuntu. I'm doing an interface for a customer and using refresh-bits.sh. the interface appears but I get these seccomp profile errors: https://pastebin.canonical.com/193757/ [17:18] zyga-ubuntu, notably: "fork/exec /usr/lib/snapd/snap-seccomp: no such file or directory" [17:19] zyga-ubuntu, which is correct, that snap-seccomp file does not exist. any tips to get passed this? [17:21] interesting [17:22] kyleN: so is this on raspbian? [17:22] kyleN: on armv7? [17:22] zyga-ubuntu, no: amd64 ubuntu server 16.04 [17:23] o!? [17:23] what [17:23] kyleN: can you do snap version [17:24] https://pastebin.canonical.com/193758/ [17:24] i guess snapd is UNKNOWN because I am currently running the script to use the locally built snapd.... [17:24] kyleN: apt-cache policy snapd [17:24] 4.4.0-59-generic !!! [17:25] when I stop the script I get: snapd 2.26.9 [17:25] all of these exclamation points!! l) [17:25] :) [17:26] well,that kernel is *pretty* old ... [17:26] kyleN: or apt list snapd [17:26] yes hang on [17:26] Installed: 2.22.3 [17:27] snapd/xenial-updates 2.25 amd64 [upgradable from: 2.22.3] [17:27] * zyga-ubuntu brb [17:28] kyleN: please keep it as it is for now (this version) [17:28] kyleN: I suspect we know what is going on [17:28] darn, mvo I just upgrade snapd [17:28] kyleN: no worries [17:28] upgradeD [17:28] kyleN: if you just upgraded it, did the problem go away? [17:28] kyleN: or stil lthe same error? [17:28] checking [17:29] you surely also want a new kernel ... one that has less open security holes :) === cachio_lunch is now known as cachio [17:30] no, problem still exists. [17:30] (and also apparmor fixes that landed since -59-generic) [17:30] (we're at -83- currently) [17:30] ogra this is a hand crafted system (not by me) with hand installed kernel modules to support broadcom asic [17:31] so I don't want to muck with the kernel (but I can get Luke to if needed) [17:31] kyleN, well, i dont know wher, but there were seccomp and apparmor fixes since ... [17:31] s/wher/when/ [17:31] kyleN: can you pastebin the journal/syslog [17:31] ogra: ok, so you think this might be due to an old kernel? [17:31] i think it is likely they happened after the 53 revision [17:32] err [17:32] 59 [17:32] if they use a server install with extra modules, someone should help them to make them dkms modules so you dont get stuck on the kernel version [17:33] else the system is vulnerable ... [17:35] zyga-ubuntu, here's the last part of the journal, its long: https://pastebin.canonical.com/193763/ [17:36] looking [17:37] kyleN: can you please restart snapd (systemc restart snapd.service) [17:37] kyleN: while having look at the logs [17:37] kyleN: (journalctl -f) [17:37] kyleN: and then pastebin the new parts that show up after the restart [17:37] ok [17:43] sorry for the delay [17:45] kyleN: could you please snap refresh --edge core and see if that fixes the problem? we fixed a releated bug vsome minutes ago [17:45] zyga-ubuntu, https://pastebin.canonical.com/193766/ [17:45] mvo, ok [17:46] thank you, looking [17:48] mvo, after refreshing core from edge, I get the same error. of course the error occurs when using the locally built snapd with my dev interface. I am not clear whether it should be trying to find /usr/lib/snapd/snap-seccomp on that path or on the path of the temporary snapd... [17:49] kyleN: ok, very interesting [17:49] kyleN: did you change anything in /etc/ related to snapd reexec? [17:49] no [17:50] kust run: ubuntu@wedge100:~/go/src/github.com/devtools$ ./refresh-bits snapd setup run-snapd restore [17:50] Just run [17:50] then the error occurs when I do somethign with snap, like sudo snap interaces, or snap try... [17:50] kyleN: OMG [17:51] not sure if that is good OMG or bad OMG ;) [17:51] I'll go with bad OMG as a starting position ;) [17:51] PR snapd#3602 opened: snap-seccomp: add secondary arch for unrestricted snaps as well [17:51] kyleN: sorry [17:52] quite alright, this is fun [17:52] kyleN: so, I think devtools is somewhat unmaintained [17:52] ah [17:52] kyleN: and some things are missing [17:52] PR snapd#3603 opened: snap-seccomp: add secondary arch for unrestricted snaps as well [17:52] zyga-ubuntu, so I need to test my local snapd with my dev interface to prove it works before making PR. what do you recommend [17:52] kyleN: if you are hacking on a core device you may need to update devtools to copy new things over [17:52] is not a core device. is server [17:53] kyleN: if you are hacking on a classic device it may be easier to just hack on it directly/build package/run commands from core/etc [17:53] kyleN: if you need a hand I can elp [17:53] kyleN: including in updating devtools to the point where it works again [17:53] kyleN: but it's totally my fault that it's an unmaintained thing that poses as somethin that still works [17:54] zyga-ubuntu, I very much want to get this PR to snapd this week. can you perhaps fix up devtools so I can try again tomorrow? [17:55] I am totally open to whatever appraoch works for you zyga [17:55] zyga-ubuntu, ^ [17:55] kyleN: what's the PR? [17:55] broadcom-asic-control intefaces for customer [17:56] interface (not plural) [17:56] kyleN: aha [17:57] kyleN: well, can you please push the PR up (not sure if you already did, sorry about that) and we review it [17:57] kyleN: for hacking locally just build the package (dpkg-buildpackage) [17:57] kyleN: install it [17:57] kyleN: and then you can just hack on interfaces [17:57] zyga-ubuntu, well, I wanted to prove to myself that it works before making the PR [17:57] kyleN: and run sudo ./snapd from the tree [17:58] kyleN: you may need to sudo systemctl stop snapd.{socket,service} [17:58] kyleN: you can propose it even before it's finished [17:58] kyleN: and update it mid way [17:58] kyleN: as I suspect there may be more things than just the security bits [17:59] ok. it's pretty simple. just apparmor snippet [17:59] kyleN: but the dpkg-buildpackage + install freshly built snapd.deb + stop / disable snapd.{socket,service} + sudo ./snapd approach will get you going [17:59] I find taht with my hand overriden snap command appA profile, I get no DENIED when the kernel module is used by the snap [18:00] tyhicks, jdstrand could you please look at trivial/emergency PR: https://github.com/snapcore/snapd/pull/3603 [18:00] PR snapd#3603: snap-seccomp: add secondary arch for unrestricted snaps as well [18:00] kyleN: can you push your branch anywhere? I'd like to see the apparmor snippet [18:00] ok hang on [18:04] PR snapd#3599 closed: Fix/clasic schizofrenia bug [18:12] zyga-ubuntu, https://github.com/knitzsche/snapd/tree/broadcom-asic-interface [18:14] PR snapd#3595 closed: debian: update debian/tests/control to use isolation-machine [18:29] Bug #1705091 opened: unable to use snap after install [19:04] PR snapd#3603 closed: snap-seccomp: add secondary arch for unrestricted snaps as well [19:13] kyleN: thank you [19:13] kyleN: if you don't need udev tagging you can just use commonInterface [19:14] kyleN: less code to write [19:14] kyleN: not sure if this interface should be implicit [19:14] kyleN: that needs some more discussion [20:08] Anyone around to handle a snap in the review queue? [21:12] enozyga [21:18] zyga-ubuntu: done! (I see that it was already merged and that's fine since it was a urgent issue that was trivial) [22:02] PR snapd#3604 opened: tests: enable main suite for opensuse [23:13] anyone know if there is an easy way to get snappy to pull from ubuntu src? [23:14] most packages' source can be downloaded with "apt source packagename" [23:14] so wondering if snappy can pull src similarly [23:16] invapid, I'm afraid not [23:33] hooks........ [23:33] docs say i just need a hooks/configure file [23:33] if i copy this one https://github.com/snapcore/snapcraft/tree/master/demos/hooks/snap/hooks [23:33] and deploy my snap [23:33] Run configure hook of "openldap" snap (snap "openldap" has no "configure" hook) [23:33] what moronic thing have i got wrong/ [23:33] ? [23:39] bugg@tom-laptop2:~/Projects/openldap-snap$ ll /snap/openldap/current/hooks/configure [23:39] seems legit [23:46] hmm the demos dont work either [23:48] https://forum.snapcraft.io/t/configure-hook-doesnt-run/1365 if anyone gets bored