[06:55] Hello [07:02] :) [07:02] man it's all snowy white today :) [07:15] morning [07:15] hey mborzecki, mvo [07:16] I almost typed "hey mup", but we don't greet mup :/ [07:16] hey zyga [07:17] mvo: zyga: hey [07:17] hey mborzecki [07:23] 61 PRs [07:26] PR snapd#6429 opened: Bboozzoo/section rename 2.37 [07:26] mvo: ^^ need this for 2.37 branch too [07:27] I will do some reviews today [07:32] hi mvo, zyga [07:35] hey jamesh [07:35] mborzecki: ok, I have a look and will cherry-pick [07:35] mvo: opened a PR to 2.37 [07:35] mborzecki: I also need to cherry-pick the find fix [07:36] mvo: but feel free to close if you prefer to cherry-pick and push manually :) [07:37] mborzecki: yeah, did cherry pick some minutes ago, but still thanks for noticing [07:38] PR snapd#6429 closed: tests/searching: handle renamed video section [07:48] hey jamesh [08:40] PR snapd#6348 closed: snap: split alignment calculation and display for channels <⛔ Blocked> [08:51] Chipaca: pedronis: updated #6016 [08:51] PR #6016: [RFC] move various name validation helpers to snap/name package [08:55] mborzecki: oh no! now what do I do with my "z" snap? [08:56] Chipaca: you make it go zzz [08:56] about half of my registered names are answers to "i wonder if the whole stack catches me trying to register this name we decided was invalid" [08:56] (hint: mmmmmmaybe?) [08:58] Chipaca: btw. we allow 2 letter names right? :P plenty of combinations [09:00] Chipaca: pushing a little tweak, dropped *Name suffix where it seemed a bit sueprfluous given that the package is called 'naming' [09:00] hmm [09:00] * Chipaca looks [09:00] yes that works [09:01] mvo: where do you want to have the meeting? IRC, hangouts, something else? [09:02] jamesh: meet should be ok, I sent you an invite [09:02] jamesh: sorry that it was not on the original thing [09:38] mborzecki: hi, Q for you in 6016 [09:39] pedronis: right, i tried to keep the diff size under control, so introducing the package and indirection felt right as a first step [09:39] pedronis: with removing the store info cache (btw any better names appreciated) from being tasks, I'm moving them out of backend and into snapstate itself (like seq is already), ok? [09:40] Chipaca: it's fine out backend [09:40] mborzecki: can you work on a follow up to remove the indirection ones when you havea bit of time [09:40] pedronis: should I read that as "it's fine not in backend"? [09:41] Chipaca: yes [09:41] pedronis: ok :-) [09:41] missing a "of", at least [09:41] pedronis: spent a little time with nltk looking for the intersection between synonyms of 'container' and 'blob', with no luck [09:41] pedronis: sure :) planned to do it all along [09:44] Chipaca: ok, seems "naming" is reasonable tough [09:44] pedronis: yes <3 [09:54] Chipaca: did you see my #6389 comment ? [09:54] PR #6389: cmd/snap: small refactor of cmd_info's channel handling [09:54] pedronis: yes [09:54] pedronis: thank you [09:54] pedronis: need to get to that yet [09:55] ok [09:58] FYI I will be away for the next few hours, [10:08] oh, codecov is back [10:12] PR snapd#6421 closed: spread: enable upgrade suite on fedora [10:16] Chipaca: looked at #6356, doesn't seem inline with the requirements, what we discussed originally [10:16] PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump [10:17] mvo: hey! Did you see Pat's and Cody's e-mail about trusty snap preseeding? I'm not really knowledgable in these areas and thought maybe you had some leads/ideas [10:18] how do I build a core snap from a PR that adds a new interface, to test it locally? [10:21] sil2100: I did see it, but haven't managed to look at it yet :( [10:26] mvo: busy times, no worries! It might be something wrong from the image build POV, but I'd like a snappy expert to first take a look and see if there's anything obviously wrong there [10:40] Chipaca: /var/lib/snapd/sequence is something from snapshots? [10:40] mborzecki: nop [10:41] mborzecki: it's a cache of .Sequence [10:41] used for recovery iirc [10:42] PR snapd#6427 closed: interfaces: add block-devices interface [10:42] Chipaca: hm, didn't notice this before, snapd arch package does not clean it up properly for some reason [10:42] mborzecki: missing diff in cmd/snap-mgmt/snap-mgmt.sh.in ? [10:43] Chipaca: nah, it's not accounted for in the package, so removing the package leaves the dir behind [10:44] Chipaca: snap-mgmt only removes /var/lib/snapd/sequence/* [10:44] mborzecki: when you get a diff, show me? because I need to do something similar for /var/cache/snapd/store i suspect [10:44] mborzecki: unless you mean it doesn't remove the director itself? [10:44] 6408 needs a second review, hopefully simple [10:46] Chipaca: snap-mgmt removes all of /var/cache/snapd/* [10:48] PR snapd#6424 closed: tests: remove -o pipefail [10:48] mborzecki: why doesn't it remove all of /var/lib/snapd? [10:48] Chipaca: because fedora packaging takes care of this with %dir entries in rpm spec [10:49] Chipaca: there is no equivalent on arch, so dirs are precreated when package is built and then automatically revmoed by pacman [11:21] re [11:26] mvo: got a node when console-conf@ttyS0 keeps restarting [11:29] mborzecki: what is the systemctl status / jounralctl log output? [11:29] mborzecki: any interessting error message [11:29] PR snapd#6408 closed: tests: add spread test for system dbus interface [11:30] mvo: no, the log is rather useless https://paste.ubuntu.com/p/CHH2m9k6t5/ [11:31] mvo: hm looking at the full log, there might be a pattern though [11:31] mborzecki: how did you trigger it? [11:32] mborzecki: my naive way did not work :/ [11:32] mvo: https://paste.ubuntu.com/p/qyGfvxNrmh/ [11:32] mborzecki: aha, maybe different machines [11:32] mvo: notice how reloads are interleaved with console-conf restarting [11:33] mborzecki: indeed [11:33] mborzecki: that looks suspicious [11:33] mvo: note, i'm installing and removing 11 snaps in parallel in a separate shell [11:34] mborzecki: interessting [11:34] mborzecki: is this all the logs we get? Jan 25 11:24:45 jan251115-985265 systemd[1]: serial-console-conf@ttyS0.service: Failed with result 'exit-code'. is really not helpful, not even the exit code numbe [11:34] r [11:34] mvo: yup [11:35] mborzecki: nothing in journalctl -u serial-console-conf@ttyS0.service or systemctl status -l serial-console-conf@ttyS0.service :( sad [11:35] mborzecki: I guess you can't strace it as this all happens too quickly? [11:37] mvo: what is the value you saw from exit code? [11:37] zyga: looking at the logs from mborzecki I see nothing there [11:42] PR snapd#6430 opened: tests: enable debian sid as part of the main suite on travis [11:50] mvo: heh, reloading daemon makes console-conf fail, wtf? [11:51] mborzecki: yeah, that is … unexpected [11:56] mvo: https://paste.ubuntu.com/p/ZsCjMDdQNC/ confole-conf-wrapper started by agettu [11:57] mvo: fd 0 is /dev/ttyS0 === chihchun_afk is now known as chihchun [12:04] mvo: another one showing what it writes to stderr https://paste.ubuntu.com/p/ht5v7QhPxC/ [12:05] zyga: do you know/remember the switch to drive sbuild so that it is as close as possible to the buildds? [12:06] mborzecki: aha, nice [12:06] you have to change .sbuildrc [12:06] mborzecki: "write(2, "/usr/share/subiquity/console-conf-wrapper: line 62: read: read error: 0: Resource temporarily unavailable\n", 106) = 106" [12:06] to build arch indep separately AFAIK [12:06] mvo: but I strongly recommend something else [12:06] mvo: please look at and improve this: https://github.com/snapcore/snapd/pull/6410 [12:06] PR #6410: release-tools: add debian-package-builder [12:06] zyga: well [12:06] you can test it there :) [12:06] it's just a fire&forget [12:06] zyga: I'm looking at a spread test [12:06] (for experimenting) [12:07] I mean, to get to the point where we can be certain 2.37-2 reproduces the failure [12:07] just feed the 2.37-2 package to this script [12:07] and see if it fails [12:07] zyga: the arch indep ? [12:07] if so, that's representative of what we know so far [12:07] yes [12:07] mvo: yeah, then it proceeds to run stty, waits for it, waits for any children and exits, maybe it's how this works? the sequence seems legit [12:08] zyga: but that is "just" doing a normal sbuild without any extras, no? [12:08] correct [12:08] I suggested that as a vehicle to find out which setting in sbuild controls this to reproduce the failure [12:08] zyga: we did this as well and for us it did not fail [12:08] I think it's just one of the variables you can set there [12:08] zyga: aha, ok [12:09] I don't know the answer from the top of my head [12:09] sorry :/ [12:09] I just recall reading the example file [12:09] and this is something you can tweak there [12:09] I believe we need to run a pair of builds then though [12:09] zyga: all parts of the example are commented out :/ [12:10] maybe --no-arch-all [12:10] http://manpages.ubuntu.com/manpages/bionic/man5/sbuild.conf.5.html [12:10] by default they are built [12:11] zyga: yeah, I play around, thank you [12:11] zyga: but lunch first :) [12:11] I mainly recommended that script because you can get to the part where you can tinker easily [12:11] and it is reproducible [12:28] mvo: the thing is https://salsa.debian.org/debian/snapd/commit/7991e731c068148de7ae1b9e99d8df4e6f45601e [12:28] --no-arch-any [12:28] that's what you need [12:34] pedronis: pushed changes to the store info cache. This change makes it a lot smaller; need to update the description though [12:34] pedronis: but, one more change I think I should make: I should make the cache be per snap id, not per snap name [12:36] Chipaca: sounds reasonable [12:36] pedronis: making it per snap name would be more friendly but not sure if we care [12:36] could include the name in the json if that helped? (would it?) [12:37] * Chipaca thinks it'd be fine as is but with snap id [12:39] Chipaca: we don't want people to rely on this, so it shouldn't matter [12:39] Chipaca: I mean, it should be a snap detail, not something people use, no? [12:39] *snapd detail [12:39] right [12:39] and tomorrow we couold change it to be a sqlite or something [12:41] yes [12:41] mborzecki: reviewed 6333 [12:41] pedronis: thanks [12:44] mborzecki: anything blokcing #6403 ? [12:44] PR #6403: many: cleanup golang.org/x/net/context === chihchun is now known as chihchun_afk [12:46] pedronis: not really [12:47] mvo: are we ok to land 1.9+ things? === Sir_Gallantmon is now known as Son_Goku [13:01] sergiusens: around? About https://irclogs.ubuntu.com/2018/12/18/%23snappy.html#t02:09 [13:01] If you are, then I'll catch up on any upstream changes to the problem since, and if it's still there I'd appreciate some of your time please. [13:02] Hmm I say that but the problem appears to have gone away for now. Presumably requirements.txt changed again. [13:03] rbasak: if you use a base, it is a list, if you do not, it is a string when using 3.x [13:03] However it would be nice to know how to solve it properly and/or register it as a shortcoming in snapcraft's Python plugin if appropriate. [13:03] rbasak: and fwiw, the deb is going to stick to 2.x [13:04] * Chipaca goes to have lunch [13:35] PR snapcraft#2451 opened: static: address black warnings [13:45] mborzecki: yes, we are ok [13:45] PR snapd#6431 opened: snapcraft.yaml: fix snapcraft building in launchpad [13:46] PR snapd#6403 closed: many: cleanup golang.org/x/net/context [13:47] PR snapd#6430 closed: tests: enable debian sid as part of the main suite on travis [13:57] zyga: hey, don't bother adding your backlight to the PR, I've got a better idea [13:58] jdstrand: should I mark that pr blocked? it's green and has two +1's, somebody'll land it otherwise :-) [13:58] Chipaca: I just did, thanks! [13:59] jdstrand: ack [13:59] jdstrand: I really wish sysfs wasn't a maze of symlinks :) [13:59] jdstrand: github here disagrees, but i guess eventual consistency is eventual [13:59] Chipaca: I *just* did it after you suggested it [14:00] jdstrand: reloading it and still not seeing it :) [14:00] anyway, i'm off to the standup === ricab is now known as ricab|lunch [14:12] degville: 2010 says hi: https://r.chipaca.com/the_cult_of_done_manifesto.png [14:13] thanks Chipaca! [14:13] done is definitely better than perfect. [14:17] zyga: "shall I compare thee to seccomp" -- mvo, probably [14:24] zyga: https://en.wikipedia.org/wiki/Singularity_(operating_system) [14:25] I love the shade of blue they used [14:47] zyga: https://wiki.debian.org/X32Port FWIW [14:48] zyga: but alas debian-x32.org is no more [14:48] anyhooo [14:50] zyga: mborzecki: and i was wrong about the kernel it seems. Had the worng end of the stick on this. Sorry for the noise. [15:02] mborzecki: re 6422 - you write that you can reproduce hte mount issue without the change in the PR. does that mean with the change (i.e. when console-conf is disabled) the mount issue is no longer there? [15:03] mvo: it's still running [15:03] ta [15:05] mvo: so a core 18 node was up for ~1h and didn't error out [15:06] mvo: need to go out now, but i'll spin another one and let it run [15:06] Chipaca: do you know if 6280 is ready for a second review? or is there something fundamental that needs discussion still? [15:06] mborzecki: ta [15:06] mvo: this is the script i'm using if you want to try it yourself too https://paste.ubuntu.com/p/rXDvJgFShf/ imo it's bit more aggressive than the test we have [15:06] mborzecki: so a core18 node without console-conf (with console-conf disabled) survived 1h ? that sounds encouraging [15:07] mborzecki: thanks, looking [15:07] mvo: I think pedronis unblocked it because it's ok [15:07] Chipaca: it got my +1 - its (IMHO) an easy win, would love to see itin [15:08] so if someone looks for a fun review: 6280 (/me clearly works on is marketing skillz) [15:10] I bet it's a trap [15:18] Chipaca: mvo: yes, nothing fundamental against it (also now that --unicode is fixed for non-tty) [15:31] mborzecki: +1 to 6016 but some comments there === ricab|lunch is now known as ricab [15:43] re [15:43] dinner done, now onwards [15:53] Since a few months, sound is no longer working in my snapped Firefox, but other applications can still produce sound. This is running Debian buster. I haven't tested other sound-producing snaps, though. (repost from #snapcraft) [15:53] r4co0n: how about the chromium snap? [15:54] kenvandine, I'll go install and test. I got chromium installed via apt and it is working fine. [15:54] r4co0n: hey [15:54] r4co0n: we've made an upload to buster recently, 2.37-3 will be coming your way soon (tm) [15:54] r4co0n: would be great if you could check once that is released [15:55] r4co0n: or get it from the incoming pipe if you want [15:55] * cachio lunch [15:56] zyga, I'm still on 2.36-3, let's see when this comes to my mirror. [15:57] r4co0n: it's not migrated yet [15:57] r4co0n: can you look at your journal output, perhaps there are some denials or something similar? [15:57] r4co0n: I can try locally in a moment [15:57] PR snapd#6412 closed: tests: interfaces tests normalization [15:58] pedronis: got a bit to talk about the triggering logic for rere? [16:01] zyga, kenvandine, sound is working in the chromium snap. [16:01] Chipaca: I have a meeting noew [16:01] pedronis: my condolences [16:02] Chipaca: let's just head to the pub then ;) [16:02] yeah [16:02] * Chipaca puts on his boots [16:03] zyga: I added sbuild spread test now [16:03] woot, I'm going through reviews now, but I can look at this out of band if you want [16:06] How can I run the firefox snap in safe mode, with all plugins disabled? I tried gathering it from the help and a websearch, but found nothing. [16:06] r4co0n: no idea, sorry [16:06] r4co0n, zyga, kenvandine might be able to help [16:08] I can start with --ProfileManager and create a new profile [16:08] Not exactly the same, but problem solved. [16:09] But no sound in a new profile :/ [16:11] zyga, you were talking about some journal output I can be checking? How do I do that? I ran the snap from the terminal and there is nothing remarkable showing up... [16:11] 6431 is a very easy review [16:11] *please* [16:12] Chipaca: the meeting was short, didn't quite happen [16:12] btw, the same snap continues to work fine on Debian stretch. [16:12] Similar setup. [16:13] Other system. [16:14] r4co0n: maybe different versions of snapd though [16:14] pedronis: wrt "only do refreshes that would change epoch again", I would have to check with the store about updates, and then decide client-side whether to do the update or not depending on whether an epoch change happened? [16:15] r4co0n: is it connected to the pulseaudio interface? [16:15] check "snap interfaces firefox" [16:15] pedronis: I understand that there's a small window where a snap changes its epoch and then refreshes without changing the epoch and this would re-refresh "early" (not sure why it's a problem), but having to decide client-side whether to do a refresh the store told me to do seems wrong? [16:16] kenvandine, yes ':pulseaudio chromium,firefox' [16:17] Could reinstall help anything? [16:19] The thing is, I am using every other part of this snap just fine everytime I'm at this system. It's just those odd YouTube,etc. moments when I get aware of this problem again. [16:20] r4co0n: did you try chromium? [16:20] kenvandine, yes I did and it works there [16:22] well that's odd [16:22] r4co0n: what version of firefox? [16:23] PR snapd#6419 closed: miscellaneous policy updates [16:23] PR snapd#6420 closed: miscellaneous policy updates - 2.37 [16:25] 6417 is another simple review [16:25] (we just need a second one :) [16:27] kenvandine, it's 64.0.2-1 (167) with no available upgrades on stable [16:31] r4co0n: same as me [16:34] Chipaca: if you are around - can I merge 6400 (nice number!) or is there anything missing? I did a quick test on the UX and it looks reasonable to me [16:35] Chipaca: nice job btw, really like this [16:35] I got KDE reporting in Audio Volume Applications that 'No applications playing or recording audio' before I start audio in firefox snap, and 'AudioIPC Server' showing up as an application as soon as I start the audio stream. [16:35] The volume is non-zero. [16:35] mvo: ooh, you did the ux thing? [16:35] mvo: let me look [16:35] mvo: nice. It won't be translated, but at least it's not lying :-) [16:36] mvo: pedronis had Opinions about the naming of things, but not sure if they were blockers [16:36] ErrNoExpectedResult instead of ErrStoreUnresponsive [16:36] although ErrNoExpectedResult is wrong; it'd be ErrMissingExpectedResult [16:37] but, as i say, dunno if a blocker [16:37] r4co0n: so it's trying to do something [16:38] Chipaca: hm, hm, both seem ok to me. no strong opinion [16:38] Chipaca: anyway, should be landable once this is clarified [16:38] mvo: thanks [16:39] Chipaca: you trapped me, now I'm thinking about a good name for the last 5min [16:40] Chipaca: yes, it's a blocker [16:40] kenvandine, with Chromium, it is showing the application name 'Chromium' almost(?) immediately, sound is at the same level, and I hear stuff. [16:41] Testing with the top-left link on YouTube, btw. [16:41] Chipaca: I mean, I really don't like unresponsive there [16:41] Chipaca: do you want me to explicitly -1 it ? [16:41] PR snapd#6363 closed: cmd/snap-update-ns: save errno from strtoul [16:42] pedronis: it wouldn't be necessary now that i know you think it's a blocker [16:42] pedronis: but it does communicate that unambiguously :-) [16:42] i wish the store returned 420 instead of bogus responses, fwiw [16:43] Chipaca: done [16:43] this is again us heuristicating things [16:43] r4co0n: gnome also shows firefox as Audio IPC Server [16:43] but i can hear it [16:44] Chipaca: once we alway have rerefresh , we have to do something to chose when to reupdate [16:44] PR snapd#6432 opened: interfaces: add block-devices interface - 2.37 [16:45] kenvandine, funny side story, I purged it yesterday after having not used it for quite some months. But I still run it on my laptops. [16:45] Would have been nice for testing now. [16:45] Chipaca: you are already checking if epochs are equal (in the common code, which I don't think is where we want to make the choice) [16:46] Chipaca: I'm saying that needs to be postponed plus extra recheck in the task itself [16:46] down to 53 open PRs - lets see if we can hit 50 today! [16:49] Chipaca: we can chat more on Monday [16:52] Chipaca: Missing works for me [16:56] jdstrand: hi, could you look at #6376 [16:56] PR #6376: tests: split the test interfaces-many in 2 and remove snaps on restore [16:57] pedronis: yes, I started yesterday and will pick up in a bit [17:03] PR snapd#6433 opened: tests: Update fedora 29 workers to speed up the whole testing time [18:01] Hey ogra, does the Ubuntu Core image support the rpi 3B+ ? [18:10] Yes [18:10] kyrofa: ^ [18:10] cwayne, thank you, I suppose you ARE the person to ask these days, eh? [18:11] So I've heard :) [18:11] Ha! [18:36] * cachio afk [18:42] re [18:43] * zyga fell asleep, sorry :( [19:16] Chipaca: https://github.com/google/gops [19:16] shiny [19:31] PR snapd#6425 closed: interfaces: add u2f-devices interface and allow reading udev +power_supply:* in hardware-observe [19:32] PR snapd#6432 closed: interfaces: add block-devices interface - 2.37 [19:32] PR snapd#6433 closed: tests: update fedora 29 workers to speed up the whole testing time [19:38] PR snapcraft#2449 closed: Release changelog for 3.1