opendevreview | James E. Blair proposed opendev/zuul-providers master: Add more flavors https://review.opendev.org/c/opendev/zuul-providers/+/940756 | 00:23 |
---|---|---|
corvus | clarkb: fungi ^ i'm aiming for two birds with one stone there | 00:23 |
clarkb | +2 from me. My only other thought is bullseye is showing its age now we may want to work on bookworm and/or noble nodes next to do testing on forward looking stuff | 00:28 |
corvus | oh heh yep. zuul runs tests on jammy(!) now.. not sure if they'll run on bullseye, but if not, then that probably increases the priority for either bookworm or noble | 00:32 |
corvus | oh 3.12 runs on noble | 00:32 |
corvus | so we'd need at least one of those to pull over the 3.12 job | 00:32 |
*** ralonsoh_ is now known as ralonsoh | 08:10 | |
*** ralonsoh_ is now known as ralonsoh | 10:31 | |
opendevreview | Merged opendev/zuul-providers master: Add more flavors https://review.opendev.org/c/opendev/zuul-providers/+/940756 | 13:16 |
*** ralonsoh_ is now known as ralonsoh | 15:15 | |
clarkb | fungi: I think several mirrors need updating from focal to noble which implies we need openafs packages for noble. Did the new openafs ppa package update get build for noble? I think we may have one noble mirror somewhere too (rax flex?) | 15:49 |
clarkb | it occurred to me ^ is somethign to consider in prep for a sprint replacement of servers next week | 15:50 |
fungi | clarkb: https://launchpad.net/~openstack-ci-core/+archive/ubuntu/openafs says we built it for noble on 2024-11-19 | 15:52 |
clarkb | cool I wonder if the version is new neough to be used. I'll try to follow up on that | 15:53 |
clarkb | the other thing I'm trying to sort out is keycloak since I want to update its db soon I realized I should login to be able to test it is happy after doing so. Then realized I believe we redeployed it and started over and I need to create a new account | 15:53 |
clarkb | unfortunately our docs don't seem to indicate how that is done. Any one remember? | 15:53 |
clarkb | https://docs.opendev.org/opendev/system-config/latest/keycloak.html maybe the broken ref in that document is what i need to find | 15:54 |
clarkb | yes that seems to have what I need. Let me fix the ref before I forget | 15:55 |
fungi | clarkb: this server is running on noble: https://mirror02.ca-ymq-1.vexxhost.opendev.org/ | 15:56 |
fungi | so seems to work fine | 15:56 |
opendevreview | Clark Boylan proposed opendev/system-config master: Fix zuul-admins doc ref https://review.opendev.org/c/opendev/system-config/+/940804 | 15:57 |
clarkb | and dpkg reports the version there should be from our ppa cool | 15:57 |
clarkb | thanks! | 15:57 |
fungi | i'll be heading out to an appointment in about 45 minutes, but don't expect to be gone more than an hour so should be back before 17:00 utc | 16:00 |
fungi | er, before 18:00 utc i mean | 16:00 |
clarkb | fungi: now that pbr has released should we work on a bindep release of at least the beginning portion of the pyproject.toml stack? | 16:08 |
fungi | yeah probably, hoping we'll get some people to weigh in with preferences on the individual changes in that series | 16:08 |
fungi | i'm happy to restack them in a different order and work out the rebase conflicts if there's some consensus that one or more of the later changes in the stack is desired but its parents are not | 16:13 |
clarkb | I think I'm happy with them as is. In particular I don't mind having a small tool do what pypa wants us to do even if it deviates from our own preferences. It seems like a good way to evaluate our ability to be more in line with pypa | 16:14 |
opendevreview | Merged opendev/system-config master: Fix zuul-admins doc ref https://review.opendev.org/c/opendev/system-config/+/940804 | 16:21 |
clarkb | the docs worked great by the way. So once ^ is deployed should be easier to find | 16:30 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Stop overriding SetupTools module scanning https://review.opendev.org/c/opendev/bindep/+/940812 | 16:36 |
fungi | slight alteration to the schedule, i've been told i'm going out for lunch after the appointment, so will more likely return closer to 19:00 utc | 16:39 |
clarkb | ack | 16:40 |
clarkb | now that I have a working keycloak account I'd like to land https://review.opendev.org/c/opendev/system-config/+/940348 to update the db location for keycloak. I do note that the mariadb image updated recently and we mirrored it (oddly the image age is 3 months according to docker image list but keycloak's image id matches the image id for etherpad and keyclock gets it from docker | 16:43 |
clarkb | hub and etherpad from our quay mirror so everything is matching) | 16:43 |
clarkb | is anyone willing to review that change? It doesn't have any reviews yet | 16:43 |
clarkb | and you may want to check the image update situatuion I noted above | 16:43 |
fungi | yeah, that's sorta odd | 16:44 |
fungi | anyway, lgtm, +2 | 16:44 |
fungi | i'm headed out now, back in a couple of hours | 16:44 |
clarkb | https://hub.docker.com/layers/library/mariadb/10.11/images/sha256-3595c1017b57939d4b5c5bc79f5d4822e607d6408f220c2e50a488caacf0c40a it did update there yesterday | 16:45 |
clarkb | so nto sure why the client tooling reports it as older | 16:45 |
clarkb | clock wrong on the build host maybe? | 16:45 |
clarkb | or an old image that finally got updated? | 16:45 |
opendevreview | Merged opendev/system-config master: Switch keycloak to opendevmirror hosted mariadb image https://review.opendev.org/c/opendev/system-config/+/940348 | 17:20 |
clarkb | keycloak db updated then the deploy failed in a handler for restarting services. I haven't logged out and in aggain but the service seems to be up. I'm going to debug the handler first | 17:26 |
opendevreview | Clark Boylan proposed opendev/system-config master: Fix keycloak container restart handler https://review.opendev.org/c/opendev/system-config/+/940819 | 17:30 |
clarkb | its a simple issue and I don't think it is a problem in this case because the db did "update". I'll work on testing functiaonlity next | 17:31 |
clarkb | I am able to login with my account so seems happy | 17:33 |
clarkb | looking at the bindep stack again I think the "safe" set that I expect to be less contentious are 816741 938520 938568 940219 and 940812 (if this laste one works without the others) | 18:04 |
clarkb | fungi: ^ maybe we want to restack with the requirements file changes last though I'm not sure if that would require additional shuffling of metadata | 18:04 |
opendevreview | Clark Boylan proposed opendev/system-config master: Add AI openstack working group list to lists.openinfra.org https://review.opendev.org/c/opendev/system-config/+/940821 | 18:14 |
clarkb | infra-root if you're happy with new grafana server can you let me know on https://review.opendev.org/c/opendev/system-config/+/940752 ? Don't necessarily need a full review on that just an ack that there don't appear to be problems with the new service before I start tearing down the old one | 18:21 |
clarkb | I have a doctor appointment from ~1630-1830 tomorrow. Just a heads up I'll be out during that time. | 18:33 |
clarkb | corvus: I was wrong we do run manage-projects out of the gerrit container image | 18:44 |
clarkb | but we do it via docker run in a single use container instance not exec'ing the actual service container | 18:45 |
clarkb | I wonder if maybe we should hav a jeepyb image for commands like that. We install to the gerrit container because the gerrit hooks need to be local (or bind mounted I suppose but having that work with content from another container image seems annoying) | 18:45 |
clarkb | anyway the jeepyb change failed on rate limits | 18:46 |
clarkb | we can recheck if we're happy with the status quo or brainstorm furhter on alternative approaches though I'm not coming up with anything great along those lines | 18:46 |
fungi | clarkb: i was planning to try merging 940812 into one of the earlier changes anyway, just wanted to see if it passed all the current jobs first | 18:54 |
fungi | the gerrit hooks run scripts from jeepyb, which needs it to be installed to the python search path | 18:57 |
fungi | because those scripts import modules from jeepyb | 18:59 |
clarkb | ya we need jeepyb accessible to gerrit hooks and installing them into thei mage is still probably the easiest way to do that | 19:03 |
clarkb | in this case we're trying to udpate a non hook script so I was trying to determine if we had to rebuild a gerrit image (we do) and whether or not that is always appropriate (its probably simplest for now) | 19:03 |
corvus | we don't update this a lot... if we did, then separating it out might be worthwhile. but for occasional updates, probably not. i think we can probably just acknowledge that we'll get the new behavior whenever we next docker pull on that machine | 19:09 |
opendevreview | Clark Boylan proposed opendev/system-config master: Update to gitea 1.23.2 https://review.opendev.org/c/opendev/system-config/+/940823 | 19:13 |
clarkb | corvus: thats a good point too | 19:14 |
clarkb | gitea's new release is hot off the presses ^ | 19:14 |
corvus | looking at packges.debian.org and ubuntu.com -- it looks like python3.11 is in bookworm,sid,jammy. and 3.12 is in trixie,sid,noble,oracular | 19:23 |
corvus | so to use debian nodes, zuul would need bookworm and trixie; to use ubunte nodes it would need jammy and noble (what it currently uses) | 19:23 |
fungi | i concur. | 19:24 |
fungi | note that 3.12 will likely disappear from trixie and sid very soon | 19:24 |
corvus | i wonder if i should add bookworm and trixie jobs/images, or add jammy/noble images. we've talked about maybe using debian for a while now, but maybe that's too many moving parts.... | 19:24 |
corvus | ah | 19:24 |
fungi | trixie is expected to release with only 3.13 | 19:25 |
corvus | okay i think i should probably just do the ubuntu nodes then | 19:25 |
corvus | "just use debian" is not easier in this particular circumstance; but might still be interesting later | 19:25 |
fungi | 3.12 in trixie (and hence sid) was only a stop-gap while 3.13 hadn't made it into the distro yet, but work there is focused on porting the remaining packages to 3.13 so that 3.12 can be removed | 19:26 |
fungi | basically the python package maintainers in debian don't want to be stuck maintaining more than one python version in stable | 19:27 |
fungi | 3.12-3.13 is just taking a bit of time to complete mainly because of the stdlib cleanup in 3.13 ("removing dead batteries") | 19:27 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Evacuate most metadata out of setup.cfg https://review.opendev.org/c/opendev/bindep/+/938520 | 19:30 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop support for Python 3.6 https://review.opendev.org/c/opendev/bindep/+/938568 | 19:30 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop requirements.txt https://review.opendev.org/c/opendev/bindep/+/938570 | 19:30 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop tox.ini https://review.opendev.org/c/opendev/bindep/+/940219 | 19:30 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop auxiliary requirements files https://review.opendev.org/c/opendev/bindep/+/940711 | 19:30 |
fungi | clarkb: i've abandoned 940812 and combined it into 938520 now | 19:30 |
Clark[m] | Cool I'm sorting out an early lunch then will re review | 19:30 |
opendevreview | James E. Blair proposed opendev/zuul-providers master: Add ubuntu jammy and noble images https://review.opendev.org/c/opendev/zuul-providers/+/940826 | 19:33 |
fungi | well, let's see if it passes first, it's possible that has to shuffle to after the python 3.6 support removal | 19:34 |
opendevreview | James E. Blair proposed opendev/zuul-providers master: Add ubuntu jammy and noble images https://review.opendev.org/c/opendev/zuul-providers/+/940826 | 19:36 |
opendevreview | James E. Blair proposed opendev/zuul-providers master: Run ubuntu jammy and noble build jobs https://review.opendev.org/c/opendev/zuul-providers/+/940827 | 19:36 |
corvus | Clark: fungi when you have a second, can you review 940826 -- that needs to merge before 827 can run the check jobs (which will take a while, so i'd like to get that started) | 19:38 |
Clark[m] | Will do | 19:40 |
fungi | lgtm, approved | 19:41 |
corvus | thx! | 19:41 |
fungi | it was pretty quick to review by just comparing to the already existing entries | 19:41 |
corvus | yeah pretty mechanical | 19:41 |
opendevreview | Merged opendev/zuul-providers master: Add ubuntu jammy and noble images https://review.opendev.org/c/opendev/zuul-providers/+/940826 | 19:45 |
opendevreview | Merged opendev/system-config master: Fix keycloak container restart handler https://review.opendev.org/c/opendev/system-config/+/940819 | 19:45 |
clarkb | I've approved the change to remove grafana01 from the inventory | 20:04 |
jrosser | i think this means that i cannot use sudo in a tox job https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks/tox/run.yaml#L3 | 20:05 |
jrosser | have i understood that correctly? | 20:06 |
clarkb | jrosser: you can't use sudo if using the default tox job playbook. That is correct. This is there bceause we learned very early on that developers will hide root escalations inside of unittests | 20:06 |
fungi | generally yes, that's there specifically to keep accidental uses of sudo from creeping into tox envs and leading to devs needing to run things locally with root access | 20:06 |
clarkb | you can run tox a different way if that is particularly problematic (just keep in mind if you expect people to run this stuff on a laptop that may be surprising to those people) | 20:07 |
fungi | without it, nova unit tests would have required access to destroy your workstation | 20:07 |
jrosser | i have ended up very deep down a debugging rabbit hole, where a workaround is some apparmor manipulation | 20:08 |
clarkb | you could fix apparmor before invoking tox | 20:08 |
fungi | put the manipulation in a pre-run phase playbook | 20:08 |
clarkb | (but then other people invoking tox would also need to know to do that) | 20:08 |
fungi | but yes, it does imply complexity for anyone running that locally | 20:08 |
fungi | though at least it means that when they do that, which needs them to do it with root permissions, they'll be aware of it | 20:09 |
clarkb | the basic tox jobs run a setup script | 20:09 |
jrosser | yes i was wanting to keep this least-messy for local running too | 20:09 |
clarkb | that occurs before revoking permissions iirc and some projects use it to set up databases for example. That might be a good appraoch then people have the option to run the same script locally | 20:10 |
fungi | since "apparmor manipulation" means you're making permanent changes to the apparmor configuration of some dev's workstation | 20:10 |
clarkb | tools/test-setup.sh | 20:10 |
clarkb | nova has an example of this | 20:10 |
fungi | agreed, we tried to standardize on sticking things that need root/system permanent (or semi-permanent) additions/changes into a tools/test-setup.sh so it's discoverable | 20:11 |
fungi | swift for example uses it (or used to use it) to mount a xfs filesystem for performing attribute tests | 20:12 |
fungi | yeah, looks like they still do: https://opendev.org/openstack/swift/src/branch/master/tools/test-setup.sh#L7-L14 | 20:13 |
jrosser | my setup is with molecule | 20:18 |
jrosser | so this is tox -> molecule -> ansible (tests/prepare.yml) | 20:19 |
jrosser | ideally i would not want to be doing anything to apparmor at all | 20:20 |
jrosser | but at the moment i cannot find the root cause of the error i get | 20:20 |
clarkb | is it platform specific? could try running elsewhee (like update jammy to noble or use debian or something) | 20:23 |
jrosser | it is sort of platform specific, when running a centos9 systemd docker container via molecule you can't ssh to it, because of `unix_chkpwd[578]: could not obtain user info (root)` on the host and a corresponding apparmor denied log message | 20:24 |
jrosser | the exact same thing switching out the container image for rocky/debian/focal/noble is fine | 20:25 |
jrosser | but the root cause of the centos one causing the apparmor error, i can't pin down | 20:26 |
clarkb | that implies the problem is in the host side apparmor (containers don't run kernel protections anyway because no kernel? and centos uses selinux). But I'm wondering if a differetn apparmor setup say replacing jammy with noble or vice versa fixes it | 20:26 |
fungi | yeah, i was about to ask if it could be apparmor fighting with selinux | 20:26 |
jrosser | a very brute force `aa-teardown` on the host seems to let it proceed | 20:27 |
opendevreview | Merged opendev/jeepyb master: Create a stub .zuul.yaml https://review.opendev.org/c/opendev/jeepyb/+/940547 | 20:28 |
jrosser | i could try switching the node type from noble to jammy | 20:28 |
clarkb | re 940547 we should plan to restart gerrit and udpate the gerrit mariadb. Maybe tomorrow after my doctor appointment? | 20:30 |
clarkb | infra-root ^ fyi that way we aren't surprised by gerrit image updates later | 20:30 |
fungi | i'm on a 15:30-16:30 utc call tomorrow, but available to help with a gerrit restart outside that time | 20:32 |
clarkb | ya I need to leave for the appointment around 16:30 and be back around 18:30 as an estimate | 20:32 |
opendevreview | Merged opendev/system-config master: Add AI openstack working group list to lists.openinfra.org https://review.opendev.org/c/opendev/system-config/+/940821 | 20:37 |
clarkb | fungi: the bindep stack lgtm after reorganizing it | 20:46 |
clarkb | and I think we can probably proceed with the first three if there isn't any other input. THose seem pretty safe | 20:48 |
clarkb | the change to add that mailing list is going to run manage-projects (I dno't know where the overlap is for thsoe file matches) which should use the new gerrit image. Just fyi. I don't expect any problems as we aren't creating a new repo (and we test creating repos in ci for jeepyb too) | 20:54 |
clarkb | ya the job completed and reported success | 21:01 |
clarkb | https://zuul.opendev.org/t/openstack/build/a04032a1d7c34fa7a73ff4beac74251f | 21:01 |
fungi | good deal | 21:01 |
fungi | clarkb: regarding the bindep stack, should 940219 get shuffled higher up? i couldn't tell if we were keeping tox.ini around for any particular reason or whether it was merely missed cleanup from the switch to nox | 21:05 |
clarkb | fungi: I think it was "missing" cleanup. Initially tox.ini files were kept to make the transition easier as well as rollback but I think we're past that. I would move it up myself since I think it is safe to proceed with at this point | 21:06 |
fungi | will do, thanks | 21:06 |
corvus | the two image build jobs are running on ovh; the jammy one had a 20-minute pause while fetching .deb archives from the mirror; the noble one similarly had a 30-minute pause doing the same thing. the times overlapped, but did not start or end exactly at the same time. (20:28-20:47 in one instance, and 20:31-21:06 in the other) | 21:09 |
corvus | i don't know if that's normal, or exceptional. but probably worth keeping an eye on and looking into if it happens again? | 21:10 |
clarkb | that does seem excessive. I wonder if that implies our afs caches aren't being kept warm | 21:10 |
corvus | good thought; currently we use a smaller set of mirrors for our image builds; but this will spread it out a bit more | 21:11 |
clarkb | its possible that if we start running these regularly the caches would stay warmer and runtime would improve. Definitely worth watching | 21:12 |
corvus | ++ | 21:12 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop tox.ini https://review.opendev.org/c/opendev/bindep/+/940219 | 21:13 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Use PBR's pyproject.toml build-backend support https://review.opendev.org/c/opendev/bindep/+/816741 | 21:13 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Evacuate most metadata out of setup.cfg https://review.opendev.org/c/opendev/bindep/+/938520 | 21:13 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop support for Python 3.6 https://review.opendev.org/c/opendev/bindep/+/938568 | 21:13 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop requirements.txt https://review.opendev.org/c/opendev/bindep/+/938570 | 21:13 |
opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop auxiliary requirements files https://review.opendev.org/c/opendev/bindep/+/940711 | 21:13 |
clarkb | idea: because those are pacakges we bake into our normal images the test jobs never need to fetch them so they are always cold | 21:13 |
clarkb | basically this set of packages is disjoint from the set of packages that test nodes would normally fetch | 21:13 |
corvus | yeah. though i would normally expect that to manifest more like "runs slow for a while" rather than "stops for 30m" -- unless we're getting buffered output or something | 21:14 |
corvus | (if we are seeing buffered output, then "runs slow for a while" would look exactly like "stops for 30m" | 21:14 |
clarkb | oh ya I was assuming buffered output or at least "all the apt stuff took 30 minutes" | 21:15 |
clarkb | if its hard stopping that seems extra weird | 21:15 |
corvus | i guess the question is whether dib buffers output from the apt command in whatever element is doing that... there's a couple of layers involved | 21:16 |
clarkb | ya I think dib is a python command so dib could be buffering in python. There is an env var to have it not do that we could try setting if it persists | 21:17 |
corvus | but even if we hypothesize it's buffered -- there are some other timestamps involved that look like we got buffer flushes every few minutes; so if that's the case, then we're looking at maybe 2m between buffer flushes then 30m, so still weird. | 21:17 |
opendevreview | Merged opendev/system-config master: Remove grafana01 from config management https://review.opendev.org/c/opendev/system-config/+/940752 | 21:38 |
corvus | clarkb: fungi https://review.opendev.org/940827 passed if you want to approve it; we'll get new images then | 21:39 |
clarkb | corvus: +2 form me | 22:00 |
clarkb | not sure if fungi is still around may be worth approving as is? | 22:01 |
clarkb | does anyone want to remove the grafana01 dns cleanups now that grafana01 is no longer in inventory: https://review.opendev.org/c/opendev/zone-opendev.org/+/940753 | 22:01 |
fungi | clarkb: if you mean 940827 i approved it 5-6 minutes ago | 22:01 |
clarkb | fungi: ya sorry I should've refereshed | 22:03 |
opendevreview | Merged opendev/zone-opendev.org master: Cleanup grafana01 DNS records https://review.opendev.org/c/opendev/zone-opendev.org/+/940753 | 22:04 |
clarkb | with ^ done I cleaned up the emergency file. paste01 was still in there too | 22:26 |
clarkb | I'll plan to deelte grafana01 probably Friday /me makes a note on the todo list for that | 22:26 |
clarkb | the gitea 1.23.2 screenshots look good to me: http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_234/940823/1/check/system-config-run-gitea/234284d/bridge99.opendev.org/screenshots/ | 22:28 |
clarkb | I went ahead and approved the tox.ini removal change for bindep. That one shouldn't be controversial since we switched voer to nox some time ago | 22:50 |
clarkb | I'll leave the others in plce for more feedback for now | 22:50 |
clarkb | fungi: looking at your TODO on https://review.opendev.org/c/opendev/bindep/+/816741/24/setup.py PBR is acting as a build hook for setuptools already. I think the piece that is missing is pbr needs to appent the pbr=True flag to how it invokes setuptools? | 22:51 |
clarkb | right now its passing through to setuptools which eventually calls setup.py which is why setting pbr=True there works | 22:52 |
fungi | something like that maybe? i'm unclear on what the missing piece is to be able to drop setup.py entirely | 22:52 |
clarkb | I wonder if we can pass arbitrary setup() flags in setup.cfg or pyproject.toml to work around that | 22:52 |
clarkb | fungi: its basically needing to get pbr=True into setup() or have pbr detect it is being used some other way I think | 22:52 |
clarkb | with pyproject.toml the flow now is pbr hook -> setuptools hook -> setup.py -> setup() | 22:53 |
clarkb | I don't think we can easily get rid of pbr hook -> setuptools hook as pbr itself assumes it is running within/alongside setuptools. But if we can influence the config somehow to enable pbr without the argument to setup() then I think we can do it | 22:53 |
clarkb | https://opendev.org/openstack/pbr/src/branch/master/pbr/core.py#L64-L154 that is why we set pbr=True in setup() | 22:55 |
clarkb | which is tied into setuptools/distutils via https://opendev.org/openstack/pbr/src/branch/master/setup.cfg#L41-L42 | 22:55 |
clarkb | so basically we need to invoke that method somehow I think | 22:56 |
clarkb | fungi: maybe you can do [options]\npbr=True in setup.cfg? | 22:58 |
opendevreview | Merged opendev/bindep master: Drop tox.ini https://review.opendev.org/c/opendev/bindep/+/940219 | 22:59 |
clarkb | I'll push that up and see what happens | 23:00 |
fungi | yeah, if we can figure out how to inject it from pyproject.toml, bonus | 23:00 |
fungi | also if we can figure out how to drop the name field from setup.cfg (so that we can drop setup.cfg), extra bonus | 23:01 |
fungi | feels a little unfinished that we still need both stub setup.py and setup.cfg files | 23:01 |
opendevreview | Clark Boylan proposed opendev/bindep master: Test pbr=True set via setup.cfg https://review.opendev.org/c/opendev/bindep/+/940841 | 23:02 |
clarkb | the pyproject.toml stuff that is documented seems a lot more rigid | 23:02 |
clarkb | https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html and options doesn't seem to be an option | 23:02 |
opendevreview | Clark Boylan proposed opendev/bindep master: Test pbr=True set via setup.cfg https://review.opendev.org/c/opendev/bindep/+/940841 | 23:06 |
clarkb | fungi: ^ you'll like that. The errors I got seem to imply I need py_modules back | 23:06 |
clarkb | maybe if you define any options then that one becomes required? | 23:06 |
clarkb | so that seems to install but we don't actually install bindep | 23:10 |
clarkb | so ya that doesn't seem to work | 23:10 |
clarkb | oh well was worth a shot. I wonder if the problem is we're using a distutils hook and not setuptools and options is setuptools only | 23:11 |
clarkb | when we go through setup() I mean it uses a distutils hook apparently | 23:11 |
opendevreview | Merged opendev/zuul-providers master: Run ubuntu jammy and noble build jobs https://review.opendev.org/c/opendev/zuul-providers/+/940827 | 23:38 |
corvus | https://imgur.com/a/AqLgCHL | 23:56 |
corvus | that's two images being built in the same buildset | 23:56 |
corvus | first time we've seen that live; eventually the nightly builds will be one buildset with a bunch of image jobs. | 23:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!