| *** dviroel|rover is now known as dviroel|out | 01:09 | |
| *** rlandy is now known as rlandy|out | 01:27 | |
| opendevreview | Ke Niu proposed opendev/system-config master: remove unicode prefix from code https://review.opendev.org/c/opendev/system-config/+/854487 | 03:27 |
|---|---|---|
| opendevreview | Merged openstack/diskimage-builder master: Support LVM thin provisioning https://review.opendev.org/c/openstack/diskimage-builder/+/840144 | 04:46 |
| *** ysandeep|out is now known as ysandeep | 05:17 | |
| ysandeep | We are seeing some jobs failure today with retry_limit and no logs: https://zuul.openstack.org/builds?result=RETRY_LIMIT&result=RETRY&skip=0 | 05:18 |
| ysandeep | one of an example: https://zuul.openstack.org/build/92240e39f0104c26869cb5e88b80a016 | 05:18 |
| ysandeep | Could anyone please check ^^ | 05:19 |
| *** pojadhav|out is now known as pojadhav | 05:57 | |
| *** ysandeep is now known as ysandeep|brb | 07:06 | |
| opendevreview | Michal Nasiadka proposed opendev/base-jobs master: Add rockylinux 9 x86 nodeset https://review.opendev.org/c/opendev/base-jobs/+/854551 | 07:15 |
| opendevreview | Michal Nasiadka proposed opendev/base-jobs master: Add rockylinux 9 x86 nodeset https://review.opendev.org/c/opendev/base-jobs/+/854551 | 07:17 |
| mnasiadka | Argh, didn't notice https://review.opendev.org/c/opendev/base-jobs/+/854332 | 07:19 |
| mnasiadka | infra-root - is it possible to merge https://review.opendev.org/c/opendev/base-jobs/+/854332 sooner then later? wanted to use that predefined nodeset in a project (instead of defining a local one there) | 07:20 |
| mnasiadka | oops, I probably didn't want to wake you all up ;-) | 07:21 |
| ianw_ | haha we're not all asleep :) | 07:21 |
| ianw_ | but since i proposed all that, probably better if someone else looks at it | 07:22 |
| *** jpena|off is now known as jpena | 07:40 | |
| *** ysandeep|brb is now known as ysandeep | 07:59 | |
| opendevreview | Mark Goddard proposed openstack/diskimage-builder master: Fix LVM build when VG exists on build host https://review.opendev.org/c/openstack/diskimage-builder/+/854427 | 08:24 |
| opendevreview | Rafal Lewandowski proposed openstack/diskimage-builder master: enabled lvm for jammy ubuntu release https://review.opendev.org/c/openstack/diskimage-builder/+/854566 | 08:51 |
| *** ysandeep is now known as ysandeep|lunch | 09:47 | |
| *** ysandeep|lunch is now known as ysandeep | 10:27 | |
| opendevreview | Marek Chmiel proposed openstack/diskimage-builder master: Pass ssh-agent socket to chroot env https://review.opendev.org/c/openstack/diskimage-builder/+/854608 | 10:30 |
| *** rlandy_ is now known as rlandy | 10:37 | |
| *** soniya29|ruck is now known as soniya29|ruck|afk | 11:23 | |
| *** dviroel|out is now known as dviroel|rover | 11:23 | |
| fungi | ianw_: mnasiadka: so reviewing topic:fedora-36 i guess? | 11:43 |
| *** vsevolod_ is now known as vsevolod | 11:43 | |
| mnasiadka | fungi: I would think it's not dependent on fedora-36, since I can use rockylinux-9 nodes in repo defined nodeset - but I'm not the expert here. | 11:45 |
| fungi | well, the patch you mentioned has that review topic applied to it, presumably because it depends on some others that are specific to adding f36 | 11:46 |
| fungi | there's a whole bunch of direct and indirect dependencies which are blocking it | 11:46 |
| fungi | i suppose it's possible ianw_ didn't mean to make that change depend on all the f36 ones | 11:47 |
| fungi | ysandeep: this is what caused the failure you linked: https://paste.opendev.org/show/816172/ | 11:56 |
| fungi | looks like there's a patchback/backports/stable-4/8027bc53359e8006b94802468f7b60d89c73b61b/pr-5182 branch in github.com/ansible-collections/community.general pointed to commit fcb11f90e1846ee246491e89f70a03a76a83aef0 but that commit isn't accessible by zuul | 11:57 |
| ysandeep | soniya29|ruck|afk, dviroel|rover, ^^ | 11:59 |
| fungi | though i don't see that branch if i clone the repo from github | 11:59 |
| fungi | i wonder if the problem is cached from an earlier depends-on | 12:00 |
| ysandeep | fungi, we can keep an eye incase we hit the issue again.. I don't see the issue in currently running jobs.. soniya29|ruck|afk dviroel|rover Please correct me if you are still seeing retry in Upstream gates? | 12:02 |
| fungi | well, i'm also not ruling out a bug in zuul's cache handling. going to try and see if it's happening or happened on other executors than just the one where that build happened | 12:04 |
| *** soniya29|ruck|afk is now known as soniya29|ruck | 12:05 | |
| fungi | definitely happened on multiple executors | 12:07 |
| dviroel|rover | ysandeep: fungi: we will keep an eye to see if happens again | 12:08 |
| fungi | i see 32 entries in the current executor debug logs matching 'ValueError: SHA .* could not be resolved, git returned:' | 12:10 |
| fungi | only 9 were for that fcb11f90e1846ee246491e89f70a03a76a83aef0 missing, the other 23 were for a different commit 483e60eb94b81b36ab5d00d15269d44c5d0867e4 in the same repository associated with a refs/heads/patchback/backports/stable-4/8e59e5252506aeeccb6ca5cfe38662df2f66fb23/pr-5183 | 12:15 |
| fungi | so two adjacent pull requests | 12:15 |
| fungi | dviroel|rover: ysandeep: soniya29|ruck: the earliest of those errors appears to have been at 05:04:50 utc today, and the most recent was roughly 5 hours ago at 07:35:31, so i agree whatever it was seems to have been short-lived | 12:17 |
| dviroel|rover | fungi++ | 12:18 |
| soniya29|ruck | fungi, ack | 12:18 |
| *** tosky_ is now known as tosky | 12:25 | |
| fungi | definitely something to keep an eye on. it may be that the backport pr workflow for ansible-collections/community.general is unusual or exposing some corner case bug in zuul | 12:28 |
| *** ysandeep is now known as ysandeep|brb | 12:47 | |
| *** dasm|off is now known as dasm | 13:31 | |
| Clark[m] | fungi: the problem is on the GitHub side. They delete the ref and shas when the PRs merge | 13:49 |
| Clark[m] | The PR effectively becomes a dead end and zuul can't resolve the depends on anymore | 13:49 |
| fungi | Clark[m]: just curious why the executors cared when the changes didn't depend on those | 13:50 |
| fungi | or maybe they did and i missed it | 13:50 |
| Clark[m] | Oh ya if there isn't a direct depends on then it's a race between listing the branch refs and fetching their shas | 13:51 |
| Clark[m] | Again not much we can do about that. There is a flag on the zuul side we can set to only consider protected branches if upstream follows that system. Or upstream could stop making temporary short term branches that get deleted | 13:52 |
| Clark[m] | https://zuul-ci.org/docs/zuul/latest/drivers/github.html#branch-protection-rules I think we don't set that currently because it is a tenant setting and required all GitHub repos to use protected branches | 13:54 |
| Clark[m] | Essentially for our third party CI case it isn't a safe choice | 13:55 |
| fungi | yeah, the example failed build was for https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/843835/24 which had no dependencies (direct nor indirect) and ran in check, so no dependent pipeline introduced parents either | 13:56 |
| fungi | so we can definitely see this outside of dependency fetching | 13:56 |
| Clark[m] | Yes, that happens because zuul is trying to update for all branches in the repo. It lists them then goes and tries to fetch all their heads | 13:57 |
| Clark[m] | But by the time zuul tries to fetch it has already been deleted | 13:57 |
| Clark[m] | Similar issue happens with a direct depends if you depend on something that gets deleted. | 13:57 |
| Clark[m] | Anyway, if tripleo wants to improve things I think modifying zuul to only consider protected branches on a per repo basis (rather than tenant wide) would help. Another option is to convince the upstream repo to not delete branches constantly (but apparently this is a normal GitHub workflow because you don't always generate PRs from forks) | 14:01 |
| fungi | oh, i see, the problem is they're creating temporary branches in the target repository and then creating pull requests from those rather than using forks to propose pull requests | 14:02 |
| fungi | and i guess zuul has no way to know which branches your job will actually need, it just provides them all | 14:03 |
| Clark[m] | Yes, and the problem occurs when they delete that branch after merging the PR. If they followed what I thought was normal LR workflow of creating the PR from a branch in a fork then zuul would never see that branch and it would be fine | 14:03 |
| Clark[m] | *Normal PR workflow | 14:04 |
| fungi | agreed, making pull requests from a repository to itself seems strange. i'd never noticed projects doing that before | 14:04 |
| Clark[m] | The protected branch system is the only way zuul currently knows how to filter the branch list. And that is a tenant wide setting that requires all repos in GitHub that you talk to to use protected branches | 14:05 |
| Clark[m] | At least that was my understanding last this came up. That may not be true any longer or I may be misremembering. May be worth asking GitHub users of zuul if there is more flexible solutions we can apply on a per repo basis | 14:06 |
| Clark[m] | https://zuul-ci.org/docs/zuul/latest/tenants.html#attr-tenant.untrusted-projects.%3Cproject%3E.exclude-unprotected-branches looks like we can set it per repo. There are also include and exclude branches options. | 14:08 |
| Clark[m] | The tripleo team should probably consider those options | 14:08 |
| Clark[m] | ysandeep: soniya29|ruck: ^ if that Ansible repo applies branch protections to the long lived branches you can set that flag (I don't know how to determine this) | 14:13 |
| Clark[m] | Looks like there is a main branch and stable-x branches so you could do add matchers for those to an include branches list. Or exclude the patchback branches with an exclude filter | 14:14 |
| Clark[m] | I don't know what is most appropriate so I'll leave it to ya'll to take a look and determine that and push a change if necessary | 14:15 |
| fungi | oh, yeah i think i reviewed the new exclude branches implementation recently, pretty sure it accepts regular expressions so we could exclude pr branches that way | 14:15 |
| fungi | like exclude patchback/backports/.*/pr-.* | 14:16 |
| fungi | or whatever makes sense | 14:17 |
| *** ysandeep|brb is now known as ysandeep | 14:28 | |
| *** Guest1034 is now known as clarkb | 14:32 | |
| opendevreview | Clark Boylan proposed opendev/system-config master: DNM intentional failure to hold a node https://review.opendev.org/c/opendev/system-config/+/848181 | 14:43 |
| clarkb | I've realized that I didn't hold a node for 1.17.1 to do a spot check. I've put a hold in place for ^ and can check that directly before we commit to landing the upgrade | 14:44 |
| *** dviroel is now known as dviroel|rover | 15:02 | |
| *** tosky is now known as Guest1129 | 15:12 | |
| *** tosky_ is now known as tosky | 15:12 | |
| clarkb | https://173.231.255.72:3081/opendev/system-config appears to be happy. And when I override opendev.org in /etc/hosts locally to point at 173.231.255.108 (the held load balancer) the warning banner goes away because the url accessing the site matches our config | 15:43 |
| clarkb | fungi: ^ did you want to do any additionally manual checking? Do you think we're in a safe enough portion of openstack's release cycle to approve the upgrade to gitea 1.17.1 if it looks good to you? | 15:44 |
| fungi | upgrading this week(end) is probably fine, i'll take a look at the held node after the openstack tc meeting ends | 15:45 |
| *** dviroel|rover is now known as dviroel|rover|lunch | 15:45 | |
| clarkb | ya I mean I'm around today and tomorrow if we want to do it today. I guess we can ask the release team too | 15:47 |
| clarkb | But let's start with a sanity check of the held node(s) | 15:47 |
| *** pojadhav is now known as pojadhav|out | 15:49 | |
| *** ysandeep is now known as ysandeep|out | 15:58 | |
| fungi | on the mm3 front, i've got the the contents of lists.o.o:/srv/mailman/opendev copied to 198.72.124.71:/home/fungi/opendev for production config+archive migration trials | 16:01 |
| fungi | i was originally going to copy all of /srv/mailman but that's huge apparently | 16:01 |
| fungi | the opendev site alone is half a gig even though it has very little content (i expect a lot of that is untended moderation queues) | 16:01 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script https://review.opendev.org/c/opendev/git-review/+/854648 | 16:03 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 16:03 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 16:07 |
| clarkb | infra-root: hashar and wikimedia discovered that the version of MINA on gerrit 3.4.5 and 3.5.2 and newer (3.4.4 and 3.5.1 and older are fine) doesn't validate ssh-rsa host keys properly. https://bugs.chromium.org/p/gerrit/issues/detail?id=16215 This apparently broke replication for them. I beleive this doesn't affect us because we're checking a different host key type? Replication | 16:07 |
| clarkb | does appear to function for us and has since we updated so I'm not too concerend but calling it out in case we do notice problems later | 16:07 |
| clarkb | separately there is talk of maybe backporting MINA 2.8.0 to those older gerrit stable branches. I've asked if tehy do that that they also backport the key exchange extension fix to address the ssh-rsa problems with clients | 16:08 |
| clarkb | More info here: https://gerrit.wikimedia.org/r/c/operations/puppet/+/826237/ | 16:09 |
| fungi | i refreshed my earlier reading on mm2->3 migration and pretty much all the current recommendations converge on https://docs.mailman3.org/en/latest/migration.html#upgrade-strategy | 16:29 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 16:31 |
| fungi | so for us it's basically 1. import the configs for a site, 2. import the archive, 3. rebuild the index, 4. copy the old pipermail files into a webroot matching their prior urls (possibly via rewrites/redirects) | 16:32 |
| fungi | the tricky bit is when to stop mm2 services for a site and repoint dns records | 16:32 |
| fungi | and whether we want to put any temporary forwarding in place | 16:32 |
| fungi | we could probably do this: 0. point dns for the site (or add an mx record) going to an unreachable ip address so that messages will queue at the sender's mta, 3.5 update dns to point at the new server | 16:34 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script https://review.opendev.org/c/opendev/git-review/+/854648 | 16:35 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 16:35 |
| fungi | that means a longer delay for resumption of deliveries, but probably not substantially longer, and far less effort | 16:35 |
| clarkb | fungi: pipermail is the old mm2 archives right? | 16:38 |
| clarkb | is it not possible to point them to the new mm3 archive hosting? | 16:38 |
| clarkb | it seems a little silly to carry two archives of the same content? | 16:38 |
| clarkb | Is the problem that there is no deterministic mapping from a pipermail url to a hyperkitty url? I guess that would force you to carry the old archives if you wanted to keep old urls working | 16:40 |
| *** jpena is now known as jpena|off | 16:41 | |
| fungi | clarkb: yes, pipermail is what's typically used for archive publication in conjunction with mm2, vs hyperkitty with mm3 | 16:42 |
| fungi | and yes, it's theoretically possible to work out how to make all of pipermail's url patterns map to hyperkitty's, but far easier to just have an (increasingly outdated) copy of the old pipermail archive for keeping old urls working. you can mitigate search engine confusion by blocking indexing of that in robots.txt | 16:44 |
| fungi | also bear in mind we have retired lists which are now only archives, so nowhere to "import" them unless we recreate a shell of a list to contain them and then disable listing and posting to those some other way | 16:45 |
| fungi | so we might actually want to let search engines continue indexing those specifically | 16:46 |
| fungi | at any rate, it's not much additional work. we already have to copy the old archives to the server anyway | 16:47 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script https://review.opendev.org/c/opendev/git-review/+/854648 | 17:02 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 17:02 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script https://review.opendev.org/c/opendev/git-review/+/854648 | 17:06 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 17:06 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script https://review.opendev.org/c/opendev/git-review/+/854648 | 17:08 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 17:08 |
| *** dviroel|rover|lunch is now known as dviroel|rover | 17:10 | |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 17:11 |
| opendevreview | Andy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation https://review.opendev.org/c/opendev/git-review/+/854649 | 17:14 |
| fungi | clarkb: is this possibly the same bug wikimedia observed? https://zuul.opendev.org/t/opendev/build/217cebaa8b754c85a0967dbc83b65646 | 17:37 |
| fungi | exceptionCaught(ServerSessionImpl[null@/127.0.0.1:55752])[state=Opened] SshException: Unable to negotiate key exchange for server host key algorithms (client: sk-ecdsa-sha2-nistp256@openssh.com / server: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa) | 17:37 |
| fungi | it hadn't dawned on me to try 3.4.4 instead of 3.4.5 but i'll give that a shot | 17:38 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Upgrade testing to Gerrit 3.4.4 https://review.opendev.org/c/opendev/git-review/+/849419 | 17:41 |
| clarkb | fungi: I don't know that is the same issue based on the lack of a mutual algorithm | 17:41 |
| fungi | well, easy to test the theory anyway | 17:42 |
| clarkb | fungi: in the wikimedia case I think they mutually chose a diffie helman sha + rsa algorithm that the mina library doesn't implement properly. This error seems to occur before the negotiation gets that far along | 17:42 |
| fungi | yeah, looking closer, seems unlikely | 17:42 |
| clarkb | fungi: have you had a chance to look at https://review.opendev.org/c/opendev/system-config/+/847204 via the held node yet? I'm feeling a lot more confiddent in it now that I've looked at the held node | 17:43 |
| fungi | oh, right, not yet. pulling that up now | 17:43 |
| fungi | clarkb: the "jinja" link with the red circle next to opendev/system-config in the repository browser... any clue what that's meant to represent? | 17:45 |
| fungi | might not be new, i just haven't noticed it before | 17:45 |
| fungi | looks like it's attempting to classify repositories by what programming language they use | 17:46 |
| clarkb | yes it is classifying the code content in the repo. It isn't new | 17:46 |
| clarkb | if you open the repo and click the multicolored bar under the commit count you get a breakdown | 17:46 |
| clarkb | 35.5% jinja 31.4% python and so on | 17:47 |
| fungi | oh, i had always thought that color bar was decorative! | 17:47 |
| fungi | hah | 17:47 |
| clarkb | btw I've noticed with current gitea that the text search of our repos may be good again | 17:48 |
| clarkb | I haven't felt confident enough in suggesting we delete codesearch yet | 17:48 |
| clarkb | but I've been using it off and on and been happy with the results | 17:48 |
| fungi | neat, yeah i hadn't tried it recently | 17:49 |
| fungi | they made improvements/fixes to the indexing, i guess? | 17:49 |
| clarkb | ya I'm not sure what specific improvements were made but it seems far more useful now | 17:49 |
| clarkb | I think codesearch has richer search queries and I'm not sure if gitea does multiple branch searches | 17:51 |
| clarkb | you can also do a file search with gitea that is useful if I don't want to open a terminal and run a find command :) | 17:52 |
| fungi | i wonder if we can/should do something about the file edit and delete buttons in gitea | 17:52 |
| fungi | the edit one talks about forking the repository to propose changes | 17:52 |
| fungi | not urgent though, that's been there for a long time i think | 17:53 |
| clarkb | I see the action buttons are greyed out, but they tell you what you need in order to perform the actions and we'll never give that access out | 17:53 |
| fungi | right | 17:54 |
| clarkb | I'm not sure I ever noticed that before. But I agree we should probably look into not showing them | 17:54 |
| fungi | more that it implies a different workflow/tooling than what we use | 17:54 |
| fungi | not that i think it poses any risk other than being misleading | 17:54 |
| fungi | clarkb: any idea what the "vendored" means next to the filename at https://opendev.org/opendev/system-config/commit/2d9d24d07d73d959241f3a7e4ba50e83542ebed0 ? | 17:56 |
| clarkb | I do not | 17:57 |
| clarkb | if I had to make a wild guess it is some sort of golang thing to show files for vendored libraries withing a golang project | 17:58 |
| clarkb | and whatever heuristic they use for that is tripping on that file | 17:58 |
| fungi | also seems to already be there in 1.16.9 so it's nothing new | 17:59 |
| clarkb | if you click view file the annotation goes away though | 17:59 |
| clarkb | maybe something specific in the context of a git commit | 17:59 |
| clarkb | fungi: https://github.com/go-gitea/gitea/blob/main/.gitattributes the git diff code in gitea appears to trigger off of these linguist-vendored tags | 18:01 |
| fungi | interesting | 18:01 |
| clarkb | and then if you aren't explicit about it via git attributes there is an analyze.IsVendor() call against the diff | 18:03 |
| clarkb | I suspect in our case it is the analyze.IsVendor() call that we are tripping | 18:03 |
| fungi | at any rate, it's a cosmetic thing, seems like | 18:04 |
| clarkb | yes I think so | 18:04 |
| fungi | browsing the things i expect to be able to browse works for me, as does cloning/fetching, so i'm good with upgrading whenever | 18:04 |
| fungi | all the stuff we normally disable still seems to be hidden from the yu | 18:05 |
| fungi | ui | 18:05 |
| clarkb | https://github.com/go-enry/go-enry/blob/7168084e5e5de38b915b1874528ff73f20a86b69/data/vendor.go if you match these regexes then you are vendored | 18:06 |
| clarkb | but yes I agree cosmetic and something we can influence via gitattributes (at least in the positive direction, for false positives that may be more difficult) | 18:07 |
| clarkb | https://github.com/go-enry/go-enry/blob/7168084e5e5de38b915b1874528ff73f20a86b69/data/vendor.go#L110 I think that specific line is why we are marked vendored on that file | 18:08 |
| fungi | one thing i notice on our current version is that eff privacy badger says it's blocking a cookie for api.github.com | 18:08 |
| clarkb | git grep on the gitea repo seems to show they fetch license info and gitignore info (for new repos I think) from api.github.com | 18:09 |
| fungi | that's interesting, and mildly concerning | 18:10 |
| clarkb | fungi: I don't see a github cookie in my browser though | 18:11 |
| clarkb | and ublock origin claims it isn't blocking anything | 18:11 |
| fungi | mine might be held over from an earlier session somehow. i'll try clearing it | 18:11 |
| clarkb | I have 3 cookies all for opendev.org | 18:11 |
| fungi | also the gravatar integration is causing clients to disclose their browsing to a third party | 18:12 |
| clarkb | we can disable gravatar https://docs.gitea.io/en-us/config-cheat-sheet/#picture-picture | 18:12 |
| clarkb | we should probably do that as a separate change though (either before or after the upgrade) | 18:13 |
| fungi | yeah, after telling privacy badger to block the api.github.com cookie it claimed it was providing and then clearing the settings, it's saying it sees nothing, so must have been old cruft | 18:14 |
| fungi | and yes, similar concerns about gravitar are what caused us to hold off doing https://review.opendev.org/847870 | 18:15 |
| fungi | why do applications which want to use that site not fetch and cache the icons, and then serve them to the client? against the gravatar tos maybe? | 18:16 |
| fungi | yep, that's precisely it... " Third party websites may enable the use of the Services on their respective websites as expressly authorized by Automattic (e.g., API calls into Gravatar: http://en.gravatar.com/site/implement); provided that they (i) do not copy, store..." | 18:17 |
| clarkb | ya I have no objections to disabling the feature. Just don't want to tie it to the ugprade itself | 18:18 |
| fungi | which makes me even more leery about supporting that | 18:18 |
| clarkb | so either we focus on that first or followup with it | 18:18 |
| fungi | follow up, for sure. let's upgrade asap | 18:18 |
| fungi | i was mentioning it as a separate thing, just because i happened to be looking more closely at the gitea interface than i had in a while | 18:19 |
| clarkb | ok cool. I think I've convinced myself upgrading with this change should be safe given the held node state. Do you want to +A when you're satisfied with your investigating? | 18:19 |
| clarkb | I'm around all day today and will keep an eye on ti | 18:19 |
| fungi | i'm done and approving, yep | 18:20 |
| clarkb | cool and thank you | 18:20 |
| fungi | thanks for doing all the legwork | 18:20 |
| clarkb | fungi: one thing that occured to me re pipermail is how do we manage that for private archives? Maybe we don't include those? | 18:21 |
| fungi | we don't need to worry about keeping pipermail copies of non-public archives, no. it's relatively safe to assume links won't have been published for things in them anyway since they required authentication to reach in the first place | 18:25 |
| fungi | i'm really only concerned with preserving access to things which were publicly accessible to start with | 18:26 |
| opendevreview | Tristan Cacqueray proposed openstack/diskimage-builder master: Allow flake8 version 5 https://review.opendev.org/c/openstack/diskimage-builder/+/854670 | 18:31 |
| fungi | on the topic of testing git-review with gerrit 3.4, 3.4.4 does indeed give me the same key exchange errors as 3.4.5 so it wasn't that regression at least | 18:40 |
| fungi | looking closer, i think the actual error is coming from the rest api when trying to add a client ssh key | 18:41 |
| fungi | clarkb: huh... https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini#L1718-L1721 | 18:56 |
| *** kopecmartin is now known as kopecmartin|pto | 18:57 | |
| clarkb | fungi: ya I think that is an alternative to gravatar? | 19:00 |
| clarkb | hrm though it seems tied to the gravatar setting so maybe not | 19:01 |
| fungi | yeah, albeit federated and software we could choose to run for our users to host their avatars in. libravatar's integration documentation recommends setting referrerpolicy="no-referrer" when embedding images. i'm trying to find any indication of whether their fallback service has a tos forbidding server-side querying/caching | 19:01 |
| fungi | for whatever reason, gitea has decided to tie its libravatar support to its gravatar config option, and uses gravatar as a fallback when libravatar returns nothing, based on what i can piece together at least. seems like it may be possible to not have it actually fall back on gravatar though | 19:09 |
| fungi | anyway, if people really dislike us turning off gravatar support, that may be an alternative. more compelling since it also has openid mapping options, so we might be able to associate an instance with our sso if we really want | 19:11 |
| fungi | clarkb: you started an etherpad where we were collecting mailman upgrade notes, right? i seem to have lost the pad name and just want to make sure i take more notes in the right place | 19:22 |
| clarkb | fungi: no, everything has been in the change so far | 19:23 |
| clarkb | I think you may have had an etherpad from earlier investigations though | 19:23 |
| opendevreview | Merged opendev/system-config master: Update to Gitea 1.17 https://review.opendev.org/c/opendev/system-config/+/847204 | 19:24 |
| fungi | ahh, yeah i had an old mm3poc pad, for some reason i thought we had some other notes somewhere | 19:25 |
| fungi | was going to start drafting up a migration plan/process with the commands i'm running just so this is repeatable | 19:25 |
| fungi | i'll work on it in https://etherpad.opendev.org/p/mm3migration | 19:27 |
| clarkb | sounds good,thanks | 19:28 |
| clarkb | two more hourly jobs then 847204 will start deploying | 19:28 |
| fungi | excellent | 19:28 |
| clarkb | the first 4 giteas have updated | 19:55 |
| clarkb | I can web browse and git clone | 19:56 |
| clarkb | all 8 appear done now. Just waitingfor the job to complete | 20:06 |
| clarkb | the job completed successfully according to zuul. I'm yet to see any problems myself | 20:11 |
| fungi | yep, just got back from picking up some lazy takeout, but they lgtm too | 20:18 |
| *** ianw_ is now known as ianw | 20:37 | |
| ianw | fungi: sorry, yeah that rocky node addition can be rebased on master if we like | 20:38 |
| ianw | i'll just merge both, i was mostly worried about a typo or something | 20:39 |
| ianw | clarkb: the gitea code search is per-repo though? (as opposed to hound?) I do also like that hound does regexes, although the "fuzzy" matching in gitea seems pretty good | 20:43 |
| clarkb | ianw: ya they aren't overlapping in utility. its possible the gitea search may never replace hound. Just in the past gitea search didn't really work at all | 20:45 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Disable Gravatar in Gitea https://review.opendev.org/c/opendev/system-config/+/854678 | 20:54 |
| clarkb | fungi: ^ we should check screenshots and see how that affects local avatar storage (for the various projects which we manage directly) | 20:54 |
| frickler | incidentally I noticed the "vendored" thing earlier today for https://opendev.org/openstack/oslo.cache/commit/7fb06bc2034d9747c9721c9d3eff06925a4483c6 which marks almost everything, which doesn't make any sense at all to me | 21:17 |
| fungi | yeah, the pattern matches for that seem a bit too broad | 21:18 |
| fungi | maybe they should also be limited by file extension or something | 21:19 |
| clarkb | I think https://github.com/go-enry/go-enry/blob/7168084e5e5de38b915b1874528ff73f20a86b69/data/vendor.go is the rule hitting frickler's example | 21:20 |
| clarkb | Looking at their rules more closely it seems they want to match the start of the string or / at the beginning but I suspect that however they do the match treats those bits as optional | 21:20 |
| fungi | (^|/)cache/ | 21:20 |
| fungi | yep | 21:20 |
| frickler | seems to be because of `(^|/)cache/` vs. "oslo_cache", but ignores the ^ | 21:21 |
| fungi | it may be tokenizing and treating _ as a token separator | 21:22 |
| fungi | so parses /oslo and then parses cache/ | 21:22 |
| fungi | though probably not, since there are literal _ elsewhere in the expressions which aren't escaped or anything | 21:23 |
| frickler | which would seem pretty useless to me. anyway, EOD here | 21:23 |
| fungi | yeah, no clue | 21:23 |
| clarkb | it seems to be using golang's normal regexp library | 21:23 |
| clarkb | It says it does a left most match. I wonder if ^ is effectively useless in that case | 21:24 |
| clarkb | https://regoio.herokuapp.com/ says that isn't the case though | 21:25 |
| clarkb | actually I think https://github.com/go-enry/go-enry/blob/7168084e5e5de38b915b1874528ff73f20a86b69/data/vendor.go might be buggy | 21:26 |
| clarkb | * https://github.com/go-enry/go-enry/blob/7168084e5e5de38b915b1874528ff73f20a86b69/utils.go#L140 may be buggy | 21:27 |
| fungi | oh yikes | 21:28 |
| fungi | that looks like a recipe for disaster | 21:28 |
| fungi | in order to be sure that's even a safe idea (implementation notwithstanding) i'd have to dust off a bunch of old brain cells i shelved after i finished set theory | 21:31 |
| clarkb | I think what they are trying to accomplish is functionally the same as checking each regex separately and returning true if one matches | 21:33 |
| clarkb | since you can have a finite automata that basically implements the if elif elif etc | 21:33 |
| fungi | it might be safe as long as they don't do any lookaround (positive or negative lookahead/lookbehind)? | 21:33 |
| clarkb | ya if you do something more powerful than a finite automata then it might get weird | 21:36 |
| clarkb | ok that library (enry) wraps around the definitions in https://github.com/github/linguist/blob/master/lib/linguist/vendor.yml | 21:37 |
| *** rlandy is now known as rlandy|bbl | 21:38 | |
| clarkb | I'm installing go now | 21:40 |
| fungi | my condolences | 21:41 |
| clarkb | ok I have small reproducer now | 21:51 |
| fungi | go go gadget regex | 21:53 |
| *** tosky_ is now known as tosky | 22:06 | |
| clarkb | https://github.com/go-enry/go-enry/issues/135 | 22:11 |
| *** dasm is now known as dasm|off | 22:32 | |
| mnaser__ | is gerrit stuck by any chance? | 22:34 |
| mnaser__ | `ssh mnaser@review.opendev.org -p29418` is not responsive from my local system | 22:34 |
| mnaser__ | but i can open the web ui | 22:34 |
| mnaser__ | ah i think that might be my side since it works on another remote vm, weird | 22:34 |
| mnaser__ | my ssh-agent seems dead | 22:34 |
| fungi | that'd do it | 22:35 |
| mnaser__ | my yubikey seems to just do nothing when im trying to add it to my ssh-agent. fun | 22:35 |
| clarkb | I was wondering if this was a case of what we are trying to mitigate against but cacti is looking clean and `gerrit ls-projects` works for me | 22:36 |
| mnaser__ | well, plugging it out and back in did the trick | 22:37 |
| fungi | yubikey equivalent of "have you tried turning it off and on again?" | 22:38 |
| *** rlandy|bbl is now known as rlandy | 22:47 | |
| clarkb | fungi: https://paste.opendev.org/show/bfRYQjx2E38eqtpIOyL4/ thats the end result regexp expression according to the debugger | 22:48 |
| clarkb | I'm working on formatting it so it is easier to understand | 22:50 |
| clarkb | and now I think I see the bug | 23:04 |
| clarkb | The issue has details. I'm working on a PR now | 23:15 |
| clarkb | fungi: frickler: https://github.com/go-enry/go-enry/pull/136 if that lands and gitea updates the go-enry version this issue will go away | 23:28 |
| opendevreview | Tim Burke proposed openstack/project-config master: test-release-openstack: Collect tested artifacts https://review.opendev.org/c/openstack/project-config/+/854681 | 23:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!