[00:34] <mup> PR snapcraft#1214 opened: asset-tracking: add subversion source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1214>
[00:58] <mup> PR snapcraft#1215 opened: asset-tracking: add mercurial source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1215>
[09:50] <zyga> Pharaoh_Atem: you may be interested in joining https://plus.google.com/communities/103356268060178755068
[10:16] <Son_Goku> zyga: I'm in it now
[10:20] <mup> PR snapd#3071 opened: many: Ignore configure hook failures on core refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/3071>
[10:23] <zyga> Son_Goku: great, thanks
[10:23] <zyga> Son_Goku: I set moderation for 1st post of new members
[10:23] <zyga> Son_Goku: but after that you should be good
[10:23] <Son_Goku> well, I don't have anything to say...
[10:27] <zyga> Son_Goku: aww, I'm sure you will have something to say one day :)
[10:27]  * Son_Goku shrugs
[10:43] <mup> PR snapd#3071 closed: many: Ignore configure hook failures on core refresh <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3071>
[11:25]  * zyga does school run
[11:48] <mup> PR snapd#3071 opened: many: Ignore configure hook failures on core refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/3071>
[11:54] <Son_Goku> morphis, golang deps packaging?
[11:56] <morphis> Son_Goku: I've started and coming along
[12:16] <mup> PR snapd#3072 opened: interfaces: use udev spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/3072>
[13:00] <mup> PR snapcraft#1216 opened: cleanbuild: don't copy cache into container <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1216>
[13:03] <morphis> Son_Goku: can you have a look at https://github.com/CanonicalLtd/snappy-docs/pull/47 and check the Fedora part of you see something wrong?
[13:03] <mup> PR CanonicalLtd/snappy-docs#47: Extend snapd installation instructions <Created by morphis> <https://github.com/CanonicalLtd/snappy-docs/pull/47>
[13:05] <Son_Goku> morphis: yeah, there are no working snappy packages
[13:05] <morphis> Son_Goku: the 2.16 ones from zyga's repo worked to some degree .. however this is more for the near future where we have working packages again
[13:06] <Son_Goku> when we have working packages, they'll just be in the Fedora repos
[13:06] <morphis> Son_Goku: sure, but keeping what is written there doesn't make sense so this just takes it and rewrites it
[13:06] <Son_Goku> yes
[13:06] <Son_Goku> I guess
[13:07] <Son_Goku> by that token, I could have just built and released 2.16 now
[13:07] <morphis> and if we can provide something in a repo until its in the main distribution we should do that to have something people can test
[13:07] <morphis> Son_Goku: hm, lets not do that, it has too many unknowns for me right now
[13:08] <Son_Goku> I held off on releasing 2.16 because zyga said we'd have 2.23 done in a week, several weeks ago :(
[13:08] <morphis> there were quite some problems recently with getting people upgraded and if we release to main it should use the core instead of ubuntu-core snap from the beginning
[13:08] <morphis> Son_Goku: yeah 2.23 is there now and I am here to put speed on this :-)
[13:08] <Son_Goku> yeah, except 2.23 and 2.23.1 don't build
[13:09] <morphis> we can fix this and I am working on the golang packages
[13:09] <Son_Goku> well, I'm tired of receiving the errors from the buildsystem about snapd-glib needing snapd and it's unresolvable, so I hope you have the golang packages today for me to review :)
[13:09] <morphis> Son_Goku: lets see
[13:10] <Son_Goku> I also am able to sponsor new packagers into the packager group, so we can get it done very quickly
[13:15] <morphis> Son_Goku: awesome!
[13:16] <morphis> Son_Goku: can I enter the chroot mock builds somehow?
[13:16] <Son_Goku> yes
[13:17] <Son_Goku> mock [-r <name-of-root>] --shell
[13:17] <morphis> ok
[13:22] <morphis> Son_Goku: I love this .. the guy named the repo gettext.go and if you call go test github.com/ojii/gettext.go go can't deal with it as it things its a .go file
[13:22] <Son_Goku> :/
[13:23] <morphis> you need to put / behind it to make sure its a dir
[13:25] <zyga> morphis: you may use go test github.com/ojii/gettext.go/....
[13:25] <zyga> (one less dot)
[13:26] <pmcgowan> zyga, is snapd checking the content: name in a newer version? does not seem to on 2.23.1
[13:27] <pmcgowan> also what is the advantage of having a content: value specified
[13:27] <mup> Bug #1675413 opened: snap disconnect doesn't support tab completion <Snappy:New> <https://launchpad.net/bugs/1675413>
[13:41] <Son_Goku> morphis: it used to be called gogettext :/
[13:41] <Son_Goku> then they broke it
[13:42] <zyga> pmcgowan: I think it does
[13:42] <zyga> pmcgowan: there was a regression at one revision but it was fixed AFAIR
[13:43] <pmcgowan> zyga, I have 2.23.1 and it doesnt seem to get checked
[13:43] <pmcgowan> zyga, but I am wondering, what is it good for?
[13:44] <pmcgowan> since I cant really rev interface versions using it aiui
[13:46] <zyga> pmcgowan: it's a "protocol" handshake
[13:46] <zyga> pmcgowan: you cannot connect if plug and slot don't agree
[13:47] <pmcgowan> zyga, but I already need to have the names agree, how is this different
[13:47] <zyga> pmcgowan: the regression was in one place where we didn't return the default one based on interface name
[13:47] <zyga> pmcgowan: which names?
[13:47] <pmcgowan> the plug and slot
[13:47] <zyga> pmcgowan: those are irrelevant
[13:47] <zyga> pmcgowan: you cna name them any way you want
[13:47] <pmcgowan> so they dont need to match
[13:47] <pmcgowan> ok
[13:47] <zyga> pmcgowan: the content attirbute matters
[13:47] <pmcgowan> so its just broken in this version
[13:47] <zyga> I think so
[13:48] <pmcgowan> ok
[13:48] <zyga> pmcgowan: but if you define content explictly it should work in any version
[13:48] <pmcgowan> yeah its not
[13:48] <pmcgowan> zyga, I just connected foo to bar basically and it worked
[13:50] <pmcgowan> zyga I also filed a bug about connecting to the wrong snap entirely
[13:53] <pmcgowan> zyga, unless the checking is not happening with locally installed snaps with dangerous
[14:00] <zyga> pmcgowan: I think that's possible
[14:00] <zyga> pmcgowan: this is based on assertions
[14:00] <zyga> pmcgowan: so without assertions that will happen
[14:01] <pmcgowan> zyga, ok thanks
[14:05] <morphis> Son_Goku: hah! INFO: Done(/home/simon/rpmbuild/SRPMS/golang-github-ojii-gettext.go-0-0.1.gitb6dae1d.fc25.src.rpm) Config(default) 0 minutes 36 seconds
[14:05] <Son_Goku> yay
[14:05] <morphis> Son_Goku: ok, this is pretty rough, where can I submit for review?
[14:06] <Son_Goku> process is mentioned in https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request
[14:09] <morphis> ok
[14:10] <zyga> morphis: note that first review is a bit different
[14:10] <zyga> morphis: you need a space to put your spec file and srpm
[14:10] <morphis> yeah
[14:10] <zyga> morphis: after the first review you get assigned space (though not sure since fedorahosted was shut down)
[14:10] <Son_Goku> fedorahosted != fedorapeople
[14:11] <Son_Goku> fedorahosted was like Debian Alioth
[14:11] <Son_Goku> except using Trac instead of FusionForge
[14:11] <Son_Goku> fedorapeople is just a space for people to use :)
[14:12] <mup> PR snapcraft#1216 closed: cleanbuild: don't copy cache into container <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1216>
[14:13] <zyga> aaah
[14:13] <zyga> so that's fine
[14:13]  * zyga wonders why this doesn't work
[14:13] <zyga> http://paste.ubuntu.com/24235103/
[14:15] <mup> PR snapcraft#1217 opened: tour: make it work when its a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1217>
[14:16] <jdstrand> zyga: fyi https://github.com/snapcore/snapd/pull/2624#issuecomment-288732682
[14:16] <mup> PR snapd#2624: cmd/snap-confine: re-associate with pid-1 mount namespace if required <Critical> <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2624>
[14:28] <zyga> jdstrand: checking
[14:28] <zyga> jdstrand: noted
[14:38] <morphis> Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1435327
[14:39] <morphis> Pharaoh_Atem: this is mostly what gofed gave me + some small additions to get the tests running
[14:39] <morphis> zyga: ^^
[14:59] <Pharaoh_Atem> morphis: left comments on review
[15:00] <morphis> Pharaoh_Atem: great
[15:06] <morphis> Pharaoh_Atem: fine for you if I update the spec and srpm at the same location?
[15:06] <Pharaoh_Atem> yes, just make sure you note it as a comment
[15:06] <Pharaoh_Atem> it's not significant enough to require anything else...
[15:07] <morphis> aye
[15:09] <morphis> Pharaoh_Atem: done
[15:32] <mup> PR snapcraft#1218 opened: asset-tracking: use a more likely to be found global build-package <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1218>
[15:41] <NicolinoCuralli> hi all which test ran on a snap as soon as published on a channel?
[15:42] <morphis> Pharaoh_Atem: for the other package I need to see why gofed crashes on it
[15:54] <mup> PR snapd#3073 opened: overlord: make sure all managers packages have *state.go with the main state manipulation/query APIs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3073>
[16:01] <Pharaoh_Atem> morphis: ERROR: 'Error [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661) downloading https://mm.gravedo.de/files/golang-github-ojii-gettext.go-0-0.1.gitb6dae1d.fc25.src.rpm' (logs in /home/makerpm/.cache/fedora-review.log)
[16:02] <morphis> what?
[16:02] <morphis> Pharaoh_Atem: it's singed by LetsEncrypt
[16:02] <morphis> maybe that is the issue here for your build host
[16:14] <mup> PR snapcraft#1219 opened: kernel plugin: learn how to assemble the ubuntu config using kconfigflavour <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1219>
[16:29] <mup> PR snapd#3074 opened: configstate,hookstate: limit runtime of the configure hook to 1 minute <Created by mvo5> <https://github.com/snapcore/snapd/pull/3074>
[16:46] <Pharaoh_Atem> morphis: something isn't set up right with your cert, since the only thing that lets me access it is Chrome
[16:59] <mup> PR snapd#3073 closed: overlord: make sure all managers packages have *state.go with the main state manipulation/query APIs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3073>
[17:35] <stokachu> anyone seen returns: "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid
[17:35] <stokachu>                  permission escalation attacks"
[17:35] <stokachu> before?
[17:36] <stokachu> ThiagoCMC: can you post `snap version` as well?
[17:36] <ThiagoCMC> sure
[17:36] <ThiagoCMC> 1 sec
[17:36] <ThiagoCMC> "dpkg -l | grep snapd" = snapd 2.22.6
[17:37] <ThiagoCMC> It is a fresh installed Ubuntu 16.04.2
[17:37] <ogra_> better use "snap version"
[17:37] <ThiagoCMC> Oh...
[17:37] <ogra_> and also make sure to have all updates before trying to use snap
[17:37] <ThiagoCMC> "apt full-upgrade" was executed a few minutes ago...
[17:37] <ogra_> snapd is on a pretty frequent SRU cadence
[17:37] <ThiagoCMC> sandvine@juju-1:~$ snap version
[17:37] <ThiagoCMC> snap    2.23.1
[17:37] <ThiagoCMC> snapd   2.23.1
[17:37] <ThiagoCMC> series  16
[17:37] <ThiagoCMC> ubuntu  16.04
[17:37] <ThiagoCMC> kernel  4.8.0-41-generic
[17:38] <ogra_> that looks better :)
[17:38] <ThiagoCMC> damn... pasted my private login... lol
[17:38] <stokachu> dont worry we're all saints here
[17:38] <ThiagoCMC> So, how to fix: "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks" ?
[17:38] <ogra_> we wont tell anyone (only the IRc logs and google will though)
[17:38] <ThiagoCMC> I know....  ^_^
[17:38] <ThiagoCMC> that's ok.. haha
[17:39] <ogra_> looks like zyga is already off ... snap-confine is his area :/
[17:39] <stokachu> found this http://askubuntu.com/questions/888497/snap-confine-refuses-to-launch-application-to-avoid-permission-attack
[17:39] <stokachu> no answers but..
[17:39] <ThiagoCMC> I found that too...  =/
[17:40] <ThiagoCMC> So, http://conjure-up.io/ instructions are basically, broken.   :-(
[17:40] <stokachu> ThiagoCMC: you aren't on mint are you?
[17:40] <ThiagoCMC> Nop!
[17:40] <ThiagoCMC> Ubuntu 16.04.2, fresh installed.
[17:41] <ThiagoCMC> from Ubuntu Server ISO...
[17:41] <stokachu> hmm
[17:42] <stokachu> so where was "dpkg -l | grep snapd" = snapd 2.22.6 run from?
[17:42] <zyga> hello
[17:42] <stokachu> b/c your snap version shows 2.23.1
[17:42] <stokachu> ah
[17:42] <zyga> stokachu: hey
[17:42] <stokachu> zyga: hey!
[17:42] <zyga> so I wrote that part
[17:42] <stokachu> zyga: have a user running into snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[17:42] <zyga> stokachu: I'm curious where are you running this
[17:42] <mup> PR snapcraft#1218 closed: asset-tracking: use a more likely to be found global build-package <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1218>
[17:42] <stokachu> ThiagoCMC: ^
[17:42] <stokachu> zyga: ThiagoCMC is the user with the issue
 snap    2.23.1
 snapd   2.23.1
 series  16
 ubuntu  16.04
