/srv/irclogs.ubuntu.com/2019/03/19/#snappy.txt

mupPR snapd#6618 opened: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>00:42
zygaGood morning05:58
mborzeckimorning06:33
mborzeckimvo: morning06:47
mvomborzecki: hey, good morning06:47
zygahey mborzecki, mvo07:43
mborzeckizyga: hey07:43
zygakids off to school, time to work07:43
zygaI took sime time to clean my office yesterday07:45
zygaI must say, it feels great to work in a tidy place07:45
zygaI will try to preserve this condition better than last time07:45
zygaI have a few small PRs that could land quickly, if anyone wants to see07:46
mborzeckizyga: which ones?07:47
zygamborzecki: typedef struct mountinfo is trivial07:47
zygamborzecki: UMOUNT_NOFOLLOW is super trivial07:48
zygathose two can just land07:48
zygamborzecki: there are some short but not trivial branches like fixed private /tmp07:48
zygaor fixes to mountinfo parsing07:48
mvohey zyga07:58
zygagood morning :)07:58
zygahow is your daughter today?07:58
mvozyga: all well07:59
mvozyga: and yours :) ?07:59
zygashe was very hungry today, eating a few times in a row08:00
zygathe older one went to school recently :)08:00
zyga(need to remember about both)08:00
=== pstolowski|afk is now known as pstolowski
pstolowskimornings!08:03
mborzeckipstolowski: hey08:04
mvogood morning pstolowski08:04
mborzeckizyga: do you need a review from pedronis on https://github.com/snapcore/snapd/pull/6608  and the mountinfo one?08:14
mupPR #6608: cmd/snap-confine: umount scratch dir using UMOUNT_NOFOLLOW <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6608>08:14
zygaI will wait for a pass, yes08:14
dot-tobiasgood morning08:17
zygahey dot-tobias08:30
dot-tobiaszyga: Morning 😊 BTW, thank you again for the layouts feature, made both of my snaps possible in the first place! Huge improvement for snapping otherwise “unconfinable” software IMHO08:32
pedronis6608 can land08:52
Chipacaman i wish each log line said what machine it was from :-(09:05
Chipacamorning all09:05
mborzeckiChipaca: wouldn't be suprised everyone has a patch for spread to do just that :P i had one09:08
zygapedronis: hello09:08
zygapedronis: I updated https://github.com/snapcore/snapd/pull/650209:08
mupPR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>09:08
zygadot-tobias: I'm very glad to hear that :-)09:08
zygathank you :)09:09
zygaChipaca: good morning09:09
zygapedronis: thank you, merged now09:09
mupPR snapd#6608 closed: cmd/snap-confine: umount scratch dir using UMOUNT_NOFOLLOW <Reviewed> <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6608>09:09
mvozyga: hey, when you have a spare slot, could you please re-review 6491 - aiui it "just" needs a re-review at this point09:15
mvopstolowski: (or is anything missing in 6491)09:15
pstolowskimvo: no, it needs 2nd review09:18
pstolowskiChipaca: hey, can you cast your eye on https://github.com/snapcore/snapd/pull/6617 ?09:24
mupPR #6617: cmd/snap: fix regression of snap saved command <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6617>09:25
zygamvo: sure, doing so now09:26
Chipacaah, yes09:26
mvozyga: thank you!09:27
Chipacakjackal: ping09:32
kjackalhey Chipaca09:32
Chipacakjackal: hey09:32
Chipacakjackal: which 16.04 image from ovh doesn't support squashfs?09:32
kjackalLet me see what that person said, give me a sec09:33
kjackalChipaca: unfortunately he did not came back to answer your questions: https://github.com/ubuntu/microk8s/issues/36209:34
kjackalI did point him to the discourse topic09:35
Chipacakjackal: thanks09:37
Chipacakjackal: I've raised the issue internally as well09:37
Chipacaif it doesn't support squashfs it's running some random kernel, meaning it's not Ubuntu09:37
kjackaldoes the ovh get certified ubuntu images from us?09:37
Chipacathey've been in trouble with canonical before for selling something as Ubuntu and it not being Ubuntu09:38
Chipacabut I don't know how that got resolved09:38
Chipacaif it did, even09:38
pstolowskigrrr the testing situation is really annoying09:39
zygacan we all stop the line and fix tests09:40
zygaincluding perhaps spending a moment to ensure that the situation is really better, not just not broken again09:41
Chipacazyga: what's broken now?09:42
zygaChipaca: is the situation with /var/snap fixed now?09:42
Chipacazyga: no09:42
zygaso that's enough ;)09:42
Chipacai'm still working on it09:42
zygatests cannot be red for many days09:42
Chipacai'm still working on it09:42
zygaI understand, I'm saying we should all jump at fixing the fundamental issue09:42
Chipacawhich is the fundamental issue?09:43
zygathat is the one-to-all influence of every test09:43
zygaany test can break any other test09:43
zygawe do insufficinent work in making sure the environment is pristine09:43
zygaand the definition of pristine is not strict09:43
zygait's all reactionary09:43
Chipacaquick fix: set workers to the number of tests09:43
zygaI'm partially not joking, it's just impractical to develop snapd for several years and constantly be in a situation where nearly every PR needs to be restarted09:45
zygagithub is down, fine, happens once a year09:45
zygatests don't clean up: *not* fine09:45
zygawe should really fix this09:45
Chipacai'm not disagreeing, but09:46
Chipacathis issue is something else09:46
Chipaca'snap changes' indicates that snapd _did_ remove the snap09:47
Chipacaso there's an actual bug somewhere09:47
zygathat's okay, but the first test that experiences this should stop and fail,09:47
zygaand not influence something entirely different later09:48
zygaonce you fix the problem with current we will still have the very same unreliability problem with tests09:48
Chipacawhat do you mean by "experiences"09:49
zygaa test that, by the end of the execution, due to the bug or otherwise leaves the test environment (system) in a state different from the state it was in at the beginning of the test09:50
zygamy impression is that right now our tests feel like DOS software09:51
zygaone program runs and corrupts something09:51
zygathem sometime later another program dies because of that corruption09:51
zygait's very time-consuming to debug09:51
zygawe should spend the time in a smarter way09:51
mborzeckican i get some eyes on https://github.com/snapcore/snapd/pull/6609 ?09:52
mupPR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>09:53
Chipacaso, we have the snapd-state code09:53
zygamborzecki: enqueued09:53
mborzeckizyga: thanks09:53
Chipacathis problem would go away, i expect, if /var/snap were also part of the things that got nuked every iteration09:53
ChipacaOTOH, maybe the restore code should fail if there's things that shouldn't be there09:54
Chipacaso then the tests _need_ to clean up after themselves09:54
zygaperhaps the assumption that there's a magic cleanup system was flawed09:54
Chipacaso then we are testing that things are clean after cleaning up09:54
mborzeckiChipaca: wonder if that may be the package post/pre rm cleanup code09:54
zygawould tests be really that much longer if install_local enqueued a restore action that removes the test09:54
zygaand the restore code would just check that nothing is left behind (and fail if there was)09:54
mborzeckithough it's only happening on ubuntu-core, hmm09:54
Chipacamborzecki: what's only happening on ubuntu-core? these failures you mean?09:55
zygamborzecki: interesting09:55
zygaon core we get extra snaps for testing09:55
mborzeckiChipaca: yeah, i recall seeing only ubuntu-core there09:55
zygaanyway, I'm grumpy because I see us happily igoring the ephant in the room09:55
Chipacahmmm!09:55
zygaour testing infrastructure needs love09:55
Chipacamborzecki: i hadn't noticed :-/09:55
zygait's not healthy09:55
Chipacaif it's that, maybe it's silly09:55
Chipacabecause is_snapd_state_saved behaves differently on core09:56
mborzeckiheh09:56
Chipacasave_snapd_state behaves differently on core too09:56
mborzeckiChipaca: yup, looking at 3 logs atm, all ubuntu-core09:56
Chipacai thought i'd seen a non-core one, but can't find it now09:57
Chipacaso it might've been unrelated09:57
Chipacathe whole 'snap state file' thing does not exist on core09:57
mborzeckiand we dont uninstall the package on ubuntu-core, because how we'd do it?09:57
Chipacaafaict09:57
Chipacamborzecki: we don't do that either, in the save state thing -- are you saying we do that each loop?09:58
mborzeckiChipaca: my bad, we don't09:59
Chipacamborzecki: might just be coincidence tho10:00
Chipacahm10:01
Chipacamborzecki: in save_snapd_state, when it's core, we copy /var/lib/snapd10:01
Chipacaah and then restore_snapd_lib10:02
Chipacaok fair10:02
Chipacaeep! finally got a shell in a failed one!10:04
* Chipaca runs10:04
mborzeckihahah10:05
mborzeckiChipaca: hm, but we dont restore snapd state for each test10:09
Chipacamborzecki: in core we do10:09
Chipacamborzecki: reset_all_snap does that10:09
Chipacaand this might be the problem?10:09
Chipacaor at least i think we do10:10
Chipacai mean, that's the code that fails10:10
Chipacareset.sh calls reset_all_snap on load10:11
Chipacaso everything that sources it will do that10:11
Chipaca(on core)10:11
Chipaca(on classic, reset_classic)10:11
Chipacaso prepare_suite_each and restore_suite both do that10:12
pedroniswe should restore the state for each test,  lots of things assume that10:16
mborzeckiChipaca: ok, then reset_classic does rm -rvf /var/snap, reset_all_snap doesnot10:18
mborzeckiit calls snap remove which sould do the trick10:19
Chipacapedronis: the -each versions do run for each test10:19
Chipacamborzecki: indeed10:19
mborzeckimaybe we should have a check there to verify that /var/snap does not have any extra data?10:19
Chipacamborzecki: we kinda do :-)10:21
* zyga wonders if we will ever return to the spread measurements idea that he proposed about a year ago10:21
Chipacai mean, that's why it's dying10:21
zygawell, more than a year now10:21
=== ricab is now known as ricab|brb
=== ricab|brb is now known as ricab|bbiab
Chipacazyga: ?10:24
zygaChipaca: I proposed a spread extension where we can add a "measure: " section; anything printed there is stored compared with before/after for each level of nesting10:25
zygaChipaca: so if you print the set of installed packages10:25
zygayou will notice leaked packages10:25
zygaif you print the state of systemd services10:25
zygayou will see systemd services changing state across tests10:25
zygawe can easily measure anything we want10:25
zygaI iterated on this idea10:26
zygaand while doing so found a bunch of bugs in our test setup then10:26
Chipacazyga: and what happened?10:34
zygaI think not enough eyes looking or agreeing with the gravity of the problem10:36
zygaChipaca: I think that we need something that would alert us of a test doing unexpected system change10:38
zyganot just trying to fix them10:38
zygafixing is costly (we untar / remove all the time)10:38
zygachecking is presumably cheaper10:38
zygaso this might also speed up things in the end10:39
pedronisit was also mixed with a change to spread which come with friction10:41
zygapedronis: we could replicate that without spread but arguably the issue is that spread is too open and doesn't give us the ability to tame that10:41
zygapedronis: perhaps that's the way forward?10:41
pedronisanyway "flaky tests" and "test invariant" are still part of my open problems list10:42
zygaI would argue we should solve that with priorty because it hinders any other development done by the team10:43
pedronislet's look at this in the standup (cc mvo)10:51
zygagladly!10:59
zygabrb11:04
mupPR snapd#6619 opened: partition,bootloader: rename 'partition' package to 'bootloader' <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6619>11:06
zygapstolowski: https://github.com/snapcore/snapd/pull/6491 reviewed11:29
mupPR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>11:29
zygamborzecki: looking at https://github.com/snapcore/snapd/pull/660911:30
mupPR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>11:30
pstolowskizyga: thanks!11:30
zygamborzecki: https://github.com/snapcore/snapd/pull/6609 done11:32
mupPR #6609: snap/gadget: introduce volume update info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6609>11:32
zygapstolowski: I think that some of my questions got answers by the time I read to the bottom but I chose not to remove them.11:32
zygapstolowski: it's safer and easier to ask and just get a quick answer11:33
pstolowskizyga: sure, makes sense11:33
* zyga goes for a break11:36
mborzeckiChipaca: have you found anything interesting in the debug shell?11:48
Chipacamborzecki: nothing as yet, but i'm retrying with more debug11:49
Chipacahm12:03
Chipacamvo: 'snap remodel' doesn't print a last \n12:03
ChipacaHAH! found the bugger12:04
* Chipaca notes that is "the thing that causes the bug", not any other meaning of the word12:04
Chipacamborzecki: the 'snap remodel' spread test leaves things in a confused state12:05
mborzecki'confused'12:06
pedroniswell, it's a remodel12:06
pedronis:/12:06
mborzeckiChipaca: installed snap disappeared from the state?12:06
Chipacawell, it's hard to call it 'disappear' when the restore of the test overwrites state.json12:07
Chipacapedronis: it isn't the remodel per se; the restore of the test just was untidy12:09
Chipacai now need to test the fix a few times12:09
Chipacapedronis: we can remove required-snaps. Are we supposed to be able to remove required-snaps?12:10
pedronisChipaca: no, it's a bug in remodel, I actually discussed that mvo this morning12:10
pedronis*with mvo12:10
pedronisChipaca: it's not setting the flag properly12:10
Chipacagrr12:11
Chipacathen this fix gets a lot harder12:11
Chipacapedronis: can you remodel 'back'?12:18
mborzeckido we have a helper to parse size information that has format like 100M ?12:18
pedronisChipaca: yes12:18
Chipacamborzecki: yes, strutil12:18
mborzeckiChipaca: ta!12:18
pedronisit doesn't remove things12:18
Chipacamborzecki: strutil.ParseByteSize12:18
pedronisbut under correct behavior12:18
Chipacamborzecki: it's ISO tho12:18
pedronisit would unset the required flag12:18
sergiusensChipaca: hey, do you know in what snapd version will the """download""" local snaps feature show up in?12:19
Chipacapedronis: so I can remodel back, and snap remove, and it'd be happy12:19
pedronisChipaca: yes12:19
pedronisassuming no bugs :)12:19
Chipacasergiusens: 2.38 afaik12:19
pedronisbut we are interesetd to know if we have some12:19
Chipacasergiusens: but let me confirm12:19
Chipacasergiusens: this reminds me we still need to talk about the commandline options (not this week tho)12:19
Chipacasergiusens: maybe 2.39 :-(12:20
sergiusensChipaca: also, can we consider having a `snap wait-for-ready` command for easier scripting, and until that is done, what is the most bullet proof way to write my own? (e.g.; for multipass we run `multipass version` and wait for the `multipassd` version to show up)12:20
Chipacasergiusens: what is wait-for-ready12:20
sergiusensChipaca: block until snapd is ready12:21
pedronisready in which sense?12:21
Chipacasergiusens: what pedronis said12:21
Chipacasergiusens: snap wait system seed.loaded <- that's one version of 'wait for ready'12:21
sergiusensready to be able to carry over "snap install" commands through the socket (no need to consider networking)12:22
pedronisthen what John showed is mostly that12:23
sergiusensto the minimum, the socket existing and taking connections12:23
sergiusensgreat12:23
Chipacasergiusens: I should probably ask mvo every time somebody asks me about versions-to-features12:35
Chipacasergiusens: 2.38 isn't cut yet, so 2.38 will have the download api12:35
sergiusensthanks Chipaca, that will be a pleasure 🙂12:36
Chipacasergiusens: you saw what its final form was?12:36
* pstolowski lunch12:36
sergiusensChipaca: is that to counter my "pleasure" comment? Should I be afraid?12:37
Chipacasergiusens: GET ..../v2/snaps/<snapname>/file12:37
sergiusensChipaca: I did not get to see it though, no... did it change much from what we discussed12:37
sergiusensah, that sounds usable12:37
Chipaca:-)12:37
Chipacasergiusens: when you saw it it was the same, but .../blob12:38
* Chipaca <- really good at bad names12:38
sergiusensI remember the tusks and husks and all that 😉12:38
Chipacait's all been downhill since candirú12:39
Chipacacerati/candirú/curucú12:39
Chipacapopey: BTW, Feb 11 17:07:15 hal snapd[14673]: desktop.go:129: cannot use line "Exec=/usr/share/code-insiders/code-insiders --new-window %F" for desktop file "/var/lib/snapd/desktop/applications/code-insiders_code-insiders.desktop" (snap code-insiders)12:45
Chipacamaybe something to raise with code-insiders12:45
Chipacapopey: and, as feared, Mar 19 12:31:02 hal snapd[3271]: main.go:141: DEBUG: activation done in 21.615s12:47
Chipacathat's one slow activation12:47
mupPR snapcraft#2505 closed: Test store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2505>12:49
zygaChipaca: question to you sir12:53
zygaChipaca: when is a refresh done12:53
Chipacazyga: it was like that when I got there!12:53
zygaconceptually12:53
zygahah :)12:53
zygaI would like to reset a new time stored in the state when a refresh is ready12:54
Chipacazyga: I did not understand that last statement12:54
Chipacazyga: but12:54
Chipacazyga: please explain12:54
zygaChipaca: when refresh is done, when a part of a change that refreshes a particular snap is deemed complete, I'd like to perfrom some operations12:54
zygaChipaca: to account for that in the state12:55
zygaChipaca: should that be link-snap/12:55
zygaChipaca: or start services?12:55
zygaor a new task?12:55
zygathis may also be relevant for health checks12:55
Chipacapedronis: you _can't_ set a revision 'back' :-/12:55
zygaChipaca: do you know CLOS?12:55
pedronisChipaca: no, you can make a new one though, that is like the first12:56
Chipacapedronis: but i don't have the key for that12:56
Chipacapedronis: dunno who does12:56
Chipacapedronis: do you?12:56
pedronisChipaca: it's the test key12:56
Chipacazyga: no i do not know clos12:56
pedronisit's in the code12:56
pedronisbut let's talk at the standup about this at this point12:56
zyga(defmethod refresh :after ((s snap)) (setf (postponed-refresh-time (state-of-snap s)) 0))12:57
Chipaca:-( ok12:57
zygasomething along those lines12:57
* Chipaca kickbans zyga12:57
zygahehe12:57
Chipacazyga: CLOs are collateralized loan obligations, the internet tells me12:58
zygahttps://lispcookbook.github.io/cl-cookbook/clos.html#method-qualifiers-before-after-around12:58
* pedronis eyes his copy of "The Art of The Metaobject Protocol"12:58
* Chipaca writes back to the kind person from google12:58
Chipacawell, recruiter, 'person' might be a stretch12:58
ChipacaI think the answer to "thinks are rather complex and starting to fail in ways that escape us" is not "let's make it more complex"12:59
zygaall things evolve till the contain an implementation of lisp, that sort of thing ;)12:59
Chipacathings*12:59
Chipacapedronis: I mean, I could push a fix that just does 'snap remove', which will then fail when it gets fixed13:02
pedronisChipaca: that's fine I think13:03
zygaChipaca: so.... where would I put something like that?13:03
pedronisit will fail in a clear way13:03
pedronis(at least)13:03
Chipacazyga: nowhere13:03
pedroniszyga: it depends what you need to know?  link-snap is the easiest place if it's good enough13:04
zygapedronis: yeah, I think link-snap is OK for now13:05
zygapedronis: conceptually where post-refresh hooks run probably13:05
zygas/where/when/13:05
pedroniswe have rerefresh now , so you have options if you need something else13:05
pedronisbut link-snap would be easier13:05
pedronisif it's enough13:05
mborzeckioff to pick up the kids13:05
zygaI think it's enough for now13:06
zygathanks!13:06
zygait will all be a PR soon13:06
* Chipaca honestly didn't understand13:07
* Chipaca will look at the pr13:07
mvoChipaca: reading backlog - verison-to-feature - for some we have this in the forum. for all the "important" ones. remodel test - I miss some details, how can it leave things in state when we restore state.json from a backup?13:08
Chipacamvo: remodel test, fixing it13:08
Chipacamvo: with comments about how to fix it again when you fix remodel and thus break the test fixer13:08
Chipacamvo: i'll push as soon as it's green here13:09
mvoChipaca: woah13:11
mvoChipaca: looking forward to that13:11
Chipaca¯\_(ツ)_/¯ it's not lisp13:11
mvoChipaca: really curious what I'm missing13:11
Chipaca=)13:11
roadmrlots of incredibly silly parentheses13:13
mvoChipaca: at least this part I understand13:13
* mvo is very proud about this 13:13
* zyga is unsure about the LISP comments13:25
Chipacamvo: vvv13:33
mupPR snapd#6620 opened: tests/main/remodel: clean up before reverting the state <Created by chipaca> <https://github.com/snapcore/snapd/pull/6620>13:33
Chipacamvo: ^^^13:33
mupPR snapd#6621 opened: overlord/snapstate: track time of postponed refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/6621>13:34
mvoChipaca: looking13:36
mvoChipaca: thanks! do we actually keep state.json between when we do a restroe for the next test?13:37
mvoChipaca: what I'm missing is why this makes the state untidy13:37
Chipacamvo: this test itself does13:37
Chipacathis test is rather piggy13:37
Chipacaon classic, where we restore the state by hand, it doesn't break (because that restoring cleans things up also)13:38
mvoChipaca: oh, so this restore runs *after* the full restore?13:38
Chipacaon core we use snapd to remove stuff, and that fails because of this13:38
mvoChipaca: aha13:38
Chipacaso13:38
Chipacait's like this:13:38
Chipacathis test restores the state, but does not clean up /var/snap13:38
mvoChipaca: it seems on core we also want to restore the previous state.json. it sounds dangerous what we do right now13:39
Chipacathe next test that installs test-snapd-tools, fails on cleanup13:39
mvoChipaca: ohhhhh13:39
mvoChipaca: now I get it13:39
Chipacaso it might not be the immediate next test13:39
Chipacait would have to install test-snapd-tools first :-)13:39
Chipacaanyway, that13:39
Chipacamvo: on the contrary i'd be happier if restoring state.json wasn't needed (unless we were snapshotting the whole machine)13:40
Chipacabecause we _should_ be able to clean back to a known-good state13:40
Chipacabut, alas, sometimes we don't13:40
Chipacaso i dunno13:40
mvoChipaca: right, except that some tests use "jq" to do things13:40
mvoChipaca: which might make a mess13:40
Chipacayeah13:40
mvoChipaca: but yeah, I guess even then we should write good "jq"13:40
Chipacamvo: those do restore it tho13:40
Chipacaat least, i grepped and it looked like they did13:41
Chipacai wasn't too thorough because i'm tired of red tests13:41
Chipacaand the jq-using tests are all old :)13:41
mvoChipaca: thanks for finding this one, you get a hero medal for this one (https://www.google.com/imgres?imgurl=https://vignette.wikia.nocookie.net/wreckitralph/images/1/1d/RalphHeroesDutyMedal.png/revision/latest?cb%3D20130516213303&imgrefurl=https://wreckitralph.fandom.com/wiki/Medal_of_Heroes&docid=OoNm4g5X82ygWM&tbnid=4S4dCW2qcULhzM:&vet=1&w=783&h=446&source=sh/x/im)13:42
zygamvo: quick trivial for your consideration https://github.com/snapcore/snapd/pull/662213:42
mupPR #6622: cmd/libsnap: rename C enum for feature flag <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6622>13:42
mvozyga: thanks13:42
mupPR snapd#6622 opened: cmd/libsnap: rename C enum for feature flag <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6622>13:42
zygahmm, comparing time is apparently harder than I hoped13:47
zygabrb, see you at standup13:52
popeyChipaca: sorry, i don't know what that means, whether it's good or bad (the DEBUG thing)13:54
Chipacapopey: I'll be getting you a snapd with moar debug, if you don't mind13:55
popeyhah13:55
Chipacapopey: because your snapd is taking 21 seconds to do … nothing? :-)13:55
popeysweet13:55
Chipacanot nothing, but all very quick things13:55
Chipacaso we're missing something :-)13:55
Chipacapopey: i've got a few things on my plate before that tho13:56
Chipacaso maybe tomorrow13:56
popeykk13:56
popeynp13:56
Chipacaany more things on my plate and the carrots will start touching the fish13:56
=== ricab is now known as ricab|lunch
popeyCreate a breakwater with some potatoes13:57
Chipacathe potatos are at gravy carrying capacity13:57
Chipacaas is law13:57
pedronisChipaca: we initialize the interface manager, that might have slow bits13:58
zygapedronis: perhaps we should inject a change (even a fake one) that accumulates the time of the system-key regeneration cost14:03
zygapedronis: it would help with accountability14:03
pedroniswell, the new infra can measure14:03
pedronisout of changes too14:03
zygadoes the new infra measure non-task cost like this? if so that's great14:04
sergiusensChipaca: if I do not wait by other means, I get `error: cannot communicate with server: Get http://localhost/v2/snaps/system/conf?keys=seed.loaded: dial unix /run/snapd.socket: connect: no such file or directory`14:18
sergiusensshould I just loop until that call works? I want to avoid using anything internal that is subject to change14:20
Chipacasergiusens: that's strange, because multi-user.target and cloud-final.target both wait for that14:34
Chipacasergiusens: how are you getting 'in'?14:34
sergiusensChipaca: lxc exec14:35
ograHRM14:35
Chipacasergiusens: does that ssh?14:35
ograshouldnt "apt remove snapd" also remove all installed snaps ??14:36
sergiusensChipaca: no, it just runs whatever I tell it to run in that container14:36
Chipacaogra: purge does14:36
ograbah14:36
Chipacaogra: dpkg -P snapd14:36
sergiusensChipaca: if you say that waiting for cloud-init is enough, then I will do that14:36
ograapt purge does it too ... thanks ... i thought a simple remove suffices14:36
Chipacasergiusens: how do you wait for cloud-init?14:36
sergiusens`apt remove --purge snapd`14:36
sergiusensChipaca: I am not, but I can14:37
Chipacasergiusens: if you can wait for cloud-init, can't you wait for snapd?14:37
sergiusensChipaca: I think we just agreed on what to do14:38
Chipacasergiusens: wait for snapd :)14:38
zygapstolowski: there are new imacs today :) https://www.apple.com/pl/imac/14:53
pstolowskizyga: i'm not looking. lalalla.14:54
pstolowskizyga: ok i lied; i looked14:54
Chipacai'm going for a walk to wake up a bit, bbiab14:58
=== ricab|lunch is now known as ricab
* zyga lunch & walk15:02
zygajdstrand: 3 second PR https://github.com/snapcore/snapd/pull/660715:02
* zyga really gone now15:02
mupPR #6607: cmd: typedef mountinfo structures <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6607>15:02
* cachio lunch15:31
jdstrandzyga: I'm aware of the PR :) I glanced at it, it isn't 3 seconds, but it is fast. I have several things I'm trying to get to, and that is towards the top15:44
zygajdstrand: how can it not be 3 seconds, it's a typedef :)15:47
zygajdstrand: but I'm happy to see the final review15:47
zygajdstrand: don't forget it's the 360 day15:47
jdstrandzyga: cause it is a bunch of them :)15:47
zygathat's always a priority15:47
jdstrandzyga: indeed, that is one of the things that was before it (I just completed that, fwiw)15:48
zygaI'm doing that now15:48
zygajust NaN people left :)15:48
jdstrandheh, yeah15:48
Chipacabrb need to reroute my booter15:50
=== Luke_ is now known as Guest69457
mupPR # closed: core-build#11, core-build#22, core-build#26, core-build#3716:14
mupPR # opened: core-build#11, core-build#22, core-build#26, core-build#3716:15
zygaalmost done with 360s16:27
zyga(and then the walk I promised myself)16:27
zyga360 done, I'll go now because it's getting dark16:34
zygattyl16:34
mupPR snapd#6623 opened: interfaces/builtin/opengl: allow access to Tegra X1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6623>16:39
pedronisChipaca: mborzecki: we can close 6615 at this point, right?16:54
Chipacapedronis: i'm still running that16:54
Chipacapedronis: to confirm my hypothesis16:55
Chipaca(so far it's failed because opensuse is having a day)16:55
pedronisah16:56
ackkhi, does snapd do something special with /snap and snap dirs if the underlying fs is btrfs?16:57
Chipacaackk: no16:58
Chipacaackk: any weirdness you see is entirely of btrfs's making :-)16:58
Chipacapedronis: … and again opensuse :-(17:00
zygaackk: can you tell me more please?17:04
pedronisChipaca: push to make it manual if it's having a day17:06
pedronisChipaca: that's another area that we'll need to think about in our tests17:07
ackkzyga, so it's a bit complicated dev setup I have here. basically my disk is all btrfs, and I'm using "snap try" in a lxd container (which uses btrfs backend as well)17:08
ackkzyga, the issue I'm having which I suspect is related is that sometimes I rsync some files to the prime/ dir then "snap restart mysnap" and I get "no such file or directory" when trying to execute snap commands17:09
ackkbut the files are there17:09
zygaCan you provide a small reproducer17:09
zygaI wonder if rsync replaces the directory17:09
zygaMaking the bind mount die17:10
ackkzyga, it doesn't happen all the times. what I noticed is that the /snap dir in the snap shows as a btrfs subvolume mounted, but that's not true17:10
zygaCan you provide a copy of proc self moujtinfo please17:10
ackkzyga, specifically: /dev/mapper/ubuntu-root on /snap type btrfs (rw,noatime,ssd,space_cache,subvolid=1337,subvol=/lxd/storage-pools/default/containers/maas/rootfs/snap)17:10
ackksure one sec17:11
zygaTying from phone sorry17:11
zygaI will be home in 10 minutes17:11
ackkzyga, http://paste.ubuntu.com/p/SXmVh3XYM9/17:12
ackkzyga, if you're trying to reproduce in a lxd container on your phone, that's impressive :)17:12
zygaIt is an Ubuntu phone ;-)17:12
zygaKidding though17:12
zygaI will try at home17:12
ackkthanks17:12
zygaDo you have the broken setup still17:13
zygaCan you jump into lxd17:13
zygaAnd mointinfo there17:13
zygaLastly jump into broken mount namespace (use nsenter -m/run/snapd/ns/snapname.mnt)17:14
zygaAnd provide that third mountinfo please17:14
ackkzyga, I don't have it anmore at the moment17:14
zygaPlease wrap that into a bug report17:14
zygaOk17:14
zygaOnce you do please :-)17:14
ackkzyga, fwiw the snap-try'd dir also was showing as a btrfs mount17:15
ackkwith a subvol= pointing at the dir (which is not really a subvol)17:15
ackkzyga, that paste is from within the lxd fwiw17:15
ackkzyga, ok I will, thanks17:16
ackkI've seen this happening a lot of times17:16
ackkzyga, if it matters, the snap is --devmode17:16
zygaSnap try is just a bind mount17:16
zygaSnaps sets that up based on the path given17:17
zygaSo it would likely be whatever is powering the lxd container17:17
zygaMy personal setup is not using btrfs17:17
zygaETOOMUCHHASSLE17:18
zygabut perhaps I should dog food more17:18
zygaIs this on openSUSE?17:18
ackkno, ubuntu17:20
ackkI've been using btrfs since xenial here17:20
zygaAha17:21
ackkzyga, ah yeah indeed if you bind-mount a dir it shows in subvol17:22
=== pstolowski is now known as pstolowski|afk
zygaackk: so the bind mount subvol thing is a non-issue?17:30
zygaackk: I wonder about the breakage17:30
zygaackk: I suspect rsync is replacing the prime directory17:30
zygaackk: if this happens, look if mountinfo says "deleted"17:30
zygaackk: that would be a good bug report17:30
mupPR # closed: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#250417:32
ackkzyga, yeah it seems the bind mount just shows the dir as subvol, so I guess it's not an issue17:32
zygaackk: but you said it was broken too17:32
ackkzyga, yeah sorry I mean, it's not something different that snapd is doing wrt the mountpoint17:33
zygaok17:33
ackkzyga, yeah it seems binaries are not found althoguh they're there17:33
zygacan you run "snap run --strace=--raw snap.app"17:34
zygaI wonder what really happens17:34
mupPR # opened: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2493, snapcraft#2495, snapcraft#2500, snapcraft#250417:35
* zyga EODs17:47
zygatty17:47
zygaackk: please follow up tomorrow, I'd love to see that strace17:47
Chipaca#6620 could use a second review17:51
mupPR #6620: tests/main/remodel: clean up before reverting the state <Created by chipaca> <https://github.com/snapcore/snapd/pull/6620>17:51
mupPR snapd#6624 opened: overlord/snapstate, store: retry less for auto-stuff <Created by chipaca> <https://github.com/snapcore/snapd/pull/6624>17:51
Chipacaand, pedronis if you're around, 6624 ^ is nasty but nice17:52
Chipacamy wifi goes AWOL in 8 minutes, so my EOD is then17:52
* Chipaca trying a new thing to see if he can get his sleep schedule sorted17:52
* Chipaca thinks better about it, and adds two minutes to the scheduled wifi shutoff17:54
Chipacaok, EOD, ttyl, hand, etc etc18:00
cachioniemeyer, hey18:31
cachioniemeyer, when you have a minute, could you pleas take a look to https://github.com/snapcore/spread/pull/7518:32
mupPR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>18:32
cachio?18:32
pedronismvo: I don't think the whole of 6624 is viable for 2.3818:46
cachiopedronis, about the card to add tests for service.ssh.disable18:56
pedroniscachio: yes?18:56
cachiopedronis, how should be the gadget scenario?18:57
cachiojdstrand, hey, is there any lp issue for the sru validation?19:00
pedroniscachio: we need something like  main/ubuntu-core-gadget-config-defaults/task.yaml at least19:02
pedroniscachio: then we should explore if we can do something where we boot for real (not just snapd restart) with something made with ubuntu-image19:02
jdstrandcachio: see privmsg19:03
cachiopedronis, ok19:04
cachiopedronis, starting with this, thanks19:05
mvopedronis: looking at 662419:05
mvopedronis: yeah, it looks risky, lets discuss tomorrow, my brain is a bit fried19:09
mupIssue # closed: core18#56, core18#86, core18#89, core18#11720:26
mupPR # closed: core18#43, core18#63, core18#72, core18#90, core18#98, core18#12020:26
mupIssue # opened: core18#56, core18#86, core18#89, core18#11720:27
mupPR # opened: core18#43, core18#63, core18#72, core18#90, core18#98, core18#12020:27

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