/srv/irclogs.ubuntu.com/2019/05/22/#snappy.txt

zygaHi04:36
=== amurray` is now known as amurray
mborzeckimorning05:07
mupPR snapd#6884 opened: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>05:29
zygamborzecki: I've opened a draft PR above05:29
zygaand I'm rushing to the car to take Iza to the new school05:29
zygattyls :)05:30
mborzeckizyga: ok, i'll take a look05:30
zygaI'll get rid of other bits from that branch05:30
zyganamely defer patches05:30
zygaand various other changes that can be broken out05:30
zygathe essence of the main thing is there05:30
zygaI'm not 100% sure about one part though05:30
zygahttps://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R9405:31
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>05:31
zygaI need to make the test more clear so that the relationship (peer groups) is clearly visible05:31
zygamborzecki: the mountinfo-tool program can probably land in tests/lib somewhere05:33
zygaOn my way to the new school now05:38
zygamborzecki: darn, I committed the broken version that was going to work on older python05:40
zygaWell, let’s fix that05:40
mborzeckibtw. totally forgot about the draft PRs, maybe should open one for all of gadget update code05:42
zygayeah!05:43
zygaforce pushed05:46
zygasome weird gnome bug05:47
zygawith x11 I have no desktop background05:47
zygawith wayland I do but lots of other things are broken05:47
zygasome error messages about using freed object in gnome shell05:48
zygaeh05:48
zygaDaughter is now at the new school06:10
zygaApart from the fact that we cannot leave because someone parked next to our car all is good06:11
zygamborzecki: trivial https://github.com/snapcore/snapd/pull/688506:53
mupPR #6885: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6885>06:53
mupPR snapd#6885 opened: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6885>06:54
zygahey pedronis07:03
mvohey zyga, pedronis and mborzecki07:03
zygahey mvo, didn't see  you join earlier07:03
mvozyga: no worries, reading PRs and reporting bugs :)07:04
zygahow are you doing? I have a very eventful day but I'm hoping to make progress07:04
mborzeckipedronis: mvo: hey07:04
mborzeckizyga: +1 on the PR, i think we had a note about that somewhere earlier in s-c code07:06
zygaoh, I'll check07:07
zygathanks!07:07
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:07
zygagood morning pawel07:10
zygamborzecki: one more similar change: https://github.com/snapcore/snapd/pull/6886  -- I'm shaving the main branch to have other tweaks separate so that they don't cloud the non-trivial review of the main part07:13
mupPR #6886: cmd/snap-update-ns: use "none" for propagation changes <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6886>07:13
mupPR snapd#6886 opened: cmd/snap-update-ns: use "none" for propagation changes <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6886>07:13
mvozyga: we have this mount propagation bug that we want in 2.39.1, right? I'm looking into doing 2.39.1 soon(ish) and just wanted to check whats missing07:32
zygamvo: yes, I'm shaving the branch for that now, there's a draft PR with some cruft still07:38
zygamvo: and one test that I mentioned yesterday that fails in the restore phase (fuse mounts, so related)07:39
mvook07:39
zygamvo: the essence of the fix is https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb0707:39
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>07:39
zyga(though as I said the diff will still shrink slightly)07:39
mvozyga: woah, thats big - reading07:40
zygamvo: it's not *that* big, mostly verbose diff in test changes07:41
zygamvo: the non-test code changes are tiny07:41
mvozyga: yeah, lots of test changes07:41
zygamvo: the essence of the idea builds from ...07:41
zygahttps://github.com/zyga/mimic-bug/blob/master/bug.sh07:41
zygamvo: what we were missing is MS_SHARED so that ns:snap events  propagate to ns:user07:42
* mvo nods07:42
zygamvo: interestingly, due to inheritance of sharing flags, bulk of the changes are in snap-confine bootstrap07:42
zygamvo: the only other changes are to mimic construction code:07:42
zygahttps://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-4480ffd44957efa3395867c929f88014R48807:42
zygahere07:42
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>07:42
zygaliterally one line :)07:42
zygamvo: the change makes the stash used during mimic construction private07:43
zygabecause due to the sharing that is now everywhere, events made during mimic construction would clobber it, this essentially makes the mimic behave as  it did before sharing was added on the outer layer07:43
zygamvo: on top  of this I wrote a tool like findmnt07:44
zygahttps://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-427083700c87c7cd79d1ac50787fab0fR107:44
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>07:44
zygait's just a think wrapper around mountinfo07:44
zygabut has two properties: it shows propagation flags better than findmnt07:44
zygaand it has good renumbering features so that it works well in tests07:44
zygait's also great for interactive use07:44
zygausing that tool I crafted some new tests07:45
zygahttps://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-f54c331654290afe84ce29593d97a871R7007:45
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>07:45
zygathat check how things behave with content initially connected, initially disconnected and finally connected then disconnected and reconnected07:46
zygathere's a smilar one for layout07:46
zygaand I will still replicate that for parallel instances07:46
zygathere's a chance parallel instances are still broken because the failure I observed is exactly in that scenario07:46
zygaI wrote the test in defer style because it was way faster07:47
mvozyga: ok07:47
zygabut I will remove defer from this patch07:47
zygaso that it can land  separately07:47
zygamvo: one interesting thing is this existing test07:47
zygahttps://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-a6e200ddb24754df8611a002020deccdR107:47
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>07:47
zygathat used to be broken and is now fixed07:47
zygait essentially captures the fact that layouts *can* correctly change from revision to revision, now, with this fix07:48
zygamvo: it needs careful review07:49
zygaand anyone doing so needs to readhttps://lwn.net/Articles/159077/ and https://lwn.net/Articles/159092/07:50
mvozyga: maybe worth linking to that in the PR description(?)07:53
mvozyga: thank you for the link!07:53
zygamvo: great idea, I will do so07:53
mvota07:56
mupPR pc-amd64-gadget#15 opened: add .travis.yml to enable basic smoke testing <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/15>08:01
mupPR pc-amd64-gadget#16 opened: add .travis.yml to enable basic smoke testing (18) <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/16>08:12
mupPR pc-amd64-gadget#17 opened: add .travis.yml to enable basic smoke testing (20) <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/17>08:13
* zyga is back home08:17
mupPR snapd#6885 closed: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple πŸ˜ƒ> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6885>08:29
Chipacapedronis: https://gopenpgp.org/ !08:29
pedronisChipaca: bookmarked08:33
pedronisChipaca: does my answer in the download topic makes sense?08:34
popey_zyga: is there a bug open for content snaps not being connected sometimes, causing apps to fail?08:37
popey_zyga: I suspect this kde calc bug is a snapd bug https://bugs.kde.org/show_bug.cgi?id=40723408:37
zygapopey_: perhaps many08:37
popey_zyga: as it can't find libqtcore which is in the kde frameworks snap08:37
zygayeah08:37
zygathis is all coming together in https://github.com/snapcore/snapd/pull/688408:37
zygait will be in 2.39.108:37
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>08:37
zygajust shaving the yak so that it can land08:38
zygait fixes a bug where connect/disconnect would be broken for desktop apps08:38
popey_thanks08:38
zygapopey_: that was one tricky bug08:39
zygapopey_: sorry for taking so long to nail it08:39
popey_I can only imagine!08:39
popey_np, glad it's on the radar08:39
zygapopey_: reading the test here https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R50 should show you what is ensured to work correctly now08:39
mupPR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>08:39
zygathe key is that this test runs both as root and as non-root user08:39
zygathat's where the bug has been mostly lurking08:40
zygaroot users are OK08:40
zygaironically all our tests run as root by default08:40
popey_hah!08:40
pedronisironically wouldn't be the word I use08:40
popey_There are many adjectives that could be used here. But we're a family friendly channel ;)08:41
pedronisI always thought it was just problems waiting to happen08:41
mvomborzecki: silly question - do we use the ":role" yaml property in any of our gadgets? just looking at ubuntu-image08:41
pedronisthough is convenient08:41
zygapedronis: I agree08:41
zygapedronis: when I was coding this test I ran it locally as user and coded most of the test to use sudo08:41
mborzeckimvo: we should be, type: mbr is supposed to be legacy, we ought to have role: mbr there instead08:41
zygapedronis: I think I would not stumble onto that part of the problem otherwise08:42
Chipacapedronis: yes indeed08:42
mvomborzecki: aha, I see - I have not seen role: system-boot/system-data in the wild I think(?)08:42
mvomborzecki: we probably need system-recovery here in the future :)08:42
mborzeckimvo: neither did i08:42
mborzeckimvo: we can add a new role08:42
mvomborzecki: maybe a case of YAGNI? anyway08:42
mborzeckimvo: system-recovery fwiw08:42
* mvo adds a note to the trello08:42
mborzeckimvo: probably better to have a new role in case there's actually someone using system-{boot,data}08:43
mborzeckimvo: oh, and system-data may be used implicitly when a rootfs paritition is added automatically08:43
mvomborzecki: yeah, given that its already docuemtned and used in the wild I think you are right08:43
mvomborzecki: yeah, I need to look at this and make it not-automatic but maybe not for v008:43
* mvo adds it to trello08:44
mborzeckimvo: i should be albe to dump the whole gadget update branch as a draft work-in-progress pr, it includes the tool for building images08:45
mvosergiusens silly question - running snapcraft in travis now blocks with "Support for 'LXD' needs to be set up. Would you like to do that [y/N]" - do you have an example for a .travis.yml with snapcraft3/base: core18 that just builds the snap ? (or maybe popey knows?)08:47
popey_Oh, maybe I do. I'll see if I can find one08:48
mvomborzecki: nice, yeah, I may be able to get away with a hack - marking the system-recovery partition with role: system-data so ubuntu-image will not create writable and will also put the files into the right place on disk08:48
mvomborzecki: its a bit of a fugly hack but maybe enough to get me one step further08:49
mvopopey_: that would be lovely08:49
mupPR snapcraft#2570 opened: cli: do not prompt when there is no tty available on stdin <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2570>09:03
Chipacapedronis: I'll be working on the users as soon as i've deconflicted the cohort refresh one09:07
pedronisChipaca: sounds good09:07
albertosottilepedronis sorry to bother you, I saw that you found some time to address the pending forum tags... could you give a look at our request too? https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189/5 Thanks09:09
zygamvo: https://github.com/snapcore/snapcraft/pull/2570/files#r28638921209:12
mupPR snapcraft#2570: cli: do not prompt when there is no tty available on stdin <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2570>09:12
mvozyga: thank you!09:16
zygamvo: socket activation when daemon goes off doesn't work; systemd stops snapd.socket too09:19
zyga(totally offtopic)09:19
Chipacapedronis: in the cohort refresh pr I added an UpdateOptions struct09:20
Chipacapedronis: should device ctx be part of that?09:20
zygamvo: the test squashfs we mount on snapd startup briefly flashes in unity launcher, I think we are missing the mount option that makes the launcher ignore it09:20
Chipacapedronis: or is it being separate (like userID is separate) better?09:20
mvozyga: oh? meh, that will need some investigation then09:20
Chipacax-nothing-to-see-here09:22
cjwatsonChipaca: Re your code import question on #launchpad, LP staff can edit existing code imports09:23
Chipacacjwatson: hi :) i think i probably broke something, or don't understand how any of it works as the whole ppa vanished now afaict09:24
cjwatson... PPA?09:24
cjwatsonyou mean import?09:24
Chipacathere was a ppa and a recipe and an import09:24
Chipacathe import was failing, the recipe wasn't reciping and the ppa was stale09:24
Chipacabut the gnu parallel people reply to "where's instructions for ubuntu" with "john lenton has a ppa"09:25
cjwatsonChanging a code import will not delete a PPA under any circumstances09:25
Chipacaso i thought rather than try to convince gnu people that they're being bottom sombreros, i'd get it working again, but i probably broke something along the way09:25
Chipacacjwatson: never underestimate the power of a sleepy chipaca09:25
cjwatsonRight, *you* might :)(09:25
cjwatson:)09:25
cjwatsonhttps://code.launchpad.net/~chipaca/parallel/+git/parallel looks promising now though09:26
Chipacayep yep09:26
Chipacacjwatson: that's a new one i made last night (trying to import the same thing to bzr failed with a credentials error?)09:26
Chipacasomething about the host name not matching the cert09:27
Chipacaanyway09:27
Chipacacjwatson: I'll pick this up again on the weekend, there is no real urgency to it09:27
cjwatsonChipaca: power tip: if you're quick then you might be able to use https://staging.launchpad.net/~chipaca as a reference for resurrecting deleted config, since staging is only restored from production weekly09:27
Chipacacjwatson: I do appreciate you reaching out though :)09:27
cjwatsonChipaca: but you will need to do that before the weekend as it will vanish early on Saturday09:27
Chipacacjwatson: ack. I guess it's material for tonight then :) thanks!09:29
Chipaca- Run install hook of "fwupd" snap if present (run hook "install": install: cannot create regular file '/usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules': No such file or directory)09:32
mupPR snapd#6887 opened: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6887>09:42
zygamborzecki: one more bit of yak shave https://github.com/snapcore/snapd/pull/688709:42
mupPR #6887: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6887>09:43
mupBug #1829558 changed: Unable to install fwupd <Snappy:Invalid> <https://launchpad.net/bugs/1829558>09:49
pedronisChipaca: no, it should be kept separate, it might also be that once we pass context.Context everywhere we might need to use it less deeply, but we will see.09:53
Chipacaok09:54
mupPR snapd#6886 closed: cmd/snap-update-ns: use "none" for propagation changes <Simple πŸ˜ƒ> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6886>10:16
zygaThanks!10:22
mupPR snapd#6888 opened: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>10:22
zygapstolowski: is snap unset implemented now?10:31
pstolowskizyga Im just about to propose it in a series of PRs10:33
zygagreat, looking forward to use it :)10:34
zygabrb for quick coffee10:34
cachiomvo, hey10:48
* zyga had a great idea10:49
zygabrb10:49
zygare10:53
zygawe live in interesting times for sure: https://www.bbc.com/news/technology-4836377210:57
Chipacasigh11:06
Chipacawe have a test that waits for a condition in a limited loop, and then checks for the condition on exit11:07
Chipacawhich sounds fine and correct11:07
Chipacaexcept those two conditions? not the same one11:07
Chipacaso guess what :)11:07
popey_i have a system where core18 won't install. It fails at the mount step. What info do I need to get from it?11:17
mborzecki 5 files changed, 2256 insertions(+)  <-- guess nobody will the code now :(11:24
mborzeckiat least that 1639 lines are tests11:24
* zyga is happy about this: >11:25
zygamountinfo-tool on core18 :) https://www.irccloud.com/pastebin/J8uVY9P4/11:25
mupPR snapd#6889 opened: tests/main/auto-refresh-retry: fix loop/break condition <Created by chipaca> <https://github.com/snapcore/snapd/pull/6889>11:27
Chipacapopey_: depends :)11:28
Chipacapopey_: _how_ does it fail at the mount step?11:28
popey_https://forum.snapcraft.io/t/core18-fails-to-install-mount/1147211:28
popey_yes11:28
mupPR snapd#6890 opened: gadget: mounted filesystem writer & updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6890>11:30
Chipacapopey_: anything interesting about this system? is it running /var off nfs from a server in antartica, for example?11:31
popey_nope, it's an hp microserver in my house11:32
popey_it has a few snaps installed11:32
popey_huh, I can't even remove snaps either11:33
Chipacahmm11:36
Chipacapopey_: what does dmesg say?11:36
Chipacasounds like something nasssty11:37
popey_nothing out of the ordinary11:37
Chipacapopey_: what does it say when you try to remove a snap? also a timeout from mount?11:38
popey_yeah, added to the forum post11:38
popey_repeatedly11:38
popey_(every 3 mins)11:38
Chipacahmmm11:38
Chipacapopey_: ^C should abort that cleanly fwiw11:39
Chipacazyga: want to have fun? ^11:39
zygaChipaca: I always want to have fun11:39
Chipacaikr11:39
Chipacameanwhile I'll go have lunch instead11:40
zygapopey_: can you look at dmesg to see any suspicious kernel messages?11:40
popey_I'm tailing it and see nothing out of the ordinary, just a bunch of the usual apparmor stuff11:41
zygapopey_: when something survives SIGKILL it is either 1) kernel recycled processes and systemd is confused or 2) the process is in an uninterruptible part of the kernel and cannot be killed11:41
zygapopey_: run top, any process with "D" state?11:41
popey_hmm, yes11:41
popey_might be io blocked11:42
pedronisChipaca: did another pass on 6564, thanks for the work there, fear a couple more nitpicks though11:42
Chipacapedronis: :'( but also agreed with you11:42
Chipacapedronis: fwiw #6816 is defonclicted and green11:47
* Chipaca tries to actually go have lunch11:47
mupPR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>11:47
pedronisChipaca: yes, next on my list11:48
pedronisthank you11:48
mvohey cachio !11:59
mvocachio: thanks for the update on the stable core release!12:00
mvocachio: all makes sense now :)12:00
mupPR snapd#6887 closed: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple πŸ˜ƒ> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6887>12:01
cachiomvo, hey12:02
cachiomvo, yesterday we were waiting until last hour to do the promotion but finally we couldnt12:02
zygamvo: thank you12:02
cachiomvo, do you prefer to make it after the stand up? or now?12:03
mvocachio: either way is fine12:09
mvocachio: now is ok12:09
=== ricab is now known as ricab|lunch
popey_zyga: Chipaca a reboot """fixed""" it ;)12:17
popey_sorry for the noise12:17
Chipacapedronis: cachio: oops, yes 6889 and 6883 address the same issue12:18
cachioChipaca, :)12:19
Chipacacachio: what does the 'ip netns delete testns' accomplish?12:20
Chipacacachio: wondering whether i should merge yours into mine or viceversa :)12:20
cachioChipaca, if you execute twice the same test, the "ip netns add testns" fails12:21
cachiobecause it is not deleted during the restore12:21
Chipacacachio: ah12:21
cachiothe test was leaving the namespace created12:21
Chipacacachio: wrt your fix for the loop thing, i like mine more because it uses a variable for the string (no dupe string), and doesn't print out the failure in a loop12:21
Chipacacachio: but yours has more fixes than just that12:22
Chipacacachio: i'll close mine12:23
cachioChipaca, nice, thanks :)12:23
mupPR snapd#6889 closed: tests/main/auto-refresh-retry: fix loop/break condition <Simple πŸ˜ƒ> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6889>12:24
pedronisChipaca: commented on #6816, I think we need to agree on the func signatures/Options12:33
mupPR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>12:33
Chipacapedronis: the way i split it, UpdateOptions had everything that was about the update, whereas outside were things about how/where the update run (so state, user id, context would be outside of options, but name and flags would be inside)12:42
Chipacapedronis: not sure what the rationale would be to split out name and flags12:42
pedronisChipaca: because you can craft an options and use it with many names, we don't support it or want but in theory you could pass it in UpdateMany as well12:44
pedronisChipaca: about flags, it's already a struct. I don't think the goal is to have functions that take one struct. The goal is to bundle things reasonably12:45
pedronisChipaca: anyway my strong opinion at the moment is about name and the order of userID12:46
pedronisChipaca: st, name, options, userID, flags  seems a decent signature from where we stand atm12:49
Chipacapedronis: and device context?12:49
pedronisyes12:49
Chipacapedronis: at the end?12:49
pedronisthere are different functions taking that12:50
pedronisyes, at the end12:50
ChipacaI could just do like I did in install, and multiply the functions12:50
Chipacaleave the struct for later12:51
pedronisthat is a problem too, multiple styles12:51
Chipacabut when i did install we said yeah do it via options so i did so i now i need to do over12:51
pedronisChipaca: we agree to do options, not exactly how they would look like12:52
mupIssue core18#129 opened: Multiarch isn't working <Created by xordspar0> <https://github.com/snapcore/core18/issue/129>12:52
zygamup still has the typo "issues" (good) vs "issue" (broken)12:52
pedronisChipaca: I mean, doing a refactor and a feature in one commit/PR is a risky move12:52
pedronisChipaca: anyway, it's probably personal but this snapstate.Update(st, 0, &snapstate.UpdateOptions{Name: "foo", Channel: "stable"}) looks weird to me12:54
pedronisthe 0 position, and the name inside12:54
pedronisit might also be that I don't feel the name is an option here12:54
pedronisis the main thing we act on12:55
pedronisbeing in the struct means you can also swap it around12:55
pedronis&snapstate.UpdateOptions{Channel: "stable", Name: "foo"}12:56
pedronisagain not a clear win to be able to do that12:56
* zyga watches spread cycles cycle12:56
pedronisChipaca: maybe I'm sounding unreasonable, hope not12:57
Chipacapedronis: it seems arbitrary, but that might be on me12:58
pedronisChipaca: maybe your reference point it the store methods, SnapInfo / Find12:59
pedronisnot a fan of them, but they are fairly different, in terms of what they take or not12:59
Chipacaboth of these seem to be trying hard not to be SomeOperation{ the stuff it needs }.Do()13:00
* Chipaca hides13:00
Chipacamaybe go needs named arguments a la python13:00
* Chipaca hides even more13:00
pedronisChipaca: maybe it does13:00
mvopedronis, Chipaca standup :) ?13:01
Chipacaops13:01
Chipacayes13:01
pedronisChipaca: but I invite to consider the differences between name for Update vs Query in Find13:01
mborzeckizyga: standup?13:01
pedronisChipaca: also notice that at the moment SnapSpec is just Name13:01
zygasorry, joining13:01
pedroniswhich is funny13:01
pedronisin its own way13:02
pedronisChipaca: so maybe it merits the reverse treatment at some point13:02
mupBug #1830051 opened: Fails to recognize UTF-8 locale <Snappy:New> <https://launchpad.net/bugs/1830051>13:44
mupBug #1830052 opened: Ellipsis printed in UTF-8 regardless of locale <Snappy:New> <https://launchpad.net/bugs/1830052>13:44
mborzeckirunning ediff on hexl views of partition tables, fun :)13:55
cachiomvo, core 2.39 is in stable now14:07
=== ricab|lunch is now known as ricab
cachiomvo, snapd 2.39 also promoted to stable14:27
mvocachio: \o/ thank you!14:29
mupPR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#3814:40
kenvandinewoot14:41
mupPR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#3814:41
cachiomvo, yaw14:55
zygamvo: core20 kickof URL?15:00
pedronismvo: are we using the same hangout as yesterday?  or something else15:00
mvozyga, pedronis sorry, added a url to the invite now15:00
mvosilly me15:00
sergiusenspedronis: not to let the conversation on the forum cold (wrt tracks, content interface, stage-snaps), I am not sure what you are asking. Also, I am not +1 nor -1 the request at all.15:00
mvosergiusens: hey, did you see my earlier question about how to run snapcraft 3 in travis ?15:01
sergiusensmvo: no, sorry, it is a bit involved and it is what I said we would fix with travis in the coming days but I can give you something that would work today15:02
mvosergiusens: waiting some days is fine15:03
sergiusensmvo: by involved, I mean 8 lines instead of 2, something like this works https://github.com/snapcrafters/gimp/blob/use-use-lxd/.travis.yml15:03
sergiusensalthough I would put most of the lxd scaffolding in the `install` stanza for travis instead of `script`15:04
mvosergiusens: thanks! I'm in a meeting right now but have a look once this is over15:08
mvosergiusens: looks very reasonable, thank you!15:09
mvosergiusens: out of curiosity, how will it look soon?15:09
sergiusensmvo: travis has a concept of actions and another one I cannot recall the name for now... regardless of that implementation detail, you will be able to say you want to have an environment that is correct for snapcraft and then just call `snapcraft --use-lxd`15:17
sergiusensthis is one of the work items we have for the Montreal Summit15:17
sergiusensmvo: if you tell me where you want to build snaps on travis, I am happy to do a PR and as a side effect of that write up some documentation15:19
sergiusensbut right right now, I need to go and pickup my kid from school, I will be able to look into it an hour and a bit from now15:20
mvosergiusens: nice,thanks for this update15:28
mvosergiusens I think I know all I need to know15:28
mupPR snapd#6884 closed: WIP LP:#1828354 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6884>15:33
mupPR snapd#6891 opened: many: make new mount points MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>15:33
zygareplaced one WIP branch with one that's much like the real thing15:33
zygamborzecki: hey still around?15:33
* cachio lunch15:34
zygamborzecki: in case you are https://github.com/snapcore/snapd/pull/688815:35
mupPR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>15:35
cmatsuokazyga: script fixed, the problem was the cpio format15:52
pedronismvo: pstolowski: this how it works ATM btw just to confirm (that's a snap with a no-op configure): https://pastebin.ubuntu.com/p/YJMd5KDMDZ/16:13
pstolowskipedronis: ack, good, ty16:15
=== pstolowski is now known as pstolowski|afk
pedronisChipaca: +1 to 6564 with a question16:47
sergiusensmvo: pedronis is it correct to assume that if I want 2.39 today I need to install core?17:27
sergiusensit does seem so in practice17:27
jdstrandroadmr: hi! are we to the point of doing git pulls for the review-tools? if so, can you pull 20190522-1231UTC?17:33
jdstrandroadmr: I was going to do YYYMMDD but then I realized I sometimes ask you to do a second in the same day, so went out to the minute17:34
pedronismvo: cachio: what's the process for the snapd snap, it has a version like 2.39+git48.g1ae2fb7 for stable17:39
pedroniswhich is not nice17:39
pedronissergiusens: you mean whether it's SRUd? seems not17:40
sergiusenspedronis: just connecting the dots... if I move snapcraft to core18 and have an assumes on snapd239 it would not be satisfied until snapd is offered as a snap or the deb SRUed17:42
sergiusensif SRUing is in plans, all is good though, there is no urgency, I am just aligning the order of work17:43
jdstrandpedronis, ogra: hey, remind me, as the owner of an Ubuntu Core system (ie, *not* the gadget publisher, etc), is it possible for me to adjust the kernel command line? My understanding is 'no'17:45
pedronissergiusens: you probably need mvo for the timings17:46
cachiopedronis, mvo defined that but it is following the same format since long time18:04
cachiopedronis, I agree on that it is not nice18:05
cachiopedronis, I think we never discussed a version pattern for snapd snap, we just did it for core18 snap18:06
pedronisI think for stable at least it should be just 2.39 or 2.39.x etc18:07
pedronisbut sounds we need to talk with mvo18:07
cachiopedronis, yes18:07
sergiusenspedronis: I suspect your version setting will do the right thing if you go with an annotated tag instead of a normal git tag18:29
ograARGH !18:47
ogradid we just have a core update ?18:48
ograhttps://imgur.com/a/QgwRKo518:48
* ogra knew running his 3D printer on UC16 wasnt a good idea !18:48
ograjdstrand, well, you can surely manually edit the cmdline parameters ...18:49
jdstrandogra: so, I can update grub on a core device? I'm just thinking through sepculative execution and in particular hyperthreading (nosmt)18:50
jdstrandogra: grub in this case since I'm thinking about intel, but more generally it could be armhf/arm64 so uboot/whatever18:51
ograjdstrand, there is a grub.cfg file somewhere in /boot/grub that carries the default cmdline18:52
mupPR snapd#6564 closed: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6564>18:52
ograon arm it is usually nside the uboot.env ... which you can edit with the fw_setenv/fw_getenv tools from the shell (only UC16) or from the uboot shell18:52
ogra(arm not being the rpi :P ... there it is in /boot/uboot/cmdline.txt)18:53
jdstrandI see. so yes, the owner of the device can edit these things if desired. ok, thanks!18:54
ograas long as you have a login or serial access at least18:54
* jdstrand nods18:55
* ogra goes and starts over with the printer ... hoping there wont be an emergency point release today :P18:56
* cachio afk19:03
=== ComradeCrocodill is now known as Crocodillian
mupPR # closed: pc-amd64-gadget#10, pc-amd64-gadget#11, pc-amd64-gadget#14, pc-amd64-gadget#15, pc-amd64-gadget#16, pc-amd64-gadget#1719:07
mupPR # opened: pc-amd64-gadget#10, pc-amd64-gadget#11, pc-amd64-gadget#14, pc-amd64-gadget#15, pc-amd64-gadget#16, pc-amd64-gadget#1719:08
kyrofajdstrand, zyga we can specify autoconnections in the gadget now, right? Do we have docs for that?19:19
mupPR snapd#6834 closed: daemon: pass the model to the create known user helpers (instead of full Overlord) <Remodel :train:> <Created by pedronis> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6834>19:22
kyrofaogra, HAHAHAHAHA19:32
kyrofazyga, that "please don't update me, I'm busy" functionality we've talked about should probably also apply to core updates/reboots ^19:33
kyrofaroadmr, you around? Can you confirm that these docs are up to date and good to go for the snap proxy? https://docs.ubuntu.com/snap-store-proxy/en/19:41
=== daniel is now known as Guest56737
roadmrkyrofa: I am around but I'm not the best person to confirm that - sparkiegeek, bloodearnest, twom might be better candidates. They're UK timezone so probably asleep now19:42
jdstrandkyrofa: we can, yes. there should be docs. I don't know otoh which page it is19:42
kyrofajdstrand, hmm. Not on the gadget page anyway19:43
roadmrkyrofa: if you want to use the snap-store-proxy yourself the docs should be reasonably accurate and you can always ask us for help. If it's for sharing with a third party, it'd be best to wait for confirmation from the above mentioned folks πŸ˜„19:43
bloodearnestthose docs are current19:43
kyrofaroadmr, yeah, it's for sharing19:43
kyrofabloodearnest, thank you!19:43
roadmrthanks bloodearnest πŸŒƒ19:44
jdstrandroadmr: hey, did you see my request for a review-tools pull?19:44
jdstrandkyrofa: perhaps degville knows?19:44
roadmrjdstrand: I did! oooh fun! let's try this19:44
roadmrperfect chance to adapt my fire-and-forget script too19:45
mvosergiusens sorry for the delay, we should have released the snapd snap today as well (2.39), let me check19:45
jdstrandroadmr: cool. thanks. no rush, just wanted to make sure you saw it. if it works then I will stop using the bzr branch immediately19:46
mvocachio: (just reading backlog) there should be a 2.39 snapd snap and that is what we need to promote and test, it might get superseeded from beta when there is a new commit to 2.39 but thats the one we should promote to candidate/stable (the 2.39) "snapcraft history snapd" has the exact revision, its around 3289. it is slightly different from the way core is getting to beta, happy to talk about this tomorrow before the HO (for the details)19:47
degvillekyrofa / jdstrand: they are the latest (and only) docs that I know of for snap store proxy.19:54
kyrofadegville, sorry, we had two conversations going at once. The question for you was: have we documented gadget interface auto-connection anywhere?19:54
degvillekyrofa: ah, right, no worries. re: gadget auto-connections, no - I don't think we've added anything to the docs to cover this. I can sync with zyga tomorrow and get back to you.20:22
* zyga is around but a bit too late to jump into new topics20:22
zygasorry kyrofa, degville20:22
degvilleno problem zyga! it's getting dark :)20:23
mupPR snapd#6892 opened: tests: reuse the image created initially for nested tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6892>20:23
kyrofadegville, zyga thank you, that would be helpful for some stuff I'm writing20:55
* zyga gets the last part of the bug21:47
* zyga EODs21:47
zygattyl21:47

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