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