[01:17] <mup> PR snapd#5294 opened: Update SELinux Policy <Created by kevinanderson1> <https://github.com/snapcore/snapd/pull/5294>
[05:04] <mborzecki> morning
[05:15] <Son_Goku> mborzecki, night :)
[05:15]  * Son_Goku is nearly about to go to sleep
[05:15] <mborzecki> Son_Goku: an goodnight :)
[05:15] <mborzecki> s/an/and/
[05:57] <zyga> good morning
[05:57]  * zyga is somewhat tied after yesterday
[05:58] <zyga> it is good that there is some rain this morning
[06:01] <mborzecki> zyga: hey
[06:01] <zyga> hi :)
[06:02] <mborzecki> it rained a bit here, pity it was the only rain in 2 weeks or so
[06:30] <zyga> it still rains here, forecast says it will all day
[06:33] <zyga> ok, kids off to school
[06:33] <zyga> first (or I forget) social security payment
[06:33] <zyga> then work
[06:45] <mvo> pstolowski|afk: 5288 has (ironically) an econnreset test failure :)
[06:45] <mvo> pstolowski|afk: might be yet another interessting corner case
[06:52] <mborzecki> mvo: hi
[06:52] <mvo> hey mborzecki
[06:53] <zyga> ok, all taxes and payments done
[06:53] <zyga> now back to patches
[06:56] <mup> PR snapd#5295 opened: cmd/snap-mgmt: remove system key on purge <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5295>
[06:56] <mborzecki> trivial PR ^^
[07:01] <mvo> mborzecki: do we do this in debian/postrm already? or does it need to be done there as well
[07:01] <mborzecki> mvo: snap-mgmt --purge is used on fedora, opensuse, arch
[07:01] <mvo> mborzecki: I know, I mean, do we need this on debian/ubuntu as well?
[07:02] <mvo> mborzecki: or did we add it there already
[07:02] <mborzecki> mvo: aah, let me check :) i automatically assumed that it's correct there
[07:02] <mvo> mborzecki: maybe it is :)
[07:05] <mborzecki> mvo: well it does rm -rf /var/lib/snapd
[07:05] <mvo> mborzecki: heh, that should cover it
[07:06] <mvo> mborzecki: thanks for checking
[07:06] <mborzecki> mvo: np
[07:06] <mborzecki> mvo: btw. do you have any idea why the repair timer may be getting stopped before the test?
[07:08] <mvo> mborzecki: no idea, that is a bit mysterious
[07:08] <mborzecki> mvo: i've restarted 5285 but the log on friday showed that snapd.snap-repair.timer was being stopped just before the test
[07:08] <mborzecki> (kudos to systemd guys for actually collecting and showing this in systemctl show ..)
[07:10] <pstolowski> morning
[07:10] <mvo> mborzecki: I did a quick git grep over the tests dir but nothing jump out that would touch the repair service
[07:11] <mborzecki> pstolowski: hey
[08:17] <mup> PR snapd#5294 closed: Update SELinux Policy <Created by kevinanderson1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5294>
[08:17] <mup> PR snapd#5295 closed: cmd/snap-mgmt: remove system key on purge <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5295>
[08:17] <mborzecki> zyga: thanks!
[08:23] <mborzecki> when mounting a snap fails, does the journal contain anything useful?
[08:23] <zyga> mborzecki: as much as the kernel provides
[08:24] <abeato> hi, how can I get more information when I see this sort of trace?: "handlers.go:372: Reported install problem for "core" as 680c957c-6d4a-11e8-a5bb-fa163e839e11 OOPSID"
[08:24] <mborzecki> zyga: i'm wondering if we should try and grab the output of journalctl -u <failed-unit>.mount at least
[08:24] <zyga> abeato: this goes to errors.ubuntu.com
[08:24] <zyga> mborzecki: mmmmm
[08:24] <zyga> mborzecki: in tests or in general
[08:25] <mborzecki> zyga: in tests
[08:25] <zyga> I think in tests we do (by extension of capturing lots of output)
[08:25] <zyga> in general would be interesting
[08:25] <mborzecki> zyga: in test's we don't, the tests run journalctl -u snapd .. which will not include the mount unit stuff
[08:26] <abeato> zyga, ok, but there is no other information that can be looked into in the system?
[08:26] <zyga> I think you can see more in "snap changes"
[08:26] <zyga> and "snap tasks NNN"
[08:27] <abeato> zyga, got it, thanks
[08:28] <Chipaca> abeato: the error report is going to contain things that are in the log (before it talks about the error report), or in the tasks log
[08:28] <Chipaca> or general system info
[08:28] <abeato> great
[08:28] <Chipaca> abeato: otherwise, https://errors.ubuntu.com/oops/680c957c-6d4a-11e8-a5bb-fa163e839e11
[08:28] <mborzecki> zyga: pff, i see it now, there's something logged :/ but not much
[08:28] <zyga> Chipaca: heyo :)
[08:29] <Chipaca> zyga: 'sup
[08:29] <Chipaca> abeato: in particular: ERROR [--root / enable snap.network-manager.networkmanager.service] failed with exit status 1: Created symlink from /etc/systemd/system/multi-user.target.wants/snap.network-manager.networkmanager.service to /etc/systemd/system/snap.network-manager.networkmanager.service.
[08:29] <Chipaca> abeato: which is not particularly helpful :-)
[08:29] <Chipaca> abeato: no doubt you have better debug info locally
[08:29] <abeato> Chipaca, right, I just saw that in "snap change 1"
[08:30] <abeato> weird thing, then it retried and the second time it worked :/
[08:30] <Chipaca> also, whoa, 96 bogoMIPS
[08:30] <Chipaca> speed fiend
[08:31] <abeato> hehe, yes, it is a pretty slow processor
[08:31] <Chipaca> mborzecki: what're you trying to do?
[08:31] <zyga> 96 tail movements in turtle graphics
[08:31] <mborzecki> Chipaca: was wondering if there's something more to collect when we fail to mount a snap
[08:31] <Chipaca> zyga: tail *recursive*?
[08:32] <zyga> Chipaca: ouch ;)
[08:35] <Chipaca> mborzecki: AFAIK no
[08:36] <Chipaca> mborzecki: systemd doesn't even report the errno of the mount call
[08:36] <zyga> because there is none
[08:36] <zyga> I mean
[08:36] <mborzecki> Chipaca: right, that's the protocol part
[08:36] <zyga> not one, it uses libmount
[08:36] <zyga> lots of more complexity and features handled
[08:38] <Chipaca> ¯\_(ツ)_/¯
[08:39] <Chipaca> if you need to do foo, and you do it by using libfoo, that does not get you off the hook of handling foo errors properly
[08:39] <mborzecki> errors go to /dev/foo
[08:39] <Chipaca> I mean, you're responsible for the libraries you use as well as the code you write
[08:40] <Chipaca> mborzecki: only in 4.16.17 compiled on even days of the month though
[08:40] <zyga> mborzecki: /dev/foo?
[08:41] <mborzecki> zyga: s/f/p/ if you wish :)
[08:41] <zyga> ah
[08:41] <zyga> well
[08:41] <zyga> you are actually close ;)
[08:41] <zyga> there is a new kernel interface for mount errors
[08:41] <zyga> and it is a special device
[08:41]  * zyga looks for the patch
[08:41] <mborzecki> no wai
[08:41] <mborzecki> zyga: link?
[08:41] <Chipaca> mborzecki: too late
[08:42] <Chipaca> mborzecki: EVERYTHING IS ~~SPIDERS~~ block devices
[08:45] <mborzecki> btw. on friday i got my car back from the shop, the damage cost ~1800eur to fix, fortunately i'm not paying :P
[08:46] <zyga> I cannot find the patch
[08:46]  * zyga looks through bookmarks
[08:47] <Chipaca> mborzecki: whoa
[09:16] <pedronis> hi
[09:17] <zyga> hey :)
[09:19] <mup> PR snapd#5296 opened: daemon: paging is not a thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/5296>
[09:25] <Chipaca> mvo: if I had a feature I needed to be in 2.34, what's the latest it can land on master?
[09:25] <Chipaca> (without causing undue work to other people i mean)
[09:28] <Chipaca> also, that pr ^ is the shortest I've done in ages :-)
[09:30] <Chipaca> popey: you should snap OpenNFSv3 just to confuse people
[09:30] <Chipaca> needs some care in writing the description so you don't really know if you're getting a filesystem or a racing game
[09:31] <popey> hah
[09:31] <Chipaca> 'from scratch rewrite of NFS with a focus on performance and interoperability', say
[09:51] <zyga> mborzecki: I think your PR is bigger
[09:51] <mup> PR snapd#5297 opened: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[09:52] <mborzecki> pedronis: just to be sure i'm not missing something, InstanceKey in snap action == InstanceKey in current snap in context right?
[09:54] <mvo> Chipaca: for 2.34 would be good to land this week or early next week
[09:54] <Chipaca> mvo: ok
[09:54] <Chipaca> mvo: thanks
[10:03] <mup> PR snapd#5296 closed: daemon: paging is not a thing <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5296>
[10:14] <pedronis> mborzecki: yes, for refreshes
[10:14] <mborzecki> pedronis: thx
[10:16] <mborzecki> pedronis: i'm close to finishing with the changes in store, once i push the patch, i'll send you a link for a quick review in case i did something overly stupid there
[10:42]  * zyga -> coffee
[11:08] <mup> PR snapd#5298 opened: store, image: have 'snap download' use v2/refresh action=download <Created by chipaca> <https://github.com/snapcore/snapd/pull/5298>
[11:09] <Chipaca> pedronis: ^ info inch-pebble
[11:12] <pedronis> Chipaca: thx, I'll look after the break
[11:12] <Chipaca> pedronis: somewhat trepidatious as it almost seemed to easy :-)
[11:12] <Chipaca> too*
[11:13] <Chipaca> in other news: you'll be shocked to hear snapd doesn't work in WSL
[11:14] <Chipaca> (there's a bug about it an' all)
[11:19] <zyga> Chipaca: is it snapd or general code around it that breaks?
[11:19] <Chipaca> zyga: WSL doesn't support daemons
[11:20] <Chipaca> zyga: WSL doesn't support systemd
[11:20] <zyga> daemons are supported
[11:20] <zyga> but systemd is not
[11:20] <Chipaca> zyga: ah, release notes I read said No, but that was a while ago
[11:20] <zyga> yeah, it is recent
[11:26] <mborzecki> well, snaps under wsl, on windows, that would be fun
[11:28] <zyga> mborzecki: well, once they support mount namespaces we could
[11:28] <zyga> drop all sandboxing
[11:28] <zyga> and handle mounting snaps with something else (unpack?)
[11:29] <Chipaca> zyga: fuse :-)
[11:29] <Chipaca> (does it even)
[11:29] <Chipaca> i mean, windows does have the idea of mounting stuff
[11:29] <zyga> Chipaca: WSL does some special things to windows filesystem
[11:29] <zyga> so not easily
[11:31] <Chipaca> zyga: if we really wanted to pursue this we might be able to get in touch with people at ms
[11:37] <zyga> mborzecki: hey look https://github.com/snapcore/snapd/pull/5297 is green now
[11:37] <zyga> I feel I should swap this review for your uber rename one
[11:37] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[11:38] <zyga> this needs a 2nd review https://github.com/snapcore/snapd/pull/5283 and is pretty short and simple
[11:38] <mup> PR #5283: snapstate: get rid of needsMaybeCore <Created by mvo5> <https://github.com/snapcore/snapd/pull/5283>
[11:39] <zyga> https://github.com/snapcore/snapd/pull/5230 needs a 2nd review and is otherwise ready
[11:40] <mup> PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
[11:49]  * cachio afk
[11:55] <zyga> jdstrand: hello, can you please enqueue some time to look at this https://github.com/snapcore/snapd/pull/5170#issuecomment-396216845
[11:55] <mup> PR #5170: interfaces/builtin: add adb-support interface <Blocked> <Decaying> <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
[11:59] <pedronis> Chipaca: I think we might have an ubuntu-image test using the fakestore, so it probably needs to learn about download
[12:00] <Chipaca> pedronis: only one spread error, and it seems unrelated to my change
[12:00] <zyga> mvo: can you please weigh in on https://github.com/snapcore/snapd/pull/4996
[12:00] <mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
[12:00] <zyga> is that ready for landing or is more stuff needed
[12:01] <pedronis> Chipaca: ok, I'm probably misremembering then
[12:01] <zyga> mvo: can you please add a reference to the apt bug on https://github.com/snapcore/snapd/pull/5122
[12:01] <mup> PR #5122: snap: add support for `snap advise-snap --from-apt` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5122>
[12:01] <Chipaca> pedronis: maybe fakestore implemented enough of v2 refresh for it to work :-)
[12:03] <Chipaca> pedronis: tests/main/snap-download talks to the real stores tho
[12:03] <pedronis> Chipaca: possibly,   no I remembered right:  /main/prepare-image-grub/task.yaml  seems to use the fakestore, maybe a double check that it works for semi-reasonable reasons would be good
[12:03] <Chipaca> ah, prepare-image
[12:04] <pedronis> ah, it uses the fakestore only for assertions
[12:04] <pedronis> Chipaca: anyway it probably is a good idea to make sure the fakestore could handle download
[12:04] <pedronis> given we are in the middle of introducing it
[12:06] <pedronis> Chipaca: but yes, seems it should just work, afaict there's just a Action == "refresh" in all the relevant cocde
[12:07] <Chipaca> pedronis: we could make it barf on unknown actions, or sth
[12:07] <Chipaca> seems fine as is though
[12:07] <mvo> zyga: re 4996> does it need a gustavo review to ensure names (e.g. ifaceRepokey) are agreed upon?
[12:08] <zyga> mvo: the name was changed since earlier reviews (AFAIR by pedronis) so .. not sure
[12:09] <pedronis> it was changed by mborzecki picking one of couple of suggestions
[12:09] <pedronis> I made I think
[12:10]  * Chipaca ~> lunch
[12:11] <mborzecki> right, i took over 4996 for a while and addressed all (most) comments
[12:12] <zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/4416
[12:12] <mup> PR #4416: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416>
[12:12] <zyga> you reviewed it before
[12:12] <zyga> and it's the only PR from 2017:D
[12:14] <pedronis> mvo: the choices were snap-interfaces or snap-profiles or snap-interface-profiles
[12:14] <mvo> pedronis: its fine with me, just want to ensure gustavo is happy about the naming as well
[12:14] <mvo> (as he usually cares a lot about this)
[12:15] <pedronis> mvo: then you need to wait, but it's been like this since forever
[12:15]  * zyga -> lunch
[12:17] <mvo> zyga: I looked at 4416 - it looks like your question ("how its supposed to be used") is not answered
[12:17] <pedronis> mvo: it's going to be used when we reload profiles
[12:18] <mvo> pedronis: yeah, sorry, I was replying to a different PR (the performance measure one)
[12:18] <pedronis> ah
[12:18] <mvo> pedronis: I will +1 the other one, one sec
[12:18] <pedronis> I saw the 4**6  I didn't read the middle number
[12:18] <pedronis> s
[12:18] <pedronis> it seems
[12:18] <mvo> pedronis: :) no worries
[12:18] <mvo> pedronis: just shows we still have too many open
[12:19] <pedronis> that is true
[12:21] <mvo> pedronis: looks like 5221 just needs this tiny tweak that pawel suggests and then it can go in as well(?)
[12:21] <pedronis> mvo: yes, I will do the change today
[12:21] <pedronis> I'm also working on actually using this
[12:22] <mvo> pedronis: nice
[12:25] <mvo> mborzecki: how did you create test-snapd-appstreamid? via a snapcraft file?
[12:27] <mvo> mborzecki: aha, nevermind, found it
[12:27] <mborzecki> mvo: yup ;) glad that you found it
[12:28] <mvo> mborzecki: I make it arch: all, it breaks on non amd64 tests right now:)
[12:28] <mborzecki> right, iirc i've only published amd64 snap
[12:29] <mvo> mborzecki: yeah, no worries, I take care of it
[12:29] <mborzecki> mvo: ok, great
[12:35] <mup> PR snapd#5299 opened: tests: publish test-snapd-appstreamid for any architecture <Created by mvo5> <https://github.com/snapcore/snapd/pull/5299>
[12:36] <pedronis> Chipaca: I did a pass over the download one
[12:39] <mvo> pedronis: if you have a spare cycle I would love to get an opinion on 5276
[12:44] <pedronis> mvo: it looks good, but I think we want like for core,base,kernel,gadget to make sure  snapd  is done first (even if seed.yaml order isn't what we expect)
[12:44] <pedronis> I added a comment there too
[12:48] <mup> PR snapd#5300 opened: tests: skip security-dev-input-event-denied on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/5300>
[13:35] <Chipaca> mborzecki: https://www.gumtree.com/p/bicycles/unisex-optima-cougar-mountain-bike./1302194477
[13:35] <Chipaca> mborzecki: https://www.gumtree.com/p/bicycles/gents-bike-ladies-bike/1302156061
[13:35] <mborzecki> Chipaca: those look legit
[13:36] <Chipaca> mborzecki: told you
[13:36] <Chipaca> not sure why but bikes have very low resale value in uk
[13:38] <mborzecki> Chipaca: hmm weird, it's like cars then, isn't it?
[13:38] <popey> also, gumtree -> stolen goods
[13:38] <zyga> my connection broke at around when cachio was talking so I just returned home then
[13:39] <Chipaca> popey: not always though
[13:39] <popey> Sure.
[13:39] <Chipaca> you do need a sketchometer though
[13:39] <Chipaca> sketchy-o-meter
[13:40] <zyga> hmmm
[13:40] <zyga> guys, does anyone have a theory why there are all the test failures recently?
[13:40] <zyga> any specific change that triggered it
[13:41] <Chipaca> zyga: I blame multicasts on broken packets
[13:41]  * Chipaca puts away his BOFH excuse generator
[13:42] <zyga> for instance, what broke
[13:42] <zyga> + systemctl is-active snapd.snap-repair.timer
[13:42] <zyga> inactive
[13:43] <zyga> mborzecki: can you please look at v
[13:43] <zyga> https://github.com/snapcore/snapd/pull/5297
[13:43] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[13:44] <Chipaca> mvo: #5294 confirmed wrt cla
[13:45] <mup> PR #5294: Update SELinux Policy <Created by kevinanderson1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5294>
[13:46] <jdstrand> roadmr: hi! would you mind flipping on requash enforcement?
[13:46] <roadmr> jdstrand: sure! flipping now
[13:48] <jdstrand> roadmr: thanks!
[13:48] <roadmr> jdstrand: where "now" is now. I'ts just been flipped to ON
[13:48] <mvo> Chipaca: confirmed that the CLA is singed or not signed?
[13:49] <roadmr> jdstrand: also we'll get r1089 rolled out today \o/
[13:49] <jdstrand> roadmr: thanks! :)
[13:52] <jdstrand> roadmr: unrelated to that, fyi, this seems stuck: https://dashboard.snapcraft.io/snaps/inoxision-webclient/revisions/115/
[13:52] <jdstrand> roadmr: as does https://dashboard.snapcraft.io/snaps/falkon/revisions/45/
[13:53] <roadmr> jdstrand: let me unwedge them
[13:53] <jdstrand> thanks
[13:54] <roadmr> jdstrand: interesting, inoxision-webclient says "Task 47c953d4-cb72-4618-9df6-5de67275e931 failed. ". I'll unwedge for now but will have a closer look at that task id later
[13:54] <jdstrand> yeah, thanks
[13:54] <roadmr> jdstrand: falkon is ready to roll, inoxision-webclient should be in a couple of mins (it's a large snap)
[13:55] <mborzecki> off to pick up the kids
[13:55] <mborzecki> zyga: i'll take a look when i get back
[13:55] <zyga> thanks
[13:55] <zyga> jdstrand: hey :)
[13:56] <zyga> mvo: signed
[13:58] <zyga> jdstrand: you may find https://github.com/snapcore/snapd/pull/5297 interesting :)
[13:58] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[13:58] <mvo> zyga: cool, thanks
[14:01] <jdstrand> hey zyga :)
[14:08] <mup> PR snapd#4700 closed: interfaces: add the dvb interface <Created by ThyMYthOS> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4700>
[14:19] <Chipaca> mvo: signed
[14:19] <mup> PR snapd#5300 closed: tests: skip security-dev-input-event-denied on s390x/arm64 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5300>
[14:28] <popey> Wimpress: ping!
[14:28] <Wimpress> popey: Pong?
[14:28] <Chipaca> pedronis: do you remember offhand how to get the thing 'snap download' expects for auth?
[14:29] <pedronis> Chipaca: in which sense?
[14:29] <Chipaca> pedronis: UBUNTU_STORE_AUTH_DATA_FILENAME=~/.snap/auth.json doesn't work
[14:30] <pedronis> that doesn't work, because we don't store the store macaroons anymore there
[14:30] <pedronis> only the local one
[14:30] <Chipaca> pedronis: we didn't have a 'snap grab-the-auth' command?
[14:30] <pedronis> Chipaca: we don't yet
[14:30] <pedronis> Chipaca: but snapcraft export-login works
[14:30] <pedronis> one sec
[14:30] <Chipaca> ah there we go :-)
[14:32] <Chipaca> hm, looks like my snapcraft macaroni has expired or sth
[14:32] <pedronis> Chipaca: just give it  --acls  package_access
[14:33] <Chipaca> huh, export-login asks you to log in again?
[14:34] <pedronis> yes
[14:34] <pedronis> anyway as I said you need different acls than your usual login
[14:34] <pedronis> sorry, I mean, than the usual snapcraft macaroon
[14:35] <Chipaca> right
[14:36] <Chipaca> pedronis: wrt checking channel & revision, any reason not to let them through and have the store error?
[14:36] <Chipaca> is there a path in which we set both?
[14:37] <Chipaca> if we let them through, we get: error: cannot find snap "http": cannot download snap "http": Both revision and channel are present in the request for this Snap. It should be one or the other exclusively.
[14:37] <pedronis> Chipaca: you an do snap download --channel=foo --revision=#  no?
[14:37] <Chipaca> (and yes I'll drop the 'cannot find' thing)
[14:37] <pedronis> are you saying for this it's good enough?
[14:37] <Chipaca> pedronis: I'm saying it's weird to check it at this level
[14:37] <Chipaca> pedronis: better to check it in cmd_download
[14:37] <pedronis> ah, ok
[14:38] <Chipaca> and at this level just let it through
[14:38] <Chipaca> IOW, I'd drop the one in snapstate
[14:38] <Chipaca> rather than adding it to image
[14:38] <pedronis> please don't drop the one in snapstate
[14:38] <pedronis> if you do, you need to add checks in a lot of places
[14:38] <Chipaca> aw! you're no fun anymore
[14:39] <Chipaca> :-D
[14:39] <pedronis> not a lot, but enough that is hard to keep track
[14:39] <Chipaca> pedronis: my 2nd favourite thing would be to move it into store itself
[14:40] <Chipaca> unless your point is that we'd have to have that code in fakestore as well?
[14:40] <pedronis> ?
[14:40] <Chipaca> pedronis: ok to move it from snapstate to store?
[14:40] <pedronis> fakestore is a server
[14:40] <pedronis> Chipaca: yes, but remember this applies only to install and download
[14:41] <Chipaca> yes. what's the name of the thing that mocks Store though.
[14:41] <pedronis> ah, the other fake store
[14:41] <pedronis> but yes
[14:41] <pedronis> Chipaca: there's an argument to  do it both places tbh
[14:42] <pedronis> belt and suspenders
[14:42] <pedronis> as they say
[14:51] <mup> PR snapd#5301 opened: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
[14:52] <mvo> mborzecki: there is an nmap netcat?
[14:53] <mvo> mborzecki: woah, I had no idea, fun
[15:04] <mborzecki> Son_Goku: fedora netcat comes from nmap right? cc mvo
[15:04] <Son_Goku> yes
[15:04] <mborzecki> Son_Goku: ack, thx
[15:04] <Son_Goku> redhat / fedora netcat is nmap's variant
[15:41] <ondra> kyrofa ping
[15:44] <zyga> mvo: FYI, https://github.com/snapcore/snapd/pull/5301#pullrequestreview-127623720
[15:44] <mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
[15:47] <zyga> pstolowski: I need a 2nd review on https://github.com/snapcore/snapd/pull/5278
[15:47] <mup> PR #5278: cmd/snap-update-ns: add IsSnapdCreatedPrivateTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
[15:48] <zyga> it's a PR with one new simple function
[15:48] <kyrofa> Hey ondra, what's up?
[15:49] <ondra> kyrofa hey
[15:49] <ondra> kyrofa I've got problem with snapcraft on one machine
[15:49] <mvo> zyga: thank you, just replied and updated the test. thanks for noticing. I can look into doing this on apparmor init as well if you feel this is cleaner
[15:49] <ondra> kyrofa it gets stacked in pull stage on 99%
[15:50] <zyga> mvo: I had a look and I don't know how to do it easily
[15:50] <zyga> mvo: as we'd need the revno for core
[15:50] <zyga> mvo: in apparmor.Backend.Initialize
[15:50] <zyga> mvo: let me look at your patch first
[15:50] <kyrofa> ondra, every time? Have you run in debug mode?
[15:50] <mvo> zyga: aha, right
[15:51] <zyga> mvo: ah, debian 9
[15:51] <zyga> mvo: if this passes on Sid I'm happy then
[15:51] <zyga> mvo: the rest can be re-factored separately
[15:51] <ondra> kyrofa every time and on different projects now
[15:51] <zyga> mvo: any idea why it didn't fail before?
[15:52] <ondra> kyrofa I have wiped ~/.cache/snapcraft but some result
[15:52] <kyrofa> ondra, no errors, though? Is this pulling build- or stage-packages?
[15:52] <ondra> kyrofa I think stage packages
[15:52] <mvo> zyga: its a new test, I added it to check that things really work as we expect them to work
[15:53] <ondra> kyrofa https://paste.ubuntu.com/p/k3rfJT6RmG/
[15:53] <ondra> kyrofa and then it will sit here forever
[15:53] <zyga> mvo: https://github.com/snapcore/snapd/pull/5301/commits/e6eb26c46718747e7e328dba1db24958f45cda7f#r194454976
[15:53] <mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
[15:53] <zyga> I see
[15:53] <kyrofa> ondra, huh, that's just fetching indexes
[15:54] <kyrofa> Er, indices
[15:54] <zyga> please make this modification and if it passes I'm +1
[15:54] <zyga> having no 2nd phase tasks would be a major simplification
[15:54] <pstolowski> zyga: looking
[15:54] <mvo> zyga: ok, will do tomorrow (or feel free to just tweak yourself). I need to go and play hockey now :)
[15:54]  * mvo waves
[15:54] <zyga> :)
[15:54] <ondra> kyrofa running apt-get update passes fine
[15:55] <ondra> kyrofa I do have multiple architectures on that machine though
[15:56] <kyrofa> ondra, hmm, that could make things a little odd. Try running `snapcraft pull --enable-geoip` as well
[15:56] <ondra> kyrofa so it was working fine, can't really say when it broke, not apparent reason there
[15:56] <ondra> kyrofa loads of errors with that option
[15:57] <ondra> kyrofa and indeed errors are related to arm64 and armhf
[15:59] <ondra> kyrofa interestingly I have another machine with similar setup, same errors there, but build still works
[16:00] <pstolowski> zyga: 1 comment
[16:01] <ondra> kyrofa OK so it looks like snapcraft is trying to be smarter and it's not actually following /etc/apt/sources.list
[16:01] <kyrofa> ondra, when you ctrl+c is while it's hung there, do you get a traceback?
[16:01] <ondra> kyrofa there I have correct setup for each arch
[16:03] <ondra> kyrofa https://paste.ubuntu.com/p/Mb9zBYFZY5/
[16:05] <zyga> pstolowski: thank you, looking now
[16:06] <zyga> pstolowski: replied now
[16:10] <Luke> how does snapcraft decide what to include in the install/stage after the build phase? Is it just any file or change that is applied outside of the build dir?
[16:11] <kyrofa> ondra, huh, it really is just the apt api sitting there
[16:13] <kyrofa> ondra, I'm really not sure what's happening there
[16:13] <kyrofa> ondra, what happens if you remove the multiarch stuff?
[16:14] <ondra> kyrofa then I won't be able to cross build :)
[16:14] <kyrofa> ondra, haha, you can't right now anyway ;)
[16:14] <mup> PR snapd#5278 closed: cmd/snap-update-ns: add IsSnapdCreatedPrivateTmpfs and tests <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5278>
[16:14] <ondra> kyrofa lol
[16:14] <kyrofa> I'm just throwing darts at the wall, trying to figure out what's causing it to get caught up
[16:15] <ondra> kyrofa fair point :P
[16:15] <zyga> thank you pawel!
[16:15] <ondra> kyrofa testing it now
[16:15] <ondra> kyrofa so I removed arches with dpkg, I left them in sources, which seems to be ignored somehow anyway
[16:16] <ondra> and that is same result, stacked at 99%
[16:17] <kyrofa> sergiusens, any idea what would cause the apt API to do that ^ ?
[16:17] <ondra> kyrofa and 'snapcraft pull --enable-geoip' passes without error
[16:17] <kyrofa> ondra, wait, that finishes the pull step?
[16:17] <ondra> kyrofa ha and now that continues to pulling other parts
[16:17] <kyrofa> Innnteresting
[16:18] <kyrofa> It sounds like one of the repos being used it having issues, then
[16:20] <ondra> kyrofa so calling snapcraft will hang, calling ''snapcraft pull --enable-geoip' will complete pull stage
[16:24] <kyrofa> ondra, yeah, by default it just uses archive.ubuntu.com, but with geoip will use your country prefix
[16:25] <ondra> kyrofa I'm running it in the cloud, so god knows what that actually is
[16:26] <kyrofa> Oh, fun
[16:26] <sergiusens> ondra: please post on the forum
[16:30] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[16:30] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[16:31] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[16:31] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[16:36] <zyga> jdstrand: do you think we could fast-track https://github.com/snapcore/snapd/pull/5297
[16:36] <mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
[16:36] <zyga> and land it?
[16:37] <jdstrand> zyga: I'll move it to the top of the list, but the others need to wait. I owe morphis a review
[16:38] <zyga> ack
[16:38] <zyga> thank you
[16:38] <zyga> it's a large and very boring review
[16:38] <zyga> so I just want to land it to help me out and not conflict
[16:56] <ondra> sergiusens https://forum.snapcraft.io/t/snapcraft-getting-stacked-at-99-during-pull-stage/5876
[17:04]  * zyga explores a descriptor leak that makes no sense
[17:14] <mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[17:14] <mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[17:14] <mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
[17:16] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[17:16] <mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[17:16] <mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
[17:22] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[17:22] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[17:23] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[17:23] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[17:25]  * zyga found the bug but first walk
[17:50] <kyrofa> zyga, if I have an `environment:` keyword in the root of my YAML, that applies to all apps and hooks, right?
[18:05] <zyga> kyrofa: let me check
[18:05] <zyga> kyrofa: I'd say yes
[18:05] <zyga> but I'll look
[18:07] <zyga> kyrofa: ha
[18:07] <zyga> so it looks buggy
[18:08] <zyga> kyrofa: ah, sorry
[18:08] <zyga> it looks good
[18:08] <zyga> so yes,
[18:08] <kyrofa> zyga, alright, something odd is happening on my hook... still investigating
[18:08] <zyga> we take the global (snap-global) environment
[18:08] <kyrofa> Thanks for the quick check!
[18:08] <zyga> then take the per app environment
[18:08] <zyga> oh, hook you say?
[18:09] <zyga> kyrofa: curious
[18:09] <zyga> kyrofa: hooks don't take environment at all
[18:10] <zyga> kyrofa: yes, hooks just take the snap-level environment keys
[18:10] <zyga> and with that I'm off for another round of bicycling
[18:13] <roadmr> yeay zyga
[19:02]  * cachio afk
[20:22] <mup> PR snapd#5302 opened: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302>
[20:23] <kyrofa> zyga, that's ^ the problem I was hitting
[21:31] <zyga> kyrofa: I saw that just now. I will review it first thing tomorrow
[21:38] <kyrofa> Thanks zyga
[21:39] <zyga> Thank you x10 for the patch!
[22:50] <wililupy> question: what is '/var/lib/snapd/hostfs' used for?
[22:53] <zyga> wililupy: hey
[22:54] <wililupy> hi zyga!
[22:54] <zyga> wililupy: it is used at runtime to host the / of the host system
[22:54] <zyga> technically when a snap application runs it constructs some temporary directories and then makes moves all of the root filesystem (/) to /var/lib/snapd/hostfs, replacing the / with something else
[22:54] <zyga> then hostfs is used as a "view" to the rest of the filesystem
[22:56] <wililupy> zyga: thats what I thought. I have a weird apparmor error trying to confine my snap and the path.
[22:57] <wililupy> I created an interface with the rule: /var/lib/snapd/hostfs/{,*} rw,
[22:57] <zyga> what is the denial you are getting, exactly?
[22:58] <wililupy> Jun 11 22:52:36 dpdk-test kernel: [ 1408.757203] audit: type=1400 audit(1528757556.659:90): apparmor="DENIED" operation="open" profile="snap.dpdk-wililupy.testpmd" name="/var/lib/snapd/hostfs/mnt/huge/" pid=2546 comm="testpmd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[22:58] <zyga> Right
[22:58] <zyga> I think what we want instead is to mirror /mnt from the host
[22:59] <zyga> and add it to removable media or a new interface
[22:59] <zyga> there's a thread about that on the forum
[22:59] <wililupy> and mnt/huge is not there
[22:59] <zyga> I will make a patch for this tomorrow
[22:59] <zyga> (it's 1AM for me)
[23:00] <wililupy> zyga: no problem. Its for a hugepages interface I am working on (https://github.com/wililupy/snapd/blob/master/interfaces/builtin/hugepages_control.go)
[23:01] <zyga> I can quickly say that https://github.com/wililupy/snapd/blob/master/interfaces/builtin/hugepages_control.go#L35 is probably not going to fly
[23:01] <zyga> as this gives full write access to the host
[23:01] <zyga> why /mnt/huge? isn't there a standardised place for huge pages elsewhere?
[23:02] <wililupy> zyga: I'm following their testing documentation and that is the path they use in their example.
[23:02] <zyga> can you refer to that?
[23:03] <wililupy> zyga: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#running-dpdk-applications
[23:04] <zyga> mount | grep huge
[23:04] <zyga> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
[23:05] <zyga> unless dpkd requires that specific path
[23:06] <zyga> wililupy: could you open a forum thread about this effort? it will be easier to sync this way than on IRC
[23:06] <wililupy> Sure thing. Get some sleep.
[23:56] <mup> PR snapd#5297 closed: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5297>