| opendevreview | Merged openstack/openstack-manuals master: Correct links to OpenStack Security site https://review.opendev.org/c/openstack/openstack-manuals/+/991641 | 01:43 |
|---|---|---|
| opendevreview | Merged openstack/openstack-manuals master: Replace deprecated openstackdocstheme options https://review.opendev.org/c/openstack/openstack-manuals/+/989373 | 01:44 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-manuals master: Add OpenStack-Ansible to projects for 2026.1 https://review.opendev.org/c/openstack/openstack-manuals/+/995453 | 08:51 |
| fungi | i'm on vacation and can't make the meeting today, but in case anyone missed it there's finally a post to openstack-discuss introducing the riscv sig proposal: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/UK2YYNPXC3BGZM3IWHYM6XYNQXHPD57C/ | 12:48 |
| spotz[m] | Thanks fungi go enjoy yourself!! | 13:23 |
| gouthamr | tc-members: a gentle reminder that our weekly meeting will be hosted here in ~50 minutes | 16:11 |
| gouthamr | Agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 16:11 |
| opendevreview | Dr. Jens Harbott proposed openstack/governance master: Add reviewers as Active Contributors https://review.opendev.org/c/openstack/governance/+/995535 | 16:22 |
| frickler | I finally got round to looking at this ^^ and although I'm a bit embarrassed that I only came up with a single sentence, maybe that will be enough? | 16:23 |
| cardoe | What is this "tc" you speak of gouthamr? | 16:25 |
| cardoe | aka I've been away from my desk quite a bit these last few weeks. So bare with me while I get caught up on items. | 16:26 |
| gouthamr | cardoe: you went to go see bears and became a monk :D | 16:57 |
| * gouthamr will admit that happened to him | 16:57 | |
| gouthamr | frickler++ w00t | 16:57 |
| spotz[m] | frickler: Suggested a sentence change for clarity, let me know what you think | 16:57 |
| gouthamr | fungi: ack, great to see that.. spotz[m] bounced that email to RISC-V foundation folks that were talking to us privately.. hopefully someone will connect directly, else we'll keep watching the space.. | 16:58 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Jun 30 17:00:28 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| gouthamr | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 17:01 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| spotz[m] | o/ | 17:01 |
| frickler | \o | 17:01 |
| noonedeadpunk | o/ | 17:01 |
| gouthamr | courtesy-ping: dansmith, cardoe, bauzas | 17:03 |
| gouthamr | noted-absence: m n a s i a d k a | 17:03 |
| dansmith | gah sorry | 17:03 |
| dansmith | here | 17:03 |
| gouthamr | you didn't say "o/", disqualified | 17:03 |
| dansmith | o/ \o \o/ | 17:03 |
| gouthamr | :D | 17:04 |
| gouthamr | alright, let's get started.. | 17:05 |
| gouthamr | #topic Last Week's Action Items | 17:05 |
| gouthamr | we may have had a chance to think some more about the Contributor Experience Working Group... i see a number of RC votes on the proposal, thank you.. i meant to send an email to the openstack-discuss email list, and prep some more for folks to come in and start organizing around the initial proposal... | 17:06 |
| gouthamr | if/when the TC merges it, we can get on the tasks and make progress.. | 17:07 |
| gouthamr | ildikov/fu n gi/clarkb continue to discuss the survey outcomes with project teams and are compiling a list of suggested actions for us to take.. we can discuss this in a couple of weeks perhaps.. | 17:08 |
| * gouthamr keeps the action item on the openstack-discuss mailing list post | 17:08 | |
| gouthamr | if you haven't looked/voted on the governance change, please do: | 17:09 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/994046 (Establish Contributor Experience Working Group) | 17:09 |
| gouthamr | on to the next action item.. deprecations and retirements: | 17:10 |
| gouthamr | noonedeadpunk was closing out the venus retirement changes, and the vitrage deprecation changes | 17:10 |
| gouthamr | anything to share regarding this, noonedeadpunk? | 17:11 |
| noonedeadpunk | So still one more vote needed for project-config | 17:11 |
| noonedeadpunk | #link https://review.opendev.org/c/openstack/project-config/+/982878 | 17:11 |
| noonedeadpunk | Then content removal can be merged | 17:12 |
| spotz[m] | I think I'm up todate on votes | 17:12 |
| gouthamr | great; frickler can probably help | 17:12 |
| noonedeadpunk | Will propose content removal patches as govenrance deprecation has been approved | 17:12 |
| gouthamr | #link https://review.opendev.org/q/hashtag:%22deprecate-vitrage%22+(status:open%20OR%20status:merged) (Vitrage Deprecation changes) | 17:13 |
| clarkb | are the xstatic repos only used by vitrage? | 17:14 |
| clarkb | the relationship there isn't immediately clear to me | 17:14 |
| noonedeadpunk | only vitrage and venus were using them | 17:14 |
| clarkb | got it | 17:14 |
| noonedeadpunk | venus already gone | 17:14 |
| clarkb | I have approved 982878 | 17:15 |
| noonedeadpunk | I tried to check through codesearch, but another pair of eyes won't hurt | 17:15 |
| gouthamr | nice, ty clarkb | 17:16 |
| noonedeadpunk | +1 | 17:16 |
| gouthamr | alrighty, do you have the appetite to explore Pypi's new package archival? | 17:17 |
| noonedeadpunk | Actually that would be really nice | 17:18 |
| noonedeadpunk | I can recall that there was no API last time I checked | 17:18 |
| noonedeadpunk | but that was like.... 6m ago almost now | 17:18 |
| gouthamr | i was thinking of two extensions to our existing retirement process: | 17:18 |
| gouthamr | - clean up pypi (mark deliverables obselete/archived), ansible-collections and anywhere else we upload packages/artifacts to | 17:18 |
| gouthamr | - clean up trackers (launchpad/storyboard) | 17:18 |
| gouthamr | noonedeadpunk: ack, opendev infra folks can take actions if you tell them what needs to be done too, in the absence of an API | 17:19 |
| noonedeadpunk | cleaning up trackers is good point as well | 17:20 |
| noonedeadpunk | At least worth updating description in there | 17:20 |
| gouthamr | yes; and launchpad admins might appreciate us letting them know | 17:21 |
| gouthamr | #link https://ubuntu.com/docs/launchpad/user/reference/launchpad-and-community/legal/launchpad-policies/#projects-and-project-groups | 17:21 |
| noonedeadpunk | I think we should be having a group on launchpad to control that | 17:22 |
| gouthamr | to file a deletion request? | 17:22 |
| gouthamr | (i've just asked them to verify my existence/credibility via billy olsen and prior requests) | 17:23 |
| noonedeadpunk | do we really want to delete it though? | 17:23 |
| noonedeadpunk | As clean-up for me would be marking them as deprecated/retired and close all bugs/etc | 17:23 |
| gouthamr | good point, i don't know.. i was just thinking of orphaned references and felt like this would be nice to do | 17:23 |
| noonedeadpunk | But not sure about deleting the project as a whole | 17:24 |
| noonedeadpunk | Same idea with pypi? we don't want to delete, but archive | 17:24 |
| gouthamr | ack | 17:24 |
| gouthamr | sure that might be a good thought.. | 17:24 |
| noonedeadpunk | btw venus was created quite standalone - it's not "part of" OpenStack and there're no infra maintainers for it | 17:25 |
| gouthamr | *facepalm* | 17:25 |
| noonedeadpunk | Like vitrage's launchpad is owned by openstack at least | 17:25 |
| gouthamr | actually, everything is created standalone, but, when the governance transition happens, we should probaby begin asking for this to be done | 17:25 |
| noonedeadpunk | So I'd need to figure out access to it through ticket/email | 17:25 |
| noonedeadpunk | I think I did that some time ago for freezer | 17:26 |
| gouthamr | okay, good stuff, we can discuss post meeting.. | 17:26 |
| gouthamr | anything else regarding retirements and deprecations? | 17:27 |
| gouthamr | i think conversations regarding retirement of cinderlib are progressing | 17:28 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/994004 (Retire cinderlib) | 17:28 |
| gouthamr | #link https://review.opendev.org/q/topic:%22retire-cinderlib%22 | 17:28 |
| gouthamr | elodilles suggested rosmaita wait a couple of weeks before the release patch EOL'ing all branches can be merged | 17:29 |
| gouthamr | but, shouldn't affect the governance change.. we aren't voting on the fate of unmaintained branches there | 17:29 |
| gouthamr | please do take a look, and flag anything concerning.. i'll try to get this in | 17:29 |
| gouthamr | next item was x/cursive's move into the openstack namespace | 17:30 |
| gouthamr | i think infra has provided a date for this maintenance | 17:30 |
| clarkb | we've pencilled in July 9 at ~2100 UTC | 17:31 |
| frickler | couple of days instead of weeks sounds to be enough for me (re cinderlib) | 17:31 |
| gouthamr | neat, thank you clarkb | 17:31 |
| clarkb | gouthamr: I still don't know if the owership situation was sorted out? | 17:31 |
| gouthamr | ah, good point | 17:31 |
| clarkb | historically we've had no problem with handing over repos if someone from the old core/release groups says go ahead, but I'm not sure that has happened here? | 17:31 |
| clarkb | the project appears to have been somethign out of johns hopkins univeristy and while I agree it seems idle I think it would be good if we can ensure we're not just strong arming anyone over this | 17:32 |
| gouthamr | +1, i'm trying to find fu n gi's call out regarding this | 17:32 |
| gouthamr | ah, it was on this channel | 17:33 |
| fungi | (it was in #openstack-oslo, i think) | 17:33 |
| gouthamr | "jhuapl folks and barbican-core" | 17:33 |
| * gouthamr you're not here, fungi | 17:33 | |
| * fungi is like a ghost | 17:33 | |
| spotz[m] | Get back to your PTO! | 17:34 |
| gouthamr | #link https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2026-06-23.log.html#openstack-tc.2026-06-23.log.html#t2026-06-23T20:04:37 | 17:34 |
| gouthamr | okay, i can take the action on this and contact these folks | 17:34 |
| frickler | also the gerrit acls still need amending and iiuc stephenfin is out for some weeks, anyone want to take that up? see my inline comment on https://review.opendev.org/c/openstack/project-config/+/990122 | 17:35 |
| gouthamr | i see, ty for flagging that frickler.. | 17:35 |
| gouthamr | basically you need that attr dropped | 17:38 |
| gouthamr | s/attr/access | 17:38 |
| gouthamr | correct? you don't want someone to be able to tag a release on gerrit | 17:38 |
| gouthamr | (https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/bifrost.config doesn't seem to be in compliance then) | 17:38 |
| gouthamr | context: https://gerrit-review.googlesource.com/Documentation/access-control.html#category_create_signed | 17:39 |
| clarkb | not all projects follow the release process (not sure if bifrost does) | 17:39 |
| gouthamr | if this is an oslo deliverable, this seems straightforward to do.. i.e., drop that access | 17:40 |
| gouthamr | do you mind that coming as a separate change? | 17:41 |
| frickler | https://review.opendev.org/c/openstack/releases/+/993729 looks like it is meant to be treated like "the usual suspects" ;) | 17:42 |
| gouthamr | yes | 17:42 |
| gouthamr | you've some x-ray vision | 17:42 |
| frickler | IMO it would be better to do it all in one patch, not sure what other infra admins think | 17:43 |
| gouthamr | ack, maybe we can decide on the change or outside this meeting | 17:44 |
| frickler | ack | 17:44 |
| gouthamr | the final action item is an upleasant one | 17:44 |
| gouthamr | extended absences from TC | 17:44 |
| gouthamr | people's priorities change, and we should probably have a formal process around this.. | 17:45 |
| gouthamr | if there are any ideas on how to deal with it, please chime in.. | 17:45 |
| gouthamr | i don't think status quo is useful | 17:46 |
| noonedeadpunk | well, the only way to go about it is to have some election | 17:46 |
| noonedeadpunk | which... eh... would be also tricky to organize? | 17:46 |
| gouthamr | i don't know about tricky... but it might be tricky for now | 17:47 |
| noonedeadpunk | given that it's what? 2 month of cadence left? | 17:47 |
| dansmith | I assume one strategy is to just let the situation resolve itself when the expiring member's term is up.. which we could opt for out of simplicity if the absence isn't causing a problem right? | 17:47 |
| gouthamr | yes, the term ends in September 2025 | 17:47 |
| gouthamr | ugh, 2026 | 17:48 |
| dansmith | the downside of that being someone dying to be on the TC that can't be until that happens | 17:48 |
| spotz[m] | You could have criteria of what is an extended absence. How many miised meetings might not be the best due to timezones but maybe not being active in reviews, not completing volunteered tasks? | 17:48 |
| noonedeadpunk | I was pretty sure there was smth written in more vague words which we can formalize | 17:48 |
| dansmith | so we're talking <3 months at this point, which seems hard to justify a big hoopla for, unless you're just hoping to use this as a driver to get a process in place (which is valid I guess) | 17:48 |
| gouthamr | agreed on most of those spotz[m].. | 17:49 |
| noonedeadpunk | yeah, process is valid to have | 17:49 |
| noonedeadpunk | effort might not worth it... | 17:49 |
| gouthamr | +1 on being opportunity to evolve a process regardless of what we can do | 17:49 |
| noonedeadpunk | as generally I would be expecting for people to step out formally if they can't get to end of the cadence | 17:49 |
| dansmith | right, I assume this is the first time we've had this problem in ~15 years? (assuming, I hadn't heard of it being a problem before) | 17:49 |
| spotz[m] | I think this is a future govenance thing, as mentioned we're alonst at election with no policy in place. We could put in the governance the next person from the election provided they qualify or leave open to next election if there is no one | 17:50 |
| spotz[m] | That could potentially flip the 4/5 seats though | 17:50 |
| gouthamr | in the new process you mean? | 17:51 |
| gmaan | we had such absence (at least very less active members) in past but did not do/trigger any action on that because they were not officially absent or so | 17:52 |
| spotz[m] | Yeah if we didn't have a next inline or only one next inline and they were ineligible. Might be over thinking it | 17:52 |
| gouthamr | ah! i get your point.. is that what the OIF board does? | 17:53 |
| dansmith | I guess my point is, I generally don't see a need to legislate every uncommon occurrence.. if it happens frequently (or will) then sure, but idk, seems like maybe it's just not worth the squeeze in this case | 17:53 |
| gouthamr | dansmith: i'd like to save a future chair (and TC) the headache of having to deal with the implications of this | 17:54 |
| dansmith | I understand, I'm just saying it doesn't seem like it's super likely to happen again | 17:54 |
| gouthamr | yep, hopefully | 17:55 |
| * gouthamr glances at the clock.. and at the topics added | 17:55 | |
| gouthamr | hmm, we lack the time to talk about the TC vision | 17:56 |
| gouthamr | there are some open discussion items added | 17:56 |
| spotz[m] | As far as I know OIF board doesn't have a policy, there's policies for if a gold company downgrades and if they held a gold seat but I think that is it | 17:56 |
| gouthamr | i see | 17:57 |
| gouthamr | ack, let's park the current topic and discuss if/what we'd do | 17:57 |
| fungi | (the old pre-lf openinfra bylaws had an absentee policy, the new governing board charter does not have one) | 17:57 |
| gouthamr | #topic Open Discussion | 17:57 |
| gouthamr | please continue, or seed any discussions here for post-meeting, or next week | 17:58 |
| gouthamr | noonedeadpunk: do you mind previewing the barbican-ui discussion? is this something we can do next week, and get mharley[m], ade_lee, dwilde, dmenzibal and whoever else on the barbican team involved with as well | 17:59 |
| noonedeadpunk | yes, sure | 17:59 |
| noonedeadpunk | I added it just yesterday evening | 17:59 |
| noonedeadpunk | to for sure it can wait | 18:00 |
| anfimovir | ++ | 18:00 |
| gouthamr | ack, ty.. good concern to raise | 18:00 |
| noonedeadpunk | It waited for quite a while already :D | 18:00 |
| gouthamr | same with the git 3.0 changes, i'll promote them to topics if you don't mind | 18:00 |
| gouthamr | anything to add to the meeting minutes today? | 18:01 |
| noonedeadpunk | yeah, these are more concerning and I'd expect to require some discussion | 18:01 |
| gmaan | Sorry, forgot to add it to the agenda, but a heads-up for "enforce_scope flag removal". deadline is July 3rd, and it may/will break some projects that have not fixed or merged the fixes yet. https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/M72AY5ABQFXQ7XHLVEGHLBBK4XFQGVFK/ | 18:01 |
| gouthamr | right before a US holiday, gmaan | 18:01 |
| gmaan | i proposed the fixes for some projects but not all so just want to raise it is coming | 18:01 |
| noonedeadpunk | they were raised already once, but were dismissed due to amount of effort and not that critical back in days | 18:01 |
| clarkb | gouthamr: what git 3.0 changes are we considering? | 18:01 |
| gmaan | yeah, it was started more than a month ago | 18:01 |
| gouthamr | gmaan: just kidding, thanks for bringing fireworks | 18:01 |
| gmaan | :) | 18:01 |
| noonedeadpunk | clarkb: well the default branch name changed to main for new repos | 18:02 |
| gouthamr | clarkb: it's on the agenda here, https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee - i think the concerns are branch name defaults, and checksums | 18:02 |
| noonedeadpunk | and then I wonder if removal of sha1 hashes can be problematic for some projects | 18:02 |
| clarkb | noonedeadpunk: gerrit doesn't support sha256 so you won't be able to do that | 18:03 |
| clarkb | so no it shouldn't berak anything except for your ability to push to gerrit but verything that flows from gerrit should be sha1 until gerrit/jgit add support for sha256 | 18:03 |
| clarkb | and for branch names the opendev team has said we would change the default new branch name to main for new repos when git does that switch. But this doesn't affect existing repos | 18:04 |
| noonedeadpunk | yup, it doesn't indeed | 18:04 |
| gouthamr | okay, let me wrap up the meeting, sorry to break this conversation a bit | 18:04 |
| noonedeadpunk | but then it could be that we won't love having inconsistencies in default branch names | 18:04 |
| gouthamr | thank you all for attending | 18:04 |
| gouthamr | #endmeeting | 18:04 |
| opendevmeet | Meeting ended Tue Jun 30 18:04:53 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-06-30-17.00.html | 18:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-06-30-17.00.txt | 18:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-06-30-17.00.log.html | 18:04 |
| gouthamr | clarkb: noonedeadpunk: apologies, continue.. | 18:05 |
| gouthamr | we discussed this in the past that all the charms repos use "main" already | 18:05 |
| clarkb | noonedeadpunk: yes openstack may want to consider sticking to master for consistency or plan to switch to main globally | 18:05 |
| clarkb | you can use main in opendev today without issue (though sometimes your zuul config needs a little extra help) | 18:05 |
| noonedeadpunk | right. so I wanted to raise this topic again to verify we're still commited, when default changes | 18:05 |
| clarkb | we've just decided to stick to git's defaults rather than githubs | 18:05 |
| gouthamr | ack, breaks our assumptions for things like codesearch, and i forget what else.. frickler pointed these out at the time | 18:06 |
| noonedeadpunk | zuul was not pleasent to deal with during migration or different defaults acrosss the board... | 18:06 |
| clarkb | yes I think eprsonally its not worth the effort | 18:06 |
| clarkb | there is an assumption that it is a trivial change to make but it really isn't | 18:06 |
| clarkb | and unless we want to spend a week or three focused on tracking this stuff odwn then I'm not sure it is worth it | 18:06 |
| noonedeadpunk | and for sha1/256 - I am potentially less worried about gerrit... for now... but then we need to ensure that tooling not getting on platform far enough where git3 will be default | 18:07 |
| clarkb | noonedeadpunk: git3 supports both | 18:07 |
| clarkb | it shouldn't be an issue in git3 | 18:07 |
| clarkb | what will change is only what happens when you git init aiui | 18:07 |
| clarkb | if you git init with a git3 installation you'll get sha256 by default. But if you clone a repo that is sha1 it will continue to be sha1 | 18:08 |
| noonedeadpunk | ah, ok, right, this is also only new repos | 18:08 |
| noonedeadpunk | my bad, I misread things | 18:08 |
| clarkb | yes, I think the idea is this will be a gradual change because the distros won't update to sha256 immediately and so on | 18:08 |
| clarkb | if it was an event horizon then the entire git world would break | 18:08 |
| clarkb | then eventually at some point git would presumably drop sha1 support and by then we will have needed to convert all of our repos | 18:09 |
| clarkb | but it isn't an overnight switch (nor do I think they expect people to switch like that) | 18:09 |
| clarkb | for branch renaming Zuul automatically detects the default branch for your repo if it is hosted in Gerrit | 18:10 |
| clarkb | this alleviates a lot of the zuul configuration stuff that you may need to do (there are some issues with it and Github and needing the zuul github application properly installed) | 18:10 |
| clarkb | but if you're using a mixed master in half the repos and main in the other half the repos I'm not sure it will reconcile that in all cases for jobs that set up repos with a mixture like that | 18:11 |
| clarkb | its possible that you may want to do some testing with the charm repos to find out | 18:11 |
| noonedeadpunk | I played a bit internally with changing default branch to main, and it does work with couple of branch defenitions of here and there, but I would love not to have them incosistently for openstack projects tbh | 18:12 |
| noonedeadpunk | and indeed stick with some option. | 18:12 |
| clarkb | noonedeadpunk: I think the sha256 migration process will look somethign like Gerrit+Jgit add support (also gitea but I expect it to do so quicker), then add sha256 sums concurrently to repos alongside the existing sha1 hashes (this is possible in C git and I'm not positive Gerrit will support this or not), after checking the sha256sums work in that mode then convert repos to | 18:17 |
| clarkb | sha256 primary with sha1 backup, finally drop sha1 once git sha256 sum support is in enough places | 18:17 |
| clarkb | that is a bit hand wavy because a lot of it depends on what jgit will do | 18:17 |
| noonedeadpunk | I'd assume that would take at least bunch of years to complete then | 18:18 |
| noonedeadpunk | or well, it will be couple of years just for all distros to get git3 | 18:18 |
| clarkb | https://github.com/eclipse-jgit/jgit/issues/73 is the upstream issue | 18:18 |
| clarkb | yes exactly | 18:18 |
| clarkb | we'll probably continue to have sha1 for some time | 18:18 |
| gouthamr | non-urgent, but was curious why zuul's placing errors in patches: ".ssh/known_hosts.old found in build home directory during playbook" | 20:11 |
| gouthamr | oh, we're adding more deets to catch this | 20:12 |
| gouthamr | https://review.opendev.org/c/zuul/zuul/+/995547 | 20:12 |
| clarkb | they aren't errors they are warnings | 20:13 |
| gouthamr | yes, sorry.. mischaracterization | 20:13 |
| clarkb | but the idea is that the homedir for zuul runs on the executor shouldn't be perserved between playbook invocations | 20:14 |
| clarkb | so warnings are there to help people clean them up | 20:14 |
| gouthamr | so we add playbook steps to clean this up in the base jobs somewhere? | 20:15 |
| clarkb | or just stash info outside of the homedir from the start | 20:16 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!