/srv/irclogs.ubuntu.com/2019/09/25/#snappy.txt

mupPR snapd#7504 opened: tests/cmd/debug_state: make the test output TZ independent <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7504>00:56
mborzeckimorning05:05
mvogood morning mborzecki05:05
mborzeckimvo: hey05:06
mborzeckihmm google:ubuntu-18.04-64:tests/main/mount-ns:inherit failing, looks like the expected mountinfo content needs and update, but why doesn't it fail always05:08
mvomborzecki: meh, that sounds like a zyga question05:12
mupPR snapd#7500 closed: api,timings: report duration via Doing column for ensure/startup <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7500>05:14
mupPR snapd#7501 closed: interfaces/kubernetes-support: allow use of /run/flannel <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7501>05:15
mupPR snapd#7502 closed: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7502>05:15
mupPR snapd#7505 opened: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7505>05:19
mborzeckimvo: zyga: this should fix the problem ^^05:19
mupPR snapd#7504 closed: tests/cmd/debug_state: make the test output TZ independent <Simple 😃> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7504>06:41
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:00
mborzeckipstolowski: hey07:02
mborzeckiduh gorename being silly and going through the whole of GOPATH07:16
zygahey ho07:26
zygasorry for starting late07:26
zygaI'm feeling so so still07:26
mupPR snapd#7506 opened: devicestate: add support for gadget->gadget remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7506>07:33
mvopstolowski, zyga hey and good morning!07:34
mvozyga: no worries, get well07:34
pedronismvo: hi, I put some questions in 750607:43
=== His_Dudeness__ is now known as huenzelgruenz
pedronismvo: it would be good if either mborzecki or you did something about #716607:45
mupPR #7166: client: add doTimeout to http.Client{Timeout} <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>07:45
mborzeckipedronis: i keep working on that07:45
mvothanks pedronis07:46
mvopedronis: I can scope down 7506 to only allow track switching for now maybe?07:47
mvopedronis: but I guess the question remains the same07:47
mvopedronis: we need a check to ensure the volumes are compatible, right?07:47
pedronisyes07:47
pedronisanyway I doubt it's a small task, it sounds really more mborzecki material once he is done with other stuff07:48
mvopedronis: yeah, that should be ok07:48
pedronisJohn will pick up #737707:49
mupPR #7377: patch: add an overlord patch that normalizes channel in state <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7377>07:49
mvopedronis: great!07:50
pedronisas I discussed with him yesterday07:50
mupPR snapd#7505 closed: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7505>07:51
pedronismvo: I need to think a bit more about #7348, I'm not happy with the regression in some cases, I'm not happy with the complexity of the clean solution either07:54
mupPR #7348: snapstate,store: check assumes early before downloading the snap <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>07:54
mvopedronis: fair enough, we can just close it if you feel it hurts more than it helps07:55
pedronismvo: no, maybe there is just cheap way out, but I really need to focus on some other things, we can try to rediscuss it in the next days07:56
mvopedronis: ok07:56
pedronismvo: #7434 is ready for review07:59
mupPR #7434: seed/seedwriter:  implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>07:59
mvopedronis: thanks, looking08:03
pstolowskipedronis: hey, https://github.com/snapcore/snapd/pull/7468 is referencing itself in the comment (wrong PR #)08:05
mupPR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>08:05
pedronispstolowski: ah, anyway we probably want to wait for them to land one by one08:06
pedronisI haven't pushed the big one through all the way08:06
pedronisbecause too much rebase complexity all over08:06
pstolowskiack, yes i can imagine08:07
pstolowskipedronis: what would be the next to review after 7434?08:08
pedronispstolowski: I think it's actually #744108:09
mupPR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>08:09
pstolowskipedronis: btw did you force-pushed 7434 a moment ago? i was reviewing it and at some point github told me to refresh, but there was just 1 commit08:09
pedronispstolowski: yes, I added some test lines08:10
pedroniswhere there was a ...08:10
pstolowskipedronis: ok. it's a bit confusing when something like this happens ;)08:10
pedronisI didn't know somebody was already reviewing it08:11
pedronispstolowski: anyway I added exactly lines at the very end: https://github.com/snapcore/snapd/pull/7434/files#diff-81b90abba270c6b3849a0191b406c81bR71908:11
mupPR #7434: seed/seedwriter: implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>08:11
pedronisthere was a // check snap-revision  // ...  there08:11
pstolowskithanks08:12
pstolowskipedronis: btw all the //XXX: channel stuff is waiting for John's changes?08:13
pedronispstolowski: no, I added to the description now, it is taken care in a follow up just about channel08:14
pstolowskiok08:14
pedronisthough I expect later changes again because of some decisions about UC20 models08:14
pedronispstolowski: it's done in #746708:14
mupPR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>08:14
pedronispstolowski: related to the // ... I'm sure I forgot some small todos here and there, I'm trying to address them when I merge master into things when the prereq lands08:15
pedronisbut big things are taken are along the sequence08:15
pedronisas I mentioned I do have code that makes image.go tests pass again, that's something I'm trying to finish today08:16
pedronispstolowski: we do use just a for assertion here and there, is not the only place there08:19
pedronisI mean across the codebase08:19
pstolowskipedronis: ok, fair enough08:19
mborzeckipedronis:  pushed an update to #716608:46
mupPR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>08:46
pedronismborzecki: thx, queued to look at08:47
mborzeckipedronis: great, thank you!08:47
pedronismborzecki: are you going to work on the issue with invalid old gadgets that was discussed yesterday?09:26
mborzeckipedronis: yup, i'm working on it right now09:26
pedronisthx09:27
pedronispstolowski: right now it seems you are commenting on some code that exists already like that in image.go09:30
pedronisnot saying that it might not get more confusing now that is getting lifted09:30
pedronisand might need more comments09:31
pedronisbut a bit of context maybe is useful09:31
pedronispstolowski: I put a link to the original code in the response to one of your comments09:32
pstolowskipedronis: hmm, maybe... it's the inherent problem of stacked PRs :( (not your fault by any means)09:32
pstolowskieasy to get lost09:32
Chipacapedronis: in #6958 we implemented download via snapd as a POST. I asked why it wasn't a GET, we discussed it in the standup, and apparently it needed to be POST … but we didn't write down why, and now I don't remember09:33
mupPR #6958: Added api endpoint for downloading snaps <Created by glower> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6958>09:33
Chipacapedronis: do you?09:33
pedronisChipaca: we might want to send alternative auth bits or http proxy config at some point it09:34
pedronisit would get unwieldy as GET params09:34
Chipacafair09:35
Chipacamvo: ^^^09:35
pedronispstolowski: also maybe you are re-reviewing code?  the only new code in that PR is https://github.com/snapcore/snapd/pull/7441/commits/ab5e4c151488cc399946a42ce413752c9a1651bd09:37
mupPR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>09:37
pedronispstolowski: btw fwiw I fixed the chaining ref in 7468, it's based on #746709:41
mupPR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>09:41
Chipacaif y'all are hungering for something to review, #7320 is sitting there09:41
mupPR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>09:41
pedronisChipaca: I queued it, I skimmed it, it seems to need a couple of tweaks09:47
zygamvo: I'll get some meds and work on triaging09:58
zygamvo: I worked with roger in the morning, I have some updates on that, save them to the doc09:59
pedronismvo: this is interesting: https://forum.snapcraft.io/t/first-boot-doesnt-recover-if-system-restarts-while-snapd-is-starting/1339210:04
* mvo is in a meeting right now10:04
zygapedronis: we discovered that yesterday10:06
pstolowskiChipaca: my only reservation wrt #7320 is what i described in general comment, the fact that snap run will be affected. not sure if this is going to be an issue in practice10:11
mupPR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>10:12
mvopedronis: just read backlog (meeting is over) - yes, thats serious and needs fixing :/10:17
* pstolowski lunch and school run10:30
mupPR snapd#7507 opened: gadget: do not fail the update when old gadget snap is missing bare content <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7507>10:37
zygamvo, pedronis: I updated the forum and created a detailed bug report10:44
pedroniszyga: I commented there, what's the right solution is not super clear to me10:59
pedroniswe need to discuss further10:59
zygapedronis: sure, I only gave a suggestion how this might be addressed but I agree it's something to design more closely as this is a very critical element11:00
cachiomvo, hey11:32
cachioyesterday I was researching a bit an error on the rpi11:32
cachiofor core 18 tests11:32
cachioI see that for arm devices the file /boot/grub/grubenv does not exist11:33
cachioand for amd64 and i386 it exists11:33
cachiodo you know the reason?11:33
ograarm doesnt use grub11:33
ograinstead you should have /boot/ubot11:34
ogra*/boot/uboot11:34
cachioogra, I have it11:34
cachioright11:34
ogra(and everything in snapd should take that into account=11:34
ogra)11:34
cachioso how should I get the env vars?11:34
cachioshould we compile fw_printenv right?11:35
ograon core16 you had the fw_printenv tool pre-installed, but i think mvo decided to drop it in core18 so there is no way except from serial console directly in the bootloader shell11:35
cachioogra, ah, ok11:36
ograwhile you can indeed compile it, there is more to it, as you need a config file in /etc that points to the right addresses the uboot.env lives11:36
ograwe had some setup in core1611:36
cachiowell in this case I'll have to skip this test for arm devices until we define an alternative path for it11:37
cachiothanks ogra11:37
cachiofor the explanation11:37
ogra(and it is massively annoying that fw_printenv/setenv are gone ... since customers need to hack bootloader configs directly in the uboot shell now .... quite a time waster to do all these reboots)11:37
cachioogra, indeed11:38
* Chipaca wanders off in search of sustenance11:43
pedroniscachio: mvo: sounds we might have to consider bringing it back, either in core or snapd11:44
ogra+1 !!11:44
zygapedronis: snap debug boot-env {set,get,unset} ?11:45
zygapedronis: so that snapd code for working with environment is exercised11:45
mupPR snapd#7508 opened: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7508>11:45
pedroniszyga: maybe11:46
zygaperhaps even as direct in snap thing11:46
zygaso that it can be used at all times11:46
zygabut not sure about that11:46
pedronisno, that seems strange11:47
zygayeah, it's better to do it "for real" via snapd11:47
ograwell, for development/porting it is super helpful to have some access from userspace ... wether thats via fw_* or via snap set/get surely doesnt matter ... but having *some* access again would be really helpful11:48
zygayeah, I think that's key11:48
pedroniszyga: I missed what you meant11:50
zygapedronis: that _a_ tool is available11:50
pedronisno, I though with direct, you meant snap boot-env, snap debug boot-env11:51
pedronisnot about skipping snapd11:51
zygaah, sorry, I meant snap <something not top level> boot-env11:51
pedroniseither it's an area that will be in flux soon11:51
pedronisso a bit hard to start on this now11:51
zygayeah11:51
* zyga lunches11:59
Chipacaogra: in https://forum.snapcraft.io/t/partition-layout-for-snappy/656/4712:10
Chipacaogra: i know most of the words, but not in the order you're using them :-p12:10
Chipacaogra: so, what would be a good title for the new topic that started tehre today?12:10
Chipacaogra: so I can split it out as it doesn't seem to be related to the previous one12:10
=== ricab is now known as ricab|lunch
zygaChipaca: consider looking at (wishlist to support another systemd service unit property useful for forking daemons) https://bugs.launchpad.net/snapd/+bug/182233712:15
mupBug #1822337: Support for setting PIDFile for "forking" daemons <snapd:Triaged> <https://launchpad.net/bugs/1822337>12:15
Chipacammm, forks12:15
Chipacazyga: I'd call that a papercut12:16
Chipacazyga: is that what you're asking me?12:16
zygaif that's sensible in your eyes let's tag it and move on12:17
Chipacazyga: yeap12:17
Chipacazyga: once we have ~5 papercuts we can start thinking of keeping it to that number (i.e. doing some of them ourselves in our copious free time)12:17
zygaChipaca: at the 8th day of the week12:18
Chipacazyga: and yes I pulled that number out of ... thin air12:18
zyga;)12:18
Chipacaosvaldo12:18
zygaChipaca: could I also ask you to look at https://bugs.launchpad.net/snapd/+bug/1823768 -- it was reported almost half a year ago and perhaps was fixed since12:20
mupBug #1823768: snap refresh failure during task: Consider re-refresh of snap: snap has "refresh-snap" change in progress <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1823768>12:20
zygayou're assigned to it as well12:20
zygaI've triaged it so I'll leave the rest to you, if you want to update the status please do so12:20
Chipacazyga: that one has not been fixed afaik12:21
pedronisChipaca: I might have fixed it in my remodel work12:22
Chipacapedronis: was about to ask12:22
pedronisbut we never reproduced it12:22
Chipacapedronis: but even when it was reported it wasn't clear how to repro12:22
Chipacayeah12:22
pedronisto be precise I found a place that was buggy in my remodel work and fixed it12:23
pedronisI don't know of any other place12:23
pedronisbut might exist12:23
pedronisthe place was in the alias handling code12:24
pedronisfor an update12:24
pedronismborzecki: #7166 is failing the static tests12:27
mborzeckiduh12:28
mupPR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>12:28
mborzeckilet me see12:28
zygakenvandine: is snap-store bug tracker on lauchpad?12:29
zygakenvandine: can you please reassign this bug as appropriate https://bugs.launchpad.net/snapd/+bug/182416612:30
mborzeckipedronis: interesting, looks like that naked return been there since 04.201812:30
mupBug #1824166: Any snaps without --classic don't have access to the internet on Deepin. <snapd:Invalid> <https://launchpad.net/bugs/1824166>12:30
mupPR snapd#7503 closed: tests: restart the journald service while preparing the test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7503>12:32
zygahmmm, launchpad timeouts are somewhat common12:35
mborzeckimeh, the default config for nakedret used by golangci-lint is to complain if the func is above 30 lines of code, while vanilla nakedred does that for 5+ lines of code12:35
ograChipaca, hmmm which bits exactly do you want to split out ?12:36
pedronismborzecki: what changed? anyway 5+ seems a bit too conservative but no strong opinion there12:36
mborzeckipedronis: i've added some code to the function that nakedret flagged, and it's just above the default threshold of 5 lines when it start to complain12:37
ograChipaca, note that i only pointed to a howto from mvo to install to internal MMC ...12:37
pedronismborzecki: let me look at that function and form an opinion :)12:37
mborzeckihaha12:38
mborzeckibtw. forgot to mention that when we discussed the tooling we use, i'm using https://github.com/golangci/golangci-lint locally to check the code before pushing out12:38
zygaChipaca: https://bugs.launchpad.net/snapd/+bug/1826064 is something you may be interested in as a hobby interest :)12:40
mupBug #1826064: snap command outputs unicode in publisher name even when locale is ascii <cdo-qa> <foundations-engine> <snapd:Confirmed> <https://launchpad.net/bugs/1826064>12:40
Chipacazyga: ikr12:40
Chipacaogra: from shubham's question today down12:41
ograChipaca, well, it is 50% about what i linked to (how to install to internal MMC) and 50% related to ondra's stuff regarding fastboot hackery12:41
ograso i dont think it is in the wrong place12:42
pedronismborzecki: we could bump the default to -l 10 , 30 seems a bit much to me12:42
Chipacaogra: ah, fair enough12:43
pedronisthough12:43
ograChipaca, i.e. you can use tw ways to get stuff to internal MMC ... one is to simply godd the image to the internal device from an SD booted system ... the orther is to jump through a million of hoops and make your image a multi-partition one tat fastboot accepts12:44
pedronismborzecki: a bit your call what you want to do there, either bump or fix12:44
ogra(in case your board has fastboot support in the ROM/first-stage-bootloader)12:44
* ogra notes his typing sucks today :(12:45
mborzeckipedronis: already pushed a fix to use named arguments with return12:45
zygapopey: could I ask you to look at https://bugs.launchpad.net/snapd/+bug/1826470 -- it seems that brave works but only from the command line for some reason, perhaps it's a papercut in the desktop file12:45
pedronismborzecki: ok12:45
mupBug #1826470: Can't launch brave from dock <snapd:Confirmed> <https://launchpad.net/bugs/1826470>12:45
mborzeckiwow, our standup notes are *long* :P12:46
pstolowskimborzecki: we need a second document with only a highlights of the first one ;)12:47
mborzeckipstolowski: should employ some ML to distill the most important bits12:48
cmatsuokaI'm trying to keep it with a civilized level of detail12:48
zygamborzecki: Machine Learning? :D12:48
mborzeckizyga: yup12:48
zygaI try to use a sub-points for details12:48
zygaand main points for highlights12:49
zygathis way you can just briefly read the report without needing to deduce what's detail and what's overview12:49
cmatsuokaafter a few months we can feed it to a markov chain of sorts and have an entirely new set of activities12:51
kenvandinezyga: snap-store is strict, so not sure what I can do from within the confined snap to fix dns resolution12:52
kenvandinezyga: looks like something isn't properly exposed in the sandbox12:52
zygakenvandine: perhaps the issue is fixed now12:54
zygakenvandine: it was classic earlier if I recall correctly12:54
kenvandineIt was briefly published to edge as classic12:56
kenvandineonly for a couple days though, about 18 months ago12:56
kenvandinethis bug report is only a few months old12:57
kenvandinei think the reporter is saying classic snaps work and strict snaps do not12:57
kenvandinevscode can access network, firefox can not12:58
zygaah, perhaps I misread the bug12:58
zygacan you add this to the bug, I'll look at it on the next pass12:58
kenvandinethat is in the bug :)12:58
kenvandinehe explains that firefox can't access the network but vscode can.12:59
kenvandineand he explains that vscode is classic and hints that is why it works12:59
kenvandinei'll comment on the bug though12:59
ijohnsonzyga: quit triaging bugs, it's my day today!12:59
zygaijohnson: I know it's not my day, I kind of missed the schedule because I was partially off yesterday and didn't realize it's Wednesday12:59
Chipacakenvandine: zyga: which bug is this?13:00
* ijohnson accepts zyga's apology in exchange for more polish sweets at next sprint13:00
zygaijohnson: I'll send you the menu ;)13:00
Chipacakenvandine: zyga: please don't say kali13:00
ijohnson:-)13:00
zyga2fa13:00
kenvandineChipaca: bug 182416613:01
kenvandineit's Deepin13:01
mupBug #1824166: Any snaps without --classic don't have access to the internet on Deepin. <snapd:Invalid> <https://launchpad.net/bugs/1824166>13:01
kenvandineI moved it out of invalid until it gets looked at again13:02
Chipacakenvandine: deepin has some kind of issue somewhere13:02
Chipacakenvandine: snaps that need network, or x, don't work right13:02
Chipacaor maybe x is just kali?13:03
Chipacakenvandine: https://forum.snapcraft.io/t/deepin-debian-9-snaps-have-no-internet-connection/11295/7?u=chipaca13:03
Chipacaah, kali was the weird "homes are in /" thing13:06
* Chipaca gets them confused13:06
kenvandinezyga: ok, the theory is confirmed by that forum post.13:08
zygapedronis: can you please enqueue looking at this bug report, it has an observation that may be relevant for your core 20 model design work: https://bugs.launchpad.net/snapd/+bug/183468813:26
mupBug #1834688: connections stanza in gadget.yaml requires snap id <snapd:Confirmed> <https://launchpad.net/bugs/1834688>13:26
cachiomvo, I could reproduce the error running the interfaces-many-core-provided using a vm13:33
cachiohere13:33
cachioI need to re run to start printing more information13:34
cachiodebug information13:34
cachiowhat I saw is that the cpu went to 170% and then it didn't accepted any connection anymore13:35
cachioaccept13:35
mvocachio: cool, thank you!13:37
* zyga breaks for coffee13:38
zygamvo: snapd will have 0 new bugs today :)13:38
zygamvo: the next pass will need to look at snappy13:38
zygamvo: and finally at gardening all open bugs13:38
mvozyga: \o/13:39
zyganot sure who's interested in seeding today but...13:42
zygahttps://bugs.launchpad.net/snapd/+bug/1835795 is something that might impact design of the command that creates the seed structure13:42
mupBug #1835795: seeding a snap with higher assumes than deb pkg of snapd on classic fails <snapd:Confirmed> <https://launchpad.net/bugs/1835795>13:42
zygaping pedronis for architectural consideration, I think you can just read the 1st comment on the bug for a brief summary13:42
=== ricab|lunch is now known as ricab
zygaI think https://bugs.launchpad.net/snapd/+bug/1835805 is something jdstrand should add to his queue for some ideas on how we could design enough changes to unblock using classic snaps like compilers from other classic snaps, like developer IDEs13:44
pedroniszyga: I fear it's medium13:44
mupBug #1835805: strict snap run from classic snap can't write to filesystem <snapd:Triaged> <https://launchpad.net/bugs/1835805>13:44
zygapedronis: please reassign the priority as you see fit13:44
ijohnsonzyga: yay for triaging my bugs13:45
zygaijohnson: thank you for filing nice bugs :)13:45
ijohnsonoh actually that most recent one about strict snap from classic snap is on the forum somewhere, let me update that one too13:45
pedroniszyga: made a comment as well, I don't think it's a seeding time validation problem13:46
zygapedronis: do you think and older snapd should be able to interpret a seed with assumes that it cannot itself satisfying by properly staging the re-execution step?13:47
pedroniszyga: that's even a different problem13:47
pedroniswe are talking assumes here13:47
pedroniswe haven't really changed the seed format in a long while13:47
zygathat's true13:48
zygathat's a separate issue13:48
pedronisat some it becomes a "it hurts then don't do it" sort of situation13:48
pedronisassumes are bound to change quicker than sruing so I understand the concern13:48
zygapedronis: indeed13:49
pedronismy point is mostly I don't think we need an unrealistically general solution13:49
zygapedronis: I think as long as snapd can reexec it could be handled with proper logic in snapd itself13:49
pedronisstill feels medium to me13:49
zygasure, I think that as we do this more often (now) we will get a broader shared understanding of each priority13:49
ijohnsonpedronis, mvo: I'm now blocked waiting on reviews for my snapstate PR's, should I work on reviews today or move on to fixing the socket/timer stuff we discussed in Paris?13:50
pedronisijohnson: you can do a bit reviewing, I'll try to get to some of your PRs today myself13:51
ijohnsonack, thanks!13:51
mupPR snapd#7509 opened: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>13:56
pstolowskipedronis: re debug timings & start-time (what we discussed yesterday). it's slightly annoying: we have start times in timings for some tasks, but it's not guaranteed. some handlers may not implement timings, also sometimes timings are not stored (>5ms threshold). but we still report all tasks of the change (just doing/undoing time, with no nested timing details). so, we can use start-time if available, but otherwise14:13
pstolowskineed to fall back to something else. not sure if it makes sense, may be confusing.14:13
pedronispstolowski: it will be confusing14:22
mupPR snapd#7510 opened: daemon: make /v2/download take snapDownloadOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7510>14:23
mupPR snapd#7286 closed: tests: use images:ubuntu/ in lxd tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7286>14:24
pstolowskipedronis: so i think we need to stick to timestamps already available on Tasks. ReadyTime() ?14:24
pedronispstolowski: no, we need to step back a bit and consider our options14:25
mupPR snapd#7447 closed: snapstate: do not allow removal of the snapd snap <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7447>14:27
roadmrbut I want to use core without snapd 😤14:27
Chipacaroadmr: ?14:29
roadmrj/k Chipaca 😆14:29
ijohnsonroadmr: there's an experimental option in edge that I think you can use now if you wanted to be serious14:29
roadmrijohnson: not really, I mean, how would I even install stuff on a snapd-less core system...14:30
ijohnsonyou'd use the snapd snap and not the core snap!14:30
mupPR snapd#7506 closed: devicestate: add support for gadget->gadget remodel <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7506>14:33
mupPR snapd#7377 closed: patch: add an overlord patch that normalizes channel in state <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7377>14:34
mupPR snapd#7495 closed: [RFC] tests: add gh action for static checks <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7495>14:34
diddledandon't you need the snapd snap installed to be able to install the snapd snap?14:35
diddledanbootstrapping is hard14:35
ijohnsonno first you install the "snap your fingers to turn the lights on" thing from night at the museum, then you snap your fingers and install the snapd snap14:36
diddledandoesn't snapping your fingers make 50% of all living things disappear?14:36
* ijohnson stops snapping fingers14:37
mupPR snapcraft#2729 closed: snaps: if snap is installed, don't check is_valid() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2729>14:37
pedronispstolowski: one option is to return the actual info about what waits for what and do a topological sort (in the client), generally in a lane tasks are sequential so ready time is probably as good as start time. so sortint (min(lanes), ready time) seems ok, except we need to think what to do about lane 0 tasks14:37
pedronisif we go that way14:37
pedronispstolowski: I have a meeting now, do you want to have a chat in ~45 mins or tomorrow?14:54
pstolowskipedronis: later today works for me14:55
pedronispstolowski: ok, I'll ping you14:55
pstolowskipedronis: thanks!14:55
cachiomvo, when it gets stuck I see this https://paste.ubuntu.com/p/CNb5P2Kf7K/14:56
cachiomvo, the problem seems to be with the focker-support interface15:02
zygafocker-support?15:02
zygadid we add a new interface? ;-)15:02
diddledandamn those fockers15:03
zygacachio: can you look at journal  please? anything interesting there15:03
cachiozyga, no I can't15:03
cachiothe machine is dead15:03
cachioI'll run again15:03
cachioand print the journal15:03
zygadiddledan: those fockers were meserszmits15:03
zygacachio: interesting15:03
zygacachio: is it responding to ping?15:03
cachioperhaps doing that I can get nicer information15:03
zygacachio: ping is a good way to check if the kernel is up15:04
zygacachio: but userspace is bonkers15:04
zygacachio: please try that the next time if you can15:04
zygacachio: keep pinging the machine15:04
* diddledan spits some fire15:04
cachiozyga, sure15:04
cachioI'll make another round15:04
zygacachio: once ping stops working it's a good indicator that the kernel went belly up15:04
zygacachio: how do you reproduce this issue roughly?15:05
diddledanor you tripped over the cable15:05
zygaI don't want to jump into it15:05
zygabut I'm curious for tomorrow15:05
zyga   33 root      20   0       0      0      0 S  66.0  0.0   0:09.06 kswapd015:05
cachiozyga, spread2 -repeat 10 -show-output external:ubuntu-core-16-64:tests/main/interfaces-many-core-provided15:05
zygathis feels like OMG MEMORY15:05
zygaKiB Swap:        0 total,        0 free,        0 used.    15462 avail Mem15:05
zygaand in fact, we have no swap15:05
diddledanwho needs swap?!15:05
cachiowith core 16 image from beta15:05
zygacachio: can I ask you to run another command in a separate connection15:06
cachiozyga, yes15:06
zygacachio: run slabtop15:06
zygain case it is memory15:06
cachiozyga, sure15:07
zygacachio: external, is the target a physical machine?15:07
zygacachio: or kvm?15:07
cachiokvm15:07
cachiorunning in my laptop15:08
zygacachio: perhaps log in as root15:09
zygacachio: on the console15:09
zyga(if you have one)15:09
cachioyes15:09
cachioI do that15:09
ograwiggle the cable !!15:09
cachiozyga, running15:12
cachiozyga, I am having lunch and then I'll show you the output15:12
zygathanks15:12
cachiozyga, to you15:12
zygaI may be away but I'll happily look tomorrow15:13
cachiozyga, sure15:13
cachioI'll continue researching this one15:13
cachiozyga, thanks for the support15:13
zygaI'm very curious to see what this will uncover15:13
pedronispstolowski: my meeting was quicker than usual, let me know when you can chat15:17
* cachio lunch15:17
zygamvo: hey, a quick question about https://bugs.launchpad.net/snapd/+bug/1840375 -- is it the case that we can now pass --extrausers to groupdel?15:19
mupBug #1840375: groupdel doesn't support extrausers <verification-needed> <verification-needed-bionic> <verification-needed-disco> <verification-needed-xenial> <snapd:Triaged by mvo> <shadow (Ubuntu):Fix Released by mvo> <shadow (Ubuntu Xenial):Fix Committed> <shadow (Ubuntu Bionic):Fix Committed>15:19
mup<shadow (Ubuntu Disco):Fix Committed> <https://launchpad.net/bugs/1840375>15:19
pstolowskipedronis: ok, i'm ready15:19
pedronispstolowski: going to the standup15:20
ograzyga, looks like the SRU isnt finished15:22
ogra(so you could ... but only in "eoan core")15:23
zygaah, I didn't notice the "green" is fix commited15:26
zygaoh well15:26
mvozyga: yes, iirc I added this to groupdel, let me double check15:29
mvozyga: https://launchpad.net/ubuntu/+source/shadow/1:4.2-3.1ubuntu5.515:30
zygamvo: so is the bug fix committed now?15:30
zygamvo: actually, can you just update the bug as you see fit15:30
mvozyga: its in -proposed15:31
mvozyga: in a meeting15:31
zygasure15:31
mupPR snapcraft#2730 opened: tests: update rust-toolchain test so it pulls from beta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2730>15:46
* ijohnson takes a break16:03
mupBug #1606539 changed: handle errors from `snap create-user` gracefully <snapd:Triaged> <https://launchpad.net/bugs/1606539>16:05
mupBug #1609864 changed: Enable a command to be run on machine shutdown <cpc> <snapd:Triaged> <https://launchpad.net/bugs/1609864>16:05
mupBug #1633141 changed: gadget.yaml should specify disk/volume image sizing behavior <snapd:Triaged by maciek-borzecki> <Ubuntu Image:New> <https://launchpad.net/bugs/1633141>16:05
pedronismvo: I made a suggestion in #7348 , let me know what you think when you get to it16:05
mupPR #7348: snapstate,store: check assumes early before downloading the snap <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>16:05
mupBug #1620592 changed: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <snapd:Triaged> <https://launchpad.net/bugs/1620592>16:08
mupBug #1621666 changed: It is possible to install the classic snap in a classic system <classic> <snapd:Confirmed> <https://launchpad.net/bugs/1621666>16:11
Chipacawho works on microk8s?16:12
Chipacapopey: do you know, offhand?16:12
ograChipaca, there is an upstream bug for the issue linked inside the topic16:13
ograupstream sent him over to the forum16:13
popeyhttps://github.com/ubuntu/microk8s/graphs/contributors16:13
Chipacaah ok16:13
Chipacapopey, ogra, thanks16:13
ograand there is no logical reason that this happens at all !!16:13
popeylogic... lulz16:13
ograneither is it reproducable16:13
ogra(i mean not reproducable for any of us but fully reproducable for that user)16:14
mvopedronis: thank you, I check it out16:17
* Chipaca puts on his running shoes16:19
* zyga EODs16:25
pedronisChipaca: I did a pass on #732016:26
mupPR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>16:26
Chipacapedronis: thank you16:26
=== pstolowski is now known as pstolowski|afk
ograoh, wow ... another missing symlink issue !16:31
Chipacainternet is needed to catch the etherbunny16:33
ChipacaI'm soft-EODing and going for a run16:34
Chipacashould be back in under an hour to poke at this a bit more16:34
ograwell, i bet the reinstall will just fix it16:35
popeyof the snap or the whole machine?16:35
popeyalso "fix" :)16:35
ograof snapd16:35
popeyrefreshing core or installing the snapd should trigger that?16:36
ograwell, he said core was pre-installed16:36
popeyno, i mean, refreshing rather than uninstall/reinstall16:36
ogramy guess is something went wrong with initial seeding or so16:37
ograah16:37
popeyplusible16:37
popeycould we add some checks at startup, that if a snap is marked installed, it must have a current directory?16:37
ograwell, john already asked him to purge/reinstall ... i guess it is to late to check if refresh would have helped16:37
Chipacayeah, seed.yaml busted is a safe bet16:38
Chipacahopefully we can find the image and get it fixed16:38
Chipacaanyway! run run run run16:38
* Chipaca disappears in a cloud of sweat16:38
* ogra sprays some deodorant around16:39
cachioslabtop : https://paste.ubuntu.com/p/NTS4DCWKmG/16:56
cachiozyga,16:56
mupPR snapcraft#2730 closed: tests: update rust-toolchain test so it pulls from beta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2730>17:28
mupIssue classic-snap#33 opened: It is possible to install the classic snap in a classic system <Created by anonymouse64> <https://github.com/snapcore/classic-snap/issue/33>18:44
mupPR snapd#7511 opened: tests: when the backend is external skip the loop waiting for snap version <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7511>18:55
cachiozyga, I updated the standup doc with the details about the issue19:08
cachiozyga, the problem is related to memory19:08
cachiosee you19:08
mupBug #1626082 changed: Fedora 24 install fail with snapd 2.14 <snapd:Fix Released> <https://launchpad.net/bugs/1626082>19:48
mupBug #1627860 changed: run fail at missing folder /lib/modules (eg. on a virtual host) <snapd:Fix Released> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1627860>19:48
mupBug #1639798 changed: enable gpio interface for rpi2/3 (and other boards if suited) <gadget> <Snappy:Fix Released> <https://launchpad.net/bugs/1639798>19:51
mupBug #1639952 changed: When running in unity8 desktop snap, snap application icons aren't found in app scope <personal> <Canonical System Image:Fix Committed by pat-mcgowan> <Snapcraft:Confirmed> <snapd:New> <ubuntu-app-launch (Ubuntu):Fix Released> <https://launchpad.net/bugs/1639952>19:51
mupBug #1649399 changed: 'daemon: dbus' is incomplete <snap-docs> <snapd:New> <https://launchpad.net/bugs/1649399>19:57
mupBug #1655834 changed: Support factory reset <snapd:In Progress> <https://launchpad.net/bugs/1655834>19:57
mupBug #1630976 changed: Incomplete home directory mapping <snapd:Confirmed> <https://launchpad.net/bugs/1630976>20:00
mupBug #1625817 changed: Document snap prepare-image options <snapd:Fix Released> <https://launchpad.net/bugs/1625817>20:04
mupBug #1635101 changed: /snap/bin is not added to path for "sudo su" <snapd:Confirmed> <https://launchpad.net/bugs/1635101>20:10
mupBug #1637934 changed: update install hook documentation <snapd:New> <https://launchpad.net/bugs/1637934>20:16
mupPR snapd#7512 opened: Misc updates for strict k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7512>20:47
mupPR snapd#7513 opened: interfaces/docker-support,kubernetes-support: misc updates for strict k8s - 2.42 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7513>20:49
* cachio EOD20:59
mupPR snapcraft#2731 opened: meta: take no command-chain being prepended into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2731>21:11
mupPR snapcraft#2727 closed: storeapi: use the channels attribute in push <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2727>21:20

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