[00:00] you. all, too :-) [00:13] Ian. It's nice to read your message. Because my thing in my brain remembers, or something.. thank you, for learning ; -) just rembering the timezones ;-) [00:45] how can i see when a branch is going to close? [06:36] morning [06:54] PR snapd#8028 closed: tests: use test-snapd-upower instead of upower <⚠ Critical> [08:04] morning [08:05] good morning [08:05] mwhudson: what do you mean? [08:06] zyga: branches autoclose in 30 days right? [08:06] mwhudson: ah, I see [08:06] I _think_ so [08:06] but I only used branches once [08:06] and I didn't look at it after the week I needed it [08:06] i'm sure i've seen the date a branch is due to close at somewhere in some command's output [08:06] but i can't remember what [08:14] zyga, mwhudson : they do, and closure date might show in snapcraft status output [08:14] not sure snap info shows that [08:15] actually pretty sure snap info does NOT show that because it doesn't show branches at all :) [08:16] mwhudson: confirmed, you need to own the snap and use "snapcraft status" to see branch expiration timedate [08:16] oh wait part of why i'm confused is that the branches i care about have already closed :) [08:16] roadmr: thanks for checking that though :) [08:16] mwhudson: :P [08:24] zyga: pstolowski: hey [08:33] zyga: do you remember a discussion about debug symbols in snaps? [08:34] zyga: there's a discussion about stripping arch packages, and someone brought up Clear Linux debug symbols support: https://docs.01.org/clearlinux/latest/guides/clear/debug.html# [08:34] zyga: imo it does look intriguing [08:46] PR snapd#8030 closed: tests: add a command-chain service test [08:51] mborzecki: yes, I do [08:52] mborzecki: indeed, that is interesting [08:52] mborzecki: can you add this so the thread somewhere or add a card to investigate it later [09:29] gosh, I'm so sleepy today [09:31] zyga: the fact that it's snowing doesn't make it better i suppose [09:31] snownig? [09:31] *snowing? [09:31] zyga: or at least it's pretending to snow here [09:31] really? [09:31] it's raining here [09:31] at +3 [09:31] snowesome! [09:32] I wish we had a real winter [09:32] not this fake winter thing [09:33] zyga: yeah, snowing very lightly and it melts right away [09:33] I'm fighting the mount-ns test and the gadget test now [09:33] I'll make real coffee (decaf doesn't work but doesn't cause headaches) and keep pushing [09:34] in soviet russia vinter melts you [09:34] zyga: can you take a look at https://github.com/snapcore/snapd/pull/8029 ? [09:34] PR #8029: tests: use test-snapd-upower instead of upower <⚠ Critical> [09:34] oh, that's a 2.43 backport [09:34] sure [09:35] +1 [09:35] shall we just merge? I think so [09:38] https://github.com/snapcore/snapd/pull/8027 is green, i'd land it and start working on a followup [09:38] PR #8027: snap: disable auto-import in uc20 install-mode [09:38] mborzecki: I see what you mean now, that's great [09:38] it's green [09:38] let's land [09:39] though ian wanted to look [09:39] can you work on a follow-up [09:39] ian should be up soon-ish [09:41] zyga: yeah, i will [09:41] quick errand, back in 1h or so [09:42] ok [09:45] hmm [09:45] what's /image.fstab? [10:02] PR snapcraft#2874 closed: Sync fixes from snapcraft-desktop-helpers (LP-1661626 & broken XDG link) [10:08] zyga, mborzecki are you guys familiar with test suites in spread? [10:08] pstolowski: as much as we all are [10:08] what's up? [10:09] zyga: i defined a new one (which is a carbon copy of existing one, plus tweaks), but getting: error: nothing matches provider filter [10:09] pstolowski: can you show me ze code [10:09] spread -debug google-nested:ubuntu-18.04-64:tests/nested/preseed/ [10:10] you need an entry in spread.yaml [10:10] and a directory with actual tests [10:10] zyga: https://pastebin.ubuntu.com/p/7YRs9qT6w7/ [10:10] pstolowski: did you add tests to tests/nested/preseed? [10:11] zyga: https://pastebin.ubuntu.com/p/3HFjMMrG7b/ [10:11] is the task manual? [10:12] zyga: it's manual:true in the suite definition, not in the task ()it's the same for existing nested tests [10:12] hmm [10:13] can you spread -list and see it? [10:13] brb [10:14] aha, it's not shown, maybe indentation is off in the yaml [10:20] nope, indentation is fine.. it must be something silly [10:24] pstolowski: silly idea [10:24] pstolowski: build spread and printf the yaml it loads [10:24] pstolowski: or maybe spread -list -vv will show that, dunno [10:24] I wonder what is [10:25] zyga: indeed -vv prints it [10:25] pstolowski: backends? [10:25] and if you remove manual: true? [10:27] ha [10:27] I found a bar of chocolate [10:27] it was on top of the fridge [10:27] probably hid it so that kids would not devour all xmas stuff at once [10:28] $wife doing orange juice and needed to fetch the juicer [10:28] :) [10:30] removing manual:true doesn't help. my suite is visible as spread.Suite with -vv. something doesn't match somewhere apparently [10:30] can you check backends [10:30] I had an issue somewhere a while ago [10:30] where a test would just not execute on anything defined [10:30] because backends or systems didn't match [10:37] zyga: aaah, silly me, solved. backends systems definition vs test's system as you said, thank you! [10:37] cool :) [10:37] i'll need sergio to figure out 19.10 and 20.04 on gc [10:43] mborzecki: can you look at https://github.com/snapcore/snapd/pull/8031 when you are back [10:43] PR snapd#8031 opened: tests: update mount-ns test tables [10:43] PR #8031: tests: update mount-ns test tables [10:43] mborzecki: in particular I think I found a bug in writable paths configuration [10:44] mborzecki: as /etc/systemd/system is mounted twice [10:56] re [10:56] mborzecki: o/ [10:57] oh, that's interesting [10:57] zyga: does that only happen on core? [10:57] system or machine-id? [10:58] I think only on core [10:58] let me check [10:58] /etc/systemd/system moutned twice [10:58] yeah [10:58] note that it is mounted on HOST [10:58] so it's there before we touch it [10:59] zyga: maybe related to /etc/systemd/system coming from writable [10:59] I bet some code manually does it [10:59] I checked core18 and it's only listed once [10:59] or the whole /etc/systemd, don't remember how wriable-paths is set up in 18 [10:59] so ... dunno [11:02] hey, is there another interface for the call `sched_setscheduler` ? I only found `process-control`, `docker`, `browser` ? It seems that music-application, like synthezier and midi-sequencer also needs this. [11:04] I don't think so [11:04] there used to be rtkit [11:04] hmm, `process-control` could be good enough. [11:04] that would allow apps to use it without privs [11:04] sdhd-sascha: do you have an app that needs it? [11:04] zyga: true, thank you [11:04] in #snapcraft, there i test `gsequencer` snap https://bazaar.launchpad.net/~jkraehemann/+junk/gsequencer-3/files [11:05] i just see this call in the logs. Is not for me [11:13] mborzecki: check this out [11:14] https://www.irccloud.com/pastebin/89vWxX4n/ [11:14] just a quick prototype [11:18] the diff is tiny, I'll check how it changes the usability of the data [11:19] I suspect it will let us see meaningful diffs across core systems [11:19] brb [11:19] mborzecki: also note the machine-id thing [11:19] it feels very fishy [11:19] unless I am looking at some tmpfs-not-persistent view [11:19] but I doubt taht [11:19] *that [11:34] PR snapd#8027 closed: snap: disable auto-import in uc20 install-mode [11:37] re [11:38] hey ian! [11:38] thanks for merging that [11:38] mborzecki: ^ follow-up space ready [11:38] mhm [11:39] Hey folks [11:40] * ijohnson is not really here yet === ricab is now known as ricab|bbl [12:09] hi ijohnson! [12:18] Issue core20#12 opened: Drop consoleconf from the core snap [12:18] PR core20#11 opened: Add arm64 architecture [12:19] eh, mup still gives bad github urls [12:21] mborzecki: I simplified the differential idea, I love it [12:21] mborzecki: thank got python has type inheritance on base types [12:21] mborzecki: so all I needed was sint(int) that renders as {:+} [12:21] and a few patch-ups to use sint() when diffing [12:21] I'll check how this behaves in reality in core16 [12:21] but I'm very optimistic now [12:22] mborzecki, ijohnson: I'd like to land this https://github.com/snapcore/snapd/pull/8031 [12:22] PR #8031: tests: update mount-ns test tables [12:22] green [12:22] please review / object [12:54] PR snapd#8032 opened: boot, cmd/snap(-bootstrap): move run mode and system label detection to boot [12:55] cmatsuoka: ^^ can you take a look [12:55] mborzecki: sure, I'm just finishing a fix here [12:55] guys, I need to skip standup [12:55] or I'll join from the go [12:56] need to help wife as she drives around with lucy [12:56] ack [12:56] plus no food at home and starving to eat out [12:56] I'll keep working on a feature branch on the ho [12:56] *go [12:58] PR snapd#8033 opened: Tweak/differential mount ns [12:59] zyga: yeah I reported the mup GitHub issue links to Gustavo a while ago [12:59] ^ just a draft, partial data change, won't pass [12:59] zyga: also yes I will review your branch after SU [12:59] ijohnson: I think I did so as well [12:59] ijohnson: thanks! [12:59] going now [12:59] ttyl [12:59] I'll publish testbed-tool today [12:59] didn't figure out a better name, open to rename later [13:09] ijohnson: have you started looking into a spread test for kernel failover? if not i can look into that [13:12] PR snapcraft#2888 opened: elf: read ELF type when extracting attributes [13:15] mborzecki: do you mean for the uc20 kernel extraction? I have not yet done a spread test, but I have started a bit what we talked about with pedronis on Friday about panic'ing in the mock bootloader [13:25] ijohnson: i can try with actual broken kernel, to see how complicated that is [13:31] re [13:31] online in the back seat [13:31] all three kids accounted for [13:31] dog included [13:31] man [13:31] we travel like polish memes [13:34] mborzecki: I tried the failover with an empty file as the kernel.efi but the bootloader just hung, so if you had a real broken kernel that panicked immediately that would be better for tests [13:35] can I un-approve a PR after I already approved it? [13:35] cmatsuoka: you can dismiss your review [13:35] cmatsuoka: should be near the bottom of the page, where the ci checks are listed [13:35] hmm, let me see... [13:36] Ok, nice, thanks! [13:43] zyga, https://imgur.com/a/XtGYPeI ... about 200 layout entries now ... but it runns fully confined (as root, no gdm/lightdm though) [13:44] * ogra is very surprised to not see an actual performance impact from these many layouts [13:46] ogra: OMG [13:46] I need to rework some layout code to make it better [13:46] it would be really awesome to have something luke "auto-layout" ... [13:47] simply diff $SNAP with / and automatically add bindmounts and symlinks for all non-existing files in / [13:47] s/luke/like/ ... :) [14:01] ijohnson: standup? [14:24] mborzecki, sit down! [14:24] PR snapcraft#2889 opened: meta: always generate snapcraft-runner to workaround classic PATH bug === ricab|bbl is now known as ricab [14:26] back! [14:27] what did I miss [14:27] mborzecki: is the standup over? [14:27] diddledan: rinse and repeat :) [14:27] zyga: yup [14:28] zyga: you missed the part where I heroically came in at the last minute to standup [14:28] haha [14:28] if you were a moment longer I could have joined too :) [14:28] but no worries [14:28] :-) [14:28] my standup update is simple: fixed one more branch (green), working on leaky tests [14:28] also did you see my comment on your core20 mount ns PR? [14:28] as an associated brach-off I updated mount-ns tables [14:28] ijohnson: not yet [14:29] and I'll open another PR that does differential tables [14:29] just a quick thing not sure if you had a typo or if we do actually have an issue there [14:29] probably not a typo [14:30] hmm :-/ [14:30] ijohnson: so (/dev/sda3)/EFI/ubuntu was mounted as /boot/grub [14:30] ijohnson: (if this syntax makes sense) [14:30] ijohnson: is that unexpected? [14:30] yes that makes sense [14:30] your PR description said /boot/grub was from /boot/EFI [14:30] ijohnson: in any case I think this PR showed some suspicious stuff and I'm happy I updated those tables [14:30] (missing the /ubuntu) at the end [14:30] ah, probably mistake there :) [14:30] :-)_ [14:30] I did type the commit by hand [14:31] while outside I got a veggie burger [14:31] and it was ... good [14:31] not great but not bad either [14:31] need to try some more [14:34] ijohnson: I revised the commit message [14:34] PR snapd#8024 closed: overlord/snapstate: add reproducer for LP#1860324 scenario [14:34] PR snapd#8025 closed: overlord/snapstate: add reproducer for LP#1860324 scenario (2.43) [14:35] zyga: have you tried the "impossible burger" ? [14:35] ijohnson: nobody sells them here yet [14:35] but I heard about it [14:35] zyga: ah I see [14:35] I haven't tried it myself yet either [14:35] I really like these black bean veggie burgers from the supermarket though [14:36] don't remember the brand [14:36] I love beetroot burgers [14:36] we make them at home [14:36] interesting never tried beetroot burgers [14:36] zyga: beetroot in place of meat or the bun? [14:36] mborzecki: meat [14:36] it's not pure beetroot, I can ask my wife for the recipe [14:37] but the taste is insane :) [14:37] I love those really [14:37] we bake them in the oven [14:37] btw. if it has no mean, can it still be called a burder or does it downgrade to sandwich at that point? :P [14:37] s/mean/meat/ [14:37] and when we make a batch it's usually 30-50 [14:37] we eat half and freeze the rest or give them away [14:38] mborzecki: I think nobody can claim it is not a burder ;-) [14:38] https://github.com/snapcore/snapd/pull/8031 <- review please [14:38] PR #8031: tests: update mount-ns test tables [14:38] it's just the data tables [14:38] and I can open the follow-up on top [14:43] PR snapd#8034 opened: fix for lp:1860324 for 2.43 [14:44] <__chip__> 👋 [14:44] hey __chip__ [14:44] <__chip__> #8034 should be interesting [14:44] PR #8034: fix for lp:1860324 for 2.43 [14:44] __chip__: ouch, updated vs updates! [14:44] <__chip__> as soon as samuele can there'll be one against master (already pushed so you can look at it if you want but not proposed so missing my test) [14:45] mhm [14:45] thank you for finding the time to propose those at the sprint! [14:45] <__chip__> to be clear, this is a bug on master, 2.43 just makes it more likely [14:45] we'll get them reviewed [14:45] * zyga nods [14:45] <__chip__> but it's subtle enough that it warrants another 2.43, at least the last time i was able to talk about it with mvo [14:46] __chip__: did any new data on the __writable__ issue came up at the sprint? [14:47] <__chip__> zyga: not yet, i think we're waiting for info from $customer but i don't know if we've asked them yet :| [14:47] <__chip__> zyga: i'll ask [14:47] __chip__: zyga: I asked the customer in the bug but didn't hear anything back [14:47] ack, thank you guys [14:48] <__chip__> ijohnson: was the customer reading the bug, or did it need to go via field? [14:48] <__chip__> 'cause all i was going to do was ask field :) [14:48] <__chip__> (which i can still do, sometimes the cable needs jiggling) [14:48] __chip__: the customer reported the bug and responded to a question I asked on Friday so I assume that they are reading it, but they might have been busy with other things mon/tues [14:49] __chip__: the bug tracker was customer specific so I would expect they follow it [14:49] <__chip__> ah [14:49] <__chip__> k [14:49] __chip__: yeah probably worth trying to talk to John Agosta in CPT to raise it with them [14:49] raise it -> make sure that the customer tries our suggestionss [14:49] <__chip__> ijohnson: will do [14:50] __chip__: ack thanks [14:52] __chip__: thanks for the PR! edited the title so that the title checks are happy [14:53] <__chip__> ah, yeh thanks [15:28] PR snapd#8035 opened: data/selinux: workaround incorrect fonts cache labeling on RHEL7 (2.43) [15:28] pstolowski: ^^ [15:28] sure [15:49] mborzecki, ijohnson: ping on https://github.com/snapcore/snapd/pull/8031 please [15:49] PR #8031: tests: update mount-ns test tables [15:49] it's just data tables! [15:49] zyga: but it's almost 2000 lines of data tables! :-) [15:49] yes but they are what we do today [15:49] we can argue if that's correct but that's just a snapshot [15:50] note that I don't mind if you read them in detail [15:50] the next PR after that will make it less painful to do changes [15:50] (after another painful change though) [15:50] hmm wasn't your re-numbering option supposed to prevent things like this? [15:50] it makes them less severe [15:51] but as I explain in the follow-up [15:51] it's not immune to insertion in the middle [15:51] that causes re-numbering [15:51] the follow-up switches to delta encoding [15:51] i.e. for xenial it was `1:1 /system-data/etc/systemd/user /etc/systemd/user rw,relatime shared:45 - ext4 /dev/sda3 rw,data=ordered` and now it's just `1:1 /system-data/etc/systemd/user /etc/systemd/user rw,relatime shared:46 - ext4 /dev/sda3 rw,data=ordered` [15:51] so insertions in the middle don't affect the rest as much as they did [15:51] the only difference being that 45 changed to 46 [15:51] yeah [15:51] but I thought you sorted it and re-numbered it? [15:51] oh wait I see what you mean [15:51] yes but something else became :45 [15:51] there's a new thing that was added [15:52] right [15:52] sorry a bit slow today [15:52] I mean, it's not perfect, it's already a bit distant from the totally volatile original [15:52] but this will make it better :) [15:52] the problem is that core tables are out of date [15:52] because those test were disabled [15:53] and we missed some updates the core snap being reflected [15:53] zyga: submitted [15:53] err approved [15:53] :D [15:53] thank you! [15:54] I'll open the follow up shortly [15:54] zyga: but also I do like the relative numbering idea to reduce the diff to protect against this kind of thing [15:54] yeah [15:54] it's super costly and painful to read [15:54] yeah, we'll know more once the tests are enabled on core [15:54] just doing classic side now [15:54] and I'll fix those bugs with gadget snaps [15:54] at least one [15:54] * zyga braces for the fight! [15:54] PR snapd#8031 closed: tests: update mount-ns test tables [15:58] * ijohnson recommends zyga look for the mount ns excalibur [15:58] PR snapd#8036 opened: snapstate: refactor things to add the re-refresh task last [16:08] ijohnson: https://github.com/snapcore/snapd/pull/8033 [16:08] PR #8033: tests: switch mount-ns test to differential data set [16:08] ijohnson: I love how github rendered some of the diffs [16:08] https://github.com/snapcore/snapd/pull/8033/files#diff-9593b62bc67b4cedc7e7106954025f18 [16:08] e.g. here [16:09] it's clear what only the relevantparts are changed [16:09] and I can really read the diff [16:09] 16.04 -> 18.04 is just a few changes [16:09] that are all explainable [16:09] yes that is very nice [16:10] wow' it's raining heavily now [16:10] do you have an example of what it would look like if a new mount was added in the middle to see that the generated diff is very small then ? [16:10] https://usercontent.irccloud-cdn.com/file/ckBZMBmf/classic%2016.04%20vs%20classic%2018.04%20mount%20ns [16:10] just look at this [16:10] those are real tables for 16.04 and 18.04 [16:10] with changes in the middle [16:11] that's great [16:11] much much better, good work! [16:11] maybe include that screenshot in the PR as a comment for other reviewers? [16:11] yeah [16:11] good idea [16:12] https://usercontent.irccloud-cdn.com/file/7loYb2PY/core%2016%20vs%20core%2018%20mount%20ns [16:12] this one is a lot different [16:12] but the diff is really readable now [16:14] here's a silly question - do we even need those mount numbers at all for your actual tests? [16:14] * ijohnson doesn't remember what the actual original test looks for [16:14] that's a good question [16:14] it's hard to answer [16:14] for the shared: parts I'd strongly say yes [16:14] for the major:minor it's useful but probably for debugging (i.e. it will tell you what the device really was) [16:15] for mount_id parent_id it's also less clear but perhaps for debugging [16:15] I think the strongest case is for the shared: master: numbers [16:15] those really mean stuff [16:15] right [16:15] as in, right vs broken [16:15] hmm well something to think about perhaps [16:16] screenshot added [16:17] oh, 14.04 ! [16:17] forgot about that [16:17] I'll force-push one more change [16:17] ah, no [16:17] it's not there, just enabled too many things locally [16:17] uff :) [16:20] ijohnson: I'll do one more pass locally without the major:minor [16:20] and perhaps an --exclude feature [16:20] to remove some of the annoying cgroup changes that caused breakage before [16:20] but first... tea break [16:21] it's still cold in the office :/ [16:21] I wonder if winter comes at all this year [16:22] zyga: shall I bring some snow to frankfurt for you to take home? [16:22] :-) [16:22] haha, I wonder if you actually will [16:22] with the climate upside down [16:22] march may be snowy [16:22] we had days above zero in Montreal, in January... go figure [16:23] roadmr: yesterday the temperature in warsaw and in the canary islands was the same [16:23] +6 [16:23] haha [16:23] * zyga goes fetch that tea [16:23] definitely a more valid comparison than "it's as cold as mars" [16:23] at this rate it'll be "it's hotter than venus" [16:25] (robot announcing the weather) GOOD MORING REMAINING HUMANS; TODAY IS A LOVELY DAY WITH TEMPERATURES AT AROUND +370C; NIGHT WILL BE BELOW ZERO, BELOW -200C TO BE EXACT; HA HA HA; STAY WARM WARM-BLOODS! [16:26] more slaves for my robot colony [19:47] PR snapcraft#2890 opened: extensions: add opengl extension to support classic and strict [20:54] * sdhd-sascha oh - oh ... i don't wan't to disturb someone ---- big sorry ;-) [21:03] is it for you the same, that younge poeple want learn ? or is this only my person who is strange... [21:03] wan't [21:04] i consider, you can be `consuldant` ... or ... but didn't work.. [21:05] hmm... d... mn [21:10] have had visit .. i talk about tesla - and that every informtic-problem is solved now ... and so on... [21:11] ... [21:11] (my wife is afraid, that i'm again a plant eater .. ;-) ) [21:26] zyga: hey, again, thank you ;-) the python library i mean , was used by `conjure-up` ... but can't remember *widget..*