| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === pbek_ is now known as pbek | ||
| mborzecki | morning | 05:07 |
|---|---|---|
| zyga | Hi | 05:26 |
| zyga | Mvo: I fixed it | 05:35 |
| mvo | zyga: \o/ | 05:42 |
| mvo | zyga: woha, nice | 05:43 |
| mvo | zyga: what was it? | 05:43 |
| zyga | Flipped logic | 05:43 |
| zyga | Look at the FIX patch | 05:43 |
| * mvo looks | 05:43 | |
| zyga | Core test still need change but runtime is fine | 05:43 |
| mvo | zyga: what core test needs a change? | 05:45 |
| zyga | Or actually no. It doesn’t | 05:46 |
| zyga | Ignore me :-) | 05:46 |
| zyga | Not enough sleep | 05:46 |
| zyga | Don’t look at the time stamp | 05:46 |
| zyga | I will clean this up and propose to master | 05:46 |
| mvo | zyga: uhhh | 05:50 |
| * mvo hugs zyga | 05:50 | |
| mvo | zyga: really not enough sleep | 05:50 |
| mvo | zyga: yay, works here, nice job | 05:58 |
| zyga | Same here | 05:58 |
| zyga | Cool, so one last issue ahead | 05:58 |
| zyga | And one that should be way | 05:58 |
| zyga | Easier | 05:58 |
| zyga | I’ll get some coffee and get right to it | 05:58 |
| mborzecki | mvo: hi, can you take a quick look at #5424 ? | 06:00 |
| mup | PR #5424: tests/main/snapd-notify: use systemd's service properties rater than the journal <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5424> | 06:00 |
| mvo | mborzecki: good morning | 06:02 |
| mvo | mborzecki: sure | 06:02 |
| mup | PR snapd#5361 closed: snapstate: allow removal of snap.TypeOS when using a model with a base <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5361> | 06:16 |
| mup | PR snapd#5424 closed: tests/main/snapd-notify: use systemd's service properties rater than the journal <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5424> | 06:19 |
| mborzecki | mvo: yay! | 06:19 |
| mvo | mborzecki: thank you, that was failing a lot recently | 06:20 |
| pedronis | #5392 needs a 2nd review | 06:23 |
| mup | PR #5392: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5392> | 06:23 |
| mvo | abeato: hey, good morning! 5309 got a +1 just a tiny tweak to the filename is requested | 06:37 |
| abeato | mvo, morning! | 06:37 |
| abeato | mvo, yeah saw that, will change it and ping you back :) | 06:38 |
| mvo | abeato: great, thank you! I'm keen to land it :) | 06:39 |
| mvo | sil2100: hey, good morning. I noticed our /etc/hosts on core18 is empty, do you know where that files comes from nowdays? I wonder if we need to add a static one to our build tooling | 06:48 |
| mvo | sil2100: with localhost and the like | 06:48 |
| abeato | mvo, 5309 re-pushed | 06:52 |
| mvo | looking | 06:52 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 06:59 |
| mvo | good morning pstolowski | 07:00 |
| mborzecki | pstolowski: hey | 07:00 |
| zyga | re | 07:11 |
| zyga | small horror story | 07:11 |
| zyga | what happens after: | 07:12 |
| zyga | 1) you talk with your wife about ways of making coffee | 07:12 |
| zyga | and about perhaps getting those portable espresso machines | 07:12 |
| zyga | 2) you work till 3AM | 07:12 |
| zyga | anyone wants to guess? :) | 07:12 |
| zyga | the coffee machine breaks :( | 07:12 |
| mborzecki | zyga: you go a buy a moka pot? :) | 07:14 |
| mup | PR snapd#5420 closed: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5420> | 07:14 |
| zyga | what's a moka pot? :) | 07:14 |
| zyga | so far I fed the children and tidied the kitchen, now I need to walk the dog | 07:14 |
| mborzecki | zyga: https://en.wikipedia.org/wiki/Moka_pot | 07:14 |
| zyga | but first, small rebase of that WIP+FIX patches so that I can send it to master | 07:15 |
| sil2100 | mvo: let me make sure | 07:18 |
| mborzecki | any PRs in need of review? | 07:18 |
| mvo | mborzecki: the 2.34 ones would be great | 07:24 |
| zyga | mvo: ok, I have a nice patch now | 07:26 |
| zyga | I force-pushed to my working branch | 07:27 |
| zyga | I will now open a master PR | 07:27 |
| pedronis | mvo: could you review #5304 ? | 07:29 |
| mup | PR #5304: overlord/ifacestate: simplify checkConnectConflicts and also connect signature <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5304> | 07:29 |
| pedronis | heh, sorry | 07:29 |
| pedronis | mvo: I meant #5403 | 07:30 |
| mup | PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403> | 07:30 |
| mvo | pedronis: sure | 07:30 |
| mborzecki | zyga: https://paste.ubuntu.com/p/vn9XJVcpKj/ | 07:31 |
| zyga | mborzecki: is match passing -E? | 07:31 |
| zyga | but ... odd | 07:31 |
| zyga | do you have a debug shell? | 07:31 |
| zyga | if so, type MATCH could be useful | 07:31 |
| mborzecki | zyga: yeah, i checked spred source code, it's using ... grep -q -E \"$@\" .. | 07:32 |
| mborzecki | zyga: https://github.com/snapcore/spread/blob/master/spread/client.go#L357 | 07:32 |
| mup | PR snapd#5432 opened: cmd/snap-confine: fix snaps running on core18 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5432> | 07:33 |
| zyga | mvo: ^ this is for you | 07:33 |
| zyga | mborzecki: magic :) | 07:33 |
| mvo | mborzecki: yeah, this is strange, this tests passes most of the time | 07:33 |
| mvo | zyga: \o/ | 07:33 |
| zyga | mvo: I need to take the dog out and look after myself a little | 07:34 |
| zyga | I will be back around 10:30 perhaps | 07:34 |
| Son_Goku | zyga, do you think we can have a fedora-based snap to demo by Flock? | 07:40 |
| zyga | yes | 07:40 |
| abeato | mvo, 5309 finished CI fine (thanks for the change in the spread test, I had not noted that one) | 07:41 |
| mvo | abeato: ta | 07:41 |
| abeato | \o/ | 07:42 |
| mup | PR snapd#5309 closed: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5309> | 07:42 |
| niemeyer | Mornings | 07:45 |
| zyga | hey | 07:48 |
| mborzecki | niemeyer: hey, you're early, adjusting to new timezones? | 07:48 |
| niemeyer | mborzecki: Heya | 07:49 |
| niemeyer | mborzecki: Nah, just in the mood for night hacking | 07:49 |
| niemeyer | Well.. "hacking".. reviewing right now | 07:50 |
| pedronis | mvo: #5392 paniced btw, not sure it's the panic fixed by the other PR | 07:51 |
| mup | PR #5392: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5392> | 07:51 |
| pedronis | mvo: could be though, maybe they need to be merged | 07:52 |
| mvo | pedronis: indeed, I think its the same, I will merge the fix and see if that helps | 07:52 |
| mvo | pedronis: but its slightly odd as this panic happens when there are snaps in the seed, I will dig into it | 07:53 |
| mvo | pedronis: right after I reviewed your PR | 07:53 |
| mup | PR snapd#5388 closed: tests: fix tests when no keyboad input detected <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5388> | 07:54 |
| mvo | pedronis: aha, I think I know what is going on, silly me | 07:55 |
| pedronis | ah, it was the previous commit | 07:59 |
| mvo | pedronis: yeah | 08:00 |
| === chihchun_afk is now known as chihchun | ||
| mvo | pedronis: reviewed, looks fine and added some comments but we can land when green I think | 08:23 |
| pedronis | mvo: thx, yes, need to tweak a couple of spread tests to get it green | 08:26 |
| * Chipaca afk for a while | 08:39 | |
| popey | cjwatson: when did "Manage this package in the store" link land in the store? I only just noticed it. It's super useful, thank you (if it was you, which I assume it was) that made it happen :) | 08:40 |
| popey | s/store/launchpad/ | 08:41 |
| cjwatson | popey: 2016 :-) You're welcome | 08:44 |
| popey | wow | 08:44 |
| Son_Goku | mvo, it's happening! https://pagure.io/flock/issue/87 | 08:51 |
| mvo | Son_Goku: \o/ woah | 08:51 |
| pstolowski | nice! | 08:51 |
| Son_Goku | I just filed the proposal since niemeyer gave me the all-clear | 08:52 |
| mup | PR snapd#5427 closed: configcore: fix incorrect handling of keys with nubmers (like gpu_mem_512) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5427> | 09:00 |
| mvo | mborzecki: 5389 looks good, does this need any further design review or can I just land it? | 09:14 |
| mvo | mborzecki: at this stage, what is missing for parallels installs to get them working end-to-end? just curious | 09:14 |
| pedronis | mvo: all the interface backends need some work (some a little, some a bit more) | 09:16 |
| mborzecki | mvo: i still have changes for snapstate/snapsup, some tests in overlord, small change in daemon and some spread tests, plus changes in store | 09:16 |
| mvo | pedronis: aha, thanks | 09:16 |
| mborzecki | mvo: oh and some bits in snap-confine too | 09:16 |
| mup | PR snapd#5389 closed: snap: account for parallel installs in wrappers, place info and tests <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5389> | 09:17 |
| mup | PR snapd#5429 closed: osutil: import go-udev <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5429> | 09:18 |
| mborzecki | hit a weird problem, if /etc/dbus-1/system.d does not exist and we dump a file there (creatign the directory first), does dbus daemon need a reload/restart to pick up the new files? | 09:20 |
| mvo | mborzecki: I bet it does | 09:21 |
| mvo | mborzecki: probably a inotify (or whatever it is nowdays called) restriction | 09:21 |
| mborzecki | so #5413 does some distro purge, in arch /etc/dbus-1/system.d is not owned by dbus but rather by individual pacakges | 09:21 |
| mup | PR #5413: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5413> | 09:21 |
| mvo | mborzecki: i.e. I assume it sets up a watcher for this dir, but if the dir does not exists it will not setup this watcher | 09:21 |
| mborzecki | it's possible that we end up without /etc/dbus-1/system.d at some point | 09:22 |
| mborzecki | then when snap is installed, create the dir and dump the *.service file but it's not picked up | 09:22 |
| mvo | mborzecki: hm, that seems unfortuante | 09:22 |
| mup | PR snapd#5392 closed: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5392> | 09:22 |
| mvo | mborzecki: might be worthwhile to fix in the arch dbus package? it seems odd that it would not own the dir | 09:23 |
| mborzecki | mvo: i could own /etc/dbus-1/system.d in snapd package, but it's slightly meh, another empty dir | 09:23 |
| mvo | mborzecki: especially if the suspicion about the inotify watch is true | 09:23 |
| mvo | mborzecki: I don't know the conventions of arch so I might be off but I think the dbus arch package should own the dir | 09:24 |
| mvo | mborzecki: or at least co-own it | 09:24 |
| mvo | mborzecki: like if dbus is installed it should always be there | 09:24 |
| mborzecki | mvo: the 'convention' is no empty dirs shipped by the pacakge, but we're already not doing this | 09:24 |
| mborzecki | or doing, i.e. shipping empty dirs :) | 09:24 |
| mvo | mborzecki: heh, yeah, I understood (but parsing took a little longer) | 09:25 |
| mvo | mborzecki: so that is why dbus does not own the dir? because it would be empty? | 09:25 |
| mborzecki | mvo: yes | 09:25 |
| mvo | mborzecki: that seems to be slightly silly tbh, it could ship a README in there (again assuming the theory about inotify is correct) | 09:25 |
| mborzecki | mvo: it ships /usr/share/dbus-1/system.d, though we don't touch that | 09:26 |
| mvo | mborzecki: because dbus is buggy for other packages as well. install foo-that-uses-dbus.d and it won't get picked up until dbus is restarted | 09:26 |
| mvo | mborzecki: anyway, just my 2¢ | 09:27 |
| pstolowski | zyga, mborzecki can you take another look at https://github.com/snapcore/snapd/pull/5416 ? | 09:28 |
| mup | PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416> | 09:28 |
| pedronis | niemeyer: Q, what kind name we would use for the new single one (the old one cannot be reused because different expectations about Value) ? | 09:29 |
| niemeyer | pedronis: Was hoping we could just preserve what we have | 09:31 |
| niemeyer | pedronis: How has the Value changed? | 09:31 |
| niemeyer | pedronis: Is it incompatible? | 09:31 |
| pedronis | niemeyer: Value is now a mapping of details, before it was just snapName | 09:31 |
| * niemeyer looks again | 09:31 | |
| niemeyer | pedronis: But is it just more than what we had, or incompatible somehow? | 09:32 |
| pedronis | it's incompatbile string vs mapping | 09:32 |
| niemeyer | pedronis: Ah, the entire "value" was a snap name? | 09:32 |
| pedronis | yes | 09:32 |
| niemeyer | Ouch | 09:33 |
| pedronis | niemeyer: we could use snap-revision-not-available-as-specified (to follow your suggested base error message) | 09:34 |
| niemeyer | pedronis: "snap-not-available" maybe | 09:34 |
| zyga | pstolowski: yes | 09:34 |
| pedronis | niemeyer: sounds a bit too much like snap-not-found to me | 09:35 |
| niemeyer | Indeed | 09:35 |
| niemeyer | hmm | 09:35 |
| mvo | zyga: I took the liberty to push a very small spread test to your 5432 fixup pr, thanks again for this | 09:35 |
| zyga | sure, thank you | 09:36 |
| pedronis | niemeyer: also to explain, I went for two kinds, not just because I needed a kind, but because so a naive client could give a slightly accurate message without parsing value | 09:37 |
| niemeyer | pedronis: Ah, indeed.. that will also be solved with the separate kind | 09:38 |
| pedronis | I mean "there is nothign for this arch" vs "there is something but not in this channel" | 09:38 |
| niemeyer | pedronis: I see | 09:41 |
| niemeyer | pedronis: That's nice indeed | 09:41 |
| niemeyer | pedronis: and I guess the "nothing for this arch" is quite useful, even if there's nothing in this channel either | 09:42 |
| pedronis | yes | 09:42 |
| niemeyer | It's more like "give up, you won't find anything here" | 09:42 |
| pedronis | that was the reasoning | 09:42 |
| niemeyer | pedronis: +1 | 09:42 |
| pedronis | I will switch to the shorter kind you proposed tough | 09:43 |
| niemeyer | pedronis: Btw, I think we should provide such a message from the server also | 09:43 |
| niemeyer | pedronis: In case the client is dumb | 09:43 |
| niemeyer | pedronis: Right now I think it's only providing the general "nothing found" one | 09:43 |
| pedronis | let me see | 09:43 |
| pedronis | niemeyer: no, it gives two different messages if (it has info) | 09:44 |
| pedronis | no snap revision for the given channe | 09:44 |
| pedronis | l | 09:44 |
| pedronis | and | 09:44 |
| niemeyer | Or more specifically, "nothing for given constraints".. there's a note about this message being bad in the review, but it would be nice to at least hint at the delta between "nothing for this arch" vs "nothing for this channel", even if we don't go full blown for now | 09:44 |
| pedronis | no snap revision for the given architecture | 09:44 |
| niemeyer | pedronis: Ah, okay.. I must have missed something then.. it thought it was just returning the rna.Error() message, which is a single one | 09:45 |
| pedronis | that's used only as fallback | 09:45 |
| pedronis | if some reason or corner case | 09:45 |
| niemeyer | Ack | 09:45 |
| pedronis | the store doesn't provide the info | 09:45 |
| pedronis | niemeyer: code is here: https://github.com/snapcore/snapd/pull/5403/files#diff-e1016939c627280d9f6c53bdab0530bfR399 | 09:46 |
| mup | PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403> | 09:46 |
| niemeyer | pedronis: Cool, thanks, looks good.. suggested a minor tweak to the messages | 09:48 |
| pedronis | ok, I'll proceed as discussed then | 09:48 |
| niemeyer | Thanks | 09:49 |
| pedronis | about simplifying thanks, I'll first go over the other feedback, messages and kinds | 09:49 |
| pedronis | and then see what i can do | 09:49 |
| pedronis | (it's already a bit big and some of that is preexisting) | 09:49 |
| niemeyer | mvo: Three PRs from 2.34 to go.. but I'll try to get a couple of hours of sleep before the meeting marathon this morning.. may not be able to review these last ones before my afternoon | 09:49 |
| pedronis | heh, s/thanks/things/ | 09:49 |
| mvo | niemeyer: no worries | 09:49 |
| mvo | niemeyer: we can always postpone them or merge them slightly later | 09:50 |
| mvo | niemeyer: thanks a lot for your reviews | 09:50 |
| niemeyer | np, see you all soon o/ | 09:50 |
| pedronis | mvo: I'll go over the new feedback for 5403 after lunch | 09:56 |
| mvo | pedronis: thank you, also no worries, I plan to do 2.34~pre1 today to see if it builds everywhere and if autopkgtest are fine, we will probably need to do a ~pre2 to deal with that fallout anyway so if a PR is not ready today that is not too terrible | 09:58 |
| mvo | pedronis: I also updated 5428, should be an easy review I hope | 10:00 |
| pstolowski | zyga: can #5411 land? | 10:09 |
| mup | PR #5411: many: remove core-support interface <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5411> | 10:09 |
| pedronis | mvo: it's red atm | 10:09 |
| zyga | pstolowski: I think so but I wanted jdstrand to see it too | 10:10 |
| pstolowski | ack | 10:10 |
| mup | PR core#89 opened: hooks: fix 30-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <https://github.com/snapcore/core/pull/89> | 10:13 |
| mup | PR core18#44 opened: hooks: fix 030-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <https://github.com/snapcore/core18/pull/44> | 10:14 |
| mup | PR snapd#5431 closed: interfaces: move ValidateName helper to utils <Simple> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5431> | 10:22 |
| mvo | zyga: we are down to two failing test: ubuntu-core-18-64:tests/main/snap-disconnect (and one race) and tests/main/catalog-update which I am looking into right now | 10:29 |
| zyga | that's great, I will give you the patch for disconnect today so that will be just landing and polishing for next week | 10:30 |
| zyga | mvo why is catalog-update failing? | 10:30 |
| mvo | zyga: no idea, might be a fluke | 10:30 |
| zyga | and what happened to systemd and signals? did you find the issue? | 10:30 |
| mvo | zyga: checking now | 10:30 |
| mvo | zyga: this is the racy one | 10:30 |
| zyga | I see that test fail from time to time (~ once a week maybe) | 10:30 |
| mvo | zyga: still not sure what is going on there :( | 10:30 |
| zyga | aha | 10:30 |
| zyga | ok, good news though | 10:30 |
| zyga | I think core18 will rock :) | 10:31 |
| mvo | zyga: heh, eventually | 10:31 |
| mvo | zyga: but yeah, we are on the right path at least | 10:31 |
| sil2100 | mvo: so I just did a quick check - the /etc/hosts file is still generated by netcfg from what I see, which is a d-i package | 10:48 |
| mvo | sil2100: aha, so we probably should include something in our build given that we don't run d-i | 10:48 |
| sil2100 | mvo: I guess the easiest way would be just to prepare a static one | 10:48 |
| sil2100 | Let me do that | 10:49 |
| mvo | sil2100: \o/ thank you | 10:50 |
| mvo | zyga: catalog-refresh looks very much like a bug in get_journalctl_log | 10:50 |
| zyga | yeah | 10:50 |
| mvo | zyga: when I run journalctl -u snapd.service | MATCh things magically work | 10:50 |
| zyga | I think that it is buggy because of buffering | 10:50 |
| zyga | we don't see stuff in the "pipe" | 10:50 |
| mvo | zyga: I think we need to revert that | 10:50 |
| mvo | zyga: it might also the reason why the stop-mode test is failing | 10:50 |
| mvo | zyga: I can look after lunch | 10:51 |
| zyga | that would be a good thing to see actually | 10:51 |
| zyga | yeah | 10:51 |
| zyga | ok, thank you | 10:51 |
| mvo | zyga: my gut feeling is revert | 10:51 |
| zyga | I'm doing reviews, my head is too dizzy still | 10:51 |
| mvo | zyga: ok - if you want we can have a quick HO and I can do the disconnect work. I just need some info what you had in mind. but lunch first | 10:52 |
| zyga | no, that's fine, I will finish that one :) | 10:52 |
| mvo | zyga: I'm super motiviated to get the last bit in | 10:52 |
| mvo | zyga: ok | 10:52 |
| * mvo hugs zyga | 10:52 | |
| zyga | yes, mee to :) | 10:52 |
| zyga | me too | 10:52 |
| zyga | just ... sleepy | 10:52 |
| * zyga takes a break from reviews and hacks that bit in | 10:52 | |
| mup | PR snapd#5433 opened: interfaces/repo: added AllHotplugInterfaces helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433> | 10:56 |
| === pstolowski is now known as pstolowski|lunch | ||
| mup | PR core18#45 opened: Provide a static simple /etc/hosts file <Created by sil2100> <https://github.com/snapcore/core18/pull/45> | 10:59 |
| zyga | mvo: ok, testing the fix now | 10:59 |
| mvo | zyga: woah, thats impressively fast | 11:08 |
| mvo | sil2100: \o/ | 11:09 |
| zyga | mvo: that's a good joke for a 1st patch at 13:12 :) | 11:12 |
| * mvo hugs zyga | 11:12 | |
| mup | PR core18#45 closed: Provide a static simple /etc/hosts file <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/45> | 11:15 |
| mup | PR snapd#5434 opened: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434> | 11:25 |
| zyga | mvo: some more tweaks after first round of testing | 11:50 |
| zyga | I'll break for 30 minutes now and get back to this before the standup | 11:50 |
| zyga | I think it will pass before the standup | 11:50 |
| === pstolowski|lunch is now known as pstolowski | ||
| mup | PR snapd#5408 closed: i18n: use xgettext-go --files-from to avoid running into cmdline size limits <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5408> | 12:15 |
| zyga | mvo: I tweaked it now to be even easier, testing now | 12:36 |
| === chihchun is now known as chihchun_afk | ||
| zyga | running more tests, it's funny how I ping pong around the cod | 12:47 |
| mvo | zyga: :) thanks a lot! | 12:52 |
| zyga | I forgot we have resolve disconnect that is full blown and used in daemon/api.go | 12:53 |
| zyga | so perhaps the tweaks to other places are actually not needed | 12:53 |
| zyga | (more self-contained change) | 12:53 |
| pedronis | yes, the fewer the places the better, the easier is to reason about | 12:54 |
| mvo | pedronis: re 5422 - I agree with you, we need at least a proper test and I can give the idea of using the connections a go. I want it in 2.34 but in a way that is not too ugly | 12:54 |
| pedronis | mvo: yes, a regression test would also be good | 12:56 |
| zyga | joining | 13:02 |
| Chipaca | oops, standup | 13:07 |
| * Chipaca runs | 13:07 | |
| zyga | mvo: it passes now, I will remove my extra patches :) | 13:08 |
| zyga | mvo: I pushed two tiny patches to my integration PR | 13:13 |
| zyga | mvo: I will amend the latest one to have more tests | 13:14 |
| zyga | have a look | 13:14 |
| mvo | zyga: nice | 13:14 |
| zyga | mvo: question | 13:25 |
| zyga | mvo: why is snap-disconnect test _not_ listed for systems: [-ubuntu-core-16-64] | 13:25 |
| mvo | zyga: I don't know why its disabled there? | 13:26 |
| zyga | my guess was home is not auto connected but that's not relevant there | 13:26 |
| zyga | I'll re-enable it | 13:26 |
| mvo | zyga: thanks | 13:26 |
| mvo | zyga: lets check git blame | 13:26 |
| zyga | ha, good idea | 13:26 |
| zyga | checking | 13:26 |
| zyga | since day 1 | 13:27 |
| zyga | mvo: and it passes :) | 13:41 |
| mvo | zyga: \o/ | 13:41 |
| zyga | mvo: also pushed | 13:41 |
| Chipaca | mborzecki: where is that failure from? the MATCh one | 13:45 |
| mvo | Chipaca: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L482 is the relevant code | 13:46 |
| Chipaca | yes i've got that | 13:46 |
| mvo | Chipaca: aha, you mean from what PR? | 13:46 |
| Chipaca | yeah | 13:46 |
| mborzecki | Chipaca: i don't remember the actual PR | 13:46 |
| Chipaca | basically, two things could be happening that I can think of right now: | 13:46 |
| mborzecki | Chipaca: but if you pick one of the failed ones there's a high chance you'll run into it :) | 13:47 |
| Chipaca | 1. a non-printable character is in that file, before 'test' | 13:47 |
| Chipaca | note the first grep does >> instead of >, so if there was rubbish there it'll still be there | 13:47 |
| Chipaca | 2. something wrote to the file between the grep and the MATCH (I don't think so as nothing should be happening concurrently at this point) | 13:48 |
| pedronis | Chipaca: one possibility is that the file >> sometimes doesn't end with newline | 13:48 |
| Chipaca | pedronis: right, that's what I mean, there might be a \0 or something in the file, and it gets test:yaddayadda appended | 13:49 |
| pedronis | I meant the file >> to | 13:49 |
| Chipaca | if there's no reason for the first >> we should change it to a > and be done with it :) | 13:49 |
| Chipaca | pedronis: sorry i didn't quite follow you | 13:50 |
| Chipaca | pedronis: if you mean the left hand side of the >>, that's a grep so it'll be adding its own newlines | 13:50 |
| pedronis | no | 13:50 |
| pedronis | I mean the preexisting file ending | 13:50 |
| pedronis | maybe we should add a check about that assumption | 13:50 |
| pedronis | at least it woudl cleanly | 13:51 |
| pedronis | would fail cleanly | 13:51 |
| sergiusens | Chipaca: so I've followed the suggestion to mount inside the VM, so carry on with the idea of 400 for snaps | 13:52 |
| Chipaca | sergiusens: *smooch* | 13:52 |
| mvo | Chipaca: fwiw, golang-1.10 builds fine on xenial in pbuilder, trusty looks a bit more involved, at least the build-depds need to be updated there but probably also not that much work given that we have 1.6 there already | 13:53 |
| pedronis | Chipaca: something like either length is 0 or tail -c 1 /mnt/system-data/var/lib/extrausers/"$f"| some way to check for a single "\n" | 13:54 |
| mvo | Chipaca: I did not really look into trusty though as agreed in the standup :) | 13:54 |
| mvo | zyga: I ran snap-disconnect from your PR and it failed :( | 13:55 |
| Chipaca | mvo: I'll be giving that a poke on Monday, I reckon | 14:02 |
| zyga | mvo: how did it fail, which test did you run exactly? | 14:20 |
| mvo | Chipaca: sure thats fine | 14:22 |
| mvo | zyga: I used your branch and did: spread -v google:ubuntu-core-18-64:tests/main/snap-disconnect | 14:22 |
| mvo | zyga: zyga error: snap "core" has no slot named "home" | 14:22 |
| zyga | hmm, I ran exactly that ! | 14:22 |
| mvo | zyga: but maybe I did smething wrong | 14:22 |
| * zyga checks for un-commited stuff :) | 14:22 | |
| mvo | zyga: and have the wrong branch or whatnot | 14:22 |
| mvo | zyga: I'm in a meeting so maybe that | 14:22 |
| mvo | zyga: was distracted | 14:22 |
| zyga | mvo: I pushed one more patch there | 14:22 |
| zyga | maybe that is also needed in practice | 14:23 |
| mvo | zyga: ok, let me pull | 14:23 |
| mvo | zyga: running it again | 14:23 |
| mvo | zyga: I have b4d4df8ff92ddde657cea9f7249b8a69872d69e0 on top currently | 14:23 |
| zyga | I think I commited it wrong, it needs to be split into two | 14:23 |
| Chipaca | pedronis: so, it's not gibberish at the start of the file | 14:24 |
| zyga | I have 71230a6d0e5f11eb6a09aa958b200c00167592b7 | 14:24 |
| zyga | mvo: top is " overlord/ifacestate: translate explicit requests for core to snapd" | 14:24 |
| zyga | I will split this patch and check what I did | 14:24 |
| pedronis | Chipaca: ? | 14:25 |
| Chipaca | pedronis: the MATCH thing | 14:25 |
| pedronis | yes | 14:25 |
| Chipaca | pedronis: I've got a shell in a failed run | 14:25 |
| Chipaca | the file is fine afaict | 14:25 |
| pedronis | and? | 14:25 |
| mup | PR snapd#5435 opened: overlord/snapstate: introduce path to fake backend ops <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5435> | 14:25 |
| pedronis | Chipaca: mmh | 14:26 |
| pedronis | fine in which sense | 14:26 |
| pedronis | test: ... | 14:26 |
| pedronis | on its own line? | 14:26 |
| Chipaca | yep | 14:26 |
| Chipaca | and MATCH passes | 14:26 |
| Chipaca | but it failed | 14:26 |
| pedronis | mmh | 14:27 |
| mborzecki | Chipaca: can you write a short script, source $TESTSLIB/spread-funcs.sh inside and check if that MATCH works in the script? | 14:27 |
| pedronis | fun, not | 14:27 |
| Chipaca | mborzecki: by a short script you mean one that does the 'for f in …' thing? | 14:28 |
| zyga | mborzecki: note that spread-funcs is empty outside of a spread run | 14:28 |
| zyga | it doesn't "cache" any copy of the functions in the tree | 14:29 |
| Chipaca | I'm going to add a 'sync' option in there and run it a few times to see | 14:30 |
| mborzecki | zyga: but it's dumped in top level prepare in spread.yaml, won't that be present in when you have debug shell? | 14:30 |
| zyga | sync | 14:30 |
| zyga | sleep 1 | 14:30 |
| zyga | sync # to be sure | 14:30 |
| zyga | rebot | 14:30 |
| zyga | mborzecki: yes, in debug shell that works ok | 14:30 |
| Chipaca | zyga: mount / -o remount,sync | 14:30 |
| mborzecki | zyga: but MATCH in debug shell comes from the profile which is mangled by spread, i want to check the MATCH that was duped to spread-funcs.sh | 14:31 |
| Chipaca | mborzecki: next time it fails i'll look into that | 14:31 |
| mborzecki | it's probably ok anyway | 14:32 |
| mvo | pedronis: 5403 is green, anything missing there or can I merge it? we can always do a followup | 14:32 |
| mvo | pedronis: aha, I think this probably needs a re-review first, right? | 14:32 |
| zyga | mborzecki: just source it then :) | 14:33 |
| zyga | mborzecki: actually | 14:33 |
| zyga | write a script that _sources_ it and _execute_ the script | 14:33 |
| mvo | zyga: it woooooooooooooooooooooorked | 14:35 |
| * mvo hugs zyga | 14:35 | |
| zyga | nice :) | 14:35 |
| pedronis | mvo: I don't know | 14:35 |
| zyga | so that's ... ... that's all that passes now? | 14:35 |
| zyga | just reviews and merges and stuff? | 14:35 |
| mvo | zyga: please propose your PR and then I can push the big core18-all-tests PR | 14:37 |
| zyga | OK | 14:37 |
| zyga | on it ;) | 14:37 |
| mvo | zyga: \o/ | 14:37 |
| zyga | :-) | 14:37 |
| mvo | sergiusens: let me search for this postpone of refresh command now | 14:41 |
| mvo | sergiusens: its "snap set core refresh.hold", let me find a proper example | 14:42 |
| sergiusens | mvo: thanks! | 15:07 |
| mvo | sergiusens: I'm creating a integration test with a proper example | 15:10 |
| zyga | mvo: I'm still reworking it slightly to be less copy-pasty | 15:24 |
| mvo | zyga: ok, still in a meeting | 15:25 |
| zyga | ok | 15:25 |
| mup | PR snapcraft#2174 opened: build_providers: inject snaps when running from a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2174> | 15:36 |
| sergiusens | mvo: in case you have moments to spare ^ | 15:38 |
| mup | PR snapd#5436 opened: tests: add basic integration test for spread hold <Created by mvo5> <https://github.com/snapcore/snapd/pull/5436> | 15:43 |
| mvo | sergiusens: the hold example is here -^ | 15:43 |
| senya | hello! are there examples of complete ruby on rails applications packed with snapcraft? | 15:44 |
| senya | specifically: how do I pack an application if it depends on a DB running instance? | 15:49 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | senya: hey, I don't knof of any but please ask around and also check on the forum | 16:13 |
| zyga | senya: note that the database may be (perhaps) a separate snap if that is more convenient | 16:13 |
| senya | the whole idea of snap is to be self-sufficient, so I think that if DB is a part of the application then it should be bundled with the application | 16:14 |
| === mup_ is now known as mup | ||
| zyga | well, it depends on how you look at it | 16:18 |
| zyga | you can bundle for a totally self-contained product | 16:18 |
| zyga | you can also integrate with an existing database | 16:18 |
| zyga | this also makes sense when you think that database may be shared by many systems that have the app snap installed | 16:18 |
| zyga | it depends on what you want to achieve | 16:18 |
| Chipaca | so... with the changes to prepare.sh, I can no longer get the MATCH thing to fail | 16:24 |
| Chipaca | this bothers me intensely | 16:25 |
| senya | what I think would be cool to have is a way to package RoR apps with snap, like Redmine, Discourse, etc, so that you can deploy a service with just "snap install redmine" and start using it right away, and then upgrade it with snap when new release is out | 16:25 |
| zyga | mvo: still moving stuff around but the resulting logic is much nicer | 16:25 |
| zyga | I will push another patch in this branch but open an itegrated PR for master | 16:26 |
| mup | PR snapd#5437 opened: tests/lib: sync the file before checking its contents <Created by chipaca> <https://github.com/snapcore/snapd/pull/5437> | 16:26 |
| zyga | senya: yeah, I agree | 16:26 |
| zyga | senya: I think this is possible | 16:26 |
| zyga | senya: and even in a mode where they bundle a simple database | 16:26 |
| zyga | (sqlite) | 16:26 |
| zyga | senya: but allow a full database to be attached via the configuration system in snaps (snap set) | 16:27 |
| Chipaca | senya: doesn't nextcloud use ruby at all? | 16:27 |
| Chipaca | afaik it ships with the whole stack in a snap | 16:28 |
| Chipaca | (but it might be php, for all i know) | 16:28 |
| senya | nextcloud is written on php | 16:28 |
| zyga | repyhape | 16:29 |
| senya | but if it bundles a DB it could be good as a reference! | 16:29 |
| popey | There's not a ton of ruby snaps in the store | 16:29 |
| popey | I can't even think of any right now | 16:29 |
| Chipaca | zyga: repyhape? | 16:29 |
| senya | there was a ruby example somewhere at snapcraft.io I think, but it was for ruby gem, not for a Rails application | 16:30 |
| zyga | a frankenstein with php ruby and python | 16:30 |
| Chipaca | popey: rubymine? | 16:30 |
| popey | thats... java? | 16:30 |
| zyga | perl | 16:30 |
| Chipaca | popey: psh | 16:30 |
| Chipaca | how can they write an ide for a language in anything other than the language | 16:31 |
| Chipaca | hard to take 'em seriously | 16:31 |
| Chipaca | :) | 16:31 |
| popey | turns out you can take one ide, re-skin it for 10 languages and $$$ :D | 16:31 |
| popey | (I kid, their IDEs are amazing) | 16:31 |
| zyga | $$$ oh wait, it is free ;) | 16:31 |
| Chipaca | popey: nothing against $$$ tho | 16:31 |
| popey | until it isnt | 16:31 |
| Chipaca | I like $$$, myself | 16:31 |
| popey | nom nom tasty dolla | 16:31 |
| senya | I think I can take https://github.com/nextcloud/nextcloud-snap as a reference and try to adapt the approach for RoR | 16:31 |
| Chipaca | just the other day I used some of it to obtain some coffee, and it was good | 16:32 |
| senya | oh, the repo even includes some ruby code, interesting | 16:32 |
| senya | that what you meant by frankenstein | 16:32 |
| Chipaca | zyga: https://twitter.com/perrito666/status/1012730660426059777 | 16:37 |
| Chipaca | i think I should probably check out | 16:37 |
| senya | they are building mysql from the source code https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L255 | 16:37 |
| senya | but is it possible to use apt to get the mysql package bundled to the snap? | 16:37 |
| Chipaca | senya: yes | 16:38 |
| senya | I like this idea better | 16:38 |
| Chipaca | anyway, EOD, EOW, etc. Will probably pop in later to check on that silly PR, and such, but for now I'm going to go out with the boys before summer ends | 16:38 |
| zyga | ends? | 16:40 |
| zyga | it just started | 16:40 |
| zyga | unless brexit makes UK go directly from one winter to another | 16:41 |
| tomwardill | british summer usually starts and ends in the same week | 16:41 |
| zyga | hahahaha | 16:41 |
| tomwardill | and goes from 'cold and rainy' to 'rainy and a bit warmer' | 16:42 |
| zyga | I should invite chipaca over | 16:42 |
| zyga | (for winter) | 16:43 |
| zyga | mvo: ok, I think I have a nicer version now | 16:51 |
| zyga | still missing extra tests for many cases, I will attack those over weekend | 16:51 |
| zyga | but now in a much much nicer shape | 16:51 |
| zyga | where all remapping is done in a pair of functions | 16:51 |
| zyga | incoming and outgoing | 16:52 |
| zyga | so we could eventually remap more things if we want to, without ripping the code apart | 16:52 |
| zyga | I'm running spread now, will check how the patch looks like | 16:52 |
| zyga | one last bastion is daemon/api.go | 16:52 |
| zyga | which really duplicates (synchronously) some of the work in other places | 16:52 |
| zyga | one thing I can do (and should) is to move the remapping logic to a place where daemon can use it as well | 16:53 |
| zyga | let me look | 16:53 |
| zyga | I pushed to my branch for reference | 16:54 |
| zyga | (force pushed since this is all bunch of WIP's and rebases) | 16:54 |
| zyga | it passes, so no regressions | 17:03 |
| zyga | that was 16, now trying core 18 | 17:03 |
| zyga | all green | 17:13 |
| zyga | mvo: I will have 3 nice small branches soon, just need to take the dog out | 17:42 |
| zyga | one refactor that makes it easy | 17:42 |
| zyga | one new helper | 17:42 |
| zyga | and the meat (tiny then) | 17:42 |
| zyga | but first | 17:42 |
| zyga | dog :) | 17:42 |
| zyga | mvo: actually, not sure if you are around | 18:20 |
| zyga | mvo: I have some ideas how to shrink that to two branches | 18:20 |
| zyga | but I should _pack_ first | 18:20 |
| zyga | so I will send stuff to look at (next week, please have your weekend) | 18:21 |
| zyga | but my time would be better spent on packing everything for the move | 18:21 |
| zyga | mvo: if you are around and want to provide quick feedback that is also welcome | 18:22 |
| zyga | mvo: because I could change how I refactor that further based on your input | 18:22 |
| mvo | zyga: sorry, wasn't around earlier but back now | 18:42 |
| zyga | mvo: re | 18:55 |
| zyga | mvo: let me show you quickly... | 18:55 |
| zyga | mvo: please look at https://github.com/snapcore/snapd/compare/master...zyga:feature/snapd-core-remapping?expand=1 | 18:56 |
| zyga | I will drop the first change that adds NewConnRefStrings perhaps, I need to do one more pass through this | 18:57 |
| zyga | the key thing is the pair of remap functions that define the transformations | 18:57 |
| zyga | and their application in several places | 18:57 |
| zyga | I plan to refactor this a little bit more to propose the refactoring without the remapping so that remapping is clearly layered on top | 18:57 |
| zyga | also some of the comments should just be unified and placed in one spot | 18:58 |
| zyga | this looks a bit nicer than earlier attempt that had similar-but-not-quite code all around | 18:58 |
| zyga | I still don't like how we need to careful remap in specific places but hopefully those are limited | 18:58 |
| zyga | we cannot remap at the api level though because there it would show up in the state | 18:59 |
| zyga | so this is a compromise of sorts | 18:59 |
| zyga | the key improvement in this iteration is that the functions that remap are well defined and we could possibly do other mappings later easily | 18:59 |
| mvo | zyga: ok, thank you! I check it out, just workiing on 2.34 beta right now | 19:01 |
| zyga | OK | 19:01 |
| mvo | zyga: this looks pretty nice | 19:23 |
| mvo | zyga: feel free to propose | 19:25 |
| mvo | zyga: that PR | 19:25 |
| zyga | I'm 30-40% through packing, I would still like to change one little detail there and add some tests | 19:25 |
| kyrofa | Hey zyga, I just got a bug report from a user who's snap suddenly stopped working. Logs are filled with lines like this: https://pastebin.ubuntu.com/p/JsKrXrGx9b/ | 19:32 |
| zyga | kyrofa: snap version please | 19:33 |
| zyga | this means the profile was not loaded so we could not switch to it | 19:33 |
| zyga | (and sandy that's not an error message we can easily fix, though I will look into it) | 19:33 |
| zyga | a way to fix it would be to call apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap* | 19:34 |
| zyga | but I'm wondering why the profiles were lost | 19:34 |
| zyga | ideally which distribution and how is it set up (containers?) | 19:34 |
| kyrofa | zyga, I asked for `snap version`, but the bug says "Debian 9 (stretch) with all updates applied" | 19:35 |
| kyrofa | zyga, excellent on the workaround, shall I suggest it, or do you want more data first? | 19:36 |
| zyga | suggest it and ask for uptime, and logs perhaps (system logs) | 19:36 |
| kyrofa | Shall I suggest uptime, syslog, and snap changes? | 19:37 |
| zyga | oh, snap changes is always useful, yes | 19:40 |
| zyga | that sounds like an excellent choice | 19:40 |
| kyrofa | Wait, does Debian actually use apparmor? | 19:43 |
| kyrofa | I didn't think so | 19:43 |
| kyrofa | zyga, here is `snap version`: https://pastebin.ubuntu.com/p/XjfvCT8Br9/ | 19:43 |
| zyga | yes, it does, though we don't rely on it as much there | 19:44 |
| zyga | this all looks good | 19:44 |
| zyga | I do wonder what happened | 19:44 |
| mvo | zyga: do you think this diff is good enough to cherry pick into the core18-all-tests-all-fixes branch? or will it change again? | 19:44 |
| zyga | mvo: it will change a little but it depends on how you plan to use the branch | 19:45 |
| zyga | my idea is to decompose it and land bits as they get reviewed | 19:45 |
| mvo | zyga: ok | 19:45 |
| zyga | so it can stay there because the branch will be rebased and rebased until it shrinks and becomes identical to master | 19:45 |
| zyga | you can take it to see how far you get | 19:46 |
| zyga | if that helps, sure | 19:46 |
| zyga | it might conflict with older patches in that branch so feel free to drop them | 19:47 |
| zyga | (they are pretty clearly labeled as affecting ifacestate) | 19:47 |
| mvo | zyga: its ok, it can probably wait until monday | 19:47 |
| zyga | s/might/will, I'm just polite/ ;) | 19:47 |
| mvo | zyga: hm, hm, can't cherry pick apparently | 19:58 |
| zyga | oh? | 20:00 |
| mvo | zyga: no worries | 20:00 |
| mvo | zyga: fixed the conflicts | 20:00 |
| kyrofa | jdstrand, the fact that snaps can stat files outside of their confinement but not actually open them is starting to get really annoying :P | 20:02 |
| kyrofa | Has there been any progress on fixing apparmor in that regard? | 20:02 |
| kyrofa | So many things look for files and open them if they find them. If they find a file they want to open, they rarely write guards around an inability to open them | 20:03 |
| kyrofa | I've had to patch certbot already, and now it looks like I need to patch mysql | 20:03 |
| jdstrand | kyrofa: not that I'm aware. jjohansen may have additional details ^ | 20:06 |
| zyga | kyrofa: can layouts help? | 20:15 |
| mup | PR snapd#5438 opened: many: run all of main against core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5438> | 20:16 |
| kyrofa | zyga, maybe, but I haven't played with them | 20:17 |
| kyrofa | And only once layouts are generally available everywhere | 20:18 |
| zyga | jdstrand: thank you for the review on https://github.com/snapcore/snapd/pull/5395 | 20:23 |
| mup | PR #5395: interfaces: generalize writable mimic profile <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5395> | 20:23 |
| zyga | jdstrand: I replied to some of the comments there | 20:25 |
| zyga | not everything because too tired and packing | 20:25 |
| mvo | zyga: I pushed the core18-all-tests PR which includes your disconnect fix, fingers crossed | 20:27 |
| zyga | ok | 20:28 |
| mvo | zyga: I call it a day now, enjoy | 20:28 |
| zyga | I wonder if it will pass or if we missed anything | 20:28 |
| zyga | night night | 20:28 |
| jjohansen | jdstrand: meh, I agree its a pita, but isn't something I can change with in apparmor, it needs to be done in the LSM and vfs | 20:49 |
| jjohansen | which is something that some people don't want | 20:49 |
| jdstrand | jjohansen: ack. kyrofa, fyi ^ | 20:49 |
| kyrofa | :'( | 20:50 |
| jjohansen | basically hiding them would make applications think they can create, and now we have people trying to create something that doesn't exist | 20:50 |
| jdstrand | kyrofa: but, the application is buggy. just cause you can stat() something has little bearing on if you can open() it | 20:50 |
| jjohansen | but really does | 20:50 |
| jdstrand | kyrofa: I suggest filing an upstream bug | 20:50 |
| kyrofa | jjohansen, but at least in that case they'll just get a good old permission denied | 20:51 |
| kyrofa | jdstrand, no argument from me, but it's been multiple projects now | 20:51 |
| kyrofa | Logging bugs upstream doesn't save me from needing to patch them myself, I'm afraid | 20:51 |
| jdstrand | no, it wouldn't | 20:53 |
| kyrofa | jdstrand, actually, it seems the issue is in the core snap | 21:08 |
| kyrofa | Look at the last line of /snap/core/current/lib/lsb/init-functions | 21:08 |
| kyrofa | mysql runs that file, it seems | 21:08 |
| kyrofa | [ -e /etc/lsb-base-logging.sh ] is true, but then it can't source it | 21:09 |
| kyrofa | So the script exits non-zero, which then brings mysql down with it | 21:09 |
| kyrofa | Who is in charge of the core snap, these days? | 21:10 |
| kyrofa | I guess I can log a bug over there | 21:11 |
| kyrofa | jdstrand, https://bugs.launchpad.net/snapd/+bug/1779416 | 21:24 |
| mup | Bug #1779416: Scripts in core snap attempt to do things impossible under confinement and die <snapd:New> <https://launchpad.net/bugs/1779416> | 21:24 |
| kyrofa | niemeyer, I guess you guys own the core snap these days? ^ | 21:25 |
| niemeyer | kyrofa: Yeah | 21:25 |
| niemeyer | Looking | 21:25 |
| niemeyer | kyrofa: Yeah, removing the line sounds fair | 21:28 |
| kyrofa | niemeyer, does spread provide a way to determine the OS under test? | 22:22 |
| kyrofa | In a task, I mean | 22:23 |
| kyrofa | Ooo, $SPREAD_SYSTEM maybe | 22:24 |
| niemeyer | kyrofa: Yeah, exactly | 22:55 |
| niemeyer | All the "matrix" is exposed as vars | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!