#snappy 2015-11-23
<General-Beck> hi2all! How to me to create the folder in a HOME directory of application before its start in start.sh? if i use mkdir -p $HOME/folder i see in log ubuntu-core-launcher mkdir: cannot create directory â/folderâ: Read-only file system
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy Monday, and happy Fibonacci Day! ð
<Chipaca> longsleep: moin! did you ever file a bug about wait4network not coming after firstboot?
<Chipaca> or was it frameworks.target not coming after firstboot
<Chipaca> i can't find it, so i'm going to assume you didn't
<kyrofa> Good morning
<kyrofa> sergiusens, I'm getting a plainbox crash in snapcraft... not super familiar with it
<kyrofa> sergiusens, http://pastebin.ubuntu.com/13476687/ any ideas?
<sergiusens> kyrofa, are you on xenial? if not, add the ppa from the docs
<kyrofa> sergiusens, the docs say only if 15.04 or previous. I'm on wily-- should the docs say 15.10 or previous?
<sergiusens> zyga, ^
<sergiusens> kyrofa, paste me the plainbox error just in case
 * zyga looks
<kyrofa> sergiusens, http://pastebin.ubuntu.com/13476687/
<sergiusens> kyrofa, are you adding stuff, but the traceback, the name of the test is the problem?
<zyga> kyrofa: odd, can you tell me if that's vanilla or did you change anything to trigger that?
<longsleep> Chipaca: hey i am playing around with your http.chipaca snap and wanted to try snapd with it - though i get a audid DENIED on /run/snapd.socket - any ideas?
<zyga> kyrofa: and if you did, can you run ./manage.py validate please
<kyrofa> zyga, just cloned snapcraft, installed deps in debian/control + plainbox, and ran tests
<zyga> kyrofa: hmmm
<zyga> kyrofa: thanks, please file a bug on plainbox and attach this backtrace
<zyga> kyrofa: I'll see if I can replicate that
<kyrofa> zyga, sure!
<zyga> kyrofa: it looks really weird on first look
<Chipaca> longsleep: the socket is 0600 so you need sudo for any op for now
<longsleep> Chipaca: i am running as root
<Chipaca> longsleep: also it'll only work on rolling without more fiddling
<longsleep> Chipaca: ah
<Chipaca> as 15.04 still uses @snapd, not /run/snapd.socket
<longsleep> Chipaca: Ah so i would need to change the aa profile to get it running?
<longsleep>  addr="@snapd" i see in that
<zyga> kyrofa: please ping me with the URL or assign the bug to me (zyga)
<Chipaca> longsleep: the .socket file (you can copy it to /etc/systemd/system and edit it there)
<Chipaca> longsleep: and even then you probably need to change something in apparmor
<longsleep> Chipaca: ok :) - so the snapd profile is essentially broken on 15.04 then?
<kyrofa> zyga, will do. I'm gonna toast my lxc and try clean one last time, then I'll log it
<Chipaca> longsleep: yeah :-( /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/snapd is still @snapd
<Chipaca> hmmm
<zyga> kyrofa: thanks
<Chipaca> longsleep: what happens if you edit "do" to use \0snapd?
<longsleep> Chipaca: let me check
<longsleep> Chipaca: ConnectionRefusedError(111, 'Connection refused')
<Chipaca> sigh
<Chipaca> longsleep: i'll play with it in 15.04 and see how i can make it work
<Chipaca> longsleep: you're not the first person to ask me this :)
<Chipaca> i think olli was always wanting this
<Chipaca> but, priorities
<Chipaca> (it might'v been asac wanting http.chipaca on 15.04)
<longsleep> Chipaca: cool - i am not so much about the http snap, i rather want to play with snapd to check if i should go through it or rather import snappy directly to read and sed configuration
<Chipaca> longsleep: ah! that's an easy one to do
<Chipaca> longsleep: sudo /lib/systemd/systemd-activate -l 8080 /usr/bin/snapd
<longsleep> Chipaca: ah ok
<Chipaca> longsleep: tadaa, snappy rest daemon on 8080
<Chipaca> longsleep: *unauthenticated*
<longsleep> awesome - thanks!
<Chipaca> (you just gave root to the network)
<longsleep> sure
<longsleep> fie with me :D
<longsleep> fine
<Chipaca> but, for testing, in a vpn or whatever, you're fine :)
<kyrofa> zyga, yeah still hitting this. You want the bug filed against plainbox even though this is in snapcraft?
<zyga> kyrofa: yes
<zyga> kyrofa: please
<zyga> kyrofa: I'll re-assign if needed
<kyrofa> Doing now
<zyga> thank you
<longsleep> Chipaca: regarding snapd, i am retrieving ubuntu-core.ubuntu.config with GET and trying to PUT this back, is that supposed to work?
<longsleep> Chipaca: i just get line 1: cannot unmarshal !!str `modprob...` into coreconfig.configYaml
<kyrofa> zyga, https://bugs.launchpad.net/plainbox/+bug/1519008
<ubottu> Launchpad bug 1519008 in PlainBox (Toolkit) "Plainbox crash: AttributeError: 'NoneType' object has no attribute 'replace'" [Undecided,New]
<zyga> kyrofa: thank you, I just prepared a xenial environment to run some tests
 * zyga hopes to get up to speed with go so that he can still maintain useful add-ons to plainbox and checkbox
<zyga> kyrofa: wait, wily or xenial?
<kyrofa> zyga, wily (the docs led me to believe wily was okay-- should this be xenial instead?)
<kyrofa> zyga, I can re-test in xenial
<zyga> kyrofa: no, that's okay, I misundertood you earlier
<zyga> kyrofa: wily is fine
<longsleep> Chipaca: ok got it, yaml format issue. Another question though, probably general to snappy config, how do i delete nodes from the yaml when they there added before?
<longsleep> Chipaca: fyi, when using the updated content for /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/snapd from xenial/ubuntu-core-security-apparmor http.chipaca works just fine on 15.04/stable
<longsleep> Chipaca: i think i patch the profile in our rootfs and go forward with connecting to snapd via /run/snapd.socket
<longsleep> Chipaca: is anyone actually using the abstract snapd socket? If not i suggest the next rootfs for 15.04 should have a fix for the snapd socket policygroup
<elopio> fgimenez: ah, another thing I tried last week was to attach the failure reason into the subunit file. But I found that requires a change in gocheck.
<elopio> you know, to avoid that StringException that is shown on jenkins.
<fgimenez> elopio, it would be very helpful
<elopio> I think that will be one of the priorities for the following weeks, show nice errors.
<fgimenez> elopio, yes, once the pull requester has access to the results having the failure reason right there would be much better
<elopio> nessita: Chipaca: mvo: now I'm getting 401. This one is new.
<elopio> hello-world failed to install: received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/anon/download/canonical/hello-world.canonical/hello-world.canonical_1.
<elopio> 0.18_all.snap
<elopio> Has happened like 2 times out of 4 today.
<nessita> elopio, myapps is failing atm, we're working on that
<nessita> elopio, you shouldn't get a 401 but some 500, you sure is a 401?
<Chipaca> longsleep: no, nothing is using the abstract socket. Need to check with jdstrand_ but I suspect we can bump the policies in the next 15.04 (if there is a next 15.04)
<elopio> nessita: yup, 401.
<elopio> Here's another:
<nessita> elopio, what API call is returning 401?
<elopio> hello-dbus-fwk failed to install: received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/anon/download/canonical/hello-dbus-fwk.canonical/hello-dbus-fwk.can
<elopio> onical_1.0.2_multi.snap
<elopio> the code says: // try anonymous download first and fallback to authenticated
<elopio> so maybe it gets a 500 on the anonymous downlaod, and then a 401 on the authenticated.
<elopio> it's a GET on that URL of the snap.
<elopio> nop, that's not what it's doing.
<mvo> jdstrand_: if I could get approval for "ubuntu-classic.mvo" that would be neat. its a first iteration of the ubuntu-classic mode for snappy
<noise][> nessita: elopio: i had a brief spat of 401s from downloads from public.apps.u.c. as well
<noise][> but resolved itself
<nessita> noise][, we have fixed the store
<nessita> I wonder why a 500 from the store would be a 401 in updown
<nessita> I should check the code
<noise][> not sure, let me know if you need timestamps of my 401s
<sergiusens> elopio, shall we wait for your PR to release a new snapcraft?
<sergiusens> if not, then a sort of final test run would be good today
<elopio> sergiusens: no. There are no regressions. I can do exploratory today and you can release unless I find something big.
<elopio> sergiusens: do you have a nice list for this milestone?
<sergiusens> elopio, sounds good
<sergiusens> elopio, https://launchpad.net/snapcraft/+milestone/0.5
<sergiusens> same old place :-)
<elopio> thanks.
<tsimonq2> hmm, how would I go about contributing to Snappy?
<tsimonq2> I am just not finding that clear of information on this
<tsimonq2> just how to install Snappy and use it
<pixel_> tsimonq2, https://developer.ubuntu.com/en/snappy/start/ ?
<pixel_> tsimonq2, https://github.com/ubuntu-core
<tsimonq2> pixel_: that is just getting started and developer/usage tips, no?
<pixel_> tsimonq2, yes how to install and use snappy
<tsimonq2> pixel_: but what about actually *contributing*?
<pixel_> tsimonq2, https://launchpad.net/snappy (lp) https://github.com/ubuntu-core (github) mailing lists https://lists.ubuntu.com/archives/snappy-app-devel/ + https://lists.ubuntu.com/archives/snappy-devel/
#snappy 2015-11-24
<liuxg> does anyone know how to install mysql into snappy?
<fgimenez> good morning
<dholbach> good morning
<dholbach> tedg, do you know how close we are to releasing snapcraft 0.5?
<mattyw> morning folks - the first thing to be said is that I'm very new to setting up bridge networks - so go gentle, but is there any equivalent to bridge-utils for snappy? I'm trying to create a bridge so I can create lxc containers that get ip addresses from my router, but I don't see a simple way of being able to create a bridge device
<JamesTait> Good morning all; happy Tuesday and happy Celebrate Your Unique Talent Day! ð
<asac> Chipaca: yeah, so having rest api working (TM) on 15.04 would be great
<tsimonq2> hmm, are there any snaps that need to be made? :P
<sergiusens> tsimonq2, can you maybe be more specific?
<tsimonq2> sergiusens: or rather tasks that need to be done? I would like to contribute to Ubuntu Snappy
<sergiusens> tsimonq2, you can try and write a snapcraft plugin to handle a source type if you want; there are snappy clinics on youtube getting into the basics
<sergiusens> another things could be using Ubuntu Core, finding bugs and maybe fixing them
<sergiusens> not sure what you are into
<elopio> plars: I need to look at the output of the latest script. Can you get it for me please?
<elopio> I think it would be easier if I add set -x and rerun, right?
<kami__> Hi. I have installed snappy ubuntu core on raspberry pi 2. Does anyone know if it's possible to compile Qt for it?
<kgunn> tedg: ping
#snappy 2015-11-25
<liuxg> when I am trying to config a snap, I get the following error http://paste.ubuntu.com/13499100/. what could be the reason for it?
<liuxg> how to set a locale for my raspberry pi device. I get the error like http://paste.ubuntu.com/13499347/
<dholbach> good morning
<dholbach> liuxg, looking at the webcam example right now
<liuxg> dholbach, ok. thanks!
<liuxg> dholbach, I just installed the latest snapcraft 0.5 version, and I got the error like http://paste.ubuntu.com/13500846/
<dholbach> liuxg, I don't see that happening here... the .snap build succeeds for me
<dholbach> which version of Ubuntu are you using?
<liuxg> dholbach, I am now on vivid, and I am using snapcraft 0.5
<liuxg> dholbach, what is your snapcraft version?
<dholbach> liuxg, I'm just using it from the git branch
<liuxg> dholbach, liuxg@liuxg:~/snappy/examples$ snapcraft version snapcraft (0.5).Run "snapcraft help" to get started.
<dholbach> ok
<dholbach> that's the most recent
<liuxg> dholbach, what is your version in your place? I just re-pulled the code, and I got the same error in my place.
<dholbach> 481c79b7cee578e793baaf02bb733f1e14e1bd29 is the last commit
<dholbach> liuxg, did you make modifications to the snapcraft.yaml in that directory?
<liuxg> dholbach, how did you install your snapcraft? I used ./setup.py build and sudo ./setup.py install
<dholbach> git clone <branch> and then I ran it with ../../bin/snapcraft
<dholbach> I didn't install it locally, but used the version from the archive
<liuxg> dholbach, no, I did not do any change. It complained "DEPRECATED: plugin names ending in -project are deprecated. Using python3 instead of python3-project". I changed it to python3, and I got the same error.
<dholbach> that's a warning only, I'll submit a fix for that
<liuxg> dholbach, yes, you are right. your way worked. I do not know how come I did not install it successfully?
<dholbach> maybe send a mail to the mailing list about it?
<liuxg> dholbach, yeah, I think it is a good idea
<liuxg> dholbach, by the way, what is the use of the setup.py there in the project?
<dholbach> it's used internally for building the package for the ppa and the archive
<dholbach> liuxg, https://github.com/ubuntu-core/snapcraft/pull/115/files for the warning you saw earlier
<liuxg> dholbach, I got it. so for the project itself, it is no much use, right?
<dholbach> I'm not sure I understand the question
<liuxg> dholbach, what i mean is that setup.py in the example project is only for ppa use, not for building the snap purpose :)
<dholbach> oh.... sorry
<dholbach> in which example project?
<dholbach> in the webcamui?
<dholbach> there it's used to install the relevant file in the right places
<dholbach> it's the project's "build system"
<liuxg> dholbach, yes, it is in the webcam-webui project https://github.com/ubuntu-core/snapcraft/blob/master/examples/webcam-webui/setup.py
<liuxg> dholbach, do we need to use it for any purpose from a developer point of view?
<dholbach> yep, it's used by 'snapcraft build'
<dholbach> when it uses the python3 plugin
<liuxg> dholbach, so for the snapcraft.yaml, it is of no use?
<dholbach> it is of use
<dholbach> python3 or python2 projects use setup.py
<dholbach> the cmake plugin uses CMakeLists.txt
<dholbach> etc
<liuxg> dholbach, so, it is used there for the python3 plugin during the compile process?
<dholbach> yes
<dholbach> so whenever you use a certain plugin, your project needs to fulfil y certain set of requirements
<liuxg> dholbach, I used to compile a python project, in fact, I did not use the setup.py, and it worked directly.
<liuxg> dholbach, this is the one https://github.com/campbieil/mqtt-for-ubuntu-core
<fgimenez> good morning
<dholbach> liuxg, if you look at the snapcraft.yaml it uses the python3 plugin
<dholbach> liuxg, and if you look at the source it's pulling in (https://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.python.git/tree/), there's a setup.py
<zyga> morning
<liuxg> dholbach, oh, thanks. I will check it. by the way, do you know how to use golang to do the config for snappy?
<dholbach> golang and config are two separate things
<dholbach> go is a plugin just like python3 or cmake or node or anything else - the way the project is built
<dholbach> the config is a layer on top of that
<liuxg> dholbach, I mean if you have any examples showing how to do the config in golang. Currently, all of the samples use python to do that.
<liuxg> dholbach, webcam-webui is a good project. however, it involves too many technologies:ãgolang, script, python, c. For developers, it is not easy to master all of these. I think it is good to stick to a narrow set,
<dholbach> I don't know if there's an example for that
<dholbach> but seriously, you can have config on top of any plugin you like, it's a separate thing
<liuxg> dholbach, if is true. We can manually handle that as well. Still a programming way makes it easier.
<dholbach> kind of like you can have services and binaries defined in a snap, no matter which plugin was used to build the part(s)
<liuxg> dholbach, I think it is good to provide the solution in different method in addition to the python one in the example.
<dholbach> right
<liuxg> dholbach, I just sent an email to the snappy mailinglist for the build problem.
<dholbach> ok cool
<liuxg> dholbach, may I ask whether there is any golang solution to the config?
<dholbach> I don't know
<liuxg> dholbach, in the webcam-webui example, config.py is finally copied to the /usr/bin/config.py. how can this be done in the snapcraft.yaml? I do not see the copy there.
<dholbach> liuxg, it's installed via setup.py - see the scripts definition in there?
<liuxg> dholbach, yeah, I see config.py there. is this unique to the python?
<dholbach> yes, in setup.py you can define modules, data files, scripts and other stuff
<dholbach> scripts are automatically installed into usr/bin
<liuxg> dholbach, it looks a new syntax to me anyway.  I just take it for granted!
<dholbach> in the python world it's very nice and easy to use
<liuxg> dholbach, in fact, there is a bug for it. http://paste.ubuntu.com/13501234/
<liuxg> dholbach, in the final installation, the config.py is not there even though it appears in the "snap" directory
<dholbach> I don't understand
<liuxg> dholbach, you just deploy the snap, and on the target, you do not find the config.py file there in the /usr/bin directory
<dholbach> it is there
<dholbach> aniel@daydream:~/dev/snappy/snapcraft/examples/webcam-webui$ dpkg -c webcam-webui_1_amd64.snap | grep bin/config.py
<dholbach> -rwxrwxr-x root/root       246 2015-11-25 10:15 ./usr/bin/config.py
<dholbach> daniel@daydream:~/dev/snappy/snapcraft/examples/webcam-webui$
<liuxg> dholbach, have you installed it onto KVM?
<dholbach> no, this is just locally
<dholbach> I ran the build and inspected the resulting snap file
<liuxg> dholbach, strange. let me reinstall it.
<liuxg> dholbach, sorry, I found it in the /usr/bin directory. However, when I ran th config, I got an error like http://paste.ubuntu.com/13501276/
<liuxg> dholbach, what doe exactly the config file look like? I cannot create one.
<dholbach> can you file a bug about this?
<dholbach> it looks like a bug
<liuxg> dholbach, against snapcraft project? did you duplicate this in your place?
<dholbach> I'm busy with something else right now, so I didn't try it locally yet
<liuxg> dholbach, ok. I will file a bug for it.
<JamesTait> Good morning all; happy Wednesday, and happy Shopping Reminder Day! ð
<Chipaca> liuxg: to know the os version, 'snappy info' and 'snappy list' together would work
<liuxg> Chipaca, interesting, lsb_release -a command works as well. Description:	Ubuntu 15.04. so what is the right command to turn the autopilot off?
<liuxg> Chipaca, snappy info and snappy list do not tell me the OS version.
<Chipaca> liuxg: well then you mean something different than I understand by âOS versionâ
<Chipaca> because `snappy info` tells me `ubuntu-core/rolling/edge`
<liuxg> Chipaca, just now, you said if you ran on 15.04, ....
<Chipaca> and `snappy list` tells me I'm on revision 259
<liuxg> Chipaca,  snappy config ubuntu-core | grep autoupdate does not return anything
<Chipaca> liuxg: what does `snappy list` output
<Chipaca> sorry
<Chipaca> liuxg: snappy info
<liuxg> Chipaca, http://paste.ubuntu.com/13501602/
<Chipaca> liuxg: and snappy info?
<liuxg> Chipaca, snappy info http://paste.ubuntu.com/13501606/
<Chipaca> liuxg: first line of that snappy info output
<Chipaca> liuxg: tells you you're on ubuntu-core/15.04/stable
<Chipaca> liuxg: and snappy list tells me you're on revision 2 of 15.04/stable
<liuxg> Chipaca, yes, I saw it. thanks. but snappy config ubuntu-core | grep autoupdate command does not tell me anything there.
<Chipaca> liuxg: which also tells me you're something like 8 releases behind current
<liuxg> Chipaca, so, I need to update my system?
<Chipaca> liuxg: as I said, if you're on 15.04, s/autoupdate/autopilot/
<Chipaca> liuxg: very yes
<Chipaca> liuxg: and it sounds like it's been trying to do so for a while
<Chipaca> liuxg: it's possible the update is failing and you're rolling back automatically, if so it'd be somewhat interesting to figure out why
<liuxg> Chipaca, do you mean "s/autoupdate/autopilot/" command?
<Chipaca> but only somehwat, because the raspberry pi was not officially supported on release 2
<Chipaca> version 2
<Chipaca> revision 2
<Chipaca> whatever we call it
 * Chipaca has a headache
<liuxg> Chipaca, yes, it keeps trying.  I need to manually upgrade it :)
<Chipaca> liuxg: so it's entirely possible you *can't* upgrade and need to reflash; ogra_ would know more
<liuxg> Chipaca, I can flash it myself. that is not a problem.
<Chipaca> liuxg: by s/autoupdate/autopilot/ i mean "replace autoupdate by autopilot in all the doc", because autoupdate is the new name; it used to be called autopilot
<Chipaca> I'm not sure if we changed it in the latest 15.04, but I think not
<liuxg> Chipaca, OK. I got it. thanks! I think it is good to update the doc.
<Chipaca> in any case, if ... config | grep autoupdate doesn't print anything, you need to say autopilot instead
<Chipaca> no, it's not good to update the doc
<Chipaca> that doc is correct for rolling
<Chipaca> it's also published for stable on the ubuntu website, which you can probably find easier than i
<Chipaca> i just have the github link closer to hand
<liuxg> Chipaca, in my place, both ways do not show anything there http://paste.ubuntu.com/13501627/
<Chipaca> liuxg: update first
<liuxg> Chipaca, OK
<liuxg> Chipaca, https://developer.ubuntu.com/en/snappy/guides/autopilot/
<Chipaca> yes, that's the *old* old doc
<Chipaca> update, and let's check
<liuxg> Chipaca, so, the doc needs to be updated, right?
<Chipaca> that's what i meant by âupdate, and let's checkâ
<Chipaca> i believe it does
<Chipaca> but i've lost track a little
<liuxg> Chipaca, my system refuses to update to the latest http://paste.ubuntu.com/13501646/
<liuxg> Chipaca, the new version is there. it happened to me before.
<liuxg> Chipaca, the latest version is there, but it does not use it.
<Chipaca> ogra_: ping
<ogra_> hey
<liuxg> Chipaca, I use to report a bug at https://bugs.launchpad.net/snappy/+bug/1508368
<ubottu> Launchpad bug 1508368 in Snappy "Ubuntu core does not boot into the right version" [Undecided,Incomplete]
<liuxg> Chipaca, it happened on the KVM long time ago.
<Chipaca> ogra_: when is 15.04/stable revision 2 on rpi2 from? and should update work?
<ogra_> Chipaca, only for subsequent images ...
<Chipaca> liuxg: ^. Just reflash the rpi2 to something newer.
<ogra_> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/stable/latest/ has the official images
<Guest552342> what is this?? https://uappexplorer.com/app/ubuntu-classic-armhf.mvo
<ogra_> Guest552342, it installs a classic "deb" mode
<ogra_> (in its very early stages still though, the implementation can still change)
<Guest552342> ogra_, AWESOME! :D
<Guest552342> oh it's only for armhf :\
<Guest552342> i haz none, only x86
<ogra_> (i.e. you will be able to install debs in a container that uses the snappy rootfs as base)
<Guest552342> super nice!
<Guest552342> can't wait to land on the phone :D
<ogra_> (to make running snapcraft to create snappy packages easy)
<ogra_> i'm not sure how much of snappy will actually land on the phone initially ...
<ogra_> i think the plan is to only support the package format for now ... not an actual snappy install yet
<Guest552342> i'll be happy with whatever it lands :D but when? :P
<ogra_> in time for 16.04
<Guest552342> soon then
<mvo> Guest552342: ubuntu-classic.mvo is the version for amd64
<mvo> Guest552342: but like ogra_ said, there will be some changes :)
<ogra_> mvo, interestingly uappexplorer doesnt fine the non armhf version
<ogra_> https://uappexplorer.com/apps?q=ubuntu-classic&sort=relevance&type=snappy
<SaMnCo-desktop> Hello!
<Guest552342> thanks mvo :D yep ogra_ i coudn't find the amd64 version in uappexplorer
<ogra_> snappy searhc should find it though
<SaMnCo-desktop> Not sure it's a snappy problem or a LXD problem, but I can't start a Trusty image on a rpi with Snappy
<ogra_> might be a bug in uappexplorer
<SaMnCo-desktop> log here : http://paste.ubuntu.com/13501779/
<SaMnCo-desktop> it used to work ok
<ogra_> SaMnCo-desktop, hmm, without sudo ?
<SaMnCo-desktop> (RaspberryPi2)ubuntu@samnco01:~$ sudo lxc start trusty
<SaMnCo-desktop> error: cannot read config file: open /home/ubuntu/apps/lxd/0.21-1/.config/lxc/config.yml: permission denied
<SaMnCo-desktop> ogra_-  ^
<ogra_> hmm
<ogra_> i fear you have to wait for stgraber
<SaMnCo-desktop> ogra_-   I have this line: No such file or directory - failed to access to '/var/lib/apps/lxd/current//lxc', check it is present
<SaMnCo-desktop> and ls /var/lib/apps/lxd/current doesn't exist
<SaMnCo-desktop> should I create the symlink myself?
<ogra_> hmm, it should, how old is your rpi image ?
<SaMnCo-desktop> pretty new, a couple of weeks maybe?
<ogra_> well, the link should be there with the last stable image and with rolling
<ogra_> iirc we set it everywhere now
<SaMnCo-desktop> ok forget about it, adding the link actually fixes the problem
<ogra_> Chipaca, is that right ?
<SaMnCo-desktop> ogra_-  so my problem is fixed, but if there is further investigation you want to make, I am happy to help
<ogra_> well, snappy should have created the link at package install time
<ogra_> at least on a recent image
<liuxg> Chipaca, ok.. thanks! I will do it
<Chipaca> ogra_: i'm not sure we have the link on stable, let me check
<Chipaca> ogra_: s/stable/15.04/
<ogra_> i thought it was a requirement for the last release
<ogra_> yeah, 15.04
<Guest552342> :| when i ssh -p 8022 ubuntu@localhost WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
<Guest552342> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
<Guest552342> It is also possible that a host key has just been changed.
<Guest552342> ogra :(  sudo snappy install curl.tetor
<Guest552342> Installing curl.tetor
<Guest552342> curl failed to install: Get https://public.apps.ubuntu.com/anon/download/tetor/curl.tetor/curl.tetor_0.1.10_amd64.snap: dial tcp: lookup public.apps.ubuntu.com: No address associated with hostname
<ogra_> are you online at all ?
<ogra_> doesnt look  like it
<Guest552342> hm.. right i'm offline but why
<Guest552342> or am i? snappy search returns searches
<Chipaca> Guest552342: wrt the 'remote host identification' warning, i have this in my ~/.ssh/config:
<Chipaca> Guest552342: http://pastebin.ubuntu.com/13501861/
<Chipaca> Guest552342: that avoids the warning, and makes âssh kvm.snappyâ work
<Guest552342> thanks Chipaca  :D i'll add that
<ogra_> Chipaca, hmm, does snappy confi havwe a concept of existing but disabled config options ... i.e. similar to commented out options in config files like "# myvar = 'change to your liking'"
<Guest552342> :'( so the search works but i can't install snaps. the search requires internet, right?
 * ogra_ isnt sure, it might for the first search but might cache subsequent ones
<liuxg> Chipaca, after I install the new software, I find that the "apps" directory in the home does not exist
<liuxg> Chipaca, where does the directory go?
<Chipaca> ogra_: not really, why?
<ogra_> Chipaca, well, i just notice that many config files have this so you save the admin from having to read through docs
<Chipaca> liuxg: it goes nowhere; apps create it as needed
<Guest552342> ogra_, out of the blue i managed to install hello-world o_O. do you know if webdm is preinstalled?
<ogra_> depends
<ogra_> it is in the official images
<Chipaca> Guest552342: what error do you get when you try to install?
<Guest552342> webdm failed to install: the given snap is already installed
<ogra_> it wont be preinstalled if you use ubuntu-device-flash without the --install option for a self built image
<ogra_> snappy list
<ogra_> ;)
<Guest552342> i am using  wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz and running the image in kvm
<Guest552342>  sudo snappy install curl.tetor
<Guest552342> Installing curl.tetor
<Guest552342> curl failed to install: snappy package not found
<ogra_> try without the suffix
<Guest552342> without tetor?
<ogra_> yep
<Guest552342> curl is the prefix right? :D
<Guest552342> ok :d
<Guest552342> same
<Guest552342> Installing system-status.victor - ok (worked)
<ogra_> hmm, weird
<liuxg> Chipaca, you are right. I have to run the app once to get the directory. for example, I want to install sth in the docker. I need to know its path.
<Guest552342> Installing snake.mectors - ok. so i do have internet connection :D and i can install stuff but not all the snaps work
<liuxg> Chipaca, by the way, last time, you said that you got a way to compile for armhf on device. do you have the detailed instruction for it?
<liuxg> Chipaca, if yes, I would like to blog it :)
<ogra_> Guest552342, do you see it in a "snappy search *" call ?
<Guest552342> curl.tetotr?
<ogra_> yes
<Guest552342> yep, http://pastebin.ubuntu.com/13501969/
<Guest552342> curl.tetor                    0.1.10             cURL
<ogra_> very weird, then it should definitely be installable ...
<ogra_> i wonder if there is an issue with the store
<ogra_> beuno, ^^^ ?
<Guest552342> mvo, sudo snappy install ubuntu-classic.mvo
<Guest552342> Installing ubuntu-classic.mvo
<Guest552342> ubuntu-classic failed to install: snappy package not found
<beuno> hi!
<ogra_> Guest552342, yeah, i get the same when trying on an amd64 stable image here
<Guest552342> so it's popey 's fault
<beuno> can you find it by searching?
<Guest552342> noh
<popey> obviously
<ogra_> though my snappy search also only returns one single package
<ogra_> (amd64)ogra@aleph2:~$ snappy search *
<ogra_> Name                 Version Summary
<ogra_> transmission.matiasb 2.84.2  Transmission
<ogra_> thats all i get here
<beuno> so that's why
<beuno> lets try and figure out what's getting filtered out
<ogra_> beuno, well, for me, but Guest552342 has a proper search output
<ogra_> see the pastebin above
<beuno> matiasb, hi!  would channels be doing this?  ^
<ogra_> ah, i'm on an "edge" 15.04 image here
<beuno> ah
<ogra_> which is identical with the release
<beuno> so the system is just looking at the edge channel by default
<ogra_> just not from the stable channeÃ¶l
<Guest552342> i'm on release
<beuno> this is new behavior ogra_
<matiasb> beuno, right, edge channel is empty atm
<ogra_> right, so that explains the difference
<beuno> yes
<matiasb> I published transmission after the rollout yesterday
<ogra_> but doesnt explain why Guest552342 cant install the packages
<beuno> so now back to Guest552342's problem
<beuno> we'd need a bit more debug information
 * matiasb reads backlog
<beuno> maybe mvo, sergiusens or Chipaca can help
<Guest552342> i can type stuff in that black window if you tell me what :d
<Chipaca> beuno: matiasb: a heads-up to the mailing list would've been nice
<ogra_> beuno, so is there a chance that we can make the stable snaps available to all edge channels if they dont have an "edge" equivalent ?
<ogra_> thats pretty limiting otherwise
<ogra_> (i tend to do development on an edge image, now i cant download any snaps )
<beuno> ogra_, yes, just need to ship the edge image that defaults to stable channel for everything except the things you want on edge
 * Guest552342 brb. smoke
<beuno> also, developers will be able to publish to edge soon
<ogra_> yeah, i saw the option in the web UI
<beuno> Chipaca, sorry about that, we've been coordinating with mvo instead
<ogra_> but it would make sense to have edge packages of stable packages where devs didnt explicitly pick to publish in edge
<beuno> that was the original proposal for channels
<beuno> maybe we'll circle back to that
<beuno> but the reality is I think the edge image should just pick the OS & Kernel from the edge channel
<beuno> and default to stable for everything else
<ogra_> i dont care abnout os and kernel
<ogra_> yeah :)
<beuno> right  :)
 * ogra_ sighs ... another 300 mails to read 
<ogra_> off for a week and i return to 1200 mails in my inbox :(
<Chipaca> liuxg: wrt the directory, i don't understand what you want/need/mean
<beuno> Chipaca, any idea why Guest552342 would get back a search result and then not be able to install?
<Chipaca> beuno: i don't know the error message he was getting
<Chipaca> ogra_: btw, install $pkg/stable works
<ogra_> (amd64)ogra@aleph2:~$ sudo snappy install ubuntu-classic.mvo/stable
<ogra_> Installing ubuntu-classic.mvo/stable
<ogra_> ubuntu-classic failed to install: snappy package not found
<ogra_> not even if i drop mvo
<Chipaca> i suspect that's been unpublished
<Chipaca> check with mvo
<davmor2> ogra_: You can have my inbox if you like I had 750 I only had one day off :)
<ogra_> davmor2, well, you dont want to knwo about the subfolders :P
<davmor2> ogra_: oh you mean in you inbox minus the subfolders
<ogra_> yep :)
<davmor2> ogra_: maybe you should break so much then people wouldn't have to blame you
<ogra_> (amd64)ogra@aleph2:~$ sudo snappy install curl.tetor/stable
<ogra_> Installing curl.tetor/stable
<ogra_> ...curl          2015-11-25 0.1.10       tetor
<ogra_> seems to work !
<ogra_> Guest552342, ^^^
<matiasb> Chipaca, ogra_, fwiw, checking in the store ubuntu-classic is still review pending, but ubuntu-classic-armhf is published
<liuxg> Chipaca, I need to install a container inside the docker. without knowing it first, I do not know where to install. Anyway, after I run "docker version" once, it creates the directory for me.
<ogra_> matiasb, yep ...
<Chipaca> liuxg: what do you mean "where to install"?
<ogra_> seesm to work with another package
<liuxg> Chipaca, I can only install container inside sth like apps/docker/1.6.2.004/
<Chipaca> liuxg: i don't understand
<liuxg> Chipaca, the path apps/docker/1.6.2.004/  belongs to docker, and we cannot install a container in any other places.
<beuno> Chipaca, if it were unpublished, it wouldnt show up in search results?
<Chipaca> liuxg: what you said is true. I still don't understand the problem you're having.
<ogra_> liuxg, install the owncloud snap and take a deep look at the start script it ships
<ogra_> that should show you how to properly use docker
<liuxg> Chipaca, if I do not run docker once, the path is not created, so should I create it manually?
<ogra_> (i dont think it should use anything out of /var/lib/apps/docker...../ )
<liuxg> ogra_, thanks! the app path is only created when it runs once.
<Chipaca> liuxg: why do _you_ need to know that path?
<amp_> Hi everyone. This is probably my first use of IRC, please excuse me if I've do something wrong here. I have a question...
<Guest552342> ogra_, yep  sudo snappy install curl.tetor/stable works :D
<Guest552342> i had no idea i have to add /stable
<ogra_> Guest552342, nobody had
<Guest552342> :))
 * ogra_ blames beuno 
<beuno> Guest552342, it's new  :)
<ogra_> :P
<beuno> channels go introduced yesterday
<Chipaca> Guest552342: you shouldn't; it's a bug
<Guest552342> oh :D
<ogra_> beuno, FAVO "introduced"
<ogra_> *FSVO
<beuno> Guest552342, are you using the edge image?
<ogra_> he uses stable
<beuno> ok
<amp_> I have flashed the new stable bbb image (15.04) to my BeagleBoneBlack using SD card. I can boot it, I can ssh into it from LAN, but the image cannot see the internet. 'snappy list -u' fails.
<ogra_> from releases.u.c
<Guest552342> yep stable
<beuno> so there's a bug indeed
<beuno> we'll figure out where
<beuno> matiasb, am I correct that if no channel is passed, you should get back stable?
<beuno> it seems true for search
<beuno> maybe not true for package API calls?
<ogra_> beuno, how do you figure out on which channel i am btw ? ...
<ogra_> system-image will be gone soon
<beuno> ogra_, not sure what the CLI exposes
<amp_> What can I do to debug this problem?
<matiasb> beuno, correct, CPI always assumes stable when no channel is specified
<beuno> matiasb, seems true for search, but doesn't seem true for installing a package
<ogra_> beuno, well, the only place i know is system-image-cli -i ... but that will be gone as soon as we swithc to all-snaps
<beuno> right
<beuno> ogra_, we'll have to find a place for it in the snappy CLI
<ogra_> right
<matiasb> beuno, hmm... installing a package shouldn't need a channel per-se, you get the package from a upload version URL; otoh, CPI package details, also assumes stable by default
<beuno> k
<beuno> we'll have to figure out what's going on then
<beuno> why search is fine but install isn't
<beuno> otp with the people who can find out
<Chipaca> Guest552342: can you check whether it now works *without* /stable?
<beuno> so will wait for that to be over  :)
<matiasb> ack, I can check if there is some code I can take a look at to review the involved API calls; in my head, nothing should have changed for stable installs
<nessita> beuno, matiasb sorry if this is noise, but isn't snappy 16.04 using edge as default channel?
<Guest552342> Chipaca, yep :d works now whothout /stable
<Guest552342> yay
<matiasb> nice
<beuno> nessita, it depends what image you download
<beuno> Chipaca, why would it have worked the second time?
<Chipaca> Guest552342: so either you're having intermittent network issues, or we're having intermittent server issues
<Chipaca> i hope beuno would know if the latter were the case ;-)
<beuno> Chipaca, we should try and have the client expose that a bit better
<Guest552342> i have strong and fast internet! :D
<beuno> it seemed like a 404 vs network
<Chipaca> beuno: expose what exactly?
<Guest552342> Installing mir
<Guest552342> mir failed to install: snappy package not found
<Guest552342> but i can see mir when i search
<Chipaca> Guest552342: the mir package is buggy, and i'm not sure it works at all, but try âmir.mvp-demoâ
<Guest552342> Chipaca, uuu 76Mb :D yep this one works
<Chipaca> beuno: ah, snappy install just responds 'not found' on network error, yes, that needs updating
<beuno> yes, that
<Chipaca> beuno: snappy search is more boisterous
<ogra_> Chipaca, mvo, who broke ubuntu-snappy-cli on the weekend ?
<Chipaca> ogra_: how's it broken?
<ogra_> (images dont build since sat.)
<ogra_> The following packages have unmet dependencies:
<ogra_>  ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.7ubuntu1-1+906~ubuntu16.04.1) but it is not going to be installed
<ogra_> E: Unable to correct problems, you have held broken packages.
<mvo> ogra_: the build failure?
<ogra_> ah, did it ftbfs ?
<dholbach> sergiusens: when do you think we should do the next clinic about snapcraft 0.5? :)
<ogra_> is 0.4 out yet ?
 * ogra_ didnt get an update
<liuxg> Chipaca, I have upgraded my software, however, when i run "snappy config ubuntu-core | grep autoupdate", I still get nothing. see http://paste.ubuntu.com/13502677/
<Chipaca> liuxg: snappy info, snappy list, please
<beuno> Chipaca, mvo, we need to figure out what to do with the new channels behaviour for the edge image. Any suggestions?
<beuno> do we update the edge image?  set all current snaps to the edge channel as well?
<dholbach> ogra_, xenial has 0.5 and the PPAs should be updated too
<liuxg> Chipaca, http://paste.ubuntu.com/13502700/
<ogra_> dholbach, well, my wily install doesnt have it ... i only have 0.3
 * ogra_ checks if the PPA got disabled or something
<Chipaca> liuxg: "snappy config" output?
<Chipaca> liuxg: erm
<Chipaca> liuxg: sudo snappy config ubuntu-core
<ogra_> bah, indeed it did
 * ogra_ curses ... so my snaps are all outdated :/
<Chipaca> ahhh
<Chipaca> liuxg: AUTOPILOT
<sergiusens> dholbach, Monday or Wednesday?
<liuxg> Chipaca, http://paste.ubuntu.com/13502726/
<Chipaca> liuxg: not autouplitottogiqwerwhateveryoutyped
<dholbach> sergiusens, which to do you prefer?
<liuxg> Chipaca, yeah, you are right. sorry.
<sergiusens> dholbach, Wednesday so I can speak to kyrofa in case he wants to join
<dholbach> sergiusens, ok, which time?
<sergiusens> dholbach, 5pm your time maybe? (I am lost with tz diffs, sorry)
<dholbach> that'd clash with our community team meeting, but maybe I can miss it just this once :)
<dholbach> so that'd be 2nd Dec 16:00 UTC
<sergiusens> dholbach, is that good for you? tuesday is fine as well
<sergiusens> so you don't miss the meeting
<dholbach> tuesday that timeslot is the community Q&A :)
<stgraber> SaMnCo-desktop: don't use sudo
<SaMnCo-desktop> stgraber-  Yeah, it works now. The problem was that the system did not create the symlink for the latest lxd version
<SaMnCo-desktop> therefore if you look at the log, it didn't know where to find the lxc binary
<stgraber> ah yeah, I think we have a note for that in our getting-started instructions
<stgraber> x86 and bbb images have it but not rpi2
<SaMnCo-desktop> stgraber-  Ah, I didn't see that, RTFM to me then :D
<stgraber> SaMnCo-desktop: https://linuxcontainers.org/lxd/getting-started-cli/#ubuntu-core-snappy
<ogra_> stgraber, rpi has it too
<ogra_> the bbb and rpi images are 100% identical since last stable
<ogra_> (module the hardware setup indeeD)
<ogra_> *modulo
<ogra_> (this is ubuntu-core v3 in "snappy list")
<SaMnCo-desktop> side question, does anyone know when Docker will be updated to a more recent version than 1.6.2?
<SaMnCo-desktop> like... 1.9?
<asac> i have troubles figuring how to conveniently setup my lxc so i have my home mounted and i auto login with the right user etc. ... anyone has done this and has pointers/tricks?
<asac> kickinz1: see docker questiona bove
<asac> (if it matters, i am using lxd from daily ppa
<kickinz1> SaMnCo-desktop, there has been some work, and there is an 1.8.3 amd64 snappy build already, but the armhf need some bug fixes, and I don't have time for that right now.
<kickinz1> asac ^
<asac> kickinz1: is armhf support not upstream yet?
<dholbach> sergiusens, not sure if you saw the message earlier: tuesday that timeslot is the community Q&A :)
<sergiusens> dholbach, oh, yeah, then wednesday is fine
<dholbach> ok cool
<SaMnCo-desktop> kickinz1-  ok thanks
<Guest55Aw> ogra_, welp :( i can't install https://uappexplorer.com/app/classic.mvo [Architecture: all]
<Guest55Aw> classic failed to install: snappy package not found
<Guest55Aw> but it's in the store
<ogra_> Guest55Aw, hmm, i cant either ... perhaps another store issue
<Guest55Aw> ogra_, ok thanks :'(
<elopio> fgimenez: the $1 and $2 are alright http://paste.ubuntu.com/13503344/
<mvo> Guest55Aw: you will need a "rolling" (16.04) image for now its only availalbe there. I expect it wil come to 15.04 too (soonish) but it is still in development
<elopio> ogra_: hey, welcome back!
<ogra_> elopio, hey ho !
<mvo> ogra_: oh, you have this issue too, me
<ogra_> mvo, i'm on 15.04 edge
<elopio> I missed you. Don't leave us again :')
<Guest55Aw> mvo, oooo nice :D let's roll then
<ogra_> so i'm fine
<mvo> ogra_: its only rolling for now
<ogra_> yeah
<Guest55Aw> mvo, silly question but from where do i wget the rolling image
<ogra_> Guest55Aw, you have to create it yourself using ubuntu-device-flash
<Guest55Aw> ogra_, oh, i see :D
<fgimenez> elopio, no idea then... the script works fine locally
<Guest55Aw> ogr, so.. ubuntu-device-flash core 16.04 -o snappy_rolling.img --size 4 --enable-ssh ?
<Guest55Aw> ogra_,  so.. ubuntu-device-flash core 16.04 -o snappy_rolling.img --size 4 --enable-ssh ?
<fgimenez> elopio, i would ask more about the environment, env and go version, not sure if they could affect the suite execution though
<ogra_> Guest55Aw, i think:  ubuntu-device-flash core rolling --channel=edge  -o snappy_rolling.img  --enable-ssh
<Guest55Aw> ogra_, thanks
<Guest55Aw> ogra_, Determining oem configuration
<Guest55Aw> generic-amd64 failed to install: snappy package not found
<Guest55Aw> nope
<ogra_> oh, then you need --oem=genercic-amd64
<Guest55Aw> ogra_, same error
<ogra_> sudo ubuntu-device-flash core --oem=generic-amd64 --channel=edge  -o snappy_rolling.img  --enable-ssh rolling
<ogra_> works here
<Guest55Aw> ogra_, strange i get Determining oem configuration generic-amd64 failed to install: snappy package not found :|
<Guest55Aw> weird
<ogra_> when you copy/paste my line above ?
<Guest55Aw> i'm on 16.04
<Guest55Aw> yes
<Guest55Aw> :~$ sudo ubuntu-device-flash core --oem=generic-amd64 --channel=edge  -o snappy_rolling.img  --enable-ssh rolling
<Guest55Aw> Determining oem configuration
<Guest55Aw> generic-amd64 failed to install: snappy package not found
 * ogra_ is on 14.04 but that shouldnt matter, my ubuntu-device-flash should be the same version as yours
<Guest55Aw> ogra_,  ubuntu-device-flash 0.33-0ubuntu2
<ogra_> oh,. i'm on 0.31 still
<Guest55Aw> oh :D i wander what changed
<ogra_> the changelog doesnt look like it would have any relation to your error
<Guest55Aw> should i open a bug report?
 * Guest55Aw brb -pizza-
<ogra_> Guest55Aw, yeah ... i dont use 16.04 anywhere, probably it is expected breakage
<elopio> ogra_: I need your help. If I put this in a bash script: http://paste.ubuntu.com/13504401/
<elopio> no matter how badly the command fails, the error will be left in output.txt ?
<jerryG> getting a "has non-unique elements" error when trying to execute snapcraft.  any suggestions?
<sergiusens> jerryG, can I see your snapcraft.yaml?
<ogra_> elopio, yes
#snappy 2015-11-26
<liuxg> has anyone successfully turned off autopilot for a snappy device? I did exactly the same at the instructions at https://github.com/ubuntu-core/snappy/blob/master/docs/autoupdate.md, but no success. I have replaced the "autoupdate" to autopilot.
<dholbach> good morning
<fgimenez> good morning
<SaMnCo-desktop> Hello! If I would like to run a set of Docker Containers and give them access to a BLE USB stick, what would be the recommended method?
<Chipaca> liuxg: echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core -
<Chipaca> liuxg: it seems autoupdate.md is missing the -
<liuxg> Chipaca, is it "off", or "false"?
<liuxg> Chipaca, it should be "true" or "false". it should not be "on" or "off"
<Chipaca> liuxg: why should it not be on/off?
<Chipaca> liuxg: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF
<Chipaca> liuxg: all of those are valid boolean values in yaml
<liuxg> Chipaca, ok.ãlet me try it.
<liuxg> Chipaca, sorry, I am wrong. it works. also true/false work as well. :)
<liuxg> Chipaca, by the way, what is the use of "-" in the command?
<Chipaca> liuxg: conventionally, specifying - for an argument that expects a file uses stdin as the file
<liuxg> Chipaca, I got it. thanks
<liuxg> Chipaca, I just found that the method at https://developer.ubuntu.com/en/snappy/guides/autopilot/ also worked
<mattyw> hey folks, this new snap format, that's not landed in the repository yet has it (I just built a snap and got this when I tried to upload (failed to install: Signature verification failed: Internal error. E.g. Package corrupt, gpg failed, etc.)
<JamesTait> Good morning all; happy Thursday and happy Cake Day! ð  http://goo.gl/oKyw2t
<ogra_`> mattyw, did you use the --allow-unauthenticated option to snappy install ?
<mattyw> ogra_`, I didn't that must be a new thing?
<ogra_`> oh, ignore me
<ogra_`> i thought you meant you sideload a snap ... but you see that on upload
<JamesTait> Error "failed to install" when uploading? o_O
<ogra_`> oh, right
<mattyw> JamesTait, ogasawara well, snappy-remote install
<ogra_`> ah !
<mattyw> yeah I'm sideloading
<JamesTait> Ah!
 * JamesTait stands down
<ogra_`> then you want the --allow-unauthenticated option indeed
<ogra_`> (and no, thats not new at all)
<mattyw> ogra_`, I'll give it a go, thanks very much, sure I didn't need it a few months ago but no biggy
<ogra_`> i'm sure you always needed it ... might be that snappy-remote did set it automatically or some such though
 * ogra_` never uses it
<ogra_`> (snappy-remote that is)
<Chipaca> mattyw: a few months ago you might have been using an image in developer mode
<Chipaca> mattyw: which imples --alllow-unauthenticated-potatos
<mattyw> unknown flag `allow-unauthenticated'
<mattyw> hmmm
<mattyw> ogra_`, unknown flag, what do you use if not snappy-remote?
<mattyw> ogra_`, just works now, maybe I did have a bad snap - all working now, sorry to trouble you
<SaMnCo-desktop> is there a list of all caps available for users somewhere?
<SaMnCo-desktop> eg. in https://insights.ubuntu.com/2015/07/20/prime-time-docker-juju-and-snappy-ubuntu-core/ Dustin uses "docker_client"
<SaMnCo-desktop> where does that come from?
<Chipaca> SaMnCo-desktop: docker itself
<Chipaca> SaMnCo-desktop: frameworks can extend caps
<SaMnCo-desktop> Chipaca-  ok so if I want a Docker container to have access to Bluetooth, I should have it use the framework "docker" so it can run
<asac> so the kernel-snap thingy annouced by rtg the other day is not abouut a snapcraft plugin, but rather hard coded build logic in the kernel source tree? or did i miss something?
<SaMnCo-desktop> and then, what cap / framework should I use to add the BLE stack?
<Chipaca> SaMnCo-desktop: i'm not sure there's a bluez framework yet, but there might be
<SaMnCo-desktop> Chipaca-  Is there a list of public frameworks available somewhere?
<Chipaca> SaMnCo-desktop: i don't think so, but i'm not sure
<Chipaca> dholbach: so, two issues with snappy docs in d.u.c
<Chipaca> dholbach: one is the autopilot doc, which is stale
<Chipaca> dholbach: in fact i don't think it's ever been true for a released snappy
<SaMnCo-desktop> Chipaca-  so, is there a list of the caps available somewhere?
<dholbach> yes, I know some are stale :-/
<Chipaca> dholbach: the other is that I think most of those should have some kind of text that said "these are for 15.04; for rolling, go to <github/yaddayadda/docs/blah.md>
<dholbach> yes, that's the plan
<dholbach> the automatic importer does all of this, but it's broken and we're working with django cms upstream to get it fixed
<Chipaca> ah
<dholbach> what can I do for the short term? update the autopilot doc?
<Chipaca> that'd help
<dholbach> from the 15.04 branch?
<Chipaca> oh, good point
<Chipaca> let me check that :)
<Chipaca> dholbach: is this manual or automatic?
<dholbach> it's manual now
<dholbach> I hope it's automatic very soon
<Chipaca> dholbach: in any case, i think i should first fix them on the 15.04 branch and then point you at it there
<dholbach> but I guess it'll take at least 1-2 more weeks
<Chipaca> dholbach: i'll poke you later today when the 15.04 branch has the right autopilot docs
<Chipaca> dholbach: thanks
<dholbach> thanks Chipaca
<ogra_`> asac, the kernel snap only uses binary debs
<ogra_`> asac, it is actually rootstock hacked up :P
<asac> ogra_`: why didnt we do the snapcraft plugin?
<asac> was there a need to do the shortcut?
<ogra_`> asac, it is a snapcraft plugin but using rootstock as backend
<asac> it is?
<asac> the git branch rt announced isnt
<ogra_`> asac, http://kernel.ubuntu.com/git/rtg/kernel-snap.git/tree/
<asac> its just a makefile in a source tree that does everything
<asac> http://kernel.ubuntu.com/git/rtg/kernel-snap.git/tree/Makefile?h=amd64-from-deb-16.04
<asac> how is that a plugin?
<ogra_`> build_chroot: rootstock
<ogra_`> 	sudo sh ./rootstock -a $(ARCH) -f $(LINUX_FLAVOUR) -m $(MIRROR) -s $(SUITE) -b $(BOOTLOADER) $(PPAS) -k
<ogra_`> 	sudo chmod +r $(CHROOT)/boot/*
<ogra_`> the only git i see in that file is to pull the most recent rootstock script
<ogra_`> asac, and there is no other way to do it ... you need a proper initrd which you can only get from packages
<ogra_`> http://kernel.ubuntu.com/git/rtg/kernel-snap.git/log/?h=raspi2-from-git
<ogra_`> this seems to first build a deb from a kernel tree and then pipes it into rootstock
<ogra_`> but effectively it is all deb based
<ogra_`> (in the backend processing)
<asac> ogra_`: ok, but this is not using snapcraft... guess will have to happen still then. thanks
<ogra_`> asac, it is a snapcraft plugin and i plan to use it in the official builds later
<sergiusens> ppisati, hey, are you going to be able to make it to the dtb meeting I set?
<ogra_`> (or it will become one in the end at least as i understand)
<sergiusens> ogra_`, asac what plugin?
<ogra_`> sergiusens, tims kernel thin
<ogra_`> *thing
<ogra_`> sergiusens, http://kernel.ubuntu.com/git/rtg/kernel-snap.git/refs/
<ogra_`> asac, as i understood tim plans to just hook it into the make plugin in the end
<sergiusens> ogra_`, so it would be a part, not a plugin
<ogra_`> might be ... better ask tim how he planned to integrate it
<sergiusens> the only thing that worries me are the sudo calls
<ogra_`> but as i understood the reason for the toplevel Makefile is to make use of the make plugin
<ogra_`> yeah, he probably should use fakechroot
<ogra_`> (and fakeroot)
<asac> hmm. sounds not as cool as it could/should be, in this case snapcraft doesnt make life easier
<sergiusens> ogra_`, can you do everything there with sudo?
<ogra_> sergiusens, thats what i do in the touch initrd build scripts
<ogra_> you dont need sudo at all then ... it fakes a root env
<ogra_> asac, well ... you need the chroot bit to generate an initrd until we have any other solution ... you will always end up with scripts there ...
<ogra_> the build wouldnt need to use a deb for the kernel itself though ... but i guess thats also more maintenance in the end
<sergiusens> ogra_, so what's up the the talks about making initrd generic?
<ogra_> sergiusens, i wish we could ... but that would mean a bunch of kernel changes
<ppisati> sergiusens: yep
<asac> ogra_: what is the other solution? who is working on it and if noone what needs doing e.g. the plan?
<sergiusens> ppisati, great
<ogra_> not sure we actually want squashfs and all of vfat built into every generic kernel
<asac> if noone comes up with a better solution we have to go generic
<asac> not sure if anyone is thinking about better solution though; hence asking
<ogra_> asac, the only other solution would be a module-less initrtd that you can just pull from somewhere
<ogra_> asac, but as i said above, that needs all bits we need to boot snappy built into the kernel
<asac> sure
<ogra_> ad as ling as we use the generic kernel thats tricky
<asac> doesnt feel wrong to do that; who is pushing back?
<ogra_> *long
<ogra_> nobody is pushing back
<asac> so vfat is surely in the kernel right now, no?
<ogra_> not all of it
<ogra_> codepages are mnodules
<asac> whats that?
<ogra_> we need all of vfat, ext4 and squashfs builtin
<ogra_> nls codepages
<ogra_> for being able to handle filenames
<ogra_> vfat needs that
<ogra_> and there are multiple (i never saw any other than iso-8859-1 used though, but there are like 30-50 of them)
<asac> so we support some format of filenames?
<asac> why cant we restrict us to those?
<ogra_> vfat does
<ogra_> its not us
<ogra_> i dont think there is a utf-8 codepage that could cover everything
<ogra_> asac, the prob is ... if you get a usb stick from a chinese friend it might need a different codepage ... vfat wouldnt mount it if that isnt available ... while we could build all codepages into the kernel technically that adds a huge amount of bloat
<ogra_> OTOH i'm not sure if we could build only the codepage we use into the kernel and leave the rest as modules
<ogra_> probably ppisati knows :)
<sergiusens> Chipaca or mvo_ , is      security-template: network-status    a 16.04 only thing?
<Chipaca> sergiusens: no
<Chipaca> sergiusens: bah. it's under 15.04. let me check on actual 15.04
<Chipaca> sergiusens: it's there in 15.04
<Chipaca> sergiusens: /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/network-status
<sergiusens> Chipaca, meh, then boo :-)
<sergiusens> Chipaca, 2015/11/24 08:43:59.067839 security.go:205: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=network-status --policy-groups=networking] failed
<sergiusens> bwm-ng_0.6-3.2_amd64.snap failed to install: exit status 1
<sergiusens> Chipaca, is it on sstable or only edge?
 * sergiusens starts the day and checks
<Chipaca> sergiusens: stable r10
<sergiusens> Chipaca, hah, review tools fail for this as well with 'unsupported template'
<sergiusens> Chipaca, this is what I'm looking at btw https://bugs.launchpad.net/snapcraft/+bug/1519251
<ubottu> Launchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete]
<ogra_> beuno, i still cant install any snaps on either of my edge installs, how long do you plan to keep it that way ?
<ogra_> (shouldnt that be rolled back until we have a proper solution ?)
<Chipaca> sergiusens: you should probably have a word with the jamie
<ogra_> mvo_, what do you think about forcing LC_ALL=C in an /etc/profile.d snippet that we ship in ubuntu-core-config ?
 * ogra_ is annoyed having to set LC_ALL=C all the time
<beuno> ogra_, hi. We just need to make a decision on how to fix it. I'll get that decision in ~30 minutes
<ogra_> ok
<dholbach> hey sergiusens
<mvo_> ogra_: +1 from me until have  a image that supports locales
<dholbach> sergiusens, if I list a file under binaries which is a shell script, should that work and provide a valid snap?
<ogra_> mvo_, eek ... you really want to go down that rabbit hole ?
<dholbach> sergiusens, or do we only want to list binaries there?
<mvo_> ogra_: I think eventually we have no choice, for now I think forcing C or C.UTF-8 is fine
<ogra_> mvo_, we always have choice :)
<ogra_> but yeah. i'll add that snippet
<sergiusens> dholbach, interpreted languages are binaries(!)
<sergiusens> dholbach, well, to the purpose of snapcraft ;-)
<sergiusens> dholbach, the examples are full of them
<dholbach> sergiusens, I get this:
<dholbach> - lint:control_architecture_specified_needed
<dholbach> 	Could not find compiled binaries for architecture 'amd64'
<dholbach> I guess that's a bug for click-reviewers-tools
<sergiusens> dholbach, define architetures: [all]
<dholbach> maybe somebody could help Jamie with a review of this one too: https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218
<sergiusens> dholbach, your snap is just one one one script?
<dholbach> yes
<dholbach> sergiusens, "architetures: [all]" doesn't fix it
<sergiusens> dholbach, is there a typo there?
<sergiusens> missing a c :-)
<dholbach> sorry, "architectures: [all]"
<dholbach> https://bazaar.launchpad.net/~dholbach/+junk/hello-world.snap/view/head:/snapcraft.yaml
<dholbach> sergiusens, ^
<sergiusens> dholbach, yeah yeah, one sec ;-)
<dholbach> ok, no worries :)
<beuno> ogra_, conclusion is that we'll update the edge image to point at the stable channel
<beuno> and other things, that i'll send to the list in a little bit
<ogra_> beuno, dont forget about stable then :)
<ogra_> (i mean 15.04/edge, sorry )
<beuno> yes, for 15.04 as well
<beuno> mvo will solve all the problems, as usual
<ogra_> ah, k, then it is in good hands
<sergiusens> dholbach, so I guess we don't support your use case anymore
<dholbach> ok...
<sergiusens> dholbach, we could, we just don't
<dholbach> I guess this might be a common one?
<dholbach> is there another way to at least create a wrapper for scripts?
<ogra_> sergiusens, well, as long as "snappy build" works, once can at least still build multi snaps manually :P
<sergiusens> ogra_, snappy build will not work in 16.04
<ogra_> sergiusens, yeah, and with that snappy loses a lot of excitement for me as maintainer ... unless you start supporting multi snaps in snapcraft
<sergiusens> dholbach, I really doubt there will be a lot of snaps that are just scripts, but just create a bug ;-)
<ogra_> since i have to maintain a single snap for each arch ... with a single page in the store etc etc ...
 * ogra_ guesses that wont win us more maintainers 
<dholbach> sergiusens, is that a snapcraft or click-reviewers-tools issue?
<sergiusens> dholbach, snapcraft, we mark the arch as where you build it
<dholbach> ok
<ogra_> sergiusens, maintaining debs is easier then
<ogra_> (which is very sad)
<sergiusens> dholbach, if I find something to parse the tree and check if it is an actual binary we can do this automatically
<sergiusens> ogra_, I have no idea what you are talking about ;-)
<dholbach> sergiusens, you can probably borrow the checks from the reviewers tools
<ogra_> sergiusens, that maintaining my stuff in a deb is abouot 10% the work it takes me to maintain 4 snaps
<ogra_> with that new model
<ogra_> we are making maintainer life really hard with that
<ogra_> i.e. it wouldnt encourage me to turn my stuff into a snap as an upstream ... even thouh it is easier to set up a snapcraft.yaml vs a debian dir, the followup work is horrid
<sergiusens> ogra_, you can take the store issues to beuno and for snapcraft, better bring in concrete problems (in the form of bugs would be nice so it's not fire and forget)
<ogra_> sergiusens, well, thats not a store issue ... i have a few multi arch snaps
<ogra_> (in fact node-snapper defaults to build multi)
<ogra_> with dropping the ability to do that you make maintainer life really hard if i as maintainer want to support all arches
<sergiusens> ogra_, as a debian package maintainer you need to create N builds for N arches; I don't understand how it is harder
<ogra_> and i dont think a bug is the right thing for somethin "planned"
<ogra_> sergiusens, i dont ... i upload one source package
<sergiusens> ogra_, you should be able to build for N arches on launchpad
 * sergiusens goes back to work
<ogra_> sergiusens, right, but then i still need to maintin N store pages because i have not a single multi snap but N arches i need to support now
<ogra_> i simply think it is very discouraging to drop that feature
<sergiusens> dholbach, ping me once you have the bug
<dholbach> sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1520248
<ubottu> Launchpad bug 1520248 in Snapcraft "snap with only scripts gets wrongs architecture set" [Undecided,New]
<Chipaca> dholbach: https://github.com/ubuntu-core/snappy/blob/15.04/docs/autopilot.md is ready for you
<dholbach> thanks Chipaca
<dholbach> Chipaca, updated
<Chipaca> huzzah
<sergiusens> dholbach, this is also ready for you https://github.com/ubuntu-core/snapcraft/pull/121
<dholbach> sergiusens, checking in a sec
<dholbach> sergiusens, so with this branch I'm required to specify architectures, right?
<sergiusens> dholbach, yes
<dholbach> it'd be nice if that wasn't necessary O:-)
<sergiusens> dholbach, oh; but then ogra_ will complain that multi is not working either
<sergiusens> dholbach, I will add auto detect into a future branch
<ogra_> :P
<dholbach> I don't understand
<dholbach> couldn't this be completely autodetected at some stage in the future?
<sergiusens> mvo_, Chipaca mind confirming my comment? https://bugs.launchpad.net/snappy/+bug/1520253
<ubottu> Launchpad bug 1520253 in Snappy "Only one of apparmor.override / seccomp.override is required" [Undecided,New]
<ogra_> hmm ... snappy list on my rpi shows me "classic.mvo" .... i thought thats amd64 only
<davmor2> I think mvo only called it classic so he could get people to say classic.mvo more often
<ogra_> well, i should see ubuntu-classic-armhf.mvo i think
<davmor2> ogra_: spoilsport
<sergiusens> dholbach, the arch stuff in click-review only checks for binaries, I'd need to walk the full tree, might be doable
<sergiusens> err, hmm, all_files, nevermind :-)
<beuno> ogra_, ubuntu-classic-armhf.mvo
<beuno> hasn't been published
<ogra_> oh
<beuno> not sure if by accident or not
<ogra_> https://uappexplorer.com/app/ubuntu-classic-armhf.mvo
<ogra_> your API thinks differently :)
<beuno> ogra_, classic.mvo
<beuno> is marked as architecture independant
<beuno> which I'm sure is a lie
<ogra_> you'd guess :)
<beuno> that's why you get it as a result
<beuno> ogra_, it was published and then unpublished
<beuno> seems uappexplorer doesn't keep up with removals
<ogra_> ah !
<beuno> Wed 25 Nov. 2015
<beuno> Ready to publish.
<beuno> Tue 24 Nov. 2015
<beuno> Published.
<beuno> mvo is such a tease
<ogra_> haha
<ogra_> yeah
 * ogra_ installs his debootstrap snap then ... who needs classic :P
<dholbach> install the moon-buggy snap :-P
<ogra_> hah !
<sergiusens> dholbach, what does that do?
<ogra_> cool
<ogra_> someone needs to do a nethack snap too !
<dholbach> sergiusens, it's a silly ascii art game
<dholbach> sergiusens, I was just looking for something hello-world-esque to snap :)
<tsimonq2> an irssi snap would be pretty badass
<tsimonq2> or an ssh one
<tsimonq2> (if it isn't already integrated)
<ogra_> an ssh one ??
<ogra_> ssh is
<tsimonq2> ogra_: oh, ok
<ogra_> i'm about to upload a bip snap
<ogra_> and an approx one too
<tsimonq2> ogra_: but an irssi one would be pretty badass, no?
<ogra_> sure, go ahead !
<tsimonq2> :D
<tsimonq2> ogra_: would you happen to know how I can make myself a debootstrap Sannpy environment, instead of using a VM?
<tsimonq2> *Snappy
<ogra_> you mean on your PC ?
<tsimonq2> ogra_: yep, I am using an i386 Lubuntu machine, which is old, so no Hardware Virtualization support
<tsimonq2> ogra_: so that would probably be a way around that, right?
<ogra_> no, it wont ... to run a snappy install you need a certain partitioning
<tsimonq2> oh ok
<dholbach> sergiusens, we'll go with next Wed 16 UTC, right? if you're fine with that, I'll send the announce and get it added to the calendars
<ogra_> so some kind of vm is needed ...
<tsimonq2> ogra_: I have a nicer machine, so when I get access to it, I will use that with a VM
<tsimonq2> because an irssi snap would be awesome :D
<ogra_> (unless you have actual hardware like an Rpi2)
<tsimonq2> nope
<ogra_> to actually build a snap you only need snapcraft installed
<tsimonq2> oh, is that as simple as sudo apt install snapcraft?
<ogra_> (thouh indeed, to test it you will need a VM to instal it in)
<ogra_> yeah
<sergiusens> dholbach, yeah, by then 0.6 might be out :-P
<tsimonq2> ok, might as well play with it a bit, this could be awesome :D
<dholbach> sergiusens, ok.. I'll just call it "what's new in snapcraft" :)
<ogra_> if you have questions, just ask here
<tsimonq2> ok, thanks ogra_
<tsimonq2> ogra_: do you guys have support for the Raspberry Pi Zero yet?
<ogra_> we cant
<ogra_> it uses the same CPU arch as the RPi1
<tsimonq2> ogra_: so NO Ubuntu on that AT ALL?
<tsimonq2> sad :(
<ogra_> yep
<ogra_> sergiusens, is there any way to use a package proxy for snapcraft ?
<ogra_> or make it use the sources.list entry from my build chroot
<sergiusens> ogra_, USE_LOCAL_SOURCES=1
<sergiusens> ogra_, the xenial snapcraft will always do that btw
<sergiusens> oh, but the cache, the cache is different
<sergiusens> the way python apt is done, it is not straightforward and haven't found time
#snappy 2015-11-27
<fgimenez> good morning
<dholbach> good morning
<JamesTait> Good morning all; happy Friday, and happy Systems Engineer Day! ð
<ogra_> 402614
<tbr> 42!
<ogra_> yay, yubikey !
<ogra_> hmm, do we have a way to define a mode for the target file in the snapcraft copy plugin ?
<longsleep> ogra_: not that i am aware of, would be nice to have though
<ogra_> yeah
<longsleep> especially for binary and service files some consistency check would be good as well, makes no sense for them to be non executable
<elopio_> fgimenez: what would be a good name for the reboot flag?
<elopio_> !cannotrebot ?
<ubottu> elopio_: I am only a bot, please don't think I'm intelligent :)
<elopio_> we have the double negative again.
<elopio> fgimenez: maybe, !withoutreboots
<fgimenez> elopio, AFAIUI if we want them to be executed by default they have to be defined with the double negative, yes
<fgimenez> elopio, sounds good, or continue with exclude...
<elopio> fgimenez: yes, that's the problem with tags. But using "low" was a nice trick.
<elopio> !excludereboot, that's not so bad.
<ubottu> elopio: I am only a bot, please don't think I'm intelligent :)
<fgimenez> elopio, at least the command line reads fine: -test-build-tags=[without|exclude]reboots
<mterry_> ogra_, hah, love the nethack snap, haven't tried it yet, but saw it go by  :)
<ogra_> :D
#snappy 2015-11-29
<tsimonq2> ogra_: is there a more up-to-date release of Snappy that I can download? Maybe 15.10 or Xenial? The tutorial just says 15.04
<ogra_> you can use rolling (xenial based)  when you build your own image with ubuntu-device-flash
<tsimonq2> ogra_: how?
<tsimonq2> ogra_: and isn't there just an equivelent to do-release-upgrade in snappy?
<ogra_> updates are installed automatically when new images are released by default
<ogra_> (you can turn that off with "snappy config ubuntu-core" if you do not want that)
<tsimonq2> oh, so could I just do snappy update and it will automatically be rolling then?
<ogra_> but they will only remain within the channel you originally instaleld
<ogra_> no
<ogra_> if you use a 15.04 image it will auto-update if there i a new 15..04
<ogra_> you wont be able to switch over to the rolling channel
<ogra_> (thins might change once we dropped all of system-image)
<tsimonq2> ogra_: so there is NO way whatsoever to switch the channel? No sources.list change?
<ogra_> not currently, no
<tsimonq2> oh, ok
<ogra_> as i said, that will likely change once we dropped system-image
<tsimonq2> ogra_: is there a download link for a rolling amd64 image?
<ogra_> no, there is no such thing, you have to create one yourself
<ogra_>  sudo ubuntu-device-flash core --channel=edge --oem=generic-amd64 -o test.img rolling
<ogra_> that should get you one
<ogra_> (probably add --install=webdm)
<ogra_> (and --enable-ssh)
<Guest74213> tsimonq2, tsimonq2 it doesn't work on xenial, try on 14.04 Determining oem configuration
<Guest74213> generic-amd64 failed to install: snappy package not found
<tsimonq2> Guest74213: I just did sudo apt -y install snappy
<tsimonq2> oh...but one removes the other
<Guest74213> :>]
<tsimonq2> ogra_! what packages do I need installed for this? I am running xenial
<ogra_> just ubuntu-device-flash should be enough ... it should pull the needed dependencies
<Guest74213> ogra_, it doesn't work on xenial
<tsimonq2> ogra_: this is what I am getting: generic-amd64 failed to install: snappy package not found
<Guest74213> yes, me 2
<ogra_> try adding https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<tsimonq2> ok, trying now
<ogra_> seems the last snappy upload FTBFS
<ogra_> so it might be uninstallable atm
<ogra_> (xenial is a devel release after all :P )
<tsimonq2> ogra_: what do I have to do after the ppa? the package is already installed
<Guest74213> The following packages will be upgraded:
<Guest74213>   golang-snappy-dev ubuntu-snappy-cli
<Guest74213> Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory
<Guest74213> The system user `snappypkg' already exists.  Exiting.
<Guest74213> and the same error
<tsimonq2> it went fine for me...
<Guest74213> oh
<Guest74213> so can you make the image now?
<tsimonq2> nope
<tsimonq2> still the same error
<Guest74213> yeah :'(
<tsimonq2> I'm wondering if I should just pull up a 14.04 VM and build it there, then transfer it over
<tsimonq2> (to the host system)
 * tsimonq2 trys that
<Guest74213> tsimonq2, after that try to install this snap https://uappexplorer.com/app/classic.mvo
<Guest74213> tsimonq2, https://uappexplorer.com/app/classic.mvo
<Guest74213> sorry
<Guest74213> tsimonq2, https://lists.ubuntu.com/archives/snappy-devel/2015-November/001290.html
<tsimonq2> well stahp, let me get it installed first jeez us
<Guest74213> :D
<Guest74213> by all
<tsimonq2> I have the Lubuntu 14.04.3 VM ready
<tsimonq2> so what do I install?
<ogra_> you enable the above PPA and install ubuntu-device-flash
 * tsimonq2 met dependency errors and got frustrated, so he is going to give in to just using 15.04 for now
<tsimonq2> ogra_: looking to build a snap for irssi, is it easy enough to just port it, or do I have to tweak it a lot?
<tsimonq2> ogra_: and what do I do abou dependencies?
<tsimonq2> *about
<ogra_> create a snapcraft file, it will care for the deps any everything
<tsimonq2> ok
<ogra_> (for that you want to install snapcraft indeed ... there is some PPA for it too)
<tsimonq2> already installed
<tsimonq2> ogra_: following https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/, running "snapcraft" in my irssi directory that I created with my snapcraft.yaml file just outputs that I am missing the parts property, but it isn't listed on that link. What's the reason?
<ogra_> dunno, someone didnt update the docs yet  ?
<tsimonq2> oh
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files
<ogra_> take a look at that snapcraft.yaml
<ogra_> at the bottom you see the packages it is supposed to install
<ogra_> so create your own parts block :)
 * tsimonq2 already found it here: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<tsimonq2> but thanks :)
<tsimonq2> so I just need to list ALL of the dependencies?
<tsimonq2> ogra_: ok, so irssi is on Github and requires some dependencies, is there any way that I could just clone it from Github, then add/edit some config files, and it will work?
<tsimonq2> ogra_: or will it require a complete rewrite?
<ogra_> tsimonq2, i think thats easy, but i have never done it ... my packages usually just use debs from the archive
<ogra_> you dont need to llist any dependencies
<tsimonq2> ogra_: well irssi IS in the repos, so I COULD do THAT too
<ogra_> see my file above ... it onnly defines bip and openssl
<ogra_> deps are pulled automatically into the snap
<tsimonq2> oh cool
#snappy 2016-11-28
<mup> PR snapd#2352 closed: tests: save/restore /snap/core/current symlink <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2352>
<dholbach> good morning
<zyga> good morning
<didrocks> hey guys
<foxmask> bonjello
<longsleep> sergiusens: Hey do you have a minute? I have troube registering a key with snapcraft, only get "Key registration failed: The account-key-request assertion is not valid."
<zyga> ogra_: hey
<zyga> ogra_: good morning, how are you?
<ogra_> zyga, fine, whats up ?
<longsleep> ogra_: hey i played around with snappy on the weekend and on my outdated Kernel 3.10 i get some apparmor denies from snap-confine - is there a list/instructions of what a Kernel needs to support nowadays?
<longsleep> ogra_: The exact problem is [20615.733900] type=1400 audit(1480285192.166:21): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/hello-world.mnt/" pid=2537 comm="snap-confine" srcname="/" flags="rw, bind" (essentially happens on running anything provided by a snap)
<ogra_> longsleep, yeah, snapd uses namespaces now ... not sure what kernel feature you need there though
<zyga> ogra_: hey, I have a question about bug ...
<mup> PR snapd#2362 opened: daemon: ensure `snap try` installs core if its missing <Created by mvo5> <https://github.com/snapcore/snapd/pull/2362>
<zyga> longsleep: hmm, I may be able to help with that
<zyga> one sec
<zyga> ogra_: do you recall this bug https://bugs.launchpad.net/snappy/+bug/1558944 ?
<mup> Bug #1558944: modprobe.d directory is created in /etc/modprobe.d/ <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1558944>
<ogra_> zyga, yep
<longsleep> ogra_: yeah i got user namespaces and stuff and lxc/lxd works just fine - this is Kernel 3.10 plus a lot of patches i did a while ago to get lxd running.
<zyga> longsleep: this errors is about when snap-confine tries to capture the mount namespace via a bind mount on the nsnfs sfs file sye
<zyga> longsleep: let me check the man page
<zyga> longsleep: technically since 3.8
<zyga> longsleep: but this is not kernel itself but apparmor on snap-confine
<longsleep> zyga: Kernel config: https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/arch/arm64/configs/sun50iw1p1smp_linux_defconfig + https://github.com/longsleep/build-pine64-image/blob/snappy/snappy/kernel/snapcraft.yaml#L15-L20
<zyga> longsleep: does that kernel have the full apaprmor patch set applied?
<longsleep> zyga: yes
<longsleep> zyga: not sure how exactly "full apparmor" is defined though
<zyga> longsleep: hmmm, can you file a bug on launchpad.net/snap-confine with the kernel config and the patches applied (perhaps git gree), I can try to check it out
<zyga> longsleep: thre are two branches that are in review that would let you run snap-confine without confinement that would perhaps unblock this
<zyga> longsleep: you can try those out
<longsleep> zyga: yes tonight when i am at home again - do you have a link?
<zyga> longsleep: yes, just opening
<ogra_> zyga, your bug is a duplicate of Bug 1638524
<mup> Bug #1638524: /etc/modprobe.d adds one to much directory level <Snappy:Fix Released> <ubuntu-core-config (Ubuntu):Fix Released> <https://launchpad.net/bugs/1638524>
<zyga> https://github.com/snapcore/snap-confine/tree/use-aa-support
<zyga> rebuild snap-confine with this
<zyga> and remove the apparmor profile entirely
<zyga> ogra_: checking
<longsleep> zyga: ok then it will run unconfined, this would help to know if that is the problem?
<zyga> ogra_: thank you! :)
<zyga> longsleep: yes
<mup> Bug #1558944 changed: modprobe.d directory is created in /etc/modprobe.d/ <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1558944>
<Odd_Bloke> ogra_: Any advance on https://bugs.launchpad.net/snappy/+bug/1639878 ?  That's currently blocking us from publishing Ubuntu Core to Azure.
<mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:New for ogra> <https://launchpad.net/bugs/1639878>
<longsleep> zyga: if you scroll down a bit on https://github.com/longsleep/linux-pine64/commits/pine64-hacks-1.2?after=1od8aSrvwOrJAFEQq6ob8d%2FRHfIrMzQ%3D then you see what i merged for apparmor support back then
<longsleep> (UBUNTU: SAUCE stuff)
<longsleep> maybe its too old or something was added since april
<zyga> longsleep: maybe, but I'm not a kernel expert, you'd have to check again
<longsleep> zyga: yeah will do thanks!
<mup> Bug #1645271 opened: User unable to disable service <Snappy:New> <https://launchpad.net/bugs/1645271>
<ogra_> Odd_Bloke, on my TODO for this week
<Odd_Bloke> ogra_: <3
<ogra_> (this needs a bit per-arch love first, we dont want all these modules on arm images for example)
<mup> PR snapd#2363 opened: snap: support "daemon: notify" in snap.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/2363>
<jamespage> morning all
<gerry_> hello all, has anybody hear of an issue of using the jdk plugin with a java swing gui?
<jamespage> is it possible to use the install from a snapcraft part as part of the build env for another?
<jamespage> specifically I'd like to build libvirt-python (using the python module) against libvirt built in a previous part
<jamespage> sergiusens, ^^ is that possible?
<gerry_> I have been told that the jdk plugin is headless as I need the x11 server how do I cure this in my wrapper?
<ahasenack> hi, is there a (trivial?) way to tell snapcraft cleanbuild to set a proxy for the lxd it creates?
<ahasenack> I set a proxy for lxc, via lxc config, but that doesn't affect the ubuntu install running inside the lxd
<mup> PR snapd#2362 closed: daemon: ensure `snap try` installs core if it's missing <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2362>
<jamespage> oh wait - that might actually be happening already
<gerry_> I have been told that the jdk plugin is headless could this be the reason why my java program crashes when I try to start it with sudo?
<gerry_> how would I load a part which contains the jdk headers ?
<gerry_> how do I do this? "If you only need to embed a Java runtime, add a part with the jdk type."
<zyga> gerry_: perhaps ask kyrofa or sergiusens when they are around or ask on the mailing list where others can google it easier
<gerry_> zyga: thanks for the advice, on this list? snapcraft@lists.snapcraft.io
<zyga> gerry_: yes, this one
<zyga> gerry_: both of the gentelmen I mentioned are in US-ish timezones so it may be better if you are "far away" from them
<gerry_> ok thank you very much for your help
<zyga> jdstrand: hey
<zyga> jdstrand: are you around today?
<jdstrand> zyga: hey, yes
<jdstrand> I just got online
<zyga> jdstrand: hey :)
<zyga> jdstrand: how were your holildays?
<zyga> jdstrand: I have a few things I'd like your input on
<zyga> jdstrand: some are more trivial than others, I think the most important one is the XDG_RUNTIME_DIR design
<jdstrand> zyga: they were pretty laid back but nice, thanks :) how was your weekend?
<zyga> jdstrand: can you please ping me when you have the time to talk about that?
<zyga> jdstrand: great, I was in a theme park with my family; lots of fun and memories :)
<jdstrand> zyga: nice!
<jdstrand> zyga: and sure-- it'll be a few minutes-- lots of pings and emails
<zyga> jdstrand: no worries, same here :)
<jdstrand> and by a few minutes, I mean a little while
<mup> PR snapd#2364 opened: overlord: increase test timeout and improve failure message <Created by mvo5> <https://github.com/snapcore/snapd/pull/2364>
<mup> PR snapd#2365 opened: interfaces: fix system-observe interface to work with ps_mem <Created by mvo5> <https://github.com/snapcore/snapd/pull/2365>
<mup> PR snapcraft#930 opened: Parser support remote dependencies <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/930>
<alex-abreu> mvo, ping
<mvo> alex-abreu: pong
<alex-abreu> mvo, just a quick question, just wondering if me & david can be added to the snappy dev team?
<mvo> alex-abreu: in github? or in LP ? or both?
<alex-abreu> mvo, LP
<mup> PR snapd#2366 opened: interfaces: apparmor support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2366>
<mvo> alex-abreu: sure, done
<alex-abreu> mvo, thank you
<abeato> jdstrand, I am getting this error in the automated review of the ofono snap: "not allowed by 'deny-connection/on-classic' in base declaration declaration-snap-v2_slots_deny-connection (service, ofono)", is that happening because latest snapd is still not used by the store?
<jdstrand> abeato: no, that is because there is no snap declaration for it
<jdstrand> abeato: let me add one
<abeato> jdstrand, ack, thanks
<jdstrand> abeato: done. you can press the publish button now
<abeato> jdstrand, nice!
<abeato> and published :)
<mup> PR snapcraft#931 opened: parser: add support for origin-{branch,commit,tag} <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/931>
<icey> is it possible to poke the CI to have it run again without a new push? ref: https://github.com/snapcore/snapcraft/pull/908
<mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
<zyga> icey: you should be able to rerun travis tests, as for other CI, I don't know
<icey> zyga: travis passes, autopkgtests failed
<zyga> icey: AFAIK pitti was the one that set this up, I don't know how to restart that
<pitti> icey: yes it is, you need the shared secret for that; mvo has it
<pitti> sorry, snapcraft, not snapd -- that would be sergiusens
<mup> Bug #1645377 opened: AppArmor policy error for networking at initialization, even with the correct network plug. <Snappy:New> <https://launchpad.net/bugs/1645377>
<mterry> Poke about bug 1642669 -- it's preventing us from supporting snap installation in the unity8-session snap.  We're not sure this is supposed to work or if we should be using a different method of installation
<mup> Bug #1642669: PolicyKit doesn't work inside snaps, preventing snap installation in unity8 <snapd-glib:Confirmed> <Snappy:New> <https://launchpad.net/bugs/1642669>
<mup> PR snapd#2367 opened: store: fix mismatch for snap download hash mismatch error message <Created by mvo5> <https://github.com/snapcore/snapd/pull/2367>
<mup> PR snapd#2354 closed: release: releasing package snapd version 2.18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2354>
<mup> Bug #1645377 changed: AppArmor policy error for networking at initialization, even with the correct network plug. <snapd-interface> <Snappy:Invalid> <ubuntu-ui-toolkit-examples:New> <https://launchpad.net/bugs/1645377>
<mup> PR snapd#2367 closed: store: fix mismatch for snap download hash mismatch error message <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2367>
<zyga> jdstrand: will you be able to do a pass over snap-confine pull requests today?
<mup> Bug #1592901 changed: gvfs confinement issues <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1592901>
<flexiondotorg> zyga, I've tried build a deb of snapd locally and in a PPA>
<flexiondotorg> It is failing :-(
<flexiondotorg> debian/rules:67: recipe for target 'override_dh_auto_build' failed
<flexiondotorg> Anything familiar about that?
<flexiondotorg> I've tried a local build too, same issue.
<flexiondotorg> I'd like to test some of my changes before submitting a pr.
<longsleep> Is anyone here who might be able to help me to get a key registered at the store with snapcraft? I only get "Key registration failed: The account-key-request assertion is not valid."
<zyga> flexiondotorg: you need to run govendor AFAIK, look at how debian/gbp.conf file please
<flexiondotorg> zyga, OK. I'll double check.
<flexiondotorg> Thanks.
<mhall119> oSoMoN: would you be willing to make a blog post about what you posted on G+ re: ubuntu-app-platform snap?
<oSoMoN> mhall119, I donât mind, where would that be published?
<mhall119> developer.ubuntu.com would be appropriate for that
<mhall119> do you have editor access to it?
<mup> Bug #1645407 opened: interface required: network namespace management <neutron> <snapd-interface> <snap-nova-hypervisor:New> <Snappy:New> <https://launchpad.net/bugs/1645407>
<mup> PR snapd#2368 opened: tests: parameterize remote store <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2368>
<mup> Bug #1645410 opened: interface required: openvswitch <snapd-interface> <snap-nova-hypervisor:New> <Snappy:New> <https://launchpad.net/bugs/1645410>
<mup> Bug #1645413 opened: gvfs confinement issues (directory listing) <Snappy:New> <https://launchpad.net/bugs/1645413>
<oSoMoN> mhall119, I donât think so
<zyga> jdstrand: any chance for some reviews/chat?
<jdstrand> zyga: I'm moving to that now
<zyga> jdstrand: great, I'll be here for a few more hours
<mup> Bug #1645407 changed: interface required: network namespace management <neutron> <snapd-interface> <snap-nova-hypervisor:Triaged> <Snappy:New> <https://launchpad.net/bugs/1645407>
<mup> PR snapcraft#932 opened: Implement `enable-ci travis --refresh` command <Created by cprov> <https://github.com/snapcore/snapcraft/pull/932>
<mup> Bug #1645445 opened: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1645445>
<mhall119> oSoMoN: you should be able to login at https://developer.ubuntu.com/openid/login/ now
<mhall119> go to (menu at the top) Zinnia->New Entry
<mhall119> and include the categories English and Article
<mhall119> ping me if you need help, the interface can be confusing
<longsleep> zyga: added bug https://bugs.launchpad.net/snap-confine/+bug/1645457, going to give https://github.com/snapcore/snap-confine/tree/use-aa-support a shot now
<mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
<zyga> longsleep: ok
<zyga> jdstrand: I'd like to land https://github.com/snapcore/snap-confine/pull/197/files
<mup> PR snap-confine#197: Fix spread tests preventing Ubuntu 16.04 i386 from passing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/197>
<zyga> jdstrand: unless you want to spend some time reviweing it in detail I'll just merge it
<longsleep> zyga: mhm - seems i cannot cross compile snap-confine for arm64 :/ 'no package 'glib-2.0' found
<longsleep> zyga: any idea if i could do that somehow on the device even when snap-confine does not work?
<zyga> longsleep: you probably need all the build-deps cross compiled
<longsleep> zyga: yeah :/
<zyga> longsleep: aka get the aarch64 version of them
<zyga> longsleep: (it's pretty easy)
<zyga> longsleep: if you don't know how to do that just build it natively on arm
<longsleep> zyga: yes but i do not have enough disk space on my laptop :)
<zyga> longsleep: install the classic snap
<zyga> longsleep: no, I mean, you can just get them from the archive
<zyga> longsleep: add arm64 arch to your apt sources
<longsleep> zyga: yes but i have to install them - and rootfs is pretty much full :(
<zyga> though I don't cross compile on arm often
<zyga> longsleep: well, just wait then, I'll sort things out :)
<longsleep> i can do it on arm64 - if i can install and run classic on my half working snappy install
<zyga> longsleep: your shell is unconfined, remember that
<jdstrand> zyga: looks fine to me
<longsleep> zyga: yes but how to switch to classic now?
<longsleep> root@localhost:~# classic
<longsleep> cannot bind-mount the mount namespace file /proc/3965/ns/mnt -> classic.mnt. errmsg: Permission denied
<longsleep> chicken egg problem?
<zyga> longsleep: classic is a snap, you don't need it if you have a rootfs
<zyga> longsleep: just do it manually
<zyga> longsleep: but again, if you don't want to figure out the chain of things that are required to check a potential fix then please just wait
<longsleep> zyga: well i want to learn details as much as possible - so if i can figure out things without asking too many stupid questions then i will continue
<zyga> longsleep: I'm happy to give you the answers if you want to dig deeper
<longsleep> zyga: awesome ! so i did not follow you above, what do you mean "do it manually" if i have a rootfs?
<zyga> https://github.com/zyga/devtools/blob/master/classic.sh
<longsleep> zyga: i mean i can download arm64 rootfs and chroot into it - somehting like that?
<zyga> I didn't try it for a while
<zyga> but that did do the trick before
<longsleep> zyga: ah cool, let me try
<zyga> and it can be used to learn what it takes to have "classic"
<longsleep> zyga: looks about right and pretty much what i had done now manually
<mup> PR snapd#2350 closed: tests: include /boot in saved state (including bootenv and any kernels) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2350>
<longsleep> zyga: so i got snap-confine compiled, any suggestion on how to replace it now for testing?
<longsleep> zyga: i probably did something wrong, but the self-compiled snap-confine from use-aa-support branch segfaults when running it like /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env
<longsleep> Segmentation fault
<mup> PR snapd#2348 closed: debian/rules: build with -buildoptions=pie <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2348>
#snappy 2016-11-29
<sitter> jdstrand, mhall119: about KDE dbus usage... org.kde.$name-$pid is used when the application can have multiple instances running at the same time. they all claim their own address on the bus due to their pid, but you can still find them all due to the basename. applications where multiple instances make no sense do simply not use the pid extension. that being said we do generally know which of the two forms an application will use and we do generally
<sitter> know the basename
<dholbach> hey hey
<mup> PR snapd#2366 closed: interfaces: apparmor support for classic confinement <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2366>
<mup> Bug #1645605 opened: No alsa module on ubuntu core image <Snappy:New> <https://launchpad.net/bugs/1645605>
<mup> PR snapd#2361 closed: snap: fix try command when daemon linie is added <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2361>
<didrocks> renato__: hey! Did you open a bug for snap connect not working after the first run of a snap using the content interface? If not, do you mind opening one?
<mup> Bug #1645606 opened: Default ubuntu core Pi2 configuration doesn't allow to use fullscreen browser <Snappy:New> <https://launchpad.net/bugs/1645606>
<zyga> ogra_: hey, I was thinking about simplifying the various repos on https://code.launchpad.net/snappy-hub
<zyga> ogra_: specifically I'd like to move the gadget snaps for reference platforms over to github.com/snapcore/
<zyga> and to give them their proper projects on launchpad so that they can have bugs associated with them
<ogra_> zyga, well, i'd like to start auto-builds for the gadgets before end of year ... i dont think we have that for github projects yet (ICBW though)
<ogra_> i'd prefer to wait with the move til github is fully supported
<zyga> ogra_: my idea is to mirror them to launchpad
<zyga> ogra_: but use git in both places
<zyga> ogra_: and to really make the reference code discoverable
<zyga> ogra_: can you show me which of the 50 branches on snappy-hub contains the published pi2 and pi3 gadgets? I'd like to start with those
<ogra_> dunno, do we have auto-buiollds for that in place (i.e. you can bump the version and out comes a snap )
<ogra_> huh ? 50 branches ?
<zyga> ogra_: github -> (git mirror) -> launchpad project -> (snapcraft.yaml auto build to edge) -> store
<zyga> https://code.launchpad.net/snappy-hub
<ogra_> doesnt open here
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<zyga> odd, this works here: https://code.launchpad.net/snappy-hub
<ogra_> thats the master branch we always used
<zyga> ok
<zyga> thanks, I'll use that
<ogra_> i didnt even know that there was anything else under snappy-hub :P
<zyga> how does it auto build
<ogra_> but i had plabnned to re-work it comp,ltely to use archive packages for the bootloader binaries etc
<ogra_> and for auto builds
<ogra_> (we dont have that yet ... this move kind of trashes my plans then)
<zyga> ogra_: hmm, why?
<ogra_> why what ?
<zyga> ogra_: (it's not a plan, I want to make the sources for gadgets discoverable)
<zyga> why does it trash that plan?
<zyga> I want people to be able to find them, report bugs against them and fork them for local tinkering
<ogra_> well, it adds complexity, it doesnt "trash"them ... sorry :)
<zyga> ah
<zyga> I hope you just use git
<zyga> and that's it
<zyga> the rest should be automatic
<zyga> ogra_: later on we should be able to build them with snapcraft as well
<zyga> ogra_: right now I'll just add a readme file and we can work from there
<zyga> ogra_: does that sound good to you? anything I'm missing"
<ogra_> well, i'd like to sdo the snapcraft (and first of all the deb part) first
<ogra_> we dont have sources for some of the uboot builds etc
<ogra_> and foundations insists these should all be deb based in the archive
<ogra_> i think it would make sense to have a meeting before we change the world
<zyga> hmm
<ogra_> i.e. we need all the binaries in these trees packaged and reviewed (which is partially their responsibiliry)
<zyga> the archive part is interesting, I suspect we're going to use archives but everyone building their own won't care about that
<ogra_> exactly
<zyga> right now it's pretty hard to find our gadgets and even harder to make sense of this all and how to tweak e.g. the pi2 one
<ogra_> apart from BBB these are all official bits that need a classic image equivalent
<zyga> I think the git move is separate and should not wait on this
<ogra_> which means they need to have debs for the bootloader
<ogra_> so to not do the work twice we should start with the debs
<zyga> I think I'm still missing something
<zyga> If all I do is move the current branch to git and publish it on snapcore/*
<ogra_> turning on auto-builds and have snapcraft builds is indeed a side job but moving away from LP adds a lot of complexity
<zyga> then everyone working on this can continue to do what they do there
<zyga> and it's easier to find
<zyga> no
<ogra_> i'd prefer to have everything ready and done and*then*Ã do the move)
<zyga> remember: lp can mirror git!
<zyga> we can do the move in 3 hours and then all git commits on github show up in launchpad (as git) and can be acted upon
<ogra_> without any intervention now ?
<zyga> yes, I think so
<ogra_> last i chercked you needed to manually do that first every time
<zyga> manually do the git mirrors?
<zyga> I can check, give me a sec
<ogra_> yes
<zyga> ogra_: btw, I also feel this should be a repo-per-gadget
<ogra_> we should have a reference repo for porters ... but i like to have all bits in one place for the official images
<ogra_> though if you insist ...
<zyga> ogra_: this means no snapcraft builds
<zyga> ogra_: one repo per snapcraft.yaml I think
<ogra_> (makes everything harder imho)
<zyga> ogra_: and also, bbb is not officially supported so it'd have to be somewhere else
<zyga> ogra_: I understand the transition is difficult but current situation is very bad for everyone trying to figure out how this works and fork something to expeirment
<ogra_> well, irt is the only one that can use unpartitioned bootloader paertitions ... which makes it a good example
<ogra_> but well, go ahead and rip it apart ... it will take me a lot longer to sort everything then though
<zyga> ogra_: that's all fair, we need to just find a spot for all the (large) number of non-officially supported devices
<zyga> ogra_: don't get me wrong, I don't want to make your life harder
<zyga> ogra_: I hope we can all benefit from this
<zyga> ogra_: please help me help everyone
<ogra_> (kind of trashes my planning ... but it wasnt high on my TODO (i.e. notz before EOY) anyway)
<abeato> mvo, hi, I re-pushed https://github.com/snapcore/snapd/pull/2252 to re-run the tests, most of them worked this time. The few that did not seem to be due to infrastructure: "cannot connect to linode:..." etc
<mup> PR snapd#2252: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2252>
<zyga> ogra_: can you still execute your plan the way you want when this is on git on github in snapcrore?
<ogra_> sure, i just need more time to adapt to the new stuff first
<zyga> ogra_: to git vs bzr or is there something else?
<ogra_> to a completely new setup and all the possible (and unplanned) differences in that
<zyga> ogra_: but all I want to do is to move the repository, is that what you mean?
<ogra_> my plan was simply a different order and not to sit down and find out how/if auto-builds work, to re-arrange the world etc etc as the first step
<ogra_> i.e. make things work first and *then* do the chasnges
<zyga> ogra_: I see, if we waited till next year would that make it eaier for you?
<ogra_> but as i said, i only have two weeks before EOY ... i wont finish that stuff in that time anyway
<ogra_> and we need to coordinate with foundations somehow for everything but BBB
<ogra_> since they will want a central place for the binaries that also the debs can use
<ogra_> (uboot, blobs etc)
<zyga> ogra_: can that be the git repo perhaps?
<ogra_> no
<didrocks> zyga: on alsa: if I'm correct, there are multiple sound modules and they have different names depending on the card
<zyga> ogra_: why not?
<ogra_> not if the git repo has not been completely changed from what the LP one contains today
<didrocks> ogra_: do you know if this is correct? ^
<zyga> didrocks: interesting, how does it work on classic?
<ogra_> the repo will end up to only have a snapcraft.yaml in the end
<didrocks> zyga: it's a very good question, I never dive into this part, pulseaudio worked for me :p
<zyga> ogra_: interesting, and where will all the source code be?
<ogra_> zyga, preferably debs in the archive
<ogra_> so the classic images can use them
<zyga> ogra_: hmm, I see
<zyga> ogra_: I think this is somewhat difficult for others (poor reference) because they will start with uboot tree
<zyga> ogra_: not with any debss
<zyga> ogra_: but perhaps we can find a way to accomodate that somehow
<didrocks> zyga: can you try to lsmod | grep snd on your machine?
<didrocks> I do have:
<didrocks> snd                    81920  18 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,thinkpad_acpi,snd_seq_device
<didrocks> (notice the thinkpad_acpi)
<ogra_> zyga, the only arch that can use a uboot tree only is the BBB
<ogra_> zyga, all others need additional blobs
<zyga> ogra_: that's fine but my point is that the snapcraft.yaml that is deb based is not aligned with people that want to create a gadget for their board that uses some bootloader and they build it from sources
<didrocks> zyga: ah, the machine-dependant one for me is: cat /proc/asound/modules
<didrocks>  0 snd_hda_intel
<ogra_> didrocks, there are /usr/share/alsa/cards and /usr/share/alsa/ucm
<zyga> didrocks: I'm on a VM here, on my thinkpad natively I'd probably get the same thing
<ogra_> they have the default configs for certain cards
<ogra_> zyga, yes, so using our official gadget trees as reference is perhaops the wrong thing altogether
<didrocks> zyga: and look at /etc/modprobe.d/alsa-base.conf
<didrocks> those are the rules
<ogra_> zyga, like our kernel snaps are not even remotely related to what the kernel snapcraft plugin gives you
<mvo> abeato: aha, I have a look, thank you
<abeato> great, np
<didrocks> ogra_: context is bug #1645605
<mup> Bug #1645605: No alsa module on ubuntu core image <snapd-interface> <Snappy:Incomplete by zyga> <https://launchpad.net/bugs/1645605>
<ogra_> zyga, anyway, do what you feel you need to do ...
<mvo> didrocks: hey, thanks for the additional info in the download bug \o/ I'm going through it now and try to make sense of it
<ogra_> didrocks, BSPs usually have their sound bits builtin ... also arm boards usually use UCM
<didrocks> mvo: thanks! If there is anything else I can do to help debugging, I have my setup started here
<ogra_> didrocks, anyway ... your alsa bug is a kernbel bug in the first place
<ogra_> (if you dont find a soundcard there is either the UCM setup or the module missing in the kernel)
<ogra_> i thought we had that enabled but /proc/asound/cards is empty on all boards here
<ogra_> so first of all the kernel needs the bits enabled to turn on UCM ... and it should ship the right UCM config
<zyga> re
<zyga> ogra_: that's true
<zyga> ogra_: I guess we have to decide what to do then
<zyga> ogra_: perhaps we need "both" to the point where those are identical (long term plan)
<zyga> ogra_: perhaps something else entirely
<ogra_> well, rolling a gadget isnt "have that ubioot tree and drop a snbapcraft.yaml in"
<ogra_> it is sadly a lot more complex
<zyga> ogra_: indeed
<zyga> ogra_: do you think it can be, eventually, a snapcraft.yaml in a tree of sources (and blobs if there's no source for them) that builds all the way?
<ogra_> anyway, if you feel it is urgent to do that github move and split of trees right now, go ahead
<ogra_> no
<ogra_> you need a lot of manual work, tinkering and testing to find the right setup before being able to build your first gadget if it is a completely new arch
<zyga> ogra_: oh, sure, I mean our references
<ogra_> we should have a reference tree for every bigger setup imho
<zyga> ogra_: do you think we can eventually build them from source all the way?
<ogra_> (i.e. we dont have anything for sunxi boards ... proting to that will be a pain for users)
<ogra_> we can surely build parts opf them from source ... really depends on the board
<zyga> ogra_: I see, thanks for the input
<zyga> ogra_: I'm not going to do anything right now, I've added a card to track this
<ogra_> the only arches where booting does nto depend on binary blobs are x86 and BBB thogh
<ogra_> *not
<zyga> ogra_: I'd like to improve the visibility of the gadgets
<zyga> ogra_: and perhaps de-mystify them a little
<ogra_> +1
<zyga> ogra_: but it's a complex topic and I don't want to just break more than I improve
<seb128> is there any documentation about the dump plugin?
<ogra_> well, i think forst of all we should have a meeting or so with foundations
<seb128> http://snapcraft.io/docs/reference/plugins/dump is virtually empty
<ogra_> to clearly line out a plan ...
<zyga> ogra_: that's a good idea
<seb128> the "examples" also sends you to an empty page
<zyga> ogra_: preferably early so that everyone can think about this over xmas
<ogra_> i had hoped to do that in the hague ... but there was not much foundations there
<ogra_> (i want steve and adam in that meeting)
<zyga> ogra_: so slangasek and ...  (slipped my head)
<zyga> (and looking at /names doesn't help)
<ogra_> the infinite one ;)
<ogra_> infinity in case that wasnt clear :)
<mup> PR snapd#2369 opened: snap: disable support for socket activation <Created by stolowski> <https://github.com/snapcore/snapd/pull/2369>
<Chipaca> does adt-buildvm-ubuntu-cloud on xenial not work to build yakkety images?
<mvo> Chipaca: you need the version from xenial-backports iirc
<mvo> Chipaca: apt install autopkgtest/xenial-backports
<Chipaca> mvo, ah! thanks
<Chipaca> that works, indeed
<mup> PR snapd#2363 closed: snap: support "daemon: notify" in snap.yaml <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2363>
<zyga> ogra_: right, that was clear, thanks :)
<ogra_> :)
<mup> PR snapd#2370 opened: i18n: use github.com/ojii/gettext.go (pure go) for i18n to avoid cgo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2370>
<gerry_> snappy-debug suggestion "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" anybody have any idea how to do this?
<mup> Bug #1402536 changed: snappy install should support version/hash to get specific version from the store <Snappy:Invalid> <https://launchpad.net/bugs/1402536>
<mup> Bug #1413185 changed: Snappy remote install requires password three times <snappy> <Snappy:Fix Released> <https://launchpad.net/bugs/1413185>
<mup> Bug #1457491 changed: Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode) <snappy-robustness> <Snappy:Won't Fix> <https://launchpad.net/bugs/1457491>
<mup> Bug #1459642 changed: If a gadget install fails, udev is not cleaned up <Snappy:Won't Fix> <Snappy 15.04:Won't Fix> <https://launchpad.net/bugs/1459642>
<mup> Bug #1464944 changed: no way to configure keyboard layout <Snappy:Fix Released> <https://launchpad.net/bugs/1464944>
<mup> Bug #1466682 changed: Docker unix socket permission issue on ubuntu-core update <Snappy:Fix Released> <https://launchpad.net/bugs/1466682>
<zyga> ogra_: invinte sent, let me know if that's that's too late for you
<mup> Bug #1468958 changed: selftests print "no such file or directory" on error <Snappy:Fix Released> <https://launchpad.net/bugs/1468958>
<renato__> didrocks, hey, I saw someone complaining about that on the ml, I think there is a bug already. Let me find it
<ogra_> zyga, hmm, its ok ... are you sure that short of a notice works for the others though ?
<mup> Bug #1472721 changed: snappy update shows no message when there are no updates <Snappy:Fix Released> <https://launchpad.net/bugs/1472721>
<mup> PR snapd#2371 opened: daemon, store: let snap info find things in any channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/2371>
<mup> Bug #1472802 changed: ubuntu-core timezone config has no effect <Snappy:Won't Fix> <https://launchpad.net/bugs/1472802>
<zyga> ogra_: if not we can move
<mup> Bug #1474125 changed: Image got in a broken state after update -> rollback -> update (wrong kernel) <Snappy:Fix Released> <Snappy 15.04:Fix Released by sergiusens> <https://launchpad.net/bugs/1474125>
<renato__> didrocks, ohh, just saw that you replied the e-mail asking to open the bug, but did not get reply. Let me open it
<mup> Bug #1479027 changed: package.yaml docs missing releases OR frameworks fields <snap-docs> <Snappy:Won't Fix> <https://launchpad.net/bugs/1479027>
<mup> Bug #1481086 changed: Need API/cli method to know if "is_snappy" <Snappy:Fix Released> <https://launchpad.net/bugs/1481086>
<mup> Bug #1484982 changed: service description whitelist unnecessarily strict <Snappy:Invalid> <https://launchpad.net/bugs/1484982>
<mup> Bug #1495059 changed: cannot add new sudo users <Snappy:Fix Released> <https://launchpad.net/bugs/1495059>
<mup> Bug #1495452 changed: auto upgrade unintentionally updates /etc/udev/rules.d/70-persistent-net.rules <Snappy:Fix Released by ogra> <Snappy 15.04:Fix Released by ogra> <Snappy trunk:Fix Released by ogra> <https://launchpad.net/bugs/1495452>
<mup> Bug #1495662 changed: Services and binaries allow _ # <Snapcraft:Fix Released by sergiusens> <Snappy:Fix Released> <Snappy 15.04:Won't Fix> <Snappy trunk:Fix Released> <https://launchpad.net/bugs/1495662>
<gerry_> hi I have this suggestion by snappy-debug: "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" anybody have experience of this?
<mup> Bug #1496319 changed: Could not create symlink to hw device with udev rules <Snappy:Won't Fix> <https://launchpad.net/bugs/1496319>
<mup> Bug #1499109 changed: hw-assign and oem assign are inconsistent <Snappy:Won't Fix> <https://launchpad.net/bugs/1499109>
<mup> Bug #1499478 changed: snappy install failure if service doesn't start does not cleanup <Snappy:Fix Released> <https://launchpad.net/bugs/1499478>
<mup> Bug #1499662 changed: boot partition size should be configurable <Snappy:Fix Released> <https://launchpad.net/bugs/1499662>
<mup> Bug #1499993 changed: U-d-f uses hardcoded names for kernel and initrd instead of the ones defined in hardware.yaml <Snappy:Fix Released> <https://launchpad.net/bugs/1499993>
<mup> Bug #1500020 changed: /var/lib/opencryptoki needs to be in /etc/system-image/writable-paths <Snappy:Fix Released> <ubuntu-core-config (Ubuntu):Fix Released> <https://launchpad.net/bugs/1500020>
<foxmask> bonjello
<mup> Bug #1502810 changed: Implement "snappy try" <Snappy:Fix Released> <https://launchpad.net/bugs/1502810>
<longsleep> zyga: i tried snap-confine from the use-aa-support branch but it segfaults : http://paste.ubuntu.com/23553160/ - do you have any suggestion?
<zyga> longsleep: looking
<zyga> longsleep: any chance to get a backtrace?
<longsleep> zyga: yeah let me install gdb
<mup> Bug #1504649 changed: dns-nameserver, dns-nameservers and dns-search not documented for snappy config for static ip addresses <Snappy:Won't Fix> <https://launchpad.net/bugs/1504649>
<mup> PR snapd#2372 opened: interfaces/seccomp: add support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2372>
<longsleep> zyga: here you go: http://paste.ubuntu.com/23553195/
<zyga> longsleep: checking
<longsleep> not much in there :/
<zyga> longsleep: oh, nice
<zyga> longsleep: up
<zyga> longsleep: (one sec, switching branches)
<zyga> longsleep: print label
<mup> Bug #1504938 changed: invalid character '<' looking for beginning of value <Snappy:Won't Fix> <https://launchpad.net/bugs/1504938>
<mup> Bug #1505696 changed: SquashfsTestSuite.TestRunCommandUgly fails if you have a non-english locale <Snappy:Fix Released> <https://launchpad.net/bugs/1505696>
<mup> Bug #1505717 changed: prefer vmlinuz-*.efi.signed over vmlinuz in device tarball <Snappy:Fix Released> <https://launchpad.net/bugs/1505717>
<zyga> longsleep: print mode
<zyga> longsleep: perhaps something I dind't account for, I can fix that quickly
<longsleep> zyga: http://paste.ubuntu.com/23553198/
<zyga> longsleep: let me cook a patch
<zyga> longsleep: nice, thanks
<longsleep> zyga: let me see if i can resolve the not found
<zyga> longsleep: nah, that's all good
<zyga> longsleep: I know what the bug is already
<zyga> longsleep: thank you!!! :)
<longsleep> zyga: awesome :)
<mup> Bug #1507607 changed: move boot-ok to before sessions <Snappy:Fix Released> <https://launchpad.net/bugs/1507607>
<longsleep> zyga: fixed the not-found - see here http://paste.ubuntu.com/23553206/
<zyga> longsleep: I just pushed a fix
<longsleep> zyga: rebuilding
<zyga> longsleep: feel free to comment on the pull request as well once you get this working
<mup> Bug #1511435 changed: ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1511435>
<longsleep> zyga: looks better now
<longsleep> /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env
<longsleep> SNAP_NAME is not set
<longsleep> zyga: so do you have a suggestion how i could fully test this now?
<longsleep> zyga: still does not seem to work though
<longsleep> SNAP_NAME=hello-world /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env
<longsleep> cannot change apparmor hat. errmsg: Operation not permitted
<longsleep> support process for mount namespace capture exited abnormally
<longsleep> [157896.731125] type=1400 audit(1480424709.523:33): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 profile="unconfined" pid=17652 comm="snap-confine"
<zyga> longsleep: (just in a call now, I'll be with you in 15 minutes0
<longsleep> zyga: all right thanks - take your time and just ping me when you are available
<mup> PR snapcraft#918 closed: create the deltas package/class with xdetal generation implementation <Created by seawaywen> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/918>
<zyga> longsleep: nice
<zyga> longsleep: you now need snapd and snap-run to get this to work
<zyga> longsleep: oh, that's super odd, let me check why this happens (the hat thing which is what this was supposed to fix)
<longsleep> zyga: is there a way i can make snapd/snap-run use my custom snap-confine?
<zyga> longsleep: fixed again
<longsleep> zyga: you are awesome, rebuilding
<zyga> longsleep: yes, do a bind mount so it shows up in /usr/lib/snapd
<zyga> longsleep: sudo mount --bind some/custom/snap-confine /usr/lib/snapd/snap-confine
<zyga> longsleep: and make sure it's stuid root
<zyga> setuid*
<zyga> longsleep: (no wonder this doens't work, there's no spread test for it yet)
<zyga> longsleep: thank you for trying this
<longsleep> zyga: seems to work now
<zyga> longsleep: great!
<longsleep> zyga: http://paste.ubuntu.com/23553265/ so what does that tell us now?
<zyga> longsleep: thank you!
<mup> Bug #1511447 changed: snapcraft stage does not work with Go and Launchpad <Snapcraft:Confirmed> <https://launchpad.net/bugs/1511447>
<longsleep> zyga: that branch will get merged into release eventually and it wont matter that my kernel does what it does?
<zyga> longsleep: that it should be good
<zyga> longsleep: you can set SNAP_CONFINE_DEBUG=yes
<zyga> longsleep: to see what's going on
<zyga> longsleep: yes
<zyga> longsleep: I plan to merge it as soon as I get a review from security
<zyga> longsleep: well..
<zyga> longsleep: if your snap-confine is unconfined it won't try to switch hat
<zyga> longsleep: there are other places that care about apparmor
<zyga> longsleep: (in snapd)
<zyga> longsleep: but some of the work I'm doing will make that more flexible
<zyga> longsleep: I want to know one more thing
<zyga> longsleep: can you run
<zyga> longsleep: apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine
<zyga> longsleep: that probalbly crashes but I want to see why
<longsleep> zyga: sure, this is the debug output http://paste.ubuntu.com/23553270/
<mup> Bug #1511448 changed: ubuntu-snappy.firstboot fails when oem snap contains config for snaps not preinstalled, built-in <Snappy:Won't Fix> <https://launchpad.net/bugs/1511448>
<longsleep> zyga: the apparmor_parser -r does not print anything
<zyga> longsleep: odd
<zyga> longsleep: hmmm
<zyga> longsleep: I'll get back to you
<jamespage> anyone had any success in allowing a confined snap to manage network namespaces?
<zyga> jamespage: hey
<jamespage> zyga, hello
<zyga> jamespage: jdstrand is working on supporting it, the current idea is that /run/something-used-by-ip-netns will be like /media today
<jamespage> I was just reading https://bugs.launchpad.net/snappy/+bug/1624675
<mup> Bug #1624675: Please add network-namespace interface <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1624675>
<zyga> jamespage: and then you can use ip setns
<zyga> jamespage: I'll try to sync with jamie today, adding that directory should be trivial
<zyga> jamespage: would that be sufficient for you?
<jamespage> zyga, it might be - the neutron agents do a load of things with namespaces to support overlapping ip address ranges and alike
<jdstrand> jamespage: note that as of today, you can use devmode to create network namespaces via 'ip netns' that will work for that snap
<zyga> jdstrand: hey!
<jamespage> jdstrand, yeah - have my snaps working ok with the hypervisor snap in devmode
<zyga> jdstrand: I sent you an invite for a call today (if you can get there please let me know)
<jdstrand> zyga: hi!
<jamespage> I think that this netns bit is the last part that means I still need devmode
<jamespage> (looking at the kernel log at least)
<jamespage> well for now
<jdstrand> jamespage: do you have a wiki page for testing this? I've never gotten very far with neutron/etc in the past. ideally this would be to run in a vm
<jamespage> jdstrand, yeah - we do
<zyga> jdstrand: I replied to your question on https://github.com/snapcore/snap-confine/pull/193 -- I'd love to know if I can merge that and if my explanation is correct, I'm working on addressing the remaining things in a new pull request
<mup> PR snap-confine#193: Replace mkpath with sc_nonfatal_mkpath <Created by zyga> <https://github.com/snapcore/snap-confine/pull/193>
<jdstrand> jamespage: do you know otoh if these things are using 'ip netns' or are they doing something else?
<jamespage> jdstrand, https://github.com/openstack-snaps/snap-test
<jamespage> I need to add in the bit for the nova-hypervisor snap - however that is a little dependent on some of the interface work I have inflight atm
<jamespage> jdstrand, they all use ip netns
<jdstrand> jamespage: ok, I'll be poking at this soon (ie, this week)
<jamespage> but I guess using in devmode would be supportable
<jamespage> I'll need to drop the newer interface bits from the snap for now
<jdstrand> I can deal with interface bits fine
<jdstrand> so don't do anything extra on my account
<jamespage> jdstrand, ack
<jdstrand> zyga: re the meeting later, I'll talk to tyhicks and one of us will join
<jamespage> tbh most of my time in the last few days was burnt on trying to get libvirt to work from within a snap
<jamespage> I parked that for now
<jdstrand> eek
<zyga> jdstrand: perfect, that's exactly what I suggested in the meeting notes
<jdstrand> jamespage: definitely start with devmode. libvirt as a snap is going to need to be super-privileged like docker-support and lxd-support
<jamespage> jdstrand, most of my pain was due to the amount of build time detection and path encoding that libvirt does
<jdstrand> yeah, I can imagine
<jamespage> anyway I'm aiming for on host os libvirt and ovs for now
<jamespage> I have another interface to propose - openvswitch in the style of libvirt - just allows access to the ovs db socket on the host
<mup> Bug #1516351 changed: Consider changing release id <Snappy:Fix Released> <https://launchpad.net/bugs/1516351>
<mhall119> tedg: do you know what's keeping inkscape from being published to the stable channel?
<mup> Bug #1520093 changed: ugly error when trying to set config without sudo <Snappy:Won't Fix> <https://launchpad.net/bugs/1520093>
<mup> Bug #1521927 changed: Package operations are not atomic. <Snappy:Fix Released> <https://launchpad.net/bugs/1521927>
<mup> Bug #1563737 changed: Bootloader type detection ignores the actual bootloader in use <Snappy:Fix Released> <initramfs-tools-ubuntu-core (Ubuntu):Fix Released> <https://launchpad.net/bugs/1563737>
<mup> Bug #1564316 changed: classic dist-upgrade fails on sudo and tzdata... <Snappy:Fix Released> <https://launchpad.net/bugs/1564316>
<didrocks> renato__: hey, did you file it? I would like a link I can reference :)
<mup> Bug #1569577 changed: please remove var/lib/snapd/apparmor/additional from debian/snapd.dirs <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1569577>
<renato__> didrocks, https://bugs.launchpad.net/ubuntu-app-platform/+bug/1645731
<mup> Bug #1645731: Fail to access the shared content if app starts before connect interface <Ubuntu App Platform:New> <https://launchpad.net/bugs/1645731>
<didrocks> renato__: thanks! :)
<didrocks> renato__: hum, no snappy ref?
<didrocks> renato__: didn't Mirv said this was a snappy bug? mind adding this task?
<mup> Bug #1570280 changed: snap and snappy man pages incomplete <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1570280>
<renato__> didrocks, this is a snapd bug I think
<didrocks> renato__: please add an upstream snappy task then
<zyga> didrocks, renato__: I just assigned that bug to mysel
<zyga> f
<renato__> zyga, ok thanks
<didrocks> zyga: thanks :)
<mup> Bug #1570261 changed: Snappy does not deal well with non-existing/non-working daemon command <Snappy:Fix Released> <https://launchpad.net/bugs/1570261>
<mup> Bug #1645731 opened: Fail to access the shared content if app starts before connect interface <Snappy:Confirmed for zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
<tedg> mhall119: Yes
<mup> Bug # changed: 1570618, 1571710, 1571721, 1572151, 1572463
<tedg> mhall119: It's based on a pre-release version that hasn't been released yet. Will be pushed to stable once 0.92 is released.
<mhall119> ah, cool, ok
<mhall119> is that happening soon? If not, would they snap up the current stable?
<mup> PR snapd#2373 opened: debian: remove unneeded conflict against the "snappy" package <Created by mvo5> <https://github.com/snapcore/snapd/pull/2373>
<mup> Bug #1574526 changed: x11 plug doesn't allow getsockname, breaks xeyes <snappy-interfaces> <verification-done> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1574526>
<mup> Bug #1574556 changed: apparmor denials reported for encrypted HOME <apparmor> <Snappy:Fix Released> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <ubuntu-core-launcher (Ubuntu Xenial):Fix Released by jdstrand> <https://launchpad.net/bugs/1574556>
<mup> Bug #1574829 changed: snappy install requires root or login, but doesn't tell you so <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1574829>
<mup> Bug #1575399 changed: Half installation for a snap <verification-done> <Snappy:Fix Released> <https://launchpad.net/bugs/1575399>
<mup> Bug #1576263 changed: Installing a non-existent app from the store results in core being downloaded but not installed <Snappy:Fix Released> <https://launchpad.net/bugs/1576263>
<mup> Bug #1577228 changed: "Ubuntu Core Snappy AutoUpdate" service failed with "error: the required argument `<snap>` was not provided" <amd64> <apport-bug> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1577228>
<mup> Bug #1577441 changed: No way to rollback a snap since the move to snap command <Snappy:Fix Released> <https://launchpad.net/bugs/1577441>
<wxl> interesting
<wxl> oops wrong channel
<wxl> sheesh
<wxl> is there a snappy core channel?
<mup> Bug #1577439 changed: No more -u/-v options for "list" <Snappy:Fix Released> <https://launchpad.net/bugs/1577439>
<mup> Bug #1579932 changed: The user acceptance test suite is called integration-tests <Snappy:Fix Released by elopio> <https://launchpad.net/bugs/1579932>
<mup> Bug #1580403 changed: snap tries to manage bootloader in snappy-on-ubuntu-classic mode <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1580403>
<didrocks> wxl: this is this one
<mup> Bug #1583259 changed: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:Fix Released> <click-reviewers-tools
<mup> (Ubuntu):Fix Released> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
<wxl> didrocks: great. is there a prepared snappy image i could use in virtualbox or do i just need to go ahead and install one?
<didrocks> wxl: hum, there is a qemu image, I don't think there is one for virtualbox
<didrocks> Trevinho: hey! I would need the bug reference for the snapcraft parser now please :)
<wxl> didrocks: great thanks
<Trevinho> didrocks: I already subscribed to you there...
<didrocks> Trevinho: oh?
<Trevinho> didrocks: see https://github.com/snapcore/snapcraft/pull/930
<mup> PR snapcraft#930: Parser support remote dependencies <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/930>
<Trevinho> didrocks: https://bugs.launchpad.net/snapcraft/+bug/1645350
<mup> Bug #1645350: Parts depending on other remote parts aren't properly added <Snapcraft:In Progress by 3v1n0> <https://launchpad.net/bugs/1645350>
<didrocks> Trevinho: thanks!
<didrocks> Trevinho: you didn't subscribe me to the bug
<Trevinho> didrocks: I did...  https://usercontent.irccloud-cdn.com/file/sJNTn1yT/
 * Trevinho has to fix the branch now... :-/
<didrocks> Trevinho: I only see Joe and you on my launchpad bug
<Trevinho> weird
<didrocks> you are talking about #1645350, right?
<mup> Bug #1645350: Parts depending on other remote parts aren't properly added <Snapcraft:In Progress by 3v1n0> <https://launchpad.net/bugs/1645350>
<Trevinho> yes
<didrocks> this is weird, I definitively have only you two in this section :/
<Trevinho> who knows.... maybe you filter out something... but I did subscribe you just after filing it
<jdstrand> zyga: 193 approved
<didrocks> Trevinho: well, my filter wouldn't change launchpad page :p
<mup> Bug #1584586 changed: First snap install should fail fast rather than download OS snap <Snappy:Fix Released> <https://launchpad.net/bugs/1584586>
<Trevinho> didrocks: yeah I mean... Something related to lp project options?
<didrocks> Trevinho: could beâ¦ I don't think, first time I see that
<zyga> jdstrand: thanks!
<jdstrand> zyga: thanks for the cleanups :)
<zyga> jdstrand: I'm taking a different approach for mode/uid/gid mkdir, that will be easier to verify I hope
<gerry_> hi I get this output when I try to run my program as sudo  "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" could anyone advise me how to deal with this please?
<gerry_> sorry meant to say while running snappy-debug
<jdstrand> gerry_: if you get it while running sudo, it sounds like the unix permissions are being ignored because you are root. eg, perhaps a user owned directory that is 755 that root is writing to, a file that is 644 that isn't root owned, etc
<jdstrand> that is usually what triggers that sort of thing
<gerry_> ok so I change the permissions of my file?
<jdstrand> if that is the issue, that would fix it, yes. change perms or owner
<gerry_> jdstrand : thank you for your help I will try
<mup> PR snapd#2374 opened: snap: tweak snap install output as designed by Mark <Created by mvo5> <https://github.com/snapcore/snapd/pull/2374>
<gerry_> jdstrand: no I still  have the same problem my program run when installed in devmode but crashes with "No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server" when I try to run it with sudo, while installed in dangerous mode
<mup> Bug # changed: 1586248, 1587175, 1587445, 1587676
<wxl> um, so is ubuntu core (http://cdimage.ubuntu.com/ubuntu-core/16/stable/) and ubuntu snappy core different???
<mup> Bug #1596243 changed: snap gets stuck removing snap <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1596243>
<mup> Bug #1597417 changed: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1597417>
<didrocks> wxl: no, it's the same, ubuntu core is the official name
<didrocks> (yeah, naming was bad, sorry)
<mup> Bug #1597948 changed: github.com/snapcore/snapd/cmd/snap TestSnapRunSnapExecEnv fails if HOME is set in environment <Snappy:Fix Released> <https://launchpad.net/bugs/1597948>
<mup> Bug #1599919 changed: SnapOpSuite unit tests interfere with the user's $HOME/.snap directory <Snappy:Fix Released> <https://launchpad.net/bugs/1599919>
<wxl> didrocks: ok. well when i boot that image, it asks me to configure networking. it doesn't seem to give me an option for wifi, which is understandable, i guess. is there a workaround besides building a custom image? also, is there official documentation that goes over things like this?
<didrocks> wxl: you are in a VM, correct? This is why you don't have wifi option
<didrocks> but your VM should share connexions
<mup> Bug #1600260 changed: Support paravirtualization <Snappy:Fix Released by ogra> <initramfs-tools-ubuntu-core (Ubuntu):Fix Released by ogra> <https://launchpad.net/bugs/1600260>
<wxl> didrocks: omg. derp.
<mup> Bug #1600719 changed: The camera interface only grants access to /dev/video0 <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1600719>
<wxl> didrocks: the "store" refers to where exactly?
<mup> Bug #1603018 changed: snap create-user gets bad username <create-user> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1603018>
<didrocks> wxl: ubuntu snap store (which is the same than click store)
<didrocks> I thought there was a link to register, correct?
<mup> PR snapd#2375 opened: store: retry tweaks and logging <Created by stolowski> <https://github.com/snapcore/snapd/pull/2375>
<wxl> not that i saw
<wxl> is that apps.ubuntu.com?
<wxl> or maybe myapps.developer.ubuntu.com?
<didrocks> yeah, the latter
<wxl> sorry for all the noob questions but i'm not really finding any great docs anywhere and the answers aren't immediately obvious
<mup> Bug #1603610 changed: Snaps have no screenshots <verification-done> <snapd-glib:Fix Released by robert-ancell> <Snappy:Fix Released by robert-ancell> <gnome-software (Ubuntu):Fix Released by robert-ancell> <gnome-software (Ubuntu Xenial):Fix Committed by robert-ancell> <gnome-software (Ubuntu
<mup> Yakkety):Fix Released by robert-ancell> <https://launchpad.net/bugs/1603610>
<wxl> so does it create a login based on that account? if so, given i got in via SSO, what's my password?
<didrocks> wxl: yeah, there is few starting guide
<didrocks> create an account for myapps
<mvo> jdstrand is bug #1603879 something straightforward ? or very tricky?
<mup> Bug #1603879: Requesting additions to optical-drive interface for cdparanoia. <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1603879>
<seb128> wooot, it looks like the snappy team is triaging their bugs ;-)
<mvo> seb128: *cough*
<seb128> :-)
<mvo> seb128: did I ever mention how much I hate bug triage?
<seb128> haha
<seb128> you might :p
<mup> Bug #1604016 changed: Snap requires sudo if not logged in <Snappy:Fix Released> <https://launchpad.net/bugs/1604016>
<seb128> but yeah, it's borring but useful!
<zyga> slangasek, ogra_: will you be able to make the call/hangout on gagets later today?
<seb128> speaking of bugs, where does one report issues about the snapcraft.io documentation bugs?
<wxl> didrocks: ok got the account. it accepted my email. now i'm confronted with a request for credentials and have no clue what they are.
<didrocks> well, it's just your email address, correct?
<didrocks> the "store account"
<wxl> yep, but there's no password given SSO
<didrocks> you don't know password
<wxl> unless i'm meant to use my launchpad password
<didrocks> on the ubuntu core image vm
<didrocks> just the email address is asked
<didrocks> s/know/need any/
<mup> Bug #1604880 changed: Missing inhibit interface <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1604880>
<mup> Bug #1604885 changed: Access to mounted USB drives <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1604885>
<wxl> i already gave it that, which is accepted
<wxl> so now i'm beyond that
<didrocks> ah, I see what you mean
<didrocks> did you read the last line?
<wxl> now i'm presented with a localhost login
<slangasek> zyga: yes, though I'm surprised this needs a hangout.  I had talked with sergiusens at the last sprint about the fact that we needed pointers to sources from binary snaps, and that it should preferably be done officially in snapcraft - since we don't have any way to add arbitrary things to meta if we're using snapcraft
<didrocks> you can ssh to your vm now
<didrocks> better to ssh
<wxl> oic
<didrocks> your ssh key was copied over to it
<mvo> seb128: yeah
<mvo> seb128: snapcraft.io bugs, not sure, dholbach probably knows
<zyga> slangasek: this is an informal call driven mainly by me; I want gadgets to be easier to find and (eventually) serve as a reference
<didrocks> seb128: https://github.com/ubuntudesign/snapcraft.io/issues/new
<didrocks> see bottom of the page :)
<mvo> thanks didrocks
<zyga> slangasek: since I don't own then I cannot decide by myself and I want to share my (simple) plan/idea with you to get feedback and see if you like the idea
<zyga> slangasek: right now it's hard to find where each gadget comes from and harder to report bugs against them
<seb128> didrocks, right, I was unsure if the content for the plugins section is coming from the site or autogenerated from the code
<zyga> slangasek: I talked to ogra about this in the morning and he suggested that I add you and adam to the mix
<didrocks> seb128: long long discussionâ¦
<didrocks> seb128: in summary, file them there, and normally davidcalle retargets, fixes
<slangasek> zyga: ok. do you have a proposed layout under github for them?  How will I have commit access to them once moved there?
<seb128> didrocks, lol, let's not reboot it then, thanks for the url
<mup> Bug #1604964 changed: huge download for nothing - snap does not exist <Snappy:Fix Released> <https://launchpad.net/bugs/1604964>
<mup> Bug #1605216 changed: cups-control interface doesn't allow printing <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1605216>
<seb128> thanks
<zyga> slangasek: my layout idea is super simple, either move them as-is (perhaps not ideal, see below) and start making them nicer (commit rights are super easy to manage)
<ogra_> slangasek, the question was also about the uboot sources (deb sources shared with classic images) etc ...
<zyga> slangasek: or split them so that later on launchpad can import separate repos and do github->launchpad->(Snapcraft)->store pipeline
<zyga> slangasek: but even the split can be step two
<zyga> slangasek: correspodning to this I'd like to have a place to file bug against each specific reference gadget (all 4 of them)
<gerry_> hi snappy debug has this output "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" when I try to start my program with sudo any help gratefully received
<davidcalle> seb128: didrocks: "fixes"? that's debatable :p
<ogra_> slangasek, my assumption is that the github "tree" is in the end just a snapcraft.yaml and that we can have the gadgets auto-built if someone bumps a version in the tree
<zyga> slangasek: and lastly, not sure what to do with bbb, it's not the same support status but we should find some way to have it live (as a community gadget) somewhere and perhaps share the benefits
<ogra_> at least that was the plan with lsunchpad
<ogra_> i think github is a little further from that automation plan atm
<davidcalle> seb128: this location is fine, lp:snappy with snap-docs tag works as well if you prefer your bug mail on lp
<ogra_> zyga, i'm the maintainer of BBB ... i'lll keep it in LP if you dont mind
<zyga> slangasek: perhaps we can do a project for gadgets/kernels that are not officially supported
<ogra_> (BBB is community supported ... )
<slangasek> zyga: as it's not supported by us, but by ogra, you should ask ogra what works for that :)
<ogra_> zyga, kernels are a totally different story
<zyga> ogra_: no, I don't mind but if you can use bbb as a way to show how to build an ecosystem (if we agree on how that would look like)
<zyga> slangasek: my main goal is to make the gadgets easier to find, easier to fork and more of a reference
<zyga> slangasek: all I want to do is take a first step
<ogra_> i wont go my own path here but i prefer to have things easier maintainable ... gihub is a pain i'd like to avoid for my own projects
<zyga> slangasek: and move them out of the rather hard-to-find project on launchpad branch
<ogra_> (until LP stops to support bzr completely :) )
<seb128> davidcalle, ok, thanks
<zyga> ogra_: that's okay, let's not complicate this over with bbb, focus just on the reference platforms
<seb128> davidcalle, in any case the bug as been fixed it seems, so for next time
<davidcalle> seb128: best kind of bugs
<seb128> davidcalle, the "examples" at the bottom of the plugins descriptions was giving a github page stating that queries needs a project or user specified
<seb128> but seems to work now
<zyga> slangasek: apart from what we have there in the lp branches now I'd like to add a readme to each repository so that it explains what the content is, how it can be built and how it ends up in the store
<zyga> slangasek: as well as a link to launchpad for bug tracking
<ogra_> zyga, regarding kernels, the stuff is already moving to kernel.ubuntu.com (sadly) and will be 100% in the kernel team hands ... apart from the builds for the edge chaynnel where we need group mgmt from LP
<zyga> slangasek: and anything else we can come up that's useful over time
<zyga> ogra_: interesting
<ogra_> the kernel team will take ovber everything
<zyga> ogra_: I think that's fine, my focus is on gadgets today :) for kernels there will be another day (maybe) to look at how people can do their own kenrel easily with snapcraft / store
<ogra_> (but we need edge in a state that everyone can make changes to the non-kernel components in the kernel snap)
<ogra_> zyga, well, such people should use the snapcraft plugin ... but that will make you end up with something completely different indeed
<zyga> ogra_: step by step, let's work on gadgets first, set up git trees, lp mirrors etc
<zyga> ogra_: sergiusens made a pull request that snapcraftifies one of the gadgets
<zyga> ogra_: that's a great first step and IMHO the way to go with all of them
<ogra_> zyga, yes, i have sergiusens commit open here because i planned to look into it before EOY
<wxl> is there a juju snap? i'm not immediately finding one and i'm surprised
<zyga> ogra_: +1 thank you
<zyga> slangasek: so that's the rough idea, the call is there just so that we can all share concerns and plans and align
<mup> PR snapd#2376 opened: docs: document SNAP_DEBUG_HTTP in HACKING.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/2376>
<wxl> correction: i find https://uappexplorer.com/app/juju-nskaggs.nskaggs but i cannot for whatever reason find it with snap
<ogra_> wxl, probably not in the stable channel or perhaps it uses devmode
<wxl> ogra_: oh, you know what. it's amd64 only.
<ogra_> :)
<seb128> sergiusens, hey, what do you mean by "allowing" in  "we agreed on allowing /snap/<snap_name>/current"?  That's its a stable interface garanty that it's not going to change/go away and that any snap can rely on the dir to be there for ever?
<wxl> awww fooey
<mup> PR snapd#2377 opened: snap: provide friendlier `snap find` message when no snaps are found <Created by mvo5> <https://github.com/snapcore/snapd/pull/2377>
<jdstrand> zyga: hey, tyhicks was wondering if the meeting re snap-confine and snapd merging just to convince the security team it is ok, or is it something else?
<jdstrand> s/just/was just/
<tyhicks> hey zyga :)
<jdstrand> well, I was wondering too after he mentioned it :)
<zyga> jdstrand: I want do convince you that it is better to merge it into snapd
<zyga> tyhicks: hey, how are you :)
<tyhicks> doing well :)
<zyga> tyhicks: I discovered that a gamy my son likes has a special easter egg for thanksgiving :)
<zyga> tyhicks: (too bad we cannot do those in snap-confine) ;)
<tyhicks> hehe
<jdstrand> zyga: well, if that is all the meeting is about, we can probably cancel it-- tyhicks and I don't have strong objections
<zyga> jdstrand: ah, in that case +1
<mup> Bug # changed: 1606813, 1606815, 1606893, 1606932, 1606961
<zyga> jdstrand: do you want to have the security label that requires a security +1 on pull requests?
<tyhicks> zyga: I don't know that we need a meeting for that. We understand the positives and only have a preference for keeping it a seperate project (no hard blockers against it)
<zyga> jdstrand: or some other way to track this?
 * zyga nod
 * zyga nods
<tyhicks> zyga, jdstrand: I'll leave a +0 comment in the bug
<zyga> thank you
<jdstrand> zyga: we probably need a way to track things better that need security team awareness/review, yes
<tyhicks> we will need that
<tyhicks> zyga's idea for labels is probably the best that we'll get
<jdstrand> zyga: it was easy before to see the changes to snap-confine
<jdstrand> is there a way to auto-label?
<jdstrand> like, if it is in this dir, then it gets a label?
<mup> Bug # changed: 1607121, 1607129, 1607344, 1607604
<tyhicks> oh, that's a nice idea
<zyga> jdstrand: not that I know of, it will require some though on our end
<zyga> jdstrand: maybe with a bot later (it can do this in pull requests)
<zyga> thought*
<jdstrand> zyga: having it separate in github meant that there was a mental separation that snap-confine was special and needed special attention. I'm not sure how to achieve that once it is merged
<jdstrand> sometimes the smallest changes can result in disaster in a setuid executable
<mup> Bug #1608608 changed: Snapweb avahi service is still called webdm.local <Snappy:Fix Released> <https://launchpad.net/bugs/1608608>
<mup> Bug #1608807 changed: create-user fails on classic <create-user> <Snappy:Fix Released> <https://launchpad.net/bugs/1608807>
<mup> Bug #1586248 opened: 96boards-kernel need change name <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1586248>
<tyhicks> I don't see a way to automatically tag PRs like that
<tyhicks> a bot is likely needed
<mup> Bug #1609930 changed: Support license acceptance <Snappy:New> <https://launchpad.net/bugs/1609930>
<sergiusens> seb128 it will be a stable interface yes; if it changes we burn zyga's place down
<seb128> sergiusens, good! :-)
<sergiusens> :-)
<mup> Bug #1611063 changed: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1611063>
<zyga> jdstrand: note that many things in snapd are already special (all interface reviews)
<mup> Bug #1611384 changed: Change detection not working, have to "snapcraft clean" between builds when modifying snap contents <Snapcraft:New> <https://launchpad.net/bugs/1611384>
<mup> Bug #1616006 changed: clean remove of snapd <Snappy:Fix Released> <https://launchpad.net/bugs/1616006>
<zyga> jdstrand: how do you manage those currently?
<zyga> sergiusens, seb128: AFAIK we're not changing the current symlink in 16 series (it will stay as-is)
<seb128> zyga, I'm glad to read that!
<zyga> timothy: hey, you reported bug 1604346 a while ago
<mup> Bug #1604346: snapd apparmor tests fail on ArchLinux <Snappy:Incomplete by zyga> <https://launchpad.net/bugs/1604346>
<zyga> timothy: can you check if that still happens with latest snapd?
<timothy> zyga: I had to reboot  with apparmor kernel
<attente> sergiusens: is there a way to make an exception for a snapcraft integration test to allow network access?
<zyga> timothy: no rush, if you can please add this to the bug report
<zyga> timothy: how is arch btw?
<seb128> where can one find detailed descriptions of interfaces?
<seb128> http://snapcraft.io/docs/reference/interfaces is a good list
<zyga> timothy: I didn't do much cross distro work lately and when I did I was stuck on fedora and selinux
<seb128> but it has no details/example of how to use those
<zyga> seb128: only in the code for now, I've added one page to the wiki to describe the content interface, I want to do this for all interfaces: https://github.com/snapcore/snapd/wiki/Content-Interface
<zyga> seb128: (I actually didn't link it from the main list of interfaces yet)
<zyga> seb128: it's a wiki though so editors welcome, if you have a specific interface we could work on documenting it
<zyga> tyhicks, jdstrand: could you guys have a look at https://github.com/snapcore/snap-confine/pull/188
<mup> PR snap-confine#188: Add apparmor support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/188>
<seb128> zyga, wooot, the content interface was the one I was after so thanks for that ;-)
<zyga> seb128: :D my pleasure, feedback welcome, this is my first edit on the wiki
<seb128> k, will do
<wxl> how does one add a new group on snappy?
<zyga> wxl: you mean system group?
<zyga> wxl: that's not supported yet
<wxl> fooey
<wxl> i found an lxd beta snap but it doesn't seem to add the lxd group
<zyga> wxl: but we have some plans to do that, many daemons would like that
<zyga> mvo: ^ did we add lxd hack to snapd?
<ogra_> hack ? i thought the hacks were gone
<ogra_> :P
<ogra_> iirc you need to manually call addgroup if you use the snap on a core image
<timothy> zyga: I see Fedora uses /var/ directory instead of /snap, did you create a migrate procedure?
<ogra_> (with the --extrausers option)
<zyga> timothy: no, we decided not to,
<zyga> timothy: we didn't publish any packages that use that yet either because of confinement issues
 * zyga jumps into a call
<jdstrand> zyga: usually someone manually pings me are adds @jdstrand. this is not great and I'd want to tie changes to interfaces/ (for example) to be tagged in some way
<wxl> ogra_: --extrausers is a snap option?
<ogra_> wxl, nope ... passwd/adduser etc
<jdstrand> zyga: ie, do for interfaces what we do for snap-confine
<wxl> oh right, so you're talking about building the snap then
<ogra_> nope about the core image
<wxl> oh
<wxl> even worse XD
<seb128> zyga, it's a bit confusing in the examples to have the same word used for slots/plugs names and as an attribute
<zyga> slangasek: hey, do you have the time to attend the gadget call now?
<zyga> seb128: aha, thanks, I'll see if I can change that or make it more obviou
<wxl> ogra_: i was sure hoping that coreâsnap juju/lxdâjuju deploy mysql/wordpress would do the trick, but i guess i'm still a bit ahead of my time
<seb128> zyga, yw :-)
<seb128> zyga, hum, also is it required to have a "interface: content"? your example doesn't have it
<mup> Bug #1639952 opened: When running in unity8 desktop snap, snap application icons aren't found in app scope <Canonical System Image:New> <Snapcraft:Confirmed> <Snappy:New> <ubuntu-app-launch (Ubuntu):New> <https://launchpad.net/bugs/1639952>
<sergiusens> attente integration tests do have network access, unit tests do not (those are also run on package build which is networkless)
<zyga> slangasek: can you point me to the official branch?
<zyga> slangasek: there were some more commits on the vorlon one AFAIK
<zyga> seb128: interface: content?
 * zyga looks
<tyhicks> zyga (cc jdstrand): I'm in the middle of reviewing snap-confine PR 188
<zyga> tyhicks: thanks!
<seb128> zyga, well other examples I found have an "interface: content" line, I guess it needs to know what interface to use?
<mup> Bug # changed: 1617250, 1617251, 1617264, 1617278
<zyga> seb128: is "interface" there an attribute?
<zyga> seb128: of a plug or a slot?
<zyga> seb128: that attribute doesn't mean anything, we only look at "content"
 * zyga triple checks
<seb128> zyga, I don't know, that thing is undocumented, I'm basing my comment on the read of http://askubuntu.com/questions/841004/cannot-get-basic-content-interface-example-working-with-snapcraft
<zyga> ah
<zyga> seb128: "interface: content" is required when the interface itself is not named "content"
<seb128> oh
<zyga> seb128: the plug / slot name can be anything
<seb128> k
<mup> Bug #1617770 changed: Snap cannot exec tput <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1617770>
<zyga> seb128: but we create an implicit "interface: $PLUG_OR_SLOT_NAME"
<seb128> some more magic ;-)
<zyga> seb128: so when things all match is shorter and more magic
<seb128> good to know
<seb128> thanks zyga
<zyga> seb128: I'll document that, thanks for pointing that out!
<zyga> ogra_, slangasek: can you confirm that
<zyga> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<zyga> is the place that has all the commits
<ogra_> yep
<zyga> thanks!
<mup> PR snapd#2356 closed: cmd/snap: have some completers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2356>
<seb128> zyga, thanks!
<mup> Bug #1619455 changed: classic does not work with connsole-conf created user <Snappy:Fix Released by ogra> <https://launchpad.net/bugs/1619455>
<zyga> ogra_: the latest commit there is
<zyga> timestamp: Fri 2016-10-28 13:06:29 +0200
<zyga> ah, 2016, I read that like 2015
<zyga> sorry :)
<ogra_> heh
<ogra_> no, i bumped the dragonboard last ... right before release
<ogra_> adding a second console= kernel option like on all other arches
<mup> Bug #1617232 changed: subiquity goes into endless configuration loop, no way to get out <Snappy:Invalid> <subiquity (Ubuntu):Invalid by mwhudson> <https://launchpad.net/bugs/1617232>
<jamespage> jdstrand, zyga: are you ok with me proposing pull requests with stacked commits? or do you want me todo them as standalone commits?
<jamespage> happy todo either
<zyga> jamespage: to snap-confine?
<jamespage> to snapd
<zyga> jamespage: in snapd we don't do squashing, so more commits is fine
<zyga> ogra_: this is the first one
<zyga> slangasek: ^^
<zyga> https://github.com/snapcore/pi2
<ogra_> looks good
<zyga> ogra_: no tags?
<mup> PR snapd#2378 opened: Openvswitch interface <Created by javacruft> <https://github.com/snapcore/snapd/pull/2378>
<ogra_> nope
<zyga> ah, no tags in bzr either, ok
<ogra_> dunno if we want to start to have two branches (one for edge, one that migrates through beta->canididate->stable, for the second one i'd use tags
<zyga> slangasek: master == edge
<zyga> er
<zyga> ogra_: ^^
<zyga> ogra_: I think the rest is up to you
<ogra_> yeah, thats what we did in the past
<zyga> ogra_: you can also work with QA on this
<ogra_> i just dont know if we want to kkeep that setup
<ogra_> i'd actually like to have a "go wild" branch for edge
<ogra_> where you can try out the evil stuff without harming the branch that gos later into stable
<ogra_> *goes
<zyga> ogra_: I think those are pull requests
<zyga> ogra_: if we set this right, pull requests can even go to named channels
<mup> PR snapcraft#933 opened: _filedir takes an extension, not a glob <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/933>
<ogra_> you mean a PR would land in edge so you can trigger an img build from it ?
<mup> PR snapd#2376 closed: docs: document SNAP_DEBUG_HTTP in HACKING.md <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2376>
<kyrofa> ogra_, no, a PR would land in its own custom channel
<kyrofa> "here, try this bugfix"
<ogra_> kyrofa, right ... not what i want
<ogra_> kyrofa, i want to land a fix and have it show up in tomorrows daily img without me doing anything
<ogra_> (or land "the test of a fix" ... this is edge ... that is what it is for)
<zyga> ogra_: that's edge
<ogra_> right
<zyga> ogra_: but even before you land someone's PR you can use a branch channel
<zyga> ogra_: and try that out
<ogra_> why would i ?
<ogra_> sounds like we'd have a lot fragementation then
<zyga> ogra_: you see a pull request, you do code review, you check that on a real device with a channel switch
<kyrofa> ogra_, right, reading more backlog your use-case isn't the custom channels thing. You just want a branch essentially assigned to edge
<kyrofa> That doesn't necessarily get merged into anything more stable
<ogra_> zyga, how does a channel switch help me with some initial boot stuff (i.e. gadget)
<zyga> ogra_: you switch and reboot
<ogra_> i need an imag to dd
<zyga> ogra_: no
<zyga> ogra_: you switch and reboot :)
<zyga> ogra_: maybe with a helper to wipe first-boot logic
<ogra_> gadgets very very rarely have anything that helps via a channel switch
<zyga> ogra_: if that doesn't do enough it's a bug in snapd, eventually that should be enough
<ogra_> usually fixes are in the firstboot area etc
<ogra_> anyway ... whatever works ...
<zyga> jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/195/files
<mup> PR snap-confine#195: Fix creation of $XDG_RUNTIME_DIR and $SNAP_USER_DATA <Created by zyga> <https://github.com/snapcore/snap-confine/pull/195>
<zyga> I'm still going to add more unit tests and spread tests for this
<zyga> for $SNAP_USER_DATA
<zyga> and for chown logic (unit tests)
<zyga> and for the hint callback
<zyga> but have a look please for the overall aproach
<zyga> approach*
<zyga> slangasek: I did all the repos, look at github please
<zyga> slangasek: I'll do all the launchpad repos next (I did pi2 as launchpad.net/snap-pi2)
<zyga> slangasek: and I'll work on snapcraft.yaml's
<zyga> slangasek: and publication to edge
<zyga> but now, some time for my son, ttyl
<mterry> jdstrand: were you the person that pmcgowan talked to about policykit in the unity8-session snap?  I wanted to discuss that a bit
<mterry> Specifically the suggestion to just bundle polkitd.  One problem with that is that we'd need to patch policykit to get rid of the setuid requirement for the libpolkit agent helper.  Which you security folks might not be thrilled with
<jdstrand> mterry: I'm working on a response to that bug. it is quite a complicated prospect overall
<mterry> jdstrand: ok cool we can talk in the bug
<jdstrand> mterry: as for the setuid bit, why is it setuid?
<mterry> jdstrand: I don't know?  /usr/lib/policykit-1/polkit-agent-helper-1 is setuid and last time I looked, I think it verifies that setuid is set?  Maybe I'm wrong that it verifies, and we could try faking it...
<jdstrand> mterry: also, it is possible to ship a snap with a setuid binary. it will fail review, but there is a way to override that
<mterry> jdstrand: not my favorite path but sure  :)
<jdstrand> mterry: from the security team notes: http://paste.ubuntu.com/23554639/
<jdstrand> seems it is only needed for password prompts. since iirc Touch didn't have any of those, you could probably skip it. But you'd need to be sure to undo this once you added password prompts
<mterry> jdstrand: well we only don't have password prompts in Touch because we added a lot of polkit policy files that said "don't ask for a password if the phablet user makes this call"
<mterry> I'm not sure we want to go down that route again
<jdstrand> mterry: that's a fair observation. I commented in the bug
<jdstrand> mterry: you might refresh-- I made two more comments
<mterry> jdstrand: guh I don't like supporting both classic and all-snap in one  :(
<jdstrand> I would imagine you wouldn't
<mterry> :)
<jdstrand> :)
<mterry> jdstrand: it might be a better use of eng resources on my side to not implement any of the workarounds until a bit more guidance comes from you snappy folks -- u8 isn't broken without this, we just can't install more snaps through the ui.  But I'll leave that to product folks to decide
<mterry> let me put that in the bug
<jdstrand> mterry: note, I'm not tasked with this. like you, would need product folks to bubble that up. it probably isn't on the snappy team's radar either, so that stakeholder meeting would need to include Ja mieBennett, rat liff and whoever from your side and product
<mterry> jdstrand: got it.  Thanks for the comments!
<jdstrand> np!
<mup> Bug #1645841 opened: Separate Signature Keys topic from Image Building flow <Snappy:New> <https://launchpad.net/bugs/1645841>
<jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/2366#discussion_r90101320
<mup> PR snapd#2366: interfaces: apparmor support for classic confinement <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2366>
<mup> Bug #1559248 changed: Support unversioned data directory (i.e. data shared between versions) <Snappy Launcher:Invalid by kyrofa> <Snappy:Fix Released by kyrofa> <https://launchpad.net/bugs/1559248>
<mup> PR snapcraft#934 opened: Migrate from xdelta to xdelta3 <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/934>
<zyga> jdstrand: thanks, checking
<mup> PR snapcraft#935 opened: Utilize MakePlugin build logic within CMakePlugin. (LP: #1645853) <Created by larryprice> <https://github.com/snapcore/snapcraft/pull/935>
#snappy 2016-11-30
<robert_ancell> Is there a method for system services to own (system) D-Bus names or is this the same problem as for sessions? i.e. bug 1590679
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<mup> PR snapcraft#927 closed: Add a test script to build external snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/927>
<mup> Bug #1645961 opened: Snapd generates a wrong udev rule for i2c devices <Snappy:New> <https://launchpad.net/bugs/1645961>
<mup> Bug #1627175 changed: RPi3 with only HDMI attached never shows subiquity <Snappy:Fix Released by ogra> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1627175>
<mup> Bug #1626121 changed: strict mode snaps crash with Segmentation fault on 16.10 <Snappy Launcher:Invalid> <Snapcraft:New> <Snappy:Fix Released by jdstrand> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1626121>
<mup> Bug #1624676 changed: ERROR cannot remove snap file "kicad-dev-snap", will retry in 3 mins: umount: /snap/kicad-dev-snap/x6: mountpoint not found <Snappy:Fix Released> <https://launchpad.net/bugs/1624676>
<mup> Bug #1623897 changed: console-conf should show if wired interfaces are connected <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1623897>
<mup> Bug #1624329 changed: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1624329>
<mup> Bug #1628193 changed: please set TMPDIR=/tmp when launching snaps <Snappy:Fix Released> <snap-confine (Ubuntu):Fix Released> <https://launchpad.net/bugs/1628193>
<mup> Bug #1628289 changed: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Fix Released> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<mup> Bug #1628357 changed: A deamon fails with: No home directory found <Snappy:Fix Released> <https://launchpad.net/bugs/1628357>
<mup> Bug #1628559 changed: Can't install more than 1 package in one command <Snappy:Fix Released> <https://launchpad.net/bugs/1628559>
<mup> Bug #1628640 changed: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Triaged by facundo> <https://launchpad.net/bugs/1628640>
<foxmask> bonjello
<mup> Bug #1630036 changed: auto import of assertions fails for devices present at boot <Snappy:Fix Released> <https://launchpad.net/bugs/1630036>
<mup> Bug #1630520 changed: snap login error message incorrect <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1630520>
<mup> Bug #1630586 changed: Pi3 kernel crash and is unreliable <patch> <Snappy:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1630586>
<mup> Bug #1630652 changed: snap revert and refresh forwards and backwards causes breakage <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1630652>
<mup> Bug #1631159 changed: No way to simply list available snaps via snapd <Canonical System Image:New> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1631159>
<mup> Bug #1632305 changed: console-conf cannot be used twice <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1632305>
<dholbach> hey hey
<mup> Bug #1632336 changed: after first boot /var/lib/snapd/seed/snaps is empty <Snappy:Fix Released> <https://launchpad.net/bugs/1632336>
<mup> Bug #1632337 changed: dragonboard beta3 image reboots during snap create-user <Snappy:Fix Released> <https://launchpad.net/bugs/1632337>
<mup> Bug #1634089 changed: Cannot activate Chinese input method for Qt app <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1634089>
<seb128> hey dholbach!
<dholbach> salut seb128
<mup> Bug # changed: 1634730, 1634775, 1634822, 1634880
<seb128> that bot should tell what the bugs are, giving random numbers as changed is not that useful
<didrocks> bingo!
<didrocks> seb128: no no, it can be useful :)
<mup> PR snapd#2379 opened: snap: remove unused experimental command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2379>
<mup> Bug #1634909 changed: Disabling pc||pc-kernel||core should give a warning message <Snappy:Fix Released> <https://launchpad.net/bugs/1634909>
<mup> PR snapd#2380 opened: debian: add missing ca-certificates dependency <Created by mvo5> <https://github.com/snapcore/snapd/pull/2380>
<abeato> woodrowshen, hi, I  saw you created an alsa-utils package, where could I find the sources?
<woodrowshen> abeato: oh, https://github.com/woodrow-shen/snapcraft-alsa-utils/blob/master/snapcraft.yaml
<abeato> woodrowshen, awesome, thanks
<woodrowshen> abeato: i didn't use interface yet
<abeato> woodrowshen, so this for installing with --devmode?
<woodrowshen> abeato: yes
<abeato> oh, I see
<longsleep> So anyone can point me to someone who might be able to help me fix the "Key registration failed: The account-key-request assertion is not valid." - i am not able to register-key any key with snapcraft and my account :/
<stub> Are snappy updates being backported to Trusty? I'm interested in some 2.18 fixes in Trusty and Xenial.
<mup> PR snapd#2381 opened: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL <Created by mvo5> <https://github.com/snapcore/snapd/pull/2381>
<mup> Bug # changed: 1636023, 1636383, 1636419, 1636421
<mup> Bug #1636764 changed: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid <Snappy:Won't Fix> <https://launchpad.net/bugs/1636764>
<mup> Bug #1636864 changed: ubuntu-image 0.10+real1 requires sudo <Snappy:Fix Released> <https://launchpad.net/bugs/1636864>
<mup> Bug #1636894 changed: [raspberry pi3]pi3 snap is removable  <Snappy:Fix Released> <https://launchpad.net/bugs/1636894>
<mup> Bug #1637981 changed: failed snap refresh removes security profiles <Snappy:Fix Released> <https://launchpad.net/bugs/1637981>
<mup> Bug #1638656 changed: snapd testsuite fails when run inside an lxd container <Snappy:Fix Released> <https://launchpad.net/bugs/1638656>
<mup> Bug #1638798 changed: mir server process goes defunct when a mir client attaches under confinement <Snappy:Fix Released> <https://launchpad.net/bugs/1638798>
<mup> Bug #1639234 changed: docs/rest has not url for install (refresh, revert, remove) example <Snappy:Fix Released> <https://launchpad.net/bugs/1639234>
<mup> Bug #1639614 changed: Sandbox denials with snap using thumbnailer <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1639614>
<kalikiana_> stub: I expect trusty will get backports, considering new interfaces that's pretty much required anyway to run all (new) snaps in the long term
<kalikiana_> I'm not sure, though, if that's documented somewhere
<kalikiana_> Or in what cadence
<mup> PR snapd#2382 opened: snap: Improve `snap --help` output as designed by Mark <Created by mvo5> <https://github.com/snapcore/snapd/pull/2382>
<abeato> woodrowshen, how did you test the alsa snap? I'm trying with a kvm machine using "-soundhw hda", and I get these errors when using aplay: http://paste.ubuntu.com/23557271/
<mup> PR snapd#2383 opened: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <https://github.com/snapcore/snapd/pull/2383>
<mup> PR snapd#2215 closed: tests: spread system user autoimport <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2215>
<woodrowshen> abeato: oh, yes, it seems to have /usr/share/alsa/alsa.conf
<woodrowshen> abeato: from libasound2-data
<woodrowshen> abeato: for early stage, i hacked os snap to workaround it ...
<abeato> woodrowshen, you copied the alsa.conf file around, isn't it?
<woodrowshen> abeato: right
<abeato> noted, thanks
<mup> PR snapd#2384 opened: snap: add snap size, description and provided apps to `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2384>
<woodrowshen> abeato: np
<sil2100> Hey! When running snap prepare-image (through ubuntu-image) I get a sha3-384 mismatch when downloading core
<sil2100> Yesterday it worked fine, although then I was getting a similar mismatch when downloading pc-kernel IIRC
<sil2100> Is this a known problem?
<sil2100> error: sha3-384 mismatch downloading core: got 4ebcade07da9a4d1dfc822efdb300997fd17f5fdd3e91fd0036bb1479fba2ff586cd672b04933d396b2734c57f949c30 but expected 536b4e3795ae66f1962567ce6f129eb979d08054aed874c40772c39b30222dd535e8739769af0e81e794b2136e05adbe
<mup> PR snapd#2385 opened: daemon, strutil: move daemon.quotedNames to strutil.Quoted <Created by chipaca> <https://github.com/snapcore/snapd/pull/2385>
<sil2100> I'm using snapd 2.17.1
<zyga> sil2100: no, can you please report it!
<sil2100> On it!
<mvo> sil2100: anything in syslog that indicates that there was some retry or something?
<mup> PR snapd#2346 closed: Misc libvirt fixes <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapd/pull/2346>
<mup> PR snapd#2276 closed: Add openvswitch-support interface <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapd/pull/2276>
<sil2100> mvo: nothing, but actually after trying now hm, both core and pc-kernel went fine through
<ogra_> sil2100, do you use the canonical VPN ? (due to the recent router attacks mine died a few times since monday without notice)
<sil2100> I remember trying to run the same command at least 4 times yesterday and getting mismatches for pc-kernel
<sil2100> While now it just succeeded after a re-run
<sil2100> Strange
<sil2100> Anyway, seems like a false alarm, sorry for the noise
<ogra_> hmm, i'm getting a lot of 504 errors on launchpad
<ogra_> seems you are not alone
<ogra_> err, from the store, sorry ...
<mup> PR snapd#2386 opened: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <https://github.com/snapcore/snapd/pull/2386>
<zyga> ogra_: hey ogra, how are you
<zyga> ogra_: I did some of the things we talked about, please have a look at github.com/snapcore now
<zyga> ogra_: I've done the lauchpad project for pi2 so far (snap-pi2), I'll make the rest next
<ogra_> zyga, trying to find out why core failed to upload tonights builds :P
<zyga> ogra_: pi2 is set so that each commit that lands on master gets pushed to the store
<zyga> ogra_: I'll patch all the gadgets to have a skeleton snapcraft.yaml with dump plugin
<ogra_> zyga, hmm, i thought you would create a master project for that under snapcore
<ogra_> like snapcore/gadgets/$arch
<ogra_> alternatively probably putting "gadget-" in the branch name might make sense
<ogra_> they kind of vanish in the amount of stuff thats already there
<ogra_> (and i guess that will become more)
<ogra_> also, while we're moving we should probably also drop "generic-" from the x86 arches
<ogra_> in the store they are called pc or pc-i386
<zyga> ogra_: on github there are no projects, jsut repositories
<zyga> ogra_: in the store both pc gadgets are just called "pc"
<zyga> ogra_: once we build more from source we can unify them and drop one
<zyga> ogra_: but now we cannot since we need two snapcraft.yaml's that are different
<zyga> ogra_: in the end we'll get only four gadgets, pc, pi2, pi3 and dragonboard
<zyga> ogra_: but now the pc one has two repos because that's how we need to do it
<ogra_> zyga, i'm not talking about merging them but making them better discoverable in the amount of projects there
<ogra_> s/projects/branches/
<ogra_> and about dropping the "generic"
<ogra_> "<ogra_> alternatively probably putting "gadget-" in the branch name might make sense"
<ogra_> i find them hard to discover already and there are not many branches under snapcore yet ... in a year that will have doubled
<zyga> ogra_: I wanted to match the snap name, we can do that gadget- prefix later (once slangasek owns those, it's just a rename button)
<zyga> ogra_: note: those are repos, not branches
<ogra_> ok
<ogra_> "things"
<ogra_> :P
<zyga> ogra_: we don't want to add all the gadgets there, just the ones that we support
<ogra_> yes
<zyga> ogra_: and snap-confine will go away so we'll have less things there
<zyga> ogra_: note that you won't see branches, this is essential, you won't see 12s of forks and branches from other people
<ogra_> yes, i have used github before :)
<zyga> ogra_: sorry, I was just trying to explain how this might look like
<ogra_> yeah, no worries :)
<zyga> ogra_: ok, now for the publishing pipeline
<mup> PR snapd#2385 closed: daemon, strutil: move daemon.quotedNames to strutil.Quoted <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2385>
<zyga> tyhicks, jdstrand: could you please review https://github.com/snapcore/snap-confine/pull/189/files -- it is the next one in the apparmor support series, (I've merged it after improvements suggestef by tyler)
<mup> PR snap-confine#189: Use apparmor-support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/189>
<ogra_> mvo, danm !
<ogra_> *damn even
<mvo> ogra_: hu?
<ogra_> mvo, i'll have to revert your change to bug 1639878
<mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:Fix Committed by ogra> <https://launchpad.net/bugs/1639878>
<mvo> ogra_: why?
<ogra_> i'm in the middle if re-working pre-arch modules
<ogra_> *per
<ogra_> because our initrd gets to big
<ogra_> we really dont want the virt stuff on arm
<mvo> ogra_: I don't see this module on arm
<ogra_> on which arm do you look ?   :)
<ogra_> (the generic kernel has it)
<mvo> ogra_: pi2, the only one I have
<ogra_> right, there we dont build it
<ogra_> anyway, i'm already working on a fix and should have it ready later today
<ogra_> (there are a bunch of others like virtio that need to go)
<mvo> ogra_: *shurg* its 28kb (the hv_storsvc) and 96kb (the hv_vmbus). but yeah, go ahead if thats too big
<ogra_> its not about to big but about loading them forcefully ... check lsmod on your rpi
<ogra_> they eat ram
<mvo> ogra_: we are loading them forcefully? that sounds not ideal, why is that?
<ogra_> (we use MODULE=list in the initrd)
<ogra_> to keep the number small, thats the only way, all others load a lot of default stuff we dont need and thats megabytes
<mvo> ogra_: I get "no such device" when trying to load it here on my machine, so it seems like it will not get loading if not in a hv env?
<mvo> ogra_: I don't disagree to fix all that, don't get me wrong
<mvo> ogra_: this upload was a drive-by from bug triage and it was less work to fix it than to write the comment about the status etc. and AFAICT it does not harm you in any way, the rework will just superseed it, or am I missing something?
<ogra_> mvo, indeed
<ogra_> mvo, on another note ... how about we get rid of /etc/system-image and move writable-paths one level up for one of the next releases ?
<ogra_> we dont ship the package anymore and the path is an anachronism
<mup> PR snapd#2342 closed: client: use typed snap.ConfinementType <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2342>
<mvo> ogra_: that makes sense, yes, its slight ugly as it is right now
<ogra_> yup
<mup> PR snapd#2387 opened: asserts: introduce top-commands header in snap-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2387>
<ogra_> not really high prio but it makes me itch every time i have to touch it
<mvo> +1
<zyga> ogra_, mvo: https://github.com/snapcore/pi2/pull/1
<mup> PR pi2#1: Improve the README file <Created by zyga> <https://github.com/snapcore/pi2/pull/1>
<ogra_> zyga, perhaps we should have a "BUILDING" file for the old content
<ogra_> (which could also point to sources etc and have some more info on where the binaries come from(
<zyga> ogra_: for the mkvenvimage line?
<ogra_> yeah, it is highly important for oporters to know about it
<zyga> ogra_: can you propose that please? I'm sure you'd be more accurate than I am
<ogra_> *porters
<zyga> ogra_: let's land this branch and iterate
<ogra_> though ...
<zyga> ogra_: I'll make the snapcraft.yaml with dump plugin now
<ogra_> we could switch to the make plugin and simply automate it i guess
<zyga> ogra_: :D
<zyga> ogra_: I'll do the naive dump plugin
<zyga> ogra_: and let you improve, ok?
<ogra_> yeah, start with that
<zyga> ok!
<ogra_> :D
<mup> PR snapd#2373 closed: debian: remove unneeded conflict against the "snappy" package <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2373>
<gerry_> hi all, I am using the jdk plugin but I need the headers how do I do this?
<mup> PR snapd#2379 closed: snap: remove unused experimental command <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2379>
<zyga> ogra_, mvo, slangasek: https://github.com/snapcore/pi2/pull/2
<mup> PR pi2#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi2/pull/2>
<zyga> sergiusens: ^^
<zyga> sergiusens: I found a bug in snapcraft, I think, building that with snapcraft twice results in an odd error message about meta/gadget.yam
<ogra_> zyga, why didnt you keep the boot-assets" name
<zyga> ogra_: I did, it's a subdirectory there
<ogra_> oh, sorry
<zyga> ogra_: I didn't try booting with that
<zyga> ogra_: but the prime/ directory looks identical to the old tree, except for meta/gui/icon.png
<ogra_> well, as long as the bits land in boot-assets later all is fine
<sergiusens> zyga we deal with bugs through bug reports if you are so sure of it ;-)
<zyga> ogra_: can you review it please then
<zyga> sergiusens: let me file it quickly :)
<zyga> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1646081
<mup> Bug #1646081: Gadget snap cannot be built twice <Snapcraft:New> <https://launchpad.net/bugs/1646081>
<zyga> sergiusens: does that look sensible?
<zyga> sergiusens: I found this on the following pull request: https://github.com/snapcore/pi2/pull/2
<mup> PR pi2#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi2/pull/2>
<zyga> sergiusens: and btw, since you are here, where should the icon be? am I doing the right thing with setup/gui/icon.png?
<zyga> ogra_: I'm waiting for your comment there, if you +1 it we can land it :)
<zyga> ogra_: thanks! merged
<zyga> ogra_: so now about that makefile part
<zyga> ogra_: do you think we should also copy the licenses?
<ogra_> dont we do that ? yes, we should
<ogra_> like they are upstream
<sergiusens> zyga yes, but you can use the dedeprecated `icon` entry to get rid of `setup`
<zyga> ogra_: ok, let me fix that
<zyga> sergiusens: how can I read about filesets or organize help?
<zyga> sergiusens: how can I cope three license files from the root of the project, I tried the copy and dump plugins but my attempts didn't work
<zyga> ah
<zyga> sorry, there's a typo in the tree itself :)
<zyga> ogra_, sergiusens: https://github.com/snapcore/pi2/pull/3
<mup> PR pi2#3: Copy licenses to the snap <Created by zyga> <https://github.com/snapcore/pi2/pull/3>
<zyga> ogra_: shall I correct the LICENSE vs LICENCE typo?
<ogra_> zyga, well, thats also from upstream :)
<popey> is it possible to just point to a deb url in a snapcraft yaml?
<ogra_> however you feel like ;)
<popey> to pull in a pre-built deb and unpack it?
<zyga> ogra_: ok, I'll leave it as-is then
<ogra_> popey, https://github.com/ogra1/laidout is one way
<ogra_> (see the Makefile)
<popey> ta
<popey> oh
<popey> that's icky, can we not just source: foo.deb ?
<ogra_> well, it is old ... perhaps we can now :)
<popey> ok
<popey> :)
<ogra_> thats a sergiusens question
<mup> Bug #1646085 opened: snapd-interface access to /usr/bin/infocmp denied <Snappy:New> <https://launchpad.net/bugs/1646085>
<popey> what I really want is access to a 3rd party archive in a cleanbuild
<gerry_> hi when I run snappy-debug and run my app with sudo I get "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" can anybody tell me how to do this?
<zyga> ogra_: https://github.com/snapcore/pi2/pull/4
<mup> PR pi2#4: Add URL to launchpad build history <Created by zyga> <https://github.com/snapcore/pi2/pull/4>
<zyga> gerry_: it probably means that the appliaction tries to touch files that are not owned by root but the process dones't have CAP_DAC_OVERRIDE which typical root processes have
<zyga> gerry_: if you use sudo you'd have to make those files root owned (probaly something in ~/snap/$SNAP_NAME but I may be wrong)
<gerry_> zyga: thank you for your help the app works when I run it without sudo it crashes when I use sudo with an exception
<zyga> do you need to run it with sudo?
<zyga> ogra_: I just requested a manual build
<zyga> ogra_: if all goes well it will end up in edge :)
<zyga> ogra_: and if not we can work with mvo on store side permission
<gerry_> yes because when I upload it to the ubuntu store it does not get loaded into software
<zyga> gerry_: what do you mean by "it does not get loaded into software"
<ogra_> zyga, i could add you if i could reach the store ... seems it isnt liking me today ... getting 504s
<zyga> ogra_: yeah, the store has hicckups today
<zyga> hic-hic-hic-hic
<zyga> or more rather
<zyga> hic-hic-504-hic
<ogra_> heh, it seems to be one very looong hick .... and no "up" at all for me
<zyga> sergiusens: hey, can you suggest how we can use the dump plugin for this: ?
<zyga> sergiusens: https://github.com/snapcore/pi2/blob/master/snapcraft.yaml#L15
<gerry_> zyga : the gnome-software library I can see it when it is listed in the installed apps but does not get listed in the "wild"
<zyga> gerry_: ah, I think this is a separate bug
<zyga> gerry_: how does using sudo helps?
<gerry_> zyga: I was told it had to work with sudo to be accepted
<zyga> gerry_: who told you that?
<gerry_> somebody on here didrocks
<zyga> didrocks: can you tell me more about this please?
<zyga> ogra_, mvo: can you guys please add me to the pi2 gadget snap in the store, if you can?
<ogra_> if i could :P
<ogra_> i cant even get the front page of myapps.d.u.c
<ogra_> 504 Gateway Time-out
<ogra_> The server didn't respond in time.
<ogra_> ...
<ogra_> oh, a new message !
<ogra_> We're currently experiencing some difficulties
<ogra_> Sorry, it looks like we're experiencing a problem with this service. We'll be investigating shortly.
<ogra_> ... so that i dont get bored :P
<zyga> thanks for checking
<didrocks> hum? I didn't say to use sudo AFAIK
<didrocks> gerry_: not sure where this is coming from, are you mixing with the permissions issues you had? ^
<didrocks> zyga: ^
<didrocks> scrolling back -> gnome software
<didrocks> yeah, I did tell you that for now, you will only see snaps in gnome software if you use sudo AFAIK
<didrocks> sudo to start gnome software
<didrocks> nothing to do with your snaps
<didrocks> (there is a permission mismatch in snapd/gnome-software)
<zyga> gerry_: please don't worry about this, it will get fixed in gnome-software
<didrocks> yeah, but gerry_ wanted to see his snap right now, hence this solution
<zyga> gerry_: you should be able to just find the launcher of your app from dash/gnome-shell
<zyga> gerry_: and it should run when started from that location
<gerry_> zyga: yes I can run it locally but my ultimate aim was to have it included in gnome-software
<zyga> ogra_: https://github.com/snapcore/pi3/pull/1
<mup> PR pi3#1: Improve the README file <Created by zyga> <https://github.com/snapcore/pi3/pull/1>
<ogra_> oh, hello store !
<zyga> ogra_: https://github.com/snapcore/pi3/pull/2 :)
<mup> PR pi3#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi3/pull/2>
<ogra_> zyga, you should have three invite mails from the store...
<gerry_> zyga, didrocks: sorry I am a little confused now have I still to continue looking for an answer to my sudo problem?
<zyga> ogra_: thank you
<zyga> gerry_: no, unless you expect your users to use sudo on a daily basis
<zyga> ogra_: you should have invites to the repos
<ogra_> two for now, yeah
<gerry_> zyga: so now I just need to find out why it has not been included in gnome-software? thank you very much and sorry I am such a pain
<didrocks> gerry_: it does show up in snap find, correct?
<didrocks> your snap
<zyga> gerry_: does it show up in the dash when you search for it?
<zyga> gerry_: is the desktop file in /var/lib/snapd/desktop/applications/ what you'd expect?
<zyga> gerry_: if so, you are good
<zyga> ogra_: ok, got it, I'll triggere another build of pi2 so that it can get published
<zyga> ogra_: let's do dragon next, it doesn't have the PC problem
<gerry_> I am using gnome desktop where it shows up as a menu selection and it shows up in gnome-software as an installed app
<ogra_> oh, dragon ...
<ogra_> forgot that one ... invite sent
<gerry_> just when I search for it under "all" it is not there
<zyga> ogra_: https://github.com/snapcore/dragonboard/pull/1
<mup> PR dragonboard#1: Improve the README <Created by zyga> <https://github.com/snapcore/dragonboard/pull/1>
<zyga> ogra_: got the invite, thanks
<zyga> ogra_: so I see revision 30 in the store but it's not published automatically
<zyga> looks like a launchpad bug?
<zyga> https://myapps.developer.ubuntu.com/dev/click-apps/2436/rev/30/
<zyga> cjwatson: should a snap built according to this recipe auto-publish to edge? https://code.launchpad.net/%7Ezyga/+snap/pi2
<ogra_> zyga, yes
<ogra_> note that it takes a while for the last step in the store
<ogra_> (thats a cronned publisher i think)
<ogra_> and there it published ;)
<zyga> woooooot!
<zyga> great
<renato__> zyga, hey I am getting this error: http://paste.ubuntu.com/23554713/, while trying to test my new interface. What I am missing?
<zyga> ogra_: https://github.com/snapcore/dragonboard/pull/2
<mup> PR dragonboard#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/dragonboard/pull/2>
<zyga> renato__: looking
<zyga> renato__: you probably how to edit the base declaration assertion
<zyga> renato__: look at ...
<zyga> ah, sorry afk
<renato__> let me check
<renato__> zyga, http://paste.ubuntu.com/23557921/
<sergiusens> didrocks mind helping me with `snapcraft define preload`?
<gerry_> hi guys sorry I have another question had a look in ubuntu one and my app has the entry Tue 22 Nov. 2016 Approved. Automated review found no issue how long until it gets in gnome-software ?
<zyga> gerry_: it's automatic it if is published into the stable channel
<mup> PR snapd#2388 opened: make snap install/refresh/etc abort if the service does not stay active, unless --devmode is given <Created by chipaca> <https://github.com/snapcore/snapd/pull/2388>
<gerry_> zyga: thank you nothing yet just found the little "release" button though
<zyga> ogra_: pi3 build in progress, dragon is next but I'm waiting for the initial launchpad mirror
<ogra_> cool
<zzarr> hello! I'm trying to install snapd on a machine running 16.04.1, but get this error http://pastebin.com/QxCLfWE4 how do I solve it?
<zzarr> are there a problem with the repository?
<zzarr> I could install other packages
<zyga> zzarr: there's a conflict there, you need to remove the snap package
<zzarr> thanks zyga, I will do
<zzarr> it worked, once more, thanks zyga
<zzarr> if I install the nexctcloud snap, would that break my apache setup?
<zyga> ogra_: dragonboard build triggered
<ogra_> great
<zyga> ogra_: now for pc
<zyga> I wonder if I can cheat
<ogra_> yay
<zyga> merge both generic- repos into one
<zyga> and use snapcraft.yaml to build it
<zyga> so that there's one project that gives two working gadget snaps for both arches
<zyga> hmmm - perhaps that's the way
<ogra_> yeah
<zyga> ogra_: pi2, pi3 and dragonboard are now auto-published :)
<ogra_> yay
<zyga> sergiusens: question about gadget.yaml
<zyga> sergiusens: looking at amd64 and i386 gadget snaps I see differences in their gadget.yaml files
<zyga> sergiusens: do you think we can build both snaps from one tree somehow?
<zyga> sergiusens: or is this futile
<zyga> zyga@xenial-server:~/snappy-hub$ diff -u generic-amd64/meta/gadget.yaml generic-i386/meta/gadget.yaml  | pastebinit
<zyga> http://paste.ubuntu.com/23558061/
<zyga> ogra_, slangasek ^^
<ogra_> zyga, the diff looks right
<ogra_> i386 doesnt have secure boot
<ogra_> not sure how you would get that into a single snapcraft.yaml though
<zyga> yeah, that's what I'm thinking about
<ogra_> or rather gadget.yaml
<zyga> if there's no way we can just accept two repos/snapcraft.yamls for now
<gerry_> hi finally got my app uploaded to gnome-software thank for the zyga and didrocks
<gerry_> *help
<zyga> gerry_: that's great! glad to see your snap in the store
<gerry_> I have another problem now when I want to remove it via the gnome-software it keeps asking me for my ubuntu one  email and password ?
<zyga> gerry_: I think you have to login at least once to do that
<gerry_> zyga: oh ok thanks trying that now :)
<gerry_> zyga: I try to enter my email and password and it just says one of them is false even though I have checked it out in my browser and it logs in ok on that?
<mhall119> does /w 79
<gerry_> found a way started gnome-software as sudo
<gerry_> I have another question why in gnome-software is my app have non-free written on it?
<gerry_> *does
<kalikiana> gerry_: non-free means nobody vetted the source code - so for a snap that's by design the case, nobody can know how it was built, as opposed to packages from the Ubuntu archive
<kalikiana> I'll agree, though it looks ugly, it's just a technical stupidity
<gerry_> Kalikianna: thanks for you help just one more question it does not seem to use screenshots either?
<mup> Bug #1632390 changed: "snap find" return unrelative snap <Snappy:Opinion> <https://launchpad.net/bugs/1632390>
<kalikiana> gerry_: It doesn't seem to be implemented yet. Not sure if there's a bug yet
<mhall119> sergiusens: does snapcraft support ./setup/hooks/ yet? Or do you still have to put them into ./prime/meta/hook/ before the final snap step?
<mhall119> niemeyer: zyga: related to that, has the change to run the configure hook on install & upgrade landed in the snapd archive packages?
<didrocks> sergiusens: sorry, didn't see your ping, sure, what about it?
<zyga> mhall119: I think we're still waiting for some stuff to get the next SRU out, mvo knows details
<jdstrand> morphis, joc_ (cc niemeyer): hey, I was refamiliarizing myself with how serial-port, gpio, i2c and hidraw work in practice (due to responding to bug #1645445) and realized that https://github.com/snapcore/snapd/wiki/Interfaces was a bit lacking
<mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1645445>
<jdstrand> morphis, joc_ (cc niemeyer): so I fixed that: https://github.com/snapcore/snapd/wiki/Interfaces/_compare/0c2b18b9a98ce1a5e45d4392c05023a505072c2e...e514578237da8a4d00b38a0f6db6c1053448f764
<jdstrand> morphis, joc_ (cc niemeyer): please let me know if I should change something
<jdstrand> mvo: regarding 1645445, I responded. need feedback from the dev and then I can talk to Gustavo on how to advise on the next steps
<zyga> jdstrand: o/
<jdstrand> zyga: hey
<zyga> jdstrand: I created a Content-Interface wiki page
<zyga> jdstrand: I'd like to move all the interesting interfaces to sub-pages with details and link to them from the Interfaces page
<mvo> jdstrand: thank you
<zyga> jdstrand: thanks for your XDG_RUNTIME_DIR review, I will adjust the code as suggested
<zyga> jdstrand: I proposed https://github.com/snapcore/snap-confine/pull/189 as a follow-up to what tyler reviewed yesterday
<mup> PR snap-confine#189: Use apparmor-support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/189>
<jdstrand> zyga: re Interfaces page, sounds good to me
<jdstrand> zyga: re 189, yep saw that. re xdg, thanks!
<abeato> sergiusens, maybe you know, how can add a user to a group in ubuntu core? --extrausers seems to be not magical enough
<zyga> jdstrand: there was one interesting bug in i2c that was found recently
<zyga> jdstrand: we used = instead of == in the udev rule
<jdstrand> eek
<zyga> jdstrand: I didn't do a pass over all of those but it feels like it slipped through review and is not CId yet
<zyga> jdstrand: one interesting development today: look at github.com/snapcore
<zyga> jdstrand: look for pi2, pi3 and dragonboard :)
<zyga> jdstrand: I plan to hack on the wiki extensively tomorrow-ish
 * ogra_ wonders why the snapcraft@ suddenly is hit by so much spam stuff 
<ogra_> is that only me ?
<abeato> not only you, not
<zyga> ogra_: we've noticed, taking action
<ogra_> thx
<zyga> my inbox was beeping like a timer ;)
<jdstrand> zyga: oh, that is handy. cool :)
<zyga> jdstrand: PC is the last to go because of two arches sharing snap name but I'll get it supported if I can
<jdstrand> ogra_: you may have an answer for abeato ^
<zyga> jdstrand: also a place to report bugs (on the LP mirror projects)
 * ogra_ reads backlog
<jdstrand> interestingly, I *just* made a comment about group membership in bug #1645445
<mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1645445>
<abeato> ogra_, about adding a user to a group :)
<ogra_> abeato, hmm, addgroup with --extrausers doesnt work ?
<ogra_> err
<ogra_> adduser
<ogra_> adduser --extrausers ogra newgroup
<ogra_> something like that
<abeato> ogra_, http://paste.ubuntu.com/23558361/
<ogra_> (newgroup being the name of the group)
<ogra_> hmm, that should work
<ogra_> abeato, oh
<ogra_> you are trying to add the user to a group that lives in /etc/group
<ogra_> so that cant work
<abeato> ogra_, :(
<abeato> ogra_, should not that be possible? is this a bug?
<ogra_> we'd have to move that group to /var/lib/extrausers ... though the audio group is deprecated since half a decade now
<jdstrand> ogra_: dialout came up in 1645445
<abeato> ogra_, /dev/snd/ stuff has that group
<ogra_> jdstrand, well, we cant really make these system groups dnyamic ... that will break the filesystems badly
<mup> PR snapd#2364 closed: overlord: increase test timeout and improve failure message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2364>
<jdstrand> ogra_: we need a solution for device permissions and users. maybe it is simply that we have snap.dialout and snap.audio and snapd's udev rules does that instead
<ogra_> abeato, yes, but you should only access it through a sound daemon
<jdstrand> ogra_: I think groups are still useful on all snaps, but it needs design
<ogra_> jdstrand, that might work ... the prob is that the GIDs are immovable due to readonly/readwrite merges
<rvr> Spam on snapcraft mailing list :(
<jdstrand> ogra_: I was thinking snapd.dialout is an extrausers group. that suffers from the merge problem?
<ogra_> which is why the system groups are all sitting in /etc/group
<ogra_> jdstrand, the issue is the GID ... would an additional rgoup help at all ?
<ogra_> the device node would still be owned by audio ... and potential homedirs of a daemon too ...
<jdstrand> well, that is tricky. we don't want to change all dialout to snap.dialout cause that might break core
<ogra_> if you now change GIDs the filesystem ownership breaks
<jdstrand> yeah
<jdstrand> hrm
<ogra_> you would have to update the GID ownership on every boot ...
<zyga> ogra_: https://github.com/snapcore/generic-amd64/pull/1/files
<mup> PR generic-amd64#1: Add initial README.md file <Created by zyga> <https://github.com/snapcore/generic-amd64/pull/1>
<ogra_> walking the whole fs
<zyga> ogra_: I will do two github repos but one launchpad project with two git mirrors there
<zyga> ogra_: and they will both build to the "pc" snap
<ogra_> zyga, sounds good ... i'd still prefer pc and pc-i386 as names though :)
<zyga> ogra_: yeah, maybe once we implement generic rename support we can do that
<zyga> ogra_: do you want to rename the repos?
<zyga> ogra_: this is free now
<ogra_> generic is a 15.04 name we forcefully dropped everywhere (except in that branch because nobody cared)
<zyga> ok
<zyga> I'll do that
<zyga> pc-$ARCH
<niemeyer> jdstrand: Thanks for the wiki improvements
<ogra_> thanks:)
<abeato> ownership stuff can get tricky, what I am doing is playing with a confined aplayer, in the end I have to do: "sudo alsa-utils.aplay /root/enter.wav" when I have alsa and home interfaces connected... you have to do sudo *and have a file in /root/ folder* to play something
<jdstrand> ogra_: it seems extrausers and the system group issue is that what we have isn't smart enough. it seems like an artificial limitation of the implementation that an extrauser can't be added to a system group. perhaps snappy needs an updated nss module that can handle that
<abeato> addinng my user to the audio group would help a bit
<ogra_> jdstrand, well, i wont hold you back :P
<ogra_> abeato, device ownerships should be handled by udev ACLs nowadays
<ogra_> (since years actually)
<jdstrand> hrm
<zyga> ogra_: https://github.com/snapcore/pc-amd64 and https://github.com/snapcore/pc-i386
<jdstrand> it needs design
<jdstrand> but seems possible
<jdstrand> it also needs someone assigned to it
<ogra_> jdstrand, and you think we cant do it via ACLs like we do oon the desktop since ages ?
<abeato> ogra_, ok, I will try with an ACL, is that possible in ubuntu core?
<ogra_> iirc we dropped the audio group membership for default users in 10.04 or 12.04 in favour of ACLs
<zyga> ogra_: how does it work with ACLs?
<ogra_> abeato, perhaps not without changes to core ... but i think if possible we should use them
<zyga> ogra_: and wich users should get access? (if the ACLs relate to users, I don't know)
<ogra_> zyga, now i'd say thats a pitti question ... but i guess we need to start getting along alone ... (he implemented that IIRC)
<zyga> ogra_: is that documented anywhere?
<ogra_> zyga, logind manages the access
<zyga> ogra_: (and let's land https://github.com/snapcore/pc-amd64/pull/1/files unless you want to tweak wording)
<mup> PR pc-amd64#1: Add initial README.md file <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/1>
<ogra_> abeato, "getfacl /dev/snd/controlC0 | grep -Eo "user:.+:" | cut -d: -f2" ...
<ogra_> that should return your username if you have acl access to the sound device ... independent from the audio group
<zyga> ogra_: so for services (root) this is irrelevant but fro users that log in we could useit
<jdstrand> ogra_: maybe. I see only one setfacl in /lib/udev/rules.d
<ogra_> the above command clearly retuns ogra on all my desktop installs
<ogra_> so we should make sure this works on core as well
<zyga> ogra_: does logind manage ssh logins and console logins?
<ogra_> and at the same time:
<ogra_> ogra@styx:~$ groups|grep audio
<ogra_> ogra@styx:~$
<abeato> ogra_, same for me, it shows my user, but no getfacl in core, certainly
<ogra_> ok, file a bug ... lets first get the tools in and then see if we can make them work ;)
<abeato> ogra_, alright, in snappy I guess?
<ogra_> yeah
<jdstrand> ogra_: this seems like a plausible way to handle it. yes, abeato, please file a bug
<abeato> cool
<ogra_> if you can ... assign to me
<abeato> sure :)
<jdstrand> I'm curious about the mechanism used to setfacl
<ogra_> i think there is some buuiltin setfacl in udev somehow
<ogra_> but pitti only explained it once to me and that was several years ago
<ogra_> (i have forgotten most of it and need to dig into it again)
<mup> PR snapd#2388 closed: make snap install/refresh/etc abort if the service does not stay active, unless --devmode is given <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2388>
<ogra_> aha
<ogra_> jdstrand, https://wiki.ubuntu.com/Audio/TheAudioGroup
<ogra_> a little sparse but it at least explains the high level to endusers
<pitti> ogra_: right, /lib/udev/rules.d/70-uaccess.rules tags such devices as "uaccess" and 73-seat-late.rules calsl the "uaccess" builtin
<jdstrand> ogra_: it looks like it should be systemd these days instead of consolekit, but yeah
<ogra_> yeah, that was it ... uaccess
<mup> PR snapd#2382 closed: snap: Improve `snap --help` output as designed by Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2382>
<mup> PR snapd#2383 closed: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2383>
<ogra_> i guess fort thing is to seed acl on core :)
<ogra_> nice .... not really a dependency chain ... thats easy
<ogra_> s/fort/first/
<zyga> ogra_: https://github.com/snapcore/pc-amd64/pull/2
<mup> PR pc-amd64#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/2>
<zyga> ogra_: it feels like licenses are missing
<ogra_> zyga, what licenses ?
<zyga> ogra_: and it would bew nice to have some gardening of the wording in snapcraft.yaml
<jdstrand> ogra_: huh. with all the uaccess rules already there and systemd already in place, I'm curious if that is all you have to do...
<zyga> well, for those binaries we are shipping now :)
<ogra_> jdstrand, probably ... lets see :)
<ogra_> zyga, well, they are built from ubuntu archive source for these arches
<jdstrand> ogra_: that would literally be the best outcome imaginable :)
<ogra_> yeah :)
<ogra_> zyga, the licenses in the pi and dragonboard gadgets are only for the binary blobs we can not control and come as-is from upstream ...
<ogra_> we ship a copy of the GPL in core ... so thats all fine for the gadgets that come completely from source
<abeato> ogra_, https://bugs.launchpad.net/snappy/+bug/1646144 . I cannot assign, so feel free to auto-assign ;)
<mup> Bug #1646144: ACLs to devices need to be supported in core  <Snappy:New> <https://launchpad.net/bugs/1646144>
<ogra_> merci !
<abeato> np
<mup> Bug #1646144 opened: ACLs to devices need to be supported in core  <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1646144>
<mup> PR snapcraft#936 opened: nodejs: install during pull to support npm run <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/936>
<mup> PR snapd#2375 closed: store: retry tweaks and logging <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2375>
<zyga> cjwatson: hey, can you please suggest some lp-shell operation that would un-set the default repo from https://code.launchpad.net/snap-pc
<zyga> cjwatson: so that it shows github-mirror-{i386,amd64} explicitly
<zyga> ogra_: https://github.com/snapcore/pc-amd64/pull/3 and https://github.com/snapcore/pc-i386/pull/1
<mup> PR pc-amd64#3: Correct repo URL <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/3>
<mup> PR pc-i386#1: Add initial README.md <Created by zyga> <https://github.com/snapcore/pc-i386/pull/1>
<zyga> thanks!
<ogra_> np
<zyga> ogra_: https://github.com/snapcore/pc-i386/pull/2
<mup> PR pc-i386#2: Add simple snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pc-i386/pull/2>
<ogra_> not naive this time ? :)
<zyga> cjwatson: no worries, I figured it out :)
<zyga> ogra_: haha, I saw your comment :D
<ogra_> :)
<zyga> ogra_: so all the base four are done
<ogra_> yay
<zyga> ogra_: once the mirror is refreshed I'll add snapcraft recipes
<ogra_> cool
<zyga> ogra_: and I should give slangasek admin rights over this
<ogra_> yeah
<ogra_> he has all the store submission rights already
<zyga> ogra_: right, I want to give him github and launchpad project ownership
<ogra_> the question is ... as what user does the LP build run ?
<ogra_> you might need to re-own the snaps to snappy-dev (and just add steve to that team)
<ogra_> else the store submissions will be as zygoon
<jdstrand> ogra_: https://bugs.launchpad.net/snappy/+bug/1646144/comments/2
<mup> Bug #1646144: ACLs to devices need to be supported in core  <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1646144>
<jdstrand> ogra_: I have an idea :)
<jdstrand> ogra_: I need to step away for a bit, but this chat of ours today I think may get us somewhere good :)
<ogra_> :D
<ogra_> the idea sounds good !
<zyga> jdstrand: I'm curious too :)
<mup> PR snapcraft#923 closed: pluginhandler: source management moved to the core <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/923>
<ogra_> zyga, see the bug comment
<zyga> ogra_: I think those are as me
<zyga> ogra_: but I updated my boards, let me check
<ogra_> essentially, we use ACLs but for additional groups in extrausers
<zyga> ogra_: show up as canonical: http://pastebin.ubuntu.com/23558568/
<ogra_> i,e, snap-dialout ...
<ogra_> zyga, thats irrelevant ... i mean the sotre
<ogra_> **store
<zyga> ogra_: store says the published is canonical
<ogra_> who is the uploader
<zyga> ogra_: you cannot see that via snap info I suspect ( Chipaca << )
<ogra_> (the sotre will always say canonical is the publisher ... thats the output side ... i'm concerned about the input side here)
<zyga> ogra_: but my point is that it may not matter if it works
<Chipaca> what can't you see?
<ogra_> no, you can see it in the sotre page
<zyga> ah, from the store page
<zyga> Chipaca: uploader vs publisher on a snap
<Chipaca> yeah, that doesn't reach the client yet
<ogra_> zyga, it matters as soon as you resign, your account gets closed and alll builds under that account immediately stop
 * zyga nod
<ogra_> sadly i get 504 errors again :/
<zyga> nods even
<ogra_> so i cant really check
<zyga> yeah, same here
<zyga> ogra_: if that's "Submitted by" then it is indeed me
<ogra_> right ... i wonder if we can get that team owned
<ogra_> afaik it is the user who triggered the LP build
<zyga> I suppose so, it probably depends on the recipe
<zyga> right
<ogra_> so if your tree is owned by snappy-dev on LP everyone from the tam can be the owner
<ogra_> *team
<ogra_> that at least gives the opportunity to have some other account take over instead of having everything killed once an account is closed on LP
<zyga> ogra_: we could have a project group for all the canonical snaps on launchpad
<zyga> ogra_: as a way to find them more easily
<zyga> slangasek: around?
<slangasek> zyga: hi
<ogra_> zyga, well, thats snappy-dev for all others today
<zyga> slangasek: hey, I wanted to give you and update on where we are for the transition we talked about yesterday
 * slangasek nods
<zyga> slangasek: all the official gadgets are on https://github.com/snapcore/ already
<zyga> slangasek: we will probably tweak repository names later but they are all there and have the relevant history
<slangasek> and do I have admin / commit privs on them?
<zyga> slangasek: they have all been updated with nicer radmes and snapcraft.yamls that work
<zyga> slangasek: not yet, I need your github handle for that
<slangasek> zyga: vorlonofportland
<zyga> slangasek: all but pc are also built all the way to the store already (just waiting for the mirror to enable the last two)
<slangasek> zyga: did you end up using the pc snapcraft.yaml that sergiusens did?
<zyga> slangasek: not yet but I plan to next
<zyga> slangasek: all of the current ones are just dump plugins
<slangasek> ok
<ogra_> it think tehy are currently all just "dump"
<slangasek> wfm
<ogra_> yeah, we'll sort that over time
<zyga> slangasek: there are also four new launchpad projects, snap-{pi2,pi3,dragonboard,pc}
<zyga> slangasek: those host mirrors and do the package builds
<slangasek> only pc, not pc-i386 vs. pc-amd64?
<ogra_> nope
<zyga> slangasek: I need to give you admin access over those so that you can tweak the rest (ownership etc)
<ogra_> pc can handle both arches
<ogra_> store side
<ogra_> LP is where they get merged
<zyga> slangasek: only one because pc can handle both (on launchpad), it does have two repositories
<slangasek> but the gadget contents are different
<zyga> slangasek: but that can change over time
<ogra_> yeah, the github trees are too
<zyga> slangasek: the idea was that those map to snap names exactly with "snap-$SNAP_NAME"
<zyga> slangasek: github repos for pc were renamed from generic-* to pc-*
<zyga> slangasek: ogra reviewed all the pull requests sofar
<longsleep> zyga: its nice to have all the example/reference gadget stuff in one place - i will update my stuff on https://github.com/longsleep/build-pine64-image/tree/snappy/snappy accordingly.
<zyga> slangasek: and that's about it
<zyga> longsleep: woot! thank you!
<ogra_> nobody tested them though ... :)
<ogra_> or did you zyga ?
<zyga> ogra_: I switched my boards to them but I dind't build images, the content is the same as before thoughj (looking at prime/)
<slangasek> ok, so because the actual snap is named 'pc' this works - yes, understood
<ogra_> well, then we're fine
<zyga> slangasek: there are some low hanging fruit that I'll do a pass on also before finishing with this
<zyga> slangasek: I want to improve snapcraft.yaml's wrt consistency and wording
<zyga> (summary and description)
<slangasek> ok
<zyga> slangasek: so that's it :)
<longsleep> zyga: the only thing which prevents me from releasing snappy stuff for pine64 is the issue that i cannot register my key with snapcraft and that the kernel fails with some aparmor thing which we debugged yesterday. Do you have an ETA when to expect a release of that branch of yours? Or would it be better to search for a fix on the current core release?
<slangasek> zyga: who will review those snapcraft.yaml changes ? since you don't own these snaps :)
<zyga> longsleep: ETA 2-3 days to the image PPA from which it gets to edge instantly
<ogra_> slangasek, well, i handled them in the past, i will go on doing that
<zyga> slangasek: you and gora
<zyga> ogra
<zyga> slangasek: those are regular pull requests
<zyga> slangasek: I plan to add CI for snapcraft but maybe not tonight, I have a few other things to look at
<longsleep> zyga: ah ok thats good, so i might be able to build a edge image on the weekend or next week
<zyga> slangasek: let me add you as admin to the repos now
<zyga> oh, bugget
<zyga> bugger :P
<zyga> launchpad cannot build two recipes from one account to the same snap name
<zyga> "There is already a snap package owned by Zygmunt Krynicki with this name.
<zyga> cjwatson: ^^
<zyga> https://code.launchpad.net/~zyga/+snap/pc
<longsleep> zyga: https://github.com/snapcore/sample-kernels/commits/stable-3.10.y should work yes? So if i would compare whatever was merged into that tree my kernel should work with snappy too?
<zyga> longsleep: I don't know for sure, perhaps you should ask in #ubuntu-kernel
<zyga> slangasek, ogra_: have a look at https://code.launchpad.net/~zyga/+snap/pc
<longsleep> zyga: ok cool thanks
<zyga> is the name under "registered store package name" the only relevant thing
<zyga> and I can rename this to pc-i386?
 * zyga tries
<ogra_> i think thats the only relevant thing, yeah ... but you cant change it if you want to have it be the same thing in the sotre
<ogra_> (same thing as amd64)
<zyga> ogra_: compare https://code.launchpad.net/~zyga/+snap/pc-amd64 and https://code.launchpad.net/~zyga/+snap/pc-i386 please
<zyga> IMHO looks good but ... we'll know when this is done
<ogra_> ah, yeah, that looks correct
<ogra_> the name in snapcraft,yaml is also pc for both ?
<zyga> yes
<mup> PR snapd#2381 closed: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2381>
<zyga> you reviwed that :)
<ogra_> then we should be good
<mup> PR snapd#2371 closed: daemon, store: let snap info find things in any channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2371>
<zyga> niemeyer: can you please add vorlonofportland to the ubuntu-foundations team on https://github.com/orgs/snapcore/teams/ubuntu-foundations as the team maintainer
<zyga> slangasek: this will then give you control over https://github.com/orgs/snapcore/teams/ubuntu-foundations/repositories
<zyga> slangasek: let's talk about launchpad projects, who should own them?
 * ogra_ would keep them at snappy-dev and add people as needed to the snappy-dev team 
 * zyga nods
<ogra_> that worked in the past and all other automatic snaps use it
<ogra_> (core and kernels at least)
<ogra_> (though the kernel bit might move with the kernel team taking over)
<zyga> ogra_: pc-* builds completed
<ogra_> yep, i saw
<ogra_> failed the store review though
<zyga> ogra_: yeah, I'm seeing the same thing
<ogra_> Could not find compiled binaries for architecture 'i386' lint-snap-v2_architecture_specified_needed (i386)
<zyga> ogra_: interesting: Could not find compiled binaries for architecture 'i386'
<zyga> tyhicks: do you know where to report issues on store review tools?
<ogra_> well, it worked before ... something is wrong
<ogra_> bah
<ogra_> sigh
<zyga> store review tools may have gotten stronger, dunno
<zyga> can you look at the snap to triple check it is sane?
<ogra_> the new store policy will now stop all uploads for pc
<ogra_> so amd64 wont even go inot testing so we could compare
<zyga> I see
<zyga> that's unfortunate, indeed
<ogra_> yeah, thats a silly policy
<zyga> ogra_: do you want me to push the bbb gadget snap anywhere? I did transition it as well
<ogra_> push to a bzr branch
<zyga> ogra_: sorry, that was all in git after the repo split :/
<zyga> ogra_: one thing in bzr that we have to do is to remove those old versions from snappy-hub
<tyhicks> zyga: https://bugs.launchpad.net/click-reviewers-tools/+filebug
<zyga> tyhicks: thank you!
<tyhicks> np!
<ogra_> the i386 content looks fine to me
<ogra_> i see pc-boot.img and pc-core.img as well as grub.cfg
<ogra_> as it should be
<ogra_> i dont understand why the check tools would compplain here
<zyga> ogra_: reported as https://bugs.launchpad.net/click-reviewers-tools/+bug/1646176
<mup> Bug #1646176: pc gadget snap blocked because it doesn't have i386 executables <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1646176>
<zyga> ogra_: I suspect they look for elf files
<ogra_> zyga, well, it looks identical to the former pc i396 gadget
<ogra_> **i386
<zyga> ogra_: as I said earlier I suspect the review tools have chanced since it was last uploaded but that's just a theory
<ogra_> so why would this one fail while the other one went through
<ogra_> i dont think they changed much in the last three/four weeks
<zyga> slangasek: I didn't see your response for who should own launchpad objects
<zyga> ok, I need a break, it's gotten very cold up here, time to get some warm tea made
<zyga> ogra_: let me know if I can convince you of a nice shiny git repository
<ogra_> do it ... :P
<zyga> ogra_: I'd love to help as I want to support beagle boards for my ow needs
<zyga> ogra_: ! :)
<zyga> ogra_: where should we put the repo?
<zyga> ogra_: is there a bbb community that we could use to host this?
<zyga> ogra_: (nice to play in an exisiting playground :)
<ogra_> i dont think so ... or i dont know about one on github at least
<zyga> ogra_: ok, I'll get that tea and look around
<zyga> ogra_: it would be nice if we could support variou TI boards this way, as long as they have a nice kernel and support ARMv7
<zyga> ogra_: I bet you have more than I do :)"
<ogra_> but i dont think it is bad if either you or me own it
<zyga> ogra_: we could create a small organization and keep those projects there, it's a nice way to attract attention as it's not under anyone's name
<zyga> ogra_: e.g. "beagleboard.org" or something
<ogra_> we already can support multiple TI boards ... the generic kernel has a bunch of dtb's
<ogra_> but each would need its own gadget anyway
<zyga> but I bet there's some organization on github already, we just need to find it
<zyga> ogra_: yes but that's an org, repos are under an owner (org or person)
<ogra_> and the bbb community wont use our kernel anyway
<ogra_> we're missing all the rcn-ee patches
<ogra_> so that gadget isnt really for them
<zyga> ogra_: so could be github.com/beagleboard.org/{beagle,beagleboardblack,...}
<zyga> ogra_: one step at a time :)
<ogra_> well
<ogra_> the bbb gadget as is is far from being done
<ogra_> it is supposed to use raw imgs, not a vfat for uboot ...
<zyga> ogra_: sure, but it doesn't need to be perfect, it's important to find people that are willing to improve it and let them do it
<ogra_> i had to cripple it due to an ubuntu-image bg
<ogra_> **bug
<ogra_> until it is ready for consumption i'd really prefer to not submit it anywhere
<zyga> ogra_: what is the bug?
<ogra_> a limitation in the sdgisk handling
<ogra_> it is fixed now
<ogra_> (you had to assign a partition per raw blob ... that moved the partition numbering and broke uboot... )
<kalikiana> Is there any way to shadow /usr/bin/ locally from the point of view of a snap? I'm wondering if I can deal with a hard-coded /usr/bin/ without modifying the source
<ogra_> it needs love (essentially a re-write of the gadget.yaml) that i didnt get to yet
<slangasek> zyga: I disagree, the launchpad projects should be clearly owned by the foundations team not just snappy-dev
<zyga> kalikiana: yes but it's not supported yet, we plan to support that
<zyga> slangasek: fine, just give me the team name :)
<ogra_> slangasek, is there a LP team for foundations used to own branches etc ?
<slangasek> zyga: canonical-foundations
<zyga> kalikiana: I think it will come to my todo list in Jan next year
<zyga> slangasek: thank you :)
<ogra_> (i only know cnaonical-foundations but thought thats organisational)
<zyga> kalikiana: in a release Feb perhaps
<slangasek> (there is a community ubuntu-foundations team but I'd rather just keep canonical-foundations for now)
<kalikiana> zyga: Okay, I suppose hacking the source it is then. Waiting two months is not an option, but thanks anyway :-D
<zyga> kalikiana: contributions are welcome, if you want to help we could get it in earlier
<zyga> kalikiana: I can work with you and guide you through the code
<zyga> kalikiana: we have machinery for that
<zyga> slangasek: can you go to https://launchpad.net/snap-pi2 and edit all the other objects to be owned by that team
<zyga> slangasek: I can no longer do it
<zyga> slangasek: please also edit git mirror owner
<kalikiana> zyga: I'd be interested in having a look. I don't know at what end that would be tackled at all, though - I have written some snapd code but no clue about other related bits
<zyga> slangasek: or add me to that team for a moment
<zyga> slangasek: I think that might be faster
<zyga> kalikiana: you can hack a prototyle locally
<slangasek> zyga: on a call, I will look at this shortly
<zyga> slangasek: thank you
<zyga> kalikiana: you can edit the mount profile that looks like an fstab, it is in /var/lib/snapd/mount/profiles AFAIR
<zyga> kalikiana: (it might be gone if you don't have one for a snap but it's easy to create
<zyga> kalikiana: the contents are exactly like an /etc/fstab
<zyga> kalikiana: if you describe a bind mount operation there you can bind mount, e,g. /snap/yoursnapname/revision/bin to /bin
<zyga> kalikiana: you will have to patch snap confine (perhaps) to allow this via an apparmor profile but you can do that live on a running system without rebuilding anything
<zyga> kalikiana: by editing /etc/apparmor.d/usr.lib.snapd.snap-confine
<zyga> kalikiana: (I can show you how)
<zyga> kalikiana: and re-compiling the profile with apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine
<zyga> kalikiana: if that all works the rest is to make that nicer and exposed through snapcraft.yaml
<zyga> kalikiana: from there to snapd
<zyga> kalikiana: and to that file
<zyga> kalikiana: should be very easy to do a quick check if this works for you
<zyga> kalikiana: and if it does I can help you make the contirbutions to snapd and eventually to snapcraft
<kalikiana> Hmmm that sounds simpler than I might've expected
<zyga> kalikiana: the fstab file is named snap.$SNAP_NAME.$APP_NAME AFAIR
<zyga> kalikiana: you can run your program with SNAP_CONFINE_DEBUG=yes in the environment
<zyga> kalikiana: it is pretty useful to see what's going on
<zyga> kalikiana: one important note!
<zyga> kalikiana: you need to run sudo /usr/lib/snapd/snap-discard-ns $SNAP_NAME
<zyga> kalikiana: after every change to the mount profile and invocation of snap-confine
<zyga> kalikiana: we don't have live modification of the mount namespace yet, that's something high on my todo list but it's not done yet
<zyga> kalikiana: try it and ask if you get stuck on anything
<zyga> :-)
<zyga> kalikiana: and you can look at a snap using the content interface (connected) to see how this file usually looks like and how it is named
<zyga> slangasek: I'm EODing, please add me to canonical-foundations so that I can complete the move
<zyga> slangasek: ttyl :)
<slangasek> zyga: ... no, but I will move over anything you want moved over :)
<zyga> slangasek: can you move the git repos as well?
<slangasek> yes, sure
<zyga> slangasek: unless you have lp superpowerers you may not be able to
<zyga> slangasek: if you can just go for it :)
<slangasek> zyga: "git clone" "git push"
<zyga> slangasek: no.. don't do that
<zyga> slangasek: those are git mirrors
<slangasek> heh ok
<zyga> slangasek: also snap build recipes from those
<zyga> slangasek: perhaps you can just ask lp admins to change those
<slangasek> zyga: or should I not just recreate them?
<zyga> slangasek: in the end you will also have to change all the README.md files as the owner is encoded in the URL
<zyga> slangasek: well, that'd just duplicate all the work I did, I think it's faster to change the owner
<ogra_> recreate sounds sanest
<zyga> ogra_: why? this is all checked already
<ogra_> but that would need super powers
<zyga> slangasek: wait
<zyga> slangasek: I can move this to canonical (group)
<zyga> slangasek: you can move it then to the foundations team
<zyga> slangasek: ok?
<ogra_> heh
<slangasek> zyga: which bit are you moving?
<ogra_> canonical proxy
<zyga> https://code.launchpad.net/~zyga/snap-pi2/+git/github-mirror/+edit
<slangasek> ok
<zyga> slangasek: try now
<zyga> oh boy, the snap owenr edit has broken UI :)
<ogra_> https://code.launchpad.net/~canonical/snap-pi2/+git/github-mirror/+edit seems to offer swithing owners though
<zyga> slangasek: also https://launchpad.net/~canonical/+snap/pi2
<zyga> repo chown'ed
<zyga> nice!
<ogra_> yay
<zyga> now just the package
<slangasek> zyga: done and done
<zyga> slangasek: great, I'll move pi3 and the rest next
<zyga> slangasek: https://code.launchpad.net/snap-pi3 all yours now
<zyga> slangasek: snap-pc ready for you
<zyga> slangasek, ogra_: https://github.com/snapcore/pi2/pull/5 https://github.com/snapcore/pi3/pull/3 https://github.com/snapcore/dragonboard/pull/3 https://github.com/snapcore/pc-i386/pull/3 https://github.com/snapcore/pc-amd64/pull/4
<mup> PR pi2#5: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pi2/pull/5>
<mup> PR pi3#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pi3/pull/3>
<mup> PR dragonboard#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/dragonboard/pull/3>
<mup> PR pc-i386#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pc-i386/pull/3>
<mup> PR pc-amd64#4: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/4>
<ogra_> all approved
<zyga> ogra_: merge them
<zyga> ogra_: you should have the green button :)
<ogra_> done
<zyga> ogra_: thanks!
<zyga> :)
<ogra_> awful clickery
<zyga> slangasek: snap-pc doesn't have the nice summary as other snaps do
<zyga> slangasek: sorry, I didn't notice this earlier when creating the project
<zyga> compare https://launchpad.net/snap-dragonboard and https://launchpad.net/snap-pc
 * zyga EODs
 * ogra_ too
<zyga> ogra_: thanks for your help, that was well worth it IMHO :)
<zyga> ogra_: let's talk tomorrow about bbb
<zyga> ogra_: enjoy your evening :)
<ogra_> i will !
<ogra_> you too !
<mup> PR snapd#2299 closed: overlord, daemon, progress: enable building snapd without CGO <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2299>
<slangasek> zyga: branches and snap recipes transferred, thanks!
<zyga> slangasek: I think you missed https://code.launchpad.net/~canonical/+snap/dragonboard
<slangasek> zyga: race condition ;) done now
<zyga> slangasek: confirmed! all the links from github work as well
<zyga> nice :)
<zyga> thank you for the help
<zyga> slangasek: you may want to look at https://bugs.launchpad.net/click-reviewers-tools/+bug/1646176 though
<mup> Bug #1646176: pc gadget snap blocked because it doesn't have i386 executables <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1646176>
<zyga> slangasek: it cripples i386 / amd64 gadgets today
<mup> PR snapd#2389 opened: daemon: close the dup()ed file descriptor to not leak it <Created by chipaca> <https://github.com/snapcore/snapd/pull/2389>
<slangasek> zyga: by "cripples" you just mean that it prevents auto-publishing to edge, correct?
<zyga> slangasek: yes
<zyga> slangasek: they are stale
 * slangasek nods
<slangasek> though if any of your PRs changed the binary contents of the gadget... :)
<zyga> slangasek: I'm running those gadgets on my boards / pc's but I didn't try to re-flash
<zyga> slangasek: I think you should work with QA to propmote some edge revisions to beta to get them tested
<zyga> slangasek: or candidate before the next release
<zyga> slangasek: I'll propose some improvements to snapcraft.yaml's because they are ugly-ish and were done in a hurry
<zyga> slangasek: but those are now normal reviews :)
<zyga> slangasek: when gustavo adds you to the team on github you will have admin power over all those repos
<slangasek> zyga: also, I saw your autobuild recipes use xenial. Any reason not to track devel?
<zyga> slangasek: no opinion on that, right now it doens't matter (IMHO) but perhaps I'm wrong
<slangasek> I don't think we want to build edge only from binaries that have cleared SRU queue
<zyga> slangasek: also those are for 16 series which is xenial-ish so ... there
<zyga> slangasek: but feel free to change those if you think it should be something else
<slangasek> it's edge; we should take edge bootloader contents
<slangasek> (switching now)
<zyga> slangasek: one detail, can you updatet https://launchpad.net/snap-pc to have nicer summary
<zyga> slangasek: e.g. " The gadget snap for Personal Computers using Intel or AMD processors"
 * zyga nod
 * zyga nods
<zyga> (and s is stuck)
<ogra_> time for a new keyboard ;)
<zyga> nah, I'll just spray some air into it, it's not that old
<zyga> ssss
<slangasek> zyga: I'm unclear what you're wanting changed on https://launchpad.net/snap-pc, I already see a description much like the one for https://launchpad.net/snap-dragonboard
<zyga> slangasek: the big bold "snap-pc"
<slangasek> ah
<zyga> slangasek: compare to https://launchpad.net/snap-pi2
<slangasek> done
<zyga> slangasek: so that it feels uniform among snap-{pi2,pi3,dragonboard,pc}
<zyga> thanks!
 * zyga really EODs now :-)
<attente> sergiusens: hi, for some reason i keep getting "fatal: unable to access 'https://git.gnome.org/browse/jhbuild/': Failed to connect to git.gnome.org port 443: Connection timed out" from the integration test on github c-i
<sergiusens> elopio can you check on attente's problem?
<mup> PR snapd#2390 opened: tests: do not use external snaps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2390>
<zyga> slangasek: I've added -gadget suffix to all the repos on github per niemeyer's request, can you please edit the correspodning github/launchpad links. I believe there are some redirects but it is more confusing if we have to rely on those
<slangasek> zyga: ack, will do shortly
<slangasek> zyga: I can't find an option to change the git branch that's the target for mirroring
<cwayne> zyga: hey, sorry to bother you -- any eta on 'snaps calling other snaps' fix?
<mup> PR snapcraft#933 closed: _filedir takes an extension, not a glob <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/933>
<pedronis> cwayne: we don't have a design, either way last IÂ heard it needs to be expressed as some kind of interface (it's setting up a dependency in practice so it needs to be mediated that way to fit)
<zyga> cwayne: progressing, still not done, still pending for .45
<zyga> slangasek: you mean source, right?
<zyga> slangasek: I think that's fine, github does the aliases internally
<slangasek> zyga: ok, then what was it you wanted updated?
<zyga> slangasek: URLs in in README.md's and on launchpad itself in project description
<slangasek> ah
<mhall119> jdstrand: has https://issues.apache.org/jira/browse/COUCHDB-3226 been fixed in the mount-observe interface now?
<robert_ancell> jdstrand, regarding your PR for D-Bus addresses. The first interface I am thinking of is the LigthDM D-Bus service. It seems to me this doesn't make sense as a built-in interface in snapd.
<ssweeny> I currently use systemd mount dependencies to keep my media server software from starting until the external drive with the media on it is mounted. Is there a way to do that in a snap or do I have to write a startup script that waits on the mount to happen?
<jdstrand> mhall119: it is in trunk. It should be in 2.18
<jdstrand> robert_ancell: hmm, it seems to me like it *would* be an interface
<robert_ancell> jdstrand, but it only applies to that one snap, and if I changed it in the future it would require modifying snapd...
<mhall119> jdstrand: I thought 2.18 was released, is it waiting to be SRU'd into 16.04?
<mup> PR snapcraft#936 closed: nodejs plugin: install during pull to support npm run <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/936>
<jdstrand> robert_ancell: that could be said of the network-manager interface as well. that is the nature of interfaces. Interfaces are contracts between consumers and providers. if lightdm is going to be shipped as a snap and going to provide a service, it needs an interface
<jdstrand> robert_ancell: the interface can be forward thinking and written in a way to minimize future changes
<robert_ancell> jdstrand, it just seems like this is not going to scale for the hudreds of other interfaces that need to exist
<jdstrand> robert_ancell: again, interfaces are contracts between snaps that may not be coordinating. if lightdm changes in an incompatible way with other snaps, then that needs to be coordinated via snappy such that a new lightdm doesn't break a consuming snap
<jdstrand> robert_ancell: if lightdm isn't changing in incompatible ways like that then there is no maintenance issue because snapd shouldn't have to change
<jdstrand> robert_ancell: some day the dbus interface might grow to a point that you wouldn't need a separate interface beyond it. however, system services, bus policy, policykit, etc, it isn't there yet
<mup> PR snapd#2389 closed: daemon: close the dup()ed file descriptor to not leak it <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2389>
<mup> PR snapcraft#934 closed: deltas: migrate from xdelta to xdelta3 <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/934>
<mup> PR snapcraft#935 closed: cmake plugin: utilize MakePlugin build logic within CMakePlugin <Created by larryprice> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/935>
#snappy 2016-12-01
<mup> PR snapcraft#937 opened: Incorporate all part properties into state tracking <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/937>
<josharenson> When I run refresh-bits ala git@github.com:zyga/devtools, I get an error about not having systemd installed? (running zesty)
<mup> Bug #1646333 opened: bind mounts related to content interface plugs remain stale on snap disconnect/connect or snap updates <Snappy:New> <https://launchpad.net/bugs/1646333>
<mup> PR snapd#2391 opened: Discard mount namespace on a content i/f plug connect/disconnect <Created by albaguirre> <https://github.com/snapcore/snapd/pull/2391>
<foxmask> bonjello
<mup> PR snapd#2390 closed: tests: do not use external snaps <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2390>
<dholbach> hey hey
<zyga> o/
<seb128> hey dholbach zyga, how are you?
<dholbach> salut seb128
<dholbach> doing all right - how about you?
<seb128> I'm good thanks :-)
<zyga> seb128: hey, I'm good :-) how are you?
<seb128> zyga, I'm good thanks ;-)
<tsdgeos> guys, snapcraft should never use one of my libs from /usr to end up in the snap but instead use the libs from the .deb files it downloads, no?
<kalikiana> I would intuitively expect the .deb files to take priority
<tsdgeos> because i think i found a case in which is not happening
<tsdgeos> which i have to say was unexpected
<Chipaca> tsdgeos: that's a bug
<Chipaca> tsdgeos: without knowing the details I can't say whether it's a bug in snapcraft, or in your yaml
<tsdgeos> Chipaca: how would the yaml make that happen?
<Chipaca> tsdgeos: if the lib needed isn't in the deb you download (or maybe even if it's in the deb but needs the library path tweaked by postinst)
<tsdgeos> ok
<mup> Bug #1646415 opened: cannot run configure hook <Snappy:New> <https://launchpad.net/bugs/1646415>
<mup> Bug #1646415 changed: cannot run configure hook <Snappy:Invalid> <https://launchpad.net/bugs/1646415>
<mup> PR snapd#2392 opened: partition: add support for native grubenv read/write and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/2392>
<caio1982> ng
<caio1982> good morning
<zyga> hey caio1982
<grigio> hi, I get â¯ env LANG=C ./electron-quick-start  ./electron-quick-start: line 6: cd: /lib/node_modules/electron-quick-start: No such file or directory ./electron-quick-start: line 7: /bin/npm: No such file or directory
<grigio> I tried this example http://bazaar.launchpad.net/~3v1n0/+junk/electron-quick-start-snap/files
<renato__> mvo, hi, could you approve this MR? https://myapps.developer.ubuntu.com/dev/click-apps/6062/rev/21/
<mvo> renato__: sure
<renato__> mvo, thanks
<mup> PR snapd#2393 opened: interfaces/apparmor: use distinct apparmor template for classic <Created by zyga> <https://github.com/snapcore/snapd/pull/2393>
<mup> PR snapd#2372 closed: interfaces/seccomp: add support for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2372>
<renato__> mvo, could you approve two more packages: https://myapps.developer.ubuntu.com/dev/click-apps/6019 rev 7 and 8
<renato__> mvo, same for address-book-app: https://myapps.developer.ubuntu.com/dev/click-apps/6010 rev 19 and 20
<ondra> ogra_ ping
<ogra_> hey ondra
<ondra> ogra_ hi, this would be simple one, in shell script, what is best reliable way to detect app is running as snap?
<ogra_> hmm ... check the path of the binary ?
<ogra_> something like that
<ogra_> there is a bunch of $SNAP_ variables you could look for
<ondra> how about check is SNAP_COMMON exist?
<ogra_> SNAP_NAME or SNAP_VERSION ....
<ondra> ogra_ is it something we will keep for foreseeable future?
<ogra_> i guess so
<ondra> ogra_ OK, then I will stick to those :)
<ondra> ogra_ cheers!
<ogra_> install hello-world, run hello-world.sh ...
<ogra_> then check the env
<ogra_> (or there is even a hello-world.env i think)
<ondra> ogra_ yeah there is
<mvo> jdstrand, renato__: I approved https://myapps.developer.ubuntu.com/dev/click-apps/6010/ - what is needed to make this automatic?
<renato__> mvo,  I know that jdstrand is working on it. I am not sure about the status
<mvo> renato__: aha, sure, thats fine then
<renato__> mvo, could you approve 6019 too?
<mvo> renato__: I did, didn't i?
<renato__> mvo, no still blocked
<mvo> renato__: oh, you are right
<renato__> mvo, thanks
<icey> should I push a BS commit to trigger the autopgktests on this again, or maybe merge in master for the commit to get the fix from master? https://github.com/snapcore/snapcraft/pull/908
<mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
<renato__> mvo, sorry to keep disturbing you, but 6019 rev 9 still blocked :(
<jdstrand> renato__ (cc mvo): you need to request a manual review
<jdstrand> renato__: it doesn't show up in the list unless you do that
<renato__> jdstrand, humm sorry I miss this one
<jdstrand> renato__: and the person who pushes that button can't then approve it
<jdstrand> (so it can't be us)
<jdstrand> mvo: I handled it
<renato__> thanks
<jdstrand> renato__: done
<mvo> jdstrand: thanks, was in a meeting
<flexiondotorg> sergiusens, kyrofa I've discovered a bug with source-type: deb
<flexiondotorg> Want to find out if it is known.
<flexiondotorg> If you use a deb as source and that deb has sym-links in it, the link names are created as directories in the snap.
<flexiondotorg> In my use case the binary is trying to load a lib which is effectively doesn't exist.
<mup> PR snapd#2394 opened: snap: show last update time <Created by mvo5> <https://github.com/snapcore/snapd/pull/2394>
<mup> PR snapcraft#938 opened: store: return specific error when already owned <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/938>
<alex-abreu> mvo, could you comment on https://github.com/snapcore/snapweb/pull/101 ?
<mup> PR snapweb#101: replace find vs findone <Created by AlexandreAbreu> <https://github.com/snapcore/snapweb/pull/101>
<mup> PR snapd#2395 opened: make state and squashes immutable when appropriate <Created by chipaca> <https://github.com/snapcore/snapd/pull/2395>
<mvo> alex-abreu: let me have a look
<timp> jdstrand: hello, I have a question about this bug https://bugs.launchpad.net/ubuntu-ui-toolkit-examples/+bug/1645377
<mup> Bug #1645377: AppArmor policy error for networking at initialization, even with the correct network plug. <snapd-interface> <Snappy:Invalid> <ubuntu-ui-toolkit-examples:New> <https://launchpad.net/bugs/1645377>
<timp> jdstrand: that app just wants to download something from internet, for that it should not need to use the network-manager interface right?
<timp> any ideas why it currently needs that?
<renato__> popey, hey, could you review this? https://code.launchpad.net/~renatofilho/ubuntu-calculator-app/unity8-snap/+merge/312260
<timp> renato__: why do you need unity7 and unity8?
<renato__> timp, the unity8 session that tedg is working needs unity8 interface.  And unity7 is to keep it compatible with unity7
<timp> renato__: ah, ok. Will we need to add unity8 to all GUI apps?
<renato__> timp, I think so
<timp> renato__: hmm.. and all GUI apps also need opengl I guess. So maybe we should find out if it is possible for [platform] to also imply [opengl, unity7, unity8]
<timp> I don't know if it would work if we simply add those plugs to the ubuntu-app-platform snap.
<timp> sergiusens: ^how would we do that?
<renato__> timp, I am not sure about that. I think that is ok to explicitly say which interface you app request. S
<renato__> timp, and some apps can be ready only for unity7
<timp> renato__: but if you use the platform snap, you'll need all those plugs
<renato__> timp, some apss can uses plataform and does not have any ui
<timp> renato__: ah, that's true.
<timp> hmm
<timp> well the core of the platform (at least the dependencies that we put in there first) is the UITK
<renato__> timp, i can have a app that only uses qtcore or network, etc..
<timp> hmm
<timp> yeah
<timp> but would you use the platform snap then? Platform has a lot more than just qt.
<timp> but if you don't want to compile qt, then currently the platform snap is what you need to use.
<renato__> timp, if the plataform is part of the system already. I do not see why not use that
<timp> That really depends on the use case.
<renato__> if I have a gadget that only runs my app problably I can pack qt on it.
<timp> yes
<timp> renato__: ok. We can leave it as it is for now then :)
<renato__> popey, one more: https://code.launchpad.net/~renatofilho/ubuntu-clock-app/unity8-snap/+merge/312263
<jdstrand> timp: you are right, it shouldn't need network-manager. It is (almost certainly) only accessing network-manager to see if the network is available. this is a very longstanding conversation regarding Qt and network-manager and is precisely why connectivity-api was developed. see bug #1341548
<mup> Bug #1341548: Online detection does not work with confined apps on Nexus 4 <rtm14> <touch-2014-08-21> <Dekko:Fix Released by dpniel> <Network Menu:Fix Released by kaijanmaki> <apparmor-easyprof-ubuntu (Ubuntu):Fix Released by jdstrand> <connectivity-api (Ubuntu):Fix Released by kaijanmaki>
<mup> <indicator-network (Ubuntu):Fix Released by kaijanmaki> <connectivity-api (Ubuntu RTM):Fix Released by kaijanmaki> <indicator-network (Ubuntu RTM):Fix Released by kaijanmaki> <https://launchpad.net/bugs/1341548>
<timp> jdstrand: so I will be required to use connectivity-api whenever I access the network, even when I use the [network] plug already?
<timp> in which channel should I ask about snap store reviews and automatic publishing of LP projects to the store?
<timp> maybe here?
<ogra_> here :)
<timp> Ok. :) I configured https://launchpad.net/~ubuntu-sdk-team/+snap/ubuntu-ui-toolkit-examples to automatically upload a snap on the edge channel in the store, but on https://myapps.developer.ubuntu.com/dev/click-apps/6427/rev/3/ it appears in the Release channel
<timp> ^is that a bug?
<zyga> renato__: no idea, sorry
<zyga> renato__: did you trace the calls from that failure back to base policy?
<timp> ignore my question. It was already answered somewhere else <noise> timp: that's not a channel name, that's the action button to release it into channels
<ogra_> heh
<ogra_> i was about to ask what you mean with release channel
<zyga> ogra_: new channels, there's one every weekend ;)
<zyga> matrix keeps changing
<ogra_> heh
<timp> ogra_: right :)
<timp> who can I kick to review the ubuntu-ui-toolkit-examples snap in the store?
<sborovkov> Hello. snap store seems to be very slow. I get constant timeouts when clicking on revision? Any idea what's up with it?
<jdstrand> timp: if your app is trying to check if the network is available, it will need to plugs something else, yes. if it is using network-manager, it needs to plugs network-manager (that will require a snap interface manual connect), if it is using connectivity-api, it needs to plugs it (that will be auto-connected)
<jdstrand> timp: note that connectivity-api interface isn't available yet. it is part of the Ubuntu Personal work. I don't know the status
<timp> jdstrand: so if you use network you will always need network-manager or connectivity-api?
<jdstrand> zyga: fyi, you mentioned not looking for other occurences of the i2c bug. I just did. i2c is the only thing not using utils.go and utils.go is fine
<timp> I assume when you use the network, it will check whether that's available.
<jdstrand> timp: plenty of apps need only 'plugs: [network]'. your app is trying to be smart and as a result it needs to plugs something else
<jdstrand> (in addition to network)
<zyga> jdstrand: good to know, thank you
<jdstrand> timp: in Ubuntu Touch, we put connectivity-api in the network policy group. the core snap does not have the connectivity-api daemon in it, so it will be provided via a snap. as such, you will need to 'plugs: [network, connectivity-api]' on snappy (whenever connectivity-api is available)
<zyga> jdstrand: I'm iching to rewrite interfaces internally as we discussed, maybe over xmas :)
<zyga> itching*
<jdstrand> zyga: heh, please make sure that the policy remains easily auditable within the codebase. that's all tyhicks and I are asking :)
<timp> jdstrand: This is the full app http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/examples/jokes/jokes.qml
<zyga> jdstrand: as agreed :)
<timp> It does not seem to do anything smart, I guess the XMLHttpRequest(); does that then.
<zyga> jdstrand: I'd definitely do that to ensure my sanity :)
<timp> I'm just thinking how to make it easy for developers to use that.
<timp> I don't know the details of what the XMLHttpRequest object does, just trying to snap the UITK examples.
<jdstrand> timp: if this is for qtubuntu apps, seems reasonable to default the snapcraft.yaml to use 'plugs: [network, connectivity-api]' just like for click it use '"policy_groups": ["network"]'
<jdstrand> timp: in the sdk
<timp> jdstrand: yes, it is a qtubuntu app (using the ubuntu-app-platform snap) with "network" int he policy groups.
<timp> jdstrand: I'll add a note in my snapcraft.yaml to add that when the connectivity-api is done. Let's see if I can find the bug for that.
<Odd_Bloke> ogra_: Still looking at this week for that Azure bug?
<ogra_> Odd_Bloke, bug 1639878 ?
<mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:Fix Committed by ogra> <https://launchpad.net/bugs/1639878>
<Odd_Bloke> ogra_: Yep.
<ogra_> (new kernel snap is in edge with the modules included)
<Odd_Bloke> Oh, I must not be subscribed, I hadn't seen updates.
<Odd_Bloke> Fail.
<ogra_> not sure when the next release is planned though ... mvo might know
<ogra_> then it should hit stable
<mvo> ogra_: next release is next thursday
<mvo> Odd_Bloke: -^
<ogra_> :)
<Odd_Bloke> Cool, thank you both!
<mvo> ogra_: I think we can bump the kernel to beta now (if it booted) and then I can ask qa to test it
<ogra_> mvo, yeah, though we are missing an updated rpi2 one it seems
<ogra_> dragon and pc broth had updates since my vacation
<ogra_> pi not
<mvo> ok
<ogra_> not sure what keeps it in proposed ... ppisati ?
<ogra_> but we can indeed push the others up to beta
<mvo> ogra_: thank you!
<alex-abreu> mvo, btw this wont be added back to 2.18 right ? https://github.com/snapcore/snapd/pull/2394
<mup> PR snapd#2394: snap: show last update time <Created by mvo5> <https://github.com/snapcore/snapd/pull/2394>
<mvo> alex-abreu: correct, this is targeted for 2.19
<alex-abreu> mvo, ok thx
<mvo> (which is just one week away :)
<alex-abreu> mvo, even better thx :)
<mup> PR snapd#2396 opened: tests: fix incorrect restore of the current symlink <Created by mvo5> <https://github.com/snapcore/snapd/pull/2396>
<zyga> jdstrand: can you join a call about classic confinement and the store now?
<kyrofa> flexiondotorg, just ANY symlink?
<kyrofa> flexiondotorg, not known by me anyway
<kyrofa> flexiondotorg, ah, wait, LP: #1634813
<mup> Bug #1634813: Symbolic links inside .deb pulled as directories <sources> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1634813>
<flexiondotorg> kyrofa, Yep, that is the issue.
<flexiondotorg> I'll subscribe to that.
<flexiondotorg> I've got a fix in progress.
<kyrofa> flexiondotorg, thanks for the poke. Ah! You know what the issue is?
<flexiondotorg> kyrofa, The issue is apt_install.extractall() doesn't do the right thing.
<flexiondotorg> The Tar() class in internal/sources.py does the right thing, so can be the basis of a fix.
<kyrofa> Good deal. Happy to investigate if you're short on time, let me know?
<flexiondotorg> Well, I'll be leaving the office in a bit.
<kyrofa> flexiondotorg, alright I'll take a look once I'm done with my current PR
<flexiondotorg> kyrofa, Thanks.
<flexiondotorg> I'm just finishing something else too.
<kyrofa> flexiondotorg, thanks for the pointers :)
<flexiondotorg> In the Tar() class you'll see the _extract() method. That is what I was going to reimplement for the Deb() class.
<bitpushr> Howdy all - setting up snappy, however the key on my ubuntu one account was dsa - and I can't SSH in with it because it is a rejected protocol. Anyway to trigger the snappy device to redownload my ssh public keys?
<bitpushr> (without logging in or running a fresh install)
<kyrofa> ogra_, do you know the answer to that question? ^^
<ogra_> nope
<ogra_> i saw the question before ... have never used a dsa key
<ogra_> (i think someone asked the same at the beginning of the week)
<ogra_> kyrofa, sounds more liek a question to some store person :)
<ogra_> *like
<kyrofa> ogra_, indeed, thank you. nessita, are you around?
<kyrofa> mvo, you might be able to help with that as well. Is there any way to trigger Ubuntu Core to re-download SSH keys? 1) as a logged in user, and 2) without being able to login?
<nessita> kyrofa, around otp, could you repeat the question?
<jdstrand> niemeyer: can you meet now for snap decl talk>?
<niemeyer> jdstrand: Yep, is your mic working agian?
<niemeyer> https://hangouts.google.com/hangouts/_/canonical.com/base-declaration
<jdstrand> niemeyer: I'll get it to work. can you start a new hangout and I'll join?
<jdstrand> ok
<jdstrand> niemeyer: it says I am the first to join
<kyrofa> nessita, sure thing-- bitpushr had a dsa key on his SSO, so when Ubuntu Core fetched the keys that's all it got, and it doesn't work. If he's since uploaded an rsa key, do you know if there's a way to re-trigger the key download?
<nessita> kyrofa, hum, I have no idea, the store is not involved in that part
<nessita> other than providing an API to get all the public sshs for an emai;
<nessita> email*
<kyrofa> nessita, yeah, me neither :( . Alright, thanks for your time!
<nessita> kyrofa, :-)
<bitpushr> kyrofa: you have same issue?
<pedronis> kyrofa: refreshing keys is still a TODO afaik
<kyrofa> bitpushr, I'm afraid not, I use rsa keys
<bitpushr> It would be a good idea to refresh them on boot at least
<bitpushr> I thought it might but it does not
<kyrofa> pedronis, so what is the path forward. A reinstall?
<pedronis> IÂ don't know
<bitpushr> No worries, but I would like to put that in as a feature request. Would also help handle expired keys, updated keys, etc
<bitpushr> This was an old key I had
<sergiusens> flexiondotorg will look into it
<sergiusens> flexiondotorg but we are using the python deb extraction implementation
<renato__> jdstrand, could you approve messaging-app package in the store: https://myapps.developer.ubuntu.com/dev/click-apps/6192 rev 4 e 5
<pedronis> bitpushr: I created this https://bugs.launchpad.net/snappy/+bug/1646559
<mup> Bug #1646559: should periodically refresh ssh keys that were obtained from SSO/store for local users <Snappy:New> <https://launchpad.net/bugs/1646559>
<mup> Bug #1646559 opened: should periodically refresh ssh keys that were obtained from SSO/store for local users <Snappy:New> <https://launchpad.net/bugs/1646559>
<bitpushr> Thank you pedronis
<jdstrand> renato__: looking now. sorry was in meetings
<renato__> jdstrand, np. thanks
<zyga> tyhicks, jdstrand: https://github.com/snapcore/snap-confine/pull/199
<mup> PR snap-confine#199: Add error support code <Created by zyga> <https://github.com/snapcore/snap-confine/pull/199>
<zyga> this is a prelude to https://github.com/snapcore/snap-confine/commit/f7ee6df44916109731ce8a611ff57d9a70954b56
<zyga> and on top a small patch that adds --classic support
<mup> PR snapcraft#900 closed: ftp source support <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/900>
<zyga> which is https://github.com/snapcore/snap-confine/commit/6f289caa3a7adcfcedef25c13378fb9bd5de2f95
<mup> PR snapcraft#939 opened: Replace coveralls with codecov <Created by elopio> <https://github.com/snapcore/snapcraft/pull/939>
<zyga> I got a +0.5 from mvo on telegram, I'd love a review from you
<zyga> one more branch and I'll switch to that for parsing command line
<zyga> and then (no-op) classic can be dput to a image ppa
<mup> PR snapd#2387 closed: asserts: introduce auto-aliases header in snap-declaration <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2387>
<mup> PR snapd#2396 closed: tests: fix incorrect restore of the current symlink <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2396>
<mup> PR snapd#2369 closed: snap: disable support for socket activation <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2369>
<mup> PR snapcraft#940 opened: Implement delta uploads in push <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/940>
<alex-abreu> niemeyer, do you have an update on the snapd-control & install/connect issue for local snaps?
<jdstrand> alex-abreu (cc niemeyer): we had a meeting today. we are getting close to having an answer
<alex-abreu> jdstrand, ok it will be backported to 2.18 right ?
<jdstrand> alex-abreu: that is the intent, yes
<alex-abreu> jdstrand, thank you, ... any eta?
<jdstrand> alex-abreu: well, no since we don't have the answer yet
<jdstrand> but getting there. once we've worked through the answer, someone will send something to the list
<alex-abreu> jdstrand, ok, ... thank you
<icey> is there anny chance of (non-root) installable snaps?
<kyrofa> icey, probably not, at least not in the near future
<tedg> jdstrand: Are the snap confine tools closing all the file descriptors?
<tedg> jdstrand: Trying to pass one through and it's not making it...
<zyga> jdstrand: hey
<jdstrand> tedg: not that I can see
<zyga> jdstrand: wow, you are here :)
<tedg> jdstrand: Hmm, okay, must be messing something else up :-)
<zyga> tedg: no, but remember there are snap-run snap-exec there as well
<zyga> tedg: being in go they may do that in the runtime
<zyga> tedg: can you show me a reprouction test case?
<tedg> Uhg, yeah.
<tedg> Not really right now, I have things heavily modified to recreate it.
<zyga> jdstrand: hey, is there a chance for you to look at https://github.com/snapcore/snap-confine/pull/199 today
<mup> PR snap-confine#199: Add error support code <Created by zyga> <https://github.com/snapcore/snap-confine/pull/199>
<zyga> tedg: even a small test case I can run locally would be great
<zyga> tedg: e..g something hacked in shell
<tedg> zyga: Let me chase down a couple other threads first, might be me screwing things up as well.
<mup> Bug #1646625 opened: on first boot rpi2 cannot configure (core16) <Snappy:New> <https://launchpad.net/bugs/1646625>
<zyga> tedg: that's ok, it's pretty late for me anyway, if you share something I can tinker with I'll try to help you out tomorrow
<jdstrand> zyga: looking at that PR I would want to spend some time with it (more than I have this afternoon). I can look at it first thing tomorrow
<jdstrand> zyga: if you need it sooner, perhaps tyhicks could look at it, but I don't know what he has going on
<zyga> jdstrand: thanks, if you want more context look at https://github.com/snapcore/snap-confine/branches (specifically https://github.com/snapcore/snap-confine/tree/arguments )
<zyga> https://github.com/snapcore/snap-confine/commit/a84be35d70be79b6f92dd192d40a82f6f0717856
<zyga> this patch
<jdstrand> zyga: what is the motivation of this patch?
<tyhicks> zyga: hey - those look a little more like code churn than a PR that we should drop other stuff and review today
<tyhicks> maybe I'm missing something
<tyhicks> (it is really nice to have non-fatal error message handling)
<zyga> tyhicks: it's okay, you don't have to review it today
<jdstrand> tyhicks: well, fatal message handling has the nice benefit that you know you fail closed
<zyga> jdstrand: argument parsing is going to grow a little and I didn't want to add more hackery to main()
<zyga> jdstrand: and I wanted to write code that can follow one style of error handling and die()/death in proper places
<tyhicks> jdstrand: that's true
<zyga> jdstrand: and lastly I wanted something that can be unit tested a little bit better
<jdstrand> zyga: what arguments are being added?
<zyga> jdstrand: --classic
<zyga> jdstrand: but I be we'll need more soon
<zyga> jdstrand: e.g. --base to switch base snaps
<zyga> jdstrand: perhaps --revision to not care about current symlinks
 * zyga EODs
<zyga> good night everyone
<mup> PR snapcraft#937 closed: Incorporate all part properties into state tracking <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/937>
<mup> PR snapcraft#937 opened: Incorporate all part properties into state tracking <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/937>
<mup> Bug #1545871 opened: Be able to query with multiple terms <Snappy:New for chipaca> <https://launchpad.net/bugs/1545871>
#snappy 2016-12-02
<miken> bitpushr: Hi there. I was just investigating a question you had earlier about ssh access.
<miken> bitpushr: afaict, once the first-boot script completes successfully, it's not possible to re-trigger the ssh import.
<miken> bitpushr: Re-flashing so you can re-run the first-boot process is the only option I'm aware of, sorry :/ ( mwhudson may know more, but he's on leave atm).
<mup> Bug #1572038 opened: snap find doesn't find partial names <Snappy:New> <https://launchpad.net/bugs/1572038>
<mup> Bug #1606539 opened: handler errors from `snap create-user` gracefully <Snappy:New> <https://launchpad.net/bugs/1606539>
<mup> Bug #1572038 changed: snap find doesn't find partial names <Snappy:Fix Released> <https://launchpad.net/bugs/1572038>
<mup> Bug #1593989 opened: snap installed .desktops collide with .deb installed .desktops in unity7 <Snappy:New> <https://launchpad.net/bugs/1593989>
<lutostag> hey all, ran into an issue installing lxd on core-16. I can't create the lxd group that it needs
<lutostag> any way to do that?
<mup> PR snapcraft#941 opened: Support symlinks within deb sources <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
<mup> PR snapcraft#930 closed: parser: support remote dependencies <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/930>
<mup> PR snapcraft#932 closed: cli: implement `enable-ci travis --refresh` command <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/932>
<mup> PR snapcraft#939 closed: Replace coveralls with codecov <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/939>
<mup> PR snapcraft#942 opened: store: return specific error when already owned <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/942>
<mup> PR snapd#2397 opened: interfaces: add iio <Created by lpotter> <https://github.com/snapcore/snapd/pull/2397>
<foxmask> bonjello
<dholbach> hey hey
<seb128> hey dholbach!
<dholbach> hey seb128
<seb128> dholbach, happy friday!
<dholbach> and the same to you :)
<didrocks> happy Friday dholbach :)
<dholbach> hey guys :)
<zyga> tvoss: hey
<zyga> tvoss: just finishing something on the arg parsing side and then going back to feedback from reviews
<tvoss> zyga: good morning :) sounds good to me
<jibel> fgimenez, morning, did you look into the autopkgtest failure of snapd on zesty/ppc64el? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd
<fgimenez> hi jibel, nope, i think that mvo has been tackling it
<jibel> fgimenez, and is he looking into the failures in xenial too?
<jibel> fgimenez, we'd need 2.18 in proposed if there is a release of 2.19 next week
<fgimenez> jibel, not sure but i think so, he can confirm
<mup> PR snapcraft#943 opened: Replace subTests with TestScenarios <Created by elopio> <https://github.com/snapcore/snapcraft/pull/943>
<gerry_> hello, My app is in gnome software but today I log on there and there are two versions of my app on there is it something I have done wrong?
<zyga> gerry_: can you look at /var/lib/snapd/desktop/applications/
<zyga> gerry_: are there multiple desktop files for your app there?
<gerry_> zyga: no just one but it has the icon of the one that appeared in gnome-software today
<zyga> gerry_: I suspect that what you see then is a glitch in the gnome-software then
<zyga> gerry_: can you report that and attach some screenshots perhaps
<zyga> gerry_: maybe you see your app in the store and your app locally installed
<zyga> gerry_: and those are separate for some reason (no idea really, not my area of expertise)
<zyga> morphis__: hey
<zyga> morphis__: how's projects?
 * zyga fixed some tests and runs spread to verify
<zyga> gerry_: for gnome-software you want to find robert ancel AFAIK
<morphis__> zyga: hey!
<morphis__> zyga: you mean any specific ones :-)
<gerry_> zyga: ok thank you very much for your help
<zyga> morphis__: in general, are things going OK?
<zyga> gerry_: his IRC nickname is robert_ancell
<zyga> (double l, sorry for getting that wrong earlier)
<zyga> gerry_: you may have better luck finding him earlier though as he is from new zeland
<morphis__> zyga: yeah, so far everything is fine :-)
<morphis__> zyga: you got the problem with the content itnerface fixed already?
<zyga> morphis__: do you mean the multiple entries or something else?
<zyga> morphis__: the content interface is not broken AFAIK but needs new features to support some interesting use cases
<zyga> morphis__: that bug you spoke about at a call a while ago is fixed
<zyga> morphis__: (and the other one as well, I updated LP bugs)
<gerry_> zyga: just one thing the one that has appeared today has "*3rd party" on it where as the my entry does not have that?
<morphis__> zyga: ah good, yeah especially the use case to share a local socket was of interest for us
<morphis__> zyga: which snapd/snap-confine do we need to get that working?
<zyga> gerry_: that's a gnome-software tag, I would recommend that you file bugs on snappy / gnome-software for each of those that feels wrong to you; some are missing features, some are OK but need to be explained (bugs can be converted to questions that can show up in a FAQ on launchpad)
<zyga> morphis__: that should work, I didn't try it myself but the code looks fine
<zyga> morphis__: I think .44
<zyga> morphis__: maybe earlier but I'd have to check tags
<morphis__> zyga: ok, so nothing which is in stable yet, right?
<zyga> morphis__: actually
<zyga> morphis__: it's a snapd fix and it might be out now
 * zyga looks
<zyga> because that side was in snapd
<zyga> morphis__: can you just try, use $SNAP_DATA as described there: https://github.com/snapcore/snapd/wiki/Content-Interface
<morphis__> zyga: ah ok, let me try that then
<zyga> morphis__: and feel free to edit that wiki
<zyga> morphis__: really, it is very useful if you do
<morphis__> zyga: oh I see, I can do that
<morphis__> zyga: can everyone?
<zyga> morphis__: yes
<zyga> :)
<zyga> it's a wiki!
<morphis__> good :-)
<zyga> morphis__: I should link it to the interfaces page
<zyga> morphis__: I'll do that shortly
<morphis__> ok
<morphis__> zyga: btw. you saw my replies on https://bugs.launchpad.net/snappy/+bug/1646415 ?
<mup> Bug #1646415: cannot run configure hook <Snappy:Invalid> <https://launchpad.net/bugs/1646415>
 * zyga looks
<zyga> no, not yet
<zyga> hmm, odd
<zyga> I looked at the code and we parse hooks in meta/snap.yaml
<zyga> I bet you really need that hook to be defined there
<zyga> maybe something is out of sync
<zyga> I'll check with gustavo
<zyga> or maybe
<zyga> pstolowski: ^^ do you know?]
<zyga> the person who is on the hook about hooks :)
<pstolowski> :)
<pstolowski> looking
<seb128> hum
<seb128> are launchpad snap builds on yakkety know to be buggy?
<seb128> "W:GPG error: http://ppa.launchpad.net/snappy-dev/tools/ubuntu yakkety InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F1831DDAFC42E99D, E:The repository 'http://ppa.launchpad.net/snappy-dev/tools/ubuntu yakkety InRelease' is not signed."
<seb128> cjwatson, ^  you might know?
<ogra_> seb128, at the start of the build ? thats normal iirc
<ogra_> (the build finishes properly, right ? )
<seb128> ogra_, no, the build errors out on that after trying to install the build-packages
<seb128> https://launchpadlibrarian.net/295822697/buildlog_snap_ubuntu_yakkety_amd64_ghex-udt_BUILDING.txt.gz
<seb128> ogra_, ^
<ogra_> well, if you look at the top of the log you see the exact same which passes
<seb128> that same branch was building fine on xenial
<pstolowski> morphis, zyga the hook-example looks good. having meta/hooks/configure is enough. we have similar spread tests
<seb128> I just tried to change to yakkety and now got that
<seb128> ogra_, do you know if I'm doing something wrong there and what?
<ogra_> i guess because not all packages are in the PPA for yakkety
<seb128> but I'm not building using a ppa
<seb128> I selected to build from the archive
<seb128> so I guess it's a launchpad setup issue?
<ogra_> yeah, i wonder what it tries to pull from there
<pstolowski> morphis, zyga I can look at this later today
<zyga> pstolowski: thank you, if you are right then snap.Info may lie sometimes :/
<pstolowski> zyga, i think we would see these spread tests fail. so not sure what's wrong
<zyga> pstolowski: spread test may not fail even if what I said is true
<pstolowski> zyga, hmm why not?
<mup> PR snapcraft#942 closed: store: return specific error when already owned <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/942>
<zyga> pstolowski: if the hook manager is not using hook info from snap info, for example
<Trevinho> ralsina: hey, when do you think this commit https://github.com/snapcore/snapcraft/commit/6c012194bde will hit the snapcraft server (or, can it backported now ;-))?
<ralsina> Trevinho: I don't work on snapcraft :-)
<ralsina> Trevinho: so, I hope soon, if you need it!
<Trevinho> ralsina: yeah, but.... Didn't you manage that server or what (IIRC some days ago you got pinged to restart the job)?
<Trevinho> and I don't know how the server-side is managed (if it's just using zeisty or a snapcraft ppa)
 * zyga hugs dholbach 
<ralsina> Trevinho: not really
<Trevinho> oh, ok... so sorry.
<ralsina> Trevinho: but I can ping the right people. What's the change server side? That link points to snapcraft code
<Trevinho> ralsina: that commit should be included
<ralsina> Trevinho: you showed a link to a PR in snapcraft, that's client-side code, not server-side
<Trevinho> ralsina: no, it's not...
<Trevinho> ralsina: it's all shared code
<ralsina> Trevinho: the store is lp:software-center-agent, it's a whole different project
 * ralsina -> school run bbl
<Trevinho> ralsina: oh, wait... I meant a different thing then... this: https://parts.snapcraft.io/v1/parts.yaml
<Trevinho> (the generator of that)
<cjwatson> seb128: https://bugs.launchpad.net/launchpad/+bug/1626739
<mup> Bug #1626739: Snapcraft build failing in Yakkety for unauthenticated stage-packages <launchpad> <snap> <Launchpad itself:New> <https://launchpad.net/bugs/1626739>
 * dholbach hugs zyga back
<zyga> dholbach: visit spain sometimes, great places to see, great food, great weather, sun and no snow :)
<dholbach> :-)
<mup> PR snapcraft#938 closed: store: return specific error when already owned <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/938>
<ralsina> Trevinho: ahhhhh parts, no idea about that, never touched it
<Trevinho> ralsina: sorry for bothering you then... :-)
<ralsina> Trevinho: np
<sergiusens> Trevinho that was roadmr
<Trevinho> sergiusens: yeah, I figured just two seconds after... :-D
<ralsina> hahaha
<Trevinho> I remembered the nickanme started with "r"... :-P
<Trevinho> and since I know ralsina does serverside stuff.... :-P
 * Trevinho is terrible with names... Sorry :-)
<ralsina> Trevinho: it happens :-)
<zyga> mv roadmr r-server-side-stuff
<zyga> mv ralsina r-server-side-stuff
<zyga> aww, clash
<Trevinho> lol
<Trevinho> no, we're in a snappy world... That can't happen!
<ralsina> Hell, I do touch some server-side-stuff so I just assumed I had forgotten about it
<zyga> maybe you want a round-robin queue?
<nottrobin> I get pinged every time someone mentions round-robin
<nottrobin> I didn't even know what it was to start with
<nottrobin> :D
<nottrobin> as you were
<Elleo> snapcraft's failing for me with an error about held broken packages when it tries to fetch the stage packages; is there any way to get it be more verbose and tell me which packages are causing the issue? running with -d didn't help
<zyga> Elleo: while this is totally different from what you may expect try opening a second terminal and run forkstat there
<zyga> the output should tell you what apt is doing and may give you a hint of what is going wrong
<seb128> cjwatson, thanks, am I reading correctly that there is no workaround suggestion atm?
<Elleo> zyga: okay, thanks
<cjwatson> seb128: I don't think I have anything at the moment, unfortunately, short of not using stage-packages
<cjwatson> (which is not really a workaround!)
<seb128> cjwatson, right, I was going to say that I kind of need those...
<mup> PR snapd#2398 opened: cmd/snap: change terms accept URL following UX review <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2398>
<seb128> well, back on using xenial for now I guess, I might try to backport things to a ppa on top to workaround
<cjwatson> I forget quite why it only affected yakkety
<cjwatson> or post-xenial I guess
<Elleo> zyga: nothing obvious there, it does a bunch of stuff with apt-key presumably checking signatures when updating, starts a few apt/method/http threads and then stops
<zyga> well, it was a long shot
<Elleo> zyga: I don't get any errors installing other packages on the host system normally, but it looks like oxide is being held for some reason
<cjwatson> seb128: it's definitely fixable, just a bit complicated because we need to bite the bullet and finally start sending public key material to builders; chances of me getting to it this year are low :-/
<seb128> cjwatson, don't worry, it would be nice if it worked but it's not really blocking anything that needs to land from our side, we just wanted to try to provide gtk apps based on the yakkety gtk version to xenial users, but we can backport the new gtk to xenial in a ppa for that
<ogra_> cjwatson, why is that PPA enabled at all ? there is nothing relevant in it
<ogra_> (neither for xenial nor for yakkety)
<ogra_> imho we could just completely drop it and be done
<cjwatson> ogra_: until the next time we need it
<ogra_> hmm
<cjwatson> it was definitely needed pre-xenial
<ogra_> seems the last time was in 2015
<ogra_> (looking at the packages in there)
<cjwatson> and it's very useful to have that kind of facility available
<ogra_> true indeed
<cjwatson> right, it was absolutely necessary pre-xenial because the archive didn't have snapcraft
<cjwatson> in the future y'all might well decide that you want a newer version of snapcraft used by LP regardless of what's in the distribution
<cjwatson> this is how we do that kind of thing
<ogra_> yeah, understood
<mup> PR snapd#2399 opened: Add /dev/uhid to bluetooth-control interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2399>
<zyga> morphis__: hey, remember that configure bug, can you tell me whicih version of snap-exec you have in you core
<zyga> which*
<zyga> morphis__: is that in a core or classic system?
<zyga> morphis__: gustavo just made me realise that without sufficiently up-to-date core snap and snap-exec you won't get it to work
<renato__> jdstrand, could you approve camera-app package? https://myapps.developer.ubuntu.com/dev/click-apps/5990 vr 7 and 8
<mup> PR snapcraft#926 closed: sources: add current dir to ignore list if we're iterating on parent <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/926>
<zyga> jdstrand: hey
<zyga> jdstrand: we will deny --jailmode or --devmode when --classic is passed
<zyga> jdstrand: I'll make the patch after lunch
<zyga> jdstrand: classic confinement seems to work for me locally :)
<zyga> jdstrand: I could use a few reviews, I think it can all land toda
<morphis__> zyga: I am using 2.18 here from the core snap from candidate
<morphis__> its a classic system with SNAP_REEXEC
<zyga> morphis__: in a core system or on classic?
<morphis__> zyga: however lorn was trying it with 2.17.1 from the ubuntu image ppa on classic
<zyga> morphis__: ah, snap-exec doesn't use reexec
<zyga> that's one of the things we'll fix later
<morphis__> zyga: but for me with SNAP_REEXEC and 2.18 the configure hook is working well
<morphis__> zyga: just for lorn it is 2.17.1 from the ppa without SNAP_REXEC and there it isn't working
<jdstrand> roadmr: hi! fyi, r807 supports classic. I've got another unrelated bug I'd like to fix, but feel free to pull 807 if that works for you timing-wise
<zyga> jdstrand: we have a streak of holidays and release next week, could you have a look at one essential part of snap-confine that's there for classic quickly
<jdstrand> tedg, renato__: fyi, that ^ also has the unity8 workaround you asked for
<tedg> jdstrand: Great!
<zyga> jdstrand: essentially this: https://github.com/snapcore/snap-confine/commit/43f5041deb8ed061f8a38f4342a5c3065b8ec3cf
<jdstrand> zyga: are those what you asked for earlier today?
<tedg> Is anyone else able to build snaps on LP?
<tedg> Seems I'm getting parts update errors.
<zyga> jdstrand: it's piled up there, I didn't open PRs since github makes those uber long when stacking branches
<renato__> tedg, I built camera some minutes ago
<zyga> jdstrand: but this is the essence, regardless of argument parsing changes (if we do the cheap way or if we do the full way)
<renato__> tedg, try again. I got that in one of the builds but worked nice on the second try
<jdstrand> zyga: can you give me a prioritized list of what must be reviewed today?
<renato__> jdstrand, thanks. I am happy to not disturb you with reviews :D
<zyga> jdstrand: this is the essential patch, everything else is optional
<jdstrand> ok
<renato__> jdstrand, btw. My eds/unity8-pim is ready for review :D
<zyga> jdstrand: if you +1 I'll land it without the intermediate argument parsing and error improvements
<jdstrand> renato__: ack (I have it on my list already, might be today but maybe early next week)
<renato__> jdstrand, thanks,
<jdstrand> renato__: approved
<jdstrand> zyga: fyi, the commit message is not quite right. I think you mean "to essentially switch the sandbox off entirely"
<zyga> jdstrand: yes, good catch
<zyga> jdstrand: I'll correct that before it lands
<roadmr> jdstrand: oh awesome! sure, I'll put that in the pipeline (but not smoke it) (pretty sure I've used this joke before)
<jdstrand> roadmr: hehe
<jdstrand> zyga: this is totally unimportant and unrelated to this PR, but in snap-confine.c you have
<jdstrand> #ifdef HAVE_SECCOMP
<jdstrand>   sc_load_seccomp_context(seccomp_ctx);
<jdstrand> #endif
<jdstrand> zyga: but for apparmor you have:
<jdstrand>   sc_maybe_aa_change_onexec(&apparmor, security_tag);
<jdstrand> zyga: and the ifdef for HAVE_APPARMOR is in sc_maybe_aa_change_onexec()
<jdstrand> zyga: why not just:
<jdstrand> zyga: why not just in snap-confine.c:
<jdstrand> #ifdef HAVE_APPARMOR
<jdstrand>   sc_aa_change_onexec(...)
<jdstrand> #endif
<jdstrand> ?
<jdstrand> zyga: basically, the 'maybe' caught me eye while doing the review :)
<jdstrand> my*
<mup> PR snapd#2400 opened: snap: support for parsing and exposing on snap.Info aliases <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2400>
<mup> PR snapcraft#943 closed: Replace subTests with TestScenarios <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/943>
<zyga> jdstrand: because that gets rid of the extra ifdef
<zyga> jdstrand: and maybe apparmor is not enabled on boot
<jdstrand> zyga: I'm not saying get rid of the ifdef. I'm asking why it isn't in hte same place as the seccomp one
<jdstrand> zyga: or, why not put the seccomp one in sc_maybe_load_seccomp_context(...)
<jdstrand> ?
<zyga> jdstrand: because seccomp leaks the types around, I may return to it and to the same though
<zyga> jdstrand: I wasn't touching seccomp lately :)
<zyga> jdstrand: I plan to unify the code when we have more review time
<jdstrand> zyga: it isn't important. I just thought it odd that the ifdef was in one place for seccomp and in another for apparmor
 * zyga -> quick break for lunch 
 * zyga nods
<jdstrand> zyga: what is important is I reviewed the patch you asked me to :)
<jdstrand> zyga: just a request for a comment. also thanks for the --devmode/--jailmode update :)
<mup> PR snapd#2401 opened: snap: abort install with ctrl+c <Created by stolowski> <https://github.com/snapcore/snapd/pull/2401>
<tedg> cjwatson: sergiusens: Seeing some build errors that looks like snapcraft can't update its parts. Happening on other snaps too, but here's an example: https://code.launchpad.net/~ted/+snap/unity8-session-xmir-preload
<tedg> I can update parts locally, so I don't think that's an issue.
<tedg> Not sure what else to try to debug it.
<cjwatson> Hm, I wonder why that would have changed.
<cjwatson> Actually, I'm not sure that has anything to do with parts.
<cjwatson> tedg: The actual error is from apt.  I think it's just that a parts update happened to be right before it.
<cjwatson> My guess would be that the set of packages pulled by the unity8 part is in fact not coinstallable when pulled from that PPA.
<cjwatson> It's a little hard to tell, but hopefully cleanbuild would reproduce the same thing if you gave it an appropriate set of apt sources.
<tedg> Oh, I figured it was a generic error message left over from converting things over to snap building :-)
<tedg> Hmm, okay. I'm not sure what could have happened there, but a lot of people pushing into that PPA.
<tedg> Thanks cjwatson !
<zyga> jdstrand: thank you, checking now
<zyga> jdstrand: wooooot
<zyga> jdstrand: thanks :)
<bartbes> quick question, are the XDG_* environment variables already set based upon SNAP_USER_DATA, or do I have to make sure I do that myself?
<ogra_> easy answer: .... it depends
<ogra_> :)
<bartbes> I'll just set it myself, then :P
<ogra_> there are desktop launcher parts you can use ...
<ogra_> if you use them, they set these vars
<ogra_> if you dont, you need to set them yourself ...
<ogra_> you can check whats set by installing hello-world
<ogra_> and then running hello-world.env
<ogra_> it will print the default environment the hello-world binary sees
<ogra_> your snap would see something similar
<bartbes> right
<zyga> bartbes: you don't have to do anything, we set $HOME and software correctly derives the rest
<bartbes> well, if XDG_DATA_HOME is unset, yes
<ogra_> zyga, well, we dont explicitly set XDG_ vars, do we ?
<jdstrand> zyga: fyi, all the 'pc' gadget uploads you did are approved and just need you to press the publish button
<ogra_> only the desktop launchers do
<jdstrand> zyga: I also fixed the issue in the review tools that made it get hung up (requested a store pull, but that probably won't happen til next week)
<bartbes> ogra_: the spec says it's derived from HOME if it isn't set
<ogra_> well, all i know is that the launchers set it based on $HOME, i wasnt aware it is set by something else now
<ogra_> (if it actually is)
<jdstrand> bartbes: that's right. as such you don't need to set them. HOME is set to ~/snap/$SNAP_NAME/$REVISION and so your snap will use ~/snap/$SNAP_NAME/$REVISION/.config, ~/snap/$SNAP_NAME/$REVISION/.cache, etc
<bartbes> ogra_: no, applications need to default to $HOME/.local/share themselves if $XDG_DATA_HOME isn't set
<ogra_> jdstrand, how  if the XDG_ vards arent filled at all and the app looks for them
<jdstrand> we will start setting XDG_RUNTIME_DIR in snapd
<ogra_> ah
<jdstrand> ogra_: because the toolkits follow the spec
<bartbes> jdstrand: you know, if they weren't set to begin with, anyway, I want it to be $SNAP_DATA_COMMON, since the information isn't version-specific
<bartbes> so it doesn't matter, I need to write a wrapper anyway
<jdstrand> bartbes: well, perhaps, but we wouldn't want to diverge from the spec I don't think (that was a conscious decision). we could arguably set HOME to SNAP_USER_COMMON, but that feels a little weird. you are always free to set XDG_... to SNAP_USER_COMMON if that is appropriate for your snap
<bartbes> that's perfectly sensible
<bartbes> I'm doing something weird anyway
<zyga> ogra_: we don't but software should not set it either as libraries typically do that
<zyga> jdstrand: the store issue that affected the pc gadget snap?
<ogra_> aha
<ogra_> (and i thought desktop envs usually set it on startup :) )
<attente> elopio: hey, could you take a look at why the clone is failing on this integration test on github c-i? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-snapcraft-daily/zesty/amd64/s/snapcraft/20161201_214708_59c43@/log.gz
<barry> hi all.  is there documentation on snap recipes in launchpad?  i'm having a hard time finding it on help.launchpad.net or snapcraft.io
<zyga> jdstrand: this is something I mentioned before a few times; the CE team would love if this landed for their devmode testing snaps. Can you eyeball it quickly (the function has like five syscalls inside) and give me some feedback. I didn't tweak the apparmor profile yet. https://github.com/snapcore/snap-confine/commit/b36fe6c334ca70166a7def06ba4418a764af492e
<zyga> cwayne: ^^
<cwayne> zyga: <3
<cwayne> zyga: jdstrand: this is actually pretty critical to testing our projects
<zyga> cwayne: sorry for starving it for so long
<cwayne> zyga: no worries, totally understand how swamped you guys are :)
<jdstrand> zyga: I don't know what store issue you are referring to. I saw that the pc gadget snap was stuck in manual review. I approved it and fixed the review tools trunk so that won't happen again, but that hasn't landed in the store just yet
<zyga> jdstrand: yes, that's what I was thinking about with the pc gadget snap
<zyga> jdstrand: thank you for fixing that!
<zyga> jdstrand: (those are auto built now as you probably know :)
<zyga> jdstrand: the store issue was that the gadget snap required to have i386 elf binaries for i386 and I believe this is what you fixed
<mup> PR snapd#2402 opened: debian: disable autopkgtests on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/pull/2402>
<barry> the question i am trying to find documentation on is whether we can target zesty as the primary archive for automatic launchpad builds.  i am building ubuntu-image, but i remember reading somewhere (that i can't find now) that only xenial is supported, but that won't work for us because we need e2fsprogs from >=yakkety
<renato__> sergiusens, would be nice if the "apps" section of the snapcraft file we could set environment variables to each app. Something like environment:"OXIDE_NO_SANDBOX=1;MY_APP_VAR=True"
<renato__> this will avoid create a wrapper file just to export vars
<zyga> renato__: I believe you already can
<zyga> renato__: we spent lots of time connecting the docs to make that owrk
<zyga> renato__: may be disabled but we technically can now
<zyga> I don't remember, sorry
<renato__> zyga, \o/ this is great, just need to figure out which syntax I should try
<zyga> renato__: disclaimer, it may not be enabled at some layer yet but we definitely planned this for a long time so ask sergiusens
<renato__> zyga, thanks
<zyga> jdstrand: hmmm, snap confine oopses the kernel
<zyga> jdstrand: I guess we're pushing the boundaries
<zyga> jdstrand: https://pastebin.canonical.com/172640/
<zyga> jjohansen: ^
<tyhicks> zyga: that's a bad strlen call so just a plain ol' bug (not pushing any limits)
<tyhicks> zyga: can you file a bug with reproducer instructions?
<zyga> tyhicks: against the kernel package?
<tyhicks> zyga: yes, the linux source package
<zyga> ay, will do
<pmcgowan> should there be a direct mapping between implicitClassicSlots and what is marked transitional on the interfaces page? as there is not and I cannot grok the criteria
 * zyga doesn't kow
<zyga> know*
<jdstrand> tyhicks: hey, is that something that is known? ^
<tyhicks> jdstrand: I've not seen it before - does it look familiar to you?
<jdstrand> no
<pmcgowan> jamiebennett, any idea on my interfaces query above
<mup> Bug #1646881 opened: Enable pre-caching of snaps in a classic chroot <cpc> <Snappy:New> <https://launchpad.net/bugs/1646881>
<zyga> jdstrand: how can I discard any profile I may currently have?
<pmcgowan> perhaps its that the interfaces will be provided by other snaps in all snaps world so its not transitional
<zyga> jdstrand: I think that oops above is related to the fact that snap-confine is invoked from snap-confine
<zyga> Dec 02 16:51:13 xenial-server audit[78188]: AVC apparmor="ALLOWED" operation="capable" profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine//null-mount-namespace-capture-helper" pid=78188 comm="snap-confine" capability=19  capname="sys_ptrace"
<zyga> this shows up just before the oops
<zyga> the "null"s there seem wrong
<gerry_> hi all, I uploaded a screenshot to " my apps" but it does not appear in gnome software ?
<zyga> gerry_: I believe there's a bug about that already
<bartbes> I installed a snap in devmode, but it still can't connect to either my x session or to opengl, do I need to do anything special, except list the plugs?
<zyga> bartbes: no, you should be fine, what is the error you are seeing and how are you launching your app?
<gerry_> zyga: oh ok sorry to bother you all
<bartbes> it's an error by the application itself, from sdl: "No available video device"
<zyga> gerry_: no worries
<bartbes> and it happens both when using snap run, or launching it using the /snap/bin file
<bartbes> though it doesn't without any sandboxing, because if I run it directly it does work
<bartbes> it doesn't need to contain a libGL does it?
<zyga> bartbes: are you using nvidia propietary drivers?
<bartbes> can I attach a debugger, or get a shell, maybe?
<bartbes> yes
<zyga> bartbes: interesting
<zyga> bartbes: can  you look at: snap run --shell snap.app (replace with the right stuff)
<bartbes> on arch, I should probably mention
<zyga> bartbes: and look at /var/lib/snapd/lib/gl
<zyga> bartbes: do you see libGL there?
<zyga> ah
<zyga> on arch... hmm hmm
<zyga> I think that's a known issue for arch and certain version of the driver
<zyga> can you look at that directory
<zyga> and report which driver version you have
<bartbes> yeah, it's empty
<zyga> in any case, report a bug on snap-confine on launchpad
<bartbes> and the shell is kind of hard to use if I don't even have ls :P
<bartbes> it's version 375.20-3
<zyga> bartbes: exit that shell and look at /sys/module/nvidia/version
<zyga> bartbes: is it there? what does it contain?
<bartbes> that contains 375.20, unsurprisingly
<zyga> bartbes: when it runs outside of a snap, where is libGL.so
<zyga> bartbes: unfortunately distros differ on how they package nvidia drivers and there's some code that has to be maintained for each distro
<zyga> bartbes: the arch code is different from ubuntu entirely
<zyga> bartbes: perhaps something changed since and it needs updating
<zyga> bartbes: if oyu want to hack I can help you get started, maybe it's better now and something has been unified
<zyga> bartbes: maybe it's just a path that needs updating
<zyga> bartbes: nvidia support code is not under CI
<bartbes> /usr/lib/libGL.so is a symlink to /usr/lib/libGL.so.1 is a symlink to /usr/lib/nvidia/libGL.so.1 is a symlink to libGL.so.1.0.0
<zyga> bartbes: (on any distro)
<zyga> ah
<zyga> interesting
<zyga> that's different and indeed that would explain why it fails
<zyga> can you grab snap-confine source
<zyga> and patch one line
<bartbes> sure
<zyga> go to mount-support-nvidia.c
<zyga> and jump to line 49
<zyga> oh,
<zyga> and mabe as a second idea, compile snap-confine with --enable-nvidia-ubuntu
<zyga> just as a quick test
<zyga> as for recompiling with the same options as in current arch packaging please look at adding some globs there on line 49
<zyga> :/
<zyga> I'm sorry for this, my nvidia box is not usable lately and I don't test this actively on arch as a side effect
<ZenHarbinger> Quick question: I know that work is/was done for xdg-open on yakkety. I've installed the snapd-xdg-open deb, but how do I call xdg-open from my snap? I get that it is not found (in the PATH).
<bartbes> doesn't it follow the symlink?
<zyga> ZenHarbinger: you should just call xdg-open, I believe the shim xdg-open is in the core snap
<bartbes> or does it copy the symlink but not its target?
<zyga> ah, it seems not to be the case
<sborovkov> what's going on with ubuntu store? anyone knows? last few days it's super unresponsive. I constanly get 504 timouts when trying to publish new revision
<zyga> bartbes: can you report a bug on snapd for this please
 * zyga needs a break or a beer
<zyga> long day
<bartbes> oh, so it isn't snap-confine?
<jdstrand> zyga: discard a profile you already have? you don't want to do that
<jdstrand> zyga: I'm going to refer you to tyhicks on why the nulls are in that ALLOWED log entry. iirc, there were some bugs jj was looking at in this area, but I'm not up on the issue
<tyhicks> zyga: and I'm going to refer you to jjohansen - I'm not sure why they'd be there
<tyhicks> jjohansen: if you are too swamped to triage it today, let me know and I can dig through the code
<tyhicks> zyga: I think the most important thing we need from you is a reproducer
<bartbes> zyga: so what should I mention in my report, that I'm running arch with nvidia and /var/lib/snapd/lib/gl/ is empty?
<zyga> tyhicks: this is not urgent for today
<zyga> tyhicks: we can have a call to discuss this next week, perhaps faster than irc
<zyga> bartbes: yes, and the driver version and the location of the GL files in the tree
<zyga> bartbes: sorry I meant to reply to ZenHarbinger earlier
<bartbes> alright
<zyga> ZenHarbinger: can you report a bug on missing xdg-open in the core snap please
<zyga> tyhicks: the reproducer will take some time to create, I don't quite know what I did to make this happen (yet)
<zyga> I see two different versions of s-c being invoked (one from my tree, one from the core snap)
<tyhicks> zyga: ok, the stacktrace might be sufficient since I suspect that it is most likely strlen() being called on a bad address or an unterminated string
<tyhicks> zyga: in other words, don't spend personal time working on it
<zyga> ok :)
<zyga> tyhicks: looking there everything seems to be testing for non-NULL values but maybe it's just garbage, not null
<bartbes> zyga: oh, I just noticed /usr/lib/nvidia/libGL* is in libglvnd, which the snap-confine source claims is unsupported, so this is a known issue?
<zyga> bartbes: yes :-(
<zyga> bartbes: I failed to find a way to support that
<zyga> bartbes: if you can spend some cycles on this then this would be really appreciated
<bartbes> why doesn't it work?
<bartbes> isn't the libGL.so.1 that's pointed to just a valid libGL?
<zyga> bartbes: the lib-gl-vendor library is a shim that does dlopen on the real library based on some condition
<zyga> bartbes: you'd have to see what it does internally and what it takes to make the sandbox work with this
<zyga> bartbes: the glvendor thing feels like a good idea but just is more complicated to support
<bartbes> I hadn't heard of it before today
<bartbes> so I don't know how it got installed :P
<zyga> welcome to linux plumbing :)
<zyga> bartbes: it's a part of the nvidia driver stack now
<zyga> bartbes: and thank you for using snappy ::)
<bartbes> can't you just.. copy the entire thing?
<zyga> bartbes: you can do a few things but you have to make libglvndr find what it expects in the right spot
<zyga> bartbes: TBH nvidia support is one of the more hairy part of snap-confine
<zyga> tyhicks: yeah, looks like it explodes because of strlen
<zyga> tyhicks: but that implies the non-null pointer is garbage somehow
 * zyga is tempted to build a kernel with an extra printk
<zyga> it's friday and I could have my first kernel patch;
<bartbes> it looks like it just dlopens libGLX_<vendor>.so
<zyga> bartbes: the key question is -- where from
<zyga> bartbes: look at what the symlinks do
<zyga> bartbes: maybe what we need is to symlink the right /usr/lib/nvidia content, not sure
<bartbes> from the standard path, I managed to get it to load from somewhere else using LD_LIBRARY_PATH
<zyga> bartbes: remember that snaps don't run in the typical environment
<zyga> bartbes: snap-confine does lots of magic
<bartbes> oh, the "normal" one is in /usr/lib/libGLX_nvidia.so.0
<zyga> bartbes: one of thoe is pivot_root
<zyga> those*
<zyga> and / is different (it is the core snap or the ubuntu-core snap)
<bartbes> well, technically what it points to, which is the versioned one, but it loads the .0 using dlopen
<zyga> and your old / is in /var/lib/snapd/hostfs
<zyga> so the nvidia support code for arch puts a tmpfs in /var/lib/snapd/lib/gl
<zyga> and drops a bag of symlinks from there to /var/lib/snapd/hosfs/usr/lib/nvidia*
<zyga> the globs control those
<zyga> does that make sense?
<zyga> at runtime snapcraft-made wrapper file adds SNAP_LIBRARY_PATH to LD_LIBRARY_PATH
<zyga> and SNAP_LIBRARY_PATH contains /var/lib/snapd/lib/gl
<zyga> (and that's end of the magic)
<bartbes> I see
<bartbes> I've been poking about some more and I'm even more confused now
<zyga> bartbes: I'll gladly help if you have a question
<bartbes> so it turns out "both" "vendors" point to the same libGLX in the end
 * bartbes sighs
<bartbes> that said, it does look like it uses dlopen without a fixed path
<zyga> yeah, there's hope
<zyga> its just requires someone to follow the trail of calls to the end
<zyga> strace helps
<bartbes> aha, I figured out why it doesn't load
<bartbes> I tried to force it with LD_PRELOAD:
<bartbes> /bin/sh: error while loading shared libraries: libnvidia-tls.so.375.20: cannot open shared object file: No such file or directory
<zyga> ah
<bartbes> no wait, that may be because the preload is before library path
<zyga>     "/usr/lib/libnvidia-tls.so*",
<zyga> that's probably handled
<bartbes> anyway, it's time to eat dinner, I'll look into it some more afterwards
<zyga> thanks! stay in touch please
<kalikiana> zyga: Still there?
<kalikiana> I added rules for my fake /usr/bin as we talked about earlier this week, and it's mounted - but I can't execute anything from it
<kalikiana> Was wondering if you'd have some hint, I feel like I'm missing something
<kalikiana> /etc/apparmor.d/usr.lib.snapd.snap-confine: mount options=(ro bind exec) /snap/*/** -> /usr/**, /usr/bin/** ixr,
<kalikiana> /var/lib/snapd/mount/snap.ubuntu-sdk-ide.ubuntu-sdk-ide.fstab: /snap/ubuntu-sdk-ide/x14/bin /usr/bin none bind,ro,exec 0 0
<zyga> kalikiana: yes
<zyga> kalikiana: when you say you cannot execute anything, can you be more specific please
<kalikiana> In "snap run --shell" I can see my fake /usr/bin, but I get "bash: /usr/bin/pkexec: Permission denied"
<zyga> kalikiana: ah, right, that would be the base confinement not letting you run that specific executable
<zyga> kalikiana: some are allowed, some are not
<kalikiana> ls /usr/bin confirms that the files are there
<zyga> kalikiana: you won't get out of the sandbox with pkexec btw
<zyga> kalikiana: if you tell me more what you need to do I may be able to help you better
<zyga> kalikiana: yes but the process is confined and the confinement doesn't allow to run that particular binary
<zyga> kalikiana: you can look at dmesg | grep DENIED to confirm this
<kalikiana> zyga: That is fine, I just need to deal with the app "expecting" /usr/bin/pkexec but I don't actually need the functionality to be equivalent
<zyga> kalikiana: unfortunately you won't be able to do it this way but maybe there's a way
<zyga> kalikiana: put a symlink over /usr/bin/pkexec
<zyga> and make that symlink point to something benine that is allowed by the policy, e.g. /bin/true or maybe /snap/yoursnapname/current/fake-pkexec
<zyga> symlinks are "transparent" to apparmor, apparmor really only cares about the final path
<zyga> give that a try
<kalikiana> zyga: I don't get DENIED for pkexec
<zyga> kalikiana: maybe it's silent then, interesting
<zyga> kalikiana: give that a try though
<kalikiana> Hmmm not sure if I follow
 * zyga should rest a littlet
<zyga> little
<kalikiana> zyga: The pkexec is a shell script in my snap
<zyga> I'll be back in a few hours to check if my kernel built, if you leave me a message I'll respond
<zyga> kalikiana: right, the point is that your overlaid /usr/bin/pkexec _must_ be a symlink to something in $SNAP
<zyga> kalikiana: or something that is already allowed to execute
<kalikiana> zyga: How could I create that? I can't snap a symlink before I know the real path with its version..
<zyga> kalikiana: you can use current
<zyga> kalikiana: the symlink can be  "/snap/$SNAP_NAME/current/fake-usr-bin/fake-pkexec"
<zyga> kalikiana: just put the snap name for real
<mup> Bug #1642581 opened: Livepatch checkState: check-failed <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1642581>
<zyga> kalikiana: then adjust the fstab file to bind mount fake-usr-bin over /usr/bin
<kalikiana> Okay, that makes sense. Will try that
<kalikiana> Thanks
<bartbes> so that was fun, I figured out I was missing some X libraries
<bartbes> copied them over.. "*** stack smashing detected ***"
<zyga> bartbes: interesting, might be incompatiblity between libc in arch and the one in the core snap
<zyga> bartbes: would be good to check if the version are compatible and if there are any funny patches
<bartbes> and the system I built the binaries on, debian oldstable
<zyga> the way the userspace library that that is the "driver" sharing works is always at risk that this would happen
<zyga> ideally libc is stable and compatible but ... well
<zyga> it's all FOSS and patches
<bartbes> right, I presume this would be the arch nvidia driver, linked against the arch libc, and the libc available in the snap, which is the ubuntu core one
<bartbes> I wonder.. if I copy the new libc in..
<zyga> no but ... you can bind mount the arch libc
<zyga> as a quick test
<zyga> sudo mount --bind /lib/glibc-something-something /snap/ubuntu-core/current/lib/glibc-something-something
<zyga> replace ubuntu-core with core if you have that, or do both to be safe
<bartbes> same result
<bartbes> oh well, at least I tried
 * zyga hugs bartbes 
<zyga> thank you!
<bartbes> it's good to see you took the hard problem of portable binaries
<bartbes> and added confinement to it :P
<mup> Bug #1646912 opened: Snaps after an update disappear from the launcher <Snappy:New> <https://launchpad.net/bugs/1646912>
<zyga> bartbes: well, confinement is actually not a factor in this prolem
<bartbes> not in this particular problem
<zyga> bartbes: (of only nvidia didn't need a proprietary driver)
<zyga> bartbes: you were joking perhaps but I just wanted to clarify that
<zyga> bartbes: it's perectly possible to make this work but we'd have to put the driver into a snap
<zyga> bartbes: and assuming the kernel is OK, id all work
<zyga> bartbes: I was thinking about prototyping this but didn't have the time
<bartbes> I don't think you can put the driver in a snap, since they are tied to the kernel module versions
<zyga> bartbes: are they?
<zyga> bartbes: AFAIK the module is but not the userspace lib
<zyga> bartbes: the userspace lib is not something we rebuild and that's the problematic part
<bartbes> not sure, but when I update the drivers (both sides) and try to run something using gl after I tend to get version mismatch errors
<zyga> bartbes: interesting, maybe they share some cookie
<zyga> bartbes: it'd be good to have someone from nvidia to work with us on this
 * zyga gets back to resting, not looking at irc 
<cjwatson> elopio: did you ever get a chance to check whether the firewall fix from https://portal.admin.canonical.com/97657 improved matters for you?
<kalikiana> Hrm. I guess the symlink isn't possible, absolute or relative (../usr/bin): './parts/stubs/build/pkexec' is a broken symlink pointing outside the snap
<mup> PR snapd#2402 closed: debian: disable autopkgtests on ppc64el <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2402>
<larryprice> i'm attempting to use X from the lxd snap, but doing so generally requires bind-mounting /tmp/.X11-unix from the host to the container
<larryprice> however there is no /tmp/.X11-unix in my snap's fs
<larryprice>  is something mounting over /tmp so an unconfined snap can't access? is there any way around this?
<bartbes> to the former: yes
<jjohansen> zyga: have you opened a bug for your strlen oops yet?
<larryprice> bartbes, thanks for the confirmation. so there's no way to access anything in /tmp on the system from a snap?
<bartbes> I'm not sure, I only found this out during debugging earlier
<ali1234> i have a question
<ali1234> if you make a snap containing a web app, how do you use it on a vhost?
<ali1234> for example wordpress
<ssweeny> you'd probably want something like nginx in front of it acting as a proxy
<ali1234> so that is not automated?
<ssweeny> it depends on the packager what they include
<ssweeny> you could include a copy of nginx or use the distro version
<ssweeny> or a separate snap of nginx that points to your wp snap :)
<ali1234> including a copy of nginx doesn't help
<ali1234> suppose i have bought three domain names, foo.com, bar.com, baz.com
<ali1234> i want to run separate wordpress instances on foo.com and bar.com, and rocket chat on baz.com
<ali1234> and i only have one dedicated server
<ali1234> how do i do that, using snaps?
<ssweeny> see for example how nextcloud does it: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml
<ssweeny> they include apache and everything needed to run nc on its own
<nacc> ali1234: snaps are very different in this regard, IMO
<ssweeny> you could on top of that have something like nginx proxying requests to that apache instance
<nacc> and you'd probably need something like that, to handle the port issues you run into with having multiple webservers running (potentially)
<nacc> *that being what ssweeny is describing
<ali1234> yes
<ali1234> so i would end up needing multiple apache installs
<nacc> well, each app would have its own
<ali1234> then i would have to manually configure nginx to proxy them all?
<ssweeny> that's one way to do it
<ssweeny> easy enough if not terribly efficient
<ali1234> is there a way to do it where all i have to do is install things and then it just works?
<ssweeny> you could also roll your own snap with wp, rocket.chat, and apache with the apache config set
<ali1234> that doesn't seem like it would have any benefit over just installing it the old way
<ssweeny> confined apache alone seems worth it :)
<ali1234> not really, not if it is the only thing running on the server
<nacc> ali1234: i think you misunderstand what confinement gets you, potentially
<nacc> ali1234: it doesn't matter that there are or aren't other things running on the server, really
<ali1234> confinement isn't the problem i am trying to solve though
<ali1234> the problem i am trying to solve is that every web app has different weird requirements that conflict with each other
<nacc> which snaps help solve :)
<ali1234> but only if you put each thing into a different snap
<ssweeny> right
<nacc> ali1234: not sure what you're arguing is the alternative?
<ali1234> it's not the alternative. what i do now is instal things from source in /usr/local
<ali1234> it ends up a huge mess
<ssweeny> right so snaps will still help there since you only have to build each piece once and they won't interfere with each other
<ali1234> yeah
<ssweeny> there's just a bit of configuration on top to get them to cooperate, which can't be harder than what you're doing now
<ali1234> so what i would like to do is install web app snaps and then use "snap connect" to connect them all to my web proxy snap (which might be nginx, or might be something else)
<ali1234> through a standard interface
<ali1234> rather than manually writing an nginx config file
<ali1234> this kind of crosses over with juju at this point
<ali1234> but this is something juju never really seemed to be able to do either
<nacc> ali1234: well, your web proxy snap would then have that config file, basically, or understand how to handle `snap connects` to it sslots?
<ali1234> yes
<ali1234> the web proxy snap would have a config file which lists all the domains/vhosts
<ali1234> then from that it would auto generate a list of interfaces
<ssweeny> a "web-proxy" slot would be interesting I think but I don't know if there's anything close to that implemented now
<ali1234> and i'd connect the web apps to them
<ssweeny> close to that conceptually I mean
<ali1234> yeah that's it
<ssweeny> mostly what interfaces do now is mediate access to files and dbus communication
<nacc> you'd also have to give that connection more information
<nacc> like what port  to proxy to what port, etc
<ali1234> no
<ali1234> it would proxy whatever you connect it to
<nacc> ok, that could be the plug you defined
<ali1234> the only information you would give it on the nginx side is what domain name and port to listen on
<ali1234> yes
<nacc> ali1234: i think you took me too literally, i mean you'd have to define that as part of the connect-interface
<ali1234> the port that the web app internally runs on should be dynamically chosen to avoid conflicts
<ali1234> i see, yes
<nacc> ali1234: aiui, everything you're saying doesn't exist yet, but I've not tried recently
<ali1234> can you connect multiple snaps to the same mysql snap?
<ali1234> that seems like a similar problem, if the mysql snap has a configurable port
<nacc> ali1234: again, i don't think that's how connect works currently
<nacc> ali1234: e.g., nextcloud bundles its own mysql in the snap
<nacc> ali1234: also, putting those connections between snaps, i wonder, if it runs a bit contrary to avoiding dependency hell. What happens when the mysql snap gets updated? How do you know your app is compatible?
<nacc> (just thinking out loud0
<ali1234> um... because its mysql
<ali1234> can you install two copies of the same snap at the same time, with different configuration?
<ssweeny> right, currently if your app is tightly coupled to another piece of software you're better off including it
<ali1234> mysql has a well defined interface, it is not tightly coupled
<nacc> ali1234: you can't install 'two copies' of a snap on the same system
<nacc> afaik
<ssweeny> there is some effort going on now with "framework" snaps like Qt, but it's still early days
<nacc> ssweeny: cmiiw, please!
<ssweeny> right, one snap one version
<nacc> ali1234: so it feels like maybe you thought snaps were solving a different problem than they are?
<ali1234> i thought they were solving all problems :)
<ssweeny> eventually :)
<ali1234> but this is one problem i have now
<ali1234> and it's really annoying
<ali1234> i'd like to try out rocket chat
<ssweeny> right, so for now you can get some benefit from snapping but there is still some manual config needed
<ali1234> but i can't install it on my server
<ssweeny> the rocket chat snap works pretty well
<ali1234> and many other web apps
<ali1234> but my server already has a horrible mess of vhost configs
<ali1234> also it is running 14.04
<nacc> ali1234: yes, sorry -- i should have 'had solved a different problem than they have' :)
<ali1234> at the moment it is running about 6 wordpress instances, some wiki software, a bug reporting app, a couple of joomlas
<ali1234> i think there's a gitlab install as well
<ssweeny> multiple wordpress instances is going to be the big hurdle
<ali1234> they are the easiest to deal with currently because they don't need any funny dependencies like ruby on rails or node
<ssweeny> maybe leaving them alone is the way to go then
<ali1234> just unzip it in the htdocs and that is it
<ssweeny> since you still need a central nginx then you could still install the rocket snap
<ali1234> but i don't need a central nginx currently?
<ali1234> i just use apache vhosts
<ssweeny> same difference :)
<ssweeny> apache has a mod_proxy that'll let you do the same thing
<ali1234> hmmmmm
<ssweeny> I just thought all the kids were using nginx these days
<ali1234> only because they are using five separate virtual machines to run one copy of wordpress
<ssweeny> says the guy who set up a webserver like 6 years ago and is afraid to change it
<ssweeny> running lighttpd no less because at the time the VPS had very limited RAM
<ali1234> this server moved off a VPS because of stupid ram limits
<ali1234> the provider placed a limit of like 8MB of non-swappable kernel memory
<ali1234> so we had like 1GB of RAM, but things were getting OOM killed because they opened too many files
<ali1234> took us ages to figure it out as well
<larryprice> bartbes, fyi after installing in devmode i found some of my /tmp folders in `source=/var/lib/snapd/hostfs/tmp/` in the container
<bartbes> when I tried to open that it was empty
<bartbes> and that's in devmode
<larryprice> hmm weird... mine only show up when i ask for the specific directory i'm looking for
<jdstrand> renato__: if you click 'manual review' I'll approve https://myapps.developer.ubuntu.com/dev/click-apps/4632/rev/17/
<mup> Bug #1644058 changed: Different behaviour in MPRIS interface with local install vs store install <Snappy:Invalid> <https://launchpad.net/bugs/1644058>
<mup> Bug #1646415 opened: cannot run configure hook <Snappy:New> <https://launchpad.net/bugs/1646415>
<mup> PR snapcraft#937 closed: Incorporate all part properties into state tracking <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/937>
<mup> PR snapcraft#944 opened: Release changelog for 2.23 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/944>
#snappy 2016-12-03
<mup> PR snapcraft#944 closed: Release changelog for 2.23 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/944>
<mup> PR snapd#2403 opened: store: fix unhandled error from io.Copy() in download() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2403>
<madprops__> very excited about snap
<madprops__> still dont understand it fully
<madprops__> thinking about what would happen with big applications like DEs
<madprops__> im guessing some of it will be global ... but temporarily?
<madprops__> will it be snap and the normal global system in conjunction
<madprops__> or will everything be snap
<madprops__> i wonder
<madprops__> but giving applications its jar and water to live is an idea ive always thought why it was not being implemented
<madprops__> idk
<madprops> I saw a question that made me wonder, maybe someone can explain it to me "How do I verify that all 300 copies of libgnutls.so are patched and protected against the latest vulnerabilities?"
<ali1234> madprops: there is no good answer to that question, in the general sense. it has always been a problem for any type of app bundling
<ali1234> for highly important libraries involving encryption etc there will be platform snaps which will provide library sharing
<ali1234> and of course the core platform
<ali1234> but you can still get bitten by something obscure
<madprops> that's what i feared
<madprops> makes me think, this among other things, that maybe "snapifying" a system maybe not the way to go .. except for certain cases
<madprops> like video games make sense
<madprops> but at the same time you can have something like steam
<madprops> but on the other hand it does have some benefits, like less prone to dependency hell and quicker updates
<qengho> madprops: I expect there will be a kind of scanner for out of date dependencies in packages, and shame as the major motivator for people to fix their bugs.
<qengho> madprops: The great thing about snaps is that a broken package can only harm the things it is allowed touch, which is not very much -- pretty much only what it makes.
<qengho> madprops: As always, you have to trust the person who makes the code. With snaps, there is no third person (a packager) who has to care enough also.
<madprops> qengho, how do snap hosting works? do developers make a snap and publish it in some centralized server or they host it themselves?
<qengho> madprops: There are central hosts, stores.
<qengho> madprops: Your "snap" system has one in mind when you install.
<qengho> madprops: And your machine ensures everything is up to date by checking its store every so often.
<madprops> who mantains these stores monetarily?
<qengho> madprops: You, if you develop a snap-using OS. Ubuntu has one. Probably others.
<qengho> I use Ubuntu Core, so my machines ask Ubuntu's store.
<qengho> I also upload a few packages to Ubuntu's store. I push to a Launchpad branch and it deposits compiled packages (for four architectures!) into my snap-package's Proposed channel in a few minutes. I make sure it looks right and then promote it to Stable channel in the store.
<qengho> https://myapps.developer.ubuntu.com/
<madprops> nice
<ali1234> what architectures do you build for?
<ali1234> can snapcraft do cross-builds yet?
<qengho> ali1234: Some parts have cross-build support, but not all. Some will be tricky. I build for x86, amd64, armhf, & amr64
<qengho> ali1234: Now that there's a virtual-machine build process, I suspect the built-in cross-build will die and we'll just emulate the other arch and run "native" there.
<qengho> But I don't know a lot of that.
<ali1234> i find the launchpad workflow too slow for development
<ali1234> it would probably be okay once i actually get things working
<qengho> Yeah, Launchpad isn't your development environment.
<ali1234> yeah... unfortunately my target is raspberry pi
<ali1234> so native builds are even slowed
<qengho> ali1234: "snapcraft cleanbuild" runs lxc. Making that be a different architecture should be possible.
<ali1234> i couldn't get cleanbuild to even work for host architecture
<qengho> Just some other wrapper to an emulator.
<ali1234> it just gives me apt errors
<ali1234> http://askubuntu.com/questions/787258/internal-server-error-when-retrieving-files-from-the-archive-in-lxd
<qengho> http 500 from an archive? Sounds funny. Are you using a proxy or something?
<ali1234> no
<qengho> ali1234: Well, that would be a problem common to every Ubuntu user everywhere, not specific to snapcraft.
<ali1234> it only happens with snapcraft
<ali1234> specifically, only with lxc it seems
<ali1234> also i didn't post that question
<ali1234> so it isnt just me
<torusJKL> Hi. I have a qustion regarding building with autotools.
<torusJKL> I want to instruct snapcraft to build witin the directory build_unix.
<torusJKL> But the configure.ac file is in the directory dist.
<torusJKL> I tried to use source-dir and specified dist.
<torusJKL> It found the configure file but then it would say that I should not build in this directory.
<torusJKL> The error is: Berkeley DB should not be built in the top-level or "dist" directories. Change directory to the build_unix directory and run ../dist/configure from there.
#snappy 2016-12-04
<mup> PR snapd#2404 opened: interfaces/builtin: updates to dcdbas-control interface <Created by tonyespy> <https://github.com/snapcore/snapd/pull/2404>
<Guest86497> Hi I just install the handbrake snap package, but Handbrake doesn't have access to my DVD drive!
<mup> Bug #1647139 opened: CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-12520/chroot-autobuild', 'linux64', '/bin/sh', '-c', 'cd /build/qucs-spice && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:3128
<mup> http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 <build> <lp> <Snappy:New> <https://launchpad.net/bugs/1647139>
<TMiguelT> Is there a command to list the files in a .snap?
<bartbes> unsquashfs -l
<TMiguelT> Ooh nice, thanks!
<TMiguelT> If I have an `organise: {usr/bin: bin}` in my snapcraft file, will it physically move all the binaries from usr/bin to bin? How come that doesn't seem to work?
<TMiguelT> Actually it seems that that configuration moves some of the files but not all.
<TMiguelT> I wonder how that is
<mup> Bug #1647169 opened: Oneshot services with start/stop commands need RemainAfterExit=yes <Snappy:New> <https://launchpad.net/bugs/1647169>
<Zap123> Hello, I'm trying to package as a snap my favourite music player https://github.com/gnumdk/lollypop for a while, but I can't manage to make it work because the python directory during ./configure is set to a path different than the one in the snap container. Can someone have a look at it? http://pastebin.com/GX4hZwfM The author made a flatpack but they doesn't seem similar to snap packages to gain any insight
<mup> Bug #1647200 opened: xdg-open does not open link when java is staged <snap> <xdg-open> <yakkety> <Snappy:New> <https://launchpad.net/bugs/1647200>
<ZenHarbinger> Yesterday I asked about xdg-open and how it wasn't working for me.  I located a couple of issues where it doesn't work and submitted a bug.
<ZenHarbinger> https://bugs.launchpad.net/snappy/+bug/1647200
<mup> Bug #1647200: xdg-open does not open link when java is staged <snap> <xdg-open> <yakkety> <Snappy:New> <https://launchpad.net/bugs/1647200>
#snappy 2017-11-27
<mborzecki> morning
<mup> PR snapd#4269 closed: timeutil: new refresh timer parser <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>
<mborzecki> mvo: morning
<mvo> hey mborzecki, good morning!
<mborzecki> mvo: did you have your morning coffee? because I need some help right here https://github.com/snapcore/snapd/pull/4296#discussion_r153116179
<mup> PR #4296: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4296>
<mvo> mborzecki: sure, let me have a look. I had my cup of morning tea (Hainan Bai Cha Lu which I can hightly recommend ;)
<mvo> mborzecki: haha, yeah, its confusing because snapd creates dirs on demand so if we don't update the dirs files we don't notice
<mvo> mborzecki: I think you are on the right track, i.e. lets make sure we get it right at least once
<mborzecki> haha
<mborzecki> are any of the directories listed specific for ubuntu package only?
<mborzecki> umm, and /var/snap, it holds SNAP_DATA or SNAP_USER_COMMON?
<mvo> mborzecki: yeah, we want this too
<mvo> mborzecki: the dirs/dirs.go is the best source I think
<mvo> mborzecki: because we use it for mocking in the tests pretty much everything is listed there
<mborzecki> ok, i'll update the list for arch then along with some other fixes
<mvo> mborzecki: sounds good, bonus points for a PR that also updates the other packaging :)
<mborzecki> spread tests actually caught stuff like a missing manpage for snap, some missing dirs in /var/lib/snap
<mvo> mborzecki: nice!
<mvo> mborzecki: thanks again for doing those new arch tests
<mup> PR snapd#4300 opened: packaging/arch: install missing directories, manpages and version info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4300>
<ogra_> cjwatson, does LP snap building have a network prob ? https://launchpad.net/~snappy-hwe-team/+snap/wifi-connect-daily (seems there are proxy errors for git.lp.net)
<mborzecki> pushed another set of fixes for spread with Arch, let's see how far we get this time
<mborzecki> pstolowski: morning
<pstolowski> mborzecki, hey!
<zyga-solus> hello
<zyga-solus> mvo: sorry for being late, my daughter is sick and I'm the parent that says at home
<zyga-solus> things are under control now so I'll get to work
<mborzecki> zyga-solus: hey, sorry to hear about your daughter, hope she recovers quickly
<zyga-solus> mborzecki: just some fever
<zyga-solus> mborzecki: she wasn't sick in years so it's an event :)
<zyga-solus> mborzecki: it started (obviously) on Friday after the swimming pool, she's much better now
<mborzecki> i suppose one of the downsices of coming back to polish climate
<zyga-solus> indeed
<zyga-solus> but they'd love to see some snow again
<zyga-solus> so the mood is very good
<mborzecki> i remember i used to like playing in snow when i was a child
<mup> PR snapd#4300 closed: packaging/arch: install missing directories, manpages and version info <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4300>
<mborzecki> then i grew up and had to commute to work in the morning, in the snow:/
<zyga-solus> mborzecki: she saw snow when she was maybe 6 or 5
<zyga-solus> mborzecki: we went to a valley in the pyrenees :)
<mborzecki> hahah
<zyga-solus> she cut her arm on some sharp ice
<zyga-solus> and keeps recalling that whenever we mention winter again :)
<mborzecki> ouch
<mup> PR snapd#4294 closed: Mount with x-gdu.hide option <Created by azzar1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4294>
<zyga-solus> man, we're rocking at 20 PRs
<zyga-solus> and many more to land soon
<zyga-solus> https://github.com/snapcore/snapd/pull/4281 needs a 2nd review and is green
<mup> PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
 * ikey will be sending more once he's alive again..
<zyga-solus> ikey: hey, thank you :)
<zyga-solus> your PRs are always welcome :)
<ikey> merci :]
<ikey> gotta work out how to get fedora nvidia happy
<ikey> the new glvnd stuff
<zyga-solus> mvo: I wonder what to do about https://github.com/snapcore/snapd/pull/4140 -- I'll ask jdstrand for a look but it "feels" ready otherwise
<mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<zyga-solus> ikey: I think (fortunately) everyone will use it eventually
<zyga-solus> (much better than dpkg alternatives or other voodoo)
<ikey> yeah we have an open issue in solus for it too
<ikey> we also have to do similar levels of magic filesystem butchery to make GL work
<ikey> i.e. /usr/lib64/libGL.so.1: symbolic link to /usr/lib64/glx-provider/nvidia/libGL.so.384.98
<ikey> but we live in a post update-alternatives world :p
<ikey> speaking of jdstrand - around today?
<zyga-solus> ikey: I cannot say, let me check
<ikey> merci
<zyga-solus> ikey: he seems to be around today
<ikey> ah cool
<ikey> there is light at the end of the tunnel then ^^
<zyga-solus> ikey: and it says "choooo chooo"
<ikey> lol yeah
<mvo> zyga-solus: yeah, I think we need a security review but I would love to merge it
<zyga-solus> mvo: indeed, I would like to wait for jdstrand
<mvo> zyga-solus: re late> no worrie
<mvo> s
 * ikey blinks at the external repos forum thread
<ikey> nitrux reasoning is uh, off, to say the least
<ikey> they're insinuating that snapd-glib{,qt} isnt maintained
<zyga-solus> ikey: which thread is that?
<ikey> https://forum.snapcraft.io/t/external-repositories/1760/144
<mborzecki> interesting, anyone used nitrux? what's special about this one?
<ikey> it uses not-a-budgie
<ikey> (the desktop looks like a qt/kde budgie)
<ikey> and i think they do hardware stuff?
<mborzecki> interesting
<mborzecki> their page has some issues in ff through :(
<zyga-solus> mvo: do you know what is the status of https://github.com/snapcore/snapd/pull/3998 -- it feels like that's something on our plate now
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<zyga-solus> mvo: let's talk about that at the standup perhaps?
<zyga-solus> mvo: and on the same vein: https://github.com/snapcore/snapd/pull/4049 -- this is clearly our game but I'd like to know your plans for it
<mup> PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>
<mvo> zyga-solus: iirc one blocker is that the downstreams need an updated seccomp golang
<mvo> zyga-solus: but yeah, we need to talk about it
<mvo> zyga-solus: iirc the code itself (without our libseccomp etc) is fine now, I updated the tests ages ago
<cjwatson> ogra_: Thanks, something does seem to be badly wrong with the snap-proxy.  Investigating
<ogra_> thx
<cjwatson> ogra_: Should be fine now
<cjwatson> (restarted squid)
<ogra_> cjwatson, thanks a lot
<mup> PR snapd#4301 opened: interfaces: small helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>
<mup> PR snapd#4302 opened: timeutil, overlod/snapstate: cleanup remaining pieces of timeutil weekday support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4302>
<zyga-solus> pstolowski: reviewed
<pstolowski> zyga-solus, that was quick, thanks! will move the test into separate method
<zyga-solus> thanks
<zyga-solus> mborzecki: same, though asked a small uncomfortable question
<pstolowski> zyga-solus, done
<mborzecki> zyga-solus: thanks, and mvo thanks for addressing zyga's comment :)
<mvo> yw
<mborzecki> pstolowski: added some reflect magic in the comments to your PR
<pstolowski> mborzecki, I saw that, thanks! i like that, let's see if anyone opposes it, if not this is going to simplify some of the changes i'm doing right now, actually
<mborzecki> pstolowski: i'm quite sure it works for simple assignable types, haven't checked slices or functions
<zyga-solus> mborzecki: I think we try to avoid reflection in non-test code
<mvo> meh, tests are hitting the timeouts pretty consistently currently :(
<pstolowski> ah, here you go
<mborzecki> zyga-solus: you mean hand written reflection? because json de/encoding does the same (just in more horrid way)
<mvo> mborzecki: 4285 has conflicts (in case you haven't seen that already)
<mborzecki> mvo: thaks, i'll take a look later, hopefully nothing too complicated
<zyga-solus> mborzecki: I mean "import reflect" in general, that was my experience at least
<zyga-solus> mborzecki: but we'll see, I'm don't know :-)
<zyga-solus> mvo: store woes or things we're not re-trying?
<mvo> zyga-solus: not sure
<mvo> mborzecki: yeah, probably small stuff, I also added some comments, a bit drive-by, sorry for that, will do a more systematic one too
<mup> PR snapd#4303 opened: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4303>
<pedronis> mvo: hi, I did a final pass on a couple of your open PRs
<pedronis> now lunch
<mvo> pedronis: \o/ thank you
<mvo> pedronis: I check it out
<cachio> mvo, hey, I'll be 5 minutes late for the standup
<mvo> cachio: no problem
<cachio> mvo, tx
<niemeyer> Hellos
<mvo> pstolowski: woah, 4303 looks like you had a lot of work with that one
<niemeyer> Good mondays
<mvo> good morning niemeyer, happy monday!
<pstolowski> mvo, it was a pleasure
<pstolowski> mvo, just kidding ;)
<mvo> pstolowski: rotfl
<mvo> pstolowski: it looks impressive in any case :)
<pstolowski> hey niemeyer! any thoughts on the suggestion from mborzecki here in the comments: https://github.com/snapcore/snapd/pull/4301 ?
<mup> PR #4301: interfaces: small helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>
<zyga-solus> pstolowski: OMG 4303 is monumental
<pstolowski> zyga-solus, it would be 2x more if I didn't artificially split it (with the hack mentiond in the desc)
<pstolowski> yeah, these kind of changes are pain..
<niemeyer> pstolowski: Looking
<pstolowski> niemeyer, zyga-solus was saying we don't want to use reflection in the code?
<niemeyer> pstolowski, mborzecki: That's quite nice
<niemeyer> pstolowski: I don't see why.. we're using reflection like this all the time because we use json
<pstolowski> good
<niemeyer> jdstrand: ping
<pedronis> niemeyer: hi, could you look at #4281  it looks sane to me, but IÂ wasn't there when the details of it where discussed
<mup> PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
<niemeyer> pedronis: On it
<mup> PR snapd#4302 closed: timeutil, overlod/snapstate: cleanup remaining pieces of timeutil weekday support <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4302>
<niemeyer> pedronis, pstolowski: Sent some questions about the details there
<zyga-solus> mborzecki: trivial conflict on 4285
<niemeyer> zyga-solus: Coming?
<sergiusens> zyga-solus remind me again, when using a non ubuntu kernel on ubuntu, but having confinement enabled, how do I tell snap-confine to behave? http://pastebin.ubuntu.com/26057979/
<zyga-solus> niemeyer: yes, just 2fa woes
<zyga-solus> sergiusens: I think this is fixed in master now
<sergiusens> mpt hey there, mind reviewing the wording on this PR? https://github.com/snapcore/snapcraft/pull/1634/files
<mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
<mpt> sure
<sergiusens> mpt thanks!
<sergiusens> mpt if you think of a better "command name" don't hesitate to bring it up :-)
<Facu> mpt, sergiusens, thanks
<sergiusens> zyga-solus to use master, do I just bring it in? As in, is snap-confine going to be executed host side or from "core/base" if I build a package from master and install?
<zyga-solus> sergiusens: you just use edge, hopefully that should be enough
<sergiusens> zyga-solus ah, that's risky business :-P
<sergiusens> zyga-solus might it be in beta or candidate?
 * sergiusens refreshes to edge
<sergiusens> I hope that going to candidate eventually (to a past revision) won't ruin up all the apparmor or seccomp profiles created
 * lundmar looks around pondering how to speed up his alias request for lxi-tools :)
<sergiusens> zyga-solus do I need to reboot?
<sergiusens> if the answer is no, the fix does not seem to be in master
<lundmar> Hmm, I've granted build.snapcraft.io access to the repositories in one of my organizations. However, now I need to grant access to other repositories in a different organization but I can't find or reopen the interface for doing that at build.snapcraft.io ?
<lundmar> Oh never mind, I've found it.
<mpt> sergiusens, I think it would take a long time for me to learn enough to have a useful opinion on that PR, so Iâll stay out of it. Sorry. :-)
<sergiusens> mpt how about if I just ask you to look at this https://forum.snapcraft.io/t/mechanisms-for-converging-store-and-snap-metadata/2200 ?
<sergiusens> mpt  oh, you already have
<sergiusens> mpt Facu instead of `snapcraft update-metadata` what about `snapcraft push-metadata` which has a more consistent feel to the default `push` or do we want to keep the word "update" in there?
<mpt> sergiusens, that seems reasonable to me
<lundmar> no more update, upload, just push please :)
<Facu> sergiusens, not following you... currenct command is `snapcraft push <snap> --only-metadata`
<Facu> sergiusens, no "update" at all
<sergiusens> mpt Facu sorry my head works in mysterious ways... I don't know where I got my references from; but starting from scratch, does `snapcraft push-metadata` feel more straightforward and understandable than `snapcraft push --only-metadata`?
<mpt> sergiusens, to me, yes
<sergiusens> thanks for the feedback mpt
<Facu> sergiusens, `snapcraft push-metadata <snap> [--force]` ?
<sergiusens> yes
<sergiusens> mvo zyga-solus help, I cannot come back to stable after going to edge it seems http://pastebin.ubuntu.com/26058202/
<sergiusens> it is stuck there
<mvo> sergiusens: yes, its a known issue, the fix is in an open PR. in the meantime, please run `snap changes` and check the change in "do" start and `snap abort <nr>` it
<mvo> sergiusens: that should unbreak you
<mvo> sergiusens: this https://github.com/snapcore/snapd/pull/4298 is the fix
<mup> PR #4298: many: remove configure-snapd task again and handle internally <Created by mvo5> <https://github.com/snapcore/snapd/pull/4298>
<mvo> sergiusens: once it lands things are good again
<sergiusens> mvo ok, thanks
<sergiusens> so I get to stay on edge until this gets there :-P
<mvo> sergiusens: :) yes
<mvo> sergiusens: hopefully this lands today
<sergiusens> if I become unresponsive everyone should know why ;-)
<sergiusens> great
<mvo> sergiusens: heh
<sergiusens> mvo I kid thought, I have my wifes computer close by ;-)
<sergiusens> zyga-solus bottom line, edge does not have the fix which makes me boot with `apparmor=0` and I am totally confused as why that would be more secure :-/
<zyga-solus> sergiusens: to the best of my knowledge, yes
<zyga-solus> sergiusens: what are you getting?
 * zyga-solus lunches
<sergiusens> zyga-solus same message as before and snap-confine going dead
<zyga-solus> sergiusens: hmm, "not confined but should be"?
<lundmar> Question, why is it that some use "description: |" and some simply "description:" ? It seems to make no difference.
<sergiusens> lundmar multiline is easier with `description: |`
<mup> PR snapd#4304 opened: debian: demote gnupg from dependencies to recommends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4304>
<sergiusens> e.g.; for writing paragraphs
<lundmar> sergiusens: But even without | paragraphs seems to work just fine
<sergiusens> zyga-solus yes
<zyga-solus> sergiusens: what does `aa-enabled` say?
<sergiusens> lundmar I'd have to check the yaml spec to get a better answer to this one
<lundmar> sergiusens: fyi - this works fine: https://github.com/lxi/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml
<sergiusens> zyga-solus exactly what I shared on the first pastebin; I am now running disabled to get work done
<zyga-solus> hmm hmm
<zyga-solus> (that's not good)
<sergiusens> zyga-solus exactly, I am about to "distro patch" that check out of the code base to be able to enable apparmor again
<zyga-solus> sergiusens: how do I run a mailine kernel like you do?
<lundmar> sergiusens: If it is perfectly fine to not use | then I think it should not be encouraged to use it - it simply becomes noise/clutter.
<sergiusens> lundmar can you check the spec and make sure that is the case? It might as well be, but we initially had problems when we didn't
<lundmar> perhaps it has been improved since
<sergiusens> zyga-solus you can use the one the kernel team provides or use https://github.com/jakeday/linux-surface which is what I have
<sergiusens> zyga-solus https://wiki.ubuntu.com/Kernel/MainlineBuilds
<zyga-solus> sergiusens: let me try those and get back to you
<lundmar> the only place I can find a doc reference to | is https://docs.snapcraft.io/build-snaps/your-first-snap
<lundmar> However, it seems to work just fine without so I guess recent snapd supports not using the odd |
<lundmar> *snapcraft
<sergiusens> kyrofa are you up and about? How was the weekend?
<mup> PR snapd#4305 opened: snapd.dirs: add var/lib/snapd/lib/gl32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4305>
<kyrofa> sergiusens, I am, good morning
<sergiusens> kyrofa good afternoon then :-P
<kyrofa> Yeah, good weekend. The rest of the hardware for my series arrived, so I took some of my intro footage before I needed to poke holes in the box
<kyrofa> You?
<pstolowski> niemeyer, the question you raised on 4281 wrt running pre-refresh hook if snap is not active is an interesting problem. the short answer is no, I should prevent this, because it won't work. but the question is what's the right thing to do. the fact that we will not execute this hook on refresh just because the user has disabled the snap seems a but questionable
<pedronis> pstolowski: let me check something
<pedronis> pstolowski: we don't refresh inactive snaps atm (we said it the past that we should reconsider that decision, but that's the current status)
<pstolowski> pedronis, hmm how is it the case? we do have logic around isActive in doInstall (update)? or do we cut this off somewhere else?
<pedronis> pstolowski: look at Update and refreshCandidates
<pstolowski> pedronis, aha!
<pedronis> 	// FIXME: snaps that are not active are skipped for now
<pedronis> 	//        until we know what we want to do
<pedronis> 	if !snapst.Active {
<pstolowski> pedronis, thanks!
<pstolowski> that answers it
<niemeyer> pstolowski: Yeah, I don't quite understand the question, probably based on pedronis' feedback
<niemeyer> pstolowski: Inactive snaps are equivalent to not being there at all in many senses
<niemeyer> pstolowski: We definitely don't want logic running on them
<pedronis> yea, IÂ think the current decision is probably right in retrospect, and will be even saner with epoch support
<pstolowski> niemeyer, yes. but the bottom line (as far as I understand this) is the logic wouldn't be fired anyway in this case. i'm adding isActive check anyway
<niemeyer> pstolowski: I don't understand the point.. the check there which was omitted is meant to check for exactly this, right?
<pedronis> pstolowski: notice that that check about Active in doInstall is probably just a historical spelling of IsInstalled IÂ think
<pedronis> it would also support refreshing an inactive snap (which we don't do though)
<pstolowski> okay, not doing anything about that then. the problem of running after stop-services is fixed now. the post-refresh hook already runs before start-snap-services, so nothing to fix there
<pstolowski> niemeyer, ^
<niemeyer> pstolowski: Sounds good, let me know when it's ready for another round please
<sergiusens> kyrofa did you catch my comment on the `init` PR?
<pstolowski> niemeyer, it is now
<kyrofa> sergiusens, init? Are you talking about the tuple one?
<sergiusens> kyrofa yeah
<kyrofa> sergiusens, I did, and you're right, considering that's on our roadmap anyway implementing the SNAPCRAFT_ARCH_TRIPLET seems the proper fix. However, do we want to add gcc as a required build-package for everything?
<kyrofa> We could go the other way and use the map we already have
<kyrofa> sergiusens, note that I'm working on the macaroon at the moment. Would you like me to give this priority?
<sergiusens> kyrofa yeah, use the map; macaroon stuff can go first too
<kyrofa> You got it
<lundmar> I assume it is still the correct procedure to request aliases in the snapcraft forum or has procedure changed? (alias vs declarations?)
<kyrofa> lundmar, indeed, that's correct
<lundmar> kyrofa: ok, so I just have to be patient :)
<lundmar> fyi - I've put an alias request in the "store" forum channel.
<kyrofa> lundmar, can you provide a link here?
<kyrofa> lundmar, oh, found it
<lundmar> ok thanks
<lundmar> the lxi-tools one
<kyrofa> lundmar, note that there's a waiting period for comments (a week I think)
<kyrofa> There was a document about the process, but I think the forum swallowed it
<kyrofa> A topic, rather
<lundmar> oh. Wau thats quite some time :/
<lundmar> Wouldn't it be easier for everyone if you guys only have to address and vote to solve alias conflicts instead of voting all alias requests?
<sergiusens> kyrofa a final ack on snapcraft#1759 would be nice :-)
<mup> PR snapcraft#1759: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>
<kyrofa> Ah, the docs were updated, nice
<kyrofa> sergiusens, yep, excellent
<kyrofa> sergiusens, I suppose I need to make a forum proposal if I actually want to write a command to save the macaroon, huh?
<kyrofa> lundmar, yes, agreed, we just don't quite have the infrastructure for that in place just yet
<sergiusens> kyrofa a forum post would be ideal, yes
<kyrofa> Okay I've got this mostly done, that's the last step. Let me write it up
<mup> Issue snapcraft#1662 closed: patchelf with ld-linux <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1662>
<mup> PR snapcraft#1759 closed: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>
<sergiusens> kyrofa great
<sergiusens> kyrofa, btw it is just me and you this week
<kyrofa> sergiusens, oh good to know
<kyrofa> I knew elopio was out
 * sergiusens starts getting ready for physiotherapy 
<jdstrand> zyga-solus: still slogging through holiday backlog. PR 4100 added to list
<mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>
<jdstrand> zyga-solus: err, it was always on the list. I mean it is on my list for this week, assuming it doesn't get preempted
<jdstrand> zyga-solus: pr 4140 is also on the list. that requires some investigating from me
<mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<jdstrand> niemeyer: hey, pong
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Have you seen the follow ups on ikey's thread re. the base image?
<niemeyer> Erm
<niemeyer> base snap
<jdstrand> niemeyer: I saw them in my inbox but put them to the side until I could review them more carefully. I'm about to go back to them (various pings/meetings/etc this morning)
<niemeyer> jdstrand: Ack, just wanted to make sure it was back on your upcoming list, thanks!
<jdstrand> yep
<jdstrand> np
<jdstrand> niemeyer: and sorry I missed the hongout last week, was on holiday and missed the emails/etc
<niemeyer> jdstrand: np, and sorry for pinging while you were on holiday, it was not intended to take you out of them :)
<lundmar> kyrofa: I've put a forum post regarding the alias vote suggestion: https://forum.snapcraft.io/t/suggestion-only-vote-to-resolve-alias-conflicts/2966
<niemeyer> pstolowski, pedronis: Shouldn't the pre-refresh hook also be gated by isActive?
<pedronis> niemeyer: IÂ think we talked past each other,  yes to be correct if we allow refreshing inactive snaps, but we don't do that atm. we have a similar check already in doInstall, we probably need to decide one way or another at some point
<pedronis> I think we want to keep things as they are (no refreshes for inactive snaps) and then probably checks in doInstall would need to be different
<pedronis> but IÂ suppose for this PR the most consistent thing is to add an isActive guard
<pstolowski> indeed, i wanted it for clarity but afaiu it's not going to be effective atm, since refresh will not be performed
<niemeyer> pstolowski, pedronis: The logic there just tastes wrong in either of those cases
<niemeyer> We *are* checking if the snap is active before performing certain things
<niemeyer> So we need to make up our minds: do we assume that never happens, and really fail upfront if that does happen, or we continue to be mindful of the fact it might not be active
<niemeyer> What makes no sense to me unless I'm missing something, is to pretend it can happen, and code the logic incorrectly for that situation
<pedronis> I think we should fail upfront (the more things can happen when refreshing a snap the less it makes sense to support for refreshing inactive ones)
<pedronis> niemeyer: I think the current code is just a result of history, we never committed one way or another so far
<niemeyer> pedronis: That's fine.. I just don't want to have logic in place that is clearly wrong and we do know it's wrong
<niemeyer> pedronis: I would like to eventually support that use case, so one can install something without having it enabled right off
<niemeyer> pedronis: But there's no pressure to do that now
<pedronis> that's a bit different though
<pedronis> IÂ mean the check IÂ would add wouldn't involve that case directly
<niemeyer> pedronis: Actually, it does sound a bit awkward to *not* support it
<pedronis> snapst.IsInstalled && !snapst.Active => error
<niemeyer> pedronis: Just considering the case: there's something wrong with the current version, we disable it so it stops creating havoc
<niemeyer> pedronis: We want to enable it, but update it first
<niemeyer> pedronis: That's exactly that situation, I think
<niemeyer> pedronis: Unfortunately, that means the pre-hook could not run, which might be a real issue
<pedronis> we need custom logic
<pedronis> consider that pre-refresh could explode
<niemeyer> pedronis: So +1 on simply forbidding for now
<niemeyer> pstolowski: Are you with us?
<pstolowski> niemeyer, yes. so that's the kind of doubts I had with my original question way above, although phrased in a different way.
<pedronis> let me check quickly if I'm off and lots of tests explode
<pedronis> if we do that
<pedronis> which probably means it needs to be its own PR
<niemeyer> pstolowski: Sure, we're exploring and discussing..
<niemeyer> pstolowski: and we reached an agreement.. do you understand it/agree?
<pstolowski> niemeyer, you want to support refresh on disabled snap, but not run the pre-refresh hook if snap is not active, is that it?
<pedronis> pstolowski: no,   for now we want to forbid it
<niemeyer> pstolowski: No.. we want to forbid the situation upfront, and remove traces of that logic
<niemeyer> pstolowski: The code in the PR is still bogus if the situation happens, and while we can fix it to make non-bogus, we don't currently do that, and we have no tests making sure that will continue to work
<niemeyer> or even that it works at all
<niemeyer> pstolowski: So we either fix it for real, or we stop pretending, basically
<pedronis> I did the change locally here
<pedronis> test seems still happy
<niemeyer> That's awesome, so let's just kill it for now
<niemeyer> Explicitly, and with guards
<pedronis> pstolowski: I can give you a sketch diff in a sec
<pedronis> pstolowski: something like this IÂ suppose:  http://pastebin.ubuntu.com/26059429/  (given that we already have guards a level up)
<pstolowski> pedronis, I see
<brunosfer> Hi guys, I'm struggling a bit here. I'm trying to compile a go file to further develop a snap, but go tools require the go compiler and the go compiler requires gcc for ARM (in my case) and in ubuntu snap core I can't find any gcc snap. How do you guys do this? Thanks
<cjwatson> The existing go snap should include everything you need, shouldn't it?
<pedronis> pstolowski: there's some argument to produce a nice error even there, but that's the main change I think
<Facu> sergiusens, mpt, pushed the changes to PR with the paradigm change you requested today: https://github.com/snapcore/snapcraft/pull/1634
<mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
<Facu> roadmr, matiasb ^
<matiasb> great, thx
<niemeyer> I need to step out for a while to run an errand.
<roadmr> Facu: yay thanks
<roadmr> hopefully sergiusens will have a moment to review that :)
<pstolowski> pedronis, okay, added to my PR
<pstolowski> thinking about test now, but i don't see how to provoke it (we cut that case off at higher level)
<pstolowski> pedronis, ok, pushed a simple test, can you take a look?
<lundmar> Is there a public online directory of all the snaps in the global store somewhere?
<pedronis> pstolowski: looks ok
<lundmar> I mean, a browsable/searchable directory.
<lundmar> This is the only online snap searcher/browser I can find: https://uappexplorer.com/snaps
<kyrofa> lundmar, yeah that's it (it's unofficial)
<pstolowski> eod, cu!
<zyga-solus> re
 * zyga-solus finally doesn't have to look after kids, straps for an late-night coding session
 * ikey sends broken update to zyga-solus's machine
<ikey> >_>
<ikey> <_<
<zyga-solus> ikey: btw, did you hear that tubmleweed added "snapshots"
<zyga-solus> so that you can update and keep a given snapshot
<zyga-solus> and rollback
<ikey> oh cute
<ikey> btrfs ?
<zyga-solus> I didn't read more, they mentioned "copying all the packages"
<ikey> ._.
<zyga-solus> OMG HI_TEH
<ikey> oh btw i wrote that hashmap in the end :p
<zyga-solus> ikey: nice! :)
<zyga-solus> ikey: I'll show you some of my stuff once it brews to usability
<ikey> look forward to it :]
<ikey> my current (early) map https://github.com/ikeydoherty/libuf/blob/master/src/map.c
<ikey> needs iter apis but it'll do the job for now
<sergiusens> Facu roadmr matiasb approved with a minor comment if you don't mind addressing
<mup> PR snapd#4305 closed: snapd.dirs: add var/lib/snapd/lib/gl32 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4305>
<zyga-solus> jdstrand: can you please look at 4306, it's the #include vs include bug
<mup> PR snapd#4306 opened: cmd/snap-confine: use #include instead of bare include <Created by zyga> <https://github.com/snapcore/snapd/pull/4306>
<mup> PR snapd#4292 closed: snapstate: store userID in snapstate <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4292>
<ikey> jdstrand, ty for review!
 * ikey whacked the magical edge release thingy
<sergiusens> kyrofa can you think of a better name than snapcraft#1755 ? the "save them to git part". Also, our first liners are getting too long to have a pleasant view after committing
<mup> PR snapcraft#1755: tests: collect the autopkgtest results and save them in git  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1755>
<mup> PR snapd#4306 closed: cmd/snap-confine: use #include instead of bare include <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4306>
<mup> PR snapcraft#1742 closed: lxd: always remove tmp_dir after execution <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1742>
<jdstrand> ikey: thanks for the snap :)
<Facu> sergiusens, pushed the change
<sergiusens> Facu thanks, as soon as that is green I will merge; thanks again!
<Facu> sergiusens, thank you
<sergiusens> kyrofa mind reviewing/testing snapcraft#1762 ?
<mup> PR snapcraft#1762: lxd: delete container only if parts is empty <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1762>
<kyrofa> Sure thing
<kyrofa> sergiusens, mind taking a look at my forum proposal?
<jdstrand> roadmr: hi! can you sync r950 of the review tools?
<roadmr> jdstrand: sure! thanks!
<jdstrand> thank you :)
<roadmr> jdstrand: if that addresses https://bugs.launchpad.net/snapstore/+bug/1733699 could you link the bug to the branch please?
<mup> Bug #1733699: invalid snaps that trigger 'runtime-errors' json output are not correctly processed by the store <Snap Store:In Progress by jdstrand> <https://launchpad.net/bugs/1733699>
<jdstrand> roadmr: I already added a reference to that in the comments
<roadmr> thanks :)
<jdstrand> roadmr: it wasn't a branch-- I gave a link to the commit
<roadmr> oh that works well too
<jdstrand> roadmr: https://bugs.launchpad.net/snapstore/+bug/1733699/comments/5
<mup> Bug #1733699: invalid snaps that trigger 'runtime-errors' json output are not correctly processed by the store <Snap Store:In Progress by jdstrand> <https://launchpad.net/bugs/1733699>
<roadmr> oh I missed that
 * roadmr subs to the bug
<mup> PR snapcraft#1634 closed: Push metadata to the Store <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1634>
<mup> PR snapcraft#1762 closed: lxd: delete container only if parts is empty <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1762>
<mup> Issue snapcraft#1703 closed: Generate a list of error messages for design <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1703>
<lundmar> hmm, looks like the avahi-daemon is not accessible for snaps on Ubuntu 17.10
<lundmar> avahi clients fail to see avahi-daemon when using avahi-observe plug
#snappy 2017-11-28
<mup> PR snapcraft#1765 opened: store: refactor acquirement of attenuated macaroon <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1765>
<mup> PR snapd#4307 opened: Fix for issues when snad service is canceled and cleanup for snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4307>
<mborzecki> morning
<zyga-ubuntu> good morning
<mborzecki> zyga-ubuntu: hey
<mborzecki> zyga-ubuntu: how's your daughter? better?
<zyga-ubuntu> mborzecki: yeah, she's better but will stay one more day at home
<zyga-ubuntu> mborzecki: but hopefully I won't have to spend most of my time next to her as she will not (hopefully) stay in bed all day
<mup> PR snapd#4308 opened: packaging/arch: install snap-mgmt tool <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4308>
<zyga-ubuntu> mborzecki: reviewed
<mborzecki> thanks
<zyga-ubuntu> pstolowski: hey
<pstolowski> zyga-ubuntu, morning!
<zyga-ubuntu> pstolowski: I looked at 4303 and it seems to be really failing
<pstolowski> zyga-ubuntu, indeed, thanks for heads up, will check
<Chipaca> moin moin
<pedronis> Chipaca: hello
<mvo> hey Chipaca, good morning and good morning to pedronis
<Chipaca> pedronis: mvo: hiya :-)
<Chipaca> what's on fire?
<mvo> Chipaca: surprisingly little this morning
<mvo> Chipaca: the 2.30 branching is immanent but thats hardly a fire :)
<Chipaca> mvo: unless you mean 2.30 branching pervades the universe, i think you mean it's imminent
<pedronis> mvo:  we still have some PRs open for 2.30 right?
<Chipaca> snapd is imanent \o/ nothing more for us to do
<Chipaca> immanent*
<Chipaca> silly english
<pedronis> s/IOT/immanent computing/
<mvo> Chipaca: haha, indeed, sorry. ENEEDMORETEA
<mvo> pedronis: yes, we are still waiting for those
<zyga-ubuntu> Chipaca: hey
<Chipaca> zyga-ubuntu: hiya :)
<Chipaca> can anyone see what went wrong in the spread run of #4299? It seems to have just stopped mid-dance
<mup> PR #4299: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4299>
<mvo> Chipaca: yeah, confusing
<Chipaca> mvo: #1734845 sounds like fun
<mup> Bug #1734845: hook (core) configure â exit status 1 cannot create lock directory /run/snapd/lock â Permission denied <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734845>
<ogra_> pedronis, where does the firstboot key generation exactly live again ? could you point mvo to it in 4304 ?
<pedronis> overlord/devicestate/crypto.go  using ssh-keygen
<pedronis> nothing to do with gnupg
<ogra_> eek ... damn
<ogra_> mvo, sorry for the noise ...
<ogra_> i thought we also generate gpg keys there
<pedronis> so we need openssh-client
<ogra_> yeah
<ogra_> but 4304 is about dropping gnupg only ... so thats fine
<pedronis> that's used only for snap *-key commands
<pedronis> and the corresponding snapcraft ones
<ogra_> yeah
<mvo> ogra_: no worries, that was my understanding that we don't need it but it does not hurt to double check
<ogra_> true indeed
<Chipaca> oooh, bug
<Chipaca> pedronis: I like the idea of making Init more Mock-like more and more
<Chipaca> pedronis: would a bare Mock be alright?
<pedronis> taking nothing?
<Chipaca> pedronis: taking nothing, but returning a restorer func
<Chipaca> pedronis: otherwise every test that calls this would leave the system in a weird state after
<pedronis> ah
<pedronis> then yes
<pedronis> you  probably want a function that does the init bit alone though
<pedronis> to call from init()
<Chipaca> or viceversa
<Chipaca> i could call init by hand from the mock :-)
<Chipaca> zyga-ubuntu: if you have a bunch of distros hanging around, could you do a login.defs zoo?
<zyga-ubuntu> Chipaca: haha, sure
<zyga-ubuntu> Chipaca: I never looked at that file
<Chipaca> zyga-ubuntu: also: man subuid
<zyga-ubuntu> Chipaca: what's interesting about it?
<Chipaca> zyga-ubuntu: for osutil/user, SYS_UID_MAX
<Chipaca> i didn't know about subordinate uids
<pedronis> Chipaca: I don't think you can call init functions, they are special
<pedronis> you can have many of them, but not call them
<Chipaca> pedronis: I'll call it innit then
<Chipaca> :-)
<Chipaca> zyga-ubuntu: I don't need the login.defs zoo, fwiw -- i'm reading the file directly
<zyga-ubuntu> brb
<mup> PR snapd#4309 opened: snap: fix TestDirAndFileMethods() test to work with gccgo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4309>
<zyga-ubuntu> mvo: that's weird
<pedronis> mvo:  do we need more special casing now that we are removing configure-snapd to make it so, that snap set core works also before there's core at all ?
<mvo> zyga-ubuntu: yes it is - gccgo
<mvo> pedronis: maybe, I need to look
<pedronis> mvo: we do
<mvo> pedronis: thank you
<pedronis> mvo: is not easy to have no core snap in a spread test, right? unless it has its own prepare sequence?
<zyga-ubuntu> pedronis: I think so, though some tests just purge snapd
<pedronis> ah
<zyga-ubuntu> pedronis: I'd like to fix some things and change the prepare/restore code so that each test automatically installs snapd and starts from a clean slate otherwise
<zyga-ubuntu> pedronis: (the fixes would involve making that operation very cheap)
<zyga-ubuntu> pedronis: IMO the prepare/restore code is a bit complex today and optimizes for time rather than clarity while we can have both
<pedronis> anyway IÂ just need some expedient for today, and now I see indeed some tests start purging snapd
<mvo> pedronis: yeah, purging is probably the easiest, or just rm -f /var/lib/snapd/state.json if you need to simulate an empty state
<simosx> there is a source code repository (plugin: qmake) that does not implement "make install". How would I pick up the executable in order to move it in the snap?
<jdstrand> sergiusens: hey, is 'SNAPCRAFT_BUILD_INFO=1 snapcraft cleanbuild' supposd to work? (ie, SNAPCRAFT_BUILD_INFO with cleanbuild)
<mup> PR snapcraft#1766 opened: Enhanced fake store to detect that metadata can't be pushed prior to pushing the binary, and fixed the test <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1766>
<jdstrand> sergiusens: I have 2.34+17.10 and I don't see a build artifact
<jdstrand> (maybe I am looking in the wrong place?)
<sergiusens> jdstrand it is inside the snap, under the `snap` directory
<jdstrand> sergiusens: yeah. that is where I looked
<jdstrand> not there
<zyga-ubuntu> jdstrand: hey,
<jdstrand> hey zyga-ubuntu :)
<zyga-ubuntu> jdstrand: do you have some time, I made updates to https://github.com/snapcore/snapd/pull/4224
<mup> PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
<zyga-ubuntu> jdstrand: just comment changes + one function rename
<zyga-ubuntu> jdstrand: there's also one other PR that waits for your review: https://github.com/snapcore/snapd/pull/4140 a new interface
<mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<zyga-ubuntu> jdstrand: and lastly you have some feedback on https://github.com/snapcore/snapd/pull/4100 that looks like low hanging fruit, maybe something I can help with?
<mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>
<jdstrand> zyga-ubuntu: all are on my list for this week (I mentioned this yesterday)
<jdstrand> zyga-ubuntu: 4224 is for today
<jdstrand> zyga-ubuntu: 4140 requires some investigating from me. 4100 I need to think through a little bit more
<zyga-ubuntu> jdstrand: thank you on all counts :)
<mup> PR snapcraft#1763 closed: Make the pip filtering in the Python plugin more fine-grained <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1763>
<zyga-ubuntu> jdstrand: I'm preparing follow-up for layouts, I'd like to finally finish that and I think we are really close now
<jdstrand> sergiusens: 06:47 < jdstrand> not there
<jdstrand> sergiusens: wait, what snap directory? snap/ during the build or in meta/ of the snap?
<jdstrand> zyga-ubuntu: nice
<jdstrand> sergiusens: I have a toplevel snapcraft.yaml. let me put it in snap/
<zyga-ubuntu> oh
<zyga-ubuntu> standup
<zyga-ubuntu> joining
<jdstrand> sergiusens: ok, I moved snapcraft.yaml to snap/snapcraft.yaml, then ran 'SNAPCRAFT_BUILD_INFO=1 snapcraft cleanbuild'. I now have a snap/ directory in the snap, but no manifest
<sergiusens> jdstrand oh, with cleanbuild you need 2.35, the env var wasn't being passed in before
<sergiusens> jdstrand `snap install snapcraft --classic` :-)
<jdstrand> hmmm, if I do that I need to remember what you said to do about lxd and networking
<jdstrand> sergiusens: yes, that worked. thanks
<sergiusens> cjwatson btw, mind if we work on switching snapcraft to use the snap for lp buidlers?
<cjwatson> sergiusens: I don't mind, but how were you planning to go about it?
<cjwatson> it's a bit involved
<sergiusens> cjwatson oh, then step one would be to get an idea of how involved it is :-)
<sergiusens> I had the impression it would be more about testing that s/apt install snapcraft/snap install snapcraft --classic/ was working as expected on staging
<cjwatson> sergiusens: we need to make it be a switch, not just change it in the code (which is harder to roll back, harder to experiment with on particular snaps, etc.); and probably as part of the same chunk of work we need to add channel control
<cjwatson> sergiusens: which means it needs to be propagated down from the LP buildd-manager, and probably needs data model changes
<sergiusens> cjwatson up to LP or even build.snapcraft.io ?
<sergiusens> I'll write up the proposed set of steps on the forum
<cjwatson> sergiusens: not build.snapcraft.io IMO.  We can flip the switch eventually but it needs to be controlled
<cjwatson> sergiusens: IMO the steps are: (1) design data model in LP (possibly taking into account where core is installed from too, at least for the future?) (2) add option to snap build type in launchpad-buildd to cause it to install snapcraft as a snap (3) LP database migration to add whatever new columns we need (4) implement new data model and API changes in LP, and adjust the build args sent to ...
<cjwatson> ... builders (5) possible UI changes
<cjwatson> sergiusens: ordering is important because builders, DB migrations, LP code are all deployed independently so we need to ensure the right kind of compatibility
<niemeyer> cachio: Spread-24 is now a brand new machine
<niemeyer> cachio: Let me know how it goes please
<cachio> niemeyer, great, thanks
<cachio> niemeyer, I'll put an eye on it
<mup> PR snapd#4310 opened: many: allow to configure core before is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310>
<pedronis> mvo: ^    it has conflicts though, what stops merging your PR ?
<jdstrand> zyga-ubuntu: I've not looked at this at all, but fyi https://bugs.launchpad.net/bugs/1734845
<mup> Bug #1734845: hook (core) configure â exit status 1 cannot create lock directory /run/snapd/lock â Permission denied <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734845>
<zyga-ubuntu> jdstrand: ack
<pedronis> mvo: your PR is red
<zyga-ubuntu> jdstrand: I looked at this when initially made aware of this about a week ago, my best theory is this is in a privileged container without apparmor stacking
<jdstrand> zyga-ubuntu: like I said, I don't know, but there are quite a few issues on errors.u.c: https://errors.ubuntu.com/problem/cf07c2fa3f39a98f0b52aaf20ff82faab7969129
<jdstrand> zyga-ubuntu: 515 instances in the last week: https://errors.ubuntu.com/?period=week
<mvo> pedronis: yes, timeout
<mvo> pedronis: interestingly in snap set core prxy.store=fake
<pedronis> real bug?
<mvo> pedronis: maybe but it looks a bit random
<pedronis> it's never been green afaict
<mvo> pedronis: :/
<mvo> pedronis: I debug once I have the nvidia done
<mvo> pedronis: if its real it might be some race, I wonder if something with the state lock, that would explain why it times out, but I don't think there is anything racy in there
<pedronis> mvo: probably something wrong with the lock
<pedronis> that's my guess as well
<pedronis> (that we don't see in the unit tests)
<mup> PR snapd#4311 opened: debian: ensure /var/lib/snapd/lib/vulkan is available <Created by mvo5> <https://github.com/snapcore/snapd/pull/4311>
<pedronis> mvo: I see  corecfg.Run expects to run without the lock, but the new code in hookmgr locks
<mvo> pedronis: heh, that would explain it
<pedronis> I think we need to think a bit who should be responsible for what
<pedronis> mvo: we probably shouldn't lock around the hijack, and make it it's problem
<pedronis> mvo: IÂ need to take my walk break, but IÂ can look in to this afterward
<zyga-ubuntu> jdstrand: FYI, after "plan writable mimic" branch lands I'd like to propose this: https://github.com/zyga/snapd/commit/9b4507bdbfd22f858808924fa45c633209d290c1
<zyga-ubuntu> jdstrand: I think it fits into the discussion and I'm just letting you know in case you need context for the other review
<mvo> pedronis: sounds good, lets sync when you are back, I'm fighting apparmor right now
<zyga-ubuntu> jdstrand: this patch does the execution of the plan and creation of the undo changes
 * zyga-ubuntu jumpst onto the user mount namespace topic
<jdstrand> mvo: is that the include issue or something else?
<mup> PR snapd#4312 opened: snap-confine: create mount target for lib32,vulkan on demand <Created by mvo5> <https://github.com/snapcore/snapd/pull/4312>
<mvo> jdstrand: I was refering to the include issue earlier, but I think its a non-issue now, we fixed it by using #include now instead of "include"
<mvo> jdstrand: well, when I say "we" I mean zyga-ubuntu
<lundmar> Hi guys, I'm looking forward to more +1 in this alias request: https://forum.snapcraft.io/t/request-automatic-aliases-for-lxi-tools/2956 . Thanks! :)
 * jdstrand nods
<jdstrand> lundmar: you don't need any more
<lundmar> oh great. Can it move to next step already?
<jdstrand> lundmar: you have two votes. we just need to wait the allotted time to allow others the opportunity to vote against
<lundmar> ok
<jdstrand> lundmar: then we'll grant the alias. fyi, the voting period is one week, so next monday I'll tally/grant
<lundmar> ok, parience it is then :)
<lundmar> patience*
<mup> PR snapd#4313 opened: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<lundmar> jdstrand: btw, I'm the guy who made the feature request for completions scripts support long ago. I recently revisited snap and I'm happy to see it has been added. However, it seems it is not working for aliased commands.
<Chipaca> lundmar: hello
<mup> PR snapd#4314 opened: interfaces: switch to ConnectedPlug/ConnectedSlot API <Created by stolowski> <https://github.com/snapcore/snapd/pull/4314>
<Chipaca> lundmar: https://forum.snapcraft.io/t/tab-completion-for-snaps-bash/2261
<Chipaca> lundmar: 2.30 has support for aliased commands
<lundmar> Chipaca: Ahh, 2.30 . Got it. Thanks.
<Chipaca> lundmar: let me know how it breaks :-)
<lundmar> of couse, I expect it to :)
<lundmar> courseÃ
<lundmar> course*
<Chipaca> lundmar: also note the completion snippet doesn't "see" the alias
<Chipaca> ie if a snap foo has an app called bar that has a snippet, the snippet is always called as if the user had used foo.bar, even if the user aliased foo.bar to quux and used that
<mvo> pedronis: nvidia is under control, I will fix the locking now (unless you are already on it)
<lundmar> Chipaca: I'll look into to the snippet stuff. The less defintion we have to add to get completion scripts working in its traditional form the better.
<Chipaca> lundmar: you should be able to just drop in the snippet you'd usually drop in /usr/share/bash-completion/completions into you snap, set a 'completer' key in the yaml, and things work. At most you need to make it handle foo.bar instead of just bar.
<lundmar> Chipaca: Like this right? https://github.com/lxi-tools/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml
<Chipaca> lundmar: like so
<lundmar> I'm adding the alias manually, however I noticed it does not work.
<zyga-ubuntu> mvo: what do you know about the locking issue
<zyga-ubuntu> mvo: do you have any theory?
<Chipaca> lundmar: completion, or the alias?
<mvo> zyga-ubuntu: none at all currently :(
<zyga-ubuntu> mvo: question is 2.29 really open as milestone? are you doing a 2.29.x release?
<lundmar> Chipaca: completion not working for the lxi-tools.lxi command nor lxi alias (the latter is most important).
<mvo> zyga-ubuntu: not sure I understand but yes, 2.29 is still open because its not released yet to stable core and also it looks like there are some warts with the SRU
<Chipaca> lundmar: is it the one in the store?
<mup> PR snapd#4311 closed: debian: ensure /var/lib/snapd/lib/vulkan is available <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4311>
<lundmar> Chipaca: yes
<Chipaca> lundmar: complete -o default -F _lxi lxi
<jdstrand> lundmar: glad completion scripts are (finally) getting there for you :) they were a very interesting feature to enable (huge thanks to Chipaca)
<Chipaca> lundmar: that bit in your snippet will only work with "lxi"
<jdstrand> (he did all the heavy lifting)
<Chipaca> lundmar: and that will never get called with 'lxi' because the snap is called lxi-tools
<Chipaca> lundmar: so... you probably ant complete -o default -F _lxi lxi-tools.lxi
<Chipaca> want*
<lundmar> Chipaca: which is just fine. I'm really only interested in it working for the 'lxi' alias, not lxi-tools.lxi
<Chipaca> lundmar: the snippet doesn't see the alias, as i tried to explain
<Chipaca> the snippet always sees the 'canonical' (heh) app name
<Chipaca> lundmar: (because the user can alias it to _anything_ and still want completion to work)
<lundmar> jdstrand: yeah, I know getting it working across confiment was interesting. Now, next feture we need to have first class commandline support is support for the 'man' command to view man pages ;)
<jdstrand> lundmar: work on that recently continued, thanks to cjwatson
<jdstrand> once the confinement is working in the man command, then snapd can implement the bits to put man pages from snaps in the right place
<mup> PR snapd#4309 closed: snap: fix TestDirAndFileMethods() test to work with gccgo <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4309>
<lundmar> Chipaca: Hmm. Then I will have to create a duplicate completion script just for the sake of snap.
<Chipaca> jdstrand: next after that... devhelp :-D
<jdstrand> Chipaca: heh
<Chipaca> lundmar: aw
<Chipaca> lundmar: or! or
<Chipaca> lundmar: âcomplete -o default -F _lxi lxi lxi-tools.lxiâ
<Chipaca> lundmar: that should work in both places
<lundmar> Chipaca: yes, and that line belongs in the completion script (that I will have to create specifically for snap) unless I can somehow add the single line in the .yaml?
<Chipaca> lundmar: i mean, you can ship that line in both places, it won't break stuff
<jdstrand> mvo: whenever is convenient, can you take a look at https://dashboard.snapcraft.io/dev/snaps/8748/feedback/
<jdstrand> mvo: (base-18 issues)
<jdstrand> mvo: I approved it for now, but it would be nice to get it to pass automated review
<mvo> jdstrand: sure
<lundmar> I guess my point is, if possible I want to avoid changing anything in my source to reflects snap support. If possible it would be better to find a way for snap to support standard configurations.
<mvo> jdstrand: thank you, it looks really messy :)
<jdstrand> mvo: (note that r950 of the review tools have changes for base-18 but aren't in prod yet)
<mvo> jdstrand: but note the version number
<jdstrand> mvo: yes. I like your style :)
<mvo> jdstrand: thank you for doing those
<mvo> jdstrand: :P I will work on the errors after the other fires are under control
<Chipaca> lundmar: i didn't find a way for that to work, unfortunately
<mvo> jdstrand: thanks for the heads up
<lundmar> Chipaca: I can see how it is tricky to solve.
<Chipaca> lundmar: that is: users can decide not to install your aliases (snap install --unaliased), or to override it with anything else, and we still want completion to work in those cases
<Chipaca> if there's a trick i missed, i'd be happy to learn it
<lundmar> Chipaca: I'm thinking what if we define âcomplete -o default -F _lxi lxi lxi-tools.lxiâ directly or indirectly (through simple key) and have that be picked up and source by some of the command wrappers. This way we can support standard completion scripts and end users don't have to touch their original completion scripts.
<lundmar> sourced*
<Chipaca> lundmar: doable but a lot of work, because of how hairy complete can get
<lundmar> I mean, we could create maybe a completer-alias: lxi-tools.lxi key and support it that way.
<cjwatson> jdstrand: Yeah, I landed the apparmor work in unstable/bionic but I still need to finish the seccomp work
<lundmar> the have the command wrapper source the completer script in case the _lxi bash function does not already exist (not sourced before). Might be simple to do.
<lundmar> then*
<lundmar> Chipaca: either way, users are free to change aliases manually. It seems to me we need to figure out a way to support that. I think changing the command wrapper accordingly might be a way.
<mvo> pedronis: my local spread run appears to be happy now, fingers crossed for the spread run
<pedronis> mvo: thanks, I think the test need some tweaking to fail earlier
<mvo> pedronis: the spread test you mean?
<mvo> pedronis: or do you mean we need a unit test that tests this particular combination ?
<pedronis> mvo: no, the unit tests, IÂ think the Mock function in configstate is a bit strange
<pedronis> it mocks too much
<pedronis> anyway I'm picking up the branch to work a bit on this
<mvo> pedronis: much appreciated, thank you
<Chipaca> lundmar: in all the above you refer to 'command wrappers'. What do you mean?
<pedronis> mvo:  am IÂ confused, or there are no tests for the hijack in  configstate itself?
<Chipaca> lundmar: note that if your snap were called just 'lxi' things would just work :-)
<mvo> pedronis: iirc only indirect via coreCfgRun mocking
<mvo> pedronis: so +1 for adding one, let me know if I should do this. sorry for this
<pedronis> mvo: no, the mocking is not called in configstate
<pedronis> it's only used far away (devicestate)
<mvo> pedronis: autsch, indeed
<pedronis> I'll see if I can add one
<lundmar> Chipaca: Yes, however - that is not an option. We can't name all snaps after the primary tool it includes ;)
<Chipaca> lundmar: one can dream though
<Chipaca> lundmar: (also: why not?)
<mvo> pedronis: please let me know if its too annoying, then I will do it :)
<kyrofa> sergiusens, is there a reason we're using mypy 0.540 instead of the newest?
<lundmar> Chipaca: image a snap package with many tools (apps). You would need aliases for each app to avoid the <snap name>. prefix.
<lundmar> imagine*
<kyrofa> If not, mind if I update?
<Chipaca> lundmar: most tools that are parts of a whole do have a common prefix or suffix, though
<lundmar> Chipaca: I assume the overall goal with aliases is to make it possible for the users to never know they are using a snap.
<lundmar> that is very aliases become powerfull feature
<lundmar> where*
<lundmar> Chipaca: I was looking at this file: /snap/lxi-tools/current/command-lxi.wrapper
<Chipaca> lundmar: ah, that's a snapcraft thing
<Chipaca> not sure what's in there today
<Chipaca> (haven't had to look in a while because it mostly just works)
<lundmar> Chipaca: oh, it's not used when firing commands?
<Chipaca> lundmar: completion doesn't run the command though
<lundmar> I thought maybe this file was fired every thing you fire the lxi-tools.lxi command
<kyrofa> lundmar, indeed it is
<kyrofa> lundmar, that's how snapcraft gets the LD_LIBRARY_PATH in there, runs any required setup scripts, etc.
<lundmar> in which case it would be possible to add a check to see if the e.g. _lxi function (defined via eg. new completer-alias key) and if the _lxi function does not exist it will simply source the completion script.
<zyga-ubuntu> jdstrand: I'll resume work on the base snap staleness issue
<kyrofa> Hey zyga-ubuntu, any more progress on the lxd upgrade issue?
<zyga-ubuntu> kyrofa: no, not yet
<Facu> sergiusens, so, my last commit in the metadata branch failed in travis with "The job exceeded the maximum time limit for jobs, and has been terminated." ... what should I do?
<Facu> roadmr, matiasb ^
<matiasb> hm.. no idea, trigger it again? :/
<mup> PR snapcraft#1580 closed: cli: setup gitignore when working from git directory at init <Created by msis> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1580>
<roadmr> Facu: I'd trigger it again. Travis is brutal, it takes ages :(
<Facu> roadmr, ack
<Chipaca> lundmar: https://forum.snapcraft.io/t/2972?u=chipaca
<jdstrand> sergiusens: I meant to ask before, are snap rebuilds expected to work now? I tried by just copying manifest.yaml over snapcraft.yaml but it didn't work. if it is expected to work, what is the right way to do it?
<roadmr> jdstrand: hey, we made a proposal on how to solve https://bugs.launchpad.net/snapstore/+bug/1732781, could you check the last comment (mine!) and let me know if that sounds acceptable? if not, I'm happy to find other alternatives
<mup> Bug #1732781: store should detect and reject changing snap types <Snap Store:New> <https://launchpad.net/bugs/1732781>
<jdstrand> roadmr: oh I missed that
 * jdstrand reads
<roadmr> :D
<jdstrand> roadmr: commented
<roadmr> thanks1
<roadmr> !
<jdstrand> hehe
<pedronis> mvo: I noticed that configmanger has still the runner but now is unused
<pedronis> mvo: I pushed the test and tweaks if you want to look
<Facu> roadmr, the github page says "failed", should it say "testing" or something?
<lundmar> Chipaca: great, let me get back to that thread later. I have a few things to take care of first.
<Chipaca> lundmar: forum is async \o/
<lundmar> my brain is async :D
<pdefreitas> hello guys, I'm looking forward to get a full dev reference of snapcraft. Can anyone guide me regarding that?
<zyga-ubuntu> pdefreitas: hey, did you see snapcraft.io
<zyga-ubuntu> pdefreitas: we have a forum, tutorials and other documents
<roadmr> Facu: let me check
<niemeyer> mborzecki: Btw, I don't know if I ever sent you the link to https://forum.snapcraft.io/t/task-workflow-in-the-forum/206
<pdefreitas> yes, I did, but I am looking for more advanced reference.
<niemeyer> mborzecki: I know we talked about it, but I don't recall if I did send the link or not
<mborzecki> niemeyer: thanks, i'll check it out
<mvo> pedronis: re runner> yeah, we can kill that one again I think
<pedronis> mvo: IÂ pushed the test if you want to look
<pedronis> mvo: killing the runner, yes, don't know if it's urgent
<mvo> pedronis: test is nice, thank you
<niemeyer> mborzecki: I just removed one of your nick tags from a topic because I thought you forgot to drop that when you dropped upcoming or backlog, but now I realize that you were probably not aware of those conventions
<mvo> pedronis: probably not urgent, I make a note and fix it in my morning
<zyga-ubuntu> pdefreitas: which topic in particular are you interested in?
<mborzecki> niemeyer: yup, i was not
<roadmr> Facu: checking how to re-trigger the travis run
<Facu> roadmr, thanks
<mvo> pedronis: nice simplification in your commit, thanks for this
<roadmr> Facu: I don't think I can trigger a rebuild, you might be able to, I found some advice in https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit
<Facu> roadmr, but if I close the PR and reopen it again won't lose all the conversation?
<Facu> sergiusens, you have write access to the repo? may re-trigger that travis?
<roadmr> Facu: yes, that sounds scary :( sounds like the best option is to get someone with write access to retrigger the build
<mup> Issue snapcraft#1767 opened: stage-packages does not respect architectures <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1767>
<Chipaca> niemeyer: ping
<niemeyer> Chipaca: pongus
<Chipaca> niemeyer: running spread with -debug, and not getting shell prompts; instead i'm getting âError running debug shell: EOFâ
<Chipaca> niemeyer: and then âError restoring linode:ubuntu-14.04-64:tests/main/ : EOFâ
<niemeyer> Chipaca: That means a disconnection
<niemeyer> Chipaca: Thus no shell
<Chipaca> niemeyer: 20+ in a single run?
<niemeyer> Chipaca: Clearly something wild going on
<pdefreitas> zyga-ubuntu: the use of interfaces, in particular the bluez interface
<niemeyer> Chipaca: Note that if the connection is killed in general it's not reestablished, as Spread assumes the machine is in a random state
<Chipaca> niemeyer: i can tell you think you're explaining something to me, but alas
<Chipaca> niemeyer: "a disconnection" -- what disconnected?
<niemeyer> Chipaca: The Spread connection to the machine
<niemeyer> Chipaca: ssh
<Chipaca> niemeyer: so, all my ssh's disconnected
<Chipaca> because they're all doing the same thing
<niemeyer> Chipaca: Were you connected to multiple machines, or a single machine?>
<Chipaca> but, if it disconnected, how is it still reporting progress?
<niemeyer> Chipaca: IOW, was it a full run, all systems in Linode, or a custom run with only a single machine?
<Chipaca> niemeyer: a full run on linode
<niemeyer> Chipaca: Ok, so that tastes a lot like a local network hiccup
<Chipaca> niemeyer: if the EOF is a disconnect, how does it continue after that?
<niemeyer> Chipaca: If all machines were disconnected at once, your ISP might have quickly bounced your connections
<niemeyer> IP change or whatever
<niemeyer> Chipaca: It does not continue.. not on the EOFd machine.. that's why no shell
<niemeyer> Chipaca: So the tasks will keep up waiting, and if nothing else picks up (a second worker with the same exact system, if any) the remaining tasks are reported as Aborted at the end
<Chipaca> niemeyer: i'm not sure that matches what i see, but fair enough; i'll wait for it to finish and then kick it off again
<niemeyer> Chipaca: If the errors is across machines, it needs to be network related
<niemeyer> Chipaca: Even more if it's an EOF, that's a huge hint
<niemeyer> Chipaca: Either on your end, or on Linode's
<niemeyer> Chipaca: We have half of our systems on our DC and half on another.. if vaguely half of your systems got an EOF, I'd suspect one data center got a kick
<niemeyer> Sorry, s/our DC/one DC/
<Chipaca> niemeyer: this is an excerpt of what I see (removed the "running late" lines): https://pastebin.canonical.com/204297/
<Chipaca> niemeyer: the thing that puzzles me is that, if each EOF takes a machine out of the pool, and we have 4 14.04 workers, how are there so many more than 4 EOFs?
<Chipaca> niemeyer: i think i can answer that now though
<niemeyer> Chipaca: I see, so the EOF actually happened on a single system
<Chipaca> it's an EOF for the debug output, an EOF for the two restores (test and project) and an EOF for the debug shell itself
<niemeyer> Chipaca: Looks like Spread is not realizing the EOF isn't going away any time soon, and should stop trying to debug those
<Chipaca> niemeyer: or that :-)
<niemeyer> Chipaca: This is a single system, most likely a single machine too
<niemeyer> Chipaca: (most likely because we have multiple workers per system)
<pdefreitas> If I want to run multiple snaps that use the very same bluetooth API (bluez) would I have any kind of trouble? Are they independent?
<kyrofa> mpt, cprov I'd like to meet with you two some time this week to discuss `snapcraft enable-ci`. Any chance you have some slots available?
<mpt> kyrofa, itâs possible, but weâre in quite different time zones, so check the calendars
<kyrofa> mpt, alright, will do
<kyrofa> snappy-m-o, autopkgtest 1765 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> Noo, wrong PR
<kyrofa> snappy-m-o, autopkgtest 1760 xenial:i386
<snappy-m-o> kyrofa: I've just triggered your test.
<cprov> kyrofa: I am available, please schedule something in my calendar too.
<kyrofa> Thanks cprov, taking a look now :)
<kyrofa> sergiusens, by the way, given that it's just us and we talked this morning, I have nothing new for our 1-1 today. Want to skip?
<kyrofa> mpt cprov invite sent
<zyga-ubuntu> pdefreitas: re, sorry for lagging
<zyga-ubuntu> pdefreitas: so I was thinking about this and indeed I could not find any good documentation
<sergiusens> kyrofe sure
<zyga-ubuntu> pdefreitas: but in fact we have an interface for bluetooth and we even provide a good snap for core devices
<sergiusens> Facu sure, just finished lunch with perrito
<zyga-ubuntu> pdefreitas: perhaps you could start a topic on the forum and this topic could, over time, transform into a documentation of those aspects (the canonical bluez snap, the bluez and bluetooth-control interfaces
<cachio> zyga-ubuntu, did you see that? https://travis-ci.org/snapcore/snapd/builds/308480596#L4586
<cachio> zyga-ubuntu, It is not happening always
<cachio> I am trying to reproduce it here but I can't
<sergiusens> kyrofa do you have an ETA on that split?
<kyrofa> sergiusens, PR modified, tests running
<sergiusens> kyrofa great, because everything is timing out :-)
<kyrofa> sergiusens, ugh
<davidcalle> pdefreitas: zyga-ubuntu: we have a bluez snap reference here https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/
<davidcalle> (not sure if it's advanced enough, though)
<KrzysiekSiemv> Hi!
<zyga-ubuntu> cachio: looking now
<zyga-ubuntu> + rm -rf /snap
<zyga-ubuntu> looots of "read-only file system"
<zyga-ubuntu> snaps are still mounted
<zyga-ubuntu> cachio: it may be related to the LXD issue
<zyga-ubuntu> cachio: it would be good (if you ever get to reproduce it) what is the state of the mount table then (/proc/self/mountinfo)
<zyga-ubuntu> davidcalle: awesome, could we link to that page from the forum
<andre-geert> hey all, I have a question about encryption
<andre-geert> we are considering adopting Snappy Core to replace some of our existing OS on devices
<zyga-ubuntu> andre-geert: hey
<andre-geert> we would be producing a snap (not published on the store)
<m4sk1n> hi
<zyga-ubuntu> andre-geert: you can publish that snap on your own LAN in your private store proxy
<zyga-ubuntu> hey m4sk1n
<andre-geert> and would want that snap (and all the configuration/generated data) to live on an encrypted partition
<andre-geert> ah, that's good to know, thanks!
<andre-geert> is there a way to choose the install directory (symlink before an install, etc?)
<zyga-ubuntu> andre-geert: are you thinking about a "core" system where you just use snaps or a classic system that is a hybrid of other packages and snaps?
<cachio> zyga-ubuntu, still trying to reproduce it
<zyga-ubuntu> andre-geert: we don't have support for encrypted partitions _yet_ AFAIK
<zyga-ubuntu> andre-geert: unless canonical commercial engineering has something I'm not aware of (they might), it'd be worth asking on the forum
<zyga-ubuntu> andre-geert: on a classic system you can certainly use snaps and encrypted disk or home partition
 * Chipaca sees the time and disappears in a cloud if tardy smoke
 * zyga-ubuntu never knew chipaca was a genie but that explains a lot of things :)
<davidcalle> I'm looking for a Polish native speaker https://github.com/canonical-websites/tutorials.ubuntu.com/pull/505
<davidcalle> zyga-ubuntu: would you happen to know one, reasonably well versed in snaps too ? :-)
<sergiusens> zyga-ubuntu stgraber any idea why I cannot mount snaps in lxd on fedora or non ubuntu kernels in general?
<zyga-ubuntu> davidcalle: re
<lundmar> zyga-ubuntu: Hi. Are you aware of any issues with accessing the avahi-daemon via the avahi-observe plug on Ubuntu snap? I notice that my lxi-tools snap (see https://github.com/lxi-tools/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml) works fine in Fedora but not on Ubunu 17.10 (it reports avahi daemon not running, despite it works fine when not using snap).
<zyga-ubuntu> davidcalle: hehe gladly :)
<zyga-ubuntu> lundmar: oh, interesting, do you have any apparmor denials when you do that?
<zyga-ubuntu> lundmar: I'm not immediately aware of any issues but I didn't look at the interface code,
<lundmar> I haven't checked, I'm running defaults
<zyga-ubuntu> lundmar: let me check the PR from davidcalle first and I'll look at avahi-observe next
<zyga-ubuntu> lundmar: dmesg | grep DENIED
<lundmar> zyga-ubuntu: thanks
<lundmar> zyga-ubuntu: correct, I get some DENIED messages for lxi-tools regarding avahi daemon. Should i use the avahi-control plug instead?
<lundmar> I thought the avahi-observe plug was meant for clients (which should be my case).
<zyga-ubuntu> lundmar: not sure, show the denials and what you were expecting to do
<zyga-ubuntu> lundmar: bonus points for asking on the forum ^_^
<sergiusens> davidcalle are you a mentor for codein? you don't seem to be on #ubuntu-google
<lundmar> well, irc is always a good starting point ^^
<lundmar> I'll try avahi-control, if that does not work I'll ask aroun in the forum. thanks.
<sergiusens> zyga-ubuntu now answer me :-)
<lundmar> around*
<lundmar> Ahh, i think I know what is the issue. The avahi-observe nor the avahi-control plug autoconnects to any snaps.
<lundmar> so the snap providing the avahi daemon is not connected/loaded.
<zyga-ubuntu> lundmar: ah, that explains it
<lundmar> yup, 'snap connect lxi-tools:avahi-observe :avahi-observe' and now it works fine.
<lundmar> is there any way to avoid firing this command to make it work automagically?
<lundmar> I mean, can I add something to the snapcraft.yaml to make it work
<zyga-ubuntu> yes
<lundmar> I guess Fedora runs a more relaxed security policy and simply autoconnect most plugs
<zyga-ubuntu> lundmar: you can request your snap declaration to contain some language that will make that connection happen automaticlaly
<zyga-ubuntu> but this is per-snap store-side decision
<zyga-ubuntu> lundmar: no, on fedora you don't have the confinement that kept that from connecting
<zyga-ubuntu> apparmor does DBus mediation
<lundmar> zyga-ubuntu: I understand. Makes sense. So I should request a vote for it like I recently did a request for aliases?
<lundmar> Fedora is not running apparmor?
 * lundmar is not that familiar with the internals of Fedora
<zyga-ubuntu> yes
<zyga-ubuntu> lundmar: nope
<zyga-ubuntu> lundmar: fedora uses SELinux and SELinux doesn't (AFAIK) do per-method mediation (though maybe I'm wrong, Pharaoh_Atem can correct me probably)
<lundmar> zyga-ubuntu: got it. Thanks for you help. FYI - your *-ubuntu nick makes you a natural target for Ubuntu questions ;)
<lundmar> your*
<zyga-ubuntu> davidcalle: done
<zyga-ubuntu> lundmar: haha, nice
<zyga-ubuntu> lundmar: I use many OSes and I keep the -$OS suffix to avoid them from crashing
<zyga-ubuntu> on crazier days there's a good chunk of zyga's in the channel
<zyga-ubuntu> davidcalle: please look at my review
<davidcalle> zyga-ubuntu: that was fast o_o
<zyga-ubuntu> davidcalle: with such a large minority of snapd developers using polish that is something we could perhaps look at periodically
<zyga-ubuntu> davidcalle: polish is probably 1st native language in the team :)
<zyga-ubuntu> davidcalle: some things need changes in the original
<zyga-ubuntu> davidcalle: I'd rip out gentoo (see my comment) and actually put solus in its place
<davidcalle> zyga-ubuntu: definitely
<zyga-ubuntu> davidcalle: solus has great snapd integration and has some interesting features (thank you ikey) straight from the distributor
<zyga-ubuntu> (and is preinstalled now)
<mup> Issue snapcraft#1710 closed: Research circle-ci <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1710>
<lundmar> guys, just one question more. Am I correct to assume that my lxi-tools snap does not connect the hosts avahi daemon but rather it connects to an avahi-daemon runnning in another snap?
<zyga-ubuntu> lundmar: on classic, it talks to the normal avahi daemon running on the host
<zyga-ubuntu> jdstrand: any chance for a 2nd look on https://github.com/snapcore/snapd/pull/4224 today?
<mup> PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
<mup> PR snapd#4315 opened: cmd/snap-update-ns: add code that executes a plan for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga-ubuntu> I need a review for https://github.com/snapcore/snapd/pull/4315
<mup> PR #4315: cmd/snap-update-ns: add code that executes a plan for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<kyrofa> snappy-m-o, autopkgtest 1760 xenial:amd64
<lundmar> zyga-ubuntu: Great thanks. Then I understand correctly.
<snappy-m-o> kyrofa: I've just triggered your test.
<lundmar> I've put a vote here if anyone would like to +1 it :) https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976
<lundmar> I mean, request.
<mup> PR snapcraft#1766 closed: Enhanced fake store to detect that metadata can't be pushed prior to pushing the binary, and fixed the test <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1766>
<mup> PR snapd#4298 closed: many: remove configure-snapd task again and handle internally <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4298>
<Facu> yay
<jdstrand> zyga-ubuntu: yes, done
<zyga-ubuntu> thanks, looking
<kyrofa> sergiusens, snapcraft#1760 is green on Travis anyway
<mup> PR snapcraft#1760: tests: move the catkin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1760>
<kyrofa> Your call on adt
<kyrofa> plugins suite is back to 44 minutes or so
<zyga-ubuntu> jdstrand: thank you!
<zyga-ubuntu> jdstrand: I tried to document and be clear about everything in https://github.com/snapcore/snapd/commit/5e75000f604a2eddece5c1c3669164999b453b2d
<zyga-ubuntu> jdstrand: not sure if you have the time to look at that today
<jdstrand> zyga-ubuntu: I added it to my todo to review as part of your next PR
<jdstrand> zyga-ubuntu: is that not sufficient?
<jdstrand> zyga-ubuntu: ie, part of PR 4315?
<mup> PR #4315: cmd/snap-update-ns: add code that executes a plan for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga-ubuntu> jdstrand: yeah, that's the same thing
<zyga-ubuntu> jdstrand: thanks, I should stop nagging :)
<kyrofa> zyga-ubuntu, alright, any ETA on the lxd upgrade issue, then? It's super painful, and has been for months
<zyga-ubuntu> kyrofa: it's in the top of my list but I'm rotating among this and two other topics
<zyga-ubuntu> kyrofa: I'll talk to mvo tomorrow and plan something based on past attempts
<kyrofa> Haha, so your list is a lazy susan?
<kyrofa> Thanks zyga-ubuntu
<zyga-ubuntu> lazy susan?
<zyga-ubuntu> not sure what that is but I try to keep it close to roundy robin
<mup> PR snapcraft#1760 closed: tests: move the catkin integration tests to a separate suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1760>
<mup> PR snapcraft#1718 closed: lxd: let lxd choose the architecture <Created by mwhudson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1718>
<mup> PR snapcraft#1768 opened: project: export the arch triplet into the environment <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1768>
<Pharaoh_Atem> zyga-ubuntu: I don't know if per-method mediation is supported, you should ask the SELinux guys
<Pharaoh_Atem> I suspect it may be partially there
<ikey> i saw a ping but i know not why
<ikey> cursed be the small back buffer..
<mcphail> ikey: 19:53 < zyga-ubuntu> davidcalle: solus has great snapd integration and has some interesting features (thank you ikey) straight from the distributor
<ikey> o. :3
 * ikey doesn't get context now xD
 * ikey buys a bigger backbuffer
<ikey> (ty for sharing ^^)
<mcphail> ikey: http://termbin.com/gbqm
<mcphail> context is everything
<ikey> ty ^^
#snappy 2017-11-29
<kyrofa> Anyone around here have any GPIO experience on raspberry pi 2? https://forum.snapcraft.io/t/raspberry-pi-2-missing-gpio-slot/2979
<ogra_> sorry for sounding like a broken record kyrofa ...
<kyrofa> ogra_, oh you're being super helpful, and I know this isn't on you :)
<kyrofa> ogra_, but I... just can't believe it :
<kyrofa> :P
<ogra_> kyrofa, well, seems niemeyer thinks it is safe ... so we'll see what happens
<ogra_> the answer sounds like a "soon" :)
<niemeyer> ogra_: No, I don't just think it is safe.. I'm saying the specific reason for which these images were held back for a very long time was investigated and turned out to be a non-issue in practice, after actual verification of the specific differences between the old kernel and the new kernel... the kernel team agrees this is a good path to take.
<ogra_> niemeyer, well, it is not "old vs new kernel" but old dtb in the gadget with new kernel binary ... if the research showed that all HW works 100% in that constellation, thats fine indeed (though given that we changed config options for peripherials over time this surprises me)
<ogra_> (specifically the overlay dtbs ... and even more specifically the graphics stack (which is actually used by customers in production) ...)
<ogra_> (IIRC the kernel in stable did not even have the vc4 driver enabled so the dtb overlay will be missing or broken)
<ogra_> but i trust that you guys tested all this :)
<niemeyer> ogra_: No, you actually don't.. this is called irony, and also passive aggressiveness. It's unhealthy when we work together with people.
<ogra_> niemeyer, i meant what i said ... sorry that you interpreted the smiley as irony, i was just trying to be firendly ...
<niemeyer> ogra_: No, you really didn't. The fact you can't be honest to yourself about this is part of the issue.
<ogra_> niemeyer, well, i had different results when testing it myself, there are 98 overlay dtbs shipped in the gadget for addon HW along with the main dtb and there were many changes ... but i also fully trust paolos expertise if he says it is fine, he is definitely more expert than me ... i really dont try to be ironic oer anything
<niemeyer> ogra_: We are not updating any of those dtbs.. We are updating the kernel.
<ogra_> err
<niemeyer> ogra_: Yes, things can break, always, on any update.
<niemeyer> ogra_: We'll do our best to keep things stable and working.
<niemeyer> ogra_: And it's exactly for that sort of reason we have a release process. Anyone using Ubuntu Core and the kernel snap in real production environment *must* be testing it.
<niemeyer> The release will go into beta, and into candidate, and then into stable.
<mup> Issue snapcraft#1709 closed: Extract macaroon retrieval into more generic place <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1709>
<mup> PR snapcraft#1765 closed: store: refactor acquirement of attenuated macaroon <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1765>
<ogra_> niemeyer, are your mongodb snapcraft.yamls anywhere public ?
<ogra_> ( i dont see a mongo repo under your GH account)
<niemeyer> ogra_: Haven't been updated in a while, but haven't changed much either:
<niemeyer> github.com/niemeyer/snaps
<ogra_> thanks !
<niemeyer> np
<lundmar> anyone know if there is a plug interface available that allows access to NFS network mounted home directories? (the 'home' interface is apparently not sufficient).
<lundmar> I can't seem to find anything useful in the docs regarding this.
<lundmar> specificall I need to be able to write in a NFS network mounted home dir.
<lundmar> +y
<mup> Issue snapcraft#1752 closed: export the arch triplet variable during build time <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1752>
<mup> PR snapcraft#1768 closed: project: export the arch triplet into the environment <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1768>
<ogra_> lundmar, https://forum.snapcraft.io/t/snaps-and-nfs-home/438 discussed this
<mup> PR snapcraft#1557 closed: cleanbuild: add a --image option to build in a different image <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapcraft/pull/1557>
<mup> PR snapcraft#1769 opened: lxd: add an --image argument to cleanbuild <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1769>
<lundmar> ogra_: ok thanks. So it looks like NFS mounted home suppor is arriving in snap v2.29
<lundmar> support*
<ogra_> which should technically be released already
 * ogra_ sees 2.29.3  in "snap version"
<lundmar> too bad many if the distributions running snapd are hopelessly behind in snapd version :/
<lundmar> of*
<ogra_> well, it will eventually dripple down into all of them
<lundmar> true
<ogra_> (would be great if all of them would do re-exec like ubuntu does .... then it wouldnt really matter since snapd would com from the core snap)
<lundmar> ogra_: oh, thats clear. So that way the old snapd process gets replaced by the new snapd.
<ogra_> yeah
<ogra_> and snapd does just update along with the core snap
<ogra_> so you dont need to wait for a distro package to be updated
<mup> PR snapcraft#1770 opened: Add codespell support <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1770>
<mup> PR snapcraft#1764 closed: snapcraft.yaml: use gcc to determine tuple <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1764>
<mup> PR snapcraft#1771 opened: lxd: suppress traceback when lxc launch / init fails <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1771>
<mup> PR snapcraft#1772 opened: Release changelog for 2.36 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1772>
<sergiusens> snappy-m-o autopkgtest 1772 xenial:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<ogra_> grrr ... why is vt.handoff= not working right in core
 * ogra_ wonders if thats subiquitys fault ... 
<mborzecki> morning
<koza> mborzecki, hey
<mup> PR snapd#4224 closed: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4224>
<zyga-ubuntu> good morning
<zyga-ubuntu> mvo: hey, what are your release / branch plans for today?
<zyga-ubuntu> mvo: looking at the 2.30 tags we have a few branches still open
<mborzecki> zyga-ubuntu: morning
<zyga-ubuntu> hey :)
<mborzecki> mvo: hey
<mvo> zyga-ubuntu: hey, good morning. yeah, branch happens as soon as we get the blockers out of the way
<mvo> mborzecki: hey, good morning
<zyga-ubuntu> mvo: I recall pedronis said something about some blocker yesterday, is that already reflected in the list of PRs?
<mborzecki> https://github.com/snapcore/snapd/commit/308c7ca6315a56fcc1028f3d9aeddb465c51c0d4 other distros should do the same I suppose?
<mvo> zyga-ubuntu: yes, the list should be accurate
<zyga-ubuntu> mborzecki: yeah, I was thinking about htat
<zyga-ubuntu> mborzecki: idea
<zyga-ubuntu> mborzecki: add a make install code to data
<zyga-ubuntu> mborzecki: let that handle all mkdir's
<zyga-ubuntu> mborzecki: and let that handle distro differences as well
<zyga-ubuntu> mborzecki: then drop the random code from packaging that just creates those directories
<zyga-ubuntu> mborzecki: then we have one place
<zyga-ubuntu> mborzecki: and packaging will at most complain about unpackaged directories
<zyga-ubuntu> mborzecki: +1/-1?
<mborzecki> iirc you'll still have to list the directories, eg in rpm spec
<zyga-ubuntu> mborzecki: yes but then you know when you messed up in packaigng
<zyga-ubuntu> mborzecki: and the directories are the same in one central place
<mborzecki> right
<mborzecki> but yeah, sounds like a good idea
 * zyga-ubuntu needs a review on 4315
<mborzecki> on top of this, i'm not quite fond of data/ makefile taking some vars in command line while we pass those to cmd/ configur already
<zyga-ubuntu> mborzecki: is configure setting any environment we can reuse?
<zyga-ubuntu> mborzecki: anyway, I'm sure you can refactor it to be nicer :)
<mborzecki> something to explore perhaps
<mborzecki> where do we keep a backlog of things to explore/revisit?
<zyga-ubuntu> mborzecki: on the forum
<zyga-ubuntu> mborzecki: tag with your name and "backlog"
<mborzecki> oh, ok
<mborzecki> discourse ux is not what i expected it to be after hearing so many good things about
<mborzecki> zyga-ubuntu: https://forum.snapcraft.io/t/2984
 * zyga-ubuntu looks
<mborzecki> at least there'd be no need to pass various *DIR settings to data/Makefile
<haisheng>  how should I package the base system(customized base ubuntu) to the snap ? I don't wamt to use the maintained Ubuntu one. any info about it can be provided ? Thanks.
<zyga-ubuntu> haisheng: hello
<zyga-ubuntu> haisheng: can you tell me more about what you mean
<haisheng> I want to customize the base snap image.
<haisheng> https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#2
<zyga-ubuntu> haisheng: do you intend your base snap to be used for booting the system or just as a runtime for some apps?
<haisheng> used for booting the system
<zyga-ubuntu> mvo: ^
<haisheng> I am from china. And my english is not good. sorry for that.
<zyga-ubuntu> haisheng: I think this is something we are still exploring/building but mvo is focusing on that more than I do
<zyga-ubuntu> haisheng: no worries :)
<zyga-ubuntu> haisheng: what kind of changes would you like to make to your base snap?
<mvo> haisheng: hey, welcome! for now you can explore by just modifying the "core" snap. however very soon you will be able to make bootable base snaps. but right now the base snaps are not integrated into the boot process, so you can use base snaps today for applications but not yet to boot the system. but we are currently working on making this happen
<haisheng> the ubuntu base snap has three snap at least. include a core snap and  a kernel snap .and i want to customize that core snap and kernel snap.
<haisheng> ok,thanks. show can i modify the "core" snap, and info can be provided for reference.
<zyga-ubuntu> haisheng: can you describe the kind of changes you want to make?
<haisheng> In fact, I just want to know how the roofs can be packaged the snap
<haisheng> how base system can be packaged the snap
<zyga-ubuntu> haisheng: ikey here is making use of base snaps for app runtimes; he builds a non-ubuntu based rootfs
<zyga-ubuntu> haisheng: but he uses it for apps, not for booting the system
 * ikey flicks into life
<zyga-ubuntu> (in his case the system is a classic distribution like ubuntu or solus)
<ogra_> mvo, proof of concept ... https://github.com/ogra1/pc-splash-gadget/commit/b8ea0f98fb5c3e5dfa40b7ed14a652a43a39458d (using split-initrd for showing a splash screen in a grub based image ... works great)
<zyga-ubuntu> mborzecki: can you do a 2nd review on 4291
<zyga-ubuntu> mborzecki: this will help chipaca's other branch
<mborzecki> ok, looking now
<zyga-ubuntu> thank you
<haisheng> ok , zyga-ubuntu, thanks. how can i customize the base snaps for app runtimes. any info about it can be provided.
<zyga-ubuntu> haisheng: please look at the forum (forum.snapcraft.io), it's documented there
<mvo> ogra_: aha, nice
<ogra_> so spit initrd for modules shouldnt be any prob either ...
<ogra_> *split
<ogra_> (testing it on grub was the remaining missing bit)
<mborzecki> zyga-ubuntu: added comments to #4291, I'm not sure sure about SYS_GETUID and SYS_GETUID32, perhaps you can comment on this as well but it feels like something that should be looked at
<mup> PR #4291: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <https://github.com/snapcore/snapd/pull/4291>
<zyga-ubuntu> mborzecki: yeah, I thought about that when reviewing this and I assumed that the older syscall is just not exposed
<zyga-ubuntu> mborzecki: but indeed worth checking
<zyga-ubuntu> john is not around yet, it seems
<mup> PR snapd#4161 closed: snapstate: add support for refresh.schedule=managed <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4161>
<mborzecki> looks like Go uses SYS_GETUID32 on 32bit arches, https://github.com/golang/go/search?utf8=%E2%9C%93&q=SYS_GETUID32&type=
<ikey> rewrite snapd in C when?
<ikey> *runs*
<ogra_> pfft ...
<ogra_> shell ... C is boring
<ikey> :O
<Chipaca> zyga-ubuntu: good catch on the GETUID32 thing! i shall now add a test and do penance
 * Chipaca wonders if people will notice penance is actually just more coffee
<zyga-ubuntu> Chipaca: is it, I'm not sure if your syscall is wrong, I didn't check the number
<Chipaca> zyga-ubuntu: yes
 * ikey starts on libsoup/glib2/libxml2/glib-networking/gnutls/gobject powered "lightweight" snapd fork
<zyga-ubuntu> ikey: don't forget adding scheme "for scripting"
<Chipaca> ikey: WAT
<ikey> oh we could use libpeas
<ikey> python plugins
<zyga-ubuntu> no no, use guile
<ikey> yeah i think you might be right there
<ikey> >_>
<Chipaca> am i missing context for this, or is it just too early?
<Chipaca> i can go away and come back at noon
<ikey> Chipaca, im just on a wind up
<ikey> proposing the most offensive combination of technology possible :p
<ikey> hm I *did* forget the bytecode VM ..
<pedronis> mvo: hi, #4281 looks in a sane state to me, don't know if you want to wait for Gustavo to re-review
<mup> PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
<pedronis> zyga-ubuntu: yes, it is in the list, #4310
<mup> PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310>
<zyga-ubuntu> pedronis: great, thank you for confirming
<mborzecki> zyga-ubuntu: added some questions to #4315
<mup> PR #4315:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga-ubuntu> mborzecki: thank you
<zyga-ubuntu> mborzecki: replied, thanks
<zyga-ubuntu> ugh, more snow
<pedronis> #4310 needs a 2nd review
<mup> PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310>
<mup> Issue snapcraft#1773 opened: Please upgrade brew version <Created by fengerzh> <https://github.com/snapcore/snapcraft/issue/1773>
<Chipaca> ok, i've got to go see the doc; bbl
<mvo> pedronis: re 4281> checking it now
<pedronis> zyga-ubuntu: judging from the coverage report on one of my branches it seems the snap-update-ns are not deterministic I see random coverage changes there, and IÂ haven't touched them
<zyga-ubuntu> pedronis: let me look, probably sorting
<zyga-ubuntu> pedronis: I cannot reproduce this
<zyga-ubuntu> pedronis: I tried watch -n 1 -d "go test -cover -coverprofile=coverage.out && go tool cover -func=coverage.out"
<zyga-ubuntu> pedronis: (in the cmd/snap-update-ns) directory
<zyga-ubuntu> pedronis: and the only thing that varies slightly is time
<zyga-ubuntu> pedronis: which commit are you on?
<pedronis> ok, just weirdness then
 * zyga-ubuntu -> tea
<mup> PR snapd#4316 opened: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4316>
<zyga-ubuntu> Chipaca: should "snap switch --devmode" be a thing?
<Chipaca> zyga-ubuntu: only if snap switch --undevmode is a thig
<zyga-ubuntu> Chipaca: snap switch --strict
<zyga-ubuntu> I think there's no way to toggle devmode now
<Chipaca> zyga-ubuntu: that is correct
<Chipaca> i mean, it is a correct description
<Chipaca> or a true statement
<Chipaca> there, it's a true statement.
<niemeyer> o/
<zyga-ubuntu> hey niemeyer
<pdefreitas> which plug do I need to avoid this kind of denial: operation="capable" comm="snap-confine" capability=2  capname="dac_read_search"
<zyga-ubuntu> pdefreitas: what did you do to get that error?
<zyga-ubuntu> pdefreitas: snap-confine should never experience that
<pdefreitas> snapping an electron app from a deb like the discord one available in snapcrafters github
<zyga-ubuntu> pdefreitas: can you be more specific, this error can only happen at runtime, what did you run next?
<pdefreitas> installed the app and when I ran it it crashed, checked the syslog and I got that
<pdefreitas> running in devmode ofc
<pedronis> on what kind of host?
<pdefreitas> latest artful
<pdefreitas> x64
<pedronis> niemeyer: hi
<niemeyer> pedronis: Heya
<pedronis> niemeyer: #4281 needs a re-review from you
<mup> PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
<niemeyer> pedronis: Two trivials and LGTM, thanks for the ping
<niemeyer> ahasenack: ping
<ahasenack> niemeyer: hi
<niemeyer> ahasenack: Heya!
<niemeyer> ahasenack: Can I abuse your knowledge for a moment? :)
<ahasenack> sure
<niemeyer> ahasenack: It's about PAM..
<niemeyer> ahasenack: Is there:
<niemeyer> 1. A standard protocol between PAM and its modules that doesn't involve linking with libpam
<niemeyer> or, alternatively
<niemeyer> 2. A standard module provided with most distributions that links with libpam and offers a more stable protocol that doesn't involve linking with libpam
<niemeyer> ?
<ahasenack> 1. I think not
<ahasenack> the "conversation" happens within the libraries/modules
 * mborzecki is away for half an hour
<niemeyer> mborzecki: /
<niemeyer> o/
<mup> PR snapcraft#1774 opened: Push binary metadata to the Store <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/1774>
<ahasenack> I haven't heard about 2
<niemeyer> ahasenack: Okay, thanks :(
<niemeyer> ahasenack: I was hoping for some luck
<ahasenack> tl;dr you want to benefit from existing pam modules but without linking with libpam?
<niemeyer> ahasenack: Yeah, the key issue is ABI stability
<niemeyer> ahasenack: Well, actually, not really
<niemeyer> ahasenack: The thing I'd like to do is enable a typical libpam-linked application to use a stable ABI to authenticate
<ahasenack> did you just encounter an abi breakage?
<ahasenack> between xenial and xenial+N perhaps?
<niemeyer> ahasenack: So *inside* the snap we need to offer something to that application that will answer auth questions
<niemeyer> ahasenack: No.. I'm anticipating that there will definitely be ABI breakages and differences across snaps
<ahasenack> ok
<niemeyer> ahasenack: I'm surprised nobody did a "Hey, here is how to do a PAM module in shell!" kind of thing
<niemeyer> ahasenack: Although that's arguably for the best ;P
<ahasenack> I quickly searched for pam over dbus (!)
<ahasenack> but what I found isn't that
<niemeyer> ahasenack: I suspect that will find a huge amount of people doing the authentication part of it
<niemeyer> ahasenack: Instead of the extension
<ahasenack> or just the very simple bits of the authentication
<niemeyer> ahasenack: Yeah, our problem is really not authenticating.. it's giving to a typical application that uses PAM something it can use
<niemeyer> I mean, we'd then have to bridge it into the real modules, but that's easier
<ahasenack> do you have some sort of pam interface in snaps? for snaps to use the host's pam?
<niemeyer> ahasenack: Exactly :)
<ahasenack> interesting
<niemeyer> ahasenack: I'm figuring if we can do that at all
<ahasenack> and I can see that breaking indeed
<niemeyer> Without major pain, of course
<ahasenack> you could tie it to pam in the core snap, but then the user db (for example) would have to live there, and that won't be practical
<sborovkov> Hi! When did CA bundle was last updated for core? For some reason my browser on the core stopped opening google maps due to ssl handshake error. And initially it worked on some older snapd (from 2 months ago)
<niemeyer> ahasenack: Not just that, but it implies every application in the world would use that same .so ABI
<niemeyer> ahasenack: Which we know is a time bomb
<ahasenack> yeah
<ahasenack> you need some sort of pam broker
<mup> Issue snapcraft#1773 closed: Please upgrade brew version <Created by fengerzh> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1773>
<niemeyer> ahasenack: Thanks for those details
<niemeyer> ahasenack: If you're interested:
<niemeyer> https://forum.snapcraft.io/t/user-authentication-in-snapd/2915/4
<Chipaca> zyga-ubuntu: do you have an armhf board on core handy?
<brunosfer> Hi guys, does anyone knows how can I override the GOGCCFLAGS for a crosscompilation of Go that imports C libs ?
<ahasenack> niemeyer: good real world case
<Chipaca> brunosfer: is it for -ldflags?
<ahasenack> of course, it had to be about printers :)
<niemeyer> ahasenack: :P
<brunosfer> chipaca: yes, but when I do it through ubuntu artful it always loads the predefined flags and I can't move on.
<Chipaca> brunosfer: is this for go inside snapcraft?
<brunosfer> yep
<Chipaca> ah
<brunosfer> but first I want to make sure I can compile it, to move further with the snapcraft tool...
<Chipaca> brunosfer: how are you trying to compile it?
<brunosfer> I have a static lib in C inside my main.go file and I'm trying to build with: go build --ldflags '-extldflags "-static"' main.go
<brunosfer> it works if I compile to my host platform amd64, but I want to compile for arm.
<brunosfer> But I can open a topic on the forum, I think it's the best option, since it doesn't seem to exist a straight answer for that.
<Chipaca> brunosfer: how are you compiling it for arm?
<zyga-ubuntu> Chipaca: yes, sure
<zyga-ubuntu> Chipaca: I can give you access in a moment
<zyga-ubuntu> Chipaca: pi2 and dragon running core
<Chipaca> zyga-ubuntu: thanks
<pdefreitas> how can I get more detailed logging of which permissions is my snap failing in devmode?
<pdefreitas> Is /var/log/syslog the only way to debug ?
<cjwatson> sergiusens,elopio: Are there any constraints on when SNAPCRAFT_BUILD_INFO=1 produces a manifest file?  I've tried a couple of noddy test snaps and I'm not getting one, so I'm wondering if I'm missing something
<Chipaca> pdefreitas: snapd core team is in a meeting right now
<sergiusens> cjwatson if this is a test, can you try using 2.35 (it is in xenial-proposed currently)
<sergiusens> cjwatson but every build should produce at a minimum a manifest with the core attributes set (stage- and build-packages, host, kernel) and a give or take depending on the plugin (from the top of my head, parts using the python plugin are fully captured)
 * sergiusens checks pending-sru
<cjwatson> Yeah, this is just me testing that my launchpad-buildd changes work.  Let's see ...
<cjwatson> sergiusens: No, I can't seem to get this to work.  Do you have a known-good-with-this test snap I could try?
<zyga-ubuntu> pdefreitas: we have a helper snap (snapd-debug) for that
<cjwatson> sergiusens: Ah, never mind, I was just looking in the wrong place!  Shows up in prime/snap/ but not in snap/, so that confused me slightly
<pdefreitas> zuga-ubuntu: but that helper just don't watch /var/log/syslog
<pdefreitas> *zyga-ubuntu
<pdefreitas> it tails me to the same issue I reported lol
<pdefreitas> just a syslog watcher
<zyga-ubuntu> mwhudson: can I use netplan to assign metric to my interfaces so that I can use pi3 over eth in preference to wifi
<brunosfer> How can I install classic snap in ubuntu snappy core on RPi3 ?
<brunosfer> I've tried sudo snap install --devmode classic but it doesn't recognize classic as a valid snap...
<mvo> brunosfer: please try "sudo snap install --devmode --beta classic
<brunosfer> mv: thank you very much, it worked perfectly.
<brunosfer> mvo: thank you very much, it worked perfectly.
<mvo> yw
<brunosfer> btw, is there any gcc snap package for snappy core?
<mup> PR snapd#4317 opened: tests: make interfaces-snapd-control-with-manage more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/4317>
<Chipaca> lunch!
<mup> PR snapd#4318 opened: snapstate: fix unkeyed fields error <Created by stolowski> <https://github.com/snapcore/snapd/pull/4318>
<pstolowski> ^ guys, a really trivial fix
<pedronis> pstolowski: I fear IÂ had to add a couple comments on the last feedback changes in #4281
<mup> PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
<pedronis> Chipaca: sha512 doesn't seem interesting, we would need something cheaper
<Chipaca> pedronis: crc32 ftw
<pstolowski> pedronis, no worries & thanks
<pedronis> pstolowski: thx
<mborzecki> pedronis: sha256? din't know if that's any cheaper, there are hardware acceleration implementations of both sha256 and sha512
<mborzecki> even in golang
<zyga-ubuntu> network failed
<zyga-ubuntu> mvo: is it still expected not to be able to go from edge to candidate?
<zyga-ubuntu> ah, linode is busy
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: I have an exciting PR to review
<cyphermox> zyga-ubuntu: mtu> you may be able to set routes: like in the very last example from the netplan manpage; there you can set a metric
<zyga-ubuntu> cyphermox: looking!
<zyga-ubuntu> cyphermox: thanks!
<cyphermox> basically, a route to 0.0.0.0 via whatever your default gateway is, and a metric lower than whatever you already have otherwise
<mborzecki> i recall a fosdem talk from one of the minio guys, they implemented sha256 in golang on armv8 and were basically beating xeon with avx2
<jdstrand> zyga-ubuntu: more exciting than 4315?
<zyga-ubuntu> jdstrand: yes, https://github.com/snapcore/snapd/compare/master...zyga:fix/discard-stale-base-snap?expand=1
<zyga-ubuntu> jdstrand: I'll open it when there are more linode things available
<jdstrand> ok
<zyga-ubuntu> jdstrand: something mvo might include in 2.30 if you deem it safe
<jdstrand> you've really been keeping me busy...
<sborovkov>  Hi, I built an image yesterday using ubuntu-image. It includes extra snaps. When I log in into that system and refresh snap from stable to candidate. On the next boot I get loaded into busy box as system is corrupt. (Rip)
<sborovkov> (Raspberry pi not rip)
<zyga-ubuntu> sborovkov: but rip is so appropriate here ;)
<zyga-ubuntu> sborovkov: are those extra snaps a factor?
<mvo> zyga-ubuntu: oh, stale mount namespace fix? that sounds sweet
<mvo> zyga-ubuntu: re edge -> candiate - almost there, I think the fix landed last night
<mvo> zyga-ubuntu: so the next core build in edge should be good again
<zyga-ubuntu> mvo: aha, do we need the fix in candidate or just in edge?
<sborovkov> zyga-ubuntu, I am not sure, I have older image that works fine. There I can update from the stable to candidate with no issues
<sborovkov> But this one just died 3 times in a row after such update. I was thinking that it is faulty sd card first
<lundmar> Hmm, the licens of my open source lxi-tools snap is listed a having a proprietary licens here: https://uappexplorer.com/snap/ubuntu/lxi-tools (?)
<lundmar> as*
<lundmar> anyone know what sets the license field?
<mup> PR snapcraft#1772 closed: Release changelog for 2.36 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1772>
<zyga-ubuntu> lundmar: maybe robert_ancell does?
<brunosfer> Hi guys, does anyone knows how can I install gcc in ubuntu snappy core for RPi3?
<zyga-ubuntu> brunosfer: hey, just install the "classic" snap
<zyga-ubuntu> brunosfer: and then you can apt-get install your toolchains
<mvo> zyga-ubuntu: just edge
<brunosfer> zyga-ubuntu: I've alredy done that, however when I type apt-get update or any apt-get option, the system shows me the error "Ubuntu Core does not use apt-get, see 'snap --help'!"
<mup> PR snapd#4319 opened: tests: add support for autopkgtests on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/4319>
<zyga-ubuntu> brunosfer: you must run "sudo classic"
<brunosfer> zyga-ubuntu: Thanks, it worked ;)
<zyga-ubuntu> cool, cheers :)
 * zyga-ubuntu -> coffee
<niemeyer> mvo, zyga-ubuntu: Did we get rid of the outdated snap-confine apparmor profiles for good?
<niemeyer> Sorry, let me fix the phrase
<niemeyer> mvo, zyga-ubuntu: Did we get rid of the issue regarding outdated snap-confine apparmor profiles for good?
<niemeyer> mvo: Just wondering as otherwise #4312 will bite us due to a new snap-confine trying to create a directory it doesn't have access to
<mup> PR #4312: snap-confine: create mount target for lib32,vulkan on demand <Created by mvo5> <https://github.com/snapcore/snapd/pull/4312>
<niemeyer> pedronis: Question on #4310
<mup> PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310>
<zyga-ubuntu> hmmmm
 * zyga-ubuntu wonders why unsquashfs chowns files to test:test
<zyga-ubuntu> drwxr-xr-x  24 test test      4096 Nov 29 05:22 squashfs-root
<zyga-ubuntu> and this runs as root
<pedronis> niemeyer: answered, I agree maybe we need a different name, a bit unsure what to use though
<zyga-ubuntu> omg
<zyga-ubuntu> acutally
<zyga-ubuntu> the core snap is owned by test.test!!!
 * zyga-ubuntu runs -shell-before
<zyga-ubuntu> (as in, files inside are test.test)
<zyga-ubuntu> cachio: ^
<zyga-ubuntu> my box is busy building a fresh image for inspection
<zyga-ubuntu> cachio: I found that, for some reason, files in the core snap were not owned by root but instead by 12345
<mup> PR snapd#4312 closed: snap-confine: create mount target for lib32,vulkan on demand <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4312>
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: drwxr-xr-x  2 test test 1937 Nov 29 05:22 bin
<mvo> zyga-ubuntu: uh, where?
<zyga-ubuntu> spread -v -shell-before qemu:ubuntu-16.04-64:tests/main
<zyga-ubuntu> mvo: my test cannot have caused that, I'm trying master now
<zyga-ubuntu> mvo: (this is most unexpected)
<zyga-ubuntu> mvo: I'll look at project-prepare
<mvo> zyga-ubuntu: could be a bug in the setup
<mvo> zyga-ubuntu: worth fixing but not omg in my book just yet :)
<mvo> zyga-ubuntu: thanks for tracking it down though
<zyga-ubuntu> mvo: looks like create_test_user does something weird
<mvo> zyga-ubuntu: still curious given that we install it from a deb that should have sane permissions
<zyga-ubuntu> mvo: I was OMG for a second, assuming it's in edge
<zyga-ubuntu>     chown test.test -R ..
<zyga-ubuntu> this is what we do
<brunosfer> zyga-ubuntu: I just installed gcc toolchain with classic on ubuntu snappy core on RPi3 however I can't find it anywhere, /usr/bin, /usr/sbin... Do you have any idea?
<mvo> zyga-ubuntu: oh, right, that would have been a OMG moment for sure :)
<zyga-ubuntu> brunosfer: in the same shell you installed them in
<zyga-ubuntu> brunosfer: you need to sudo classic
<zyga-ubuntu> brunosfer: those are not available outside
<cachio> zyga-ubuntu, can I help on this?
<pdefreitas> how can I debug plugs needed?
<zyga-ubuntu> cachio: yes, perhaps, do you remember what's the purpose of that chown?
<zyga-ubuntu> pdefreitas: can you please ask a more specific question?
<zyga-ubuntu> cachio: should that just be chown test.test -R "$SPREAD_PATH"
<niemeyer> pedronis: The problem with having a flags option is that we cannot  import configstate from snapstate due to the cycle
<niemeyer> pedronis: and "true" wouldn't improve the situation much
<niemeyer> pedronis: How about Configure and ConfigureTasks
<pedronis> that works for me
<niemeyer> pedronis: Or Task? (is it one)
<niemeyer> Ah, no Tasks, since it's a set
<pedronis> that works too
<pdefreitas> zyga-ubuntu: I'm working in porting a electron app, just for learning purposes, so I have a binary, I have no idea which system APIs it may use. When I run the devmode it gives me an access denied in snap-confine... No clue what it is trying to that that violates since it just crashes after that (sig fault)
<pedronis> it would be similar to other methods
<niemeyer> pedronis: Okay, so let's please rename the var inside snapstate too, so it's ConfigureTasks
<niemeyer> pedronis: So it doesn't feel like we're calling the wrong thing
<zyga-ubuntu> pdefreitas: not sure, can you please open a thread about this, if you include the snap or snapcraft instructions on how to build it people can try and debug
<niemeyer> pedronis: It's not 100% ideal since both of them returns tasks, but I cannot come up with anything better either.. they are doing the same thing.. it's just that one is checked and the other is not
<pedronis> yea
<niemeyer> pedronis: We might say ConfigureInstalled for the first one, but then core is an exception
<cachio> zyga-ubuntu, mmm I dont remember
<cachio> zyga-ubuntu, let me check the code
<niemeyer> pedronis: Perhaps that's better? We can live with the exception..
<pedronis> niemeyer: I was looking at other things similar,  we have:
<niemeyer> pedronis: At least the name makes more clear why we have both
<pedronis> snapstate.SetupInstallHook = SetupInstallHook
<zyga-ubuntu> cachio: I'll let you know what I find
<pedronis> so that would make SetupConfigureHook ?  seems a bit verbose though
<pedronis> also those return a single *state.Task
<niemeyer> pedronis: Hmm
<niemeyer> pedronis: We'd still have the same issue I guess
<pedronis> ?
<pedronis> IÂ mean have Configure  and SetupConfigureHook
<niemeyer> pedronis: In the sense we need a delta between the two names so we can tell why we have two names
<niemeyer> pedronis: They are both setting up the configure hook :)
<niemeyer> pedronis: I suggest going with something close to your suggestion
<niemeyer> pedronis: ConfigureInstalled and Configure
<pedronis> ConfigureInstalled is the one that checks?
<niemeyer> pedronis: The first one is a lie in the case of "core", but at least we know exactly why we have the two, and it's clear what's going on when we call one of them
<pedronis> ok
<niemeyer> pedronis: Yeah.. also makes for a smaller delta on the PR, which is a small win
<zyga-ubuntu> cachio, mvo: https://github.com/snapcore/snapd/compare/master...zyga:fix/overzealous-chown-in-spread?expand=1
<zyga-ubuntu> can you please comment before I open the PR, I don't want to waste spread time
<pedronis> niemeyer: let me take a short break, and then make that change
<niemeyer> pedronis: Thanks!
<zyga-ubuntu> mvo: I see you play with fire
<zyga-ubuntu> mvo: s390x :)
<lundmar> Hi. I assume I'm following the correct procedure when I make this request? https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976
<mvo> zyga-ubuntu: haha
<cachio> zyga-ubuntu, nice catch
<mup> PR snapd#4320 opened: tests: don't chown the whole world to test.test <Created by zyga> <https://github.com/snapcore/snapd/pull/4320>
<cachio> zyga-ubuntu, the change makes sense for me
<mup> PR snapd#4321 opened: configmgr: simplify ConfigManager <Created by mvo5> <https://github.com/snapcore/snapd/pull/4321>
<kyrofa> jdstrand, how would you feel about an interface that allows access to /dev/gpiomem? Context: https://forum.snapcraft.io/t/raspberry-pi-2-denials-using-rpi-gpio/2982/4
<zyga-ubuntu> mvo: I assume the s390x PR is for 2.30
 * sergiusens heads out to physiotherapy 
<mvo> zyga-ubuntu: its not strictly needed but would be nice
<mvo> zyga-ubuntu: there are three open ones right now, two are musts so we can still pull targets of opportunity in but if it does not make it I will not shed a tear, it will be in .31
<mup> PR snapd#4318 closed: devicestate: fix unkeyed fields error <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4318>
<zyga-ubuntu> mvo: I think we are SOM - so out of machines
<mvo> zyga-ubuntu: we are, but also quite advanced
<zyga-ubuntu> :)
<zyga-ubuntu> mvo: look at 4317 please
<brunosfer> zyga-ubuntu: I'm trying to set the CC variable in "go env" to include C libs inside a go file and I can't set it with "classic gcc"? Is there another way to set the gcc path in the go env variables?
<zyga-ubuntu> brunosfer: classic is like "ssh into this box as classic"
<zyga-ubuntu> brunosfer: just build your stuff inside classic
<zyga-ubuntu> brunosfer: once you are in the classic shell you can do whatever you want
<zyga-ubuntu> brunosfer: don't try to run classic tools from the core system to build things
<brunosfer> zyga-ubuntu: I'll look for that, thanks ;)
<zyga-ubuntu> brunosfer: also note that the filesystem is different
<zyga-ubuntu> brunosfer: after you sudo classic only /home and a few other places are the same as before
<zyga-ubuntu> brunosfer: most of /usr is different
<zyga-ubuntu> mvo: I wonder what it would take to shellcheck our spread scripts
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> mvo: I think it would be very useful
<mvo> zyga-ubuntu: +10
<mvo> or even +100
<zyga-ubuntu> mvo: I can look into that tomorrow
<zyga-ubuntu> mvo: maybe something as simple as "spread -shellcheck"
<brunosfer> zyga-ubuntu: Yeah, It's everything new for me, so I'm still getting acquainted to this paradigm shift. Thanks for the support ;)
<zyga-ubuntu> brunosfer: sure, it's a brave new world :)
<zyga-ubuntu> brunosfer: note that you can build stuff with snapcraft
<zyga-ubuntu> brunosfer: and snapcraft does a lot of magic heavy lifting
<zyga-ubuntu> (and makes snaps :)
<brunosfer> zyga-ubuntu: Yeah, that's my final goal. However I do have to understand the process first. Full hands on ;)
<niemeyer> Just got mail with the subject "Remote Work: The Complete Guide"
<niemeyer> Finally someone will explain to me how this thing works.. :P
<mvo> haha
<kyrofa> niemeyer, haha, from trello?
<niemeyer> Yeah :)
<kyrofa> Pretty sure they need "insider advice" from US
 * zyga-ubuntu doesn't believe any such guide unless it starts with "step one, get dressed"
<niemeyer> "step two, go back to step one.. we didn't mean pijamas"
<zyga-ubuntu> hmm
<zyga-ubuntu> hahaha
<pedronis> niemeyer: pushed changes to #4310
<mup> PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310>
<kyrofa> Crap... /me goes back to step 1
<niemeyer> pedronis: That was all, LGTM otherwise
<niemeyer> Oops.. meeting
<niemeyer> Still trying to figure the algorithm for hangouts to decide whether you need to click join or not.
<mup> PR snapd#4322 opened: corecfg: rename package to overlord/configstate/configcore <Created by mvo5> <https://github.com/snapcore/snapd/pull/4322>
<niemeyer> I thought it was number of people, but it just got me through to a meeting with 4 people with no questions
<mvo> reviews for https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.30 would be appreciated
<mvo> well, I think the first has two already
<mvo> and 4281 probably just need a final review from niemeyer
<niemeyer> mvo: It's got my +1 already, and I'm half way through default-provider
<pedronis> mvo: no, first two just need to get green
<pedronis> now
<m4sk1n> hi
<m4sk1n> `/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /snap/otter-browser/x1/lib/x86_64-linux-gnu/libsystemd.so.0)` when trying to run my snap
<m4sk1n> lubuntu 17.10, up-to-date
<zyga-ubuntu> m4sk1n: is that snap using classic confinement?
<m4sk1n> no
<m4sk1n> devmode
<zyga-ubuntu> m4sk1n: how did you build it?
<m4sk1n> how âhowâ?
<m4sk1n> cmake
<zyga-ubuntu> m4sk1n: did you use snapcraft?
<zyga-ubuntu> m4sk1n: snapcraft ensures that the right toolchain is used
<m4sk1n> yes
<zyga-ubuntu> m4sk1n: matching what is in the base snap at runtime
<zyga-ubuntu> m4sk1n: if this was with snapcraft then I guess that kyrofa wants to know
<zyga-ubuntu> m4sk1n: if it's not a secret, can you please open a forum thread and share your snapcraft.yaml source?
<m4sk1n> i tried to test my snap on the same pc that i used to build it
<kyrofa> m4sk1n, you need to build your snap on Xenial, or with cleanbuild
<m4sk1n> (on the same os)
<kyrofa> You're building against a libc that is too new
<kyrofa> When you run your snap, it runs against the libc in the core snap, which is based on xenial
<m4sk1n> I understand
<zyga-ubuntu> kyrofa: ah, I would have assumed snapcraft would not allow that
<kyrofa> zyga-ubuntu, how could it not?
<zyga-ubuntu> kyrofa: you could read /etc/os-release
<m4sk1n> what's the easiest way? `classic`?
<kyrofa> zyga-ubuntu, just bail on newer releases?
<zyga-ubuntu> kyrofa: and say "OMG dude, cleanbuild"
<kyrofa> Hahaha
<zyga-ubuntu> kyrofa: well, this or build useless snaps that don't work?
<kyrofa> Yeah perhaps so
<kyrofa> Indeed
<kyrofa> m4sk1n, the best way to build on xenial when you're running a newer release is to use a container. Are you familiar with LXD?
<m4sk1n> no, but it's a good moment to startâ¦
<ikey> btw when reading os-release you should do so in a cascading order
<zyga-ubuntu> ikey: ?
<ikey> [/etc/os-release, /usr/lib/os-release, /run/os-release]
<zyga-ubuntu> ikey: ah, that
<kyrofa> ikey, that's good to know actually. We don't do that today
<zyga-ubuntu> kyrofa: this is in the manual page AFAIK
<ikey> aye just future++ cruft
<zyga-ubuntu> haha
<zyga-ubuntu> I just did "man ikey"
<zyga-ubuntu> wanting to do man os-release
<zyga-ubuntu> we should do this
<ikey> lulz
<zyga-ubuntu> manual pages for people
<ikey> man: ENOMAN
<zyga-ubuntu> the package could be called
<kyrofa> m4sk1n, it's pretty easy. Are you familiar with containers in general? e.g. docker?
<zyga-ubuntu> manpages-devs (vs -dev) ;)
<ikey> hah
 * zyga-ubuntu writes ikey's manual page
<Chipaca> zyga-ubuntu: like netscape's old about:<dev> thing
<ikey> this is like a nerd dream come true
<m4sk1n> yup
<ikey> my  biography, in groff
<zyga-ubuntu> Chipaca: I never heard about that but I'm curious now :)
<zyga-ubuntu> hahaha
<zyga-ubuntu> ikey: just wait for it
<zyga-ubuntu> patches welcome
<zyga-ubuntu> crazy ideas that should be made
<ikey> 80 columns of goodness
<Chipaca> zyga-ubuntu: https://www.jwz.org/doc/about-jwz.html
<Chipaca> zyga-ubuntu: maybe instead of 'man ikey' we want 'tldr ikey'
<Chipaca> or just apropos ikey
<ikey> nah, whatis has the right idea
<ikey> whatis ikey
<ikey> ikey: nothing appropriate.
<Chipaca> finger ikey
<Chipaca> â¦ nobody runs fingerd any more
<ikey> might wanna buy a drink first
<Chipaca> :-)
<mup> PR snapcraft#1770 closed: Add codespell support <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1770>
<ikey> I once wrote a fingerd in java
<ikey> because freenode was bugging me with the ~
<Chipaca> remind me not to upset you
<ikey> lol
<zyga-ubuntu> ikey: in java?
<zyga-ubuntu> ikey: oh man
<ikey> ikr?
<zyga-ubuntu> shall I include this shameful fact in your manual page?
<zyga-ubuntu> ;D
<ikey> pre nio
<ikey> lol
<ikey> my manpage would probably be included with the insults portion of fortune
<jdstrand> kyrofa: I don't know anything about gpiomem otoh. I would need to look into it
<pedronis> mvo: btw, in principle do we still need core-support (the interface) now that we don't have a configure hook in core anymore?
<kyrofa> jdstrand, would you mind putting that on your list? sysfs is deprecated, is slow, and doesn't support everything. It's actually hard to find rpi docs that don't use /dev/mem or /dev/gpiomem
<jdstrand> kyrofa: it is already on my list
<kyrofa> jdstrand, excellent, thank you :) . I'd happily contribute the interface if you think it deserves to be there
<kyrofa> Until then, /me starts on on a soft PWM using sysfs. /me cries
<jdstrand> kyrofa: on the face of it, having gpiomem access in a 'gpiomem' interface is not contentious. the question is, what does that allow? do gpio devices show up in /dev after using it? if so, how does that interact with the device cgroup? if not, what other accesses are needed?
<jdstrand> kyrofa: or maybe we have a gpio-raw interface that is analgous to usb-raw
<pedronis> mvo: IÂ have a question about your 2.30 open PR, left it in it
<jdstrand> where everything is allowed
<jdstrand> I'm not suggesting that, cause the usb-raw interface only exists as astop gab for dynamic hotplug and isn't really the type of interface we like to have
<kyrofa> jdstrand, both approaches seem reasonable, but I suspect... yes exactly
<jdstrand> as a stop gap*
<kyrofa> I want to be able to respond favorably to automatic connection requests if possible
<kyrofa> It may not be. As you say, we don't know much about this
<jdstrand> kyrofa: since I don't know gpio well, and you have experience (and hardware) with it, perhaps you could play with gpiomem in strict mode. add /dev/gpiomem to the apparmor profile and then see what else pops out
<kyrofa> jdstrand, doing now
<jdstrand> if it is just gpiomem, then having a gpiomem or gpiomem-control implicit core interface seems quite fine
<kyrofa> jdstrand, also happy to give SSH access if you want to poke about
<jdstrand> kyrofa: that could work if you tell me the commands to use. eg, if you have a devmode snap that is representative of gpiomem use, I could put it in strict mode and run the commands that exercise the snap
<kyrofa> jdstrand, I have a strict one, indeed. Totally up to you, not sure what your schedule looks like
 * zyga-ubuntu started https://github.com/zyga/manpages-devs
<jdstrand> kyrofa: what priority is this? there is a lot of stuff that is high priority atm. I really need to get to the mir issue for greyback
<kyrofa> jdstrand, high for me, but I would not presume to suggest priorities for you! Why don't I play with it and see what I can turn up, maybe I can iron things out
<kyrofa> If you're available for a few questions along the way, I bet we can make things work
<zyga-ubuntu> kyrofa: just make the interface
<zyga-ubuntu> kyrofa: it should be easy
<jdstrand> kyrofa: that would be excellent. if your snap ends up with a device cgroup, then you can add the device to the cgroup by doing: echo 'c <major>:<minor> rwm' > /sys/fs/cgroup/devices/snap.name.command/devices.allow
<zyga-ubuntu> kyrofa: and then you can play with it
<zyga-ubuntu> kyrofa: and jdstrand can review it once it's ready
<zyga-ubuntu> kyrofa: it should be a no-brainer nowadays
<jdstrand> kyrofa: alternatively, see https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 for stuff with device cgroups
<kyrofa> zyga-ubuntu, right, that's my plan. Just want to make sure we understand what we're getting into with it
<kyrofa> zyga-ubuntu, I've made a few nowadays
<zyga-ubuntu> kyrofa: :)
<jdstrand> kyrofa: note, if echoing into sysfs, use snap run --shell snap.name.command, then in another terminal do the echo, then in the snap shell, run your commands
 * jdstrand is curious what 'udevadm info /dev/gpiomem' does
<jdstrand> kyrofa: ^
<zyga-ubuntu> jdstrand: FYI, I have a pi3 and dragonboard available over ssh if you want
<zyga-ubuntu> jdstrand: http://pastebin.ubuntu.com/26073757/
<jdstrand> zyga-ubuntu: I have a dragonboard, but it doesn't have /dev/gpiomem
<kyrofa> jdstrand, from outside of the snap? https://pastebin.ubuntu.com/26073768/
<zyga-ubuntu> jdstrand: just saying, available 24/7 :)
<jdstrand> zyga-ubuntu (cc kyrofa): ok good, it is udev taggable
<zyga-ubuntu> jdstrand: yep, that's a good call to check this :)
<jdstrand> depending on what it does, /dev/gpiomem and some sysfs entries may be sufficient. it really depends on how pin access works now
<jdstrand> do they magically pop up in /dev, are they virtual devices (eg, like tun/tap), etc
<jdstrand> I actually have an rpi2. I just don't have things plugged into pins, etc, etc
<kyrofa> jdstrand, it's just memory mapped
<kyrofa> jdstrand, take a look here: http://paste.ubuntu.com/26073822/
<mvo> pedronis: I noticed it, I ponder a bit and will reply, probably in my morning, will EOD soon
<kyrofa> This is part of the python lib I'm using
<jdstrand> kyrofa: that is my undersatnding, but lets see what blackbox testing reveals :)
<kyrofa> jdstrand, oops, too late, it's gray box now
<kyrofa> jdstrand, adding /dev/gpiomem rw, works
<mup> PR snapcraft#1775 opened: Add --help command for the runtests.sh script <Created by m4sk1n> <https://github.com/snapcore/snapcraft/pull/1775>
<zyga-ubuntu> m4sk1n: whee, thanks!
<ikey> q: when is 2.30 gonna drop?
<ikey> think ill do my call for testing on LSI when 2.30 is generally available
<jdstrand> kyrofa: ok, that's great. I then suggest sending up an interface for it. happy to review it. please remember the udev backend. you'll need to figure out what to add. I suggest looking at interfaces/builtin/physical_memory_control.go and seeing if you can just use it as a template
<zyga-ubuntu> kyrofa: you should all good with just common interface nowadays
<jdstrand> physical-memory-control uses 'common'
<popey> jdstrand: i have a command line application which needs xdg-open. Do I really have to add 'desktop' or 'unity7' plugs? Won't that complain about a missing desktop file?
<popey> Or is it either/or, just ship xdg-open and no extra plugs?
<zyga-ubuntu> popey: don't ship xdg-open :)
<popey> snappy-debug.security tells me to!
<zyga-ubuntu> jdstrand: ^
<jdstrand> note that snappy-debug is not the sharpest tool in the shed. I can add an exception for xdg-open to not recommend shipping it
<kyrofa> jdstrand, say someone requests an interface auto-connection. Would you be more likely to grant gpiomem than physical-memory-control?
<jdstrand> popey: but today, you need desktop or unity7, yes. you can add a forum topic describing your use case and why it should be allowed by default
<popey> ok, will do
<popey> thanks!
<jdstrand> np
<jdstrand> kyrofa: gpiomem is a more specific interface so if the snap is something that clearly needs access to gpio pins, then sure, that would be a candidate for auto-connection as much as a snap that needs access to a specific pin
<kyrofa> jdstrand, okay excellent. This will be the first interface I've done that has any udev component, so I'll take a closer look at that now
<jdstrand> kyrofa: hopefully using physical-memory-control as a template will make that easy (eg, KERNEL=="gpiomem")
<jdstrand> kyrofa: you can test that out for yourself on the live system without a new snapd if you look at https://forum.snapcraft.io/t/security-policy-and-sandboxing/554
<kyrofa> jdstrand, similar to physical-memory-*, think it's worth adding gpiomem-observe as well as control?
<jdstrand> kyrofa: will anyone just need read access?
<kyrofa> jdstrand, I... doubt it
<kyrofa> And I'm uncertain how that would work given the memory mapping needed
<jdstrand> kyrofa: you could name it gpiomem-control but just not add gpiomem-observe to leave the option for the future
<kyrofa> Good call
<zyga-ubuntu> travis is starving us
<zyga-ubuntu> man, it wants me to say "EOD man"
<zyga-ubuntu> I just want to see my fix work in practice
<jdstrand> kyrofa: is there anything special about python3-coverage that would cause it to not be installed if in build-packages?
<kyrofa> jdstrand, not that I know of. Any chance it's already installed?
<kyrofa> Or is this a cleanbuild?
<jdstrand> it is already installe
<jdstrand> d
<jdstrand> Building review-tools
<jdstrand> python3 -m coverage run ./run-tests
<jdstrand> /home/ubuntu/snappy-apps/review-tools.git/parts/review-tools/install/usr/bin/python3: No module named coverage
<jdstrand> kyrofa: I'm using a prepare scriptlet to run tests. I thought it would be cool to run my coverage tests
<jdstrand> kyrofa: but adding python3-coverage to build-packages doesn't seem to be pulling it down
<kyrofa> jdstrand, ah, it's probably using the snap's environment, which looks inside the part for python packages
<jdstrand> or using what is on the system...
<kyrofa> jdstrand, try staging it, does that work?
<jdstrand> kyrofa: no
<jdstrand> kyrofa: it works fine for all the other ones. eg, python3-yaml, execstack, pep8, etc
<kyrofa> Oh interesting indeed
<jdstrand> it is just python3-coverage
<kyrofa> jdstrand, I've run into similar issues before with staging python debs. Sometimes they create __init__.py files in a postinst
<kyrofa> Which means when staged, they aren't actually packages
<kyrofa> (since hooks aren't run)
<kyrofa> Do you see coverage in the installdir at all?
 * jdstrand uninstalled python3-coverage from the 'host' and still didn't work
<jdstrand> let me look at the postinst
<kyrofa> jdstrand, if I see this, I assume that means my udev tagging works properly? https://pastebin.ubuntu.com/26074073/
<jdstrand> kyrofa: indeed
<kyrofa> (KERNEL=="gpiomem" got me there, which seems to work like physical-memory-control)
<kyrofa> Okay good deal
<jdstrand> great
<kyrofa> Heck, this should take about five minutes or so
<jdstrand> kyrofa: so, python3-yaml, which works has: py3compile -p python3-yaml. python3-coverage, which doesn't, has: py3compile -p python3-coverage -V 3.2-
<jdstrand> kyrofa: does that ring any bells?
<kyrofa> jdstrand, I'm afraid not. Let me test something...
<jdstrand> kyrofa: it isn't hugely important. I'm about to bail on it and just run the tests without coverage
<jdstrand> kyrofa: I just thought it was weird, and since we were already chatting...
<kyrofa> jdstrand, haha, you can always ping me, even if we're not chatting :) . I agree that it's weird!
<jdstrand> kyrofa: btw, is my use of the prepare scriptlet to run build tests not too weird?
<jdstrand> I wanted to fail the build if the tests fail
<jdstrand> and thought that might be a good way to do it
<kyrofa> jdstrand, yeah seems reasonable to me, although note that until the most recent release, failing scriptlets did not fail the build process
 * jdstrand notes that prepare runs before the build, but in this case, that is ok-- I don't actually build anything so running before works fine
<jdstrand> I'm on 2.35. it fails the build
<kyrofa> jdstrand, yeah, `install` runs after. Note that we're also going to get more generic with pre/post instead of those names
<kyrofa> Good, 2.35 is what you need
<kyrofa> Okay so staging it seems to work properly here
<kyrofa> Let me actually try using it
<jdstrand> kyrofa: I'm using 'python3 -m coverage run <something>'
<kyrofa> Huh... it's working for me
<kyrofa> I mean, I have no tests so it's bailing, but it's saying "no file to run" instead of "blah coverage doesn't exist"
<kyrofa> jdstrand, any chance your YAML is public?
<jdstrand> kyrofa: http://paste.ubuntu.com/26074189/
<zyga-ubuntu> kyrofa: is there an acronym for 'too long to explain, give me the source'?
<jdstrand> kyrofa: not committed yet cause not working. ./run-snap-build-tests runs 'make coverage'. https://code.launchpad.net/review-tools is the full tree
<kyrofa> jdstrand, I can confirm that using coverage as a build-package doesn't work. However, using it as a stage-package does
<jdstrand> kyrofa: how did you use it as a stage-packages? add the scriptlet there?
<kyrofa> jdstrand, if you want to use build-packages, you can do `export PYTHONHOME="/usr"` in your scriptlet
<kyrofa> That will force it to use the host's python instead of the one in your snap
<kyrofa> jdstrand, I used stage-packages like this: https://pastebin.ubuntu.com/26074229/
<jdstrand> ok, so I have options
<jdstrand> kyrofa: is this a bug in snapcraft?
<kyrofa> jdstrand, well, I'm not sure. When you use the `python` plugin, you're essentially creating a venv inside the snap, which is desired. We also assume you want to use that environment when building
<kyrofa> It feels weird to then say "Yes I know I've created that environment there, but I'd actually like to not use it for a sec"
<jdstrand> kyrofa: so why isn't python3-coverage ending up in there, when everyting else is?
<jdstrand> oh
<kyrofa> jdstrand, you have it set as a build-package, which only gets installed on the host
<kyrofa> jdstrand, if you want to get it into the part with everything else, you need to use stage-packages
<jdstrand> ok, so the issue is that I'm calling 'python3' directly in the scriptlet
<jdstrand> with -m coverage
<jdstrand> kyrofa: ok, thanks
<mup> PR snapd#4310 closed: many: allow to configure core before it is installed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4310>
<mup> PR snapd#4281 closed: snapstate: support for pre-refresh hook <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4281>
<sergiusens> kyrofa look at this trick https://travis-ci.org/snapcore/snapcraft/builds/309146667?utm_source=github_status&utm_medium=notification :-)
<kyrofa> sergiusens, dude!
<mup> PR snapcraft#1776 opened: ci: name the travis jobs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1776>
<kyrofa> sergiusens, so much better
<sergiusens> I agree
<sergiusens> it will need to be that way until the issue under consideration on the issue tracker for travis is decided upon
<sergiusens> but given how the matrix stuff works, I think that this is the intended mechanism for this
<pedronis> just one 2.30 PR lef but tomorrow
<pdefreitas> gtk-update-icon-cache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found
<pdefreitas> Artful using a different glibc version?
<pdefreitas> I got snapcraft 2.35
<zyga-ubuntu> pdefreitas: yes
<zyga-ubuntu> pdefreitas: use cleanbuild
<kyrofa> zyga-ubuntu, jdstrand https://github.com/snapcore/snapd/pull/4323 FYI
<mup> PR #4323: interfaces: add gpio-memory-control interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/4323>
<mup> PR snapd#4323 opened: interfaces: add gpio-memory-control interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/4323>
<zyga-ubuntu> kyrofa: ack
<mup> PR snapd#4320 closed: tests: don't chown the whole world to test.test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4320>
<pdefreitas> zyga-ubuntu: I'm using electron.. how do I cleanbuild since npm produces the snap ?
<zyga-ubuntu> pdefreitas: I don't know what you just said, sorry,
<zyga-ubuntu> pdefreitas: cleanbuild is for snapcrat
<zyga-ubuntu> *snapcraft
<jdstrand> kyrofa: reviewed
<zyga-ubuntu> jdstrand: it passes!!!
<zyga-ubuntu> jdstrand: I updated my patch, it still shows the bug in apparmor (now easy to reproduce) but it passes now (hopefully in a sane way)
<zyga-ubuntu> jdstrand: it did pass before because I didn't notice I made a mistake
<zyga-ubuntu> jdstrand: and I never unmounted the old namespace, just bind mounted over it again (which probably did the right thing)
<zyga-ubuntu> jdstrand: having tried to unmount it I found the pattern that confuses apparmor
<zyga-ubuntu> jdstrand: it's a combination of an open file descriptor, that we keep open, across two setns calls
<zyga-ubuntu> jdstrand: and fchdir that is used to re-locate us to a directory prior to an unmount call
<zyga-ubuntu> jdstrand: (that uses relative name)
<zyga-ubuntu> jdstrand: what I did was to unmount the file with an aboslute name
<zyga-ubuntu> jdstrand: (this started to fail with EBUSY for unknown reason)
<zyga-ubuntu> jdstrand: (as nothing inhabits that namespace anymore)
<zyga-ubuntu> jdstrand: and I switched that to MNT_DETACH
<zyga-ubuntu> jdstrand: this passed my spread test
<zyga-ubuntu> jdstrand: I'm going to trim the appamor profile to remove things I added while shooting in the dark
<mup> Issue snapcraft#1777 opened: Proxy support? <Created by array42> <https://github.com/snapcore/snapcraft/issue/1777>
<jdstrand> zyga-ubuntu: nice! jjohansen, fyi ^
<jdstrand> zyga-ubuntu: can you update the bug with that info?
<zyga-ubuntu> jdstrand: yes, I will!
<zyga-ubuntu> jdstrand: I had an euphoria and panic attack today
<jdstrand> zyga-ubuntu: sounds like quite a day :)
<jjohansen> uh, setns is a known problem, double setns doesn't change that
<zyga-ubuntu> jdstrand: when I realized that it worked (on my laptop) and then that it fails the spread test (which was more careful) and then that it finally worked with those extra hacks in place
<zyga-ubuntu> jjohansen: this doesn't explain why setns is not causing massive failures, we setns for every single started snap
<zyga-ubuntu> jjohansen: (well, except the first of a given snap)
<zyga-ubuntu> jjohansen: hey :) long time no see btw
<zyga-ubuntu> jjohansen: would you have some time to look at the code in the patch and at the denial (also documented in the patch) and see what you make of this?
<sergiusens> kyrofa mind reviewing snapcraft#1774 before you EOD today?
<mup> PR snapcraft#1774: Push binary metadata to the Store <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/1774>
<jjohansen> hey zyga-ubuntu, setns won't necessarily break everything dependent on several things. Partly to due with how mounts are shared or whether they are cloned ..
<kyrofa> sergiusens, sure thing
<jjohansen> zyga-ubuntu: yes I will look into it
<mup> Issue snapcraft#1777 closed: Proxy support? <Created by array42> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1777>
<zyga-ubuntu> jjohansen: I see
<zyga-ubuntu> jjohansen: thank you, I'll open the PR in 10 minutes
<mup> PR snapd#4324 opened: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/4324>
<zyga-ubu1tu> jjohansen, jdstrand ^
<jdstrand> jjohansen: so, what is supposed to be happening here (zyga-ubu1tu can correct me) is that we do the setns for the persistent mount namespace. that thing sticks around until it becomes 'stale'. if no processes are using the mount namespace, snap-confine will remove the persistent mount namespace so that it can be started anew the next time
<jdstrand> jjohansen: eg, foo.bar starts and a persistent mount namespace is setup and foo.bar is put into it
<jdstrand> jjohansen: foo.baz comes along, sees that foo's persistent mount namespace is available and doesn't have to be setup, then setns into it
<jdstrand> jjohansen: things might be added to the mount namespace through snap connections, but if they are removed, the namespace is considered stale.
<jdstrand> jjohansen: running processes continue to use the stale namespace until no processes are using it, at which point, the next foo.whatever invocation tears it down and reconstructs it
<jdstrand> zyga-ubu1tu: please correct me ^
<jdstrand> jjohansen: snaps themselves are not allowed to use setns or mount to escape
<jjohansen> jdstrand: that wouldn't be a double setns, setns in, and then setns out
<zyga-ubu1tu> jdstrand: one thing I would correct is that we only consider it stale when the base snap revision (the rootfs) changes and we want to follow by starting with a fresh namespace
<jjohansen> and that should not be a problem, unless the ns being reaped is lazily unmounted, at which everything within that namespace becomes disconnected, as it no longer has a namespace
<zyga-ubu1tu> jjohansen: the double setns is when we consider using a namespace, we jump inside (1st setns), see that it is stale and then jump out (2nd setns by folling /proc/1/ns/mnt) in order to be able to do the unmount (the bind mounted namespace is only visible on the main namespace)
<jdstrand> jjohansen: I don't know what the 'double setns' talk is about. I think zyga-ubu1tu was saying he made a coding mistake that he since corrected
<zyga-ubu1tu> jdstrand: I did use MNT_DETACH, as described in the patch
<zyga-ubu1tu> er, jjohansen ^
<jjohansen> zyga-ubu1tu: that is basically known as a chroot escape, and it is very bad form
<zyga-ubu1tu> jjohansen: though I don't quite know why that is needed, I got EBUSY otherwise
<jdstrand> oh yes, the setns to pid 1's namespace
<jdstrand> that is only for snap-confine though, not snaps
<zyga-ubu1tu> jjohansen: when we lazily unmount there should be no more processes there
<jjohansen> jdstrand: your point being?
<zyga-ubu1tu> jjohansen: measured using a freezer cgroup that all processes from this snap inhait
<zyga-ubu1tu> *inhabit
<jjohansen> zyga-ubu1tu: I am going to have to dig into your specific case more
<jjohansen> before I can say exactly what is going on to cause the failure
<zyga-ubu1tu> jjohansen: sure, thank you for looking
<jdstrand> zyga-ubu1tu: this only reason for doing the /proc/1 stuff is for the devmode/checkbox snap, correct?
<zyga-ubu1tu> jdstrand: the only other reason
<zyga-ubu1tu> jdstrand: here it's a "legitimate" way to jump out
<zyga-ubu1tu> jdstrand: as a variant where we don't jump out I could use the capture helper (process forked earlier still in the original namespace) and re-distribute the flow of the code so that it does the work
<kyrofa> Hey cprov, can I not generate an attenuated macaroon for a specific project if I'm only a collaborator on that project?
<zyga-ubu1tu> jdstrand: in general I think we can refactor snap-confine, re-write it if necessary if we get directions on what to do and what not to do to stay in the bounds of the limitations of the kernel
<zyga-ubu1tu> attenuated macaroon, boy, and I find my job confusing sometimes ^_^
<zyga-ubu1tu> kyrofa: what is an attenuated macaroon, a very small cookie?
<cprov> kyrofa: let me check the code, but it's possible that is restricted to the publisher.
<zyga-ubuntu> ok, I'm EOD, it far too late already
<zyga-ubuntu> niemeyer: ^^
<jdstrand> zyga-ubuntu: you say "this" is a legitmate reason to jump out... can you explain the flow for this legitimate use case?
<zyga-ubuntu> jdstrand: yes
<zyga-ubuntu> jdstrand: we start in whatever the namespace is (let's say the main one), look at /var/lib/snapd/ns/$SNAP_NAME.mnt and setns inside (successfully) in an attempt to reuse it
<cprov> kyrofa: can you file a bug on the snapstore project with the traceback of the request you are doing ?
<zyga-ubuntu> jdstrand: once inside we measure / and see that it's not the one we expect and we consider if we can clean it up
<zyga-ubuntu> jdstrand: we measure /sys/fs/cgroup/freezer/snap.$SNAP_NAME/cgroup.procs and look for inhabitants,
<zyga-ubuntu> jdstrand: finding none we consider it safe to unmount and start over
<zyga-ubuntu> jdstrand: we setns on /proc/1/ns/mnt to have a perspective in which we can unmount /var/lib/snapd/ns/$SNAP_NAME.mnt (remember that ... oh drat, I meant /run/snapd/ns above and here) has private mount sharing
<jdstrand> zyga-ubuntu: another way to do it would not setns in it at all. just look for inhabitants. if none, reconstruct
<zyga-ubuntu> jdstrand: then we umount with MNT_DETACH and re-start the procedure (where we see the that .mnt file is no longer a namespace bind mount so we construct a fresh one and bind over it)
<zyga-ubuntu> jdstrand: yes but the current detection logic depends on looking at / from the inside (I think this is not a problem and we could adjust) and also this would make the cache effectively useless
<zyga-ubuntu> jdstrand: as a cache that is
<zyga-ubuntu> jdstrand: it would still function for as long as we have a living process inside
<zyga-ubuntu> jdstrand: it could probably cause some issues for snaps that keep data in /tmp and (currently, unaware of this) depend on it to stick around
<zyga-ubuntu> jdstrand: I would rather setns and exit and then continue from a forked child that hasn't setns at all yet
<jdstrand> zyga-ubuntu: the /tmp case is still there regardless. consider a snap disconnect
<zyga-ubuntu> jdstrand: (and since we already fork for the bind mount that captures the namespace, due to how the kernel requires this to be done, we could do this without additional "cost")
<zyga-ubuntu> jdstrand: yes? what about it?
<zyga-ubuntu> jdstrand: (we don't lose /tmp then)
<jdstrand> zyga-ubuntu: you said that 'it could probably cause some issues...'. I'm saying that is still the case
<zyga-ubuntu> jdstrand: yes but today this is less frequent (both in master and with this patch)
<zyga-ubuntu> jdstrand: but otherwise I agree
<zyga-ubuntu> jdstrand: I just didn't understand why "snap disconnect" matters
<kyrofa> cprov, will do... but I may have broken this
<zyga-ubuntu> jdstrand: we should never discard a namespace on disconnect
<jdstrand> zyga-ubuntu: I was just mentioning a case where the mount namespace might have to be updated
<jdstrand> eg, you disconnect a content interface. sure, you don't discard *then*, but you will whenever no processes are there
<zyga-ubuntu> jdstrand: right, but we don't change /tmp in that case, I really did mean /tmp specifically where software just keeps various files
<zyga-ubuntu> jdstrand: agreed on all that
<jdstrand> anyway
<jdstrand> zyga-ubuntu: so, it feels really weird to setns in and then out and then in again
<zyga-ubuntu> jdstrand: well, in, out, and then unshare technically
<zyga-ubuntu> jdstrand: we never setns three times
<jdstrand> sure
<zyga-ubuntu> jdstrand: if I adjust the logic for staleness detection I think it's equally possible to not setns again, but I'd have to see how much code needs refactoring to allow that
<zyga-ubuntu> (some of the code is a victim of evolutionary approach there)
<jdstrand> zyga-ubuntu: I think with the myriad of PRs over weeks/months it was hard for me to understand where we were heading. I'm sorry for that (not blaming you or anything. I just feel bad about not seeing this early)
<jdstrand> on the one hand, we are talking about 'only' snap-confine needing this access to jump out
<jdstrand> *but* snap-confine is setuid root and an attack vector, so we are trying to minimize what it can do
<jdstrand> zyga-ubuntu: there are certainly other ways to do this, but fork/exec'ing a helper in the namespace to detect staleness and communicating to the parent (snap-confine) how to proceed would avoid the issue
<jdstrand> zyga-ubuntu: so, snap-confine starts in the original ns, it launches a helper that detects staleness, it gets back the results and snap-confine decides what to do
<jdstrand> zyga-ubuntu: this way, snap confine doesn
<jdstrand> 't have any extra permissions. the helper could have a small subset of the current profile and snap-confine could have some rules removed that are only in the staleness detector
<jdstrand> zyga-ubuntu: this should avoid the kernel issue you are seeing. that kernel issue is, I think, indicative of the fact that one shouldn't really be jumping around with setns()
<zyga-ubuntu> jdstrand: yeah, I think there are ways to do this
<jdstrand> which is why it isn't surprising that it isn't working as expected
<zyga-ubuntu> jdstrand: though here I'll repeat what I said earlier in the conversation: knowing the limitations would help to desing this better
<zyga-ubuntu> jdstrand: if there's a rule to setns at most once, that's a valuable fact
<zyga-ubuntu> jdstrand: note that setns(2) doesn't really documenta any constraints
<zyga-ubuntu> *document
<zyga-ubuntu> jdstrand: though I know this is all tricky business and there dragons around :)
<jdstrand> zyga-ubuntu: I don't think my helper idea would require a ton of refactoring or anything. maybe you can think of something else, but the fork/exec with the parent and child in different namespaces is clean design-wise
<zyga-ubuntu> jdstrand: agreed
<zyga-ubuntu> jdstrand: but I think we still don't (at least not me) have a very clear idea of what is off limits and what is allowed
<zyga-ubuntu> jdstrand: why is 2nd setns special?
<jdstrand> zyga-ubuntu: well, we are pushing the boundaries here. I think the only one setns() is implied rather than explicit
<zyga-ubuntu> jdstrand: I think we need to wait for a deeper analysis
<zyga-ubuntu> jdstrand: well, it works if you unconfine :)
<jdstrand> zyga-ubuntu: so, namespaces are, in part, meant to address shortcomings in things like chroot
 * zyga-ubuntu should get to bed, day starts soon 
<jdstrand> zyga-ubuntu: so if you can setns in and out of a namespace all the time, that isn't great, so people, I think, are really thinking about a single setns that you shouldn't leave
<zyga-ubuntu> jdstrand: I will shift my timezone to match yours next year
<zyga-ubuntu> jdstrand: and I will probably (likely) be off most of december to burn my holidays
<zyga-ubuntu> jdstrand: at one point in time I was hoping we can keep a thread in each namespace permanently but then, unfortunately, I learned that sents must be called when there's only one thread
<jdstrand> jjohansen: sorry it is late for you. note that jjohansen can be considered a kernel expert in this area. the fork/exec idea is confirmed as fine
<jdstrand> meh
<jdstrand> jjohansen: nm
<jdstrand> zyga-ubuntu: ^
<zyga-ubuntu> jdstrand: it would be really cool to design snapd in a way that keeps a pool of threads in each namespace
<zyga-ubuntu> :-)
<zyga-ubuntu> jdstrand: I will look at reworking it tomorrow if you desire
<jdstrand> zyga-ubuntu: I do. it is a significant deparature in design-- you still detect and decide, it is just a tweak on how to organize that
<jdstrand> err
<jdstrand> zyga-ubuntu: it isn't*
<jdstrand> zyga-ubuntu: and that tweak makes a big difference in what snap-confine is allowed to do, and keeps a cleaner separation of the namespaces, which is more inline with kernel expectations
<zyga-ubuntu> ack
<jdstrand> zyga-ubuntu: so, there is still the sc_reassociate_with_pid1_mount_ns() that is called unconditionally in snap-confine.c when !classic confinement
<pedronis> it's a bit annoying that there's no way to measure the namespace from outside even being root
<jdstrand> zyga-ubuntu: don't worry about that for now. I want to think through that (I never cared for this-- can checkbox not just be classic)?
<jdstrand> I guess it is really all devmode snaps. but now that we have classic and devmode is a step to strict, I don't see the problem with disallowing calling other snaps from devmode. but that conversation has been had. anyway, let me think about it
<mup> PR snapcraft#1775 closed: Add --help command for the runtests.sh script <Created by m4sk1n> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1775>
<sergiusens> kyrofa any idea why from one stage to the next the built snap wouldn't be available? -> https://travis-ci.org/snapcore/snapcraft/builds/309146667?utm_source=github_status&utm_medium=notification
<mwhudson> er is there a reason snap run uses snap-exec from the host system not the core snap?
<mwhudson> sounds like a fourm question
<kyrofa> Hmm.... I'm not sure how that works sergiusens
<kyrofa> sergiusens, I mean, that dir is cached
<kyrofa> I don't think there's magic beyond that
<sergiusens> kyrofa maybe the next stage ran somewhere else? I am going to just click on rebuild for everything and if not wait for the transfer.sh work to finish ;-)
<kyrofa> sergiusens, unless lxc file pull can fail without exiting non-zero... super weird
<kyrofa> sergiusens, but yeah, I've seen the stages run out of order before, elopio had to close/re-open to get it to run again
<kyrofa> Correctly, I mean
<sergiusens> I saw these ran in order, but with a lot of time in between each stage
<mup> PR snapd#4325 opened: Adding test for netlink-connector interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4325>
#snappy 2017-11-30
<mborzecki> morning
<zyga-ubuntu> hi
<zyga-ubuntu> mborzecki: man, I need more sleep
<mborzecki> zyga-ubuntu: hey
<mborzecki> seen the snow outside?
<zyga-ubuntu> yes
<zyga-ubuntu> my kids are happy
<zyga-ubuntu> my wife is not, the car is all covered with snow
<mborzecki> haha, same here :)
<mborzecki> i see Chipaca fixed #4291
<zyga-ubuntu> man
<mup> PR #4291: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <https://github.com/snapcore/snapd/pull/4291>
<zyga-ubuntu> our logs are too long
<mborzecki> i'm slightly confused, there's 'syscall' package and 'golang.org/x/sys/unix', looks like 'syscall' is covered by go's stable api promise but x/sys/unix is not, so any fixing if 'syscall' actually happens in x/sys/unix
<mborzecki> s/if 'syscall'/of 'syscall'/
<zyga-ubuntu> mborzecki: and x/sys/unix is not ported to all arches
<zyga-ubuntu> mborzecki: anyway, I'm happy with https://github.com/snapcore/snapd/pull/4324
<mup> PR #4324: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/4324>
<zyga-ubuntu> needs small rework but it is worth it
<mborzecki> let me have a quick look
<zyga-ubuntu> mborzecki: if you have backlog from yesterday midnight it's sensible to look
<zyga-ubuntu> well, 22:04 -> 23
<zyga-ubuntu> small coffee
<ogra_> zyga-ubuntu, thats called espresso
<zyga-ubuntu> ogra_: no, I wasn't honest
<zyga-ubuntu> after my wife made me de-snow the car in flip flops
<zyga-ubuntu> I want a 1L jug of tea
<zyga-ubuntu> and a bit coffee with lots of warm water
<zyga-ubuntu> maaan
<zyga-ubuntu> it's winter :D
<zyga-ubuntu> mborzecki: how would you feel about migrating away from indent onto clang-format?
<ogra_> dont tell me ... i have a broken ankle and have to fly home in flip/flops on sat.
<ogra_> not yet sure how i'll manage to get from frankfurt to kassel without proper shoes then
<mborzecki> zyga-ubuntu: sounds good to me, have you checked if 14.04 (or do we need it there for the unit tests?)
<mborzecki> clearly I have not had a morning coffee yet
<zyga-ubuntu> mborzecki: I'll check everything in detail, I only saw it failed on core (where it reboots so there's no need for this)
<zyga-ubuntu> looking at 14.04 log again
<zyga-ubuntu> though
<mborzecki> zyga-ubuntu: uncrustify if a simpler alternative though
<zyga-ubuntu> I'll have to rewrite this a bit after yesterday's discussion
<zyga-ubuntu> but first
<zyga-ubuntu> shower and tea
<mvo> ogra_: uh, did you break it during the sprint? sorry to hear that, get well!
<ogra_> mvo, yeah, directly on monday evening ... only a micro fracture but really annoying when you cant walk around the city a lot in the evenings
<mvo> ogra_: :(
<mvo> ogra_: indeed. get well!
<zyga-ubuntu> ogra_: you need more structural integrity ;_)
<ogra_> OTOH i had an exciting day at the taipei hospital
<zyga-ubuntu> (sorry, bad humor in the morning perhaps)
<ogra_> quite an experience ...
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4324
<mup> PR #4324: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/4324>
<mvo> ogra_: heh, at least you got a good story out of it
<ogra_> zyga-ubuntu, tsk ... thats exactly the same my GF said !
<mvo> zyga-ubuntu: yeah, I saw it
<zyga-ubuntu> mvo: will need a small change (more forking to avoid kernel bugs)
<ogra_> mvo, yeah, and i could see some of the city by daylight even ... which i normally dont during a sprint :)
<mvo> haha, so truuuueeee
<zyga-ubuntu> ogra_: so "break a leg" will now mean "enjoy the sprint outside of the office"? :D
<ogra_> yeah !
<mvo> mborzecki: you triggered a build 2h ago? man, you are up early :)
<mup> PR snapd#4319 closed: tests: add support for autopkgtests on s390x <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4319>
<mup> PR snapd#4326 opened: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>
<zyga-ubuntu> re
<ogra_> mvo, if i want to add a new config option to core now, where do i do it ? still in the core snap source or somewhere hidden in snapd ?
<mvo> ogra_: its now in snapd, one sec
<mvo> ogra_: https://github.com/snapcore/snapd/tree/master/corecfg
<ogra_> configstate/configcore/ ?
<ogra_> ah
<mvo> ogra_: yeah, that is the final one
<mvo> ogra_: but the PR is iirc not quite merged
<mvo> ogra_: I was about to point you to the PR :) what option do you need?
<ogra_> mvo, https://forum.snapcraft.io/t/disabling-the-assertion-auto-import-job-on-core-should-be-possible/2923
<ogra_> (for a customer, not super urgent but soon it will be, so i wanted to check how it works now)
<ogra_> hmm
<ogra_> the question is if the service managing works on things in multi-user-target too ...
 * zyga-ubuntu runs tests and hopes for the best
 * ogra_ wonders if systemd is clever enough
<ogra_> mvo, hmm, i see Disable in  https://github.com/snapcore/snapd/blob/master/systemd/systemd.go but i dont see mask used anywhere, didnt we switch to mask because of writable transitions ?
<ogra_> (to force linking to /dev/null)
<zyga-ubuntu> mvo: offtopic, did you consider changing the display on your x250?
<mvo> ogra_: oh, that is possible that this got lost during the transition, that is a must-fix, let me double check
<ogra_> grepping for "ask" doesnt reveal anything in https://github.com/snapcore/snapd/blob/master/systemd/systemd.go or https://github.com/snapcore/snapd/blob/master/corecfg/services.go
<ogra_> so i think it got lost
<mvo> zyga-ubuntu: I have not considered that just yet, is it worth it?
<zyga-ubuntu> mvo: I'm lookin at it and I think it is
<zyga-ubuntu> mvo: I have a slightly broken panel
<zyga-ubuntu> mvo: and considering swapping it for a new one
<zyga-ubuntu> mvo: the HD TN panel is half the price
<mvo> ogra_: do you remember the original PR?
<zyga-ubuntu> but it really looks like crap when compared side-by-side
<mvo> zyga-ubuntu: heh, yeah, I think I would go for the best available one
<ogra_> mvo,   https://github.com/snapcore/core/pull/61
<mup> PR core#61: Also "mask" services when disabling them <Created by mvo5> <Merged by ogra1> <https://github.com/snapcore/core/pull/61>
<mvo> zyga-ubuntu: given that its a lot of your time that you need to invest into fixing it
<mvo> ogra_: nice, thank you!
<zyga-ubuntu> mvo: well, it's open already :D
<mvo> zyga-ubuntu: heh
<zyga-ubuntu> mvo: I sent you three photos
<zyga-ubuntu> the 2nd laptop is a music box while I wait for parts :)
<zyga-ubuntu> the viewing angles on that TN panel are horrid
<mborzecki> tn?
<zyga-ubuntu> mborzecki: x240 with TN panel vs x250 with IPS
<mborzecki> iirc x250 had full hd ips panels too
<mvo> zyga-ubuntu: heh
<zyga-ubuntu> the current TN panel is broken a little and I'm just considering which to replace
<mvo> ogra_: thanks for the link, I will add code to corecfg today to fix this. good catch!
<ogra_> mvo, hmm, but mask for snapd.autoimport.service just creates a /dev/null symlink in /etc/systemd/system ... /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service still exists and points to the old target
<ogra_> so that might be a bit trickier than just calling mask/stop/etc ...
<zyga-ubuntu> (fingers crossed guys:)
<ogra_> :/
<mborzecki> zyga-ubuntu: http://allegro.pl/matryca-lenovo-x240-x250-1920x1080-fhd-ips-04x3922-i7010276242.html ?
<zyga-ubuntu> mborzecki: right, I was looking at ebay but the prices there are similar
<zyga-ubuntu> mborzecki: I was a bit tempted to see if there is a FHD + touch model
<zyga-ubuntu> mborzecki: but I didn't check if the motherboard for non-touch model accepts that
<zyga-ubuntu> mborzecki: since this laptop is for my mother, she could probably use touch as extra-intuitive input method
<zyga-ubuntu> mborzecki: though she will mainy use it for writing books
<ogra_> hmm, but it seems systemctl is clever enough here ...
<ogra_> ogra@pi3:~$ sudo systemctl list-unit-files|grep autoimport
<ogra_> snapd.autoimport.service                   enabled
<ogra_> ogra@pi3:~$ sudo systemctl mask snapd.autoimport.service
<ogra_> Created symlink from /etc/systemd/system/snapd.autoimport.service to /dev/null.
<ogra_> ogra@pi3:~$ sudo systemctl list-unit-files|grep autoimport
<ogra_> snapd.autoimport.service                   masked
<ogra_> .... even though /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service still exists and points to the old target
<mup> PR snapd#4327 opened: release: merge 2.30~rc1 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4327>
<mvo> pstolowski: hey, good morning. do we have a forum topic for the post-refresh hook? I'm updating the roadmap right now
<mup> PR snapd#4328 opened: wrappers: fix unit tests to use dirs.SnapMountDir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4328>
<mborzecki> trivial review ^^
<pstolowski> mvo, hey! there was something, but I'm not sure if it's useful to anyone. i need to search it
<pstolowski> mvo, ok, that was https://forum.snapcraft.io/t/install-remove-hooks/478 but it's not really covering post- and pre- which we ended up with
<pstolowski> mvo, I'll respond in this thread with up-to-date info
<mborzecki> mvo: thanks for the review
<zyga-ubuntu> mborzecki: doing
<zyga-ubuntu> done
<mborzecki> zyga-ubuntu: thanks
<mvo> pstolowski: ta
<zyga-ubuntu> small simplification and another run
<zyga-ubuntu> maybe last one :)
<KristijanZic> Hi, I'm having trouble downloading Ubuntu Core 16 for RPi3 (edge) image. I get the Apache 403 sever error. Can somebody configure that real quick?
<KristijanZic> here is the link: http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz
<zyga-ubuntu> KristijanZic: works for me
<zyga-ubuntu> KristijanZic: maybe you have a transparent proxy?
<KristijanZic> zyga-ubuntu: thanks, it was my adblock
<mborzecki> anyone wants to take a stab at reviewing #4313?
<mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<zyga-ubuntu> mborzecki: I'll look but I want to finish this invalidation first
<zyga-ubuntu> oohh
<zyga-ubuntu> darn
<zyga-ubuntu> 1 vs 0 typo
<zyga-ubuntu> now it works
<zyga-ubuntu> ffss..
<mborzecki> :)
<mborzecki> damn my back hurts
<mborzecki> came back to playing badminton again after one month pause, wasn't able to walk up and down the stairs yesterday
<zyga-ubuntu> mborzecki: man, did you exert yourself too much?
<zyga-ubuntu> mborzecki: or did you have some accident during the game?
<zyga-ubuntu> (tests rolling now)
<mborzecki> guess it just was a bit too much, rally after rally ;) badminton is really fast, lost of movement back and forth at full speed down to full stop
<mup> PR snapd#4329 opened:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<zyga-ubuntu> so
<zyga-ubuntu> mvo: what shall we do with indent
<zyga-ubuntu> mvo: the version in artful produces different "canonical" representation than the version of indent in xenial
<mvo> zyga-ubuntu: meh, that is sad
<zyga-ubuntu> mvo: I'm inclined to kill it
<zyga-ubuntu> mvo: and go to clang-format which is a bit better
<zyga-ubuntu> mvo: (flag day to run make fmt)
<mvo> zyga-ubuntu: can we change gradually? what I hate is that we lose the history
<zyga-ubuntu> mvo: not that I see
<zyga-ubuntu> mvo: we can disable the check
<mvo> zyga-ubuntu: well, not loose totally but it makes things harder
<mvo> zyga-ubuntu: lets do that then
<zyga-ubuntu> mvo: kk
<mup> PR snapd#4330 opened: cmd: disable check-syntax-c <Created by zyga> <https://github.com/snapcore/snapd/pull/4330>
<zyga-ubuntu> mvo: ^^
<pedronis> that is :(
<zyga-ubuntu> pedronis: ?
<zyga-ubuntu> pedronis: are you talking about 4330
<zyga-ubuntu> mvo: I'm a bit sleepy and tired, I have to stop working till midnight
<zyga-ubuntu> mvo: when stale base v2 patch is green I'll break and get a long walk in the sno
<zyga-ubuntu> mvo: I'll be back to discuss this with jdstrand and jjohansen as actually, the workaround we discussed last night is still showing the kernel bug
<zyga-ubuntu> mvo: so whatever we end up doing, I think we need more jjohansen's eyes on this
<mvo> zyga-ubuntu: ok, thanks for the headsup
 * zyga-ubuntu sees green ^_^
<zyga-ubuntu> let's run 14.04
<pedronis> zyga-ubuntu: yes, when do we run it?Â in our unit tests?Â when we build the deb?
<zyga-ubuntu> pedronis: it's a part of "make check"
<zyga-ubuntu> pedronis: so it affects unit tests, package builds and everything
<zyga-ubuntu> pedronis: I kept the target, just detached it from make check
<pedronis> even manually we need to decide where to run it? no?
<pedronis> otherwise it will be a whack-a-mole
<zyga-ubuntu> pedronis: I think unless we figure out how to make indent behave, it's useless
<zyga-ubuntu> pedronis: we can run "make fmt"
<zyga-ubuntu> pedronis: (as an informal requirement for C code changes)
<zyga-ubuntu> pedronis: the output will look mostly consistent but there will be small changes between xenial and artful
<zyga-ubuntu> I think we are mostly all on artful (or equivalently recent indent)
<pedronis> yes, but if one runs make fmt with one versio and the next person with another
<zyga-ubuntu> pedronis: yes, so as long as this is reasonably consistent inside the team (few people touch this code) then I think it's not a problem
<pedronis> that sounds optimistic to me
<pedronis> maybe we should code a version in fmt and just warn, do nothing if it is not that one
<zyga-ubuntu> pedronis: I'll look into this
<zyga-ubuntu> pedronis: maybe there's a new knob in indent
<zyga-ubuntu> pedronis: and we don't control it so it fluctuates
<zyga-ubuntu> but this assumes that we can still make a profile that won't die on xenial
<zyga-ubuntu> man, I should have used clang-format years ago
<zyga-ubuntu> 14.04 is good too
<zyga-ubuntu> this looks like a winner
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4329 if someone wants to go down there and examine dragons
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<mup> PR snapd#4291 closed: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4291>
<pedronis> mvo: can you create the 2_31 tag in the forum
<mup> PR snapd#4331 opened: systemd: add support for the mask/unmask operations <Created by mvo5> <https://github.com/snapcore/snapd/pull/4331>
<mvo> pedronis: let me try, I think I can
<mvo> pedronis: anything specific I should tag?
<pedronis> there are at least things to move
<mvo> pedronis: +1
<pedronis> because they didn't make it for 2.30
<mvo> pedronis: updated
<pedronis> thank you
<pedronis> now when 2.30 goes to stable
<pedronis> we can cleanup upcoming stuff
<mup> PR snapd#4332 opened: corecfg: also "mask" services when disabling them  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4332>
<mup> PR snapd#4328 closed: wrappers: fix unit tests to use dirs.SnapMountDir <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4328>
<zyga-ubuntu> man
<zyga-ubuntu> I will never go out
<zyga-ubuntu> slooow tests
<mborzecki> got this: error: cannot list snaps: cannot list local snaps! cannot find publisher details: snap-declaration (99T7MUlRhtI3U0QFgl5mXXESAiSwt776; series:16) not found
<mborzecki> any idea where this is coming from?
<zyga-ubuntu> hmmm, looks like missing assertion
<zyga-ubuntu> no idea
<zyga-ubuntu> (why)
<mborzecki> that's `snap list`
<mborzecki> funny, if I do `snap install core` then it complains that core is installed, but there no core in /var/lib/snapd/snap
<zyga-ubuntu> what did you do to get there?
<pedronis> that is a weird state
<mup> PR snapd#4333 opened: packaging/arch: add bash-completion as optional dependency <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4333>
<mborzecki> hmm must have borked something when playing locally with the package
<Chipaca> niemeyer: â2017-11-30 10:45:02 Error debugging qemu:ubuntu-14.04-32:tests/main/snap-confine-privs : EOFâ <- probably not the network
<Chipaca> niemeyer: the thing that stands out is that the first line of output of the failing test output is 'stdin: is not a tty'
<zyga-ubuntu> eh
<zyga-ubuntu> ok
<zyga-ubuntu> that's it
 * zyga-ubuntu -> walk
 * sergiusens waves
<mborzecki> sergiusens: hey
<mvo> niemeyer: if 4322 captures your suggestion from some days ago, please merge, I have work on topic of it but I wanted to double check with you first that the name is what you had in mind
<mup> PR snapcraft#1778 opened: Add sentences to error when registering name <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1778>
<zyga-ubuntu> re
<sergiusens> mpt hey there, it's me again and I have a small request, can you look at https://github.com/snapcore/snapcraft/pull/1778/files ? It is an error message improvement and the author created it from a Google code-in task
<mup> PR snapcraft#1778: Add sentences to error when registering name <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1778>
<zyga-ubuntu> man, I need polish-weather-proof shoes
<Chipaca> zyga-ubuntu: https://i.imgur.com/R2Iwz6G.jpg
<zyga-ubuntu> Chipaca: you laugh but I was using that for 80% of the year back in spain
<Chipaca> zyga-ubuntu: oh, i'm laughing alright
<zyga-ubuntu> Chipaca: my "winter shoes" were just that + small outer layer
<zyga-ubuntu> I want back!
<cachio> niemeyer, I'll be 5 minutes late today
<mpt> looking
<zyga-ubuntu> eh
<zyga-ubuntu> I wish it was xmas
<mup> PR snapd#4327 closed: release: merge 2.30~rc1 back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4327>
<zyga-ubuntu> tests would be happier
<zyga-ubuntu> everybody is happier on xmas
<zyga-ubuntu> and there's more green
<niemeyer> cachio: Ack, and hellos
<niemeyer> I am late myself today as well
<niemeyer> zyga-ubuntu: Well, just pretend it is! It's not too different from the 25th.. it's just more people pretending..
<niemeyer> Chipaca: Is it the same test?
<niemeyer> mvo: Will look, thanks
<Chipaca> niemeyer: http://pastebin.ubuntu.com/26080210/
<zyga-ubuntu> niemeyer: hey
<zyga-ubuntu> niemeyer: I was wishing for more green tests :)
<zyga-ubuntu> at some point we'll talk about eco-tests
<mup> PR snapd#4322 closed: corecfg: rename package to overlord/configstate/configcore <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4322>
<niemeyer> mvo: It's in.. good branch name too :)
<niemeyer> zyga-ubuntu: Some good discussions here from last night.. a bit too long to jump in without context, but curious to hear your thoughts on it during or after the standup
<Chipaca> i might be missing the standup today: the cops said they'd come by at 12 but they haven't yet, and if it's any later than it'll overlap
<Chipaca> s/than/then/
<niemeyer> Chipaca: Cops?  Are you okay?
<zyga-ubuntu> niemeyer: gladly
<Chipaca> niemeyer: bullying at the boys school escalated
<Chipaca> there's now apparently a video on youtube
<niemeyer> Chipaca: Oh my.. what are we doing with our society
<mborzecki> omg, kids
<mborzecki> but then adults are not that much better
<niemeyer> No, more like OMG people overvaluing kids actions
<niemeyer> Well, or maybe not
<niemeyer> It really depends on what's going on, and I'm inferring from recent experiences.. so I'll just shut up.
<mborzecki> niemeyer: can i ask you for a review of #4313?
<mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<niemeyer> Chipaca: The stdin is indeed not a tty..
<niemeyer> Chipaca: Nor the stdout
<niemeyer> Chipaca: Unless the shell is used, obviously
<Chipaca> niemeyer: but wherefore the message?
<niemeyer> (TIL a new word)
<Chipaca> niemeyer: it's an old word :-)
<niemeyer> Chipaca: Because it's indeed not.. it's a pipe in this case
<niemeyer> Chipaca: Something was trying to do something and failed
<niemeyer> Chipaca: This wouldn't justify a disconnection, even more considering that the output did continue
<niemeyer> Chipaca: Did you manage to reproduce it predictably?
<niemeyer> Chipaca: If the other end is managing to disconnect reliably, it has to do with either networking or ssh
<Chipaca> niemeyer: i'll answer that in a few minutes when it runs again
<niemeyer> Chipaca: Note that networking is indeed involved in qemu, despite being local
<niemeyer> (still ssh)
<Chipaca> niemeyer: yeah but it's not some network op along the route toggling a box
<niemeyer> Chipaca: Killing sshd would also have a similar effect
<Chipaca> niemeyer: (i'm only involving you because they're weird enough they might be indicative of something more obscure; i'll continue continuing)
<niemeyer> Chipaca: Yeah, it will be something more interesting, like a bug in Spread's client or something inside the VM poking the system state
<niemeyer> Chipaca: Thanks, glad to continue investigating
<niemeyer> mborzecki: Yeah, let me just finish a review and will pick that one next
<zyga-ubuntu> dran you travis
<zyga-ubuntu> travis is penalizing us for having many long tests
<niemeyer> Chipaca: Did you update your Spread from the tarball recently?
<niemeyer> As in, late last week
<Chipaca> niemeyer: aug 24
<niemeyer> zyga-ubuntu: Huh?
<niemeyer> Chipaca: Okay, not a bug in the zlib thing then
<zyga-ubuntu> niemeyer: I went for a walk after one of my tests timed out
<zyga-ubuntu> niemeyer: it's still "waiting to start"
<zyga-ubuntu> niemeyer: that was ~2 hours ago
<niemeyer> zyga-ubuntu: That's not Travis penalizing us.. that's usually Travis constraining how much they are willing to give us (for free!) at once
<zyga-ubuntu> yes, that's true
<niemeyer> zyga-ubuntu: Right *now* we have 8 branches waiting to be tested
<niemeyer> zyga-ubuntu: If you push something to test *now*, it will take about 8*30min/3
<jdstrand> zyga-ubuntu: hey, it may be because of the unconditional sc_reassociate_with_pid1_mount_ns() in main.c
<niemeyer> zyga-ubuntu: Which is about 1h30mins
<jdstrand> zyga-ubuntu: so I think we were doing a triple setns(). -> 1, -> inside to verify -> 1 as needed
<jdstrand> zyga-ubuntu: curious if you comment that out in your current refactored branch if you see the issue
<jdstrand> (as a temporary test)
<zyga-ubuntu> jdstrand: but that doesn't do anything
<zyga-ubuntu> jdstrand: that just stats and does nothing more
<zyga-ubuntu> jdstrand: we _dont_ setns there
<zyga-ubuntu> jdstrand: (hey)
<jdstrand> maybe I misread something. hold on
<zyga-ubuntu> jdstrand: comment out what exactly?
<zyga-ubuntu> jdstrand: the code in sc_reassociate_with_pid1_mount_ns doesn't ns unless it has to, and in this case it doesn't
<zyga-ubuntu> jdstrand: I can comment that out and see if the confusion goes away
<zyga-ubuntu> jdstrand: note that I also use absolute paths, not fchdir + relative paths
<zyga-ubuntu> jdstrand: IMO apparmor is confused by something we do, but it's not just setns
<jdstrand> zyga-ubuntu: I'm reading sc_reassociate_with_pid1_mount_ns() in ns-support.c. I see only one return. where is it deciding not to setns to pid 1?
<jdstrand> zyga-ubuntu: I was suggesting just commenting out the line in main.c: // sc_reassociate_with_pid1_mount_ns();
<jdstrand> oh the memcmp. let me read more carefully
 * jdstrand is not completely awake yet
<zyga-ubuntu> :)
<zyga-ubuntu> jdstrand: no worries
<zyga-ubuntu> jdstrand: I'm happy to experiemnt to see what is breaking it
<zyga-ubuntu> jdstrand: I also devised a way to not setns and measure
<zyga-ubuntu> jdstrand: it's a bit more contrived but will work
<jdstrand> zyga-ubuntu: commenting that out is certainly a fast test
<zyga-ubuntu> jdstrand: test in progress
<jdstrand> zyga-ubuntu: nice. I thought of a rather crude way to not setns from devmode too. fork/exec snap-confine from snap-confine. still want to think through that
<zyga-ubuntu> jdstrand: look at freezer cgroup, look at each pid, look at its mountinfo
<zyga-ubuntu> jdstrand: as long as any process is there, we can see the mountinfo
<jdstrand> zyga-ubuntu: oh, that's good
<zyga-ubuntu> jdstrand: so this gives us two values: we know if it's empty
<jdstrand> yep
<zyga-ubuntu> (but we don't know if it's stale then, that's a downside)
<zyga-ubuntu> jdstrand: and we know if it's active and then which root is used
<pstolowski> hey guys, i'm gonna be 5 minutes late to standup
<zyga-ubuntu> jdstrand: I haven't founda way not to setns to measure if it is really empty
<zyga-ubuntu> jdstrand: so I didn't implement that as it reduces to current problem in worst-case
<m4sk1n> created bug #1735410 for l10n support, should I start doing it?
<mup> Bug #1735410: Localization support <l10n> <Snapcraft:New for m4sk1n> <https://launchpad.net/bugs/1735410>
<zyga-ubuntu> woot, thank you m4sk1n
<m4sk1n> (for snapcraft)
<jdstrand> zyga-ubuntu: well, the fork/exec into the freezer/setns into the mount namespace would do it
<zyga-ubuntu> jdstrand: fork + exec as opposed to just fork?
<zyga-ubuntu> jdstrand: I really want to get to the bottom of this bug in the kernel
<jdstrand> it doesn't have to be a full on helper though.
<zyga-ubuntu> jdstrand: as I feel like we're walking on a minefield with our eyes closed
<zyga-ubuntu> jdstrand: we could fexec /bin/cat
<zyga-ubuntu> jdstrand: to cat mountinfo
<jdstrand> zyga-ubuntu: the fork may be enough, but would need jjohansen to confirm
<zyga-ubuntu> jdstrand: hold on, we fork now
<zyga-ubuntu> jdstrand: it's not enough
<m4sk1n> ok, so I'll start today
<zyga-ubuntu> m4sk1n: yes, I think so
<zyga-ubuntu> m4sk1n: kalikiana is a snapcrafter so he can help you out
<zyga-ubuntu> m4sk1n: I will gladly review the translation as I'm familiar with the language and the topic
<zyga-ubuntu> jdstrand: confirmed, that has no impact
<mup> PR snapd#4333 closed: packaging/arch: add bash-completion as optional dependency <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4333>
<zyga-ubuntu> jdstrand: I commented out both the extra apparmor rule and the optional reassociation
 * jdstrand nods
<jdstrand> zyga-ubuntu: well, this is good info for jjohansen
 * mvo hugs Son_Goku 
<Son_Goku> what brought this on?
<sergiusens> zyga-ubuntu niemeyer we moved over to using travis stages, overall the whole suite can take longer, but it is mitigated as the fast tests are what usually fail not needing to wait for all the jobs to end (jobs from the next stage won't pass if the previous one isn't completely green)
<sergiusens> this has saved us plenty of wait
<niemeyer> sergiusens: We need to wait for tests to end either way, because we're limited on the number of worker machines too
<zyga-ubuntu> jdstrand: I have a suspicion about what _may_ be going on, I'll write a small C program and apparmor profile to help jjohansen
<zyga-ubuntu> jdstrand: I'll keep you posted
<zyga-ubuntu> jdstrand: in the end we need some idea if the workaround I implemented in both PRs is acceptable
<zyga-ubuntu> jdstrand: and if we can roll with it
<jdstrand> zyga-ubuntu: note that the double setns is not desirable regardless
<jdstrand> zyga-ubuntu: but maybe there is something else that can be done to your current attempt after jjohansen looks at it
<zyga-ubuntu> jdstrand: we don't do double setns now
<jdstrand> zyga-ubuntu: I know
<zyga-ubuntu> ah,o k
<jdstrand> zyga-ubuntu: I wasn't sure if you were saying that you wanted to go back to what you had yesterday
<jdstrand> zyga-ubuntu: and I was simply saying what you did today was good on its own, even if there is still something else going on
<sergiusens> zyga-ubuntu did you make any progress on that non ubuntu kernel snap-confine die issue which makes me disable apparmor completely?
<mpt> sergiusens, done
<zyga-ubuntu> jdstrand: no, no I mean I just need some advice on what to do next
<zyga-ubuntu> jdstrand: I see, thank you for clarifying that
<zyga-ubuntu> sergiusens: no, sorry, still entangled in bugs
<jdstrand> zyga-ubuntu: jjohansen would be able to provide that, there is just a question of timing. I'll let him comment-- he may need to talk to tyhicks/ratliff if it requires deep investigation
<zyga-ubuntu> jdstrand: I reproduced this
<zyga-ubuntu> jdstrand: reducing it to a small C program
<zyga-ubuntu> jdstrand: woot :)
<zyga-ubuntu> niemeyer: ^ I was right abount my hunch I said during the call :)
<jdstrand> zyga-ubuntu: a small reproducer will be super helpful
<zyga-ubuntu> jdstrand: yep, just writing a README file now
<jdstrand> mvo: hey, curious if the 'include -> #include' fix will be in 2.29.4?
<cachio> jdstrand, hey
<cachio> jdstrand,  I am working in a PR to test the netlink connector interface
<cachio> jdstrand, #4325
<mup> PR #4325: Adding test for netlink-connector interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4325>
<cachio> I am getting an error "Bad system call" when I try to use the interface and the plug is disconnected
<cachio> jdstrand, not sure if it is expected or not?
<matiasb> kyrofa, o/ hey, thanks for the comments in the PR (https://github.com/snapcore/snapcraft/pull/1774), pushed some updates for when you get some minutes; let me know if you have any other comments
<mup> PR snapcraft#1774: Push binary metadata to the Store <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/1774>
<zyga-ubuntu> jdstrand: I think it will be in 2.30
<zyga-ubuntu> jdstrand: I don't recall any backports done to that PR
<ikey> when is 2.30ish?
<zyga-ubuntu> ikey: next week
<ikey> oo nice
<ikey> thats when ill do my call for testing then
<mvo> jdstrand: the include fix is not in 2.29.4, do you need it? it is in 2.30 and we could pull it in to the 2.29 branch *if* we need to do another 2.29 (which I hope we don't need to :)
<jdstrand> mvo: I thought someone mentioned it as a regression in bionic, which means the sru would be halted, no?
<jdstrand> maybe it wasn't bionic specific. let me reread the bug
<jdstrand> mvo: actually, it affects 17.10: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1733700
<mup> Bug #1733700: aa-enforce fails due to syntax error in snapd.snap-confine profile <snapd (Ubuntu):Triaged by zyga> <https://launchpad.net/bugs/1733700>
<jdstrand> I thought there was another bug...
<mvo> jdstrand: uhh, ok
<jdstrand> ok, yes 1734038
 * jdstrand reads
<mvo> jdstrand: this is very annoying, I will pull it into branches/2.29 and we need to discuss what to do
<jdstrand> yes, 1734038 mentions artful as well
<mvo> zyga-ubuntu: silly question but why is it     #include "/var/lib/snapd/apparmor/snap-confine" in master vs ".../snap-confin.d" in 2.29?
<mvo> jdstrand: or maybe you know the answer -^
<jdstrand> mvo: I think we need a spread test to do 'apparmor_parser -QTK /path/to/snap-confine/profile'
<jdstrand> mvo: that will make sure that the policy is good everywhere
<jdstrand> mvo: the fact that cache files masked the issue is unfortunate
<jdstrand> mvo: let me look
<mvo> jdstrand: ok, let me write a test for this
<jdstrand> mvo: note that as of recent PRs, the interfaces-many spread test I added achieves the same result for snaps
<jdstrand> so it will be nice to ohave that for snap-confine itself
<om26er> sergiusens: Hi! re: snapcraft 2.35 on xenial, its been 7 days today, so I guess we can move that from xenial-proposed to -updates ?
<zyga-ubuntu> mvo: niemeyer asked us to drop the .d
<mvo> zyga-ubuntu: aha, ok. can/should this happen in 2.29 as well? we are a bit inconsistent right now between 2.29 and 2.30+
<jdstrand> zyga-ubuntu: does the move away from .d cleanup the .d directory? if so, are reverts handled ok?
<sergiusens> om26er you can help with the SRU process by adding a comment on the SRU bug, elopio did a call for testing a while back
<sergiusens> he's on holidays so it is taking longer than usual
<zyga-ubuntu> mvo: not sure
<zyga-ubuntu> jdstrand: not sure either
<zyga-ubuntu> man
<zyga-ubuntu> jdstrand: I can trigger the bug with a small C program
<zyga-ubuntu> jdstrand: but only if snap-confine first produces a namespace
<zyga-ubuntu> jdstrand: if I use a simple tool that produces a namespace I don't get that bug
<zyga-ubuntu> jdstrand: I wonder which of the things we are doing is causing it
<mup> PR snapd#4334 opened: tests: ensure snap-confine apparmor profile is parsable <Created by mvo5> <https://github.com/snapcore/snapd/pull/4334>
<zyga-ubuntu> jdstrand: my mini-tool now does unshare + pivot_root
<om26er> sergiusens: ok, I added my comments there as well. I hope that gets promoted to -updates soon.
<jdstrand> mvo: oh right, so the apparmor -QTK test is absolutely valid, but wouldn't have caught this (I forgot, the parser is fine, it is the apparmor python tools that are not, which is why users see this and qrt kernel failures). let me give you an additional test for -QTK
<jdstrand> to -QTK
<jdstrand> meh, let me give you the userspacec tools test too
<jdstrand> mvo: before I right that, this is tricky
<jdstrand> mvo: cause say you fix this. the previously broken revision is still on the system
<jdstrand> mvo: and the userspace tools will still fail
<zyga-ubuntu> jdstrand: what's the problem?
<zyga-ubuntu> jdstrand: is it the #include vs include?
<jdstrand> zyga-ubuntu: yes
<jdstrand> so, apparmor_parser is fine
<zyga-ubuntu> jdstrand: can we fix the userspace tools
<jdstrand> so snaps work
<zyga-ubuntu> jdstrand: this is IMO a bug in the tools
<jdstrand> but apparmor python tools don't understand 'include' and the tools read all profiles that are in /etc/apparmor.d
<zyga-ubuntu> jdstrand: sure, can we fix those tools to understand the same language that the other tools do?
<jdstrand> so if someone has a broken revision and gets the new unbroken revision, then the userspace tools will still be broken until the broken revision rotates out
<jdstrand> I think we have to
<zyga-ubuntu> jdstrand: yes, I think this is the correct way to deal with this
<jdstrand> mvo: I think the spread test is valuable. I don't think the 2.29 respin is required
<jdstrand> tyhicks: we need to update the userspace tools everywhere for 1734038 and 1733700
<jdstrand> man, that sucks
<jdstrand> mvo: in addition to 'apparmor_parser -QTK /path/to/profile', please also do 'apt-get install apparmor-utils && aa-enforce $ sudo aa-enforce /path/to/profile'
 * zyga-ubuntu hugs jdstrand 
<zyga-ubuntu> it's not too bad, just one gazillion packages
<oSoMoN> would it be valid to refer to/copy files from partA in partB's install scriptlet using a relative path (e.g. ../../partA/install/some/file.ext), provided IÂ declare that partB is built after partA, or is that discouraged?
<jdstrand> mvo: when it doesn't fail, it simply will compile the profile and load it into the kernel
<jdstrand> mvo: but aa-enforce will (weirdly) pull in all the profiles, just like logprof and genprof
<oSoMoN> sergiusens, you probably know? ^
<sergiusens> oSoMoN not until I read what this is all about :-)
<oSoMoN> sergiusens, just that one question 3 lines above
<sergiusens> oSoMoN discouraged, parts are private, think of it like using private headers, you can, but if it breaks you get to keep the pieces
<zyga-ubuntu> jdstrand: ok, I have a reproducer in C, separate form snapd
<zyga-ubuntu> *from
<oSoMoN> sergiusens, right, that's what I feared
<sergiusens> oSoMoN it would be more convenient to stage the files from partA and consume them in partB from $SNAPCRAFT_STAGE
<oSoMoN> sergiusens, ah, IÂ didn't know of $SNAPCRAFT_STAGE, that sounds like what I need
<sergiusens> oSoMoN or if you have a plugin `self.project.stagedir` iirc
<sergiusens> one sec, an example to arrive
<oSoMoN> great
<oSoMoN> but I need to run a scriptlet on those files, isn't it too late for that at the stage phase?
<sergiusens> oSoMoN https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/integration/snaps/stage_env/snapcraft.yaml
<mvo> jdstrand: ok, will do.
<sergiusens> oSoMoN if a part depends on another, the dependant part goes all the way to staging as that is the only place a dependency can be consumed (in the for of a library, runnable or whatever other artifact)
<mvo> jdstrand: silly question, could you do something like s/include/#include/ in your python tools as a quick fix?
<oSoMoN> sergiusens, great, so that should do the trick
<oSoMoN> thanks!
<jdstrand> mvo: that is what I was saying-- we have to sru apparmor everywhere to do that (or backport the actual patch)
<mvo> jdstrand: ok, thank you
<mvo> jdstrand: PR updated to include aa-enforce
<zyga-ubuntu> jdstrand: where can I share the program?
<zyga-ubuntu> jdstrand: actually, I'll just add that to the bug report
<niemeyer> mvo: The point about .d was that all of these are .d-irectories.. :)
<niemeyer> mvo: There's nothing special about that one
<niemeyer> mvo: I did originally ask back then, quite a while ago actually, whether this was already released.. the answer was no
<zyga-ubuntu> jjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/1735459
<mup> Bug #1735459: Incorrect denial on umount with bind-mounted mount namespace <AppArmor:New> <https://launchpad.net/bugs/1735459>
<zyga-ubuntu> niemeyer: ^ that bug with small C reproducer
<zyga-ubuntu> niemeyer: I said it wasn't AFAIK, I must have made a mistake there
<pedronis> mvo: btw I checked, snap install lxd  lxd   really creates twice the tasks, and then they confuse each other
<pedronis> running at the same time
<niemeyer> zyga-ubuntu: I do remember grepping the code and finding no uses either, so at the very least I made the same mistake
<jdstrand> zyga-ubuntu: we could work around that denial if needed, but I defer to jjohansen
<zyga-ubuntu> niemeyer: I looked at git tags
<niemeyer> pedronis: This demonstrates the issue, but it's an obvious case that we don't in fact want to reach that code.. this should drop duplicates very early on.. in the API itself
<zyga-ubuntu> jdstrand: the example contains a workaround as well
<zyga-ubuntu> jdstrand: but I'd like jjohansen to analyze and figure it out
<zyga-ubuntu> jjohansen: I'm happy to help
<zyga-ubuntu> jjohansen: (with the kernel side)
<popey> Anyone tried snapd on fedora 27 recently? It just hangs, and I get messages in the journal about selinux blocking access to /proc/<pid>/stat
<zyga-ubuntu> popey: no :/
<popey> I have never knowingly disabled selinux on fedora before.
<niemeyer> jdstrand, jjohansen: We just need something that works soon, and we need an ack that we can trust it not to break in the foreseeable future.. if you guys have a different suggestion, we can go with anything else too.. we just need to get this working and out of the way.
<popey> I just booted it and updated the machine and now snaps don't work
<zyga-ubuntu> Son_Goku: ^ is that something we can fix for 2.30?
<niemeyer> popey, zyga-ubuntu: Yes, we did try recently, as in last week.. we've just built images for it
<niemeyer> cachio will have more details
<zyga-ubuntu> niemeyer: ah, indeed!
<popey> I don't understand. I had snaps working here previously
<popey> suddenly since an update, i cant install snaps
<pedronis> niemeyer: yes, it's really a different kind of issue/bug, anyway it's there atm
<cachio> popey, last week I executed the snapd test suite on fedora 27 and just 1 test failed
<cachio> popey, we are using the image fedora-27-64 on linode, that will be ready next week
<zyga-ubuntu> cachio: is selinux enabled on our image?
<zyga-ubuntu> (worth having a spread test for it)
<cachio> zyga-ubuntu, I need to check that
<popey> Do I need to file a bug somewhere? Because right now Fedora 27 users can't install snaps (AFAICT)
<jdstrand> niemeyer (cc jjohansen and zyga): that is what we all want and are working towards
<niemeyer> jdstrand: I'm talking pragmatically about the specific code that zyga-ubuntu posted today
<niemeyer> jdstrand: One of them works, the suggested approach doesn't
<cachio> popey, yes please
<niemeyer> jdstrand: We cannot use a suggested approach that doesn't work, of course.. so either we need a +1 on the approach that does work, or we need a third approach that you and jj can vouch for and does work too
<cachio> popey, I'll be researching that
<jdstrand> mvo: is bug #1734038 marked as a blocker for sru? in thinking about it, it probably should be because if 2.29 goes to stable releases, the offending rule will be on disk for everyone, regardless of if they use snap install and get a new core, meaning all stable release users who use apparmor-utils will break whether they use snaps or not
<mup> Bug #1734038: utils don't understand Â«include "/where/ever"Â» (was: Potential regression found with apparmor test on Xenial/Zesty) <apport-bug> <package-from-proposed> <regression-proposed> <s390x> <xenial> <zesty> <AppArmor:New> <apparmor (Ubuntu):New> <linux (Ubuntu):Confirmed> <snapd
<mup> (Ubuntu):Invalid> <https://launchpad.net/bugs/1734038>
<popey> cachio: where should I file it? forum / launchpad / github?
<cachio> popey, in the forum please
<niemeyer> jdstrand: This has been coming for some time and I understand we all want to reach the same goal.. but we need to get it through and move on
<jdstrand> niemeyer: I understand. what zyga posted today may be fine and just a bug that can be worked around in policy as opposed to what was there yesterday that went against the grain of how namespaces are intended to function
<jdstrand> niemeyer: we need jjohansen to comment. I just wanted you to know that it is understood that this is a priority and no one wants to block
<mvo> jdstrand: 1734038 is not a blocker yet, I can update 2.29 and do a new SRU if needed, we probably also need to update the core snap though as this will also write include (and not #include)
<niemeyer> jdstrand: Thanks a lot, and please don't take my words as "we need to move on anyway".. the point is just that we do need to move on, so we need to investigate and get to an understanding and agreement that a given approach solves the problem and is reliable in terms of the implementation not changing behind us tomorrow
<jdstrand> niemeyer: understood (cc jjohansen ^)
<niemeyer> jdstrand: zyga-ubuntu produced a smaller test case which hopefully will make things easier for you and jj to discuss and find a workable agreement in those terms
<jdstrand> tyhicks, ratliff: do note the above ^ (since I can't just assign jjohansen to something :)
<jdstrand> niemeyer: yes
<ratliff> zyga-ubuntu: did you send your test case to jjohansen with a brief description? I don't think that it is optimal for him to try to read through this backscroll
<zyga-ubuntu> ratliff: better: https://bugs.launchpad.net/apparmor/+bug/1735459
<mup> Bug #1735459: Incorrect denial on umount with bind-mounted mount namespace <AppArmor:New> <https://launchpad.net/bugs/1735459>
<ratliff> zyga-ubuntu: excellent, thanks!
<jdstrand> jjohansen (cc niemeyer, ratliff, tyhicks): re bug #1735459, the question is whether that approach is sane or not. if so, we can add a workaround rule and treat it like a regular bug. if not, we should recommend an approach to zyga
<mup> Bug #1735459: Incorrect denial on umount with bind-mounted mount namespace <AppArmor:New> <https://launchpad.net/bugs/1735459>
<mup> PR snapd#4335 opened: snap-confine: use #include in snap-confine.apparmor.in <Created by mvo5> <https://github.com/snapcore/snapd/pull/4335>
<mvo> jdstrand: -^
<jdstrand> mvo: approved. where is the pr for the -QTK/aa-enforce spread test?
<zyga-ubuntu> mvo: hmm
<zyga-ubuntu> mvo: we merged https://github.com/snapcore/snapd/pull/4335/files before!?!
<mup> PR #4335: snap-confine: use #include in snap-confine.apparmor.in <Created by mvo5> <https://github.com/snapcore/snapd/pull/4335>
<zyga-ubuntu> mvo: what am I missing?
<zyga-ubuntu> mvo: I pushed this yesterday or two days ago
<jdstrand> zyga-ubuntu: release/2.29
<zyga-ubuntu> ahh
<zyga-ubuntu> sorry
<zyga-ubuntu> all good
 * zyga-ubuntu had panic moment
<mup> PR snapd#4335 closed: snap-confine: use #include in snap-confine.apparmor.in <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4335>
<mup> PR snapd#4330 closed: cmd: disable check-syntax-c <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4330>
<cachio> zyga-ubuntu, after double check status on fedora 27
<cachio> zyga-ubuntu, selinux is enabled
<cachio> and we are using kernel 4.13.15-300.fc27.x86_64
<cachio> popey, please read this
<popey> ok
<zyga-ubuntu> cachio: perhaps popey's machine uses different kernel
<zyga-ubuntu> cachio: or perhaps the workstation image contains some different defaults
<popey> its a vm
<zyga-ubuntu> cachio: would be good to check a full workstation VM
<popey> just a plain vanilla fedora 27 vm
<cachio> zyga-ubuntu, I think this is the real diff
<popey> nothing special.
<zyga-ubuntu> popey: correction *workstation* vm
<zyga-ubuntu> popey: fedora has workstation, server and atomic editions AFAIK
<popey> yeah, it's workstation
<zyga-ubuntu> popey: our CI is done on cloud images
<zyga-ubuntu> popey: I don't fully understand how they differ
<popey> One of them doesn't work, that's a key difference ;)
<mup> PR snapd#4336 opened: Adding fedora 27 and rawhide to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
 * zyga-ubuntu goes to test vlc and that amd gpu for popey 
<zyga> popey: oy, doing that test now, man, I haven't booted this in a while
<zyga> I' got a gazillion updates
<zyga> popey: that bunny movie is hard to download, from the blender website at least
<popey> I hear there are free movies on the internet
<zyga> yes, but all over 18
<zyga> I'm trying blender mirrors
<zyga> popey: well
<zyga> popey: it works
<zyga> popey: not sure if this is hw accelerated
<zyga> popey: any hints on how to check
<popey> it should tell you on the console
<popey> probably mentioning VDPAU or VAAPI
<zyga> [00007f782801a800] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding
<zyga> so yep
<popey> and that it's trying to load a vdpau or va-api module
<popey> oooooh
<zyga> butter smooth
<zyga> :-)
<popey> that's freaking awesome
<zyga> yep
<zyga> I'll comment on the forum
<zyga> thank you!
<zyga> and VLC looks great
<popey> awesome
<zyga> popey: done
<popey> thanks.
<zyga> my pleasure
<zyga> it was surprisingly flawless :)
<popey> i should hope so after the effort that went into making that snap! :D
<zyga> popey: do you need a Nvidia test?
<Chipaca> zyga: so... i'm getting very weird errors from the spread suite, and i thought maybe you knew something (seeing as you'd spent some time hating it this week)
<popey> no, got that covered thanks
<zyga> popey: I don't have anything recent, I have one old laptop with nvidia gpu
<zyga> Chipaca: yes?
<popey> me and wimpy both have nvidia by default, so easy to cover that
<zyga> popey: great, thank you for doing this
<Chipaca> zyga: there's a test that fails every time, but never if i run it on its own
<zyga> Chipaca: want to help me figure it out?
<Chipaca> zyga: and when it fails i get no debug info, and i can't -debug it by hand, because it's just EOF
<zyga> oh
<zyga> hmm
<zyga> well
<zyga> I'd start with this:
<zyga> Chipaca: install this copy of spread https://github.com/snapcore/spread/pull/47
<mup> PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>
<zyga> Chipaca: add measure-each: to spread.yaml, I do something like this:
<zyga> Chipaca: something-to-measure > /tmp/now.log
<zyga> Chipaca: if [ ! -e /tmp/vanilla.log ]; cp /tmp/now.log /tmp/vanilla.log; fi
<zyga> Chipaca: diff -u /tmp/vanilla.log /tmp/now.log
<zyga> Chipaca: start small, something that few tests break
<zyga> Chipaca: and iterate with -seed set
<zyga> Chipaca: I made some things that help:
<Chipaca> zyga: uh... but
<Chipaca> zyga: i don't see anything broken :-/
<zyga> Chipaca: run this on linode to save network if you want to avoid that
<zyga> Chipaca: sure
<Chipaca> it just dies
<zyga> Chipaca: my point is that _something_ messes up
<zyga> Chipaca: and over time, as we measure more things
<zyga> Chipaca: one more idea
<zyga> Chipaca: patch spread to don't do headless qemu
<zyga> Chipaca: when it breaks, log in from the window and see what you get
<zyga> Chipaca: I didn't do this but it's useful
<zyga> Chipaca: maybe something rm -rf's /
<zyga> Chipaca: another idea, run each possible combination of (n, test_that_eofs) where n is each test in the suite
<zyga> Chipaca: unless the bug is a combination of more than one cleanup going wrong
 * zyga reboots to get new kernel
<niemeyer> pedronis: Hey, which specific test case where you referring to the whole time in our call?
<niemeyer> Sorry, not the case, condition
<niemeyer> Sorry, not test case, condition
<niemeyer> pedronis: I'm now wondering whether we were talking across each other the whole time.. that would explain why it took us a while
<zyga> Chipaca: I hope my messages were not grim
<zyga> popey: I got one denial
<zyga> [  262.410700] audit: type=1400 audit(1512064138.223:71): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/xdg/QtProject/qtlogging.ini" pid=3902 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga> looks harmless
<popey> not seen that before, thanks
<zyga> I wish we had a way to deny things per-snap
<zyga> "silence those denials"
<niemeyer> mvo: I'm pretty sure this was the case..
<zyga> popey: another one [  328.556164] audit: type=1400 audit(1512064204.370:72): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/vdpau_wrapper.cfg" pid=3902 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga> popey: ohh, subtitles are broken
<popey> yeah, i get that one, it's fine
<popey> ooh
<zyga> popey: I ran a anime movie and it shows garbage
<popey> broken how?
<popey> fonts probably?
<zyga> "the wind raises"
<zyga> probably
<zyga> or
<zyga> encoding/locale
<zyga> more likely
<zyga> the movie is in japanese with english subs
<zyga> and I'm not sure if we ship an UTF-8 capable locale by default
<niemeyer> mvo: Which would be super ironic, and somewhat telling about how easy it is to discuss the wrong thing :)
<popey> ugh
<zyga> I can attach a photo
<popey> k
<popey> is it an mkv?
<popey> i have some which have subtitles so can probably test here
<zyga> yes
<zyga> hey, even the appindicator works :D
<Chipaca> huh, that's interesting
<Chipaca> Nov 30 17:57:11 autopkgtest rngd[3413]: read error
<zyga> out of randomness?
<Chipaca> somehow
<Chipaca> probably qemu doesn't have /dev/hwrng
<zyga> Chipaca: hmm
<zyga>            -object rng-random,id=id,filename=/dev/random
<zyga>                Creates a random number generator backend which obtains entropy from a device on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The
<zyga>                filename parameter specifies which file to obtain entropy from and if omitted defaults to /dev/random.
<zyga> Chipaca: I can search for random strings in qemu man page
<zyga> (pun intended :)
<zyga> oh, I didn't mention: I'm off tomorrow, burning holidays
<zyga> jjohansen: do you need anything from me, I'll be back for part of next week
<Chipaca> running htop inside the qemu doing the spread tests is interesting
<Chipaca> also: boring
<Chipaca> also: EOD time here, but i'll be around async
<jdstrand> zyga, popey: we should allow /etc/vdpau_wrapper.cfg I think. what happens if you add it?
<zyga> jdstrand: checking
 * jdstrand adds it to todo for the next policy updates for 2.30
<zyga> jdstrand: it still works
<jdstrand> zyga: cool. I'll get that into 2.30
<zyga> jdstrand: thank you :)
<zyga> jdstrand: in case this is interesting:
<zyga> $ cat /etc/vdpau_wrapper.cfg
<zyga> enable_flash_uv_swap=1
<zyga> disable_flash_pq_bg_color=1
<jdstrand> thanks
<zyga> popey: where is the sublime text snap?
<zyga> popey: AFAIK we had some
<popey> news to me
<zyga> aha
<zyga> I saw some chatter on the forum
<popey> it was desired
<cachio> mvo, starting sru, do you have the lp link?
<mvo> cachio: bad news, we need a respin
<mvo> cachio: I just uploaded 2.29.4.2 to beta
<zyga> mvo: uh
<mvo> cachio: if you could validate so that we can push to candidate tomorrow(ish) that would be great
<mvo> cachio: and then I push new SRUs
<mvo> zyga: yeah, include ftw :(
<mvo> zyga: but it breaks people so we need to fix it
<zyga> mvo: but didnt jdstrand say this is a bug that needs to be fixed in apparmor
<cachio> mvo, sure
<cachio> mvo, which is the issue fixed?
<jdstrand> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1734038/comments/15
<mup> Bug #1734038: snap-confine profile uses 'include' instead of '#include' which breaks apparmor-utils python tools <apport-bug> <package-from-proposed> <regression-proposed> <s390x> <xenial> <zesty> <snapd (Ubuntu):In Progress by mvo> <snapd (Ubuntu Trusty):New> <snapd (Ubuntu Xenial):New> <snapd
<mup> (Ubuntu Zesty):New> <snapd (Ubuntu Artful):New> <snapd (Ubuntu Bionic):In Progress by mvo> <https://launchpad.net/bugs/1734038>
<jdstrand> zyga: the problem is that if the sru goes through without the updated rule, all non-snap users that use apparmor-utils will regress (ie, server/cloud users)
<jdstrand> so we either need to delay the snapd sru to depend on the apparmor sru, or fix the snapd sru and do apparmor sru separately
<jjohansen> zyga: so you can't currently do that, see bug
<zyga> jjohansen: looking
<zyga> jjohansen: that's okay then
<zyga> jjohansen: I think we can land https://github.com/snapcore/snapd/pull/4329
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<mvo> cachio: sorry for the slow answer, I just pushed the new packages into -propsed but they need SRU approval first, the only change is to change "include" to "#include" in our snap-confine apparmor file
<cachio> mvo, great, thanks
<cachio> mvo, ok, I am creating beta images to run beta validation
<cachio> but my internet connection is slow today
<mvo> cachio: thank you, much appreciated
<mvo> cachio: sorry for this last minute change :/
<cachio> mvo, np
<mup> PR snapcraft#1779 opened: catkin-tools plugin: use stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1779>
<kyrofa> cratliff, if you could give that ^ a test when you're able I'd very much appreciate it!
<kyrofa> It looks big, but that's only because I added that integration test
<cratliff> kyrofa, Yeah, I'll give it a look.
<lundmar> it would be nice if anyone whould like to review and +1 this request: https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 . Thanks.
<jdstrand> zyga: hey, I just noticed that we are calling a nmber of things after sc_create_or_join_ns_group() (the setns() to the snap's mount namespace). this isn't wrong per se since we are mounting things like /sys into the namespace, but feels a bit weird. eg, shouldn't we be setting up the snap's freezer cgroup before we setns?
<zyga> jdstrand: hmm
<zyga> jdstrand: I think the freezer needs to be set just before we exec, at any time
<zyga> jdstrand: I wanted to avoid snap-confine getting frozen by accident in the more critical aprts
<zyga> *parts
<zyga> jdstrand: not sure if that answers your question, please ask again if needed
<jdstrand> zyga: really I'm not asking for you to do anything right this second but maybe add to your todo to consider that we should probably setns() as late as possible
<jdstrand> zyga: and do as much management of the snap in the default mount namespace as possible, to avoid subtle bugs down the line
<zyga> jdstrand: noted
<zyga> jdstrand: I added two points to your description on the v2 patch
<zyga> jdstrand: (fantastic description btw, worth saving in a README)
<kyrofa> snappy-m-o, autopkgtest 1779 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<jdstrand> zyga: thanks
<kyrofa> Hey niemeyer, are you around? Would you mind taking a quick look through #4323?
<mup> PR #4323: interfaces: add gpio-memory-control interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/4323>
<niemeyer> kyrofa: Hey
<niemeyer> kyrofa: Not entirely, but I have a quick window now.. let me look
<kyrofa> niemeyer, really just need your input on the name
<niemeyer> kyrofa: Do you have docs for the kernel?
<niemeyer> kyrofa: On that device
<kyrofa> niemeyer, the link there is all I have: https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/bcm2835-gpiomem.c
<niemeyer> kyrofa: LGTM
<kyrofa> Thanks niemeyer, I appreciate your time :)
<zyga> ok, time to sleep!
<zyga> night night everone
<zyga> everyone
<mup> PR snapd#4323 closed: interfaces: add gpio-memory-control interface <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/4323>
<lundmar> is the build.snapcraft.io not triggering amd64/i386 builds anymore? I just triggered a build but only arm gets built.
<lundmar> something is wrong with build.snapcraft.io
<mup> PR snapcraft#1780 opened: cli: add export-login command <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1780>
#snappy 2017-12-01
<mup> PR snapd#4337 opened: cmd/snap: use snap-exec from core with a classic snap when reexecing <Created by mwhudson> <https://github.com/snapcore/snapd/pull/4337>
<lundmar> definitely something is wrong with build.snapcraft.io - it's not building amd64 and i386 snaps. I can't even trigger them manually.
<mborzecki> morning
<ogra_> [   25.409984] cgroup: new mount options do not match the existing superblock, will be ignored
<ogra_> hmm .... why would anything expect a superblock there
<mup> PR snapd#4321 closed: configstate: simplify ConfigManager <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4321>
<mup> PR core#65 opened: xdg-settings: make the reply timeout for xdg-settings set 5min <Created by mvo5> <https://github.com/snapcore/core/pull/65>
<mborzecki> `man --what snap` shows 'nothing appropriate', but `man snap` shows the manpage
<mborzecki> any ideas what might be causing this?
<mvo> mborzecki: hm, that appears to be working here on ubuntu
<mvo> mborzecki: I would assume some metadata in the man-page missing but that is of course not very helpful
<mborzecki> mvo: something strange on Arch again, snapd package is installed first in project prepare and man-db is installed later in task prepare, that does not seem to run mandb to index the pages
<mborzecki> i think that if if the order was reverse, package install hooks should retrigger indexing of new manpages, but for now there's a workaround at least
<mborzecki> mvo: since you're available, can i ask you for a review of #4313?
<mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<mvo> mborzecki: aha, interessting
<mvo> mborzecki: sure, I have a look
<mvo> mborzecki: hm, one low hanging fruit might be to split out the (small) change to make the snapstate/corecfg code look at ParseLegacySchedule, that would (slightly) reduce the PR size and is probably trival to pull in
<mborzecki> mvo: i'll try to pull it into a separate PR
<mup> PR snapd#4338 opened: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4338>
<mborzecki> mvo: ^^
<mvo> mborzecki: thanks, I started with the other PR now as well
<mborzecki> great, thanks :)
<Chipaca> so... I can repro the EOF thing
<mvo> Chipaca: what EOF thing is that?
<Chipaca> mvo: spread test dying with no failure message, debug and restore giving EOF (or "ssh: zlib failed to flush data" if you have a newer spread)
<Chipaca> now going to try too repro in qemu, so i can get dmesg; i'm suspecting the whole thing is OOMing or getting killed by something
<mvo> Chipaca: oh, maybe related to the compression changes?
<mvo> Chipaca: aha, ok
<Chipaca> mvo: no, the bare EOF is in a spread pre-compression
<Chipaca> the message is different with compression, but it's the same issue: it dies with no apparent reason, and it stays dead (so you get no debug info)
<Chipaca> ie instead of the useful logs from the debug step you just get EOF (or failed-to-flush from ssh/zlib)
<mvo> Chipaca: aha, thanks
<mvo> Chipaca: how did you manage to reproduce it?
<Chipaca> mvo: spread  -seed=1512088627 -shell linode:ubuntu-14.04-64:tests/main/{interfaces-browser-support,abort}
<Chipaca> mvo: (with my users PR; haven't tried master)
<Chipaca> bah, change  -shell to -debug
<Chipaca> (with -shell you need to do things by hand :-) )
<mvo> oh, nice
<Chipaca> mvo: for Friday values of 'nice'
<mvo> Chipaca: heh, well, reproducible++ :)
<mup> PR core#65 closed: xdg-settings: make the reply timeout for xdg-settings set 5min <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/65>
<Chipaca> in other news, I've been typing âM-x join-lineâ for ages, when âM-^â does basically the same thing /o\
<Chipaca> (M-^ is delete-indentation, not join-line, so you don't get the hint about using the key combo -- but join-line is an _alias_ of delete-indentation... //o\\)
<mvo> Chipaca: heh, emacs is almost as good as nethack when it comes to text adventures
<mup> PR snapd#4316 closed: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316>
<Chipaca> as feared, it looks like it's killed by confinement :-(
<Chipaca> mvo: the new users thing tries to be smart by not even looking at non-people users for snap directories, where non-people are things below UID_MIN (from reading login.defs) and things with a shell not in /etc/shells
<Chipaca> mvo: it also reads extrausers/passwd
<Chipaca> these three things throw up denials -- and it looks like at some point it's all just killed outright (i don't get to see logs about that)
<mvo> Chipaca: woah
<Chipaca> mvo: I can drop the shells lookup and hardcode UID_MIN to 1000, and only look at extrausers in core, but it feels like a step back
<ikey> Chipaca, if you're trying to determine human vs non human you might look at this for inspiration: https://github.com/solus-project/qol-assist/blob/master/src/user-manager.c
<ikey> we had to solve the same thing in solus for qol-assist to reliably detect peoples
<ikey> being human basically comes down to having a valid shell *and* meeting uid requirements
<Chipaca> ikey: yes, that's what i implemented
<ikey> and i got a cheap "grab all user shells" function here https://github.com/solus-project/qol-assist/blob/master/src/util.c#L31 to save keep calling the function
<Chipaca> now i need to go scrub my eyes of Qs
<ikey> heh
<Chipaca> dude
<Chipaca> the problem is that i get killed by seccomp (or sth) because of doing those checks
<ikey> i get that - was merely trying to save you duplication of effort :p
<ikey> no need to dude me :p
<Chipaca> ikey: i appreciate that
 * ikey gets back to fighting with appstream-builder
<ikey> aka worlds most inefficient tool
<Chipaca> mvo: did you merge a pr bboozzoo asked not to be merged yet?
<Chipaca> i mean #4316
<mup> PR #4316: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316>
<Chipaca> ikey: where does QOL_MIN_UID come from in your code?
<ikey> config.h
<ikey> >_>
<ikey> its a build time option
<ikey> lol
<ikey> technically to be more portable you'd want to consult shadow config
<ikey> which is begging for issues
<Chipaca> ikey: /etc/login.defs is what you want to consult for that one
<ikey> swhat i said :p
<Chipaca> mmkay
<ikey> solus: Package shadow has file /etc/login.defs
<pedronis> mvo: hi, if you have seen I have put more comments with issues in the default-provider PR, happy to chat again about it, better on Monday though I suppose
<mborzecki> mvo Chipaca zyga's comment https://github.com/snapcore/snapd/pull/4316#pullrequestreview-79846561 was supposed to be fixed by this patch https://github.com/snapcore/snapd/pull/4316/commits/44cec064f04899d4821093b0c69459df5e331926 can you take a quit look at it?
<mup> PR #4316: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316>
<mborzecki> is there a checker that can do `c.Check(iface, Or(<another-checker>), alternative1, alternative2)` ?
<pstolowski> mborzecki, I don't think so
<mborzecki> i have an error message that depends on the order the elements are ranged over in a map, and it's different on each run ;?
<cachio> mvo, beta validation almost completed
<cachio> no regressions
<cachio> results on here: https://docs.google.com/document/d/16sp6iXv9rqVsysjmAS9DxN7lfkoy-tKvJN2BpF3d4Wk/edit
<pstolowski> mborzecki, in such cases we usually sort
<pstolowski> mvo, ah, sorry, map.
<pstolowski> mborzecki, ^
<pstolowski> mborzecki, DeepEquals should do it, no?
<mborzecki> nope, it won't
<mborzecki> what i'm doing is that once a snap yaml is parsed, i verify that the apps that have `start-before/start-after: list-of-apps` (new thing) are actually valid
<mborzecki> so i need to range over the snap.Info.Apps, and it's a `map[string]*AppInfo`, so keys are in some random order
<pstolowski> mborzecki, sort the keys first?
<mvo> cachio: great, looking
<mvo> Chipaca: if I did I'm sorry, I though all was addressed. maybe we need to use "blocker" more liberal if I prematurely merged
<Chipaca> mvo: it's unclear to me :-)
<mvo> pedronis: monday sounds good, I'm not sure I have the energy to dive into it
<mvo> mborzecki: did I merge 4316 too early?
<cachio> mvo, the core revert test cannot be executed until the user assertion is not updated
<mborzecki> mvo: i fixed the problem that zyga raised in a patch listed ^^, i'd be gread if you could give it a 2nd look
<cachio> mvo, it is also affecting some executions in spread-cron
<cachio> mvo, I'll be 5 minutes late today
<mborzecki> mvo: https://forum.snapcraft.io/t/snap-app-startup-ordering/3009 systemd After/Before we talked about yesterday
<mvo> mborzecki: thanks for the form topic
<mvo> cachio: late> no worries, I may be late myself (or miss it entirely :/)
<mvo> niemeyer: I *may* miss the standup today, a repairman will come today and its not clear when exactly. I need to open him and explain what needs to be done etc so there is a chance I cannot make it
<niemeyer> mvo: Heya, and ack, thanks for the note
<mvo> niemeyer: thank you
<niemeyer> mvo: Opening a repairman must take a while, so take your time :P
<mvo> mborzecki: I think your changes in snap-mgmt look fine,
<niemeyer> pedronis: Hey, btw, I suspect we talked across each other for a while yesterday
<mvo> mborzecki: just in case, if things are not quite ready feel free to use the "blocked" label (or just close the PR)
<mborzecki> mvo: noted
<mvo> mborzecki: and no worries
<niemeyer> mvo
<niemeyer> mvo: I suspect pedronis was really talking about the check inside changeInProgress, rather than the test that for loop that verifies whether the current change has the link-snap
<mvo> niemeyer: *nod*
<mvo> niemeyer: yeah, he added some further comments to the PR, I will add more tests and rework the approach on monday
<niemeyer> mvo: That test indeed seems unnecessary, I think, since the loop right above would have caught the same situation and skipped the rest altogether
<mvo> niemeyer: right
<mvo> niemeyer: I was thinking about creating something circular as a testcase just to be sure we handle this
<niemeyer> mvo:  You mean in this area, or in state specifically?
<mvo> niemeyer: for this specific area
<mvo> niemeyer: a circular content provider loop or something, I have not thought it through yet but the discussion from yesterday indicated it is probably a good idea to have a test for this
<mup> PR snapd#4339 opened: userd: generalize dbusInterface <Created by mvo5> <https://github.com/snapcore/snapd/pull/4339>
<niemeyer> mvo: Hmm
<mvo> niemeyer: if you think its not needed/something different is needed, happy to do that instead
<niemeyer> mvo: I'm trying to think whether the cost benefit would good in this case, or whether we should try to split it down into more fundamental properties of the system that would just mean we handle this correctly in the end
<niemeyer> mvo: For the case we discussed yesterday, we might artificially produce a change set that has the to-be-included install before and the another one after the expansion task
<niemeyer> s/and the another/and then another/
<pedronis> niemeyer: mvo: IÂ don't think we can do something sane for the circurlar case until we split  setting up repo/slots and plugs for snap, vs handling autoconnect, atm it's all in one task
<pedronis> IÂ imagine that pawel will need to change that though
 * mvo needs to leave to get lunch, will be back in some minutes
<niemeyer> mvo: o/
<niemeyer> pedronis: I think we should just prevent the circular case from going through
<niemeyer> pedronis: Other package managers show this is a huge can of worms
<pedronis> niemeyer: it's just that we can only detect while doing, not upfront, unless we consult the store potentially various level deep at the beginning
<niemeyer> pedronis: Well, we can simply not attempt to close the circle
<niemeyer> pedronis: Again taking the view that those are not strictly pre-requisites
<niemeyer> pedronis: In practice, if we find a snap to be installed that is already on the list, just don't order it further
<niemeyer> pedronis: The base snap is the only real pre-requisite, and this one will have been inserted into the change upfront
<niemeyer> pedronis: I mean, just don't order it further if it would establish a circle
<pedronis> it will be fairly non-deterministic though, otoh it might be a corner case enough that we don't care
<niemeyer> pedronis: Right, and also a "doctor it hurts" case
<niemeyer> pedronis: The connection will simply be established later, and good interface hooks should tolerate that nevertheless
<mup> PR snapd#4340 opened: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4340>
<mup> PR snapd#4341 opened: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4341>
<LyzardKing> Hi! I need help with the waf plugin. I need to build pycairo, and it comes with a waf installer. By default the installer uses python2...how can I run "python3 ./waf..."?
<ikey> pycairo also has setup.py
<ikey> so you can build it setuptools style
 * ikey actually sees no waf in the pycairo tarball :/
<ikey> LyzardKing, are you building from https://github.com/pygobject/pycairo/releases/ ?
<LyzardKing> ikey: That version apparently does not have py3cairo, which is needed by pygobject
<ikey> you build it with python3
<ikey> https://dev.solus-project.com/source/python3-cairo/browse/master/package.yml
<ikey> idk what the new ones like :3
<ikey> (1.15)
<ikey> i can python3 -c 'import cairo'..
<LyzardKing> I tried adding the tarball from github to the requirements.txt, but that didn't work...
<LyzardKing> the setup for pygobject can't find py3cairo, (even though pycairo is indeed installed from the github tarfile)
<LyzardKing> configure: error: Package requirements (py3cairo >= 1.11.1) were not met: No package 'py3cairo' found
<ikey> o_O
<ikey> thats pkgconfig level stuff
<ikey> i.e. python3-cairo-dev or whatever the subpackage would be called..
<LyzardKing> ...If I install that as a build-dependency, I then have the issue that the version in the repo is 1.10.0, and the first version with pip is later (1.11.1?)
<LyzardKing> And I can't use the version from the repo because in a classic snap it will segfault...
<jdstrand> mvo: hi! I wanted to confirm something. is the os snap supposed to ship device files in /dev?
<mvo> jdstrand: no, that is a bug AFAICT
<jdstrand> mvo: related, are base snaps not supposed to ship device files in /dev?
<jdstrand> it seems for sure base snaps should not
<jdstrand> but it wasn't clear to me about the os snap
<jdstrand> mvo: would you agree with my assessment re base snaps?
<mvo> jdstrand: I think we don't need /dev files, do we have those currently?
<jdstrand> mvo: base-18 did and I mentioned they should be removed (I don't know how we would even override devices via a base snap. that seems really wonky...)
<jdstrand> mvo: let me double check core
<mvo> jdstrand: yeah, base-18 is just a bug
<mvo> jdstrand: I'm not 100% certain about core itself, but probably the same, I don't think we need them
<jdstrand> mvo: core ships them: unsquashfs -lls /var/lib/snapd/snaps/core_3604.snap | grep 'squashfs-root/dev/'
<pedronis> mvo: how does that work on core?
<jdstrand> mvo: it would be ideal if we could say 'no device files allowed in snaps'. right now I whitelist for os snaps and mistakenly for base snaps
 * jdstrand will fix test for base snaps
<pedronis> mvo: where does /dev come from on a core device?
<jdstrand> mvo: I suspect you may be right that those devices files in core are not needed, but I'm not sure how the early boot code works (ie, pedronis question)
<pedronis> jdstrand: we plan at some point to have bootable bases so that question will apply to them
<pedronis> as well
 * jdstrand raises eyebrows at boot base
<jdstrand> how is that now an os snap?
<jdstrand> s/now/not/
<mvo> pedronis: initramfs iirc, but I need to double check
<pedronis> jdstrand: that might be how to do it, but at some point the plan was not to have os snaps anymore, just bases and a some kind of snap carrying snapd
<pedronis> as I said this is is not an immediate concern
<mvo> jdstrand: yeah, what pedronis said, the idea was to phase out "os" snap and use "base" snaps and a "snapd" snap and core snap only for compatiblity with classic snaps
<mvo> jdstrand: but we are some days behind this
<jdstrand> pedronis: I thought the plan was strip down the os snap to what is needed for snapd to run/etc and everything else in a base snap.
<jdstrand> oh, this is news to me
<mvo> jdstrand: we cannot easily do that with core at least, we might introduce new os snaps though
<jdstrand> I thought os was going to still be a thing, just alot smaller
<mvo> jdstrand: yeah, its all a bit in the air still, we have some options
<jdstrand> how in the world are you going to resolve things like multiple systemds?
<mvo> jdstrand: the trouble is that we cannot change core, it is used for classic snaps because snapcraft may link to things in /snap/core/current
<pedronis> jdstrand: there's is only one bootable base per device
<pedronis> but yes, we do have a question about where do services come from
<jdstrand> well, 'bootable base' is then effectively 'os snap minus snapd'
<pedronis> jdstrand: to be clear this is all for core dvices
<pedronis> it's not a concept relevant on classic
<jdstrand> anyway, I don't mean to distract
<pedronis> jdstrand: that part is not clear,  some discussion mentioned that systemd would be in the snapd snap
<pedronis> lots of questions and options
<jdstrand> heh, well, that ends up looking a lot like an os snap after you add its deps, etc
<jdstrand> anyway
<jdstrand> mvo: so, device files cause problems with the review tools
<mvo> jdstrand: yeah, it will be conceptually similar
<mvo> jdstrand: cause problems for the os snap as well?
<mvo> jdstrand: or just for the base snaps?
<jdstrand> mvo: cause if they are in the snap, you can't mknod them unless you are root
<pedronis> anyway whatever we do bootable bases will have more constraints and rules than generic bases
<jdstrand> mvo: conceptually they are problematic
<mvo> jdstrand: its ok to have them blacklisted for now, we may need them for bootable bases, otoh I think we can probably get away with the right initramfs magic
<jdstrand> mvo: the kernel requires root to mknod. unsquash as non-root just creates regular files, so a resquash fails. as root is possible, but really need the tools confined (eg, as a snap) and that causes issues with the security policy
<mvo> jdstrand: aha, I see. does fakeroot helps?
<jdstrand> today base and os snaps are all manual reviewed anyway, so we skip the test, but if the device files aren't meant to be there at all, it would mean we don't have to do anything special in the tools
<jdstrand> mvo: nope
<jdstrand> the kernel requires root
<jdstrand> fakeroot just gives you regular files
<mvo> jdstrand: even inside the fakeroot env?
<mvo> jdstrand: I though as long as you are inside the fakeroot session you see them as device files (because of the preload magic), no?
<jdstrand> that's right, unsquash as non-root skips them, unsquash with fakeroot creates regular files, unsquash as root works but need lots of extra security permissions
<jdstrand> mvo: let me try that. I just did fakeroot unsquash then looked
<mvo> jdstrand: I think that should work
<mvo> jdstrand: anyway, we will know soon :)
<mvo> jdstrand: the key is that have the same FAKDEROOTKEY environemnt
<LyzardKing> ikey: Is it possible to satisfy the python-cairo-dev dependency from pip?
<jdstrand> mvo: that seems to work.
<jdstrand> mvo: thanks!
<mvo> jdstrand: yay, great
<Chipaca> jdstrand: in 14.04, should seccomp be logging when it kills things?
<Chipaca> jdstrand: i'm trying to debug a thing where a whole process group is killed, in 14.04 only, but not getting anywhere
<Chipaca> jdstrand: (the reason it's hard to debug is that it's in spread, and the process group includes everything that spread has a hand in afaict)
<jdstrand> Chipaca: it should, yes. do sudo sysctl -w kernel.printk_ratelimit=0 and watch /var/log/syslog or dmesg (not journalctl)
<mup> PR snapd#4342 opened: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342>
<Chipaca> jdstrand: all that appears in syslog is apparmor denials :-(
<Chipaca> http://pastebin.ubuntu.com/26089734/
<jdstrand> Chipaca: is it getting killed or just dying on its own cause it doesn't have what it needs? (that is very common)
<Chipaca> jdstrand: the thing trying to run dies, but the bash running it dies also, the su running that bash dies, and the bash running that su dies
<Chipaca> jdstrand: (so the 'debug' phase of spread gets EOF)
<Chipaca> jdstrand: and the restore phase also EOFs
<Chipaca> ie the ssh client connection from spread dies
<jdstrand> that's a massacre
<Chipaca> it's like oprah, but with kill
<jdstrand> the bash running the thing shouldn't die unless it is using 'exec thing'
<Chipaca> jdstrand: now, there's a bug i need to fix, but this cascade of death seems to be indicating a deeper concern, which is why i'm still digging
<jdstrand> I mean, if you are using su -c 'bash -c foo'
<jdstrand> then I would expect foo, bash and su to all exit
<jdstrand> but that upper bash is presumably the spread debug which shouldn't die since it is interactive
<jdstrand> anyhoo, good luck :)
<Chipaca> :-)
<Chipaca> thanks
<Chipaca> jdstrand: I can hand it over to you if you feel like bashing your head on something soft
<jdstrand> hehe
<jdstrand> I'm good :)
 * Chipaca is very generous
<ikey> jdstrand, quick q - when i do a build of the snaps later will those dudes need manual review or is that tooling active now?
<ikey> gonna update the base images once the solus repos sync today
<mup> PR snapd#4331 closed: systemd: add support for the mask/unmask operations <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4331>
<mup> PR snapd#4332 closed: corecfg: also "mask" services when disabling them  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4332>
<sergiusens> kyrofa get ready for a tough review :-)
<kyrofa> sergiusens, okay
<jdstrand> ikey: it is live now (as of today)
<ikey> ah thanks bud :D
<ikey> no promises i can get it done today but i thought id ask you before we all EOW
<kyrofa> sergiusens, snapcraft#1779 is green, when you have some time to take a look
<mup> PR snapcraft#1779: catkin-tools plugin: use stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1779>
<sergiusens> kyrofa sounds good, I'll do it after lunch
<sergiusens> btw, the fact that we have $(root)/snapcraft/tests and not $(root)/tests is really starting to annoy me
<mup> PR snapcraft#1781 opened: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
<sergiusens> kyrofa snapcraft#1781
<mup> PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
<mup> PR snapd#4343 opened: interfaces: rename sanitize methods <Created by stolowski> <https://github.com/snapcore/snapd/pull/4343>
<cachio> mvo, there?
<cachio> mvo, I am working with the test that check interfaces after reboot
<cachio> mvo, what I see is that after reboot the directory /snap/core/current is empty
<cachio> and /snap/core/3615/ also empty
<cachio> mvo, at the begining of the test it is not empty
<kyrofa> jdstrand, any ideas on this issue? https://askubuntu.com/questions/978639/mount-error-when-installed-using-snap/981802
<cachio> mvo, I see this in a linove vm
<cachio> do you want ips?
<mvo> hey cachio
<mvo> cachio: yeah, if you /msg it to me, that would be cool
<mvo> cachio: I can poke around a bit
<mvo> we need to think how we can tame the tests again :/ master is timing out a lot right now (runtime more than 49min)
<mup> PR snapcraft#1778 closed: Add sentences to error when registering name <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1778>
<jdstrand> kyrofa: otoh, no
<jdstrand> kyrofa: maybe /home is a separate partition?
<sergiusens> kyrofa did you have a chance to check the PR? I am EODing in an hour or so
<kyrofa> sergiusens, not yet, just about done here, then I can
<mup> PR snapcraft#1782 opened: project_loader: support grammar on architectures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1782>
<mup> PR snapcraft#1761 closed: lxd: ContainerConnectionError on failed launch/ start <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1761>
<mup> PR snapcraft#1783 opened: tests: run codespell as part of static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1783>
#snappy 2017-12-02
<mup> PR snapcraft#1784 opened: store: show helpful message for 'snapcraft list-keys' with no keys <Created by BayMinimum> <https://github.com/snapcore/snapcraft/pull/1784>
#snappy 2017-12-03
<billythekido> hi guys. I'm on Ubuntu 17.10 and I see that the majority of gnome programs are already available in Snap format. I was considering replacing the apt versions with snaps. Would you advise against that?
<billythekido> also can anyone share thoughts about the policy of Ubuntu on 18.04 concerning snaps? In a fresh install, will the snap version of the gnome programs be installed by default or the apt versions of the tools will be preferred? I know it is speculative at the moment, just asking for thoughts
<billythekido> no thoughts?
<Faults> I'm no pro, but depends bit on app. Most of the Apps don't include theming so your Apps looks like Windows NT 4.0
<Faults> I truely like the Snap (and Flatpak), but you might encounter regression... Or in some cases you will gain benefit.
<Faults> Example if you prefer to have latest and greatest Apps, but you prefer using super stable distro like Ubuntu LTS, Mint or Debian.
<billythekido> good points. the truth is during weekends I gamble the stability of my box by experimenting with experimental features. so far it has not bit me :P
<billythekido> I see that canonical is pushing forward with snaps, providing almost the majority of default programs in that version. it is completely unclear though whether they will go with them as "default" apps in 18.04
<billythekido> as far as I know there is no posts on the net clarifying the topic. I spotted a couple saying that they plan to cover all the default snap apps but no explicit input on whether they will be used by default
<mup> Bug #1736006 opened: Replace deb with snappy version <Snappy:New> <https://launchpad.net/bugs/1736006>
<mcphail> Hi. What's the policy on adding shareware to the snap store? Too dodgy?
<m4sk1n_> hi
<m4sk1n_> I'm trying to add i18n support for snapcraft
<m4sk1n_> marked strings, added build_i18n to setup.py, but can't get to make it using .mo files
#snappy 2018-11-26
<mborzecki> morning
<zyga> Good morning
<zyga> offie is a bit cold so I'll start from ... bed :)
<mborzecki> zyga: hey
<zyga> hi :)
<mborzecki> zyga: did you look in 2.36 apparmor or should I?
<zyga> I looked
<zyga> I was unable to reproduce it for ~5 hours
<zyga> ideas on what is the magic trigger are very much welcome
 * zyga wondres what caues commands with leading space to not be recorded in bash history
<zyga> mborzecki: I have something to share
<zyga> just need a moment
<zyga> mborzecki: https://pastebin.ubuntu.com/p/DS2BFfgYGp/
<zyga> mborzecki: pair with https://github.com/zyga/spread/tree/slices (though it contains extra stuff)
<zyga> mborzecki: in spread.yaml add measure-each: ./measure.sh
<zyga> mborzecki: needs tweaking for running in spread.yaml from snapd
<zyga> because I chose different paths
<zyga> should yield useful fixes very quickly
<zyga> and may yield some eye-opening mistakes
<zyga> oddly it fails on bintfmt misc being mounted
<zyga> perhaps due to automount somewhere?
<zyga> good morning mvo
<mvo> hey zyga
<mup> PR snapd#6194 closed: snap: make description maximum in runes, not bytes <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6194>
<zyga> need to take the dog out, brb
<pstolowski> mornings
<mvo> hey pstolowski - good morning
<zyga> Hey PaweÅ
<zyga> back
<mborzecki> mvo: pstolowski: hey
<mborzecki> guys, how about we un-manual fedora-28 until we fix f29?
<mvo> mborzecki: sounds good to me
<ackk> hi, is there a way to get stdout/stderr from a snap hook even if it doesn't fail?
<mup> PR snapd#6211 opened: spread: run tests on Fedora 28 again <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6211>
<zyga> ackk: pstolowski would know but I don't believe so
<ackk> zyga, not even in some log?
<zyga> yep
<zyga> not anywhere
<zyga> maybe some things are logged in tasks in case errors occur
<zyga> but not sure
<ackk> yeah you get stderr if the hook fails
<pstolowski> ackk: not really, apart from manually writing it from withing a hook to a place snap can write to
<ackk> but I have a case where it doesn't but things don't work as expected. so far I've been forcing a failure to get the output
<zyga> mvo: hey
<ackk> pstolowski, I see
<zyga> mvo: some experiments from last week
<zyga> https://github.com/snapcore/snapd/pull/6212
<zyga> since nothing can land because everything is perpetually red
<mup> PR #6212: tests: measure kernel properties across tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6212>
<mup> PR snapd#6212 opened: tests: measure kernel properties across tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6212>
<zyga> mvo: to use this for real you need patched spread
<zyga> but I wanted to share it
<mvo> zyga: thanks, looking
<zyga> it's super simple
<zyga> I played with it on a toy project
<zyga> trying to tune some of the things I capture
<mvo> zyga: do you think the kernel is a problem during the tests ? or is this just an example?
<zyga> all of the "measurables" are working fine in my toy project
<zyga> mvo: I do think it is a problem
<zyga> as in
<zyga> look what is measured
<zyga> I think all of those fail in snapd
<zyga> without exceptions
<zyga> some will need tuning in spread.yaml
<zyga> some in tests
<zyga> some in test helper code
<ackk> pstolowski, unrelated question: I have a clean cosmic install, it seems gnome doesn't find icons for desktop snaps (like gnome-calculator, gnome-system-monitor,...). when I search they all show the default icon. is that a known issue?
<mvo> zyga: silly question - should/could we run this after each restore?
<zyga> mvo: that's exactly when this runs :-)
<zyga> mvo: https://github.com/snapcore/snapd/pull/6212/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R429
<mup> PR #6212: tests: measure kernel properties across tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6212>
<zyga> it runs when the system state is supposed to be invariant
<zyga> mvo: realistically I think it will be a long while before we can really merge this
<zyga> but I wanted to share what I have
<mvo> zyga: spread.yaml has "measure-each" - this is not in the released spread, yes?
<zyga> using this locally can yield real fixes
<zyga> mvo: that's right but that's not the problem
<zyga> the problem is that we have many tests and complex setup that is broken
<zyga> it will be a while before this turns green
<zyga> mvo: the upside is that unlike causual spread debugging
<mvo> zyga: what I mean is, could we run this even without measure-each by running it last in restore-each?
<zyga> this is failing fast
<zyga> mvo: no, they run at the wrong order
<mvo> zyga: and we can't put them in the right order without changing spread?
<zyga> no
<zyga> but that's irrelevant really
<pstolowski> ackk: i don't know that, you may want to ask around on #ubuntu-desktop
<zyga> spread ownership is a separate topic
<zyga> this will not pass yet
<zyga> note I only enabled kernekl
<zyga> *kernel
<zyga> out of all the set of measuremetns
<zyga> I think kernel will show the biggest offenders
<zyga> stray processes
<zyga> and stray mounted stuff
<ackk> pstolowski, ok. thanks. do you know what would be the right lp project to report the issue?
<zyga> mvo: next we should look at files, specifically /var
<zyga> mvo: anyway, anyone can run this trivially
<zyga> and see what they can carve of the mess plate
<mvo> zyga: why can't it run on restore? pardon my ignornce
<pstolowski> ackk: probably one of the affected projects on LP - e.g. https://bugs.launchpad.net/ubuntu/+source/gnome-calculator - you may also ask on the forum https://forum.snapcraft.io/
<zyga> mvo: it must run before any prepare and after all restore
<zyga> mvo: there's no wat do do that
<zyga> *no way
<mvo> zyga: because spread provides no way to order things?
<mvo> zyga: I mean in the toplevel spread.yaml we have "prepare-each" - we cannot run it there before we run anything else?
<zyga> mvo: if you hand tune a project you might run it at the right order
<zyga> but it can be broken by simple changes to unrelated parts
<ackk> pstolowski, thanks
<zyga> mvo: but that's not the problem, really
<zyga> mvo: the problem is we have a backlog of things to fix in our suite first
<Chipaca> moin moin
<Chipaca> the staticcheck pr refuses to go green :-(
<pedronis> mvo: hello, bit of a high number of open PRs
<mvo> zyga: I think I'm missing things here, the "but it can be broken by simple changes to unrelated parts" is something I don't grok, I would assume this only breaks when we change the toplevel prepeare-each and do something else before the "measure", or what am I missing?
<mvo> pedronis: yes :/
<mvo> zyga: let me play with this real quick, maybe then I understand things better
<mvo> pedronis: and good morning - hope you had a good trip back
<zyga> look at spread patch
<zyga> see what it doeas
<zyga> *does
<zyga> it is easier to discuss things
<zyga> I added it to the PR
<zyga> I pushed a typo fix as well, my local measure.sh was slightly different and some editing broke it, it should work now
<mvo> pedronis: also 2.36 is not passing tests right now and tests are flaky in general, not great times
 * Chipaca hugs zyga 
<zyga> Chipaca: hey :)
<zyga> mvo: the patch is https://github.com/snapcore/spread/pull/47
<mup> PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>
<Chipaca> zyga: really sorry I answered your feedback on 6205 so grumpily on friday
<mvo> zyga: maybe we need to talk during the standup I still don't get why we can't do it in prepare-each
<mvo> zyga: I read the diff
<mvo> zyga: anyway, let me play with this
<mvo> zyga: I'm sure my ignorance will fade then
<pedronis> mvo: will it help something immediate, this?
<zyga> pedronis: no but fixes from running it will
<zyga> I'm trying to land my stuff
<zyga> but since it's always red
<zyga> and normal debugging doesn't yield results
<zyga> I wrote this
<pedronis> zyga: https://github.com/snapcore/snapd/pull/6147 this is green and without reviews
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> pedronis: god knows how many times I retriggered test last week
<zyga> it's utterly wasteful
<pedronis> zyga: mvo: we should have a HO
<mvo> zyga: does measure.sh already raise the red flag(s) you describe in your spread PR?
<mvo> pedronis: sure, happy to
<zyga> mvo: as in does it really fail?
<mvo> zyga: aha, yes - I see it now
<pedronis> pstolowski: hi, how it's going with hot plug and conflicts?
<pedronis> zyga: this one fails very consistently in one test fwiw: https://api.travis-ci.org/v3/job/454933150/log.txt
<pstolowski> pedronis: hey, i need to push the changes, will do in a moment
<pedronis> zyga: mvo: can we do a HO now?
<zyga> pedronis: what's the PR link if I may ask?
<zyga> pedronis: yes
<mvo> pedronis: sure
<pedronis> zyga: #6149
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> pedronis: did you notice the comment on that PR?
<zyga> pedronis, mvo: so shall we join the standup HO
<pedronis> zyga: which comment?
<zyga> https://github.com/snapcore/snapd/pull/6149#issuecomment-438771770
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> it depends on another PR going in first, I proposed it for full context
<pedronis> zyga: ok, we do really need this HO
<zyga> stuck in HO again
<zyga> hmmm
<zyga> can we please try meet, I don't know how to fix this
<zyga> pedronis, mvo: ^
<zyga> tried logging out and back in
<zyga> trying with my personal account
<zyga> no luck
<zyga> I gave up
<zyga> pedronis: can we please try meet?
<mvo> zyga: sure
<zyga> thanks, sorry, I really don't know what's wrong with HO
<pedronis> zyga: mvo: https://meet.google.com/bwv-hykn-thy
<zyga> same browser, same network
<zyga> thanks
<mup> PR snapd#5792 closed: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5792>
<mup> PR snapd#6174 closed: many: add snap debug refresh-catalogs <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6174>
<mup> PR snapd#6184 closed: perf: add performance helpers <Performance ð> <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6184>
<mup> PR snapd#6110 closed: spread.yaml: add openSUSE Tumbleweed <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6110>
<mup> PR snapd#6209 closed: run-checks: discard test good/bad banner <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6209>
<mup> PR snapd#6212 closed: tests: measure kernel properties across tests <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6212>
<mup> PR snapd#6111 closed: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6111>
<mup> PR snapd#6163 closed: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6163>
<mup> PR snapd#6164 closed: wrappers: rename the desktop file to their apps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6164>
<mup> PR snapd#6166 closed: tests: run gpio test on core18 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6166>
<mup> PR snapd#6205 closed: many: staticcheck fixes <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6205>
<Chipaca> zyga: any news on the 2.36 fix?
<zyga> no
<zyga> I cannot reproduce it!
<zyga> but I was running main in a loop
<zyga> out of 2.36 release branch
<zyga> perhaps it is broken by other suites?
<Chipaca> pstolowski: mborzecki: #6104 has half a review from both of you :-)
<mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<Chipaca> zyga: what is 'running main in a loop'?
<zyga> running the main suite in a loop
<Chipaca> zyga: how were you running it?
<zyga> Chipaca: spread running xenial main suite out of the 2.36 release branch
<zyga> I'm running again without just main (so all suites)
<zyga> let's see if I can hit this
<Chipaca> zyga: in the run I have here the failing  tests didn't run non-main tests before failing
<Chipaca> zyga: (search for /runs)
<zyga> :/
<zyga> so why did it not fail for me
<zyga> eh eh
<Chipaca> zyga: ï¼­ï¼¡ï¼§ï¼©ï¼£
<zyga> let's see if I'm more unlucky today
<mvo> zyga: fwiw, I ran http://paste.ubuntu.com/p/FqXw8pMSVV/ but get tons of errors after the lxd test, it changes the module/sysctl state quite a bit
<mvo> zyga: anyway, running 2.36 now to see what is going on there
<zyga> mvo: I'm also looking at 2.36 now
<zyga> we can chat after that one is fixed
<pedronis> mborzecki: hi, so far the loop devices mount bug, if we have a reproducer and are waiting for answers from upstream? is that right?
<pedronis> s/far/for/
<pedronis> s/if//
<Chipaca> pedronis: https://github.com/systemd/systemd/issues/10872
<pedronis> Chipaca: thx
<pedronis> it actually was also in the card
<zyga> 2.36 tests running... so far green :(
<mborzecki> pedronis: yup, in the card too
<pedronis> mborzecki: saw that now, moved/updated the card to reflect status, thank you
<mup> PR snapd#6196 closed: many: validate title <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6196>
<zyga> mvo: any luck with 2.36? can you trigger it?
<Chipaca> mborzecki: I think #6183 is gtg (github only counts one of its +1s but it does have two)
<mup> PR #6183: sanity, spread, tests: add CentOS (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6183>
<Chipaca> (as of just now)
<mvo> zyga: I just got a failure this second
<zyga> how did you run spread?
<mvo> Disable one alias for aliases snap
<mvo> error: pattern not found, got:\nRemoved:
<mvo>   - aliases.cmd2 as alias2
<mvo> in 2018-11-26 10:57:46 Debug output for google:ubuntu-16.04-64:tests/main/parallel-install-aliases :
<zyga> hmmm
<mborzecki> Chipaca: i was waiting for #6189 but no luck so far
<mup> PR #6189: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6189>
<mvo> zyga: looks very unrelated .(
<zyga> that's not the issue that was een
<zyga> yep
<zyga> another random fluke
<mvo> zyga: spread -v -debug google:ubnuntu-16.04-64
<Chipaca> mborzecki: ah drat
<zyga> thanks
<zyga> same here :/
<zyga> I'll get a coffee
<mborzecki> Chipaca: that way Neal would be able to rebuild the package on his end
<mvo> zyga: https://paste.ubuntu.com/p/FYqWkFmVbN/ <- looks also wrong at least at first glance
<zyga> mvo: looks like stdout vs stderr
<zyga> though
<zyga> not sure
<zyga> it looks like IO intertwined
<zyga> no idea
<mvo> zyga: yeah, I have not seen this I poke a bit more
<mborzecki> wonder why auditd is not started in our fedora images on gcp, while the cloud image starts it by default
<zyga> mvo: got it!
<zyga> :D
<zyga> https://www.irccloud.com/pastebin/jiEYTg2z/
<mvo> zyga: nice
<zyga> Nov 26 10:02:44 nov260941-894159 audit[24801]: AVC apparmor="DENIED" operation="mkdir" profile="/snap/core/6013/usr/lib/snapd/snap-confine" name="/tmp/snapd.quirks_wlXkFF/" pid=24801 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<zyga> google:ubuntu-16.04-64 /var/lib/snapd/apparmor/profiles# pastebinit snap-confine.core.6013
<zyga> http://paste.ubuntu.com/p/xKvYgnBR2n/
<mvo> zyga: oh, we removed the quirks profile generation but not in 2.36
<zyga> yes
<zyga> but we knew that
<zyga> I said that last week when first reports came in
<zyga> the question is why the profile is not matching 2.36
<zyga> mvo: the kernel profile != disk profile
<mvo> zyga: yeah, exactly, why is there a mismatch
<zyga> disk profile is correct
<zyga> another cache bug?
<mvo> zyga: uhhh
<zyga> I'll get that coffee first
<mvo> zyga: that sounds likely, oh boy
<zyga> mvo: the measure state dumper I wrote can measure that too :)
<zyga> brb
<mvo> zyga: maybe we should enable that then instead of the kernel one first
<mvo> zyga: can you get the timestamps of the kernel profile and the disk profile?
<zyga> mvo: looking
<zyga> kernel profile has no timestamp, looking at what is in the cache
<zyga> http://paste.ubuntu.com/p/bjDm3gxXTz/
<zyga> that is /var/cache/apparmor/
<zyga> a bit odd
<zyga> I have a hunch now, hold on
<zyga> mvo: it's super interesting that we do skipReadCache
<zyga> so
<zyga> if we had actually got to the phase where snap-confine profile is loaded we would pass an argument to apparmor parser that instructs it to skip any cache reads
<zyga> ah
<zyga> sorr
<zyga> ha
<zyga> I see the bug now
<zyga> one liner fix coming up
<mvo> zyga: cool
<mvo> zyga: curious to see what it is/was
<pedronis> mvo: I put some comments in #6185
<mup> PR #6185: snap: add new `snap run --trace-exec` call <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6185>
<pedronis> Chipaca: we are getting failures of the funcarg completion tests with timeouts
<Chipaca> pedronis: yes
<pedronis> Chipaca: see for example https://api.travis-ci.org/v3/job/458809746/log.txt
<pedronis> Chipaca: any idea what is happening?
<zyga> mvo: 2nd depth to the problem
<Chipaca> pedronis: no
<zyga> mvo: it's not cache
 * pstolowski is having network outage
<zyga> Nov 26 10:02:33 nov260941-894159 snapd[24445]: backend.go:312: cannot create host snap-confine apparmor configuration: cannot reload snap-confine apparmor profile: cannot load a
<zyga> pparmor profiles: signal: terminated
<pedronis> Chipaca: can you investigate when you have a bit of time?
<Chipaca> pedronis: yes
<Chipaca> pedronis: on it already
<pedronis> thx
<Chipaca> pedronis: I wish I'd get something as clean as that logfile though
<Chipaca> :-)
<pedronis> Chipaca: that zyga branch seems to be failing with that error or many of it
<pedronis> all the time
<Chipaca> ok, i'll try on that, thanks
<zyga> mvo: so I though it was missing skipReadCache
<zyga> mvo: but that's not it
<zyga> the cache timestamp and profile timestamp warrant a cache skip
<zyga> but apparmor parser was killed
<zyga> and snapd ignores the error
<zyga> why it gets killed is unclear yet, looking
<zyga> mvo: I made the error fatal
<zyga> but no clue as to what triggers it yet
<zyga> more debugging in progress
<zyga> another random failure:
<zyga> panic in unit tests https://www.irccloud.com/pastebin/BaMV9MrJ/
<pedronis> that's definitely a bug or test flakiness, first time I see it tough
<mborzecki> hmm, core snap pulled from the store does not have selinux labels in xattrs, but the tests repack the core snap and it picks up user_home_t in the process :/
<mvo> zyga: thanks, sorry, had a meeting reading backlog
<zyga> k
<zyga> backlog?
<mvo> mborzecki: do we need to append -no-xattr to our mksquashfs when we repack?
<mborzecki> mvo: iirc s-c was supposed to not use +s bur rely on xattr caps, not sure if that's true for the core snap now
<Chipaca> mvo: you need to not append it for non-app snaps
<Chipaca> (snap pack dtrt)
<pedronis> mborzecki: yes, I remember was conversations around that
<pedronis> not sure what was the outcome
<Chipaca> https://github.com/snapcore/snapd/blob/master/snap/squashfs/squashfs.go#L325 fwiw
<mvo> zyga: backscroll :) so it seems the issue is not entirely clear yet?
<mborzecki> Chipaca: yup, that's the line
<zyga> mvo: the origin is not, the mechanics are
<zyga> mvo: we ignore the error from compiling the apparmor profile of snap-confine
<mvo> zyga: uh, ok
<zyga> the error is that apparmor_parser is killed with a signal
<mvo> zyga: thanks, that sounds like a bug in itself
<pstolowski> zyga: i'll take a look at that panic
<zyga> mvo: the reason for the signal is unclear
<Chipaca> WAT
<zyga> I made the error not ignored
<mvo> zyga: right, so no error output just a signal?
<mvo> zyga: is the error reproducible?
<pedronis> pstolowski: btw do ping me if there is something ready for me to review/re-review
<Chipaca> https://imgur.com/ndV0USM
<zyga> mvo: we collect output but there is none
<zyga> mvo: ran it again and it passed
<zyga> running it again until I hit the bug
<pstolowski> pedronis: #6114 is ready; travis failure unrelated
<mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<Chipaca> sergiusens: ping
<Chipaca> or was today a holiday in .ar
<mvo> zyga: thank you!
<zyga> mvo: one more observation from running measure.sh, we never remove any apparmor profiles
<zyga> mvo: (running two loops)
<zyga> as in, from the kernel
<zyga> they stay there forever
<pedronis> pstolowski: ok, thx, I'll look at it after lunch
<mvo> zyga: aha, interessting, that sounds like a bug too
<zyga> yes, fixed locally now
<mup> PR snapd#6213 opened: interfaces: let NM access ifindex/ifupdown files <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6213>
<zyga> got the panic again
<zyga> ... Panic: change 1 unexpectedly became unready (Do) (PC=0x45ECEE)
<zyga> carrying on with debugging
<pstolowski> zyga: running these tests in a loop, no panic (yet)
<zyga> pstolowski: FYI, this is on 2.36 release branch
<zyga> maybe fixed since
<zyga> not sure
<pstolowski> zyga: i doubt it, we haven't touched this area afaik
<zyga> pstolowski: if you want to try spread it was google:ubuntu-16.04-64:tests/unit/go
<pstolowski> zyga: thanks, will try (running net on my mobile atm, my isp is down)
<zyga> try with -repeat or -count (forgot which one is real)
<pstolowski> zyga: ok
<zyga> mvo: reproduced again
<zyga> let me inspect snapd
<zyga> mvo: same Nov 26 11:27:30 nov261108-796129 snapd[9598]: helpers.go:187: cannot regenerate apparmor profile for snap "core": cannot create host snap-confine apparmor configuration: cannot
<zyga> reload snap-confine apparmor profile: cannot load apparmor profiles: signal: terminated
<zyga> Nov 26 11:27:30 nov261108-796129 snapd[9598]: apparmor_parser output:
<pstolowski> zyga: i suspect task runner doesn't like the fact that we manually mess with task status in the test, and if i read change.go code correctly, it doesn't like that task status became out of sync with change status (a race provoked by SetStaus in the test?). we might have been lucky not to hit this earlier
<zyga> (nothing, no output0
<zyga> mvo: I can load and compile the profile manually
<zyga> then things work
<zyga> mvo: my patch made us return an error but it just got logged still, something is also wrong
<zyga> none of the changes recorded the error
<zyga> mvo: again, we ignore setup errors in ifacestate
<mvo> zyga: ok
<zyga> fixed that too, trying again
<mvo> zyga: thanks!
<zyga> still no insight into what kills that process
<zyga> my patch so far
<zyga> http://paste.ubuntu.com/p/B688VzKY6S/
<zyga> mvo: hopefully with this run I will pinpoint the moment this breaks, maybe that will suggest something
<mvo> zyga: ta
<mvo> zyga: and fingers crossed that this yields some results
<mvo> Chipaca: I get some :funcargs errors currently too, should we disable this test until this clearer what  is going on or are you already close to a fix?
<Chipaca> mvo: I can't yet see why it's failing
 * zyga is happy to see people attacking test issues
<mup> PR snapd#6214 opened: spread.yaml: disable _/funcarg test for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6214>
<zyga> pstolowski: I get the panic each time, wonder what upsets the timing now
<pstolowski> zyga: haven't seen it yet. i see "main.go:158: Exiting on %!s(<nil>) signal." though, is that what you discussed above?
<zyga> pstolowski: can you provide more logs please?
<zyga> pstolowski: that's not the error I'm seeing though
<zyga> but that is what Chipaca found last week
<zyga> broken daemon shutdown
<zyga> we should cherry pick the fix into stable
<zyga> probably is proposed and cannot land
<Chipaca> zyga: I closed that PR because it never got green
<zyga> but I did not chcek
<zyga> *check
<zyga> heh :-)
<Chipaca> restarted the tests all weekend :-(
<Chipaca> but I'll open a new one with just that bit
<Chipaca> or you can
<Chipaca> :-)
<zyga> Chipaca: my hands hurt after hitting restart for the billionth time
<Chipaca> you monster
<Chipaca> :-)
<pstolowski> zyga: i don't think i can have more logs atm, running it on spread
<zyga> k
<zyga> mvo: when we restore in spread we are unpacking the tarball
<zyga> so we are putting apparmor profiles on disk
<pstolowski> https://www.irccloud.com/pastebin/nYunJ1EE/
<zyga> mvo: when we do that we may confuse the code that looks at the profiles to see what to do
<pstolowski> zyga: ^
<zyga> pstolowski: if anything the log message needs improvements
<zyga> mvo: we only restore the disk profiles, not the kernel state
<zyga> mvo: no more progress yet, given that I see it very infrequently we may attempt to restart 2.36 tests on travis
<zyga> mvo: no failure since introducing trivial changes not to ignore errros
<sergiusens> Chipaca: pong?
<pstolowski> mvo, pedronis interesting failure - i've just tried to test something on an old VM which was stuck on 2.25: https://pastebin.ubuntu.com/p/Rg4CTMrGDr
<sergiusens> with no context ð
<sergiusens> holiday was last week
<sergiusens> today is only a major strike day ð
<pedronis> pstolowski: interesting
<pedronis> pstolowski: does installing hello-world works?
<pedronis> Chipaca: I reviewed #6104
<zyga> pstolowski: report the bug or we'll forget soon
<mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<pstolowski> pedronis: yep, and afterwards it's all fine as expected
<pstolowski> zyga: good point, doing
<pedronis> ok
<pedronis> pstolowski: it's a store bug btw, we cannot really change old versions
<pedronis> mvo: could you review #6126 ?
<mup> PR #6126: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>
<pedronis> Chipaca: I added some questions in #6034
<mup> PR #6034: many: save media info when installing, show it when listing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<pstolowski> pedronis: reported https://bugs.launchpad.net/snapstore/+bug/1805140
<mup> Bug #1805140: 'snap find' on old version of snapd 2.25 produces error about base <Snap Store:New> <https://launchpad.net/bugs/1805140>
<pedronis> pstolowski: thx
<mup> PR snapd#6215 opened: tests: reset the snapd package to make the first test on the suite work properly <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6215>
<pedronis> cachio: hi, what's the status of #5174 ?
<mup> PR #5174: interfaces/default,process-control: miscellaneous signal policy fixes <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5174>
<pedronis> gah, sorry
<pedronis> cachio: I meant, #5714
<mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<mvo> pedronis: sure, I have a look now
<zyga> cachio: so 6215 should the reset instead go to per-suite restore function?
<mvo> zyga: hm, hm, no errors still?
<cachio> pedronis, it was failing but not because of the test
<mvo> pstolowski: looking
<cachio> pedronis, I was waiting a fix for that, I'll update it and see the current status
<pedronis> cachio: ok, it has a conflict now, thx
<zyga> mvo: apart from the panic, no
<zyga> mvo: I reproduced it twice in total today
<zyga> "luck'
<cachio> zyga, the problem is happening on the first completions test after run other test suite
<cachio> zyga, because before we were calling the reset
<zyga> cachio: and why should this not run in per-suite restore?
<cachio> I zyga we need to split it and reorganize it a bit more so we dont need to do it at suite level
<cachio> just on test level
<zyga> not sure I follow
<cachio> now I am trying to define the initial/end state at suite level, and test level
<cachio> because we have a mix of things currently
<cachio> zyga, conceptually, we should define a state for the whole environment when we run any suite
<cachio> and a different one for the tests
<zyga> mhm
<zyga> yeah, I agree about that 100%
<cachio> so then we make sure each suite and test leaves the same env on the restore
<zyga> right
<zyga> so what is wrong now?
<cachio> but currently it is not happening 100%
<zyga> what is the state we want to have at suite level
<zyga> and at test level
<cachio> now the first test in the suite is not getting the same env than the rest
<pedronis> what changed?
<zyga> I suspect https://github.com/snapcore/snapd/pull/6202/commits/8b174e8daec7b21f3091a0e99fb79467f56625ab
<mup> PR #6202: tests: restore in restore, not in prepare <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6202>
<cachio> yes
<zyga> cachio: can you be specifc, do you know what is actually not the same now
<cachio> when we moved the reset to the restore
<pedronis> well, sounds like that needs reverting until we understand more
<pedronis> for sure I'm seeing bizarre errors I have never seen
<pedronis> before
<cachio> the snapd state is restored on the reset
<pedronis> yes
<cachio> so
<cachio> when we run the first test suite
<cachio> the first test runs with the initial state with is ok
<cachio> and as any test is calling the reset in its restore
<cachio> all the tests receive the correct snapd state
<pedronis> yes
<pedronis> then next suite?
<cachio> then when the suite calls its restore
<cachio> it cleans snapd
<cachio> then next suite is called
<cachio> but the first test receives a different state
<cachio> because the reset is not called
<zyga> but ... ?
<zyga> suite-a/restore => calls reset
<zyga> suite-b/prepare => ...
<pedronis> anyway I'm not sure why this is better than the old approach
<zyga> suite-b?/test => runs in what was left by reset.sh
<pedronis> even if the old approach was called confusing :)
<cachio> zyga, suite-a/restore => is uninstalling snapd
<Chipaca> I personally like the tests that do "snap try" in prepare, and "rm -rf underlying/dir" on restore
<cachio> after the reset
<pedronis> Chipaca: without remove ?
<Chipaca> mhmm
<cachio> zyga, so there we clean the state again
<Chipaca> I don't know if snapd copes well enough with that to be in a sane state :-)
<zyga> cachio: my point is that now each suite restore calls reset.sh, the change you are proposing is making the prepare.sh run the same thing
<zyga> seems like a no-op
<zyga> there must be a part missing
<cachio> zyga, the change I did it is just a workaroud to fix the tests
<pedronis> zyga: there is a prepare in suite
<pedronis> between that restore
<pedronis> and the suite
<pedronis> in the old world
<zyga> yes, I know
<zyga> but that is all calling reset.sh
<zyga> so?
<zyga> we used to call it in prepare.sh
<zyga> er
<pedronis> yes,
<zyga> sorry, we used to call it in suite prepare
<pedronis> simpler I think
<pedronis> if confusing
<zyga> after suite prepre we run tasks, then suite restore
<cachio> zyga, I think we need to reorganize a bit the prepare/restore at test suite level
<zyga> I bet this will work
<zyga> because we essentially revert that patch
<zyga> but I think we don't understand why exactly (or perhaps just me)
<pedronis> cachio: zyga: it's all good but given the state of things I would prefer we get back to a state that was known to work a bit more
<zyga> because the sequence of calls to reset.sh seems to be the same
<pedronis> before reorganizing again
<cachio> zyga, the workaroud which I proposed is to run the reset at the begining of the test suite
<pedronis> basically first revert https://github.com/snapcore/snapd/pull/6202
<mup> PR #6202: tests: restore in restore, not in prepare <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6202>
<cachio> not for each test
<zyga> cachio: I'd love to understand this better when time is not ticking
<cachio> zyga, we have standup in 15 mins :)
<zyga> oh, I need to take the dog out then
<zyga> ttyl
<cachio> zyga, let see that there
<zyga> cachio: I would rather understand the details of what is wrong
<zyga> revert the thing I pushed that broke master
<zyga> and later on fix master so that we can clearly agree that the prepare/restore logic is ok
<pedronis> yes, that's my preferred approach
<pedronis> as well
<mup> PR snapcraft#2411 closed: cli: snapcraft init with a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2411>
<mup> PR snapcraft#2412 closed: schema: add support for title <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2412>
<zyga> with perhaps revert even before the understand :)
<pedronis> yes
<zyga> sorry for breaking master for everyone
<zyga> mvo: I will try with seed, still 0 reproducted cases
<pedronis> cachio: can you prepare a revert of #6202 ?
<mup> PR #6202: tests: restore in restore, not in prepare <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6202>
<zyga> pedronis, cachio: perhaps just https://github.com/snapcore/snapd/pull/6202/commits/8b174e8daec7b21f3091a0e99fb79467f56625ab
<zyga> the rest is not related
<Chipaca> is the standup via hangouts still?
<zyga> why?
<zyga> are they broken for you?
<Chipaca> zyga: weren't you unable to use it?
<zyga> (asking for a friend :)
<Chipaca> no, my browser works
<Chipaca> :-)
<zyga> yes, same thing today
<zyga> chrome
<zyga> video starts, then ... nothing
<zyga> meet worked
<zyga> I can do standup from phone
<mvo> pedronis: thanks for your review on 6185 - do you want me to move some code to osutil/strace there ? or would you prefer to do that in a followup?
<cachio> zyga, pedronis sure
<pedronis> mvo: I think there, as I also said the code seems right but probably some better naming of thing/comment would help explaining but is doing
<pedronis> s/but is/what is/
<mvo> pedronis: sure, happy to do that. thank yoU!
<pedronis> there are probably also some assumptions around how exec are expected to happen
<pedronis> that maybe need to be explicit
<mvo> pedronis: I will move code around and use the opportunity to clean naming a bit more, I agree its not ideal
 * mvo nods
<pedronis> thank you
<pedronis> cachio: zyga: I made a note in 6125 about this
<mup> PR snapd#6216 opened: tests: revert "tests: restore in restore, not prepare" <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6216>
<geodb27> People : hi !
<geodb27> I suspect a problem on my kubuntu18.04 laptop with the "service" named "run-snapd-ns-lxd.mnt.mount" what are the common log-files or log-programs that can help diagnose a problem (or not) for snaps ?
<zyga> geodb27: hey
<zyga> in a call, please hold
<zyga> that is not a service as you noticed
<zyga> geodb27: can you tell me what the problems are
<zyga> that file is a mount namespace
<zyga> belonging to the lxd snap
<geodb27> of course I can zyga, thanks a lot for your help.
<geodb27> What I suspect is the following : my system boots, the /tmp is mounted. But, at one point, the snap lxd service is started and somehow bind-mounts something *OVER* the /tmp.
<zyga> over the /tmp on the host?
<geodb27> yep.
<zyga> geodb27: can you you please run cat /proc/self/mountinfo on the host where lxd is running
<geodb27> http://dpaste.com/0H48WSH here it is
<zyga> geodb27: according to that log there is nothing mounted over /tmp
<zyga> geodb27: perhaps you meant that something is in /tmp inside the containers started by lxd?
<geodb27> You will get some more infos here https://github.com/lxc/lxd/issues/5171 since I've already discussed this issue here.
<zyga> geodb27: so can we get back to the problem, how is that file a problem?
<geodb27> The output I gave you is the one I got after having run "systemctl stop run-snapd-ns-lxd.mnt.mount"
<zyga> sorry, I still don't understand, when you inspected mountinfo, was the system affected by this issue?
<geodb27> Well, here is what I've observed on my machine and the conclusions I came to : when my machine boots, the sddm service is broken (I can enter my password, but the "connexion" button does nothing). To access my desktop, I must go on a virtual console, log-in as root and issue systemctl restart sddm.
<geodb27> That's one point. And I came to suspect that the run-snapd-ns-lxd.mnt.mount was the problem. I suspect it to remount the /tmp after the sddm service is started, so that sddm loses it's tmp files).
<zyga> why do you suspect that?
<zyga> the .mnt file is not a service
<zyga> it's a virtual unit created by systemd
<zyga> for every entry in the mount table
<zyga> you will see one
<zyga> it is a specific mount namespace used by all the processes of the lxd snap
<zyga> it cannot execute code so it cannot mount or otherwise over /tmp
<geodb27> Indeed, that's what I've observed. However, when I issue systemctl stop run-snapd-ns-lxd.mnt.mount the content of the /tmp folder is altered.
<zyga> how?
<zyga> can you show me mountinfo *before* that stop and *after* that stop
<zyga> I suspect that what happens is that stop on that unit affects other units
<zyga> that also stop
<zyga> but that's not the unit per se, just something related to it
<geodb27> I can do that. Give me the time to do so :-)
<zyga> sure, thank you
<geodb27> I'll have to reboot my machine. I'll be back when it is done. Thanks a lot for your help.
<zyga> sure
<craigulliott> Good morning everyone. Is there an appropriate channel where I can ask about manual review for a snap we have created. I believe it failed automatic review because it uses an X11 plug and slot (message said due to 'deny-connection' constraint for 'on-classic' from base declaration).
<mup> PR snapd#6215 closed: tests: reset the snapd package to make the first test on the suite work properly <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6215>
<niemeyer> Weird..
<niemeyer> Server is not responding.. is it just me?
<zyga> niemeyer: seems so
<niemeyer> Back.. the tubes are broken
<geodb27> back again. Sorry for the time it took me zyga. Here are all the facts I've collected from boot : http://dpaste.com/2CFWT2S
<zyga> geodb27: thanks
<roadmr> craigulliott: you can ask in https://forum.snapcraft.io/c/store but you don't need to; the manual review queue is checked periodically by reviewers
<zyga> geodb27: that's not quite what I asked for,  I wanted to see the mount table alone (cat /proc/self/mountinfo) across the stop of that mount unit
<craigulliott> @roadman Great, thank you! Do you know how long it usually takes? I'm not looking to expedite, just to plan according.
<zyga> geodb27: one thing is sure, there's nothing mounted over /tmp in your log
<craigulliott> @roadmr Great, thank you! Do you know how long it usually takes? I'm not looking to expedite, just to plan according.
<zyga> geodb27: let me read it in detail though, maybe something interesting shows up
<roadmr> craigulliott: there's no "standard of service" unfortunately :/ depends on the reviewers' workload really.
<zyga> stgraber: hello
<zyga> stgraber: one question
<zyga> stgraber: does this mount entry look normal to you?
<zyga> 860 844 0:3 mnt:[4026532713] /var/snap/lxd/common/ns/shmounts rw - nsfs nsfs rw
<zyga> that's a mount namespace over shmounts
<zyga> is that something that lxd does?
<craigulliott> roadmr: thanks!
<geodb27> The last command I launched is indeed the systemctl stop run-snapd-ns-lxd.mnt.mount. I provided all this to show that before this command, the lxc profile edit throws an error related to /tmp, while after it runs fine. So, to me, there definetly is a problem related to this virtual service.
<pedronis> zyga: can you check whether #6216 does what you expected from the revert?
<pedronis> otherwise it can land I think, it's green
<mup> PR #6216: tests: revert "tests: restore in restore, not prepare" <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6216>
<stgraber> zyga: yeah, that's normal, it's the logic we have to be able to keep our mounts across snap mntns changes (when core gets refreshed)
<geodb27> Hi stgraber :-)
<stgraber> zyga: on first startup we create a separate mount namespace, setup propagation both ways (rshared) with the snap-confine mntns and put a reference to it in the initial mount namespace so we can recover it even when our mntns is completely destroyed
<mvo> 6216 needs a second review
<mup> PR snapd#6214 closed: spread.yaml: disable _/funcarg test for now <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6214>
<zyga> stgraber: thank you for confirming
<zyga> pedronis: looking
<zyga> pedronis: yes, merged now
<zyga> thank you
<zyga> I'll grab quick lunch now
<pedronis> np
<zyga> mvo, pstolowski: still 100% reproducing that race in unit tests and 0% reproducing that 2.36 issue
<stgraber> geodb27: still that weird /tmp behavior? :(
<stgraber> geodb27: we had one other report of something similar so far, but that user was running tmpreaper, so that made sense and was easy enough for them to fix
<mup> PR snapd#6216 closed: tests: revert "tests: restore in restore, not prepare" <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6216>
<mvo> zyga: I'm running the branch with your diff too, but no success so far
<pstolowski> zyga: wait, i thought you were reproducing it in 2.36 release?
<geodb27> indeed, still the same very problem. Well, for now, the solution is "simple" as you can see : issue first a "systemctl stop run-snapd-ns-lxd.mnt.mount" and then "systemctl restart sddm" to have my laptop behave as expected. The fact is that I really want to understand why it is so.
<geodb27> (I'm somehow stubborn and obstinate and really want to understand) :p
<mvo> pstolowski: I get the "... Panic: change 1 unexpectedly became unready (Do) (PC=0x45ECEE)
<mvo> " panic pretty reliable here currently when running google:ubuntu-16.04-64 from upstream/release/2.36 fwiw
<pstolowski> mvo: thanks, interesting i couldn't repro locally with 2.36 (although kinda expected if it's a race)
<kyrofa> zyga, interesting feedback from a snap user: https://help.nextcloud.com/t/nextcloud-snap-users-please-list-the-issues-youre-facing/1979/152 . Does a revert after a refresh that changes a channel not revert the followed channel as well?
<mup> Bug #1805162 opened: Impossible to get newly settled props <configure> <props> <snapctl> <snapset> <validation> <Snappy:New> <https://launchpad.net/bugs/1805162>
<zyga> back now
<pedronis> pstolowski: probably speed of the hardware (virtual or not) is relevant
<zyga> geodb27: we want to understand as well :)
<geodb27> I'm sure you want :-)
<zyga> kyrofa: I think .. I don't know - perhaps not, we just revert the revision, not the tracking change operation
<geodb27> hang on, I've found something that might interest you, zyga.
<zyga> pedronis, pstolowski: I was testing on google
 * cachio lunch
<zyga> geodb27: cool
<geodb27> as @stgraber suggested and pointed out on the discussion we both had on github, look at this : http://dpaste.com/0C35VXQ and in particular line 71.
<geodb27> This is from my system, right now, so after the systemctl stop and when things work. However, this looks weird to me : the source of the mount point is indeed deleted.
<geodb27> oups, typo, line 73
<zyga> oh, nice
<zyga> 661 751 259:2 /tmp/snap.0_lxd_M9HkFH/tmp//deleted /tmp rw,relatime - ext4 /dev/nvme0n1p2 rw,errors=remount-ro,data=ordered
<geodb27> yep, that one. I've checked, there is nothing instructed to wipe /tmp at boot time.
<zyga> this says that /tmp/snap.0_lxd_M9HkFH/tmp/ of the ext4 filesystem at device /dev/nvme0n1p2 is mounted at /tmp and that the source has been removed
<zyga> so
<zyga> as I see it
<zyga> when you boot you get /tmp from ext4 on nvme
<zyga> then lxd snap starts up and creates that lxd.mnt file you know about in /run/snapd/ns/
<zyga> that file captures the mount namespace of the lxd process
<zyga> though lxd is special because it has more permissions than most snaps, so it can do many mount changes by itself
<zyga> then something cleans up /tmp
<zyga> removing the snap.0_lxd_$random directory
<zyga> so I have an ide
<zyga> *idea
<zyga> geodb27: what is your distribution?
<geodb27> kubuntu 18.04 lts
<zyga> geodb27: at least on ubuntu there's a systemd unit that wipes /tmp
<zyga> one sec, let me check something
<geodb27> take your time... I'm not in a hurry :-)
<zyga> can you share the output of systemctl status systemd-tmpfiles-clean.service
<geodb27> Sure : here it is http://dpaste.com/2NMEPHJ
<zyga>    Active: inactive (dead) since Mon 2018-11-26 15:46:46 CET; 55min ago
<zyga> can you try to corelate that to the snap.lxd.service please?
<geodb27> http://dpaste.com/0X9RW2S I think that you got it !
<zyga>    Active: active (running) since Mon 2018-11-26 15:31:51 CET; 1h 12min ago
<zyga> so
<zyga> lxd starts before the tmpfsiles wipe job
<geodb27> But I guess that systemctl disable systemd-tmpfiles-clean.service will not be the right solution.
<zyga> when you unmount that .mnt file you get a clean slate
<zyga> but one suggestion
<zyga> next time instead of doing that
<zyga> call
<zyga> sudo /usr/lib/snapd/snap-discard-ns lxd
<zyga> this does more than that umount alone
<zyga> geodb27: no, it's started by a timer
<zyga> and it is a good idea anyway
<zyga> but this feels like a systemd bug
<zyga> it seems, unless I'm mistaken
<zyga> that it can wipe /tmp at any time
<zyga> CC: stgraber ^
<zyga> geodb27: I would appreciate if you could add this to the bug report
<geodb27> which bugreport ? The one on github I pointed to ?
<zyga> yep
<zyga> to capture that tmp is wiped with that service
<geodb27> I'll do it right now. Thanks a lot for your kind help !
<zyga> and this causes the tmp subdirectorty that is used by lxd as /tmp is gone
<zyga> thank you!
<zyga> *subdirectory
<zyga> and I'm back to debugging other things
<zyga> pstolowski: do you have any patches, even early on that I could try
<zyga> I hit that error every time I try now
<stgraber> zyga: right, so not specific to LXD at all, this would break any snap that's started on boot, LXD just happens to be a very common one of those
<zyga> stgraber: exactly
<stgraber> zyga: still odd that geodb27 is the only report we've seen of this
<geodb27> @stgraber not really... I don't think that lxd is much used on Kubuntu... on ubuntu there is no doubt at all... But on a desktop distro ?
<pstolowski> zyga: no, nothing yet
<pstolowski> zyga: will let you know as soon as i've something
<mup> Bug #1805170 opened: Extend snapd REST API to get conf props from change transaction <Snappy:New> <https://launchpad.net/bugs/1805170>
<stgraber> geodb27: sadly Kubuntu itself reports Ubuntu through lsb-release so we don't get any idea of number of users
<stgraber> geodb27: I do however see about 500 users on KDE neon 18.04, so at least those are desktop users of LXD using KDE
<geodb27> I beleive you @stgraber :-) This was just a guess. Thenafter, my machine was updated from kubuntu 16.04 to 18.04 with a do-release-upgrade. I don't say that this is what caused the problem, but it could somehow be (though I don't know how at all).
<zyga> mvo: can you reproduce the issue with 2.36 branches
<zyga> I will re-trigger them now
<zyga> I cannot reproduce the issue at all
<mvo> zyga: I have not reproduced the permission denied issue yet, I run it again, I ran it ~2 times
<mvo> zyga: or three maybe
<zyga> ok
<zyga> maybe not super critical
<zyga> if it happens once in ~10 hours
<pedronis> Chipaca: #6126 got +2  , don't know if I need to look at it as well, or if there is  still some open Q there
<mup> PR #6126: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>
<Chipaca> pedronis: ah i missed the second +1
<Chipaca> pedronis: should be gtg
<mup> PR snapd#6126 closed: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6126>
<geodb27> zyga, with your kind help and some reading, I've added a /etc/tmpfiles.d/snap.conf file with this content : x /tmp/snap* X/tmp/snap* (on two lines).
<zyga> ah
<zyga> this won't unlink those directories
<zyga> perhaps snaps should ship that?
<zyga> geodb27: is there a bug report about this on launchpad.net?
<zyga> specifically bugs.launchpad.net/snapd
<zyga> if no, can you file one, while we cannot reproduce this straight away shipping those exclusion rules in snapd seems possible
<geodb27> I'll be heading for this when I'll be 100% sure that this solves the problem, indeed !
<zyga> geodb27: thank you!
<zyga> good luck :)
<pedronis> pstolowski: I reviewed the hotplug PR that you fixed, lgtm,  I think the one I reviewed now need a pass by mvo. And as I said we should try to chat on wed about more global issues about event sequences for the same device
<pstolowski> pedronis: thanks, wed sounds good
<geodb27> zyga : https://bugs.launchpad.net/snapd/+bug/1805182 job done. Thus, I'm sure not to forget about it :-)
<mup> Bug #1805182: /tmp is sometime cleaned up after snaps are launched <snapd:New> <https://launchpad.net/bugs/1805182>
<zyga> geodb27: thank you!
<geodb27> Time to go, my day's work's over.
<geodb27> Again, thanks a lot for your kind help !
<zyga> thank you for the detailed reports!
<mvo> pedronis: I look at the hotplug PR tomorrow
<pedronis> mvo: there's a couple where I requested your review
<zyga> mvo: can you look at that bug please^
<pedronis> yes, tomorrow is fine
<zyga> mvo: just triaged it to high
<mvo> pedronis: thanks, will do those tomorrow as well
<zyga> mvo: seems that we could ship a tmpiles removal rule that would exempt removal of /tmp/snap.* directories
<zyga> mvo: all the details are in the bug
<mvo> zyga: ok, I check that tomorrow as well
<zyga> sure
<zyga> 17:49
<mvo> zyga: ?
 * zyga wonders if EODing on time is a good idea
<mvo> zyga: heh, I play hockey in some minutes
 * mvo looks forward to this
<zyga> mvo: thatt's a great thing to do :)
<zyga> enjoy!
<mvo> ta
<sacarde> hi
<sacarde> I installed vlc 3.0.4 from snap in ubuntu-18.04, but I dont find binaries: cvlc nvlc...  is right?
<pedronis> cachio: does 5714 need a 2nd master merge?
<pstolowski> zyga: puzzled by that panic, can't repro on spread either - (release/2.36*) $ spread -debug -repeat 10  google:ubuntu-16.04-64:tests/unit/go
<zyga> hmm
<zyga> wonder what I do
<zyga> anyway, let me know if you figure out the error, may be some debug log can help
<zyga> e.g. extra logging we do in that test case
<roadmr> sacarde: looks like the vlc snap does not provide those commands.
<pstolowski> zyga: can you try with this patch https://pastebin.ubuntu.com/p/sGzrRdbV6Y/ and show me the output?
<zyga> sure!
<pedronis> zyga: #6206 has a conflict now also probably needs master merge anyway
<mup> PR #6206: many: fix composite literals with unkeyed fields <Created by zyga> <https://github.com/snapcore/snapd/pull/6206>
<zyga> ta
<pstolowski> zyga: also, let me know if you run it differently; nb i believe my 2.36 is up-to-date, last commit 84e5ab2ad44511cb287a6450f5be6074563ea535
<mup> PR snapd#6199 closed: Revert "cmd/snap, tests/main/snap-info: highlight the current channel" (2.36) <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6199>
<zyga> pstolowski: I'm getting this error each time I run a snap
<zyga> warning: cannot open cookie file /var/lib/snapd/cookie/snap.sublime-text
<zyga> this particular snap that is
<zyga> pstolowski: it is classic, is this expected?
<pstolowski> zyga: no
<zyga> pstolowski: and I have some good news
<zyga> panic with debug messages https://www.irccloud.com/pastebin/HTj9vvG7/
<zyga> pstolowski: can you reproduce that quickly with sublime-text?
<pstolowski> zyga: oh, re panic, we're not mocking something?
<zyga> popey: well, we always paniced
<zyga> ... Panic: change 1 unexpectedly became unready (Do) (PC=0x45ECEE)
<zyga> *panicked
<pstolowski> zyga: sublime installed fine, cookie created, no error when run
<zyga> hmm
<zyga> odd
 * zyga wonders
<pstolowski> zyga: did you mess up with state or anything else could get out of sync?
<zyga> ha
<zyga> that's fun
<zyga> I don't have sublime-text installed
<zyga> something is veeery broken on that system
<zyga> no worries, thanks for checking
<zyga> https://www.irccloud.com/pastebin/uHJV0NSj/
<zyga> ^ this runs sublime-text from classic package
<zyga> fun, eh?
<zyga> stray alias entry can run any command on host
<pstolowski> hmm
 * Chipaca wanders off
<pstolowski> zyga: i wonder if we shouldn't mock snap-confine wrt to that setup-profiles error in the test? still, wondering why i don't see it
<zyga> pstolowski: I'm happy to try more patches tomorrow, I'm wrapping up now
<zyga> and working on something else still
<zyga> sorry if I'm not more helpful
<pstolowski> zyga: yeah, me too
<pstolowski> zyga: you helped a lot, thanks!
 * cachio afk
<sacarde> roadmr, who build package vlc(snap or deb), ubuntu or snap ?
<mup> PR snapd#6206 closed: many: fix composite literals with unkeyed fields <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6206>
<roadmr> jdstrand: are you around?
<roadmr> sacarde: the vlc developers are responsible for maintaining that snap
<roadmr> sacarde: you can find contact and support info here https://snapcraft.io/vlc
<sacarde> roadmr, in #videolan reply to my question, that command are alias from vlc command
<sacarde> thank you
<roadmr> sacarde: glad you got it sorted out :) cheer
<sacarde> thanks
<ijohnson> roadmr: jdstrand is out today and tomorrow
<roadmr> thanks ijohnson ! I'll poke him on Wednesday then
#snappy 2018-11-27
<mup> PR snapd#6217 opened: tests: reset snapd state on tests restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6217>
<mup> Bug #1753760 changed: Adding public RSA Key doesn't make login on device possible <Snappy:Expired> <https://launchpad.net/bugs/1753760>
<zyga> o/
<geodb27> People : hi !
<zyga> hello
<zyga> brb, need to take the dog out
<pstolowski> mornings
<pstolowski> back to yesterday's test panic issue, the debug log from zyga shed some light on it
<mvo> pstolowski: good morning and good luck wit hthat
<zyga> Hey PaweÅ, Michael
<zyga> mvo: Iâm off the 2.36 bug
<zyga> No progress made
<zyga> Need to finish my stuff now
<mvo> zyga: ok
<pstolowski> zyga: may i ask you to try one more patch>
<pstolowski> ?
<zyga> Sure
<pstolowski> zyga: https://pastebin.ubuntu.com/p/Kgs7tXTfRH/
<mvo> pedronis: re 6195 - shall we (after this got a second review) merge and do 2.36.2 and then look for a better place for this than link_snap.go? or would you rather like to look for this place now before it goes to master?
<mup> PR snapd#6218 opened:  snapstate: update fontconfig caches on install (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6218>
<pstolowski> zyga: actually that patch won't help; i'll have another one soon
<pstolowski> i wish i understand what the delta is between our setups and why it doesn't fail for me on travis, pretty weird
<zyga> pstolowski: re, sorry, had a delay and network woes
<zyga> pstolowski: yeah
<zyga> pstolowski: if you want I can give you ssh access
<zyga> not sure if that would help
<zyga> to my box
<zyga> where this happens
<zyga> I can work on another
<pstolowski> zyga: yeah, that could help, thanks. also question, did we change anything related to finding if apparmor should be enabled or not recenlty? it looks like setup-profiles in this test now wants to read vanilla snap-confine profile of core; this happens if we find that release.AppApparmorLevel != NoApparmor. we're not mocking vanilla profile in the mock core snap obviously
<pstolowski> mvo: you might know as well^
<zyga> pstolowski: not sure when is recently
<zyga> when apparmor is not entirely disabled we operate
<zyga> including making a special profile for snap-confine itself
<zyga> if you think mocking is missing by all means, add some
<pstolowski> yep. it's just curious it's not happening consistently
<Chipaca> moin moin
<zyga> hey Chipaca
<Chipaca> have you seen https://forum.snapcraft.io/t/disable-enable-not-longer-working-when-snap-have-gpio-pins-as-connect/6473 ?
<zyga> oh noes
<zyga> well
<zyga> this is a bug we fixed
<Chipaca> zyga: "withthe edge channel" of core presumably?
<zyga> yes
<pstolowski> morning Chipaca
<zyga> Chipaca: your questions got me curious
<zyga> so I did some more experiments on https://github.com/snapcore/snapd/pull/6147
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> and I believe we understand why additional permissions are required
<zyga> my only question now
<zyga> should I split the permissions so that snap-update-ns is called with the existing profile transition
<zyga> and the only permission we have remains "r"
<zyga> adding a new block for snap-discard-ns which runs with the same profile
<zyga> or is the patch as-is good enough?
<Chipaca> zyga: WWJ(S)D?
<zyga> split it
<Chipaca> :-)
<zyga> for maximum confinement
<zyga> I'll do that
<zyga> btw, love the acronym :D
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6147 is ready now
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> eh
<zyga> https://gitlab.gnome.org/GNOME/gnome-control-center/issues/230#note_373259
<mup> PR snapd#6219 opened: overlord/tests: [WIP] fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6147
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> Chipaca: thank you!
<zyga> I also need a 2nd review on https://github.com/snapcore/snapd/pull/6159
<mup> PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
<pstolowski> zyga: +1 with one question
<mup> PR snapd#6159 closed: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6159>
<zyga> answered
<zyga> thanks! :)
<zyga> mvo: what's the 2.36 weather like?
<mvo> zyga: medium, still see failures but can't reproduce them
<zyga> mvo: magic
<zyga> mvo: pstolowski is working on a fix for the panic I can reproduce trivially
<zyga> I'll just run tests for his incremental patches
<pstolowski> zyga:you can try https://github.com/snapcore/snapd/pull/6219
<mup> PR #6219: overlord/tests: [WIP] fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<zyga> sure thing
<pstolowski> zyga: btw, it's green, does it mean anything?
<zyga> test in progress
<pstolowski> cause i can't repro here, pretty annoying
<mvo> pstolowski: I can try to run this after my current run, I had some luck reproducing the panic
<pstolowski> mvo: thanks. i tried running it with spread -debug -repeat 10 google:ubuntu-16.04-64:tests/unit/go
<pedronis> mvo: I hopefully answered in the PR
<mvo> pedronis: ta
<pedronis> np
 * pedronis goes back to swap daying
<mvo> pstolowski: I am running it now again, lets see
<zyga> Brb, coffee or something warm
<mvo> pstolowski: https://paste.ubuntu.com/p/9rj8ydFg5p/ <- I cherry picked  1c5b166643a5623b0a534fd1a8acb7d03d50d856 from 6219 earlier
<pstolowski> mvo: aha, interesting, let me mock core rev 1 as well
<mvo> pstolowski: shall I run it again?
<mvo> pstolowski: I mean, after you upated the pr?
<pstolowski> mvo: i've just pushed a change
<pstolowski> mvo: thanks!
<cachio> pedronis, I am working again with the #5714
<mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
<mvo> 6195 needs a second review
<zyga> mvo: I reproduced 2.36 bug again
<zyga> pstolowski: no panic yet
<pstolowski> zyga: are you running with the update i pushed  a few minutes ago ^ ?
<zyga> pstolowski: no, the one from earlier today
<zyga> mock vanilla profile for snap-confine
<zyga> mvo: same thing, apparmor parser killed by signal
<pstolowski> zyga: ok; yeah, i think one more revision of core in the tests needs it too, i added it
<zyga> ok
<mvo> zyga: anything interessting why its killed?
<zyga> mvo: I cannot find any information about why
<mvo> zyga: or what signal? sigter
<zyga> hits appreciated
<mvo> zyga: meh :(
<zyga> I suspect sigterm because it says "terminated"
<zyga> ah
<zyga> something interesting
<zyga> mvo: look at this
<zyga> lots of terminated errors https://www.irccloud.com/pastebin/FVHUi8t8/
<zyga> I thought it is just one time
<zyga> mvo: it's not just once
<zyga> it seems to happen all the time
<zyga> snap changes https://www.irccloud.com/pastebin/2UoYFGwX/
<zyga> *hmm*
<zyga> mvo: note that this branch doesn't have the tweak I used before
<zyga> so the error was not fatal
<zyga> I was testing pawel's patches
<zyga> I will record the seed and continue unless anyone has some better idea
<zyga> ok, seed is -seed=1543315161
<zyga> I will pull more of pawel's patches
<zyga> as well as my stashed error handling
<zyga> and let's see
<mvo> zyga: thank you
<mvo> zyga: I run it also with your diff to make the error fatal
<mvo> zyga: but so far no luck in reproducing
<zyga> restarted
<zyga> back to working on feature
<Chipaca> what's holding back snapd on debian?
<zyga> Chipaca: AFAIK there's a test failure that happens there
<zyga> but no investigated
<Chipaca> I mean packaging-wise
<Chipaca> it's on 2.30
<Chipaca> and no reexec
<zyga> I believe you are wrong, there is reexec
<Chipaca> hmm
<zyga> as for the package, nobody released updates
<Chipaca> I wonder if deepin mangles os-release or sth, then
 * Chipaca installs deepin
<zyga> note that we have a blacklist, not a whitelist
<Chipaca> no we don't
<Chipaca> I mean
<Chipaca> 	if !release.DistroLike("debian", "ubuntu") {
<Chipaca> that's a whitelist, even if it has a "not" in front of it
<zyga> oh
<zyga> indeed
<zyga> that's new to me
<Chipaca> zyga: reading a bit of above, "terminated" is the %s of signal 15
<zyga> aha
<zyga> sigkill
<zyga> that's odd
<zyga> wonder why we do that
<Chipaca> zyga: /usr/share/go-1.6/src/syscall/zerrors_linux_amd64.go
<zyga> (not really us probably)
<zyga> ze errorz zey keep koming!
<Chipaca> I think it's just shorthand for "zee autogeneraed files"
<Chipaca> zyga: 15 is TERM, so what else would you call it?
<zyga> ah, sorry
<zyga> 9 is kill
<Chipaca> :-)
<zyga> I did make tea, not coffee
<zyga> so terminated
<Chipaca> and 9 would say "killed"
<zyga> maybe test setup?
<zyga> there is one silly way to fix it :)
<zyga> we could wrap aa-parser with an apparmor profile
<zyga> that rejects SIGTERM :D
<zyga> (I'm half serious)
<zyga> might help us to pinpoint the sender
<zyga> because we would get a denial
 * pstolowski lunch
<zyga> is maciej around today?
<zyga> ah, he called in sick
<zyga> ok
<Chipaca> https://forum.snapcraft.io/t/cannot-run-any-program-trace-breakpoint-triggered-errors/8707?u=chipaca if anybody has clues about apparently x11 being broken on deepin
 * zyga thinks
<zyga> I know
<Chipaca> zyga: i'm going to get lunch, but i'll read when i return
<zyga> ls /tmp/.X11-unix
<zyga> on ubuntu we use abstract socket to talk to x
<zyga> on some systems we don't
<zyga> without special support we won't have x socket
<Wimpress> If snap A connects to snap B via a content interface, can snap A execute binaries within snap B?
<zyga> Wimpress: yes, but must use the internal interface, not via "snap run ..." or /snap/bin/..."
<zyga> and said binaries run with confinement of snap A
<Wimpress> snap A is confined.
<Wimpress> snap B might be classic ;-)
<zyga> by internal interface I mean by knowing how to execute the binary directly from where the content sharing is establieshed
<zyga> Wimpress: content sharing shares bits and bytes
<zyga> not changing anything else
<zyga> does't grant more permissions to run
<zyga> or not run
<Wimpress> OK, so by virtue of having the snaps connected, snap A can not execute binaries from snap B. Correct?
<zyga> no, that's not correct
<zyga> if I have a snap that contains a shell script
<zyga> and I expose that via a content interface
<zyga> and that interface is connected to some other sna
<zyga> that other snap can invoke that shell script
<Wimpress> Excellent.
<zyga> that shell script may not be an exposed application
<zyga> and in fact if it is an exposed application
<zyga> I cannot use that exposed application from any snap
<zyga> note that this doesn't imply any more permissions
<zyga> if you content-connect to LXD, for example, you don't get to run LXD with all the powers attached
<Wimpress> So snap A would have to invoke the binary in snap B via a full path?
<zyga> it's just a way to share bytes
<zyga> Wimpress: with path, environment and any other quirks required
<zyga> it's as easy or hard as the associated binary implementation details are
<Wimpress> Would binaries snap A want to execute from snap B be referenced via /snap/snapA/current/bin/foo or via /snap/snapB/current/bin/foo? Or will $SNAP be fine?
<zyga> neither, you need to use the real path where they are shared
<zyga> so if you share them to, say
<zyga> $SNAP/plugins/
<zyga> and find them there
<zyga> you need to know to call $SNAP/plugins/foo/bin/plugin.bin
<zyga> $SNAP or any other variables are not aware of that
<zyga> they will not know anything about any connected content interfaces (perhaps many)
<zyga> they will always point to the snap for which the main process was started
<zyga> (snap A in this case)
<Wimpress> OK. Sounds promising.
<Wimpress> So, if snap A (confined) is connecting to snap B (classic), snap A can execute binaries exposed from snap B but within the confinement defined by snap A. Correct?
<zyga> yes
<Wimpress> Cool.
<zyga> it's really just the same
<zyga> as if they were copied into snap A
<zyga> it's just a way to share bytes
<Wimpress> Just wanted to be clear.
<zyga> sure
<Chipaca> zyga: am back. Indeed /tmp/.X11-unix/X0 is where it's at
<zyga> yay
<Chipaca> zyga: so what do I do?
<zyga> we can easily fix that too
<zyga> hold on
<zyga> looking for something
<zyga> Chipaca: in cmd_run.go we handle XAUTHORITY
<zyga> we could handle X11 socket
<Chipaca> zyga: handle it how?
<zyga> ha, that's tricky
<zyga> we can see the socket
<zyga> but not access it
<zyga> perhaps we should preserve /tmp/.X11* in snap-conifne
<zyga> which is not terribly hard but not super easy either
<zyga> Chipaca: can you please file a bug
<zyga> or find one
<zyga> I bet people reported it
<zyga> there are also mentions of this on the forum
<cachio> zyga, hey
<Chipaca> zyga: I mean, this is from the forum :-)
<zyga> Chipaca: let's cross reference them then
<zyga> cachio: hello
<cachio> zyga, I could make the cifs test work but ...
<cachio> zyga, just adding this to the interface "/run/mount/utab rw,"
<Chipaca> zyga: I wonder if there's a way to tell X to use abstract sockets
<zyga> I think we discussed that
<zyga> cachio: we should not do that
<zyga> Chipaca: some systems don't have one
<cachio> zyga, based on the comment we shouldn't
<zyga> cachio: we cannot add that permission because that would allow snaps to confuse the host's libmount about what certain attributes are
<Chipaca> zyga: it seems to also have an abstract socket, @/tmp/.X11-unix/X0
<zyga> Chipaca: is there anything in the environment
<zyga> any X... variable set?
<zyga> maybe we can do a low cost fix
<zyga> "unset XSTH"
<Chipaca> nothing that I can see
<zyga> dunno then
<Chipaca> zyga: and if I install with devmode it workss
<zyga> oh
<zyga> that's odd
<Chipaca> zyga: so it's not the /tmp/.X11 socket
<zyga> what's the denial?
<Chipaca> zyga: it's access to the socket itself
<pstolowski> mvo: any news on the 2nd run of https://github.com/snapcore/snapd/pull/6219 ?
<Chipaca> 1 sec because I accidentally killed the vm :-)
<mup> PR #6219: overlord/tests: [WIP] fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<zyga> pstolowski: I ran it again, 0 failures
<zyga> restarted (thanks for reminidng me)
<pstolowski> nice, thanks
<pstolowski> fwtw travis pass was green again
<Chipaca> [  157.486384] audit: type=1400 audit(1543324906.843:348): apparmor="DENIED" operation="create" profile="snap.xbill-xaw.xbill-xaw" pid=3187 comm="xbill" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
<Chipaca> had to purge the charon thing to get to see that
<zyga> hold on
 * Chipaca goes to check on the soup
<zyga> weird
<Chipaca> soup for lunch isn't that weird
<Chipaca> i've got a bad cold
<Chipaca> Â¯\_(ã)_/Â¯
<Son_Goku> niemeyer, zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b
<Son_Goku> this might make you guys happy :)
<zyga> indeed
<zyga> Son_Goku: mborzecki is sick, he's off today
<zyga> but I'll make sure he knows
<Son_Goku> ah, that's too bad
<Son_Goku> hope he feels better soon :)
<zyga> Chipaca: which interfaces do you have connected
<zyga> Chipaca: x11 plug grants socket AF_NETLINK, not unix
<zyga> also allows some x abstractions, reading on those now
<zyga> Chipaca: but nothing grants access to that socket
<zyga> Chipaca: could it be the case that apparmor simply doesn't handle abstract sockets
<zyga> and we never noticed?
<Chipaca> sounds like a jdstrand question :-)
<Chipaca> or, maybe a jjohansen ? if i remember people right
 * Chipaca often doesn't
<Chipaca> mmm, tasty tasty schadenfreude http://forum.asrock.com/forum_posts.asp?TID=10174
<zyga> Chipaca: both would know
<Chipaca> ok, i'm off to have actual lunch now
<Chipaca> ttfn
<zyga> good idea
<zyga> I'll wait till after standup
<zyga> I'd love to land https://github.com/snapcore/snapd/pull/6147
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> mvo: can you do a quick review, in mborzecki's absence
<Chipaca> zyga: https://pastebin.ubuntu.com/p/B5d5n36p2h/ might this be relevant to the x11 thing?
<zyga> maybe
<zyga> mvo: the bug is https://bugs.launchpad.net/snapd/+bug/1805182
<mup> Bug #1805182: /tmp is sometime cleaned up after snaps are launched <snapd:Triaged> <https://launchpad.net/bugs/1805182>
<Chipaca> socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) vs socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0)
<mup> PR snapd#6220 opened: cmd: drop cruft from snap-discard-ns build rules <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6220>
<zyga> mvo: can you do a quick review of https://github.com/snapcore/snapd/pull/6147 please
<mup> PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
<zyga> it's green and if it lands I can continue
<zyga> and has one and a half review
<mvo> zyga: I try, have a lot of meeting now :/
<zyga> ok
<zyga> pstolowski: perhaps you ^
<pstolowski> 6147?
<pstolowski> zyga: ^
<zyga> yes
<pstolowski> ok
<zyga> meanwhile, 2.36 branch for those errors
<zyga> mvo: I just realized something
<zyga> the terminated error is not new
<zyga> we probably had it since forever
<zyga> but we would not notice it until the special situation in 2.36 branch
<zyga> this doesn't change why it is broken
<zyga> but may help us form new perspective
<zyga> because we had ignored those errors all the time
<zyga> we would just happily carry on
<mup> PR snapcraft#2417 opened: Revert "lifecycle: make snapcraft init template use > not | (#2393)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2417>
<mup> PR snapd#6221 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
<zyga> mvo: this one is for you https://github.com/snapcore/snapd/pull/6221
<mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
<mup> PR snapd#6222 opened: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
<zyga> pstolowski: nice
<zyga> pstolowski: 0 errors
<pstolowski> zyga: very nice, thanks, i'm cleaning that PR atm, will push an update
<zyga> pstolowski: I woudn't mind a follow up
<zyga> this looks sane as-is
<pstolowski> well it outputs debug
<pstolowski> pushed
<pstolowski> i'll cherry pick into master
 * cachio lunch
<zyga> cachio: offtopic, can we start instances not in us-east
<zyga> it would be awesome if we could do europe too
<zyga> cachio: latency to us-east sucks :/
<zyga> not sure if this is something you or gustavo needs to handle
<zyga> spread on travis is ok
<zyga> but interactive spread for debugging is not
<zyga> I'm fine with editing my spread.yaml if I can achieve that
<mup> PR snapd#6147 closed: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Per-user mount ns  ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6147>
<zyga> thank you mvo!
<zyga> mvo: https://github.com/snapcore/snapd/pull/6221 no errors yet!
<mvo> zyga: meeting ended early :)
<mvo> zyga: oh no
<mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
<zyga> well, there are unit test panics that pstolowski is fixing
<mvo> zyga: its so annoying
<zyga> but none of the other errors
<zyga> so while I don't get it, it's interesting output
<mvo> zyga: it seems to be happening all the time in the 6128 PR
<zyga> mvo: 6128 is merged, I assume you mean a 2.36 backport of that
<zyga> well, let's see
<zyga> I need to break for dinner now
<zyga> I will be back
<zyga> mvo: https://github.com/snapcore/snapd/pull/6220 looks like an easy win
<mup> PR #6220: cmd: drop cruft from snap-discard-ns build rules <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6220>
<zyga> and helps me move forward too
<mvo> zyga: 6218 - sorry
<mvo> zyga: as a general rule I always approve PRs that have only reds
<zyga> re
<zyga> looking
<zyga> mvo: https://github.com/snapcore/snapd/pull/6221 didn't fail on that apparmor issue
<mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
<zyga> mvo: do you have any theory as to why the patch may make it better?
<mvo> zyga: in a meeting, can you just retrigger?
<cachio> zyga, I think we can
<zyga> yep
<zyga> did
<cachio> nice
<cachio> there is a problem
<zyga> cachio: if you tell me how I'd love to try
<zyga> but I need to take the dog out first :)
<cachio> the spread cleaner is configured to clean machines just on us-east1-b
<zyga> oh
<cachio> it is basically because you query instances by zone
<kenvandine> mvo: were you saying desktop-launch in brave was taking ~2s on the 2nd launch on 18.10?
<zyga> kenvandine: AFAIK it was update-mime-cache or something like that
<kenvandine> that should only be on the first run
<zyga> pstolowski: I just got a notification that ISS is rising
<zyga> coool
<zyga> the app is not even open
<pstolowski> zyga: :)
<zyga> kenvandine: yeah but from what mvo researched it seemed to be a constant cost
<kenvandine> interesting
<zyga> I didn't examine that, I think it's best to wait for mvo to leave the meeting frenzy
<kenvandine> i just tried it on my 18.10 laptop and i'm getting good results
<kenvandine> desktop-launch elapsed time:  0.116752997
<zyga> mmm
<mvo> kenvandine: interessting - here is my second run:http://paste.ubuntu.com/p/hFbMF8CQKT/
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6222#issuecomment-442126406
<mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
<mvo> kenvandine: maybe specific to my machine, its a pretty beaten setup :)
<kenvandine> mvo update-mime-database and update-icon-cache should only run on the 1st run
<mvo> kenvandine: ok, should I set -x the script to see what is going on?
<mvo> kenvandine: let me do that
<kenvandine> yes
<kenvandine> mvo:  that would be useful
<kenvandine> mvo: that should only run if needs_update is true
<pstolowski> zyga: damn, i think it's not deteministtic... saw that error once but then stopped getting it as the test was tweaked
<kenvandine> mvo: https://pastebin.ubuntu.com/p/C2M7Y6XQpf/
<mvo> kenvandine: it looks like the user-dirs.dirs check is setting needs_update=true
<mvo> kenvandine: I'm trying to figure out now why
<kenvandine> oh
<kenvandine> mvo: that's not setting it for me
<kenvandine> so maybe that's the trigger
<kenvandine> perhaps we shouldn't overload needs_update there
<mvo> kenvandine: I have no .md5sum file in my dir it seems
<kenvandine> mvo: what's your actual $HOME/.config/user-dirs.{dirs,locale} look like
<mvo> kenvandine: I don't have a user-dirs.locale
<kenvandine> sigh...
<kenvandine> i wonder why not
<mvo> kenvandine: I have no idea :/
<mvo> kenvandine: but its there on my other box - what creates it?
<kenvandine> not sure
<kenvandine> mvo: so for you it's doing a bunch of things on every run that it shouldn't
<mvo> kenvandine: indeed
<kenvandine> seb128: ^^ what creates user-dirs.locale?
<roadmr> hey folks, a question! two old revisions of each snap are kept for rollback purposes. But these are squashfs-mounted. Why are they mounted if they're not really in use?
<zyga> roadmr: two reasons
<zyga> roadmr: we didn't do it better
<zyga> roadmr: we don't cache meta/snap.yaml
<zyga> so we really go and look each time you ask
<zyga> we also rely on the filesystem being there to discover things like hooks
<roadmr> ok :)
<mup> PR snapd#6220 closed: cmd: drop cruft from snap-discard-ns build rules <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6220>
<zyga> roadmr: given that they consume memory it would be nice to not have to mount those
<zyga> roadmr: we might get to a point where snapd caches enough stuff about them to stop needing that
<roadmr> zyga: indeed, it did seem weird and wasteful but doesn't seem to be the end of the world :)
<zyga> pstolowski: I keep getting panics
<zyga> those that your PR fixes
<zyga> cannot wait for 6219
<pstolowski> zyga: noooo..
<pstolowski> zyga: uh oh, you getting them without my PR?
<zyga> yes
<zyga> btw
<pstolowski> ufff
<zyga> inside your pr
<zyga> what were the calls to the "snap" command like?
<zyga> can you check that in the test quickly
<zyga> even locally
<pstolowski> zyga: probably none, i added just in case run-hook is exectued, as this was a case in many other tests before. i can probably remove it here, but there is no harm in leving it
<zyga> can you just double check before this goes in
<pstolowski> ok
<cachio>  zyga already tried mounting on /run/mount but still get the same denial
<cachio> apparmor="DENIED" operation="open" profile="snap.test-snapd-sh.with-cifs-mount" name="/run/mount/utab" pid=24510 comm="mount" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0
<zyga> cachio: you'd have to change the interface
<zyga> cachio: to do two more things:
<zyga> allow that path to be written
<zyga> and create a symlink in /run/mount/utab
<zyga> the problem is that it's not easy to do 2)
<zyga> for the moment I have no solution
<pstolowski> zyga: no calls to snap cmd, verified with fmt.Printf("%q\n", ms.snapCmd.Calls()) in teardown
<zyga> cool
<cachio> zyga, ok, I'll try that
<zyga> cachio: no, please don't
<zyga> cachio: there is no fix now
<cachio> zyga, ah, ok
<cachio> :(
<zyga> sorry, no easy win
<zyga> mvo: one more trivial https://github.com/snapcore/snapd/pull/6223
<mup> PR #6223: cmd/libsnap: move apparmor-support to libsnap <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6223>
<zyga> this all setting the stage for the big tool cleanup that mborzecki requested
<mup> PR snapd#6223 opened: cmd/libsnap: move apparmor-support to libsnap <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6223>
<pstolowski> #6219 failed on unrelated stuff, for the 2nd time
<pstolowski> google:ubuntu-16.04-64:tests/main/interfaces-content-mkdir-writable
<mup> PR #6219: overlord/tests: fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<pstolowski> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
<pstolowski> (previously it failed on the .mnt unit bug)
<zyga> cachio: some quick comments on 6217
<zyga> pstolowski: eh
<zyga> 2.36 of doom
<zyga> pstolowski: perhaps we should merge the two 2.36 fixes into one branch
<zyga> WOAH
<zyga> we foudn some useful stuff
<cachio> zyga, tx
<zyga> error from apparmor-parser https://www.irccloud.com/pastebin/4APIpXG2/
<zyga> jdstrand: hey, I recall there were some parser incompatiblity with older LEAP releases
<zyga> this looks similar ^
<zyga> do I recall if you had a PR that fixed this in master
<zyga> this comes from a PR that makes errors actually reported: https://github.com/snapcore/snapd/pull/6221
<mup> PR #6221: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
<zyga> it is against 2.36, not master
<pstolowski> zyga: !
<mup> PR snapd#6224 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6224>
<zyga> I opened one against master
<zyga> let's see what happens
<zyga> I need to take Bit out for that walk!
<zyga> I'm terrible at tracking time sometimes
<zyga> ttyl
<zyga> mvo: I'll break to get some groceries with wife
 * cachio afk
<mvo> zyga|afk: hm - so "AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap-confine.core.6016 in /var/lib/snapd/apparmor/profiles/snap-confine.core.6016 at line 103: Exec condition must begin with '/'." - in my profile line 103 is: "    change_profile unsafe /** -> [^u/]**,
<mvo> "
<zyga|afk> Hey
<zyga|afk> mvo: I know what that is but I m afk now
<zyga|afk> mvo: still here?
<mvo> zyga|afk: back now
<zyga> hey
<zyga> so long story, we use a incompatible format in master
<mvo> zyga: you know what it is?
<mvo> zyga: meh
<zyga> yes, we knew about it
<zyga> I think jdstrand assumed that leap is not needed anymore
<zyga> and because we didn't return the error all the way
<zyga> it was non-fatal
<zyga> I actually think there's some correlation between this and the unit test failure
<zyga> see
<zyga> if some things weren't mocked
<zyga> and really ran
<zyga> they may really fail
<zyga> and then we'd start undoing
<zyga> look at master version of the PR that uncovers this
<mvo> zyga: hm, so why is it flaky then and does not fail all the time?
<zyga> the error in master is exactly the panic that pawel was chasing
<mvo> zyga: and its incompatible with 16.04?
<zyga> it depends on what ran before
<zyga> I don't think it is incompatible with xenial
<zyga> but I don't know yet
<zyga> I just realised what it was while outside
<zyga> I will see for myself on leap 42.3 - i have all those VMs around
<mvo> zyga: ok, thats great that we finally have a lead
<zyga> I didn't check
<zyga> or I don't remember
<zyga> if the unit test failure was specific to one system
<mvo> zyga: I'm still puzzled that we see these failures on ubuntu
<zyga> or was it all over
<zyga> yeah
<zyga> what's curious is that here (now) we got a message from apparmor parser
<zyga> we got the output saying "stuff is bad here and here"
<zyga> previously it was just "terminated"
<zyga> that's still hinting at another problem
<zyga> that's all the insight I have so far
<mvo> 2018-11-27 17:11:14 Error executing google:ubuntu-16.04-64:tests/main/parallel-install-interfaces-content:common :
<mvo> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
<zyga> yeah
<zyga> that means you run with edge profile
<mvo> zyga: aha, ok
<zyga> because you were not able to load the real profile
<zyga> maybe 16.04 _is_ incompatible
<mvo> zyga: yeah, indeed
<zyga> I'll check
<zyga> fun stuff
<zyga> well
<mvo> zyga: that would be nice, thanks a lot, again, great to hear the progress
<zyga> "fun"
<zyga> logging a problem vs returning it
<zyga> because reliability
<zyga> while I have you
<zyga> https://github.com/snapcore/snapd/pull/6223
<mup> PR #6223: cmd/libsnap: move apparmor-support to libsnap <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6223>
<zyga> :D
<zyga> pretty plesae
<zyga> *please
<mvo> zyga: heh, ok
<zyga> \o/
<zyga> thanks!
<zyga> I'm moving this because the next PR will add a tool.c tool.h combo that is all about "I want to run snapd tool from another snapd tool written in C"
<zyga> this is the cleanup that maciej requested
<zyga> so I'm shaving some yak there
<zyga> mvo: https://github.com/snapcore/snapd/pull/6149 this is the next critical in the pipe, but that's for tomorrow
<zyga> mvo: I'll get to that apparmor issue now
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> and let's see what we get
<mvo> zyga: ok, my critical pipe is 2.36, can we somehow test the theory that its incompatible apparmor? and if incompatible, what exactly is incompatible and is there something we could revert back to?
<zyga> yes
<zyga> one part of the syntax is
<zyga> I have it on screen now
<zyga> I don't think we can revert it easily
<zyga> it was intertwined with other work jdstrand did for docker and some other snaps
<zyga> what we have now is rich enough to know we have old apparmor parser
<zyga> so we might be able to offer alternative syntax
<zyga> stay tuned
<zyga> or
<zyga> go get some rest
<zyga> go get github.com/mvo5/rest
<zyga> leap 42.3 has apparmor parser 2.10.3
<zyga> checking 14.04
<zyga> 14.04 has 2.10.95
<zyga> feels like the .95 is a "backport of lots of stuff"
<zyga> I'll check compatibility now
<zyga> TW has 2.13
<mvo> zyga: thank you
<pedronis> mvo: zyga: do we have issues in 2.36 that affects only SUSE ?
<pedronis> do we turn on apparmor by default there?
<zyga> pedronis: it affects one suse release but it seems that there's some overlap with other distributions because the error was ignored
<zyga> no
<zyga> but we don't special case that in apparmor backend when  setting up core/snapd
<zyga> we could also fix it there somewhat
<pedronis> is this specific to snap-confine own profile?
<zyga> yes
<pedronis> zyga: so we did something there that breaks on some distros != ubuntu where we do use apparmor?
<pedronis> but didn't notice because we were ignoring apparmor parsing errors?
<zyga> yes
<pedronis> mmh
<pedronis> fun, not
<zyga> not really parsing errors, we ignored all setup errors
<zyga> with a comment saying "better to carry on"
<zyga> I guess this goes back to the age when we had mysterious errors when snap revision was not in the state
<zyga> and we just ignored it
<zyga> without knowing what that ultimate cause was
<zyga> but as I told mvo, I think that's not the full story
<zyga> and that we are missing something
<pedronis> zyga: in which sense?
<zyga> I think there are two issues related to apparmor parser
<zyga> one has a clear message that says we use unknown syntax and happens on leap 42.3
<zyga> another has no message at all
<zyga> and happens all over the place
<pedronis> mmh
<zyga> (certainly on xenial)
<pedronis> this is related to recent changes to the snap-confine profile?
<zyga> no
<pedronis> since when is this broken?
<zyga> I think ~2 months
<pedronis> then
<zyga> let me check
<pedronis> also on xenial?
<pedronis> you are saying 2.35 ... ?
<pedronis> or just that 2.36 has been around so long?
<zyga> I don't believe xenial parser has issues with this
<zyga> one sec, git blame'ing
<zyga> hmmm, no that's not right
<zyga> it must be something else
<zyga> the patch introducing this syntax is from 2016
<pedronis> well you said we have two problems
<zyga> back to the idea board
<pedronis> zyga: anyway this sounds more and more a needs fresh brain issue, that solve it now
<zyga> I will check the backend code now
<zyga> yeah
<zyga> I'm just happy we have something to look at now
<pedronis> I would recommend to sleep on it and we talk in the morning
<zyga> all yesterday was chasing ghosts
<zyga> good idea
<zyga> let's EOD
<mvo> ok
<zyga> see you tomorrow
<pedronis> mvo: if it's not a regression we can decide to do 2.36 anyway
<pedronis> mvo: sounds like too many moving parts atm
<pedronis> mvo: we should discuss in the morning
<zyga> pedronis: he's left now
<pedronis> ok
<pedronis> good either way
<pedronis> as stand by my "needs fresh brain" "proclamation"
<pedronis> let's chat in the morning again
<zyga> yep
<pedronis> s/as/I/
<roadmr> ð§ 
<pedronis> roadmr: brain emoji?
<roadmr> pedronis: you wanted fresh brain :)
<pedronis> now you make me sound like a zombie, "brains" "brains"  :)
<roadmr> there's unsurprisingly also an emoji for that :P
 * pedronis is unsurprisingly unsurprised :)
<roadmr> hehe
<kyrofa> It's so tiny here, I thought it was ice cream
<roadmr> kyrofa: oh, you mean, like: https://bit.ly/2AsL6KS ?
<kyrofa> Haha
<mup> PR snapd#6225 opened: tests: fix for failover test on how logs are checked <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6225>
#snappy 2018-11-28
<mup> PR snapcraft#2354 closed: Preflight missing multipass <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2354>
<mborzecki> morning
<zyga|afk> Hey
<zyga|afk> mborzecki: how are you
<mborzecki> zyga|afk: hey, feeling better today
<mborzecki> zyga|afk: noticed that removable-media allows acessing/wiritng to /mnt, i was always under the impression that only {/run}/media is allowed there
<mborzecki> mvo: morning
<mvo> mborzecki: good morning! hope you feel better
<mvo> zyga|afk: hey, anything new from the aa bug?
<mborzecki> mvo: yes, way better today
<mvo> mborzecki: great!
<mborzecki> zyga|afk: when you're here, can you take a look at https://forum.snapcraft.io/t/the-removable-media-interface/7910 I've added /mnt there since we support it, but did not mention anything about mount propagation since the interface does not allow mounting anyway
<pstolowski> hey
<mborzecki> pstolowski: hey
<pstolowski> mborzecki: hey, how are you, feeling better?
<mborzecki> pstolowski: yeah, thanks
<mvo> zyga|afk: woah, I got "cannot create temporary directory for /var/lib/snapd mount point: Permission denied" now on first try of mvo5/run-fontconfig-2.36
<mwhudson> popey: i took your advice and made a screenshot https://snapcraft.io/go
<mup> PR snapd#6223 closed: cmd/libsnap: move apparmor-support to libsnap <Simple ð> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6223>
<mborzecki> mwhudson: nice, should include go env output too
<mwhudson> mborzecki: you think? i most of it is pretty boring
<mwhudson> +think
<pedronis> mvo: hi
<mborzecki> mwhudson: maybe go env GOROOT GOTOOLDIR?
<pedronis> mvo: anything I can help with?
<mwhudson> mborzecki: yeah, might make sense
<mwhudson> the whole process is a bit tedious tbh, but if i redo it for some reason :)
<mborzecki> mwhudson: that's asciinema right?
<mvo> pedronis: good morning - we are still struggling with the apparmor failure in 2.36. I did some work on the --trace-exec in 6185, please have a look but I can do more just got distracted because of the aa issue
<mwhudson> mborzecki: yes, plus hacking to smooth out the typing
<mvo> pedronis: but 6185 should be cleaner than before
<popey> mwhudson: I love that!
<pedronis> mvo: ok, do we need to have a chat about the aa issues with zyga as well?
<mborzecki> mwhudson: mhm, very nice!
<mvo> pedronis: maybe, I think he had some new ideas since last night, but I don't know more details yet
<pedronis> ok
<popey> mwhudson: I hope it's not so big as to trigger this though ;) https://gitlab.gnome.org/GNOME/gnome-software/issues/532
<mwhudson> popey: heh no
<mvo> pedronis: 5845 needs a second review (the files interface) but thats probably in good hands with jamie and zyga
<pedronis> pstolowski: are you blocked atm?  my and mvo days are a bit full of meetings and we have the 2.36 troubles
<pedronis> pstolowski: I still would like the 3 of us to talk about hot plug next step this week tough, but tomorrow might be better
<pstolowski> pedronis: not really, it can wait till tomorrow (not sure i can get 2nd review of the hotplug disconnect branchs from mvo under these circumstances anyway). i've also been working on one of the 2.36 blockers
<pedronis> pstolowski: ok, btw I answered in https://bugs.launchpad.net/snapd/+bug/1777121 it makes sense to pick it up, make a card and work on it when you have time
<mup> Bug #1777121: Remove is called after snap services are stopped  <snapd:Triaged> <https://launchpad.net/bugs/1777121>
<pstolowski> pedronis: great, i'll take it
<pedronis> pstolowski: can I help somehow with that panic?
<pstolowski> pedronis: no, thanks, i think that's fixed, except cannot land due to other random test failures
<mvo> pedronis: the panic is interessting, mocking the usr.lib.snapd.snap-confine.real makes the problem go away - it almost looks like there might be a connection to the other bug we are looking at
<zyga|afk> Yep
<zyga|afk> Hello
<mvo> pstolowski: could it be that setup profiles for some reason looks at the real /snap/core/current/... usr.lib.snapd.snap-confine.real and dies there?
<zyga|afk> Sorry for starting late. Daughter woes
<pstolowski> hey zyga|afk
<mvo> zyga|afk: hey
<zyga|afk> Iâm taking bit out but heading home now
<zyga|afk> I will read backlog
<pstolowski> mvo: no, it's not looking at real one; it's for sure looking at /tmp/.../check-xyz/snap/core/<rev> (i had debug logs confirming this)
<mvo> pstolowski: ok
<pstolowski> it's curious why it wasn't failing before though, not sure what changed. or if we were plain lucky before
<zyga|afk> Hahhahhahh
<zyga|afk> You will have fun knowing why
<zyga|afk> Man
<zyga|afk> Sorry still not at my kb
<zyga|afk> There
<zyga|afk> Solved it
<mvo> zyga|afk: can't wait to hear the details
<mvo> zyga|afk: does it also shed some light on the other issue ?
<pstolowski> can't wait to that as well :)
<pstolowski> mvo: is there any other 2.36 issue i can help with?
<mvo> pstolowski: 6185 needs a second review, we could pull this into 2.36
<mvo> pstolowski: but it first needs a merge into master :)
<pstolowski> mvo, zyga|afk https://github.com/snapcore/snapd/pull/6219 is green now ; needs 2nd review
<mup> PR #6219: overlord/tests: fix panic in managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<pstolowski> now sure how relevant it is with zyga|afk's findings about setup-profiles
<mvo> pstolowski: I'm looking at the exact error now, I have it in a VM and it seems to be reliable to reproduce
<pstolowski> mvo: is it cosmic?
<zyga|afk> re
<mvo> pstolowski: 16.04
<zyga> give me a moment please
<zyga> so, the 1000ft version is that we never ever mocked security backends
<zyga> and that's not good
<zyga> and stuff didn't blow up because we 100% ignored all errors
<zyga> so running overlord tests would really run apparmor parser
<zyga> reload udev
<zyga> and all the other stuff
<zyga> including setting up all snaps on manager startup
<zyga> including initializing the apparmor backend
<mvo> errors:[]state.taskError{state.taskError{task:"Setup snap \"some-snap\" (40) security profiles", error:"cannot setup apparmor for snap \"core\": cannot create host snap-confine apparmor configuration: cannot compute snap-confine profile: cannot open apparmor profile for vanilla snap-confine: open /tmp/check-2391705272889139391/162/snap/core/1/etc/apparmor.d/usr.lib.snapd.snap-confine: no such file or directory"
<zyga> and setting up snap-confine profile when core was being setup
<mvo> zyga: so yes :)
<zyga> so
<zyga> the reason that pawel's branch fixed the panic
<zyga> is that it made part of the apparmor.Backend.Setup code happy
<pedronis> zyga: where?  I'm quite sure we tried to mock aa parser
<zyga> I realised while outside that the only reason this can have an effect
<zyga> is that we ran with the full backend
<zyga> pedronis: managers_test
<zyga> it just spawns the full interface manager and carries on
<pedronis>  ms.aa = testutil.MockCommand(c, "apparmor_parser", "")
<pedronis> etc
<mvo> zyga: I think this is understood now, thank you! the next question is why http://paste.ubuntu.com/p/fv5fsh3PDy/ makes the error to setup the aa profile basicly go away
<mvo>   
<pstolowski> zyga: we do mock apparmor_parser though (at least in these tests i worked on)
<pedronis> maybe it doesn't work, but for sure it was trying
<zyga> that's only part of the story, we should not run those tests with real backends
<pedronis> zyga: ?
<pedronis> they are meant to be quite integrationy
<pedronis> that seems a bit of a broad statement
<zyga> then we need much more preparation in that phase, right now a small tweak in backend needs to be reflected in extra setup or mocking in the overlord test
<mvo> pedronis: the error we get in the test is actually that it can't open the core template profile, so this happens before aa_parser (just for context)
<zyga> anyway, please let me explore
<zyga> yep
<zyga> so we need to either:
<pedronis> mvo: yes, so we have some code that doesn't respect dirs root
<zyga> 1) prepare a full blown environemnt that each backend expects
<pedronis> or soemthing
<pedronis> I'm just trying to counter that it wasn't trying to mock things
<mvo> pedronis: it does respect them, thats the problem, there is nothing there so it fails to open the profile
<mvo> pedronis: yeah, that is correct - we do mock stuff
<zyga> 2) ask each backend to mock itself properly so that it can kind of run but have no real effect
<zyga> 3) not run with real backends at that stage
<zyga> we mock things in the wrong place, the overlord doens't know how to mock apparmor
<zyga> mocking one command is not enough
<pedronis> zyga: assume I understand what you are saying
<zyga> the responsibility of knowing how to mock is in the backend itself, not in a test far far away
<pedronis> zyga: is there a clean way to turn off the backends? would those tests still pass as they are?
<zyga> e.g. calling backend.Initialize from apparmor interrogates the system about nfs and overlayfs
<zyga> that's not mocked in any way
<zyga> pedronis: sure, we do that in the interface manager tests
<zyga> pedronis: I was surprised this is not done so
<zyga> partially the question is what do we want to do in those tests
<zyga> are they integration tests?
<zyga> are they tests for the overlord?
<pedronis> zyga: the name tells you what they try to do
<pedronis> they try to test the integration of more than one manager
<zyga> if they are integration tests then running with real managers, even if their activity is mocked feels wasteful since we don't observe what they do
<zyga> pedronis: that's fine
<zyga> keeping the manager is ok
<pedronis> zyga: anyway I told you a very actionable thing, is there a clean way to turn off the backends? would those tests still pass as they are?
<zyga> but if we don't check what is the impact of apparmor or seccomp part of the interface manager, perhaps we should not use real backends
<pedronis> you answered the first bit
<pedronis> let's see about the 2nd, no?
<zyga> yes, checking that now
<zyga> hold on
<mvo> I think this is interessting and we need to look at this but it does not (afaict) help with the apparmor_parser getting killed issue we have in 2.36
<pedronis> mvo: does it get killed on some distros or all distros?
<pedronis> when does it get killed?
<mvo> pedronis: so far I only saw it on 16.04
<pedronis> I mean in which tests
<mvo> pedronis: it gets killed when it tries to setup the snap-confine security profiles on the hosts
<pedronis> in a spread test? unit test?
<pedronis> randomly?
<mvo> pedronis: I see it in tests/main/layout and tests/main/parallel-install-layout - spread tests
<pedronis> ok, spread test
<mvo> pedronis: let me try to find out if it happens in more
<pedronis> anywy, yes then is not related
<pedronis> by def
<mvo> pedronis: making the error from a notify log to a real error changes the outcome for some reason, its super strange but with http://paste.ubuntu.com/p/kksmSpN95H/ I cannot reproduce the issue anymore
<pedronis> mvo: there are probably two calls? and the first fails benigly and the 2nd days?
<pedronis> that would explain why that would make a difference
<mvo> pedronis: also failure seems slightly random, in GH we see it also in parallel-install-interfaces-content and snap-env but all 16.04
<zyga> mvo: there is one more place
<zyga> mvo: actually two, you just have an older patch
<zyga> mvo: the key place is actually in interface manager initialize when we redo security when system key changes, this is still ignored in the older copy you have
<mvo> zyga: ok, where can I find the correct one?
<mvo> zyga: what is super strange is that literally on the first try of run-fontconfig-2.36 I hit the bug
<mvo> zyga: then I added the diff and run again and had ~4-5 runs since and nothing triggers it
<zyga> pedronis: all tests pass
<pedronis> zyga: good, can you propose something that removes the bad mocking and does the right mocking? so we can look at it
<zyga> yep
<zyga> doing that now
<pedronis> mvo: I added a couple of questions to #6185
<mvo> pedronis: thank you, checking
<mup> PR #6185: snap: add new `snap run --trace-exec` call <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6185>
<zyga> mvo: sorry, missed your question
<zyga> mvo: there's a patch with logging -> errors on GH but I found one more place where that happens, haven't pushed that part
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6226
<mup> PR #6226: overlord: mock security backends for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/6226>
<zyga> let's see how this runs
<mup> PR snapd#6226 opened: overlord: mock security backends for testing (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6226>
<mvo> zyga: thank you!
<zyga> mvo: re errors vs logging, I checked my patches from last night and they are all up to date
<zyga> sorry for the noise, still drinking my first coffee
<mvo> zyga: no worries
<zyga> what remains a bit of a mystery is the no-output error from apparmor parser
<mvo> zyga: I reverted to see if I get the failure without the change or if I'm hunting a ghost
<zyga> cookl
<mvo> zyga: yeah, especially since we set SNAPD_DEBUG afaik in the tests so we should see output
<zyga> I restarted my tests, if I can get it to happen again I'd like to look
<zyga> I wonder if it is possible that mocked no-op apparmor_parser is _somehow_ leaking from unit tests into the state of the machine where they execute
<zyga> mvo: I will now look at the profile compatibility issue on leap
<zyga> mvo: I think we should not compile snap-confine profile if snap-confine in the distribution has disabled apparmor
<pedronis> zyga: MockCommand is based on setting PATH so it should't go further than unit tests
<zyga> pedronis: yeah but maybe some magic sequence of bugs or something
<zyga> mvo: alternatively we can look at apparmor parser version and skip it this way, it should be the same outcome
<zyga> s/be/have/
<mvo> zyga: first run without the diff that makes it a real error and I hit the issue again
<mvo> zyga: "Nov 28 10:32:00 nov281009-194489 snapd[29337]: backend.go:312: cannot create host snap-confine apparmor configuration: cannot reload snap-confine apparmor profile: cannot load apparmor profiles: signal: terminated
<mvo> "
<mvo> Nov 28 10:32:00 nov281009-194489 snapd[29337]: apparmor_parser output:
<zyga> can you check one thing
<zyga> if you have shell still
<mvo> I do
<zyga> look at what apparmor_parser is
<zyga> is it the real deal
<zyga> also look at journalctl
<mvo> zyga: https://paste.ubuntu.com/p/BvBvkxP4Mn/
<zyga> if the parser is loading stuff into the kernel it will trigger an audit event
<zyga> so you may match the timestamp above
<zyga> to an audit even
<zyga> (looks allright)
<mvo> zyga: https://paste.ubuntu.com/p/KWYSKPVgJY/ - looks like audit is not showing that the snap-cofine profile is loaded
<zyga> indeed
<zyga> anything around the timestamp of
<zyga>  "Nov 28 10:32:00 nov281009-194489
<mvo> zyga: https://paste.ubuntu.com/p/6wbYy8psFb/
<zyga> hum
<zyga> as if nothing had happened
<mvo> zyga: I will try to run the apparmor_parser manual now
<zyga> mvo: crazy idea, apparmo_parser -> apparmor_parser.real, log all invocations
<zyga> can you reliably reproduce it?
<zyga> which test was it that failed now
<mvo> zyga: the test is pretty random
<mvo> zyga: but without your diff I hit it 2/2 so far
<mvo> zyga: today
<mvo> zyga: via the mvo5/run-fontconfig-2.36
<mvo> zyga: I think plain upstream/release/2.36 will also work, takes ~100 tests and then it happens
<zyga> mvo: I will try your branch now
<mvo> zyga: silly question, what is our cache dir again?
<zyga> which cache?
<zyga> apparmor?
<mvo> zyga: apparmor cache for the re-exec thing
<zyga> we use /var/cache/apparmor
<zyga> for all our profiles
<zyga> we no longer use any other paths
<mvo> zyga: thanks
<zyga> note: we still use the other place for that single profile that ships with the package
<mvo> zyga: and running it by hand - works :(
<zyga> yeah, I ran it by hand once in a debug session
<zyga> it's maddening
<zyga> wish I had a rollback machine to get a few seconds into the past
<zyga> mvo: so FYI, /etc/apparmor.d/cache/
<zyga> because cache is in etc
<pedronis> pstolowski: mvo: I created a meeting for tomorrow, let me know if it doesn't work
<pstolowski> pedronis: thanks, it's fine
<mvo> pedronis: thank you
<zyga> brb, it's super cold in the office today
<mvo> zyga: see you - I add the wrapper thing now
<zyga> back
<zyga> mvo: https://github.com/snapcore/snapd/pull/6226 is green!
<mup> PR #6226: overlord: mock security backends for testing (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6226>
<zyga> pedronis: can you look please,
<zyga> I think this is the dealbreaker
<zyga> though it doesn't explain why things fail in non-unit tests
<zyga> those also passed on 1st run :)
<zyga> virtually unheard of :)
<pedronis> zyga: do we have other places outside of overlord that do overlord.New ? and need the same mocking
<pedronis> I think daemon might
<zyga> I checked all of overlord but indeed, daemon might
<zyga> looking now
<pedronis> zyga: +1 with this kind of questions
<zyga> pedronis: yes, adding the same treatment to daemon now
<pedronis> zyga: devicestate/firstboot_test.go seems also to create a full overlord
<pedronis> for some tests
<zyga> I added a printf that logs the added backends, I'll check that we are good across the tree
<zyga> actually, it seems daemon did this already
 * zyga double checks
<zyga> though not for all suites
<mvo> zyga: oh, fun
<zyga> mvo: any luck with apparmor_parser?
<mvo> zyga: not yet
<mvo> zyga: still running
<mvo> zyga: green is also annoying - why is it green, it should fail with the same appamor issue
<mvo> zyga: I mean, it should fail with permission denied at a random place when the apparmor_profile canot be (re)loaded
<zyga> yes :/
<zyga> odd observation
<zyga> go test
<zyga> I see stdout
<zyga> go test ./...
<zyga> I don't see stdout!
<mvo> zyga: I remember I discussed that with john a while ago, it was strange go testrunner setup iirc
<zyga> everything is mocked now, let's do a master version of that
<mup> PR snapd#6227 opened: overlord,daemon: mock security backends for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/6227>
<mvo> zyga: with wrapper -> no error
<zyga> seriously
<zyga> how can that be!?!
<zyga> maybe just back luck?
<zyga> *bad
<mvo> zyga: maybe, I run it again
<mvo> zyga: the mock security backends got cherry-picked, right?
<zyga> mvo: meaning?
<zyga> I opened a 2.36 and master PRs
<zyga> same patch
<mvo> zyga: I mean, between 2.36 and master it can be chrry picked?
<zyga> yes
<mvo> zyga: great
<zyga> two PRs are in flight now
<mvo> zyga: ok
<mvo> zyga: did you restart the 2.36?
<zyga> yes
<zyga> well
<zyga> I pushed to include daemon mocking and devicestate mocking
<zyga> so same patch in both places, one was new one was force pushed over the old one
<mvo> zyga: ok
<mup> PR snapd#6228 opened: snapstate,overlord: update fontconfig caches with overlord mocking (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6228>
<mvo> zyga: second run with wrapper starts now
<zyga> mvo: I'm fixing leap bug
<zyga> mvo: I'm a bit unsure if we should land https://github.com/snapcore/snapd/pull/6221
<mup> PR #6221: interfaces: return security setup errors (2.36) <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6221>
<zyga> the risk is breaking snapd startup
<mvo> zyga: got the error: https://paste.ubuntu.com/p/r54VmSGf37/
<mvo> zyga: yeah, this is why I set it to blocked
<zyga> perhaps we should still ignore this error: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/helpers.go#L187
<zyga> looking
<mvo> zyga: I think this needs some more work, breaking on startup is not ideal
<zyga> I checked my PR, it's not blocking startup
<mvo> zyga: hm, actually the real error is earlier, let me dig some more
<zyga> memory of what I pushed last evening is rusty
<zyga> mvo: is that the only invocation?
<zyga> or last one
<mvo> zyga: the last one, a gazillon before
<zyga> aha
<mvo> zyga: I thik `--replace --write-cache -O no-expr-simplify --cache-loc=/var/cache/apparmor /var/lib/snapd/apparmor/profiles/snap-confine.core.6022` is the failing one but the script needs to be smarter
<zyga> maybe patch the wrapper to log the error too
<mvo> zyga: yeah
<zyga> cool
<zyga> suggestion
<zyga> when it fails copy the non -- arguments to /tmp/WAT/
<zyga> for inspection
<zyga> fingers crossed
<zyga> pstolowski, mvo: shall we close https://github.com/snapcore/snapd/pull/6219
<mup> PR #6219: overlord/tests: fix panic in managers test <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<pstolowski> closed
<mup> PR snapd#6219 closed: overlord/tests: fix panic in managers test <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6219>
<zyga> pstolowski: thank you for writing that, without that PR I would never think that that code is using apparmor backend
<mvo> yeah, thanks pstolowski and zyga for this one - now we just need to figure the appamor thing out to make me truly happy
<pstolowski> yep, that an interesting one ;)
<zyga> mvo: the branches are green
<zyga> shall we merge https://github.com/snapcore/snapd/pull/6226
<mup> PR #6226: overlord,daemon: mock security backends for testing (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6226>
<zyga> and https://github.com/snapcore/snapd/pull/6227
<mup> PR #6227: overlord,daemon: mock security backends for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/6227>
<zyga> pedronis: ^ ?
<pedronis> one sec
<pedronis> zyga: did you rebase it?
<zyga> pedronis: the one on master, yes
<pedronis> well seems you force pushed the one on 2.36 as well
<zyga> yes, with daemon and devicestate changes
<zyga> I wanted one patch for master
<pedronis> zyga: do we need the devicestate changes? it doesn't seem to use the interface manager
<zyga> pedronis: it spawns the overlord, that initializes apparmor backend doing some work
<pedronis> where?
<zyga> just creating the overlord is enough, then that adds the interface manager, that does the rest
<zyga> I tested this with a printf next to AddBackend in the interface manager initialization function
<zyga> (printing each security backend being added)
<pedronis> zyga: it creates only a Mock overlord
<pedronis> we do that all over tha place
<pedronis> so we need to know because there might be more
<zyga> Mock is safe
<zyga> let me double check
<pedronis> I don't see a overlord.New there
<pedronis> but maybe I'm missing something
<pedronis> zyga: I'm talking devicestate_test.go to be clear
<pedronis> firstboot_test.go does create a full overlord
<zyga> testing...
<zyga> and I think you are correct, perhaps I did one too many :)
<zyga> I can drop that
<zyga> pushed
<pedronis> looking in a sec
<zyga> into the master version of the PR
<zyga> devicestate tests are slooow
<pedronis> zyga: :)
<zyga> 25 seconds on a 12 core VM
<pedronis> they got worse then
<pedronis> anyway not a priority to improve that
<zyga> pushed into 2.36 PR as well
<pedronis> right now
<pedronis> they take 4s here
<pedronis> btw
<zyga> PASS: devicestate_test.go:899: deviceMgrSuite.TestDoRequestSerialErrorsOnNoHost	20.213s
<zyga> maye OS differences matter?
<pedronis> no, network setup/dns resolution
<pedronis> differences
<zyga> yep
<mup> PR snapd#6161 closed: tests: new test suite to run snapd tests on a google remote instance <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6161>
<zyga> mvo: any luck?
<zyga> https://github.com/snapcore/snapd/pull/6228 is green btw
<mup> PR #6228: snapstate,overlord: update fontconfig caches with overlord mocking (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6228>
<pedronis> zyga: +1, need a 2nd review for master changes, also agree with mvo how land it in 2.36, will we get conflicts now?
<zyga> pedronis: not likely
<zyga> pedronis: the patches are the same
<zyga> in any case, we can manage if some conflicts happen
<zyga> I have a fix for the leap issue
<zyga> mvo: I added a new apparmor level
<zyga> ancient
<zyga> when level is ancient, we don't enable the apparmor backend
<zyga> when the parser has insufficient features to compile our basic profiles I return ancient
<zyga> (using the existing parser feature check)
<zyga> this makes leap 43.2 work
<zyga> on TW all is good, as is on 16.04
<zyga> parser feature check is not version based, we actually try to use the parseer
<zyga> so this feels like a good way to fix this
<zyga> I'll clean up the code slightly, add tests and propose
<mvo> zyga: no luck yet, one full run worked
<mvo> zyga: second run is ongoing
<zyga> :/
<zyga> but at least we're crawling out of the 2.36 hole
<seb128> pstolowski, hey, unsure bug #1754345 should have been closed, it was an understood problem/assigned and an user states he's still having the issue, could you reconsider?
<mup> Bug #1754345: Returns "invalid credentials" error while trying to refresh an invalid macaroon <snapd:Invalid by chipaca> <https://launchpad.net/bugs/1754345>
<pedronis> zyga: pstolowski: mborzecki: btw both mvo and me have a bunch of meetings today so won't make the standup
<zyga> pedronis: ack
<mborzecki> ack
<zyga> brace, the meetings are coming :)
<pstolowski> seb128: sure, looking
<seb128> pstolowski, thx
<pstolowski> seb128: right, re-opened, thanks; i didn't see the new comment yet
<mup> PR snapd#6229 opened: release: probe apparmor features lazily <Created by zyga> <https://github.com/snapcore/snapd/pull/6229>
<seb128> pstolowski, thx
<zyga> mvo: 1st of the several branches that lead towards leap fix: https://github.com/snapcore/snapd/pull/6229
<mup> PR #6229: release: probe apparmor features lazily <Created by zyga> <https://github.com/snapcore/snapd/pull/6229>
<zyga> pstolowski, mborzecki ^ if you can
<mborzecki> zyga: looking
<zyga> for context: we load apparmor even when it's kernel features are sane but userspace is too old,
<zyga> this is the first of that sequence: the next is caching of parser feature check, the last is introduction of the "ancient" apparmor "level" (level is how we classify apparmor) and usage of that level when parser doesn't have the feature we need
<zyga> decided to split because smaller patches and we can see if something falls apart
<mborzecki> zyga: lgtm, not that the user can switch off secrity=apparmor at runtime
<zyga> yep
<zyga> that's handled
<zyga> :)
<zyga> (when you do that apparmor fs is not mounted)
<zyga> and we treat it as apparmor none
<mborzecki> that selinux uhh, funny how all the information is scattered everywhere, i'm sure ther's like a handfull of people who know their way around it
<zyga> mborzecki: laughing their way to the bank ;)
<zyga> mvo: what do you want to do about 6228
<zyga> merge it or drop it?
<zyga> brb, more tea, it's still freezing in here
<mborzecki> i had this nice split into snapd, helpers with specific types, separate for snap-{update,discard}-ns, s-c and cli tools snap{,ctl} but was getting EACCESS when snapd (snappy_t domain) tried to run s-u-n (snappy_mount_t domain), even though i seemigly had all the stuff set up properly (which apparenly i didn't)
<pstolowski> zyga: looking
<mvo> zyga: woah, its green now 6228 - thats so strange
<mvo> zyga: I run it again, just to see what happens
<zyga> mvo: backends were messing up the system
<zyga> note
<zyga> mvo: when backends were paritally mocked
<mvo> zyga: well, maybe
<mvo> zyga: but how?
<zyga> e.g. not disabled
<mvo> zyga: I mean, I get the theory
<zyga> but not mocking commands
<zyga> and spread runs unit tests as root
<zyga> things really affect the system
<zyga> and silly tests that fake installs core
<mvo> zyga: yeah, but rootdir is set to something different
<zyga> mmmm
<zyga> yeah
<zyga> that's true
<zyga> well
<zyga> ish
<mvo> zyga: I mean, I want to believe
<zyga> it may be set to whatever
<zyga> but if we can call apparmor_parser /path/to/whatever
<zyga> it would still do stuff :)
<mvo> zyga: it will
<zyga> did your overloaded parser command catch any like that?
<mvo> zyga: and yet the file is correct when I get a debug shell, apparmor parser is correct
<mvo> zyga: still no reproducer since the one I showed you earlier
<zyga> what do you have in your tree?
<zyga> as in
<zyga> which patches
 * zyga does it fail on vailla 2.36?
<mvo> zyga: this is run-fontconfig-2.36 with the extra apparmor_parser wrapper
<zyga> aha
<zyga> well
<zyga> magic
<mvo> zyga: I have not tried vanialla
<mvo> zyga: and yes, magic - the bad kind
<zyga> that should trigger it
<zyga> what you have
<zyga> as long as you don't have the mocking patch
<zyga> where backends are nil
<mvo> yeah, I don't have this patch
<xnox> mvo, has i broken systemd in disco on arm64... or? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/arm64/s/snapd/20181127_120551_2b149@/log.gz
<xnox> 2018-11-27 11:33:48 Error executing autopkgtest:ubuntu-19.04-arm64:tests/main/interfaces-daemon-notify :
<xnox> -----
<xnox> also lots of apparmor denials
<xnox> [Tue Nov 27 11:33:26 2018] audit: type=1400 audit(1543318407.221:18418): apparmor="DENIED" operation="exec" profile="snap.test-snapd-daemon-notify.notify" name="/bin/systemd-notify" pid=4946 comm="notify" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<xnox> [Tue Nov 27 11:33:26 2018] audit: type=1400 audit(1543318407.229:18419): apparmor="DENIED" operation="open" profile="snap.test-snapd-daemon-notify.notify" name="/bin/systemd-notify" pid=4946 comm="notify" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<xnox> [Tue
<mvo> zyga: I think you are right, something in this test is bleeding into the others but there are some holes still I think
<zyga> mvo: perhaps we should not run unit tests as root :)
<mvo> xnox: thanks, I need to look at this
<zyga> in case they are less unit-y
<zyga> call them
<zyga> practical tests
<mvo> zyga: iirc they run with some su -l call, let me look
<zyga> practical detonation tests
<zyga> in the spread task?
<zyga> I didn't check
<mvo> zyga: they run as user "test"
<zyga> uh
<zyga> ok
<zyga> so that theory goes out the window
<zyga> how about package build
<zyga> do we do nocheck?
<mvo> zyga: at least the ones in tests/unit/go
<mvo> zyga: yeah, let me check package build
<mvo> zyga: dpkg-buildpackage is also run with su test and fakeroot
<zyga> ok, so all theories are out the window
<zyga> feels like if we don't find this
<zyga> it will just come back :)
<mvo> zyga: yeah, its very strange
<mvo> zyga: anyway, a shame, I really liked the theory :(
 * mvo weeps a bit in the corner
<zyga> mvo: can you ack https://github.com/snapcore/snapd/pull/6227 please
<mup> PR #6227: overlord,daemon: mock security backends for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/6227>
<zyga> mborzecki: can you please look at https://github.com/snapcore/snapd/pull/6149 after the standup
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> it's the next part of the feature branches
<zyga> holly molly
<zyga> mvo: noooooooo
<zyga> :D
<zyga> https://api.travis-ci.org/v3/job/460760408/log.txt
<zyga> https://www.irccloud.com/pastebin/oxArPCqx/
<zyga> this is from https://github.com/snapcore/snapd/pull/6226
<mup> PR #6226: overlord,daemon: mock security backends for testing (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6226>
<zyga> mvo: again failed on 16.04 only
<zyga> mvo: my take on this is that there are multiple things happing in parallel: the backends doing stuff turned out to be a fluke (they just affect the unit tests), the ignored error in setup is interesting and I would like to focus on reproducing that problem with the panic issue out of the way
<zyga> mvo: I added a restore-each check for "signal: terminated"
<zyga> fingers crossed (if that happens)
<zyga> using the same seed that was in the failing log
<zyga> wow, hit the problem instantly
<zyga> looking
<zyga> ooooooooh
<zyga> mvo: THEORY :)
<zyga> 2018-11-28T14:18:10Z INFO Requested daemon restart.
<mvo> zyga: tell me
<mvo> zyga: termintaes as part of daemon restart?
<zyga> yes
<zyga> checking
<zyga> hold on
<zyga> mvo:
<zyga> wowoooow
<zyga> Nov 28 14:18:44 nov281411-886866 snapd[29935]: helpers.go:187: cannot regenerate seccomp profile for snap "core": signal: terminated
<zyga> look what this says
<mvo> zyga: nice, can't wait (and I'm in a meeting)
<zyga> snap-seccomp
<zyga> 14:18
<mvo> zyga: ohhh
<zyga> this is not even apparmor
<mvo> zyga: nice
<zyga> it's any child
<mvo> zyga: so a missing wait somewhere? when we shut down/restart?
<mvo> zyga: nice!
<mvo> zyga: nice nice nice
<zyga> probably
<zyga> but man
<zyga> looking at timing logs
<mvo> zyga: also means we had this forever
<zyga> yes
<mvo> zyga: we just now notice because the profile actually changed
<mvo> zyga: so far all the bits fit :)
<zyga> https://github.com/snapcore/snapd/pull/6230
<mup> PR snapd#6230 opened: spread: detect "signal: terminated" in journal logs <Created by zyga> <https://github.com/snapcore/snapd/pull/6230>
<mup> PR #6230: spread: detect "signal: terminated" in journal logs <Created by zyga> <https://github.com/snapcore/snapd/pull/6230>
<zyga> need to run for lunch
<zyga> but so far best theory
<zyga> and man, we suck :)
<mvo> zyga: !!!
 * mvo hugs zyga 
<pstolowski>  /o\
<zyga> mvo: is it that fix for daemon shutdown that [c]ipaca did?
<zyga> I'll try
 * cachio going to the bank
<cachio> and lunch
<mvo> zyga: as a quick test - we can set KillMode=process and see if that helps
<mvo> zyga: I bet it does
<zyga> mvo: better, I'll cherry pick the two patches from chipaca that fix it
<zyga> it's super easy to trigger now
<zyga> with that journalctl check
<mup> PR snapd#6228 closed: snapstate,overlord: update fontconfig caches with overlord mocking (2.36) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6228>
<zyga> mvo: running now
<mvo> zyga: cool, let me know
<zyga> fingers very much croessed
<zyga> *crossed
<mvo> zyga: hopefully the fix from chipaca is enough
<zyga> mvo: I will look at what happens in the daemon restart sequence now
<mup> PR snapd#6231 opened: data: set KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/6231>
<zyga> thanks for that ^ mvo
<zyga> feels like attacking many fronts at the same time yields results
<mvo> zyga: the critical bit is that we can't stop the daemon before all the subprocesses are finished
<mvo> zyga: or we need Killmode=process
<zyga> mvo: are you out of the meeting spree?
<zyga> can you review https://github.com/snapcore/snapd/pull/6227
<mup> PR #6227: overlord,daemon: mock security backends for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/6227>
<mvo> zyga: yeah, we are doing a pincer move on this (remember Cannae) - anyway, still meeting so only 1/4 brain available
<zyga> running, no failures yet
<mvo> zyga: the one from john?
<zyga> yes
<mvo> zyga: that is definitely the best solution if that is enough - yay^2
<zyga> I took two patches from john and kept my journalctl test
<zyga> yes :)
<mvo> zyga: please propose to 2.36
<zyga> absolutely will
<zyga> if this passes
<mvo> zyga: than hopefully when the meetings are over I can merge and get on with life
<mvo> zyga: thank you!
<zyga> thank you
<zyga> for 2.36.2 I would like to fix leap too, so if time permits I will try
<zyga> 2.36.2 is tomorrow?
<mvo> zyga: or later tonight
<zyga> ok
<zyga> can be tonight
<zyga> I mean, I have the patches now
<mvo> zyga: I would rather do a .3 than to wait tbh
<zyga> ok
<zyga> I can distro patch too
<mvo> zyga: I think its fine, we can do .3 with --trace-exec
<mvo> zyga: and your fix
<zyga> ok
<mvo> zyga: etc
<zyga> let's do .2 today if we can
<mvo> zyga: but yeah, depends on how long tests take and all that
<zyga> and .3 tomorrow with extra leap fix
<zyga> (leap is not critical since it doesn't break the use of apps)
<mvo> zyga: so including it is not off the chart, just that I would not want to wait for it
<zyga> I agree
<zyga> 40/364, no errors in sight
<mvo> zyga: hurrazh!
<mvo> zyga: I close the KillMode=process then
<mvo> zyga: at least for now
<zyga> keep it
<zyga> let's see what happens
<mvo> zyga: you think so? ok
<zyga> mvo: nooo, broke again
<zyga> looking
<zyga> Nov 28 15:07:08 nov281459-174393 snapd[30000]: helpers.go:187: cannot regenerate seccomp profile for snap "core": signal: terminated
<zyga> I find this part interesting:
<zyga> https://www.irccloud.com/pastebin/WYfAENsz/
<zyga> they always come in pairs, first this then the message that we're ready to go, in deamon
<zyga> so it must be the profile regen code
<mvo> zyga: lets see if KillMode= helps
<zyga> journald logs: http://paste.ubuntu.com/p/hv8y3mgQJF/
<zyga> Nov 28 15:06:18 nov281459-174393 snapd[29138]: main.go:82: DEBUG: Setting up sd_notify() watchdog timer every 2m30s
<zyga> sooooo
<zyga> theory
<zyga> we start up
<zyga> shit takes time
<zyga> systemd says "bye dude" and kills us
<zyga> I once told maciej that during startup
<zyga> when we regen profiles
<zyga> we should tell systemd "gimme more time"
<zyga> otherwise watchdog
<zyga> may
<zyga> may kill us on a slow system
<zyga> viable?
<zyga> http://paste.ubuntu.com/p/Bp9jBsjN3S/ <- complete journal logs
<zyga> so
<zyga> I don't get it
<zyga> look at that 2nd log please
<zyga> go to line 1272
<zyga> we just installed core rev 6022
<zyga> on line 1280 we restart
<mvo> zyga: still meeting will look in a wee bit
<zyga> now comes up something weird
<zyga> we do a bit of restarts
<zyga> one after another
<zyga> (sure, I'm just letting my mind flow)
<cwayne> Wow when did mvo become Scottish
<zyga> it's double plus interesting that the test this failed on is main/degraded
<mvo> zyga: oh, interessting - we could disable the watchdog to test this theory
<zyga> i.e. nothing special
<zyga> yep, I'll try that in a moment
<mvo> cwayne: haha - I think I read too much terry pratchett
<zyga> we restart about a half a dozen times
<zyga> and what's with CUPS and ACPI being restarted
<zyga> are we doing something wrong in test prep?
<zyga> mvo: I don't think this is the watchdog
<zyga> there's just one snap installed, core
<zyga> would not take that long
<zyga> on line 1375 test helpers say "new test starts here"
<zyga> going to look what prints that
<mvo> zyga: lets have a quick HO to catchup after my meeting(s)
<zyga> gladly
<zyga> I'm out of ideas
<zyga> looking at your kill mode branch
<mvo> zyga: it is running and still going strong afaict
<mvo> zyga: so fingers crossed, I have a theory that I would like to talk through (to see if it is really cohesive)
<zyga> list of jobs that failed with "signal: terminated" present in the log https://www.irccloud.com/pastebin/ZQikNO6z/
<zyga> I wonder if this list is stable
<zyga> I wonder if there's a combination of test activity and something else
<zyga> your killmode branch seems to suggest that systemd stops snapd
<zyga> and things go south because children die too
<zyga> question is why
<zyga> why are we being stopped
<zyga> or more precisely: why this happens this way
<zyga> mvo: one more idea to fix this
<zyga> mvo: in regen all profiles code path, when anything fails, we don't write system key
<mvo> zyga: systemd
<zyga> then next time we try again
<mvo> zyga: oh, interessting
<zyga> yes, systemd but why :-)
<zyga> yep
<zyga> I'll make coffee
<zyga> when will your meetings finish?
<mvo> zyga: yeah, lets tlak in the HO
<mvo> zyga: in 5-20min
<zyga> ok
<zyga> I'll take a break now
<mvo> zyga: sounds great
<zyga> see you in 15
<mvo> zyga: I have a theory
<mvo> zyga: so don't worry - and poke holes into it once we talk :)
<zyga> back
<mvo> zyga: let me make a cup of tea, meeting is over, ready in 3min
<zyga> ok
<zyga> started another run with:
<zyga> chipaca's patches
<zyga> terminated detector
<zyga> propagated error from snap-confine apparmor setup
<zyga> and system-key write skip if something fails
<zyga> let's see what we get now
<pedronis> zyga: mvo: let me know if I can help, want to discuss, I need a short break now tough
<zyga> k
<pedronis> mvo: is the fontconfig stuff expected in #6231?
<mup> PR #6231: data: set KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/6231>
<mvo> pedronis: yes, lets set this to blocked
<mvo> pedronis: its an experiment to see if that fixes the issue in the test
<mvo> s
<Mmike> Hi, lads. Can't snaps run in lxc containers?  I've created a fresh, empty container (lxc launch ubuntu:16.04 xen-snaptest), when it started I added my ssh key to ubuntu user (lxc exec xen-snaptest), sshed into the container, did apt update/upgrade mantra, then did: snap install hello. Snap installed, but when I try to run 'hello' command, this is what I get:
<Mmike> ubuntu@xen-test:~$ hello
<Mmike> cannot remount /tmp/snap.rootfs_z1wdjU/var/lib/snapd/lib/vulkan as read-only: Permission denied
<Mmike> my container is unprivileged
<Mmike> at least the lxd docs say defaults are unpriv containers, and also I can see that /proc inside the container is owned by nobody.nogroup
<mup> PR snapd#6232 opened: overlord/snapstate: support for pre-remove hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/6232>
<pedronis> mvo: zyga: so we are getting killed why running subprocesses?
<pedronis> but we don't know what is killing us?
<pedronis> s/why/while/
<zyga> pedronis: hey
<zyga> can you join the standup please
<zyga> it will be easier to explain this way
<mvo> zyga: and remember to listen to the free software song
<zyga> mvo: systemd uses kill(pid, SIGTERM)
<zyga> mvo: not -pid
<zyga> (sorry, I didn't mean to say -SIGTERM earier)
<zyga> I will nuke system key and see what happens during a restart
<mvo> zyga: hm, does it send SIGERM to anything else, i.e. a running snap-seccomp or similar?
<zyga> mvo: going through the log now
<mup> PR snapd#6183 closed: sanity, spread, tests: add CentOS (2.36) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6183>
<mvo> 6195 and 6218 need a second review
 * mvo gets dinner while waiting for this
<zyga> mvo: this is what happens:
<zyga> systemd killing everything in a cgroup https://www.irccloud.com/pastebin/2TpqMTd7/
<zyga> immediately after that there's a second loop that ensures the cgroup is now empty
<zyga> mvo: that's settled
<zyga> but one thing still bugs me
<zyga> if we only tell systemd that we are ready after we are done starting the overlord
<zyga> how can we ever be killed mid way?
<zyga> are we not telling systemd about our readiness on 16.04?
<zyga> on 14.04 we are type=notify
<zyga> I wonder if this means we still don't fully know how this happens
<zyga> mvo: forkstat debugging  https://www.irccloud.com/pastebin/yeeIBEmw/
<zyga> just to put my mind at ease
<zyga> mvo: ^ this is actually a pretty amazing way to see what was going on around each test
<zyga> and have historical data if it fails
<zyga> small digression about our lives: https://youtu.be/sTdWQAKzESA
<zyga> eh, forkstat -l is too new
<roadmr> hi jdstrand !
<Saviq> cachio: hey, are you guys testing on Fedora rawhide? or plan to?
<zyga> Saviq: not testing now
<zyga> Saviq: planning to is hard to say
<Saviq> what I'm really asking is how to reliably get a rawhide env on spread+google... but I suppose that answers that ;)
<zyga> I'll let cachio answer that :)
<Saviq> we're trying to upgrade from the latest image available, but that misses the "reliable" bit
<zyga> Nov 28 18:05:08 nov281757-030500 snapd[30252]: helpers.go:192: cannot regenerate seccomp profile for snap "core": signal: terminated
<zyga> http://paste.ubuntu.com/p/4X5KvfZB7W/ < forkstat
<zyga> mvo: ^
<zyga> mvo: this forkstat stuff may also help maciej with systemd / mount error
<zyga> e.g. would you guess we are calling probe-bcache on all those snaps?
<zyga> 18:05:08 exit  30278     15    2.510 /snap/core/6022/usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.core.hook.configure.src /var/lib/snapd/seccomp/bpf/snap.core.hook.configure.bin
<zyga> this is snap-seccomp existing after SIGTERM
<zyga> mvo: there are some more details here
<zyga> mvo: anyway, ping if you are around
<zyga> otherwise let's chat later
<zyga> mvo: we should look at this tomorrow
<zyga> it seems that snapd was running long before
<zyga> mvo: tracing the snap-seccomp that was stopped
<mvo> zyga: hm?
<zyga> hey
<zyga> if you want please look at the pastebin above
<mvo> zyga: looking
<zyga> find the line where snap-seccomp process 30278 is killed
<zyga> then look back in time
<zyga> to see when it is started
<zyga> one thing that doesn't make sense in the current theory
<zyga> is that "systemctl restart snapd.service"
<zyga> that will _wait_ until security is setup, right?
<mvo> zyga: I'm not sure
<mvo> zyga: I think we need to look at systemd and read how it behaves for things not fully started up
<zyga> in general, it waits until the service is ready
<zyga> my point is that if we had started snapd  in the past
<zyga> it has completed the setup op
<zyga> what we're observing is disagreeing with that
<zyga> it seems that when we ask snapd to restart (from a synchronously running shell script)
<zyga> it is still starting up
<zyga> I don't know how to explain that
<zyga> apart from my misunderstanding of systemd
<zyga> but snapd.service is service type "notify"
<zyga> anyway, look at the log, at the branch
<zyga> you can reproduce the failure yourself
<zyga> and look at both forkstat data
<zyga> and at journal
<zyga> I think this is very very useful in general, for debugging all sort of issues
<mvo> zyga: hm, hm, I see
<zyga> did I share the seed?
<mvo> zyga: I don't see in the forkstat when a process dies and why - or am I looking at the wrong thing?
<zyga> mvo: spread -debug -v -seed=1543419805 google:ubuntu-16.04-64:
<zyga> you are not looking right
<zyga> look at the output above:
<zyga> 18:05:08 exit  30278     15    2.510 /snap/core/6022/usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.core.hook.configure.src /var/lib/snapd/seccomp/bpf/snap.core.hook.configure.bin
<zyga> this tells you that on 18:05:08 a process with pid 30278 exited due to signal 15
<zyga> taking 2.510 seconds of execution time
<zyga> you can now look in past for pid 30278
<zyga> you will find when the process was launched
<mvo> zyga: aha, nice
<mvo> zyga: sorry, just not used to ready it
<zyga> yeah
<mvo> zyga: uh, just looking at daemon.go - we set READY=1 in Start() so maybe we do it too early
<zyga> took me some time to figure it out
<zyga> oooh
<zyga> yeah
<zyga> definitely!
<zyga> actually
<zyga> let me look :D
<zyga> I think I'm easily excited
<mvo> zyga: ahahahaha
<mvo> zyga: well, looking now as well where exactly the security setup happens
<zyga> security setup happens in overlord.New
<zyga> it's all packed there
<zyga> but
<zyga> maybe
<zyga> what I'm missing is that some of it runs in a goroutine?
<zyga> but probably not
<zyga> mvo: if you follow overlord.New you will get to ifacestate.Manager()
<zyga> that follows to m.initialize
<zyga> and that to m.regenerateAllSecurityProfiles
<zyga> one possible alternative is that there was a real refresh
<zyga> but not sure that's even possible
<mvo> zyga: hm, indeed
<zyga> one thing for sure: forkstat == invaluable for corelating logs and activity
<zyga> we can look at snap changes, journal and forkstat
<zyga> and see what happens
<zyga> I won't get to the bottom of this tonight but we have all the means to conclusively say what the issue is
<zyga> mvo: as for systemd killing processes
<zyga> it seems to just read the cgroup .procs file
<zyga> and kill one by one
<zyga> not the parent
<zyga> I would love to cross check that with code and docs
<zyga> I have not yet
<zyga> that's from my strace'ing session
<pedronis> zyga: there shouldn't be snapd own goroutines going (except the watchdog one) until inside start I think
<pedronis> Start
<zyga> mmm
<zyga> interface manager doesn't have any ensure logic that would do security setup
<zyga> unless hotplug and autoconnect are considered
<pedronis> ?
<zyga> I meant that if there are no things going on in the background outside of the state manager then this must be synchronously running from overlord.New
<mvo> zyga: do you have a current jounalctl -u snapd log?
<zyga> er, I did but I closed the session
<pedronis> zyga: that's also what I said
<zyga> I can restart and give you one in a moment
<zyga> pedronis: then we are in agreement and this suggests that snapd was stopped while it was still starting
<mvo> zyga: just curious what we see there (e.g. snapd starting and then the error right after that)
<zyga> mvo: started now
<zyga> I will pastebin the three logs when I have them
<pedronis> zyga: but regenerateAllSecurityProfiles is called by initialize
<pedronis> and does security setup, no?
<zyga> yed
<zyga> *yes it does
<pedronis> that's the bit I was confused
<zyga> it's on the direct call path from overlord.New
<pedronis> yes
<pedronis> anyway no Ensure is called before do Loop in Start
<cachio> Saviq, we dont test on rawhide
<zyga> hmm, overlord.Start is called and then we tell systemd we're ready
<zyga> I'm sorry, I meant overlord.Loop
<pedronis> yes
<cachio> Saviq, so far we test on f28
<cachio> Saviq, and we are gonna test on f29 soon
<cachio> Saviq, no plans for rawhide, why?
<Saviq> cachio: we're ~testing Mir on rawhide, was wondering if you have a reliable solution
<Saviq> so we're upgrading from f28 to rawhide in spread, but that's not really reliable...
<zyga> mvo: got it
<zyga> mvo: Nov 28 18:55:03 nov281847-525365 snapd[30231]: helpers.go:192: cannot regenerate seccomp profile for snap "core": signal: terminated
<zyga> mvo: forkstat http://paste.ubuntu.com/p/DqmTPympC6/
<zyga> mvo: journal http://paste.ubuntu.com/p/4h9gcyWHCH/
<zyga> mvo: snap changes http://paste.ubuntu.com/p/snbqrwBXMW/
<cachio> Saviq, still not testing on f29
<cachio> Saviq, this it blocking that https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394
<cachio> Saviq, I'll let you know if there is a plan to test on rawhide
<zyga> mvo: (phone)
<zyga> mvo: if you are looking at this
<zyga> mvo: I would love to understand the origin of the restart frenzy from 18:54:58 toll 18:55:02
<cachio> Saviq, do you need an image of f rawhide?
<Saviq> cachio: if it's not any trouble :)
<cachio> Saviq, I'll create it today
<cachio> I'll ping you once it is ready
<mvo> zyga: sorry, was distracted as well - maybe we should add a debug.log() before READY=1
<pedronis> mvo: I gave my +1 to #6185, needs a full 2nd review, and there are already some interesting comments there from other reviewers
<mup> PR #6185: snap: add new `snap run --trace-exec` call <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6185>
<mvo> pedronis: thank you. yeah, second review for fontconfig needed
<mvo> pedronis: I will look at the comments from pawel in the morning
<zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/6227
<mup> PR #6227: overlord,daemon: mock security backends for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/6227>
<zyga> I'd love to shrink the number of PRs
<mup> PR snapd#6227 closed: overlord,daemon: mock security backends for testing <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6227>
<mup> PR snapd#6226 closed: overlord,daemon: mock security backends for testing (2.36) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6226>
<zyga> thanks
<mup> PR snapd#6229 closed: release: probe apparmor features lazily <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6229>
<mvo> zyga: thank *you*
<zyga> I'll prepare that final small PR with system key behavior
<mvo> zyga: 6195 needs a second review
<zyga> aha
<zyga> looking
<pedronis> mvo: zyga: I think I reviewed the pending things for 2.36 blocking a .2 right?
<zyga> AFAIK yes
<mvo> pedronis: yeah, I think we are good
<pedronis> zyga: mvo: thanks for chasing these issues btw
 * pedronis goes a bit afk
<mvo> pedronis: thank you, yeah, happy that we found the issue. enjoy the evening
 * mvo also needs to be afk
<zyga> pushed the syskey handling change
<mup> PR snapd#6233 opened: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<mup> PR snapd#6234 opened: overlord: don't write system key if security setup fails (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6234>
<zyga> I will add unit tests tomorrow, it's far too late anyway
<zyga> ttyl!
<mup> PR snapd#6235 opened: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
 * roadmr repings jdstrand
<jdstrand> roadmr: sorry, still going through backscroll from being off. what's up?
<roadmr> jdstrand: wanted to ask! is it possible to make a plug in one snap automagically connect to another snap's slot? I know the IDs of both snaps.
<jdstrand> roadmr: yes
<roadmr> \o/ jdstrand how would I go about it? I'm happy to study existing examples if you point me to some
<zyga> hey jdstrand, long time no see
<jdstrand> zyga: hey, yeah
#snappy 2018-11-29
<cachio> Saviq, hey, please try the image fedora-rawhide-64, tomorrow I'll ping you
<mborzecki> morning
<zyga> Hi
<zyga> Some late night pull requests
<zyga> With green 2.36
<zyga> :-)
<mborzecki> heh :) went to a meetup yday, then i stayed until midnight making that damn selinux work, audit actually showed some interesting behavior by journald poking some attributes in /proc all the time
<zyga> Cool, looking forward to that
<zyga> My son is 1/3rd my age today
<zyga> Feeling old or young? :-)
<zyga> re
<zyga> mborzecki: hey
<zyga> so today we will try to stabilize 2.36 and merge the bits back into master
<zyga> mborzecki: this is part of the issue https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<zyga> mborzecki: this is a more complete view but as you will see there it cannot land just yet https://github.com/snapcore/snapd/pull/6235
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> each commit has some description that explains what was going on
<zyga> Chipaca: good morning sir!
<zyga> I need to run an errand in the morning (wife doctor checkup) but I will be back as soon as I can
<Chipaca> zyga: goodmorning
 * Chipaca not legally awake yet
<mup> PR snapd#6236 opened: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
<zyga> Hey mvo
<zyga> Iâm afk on the way to a doctor with my wife (all is good, no worries)
<zyga> I sent some PRs last night
<zyga> Please have a look
<mvo> zyga: cool
<mvo> zyga: thanks, I check the PRs
<zyga> If you have time I would love more eyes on the trio of pastebins from yesterday
<zyga> To be confident we understand how things happen
<zyga> After I am back I will post leap fixes
<zyga> Together this will fix 2.36 as we understand it so far
<mvo> zyga: great
<pedronis> zyga: I asked a question in one of them
<pstolowski> morning
<mvo> hey pstolowski
<zyga> pedronis: replied now
<zyga> Actually
<zyga> Hmmm
<zyga> More problematic
<zyga> Oh boy :-)
<zyga> Something to think about
<pedronis> zyga: I thought we already added the waiting to snap-confine, is that false?
<zyga> No system key, no snap run
<mvo> pedronis: thanks for adding the todo to 6195
<zyga> Iâm afk partially sorry for laggy replies
<pedronis> zyga: ?
<pedronis> I thought we did something saner
<zyga> Iâm not at home, doctor visit with wife
<pedronis> zyga: ok, let' chat later
<pedronis> mvo: do you know what snap-confine does if there's no system-key? I thought it would wait a while
<mvo> pedronis: it will wait a while, do you see something different?
<mvo> pedronis: it should try to talk to snapd in this case
<zyga> This is really about a restart case
<pedronis> zyga: is saying something else
<zyga> So we error because we are restarting
<zyga> It will be fixed by next startup
<pedronis> ?
<pedronis> error where
<pedronis> something sounds wrong
<pedronis> is snap-confine assuming that snapd runs all the time
<pedronis> that's a bit optimistic
<mvo> pedronis: well, we had a long discussion abut this when we introduced the system key
<pedronis> mvo: I mean  if snap-confine needs to wait and can't talk to snapd it should wait a bit more and try again, no?
<mvo> pedronis: I can look in a bit for the details, I think we wrote it down. at least gustavo and me, don't remember if you were part of it
<zyga> I can hop on a voice call if you want to discuss this in detail
<pedronis> until some timeout
<mvo> pedronis: yes, thats correct
<pedronis> is it simply dying if snapd is not there
<pedronis> ?
<mvo> pedronis: is this not what you see?
<zyga> That is what currently happens
<mvo> pedronis: no, it should not
<mvo> zyga: oh?
<zyga> It waits
<zyga> And then might die if something required is missing
<zyga> AFAIK
<mvo> I am just trying this
<mvo> it definitely waits
<pedronis> then is as designed, no?
<pedronis> I mean, I don't expect this to work 100%
<zyga> Yes
<zyga> I think this is as designed
<pedronis> it should not fail on boot 100%
<mvo> and when I start snapd again it will continue
<pedronis> either
<pedronis> we might have a problem in that
<pedronis> the timeout might be shorter than it takes to regen all security if lots of snaps ?
<zyga> Yes
<mvo> yes, that could be a problem :(
<pedronis> is not a problem for today tough
<pedronis> but zyga scared a bit, like snap-confine would not to do what I remember was designed to do
<mvo> it waits 60s right now
<mvo> pedronis, zyga let me try this
<Chipaca> what were we calling the feature where we'd delay a snap refresh until the app was closed?
<mvo> 6195 still needs a second review
<zyga> I think it is not perfect but as designed
<pedronis> as I said I don't expect perfect (kind of impossible given the constraints), we might have to improve over time in some corners
<pedronis> but for a second it sounded like it was broken
<zyga> I was scared :-)
<mvo> hm, it seems to error when it hits the timeout - iirc we wanted it to continue (best effort) - yes?
<pedronis> Chipaca: we call it "Prevent refreshes while running"
<pedronis> at least that's the name of the day
<Chipaca> pedronis: is there a forum topic about it?
<Chipaca> asking because https://forum.snapcraft.io/t/concerns-about-consistency-and-data-corruption-during-snap-refresh/8741
<pedronis> yea, I saw that one
<Chipaca> if there isn't, i'll just reply vaguely
<Chipaca> :-)
<pedronis> Chipaca: I don't see one, is mentioned in the last sprint topics but not as a discussed one
<pedronis> anyway is planned for the cycle
<Chipaca> pedronis: https://forum.snapcraft.io/t/concerns-about-consistency-and-data-corruption-during-snap-refresh/8741/2?u=chipaca
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> mvo: #6195 gtg fwiw
<mup> PR #6195: snapstate: update fontconfig caches on install <Created by mvo5> <https://github.com/snapcore/snapd/pull/6195>
<pedronis> Chipaca: thx
 * Chipaca wanders off in search of coffee
<zyga> I could use some too
<zyga> Waiting for blood tests now
 * mvo gets some lovely tea
<zyga> Iâm happy nobody mentioned nutrient breakfast yet
<Chipaca> mvo: I saw somebody using "material tea timer" and thought you might like it (if you didn't have it already)
<Chipaca> mvo: https://play.google.com/store/apps/details?id=org.ligi.materialteatimer
<mvo> Chipaca: nice!
<mvo> Chipaca: I don't have it, I use the boring clock app
<mvo> Chipaca: but this even has nice pics (teap0rn)
<Chipaca> mvo: and it's FOSS
<mvo> \o/
<mup> PR snapd#6195 closed: snapstate: update fontconfig caches on install <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6195>
<mup> PR snapd#6218 closed:  snapstate: update fontconfig caches on install (2.36) <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6218>
<dot-tobias> good morning
<zyga> Hey dot-tobias
<mborzecki> hm finnally, clean installation, no denials, ending up with this: system_u:system_r:unconfined_service_t:s0 root 11016 1  0 09:11 ?      00:00:00 /bin/sh /snap/test-snapd-service/x1/bin/start
<mup> PR snapd#6237 opened: client, store: don't use store from client (use client from store) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6237>
<zyga> Breakfast time
 * Chipaca joins zyga
 * Chipaca thinks hobbits had the right of it
<zyga> Haga
<zyga> Haha, yes :-)
<mup> PR snapd#6189 closed: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6189>
<mup> PR snapd#6238 opened: [RFC] many: add minimal SELinux support, refactor the policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
<mborzecki> putting selinux aside for while now
<mborzecki> any PRs needing 2nd reviews?
<Son_Goku> mborzecki, you are literally my best friend right now!
<Son_Goku> you have _no_ idea how happy I am to see this pull request!
<mborzecki> Son_Goku: haha :) yw, would appreciate if you could find someone more familiar with this stuff to take a look at the policy
 * Son_Goku dances in joy
 * zyga goes to sob in the corner
<zyga> :-)
<Son_Goku> zyga, this is something I've been asking for two years for!
<zyga> Heading home ttyl
<Son_Goku> you can't blame me for being overjoyed :)
<zyga> I know but I donât make the schedule
<mborzecki> Son_Goku: hope i got most of the things right, but figuring out the bits was like uhh
<zyga> Iâm happy to see this too :-)
<Son_Goku> mborzecki, yeah I knew it was going to be like that
<zyga> Beginning of a long journey
<mborzecki> and the docs are few and useless really :P
<Son_Goku> mborzecki, most security subsystems aren't well documented sadly :(
<Son_Goku> I'll see if I can get Lukas from the Fedora SELinux team to do a review
<zyga> Insecurity by security obscurity
<mborzecki> Son_Goku: yeah, unfortunately true
<mborzecki> some to think of it, SMACK is probably more obscure than SELinux and AppArmor
<Son_Goku> yep
<mborzecki> s/some/come/
<Son_Goku> and TOMOYO even more so
<Son_Goku> (TOMOYO is what Mageia has enabled, but no one knows what to do with it)
<mborzecki> hahah
<mborzecki> iirc AGL was supposed to use SMACK
<Son_Goku> yep
<Chipaca> Son_Goku: o/ !
<Son_Goku> Chipaca: \o
<Chipaca> Son_Goku: when you have a moment I'd like to pick you brain a tiny little bit
<zyga> You know
<Son_Goku> Chipaca, I have a moment now
<zyga> Breakfast downtown is fun and fancy
<zyga> Need to do this more often
<mborzecki> zyga: nice, enjoy!
<Son_Goku> mborzecki, and the biggest criticism of SMACK is that it's pretty much functionally identical to a minimal SELinux policy
<Chipaca> Son_Goku: you remember, ages ago, when we talked about tracking what users had used snaps, to enable snap-user-enumeration without having to do system-user-enumeration?
<Son_Goku> Chipaca, yeah? that was what, a year ago at the rally?
<Chipaca> Son_Goku: you objected to that because you said a user's data should be the user's to control,  or something like that?
<Son_Goku> yes
<Chipaca> yeah probably more
<Son_Goku> actually I don't think that was my only objection
<Chipaca> Son_Goku: now we're again looking at things where we need to enumerate users
<Chipaca> Son_Goku: and the same solution comes up, and so I wanted to revisit your objection to it
<Chipaca> to see if I understood it correctly
<Son_Goku> are we talking about ~/snap/* enumeration?
<Son_Goku> or the user population/enumeration for services?
<Chipaca> Son_Goku: "all users that have used snaps"
<Chipaca> Son_Goku: like
<Chipaca> Son_Goku: ls /home/*/snap/* but that's a bad way of doing it
<Son_Goku> right
<zyga> You need a dbus call that does a perl shell call to is
<Son_Goku> this? https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201
<zyga> Ls, darn shell typos
<Son_Goku> Chipaca ^ ?
<mvo> zyga: have you looked at the systemd-run change for the profile generation? if not I can do that while waiting for builds
<Chipaca> Son_Goku: yeh
<Chipaca> Son_Goku: i think that's it
<Son_Goku> my problem was that the proposal as I understood it would break shared setups and make user data private from the user itself
<Chipaca> Son_Goku: that's one bit I don't understand
<Chipaca> Son_Goku: what's the user data that would be private from the user?
<Chipaca> Son_Goku: the proposal is not to move all user data to /var/whatevs
<Son_Goku> well, how I understood it is that data would move from ~/snap to /var/lib/snapd/<userid>/data
<Chipaca> Son_Goku: but to create a stamp file in /var/whatevs "this user used a snap"
<Son_Goku> or something like that
<Son_Goku> Chipaca, my only objection there is that it makes network shared users ugly
<Chipaca> Son_Goku: user data would remain unchanged; all this'd do is that 'snap run' would 'touch /var/lib/snapd/user/$USER' before running the thing
<Chipaca> Son_Goku: how does it make network shared users ugly?
<Chipaca> please expand :-)
<Son_Goku> well, actually, if it's only that and doesn't effect how data "ownership" and migration occurs, then it's not an issue
<Son_Goku> the way it was explained to me at the rally is that we wanted to do "smart things" by doing so
<Son_Goku> for example, automatic cleanup of related user-data if the stamp didn't exist
<Son_Goku> which would be extremely dumb for networked user case
<Chipaca> er, no, that's the opposite of what I'd want to do
<Chipaca> "related user-data" would not be even looked at if the stamp didn't exist
<mup> PR snapd#6239 opened: packaging/fedora/snapd.spec: fix bogus date in changelog <Created by mvo5> <https://github.com/snapcore/snapd/pull/6239>
<mvo> mborzecki: it looks like the selinux pr is failing because libselinux not found on centos afaict
<Chipaca> as you say it breaks for networks, it also means that something is enumerating users from the system, which is a no-no
<mborzecki> mvo: thanks, will look into it
<mvo> mborzecki: really nice progress btw
<Chipaca> Son_Goku: re-reading that topic now to find the cleanup-of-missing thing to address it there
<mborzecki> mvo: thanks, and sorry for not being too responsive for reviews the last couple of days, didn't want to loose context
<Son_Goku> mborzecki, it's because you've disabled libselinux right now
<Son_Goku> mborzecki, you currently have selinux disabled for centos builds
<mvo> mborzecki: no worries
<Son_Goku> oh no, wait, it looks like you've switched it back
<mborzecki> Son_Goku: --enable-selinux is behind %{?with_selinux:..}
<mborzecki> Son_Goku: and the rest is if/endif'ed
<mborzecki> Son_Goku: restored fedora 28 to spread specifically to build it
<mborzecki> omg, with_selinux is always defined :/
<mup> PR snapd#6240 opened: release: 2.36.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6240>
<zyga> mvo: I have not looked yet
<mvo> zyga: ok, I give it a poke
<zyga> Thank you
<mborzecki> hmm selinux doesn't like the fontconfig bits
<Chipaca> Son_Goku: https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201/14?u=chipaca
<Son_Goku> mborzecki, will this work if both apparmor and selinux are available as options (i.e. SUSE distributions?)
<mborzecki> Son_Goku: we'll probably need to disable one, i see that with_selinux is 1 by default
<Son_Goku> well, I'm saying can the integration be compiled in?
<Son_Goku> because there are folks that use SELinux instead of AppArmor on SLED/SLES, for example
<mborzecki> Son_Goku: you can build both and there's a change it'll work out of the box, the libselinux bits do autodetection and so does libapparmor
<Son_Goku> yeah, that's what I was getting at
<mborzecki> Son_Goku: there's always a quesion of refpolicy they use, whether it's the same as fedora
<Son_Goku> RH/Fedora and (open)SUSE use the same upstream: fedora-selinux
<Son_Goku> actually, of all the distros that offer SELinux support, I think only Debian/Ubuntu don't offer the fedora-selinux variant of the policy
<Son_Goku> (and "offer" is a _strong_ word here for Ubuntu... more like didn't purge from Debian impots)
<Son_Goku> *imports
<jamesh> Chipaca: if you've got time, could you have a look at https://github.com/snapcore/snapd/pull/5822 ?
<mup> PR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<mborzecki> Son_Goku: mhm, right so there's a change it'll work :) happy to learn how far it gets though
<Chipaca> jamesh: whoops, yes
<Son_Goku> mvo, niemeyer, I hope mborzecki's PR for selinux makes it in for the next release, this would drastically improve my confidence in shipping snapd for RHEL/CentOS through EPEL
<Son_Goku> I'm actually pretty tempted to not ship until we get this in a release, because this is a *big* improvement across the board
<jamesh> Chipaca: it should be fairly up to date now: I rebased it recently and spread seems happy with it again
<Chipaca> jamesh: ok
<cachio> Saviq, hey, could you try the rawhide image?
<Son_Goku> mborzecki, how is transitioning from older policy rules to the new one?
<Son_Goku> it works okay?
<mborzecki> Son_Goku: haha, don't be, i see some issues on centos alredy, we need to have smarter runtime detectio of whether the policy is present and the latest bits with fontconfig are causing some issues
<Son_Goku> ah
<Son_Goku> mborzecki, well, it would at least mean the confinement _does_ something now :)
<Son_Goku> not great, but it does something
<mborzecki> Son_Goku: it's only confining snapd and helpers
<Son_Goku> but now the framework is in place to confine snaps properly too
<mborzecki> Son_Goku: but there's a path forward i guess at this point
<mborzecki> Son_Goku: at least there are options to explore :)
<Son_Goku> yep
<Son_Goku> now that we have libselinux integration, we can look at things like mapping CIL and snappy policy knobs to the snappy security HLL
<zyga> re
<zyga> mvo: sorry for being absent so long, I'm finally home now
<zyga> mvo: I will start by adding tests to https://github.com/snapcore/snapd/pull/6233
<mvo> zyga: no worries
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<zyga> then resume with leap fixes
<cachio> mvo, hey, I saw 2.36.2 branch has failed
<cachio> 2 tests with same error on configure hooks
<mvo> cachio: failed in spread?
<mvo> cachio: or failed somewhere else?
<cachio> mvo, in spread
<mvo> cachio: I have not looked yet, does the failure look familiar in any way?
<cachio> https://paste.ubuntu.com/p/z7jh7KwJt9/
<cachio> mvo, it is happening on 2.36 family
<cachio> mvo, I am already trying to reproduce it
<zyga> cachio: no  need
<zyga> cachio: this is the problem we've been trying to understand recently
<zyga> and now I believe we mostly do
<cachio> zyga,ah, ok
<cachio> zyga, It just failed here :)
<Saviq> cachio: I did, it seems to have failed to install our deps https://travis-ci.org/MirServer/mir/jobs/461204937
<Saviq> I need to add a spread timeout < 50 minutes so it bails out I suppose
<mvo> zyga, cachio is it the permission denied bug?
<zyga> yes
<mvo> cachio, zyga thanks! in this case I hope to push a PR soon with a fix
<cachio> mvo, yes
<cachio> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
<zyga> mvo: does systemd-run play ball on 14.04?
<mvo> cachio: yeah, I hope to have something ready before or shortly after lunch
<mvo> zyga: I don't know, need to check but if not that would suck(tm)
<mvo> zyga: 14.04 is just ~5 more month but still
<zyga> mvo: the set of patches I proposed fixes this too
<zyga> I will land all the bits needed today
<zyga> I don't mind systemd-run being used as well,\ we may have other issues causing system key-based problem
<mvo> zyga: hm, you mean 6234 - or more?
<zyga> https://github.com/snapcore/snapd/pull/6235
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> that's the full set but it is blocked by leap
<zyga> https://github.com/snapcore/snapd/pull/6235/commits/15cae44908738b6c8e1814563c0cae727594a3d7
<zyga> have a look at each patch there
<mvo> zyga: interessting - and its green, nice. is this reliable, i.e. did you run a couple of times?
<zyga> not in that PR but yeah, a few times locally
<zyga> feel free to restart it as many times as you like
<zyga> it failed only on noise like mount error or store timeout
<mvo> great
<mvo> zyga: looks like systemd-run is out, a shame
<zyga> oh, why?
<mvo> zyga: not availalbe on trusty, it has 204 but we need 205
<zyga> 14.04?
<zyga> :////
<zyga> bummer
<zyga> well
<zyga> 4 months
<mvo> zyga: yeah, indeed
<zyga> and I'm busy writing tests
<mvo> oh well, I will shelve the PR
<mvo> until then
<zyga> I'm happy to finally end 2.36 drama ;)
<mvo> zyga: indeed
<mvo> zyga: well done!
<cachio> zyga, :)
<mup> PR snapd#6239 closed: packaging/fedora/snapd.spec: fix bogus date in changelog <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6239>
<Chipaca> mvo: systemd-run wha?
<pedronis> Chipaca: it doesn't exist in 14.04 ?
<zyga> mvo: I pushed unit test to https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<zyga> mvo: I will now add a spread test
<zyga> have a look please
<mborzecki> off to pick up the kids
<pstolowski> mborzecki: what's the story with https://bugs.launchpad.net/snapd/+bug/1759349 ?
<mup> Bug #1759349: Confinement doesn't work on arch (manjaro) linux <snapd:Triaged> <https://launchpad.net/bugs/1759349>
<mvo> zyga: sure, looking
<zyga> thx
<mvo> Chipaca: https://github.com/snapcore/snapd/compare/master...mvo5:systemd-run-security-gen?expand=1 <- the idea was to avoid that apparmor_parser and snap-seccomp processes get killed when we restart snapd
<mvo> Chipaca: but a non-starter for now
<jdstrand> mvo: curious how snapd fits into trusty/esm...
<mvo> jdstrand: last time we talked about this someone mentioned that snapd would probably not included but that wasn't very official
<zyga> jdstrand: gives mvo more gray hair?
<jdstrand> mvo: probably want to talk to joe and amurray. they arer in the process of defining what's in trusty/esm and that is coming from stakeholders
<mvo> jdstrand: ok
<jdstrand> mvo: I hadn't really thought that snapd would be in esm, but it seems likely it will have a (much) expanded package set than precise/esm
<jdstrand> mvo: I guess part of this would be looking at data for snapd on trusty and seeing how that maps to esm customers
<jdstrand> mvo: which joe and amurray may need some help with (on the data collection bits)
<mvo> jdstrand: makes sense. however the version of systemd (204) there is giving us a headache
<jdstrand> mvo: not trying to give you gray hair, sorry :\
 * jdstrand nods
<zyga> mvo: wrote the spread test, running it now
<zyga> I'll make something warm
<mvo> zyga: thanks!
<mvo> zyga: and sorry for commenting on the wrong PR :/ I commtned on the right now now too
<zyga> mvo: with both spread and unit test I'm happy with this being merged into master
<zyga> mvo: hah, no worries :)
<zyga> least of our problems
<jdstrand> mvo: I wouldn't necessarily consider also upgrading systemd in trusty/esm off the table. there is more flexibility there, so *if* snapd should be included in trusty/esm, perhaps there are things that can be done to make it easier on you
<mvo> jdstrand: well, it will be a discussion but trusty is a real burden for us, that should be taken into consideration
<jdstrand> mvo: sure, which is why I wanted to mention that you should let joe and amurray aware of that. you're obviously a stakeholder :)
<mup> PR snapcraft#2380 closed: tests: use autopkgtest to leverage snap testing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2380>
<zyga> jdstrand: I would love 14.04 == 16.04 as far as systemd is concerned
<zyga> would be much sweeter support target
<zyga> we have plenty of // TODO because 14.04 ... in the code
<zyga> mvo: I added 2.36.3 milestone
<mvo> zyga: thanks
<mvo> zyga: to LP?
<zyga> yes
<mvo> zyga: cool
<zyga> mborzecki: probably want to update https://bugs.launchpad.net/snapd/+bug/1772016
<mup> Bug #1772016: Mount snap "snapcraft" (1591) ([start snap-snapcraft-1591.mount] failed with exit status 1: <snapd:Triaged> <https://launchpad.net/bugs/1772016>
<mup> PR snapd#6231 closed: data: set KillMode=process <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6231>
<zyga> mvo: I must say I really enjoy filing bugs and writing regression tests
<zyga> that paper trail and non-main test means that we still get rapid testing of features (main) but get nice and good feeling that over time things don't explode on bugs that we fought before
<zyga> and if it happens we have all the context to look at
<pedronis> Chipaca: standup?
<Chipaca> pedronis: omw
<pedronis> cachio: ^
<mvo> zyga: indeed
<mvo> cachio: 2.36.2 is ready for beta validation now :)
<cachio> mvo great
<cachio> I'll start asap
 * cwayne gets excited for some core results
<mvo> kenvandine: the fontconfig fix is in the core beta now, if you could test and ask your team to test that would be awesome
<kenvandine> mvo: awesome
<kenvandine> thanks
<kenvandine> mvo: how about core18?
<mvo> kenvandine: it will work there too
<kenvandine> sweet
<mvo> kenvandine: I mean, it will work with snaps that use core18 as well
<sergiusens> niemeyer: hello, just to clarify, is the conclusion from https://forum.snapcraft.io/t/snap-multi-line-descriptions-need-newline-trim-on-store-import/3934/12 to use | instead of > considering that the markdown filter will apply the appropriate formatting wrt (in this case) newlines?
<mborzecki> zyga: can you try 'snap install hello-world_foo hello-world_bar'? does it work for you?
<zyga> mborzecki: in a sec
<zyga> mvo: if you can do a final ack on https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<mup> PR snapcraft#2417 closed: Revert "lifecycle: make snapcraft init template use > not | (#2393)" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2417>
<zyga> mborzecki: yes
<zyga> mborzecki: works ok
<mborzecki> zyga: both snaps in a single line?
<zyga> yes
<mborzecki> zyga: are you running the latest master?
<zyga> no
<zyga> 2.36.1
<zyga> sorry, too many machines :)
<zyga> my master machine is on the right
<zyga> this one was on the left
<mborzecki> zyga: i get 'error: store.SnapNotFound with 2 snaps'
<zyga> hmmmm
<niemeyer> sergiusens: It looks like ">" (aka line folding) changes the output completely from what is presented to the user. It even corrupts the rendering once the text is interpreted as Markdown.
<niemeyer> sergiusens: Isn't that true?  If it is, then it indeed looks like a terrible idea to use it.
<sergiusens> niemeyer: yes, exactly why I am inclined to revert it https://www.irccloud.com/pastebin/WaNVs8vG/para%20que%20veas%20el%20efecto
<zyga> mup: hello
<mup> zyga: I apologize, but I'm pretty strict about only responding to known commands.
<niemeyer> Heh..
<zyga> 2fa?
<niemeyer> No.. either chrome or hangouts itself is hanging on me
<mup> PR snapd#6241 opened: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
<mup> PR snapd#6240 closed: release: 2.36.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6240>
<niemeyer> sergiusens: Why are you just inclined?  Is the behavior reasonable?
<pedronis> pstolowski: niemeyer:  I wrote something here: https://bugs.launchpad.net/snapd/+bug/1777121
<mup> Bug #1777121: Remove is called after snap services are stopped  <snapd:In Progress by stolowski> <https://launchpad.net/bugs/1777121>
<niemeyer> sergiusens: To me it looks clearly like a bug.. ideally that sort of change should be carefully investigated before it takes place
<niemeyer> pedronis: Thanks.. depending on their use case, we might have a hook like this, but I'd try to cook it in a way that detaches from the promise of running services
<pedronis> niemeyer: let's see if they have further feedback, now that the picture is clearer
 * zyga -> soup
<pstolowski> pedronis: ty. i marked my PR blocked for now, we can decide if we want to close depending on feedback
<Chipaca> brb, need to reboot - plugging in my headset hangs my trackpad
<Chipaca> (WAT)
<cachio> mvo, hey
<cachio> https://paste.ubuntu.com/p/gNMHkR2Wpt/
<cachio> any idea about this request
<cachio> it is taking about 3/4 seconds
<cachio> delaying the test suite
<niemeyer> pedronis: We might call it "cleanup", for example.. we should just make its semantics more clear, including when exactly it's called, what are the promises or possibilities, and we might also consider what other use cases we might have for the same hook
<mvo> cachio: not sure where it comes from, what happens before/after in the logs?
<cachio> mvo, https://paste.ubuntu.com/p/ct763X3tj5/
<cachio> mvo, it jumps from 14:50:20 to 14:50:24
<cachio> with that request
<jdstrand> mvo: hey, did you see my response regarding your compression exploration? we don't need to discuss it here, but if you start to narrow in on something, please perform resquash tests (I can show you how) on a variety of snaps (eg, large, like chromium as well as snaps built on one arch (eg, i386, armhf, arm64) and resquashed on amd64)
<cachio> it happens when we stop the snapd.service
<mborzecki> could we land https://github.com/snapcore/snapd/pull/6211 ? super simple
<mup> PR #6211: spread: run tests on Fedora 28 again <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6211>
<rbasak> "error: cannot install zero snaps" -- not something I ever thought I'd see a dedicated error message for :)
<rbasak> (my fingers raced a middle click paste against the return key)
<zyga> rbasak: attention to detail :-)
<mvo> jdstrand: yeah, saw it but didn't look at the details yet
<mvo> cachio: aha, looks like the catalog update
<mvo> cachio: I guess we could disable that via some magic
<mvo> cachio: but we need to write code for that, iirc we currently unconditionally run it
<cachio> mvo, the problem is that we start / stop it on reset
<cachio> and it takes like 7/10 seconds to stop it
<jdstrand> mvo: ok, don't want to distract you, just want you to be aware that we should not regress resquash tests in the store and that, having been through this with our existing options, things are rather delicate
<cachio> mvo, is it refreshing the catalog any time we start snapd?
<Chipaca> cachio: catalog refresh happens every startup yes
<Chipaca> cachio: also sometimes assertions
<zyga> fun fact: on freebsd there's /.snap and then there's a /sys symlink to source code
<Chipaca> zyga: what's /.snap ?
<zyga> empty directory
<zyga> maybe snapshot spot?
<zyga> not sure yet
<zyga> Chipaca: you will like this one
<Chipaca> zyga: https://lists.freebsd.org/pipermail/freebsd-questions/2012-January/237296.html
<zyga> Chipaca: /home is a symlink to /usr/home :D
<cachio> Chipaca, mmm, ok, perhaps I can make small change to avoid stop snapd just after we start it
<zyga> Chipaca: also /proc exists, but it is empty
<zyga> freebsd is odd :)
<zyga> Chipaca: there's /rescue which is much like /bin but everything is statically linked
<zyga> I see what you did there freebsd
 * cachio lunch
<Chipaca> cachio: or we could make snapd check the timestamp on the catalog and not refresh too often
<zyga> mvo, Chipaca found a fun bug
<zyga> https://pastebin.ubuntu.com/p/xyNHG2Hqdk/
<zyga> we mount core18 _after_ starting snapd
<zyga> and things go south
<zyga> is this expected?
<Chipaca> zyga: all bugs are expected
 * Chipaca puts down his tea and looks at it quizzically
<pedronis> zyga: where? what's the context of that?
<zyga> pedronis: regression test noticed that things misbehave on a core18 system
<zyga> just vanilla run-off-the-mill core18 test system
<zyga> looking at journal logs to see what was wrong
<zyga> I guess this possible means that we mount any snap after snapd is started
<zyga> which would be possibly quite grim
<zyga> shall I report it and finish my current task?
<cachio> Chipaca, yes, that too
<pedronis> zyga: yes
<mvo> zyga: yeah, thanks for finding this
<zyga> reported as https://bugs.launchpad.net/snapd/+bug/1805866
<mup> Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>
<mvo> zyga: its slightly strange iirc we set Before=snapd.service in our mount units plus mounts happen before multi-user
<zyga> and if I can have one xmas present, I would love to see markdown support on launchpad comments
<mvo> zyga: but might be because of something in core18 that is special
<zyga> yep
<zyga> it's "fun" that this fix for 2.36 uncovers issues like that
<mvo> zyga: yeah
<mvo> zyga: is this first run on core18? I mean, very first start? there nothing is mounted yet, snapd needs to bootstrap itself
<zyga> mvo: I just ran
<zyga> spread -debug -v google:ubuntu-core-18-64:tests/regression/lp-1805838
<zyga> maybe try with -shell-after
<mup> PR snapd#6211 closed: spread: run tests on Fedora 28 again <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6211>
<mup> PR snapd#6242 opened: overlord/snapstate: use file timestamp to initialize timer <Created by chipaca> <https://github.com/snapcore/snapd/pull/6242>
<mvo> zyga: ok, what PR was this again?
<Chipaca> cachio: ^
<zyga> https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<zyga> the test passes on all systems now
<mvo> zyga: thanks! running it now
<mup> PR snapd#6243 opened: systemd: allow only a single daemon-reload at the same time <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>
<pstolowski> zyga: can you take a look at #6180 (doesn't have to be today)
<pstolowski> ?
<zyga> k
<mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
<zyga> ah
<zyga> sure
 * pstolowski should probably remove complex label from it and have something that attracts people instead ;)
<zyga> we need a <cookie> label
<pstolowski> yay
<roadmr> ðª
<pstolowski> it's not really complex btw.. just needs some insight maybe
<zyga> roadmr: just need to cross check with kyrofa about how it renders
<pstolowski> roadmr: lovely
<mup> PR snapcraft#2418 opened: Release changelog for 3.0.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2418>
<pedronis> zyga: do we need #6230 ?
<mup> PR #6230: spread: detect "signal: terminated" in journal logs <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6230>
<zyga> no, it was just experiments
<zyga> closed now
<mup> PR snapd#6230 closed: spread: detect "signal: terminated" in journal logs <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6230>
<zyga> pedronis, mvo: though the forkstat stuff was amazing
<mvo> zyga: yeah, I think we keep this in mind, something like this may come back later
<pedronis> Chipaca: #6192 needs a 2nd review and I suggested a smal tweak
<mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
<mvo> zyga: I suspect the issue with the core-18 is really that on first-run nothing is available yet. otoh the state should also be empty so slightly strange
<zyga> maybe particular test setup is the culprit but I don't expect this to happen
<mvo> zyga: I see "Reboot on qemu:ubuntu-core-18-64 ... is taking a while" and it seems like its hanging
<zyga> we're either seeging
<zyga> *seeding
<zyga> and snaps are installed
<zyga> or we know nothing about them
<zyga> feels like a bug for real at some level
<mvo> zyga: oh, they are installed, hm, hm, if so we should have a Before=snapd.service
<zyga> mmm
<zyga> yeah
<zyga> I haz real bug
<pedronis> zyga: mvo: we do have some tests that wipe the state
<zyga> pedronis: I ran that single test in isolation
<pedronis> and simulate the seeding again
<zyga> it was the first code to run
<pedronis> zyga: what test is it?
<mvo> zyga: did you also get this wait?
<zyga> spread -debug -v google:ubuntu-core-18-64:tests/regression/lp-1805838 from https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6233>
<zyga> wait?
<pedronis> am I reading it wrong, that info is not in the bug?
<zyga> no, it's not in the bug but that test is arguably not doing anything, it just restarts snapd to see what the logs show -
<pedronis> it's a new test?
<pedronis> I don't have it here
<zyga> yes
<zyga> it's a regression test for that branch
<zyga> mvo: I missed this part:
<zyga> zyga: I see "Reboot on qemu:ubuntu-core-18-64 ... is taking a while" and it seems like its hanging
<zyga> mvo: I didn't get that
<zyga> is it still hanging
<zyga> ?
<mvo> zyga: hm, ok
<mvo> zyga: yeah, I try again
<zyga> eh, failed on mount error
<zyga> - Mount snap "test-snapd-tools" (7) ([start var-lib-snapd-snap-test\x2dsnapd\x2dtools-7.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dtools-7.mount failed.
<zyga> See "systemctl status "var-lib-snapd-snap-test\\x2dsnapd\\x2dtools-7.mount"" and "journalctl -xe" for details.
<mvo> zyga: I was running it in qemu
<zyga> aha
<mvo> zyga: running it in google now
<zyga> afk
<zyga> going to my son's birthday :)
<zyga> ttyl
<kyrofa> Haha, zyga|afk looks like a rock
<roadmr> https://www.youtube.com/watch?v=2NEbe_brJAQ
<mvo> zyga|afk: enjoy!
<mvo> zyga|afk: hm, hm, spread -v -debug  google:ubuntu-core-18-64:tests/regression/lp-1805838 just worked, I try again after dinner
<zyga|afk> mvo: yes, it passes
<zyga|afk> mvo: try -shell-after
<zyga|afk> see what logs say
<zyga> whee
<mup> PR snapd#6233 closed: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
 * cachio afk
<mup> PR snapd#6244 opened: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
 * zyga really goes to sleep now
#snappy 2018-11-30
<mup> PR snapcraft#2418 closed: Release changelog for 3.0.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2418>
<mborzecki> morning
<zyga> Hi
<mborzecki> zyga: hey
<zyga> Hej
<zyga> Breakfasting
<zyga> I sent a PR last night
<zyga> Fixing leap issues
<zyga> I will make a small variant for 2.36
<mvo> good morning! it looks like the tests in 6243 got restarted, did we see any trace of the protocol error in the last run?
<mvo> looks like the current run was good, I do another one now
<mborzecki> mvo: i restarted them twice already, first time failed in prepare of juju observe test (unrelated), next failure was centos mirrors being flaky
<mvo> mborzecki: heh
<mvo> mborzecki: ok, it had one green now and I just triggered it again (via rename of GIL->GML)
<mborzecki> super simple review #6241
<mup> PR #6241: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs â> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
<pstolowski> mornings
<zyga> Back from walk
<zyga> Brrrr
<zyga> Though I really like it when winter makes everything dry
<zyga> Hey mvo
<zyga> I will be around shortly
<mvo> zyga: hey, no worries
<mvo> zyga: all is looking great, I'm in a very good mood, PRs look super interessting
<zyga> I posted the leap fix last night
<zyga> Just the master version
<zyga> 2.36 will be microscopic
<zyga> Master has a cleanup as well
<mvo> zyga: aha, even better
<pedronis> mborzecki: I put a question in #6079
<mup> PR #6079: [RFC] `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<mup> PR snapd#6234 closed: overlord: don't write system key if security setup fails (2.36) <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6234>
<mborzecki> pedronis: thanks, finishing up with snapd update for arch now, will lack at your review in a bit
<mup> PR snapd#6221 closed: interfaces: return security setup errors (2.36) <â Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6221>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6245
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<zyga> it won't pass entirely
<zyga> after that there will be only one small patch that makes apparmor-parser errors really reported and 2.36 is green
<zyga> similar to the one you closed above in 6221
<mup> PR snapd#6245 opened: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<zyga> if you want I can add it here
<pstolowski> mvo: that case you found with brave install & removal sequence is amazing; it really has to involve all the three ops, just installing the instance and removing it (2 ops) is not enough
<mvo> pstolowski: yeah, I found this too, its interessting
<mvo> zyga: it sounds like like it can be added to 6245 if its small
<zyga> mvo: yes, and one will not pass without the other
<zyga> I'll do just that
<zyga> mvo: thank you for merging the 2.36 fix even though it was not passing
<zyga> pstolowski, mvo: what's the special case with brave?
<pstolowski> zyga: sudo snap install brave && sudo snap install brave_test && sudo snap remove brave brave_test
<pstolowski> zyga: (with instances feature on)
<zyga> mhm
<pedronis> pstolowski: hi, do we have developer docs for interface hooks?
<pstolowski> zyga: results in a bunch of conflicts and retries on the last step, take a good while to finish
<pedronis> pstolowski: conflicts on what?
<pstolowski> pedronis: yes, they were written a couple of weeks ago
<pstolowski> pedronis: conflicts on disconnects on removal (last op)
<pedronis> I see
<pedronis> pstolowski: I suppose at this point they are expected, no? we'll need to step back to improve that? or is there a low hanging fruit?
<pstolowski> pedronis: yes, we expect it, but mvo observed a noticable slowdown with edge (which i can confirm)
<pedronis> ok
<pstolowski> pedronis: it was noticed ~last week
<pstolowski> pedronis: and again, it completes and work, is just slow
<pedronis> pstolowski: any candidate on why? feel free to dig a bit when you have a bit of time
<pstolowski> pedronis: yeah i'm on, investigating, don't know yet
<mborzecki> hmm no smart way of reloading snap-confine aa profile on arch when installing/updating snapd, i expect people to run into problems with snap-confine
<zyga> oh
<zyga> can we do that ourselves?
<zyga> in the package file?
<mborzecki> zyga: i can, but it's unclear whether i should, you know, the unwritten policy of doing nothing :)
<zyga> hehe
<zyga> does that also apply to libc breaking people on upgrades?
<zyga> is there any limit?
<mborzecki> hahah, it's /r/archlinux, or bbs.archlinux.org or just archlinux.org main page with 'manual steps needed' memo
<zyga>  /o\
<mborzecki> though i don't recall any major screwups for years now
 * zyga is happy with opensuse :)
<mborzecki> i mean, surprisingly, it just works
<mborzecki> does it make sense to request snapd restart on a classic system where reexec is not supported?
<zyga> mmm
<zyga> probably not
<mborzecki> that's what happens on arch, fedora and prooably opensuse too
<zyga> morning Chipaca
<Chipaca> morning
<mborzecki> this basically https://paste.ubuntu.com/p/xRnrQMNTH8/
<mborzecki> Chipaca: morning, sir
<pedronis> Chipaca: hi
<Chipaca> 'sup
<pedronis> mborzecki: hi, you have various things under review, but no current task that isn't blocked on feedback? is that true?
<mborzecki> pedronis: i'm addressing feedback on the PRs and chopping selinux branch up to pull out the bits that aren't strictly related (mostly tests)
<pedronis> mborzecki: ah ok, so you are not blocked atm?
<pedronis> Chipaca: did you see https://github.com/snapcore/snapd/pull/6236#discussion_r237451827 ?
<mup> PR #6236: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
<mborzecki> pedronis: no
<Chipaca> pedronis: I did
<Chipaca> I'm assuming it's technically correct
<Chipaca> in practice, not sure how important it is :-)
<pedronis> Chipaca: ?
 * pedronis is probably missing something
<Chipaca> pedronis: the current regep means we won't run staticcheck on ".0" releases
<Chipaca> because go doesn't do .0, instead just does ""
<Chipaca> apparently
<pedronis> Chipaca: not sure why you say is not important? having a test that doesn't run for a while
<pedronis> and then again
<pedronis> is usually source of confusion
<pedronis> of which if have enough I think
<pedronis> s/if/we/
<pedronis> Chipaca: or you thinking that .0 never makes it into Ubuntu anyway?
<Chipaca> I'll fix it (not that way though)
<pedronis> anyway changing it is likely quicker than this silly discussion :)
<Chipaca> but, i'm worried that already 1.11 is breaking things for us
<Chipaca> wonder what 1.12 will bring
<Chipaca> and then there's go 2
<pedronis> one thing at a time
<Chipaca> pedronis: did you see"go 2 considered harmful"?
<Chipaca> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
 * Chipaca grins
<pedronis> no
<zyga> lol
<Chipaca> changing subjects, I pushed a little "make snapd start faster" pr after talking with cachio yesterday
<Chipaca> and mvo fixed the spread tests (thanks mvo!)
<Chipaca> and now it's so fast, systemd freaks out :-/
<pedronis> I saw it
<pedronis> ah
<Chipaca> :-)
<pedronis> no good deed goes unpunished
<Chipaca> bah, it might be something else
<Chipaca> i need to dig
<Chipaca> but
<Chipaca> Job for snapd.service failed because start of the service was attempted too often. See "systemctl status snapd.service" and "journalctl -xe" for details.
<Chipaca> that thing :)
<pedronis> Chipaca: let's try to merge 6192 first
<Chipaca> ok
 * Chipaca looks at what's missing there
<pedronis> couple of minors there, and it needs a 2nd review (I cannot review twice)
<Chipaca> pedronis: looking at the revision of the local snap would split error messages even more though
<Chipaca> i mean, either snap could be local
 * Chipaca gives it a stab
<pedronis> Chipaca: ?
<Chipaca> pedronis: your suggestion to, in the local case, say "current local"
<pedronis> yes
<Chipaca> pedronis: is about the current snap
<Chipaca> pedronis: the revision we talk about in the error messages so far is about the new snap
<Saviq> cachio: oh seems it worked this time: https://travis-ci.org/MirServer/mir/jobs/461685223
<pedronis> Chipaca: let me look
<pedronis> I might be very confused
<Chipaca> pedronis: unless you meant to always say "current local", as in that-which-is-locally-current
<Chipaca> and not as in that-which-is-locally-current-and-has-a-revision-that-is-local
<pedronis> Chipaca: I see, I'm confused
<pedronis> but something is off either way
<Chipaca> hello confused i'm dad
<pedronis> Chipaca: so we are looking at snapInfo revision
<pedronis> great
<pedronis> except that calling a local installed snap new revision in the 2nd message
<Chipaca> i could've caled them newInfo and curInfo instead of snapInfo and curInfo  i guess
<pedronis> is confusing and what threw me off
 * Chipaca looks
<pedronis> Chipaca: if I do snap install --dangerous foo.snap
<pedronis> calling the incoming thing new revision
<pedronis> is confusing
<Chipaca> aha
<pedronis> (tough technically correct)
<Chipaca> i'll happily drop in any other noun :-)
<Chipaca> I might even drop in a verb if i'm in a hurry
<Chipaca> pedronis: I mean: Â«cannot refresh "foo" because [this new thing]  has epoch 123 that can't read [the old thing]'s epoch of 0Â»
<pedronis> Chipaca: "new epoch %s being locally installed"  would be the verbose thing
<Chipaca> Â«cannot refresh "foo" because new epoch 123 being locally installed can't read [...]Â»?
<pedronis> yes
<Chipaca> that's confusing to read
<pedronis> I'm happy to suggestion, the current error confused me though, so we need to do better
<Chipaca> so, it can be a try or a --dangerous
<pedronis> yes
<pedronis> cannot refresh "foo" with local snap because its epoch ...?
<Chipaca> Â«cannot refresh "foo" because the one you're trying to install has epoch [...]Â»
<Chipaca> ?
<Chipaca> hm
<pedronis> cannot refresh "foo" with local snap with epoch %s ... ?
<Chipaca> cannto refresh "foo" to local snap with epoch...?
<pedronis> that also work
<pedronis> s
<Chipaca> good, let me write it out in full just in case
<Chipaca> cannot refresh %q to local snap with epoch %s, because that can't read current revision's epoch of %s
<Chipaca> or maybe change the that to an it
<Chipaca> cannot refresh %q to local snap with epoch %s, because it can't read current revision's epoch of %s
<Chipaca> bah, that "revision's" there is noise
<Chipaca> noise][1: no offence
<pedronis> can be dropped I suppose
<Chipaca> cannot refresh %q to local snap with epoch %s, because it can't read the current epoch of %s
<mborzecki> snap install hello-world does-not-exist, giving 'error: store.SnapNotFound with 2 snaps' is not super user friendly
<pedronis> mborzecki: my PR will fix it
<mborzecki> pedronis: ack
<Chipaca> mborzecki: i disagree, it's super friendly. You're just not its friend.
<pedronis> I'm actually hoping to get to it today
<mborzecki> Chipaca: hehe :P didn't bother me until yesterday i didn't notice a typo in snap name i tried to install and ended up going through snapd code to figure it out
<Chipaca> mborzecki: tbf that error means there's a bug, it's meant as an error for us and not for users
<mborzecki> we're lucky then that users install snaps one by one
<mborzecki> but it did give me a bit of panic yesterday when 'snap install hello-world_foo hell-world_bar' didn't work :/
<pedronis> Chipaca: there's two part of the code that make different assumptions, anyway #5712 should stop that afaiu
<mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <â Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<Chipaca> pedronis: ð
<pedronis> Chipaca: we probably should drop revision's alos in the other one, current epoch alone seems ok, no?
<Chipaca> pedronis: heh
<pedronis> given also that it might be local or not in its own
<Chipaca> 	return fmt.Errorf("cannot refresh %q to %s with epoch %s, because it can't read the current epoch of %s", snapInfo.InstanceName(), desc, snapInfo.Epoch, curInfo.Epoch)
<Chipaca> ^ current code
<Chipaca> where desc is "local snap" or "new revision %s"
<pedronis> sounds good
<pedronis> Chipaca: we get the {}  notation right if the epoch is complicated ?
<Chipaca> yes
<pedronis> that's fine for now
<pstolowski> mvo, pedronis ok, i understood the problem with slowness on brave+brave_test install+remove. perhaps HO would be fastest to explain if you have a few minutes
<Chipaca> for now it's the json one
<Chipaca> although from using it, just {[],[]} might be enough
<Chipaca> (as opposed to {"read":[],"write":[]} )
<pedronis> pstolowski: I'm available in a couple of minutes
<pstolowski> pedronis: ok, ping me then (mvo feel free to skip it)
<Chipaca> silly Go, not telling that when I write lcoal I mean local
<pedronis> pstolowski: ready now, in the standup
<pstolowski> pedronis: ok coming
<mborzecki> another thing we maybe could improve, when installing a snap that pulls in a content snap, the prompt will stay on 'Automatically connect eligible ..' for a long time, while the content snap is downloading
<zyga> mvo: https://github.com/snapcore/snapd/pull/6245 needs a review
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<zyga> pstolowski: reading https://github.com/snapcore/snapd/pull/6180
<mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
<pstolowski> zyga: thanks!
<pedronis> mvo: zyga: Chipaca: I'll be late for standup, I posted a forum message to the team about this
<zyga> thank you
<mvo> pedronis: thank you
<mvo> pstolowski: sorry, was away but I take it you clarified this?
<pstolowski> mvo: yep, no worries
<mvo> zyga: I do a new round of review now
<zyga> thank you
<Chipaca> the local authority has finally (nearly 12 months later!) come to a decision about the boys' school \o/
<zyga> I'm not feeling well, sorry about being very slow today
<Chipaca> â¦ so I might miss the standup entirely today
<mvo> zyga: no worries
 * Chipaca hugs zyga 
<mvo> Chipaca: good news! (about the boys - not that you miss the standup ;)
<Chipaca> but â¦ from far away just in case it's cooties
 * mvo hugs zyga as well
<zyga> just cold, nothing fancy :)
<zyga> I'll be allright
<pedronis> Chipaca: ok
<pstolowski> pedronis: retry mechanism seems to work *most of the time*, but there is something fishy there, *sometimes* it doesn't pick any other task until retry time of previous one is reached - see the proof with some extra debug https://pastebin.ubuntu.com/p/TYMffsdTQX/
<cachio> Chipaca, nice, I'll try it
<cachio> thanks
<cachio> Saviq, nice
<cachio> please let me know if we need any change to that image
<pedronis> pstolowski: that seems strange, we are missing something, I suppose some prints in the taskrunner might help
<cachio> Chipaca, which is the PR number?
<pedronis> #6192  needs a 2nd review
<mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
<pstolowski> pedronis: yep
<Chipaca> cachio: #6242
<mup> PR #6242: overlord/snapstate: use file timestamp to initialize timer <Created by chipaca> <https://github.com/snapcore/snapd/pull/6242>
<pedronis> degville: might you could look quickly at the new errors in #6192, if you have some feedback on them
<pedronis> notice that in most sitation the store should avoid us hitting them tough
<pedronis> they are more relevant for local development using try or local installs
<mborzecki> zyga: did you mean to open #6245 with target set to release/2.36? it's targeting master now
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<zyga> ooh
<zyga> shit :)
<zyga> yes
<zyga> fixed
<zyga> this version is for the stable release
<zyga> I was surprised it passed alone
<mvo> heh, same here
<mvo> (also surprised)
<pedronis> degville: thanks for https://forum.snapcraft.io/t/the-docs-roadmap/8763
<Chipaca> cachio: the problem is nfs-support restarts snapd 11 times :-)
<Chipaca> cachio: and it's fast enough for that to be a problem now
<Chipaca> cachio: I'm fixing
<cachio> Chipaca, nice, thanks for that !!!
<mvo> 5845 is ready for a second review
<degville> no problem.
 * pedronis can't type today
<mup> PR snapd#6241 closed: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs â> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
<mborzecki> mup: kicked off another spread run in #6243
<mup> mborzecki: In-com-pre-hen-si-ble-ness.
<mborzecki> mvp: kicked off another spread run in #6243
<mborzecki> mvo: kicked off another spread run in #6243
<mup> PR #6243: systemd: allow only a single daemon-reload at the same time <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>
<mvo> mborzecki: thanks, I run this now also locally against google:ubuntu-18.04-64, so far no issues, lets see
<Chipaca> actually, i wonder if systemd seeing the restarts as problematic are because we don't exit from the main loop properly
 * Chipaca digs
<Chipaca> could I get a second review of #6236? it's got a minor fix pending (in a Suggestion already) but I'd rather not re-trigger a travis just for that unless it's the only thing left
<mup> PR #6236: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
<Chipaca> jamesh: I am keeping your user session pr in mind, have not finished the review yet though
<mvo> Chipaca: I have it on my list, hope to get to it before lunch
<Chipaca> mvo: excellent thanks
<zyga> mvo: https://github.com/snapcore/snapd/pull/6245 is green!
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<zyga> that's lucky
<Chipaca> mvo: looks like we dropped the ball on https://forum.snapcraft.io/t/anything-changed-around-snapcraft-yaml-gpio-interface-for-2-36/7852/4 (unless there was more communication out of band)
<zyga> moar fire
<Chipaca> toasty
<zyga> pretty please review on 6245
<Chipaca> sir yes sir
<zyga> thank you, that's almost all needed to make 2.36 green again
<mvo> Chipaca: I think we fixed this but we did not communicate this well :(/
<mvo> Chipaca: I need to look what PR fixed it, don't quite remember offhand
<zyga> mvo: is is in 2.36.x ?
<jamesh> Chipaca: thanks.
<zyga> maybe we need a .3
<mvo> zyga: I think so
<mvo> zyga: oh, why .3? what is missing?
<zyga> I mean, if this is not in stable
<zyga> but in 2.37 / beta only
<zyga> but no need otherwise
<Chipaca> don't propose a new .X on the eve of a sprint dude, that's just mean
<Chipaca> you need to do it the monday of the sprint and write a CVE, that's the sporting way
<mvo> Chipaca: *wahhhhh*
 * mvo runs away screaming
<zyga> HAHHAHA
 * Chipaca 's job is done
<zyga> Chipaca: make sure to msg mvo on his cell at 23:00 on sunday ;)
<zyga> PLANES FALLING OFF THE SKY, NEED .3
<mvo> zyga: you guys are so mean!
<zyga> mvo: we will attach patches :) that's foss spirit, right?
 * zyga hugs mvo
<mvo> lol
 * mvo hugs zyga 
<zyga> no worries, we will wait until after breakfast
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<mup> PR snapd#6246 opened: spread: show AVC audits when debugging, start auditd on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6246>
<mup> PR snapd#6247 opened: tests/lib: do not pick up xatts when repacking core snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6247>
<pedronis> mborzecki: ^ don't we have xattrs that we care about in core tough?
<mborzecki> pedronis: afaik not yet
<zyga> pedronis: not that I know of, ubuntu will enable xattrs but it's not done yet
<pedronis> still is that change just exchaing a bug for another later?
<zyga> heh, in some way yes
<zyga> but xattrs will not show up by accident
<zyga> and I think we will have some changes around snapd too
<pedronis> we are not the one adding them, though? are we
<pedronis> ?
<zyga> sorry?
<pedronis> zyga: I mean,  it depends on what you mean by accident,
<pedronis> other teams doing things without telling can be considered an "accident"
<pedronis> mborzecki: can we add some code to detect if there's xattrs that are not selinux related around?
<zyga> I meant that there will be coordination and I expect things will fail if we rip them out in some tests. programs that were setuid root will require on capabilities instead
<pedronis> zyga: you are an optimistic
<mborzecki> pedronis: i'll think about it, with the context applied via mount that change may not be needed at all
<pedronis> thx
<mborzecki> otherwise a way of doing this without adding selinux context would be nice, but not sure if that's entirely possible when we repack the snap
<pedronis> mborzecki: is there no utility to run something controlling the context?
<pedronis> anyway I let you look into this further
<mup> PR snapd#6248 opened: tests/lib/reset: restore context of removed snapd directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6248>
<mup> PR snapd#6237 closed: client, store: don't use store from client (use client from store) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6237>
<jdstrand> zyga: hey, curious, does leap run on arm?
<zyga> jdstrand: hey
<zyga> yes, I think there were some pi3 announcements by suse
<zyga> https://en.opensuse.org/HCL:Raspberry_Pi3
<zyga> I haven't tried myself
<zyga> why? :)
<zyga> jdstrand: FYI, I sent some patches that disable apparmor on 43.3 because apparmor_parser 2.10.3 doesn't parse our profiles
<jdstrand> zyga: it is because of your fyi :)
<zyga> haha
<zyga> I see
<zyga> :)
<zyga> can you expand, I don't yet see a correlation between leap and arm
<zyga> Chipaca: https://github.com/Juniper/libxo
<zyga> remember the topic about snap foo --json
<zyga> and friends?
<jdstrand> zyga: you surely recollected that we added conditional support for unsafe in classic and there is https://github.com/snapcore/snapd/pull/5982
<mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
<zyga> yes
<zyga> but to interfaces
<jdstrand> yes
<zyga> snap-confine's own profile goes down in flames
<zyga> we just never noticed
<jdstrand> I know
<zyga> until all hell broke loose
<jdstrand> again, I read the pr
<jdstrand> so I was thinking "should we even consider conditionally adding unsafe to the snap-confine profile?"
<jdstrand> then I reread why we added it: https://github.com/snapcore/snap-confine/pull/133
<mup> PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/133>
<zyga> 42.3 will be EOL in june next year
<jdstrand> we added it for arm
<jdstrand> so if arm is on leap, and we conditionally added it, the on arm leap would break
<jdstrand> or rather, if leap is on arm
<zyga> hmm, I don't recall the whole arm / leap part of the branch
<jdstrand> so the answer is "no, we need to unconditionally add it"
<zyga> ah
<jdstrand> zyga: that branch wasn't done for leap
<jdstrand> the branch was done to fix snapd on arm at all
<zyga> ok, I read the patch again, I see what that was about
<zyga> now back to the current patches
<jdstrand> point is, if we decided to conditionally add unsafe to the snap-confine profile, then wherever we didn't add it, arm would be broken. that's silly
<mborzecki> off to pick up the kids
<zyga> jdstrand: where are we doing this conditionally? I must be missing something
<jdstrand> zyga: huh? the interfaces
<zyga> jdstrand: are you talking about the current set of patches?
<zyga> jdstrand: ah. sorry, too many patches
<zyga> so
<zyga> there are two cases of broken
<zyga> one was louder than another
<jdstrand> zyga: I think you may be reading this irc conversation too quickly
<zyga> we ignored some errors so the snap-confine profile being broken was below the radar for a long time
<jdstrand> 06:57 < jdstrand> again, I read the pr
<jdstrand> 06:57 < jdstrand> so I was thinking "should we even consider conditionally
<jdstrand>                   adding unsafe to the snap-confine profile?"
<zyga> but interfaces were
<zyga> aha
<zyga> I see
<jdstrand> zyga: I asked you about arm on leap to answer my question that was in my head
<zyga> thank you for explaining
<zyga> so, we can do that in 2.37, I don't mind doing that
<jdstrand> zyga: the pr is doing the right thing
<zyga> we'd just have to check
<zyga> (on a real board)
<jdstrand> (in principle)
 * jdstrand hasn't reviewed the code
<zyga> jdstrand: note that there are two versions
<jdstrand> zyga: are you planning a followup pr to clean up the classic template's conditional use of unsafe?
<zyga> https://github.com/snapcore/snapd/pull/6245/files is super short for 2.36
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<jdstrand> zyga: I saw
<zyga> I can do that, yeah
<zyga> I didn't connect that dot last night
<jdstrand> zyga: yeah, well, I didn't connect the dots with the snap-confine profile when doing the classic template pr
<zyga> in hindsight logging errors and carrying on was a costly thing :)
<jdstrand> zyga: when these land, I'll update that open docker-support pr
<zyga> jdstrand: did you see https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
<jdstrand> no
<zyga> that took some time to track down
<zyga> it was breaking 2.36 for all last week and this week
<jdstrand> I need to read that carefully-- my first question is 'why is snapd restarting when snap-seccomp and apparmor_parser are running?
<jdstrand> '
<zyga> jdstrand: it is done in test prep
<zyga> that's actually the only thing we don't have a 100% firm answer
<zyga> as in
<zyga> to be precise
<zyga> why snapd is being restarted while those things are in flight
<jdstrand> exactly
<zyga> since we use sd_notify to tell systemd we are ready only after the managers have been constructed
<zyga> one possible explanation
<jdstrand> that sounds... weird and probably worth knowing cause there might be other bugs that are caused by this
<zyga> is that overlord is indeed done but this is a part of some ensure cycle
<zyga> (so normal activity)
<zyga> I pasted traces
<zyga> and there's a PR that can show you all the data in one spot
<zyga> (closed now, I can revive it)
<jdstrand> that 'weird' comment was for your 'why snapd is being restarted while those things are in flight' comment, not your sd_notify idea
<zyga> yes
<zyga> so we have journald/strace/forkstat and snap changes
<zyga> I would love if someone had a deeper look at this
<zyga> I feel tired after fighting 2.36 issues this week
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6230
<mup> PR #6230: spread: detect "signal: terminated" in journal logs <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6230>
<zyga> the PR name is stale, it became a box of experiments
<zyga> I can find the seed that reproduces the problem
<pedronis> jdstrand: to be clear, this is in tests, there is quite a bit of manual restarting of snapd going on
<zyga> though honestly any run on that branch will fail quickly
<jdstrand> zyga: did you consider trapping the signal and waiting to stop til it was safe?
<zyga> jdstrand: it's not our side that can trap
<zyga> I mean, we'd have to change apparmor parser
<pedronis> jdstrand: this is killing the helpers
<zyga> systemd looks at the whole cgroup
<pedronis> not snapd
<zyga> and kills one by one
<pedronis> anyway  we had a different solution as well
<zyga> yes, mvo sent a PR with KillMode=process
<zyga> though it was not merged
<pedronis> it's not useful for non reexcing
<jdstrand> zyga: well... snapd is calling the parser. if systemd tells us to stop and parser didn't complete...
<pedronis> sorry, it's not useful for distros that don't update
<zyga> jdstrand: systemd is killing both us and the parser and snap-confine
<pedronis> but it would be cleaner
<jdstrand> oh, I see
<jdstrand> is that configurable in the systemd unit?
<zyga> every process is
<zyga> yes
<pedronis> mvo: why did we close the KillMode change ?
<jdstrand> I mean, sure, this may happen regularly in the tests, but maybe it happens legitimately somewhere
<zyga> pedronis: I believe we could do both actually, it seems saner for kill mode to be process for snapd
<pedronis> zyga: yes, my point
<jdstrand> I don't know when that would be-- an admin restarting it? a deb upgrade?
<zyga> but it doesn't fix reexecing cases
<pedronis> I know
<pedronis> but it gives us a saner future
<zyga> yes
<pedronis> (theoretically)
<jdstrand> it seems rather harsh for systemd to just kill everything in the cgroup without given the parent a chance to cleanup
<zyga> jdstrand: that's the default :)
<zyga> but in hindsight I agree
<pedronis> jdstrand: well, indeed there are ways to control that, it's the default tough as zyga said
<jdstrand> there is no timeout associated with that?
<jdstrand> anyway, I won't question the default of systemd here cause I don't have the context for that decision
<jdstrand> but, if that is configurable, certainly for sanity we would want to at least try to have snapd shutdown cleanly
<jdstrand> no?
<pedronis> yes
<pedronis> sorry, but I made a note, but we need mvo around but he is lunching
<zyga> jdstrand: no, that's just SIGTERM
<zyga> jdstrand: after that there is a wave of SIGKILL
 * pstolowski lunch
<jdstrand> zyga: that is my question. how long before the wave comes?
<zyga> jdstrand: the wave of sigkill?
<jdstrand> 07:21 < zyga> jdstrand: after that there is a wave of SIGKILL
<jdstrand> zyga: you said that SIGTERM is sent. then a wave of SIGKILL
<zyga> yes
<zyga> DefaultTimeoutStopSec
<jdstrand> zyga: I'm saying, trap SIGTERM, try to shutdown before the SIGKILLs
<zyga> 90 seconds
<zyga> jdstrand: assuming we are using kill mode process yes
<zyga> but that would need some serious work
<zyga> it's not easy to do now
<zyga> e.g. manager startup is synchronous
<zyga> so is overlord startup
<zyga> we don't notify systemd that some startups need more time either
<jdstrand> zyga: ok. so, certainly we can trap SIGTERM and signal the backend to finish the current parser and snap-seccomp calls, then exit without moving to the next batch, no?
<zyga> jdstrand: we trap sigterm but the interaction between this and the rest of the daemon is not simple
<zyga> I agree we can do this
<jdstrand> hmm
<jdstrand> well, I was only asking a question. it sounds like we have a stability/robustness concern here that the 6233 papered over
<zyga> yes, I agree
<jdstrand> not saying that 6233 is invalid for moving forward
<zyga> we didn't notice that daemon was incorrectly stopping either
<zyga> john sent some patches that caught that with static analysis
<pedronis> well, first we need to stop systemd to send the SIGTERM to apparmor_parser as well, etc
<jdstrand> ok, well, I don't mean to distract. just rasing the point that perhaps a followup for cleaning up cleanly when receiving SIGTERM is a good idea
<jdstrand> raising*
<zyga> it also makes testing more complex, since right now all systemd started snapd's behave the same
<zyga> with changing of kill mode some will run under the old snapd.service unit
<zyga> some will run under the new one
<zyga> jdstrand: all fair points jamie,
<zyga> I think it would be nice if we could fix this with reexec magic and systemd services
<jdstrand> ok, reading the description of 6233, that seems like a good improvement regardless of sigterm
<mvo> pedronis: hi, KillMode=process got closed mostly because the other changes made it less urgent, it is probably still a good idea
<zyga> mvo: with kill mode = process, we should make sure that it also applies to snapd run from snapd.snap via that special service
<mvo> zyga: yeah, we can install a snapd.service.d file
<mvo> zyga: I mean, write it automatically
<zyga> oh
<zyga> super nice idea
<zyga> +1001
<mvo> zyga: :)
<mvo> zyga: I can reopen my PR and add code to add the .d file
<zyga> mvo: it's not urgent but yeah, for master +1
<mvo> zyga: +1
<zyga> mvo: though we need to think about revert consequences or just managing those .d files over time
<mvo> zyga: indeed
<mup> PR snapd#6249 opened: cmd/libsnap: introduce and use sc_strdup <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6249>
<zyga> mborzecki: could you try to look at 6149 today?
<mup> PR snapd#6250 opened: data: set KillMode=process for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6250>
<mup> PR snapd#6247 closed: tests/lib: do not pick up xatts when repacking core snap <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6247>
<Chipaca> degville: "keeping it the same" is that a +1 :-D
<degville> Chipaca: yes!
<degville> :)
<Chipaca> wooowoeoeoo
<pstolowski> pedronis: you're right, it's about AddBlocked predicate
<zyga> mborzecki: hey
<zyga> remember when you asked for a cleanup of how tools are invoked from snap-confine?
<zyga> mborzecki: so you have your wish
<pedronis> pstolowski: good, but yes we'll need to think a bit what to do about that
<zyga> mborzecki: found a branch that does that :)
<mborzecki> zyga: hah :)
<Chipaca> mborzecki: i think you did half a review of 6912 already, could you finish it?
<Chipaca> #6912
 * Chipaca kicks mup
 * Chipaca jumps up and down on mup
<mborzecki> Chipaca: wrong PR #?
<Chipaca> mborzecki: https://github.com/snapcore/snapd/pull/6192
<mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
<Chipaca> #6192
<Chipaca> 6192, 6912, what EVAR
<mborzecki> aah epoch read thing
<Chipaca> yeh
<Chipaca> tempted to run with graham's +1 but thought i'd follow process for once :-p
<zyga> Chipaca: friday called and wants to +1 your PRs
<Chipaca> well there's one less to +1 now
<mup> PR snapd#6192 closed: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6192>
<Chipaca> and I guess I need to address the comments on the other ones
<Chipaca> ugh, that's too much like work
<pedronis> Chipaca: the media one has a question by me, it probably needs discussion
<Chipaca> pedronis: yeah
<zyga> brb
<Chipaca> pedronis: do you have the time to discuss?
<pedronis> Chipaca: not really today, that one we'll have to wait when we are both back
<Chipaca> pedronis: ok
<zyga> re
<zyga> mvo: hey
<zyga> mvo: do you have a sec
<zyga> https://github.com/snapcore/snapd/pull/6235 is green
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> and should make 2.36 green
<zyga> would you mind finishing your review there
<zyga> I'm happy to backport / cherry pick tests
<zyga> or other stuff
<zyga> from the corresponding master branches
 * zyga considers EODing
<zyga> unless someone wants to look at 2.36 PRs
<Chipaca> pedronis: I pushed the discussed reorg to #6104. If you won't have time to re-review, can I discard your block?
<mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<pedronis> Chipaca: yes, the direction looks what we discussed
<pedronis> Chipaca: done myself
<Chipaca> pedronis: i included your rationale in the commit message, for posterity, fwiw
<Chipaca> pedronis: thank you
<Chipaca> zyga: #6104 is now needing a second review, if you're still itching to do one
<mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<zyga> yep
 * Chipaca goes to get tea and some ibuprofen
<zyga> Chipaca: can you trade for trivial https://github.com/snapcore/snapd/pull/6249
<zyga> I wanna land it :)
<mup> PR #6249: cmd/libsnap: introduce and use sc_strdup <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6249>
<zyga> 2.36.2 looks good on suse :)
<zyga> and startup time for snaps is nice
<zyga> though I wonder if we need to refresh each snap to see the effect
<zyga> I disable/enable things to see that
<zyga> mvo: ^
<zyga> Is that expected?
<mvo> zyga: one refresh or enable/disable should be enough to fix the fontconfig cache
<mvo> zyga: (also in a meeting)
<zyga> ta
<mup> PR snapd#6236 closed: Staticcheck fixes <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6236>
<zyga> kenvandine: ping
<zyga> is this expected? https://www.irccloud.com/pastebin/G8zDQBdJ/
<kenvandine> zyga: yes... jamesh submitted a PR to Yaru to fix that
<zyga> cool
<zyga> thanks
<kenvandine> i'll check on the status
<kenvandine> it's been weeks
 * cachio lunch
<mup> PR snapd#6213 closed: interfaces: let NM access ifindex/ifupdown files <Created by alfonsosanchezbeato> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6213>
<zyga> Chipaca: +1
<zyga> mvo: suse updated :)
<zyga> error: snap "test-snapd-policy-app-consumer" has "remove-snap" change in progress
<zyga> pstolowski: ^ is that something you were describing during the standup?
<mvo> zyga: \o/
<pstolowski> zyga: hmm not really, my issue doesn't cause errors
<pstolowski> zyga: where do you see it?
<zyga> random failure on strdup
<zyga> (on that PR)
<zyga> I restarted as it looked like noise
<pstolowski> uhm
<zyga> mvo: vscode startup on leap 42.3 and TW is very good
<zyga> Chipaca: did you see my ping about http://juniper.github.io/libxo/libxo-manual.html xo?
<Chipaca> zyga: i did
<zyga> cool
<Chipaca> zyga: I'm not adding anything to my stack right now though :-)
<zyga> sure sure
<zyga> it's a C api
<zyga> but the idea is neat
<mvo> zyga: cool
<mvo> zyga: thanks for checking/confirming!
 * pedronis calls it a week
<pedronis> have a good weekend!
<cachio> mvo, 2.36.2 in candidate
<mvo> cachio: nice!
<cwayne> Now with spread results on customer hw :D
<pedronis> Chipaca: I managed to update my PR: https://github.com/snapcore/snapd/pull/5712
<mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<Chipaca> pedronis: i saw! excellent
<Chipaca> pedronis: is that enough to unblock it?
<pedronis> yes
<Chipaca> cwayne: that sounds like a good thing. Is that a good thing?
<Chipaca> pedronis: neat
<cwayne> Chipaca: no it's a great thing :)
<Chipaca> :)
<pedronis> Chipaca: if it gets green, there is really the last commit than needs a review and then it could go in
<pedronis> I mean real commit, not the master merges
<cwayne> since we've now got my team's tests plus yours running on every core update in beta :)
<Chipaca> a'ight
<mvo> pedronis: nice
<mvo> cwayne: woah, nice!
<Chipaca> what, only beta?
<Chipaca> :-D
<cwayne> beta's my jam
<mup> PR snapd#6249 closed: cmd/libsnap: introduce and use sc_strdup <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6249>
<mup> PR snapd#6251 opened: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<zyga> mvo: not sure if you EOW but I'd love an ack on https://github.com/snapcore/snapd/pull/6245
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<mup> PR snapd#6242 closed: overlord/snapstate: use file timestamp to initialize timer <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6242>
<mup> Bug #1781906 changed: Content provider interfaces introduced to snaps aren't correctly set up <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1781906>
<mup> PR snapd#6104 closed: snapctl: add "services" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6104>
<mup> PR snapd#6252 opened: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<zyga> jdstrand: hey, not sure if you want or have time on Friday evening but... https://github.com/snapcore/snapd/pull/6244 :D
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<zyga> you looked at it
<Chipaca> EOW'ing here
<zyga> o/
<Chipaca> when you see me next, december will be into two (decimal) digits!
<Chipaca> :-D
<zyga> maaan
<zyga> envy *
<Chipaca> well, unless i'm bored or something
<Chipaca> :-)
<zyga> you can always do reviews *D*
<zyga> NOT :)
<zyga> enjoy the time off
<Chipaca> if I'm tempted, instead I'll work on werm
<Chipaca> ttfn :-)
<zyga> werm?
<zyga> well, I'll find out in Dec
<jdstrand> zyga: I'll try. have a few things I must get done today
<zyga> thanks cwayne
<zyga> thank you jdstrand :)
<cwayne> zyga: <3
<kenvandine> zyga: the CLA check shouldn't fail if I'm a member of canonical, right?
<zyga> kenvandine: if it does it's a bug :)
<zyga> are you asking about https://github.com/snapcore/snapd/pull/6252 ?
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<kenvandine> zyga: yes
<zyga> review sent :)
<zyga> I should EOW
<zyga> I may be back in the office but not actively paying attention unles pinged
<zyga> *unless
<mup> PR snapd#6225 closed: tests: fix for failover test on how logs are checked <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6225>
 * cachio afk
<mup> PR snapd#6253 opened: Members of canonical LP group should pass CLA check <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6253>
<mup> PR snapd#6224 closed: interfaces: return security setup errors <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6224>
<zyga> kenvandine: https://github.com/snapcore/snapd/pull/6252/files#r237971362
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<mup> PR snapd#6254 opened: tests: improve how the log is checked to see if the system is waiting for a reboot <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6254>
<dennwc> Hi! Can anyone help me to setup snapcraft dev environment? I'm trying to fix a bug related to Go modules support, but I can't get the local version of snapcraft working.
#snappy 2018-12-01
<mup> Issue core18#93 opened: 32-bit compatibility missing on amd64 version of core18 <Created by mmtrt> <https://github.com/snapcore/core18/issue/93>
#snappy 2019-11-25
<mborzecki> morning
<pedronis> mborzecki: hi, is this known https://bugs.launchpad.net/snapd/+bug/1853512 ?
<mup> Bug #1853512: snapd can't be installed on Centos 8 <snapd:New> <https://launchpad.net/bugs/1853512>
<mborzecki> pedronis: that would be unexpected, thought snapd would be rebuilt automatically
<mborzecki> Eighth_Doctor: wouldn't snapd get and automatic rebuild when selinux-policy-base gets a bump?
<mborzecki> pedronis: i need to prep an update to 2.42.2 so we'll get a rebuild anyway
<pedronis> ok
<pedronis> mborzecki: I assigned it to you
<mborzecki> pedronis: ok
<mup> Bug #1484641 changed: snappy config command does not restart service after setting the configuration <Snappy:Won't Fix> <https://launchpad.net/bugs/1484641>
<Eighth_Doctor> mborzecki: no
<mborzecki> Eighth_Doctor: it's because the snapd-policy is outside of EPEL right?
<Eighth_Doctor> no
<Eighth_Doctor> it's because the Fedora build system can't do that
<Eighth_Doctor> it can't auto-submit a rebuild
<mborzecki> Eighth_Doctor: meh :P where do i submit the PRs?
<pedronis> mborzecki: mvo:  https://api.travis-ci.org/v3/job/615952834/log.txt  gadget-update-pc seems to have a real issue
<mborzecki> pedronis: should be a quick fix
<zyga> good morning
<pstolowski> morning
<zyga> hey PaweÅ
<pedronis> pstolowski: hi, what's blocking the preseed PRs, lack of reviews ?
<pstolowski> pedronis: yes
<pstolowski> pedronis: #7706 and #7658 are closest to be landdable i think
<mup> PR #7706: overlord/snapstate: install task edges <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7706>
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pedronis> pstolowski: I will switch to do more reviewing this week
<pedronis> mborzecki: are you working on fixing that gadget-update-pc issue?
<pedronis> pstolowski: a 2nd review for #7774 would be great
<mup> PR #7774: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7774>
<pstolowski> pedronis: sure, looking at it
<pedronis> thx
<mborzecki> pedronis: yes
<pedronis> thank you
<mup> PR snapd#7774 closed: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7774>
<pstolowski> dot-tobias: hello! was that you who reported and intended to work on a fix for https://bugs.launchpad.net/snapd/+bug/1851480 ?
<mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:Confirmed for glancr> <https://launchpad.net/bugs/1851480>
<mborzecki> heh, so core18 gadget-update test fixed, but fails on core16 now, because core18 uses pc=18, but core16 just pc, perhaps the update of gadget.yaml should be done in yaml-aware way, rather than by swapping the text file
<pedronis> mborzecki: pc for 18 has a track, pc latest is really 16
<pedronis> so that part of the tests is right
<mborzecki> pedronis: right, 18/edge contains some extra entries that aren't in latest
<pedronis> might need to talk with mvo/foundations about them
<zyga> brb, 2nd coffee needed
<mborzecki> pedronis: the test should account for that, so as far as i'm concerned the test needs fixing
<pedronis> mborzecki: sounds it need different reference info for 18 vs 16 ?
<mborzecki> pedronis: pyyaml is in core*,
<mborzecki> pedronis: so i might just generate gadget.yaml's on the fly
<pedronis> pstolowski: reviewed 7706, let me know if the comment abou edge names make sense
<pstolowski> pedronis: yes, i get your point, makes sense, thx
<pedronis> pstolowski: I did another pass on 7658, minor things
<pstolowski> thank you!
<mup> PR snapd#7782 opened: osutil: handle "rw" mount flag in ParseMountEntry <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7782>
<mup> PR snapd#7727 closed: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7727>
<Chipaca> brb, coffee break
<mup> PR snapd#7783 opened: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>
<mup> PR snapd#7770 closed: testutil, many: make MockCommand() create prefix of absolute paths <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7770>
<mup> PR snapd#7784 opened: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
<zyga> mborzecki: are you onto that master-broken thing?
<mborzecki> zyga: yes, opening it in a bit
<zyga> great, thank you
<mup> PR snapd#7785 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
<mborzecki> zyga: pedronis: ^^ should unbreak master
 * zyga looks too
<mborzecki> wish there was a way for pyyaml to preserve the structure of the document
<zyga> mborzecki: reformat with black please
<zyga> it's a good default
<zyga> and seems to be adopted across canonical now
<pedronis> mborzecki: thanks, reviewed
<mborzecki> zyga: pedronis: thanks, i'll push those in a followup if you don't midng
<zyga> not at all
<mup> PR snapcraft#2815 closed: minor developer env/doc updates <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2815>
<pedronis> mborzecki: it's fine, as I as much in the review
<pedronis> s/as I as/I said as/
 * Chipaca sets up a synchrotron in a cave to make antichampagne
<mvo> Chipaca: lol
<mup> PR snapcraft#2803 closed: snap: add license to snapcraft.yaml <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2803>
<pedronis> mvo: zyga: https://github.com/snapcore/snapd/pull/7773 will the feature flag be only for 2.42 ? did you discuss that again?
<mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <â  Critical> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
<mvo> pedronis: if everyone feels its safe to include it in 2.42 as is I'm fine with that - otherwise I think we want this behind a feature flag
<mvo> pedronis: wdyt?
<pedronis> mvo: my main input is that the feature flag doesn't make sense on master, it's fix that we want to test
<pedronis> mvo: I would like to understand what we think makes it not safe
<pedronis> it's a fairly global change, so if it's not safe, it's probably not safe very generally
<zyga> pedronis: I think mvo's concern was that it will have extremely limited testing
<zyga> pedronis: and for the point release it would be safer to put it behind a feature flag
<zyga> pedronis: so that it can be exposed to the customer that needs to use it
<zyga> pedronis: the next regular release can enable the feature flag if unset
<zyga> pedronis: so that it goes through regular testing
<pedronis> something doesn't add up for me
<mvo> pedronis: yeah, it's fine for master but I'm a bit concerned that it's too invasive for a point release
<zyga> pedronis: can you be more specific?
<pedronis> zyga: the change has two parts, one is turning keeping into unmount/mount, either we are ok with that or we aren't ?
<pedronis> the other ignoring some errors, that is more worrying, but it's a bit unclear if a feature flag will help with that or not. what sanity/safety are we losing here?
<zyga> pedronis: I think we are fine with both of those (the error is ignored for a specific reason) but the fact that it will get limited testing before hitting stable (AFAIK 2 days) is why mvo wanted to avoid the chance that we missed something and it is indeed unsafe.
<zyga> pedronis: as for testing, I will work to make sure that both unit and spread tests cover both variants for now
 * mvo is in a meeting, sry!
<zyga> pedronis: and for the next release we can change the default-if-unset to true so that everyone gets the new, improved behavior
<zyga> pedronis: and given that it will be tested over a cycle, we can release that with more confidence
<pedronis> zyga: will need also to disuss another rewrite of update-ns, I'm not a fan of the ignoring the error bit going forward
<zyga> at least that's how I understood mvo's concerns
<zyga> pedronis: that's fine, we understand how to make that possible, it's just larger in scope
<zyga> pedronis: note that ignoring the error is only safe when both patches are used
<pedronis> mborzecki: what's the status of #7732 ?
<mup> PR #7732: [PoC] many: extracted snaps mode <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7732>
<mborzecki> pedronis: we can close it, it was a temporary hack for ijohnson to try
<mup> PR snapd#7732 closed: [PoC] many: extracted snaps mode <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7732>
<pedronis> zyga: I'm worried of the added messiness in terms of tests and code of the flag, that's why I'm not a fan of having it on master
<zyga> pedronis: I see
<mborzecki> heh, #7785 is red, i can push a followup patches there anyway now
<mup> PR #7785: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
<zyga> I wonder if we could avoid that entirely with a snapd-from-branch
<zyga> so that the customer could use snapd from a branch and upgrade to stable on the regular cycle
<zyga> is that possible today?
<pedronis> in principle yes
<pedronis> pstolowski: given that #7320 and 7744 are related, you should probably pick up the former from John
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<Chipaca> pedronis: you meant 7744?
<pedronis> heh, not I meant 7740
<Chipaca> phew :)
<pstolowski> pedronis, Chipaca: sure, i can take it
<mup> PR snapd#7777 closed: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7777>
<mup> PR snapd#7785 closed: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
<mborzecki> master should be unblocked now
<pedronis> mborzecki: great, thanks
<mup> PR snapd#7786 opened: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <https://github.com/snapcore/snapd/pull/7786>
<pedronis> that's a small tweak ^
<pedronis> #7775 is also ready for review (been rebased)
<mup> PR #7775: seed: support extra snaps on top of Core 20 dangerous models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7775>
<cachio> mborzecki, hey
<mborzecki> cachio: hey, what's up ?
<cachio> I see the test gadget-update-pc is failing
<cachio> the pc-gadget.yaml on the test seeems to need an update
<cachio> mborzecki, https://travis-ci.org/snapcore/snapd/jobs/616564112#L3392
<cachio> mborzecki, can you confirm that?
<mborzecki> cachio: the fix landed half an hour ago :)
<cachio> mborzecki, ahhh, nice
<zyga> brb
<zyga> thank you for fixing master mborzecki
<mup> PR snapd#7721 closed: gadget: add support for hybrid partitioning schemas <Simple ð> <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7721>
<mup> PR snapcraft#2821 opened: meta: remove __dict__ usage in Snap  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2821>
<ijohnson> zyga: thanks for the response on that post, just read it and it all makes sense, I just wasn't sure if there was some deeper reason to that limitation or not
<zyga> ijohnson: the deeper reason is: we didn't anticipate it I guess
<zyga> ijohnson: as for the 200 ms optimization
<zyga> ijohnson: I think it's worth it for reliability and simplicity
<ijohnson> yah I don't think it's worth it right now
<zyga> ijohnson: also, we could change the way themes are used using tmpfs layout instead of mimic
<ijohnson> just something I wanted to bring up mostly so we don't forget about it later :-)
<zyga> one layout, many content connections == more explicit and obvious as to what is going on
<ijohnson> hmm interesting point about the many themes
<ijohnson> I don't have the numbers with me, but IIRC when I tested the various permutations of layouts and themes, the big time we spend right now for these snaps is in the layouts, not in the themes
<zyga> yeah but it's all one thing
<zyga> not two things
<zyga> if we can change $anything to avoid the need to use mimics it will both be simpler to understand and faster
<ijohnson> the themes results in a lot of mounts, but not a lot of computation (i.e. total speedup from removing themes wasn't measurable, but removing the mimics was)
<ijohnson> yes agreed
<ijohnson> mimics == complicated and slow
<ijohnson> (relatively speaking)
<zyga> yes
 * cachio lunch
<jdstrand> roadmr: hi! can you pull 20191125-1519UTC? note, I'm off Wed-Fri
<roadmr> jdstrand: sure! so am I, heh, so no guarantees it'll be rolled out before Monday, but I'll try to leave everything merged and QAd so someone else can action that
<jdstrand> roadmr: monday rollout seems reasonable since we are off
<Chipaca> saw a tweet just now and thought "ooh, they're using snaps at nasa?"  â¦ https://www.theregister.co.uk/2019/11/25/space_roundup/
<Chipaca> (short answer: mu)
<pstolowski> ijohnson: hey, would you find a moment for \https://github.com/snapcore/snapd/pull/7740 ?
<mup> PR #7740: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7740>
<mup> PR snapcraft#2818 closed: project: pivot `info` from ProjectInfo to Snap <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2818>
<mup> PR snapd#7744 closed: snap-bootstrap: set expected filesystem labels <uc20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7744>
 * Chipaca shakes fist at universe and goes for a cuppa tea
<pedronis> a 2nd review for #7786 would be great (it's small)
<mup> PR #7786: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <https://github.com/snapcore/snapd/pull/7786>
<pstolowski> pedronis: https://github.com/snapcore/snapd/pull/7780 can land
<mup> PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
<mup> PR snapd#7786 closed: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7786>
<pedronis> thx
<Chipaca> pedronis: +1
<Chipaca> heh, that
<pedronis> cachio: can you give a quick look at #7780 fyi
<mup> PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
<mup> PR snapd#7781 closed: seed: fix confusing pre snapd dates in tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7781>
<mup> PR snapd#7780 closed: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7780>
<mup> PR snapd#7753 closed: po: sync translations from launchpad <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7753>
<mvo> yay, below 70!
<mup> PR snapd#7740 closed: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7740>
<mup> PR snapd#7787 opened: many: share single implementation to list needed default-providers <Created by pedronis> <https://github.com/snapcore/snapd/pull/7787>
<ijohnson> pstolowski: sure it's on my queue, should get to it in my PM
<ijohnson> pstolowski: hmm seems I was too slow and mvo already approved/merged it :-)
<pstolowski> ijohnson: hah, indeed, mvo was faster :)
<pstolowski> anyway, thanks, both of you :)
<mvo> my pleasure
<mup> PR snapd#7788 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
<mborzecki> pedronis: ^^
<mborzecki> wrapping it up, need to go and pick up the kids from some extra classes and help out with the homwork a bit
<sdhd-sascha> is it correct, the the build base here is core20 ? https://github.com/snapcore/core20/blob/master/snapcraft.yaml
<sdhd-sascha> Just found, how to build an image: https://discourse.ubuntu.com/t/building-multipass-images-with-packer/12361
<sdhd-sascha> Hope i will find the source, for the core20 multipass image... ð¶
<ijohnson> hey diddledan, you around? got a question for you about https://github.com/diddlesnaps/supertuxkart/blob/master/libopenh264-helper/libopenh264/library-exports
<ijohnson> ugh github is being slow/is down
<Chipaca> sdhd-sascha: what are you trying to do with core20?
<sdhd-sascha> just want to see if the eoan 19.10 packages from sway, would run inside of a snap. I know i could create a squash, or use the same patches, etc... I figured out, that the core18 is the same as ubuntu-core-18-amd64.img... Know i need to know how to add the image into multipass. Then i found that inside _multipass.py:46 is core18 and core...
<sdhd-sascha> i mean, add sway as stage-package and do a black box comparison. Chipaca:
<sdhd-sascha> Chipaca: ;-)
<sdhd-sascha> The problem is that sway, with sys_cap_admin and suid inside the snap, do so many fork's and execv.. calls, that somewhere the environment goes away (LD_LIBRARY_PATH). And "strace -f" hangs if sway is started with this privileges. But the current version of eoan (debian) has some patches, where no suid and no "setcap" is needed. So i would just try if the eoan packages would work. I don't want to do a dist-upgrade
<sdhd-sascha> inside of core18. Maybe a apt-build...
<sdhd-sascha> have also considered sway linking static, then the LD_LIBRARY_PATH does not matter.
<sdhd-sascha> yesterday i build wlroots as meson-subprojects, which has the affect, that systemd was recognized. (didn't tested to start sway over systemd yet... this should work without cap's)
<sdhd-sascha> And i experiment with dbgsym's inside of's snap's because at some stage the my kms/drm drivers crashed on start from tty.
<sdhd-sascha> Chipaca: and so on ... :-D
<Chipaca> ah, the weird compositor that needs crazy capabilities
<Chipaca> o...k :)
 * Chipaca isn't running that any time soon
<sdhd-sascha> Well, back to my question. Did i need patch snapcraft or multipass? Or can i just add the daily cloud-images from ubuntu.com somewhere and install snapcraft-edge ...
<sdhd-sascha> But, is ok. I could also figure it out, sometime
<sdhd-sascha> Chipaca: I have to go the other way yet. Unless I want to build the ubuntu-core images myself. 'Cause the CI/CD doesn't produce the needed images for multipass... https://github.com/CanonicalLtd/multipass/pull/1192
<mup> PR CanonicalLtd/multipass#1192: add core20 image urls <Created by sd-hd> <https://github.com/CanonicalLtd/multipass/pull/1192>
 * cachio afk
#snappy 2019-11-26
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mup> PR snapd#7782 closed: osutil: handle "rw" mount flag in ParseMountEntry <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7782>
<mup> PR snapd#7778 closed: seccomp: allow chown 'snap_daemon:root' and 'root:snap_daemon' <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7778>
<zyga> good morning
<zyga> wow, everyone is up early
<mvo> hey zyga - welcome to the right TZ!
<zyga> mvo: ... :D
<zyga> mvo: I took Bit for a walk at 1:30AM
<zyga> mvo: but I feel okay now
<zyga> mvo: I try to take a nap mid-day to compensate
<zyga> mvo: I'll jump into the fray soon
<mborzecki> zyga: hah 1:30am ;P sounds like a different tz to time
<mvo> zyga: cool
<mborzecki> mvo: regarding https://github.com/snapcore/snapd/pull/7772#pullrequestreview-322085662 maybe something the generators could do, but those run before local fs mounts, so it'd have to be in the core snap if i understand it correctly
<mup> PR #7772: wrappers: write and undo snapd services on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
<mvo> mborzecki: aha, interessting idea
<pedronis> mborzecki: mvo: hi, should we have a chat about the snapd configure issues?
<mborzecki> pedronis: hi, sure
<pedronis> mborzecki: mvo: standup?
<mvo> pedronis: ok
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#7765 closed: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7765>
<pedronis> mvo: I did a pass on #7746
<mup> PR #7746: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
<mup> PR snapd#7789 opened: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7789>
<tomwardill> hi all, store team here. Downloads might see some errors atm, we're working on it
<pstolowski> tomwardill: hi, thanks for heads up!
<mvo> pedronis: thank you!
<BjornT> mvo: hi! how can i try out this snapfuse fix on bionic? https://bugs.launchpad.net/snapd/+bug/1817276
<mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
<BjornT> mvo: it seems like the snapfuse binary comes from the snapd deb, which is still 2.40
<mvo> BjornT: we have a updated it in bionic-proposed
<mvo> BjornT: I think the sru was actually validated so it's mostly a matter of getting this released
<mvo> BjornT: I can poke foundatoins
<BjornT> mvo: cool, i'll install it from -proposed then
<mborzecki> mvo: pedronis well, the spread test seems to be working now with the tweaks in configstate
<BjornT> mvo: nice. confirmed that the fix is a major improvement. after upgrading snapd to 2.42, my load average isn't constantantly growing anymore and back to normal levels
<mvo> BjornT: yay! if you could give me numbers from your workload that would be awesome
<BjornT> mvo: what kind of numbers? i haven't done any performance tests yet. but before snapfuse was taking 100% constantly, probably while syncing images, which requires a lot of writing. now it still can burst up to 90%, but it quickly goes down again.
<BjornT> mvo: and the load average just kept growing. it was up to 900 before i upgraded snapd
<zyga> 900?!
<mvo> BjornT: thanks, that was what I was looking for, some details :)
<pedronis> mborzecki: great
<pedronis> mvo: reviewed 7789
<pedronis> pstolowski: thanks for the review, I applied the suggestion
<pstolowski> yw
<mvo> pedronis: thank you!
<pedronis> Chipaca: is #7671 ready for review ?
<mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
<Chipaca> pedronis: AFAIK :)
<pedronis> Chipaca: ok :)
<pedronis> mvo: now that I remembered how the current bootloader.Options flag is used by lk, I think we do want a 2nd flag, probably just InstallMode bool (would be false for UC 16 / 18)
<pedronis> mvo: doesn't block the current PR but would be relevant for next step
<mvo> pedronis: I was thinking about a "Recovery" flag that could be used by "bootloader.Find()" and "InstallBootConfig()" to tell the system to install bootconfig for recovery or real-boot. That should also address this, but I'm happy with InstallMode as well
<pedronis> mvo: that works too, Recover = true = InstallMode
<pedronis> Recovery
<mup> PR snapd#7746 closed: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7746>
<pedronis> Chipaca: does #7671 need a master merge?
<mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
<Chipaca> pedronis: ah, maybe; i'll look in a bit
<pedronis> Chipaca: I see things that I thought I reviewed already, but maybe I'm confused (that's possible)
<zyga> sil2100, ogra: do you know who is maintaining the pi gadgets today
<zyga> degville: I was looking at https://snapcraft.io/docs/gadget-boot-assets and noticed it's not linked from https://snapcraft.io/docs/gadget-snap - just wanted to check with you if I should edit and make the connection or is there another path somewhere
<degville> zyga: I think you're right - I'd not added the link yet pending the boot assets edits and final changes, but it makes better sense to link it now.
<degville> (as doc and boot assets are in pretty good shape)
<mup> PR snapd#7787 closed: many: share single implementation to list needed default-providers <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7787>
<mup> PR snapd#7790 opened: boot: add boot.Modeenv that can read/write the UC20 modeenv files <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7790>
<mup> PR snapd#7789 closed: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7789>
<mvo> pedronis_: hopefully simple and then I can build on top of this
<pedronis> mvo: commented
<mvo> pedronis: thank you!
<Chipaca> pedronis: ok if i rebase 7671?
<Chipaca> pedronis: i've rebased 7671
<Chipaca> pedronis: it looks a lot more like a patch patch now
<mvo> pedronis: addressed your comments, thanks again
<sil2100> zyga: hey! That's us (foundations), but it's basically waveform mostly
<zyga> sil2100: thanks, I'll reach out to him
<pedronis> Chipaca: thx, I will look in a bit
<pedronis> mvo: that's not the rename I proposed, I proposed to match what we use in the file (up to format)
<pedronis> :)
<pedronis> mvo: ah, not the code is right, but the commit says another thing
<pedronis> mvo: +1 with some more comments, mostly about the tests
<mvo> pedronis: thank you, on it!
<mup> PR snapd#7791 opened: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7791>
<mborzecki> mvo: pedronis: i've updated #7788 please take a look
<mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <â  Critical> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
<mborzecki> need to sort out my flights
<pedronis> mborzecki: thanks, will look in a bit
<pedronis> Chipaca: reviewed, maybe pstolowski can give a look too
<zyga> mborzecki: about flights, I looked at trains
<zyga> mborzecki: but it's a no-go because it's impossible to get tickets for a ride this distant
<zyga> mborzecki: assuming that train schedules don't change it's a whole-day trip with one stop in Berlin
<mborzecki> zyga: and it's probably half a day
<zyga> mborzecki: and the price is very competitive with flying
<zyga> mborzecki: even if you consider first class actually
<zyga> mborzecki: but I decided not to use it because << 2 hours is meh-good-enough
<pstolowski> pedronis, Chipaca will do
<zyga> mborzecki: there are a number of connections, some take over half a day and involve many stops, some are fast
<pedronis> mborzecki: done, thank you
<pedronis> mborzecki: have you looked at the other issue (installing core on a snapd-only system with defaults) or not yet?
<mborzecki> pedronis: not yet, spent silly amount of time fighting the configstate handlers test
<mvo> 7790,7791 should be simple reviews and unblock some more of the early boot work
 * mvo considers lunch
<pedronis> mborzecki: lots of setup needed
<mborzecki> pedronis: might have overdone it a little
<zyga> jdstrand: good morning
<mup> PR snapd#7759 closed: devicestate: add reading of modeenv to uc20 firstboot code  <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7759>
<pstolowski> pedronis, Chipaca will do
<pstolowski> ups, wrong window
<zyga> mborzecki: 2nd +1 on https://github.com/snapcore/snapd/pull/7788#pullrequestreview-322948196
<mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
<mborzecki> zyga: thanks
<zyga> I'll make coffee and resume patches
<mborzecki> cmatsuoka: hi, quick question about #7743, in the real world scenario, we wouldn't need sfdisk --force, because snap-bootstrap will be running off initramfs right?
<mup> PR #7743: snap-bootstrap: force partition table operations <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
<cmatsuoka> mborzecki: it's likely that it will be needed in the real case, I added snap-bootstrap to the spike and it required --force
<cmatsuoka> mborzecki: --force was completely under my radar until I tested it in a real scenario
<cmatsuoka> mborzecki: the same happened with the udev node creation, for some reason partx -u triggers node creation but blockdev --rereadpt doesn't
<cmatsuoka> mborzecki: I started to check the partx source code to see what exactly it's doing there, but it does quite a lot
<mborzecki> cmatsuoka: interesting, i would guess that sfdisk handles that when it triggers the kernel to reread the partition table
<mborzecki> cmatsuoka: afaiu that's what partx does by doing a bunch of ioctls() though it passes an actual partition number there
<mborzecki> cmatsuoka: either way, this goes through the kernel -> devfs, and in parallel to udev which does symlinking under /dev/disk/by-*/, that's probbaly why the extra delay is needed
<cmatsuoka> I also tried to manually run udevadm trigger but it didn't do anything
<mborzecki> cmatsuoka: was any paritition from taht device mounted at the time when sfdisk ran?
<cmatsuoka> According to a comment in the partx source code, it needs a few ms to settle after the operation
<cmatsuoka> mborzecki: hmm, yes, it's possible that we had partitions mounted in initramfs
<cmatsuoka> mborzecki: ah, I guess core was mounted from seed directly at that point
<mborzecki> cmatsuoka: that would explain why the disk was seen as 'used'
<cmatsuoka> mborzecki: yes, indeed. but we can't unmount everything, we need seed an boot
<cmatsuoka> and boot
<mborzecki> cmatsuoka: right, i guess there's no way around that, so --force seems ok
<mborzecki> cmatsuoka: perhaps that's why you needed to call partx
<cmatsuoka> mborzecki: about the partx -u, I don't like the idea that we're relying on a side effect of a specific utility -- ideally I'd like to redo whatever partx is doing there
<cmatsuoka> but that would take some time to analyse
<mborzecki> cmatsuoka: was there any mesage from fdisk? specificaly thinking https://github.com/karelzak/util-linux/blob/master/libfdisk/src/context.c#L833-L840
<cmatsuoka> mborzecki: no such message, the PT re-read was apparently successful
<mborzecki> heh, fun ;)
<cmatsuoka> those real life problems are very annoying!
<cmatsuoka> also I hope that kernel 5.4 doesn't crash in firstboot, 5.3 did but I still didn't check why
<cmatsuoka> mborzecki: I think I should add an XXX note there
<mborzecki> cmatsuoka: yup, sounds like a good idea
<cmatsuoka> mborzecki: doing that
<mup> PR snapd#7790 closed: boot: add boot.Modeenv that can read/write the UC20 modeenv files <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7790>
<mborzecki> anyone know of a tool that lists what desktop files are visible?
<mup> PR snapd#7760 closed: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7760>
<zyga> pedronis, mvo: I'll check if there are any open bugs that are related to nested mimics and see if they have regression tests
<mup> PR snapd#7792 opened: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7792>
<mup> PR snapd#7671 closed: overlord/patch: normalize tracking channel in state <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7671>
<Chipaca> *gasp* i was supposed to wait for pstolowski :-(
<mvo> pedronis: 7792 should also be easy hopefully
<pstolowski> Chipaca: i'm finishing it atm..
<Chipaca> pstolowski: please tell me it's not on fire :-|
<mborzecki> mvo: pedronis: #7788 is green
<mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
 * cachio lunch
<thresh> hi.  cant launch chromium anymore, on debian: https://paste.debian.net/1118076/
<thresh> installed:   78.0.3904.108            (958) 160MB -
<thresh> any ideas? thank you.
<Chipaca> thresh: can you pastebin 'snap version' please?
<Chipaca> who was it that was looking at the /sys/kernel/mm/transparent_hugepage/hpage_pmd_size thing
<thresh> sure thing.  there you go Chipaca: http://paste.debian.net/1118077/
<Chipaca> mvo: you do remember, offhand?
<Chipaca> yeah, 42 on a 5.3
<Chipaca> there was somebody looking at this, but i don't remember what the conclusion was
<Chipaca> jdstrand: is it expected that chromium tries to do things that would require hardware-observe?
<pedronis> Chipaca: I saw some chromium related stuff in some of recent jdstrand PRs
<pedronis> not sure it relates or not
<pedronis> maybe he can say
<jdstrand> Chipaca: what things?
<Chipaca> jdstrand: looks like it's trying to read /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
<Chipaca> as per the pastebin above
<Chipaca> jdstrand: https://paste.debian.net/1118076/
<zyga> mvo: can you double check https://github.com/snapcore/snapd/pull/7773 please
<mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
<zyga> mvo: it has +2 and as soon as it's green I'd like to merge it and open a backport for 2.42.3
<jdstrand> Chipaca: seems like we need something added to PR 7779
<mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
<jdstrand> Chipaca: I'll do that in a bit
<Chipaca> jdstrand: is there something thresh can do to get unblocked?
<Chipaca> i'm guessing 'reboot into pre-5.3 kernel' would work but not be a nice way out
<jdstrand> Chipaca: oh, actually, that is snap-update-ns.chromium
<zyga> o/
<thresh> It's not a big deal.  I use firefox mainly anyway.  Just something that is probably best reported & fixed :)
<Chipaca> thresh: <3
<pedronis> jdstrand: mvo is looking at doing a 2.42.3, it would be good to know if we need things in it for this
<jdstrand> I'll look into that access. one could modify /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium
<jdstrand> thresh: ^
<jdstrand> eg, add '/sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,' then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium'
<jdstrand> that only works until snapd refreshes the policy of course (then you'd have to do it again)
<jdstrand> pedronis: ack
<Chipaca> jdstrand: thank you
<thresh> jdstrand, huh.  well that worked to remove the apparmor denial line from dmesg indeed.
<thresh> but chromium still crashes with the same message
<thresh> so maybe those are not related.
<Chipaca> oSoMoN: ^ is that a 'you' thing?
<Chipaca> thresh: at this point i'd say it's probably best to open a topic in forum.snapcraft.io, so it can be looked at async
<thresh> right
<Chipaca> either that or a good ol' bug :)
<Chipaca> but forum is probably easier
<thresh> I'm going to try a different user / clean profile etc
<oSoMoN> thresh, mind filing a bug at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+filebug ?
<mup> PR snapd#7793 opened: devicestate: read modeenv early and store in devicestate <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7793>
<oSoMoN> Chipaca, the chromium snap is a 'me' thing indeed
<thresh> oSoMoN, I will, thanks!
<mup> PR snapd#7791 closed: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7791>
<Chipaca> oSoMoN: :)
<mvo> zyga: sure, looking now
 * Chipaca grabs a cuppa tea and tries to stop eating biscuits
<Chipaca> I visited my mum on sunday and cam back with a metric ton of chocolate chip
<Chipaca> send help
<mup> PR snapd#7773 closed: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <â  Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7773>
<zyga> Chipaca: send chocolate :)
<zyga> Chipaca: we should take preorders on treats for Fra
<Chipaca> Fra is three months away
<zyga> Chipaca: with everyone taking trains we can bring anything :)
<Chipaca> in fact, fra is two weeks before i run the lisbon half
<Chipaca> so no treats!
<mvo> mborzecki: I think we can merge 7788 - do you want to squash merge or do you prefer the commits and then we open a 2.42 version ? either way is fine with me. if squash I think it would be great if you could do it yourself so that you can decide on the commit message
<zyga> mvo: https://github.com/snapcore/snapd/pull/7794
 * zyga goes for lunch
<mup> PR #7794: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>
<mup> PR snapd#7788 closed: overlord/snapstate: pick up system defaults when seeding the snapd snap <Squash-merge> <â  Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
<mup> PR snapd#7794 opened: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>
<mup> PR snapd#7795 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap (2.42) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7795>
<mborzecki> mvo: ^^
<ackk> zyga, hi, I just ran again into the issue with the maas snap reporting that the command is not there, when the snap is installed. this time it happened right after installing the snap from the store
<ackk> zyga, any useful info I can gather ?
<zyga> ackk: oh my :D
<zyga> ackk: what what the exact error message?
<ackk> $ maas
<ackk> execv failed: No such file or directory
<zyga> ackk: this is worrying, so it was not a "snap try" version
<ackk> zyga, it's odd because every time I've seen it happen, it was just after I ran maas init
<zyga> ackk: did you have a snap-try version before though?
<zyga> and then installed from the store on top of that?
<ackk> zyga, that's a good question, I'm not sure
<mvo> mborzecki: \o/
<zyga> ackk: that might explain why
<mvo> pedronis: you mentioned another potential thing we need for .3 ?
<zyga> ackk: we actually landed a feature that might help
<ackk> zyga, can I check somehow?
<zyga> ackk: it fixes a whole class of issues
<zyga> ackk: try edge when it builds please,
<ackk> zyga, I would have an x1 dir if I had upgraded from try right?
<zyga> yes
<zyga> or x$something
<ackk> zyga, then no, I only have one revision
<ackk> /o\
<zyga> ackk: any ideas on how to reproduce are welcome
<zyga> ackk: to finish that thought though: https://github.com/snapcore/snapd/pull/7773 is what I was referring to
<mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <â  Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7773>
<zyga> ackk: it introduces snap set core experimental.robust-mount-namespace-updates=true
<zyga> ackk: which changes how mount namespace is updated
<ackk> zyga, that's not yet in edge though?
<zyga> ondra: ^ btw, it landed, we're going to be good for release soon
<zyga> ackk: no, it's just in for a few minute
<ackk> zyga, so, snapd edge ?
<ondra> zyga cool, I will run edge on one of the devices and confirm it is updating ( and I will also give customer heads up)
<ackk> zyga, and that snap set
<ackk> zyga, is that valid for core18 as well?
<zyga> ackk: snapd edge or core edge once it builds
<zyga> ackk: it works across all versions
<ackk> cool
<mborzecki> pedronis: mvo: yeah, looks like we have a problem with subsequent install of core on a core18 device
<mvo> thanks zyga and mborzecki
<mvo> mborzecki: meh, do you have more details?
<zyga> oh
<zyga> mborzecki: so more fixes for 2.42.x required?
<zyga> mvo: do you want to cherry-pick any of jdstrand's recent interface fixes?
<zyga> mvo: I can cherry-pick them back to offload you
<mborzecki> mvo: pedronis: https://paste.ubuntu.com/p/mpV9Nr8v9H/
<mborzecki> zyga: yes, think so
<mup> PR snapd#7761 closed: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7761>
<zyga> ijohnson: hey
<zyga> ijohnson: I'd like to land https://github.com/snapcore/snapd/pull/7783
<mup> PR #7783: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>
<zyga> ijohnson: I explained why the suggestion doesn't work (ordering)
<ijohnson> sure let me take a look
<zyga> ijohnson: I'm happy to iterate on ideas but I'd like to merge this and unblock another PR
<zyga> ijohnson: so that the useful improved debug output from snap-update-ns doesn't get stuck/lost
<mup> PR snapd#7796 opened: tests/main/ubuntu-core-config-defaults-once: make sure configuration defaults are applied once <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7796>
<zyga> dot-tobias: hey
<zyga> dot-tobias: please check out updates to https://bugs.launchpad.net/snapd/+bug/1844496
<mup> Bug #1844496: âDevice or resource busyâ error during snap refresh when using layout with variable <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1844496>
<mup> PR snapd#7797 opened: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7797>
<mvo> zyga: only if we really need them for .3
<zyga> mvo: ok
<mvo> mborzecki: aha, so this is the defaults that get reapplied?
<pedronis> mborzecki: bad but expected
<pedronis> the fix should be simple as discussed
<pedronis> in snapstate
<mvo> pedronis: that's not .3 criticial, is it?
<ijohnson> zyga: approved, but please note my response :-) thanks
<zyga> looking
<zyga> and thank you :)
<mvo> pedronis: did you mention earlier anything else criticial for .3?
<pedronis> mvo: jdstrand was looking into chromium failing in some places with denials
<jdstrand> mvo: when do you expect 2.43 to go out? I ask cause ondra needs raw-volume soon and PR 7779 is also interesting
<mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
<jdstrand> mvo: (these might be candidates for .3)
<mvo> jdstrand: we do a .3 today/early tomorrow, once that is in candidate I will branch 2.43
<jdstrand> mvo: so, a couple of weeks?
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/7777 would be nice for people to have
<mup> PR #7777: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7777>
<jdstrand> mvo: that is a real clean cherrypick
<mup> PR snapd#7783 closed: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7783>
<mvo> jdstrand: 2.43 is ~4 weeks away
<zyga> ijohnson, mborzecki: https://github.com/snapcore/snapd/pull/7784 is no longer stacked. It's not urgent though
<mup> PR #7784: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
<ijohnson> zyga: yes will review after I submit a PR changing that to a list for you :-)
<mvo> jdstrand: 7777 is merged
<zyga> ijohnson: sounds great :)
<zyga> mvo: let's cherry pick it
<jdstrand> mvo: ah, cool
<mvo> zyga: cherry pick which one?
<mvo> zyga: I cherry picked 7777
<jdstrand> pedronis: I added the comment to https://github.com/snapcore/snapd/pull/7779
<mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
<zyga> mvo: ah, perfect
<zyga> yeah, that one
<zyga> it's just a pair of denials for something that is not allowed
<jdstrand> pedronis: assuming you are happy with it, this would be a candidate for 2.42.3 for mvo imho
<zyga> mvo: and cuts logging
<pedronis> jdstrand: which one?
<pedronis> 7779 ?
<jdstrand> ondra: how fast can you switch over to raw-volume in that snap? trying to figure out if this must be in 2.42.3 or waiting for 2.43 as planned (at least a week more if 2.43)
<jdstrand> pedronis: 7779 has the comment change, yes. that I think would be good in .3 and is ready to go once you do final review (you have a request changes)
<ondra> jdstrand it's not time critical as they are using system-files. And switching would need to be added to customers dev cycle
<ondra> jdstrand so I'd not gate 2.43 with it
<jdstrand> pedronis: I also updated PR 7768 (raw-volume), but per ondra, this is not critical for 2.42.3
<mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<ondra> jdstrand and thank you for working on it. I really like the PR
<jdstrand> ondra: cool, yw
<pedronis> jdstrand: looking at 7779 in a short bit, having parallel discussions
<jdstrand> mvo: I'm investigating thresh' denial, but it isn't critical and will be in a separate PR
<jdstrand> mvo: ie, I might have a small PR. I'm not changing 7779
<jdstrand> mvo: in case it wasn't clear. ignore PR 7768 (raw-volume) for 2.42.3
<mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<pedronis> jdstrand: done with 7779, it's ok for .3 for me, if you are comfortable with that yourself
<mvo> jdstrand: thanks! ok, please tag everything you want for 2.42 with the 2.42 milestone
<pedronis> jdstrand: thanks for the work on raw-volume, I will re-review it,  not today though given is not a blocker
<jdstrand> mvo: ok, https://github.com/snapcore/snapd/pull/7779 updated, though it has to run through spread for the comment update that was requested
<jdstrand> (that is happening now)
<mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
<mup> PR snapcraft#2822 opened: xattrs: ignore errors if SNAPCRAFT_BUILD_INFO is unset <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2822>
<mup> PR snapcraft#2823 opened: xattrs: switch to python's os package for reading/writing xattrs <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2823>
<mup> PR snapd#7798 opened: interfaces/browser-support: allow reading status of huge pages <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>
<jdstrand> mvo: ok, PR 7798 milestoned for 2.42.3
<mup> PR #7798: interfaces/browser-support: allow reading status of huge pages <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>
<zyga> jdstrand: FYI, there's a corresponding launchpad milestone, if there are bugs you can have them target that release
<jdstrand> zyga: ack
<mvo> jdstrand: thank you
<zyga> brb, tea
<pedronis> mvo: what are the next UC20 PRs that need review?
<mvo> pedronis: 7792 should be an easy one
<mvo> pedronis: then 7793 which is also easy
<mvo> pedronis: and 7797 should also be easy, I tried to make them all bite-size :)
<mvo> pedronis: once 7793 is in I will do one more and then help with 7762
<pedronis> mvo: thanks, not sure how much more I will do tonight, but at least I know where to start tomorrow
<mup> PR snapd#6436 closed: interfaces: add system-backup interface <Needs Samuele review> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6436>
<ijohnson> zyga: alright here you go https://github.com/snapcore/snapd/pull/7799 I even benchmarked it for you :-)
<mup> PR snapd#7799 opened: osutil/mount: de-duplicate code to use a list <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
<mup> PR #7799: osutil/mount: de-duplicate code to use a list <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
<jdstrand> degville: hey, fyi, I took a crack at https://forum.snapcraft.io/t/the-system-backup-interface/14348 and updated https://forum.snapcraft.io/t/supported-interfaces/7744
<mup> PR snapd#7800 opened: tests: add Ubuntu Eoan to google-sru backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7800>
<jdstrand> ogra: hey, are there some official (or at least, something you use) docs for booting a rpi off of usb hard drive?
<jdstrand> ogra: googling finds me stuff, but I don't know if I should trust it
<zyga> ijohnson: how would it perform if you added a break on flags == 0?
<ijohnson> zyga: hmm, let me see
<ijohnson> zyga: well looking at it before I even write the code, none of the benchmarks I have will result in that because flags isn't 0 with any of the test cases
<ijohnson> zyga: is 0 a common case for mounts we do? if so I can add it to the test case, but it feels like that wouldn't happen "in the wirld"
<ijohnson> s/wirld/wild/
<zyga> ijohnson: zero mid-loop
<zyga> It will usually have one or two flags
<ijohnson> ah I see what you mean
<zyga> ijohnson: we could even reorder flags to put most common first
<zyga> ijohnson: thank you for doing that
<ijohnson> yes good point if we are going to break early then putting most common flags first makes a lot of sense
<zyga> ijohnson: sorry for being absent
<zyga> ijohnson: I'll show you what I was doing
<ijohnson> zyga: don't worry about it
<thresh> oSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1854091 there you go
<mup> Bug #1854091: [snap] traps on start <chromium-browser (Ubuntu):New> <https://launchpad.net/bugs/1854091>
<thresh> oSoMoN, let me know if I can provide any more information.  thank you!
<zyga> ijohnson: https://twitter.com/zygoon/status/1199399096399859712
<ijohnson> :-) seems like a better use of time than looking ay my silly optimizations of a couple nanoseconds
<mvo> pedronis: thank you!
<zyga> mvo: gadget update pc fails on the release branch
<zyga> mvo: I think we need to backport the fix for that one first
<mvo> zyga: uh, right. are you on this or shall I have a look?
<zyga> I'll find it and send it
<zyga> mvo: just woke up :)
<zyga> done
<mup> PR snapd#7801 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml (#7785) <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
<murthy> why mojo video decoder is not enabled for chromium snap?
<mvo> zyga: thank you!
<mup> PR snapd#7802 opened: update system-backup tests to not check for sanitize errors related to os <Simple ð> <â  Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7802>
<jdstrand> mvo: erf, ^ needed for master
<jdstrand> mvo: basically, something changed out from under the system-backup PR and the tests weren't re-run before committing. this fixes that
<murthy> Reference article: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-73-Linux-Mojo-Video-Dec
<murthy> according to the above article chromium has enabled mojo video decoder by default on windows
<murthy> and chromium provides hardware acceleration for video playback via mojo video decoder
<murthy> This is the bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=522298
<murthy> According to the Comment 51 in the bug tracker you can enable mojo decoder by setting the gn arg of "use_vaapi" to true
<murthy> during compilation I mean
<Chipaca> oSoMoN: ^
<pedronis> jdstrand: yes, our CI is fragile to that, it's a good idea to merge master in any long lived PR
<jdstrand> pedronis: yeah, that is what I was thinking :\
<oSoMoN> thresh, Chipaca:Â thanks
<mvo> jdstrand: thank you
<mup> PR snapcraft#2824 opened: Support for go.mod <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2824>
<mvo> thanks zyga for 7801
<zyga> :)
<ijohnson> oh zyga btw adding a check in the loop slows everything down oddly enough :-(
<ijohnson> https://www.irccloud.com/pastebin/F2LyBHTL/
<vidal72[m]> murthy: do you know any distro that enabled that option? I assume it's disabled for a reason
<murthy> vidal72[m]: probably fedora
<vidal72[m]> murthy: nope, see comment https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_1810
<vidal72[m]> https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_23
<vidal72[m]> I don't think it's worth hitting all regressions others had with vaapi
<vidal72[m]> without upstream support this is hopeless
<vidal72[m]> murthy: Arch linux also disabled vaapi after trying it https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=493cb5bf7b8453f628ee74ae75add8699ad244f0
<murthy> vidal72[m]: It only enables mojo video decoder, users have to enable the "Override software rendering list" flag to enable hardware acceleration using vaapi
<murthy> checking
<murthy> It seems they had specifically reverted that patch
<vidal72[m]> heh
<vidal72[m]> RIP vaapi :(
<murthy> Its just that I tried a chromium build from an an unofficial ppa and it seems stable
<murthy> vidal72[m]: Intel is not doing a good job for Linux
<vidal72[m]> I think it depends on hardware
<murthy> right
<murthy> Mine is a kabylake
<vidal72[m]> intel is still miles ahead of amd and nvidia :)
<murthy> what?
<vidal72[m]> I heard that most vaapi issues come from amd
<murthy> vidal72[m]: also downstream packaging restrictions
<murthy> This is the article that said vaapi was enabled in fedora https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snaps-Chromium-VA-API
<murthy> phoronix fellows know how to get the clicks
<vidal72[m]> murthy: then enabled it then disabled, same as Arch
<vidal72[m]> *they
<murthy> ya
<murthy> Do you know this ppa? Can I trust it? https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-beta
<vidal72[m]> I don't know it
<murthy> ok
<murthy> vidal72[m]: Thanks for the support
<zyga> mvo: is master still broken
<zyga> I can jump into that
 * zyga checks
<zyga> heh
<zyga> funny
<mvo> zyga: didn't jamie fix this?
<zyga> ah, I see
<mvo> zyga: unit test failure it seems, fun
<zyga> I'll send a useful patch nonetheless
<zyga> we have some leftover junk
<mvo> zyga: invalid title
<mvo> zyga: fun!
<mvo> zyga: restarted the build
<zyga> eh
<zyga> :D
<zyga> must be OMG RELEASE DAY
<mvo> zyga: haha yes
<zyga> mvo: https://github.com/snapcore/snapd/pull/7803
<mup> PR #7803: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
<mvo> zyga: nice, thank you
<mup> PR snapd#7803 opened: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
<zyga> mvo: meanwhile https://github.com/snapcore/snapd/pull/7801 is still yellow
<mup> PR #7801: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
<mvo> zyga: yeah, it's a bit sad
<zyga> about 20 minutes left
<zyga> if it passes
<mvo> zyga: I call it a day, hopefully in 8h when I'm up again the world is less red
<zyga> yeah
<zyga> I'll merge and restart anything I can
<zyga> mvo: can I merge stuff into the release branch with one review?
<zyga> mvo: it could be all merged for you in the morning
<mvo> zyga: I think that's fine, strict backports just need one review
<zyga> ok
<zyga> technically https://github.com/snapcore/snapd/pull/7801 is not reviewed
<zyga> that's the fix to unbreak others :)
<mup> PR #7801: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
<mvo> zyga: refresh please
<zyga> \o/
<zyga> thanks!
<zyga> I had a nap so I can work for the next 45 minutes
<zyga> if that helps tomorrow that's useful
<zyga> tomorrow I'm back to feature work
<zyga> I have some follow ups for the update-ns that pedronis suggested
<zyga> but we have enough open PRs now
<mvo> zyga: thank you ! much appreciated. just make sure you don't overdo it, if you feel sleepy/want-to-do-something-else just do it :)
<zyga> yeah
<zyga> I totally will :)
 * mvo hugs zyga and vanishes 
<zyga> o/
<sdhd-sascha> Chipaca: i have trouble with upload to the store. But yesterday i could start sway in classic mode. It's on github
 * cachio afk
<zyga> oh for crying out loud ....
<zyga> timeout
<ijohnson> hey zyga, looks like I missed some stuff that happened while out to lunch, what can I help review to unbreak master/critical things?
<zyga> ijohnson: it's all fixed now, jdstrand sent a followup PR
<zyga> we're just waiting for things to be less red
<ijohnson> zyga: ack ok
<zyga> another one failed
<zyga> I'll call it a day
<ijohnson> good night zyga, see you tomorrow
<mup> PR snapd#7802 closed: interfaces: update system-backup tests to not check for sanitize errors related to os <Simple ð> <â  Critical> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7802>
<jdstrand> ijohnson: ^
<ijohnson> Right, nice
<cmatsuoka> devicestate tests are very intersting, but it's time to call it a day
#snappy 2019-11-27
<mup> PR snapcraft#2825 opened: remote-build: remove need to specify user <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2825>
<mup> PR snapd#7798 closed: interfaces/browser-support: allow reading status of huge pages <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7798>
<mup> PR snapd#7801 closed: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7801>
<mup> PR snapd#7779 closed: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7779>
<mup> PR snapd#7804 opened: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al (2.42) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7804>
<zyga> good morning mvo
<zyga> mborzecki: hey
<mborzecki> morning
<mborzecki> zyga: hey
<zyga> mborzecki: yesterday stuff was red all the time
<zyga> I went to bed after 3rd round of restart-and-pray
<zyga> I saw mvo merge and restart things that managed to land last night after I went to bed
<mborzecki> there was a unit test failing on moster, but looks like it's fixed now
<zyga> yeah
<zyga> jamie fixed it
<mborzecki> ok, cool
<zyga> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.2-Go-Register-Corrupt
<zyga> re
<mborzecki> zyga: that's encouraging
<Eighth_Doctor> for some godforsaken reason, I haven't fallen asleep yet
<Eighth_Doctor> but anyway, looks like snapd 2.42.2 and snapd-glib 1.54 landed in all Fedora releases and EPEL 7 and EPEL 8
<pedronis> mvo: hi, I commented a bit on the next two UC20 PRs
<pstolowski> good morning
<mvo> pedronis: thanks!
<mborzecki> mvo: thanks for updating #7795
<mup> PR #7795: overlord/snapstate: pick up system defaults when seeding the snapd snap (2.42) <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7795>
<mborzecki> pstolowski: hey
<mborzecki> Eighth_Doctor: yay!
<mvo> mborzecki: no worries, let's hope it's fine this time
<mborzecki> haha, #7799 is a nice playground for bikeshedding about performance with artificial microbenchmarks
<mup> PR #7799: osutil/mount: de-duplicate code to use a list <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
<pedronis> pstolowski: hi, your prebake trello card seems to be still about the spike, vs landing the pieces
<pedronis> I mean in Doing
<pstolowski> pedronis: hey, right, will update, thanks
<pedronis> thx
<mup> PR snapd#7805 opened: osutil/mount: optimize flagOptSearch some more <Created by zyga> <https://github.com/snapcore/snapd/pull/7805>
<zyga> pstolowski: hey
<pedronis> zyga: ^ is that related to Ian's perf findings ?
<zyga> pstolowski: simple one for the morning? https://github.com/snapcore/snapd/pull/7803
<mup> PR #7803: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
<zyga> pedronis: yes
<zyga> pedronis: it's a bit of a wake up thing
<zyga> the original is still faster if we optimize allocation with popcount l
<pstolowski> zyga: sure.. interesting, i though i removed it at some point when validation was delegated to policy check
<zyga> thanks!
<mup> PR snapd#7803 closed: interfaces: remove reservedForOS from commonInterface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7803>
<zyga> mvo: 2.42.3 is okay except for waiting for CI right?
<zyga> mvo: I can jump into my regular feature work now
<mvo> zyga: correct
<mvo> zyga: once stuff is green I will release
<pstolowski> Chipaca: hey, per yesterday's suggestion from pedronis, i'm happy to take https://github.com/snapcore/snapd/pull/7320 from you if that's ok
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<Chipaca> pstolowski: sure
<Chipaca> pstolowski: was there more to do there?
<pstolowski> Chipaca: there are a couple of comments, e.g. special casing for 'snap run'
<pstolowski> Chipaca: i'll probably get to it in a day or two
<Chipaca> right
<ogra> jdstrand, do you actually want to boot without SD ? (sorry, i'm at a trade show so only saw your ping now) ... if you can live with SD, just copy the writable partition over to the USB drive, re-label the SD one to "writable-old" and make sure the USB one is labeled "writable" ...
<zyga> pstolowski: that pip feature is super useful
<zyga> pstolowski: thank you again
<zyga> pstolowski: it works on top of vmware
<mborzecki> zyga: pip?
<pstolowski> zyga: yep it's super nice
<mborzecki> as in picture-in-picture?
<zyga> mborzecki: picture in picture
<zyga> https://usercontent.irccloud-cdn.com/file/BH5R96NZ/pip-over-vmware.png
<mborzecki> zyga: a macos thing?
<zyga> mborzecki: safari feature
<zyga> yeah
<pstolowski> zyga: would be cool if it worked with meet/ho
<zyga> does it?
<pstolowski> nope
<mup> PR snapd#7804 closed: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al (2.42) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7804>
<pedronis> mborzecki: what's the plan with 7796, on its own is supposed to fail no?
<pedronis> (it's failing on other random stuff atm)
<mborzecki> pedronis: failed as planned https://paste.ubuntu.com/p/4rjfhJzjBT/
<pedronis> mborzecki: do you plan to change to contain the fix? land it with manual and do another PR?
<mborzecki> pedronis: i'll be pushing the fix in snapstate into that branch
<pedronis> ah ok
<pedronis> it will need a summary change
<pedronis> (stating the obvious in case :) )
<mborzecki> mhm
<mborzecki> zyga: do you remember the bit we had in the spec that worked around fedora's patching of /bin/sh to /usr/bin/sh ?
<zyga>  yes
<zyga> what about it?
<mborzecki> zyga: must be blind, i'm looking at our spec and a downstream one and don't see it
<zyga> one sec :)
<zyga> mborzecki: we only have it in our test code
<zyga> https://github.com/snapcore/snapd/pull/7614/files#diff-556bb7431481e375713ea3e0883a771aL111
<zyga> I remove it here
<zyga> it's not downstream
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<mborzecki> zyga: right, i was asking in the context of https://bugs.launchpad.net/snapd/+bug/1824158
<mup> Bug #1824158: compatibility bug with fedora <snapd:Confirmed for maciek-borzecki> <https://launchpad.net/bugs/1824158>
<zyga> mborzecki: it's the impossible task of using one program from both contexts
<zyga> mborzecki: not sure what you are asking about specifically
<zyga> mborzecki: the bug is still present
<zyga> it's fixed by the PR I referenced
<mborzecki> zyga: downstream had _brp_mangle_shebangs_exclude ^/bin/(bash|sh)$, but that got dropped when updating to 2.41, don't recall why
<zyga> I don't recall why either
<zyga> perhaps accident?
<mborzecki> Eighth_Doctor: do you recall whether that mangling workaround was no longer needed?
<mup> PR snapd#7806 opened: tests/lib/prepare: drop workarounds for rpmbuild rewriting /bin/sh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7806>
<pstolowski> dot-tobias: ping
<zyga> mborzecki: why do you want to drop https://github.com/snapcore/snapd/pull/7806
<mup> PR #7806: tests/lib/prepare: drop workarounds for rpmbuild rewriting /bin/sh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7806>
<zyga> it's not going to pass today, is it?
<mborzecki> zyga: ohmygiraffe works on f31 without the rewrite, quite sure it picked up the drm dervices since there's opengl interface involved
<zyga> mborzecki: because f31 has v2?
<zyga> I mean, it's premature
<mborzecki> zyga: it's f30
<mborzecki> the system i tried it on
<zyga> on f31 you don't have device cgroup
<zyga> on f29 it will regress
<zyga> unless I'm missing something
<zyga> we should not drop that yet
<jamesh> zyga: a while back, you said you were working on a better way to detect snap confined apps than reading the cgroup proc file.  Has any progress happened with that?
<zyga> jamesh: yes, there's been a lot of progress on this topic
<zyga> jamesh: but the means have changed
<zyga> jamesh: because of all kinds of unexpected complexity
<zyga> jamesh: I'm working on this today actually
<pedronis> Chipaca: hi, maybe you could get to do a first review of #7771 when you have a moment ?
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<Chipaca> a'yup
<zyga> jamesh: the status quo is that we'll use a systemd _scope_ for all non-service processes
<zyga> jamesh: and typical service cgroup for services
<jamesh> zyga: awesome.  Is it still a file we can read from the process's mount namespace, or something else?
<zyga> jamesh: I'll share the details if you want
<zyga> jamesh: but if you wait a day you I will have the new PR up
<zyga> jamesh: a means to check if a process belongs to a snap involves reading /proc/[pid]/cgroup
<zyga> jamesh: one _can_ spoof this
<zyga> jamesh: but it's true for all snaps
<zyga> jamesh: does this make sense so far?
<jamesh> zyga: I can wait for the PR.  I'm mostly interested in terms of improving xdg-desktop-portal's snap support
<mborzecki> zyga: hm looks like you fixed it a while ago https://github.com/snapcore/snapd/commit/641adbf815db392248134a6cfe9650e1abf89575
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/7049 yeah, that'd explain why it works now
<zyga> mborzecki: interesting :)
<mup> PR #7049: cmd/snap-confine: handle device cgroup before pivot <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7049>
<zyga> mborzecki: but even if we run it, will it run correctly?
<jamesh> zyga: so I mostly want something that (a) doesn't depend on AppArmor like the current code does, (b) is unlikely to change over snapd versions
<zyga> it won't run in one of the two spaces
<zyga> jamesh: a) is true b) is something we can try to promise to keep
<mborzecki> zyga: yes, it's run either by s-c inside the host ns, or udev also in host ns
<zyga> jamesh: a) also works across cgroup v1 and v2
<jamesh> zyga: false positives are not too bad, since we'd be shelling out to "snap routine portal-info" to get the actual information
<zyga> jamesh: that's great
<jamesh> which could do something snapd version specific
<zyga> brb
<pedronis> mvo: 7797 will need updating because of 7792
<mvo> pedronis: yeah, I will do as soon as one of them lands
<mup> PR snapd#7807 opened: snap-bootstrap: remove SNAPPY_TESTING check, we use it for real now <Simple ð> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7807>
<mup> PR snapd#7794 closed: many: backport pull request #7773 from zyga/fix/lp-1852361 <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7794>
<mup> PR snapd#7795 closed: overlord/snapstate: pick up system defaults when seeding the snapd snap (2.42) <â  Critical> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7795>
<zyga> mvo: woot, thank you
<mborzecki> yay
<mborzecki> so .3?
<mup> PR snapcraft#2826 opened: Copy npm and npx binaries in snap <Created by guilhem> <https://github.com/snapcore/snapcraft/pull/2826>
<Chipaca> pstolowski: almost +1 on 7771
<mvo> zyga, mborzecki *thank you* !
<pstolowski> Chipaca: ty
<zyga> mvo: as soon as .3 is out I'll do a suse version
<mvo> zyga: working on it now, had a meeting before
<zyga> cool, no rush :)
<pedronis> mvo: mborzecki: what about 7796 ?
<mborzecki> pedronis: i did the change we discussed, waiting for spread test, but still have some wonderings about the fix
<mborzecki> need to run a quick errand, back in 30 or so
<mup> PR snapd#7808 opened: release: 2.42.3 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7808>
<mvo> pedronis: you mean what about 7796 for 2.42.3?
<pedronis> mvo: yes
<cachio> pstolowski, hey
<pstolowski> cachio: hi
<cachio> I am researching the test bad-interfaces-warm
<cachio> and I see an error when we execute on arm devices
<cachio> pstolowski, this is the otuput of the snap install https://paste.ubuntu.com/p/XpY4spwC5Q/
<mvo> pedronis: I thought we said it's not criticial for this release, has that changed? we also don't have a fix yet, correct? i.e. so far this is the regression test
<pedronis> mvo: it is kind of critical given we don't know how they use the device
<pedronis> mvo: it's the third aspect that is not critical
<cachio> pstolowski, I see that on edge and beta
<cachio> pstolowski, is it a bug?
<cachio> right?
<pstolowski> cachio: no. unless the test failed?
<pstolowski> cachio: this is a new test about bad plug/slots
<pstolowski> cachio: snap install will warn if there are bad plugs/slots
<cachio> pstolowski, the test fails
<pstolowski> cachio: can you show me the full output?
<cachio> pstolowski sure
<cachio> https://paste.ubuntu.com/p/zGzjtTdRjs/
<mvo> pedronis: ok, that sounds like we need a .4 :/ let me tag it with 2.42. and critical
<pedronis> mvo: sorry, I thought it was clear we wanted a fix for this in too
<cachio> mvo, hey, should I invest time testing .3?
<cachio> if we are going to have a .4?
<mvo> pedronis: I misunderstood, sorry
<mvo> cachio: yes, .4 there will be
<cachio> ok
<pstolowski> cachio: is this test run against latest snapd? looks like the new functionality is not there
<cachio> on edge if failing with the same error
<pstolowski> hmm or maybe there is a race and warning is not immediately available
<pstolowski> cachio: do you have shell with this failrue?
<cachio> pstolowski, yes
<cachio> I am refreshing to edge now
<pstolowski> cachio: can you execute 'snap warnings' ?
<cachio> No warnings.
<cachio> with beta
<cachio> letme refresh to edge
<cachio> pstolowski, same output with core on adge
<cachio> pstolowski, using this core 16-2.42.2+git1570.35c66d9
<cachio> also: No warnings.
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7806#pullrequestreview-323645799
<mup> PR #7806: tests/lib/prepare: drop workarounds for rpmbuild rewriting /bin/sh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7806>
<mup> PR snapd#7799 closed: osutil/mount: de-duplicate code to use a list <Simple ð> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7799>
<ijohnson> zyga, mborzecki: so I stayed up all night and hand wrote GPU assembly and was able to get that mount opts parsing code down to 4 planck time units!
<zyga> ijohnson: hehe
<zyga> hey :)
<ijohnson> Morning :-)
<zyga> ijohnson: I think the original would be still fastest with the only extra change to get the array size done up front
<pstolowski> hey ijohnson
<pstolowski> does anyone know how to map our short git1570.35c66d9 version number to git log?
<mborzecki> re
<mborzecki> ijohnson: hahah ;) must have been a great deal of fun
<zyga> ijohnson: did you see 7805?
<pstolowski> cachio: i suspect core doesn't have my change yet for some reason as was a case already in the past. i need to decode that git version string to check
<ijohnson> zyga: I saw the email notifications y'all had more optimizations, but haven't really looked yet
<pstolowski> cachio: this is backed up by the fact that even snap warnings doesn't show anything
<ijohnson> pstolowski: is that from the edge channel? IIRC that git commit is from some other repo that builds the core snap on edge
<cachio> pstolowski, I can check on amd64
<cachio> pstolowski, I found the problem
<cachio> snapd-vendor-sync is not running
<pstolowski> whew
<zyga> whee
<cachio> pstolowski, I'll check the vm to see why
<zyga> thinkpad cover arrived
<cachio> pstolowski, thanks
<pstolowski> cachio: yw
<pstolowski> ijohnson, cachio is vendor sync / other repo making this version number completely different from our git revisions~?
<cachio> pstolowski, yes
<pstolowski> huh
<cachio> snapd-verdor-sync does not use github
<pstolowski> that's annoying
 * ijohnson goes back to breakfast
<mup> PR snapd#7797 closed: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7797>
 * Chipaca takes a break, and reboots while at it
<zyga> good progress on cgroup bits, one last annoying spread test and I'll open a PR for initial review
<zyga> thnkpad is fixed :)
<zyga> uhhh
<zyga> it's not
<mborzecki> zyga: thinkpad is never broken, it's only an transient non-working state
<zyga> the part was broken
<zyga> heh
<zyga> that's ok
<zyga> it's silly
<mborzecki> unless it's cooling, it's broken by design
<zyga> part of the bottom cover is broken
<zyga> but that's ... enough
<zyga> I guess
<zyga> spending more money on this is probably not worth it
<mup> PR snapd#7800 closed: tests: add Ubuntu Eoan to google-sru backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7800>
<zyga> ijohnson: did I understand you correctly that snap-confine without root was the topic you mentioned?
<zyga> like without root at all
<ijohnson> zyga: https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258/10?u=ijohnson
<ijohnson> no, "/" is not root-owned is the issue
<zyga> ah
<zyga> what's fun
<zyga> and weird
<zyga> we can relax that check I guess
<zyga> is there a corresponding bug report?
<ijohnson> no I don't think so
<zyga> ok
<zyga> I'd like to understand why / is 501 though, it's a bit silly and odd
<zyga> I'll read the thread after the standup
<Chipaca> dot-tobias: ping
<ijohnson> pstolowski: let me know if you want me to look at your service branch, wasn't sure if that's one of your current open PR's or a local branch
<pstolowski> ijohnson: thanks, it's not proposed yet; i'll dig a bit more myself. will definately ask you for a review when ready. nb, have you discussed any particular approach for fixing snapctl side?
<ijohnson> pstolowski: there's this forum post: https://forum.snapcraft.io/t/systemctl-service-management-unification/13808 I need to post an update from the discussion I had with folks after that on the plan so yes we have discussed the approach, I forgot to put it on the forum :-)
<pstolowski> ijohnson: great, ty!
<mborzecki> pedronis: i've updated #7796
<mup> PR #7796: overlord/snapstate: make sure configuration defaults are applied only once <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7796>
<mborzecki> heh, typo
<mup> PR snapd#7776 closed: interfaces: add login-session-observe for who, {fail,last}log and loginctl <Needs Samuele review> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7776>
<mborzecki> off to pick up the kids
<pedronis> mvo: mborzecki: small comment on ^
<pedronis> heh, I mean #7796
<mup> PR #7796: overlord/snapstate: make sure configuration defaults are applied only once <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7796>
<pstolowski> Chipaca: I think I addressed all your comments to #7771
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<Chipaca> pstolowski: thank you
<mup> PR snapd#7793 closed: devicestate: read modeenv early and store in devicestate <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7793>
<ijohnson> pstolowski: I updated https://forum.snapcraft.io/t/systemctl-service-management-unification/13808/7?u=ijohnson with what we discussed in that meeting
<pstolowski> ijohnson: thanks for that and for the exhaustive description of the problem. looks like it may be a separate PR that's a prerequisite for my current set of changes
<ijohnson> pstolowski: ok, does this mean you are now blocked on me working on that? I think I'm at a point now where I can switch to doing that instead of the performance stuff, just need to get folks to agree on what we should do now I think
<mup> PR snapd#7809 opened: interfaces: remove leftover reservedForOS <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7809>
<pstolowski> ijohnson: ah, you inteded to do that? i thought it was passed to me after your initial changes to services. yes, this is kinda blocking, i'm not sure there is a way around that
<ijohnson> pstolowski: yes that was the plan that I was going to work on that after I wrapped up the performance stuff. but if you're totally blocked on it, considering I will be out on thurs + friday, perhaps it makes more sense for you to get started on that
<pstolowski> ijohnson: right, it may be best if i take it (as long as it doesn't make your plate empty ;))
<ijohnson> I'm sure mvo can find something else for me to work on :-)
<mvo> ijohnson: haha, I'm not worried about this
<pstolowski> :)
<pstolowski> ijohnson, mvo: ok, i'll take it then
<ijohnson> zyga: I think https://github.com/snapcore/snapd/pull/7805 is ready to merge now :-)
<mup> PR #7805: osutil/mount: optimize flagOptSearch some more <Performance ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7805>
<zyga> looking
<zyga> ijohnson: I may do more ;)
<zyga> ijohnson: but it was fun, thank you
<mup> PR snapd#7805 closed: osutil/mount: optimize flagOptSearch some more <Performance ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7805>
 * cachio lunch
<ijohnson> you're welcome :-) always happy to help in this way
<mup> PR snapd#7810 opened: devicestate: add reading of modeenv to uc20 firstboot code <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7810>
<zyga> Chipaca: are you a forum admin?
<zyga> Chipaca: could you please fork https://forum.snapcraft.io/t/snap-layouts/7207/36 to a new thread
<Chipaca> zyga: a moderator, not an admin, but i can fork
<Chipaca> zyga: thread title?
<Chipaca> and category plz
<zyga> python3 application with external module
<zyga> snap
<zyga> I think that matches it
<zyga> careful, the reporter is writing more in the original thread
<zyga> so you may need to wait a sec
<zyga> ah
<zyga> I see you just did
<zyga> cool, thanks!
<Chipaca> zyga: i can move the reply too
<zyga> thanks
<zyga> he is still typing
<Chipaca> zyga: was that the right place to cut it?
<zyga> yeah
<Chipaca> ok
<zyga> that's great
<mborzecki> re
 * zyga dinner
<mborzecki> pedronis: thanks for the comments, updated 7796 with little tweaks to make that if more readable
<mvo> cmatsuoka: do you think you could give 7792 a look?
<mvo> mborzecki: thanks so much for this fix!
<cmatsuoka> mvo: checkint it
<cmatsuoka> checking it
<mvo> ta
<pedronis> mborzecki: +1, thanks
<mborzecki> mvo: pedronis: thanks!
<pedronis> is master broken?
<pedronis> it seems there were again out-of-sync landings
<pedronis> yes :/
<mborzecki> pedronis: https://github.com/snapcore/snapd/pull/7809 should fix master
<mup> PR #7809: interfaces: remove leftover reservedForOS <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7809>
<pedronis> ah
<pedronis> yes
<mvo> pedronis: 7792 landed so you can do the followup with the wording tweaks
<pedronis> mvo: thx
<mup> PR snapd#7792 closed: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7792>
<pedronis> mvo: I finished the code for plug-names/slot-names, waiting for fixed master (because I rebased on it) before pushing though
<zyga> mvo: sorry about the trouble
 * zyga overcame an issue with lxd just now :)
<zyga> whee
<zyga> and learned a lot :)
<mvo> pedronis: cool, yeah, I have another (small) PR waiting for this too
<pedronis> mvo: actually I might have spotted a bug
<pedronis> mvo: seedDir needs to be seed not seed/systems
<mvo> pedronis: oh, right! nice catch, thank you!
<pedronis> mvo: I can fix in this PR if you want, or at least try
<zyga> lol
<zyga> I was wondering what kept spawning qemu
<zyga> I was running "spread ... ubuntu-18.04-64:tests/main"
<zyga> notice the lack of google:
<pedronis> mvo: mmh, no the code is right just a bit confusing
<zyga> ondra: hey
<zyga> around?
<pedronis> mvo: these are the changes I have in mind:  https://github.com/pedronis/snappy/commit/7fe73e0848db2db203e1d42439d024a8f8bad1d8
<mvo> pedronis: looks good!
<ijohnson> jdstrand: hey do you have some time today to chat about bpf (i.e. seccomp) and non-root owned "/" ? it's an issue for folks using github actions / azure pipelines because for some reason "/" is not root-owned
<zyga> ijohnson, jdstrand: if you do please include me
<vidal72[m]> is snapd 2.42.3 available in snap?
<zyga> vidal72[m]: .4 will be available in a few days
<zyga> vidal72[m]: mvo is doing the release today
<mvo> vidal72[m]: .3 is available in candidate, .4 is scheduled for today but testing is a bit tricky today (some unrelated issues)
<zyga> I'll call it a day soon
<zyga> but it's a good day because I've confirmed everything is working as expected
 * zyga fired last run of spread across all OSes to see if it has any extra issues
 * zyga EODs
<zyga> ttyl!
<mup> PR snapd#7809 closed: interfaces: remove leftover reservedForOS <Simple ð> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7809>
<mup> PR snapd#7811 opened: cmd/snap-bootstrap: some small naming and code org tweaks <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7811>
<pedronis> mvo: I merged master fix and proposed ^
<mup> PR snapd#7812 opened: asserts: parse plug-names/slot-names constraints  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7812>
<mup> PR snapd#7813 opened: interfaces/policy: enforce plug-names/slot-names constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/7813>
<mvo> pedronis: thank you!
<mup> PR snapd#7814 opened:  overlord/snapstate: make sure configuration defaults are applied only once (2.42) <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7814>
<mup> PR snapd#7807 closed: snap-bootstrap: remove SNAPPY_TESTING check, we use it for real now <Simple ð> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7807>
<mup> PR snapd#7808 closed: release: 2.42.3 <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7808>
<mup> PR snapd#7815 opened: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>
#snappy 2019-11-28
<mup> PR snapd#7796 closed: overlord/snapstate: make sure configuration defaults are applied only once <â  Critical> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7796>
<mup> PR snapd#7811 closed: cmd/snap-bootstrap: some small naming and code org tweaks <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7811>
<mup> PR snapd#7814 closed:  overlord/snapstate: make sure configuration defaults are applied only once (2.42) <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7814>
<mup> PR snapd#7816 opened: release: 2.42.4 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7816>
<pedronis> mvo: hi, I made some (further) comments in #7810, hope they make sense
<mup> PR #7810: devicestate: add reading of modeenv to uc20 firstboot code <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7810>
<mvo> pedronis: good morning
<mvo> pedronis: looking, thanks a lot for the feedback
<pedronis> mvo: that final note probably means we should tweak the boot pkg interface for modeenv to avoid errors, but can be done a bit later
<mvo> pedronis: ok, the comment makes sense, I will work on this in a wee bit (after some baby-sitting for 2.42.4, the review tools are acting up or something else is blocking reviews)
<pstolowski> morning
<marcustomlinson> morning :)
<mvo> pedronis: thanks and I updated 7810 - hope I captured what you suggested there
<mvo> pstolowski, marcustomlinson good morning!
<pedronis> mvo: reviewed
<mvo> pedronis: thank you!
<mup> PR snapd#7817 opened: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7817>
<zyga> Good morning
<zyga> Working till 1am
<zyga> Will start in an hour
<zyga> mvo: is the release successful?
<mvo> zyga: so far it looks good, we need sergio to do the validations now but stuff is in beta
<zyga> Ack
<pedronis> mvo: did a pass on 7817
<mvo> pedronis: thank you!
<mup> PR snapd#7818 opened: cmd-boostrap: write /var/lib/snapd/modeenv to the right place <Simple ð> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7818>
<pedronis> mvo: let me know if you have questions
<mup> PR snapd#7750 closed: sanity: check /dev/loop-control device as part of sanity checks <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7750>
<mvo> pedronis: looks good, will work on this next
<mup> PR snapd#7819 opened: boot: add boot.Modeenv.Base support <Simple ð> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7819>
<mvo> pedronis: thank you so much for the review of the uc20 booting spec!
<mborzecki> morning
<pstolowski> hey mborzecki
<mvo> hey mborzecki
<pstolowski> pedronis: reviewing your plug/slot name cstrs
<pedronis> pstolowski: thx,  I asked a question in the is-connected one
<pstolowski> ty
<mborzecki> heh, switching to OneTab is kind of difficult, i don't feel this workflow yet
<pstolowski> mborzecki: it's a pitty firefox dropped the tab groups feature, it was cool
<mborzecki> pstolowski: not the only useful thing they dropped (or are dropping)
<mborzecki> iirc scratchpad is next to go
<mborzecki> as mus as i dislike js scratchpad was kind of useful to testing stuff out
<zyga> hey mborzecki
 * zyga is back now
<zyga> but feeling so so still
<pstolowski> pedronis: updated #7771
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<pedronis> pstolowski: mmh, did you try it?
<pstolowski> pedronis: i've run the spread test
<pstolowski> pedronis: why?
<pedronis> I'm confused by our code then
<ondra> zyga hey
<zyga> hey
<zyga> I just wanted to ensure you know that to use the fix you need to enable the experimental option
<ondra> zyga sorry I was out yesterday, still something I can help today?
<zyga> and that the gadget will enable it
<zyga> no worries :)
<ondra> zyga for refresh bug?
<zyga> yes
<ondra> zyga what is config option, so I can make sure it's in our gadget
<zyga> ondra: it's exactly the same one as was given in all the bug reports
<ondra> zyga cool, let me check
<zyga> snap set core experimental.robust-mount-namespace-updates=true
<pstolowski> pedronis: my bad, the error is actually "error: error running snapctl: plug is not connected" (i misread the output)
<pstolowski> pedronis: that's a byproduct of our error propagation
<pstolowski> pedronis: was that the confusing bit?
<pedronis> pstolowski: yes
<pedronis> pstolowski: I think we need to decide what to do, that's kind of a not great error for this
<pedronis> also the double error... : is bad in general
<mup> PR snapd#7816 closed: release: 2.42.4 <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7816>
<pstolowski> pedronis: true. slightly annoying is the fact that the only way for reporting non-zero status from this corner of the code is via non-empty error message
<pedronis> pstolowski: I don't think that's true
<pedronis> pstolowski: anyway, let me think a bit
<zyga> ok, only one more thing to write
<pstolowski> pedronis: ok, looking at api - runSnapctl we could special case this like we do for ForbiddenCommandError; on the client we always append "error: ", that way we would have "error: plug is not connected"
<mup> PR snapd#7820 opened: [RFC] boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7820>
<pedronis> mvo: ^ we need to discuss this, is unexpected
<mvo> pedronis: yeah, happy to - this is why its RFC :) I'm pondering how to link from the static kernel.img back to the right kernel snap that needs to get mounted in initramfs
<mup> PR snapd#7706 closed: overlord/snapstate: install task edges <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7706>
<mvo> pedronis: that's the reaosn for this PR but I'm probably missing something
<mvo> pedronis: happy to chat (here or HO) in a bit, just need a short break
<pedronis> mvo: I need to have lunch
<zyga> tracking is now tested to work across all systems except 14.04
<zyga> need to rewrite snap-run patch not to shell out to busctl
<zyga> then it will work faster and on all of them
<zyga> whee
<mborzecki> zyga: does it work on centos/amazon too?
<zyga> yes
<mborzecki> cool
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:feature/sub-cg-wip-v2?expand=1
<zyga> mborzecki: early review welcome
<zyga> mborzecki: I need to move some things to sandbox/
<zyga> mborzecki: and add more tests as indicated by TODOs
<pedronis> pstolowski: I made some initial suggestions
<pstolowski> pedronis: ty
<mborzecki> pstolowski: rebased by old branch about parallel seccomp profile compiles since we now know that it takes much longer to execute https://paste.ubuntu.com/p/NwxKtFtSJQ/
<pstolowski> mborzecki: great, thanks
<Chipaca> i so want to throw away all stringy channels and replace them with a type
<zyga> Chipaca: \o/
<zyga> yay for types
<pedronis> Chipaca: we have a type, no, snap/channel.Channel ?
<Chipaca> pedronis: yes, but most of the time we pass around strings
<pedronis> well, because the type came later
<pedronis> also we have risk only vs full
<pedronis> also some channels come from assertions these days
<Chipaca> pedronis: risk vs full, imho, is an argument for structured, not against
<pedronis> Chipaca: we started in a world where channels were opaque to us, we cannot live there anymore sadly
<pedronis> Chipaca: do you have a sense of how big a change it would be ?
<pedronis> (I fear too big for right now, but maybe I'm wrong)
<Chipaca> rather big, especially in tests
<zyga> re
<zyga> coffee is badly needed
<mup> PR snapd#7818 closed: cmd/snap-bootstrap: write /var/lib/snapd/modeenv to the right place <Simple ð> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7818>
<mup> PR snapd#7819 closed: boot: add boot.Modeenv.Base support <Simple ð> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7819>
<zyga> eh
<zyga> d-feet hangs when you pick systemd1 on session bus
<zyga> ah, actually it's just *very* slow
<zyga> but it works
<mup> PR snapd#7821 opened: interfces/seccomp: parallelize secomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<pedronis> mborzecki: ^  I asked a question there
<mborzecki> pedronis: cpu bound, but the compilation is single threaded
<pedronis> mborzecki: do we want really to spawn that many processes on low end devices?
<mborzecki> pedronis: we could as go about NumCPU(), but not i wanted to get a feeling whether anything breaks right away
<pedronis> mborzecki: yes, I think we should use NumCPU() somehow
<pedronis> mborzecki: it wasn't clear it's a draft
<mborzecki> pedronis: ah, let me add [RFC] in the title
<sdhd-sascha> is there a working weston snap ?
<pedronis> Chipaca: can you explain the stack of failing spread tests?  pstolowski had that landed at some point and we reverted it, so I think the spread tests were passing
<pedronis> Chipaca: I mean this: https://github.com/snapcore/snapd/pull/7373
<mup> PR #7373: overlord/snapstate: revert track-risk behavior change and validation on install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7373>
<Chipaca> pedronis: yes
<Chipaca> pedronis: i assume it's because of the other changes in this area
<pedronis> but master is green
<Chipaca> ...?
<pedronis> I mean I don't understand why the semantics change would now cause a cascade of spread failure
<pedronis> when it didn't originally
<Chipaca> ah
<Chipaca> well, because we were over-normalising channels
<Chipaca> and testing for that
<Chipaca> so stable would become latest/stable before snapstate got to see it
<pedronis> ?
<mup> PR snapd#7806 closed: tests/lib/prepare: drop workarounds for rpmbuild rewriting /bin/sh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7806>
<pedronis> the changes were all in snapstate in pawel PR
<pedronis> I'm still missing something
<Chipaca> pedronis: was pawel's change sufficient to effect the behaviour change we wanted
<Chipaca> pedronis: because testing locally, with master today, it would not have been
<Chipaca> in particular cnd/snap's setChannelFromCommandline sets channel to the parsed short name
<Chipaca> so there an explicit latest/ would be lost
<Chipaca> and then daemon's snapRevisionOptions's validate would set channel to the parsed channel's name
<Chipaca> so, again
<pedronis> Chipaca: this is pawel main PR: https://github.com/snapcore/snapd/pull/7199
<mup> PR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7199>
<pedronis> notice that I didn't review it
<mborzecki> pstolowski: btw. didn't snap debug timings show the sum of doing-time at some point?
<mborzecki> pstolowski: had to resort to some jq trickery :/
<pstolowski> mborzecki: heh. no
<Chipaca> pedronis: I did, and the change is necessary but not sufficient with today's master
<Chipaca> pedronis: but, note both those things that over-normalize might be newer than pawel's pr
<pedronis> Chipaca: yea, I woudl try to fix cmd/snap to stop changing latest/foo
<pedronis> we don't want that anyway
<pedronis> for default tracks
<pedronis> Chipaca: it should try to pass as much as possible what the user gave
<Chipaca> I know
<pedronis> Chipaca: seems like a good separate PR
<Chipaca> hmm
<Chipaca> pedronis: i could make a separate pr from both un-over-normalisation changes
<Chipaca> i'll do that
<pedronis> but I missed something when I reviewed, I though we would use full only if errors
<pedronis> ah
<pedronis> I see
<pedronis> the joy of ParseChannel vs Verbatim
<pedronis> grumble
<pstolowski> pedronis: standup?
<pedronis> maybe
<Chipaca> nice, half my system froze
<zyga-laptop> hmm
<zyga-laptop> ok, I pushed an update to the draft
<zyga-laptop> mborzecki do you have a moment to just go over it with me
<zyga-laptop> mborzecki I'm looking for advice on what to move or change ahead of proper PR
<zyga-laptop> just a quick look
 * cachio lunch
<mborzecki> zyga-laptop: sure
<mborzecki> zyga-laptop: meet?
<zyga> yep
<zyga> https://meet.google.com/eyi-xjto-svg?authuser=1
 * zyga EODs
<Chipaca> pedronis: FWIW the under-over PR does not break the spread tests
<Chipaca> pedronis: https://github.com/snapcore/snapd/compare/master...chipaca:under-over-normalise
<pedronis> good, you mentioned also SetChannelFromCommandline ?
<pedronis> is that a different thing
<Chipaca> pedronis: that's the first chunk in that diff
<pedronis> ah, sorry
<pedronis> Chipaca: is that a good thing or a bad thing that the spread tests don't break?
<Chipaca> pedronis: i'm going with 'bad'
<pedronis> ok, same as me then
<Chipaca> :)
<pedronis> still not sure why the other change would break lots of spread test
<pedronis> s
<pedronis> sound some subtle thing gone awry
<pedronis> mvo: anything I need to re-review still today? I was considering eoding soon
<mvo> pedronis: should be fine, thank you
<mup> PR snapd#7822 opened: devicestate: ensure system installation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7822>
<mup> PR snapd#7823 opened: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7823>
<kjackal> did we change anything recently in snapcraft? Builds are failing on travis with: An error occurred when trying to execute 'snap set system experimental.snapd-snap=true' with 'LXD': returned exit code 1.
<kjackal> I build there with --use-lxd
<mvo> cmatsuoka: reviewed your PR, super close! thanks for this
<cmatsuoka> mvo: thanks for the review, fixing it now
<mvo> cmatsuoka: I also marked the stuff that is done green in the gdoc
<mvo> cmatsuoka: there is a lot of not-green stuff :/ oh well :)
<sdhd-sascha> hi, does anybody know, where in the golang code inside of snapd (snap+d - deamon) the mount for the /etc/fonts directory happens ?
<sdhd-sascha> i want to disable these mount. And have already removed all plugs.
<sdhd-sascha> ogra: is this the right place for this question? because it needs go-lang programming knowledge. and knowlege of internals of snapd
<mup> PR snapcraft#2827 opened: build providers: only set the snapd flag when installing snapd <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2827>
<sdhd-sascha> Or, how can the snap mounts be shown ? losetup and /run/mount/utab doesn't show /etc/fonts
<sdhd-sascha> Ok, inside the snap, the mounts are visible. (snap run --shell <snap> ; mount )    I look for a way, from outside...
 * cachio afk
<sdhd-sascha> hmm, seems that starting a snap, forks into a new namespace, and the mounts are under /proc/<snap pid>/mounts
<zyga> sdhd-sascha: hey
<zyga> sdhd-sascha: I know some things about how snap runtime works
<zyga> sdhd-sascha: please feel free to ask me any questions you may have
<sdhd-sascha> :-)
<sdhd-sascha> zyga: for me it's sometimes very awkward to ask some noob question, and then the next day or the next 10 minutes i found the answer :-o
<sdhd-sascha> thank you ;-)
<zyga> sdhd-sascha: I'm such a noob at many things
<zyga> sdhd-sascha: please don't worry, ask away :)
<zyga> sdhd-sascha: snapd uses mount namespaces
<sdhd-sascha> i just found git:/snapd/snap/cmd/cmd_run.go ... now i want to find the place where the namespace (or others) are created, to have a look at the linux-api. So i can then read about the api to understand snapd better...
<zyga> sdhd-sascha: and many mounts within per-snap mount namespaces
<zyga> sdhd-sascha: look at cmd/snap-confine/
<zyga> sdhd-sascha: that part is implemented in C
<zyga> sdhd-sascha: there's a document that explains, though older, version of snap-confine
<sdhd-sascha> zyga: great :-)
<zyga> sdhd-sascha: as a super-simple overview each non-classic snap runs in a new mount namespace
<sdhd-sascha> i read a lot about "seccomp". what does this "abbrev" stand for ?
<zyga> sdhd-sascha: seccomp is a feature of the linux kernel
<zyga> sdhd-sascha: you can read about it by in many places, man pages are a good start, but it's essentially a way to control which system calls a given program may use
<sdhd-sascha> ah, ok
<zyga> sdhd-sascha: snap-confine creates a new mount namespace
<zyga> sdhd-sascha: which is essentially a new mount table that is no longer always identical to the one you see normally
<zyga> sdhd-sascha: then it performs a number of operations to change that mount table
<zyga> sdhd-sascha: one thing it does is perform a super-charged version of chroot, called pivot, to change what the snap sees as the root filesystem
<zyga> sdhd-sascha: I can tell you all the details about that if you have specific questions
<sdhd-sascha> zyga: understood ;-)
<zyga> sdhd-sascha: snaps using classic confinement (those that need snap install --classic something to install) are somewhat different
<zyga> sdhd-sascha: they also use a mount namespace but the mount table is very similar to the host mount table
<zyga> sdhd-sascha: and it is set up in a way that shares changes, so things mounted in one place show up in the other (e.g. you mount a drive on the system and the snap would see it)
<zyga> sdhd-sascha: snap-confine does a few more things but that's about it for the mount parts
<zyga> sdhd-sascha: oh, such mount tables are "persisted" so multiple processes started independently see the same mount table if they belong to the same snap
<sdhd-sascha> zyga: thank you again
<sdhd-sascha> currently sway runs in "devmode", so i concentrate on that now
<zyga> sdhd-sascha: devmode is a concept where the snap runs in a mount namespace but the confinement is not enforced
<zyga> sdhd-sascha: so it can do operations that normally are not allowed
<zyga> sdhd-sascha: or are only allowed if a specific interface is connected
<zyga> sdhd-sascha: this involves system calls that can be used, files and sockets that can be accessed as well as DBus messages that can be sent or received
<sdhd-sascha> from the past, i can remember, that with "fork" or a similar call, you can give a parameter which says, to e.g. share some file-descriptors with the child or leave it
<zyga> sdhd-sascha: file descriptors are shared across fork
<zyga> sdhd-sascha: but not always across exec
<sdhd-sascha> some days later i surely know what api-call snapd uses and if it can set similiar inheritence options
<zyga> sdhd-sascha: typically library code will set the equivalent of O_CLOEXEC on each file descriptor opened
<zyga> sdhd-sascha: and only clear that for things that need to be explicitly passed to executed program
<sdhd-sascha> zyga: it's many years ago, i read about linux-/unix-systemprogramming ;-)
<zyga> sdhd-sascha: manual pages are a great place to start
<zyga> sdhd-sascha: though they can be somewhat dense at first
<zyga> sdhd-sascha: cross-referencing each other
<zyga> sdhd-sascha: feel free to ask, I'm here most of the time
<sdhd-sascha> you are right. I'm the guy who read source, then open for 3 seconds the manual ...
<sdhd-sascha> zyga: "snap-confine", was a super hint. great :-)
<zyga> sdhd-sascha: oh, I forgot to share that link
<zyga> one sec
<zyga> sdhd-sascha: https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843
<zyga> it's not super up-to-date with latest changes but it's very good no-code overview
<sdhd-sascha> Good to know. Will read this maybe tomorrow. and try to delete the flock :-D
<sdhd-sascha> ============
<sdhd-sascha> One thing: can i access the X11 socket from the host - without mount /etc/font/fonts.conf
<zyga> sdhd-sascha: those are unrelated
<zyga> sdhd-sascha: the X socket is, on some systems, an abstract unix socket
<zyga> sdhd-sascha: so it's not a filesystem object, even though it has "path" like name
<sdhd-sascha> yes, here it is unix
<zyga> sdhd-sascha: on other systems it's a unix socket that is mounted in a location that is visible from the snap and from the host
<zyga> sdhd-sascha: and given the x11 interface is connected, the application process will have rights to open and use it
<zyga> sdhd-sascha: fonts are entirely unrelated
<zyga> sdhd-sascha: not sure why you mentioned /etc/font/font.conf but there are a number of interfaces for desktop interaction, specifically "desktop" is one such generic and broad interface that provides useful desktop-y things like font support, sharing of fonts from the host and more
<sdhd-sascha> interfaces/builtin/desktop.go:284:              // Since /etc/fonts/fonts.conf in the snap mount ns is the same
<sdhd-sascha> interfaces/builtin/desktop.go-285-              // as on the host, we need to preserve the original directory
<sdhd-sascha> zyga: i found only this, so i started to understand the namespaces.
<sdhd-sascha> and now i want to find, the interface which mounts this thing
<zyga> sdhd-sascha: that's "desktop"
<sdhd-sascha> zyga: it don't want to mention you any longer. You was a great help. I will figure it out by myself.
<zyga> sdhd-sascha: this is a place to start https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go
<zyga> snap interfaces provide "specifications"
<zyga> to various parts of the sandbox setup
<zyga> e.g. mount specification describes what to mount
<zyga> apparmor specification describes apparmor-level permisions (that's part of the sandbox)
<zyga> and so on
<zyga> various parts of snapd understand that and implement the policy described by the specifications
<sdhd-sascha> Have three more questions now:
<sdhd-sascha> * which part/source parse and execute this specs?
<sdhd-sascha> * what is the minimal way to clone an interface, modify it and register it into snapd.
<sdhd-sascha> * Okay, this one, i can ask google... How set snapd into the most verbose debug mode.
<sdhd-sascha> zyga: sorry. if you don't have time. Than i can wait and looking around by myself for today
<zyga> sdhd-sascha: it's all internally done by snapd
<zyga> sdhd-sascha: snapd passes each spec to a "backend" of a given kind (e.g. apparmor backend in snapd)
<zyga> sdhd-sascha: then the backend does some processing on all the specs combined (spec is for a specific interface, snaps may have many) and applies that in the system
<zyga> sdhd-sascha: all interfaces are declared inside snapd, so you'd have to create a new file in interfaces/builtin and define stuff there, the magic happens when the interface is registered, e.g. here: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go#L293
<zyga> sdhd-sascha: you can set SNAPD_DEBUG=7 or SNAP_DEBUG=7 (I always forget which)
<zyga> but but but
<zyga> be careful :)
<zyga> because snapd re-executes itself
<zyga> so you will not run your own code changes most of the time
<zyga> you can disable that by setting and exporting SNAP_REEXEC=0
<zyga> you can then define a new interface, even a dummy empty one
<zyga> and see that "snap interface --all" reports it
<sdhd-sascha> allright ;-)
<zyga> sdhd-sascha: there are lots of merged pull requests that show how an interface looks like
<zyga> sdhd-sascha: and what needs changing to add one
<zyga> sdhd-sascha: apart from adding the new .go file in the right spot there are a few small changes elsewhere
<zyga> sdhd-sascha: but that's not something you will need soon
<zyga> sdhd-sascha: some things are related to the so-called default policy and some more with integration tests
<sdhd-sascha> there are enough interfaces. i compare these, then i will see what is possible with interfaces...
<sdhd-sascha> you mean, desktop_test.go ?
<sdhd-sascha> e.g.
<zyga> no, those are unit tests
<zyga> integration tests are in tests/main/ in the top-level
<zyga> there are lots of those but there's one specific one that checks each interface type
<zyga> and it requires small change each time a new interface is defined
<sdhd-sascha> normally, i will found them
<sdhd-sascha> i always start with grep'ping the template interface. and look where it's name is used
<sdhd-sascha> usally i would take a interface with a random name, so i could find all places faster
<zyga> if there's something specific you'd like an interface to allow an app to do you can ask on the forum
<zyga> or ask here now
<sdhd-sascha> thanks :-)
<sdhd-sascha> Compliments to all Snapd developers, the source looks clean and structed!
<zyga> it's not all rosy but we do our best to keep it tidy :)
<mup> PR snapd#7810 closed: devicestate: add reading of modeenv to uc20 firstboot code <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7810>
<zyga> and my colleague is still working
<sdhd-sascha> :-)
<sdhd-sascha> how many core developer are in the snapd team ? In my past, i was mostly a one-man team :-( There was often no time to cleanup, or rewrite the code
 * cachio afk
<zyga> sdhd-sascha: ten-ish
<zyga> sdhd-sascha: though it's not all the same, we specialize and some members have different roles
<sdhd-sascha> oh, i am too exhausted for today. I will be there tomorrow
<zyga> good luck, stick around :)
<sdhd-sascha> :-)
<sdhd-sascha> i will. makes fun
<sdhd-sascha> hope i can soon adapt the code from alan_g and start another snap from wayland
<sdhd-sascha> ;-)
<sdhd-sascha> in some days, i will maybe have another question: How to start a console-command from another snap ? Because of the termite snap https://snapcraft.io/termite
<zyga> sdhd-sascha: can you be more specific?
<zyga> do you want to run one snap from another snap?
<zyga> or something else
<sdhd-sascha> alan has some repo with snapd in the mirServer repo
<sdhd-sascha> there are some modifications to start a snap "B" from snap "A"
<zyga> ah
<zyga> yeah, I know that branch
<zyga> it's not merged yet, I need to review it
<sdhd-sascha> at first glance, it looks like it can only start other desktop-applicaionts
<zyga> yes
<sdhd-sascha> now, i wonder, if we have some terminal-snap (e.g. gnome-terminal)
<zyga> starting arbitrary things is complicated
<zyga> there are technical reasons why it doesn't work
<sdhd-sascha> how could we launch "tig", "conjure-up" or other curses-application
<zyga> it's late, come back tomorrow and I can explain, ok?
<zyga> it _can_ be done
<zyga> but one must accept the limitations of what the resulting process is
<zyga> it won't be a descendant of the process requesting to launch it
<sdhd-sascha> yes :-) i will ask in some days, if i understood the current solution
<sdhd-sascha> another thought that I had,
<sdhd-sascha> Is it possible to create a master-snap template, and embed other snap's inside of them ?
<zyga> like a "fat" snap that has many snaps inside?
<zyga> yes
<sdhd-sascha> so anybody could create a snapcraft.yaml with, e.g. this desktop , this terminal, this app and combine them
<zyga> but there are limitations, some permissions are special
<sdhd-sascha> yes
<zyga> and we don't grant them easily
<zyga> only specific snaps can have powerful interfaces
<zyga> because we trust those publishers
<zyga> sometimes it's better to be interconnected with interfaces
<zyga> than to bundle and ask for the same interfaces that the originals had
<sdhd-sascha> But could there be a master-namespace ... and each embedded part of the snap, has an sub-ns ?
<zyga> it's not a namespace thing
<zyga> namespaces are one aspect
<zyga> it's really late, let's carry on tomorrow please
<sdhd-sascha> yes, it's late
<zyga> e.g. seccomp cannot be removed
<zyga> or lessend
<zyga> it can only be constrained
<zyga> think about that
<sdhd-sascha> And it's better to talk about it, when i have learned this in more depth
<zyga> if you cannot use syscall X because of a seccomp profile
<zyga> you cannot remove that constraint from a process, or its children
<zyga> this complicates things that involve one snap launching another snap
<zyga> (that constraint is enforced by the kernel)
<sdhd-sascha> good night ;-)
<Chipaca> sdhd-sascha: without reading the _whole_ backlog, about just executing arbitrary things, note https://forum.snapcraft.io/t/how-to-confine-a-desktop-shell/6561
<Chipaca> sdhd-sascha: and there are newer forum topics continuing this subject but i can't find them right now probably because it's late:)
<Chipaca> sdhd-sascha: https://forum.snapcraft.io/t/how-to-confine-a-desktop-shell/6561
<Chipaca> wait that's the same one
<Chipaca> ok i'm officially eod
#snappy 2019-11-29
<mborzecki> morning
<zyga> o/
 * zyga had a hard night
<mborzecki> zyga: hey
<zyga> hey
<zyga> mborzecki: janek is 13 today
<mborzecki> zyga: wow nice, best wishes for him :)
<zyga> and iza turned her room upside down
<zyga> being upset and angry well into midnight
<zyga> because she wanted to have something for the sims and we said no, and it went downhill from there
<mborzecki> hahaha ;)
 * zyga is sleeeeeepy
<zyga> (literally half of her stuff is downstairs as it slid down the stairs)
<mborzecki> quick errand, need to drop by the town hall, back in 1h or so
<zyga> she also tore our bed apart
<zyga> good luch
<zyga> luck I mean
<zyga> I need to wake up
<mborzecki> re for a little bit
<mborzecki> i keep forgetting, why do we avoid using x/sys/unix?
<zyga> mborzecki: no idea
<zyga> I think it used to not support ppc
<zyga> but now we don't support ppc eiter
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> ok, trying the town hall once again
<zyga> Hey
<zyga> Is town hall today?
<pstolowski> hey zyga
<zyga> :-)
<pstolowski> yeah i asked mborzecki the same, i don't have anything in my calendar
<zyga> I see Oct 24th
<zyga> nothing more?
<pstolowski> zyga: same here
<mborzecki> re
<mborzecki> zyga: no, i mean my local council ;) dealing with some beaurocracy stuff here
<zyga> ah ;D
 * Chipaca coffees up
<zyga> hey Chipaca  :)
<Chipaca> zyga: 'sup :)
<zyga> good, sleepy
<zyga> slow day
<Chipaca> zyga: yup
<Chipaca> zyga: feels like a saturday, here
<pstolowski> Chipaca: hey, i'll re-request a review for snapctl is-connected from you; the core implementation didn't change, but there is new stuff wrt error propagation between api and client
<pstolowski> Chipaca: and i feel it's a bit of muddy waters :}
<Chipaca> pstolowski: ok
<pstolowski> i'm going to push in a moment
<zyga-laptop> Chipaca http://asciicker.com/y0/
<zyga-laptop> Chipaca try f1 / f2
<ppd1990> Hi. Isn't snapcraft 3.9.2 supposed to be in the stable channel already?
<pstolowski> zyga-laptop: wow @asciicker
<Chipaca> ppd1990: supposed by who?
<ppd1990> Chipaca: https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-9/13944/26
<Chipaca> ppd1990: hm. Maybe it's phasing, or maybe somebody found an issue and it had to be rolled back?
<zyga> pstolowski: right? :)
<zyga> brb
<mup> PR snapd#7824 opened: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
<mborzecki> just when i thought mpt doesn't work again
<mpt> ?
<mborzecki> mpt: sorry, meant mup :)
<Chipaca> mborzecki: no rebooting mpt
<Chipaca> without their consent at least
<mborzecki> should rename mup to something more bot-like
<mpt> ð´
<ppd1990> Chipaca: Probably :)
<Chipaca> ppd1990: ask sergiusens in a few hours
<Chipaca> ppd1990: (or, ask in that forum thread)
<pstolowski> ppd1990: or ask on the forum
<Chipaca> wow, the models used for CV are yuge
<Chipaca> it's like 4GB of just models
<zyga> what are you doing with CV?
<mborzecki> osutil/stat.go:106:9: undefined: syscall.Faccessat on osx :/
<zyga> mborzecki: heh
<zyga> mborzecki: one sec
<zyga> yeah, no such syscall
<zyga> mborzecki: macos doesn't have a stable syscall layer
<zyga> so we should probably not use it
<zyga> it only has a stable .dylib layer
<mborzecki> zyga: can you check what value does R_OK have on osx?
<mborzecki> heh it's in x/sys/unix
<mborzecki> i mean, the Faccessat on osx
<Chipaca> zyga: just trying to get https://github.com/sniklaus/3d-ken-burns to work, for now
<zyga> aha
<mup> PR snapd#7825 opened: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7825
<zyga> I decided to open it without larger changes
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> mborzecki: I think landing and iterating will be just easier
<zyga> mborzecki: and will unlock more things to land in parallel
<zyga> (smaller things)
 * zyga is baby-sitting lucy 
<mborzecki> time for some reviews
<cachio> cmatsuoka, hey
<cachio> there is a bug that perhaps you could take a look https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852544
<mup> Bug #1852544: uc20 grubenv block seems odd <core20> <Gadget snap for Personal Computers using Intel or AMD processors:New> <Ubuntu Image:Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852544>
<cachio> it is related to UC20
<cmatsuoka> cachio: checking that
<cachio> cmatsuoka, thanks
<cmatsuoka> cachio: we're already working on that
<cachio> cmatsuoka, nice
<cachio> cmatsuoka, good to know
<cachio> cmatsuoka, is there a priority to assign to  the bug?
<cmatsuoka> I believe it's already fixed but I didn't check the latest image to see how it's going
<cmatsuoka> xnox: did we fix  https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852544 already? I believe so since you have a booting image (which I didn't check yet but's in my todo list for this morning)
<mup> Bug #1852544: uc20 grubenv block seems odd <core20> <Gadget snap for Personal Computers using Intel or AMD processors:New> <Ubuntu Image:Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852544>
<xnox> cmatsuoka:  i believe that is still wrong
<xnox> cmatsuoka:  in the gadget snap, i'm importing all the environment blocks, both good and bad.
<cmatsuoka> xnox: humm ok I'll check the plans with Michael
<cmatsuoka> xnox: thanks
<cachio> kenvandine,  hi
<cachio> kenvandine, I see and error when installing gimp in i386
<cachio> kenvandine, https://travis-ci.org/snapcore/spread-cron/builds/618422327#L3292
<cachio> is it being supoported right?
<mup> PR snapcraft#2827 closed: build providers: only set the snapd flag when installing snapd <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2827>
<sergiusens> ppd1990: there was an issue, I had to roll back temporarily https://github.com/snapcore/snapcraft/commit/1eebc27968e20e63ead11f7214c655284357fef2
<ppd1990> sergiusens: Thanks a lot for the info. Much appreciated!
<sergiusens> getting a bug (in my human body) did not help in making this go faster, sorry about that
<mup> PR snapd#7726 closed: RFC: change how snapd tracks processes <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7726>
<mup> PR snapd#7722 closed: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7722>
<mup> PR snapd#7486 closed: tests: add regression test for lp: #1844496 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7486>
<mborzecki> zyga: we don't have a type for security tags do we?
<mborzecki> zyga: i'm looking at #7825, and thiking that we may need a package to encode the ideas about naming things, like snap related cgroup, security tag and so on
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> mborzecki: nope
<zyga> mborzecki: security tag is more of an interface
<zyga> mborzecki: with a String() method
<mborzecki> zyga: for instance, right now the scope name is in snap run where it's created, and then some bits are in snapstate where the cgroup name is interpreted
<zyga> and a InstanceName() method
<zyga> I think we can clean it up a lot but ... it's a long path
<zyga> mborzecki: can you do a quick review on https://github.com/snapcore/snapd/pull/7784
<zyga> I can land it and iterate perhaps
<mup> PR #7784: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
<zyga> mborzecki: back to security tag, I think it ought to be an interface
<zyga> mborzecki: because we have several kinds of security tags that are not alike
<zyga> mborzecki: the concrete type of each could be string
<zyga> mborzecki: but the wrapper type would be more useful .e.g. hook security tag, app security tag, that weird non-app-non-hook security tag for some udev things
<zyga> mborzecki: it could have methods like SnapWideGlob()
<mborzecki> zyga: and then the scope & cgroup names
<zyga> and we could have a helper like GenrateScopeName(tag SecurityTag)
<zyga> *Generate
<zyga> mborzecki: how does that sounD?
<mborzecki> sounD :) like systemD? :P
<zyga> mborzecki: btw, offtopic, on fedora 31 I don't get snap icons in alt-tab in gnome
<zyga> probably related to the centos bug
<mborzecki> zyga: do you get them in the activities view?
<zyga> yes i do
<mborzecki> zyga: i suppose nothing in the logs?
<mborzecki> zyga: btw. wayland or xorg?
<zyga> wayland
<zyga> logs are always full of garbage
<zyga> lis 29 14:43:04 x240 gnome-shell[2041]: value "nan" of type 'gdouble' is invalid or out of range for property 'vignette-sharpness' of type 'gdouble' ;-)
<zyga> lis 29 14:43:10 x240 systemd[1841]: dbus-:1.2-org.gnome.Boxes.SearchProvider@14.service: Succeeded. ;)
<zyga> but nothing about the fact icons are gone
<mborzecki> heh, at least it's no spamming the logs like it did a month ago
<zyga> weirdish
<zyga> oh it's full of junk really
<mborzecki> right after 3.34 there'd be a constant 1-2kB/s of logs going to journal
<zyga> heh
<zyga> nvme pays for itself ;)
<mup> PR snapd#7784 closed: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7784>
<zyga> mborzecki: I cannot join yet
<zyga> lucy is waking up now
<zyga> mborzecki: my update is simple: working on more testing and follow-ups
<zyga> I'll update the doc shortly
<xnox> cmatsuoka:  i did snap refresh of ubuntu-image & snapd
<xnox> cmatsuoka:  created a fresh image
<xnox> it still has two copies of core & pc-kernel snaps
<xnox> once in /snaps and ones in /var/lib/snapd/snaps/
<xnox> the second location is not used on UC20 seed partition
<xnox> and grubenv is still in the wrong location at /boot/grub/ instead of at /EFI/ubuntu/
<kenvandine> cachio: afaik.  diddledan see the question about gimp?
<mborzecki> zyga: left some comments under 7825, need to play with this locally
<cachio> kenvandine, taj, ok, thanks
<diddledan> what's the spread test trying to do with gimp?
<zyga> mborzecki: sure, thank you
<zyga> thanks, replied to most
<zyga> I'll apply the trivials shortly
<zyga> mborzecki: note, I'm running this on F31 and it's not exploding :)
<zyga> it's pretty cool that I can see memory usage of my app
<zyga> mborzecki: sublime-text instance from a snap https://www.irccloud.com/pastebin/M8V1r6t3/
<cachio> diddledan, it just installs gimp
<diddledan> are you sure that's _all_ it is doing? because there's weird messages about "Match"ing stuff
<cachio> diddledan, this is the test https://github.com/snapcore/snapd/blob/master/tests/nightly/install-snaps/task.yaml
<cachio> diddledan, the MATCH is used to detect the channel and other info about the snap to isntall
<diddledan> so what is the actual failure condition then?
<cachio> diddledan, the test tries to install gimp in ubuntu 16.04 32bits
<cachio> and this is happening
<cachio> + snap install gimp --stable
<cachio> error: cannot perform the following tasks:
<cachio> - Ensure prerequisites for "gimp" are available (cannot install prerequisite "gtk2-common-themes": no snap revision available as specified)
<zyga> cachio: that's weird, I'm not getting that
<diddledan> yes, well that's not my fault then. that's down to whoever unpublished gtk2-common-themes from the 32bit stable channel :-)
<diddledan> it affects other snaps too
<diddledan> e.g. audacity
<cachio> diddledan, yes
<diddledan> (another of mine :-)
<diddledan> gtk2-common-themes is still available in 64bit so I'm assuming closing the 32bit stable channel was either a mistake or someone wasn't thinking things through
<cachio> I could include audacity to the test if you want
<cachio> to we detect this kind of errors on important snaps
<diddledan> in fact, gtk2-common-themes is _only_ availeble for amd64 now - it used to be available for i386.. https://snapstats.org/snaps/gtk2-common-themes
<diddledan> kenvandine: is this something for you to look into?
<kenvandine> Not sure what happened to i386
<diddledan> it is probably worth investigating adding armhf and arm64 too
<diddledan> for those of us that insist on using a pi as their desktop :-p
<kenvandine> Yeah
<kenvandine> I can't look at it today, but will on Monday
<diddledan> coolbeans :-)
<zyga> ah, 32bit systems
<zyga> interesting
 * cachio lunch
<mborzecki> zyga: 130MB for sublime?
<diddledan> all the MB!
<mborzecki> heh, actually my emacs is using 250MB of heap so, maybe 130 isn't that much after all
<zyga> mborzecki: yeah
<zyga> mborzecki: I guess that's all the .so's loaded and stuff
<zyga> mborzecki: but it's really neat
<zyga> because we _can_ measure it
<mborzecki> finally #7824 is green
<mup> PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
 * zyga participated in his son's birthday
<pstolowski> cachio: 2 questions to #7815, once clarified i can +1 it
<mup> PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>
<Chipaca> i'ma gonna go ahead and EOW
 * Chipaca just broke all the tests
<Chipaca> see y'all monday
<sdhd-sascha> zyga: hi, Hope your day was better than the night.
<zyga> sdhd-sascha: it was pretty calm :)
<sdhd-sascha> :) I had to help the in-laws today.
<sdhd-sascha> I had two small question, if you have time ?
<zyga> sure
<sdhd-sascha> Is it possible to use a part only on a specific release (e.g. only on bionic) ?
<zyga> are you asking about building in snapcraft?
<sdhd-sascha> i found the advanced-grammer - but until now no source code
<sdhd-sascha> yes
<zyga> yeah
<zyga> the source code is in a sister project, there are tests for this feature
<zyga> which can be used as quick documentation
<zyga> it's github.com/snapcore/snapcraft
<sdhd-sascha> ok, i have it already here
<zyga> I don't know the details, I think it's meant for system packages that can be injected into a snap package
<zyga> you can vary those depending on build architecture IIRC
<zyga> but it's not for this-or-that release
<zyga> because the release is fixed by the selection of the base snap
<zyga> inside snap.yaml and snapcraft.yaml you can say base: foo
<zyga> and foo is a base snap name that defines how to build it
<zyga> and how to run it
<zyga> there are two commonly used base snaps now
<zyga> core, which is derived from ubuntu 16.04
<zyga> and core18 which is derived from ubuntu 18.04
<sdhd-sascha> yes :-)
<zyga> if you say base: core18 you will get binary packages from the matching architecture of that release
<sdhd-sascha> i found it inside git:snapcraft/internal/project_loader/grammer/_on.py
<sdhd-sascha> https://www.irccloud.com/pastebin/UecwmS5C/
<sdhd-sascha> my problem is, that fontconfig of my 19.04 host is incompatible, with core18 ... Ok, i will try if a newer fontconfig inside a part is backward compatible
<zyga> yeah, as I said it's for things like "on arm64 use this package" on "amd64 use that package"
<zyga> wait wait
<zyga> your host should not be a part of the build
<zyga> when you build with snapcraft your tree should be transferred to a pristine vm managed by multipass
<zyga> and built there
<sdhd-sascha> Yes, but /etc/fonts/font.conf is from the host and mounted inside the snap
<zyga> the vm will match the base you picked
<zyga> ah, yes
<zyga> and what are you seeing?
<zyga> we have some special handling for fontconfig
<zyga> perhaps there's a bug or the current system is insufficient
<sdhd-sascha> i see:
<sdhd-sascha> Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute 'translate'
<zyga> can you please report that, along with the output of "snap version" on bugs.launchpad.net/snapd
<zyga> we'll have a look on Monday
<zyga> I have a plan to stop sharing /etc
<zyga> as it was a mistake
<zyga> but it's not urgent enough to push through
<zyga> (there are higher priority topics first)
<zyga> once that is done we can synthesize correct /etc/fonts and anything else that matches the base snap
<sdhd-sascha> ok. Also the goal is to not share /etc. right? (only i ask only for me, because i will experiment on this weekend)
<zyga> that's my goal
<zyga> it's not on the product roadmap
<zyga> it will likely happen during the cycle
<sdhd-sascha> Why would it be bad, to build fontconfig into the snap? (not urgent this question, i will try this too)
<zyga> you can
<zyga> but it's just bigger
<zyga> and usually there's a fontconfig around from other places
<zyga> e.g. the gnome runtime content snap
<sdhd-sascha> ok
<zyga> snaps don't have a "you must" policy usually
<zyga> so if you want to showcase a cool feature of patched fontconfig
<zyga> go for it :)
<zyga> it's not like classic packaging
<sdhd-sascha> The second question was: What is the difference of plugs/slot inside apps and inside global?
<zyga> right
<zyga> so, in general, each app and hook can have any number of plugs and slots
<zyga> if you define a plug at a level of a specific app or hook it is "bound" there
<zyga> if you define it globally you add it to all the apps and hooks
<zyga> except if you define it globally but then only mention it in a specific app or hook
<sdhd-sascha> ok. i understand.
<zyga> the reason to define plugs and slots globally is so that you can use the richer syntax that has attributes
<zyga> some interfaces require that
<zyga> at app/hook level you can only use the abbreviated syntax
<zyga> where just the name is given
<zyga> and it defines a plug or slot with the same name and type
<zyga> one example that is very common, that requires global definitions is the content interface
<zyga> because it always requires some attributes
<zyga> that's that
<zyga> I think it's fairly documented on snapcraft.io/docs
<zyga> but if you find something is missing or unclear please just say so
<sdhd-sascha> The docs have also hidden pages, which are not in the menu, only in the text...
<sdhd-sascha> About plugs/slots:
<zyga> missing links are easy to fix
<zyga> you can just go to the forum
<zyga> and comment on the thread
<zyga> there's a link on each doc page
<sdhd-sascha> Now if a snap provide wayland and can also run under wayland, how should this be defined ? I got a error, if i use the wayland plug/slot as both
<zyga> or ping @degville about it, he's managing documentation
<zyga> so interfaces have two sides, plugs and slots
<sdhd-sascha> :)
<zyga> slots are the "providing" part, and plugs are the "consuming" side
<zyga> having a plug or slot may already give you some permission
<zyga> having a plug or slot connected to another slot or plug usually gives even more permissions
<zyga> are you asking what is needed to run a wayland _server_?
<sdhd-sascha> Both, wayland as client under wayland. And wayland as server, and later as client for other snaps.
<zyga> ahj
<zyga> I see
<zyga> so you need two interfaces
<sdhd-sascha> But we can delay this question.
<zyga> plug and slot of wayland
<zyga> they just need to have different names
<sdhd-sascha> Ah
<zyga> plugs: wayland-client: interface: wayland
<zyga> slots: wayland-server: interface: wayland
<sdhd-sascha> okay, then copy, paste the interface
<zyga> (insert tabs and newlines as required)
<zyga> yeah
<sdhd-sascha> i understand
<zyga> we added a requirement for plugs and slots to have unique names
<zyga> to avoid confusing situations
<sdhd-sascha> zyga: thank you. Now i have enough task, for the weekend ;-)
<zyga> enjoy :)
<sdhd-sascha> :)
 * cachio afk
<mup> PR snapd#7826 opened: tests: use on spread tests the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826>
#snappy 2019-11-30
<mup> Bug #1646625 changed: on first boot rpi2 cannot configure (core16) <Snappy:Expired> <subiquity:Expired> <https://launchpad.net/bugs/1646625>
#snappy 2019-12-01
<mup> Bug #1634088 changed: Cannot activate Chinese input method for Qt app <Snappy:Expired> <https://launchpad.net/bugs/1634088>
<mup> Bug #1637196 changed: Pi 3 drops off network on update <Snappy:Expired> <https://launchpad.net/bugs/1637196>
<mup> Bug #1671062 changed: Cannot open rocketchat-server on a VM <Snappy:Expired> <https://launchpad.net/bugs/1671062>
