Thursday, 2020-08-27

openstackgerritMerged zuul/zuul master: model.py : remove unused inheritable_attributes dictionary  https://review.opendev.org/74760000:05
*** _erlon_ has quit IRC00:25
*** frenzyfriday has joined #zuul00:29
*** frenzyfriday has quit IRC00:38
*** mgoddard has quit IRC00:41
*** mgoddard has joined #zuul00:47
*** sgw has quit IRC01:14
*** rlandy has quit IRC01:15
*** mgoddard has quit IRC01:17
*** reiterative has quit IRC01:22
*** reiterative has joined #zuul01:24
*** mgoddard has joined #zuul01:24
*** sgw has joined #zuul01:33
*** frenzyfriday has joined #zuul02:14
*** frenzyfriday has quit IRC02:18
*** bhavikdbavishi has joined #zuul02:59
*** frenzyfriday has joined #zuul03:08
*** frenzyfriday has quit IRC03:17
*** bhavikdbavishi has quit IRC03:18
*** bhavikdbavishi has joined #zuul03:42
*** evrardjp has quit IRC04:33
*** evrardjp has joined #zuul04:33
*** saneax has joined #zuul04:46
*** bhagyashris|away is now known as bhagyashris05:02
*** vishalmanchanda has joined #zuul05:10
*** kmalloc has quit IRC05:40
*** reiterative has quit IRC05:43
*** reiterative has joined #zuul05:43
*** frenzyfriday has joined #zuul05:47
*** mach1na has joined #zuul05:48
*** bhavikdbavishi1 has joined #zuul05:55
*** bhavikdbavishi has quit IRC05:56
*** bhavikdbavishi1 is now known as bhavikdbavishi05:56
*** mach1na has quit IRC06:38
*** bhavikdbavishi has quit IRC06:45
*** frenzyfriday has quit IRC06:48
*** frenzyfriday has joined #zuul06:49
*** frenzyfriday has quit IRC06:54
openstackgerritJan Kubovy proposed zuul/zuul master: Annotate logger with event ID when (un)locking node set  https://review.opendev.org/74836506:55
*** LLIU82 has joined #zuul06:55
openstackgerritJan Kubovy proposed zuul/zuul master: Annotate logger with event ID when (un)locking node set  https://review.opendev.org/74812206:58
openstackgerritJan Kubovy proposed zuul/zuul master: Scheduler's pause/resume functionality  https://review.opendev.org/70973507:02
openstackgerritJan Kubovy proposed zuul/zuul master: Separate connection registries in tests  https://review.opendev.org/71295807:02
openstackgerritJan Kubovy proposed zuul/zuul master: Prepare Zookeeper for scale-out scheduler  https://review.opendev.org/71726907:02
openstackgerritJan Kubovy proposed zuul/zuul master: Mandatory Zookeeper connection for ZuulWeb in tests  https://review.opendev.org/72125407:02
openstackgerritJan Kubovy proposed zuul/zuul master: Driver event ingestion  https://review.opendev.org/71729907:02
openstackgerritJan Kubovy proposed zuul/zuul master: Connect merger to Zookeeper  https://review.opendev.org/71622107:02
openstackgerritJan Kubovy proposed zuul/zuul master: Connect fingergw to Zookeeper  https://review.opendev.org/71687507:02
openstackgerritJan Kubovy proposed zuul/zuul master: Connect executor to Zookeeper  https://review.opendev.org/71626207:02
openstackgerritJan Kubovy proposed zuul/zuul master: WIP: Switch to using zookeeper instead of gearman for jobs (keep gearman for mergers)  https://review.opendev.org/74441607:02
*** mach1na has joined #zuul07:04
*** mach1na has quit IRC07:17
*** bhavikdbavishi has joined #zuul07:24
*** yoctozepto has quit IRC07:34
*** tosky has joined #zuul07:47
*** mach1na has joined #zuul07:49
*** nils has joined #zuul08:06
openstackgerritMerged zuul/zuul-jobs master: bindep: Fixed runtime warnings  https://review.opendev.org/74778108:24
openstackgerritJan Kubovy proposed zuul/zuul master: Scheduler's pause/resume functionality  https://review.opendev.org/70973508:28
*** yoctozepto has joined #zuul08:55
LLIU82I met a problem of when I try to run a child job of tox-doc. I have set the proxy information as environment variable for the ansible user. But the error shows the connection problem to pypi.org09:08
LLIU822020-08-27 08:54:31.886616 | TASK [bindep : Install bindep into temporary venv]09:09
LLIU82redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f783632b790>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/bindep/\n  WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken09:09
LLIU82by 'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f783632b9a0>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/bindep/\n  WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by09:09
LLIU82'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f783632b730>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/bindep/\n  WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by09:09
LLIU82'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f783632b400>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/bindep/\n  WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by09:09
LLIU82'ConnectTimeoutError(<pip._vendor.urllib3.connection.VerifiedHTTPSConnection object at 0x7f783632b490>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/bindep/\n  ERROR: Could not find a version that satisfies the requirement bindep (from versions: none)\nERROR: No matching distribution found for bindep\n"09:09
LLIU8209:01:07.989124 | zuul-doc-server | }09:09
*** LLIU82 has quit IRC09:19
*** LLIU82 has joined #zuul09:22
*** hashar has joined #zuul09:45
*** holser has quit IRC09:45
*** bhavikdbavishi has quit IRC09:58
*** holser has joined #zuul09:59
*** tkc17 has joined #zuul10:01
tkc17Hi Guys, when using 3.19.1.dev155, we are seeing an issue with integrated gate queue, unrelated jobs are made dependent i.e., even though one job is completed the results are not posted till an other unrelated job is done (can see a black line indicating they are dependant but they are not), this is seen with the latest move to DEV but my colleague says he has seen this earlier as well but not sure. Any ideas?10:07
*** bhavikdbavishi has joined #zuul10:14
*** sshnaidm|afk is now known as sshnaidm10:30
*** bhavikdbavishi has quit IRC10:44
*** hashar is now known as hasharLunch10:48
*** mach1na has quit IRC11:10
avassIs there a reason for why the mergers don't do a sparse checkout with only the relevant zuul directories? compatibility with older git versions?11:11
openstackgerritBenjamin Schanzel proposed zuul/nodepool master: k8s Driver: Fix Node Launch For Secrets Without API Credentials  https://review.opendev.org/74841411:19
avassoh, it's still experimental. that's probably why :)11:24
*** Goneri has joined #zuul11:34
*** mach1na has joined #zuul11:47
*** rlandy has joined #zuul11:57
*** mach1na has quit IRC12:00
*** mach1na has joined #zuul12:00
*** hasharLunch is now known as hashar12:01
*** bhavikdbavishi has joined #zuul12:26
*** bhavikdbavishi has quit IRC13:08
*** bhavikdbavishi has joined #zuul13:14
*** bhavikdbavishi has quit IRC13:36
*** rlandy is now known as rlandy|mtg14:00
fungitkc17: i'm having trouble following your problem description... i wonder if maybe you mean changes when you say jobs? dependent queues are all about testing changes in a series, so if a change has another ahead of it, the later change's build results can't be reported until zuul is sure the change ahead of it worked, since they were tested together (if the change ahead of it fails, all jobs for the second14:05
fungichange have to be rerun to get new build results without the first change included)14:05
tkc17Sorry, let me elaborte. There are 2 different jobs submitted from 2 repos with no depends-on for gate pipeline, but still Zuul marked them as dependent.14:07
fungitkc17: are you maybe saying that zuul  is putting unrelated changes into the same queue and you're not sure why? if so, it probably means it's worth reviewing the section of the zuul docs on how it determines what changes share a queue to make sure none of those are the cause14:07
* fungi finds that part of the docs14:07
tkc17Yes, we are using a "integrated" queue for all gating jobs.14:08
fungithe beginning of https://zuul-ci.org/docs/zuul/reference/project_def.html talks about that14:09
fungiif you tell all your projects to share a named queue called "integrated" then all their changes will be serialized in that queue in dependent pipelines14:09
tkc17yes, but normally I see the changes are independent of each other (serial/parallel) and once jobs for a change are done the changes gets merged/rejected.14:11
tkc17Even the above docs say that serialization checks dependencies, and also specifically it mentions "Zuul could simply assume that all projects are related, or even infer relationships by which projects a job indicates it uses, however, in a large system that would become unwieldy very quickly, and *unnecessarily delay changes to unrelated projects*"14:13
tkc17that last section is the issue I am seeing.14:13
fungiyes, it sounds like you created that by putting all your projects in a single queue14:14
tkc17okay, I need to group things properly with different queues?14:15
tkc17(using different queue names)14:15
fungito be able to mix and match those conditions, zuul would need to be able to merge different queues on the fly, and i'm not entirely clear how you would work out what order to put in-flight changes in when that happened. consider you have several changes approved for project-a and they're being tested in the project-a queue, separately you have several changes approved for project-b and they're being tested in14:16
fungithe project-b queue. now you aprove a new change for project-b which depends-on an already approved and queued change for project-a... how does zuul decide which queue to put it in? if the queues aren't shared then the current behavior is to not enqueue the project-b change into the project-b queue until the change it depends-on in project-a has merged14:16
fungiyou've effectively told zuul to share a single queue for project-a and project-b, which means that when changes for either are approved, they're sequenced together with one another14:17
fungiand so can only be reported in sequence14:17
tkc17okay, but changeB jobs which run faster wait on changeA jobs which take longer14:18
tkc17as ChangeA was submitted first to the queue14:18
fungi(each change has to report or be separated from the queue sequence due to a failing build before the change after it can be reported)14:18
tkc17even though changeA and changeB are in no way related, just that they share the same queue14:19
fungitkc17: correct, because if you tell zuul to use a shared queue for both projects, it assumes that an error introduced in a change in one project could imply altered behavior for the builds for the other project14:19
tkc17I understand, thanks.14:20
fungisay, a repository for an application and a repository for a tightly-coupled library, you might have a change adding a new method in the library and a related change in the application which uses that new method... so zuul wants to make sure that the change to the application still gets exercised based on the state of the change for the library if the library change was approved before the application change14:21
fungithose are cases where you would likely know ahead of time that you wanted an explicit depends-on, so maybe a better example is that there's a change for the library to remove an unused method, and a separate change in the application to start using that method. if those were tested and merged independently in parallel in separate queues you could effectively wedge both projects14:24
tkc17Got it, but normally we mark that dependency explicitly eg: In Gerrit using Depends-on14:24
tkc17yes, second case is a better example as there could be a clash and both developers aren't aware so no explicit depends-on.14:26
tkc17But in my case it wasn't the case, so, need to divide the repos into some more groups.14:27
clarkbLLIU82: depending on how you set the env var for the proxy certain ansible tasks may not load it14:42
clarkbcommand vs shell in particular14:42
fungitkc17: my rule of thumb for when to avoid vs when to apply shared queues is that if projects consume each other from release versions (or not at all) then they're safe to have their changes queued independently. if they consume each other continuously from source (e.g. a git branch) then they likely are better off in a shared queue14:43
tkc17okay, inline with my understanding. Thanks.14:52
*** rlandy|mtg is now known as rlandy15:09
zbrcorvus: clarkb: does https://review.opendev.org/#/c/740733/ look fine? cmd rendering inside pre, like the other interesting keys15:12
zbrsometimes cmd can be long and/or multiline, we should render it nicely15:12
zbrcurrent implementation breaks it so multiline ones cannot be copied, and much harder to read15:13
fungicatching up on yesterday's accessibility discussions, i'm not blind so my case is likely trivial compared with someone who is. while i don't use mice specifically, i do have systems with pointer devices (trackballs, trackpoints, trackpads, drafting/drawing tablets, touchscreens...) and will use them when it's the more efficient solution, say for graphic arts tasks. and if i really want to use the keyboard as a15:26
fungipointer i also have the keynav driver installed (it's awesome, check it out sometime). though for browser navigation of hyperlinks and form fields i have an extension that enumerates all the links with short letter/number codes when i hit the right key, and then i can type one or a few keys to follow the link i'm interested in, so i haven't really missed tab working. spacebar and pgup/pgdn/home/end/arrows are15:26
fungimore what i use for page scrolling15:26
fungii will note that javascript onclick and hover events are something i wind up needing a pointer (like keynav's) to activate15:28
*** mach1na has quit IRC15:28
*** mach1na has joined #zuul15:28
zbra11y is quite complex to test, to do a good job we would need someone (qa-ish) with experience in that field, something hard to find.15:29
clarkbfungi: ya https://review.opendev.org/#/c/742759/ seems to be the best compromise for now15:29
clarkbI think corvus was hoping felixedel might be able to weigh in today before we land that though15:30
*** mach1na has quit IRC15:33
*** tkc17 has left #zuul15:34
corvusfelixedel: ^ are you around to review that?15:39
corvuszbr: i agree that there's a lot to good a11y testing.  but the minimum that we can do to avoid making things harder for folks with impairments is to try to avoid breaking standard behaviors and conventions.  this is why changing tab navigation configurations (that turned out to be fine) and forcing-focus (that turned out to be hard to navigate) are things that raised a red flag with me that we should15:42
corvusinvestigate further.15:42
*** spotz has joined #zuul15:42
corvuszbr: at least, if we're going to do something weird like that, that's probably something we should get confirmation isn't going to cause a11y problems, and i don't think we got that, so i'd prefer not to do it15:43
spotzHey all, it was pointed out that https://zuul-ci.org/docs/zuul/tutorials/user.html is empty but I did confirm there are tutorial files in git. I'd put up a patch but not seeing how you'd call those pages15:43
zbri did observe our lack of attention while doing my other changes, use of "title" seems to quire rare in our code.15:43
zbrand i know well that this is made mandatory for a11y reasons for most html elements15:44
corvuszbr: indeed, i think there's actually some low-hanging a11y problems we can fix on our own15:44
zbrI could easily rephrase https://review.opendev.org/#/c/740733 to say that it addresses a11y issues, and it would not false15:45
corvusspotz: i think that page was created by a user who was hoping for a field-of-dreams scenario which has not yet come to pass, though guillaumec has been working on some15:45
corvusspotz: i think the only existing tutorial is an 'admin' tutorial15:46
corvusspotz: guillaumec work starts at https://review.opendev.org/73206615:46
fungispotz: as for where to edit, https://opendev.org/zuul/zuul/src/branch/master/doc/source/tutorials/user.rst is the file it's built from15:46
spotzcorvus the quick-start looks pretty decent but I haven't run through it15:47
corvusspotz: it's relatively admin-focused15:47
clarkbI'm looking at setting file modes to avoid future problems for zuul roles/playbooks if/when ansible does the file perms change again. At the same time I'm thinking setting owner and group is a good idea. The docs don't say but I assume the defaults for those are the current user and their primary group?15:47
spotzfungi so users.rst is like index.rst in like OpenStack docs?15:47
fungispotz: no, it's just a documentation file15:47
spotzfungi: ok15:48
fungihttps://opendev.org/zuul/zuul/src/branch/master/doc/source/tutorials is lacking a index.rst, so there winds up being no fancy index at https://opendev.org/zuul/zuul/src/branch/master/doc/source/tutorials/ (and apache's mod_autoindex is kicking in to fill in the void)15:49
spotzfungi corvus - If you want me to throw up something let me know, but I'll pass it back that it's WIP15:50
corvusspotz: i honestly don't know what to do there.  maybe a quick pgraph that says "WIP" and points to https://zuul-ci.org/docs/zuul/tutorials/admin.html ?15:51
corvussince that's the only extant tutorial at the moment15:51
spotzcorvus: Ok I'll throw up a patch you can change/reject/etc. I won't be offended with a -2 what were you thinking:)15:52
corvusspotz: thanks!15:52
clarkbcorvus: the oldest ansible zuul supports is 2.6?15:53
spotzcorvus: Ok I think I've realized the perception here, the user Tutorials page is blank but the navigation updates to what is available and if you don't notice that it seems blank15:54
spotzblank=broke15:54
corvusthis page intentionally left broke15:55
*** dustinc has quit IRC16:07
*** LLIU82 has quit IRC16:14
*** nils has quit IRC16:15
zbrcorvus: i got a similar intentional blank page on another project which i had to remove after one year, seeing the guy that was supposed to write the docs moved to another project.16:17
zbrwhat can be seen temporary today, may become more of a permanent thing, regardless if we like it or not16:17
corvusyep16:19
corvusso it'll be nice to put something there until we finish up reviewing guillaumec's changes16:20
clarkbzbr: is it an ansible-lint bug that it complains about missing mode on symlinks?16:22
zbrclarkb: lol, there are ~3-4 and one unreleased fix. E208 made my last two weeks, hard to forget16:22
clarkbzbr: ok so thats a known issue and I can ignore it for now?16:23
zbri will release the last fix today, waiting for two more merges.16:23
zbrwait for me to ping you when release is done, these fixes removed some false positives on the rule16:23
zbrbasically the lack of mode is a very real issue, but original rule was not very smart, had some false-positives16:24
*** sshnaidm is now known as sshnaidm|afk16:24
zbrtake a look at https://github.com/ansible/ansible-lint/pulls?q=E208+16:24
clarkbyes I know there are false positives it wants me to set a mode on a symlink :)16:25
clarkband requiring mode on unarchive is really clunky16:25
clarkbI don't know how you can do that sanely16:25
zbrwait ~1hour, and you will get better results, also there is a new alternative to skip_list, a warn_list16:25
zbrwhich makes is return success, but still print the rules inside it16:26
zbryou could put a "noqa: E208" to silence it in that particular place. looking to fix in the future.16:27
clarkbya I don't expect these changes to merge in the immediate future so will just assume that bug fixes will address it16:27
openstackgerritClark Boylan proposed zuul/zuul-jobs master: WIP: Address ansible-lint E208  https://review.opendev.org/74848016:29
clarkbthats sort of a halfway step16:29
zbrclarkb: i can help you to finish it16:32
*** tosky has quit IRC16:45
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: Partial address ansible-lint E208  https://review.opendev.org/74848017:21
*** mach1na has joined #zuul17:29
*** mach1na has quit IRC17:34
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: More E208 mode fixes  https://review.opendev.org/74849817:41
clarkbzbr: https://zuul.opendev.org/t/zuul/build/457c2d0ac3fb459ab4002e4c794865cd/log/job-output.txt#254 is a fun one. The ansible docs say mode: "preserve" is valid from ansible 2.6 and that job ran with 2.9 but failed17:50
clarkbI guess the docs are wrong17:50
clarkbcorvus: I wonder if https://review.opendev.org/#/c/747661/ is somehow tripping https://zuul.opendev.org/t/zuul/build/31820ad35e8e4e59aed9eba43d3ee94b/log/job-output.txt#17436-17449 (iirc maplines is used to process the zuul_return info)17:54
corvuswaiting for my browser to parse that17:55
corvushrm17:55
corvusthe anchor link did not scroll to the line17:55
clarkbif you grep 'Error mapping line:' that should take you to it too17:56
corvusi guess add that to the list of stuff messed up by pf4?17:56
clarkbcorvus: I just opened in a new browser and confirm it doesn't jump to the line17:57
corvusthx, sounds like it17:57
corvusclarkb: do you think that caused the test failure in 741157, or do you think it's a non-fatal error unrelated to the failure?18:00
corvusclarkb: because if it actually caused the failure, it should have failed 74766118:00
corvusbut if it's non-fatal, then it certainly could be a new thing18:01
corvusclarkb: unless it did fail 741157 but only due to a race?18:01
clarkbcorvus: well the final error is an ordering thing I think18:01
clarkband I'm wondering if the earlier error is affecting that final ordering18:02
corvuswhere's the final error?  it's unsurprisingly hard to navigate in a 20,000 line file only using the scrollback18:02
corvusscrollbar18:02
clarkbline 1759418:02
clarkbit is an assert looking for a line 21 otherfile.txt comment (the thing that errored on my first link) but is getting a line 21 path/to/file.py comment instead18:03
corvusgot it18:04
clarkboh18:04
clarkbok it sactually git failing because otherfile.txt has only one line in it18:04
clarkband then maybe we don't load that in the final comments content as a result18:05
clarkbthat has me thinking maybe the eralier change didn't break anything but exposed a problem in our test fixtures18:05
corvusfwiw this is much easier to deal with: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_318/741157/7/gate/tox-py35/31820ad/testr_results.html18:05
clarkbya we're just doing a single line of 'test2' in otherfile.txt I think18:07
clarkbbut that should've failed in the earlier change as you mentioned (that should be deterministic)18:07
corvusclarkb: i think the git error is a red herring18:07
corvusit's present in the old code18:08
corvuszuul captures it and includes it as a warning in the message reported back18:08
clarkbya it looks curious because the filenames line up but I agree old code would've hit it18:08
corvusso i think we can ignore the git error for file having 1 line, and the real issue is the new code or test is non-deterministic18:08
clarkbthe new code is much more reliant on ordering18:09
openstackgerritJames E. Blair proposed zuul/zuul master: Revert "Merge file comments from multiple tasks"  https://review.opendev.org/74850118:10
corvusclarkb: ^18:10
clarkbI wonder if we sort by linenumber18:12
clarkbboth of those have the same line number so sort is not stable? if that is the case we can fix the tests by making them stable or not having comments on the same line numbers across files in the tests18:13
clarkbah yup the sort is by line18:13
clarkbok I can actually fix this really quickly18:13
clarkbrather than revert18:13
clarkbtrying to test a fix locally now18:24
clarkbI need more memory18:24
fungii say that every time i forget where i left my car keys18:31
corvusclarkb: if you want to push it up i can run it through a few cycles18:32
*** holser has quit IRC18:33
clarkbsrc/re2.cpp:14806:13: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’? is what I'm hitting now s oya I'll just push it up18:34
*** holser has joined #zuul18:34
*** tosky has joined #zuul18:35
openstackgerritClark Boylan proposed zuul/zuul master: Sort comments in file_comments testing  https://review.opendev.org/74850818:35
clarkbcorvus: ^ I think we may need another level of sorting in the path/to/file.py line 42 comments18:35
clarkbI'm not sure if those are stable on their own18:36
clarkbhttps://github.com/axiak/pyre2/issues/55 is the upstream re2 issue. I think py38 must've changed its internal structs for thread state on a minor update?18:37
clarkbwe don't see it on ubuntu because its an older py38?18:37
clarkb(I'm on tumbleweed not OSX but I expect I get up to date python3.8)18:37
corvusAttributeError: 'dict' object has no attribute 'file'18:38
corvusclarkb:   File "/home/corvus/git/zuul/zuul/tests/unit/test_gerrit.py", line 251, in test_file_comments18:38
clarkbhrm maybe we have comments in the list that don't have files associated with them?18:39
clarkblike top level comment?18:40
fungii've got 3.8.5 here compiled from source if something needs confirming quickly18:40
clarkbfungi: try to pip install re218:41
clarkbthats the version I've got too18:41
corvusclarkb: here's the structure that's failing on: http://paste.openstack.org/show/797222/18:41
corvusshould be able to test that out in repl18:41
clarkbthanks18:41
fungiclarkb: mmm, i get compilation errors18:42
fungisrc/re2.cpp:1502:101: warning: ‘int PyObject_AsCharBuffer(PyObject*, const char**, Py_ssize_t*)’ is deprecated [-Wdeprecated-declarations]18:42
fungiahh, in the not warnings i have a bunch of "src/re2.cpp:14765:25: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘exc_value’; did you mean ‘curexc_value’?" and so on18:44
clarkbfungi: ya I think python3.newerthanbionicandfocal changed the internal api18:44
clarkband re2 breaks on it18:44
clarkbgood to confirm it isn't just me18:44
fungiokay, so that's the same as what you're seeing then18:44
fungiand yeah, this is literally just checkout the 3.8.5 tag in git and configure;make18:44
fungion a reasonably up to date debian/unstable system18:45
*** LLIU82 has joined #zuul18:45
fungi(i mean, i also turn on some build optimizations and whatnot, but it's still vanilla built toolchain)18:45
clarkbcorvus: I can reproduce the issue using attrgetter but not using lambda x: x['file'] also all of them have a file attribute. I must not fully understand attrgetter18:46
corvusclarkb: i don't understand it which is why i didn't just fix it :)18:47
corvusi love me some lambda though18:47
fungihttps://github.com/andreasvc/pyre2/issues/1018:47
clarkboh its because attrgetter is just class attributes derp18:47
clarkbso ya I'll update the lambda instead18:47
fungihuh, odd18:47
openstackgerritClark Boylan proposed zuul/zuul master: Sort comments in file_comments testing  https://review.opendev.org/74850818:48
clarkbfungi: https://github.com/axiak/pyre2/issues/55 too. which is the canonical repo?18:49
fungior maybe https://github.com/facebook/pyre2/issues/20 ?18:59
clarkbaha19:03
clarkbI think the extra PyThreadState bits are generated by cython19:03
clarkbcpython never has them, cython mixes them in19:03
clarkbfungi: aha19:10
clarkbfb-re2 is what we actually dep on and that is the facebook repo you point to and install fb-re2 doesn't explode (probably why we use it) but then fails for me on finding the libre2.so.719:11
clarkbI have libre2 intsalled so now I get to figure out why my .so isn't good19:12
clarkbbecause i have libre2.so.819:14
clarkbhow is it linking libre2.so.7 if that doesn't exist on my system19:14
clarkbmaybe a wheel cache?19:14
clarkbwow that was it, sorry for all the noise. I guess I should periodically flush my wheel cache19:17
clarkband with all that done I think I've just confirmed that latest patchset does pass (though not run enough iterations to know if there is still an ordering concern)19:21
fungiyeah, i clear ~/.cache/pip every time i recompile python19:21
fungiand rebuild all my venvs19:21
clarkbfungi: in this case it was libre2 updating not python19:22
clarkbwhich broke the linker paths19:22
clarkbI've not got that test running on a loop (its not super fast on my laptop) to see if we trip over any additional ordering issues19:24
*** vishalmanchanda has quit IRC19:25
clarkb4 successful runs so far19:33
clarkblooking good19:34
clarkbit did 7 without error before I stopped it due to eating my cpu19:44
openstackgerritSorin Sbarnea (zbr) proposed zuul/zuul-jobs master: More E208 mode fixes  https://review.opendev.org/74849819:47
*** LLIU82 has quit IRC20:16
openstackgerritClark Boylan proposed zuul/zuul master: Sort comments in file_comments testing  https://review.opendev.org/74850820:35
*** hashar has quit IRC21:23
*** saneax has quit IRC21:32
*** Goneri has quit IRC21:39
corvusclarkb: i'm going to single-core approve your test fix, abandon my revert, then approve ianw's scroll fix21:41
clarkbk21:41
*** holser has quit IRC22:33
openstackgerritMerged zuul/zuul master: Sort comments in file_comments testing  https://review.opendev.org/74850822:42
*** holser has joined #zuul22:56
*** saneax has joined #zuul23:02
*** sanjayu_ has joined #zuul23:10
*** saneax has quit IRC23:13
*** frenzyfriday has joined #zuul23:24
*** frenzyfriday has quit IRC23:28
clarkblooks like the css thing failed on a zuul-tox-remote fialure23:30
clarkbI've reapproved it23:30
clarkbthere was another change that hit the file comments issue that I have reapproed as well. will see if those continue to fail on zuul-tox-remote23:32
*** sanjayu_ has quit IRC23:54
*** tosky has quit IRC23:59
openstackgerritAmy Marrich (spotz) proposed zuul/zuul master: Add content to User Tutorials page  https://review.opendev.org/74855523:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!