[01:32] <mup> PR snapcraft#2426 opened: tests: use fixed version for idna in plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2426>
[05:16] <brlin> Good afternoon, from UTC+8
[05:54] <brlin> I noticed that `snapcraft init` adds a recipe that asserts `base: core18`, is that indicate that it is now recommended to use core18 as the base instead of core16?
[06:22] <mborzecki> morning
[06:22] <mvo> mborzecki: hey
[06:23] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/6297 ?
[06:23] <mup> PR #6297: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
[06:23] <mvo> sure
[06:23] <mborzecki> mvo: we'll need to cherry pick that patch to 2.36
[06:24] <mvo> mborzecki: ok - should we run sepolgen-ifgen as part of the tests?
[06:25] <mborzecki> mvo: yes, that's a good idea, i'll add it to the selinux PRs
[06:25] <mvo> mborzecki: I merged this one now
[06:25] <mborzecki> mvo: thanks
[06:26] <mvo> and cherry-picked, so all good
[06:26] <mvo> thank you!
[06:26] <mborzecki> mvo: great, thanks!
[06:26] <mup> PR snapd#6297 closed: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6297>
[06:27] <mborzecki> and added a card :)
[06:37] <mborzecki> another trivial PR https://github.com/snapcore/snapd/pull/6298
[06:37] <mup> PR #6298: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>
[06:38] <mup> PR snapd#6298 opened: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>
[06:54] <zyga> Good morning
[06:54] <mborzecki> zyga: hey
[06:55] <mvo> hey zyga
[07:10] <zyga> :-)
[07:23] <zyga> sorry, a bit sleepy still
[07:23] <zyga> I stayed up late and fixed my TV
[07:24] <zyga> mborzecki: trivial removal of dead code: https://github.com/snapcore/snapd/pull/6293
[07:24] <mup> PR #6293: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
[07:25] <mborzecki> looking
[07:27] <mup> PR snapd#6295 closed: systemd: start snapd.autoimport.service in --no-block mode <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6295>
[07:32] <zyga> mvo: what's the state of the release?
[07:33] <zyga> ah
[07:33] <zyga> the gai_strerror thing
[07:36] <mvo> zyga: working on it
[07:36] <mvo> zyga: some bits have landed, but more bits needed
[07:36] <mborzecki> damn, ls -Zd has different output on centos and fedora
[07:36] <zyga> cannot allocate memory in dnf makecache? https://www.irccloud.com/pastebin/2TrCykuR/
[07:36] <zyga> mborzecki: what's the difference?
[07:37] <mborzecki> zyga: centos drwxr-xr-x. niemeyer google-sudoers unconfined_u:object_r:home_root_t:s0 .
[07:37] <mborzecki> fedora unconfined_u:object_r:user_home_t:s0 .
[07:42] <mvo> sil2100: hey, good morning! one final core18 pr (hopefully the last) https://github.com/snapcore/core18/pull/103
[07:42] <mup> PR core18#103: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>
[07:52] <zyga> mvo: did you see the test failure there?
[07:52] <zyga> is that expected?
[07:55] <mvo> zyga: well, yes, I have not had time to look into it :( but tests are unhappy there
[07:55] <zyga> it doesn't seem related to the nature of the change in the pull request
[07:56] <mvo> zyga: exactly, looks like something innternal
[07:56] <mvo> zyga: so snapcraftctl iirc
=== pstolowski|afk is now known as pstolowski
[08:03] <pstolowski> hey
[08:11] <sil2100> mvo: morning! Looking in a minute
[08:12] <mvo> sil2100: thank you
[08:14] <zyga> hello Pawel
[08:28] <mup> PR snapd#6299 opened: travis: short cicruit failures in static and unit tests suites task <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
[08:28] <mborzecki> zyga: ^^
[08:29] <zyga> looking
[08:29] <pedronis> mvo: morning, sorry I'm a bit late,  what's the status of things?
[08:29] <zyga> thank you!
[08:29] <zyga> mborzecki: yes yes yes :)
[08:29] <pedronis> mvo: I saw some of the PR are landed now
[08:32] <mvo> pedronis: yeah, progress
[08:32] <mvo> pedronis: some things still pending though
[08:35] <mborzecki> heh, the code formatted with new gofmt is incorrectly formatted with the 1.6 one
[08:36] <zyga> mborzecki: yeah
[08:36] <zyga> I opened a PR to highlight that before
[08:36] <zyga> sucks :/
[08:36] <mborzecki> i'm thinking, maybe we could go get gofmt (the tool) with 1.6 instead
[08:37] <pedronis> mvo: are you waiting for me to look at #6243 ?
[08:37] <mup> PR #6243: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>
[08:37] <zyga> mborzecki: hmm?
[08:38] <mborzecki> zyga: go get github.com/golang/go/src/cmd/gofmt, this would pull the latest one
[08:38] <zyga> aha
[08:38] <zyga> I see
[08:38] <zyga> as long as people on older releases are happy to integrate this with their workflow, yeah
[08:38] <mvo> pedronis: its a bit of a target of opportunity - if you think its too much we can just leave it for later
[08:38] <mvo> pedronis: it seemed its now relatively clean and the win is relatively high
[08:38] <pedronis> mvo: my main comment there, thinking a bit further, is that the description is misleading, we do daemon-reload in other places?
[08:39] <pedronis> mvo: if to fix it we really need to serialize daemon-reload then that is not enough, no?
[08:39] <mvo> pedronis: let me see, I think you are right
[08:39] <pedronis> so it would need more work, and doesn't feel a .3 thing
[08:40] <mvo> pedronis: hm, in the overlord we really only do the daemon reload there afaict - but yeah, lets push it out
[08:40] <pedronis> let me double check
[08:40] <pedronis> mvo: we do reloads in wrappers which is used indirectly by overload for example
[08:40] <pedronis> sorry, overlord
[08:41] <mvo> pedronis: aha, its the only explicit place. indeed
[08:41] <pedronis> also interfaces systemd backend does it
[08:42] <pedronis> let me put this chat in the PR
[08:43] <mvo> pedronis: thank you, yeah - we need to investiagte, serializing all daemon reloads would be a bit painful but I'm not into the bug enough to know
[08:44] <pedronis> mvo: done, thanks for marking as blocked, yea, needs more thinking I fear
[08:47] <pedronis> mborzecki: so you were right and it seems on arch we end up with a snapd that uses the cgo resolver,  I thought we had reasons for not wanting cgo at all, do you know if can stop arch using that? not an immediate thing
[08:47] <pedronis> mvo: ^
[08:47] <zyga> cross distribution work is fun
[08:47] <zyga> you get to see *all* the buys
[08:47] <zyga> bugs
[08:50] <pedronis> mvo: so we are left with 6287
[08:51] <mvo> pedronis: there is one more that I'm working on
[08:52] <mvo> pedronis: we have snapd.seeded.service now on core18 at startup. this has a "Requires=snapd.socket" which means that when "snapd.socket" gets stopped (even if its not active) snapd.seeded.service is also stopped
[08:52] <mvo> pedronis: during the seeding the code so far naively restarts things (including snapd.socket) now it needs to be smart and only restart when snapd.socket is actually active
[08:54] <pedronis> mvo: I'm not following
[08:54] <mvo> pedronis: sorry, let me be less terse :)
[08:54] <pedronis> what breaks? :)
[08:54] <mborzecki> pedronis: hm maybe there's a build tag we could use, other than that we can use GODEBUG= switch
[08:55] <sil2100> mvo: approved if anything!
[08:55] <mvo> pedronis: we have the snapd.seeded.service. it has a "Requires=snapd.socket". this means in systemd terms that the when snapd.seeded starts snapd.socket is started by snapd. the converse is also true - systemctl stop snapd.socket will also stop snapd.seeded even if snapd.socket was not active before
[08:56] <mvo> pedronis: what breaks is that during the seeding boot snapd.seeded stops and that will (AIUI) make systemd start units with the after=snapd.seeded ordering
[08:56] <sil2100> mvo: will you guys perform some validation testing on the core18 snap now?
[08:56] <mborzecki> pedronis: hm i think we could also do that in the code, set a preferred resolved on a dialer
[08:56] <mvo> pedronis: but at this point its too early, the seeding is not done yet, we just got our snapd.socket unit and that is started now (via a restart which is the problem)
[08:56] <mvo> sil2100: yeah, once all the pieces are in cachio will run tests
[08:57] <sil2100> (still no merge-powers sadly)
[08:57] <mvo> sil2100: we also get tests from cert (cwayne team)
[08:59] <sil2100> mvo: yeah, I know the automation from certification, but I also saw some tests coming from cachio last time
[09:02] <pedronis> mvo: there is no snapd.socket in core18 itself?
[09:02] <pedronis> we write it from snapd?
[09:02] <zyga> pedronis: correct
[09:03] <mvo> pedronis: correct
[09:04] <pedronis> mvo: so we should know what to do, no? we are just being naive?
[09:04] <pedronis> I'm still missing if there's a deep problem or a shallow one
[09:04] <pedronis> (I suppose that's what systemd does to you)
[09:05] <zyga> pedronis: I think we could look at the way snapd stats up a little so that the relevant code is in our primary repository and so that core18 just consumes that
[09:05] <mvo> pedronis: we are just naive
[09:05] <zyga> pedronis: and to spend some more time on making things more robust and better tested
[09:06] <zyga> pedronis: but in general things feel okay
[09:06] <pedronis> zyga: ?
[09:06] <pedronis> it's already mostly the case
[09:06] <pedronis> there is little code in core18
[09:06] <pedronis> about this
[09:07] <zyga> pedronis: yes but it in core18 repo, it will need to be in core20 repo and in other repos eventually, we could just have core18 and core16 eventually consume a deb that is built out of snapd source package
[09:07] <pedronis> it's mostly the baggage of systemd unit keywords (they often do a bit more or less than one would exactly like)
[09:07] <pedronis> zyga: sounds like a code org issue
[09:07] <pedronis> not a what the code does issue
[09:08] <zyga> yes
[09:08] <zyga> I said we're mostly okay
[09:08] <pedronis> anyway it seems very premature before we got our v0 working
[09:13] <mup> PR snapd#6300 opened: travis: use more recent version of gofmt <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6300>
[09:19] <mup> PR snapd#6298 closed: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>
[09:19] <mup> PR snapd#6301 opened: wrappers: only restart service in core18 when they are active <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6301>
[09:22] <mvo> mborzecki: quick question for you - the systemd mount unit bug - we were wondering if the workaround must serialize all daemon-reloads. or if its enough to ensure that there is only a single mount unit started (and we wait until that start is finished) at the same time. i.e. however many daemon-reloads are ok as long as there is just a single mountunit starting. this question affects the nature of the workaround. if its just a single mountunit at
[09:22] <mvo>  the same time the workaround I pushed is probably sufficient. if we need to serialize all dameon-reload things are more complicated. do you have more insight into this?
[09:22] <mvo> (uh, that was long, sorry!)
[09:24] <mborzecki> mvo: i don't have more insight, i think i'd play it safe and serialize reloads & mounts
[09:24] <mvo> pedronis: fwiw 6301 is up and has the bits I mentioned
[09:24] <mvo> mborzecki: ok, so when we do the mountunit generation / daemon-reload /start nothing no other daemon-reloads?
[09:25] <mvo> mborzecki: that will be interessting code-wise :)
[09:25] <mup> PR snapd#6268 closed: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6268>
[09:25] <mborzecki> mvo: yes, that'd the the super safe variant
[09:25] <mborzecki> mvo: otoh, your pr only serialized the mounts and seemed to work fine
[09:26] <mvo> mborzecki: yeah, this is why I was wondering
[09:26] <mborzecki> mvo: so we could start small, it's unlinkely we'd introduce a regression
[09:26] <mvo> mborzecki: if your script could be extended to springle random daemon-reloads but only a single mount at the same time and it is fine we might get away with the simpler version
[09:27] <mvo> mborzecki: fair point, feel free to report in the bug
[09:27] <mvo> mborzecki: eh, PR
[09:27] <mborzecki> mvo: i'll update the script and let you know
[09:27] <mvo> mborzecki: \o/
[09:27] <pedronis> mvo: so stopping something that is not running does something ?
[09:27] <pedronis> that's probably the bit I don't understand
[09:27] <zyga> pedronis: yes, stops related stuff AFAIK
[09:28] <mvo> pedronis: coreect
[09:33] <pedronis> mvo: I'm working on 6287
[09:33] <pedronis> btw
[09:33] <mvo> pedronis: ta
[09:37] <mup> PR snapd#6300 closed: travis: use more recent version of gofmt <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6300>
[09:46] <mborzecki> mvo: bad news, single mount & many reloads fails the same way
[09:47] <mvo> mborzecki: thanks, there was hope for a moment :)
[09:48] <mvo> mborzecki: its fine, makes things more complicated but at least we know now. thanks for checking
[09:48] <mborzecki> mvo: i've updated the script https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9 in case yout want to double check the code
[09:48] <pedronis> ok, so that PR is indeed not enough
[09:48] <mvo> mborzecki: my brain is too mushy today :)
[09:48] <mvo> pedronis: yeah, slightly sad
[09:49] <mvo> mborzecki: but thanks for adding it, will probably be helpful in the future
[09:51] <zyga> mborzecki: nice work
[09:51] <mborzecki> mvo: fwiw, it's harder to reproduce now
[09:53] <mborzecki> mvo: i think i'd start with a simpler fix
[09:56] <mvo> mborzecki: thanks, yeah, it won't hurt and make things a bit better. we just need to make sure to document that its not the full fix
[09:56] <mborzecki> mhm
[10:02] <pstolowski> pedronis: do you have some time for a HO today?
[10:03] <pedronis> pstolowski: yes
[10:04] <pstolowski> pedronis: standup ho?
[10:05] <pedronis> pstolowski: yea, but I need 5 mins
[10:05] <pstolowski> pedronis: ok
[10:09] <mup> PR snapd#6301 closed: wrappers: only restart service in core18 when they are active <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6301>
[10:11] <mup> PR snapd#6302 opened: wrapprs: address review feedback from #6301 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6302>
[10:12] <mup> PR core18#103 closed: static: add missing systemd symlinks <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/103>
[10:12] <pedronis> pstolowski: now works
[10:13] <pstolowski> ok
[10:30] <pedronis> mvo: I pushed changes/fixes to #6287
[10:30] <mup> PR snapd#6303 opened: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
[10:30] <mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
[10:30] <zyga> pstolowski: trivial PR with some unit tests for internal functions https://github.com/snapcore/snapd/pull/6303/files
[10:30] <mup> PR #6303: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
[10:30] <pedronis> zyga: mborzecki: 6287 needs 2nd reviews btw
[10:31] <pstolowski> zyga: ok
[10:31] <Chipaca> morning peeps, sorry i'm late
[10:31] <pedronis> Chipaca: hello
[10:31] <mborzecki> pedronis: mvo: btw. do we take any steps to use go resolver on ubuntu?
[10:32] <Chipaca> zyga: wrt 6303, what were the l10n issues?
[10:37] <zyga> pedronis: ack
[10:37] <zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1806761
[10:37] <mup> Bug #1806761: Trash output for LANG=ru_RU.UTF-8 (probably all non-ASCII languages) <snapd:In Progress by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1806761>
[10:37] <mvo> mborzecki: iirc we use CGO_ENABLED=0 during the build
[10:38] <zyga> Chipaca: I think someone misunderstood the translator comment
[10:38] <mvo> mborzecki: aha, no, wait - just for selected bits like snap-exec
[10:38] <zyga> and added <foo>s with the s at the end :)
[10:39] <zyga> Chipaca: so my idea is
[10:39] <Chipaca> zyga: brb, need to order a bigger palm on amazon, for the facepalm i need to do
[10:39] <zyga> Chipaca: if the format is "<.*>s", cut the s and not log anything
[10:39] <zyga> Chipaca: right? :D
[10:39] <zyga> Chipaca: and fix the translator suggestions to make sure we say "don't add the frelling s"
[10:42] <mborzecki> mvo: pedronis: looking at net/conf.go, i think go gets confused with 'mymachines' listed as one of the hosts sources on arch
[10:42] <mvo> mborzecki: aha, it inspects nsswitch.conf ?
[10:42] <mborzecki> mvo: yes
[10:42] <mvo> mborzecki: smart!
[10:43] <mborzecki> mvo: it's parsing both nsswitch.cofn and resolv.conf, whenever it finds an option/source that's unknown it'll default to libc resolver first
[10:43]  * mvo nods
[10:44] <Chipaca> zyga: argument %q's %q should begin with < and end with >
[10:44] <Chipaca> zyga: ?
[10:44] <mborzecki> mvo: there's libnss_mymachines.so.2 in my system, owned by libsystemd pacakge
[10:45] <mborzecki> mvo: on a system which uses resolved it'll probably default to libc resolver too
[10:47] <zyga> Chipaca: sounds good
[10:47] <zyga> Chipaca: are you still off today?
[10:48] <Chipaca> no
[10:48] <zyga> mborzecki: yes
[10:48] <zyga> Chipaca: ah, splendid
[10:48] <zyga> Chipaca: shall we land https://github.com/snapcore/snapd/pull/6303?
[10:48] <mup> PR #6303: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
[10:48] <Chipaca> but i didn't need to take the boys to school today so i turned off my 6am alarm … and then it was suddenly 10:15
[10:48] <Chipaca> zyga: not without a second review, I'm still smarting from a few others we slipped in too quickly
[10:51] <zyga> mvo: some comments on https://github.com/snapcore/snapd/pull/6287
[10:51] <mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
[10:55] <mvo> zyga: thanks
[10:58] <mborzecki> Chipaca: maybe something simple to start with https://github.com/snapcore/snapd/pull/6299 ?
[10:58] <mup> PR #6299: travis: short cicruit failures in static and unit tests suites task <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
[11:03] <Chipaca> mborzecki: can I suggest an alternative implementation?
[11:03] <mborzecki> Chipaca: sure, go ahead
[11:03] <Chipaca> mborzecki: start "script" with "set -e" :-)
[11:03] <mborzecki> Chipaca: hm does travis lump all the pieces into one large script?
[11:03] <Chipaca> mborzecki: apparently
[11:06] <mborzecki> Chipaca: When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well, and accumulates the build result. taken from https://docs.travis-ci.com/user/job-lifecycle/#customizing-the-build-phase
[11:06] <Chipaca> mborzecki: https://github.com/travis-ci/travis-ci/issues/1066
[11:07] <Chipaca> mborzecki: if it works, the advantage of having them in separate lines is we get separate timings for them
[11:07] <Chipaca> mborzecki: and I like having those timings
[11:07] <mborzecki> Chipaca: mhm
[11:07] <mborzecki> but damn travis
[11:07] <Chipaca> is this an instance of "old man yells at cloud"?
[11:08] <mborzecki> haha
[11:11] <mborzecki> Chipaca: ok, pushed set -e, we'll se if it fails for real
[11:12] <mup> PR snapd#6304 opened: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6304>
[11:16] <pedronis> mborzecki: mvo: I missed this,  https://github.com/snapcore/snapd/pull/6277/files  it's a bit of odd change for a .x release
[11:16] <mborzecki> Chipaca: seems to work
[11:16] <mup> PR #6277: centos: enable SELinux support on CentOS 7 (2.36) <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6277>
[11:17] <pedronis> mborzecki: why the backport to 2.36 ?
[11:18] <mborzecki> pedronis: it's not really a functional change, neal could have enabled it any time without that PR
[11:18] <pedronis> mborzecki: how is not functional?
[11:19] <pedronis> it might break things, no?
[11:19] <mvo> he would have done it anyway, right? I mean, he would have distro-patched with this, yes? I think that was the rational, it would have been added anyway. but if its a right we can back it out
[11:19] <mborzecki> pedronis: the package that's in epel is already built this way
[11:19] <pedronis> ok
[11:20] <pedronis> sorry for picking on this, but feature changes in late .x releases are a bit wrong
[11:20] <pedronis> to me
[11:20] <mvo> pedronis: its a bit of a rathole - 6304 needs to go in too, systemd.Status() in our code is too picky to be usable at early boot
[11:20] <mvo> pedronis: no worries, your comment is correct
[11:20] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/6305
[11:20] <mup> PR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
[11:20] <mup> PR snapd#6305 opened: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
[11:20] <Chipaca> what's 19.04 called again?
[11:21] <cachio> mvo, hey
[11:21] <cachio> I see a new core18
[11:21] <Chipaca> and why does https://translations.launchpad.net/ubuntu/+source/snapd take you to the cosmic translations? isn't 19.04 open?
[11:21] <pedronis> Chipaca: disco
[11:21] <cachio> is this the final one?
[11:21] <zyga> Chipaca: about translations
[11:21] <zyga> are we importing them?
[11:21]  * pedronis lunch
[11:22] <zyga> are we building them in our packages?
[11:22] <Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1806761/comments/9
[11:22] <zyga> apparently not in opensuse
[11:22] <mup> Bug #1806761: Trash output for LANG=ru_RU.UTF-8 (probably all non-ASCII languages) <snapd:In Progress by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1806761>
[11:22] <zyga> I should fix that
[11:22] <Chipaca> zyga: we sync them manually
[11:22] <Chipaca> mvo: syncing translations is still manual, yes?
[11:22] <zyga> mvo: kind request to sync 2.37 translations
[11:23] <Chipaca> also seriously why aren't disco translations there yet
[11:26] <zyga> Chipaca: nice, thank you for that comment
[11:27] <Chipaca> zyga: i'll push a small change to your pr in a bit
[11:27] <zyga> sure, thanks
[11:29] <mvo> cachio: hey, we have one open pR (6403) and then I think we are (finally!) good
[11:29] <mvo> reviews for 6403 would be great, maybe Chipaca ?
[11:29] <mup> PR snapd#6293 closed: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  🐎> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6293>
[11:30] <mvo> cachio: sorry, it dragged on a bit but things should be under control now once this PR is in
[11:30] <cachio> mvo, nice
[11:30] <cachio> I'll wait for that
[11:31]  * mvo also lunch but will check tg
[11:31] <mvo> cachio: yes, no point in testing before this is in
[11:31] <zyga> yeah, lunch sounds good
[11:34] <Chipaca> zyga: pushed; wdyt
[11:34] <Chipaca> mvo: 6403?
[11:35] <Chipaca> mvo: going to assume you meant 6304
[11:44] <mvo> *cough* yes
[11:44] <mvo> ta
[11:46] <zyga> Chipaca: I’ll check soon
[11:48] <mup> PR snapcraft#2426 closed: tests: use fixed version for idna in plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2426>
[11:53] <pstolowski> pedronis: ok, i think what's wrong with the taskrunner
[11:53] <pstolowski> *i think i know
[11:53] <zyga> pstolowski: anything for 2.36?
[11:53] <pstolowski> zyga: no
[12:05] <zyga> Chipaca: looking now
[12:06] <zyga> Chipaca: in https://github.com/snapcore/snapd/pull/6305/commits/195523c129c7ede53f3969da2e9913bfa18c3159
[12:06] <mup> PR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
[12:06] <mborzecki> zyga: quick question about release/apparmor.go, shouldn't the code in assessAppArmor or the public functions be wrapped with a mutex?
[12:06] <zyga> did you mean to use has suffix or has prefix?
[12:06] <zyga> mborzecki: mmm, perhaps
[12:06] <Chipaca> zyga: a clear case of id10t
[12:07] <zyga> mborzecki: +1 :)
[12:07] <Chipaca> zyga: if only we had tets!
[12:07] <Chipaca> zyga: or tests!
[12:07] <pstolowski> pedronis: i think i see a problem around scheduling of next ensure; after Retry we do EnsureBefore(0), yes; but after ConsiderTask loop we also call EnsureBefore with nextTaskTime (if non-zero - it happens to be taken from the auto-disconnect task; it's the only task with non-zero AtTime()); so the call to EnsureBefore after the big loop resets EnsureTime to +5s from now. The ensureBefore() code in overlord has a condition
[12:07] <pstolowski> to prevent this I think, but it looks suspicious, I think it's incorrect
[12:07] <zyga> Chipaca: yes, tests are coming in via another PR
[12:07] <Chipaca> zyga: IKR
[12:07] <zyga> hehe
[12:07] <Chipaca> zyga: we could stack this one on that one
[12:07] <zyga> nah
[12:07] <zyga> nobody reviews things that are long
[12:07] <Chipaca> zyga: i mean, we need a test for the >s pruning
[12:07] <zyga> and it requires writing another message
[12:08] <mborzecki> zyga: seccomp piece too
[12:08] <zyga> Chipaca: one more on top :)
[12:08] <zyga> or land the 1st and then let's rebase
[12:08] <Chipaca> zyga: I mean, land the tests one, andd let's rebase
[12:08] <Chipaca> zyga: ding ding ding
[12:08] <zyga> ++
[12:08] <Chipaca> zyga: maybe we can convince mborzecki to do a review of the tests one
[12:08] <Chipaca> zyga: I hear he's into that
[12:08] <mborzecki> Chipaca: which pr is that?
[12:08] <zyga> mborzecki: you're into https://github.com/snapcore/snapd/pull/6303
[12:09] <zyga> oh
[12:09] <zyga> it has +2
[12:09] <mup> PR #6303: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>
[12:09] <Chipaca> mborzecki: 0118 999 881 999 119 725 3
[12:09] <mborzecki> Chipaca: your IBAN? :)
[12:09] <Chipaca> duude
[12:10] <zyga> whaaaat :)
[12:10] <Chipaca> mborzecki: https://www.youtube.com/watch?v=ab8GtuPdrUQ
[12:10] <mborzecki> aaa hahah
[12:10] <pedronis> pstolowski: ah, so it's some kind of EnsureBefore bug?
[12:10] <pstolowski> pedronis: i think so
[12:10] <pstolowski> pedronis: 	if next.Before(o.ensureNext) || o.ensureNext.Before(now) {
[12:10] <pstolowski> 		o.ensureTimer.Reset(d)
[12:10] <pstolowski> 		o.ensureNext = next
[12:10] <zyga> Chipaca: loool
[12:11] <pstolowski> pedronis: the 2nd part of conditional looks wrong to me
[12:11] <pedronis> pstolowski: there is something there related to coming back from sleep
[12:11] <zyga> I read that as EnsureBug bug
[12:11] <pedronis> we'll need to remember/dig
[12:12] <pstolowski> pedronis: maybe, but we check existing ensureNext against now(), and then reset to a future next, which I think is the problem in this case
[12:13] <pedronis> mvo: zyga: I'm going to merge #6287
[12:13] <mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
[12:13] <pstolowski> pedronis: i suppose after sleep we have ensureNext in the past, so we should just make sure to simply ensure *now* ?
[12:13] <zyga> +1
[12:13] <pedronis> pstolowski: yea, something like that, we'll need to consider various cases
[12:14] <pedronis> pstolowski: probably needs a bit more attention that I have right now
[12:14] <pedronis> but good we are getting closer
[12:14] <mvo> pedronis: ta, please squash and I will cherry pick
[12:14] <pstolowski> pedronis: ack
[12:17] <mup> PR snapd#6287 closed: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6287>
[12:17] <pedronis> mvo: done
[12:18] <zyga> mvo: in https://github.com/snapcore/snapd/pull/6304/files is the root directory significant or just carried over from other systemd methods?
[12:18] <mup> PR #6304: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6304>
[12:19] <pedronis> pstolowski: you should go back to Hotplug and we look at this again when I can look at the picture a bit more, thank you for the digging
[12:19] <pstolowski> pedronis: k, thanks
[12:20] <zyga> pstolowski: just write down anything you know somewhere :)
[12:20] <pstolowski> zyga: good idea. i'm sure after christmas break i won't remember a thing of that ;)
[12:21] <zyga> pstolowski: perhaps a bug report on snapd
[12:21] <pstolowski> (unless we manage to discuss and tackle it before xmas)
[12:21] <pstolowski> zyga: yeah, already reported, just need to write down the details
[12:21] <zyga> sounds good
[12:22] <mvo> zyga: just carried over, makes testing easier
[12:22] <zyga> mvo: https://github.com/snapcore/snapd/pull/6302#pullrequestreview-184634621
[12:22] <mup> PR #6302: wrappers: address review feedback from #6301 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6302>
[12:23] <zyga> mvo: +1
[12:23] <pedronis> pstolowski: thx
[12:23] <mvo> zyga: ta, no travis tests right now all busy, I get lunch and check back after that
[12:25] <zyga> mborzecki: we should ship translations in snapd packages
[12:25] <zyga> mborzecki: I'll look at doing that in 2.36.3
[12:26] <pedronis> zyga: that sounds something for 2.37
[12:26] <pedronis> no .3
[12:26] <pedronis> not .3
[12:26] <zyga> why so? we ship that on ubuntu
[12:27] <pedronis> which snapd packages?
[12:27] <mborzecki> zyga: are you saying other distrons don't ship the translations?
[12:27] <mborzecki> (arch doesn't)
[12:27] <pedronis> as formulated it sounded like all packages
[12:27] <zyga> mborzecki: suse doesn't
[12:27] <zyga> pedronis: we only ship for sure on ubuntu
[12:27] <zyga> because the translations are going in via a different mechanism
[12:27] <mborzecki> ah, so something for me to fix on arch
[12:28] <mup> PR snapd#6306 opened: release: use locking around lazy intialized state <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
[12:30] <zyga> mborzecki: reviewed
[12:31] <mborzecki> zyga: assessAppArmor calls the AppArmor*Features() functions, that's why a separate mutex
[12:32] <zyga> Ah, I see
[12:32] <mborzecki> zyga: blindly used just one in the beginnig and go test got stuck :P
[12:32] <zyga> can you add a quick one line comment to document that
[12:32] <zyga> it's correct but non obvious :)
[12:32] <zyga> (at least to me :)
[12:33] <pedronis> mborzecki: made a comment
[12:33] <mborzecki> pedronis: thanks, good point!
[12:33] <zyga> I think it will mess up tests
[12:33] <zyga> but do try
[12:34] <pedronis> we can mock/replace them as anything else
[12:35] <pedronis> anyway we have higher level mocking
[12:35] <pedronis> already
[12:38] <pstolowski> pedronis: updated https://bugs.launchpad.net/snapd/+bug/1806447
[12:38] <mup> Bug #1806447: Sophisticated snap remove retries a lot and becomes very slow <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1806447>
[12:39] <pedronis> pstolowski: thx
[12:42] <pstolowski> pedronis: i'm moving the "investigate.." card to done and will create a new one when we agree on a fix (if it's not trivial and needs a card)
[12:42] <pedronis> thx
[13:08] <mborzecki> off to pick up the kids
[13:14] <mup> PR snapd#6303 closed: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6303>
[13:14] <pedronis> mvo: last bit we are waiting on is 6304 ?
=== ricab is now known as ricab|lunch
[13:19] <zyga> Chipaca: hmm
[13:19] <zyga> Chipaca: the extra noticef is not desired
[13:19] <zyga> it will mean people still get spammed
[13:20] <zyga> ah, wait
[13:20] <zyga> what am I saying
[13:20] <zyga> I mean the order of fixup and lint
[13:20] <Chipaca> zyga: after mixing up suffix and prefix, i can't deride you for this
[13:21] <zyga> Chipaca: I don't think we should be teaching users about the translator's mistake
[13:21] <Chipaca> zyga: can you explain?
[13:21] <zyga> Chipaca: do I read your patch right that we lint, then fixup
[13:21] <Chipaca> zyga: correct
[13:21] <zyga> so you will see a bunch of noticef
[13:21] <zyga> (that mean nothing to the end users)
[13:21] <Chipaca> zyga: no
[13:22] <Chipaca> zyga: because i taught the lint about >s also
[13:22] <zyga> ah
[13:22] <zyga> that's ... confusing then
[13:22] <zyga> ok
[13:22] <zyga> +1
[13:22] <zyga> should we always lint, then fixup
[13:22] <zyga> in both cases?
[13:24] <Chipaca> zyga: which is the other case?
[13:24] <zyga> look for calls to lintArg
[13:24] <zyga> we do it in two places
[13:25] <zyga> I swapped both in my local tree now
[13:25] <Chipaca> ah, right
[13:25] <zyga> I think it's good
[13:25] <zyga> shall I push?
[13:25] <Chipaca> zyga: yes
[13:25] <Chipaca> zyga: have you added tests? :-)
[13:25] <zyga> Chipaca: tests for the whole init sequence?
[13:25] <zyga> no
[13:25] <zyga> I've rebased on the tests PR
[13:25] <Chipaca> zyga: the order means if arg is "foo>s" the user will see the notice with "foo>s" and not "foo>" (which would be extra confusing)
[13:28] <Chipaca> zyga: at the same time i wonder if it shouldn't do something like print the first one and " (and NN more similar warnings)"?
[13:28] <zyga> Chipaca: YAGNI :)
[13:28] <zyga> Chipaca: I think the has suffix is still wrong
[13:28] <zyga> I'll fix it (after adding a test)
[13:29] <Chipaca> zyga: wrt YAGNI, this comes up again and again, I'm half tempted to abandon the whole notion
[13:29] <Chipaca> the bad thing is there's nothing the user can do, and translators don't get to see the errors because of how removed translations are from the code
[13:30] <Chipaca> moving this whole thing into a test would accomplish the same as the current panic code
[13:31] <zyga> Chipaca: interesting
[13:31] <zyga> Chipaca: but tests don't run with l10n
[13:31] <zyga> and then we cannot fix it
[13:31] <zyga> I strongly doubt translators know how to build and run tests
[13:32] <zyga> especially since our tree has zero code for building localization
[13:32] <zyga> Chipaca: I pushed
[13:32] <Chipaca> zyga: tests/main/i18n/
[13:32] <zyga> Chipaca: and when it fails?
[13:32] <zyga> what next?
[13:33] <zyga> fix all i18n?
[13:33] <zyga> and wait until next import breaks them
[13:33] <zyga> in some way I agree
[13:33] <zyga> but I'd separate this
[13:33] <zyga> the patch now could go into stable
[13:33] <zyga> to unannoy users
[13:35] <Chipaca> zyga: your change makes "foo>s" pass lint
[13:35] <zyga> yes
[13:35] <zyga> because we cannot do anything about it, that's the point :)
[13:36] <Chipaca> no
[13:36] <Chipaca> zyga: "<foo>s" should pass lint
[13:36] <Chipaca> zyga: "foo>s" should not
[13:36] <zyga> ah
[13:36] <zyga> I see your point now
[13:36] <zyga> sorry, I will correct that
[13:37] <Chipaca> and, arg is known to be non-"", fwiw
[13:37] <Chipaca> but that doesn't hurt
[13:37] <zyga> tests really help :)
[13:37] <pedronis> zyga: last travis tests on #6190 failed but apparently github didn't notice
[13:37] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[13:38] <cachio> mvo, do you have models for core18?
[13:38] <cachio> I am getting errors to build images for rpi and dragonboard using ubuntuimage
[13:38] <zyga> thanks, I'll check
[13:38] <zyga> Chipaca: done
[13:40] <Chipaca> hmmm
[13:49] <zyga> https://travis-ci.org/snapcore/snapd/jobs/466961767 <- does this make any sense?
[13:49] <zyga> what failed?
[13:50] <Chipaca> zyga:  github.com/snapcore/snapd/overlord/configstate
[13:50] <Chipaca> overlord/configstate/configmgr.go:31: undefined: configcore.Conf
[13:51] <zyga> ah, thank you!
[13:51] <zyga> that output is terrible
[13:51] <zyga> but one thing at a time
[13:51] <mvo> cachio: what kind of error do you get?
[13:52] <cachio> mvo, https://paste.ubuntu.com/p/Z62mXTs6bH/
[13:53] <zyga> random unit test failure https://www.irccloud.com/pastebin/JLOllQuX/
[13:54] <zyga> chipaca: that's a small one for you :) https://www.irccloud.com/pastebin/DONZWn2s/
[13:54] <cachio> pedronis, mvo I need to take my daughter to the doctor
[13:54] <cachio> I'll try to be back asap
[13:55] <pedronis> cachio: ok
[13:55] <pedronis> hope nothing too serious
[13:57] <cachio> pedronis, a strong pain in the ear
[13:57]  * cachio afk
[13:59] <zyga> brb, start the standup without me
[13:59] <zyga> I'll join in 5 minutes
[14:02] <sdeziel> hello, looks like my snap setup is somehow busted
[14:02] <sdeziel> $ sudo snap stop lxd.daemon
[14:02] <sdeziel> error: snap "lxd" has "seed" change in progress
[14:03] <sdeziel> the seeding in question never seem to finish
[14:07] <sdeziel> I'd been a while that my system has issues related to snapd seeding (whatever that is)
[14:07] <sdeziel> my boot never completes as systemd keeps saying that snapd.seeded.service is still running
[14:08] <zyga> sdeziel: hey
[14:08] <zyga> sdeziel: I think we are onto this bug
[14:08] <zyga> sdeziel: mvo can work with you if you stick around for a moment, we're in a meeting now
[14:08] <sdeziel> zyga: great! I'll stick around
[14:09] <sdeziel> I already reported this seed bug in LP: #1806070
[14:09] <mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
[14:10] <mup> PR snapd#6304 closed: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6304>
[14:17] <sergiusens> mvo: hey, you never got back to me on https://bugs.launchpad.net/snapcraft/+bug/1805219
[14:17] <mup> Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged> <https://launchpad.net/bugs/1805219>
[14:20] <mvo> sergiusens: ineed, sorry for this, I try to reply today but need to ru nnow
[14:22] <zyga> Chipaca: can you please review https://github.com/snapcore/snapd/pull/6190
[14:22] <zyga> I know it's long
[14:22] <zyga> but I badly need a 2nd review
[14:22] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[14:28] <zyga> Chipaca: once landed it will unlock things I need to work on
[14:33] <pedronis> mborzecki: I requested reviews from you for a couple of pstolowski PRs needing 2nd reviews
[14:33] <mborzecki> pstolowski: sure
[14:33] <pedronis> thx
[14:34] <mup> PR snapcraft#2427 opened: lifecycle: query for multipass install on darwin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2427>
[14:37] <mup> PR snapd#6285 closed: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
=== ricab|lunch is now known as ricab
[14:41] <Chipaca> zyga: on it
[14:41] <zyga> thank you!
[14:46] <mup> PR snapcraft#2421 closed: tests: remove obsolete snap and external tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2421>
[14:46] <mup> PR snapcraft#2425 closed: snap: re-add pyc files for snapcraft <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>
[14:49] <mup> PR snapcraft#2428 opened: tests: increase test timeout for plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2428>
[14:50] <mborzecki> using sync.Once in release is tricky
[14:56] <Chipaca> zyga: +1
[14:56] <zyga> thank you!
[14:56] <zyga> woooot
[14:57] <noise][> ohsaycanyousay
[14:57] <noise][> wow
[14:57] <noise][> burned that hacky pass
[14:57] <sergiusens> to ALL your accounts?
[14:57] <noise][> heh
[14:58] <noise][> just all my banks :)
[14:58] <zyga> sdeziel: mvo is not around anymore, perhaps you want to open a bug report to make sure this is not lost
[14:58] <sergiusens> those are impossible to log in to at times, so no worries
[14:58] <zyga> with the features PR we can finally evolve anything we want
[14:58] <zyga> with a feature flag controlling it
[14:59] <zyga> this is a major milestone :)
[14:59]  * noise][ needs a new throwaway pass for sites that don't matter
[15:00] <sdeziel> zyga: I've already open LP: #1806070, if another is needed please tell me where
[15:00] <mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
[15:00] <zyga> thank you, that will be sufficient
[15:01] <sdeziel> zyga: OK, thanks. I'll stick around today and tomorrow as this issue is important for me as it prevents all my snaps from updating/refreshing :(
[15:02] <zyga> pedronis: ^
[15:02] <sdeziel> I'm stuck with lxd 3.2 while the stable version is 3.7
[15:08] <zyga> sdeziel: can you please save your state file /var/lib/snapd/state.json
[15:08] <zyga> sdeziel: if you had authenticated please don't send it to the bug report (snap login)
[15:08] <zyga> sdeziel: but if you did not it might help us debug
[15:09] <sdeziel> zyga: could you refresh my memory to check if I had logged in?
[15:09] <sdeziel> I vaguely remember something like that for the livepatch snap but not sure
[15:09] <zyga> sdeziel: snap whoami
[15:09] <sdeziel> email: -
[15:10] <zyga> I think you should be good
[15:10] <sdeziel> great, I'll attach this to the LP bug
[15:11] <zyga> sdeziel: you have some questions on the bug report as well
[15:11] <sdeziel> zyga: thanks, I hadn't receive the notifications emails
[15:12] <zyga> you can just refresh the bug report page
[15:13] <sdeziel> yeah, I know but that was my explanation for the delay in response ;)
[15:14] <zyga> ah, sure :)
[15:42] <sdeziel> pedronis: for faster turn around on bug 1806070, don't hesitate to ping me in here
[15:42] <mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
[15:45] <pedronis> zyga: that machine is really in curious state core requested a snapd restar but it never happened afaict
[15:58] <sil2100> Oh, no mvo?
[16:12] <pstolowski> sil2100: he had an errand to run; he might show up later but not sure. if not, then he started his holidays...
[16:13] <zyga> back from freezing outdoors
[16:13] <zyga> pedronis: didn't the reporter said that the machine rebooted
[16:13] <zyga> sil2100: no, what's up?
[16:14] <pedronis> zyga: it's in a very odd state overall
[16:14] <zyga> pedronis: no disagreement
[16:14] <zyga> pedronis: shall we aks the reporter to restart snapd?
[16:14] <pedronis> also one snap is broken
[16:14] <zyga> pedronis: it might be useful to also ask for uptime
[16:15] <pedronis> and the dates are strange
[16:15] <zyga> pedronis: remember when I reported a bug when snapd starts _before_ any snaps were mounted
[16:15] <zyga> pedronis: I think that's still the case
=== hggdh_ is now known as hggdh
[16:15] <pedronis> zyga: reported in which sense? is the a LP bug?
[16:15] <zyga> yes
[16:15] <zyga> one sec
[16:15] <pedronis> there
[16:17] <zyga> https://bugs.launchpad.net/snapd/+bug/1805866
[16:17] <mup> Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>
[16:19] <zyga> Chipaca: what's your stance on https://github.com/snapcore/snapd/pull/6305
[16:19] <mup> PR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>
[16:23] <mup> PR snapd#6190 closed: overlord/configstate,features: expose features to snapd tools <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6190>
[16:25] <sdeziel> pedronis: the gnome calc snap doesn't work so I tried to remove it a while ago without success. I've rebooted many time and the snapd.seeded service never finishes
[16:25] <zyga> sdeziel: interesting
[16:25] <zyga> sdeziel: hold on please, let me check something
[16:26] <zyga> sdeziel: what was your "snap version" again?
[16:26] <zyga> I'm sorry if you said that before
[16:26] <pedronis> 2.34.2
[16:26] <sdeziel> zyga: https://paste.ubuntu.com/p/q9qbc7HyT9/
[16:27] <zyga> ok, classic
[16:27] <pedronis> it never fully initialized
[16:27] <pedronis> so also never refreshed
[16:27] <pedronis> afaict
[16:29] <zyga> sdeziel: can you run journalctl -u snapd
[16:29] <zyga> and paste that?
[16:30] <sdeziel> zyga: http://paste.ubuntu.com/p/zmTKzSXjtD/
[16:30] <zyga> hmmm
[16:31] <sdeziel> not sure if that's related but I noticed many apparmor denials related to the livepatch snap
[16:31] <zyga> probably a consequence
[16:32] <zyga> Dec 07 08:56:49 simon-lemur snapd[1823]: 2018/12/07 08:56:49.470388 stateengine.go:101: state ensure error: Get https://api.snapcraft.io/api/v1/snaps/sections: dial tcp: lookup api.snapcraft.io on 127.0.0.1:53: read udp 127.0.0.1:53515->127.0.0.1:53: read: connection refused
[16:32] <zyga> this is curious
[16:32] <zyga> how is your system networking configured?
[16:33] <sdeziel> Network Manager drives it and the resolver is a local unbound listening on that socket
[16:34] <sdeziel> it is possible that unbound get started after snapd
[16:34] <zyga> mhm
[16:34] <zyga> can you "systemctl restart snapd.service"
[16:34] <zyga> let's see what happens then
[16:35] <sil2100> zyga, cachio: so I wanted to touch base on how the current edge/beta core18 snap tests are going
[16:36] <zyga> sil2100: I don't know
[16:36] <cachio> sil2100, hey
[16:36] <sil2100> cachio: o/
[16:36] <cachio> Just startin a new test cycle
[16:36] <sil2100> cachio: thanks ;)
[16:37] <cachio> I hope today beta validation can be finished
[16:37] <zyga> sdeziel: once it is restarted please paste "snap changes"
[16:37] <sdeziel> zyga: restart worked https://paste.ubuntu.com/p/vkvhdJhk8X/
[16:37] <sdeziel> zyga: snap changes: https://paste.ubuntu.com/p/x5YW9DC9HQ/
[16:38] <sil2100> cachio: since I see that the cert team automated tests are already running for core18 but I'd like to know if we're good to promote it to stable tomorrow and spin new core18 images
[16:38] <cachio> sil2100, once snapd and core18 snaps are validated, I'll ping you
[16:38] <sil2100> cachio: thank you!
[16:38] <zyga> sdeziel: nice, how about "snap tasks 31"
[16:38] <cachio> well, first if everything goes well we can go to candidate today
[16:39] <cachio> and then see when is more convenient to go to stable
[16:39] <cachio> perhaps on monday
[16:39] <sdeziel> zyga: snap tasks 31: https://paste.ubuntu.com/p/hRyDBKFYj8/
[16:39] <zyga> Doing   2 days ago, at 09:31 EST  -                         Automatically connect eligible plugs and slots of snap "gnome-calculator"
[16:39] <zyga> pstolowski: does 2.34.2 have the autoconnect deadlock bug?
[16:40] <zyga> sdeziel: can you snap abort 31
[16:40] <sdeziel> done
[16:40] <pstolowski> zyga: that's possible, i'd need to diff to know for sure
[16:40] <zyga> pstolowski: can you try to find the fix for that
[16:40] <zyga> at least we would know where we are
[16:40] <sdeziel> snap changes: 31   Undoing  2 days ago, at 09:31 EST  -      Initialize system state
[16:41] <pstolowski> zyga: you mean find the PR?
[16:41] <zyga> pstolowski: or the patch
[16:41] <pstolowski> zyga: sure, digging
[16:41] <sdeziel> some progress, snap changes: https://paste.ubuntu.com/p/k94DMXKBSY/
[16:42] <zyga> look at tasks inside please
[16:42] <zyga> sdeziel: one thing you might do is update snapd the package on your system
[16:42] <zyga> did you install system updates?
[16:43] <sdeziel> zyga: I pull everything that apt-get feeds me ;)
[16:43] <zyga> apt-cache policy snapd
[16:43] <sdeziel> https://paste.ubuntu.com/p/pRQMYdkSBP/
[16:43] <pedronis> zyga: we haven't SRU snapd in a while
[16:43] <pedronis> it seems
[16:43] <zyga> ahhh
[16:43] <zyga> mmm
[16:43] <zyga> sdeziel: thank you
[16:43] <pedronis> not sure what happened there
[16:44] <sdeziel> snap tasks 32: https://paste.ubuntu.com/p/pM2bBdqH5w/
[16:44] <pstolowski> zyga:  https://github.com/snapcore/snapd/pull/5827 or https://github.com/snapcore/snapd/pull/6027
[16:44] <mup> PR #5827: ifacestate/autoconnect: do not self-conflict on setup-profiles if core-phase-2 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5827>
[16:44] <mup> PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
[16:44] <zyga> yep
[16:44] <zyga> same thing
[16:44] <pedronis> or we have I think but is not quite through
[16:45] <zyga> pstolowski: based on the output in the last pastebin, do you think this is the same issue?
[16:45] <sdeziel> 2.35.5+18.04 is in -proposed, I could give it a try
[16:46] <zyga> pedronis: I have a feeling snapd seeding should become: install core/snapd (restart); refresh core/snapd; install everything else
[16:46] <zyga> pedronis: or we'll be in a world of hurt
[16:46] <sdeziel> zyga: I have to run for now but will be back in ~2h. Thanks for everything to all of you
[16:46] <zyga> sdeziel: thank you
[16:47] <pedronis> zyga: unlikely we can do that
[16:47] <pedronis> also why?
[16:47] <sdeziel> zyga: I'll hold off on the upgrade to the -proposed version just in case some more investigation is required
[16:47] <zyga> thank you
[16:48] <zyga> pedronis: why unlikely?
[16:48] <zyga> pedronis: priorty: ensure snapd can install its own updates
[16:48] <zyga> pedronis: right now we are observing a situation where it cannot
[16:48] <pedronis> we might not have network
[16:48] <zyga> sure
[16:48] <pedronis> we need a gadget to do many things
[16:48] <pedronis> the design is that the image should know is good to go
[16:48] <pedronis> and then we can refresh it
[16:49] <zyga> that doesn't fit classic world at all
[16:49] <pedronis> seeding was not designed for classic
[16:49] <zyga> unless we assume classic always refreshes snapd via classic packages in case of disaster
[16:49] <zyga> pedronis: in that case we should rethink seeding on classic
[16:49] <zyga> it's clearly not working as designed now
[16:49] <pedronis> ?
[16:49] <zyga> (and if we say that classic may need to update via classic package we need to SRU each release)
[16:50] <zyga> pedronis: none of the mechanisms we have implemented solve the problem of the reporter
[16:50] <zyga> pedronis: my suggestion was to rethink that to allow snapd to at least be able to refresh itself on classic
[16:50] <pedronis> zyga: it might help or bring other bugs
[16:51] <zyga> pedronis: it may bring other bugs but currently lack of something like that keeps old bugs (fixed bugs) around
[16:51] <pedronis> either way I'm still not sure
[16:51] <pedronis> what is the reporter issue
[16:51] <pedronis> is not like all bionic images didn't seed
[16:51] <zyga> I'll try bionic
[16:53] <pstolowski> zyga: it's very likely it's that bug. 2.34.2 is from July, bug was fixed in September.
[16:54] <zyga> thank you for checking Pawel
[16:54] <pedronis> zyga: we need a solid seeding process for core, if it's solid should also work for classic
[16:54] <pstolowski> zyga: can i help somehow?
[16:55] <zyga> I agree 100%
[16:55] <zyga> pstolowski: not that I think so, I think we need to see what happens with a proposed package after the reporter is back
[16:55] <pstolowski> ok
[16:55] <pstolowski> zyga: is 2.35.4 confirmed to have the fix?
[16:56] <pstolowski> zyga: sorry, 2.35.5
[16:56] <zyga> I don't know, we don't tag bugs or fixes and milestones together
[16:57] <pstolowski> zyga: ok, if date is any indication, then 2.35.5 in xenial is from 15 Oct (the fix was in master on 13 Sep)
[16:57] <zyga> the reporter is on bionic and has 2.34.x
[16:58] <zyga> latest is 2.34.2
[16:58] <pstolowski> yes, that version definately has the bug, just trying to estimate if the fix made it into 2.35.5 from proposed
[16:59] <pstolowski> unfortunately #6027 is not fixed in 2.35.5 afaict
[16:59] <mup> PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
[17:00] <zyga> I did a fresh install of 18.04.1 with the same version of snapd
[17:00] <zyga> it was not affected
[17:00] <zyga> perhaps just lucky
[17:03] <pstolowski> zyga: there were specific conditions to be met to hit this (i described them in the PR)
=== pstolowski is now known as pstolowski|afk
[17:07] <zyga> mount issue when refreshing core https://www.irccloud.com/pastebin/OYlOfBlU/
[17:07] <zyga> funny
[17:14] <kyrofa> Ooo, a pretty snapd panic: https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/3
[17:15] <zyga> hmm, too bad we don't log the error with state checkpoint
[17:18] <pedronis> zyga: yes, that bug pawel mentioned is fairly complicated
[17:18] <pedronis> you basically need to install with --dangerous as first thing on a new system
[17:18] <kyrofa> zyga, regarding your comment there, isn't that exactly what he just posted?
[17:18] <pedronis> or possibly do the same while seeding is still going on
[17:18] <pedronis> maybe
[17:18] <zyga> oh, I thought there would be more :/
[17:18] <kyrofa> zyga, you can try -n 100 :P
[17:36] <pedronis> zyga: we do log the error
[17:36] <pedronis> those logs are cut
[17:36] <pedronis> logger.Panicf("cannot checkpoint even after %v of retries every %v: %v", unlockCheckpointRetryMaxTime, unlockCheckpointRetryInterval, err)
[17:36] <zyga> I mean when we say "panic" we could recall the error then
[17:37] <pedronis> ?
[17:37] <zyga> Dec 12 03:12:36 localhost.localdomain snapd[992]: panic: cannot checkpoint even after 5m0s of retries every 3s: write
[17:37] <zyga> "write" is the error?
[17:38] <zyga> or was it just cut in the terminal output?
[17:38] <pedronis> as I said those logs look cut to me
[17:38] <pedronis> so hard to tell
[17:38] <pedronis> but the Panicf should include the error
[17:38] <pedronis> anyway at the end of the day
[17:38] <pedronis> checkpoint is just
[17:38] <pedronis> osutil.AtomicWriteFile(osb.path, data, 0600, 0)
[17:38] <zyga> right
[17:38] <pedronis> so yes, I would expect some kind of i/o error
[17:38] <zyga> I wonder if it is ENOSPC
[17:38] <zyga> or something else
[17:41]  * pedronis mostly calls it a day
[17:41] <pedronis> ttfn!
[17:41] <zyga> ttyl!
[17:41] <zyga> have a good evening :)
[17:49] <ovrh> Hello! I've been sent here from #ubuntu with my question, which I'm copy-pasting next: I have some weird stuff I'd like to show you guys. https://i.imgur.com/SHwXcsR.png This is the System Monitor on my laptop... what's going on? I'm assuming that can't be right, on my previous installation I had just the partitions that actually existed (swap, /home, /, and the windows partition of the dual boot), but this is... a first for me o.o
[17:50] <zyga> hey
[17:50] <ovrh> Also, here's the output from `mount`: https://paste.ubuntu.com/p/T4ZKz99CdK/
[17:50] <zyga> can you please provide "snap version"
[17:50] <zyga> I know what this is but it should not have happened, normally those mounts only exist in a separate mount namespace
[17:50] <zyga> not in your main mount namespace
[17:51] <zyga> if you open a new terminal
[17:51] <zyga> and type "cat /proc/self/mountinfo"
[17:51] <zyga> what do you get?
[17:52] <ovrh> zyga, Here's snap --version and the other command's output: https://paste.ubuntu.com/p/3wvsFmnygw/
[17:53] <zyga> ha
[17:53] <zyga> I understand now
[17:53] <zyga> so
[17:53] <zyga> everything is all right
[17:53] <zyga> when you run gnome-system-monitor as a snap it doesn't execute in the same mount namespace as your other applications
[17:53] <zyga> instead it executes in a special mount namespace that is crafted and only visible for that specific snap application
[17:54] <ovrh> So my gnome-system-monitor comes from snap? o.o I would have bet I installed it through aptitude
[17:54] <zyga> the "file systems" tab shows that gnome-system-monitor is unable to understand what is going on so it displays every mount point as a separate thing
[17:54] <zyga> it appears so
[17:54] <zyga> which gnome-system-monitor
[17:54] <zyga> anyway, mystery solved :)
[17:55] <ovrh> Dammit, I would have totally lost my bet
[17:55] <ovrh>  /snap/bin/gnome-system-monitor
[17:55] <zyga> ovrh: please report a bug with the help of people in #ubuntu-desktop
[17:55] <zyga> the application should be smarter
[17:56] <ovrh> So.. the solution is `snap remove gnome-system-monitor && sudo apt install gnome-system-monitor`?
[17:56] <zyga> ovrh: well, for a quick solution yes. but please do report this bug
[17:56] <zyga> it should be fixed to operate properly
[17:56] <ovrh> zyga, Agree about that. I'll prepare the bug report
[17:56] <zyga> thank you!
[17:57] <ovrh> No, thank you for your help :)
[17:58] <Chipaca> ovrh: zyga: the non-snapped system monitor will still show all the squashfs mounts though
[17:59] <Chipaca> it's unclear to me if ovrh objects to the half-screen of /dev/loop3 bind mounts, or the screen-and-a-half of /dev/loopX squashfs'es
[18:00] <ovrh> Chipaca, Just removed the snap and reinstalled it from aptitude, I only have 3 entries in the GUI tool now
[18:00] <zyga> I would argue that it should show neither :)
[18:00] <zyga> ovrh: no squashfses?
[18:00] <ovrh>  /, /boot/efi, /home, nothing else
[18:00] <zyga> Chipaca: I suspect it filters out things based on /run/mtab
[18:01] <zyga> ovrh: what is in your /run/mtab?
[18:01] <ovrh> zyga, Not sure what you mean
[18:01] <zyga> ovrh: can you look at the file /run/mount/utab
[18:01] <zyga> (sorry, I got the path wrong)
[18:01] <zyga> can tell us what is inside please
[18:02] <Chipaca> zyga: or maybe x-gdu.hide
[18:02] <zyga> yeah
[18:02] <zyga> I bet it is that
[18:02] <Chipaca> that's what we started adding it for at least :-)
[18:02] <Chipaca> strange that the snapped one doesn't pick up on it though
[18:02] <zyga> Chipaca: yeah
[18:02] <zyga> inside a snap you probably don't see that
[18:02] <Chipaca> I blame …
[18:02] <zyga> apparmor
[18:02] <Chipaca> The salesman drove over the CPU board.
[18:03] <ovrh> https://paste.ubuntu.com/p/tJwqjDW6T6/
[18:03] <Chipaca> hm, not a good match, let's try again
[18:03] <Chipaca> _Rosin_ core solder? But...
[18:03] <zyga> ovrh: thank you
[18:03] <zyga> please include this in your bug report
[18:03] <zyga> I'm sure it will help
[18:04] <Chipaca> zyga: out of curiosity i looked at /run/mount/utab here, and it's empty?
[18:04] <ovrh> Where's the x-gdu.hide file? Should I still look there?
[18:04] <zyga> Chipaca: 16.04
[18:04] <Chipaca> zyga: ye
[18:04] <Chipaca> zyga: ok
[18:04] <zyga> ovrh: no, that's not a file, it's just a marker
[18:04] <Chipaca> ovrh: it's a mount option (look in that utab you pastebinned)
[18:05] <Chipaca> ovrh: all those mount entries that don't appear in the gui, because of it
[18:05] <ovrh> Oh, that's what it means
[18:05] <Chipaca> yeh
[18:05] <Chipaca> zyga: is that same file visible "inside", and would those options be there?
[18:05] <Chipaca> zyga: or is this recreated for the benefit of the thing inside?
[18:05] <zyga> yes but I doubt it is allowed via apparmor
[18:06] <zyga> no, no easy way to do that
[18:06] <zyga> we'd need to mount a special fuse filesystem over to do that
[18:06] <zyga> (one that does not exist(
=== prime is now known as Guest79228
[18:07] <sil2100> cachio: could you send me an e-mail once the core18 testing is done? Thanks!
[18:07] <sil2100> o/
[18:07] <zyga> cachio: to me as well please
[18:08] <cachio> zyga, sure
[18:09] <cachio> zyga, I think it will be ready tonight
[18:09] <cachio> it is going slow
[18:25] <mup> PR snapcraft#2428 closed: tests: increase test timeout for plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2428>
[18:30] <mup> PR snapd#6305 closed: cmd: automatically fix localized <option>s to <option> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6305>
[19:43] <sdeziel> zyga: thanks the snapd version from bionic-proposed fixed it for me, thanks a lot for your help!
[21:08] <ovrh> zyga, Chipaca, I submitted the bug report. Here's it if you want to give it a look: https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/1808420 Also, let me know if it's the wrong form or something. (I also wrongly assumed markdown would be supported, my mistake)
[21:08] <mup> Bug #1808420: gnome-system-monitor from Snap does not hide /dev/loop* mounts <gnome-system-monitor (Ubuntu):New> <https://launchpad.net/bugs/1808420>