| mborzecki | morning | 05:05 |
|---|---|---|
| === vicamo_ is now known as vicamo | ||
| zyga | good morning | 06:24 |
| zyga | hey mborzecki :) | 06:24 |
| zyga | how was flock? | 06:24 |
| mborzecki | zyga: hey | 06:24 |
| mborzecki | zyga: flock was nice an interesting | 06:25 |
| mborzecki | zyga: i'm slowly finishing the report, should send it out soon | 06:27 |
| zyga | cool, looking forward to it | 06:28 |
| zyga | mborzecki: how was yesterday with regards to master stability? | 06:34 |
| mborzecki | zyga: still haunted by http2 protocol_error | 06:35 |
| zyga | what about sbuild? | 06:35 |
| zyga | is that magically better or fixed? | 06:35 |
| mborzecki | zyga: afaik it occasionally hits timeouts | 06:37 |
| mborzecki | zyga: also, mvo added a pr that retries when there's a http2 protocol error, it ought to be better now | 06:37 |
| zyga | oh, that's good | 06:37 |
| mborzecki | zyga: renewed my rhel developer subscription ;) | 06:55 |
| zyga | mborzecki: cannog go wrong with buying IBM ;-) | 06:55 |
| mborzecki | zyga: btw. need to investigate but snapd doesn't build on rhel8 | 06:56 |
| zyga | deps or tests? | 06:57 |
| mborzecki | zyga: it looks like the go rpm macros are a problem | 06:57 |
| zyga | of course :) | 06:58 |
| zyga | https://github.com/snapcore/spread gives me 504 | 06:58 |
| zyga | is that just me? | 06:58 |
| mborzecki | zyga: things like %gobuild_static are not expanded | 07:00 |
| mborzecki | 504 Not Worthy ;) | 07:00 |
| zyga | that's typical when the macro does not exist | 07:00 |
| mborzecki | zyga: same here | 07:00 |
| zyga | mborzecki: did you post the spread bugfix? | 07:00 |
| mborzecki | zyga: not yet | 07:00 |
| zyga | OK | 07:00 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:09 |
| zyga | hey Pawel | 07:14 |
| pstolowski | zyga: hey, what's the plan with the per-user-mount-ns PRs? | 07:25 |
| zyga | pstolowski: it's all sad, I'm stuck behind layers of other bugs | 07:27 |
| zyga | pstolowski: I will try to re-enable the mount measurement test now | 07:27 |
| pstolowski | zyga: uhm i see :( | 07:28 |
| zyga | pstolowski: at least on ubuntu where I think, it no longer fails | 07:28 |
| zyga | we need spread fixes | 07:28 |
| zyga | we need little test fixes (still quite a few) | 07:28 |
| zyga | hmm | 07:31 |
| zyga | sbuild test uses fastly | 07:31 |
| zyga | I: Updating chroot. | 07:31 |
| zyga | Hit:1 http://cdn-fastly.deb.debian.org/debian sid InRelease | 07:31 |
| zyga | maybe it's all connected? :) | 07:31 |
| zyga | brb | 07:33 |
| * zyga fights more broken tests | 08:04 | |
| zyga | eh | 08:04 |
| * zyga does reviews while tests churn | 08:07 | |
| zyga | spread output is unreadable | 08:13 |
| zyga | there, I said it | 08:13 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/7234 | 08:16 |
| pstolowski | zyga: huh | 08:16 |
| === Girtablulu is now known as Girtablulu|Away | ||
| jpe | Wondering where I can find info about how the isolation in snappy actually works? Google isn't really being helpful. | 08:46 |
| zyga | jpe: hey | 08:51 |
| zyga | jpe: I don't have any good one point of information | 08:52 |
| zyga | jpe: if you want to look at the code I can give you pointers | 08:52 |
| zyga | jpe: if you want to know the high-level picture I can tell you about that as well | 08:52 |
| jpe | Well the code is a lot | 08:52 |
| jpe | I see it uses apparmour somehow | 08:53 |
| jpe | *armor | 08:53 |
| jpe | It uses system image overlays similar to docker. So when you install an application you get the overlay for that application which sits on top of the core image. Then access to the system is controlled via apparmour? | 08:55 |
| zyga | jpe: we're not using image overlays (not sure what that is), we use mount namespaces | 08:57 |
| zyga | jpe: we use cgroups for device (block/char) control | 08:57 |
| zyga | jpe: we use apparmor for file level control as well as some misc things, most notably dbus method access | 08:58 |
| zyga | jpe: we use seccomp for syscall control | 08:58 |
| zyga | jpe: the mount namespaces are used for reliablity mostly, they are not a method of control | 08:58 |
| zyga | (much) | 08:58 |
| jpe | I see so it's a combination of those three tings | 08:59 |
| zyga | yes | 08:59 |
| mborzecki | ok, report sent | 08:59 |
| zyga | mborzecki: cool | 08:59 |
| mborzecki | back to normal work | 08:59 |
| zyga | mborzecki: I'm chasing flaky tests | 08:59 |
| jpe | by image overlays I meant that you have an imutable 'disk image' like file which is mounted under the mountpoint namespaces. | 08:59 |
| mborzecki | zyga: which ones? | 08:59 |
| zyga | jpe: yes but in our case it's much different from what docker does | 09:00 |
| zyga | mborzecki: how many fingers do you have :) | 09:00 |
| zyga | mborzecki: I lost track, chasing one by one | 09:00 |
| zyga | everything loves to leave mount points behind (in our test suite) | 09:00 |
| zyga | mborzecki: then the usual random suspects | 09:01 |
| zyga | mborzecki: protocol error on http2, sbuild, random timing sensitive test | 09:01 |
| jpe | zyga: thanks i guess thats enough to get me started | 09:02 |
| mborzecki | zyga: heh, the usual fun :) | 09:03 |
| pstolowski | pedronis: hey, can I land https://github.com/snapcore/snapd/pull/7209 (it has 2 reviews) or would you like to take a look? | 09:03 |
| pedronis | pstolowski: I would like to look at it quickly, wil do so today | 09:04 |
| pstolowski | pedronis: great, thanks. i've also re-requested your re-reviews or some other PRs but i'm sure you have a lot to catch up with this week | 09:06 |
| pstolowski | s/or/on/ | 09:06 |
| mborzecki | pedronis: hi, will you be able to take a look at https://github.com/snapcore/snapd/pull/7087 ? this is the last one | 09:07 |
| pedronis | mborzecki: yes, but need to see in which order, my main task today is to go over PRs | 09:12 |
| mborzecki | pedronis: sure, thank you! | 09:12 |
| * zyga looks at sbuild test | 09:30 | |
| zyga | it's so annoying that it fails with no useful output | 09:30 |
| zyga | sometimes it doesn't fail with "kill timeout reached" but just, sbuild failed, without any extra detail attached | 09:32 |
| mborzecki | zyga: ha, yeah, so there's a way to extend the debug section and tail -<some-lines> of the log file | 09:33 |
| mborzecki | zyga: if you have a shell, once the build completes, there's a log file in the test directory | 09:34 |
| zyga | ah, thanks | 09:34 |
| zyga | I'll check that out and include it | 09:34 |
| pedronis | yes, we do need that, I remember once chasing a real failure there and being very confused | 09:35 |
| pedronis | had to run it manually and stare at that log | 09:35 |
| pedronis | (which is confusing in its own, so big) | 09:35 |
| Chipaca | IDEA: close non-essential PRs until we get our PR count down | 09:38 |
| Chipaca | also: close stale PRs | 09:38 |
| Chipaca | also also: close all the PRs | 09:38 |
| popey_ | mark them WIP? | 09:38 |
| zyga | Chipaca: idea, also holidays for everyone ;) | 09:38 |
| Chipaca | zyga: yay | 09:39 |
| Chipaca | popey_: nah, that doesn't help, they're all WIP one way or another | 09:39 |
| Chipaca | popey_: we've got 85 WIP PRs | 09:39 |
| popey_ | merge them all then :) | 09:39 |
| zyga | Chipaca: I would like to see a way to switch master into "emergency" mode where other PRs don't even get tested | 09:39 |
| zyga | Chipaca: but yeah, I share the sentiment | 09:39 |
| Chipaca | zyga: per-user mount namespace work | 09:39 |
| Chipaca | zyga: from januhary | 09:39 |
| Chipaca | januhairy | 09:39 |
| zyga | Chipaca: I can close it, it's not going anywhere sadly, | 09:40 |
| Chipaca | zyga: they're all our children, killing them might hurt a little bit | 09:40 |
| * Chipaca eyes his children | 09:40 | |
| Chipaca | it would make things … simpler | 09:40 |
| zyga | done | 09:41 |
| Chipaca | zyga: what's the status of #6714 ? | 09:44 |
| Chipaca | zyga: do we need to request a re-review from j[d]strand? | 09:44 |
| zyga | I think I need to implement a fallback case | 09:44 |
| Chipaca | zyga: ah, i see he responded to my prior query there | 09:45 |
| zyga | I didn't want to but there was a disagreement between people and that's what it is at | 09:45 |
| Chipaca | zyga: i mean, https://github.com/snapcore/snapd/pull/6714#issuecomment-495302513 | 09:45 |
| zyga | though I think this will break more things | 09:45 |
| zyga | I need to return there without firefighter mode | 09:45 |
| Chipaca | zyga: and #6891? | 09:47 |
| Chipaca | (yes i'm going up PRs per person, backwards, meaning you got to go first) | 09:47 |
| zyga | Chipaca: blocked by bugs elsewhere | 09:47 |
| zyga | Chipaca: mainly tests leaking random cruft | 09:48 |
| Chipaca | zyga: aren't those now fixed? | 09:48 |
| zyga | Chipaca: snaps, system changes, et | 09:48 |
| zyga | nope, we've found more and we learned about lxd more at the last sprint | 09:48 |
| zyga | (we need to reboot after lxd test) | 09:48 |
| Chipaca | zyga: ah, and that one was proving tricky? | 09:48 |
| zyga | yeah, needs a patch to spread that mborzecki has | 09:48 |
| * zyga finds aborting spread test broken | 09:51 | |
| zyga | how do I do that again? | 09:51 |
| zyga | ctrl-c? | 09:51 |
| zyga | ctrl-d | 09:51 |
| zyga | killall -9 spread | 09:51 |
| Chipaca | zyga: ^C will eventually shut it down | 09:51 |
| Chipaca | it waits for the current test to finish iirc | 09:51 |
| Chipaca | zyga: re #7205, should you tag who you want to comment? | 09:51 |
| Chipaca | zyga: re #7225 can we close until the number of PRs is under control again? | 09:55 |
| zyga | Chipaca: it runs more tests, I want to abort a test reliably, there seems to be no command to do so | 09:57 |
| zyga | Chipaca: 7225 is in response to a PR from sergio, which I think makes our problems worse, | 09:58 |
| zyga | Chipaca: number of PRs is not the problem | 09:58 |
| zyga | inability to land them effectively is | 09:58 |
| zyga | Chipaca: 7205 is something I want to discuss with pedronis and mvo tomorrow | 09:59 |
| mborzecki | zyga: c-\ | 09:59 |
| Chipaca | zyga: 7225, why isn't that info in the PR? | 09:59 |
| mborzecki | zyga: aka ^\ | 09:59 |
| zyga | Chipaca: because it was made at a sprint and I didn't include it, it's a draft, I don't think those need to be reviewed | 10:00 |
| Chipaca | zyga: 7225 is not a draft | 10:00 |
| Chipaca | zyga: ah, you mean 7205 | 10:00 |
| zyga | Chipaca: I was responding about 7205 | 10:00 |
| zyga | 7225 references the other PR | 10:00 |
| Chipaca | zyga: just throwing a PR up when they're this many is not enough, you need to actively chase people | 10:01 |
| zyga | yeah | 10:01 |
| zyga | Chipaca: actively chasing people is not always possible (holidays/timezone), I agree but not sure what the outcome is | 10:01 |
| zyga | close all the things does not help really | 10:01 |
| Chipaca | zyga: 7225, yes but then it's set to blocked after a meeting, because it's not going to be merged for a while (when?), so... why leave it open at all | 10:01 |
| zyga | if we want to review only stuff that helps with the stabilization effort let's say so, let's make a tag or project or whatever | 10:02 |
| zyga | agree not to restart other PRs | 10:02 |
| Chipaca | zyga: I don't want us to only review one flavour of stuff, I want us to review all the stuff | 10:06 |
| zyga | Chipaca: IMO review is not the problem | 10:06 |
| zyga | Chipaca: why cannot we land a typo fix? | 10:06 |
| zyga | Chipaca: not because of reviews | 10:07 |
| zyga | Chipaca: I think we fundamentally have issue with testing in the project | 10:07 |
| Chipaca | zyga: the number of open PRs without two reviews disagrees with you | 10:07 |
| zyga | Chipaca: high number is not a problem | 10:07 |
| zyga | Chipaca: it's like saying we need to close bugs because we have two pages | 10:07 |
| zyga | Chipaca: acting on them is what matters | 10:07 |
| zyga | Chipaca: if we cannot act because everything takes forever to iterate we get into this kind of situation | 10:08 |
| zyga | Chipaca: I don't disagree we need to focus reviews | 10:08 |
| zyga | but I think open PRs is not the real problem | 10:08 |
| Chipaca | zyga: let's just add more PRs then | 10:09 |
| zyga | Chipaca: I think we both want the same thing, effective progress | 10:09 |
| zyga | if you want we can HO and discuss | 10:10 |
| zyga | Chipaca: can | 10:12 |
| zyga | you look at -- https://github.com/snapcore/snapd/pull/7242 -- it might help us to see what fails in sbuild | 10:12 |
| pedronis | zyga: too many PRs is a problem, it indicates in most cases a lack of focus, both on the opening of, and reviewing side of them | 10:13 |
| zyga | pedronis: do you think this is our actual problem now? | 10:14 |
| pedronis | at some point is also a issue of being able to keep state on the open PRs at a personal/mental level | 10:14 |
| pedronis | zyga: yes, more on the reviewing side of this equation but yes | 10:14 |
| mborzeck1 | quick errand, back in 30 | 10:15 |
| pedronis | zyga: the problem also with saying open as many PRs as you like, is no pressure on the authors on chasing reviews/conclusion on them | 10:15 |
| zyga | I think it depends on how we approach reviews; IMO putting specific barriers in place just discourages contribution | 10:18 |
| pedronis | zyga: barrier on what? | 10:19 |
| zyga | on opening a PR | 10:19 |
| pedronis | zyga: we are not blocking other people | 10:19 |
| zyga | I meant ourselves | 10:20 |
| pedronis | zyga: I don't really know were you are trying to go here | 10:20 |
| zyga | pedronis: I was explaining my POV to chipaca about how I feel about the project | 10:21 |
| pedronis | zyga: my main very rough suggestions stay the same, people on the team should try not to have more than 5 PRs open at a time, they should probably also not work on more than 2 main topics at a time | 10:21 |
| zyga | pedronis: I have opened 4 PRs today, apart from drafts I have 6 other PRs that are mainly blocked by failing tests or by something else being broken preventing them from going in | 10:23 |
| pedronis | zyga: if tests are failing then the team should fix the failing tests | 10:23 |
| pedronis | not open PRs | 10:23 |
| zyga | while I could close the other PRs (and the conversations there) until situation improves I think this is not really a meaningful improvement to our situation | 10:23 |
| zyga | pedronis: that's what I am doing | 10:23 |
| pedronis | zyga: to be honest I didn't suggest to close random PRs | 10:23 |
| pedronis | that came from Chipaca | 10:23 |
| zyga | pedronis: how do you suppose we fix anything without opening PR? | 10:23 |
| Chipaca | that was all me :) | 10:24 |
| pedronis | zyga: you are being silly now | 10:24 |
| Chipaca | zyga: every PR open uses up the team's finite resources of attention and review ability. While right now we have issues with test, at least half of our open PRs predate that | 10:24 |
| zyga | we do tend to get more revies for the stuff up top so that helps | 10:24 |
| zyga | pedronis: that was a joke, but I'm not sure your comment was spot on, we are doing that I think | 10:24 |
| pedronis | zyga: sorry, not really for joke, as long you believe that opening PRs is always good, we have a problem here | 10:25 |
| zyga | pedronis: not always good, but should be a lightweight process because they land fast too | 10:26 |
| zyga | I think that's the real issue | 10:26 |
| pedronis | zyga: sorry, you just closed some month old PRs, they weren't being stuck by tests problems | 10:26 |
| zyga | yes but I'm not disputing those | 10:27 |
| zyga | cachio, Chipaca: https://github.com/snapcore/snapd/pull/7243 | 10:48 |
| zyga | another small test usability improvement | 10:48 |
| zyga | mborzeck1: can you propose your fix to spread please? | 10:53 |
| Chipaca | zyga: why do you say we don't remove base:core18 snaps? i recall no such logic | 10:56 |
| zyga | Chipaca: on core systems we routinely don't remove snaps | 10:57 |
| zyga | Chipaca: I was looking from the point of view of mounted filesystems, runs on ubuntu-core-16-64 left over pretty much all the snaps that had base:core18 | 10:58 |
| Chipaca | zyga: that's a bug in our reset.sh then I suspect, because we do reset the state afaik | 11:00 |
| zyga | amazon has systemd 219, hmm | 11:00 |
| Chipaca | zyga: so the way to fix that is in reset.sh's reset_all_snap, imho | 11:01 |
| zyga | Chipaca: ah, indeed | 11:03 |
| zyga | Chipaca: and I think I see the bug now | 11:03 |
| Chipaca | zyga: unless the ones you're seeing are test-snapd-rsync or test-snapd-rsync-core18 | 11:03 |
| zyga | Chipaca: hold on | 11:03 |
| * Chipaca onholds | 11:03 | |
| zyga | https://www.irccloud.com/pastebin/yd7O7ve9/ | 11:03 |
| mborzecki | zyga: opening a PR in a bit, doing some final testing | 11:03 |
| zyga | mborzecki: thanks! | 11:04 |
| zyga | Chipaca: we never removed them correctly | 11:04 |
| diddledan | document.getElementById('chipaca').addEventListener('hold', e => 'firm grasp!'); | 11:04 |
| diddledan | :-) | 11:04 |
| diddledan | javascript for the evil! | 11:04 |
| * Chipaca rejects outright any rumours about being evil, and casts the defamatory individuals into the Pit | 11:06 | |
| diddledan | dangit, not again | 11:06 |
| zyga | cachio, Chipaca https://github.com/snapcore/snapd/pull/7244 | 11:06 |
| * Chipaca remembers to remove diddledan's rope ladder this time | 11:07 | |
| Chipaca | zyga: I'd refactor that to use an array, but maybe not today | 11:07 |
| zyga | Chipaca: yeah, one at a time :) | 11:08 |
| diddledan | I can reliably reproduce layouts breaking with my mycroft snap but can't seem to build a simple testcase that is as reliable https://www.irccloud.com/pastebin/AhbwBUUa/ | 11:08 |
| pedronis | does that mean we can close 7241 ? | 11:08 |
| mborzecki | zyga: https://github.com/snapcore/spread/pull/85 enjoy | 11:08 |
| zyga | pedronis: yeah, I just commented there | 11:09 |
| zyga | closed now | 11:09 |
| pedronis | zyga: how are you tracking to reopen 6714 ? | 11:09 |
| pedronis | is there a trello card? or something else? | 11:10 |
| mborzecki | Chipaca: pinged you in the spread PR too :) | 11:10 |
| Chipaca | saw it | 11:10 |
| zyga | pedronis: there's still a bug for it, I will check if there's a card | 11:11 |
| mborzecki | hmmm, spread PR queue has grown | 11:11 |
| pedronis | in general I'm not a fan about closing PRs that are not just nice to have, just for the sake of PR count | 11:11 |
| cachio | zyga, checking | 11:13 |
| Chipaca | zyga, pedronis, FWIW is:closed is:unmerged is:pr author:zyga helps | 11:19 |
| pedronis | Chipaca: except it's very large | 11:20 |
| ogra | jamesh, hah, you rock, how did you manager to get the idea he looks for ant-media-server ? that would have never striked me ... | 11:28 |
| diddledan | here we go - reproducer: https://github.com/diddlesnaps/layout-fail | 11:28 |
| diddledan | oh, it looks like I've already filed it: https://bugs.launchpad.net/snapd/+bug/1808821 | 11:30 |
| diddledan | assigned to zyga :-) | 11:31 |
| zyga | diddledan: how does it fail? | 11:32 |
| diddledan | zyga: I've updated the bug | 11:36 |
| zyga | diddledan: I see now | 11:37 |
| zyga | hmmm | 11:37 |
| zyga | sbuild failed again | 11:42 |
| pedronis | flaky unit test? | 11:43 |
| pedronis | or something else | 11:43 |
| === ricab is now known as ricab|lunch | ||
| zyga | tests/main/spread, kill timeout | 11:43 |
| zyga | no further information :/ | 11:43 |
| pedronis | we should ask cachio to debug, whether is just taking long to start with | 11:44 |
| pedronis | or some unit test blocks sometimes? | 11:45 |
| * diddledan rocks out to popeycore music | 11:45 | |
| diddledan | "music" | 11:45 |
| cachio | pedronis, zyga I am working with sbuild right now | 11:46 |
| Chipaca | diddledan: no, popeycore is a dress style, like dadcore but more extreme | 11:46 |
| * Chipaca goes to have lunch before he gets himself in trouble | 11:46 | |
| diddledan | :-p | 11:47 |
| cachio | zyga, pedronis still not possible to reproduce the error running here | 11:47 |
| diddledan | Chipaca: you're as bad as me. and I'm worse :-p | 11:47 |
| popey_ | popeycore is a core laptop, no sound :) | 11:50 |
| mborzecki | pstolowski: really simple selinux fix https://github.com/snapcore/snapd/pull/7245 | 11:50 |
| diddledan | aah, art nouveau music, popey_ ? | 11:50 |
| popey_ | hmm, are there any command line (curses) music creation apps? | 11:50 |
| mborzecki | diddledan: speaking of art nouveau, couple years back, you could listen to your hard disks by running dd if=/dev/hda of=/dev/dsp | 11:52 |
| pstolowski | mborzecki: +1 | 11:53 |
| diddledan | :-o | 11:53 |
| mborzecki | pstolowski: thanks! | 11:54 |
| mborzecki | pstolowski: i'll force push that little tweak | 11:54 |
| mborzecki | pstolowski: or not, there's more places that could use a similar format change | 11:58 |
| pstolowski | is there? Ok, nvm then | 12:06 |
| popey_ | https://github.com/danfrz/PLEBTracker oooh | 12:10 |
| pedronis | #6950 needs a 2nd review | 12:15 |
| cmatsuoka | Chipaca: I see in master that create-user is still using the v2/create-user api, how should user removal be handled now? | 12:19 |
| cmatsuoka | Chipaca: is there a new api that covers all user creation/removal operations? | 12:19 |
| Chipaca | cmatsuoka: last I heard we were blocked waiting for field input | 12:20 |
| cmatsuoka | Chipaca: ah ok, so I'll wait as well, thanks | 12:20 |
| Chipaca | cmatsuoka: mvo might know more | 12:22 |
| popey_ | What exactly needs to happen (beyond editing a seed file) for tmux (which is in main) to be added to ubuntu core images? | 12:51 |
| zyga | diddledan: debugged now | 12:57 |
| Chipaca | popey_: you need to make the case that it's worth it, i guess? | 12:58 |
| Chipaca | popey_: one place to start would be with ogra, wrt size impact | 13:01 |
| ogra | me ? | 13:03 |
| ogra | i doubt i still have a say :) | 13:03 |
| ogra | i'd vote for screen instead of tmux though | 13:03 |
| popey_ | I spoke to jdstrand about it at the summit, he "voted" for tmux over screen | 13:03 |
| popey_ | (upstream screen is dead AIUI) | 13:04 |
| ogra | he never uses serial terminals :P | 13:04 |
| popey_ | that's a different use case | 13:04 |
| popey_ | I'm talking about a terminal multiplexor here, not a serial console | 13:04 |
| ogra | well, it is a usecase that screen includes | 13:04 |
| Chipaca | ogra: how does 'cu' compare to screen? | 13:05 |
| ogra | (and i use serial terminals from core to talk to attached devices...) | 13:05 |
| popey_ | what do you use now? | 13:05 |
| ogra | dunno, i think i only have used cu once in my life several years ago | 13:06 |
| === ricab|lunch is now known as ricab | ||
| ogra | popey_, screen from a chroot, classic snap or lxd | 13:06 |
| jdstrand | I did advocate for tmux, yes for a multiplexer. a multiplexer does seem like something that should be in core. if screen addresses other use cases, I would not be opposed to screen | 13:07 |
| popey_ | Ok, I personally dont care too much either way. However we have had this conversation multiple times over 2 years. | 13:08 |
| popey_ | I wondered who I have to nail down to get it | 13:08 |
| jdstrand | we even had verbal agreement it should be in core :) | 13:08 |
| Chipaca | ooh | 13:09 |
| Chipaca | maybe it's just a PR in core then? | 13:09 |
| jdstrand | iirc, mvo liked the idea, but this was before core18 was heavily pruned, and I wasn't part of those coversations | 13:09 |
| * jdstrand notes that screen is and will continue to be in main for the foreseeable future | 13:10 | |
| popey_ | despite not having a release for 2 years? | 13:10 |
| jdstrand | oh yes | 13:11 |
| jdstrand | inertia | 13:11 |
| ogra | it is "stable" ! | 13:11 |
| ogra | (though i recently had actual issues with it ... new rockchip boards use hilarious serial speeds that screen doesnt support OOTB) | 13:12 |
| ogra | (1,500,000 baud by default) | 13:13 |
| jdstrand | I mean, I strongly prefer tmux for maintenance, but it is hard to imagine screen going away. if screen is meeting real world use cases for core that tmux does not, I'm just saying it can be there from an Ubuntu maintenance perspective | 13:14 |
| ogra | well, i'm probably a special case ... but it helps to debug stuff attached via serial to core | 13:15 |
| jdstrand | that said, popey_ and I are talking about a good multiplexer that a lot of users have asked for and something a snap cannot ship. ogra is talking about serial consoles-- perhaps that continues to be a chroot/lxd/classic snap thing | 13:16 |
| ogra | not sure many people would do it that way | 13:16 |
| * jdstrand doesn't know | 13:16 | |
| popey_ | I'm currenly using screen on my core laptop, which I copied out of the deb into ~/bin which is messy | 13:16 |
| popey_ | well, if screen is still maintained, size-comparable and can hit two birds with one stone, I don't see why not? | 13:16 |
| ogra | using it is messy ? or the way you got it running ? | 13:16 |
| ogra | (does it work correctly just copying the bin ?) | 13:17 |
| jdstrand | it would feel slightly weird to put something so ancient as screen into core, but then, it isn't like glibc is that fresh (it is very well maintained though) | 13:17 |
| ogra | well, flip a coin :) i'm not pushing that hard for it, it just would make more sense imho | 13:18 |
| jdstrand | it is true that tmux does not support serial console. it would seem to me an unusual use for a core device to need a serial console program since I would expect one to use such a program to connect to the serial console of the device instead of the other way around | 13:23 |
| jdstrand | both screen and tmux are part of ubuntu-server, but no where else | 13:23 |
| popey_ | ogra: it works like that, yes | 13:23 |
| jdstrand | tmux is a modern multiplexer with healthy upstream whereas as screen is a very mature application | 13:24 |
| popey_ | that was my main reason for choosing tmux | 13:24 |
| jdstrand | I very strongly advocate for a multiplexer in core. if I had to vote, I would vote tmux | 13:24 |
| popey_ | do a pr against the seed and we poke people until it lands ? :) | 13:25 |
| jdstrand | is it just a seed? I mean, I could just do it... | 13:26 |
| jdstrand | but no, I won't do that without mvo or pedronis saying it is ok :) | 13:26 |
| jdstrand | oh, and I have used cu in the past with mixed results as a serial console. screen has always worked better. I'm not sure if that is a pebkak thing, a docs thing or a software thing | 13:27 |
| ogra | just dont forget that 90% of core installs are headless/userless anyway | 13:27 |
| ogra | we are some special breed being developers that log in to it | 13:27 |
| popey_ | Sure, but it's also useful during development | 13:28 |
| jdstrand | the problem is that it can't be a snap | 13:28 |
| popey_ | When migrating from ubuntu server to ubuntu core | 13:28 |
| pedronis | it seems a case where one would install the classic snap and use it from there? | 13:28 |
| ogra | note also that nearly all relevant developer tools were dropped on the switch to core18 | 13:28 |
| popey_ | you can't install classic snaps on core pedronis | 13:29 |
| jdstrand | pedronis: that is what people do, but that doesn't work well to use it as part of your regular workflow | 13:29 |
| ogra | so i'm not sure what adding a multiplexer means while you cant even touch the bootloader config anymore and such | 13:29 |
| pedronis | popey_: I mean the classic snap, | 13:29 |
| pedronis | not classic snaps | 13:29 |
| ogra | heh | 13:29 |
| popey_ | NAMING! | 13:29 |
| ogra | we really need a new name at some point | 13:29 |
| jdstrand | the classic snap (or an lxd container) puts you in a box, not on the host | 13:29 |
| ogra | right | 13:29 |
| popey_ | it's additional overhead too | 13:29 |
| jdstrand | and people want a multiplexer for working on the host | 13:30 |
| ogra | sure, buit given all the removals in core18 we dont really encourage development on the host anymore anyway | 13:30 |
| jdstrand | tmux is 500k | 13:30 |
| ogra | thats not actually small | 13:30 |
| ogra | (not really big either though) | 13:31 |
| * jdstrand wasn't using it as justification | 13:31 | |
| ogra | screen is 425k it seems | 13:31 |
| ogra | so not much difference here | 13:31 |
| jdstrand | but it has supporting files | 13:31 |
| popey_ | they'll also be compressed | 13:31 |
| jdstrand | idk how much they are needed | 13:32 |
| ogra | well, popey_ said he got along with only copying /usr/bin/screen | 13:32 |
| ogra | not sure if thats also true for tmux | 13:32 |
| jdstrand | the tmux package has no supporting files. I didn't look at deps | 13:32 |
| jdstrand | tmux could be a snap if we created the (gasp) classic *interface* | 13:33 |
| popey_ | well, it was a case of installing classic, jumping into classic, installing screen and finding the binary and copying it out | 13:33 |
| popey_ | not just copying /usr/bin/screen | 13:33 |
| jdstrand | which has been discussed from time to time | 13:33 |
| ogra | does it really need full classic access ? not just some files that would justify a "tmux-core" interface or so ? | 13:34 |
| popey_ | it needs to launch arbitrary binaries | 13:35 |
| ogra | oh, right | 13:35 |
| jdstrand | it needs to be able to run anything on the system. plus there is a setuid component | 13:35 |
| ogra | not just shells | 13:35 |
| ogra | yeah, i fogot that the shell you start indeed runs inside tmux | 13:36 |
| jdstrand | so, if we wanted a tmux-support interface, I could *perhaps* make it work without modifying tmux | 13:36 |
| jdstrand | it would need an installation constraint. the idea would be that I let it do what it needs to do, then use a 'ux' rule to the shell | 13:37 |
| jdstrand | this is hand-wavy | 13:37 |
| jdstrand | I still maintain that a multiplexer should be in core. tmux isn't only for development. admins use it and we provide ssh for admins | 13:38 |
| ogra | anyway, i think the decision process is somewhere between pedronis and foundations ... though if we add it, the question is, shopuldnt we also add keymaps, locales etc etc ... since we turn it into an actual developer image | 13:38 |
| ogra | ... where do we draw the line | 13:38 |
| popey_ | I don't see that we're making it a developer image | 13:38 |
| popey_ | it's just a useful tool | 13:38 |
| jdstrand | as mentioned, not for devel, for admins. devs get a nice tool in the process as a side effect | 13:39 |
| pedronis | jdstrand: is #6767 on your list? | 13:40 |
| jdstrand | that's right, it is setgidness (utemper) | 13:40 |
| Chipaca | brb, need to reboot | 13:40 |
| ogra | jdstrand, what admins ? | 13:41 |
| ogra | you usually control core from some central mgmt tool via snapd-control | 13:41 |
| ogra | and dont usually even have an account on actual products | 13:41 |
| jdstrand | ogra: there are more than devs connecting to ubuntu core via ssh. those people | 13:41 |
| ogra | well, talking from a product/sales perspective here ... | 13:42 |
| jdstrand | sure, but that doesn't mean that others don't create that user. we know of customers that demanded certain user features | 13:42 |
| jdstrand | and they even had a management snap | 13:42 |
| jdstrand | some want ssh as an escape hatch | 13:42 |
| ogra | i havent seen a single sale in the recent months where it was actualy not requested to *avoid* logins | 13:43 |
| jdstrand | I am not saying it is a primary use case, I'm agreeing with popey_ that it is a useful tool | 13:43 |
| ogra | but indeed, brand-store owners can sping own images and add system users at will | 13:43 |
| ogra | *spin | 13:43 |
| ogra | jdstrand, but so is nano for many people ... | 13:44 |
| ogra | shoudl we add it too | 13:44 |
| ogra | ... and typing on a non-us keyboard | 13:44 |
| jdstrand | ogra: but there is no multiplexer in core. there is an editor | 13:44 |
| popey_ | (I have nano in ~/bin too :( ) | 13:44 |
| ogra | hahaha | 13:45 |
| ijohnson | popey_: snap install nano --devmode | 13:45 |
| * ijohnson hides | 13:45 | |
| ogra | yeah | 13:45 |
| jdstrand | yours is an argument to have tmux and screen when there is only tmux. mine is pick something :) | 13:45 |
| ogra | well, my question is if we need it urgent enough to add it :) | 13:45 |
| ijohnson | fwiw I would love to have tmux just for terminal multiplexing | 13:45 |
| ogra | (either of them) | 13:45 |
| jdstrand | pedronis: re 6767, that and whole bunch of others | 13:45 |
| pedronis | jdstrand: ok, just double checking, it's a target for 2.41 | 13:46 |
| ogra | but as i said, not really my decision anymore anyway | 13:46 |
| jdstrand | pedronis: I'll take a looked at the milestoned 2.41 PRs and do them first | 13:46 |
| jdstrand | look* | 13:47 |
| ogra | i'd personally take screen is what i said ... thats all ... for multiplexing on logout we have nohup installed | 13:47 |
| pedronis | jdstrand: thx | 13:47 |
| ogra | for multiplexing sessions there is indeed nothing | 13:47 |
| jdstrand | pedronis: I'm going to do a push to get through as much as I can today/tomorrow, then get back to k8s/pulse | 13:47 |
| pedronis | jdstrand: I was back from holiday yesterday, I will go over your deamon user PRs in the next couple of days | 13:48 |
| ogra | (though i bet you can use nohup as session multiplexer when doing some scriptery) | 13:49 |
| ogra | but that would most likely become tmux re-implemented in shell :) | 13:49 |
| jdstrand | pedronis: thanks. fyi, while not terribly urgent, I redid PR 6436 some time ago based on your feedback. it is ready to re-review | 13:53 |
| jdstrand | (system-backup) | 13:53 |
| jdstrand | popey_: I took 30 minutes to explore a tmux-support interface. I think it is possible: set seccomp to unrestricted, opt out of the devide cgroup, apparmor allows transitioning/transitions to unconfined, ship utmpter as setgid root. this gives everything except the hosts /tmp | 14:15 |
| * cachio afk | 14:18 | |
| jdstrand | popey_: actually, no, it doesn't allow running snap commands | 14:20 |
| jdstrand | this is seriously, really best as a part of core | 14:20 |
| * zyga breaks | 14:37 | |
| * ogra looks for the glue | 14:43 | |
| abeato | jdstrand, afaik one thing that screen does and tmux not is access to serial devices (/dev/ttyUSB* and the like), which is incredibly useful if you are connected to a serial console or something like accepts AT commands | 14:55 |
| ogra | yeah, on-device GSM modems and such | 14:56 |
| abeato | or bluetooth devices too | 14:56 |
| ogra | ah, indeed | 14:56 |
| abeato | zigbee, etc. | 14:57 |
| ogra | that sounds like another point for screen over tmux | 14:57 |
| pedronis | ijohnson: Chipaca: I did another pass over #7149, there is a bit of confusion about how error kinds work there, Chipaca can also help in that area | 14:57 |
| ijohnson | thanks pedronis I'll take a look now | 14:57 |
| pstolowski | ijohnson: hey, a small hint re hotplug wrt to the forum topic about serial port | 14:58 |
| pstolowski | ijohnson: i think you looked at serial_port - HotplugDeviceMethod and concluded id vendor/model are the required attributes; this aspect may be confusing - you should be looking at hotplug.go - defaultDeviceKey() and attrGroups list. there are 4 groups of attributes we look into, and we require >=2 attributes from those groups to be present | 15:01 |
| ogra | pstolowski, interesting ... how would you actually do GPIO via hotplug ... they dont exists until you "echo $gpionum >/sys/class/gpio/export" which is what only the gpio interface does today once you connect to it actively ... (so the device doesnt show up until the interface gets connected, no udev stuff going on afaik) | 15:02 |
| ogra | (i'd love if we could do them more dynamic ... but the concept doesnt sound like it could work) | 15:03 |
| ogra | (referring to your forum answer ... i dont want to bloat the thread with offtopic chatter) | 15:04 |
| pstolowski | ogra: ok, maybe i said something silly.. i think i remember zyga suggesting gpio discovery like this, but that was long time ago in early days of hotplug, maybe i misremembered it | 15:04 |
| ijohnson | pstolowski: thanks for the pointer, I had missed that part | 15:05 |
| ogra | well, i'd love if we could find a way to use hotplug for them ... | 15:05 |
| ogra | but i dont thing tieing it to hotplug will work for this... that might need a new mechanism | 15:05 |
| ogra | s/hotplug/udev/ (sorry) | 15:05 |
| ijohnson | pstolowski, what if in the HotplugDeviceDetected method for the serial-port interface we also checked to see if ID_BUS was "pci", that would probably work for this specific device they have | 15:06 |
| ogra | pstolowski, something like reading from the devicetree (via /sys/firmware/devicetree/base/) could work for them though ... | 15:07 |
| ogra | yeah ... that would likely work: https://paste.ubuntu.com/p/bwxppNgtp6/ | 15:10 |
| ogra | (would need some filtering to find gpio-only interfaces, i.e. not spi or i2c) | 15:10 |
| pstolowski | ijohnson: yes, absolutely, although we should look at device key compuitation and possibly make pci path a part of the key for such cases (based on ID_BUS?). every hotplug interface can define HotplugKey method to override how unique key is computed | 15:13 |
| ijohnson | pstolowski, for this specific case, it already would qualify with ID_VENDOR_ID=0x8086 and ID_VENDOR_FROM_DATABASE=Intel Corporation for the vendor attr group | 15:14 |
| ijohnson | so I think all that would be needed to unblock this specifically is that check that the ID_BUS matches usb | 15:15 |
| zyga | cachio: can you disable sbuild test until we know what's wrong | 15:19 |
| zyga | cachio: it's blocking all activity | 15:19 |
| pstolowski | ijohnson: it needs 2 attributes from different groups, so vendor + model from the other group. yes. i'd extend this with path though for static devies to make sure we handle multiple devices with same vendor+model (in the absence of serial#). and yes we have a problem there afaict if serial is not present | 15:19 |
| pstolowski | in that multiple instances of same device with no serial will not be distinguished | 15:20 |
| pedronis | pstolowski: I made a comment in 7209, my plan is much more complicated though :/, let me know what you think | 15:21 |
| pstolowski | looking | 15:22 |
| ijohnson | pstolowski, oh I see what you're saying sorry I misunderstood you before I thought it needed 2 from the same group | 15:22 |
| ijohnson | pstolowski: when you say extend it with path for static devices, do you mean DEVPATH which in the code is di.DeviceName()? that's already set in the proposed slot attributes returned from HotplugDeviceDetected method for serial-port interface | 15:31 |
| ijohnson | err wait I read wrong - currently the code uses DEVNAME as di.DeviceName(), are you saying it should be extended to instead use "path" attribute in the proposed slot as the value of DEVPATH | 15:32 |
| ijohnson | i.e. `"path": di.Attribute("DEVPATH")` or thereabouts | 15:33 |
| pstolowski | ijohnson: yep, it should use whatever attribute makes that static device unique in the system (DEVPATH looks ok); it only makes sense for static devices. it must be made part of the hotplug-key which is crucial for hotplug logic and tracking of devices | 15:35 |
| ijohnson | pstolowski: so is the hotplug-key determined from the attributes which are returned from HotplugDeviceDetected in the hotplug.ProposedSlot? | 15:36 |
| pstolowski | ijohnson: and note it's strictly about hotplug key which is internal to snapd, it is not about what we expose as attributes of a slot to the user | 15:36 |
| pstolowski | ijohnson: no. it's computed by defaultDeviceKey() method in hotplug.go from the predefined groups of attributes - OR - by optional HotplugKey(..) method of the interface, if defined. | 15:39 |
| ijohnson | ahh I see that HotplugKey isn't defined for the serial-port interface so that's why I didn't see it | 15:39 |
| pstolowski | ijohnson: so if we know a specific interface needs specific logic for some devices - such as serial port & static ports with pci bus, we can override key logic just for serial port | 15:39 |
| pstolowski | ijohnson: so far have just serial port interface and no such use cases, so it's a bit hard to follow ;) | 15:41 |
| pstolowski | *we have | 15:41 |
| ijohnson | pstolowski: so can an implementation decide in the HotplugKey method to instead use the defaults instead of always providing it's own? | 15:41 |
| ijohnson | then for serial-port we could have a check, if it's pci then the interface will provide it's own including DEVPATH which will be unique, if it's usb then just use the default from defaultDeviceKey() | 15:41 |
| ijohnson | it looks like if HotplugKey returns deviceKey as "", then it will fall through and use the default one | 15:43 |
| pstolowski | ijohnson: yes. serial-port can implement HotplugKey method and return an empty key, in which case we fall back to default computation - see https://pastebin.ubuntu.com/p/zPzqVM5xDX/ | 15:43 |
| ijohnson | so I think that would work | 15:43 |
| ijohnson | yeah haha I just found that function | 15:43 |
| ijohnson | good that I'm on the right path | 15:43 |
| pstolowski | ijohnson: what's a bit undefined and missing in the enitre story is versioning of hotplug keys in case they are returned by HotplugKey of an interface. we will need to address this at some point | 15:46 |
| pstolowski | ijohnson: versioning may be needed in case we need to change how keys are computed (e.g. new attributes added, affecting how key looks for existing devices) | 15:47 |
| ijohnson | hmm yes that does look complicated | 15:47 |
| ijohnson | pstolowski, pedronis: do you think versioning keys from the HotplugKey method of a hotplug implementation would block adjusting serial-port to work for this pci case? | 15:56 |
| pstolowski | ijohnson: imho no, i don't think so - on the basis that this is still experimental | 16:07 |
| ijohnson | okay, cool I'll give it a try and push something up to try and unblock this person's use case | 16:08 |
| pstolowski | ijohnson: we should probably use 0 as version, like we do with default keys for now | 16:08 |
| ijohnson | that sounds good | 16:08 |
| pstolowski | ijohnson: fyi we have a nested vm test for hotplug & serial-port | 16:11 |
| pstolowski | pedronis: commented on #7209 | 16:12 |
| ijohnson | right I'll try to look at that as well | 16:13 |
| pstolowski | ijohnson: i don't think you'll be able to extend this for new use case, but at least it can prove no regressions | 16:14 |
| pstolowski | ijohnson: i think pedronis or mvo should ack this change, so we don't commit to providing something we need to remove later (although it looks relatively uncontroversial to me) | 16:16 |
| ijohnson | yes I was going to request reviews from them as well | 16:16 |
| pstolowski | cool | 16:16 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio | zyga, #7246 | 16:26 |
| cachio | plase approve :) | 16:27 |
| ijohnson | cachio: if it's any help I approved that too | 16:28 |
| cachio | ijohnson, sure, thanks!! | 16:29 |
| * cachio afk | 18:52 | |
| ijohnson | jdstrand: did you see my question in the PR description of #7214? | 20:55 |
| ijohnson | (thanks for the review BTW) | 20:55 |
| jdstrand | ijohnson: oh, I didn't, let me look | 21:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!