[03:54] <mup> PR snapcraft#1642 opened: tests: move the plainbox test to the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1642>
[03:57] <mup> PR snapcraft#1643 opened: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643>
[05:26] <zyga-ubuntu> good morning
[05:33] <mvo> zyga-ubuntu: good morning !
[05:33] <mvo> zyga-ubuntu: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810 - looks like something for pawel
[05:43] <mup> PR snapcraft#1644 opened: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
[05:55] <mup> PR snapd#4079 closed: daemon: allow Polkit authorization to cancel changes <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4079>
[06:07] <mup> PR snapd#4082 opened: cmd/snap: tell translators about arg names and descs req's (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4082>
[06:08] <mup> PR snapd#4083 opened:  snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4083>
[06:11] <mup> PR snapd#4084 opened: interfaces: clean system apparmor cache on core device (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4084>
[06:12] <Guest63697> Hello currently working on ubuntu core 16 need to build qt application which works on postgres database do
[06:12] <Guest63697> on need to create a separate snaps for it
[06:12] <Guest63697> and is any document for qt and postgres
[06:15] <zyga-solus> Guest63697: hello
[06:15] <zyga-solus> Guest63697: I don't know about postgres but there's something for a kiosk qt app
[06:15] <zyga-solus> Guest63697: my suggestion would be to get postgress up and running
[06:16] <zyga-solus> Guest63697: and then move on to qt
[06:16] <zyga-solus> Guest63697: also, not sure why you want separate snaps for that but that's ok, you will just need to use content interface to share data/sockets so that they can talk to each other
[06:16] <mup> PR snapd#4085 opened:  debian: do not build static snap-exec on powerpc (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4085>
[06:16] <Guest63697> zyga-solus: Hi for more details i am currently working on dell edge gateway 5000 with ubntu core16 installd
[06:18] <zyga-solus> Guest63697: right, you can prototype this on a typical ubuntu system (16.04 is ideal) and then just install the resulting snap on the device
[06:18] <zyga-ubuntu> mvo: o, looking
[06:19] <Guest63697>  zyga-solus: I am new to the core os i just tried running hello world application so needed jus help to move my existing application to core :)
[06:19] <zyga-ubuntu> mvo: aha, I see that service management test failed
[06:20] <zyga-solus> Guest63697: I suggest you start by learning about snapcraft, using snaps on your 16.04 desktop/laptop (classic system) and playing with your core system with a few snaps
[06:20] <zyga-solus> Guest63697: build a hello-world.c from source, see how that looks like
[06:20] <zyga-solus> Guest63697: then look at what it would take to run postgres
[06:20] <zyga-solus> Guest63697: or separately at kiosk-style Qt (this is documented on the forum)
[06:21] <zyga-solus> Guest63697: in the end all the pieces will come together and you should get it to work fine
[06:21] <zyga-solus> Guest63697: stick around, join the forum, experiment. read, and ask :)
[06:21] <zyga-solus> oh, and welcome :-)
[06:21] <zyga-ubuntu> mvo: I'll ignore that master failure for now unless pawel comes around and asks for help
[06:21] <zyga-ubuntu> mvo: I need to finish apparmor changes for overlayfs
[06:22] <zyga-ubuntu> mvo: and expand the spread tests for that
[06:22] <Guest63697>  zyga-solus: I have been searching on the web a multiple links can you please suggest any useful and just for curiosity should i put all the application and its dependecy under one snp
[06:22] <zyga-solus> Guest63697: try forum.snapcraft.io
[06:22] <zyga-solus> Guest63697: we also have a snapcraft tutorial on ...
[06:22] <zyga-solus> https://docs.snapcraft.io/build-snaps/your-first-snap
[06:22] <mvo> zyga-ubuntu: yeah, just a heads up about the failure not a request-for-action :)
[06:23] <zyga-solus> note that you can use a classic "regular" ubuntu system for all of this
[06:23] <zyga-solus> that's the beauty of snaps :)
[06:23] <Guest63697>  zyga-solus: sure thanks
[06:23] <zyga-solus> in the end you just deploy it on core
[06:23] <zyga-ubuntu> mvo: ack, thank you :)
[06:23] <mup> PR snapd#4081 closed: systemd: run all mount units before snapd.service to avoid race <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4081>
[06:23] <zyga-ubuntu> mvo: I was asking my son if he would like to wake up at 3AM tomorrow to look at sunirse in the nearby fields, we could take some photos of the birds nesting there
[06:23] <zyga-ubuntu> mvo: I was talking about this the whole week
[06:24] <zyga-ubuntu> mvo: and while earlier he was "yeah dad, that would be fun"
[06:24] <zyga-ubuntu> mvo: today he said "but if we stay at home, can we sleep longer"
[06:24] <zyga-ubuntu> mvo: I think I lost that one :)
[06:24] <zyga-ubuntu> mvo: if you want I can work on mount unit refresh later today
[06:25] <zyga-ubuntu> mvo: I'd like to think how to approach that: as a fixup type thing or as a change in how we maintain them
[06:28] <mup> PR snapd#4086 opened: snap-confine: increase sanity_timeout to 6s <Created by mvo5> <https://github.com/snapcore/snapd/pull/4086>
[06:28] <mvo> zyga-ubuntu: it seems conceptually cleaner to do the later
[06:29] <zyga-ubuntu> mvo: I agree but then my conclusion was, if this is something that will run in ensure (that is, all the time)?
[06:30] <zyga-ubuntu> mvo: and if so, what should we do after we notice that the files were chaned
[06:30] <zyga-ubuntu> mvo: I was thinking that this is where it gets hairy
[06:30] <zyga-ubuntu> mvo: we could log "discrepancy in unit %q"
[06:30] <zyga-ubuntu> mvo: and do nothing at all (for this specific case that's fine)
[06:30] <zyga-ubuntu> mvo: but it feels like a stretch of the concept
[06:30] <zyga-ubuntu> mvo: we also don't have similar ensure for interfaces
[06:30] <zyga-ubuntu> mvo: but
[06:31] <zyga-ubuntu> mvo: if we actually do this then the system is self-healing in a nice way
[06:31] <mvo> zyga-ubuntu: well, if its a one-off thing we should handle it like this and not complicate things, just a "fixupMountUnits()" somewhere
[06:31] <zyga-ubuntu> mvo: ^ commented on the PR, I think you need to change a few tests too
[06:31] <mvo> zyga-ubuntu: 2.29 is super close this healing thing may not even make it
[06:32] <zyga-ubuntu> mvo: yes, I agree we absolutely have to have something for 2.29, so a fixup is good
[06:32] <mvo> zyga-ubuntu: aha, thanks. we have two autopkgtest failures where the alarm goes of
[06:32] <zyga-ubuntu> mvo: maybe 2.31 target for generic healing
[06:32] <mvo> zyga-ubuntu: 2.29 is super close, candiate targeted monday so it may not even make it
[06:32] <mvo> zyga-ubuntu: but if it does even better
[06:32] <mvo> zyga-ubuntu: I plan ~rc2 today
[06:32] <mvo> zyga-ubuntu: and hopefully that is the last one
[06:32] <zyga-ubuntu> mvo: for the tests we need "make check" to pass
[06:33] <zyga-ubuntu> mvo: what about 4008?
[06:34] <mvo> zyga-ubuntu: its still hanging there, I wanted to see where things are at lunchtime, if everything else is in and ready +1
[06:35] <mvo> zyga-ubuntu: thanks, I adjusted the test now. I did a force push to make it easier to cherry-pick (either way)
[06:36] <zyga-ubuntu> mvo: no worries, I approve of --force ;D
[06:47] <mup> PR snapd#4087 opened: cmd: downgrade log message in InternalToolPath to Debugf() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4087>
[07:32] <mvo> pstolowski: hey, good morning. you have two 2.29 targeted PRs, could you please create a branch based on upstream/release/2.29 and cherry-pick your commits to it so that we merge to 2.29?
[07:32] <mvo> pstolowski: also master is failing right now
[07:34] <pstolowski> mvo, sure
[07:35] <pstolowski> mvo, what is failing?
[07:43] <kalikiana> o/
[07:58] <Guest63697>  zyga-ubuntu: I am trying run the qt4 text editor example on from snapcraft github it is giveing error as application cannot connect to x server
[08:00] <zyga-solus> Guest63697: on core or on classic?
[08:00] <Guest63697>  zyga-ubuntu: on core
[08:01] <zyga-solus> on core there's no display stack
[08:01] <zyga-solus> you need to look at qt + kiosk mir demos for that
[08:15] <mvo> pstolowski: sorry for the delay, I was distracted: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810
[08:15] <mvo> pstolowski: maybe racy?
[08:15] <mvo> pstolowski: line 5810 (takes forever to load for me :/
[08:16] <mvo> pstolowski: maybe https://travis-ci.org/snapcore/snapd/builds/293175118#L5758 works better?
[08:17] <mvo> pstolowski: the gist is http://paste.ubuntu.com/25828740/
[08:17] <pstolowski> mvo, thank you
[08:17] <pstolowski> mvo, oh damn.. this indeed might be racy. i wonder what to do about that test :(
[08:18] <mvo> pstolowski: sleep 10 - what we always do (kidding of course)
[08:18] <pstolowski> i guess we need a function that tries a couple of times until a timeout passed, then it gives up
[08:19] <mvo> pstolowski: yeah, I think that is sensible
[08:20] <pstolowski> mvo, ok, i'll work on this, sorry about the problem
[08:21] <mvo> pstolowski: no worries, thank you
[08:23] <pstolowski> mvo, when cherry-picking for 2.29, is it ok to squash?
[08:25] <mvo> pstolowski: if it is merge in master already then please cherry-pick individually otherwise the merge of 2.29 into master will be infected with conflicts
[08:26] <mvo> pstolowski: if it is not merged yet the easiest is to squash merge when merging into master to get any easy cherry-pick
[08:27] <pstolowski> mvo, ack
[08:40] <pedronis> mvo: hi,  I'm trying to finish something not to lose state, let's talk about ignore-validation after lunch
[08:42] <mvo> pedronis: +1
[08:54] <mup> PR snapd#4082 closed: cmd/snap: tell translators about arg names and descs req's (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4082>
[09:01] <ackk> is there a way for a snap to know the underlying os version? (not the core snap one)
[09:04] <zyga-solus> ackk: mmm, no I don't think there is
[09:17]  * zyga-ubuntu -> coffee
[09:17] <mvo> pstolowski: while you fix the test I can help with the 2.29 cherry-picks for 4070 - we need this for 2.29, right? its a bugfix aiui?
[09:19] <mup> PR snapd#4088 opened: snapctl: cherry pick service commands changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/4088>
[09:20] <pstolowski> mvo, ^
[09:21] <pstolowski> mvo, yes, it's kind of a bugfix
[09:23] <pstolowski> mvo, nb, i think 4080 is not very important for 2.29
[09:27] <mvo> pstolowski: thank you
[09:28] <mvo> pstolowski: what branches does 4088 cover? i.e. which of the previous PRs that were tagged 2.29?
[09:29] <pstolowski> mvo, 4070 and 4065 (the latter for prerequisite for the former anyway)
[09:31] <zyga-solus> oooh
[09:31] <zyga-solus> man
[09:31] <zyga-solus> after using vim for what, 20 years
[09:31] <zyga-solus> I learned what "x" is for when in directory listing mode
[09:33] <mvo> pstolowski: do we need to cherry-pick b693557 in 4088 as well? its the last commit in 4070?
[09:34] <pstolowski> mvo, oh yes, that a test only, but yes. done
[09:34] <mvo> ta
[09:35] <ackk> zyga-solus, do you think that adding an interface for allowing that would be accettable?
[09:35] <zyga-solus> ackk: not sure how such an interface would look like
[09:35] <zyga-solus> ackk: why do you need this information?
[09:35] <zyga-solus> ackk: and how would you expect to read it?
[09:36] <ackk> zyga-solus, for an app to expose the information. perhaps reading /etc/os-release from the host (possibly linked somewhere else)
[09:38] <zyga-solus> ackk: most apps I know of don't read or expose /etc/os-release, I'm sure there must be some special cases though that's why I'd like to understand the need better
[09:38] <zyga-solus> ackk: /etc/os-release says you are on ubuntu core
[09:41] <ackk> yeah
[09:52] <pstolowski> mvo, ok, i've a tentative fix for test race, let's see how travis likes it, i've never experieced it locally
[09:53] <mvo> pstolowski: great
[09:53] <pstolowski> and i hope it's a race, nothing else
[09:53] <mvo> pstolowski: looking forward to it, my top priority for today is to get the 2.29 branches in and release 2.29~rc2 to beta so that it can go to candidate monday. having master in good shape is vital .)
[09:53] <mvo> pstolowski: yeah
[10:10] <zyga-solus> man, it's cold today
[10:10] <mup> PR snapd#4088 closed: snapctl: cherry pick service commands changes <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4088>
[10:11] <mup> PR snapd#4089 opened: tests: wait for service status change & file update in the test to avoid races <Created by stolowski> <https://github.com/snapcore/snapd/pull/4089>
[10:12] <pstolowski> mvo, ^
[10:16] <mvo> pstolowski: thanks a bunch, lets see if travis is happy with this
[10:27] <zyga-solus> ok
[10:27] <zyga-solus> fingers crossed
[10:29] <zyga-solus> mvo: so just to confirm, 4008 should be squash merged today
[10:34] <mvo> zyga-solus: if we want it in, yes
[10:37] <zyga-solus> mvo: ok, please tell me when
[10:55] <kalikiana> zyga-solus: ackk /etc/os-release is already exposed in apparmor afair
[10:57] <zyga-solus> kalikiana: yes but it doesn't show you the real /etc/os-release file
[10:57] <zyga-solus> kalikiana: it shows the one from the core snap
[10:59] <kalikiana> zyga-solus: Hmm classic snaps can see the real file... but I guess in that case apparmor doesn't apply anyway
[11:01] <zyga-solus> kalikiana: can you show me how you determined that?
[11:02] <zyga-solus> kalikiana: I just saw the file from core snap on a 16.04 test vm
[11:03] <kalikiana> zyga-solus: snapcraft can read the file. From checking interfaces/apparmor/template.go in snapd sources it's not obvious, though, if that applies or not
[11:03] <kalikiana> To me at least
[11:03] <zyga-solus> kalikiana: I didn't say that it is not unreadable, it *is* readable
[11:04] <zyga-solus> kalikiana: I said that it should almost always contain the /etc/os-release file from the core snap or other base snap that is used by a given app snap
[11:04] <zyga-solus> kalikiana: thus when read on fedora it will not say "fedora"
[11:04] <zyga-solus> kalikiana: it will consistently say "ubuntu core" or whatever the base snap says
[11:05] <kalikiana> zyga-solus: Right. I didn't mean to contest that... maybe bad wording on my part
[11:05] <zyga-solus> kalikiana: no worries, I just wanted to explain what I meant earlier :)
[11:08] <kalikiana> zyga-solus: I think it technically makes sense so long as you have no access to the underlying system. Tho it would make something like a user agent that's used for statistical purposes impossible
[11:11] <mup> PR snapd#4089 closed: tests: wait for service status change & file update in the test to avoid races <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4089>
[11:11] <zyga-solus> kalikiana: yes, I agree
[11:11] <zyga-solus> technically we have the real file in /var/lib/snapd/hostfs/{etc,lib}/os-release but it is not readable in strictly confined apps
[11:29] <mup> PR snapd#4087 closed: cmd: downgrade log message in InternalToolPath to Debugf() <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4087>
[11:57] <zyga-solus> hrm
[11:57] <zyga-solus> some good and some bad news
[11:57] <zyga-solus> let's make a PR
[12:04] <jdstrand> zyga-solus, kalikiana: /var/lib/snapd/hostfs/{etc,lib}/os-release is actually allowed via system-observed
[12:04] <jdstrand> system-observe*
[12:05] <mup> PR snapd#4090 opened: interfaces/mount: exspose mount.{Escape,Unescape} <Created by zyga> <https://github.com/snapcore/snapd/pull/4090>
[12:07] <zyga-solus> jdstrand: oh!
[12:07] <zyga-solus> jdstrand: that's neat, I didn't know
[12:07] <zyga-solus> (and didn't check apparently :)
[12:08] <zyga-solus> mvo: I'm merging 4008 (squash)
[12:08] <zyga-solus> mvo: speak now to stop me please
[12:09] <zyga-solus> mvo: 3...
[12:10] <mup> PR snapd#4086 closed: snap-confine: increase sanity_timeout to 6s <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4086>
[12:10] <zyga-solus> mvo: 2...
[12:11] <zyga-solus> mvo: 1...
[12:12] <zyga-solus> merging
[12:13] <mup> PR snapd#4008 closed: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4008>
[12:16] <mup> PR snapd#4060 closed: interfaces: clean system apparmor cache on core device <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4060>
[12:16] <mup> PR snapd#4091 opened: cmd/snap-update-ns: allow fault injection to provide dynamic result <Created by zyga> <https://github.com/snapcore/snapd/pull/4091>
[12:16] <mvo> zyga-solus: ok, no worries
[12:17] <zyga-solus> mvo: you can cherry pick for 2.29
[12:22] <kalikiana> jdstrand: Does system-observed change which one /etc/os-release points to? Is it still the one from the core snap?
[12:23] <zyga-ubuntu> kalikiana: no, it doesn't
[12:23] <mup> PR snapd#4069 closed: debian: do not build static snap-exec on powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4069>
[12:23] <mup> PR snapd#4092 opened: cmd/snap-update-ns: allow Change.Perform to return changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4092>
[12:24] <mup> PR snapd#4080 closed: snapctl: added long help to stop/start/restart command <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4080>
[12:25] <mup> PR snapd#4085 closed:  debian: do not build static snap-exec on powerpc (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4085>
[12:30] <mup> PR snapd#4083 closed:  snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4083>
[12:30] <mup> PR snapd#4084 closed: interfaces: clean system apparmor cache on core device (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4084>
[12:33] <mvo> zyga-ubuntu: just to double check - freezeSnapProcess() is now called everytime snap-update-ns is run, right? with 4008?
[12:34] <zyga-solus> yes
[12:43] <cachio> kenvandine, hey
[12:49] <zyga-solus> mvo: I have one more for 2.29.2
[12:51] <mvo> zyga-solus: which one?
[12:51] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4093
[12:51] <mup> PR #4093: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4093>
[12:51] <zyga-ubuntu> just one liner
[12:52] <zyga-ubuntu> but it will help us in case 4008 explodes in the field
[12:52] <kenvandine> cachio, hey
[12:52] <mvo> zyga-ubuntu: ok
[12:52] <mup> PR snapd#4093 opened: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4093>
[12:53] <cachio> kenvandine, I copied the approach you use for the calculator
[12:53] <cachio> kenvandine, but still it can't access to the gsettings schema
[12:53] <cachio> I it copying the schema to the correct place
[12:54] <kenvandine> cachio, can i get a checkout of your yaml?  I'll try it myself
[12:54] <cachio> kenvandine, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings
[12:54] <kenvandine> cachio, i have a bunch of snaps all using gsettings
[12:54] <cachio> kenvandine, I know
[12:55] <jdstrand> kalikiana: system-observe doesn't change the system. you can either look at /etc or /usr/share/... for what the os-release is for the snap's runtime (you have access to this by default), or you can plugs system-observe and look in hostfs to see what the host system is
[12:55] <jdstrand> zyga-solus: re new> yes, it is a recent update
[12:55] <kenvandine> cachio, oh... you aren't using the desktop helpers
[12:55] <kenvandine> i bet that has something to do with it
[12:55] <cachio> kenvandine, how should I add it?
[12:56] <kenvandine> the desktop helpers probably tweak the schema env
[12:56] <kenvandine> after: [desktop-gtk3]
[12:56] <kenvandine> for example
[12:56] <kenvandine> and command: desktop-launch check-schema
[12:56] <kenvandine> or you can look at the launcher script and reproduce that in your own script
[12:57] <cachio> kenvandine, ok, I'll try that
[12:57] <kenvandine> that helpers sets lots of env needed for desktop stuff
[12:57] <cachio> kenvandine, thanks
[12:57] <kenvandine> np
[13:00] <kalikiana> jdstrand: Alright, that makes sense, thanks for clarifying! I guess even in that case it's best to have both available and not just change behavior.
[13:29] <mup> PR snapcraft#1625 closed: tests: use the snapcraft snap for integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1625>
[13:34] <zyga-ubuntu> jdstrand: hey
[13:35] <zyga-solus> jdstrand: do you have 15 minutes to consider and answer a question?
[13:35] <zyga-solus> jdstrand: it would require you to have spread (local or remote) and checkout my branch, run it, get a denial and see what you think about it
[13:36] <zyga-solus> jdstrand: I suspect you know the answer without running it
[13:36] <zyga-solus> jdstrand: but I wanted to check
[13:39] <cachio> kenvandine, works with the desktop-lunch
[13:39] <cachio> launch
[13:39] <om26er> popey: hey! was looking at this yaml a few days ago but couldn't find it today. Do you have a copy ? https://github.com/snapcrafters/pycharm-community/blob/master/snap/snapcraft.yaml
[13:39] <cachio> thanks
[13:39] <om26er> (need that yaml file to snap a related project)
[13:39] <kenvandine> cachio, cool
[13:39] <popey> hi om26er
[13:40] <popey> i deleted the repos from snapcrafters because it's owned upstream now. I have a backup though, can pastebin if you need it?
[13:40] <om26er> popey: yes, that would do.
[13:41] <popey> http://paste.ubuntu.com/25830418/
[13:41] <mup> PR snapd#4094 opened: tests: cherry pick the fix for services test into 2.29 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4094>
[13:43] <pstolowski> mvo, ^
[13:44] <mvo> pstolowski: ta!
[13:45] <pstolowski> mvo, the changes to help docs seem to already be there in 2.29, guess you merged them
[13:45] <mvo> pstolowski: yeah, I cherry picked
[13:45] <pstolowski> cool, thanks
[13:48] <om26er> popey: I would need the .desktop file as well :)
[13:49] <popey> http://paste.ubuntu.com/25830453/
[13:49] <popey> sorry
[13:57]  * zyga-solus lunches
[14:02] <mup> PR snapd#4093 closed: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4093>
[14:02] <zyga-solus> thank you :)
[14:03] <pedronis> mvo: is Chi-paca supposed to be back Monday?
[14:04] <mvo> pedronis: AFAIK he is
[14:04] <mvo> zyga-solus: thank *you* and cherry-picked into 2.29
[14:07] <mup> PR snapd#4095 opened: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4095>
[14:11] <mattyw> hey folks, is it possible to have private snaps using the public store?
[14:11] <om26er> when will build.snapcraft respect `architectures` config ?
[14:16] <jdstrand> kenvandine: hey, fyi I noticed an issue with the gedit snap
[14:16] <ogra_> om26er, https://forum.snapcraft.io/t/snapcraft-build-on-hint-for-builders/939
[14:16] <kenvandine> jdstrand, oh?
[14:16] <noise][> mattyw: yes, but just keep in mind a private snap is just for the publisher and collaborators, e.g. for QA prior to release. Collaborators have full read-write access to the snap.
[14:17] <jdstrand> kenvandine: if you go to open a file and get the gtk3 file chooser, in the upper left the 'Documents', etc don't work as expected because they are expecting those folders to be under SNAP_USER_DATA (ie, what HOME is set to)
[14:17] <mattyw> noise][, is it possible to define who the collaborators are - like if I have a snap that I just want people in my team to have access to?
[14:17] <jdstrand> kenvandine: the Documents, etc in the lower left all work fine
[14:17] <kenvandine> jdstrand, yeah, i haven't figured out what to do with that
[14:17] <kenvandine> portals will help
[14:18] <noise][> mattyw: yes - on your snap details page on dashboard.snapcraft.io, there's a "Collaboration" link in the side nav
[14:18] <jdstrand> kenvandine: it should. another idea is to symlink from SNAP_USER_DATA/Documents to /home/user/Documents
[14:18] <kenvandine> jdstrand, oh... we could do that in the helpers
[14:18] <kalikiana> kyrofa: when you're up, perhaps we can chat about snapcraft#1641 briefly?
[14:18] <mup> PR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
[14:18] <jdstrand> right
[14:19] <jdstrand> zyga-solus: can you just show me the denial, the spread test and the branch of the code?
[14:21] <kyrofa> kalikiana, let me take a look here...
[14:22] <kenvandine> jdstrand, i'll take a swing at that
[14:22] <kyrofa> kalikiana, alright, want to HO real quick?
[14:22] <zyga-solus> jdstrand: ha, no denial, this is overlayfs
[14:22] <kalikiana> kyrofa: Yeah, gimme 1 minute to fetch my headset
[14:22] <kyrofa> Sure thing
[14:23] <zyga-solus> jdstrand: I can show you the branch if you want to try
[14:23] <zyga-solus> one sec
[14:24] <kenvandine> jdstrand, actually the helpers run from within the snap and don't have access to $HOME
[14:25] <zyga-ubuntu> jdstrand: fetch my remote please, go to feature/transparent-overlayfs and pop one patch off, that is go to bc687e812a693afe532f51803645cc41d027de00 - then run SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/interfaces-content-mkdir-writable:snap
[14:25] <kyrofa> kalikiana, haha you're ringing my phone, hold on, I need to learn how to use hangouts
[14:25] <kalikiana> kyrofa: https://hangouts.google.com/hangouts/_/ygq3wu36wzebfjotr7gdj7ofhye
[14:25] <kenvandine> we'd have to do some mangling of the paths like in $SNAP_USER_DATA
[14:25] <kalikiana> kyrofa: Oh, heh. Wasn't my intention. Just created a hangout ( I think...)
[14:25] <kyrofa> Ah excellent
[14:26] <zyga-ubuntu> jdstrand: I'm running it here
[14:27] <jdstrand> kenvandine: gedit plugs the home interface
[14:28] <kenvandine> yes
[14:28] <kenvandine> but we don't have proper $HOME i meant
[14:28] <kenvandine> so we would need to strip out part of the path
[14:28] <kenvandine> doable though
[14:28] <jdstrand> use getent. there is already stuff in there
[14:28] <kenvandine> oh cool
[14:29]  * zyga-ubuntu is a bit preoccupied and worried about Spain vs Catalonia just now; Catalonia has just declared independence 
[14:29] <jdstrand> kenvandine: getent passwd $UID | cut -d ':' -f 6
[14:29] <kenvandine> jdstrand, yeah, thanks!
[14:29]  * kenvandine always forgets about getent :)
[14:29] <jdstrand> zyga-ubuntu: you asked me to look at something with overlayfs. what is it you want me to look at?
[14:29] <zyga-ubuntu> jdstrand: yes
[14:30] <zyga-ubuntu> jdstrand: that's exactly that branch and that is exactly what I'm running as well
[14:30] <jdstrand> note, this is not going to take only 15 minutes if you are asking me to verify that it is going to dtrt with apparmor
[14:30] <zyga-ubuntu> jdstrand: to ensure we're seeing the same thing
[14:31] <zyga-ubuntu> 2017/10/27 14:31:17.262504 main.go:154: 	cannot apply mount change mount (/snap/test-snapd-content-advanced-slot/x1/source /snap/test-snapd-content-advanced-plug/x1/target none bind 0 0): cannot open path segment "x1" (got up to "/snap/test-snapd-content-advanced-plug"): permission denied
[14:31] <zyga-ubuntu> jdstrand: this is the error I'm seeing
[14:31] <zyga-ubuntu> jdstrand: and there are no denials
[14:32] <jdstrand> istr something with overlayfs and private mounts
[14:33] <zyga-ubuntu> jdstrand: now in that same branch there's one more patch that lets this test pass
[14:33] <zyga-ubuntu> jdstrand: it makes snap-update-ns unconfined
[14:34] <zyga-ubuntu> jdstrand: note: when s-u-n is unconfined it can complete the work and then let regularly confined apps work
[14:34] <zyga-ubuntu> jdstrand: I'm trying to understand if the failure I'm seeing is a result of missing apparmor support for overlayfs
[14:34] <jdstrand> zyga-ubuntu: I'll try the spread test, but note, I'm not keen on spending a lot of time on overlayfs until niemeyer or mvo say that the change in direction is what we want in the PR. I laid out many questions about this and didn't get a response that pertains to them. morphis then followed up but no response
[14:34] <zyga-ubuntu> jdstrand: I suspect the answer is "yes"
[14:35] <zyga-ubuntu> jdstrand: gustavo strongly wants me to pursue this, I'll review your questions and ensure they are all answered
[14:35] <jdstrand> s/in the PR/in the forum/
[14:35] <zyga-ubuntu> jdstrand: ack
[14:36] <jdstrand> zyga-ubuntu: that is a complete 180 in terms of direction wrt overlayfs. it has always been "no, because it can't be backported"
[14:36] <jdstrand> tyhicks: fyi ^
[14:36] <jdstrand> ratliff: ^
[14:37] <jdstrand> zyga-ubuntu: you mentioned something about a fallback to !overlayfs. if that is supposed to work as well as (from the pov of the user) overlayfs, why not just focus on that instead? you can answer that in the forum (it was one of my questions)
[14:41] <kalikiana> fg
[14:41] <kalikiana> Oops
[14:42] <morphis> zyga-ubuntu: this means we will always have two different implementations inside snapd for the layouts feature?
[14:43] <kenvandine> seb128, the user-dirs.defaults directories, are the actual directory names translated?  Or just the presentation of them?
[14:43] <kenvandine> s/are the/are they
[14:43] <seb128> kenvandine, the actual dirs
[14:43] <kenvandine> bummer
[14:43] <kenvandine> ok
[14:43] <kenvandine> is there an easy way to get those names?  Or do i need to parse them out of user-dirs.defaults?
[14:44] <zyga-ubuntu> morphis: I don't know yet
[14:44]  * kenvandine thought there was an easy way
[14:44] <seb128> kenvandine, g_get_user_special_dir ()
[14:44] <kenvandine> yeah, but nothing available in a shell script
[14:45] <seb128> you can use the binding from python
[14:45] <kenvandine> i guess i can look at the g_get_user_special_dir implementation
[14:45] <kenvandine> ah
[14:46] <kenvandine> seb128, although i doubt starting a python interpretor in the desktop helpers would be a good idea speed wise
[14:46] <morphis> zyga-ubuntu: please let me know once you guys are closer to a decision on this as this will have quite some impact on system enablement etc.
[14:46] <seb128> kenvandine, $ python -c "from gi.repository import GLib; print(GLib.get_user_special_dir(GLib.USER_DIRECTORY_DOCUMENTS))"
[14:47] <zyga-ubuntu> morphis: right, I think this will happen one gustavo is back
[14:47] <tyhicks> zyga-ubuntu: I'm sure you are aware of this but there will be a considerable lead time before apparmor and overlayfs can be fully working together and the one or two people that can work on that are committed to other work
[14:47] <seb128> kenvandine, it wouldn't be the slowest thing in there...
[14:47] <zyga-ubuntu> morphis: in the meantime I'll work on options
[14:47] <seb128> kenvandine, but yeah, probably easier to just shell parse the .config
[14:47] <zyga-ubuntu> tyhicks: noted,
[14:48] <kenvandine> seb128, thx!
[14:48] <seb128> kenvandine, yw
[14:48] <morphis> zyga-ubuntu: aye
[14:48] <zyga-ubuntu> tyhicks: ultimately it is not my decision, I'll just collect facts and help make the descision clear
[14:49] <tyhicks> zyga-ubuntu: that makes sense - just be sure to point that out if you're in a conversation where the decision is being made
[14:49] <om26er> popey: for you: https://forum.snapcraft.io/t/please-allow-my-android-studio-snap/2634 :-)
[14:49] <zyga-ubuntu> tyhicks: you will be in the call I'm sure
[14:50] <tyhicks> sometimes it works out like that, sometimes not :)
[14:50] <tyhicks> (in all projects - not just snappy)
[15:11]  * zyga-ubuntu breaks for some follow-the-news time
[15:18] <jdstrand> kenvandine, seb128: in the past we have said that we won't support translatable directories in the filesystem (how they are presented to the user is entirely different of course). that hasn't changed, has it?
[15:24] <kyrofa> Huh. elopio what might be causing this? https://travis-ci.org/snapcore/snapcraft/jobs/292341577
[15:24] <kyrofa> Any chance it's from the "use the snap for integration tests" PR?
[15:32] <mup> Bug #1728076 opened: Initialize Device transaction incorrect "Done" status <Snappy:New> <https://launchpad.net/bugs/1728076>
[15:33] <kenvandine> jdstrand, i remember some discussions on that, but i don't recall the details
[15:33] <kenvandine> jdstrand, i've found an easy way to get those from xdg-user-dirs
[15:34] <kenvandine> in practice what it gives me might not be translated though
[15:37] <kenvandine> jdstrand, seb128: http://paste.ubuntu.com/25830955/
[15:37] <kenvandine> that seems to work
[15:37] <kenvandine> but i need to try that with a different LANG now
[15:38] <jdstrand> kenvandine: this came up a long time ago wrt click. basically, upstream and Ubuntu felt that translating those at the filesystem level was a mistake. ie, it should always be /home/foo/Documents, not /home/foo/SomeTranslatedThing
[15:39] <jdstrand> kenvandine: so we don't support translated dirs officially. as it happens, with the home interface and because all of $SNAP_USER_DATA is usable by the snap, this hasn't been an issue on snappy
[15:40] <jdstrand> kenvandine: that said, I don't think user-dirs.dirs is readable today
[15:41] <jdstrand> kenvandine: no it isn't. I'm getting lose to writing a PR that will make it readable
[15:41] <jdstrand> close*
[15:45] <seb128> jdstrand, who is "we"? translated directories are a xdg reality for 10 years...
[15:46] <ogra_> s/reality/annoyance/ :P
[15:46] <kyrofa> kalikiana, commented on snapcraft#1641
[15:46] <mup> PR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
[15:46] <seb128> ogra_, says a german speaker...
[15:47] <ogra_> who has to type "Arbeitsfläche" instead of Desktop on one machine ... i hate that
[15:47] <jdstrand> seb128: you were in the conversation. I remember discussing it in person with you and Allison. we all agreed it was a mistake even if they've been there for 10 years. and we agreed click wouldn't support them. I can pull up bugs to remind you if needed :P
[15:47] <kalikiana> kyrofa: Thanks!
[15:47] <seb128> jdstrand, you might be right, I vaguely remember discussing it but not in the snap context, maybe it was clicks
[15:47] <seb128> jdstrand, issue is that for snaps you have to deal with existing apps
[15:47] <jdstrand> seb128: no, it wasn't the snap context. only clicks
[15:47] <ogra_> (i dont mind Bilder vs Pictures and the like ... but translating the Desktop dir always puts me off)
[15:48] <jdstrand> seb128: I was saying with snaps we inherited non-support initially, but now with home and SNAP_USER_DATA, it mostly doesn't matter
[15:49] <jdstrand> only if we decide to carve up the home interface would it be an issue
[15:49] <kenvandine> seb128, i guess this is the first time i've run a snap using a different lang... so snaps aren't showing as translated?
[15:49] <ogra_> on the phone we could do the translation on the UI level because we had the content-hub and friends
[15:50]  * jdstrand notes that the gtk3 file chooser or nautilus or whatever could present anything they want (that was what we concluded unity8 might end up doing)
[15:50] <seb128> kenvandine, they do if built properly
[15:50] <ogra_> that is why it wasnt a problem there ... there was a way bigger separation
[15:50] <kenvandine> seb128, so i guess mine aren't :)
[15:50] <kenvandine> seb128, what's the magic?
[15:50] <seb128> kenvandine, do you use the --prefix build hack?
[15:50] <kyrofa> kalikiana, did you approve snapcraft#1644 ?
[15:50] <mup> PR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
[15:50] <kenvandine> seb128, yes
[15:51] <kyrofa> Rather, I know you didn't, but DO you approve
[15:51] <seb128> kenvandine, then translations should work...
[15:51] <jdstrand> ogra_: right
[15:51] <jdstrand> but again, it isn't actually a problem here
[15:51] <ogra_> yeah
[15:51] <jdstrand> cause we don't separate ~/Videos from ~/Documents
[15:52] <kenvandine> jdstrand, ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs is readable because it's under $SNAP_USER_DATA
[15:52] <kenvandine> and we run xdg-user-dirs-update after setting that
[15:52] <kenvandine> so it should do the right thing
[15:53] <jdstrand> if we did, and if translated xdg dirs are still a thing (and it sounds like they are; I guess upstream didn't pursue something better), then there would be work to do make them work in the policy (which is possible)
[15:53] <jdstrand> kenvandine: yeah, but, where are you getting that?
[15:54] <jdstrand> kenvandine: https://forum.snapcraft.io/t/xdg-user-dirs-and-dconf-apparmor-denials/2390/3
[15:54] <jdstrand> kenvandine: in addition to that, I also need to add ~/.config/user-dirs.conf
[15:54] <kenvandine> the desktop helper runs xdg-user-dirs-update after setting $XDG_CONFIG_HOME properly
[15:54] <jdstrand> kenvandine: in addition to that, I also need to add ~/.config/user-dirs.dirs?
[15:55] <kenvandine> jdstrand, that would be good
[15:55] <jdstrand> ok
[15:55] <jdstrand> I was talkingn about .conf
[15:55] <jdstrand> but we should also allow /etc/xdg/user-dirs.defaults
[15:55] <kenvandine> yeah
[15:56] <elopio> kyrofa: ugh, you broke it :( it worked less than a day.
[15:56] <kyrofa> elopio, hahahahaha
[15:56] <elopio> Let me check the logs to see if I can understand something there. But more likely I'll have to debug.
[15:56] <jdstrand> zyga-ubuntu: I gave spread the wrong args and it is running all the tests. I can't seem to kill it
[15:57] <zyga-solus> jdstrand: qemu or linode?
[15:57] <jdstrand> zyga-ubuntu: I bg'd it and tried -discard, but it held the lock
[15:57] <zyga-solus> jdstrand: if qemu just kill qemu process
[15:57] <jdstrand> zyga-ubuntu: linode
[15:57] <zyga-solus> jdstrand: ah
[15:57] <jdstrand> (hence the wrong argument
[15:57] <zyga-solus> jdstrand: kill spread and -discard then
[15:57] <kenvandine> seb128, confirmed gedit is using the prefix hack but not showing up as translated for me
[15:57] <zyga-solus> (run the same thing bug pass -discard)
[15:57] <kenvandine> seb128, can you please confirm?
[15:57] <jdstrand> ok, wasn't sure that would work
[15:58] <zyga-solus> yes, all you need is in that local .spread.* file
[15:58] <zyga-solus> it just kills the node from the lindoe API
[16:01] <sergiusens> kyrofa can you look at my comment on snapcraft#1641, the objective is to not print an error, not to capture and print the same error again
[16:01] <mup> PR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
[16:01] <jdstrand> zyga-solus: did you disable rate limiting? I think we are doing that by default now in spread, but worth asking
[16:01] <seb128> kenvandine, indeed, (gedit:8296): Gtk-WARNING **: Locale not supported by C library.
[16:01] <seb128> 	Using the fallback 'C' locale.
[16:01] <kyrofa> sergiusens, right, capturing it would cause it to _not_ be printed
[16:01] <zyga-solus> jdstrand: no, I didn't! that's a good think to check
[16:01] <kyrofa> sergiusens, and give us the ability to print it
[16:02] <kyrofa> sergiusens, rather than traceback, we can simply use the stderr
[16:02] <kalikiana> kyrofa: Yes. I was reluctant to give my v here since I changed the unit tests. But the fix is good to my mind
[16:03] <seb128> kenvandine, I had my ghex snap working with that wrapper http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/ghex.wrapper
[16:03] <jdstrand> zyga-solus: note that if it is a capability denial, apparmor itself might be rate limiting it (it actually rate limits quite a few things. see: https://bugs.launchpad.net/apparmor/+bug/1707743). capability is the only one that really seems to be a problem
[16:03] <mup> Bug #1707743: denied capability logged only after profile load <aa-kernel> <AppArmor:New> <https://launchpad.net/bugs/1707743>
[16:04] <jdstrand> zyga-solus: perhaps you could add a base capability rule and see if it passes? 'capability,'
[16:04] <jdstrand> s/base/bare/
[16:05] <seb128> kenvandine, the desktop launcher has https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L127 ... did you try to stage locales-all?
[16:05] <zyga-solus> jdstrand: trying
[16:06] <seb128> kenvandine, that might take space though, the hack in ghex was only needing libc-bin/locales iirc which is smaller
[16:08] <sergiusens> kyrofa kalikiana why is it not possible to NOT traceback and NOT print?
[16:08] <sergiusens> kyrofa on a cli, you will run something, it will be seen as a double error being printed
[16:09] <kyrofa> sergiusens, we're saying the same thing, perhaps we should jump on a HO?
[16:10] <ogra_> to say the same thing aloud ?
[16:11] <kyrofa> ogra_, in harmony
[16:11] <ogra_> yeah, thats what i imagined
[16:12] <jdstrand> zyga-solus: I see the same thing. no denial
[16:12] <kenvandine> seb128, i'll play around with it
[16:12] <kenvandine> seb128, thx
[16:13] <zyga-solus> capability didn't change it
[16:15] <kenvandine> seb128, i can probably add locales-all to the platform
[16:15] <jdstrand> zyga-solus: try removing this: deny capability fsetid,
[16:15] <zyga-solus> k
[16:15] <jdstrand> zyga-solus: or turn it into an allow by removing 'deny'
[16:16] <zyga-solus> jdstrand: running, though it is on the parent profile so probably not a factor
[16:16] <jdstrand> removing the rule would still have it deny of course
[16:16] <zyga-solus> sure
[16:16] <sergiusens> kyrofa I think you want to handle the printing the exception handler which requires all of what you mentioned is needed. I am just saying, from whatever calls lxc exec, raise a specific exception that will be caught and handled differently
[16:17] <jdstrand> zyga-solus: that should be unrelated anyway, but, like I said, there are some weird bugs
[16:17] <jdstrand> (with overlayfs and apparmor)
[16:17] <kyrofa> sergiusens, handled differently i.e. just exit non-zero and don't say anything extra?
[16:19] <kyrofa> I think we can do that just by raising a SnapcraftError(), but I'll check
[16:20] <kyrofa> We'll need a SnapcraftError with a __str__ that is empty
[16:21] <sergiusens> kyrofa yes, exactly; given that the run was owned by the instance of snapcraft run inside the container; if we go a different path this will be exceedingly complex to handle; that said, in a future PR we could just use the piping mechanism to create a .log of the build when using containers (should be straightforward)
[16:22] <kyrofa> sergiusens, yeah that seems to be the direction we're heading overall anyway
[16:22] <kyrofa> sergiusens, when it comes to the nested snapcraft I totally agree
[16:22] <kyrofa> sergiusens, but doing the same for the setup stuff isn't quite as clear. How do you feel about hiding that behind a progress bar?
[16:23] <zyga-solus> jdstrand: no change
[16:24] <kyrofa> It'll take two PRs to do that, this one using essentially a dumb exception, and another one splitting the setup tasks out
[16:25] <jdstrand> zyga-solus: I've dropped to the shell in spread. I should just be able to edit the profile and run stuff, right? I tried to run test-snapd-content-advanced-slot.sh' but things went terribly wrong
[16:25] <jdstrand> /bin/sh: 0: Bad substitution
[16:25] <jdstrand> repeated forever. I couldn't recover and had to kill the vm
[16:28] <zyga-solus> yes
[16:29] <zyga-solus> yes, that breaks, paste the same line you saw in the test and it will work
[16:29] <zyga-solus> so
[16:29] <zyga-ubuntu> test-snapd-content-advanced-plug.sh -c 'test -d $SNAP/target'
[16:29] <zyga-ubuntu> this will re-try
[16:29] <zyga-ubuntu>  /usr/lib/snapd/snap-discard-ns test-snapd-content-advanced-plug; test-snapd-content-advanced-plug.sh -c 'test -d $SNAP/target'; echo $?
[16:29] <zyga-ubuntu> this is even better
[16:30] <sergiusens> kyrofa what setup stuff?
[16:30] <jdstrand> zyga-solus: unfortunately I was winging it cause I did 'reset' :)
[16:30] <kyrofa> sergiusens, installing squashfuse, injecting snaps, the stuff that failed for popey that spawned that PR
[16:31] <sergiusens> kyrofa oh, that should be handled the way we usually handle exceptions in our code base
[16:31] <kyrofa> sergiusens, right, which is what kalikiana did. Problem is, the codepath is the same
[16:32] <kyrofa> sergiusens, so my suggestion is: if we're splitting them out, might as well put that stuff behind a progress bar
[16:33] <mup> PR snapd#4094 closed: tests: cherry pick the fix for services test into 2.29 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4094>
[16:33] <sergiusens> kyrofa code path the same being, the sequence of steps comes one after the other?
[16:34] <sergiusens> they just need to be handled differently then, a progressbar could do, but I would hold off on that until we have a better separation of cli/logic
[16:35] <kyrofa> sergiusens, no, they all go through `_container_run`, which is where the exception-handling logic has been added. They just need to be, yeah, treated differently
[16:35] <kyrofa> sergiusens, okay, I'll summarize on the PR
[16:36] <sergiusens> thanks
[16:36] <kalikiana> kyrofa: treat differently how? I'm a bit lost now
[16:36] <kyrofa> kalikiana, don't worry, I will try to make all things clear in my summary
[16:36] <kalikiana> Okay thanks
[16:37] <mup> PR snapd#4096 opened: spread: welcome bionic beaver <Created by mvo5> <https://github.com/snapcore/snapd/pull/4096>
[16:38] <kalikiana> btw wrapping up for today now - I'll be off most of next week (you can see it in the team view) but will be checking in here and there for comments etc
[16:45] <mvo> cachio: finally! 2.29~rc2 for i386,amd64 - arm is still pending, no idea what is going on with the arm autobuilders currently, super slow
[16:48] <ogra_> i guess you are fighting with doko ;)
[16:48] <ogra_> initial import of bionic etc
[16:57] <jdstrand> zyga-solus: I've spent way more than 15 minutes on this. unfortunately, my desktop crashed and I lost all state (/me shakes fist at wayland/mutter not being able to restart)
[16:58] <jdstrand> zyga-solus: I don't think there is enough information to definitively say it is apparmor. however, you could try different bare rules to see what is the issue
[16:58] <zyga-solus> jdstrand: thank you for the effort
[16:58] <zyga-solus> jdstrand: I think this is enough for now
[16:58] <jdstrand> zyga-solus: eg, add 'file,'
[16:58] <jdstrand> then mount,
[16:58] <jdstrand> then ptrace,
[16:58] <jdstrand> etc
[16:58] <zyga-solus> I'll try
[16:59] <jdstrand> maybe one of them will work and that will provide a clue
[16:59] <jdstrand> could be a logging bug
[16:59] <jdstrand> could be a poor interaction between attach_disconnected and overlayfs
[17:00] <jdstrand> it would not surprise me at all if attach_disconnected is mapping something to the wrong place
[17:00] <jdstrand> zyga-solus: ^
[17:00] <zyga-solus> aha
[17:01] <zyga-solus> I'll try all and we'll know more next time
[17:01] <zyga-solus> thank you for investigating this
[17:01] <jdstrand> remember, attach_disconnected is a hack. overlayfs would ideally be giving us the proper locations. attach_disconnected just says connect anything that is disconnected to '/'
[17:01] <jdstrand> zyga-solus: ^
[17:01] <jdstrand> ok, yw
[17:02] <zyga-solus> I see, I didn't know it's a hack
[17:03] <cachio> mvo, could you please upload the snap https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings
[17:03] <kyrofa> sergiusens, snapcraft#1636 is ready, but you put 2.36 on there. Does that mean you don't want it in just yet?
[17:03] <mup> PR snapcraft#1636: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
[17:04] <kyrofa> It's not approved yet either, to be clear
[17:05] <kyrofa> I'm also good with snapcraft#1593 if you want to take a look
[17:05] <mup> PR snapcraft#1593: catkin tools plugin: add catkin tools support <Created by cratliff> <https://github.com/snapcore/snapcraft/pull/1593>
[17:05] <cachio> mvo, I am running beta validation now
[17:08] <kyrofa> elopio, also, what do you think about the plainbox tests? Do you agree that we should remove the years?
[17:23] <om26er> why do classic snaps need manual approval ?
[17:24] <ogra_> because they have full system access
[17:24] <om26er> when does ogra_ actually go offline ?
[17:25] <ogra_> heh
[17:25] <om26er> anyways, I have a android-studio snap waiting manual review because its a classic snap. Hopefully that'll get figured out soon.
[17:30] <elopio> kyrofa: yes, I'll update my branch. Sorry the day.got complicated and I'm in a bus.
[17:30] <kyrofa> elopio, quite alright, I'm happy to update it if you like, I just wanted to make sure you agreed
[17:31] <elopio> kyrofa and your PR has the snap stage after.that integration test. That way it will never work. I'm not sure what's going on, I'll keep digging.
[17:31] <kyrofa> elopio, huh...
[17:31] <elopio> kyrofa yes please, go for it
[17:33] <sergiusens> kyrofa if you provide a list of all the systems you've checked then maybe yes; but I put 2.36 on most so the focus would stay on things for 2.35 and potentially the pip/python stuff (which is the only thing we could think about backing into 2.35)
[17:33] <kyrofa> sergiusens, alright I figured, just wanted to make sure we were on the same page
[17:33] <sergiusens> the "just one more thing" is what is causing all these release delays ;-)
[17:34] <kyrofa> Haha, amen
[17:35] <kyrofa> If you want to just lock down the release now that's fine too. Focus on autopkgtests
[17:35] <kyrofa> sergiusens, remember we can always make a release branch for stabilizing if we don't want to hold up landings
[17:36] <kenvandine> jdstrand, are you actively working on adding access to user-dirs related paths?
[17:36] <sergiusens> kyrofa I don't mind as we all have things to work on for 2.35; this is not a big team :-)
[17:36] <jdstrand> kenvandine: yes. I'm preparing a branch with various updates that includes that as we speak
[17:36] <sergiusens> I really want our small team to focus on 2.35
[17:36] <kenvandine> jdstrand, excellent
[17:37] <kyrofa> sergiusens, alright will do. I'll focus on autopkgtests
[17:42] <mvo> cachio: thanks! core build still tells me in 1h/2h for armhf/arm64 :(
[17:42] <mvo> cachio: I keep an eye one it
[17:43] <cachio> ok, np
[17:44] <cachio> mvo, ce you updaload the snap I'll create the PR
[17:54] <sergiusens> kyrofa feel free to make the ocd change in snapcraft#1644
[17:54] <mup> PR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
[17:54] <kyrofa> sergiusens, haha, okay
[18:21] <elopio> alright, back on my machine
[18:24] <stokachu> noise][: can you give cory johns @canonical.com access to charmtools snap?
[18:25] <elopio> kyrofa: I will start the hangout in a few minutes. Let me know if you want to join to test. Also sergiusens where in the world are you? You are welcome to join us, of course.
[18:26] <mup> PR snapd#4097 opened: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4097>
[18:26] <kyrofa> elopio, awesome
[18:26] <sergiusens> elopio I am finally home, since yesterday!
[18:26] <stokachu> noise][: sorry the snap is "charm"
[18:26] <stokachu> noise][: or maybe give ownership to the same group you did with conjure-up
[18:26] <zyga-ubuntu> mvo: hey, still there?
[18:27] <jdstrand> mvo: hey, I know its late, but there is the PR I was talking about. no need to review now, but I add the 2.29 milestone-- is that what you wanted me to do?
[18:27] <zyga-ubuntu> mvo: sorry for going AWOL, tracking unfolding events in spain now
[18:27] <stokachu> nessita: or if you're available to give access to charm for the canonical group (same group set for conjure-up)
[18:28] <stokachu> sergiusens: seen https://pastebin.ubuntu.com/25830958/ before?
[18:28] <nessita> stokachu, hey there. I can't add collaborators, you need mvo for that, sorry
[18:28] <stokachu> nessita: ok ty!
[18:29] <stokachu> mvo: if you got a minute from the spain madness :)
[18:30] <zyga-ubuntu> stokachu: mvo or me?
[18:30] <stokachu> zyga-ubuntu: can you give store access to people?
[18:30] <zyga-ubuntu> stokachu: I don't think I can
[18:31] <stokachu> ok
[18:33] <sergiusens> stokachu seems like request's raise_for_code did not get triggered and status was not returned in the json results. Mind logging a bug? Is this a one time thing?
[18:33] <sergiusens> Facu any idea about that scenario ^ in stokachu's pastebin?
[18:34] <stokachu> sergiusens: cory_fu is the one that hit this issue
[18:34] <jdstrand> kenvandine: fyi, https://github.com/snapcore/snapd/pull/4097
[18:34] <mup> PR #4097: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4097>
[18:34] <kyrofa> elopio, give me the link when you have it
[18:34] <elopio> one second
[18:35] <cory_fu> sergiusens: Pretty sure it's because I don't have access to the snap yet (there's an invite pending, but I never got the email nor can I find it via the Dashboard)
[18:35] <Facu> sergiusens, nop
[18:36] <Facu> cory_fu, but you can repeat it, right?
[18:36] <sergiusens> cory_fu ah, no snap access, that should return some sort of 5xx I believe, but let me try and release a snap I don't have listed here and see what happens; if you don't mind a bug might help this from falling into the cracks
[18:36] <cory_fu> sergiusens: Yep, filing one to LP now
[18:37] <cory_fu> Facu: Yes, I can reproduce it
[18:38] <cory_fu> https://bugs.launchpad.net/snapcraft/+bug/1728121
[18:38] <mup> Bug #1728121: Traceback from snapcraft release <Snapcraft:New> <https://launchpad.net/bugs/1728121>
[18:41] <elopio> kyrofa, sergiusens and anybody else who would like to join the ubuntu hour: https://hangouts.google.com/hangouts/_/jdpkqoaaz5fw7f6b2jlmhy5auie
[18:41] <mup> PR snapd#4098 opened: snap-confine: allow reading uevents from any where in /sys <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4098>
[18:41] <jdstrand> mvo: same question for ^
[18:42] <Facu> cory_fu, sergiusens, will track this server side, thanks
[18:44] <kenvandine> jdstrand, cool, i'll watch that
[18:44] <kenvandine> jdstrand, also i have a WIP branch for the helpers https://github.com/kenvandine/snapcraft-desktop-helpers/commit/9be256f76362a4f109890e033d9fc5467144f715
[18:45] <sergiusens> Facu stokachu cory_fu I can totally reproduce this https://pastebin.ubuntu.com/25831852/
[18:46] <jdstrand> kenvandine: come to think of it, `id -u` will be more robust than $UID. istr not always having $UID
[18:46] <Facu> sergiusens, also trying to release something you don't have permissions?
[18:46] <jdstrand> kenvandine: and cool! :)
[18:46] <sergiusens> I will look at the responses a bit closer (we could add one more call before release to get the account info and verify you can release to that snap if it comes to it).
[18:46] <sergiusens> Facu yes, I have no access to conjure-up :-)
[18:47] <Facu> sergiusens, I would have thought that the server is not 200ing in this case, will check
[18:48] <sergiusens> Facu ah, it is the exception that is at fault
[18:48] <sergiusens> we have if not response.ok and pass the response to our own exception implementation
[18:49] <sergiusens> Facu I'll take it from here :-)
[18:50] <Facu> sergiusens, so, server is returning that you can not access it, right?
[19:05] <sergiusens> Facu at least returning something saying it is not ok
[19:21] <mvo> jdstrand: what was the question?
[19:21] <mvo> jdstrand: I think thats reasonable
[19:22] <jdstrand> mvo: you said to 'tag' the PR with 2.29. I don't see 'tag's in the github interface, so I milestoned it
[19:22] <jdstrand> mvo: I just wanted to make sure I was doing what you asked :)
[19:22] <mvo> jdstrand: yeah, sorry, milestoned is the right thing
[19:22] <jdstrand> ok, cool
[19:22] <mvo> jdstrand: thanks! this is fine for 2.29
[19:22] <jdstrand> thank you :)
[19:23] <jdstrand> mvo: note it is 4097 and 4098 (both only add access so not risky)
[19:26] <mvo> jdstrand: aha, thank you
[19:29] <mvo> cachio: armhf/arm64 is now ready as well
[19:30] <cachio> mvo, great
[19:30] <cachio> I'll run that now
[19:30] <mvo> cachio: thanks a lot!
[19:30] <mvo> cachio: keep me updated please :)
[19:31] <cachio> mvo, so far everything passed
[19:33] <cachio> mvo, l run the devices now
[19:56] <mup> PR snapd#4054 closed: snap-{confine,seccomp}: make @unrestricted fully unrestricted <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4054>
[20:00] <mup> PR snapd#4099 opened: merge 2.29~rc2 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4099>
[20:19] <om26er> does the dump plugin support dynamic `source` parameter ?
[20:19] <om26er> maybe a script that resolves to a url ?
[20:27] <kyrofa> om26er, no, can you explain your use-case?
[20:28] <om26er> kyrofa: There is no direct link for the source zip that I want to download from. The url is resolved after a script is executed.
[20:29] <kyrofa> om26er, can you execute it locally and then copy/paste that URL?
[20:29] <om26er> I am setting version using version-script but was looking for a way to set the `source` as well.
[20:29] <kyrofa> om26er, you always do it in a local plugin
[20:29] <kyrofa> om26er, inherit from the dump plugin but make the source dynamic
[20:30] <kyrofa> you CAN always, rather
[20:30] <om26er> kyrofa: that could work but I was thinking to full automate it. i.e. whenever I know there is a new release available, just do a dummy commit to my snap package and push so that auto build kick in
[20:31] <kyrofa> om26er, yeah this doesn't preclude that
[20:31] <kyrofa> I do the same thing for daily builds, although in my case the URL is just a symlink
[20:31] <kyrofa> I just change the version and push
[20:32] <om26er> kyrofa: can you share examples of a local plugin ?
[20:33] <kyrofa> om26er, sure thing, one sec
[20:33] <kyrofa> om26er, here's an example: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-php.py
[20:34] <kyrofa> You just need to put them in snap/plugins and snapcraft will find them
[20:35] <kyrofa> (like they are there)
[20:35] <om26er> kyrofa: so when I refer them in my yaml I prepend `x-` ?
[20:35] <kyrofa> om26er, no actually-- refer to the YAML in that same project
[20:36] <om26er> kyrofa: you got an example to override dump plugin somewhere ?
[20:37] <kyrofa> The naming pattern is confusing, so just trust me: name your plugin x-<plugin name>.py and then refer to it in the YAML as <plugin name>
[20:37] <kyrofa> om26er, I don't, but simply import snapcraft.plugins.dump and inherit from snapcraft.plugins.dump.DumpPlugin
[20:38] <kyrofa> om26er, then overwrite the `pull` method, but not the `build`
[20:41] <om26er> looking into this.
[20:48] <mup> PR snapcraft#1546 closed: cli: update parts cache in the container <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1546>
[21:29] <sergiusens> elopio what is that close/open attempt all about on snapcraft#1607 ?
[21:29] <mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
[21:31] <elopio> sergiusens: kyle broke the order of the stages. I turned it on and off again to fix it.
[21:34] <kyrofa> elopio, wait... what?
[21:34] <kyrofa> How did that fix things? :P
[21:35] <elopio> (shrug)
[21:37] <mup> PR snapd#4100 opened: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>
[21:38] <elopio> kyrofa I saw only yours was failing that way, and restarting didn't help
[21:39] <elopio> I was just touching buttons. It might be necessary to do this for the ones that have been open before the change.
[21:43] <elopio> I'm going to propose the transfer nicety now.
[22:08] <kyrofa> elopio, quick plug for the `transfer` snap
[22:12] <sergiusens> kyrofa why transfer when you can wormhole it ;-)
[22:12] <kyrofa> sergiusens, one to many versus one to one
[22:12] <kyrofa> sergiusens, elopio is talking about making the snapcraft snap available for each PR by uploading it to transfer.sh
[22:17] <sergiusens> kyrofa ah, it would be much nicer to have a webhook sent to some infra we control that would end up pushing and releasing to a branch :-)
[22:17] <sergiusens> but one step at a time
[22:17] <elopio> Quick cheat until build.snapcraft.io makes it nicer for us
[22:17] <sergiusens> kyrofa is transfer.sh the one from mozilla?
[22:18] <elopio> sergiusens: the bot can't release to a branch yet
[22:18] <sergiusens> ah, no, it was send (the one from mozilla)
[22:18] <sergiusens> elopio btw, how is the bot protected?
[22:19] <elopio> sergiusens ssh-only on Google cloud.
[22:20] <elopio> ACLs for the commands, but the commands can't expose the password.