| mborzecki | morning | 05:16 |
|---|---|---|
| mvo | mborzecki: I see two failures in your PR and in one of my PRs related to arch: snap-run (that tests strace) and interfaces-timezone-control start failing it seems, did anything in arch change? | 06:49 |
| mvo | mborzecki: this is very recent, probably started ~during the night | 06:49 |
| mborzecki | mvo: systemd got updated recently, that may affect timedatectl | 06:49 |
| mborzecki | mvo: systemctl --version | 06:50 |
| mborzecki | systemd 239 | 06:50 |
| mvo | mborzecki: chipacas pr fails in the same two tests, so does mine | 06:51 |
| mborzecki | mvo: i can look into it | 06:51 |
| mborzecki | timedatectl is probably something silly | 06:51 |
| mborzecki | run --strace may be more interesting | 06:51 |
| mborzecki | (although i used it yday and saw no issues) | 06:52 |
| mvo | mborzecki: ok I just started snap-run with --debug to get an idea | 06:52 |
| mvo | mborzecki: I bet with the next master merge we will see master failing as well | 06:52 |
| mborzecki | mvo: yup, most likely | 06:52 |
| mvo | /var/lib/snapd/snap/strace-static/current/bin/strace: Unexpected wait status 0x8b | 06:59 |
| mvo | error: exit status 1 | 06:59 |
| mborzecki | aah it's using strace from snap | 07:00 |
| mvo | mborzecki: how can I install the system strace? | 07:00 |
| mborzecki | mvo: pacman -S strace | 07:00 |
| mvo | mborzecki: its using the snap as a fallback | 07:00 |
| mvo | mborzecki: aha! that worked | 07:01 |
| mvo | mborzecki: so I will add strace to the default packages for arch | 07:01 |
| mvo | mborzecki: one problem down .) | 07:01 |
| mborzecki | mvo: yes, please do | 07:01 |
| mborzecki | mvo: do we need to rebuild strace-static snap maybe? | 07:01 |
| mvo | mborzecki: thanks for your help with this one? | 07:01 |
| mvo | mborzecki: s/?/!/ | 07:01 |
| === pstolowski|afk is now known as pstolowski | ||
| mvo | mborzecki: good idea, let me have a look at strace-static | 07:01 |
| mborzecki | mvo: i'm looking into timedatectl | 07:02 |
| mvo | mborzecki: it should be pretty recent but probably not enough so | 07:02 |
| mvo | mborzecki: \o/ | 07:02 |
| pstolowski | mornings | 07:02 |
| mvo | pstolowski: good morning | 07:02 |
| mborzecki | mvo: the package one is 4.23 | 07:02 |
| mborzecki | pstolowski: hey | 07:02 |
| mvo | mborzecki: hm, arch seems to have the same version | 07:03 |
| mborzecki | mvo: i meant the arch package one is 4.23, the one from strace-static is 4.20 | 07:03 |
| mvo | mborzecki: aha, ok | 07:06 |
| mup | PR snapd#5480 opened: tests: add strace to default arch packages <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5480> | 07:06 |
| mborzecki | mvo: that timedatectl problem seems to be some sort of race | 07:09 |
| mvo | mborzecki: interessting, maybe they changed the dbus communication or something and now it returns before all changes are made | 07:12 |
| mborzecki | hm | 07:13 |
| mborzecki | mvo: https://paste.ubuntu.com/p/jpts966WWh/ | 07:17 |
| mborzecki | mvo: set-ntp behaves the same | 07:18 |
| mvo | mborzecki: hm, so racy and we just need to loop over the output for a bit? | 07:20 |
| mborzecki | mvo: yes, adding it now | 07:20 |
| mvo | ta | 07:20 |
| zyga | good morning | 07:25 |
| zyga | I think yesterday was the sweet spot of sleep/work cycle, I feel rested and not sleepy | 07:25 |
| zyga | mvo: I woke up earlier but I was busy with housework | 07:25 |
| zyga | mvo: we can have a call shortly | 07:26 |
| mvo | zyga: sounds good, I will make a cup of tea and then I'm ready | 07:26 |
| mvo | zyga: I had to add https://github.com/snapcore/snapd/pull/5478/commits/304e27a5b3735f34ebd6ac85fdb0be431c3a50a4 to fix unit tests | 07:27 |
| mup | PR #5478: many: run core18 tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5478> | 07:27 |
| zyga | aha! | 07:27 |
| mvo | zyga: without that firstboot test fails, but my PR now only fails in two arch tests that are unrelated (and are in the process of being fixed) | 07:27 |
| newbee | hi, i want to know is the ubuntu core 16 is 32 bit or 64 bit architecture. please help me | 07:27 |
| zyga | I removed it because pedronis asked if we could use the production id instead | 07:27 |
| zyga | newbee: we support 4 architectures | 07:28 |
| mvo | zyga: yeah, we can do that too, just needs some reworks in the firstboot test | 07:28 |
| zyga | newbee: x86, x86_64, armv7 and aarch64 | 07:28 |
| zyga | newbee: two of thoes are 32bit and the other two 64bit | 07:28 |
| zyga | mvo: ok, let's add that to the todo list | 07:28 |
| zyga | mvo: can snap-ids be forged easily? | 07:28 |
| mvo | zyga: yeah | 07:29 |
| mvo | zyga: in tests | 07:29 |
| mvo | zyga: in the real world I think not | 07:29 |
| newbee | ok, so when i install the ubuntu core on Raspberry pi 3 model B(ARMv8), getting the error for serial communication. | 07:30 |
| mvo | zyga: very exciting! the integration PR has only 3 failures all in non-core18 | 07:30 |
| * mvo goes and makes a cup of tea to celebrate | 07:30 | |
| newbee | is there any version for ARMv8 ubuntu core for raspberry pi 3 Model B. I have downloaded the ubuntu core from https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 and installed on Raspberry pi 3 model B | 07:33 |
| zyga | newbee: no because that board doesn't support ARMv8 in practice, | 07:34 |
| zyga | newbee: that is, the hardware is there but last time I checked the required early-boot code that toggles to aarch64 is not publicly available | 07:35 |
| zyga | newbee: all raspberry pi boards are (still) running in ARMv7 (except for those with older CPUs that use even older v6 instruction set) | 07:36 |
| newbee | Ok thanks, i have checked in the ubuntu release, found that ubuntu core version is 16, is there any other version available ? | 07:38 |
| zyga | newbee: we are working on the 18 release | 07:39 |
| zyga | newbee: it should be available a little bit before ubuntu classic 18.10 | 07:39 |
| newbee | so we have to wait to work on 64 bit (ARMv8 - Raspberry pi), am i right please correct me. | 07:40 |
| zyga | newbee: raspberry pi aarch64 mode is entirely up to the pi foundation, we have no influence over any release dates | 07:41 |
| zyga | newbee: I suspect it is more of a design decision to keep the ecosystem simple and unified around a pair of architectures (armv6+armv7) rather than three | 07:42 |
| zyga | newbee: you can get other devices today that run in aarch64 mode | 07:42 |
| zyga | mvo: ready when you are | 07:42 |
| newbee | :-).. actullay we have installed and ran our app in Intel NUC as per you guys guidlines, now we are trying for raspberry pi, please suggest me can i try in raspberry pi 2 | 07:44 |
| mup | PR snapd#5481 opened: tests/main/interfaces-timeserver-control: account for non-immediate changes with systemd >= 239 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5481> | 07:47 |
| mborzecki | mvo: ^^ | 07:47 |
| mborzecki | mvo: one quirk, both PRs (yours and mine) will fail on their own :P | 07:47 |
| mborzecki | mvo: can you merge yours? it failed on google:arch-linux-64:tests/main/interfaces-timeserver-control as expected | 07:48 |
| mvo | mborzecki: sure, I can merge yours or you merge mine | 07:50 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | newbee, you really dont want to run armv8 on a 1GB RAM board ... v8 binaries allocate twice the amount of RAM by default when running | 08:00 |
| mborzecki | mvo: merge yours, it alreay ran, i'll restart the build on mine then | 08:00 |
| mup | PR snapd#5482 opened: tests: fix tests on arch <Created by mvo5> <https://github.com/snapcore/snapd/pull/5482> | 08:01 |
| ogra_ | newbee, what are the benefits you expect of running v8 on a Pi ? will you do a lot of number-crunching and heavy math operations on it ? | 08:01 |
| mvo | mborzecki: snap :) | 08:02 |
| mborzecki | mvo: ta | 08:09 |
| mup | PR snapd#5481 closed: tests/main/interfaces-timeserver-control: account for non-immediate changes with systemd >= 239 <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5481> | 08:10 |
| jamesh | mvo: I can't push branches to ~snappy-dev, but the source code to test-snapd-eds is in the snapd tree | 08:16 |
| mborzecki | pedronis: hi, could you do a quick sanity check on https://github.com/snapcore/snapd/pull/5426 in case something non-obvious is missing? | 08:20 |
| mup | PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426> | 08:20 |
| Chipaca | pedronis: o/ | 08:27 |
| pedronis | mborzecki: yes, I plan to do reviews today | 08:29 |
| pedronis | Chipaca: hi | 08:29 |
| mborzecki | pedronis: great, thanks! | 08:29 |
| mup | PR snapd#5482 closed: tests: fix tests on arch <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5482> | 08:30 |
| Chipaca | pedronis: #5479 is the scope pr | 08:30 |
| mup | PR #5479: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <https://github.com/snapcore/snapd/pull/5479> | 08:30 |
| pedronis | Chipaca: ah, thanks, I missed it (somehow) | 08:31 |
| mup | PR snapd#5480 closed: tests: add strace to default arch packages <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5480> | 08:31 |
| Chipaca | pedronis: I should've gone with a more clickbaity title maybe | 08:31 |
| pedronis | Chipaca: I think is more of a case of too many PRs | 08:32 |
| mvo | Chipaca: I labeled that 2.34 - is that correct? | 08:32 |
| Chipaca | mvo: I believe so | 08:32 |
| mvo | excellent | 08:33 |
| mvo | jamesh: thank you, I will take care of it then | 08:33 |
| mborzecki | mvo: we need to pick the test fixes for 2.34 | 08:36 |
| mvo | mborzecki: indeed, let me do that | 08:36 |
| pedronis | Chipaca: afaict scope=wide is only about risk, not finding other archs? am I missing something | 08:37 |
| Chipaca | pedronis: ah i might've misunderstood | 08:37 |
| Chipaca | let me test | 08:38 |
| Chipaca | pedronis: you are correct | 08:38 |
| Chipaca | pedronis: i'll fix that | 08:38 |
| pedronis | Chipaca: +1 with a couple of wonderings, also related to that | 08:40 |
| Chipaca | pedronis: I thought the argument was about risks and architecture (ie have it be a driving force towards stable + multi-arch), but I misunderstand things a lot | 08:40 |
| pedronis | Chipaca: I always saw it called "find edge and beta in search" | 08:40 |
| Chipaca | k | 08:41 |
| pedronis | maybe there's a general misunderstanding, not sure | 08:41 |
| phako | hi - I'm currently struggeling to get software running that loads plugins from /usr/lib/x86_64/ - it claims that it cannot find the libraries - what exactly am I missing there? | 08:41 |
| Chipaca | architectures was about info i guess | 08:41 |
| pedronis | Chipaca: worth poking roadmr when is around | 08:41 |
| pedronis | Chipaca: yes, indeed some errors cannot refert to info because info doesn't do multi-arch | 08:41 |
| Chipaca | phako: try 'snap run --shell your.app' and look in *that* /usr/lib | 08:41 |
| phako | well they are in the squashfs | 08:42 |
| phako | but let me check | 08:42 |
| Chipaca | phako: maybe your LD_LIBRARY_PATH is wrong then | 08:42 |
| phako | hm, they are indeed missing from the shell | 08:42 |
| phako | odd | 08:42 |
| mup | PR snapd#5483 opened: tests: fix arch tests (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5483> | 08:42 |
| Chipaca | phako: the squashfs isn't at / | 08:42 |
| phako | ah! | 08:42 |
| Chipaca | phako: so if they're in the squashfs they'll be under $SNAP | 08:43 |
| Chipaca | phako: so your library path should have something like $SNAP/usr/lib/yadda | 08:43 |
| phako | not sure that works, might be that gphoto is looking for hardcoded paths | 08:43 |
| phako | sec | 08:44 |
| Chipaca | phako: might be that you need to build it from source to look at the other paths then :-) | 08:44 |
| phako | bah. :) | 08:44 |
| Chipaca | phako: if it's regular dynamic libs, setting LD_LIBRARY_PATH should work | 08:45 |
| Chipaca | phako: if it's doing plugins and dlopening stuff, it might be looking in more than one place (maybe via XDG_* env vars) | 08:46 |
| Chipaca | figuring out the latter is a lot of fun | 08:46 |
| phako | well for shotwell I'm pretty sure it looks in the hardcoded libdir (fixable) for gphoto I'd actually have to check the code | 08:46 |
| Chipaca | (in the early days we even submitted patches to, iirc, xkb so you could override where it looked for stuff) | 08:46 |
| Chipaca | anyhoo, good luck :) | 08:47 |
| phako | thx | 08:47 |
| pedronis | mborzecki: #5426 looks fine, the questions are more what we will do in api.go. just left a small comment | 08:49 |
| mup | PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426> | 08:49 |
| pedronis | mvo: what's blocking #5422 ? | 08:52 |
| mup | PR #5422: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/5422> | 08:53 |
| mvo | pedronis: aha, I think this one is good now, iirc yesterdays tests were unhappy, let me squash-nmerge it (and cherry-pick) | 08:53 |
| phako | Chipaca: hah - gphoto2 actually has an environment variable for that. cool | 08:54 |
| mup | PR snapd#5422 closed: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5422> | 08:54 |
| Chipaca | phako: winning | 08:56 |
| pedronis | Chipaca: probably worth linking to the PR from the topic | 08:56 |
| mvo | 5476 needs a second review, maybe Chipaca has some cycles for this? | 08:56 |
| Chipaca | hmm, google:arch-linux-64:tests/main/interfaces-timeserver-control and google:arch-linux-64:tests/main/snap-run have failed twice in a row | 08:57 |
| mvo | very few 2.34 milestoned PRs left :) | 08:57 |
| Chipaca | mborzecki: do you know anything about that ^? | 08:57 |
| mvo | Chipaca: yeah, we fixed it this morning | 08:57 |
| Chipaca | mvo: i'll take a look | 08:57 |
| mvo | Chipaca: just merge msater | 08:57 |
| Chipaca | mvo: w00t | 08:57 |
| mvo | master even | 08:57 |
| Chipaca | no, no, now i'm going to merge msater | 08:57 |
| Chipaca | too late to change it | 08:57 |
| mvo | lol | 08:57 |
| * mvo hugs Chipaca | 08:58 | |
| * Chipaca hugs mvo back | 08:58 | |
| phako | btw, is udev workin inside a snap? | 09:00 |
| Chipaca | pstolowski: ^ one for you i think | 09:02 |
| === matteo| is now known as matteo | ||
| pstolowski | phako: no | 09:14 |
| === chihchun is now known as chihchun_afk | ||
| mvo | zyga: we have a green run on 5478! | 09:18 |
| zyga | mvo: looking | 09:22 |
| zyga | mvo: wait, so holidays now? :D | 09:23 |
| mvo | zyga: :-D | 09:26 |
| Chipaca | mvo: so I need to squash things for 2.34? | 09:27 |
| phako | pstolowski: k, thanks | 09:28 |
| mvo | Chipaca: just if they have a gazillion of commits | 09:30 |
| pedronis | Chipaca: if they are not a single commit anyway, yes, easier to back-port | 09:30 |
| mvo | Chipaca: if you do the cherry-picking and proposing I don't mind | 09:30 |
| mvo | Chipaca: I mean, its just convenient | 09:30 |
| mup | PR snapd#5476 closed: snapstate: make sure all *link-*snap tasks carry a snap type and further hints <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5476> | 09:43 |
| Chipaca | bbiab | 09:45 |
| mup | PR snapd#5484 opened: snapstate: make sure all *link-*snap tasks carry a snap type and further hints (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5484> | 09:46 |
| zyga | mvo: ok, I have it | 09:46 |
| zyga | mvo: I will push in a moment | 09:46 |
| pedronis | mvo: anoteher backport ^ | 09:47 |
| mvo | pedronis: yay | 09:47 |
| mvo | pedronis: thank you | 09:47 |
| pedronis | still waiting for 5197 to get green | 09:53 |
| zyga | mvo: ok, ready now | 09:54 |
| zyga | pushing to two PRs | 09:54 |
| zyga | man, something is wrong with my network in ubuntu :/ | 09:57 |
| zyga | mvo: I pushed https://github.com/snapcore/snapd/pull/5439/commits/ca539763589fc20536dea6180cb25292ec55431c | 10:01 |
| mup | PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5439> | 10:01 |
| zyga | mvo: I also pushed https://github.com/zyga/snapd/commits/feature/core18-snapd-implicit | 10:02 |
| zyga | mvo: out of that the essence of what I told you about is: https://github.com/zyga/snapd/commit/09bf3fb17fbad8db32e2b3e2bcca2af74c451733 | 10:02 |
| zyga | mvo: the part that I said was missing in the test branch is now done as https://github.com/zyga/snapd/commit/5deb5e89be201f07b80d7d3d8e953156beaaa958 | 10:03 |
| mvo | zyga: cool, I check in a sec | 10:04 |
| zyga | and there are some follow up clenaups there | 10:04 |
| zyga | mvo: my suggestion is to take your integration branch, yank all my prior patches that are not in master and add just https://github.com/snapcore/snapd/pull/5485 | 10:06 |
| mup | PR #5485: testing: support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5485> | 10:06 |
| mup | PR snapd#5485 opened: testing: support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5485> | 10:06 |
| zyga | mvo: the only remaining thing I strongly know about is remaping of outgoing API responses | 10:07 |
| zyga | mvo: so what's next, what should I focus on? | 10:12 |
| zyga | mvo: I have some branches I can work on for interfaces | 10:12 |
| zyga | mvo: we could also talk to pedronis to explain the approach we took | 10:13 |
| mvo | zyga: yeah, I think the next step is to sync with gustavo and samuele to get advice | 10:15 |
| mvo | zyga: I merge/run your PRs now in the integration branch | 10:15 |
| zyga | thank you | 10:22 |
| zyga | mvo: you can keep the one patch I didn't include here, the one that does simple remapping in the client | 10:23 |
| zyga | mvo: or one of the tests will fail, but this is not that important | 10:23 |
| mvo | zyga: $ snap interfaces -i network now shows: "snapd:network network-consumer" before it was showing ":network" | 10:39 |
| zyga | this is what I meant above ^ | 10:39 |
| zyga | it was client-side remapping that was -1 by pedronis | 10:39 |
| mvo | zyga: aha, ok | 10:39 |
| zyga | the code there is a bit weird IMO as it does cliend side remapping anyway (for system) | 10:40 |
| ogra_ | when will the urandom fix land in edge (or did it already) ? | 10:40 |
| ogra_ | (working on my kiosk images firstboot on a pi3 takes around 8min til mir-kiosk and chromium are seeded ... i just noticed wiggling the mouse cuts that down to 5min so there is some chance the fix will help with slow arm firstboot too) | 10:41 |
| ogra_ | (talking about the snapd workaround obviously ... ) | 10:42 |
| zyga | mvo: you can try this: | 10:42 |
| zyga | use "nick" to perhaps understand parts of snapd snap https://www.irccloud.com/pastebin/qHO4nsvj/ | 10:42 |
| mvo | ogra_: our fix does unfortunately not help with the real seeding issue | 10:42 |
| pstolowski | zyga: can https://github.com/snapcore/snapd/pull/5433 be turned into +1? ;) i'm happy to discuss why it's needed | 10:42 |
| mup | PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433> | 10:42 |
| zyga | pstolowski: let me look | 10:43 |
| mvo | ogra_: when seeding happens for real we need real randomness and that will block until the kernel is fixed - what version of the kernel do you use? | 10:43 |
| mvo | zyga: that was the part that was NACKed ? | 10:43 |
| zyga | mvo: no, I did an explicit abbreviation of both "core" and "snapd" in cmd_interface* | 10:44 |
| ogra_ | mvo, whatever is in edge, one sec ... | 10:44 |
| pedronis | mvo: to be clear I didn't nack, I'm just generally confused why we do that in the client and not the api | 10:44 |
| zyga | mvo: the nick idea is IMO broken | 10:44 |
| zyga | mvo: if we want system we had a PR for that | 10:44 |
| ogra_ | mvo, pi2-kernel 4.4.0-1092.100 (56) | 10:44 |
| zyga | if we don't want system, what do we want? core or snapd? | 10:44 |
| zyga | mvo: this is related to the question about for how long we should re map the outgoing state | 10:44 |
| zyga | (not related to rollbacks) | 10:44 |
| pedronis | mvo: it seems a hack that started with core vs ubuntu-core | 10:44 |
| zyga | that is when we should show users that it is really snapd that holds the slots | 10:44 |
| mvo | ogra_: did that kernel get the crng change? I thought that was 4.8+ only | 10:44 |
| pedronis | and then it kept growing | 10:45 |
| pedronis | but is a bit unclear it's the right place for it | 10:45 |
| pedronis | it just keeps growing | 10:45 |
| zyga | pedronis: the iteration of remapping is going to re-map the outgoing API as well | 10:45 |
| mvo | pedronis, zyga yeah, I will update the test and we can think about a better way | 10:45 |
| zyga | pedronis: that's hte only remaining part | 10:45 |
| zyga | pedronis: I agree, I would rather remove the nick concept altogether but I'm not sure why we introduced it | 10:45 |
| mborzecki | pedronis: i'm gonna land #5426 | 10:45 |
| mup | PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426> | 10:46 |
| pedronis | zyga: maybe we are not talking about the same thing | 10:46 |
| pedronis | (me is a bit confused) | 10:46 |
| zyga | pedronis: I think you are referring to an earlier RFC patch where I was abbreviating "snapd" like we abbreviate "core" | 10:46 |
| zyga | pedronis: on the client side | 10:46 |
| ogra_ | mvo, i dont think the 4.4 kernel had any issue, my hope was the dropping of getrandom() in some places in snapd might help in general here... but if the actual seeding isnt involved in that thats indeed moot | 10:46 |
| zyga | pedronis: is that correct? | 10:46 |
| pedronis | well, we want to do that | 10:47 |
| pedronis | the question is where to achieve it | 10:47 |
| mup | PR snapd#5459 closed: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5459> | 10:47 |
| zyga | abbreviation was always client side | 10:47 |
| mborzecki | mvo: #5455 can be landed too? | 10:47 |
| zyga | I think to answer the how part we need to decide what to do long term | 10:47 |
| mup | PR #5455: many: assorted shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5455> | 10:47 |
| zyga | will we pretend core has the slots? | 10:47 |
| zyga | (not in the state but in the user-visible places) | 10:47 |
| pedronis | zyga: I think the hack as it was existed because of core vs ubuntu-core | 10:47 |
| zyga | the hack being the nick concept? | 10:48 |
| mup | PR snapd#5426 closed: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5426> | 10:48 |
| pedronis | zyga: no the fact that in the client we check for core, then it became ubuntu-core, then system (not even sure why) and now snapd | 10:49 |
| pedronis | this is getting out of hand | 10:49 |
| === pstolowski is now known as pstolowski|lucnh | ||
| === pstolowski|lucnh is now known as pstolowski|lunch | ||
| zyga | pedronis: I think this grew out of the desire to have explicit and non-magic API and a bit of magic in the CLI to make users life easier | 10:49 |
| zyga | if we abbreviate on the server then this is an API break | 10:50 |
| pedronis | but the api now is kind of magic anyway | 10:50 |
| pedronis | because you can use core even if it doesn't exist | 10:50 |
| pedronis | no? | 10:50 |
| pedronis | it's magic on the way in, but not out? | 10:50 |
| zyga | yes, but that is backwards compatible | 10:50 |
| zyga | I plan to make it magic on the way out, yes | 10:51 |
| zyga | my only real issue now is how long we keep the magic | 10:51 |
| zyga | and if we can kill the nick concept once we decide | 10:51 |
| zyga | for state we can keep the magic indefinitely really | 10:51 |
| zyga | I'm not sure if there is real value in keeping the magic in the API for too long | 10:52 |
| zyga | (and the state should drop the magic once we have epochs and a single snapd that doesn't roll back) | 10:52 |
| pedronis | zyga: to be fair I'm also not sure why we have: || slot.Snap == snap.UseNick("core") ? | 10:52 |
| pedronis | when does the api return system there? | 10:52 |
| zyga | I don't think we ever do that | 10:53 |
| zyga | it feels like dead code IMO | 10:53 |
| zyga | let me check | 10:53 |
| zyga | pedronis: the interface repo which answers that query never talks about "system" | 10:53 |
| zyga | so perhaps just symmetric but unused code | 10:54 |
| pedronis | yes, something is off there | 10:54 |
| zyga | yes, agreed | 10:54 |
| zyga | I'm happy to clean it up once there is agreement on what to do exactly | 10:54 |
| zyga | my gut feeling is: | 10:54 |
| zyga | remap both sides completely for now | 10:55 |
| mup | PR snapd#5197 closed: cmd/snap: display a link to data privacy notice for interactive snap login <Simple> <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5197> | 10:55 |
| zyga | drop system nick idea (why do we have it if this is the only instance of the "system" term in the whole interfaces and we explicitly chose not to do a "system" snap that holds slots) | 10:55 |
| zyga | once epochs land migrate the state | 10:55 |
| zyga | once we feel like it stop talking about core as host in the API and start to refuse "connect foo:network core:network" | 10:55 |
| zyga | that's my rough idea that is least disruptive and most consistent | 10:56 |
| mup | PR snapd#5440 closed: snapstate: allow setting "refresh.timer=managed" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5440> | 10:56 |
| pedronis | zyga: well, we have it for symmetry with the use in gadget defaults | 10:56 |
| pedronis | also now connections accepts it too | 10:57 |
| zyga | interesting | 10:57 |
| zyga | hmm | 10:57 |
| zyga | well, maybe that should say snapd instead? | 10:57 |
| zyga | I mean, it's half half now | 10:57 |
| pedronis | it's even the only spelling | 10:57 |
| zyga | not all the way in | 10:57 |
| pedronis | well, we decided not to use snapd | 10:57 |
| pedronis | for defaults | 10:57 |
| pedronis | it was an explicit decision | 10:57 |
| mborzecki | system was to be used there (among other things iirc) | 10:58 |
| pedronis | zyga: the issue is essentially core, snapd in the end are implemetnation details | 10:58 |
| pedronis | if we keep exposing them, we keep needing to migrate people away | 10:58 |
| zyga | pedronis: this feels like a one way mapping though, people ask for system, get snapd | 10:59 |
| zyga | pedronis: it is also odd that you see system as a snap name | 11:00 |
| zyga | but it's not installed, has no info, etc | 11:00 |
| zyga | it feels okay if this is an "alias" of some sort | 11:00 |
| pedronis | well, it's odd that system plugs are on a snap or another | 11:00 |
| pedronis | lots of things are odd | 11:00 |
| zyga | perhaps but at least it is a real snap you can see | 11:00 |
| zyga | it really doesn't matter which as long as we are clear about the semantics, my point is that right now we are not clear because it's sometimes system, sometimes core | 11:01 |
| zyga | and with the introduction of snapd it's a growing complexity problem | 11:01 |
| zyga | the api talks about "core" | 11:01 |
| zyga | the users see "system" | 11:01 |
| pedronis | remember as well that we planned to deprecate that api/comamnd | 11:02 |
| pedronis | wasn't pawel working on something else called connections? | 11:02 |
| zyga | this is not just here, it's also visible in the new api | 11:02 |
| zyga | snap interface is the new api and it is visible (core) there | 11:02 |
| pedronis | but that work isn't finished | 11:02 |
| zyga | the connections api is not written down anywhere so I cannot comment | 11:03 |
| zyga | the interface work is finished, the connection is not | 11:03 |
| zyga | (singular interface) | 11:03 |
| pedronis | zyga: correct, see what it says for "snap interface network" under slots | 11:04 |
| zyga | in the client it says system (client side remapping) | 11:04 |
| zyga | in the api it says core | 11:04 |
| mup | PR snapd#5478 closed: many: run core18 tests <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5478> | 11:04 |
| pedronis | zyga: we need a bit to decide if it should keep saysing core or snapd or system | 11:05 |
| zyga | I agree | 11:05 |
| pedronis | we are changing something either way | 11:05 |
| zyga | what was the rationale to use system in the gadget configuration language? | 11:05 |
| pedronis | (I'm also not entirely sure we anything is using those apis programatically atm) | 11:05 |
| zyga | pedronis: at the very least gnome software is using them | 11:06 |
| zyga | I believe this is where it gets the interface summary from, at least | 11:06 |
| mup | PR snapd#5484 closed: snapstate: make sure all *link-*snap tasks carry a snap type and further hints (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5484> | 11:10 |
| mborzecki | zyga: iirc not all api pieces could do remapping of system/core due to the risk of breaking the api | 11:11 |
| zyga | mborzecki: can you give me an example? | 11:11 |
| mup | PR snapd#5483 closed: tests: fix arch tests (2.34) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5483> | 11:11 |
| mborzecki | zyga: i think that snap interface foo is remapped at the client side | 11:12 |
| zyga | but foo is the interface name, not plug or slot name | 11:12 |
| zyga | interface talks about interfaces, not plugs and slots, as the primary concept | 11:12 |
| zyga | connections will have this issue | 11:12 |
| mborzecki | zyga: well whatever was coming down in snap interface(s) queries was being remapped at the client side | 11:14 |
| zyga | mborzecki: currently only the "system" <=> "core" is remapped | 11:14 |
| mborzecki | zyga: yes | 11:14 |
| zyga | but again partially, you cannot see "system" slots via snap interface*s* | 11:15 |
| zyga | we just have to decide what we want | 11:15 |
| pedronis | mvo: are you doing the cherry-pick for the snap login change? | 11:16 |
| mvo | pedronis: yes | 11:16 |
| pedronis | thx | 11:16 |
| mvo | pedronis: its in 2.34 now, waiting for the full branch test run right now, tests are very unhappy today it seems | 11:17 |
| pedronis | yes, I see a lot of red there | 11:19 |
| mup | PR snapd#5486 opened: tests: run all spread tests on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5486> | 11:20 |
| mvo | pedronis: I am checking right now for patterns but nothing emerging currently | 11:22 |
| * mvo considers lunch | 11:23 | |
| zyga | ok, I have functional response remapping now | 11:24 |
| zyga | mvo: I'll push them to 5485 | 11:39 |
| mvo | zyga: oh, neat | 11:40 |
| zyga | pushed now | 11:40 |
| mvo | zyga: this means the interface-cli test does not need any change anymoreß | 11:41 |
| mvo | ? | 11:41 |
| zyga | yes | 11:41 |
| zyga | settle is not converging https://www.irccloud.com/pastebin/dW6uZhJt/ | 11:41 |
| mvo | zyga: right - one sc | 11:42 |
| zyga | I need to re-map legacy responses as well | 11:42 |
| mvo | zyga: thats the patch I told you about | 11:42 |
| zyga | aha | 11:42 |
| zyga | I will do legacy remapping now | 11:42 |
| zyga | (legacy "snap interfaces" response) | 11:42 |
| mvo | zyga: https://github.com/snapcore/snapd/pull/5486/commits/3be7a6ac8c4ee462ed53b5ff2fa8a5ec18f43aa6 | 11:42 |
| mup | PR #5486: tests: run all spread tests on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5486> | 11:43 |
| mvo | zyga: either this or tweaking the firstboot_test to include the snap-id of the production snapd | 11:43 |
| zyga | thanks, I'll cherry-pick that | 11:43 |
| zyga | odd, I don't have the base patch in my working branch | 11:44 |
| zyga | but the helpers landed, no? | 11:44 |
| zyga | I mean the policy work | 11:44 |
| zyga | well, that's fine anyway | 11:44 |
| zyga | mvo: once you cherry pick those patches and run the tests let me know, ok? | 11:48 |
| mvo | sure | 11:48 |
| zyga | thanks! | 11:49 |
| zyga | I need to do a housework errand before my wife gets here :) | 11:49 |
| mvo | zyga: https://github.com/snapcore/snapd/pull/5486 - green | 11:50 |
| mup | PR #5486: tests: run all spread tests on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5486> | 11:50 |
| zyga | ok :) | 11:51 |
| mvo | Chipaca: 5479 is green and has two +1, can I merge and cherry-pick? | 11:52 |
| Chipaca | mvo: woo! yes :-) | 12:03 |
| Chipaca | mvo: squash also if you wish | 12:03 |
| === pstolowski|lunch is now known as pstolowski | ||
| mup | PR snapd#5479 closed: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5479> | 12:06 |
| Chipaca | mvo: :-D thank you | 12:06 |
| Chipaca | landing code makes me happy | 12:06 |
| pedronis | pstolowski: I did a pass again over disconnect-hooks, I'm a bit confused by the new code in checkConnectConflicts, something seems off | 12:07 |
| mvo | Chipaca: what makes me happy is that all targeted PRs are in | 12:10 |
| mvo | wooot | 12:10 |
| pstolowski | pedronis: thanks, let me think | 12:10 |
| Chipaca | mvo: that's because you've leveled up | 12:10 |
| mvo | Chipaca: level three tea drinker, yay! | 12:10 |
| Chipaca | mvo: we should have a sprint in london just to go have posh tea sometime | 12:11 |
| mvo | Chipaca: oh yes! | 12:11 |
| mborzecki | Chipaca: could you take a look at https://github.com/snapcore/snapd/pull/5455 ? some shellcheck cleanups | 12:17 |
| mup | PR #5455: many: assorted shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5455> | 12:17 |
| Chipaca | mborzecki: first, tea | 12:17 |
| Chipaca | post-lunch tea is best tea | 12:18 |
| mborzecki | Chipaca: thanks, and enjoy your tea! | 12:18 |
| mup | PR snapd#5487 opened: overlord/snapstate: improve PlugsOnly comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/5487> | 12:22 |
| vidal72[m] | FYI apparmor is now build-in in one of Archlinux kernels: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux-hardened&id=14eccc6c604d37fa3001146f5bd4ca32ffa15c4f | 12:30 |
| zyga | vidal72[m]: that is very interesting. Is it enabled by default as well? | 12:31 |
| vidal72[m] | zyga: no | 12:32 |
| vidal72[m] | zyga: probably never will be but at least it's something :) | 12:33 |
| zyga | mvo: I'll look after some apparmor work now | 12:45 |
| mup | PR snapd#5455 closed: many: assorted shellcheck fixes <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5455> | 12:46 |
| mborzecki | vidal72[m]: wow, surprising, do you know what was the motivation? i don't recall this being announced on the dev/general mailing lists | 12:48 |
| vidal72[m] | mborzecki: the motivation was user requests, that's tiny change in general and mantainers don't have to explain their choices in ML | 12:50 |
| mborzecki | vidal72[m]: well that's the backstory about linux-hardnend :P | 12:51 |
| mborzecki | vidal72[m]: any clue if the userland bits will come to the main repos? | 12:51 |
| vidal72[m] | mborzecki: it depens on some TU/dev wanted to mantain it. For now there is no interest | 12:54 |
| mup | PR snapd#5488 opened: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488> | 12:56 |
| vidal72[m] | mborzecki: but compiling userspace isn't a big deal after all | 12:56 |
| mborzecki | vidal72[m]: but it touches quite a bit of core packages | 12:57 |
| mborzecki | vidal72[m]: and it's still some building you have to do | 12:57 |
| vidal72[m] | mborzecki: ah, do you mean enabling apparmor support in system tools like systemd? That's out of question for now but I think it's not necessary for using apparmor. Apparmor userspace tools are enough | 13:02 |
| jdstrand | vidal72[m]: that's good news :) and yes, I agree that userspace tooling should be enough. not all that much really needs libapparmor and adding it over time (eg, like systemd) seems a fine way to go | 13:11 |
| zyga | mvo: I'm very happy with the outcome now, I will drive towards system being the first class slot holder across the API | 13:30 |
| vidal72[m] | how long till core18 will replace core16? | 13:36 |
| Chipaca | mborzecki: google:arch-linux-64:tests/main/interfaces-timeserver-control moaning again: https://api.travis-ci.org/v3/job/400865901/log.txt | 13:37 |
| Chipaca | mborzecki: :-) | 13:37 |
| Chipaca | vidal72[m]: <----- this much time -----> | 13:37 |
| mborzecki | Chipaca: hm the log is awfully short | 13:38 |
| Chipaca | mborzecki: gah! somebody restarted it :-( | 13:38 |
| Chipaca | i shoulda saved it | 13:38 |
| Chipaca | vidal72[m]: more seriously, AFAIK (but mvo might know more) we're aiming to 18.10 timeframe but not promising it | 13:39 |
| mborzecki | Chipaca: which pr is this? | 13:39 |
| Chipaca | mborzecki: #5487 | 13:39 |
| mup | PR #5487: overlord/snapstate: improve PlugsOnly comment <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5487> | 13:39 |
| vidal72[m] | Chipaca: thx | 13:43 |
| Pharaoh_Atem | vidal72[m]: fourth of never ;) | 13:47 |
| Chipaca | niemeyer: https://github.com/snapcore/snapd/pull/4792 | 13:51 |
| mup | PR #4792: overlord/snapstate: block install of "system" <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4792> | 13:51 |
| Chipaca | niemeyer: the error on 'info' is for fun, but the error on install is alright i think | 13:53 |
| Chipaca | anyway, school run time | 13:53 |
| niemeyer | Chipaca: Yeah, definitey ok on both ends | 13:54 |
| niemeyer | Chipaca: The one on info we can fix when we do the alias handling properly.. the other can stay as you point out | 13:54 |
| sparkiegeek | hmm, can't seem to get 'snap run --strace' to work (snapd 2.33.1) - I'm suspecting due to running it in a LXD container, is this "known"? | 14:01 |
| mvo | sparkiegeek: not known, what error do you get? | 14:03 |
| sparkiegeek | mvo: the very helpful "error: exit status 1" | 14:03 |
| mvo | sparkiegeek: *cough* quality error message | 14:03 |
| mvo | sparkiegeek: let me see | 14:03 |
| sparkiegeek | mvo: note installing the same snap on my host and trying it there worked just fine | 14:04 |
| * zyga hugs mvo who runs to debug issues just prior to starting holidays | 14:05 | |
| sparkiegeek | mvo: I tried to strace -ff the 'snap run --strace' but that got me into a hung process which resisted Ctrl-C and Ctrl-\ | 14:05 |
| mvo | sparkiegeek: do you get more with snap run --strace="--raw" | 14:05 |
| zyga | sparkiegeek: any denials? | 14:05 |
| mvo | zyga: aha, excellent idea | 14:05 |
| sparkiegeek | Jul 6 15:02:49 firestorm kernel: [62403.985473] audit: type=1400 audit(1530885769.599:1727): apparmor="DENIED" operation="open" profile="snap.snap-store-proxy.snap-store-proxy" name="/proc/14257/mounts" pid=14257 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 14:06 |
| sparkiegeek | 14:06 | |
| zyga | mmm, that's probably not the issue | 14:13 |
| zyga | not with hanging | 14:13 |
| * zyga needs to break now and tidy the house a little | 14:13 | |
| zyga | I will propose the remapping PR (without the remapping condition) | 14:13 |
| zyga | and the remapping condition (without the remapping) | 14:13 |
| zyga | to discuss next week | 14:13 |
| sparkiegeek | zyga: yeah, not that bothered by the hanging, strace of snapd doing strace inside an LXD is almost guaranteed to hit some weird corner cases :) | 14:18 |
| mvo | sparkiegeek: anything from snap run --strace="--raw" | 14:26 |
| Chipaca | sparkiegeek: did you see jd.strand's "how to strace"? might still be relevant for your use case | 14:26 |
| Chipaca | sparkiegeek: https://forum.snapcraft.io/t/stracing-snap-commands/1433 | 14:27 |
| sparkiegeek | mvo: https://paste.ubuntu.com/p/sCxNJ7Hdz3/ | 14:29 |
| mvo | sparkiegeek: interessting, out of curiosity, can you snap install strace-static --edge and see if that makes any difference? I doubt but worth a shot | 14:30 |
| sparkiegeek | mvo, zyga: https://paste.ubuntu.com/p/CxMYGH326c/ some denials | 14:31 |
| sparkiegeek | truomg strace-static now | 14:32 |
| zyga | there you go | 14:32 |
| sparkiegeek | eugh, off-by-one error on home-row :) | 14:32 |
| mvo | sparkiegeek: thats interessting | 14:32 |
| pedronis | mborzecki: does #5434 need a merge with master, I don't see the s/name/path/ change in there | 14:35 |
| mup | PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434> | 14:35 |
| mvo | zyga: maybe its a jamie question but can we get strace work inside lxd inside snapd? | 14:35 |
| pedronis | mborzecki: there's been quite a bit of churn with the 2.34 push, probably worth merging master in it either way | 14:37 |
| zyga | mvo: I think so | 14:52 |
| zyga | mvo: it looks like interplay of both profiles | 14:52 |
| pedronis | mborzecki: I looked a bit at #5452, seems some tests are missing, error code handling doesn't seem right for install and instance keys. also the code seems to assume sometimes but not always that download is not used with instance keys (which is fair, but need to be made more explicit) | 14:53 |
| mup | PR #5452: store, overlord/snapstate: introduce instance name in store APIs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5452> | 14:53 |
| pedronis | mborzecki: I mostly looked at store.go itself, before looking at the higher levels | 14:55 |
| pedronis | red, random red | 14:59 |
| * pedronis calls it a week | 15:00 | |
| pedronis | mvo: mborzecki: enjoy the vacations | 15:00 |
| mvo | pedronis: have a great weekend | 15:10 |
| mup | PR snapd#5489 opened: release: snapd 2.34 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5489> | 15:21 |
| cachio | mvo, hey, 2.34 is ready right? | 15:23 |
| mvo | cachio: yes, beta validation would be great if we are lucky it can make it to candidate today | 15:24 |
| mvo | cachio: and welcome back - I guess you had internet issues? | 15:24 |
| cachio | My machne is dead, I am using the backup | 15:24 |
| mvo | cachio: uh :( sorry to hear | 15:24 |
| cachio | mvo, I had to buy a new charger for it | 15:25 |
| mvo | cachio: if possible the sru validation for 2.33 (1773118) would be great, then I can prepare the 2.34 sru | 15:25 |
| cachio | sure | 15:25 |
| mvo | thanks cachio | 15:26 |
| cachio | mvo, is there any diff with the snapd 2.33.1 which I already validated last week? | 15:28 |
| cachio | mvo, is it a new one? | 15:28 |
| mvo | cachio: diff is absolutely trival http://launchpadlibrarian.net/377239984/snapd_2.33.1ubuntu1_2.33.1ubuntu2.diff.gz | 15:29 |
| mvo | cachio: so a smoke test is fine | 15:29 |
| mvo | cachio: I think the tags in the sru bug may need updating though but maybe I just misremember | 15:30 |
| mvo | (iirc some were still at validation-needed) | 15:30 |
| cachio | mvo, great | 15:30 |
| * zyga stopped mopping the floor for a sec | 15:34 | |
| zyga | it's not easy to maintain relative cleanness in the middle of the forest | 15:34 |
| cachio | mvo, is there a list of changes for 2.34 in http://people.canonical.com/~mvo/core-changes/html/beta/ ? | 15:35 |
| mvo | cachio: should be, let me check, its a cron job | 15:36 |
| Naan | hello it seems my spotify was installed automatically through snap and now I don't know how to force it to add "--force-device-scale-factor=1.5" as a command line option | 15:41 |
| Naan | by default i mean | 15:41 |
| Naan | uh never mind I just used an alias | 15:46 |
| Naan | bye! | 15:46 |
| mborzecki | pedronis: thanks for the review and enojoy your weekend! | 15:59 |
| Chipaca | mvo: late in the game, but what's the easiest way to get a directory made writable across the cores at this stage of the game? | 16:15 |
| niemeyer | kyrofa: Heya.. have a few minutes for a call now? | 16:20 |
| zyga | Chipaca: goat and a long knife | 17:07 |
| zyga | Chipaca: we could expand the core fixup script | 17:07 |
| zyga | Chipaca: what is the directory that you need to change? | 17:07 |
| Chipaca | zyga: mumble mumble mumble | 17:07 |
| zyga | Chipaca: also what do you mean by "across all the cores" | 17:08 |
| zyga | do you mean writable-paths writable | 17:08 |
| Chipaca | zyga: /usr/share/bash-completion/completions | 17:08 |
| zyga | or chmod +w writable | 17:08 |
| zyga | aha | 17:08 |
| zyga | and you want to drop files there? | 17:08 |
| Chipaca | I'm not sure how it slipped through the cracks, but, yeah | 17:08 |
| Chipaca | zyga: we try to drop files there, currently | 17:08 |
| Chipaca | well, symlink | 17:08 |
| zyga | oh | 17:08 |
| zyga | that's fun | 17:08 |
| zyga | so completions don't work on core? | 17:09 |
| Chipaca | oh hold on | 17:09 |
| Chipaca | a ghost of a memory is coming back to me | 17:09 |
| Chipaca | let me test something | 17:09 |
| mvo | Chipaca: what directory is that? | 17:09 |
| zyga | Chipaca: ghost of past releases | 17:09 |
| zyga | (chains rattling) you will pay your tech debt | 17:09 |
| Chipaca | sorry, mis-click | 17:09 |
| mvo | zyga: /usr/share/bash-completion/completions ? is that the dir? | 17:09 |
| Chipaca | mvo: yes | 17:09 |
| zyga | mvo: I think I know as much as chipaca just told me | 17:09 |
| Chipaca | but it might not be needed | 17:09 |
| zyga | Chipaca: do we really drop files there? | 17:10 |
| Chipaca | on classic, we drop snippets in there | 17:10 |
| mvo | Chipaca: right | 17:10 |
| Chipaca | well, we symlink | 17:10 |
| Chipaca | but in core | 17:10 |
| Chipaca | i think the expectation is that you'll source complete.sh | 17:10 |
| Chipaca | via profile.d or sth | 17:10 |
| Chipaca | but, let me check with ondra-san | 17:10 |
| Chipaca | unless one of you still have quick access to core | 17:11 |
| mvo | Chipaca: sourcing complete.sh would be much easier, making a /usr... dir writable is not ideal on core | 17:11 |
| Chipaca | mvo: especially one that has all sorts of junk in it already | 17:12 |
| mvo | Chipaca: exactly | 17:12 |
| zyga | Chipaca: nope, my wife is driving here with one extra device (pi3-1) from home | 17:12 |
| mvo | Chipaca: we are in sync-dir territory then, I don't like this | 17:12 |
| mvo | Chipaca: I have access to core, what do you need? | 17:12 |
| mvo | Chipaca: fwiw, we control /etc/profile on core, its RO so we can easily append sourcing anything we need there | 17:13 |
| zyga | Chipaca: yes | 17:13 |
| zyga | and perhaps there's some /etc/profile.d/ | 17:13 |
| Chipaca | mvo: working with ondra | 17:14 |
| zyga | btw, what happens if we do nothing, is something broken now? | 17:14 |
| mvo | Chipaca: ok | 17:14 |
| Chipaca | zyga: not broken, just not working | 17:15 |
| zyga | "honey the car is not broke, it's just not working" | 17:15 |
| Chipaca | i mean, the snap still is installable and everything (the completion bits fail but don't block) | 17:15 |
| zyga | Chipaca: what is not working? | 17:15 |
| zyga | aha | 17:15 |
| zyga | I see | 17:15 |
| zyga | how did we miss that, we have spread tests for this | 17:16 |
| Chipaca | zyga: systems: | 17:16 |
| Chipaca | - -ubuntu-core-* | 17:16 |
| Chipaca | mvo: we'll debug it with ondra next week | 17:19 |
| Chipaca | mvo: you go away already | 17:19 |
| * Chipaca asks JamieBennett to kickban mvo until his holiday is over | 17:19 | |
| mvo | Chipaca: ok | 17:19 |
| * mvo vanishes and hugs Chipaca on the way out | 17:19 | |
| ogra_ | Chipaca, note that mvo is wrong, /etc/environment is rw | 17:39 |
| ogra_ | 8on core) | 17:39 |
| === twobitsp1ite is now known as twobitsprite | ||
| * zyga looks at re-flashing his LTE modem with unbranded firmware by following a Russian forum | 18:45 | |
| ogra_ | what could possibly go wrong :) | 18:50 |
| zyga | ogra_: holidays | 19:51 |
| ogra_ | heh | 19:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!