| mup | Bug #1747794 opened: cannot resolve host name with avahi interface <Snappy:New> <https://launchpad.net/bugs/1747794> | 00:56 |
|---|---|---|
| mup | Bug #1702095 changed: snap enable removes complain for daemons <Snappy:Expired> <https://launchpad.net/bugs/1702095> | 04:18 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| mborzecki | morning | 06:18 |
| zyga | good morning | 06:29 |
| mborzecki | zyga: hey | 06:33 |
| zyga | -6 outside now | 06:42 |
| zyga | so pretty | 06:42 |
| zyga | coffee and back to spread | 06:49 |
| zyga | I wrote a new feature and a test together | 06:49 |
| zyga | need to split those out | 06:49 |
| mborzecki | hm tried to reproduce this https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894 but no luck, nothing 'hangs' | 07:11 |
| zyga | looking at that I wonder if the original deamon did something "fancy" that made it hang | 07:18 |
| zyga | like get stuck on a syscall or whatever | 07:18 |
| mborzecki | the next thing that happens after starting the services is running configuration hooks | 07:21 |
| mborzecki | wonder if he had any | 07:22 |
| mborzecki | oh | 07:25 |
| mborzecki | shit | 07:25 |
| zyga | oh? | 07:25 |
| zyga | did you find something nasty? | 07:25 |
| mborzecki | yeah, so whena snap is installed we run all the services | 07:25 |
| mborzecki | this one is 'oneshot' | 07:25 |
| zyga | so? | 07:27 |
| zyga | it should run and stop | 07:27 |
| mborzecki | hahaha | 07:28 |
| mborzecki | but it does not | 07:28 |
| zyga | is this a regression in 2.31? | 07:29 |
| zyga | (do we need rc4) or 2.31.1 | 07:29 |
| mborzecki | it's named usb_mount, suggesting that's it will mount a usb device, if there's none then it will apparently wait | 07:29 |
| zyga | oh | 07:29 |
| zyga | so oneshot services block until they exit? | 07:29 |
| mborzecki | so i made a simple service that loops infinitely, and it hangs 'Start snap "daemon-oneshot" (unset) services' | 07:29 |
| mborzecki | yeah | 07:29 |
| zyga | oh, wow | 07:29 |
| zyga | that's not great | 07:29 |
| mborzecki | we also probably shoulnd't start them when installing a snap | 07:30 |
| zyga | actually, what should happen for oneshot services isn't clear to me | 07:30 |
| zyga | who should start them? | 07:30 |
| zyga | the snap itself? | 07:30 |
| mborzecki | the way i used oneshot is either as a dependency before other service (eg. generate ssh keys) or as a response to something that happens (path conditions, or a template unit) | 07:32 |
| mborzecki | --no-block may be a reasonable workaround, but this doesn't change the fact that the service should not wait indefinitely | 08:06 |
| pstolowski | heyas! | 08:08 |
| mborzecki | pstolowski: morning | 08:09 |
| kalikiana | moin moin | 08:09 |
| mborzecki | everyone joining :) morning mvo & kalikiana | 08:10 |
| mvo | good morning mborzecki | 08:10 |
| mvo | hey kalikiana | 08:10 |
| zyga | hey guys | 08:21 |
| zyga | mborzecki is the service bug a regression? | 08:21 |
| zyga | if so I bet mvo will want to know | 08:21 |
| mvo | zyga: I do want to know | 08:21 |
| mborzecki | mvo: https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894 | 08:22 |
| mborzecki | zyga: not a regression, technically it was there before | 08:22 |
| mvo | mborzecki: nice find | 08:25 |
| mborzecki | mvo: what happens is that if a oneshot service hangs/loops/does not termine, snapd will be stuck in start-snap-services task | 08:26 |
| mborzecki | s/termine/terminate/ | 08:26 |
| mvo | mborzecki: yeah, I was just readoing it | 08:26 |
| mvo | mborzecki: thats really unfortunate, I wonder if --no-block in systemctl might help | 08:27 |
| mborzecki | i'm looking at some options, like not starting oneshot tasks, adding --no-block (complicates systemd interface internally), adding TimeoutSec= in *.service (the timeout is fairly arbitrary and probably incorrect in some edge cases) | 08:28 |
| mvo | mborzecki: thanks for looking into this | 08:28 |
| mborzecki | mvo: frankly i'm leaning towards not starting oneshot services at all | 08:29 |
| mup | PR snapd#4621 closed: tests: skip alsa interface test when the system does not have any audio devices <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4621> | 08:29 |
| mup | PR snapd#4618 closed: tests: new snaps to test installs nightly <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4618> | 08:30 |
| === mthaddon` is now known as mthaddon | ||
| * zyga iterates on layouts and testing | 08:38 | |
| zyga | next up: refreshes that change layouts :) | 08:38 |
| zyga | *that* will be interesting | 08:38 |
| zyga | jamesh, hey, good morning | 08:41 |
| zyga | did you guys watch the falcon heavy launch yesterday? | 08:55 |
| mvo | zyga: yeah, quite spectacular. | 08:58 |
| zyga | I watched it by accident (I got a tip from kissiel) and wow, it was crazy, like watching a sci-fi movie | 08:59 |
| zyga | *live* | 08:59 |
| kissiel | :) | 08:59 |
| * zyga found some bugs in layout validation | 08:59 | |
| zyga | time to fix that | 08:59 |
| zyga | (too conservative) | 08:59 |
| zyga | nothing to worry about | 08:59 |
| zyga | mvo remember before we had spread? | 09:00 |
| zyga | it was like driving blind | 09:00 |
| mvo | zyga: I don't, my therapist helped me with that | 09:00 |
| * mvo pats the emacs therapist | 09:00 | |
| zyga | haha, good one | 09:00 |
| mvo | zyga: but indeed, totally agree | 09:01 |
| zyga | -5C outside, brrr | 09:01 |
| zyga | let's rethink that validator | 09:01 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#4623 opened: wrappers: do not start oneshot services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4623> | 09:23 |
| mborzecki | there's probably a spread test that will fail as a result of ^^ | 09:23 |
| * kalikiana coffeeeeee | 09:29 | |
| * zyga notices a movie crew outside his house | 09:30 | |
| zyga | kalikiana khaaaaaaan | 09:30 |
| zyga | there's a fake police car, fake news crew and fake people doing an interview | 09:31 |
| zyga | they use this site for some sitcom or other local TV thing once in a while | 09:31 |
| zyga | I wonder if I was in the shot, helping my daughter go to school | 09:31 |
| zyga | they didn't stop filming, maybe just a dry run | 09:31 |
| mvo | zyga: they are shooting a new sitcom - the big O theory - guess who the starts will be ? | 09:32 |
| zyga | haha :) | 09:32 |
| * mvo stops being silly and makes more tea | 09:33 | |
| zyga | is it also freezing for you mvo? | 09:33 |
| Chipaca | zyga: a little bit of snow fell this morning, ~5am | 09:38 |
| Chipaca | zyga: it's just sitting on the glass patio table, pondering life | 09:38 |
| zyga | melting away | 09:38 |
| zyga | like all of us | 09:38 |
| zyga | ;-) | 09:38 |
| Chipaca | no, actually | 09:38 |
| * zyga is in a good mood today | 09:38 | |
| Chipaca | zyga: your comment on my MatchCounter PR, could you expand it? | 09:39 |
| zyga | yeah, let me pull the diff tab | 09:39 |
| zyga | w.partial is empty | 09:39 |
| zyga | oh | 09:39 |
| zyga | man | 09:39 |
| zyga | I should not comment late at night | 09:39 |
| === chihchun is now known as chihchun_afk | ||
| zyga | nothing :) | 09:39 |
| zyga | I got rid of it | 09:40 |
| zyga | I somehow read that bytes.IndexByte() was called on w.partial | 09:40 |
| Chipaca | ueh ueh ueh, or something | 09:40 |
| mvo | zyga: its around 0 here | 09:40 |
| mvo | Chipaca: I guess you want to rebase my PR on top of this ;)? | 09:41 |
| Chipaca | zyga: https://i.imgur.com/Wcj6Swd.png | 09:43 |
| Chipaca | zyga: censorship! | 09:43 |
| Chipaca | :-) | 09:43 |
| zyga | oh? | 09:43 |
| zyga | I didn't delete your comment, I just deleted mine | 09:43 |
| zyga | I guess it killed your comment that wasn't loaded in my tab | 09:43 |
| Chipaca | mvo: more like: if you think it'll improve things, I can push a commit to your PR that uses this | 09:44 |
| mvo | Chipaca: its more general than mine, so +1 for this | 09:44 |
| Chipaca | mvo: ok, i'll push a commit to yours as soon as this lands | 09:44 |
| mvo | ta | 09:44 |
| mvo | that was a subtle clue that I should review it, right? | 09:45 |
| Chipaca | today I'm going into london, so a lot of time on public transport with little/bad connectivity, and I'm going to miss the standup | 09:45 |
| Chipaca | mvo: not at all | 09:45 |
| Chipaca | mvo: I mean, I wasn't subtle | 09:45 |
| Chipaca | :-D | 09:45 |
| mvo | lol | 09:45 |
| * mvo hugs Chipaca | 09:46 | |
| mborzecki | Chipaca: i have mixed feelings about 4632 too, idk, maybe it'd be best to leave the code as it is now, this guys code is probably wrong | 09:46 |
| Chipaca | mborzecki: FWIW i think we _should_ expose startup timeout, and conditionals, and have some extra magic for oneshots where we don't hang but still handle it, but it's a lot of work for something that, in this case, is probably dev error | 09:47 |
| Chipaca | I mean: why would a mount process hang | 09:47 |
| mborzecki | Chipaca: otoh, it's not really possible to interrupt this, ^C has no effect | 09:47 |
| Chipaca | mborzecki: in that abort doesn't abort? | 09:48 |
| mborzecki | Chipaca: yeah, i have a snap with an app that loops inside and i cannot abort the installation | 09:48 |
| Chipaca | mborzecki: we probably want to make systemctl use the brand new osutil.RunWithContext :-) | 09:48 |
| Chipaca | and bubble context into systemd | 09:48 |
| Chipaca | OTOH it might be better to make start use --no-block and then poll, like we do with stop | 09:49 |
| kalikiana | zyga: what are fake people? robots? ;-) | 09:49 |
| Chipaca | (i mean, without it, systemctl is doing the polling) | 09:49 |
| zyga | kalikiana just actors ;) | 09:49 |
| Chipaca | kalikiana: kardashains | 09:49 |
| kalikiana | lol | 09:49 |
| mborzecki | Chipaca: hmm right, let me take another look at the code | 09:50 |
| mborzecki | s/kardashians/osbournes/ | 09:50 |
| Chipaca | mborzecki: OTO²H context + (no-block + poll) is probably the real winner | 09:50 |
| Chipaca | mborzecki: OTO³H probably a lot of work | 09:51 |
| mborzecki | yeah, sounds backlog worthy | 09:51 |
| Chipaca | mborzecki: OTO⁴H I'm running out of superscripts | 09:51 |
| * sparkiegeek wonders how many hands Chipaca has | 09:51 | |
| Chipaca | mborzecki: OTO⁽ⁿ⁺¹⁾H, you'll never know | 09:52 |
| mborzecki | Chipaca: RunWithContext was merged right? | 09:52 |
| Chipaca | mborzecki: yes | 09:52 |
| Chipaca | mborzecki: but killing systemctl might not dtrt wrt systemd, which is why i said it might be better to do the more detailed work | 09:53 |
| Chipaca | but you could use it as a base, or phase 1, or sth | 09:53 |
| * Chipaca gives up, and starts getting ready to leave | 09:53 | |
| mborzecki | probably better than stalling | 09:53 |
| Chipaca | mborzecki: first, see if killing systemctl stops the eternal oneshot | 09:54 |
| mborzecki | 'eternal oneshot' | 09:54 |
| Chipaca | if so then robert is your mother's brother | 09:54 |
| Chipaca | or something | 09:54 |
| mborzecki | Chipaca: right, it did, the unit was stopped | 09:55 |
| Chipaca | perfect then :-) | 09:56 |
| zyga | trivial PR for someone, pretty please | 09:56 |
| zyga | 4624 | 09:57 |
| mup | PR snapd#4624 opened: snap: apply some golint suggestions <Created by zyga> <https://github.com/snapcore/snapd/pull/4624> | 09:57 |
| Chipaca | mmm, golint fixes | 09:58 |
| Chipaca | zyga: ValidAppName returns true if if given string is a valid application name. | 09:58 |
| Chipaca | zyga: and if if not? | 09:59 |
| zyga | well, it returns false ;) | 09:59 |
| Chipaca | zyga: I mean, too many ifs | 09:59 |
| zyga | oh | 09:59 |
| zyga | I see now | 09:59 |
| zyga | thanks | 09:59 |
| Chipaca | this isn't me getting into the "oh it should be whether" thing | 10:00 |
| Chipaca | which I have learned is pedantic :-) | 10:00 |
| zyga | another good point | 10:00 |
| zyga | I never write that word | 10:00 |
| zyga | because I'm always afraid I will say weather | 10:00 |
| zyga | or actually, write weather | 10:00 |
| zyga | if if you see what I mean | 10:00 |
| Chipaca | zyga: maybe it's just a tsundere comment | 10:00 |
| zyga | a what comment? | 10:01 |
| mup | PR snapd#4625 opened: daemon: remove redundant UserOK markings from api commands <Created by mvo5> <https://github.com/snapcore/snapd/pull/4625> | 10:01 |
| mvo | Chipaca: ^- is what we talked about last night | 10:01 |
| Chipaca | zyga: maybe you don't want to know | 10:01 |
| Chipaca | mvo: ack | 10:01 |
| * Chipaca looks | 10:01 | |
| mvo | Chipaca: I hope this makes things for my future self easier to grok | 10:01 |
| Chipaca | mvo: when the mythical "no more features, just fixes and cleanup" year arrives, I grab "rewrite daemon" | 10:03 |
| Chipaca | anyhow, I need to run | 10:03 |
| zyga | o/ | 10:03 |
| Chipaca | telegram is your best bet to reach me (or whatsapp fwiw) | 10:04 |
| zyga | mvo "what the canAccess() policy." ... what? | 10:04 |
| mvo | Chipaca: see you | 10:04 |
| mvo | zyga: not sure I follow, did I write something in an unclear way? | 10:05 |
| zyga | I think it ends abruptly | 10:06 |
| zyga | "what the canAccess() policy means." maybe? | 10:06 |
| pedronis | unless it was meant to be "polices" (the verb) | 10:07 |
| mup | PR snapd#4626 opened: daemon: improve ucrednet code for the snap.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/4626> | 10:08 |
| pedronis | ah, just the "what" is too much | 10:08 |
| pstolowski | mvo, hey, #4579 can land, right? it got +1 from security in the old PR? | 10:10 |
| mup | PR #4579: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4579> | 10:10 |
| mvo | pstolowski: I think so, but zyga asked for a tweak (which I can do in a followup if this helps you) | 10:13 |
| zyga | mvo can be in a follow-up yeah | 10:13 |
| zyga | mvo especially since there's a new function to extract out of that logic | 10:13 |
| mvo | pstolowski, zyga I work on the followup and then work on the other two (smaller) ones | 10:14 |
| pstolowski | mvo, no, it doesn't change much for me (need other PRs as well), it's just 1 less to look after ;) | 10:14 |
| mup | PR snapd#4579 closed: many: add interfaces.SystemKey() helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4579> | 10:14 |
| sparkiegeek | FYI: the snappy store is in a maintenance window until 11:00 UTC (see https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866 ) | 10:15 |
| zyga | oh, thanks for the heads up sparkiegeek | 10:15 |
| mvo | zyga: hm, the release/apparmor.go code is doing the inverse of what I need, so I guess I just move my code there? or am I missing something? | 10:18 |
| zyga | yes | 10:18 |
| zyga | just move it there and perhaps reuse your code in the computation of what was already there, if feasible | 10:18 |
| zyga | hmm, store is doing 503 | 10:19 |
| zyga | is that expected sparkiegeek | 10:19 |
| sparkiegeek | zyga: yes, but it should be coming back up now | 10:21 |
| mup | PR snapd#4627 opened: release, interfaces: add new release.AppArmorFeatures helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4627> | 10:36 |
| === mborzeck1 is now known as mborzecki | ||
| mborzecki | pstolowski: left you a comment about truncation, feel free to ignore it, i think it would complicate the internals a bit too much | 10:37 |
| zyga | mvo 4627 is almost good | 10:40 |
| pstolowski | mborzecki, thx, will check | 10:40 |
| mup | PR snapd#4623 closed: wrappers: do not start oneshot services <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4623> | 10:45 |
| zyga | whee | 10:46 |
| zyga | spread now passes | 10:46 |
| zyga | ok, let's upstream the changes and work on hardening so that jdstrand doesn't turn grey on release day | 10:47 |
| sparkiegeek | store maintenance is now over, please report any issues on the forum thread: https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866 | 10:52 |
| mup | PR snapd#4613 closed: release: snapd 2.31 <Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4613> | 11:26 |
| zyga | woot :) | 11:26 |
| cachio_ | mvo, hey, we are ready to go to candidate | 11:26 |
| zyga | so no more RCs? :) | 11:27 |
| cachio_ | no | 11:27 |
| mvo | cachio_: yes | 11:27 |
| mvo | cachio_: actually, give me ~20min to check the autopkgtest results on bionic | 11:28 |
| cachio_ | mvo, sure | 11:28 |
| mvo | cachio_: if these are bad we *migth* need a .1 | 11:28 |
| mborzecki | uhhn the changes allwoing cancelling of systemctl start are ugly | 11:29 |
| mvo | cachio_: looks like we do have some issues in autopkgtest due to the different environment. oh well. | 11:30 |
| cachio_ | mvo, which is the link? | 11:30 |
| cachio_ | mvo, could I take a look? | 11:31 |
| mvo | cachio_: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd and follow the bionic links | 11:31 |
| mvo | cachio_: one strange one is unit test for TestDoREquestSerialErrorsOnNoHost | 11:31 |
| mvo | cachio_: but it looks like a random assortion | 11:31 |
| cachio_ | mvo, I see that a failure in the interfaces-timeserver-control is breaking the whole suite | 11:35 |
| cachio_ | for amd64 | 11:35 |
| mvo | cachio_: yeah, I have not looked into the details yet but it seems there are some failures we need to look at :/ | 11:36 |
| mvo | cachio_: slightly annoying that its so hard to test autopkgtest for real | 11:36 |
| mup | PR snapd#4628 opened: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4628> | 11:38 |
| mvo | cachio_: some is rather trivial like -^ | 11:39 |
| cachio_ | mvo, yes, I'll work on that | 11:39 |
| mvo | cachio_: thanks | 11:40 |
| mvo | zyga: looks like we need an s390x build for snapd-hacker-toolbelt | 11:40 |
| mvo | cachio_: and one for test-snapd-kernel-module-consumer for s390x | 11:40 |
| mvo | cachio_: but I guess we should focus on amd64/i386 first | 11:40 |
| cachio_ | mvo, yes, agree | 11:41 |
| xnox | mvo, isn't it nice, that s390x is no longer a restricted arch and one can just tick the tickbox for it ;-) | 11:41 |
| zyga | mvo aha | 11:41 |
| zyga | mvo in a moment, I'm busy for 15 minutes | 11:41 |
| cachio_ | mvo, not sure if we are able to create a bionic image in linode | 11:41 |
| mvo | xnox: it is! | 11:42 |
| cachio_ | as it is not stable | 11:42 |
| mvo | cachio_: I don't think this will help us much | 11:42 |
| mvo | cachio_: my feeling is that the images are not the problem | 11:42 |
| mvo | cachio_: its that the autopkgtest env is more restricted | 11:42 |
| cachio_ | mvo, ah, ok | 11:42 |
| mvo | cachio_: for whatever reason | 11:42 |
| mvo | cachio_: it really should not be, we run in a full VM and added hints that we mess the host up but e.g. timezone setting is denied | 11:43 |
| pstolowski | mvo, thanks for 4627! | 11:43 |
| cachio_ | mvo, how do you do to trigger the tests? | 11:43 |
| mvo | cachio_: or maybe it is actually bionic, might be easiest to just run against qemu to see if something in e.g. systemd failed | 11:43 |
| mvo | cachio_: s/failed/changed/ | 11:43 |
| mvo | cachio_: thats the sad part - to trigger the tests I need to upload the package to the real archive | 11:44 |
| mvo | cachio_: this is my grief with adt - there is no easy way to test against e.g. a ppa | 11:44 |
| cachio_ | mvo, ok, I'll start runnig in qemu and then if we have a 100% we can go forward | 11:45 |
| mvo | cachio_: great, I keen to know if e.g. the timezone failure is related to bionic or adt | 11:45 |
| cachio_ | mvo, so, should I promote to candidate? | 11:48 |
| cachio_ | mvo, I can do it after the standup | 11:49 |
| cachio_ | mvo, I have a doc appointment now, I'll be bac for the standup | 11:51 |
| * cachio_ afk | 11:52 | |
| zyga | mvo sorry I'm back now | 11:58 |
| zyga | I just sold my x250 | 11:58 |
| zyga | so, about that build for s390x | 11:58 |
| zyga | mvo, I wonder how we can build one, will snapcraft.io do it? | 12:02 |
| mvo | zyga: launchpad can do it, if you have snap building enabled on it | 12:03 |
| mvo | zyga: then you can just click on s390x as an arch | 12:03 |
| mvo | pstolowski: the next one (re-generate on system-key change) will arrive as soon as 4627 is green | 12:03 |
| pstolowski | mvo, great! | 12:04 |
| zyga | mvo, let me look, I honestly don't remember how I built it | 12:04 |
| mvo | pstolowski: then i think its just #3471 and its done | 12:04 |
| mup | PR #3471: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3471> | 12:04 |
| mvo | pstolowski: not sure if you need this piece for your work though | 12:04 |
| pstolowski | cool | 12:04 |
| zyga | ah, it's on launchpad allright | 12:04 |
| zyga | mvo: shall I just rebuild for all arches? | 12:04 |
| mvo | zyga: +1 | 12:05 |
| pstolowski | mvo, ah, if this is only about snap-run then no | 12:05 |
| zyga | mvo, man, I can even build for powerpc :) | 12:05 |
| zyga | would that work? | 12:05 |
| zyga | or is it just fake? | 12:05 |
| mvo | zyga: I think it will work | 12:06 |
| mvo | zyga: we could even build a core for powerpc now if that is fully enabled | 12:07 |
| zyga | https://launchpad.net/~zyga/+snap/snapd-hacker-toolbelt | 12:07 |
| zyga | builds are pending | 12:07 |
| zyga | that will be an interesting refresh :) | 12:11 |
| zyga | I should adopt one of the new features in snapcraft and generate version dynamically | 12:12 |
| * pstolowski lunch | 12:13 | |
| zyga | mvo all done | 12:14 |
| zyga | wow, | 12:14 |
| mup | PR snapd#4624 closed: snap: apply some golint suggestions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4624> | 12:17 |
| * zyga re-reads 4622 | 12:20 | |
| === jospoortvliet is now known as jos | ||
| === jos is now known as jospoortvliet | ||
| mup | PR snapd#4627 closed: release, interfaces: add new release.AppArmorFeatures helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4627> | 13:00 |
| mup | PR snapd#4629 opened: ifacestate: only rewrite security profiles if the system-key changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/4629> | 13:04 |
| mup | PR snapd#4630 opened: snap: sort layout elements before validating <Created by zyga> <https://github.com/snapcore/snapd/pull/4630> | 13:12 |
| zyga | + systemctl stop snapd.service snapd.socket | 13:25 |
| zyga | Job for snapd.socket canceled. | 13:25 |
| zyga | I wonder what this was, is this something that we fixed in another context before? | 13:25 |
| zyga | ^ cachio_ (perhaps you remember) | 13:25 |
| zyga | mvo ^ trivial 4630 | 13:30 |
| mvo | zyga: ta! | 13:30 |
| zyga | I have one more on top, also trivial but separate issue | 13:31 |
| zyga | jdstrand 4631 is super trivial but for you | 13:32 |
| mup | PR snapd#4631 opened: cmd/snap-confine: allow mounting anywhere, effectively <Created by zyga> <https://github.com/snapcore/snapd/pull/4631> | 13:33 |
| zyga | jdstrand this is a side effect of a fully working spread test, which is coming up in two branches from now | 13:33 |
| zyga | once the test lands I will start pushing hardening for snap-update-ns, knowing that I didn't break anything | 13:34 |
| mup | PR snapd#4626 closed: daemon: improve ucrednet code for the snap.socket <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4626> | 13:53 |
| diddledan | what's a "gated snap"? | 13:56 |
| zyga | diddledan snaps can use gating to ensure QA constraints | 13:57 |
| * diddledan read the snapcraft --help and found `snapcraft gated` and `snapcraft validate` | 13:57 | |
| zyga | you can use it to ensure that refreshes will happen only after you sign that off as not breaking your snap | 13:57 |
| diddledan | so what's "gating"? | 13:57 |
| zyga | so. you can, for example, have a super important snap that you want to support 24/7 | 13:58 |
| zyga | gating is the whole process | 13:58 |
| zyga | and you control your snap so that part is easy | 13:58 |
| zyga | but the core snap can introduce bugs so you want to have a way to validate them | 13:58 |
| zyga | if you have validation control on the core snap you can say that the core snap will refresh only if you say that your snap works with a given revision of the core snap | 13:59 |
| zyga | (core can by any other snap but it's typically core) | 13:59 |
| zyga | obviously this only applies if your snap is installed | 13:59 |
| zyga | it's a way to check that you can conform to your contractual agreements most likely | 13:59 |
| zyga | where you can check each new core revision and "ack" it | 13:59 |
| zyga | (for the purpose of your snap) | 13:59 |
| zyga | does that make sense? | 13:59 |
| diddledan | no | 13:59 |
| diddledan | clear as mud :-p | 14:00 |
| zyga | can you be more specific? | 14:00 |
| diddledan | I'm just thick | 14:00 |
| zyga | I can give you an example if that helps | 14:00 |
| diddledan | "Get the list of snaps and revisions gating a snap." means nothing to me | 14:01 |
| zyga | gets the list of snaps and revisions that _block the snap from refreshing_ | 14:01 |
| diddledan | can we change the verbiage then? | 14:01 |
| zyga | change what, sorry? | 14:02 |
| diddledan | "gating" is a term which requires intimate knowledge of what it means to "gate" | 14:02 |
| zyga | yes, we use many words that require one specific knowledge | 14:02 |
| diddledan | "block", "blocks" and "blocking" are much more appropriate words if that's what is happening | 14:02 |
| zyga | but I think that's unavoidable and not a problem as long as they are clearly explained somewhere accessible | 14:02 |
| zyga | it's not just blocking, it's more subtle | 14:03 |
| diddledan | ... which they're not (explained somewhere accessible) | 14:03 |
| zyga | the users can override that | 14:03 |
| zyga | diddledan please raised this with kalikiana as I think this is a snapcraft documentation | 14:03 |
| mup | PR snapd#4632 opened: Fixing denial for when using avahi-observe slot <Created by kubiko> <https://github.com/snapcore/snapd/pull/4632> | 14:04 |
| * zyga -> lunch | 14:06 | |
| kalikiana | diddledan: It's not really explained there, that's true. Would you mind filing a bug for it? | 14:09 |
| zyga | jdstrand thank you, I replied to your question if you want to look at why I needed this | 14:20 |
| mup | PR snapd#4631 closed: cmd/snap-confine: allow mounting anywhere, effectively <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4631> | 14:21 |
| * kalikiana hopping on a tram towards coffee shop for lunch, back in ~60min max | 14:35 | |
| mup | PR snapd#4628 closed: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4628> | 14:41 |
| mup | PR snapd#4633 opened: snap: introduce timer service data types and validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633> | 14:42 |
| zyga | mborzecki can you please look at 4630, it's tiny and it's just adding sorting + tests | 14:47 |
| mborzecki | looking | 14:47 |
| zyga | cool, thanks | 14:47 |
| * zyga looks at other PRs | 14:48 | |
| pedronis | mvo: cachio_: here are the failures for linode:ubuntu-16.04-64:tests/main/... with SPREAD_REMOTE_STORE=staging , I think most of them are missing snaps/old snap revisions, not sure about the core transition; canonical-livepatch and lxd we could skip though I think, the other it would be good to fix: https://pastebin.ubuntu.com/26534904/ | 14:48 |
| zyga | mborzecki you have a conflict on 4633 | 14:49 |
| zyga | and it looks like what I did, sorry | 14:50 |
| mvo | pedronis: I think core-transition, lxd, livepatch we should skip yes | 14:50 |
| jdstrand | zyga: /me nods | 14:50 |
| zyga | mvo do you think we could disable tests for core transition? | 14:50 |
| mvo | zyga: probably | 14:50 |
| zyga | jdstrand thanks for acking the dbus fix | 14:50 |
| zyga | mvo if you do 2.31.1 I would suggest cherry-picking 4632 | 14:51 |
| mvo | zyga: we do a .1 | 14:51 |
| zyga | I'll mark it | 14:51 |
| mvo | zyga: ta | 14:52 |
| mborzecki | zyga: ok if i rebase? | 14:52 |
| zyga | mborzecki quickly :) | 14:52 |
| mborzecki | haha ok | 14:53 |
| cachio__ | pedronis, ok, I'll take a look | 14:54 |
| mborzecki | zyga: pushed | 14:55 |
| mup | PR snapd#4605 closed: snap: detect unsquashfs write failures <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4605> | 14:59 |
| zyga | oh, kids home | 15:00 |
| zyga | brb | 15:00 |
| mvo | zyga: you reviewed 4491 earlier but did not do a +1 - did you forgot or was the review not complete? | 15:02 |
| zyga | checking | 15:04 |
| zyga | mvo I need to re-read that | 15:06 |
| mup | PR snapd#4634 opened: tests: check if snapd.socket is active before stoping it <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4634> | 15:10 |
| andyrock | mvo: I'm trying to allow store login in the installer. One possible solution would be to: | 15:16 |
| andyrock | 1) stop/disable snapd.service/snapd.socket (the one running in the live session) | 15:16 |
| andyrock | 2) manually start snapd inside the /target chroot | 15:16 |
| andyrock | 3) a client can now talk with the chrooted snapd through /run/snapd.socket | 15:16 |
| andyrock | Do you think that (1) and/or (2) could create any side effect? | 15:16 |
| zyga | andyrock: do you expect to be able to run snaps in the end? | 15:18 |
| zyga | andyrock I didn't check what would happen with chroot | 15:19 |
| zyga | probably it'd be okay | 15:19 |
| zyga | snapd has some logic to reassociate itself with the mount namespace of pid 1 | 15:19 |
| zyga | but since this is the same namespace, just different chroot, it should not trigger | 15:20 |
| andyrock | zyga: that's not necessary | 15:20 |
| andyrock | for livepatch we can actually enable it at first run without problems | 15:20 |
| andyrock | I just need to login into the store | 15:20 |
| andyrock | so that the state.json has the valid entries | 15:20 |
| andyrock | I need (1) otherwise the live-session-snapd will activate | 15:22 |
| mvo | andyrock: I don't see any immediate problem, give it a go | 15:25 |
| andyrock | thanks | 15:27 |
| zyga | mvo do you want me to cherry-pick 4632? | 15:34 |
| mup | PR snapd#4632 closed: Fixing denial for when using avahi-observe slot <Created by kubiko> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4632> | 15:35 |
| mvo | zyga: sure go for it | 15:39 |
| zyga | pushed | 15:43 |
| kalikiana | re | 15:47 |
| Chipaca | mvo: mborzecki: did either of you mean to +1 #4622 and didn't? | 15:49 |
| mup | PR #4622: strutil: introducing MatchCounter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4622> | 15:49 |
| Chipaca | or -1 or sth :-) | 15:50 |
| zyga | Chipaca +1 from me | 15:50 |
| zyga | though I didn't comment | 15:50 |
| zyga | let me | 15:50 |
| zyga | I read it a few times but I was in some wrong zone I guess | 15:50 |
| Chipaca | it's fiddly :-) | 15:50 |
| Chipaca | rather like round.Robin | 15:51 |
| Chipaca | :-) | 15:51 |
| zyga | hmmm | 15:54 |
| zyga | Chipaca so | 15:54 |
| zyga | do you need a flush? | 15:54 |
| zyga | on diff line 62 there | 15:54 |
| zyga | what guarantees that w.partial will be eventually inspected | 15:54 |
| Chipaca | zyga: it only matches full lines | 15:55 |
| Chipaca | zyga: either you wrote a full line, and got counted, or you didn't and it's in partial | 15:55 |
| Chipaca | \n is a flush, in that sense | 15:55 |
| zyga | mhm | 15:55 |
| Chipaca | to make it generic and not line-oriented a flush or something would be needed | 15:55 |
| zyga | okay | 15:56 |
| zyga | I think it's fine, YAGNI untill we need to do that | 15:56 |
| zyga | hmm | 15:56 |
| zyga | actually | 15:56 |
| zyga | you could use it without being line oriented | 15:56 |
| zyga | though I don't need that either | 15:56 |
| zyga | just wonder if it would be equally genreric | 15:56 |
| zyga | *generic | 15:56 |
| Chipaca | zyga: it very much uses the \n as the flusher | 15:57 |
| zyga | I'll let others comment | 15:57 |
| zyga | yeah | 15:57 |
| Chipaca | so yes you can use it, but it'd be unpredictable | 15:57 |
| zyga | regexpes are hard :) | 15:57 |
| Chipaca | and that :-) | 15:57 |
| zyga | it could compute the derivative of the re based on the partial input | 15:57 |
| zyga | and reset the re when it is empty | 15:57 |
| zyga | not needed | 15:57 |
| zyga | ;) | 15:57 |
| Chipaca | zyga: OTOH, instead of w.Flush() do w.Write([]byte{'\n'}) :-) | 15:59 |
| Chipaca | zyga: a more general thing would have two regexps (or deduce one from the other but that's Hard), one for matching, one for deciding whether to keep a chunk | 16:00 |
| Chipaca | eh | 16:01 |
| zyga | I think you can just use one RE and feed it incrementally (computing the derivative) | 16:01 |
| zyga | though I haven't seen any stdlib implementation that does that | 16:01 |
| zyga | essentially streaming | 16:01 |
| Chipaca | it'd require the regexp be front-anchored though, i think | 16:02 |
| Chipaca | i mean, the regexp for the sqlite failures is literally `.*[Ff]ailed.*` | 16:02 |
| zyga | mmmm | 16:03 |
| Chipaca | (it could be made to be `.*\b[Ff]ailed\b.*` for more nitpickiness) | 16:03 |
| zyga | I don't think it would, why would it? | 16:03 |
| zyga | derivative is a generic operation | 16:03 |
| Chipaca | zyga: because as soon as it starts with .*, you can't decide ahead of time | 16:04 |
| Chipaca | the answer always is 'yes this might match' | 16:04 |
| zyga | the derivative of ".*" over any character is ".*" | 16:05 |
| Chipaca | (aside: I'd love to understand why it's called the derivative) | 16:06 |
| zyga | but ".*foo.*" over "f" is "oo.*|.*foo.*" (probably) | 16:06 |
| zyga | dunno, you can ask the inventor | 16:06 |
| zyga | he's still alive | 16:06 |
| Chipaca | 82 and at princeton, huh | 16:07 |
| * zyga reads that page again | 16:07 | |
| zyga | https://en.wikipedia.org/wiki/Brzozowski_derivative | 16:07 |
| Chipaca | zyga: but, er, i'm not sure how the derivative would let you decide whether to discard it early | 16:07 |
| zyga | I think the re will effectively remember what you threw at it | 16:09 |
| Chipaca | ahhh | 16:12 |
| Chipaca | I'd misunderstood :-) | 16:12 |
| * Chipaca reading pdf | 16:12 | |
| Chipaca | Suppose we are given an RE r and a string u and we want to determine if u ∈ L[[r]]. We have u ∈ L[[r]] if, and only if, ε ∈ L[[∂u r]], which is true exactly when ε = ν(∂u r). Combining this fact with the definition of ∂u leads to an algorithm for testing if u ∈ L[[r]]. | 16:13 |
| * Chipaca puts pdf down | 16:13 | |
| zyga | Chipaca always read the conclusion first | 16:18 |
| zyga | then the abstract | 16:18 |
| zyga | then the rest | 16:18 |
| zyga | Chipaca I have a problem, wondering if I solved it right | 16:19 |
| zyga | https://github.com/zyga/snapd/commit/2784dc9bed05c9afb06ecbcec43328b61563c125 | 16:19 |
| Chipaca | zyga: am I looking at the problem, or the solution? :-) | 16:20 |
| zyga | the solution | 16:21 |
| Chipaca | zyga: ok tell me about the problem | 16:22 |
| Chipaca | zyga: or is that what's in the commit message? | 16:23 |
| zyga | yeah, that | 16:23 |
| zyga | feels hackish | 16:23 |
| zyga | maybe correct but hackish | 16:24 |
| Chipaca | zyga: at what point are these paths getting cleaned? | 16:24 |
| zyga | they are not cleaned, they are verified to be clean | 16:25 |
| zyga | it's on line 468 in the diff context (left hand side) | 16:25 |
| zyga | isAbsAndClean | 16:25 |
| Chipaca | zyga: right, so, filepath.Clean drops trailing /s (except for root) | 16:26 |
| Chipaca | that is, filepath.Clean("/foo/") is "/foo" | 16:27 |
| zyga | yes, right | 16:27 |
| zyga | we require that (and check for it) | 16:27 |
| Chipaca | ok | 16:27 |
| zyga | and then for directories we slam that "/" at the end | 16:27 |
| zyga | and where "for directories" I mean for tmpfs mounts and for non-file bind mounts | 16:27 |
| Chipaca | zyga: then why the check for trailing /s in effectivePath? | 16:27 |
| zyga | ah, good question | 16:28 |
| zyga | in case $SNAP expands to /snap/core/123/ | 16:28 |
| zyga | vs 123 | 16:28 |
| zyga | I just didn't want to be fragile there | 16:28 |
| Chipaca | ok | 16:30 |
| Chipaca | zyga: i wasn't concerned about being defensive, i was concerned about a muddled "clean filepath" barrier | 16:30 |
| Chipaca | OTOH I suspect whatever expands $SNAP should be cleaning it as well | 16:31 |
| zyga | mmm | 16:31 |
| zyga | I'm not cleaning there | 16:31 |
| zyga | yeah | 16:31 |
| zyga | separate patch, let's see it | 16:31 |
| zyga | done now | 16:32 |
| Chipaca | zyga: isn't this blocking a file /foo/bar if /foo/bartholomew is in the blacklist? | 16:32 |
| zyga | aha, indeed | 16:33 |
| zyga | hmm hmm :) | 16:33 |
| zyga | first, let's add a test so that I know it's broken | 16:33 |
| Chipaca | zyga: ExpandSnapVariables does clean its returns fwiw (maybe it should document this) | 16:34 |
| zyga | it does? | 16:35 |
| zyga | I tweaked it to do it now | 16:35 |
| zyga | or are you saying that os.Expand cleans | 16:35 |
| Chipaca | zyga: I'm saying it returns things that are the result of filepath.Join | 16:35 |
| zyga | as for the /foobarthomesomething, we could check for prefix if the blacklist item ends with / | 16:35 |
| Chipaca | zyga: and filepath.Join is documented as cleaning its result | 16:35 |
| zyga | and check for equaility otherwise | 16:35 |
| zyga | aah | 16:35 |
| Chipaca | zyga: would it be hard to keep files and dirs separate? | 16:36 |
| zyga | not sure I know how | 16:36 |
| zyga | can you be more specific? | 16:36 |
| Chipaca | zyga: have two blacklists, and have effectivePath return whether it's one or the other as a bool? | 16:37 |
| zyga | hmm | 16:37 |
| zyga | but I'd have to check the directory blacklist for files as well | 16:37 |
| zyga | if /foo is a tmpfs mount then I must reject /foo/bar | 16:37 |
| zyga | even if /foo/bar is a file bind mount | 16:38 |
| Chipaca | zyga: hmm | 16:38 |
| Chipaca | zyga: another option is for effectivePath to return interfacy things, and use separate concrete classes for one and t'other | 16:39 |
| Chipaca | i'm not sure i'm communicating sense | 16:39 |
| zyga | such as IsBlacklisted() os something | 16:39 |
| zyga | yeah, that would work | 16:39 |
| zyga | I mean, I'd still check the same thing but it might be less magic | 16:39 |
| Chipaca | zyga: it'd keep the / fiddliness isolated | 16:39 |
| Chipaca | zyga: the blacklist check would be 'for interfacyThing in blacklist: interfacyThing.frobbles(otherInterfacyThing) | 16:40 |
| Chipaca | or sth | 16:40 |
| zyga | yeah | 16:40 |
| zyga | thank you for spotting the bug :) | 16:41 |
| Chipaca | heh, np | 16:41 |
| zyga | https://github.com/snapcore/snapd/pull/4633 needs a 2nd review | 16:43 |
| mup | PR #4633: snap: introduce timer service data types and validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633> | 16:43 |
| mup | PR snapd#4622 closed: strutil: introducing MatchCounter <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4622> | 16:43 |
| Chipaca | zyga: tea, and i'll look at it | 16:43 |
| zyga | ha | 16:43 |
| zyga | I found my old tea | 16:43 |
| zyga | from yesterday evening | 16:43 |
| zyga | it has rum in it :) | 16:43 |
| Chipaca | sadly i have no rum (and it's a little early) | 16:43 |
| Chipaca | best i can do is port | 16:44 |
| Chipaca | but that doesn't sound like it'd work | 16:44 |
| ikey | see also https://www.youtube.com/watch?v=JImcvtJzIK8 | 16:44 |
| zyga | hehe, someone is triggered on rum :D | 16:45 |
| zyga | so | 16:46 |
| zyga | the travis log page officially sucks | 16:46 |
| zyga | it's horrible | 16:46 |
| zyga | it's so slow an iframe would be a godsend | 16:46 |
| zyga | and it's forcibly loaded when all I want to do is to hit "retry" | 16:46 |
| zyga | Chipaca I wrote the dumb version and I'll rebase and work on the smarter version next | 17:10 |
| Chipaca | mvo: you around? | 17:16 |
| mvo | Chipaca: ish - what can I do? | 17:20 |
| Saviq | niemeyer: hey, a lot of our builds started failing over the past couple of days, it's usually a single run that times out on travis because the task seems stuck at updating apt (https://travis-ci.org/MirServer/mir/builds/338519402) - I tried enabling debugging from spread, but travis didn't like the amount of logging (https://travis-ci.org/MirServer/mir/builds/338550499) | 17:20 |
| Chipaca | mvo: i'm tweaking the error output of unsquashfsStderrWriter, thought I'd check with you first | 17:20 |
| Saviq | niemeyer: any idea how to proceed? | 17:20 |
| Chipaca | Saviq: disable ipv6? | 17:20 |
| Chipaca | at a guess | 17:20 |
| * Saviq raises brow | 17:21 | |
| Chipaca | Saviq: we had a lot of hangs in linode during apt update with ipv6 enabled | 17:21 |
| Chipaca | Saviq: seems to be a problem with talking with whatever the mirror was? cachio__ might know more | 17:21 |
| Saviq | interesting! | 17:22 |
| zyga | jhodapp hey | 17:31 |
| jhodapp | zyga, hey there | 17:32 |
| mvo | Chipaca: sure, tweaking sound sgood | 17:33 |
| Chipaca | mvo: any rationale for it being 10 failures long, for example? it seems to result in a rather long message :-) | 17:34 |
| zyga | man, travis doesn't love me | 17:34 |
| mvo | Chipaca: no good reason, 4 is probably equally fine | 17:36 |
| Chipaca | mvo: perfect :-D | 17:36 |
| mvo | Chipaca: or 3 | 17:37 |
| mvo | Chipaca: I just think too little is not ideal as we really have no idea | 17:37 |
| Chipaca | mvo: are they always in groups of 3? | 17:37 |
| Chipaca | mvo: otherwise, 4 seems better | 17:37 |
| mvo | Chipaca: I need to look, I suspect not | 17:37 |
| mvo | Chipaca: gtg, but will read backlog | 17:38 |
| Chipaca | mvo: ok, if you could at some point, it can be part of your review of this ;-) | 17:38 |
| * Chipaca hugs mvo | 17:38 | |
| mvo | Chipaca: sure | 17:38 |
| * mvo hugs Chipaca and vanishes | 17:38 | |
| niemeyer | Saviq: That timeout on apt is usually associated with IPv6 | 17:40 |
| niemeyer | Saviq: Disable IPv6 on the prepare script before trying to use apt and it should work | 17:40 |
| Chipaca | Saviq: https://github.com/snapcore/snapd/blob/master/spread.yaml#L294 | 17:41 |
| Saviq | yeah, /me just stole that | 17:44 |
| Saviq | erm | 17:44 |
| Saviq | borrowed, you know | 17:44 |
| Saviq | I'll give it back | 17:44 |
| Chipaca | mvo: https://github.com/mvo5/snappy/pull/17 is the thing (i also pushed a merge of master to your pr directly, to make this one's diff easier on you) | 17:50 |
| mup | PR mvo5/snappy#17: snap/squashfs: change unsquashfsStderrWriter to use MatchCounter <Created by chipaca> <https://github.com/mvo5/snappy/pull/17> | 17:50 |
| mup | PR snapd#4630 closed: snap: sort layout elements before validating <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4630> | 18:09 |
| mup | PR snapd#4635 opened: snap: add support for `snap run --gdb` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4635> | 18:10 |
| zyga | oh, cool stuff mvo | 18:11 |
| ikey | oo | 18:12 |
| zyga | mvo quick review out | 18:15 |
| mvo | zyga: cool, thanks | 18:15 |
| zyga | Chipaca 4636 is what we talked about sans the interface indirection | 18:16 |
| mvo | zyga: good feedback, thank you. will address those, the message also needs tweaking I think. it was mostly a flash of inspiration that I wanted to check if it would work (i.e. use gdb from outside and the shim to break at the right point) | 18:16 |
| mup | PR snapd#4636 opened: snap: understand directories in layout blacklist <Created by zyga> <https://github.com/snapcore/snapd/pull/4636> | 18:16 |
| cachio | Saviq, sorry for the delay, which images are you using? | 18:18 |
| cachio | sabdfl, we have ipv6 disabled in linode images to avoid timeouts/connection issues | 18:19 |
| zyga | mvo I looked at your earlier PR but I'm at a stage where thinking requires a 7AM freshness | 18:19 |
| mvo | zyga: haha, no worries | 18:19 |
| mvo | zyga: I think I could probably untangle them but there will be conflicts | 18:19 |
| zyga | no, that's fine | 18:19 |
| mvo | zyga: so that stacking was easier | 18:19 |
| mvo | zyga: ta! | 18:19 |
| zyga | I just need to look at it carefully as it changes a few things in an area that is tricky | 18:20 |
| mvo | cachio: do we need 4634 for .31 ? | 18:20 |
| mvo | cachio: if we do, please shoot me a quick mail with the commit id and I will cherry-pick | 18:21 |
| cachio | mvo, no, it is just for an error that we see in linode | 18:21 |
| mvo | cachio: ok | 18:21 |
| mup | PR snapd#4634 closed: tests: check if snapd.socket is active before stoping it <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4634> | 18:21 |
| zyga | woot, I'm one PR away for spread test for layouts | 18:22 |
| cachio | niemeyer, do you have any idea about what could be causing this error on linode? https://paste.ubuntu.com/26537045/ | 18:23 |
| Chipaca | cachio: probably https://twitter.com/gniemeyer/status/961273050707693569 | 18:27 |
| cachio | Chipaca, nice | 18:27 |
| cachio | tx | 18:28 |
| * zyga -> afk | 18:34 | |
| cachio | niemeyer, I still can't run tests on linode, is it the same issue that we faced previously? | 19:23 |
| niemeyer | cachio: I'll soon be with you | 19:23 |
| cachio | sure | 19:23 |
| sparkiegeek | hmm, potential ux regression in 2.31? https://bugs.launchpad.net/snapd/+bug/1747992 | 19:30 |
| mup | Bug #1747992: Refreshing to a newly created channel but immediately stopped tracking <snapd:New> <https://launchpad.net/bugs/1747992> | 19:30 |
| niemeyer | sparkiegeek: Huh.. weird | 20:23 |
| niemeyer | sparkiegeek: Yeah, definitely worth looking into | 20:23 |
| niemeyer | cachio: Still there? | 20:54 |
| cachio | niemeyer, | 20:59 |
| niemeyer | cachio: So yeah, these errors look like Linode breaking down | 20:59 |
| cachio | niemeyer, https://paste.ubuntu.com/26537730/ | 20:59 |
| cachio | these kind of errors I see | 21:00 |
| niemeyer | cachio: In general Spread can automatically recover from them, though, and the fact we have several workers per systems means no big deal | 21:00 |
| cachio | niemeyer, it is related to the quota limits? | 21:00 |
| cachio | niemeyer, it is trying to connect to the vm and nothing | 21:00 |
| cachio | it tries until it breaks | 21:01 |
| cachio | it fails | 21:01 |
| niemeyer | cachio: It's not quota.. it's corruption | 21:01 |
| niemeyer | cachio: They have severe bugs in their API services.. apparently races | 21:01 |
| cachio | niemeyer, I checked debian-9 and we have ipv6 enabled there | 21:01 |
| cachio | I could not check in trusty | 21:02 |
| niemeyer | cachio: Let me see which machine is creating problems.. just a sec | 21:02 |
| cachio | niemeyer, sure | 21:02 |
| niemeyer | cachio: There are machines with an empty plan ID | 21:03 |
| niemeyer | cachio: Which gives you an idea of how nice it is | 21:04 |
| cachio | niemeyer, ouch | 21:04 |
| cachio | niemeyer, are you killing these ones? | 21:07 |
| jdstrand | davidcalle (cc sergiusens): fyi, https://docs.snapcraft.io/deprecation-notices/dn5 uses the wrong header 'DN2'. It should be 'DN5' | 21:08 |
| niemeyer | cachio: I've run a full pass of garbage collection | 21:09 |
| niemeyer | cachio: Please give a shot | 21:09 |
| cachio | niemeyer, it is still having same issue | 21:11 |
| niemeyer | Okay, hold on | 21:11 |
| cachio | niemeyer, well, now got 1 serve | 21:11 |
| cachio | r | 21:11 |
| niemeyer | cachio: What does that mean? | 21:12 |
| cachio | niemeyer, it is workfing now | 21:12 |
| niemeyer | cachio: Phew, cool | 21:12 |
| cachio | niemeyer, thanks | 21:13 |
| niemeyer | cachio: np, let me know if you have more bad cases blocking you | 21:20 |
| niemeyer | cachio: I'll need to speed up our move over, likely to Google Compute | 21:20 |
| zyga | now to get some rest and fight tomorrow | 22:09 |
| slanigan | Hi everyone, I'm struggling to build an Ubuntu Core image as per the steps on the introduction page: https://docs.ubuntu.com/core/en/guides/build-device/image-building | 22:35 |
| slanigan | I keep getting COMMAND FAILED: sudo cp -dR --preserve=mode,timestamps,ownership /tmp/tmpuv44url8/root/* /tmp/tmp7yr_gzqx/root-mount cp: error writing '/tmp/tmp7yr_gzqx/root-mount/system-data/var/lib/snapd/snaps/core_3884.snap': No space left on device cp: error writing '/tmp/tmp7yr_gzqx/root-mount/system-data/var/lib/snapd/snaps/pi2-kernel_22.snap': No space left on device cp: cannot create directory '/tmp/tmp7yr_gzqx/root-mount/s | 22:35 |
| slanigan | When I try to do the "ubuntu-image" command | 22:35 |
| kyrofa | slanigan, any chance you're out of HD space? | 22:36 |
| slanigan | df -h reports this: | 22:37 |
| slanigan | Filesystem Size Used Avail Use% Mounted on udev 7.8G 0 7.8G 0% /dev tmpfs 1.6G 9.7M 1.6G 1% /run /dev/sda1 432G 259G 157G 63% / tmpfs 7.8G 130M 7.7G 2% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup ... /dev/loop8 3.9M 52K 3.3M 2% /tmp/tmpvn70tzdq/root-mount <<<<<<<< | 22:37 |
| slanigan | That's a shortened list, but the /dev/loop8 entry is while ubuntu-image is trying to do its thing | 22:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
