[01:23] <mup> PR snapcraft#2778 opened: Release changelog for 3.9 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2778>
[06:21] <mborzecki> morning
[06:28] <mvo> hey mborzecki
[06:29] <mborzecki> mvo: hey
[07:18] <zyga> good morning
[07:18] <zyga> bug triage duty!
[07:18] <mborzecki> zyga: hey
[07:18] <zyga> hey :)
[07:18] <zyga> I'm working away from office today
[07:21] <zyga> I'll begin the day with some reviews
[07:21] <zyga> then go to UX docs
[07:30] <mup> PR snapd#7682 opened: [RFC] add kernel remodel undo tests and fix undo <Created by mvo5> <https://github.com/snapcore/snapd/pull/7682>
[07:30] <zyga> mvo: small -1 comment on the 2.42.1 cherry pick PR
[07:32] <zyga> mvo: 2.42 PR failed on mount ns test
[07:32] <zyga> mvo: the failure indicates it is a missing lxd cleanup
[07:32] <zyga> mvo: I think mborzecki sent a patch to master to fix that
[07:32] <zyga> mvo: you may want to cherry pick that as well
[07:32] <zyga> mvo: for context, this is how such failure looks like:
[07:32] <zyga> https://www.irccloud.com/pastebin/Zxxde5Sh/
[07:34] <mborzecki> zyga: mvo: this one? https://github.com/snapcore/snapd/commit/03f3210eadeb47ee3c286e2c4fb242ce67365c86#diff-413b2f27493a11371053198f7020e23f
[07:34] <zyga> I think so
[07:47] <zyga> abeato: gentle ping about https://github.com/snapcore/snapd/pull/7603
[07:47] <mup> PR #7603: interfaces: add dpdk and hugepages interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7603>
[08:04] <pstolowski> morning
[08:04] <zyga> hey pawel
[08:09] <mborzecki> pstolowski: hey
[08:33] <mvo> zyga, mborzecki thank you, I have a look
[08:39] <pedronis> mvo: hi, is #7624 ready for review?
[08:40] <mup> PR #7624: snap: make `snap download` download via snapd if available <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
[08:42] <mvo> pedronis: yes
[08:44] <mvo> store seems to give 503 right now, we have lots of red
[08:45] <mup> PR snapd#7663 closed: tests: add 14.04 canonical-livepatch test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7663>
[08:49] <pedronis> mvo: I made some initial comments in 7682
[08:50] <mvo> pedronis: yeah, excellent
[08:51] <mvo> pedronis: I was wondering if deviceCtx is the way and you suggested it for oldModel so I will add it. thank you!
[08:51] <mvo> pedronis: will make the diff a bit bigger (with test updates) so I may do it as a separate PR (?)
[08:51] <mvo> pedronis: and *thank you* for the  feedback!
[08:55] <pedronis> mvo: np
[08:55] <pedronis> did a quick on 7624 too
[08:56] <mvo> pedronis: thank you!
[09:01] <mup> PR snapd#7683 opened: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <https://github.com/snapcore/snapd/pull/7683>
[09:09]  * dot-tobias good morning
[09:14] <mvo> ackk: did you had a chance to test the performance of snaps inside lxd recently? we fixed some performance issues and iirc the maas team mentioned they were hit by the slow performance inside lxd
[09:15] <ackk> mvo, hi, I haven't tried it recently. our issue was with squashfuse being super-slow, and particularly visible with the maas snap since it's quite big
[09:15] <ackk> and a lot of small (python) files that get read at startup
[09:15] <mvo> ackk: yeah, that should be fixed in current core
[09:16] <ackk> mvo, nice, I'll give it a try, let you know how it goes
[09:16] <mvo> ackk: thank you!
[09:17] <ackk> mvo, thank you for the update
[09:22] <Chipaca> hmmmmmmm
[09:22] <Chipaca> morning folks
[09:31] <Chipaca> mvo: tried reviewing the download one but all i'm seeing is bad news so i'm going to finish my coffee and look back later, maybe i'm just grumpy
[09:33] <ackk> mvo, I'm getting "Run configure hook of "maas" snap if present (run hook "configure": cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied)" when installing the maas snap, could it be something in the configure hook or is it snapd itself?
[09:42] <dot-tobias> mvo: Is there a rough date for the next stable core release? Just to get a sense if it'll be this week, next or later.
[09:45] <Chipaca> ackk: https://forum.snapcraft.io/t/cannot-perform-readlinkat-on-the-mount-namespace-file-descriptor-of-the-init-process-permission-denied/6743/7
[09:46] <mvo> Chipaca: oh no! I'm ready for bad news, I will steady myself
[09:46] <ackk> Chipaca, thanks
[09:47] <ackk> Chipaca, so I need the snapd snap, right?
[09:48] <Chipaca> ackk: … no?
[09:49] <Chipaca> ackk: sorry i'm not sure i'm being helpful at all here
[09:49] <Chipaca> ackk: are you running this on 14.04?
[09:49] <ackk> Chipaca, no, bionic
[09:49] <Chipaca> ackk: then it's not that, probably
[09:49] <ackk> Chipaca, spinned a fresh bionic container, tried snap install --edge maas
[09:50] <Chipaca> ackk: what's in 'snap version'?
[09:50]  * Chipaca should add a --irc flag to snap version
[09:51] <ackk> Chipaca, one sec, I'm testing with an up-to-date bionic now since I didn't update snapd (from the deb) there
[09:52] <Chipaca> ackk: in which case installing core or snapd would've also fixed it via snapd updating itself
[09:53] <ackk> Chipaca, fwiw https://paste.ubuntu.com/p/2rCzjTtrMM/
[09:53] <ackk> I'm trying to install the maas snap but the store is flaky
[09:54] <ackk> yeah it's not working
[09:57] <mvo> ackk: that error rings a bell, we saw this before, probably zyga knows more
[09:57] <Chipaca> ackk: "yeah it's not working" same error, or now store issues?
[09:57] <Chipaca> ackk: the store is having some issues now yes
[09:57] <ackk> Chipaca, store errors, sorry
[09:57] <ackk> yeah I can't test right now
[09:58] <ackk> mvo, btw is "core" still required for installing core18 snaps?
[09:58] <ackk> mvo, installing maas didn't install it
[09:58] <mvo> dot-tobias: iirc we did cherry pick your fix, right? the plan is to release 2.42.1 to beta this week and stable next week (if testing is all good). worst case stable in the week after that. but there is one pending branch that needs reviews :/
[09:59] <mvo> ackk: core should not be required anymore
[09:59] <mvo> ackk: on fresh systems snapd will now install core18 and snapd
[09:59] <mvo> ackk: if you request a core18 only snap
[10:00] <mup> PR snapd#7676 closed: many: cherry pick test updates for 2.42 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7676>
[10:00] <dot-tobias> mvo: Yes, it's been merged to master (though all credit to zyga). Thanks for the timeframe, I can work with that 😊
[10:01] <mvo> dot-tobias: was it cherry-picked into release/2.42?
[10:01] <mvo> dot-tobias: it will only be in 2.42.1 if it was cherry-picked, if not please point me to the PR
[10:01] <dot-tobias> mvo: Checking
[10:01] <mvo> dot-tobias: then I can (probably) cherry-pick it, I remember it was a pretty straightforward fix
[10:02] <dot-tobias> mvo: Actually, it doesn't seem to be cherry-picked into release/4.42 yet. https://github.com/snapcore/snapd/pull/7655 is zyga's PR
[10:02] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[10:04] <mvo> dot-tobias: ok - now it is :) thanks for checking
[10:06] <dot-tobias> mvo: 🙏🎉
[10:08] <mup> PR snapd#7684 opened: tests: disable mount-ns test in release/2.42 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7684>
[10:18] <pedronis> pstolowski: what's the status of #7601 ?
[10:18] <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
[10:19] <pstolowski> pedronis: i've the tab open and going to address Jamie's comment, will do today
[10:19] <pedronis> ok, thx
[10:28] <pedronis> mvo: did you make a card or something about unifying the default-provider extracting code?
[10:29] <mvo> pedronis: uh, not yet, let me do this now
[10:29] <pedronis> thx
[10:34] <Chipaca> mvo: what's that about a pending branch that needs reviews?
[10:38] <Chipaca> mvo: i see one pr each in both 2.42 and 2.43 milestones, but it looks like the 2.42 one needs input from foundations and the 2.43 has all the reviewage it can handle ;-p
[10:43] <mvo> Chipaca: the most important one is the foundations input
[10:43] <Chipaca> yeh
[10:43] <Chipaca> xnox is allegedly off gallivanting though :-p
[10:44] <mvo> Chipaca: yeah, I can try to get a re-review from vorlon for #7661
[10:44] <mup> PR #7661: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/7661>
[10:44]  * Chipaca throws flowers at vorlon 
[10:45] <mvo> Chipaca: should we have a HO about 7624 ? do you think there is something fundamentally wrong with it?
[10:45] <Chipaca> mvo: just started going through it again
[10:45] <Chipaca> mvo: download-via-snapd needs to grow a 'resume' thing, but that's a separate pr
[10:45] <mup> PR snapd#7685 opened: snapstate,devicestate: make OldModel() available in DeviceContext <Created by mvo5> <https://github.com/snapcore/snapd/pull/7685>
[10:46] <mvo> Chipaca: oh, yeah, thats a good point
[10:59] <ackk> mvo, I still see snapfuse at 100%cpu but perhaps that's expected?
[11:01] <pedronis> mborzecki: I did a first pass on 7665
[11:03] <mborzecki> pedronis: thanks
[11:03] <pedronis> mborzecki: some questions/wonderings there
[11:03] <ackk> mvo, yeah, it seems it's still quite slow in the case of maas
[11:06] <mvo> ackk: hm, ok. it should be quicker than before, can you see what version of snapd is running inside your lxd?
[11:10] <pedronis> Chipaca: hi, could you answer the question about hidden commands vs autocomplete toward the end of comments in #7589 ?
[11:10] <mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
[11:12] <ackk> mvo, https://paste.ubuntu.com/p/2rCzjTtrMM/
[11:14] <Chipaca> pedronis: probaboy
[11:14] <Chipaca> probably?
[11:19] <Chipaca> mvo: review done. Less bad news than this morning early.
[11:19] <Chipaca> mvo: still a little bad
[11:32] <Chipaca> siigh
[11:33] <Chipaca> today's already been a long day
[11:33] <Chipaca> i think i need more coffee
[11:33] <Chipaca> starting to chase shadows
[11:35] <mup> PR snapd#7686 opened: systemd: handle preseed mode <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
[11:36] <pstolowski> uhm... 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"
[11:37] <mborzecki> pstolowski: yeah
[11:38] <mborzecki> in the morning i got some 503s as well
[12:05] <mvo> Chipaca: sorry for the delay, I was in a meeting - you say this gives me no progress bar for snpa donwload but iirc we don't have one today either. or am I missing something?
[12:10] <mvo> Chipaca: hm, the code says there is a download progress, I'm just not seeing it, probably an issue on my side, I have a look. nevermind
[12:10] <pedronis> mvo: Chipaca: I meade a suggestion there
[12:11] <pedronis> *made
[12:11] <pedronis> not sure it fits or not, it was a quick thought
[12:11] <pedronis> Chipaca: thanks for the answer, I enquired some more :)
[12:19]  * zyga is at a service center and may miss standup
[12:20] <zyga> I'll make up the time in the evening to do all my responsibilities
[12:20] <zyga> sorry :/
[12:23] <Chipaca> mvo: i mean, try it: 'snap download core' gives you a nice progress bar
[12:23] <Chipaca> pedronis: did you enquire, or did you inquire?
[12:25] <mvo> Chipaca: yeah, I did something wrong, thanks for noticing this
[12:25] <pedronis> Chipaca: afaict I meant enquire
[12:26] <Chipaca> pedronis: phew
[12:27] <pedronis> pstolowski: reviewed #7683
[12:27] <mup> PR #7683: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <https://github.com/snapcore/snapd/pull/7683>
[12:31] <pedronis> pstolowski: thank you
[12:31] <pedronis> pstolowski: I also made a general comment in 7686
[12:32] <pstolowski> pedronis: ty
[12:33] <sergiusens> mvo, jdstrand, zyga: any assistance with https://paste.ubuntu.com/p/KXHFrbYmvZ/ ? This is on an autopkgtest env for 18.04/amd64
[12:36] <sergiusens> journal show Oct 29 05:37:28 autopkgtest snapd[1828]: handlers.go:460: Reported install problem for "gtk3-hello" as 2f8217c0-fa0e-11e9-b619-fa163e102db1 OOPSID
[12:37] <mvo> sergiusens: are these instances resource constrained? it looks like a malloc() (well, "new") wasn't successful, maybe(?) it requested too much memory
[12:37]  * mvo needs to urgently get lunch though before he can look deeper
[12:38] <sergiusens> mvo: get lunch, I am not so worried about the failure itself (as I know our test works on google/spread)
[12:46] <pstolowski> pedronis: i've updated #7601, would you like to take a look at this as well or can it land when green?
[12:46] <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
[12:46] <pedronis> pstolowski: no, it's probably fine if zygmunt and jamie are ok with it
[12:48] <pstolowski> ack
[12:48] <pedronis> pstolowski: I mean, I can look if you think I should
[12:49] <pstolowski> pedronis: maybe just check the comment & response re locking there. i don't think there was a deep reason it was done the way it was
[12:49] <pedronis> ok
[12:50] <pedronis> pstolowski: I put it in my queue, I will also merge it if everything is fine
[12:55] <pstolowski> pedronis: thanks
[13:17] <Chipaca> pedronis: should I do the 'hidden-but-completed' thing?
[13:17] <pedronis> Chipaca: if you can, and is not too distracting, yes
[13:17] <Chipaca> it's not, right now
[13:22] <Eighth_Doctor> popey_, zyga, mborzecki, mvo: I've finally introduced `snapd` for EL8
[13:23] <Eighth_Doctor> that was a more annoying bringup than I thought it would be
[13:23] <mborzecki> but it's done now :P
[13:24] <Eighth_Doctor> yeah, I'll do a PR to snapd upstream with a spec sync soon
[13:25] <Eighth_Doctor> I haven't done one of those in a while
[13:30] <zyga> Eighth_Doctor: thank you for persisting, congratulations!
[13:31] <Eighth_Doctor> between broken architectures and missing packages due to incomplete imports, I wasn't certain EL8 was ever going to get built
[13:36] <mborzecki> Eighth_Doctor: if you take away these problems, there's no more excitement in getting things done
[13:36] <Eighth_Doctor> I guess so
[13:37] <Eighth_Doctor> but I didn't enjoy people bitching about updated snapd releases being held up
[13:43] <jdstrand> sergiusens (cc mvo, zyga): that is the memory consumption bug
[13:44] <jdstrand> sergiusens (cc, mvo, zyga): can you try edge?
[13:44] <Chipaca> mvo: silly question: i just noticed the completion helper for 'snap' in 1604 is ancient, is the update on its way / stuck somewhere?
[13:44] <jdstrand> sergiusens: zyga did excellent PR work to fix that which is committed, and may even end up in 2.42.2 (not sure of the status of that)
[13:45] <jdstrand> or is it 2.42.1 (did I say I'm not sure of the status of 2.42.N? :)
[13:47] <mvo> Eighth_Doctor: e8> nice! thanks so much!
[13:48] <mvo> jdstrand: 2.42.1 once we get it out, pending one review from xnox or vorlon (7661)
[13:48] <mvo> Chipaca: could you tell me some more details? is the completion helper part of bash-completion there?
[13:49] <Chipaca> mvo: I mean data/completion/snap that gets shipped to /usr/share/bash-completion/completions/snap
[13:49] <jdstrand> mvo: cool, thanks :)
[13:50] <Chipaca> mvo: this is not about completion of snapped commands
[13:50] <jdstrand> mvo: I wouldn't mind 2.42.1 with that change myself :)
[13:50] <Chipaca> mvo: but of the snap command itself
[13:50] <Chipaca> mvo: an easy way to check: snap debug <tab>, vs snap debug model <tab>
[13:50]  * zyga blushes :-)
[13:51] <mvo> jdstrand: I cherry picked it already :)
[13:51] <Chipaca> mvo: with the one in-tree, that second one should not offer all debug commands all over again
[13:52] <mvo> Chipaca: what do we need to do to update it? (sorry, I still don't have the full picture but hopefully I'm getting there :)
[13:52] <Chipaca> mvo: I don't know :) the one in-tree was fixed in August
[13:53] <Chipaca> mvo: how does the .deb pick that up? maybe the .deb is older than august?
[13:53] <Chipaca> or the release
[13:54] <Chipaca> i guess august on master means september release so it's not unpossible for this to be alright just lagged
[13:54] <mvo> Chipaca: aha, got it now - yes, I think we want 2.42.1
[13:54] <mvo> Chipaca: we have no deb update in a while because of various issues
[13:54] <Chipaca> ah
[13:54] <Chipaca> a'ight then
[13:54] <mvo> Chipaca: one of which is this postinst PR review :)
[13:54] <Chipaca> mvo: are we going to be able to update before 16.04.<whatever>?
[13:55] <Chipaca> mvo: because images don't ship packages from -updates so snapcraft hates us
[13:55] <Chipaca> because there's all these neat features they can't depend on or sth
[13:55] <Chipaca> anyway, snowballing moaning doesn't hep
[13:55] <Chipaca> help*
[13:55] <Chipaca> i need to get ready for standup
[13:55] <mvo> Chipaca: woah, let me look
[13:58] <mvo> Chipaca: me too - I fixed the issues in download but I guess this could need a refactor to unify a bit of this code
[13:59] <mup> PR snapd#7687 opened: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>
[14:00] <jdstrand> mvo: re cherrypic, yep, thanks! looking forward to 2.42.1 in a channel somewhere :) (not pushing, just enthusiastic :)
[14:01] <mvo> jdstrand: :)
[14:02] <jdstrand> mvo: also, I heartily endorse the approach for snap-confine in 7661
[14:02] <jdstrand> mvo: that'll be real nice to finally have fixed :)
[14:06] <mvo> jdstrand: \o/
[14:06] <sergiusens> jdstrand: cannot easily try edge on autopkgtests, will try later though, thanks
[14:13] <Chipaca> cachio: BTW there are 63520800 ways of getting 3 tests out of 400 so the fact that you found a failing combination is quite something
[14:18] <jdstrand> sergiusens: with the fact that it is a gtk3-hello demo which I bet is using the content interface, I'm inclined to say, don't worry about it for now since it will be fixed soon. if it is happening after 2.42.1 is in stable, report back (cc mvo)
[14:18]  * mvo had the same thoughts
[14:26] <cachio> Chipaca, there are pretty good search techniques :)
[14:26] <jdstrand> pstolowski: hey, fyi, this is what I meant to say before: https://github.com/snapcore/snapd/pull/7601#discussion_r340101086
[14:26] <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
[14:35] <mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
[14:35] <mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[14:38] <mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
[14:38] <mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[14:44] <pstolowski> jdstrand: ok, i see, right. i was thinking if the unlocking/locking there was deliberate or not. semantically it looks irrelevant to me and if it had any sideffects it would be a bit fishy tbh. either way it's impossible to test / prove. maybe pedronis can recall something
[14:53] <pedronis> pstolowski: I'm having a break and then I will look at that PR
[14:55] <pstolowski> ty
[14:57] <om26er> private jobs have taken over https://launchpad.net/builders ...
[15:00] <cachio> mborzecki, hey, could yo utake a look to #7681
[15:00] <mup> PR #7681: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
[15:00] <cachio> please
[15:00] <mup> PR snapd#7688 opened: cmd/snap: make completion skip commands (& opts) that ask for it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7688>
[15:00] <cachio> It is confirmed the start-limit-hit issue on core-18
[15:01] <Chipaca> om26er: private jobs do that
[15:05] <jdstrand> pstolowski: ack, not a blocker or anything. thanks for thinking about it
[15:07] <pstolowski> jdstrand: sure, thanks for the review!
[15:15] <pstolowski> mvo, pedronis: ah, i forgot about the fix for the issue of services & install hook that we want to fix for pre-seeding, and it needs ijohnson's #7341
[15:15] <mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7341>
[15:16] <pstolowski> i mean #7431
[15:16] <mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
[15:16] <ijohnson> pstolowski: I should update that PR with your suggestions later today, I implemented them just need to finish testing that the spread tests still work with my changes
[15:17] <pstolowski> ijohnson: that's great, thanks
[15:17] <Chipaca> mvo: you mind if i push some code to #7624?
[15:17] <mup> PR #7624: snap: make `snap download` download via snapd if available <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
[15:18] <Chipaca> not saying i will, but i might
[15:22] <ijohnson> hmm it's rather confusing for github's PR diff files view that for a line changed, the "unexpanded" snippet which shows the function/unindented block of code the line is in doesn't account for the fact that the "unexpanded" part itself also changed
[15:23] <cachio> zyga, could yo uplease re-review #7681
[15:23] <mup> PR #7681: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
[15:23] <cachio> I added a fix there
[15:23] <cachio> thansk
[15:24] <pedronis> pstolowski: mmh, are we losing the timing in 7601 ?
[15:28]  * cachio lunch
[15:30] <pstolowski> pedronis: we're passing it to SetupMany, it's measured there
[15:30] <pedronis> ah
[15:30] <pstolowski> indentation is a bit weird
[15:34] <pedronis> pstolowski: sorry, yes, I missed it
[15:34] <pedronis> pstolowski: I commented a bit more on the lock thing
[15:35] <pedronis> pstolowski: and gave my +1
[15:35] <pedronis> pstolowski: it can land when it is green
[15:36] <pedronis> Chipaca: I commented on 7688
[15:36] <Chipaca> pedronis: i saw
[15:36] <Chipaca> pedronis: we can always think more :)
[15:36] <pedronis> Chipaca: I can see a couple of ways out
[15:36] <zyga> cachio: doing so now
[15:36] <pstolowski> pedronis: thank you, yes, exactly what i was thinking
[15:38] <zyga> cachio: interesting
[15:38] <zyga> cachio: does this mean we can make journalctl fail if we just restart the service in a loop?
[15:38] <pedronis> Chipaca: we could add code to stick (hidden) at the end of any description of hidden command that don't have it on their own. And have a flag to stop that
[15:38] <zyga> cachio: if we could do that without any snapd stuff in the way, we could report a bug upstream
[15:38] <zyga> cachio: it feels like explicit requests should not be counted towards the number of after which the service is not started
[15:39] <Chipaca> pedronis: a contra to that is that we'd have to reflect the structs ourselves
[15:40] <pedronis> Chipaca: ?
[15:40] <Chipaca> to get the other flag
[15:40] <Chipaca> unless you meant a flag to addCommand
[15:40] <Chipaca> not a struct tag
[15:41] <Chipaca> (my first read was that you meant a struct tag, like hidden:"true" completed:"true"
[15:41] <pedronis> Chipaca: we have our own flags on cmdInfo
[15:41] <Chipaca> right
[15:41] <zyga> kenvandine: hey, personal question
[15:42] <zyga> kenvandine: where can I report a bug on gnome-shell where someone I can talk to will look
[15:42] <kenvandine> zyga: 7
[15:42] <kenvandine> :)
[15:42] <pedronis> Chipaca: can we key on Item somehow? can it be partial, how does that bit work?
[15:42] <zyga> kenvandine: I have this pet bug of mine that is very frustrating
[15:42] <zyga> kenvandine: and probably something silly somewhere
[15:42] <kenvandine> ping Trevinho :)
[15:42] <zyga> kenvandine: high-dpi in vmware results in white background
[15:42] <zyga> low-dpi is ok,
[15:42] <zyga> background shows
[15:42] <Trevinho> pong
[15:42] <zyga> kenvandine: all you need to do is to toggle 200% zoom
[15:42] <zyga> and you get white background
[15:42] <pedronis> Chipaca: I mean, we could also keep global maps Item -> flags, or Description -> flags (assuming they are unique enough)
[15:42] <kenvandine> that's annoying
[15:42] <zyga> this bug was around for about a year now
[15:43] <zyga> but I never reported it, hoping someone would notice and it wouldn't be just my machine
[15:43] <zyga> but now I just want to report it
[15:43] <zyga> because maybe my machine has something useful on it
[15:43] <zyga> it happens in vmware fusion on both my macbook and my imac
[15:43] <zyga> it happens in not just ubuntu
[15:43] <Trevinho> mhmh, ah so the problem is the guest
[15:43] <zyga> all gnome shell is affected
[15:43] <zyga> (opensuse, fedora, debian and ubuntu for sure)
[15:43] <zyga> perhaps it's some texture size limit
[15:43] <zyga> or something of this nature
[15:43] <zyga> but
[15:44] <zyga> it's a new thing
[15:44] <zyga> it did work great about a year ago, using same older VMs works good now
[15:44] <Trevinho> zyga: always in x11 or wayland?
[15:44] <zyga> let me check
[15:44] <zyga> x11
[15:44] <zyga> but double checking now
[15:44] <Chipaca> pedronis: go-flags figures out what things to complete, and we then get the list of whole names even if it's completing a partial
[15:44] <Trevinho> zyga: and also using new vmware + old ubuntu?
[15:44] <zyga> yes
[15:44] <zyga> Trevinho: it's just new gnome/kernel perhaps that causes this
[15:45] <zyga> one sec
[15:45] <zyga> Trevinho: it happens in x11, let me log out into wayland
[15:45] <pedronis> Chipaca: ok, so it sound we could make a map in addCommand as well, instead of looking at the description
[15:45] <zyga> it's also 100% reproducible on my machines using latest version of everything, I can toggle back and forth
[15:45] <pedronis> though in principle I have nothing agaisnt sticking (hidden) there,  it's true
[15:46] <zyga> Trevinho: it affects x11 and wayland equally
[15:46] <zyga> everything works great at 100% zoom in 5K
[15:46] <zyga> in 200% zoom everything but background displays fine
[15:46] <zyga> looking at logs now
[15:46] <om26er> Is https://snapcraft.io/blog/handy-snapcraft-features-remote-build in the stable channel now ? Also can we use that to build private projects and how is the code actually pushed to launchpad builders ?
[15:46] <Chipaca> pedronis: yes, we could. Assuming you mean a map of just things to skip, and there weren't synonyms where we wanted to skip only one of them, then it'd probably work
[15:47] <pedronis> Chipaca: yes, just the one to skip
[15:47] <om26er> IOW is it secure ?
[15:47] <Chipaca> pedronis: note we only get the last command
[15:47] <pedronis> ?
[15:47] <zyga> Trevinho: in wayland, toggling 200% zoom gives me
[15:47] <Chipaca> om26er: it is secure but as it says there your build is public
[15:47] <Chipaca> pedronis: 'snap debug foo' → you get "foo"
[15:47] <zyga> Trevinho: wayland journal fragment after setting 200% zoom https://www.irccloud.com/pastebin/beonJbDn/
[15:48] <pedronis> Chipaca: I see, so we cannot use item
[15:48] <pedronis> but we can use description
[15:48] <pedronis> assuming they are unique
[15:48] <pedronis> and they should be really
[15:48] <pedronis> except for a few degenerate cases that we can accept
[15:48] <pedronis> like "Internal (hidden)"
[15:49] <zyga> Trevinho: x11 journal fragment after setting 200% zoom https://www.irccloud.com/pastebin/6Wm8NA5u/
[15:49] <zyga> Trevinho: I can report that, just point me the way
[15:49] <pedronis> Chipaca: shortHelp is description ?
[15:49] <zyga> thank you for looking and I'd love to know if you have any ideas
[15:49] <pedronis> for commands
[15:49] <Chipaca> pedronis: yes
[15:50] <Trevinho> zyga: don't think journal is saying anything wrong, unless edid, but shouldn't matter for this
[15:50] <zyga> yeah, apart from the background there are no problems
[15:50] <Trevinho> zyga: better if you report it at https://gitlab.gnome.org/GNOME/mutter/issues
[15:50] <zyga> Trevinho: nothing fails, 3D works, all the apps work flawlessly
[15:50] <zyga> Trevinho: sure thing
[15:50] <om26er> @chipaca that's not a problem, we want to release the software for everyone but the source code model is closed for now
[15:51] <Chipaca> om26er: but if the build is public, the source is public
[15:51] <Chipaca> om26er: as i read it at least
[15:52] <Trevinho> zyga: also when setting 200 the WM is using native 2x or zooming?
[15:52] <Chipaca> om26er: maybe confirm with somebody that knows :)
[15:52] <Trevinho>  xprop -root RESOURCE_MANAGER
[15:52] <zyga> Trevinho: I don't know the difference
[15:52] <Trevinho> and maybe you can -spy that whiele changing the value
[15:52] <zyga> let me get that output for you :)
[15:52] <zyga> sure
[15:52] <Trevinho> (just use -spy :))
[15:52] <Trevinho> zyga: well, it's not stretched I imagine, right?
[15:53] <Trevinho> it's just asking the WM to use proper scaling I assuem
[15:53] <zyga> Trevinho: no, it's all nice and pretty all the time
[15:53] <Trevinho> assume*
[15:53] <pstolowski> pedronis: was your suggestion to also avoid 'preseed' term in the apparmor/security backend?
[15:53] <om26er> Chipaca not sure who works on the build service these days, is Colin (cj watson) the right person ?
[15:54] <pedronis> pstolowski: no, there is fine I think
[15:54] <pedronis> I mean it's ok if you want to use a different term
[15:54] <pedronis> like DiskOnly or something
[15:54] <pedronis> but preseed would work too
[15:54] <pstolowski> pedronis: ok, cause emulation indeed wouldn't fit
[15:54] <zyga> Trevinho: RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t24\nXcursor.theme:\tYaru\n"
[15:54] <zyga> Trevinho: not sure how to use -spy
[15:55] <Trevinho> just pass -spy, it will print you something if it changes
[15:55] <Trevinho> zyga: that's at 200%?
[15:55] <zyga> Trevinho: yes
[15:55] <zyga> Trevinho: let me give you output at both
[15:55] <zyga> I'm in x11 now
[15:55] <zyga> though that matters for xprop
[15:55] <Trevinho> weird, so... mh not really using internal scaling...mhmh
[15:56] <zyga> https://www.irccloud.com/pastebin/oWGjJE9b/
[15:56] <Trevinho> a scaled system should have Xft.dpi = scale*96
[15:56] <zyga> this ix xprop -root -spy
[15:56] <zyga> *this is xprop -root spy
[15:56] <zyga> when going from low to high dpi
[15:56] <zyga> Trevinho: let me double check if I got those initial output bits right
[15:56] <Trevinho> ah, ok it changes to 192, it makes sense then
[15:56] <Trevinho> I saw already, yeah... it's just showing things at 2%
[15:57] <zyga> Trevinho: so at 200% it is: RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t192\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t48\nXcursor.theme:\tYaru\n"
[15:57] <Trevinho> so, weird. Cause there's should no difference between that and normal 2x scaling (normal = native)
[15:57] <zyga> Trevinho: and at 100% it is
[15:57] <zyga> RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t24\nXcursor.theme:\tYaru\n"
[15:57] <Trevinho> yeah makes sense
[15:57] <pedronis> Chipaca: I played a bit and indeed our description are basically unique, so that idea would work
[15:57] <zyga> Trevinho: anything else I can try?
[15:57] <Chipaca> pedronis: is it worth it?
[15:58] <Trevinho> zyga: mh, no in the top of my head, should probably do some deeper debugging.
[15:58] <zyga> ok
[15:58] <zyga> let me report the issue
[15:58] <pedronis> Chipaca: less magic, so yes
[15:58] <zyga> what to include in the report?
[15:58] <pedronis> Chipaca: it's fairly simple I think
[15:58] <Trevinho> zyga: I use vmware player here, and I don't think that has the option visible
[15:59] <pedronis> Chipaca: anyway probably simple enough that I should pick up your PR and try to fit it in there
[15:59] <Trevinho> but I assume I can have the same by changing manually the conf fike
[15:59] <Trevinho> file*
[15:59] <cmatsuoka> zyga: patriciadomin needs more space for snap data, would it work if she just moves /var/snap to a different filesystem?
[15:59] <zyga> Trevinho: I think it's a fusion thing, on a high-dpi display you get to choose to give the VM the full resolution or to give it a scaled down version (e.g. for older OSes)
[15:59] <zyga> cmatsuoka: yes, it should work perfectly
[15:59] <pedronis> Chipaca: but maybe your point is that you think that by default hidden commands should auto complete?
[16:00] <cmatsuoka> zyga: thanks!
[16:00] <Trevinho> zyga: if you instead change the option internally from the VM only?
[16:00] <ijohnson> pedronis: reviewed #7679
[16:00] <mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
[16:00] <Trevinho> i.e from g-c-c, as that's what I'm doing here all the times, but never had such issue
[16:00] <zyga> Trevinho: this is internally in the VM
[16:00] <zyga> Trevinho: I didn't change the vmware fusion settings
[16:00] <zyga> Trevinho: (having that high-dpi screen really makes me want to use the high-dpi for daily work)
[16:00] <Trevinho> ah, but well fusion I suppose is doing something different the
[16:01] <zyga> Trevinho: so to be clear, the VM on the host has a setting toggled to enable "retina" resolution (native resolution of the panel)
[16:01] <zyga> Trevinho: if you toggle that down the VM gets told that resolution is half in each dimension
[16:01] <Trevinho> although I've not used this in a very high dpi screen, but simulating it shoudl be the same
[16:01] <zyga> Trevinho: and there's no 200% zoom to choose from
[16:01] <Chipaca> pedronis: no, i'm not sure what my point is, but that is not it :)
[16:01] <pedronis> Chipaca: ok, I'll try to push a PR based on yours and then we can discuss something concrete
[16:02] <Chipaca> pedronis: ok
[16:02] <Trevinho> zyga: ah, I see then. But well in the normal case it should just give the same display size so...
[16:02] <zyga> yeah
[16:02] <pedronis> Chipaca: in a bit
[16:02] <Trevinho> basically the same of the player
[16:02] <Trevinho> zyga: by luck changing the bg image rebuilds anything and makes it appear or no?
[16:02] <zyga> Trevinho: let me check
[16:02] <zyga> but I think not
[16:03] <Trevinho> in theory should not be the same of what happens on resolution changes, but.. sometimes.. :)
[16:03] <zyga> Trevinho: nope, no luck
[16:03] <Trevinho> zyga: this seems close https://gitlab.gnome.org/GNOME/gnome-shell/issues/1175
[16:03] <zyga> yeah!
[16:05] <Trevinho> could be texture size problem indeed
[16:05] <zyga> Trevinho: https://gitlab.gnome.org/GNOME/mutter/issues/894
[16:05] <Trevinho> I suppose in some cases it should be tiled
[16:05] <zyga> Trevinho: I'll grab lunch (starving) and be back soon
[16:05] <zyga> Trevinho: oh actually, I think I could set a background *color* correctly
[16:05] <zyga> now this option seems gone
[16:06]  * Chipaca ⇝ tea
[16:06] <Trevinho> zyga: I've marked as duplicate, feel free to copy&paste that text to the original bug so we don't loose the comment :)
[16:06] <Trevinho> sorry, I linked it too late
[16:08] <Trevinho> looks like something introduced during the 3.32 cycle though, so if running a machine with 3.30 is working, maybe would be nice to bisect 3.32 branches
[16:12] <om26er> I have python3.8 in a snap and a snapcraft plugin allowing other snaps to use python3.8 https://forum.snapcraft.io/t/introducing-python3-8-as-a-snap/13923
[16:15] <pedronis> ijohnson: thansk for the reviews, I tried to answer all the questions
[16:15] <ijohnson> pedronis: cool looking now
[16:17] <ijohnson> pedronis: thanks for the explanations, lgtm still
[16:18] <pedronis> thank you
[16:24] <cachio> zyga, hey, so, we can make it fail in a loop but just on ubuntu core
[16:24] <cachio> it is not reproduced on classic
[16:26] <vorlon> mvo, Chipaca: sorry, my slowness in reviewing that PR (aside from being sick yesterday) is that the PR is of course only showing me the delta vs the latest commit, and what I actually care about is the delta vs the current version of the packaging in bionic.  I'll get to it today
[16:30] <mvo> vorlon: thank you, sorry for being so pushy about it
[16:30] <Chipaca> mvo: do you know the tag of most-recently-in-bionic ?
[16:30] <Chipaca> git tag i mean
[16:31] <mvo> Chipaca: one sec, looking
[16:33] <mvo> Chipaca: commit adee89d789e452c9d12a90625865954cae448d42 (tag: 2.40)
[16:35] <zyga> Trevinho: thank you
[16:35] <zyga> cachio: interesting, wonder why there
[16:35] <zyga> cachio: and if you copy the config to a regular system, can we make it fail there?
[16:36] <cachio> zyga, didn0't try that
[16:36] <cachio> let me try
[16:36] <zyga> cachio: perhaps it's something specific to the config we use on core
[16:36] <zyga> cachio: cool, good luck
[16:47] <Chipaca> mvo: 2.40, or release/2.40?
[16:51] <mvo> Chipaca: tag is "2.40"
[16:56] <Chipaca> gah, github does not help with this
[16:56] <Chipaca> vorlon: sorry :) best i can do is say git diff 2.40 mvo5/snap-confine-conffile -- packaging/ubuntu-16.04
[16:57] <Chipaca> but that's not particularly useful :)
[16:57] <mup> PR snapd#7689 opened: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <https://github.com/snapcore/snapd/pull/7689>
[16:57] <Chipaca> it's http://paste.ubuntu.com/p/ZZ4nK4Byq9/ fwiw
[16:58] <cachio> zyga, well I found that it also fails on classic
[16:59] <zyga> cachio: that's good, closer to reproducer for a bug report
[16:59] <cachio> zyga, https://paste.ubuntu.com/p/jqdCqX7sTn/
[16:59] <mvo> Chipaca: nice!
[17:00] <zyga> cachio: why "not systemctl restart"?
[17:00] <mvo> Chipaca: I pushed 7689 that probably should land before we land 7624 (tweaks the api a little bit for things we need)
[17:00] <cachio> zyga, we restart until it fails
[17:01] <zyga> ah, I see
[17:01] <cachio> what we see is that when the tests run fast
[17:01] <cachio> the service fails to be restarted
[17:01] <cachio> and it is because we are reaching the start limit
[17:02] <zyga> cachio: would be worth to report a bug on upstream systemd project with the question if manual restarts should count towards the failure counter
[17:02] <zyga> cachio: perhaps we should reset the failure state
[17:02] <zyga> cachio: and try again?
[17:03] <cachio> reset the failut state?
[17:03] <zyga> yes
[17:03] <cachio> zyga, how can I do that?
[17:03] <zyga> cachio: one sec
[17:03] <zyga> there's a command for it
[17:03] <zyga> it's pretty rarely used
[17:04] <cachio> zyga, ahh, nice
[17:05] <zyga> cachio: systemctl reset-failed
[17:05] <zyga> cachio: note that we could do something else
[17:05] <zyga> cachio: run systemctl _stop_ to stop the journal
[17:05] <zyga> sync
[17:05] <zyga> to let various IO buffers stabilize
[17:05] <zyga> cachio: then start again
[17:06] <zyga> cachio: the sync in the middle may give everything enough time to actually not choke
[17:06] <zyga> cachio: but if stop or start fails, we could run the reset-failed command to see if we can try again
[17:06] <cachio> zyga, let me try it
[17:06] <zyga> cachio: good luck, I have not tried that, maybe it won't lead anywhere
[17:06] <zyga> but maybe it will
[17:08] <cachio> using stop / sync / start
[17:09] <cachio> works well
[17:09] <cachio> rexec 20 times without error
[17:09] <zyga> cachio: worth giving it a shot
[17:12] <cachio> zyga, fix pushed
[17:12] <zyga> cachio: super
[17:12] <zyga> cachio: thank you!
[17:12] <cachio> zyga, to you
[17:19] <mvo> pedronis: you may want to check https://github.com/snapcore/snapd/pull/7689 just to make sure that the chosen name (client.DownloadInfo) is ok. happy to adjust as needed
[17:19] <mup> PR #7689: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <https://github.com/snapcore/snapd/pull/7689>
[17:19] <mup> PR snapd#7690 opened: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7690>
[17:19] <pedronis> Chipaca: #7690 is what I had in mind
[17:19] <mup> PR #7690: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7690>
[17:20] <pedronis> mvo: seems fine
[17:21] <Chipaca> hehe
[17:24] <pedronis> Chipaca: ?
[17:25] <Chipaca> pedronis: reviewed
[17:25] <Chipaca> pedronis: "hehe" because you called it 'autocomplete', and the flag 'autocompletHidden' (sic)
[17:26] <Chipaca> pedronis: when it's completion, not autocompletion
[17:26] <pedronis> Chipaca: it's funny because people call it autocompletion but is not the correct term?
[17:27] <Chipaca> pedronis: on the phone it is
[17:27] <Chipaca> pedronis: who calls it autocompletion on the terminal?
[17:27]  * Chipaca googles
[17:27] <pedronis> me apparently
[17:27] <pedronis> living in the future
[17:27] <Chipaca> pedronis: you and 190k+ people
[17:27] <Chipaca> pedronis: vs 6M+ for just 'completion'
[17:28] <Chipaca> pedronis: you're the 3%
[17:28] <zyga> Chipaca: this autocompletes this problem
[17:28] <zyga> ;-)
[17:28] <pedronis> Chipaca: the flag is the override, so don't need to set on first boot, I need to set it on any hidden command we still want to auto complete
[17:29] <pedronis> mostly the key stuff I think
[17:29] <Chipaca> zyga: https://i.imgur.com/9HY53al.gif
[17:29] <Chipaca> pedronis: d'oh! obvs
[17:29] <zyga> my day is autocomplete now
[17:30] <Chipaca> zyga: https://i.imgur.com/NJZgC1W.gif
[17:30] <mup> PR snapd#7691 opened: builtin/browser_support.go: allow monitoring process memory utilizati… <Created by Erick555> <https://github.com/snapcore/snapd/pull/7691>
[17:39] <pedronis> Chipaca: fixed and marked some commands back
[17:39] <vidal72[m]> what "disabled" mean under "notes" in "snap list" outpout?
[17:40] <Chipaca> vidal72[m]: that the snap is not enabled
[17:40] <Chipaca> vidal72[m]: i.e. that it is not even mounted
[17:40] <Chipaca> vidal72[m]: or, if you're seeing 'snap list --all', that it is not current
[17:40] <Chipaca> vidal72[m]: why?
[17:42] <vidal72[m]> Chipaca: it seems my snap was during self-update, now "disabled" is gone
[17:48] <pedronis> Chipaca: wonder if this means we would like: snap debug commands  to list them all anyway
[17:48] <Chipaca> pedronis: say again?
[17:49] <pedronis> Chipaca: do we need a way to show all the commands implemented
[17:49] <pedronis> before this PR you could
[17:49] <pedronis> "snap " <TAB> away to that
[17:49] <Chipaca> pedronis: i don't think we do
[17:49] <pedronis> now not anymore
[17:49] <pedronis> Chipaca: ok
[17:49] <Chipaca> pedronis: «GO_FLAGS_COMPLETION=1 snap ""» fwiw
[17:50] <pedronis> Chipaca: that will not show the hidden ones now
[17:50] <Chipaca> pedronis: i know, i'm just saying you to get it non-interactively
[17:50] <pedronis> yea
[17:50] <pedronis> I mean that command to list commands, for us, not in general
[17:54] <Chipaca> pedronis: i don't think we need it, but we can add it if we do
[17:58] <Chipaca> i'ma EOD
[18:07] <mup> Bug #1584590 changed: Snap install download progress neatening up <snapd:Confirmed> <https://launchpad.net/bugs/1584590>
[18:07] <mup> Bug #1616629 changed: could not unmarshal state entry "snap-type" <canonical-bootstack> <snapd:Confirmed> <https://launchpad.net/bugs/1616629>
[18:10] <mup> Bug #1574103 changed: Raspberry Pi 2 image LEDs are swapped. <snapd:In Progress by maciek-borzecki> <https://launchpad.net/bugs/1574103>
[18:10] <mup> Bug #1630789 changed: normal users can't run snaps inside of LXD containers <verification-needed> <snap-confine:Fix Released by jdstrand> <snapd:Fix Released by tyhicks> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by tyhicks> <snap-confine (Ubuntu Xenial):Fix
[18:10] <mup> Committed> <snap-confine (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1630789>
[18:13] <mup> Bug #1664383 changed: running snap list <snap> on a system that has no snaps installed exits 0 <conjure-up> <snapd:Fix Released> <https://launchpad.net/bugs/1664383>
[18:14] <zyga> sil2100: hello, can you please enqueue looking at https://bugs.launchpad.net/snappy/+bug/1701018 tomorrow
[18:14] <mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:Confirmed> <https://launchpad.net/bugs/1701018>
[18:15] <zyga> there are open PRs and I think someone should have a look at them, decide which way to go and update the bug report
[18:16] <mup> Bug #1721676 changed: implement errno action logging in seccomp for strict mode with snaps  <verification-done-xenial> <verification-done-zesty> <snapd:Fix Released by tyhicks> <linux (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu Xenial):Fix Released by tyhicks> <linux (Ubuntu Zesty):Fix
[18:16] <mup> Released by tyhicks> <linux (Ubuntu Artful):Fix Released by tyhicks> <https://launchpad.net/bugs/1721676>
[18:19] <mup> Bug #1708527 changed: Add /proc/partitions to system-observe <snapd-interface> <snapd:Fix Released> <https://launchpad.net/bugs/1708527>
[18:23] <mup> PR snapd#7688 closed: cmd/snap: make completion skip commands (& opts) that ask for it <Created by chipaca> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7688>
[18:25] <mup> Bug #1583975 changed: ubuntu IoT - webcam-demo 1.0.2 - apparmor="DENIED" operation="open" profile="webcam-demo.canonical_webcam-demo_1.0.2" name="/dev/video0" pid=3898 comm="fswebcam" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 <snapd:Fix Released> <https://launchpad.net/bugs/1583975>
[18:25] <mup> Bug #1648431 changed: Allow snaps to shadow mounts from core <snapd:Fix Released by kalikiana> <https://launchpad.net/bugs/1648431>
[18:25] <mup> Bug #1649837 changed: Can remove required-snaps <snapd:In Progress by pedronis> <https://launchpad.net/bugs/1649837>
[18:27] <zyga> pedronis: kind request to look at the bug https://bugs.launchpad.net/snapd/+bug/1649837 and check if the state can be updated now
[18:27] <mup> Bug #1649837: Can remove required-snaps <snapd:In Progress by pedronis> <https://launchpad.net/bugs/1649837>
[18:28] <mup> Bug #1650689 changed: Channel switching (track new channel) does not work if the two channels happen to have identical snap packages <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1650689>
[18:30] <pedronis> zyga: we never implemented a patch so it's still not finished, now that we have idempotent patches maybe we can finish it
[18:31] <zyga> pedronis: thank you, I'll update the bug
[18:35] <zyga> mvo: are you still working by any chance?
[18:40] <mup> Bug #1659534 changed: userdel doesn't supports extrausers <patch> <verification-done-bionic> <verification-done-xenial> <Snappy:Fix Released> <shadow (Ubuntu):Fix
[18:40] <mup> Released> <shadow (Ubuntu Xenial):Fix Released> <shadow (Ubuntu Bionic):Fix Released> <shadow (Ubuntu Cosmic):Confirmed> <https://launchpad.net/bugs/1659534>
[18:40] <mup> Bug #1660879 changed: snap refresh with more than one argument produces poor error message <snapd:Fix Released> <https://launchpad.net/bugs/1660879>
[18:40] <mup> Bug #1661436 changed: snap download can't find snaps from a branded store <snapd:In Progress> <https://launchpad.net/bugs/1661436>
[18:53] <mvo> zyga: ish, what can I do for you?
[19:02]  * cachio afk
[19:07] <zyga> ah, sorry, I went upstairs for some tea
[19:11] <mup> Bug #1661590 changed: GNOME Software only supports running one application from a snap <verification-done-xenial> <GNOME Software:Fix Released> <Snappy:Fix Released> <gnome-software (Ubuntu):Fix Released by robert-ancell> <gnome-software (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu
[19:11] <mup> Artful):Won't Fix> <gnome-software (Ubuntu Bionic):Fix Released by robert-ancell> <https://launchpad.net/bugs/1661590>
[19:14] <mup> Bug #1693423 changed: initramfs error while loading Custom ubuntu core Image on X86 but it works fine in KVM <Snappy:Invalid> <https://launchpad.net/bugs/1693423>
[19:25] <mup> PR snapcraft#2778 closed: Release changelog for 3.9 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2778>
[20:23] <zyga> re
[20:23]  * zyga managed to put Lucy to bed
[20:23] <zyga> back to bug review
[20:31] <mup> PR snapcraft#2779 opened: ci: switch to travis workspaces <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2779>
[21:06] <mup> PR snapd#7692 opened: tests: opensuse tumbleweed has similar issue than arch linux with snap --strace <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7692>
[21:54] <mup> PR snapd#7601 closed: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Needs Samuele review> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7601>
[22:16] <om26er> Hi! I landed a pull request for a project that has been setup for snapcraft automatic builds but it seems the build didn't start
[22:16] <om26er> https://build.snapcraft.io/user/crossbario/crossbar
[22:17] <om26er> Here is the relevent PR https://github.com/crossbario/crossbar/pull/1649
[22:17] <mup> PR crossbario/crossbar#1649: Base snap on python 3.8 <Created by om26er> <Merged by om26er> <https://github.com/crossbario/crossbar/pull/1649>
[22:19]  * zyga EODs
[22:19] <zyga> ttyl
[23:50] <sil2100> zyga: ACK! Will look!