ianw | backup02 prune is running in a screen | 00:01 |
---|---|---|
Clark[m] | ianw: Foundation feedback is that the update looks great | 00:04 |
ianw | ok, i can send that on then | 00:04 |
opendevreview | Ian Wienand proposed opendev/system-config master: infra-prod: run job against linaro https://review.opendev.org/c/opendev/system-config/+/877436 | 01:05 |
wxy-xiyuan | Just checked the openEuler job timeout problem. it looks that the network speed is very very slow when do `yum install`, I'll check why and how to speed up it. | 01:53 |
wxy-xiyuan | oh, wrong channel. Sorry. | 01:55 |
ianw | #status log pruned backups on backup02 | 03:10 |
opendevstatus | ianw: finished logging | 03:10 |
opendevreview | Ian Wienand proposed openstack/diskimage-builder master: Update Fedora to 37 https://review.opendev.org/c/openstack/diskimage-builder/+/876482 | 03:43 |
opendevreview | Ian Wienand proposed openstack/diskimage-builder master: Removal focal pins for testing https://review.opendev.org/c/openstack/diskimage-builder/+/877443 | 03:43 |
opendevreview | Merged openstack/diskimage-builder master: chore: support building Fedora on arm64 AKA aarch64 https://review.opendev.org/c/openstack/diskimage-builder/+/877112 | 04:54 |
opendevreview | Ian Wienand proposed openstack/diskimage-builder master: Update Fedora to 37 https://review.opendev.org/c/openstack/diskimage-builder/+/876482 | 05:18 |
mnasiadka | Clark[m]: we have a free account, actually it's an organisation - as long as all of the repositories are public it's free (but when you push the image for the first time it sets the repository as private, but can be changed with an API call) | 06:34 |
*** elodilles is now known as elodilles_pto | 06:49 | |
*** jpena|off is now known as jpena | 08:37 | |
opendevreview | Dr. Jens Harbott proposed openstack/project-config master: Fix approval check for post-review trigger https://review.opendev.org/c/openstack/project-config/+/877453 | 09:16 |
frickler | infra-root: discovered ^^ while debugging with gtema. maybe someone wants to also look into making zuul recognize the issue earlier | 09:17 |
opendevreview | Merged openstack/project-config master: Fix approval check for post-review trigger https://review.opendev.org/c/openstack/project-config/+/877453 | 09:38 |
opendevreview | Artem Goncharov proposed openstack/project-config master: Add post-review pipeline reporting https://review.opendev.org/c/openstack/project-config/+/877458 | 10:37 |
opendevreview | Merged openstack/project-config master: Add post-review pipeline reporting https://review.opendev.org/c/openstack/project-config/+/877458 | 10:58 |
fungi | okay, this is downright frightening... is it an emerging trend in software development education? https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/QORLREOKS23LDJAEYUFMSYO4YPDNK7OD/ | 12:13 |
*** blarnath is now known as d34dh0r53 | 12:23 | |
NeilHanlon | fungi: i'd like to cancel my subscription to the internet now, thank you. | 14:28 |
fungi | people are are so insistent on avoiding actually reading documentation and learning things that, instead of annoying people who did that by asking them to answer things already covered in documentation, they just ask ai now | 14:33 |
fungi | i guess too many "rtfm" replies have backfired and created a worse problem | 14:33 |
NeilHanlon | i've been playing around with using 'chatgpt' as a starting point for some stuff (particularly: kernel inner workings and the like), but the idea that it could just give me answers on how to do X is ... I want to say laughable, but that's not quite it. There's some reason people think it's "magic" and not just.. guessing the next word | 14:46 |
fungi | i'll admit i've not actually tried that, but based on my crude understanding of the limitations of ai/ml technologies today it seems more likely to confuse learners and lead to a sort of ignorance feedback loop | 14:48 |
NeilHanlon | I agree with that. If you think the magic box is truly doing magic, bad things will happen. If you know the magic box is just a complex series of if statements... i guess it can be a useful tool. Or rather, it has been moderately useful to me in certain situations | 14:50 |
fungi | the accuracy of the information provided to a student contributes significantly to the quality of their education. i'm remembering advice from my first guitar teacher: practicing on a poorly-made instrument is the best way to learn to play badly | 14:55 |
fungi | but also, i'm imagining an ai trained on "answers" in the ubuntu forums. it's all too easy to find authoritative-looking advice that is in actuality entirely wrong, and often times even dangerous when followed | 14:57 |
NeilHanlon | 100% | 15:14 |
jrosser | theres nothing can be done but as an information point my connectivity to opendev.org via zayo has turned terrible again | 15:31 |
fungi | it's possible that padding announcements and setting prefs at the provider's edge would be sufficient to route most traffic around zayo, but i'm guessing they already tune their ebgp to optimize billing from the backbones they peer with | 15:34 |
fungi | still, it's good feedback for mnaser that communication to/from vexxhost's sjc1 region has been frequently impacted by transit issues inside zayo's network | 15:36 |
fungi | it may prove important when his contract with them comes up for renewal | 15:36 |
jrosser | it's not a fix but since this happened before i patched openstack-ansible to allow this `openstack_opendev_base_url: https://github.com` | 15:37 |
jrosser | so at least i can continue working with everything swung over to the github equivalent git repos with just one variable now | 15:38 |
NeilHanlon | fucking Zayo | 15:41 |
NeilHanlon | sorry. i'm still bitter, apparently | 15:42 |
jrosser | looks like we and zayo/above meet and LINX and we're straight into their network in london | 15:42 |
jrosser | *meet at | 15:42 |
NeilHanlon | jrosser: v4 or v6, if I may ask | 15:42 |
jrosser | v4 in this case | 15:43 |
NeilHanlon | does your latency increase at/around LINX? | 15:43 |
NeilHanlon | (I have a 'friend' I can... nag ;) ) | 15:43 |
jrosser | it looks like this https://paste.opendev.org/show/b8W9hjhiWsaTUUDLDsOS/ | 15:44 |
NeilHanlon | lol.jpg | 15:44 |
jrosser | but tbh i think people more geograpically widespread than london have seen similar trying to get to opendev.org | 15:45 |
NeilHanlon | i had a time when Zayo was shipping my traffic from Boston to New York to Boston to get to me | 15:46 |
fungi | jrosser: yes, the traces we looked at previously showed significant degradation in london and atlanta | 15:46 |
fungi | i want to say that the people who reported connectivity issues from germany had traceroutes that ended up going through london as well, but now i don't recall for certain | 15:47 |
NeilHanlon | "The packets stopped for tea" - my friends are so helpful | 15:48 |
fungi | it is about that time | 15:49 |
* fungi puts a kettle on | 15:49 | |
fungi | unfortunately, my packets going through atlanta are stopping for a tall glass of sweet tea | 15:50 |
NeilHanlon | annndd now they have diabetes | 15:51 |
fungi | known to the rest of the world as tea-colored syrup | 15:52 |
* clarkb is having a very slow start today. Probably a good thing after yesterday | 15:56 | |
fungi | take your time, nothing is on fire | 15:57 |
clarkb | ya I'll attend the openstack TC meeting then probably double check gitea09 backups are running properly. THen I don't know what is next | 15:57 |
fungi | though i have to duck out of the tc meeting early to pick up my grocery order. scheduling error since i booked that time a week ago and forgot to take the usa time change into account | 15:58 |
clarkb | should be fine, I'll keep an eye on it and fill in if necessary | 15:58 |
* fungi shakes his fist at twice-yearly timezone changes | 15:58 | |
clarkb | infra-root do we want to set a time to discuss our docker decisions? We could do an IRC meeting or jitsi meet call if we want something more formal | 16:00 |
clarkb | otherwise its probably fine to just have a time to discuss it in here | 16:00 |
fungi | i'm fine doing it in here, or in #opendev-meeting if we want to record minutes | 16:01 |
clarkb | maybe we can do 1900 UTC tomorrow? thinking that probably has the best overlap for ianw and frickler | 16:02 |
fungi | wfm, i'm free then | 16:04 |
NeilHanlon | i'll attend as a fly on the wall.. still haven't heard back from Docker via email, unfortunately. I'm seriously considering and weighing if Rocky could support a community-owned container registry.. which I think we could, it's just.. time :) | 16:04 |
clarkb | corvus: ianw frickler does 19:00 UTC Thursday March 16 work for docker decision making discussion? | 16:05 |
fungi | NeilHanlon: well, time, but possibly also storage and bandwidth depending on the number/size of images you're hosting and their popularity | 16:06 |
NeilHanlon | yeah. i need to chat with our sponsors (mostly, fastly) to see how they feel about it | 16:09 |
fungi | that's going to be my biggest concern if we decide to run an image repository, since it only makes sense to me to put time into maintaining that service if we can offer it to all the projects we're hosting | 16:12 |
fungi | and some of our projects have a lot of large images | 16:13 |
fungi | i should say, some of the projects hosted in the collaboratory have anyway | 16:13 |
NeilHanlon | sure, that makes sense. i will chat with Fastly. maybe something that can be a collaborative effort to maintain and 'own' | 16:15 |
clarkb | fungi: large images and they insist on building 5 versions of each one :) | 16:16 |
NeilHanlon | surely the cloud is free :P | 16:17 |
fungi | at least for a write-only repository backed by by the infinite storage of /dev/null | 16:19 |
clarkb | it will be sunny and 11C today. I should make sure the laptop is charged | 16:20 |
NeilHanlon | yes, you should. vitamin D is good (or something) | 16:22 |
fungi | a bit cold here on the east coast. was almost cold enough to freeze around the dock pilings overnight | 16:24 |
fungi | but mainly just unpleasantly windy, which makes the cold feel... colder | 16:24 |
clarkb | we had a couple of nice weeks in january and it has been pretty meh until the last couple of days or so | 16:27 |
clarkb | december was really cold too | 16:27 |
clarkb | Hopefully spring is here now. Some of the flowers seem to think so too | 16:27 |
NeilHanlon | yeah we just got dumped on here in Massachusetts... so.. spring next month, if all goes well :P | 16:30 |
fungi | by the time you're able to dig out | 16:31 |
fungi | okay, headed out to run errands, back within the hour i hope | 16:47 |
corvus | clarkb: that time wfm | 17:20 |
*** jpena is now known as jpena|off | 17:42 | |
clarkb | I've double checked the gitea09 backups by mounting them for each backup server and I see mysql dumps (the main things we are concerned with) as well as content in my homedir that acts as a good fs check | 17:45 |
clarkb | I think that means backups are working as expected | 17:46 |
clarkb | in the process I discovered that you don't always need to escape : in bash? | 17:46 |
clarkb | the timestamp based backup dirs when FUSE mounting have :'s in them and I was able to ls the names without escaping the noop char. Interesting | 17:48 |
clarkb | if anyone else wants to dobule check that isprobably not a bad idea but I think other than confidence in handling user demands and cleaning up the remaining old servers this is all done | 17:49 |
clarkb | hrm gitea has two 1.19.0 release RCs but no updated changelog info for them yet. Probably best to ait until we have that info before worrying about a change to test the update | 17:51 |
clarkb | oh except synchronizing the templates may be worthwhile. /me looks | 17:53 |
fungi | okay, i'm back. took longer than hoped but not by too much | 17:54 |
opendevreview | Julia Kreger proposed openstack/diskimage-builder master: Add a FIPS element https://review.opendev.org/c/openstack/diskimage-builder/+/877539 | 18:00 |
opendevreview | Clark Boylan proposed opendev/system-config master: WIP Begin gitea 1.19.x update https://review.opendev.org/c/opendev/system-config/+/877541 | 18:17 |
clarkb | The templates do need a fair bit of updates but it all seems pretty straightforward and mechanical. I also updated the golang and nodejs version to match the upstream dockerfile | 18:23 |
clarkb | htought now that I think of it I may have looked at the master dockerfile not 1.19 /me double checks | 18:23 |
clarkb | I did, but main and 1.19.-rc1 use the same compiler versions | 18:24 |
clarkb | fungi: NeilHanlon: the mailman maintainer responded to that email saying "this is not what you want to do" and described a very different path to adding the functionality | 18:33 |
clarkb | maybe ya'll saw that alraedy but I just caught up and thought that was interesting | 18:40 |
fungi | yeah, it's definitely been an amusing ml thread | 18:43 |
clarkb | corvus: https://access.redhat.com/articles/quayio-help has more quay info. Though after reading this it feels more like you have to pay for at least a dev account then public repos are free. But they keep reiterating you can use it for free os maybe I'm just thinking too hard about it | 18:45 |
clarkb | mnasiadka: ^ do you know if you can just sign up to quay creating a new account without purchasing anything? | 18:45 |
clarkb | poking around it kinda feels like we should be able to create a shared acount then use that account to create an organization. And maybe do that separately for both opendev and zuul. Then assuming this doesn't require any billing we'll be set? | 18:51 |
fungi | sounds worth a try | 18:52 |
fungi | and at least our communities already have relationships with red hat, unlike for the owners of other popular public registries | 18:54 |
corvus | i agree it's worth a try -- note that it looks like a phone # is required | 19:42 |
corvus | clarkb: i agree though, it seems like at least one dev account is required and it has a cost | 19:44 |
corvus | but also that there are sentences like "The service is free for those who want to set up their own public repositories and available for a fee, if you want to create private repositories." | 19:46 |
corvus | it seems like they're trying to say it's possible to do the thing we want, but in all the steps that describe how to set stuff up, they don't indicate how to do the thing we want :) | 19:46 |
Clark[m] | Exactly | 19:47 |
ianw | clarkb: i can do 19:00 utc tomorrow, only time i'm out is 21:30-21:50 for school drop off | 19:58 |
ianw | one interesting thing just cleaned from a HN comment is https://hub.docker.com/search?q=&type=image&image_filter=official | 20:04 |
clarkb | ianw: ya I suspect that those images we rely on will be ok due to their status | 20:04 |
ianw | i think most (all) of our base images that we're pulling are "docker official" | 20:05 |
clarkb | which really leaves the exposure for other images to jitsi, jaeger, and a few others | 20:05 |
fungi | this is an interesting discrepancy: https://codesearch.opendev.org/?q=publish-tox-docs-releases https://opendev.org/explore/code?q=publish-tox-docs-releases | 20:05 |
ianw | name: publish-tox-docs-releases doesn't find anything at all ... suggesting project-config isn't indexed? | 20:07 |
fungi | well, for me codesearch is turning it up in two projects but gitea is only finding it in one | 20:07 |
fungi | maybe it depends on the gitea backend i hit | 20:08 |
ianw | right, it doesn't find it in a direct search on project-config etiher (on gitea) | 20:09 |
ianw | https://opendev.org/openstack/project-config/search?q=the&t= | 20:09 |
ianw | does give some results, so it has *something* | 20:09 |
fungi | gitea01 has both hits, gitea09-12 don't | 20:09 |
opendevreview | Clark Boylan proposed opendev/system-config master: WIP Begin gitea 1.19.x update https://review.opendev.org/c/opendev/system-config/+/877541 | 20:09 |
fungi | so maybe something's incomplete in the search indices on the new gitea servers? | 20:10 |
clarkb | that change removes a no_log setting because it seems some sort of api has changed around listing orgs. Needs more debugging | 20:10 |
clarkb | fungi: ya maybe has to do with how we populate things with gerrit replication. I think it builds the indexes on startup | 20:10 |
clarkb | fungi: its possible we haven't indexed some thingsbecause we haven't restarted since the content was pushed in? | 20:10 |
fungi | yep, 01-04 all find it in project-config as well as releases, while 09-12 only find it in releases and not project-config | 20:11 |
fungi | maybe we haven't merged anything in project-config? seems unlikely, but... | 20:11 |
clarkb | pretty sure ianw's acl changes have occurred since at least 09 is in place | 20:11 |
clarkb | my hunch is it is more to do with the startup index processing that happens | 20:11 |
fungi | yeah, we merged things in project-config as recently as 5 hours ago | 20:12 |
clarkb | But I'm not super familar with the mechanisms that update the indexes there | 20:12 |
fungi | just odd that the index would have one repo but not the other in that case | 20:12 |
clarkb | https://github.com/go-gitea/gitea/issues/3796 | 20:13 |
clarkb | https://github.com/go-gitea/gitea/issues/3796#issuecomment-588254661 specifically seems to be the issue we've got | 20:14 |
fungi | still somewhat baffling that it decided to index one of two repos | 20:17 |
clarkb | ya maybe there is some event that triggers things that has happened for one repo but not the other? | 20:18 |
clarkb | releases isn't branched and has no tags so that isn't it | 20:18 |
clarkb | its the same code running on both gitea01 and gitea09 (same containers etc) | 20:19 |
fungi | maybe it's per-file and when a file is updated it indexes it | 20:19 |
clarkb | oh that could very well be it | 20:19 |
fungi | though no, that file in releases was last updated in january | 20:20 |
clarkb | it says "last indexed 1 day ago" | 20:20 |
clarkb | which is less recent the most recent push to releases | 20:21 |
clarkb | fungi: if you search for "originate" it shows up in project-config/zuul.d/pipelines.aml which was update a few hours ago | 20:22 |
fungi | oh | 20:22 |
clarkb | and it indicates it last indexed that a few hours ago. I'm guessing your hunch here is very close | 20:22 |
fungi | though project-config is the one it hasn't indexed | 20:23 |
fungi | at least as far as search results are concerned | 20:23 |
clarkb | no, it is indexed is my point | 20:23 |
clarkb | at least some of it | 20:23 |
clarkb | I bet it is something like it only indexes the file or directories that are modified when things are changed and not the entire repo | 20:23 |
clarkb | max-concurrency is another term that shows up and was recently added to a file | 20:27 |
opendevreview | Jeremy Stanley proposed openstack/project-config master: Temporarily remove release docs semaphores https://review.opendev.org/c/openstack/project-config/+/877552 | 20:28 |
opendevreview | Jeremy Stanley proposed openstack/project-config master: Revert "Temporarily remove release docs semaphores" https://review.opendev.org/c/openstack/project-config/+/877553 | 20:28 |
fungi | clarkb: ^ your idea | 20:28 |
clarkb | re gitea it is definitely indexing project-config but it seems like it is consistently indexing files that have been updated since the service is up but not others. However, I agree releases/.zuul.yaml doesn't appear to have updated recently either. Maybe someone pushed a change that updates releases/.zuul.yaml that is unmerged and that tripped the indexer? | 20:31 |
clarkb | since unmerged changes get replicated too | 20:31 |
fungi | that would be interesting, since they don't get included in the search results | 20:32 |
clarkb | oh yup it even says indexed 5 days ago when you search max-concurrency and that is when it merged | 20:32 |
clarkb | so definitely seems tied towhen files are being updated somehow | 20:32 |
clarkb | but the originate typo was more recent and gives a different indexed time stamp | 20:33 |
clarkb | trying other terms from that missing file also shows no results. Really makes me think it just hasn't indexed that file because we haven't crated and event that would cause that to happen | 20:41 |
fungi | maybe the file is too large and gitea's search doesn't index files over a certain size? | 20:46 |
clarkb | that could be. Gerrit definitely has those file size short circuits for rendering the files | 20:46 |
clarkb | we just got an alert that the translate-MySQL_upgrade DB has less than 10% of its disk free | 20:51 |
clarkb | I suspect this is probably fine since openstack is moving towards weblate now | 20:51 |
clarkb | and if this was the first time we've gotten the warning we should be just under that threshold, but I have a school run shortly so not really going to double check those assumptions right now :) | 20:51 |
fungi | my guess is that new copies of strings were made or something for creation of the 2023.2 branches | 20:55 |
fungi | but i agree, growth there is slow enough we can likely ignore it until weblate has fully reached production and zanata is retired | 20:56 |
clarkb | ya exactly if it took this long to reach 90% chances are we're ok for a while | 20:58 |
ianw | clarkb: https://review.opendev.org/c/opendev/system-config/+/877436 was the result of the discussion yesterday about partially managed hosts | 20:59 |
clarkb | ianw: I wonder if "!foo:!bar" means not foo and not bar or not foo or not bar | 21:00 |
clarkb | https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html#common-patterns doesn't make it clear. But I think understanding that is important otherwise we could still run the base playbook there (should be easy enough to test with a mock up inventory could even use a job for that?) | 21:03 |
opendevreview | Julia Kreger proposed openstack/diskimage-builder master: Correct boot path to cover FIPS usage cases https://review.opendev.org/c/openstack/diskimage-builder/+/876192 | 21:09 |
opendevreview | Julia Kreger proposed openstack/diskimage-builder master: Add a FIPS element https://review.opendev.org/c/openstack/diskimage-builder/+/877539 | 21:09 |
opendevreview | Jay Faulkner proposed opendev/infra-manual master: Trivial: fix image sizing in creators guide https://review.opendev.org/c/opendev/infra-manual/+/877554 | 21:18 |
ianw | i hope it's "or" | 21:20 |
NeilHanlon | something something demorgan's law | 21:24 |
clarkb | I always end up with ansible groups not doing what I expect when I set up my local ansible install | 22:00 |
clarkb | the whole inventory in fact and eventually I give up and move on and just use the default localhost thing to test whatever task I was actually interested in. Hence my caution | 22:00 |
ianw | yeah i'll test | 22:05 |
clarkb | https://docs.ansible.com/ansible/latest/inventory_guide/intro_patterns.html#pattern-processing-order I think that may be the document we want | 22:05 |
ianw | i started writing up a .dot of the image build requirements. we have a lot of image builds | 22:05 |
clarkb | I think it does what we want. a:b:!e:!d:&c means Host in/is (a or b) AND host in/is all(c) AND host NOT in/is all(e, d). | 22:06 |
clarkb | ianw: we haev a lot of builds but most of them are basically take either an upstream official base image or our own python base image and then build an image on that. Which is nice because it means we aren't doing a ton of nesting its all only a few levels of image | 22:07 |
ianw | yeah it's not too deep, just long | 22:07 |
ianw | i just just trying to colorize between the "library" images upstream and things under other orgs | 22:08 |
ianw | which you've already done with https://etherpad.opendev.org/p/MJTzrNTDMFyEUxi1ReSo anyway | 22:08 |
opendevreview | Clark Boylan proposed opendev/system-config master: WIP Begin gitea 1.19.x update https://review.opendev.org/c/opendev/system-config/+/877541 | 22:28 |
clarkb | apparently ansible's uri module expects a 401 back to know it needs to send the basic auth headers by default. But if you specify expected http return codes (like we do to 200) then that 401 is an error and it doesn't proceed | 22:28 |
clarkb | so you have to force it to send the auth header upfront | 22:28 |
clarkb | that was a fun one | 22:29 |
clarkb | fungi: pip's dep solver doesn't take into account existing pacakge install's and their dependency requirements? if it does then I think requests may have a buggy set of dependencies (it seems my git-review venv at some point updated chardet to a version requests didn't like so it warned about it but I think that could only happen if the dep solver didn't consider requests deps or | 22:42 |
clarkb | requests simply doesn't express that dep properly) | 22:42 |
fungi | pip's dep solver does take installed packages into account now | 22:52 |
fungi | supposedly | 22:53 |
fungi | that's why the situation with using pip in the system python context has gotten increasingly volatile, pip wants to know how to satisfy dependencies for installed packages, and can't upgrade or necessarily even figure those out when installed by something other than pip | 22:54 |
clarkb | ya so maybe requests has a buggy dep specification | 22:58 |
clarkb | becuase it would've prevented something else from intsalling newer chardet otherwise | 22:58 |
fungi | or would have upgraded requests | 23:21 |
fungi | i'm not sure which | 23:22 |
Ramereth | fungi clarkb NeilHanlon: update from yesterday WRT OSS docker program. This morning I got an email that stated Docker Team - Annual was added to the osuosl account. I confirmed that was the case. I also finally got a confirmation email for the other submission I had done for another project (cinc) | 23:33 |
fungi | that's fast, thanks for the details! | 23:33 |
clarkb | Ramereth: nice that sounds like it was quick and easy compared to our previous attempt. Good to see they have streamlined things | 23:34 |
Ramereth | hopefully that's the same for others if they had re-submitted using the form | 23:34 |
fungi | the github issue chronicling all this seemed to be full of people saying "we applied in [2020...2021...2022] and at most only got back an automated reply or two that they'll tell us something eventually but heard nothing else" | 23:35 |
Ramereth | yeah I noticed that too | 23:35 |
fungi | i guess the sudden flood of new applicants and publicity has forced them to get more serious about processing those | 23:35 |
Ramereth | ayup | 23:35 |
fungi | infra-root: i guess https://bugs.chromium.org/p/gerrit/issues/detail?id=16765 is likely to impact our gerrit upgrade plans? at least for the broken relation chain links (we don't use submitted together as far as i know) | 23:36 |
fungi | likely there will be a 3.7.2 fixing it by the time we're ready to upgrade, i guess | 23:37 |
clarkb | fungi: yes, but also I think that may just be informational? | 23:39 |
clarkb | we may decide it isn't broken enough to prevent the upgrade? | 23:39 |
fungi | right, i was mainly thinking from a user inconvenience perspective, but maybe upgrading anyway outweighs that | 23:39 |
clarkb | ya I'm not sure yet myself. Definitely worth considering | 23:39 |
clarkb | On the one hand that info is nice on the other its never been rich enough to address me needing to look at shas anyway | 23:40 |
fungi | i mostly point people to the relation chain when they ask why a change isn't merging and its because they never approved its parents | 23:40 |
clarkb | this is something gertty does a million times better than the web ui | 23:40 |
fungi | well, what gertty does is what the old "new" change screen did | 23:41 |
fungi | which, yes, is far more useful to me anyway | 23:41 |
clarkb | gerrit has always been linear though gertty has branching which is one of the main things | 23:41 |
clarkb | you can't tell just by looking at what the web ui shows you if the change is a peer or a parent | 23:42 |
opendevreview | Clark Boylan proposed opendev/system-config master: WIP Begin gitea 1.19.x update https://review.opendev.org/c/opendev/system-config/+/877541 | 23:42 |
clarkb | hopefully thats 90% of the necessary changes to upgrade to 1.19.x once there is a changelog | 23:43 |
fungi | OpenSSH 9.3 (Bugfixes): ssh-add(1), ssh-keygen(1): use RSA/SHA256 when testing usability of private keys as some systems are starting to disable RSA/SHA1 in libcrypto. | 23:44 |
fungi | closer, but still they haven't changed the client connection default, doesn't sound like | 23:44 |
fungi | not that it matters for us any more since gerrit's finally fixed it at the server end | 23:48 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!