| mup | PR snapd#8208 opened: boot_test: add many boot robustness tests for UC20 kernel MarkSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208> | 03:32 |
|---|---|---|
| zyga | o/ | 06:40 |
| abeato | mvo, morning! | 08:00 |
| mvo | good morning abeato | 08:00 |
| abeato | mvo, one question, which are the bootloader requirements for UC20? is there any documentation on that? | 08:01 |
| pstolowski | morning | 08:01 |
| mvo | abeato: they are roughly the same as before, ideally the bootloader should be able to chainload but I think we could work without that (it means less robustness though) | 08:03 |
| zyga | mvo: good morning | 08:04 |
| mvo | hey zyga | 08:04 |
| zyga | mvo: I'll be partially off today, need to get haircut and finish that pesky travel thing | 08:04 |
| zyga | mvo: my goal for today is to publish what I did for sessions and work on prompting demo | 08:04 |
| zyga | mvo: question | 08:04 |
| zyga | mvo: last evening pedronis and I noticed a store review block on snapd | 08:04 |
| zyga | mvo: due to type | 08:05 |
| zyga | mvo: was that the auto-build? | 08:05 |
| zyga | mvo: or something new | 08:05 |
| abeato | mvo, so, basically the same modifications that we need to do today (for u-boot for instance)? | 08:05 |
| mvo | zyga: an auto-build of 2.43 | 08:05 |
| zyga | ok | 08:05 |
| mvo | zyga: but the snap was removed from the queue, no? | 08:05 |
| mvo | abeato: yes, why do you ask ? | 08:06 |
| zyga | mvo: I didn't check beyond that | 08:06 |
| zyga | I'm very tired lately, I try to sleep as much as I can | 08:06 |
| mvo | abeato: what loader do you have in mind :) | 08:06 |
| abeato | mvo, customers are asking :) | 08:06 |
| mvo | abeato: ok | 08:06 |
| mvo | zyga: good luck, yeah, I feel also not great currently, very strange | 08:06 |
| abeato | mvo, same bootloaders as usual, but I did not know if UC20 required something new | 08:06 |
| zyga | abeato: note that core 20 is x86 driven now, arm work will happen later, my suspicion is that for full feature set you may need a better bootloader | 08:07 |
| zyga | abeato: but I think it's just speculation at this stage | 08:08 |
| zyga | (or more feature integration) | 08:08 |
| mvo | abeato: foundations is working on a port of uboot to uc20 currently | 08:08 |
| mvo | abeato: we willl discuss in FRA what the status is here | 08:08 |
| mvo | abeato: no plans for lk or anrdoidboot so far though | 08:08 |
| abeato | sil2100, do you know which is the status of that? ^^ | 08:09 |
| sil2100 | abeato: hey! I don't have a full update on that, waveform is working on the raspi port - but I know there was progress last time I checked | 08:10 |
| abeato | mvo, hm, lk (well, a fork of it, but we use lk support in snapd) is used by nvidia boards which seem to be polular | 08:10 |
| mvo | abeato: yeah, I'm sure eventually we get lk support it's just not a priority right now | 08:11 |
| abeato | mvo, ok, thanks for the info | 08:12 |
| * zyga feels the urge to start using slack already | 08:13 | |
| pedronis | mvo: hi, in #8206 even the amd64 tests, broke ? | 08:14 |
| mup | PR #8206: travis.yml: run unit tests on arm64 as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206> | 08:14 |
| mvo | pedronis: yeah, it's confusing, I thing I got the syntax for the matrix wrong in some way | 08:15 |
| mvo | pedronis: I'm looking at the network-retry failure first, then I will get back to this one | 08:15 |
| pedronis | mvo: it's fine, to be understand why that one started failing just now ? | 08:15 |
| pedronis | s/to be/do we/ | 08:16 |
| mvo | pedronis: getent hosts www.ubuntu.com returns ipv6 now | 08:19 |
| mvo | pedronis: and the script naively uses "http://$ip" which is invalid for ipv6 of course | 08:19 |
| pedronis | ah | 08:19 |
| pedronis | can't we fix the script ? | 08:19 |
| mvo | pedronis: it's still a bit puzzling, we could force it to just use ipv4 but I wonder if ipv6 gives a useful error | 08:20 |
| pedronis | yes, same here | 08:20 |
| pedronis | I sort would prefer to test with boths | 08:20 |
| mvo | pedronis: exactly | 08:20 |
| abeato | zyga, do you have a pointer to the grub config that will be used for UC20? | 08:20 |
| pedronis | and teach the script to deal with both kind of addresses | 08:20 |
| mvo | pedronis: that was what I'm playing with right now | 08:20 |
| pedronis | ok, great | 08:20 |
| mvo | pedronis: the error for connect ipv6 is different but maybe I'm holding it wrong | 08:20 |
| mvo | pedronis: I litterally got there 20s before we started talking :) | 08:21 |
| zyga | abeato: I'm not closely involved in uc20 work, sorry | 08:21 |
| pedronis | abeato: I can give you pointers, there are two configs involved (they will move inside snapd soon), but at the moment they are in the gadget | 08:22 |
| pedronis | one sec | 08:22 |
| abeato | k | 08:22 |
| mvo | pedronis: meh, it really looks like ipv6 gives a very different net.OpError when it cannot connect, that feels a bit of a rathole "fun" | 08:23 |
| pedronis | abeato: here, https://github.com/snapcore/pc-amd64-gadget grub.cfg-{recovery,boot}, recovery is the first stage, boot is the 2nd used in run mode (vs the various recovery mode of UC20) | 08:25 |
| abeato | pedronis, great, thanks for the links | 08:26 |
| pedronis | mvo: the fun never ends | 08:57 |
| mborzecki | morning | 09:06 |
| mvo | mborzecki: good morning | 09:07 |
| mup | PR snapd#8209 opened: tests: use ipv4 in retry-network to unblock failing master <Created by mvo5> <https://github.com/snapcore/snapd/pull/8209> | 09:08 |
| mborzecki | mvo: hey, anything interesting going on this morning? | 09:08 |
| mvo | mborzecki: master red again but beside this not really | 09:12 |
| mvo | 8209 should unbreak us and I'm looking at an equivalent ipv6 test right now | 09:12 |
| zyga | mvo: interesting that ipv6 thing | 09:18 |
| zyga | for me it shows ipv6 on xenial | 09:18 |
| zyga | specifically | 09:18 |
| zyga | https://www.irccloud.com/pastebin/etKNfVuq/ | 09:18 |
| zyga | there are no ipv4 addresses at all | 09:18 |
| zyga | is that a change in the system config or a change in our domain name? | 09:18 |
| zyga | notably this xenial machine does not have an ipv6 global address | 09:19 |
| mborzecki | zyga: same here, ipv6 only ;) | 09:23 |
| zyga | mborzecki: it's the future ;) | 09:24 |
| mvo | yeah, maybe it's a global change, no idea | 09:25 |
| mborzecki | zyga: hm maybe the response for AAAA comes back faster than for A? | 09:25 |
| zyga | dunno, I would have expected the whole response | 09:25 |
| zyga | it's a DNS query | 09:25 |
| zyga | you ask for stuff | 09:25 |
| mborzecki | or AAAA are queried first | 09:25 |
| zyga | you get stuff | 09:25 |
| zyga | (records) | 09:25 |
| zyga | https://www.irccloud.com/pastebin/4KWXTfnL/ | 09:26 |
| zyga | check this out | 09:26 |
| zyga | curious | 09:27 |
| zyga | dig ANY website-content-cache.canonical.com | 09:27 |
| zyga | that's giving me AAAA records | 09:27 |
| zyga | but dig ANY ubuntu.com does not | 09:27 |
| zyga | but hostent gives both? | 09:27 |
| mborzecki | idk | 09:27 |
| zyga | er, hosts | 09:27 |
| mborzecki | maybe the future is now | 09:27 |
| zyga | the future is broken now | 09:27 |
| mborzecki | zyga: actually quite broken, those addresses returned by getent are not really usable, i only got private and link local addresses on my interfaces | 09:31 |
| zyga | yeah, same here | 09:31 |
| zyga | I wonder if IS changed something | 09:31 |
| zyga | or if ubuntu changed something in xenial | 09:31 |
| zyga | looking at dpkg.log | 09:31 |
| zyga | nothing, it's pretty much unchanged except installs of local test packages | 09:32 |
| mborzecki | imo it's a problem with glibc | 09:32 |
| mborzecki | unless i'm misremembering how things work with ipv6 | 09:33 |
| mvo | I can ask in #is | 09:33 |
| mvo | mborzecki, zyga asking our is folks | 09:35 |
| zyga | thank you | 09:35 |
| mborzecki | definitely the year of linux desktop ;) | 09:38 |
| mborzecki | zyga: btw. try `getent hosts localhost` | 09:39 |
| zyga | I get ::1 | 09:40 |
| zyga | that's so weird | 09:40 |
| zyga | feels broken :) | 09:40 |
| mborzecki | zyga: wonder where the preference is encoded, at least i can ping ::1 | 09:41 |
| zyga | offtopic, sun and snow / hail oscillate every 10-15 minutes | 09:42 |
| zyga | sunlight with blue sky | 09:42 |
| zyga | then dark gray and lots of snow | 09:42 |
| zyga | what a day! | 09:42 |
| mup | PR snapd#8210 opened: wrappers: add mount unit dependency for snapd services on core devices <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8210> | 09:58 |
| mborzecki | mvo: ^^ do you think this is 2.44 worthy? | 09:59 |
| zyga | mborzecki: hmm | 10:03 |
| zyga | the patch looks buggy | 10:03 |
| zyga | you have [Unit] and then immediately [Service] | 10:03 |
| zyga | in the past [Unit] had ExecStart | 10:03 |
| zyga | is that expected? | 10:03 |
| mborzecki | zyga: yeah, ExecStart is part of [Service], so i updated the tests to make them closer to real unit definitions | 10:07 |
| zyga | aha | 10:07 |
| zyga | how was it working before? | 10:07 |
| zyga | compatiblity in systemd? | 10:07 |
| mborzecki | zyga: no, it's just the test data, the actual services under data/systemd are correct and have ExecStart in [Service] | 10:08 |
| zyga | ahhh | 10:08 |
| zyga | ok, that clears up the mystery ;) | 10:08 |
| zyga | thanks! | 10:08 |
| mvo | mborzecki: probably, please tag | 10:09 |
| mup | PR snapd#8209 closed: tests: use ipv4 in retry-network to unblock failing master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8209> | 10:10 |
| mup | PR snapd#8211 opened: tests: run ipv6 network-retry test too <Created by mvo5> <https://github.com/snapcore/snapd/pull/8211> | 10:15 |
| mup | PR snapd#8207 closed: tests: fix retry network test after image update <Squash-merge> <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8207> | 10:16 |
| mborzecki | mvo: tagged | 10:22 |
| mborzecki | hmm new kernel | 10:27 |
| mborzecki | brb | 10:27 |
| mborzecki | and running 5.5.6 now | 10:34 |
| zyga | posh | 10:44 |
| zyga | mvo: FYI, 14.04 cnf suggests "snap" for "snap" | 10:53 |
| zyga | could lead to some confusioin | 10:53 |
| zyga | mvo: what's the state of ESM snapd build? | 10:54 |
| zyga | I'm testing on 14.04 as well, could get it to see if anything odd pops up | 10:54 |
| mvo | zyga: it's build in staging | 11:01 |
| * zyga -> lunch | 11:55 | |
| zyga | back, | 12:11 |
| mborzecki | zyga: can you remind me, when we launch snap-update-ns it's started using fexecve right? | 12:18 |
| zyga | correct | 12:18 |
| zyga | we launch all our tools this way | 12:18 |
| zyga | any issues? | 12:18 |
| mborzecki | zyga: trying to update the centos 8 and there's weird selinux denial, let me copy that | 12:18 |
| mborzecki | zyga: https://paste.ubuntu.com/p/nDKbryS9tv/ | 12:19 |
| mborzecki | zyga: i think it's ld.so tryign to poke ld cache | 12:19 |
| zyga | mborzecki: yeah | 12:19 |
| zyga | I suspect so | 12:19 |
| * zyga finds selinux gibberish-y | 12:20 | |
| zyga | today I learned one cool feature of dbus is not supported in busctl: https://github.com/systemd/systemd/issues/14954 | 12:20 |
| mborzecki | zyga: ha, weird why busctl doesn't support that | 12:21 |
| zyga | it's just not coded | 12:21 |
| zyga | there's an error branch and thats's that' | 12:21 |
| mborzecki | well, maybe nobody tried it with busctl yet | 12:21 |
| mborzecki | zyga: suppose there's limited use case consideing busctl is a command line tool | 12:22 |
| zyga | mborzecki: shell is still quite versatile, plus you could open python an pass a fd this way :) | 12:23 |
| mborzecki | zyga: you can, but should you? | 12:23 |
| zyga | yes :) | 12:23 |
| zyga | better than python bindings and in general even bash is sufficient to handle FDs | 12:24 |
| mborzecki | zyga: hm why is even snap-update-ns invoked when there's no mount profile? | 12:25 |
| zyga | mborzecki: for several years it is used to construct one | 12:26 |
| mborzecki | zyga: hm need to go through that code again | 12:26 |
| mborzecki | zyga: i keep evicing all state info afer a while :P | 12:27 |
| mborzecki | zyga: hm still wodnering why this isn't picked up by the other selinux specific tests, jsut this one | 12:30 |
| zyga | mborzecki: probably because that test is fairly limited | 12:30 |
| zyga | mborzecki: check out the aggregated denials bug on lauchpad | 12:30 |
| zyga | mborzecki: or enable robust mount ns | 12:30 |
| mvo | hm, ubuntu-core-18-64:tests/main/revert:remote seems to be failing currently, I wonder if it's a one-off or a new trend :( | 12:30 |
| zyga | which exercises the same code | 12:30 |
| zyga | mborzecki: there's a PR from me about that, it fails on a dozen issues | 12:30 |
| zyga | mborzecki: I bet they are the same | 12:30 |
| zyga | mborzecki: they routinely happen in normal use | 12:30 |
| zyga | mvo: how does it fail? | 12:31 |
| mborzecki | it fails due to unexpected denials in the log | 12:31 |
| mborzecki | haaa and those happen on remove | 12:31 |
| mvo | zyga: it says snapd wants to reboot the system | 12:31 |
| zyga | mvo: huh | 12:32 |
| * zyga is overwhelmed by complexity of snapd state handling sometimes | 12:32 | |
| pedronis | mvo: how does it fail? | 12:33 |
| pedronis | we haven't changed anything in that area recently | 12:33 |
| mvo | pedronis: yeah, it looks like there is a pc-kernel refresh that happend just now | 12:33 |
| mvo | pedronis: so the test runs "snap refresh" and that triggered a pc-kernel refresh :/ | 12:33 |
| mborzecki | ayy | 12:34 |
| pedronis | mvo: ah | 12:34 |
| pedronis | fun | 12:34 |
| pedronis | all tests doing snap refresh like that are fragile | 12:34 |
| mvo | yeah | 12:34 |
| pedronis | until we add holding for single snaps | 12:34 |
| * mvo is slightly depressed about this and gets lunch | 12:36 | |
| pedronis | mvo: heh | 12:38 |
| pedronis | mvo: anyway we might get some extra test failures when the test snaps get moved as well | 12:38 |
| mborzecki | hmmmm | 12:41 |
| mborzecki | so when removing a snap and disconnecting the interfaces, we keep recompiling the seccomp profiles on each disconnect | 12:42 |
| mborzecki | feels like wasted cpu cycles | 12:42 |
| mborzecki | zyga: this also triggers snap-update-ns ^^ | 12:42 |
| zyga | mborzecki: yeah, I think that's expected in our current design | 12:43 |
| zyga | mborzecki: we only have one optimization, for mass auto-connect | 12:43 |
| pedronis | mborzecki: we should remember it, but it doesn't sound like something to address right now | 12:44 |
| pedronis | (too many other things) | 12:44 |
| mborzecki | pedronis: right, i'll collect a some notes and open a forum topic | 12:44 |
| cmatsuoka | cachio: it seems that tests with the tpm-enabled branch are successfully running on the google-tpm backend, but it's very, very slow | 12:47 |
| jdstrand | pedronis: hey, since there were 2 force pushes in as many days for just reviews that I did, I wonder if it makes sense where when you first submit a PR in the section about the CLA if there should be something about force pushes | 12:49 |
| jdstrand | that sentence could've used a couple commas | 12:49 |
| === wgrant is now known as wgrant_ | ||
| === wgrant_ is now known as wgrant | ||
| cachio | cmatsuoka, ahh, ok | 13:11 |
| cachio | do you have a branch to use | 13:11 |
| cachio | perhaps I can improve it | 13:12 |
| cmatsuoka | cachio: I'm currently testing with the frankfurt-preview-tpm branch in my tree | 13:13 |
| cmatsuoka | cachio: it consolidates all encryption-related branches on top of the current master | 13:14 |
| cachio | cmatsuoka, nice, thanks | 13:18 |
| cachio | cmatsuoka, is it everything slow? | 13:18 |
| cachio | or just a specific test? | 13:18 |
| cmatsuoka | cachio: I've been running it for something like 1h now and it's still at 100/447 | 13:19 |
| cachio | cmatsuoka, ok | 13:19 |
| cmatsuoka | cachio: also I can't tell if tpm was actually used, if you can shell into the test machine you can check if there's a /writable/system-data/ubuntu-data.keyfile.sealed there. If this file exists the system booted with tpm enabled | 13:21 |
| cachio | cmatsuoka, nice | 13:27 |
| pedronis | cachio: mvo: the test snaps have been transfered, let's see if something goes wrong with some tests | 13:28 |
| mup | PR snapd#8202 closed: cmd/snap-bootstrap,seed: verify only in-play snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8202> | 13:31 |
| pedronis | ^ this might speed UC20 install/boot a little bit | 13:32 |
| pedronis | *speed up | 13:32 |
| pedronis | cmatsuoka: how many machines are you using? | 13:33 |
| pedronis | the tpm systems have one worker, and our runes take 40 minutes with 4-6 workers | 13:35 |
| pedronis | s/runes/runs/ | 13:35 |
| mborzecki | mvo: #8083 should be fine now, i've tagged it with 2.44 since there's a tiny policy update | 13:36 |
| mup | PR #8083: spread, data/selinux: add CentOS 8, update policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083> | 13:36 |
| mvo | mborzecki: thank you | 13:38 |
| cachio | pedronis, running tests right now | 13:50 |
| cachio | cmatsuoka, hey | 13:50 |
| cachio | how many workers are you using? | 13:50 |
| cachio | because by default the backend is using 1 | 13:51 |
| cmatsuoka | cachio: oh noes ok | 13:51 |
| pedronis | cmatsuoka: our runes take ~40mins with 4-6 workers | 13:52 |
| pedronis | runs | 13:52 |
| cmatsuoka | cachio: I thought it was using the same number as the rest, but now it's almost finishing | 13:52 |
| cmatsuoka | cachio: ah, it finished. With 279 tasks aborted | 13:53 |
| zyga | mborzecki: can you check this on your box | 14:47 |
| mborzecki | zyga: hm? | 14:47 |
| zyga | https://www.irccloud.com/pastebin/N9YISpKV/ | 14:47 |
| zyga | mborzecki: it should behave like "sudo" | 14:48 |
| zyga | mborzecki: it has -u for picking the user | 14:48 |
| zyga | mborzecki: it's a bit of a hack | 14:49 |
| zyga | hmmm | 14:51 |
| zyga | weird | 14:51 |
| mborzecki | zyga: https://paste.ubuntu.com/p/pPfN4F34SK/ | 14:51 |
| zyga | it still has some warts | 14:51 |
| zyga | or one annoying one | 14:52 |
| mup | PR snapd#8212 opened: tests: updating checks to new test account for snapd-test snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8212> | 15:10 |
| * zyga break | 15:25 | |
| pedronis | mmh, github is having issues for me | 15:33 |
| * cachio lunch | 15:40 | |
| pedronis | yea, status gives degraded hard to do reviews :/ | 15:42 |
| ijohnson | pedronis: sorry had my 1:1, but I'm editing the docs now, are you okay if I just make the edits directly or do you want me to propose changes with the suggestions thing on the doc? | 15:52 |
| ijohnson | (edits for what's no longer 100% accurate) | 15:52 |
| pedronis | ijohnson: probably just do the edits, unless there is something you are unsure about, in any case they are not that long, I can re-reread them after. Also remove/resolve any stale discussions/comments bits | 15:53 |
| ijohnson | pedronis: ack | 15:54 |
| pedronis | thank you | 15:54 |
| ijohnson | pedronis: what does the green highlighting mean again? does that mean we already did it? if so perhaps we remove all the green highlighting and just use light red to mean "not done" ? | 16:05 |
| ijohnson | or I guess the official name "light green 3" | 16:05 |
| cjp256 | what are the usual suspects for seeing "broken" in the notes section for a snap? | 16:07 |
| cjp256 | i have lxd (stable) installed, but recently it seemed to break (after dist-upgrade?) and I'm getting errors like apparmor="DENIED" operation="exec" profile="snap.lxd.lxc" name="/usr/sbin/aa-exec" pid=5159 comm="lxc" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0. notes section says "broken" | 16:08 |
| ijohnson | pedronis: anyways I made all the edits to update those 2 docs, I'm going to work on a section in the booting" | 16:10 |
| ijohnson | I'm going to work on a section "booting" doc to put details about what we discussed this morning about | 16:10 |
| ijohnson | cjp256: do you have a "current" symlink in /snap/lxd ? | 16:11 |
| cjp256 | yeah, rev 13487, which doesn't actually match the "installed" version according to snap info... | 16:11 |
| ijohnson | cjp256: also what about the snap mount unit in systemd `systemctl status snap-lxd-*.mount` ? | 16:12 |
| cjp256 | active, mounted 13487 | 16:12 |
| cjp256 | snap list shows 13522 as being installed though...? | 16:13 |
| ijohnson | do you only have 1 mount unit in that command above ? | 16:14 |
| ijohnson | For me, I have 2 mount units, 13487 and 13522 | 16:14 |
| cjp256 | yeah snap-lxd-13487.mount - Mount unit for lxd, revision 13487 | 16:14 |
| ijohnson | hmm so that's why it's broken, snapd wanted to install 13522, but for some reason you never got a mount unit for it | 16:14 |
| ijohnson | it -> that revision | 16:15 |
| cjp256 | so in other news, irccloud also started acting up | 16:15 |
| cjp256 | apparmor="DENIED" operation="symlink" profile="snap.irccloud.irccloud" name="/home/chris/snap/irccloud/28/.config/ibus/bus" pid=10991 comm="ln" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 | 16:15 |
| ijohnson | what does `snap list lxd --all` show? do you have other revisions listed there (perhaps ones that are disabled) ? | 16:15 |
| cjp256 | 13487 "disabled" 13522 "broken" | 16:16 |
| jdstrand_ | cjp256: does irccloud have the desktop-legacy interface connected? | 16:16 |
| === jdstrand_ is now known as jdstrand | ||
| ijohnson | try `snap revert lxd --revision 13487` | 16:17 |
| cjp256 | jdstrand: `desktop-legacy irccloud:desktop-legacy :desktop-legacy -` | 16:17 |
| jdstrand | cjp256: oh, that is down in SNAP_USER_DATA anyway. that is probably related to a refresh | 16:18 |
| cjp256 | ijohnson: that worked like a champ! :D | 16:18 |
| jdstrand | cjp256: guessing current is pointing to !28 ? | 16:18 |
| ijohnson | now you could try `snap refresh` of lxd again and see how it goes | 16:18 |
| cjp256 | well that's interesting | 16:19 |
| ijohnson | cjp256: do you have experimental.refresh-app-awareness enabled ? | 16:19 |
| cjp256 | irccloud had a similar problem | 16:19 |
| cjp256 | --all shows 24 "diabled,broken", and 27 "-" | 16:19 |
| pedronis | ijohnson: yes, green meant done afaiu (sorry was in a meeting) | 16:19 |
| cjp256 | but current is a symlink to 28 | 16:19 |
| ijohnson | pedronis: thanks | 16:20 |
| cjp256 | ijohnson: yes! | 16:20 |
| pedronis | ijohnson: and yes, if it's mostly done, I would remove it and just use read for missing bits | 16:20 |
| ijohnson | cool | 16:20 |
| pedronis | s/read/red/ | 16:20 |
| cjp256 | ijohnson/jdstrand: though in irccloud's case, a `snap refresh irccloud --stable` did restore order, current is pointed back to 26 | 16:23 |
| pedronis | ijohnson: I'll look at docs now, given that reviewing is a bit not working on github atm | 16:23 |
| ijohnson | cjp256: what's `snap changes irccloud`? | 16:24 |
| cjp256 | just `143 Done today at 11:21 EST today at 11:21 EST Refresh "irccloud" snap` | 16:24 |
| ijohnson | pedronis: ack there is one thing I'm unsure about is whether there's a modeenv in the image when we build it, I had a comment in the doc from a while ago that we were writing one there but perhaps we aren't and it was something else | 16:24 |
| cjp256 | ijohnson: i did reboot earlier to see if that resolves the problem, i don't know if changes logs prior boots | 16:25 |
| ijohnson | pedronis: the issue that made me write that was that I had a too old `snap prepare-image` and the image I was writing (even though it was writing a newer snapd into the image) wouldn't finish boot | 16:25 |
| ijohnson | It got stuck in install mode | 16:25 |
| ijohnson | cjp256: no reboots don't clear changes | 16:25 |
| ijohnson | cjp256: not sure what caused your problems but it sounded a lot like the ibus input thing jdstrand solved a while ago on irccloud and some bad refresh on the lxd snap | 16:26 |
| pedronis | ijohnson: we don't, modeenv exists only in ubuntu-data and there is no ubuntu-data in UC20 images built (at least for now) | 16:27 |
| ijohnson | pedronis: right, then I guess I will delete that, not sure what the problem was with my image a while ago but probably was an artifact of many things changing at once | 16:28 |
| cjp256 | ijohnson: now that I have a good idea of what may be happening I can dig in a bit further next time should it happen again... thanks! | 16:28 |
| ijohnson | np | 16:28 |
| pedronis | ijohnson: what are the yellow highlights, were they preexisting? | 16:31 |
| pedronis | (me doesn't remember) | 16:31 |
| pedronis | I'm looking at bootenvs right now | 16:31 |
| ijohnson | pedronis: yes you added those one day | 16:31 |
| ijohnson | pedronis: perhaps we should consolidate the info in that highlighted section and unhighlight | 16:32 |
| ijohnson | it | 16:32 |
| ijohnson | mmm seems I missed some things in the bootenvs doc | 16:32 |
| murthy | spotify's UI freezes after sometime | 16:34 |
| murthy | does that happen to any of you? | 16:34 |
| murthy | I had also tried reinstalling but issue still exists | 16:35 |
| murthy | If someone can confirm I can try to downgrade | 16:36 |
| pedronis | ijohnson: I made some suggestions, comments and marked some not yet done bits in light red in the boot envs one | 16:41 |
| pedronis | ijohnson: please review | 16:41 |
| ijohnson | pedronis: ok looking | 16:41 |
| cmatsuoka | cachio: the encryption test is failing with google-tpm (/sys/kernel/security/tpm0/binary_bios_measurements: no such file or directory) | 16:43 |
| murthy | fellows is there a bug reporting place somewhere for a snap? | 16:43 |
| cmatsuoka | cachio: I checked with Chris and the likely cause is secure boot not enabled | 16:44 |
| pstolowski | murthy: snap info spotify - the contact field | 16:45 |
| cmatsuoka | cachio: are you using the snakeoil nvram file (OVMF_VARS.snakeoil.fd)? | 16:45 |
| murthy | pstolowski: checking | 16:46 |
| pstolowski | murthy: it seems there is an issue similiar to yours https://community.spotify.com/t5/Desktop-Linux/Spotify-GUI-freezes-in-Ubuntu-19-10/td-p/4900983 | 16:48 |
| murthy | pstolowski: Ya, I just saw that | 16:51 |
| murthy | pstolowski: hope they fix it soon | 16:51 |
| murthy | pstolowski: thanks for the help | 16:51 |
| pstolowski | yw | 16:51 |
| pedronis | ijohnson: I did a pass on half of booting, the update bits need some tidying up still | 16:51 |
| pedronis | ijohnson: maybe copy some of the comments from bootstate20.go, not sure | 16:52 |
| ijohnson | pedronis: ok doing that now | 16:52 |
| pedronis | ijohnson: I left a comment about were I stopped for now | 16:53 |
| pedronis | ijohnson: would like to eod a bit earlier today | 16:53 |
| pedronis | I will still try to post my reviews later tonight if github behaves | 16:53 |
| ijohnson | pedronis: of course, we can look at it all again tomorrow | 16:53 |
| pedronis | ijohnson: thank you | 16:53 |
| pedronis | ijohnson: to be clear, feel free to accept or tweak my suggestions in the two docs | 16:58 |
| * pedronis eods | 16:58 | |
| ijohnson | yes | 16:58 |
| ijohnson | have a good evening pedronis | 16:58 |
| mvo | bye pedronis | 16:59 |
| cachio | mvo, is it ok https://paste.ubuntu.com/p/HqQP9Pfbhd/ ? | 17:05 |
| cachio | mvo, because this is making fail the fix for the create user 2 test | 17:06 |
| mvo | cachio: this smeels like a bug | 17:07 |
| mvo | cachio: if you run "snap managed" after "snap remove-user", does it report true? | 17:07 |
| cachio | mvo, exactly | 17:07 |
| cachio | and initially was false | 17:08 |
| zyga | cachio: do you have a shell there? | 17:10 |
| zyga | cachio: the state has all the info we need to grok that | 17:10 |
| cachio | zyga, sure, 1 second | 17:10 |
| mvo | cachio: meh, that sounds like a bug, quite annoying | 17:11 |
| cachio | mvo, zyga https://paste.ubuntu.com/p/Q4D8nM5Hth/ | 17:11 |
| zyga | cachio: cool, it's even up front | 17:12 |
| zyga | mvo is logged in :) | 17:12 |
| cachio | mvo, the good part is that we found it | 17:12 |
| zyga | mvo: you own plenty of devices :) | 17:12 |
| zyga | mvo: is that master or release? | 17:12 |
| mup | PR snapd#6708 closed: tests/main/buildmode: verify usability of PIE hardening for deb packages <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6708> | 17:14 |
| mvo | zyga: master | 17:15 |
| mvo | zyga: delete-user is not released yet | 17:15 |
| zyga | good | 17:15 |
| mvo | zyga, cachio it's a bit confusing, we have code that should remove the user | 17:17 |
| * mvo looks | 17:17 | |
| zyga | https://www.irccloud.com/pastebin/0ANbDwIR/ | 17:17 |
| zyga | golang's brilliant array API | 17:18 |
| zyga | n = 0 | 17:18 |
| zyga | I guess authStateData.Users becomes an empty slice | 17:18 |
| zyga | is it possible that this is not a snapd bug | 17:19 |
| zyga | but a bug in the prepare/restore | 17:19 |
| zyga | e.g. we restore a state that has auth | 17:19 |
| zyga | cachio: is the test machine backup's copy of state.json also authenticated? | 17:19 |
| cachio | zyga, checking | 17:20 |
| cachio | zyga, I dont see it https://paste.ubuntu.com/p/2GXmN3dcv8/ | 17:24 |
| cachio | users":null | 17:25 |
| cmatsuoka | cachio: tpm is (or seems to be) working in the google-tpm backend, but secure boot is disabled. are we using the snakeoil ovmf vars? | 17:28 |
| === alan_g is now known as alan_g_ | ||
| zyga | cachio: so that limits the bug | 17:29 |
| zyga | cachio: thanks! | 17:29 |
| zyga | hmm | 17:29 |
| mup | PR snapcraft#2953 closed: meta: remove remaining `__dict__` and key list usage in snap <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2953> | 17:32 |
| cachio | zyga, I think the problem comes because | 17:33 |
| cachio | userdel --extrausers -r mvo | 17:33 |
| cachio | userdel: mvo mail spool (/var/mail/mvo) not found | 17:33 |
| zyga | oh | 17:33 |
| zyga | is this test failing on core18? | 17:33 |
| zyga | perhaps /var/mail/ is not writable | 17:34 |
| mvo | cachio: oh, so this command fails and we don't get an snap delete-user error? | 17:34 |
| zyga | cachio: does userdel fail? | 17:34 |
| mvo | cachio: I need to get dinner now, please either put what you find in the standup doc or sent a mail, I can work on this in my morning | 17:34 |
| mvo | (or someone else can tonight of course if someone is around :) | 17:35 |
| cachio | mvo, sure | 17:35 |
| zyga | uh | 17:35 |
| cachio | I'll continue digging | 17:35 |
| zyga | mvo: we do something silly | 17:35 |
| zyga | if output, err := exec.Command("userdel", cmdStr...).CombinedOutput(); err != nil { | 17:35 |
| zyga | return fmt.Errorf("cannot delete user %q: %v", name, OutputErr(output, err)) | 17:35 |
| zyga | } | 17:35 |
| zyga | is err going to be != nil if command were false? | 17:35 |
| zyga | or is that buried in cmd? | 17:36 |
| zyga | there's ProcessState.ExitCode | 17:37 |
| zyga | I don't think we ever check that!!! | 17:37 |
| zyga | mvo: I'm in another topic, sorry | 17:38 |
| zyga | paging out | 17:38 |
| zyga | it could be a dead end, just not digging there more now | 17:38 |
| cachio | zyga, np, I'll leave all the findings in the doc | 17:40 |
| zyga | thanks! | 17:40 |
| ijohnson | zyga: CombinedOutput() will return non-nil err if the exit code is not 0 | 17:47 |
| zyga | ijohnson: in that case I don't see any obvious bugs in that code | 17:47 |
| ijohnson | yeah looks pretty typical code to me | 17:48 |
| ijohnson | just the snippet you posted | 17:48 |
| ijohnson | cachio: do you want me to take a look at this too? not clear to me if this is blocking the release or what the bug is that folks are looking at now | 17:48 |
| === alan_g_ is now known as alan_g | ||
| cachio | ijohnson, https://paste.ubuntu.com/p/k5wqvYMXKz/ | 17:49 |
| cachio | userdel --extrausers is breaking everything | 17:49 |
| cachio | snap remove-user works well | 17:50 |
| cachio | but we have a test which uses userdel --extrausers | 17:50 |
| ijohnson | ooh looks like fun | 17:50 |
| pedronis | well userdel will not update snapd internal status | 17:50 |
| pedronis | for sure | 17:50 |
| cachio | and is breaking the next one | 17:50 |
| ijohnson | hmm, can we have this test use a different user? | 17:50 |
| ijohnson | to add/remove ? | 17:51 |
| pedronis | but state restore should bring it back to sane, no? | 17:51 |
| ijohnson | that too | 17:51 |
| * pedronis going to have dinner | 17:51 | |
| cachio | ill update the test to do snap remove-user instead of userdel | 17:51 |
| cachio | ijohnson, does it make sense? | 17:51 |
| ijohnson | cachio: which test is this | 17:51 |
| ijohnson | remove-user ? | 17:52 |
| cachio | yes | 17:52 |
| ijohnson | looking | 17:52 |
| cachio | ijohnson, also I updated the create user 2 | 17:55 |
| ijohnson | cachio: so the problem is that this test in the restore section runs `userdel` and that breaks a different test ? | 17:55 |
| ijohnson | specifically the create-user2 test ? | 17:55 |
| cachio | ijohnson, yes but there were also another error | 17:57 |
| cachio | not sure which was causing that | 17:57 |
| cachio | but the create user 2 test needed another fix which I am testing | 17:57 |
| cachio | ijohnson, do you think we can use snap remove user instead of userdel? | 17:58 |
| ijohnson | cachio: I think it makes sense to have the remote-user test run `snap remove-user` instead of userdel, because as samuele mentioned, `snap create-user` does more than just manipulate extrausers, so to be safe we should undo all of the things that `snap create-user` did and the right way to do that is `snap remove-user` | 17:58 |
| ijohnson | sorry s/remote-user/remove-user/ | 17:59 |
| ijohnson | tldr yes use `snap remove-user` | 17:59 |
| cachio | ijohnson, nice | 18:00 |
| cachio | I am updating the tests | 18:00 |
| ijohnson | great, let me know when there's something for me to review | 18:02 |
| === ijohnson is now known as ijohnson|lunch | ||
| cachio | ijohnson|lunch, sure, in few minutes it will be ready, I am still waiting for the tests | 18:11 |
| === ijohnson|lunch is now known as ijohnson | ||
| ijohnson | cachio: I see that 8212 failed on opensuse's repos being unavailable | 18:54 |
| ijohnson | cachio: do you want me to submit a PR moving opensuse to unstable ? | 18:54 |
| cachio | ijohnson, #8205 | 19:00 |
| mup | PR #8205: tests: just remove user when the system is not managed on create-user-2 test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8205> | 19:00 |
| cachio | ijohnson, trying once and then we try moving to unstable | 19:01 |
| ijohnson | Okay | 19:05 |
| ijohnson | My internet seems to have gone down just now | 19:05 |
| ijohnson | alright I'm back now, dns problem for some reason | 19:09 |
| ijohnson | cachio: approved 8205 for you (again) | 19:11 |
| pedronis | ijohnson: cmatsuoka: I submitted now a couple of reviews to PRs of yours that I failed before because of github having issues | 19:11 |
| ijohnson | pedronis: ack thanks I'll look now | 19:11 |
| cachio | ijohnson, thanks!!! | 19:18 |
| cmatsuoka | pedronis: ack, thanks | 19:30 |
| cachio | ijohnson, still failing on opensuse | 19:36 |
| cachio | ijohnson, do you want to move to unstable or I can do it | 19:37 |
| ijohnson | cachio: I can do it if you like | 19:37 |
| cachio | ijohnson, sure | 19:37 |
| cachio | I'll approve it | 19:37 |
| ijohnson | cachio: I see that opensuse 15.0 has `manual: true`, do you remember why that is there? | 19:39 |
| cachio | ijohnson, it is intentional | 19:39 |
| cachio | we are just testing on tumbleweed and leap 15.1 | 19:39 |
| ijohnson | cachio: https://github.com/snapcore/snapd/pull/8213 | 19:41 |
| mup | PR #8213: spread.yaml: mv opensuse 15.1 to unstable <Skip spread> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8213> | 19:41 |
| mup | PR snapd#8213 opened: spread.yaml: mv opensuse 15.1 to unstable <Skip spread> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8213> | 19:41 |
| ijohnson | cachio: are we good to merge that 8213 now then? | 19:58 |
| cachio | ijohnson, no | 19:58 |
| cachio | https://travis-ci.org/snapcore/snapd/jobs/655836451#L644 | 19:58 |
| cachio | tumbleweed is also failing | 19:59 |
| ijohnson | oh no :-( | 19:59 |
| cachio | we need to move both to unstable | 19:59 |
| zyga | perhaps merge one | 19:59 |
| ijohnson | I'll push an update to my PR and move tumbleweed there too | 19:59 |
| zyga | and open the next | 19:59 |
| ijohnson | cachio: then we merge my tumbelweed PR and you can merge master into your users PR? | 19:59 |
| cachio | yes | 20:00 |
| ijohnson | k | 20:01 |
| mup | PR snapd#8213 closed: spread.yaml: mv opensuse 15.1 to unstable <Skip spread> <⚠ Critical> <Created by anonymouse64> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8213> | 20:11 |
| cachio | ijohnson, merged and pushed my branch again | 20:12 |
| ijohnson | cachio: great, thanks | 20:12 |
| cachio | ijohnson, I hope this time it is green | 20:12 |
| ijohnson | me too :-) | 20:12 |
| mateuszm | Hi guys, are you knowledgeable about Ubuntu 20.04's apparent move from deb to snap for the Software Center, and snap to dev for gnome-{calculator,logs,characters}, by any chance? I had a surprise yesterday when I apt-get updated my 20.04 pre-release install | 20:13 |
| mvo | ijohnson, sergiusens : thanks so much for taking care of the test failures! | 20:14 |
| mateuszm | Basically, folks who have an up-to-date pre-release install are in the situation where they have two versions of each of the calculator, log viewer, and character apps: the snap version (old) and the deb version (new). I'm wondering if that means I have to manually uninstall the snap version? And reciprocally, if I have to manually install the snap | 20:17 |
| mateuszm | version of the Software Center (i.e. the snap store)? | 20:17 |
| mvo | mateuszm: best to ask the #ubuntu-desktop people about that, this channel is mostly about the development of snapd itself | 20:21 |
| mvo | (and sorry, but I have no real insights here :/ | 20:22 |
| mateuszm | mvo Ah great, OK, thanks a lot! | 20:23 |
| cachio | ijohnson, I'll be afk, I ned to go to the kinesiologist | 20:32 |
| ijohnson | cachio: ack I'll merge if your PR goes green / push updates as necessary | 20:33 |
| cachio | thanks | 20:33 |
| cachio | otherwise I'll do it once I'm back | 20:33 |
| mvo | ijohnson: please push a green master to all the 2.44 tagged PRs if you don't mind :) | 20:38 |
| ijohnson | mvo: sure | 20:39 |
| mvo | thank you! | 20:39 |
| ijohnson | have a nice evening mvo | 20:39 |
| mvo | ijohnson: have a good day too | 20:40 |
| * mvo waves | 20:40 | |
| ijohnson | cachio: just fyi the ubuntu spread test failed due to a unit test failure from pstolowski's thing that he's working on a fix for, so I restarted it, I think it should probably pass when we re-run it I think | 21:27 |
| === hggdh is now known as hggdh-msft | ||
| * zyga has more or less working session-tool, with lots of practical details right | 21:58 | |
| zyga | kind of late | 21:58 |
| zyga | let's move onto testing via spread | 21:58 |
| mup | PR snapd#8212 closed: tests: updating checks to new test account for snapd-test snaps <Simple 😃> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8212> | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!