[00:18] <soee> hey :-) Someone able to help me with this problem: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks ?
[01:49] <mup> PR snapcraft#1511 closed: project_loader: support grammar on build-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1511>
[05:28] <mup> PR snapd#3804 closed: cmd/snap-seccomp: support parsing 'u:' and 'g:' for username and groups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3804>
[05:28] <mup> PR snapd#3805 closed: interfaces/{default,account-control}: Use username/group instead of uid/gid  <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3805>
[06:13] <mup> PR snapd#3398 closed: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
[06:16] <mup> PR snapd#3616 closed: cmd/snap-repair: check signatures of repairs from Next <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3616>
[07:53] <zyga-ubuntu> good morning
[07:53]  * zyga-ubuntu is packed and waiting 
[07:57] <zyga-ubuntu> mvo: I'll be going back to warsaw at around 16:30, in the meanitime I'm working from a place with (hopefully) better network than mine
[08:06] <pstolowski> morning zyga-ubuntu !
[08:07] <pstolowski> mvo, hey, conflict in 3773, plus one silly question from me
[08:08] <zyga-ubuntu> good morning :)
[08:13] <mvo> zyga-ubuntu: ok, let try to catchup today about the bases snap-confine work
[08:13] <mvo> pstolowski: thank you, I have a look now
[08:14] <zyga-ubuntu> mvo: indeed, I'm sorry about yesterday
[08:15] <mvo> zyga-ubuntu: no worries
[08:16] <mup> PR snapd#3820 closed: spread: don't set HTTPS?_PROXY for linode <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3820>
[08:17] <mup> PR snapd#3826 closed: interfaces/iio: add read/write for missing sysfs entries <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3826>
[08:18] <zyga-ubuntu> willdeberry: hey, conflicts on https://github.com/snapcore/snapd/pull/3812
[08:18] <mup> PR snapd#3812: interfaces: expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
[08:20] <mup> PR snapd#3755 closed: try to reenable fedora spread tests <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3755>
[08:20] <mup> PR snapcraft#1498 closed: lxd: pass original CLI arguments down to container <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1498>
[08:22] <zyga-ubuntu> I see this is a merge-morning :)
[08:30] <zyga-ubuntu> pstolowski: any updates on https://github.com/snapcore/snapd/pull/3810 ?
[08:30] <mup> PR snapd#3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
[08:32] <pstolowski> zyga-ubuntu, yeah, let me push. nb, I removed Ref() after all. I added them in the first place just for a single interface that needed them for error message
[08:33] <pstolowski> zyga-ubuntu, so instead I just changed the error message in that interface
[08:33] <zyga-ubuntu> pstolowski: sounds good, let me know when this is ready for another review
[08:34]  * zyga-ubuntu *really* likes commit messages from jhenstridge
[08:34] <zyga-ubuntu> this is what a descriptive patch looks like
[08:47] <zyga-ubuntu> mvo: oh 2.27.5 is out already? I need to push some packages then
[08:47] <zyga-ubuntu> I'll do that in the evening from home though
[08:57] <mvo> zyga-ubuntu: indeed
[09:02] <mwhudson> zyga-ubuntu: feel free to do debian :)
[09:03] <zyga-ubuntu> mwhudson: thank you! I really wanted to :)
[09:06] <pedronis> mvo: not an immediate thing, but related to pstolowski comment on your run branch, should we consider sending repair failures/retry marking for sending to errtracker ?
[09:07] <mvo> pedronis: that is a good idea
[09:08] <zyga-ubuntu> indeed, good idea
[09:08] <zyga-ubuntu> mvo: though I'd suggest doing a small refactor of that code
[09:08] <zyga-ubuntu> mvo: so that we can queue/send async the errors
[09:09] <zyga-ubuntu> and not just hurrah-send them like today
[09:09] <zyga-ubuntu> the same thing will become useful to other layers
[09:10] <zyga-ubuntu> mvo: it almost feels like an overlord manager
[09:12] <mvo> pedronis: sending failures sounds good, sending retries I'm not sure, given that its not a failure as such, maybe we should send an error if we got no ack over the status fd? this indicates a buggy repair script
[09:13] <mvo> zyga-ubuntu: I have no plans for this currently, I assume you have something like a spool dir and such in mind?
[09:13] <Chipaca> mvo: so, about gbp.conf, why does trusty have that? why does ¬trusty not have that? which is the right one?
[09:13] <zyga-ubuntu> mvo: yes, something like that, essentially a way to start building on this as a feature we could use for health checks later on
[09:13] <pedronis> mvo: yea, maybe that's an ok compromise
[09:13] <zyga-ubuntu> mvo: something stateful that can survive power outage
[09:13] <zyga-ubuntu> mvo: especially if we then revert core to, e.g. fix a network issue
[09:14] <mvo> Chipaca: feel free to remove it, it needs some work to be useful again. it basicly stopped being useful when we started vendoring
[09:14] <mvo> pedronis: thank you
[09:14] <zyga-ubuntu> ikey: hey, I have a question about https://github.com/snapcore/snapd/pull/3720
[09:14] <mup> PR snapd#3720: cmd,interfaces: add initial support for Solus <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3720>
[09:14] <zyga-ubuntu> ikey: do you plan on workin on that? Shall I pick it up?
[09:15] <zyga-ubuntu> ikey: it would be great to have 2.28 with solus ready :)
[09:15] <mvo> zyga-ubuntu: yeah, don't get me wrong, I am not against this at all, just have no plans to work on this currently (given the other open todo items)
[09:15] <zyga-ubuntu> ikey: and related to that, we should talk about some level of CI, a headless image to at least test building would be awesome
[09:15] <zyga-ubuntu> mvo: understood
[09:16] <Chipaca> mvo: sir yes sir
[09:18] <mvo> Chipaca: thank you
[09:18] <pedronis> Chipaca: or mvo:  need a quick sanity check of the changes I did to snapd#3573
[09:18] <mup> PR snapd#3573: overlord: always try to get a serial, lazily on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
[09:18] <Chipaca> we're two PRs away from a single page of PRs
[09:18] <Chipaca> i'm going to weep
[09:18] <Chipaca> :-)
[09:19] <mvo> quick, push more! oh, merge more I mean
[09:19]  * Chipaca reaches for his MART
[09:22]  * Chipaca quietly puts this on the coffee table: https://awfulmidis.tumblr.com/post/164727430527/totos-africa-but-with-the-donkey-kong-country
[09:23] <Chipaca> pedronis: that PR looks fine
[09:23]  * mvo looks at the current failure in master and pokes at snap userd in 14.04
[09:24] <Chipaca> mvo: :-(
[09:24] <mvo> Chipaca: 3823 looks like an easy win
[09:25] <zyga-ubuntu> mvo: oho, upstart strickes back?
[09:25] <Chipaca> pedronis: would loading "snaps" into a map[string]json.RawMessage be cheaper than loading it into a map[string]*SnapState?
[09:25] <zyga-ubuntu> strikes*
[09:25] <pedronis> Chipaca: yes
[09:25] <Chipaca> pedronis: in NumSnaps
[09:26] <Chipaca> pedronis: and loading it into a map[string]struct{}? (would that work?)
[09:28] <mvo> zyga-ubuntu: maybe :) trying to figure out what is going on right now
[09:28] <pedronis> Chipaca: that I don't know
[09:29] <pedronis> I'm not sure it makes a lot of difference
[09:29] <mvo> Chipaca: also 3795 is an easy one (and short)
[09:30]  * zyga-ubuntu reviews top-bottom
[09:30] <zyga-ubuntu> and debootstraps sid :)
[09:32] <Chipaca> mvo: 3795 is good, i didn't +1 it myself because i saw it's got a request for gustavo to do so
[09:32] <Chipaca> mvo: if you don't think it's that important for him to review it i can +1 it
[09:32] <pedronis> it's a change for the REST api
[09:32] <pedronis> that's why I put it for him to look at it
[09:33] <mvo> Chipaca: I could be wrong, but it seems the "allow-interactive" hint is uncontroversial
[09:33] <pedronis> it's a name, names are always controversial
[09:34]  * zyga-ubuntu mutters something about hygenic macros and goes back to reviews
[09:34] <zyga-ubuntu> pedronis: conflict on https://github.com/snapcore/snapd/pull/3781
[09:34] <mup> PR snapd#3781: cmd/snap-repair: track and use a lower bound for the time for TLS checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/3781>
[09:35] <mvo> pedronis: meh, good point about names being controversial (cc Chipaca)
[09:36] <pedronis> there are 6 PRs  marked for Gustavo, is not too bad, maybe
[09:37] <pedronis> Chipaca: pushed the change to *RawMesssage
[09:38]  * zyga-ubuntu wonders if we could reach PR zero by EOD
[09:38] <pedronis> very unlikely
[09:39] <pedronis> also seems we are adding more stuff to 2.28
[09:39] <pedronis> that needs jamie reviews
[09:40] <pedronis> Chipaca: anything else in #3573 ?
[09:40] <zyga-ubuntu> I think jamie is back today, no?
[09:41] <pedronis> he was back already yesterday
[09:41] <pedronis> doesn't mean much, depends where things stand on his prios
[09:42] <zyga-ubuntu> Chipaca: conflict on https://github.com/snapcore/snapd/pull/3748
[09:42] <mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
[09:43] <pedronis> it's also Blocked
[09:44] <pedronis> mvo: seems  snapd#3502 needs a 2nd look either from zyga or jamie  ?
[09:44] <mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
[09:44] <zyga-ubuntu> mvo: conflicts on https://github.com/snapcore/snapd/pull/3779 (probably trivial but I'd rather not hand-edit vendor.json)
[09:44] <mup> PR snapd#3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
[09:44] <Chipaca> pedronis: no, as i say it's fine (even without that change)
[09:44] <zyga-ubuntu> Chipaca: I think we could pull out https://github.com/snapcore/snapd/pull/3748/commits/90a8ca941f6f322e7aa7150bc7bba738708e06cb for a separate landale PR
[09:44] <mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
[09:45] <pedronis> also soon or already travis will bottleneck us
[09:48] <Chipaca> zyga-ubuntu: agreed on that, but is it worth it
[09:48] <zyga-ubuntu> Chipaca: yes, diffs shrink
[09:48] <zyga-ubuntu> that is always good :)
[09:48] <zyga-ubuntu> even if that branch doesn't land for whatever reason
[09:53]  * zyga-ubuntu looks at 3719
[09:54] <mvo> zyga-ubuntu: didn't the removal itself trigger the conflict? anyway, resovled
[09:55] <zyga-ubuntu> mvo: thanks
[09:55] <zyga-ubuntu> mvo: I think it did
[09:55] <mvo> zyga-ubuntu: uh, sorry, where does x/sys/unix come from?!? let me look again at this pr
[09:55]  * zyga-ubuntu doesn't know, sorry
[09:56]  * zyga-ubuntu is half-way through sid debootstrap
[09:56] <zyga-ubuntu> slow network lets one appreciate time
[09:58] <mup> PR snapd#3827 opened: vendor: fix artifcat from manually editing vendor/vendor.json  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3827>
[09:59] <Chipaca> zyga-ubuntu: did you see 3502 is ready for another look?
[09:59] <zyga-ubuntu> mvo: interesting read for later: https://jneem.github.io/pijul/
[10:00] <zyga-ubuntu> Chipaca: I'll review this after the desktop interface PR now
[10:00] <Chipaca> mvo: FYI: there are no spread tests that fail if I nuke the dh_systemd sections from the 16.04 rules file
[10:00] <zyga-ubuntu> Chipaca: o_O
[10:01] <zyga-ubuntu> that's curious
[10:01] <zyga-ubuntu> we are very reliable ;-)
[10:01] <Chipaca> zyga-ubuntu: meaning the defaults word probably work well enough for us
[10:01] <Chipaca> zyga-ubuntu: the overrides were created in the prehistory, and cargo-culted, need revisiting
[10:02] <mvo> Chipaca: \o/ lets kill them with fire then
[10:02] <Chipaca> mvo: piano piano
[10:02] <Chipaca> mvo: this might mean we aren't testing enough :-)
[10:03] <mvo> Chipaca: well, I guess it makes sense to compare the output of systemctl for the various units with our old rules and the defaults
[10:03] <mvo> Chipaca: not us ;)
[10:03] <Chipaca> it is an encouraging direction for further research :-)
[10:03] <Chipaca> but, not now. now i've got conflicts to resolve and review feedback to address
[10:03] <Chipaca> zyga-ubuntu: if you have feedback on snapd#3748 now would be a very good time
[10:03] <mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
[10:07] <zyga-ubuntu> Chipaca: I will, just let me finish the PRs :)
[10:07] <zyga-ubuntu> I have them all open in tbas
[10:07] <zyga-ubuntu> *tabs
[10:07] <Chipaca> zyga-ubuntu: about separating that commit, it's more involved than that unfortunately
[10:08] <Chipaca> conceptually simple, sure :-)
[10:11]  * mvo grumbles about upstart and the lack of any information why a job is no longer running
[10:13] <zyga-ubuntu> Chipaca: aha, I see
[10:15] <Chipaca> zyga-ubuntu: i'd have to go over the previous commits and pull out the right bits that made that commit necessary
[10:15] <Chipaca> very untidy of me :-/
[10:15] <pedronis> Chipaca: doesn't sound a super useful use of time
[10:16] <Chipaca> pedronis: mhmm
[10:16] <Chipaca> OTOH if the PR took much longer to get out there there might be merit to it
[10:17] <pedronis> Chipaca: it is fixing a preexisting problem? a potential preexisting problem? or something that your other stuff triggered?
[10:18] <Chipaca> pedronis: the tests were messy, some of them running with root dir on / and not writing/reading system stuff by happenstance
[10:18] <Chipaca> so i added a setrootdir to the test setup
[10:18] <Chipaca> so i then had to change all the tests that matched strings to the fixed ones
[10:19] <Chipaca> this came about because i added a test that broke when there wasn't a file in the "outside"
[10:19] <Chipaca> (the test passed on my machine because i'd already run the code in the pr so i had that file)
[10:19] <Chipaca> pedronis: so, bit of column a, bit of column b
[10:19] <mup> PR snapd#3828 opened: release: 2.27.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3828>
[10:22] <pedronis> Chipaca: sounds easier to do a new PR
[10:22] <pedronis> just about this
[10:22] <pedronis> that untangling it from that PR
[10:22] <Chipaca> my thought exactly
[10:25] <pedronis> mvo: do we have a fix for snap-userd test?
[10:25] <pedronis> I get
[10:25] <pedronis> + stop test-snap-userd
[10:25] <pedronis> stop: Unknown instance:
[10:25] <pedronis> mvo:  https://travis-ci.org/snapcore/snapd/builds/269919547?utm_source=github_status&utm_medium=notification
[10:27] <Chipaca> pedronis: i think that's what mvo is getting too
[10:27] <Chipaca> mvo: does it go away if you back out snapd#3398 ?
[10:27] <mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
[10:29] <mvo> pedronis: looking into it currently, the going is slow, my upstart is rusty and things are slightly dubious
[10:29] <mvo> Chipaca: I doubt that 3398 is related, it looks like for some reason snap userd is dying before its time
[10:29] <mvo> Chipaca: and I'm trying to figure out *why* now
[10:30] <Chipaca> mvo: if i run with --debug
[10:30] <Chipaca> mvo: i find that userd runs fine, via dbus activation? i think
[10:30] <Chipaca> mvo: it's just that upstart doesn't "see" it
[10:30] <Chipaca> i mean, ps doesn't see a snap userd, but i can message it and it appears
[10:30] <Chipaca> that's something activating it :-)
[10:31] <mvo> Chipaca: yeah, it is auto-activated
[10:31] <Chipaca> mvo: so it looks like it gets activated before upstart can start it
[10:31] <mvo> Chipaca: yeah, that sounds plausible
[10:32] <mvo> Chipaca: let me test this theory, maybe we can kill some code here :)
[10:32] <Chipaca> mvo: and this might be caused by 3398 because before we weren't copying the dbus things into place
[10:32] <mvo> Chipaca: oohhhhh
[10:32] <mvo> Chipaca: yes, now things start to make sense
[10:32] <zyga-ubuntu> jdstrand: hey
[10:32] <Chipaca> mvo: and 3398 landed because it ran the test at some silly hour in the morning, meaning less load on travis
[10:32] <Chipaca> or linode
[10:32] <Chipaca> or whatever
[10:32] <Chipaca> bah, it's a race, we one it once :-)
[10:33] <Chipaca> a bit like england motorsport
[10:33] <mvo> Chipaca: or footbal
[10:33] <mvo> Chipaca: (SCNR)
[10:33] <Chipaca> as an argentine i daren't mention the f word
[10:33]  * zyga-ubuntu raises his eyebrow 
[10:33] <mvo> Chipaca: yeah, I think it all makes sense, let me run one more test, then I will push something that removes a bunch of extra lines in this test :)
[10:33] <zyga-ubuntu> jdstrand: 3719 is good to land though it will need a follow up
[10:34] <mvo> Chipaca: f-word *cough* - double sorry, forgot about that
[10:34] <Chipaca> :-)
[10:34]  * mvo is not actually following this very much
[10:34] <Chipaca> at least fangio never won with his hand, or something
[10:34] <mvo> lol
[10:34] <zyga-ubuntu> jdstrand: I'll leave it as is and merge later today
[10:40]  * zyga-ubuntu reads 3502
[10:49] <zyga-ubuntu> Chipaca: what is the official fake base store?
[10:49] <Chipaca> zyga-ubuntu: store/storetest.Store
[10:49] <Chipaca> zyga-ubuntu: // Store implements a snapstate.StoreService where every single method panics.
[10:50] <zyga-ubuntu> that's bad-hair-day-store in lisp, rigt/
[10:50] <zyga-ubuntu> right*
[10:50] <ogra_> can y<ou then "snap install vaporware" ?
[10:51] <Chipaca> ogra_: 1. snap install xbill-xaw
[10:51] <Chipaca> ogra_: 2. enjoy your vaporware
[10:51] <Chipaca> :-)
[10:51] <ogra_> heh, insteasd of duke-nukem-forever ?
[10:51] <ogra_> -s
[10:51] <Chipaca> ogra_: there was no vapor in dnf
[10:52] <Chipaca> waaaait
[10:52] <ogra_> haha
[10:52] <Chipaca> dnf is duke-nukem-forever?
[10:52] <ogra_> i think so
[10:52] <zyga-ubuntu> well, come on
[10:52] <Chipaca> bunch'a nerds
[10:52] <zyga-ubuntu> duke is out
[10:52]  * Chipaca goes back to playing xbill
[10:52] <ogra_> yeah, it isnt exactly vaporware butu it was dfor a decade
[10:53] <zyga-ubuntu> snap install world-peace
[10:53] <zyga-ubuntu> miracle assertion required
[10:53] <ogra_> yeah, and a boring game i bet
[10:54] <zyga-ubuntu> my sid debootstrap is at "g" now
[10:54] <zyga-ubuntu> and my git fetch is at "k" now
[10:54] <ogra_> dooesnt debian have pre-made tarballs like ubuntu-base ?
[10:54] <zyga-ubuntu> ogra_: it's for sbuild
[10:54] <ogra_> ah
[10:55] <zyga-ubuntu> and I doubt I'd save any time
[10:55] <ogra_> well, using debootstrap on ubuntu takes minutes ... downloading and untarring the base tarball takes seconds
[10:55] <ogra_> that is why we have this product ;)
[10:56] <zyga-ubuntu> ogra_: my modem takes forever, priceless
[11:00] <zyga-ubuntu> mvo: should tests in cmd/snap-seccomp in https://github.com/snapcore/snapd/pull/3502 take long?
[11:00] <mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
[11:00] <zyga-ubuntu> mvo: on my x250 it's ~~ minute and going
[11:01]  * zyga-ubuntu breaks for 3 minutes
[11:01] <pedronis> Chipaca: mvo: does that test passes sometimes? or always fail? should I try to rerun?
[11:02] <Chipaca> pedronis: it passes sometimes
[11:02] <Chipaca> pedronis: but if mvo is fixing it, maybe instead of rerunning, merge his fix?
[11:03] <pedronis> when it exists
[11:04] <pedronis> anyway seems quite consistent in failing
[11:05] <zyga-ubuntu> mvo: 2m39,683s
[11:05] <zyga-ubuntu> ouch!
[11:05] <pedronis> also fedora preparate
[11:05] <pedronis> took too long
[11:06] <pedronis> https://travis-ci.org/snapcore/snapd/builds/269925918?utm_source=github_status&utm_medium=notification
[11:06] <pedronis> here
[11:23] <mvo> Chipaca, pedronis: PR is ready, sorry, took so long because I wanted to verify in qemu first
[11:24] <Chipaca> mvo: was the diagnosis confirmed?
[11:24] <mup> PR snapd#3829 opened: tests: fix race in snap userd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3829>
[11:26] <Chipaca> mvo: shouldn't we stop it after the test?
[11:30] <Chipaca> mvo: anyway +1
[11:32] <Chipaca> whoops, i just merged a pr without realising it had a request for jdstrand :-(
[11:32] <mup> PR snapd#3824 closed: interfaces: do not match any file or directory in or under /sys/bus/pci/devices/ <Created by adglkh> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3824>
[11:32] <Chipaca> jdstrand: ^ :-( sorry
[11:34] <Chipaca> mvo: snapd#3825 seems ok to land, unless you want to implement zyga-ubuntu's suggestion
[11:34] <mup> PR snapd#3825: tests: add nmcli regression test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3825>
[11:38] <zyga-ubuntu> mvo: do you recall where you saw "/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(libc-start.o): relocation R_X86_64_32 against undefined symbol _dl_starting_up' can not be used when making a shared object; recompile with -fPIC"
[11:38] <zyga-ubuntu> mvo: (context PR 3502)
[11:42] <pedronis> Chipaca: I did mark that one for jamie, but maybe you understand that stuff more than me
[11:42] <mup> PR snapcraft#1517 opened: integration: make onboarding easier for code users <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1517>
[11:48]  * zyga-ubuntu -> lunch
[11:50] <Chipaca> pedronis: very little, but just enough to get that one
[11:51] <pedronis> Chipaca: I probably got paranoid form the recent interface tweaks regressions we had
[11:51] <Chipaca> niemeyer: snapd#3642 is getting long in the tooth
[11:51] <mup> PR snapd#3642: cmd/snap: get keys or root document <Created by stolowski> <https://github.com/snapcore/snapd/pull/3642>
[11:51] <Chipaca> pedronis: la la la la can't hear you la la
[11:59] <pstolowski> is travis acting up or is it just me?
[12:00] <pedronis> pstolowski: lots of work on PRs, it might just be queuing stuff, or you seeing something in particular?
[12:01] <pstolowski> pedronis, test failures
[12:02] <Chipaca> need to reboot my router. brb.
[12:02] <pedronis> pstolowski: there's a recently added test that is flaky,  mvo has a fix
[12:03] <pstolowski> tests/main/snap-userd ?
[12:03] <pedronis> pstolowski: also fedora tests have been reenable and they seem flaky, at least they can take too long to prepare
[12:03] <pedronis> pstolowski: yes
[12:03] <pstolowski> ack, thanks
[12:03] <pedronis> pstolowski: fix is here 2017-08-11T15:49:49Z
[12:03] <pedronis> sorr
[12:03] <pedronis> y
[12:03] <pedronis> pstolowski: fix is here snapd#3829
[12:04] <mup> PR snapd#3829: tests: fix race in snap userd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3829>
[12:08] <zyga-ubuntu> oh, good old netsplit
[12:31] <mvo> Chipaca: I will investigate about your stoping question and do a followup
[12:31] <mvo> Chipaca: I'm in favour of merging 3829 to unbreak the world
[12:32] <zyga-ubuntu> Chipaca: reviewed https://github.com/snapcore/snapd/pull/3748
[12:32] <mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
[12:32] <zyga-ubuntu> except still sending the request to github
[12:36] <arm1e> Hey guys, I have found a snap I want to install on github, but does not show in snap find. Can you tell me why this is please. It says it is stable and strict confinement. Thanks
[12:36] <arm1e> https://github.com/jacobzimmermann/gnucash-jz-snap/blob/master/snap/snapcraft.yaml
[12:37] <zyga-ubuntu> arm1e: is the snap released?
[12:37] <zyga-ubuntu> arm1e: is it public?
[12:37] <zyga-ubuntu> arm1e: the presence of that snapcraft.yaml doesn't indicate that in any way (it cannot)
[12:39] <zyga-ubuntu> sub 30 PRs
[12:39] <zyga-ubuntu> nice to see that
[12:40] <arm1e> zyga-ubuntu, can I manually install it?
[12:40] <zyga-ubuntu> I find it funny that everyone seems to edit vendor.json by hand because govendor usability is poor
[12:40] <zyga-ubuntu> arm1e: I don't know, build it from source and try
[12:41] <arm1e> ty
[12:41] <mvo> zyga-ubuntu: re 3502 - if you reformat the C code, why not use the indent we use in snap-confine for consitency? instead of adding a different indent
[12:42] <zyga-ubuntu> mvo: oh sorry about that, just because it produces saner indent and I'm about to switch to that one
[12:42] <zyga-ubuntu> mvo: clang-format is less crazy
[12:42] <zyga-ubuntu> mvo: and has good defaults for various styles
[12:42] <zyga-ubuntu> mvo: I just didn't want to bother with running indent that right way for this
[12:43] <mvo> zyga-ubuntu: I refer to the "standards" from xkcd :)
[12:43] <zyga-ubuntu> mvo: and one more observation, indent actually broke with future versions
[12:43] <zyga-ubuntu> mvo: it produces different output for same profile
[12:43] <mvo> zyga-ubuntu: anyway, I don't relaly mind much, it just seems that we should pick one and stick to it. the go fmt guys were incredible wise
[12:43] <zyga-ubuntu> mvo: so that coupled with general sane output from clang-format
[12:43] <mvo> zyga-ubuntu: it does? meh, that sucks
[12:43] <zyga-ubuntu> mvo: indeed
[12:43] <zyga-ubuntu> mvo: I'll switch us to that when travis is calm
[12:44] <zyga-ubuntu> mvo: yep, sadly
[12:44] <zyga-ubuntu> mvo: the difference is in one spot and we could just remove that code and replace it with something that doesn't trigger it
[12:44] <zyga-ubuntu> mvo: but meh
[12:44] <mvo> zyga-ubuntu: I'm not a fan of reformating as we will loose all VCS history (git blame will be useless)
[12:44] <zyga-ubuntu> mvo: mmm, good point
[12:45] <zyga-ubuntu> mvo: we'll see, maybe we can do it on a file-by-file basis when introducing significant enough changes
[12:45] <mvo> omg - autopkgtests in artful for 2.27.5 arre all green, yay!
[12:46] <zyga-ubuntu> mvo: that's a rare sight :)
[12:46] <mup> PR snapd#3829 closed: tests: fix race in snap userd test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3829>
[12:48] <zyga-ubuntu> Chipaca: I reviewed https://github.com/snapcore/snapd/pull/3748
[12:48] <mup> PR snapd#3748: many: fetch & cache remote snaps and sections; complete from there <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
[12:48] <Chipaca> zyga-ubuntu: ack
[12:49] <zyga-ubuntu> hmm
[12:49] <zyga-ubuntu> zesty broke my modem connection
[12:49] <zyga-ubuntu> that's not great :/
[12:49] <zyga-ubuntu> I mean my built-in modem
[12:54] <Son_Goku> zyga-ubuntu, so... dnf is now in openSUSE Factory
[12:54] <jdstrand> Chipaca: responded (https://github.com/snapcore/snapd/pull/3824/files#r136058008)
[12:54] <mup> PR snapd#3824: interfaces: do not match any file or directory in or under /sys/bus/pci/devices/ <Created by adglkh> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3824>
[12:54] <Son_Goku> zyga-ubuntu, this means that we can use the same API for supporting snapcraft on RPM based distributions
[12:55] <zyga-ubuntu> hey
[12:55] <zyga-ubuntu> I read your earlier note, that's a good thing
[12:56] <zyga-ubuntu> not certain yet but after layouts it looks like something I can work on
[12:56] <Son_Goku> which reminds me, niemeyer, I'll be making that snapcraft forum post soonish today
[12:56] <Son_Goku> I've just been busy with life things, like eye doctor visits
[12:56] <Son_Goku> to get new glasses :)
[13:00] <zyga-ubuntu> sigh
[13:00] <zyga-ubuntu> zesty broke 3G
[13:00] <zyga-ubuntu> ...
[13:01] <zyga-ubuntu> "no such device" you say, while showing the modem *and* the signal strenght
[13:01] <Son_Goku> :)
[13:01] <zyga-ubuntu> strength
[13:02] <niemeyer> Son_Goku: Thanks!
[13:02] <niemeyer> Hello all
[13:05] <zyga-ubuntu> 2fa
[13:06] <zyga-ubuntu> logging in
[13:08] <Chipaca> jdstrand: phew
[13:19] <zyga-ubuntu> connection breaking
[13:22] <abeato> ogra_, does wifi work in the dragonboard?
[13:23] <ogra_> abeato, sure
[13:23] <ogra_> wer dont have any device where it doesnt work atm ... at least to my knowledge
[13:24] <abeato> ogra_, ok, just double checking, thanks
[13:33] <mup> PR snapd#3719 closed: interfaces: add desktop and desktop-legacy <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3719>
[13:38] <zyga-ubuntu> woot, wife arrived
[13:39] <zyga-ubuntu> I'll move luggage into the car and be back soon
[13:39] <zyga-ubuntu> mvo: you should have used your 3g modem
[13:39] <zyga-ubuntu> mvo: then you would tell me the zesty update broke it :)
[13:39] <zyga-ubuntu> mvo: and I would have stayed on xenial
[13:39] <zyga-ubuntu> mvo: I'll move to artful at home, hopefully it won't be more broken
[13:40] <mvo> zyga-ubuntu: sorry for that, I actually hardly ever use that thing
[13:40] <mvo> zyga-ubuntu: have a good trip back
[13:40] <mvo> zyga-ubuntu: nothing we can fix (relatively) easily with regards to the modem?
[13:40] <ogra_> just ... snap revert distro
[13:40] <ogra_> :P
[13:48] <niemeyer> Chipaca, pstolowski: About snapd#3642, yeah, I was somewhat consciously letting this one sleep.. I was concerned about jumping the gun on the UI change and regret the decision we agreed to
[13:48] <mup> PR snapd#3642: cmd/snap: get keys or root document <Created by stolowski> <https://github.com/snapcore/snapd/pull/3642>
[13:48] <zyga-ubuntu> mvo: I need to give you a working sim card :)
[13:48] <niemeyer> Let me look into it again
[13:48] <zyga-ubuntu> mvo: there are those services that give you low transfer for free essentially
[13:49] <zyga-ubuntu> mvo: no idea why it doesn't work, the modem works, it's just nm and mm don't see eye to eye
[13:49] <mvo> zyga-ubuntu: ha! yeah, I guess I need one of those
[13:49] <niemeyer> Hmm.. I think we should teach mup to use #3652 as a snapd bug here..
[13:49] <niemeyer> s/bug/PR
[13:49] <niemeyer> Sounds vastly more common to talk about those
[13:50] <niemeyer> Anyone against? 3.. 2.. 1.. :P
[13:53] <zyga-ubuntu> niemeyer: hmm?
[13:56] <mup> PR snapd#3823 closed: tests: rename complexion to test-snapd-complexion <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3823>
[14:00] <niemeyer> zyga-ubuntu: I'll take the hmm as "Yeah, great idea!"
[14:01] <zyga-ubuntu> niemeyer: I was trying to parse your earlier statement
[14:01] <mvo> zyga-ubuntu: fwiw, I updated 3825 (based on your idea)
[14:01] <zyga-ubuntu> niemeyer: but yeah :)
[14:01] <zyga-ubuntu> go ahead
[14:01] <zyga-ubuntu> mvo: oh, thank you!
[14:01]  * zyga-ubuntu looks
[14:02] <zyga-ubuntu> Thank you!
[14:05] <niemeyer> #3573
[14:05] <mup> PR #3573: overlord: always try to get a serial, lazily on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
[14:05] <niemeyer> There you go!
[14:07] <zyga-ubuntu> ah
[14:07] <zyga-ubuntu> niemeyer: I parsed your earier comment now, yes, definite +1
[14:08] <niemeyer> ;)
[14:10] <zyga-ubuntu> github unicorns :/
[14:10] <mvo> down to 25!
[14:11] <Chipaca> mmm, unicorns
[14:11] <mup> PR snapd#3827 closed: vendor: fix artifact from manually editing vendor/vendor.json  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3827>
[14:11] <Chipaca> i've got a slow cooker
[14:21] <ogra_> Riddell, wow, falkon is impressingly fast!
[14:21] <Riddell> ogra_: ooh it's working?
[14:21] <ogra_> yeah
[14:21] <Riddell> nice
[14:21] <ogra_> (xenial here)
[14:21] <Riddell> it seems very promising
[14:22] <ogra_> Riddell, not sure you have seen it https://forum.snapcraft.io/t/kde-neon-chooses-snap/1898 ... not working everywhere yet (though thats more an arch snapd issue i guess)
[14:23] <Riddell> yeah that's why it's nice to have a good report
[14:27] <jdstrand> mvo: fyi, I have PR 3779 on my list, but I'd like to see 3502 go through first so it is easier to see the changes
[14:27] <mup> PR #3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
[14:27] <jdstrand> PR 3502
[14:27] <mup> PR #3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
[14:33] <mup> PR snapd#3828 closed: release: 2.27.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3828>
[14:38] <pedronis> niemeyer: I'm not sure if your comment was about the TODO I added, do you have a suggestion for what comment you would like added instead?
[14:39] <niemeyer> pedronis: It wasn't about the code.. I haven't seen the updates
[14:39] <Riddell> a snapd issue? https://blog.neon.kde.org/index.php/2017/08/29/great-web-browsing-coming-back-to-kde-with-falkon-new-packaging-formats-coming-to-kde-with-snap/#comment-249
[14:39] <pedronis> niemeyer: I added a TODO there
[14:39] <niemeyer> pedronis: +1 then!
[14:39] <niemeyer> pedronis: I mean, it already had the +1, so that's +2 I guess :P
[14:40] <pedronis> yea, mostly waiting for green but travis is queuing, so much PR work going :)
[14:41] <pedronis> jdstrand: #3621 is also something I marked for you to look at
[14:41] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[14:41] <jdstrand> pedronis: yep, on the list
[14:42] <pedronis> thx
[14:48] <mup> PR snapd#3484 closed: tests: add autopilot-introspection interface test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3484>
[14:59] <mup> PR snapd#3830 opened: tests: deal with __PNR_chown on aarch64 to fix FTBFS on arm64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3830>
[15:02] <Chipaca> 24 PRs!
[15:02] <Chipaca> do we get cookies
[15:06] <genii> !cookie
[15:06] <genii> Hm
[15:07] <genii> Ah, there we go
[15:08] <pstolowski> Chipaca, hey, see https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908/8 ;ok if I take it or have you already started?
[15:10] <Chipaca> pstolowski: i have not started but was about to
[15:10] <Chipaca> pstolowski: but, if you'd rather do it go for it
[15:10] <Chipaca> pstolowski: i have no lack of things to do
[15:11] <Chipaca> pstolowski: i know the service side but would need to learn the snapctl side, and you viceversa. I suspect you've got less to learn than i
[15:11] <mup> PR snapd#3635 closed: tests: add out-of-the-box test suite <Decaying> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3635>
[15:11] <niemeyer> Lunch.. biab
[15:11] <pstolowski> Chipaca, ok. yes, that was exactly the point niemeyer was making (about other stuff on your plate), so I'm fine to take it
[15:13] <Chipaca> ogra_: how much hard drive space would a 'small' device have these days?
[15:13] <Chipaca> (for handwavy values of "hard drive")
[15:17] <ogra_> Chipaca, dunno ... i think the smalles Sd card you can buy is 2GB atm
[15:18] <Chipaca> ogra_: so keeping 100MB of space around just-in-case is not too bad?
[15:19] <Chipaca> ogra_: that is, if snapd said "i'm going to ignore what you just told me to do because disk is running short" at 100MB, that'd be alright?
[15:19] <Chipaca> on small devices i mean
[15:20] <ogra_> well the formatting tools typically reserve 5% for root so that the system keeps running even if a user fills up the disk
[15:20] <Chipaca> ogra_: yes, but snapd runs as root
[15:20] <ogra_> i wonder if a percentage is better than a fixed limit of megabytes
[15:20] <Chipaca> 5% is way too much these days, most of the time
[15:20] <ogra_> yeah, i didnt mean that :)
[15:21] <ogra_> 100MB are surely ok to keep the OS running ...
[15:21] <Chipaca> I'd be fine with max(10MB, min(100MB, 5%))
[15:21] <Chipaca> or maybe 20MB as the min min
[15:21] <ogra_> yeah,.. that sounds fine
[15:21] <ogra_> well
[15:21] <Chipaca> or, shocking idea, make it configurable
[15:21] <Chipaca> but that's Hard Work
[15:21] <ogra_> perhaps we shoudl take the core snap as measure here
[15:21] <Chipaca> so stage 2 :-)
[15:22] <Chipaca> ogra_: ah, good idea, or the kernel or sth
[15:22] <ogra_> thats 70+ MB
[15:22] <ogra_> yeah
[15:23] <ogra_> kernel can easily vary a lot ... if you produce a monolithic one with no modules that might actually become a pretty small snap
[15:23] <Chipaca> ogra_: not smaller than the kernel snap on a classic system
[15:23] <Chipaca> :-D
[15:23] <ogra_> yet, if you use our generic kernel and ship all modules 200MB is probably a likely size
[15:24] <ogra_> (modulo squashfs compression)
[15:24] <Chipaca> ah :-)
[15:24] <ogra_> snap info says the pc-kernel snap has 130MB in stable
[15:25] <ogra_> so thats probably a good number
[15:25] <ogra_> add some wiggle room and you end up at 150
[15:25] <Chipaca> so if we want to leave enough space to refresh core+kernel+gadget, 250MB would not be a bad number
[15:26] <ogra_> yeah
[15:26] <Chipaca> that's a lot, but it also seems reasonable
[15:26] <Chipaca> OTOH if you're on classic, 100MB would be fine
[15:26] <pedronis> Chipaca: notice though that means you need to teach UpdateMany to try only  subset of all things in some cases
[15:26] <ogra_> (gadgets are usually in the kilobytes though :) (unless they are raspberry pis with blob firmware :P ))
[15:26] <Chipaca> pedronis: allow me to weep a little
[15:26] <Chipaca> pedronis: but yes
[15:27] <Chipaca> pedronis: i'm just exploring the space, still
[15:27] <pedronis> or piggyback on the prerequisites task mvo is adding in one of his branches
[15:27] <pedronis> Chipaca: that's trying to make sure we don't make it worse
[15:27] <pedronis> like you get stuck
[15:27] <ogra_> Chipaca, also take into account that our device images come with only a few MB free in writable ... expansion only happens on first boot
[15:28] <pedronis> Chipaca: it depends alos where you check/fail
[15:28] <ogra_> (5 oor 10 ... i forgot what ubuntu-image adds exta ... but it isnt much)
[15:28] <pedronis> Chipaca: if you check in download just before downloading it might be alright with lanes
[15:29] <pedronis> but also need to check if UpdateMany create sequential lanes or not, I don't think so
[15:32] <Chipaca> pedronis: ogra_: added this to https://forum.snapcraft.io/t/out-of-disk-space-protection/1632/8
[15:35] <pedronis> Chipaca: thx
[16:20] <cachio_> mvo, I already saw this error in pi3 and i385 exec https://paste.ubuntu.com/25432913/
[16:21] <cachio_> mvo, not sure if the problem is in the snap or it is in snapd
[16:29] <cachio_> It is breaking the whole execution on pi3, I am running again without that test
[16:37] <Chipaca> cachio_: :-(
[16:41]  * zyga-ubuntu updates to artful
[16:48] <mvo> cachio_: a race in the tests :(
[16:48] <cachio_> mvo, yes, seems to be
[16:48] <cachio_> mvo, I am skipping this one
[16:48] <cachio_> mvo, I'll fix it on master
[16:50] <mvo> cachio_: I have a fix ready
[16:50] <mvo> cachio_: it is in #3825
[16:50] <mup> PR #3825: tests: add nmcli regression test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3825>
[16:51] <mvo> cachio_: the problem is that systemd considers the unit started too early. i.e. nm has started, but it has not yet setup its dbus things
[16:52] <cachio_> mvo, you are fast!!
[16:52] <cachio_> mvo, great
[16:52] <cachio_> mvo, the rest of the exec is ok, so we are going well
[16:56] <zyga-ubuntu> jdstrand: commented on https://github.com/snapcore/snapd/pull/3621#discussion_r136128075
[16:56] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[16:56] <zyga-ubuntu> jdstrand: I'm happy to split the rule, can you be more specific as to what you expect
[16:57] <nacc> so i'm using an application (not exposed) in my classic snap that has a hardcoded path. Is my best bet to fork their repository and apply a patch to make it a non-absolute path for the purpose of using it in the snap (since I need to use the version from my snap)?
[16:58] <zyga-ubuntu> nacc: or some preload tricks
[16:59] <nacc> zyga-ubuntu: ok, thanks
[17:00] <nacc> zyga-ubuntu: what preload trick would work to alter a hardcoded path buried in a python file? :)
[17:00] <zyga-ubuntu> nacc: one that remaps open
[17:00] <nacc> zyga-ubuntu: oh ... gross :)
[17:01] <nacc> zyga-ubuntu: i'll just fork :)
[17:01] <nacc> i filed a bug/feature request upstream
[17:01] <zyga-ubuntu> that's much better long-term IMO
[17:01] <nacc> yeah
[17:01] <nacc> zyga-ubuntu: thanks!
[17:07] <jdstrand> zyga-ubuntu: I'll comment in the PR (a bit later). note I have not done my full review of the pr yet. planning on it a bit later today
[17:08] <zyga-ubuntu> jdstrand: thank you!
[17:09] <zyga-ubuntu> I'm (passive) driving home so I have limited conditions
[17:10]  * zyga-ubuntu tries to focus on reviews amids $distractions
[17:17]  * zyga-ubuntu watches the sunset 
[17:19] <arm1e> Hey guys, can you help with an error at the end of building please. Will paste, hold on...
[17:21] <arm1e> https://paste.ubuntu.com/25433178/
[17:21] <arm1e> last line is red in terminal
[17:22] <zyga-ubuntu> arm1e: looked, no idea
[17:23] <arm1e> willsee if it will install.
[17:25] <ogra_> well, it tires to remove a file that doesnt exist obviously
[17:28] <ogra_> you might want to put libgtk-3-bin into build-packages
[17:31] <zyga-ubuntu> jdstrand: btw, is your comment on https://github.com/snapcore/snapd/pull/3814 a formal +1?
[17:31] <mup> PR #3814: interfaces: enable partial apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/3814>
[17:32] <jdstrand> zyga-ubuntu: not until the comments were addressed. let me look at the new commits
[17:33] <zyga-ubuntu> jdstrand: I think they are, let me know if something is missing
[17:35] <jdstrand> zyga-ubuntu: done
[17:37] <niemeyer> mvo: Can we merge #3830 or do we need to wait for the autopkgtests?
[17:37] <mup> PR #3830: tests: deal with __PNR_chown on aarch64 to fix FTBFS on arm64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3830>
[17:39] <zyga-ubuntu> jdstrand: strict mode with logging?
[17:39] <zyga-ubuntu> jdstrand: are you referring to using the real strict template
[17:39] <jdstrand> zyga-ubuntu: yes. the point of partial is to let apparmor mediate what it can for whatever kernel is running, and logging what it can't
[17:39] <zyga-ubuntu> jdstrand: and logging == devmode?
[17:39] <jdstrand> no
[17:39] <zyga-ubuntu> ahh
[17:39] <zyga-ubuntu> right
[17:40] <zyga-ubuntu> so about that
[17:40] <zyga-ubuntu> (now that I understand the question)
[17:40] <jdstrand> cause,in my mind, classic confinement != partial confinement
[17:41] <jdstrand> just like devmode != partial confinement
[17:41] <jdstrand> maybe I misunderstand where you are going?
[17:42] <zyga-ubuntu> (call)
[17:45] <zyga-ubuntu> re
[17:45] <zyga-ubuntu> jdstrand: I plan to switch to the normal template and see what happens in practice, if snaps using particular interface misbehave. I'm not very scientific abut this yet
[17:45] <zyga-ubuntu> jdstrand: my goal is to enable enforcing confinement to all the features that the kernel offers
[17:46] <zyga-ubuntu> jdstrand: and, if necessary, insert compatibility permissions so that apps operate
[17:46] <jdstrand> zyga-ubuntu: ok, good, that is what I understood to be where you were going
[17:46] <jdstrand> yep, +1
[17:46] <zyga-ubuntu> jdstrand: (as I recall some things changed behavior as specific features were introduced)
[17:46] <zyga-ubuntu> jdstrand: I'm mainly doing this because I spend most of my time on opensuse
[17:46] <jdstrand> we can do in the interfaces, if partial append(...)
[17:47] <zyga-ubuntu> jdstrand: and also as a way to have distros on vanilla 4.14 LTS supported to the extent possible
[17:47]  * jdstrand nods
[17:47] <jdstrand> +1
[17:47] <zyga-ubuntu> jdstrand: yep, the way I coded it now is that we can see specific features
[17:47]  * jdstrand nods
[17:47] <zyga-ubuntu> jdstrand: so that we can be smarter than just "partial vs full"
[17:47] <jdstrand> yeah
[17:47] <zyga-ubuntu> great, sorry about being confused, tired from the trip and general chaos today :)
[17:47] <jdstrand> I was going to correct myself, but then thought it hard to quickly write the pseudo code for that :)
[17:48] <zyga-ubuntu> jdstrand: and also had a call from family to interrupt at the "best" moment :)
[17:48] <jdstrand> they have a tendency to do that. hope everything is ok and the chaos diminishing
[17:48] <zyga-ubuntu> yes, all is very good :)
[17:49] <zyga-ubuntu> we're together and safely heading home
[17:49] <jdstrand> nice
[17:52] <nacc> is it possible to do a local cleanbuild using a specific container image?
[17:54] <zyga-ubuntu> mvo: my kids go to local school on Monday :)
[17:54] <zyga-ubuntu> mvo: we'll finally wake up at 6:00 :)
[18:00] <bschaefer> hey, getting a fun install error on my raspi3: snap install mir-libs --edge
[18:00] <bschaefer> error: cannot install "mir-libs": snap type unset
[18:00] <zyga-ubuntu> bschaefer: interesting
[18:00] <zyga-ubuntu> bschaefer: can you run "snap version"
[18:00] <bschaefer> zyga-ubuntu, http://paste.ubuntu.com/25433361/
[18:00] <bschaefer> i tried a refresh but was all up to date
[18:00] <zyga-ubuntu> that's good
[18:01] <bschaefer> was working yesterday, so was figuring an auto update possibly
[18:01] <bschaefer> or some state got stuck somewhere
[18:01] <ogra_> snap changes
[18:01] <ogra_> ... should tell you
[18:01] <bschaefer> https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapmgr.go#L143
[18:01] <zyga-ubuntu> bschaefer: yes, perhaps
[18:01] <zyga-ubuntu> I don't have a way to download that revision now
[18:01] <zyga-ubuntu> I'd love to see the snap.yaml file from mir-libs from edge from armhf
[18:01] <zyga-ubuntu> in case anyone from store side can provide that
[18:02] <bschaefer> zyga-ubuntu, i can install local *.snaps
[18:02] <bschaefer> i can try any package from the store if you want
[18:02] <bschaefer> was happening with mir-kiosk as well
[18:02] <zyga-ubuntu> bschaefer: aha
[18:02] <ogra_> is your SD full ? :)
[18:03] <bschaefer> ... /me checks syslog
[18:03] <ogra_> df -h /writable
[18:03]  * zyga-ubuntu finishes update to arftul
[18:03] <bschaefer> /dev/mmcblk0p2  3.6G  680M  2.7G  21% /writable
[18:03] <zyga-ubuntu> upstart is being removed :'(
[18:03] <bschaefer> hmm seems happy
[18:03] <bschaefer> though it actually failed to install the local snap
[18:03] <ogra_> yeah, just to make sure
[18:03] <zyga-ubuntu> what do you see in snap changes (ogra's idea is good!)
[18:03]  * bschaefer digs around syslog
[18:04] <bschaefer> umm
[18:04] <bschaefer> Aug 30 17:54:32 localhost kernel: [    5.716015] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities
[18:04] <bschaefer> Aug 30 17:54:32 localhost kernel: [    5.736041] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[18:04] <ogra_> yeah,
[18:04]  * zyga-ubuntu reboots
[18:04] <zyga-ubuntu> I *hope* to see you soon
[18:04] <ogra_> way to noisy ...
[18:04] <ogra_> (not an issue)
[18:04] <bschaefer> o ok
[18:04] <bschaefer> :)
[18:05] <ogra_> the ext4 driver supports ext2 and  too
[18:05] <ogra_> it loops over the features when mounting an fs
[18:05] <ogra_> and prints that crap ... and eventually mounts ext4
[18:06] <bschaefer> ogra_, hmm yeah i dont see any yelling about full or ... anything
[18:06] <bschaefer> though this log is always large :)
[18:06] <ogra_> no, if df is happy everything should
[18:06] <bschaefer> yeah and AlbertA has it working on a raspi3 with same version
[18:07] <ogra_> samy snapd too ?
[18:07] <bschaefer> sooo im thinking ... something is going on with my image
[18:07] <bschaefer> yeah
[18:07] <ogra_> *same
[18:07] <mvo> cachio_: thank you!
[18:07] <mvo> niemeyer: yeah, merged it now
[18:07] <mup> PR snapd#3830 closed: tests: deal with __PNR_chown on aarch64 to fix FTBFS on arm64 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3830>
[18:08] <mup> PR snapd#3825 closed: tests: add nmcli regression test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3825>
[18:10] <bschaefer> ogra_, 119  Done    2017-08-30T17:38:21Z  2017-08-30T17:41:17Z  Refresh snaps "core", "pi2-kernel"
[18:10] <bschaefer> was the last refresh
[18:10] <bschaefer> (besides me messing with interfaces/connects)
[18:11] <ogra_> both should be fine
[18:11] <ogra_> (didnt break here on my pi2 (my 3 is off atm) )
[18:11] <bschaefer> ogra_, well since AlbertA image is working im just going to reflash
[18:11] <bschaefer> unless you want any more debug info off it :)
[18:12] <ogra_> perhaps zyga would ...
[18:12] <bschaefer> yeah i can wait a bit
[18:12] <ogra_> well, he just did a dist-upgrade to artful ... i'D set a time limit :)
[18:12] <ogra_> heh
[18:12] <bschaefer> haha
[18:12] <ogra_> speaking of the devil
[18:12] <zyga-ubuntu> so
[18:12] <bschaefer> ive yet to do that, been meaning to
[18:12] <zyga-ubuntu> that worked
[18:12] <zyga-ubuntu> but network-manager still crashes on my modem
[18:13]  * ogra_ builds to many snaps ... i stay on xenial 
[18:13] <bschaefer> well thats good news, as ive been planning on going to artful this weekend
[18:13] <bschaefer> zyga-ubuntu, so fun, AlbertA has a raspi3 with all the same versions
[18:13] <bschaefer> and he is just fine installing snaps
[18:13] <ogra_> i have a pi2 here with the same setup/versions too .. no issues
[18:14] <zyga-ubuntu> bschaefer: I'm happy to debug this tomorrow
[18:14] <bschaefer> zyga-ubuntu, cool yeah i can keep this SD around. Want to make sure you get any debug info out you want
[18:14] <zyga-ubuntu> bschaefer: but today my working conditions are ... unusual, and I need to do three releases for different distros
[18:14] <zyga-ubuntu> thank you!
[18:14] <bschaefer> yup no worries, i can use a different SD card for work atm and reflash
[18:14] <bschaefer> np, and thank you!
[18:17] <zyga-ubuntu> I'll ask around gnome developers tomorrow
[18:17] <zyga-ubuntu> maybe someone will know how to debug
[18:19] <mvo> zyga-ubuntu: uh, 6:00am - sounds like fun (not!)
[18:26] <niemeyer> mvo: Thanks!
[18:42] <arm1e> ogra_: sorry, wasputting toddler to bed. it's not my snap, just one from github, but it ran  fine in a previous build. Should all of the snap folders (prime, snap etc,) have contents once it has built successfully?
[19:07] <arm1e> Can someone please tell me if they can get this to build correctly so that I know if it is my setuo that is the issue: https://github.com/jacobzimmermann/gnucash-jz-snap
[19:07] <arm1e> Thanks
[19:07] <arm1e> (Not my snap, just want to try it)
[19:10] <nacc> arm1e: so ... the error message you got
[19:10] <arm1e> nacc: yup
[19:10] <nacc> arm1e: that snapcraft.yaml has a install entry
[19:10] <nacc> arm1e: which does the rm
[19:10] <nacc> arm1e: possibly that line (109) needs updating if that binary has moved, isn't used, etc
[19:12] <arm1e> nacc: Not much I can do then, other than to wait for it to be fixed
[19:12] <nacc> arm1e: you can fork and fix it yourself :)
[19:12] <arm1e> I dont know how to
[19:12] <arm1e> fix, not fork
[19:13] <nacc> arm1e: ah ok
[19:15] <arm1e> nacc: Ok, looking at the build, it is the staging directory that has that file in usr/sbin/
[19:15] <arm1e> nacc: the file is there, so why wont it delete?
[19:16] <nacc> arm1e: i don't know, and i don't know why it's done that way
[19:16] <nacc> arm1e: but you coudl make it `rm -f` and it would not fail anymore
[19:17] <arm1e> will try
[19:21] <arm1e> nacc: might have worked!
[19:25] <arm1e> nacc: Right, a;; snapped up and ready to test!
[19:28] <arm1e> nacc: Error, cannot find signatures with metadata for snap
[19:30] <arm1e> nevermind, found the option to force the install
[19:34] <nacc> arm1e: nice
[19:34] <arm1e> yeah, but wont run after installed. Nothing happens
[19:34] <arm1e> oh well
[19:34] <mup> PR snapcraft#1518 opened: project: introduce build-snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1518>
[19:37] <arm1e> nacc: Will wait for a fix. Thanks for your help
[19:37] <jdstrand> willdeberry: hi! you probably saw this, but fyi, I commented on https://github.com/snapcore/snapd/pull/3812
[19:37] <mup> PR #3812: interfaces: expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
[19:37] <jdstrand> willdeberry: it is really close now
[19:49] <willdeberry> jdstrand: got out of meeting and noticed. just submitted an updated revision :)
[19:55] <jdstrand> willdeberry: one last small thing
[19:55] <jdstrand> willdeberry: s/s.appSlot/s.coreSlot/ for the udev on classic test
[19:55] <jdstrand> (see the PR)
[19:59] <willdeberry> rgr
[20:00] <willdeberry> stupid miss by my part. all fixed though
[20:02] <jdstrand> willdeberry: ok, approved. thanks!
[20:03] <willdeberry> glad I was able to figure it out. honestly thought it was going to end up being one of those things you post on the forum and twiddle your thumbs while someone else fixed lol
[20:09] <jdstrand> hehe
[20:09] <jdstrand> :)
[20:09] <jdstrand> you took control of the situation :)
[20:18] <willdeberry> with a lot of help from you and others. definitely much appreciated
[20:21] <jdstrand> willdeberry: np, my pleasure
[20:32] <willdeberry> the tests do take a crazy amount of time to run i've noticed
[21:38] <mup> PR snapcraft#1516 closed: lxd: LXD not installed when using remote <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1516>
[21:45] <mup> PR snapd#3573 closed: overlord: always try to get a serial, lazily on classic <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3573>
[21:56] <davidcalle> sergiusens: elopio: following the build-snaps PR, an issue or PR for https://github.com/CanonicalLtd/snappy-docs/blob/master/build-snaps/syntax.md will be appreciated, thanks!
[21:57] <sergiusens> davidcalle: sure, but you owe me an answer wrt the tour ;-)
[21:58] <davidcalle> sergiusens: oh, I didn't replied? With fire, kill it with fire ;-)
[21:58] <sergiusens> my eyes are pleased to read that!
[23:22] <Pharaoh_Atem> niemeyer: here it is: https://forum.snapcraft.io/t/proposal-move-to-more-granular-architecture-names-for-snaps/1916