/srv/irclogs.ubuntu.com/2018/12/13/#snappy.txt

mupPR snapcraft#2426 opened: tests: use fixed version for idna in plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2426>01:32
brlinGood afternoon, from UTC+805:16
brlinI 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?05:54
mborzeckimorning06:22
mvomborzecki: hey06:22
mborzeckimvo: can you take a look at https://github.com/snapcore/snapd/pull/6297 ?06:23
mupPR #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
mvosure06:23
mborzeckimvo: we'll need to cherry pick that patch to 2.3606:23
mvomborzecki: ok - should we run sepolgen-ifgen as part of the tests?06:24
mborzeckimvo: yes, that's a good idea, i'll add it to the selinux PRs06:25
mvomborzecki: I merged this one now06:25
mborzeckimvo: thanks06:25
mvoand cherry-picked, so all good06:26
mvothank you!06:26
mborzeckimvo: great, thanks!06:26
mupPR 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:26
mborzeckiand added a card :)06:27
mborzeckianother trivial PR https://github.com/snapcore/snapd/pull/629806:37
mupPR #6298: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>06:37
mupPR snapd#6298 opened: packaging/{fedora,opensuse}: own /var/lib/snapd/cookie <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6298>06:38
zygaGood morning06:54
mborzeckizyga: hey06:54
mvohey zyga06:55
zyga:-)07:10
zygasorry, a bit sleepy still07:23
zygaI stayed up late and fixed my TV07:23
zygamborzecki: trivial removal of dead code: https://github.com/snapcore/snapd/pull/629307:24
mupPR #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:24
mborzeckilooking07:25
mupPR 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:27
zygamvo: what's the state of the release?07:32
zygaah07:33
zygathe gai_strerror thing07:33
mvozyga: working on it07:36
mvozyga: some bits have landed, but more bits needed07:36
mborzeckidamn, ls -Zd has different output on centos and fedora07:36
zygacannot allocate memory in dnf makecache? https://www.irccloud.com/pastebin/2TrCykuR/07:36
zygamborzecki: what's the difference?07:36
mborzeckizyga: centos drwxr-xr-x. niemeyer google-sudoers unconfined_u:object_r:home_root_t:s0 .07:37
mborzeckifedora unconfined_u:object_r:user_home_t:s0 .07:37
mvosil2100: hey, good morning! one final core18 pr (hopefully the last) https://github.com/snapcore/core18/pull/10307:42
mupPR core18#103: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>07:42
zygamvo: did you see the test failure there?07:52
zygais that expected?07:52
mvozyga: well, yes, I have not had time to look into it :( but tests are unhappy there07:55
zygait doesn't seem related to the nature of the change in the pull request07:55
mvozyga: exactly, looks like something innternal07:56
mvozyga: so snapcraftctl iirc07:56
=== pstolowski|afk is now known as pstolowski
pstolowskihey08:03
sil2100mvo: morning! Looking in a minute08:11
mvosil2100: thank you08:12
zygahello Pawel08:14
mupPR 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
mborzeckizyga: ^^08:28
zygalooking08:29
pedronismvo: morning, sorry I'm a bit late,  what's the status of things?08:29
zygathank you!08:29
zygamborzecki: yes yes yes :)08:29
pedronismvo: I saw some of the PR are landed now08:29
mvopedronis: yeah, progress08:32
mvopedronis: some things still pending though08:32
mborzeckiheh, the code formatted with new gofmt is incorrectly formatted with the 1.6 one08:35
zygamborzecki: yeah08:36
zygaI opened a PR to highlight that before08:36
zygasucks :/08:36
mborzeckii'm thinking, maybe we could go get gofmt (the tool) with 1.6 instead08:36
pedronismvo: are you waiting for me to look at #6243 ?08:37
mupPR #6243: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>08:37
zygamborzecki: hmm?08:37
mborzeckizyga: go get github.com/golang/go/src/cmd/gofmt, this would pull the latest one08:38
zygaaha08:38
zygaI see08:38
zygaas long as people on older releases are happy to integrate this with their workflow, yeah08:38
mvopedronis: its a bit of a target of opportunity - if you think its too much we can just leave it for later08:38
mvopedronis: it seemed its now relatively clean and the win is relatively high08:38
pedronismvo: my main comment there, thinking a bit further, is that the description is misleading, we do daemon-reload in other places?08:38
pedronismvo: if to fix it we really need to serialize daemon-reload then that is not enough, no?08:39
mvopedronis: let me see, I think you are right08:39
pedronisso it would need more work, and doesn't feel a .3 thing08:39
mvopedronis: hm, in the overlord we really only do the daemon reload there afaict - but yeah, lets push it out08:40
pedronislet me double check08:40
pedronismvo: we do reloads in wrappers which is used indirectly by overload for example08:40
pedronissorry, overlord08:40
mvopedronis: aha, its the only explicit place. indeed08:41
pedronisalso interfaces systemd backend does it08:41
pedronislet me put this chat in the PR08:42
mvopedronis: 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 know08:43
pedronismvo: done, thanks for marking as blocked, yea, needs more thinking I fear08:44
pedronismborzecki: 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 thing08:47
pedronismvo: ^08:47
zygacross distribution work is fun08:47
zygayou get to see *all* the buys08:47
zygabugs08:47
pedronismvo: so we are left with 628708:50
mvopedronis: there is one more that I'm working on08:51
mvopedronis: 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 stopped08:52
mvopedronis: 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 active08:52
pedronismvo: I'm not following08:54
mvopedronis: sorry, let me be less terse :)08:54
pedroniswhat breaks? :)08:54
mborzeckipedronis: hm maybe there's a build tag we could use, other than that we can use GODEBUG= switch08:54
sil2100mvo: approved if anything!08:55
mvopedronis: 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 before08:55
mvopedronis: what breaks is that during the seeding boot snapd.seeded stops and that will (AIUI) make systemd start units with the after=snapd.seeded ordering08:56
sil2100mvo: will you guys perform some validation testing on the core18 snap now?08:56
mborzeckipedronis: hm i think we could also do that in the code, set a preferred resolved on a dialer08:56
mvopedronis: 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
mvosil2100: yeah, once all the pieces are in cachio will run tests08:56
sil2100(still no merge-powers sadly)08:57
mvosil2100: we also get tests from cert (cwayne team)08:57
sil2100mvo: yeah, I know the automation from certification, but I also saw some tests coming from cachio last time08:59
pedronismvo: there is no snapd.socket in core18 itself?09:02
pedroniswe write it from snapd?09:02
zygapedronis: correct09:02
mvopedronis: correct09:03
pedronismvo: so we should know what to do, no? we are just being naive?09:04
pedronisI'm still missing if there's a deep problem or a shallow one09:04
pedronis(I suppose that's what systemd does to you)09:04
zygapedronis: 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 that09:05
mvopedronis: we are just naive09:05
zygapedronis: and to spend some more time on making things more robust and better tested09:05
zygapedronis: but in general things feel okay09:06
pedroniszyga: ?09:06
pedronisit's already mostly the case09:06
pedronisthere is little code in core1809:06
pedronisabout this09:06
zygapedronis: 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 package09:07
pedronisit's mostly the baggage of systemd unit keywords (they often do a bit more or less than one would exactly like)09:07
pedroniszyga: sounds like a code org issue09:07
pedronisnot a what the code does issue09:07
zygayes09:08
zygaI said we're mostly okay09:08
pedronisanyway it seems very premature before we got our v0 working09:08
mupPR snapd#6300 opened: travis: use more recent version of gofmt <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6300>09:13
mupPR 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
mupPR 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:19
mvomborzecki: 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 at09: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:22
mborzeckimvo: i don't have more insight, i think i'd play it safe and serialize reloads & mounts09:24
mvopedronis: fwiw 6301 is up and has the bits I mentioned09:24
mvomborzecki: ok, so when we do the mountunit generation / daemon-reload /start nothing no other daemon-reloads?09:24
mvomborzecki: that will be interessting code-wise :)09:25
mupPR 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
mborzeckimvo: yes, that'd the the super safe variant09:25
mborzeckimvo: otoh, your pr only serialized the mounts and seemed to work fine09:25
mvomborzecki: yeah, this is why I was wondering09:26
mborzeckimvo: so we could start small, it's unlinkely we'd introduce a regression09:26
mvomborzecki: 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 version09:26
mvomborzecki: fair point, feel free to report in the bug09:27
mvomborzecki: eh, PR09:27
mborzeckimvo: i'll update the script and let you know09:27
mvomborzecki: \o/09:27
pedronismvo: so stopping something that is not running does something ?09:27
pedronisthat's probably the bit I don't understand09:27
zygapedronis: yes, stops related stuff AFAIK09:27
mvopedronis: coreect09:28
pedronismvo: I'm working on 628709:33
pedronisbtw09:33
mvopedronis: ta09:33
mupPR snapd#6300 closed: travis: use more recent version of gofmt <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6300>09:37
mborzeckimvo: bad news, single mount & many reloads fails the same way09:46
mvomborzecki: thanks, there was hope for a moment :)09:47
mvomborzecki: its fine, makes things more complicated but at least we know now. thanks for checking09:48
mborzeckimvo: i've updated the script https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9 in case yout want to double check the code09:48
pedronisok, so that PR is indeed not enough09:48
mvomborzecki: my brain is too mushy today :)09:48
mvopedronis: yeah, slightly sad09:48
mvomborzecki: but thanks for adding it, will probably be helpful in the future09:49
zygamborzecki: nice work09:51
mborzeckimvo: fwiw, it's harder to reproduce now09:51
mborzeckimvo: i think i'd start with a simpler fix09:53
mvomborzecki: 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 fix09:56
mborzeckimhm09:56
pstolowskipedronis: do you have some time for a HO today?10:02
pedronispstolowski: yes10:03
pstolowskipedronis: standup ho?10:04
pedronispstolowski: yea, but I need 5 mins10:05
pstolowskipedronis: ok10:05
mupPR 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:09
mupPR snapd#6302 opened: wrapprs: address review feedback from #6301 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6302>10:11
mupPR core18#103 closed: static: add missing systemd symlinks <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/103>10:12
pedronispstolowski: now works10:12
pstolowskiok10:13
pedronismvo: I pushed changes/fixes to #628710:30
mupPR snapd#6303 opened: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>10:30
mupPR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>10:30
zygapstolowski: trivial PR with some unit tests for internal functions https://github.com/snapcore/snapd/pull/6303/files10:30
mupPR #6303: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>10:30
pedroniszyga: mborzecki: 6287 needs 2nd reviews btw10:30
pstolowskizyga: ok10:31
Chipacamorning peeps, sorry i'm late10:31
pedronisChipaca: hello10:31
mborzeckipedronis: mvo: btw. do we take any steps to use go resolver on ubuntu?10:31
Chipacazyga: wrt 6303, what were the l10n issues?10:32
zygapedronis: ack10:37
zygaChipaca: https://bugs.launchpad.net/snapd/+bug/180676110:37
mupBug #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
mvomborzecki: iirc we use CGO_ENABLED=0 during the build10:37
zygaChipaca: I think someone misunderstood the translator comment10:38
mvomborzecki: aha, no, wait - just for selected bits like snap-exec10:38
zygaand added <foo>s with the s at the end :)10:38
zygaChipaca: so my idea is10:39
Chipacazyga: brb, need to order a bigger palm on amazon, for the facepalm i need to do10:39
zygaChipaca: if the format is "<.*>s", cut the s and not log anything10:39
zygaChipaca: right? :D10:39
zygaChipaca: and fix the translator suggestions to make sure we say "don't add the frelling s"10:39
mborzeckimvo: pedronis: looking at net/conf.go, i think go gets confused with 'mymachines' listed as one of the hosts sources on arch10:42
mvomborzecki: aha, it inspects nsswitch.conf ?10:42
mborzeckimvo: yes10:42
mvomborzecki: smart!10:42
mborzeckimvo: it's parsing both nsswitch.cofn and resolv.conf, whenever it finds an option/source that's unknown it'll default to libc resolver first10:43
* mvo nods10:43
Chipacazyga: argument %q's %q should begin with < and end with >10:44
Chipacazyga: ?10:44
mborzeckimvo: there's libnss_mymachines.so.2 in my system, owned by libsystemd pacakge10:44
mborzeckimvo: on a system which uses resolved it'll probably default to libc resolver too10:45
zygaChipaca: sounds good10:47
zygaChipaca: are you still off today?10:47
Chipacano10:48
zygamborzecki: yes10:48
zygaChipaca: ah, splendid10:48
zygaChipaca: shall we land https://github.com/snapcore/snapd/pull/6303?10:48
mupPR #6303: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>10:48
Chipacabut i didn't need to take the boys to school today so i turned off my 6am alarm … and then it was suddenly 10:1510:48
Chipacazyga: not without a second review, I'm still smarting from a few others we slipped in too quickly10:48
zygamvo: some comments on https://github.com/snapcore/snapd/pull/628710:51
mupPR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>10:51
mvozyga: thanks10:55
mborzeckiChipaca: maybe something simple to start with https://github.com/snapcore/snapd/pull/6299 ?10:58
mupPR #6299: travis: short cicruit failures in static and unit tests suites task <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>10:58
Chipacamborzecki: can I suggest an alternative implementation?11:03
mborzeckiChipaca: sure, go ahead11:03
Chipacamborzecki: start "script" with "set -e" :-)11:03
mborzeckiChipaca: hm does travis lump all the pieces into one large script?11:03
Chipacamborzecki: apparently11:03
mborzeckiChipaca: 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-phase11:06
Chipacamborzecki: https://github.com/travis-ci/travis-ci/issues/106611:06
Chipacamborzecki: if it works, the advantage of having them in separate lines is we get separate timings for them11:07
Chipacamborzecki: and I like having those timings11:07
mborzeckiChipaca: mhm11:07
mborzeckibut damn travis11:07
Chipacais this an instance of "old man yells at cloud"?11:07
mborzeckihaha11:08
mborzeckiChipaca: ok, pushed set -e, we'll se if it fails for real11:11
mupPR snapd#6304 opened: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6304>11:12
pedronismborzecki: mvo: I missed this,  https://github.com/snapcore/snapd/pull/6277/files  it's a bit of odd change for a .x release11:16
mborzeckiChipaca: seems to work11:16
mupPR #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:16
pedronismborzecki: why the backport to 2.36 ?11:17
mborzeckipedronis: it's not really a functional change, neal could have enabled it any time without that PR11:18
pedronismborzecki: how is not functional?11:18
pedronisit might break things, no?11:19
mvohe 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 out11:19
mborzeckipedronis: the package that's in epel is already built this way11:19
pedronisok11:19
pedronissorry for picking on this, but feature changes in late .x releases are a bit wrong11:20
pedronisto me11:20
mvopedronis: 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 boot11:20
mvopedronis: no worries, your comment is correct11:20
zygaChipaca: https://github.com/snapcore/snapd/pull/630511:20
mupPR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>11:20
mupPR snapd#6305 opened: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>11:20
Chipacawhat's 19.04 called again?11:20
cachiomvo, hey11:21
cachioI see a new core1811:21
Chipacaand why does https://translations.launchpad.net/ubuntu/+source/snapd take you to the cosmic translations? isn't 19.04 open?11:21
pedronisChipaca: disco11:21
cachiois this the final one?11:21
zygaChipaca: about translations11:21
zygaare we importing them?11:21
* pedronis lunch11:21
zygaare we building them in our packages?11:22
Chipacazyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1806761/comments/911:22
zygaapparently not in opensuse11:22
mupBug #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
zygaI should fix that11:22
Chipacazyga: we sync them manually11:22
Chipacamvo: syncing translations is still manual, yes?11:22
zygamvo: kind request to sync 2.37 translations11:22
Chipacaalso seriously why aren't disco translations there yet11:23
zygaChipaca: nice, thank you for that comment11:26
Chipacazyga: i'll push a small change to your pr in a bit11:27
zygasure, thanks11:27
mvocachio: hey, we have one open pR (6403) and then I think we are (finally!) good11:29
mvoreviews for 6403 would be great, maybe Chipaca ?11:29
mupPR 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:29
mvocachio: sorry, it dragged on a bit but things should be under control now once this PR is in11:30
cachiomvo, nice11:30
cachioI'll wait for that11:30
* mvo also lunch but will check tg11:31
mvocachio: yes, no point in testing before this is in11:31
zygayeah, lunch sounds good11:31
Chipacazyga: pushed; wdyt11:34
Chipacamvo: 6403?11:34
Chipacamvo: going to assume you meant 630411:35
mvo*cough* yes11:44
mvota11:44
zygaChipaca: I’ll check soon11:46
mupPR 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:48
pstolowskipedronis: ok, i think what's wrong with the taskrunner11:53
pstolowski*i think i know11:53
zygapstolowski: anything for 2.36?11:53
pstolowskizyga: no11:53
zygaChipaca: looking now12:05
zygaChipaca: in https://github.com/snapcore/snapd/pull/6305/commits/195523c129c7ede53f3969da2e9913bfa18c315912:06
mupPR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>12:06
mborzeckizyga: quick question about release/apparmor.go, shouldn't the code in assessAppArmor or the public functions be wrapped with a mutex?12:06
zygadid you mean to use has suffix or has prefix?12:06
zygamborzecki: mmm, perhaps12:06
Chipacazyga: a clear case of id10t12:06
zygamborzecki: +1 :)12:07
Chipacazyga: if only we had tets!12:07
Chipacazyga: or tests!12:07
pstolowskipedronis: 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 condition12:07
pstolowskito prevent this I think, but it looks suspicious, I think it's incorrect12:07
zygaChipaca: yes, tests are coming in via another PR12:07
Chipacazyga: IKR12:07
zygahehe12:07
Chipacazyga: we could stack this one on that one12:07
zyganah12:07
zyganobody reviews things that are long12:07
Chipacazyga: i mean, we need a test for the >s pruning12:07
zygaand it requires writing another message12:07
mborzeckizyga: seccomp piece too12:08
zygaChipaca: one more on top :)12:08
zygaor land the 1st and then let's rebase12:08
Chipacazyga: I mean, land the tests one, andd let's rebase12:08
Chipacazyga: ding ding ding12:08
zyga++12:08
Chipacazyga: maybe we can convince mborzecki to do a review of the tests one12:08
Chipacazyga: I hear he's into that12:08
mborzeckiChipaca: which pr is that?12:08
zygamborzecki: you're into https://github.com/snapcore/snapd/pull/630312:08
zygaoh12:09
zygait has +212:09
mupPR #6303: cmd: add tests for lintArg and lintDesc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6303>12:09
Chipacamborzecki: 0118 999 881 999 119 725 312:09
mborzeckiChipaca: your IBAN? :)12:09
Chipacaduude12:09
zygawhaaaat :)12:10
Chipacamborzecki: https://www.youtube.com/watch?v=ab8GtuPdrUQ12:10
mborzeckiaaa hahah12:10
pedronispstolowski: ah, so it's some kind of EnsureBefore bug?12:10
pstolowskipedronis: i think so12:10
pstolowskipedronis: if next.Before(o.ensureNext) || o.ensureNext.Before(now) {12:10
pstolowskio.ensureTimer.Reset(d)12:10
pstolowskio.ensureNext = next12:10
zygaChipaca: loool12:10
pstolowskipedronis: the 2nd part of conditional looks wrong to me12:11
pedronispstolowski: there is something there related to coming back from sleep12:11
zygaI read that as EnsureBug bug12:11
pedroniswe'll need to remember/dig12:11
pstolowskipedronis: maybe, but we check existing ensureNext against now(), and then reset to a future next, which I think is the problem in this case12:12
pedronismvo: zyga: I'm going to merge #628712:13
mupPR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>12:13
pstolowskipedronis: i suppose after sleep we have ensureNext in the past, so we should just make sure to simply ensure *now* ?12:13
zyga+112:13
pedronispstolowski: yea, something like that, we'll need to consider various cases12:13
pedronispstolowski: probably needs a bit more attention that I have right now12:14
pedronisbut good we are getting closer12:14
mvopedronis: ta, please squash and I will cherry pick12:14
pstolowskipedronis: ack12:14
mupPR 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
pedronismvo: done12:17
zygamvo: in https://github.com/snapcore/snapd/pull/6304/files is the root directory significant or just carried over from other systemd methods?12:18
mupPR #6304: wrappers: use new systemd.IsActive in core18 early boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6304>12:18
pedronispstolowski: 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 digging12:19
pstolowskipedronis: k, thanks12:19
zygapstolowski: just write down anything you know somewhere :)12:20
pstolowskizyga: good idea. i'm sure after christmas break i won't remember a thing of that ;)12:20
zygapstolowski: perhaps a bug report on snapd12:21
pstolowski(unless we manage to discuss and tackle it before xmas)12:21
pstolowskizyga: yeah, already reported, just need to write down the details12:21
zygasounds good12:21
mvozyga: just carried over, makes testing easier12:22
zygamvo: https://github.com/snapcore/snapd/pull/6302#pullrequestreview-18463462112:22
mupPR #6302: wrappers: address review feedback from #6301 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6302>12:22
zygamvo: +112:23
pedronispstolowski: thx12:23
mvozyga: ta, no travis tests right now all busy, I get lunch and check back after that12:23
zygamborzecki: we should ship translations in snapd packages12:25
zygamborzecki: I'll look at doing that in 2.36.312:25
pedroniszyga: that sounds something for 2.3712:26
pedronisno .312:26
pedronisnot .312:26
zygawhy so? we ship that on ubuntu12:26
pedroniswhich snapd packages?12:27
mborzeckizyga: are you saying other distrons don't ship the translations?12:27
mborzecki(arch doesn't)12:27
pedronisas formulated it sounded like all packages12:27
zygamborzecki: suse doesn't12:27
zygapedronis: we only ship for sure on ubuntu12:27
zygabecause the translations are going in via a different mechanism12:27
mborzeckiah, so something for me to fix on arch12:27
mupPR snapd#6306 opened: release: use locking around lazy intialized state <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>12:28
zygamborzecki: reviewed12:30
mborzeckizyga: assessAppArmor calls the AppArmor*Features() functions, that's why a separate mutex12:31
zygaAh, I see12:32
mborzeckizyga: blindly used just one in the beginnig and go test got stuck :P12:32
zygacan you add a quick one line comment to document that12:32
zygait's correct but non obvious :)12:32
zyga(at least to me :)12:32
pedronismborzecki: made a comment12:33
mborzeckipedronis: thanks, good point!12:33
zygaI think it will mess up tests12:33
zygabut do try12:33
pedroniswe can mock/replace them as anything else12:34
pedronisanyway we have higher level mocking12:35
pedronisalready12:35
pstolowskipedronis: updated https://bugs.launchpad.net/snapd/+bug/180644712:38
mupBug #1806447: Sophisticated snap remove retries a lot and becomes very slow <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1806447>12:38
pedronispstolowski: thx12:39
pstolowskipedronis: 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
pedronisthx12:42
mborzeckioff to pick up the kids13:08
mupPR 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
pedronismvo: last bit we are waiting on is 6304 ?13:14
=== ricab is now known as ricab|lunch
zygaChipaca: hmm13:19
zygaChipaca: the extra noticef is not desired13:19
zygait will mean people still get spammed13:19
zygaah, wait13:20
zygawhat am I saying13:20
zygaI mean the order of fixup and lint13:20
Chipacazyga: after mixing up suffix and prefix, i can't deride you for this13:20
zygaChipaca: I don't think we should be teaching users about the translator's mistake13:21
Chipacazyga: can you explain?13:21
zygaChipaca: do I read your patch right that we lint, then fixup13:21
Chipacazyga: correct13:21
zygaso you will see a bunch of noticef13:21
zyga(that mean nothing to the end users)13:21
Chipacazyga: no13:21
Chipacazyga: because i taught the lint about >s also13:22
zygaah13:22
zygathat's ... confusing then13:22
zygaok13:22
zyga+113:22
zygashould we always lint, then fixup13:22
zygain both cases?13:22
Chipacazyga: which is the other case?13:24
zygalook for calls to lintArg13:24
zygawe do it in two places13:24
zygaI swapped both in my local tree now13:25
Chipacaah, right13:25
zygaI think it's good13:25
zygashall I push?13:25
Chipacazyga: yes13:25
Chipacazyga: have you added tests? :-)13:25
zygaChipaca: tests for the whole init sequence?13:25
zygano13:25
zygaI've rebased on the tests PR13:25
Chipacazyga: 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:25
Chipacazyga: 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
zygaChipaca: YAGNI :)13:28
zygaChipaca: I think the has suffix is still wrong13:28
zygaI'll fix it (after adding a test)13:28
Chipacazyga: wrt YAGNI, this comes up again and again, I'm half tempted to abandon the whole notion13:29
Chipacathe 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 code13:29
Chipacamoving this whole thing into a test would accomplish the same as the current panic code13:30
zygaChipaca: interesting13:31
zygaChipaca: but tests don't run with l10n13:31
zygaand then we cannot fix it13:31
zygaI strongly doubt translators know how to build and run tests13:31
zygaespecially since our tree has zero code for building localization13:32
zygaChipaca: I pushed13:32
Chipacazyga: tests/main/i18n/13:32
zygaChipaca: and when it fails?13:32
zygawhat next?13:32
zygafix all i18n?13:33
zygaand wait until next import breaks them13:33
zygain some way I agree13:33
zygabut I'd separate this13:33
zygathe patch now could go into stable13:33
zygato unannoy users13:33
Chipacazyga: your change makes "foo>s" pass lint13:35
zygayes13:35
zygabecause we cannot do anything about it, that's the point :)13:35
Chipacano13:36
Chipacazyga: "<foo>s" should pass lint13:36
Chipacazyga: "foo>s" should not13:36
zygaah13:36
zygaI see your point now13:36
zygasorry, I will correct that13:36
Chipacaand, arg is known to be non-"", fwiw13:37
Chipacabut that doesn't hurt13:37
zygatests really help :)13:37
pedroniszyga: last travis tests on #6190 failed but apparently github didn't notice13:37
mupPR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>13:37
cachiomvo, do you have models for core18?13:38
cachioI am getting errors to build images for rpi and dragonboard using ubuntuimage13:38
zygathanks, I'll check13:38
zygaChipaca: done13:38
Chipacahmmm13:40
zygahttps://travis-ci.org/snapcore/snapd/jobs/466961767 <- does this make any sense?13:49
zygawhat failed?13:49
Chipacazyga:  github.com/snapcore/snapd/overlord/configstate13:50
Chipacaoverlord/configstate/configmgr.go:31: undefined: configcore.Conf13:50
zygaah, thank you!13:51
zygathat output is terrible13:51
zygabut one thing at a time13:51
mvocachio: what kind of error do you get?13:51
cachiomvo, https://paste.ubuntu.com/p/Z62mXTs6bH/13:52
zygarandom unit test failure https://www.irccloud.com/pastebin/JLOllQuX/13:53
zygachipaca: that's a small one for you :) https://www.irccloud.com/pastebin/DONZWn2s/13:54
cachiopedronis, mvo I need to take my daughter to the doctor13:54
cachioI'll try to be back asap13:54
pedroniscachio: ok13:55
pedronishope nothing too serious13:55
cachiopedronis, a strong pain in the ear13:57
* cachio afk13:57
zygabrb, start the standup without me13:59
zygaI'll join in 5 minutes13:59
sdezielhello, looks like my snap setup is somehow busted14:02
sdeziel$ sudo snap stop lxd.daemon14:02
sdezielerror: snap "lxd" has "seed" change in progress14:02
sdezielthe seeding in question never seem to finish14:03
sdezielI'd been a while that my system has issues related to snapd seeding (whatever that is)14:07
sdezielmy boot never completes as systemd keeps saying that snapd.seeded.service is still running14:07
zygasdeziel: hey14:08
zygasdeziel: I think we are onto this bug14:08
zygasdeziel: mvo can work with you if you stick around for a moment, we're in a meeting now14:08
sdezielzyga: great! I'll stick around14:08
sdezielI already reported this seed bug in LP: #180607014:09
mupBug #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:09
mupPR 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:10
sergiusensmvo: hey, you never got back to me on https://bugs.launchpad.net/snapcraft/+bug/180521914:17
mupBug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged> <https://launchpad.net/bugs/1805219>14:17
mvosergiusens: ineed, sorry for this, I try to reply today but need to ru nnow14:20
zygaChipaca: can you please review https://github.com/snapcore/snapd/pull/619014:22
zygaI know it's long14:22
zygabut I badly need a 2nd review14:22
mupPR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>14:22
zygaChipaca: once landed it will unlock things I need to work on14:28
pedronismborzecki: I requested reviews from you for a couple of pstolowski PRs needing 2nd reviews14:33
mborzeckipstolowski: sure14:33
pedronisthx14:33
mupPR snapcraft#2427 opened: lifecycle: query for multipass install on darwin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2427>14:34
mupPR 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>14:37
=== ricab|lunch is now known as ricab
Chipacazyga: on it14:41
zygathank you!14:41
mupPR 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
mupPR snapcraft#2425 closed: snap: re-add pyc files for snapcraft <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>14:46
mupPR snapcraft#2428 opened: tests: increase test timeout for plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2428>14:49
mborzeckiusing sync.Once in release is tricky14:50
Chipacazyga: +114:56
zygathank you!14:56
zygawoooot14:56
noise][ohsaycanyousay14:57
noise][wow14:57
noise][burned that hacky pass14:57
sergiusensto ALL your accounts?14:57
noise][heh14:57
noise][just all my banks :)14:58
zygasdeziel: mvo is not around anymore, perhaps you want to open a bug report to make sure this is not lost14:58
sergiusensthose are impossible to log in to at times, so no worries14:58
zygawith the features PR we can finally evolve anything we want14:58
zygawith a feature flag controlling it14:58
zygathis is a major milestone :)14:59
* noise][ needs a new throwaway pass for sites that don't matter14:59
sdezielzyga: I've already open LP: #1806070, if another is needed please tell me where15:00
mupBug #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
zygathank you, that will be sufficient15:00
sdezielzyga: 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:01
zygapedronis: ^15:02
sdezielI'm stuck with lxd 3.2 while the stable version is 3.715:02
zygasdeziel: can you please save your state file /var/lib/snapd/state.json15:08
zygasdeziel: if you had authenticated please don't send it to the bug report (snap login)15:08
zygasdeziel: but if you did not it might help us debug15:08
sdezielzyga: could you refresh my memory to check if I had logged in?15:09
sdezielI vaguely remember something like that for the livepatch snap but not sure15:09
zygasdeziel: snap whoami15:09
sdezielemail: -15:09
zygaI think you should be good15:10
sdezielgreat, I'll attach this to the LP bug15:10
zygasdeziel: you have some questions on the bug report as well15:11
sdezielzyga: thanks, I hadn't receive the notifications emails15:11
zygayou can just refresh the bug report page15:12
sdezielyeah, I know but that was my explanation for the delay in response ;)15:13
zygaah, sure :)15:14
sdezielpedronis: for faster turn around on bug 1806070, don't hesitate to ping me in here15:42
mupBug #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:42
pedroniszyga: that machine is really in curious state core requested a snapd restar but it never happened afaict15:45
sil2100Oh, no mvo?15:58
pstolowskisil2100: he had an errand to run; he might show up later but not sure. if not, then he started his holidays...16:12
zygaback from freezing outdoors16:13
zygapedronis: didn't the reporter said that the machine rebooted16:13
zygasil2100: no, what's up?16:13
pedroniszyga: it's in a very odd state overall16:14
zygapedronis: no disagreement16:14
zygapedronis: shall we aks the reporter to restart snapd?16:14
pedronisalso one snap is broken16:14
zygapedronis: it might be useful to also ask for uptime16:14
pedronisand the dates are strange16:15
zygapedronis: remember when I reported a bug when snapd starts _before_ any snaps were mounted16:15
zygapedronis: I think that's still the case16:15
=== hggdh_ is now known as hggdh
pedroniszyga: reported in which sense? is the a LP bug?16:15
zygayes16:15
zygaone sec16:15
pedronisthere16:15
zygahttps://bugs.launchpad.net/snapd/+bug/180586616:17
mupBug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>16:17
zygaChipaca: what's your stance on https://github.com/snapcore/snapd/pull/630516:19
mupPR #6305: cmd: automatically fix localized <option>s to <option> <Created by zyga> <https://github.com/snapcore/snapd/pull/6305>16:19
mupPR 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:23
sdezielpedronis: 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 finishes16:25
zygasdeziel: interesting16:25
zygasdeziel: hold on please, let me check something16:25
zygasdeziel: what was your "snap version" again?16:26
zygaI'm sorry if you said that before16:26
pedronis2.34.216:26
sdezielzyga: https://paste.ubuntu.com/p/q9qbc7HyT9/16:26
zygaok, classic16:27
pedronisit never fully initialized16:27
pedronisso also never refreshed16:27
pedronisafaict16:27
zygasdeziel: can you run journalctl -u snapd16:29
zygaand paste that?16:29
sdezielzyga: http://paste.ubuntu.com/p/zmTKzSXjtD/16:30
zygahmmm16:30
sdezielnot sure if that's related but I noticed many apparmor denials related to the livepatch snap16:31
zygaprobably a consequence16:31
zygaDec 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 refused16:32
zygathis is curious16:32
zygahow is your system networking configured?16:32
sdezielNetwork Manager drives it and the resolver is a local unbound listening on that socket16:33
sdezielit is possible that unbound get started after snapd16:34
zygamhm16:34
zygacan you "systemctl restart snapd.service"16:34
zygalet's see what happens then16:34
sil2100zyga, cachio: so I wanted to touch base on how the current edge/beta core18 snap tests are going16:35
zygasil2100: I don't know16:36
cachiosil2100, hey16:36
sil2100cachio: o/16:36
cachioJust startin a new test cycle16:36
sil2100cachio: thanks ;)16:36
cachioI hope today beta validation can be finished16:37
zygasdeziel: once it is restarted please paste "snap changes"16:37
sdezielzyga: restart worked https://paste.ubuntu.com/p/vkvhdJhk8X/16:37
sdezielzyga: snap changes: https://paste.ubuntu.com/p/x5YW9DC9HQ/16:37
sil2100cachio: 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 images16:38
cachiosil2100, once snapd and core18 snaps are validated, I'll ping you16:38
sil2100cachio: thank you!16:38
zygasdeziel: nice, how about "snap tasks 31"16:38
cachiowell, first if everything goes well we can go to candidate today16:38
cachioand then see when is more convenient to go to stable16:39
cachioperhaps on monday16:39
sdezielzyga: snap tasks 31: https://paste.ubuntu.com/p/hRyDBKFYj8/16:39
zygaDoing   2 days ago, at 09:31 EST  -                         Automatically connect eligible plugs and slots of snap "gnome-calculator"16:39
zygapstolowski: does 2.34.2 have the autoconnect deadlock bug?16:39
zygasdeziel: can you snap abort 3116:40
sdezieldone16:40
pstolowskizyga: that's possible, i'd need to diff to know for sure16:40
zygapstolowski: can you try to find the fix for that16:40
zygaat least we would know where we are16:40
sdezielsnap changes: 31   Undoing  2 days ago, at 09:31 EST  -      Initialize system state16:40
pstolowskizyga: you mean find the PR?16:41
zygapstolowski: or the patch16:41
pstolowskizyga: sure, digging16:41
sdezielsome progress, snap changes: https://paste.ubuntu.com/p/k94DMXKBSY/16:41
zygalook at tasks inside please16:42
zygasdeziel: one thing you might do is update snapd the package on your system16:42
zygadid you install system updates?16:42
sdezielzyga: I pull everything that apt-get feeds me ;)16:43
zygaapt-cache policy snapd16:43
sdezielhttps://paste.ubuntu.com/p/pRQMYdkSBP/16:43
pedroniszyga: we haven't SRU snapd in a while16:43
pedronisit seems16:43
zygaahhh16:43
zygammm16:43
zygasdeziel: thank you16:43
pedronisnot sure what happened there16:43
sdezielsnap tasks 32: https://paste.ubuntu.com/p/pM2bBdqH5w/16:44
pstolowskizyga:  https://github.com/snapcore/snapd/pull/5827 or https://github.com/snapcore/snapd/pull/602716:44
mupPR #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
mupPR #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
zygayep16:44
zygasame thing16:44
pedronisor we have I think but is not quite through16:44
zygapstolowski: based on the output in the last pastebin, do you think this is the same issue?16:45
sdeziel2.35.5+18.04 is in -proposed, I could give it a try16:45
zygapedronis: I have a feeling snapd seeding should become: install core/snapd (restart); refresh core/snapd; install everything else16:46
zygapedronis: or we'll be in a world of hurt16:46
sdezielzyga: I have to run for now but will be back in ~2h. Thanks for everything to all of you16:46
zygasdeziel: thank you16:46
pedroniszyga: unlikely we can do that16:47
pedronisalso why?16:47
sdezielzyga: I'll hold off on the upgrade to the -proposed version just in case some more investigation is required16:47
zygathank you16:47
zygapedronis: why unlikely?16:48
zygapedronis: priorty: ensure snapd can install its own updates16:48
zygapedronis: right now we are observing a situation where it cannot16:48
pedroniswe might not have network16:48
zygasure16:48
pedroniswe need a gadget to do many things16:48
pedronisthe design is that the image should know is good to go16:48
pedronisand then we can refresh it16:48
zygathat doesn't fit classic world at all16:49
pedronisseeding was not designed for classic16:49
zygaunless we assume classic always refreshes snapd via classic packages in case of disaster16:49
zygapedronis: in that case we should rethink seeding on classic16:49
zygait's clearly not working as designed now16: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:49
zygapedronis: none of the mechanisms we have implemented solve the problem of the reporter16:50
zygapedronis: my suggestion was to rethink that to allow snapd to at least be able to refresh itself on classic16:50
pedroniszyga: it might help or bring other bugs16:50
zygapedronis: it may bring other bugs but currently lack of something like that keeps old bugs (fixed bugs) around16:51
pedroniseither way I'm still not sure16:51
pedroniswhat is the reporter issue16:51
pedronisis not like all bionic images didn't seed16:51
zygaI'll try bionic16:51
pstolowskizyga: it's very likely it's that bug. 2.34.2 is from July, bug was fixed in September.16:53
zygathank you for checking Pawel16:54
pedroniszyga: we need a solid seeding process for core, if it's solid should also work for classic16:54
pstolowskizyga: can i help somehow?16:54
zygaI agree 100%16:55
zygapstolowski: not that I think so, I think we need to see what happens with a proposed package after the reporter is back16:55
pstolowskiok16:55
pstolowskizyga: is 2.35.4 confirmed to have the fix?16:55
pstolowskizyga: sorry, 2.35.516:56
zygaI don't know, we don't tag bugs or fixes and milestones together16:56
pstolowskizyga: 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
zygathe reporter is on bionic and has 2.34.x16:57
zygalatest is 2.34.216:58
pstolowskiyes, that version definately has the bug, just trying to estimate if the fix made it into 2.35.5 from proposed16:58
pstolowskiunfortunately #6027 is not fixed in 2.35.5 afaict16:59
mupPR #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:59
zygaI did a fresh install of 18.04.1 with the same version of snapd17:00
zygait was not affected17:00
zygaperhaps just lucky17:00
pstolowskizyga: there were specific conditions to be met to hit this (i described them in the PR)17:03
=== pstolowski is now known as pstolowski|afk
zygamount issue when refreshing core https://www.irccloud.com/pastebin/OYlOfBlU/17:07
zygafunny17:07
kyrofaOoo, a pretty snapd panic: https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/317:14
zygahmm, too bad we don't log the error with state checkpoint17:15
pedroniszyga: yes, that bug pawel mentioned is fairly complicated17:18
pedronisyou basically need to install with --dangerous as first thing on a new system17:18
kyrofazyga, regarding your comment there, isn't that exactly what he just posted?17:18
pedronisor possibly do the same while seeding is still going on17:18
pedronismaybe17:18
zygaoh, I thought there would be more :/17:18
kyrofazyga, you can try -n 100 :P17:18
pedroniszyga: we do log the error17:36
pedronisthose logs are cut17:36
pedronislogger.Panicf("cannot checkpoint even after %v of retries every %v: %v", unlockCheckpointRetryMaxTime, unlockCheckpointRetryInterval, err)17:36
zygaI mean when we say "panic" we could recall the error then17:36
pedronis?17:37
zygaDec 12 03:12:36 localhost.localdomain snapd[992]: panic: cannot checkpoint even after 5m0s of retries every 3s: write17:37
zyga"write" is the error?17:37
zygaor was it just cut in the terminal output?17:38
pedronisas I said those logs look cut to me17:38
pedronisso hard to tell17:38
pedronisbut the Panicf should include the error17:38
pedronisanyway at the end of the day17:38
pedronischeckpoint is just17:38
pedronisosutil.AtomicWriteFile(osb.path, data, 0600, 0)17:38
zygaright17:38
pedronisso yes, I would expect some kind of i/o error17:38
zygaI wonder if it is ENOSPC17:38
zygaor something else17:38
* pedronis mostly calls it a day17:41
pedronisttfn!17:41
zygattyl!17:41
zygahave a good evening :)17:41
ovrhHello! 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.o17:49
zygahey17:50
ovrhAlso, here's the output from `mount`: https://paste.ubuntu.com/p/T4ZKz99CdK/17:50
zygacan you please provide "snap version"17:50
zygaI know what this is but it should not have happened, normally those mounts only exist in a separate mount namespace17:50
zyganot in your main mount namespace17:50
zygaif you open a new terminal17:51
zygaand type "cat /proc/self/mountinfo"17:51
zygawhat do you get?17:51
ovrhzyga, Here's snap --version and the other command's output: https://paste.ubuntu.com/p/3wvsFmnygw/17:52
zygaha17:53
zygaI understand now17:53
zygaso17:53
zygaeverything is all right17:53
zygawhen you run gnome-system-monitor as a snap it doesn't execute in the same mount namespace as your other applications17:53
zygainstead it executes in a special mount namespace that is crafted and only visible for that specific snap application17:53
ovrhSo my gnome-system-monitor comes from snap? o.o I would have bet I installed it through aptitude17:54
zygathe "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 thing17:54
zygait appears so17:54
zygawhich gnome-system-monitor17:54
zygaanyway, mystery solved :)17:54
ovrhDammit, I would have totally lost my bet17:55
ovrh /snap/bin/gnome-system-monitor17:55
zygaovrh: please report a bug with the help of people in #ubuntu-desktop17:55
zygathe application should be smarter17:55
ovrhSo.. the solution is `snap remove gnome-system-monitor && sudo apt install gnome-system-monitor`?17:56
zygaovrh: well, for a quick solution yes. but please do report this bug17:56
zygait should be fixed to operate properly17:56
ovrhzyga, Agree about that. I'll prepare the bug report17:56
zygathank you!17:56
ovrhNo, thank you for your help :)17:57
Chipacaovrh: zyga: the non-snapped system monitor will still show all the squashfs mounts though17:58
Chipacait'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'es17:59
ovrhChipaca, Just removed the snap and reinstalled it from aptitude, I only have 3 entries in the GUI tool now18:00
zygaI would argue that it should show neither :)18:00
zygaovrh: no squashfses?18:00
ovrh /, /boot/efi, /home, nothing else18:00
zygaChipaca: I suspect it filters out things based on /run/mtab18:00
zygaovrh: what is in your /run/mtab?18:01
ovrhzyga, Not sure what you mean18:01
zygaovrh: can you look at the file /run/mount/utab18:01
zyga(sorry, I got the path wrong)18:01
zygacan tell us what is inside please18:01
Chipacazyga: or maybe x-gdu.hide18:02
zygayeah18:02
zygaI bet it is that18:02
Chipacathat's what we started adding it for at least :-)18:02
Chipacastrange that the snapped one doesn't pick up on it though18:02
zygaChipaca: yeah18:02
zygainside a snap you probably don't see that18:02
ChipacaI blame …18:02
zygaapparmor18:02
ChipacaThe salesman drove over the CPU board.18:02
ovrhhttps://paste.ubuntu.com/p/tJwqjDW6T6/18:03
Chipacahm, not a good match, let's try again18:03
Chipaca_Rosin_ core solder? But...18:03
zygaovrh: thank you18:03
zygaplease include this in your bug report18:03
zygaI'm sure it will help18:03
Chipacazyga: out of curiosity i looked at /run/mount/utab here, and it's empty?18:04
ovrhWhere's the x-gdu.hide file? Should I still look there?18:04
zygaChipaca: 16.0418:04
Chipacazyga: ye18:04
Chipacazyga: ok18:04
zygaovrh: no, that's not a file, it's just a marker18:04
Chipacaovrh: it's a mount option (look in that utab you pastebinned)18:04
Chipacaovrh: all those mount entries that don't appear in the gui, because of it18:05
ovrhOh, that's what it means18:05
Chipacayeh18:05
Chipacazyga: is that same file visible "inside", and would those options be there?18:05
Chipacazyga: or is this recreated for the benefit of the thing inside?18:05
zygayes but I doubt it is allowed via apparmor18:05
zygano, no easy way to do that18:06
zygawe'd need to mount a special fuse filesystem over to do that18:06
zyga(one that does not exist(18:06
=== prime is now known as Guest79228
sil2100cachio: could you send me an e-mail once the core18 testing is done? Thanks!18:07
sil2100o/18:07
zygacachio: to me as well please18:07
cachiozyga, sure18:08
cachiozyga, I think it will be ready tonight18:09
cachioit is going slow18:09
mupPR snapcraft#2428 closed: tests: increase test timeout for plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2428>18:25
mupPR snapd#6305 closed: cmd: automatically fix localized <option>s to <option> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6305>18:30
sdezielzyga: thanks the snapd version from bionic-proposed fixed it for me, thanks a lot for your help!19:43
ovrhzyga, 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
mupBug #1808420: gnome-system-monitor from Snap does not hide /dev/loop* mounts <gnome-system-monitor (Ubuntu):New> <https://launchpad.net/bugs/1808420>21:08

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!