[03:46] <mup> PR snapd#3857 opened: tests: fix lxd test for external backend  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3857>
[05:13]  * Son_Goku grumbles
[05:13] <Son_Goku> somehow, I just woke up at 1am :(
[05:13] <Son_Goku> so... morning, I guess
[05:41] <mvo> mwhudson: hey, thanks for helping with the ppc64el link error. do you know if there is any workaround?
[05:41] <mvo> mwhudson: this is a blocker for 2.28 currently and I wonder what options there are
[06:32] <mvo> mwhudson: nevermind, I think I found a workaround
[06:39] <mup> PR snapd#3858 opened: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/pull/3858>
[06:49] <zyga-ubuntu> o/
[06:52] <Son_Goku> meep
[06:54] <Son_Goku> you know, I *really* don't like how go does compiler flags
[06:54] <Son_Goku> it's a really dumb way to do things
[06:55] <mvo> good morning Son_Goku (not actually morning for you I guess ;)
[06:55] <mup> PR snapd#3841 closed: Do not emit cloud-init.disabled; cloud-init only runs if datasource is present <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3841>
[06:55] <mvo> and good morning to you zyga-ubuntu
[06:55] <Son_Goku> [01:12:33 AM] Son_Goku	grumbles
[06:55] <Son_Goku> [01:12:40 AM]  <Son_Goku>	somehow, I just woke up at 1am :(
[06:55] <Son_Goku> [01:12:53 AM]  <Son_Goku>	so... morning, I guess
[06:55] <Son_Goku> :/
[06:56] <Son_Goku> this is what I get for going to sleep at 8:30pm
[06:57] <mvo> Son_Goku: autsch!
[06:57] <mvo> Son_Goku: that is going to be a coffee fueled day then :)
[06:57] <Son_Goku> I was feeling pretty bad yesterday, so I took some Advil (headache medicine) and went to sleep
[06:57] <Son_Goku> much earlier than I usually do
[06:57] <Son_Goku> yeah, I might wind up drinking coffee today
[06:57] <Son_Goku> I usually don't...
[07:00] <mvo> Son_Goku: aha, yeah. hope you make it well through the day, I get cranky when I did not sleep enough
[07:00] <Son_Goku> well, my work day begins in 6 hours
[07:00] <Son_Goku> at which point, I'm going to be tired as hell
[07:00] <mvo> yeah :)
[07:00] <mvo> zyga-ubuntu: some easy reviews tagged with 2.28 *hint* ;)
[07:01] <Son_Goku> mvo, not having pie across the board for snapd 2.28 kind of sucks, though
[07:02] <mvo> Son_Goku: its just for two small helpers
[07:02] <Son_Goku> snapd is made up of "small helpers" :P
[07:02] <mvo> Son_Goku: and if you have !go1.7 you can simply reomove it
[07:02] <Son_Goku> I wonder if this is even broken on Fedora 25 for ppc64le
[07:02] <Son_Goku> we have go 1.7 there too
[07:03] <mvo> Son_Goku: 2.28 probably is, 2.27 had a slightly different cflags/ldflags iirc for snap-seccomp
[07:04] <zyga-suse> good morning :)
[07:04] <Son_Goku> hmm
[07:04] <zyga-suse> mvo: I'll have a look
[07:04] <Son_Goku> 1.7.4 ~ 1.7.6
[07:04] <Son_Goku> I guess there's only one way to find out...
[07:06]  * Son_Goku logs into Fedora ppc64le test machines
[07:07] <zyga-ubuntu> mvo: please check out https://github.com/snapcore/snapd/pull/3854#pullrequestreview-60818594
[07:07] <mup> PR #3854: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3854>
[07:07] <zyga-ubuntu> mvo: I need a re-review from jamie on https://github.com/snapcore/snapd/pull/3621 and I need to fix one opensuse packaing quirk (still fighting natively) and with merged master it should go green
[07:07] <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>
[07:08] <zyga-ubuntu> mvo: but since it is tagged for 2.28, could you please have a look?
[07:08] <zyga-ubuntu> mvo: note that we must wait for jdstrand's review for the child profile
[07:08] <zyga-ubuntu> mvo: so if you want to release earlier, please drop it from the release
[07:10] <mvo> zyga-ubuntu: I dropped it, I am happy to review but unfortunately it missed the 2.28 cycle
[07:10] <mvo> zyga-ubuntu: I replied to 3621
[07:12] <Son_Goku> mvo, I'm running through a test build of current master on Fedora 25 ppc64le
[07:12] <Son_Goku> which has golang 1.7.6
[07:12] <mvo> Son_Goku: nice
[07:20] <Son_Goku> man... ppc64le is slow
[07:21] <zyga-suse> ok
[07:21] <zyga-suse> Son_Goku: it has to be, there is only one machine on the whole planet, everything else is virtualzed and over-committed ;-)
[07:21] <Son_Goku> haha
[07:22] <Son_Goku> you're probably not far off from the truth
[07:22] <Son_Goku> at least I'm not debugging arm crap
[07:22] <Son_Goku> I hate doing that
[07:22] <Son_Goku> arm SoCs are even slower
[07:23]  * zyga-suse just had a brilliant business idea
[07:24]  * Son_Goku shoots the light bulb over zyga-suse's head
[07:24] <zyga-suse> in some future where everything is running on one big machine, to sustain old business models we will still pay for traffic from A to B even though A is B,
[07:24] <Son_Goku> oh god
[07:24] <Son_Goku> I didn't shoot it fast enough
[07:25] <zyga-suse> maybe we need a payasyougo.ko to track this
[07:25] <Son_Goku> oh god damnit
[07:25] <Son_Goku> someone switched the import path for cheggaaa/pb
[07:26] <zyga-suse> yeah, it got switched to the canonical path
[07:26]  * Son_Goku groans
[07:27] <Son_Goku> zyga-suse, file a bug against the fedora cheggaaa/pb package
[07:27] <Son_Goku> it needs the gopkg.in import path supported
[07:28] <zyga-suse> ok, what should the bug report say?
[07:28] <zyga-suse> just "please support the canonical import path via gopkg.in"?
[07:29] <Son_Goku> yeah
[07:29] <zyga-suse> hmm, I seem to have plenty of stale kernels
[07:30] <zyga-suse> Son_Goku: ok, let me try to report that
[07:30] <Son_Goku> describe what the new import path is, and why we need it added (snapd 2.28 requires it)
[07:30] <zyga-suse> ok
[07:35] <zyga-suse> Son_Goku: for rawhide?
[07:36] <Son_Goku> mark the fedora release as rawhide, but ask for it to be added for all releases the package is provided for in the bug report
[07:37] <zyga-suse> ok
[07:37] <Son_Goku> poor Jan
[07:37] <Son_Goku> he just updated cheggaaa/pb, too
[07:37] <pedronis> mvo: hi, thanks for the review of the overlord.Mock PR
[07:39] <Son_Goku> mvo: snapd git master compiles just fine today with Fedora 25 golang 1.7.6
[07:40] <zyga-suse> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1488747
[07:41] <Son_Goku> I'm surprised Fedora tests haven't started failing
[07:41] <Son_Goku> or maybe they have and no one said anything
[07:42] <Son_Goku> if that's the case, why bother having the tests... :(
[07:43] <pedronis> mvo: #3727 seems to have a real unit tests issue now, probably related to some recent merge to master
[07:43] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[07:45] <Son_Goku> oh geez
[07:45] <Son_Goku> it worked somehow
[07:46] <Son_Goku> oh, no
[07:46] <Son_Goku> let me guess
[07:46] <Son_Goku> zyga-suse: are we giving a vendorized tarball to the snapd build in Fedora?
[07:46] <zyga-suse> I don't think we do
[07:46] <zyga-suse> (especially because that progress bar package was older in fedora and had UI corrputions)
[07:46] <zyga-suse> *corruptions
[07:47] <zyga-suse> and this was fixed in subsequent commits upstream
[07:47] <Son_Goku> I mean in spread
[07:47] <zyga-suse> in spread yes, we do
[07:47] <Son_Goku> FUCK
[07:47] <Son_Goku> damn it
[07:48] <Son_Goku> the damned build tests are useless then
[07:48] <pedronis> that is bound to be always helpful
[07:48] <pedronis> *to not be
[07:48] <Son_Goku> okay, then I need to break this
[07:49] <Son_Goku> crap, this means I need to make it so patches apply cleanly with the vendor tarball
[07:49] <Son_Goku> no one notices when builddeps are missing because of the stupid usage of vendor stuff
[07:50] <zyga-suse> Son_Goku: indeed, that's a real problem
[07:50] <zyga-suse> Son_Goku: our debian build suffers from the same thing
[07:51] <Son_Goku> actually, I can just rm -rf vendor/* in %prep, I suppose
[07:51] <Son_Goku> minus the vendor.json
[07:51] <zyga-suse> Son_Goku: I think even with the vendor json, nothing needs that (just don't run get-deps)
[07:51] <mvo> pedronis: thanks, checking
[07:51] <Son_Goku> zyga-suse: remember that I need to be able to apply patches
[07:52] <Son_Goku> and I'd like to not have to edit patches more than I already have to when backported
[07:52] <Son_Goku> *backporting
[07:52] <Son_Goku> it was somewhat annoying to backport userd to 2.27.5, but I did
[07:52] <zyga-suse> what's the experience, does it work?
[07:52] <Son_Goku> you tell me
[07:53] <Son_Goku> the updates are sitting in bodhi right now
[07:53] <Son_Goku> well, koji
[07:53] <Son_Goku> for some reason they haven't made it to updates-testing yet
[07:53] <mvo> Son_Goku: hm, zesty has go 1.7.4 wonder if thats related but aiui only 1.8 fixes the issue, I will dig
[07:54] <Son_Goku> mvo: https://src.fedoraproject.org/rpms/golang/tree/f25
[07:54] <Son_Goku> that should help
[07:55] <zyga-suse> Son_Goku: how should I remove stale kernels from my fedora box?
[07:55] <Son_Goku> did you change /etc/dnf/dnf.conf for installonlypkgs limit?
[07:55] <Son_Goku> it should be set to 3 by default
[07:56] <zyga-suse> rebooting
[07:56] <zyga-suse> something broke so I booted into the recovery kernel and updated
[07:56] <zyga-suse> and ...
[07:56] <zyga-suse> the logo ...
[07:57] <zyga-suse> and...
[07:57] <zyga-suse> the same
[07:57] <zyga-suse> I'll leave it for 5 minutes in case it's some timeut
[07:57] <zyga-suse> but it looks broken :/
[07:58] <Son_Goku> ~_~
[07:58] <Son_Goku> if it's Fedora 26 or newer, then `dnf install dnf-utils; package-cleanup --oldkernels --count=3`
[07:59] <Son_Goku> Fedora 25 and older will require you to actually do the work yourself :P
[08:00] <zyga-suse> fedora 26
[08:00] <zyga-suse> but broken at boot, let me try recovery again
[08:12] <mup> PR snapd#3859 opened: packaging/fedora: Ensure vendor/ is empty for builds <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3859>
[08:12] <Son_Goku> zyga-suse: there ^
[08:13] <Son_Goku> if spread isn't failing after we do this, then there's a problem
[08:14] <davidcalle> pstolowski: did you remotely access my machine last night? Because it's working now o_o
[08:14] <mvo> davidcalle: maybe he did (automatic snap refresh maybe?)
[08:17] <davidcalle> mvo:  doesn't look like it, I had install hooks failing 100% of the time. On stable core, artful snapd, so no recent changes on this front afaik... Unless another snap was messing with everything
[08:17] <davidcalle> mvo: anyway, bug seems to be fixed, so...
[08:21] <davidcalle> pstolowski: just confirmed that the install hook was being called as expected, thanks for the help
[08:22]  * zyga-suse walks daughter to school
[08:28] <pedronis> is Chipaca off today?
[08:33] <pstolowski> davidcalle, waaat
[08:33] <pstolowski> :)
[08:36] <pstolowski> davidcalle, fyi, I investigated it further yestaerday's evening / this morning.. your state.json didn't show any apparent problem, only confirmed the issue (the error you saw was there). the only *theoretical* explanation I had was that for whatever reason an old version of snap-exec was used (as judging from the error message, snap-exec didn't know about install hooks). but since you didn't disable reexec, I'm clueless...
[08:38] <pstolowski> pedronis, hey, are you familiar with CommandManager / cmdstate?
[08:39] <pedronis> pstolowski: I think I might have reviewed it, what's the question?
[08:41] <pstolowski> pedronis, for some reason in a spread test I'm hitting timeout (which is very generous), as if change wasn't set to ready after finished - https://github.com/snapcore/snapd/pull/3852/files#diff-8c0b309b451b46cd7f7dac1f80654270R113  ; this is working fine in unit test where I'm not actually executing command, but mocking it and set change to ready explicitely
[08:41] <mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
[08:47] <pstolowski> pedronis, perhaps there is something about taskrunner / changes that I do not know or misunderstand
[08:47] <zyga-suse> re
[08:47] <pstolowski> but afaiu it should be set ready automatically when tasks are finished
[08:48] <ogra_> zyga-suse, hmm, what changed in snap-confine ? seems a lot of users get "cannot locate the base snap: ubuntu-core: No such file or directory" ... grepping the source i only see this message in snap-confine/mount-support.c
[08:49] <ogra_> (there are at least three threads on the forum wherre this seems to be an issue)
[08:50] <zyga-suse> ogra_: hmmmm
[08:50] <zyga-suse> ogra_: it's a small patch that landed that lets people use an alternate base snap as an opt-in
[08:50] <ogra_> i assume it isnt snap-confine itself but smething hands it "ubuntu-core"
[08:50] <zyga-suse> mvo: ^
[08:50] <pedronis> pstolowski: you are keeping the lock in  runServiceCommand, how can anything else run?
[08:50] <zyga-suse> ogra_: ooh
[08:50] <zyga-suse> ogra_: ubuntu-core you say
[08:50] <ogra_> well, read the error above :)
[08:51] <zyga-suse> right, I see now
[08:51] <zyga-suse> that is ... curious
[08:51] <ogra_> whats even more curious is that some users in these threads show snap list with core 16-2.26.14
[08:52] <pedronis> pstolowski: I don't what's happenign in your tests but for sure that code doesn't look right
[08:52] <ogra_> (though that might just be a rre-exec thing ... running a newer deb version)
[08:52] <pedronis> pstolowski: I mean all lock mgmt in runServiceCommand seems off
[08:53] <pstolowski> pedronis, ahh, thanks
[08:53] <pedronis> pstolowski: seems you are mocking too much
[08:53] <pedronis> btw
[08:54] <pedronis> that's probably related to why the tests fowkrs
[08:55] <zyga-suse> ogra_: core 2.26.14 with snapd 2.27.4
[08:55] <ogra_> yeah
[08:55] <zyga-suse> ogra_: but that's not possible on debian stable, it must be sid
[08:55] <ogra_> because the stable core wasnt updated yet
[08:55]  * zyga-suse booted debian 9
[08:55] <zyga-suse> ogra_: it was, last night AFAIR
[08:56] <ogra_> yup
[08:56] <ogra_> ogra@anubis:~/datengrab/devel/branches/snapd$ snap info core|grep stable
[08:56] <ogra_>   stable:    16-2.27.5                (2774) 85MB -
[08:56] <ogra_> i stand corrected
[08:56] <zyga-suse> yes
[08:56] <ogra_> but that user didnt have it :)
[08:56] <ogra_> (refresh can take up to 24h iirc)
[08:56] <ogra_> (depending on the timers)
[08:57] <zyga-suse> I'm reading https://forum.snapcraft.io/t/castersoundboard-snap-requires-deprecated-ubuntu-core/1999
[08:57] <zyga-suse> here the user did have 2.27.4
[08:57] <ogra_> theer is also https://forum.snapcraft.io/t/call-for-testing-warzone-2100/2001/4
[08:57] <zyga-suse> so that's definitely a debian unstable
[08:57] <ogra_> and cjwatson's LXD build announcement
[08:57] <ogra_> (and i think i saw it once more but i cant find it)
[08:59] <pedronis> pstolowski: maybe you want to give a look at #3856 , it might be useful for your tests there
[08:59] <mup> PR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
[09:00] <ogra_> zyga-suse, oh ... same thing but different https://forum.snapcraft.io/t/cannot-locate-core-snap-error/884
[09:03] <pedronis> Chipaca: hi
[09:03] <Chipaca> pedronis: o/
[09:03] <pstolowski> pedronis, ack, thanks.
[09:04] <pedronis> Chipaca: #3727 and #3856 could use 2nd reviews
[09:04] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[09:04] <mup> PR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
[09:05] <zyga-suse> mvo: I forsee 2.27.6
[09:05] <ogra_> yeah :/
[09:05] <Chipaca> pedronis: ack
[09:05] <Chipaca> zyga-suse: :'(
[09:07] <Chipaca> does the travis log loading bog down your whole browser, or is my laptopt showing its age?
[09:08] <Chipaca> if I wait for it to load it's multiple minutes; even getting to click the static log button takes a few seconds (the static logs load almost instantly)
[09:08] <pedronis> it takes kind of forever
[09:12] <zyga-suse> Chipaca: it's travis + javascript suxxines
[09:12] <Chipaca> or maybe our logs are too verbose :-D
[09:12] <pedronis> zyga-suse: spread on opensuse seems broken because of an actual issue in the scripts
[09:12] <pedronis> + go install -s -v -p 4 -x macro doesnt allow us to pass any additional parameters '#' so we we have to invoke '`go' 'install`' here manually. export GOPATH=/usr/src/packages/BUILD/go:/usr/lib64/go/contrib export GOBIN=/usr/src/packages/BUILD/go/bin '#' Options used are the same as the /usr/lib/rpm/golang.sh build macro does but as it '#' doesnt allow us to amend new flags we have to repeat them github.com/snapcore/snapd/
[09:12] <pedronis> here:
[09:12] <ogra_> Chipaca, use lynx :P
[09:12] <pedronis> can't load package: package macro: cannot find package "macro" in any of:
[09:13] <zyga-suse> pedronis: where? can you give me a link to the failure please?
[09:13] <pedronis> zyga-suse: here for example: https://travis-ci.org/snapcore/snapd/builds/272361316?utm_source=github_status&utm_medium=notification
[09:13]  * zyga-suse looks
[09:13] <pedronis> seems like a comment ends up as data
[09:14] <zyga-suse> pedronis: I'm debugging something similar right now, it's the %gobuild macro that is really both go build and go install
[09:14] <zyga-suse> pedronis: I'm looking for a solution
[09:14] <zyga-suse> pedronis: (note that this only affects opensuse)
[09:14] <pedronis> how did it make to master?
[09:15] <zyga-suse> pedronis: how was this merged
[09:15] <zyga-suse> pedronis: good question, my branch that is affected has not landed yet
[09:15] <zyga-suse> pedronis: I'll check this out soon, looking at debian sid and possible regression
[09:15] <pedronis> zyga-suse: mvo: master is broken like this :(
[09:16] <pedronis> how was it merged?
[09:16] <pedronis> or something has changed in suse itself?
[09:17] <zyga-suse> pedronis: nothing like that would change inside leap
[09:18] <pedronis> well master is red and broken
[09:18] <zyga-suse> sure
[09:18] <zyga-suse> I think it may be a commented-out macro
[09:18] <zyga-suse> macros cannot be commented out
[09:18] <zyga-suse> because of how rpm works
[09:18]  * zyga-suse looks quickly
[09:18] <pedronis> something doesn't compute here
[09:19] <pedronis> I how did it land either way?
[09:19] <zyga-suse> ogra_: interestingly, snapd in sid is not reexecing
[09:19] <zyga-suse> pedronis: no idea
[09:19] <ogra_> oh
[09:21] <pedronis> zyga-suse:  there's a comment like  this   in the spec:     # The %gobuild macro
[09:21] <pedronis> I suppose it gets interpreted anyway?
[09:21] <zyga-suse> I see
[09:21] <zyga-suse> though this didn't fail before
[09:21] <zyga-suse> I just removed them, let's make a quick PR
[09:22] <Son_Goku> zyga-suse, I feel like I should leave this broken: https://github.com/snapcore/snapd/pull/3859
[09:22] <mup> PR #3859: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3859>
[09:24] <zyga-suse> pedronis: I just made a PR, let's see what happens
[09:24] <mup> PR snapd#3860 opened: packaging: don't include any marcos in comments <Created by zyga> <https://github.com/snapcore/snapd/pull/3860>
[09:26] <pedronis> zyga-suse: seems definitely something that changed under our feet because those comments are still from Simon
[09:27] <zyga-suse> pedronis: I'll check changelogs
[09:32] <ogra_> huh ?
[09:32] <zyga-suse> ogra_: I cannot reproduce the issue, I'll report back but I suspect it's something funky on the reporter's machine
[09:32] <ogra_> how did 2.28 into beta ?
[09:32] <ogra_> *get into
[09:32] <zyga-suse> ogra_: mvo uploaded it
[09:32] <zyga-suse> ogra_: after 2.27.5 was stable
[09:33] <mvo> ogra_: its 2.28~rc1 fwiw
[09:33] <ogra_> why ?
[09:33] <ogra_> ah,
[09:33] <ogra_> it doesnt say -rc1
[09:33] <mvo> the thing that builds the versions cuts a but too aggressively it seems
[09:33] <ogra_> ah
[09:35] <mvo> zyga-suse: meh, do you have a handle on this issue already?
[09:36] <zyga-ubuntu> mvo: which of the recent ones?
[09:36] <mvo> ogra_: probably worth fixing, its slightly annoyying
[09:36] <ogra_> yeah, will confuse people
[09:36] <mvo> zyga-ubuntu: the name where snap-confine stops working for some people, that is rather criticial
[09:36] <zyga-ubuntu> mvo: not yet, I cannot reproduce it on debian 9 and sid
[09:36] <zyga-ubuntu> mvo: I asked for more information
[09:37] <mvo> zyga-ubuntu, pedronis: I would say we disable suse for the moment and deal with the other crisis first, ok?
[09:37] <zyga-ubuntu> mvo: and I'll check the code, what would trigger this
[09:37] <mvo> zyga-ubuntu: thanks a bunch - so all reports from debian so far?
[09:37] <zyga-ubuntu> mvo: technically it looks like snapd passes ubuntu-core as the name of the base snap
[09:37] <zyga-ubuntu> mvo: I sent a PR that might cure suse, if it fails I'll disable it
[09:38] <zyga-ubuntu> mvo: there are three reports, one is from debian "9" (but really sid apparently), the rest is unknown for now
[09:38] <mvo> zyga-ubuntu: ta
[09:39] <mup> PR core#55 closed: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core/pull/55>
[09:40] <mvo> zyga-ubuntu: thanks for the suse fix, interessting bug
[09:40] <zyga-ubuntu> mvo: not sure if that's really it
[09:40] <pedronis> mvo: it's rather mysterious
[09:40] <zyga-ubuntu> mvo: I was building suse package very often and I dind't hit this
[09:41] <mvo> zyga-ubuntu: it sounds likely
[09:41] <zyga-ubuntu> mvo: but my packaging is different and I'm on tumbleweed, not leap
[09:41] <mvo> zyga-ubuntu: yeah, like pedronis said, mysterious why it is happeing just now
[09:41] <zyga-ubuntu> mvo: I'll check in detail later, the core regression is more serious
[09:41] <mvo> zyga-ubuntu: +100
[09:41] <pedronis> from the logs is seems like it's running macros from inside the comments
[09:41] <zyga-ubuntu> mvo: golang packaging is being changed but I don't think those changes would be backported to leap
[09:41] <zyga-ubuntu> mvo: maybe I'm just wron
[09:41] <zyga-ubuntu> *wrong
[09:42] <zyga-ubuntu> I'll sync suse packaging later to see what's not in trunk
[09:42] <mvo> pedronis: yeah, this is what zyga-ubuntu fixed in his branch
[09:53] <mvo> zyga-ubuntu: are all reports from the same user?
[09:59] <zyga-suse> mvo: so far yes
[09:59] <zyga-suse> mvo: my suspicion is that something odd is going on on his machine
[10:00] <ogra_> zyga-suse, well, seems to be sid ...
[10:01] <zyga-suse> yes, it must be sid
[10:01] <ogra_> (surprise: unstable is unstable :) )
[10:01] <zyga-suse> because it has 2.27.4-1
[10:01] <zyga-suse> mvo: it looks like we append "info.Base"
[10:02] <zyga-suse> mvo: as base snap name
[10:04] <mvo> zyga-suse: yes, iirc if info.Base != ""
[10:04] <mvo> zyga-suse: which seems reasonable, no?
[10:06] <zyga-suse> yes
[10:07] <Son_Goku> unless you're re-execing?
[10:07] <Son_Goku> then it should break due to mismatch
[10:12] <mvo> zyga-suse: fwiw, I tried with my debian9 install and had no luck reproducing the issue
[10:12] <zyga-suse> same
[10:23] <brunch875> sep 06 12:11:36 magpie kernel: audit: type=1400 audit(1504692696.878:207): apparmor="DENIED" operation="open" profile="snap.hexchat.hexchat" name="/run/systemd/resolve/stub-resolv.conf" pid=6685 comm="hexchat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=102
[10:23] <brunch875> uh oh...
[10:59] <zyga-suse> heh, prune failed on ppc again
[10:59] <zyga-suse> I bet PPC has even weirder tick/scheduling
[11:00] <mup> PR snapd#3861 opened: interfaces: add NETLINK_KOBJECT_UEVENT to kernel-module-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/3861>
[11:01] <zyga-ubuntu> mvo: hmm, that feels ill-placed for that interface
[11:02] <zyga-ubuntu> mvo: I wonder if we are just missing an interface for something more specific
[11:02] <zyga-ubuntu> mvo: or if we should add a quirk system that lets us inject snippets for a specific snap
[11:02] <zyga-ubuntu> mvo: (ideally via store assertions)
[11:02] <zyga-ubuntu> mvo: so we could fix people in the wild
[11:02] <mvo> zyga-ubuntu: yeah, I agree. i asked jdstrand for suggestions
[11:02] <zyga-ubuntu> (though I don't think we refresh assertions, do we?)
[11:03] <pedronis> complexity, schmoplixity
[11:03] <pedronis> we can do a lot of stuff
[11:03] <pedronis> dont' know if more moving parts will save us in the end though
[11:03] <mvo> zyga-ubuntu: we could udisks2 or modem-manager or any of the kobject_uevent interfaes to livepatch
[11:03] <zyga-ubuntu> mvo: "add" I presume
[11:04] <zyga-ubuntu> pedronis: I think that for things like this
[11:04] <zyga-ubuntu> oh, why did my laptop quit?
[11:04] <zyga-ubuntu> for things like this, post-releaes issues wrt security
[11:04] <mvo> zyga-ubuntu: correct
[11:04] <zyga-ubuntu> it would be good to 1) fix existing specific snaps
[11:04] <zyga-ubuntu> and 2) create new interfaces and let people upgrade
[11:04] <zyga-ubuntu> (people=snap devs)
[11:04] <zyga-ubuntu> I think we broke many things when netlink mediation landed
[11:05] <zyga-ubuntu> because we started to reject things previously allowed
[11:05] <zyga-ubuntu> and then proceeded to samp the extra permissions in various places
[11:05] <pedronis> as I said we can do many things, but complexity is a proiblem in itself
[11:05] <zyga-ubuntu> pedronis: I don't disagree in any way :)
[11:05] <zyga-ubuntu> I think suse download servers are broken now
[11:06] <zyga-ubuntu> I see it both at home and on linode
[11:06] <pedronis> we don't even apply any of those kind of changes immediately, atm
[11:06] <pedronis> you need a new revno either way
[11:06] <zyga-ubuntu> I see
[11:10] <pedronis> I think we need interface hooks done before we add anything more in that area
[11:21] <zyga-suse> mvo: hey, noob question here: what can I monitor after dputting something to sid?
[11:23] <pedronis> zyga-suse: yes, suse servers seems down
[11:23] <pedronis> :/
[11:23] <pedronis> time to put it to manual until other fires are out I think
[11:23] <pedronis> given master is broken atm
[11:25] <zyga-suse> yes
[11:25]  * zyga-suse pushes branch
[11:25] <zyga-suse> FYI: https://status.opensuse.org/
[11:28] <zyga-suse> pedronis: ah, it seems we both did it
[11:28] <zyga-suse> btw, mup seems off/slow
[11:28] <pedronis> that kind of day
[11:28] <mup> PR snapd#3862 opened: spread.yaml: turn suse to manual given that it's breaking master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3862>
[11:28] <mup> PR snapd#3863 opened: spread: disable openSUSE on linode backend <Created by zyga> <https://github.com/snapcore/snapd/pull/3863>
[11:28] <zyga-suse> mvo: can you please merge one of the two instantly
[11:29] <Son_Goku> apparently fedoraproject.org DNS in Europe is having problems, too
[11:29] <Son_Goku> :)
[11:29] <zyga-suse> well
[11:29] <zyga-suse> it must be that kind of day then
[11:30] <zyga-suse> mvo: so are we doing 2.27.6?
[11:30] <pedronis> likely
[11:30] <zyga-suse> mvo: with fixes for canonical-livepatch
[11:30] <pedronis> I think we are waiting to discuss what's best with jdstran-d
[11:30] <zyga-suse> mvo: and whatever may be causing that ubuntu-core back-from-hell
[11:30] <zyga-suse> mvo: we could do a hack where we never pass ubuntu-core to snap-confine, and just change that to "core"
[11:31] <zyga-suse> mvo: I'm looking at theories why this could ever happen
[11:34] <zyga-suse> mvo: hmm, I think I know what may be going on
[11:36] <zyga-suse> mvo: my bet is that the reporter lost the current symlink
[11:36] <zyga-suse> pedronis: whatever the outcome it feels like we will have a new release
[11:51] <zyga-suse> mvo: I won though whatever took out /snap/core/current also blew everything else out of the water
[11:52] <zyga-suse> mvo: I'm worried that it might be some crazy upgrade script that does rm -rf /snap
[11:54] <pedronis> you mean in a classic snap?
[11:54] <pedronis> or somebody using such  a script on their system?
[11:54] <zyga-suse> I meant the upgrade script in debian (.postinst and such)
[11:54] <pedronis> or part of packaging?
[11:55] <zyga-suse> maybe there's some bug that causes it to run the prune code
[11:55]  * zyga-suse looks
[11:58] <pedronis> on ubuntu we just have postrm that rm things only on prune
[11:58] <pedronis> sorry, on purge
[11:59] <zyga-suse> right, but I think there's a delta with debian, looking at that now
[12:07] <pedronis> zyga-suse: I merged mine turn off suse given it got green
[12:07] <zyga-suse> ok
[12:07] <zyga-suse> please close the other
[12:08] <mup> PR snapd#3862 closed: spread.yaml: turn suse to manual given that it's breaking master <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3862>
[12:09] <mup> PR snapd#3863 closed: spread: disable openSUSE on linode backend <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3863>
[12:13] <zyga-suse> thank you
[12:14] <zyga-suse> the postrm script look sane
[12:16] <zyga-suse> pedronis, mvo: I wonder if the snap manager should ensure that all snap mount points exist and the units are mounted in its ensure loop
[12:16] <zyga-suse> having something like that would give us a healing system that would fix whatever has affected that particular user
[12:17] <zyga-suse> similarly to how snapd ensures security profiles are correct
[12:21] <pedronis> maybe, doesn't sound 2.27+ material
[12:22]  * zyga-suse break 
[12:29] <pedronis> mvo: #3727 needs a master merge
[12:29] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[12:30] <mvo> pedronis: sure, doing that now
[12:31] <mvo> zyga-suse: you should get an accept mail after dputing (sorry for the delay)
[12:34] <zyga-suse> mvo: no worries
[12:34] <zyga-suse> mvo: I got the mail (REJECTED, but that's another topic)
[12:34] <zyga-suse> mvo, pedronis: I think that after we fix what affects canonical-livepatch we *must* teach snapd to start any services that are stopped/broken
[12:34] <zyga-suse> as I bet the background service is broken on various running machines now
[12:35] <zyga-suse> and while the .6 update will fix it it would only auto-start on the next reboot, defeating the purpose
[12:37] <zyga-suse> Chipaca: ^
[12:38] <mvo> zyga-suse: we will update livepatch too (the snap)
[12:39] <ogra_> woah
[12:39] <ogra_> http://paste.ubuntu.com/25478060/
[12:39] <ogra_> do we never clean up when core gets updated ?
[12:41] <zyga-suse> mvo: that's another solution
[12:41]  * ogra_ wonders when users will start running out of inodes 
[12:42] <zyga-suse> ogra_: known bug, I think
[12:42] <ogra_> ah, k, then i wont file it ... looks shocking nontheless
[12:43] <zyga-suse> there's a bug open for hit
[12:43] <zyga-suse> for it*
[12:44] <mup> PR snapd#3861 closed: interfaces: add NETLINK_KOBJECT_UEVENT to kernel-module-control <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3861>
[12:44] <zyga-suse> mvo: is there any interface that allows just kobject uevent?
[12:45] <zyga-suse> mvo: if no let's add it to some netlink-kobject-uevent maybe and then patch the livepatch snap to use it
[12:46] <pedronis> I don't think that's the spirit, we don't have interfaces with so low granularity afaict
[12:47] <pedronis> anyway seems jdstrand is thinking/looking into this
[12:47] <jdstrand> let's not do that
[12:47] <jdstrand> mvo and I have a plan and a workaround for livepatch
[12:49] <mup> PR snapd#3864 opened: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>
[12:55] <zyga-suse> jdstrand: hey
[12:55] <zyga-suse> jdstrand: what is the plan?
[12:55] <jdstrand> that pr ^
[12:55] <jdstrand> zyga-suse: that achieves what you suggested in an existing interface. and that interface is the correct place for the policy
[12:55] <zyga-suse> jdstrand: thanks
[12:56] <zyga-suse> mvo: I commented on the PR, would love it if you could revise the commit message
[12:58] <mvo> zyga-suse: sure
[12:58]  * jdstrand thought the comment was clear (and commented on it)
[12:58] <jdstrand> but whatever you come up with is fine
[12:59] <mvo> ogra_: are those "just" empty mount points?
[12:59] <ogra_> mvo, i think so, let me check
[13:00] <ogra_> mvo, confirmed
[13:02] <zyga-ubuntu> Chipaca, pedronis: standup
[13:02] <Chipaca> omw
[13:12] <mup> PR snapcraft#1519 closed: lxd: use a unique temporary folder <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1519>
[13:20] <mvo> Son_Goku: fwiw, 2.27 has working base snaps, I would love to try this with your fedora work
[13:20] <mvo> Son_Goku: aiui you have a fedora base already :)?
[13:20] <Son_Goku> what do you mean, working base snaps?
[13:20] <Son_Goku> I have a script for making core/base snaps, yes: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap
[13:20] <Son_Goku> I stopped working it a while back because I can't test the output
[13:21] <ogra_> now you can
[13:21] <ogra_> :)
[13:38] <zyga-ubuntu> re
[13:39] <zyga-ubuntu> Son_Goku: I can explain
[13:39] <zyga-ubuntu> Son_Goku: but yes, we can now try
[13:39] <Son_Goku> I'm going to guess that my YAML needs to be different for the base snap
[13:41] <ogra_> needs to be base'ic ... (muhahaha)
[13:44] <pstolowski> davidcalle, hey, one more question re your issue and how it disappeared this morning - have you rebooted your box?
[13:46] <davidcalle> pstolowski: yes, I tend to reboot frequently, yesterday, the day before...
[13:46] <pstolowski> zyga-ubuntu, ^
[13:47] <zyga-ubuntu> pstolowski: so I know what the problem is IMO
[13:48] <zyga-ubuntu> pstolowski: I can revive a branch that fixes it and we can sit on the bug in apparmor that this exposes
[13:48] <mup> PR snapd#3642 closed: cmd/snap: get keys or root document <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3642>
[13:53] <pedronis> pstolowski: let me know if you want to have a step back chat about Plug/SlotData today or tomorrow ?
[13:53] <cachio_> mvo, I see this error https://paste.ubuntu.com/25478387/
[13:53] <cachio_> in most of the ubuntu cores
[13:53] <pstolowski> pedronis, sure, will let you know, probably tomorrow. thanks
[13:54] <pstolowski> zyga-suse, oh, so it goes deepeer
[13:54] <pstolowski> zyga-ubuntu, ^
[13:54] <zyga-ubuntu> pstolowski: it's pretty simple but the fix ran into a bug in the kernel
[13:54] <cachio_> I reproduced it
[13:54] <pstolowski> zyga-ubuntu, is this about namespaces?
[13:54] <zyga-ubuntu> pstolowski: the bug is from 2016
[13:54] <zyga-ubuntu> pstolowski: its open on LP
[13:54] <cachio_> mvo, but not sure it is a bug or not
[13:54] <Chipaca> zyga-ubuntu: 2016? psh, amateur :-p
[13:54] <cachio_> mvo, it is in the border line
[13:55] <pstolowski> zyga-ubuntu, why couldn't I reproduce it? and it was happening to davidcalle every day (till this morning)?
[13:55]  * zyga-ubuntu just had a very interesting question from tech-illiterate friend
[13:55] <zyga-ubuntu> pstolowski: I'll explain in a sec
[13:56] <zyga-ubuntu> question was: should I download amd64 or i386 build of ubuntu if I have a celeron procesor, he was going for i386 because his box is not amd
[13:56] <pstolowski> i'm glad though it's not a fundamental issue with install hook though
[13:56] <zyga-ubuntu> I wonder how many people use 32bit systems because of that
[13:56] <zyga-ubuntu> pstolowski: so the hook is in the core snap
[13:56] <zyga-ubuntu> pstolowski: which is the root fs
[13:57] <pstolowski> zyga-ubuntu, no, the hook is in a reguar snap
[13:57] <zyga-ubuntu> pstolowski: to reproduce have two revisions of a snap and two revisions of the core
[13:57] <zyga-ubuntu> pstolowski: (sorry, I meant snap-exec)
[13:57] <pstolowski> right
[13:57] <zyga-ubuntu> pstolowski: start on old-core and old-snap and run the snap (or any hook) so that we have a mount namespace
[13:57] <zyga-ubuntu> pstolowski: now refresh core to new-core (with new hook support in snap-exec) and refresh to new-snap
[13:58] <zyga-ubuntu> pstolowski: when core changes we don't have a mechanism for refreshing existing mount namespaces
[13:58] <zyga-ubuntu> pstolowski: the fix, even once my branch lands, won't always refresh it either
[13:58] <zyga-ubuntu> pstolowski: because we don't do it for valid reasons
[13:58] <zyga-ubuntu> pstolowski: a simple fix is to run snap-exec via ... and bare with me... /var/lib/snapd/hostfs/snap/core/current/usr/lib/snap-exec
[13:58] <zyga-ubuntu> pstolowski: because *that* will be always fresh
[13:59] <zyga-ubuntu> pstolowski: it should be a one liner in snap run and one liner in snap-confine.apparmor.in
[13:59] <zyga-ubuntu> pstolowski: try writing a case that reproduces this first
[13:59] <zyga-ubuntu> pstolowski: it's a very interesting bug
[13:59] <zyga-ubuntu> pstolowski: NOTE: it's sufficient to test a subset
[13:59] <zyga-ubuntu> pstolowski: stat snap-exec before and after core refresh
[13:59] <zyga-ubuntu> pstolowski: and if the inode is not changed, we are running the wrong one
[14:00] <zyga-ubuntu> pstolowski: if you can come up with a full test that would be nice but I think it's not really needed given how hard it is to set this up
[14:00] <zyga-ubuntu> pstolowski: as long as we run snap-exec via hostfs we're fine
[14:00] <zyga-ubuntu> pstolowski: one more thing is that new base snap support makes this more complex
[14:00] <zyga-ubuntu> pstolowski: but I think bases need to have hostfs so the fix is universal
[14:00] <zyga-ubuntu> pstolowski: that's all
[14:00] <zyga-ubuntu> mvo: ^
[14:01]  * zyga-ubuntu returns to 14.04 debugging
[14:01] <mvo> zyga-ubuntu: uh, interessting
[14:03] <pstolowski> zyga-ubuntu, wow, that's interesting bug indeed. thanks for explanation! I need to copy it somewhere..
[14:09] <mvo> a second review for 3854 would be great (should be trivial)
[14:11]  * zyga-ubuntu looks
[14:12] <Chipaca> mvo: question: why use mockCommand, instead of mocking SystemctlCmd?
[14:12] <zyga-ubuntu> ah, I already did
[14:12] <Chipaca> mvo: another question: why aren't i asking this in the PR?
[14:12] <zyga-ubuntu> mvo: thank you for the explanation
[14:12] <mup> PR snapcraft#1531 opened: Release changelog for 2.34 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1531>
[14:12] <Chipaca> ah, corecfg
[14:12] <Chipaca> ah
[14:12] <mvo> Chipaca: I guess corecfg actually would need some work to do it this way, might not be a bad idea to convert it
[14:13]  * zyga-ubuntu had an idea to have a way for a given module to offer to mock itself out
[14:13] <zyga-ubuntu> so that we don't have to know how to mock internal details in tests of something else that just happen to use the public API of that first thing
[14:14] <Chipaca> mvo: corecfg is already using systemd.SystemctlCmd
[14:14] <Chipaca> zyga-ubuntu: ^
[14:14] <Chipaca> it's not doing its own exec
[14:14] <zyga-ubuntu> Chipaca: sure but there's no way to say <module>.MockEverythingExternal()
[14:14] <zyga-ubuntu> Chipaca: so if <other> uses <module> it needs to know too much in its tests
[14:15] <zyga-ubuntu> ideally this would be exposed for tests in the public api but not clutter the real public api
[14:15] <zyga-ubuntu> I think that's hard in go
[14:15] <Chipaca> zyga-ubuntu: so you're saying that knowing the details of the implementation of something, and mocking one of the details, is better than knowing the API that thing exposes and using that in your tests?
[14:15] <pedronis> Chipaca: mvo: seems to be doing both
[14:16] <Chipaca> pedronis: where's it calling systemctl itself?
[14:16] <pedronis> it's also using  s.coreCfgSuite.SetUpSuite(c)
[14:16] <pedronis> sorry
[14:16] <zyga-ubuntu> Chipaca: I no, I'm saying that if I work on A that uses public api of B I should not need to know internal details of B that so that I can mock it out (again: external interactions of B)
[14:16] <zyga-ubuntu> Chipaca: maybe I'm wrong but I feel it would be nice
[14:16] <pedronis> Chipaca: I mean the tests are using mocking SystemctlCmd as well
[14:16] <mvo> Chipaca: aha, interessting, so I mocked the wrong thing
[14:16] <mvo> Chipaca: thanks, I will  tweak that
[14:17] <Chipaca> zyga-ubuntu: it sounds like we agree on the premise
[14:17] <pedronis> Chipaca: I don't if the code is using both, I asked that in the review though
[14:17] <zyga-ubuntu> Chipaca: +1 :)
[14:17]  * zyga-ubuntu is starving
[14:17] <zyga-ubuntu> I'll skip 14.04 debugging and get a meal
[14:17] <Chipaca> zyga-ubuntu: so based on that, setting SystemctlCmd is the right thing to do, and using MockCommand to replace systemctl, the wrong thing
[14:17] <Chipaca> zyga-ubuntu: gah! go get food :-)
[14:17] <zyga-ubuntu> Chipaca: yes
[14:17] <zyga-ubuntu> Chipaca: though it'd be nice if we could standardize that more
[14:18] <zyga-ubuntu> Chipaca: <module>.MockIt() or whatever
[14:18] <Chipaca> zyga-ubuntu: just as soon as we standardize all modules to be <module>.DoIt()
[14:19] <pedronis> Chipaca: I think zyga-ubuntu as a point here
[14:19] <pedronis> Chipaca: modern style is   MockFoo(foo) (restore func())
[14:19] <pedronis> or at least I hope that was his point
[14:20] <Chipaca> pedronis: in export_test yes; would we want to make that part of the public api also?
[14:20] <pedronis> we do sometimes
[14:20] <Chipaca> ah
[14:20] <pedronis> having a global that you can clobber isn't much better
[14:21] <Chipaca> oh, agreed, it's not pretty
[14:21] <pedronis> Chipaca: release.MockOnClassic for example
[14:21] <pedronis> etc
[14:21] <Chipaca> man, this battery lasts ~10 minutes :-(
[14:21] <pedronis> if we need this across packages we do it
[14:21] <pedronis> I mean put it in the pkg public api
[14:21] <Chipaca> pedronis: sounds like an easy PR
[14:22] <pedronis> they all are, they say  (at the beginning) :)
[14:22] <pedronis> not looking to add another cleanup to my current pile
[14:23] <Chipaca> i'll do it at some point maybe
[14:24] <om26er> is there an interface that allows to take a screenshot of the desktop ? (I am not aware of technicalities on what needs read permission under X11 for that)
[14:25] <Chipaca> om26er: x11 is probably good enough for that
[14:25] <Chipaca> om26er: but it won't work on wayland; i don't think we've got anything that'll work there yet
[14:26] <om26er> Chipaca: yeah, I am only concerned about X11 for now. Will check if just connecting x11 works.
[14:27] <zyga-ubuntu> pedronis: that was the point
[14:28] <zyga-ubuntu> Chipaca: ~10min on your laptop?
[14:28] <Chipaca> zyga-ubuntu: it's an 8yr old battery
[14:28] <Chipaca> yes
[14:28] <mvo> Chipaca: this is about adding "systemd.MockSystemctlCmd()"?
[14:28] <zyga-ubuntu> ah
[14:28] <pedronis> it's good it hasn't exploded or deformed
[14:28] <Chipaca> mvo: not in that PR
[14:28] <mvo> Chipaca: I missed most of the earlier discussion
[14:29] <mvo> Chipaca: it might make sense, should be easy(ish)
[14:29] <Chipaca> mvo: bottom line for your PR: replace SystemctlCmd everywhere, don't use MockCommand
[14:29] <zyga-ubuntu> mvo: how about systemd.MockExternalInteractions
[14:29] <zyga-ubuntu> MEI
[14:29] <Chipaca> zyga-ubuntu: not in that PR!
[14:29] <zyga-ubuntu> MEIBI
[14:29] <zyga-ubuntu> Chipaca: fair enough
[14:29] <pedronis> ExternalInteractions
[14:29] <pedronis> what are those?
[14:29] <mvo> Chipaca: yes, that part I got out of it
[14:29] <Chipaca> mvo: that's all, for your pr
[14:29] <Chipaca> the rest is a bigger change that needs more work
[14:29] <zyga-ubuntu> pedronis: vague stuff including things like running processes
[14:29] <pedronis> MockBoundaryCrossingPokings
[14:29] <zyga-ubuntu> +1
[14:30] <Chipaca> zyga-ubuntu: pedronis: that would mean providing two functions at least
[14:30] <pedronis> ?
[14:30] <Chipaca> SystemctlCMd and  JournalctlCmd
[14:30] <pedronis> Chipaca: we mock both with SystemctlCmd now ?
[14:31] <pedronis> or are you saying there are two globals?
[14:31] <pedronis> I don't care honestly, as long as what one has to do is understanble
[14:31] <pedronis> ExternalInteraction seems a bit too vague for my taste
[14:31] <Chipaca> there are two globals
[14:31] <Chipaca> pedronis: yes, that was a bit my point
[14:32] <Chipaca> we're trying to pretend everything is homogeneousible (?) and it clearly isn't
[14:33] <zyga-ubuntu> jdstrand: hey, can you please review the changes made to https://github.com/snapcore/snapd/pull/3621 -- I'd like to land it when you give it a +1
[14:33] <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:35] <zyga-ubuntu> jdstrand: I wrote the child profile, should be uncontroversial apart from broad/open umount
[14:36] <zyga-ubuntu> jdstrand: I can tighten that further with more PRs or inside this one, as you prefer
[14:36] <zyga-ubuntu> jdstrand: but landing this would allow me to propose useful enchancements
[14:36] <mvo> Chipaca: an alternative would be to simpliy use "testutil.MockCommand("systemctl")" maybe? less elegant I guess
[14:37] <zyga-ubuntu> mvo: what do you think about my idea to let a module offer to mock its internals out as a public API?
[14:38] <Chipaca> mvo: i see MockCommand as a last resource; the path fiddling it does is rather racy
[14:38] <mvo> zyga-ubuntu: yeah, I think that is consistent with other uses we have
[14:39] <mvo> Chipaca: ok
[14:39] <zyga-ubuntu> offtopic, I read how getenv/setenv work and OMG :/
[14:39] <zyga-ubuntu> that's not a nice API
[14:39] <Chipaca> zyga-ubuntu: hehe
[14:39] <zyga-ubuntu> not nice because designed with stupid assumptions eons ago
[14:39] <Chipaca> zyga-ubuntu: wait, did you look at it in go, or in glibc?
[14:39] <zyga-ubuntu> but less setenv we do, the better
[14:39] <zyga-ubuntu> in glibc
[14:39] <Chipaca> zyga-ubuntu: look at it in go sometimes
[14:39] <Chipaca> sometime*
[14:39] <zyga-ubuntu> ah, will do
[14:40] <Chipaca> zyga-ubuntu: that's the source of the raciness i mentioned
[14:40] <zyga-ubuntu> Chipaca: the glibc one has other issues and I suspect gets called eventually
[14:40] <Chipaca> OTOH even setenv is MT-Unsafe
[14:40] <zyga-ubuntu> yes
[14:40]  * zyga-ubuntu just checked
[14:41] <zyga-ubuntu> which probably explains why tests fail when started with -count=1000
[14:41] <zyga-ubuntu> getenv just borks
[14:41] <zyga-ubuntu> and mocked commands don't get used
[14:41] <Chipaca> yep
[14:41] <Chipaca> zyga-ubuntu: so, we could work around that
[14:41] <zyga-ubuntu> especially coreconfig tests
[14:42] <zyga-ubuntu> yes, I think we ought to
[14:42] <Chipaca> by tweaking the path super early
[14:42] <zyga-ubuntu> design it not to fail so easily
[14:42] <Chipaca> and having a single test path env
[14:42] <zyga-ubuntu> I wish golang had a warning for setenv
[14:43] <zyga-ubuntu> like gcc linker scripts have for gets
[14:47] <Chipaca> zyga-ubuntu: just don't wish too hard
[14:47] <Chipaca> zyga-ubuntu: look what happened to setuid
[14:48] <zyga-ubuntu>  /o\
[14:59] <mvo> cachio_: if you have a moment could you please have a look at spread-cron and in particular the snapd-vendor-sync branch? it seems like its not doing things automatically anymore. it should sync the lp:snapd-vendor branch on each merge to master but we had several merges today and nothing got merged since 21h. I think the last merge happend when I clicked a manual rebuild. maybe the actual cron thing is no longer running?
[15:00] <cachio_> mvo, I saw the same and restarted the snap like 30 mins ago
[15:00] <cachio_> it should be running again
[15:01] <cachio_> snapd-vendor-sync is on the queue to be executed
[15:01] <cachio_> mvo, not sure what happened, I'll take a look
[15:03] <cachio_> mvo, I am gonna disconnect now
[15:03] <cachio_> backing from the vpn
[15:04] <mvo> cachio_: thank you
[15:07] <mvo> Chipaca: is http://paste.ubuntu.com/25478666/ what you had in mind for better mocking of the systemctl thing?
[15:09] <Chipaca> mvo: that looks an awful lot like what pedronis and zyga were suggesting, which I recommended happen in a different PR
[15:09] <Chipaca> mvo: or is this a different PR
[15:09] <mvo> pedronis: 3858 should be ready for another look
[15:10] <mvo> Chipaca: it is a different pr, its nothing at all right now, I was waiting for tests and that seemed to be about the level of mental capacity I had left :/ so if it looks sane(ish) I can turn it into a PR
[15:10] <Chipaca> mvo: ah ok :)
[15:11] <Chipaca> mvo: now the same but for journalctl ;-D
[15:12] <mvo> Chipaca: yeah, much less exposure that one
[15:31] <mup> PR snapd#3865 opened: many: provide systemd.MockSystemctl() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3865>
[15:41] <pedronis> mvo: was having a walk,  seems it gets dark earlier and if I wait after dinner for my walk I end up not walking at all
[15:42] <mvo> pedronis: no worries, thank you
[15:42] <mvo> pedronis: enjoy the walk!
[15:42] <pedronis> mvo: I'm back
[15:42] <pedronis> mvo: #3727 seems mergeable to me
[15:42] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[15:42] <pedronis> but I let you do the honors if you want/need to tweak the commit message
[15:45] <mvo> pedronis: I think I take a short break now myself, feel free to merge otherwise I will when I'm back
[15:46] <mvo> pedronis: your 3856 also looks ready for merging (not sure if you want to tweak further but definitely enough +1 :)
[15:47] <jdstrand> zyga-ubuntu: this continues to be on my todo list. it is not forgotten. yesterday had a lot of things I had to respond to over the weekend. note I need to review more than the child profile-- I need to do a careful review of the arg parsing (and env, but I expect that part to go fast)
[15:47] <pedronis> mvo: I wanted to merge #3727 because I expect conflicts/needing some tweaks
[15:47] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[15:47] <jdstrand> zyga-ubuntu: it is also extremely high on said list
[15:47] <pedronis> with #3856
[15:47] <mup> PR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
[15:50] <jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/3864/files#r137309433
[15:50] <mup> PR #3864: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>
[15:51] <jdstrand> mvo: I'd like you to add 'bind' to the seccomp policy. this isn't for livepatch since it gets it elsewhere, but it is so hardware-observe can standalone
[15:51] <mup> PR snapd#3727 closed: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3727>
[15:52] <jdstrand> mvo: I would've done it in another PR but it looks like you didn't update that one yet, so thought I'd mention it. if you prefer to just merge it as is, that is fine, I'll do a followup PR
[15:59] <mup> PR snapd#3847 closed: tests: run the tests/unit/go everywhere <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3847>
[16:02] <niemeyer> Chipaca: Hey, which release did we get tab-completion fully working again?  Isn't that 2.27?  I probably missed it in the notes
[16:02] <Chipaca> niemeyer: what do you mean by "fully working"
[16:02] <niemeyer> Chipaca: Usable by snaps without any local changes
[16:03] <Chipaca> niemeyer: 2.27.2 had snippets, meaning it works without local changes on classic
[16:03] <Chipaca> and falls over flat on core
[16:03] <Chipaca> niemeyer: 2.27.4 skips creating snippets on core
[16:03] <Chipaca> or maybe that's 2.27.5
[16:03] <Chipaca> yeah, .5
[16:03] <niemeyer> Chipaca: Aha, yeah, so it's 2.27 indeed.. I will fix the notes
[16:04] <Chipaca> but 2.27 doesn't have it
[16:04] <Chipaca> there are features in the .s of 2.27
[16:05] <niemeyer> Chipaca: Yeah, sorry.. there's a bit of confusion around that.. I've made a mroe general 2.27 announcement since this was really when we've sorted all small blockers and updated the core snap
[16:05] <Chipaca> ok
[16:10] <cachio> mvo, about hte base snaps test, do you know why it did not fail on linode but it failed on the external:ubuntu-core?
[16:36] <mup> PR snapd#3866 opened: many: implement fetching sections and package names periodically <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>
[16:36] <Chipaca> it lives!
[16:40] <ogra_> hmm
[16:41] <ogra_> so in my update-manager snapd is showing up as "Tool to interact with Ubuntu Core Snappy" in the UI
[16:41] <ogra_> i wonder if we should change that to something less specific :)
[16:53] <Sir_Gallantmon> Feel free to steal my summary and description from my package
[16:58] <mvo> cachio: yes, it failed because on external it uses a snap that was build ~6month ago and on linode it uses our self-build snapbuild
[16:59] <mvo> jdstrand: if you mention it in the PR I will address it next (adding bind)
[16:59] <jdstrand> mvo: I did
[16:59] <cachio> mvo, ok
[17:00] <cachio> mvo, ok, thanks
[17:01] <mvo> jdstrand: excellent, thank you
[17:04] <doko> hi, please could somebody address https://forum.snapcraft.io/t/snapcraft-autopkgtest-failure/2007
[17:07]  * zyga-ubuntu breaks for dinner
[17:08] <zyga-ubuntu> doko: hey, good to see you
[17:09] <ogra_> finally doko found his way into the proper channels :)
[17:25] <jdstrand> mvo: ok, I've looked at this quite a bit. I looked to see what had network netlink rules and udev and all interfacecs that had both are fine (these are all slot implementations)
[17:26] <jdstrand> mvo: I then looked at avahi and found that what it is missing is NETLINK_ROUTE, but it gets that with 'network' so no regression in that snap (I'll still fix that interface for comleteness)
[17:27] <jdstrand> mvo: I then checked all the interfaces with just a 'network netlink' rule. these were all slots that were heavily checked before and have been verified by CE to work without regressions, so that should be fine
[17:27] <mup> PR snapcraft#1532 opened: tests: update the meson test to latest meson requirements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1532>
[17:28] <jdstrand> mvo: there were three plugging interfaces with 'network netlink'-- account-control, network-control and network-observe
[17:28] <jdstrand> mvo: account-control is correct and doesn't need to be changed
[17:30] <jdstrand> mvo: I then looked in the store to see what plugged account-control, network-control or network-observe and found that about half plug neither hardware-observe, x11 or unity7 (ie, things that give NETLINK_KOBJECT_UEVENT)
[17:30] <jdstrand> mvo: so I investigated if we should just add NETLINK_KOBJECT_UEVENT to network-control and network-observe, and looking at kernel sources in net/core, I think we should
[17:32] <jdstrand> mvo: therefore, I will proactively send up a PR for network-control and network-observe for NETLINK_KOBJECT_UEVENT, even though we have no regression reports on these. this will make it so nothing in the stable channel in the public store will regress on NETLINK_KOBJECT_UEVENT, because everything that could've gotten it for free with bare 'socket' before will get the new rule via an interface that they already plugs
[17:38] <mvo> jdstrand: sounds good, I guess we want to also pull this into 2.27.6 then, right?
[17:39] <jdstrand> mvo: if you are rolling a 2.27.6, yes
[17:39] <mvo> jdstrand: I think it makes sense
[17:39] <mvo> jdstrand: if only for canonical-livepatch - even though we workaround it it feels better to do a proper fix
[17:39] <jdstrand> mvo: I'll be sending up the PR for network-control and network-observe in just a bit
[17:40] <mvo> jdstrand: thank you, I will look at it in my morning
[17:40] <jdstrand> mvo: it'll be separate from any other policy work so it is easy to pull in
[17:40] <jdstrand> mvo: should I target master, 2.28 and 2.27?
[17:42] <mvo> jdstrand: we will need it in 2.27 and 2.28 and master :/  but if I can cherry pick it then one PR is enough and I just cherry-pick it
[17:46] <cachio> mvo, is it gonna come a new 2.27 today?
[17:46] <cachio> a beta one?
[17:48] <cachio> mvo, I have physiotherapy now, I can start as soon you have something
[18:23] <mup> PR snapd#3867 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3867>
[18:39] <mup> PR snapd#3869 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3869>
[18:42] <mup> PR snapd#3870 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.27 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3870>
[18:43] <jdstrand> mvo: ok, fyi ^ (3867, 3869 and 3870)
[19:28] <mup> PR snapcraft#1532 closed: tests: update the meson test to latest meson requirements <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1532>
[21:58] <mup> PR snapd#3871 opened: tests: fix regex to check core version on snap list <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3871>
[23:26] <mup> PR snapcraft#1533 opened: demos: update the name of the remote mqtt part <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1533>
[23:38] <mup> PR snapcraft#1534 opened: Fix UnboundLocalError for chmod_path in jhbuild plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1534>