Thursday, 2022-08-25

*** dviroel|rover is now known as dviroel|out01:09
*** rlandy is now known as rlandy|out01:27
opendevreviewKe Niu proposed opendev/system-config master: remove unicode prefix from code
opendevreviewMerged openstack/diskimage-builder master: Support LVM thin provisioning
*** ysandeep|out is now known as ysandeep05:17
ysandeepWe are seeing some jobs failure today with retry_limit and no logs:
ysandeepone of an example: 05:18
ysandeepCould anyone please check ^^05:19
*** pojadhav|out is now known as pojadhav05:57
*** ysandeep is now known as ysandeep|brb07:06
opendevreviewMichal Nasiadka proposed opendev/base-jobs master: Add rockylinux 9 x86 nodeset
opendevreviewMichal Nasiadka proposed opendev/base-jobs master: Add rockylinux 9 x86 nodeset
mnasiadkaArgh, didn't notice
mnasiadkainfra-root - is it possible to merge sooner then later? wanted to use that predefined nodeset in a project (instead of defining a local one there)07:20
mnasiadkaoops, 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 it07:22
*** jpena|off is now known as jpena07:40
*** ysandeep|brb is now known as ysandeep07:59
opendevreviewMark Goddard proposed openstack/diskimage-builder master: Fix LVM build when VG exists on build host
opendevreviewRafal Lewandowski proposed openstack/diskimage-builder master: enabled lvm for jammy ubuntu release
*** ysandeep is now known as ysandeep|lunch09:47
*** ysandeep|lunch is now known as ysandeep10:27
opendevreviewMarek Chmiel proposed openstack/diskimage-builder master: Pass ssh-agent socket to chroot env
*** rlandy_ is now known as rlandy10:37
*** soniya29|ruck is now known as soniya29|ruck|afk11:23
*** dviroel|out is now known as dviroel|rover11:23
fungiianw_: mnasiadka: so reviewing topic:fedora-36 i guess?11:43
*** vsevolod_ is now known as vsevolod11:43
mnasiadkafungi: 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
fungiwell, the patch you mentioned has that review topic applied to it, presumably because it depends on some others that are specific to adding f3611:46
fungithere's a whole bunch of direct and indirect dependencies which are blocking it11:46
fungii suppose it's possible ianw_ didn't mean to make that change depend on all the f36 ones11:47
fungiysandeep: this is what caused the failure you linked:
fungilooks like there's a patchback/backports/stable-4/8027bc53359e8006b94802468f7b60d89c73b61b/pr-5182 branch in pointed to commit fcb11f90e1846ee246491e89f70a03a76a83aef0 but that commit isn't accessible by zuul11:57
ysandeepsoniya29|ruck|afk, dviroel|rover, ^^11:59
fungithough i don't see that branch if i clone the repo from github11:59
fungii wonder if the problem is cached from an earlier depends-on12:00
ysandeepfungi, 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
fungiwell, 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 happened12:04
*** soniya29|ruck|afk is now known as soniya29|ruck12:05
fungidefinitely happened on multiple executors12:07
dviroel|roverysandeep: fungi: we will keep an eye to see if happens again12:08
fungii see 32 entries in the current executor debug logs matching 'ValueError: SHA .* could not be resolved, git returned:'12:10
fungionly 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-518312:15
fungiso two adjacent pull requests12:15
fungidviroel|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-lived12:17
soniya29|ruckfungi, ack12:18
*** tosky_ is now known as tosky12:25
fungidefinitely 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 zuul12:28
*** ysandeep is now known as ysandeep|brb12:47
*** dasm|off is now known as dasm13:31
Clark[m]fungi: the problem is on the GitHub side. They delete the ref and shas when the PRs merge13:49
Clark[m]The PR effectively becomes a dead end and zuul can't resolve the depends on anymore13:49
fungiClark[m]: just curious why the executors cared when the changes didn't depend on those13:50
fungior maybe they did and i missed it13: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 shas13: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 deleted13:52
Clark[m] I think we don't set that currently because it is a tenant setting and required all GitHub repos to use protected branches13:54
Clark[m]Essentially for our third party CI case it isn't a safe choice13:55
fungiyeah, the example failed build was for which had no dependencies (direct nor indirect) and ran in check, so no dependent pipeline introduced parents either13:56
fungiso we can definitely see this outside of dependency fetching13: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 heads13:57
Clark[m]But by the time zuul tries to fetch it has already been deleted13: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
fungioh, 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 requests14:02
fungiand i guess zuul has no way to know which branches your job will actually need, it just provides them all14: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 fine14:03
Clark[m]*Normal PR workflow14:04
fungiagreed, making pull requests from a repository to itself seems strange. i'd never noticed projects doing that before14: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 basis14:06
Clark[m] 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 options14: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 filter14: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
fungioh, yeah i think i reviewed the new exclude branches implementation recently, pretty sure it accepts regular expressions so we could exclude pr branches that way14:15
fungilike exclude patchback/backports/.*/pr-.*14:16
fungior whatever makes sense14:17
*** ysandeep|brb is now known as ysandeep14:28
*** Guest1034 is now known as clarkb14:32
opendevreviewClark Boylan proposed opendev/system-config master: DNM intentional failure to hold a node
clarkbI'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 upgrade14:44
*** dviroel is now known as dviroel|rover15:02
*** tosky is now known as Guest112915:12
*** tosky_ is now known as tosky15:12
clarkbhttps:// appears to be happy. And when I override in /etc/hosts locally to point at (the held load balancer) the warning banner goes away because the url accessing the site matches our config15:43
clarkbfungi: ^ 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
fungiupgrading this week(end) is probably fine, i'll take a look at the held node after the openstack tc meeting ends15:45
*** dviroel|rover is now known as dviroel|rover|lunch15:45
clarkbya I mean I'm around today and tomorrow if we want to do it today. I guess we can ask the release team too15:47
clarkbBut let's start with a sanity check of the held node(s)15:47
*** pojadhav is now known as pojadhav|out15:49
*** ysandeep is now known as ysandeep|out15:58
fungion the mm3 front, i've got the the contents of lists.o.o:/srv/mailman/opendev copied to for production config+archive migration trials16:01
fungii was originally going to copy all of /srv/mailman but that's huge apparently16:01
fungithe 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
opendevreviewAndy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
clarkbinfra-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. This apparently broke replication for them. I beleive this doesn't affect us because we're checking a different host key type? Replication16:07
clarkbdoes 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 later16:07
clarkbseparately 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 clients16:08
clarkbMore info here:
fungii refreshed my earlier reading on mm2->3 migration and pretty much all the current recommendations converge on
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
fungiso 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
fungithe tricky bit is when to stop mm2 services for a site and repoint dns records16:32
fungiand whether we want to put any temporary forwarding in place16:32
fungiwe 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 server16:34
opendevreviewAndy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
fungithat means a longer delay for resumption of deliveries, but probably not substantially longer, and far less effort16:35
clarkbfungi: pipermail is the old mm2 archives right?16:38
clarkbis it not possible to point them to the new mm3 archive hosting?16:38
clarkbit seems a little silly to carry two archives of the same content?16:38
clarkbIs 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 working16:40
*** jpena is now known as jpena|off16:41
fungiclarkb: yes, pipermail is what's typically used for archive publication in conjunction with mm2, vs hyperkitty with mm316:42
fungiand 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.txt16:44
fungialso 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 way16:45
fungiso we might actually want to let search engines continue indexing those specifically16:46
fungiat any rate, it's not much additional work. we already have to copy the old archives to the server anyway16:47
opendevreviewAndy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
opendevreviewAndy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
opendevreviewAndy Ladjadj proposed opendev/git-review master: style(cmd): use black to format script
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
*** dviroel|rover|lunch is now known as dviroel|rover17:10
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
opendevreviewAndy Ladjadj proposed opendev/git-review master: feat(cmd): add hashtag implementation
fungiclarkb: is this possibly the same bug wikimedia observed?
fungiexceptionCaught(ServerSessionImpl[null@/])[state=Opened] SshException: Unable to negotiate key exchange for server host key algorithms (client: / server: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa)17:37
fungiit hadn't dawned on me to try 3.4.4 instead of 3.4.5 but i'll give that a shot17:38
opendevreviewJeremy Stanley proposed opendev/git-review master: Upgrade testing to Gerrit 3.4.4
clarkbfungi: I don't know that is the same issue based on the lack of a mutual algorithm17:41
fungiwell, easy to test the theory anyway17:42
clarkbfungi: 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 along17:42
fungiyeah, looking closer, seems unlikely17:42
clarkbfungi: have you had a chance to look at via the held node yet? I'm feeling a lot more confiddent in it now that I've looked at the held node17:43
fungioh, right, not yet. pulling that up now17:43
fungiclarkb: 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
fungimight not be new, i just haven't noticed it before17:45
fungilooks like it's attempting to classify repositories by what programming language they use17:46
clarkbyes it is classifying the code content in the repo. It isn't new17:46
clarkbif you open the repo and click the multicolored bar under the commit count you get a breakdown17:46
clarkb35.5% jinja 31.4% python and so on17:47
fungioh, i had always thought that color bar was decorative!17:47
clarkbbtw I've noticed with current gitea that the text search of our repos may be good again17:48
clarkbI haven't felt confident enough in suggesting we delete codesearch yet17:48
clarkbbut I've been using it off and on and been happy with the results17:48
fungineat, yeah i hadn't tried it recently17:49
fungithey made improvements/fixes to the indexing, i guess?17:49
clarkbya I'm not sure what specific improvements were made but it seems far more useful now17:49
clarkbI think codesearch has richer search queries and I'm not sure if gitea does multiple branch searches17:51
clarkbyou 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
fungii wonder if we can/should do something about the file edit and delete buttons in gitea17:52
fungithe edit one talks about forking the repository to propose changes17:52
funginot urgent though, that's been there for a long time i think17:53
clarkbI 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 out17:53
clarkbI'm not sure I ever noticed that before. But I agree we should probably look into not showing them17:54
fungimore that it implies a different workflow/tooling than what we use17:54
funginot that i think it poses any risk other than being misleading17:54
fungiclarkb: any idea what the "vendored" means next to the filename at ?17:56
clarkbI do not17:57
clarkbif I had to make a wild guess it is some sort of golang thing to show files for vendored libraries withing a golang project17:58
clarkband whatever heuristic they use for that is tripping on that file17:58
fungialso seems to already be there in 1.16.9 so it's nothing new17:59
clarkbif you click view file the annotation goes away though17:59
clarkbmaybe something specific in the context of a git commit17:59
clarkbfungi: the git diff code in gitea appears to trigger off of these linguist-vendored tags18:01
clarkband then if you aren't explicit about it via git attributes there is an analyze.IsVendor() call against the diff18:03
clarkbI suspect in our case it is the analyze.IsVendor() call that we are tripping18:03
fungiat any rate, it's a cosmetic thing, seems like18:04
clarkbyes I think so18:04
fungibrowsing the things i expect to be able to browse works for me, as does cloning/fetching, so i'm good with upgrading whenever18:04
fungiall the stuff we normally disable still seems to be hidden from the yu18:05
clarkb if you match these regexes then you are vendored18:06
clarkbbut 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 I think that specific line is why we are marked vendored on that file18:08
fungione thing i notice on our current version is that eff privacy badger says it's blocking a cookie for api.github.com18:08
clarkbgit grep on the gitea repo seems to show they fetch license info and gitignore info (for new repos I think) from api.github.com18:09
fungithat's interesting, and mildly concerning18:10
clarkbfungi: I don't see a github cookie in my browser though18:11
clarkband ublock origin claims it isn't blocking anything18:11
fungimine might be held over from an earlier session somehow. i'll try clearing it18:11
clarkbI have 3 cookies all for opendev.org18:11
fungialso the gravatar integration is causing clients to disclose their browsing to a third party18:12
clarkbwe can disable gravatar
clarkbwe should probably do that as a separate change though (either before or after the upgrade)18:13
fungiyeah, after telling privacy badger to block the cookie it claimed it was providing and then clearing the settings, it's saying it sees nothing, so must have been old cruft18:14
fungiand yes, similar concerns about gravitar are what caused us to hold off doing
fungiwhy 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
fungiyep, 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:; provided that they (i) do not copy, store..."18:17
clarkbya I have no objections to disabling the feature. Just don't want to tie it to the ugprade itself18:18
fungiwhich makes me even more leery about supporting that18:18
clarkbso either we focus on that first or followup with it18:18
fungifollow up, for sure. let's upgrade asap18:18
fungii 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 while18:19
clarkbok 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
clarkbI'm around all day today and will keep an eye on ti18:19
fungii'm done and approving, yep18:20
clarkbcool and thank you18:20
fungithanks for doing all the legwork18:20
clarkbfungi: 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
fungiwe 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 place18:25
fungii'm really only concerned with preserving access to things which were publicly accessible to start with18:26
opendevreviewTristan Cacqueray proposed openstack/diskimage-builder master: Allow flake8 version 5
fungion 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 least18:40
fungilooking closer, i think the actual error is coming from the rest api when trying to add a client ssh key18:41
fungiclarkb: huh...
*** kopecmartin is now known as kopecmartin|pto18:57
clarkbfungi: ya I think that is an alternative to gravatar?19:00
clarkbhrm though it seems tied to the gravatar setting so maybe not19:01
fungiyeah, 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/caching19:01
fungifor 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 though19:09
fungianyway, 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 want19:11
fungiclarkb: 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 place19:22
clarkbfungi: no, everything has been in the change so far19:23
clarkbI think you may have had an etherpad from earlier investigations though19:23
opendevreviewMerged opendev/system-config master: Update to Gitea 1.17
fungiahh, yeah i had an old mm3poc pad, for some reason i thought we had some other notes somewhere19:25
fungiwas going to start drafting up a migration plan/process with the commands i'm running just so this is repeatable19:25
fungii'll work on it in
clarkbsounds good,thanks19:28
clarkbtwo more hourly jobs then 847204 will start deploying19:28
clarkbthe first 4 giteas have updated19:55
clarkbI can web browse and git clone19:56
clarkball 8 appear done now. Just waitingfor the job to complete20:06
clarkbthe job completed successfully according to zuul. I'm yet to see any problems myself20:11
fungiyep, just got back from picking up some lazy takeout, but they lgtm too20:18
*** ianw_ is now known as ianw20:37
ianwfungi: sorry, yeah that rocky node addition can be rebased on master if we like20:38
ianwi'll just merge both, i was mostly worried about a typo or something20:39
ianwclarkb: 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 good20:43
clarkbianw: 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 all20:45
opendevreviewClark Boylan proposed opendev/system-config master: Disable Gravatar in Gitea
clarkbfungi: ^ we should check screenshots and see how that affects local avatar storage (for the various projects which we manage directly)20:54
fricklerincidentally I noticed the "vendored" thing earlier today for which marks almost everything, which doesn't make any sense at all to me21:17
fungiyeah, the pattern matches for that seem a bit too broad21:18
fungimaybe they should also be limited by file extension or something21:19
clarkbI think is the rule hitting frickler's example21:20
clarkbLooking 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 optional21:20
fricklerseems to be because of `(^|/)cache/` vs. "oslo_cache", but ignores the ^21:21
fungiit may be tokenizing and treating _ as a token separator21:22
fungiso parses /oslo and then parses cache/21:22
fungithough probably not, since there are literal _ elsewhere in the expressions which aren't escaped or anything21:23
fricklerwhich would seem pretty useless to me. anyway, EOD here21:23
fungiyeah, no clue21:23
clarkbit seems to be using golang's normal regexp library21:23
clarkbIt says it does a left most match. I wonder if ^ is effectively useless in that case21:24
clarkb says that isn't the case though21:25
clarkbactually I think might be buggy21:26
clarkb* may be buggy21:27
fungioh yikes21:28
fungithat looks like a recipe for disaster21:28
fungiin 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 theory21:31
clarkbI think what they are trying to accomplish is functionally the same as checking each regex separately and returning true if one matches21:33
clarkbsince you can have a finite automata that basically implements the if elif elif etc21:33
fungiit might be safe as long as they don't do any lookaround (positive or negative lookahead/lookbehind)?21:33
clarkbya if you do something more powerful than a finite automata then it might get weird21:36
clarkbok that library (enry) wraps around the definitions in
*** rlandy is now known as rlandy|bbl21:38
clarkbI'm installing go now21:40
fungimy condolences21:41
clarkbok I have small reproducer now21:51
fungigo go gadget regex21:53
*** tosky_ is now known as tosky22:06
*** dasm is now known as dasm|off22:32
mnaser__is gerrit stuck by any chance?22:34
mnaser__`ssh -p29418` is not responsive from my local system22:34
mnaser__but i can open the web ui22:34
mnaser__ah i think that might be my side since it works on another remote vm, weird22:34
mnaser__my ssh-agent seems dead22:34
fungithat'd do it22:35
mnaser__my yubikey seems to just do nothing when im trying to add it to my ssh-agent. fun22:35
clarkbI 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 me22:36
mnaser__well, plugging it out and back in did the trick22:37
fungiyubikey equivalent of "have you tried turning it off and on again?"22:38
*** rlandy|bbl is now known as rlandy22:47
clarkbfungi: thats the end result regexp expression according to the debugger22:48
clarkbI'm working on formatting it so it is easier to understand22:50
clarkband now I think I see the bug23:04
clarkbThe issue has details. I'm working on a PR now23:15
clarkbfungi: frickler: if that lands and gitea updates the go-enry version this issue will go away23:28
opendevreviewTim Burke proposed openstack/project-config master: test-release-openstack: Collect tested artifacts

Generated by 2.17.3 by Marius Gedminas - find it at!