[02:25] <mup> PR snapd#4371 opened: tests: add support on tests for cm3 gadget <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4371>
[06:02] <mborzecki> morning
[06:38] <mborzecki> zyga-ubuntu: hey
[06:41] <zyga-ubuntu> mborzecki: good mornin
[06:41] <zyga-ubuntu> :)
[06:41] <zyga-ubuntu> mborzecki: my last day this year
[06:41] <mborzecki> taking the rest of the year off?
[06:44] <zyga-ubuntu> yes
[06:44] <zyga-ubuntu> though I need to check again, but that's the plan
[06:45] <mborzecki> that's so nice, wish i had that many days of vacation left :)
[06:46] <zyga-ubuntu> haha, I wish I hadn't
[06:46] <zyga-ubuntu> the weather was better in the summer
[06:56] <zyga-ubuntu> mborzecki: and I have three carry-over days
[06:58] <zyga-ubuntu> mvo is not around yet
[06:58] <zyga-ubuntu> yesterday I took a detour to play with base-18
[06:58] <zyga-ubuntu> it was really fun, especially now that we can test boot it
[07:02] <mborzecki> that'll be based on 18.04?
[07:10] <zyga-ubuntu> yep
[07:10] <zyga-ubuntu> try it
[07:10] <zyga-ubuntu> it should work for you :)
[07:16] <mborzecki> zyga-ubuntu: do you have any prs in need of review that you'd like to close before you go?
[07:18] <zyga-ubuntu> mborzecki: yes, the two that are open
[07:18] <mborzecki> #4315 #4329?
[07:18] <mup> PR #4315:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
[07:18] <mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
[07:24] <zyga-ubuntu> yes
[07:29] <mup> PR snapd#4361 closed: devicestate: fix misbehaving test when using systemd-resolved <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4361>
[07:31] <mup> PR snapd#4360 closed: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 for 2.30 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4360>
[07:38] <zyga-ubuntu> hmm
[07:38] <zyga-ubuntu> the github merge conflict resolution tool is weird
[07:38] <zyga-ubuntu> it always has to run twice
[07:38] <zyga-ubuntu> WT?
[07:38] <zyga-ubuntu> look at 4343
[07:38] <zyga-ubuntu> last two commits
[07:38] <zyga-ubuntu> one is empty, one is the real merge
[07:40] <mborzecki> zyga-ubuntu: posted some comments to 4329
[07:42] <zyga-ubuntu> thanks, replied; I'll add the enum
[07:43] <mborzecki> ok, thanks
[07:43] <mborzecki> zyga-ubuntu: btw. what did you mean here: https://github.com/snapcore/snapd/pull/4354#discussion_r155448107 ?
[07:43] <mup> PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
[07:45] <kalikiana> morning o/
[07:45] <zyga-ubuntu> o/
[08:25] <zyga-ubuntu> pstolowski: hey
[08:25] <zyga-ubuntu> pstolowski: some small conflicts on your PRs
[08:25] <zyga-ubuntu> pstolowski: good morning :)
[08:26] <pstolowski> zyga-ubuntu, morning! ok, looking
[09:12] <zyga-ubuntu> drat my seageate disks
[09:12] <zyga-ubuntu> I will never buy from that vendor again
[09:23] <kalikiana> zyga-ubuntu: did they break for good?
[09:23] <zyga-ubuntu> no, just definitely started to fail
[09:40] <mup> PR snapd#4343 closed: interfaces: rename sanitize methods <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4343>
[10:15] <mup> PR snapcraft#1797 closed: tests: update the snap name already registered for store tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1797>
[10:18] <mup> PR snapcraft#1757 closed: Saving snap-build assertion as '.build' <Created by cprov> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1757>
[10:21] <zyga-ubuntu> a little bit more
[10:22] <zyga-ubuntu> and I should have spread support for base 18
[10:28] <zyga-ubuntu> man, iteration is painful
[10:28] <zyga-ubuntu> snapcraft clean, snapcraft takes a good chunk of time
[10:40] <zyga-ubuntu> whee, another boot attempt
[10:46] <ogra_> ogra@pi3:~$ snap set core service.rsyslog.disable=false
[10:46] <ogra_> error: cannot perform the following tasks:
[10:46] <ogra_> - Run configure hook of "core" snap (run hook "configure": [--root / enable rsyslog.service] failed with exit status 1: Synchronizing state of rsyslog.service with SysV init with /lib/systemd/systemd-sysv-install...
[10:46] <ogra_> Executing /lib/systemd/systemd-sysv-install enable rsyslog
[10:46] <ogra_> insserv: warning: current start runlevel(s) (empty) of script `rsyslog' overrides LSB defaults (2 3 4 5).
[10:46] <ogra_> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' overrides LSB defaults (0 1 6).
[10:46] <ogra_> Failed to execute operation: Unit file is masked
[10:46] <ogra_> )
[10:46] <ogra_> hmm
[10:48] <ogra_> (this is on edge, latest core)
[10:48] <ogra_> i guess mvo's new config handling broke ..
[10:49] <ogra_> (looks like it tries to call "enable" before "unmask")
[11:04] <pedronis> ogra_: look at the code it doesn't seem like that,  Unmask is called before Enable
[11:04] <pedronis> *looking
[11:05] <ogra_> pedronis, yeah, i had a week old hanging core iwith a Doing task
[11:05] <ogra_> aborting and manually refreshing fixed it
[11:06] <ogra_> (see bug 1736922 (already closed again))
[11:06] <mup> Bug #1736922: new config handling breaks re-enabling of rsyslog <snapd:Invalid> <https://launchpad.net/bugs/1736922>
[11:12]  * kalikiana considers fixedly-postmenopausal-tamesha as a runner up for most ridiculous pet name of the week
[11:18] <zyga-ubuntu> hmmm
[11:18] <zyga-ubuntu> so why are services not starting
[11:18] <zyga-ubuntu> I systemctl enable stuff
[11:18] <zyga-ubuntu> and yet it's not up
[11:22] <zyga-ubuntu> brr
[11:22] <zyga-ubuntu> need warm tea
[11:25] <mborzeck1> it's 5C outside, that's warmer than on Monday :)
[11:28] <mup> PR snapd#4314 closed: interfaces: use ConnectedPlug/ConnectedSlot types (step 2) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4314>
[11:29] <zyga-ubuntu> mborzecki: mwhudson recently complained about how warm it is in new zaeland
[11:29] <zyga-ubuntu> *ea
[11:31] <pstolowski> yay, all interface hooks prerequisites landed :)
[11:44] <zyga-ubuntu> sigh
[11:44] <zyga-ubuntu> little by little
[11:44] <mup> PR snapd#4366 closed: interfaces/removable-media: also allow 'k' (lock) <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4366>
[11:44] <mup> PR snapd#4367 closed: interfaces/removable-media: also allow 'k' (lock) for 2.30 <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4367>
[11:44] <zyga-ubuntu> does anyone have any idea why a certain unit is not started?
[11:44] <zyga-ubuntu> when systemd says "vendor preset: enabled"
[11:46] <ogra_> nothing in syslog ?
[11:46] <zyga-ubuntu> well
[11:46] <zyga-ubuntu> not sure what to look for
[11:46] <zyga-ubuntu> this is very barren still
[11:46] <ogra_> typically stdout from units goes there
[11:46] <zyga-ubuntu> I have a minimal 18 base
[11:47] <zyga-ubuntu> ogra_: I doubt it is started
[11:47] <zyga-ubuntu> it works when started manually
[11:51] <zyga-ubuntu> I'll read it the hard way
[11:52] <cachio> zyga-ubuntu, hey, I'll be 5 minutes late today
[11:52] <zyga-ubuntu> cachio: that's ok
[11:52] <zyga-ubuntu> cachio: we're still starting in one hour
[11:52] <zyga-ubuntu> right?
[11:52] <mup> PR snapd#4372 opened: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4372>
[11:52] <mborzecki> trivial PR ^^
[11:53] <zyga-ubuntu> done
[11:53] <cachio> zyga-ubuntu, yea
[11:56] <mborzecki> cachio: did you manage to figure something out with the rpi test that was failing?
[12:03] <zyga-ubuntu> aha
[12:03] <zyga-ubuntu> so it seems (maybe) that it is snapcraft
[12:13] <zyga-ubuntu> gah
[12:13] <zyga-ubuntu> no,
[12:13] <zyga-ubuntu> WTF
[12:15] <zyga-ubuntu> so, /etc/systemd/system is empty after booting
[12:16] <zyga-ubuntu> but it's not empty in the core snap
[12:16] <zyga-ubuntu> WTF
[12:16] <zyga-ubuntu> ah
[12:17] <zyga-ubuntu> all is clear now
[12:17] <zyga-ubuntu> thats system-data
[12:17] <zyga-ubuntu> sooooo
[12:18] <ogra_> /etc/systemd/system should be handled via writaable-paths
[12:21] <ogra_> (in synced mode FWIW)
[12:30] <bloodearnest> Hey folks. snap set core proxy.https=https://my.proxy:3128 does seem to have any affect, on 2.29 or 2.30, on classic. Is this a Known Issue?
[12:34] <bloodearnest> gah s/affect/effect
[12:41] <pedronis> bloodearnest: yes,   except proxy.store all the other core config are core only,  now that handling has been moved we need to decide which one make sense/are sane on classic too
[12:41] <bloodearnest> ok
[12:42] <pedronis> bloodearnest: it's not a regression, always been like this so far
[12:42] <bloodearnest> thx
[12:43] <bloodearnest> pedronis: ok. Related question, assuming some future where proxy.https can be set on classic, is there a way for another snap to access core config, via snapctl inside the snap, or similar?
[12:45] <ogra_> bloodearnest, snapd's systemd unit sources /etc/environment ... if you have your proxy settings in there and restart snapd it should just pick that up
[12:45] <ogra_> (that indeed assumes a system wide proxy)
[12:46] <pedronis> bloodearnest: not at the moment,  a snap would need snapd-control  and go through the REST api directly or use snap (I don't remember if we make available there)
[12:47] <ogra_> pedronis, i suspect even then you would miss access to core-support (which the config hook uses) ... or would that be just internally used when calling set/get ?
[12:47] <pedronis> ?
[12:48] <pedronis> you can do snap get core
[12:48] <pedronis> or the equivalent with the REST api
[12:48] <pedronis> not sure how core-support (which is not needed anymore) relates
[12:48] <ogra_> ah, wh is it not needed anymore ?
[12:48] <ogra_> *why
[12:49] <pedronis> because the hook is going away
[12:49] <ogra_> oh, indeed, silly me
[12:49] <pedronis> as far as I know we have core-support just for the configure hook inside core
[12:49] <ogra_> it is snapd itself now
[12:49] <ogra_> right
[12:49] <ogra_> for allowing the shelling out to particular system binaries
[12:50] <ogra_> but indeed ... not needed when snapd manages it ... thanks !
[12:50] <pedronis> yea, that's why I said not sure, but if you have snapd-control you can use the REST api
[12:50] <pedronis> but there's no other way to peek at other snap configs atm
[12:50] <pedronis> nor any special exception around core config
[12:53] <pedronis> bloodearnest: there is some idea that snapctl should give access to some safe system information (not specifically config keys) but nothing has happened yet of that
[13:05] <zyga-ubuntu> cachio: standup
[13:05] <zyga-ubuntu> pstolowski: standup
[13:11]  * ogra_ wonders when this "snap list" on his non-networked kvm will return ... it is sitting there since several minutes now 
[13:11] <ogra_> dont we have a timeout ?
[13:12] <popey> ogra_: i saw that recently on a machine which had selinux blocking. it didnt timeout, ever
[13:12] <popey> just sits there, and journalctl shows selinux blocking errors
[13:12] <ogra_> well, its a kvm core image nad my host has somehow messed up the forwarding ...
[13:13] <ogra_> so the kvm machine thinks it has network but i cant ping anything outside
[13:13] <ogra_> it still sits there btw ...
[13:13] <popey> worth a look in the journal/syslog anyway
[13:13] <ogra_> seems to never time out
[13:14] <mup> PR snapd#4371 closed: tests: add support on tests for cm3 gadget <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4371>
[13:15] <ogra_> wow
[13:15] <ogra_> http://paste.ubuntu.com/26132566/
[13:15] <ogra_> so snapd crashes (it then restarts though and seems to run proper)
[13:15] <ogra_> oh, it finally returned the list ... only took really long
[13:15] <popey> :)
[13:16] <ogra_> over 10 min
[13:17] <ogra_> but that above was only on boot ... the actual "snap list" call doesnt produce any log output
[13:18] <ogra_> sadly even snap changes hangs
[13:19] <ogra_> hmpf
[13:26] <sergiusens> ann: if anyone pinged me in the past 2 hours I lost it
[13:33] <zyga-ubuntu> mvo: some more progress, spread now starts the vm but fails to log in because /home is synced and that kills my test-only /home/ubuntu directory; I removed most of writable paths (including home), let's see what this looks like
[13:34] <ogra_> zyga-ubuntu, dnot forget writable-paths has individual settings (two way, three way merge or completely persistent) the single dirs behave differently usually
[13:34] <zyga-ubuntu> ogra_: right, I have a custom conifg
[13:34] <zyga-ubuntu> *config
[13:35] <zyga-ubuntu> this is just a temporary step
[13:35] <zyga-ubuntu> towards something I can spread test and test boot rapidly
[13:35] <zyga-ubuntu> and in the end get a working environment for interation
[13:35] <zyga-ubuntu> I think we want to remove writable-paths entirely
[13:35] <ogra_> yeah, i get that
[13:35] <zyga-ubuntu> (eventually)
[13:35] <ogra_> just pointing out a synced dir thats now not synced might break the world :)
[13:36] <zyga-ubuntu> yep, that's all "fine" - we're far away from base-18 working
[13:36] <ogra_> heh
[13:36] <ogra_> what about doing base-16 first ?
[13:36] <zyga-ubuntu> I need to move the initramfs help
[13:36] <zyga-ubuntu> ogra_: I think that's less interesting as that can stay as a copy of current core forever
[13:36] <ogra_> since you will need the split for upgrades
[13:37] <ogra_> well, using the base-16 and then shrinking it would be my way forward
[13:37] <ogra_> (towards -18)
[13:37] <zyga-ubuntu> not sure
[13:37] <zyga-ubuntu> I think there are lots of challenges in 18 that need to be tackled
[13:37] <zyga-ubuntu> and this is also involving migration
[13:37] <zyga-ubuntu> I want to just do 18 as a clean slate first
[13:39] <bloodearnest> pedronis: zyga: ok, thanks for the info
[13:39] <ogra_> sigh ... this snapd in kvm really misbehaves
[13:39] <ogra_> error: cannot communicate with server: Post http://localhost/v2/snaps/firstboot-setup: EOF
[13:39] <ogra_> for a snap remove ...
[13:40] <zyga-ubuntu> snapd crashed?
[13:40] <ogra_> it is running ... the network forwarding outside the VM is broken ...
[13:41] <ogra_> so it thinks it is online but i cant ping the outside world (i can ping my lkvm gateway though)
[13:41] <ogra_> that makes snapd really misbehave
[13:41] <zyga-ubuntu> ping is broken in user networking
[13:41] <zyga-ubuntu> just don't ping
[13:41] <ogra_> $ ps ax|grep snapd
[13:41] <ogra_>   965 ?        Ssl    0:00 /usr/lib/snapd/snapd
[13:42] <ogra_> $ snap remove firstboot-setup
[13:42] <ogra_> error: cannot communicate with server: Post http://localhost/v2/snaps/firstboot-setup: EOF
[13:42] <ogra_> thats what i get
[13:42] <ogra_> oh ? ping is broken ? since where
[13:42] <zyga-ubuntu> any snapd logs?
[13:42] <zyga-ubuntu> ogra_: since forever in user networking, check that if you want to know why
[13:42] <zyga-ubuntu> ogra_: but that's irrelevant for snapd
[13:43] <ogra_>  2017/12/07 13:40:14.783948 daemon.go:306: started snapd/2.30~rc1+git467.c2f9631~ubuntu16.04.1 (series 16) ubuntu-core/16 (amd64) linux/4.4.0-102-generic.
[13:43] <sergiusens> zyga-ubuntu what version of go are you using for snapd?
[13:43] <ogra_> looks like it started just fine (thats the last line in the journal)
[13:43] <zyga-ubuntu> sergiusens: 1.6
[13:44] <zyga-ubuntu> sergiusens: on core
[13:44] <sergiusens> across the board?
[13:44] <zyga-ubuntu> sergiusens: and reexec
[13:44] <zyga-ubuntu> sergiusens: whatever-is-there on various distros
[13:44] <sergiusens> ah, the client on whatever the distro is I guess
[13:44] <zyga-ubuntu> sergiusens: kind of, the client on your distro execs the reexec 1.6 binary most of the time
[13:48] <cachio> ogra_, hey
[13:48] <ogra_> hey cachio
[13:48] <cachio> ogra_, I was discussing with plars about if we could have ubuntu core images bot beta
[13:49] <ogra_> cachio, sure. why not
[13:49] <cachio> ogra_, it could be manually/automatically triggered when a new core snap is in beta
[13:50] <cachio> ogra_, so then we can use those images in testflinger
[13:50] <ogra_> cachio, you would need to talk to foundations to get a beta build at http://cdimage.ubuntu.com/ubuntu-core/16/
[13:50] <ogra_> sil2100 does them i think
[13:50] <cachio> ogra_, good
[13:50] <ogra_> (unless you will roll them yourself indeed)
[13:50] <ogra_> (its always just an ubuntu-image call away anyway ;) )
[13:51] <cachio> ogra_, where is the code that we use to create the stable / edge images?
[13:51] <ogra_> cachio, also a question for foundations ... i only do the images at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ for which the build scripts are local
[13:52] <ogra_> (local meaning on my PC)
[13:52] <cachio> ogra_, ah, ok
[13:52] <zyga-ubuntu> ha
[13:52] <zyga-ubuntu> I now know a little bit more about how spread starts up
[13:52] <cachio> ogra_, great, I'll talk to sil2100 in that case
[13:52] <ogra_> yeah
[13:52] <cachio> ogra_, tx
[13:52] <ogra_> or slangasek ... either of them should be able to point you to the official scripts
[13:54]  * kalikiana off for lunch in 10min
[13:54]  * kalikiana getting hungry
[13:56] <mvo> zyga-ubuntu: sorry, in a meeting, nice progress. looking at your open PRs now
[13:56] <zyga-ubuntu> mvo: ok, just need to add sudo right
[13:56] <zyga-ubuntu> mvo: I'll open a 2nd pr for spread
[13:57] <zyga-ubuntu> (for this project, spread is ok)
[13:58] <mborzecki> mvo: if that's ok with you, i'd like to rebase #4357 on top of #4372 and skip all 'validation' pathes in this PR
[13:58] <mup> PR #4357: wrappers: autogenerate After/Before in systemd's service files for apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4357>
[13:58] <mup> PR #4372: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4372>
[14:11] <zyga-ubuntu> mvo: it works now :)
[14:11] <zyga-ubuntu> mvo: shall I expand the existing PR
[14:11] <zyga-ubuntu> mvo: or do you want to see a 2nd one
[14:12] <mup> PR snapd#4340 closed: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4340>
[14:12] <mup> PR snapd#4373 opened: snap: app startup after/before validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4373>
[14:13] <mvo> mborzecki: +1
[14:13] <mvo> zyga-ubuntu: either way is fine
[14:13] <mvo> zyga-ubuntu: whatever is easier for you
[14:13] <zyga-ubuntu> k
[14:17] <mup> PR core#66 closed: 500-create-xdg.binary: use "set -o pipefail"  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/66>
[14:18] <mborzecki> mvo: the PRs are split now, would appreciate another review :)
[14:20] <zyga-ubuntu> mvo: done
[14:20] <zyga-ubuntu> mvo: please try it :)
[14:20] <zyga-ubuntu> mvo: same PR
[14:20] <zyga-ubuntu> mvo: just look at my master
[14:20] <zyga-ubuntu> mvo: commit history (especially last one) has usage instructions
[14:21] <zyga-ubuntu> mvo: I'll polish this now, slightly, enough to start fixing the issues we see (and add tests)
[14:21] <mvo> mborzecki: great, will look
[14:21] <mvo> zyga-ubuntu: same here
[14:21] <mborzecki> mvo: thanks
[14:21] <mvo> zyga-ubuntu: \o/
[14:22] <mborzecki> i'm off to pick up the kids, afk for now
[14:26] <greyback> jdstrand: hey, I've pushed my WIP to https://github.com/snapcore/snapd/pull/4365/files, can I ask you a couple of things? (1) Am I going too far, enabling proper Wayland compositors, which allows hardware access like Mir has? (2) I've duplicated much of what Mir slot has. is that kosher, or would a shared subclass interface be do-able?
[14:26] <mup> PR #4365: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
[14:26] <greyback> zyga-ubuntu: ^^ your opinion also welcome
[14:27] <zyga-ubuntu> greyback: ack
[14:43] <zyga-ubuntu> mvo: ok, I think base-18#8 is ready for review
[14:43] <zyga-ubuntu> mvo: once it lands we can really iterate and propose tests
[14:43] <mvo> zyga-ubuntu: \o/
[14:45] <zyga-ubuntu> mvo: I'll try to enable travis now
[14:45] <zyga-ubuntu> actually
[14:45] <zyga-ubuntu> hmmm
[14:45] <zyga-ubuntu> I think this will be harder than I anticipated
[14:45] <zyga-ubuntu> unless travis can just run things on top of xenial (maybe)
[14:45] <ogra_> why wouldnt it ?
[14:46] <ogra_> all y teste run on top of a xenail chroot in travis
[14:46] <ogra_> *all my tests
[14:46] <zyga-ubuntu> I need qemu
[14:46] <zyga-ubuntu> and spread
[14:47] <zyga-ubuntu> and kpartx and other maic
[14:47] <ogra_> ouch
[14:47] <zyga-ubuntu> may be too much
[14:47] <ogra_> yeah
[14:47] <zyga-ubuntu> well, let me grab a coffee and try
[14:47] <zyga-ubuntu> or maybe
[14:47] <zyga-ubuntu> break for lunch and then come back fresh
[14:47] <zyga-ubuntu> ogra_: btw, feedback on base-18 appreciated
[14:47] <ogra_> zyga-ubuntu, where do you hide it ?
[14:48] <zyga-ubuntu> ogra_: snapcore/base-18
[14:48] <zyga-ubuntu> ogra_: see PR #8
[14:48] <ogra_> i wonder why i didnt get PR mail for that
[14:52] <zyga-ubuntu> ogra_: it's brand new
[14:53] <ogra_> zyga-ubuntu, you dont install ubuntu-core-config ?
[14:53] <ogra_> hwo do you get writable-paths right then ?
[14:53] <zyga-ubuntu> ogra_: I don't even know what is there
[14:53] <zyga-ubuntu> ogra_: note that for testing I steal core-16 intird
[14:54] <ogra_> well, it only does a debootstrap minbase and one hook installs systemd and nssswitch
[14:54] <ogra_> zyga-ubuntu, right, that will be broken since it wont fint /etc/system-image/writable-paths in the target rootfs
[14:54] <ogra_> the initrd needs that
[14:54] <zyga-ubuntu> I think this is a _very_ early core :)
[14:54] <ogra_> interesting that you get it to boot at all
[14:55] <ogra_> zyga-ubuntu, well, it should badly error before mounting the rootfs when it doesnt find the writable-paths file ... if it doesnt you found actually a bug in the initrd :)
[14:55] <zyga-ubuntu> ogra_: ogra_ I add one
[14:55] <zyga-ubuntu> ogra_: I added that file
[14:56] <zyga-ubuntu> ogra_: anyway, this is really held-with-strings for now
[14:56] <ogra_> yeah, understood
[14:56] <zyga-ubuntu> ogra_: I plan to integrate inird code here so that base-18 is separate from base-16
[14:56] <zyga-ubuntu> ogra_: and then let us iterate with confidence (tests)
[14:56] <ogra_> i dont see where you add the file though
[14:56] <zyga-ubuntu> ogra_: hooks
[14:56] <zyga-ubuntu> ogra_: btw, this also includes a small, hand coded ubuntu-image
[14:57] <mup> PR snapd#4308 closed: packaging/arch: install snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4308>
[14:57] <zyga-ubuntu> ogra_: again, all optimized for getting started and getting results quickly
[14:57] <zyga-ubuntu> ogra_: I expect everything to change
[14:57] <ogra_> zyga-ubuntu, oh, i was looking ast the tree, not the last PR
[14:58] <zyga-ubuntu> ahh
[14:59] <ogra_> wow
[14:59] <kalikiana> re
[14:59] <zyga-ubuntu> what?
[14:59]  * ogra_ shades his eyes from "create-image" 
[15:00] <kalikiana> is it shiny?
[15:00] <ogra_> well ...
[15:00] <ogra_> :)
[15:00] <zyga-ubuntu> ogra_: I'd say it's simple
[15:00] <zyga-ubuntu> ogra_: simplest one yet :)
[15:01] <zyga-ubuntu> mvo: updated the comment
[15:01] <zyga-ubuntu> mvo: shall I remove the dist-upgrade too?
[15:01] <zyga-ubuntu> mvo: and note that you have to merge it as I don't have permissions
[15:02] <zyga-ubuntu> mvo: does it work for you :) ?
[15:02] <zyga-ubuntu> (that's most interesting)
[15:05] <mvo> a review for 4372 would be great, should be an easy win :)
[15:06] <zyga-ubuntu> darn, I already did
[15:06] <mvo> zyga-ubuntu: so far I just reviewed :) thanks, I will try it in a little bit, but I also promised maj some reviews (what is the short form of his name)?
[15:06] <mvo> zyga-ubuntu: oh, sorry
[15:06] <mvo> zyga-ubuntu: you did indeed, silly me
[15:07] <zyga-ubuntu> mvo: maciej or maciek are both shorth-ish;
[15:07] <zyga-ubuntu> I don't think there's a shorter way
[15:10] <greyback> jdstrand: thanks for the review. I'll bring up a Weston snap to proof the interface and remove any Mir specifics (I'd not vetted those bits carefully yet)
[15:11] <jdstrand> greyback: I gave some feedback. imo it would be ok to strip out the things we know are mir-specifc and just make this work for the mir snap. if someone provides an alternate slot implementation (eg, weston), we could add anything else (though, bonus points if you snap weston)
[15:11]  * jdstrand is partially kidding
[15:11] <jdstrand> oh heh
[15:11] <jdstrand> :)
[15:11] <jdstrand> gold start for greyback :)
[15:11] <jdstrand> star*
[15:12] <jdstrand> greyback: thanks! :)
[15:12] <greyback> np
[15:12] <mvo> zyga-ubuntu: sad, "mac" would be a great name :P
[15:12]  * mvo hugs mborzecki 
[15:13] <mborzecki> mc borzecki
[15:13] <zyga-ubuntu> mvo: mac sounds good to me :)
[15:13] <ogra_> M.C. ... rock da house !
[15:13] <zyga-ubuntu> mborzecki: do you like it
[15:13] <mvo> lol@mc
[15:13] <zyga-ubuntu> greyback, jdstrand: sorry I wasn't looking at that PR yet
[15:13] <zyga-ubuntu> I got lost in base-18
[15:14] <mvo> mborzecki: next sprint you need to give a performance on stage as the MC
[15:14] <greyback> zyga-ubuntu: no worries, I've plenty to work with :)
[15:14]  * ogra_ adds a PR to base-18 ... "find . -name zyga-ubuntu"
[15:14] <greyback> base 18 arithmetic? yikes!
[15:14] <zyga-ubuntu> heh
[15:14] <mborzecki> hahah, not gonna happen :)
[15:14] <zyga-ubuntu> :D
[15:41] <mvo> cachio_lunch: is 4370 also for 2.30? to make your validations easier?
[15:43] <mborzecki> mvo: thanks for pushing the gofmt fix to #4372, i had it in both PRs but missed it when rebasing :/
[15:43] <mup> PR #4372: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4372>
[15:43] <mup> PR snapd#4370 closed: tests: set TRUST_TEST_KEYS=false for all the external backends <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4370>
[15:44] <mvo> mborzecki: no problem, feel free to rebase that commit from me away if you dislike it
[16:01] <zyga-ubuntu> mvo: 4329 should be mergable now
[16:02] <zyga-ubuntu> mvo: as I said in my last comment just now I constrained the fix to classic systems
[16:02] <zyga-ubuntu> mvo: this lets us land the important fix and use it while the 2nd half is implemented
[16:02] <zyga-ubuntu> mvo: so, that's one up for review :)
[16:03] <zyga-ubuntu> mvo: trivial base-18#21
[16:03] <mup> PR base-18#21: tests: check that hostname is not set <Created by zyga> <https://github.com/snapcore/base-18/pull/21>
[16:11] <zyga-ubuntu> mvo: how can I make the base-18 build aware of a local apt proxy?
[16:11] <zyga-ubuntu> mvo: it'd be good for just the basic bootstrap to do this
[16:13] <mvo> zyga-ubuntu: hm, http_proxy should be fine
[16:13] <mvo> zyga-ubuntu: the env
[16:13] <mvo> zyga-ubuntu: I also added support for squid-deb-proxy-client at some point
[16:14] <mvo> zyga-ubuntu: i.e. iirc it ran the apt config Acquire::http::ProxyAutoDetect  at some point. not sure if this is still the case though
[16:24] <cachio> mvo, please tell me if you need some help to reproduce any other the errors that I saw during beta validation
[16:29] <zyga-ubuntu> mvo: base-18#22
[16:29] <mup> PR base-18#22: hooks,tests: mask motd timer/services <Created by zyga> <https://github.com/snapcore/base-18/pull/22>
[16:29] <mborzecki> it looks to me we need a separate service that monitors how many spread nodes are avalable and then starts the CI job
[16:30] <zyga-ubuntu> mborzecki: aka spread batch system
[16:30] <zyga-ubuntu> yes, I agree
[16:30] <zyga-ubuntu> it's silly that we do things interactively
[16:40]  * zyga-ubuntu slowly EOYs
[16:40] <zyga-ubuntu> just turned my desktop off
[16:42] <brunosfer> Hey guys, I'm trying to run some services in bluetooth using my snap with sdptool, however I get the error "Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory" do you know how can I solve this problem in ubuntu snappy core?
[16:42] <zyga-ubuntu> brunosfer: please ask this question on the forum (forum.snapcraft.io) - more people can see and react and learn from responses there
[16:43] <brunosfer> zyga-ubuntu: Good idea. Thanks for the advice ;)
[16:46] <kalikiana> zyga-ubuntu: xmas is coming early for you, so to speak? :-D
[16:47] <zyga-ubuntu> kalikiana: I hope real snow will follow
[16:48] <kalikiana> fingers crossed
[16:49] <kalikiana> although where I'm at it's most likely just going to be a slushy brown mess
[16:50] <zyga-ubuntu> "ding ding ding, ding ding ding, what's this murky goo, how I hate when it wheels get stuck and shoes get white-salt stains"
[16:51] <pstolowski> zyga-ubuntu, missing Spain already? ;)
[16:51] <zyga-ubuntu> pstolowski: since I left
[16:55] <roadmr> zyga-ubuntu: haha murky goo rofl
[16:56]  * kalikiana also wrapping up for today (not for the year just yet)
[16:57] <kennyloggins> realy wanted to go to asturias , but cant afford eet.
[17:08] <mvo> cachio: still haven't managed to try it yet with a real image
[17:08] <mvo> cachio: after dinner I will try
[17:08] <mvo> cachio: else in my morning
[17:09] <kennyloggins> zyga-ubuntu they're waiting to cross, still in Seville :) https://redd.it/5ihe60
[17:09] <zyga-ubuntu> kennyloggins: hmm?
[17:09] <zyga-ubuntu> kennyloggins: I'd like to live in spain again
[17:10] <zyga-ubuntu> not sure how this is related (apart from seville)
[17:10] <kennyloggins> zyga-ubuntu: Oh, thought you were one of those bots - just a random pic. post I guess.
[17:10] <zyga-ubuntu> WHAT
[17:10] <zyga-ubuntu> :D
[17:10] <kennyloggins> zyga-ubuntu: I need better books to read though.
[17:11] <zyga-ubuntu> I can recommend some
[17:11] <zyga-ubuntu> but I need to read them first :)
[17:11] <kennyloggins> for myself, how lovely.
[17:12] <kennyloggins> oh, that's abit ridge-wing then.
[17:13] <mcphail> I'm getting build errors from build.snapcraft.io - "svn: E670002: Unknown hostname 'svn.code.sf.net'" - is there are problem with DNS resolution?
[17:13]  * mcphail has no idea why he didn't write that in English...
[17:14] <cjwatson> mcphail: https://bugs.launchpad.net/launchpad-buildd/+bug/1668358
[17:14] <mup> Bug #1668358: Snap Builds using SVN Unable to Access Internet <launchpad-buildd:Confirmed> <https://launchpad.net/bugs/1668358>
[17:14] <cjwatson> i.e. svn proxying isn't implemented yet
[17:14] <mcphail> cjwatson: aah. Thanks. That's a shame
[17:14] <cjwatson> mcphail: if you can use http/https URLs with svn, that should work though
[17:15] <cjwatson> hm, maybe not, that bug does give an http:// example
[17:15] <cjwatson> feel free to work out how to fix this ... :-/
[17:15] <mcphail> heh :)
[17:16] <mcphail> I think you overestimate my talents
[17:17] <cjwatson> we probably just need to implement the stuff from https://subversion.apache.org/faq.html#proxy
[17:17] <kennyloggins> used gscan2pdf for the first time in 2 years today - would be nice as a snap.
[17:18] <cjwatson> I don't know whether svn honours the usual proxy environment variables; if not we'll need to hack /etc/subversion/servers or similar.  And we probably also need to change the proxy config to allow those extra HTTP methods.
[17:21] <mcphail> it would be nice if people stopped using svn
[17:21] <sergiusens> cjwatson subversion only allows global setting in its file, no env vars or alternate config files are allowed from what we saw
[17:21] <sergiusens> which is why we did not implement it
[17:21] <cjwatson> sergiusens: right, but launchpad-buildd could
[17:22] <sergiusens> true, we could also implement it in snapcraft if the build environment is discardable
[17:25] <mcphail> popey: any suggestions as to what i need to tweak in https://github.com/mcphail/quakesnap to get sound working?
[17:25] <popey> the one in the store?
[17:26] <mcphail> no - this one doesn't build
[17:26] <mcphail> (well, it builds locally but not on the build server due to the svn issues above)
[17:26] <popey> do you need libpulse0 staged?
[17:26] <popey> and the environment variable so it gets found
[17:26] <mcphail> I tries that but it didn't seem to make a difference. Let me try again
[17:27] <popey> do you get apparmor issues?
[17:27] <mcphail> where do I check for those? dmesg?
[17:27] <popey> snappy-debug.security scanlog
[17:27] <popey> leave that running in a terminal
[17:27] <popey> snap install snappy-debug, if you don't have it first
[17:30] <mcphail> popey: http://paste.ubuntu.com/26133867/
[17:32] <popey> sounds like one for jdstrand ^ :)
[17:32] <mcphail> heh. I'm sure I'm just missing something daft
[17:32] <popey> the alsa plug maybe?
[17:32] <popey> but you also need to bundle a load of alsa gumpf
[17:32] <popey> lemme find an example (assuming it's alsa)
[17:33] <mcphail> certainly the app thinks it is using pulse
[17:33] <kennyloggins> where is the place to create an issue for that problem ?
[17:33] <popey> depends where the issue is
[17:33] <popey> i dont think alsa plug would do it. https://github.com/snapcore/snapd/blob/master/interfaces/builtin/alsa.go
[17:34] <kennyloggins> probably a 'enta' library or something.
[17:35] <popey> https://github.com/snapcore/snapd/search?utf8=%E2%9C%93&q=%2Fsys%2Fdevices&type=
[17:35] <popey> can't see a plug that covers it.
[17:35] <popey> so yeah, one for when jdstrand is about, or a forum thread
[17:37] <kennyloggins> libasound2 ? I think that is shared libraries in debian. but again - I'm a random today.
[17:37] <mcphail> OK. Cheers popey
[17:51] <jdstrand> mcphail (cc popey): the wgetrc you can ignore or adjust your wget invocation to use a wgetrc in your snap
[17:51] <jdstrand> mcphail (cc popey): plugs screen-inhibit-control
[17:52] <jdstrand> mcphail (cc popey): the /sys/devices issue was actually just fixed in the upcoming 2.30
[17:52] <popey> woohoo!
[17:52] <jdstrand> mcphail (cc popey): as part of the joystick interface
[17:53] <jdstrand> mcphail: I suspect tomorrow's edge snap will have the fix
[17:53] <jdstrand> edge core* snap
[17:53] <popey> Great to hear, thanks jdstrand
[17:53] <jdstrand> np
[17:54] <jdstrand> popey, mcphail: see https://forum.snapcraft.io/t/joysick-access-for-sdl2-apps/3027 for details
[17:59] <mcphail> jdstrand: ooh. thanks
[19:22] <sergiusens> elopio mind checking my update on LP: #1736861 ?
[19:22] <mup> Bug #1736861: classic snap fails to build with "cannot find section" <regression> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1736861>
[19:31] <mup> PR snapd#4374 opened: interfaces: interfaces: also an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4374>
[19:46] <elopio> sergiusens: I get "OSError: libarchive.so: cannot open shared object file: No such file or directory"
[19:46] <sergiusens> oh, I built it on a dirty system
[19:46] <sergiusens> elopio let me just push the branch
[19:49] <sergiusens> elopio snapcraft#1798
[19:49] <mup> PR snapcraft#1798: go plugin: strip sections that patchelf does not handle <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
[19:50] <mup> PR snapcraft#1798 opened: go plugin: strip sections that patchelf does not handle <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
[22:22] <mup> PR snapd#4375 opened: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4375>
[22:27] <gsilvapt> hello all
[22:27] <gsilvapt> kyrofa, you around=
[22:27] <gsilvapt> s/=/?
[22:29] <kyrofa> gsilvapt, I am, although knee deep in something at the moment
[22:30] <gsilvapt> kyrofa, I see. If you have some free time, let me know so we can finish the version feature if that's okay to you
[22:34] <kyrofa> gsilvapt, where did we leave off? Trying to add the variable in?
[22:37] <gsilvapt> kyrofa, the string was working but I was not able to pass in the %(prog) and %(version) variables correctly
[22:39] <kyrofa> gsilvapt, that's an old-style format string. Hints here: https://pyformat.info/
[22:40] <kyrofa> gsilvapt, however, I remember that we ran into testing issues with %(prog), which is why we hard-coded "snapcraft"
[22:40] <kyrofa> Might want to continue doing that
[22:40] <gsilvapt> kyrofa, thank you. I'll take a look right after I finish prepping the information to apply my LoCo to revalidation.
[22:40] <kyrofa> Sure thing
[23:12] <gsilvapt> kyrofa, now I read your first message. So are we not using %(prog) variable then?
[23:12] <gsilvapt> Or for now we'll stick with that and see how it behaves?
[23:18] <kyrofa> Either way, but I suspect you'll run into troubles using it