[17:42] <zyga> stokachu: is this on Ubuntu or is this somewhere else?
 kernel  4.8.0-41-generic
[17:42] <stokachu> zyga: yea ubuntu 16.04.2
[17:42] <zyga> ThiagoCMC: hey
[17:42] <ThiagoCMC> Hey!
[17:42] <zyga> very interesting
[17:43] <zyga> ok, can you please look at ...
[17:43] <ogra_> seems up to date and all
[17:43] <zyga> sudo cat /sys/kernel/security/apparmor/profiles
[17:43] <zyga> ThiagoCMC: can you please run that and pastebin
[17:43] <ThiagoCMC> 1 sec
[17:43] <ogra_> oh, that looks like a hwe kernel btw
[17:44] <ThiagoCMC> zyga, https://paste.ubuntu.com/24236144/
[17:44] <ThiagoCMC> yeah, Linux 4.8
[17:44] <zyga> ThiagoCMC: thanks, so lines 12 and 13 are what we needed to see
[17:45] <zyga> ThiagoCMC: can you please set SNAP_CONFINE_DEBUG=yes and run something that is a snap
[17:45] <ThiagoCMC> Let me try
[17:46] <ThiagoCMC> zyga, you mean, something like "conjure-up openstack" ?
[17:46] <zyga> ThiagoCMC: or even hello-world if you have that snap installed
[17:46] <zyga> (the smaller the better)
[17:47] <ThiagoCMC> right, 1 min...
[17:48] <ThiagoCMC> zyga, https://paste.ubuntu.com/24236164/ look good
[17:48] <zyga> ThiagoCMC: now run it
[17:50] <ThiagoCMC> zyga, https://paste.ubuntu.com/24236179/
[17:51] <zyga> hmmm
[17:51] <zyga> so hello-world worked
[17:51] <ThiagoCMC> yep
[17:51] <zyga> now run what you tried earlier
[17:51] <ThiagoCMC> maybe I need "$ sudo conjure-up openstack", with "sudo" ?
[17:51] <ThiagoCMC> instructions on conjure-up.io doesn't tell to use sudo...
[17:52] <zyga> ThiagoCMC: that error you saw should never show up
[17:52] <ThiagoCMC> =(
[17:52] <zyga> ThiagoCMC: maybe conjure-up runs some snap commands itself
[17:52] <ThiagoCMC> easy to reproduce...
[17:52] <zyga> ThiagoCMC: can you run conjure up again?
[17:52] <ThiagoCMC> sure
[17:53] <ThiagoCMC> LOL Worked after a reboot!
[17:53] <ThiagoCMC> WTF!   =P
[17:53] <zyga> ThiagoCMC: curious
[17:53] <ThiagoCMC> Windows!
[17:53] <ThiagoCMC> aheuHAEuae
[17:53] <zyga> ThiagoCMC: what did you do before reboot?
[17:53] <zyga> ThiagoCMC: what that error message said essentially
[17:53] <zyga> ThiagoCMC: is that snap-confine didn't have its apparmor profile loade
[17:53] <zyga> *loaded
[17:53] <ThiagoCMC> zyga, "sudo snap install conjure-up --classic" then reboot
[17:53] <ThiagoCMC> otherwise, "conjure-up openstack" doesn't work...
[17:54] <zyga> aha
[17:54] <ThiagoCMC> hehehe
[17:54] <zyga> hmmm
[17:54] <zyga> well
[17:54] <zyga> no idea really :/
[17:54] <zyga> ThiagoCMC: thanks, if this happens again please report it
[17:54] <ThiagoCMC> Looks like that conjure-up.io needs a review!
[17:54] <ThiagoCMC> It happens all the time!
[17:54] <zyga> oh?
[17:54] <ThiagoCMC> I tried it 3 times...
[17:54] <zyga> can you report a bug with instructions on how to cause it?
[17:54] <zyga> I never saw that myself
[17:54] <ThiagoCMC> yes
[17:54] <stokachu> ThiagoCMC: you are the only one to hit this issue
[17:55] <zyga> aaah
[17:55] <zyga> I think I know
[17:55] <ThiagoCMC> I'm the Master of Bugs!   ;-)
[17:55] <zyga> well, maybe suspect
[17:55] <zyga> suspect this is related to classic confinement which does not reset PATH
[17:55] <zyga> so you run with your own path
[17:55] <zyga> but ...
[17:55] <zyga> nah
[17:55] <zyga> that doesn't explain anything
[17:55] <ThiagoCMC> Right, I'll even record my screen and upload to youtube, then, fill a "video bug report" on launchpad
[17:56] <stokachu> thanks
[17:56] <stokachu> i'd like to reproduce it
[17:56] <zyga> ThiagoCMC: if you can report that I would appreciate the details
[17:56] <zyga> ThiagoCMC: then we can get to the bottom of it
[17:56] <ThiagoCMC> Sounds cool! I'll be happy to help!
[18:05] <Bizon> hey there. i'm packaging an app and while it runs completely fine if i start it through /snap/app/current/usr/bin/app, it just prints "F" and quits if i start it from /snap/bin
[18:05] <Bizon> does anybody have a clue what could be wrong please?
[18:09] <nacc> Bizon: iirc, /snap/bin apps are just wrapper scripts? you might be able (as root) to use bash -x or so (maybe, check what the script is first, i guess) to see what command is failing?
[18:11] <kyrofa> nacc, they aren't wrapper scripts anymore, they're symlinks
[18:11] <Bizon> nacc: /snap/bin apps are symlinks to snap run <app>
[18:12] <kyrofa> nacc, snapd uses those symlinks to determine the environment programatically, so it's a little opaque
[18:12] <nacc> kyrofa: ah! sorry, i dont' follow it actively, was going off what i recalled
[18:12] <nacc> Bizon: sorry for the misinformation!
[18:12] <Bizon> nacc: np
[18:12] <kyrofa> nacc, oh no criticism meant on my part. You were absolutely correct until a few releases ago
[18:12] <Bizon> hmm, now i see with snap run i can do --shell and try run it manually right?
[18:13] <zyga> Bizon: if you run it via /snap/bin it gets confined
[18:13] <kyrofa> Bizon, `snap run --shell` will put you into a shell confined with the same environment as the app, so yeah, try that
[18:13] <kyrofa> Bizon, I assume it'll fail the same way as when you run the app in /snap/bin/
[18:13] <zyga> Bizon: if you run it from /snap/$SNAP_NAME/current/... you just run whatever is there unconfined
[18:14] <morphis> Pharaoh_Atem: that is lets-encrypt I guess
[18:14] <Bizon> kyrofa: it doesn't, i get a ldd error
[18:14] <niemeyer> Bizon: Note you need to provide any command line arguments yourself
[18:14] <kyrofa> Bizon, ah, you're missing the snapcraft wrapper that's probably setting LD_LIBRARY_PATH for you, then
[18:14] <niemeyer> kyrofa: It'd be nice to get rid of those wrappers at some point
[18:14] <niemeyer> kyrofa: We have the environment settings support now
[18:14] <Bizon> kyrofa: oh, i have that
[18:15] <kyrofa> niemeyer, I doubt it'll ever happen. Some plugins actually inject real shell script
[18:15] <Bizon> kyrofa: running the wrapper i get just F again
[18:15] <kyrofa> niemeyer, i.e. not just exports
[18:16] <niemeyer> kyrofa: It'd be nice to find an alternative to that
[18:16] <niemeyer> kyrofa: Also, this is not a reason to not move the env itself into snap.yaml
[18:16] <kyrofa> niemeyer, I agree that they're an annoying level of redirection. What sort of alternative to you envision?
[18:16] <niemeyer> kyrofa: FIrst step would be to kill the wrapper altogether unless necessary
[18:17] <niemeyer> kyrofa: In the conversation above, note how the shell ends up in a completely different environment from the one the application will actually run on
[18:17] <niemeyer> kyrofa: More complexity, more confusion, ...
[18:17] <kyrofa> niemeyer, yes, like I said, I agree
[18:17] <niemeyer> kyrofa: So let's do it :)
[18:18] <Bizon> but yeah, if i run the app, i just get "F" printed to stderr, not even a line break
[18:18] <Bizon> and it quits immediately
[18:18] <kyrofa> niemeyer, but the environment keyword only supports state variable definitions, which doesn't cover all use-cases. The catkin plugin for example actually has real shell scripting in there
[18:18] <kyrofa> s/state/static/
[18:19] <kyrofa> niemeyer, I'm not clear on a viable alternative
[18:19] <ThiagoCMC> zyga, "conjure-up openstack", after staring the OpenStack deployment, failed again: https://paste.ubuntu.com/24236284/
[18:19] <ThiagoCMC> I'll give it up for now...   :-(
[18:21] <zyga> ThiagoCMC: hmmm
[18:21] <ThiagoCMC> ;-(
[18:21] <zyga> ThiagoCMC: is that because of snap-confine?
[18:21] <morphis> Pharaoh_Atem: ok, retry, should work now
[18:21] <ThiagoCMC> no idea...
[18:21] <ThiagoCMC> I'll try juju only, conjure-up is not working.
[18:22] <kyrofa> niemeyer, snapcraft could start placing all of its static environment in the snap.yaml and only generate those wrappers as a more special case for the plugins that need them, but that switches the order around so the plugin's environment doesn't come first which may have unintended side effects
[18:23] <niemeyer> kyrofa: In which sense would it not come first?
[18:24] <mup> PR snapcraft#1217 closed: tour: make it work when its a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1217>
[18:24] <kyrofa> niemeyer, right now snapcraft evaluates the plugin environment and then sets the stuff it knows it needs (LD_LIBRARY_PATH, PATH, etc.). If that was moved into the snap.yaml, snapd would evaluate it before the plugin's environment was evaluated
[18:24] <kyrofa> niemeyer, changing the LD_LIBRARY_PATH ordering, etc.
[18:26] <pmcgowan> kyrofa, where do I read about the environment keywword
[18:26] <niemeyer> kyrofa: This sounds like the more natural choice?
[18:27] <niemeyer> kyrofa: Defaults usually come first
[18:27] <ogra_> ThiagoCMC, that pyhon stacktrace is probably something stokachu would like to see too
[18:28] <kyrofa> niemeyer, perhaps, I'm simply stating that it's a change that could have unintended side effects. We should be careful
[18:29] <ThiagoCMC> ogra_, right... I posted on #juju as well... I'll ping him... In the end of the day, conjure-up.io instructions does not work.
[18:30] <kyrofa> pmcgowan, haha, I'm having a heck of a time finding docs for you, that's bad
[18:30] <niemeyer> kyrofa: Indeed, but note that this only affects new builds
[18:30] <pmcgowan> kyrofa, yeah I did look myself
[18:32] <jrwren> is there a way to run https://snapcraft.io/docs locally? the 3-4s page loads are slow enough to be annoying.
[18:33] <kyrofa> niemeyer, new or not, if the builds I publish via daily CI started breaking because of snapcraft changes I'd be unhappy
[18:34] <kyrofa> Regardless, I agree that it's something to move toward. Those wrappers drive me nuts
[18:34] <niemeyer> \o/
[18:34] <kyrofa> Just don't want to put more work on the shoulders of snap developers
[18:36] <kyrofa> pmcgowan, mind logging a bug about the environment keyword?
[18:37] <kyrofa> pmcgowan, you can see a demo of it here if you're curious, though: https://github.com/snapcore/snapcraft/blob/master/demos/git/snap/snapcraft.yaml
[18:37] <pmcgowan> kyrofa, what do I log against
[18:37] <kyrofa> pmcgowan, definitely snapcraft, though I couldn't find anything in snapd either
[18:37] <pmcgowan> ok
[18:38] <pmcgowan> kyrofa, as long as the wrapper needs to do things conditionally, this only helps a bit
[18:38] <kyrofa> pmcgowan, yeah that's what niemeyer and I were talking about. As soon as something other than static variables are required, we require wrappers
[18:39] <pmcgowan> kyrofa, or most of the time to even set them you test something
[18:39] <mup> PR snapd#3075 opened: overlord: split out handlers.go in devicestate and snapstate, other small order/naming tweaks <Created by pedronis> <https://github.com/snapcore/snapd/pull/3075>
[18:39] <pmcgowan> like to make the arch specific path
[18:39] <pmcgowan> or find the right socket location
[18:40] <kyrofa> pmcgowan, indeed. Check out what the catkin plugin has to do: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/catkin.py#L381
[18:40] <pmcgowan> oy vay
[18:41] <kyrofa> Soo many faces on keyboards
[18:41] <ogra_> there is a backslash missing ...
[18:41] <ogra_> ... i'm sure ...
[18:41] <ogra_> :P
[18:42] <pmcgowan> kyrofa, michi reported one already at bug #1666745
[18:42] <mup> Bug #1666745: environment appears to be undocumented <Snapcraft:New> <https://launchpad.net/bugs/1666745>
[18:42] <Pharaoh_Atem> morphis: package approved
[18:42] <kyrofa> Oh good!
[18:43] <kyrofa> Shush ogra_
[18:43] <ogra_> pmcgowan, https://github.com/myriadrf/snapcraft-sandbox/blob/master/limesdr-grc/snapcraft.yaml a good example for environment btw
[18:43] <Pharaoh_Atem> morphis: however, you're not quite done yet :)
[18:45] <kyrofa> niemeyer, would it be downright dreadful to support more verbose shell in snapd instead of just static variables?
[18:45] <kyrofa> niemeyer, the point pmcgowan makes is a good one
[18:45] <morphis> Pharaoh_Atem: you mean with submitting that package?
[18:45] <kyrofa> niemeyer, but I can see that resulting in really gross YAMLs
[18:46] <kyrofa> But as far as snapcraft is concerned, we already have the scriptlets
[18:46] <Pharaoh_Atem> morphis: well, since you're a first time packager and you're quite literally new to RPM packaging, I want you to do a couple of (non-binding) package reviews in the package review queue
[18:46] <niemeyer> kyrofa: Yes, that'd probably not end up well, but we might introduce the idea of a setup script
[18:46] <niemeyer> Which ends up in the same place
[18:46] <niemeyer> But not dreadful
[18:47] <kyrofa> niemeyer, yeah, something like that would help a lot
[18:47] <morphis> Pharaoh_Atem: sounds good, should I just pick some from https://fedoraproject.org/PackageReviewStatus/NEW.html ?
[18:47] <Pharaoh_Atem> Yep
[18:47] <Pharaoh_Atem> some from the newest ones, rather than the oldest ones
[18:48] <morphis> yeah, will take a few golang ones
[18:49] <Pharaoh_Atem> you'll want to familiarize yourself with https://fedoraproject.org/wiki/Packaging:Guidelines and https://fedoraproject.org/wiki/PackagingDrafts/Go
[18:51] <mup> PR snapcraft#1220 opened: Release changelog for 2.28 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1220>
[19:11] <Pharaoh_Atem> morphis: also, you should announce yourself on the fedora-devel mailing list
[19:12] <morphis> Pharaoh_Atem: yeah was planing to do that tomorrow
[19:55] <jrwren> is there a way I can run strace in a snap environment to see what is going on?
[19:56] <zyga> jrwren: yes
[19:56] <zyga> jrwren: you need to do a few things but it is possible
[19:56] <zyga> jrwren: the trick is to use "snap run --shell" to run a shell with confinement the same as a given app
[19:57] <zyga> jrwren: then run a copy of strace (you need to put it somewhere reachable)
[19:57] <zyga> jrwren: you may need to adjust confinement (not sure, I do this without thinking sometimes)
[19:57] <zyga> jrwren: you can copy strace from your host
[19:57] <zyga> jrwren: and e.g. stick it in /run where you can copy it from
[19:58] <zyga> jrwren: note that you will not be able to run it from /run (apparmor) so you will have to copy it somewhere else (try /tmp but again not sure because whenever I do it I do it automatically and think too little to remember)
[19:58] <jrwren> ok, i'll play around with that. the snap in question is not confined anyway, so maybe it will be easier?
[19:58] <zyga> jrwren: yes, it will be easier
[19:58] <zyga> jrwren: you can then run it directly from /var/lib/snapd/hostfs/usr/bin/strace
[20:00] <zyga> jrwren: (that is, use snap run --shell and then run strace like I said)
[20:23] <jrwren> strace helped. thanks zyga
[20:24] <jrwren> I filed a bug, but I'm snappy new enough that I wonder if it is a bug. https://bugs.launchpad.net/snapcraft/+bug/1675545
[20:24] <mup> Bug #1675545: undefined symbol: _Py_RefTotal <Snapcraft:New> <https://launchpad.net/bugs/1675545>
[20:24] <jrwren> Does the python plugin support C modules with python-version set to python2?
[20:24] <jrwren> I get ImportError: ... undefined symbol: _Py_RefTotal
[20:26] <jdstrand> roadmr: can you add a pull of r851 to your queue? like the last one, not urgent at all
[20:26] <jdstrand> roadmr: and hi! :)
[20:27] <roadmr> jdstrand: hello! sure thing, I'll prepare the merge
[20:27] <jdstrand> thanks
[20:36] <zyga> jdstrand: upstream kernel has something that fails our seccomp code
[20:36] <zyga> jdstrand: https://bugs.launchpad.net/snappy/+bug/1674193
[20:36] <mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <snapd (Debian):New> <openSUSE:Fix Released by morphis> <https://launchpad.net/bugs/1674193>
[20:36] <zyga> jdstrand: we should run our seccomp test suite on one
[20:36] <zyga> jdstrand: (I'm EOD, just wanted to let you know)
[20:37] <zyga> jdstrand: and perhaps extend it to test bind specifically
[20:38] <zyga> jdstrand: (it gets killed on bind)
[20:38] <zyga> jdstrand: this was tested on xenial with both xenial kernel (-41) and mainline kernel (linux-image-4.10.2-041002-generic)
[20:38] <zyga> jdstrand: the mainline kernel fails reliably each time
[20:39] <jdstrand> zyga: it is possible it is not the kernel but their seccomp
[20:40] <jdstrand> zyga: see this changelog for trusty's https://launchpad.net/ubuntu/+source/libseccomp/2.1.1-1ubuntu1~trusty3
[20:41] <zyga> jdstrand: no, it was tested on a machine with just rebooting to stock kernel
[20:41] <zyga> no other updates were installed
[20:41] <jdstrand> zyga: if they have 2.1.x, then they should use those patches or upgrade to 2.2.3 (what is in xenial)
[20:41] <jdstrand> what version of seccomp do they have?
[20:42] <zyga> jdstrand: asking
[20:42] <zyga> jdstrand: apt-cache policy libseccomp is sufficient?
[20:42] <zyga> (libseccomp2)
[20:42] <jdstrand> cause the issues that bug showed with 2.1 were weird
[20:42] <jdstrand> zyga: I thought this was opensuse?
[20:43] <jdstrand> but however you can give me the version, that's fine
[20:43] <zyga> jdstrand: no, I'm telling you this happens on *xenial* using a mainline (non ubuntu sauce) kernel
[20:43] <zyga> jdstrand: it happens on debian, opensuse and now xenial with !patched kernel
[20:43] <jdstrand> oh, that was not clear
[20:43] <zyga> ah, sorry, about that
[20:44] <jdstrand> I don't know of any seccomp patches to our kernel to fix bind
[20:45] <zyga> yeah, it's pretty odd
[20:45] <jdstrand> I'll see if I can trigger it locally, but may not be today-- I have several other people who asked for help from me this afternoon
[20:45] <zyga> OK
[20:45] <zyga> jdstrand: just wanted to let you know that the plot thickens :)
[20:45] <zyga> I think it may be related to apparmor in the end, if we boot a mainline kernel we may run without apparmor so snapctl may end up doing things it normally doesn't because it gets EPERM from apparmor
[20:46] <zyga> jdstrand: this was on libseccomp2 at version 2.2.3-3ubuntu3
[20:48] <jdstrand> zyga: ok 2.2.3 is fine
[20:50] <roadmr> zyga: are you still using git-lp sometimes?
[20:53] <zyga> roadmr: no, just native git
[21:04] <roadmr> zyga even better :)
[21:29] <mwhudson> jdstrand: is there anything i can help with re: bug 1674193 ?
[21:29] <mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <snapd (Debian):New> <openSUSE:Fix Released by morphis> <https://launchpad.net/bugs/1674193>
[21:29] <mwhudson> it seems mostly like people who know more about the innards than me are onto it, but i thought i'd ask
[21:30] <mwhudson> hm not the best timing there, i need to disappear for a while
[21:30] <mwhudson> but anyway, offer stands :)
[21:30] <jdstrand> mwhudson: I'm not looking at it yet, I'm helping pmcgowan with something. I've added it to my list to look at. what I plan to do is boil it down to a simple reproducer so I can hand off to someone
[21:38] <mup> PR snapd#3075 closed: overlord: clean up organization under state packages <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3075>
[22:14] <mwhudson> uh can someone name a trivial confined snap that isn't hello?
[22:17] <sbeattie> mwhudson: pwgen-tyhicks ?
[22:18] <mwhudson> sbeattie: ta
[22:19]  * tyhicks lets out a mwahahaha
[22:20] <roadmr> evil laughter \o/
[22:21] <mwhudson> uh well this is with apparmor off so i guess confined wasn't necessary
[22:22] <mwhudson> wait no it isn't
[22:25] <Pharaoh_Atem> morphis: where are we on merging in the fixes that zyga created for the openSUSE snapd package?
[22:31] <mwhudson> heh debugging things that only happen confined is impressively impossible
[23:22] <mwhudson> how do you make snapcraft actually use your python package when the snapcraft.yaml is in the same tree as your python?
[23:27] <mwhudson> oh apparently i still want the source-type git