mupPR snapcraft#3314 closed: schema: add missing name item in package-repositories <Created by jc-lab> <Closed by jc-lab> <https://github.com/snapcore/snapcraft/pull/3314>01:15
mborzeckimvo: hey06:03
mvogood morning mborzecki06:08
mborzeckimvo: do you recall vfat corruption when we got uboot.env and UBOOT.ENV in the same fs?06:22
mborzeckimvo: do you have any tooling to corrupt the vfat from that investigation? i was able to find https://gist.github.com/bboozzoo/e68254507eef4673dd8c6f9b82f65d92 with the hope it can used in #949906:23
mupPR #9499: tests: add tests for fsck <Created by zyga> <https://github.com/snapcore/snapd/pull/9499>06:23
mvomborzecki: I found some go libraries to directly access fat that can probably be used for this06:31
mvomborzecki: let me look at your stuff06:31
mborzeckimvo: fatcat?06:31
mborzeckimvo: i have a vague recollection we tried to do something with https://github.com/Gregwar/fatcat/06:32
mvomborzecki: I don't remember exactly, let me try to look06:32
mvomborzecki: https://github.com/mvo5/go-fs06:35
mborzeckimvo: interesting, thanks!06:36
mvomborzecki: if you want fat32 and lfn support you will need my version but it does not do much, maybe it's actually not that great06:38
zygagood morning06:39
zygamvo: hey!06:39
mvogood morning zyga06:39
mborzeckimvo: i was thinking that maybe we could break one of the entries, or a superblock06:39
mvomborzecki: +106:39
mborzeckizyga: morning, left some comments in 949906:39
zygaI'm looking at those now06:40
zygait was late so maybe a typo crept in?06:40
mvomborzecki: we could experiment with corrupting a cluster too, up to you, I follow with popcorn from the sideline :)06:40
zygaI'll check the offsets first06:41
zygamborzecki: I replied06:41
zygaI really think it's a separate test06:42
zygaand I think the core16 / core18 situation is unclear, for the reason I outlined in my own comments06:42
zygaso I'll start by expanding that test not to rely on early-boot kernel messages06:42
zygamborzecki: still, we don't fsck on core20 so ... bummer06:42
zygaI suspect we have to explicitly at the level we are at now06:42
mborzeckizyga: yeah, i recall ian mentioning something about fsck when he worked on snap-bootstrap06:43
zygamborzecki: the good thing is - we know :)06:43
zygathe bad thing is, it's not good :)06:43
zygamborzecki: separately I think we should consider re-mouting vfat as read only06:45
zygaubuntu-seed is writable and we mount snaps from there06:45
zygait's just waiting to corrupt and die06:45
zygawe could really keep it read only for most of the runtime of a device06:45
zygaand only remount to writable when we need to perform a specific operation06:45
zygaread-only fat doesn't corrupt on power loss06:45
mborzeckizyga: yeah, it was raised for uc2006:47
zygammm, good06:56
zygatoday is a weird day, no school for kids, wife sick and back from work06:56
zygafeels like back to quarantine06:56
pstolowskizyga: hey, i think we forgot to mount boot back after fsck yesterday, that's why core18 failed to refresh :)07:00
zygapstolowski: hmmm, could be but I don't recall07:01
zygapstolowski: we can look at that again07:01
pstolowskiyes i just checked07:01
zygapstolowski: maybe at ... 9:30?07:01
zygaI need to move back to the office and grab coffee (still upstairs in the kitchen)07:01
pstolowskithat's also an interesting material for spread test07:01
zygapstolowski: unmounted boot?07:01
amurrayzyga: hey so I tried your approach but I am not having much success (I think I am not using the right path for the core snap or perhaps am missing something else) - is this about what you had in mind? https://pastebin.ubuntu.com/p/2FXrMhN2Ck/07:01
pstolowskizyga: yes, but just to provoke failure of refresh07:01
zygapstolowski: indeed07:02
zygaamurray: hey!07:02
zygaamurray: looking07:02
zygaamurray: it looks semi okay, I think the current symlink may be a problem, we code defensively and we avoid mounting over symlinks07:03
zygawhat happens in your case?07:03
amurrayzyga: this results in the following: https://pastebin.ubuntu.com/p/mf8fGRW6dr/ so I think it is on the right track07:03
zygathat definitely looks good07:03
amurrayahh current symlink... do you know how I could know what the actual path would be then to the core snap?07:03
amurray*or should I say whatever the base snap would be?07:04
zygaamurray: this _may_ be a little more complex, I came to realize, because we cannot easily capture the base revision07:04
zygaamurray: so without checking I suspect this is good on paper but breaks because snap-update-ns doesn't want to mount with a source /snap/core/current07:04
zygabut it also shows a deeper problem, that now the snap has an explicit relationship to the base snap07:05
zygaamurray: so when the base revision changes, ... what then?07:05
zygaamurray: normally we have some logic to re-create the mount namespace in that case07:05
amurrayzyga: also do you know how I can debug what snap-update-ns is doing...?07:05
amurrayah right.. so on base refresh...07:05
zygaamurray: yes, export SNAP_DEBUG or SNAPD_DEBUG and run it by hand07:05
zygayou can actually do something simpler07:05
zygajust set SNAP_CONFINE_DEBUG=1 and snap run --shell docker07:06
zygathis will give you a lot of details07:06
zygait's a bit complex07:06
zygabecause those snaps have services07:06
zygait may be better to start with a fake-docker snap that just has the interface07:06
zygaconnect it07:06
zygaand then see what happens07:06
zygaotherwise the mount namespace is created by the service app they contain07:06
zygaand you don't see everything07:06
zygaby using a new fake snap you can run it by hand with more exact control07:07
zygaamurray: my advice is to see exactly what happens in snap-update-ns first07:07
zygaamurray: and then consider two options:07:07
zygaamurray: special-case /snap/$name/current as source and de-reference that in snap-update-ns07:08
zygaamurray: explicitly teach snap-update-ns about $BASE_SNAP_NAME $BASE_SNAP_REVISION07:08
zyga(those variables are made up)07:08
zygasnap-update-ns could expand those variables and we could use those variables in the mount profile07:08
zygathen we don't need to special case a path07:08
zygaand the feature may be useful for other things07:09
zygaamurray: how does that sound?07:09
amurrayit sounds a lot harder than the snap-confine approach... but if it is the better solution then I'll keep plugging away at it - you said 'see exactly what happens in snap-update-ns' - I am still not sure how to see that.. .I tried running snapd manually with SNAP_DEBUG etc but it didn't seem to show anything relevant07:11
zygaamurray: don't run snapd with debug07:12
zygaamurray: run snap run with debug07:12
zygasnap run invokes snap-confine which invokes snap-update-ns07:12
zygaif you enable debug there you will see that07:12
zygaone sec07:13
amurrayhmm https://pastebin.ubuntu.com/p/mDGTJp7GCH/ - I think the 'DEBUG: joined preserved mount namespace docker' means it is not showing what is actually happening07:14
zygaamurray: zyga@x240:~$ SNAPD_DEBUG=yes snap run gimp07:14
zygaamurray: exactly, because the service has constructed the mount namespace and you are not seeing that anymore07:14
zygaamurray: you can work around that without a new snap though07:14
zygaamurray: just stop all docker services07:14
zygaamurray: discard the mount namespace with sudo /usr/lib/snapd/snap-discard-ns docker07:14
zygaand then run07:15
zygaSNAPD_DEBUG=yes snap run --shell docker07:15
zygathat will give you the full output07:15
zygaamurray: snap-confine-based approach is possible too but it would be coarse and unable to handle interfaces07:15
zygaI'd prefer to avoid that07:15
zygaand it's a step in the wrong direction in a way, as we want to avoid sharing /etc over time, and have less rigid set of mounts there07:16
amurrayyep that did it (snap-discard-ns) - https://pastebin.ubuntu.com/p/Nx3C4VgCPt/ - ok I gotta run to pick up my daughter but will check back with you later tonight - thanks again for your help :)07:17
zygaamurray: ack07:19
* zyga improved the fsck test and is running it to see if core16 really fscks or not07:23
zygamborzecki: I need a review for https://github.com/snapcore/snapd/pull/944607:23
mupPR #9446: overlord,usersession: initial notifications of pending refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/9446>07:23
zygamvo: ^ and perhaps you since ian is off this week?07:23
zygamborzecki:     - google:fedora-31-64:tests/main/sudo-env is that due to sudo changes in fedora?07:24
zyga    - google:arch-linux-64:tests/main/snapshot-cross-revno failed on unrelated pr07:25
zygapstolowski: ok, I'll set what I'm doing aside and prep for our session07:26
mvozyga: yes, it's on my list but I suck and have not managed to get to it :/ need to do the 360 and an interview prep and then will hpoefully get to it07:26
mvozyga: I really want this to land asap07:26
mborzeckizyga: yes, most likely due to sudo changes07:29
mborzeckizyga: i'll open a PR with the fix07:29
zygamborzecki: superb07:29
zygapstolowski: give ma 3 minutes07:29
zygapstolowski: just warming stuff up07:33
zygapstolowski: do you have the session?07:33
pstolowskizyga: i've now07:34
zygamvo: drat, we don't fsck on core16 or core1807:45
zygathe test is now improved and fails everywhere07:45
zygaso .. well :)07:45
mborzeckizyga: w8, what?07:46
mborzeckiaah, core16 and core18 don't use systemd in initrd, so fsck is not automagic07:47
zygamborzecki: yep07:47
zygamborzecki: I have a test07:47
pstolowskirogpeppe: hi07:49
zygamborzecki: the previous test was flawed because core16 and core18 did not have systemd forwarding messages from early boot07:49
zygaanyway, I'll push the test07:50
rogpeppepstolowski: hello!07:50
pstolowskirogpeppe: hey, we have mounted /boot back and managed to refresh core18 and everything looked ok, but unfortunately after reboot it didn't come back, cannot ssh anymore :(07:51
rogpeppepstolowski: ok, i'll ask it to be power-cycled07:51
pstolowskirogpeppe: looks like we need a manual restart of your pi307:51
rogpeppepstolowski: that's what always happens, unfortunately07:52
zygamborzecki: pushede07:52
rogpeppepstolowski: which is a bit of a shame, because it makes the whole thing somewhat unreliable07:52
pstolowskirogpeppe: yeah, no denying, hopefully we will get to the bottom of this07:52
zygarogpeppe: please let us know when you can power cycle it, we will try to understand what's going on07:53
rogpeppepstolowski: i suspect that snappy will sometimes try to reboot itself to update system s/w, and this causes the machine to go down07:53
zygamborzecki: please look at my logic in https://github.com/snapcore/snapd/pull/949907:53
mupPR #9499: tests: add tests for fsck <Created by zyga> <https://github.com/snapcore/snapd/pull/9499>07:53
zygamborzecki: I really would like to know if we fsck07:54
zygaand the test is wrong07:54
zygaor if we just don't fsck07:54
zygaand the test is sadly right07:54
zygarogpeppe: pstolowski and me will resume debugging once you give us a note that the power cycle occurred07:57
rogpeppezyga: should happen in the next 5 minutes or so; i'll let you know08:00
zygarogpeppe: great, thank you08:00
mupPR snapd#9500 opened: tests/main/sudo-env: snap bin is avaialble on Fedora <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9500>08:03
mborzeckizyga: ^^08:03
rogpeppezyga, pstolowski: ok, it's back up now. it took two power-cycles as usual.08:08
zygarogpeppe: thank you08:08
zygatwo? as in yank cable twice?08:08
zygapstolowski: can you connect?08:09
pstolowskizyga: yes, i can08:10
zygapstolowski: ok, let's examine the boot partition again08:10
zygaand maybe snap changes08:10
zygaand journal?08:10
zygashall we get back to the HO?08:10
pstolowskizyga: yes, give me 508:11
pstolowskiok rdy08:15
zygawe were just talking with pawel that maybe the second reboot is because we fail to do the initial reboot at all08:18
mborzeckimvo: per monday's discussion i've updated https://github.com/snapcore/snapd/pull/9420 to use 384MB for UC2008:19
mupPR #9420: tests/nested/manual/minimal-smoke: use 384MB of RAM for nested UC20 <Run nested> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9420>08:19
mvomborzecki: thanks! (in a meeting)08:31
zygarogpeppe: does the device reboot correctly if you just "sudo reboot"?08:33
zygarogpeppe: or is it also going into this weird state that requires more than one reboot to complete?08:33
rogpeppezyga: i don't know... i'd presume not, otherwise it wouldn't have gone down last night08:34
rogpeppezyga: shall we try?08:34
zygawe're still coming up with options, we may decide to try that to learn more08:34
zygawe'll let you know for sure08:34
rogpeppezyga: ta08:34
zygarogpeppe: no chance of a serial log? :D08:35
rogpeppezyga: nope, i'm afraid not. i've never worked out how to get serial output from the pi.08:36
rogpeppezyga: don't you have to solder something onto the board or something like that?08:37
zygarogpeppe: no, just a pair of wires and a computer with usb port to capture the log08:40
rogpeppezyga: presumably you need some kind of connector for the wires, and a serial port adaptor08:41
rogpeppezyga: not sure my dad has either of those things around currently (actually, he _may_ have a serial port adaptor, but i'm not sure i want to get him to do all this remotely :) )08:42
zygarogpeppe: yeah, those are super common on ebay and amazon and go for a few pounds08:42
zygaI was more of a joking, it'd be ideal for debugging08:42
zygawe're eliminating possibilities08:42
rogpeppezyga: yeah, i've thought that before, but thought it would be too much hassle08:43
zygarogpeppe: ok, we'd like to reboot the device without any changes08:51
zygawe have some ideas but we'd be much faster if we can do some reboots08:51
zygawithout going through refresh08:51
zygarogpeppe: is it okay if we reboot the device now?08:51
rogpeppezyga: please do08:51
rogpeppezyga: let me know if you need it power-cycling again08:52
rogpeppezyga: although i'm in a meeting in 8 minutes08:52
zygawe are back08:53
zygathank you!08:53
zygarogpeppe: it rebooted successfully09:00
rogpeppezyga: yay!09:00
mborzeckiquick errand, brb09:01
mvozyga: \o/ you rock!09:42
zygamvo: we're not done, it's not over yet09:42
zygaand it's pawel and maciek :)09:42
* mvo hugs mborzecki and pstolowski 09:57
pstolowskimvo: yeah it just survived manual reboot, but not reboot after refresh; we're seeing 'rollback across reboot'09:57
mvoquick question: do we have an example gadget with cloud init configuration?10:17
* zyga doesn't remember one10:18
mvothat's fine, I will just create one I think10:18
zyga-mbpnot a good store day10:21
zygarogpeppe: we did lots of analysis but ultimately reboot just failed11:13
zygarogpeppe: if you can power cycle (once for now), that would be great11:14
rogpeppezyga: ok :\11:14
zygalet us know when ready11:14
zyga-mbprogpeppe: so, it would be amazing if you could eventually get this11:18
zyga-mbprogpeppe: let us know when the 1st power-cycle had occurred11:19
zyga-mbpif you already did that you can go ahead with the second one (2nd power cycle)11:19
zyga-mbp1st power cycle did not (as expected, though unclear why) recover the device11:19
zygaogra: do you have the permission to download pi-kernel revno 44?11:22
zyga-mbpmvo: do you have access to core18 snap?11:45
zyga-mbpI could use revision 1076 with assertions11:45
zyga-mbpsimilarly to pi-kernel at revision 4411:45
zyga-mbpand pi gadget revision 1711:45
ograzyga-mbp, let me try ...11:59
zyga-mbpthank you!11:59
ogra$ snap download --revision=44 pi-kernel12:00
ograFetching snap "pi-kernel"12:00
ograerror: cannot download snap "pi-kernel": Access by specifying a revision is not allowed for this Snap.12:00
zyga-mbpoh well12:00
ograi fear only the kernel team can ...12:00
ogra(i can download the current revision for each track/channel but not specify --revision)12:01
zyga-mbpyeah, same here12:01
ograalso 44 is pretty old .. we're at 200 currently12:02
zyga-mbpI know, we are trying to reproduce a peculiar failure12:02
ogra(for armhf that is)12:02
mborzeckicmatsuoka: hi, can you take a look at https://github.com/snapcore/snapd/pull/9474 ? it's been +1'ed by pedronis12:27
mupPR #9474: boot, overlord/devicestate: list trusted and managed assets upfront <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9474>12:27
cmatsuokamborzecki: already looking, was about to +1 it12:28
mborzeckicmatsuoka: cool thanks!12:29
mborzeckicmatsuoka: fwiw https://github.com/snapcore/snapd/pull/9443 could use your review too :)12:29
mupPR #9443: gadget, gadget/install: support for ubuntu-save, create one during install if needed <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9443>12:29
cmatsuokamborzecki: ah yes, I started reviewing it a few days ago and didn't finish it, resuming now12:36
mborzeckicmatsuoka: thank you12:44
cmatsuokamborzecki: done12:53
mborzeckicmatsuoka: yay, now if only testing was green12:54
jibelHi, I cannot launch any snap on groovy. When I launch a command from the terminal, it waits for a moment then I get this error:12:55
jibel$ matterhorn12:55
jibelcannot stat /var/lib/snapd/seccomp/bpf/snap.matterhorn.matterhorn.bin: No such file or directory12:55
jibelis there a knows issue?12:56
jibel$ snap version12:56
jibelsnap    2.47.1+20.1012:56
jibelsnapd   2.47.1+20.1012:56
jibelseries  1612:56
jibelubuntu  20.1012:56
jibelkernel  5.8.0-22-generic12:56
zyga-mbpjibel hi12:58
zyga-mbpI assume the referenced file does not exist12:58
zyga-mbpcan you run snap list without failure?12:58
jibelno failure12:59
mborzeckijibel: yeah, can you also do `ls -l /var/lib/snap/seccomp/bpf` ?12:59
zyga-mbpand if you run "snap changes" do you see any errors?12:59
jibeland the snaps I cannot launc hare listed12:59
jibel65   Error   today at 13:04 CEST  today at 13:06 CEST  Auto-refresh snaps "snapd"13:00
jibeland the error13:00
jibel2020-10-14T13:04:37+02:00 ERROR cannot compile /var/lib/snapd/seccomp/bpf/snap.dl-ubuntu-test-iso.dl-ubuntu-test-iso.src: fork/exec /snap/snapd/8790/usr/lib/snapd/snap-seccomp: no such file or directory13:00
jibellog of change 65 https://paste.ubuntu.com/p/MKWRHhZpX4/13:01
jibelupgrade of snapd didnt go well apparently13:01
mvozyga-mbp: I can give you core18 r1076 - give me 1min13:02
zyga-mbpmvo thank you13:02
zyga-mbpjibel we have a standup call now13:02
zyga-mbpI'll get back to you after that13:02
jibelzyga-mbp, for some reason auto-refresh of snapd failed, I re-refreshed snapd manually and it fixed $world13:05
zyga-mbpjibel could you look for system logs from that moment13:08
zyga-mbpperhaps there are clues there?13:08
jibelhere it is https://paste.ubuntu.com/p/ZSRcqbsVCM/13:19
zyga-mbpjibel thank you13:28
zyga-mbpjibel very interesting13:28
zyga-mbpjibel let me read the log quickly13:38
zyga-mbpjibel can you ls -ld /snap/snapd/8790/usr/lib/snapd/snap-seccomp13:38
zyga-mbpand report a bug with this log, snap changes and snap tasks NNN where NNN is the change that failed13:38
zyga-mbpI need to get my dog to the vet in a moment and I don't want to lose a chance to see the state your system was in right now13:38
zyga-mbpjibel: ^13:40
jibelzyga-mbp, version 8790 has been removed from the system, I've only 9279 and 960713:40
zyga-mbpthat explains a lot13:40
zyga-mbpthank you!13:40
jibel$ ls -ld /snap/snapd/*/usr/lib/snapd/snap-seccomp13:40
zyga-mbpso snap changes13:40
jibel-rwxr-xr-x 1 root root 2306928 sept.  4 18:33 /snap/snapd/9279/usr/lib/snapd/snap-seccomp13:41
jibel-rwxr-xr-x 1 root root 2306928 sept. 30 06:59 /snap/snapd/9607/usr/lib/snapd/snap-seccomp13:41
jibel-rwxr-xr-x 1 root root 2306928 sept. 30 06:59 /snap/snapd/current/usr/lib/snapd/snap-seccomp13:41
zyga-mbpand snap tasks for the last few changes that happened13:41
zyga-mbpI really need to go now13:41
jibelI'll report a bug13:41
zyga-mbpmborzecki, pstolowski: ^ perhaps something you can pick up to the extent that the relevant data is collected in a bug13:41
* zyga-mbp goes 13:43
mborzeckijibel: can you find the pid of `snapd` and then run `sudo ls -l /proc/<pid>/exe` ?13:46
cachiomvo, could you find the error for sbuild?13:47
mborzeckicachio: got log of that failure?13:51
cachiomborzecki, which failure?13:51
cachiothe sbuild on?13:52
mborzeckicachio: yes, the sbuild one13:52
cachiomborzecki, https://paste.ubuntu.com/p/f9MJNgc6r9/13:53
jibelmborzecki, lrwxrwxrwx 1 root root 0 oct.  14 15:02 /proc/70906/exe -> /usr/lib/snapd/snapd13:54
jibelmborzecki, zyga-mbp bug 189979413:54
mupBug #1899794: snapd error during refresh <snapd (Ubuntu):New> <https://launchpad.net/bugs/1899794>13:54
mborzeckijibel: can you attach the output of journalctl -u snapd.failure.service too?13:58
mborzeckijibel: thanks, this looks very interesting, can you also grab the output of `journalctl -u snapd.service` from before oct 12?14:03
mborzeckijibel: looks like something happend on oct 12 ~7:03 and the failure handler got started, so maybe a complete log of the snapd.service would be even better14:05
jibelmborzecki, attached14:09
mborzeckijibel: thanks14:09
jibelI'm wondering if it could be related to bug 1871538 where systemd brings the entire session down14:09
mupBug #1871538: dbus timeout-ed during an upgrade, taking services down including gdm <amd64> <apport-bug> <champagne> <focal> <id-5e988df7fb344884f67bc04f> <rls-ff-incoming> <systemd:New> <accountsservice (Ubuntu):Invalid> <dbus (Ubuntu):Incomplete> <gnome-shell (Ubuntu):Invalid> <accountsservice14:09
mup(Ubuntu Focal):Invalid> <dbus (Ubuntu Focal):Incomplete> <gnome-shell (Ubuntu Focal):Invalid> <https://launchpad.net/bugs/1871538>14:09
mborzeckijibel: not sure, looks like there were 2 instances of snapd service running one point14:17
mborzeckijibel: was there a package update sometime ~7:00 on oct 12?14:30
jibelmborzecki, yes among other there was snapd:amd64 (2.46.1+20.10, 2.47.1+20.10)14:32
mborzeckijibel: around that time?14:32
jibelfrom 07:01:25 to 07:03:5314:33
mborzeckijibel: cool, thanks14:33
mborzeckijibel: ok, added more comments to the bug, a nice one14:44
mborzeckimvo: pedronis: i've added some comments to https://bugs.launchpad.net/snapd/+bug/1899794 looks like a real problem14:45
mupBug #1899794: Error during refresh of snapd leads to unusable system <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1899794>14:45
jibelmborzecki, ta14:49
pedronismvo: I did a pass in #946915:23
mupPR #9469: snapshots: import of a snapshot set <Created by mvo5> <https://github.com/snapcore/snapd/pull/9469>15:23
pedronismborzecki: thx, snap-failure /revert logic needs improvements15:25
mvopedronis: awesome, thank you!15:35
cachio /me lunch15:36
* cachio lunch15:36
mupPR snapd#9501 opened: [RFC] wrappers: do not error out on read-only /etc/dbus-1/session.d filesystem on core18 <Created by stolowski> <https://github.com/snapcore/snapd/pull/9501>16:30
mvocachio: I did not even look at the sbiuld error, so sorry! had meeting, an interview and 36017:31
cachiomvo, np, I'll take a look17:32
cachiomvo, is it failing to build https://paste.ubuntu.com/p/hdxvkmrRVG/17:33
cachiomvo, is it any way to show more info about what failed?17:33
mvocachio: yeah, the error as is is really not helpful17:34
mvocachio: there should be maybe a sbuild.log with more info?17:34
cachiomvo, nice, thanks17:34
mvocachio: if you don't find anything, please remind me tomorrow, my day should be a bit less crazy tomorrow :)17:50
cachiomvo, sure, thanks!17:50
zygasorry, this was a long visit17:53
zygaI'll grab some food and do reviews for cachio17:53
zygaand then try to install the kernel and core mvo shared17:53
mvozyga \o/18:03
mvopedronis: I addressed the snapshot import feedback, will ask pawel tomorrow18:13
mvopedronis: for a second review18:13
mvopedronis: will call it a day now18:13
mupPR snapcraft#3317 opened: plugin handler: properly handle snapcraftctl errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3317>18:23
* cachio -> kinesiologist18:46
* zyga picks up zyga:tweak/ignore-running aka https://github.com/snapcore/snapd/pull/940619:38
mupPR #9406: many: allow ignoring running apps for specific request <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9406>19:38
mupPR snapcraft#3318 opened: plugin handler: set -x for scriptlets <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3318>19:53
mupPR snapd#9502 opened: tests: more output for sbuild test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9502>20:36
* zyga made some progress and calls it a day20:39
zygaok one more patch20:49
zygapushed some tests to https://github.com/snapcore/snapd/pull/940620:49
mupPR #9406: many: allow ignoring running apps for specific request <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9406>20:49
mupPR snapcraft#3319 opened: [RFC] plugin handler: use bash with additional error checking for core20 scripts <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3319>21:03
mupPR snapd#9503 opened: tests: use tests.backup tool <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9503>21:31

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