[00:21] <mup> PR snapd#2664 closed: cmd: move seccomp cleanup function to seccomp-support <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2664>
[00:52] <mup> PR snapd#2661 closed: tests: skip on untrusted keys <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2661>
[01:44] <wililupy_> I just noticed something interresting. I build an ubuntu-core image with a custom kernel, and when I load the system, it boots up and I can login, but when I look at /lib/modules/`uname -r` there is no directory. Is this something new?
[01:45] <mup> PR snapcraft#1059 opened: pluginhandler: support more complex stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1059>
[01:46] <wililupy_> nm, I think I figured it out.
[01:47] <wililupy_> just to verify in the assertion file, model and gadget are core now, or is it still pc?
[04:19] <mup> Bug #1643292 changed: /snap/bin/hello - fails to execute with apparmor error. <Snappy:Expired> <https://launchpad.net/bugs/1643292>
[05:09] <mup> PR snapd#2666 opened:  Add ability to set system time zone to timeserver_control interface <Created by justincan> <https://github.com/snapcore/snapd/pull/2666>
[08:15] <mup> PR snapd#2637 closed: tests: increase retries for service up <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2637>
[08:47] <mup> PR snapd#2591 closed: wrappers: add DBusActivatable to the allowed values for desktop files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2591>
[09:08] <gbisson> wililupy_: Hi! I have the same issue with latest core (893), how did you fix it?
[09:09] <gbisson> (issue being no /lib/modules nor /lib/firmware)
[09:15] <mup> PR snapd#2667 opened: tests: ensure systemd override directory is available before using it <Created by mvo5> <https://github.com/snapcore/snapd/pull/2667>
[09:39] <morphis_> ogra_: just tried to build the core snap from lp:core-snap, but things are failing with https://paste.ubuntu.com/23832507/
[09:39] <morphis_> ah my fault
[09:39] <morphis_> should run it as root
[09:39] <ogra_> i'ÄD guess some package is missing
[09:40] <ogra_> oh and that, yeah :)
[09:53] <morphis_> ogra_: btw. is there any testing for the core snap?
[09:53] <morphis_> or does that have to go into snapd?
[09:54] <ogra_> theer are regular image tests, yes ... for releasing something into beta/candidate as well as for releasing into stable
[09:54] <ogra_> there are zero tests for edge since that is developer playground and allowed to break
[09:55] <morphis_> ogra_: so where would I add a test for the configure hook I am adding now into lp:core-snap
[09:55] <ogra_> (i'm personally running edge on all boards here though, they auto-update and i usually nothice if they dont boot ... so there is some minimal recofnition of serious breakage)
[09:55] <ogra_> morphis_, you apply a patch to fgimenez i guess ;)
[09:55] <morphis_> hah
[09:56] <ogra_> (the automated spread tests only run for amd64 currently though)
[09:57] <morphis_> hm
[09:57] <morphis_> fgimenez: ping
[09:57] <fgimenez> hey morphis_ :) about the above question you can propose the tests to snapd itself and restrict by system
[09:58] <morphis_> sounds good
[09:58] <morphis_> fgimenez: but that would require me to get a new core snap into edge first, right?
[09:59] <morphis_> ogra_, fgimenez: https://code.launchpad.net/~morphis/core-snap/add-configure-hook-sshd-service/+merge/315203
[10:00] <fgimenez> morphis_, well, you could use the external backend and run against a prebuilt image, that's how we are testing the board images now
[10:00] <morphis_> ah
[10:00] <morphis_> good idea
[10:00] <ogra_> morphis_, thats definitely not enough ... you need to add tests if there is a local login
[10:01] <fgimenez> morphis_, here are the details https://github.com/snapcore/snapd/blob/master/tests/external-backend.md
[10:01] <ogra_> else any admin can accidentially completely lock himself out
[10:01] <morphis_> ogra_: sure, that is why its set as wip
[10:02] <ogra_> morphis_, i'd also use start/stop instead of restart ... but thats just a matter of taste
[10:02] <morphis_> two commands instead of a single?
[10:02] <ogra_> no
[10:02] <ogra_> start for enabled ... stop for disabled
[10:03] <mup> PR snapd#2668 opened: interfaces: abbreviate ConnRef construction <Created by zyga> <https://github.com/snapcore/snapd/pull/2668>
[10:03] <ogra_> but as a i said, matter of taste restart will indeed work fine
[10:04] <ogra_> (it is just that you trigger two actions with it instead of the one you actually want)
[10:07] <morphis_> ogra_: you're ok with the name?
[10:08] <morphis_> was wondering if I should use service.ssh or service.sshd
[10:08] <morphis_> both are the same for systemd
[10:09] <ogra_> yeah, i'm fine with either, make your pick
[10:09] <mup> PR snapd#2665 closed: cmd: more build system cleanups and a small fix <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2665>
[10:09] <ogra_> probably sshd for consistency ... after all you disable the daemon not the client
[10:11] <morphis_> yeah, but that is why it has the service. prefix
[10:11] <morphis_> let me leave service.ssh
[10:11] <morphis_> I guess niemeyer and mvo will have a opinion too :-)
[10:11] <morphis_> ogra_: what would be the best way to check for a local login?
[10:12] <ogra_> hmm
[10:12] <morphis_> passwd -S maybe
[10:12] <ogra_> the most minimal would be to check for non-zero size of /var/lib/extrausers/passwd
[10:13] <ogra_> passwd -S will only show the current user
[10:13] <ogra_> which in case of a config option will be root i guess
[10:13] <morphis_> something like
[10:13] <morphis_> test `passwd -S simon | awk '{print $2}'` = P
[10:14] <ogra_> and how do you know "simon" ?
[10:14] <morphis_> and then looping through the extrausers db and checking each user
[10:14] <morphis_> if one found with passwd then we're ok
[10:14] <morphis_> + check if he is sudo or not
[10:15] <ogra_> ogra@localhost:~$ test -e /etc/sudoers.d/create-user-* && echo foo
[10:15] <ogra_> foo
[10:16] <ogra_> that is probably sufficient for finding out there is an admin user
[10:16] <ogra_> (console-conf creates that file)
[10:16] <morphis_> why that?
[10:16] <morphis_> ah
[10:16] <ogra_> the last bit of the filename is the login
[10:16] <morphis_> but that still doesn't give us if that user has a password set
[10:16] <ogra_> right, then check for that
[10:17] <morphis_> ah
[10:17] <ogra_> should be a cheap way to get the login
[10:17] <morphis_> however in our case that doesn't work :-)
[10:17] <morphis_> as we have a system-user assertion creating a user admin
[10:17] <morphis_> and there could be other user assertions creating different users
[10:17] <ogra_> and that doesnt enable sudo ?
[10:18] <ogra_> all you want to make sure is that there is a sudo user with a password
[10:18] <ogra_> and /etc/sudoers.d/ is the only way to create one, /etc/sudoers is readonly
[10:19] <morphis_> the other question is, this is policy, do we really want to encode this in the option? in our case a management snap will take care about the whole system and will also have access to the extrausers database
[10:19] <ogra_> even your system-user assertion needs to create a file there if there is a sudo capable user
[10:19] <ogra_> hmm
[10:19] <morphis_> so it may want to enforce that there is not a user at all
[10:20] <morphis_> but just the management snap provide a nice UI to manage everything
[10:20] <ogra_> tricky
[10:20] <morphis_> it is
[10:20] <ogra_> and also perhaps something that requires wider discussion via the ML
[10:21] <morphis_> I tend to say this is just meant to turn sshd off and the caller needs to know about the consequences
[10:21] <ogra_> i personally wouldnt allow turning off sshd through a manually toggleable option if there is no way to get in anymore ...
[10:21] <ogra_> probably there is another way to inject that during image creation
[10:22] <ogra_> i belive there will be more images like this where you actually dont want a user to exist ... but at the same time it should never be possible to lock yourself out if one exists
[10:23] <ogra_> probably the answer is to not make the option runtime switchable at all
[10:23] <ogra_> so it can only be triggered by assertion or some such
[10:24] <morphis_> maybe
[10:24] <morphis_> ogra_: let me get a first working version and then we can discuss this further
[10:25] <ogra_> +1
[10:31] <mup> PR snapd#2669 opened: asserts: don't use 'context' for the path of attributes, want to reuse the concept for something else <Created by pedronis> <https://github.com/snapcore/snapd/pull/2669>
[10:32] <mup> PR snapd#2670 opened: tests: use higher version number during tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2670>
[11:19] <mup> PR snapd#2667 closed: tests: ensure systemd override directory is available before using it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2667>
[11:29] <mup> PR snapd#2668 closed: interfaces: abbreviate ConnRef construction <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2668>
[11:38] <morphis_> fgimenez: ok, I've build my own core snap now and use it to generate an image with ubuntu-image, do I have to set anything specific as snapd doesn't accept it or do I have to rebuild snapd in a special way?
[11:58] <morphis_> ogra_: how are you testing locally build core snaps?
[11:58] <ogra_> i boot the image ... install some snaps that use different interfaces (typically htop)
[11:59] <ogra_> and usually i leave the image running and watch it update itself daily (since i most of the time look at edge)
[12:03] <fgimenez> morphis_, i don't think so, you can execute your tests following https://github.com/snapcore/snapd/blob/master/tests/external-backend.md, you could filter by your own test, something like 'spread -v external:ubuntu-core-16-64:tests/main/my-test'
[12:04] <fgimenez> morphis_, the external backend doesn't make any assumption about what snapd is running, it just tries to connect and execute the given tests
[12:08] <morphis_> ogra_, fgimenez: https://paste.ubuntu.com/23833054/ is what I am running into after building an image with $ ubuntu-image --extra-snaps core_16.04.1_amd64.snap -o pc.img pc.model
[12:09] <morphis_> so wondering if there is any trick or if snapd should accept my core snap as is
[12:10] <ogra_> morphis_, and your model assertion is properly signed with a valid key ?
[12:10] <morphis_> ogra_: sure, with my developer key
[12:10] <mup> PR snapd#2670 closed: tests: use higher version number during tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2670>
[12:11] <ogra_> do you see any other errors during boot ? like the firstboot setup job failing or some such ?
[12:11] <ogra_> looks really like the initial device setup didnt run
[12:11] <ogra_> also, does snap list work at all ?
[12:12] <morphis_> it does but lists nothing
[12:12] <morphis_> ogra_: none of the snaps from the seed are imported
[12:12] <mup> PR snapd#2669 closed: asserts: don't use 'context' for the path of attributes, want to reuse the concept for something else <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2669>
[12:13] <morphis_> trying to get a few more details
[12:13] <ogra_> yeah, that smells like the device initialization hasnt run ...
[12:13] <morphis_> ogra_: but yeah, I passed console-con
[12:13] <ogra_> yeah, thats unrelated
[12:14] <ogra_> do you have an existing /var/lib/snapd/seed/seed.yaml and the correct content ?
[12:15] <morphis_> ah seems to be my fault
[12:15] <morphis_> Jan 20 12:13:27 localhost /usr/lib/snapd/snapd[1082]: task.go:303: DEBUG: 2017-01-20T12:13:27Z ERROR rm: cannot remove '/etc/ssh/sshd_not_to_be_run': No such file or directory
[12:15] <morphis_> that fails the the installation of the core snap
[12:16] <ogra_> just add a "|| true" to the end of the line as a quick hack
[12:16] <popey> hm, it's not possible to build classic snaps in lxd due to it needing core installed?
[12:16] <popey> related to bug 1650946 which changed the error message
[12:16] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946>
[12:16] <popey> oh, sergiusens dropped
[12:17] <ogra_> your question probably scared him :)
[12:19] <ogra_> there ... he's back :)
[12:19] <mup> PR snapd#2671 opened: add --classic support to try and revert, and make missing these things a little harder <Created by chipaca> <https://github.com/snapcore/snapd/pull/2671>
[12:37] <oh4> still having issues getting snapd started and not sure what the culprit is
[12:37] <oh4> https://www.irccloud.com/pastebin/JTrFROJh/
[12:39] <mup> PR snapd#2672 opened: cmd: ensure that all .c files have a -test.c file <Created by zyga> <https://github.com/snapcore/snapd/pull/2672>
[12:43] <oh4> mup: is that related to my issue?
[12:43] <mup> oh4: I really wish I understood what you're trying to do.
[12:44] <popey> sergiusens: is there a plan to allow building classic snaps inside cleanbuld lxd?
[12:44] <popey> sergiusens: the error message is now nicer, but... :)
[12:45] <oh4> mup: I am trying to install 'sudo snap install canonical-livepatch' but it requires snapd to be up and running. If I run that command, I get: 'error: cannot communicate with server: Post http://localhost/v2/snaps/canonical-livepatch: dial unix /run/snapd.socket: connect: connection refused'
[12:45] <mup> oh4: Unknown commands are unknown.
[12:45] <oh4> mup: so then I checked snapd and it isn't running and when I try to start it, I get the error above
[12:45] <mup> oh4: Can't grasp that.
[12:47] <seb128> oh4, what's the status of snapd.service ?
[12:49] <popey> oh4: mup is a bot, ignore it.
[12:50] <sergiusens> popey, I discussed on a solution, just need to work on it, it is top two on my list
[12:51] <oh4> popey: oh...lol
[12:51] <oh4> https://www.irccloud.com/pastebin/ecaBvAIR/
[12:51] <oh4> popey: ^
[12:52] <popey> sergiusens: awesome, thanks.
[12:54] <oh4> seb128: I meant you...sorry ^
[12:55] <popey> oh4: is that on ubuntu 16.04?
[12:57] <oh4> yep
[12:57] <seb128> oh4, not snapd.refresh.service, snapd.service
[12:57] <seb128> the refresh is another job
[12:59] <oh4> oops..I meant this, seb128
[12:59] <oh4> https://www.irccloud.com/pastebin/6K03T5Rn/
[13:03] <popey> jdstrand: filed this, but not sure if it's snappy or apparmor.. bug 1658086
[13:03] <mup> Bug #1658086: profile has merged rule with conflicting x modifiers <Snappy:New> <https://launchpad.net/bugs/1658086>
[13:03] <ogra_> oh4, this is a plain local ubuntu desktop or server install ?
[13:04] <oh4> ogra_: desktop
[13:04] <ogra_> oh4, i.e. not some remote cloud system or container or some such
[13:04] <ogra_> k
[13:04] <oh4> yep, my workstation here at home
[13:04] <ogra_> (that should rule out any kernel issues then)
[13:04] <mup> Bug #1658086 opened: profile has merged rule with conflicting x modifiers <Snappy:New> <https://launchpad.net/bugs/1658086>
[13:04] <ogra_> oh4, also using the default kernel from the install ?
[13:05] <oh4> correct, ogra_
[13:05] <ogra_> hmm, weird
[13:05] <oh4> no mods...fresh install yesterday
[13:05] <oh4> even ran full upgrade and nothing
[13:06] <ogra_> yeah, snapd should just run then ...
[13:06] <ogra_> do you see anything intersting grepping fro snapd in syslog perhaps ?
[13:06] <ogra_> *for
[13:09] <oh4> following 'egrep -nri "err|warn|fail" /var/log/syslog", I see the following
[13:09] <oh4> https://www.irccloud.com/pastebin/BfvADh36/
[13:09] <ogra_> just grep for snap or snapd
[13:10] <mup> PR snapd#2673 opened: cmd: add fault injection support code <Created by zyga> <https://github.com/snapcore/snapd/pull/2673>
[13:10] <oh4> but those errors are from when I attempted to use 'snap install canonical-livepatch', I believe
[13:11] <oh4> here some more just for snap
[13:11] <oh4> https://www.irccloud.com/pastebin/4avvevRr/
[13:11] <oh4> it looks like it started at some point?...hmm
[13:12] <oh4> or maybe it try to start when I run 'snap install <package>'
[13:12] <oh4> not sure
[13:15] <ogra_> oh4, well, looks like snapd starts but then fails when the livepatch thing comes into play
[13:16] <ogra_> does "snap list" work ?
[13:16] <oh4> nope, snap list gives the same error
[13:16] <oh4> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
[13:17] <ogra_> what does: dpkg -l snapd return as version ?
[13:18] <oh4> ii  snapd                                                  2.20.1ubuntu1                    amd64                            Tool to interact with Ubuntu Core Snappy.
[13:21] <ogra_> thats running here as well on all my machines ... strange
[13:21] <popey> might need a livepatch kernel person?
[13:21] <ogra_> zyga, what were the magic commands to clear up all snap related bits on a classic install ?
[13:22] <ogra_> popey, yeah, but first we cant even have the core snap installed
[13:22] <ogra_> so first i'D like to get the livepatch snap completely ripped out and snapd into a virgin state
[13:23] <ogra_> the livepatch snap seems to be sitting in queue now so starting snapd will immediately try to run it and fall flat on its face
[13:25] <zyga> ogra_: I don't know if they work now
[13:25] <zyga> ogra_: just prune snapd
[13:25] <zyga> ogra_: er. purge
[13:25] <ogra_> purge you mean
[13:25] <zyga> ogra_: that should do the same
[13:25] <ogra_> oh4, sudo apt purge snapd
[13:25] <ogra_> then install it again
[13:26] <zyga> yep
[13:27] <ogra_> and then try something like: sudo snap install htop
[13:27] <ogra_> or snap install hello or so
[13:27] <ogra_> that should install the core snap alongside
[13:27] <ogra_> after that see if snap list then works
[13:49] <mup> Bug #1658086 changed: profile has merged rule with conflicting x modifiers <eco-team> <Snappy:Confirmed> <https://launchpad.net/bugs/1658086>
[13:55] <sergiusens> diddledan, hey, nice corebird update! Would you mind writing up on the steps you went through to get xdg-open working so others can follow your lead?
[13:56] <mcphail> I'm hacking https://github.com/nextcloud/nextcloud-snap . If I change the apache.conf file (which is from the apache-customizations part) how do I rebuild the snap with just those changes?
[13:56] <diddledan> thanks. I don't think I did anything except installing snapd-xdg-open via apt
[13:56] <diddledan> where would be appropriate to post that? I can pop it on my own site but that won't be very discoverable..
[13:57] <sergiusens> diddledan, is your snapcraft.yaml anywhere I can peek at?
[13:58] <diddledan> yes, it's on launchpad git: https://git.launchpad.net/~diddledan/+git/corebird?h=master
[13:58] <diddledan> the direct link to the yaml: https://git.launchpad.net/~diddledan/+git/corebird/tree/snapcraft.yaml
[13:59] <sergiusens> diddledan, I wonder if it is now part of desktop-gtk3
[14:00] <diddledan> not sure. all I could discern was that the apt package snapd-xdg-open was required and once installed everything "just works"
[14:01] <diddledan> I think it would be nice for snapd deb to depend or recommend that package - it's not discoverable that you need to install it for xdg-open to work
[14:01] <sergiusens> diddledan, well I do have it installed but only yours actually gets it done
[14:02] <sergiusens> seb128, Trevinho would you have an idea about this? ^
[14:02] <diddledan> odd
[14:03] <diddledan> maybe other snaps aren't actually using the xdg-open mechanism but trying to call things directly
[14:03] <diddledan> I can try digging into xorebird source to see whether they shell-out or call the dbus directly
[14:03] <sergiusens> diddledan, that would explain it for some, but not all (I don't think the recent kde frameworks based apps are different)
[14:04] <sergiusens> or maybe it is a case like that
[14:07] <oSoMoN> jdstrand, when you have a minute, may I ask you to review https://myapps.developer.ubuntu.com/dev/click-apps/6219/rev/2/ ? the same warning as my webbrowser-app upload the other day is blocking publication
[14:07] <mcphail> kyrofa_: is there any reason we can't have "AllowOverride All" for the nextcloud install directory, to use the .htaccess file in there? I'm not sure the "Include" directive in your apache.conf is doing what we need it to do...
[14:08] <jdstrand> mhall119: I'll add a todo for the review tools for Exec= so at least if it hits the store, people will get the feedback
[14:13] <seb128> sergiusens, diddledan, what is the question?
[14:15] <sergiusens> seb128, xdg-open (again :-) )
[14:16] <diddledan> ok, the way that corebird calls URLs is via GLib: GLib.AppInfo.launch_default_for_uri (uri, null);
[14:16] <sergiusens> seb128, corebird-diddledan works just fine, wondering why others don't and if there is some sort of guide for this
[14:17] <seb128> sergiusens, gio should work fine
[14:18] <seb128> if the snapd-xdg-open is installed on the system
[14:18] <seb128> which mvo is looking at getting installed by default I think (that was a while ago and I didn't see any update)
[14:19] <jdstrand> popey: it is snappy. I responded in the bug
[14:27] <sergiusens> seb128, great, so if an app in snap calls xdg-open it needs to be provided in the snap?
[14:28] <sergiusens> Or is this a zyga question?
[14:29] <oSoMoN> jdstrand, thanks!
[14:29] <ogra_> sergiusens, it should be used from the core snap (where we install the script yb default)
[14:30] <ogra_> though weather snap-confine allows execution is indeed actually a zyga question
[14:30] <jdstrand> oSoMoN: yw
[14:31] <jdstrand> sergiusens: iirc, no. the xdg-open is in /usr/local/bin in the core snap and snaps have the permissions to call that
[14:32] <jdstrand> I may be misremembering-- the way we do xdg-open is a little twisty
[14:32] <jdstrand> but I don't think the snap has to ship it
[14:34] <ogra_> in fact it breaks if you ship it
[14:34] <ogra_> because then the distro script goes to /usr/bin and overrides the core script in /usr/local/bin
[14:36] <ogra_> (or rather to $SNAP/usr/bin)
[14:49] <mup> PR snapd#2672 closed: cmd: ensure that all .c files have a -test.c file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2672>
[14:50] <mup> PR snapd#2640 closed: interfaces: allow querying added security backends <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2640>
[14:52] <mhall119> thanks jdstrand
[14:55] <mvo> seb128: sorry, I was not pushing snapd-xdg-open recently :/
[14:56] <seb128> mvo, no worry, I just mentioned it because I think you said that it was on some of your backlog
[14:56] <mup> PR snapd#2674 opened: snap: show price in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2674>
[14:59] <mup> Bug #1657752 changed: 'snap find' doesn't tell me the price of a snap I have bought <Snappy:Won't Fix> <https://launchpad.net/bugs/1657752>
[14:59] <mvo> seb128: it is still there, keeps getting pushed aside by more important tasks
[15:03] <seb128> mvo, no worry, thanks for the status update
[15:04] <mup> PR snapd#2630 closed: many: detect potentially insecure use of snap-confine <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2630>
[15:13] <mup> PR snapcraft#1060 opened: options: if host is 32bit use the relative backward compatibility architecture <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1060>
[15:24] <popey> jdstrand: thanks!
[15:27] <zyga> jdstrand: hey, this has been reviwed by two other people and waits for a month for a review; I think we should just merge it and carry on; I have a branch that drops privs around argument parsing and I plan on landing it before actually using this new (parser) module.
[15:27] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2416
[15:27] <mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[15:28] <zyga> *reviewed
[15:28] <zyga> jdstrand: unless you critically want to review it I plan on merging it when it turns green
[15:29] <jdstrand> zyga: as agreed to earlier, this is behind a couple of other things and iirc, tyhicks and I felt it needed a review. please talk to ratliff and tyhicks if you want that prioritized ahead of the current work
[15:30] <jdstrand> also, it is a bit unfair to characterize it in the way you did. yes, it has been open for a month, but it also has never been on the critical path for anything
[15:31] <morphis_> ogra_: Jan 20 15:29:14 localhost.localdomain kernel: audit: type=1400 audit(1484926154.100:17): apparmor="DENIED" operation="exec" profile="snap.core.hook.configure" name="/bin/systemctl" pid=1378 comm="configure" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
[15:31] <morphis_> that is interesting but I guess that is just normal confinement and core isn't taken differently
[15:38] <jdstrand> not to mention, part of that month was a bunch of holidays :)
[15:40] <ogra_> morphis_, see rthe other channel :)
[15:45] <morphis_> ogra_: the above is a different problem
[15:46] <morphis_> ogra_: the access to /run/snapd.socket is a thing I've filed a bug for some weeks ago
[15:46] <ogra_> oh
[15:46] <ogra_> yeah, core has strict confinement by default
[15:47] <kyrofa_> mcphail, doing that wastes resources because it crawls looking for that file on requests. The idea was to disable it in order to obtain better performance on low-end hardware (e.g. the rpi2)
[15:48] <kyrofa> mcphail, my research led me to believe the Include was equivalent but had the downsides I mentioned in the comment
[15:50] <morphis_> ogra_: guess we need an interface or so
[15:51] <ogra_> could be, not sure, i think pstolowski might know more how it is supposed to work in core
[15:51] <ogra_> i'd actually not expect an interface to be needed here
[15:58] <tyhicks> zyga: hey - I'll set aside this seccomp work and review the arg parsing PR
[15:58] <mup> PR snapd#2675 opened: asserts: implement SuggestFormat to help avoid specifying the wrong format iteration for an assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/2675>
[15:58] <tyhicks> that code is in too critical of a section to not receive a close security review
[16:03] <mcphail> kyrofa: I'm still experimenting, but it works if I AllowOverrides but not with the Include. I'll keep hacking. Hadn't thought of htaccess causing a performance hit
[16:05] <kyrofa> mcphail, yeah, check this out: https://httpd.apache.org/docs/2.4/misc/perf-tuning.html
[16:07] <mup> PR snapcraft#1061 opened: Fix Exec key in desktop files for apps named like their parent package (LP: #1658123) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/1061>
[16:08] <zyga> tyhicks: thanks!
[16:08] <zyga> jdstrand: ack
[16:08] <mcphail> Looks like we really do need to get this in the conf file if possible, although I don't think performance gains are worth the loss in functionality if we can't get it to work
[16:09] <zyga> jdstrand: (I didn't think of the holidsys, sorry about that)
[16:10] <kyrofa> mcphail, agreed
[16:10] <kyrofa> mcphail, so it works with no other changes if you just allowoverride all ?
[16:11] <pstolowski> ogra_, i'm not sure what was the question... was it far it the backlog? looks like it's not about snapd.socket again;) ?
[16:12] <ogra_> pstolowski, yeah, that tricked me too on first sight ;) morphis_ is actually calling systemctl there from his core config hook
[16:12] <mcphail> kyrofa: i've made a few changes, including changing that alias for acme-challenge. I need to unpick them now and see what breaks
[16:13] <ogra_> pstolowski, and gets a denial ... should that work ?
[16:17] <pstolowski> ogra_, oh, sorry, i'm familiar with that.. zyga may know?
[16:18] <pstolowski> *i'm not*
[16:18] <mup> PR snapd#2676 opened: cmd: collect string utilities in one module, add missing tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2676>
[16:18] <kyrofa> ogra_, how does confinement work on the core snap?
[16:19] <kyrofa> ogra_, obviously on a normal snap a denial would be expected
[16:19] <ogra_> kyrofa, heh, no idea, thats a snapd/snap-confine question
[16:19] <kyrofa> ogra_, does the core snap have any apps?
[16:19] <ogra_> nope
[16:19] <kyrofa> ogra_, that'd be a good way to experiment-- make an app and see if it's confined
[16:19] <ogra_> but it is supposed to have a config hook option
[16:19] <kyrofa> I suspect it is
[16:20] <kyrofa> But then... it's trying to execute stuff within it so
[16:20] <kyrofa> Odd
[16:25] <jdstrand> davidcalle: hi! you probably have in your email something about a new version of the security whitepaper
[16:25] <jdstrand> davidcalle: but if not, I just updated it for a bunch of series 16 items, urls, etc
[16:27] <davidcalle> jdstrand: how do you know I was going to ask you about an eta for the next update? :)
[16:27] <jdstrand> davidcalle: hehe
[16:28] <jdstrand> davidcalle: I'd been getting an inkling recently that people might have been reading that doc which had a few out of date items. I guess you had the same inkling :)
[16:30] <davidcalle> jdstrand: indeed, also, we have been discussing the doc recently in the Marketing team, so, good timing :) I'll publish it on monday, I'm about to eod
[16:31] <zyga> ogra_, pstolowski: how can I help?
[16:32] <pstolowski> zyga, <ogra_> pstolowski, yeah, that tricked me too on first sight ;) morphis_ is actually calling systemctl there from his core config hook
[16:32] <pstolowski> zyga, <ogra_> pstolowski, and gets a denial ... should that work ?
[16:32] <zyga> pstolowski: no
[16:33] <ogra_> morphis_, ^^^
[16:33] <jdstrand> davidcalle: thanks. I'm not sure where the doc fits in wrt recent documentation discussions, but it is in the form it is in due to customer requirements (ie, PDF). if the format needs to change (eg, to markdown), I'd be happy to review the conversion but you might want to talk to awe_ about the customer requirement
[16:33] <zyga> morphis_: systemctl talks to systemd over dbus and your hook is confined
[16:34] <zyga> jdstrand: I'd love to put the whitepaper on the wiki
[16:34] <zyga> jdstrand: if you want I can do that
[16:34] <jdstrand> zyga: let davidcalle, marketing and awe discuss that
[16:34] <jdstrand> it is in the format it is in based on custor requirements. maybe those requirements changed or can change
[16:35] <jdstrand> customer*
[16:35] <awe_> jdstrand, I don't think it's a requirement that the document be in PDF form, especially when it's something public like your whitepaper.
[16:36] <jdstrand> awe_: you'd be surprised. they very specifically wanted a PDF whitepaper
[16:36] <awe_> jdstrand, I can think of some other PDFs that might be useful to land on the wiki (TPM2)
[16:37] <awe_> jdstrand, OK I'll check with Ak on where that came from
[16:37] <jdstrand> awe_ (cc davidcalle): of course, there is nothing saying the source form couldn't be markdown and that converted to PDF. at the time of the requirement, people said a google doc was better
[16:38] <awe_> jdstrand, the original document was a gdoc, so I think we need to ask Google for an "export to markdown" function
[16:38] <awe_> ;)-
[16:38] <awe_> jdstrand, +1
[16:38] <jdstrand> anyway, I don't think it is a big deal, just want to make sure all the stakeholders agree
[16:38] <jdstrand> awe_: hehe :)
[16:38] <awe_> sure, as mentioned I'll check with ak
[16:38] <jdstrand> thanks
[16:44] <zyga> jdstrand: there's a markdown -> latex tool that could give us acceptable output
[16:46] <mup> PR snapcraft#1008 closed: Add a simple straightforward conan.io plugin <Created by Fohlen> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1008>
[16:46] <larryprice> hello! i'm trying to wrap my head around the "alias" property in snapcraft - i built/installed the my-alias snap in snapcraft/integration_tests/snaps/alias, but i don't see any aliases in /snap/bin?
[16:46] <larryprice> latest zesty, so snapd 2.21 and snapcraft 2.25
[16:50] <zyga> larryprice: I think it's too late this week; Ask pedronis` next week
[16:53] <larryprice> zyga, ok thanks
[16:59] <Chipaca> larryprice, I think your snapd needs to be really new to get aliases automatically
[17:00] <Chipaca> larryprice, and it's possible the 'alias' snap doesn't have auto-aliases
[17:00] <Chipaca> dunno
[17:00] <larryprice> Chipaca, hmm what do you mean auto-aliases?
[17:01] <mup> PR snapcraft#1017 closed: make: add support for cwd path <Created by 3v1n0> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1017>
[17:01] <mup> PR snapcraft#1018 closed: autotools: extend Make plugin instead of repeating code <Created by 3v1n0> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1018>
[17:01] <Chipaca> i'm not sure right now if you need anything extra for them to happen on their own
[17:01] <kyrofa> Chipaca, i.e. that's something controlled by declarations?
[17:01] <Chipaca> i think so, but i'm not 100%
[17:02] <kyrofa> jdstrand might be able to verify that
[17:02] <larryprice> maybe they don't happen automatically in devmode? seems the lxd aliases are working as expected
[17:03] <morphis_> zyga: yeah feared that, somehow thought core is taken differently than other snaps :-)
[17:03] <Chipaca> larryprice, try installing test-snapd-auto-aliases
[17:03] <jdstrand> a store reviewer can setup auto-aliases today. for example, the lxd snap uses it
[17:04] <jdstrand> Chipaca, kyrofa: ^
[17:04] <kyrofa> jdstrand, so it is an assertion-related thing?
[17:04] <Chipaca> jdstrand, thanks for the confirmation
[17:04] <larryprice> Chipaca, ah ok that did install what looks like aliased snaps
[17:04] <jdstrand> kyrofa: yes
[17:04] <kyrofa> Good deal, thank you :)
[17:05] <Chipaca> larryprice, so in your snap.yaml you ask for them, but you get them from the store with human intervention
[17:05] <jdstrand> the snap declares its aliases. the user makes them go live on the system. a snap declaration can make that automatic
[17:05] <Chipaca> larryprice, jdstrand said it so much better :-)
[17:05] <larryprice> Chipaca, jdstrand, ok this is all adding up now
[17:06] <jdstrand> larryprice: they store isn't going to block or anything if you declare them. the user installs your snap and can decide to apply the aliases. in some cases, it might make sense to have a snap declaration in the store to tell snapd to do it automatically
[17:07] <larryprice> jdstrand, who should i contact when requesting an auto-alias for one of my subcommands (canonical-owned snap)?
[17:09] <jdstrand> larryprice: there isn't a form to request them, so you would need to ping a reviewer: https://launchpad.net/~myapps-reviewers/+members#active
[17:10] <larryprice> jdstrand, ok good to know
[17:10] <larryprice> Chipaca, jdstrand, thanks!
[17:10] <Chipaca> larryprice, meanwhile, "snap alias" is your friend
[17:11] <Chipaca> larryprice, and "snap aliases" if your snap/d is new enugh
[17:23] <mup> PR snapd#2677 opened: snap: improve the error message for `snap try` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2677>
[17:25] <gbisson> wililupy_: around?
[17:28] <wililupy_> yes.
[17:28] <wililupy_> gbisson: what can I do for you?
[17:31] <telelaci> Hi wililupy can I have a question
[17:31] <Blu2> thank you for https://tutorials.ubuntu.com/ !!
[17:31] <wililupy> telelaci: Sure
[17:31] <telelaci> yesterday you said your /lib/modules dir has disappeared
[17:31] <telelaci> i have the same problem
[17:32] <telelaci> /li/modules and /lib/firware both totally empty
[17:32] <kyrofa> Blu2, has it proved helpful?
[17:32] <telelaci> but if I extract the kernel snap , the files are inside
[17:32] <gbisson> wililupy: yes, telelaci is taking over, we have the same question ;)
[17:32] <wililupy> telelaci: yes. I had this happen in the past when I built images and didn't use specific names for my kernel snap.
[17:33] <telelaci> and it this was good last week
[17:33] <telelaci> what specific names ? what do you mean ?
[17:33] <Blu2> kyrofa, not yet, but I will take a closer look at it tonight :)
[17:34] <kyrofa> Blu2, if you do, you should send a note to the list-- its authors are on a different timezone and I'm sure they'd love to see that it was helpful
[17:35] <zyga> tyhicks: thank you for the review
[17:35] <wililupy> I used to say my kernel was the actual kernel_4.8.0-RC1_amd64.snap name in my assertion instead of the name: value in my snapcraft.yaml for my kernel, which was kernel. Once I put kernel: kernel and then when I built the image used the --extra-snaps=kernel_4.8.0-RC5_amd64.snap everything worked.
[17:35] <zyga> tyhicks: I'll read it and try to get back to you quickly
[17:36] <wililupy> However, I ran into this problem yesterday becuase my model: pc needed to be changed to model: core. I'm testing it right now to verify that this fixes it. If it does, I'll let everyone here know.
[17:37] <mup> PR snapcraft#1062 opened: tour: add g++ as dependency to 01-reusable-part <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1062>
[17:38] <telelaci> thank you so much I had no idea at all, because I couldn't even roll back the project on git, last week worked, today doesn't work. the same code
[17:40] <telelaci> please share everything what you experience with this thing, because its very mysterious error
[18:12] <wililupy> hmm. Interresting. I now get the lists of installed snaps, where I wasn't getting that before, but I still don't have anything mounted in /lib/modules from my kernel snap. They are all there in my /snap/kernel/x1 directory. Anyone else here in the channel have any insight?
[18:16] <mup> PR snapcraft#1063 opened: file_utils: copy symlinks to directories as symlinks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1063>
[18:35] <telelaci> wililupy: same here. but not only /lib/modules , but /lib/firmwares as well.
[18:35] <wililupy> telelaci I see that as well.
[18:35] <telelaci> do you have the /lib/firmwares in place ?
[18:37] <telelaci> wililupy: none of them mounted in your system as well, or just the modules missing ?
[18:37] <palasso> hey is this website new? https://tutorials.ubuntu.com/
[18:38] <wililupy> telelaci: none mounted. and I'm not seeing any errors specific to this.
[18:38] <telelaci> same
[18:39] <telelaci> but of course the system doesn't work properly without firmware and modules
[18:45] <mterry> I notice that snapd trunk can't be built as a deb without first getting all the deps, which requires network access.  Looks like for archive builds, you folks release a tarball with all the deps built in to get around this.  Is that a desired setup, or would a pull that changes the debian packaging to Build-Dep on the various golang packages in the ubuntu
[18:45] <mterry> archive to get the deps instead be welcome? (with the goal of being able to PPA-build a git branch directly)
[18:54] <mup> PR snapd#2678 opened: interfaces: interface to allow autoilot introspection <Created by sbaldassin> <https://github.com/snapcore/snapd/pull/2678>
[19:09] <pedronis`> mterry: the switch to vendoring was a conscious decision, it was setup the other way around before
[19:13] <mterry> pedronis: understood, thanks.  Makes playing with a patched snapd harder, but I assume there was good cause behind the change somewhere
[19:56] <mterry> jdstrand, slangasek, ratliff: Is bug 1658181 accurate?  I just noticed this, and jdstrand didn't know about it, just wanted to make sure if this was a discussion I missed
[19:56] <mup> Bug #1658181: snapd bundles golang dependencies despite being in main <snapd (Ubuntu):New> <https://launchpad.net/bugs/1658181>
[19:59] <jdstrand> it looks accurate to me. JamieBennett should be made aware as well, but he seems offline atm
[20:01] <mterry> pedronis ^ can you offer any history for that decision in the bug, if you know it?
[20:32] <slangasek> mterry: yes, I raised that with the snappy and security teams when that change went through
[20:33] <mterry> slangasek: ah good cool.  Was there a satisfying conclusion and I can close that bug or is the bug still useful?
[20:33] <slangasek> mterry: I didn't really see much follow-up tbh; I passed it over to the security team, they were aware of it
[20:45] <jdstrand> slangasek: I don't recall seeing this (maybe I am misremembering). ratliff and tyhicks, did you? ^
[20:48] <tyhicks> mterry, slangasek, jdstrand: I don't recall a discussion around snapd vendorizing packages
[20:49] <tyhicks> I have had some discussions around other projects vendorizing things in stable releases when they have new upstream releases that depend on packages that aren't in the archive
[20:49] <tyhicks> I don't recall that for snapd though
[20:54] <slangasek> tyhicks: I sent mail on it Oct 12 to you + ratliff
[20:55] <slangasek> tyhicks: with an earlier thread Oct 6 to ratliff + JamieBennett + mvo
[20:57] <tyhicks> ok, I see the Oct 12 email
[21:04] <tyhicks> jdstrand: if they're build-depending on dh-golang, is it sufficient to have just the following line in the control file for snapd:
[21:04] <tyhicks> Built-Using: ${misc:Built-Using}
[21:04] <tyhicks> seems like that's probably not sufficient
[21:04] <tyhicks> for us to track everything
[21:27] <jdstrand> tyhicks: no. built using is useful for static build that use golang-*-dev packages from the archive
[21:27] <jdstrand> tyhicks: they are using embedded copies and thus can't be tracked
[21:27] <jdstrand> tyhicks: unless we put that somewhere
[21:27] <tyhicks> oh, right
[22:45] <mcphail> kyrofa: sent a PR. I think this fixes things. dav .well-known paths and let'sencrypt both seem to work
[22:49] <mup> PR snapcraft#1064 opened: pluginhandler: support colliding with directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1064>
[22:51] <kyrofa> mcphail, thank you for reading the contributing guide :)
[22:51] <mcphail> kyrofa: hah!
[22:52] <kyrofa> You're the first to get it right!
[22:52] <kyrofa> Dang, even the commit message
[22:52] <mcphail> kyrofa: having vim set up correctly to nag makes commit messages easier
[22:53] <kyrofa> mcphail, I've got a few questions-- want to chat here, or want me to comment on the PR?
[22:54] <mcphail> kyrofa: either is fine. GH may be better to keep conversation documented
[22:54] <kyrofa> mcphail, alright
[22:55] <kyrofa> mcphail, wait, I lied-- I answered my own question. This looks really nice, thank you :) . I'll take it for a spin
[22:56] <mcphail> kyrofa: quite late here, so I'll catch any questions in the morning
[23:22] <mup> PR snapcraft#1057 closed: godeps plugin: support for go-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1057>