| ianw | i'm assuming https://launchpad.net/~openstack-ci-core/+archive/ubuntu/bubblewrap is no longer in use too | 00:11 |
|---|---|---|
| fungi | that's my assumption as well | 00:25 |
| opendevreview | Ian Wienand proposed openstack/project-config master: Add opendev/infra-vhd-util-deb repository https://review.opendev.org/c/openstack/project-config/+/841054 | 00:59 |
| *** ysandeep|out is now known as ysandeep|rover | 04:58 | |
| opendevreview | Merged openstack/diskimage-builder master: Ensure cloud-init is configured to generated host keys https://review.opendev.org/c/openstack/diskimage-builder/+/840825 | 05:24 |
| opendevreview | Sandeep Yadav proposed openstack/diskimage-builder master: [DNM] test patch https://review.opendev.org/c/openstack/diskimage-builder/+/841065 | 05:46 |
| *** soniya29 is now known as soniya29|ruck | 06:13 | |
| *** soniya29 is now known as soniya29|ruck | 06:58 | |
| *** soniya29 is now known as soniya29|ruck | 07:19 | |
| *** ysandeep|rover is now known as ysandeep|rover|lunch | 07:20 | |
| *** jpena|off is now known as jpena | 07:30 | |
| *** soniya29 is now known as soniya29|ruck | 07:38 | |
| *** soniya29|ruck is now known as soniya29|ruck|lunch | 07:57 | |
| *** soniya29|ruck|lunch is now known as soniya29|ruck | 08:23 | |
| *** ysandeep|rover|lunch is now known as ysandeep|rover | 08:23 | |
| dirk | hi all, I am trying to push a new signed tag for renderspec, but I get this error message: remote: You need 'Create Tag' rights to push a normal tag. remote: User: dmllr | 09:48 |
| dirk | I was hoping I would have create tag rights via https://review.opendev.org/admin/groups/6fa146e80fe07f4d94f5c1ee34b4e1b590f7bb63,members but that doesn't seem to be enough. what else is missing? | 09:49 |
| *** rlandy|out is now known as rlandy | 10:24 | |
| *** dviroel_ is now known as dviroel\ | 11:14 | |
| *** dviroel\ is now known as dviroel | 11:14 | |
| fungi | dirk: the message says "normal tag" which implies at least one tag you're trying to push isn't actually signed. are you following the instructions here? https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#tagging-a-release | 11:40 |
| *** ysandeep|rover is now known as ysandeep|rover|break | 11:57 | |
| dirk | fungi: I did fillow, but it is a ssh tag | 11:57 |
| fungi | what do you mean a ssh tag? | 11:58 |
| fungi | do you mean you're using a signed push instead of signing the tag object? if so, that's not the same thing | 11:58 |
| dirk | fungi: https://calebhearth.com/sign-git-with-ssh | 11:59 |
| fungi | dirk: right, not the same. you need to use git tag -s | 12:00 |
| dirk | I guess I need to create a gpg key and retry | 12:00 |
| fungi | yes, please see the instructions i linked above | 12:00 |
| fungi | signed pushes are signing the activity of pushing objects, not the objects themselves (it's distinct, since you could be pushing objects on behalf of another committer) | 12:01 |
| fungi | you need to sign the tag object, which is what git tag -s does | 12:01 |
| dirk | fungi: I did ran git tag -s | 12:20 |
| *** pojadhav is now known as pojadhav|break | 12:22 | |
| fungi | dirk: and you're explicitly pushing the tag you created, specifying it by name in the push command? | 12:36 |
| *** ysandeep|rover|break is now known as ysandeep|rover | 12:57 | |
| dirk | fungi: https://paste.openstack.org/show/b6wQqO9AE5T6fpo2mF9H/ | 13:05 |
| dirk | https://paste.openstack.org/show/bcxHi01YANJ8DUzonvjp/ is the tag | 13:07 |
| dirk | it looks like gerrit is not patched to handle ssh signatures, https://github.com/GerritCodeReview/gerrit/blob/master/java/com/google/gerrit/server/restapi/project/CreateTag.java#L110 | 13:07 |
| fungi | ahh, yes, i've never heard of ssh signatures, which is why i thought you were talking about signed pushes | 13:08 |
| fungi | it needs an openpgp signature | 13:09 |
| dirk | its a relatively recent feature | 13:09 |
| fungi | gerrit, being implemented in java, doesn't use cgit but rather jgit, which tends to lag behind cgit feature-wise | 13:10 |
| fungi | and gerrit usually doesn't bundle the most recent jgit version, we're usually not on the very latest gerrit release anyway | 13:10 |
| fungi | so git features can take years to trickle into our gerrit deployment, unfortunately | 13:11 |
| fungi | but thanks for educating me on git's ssh signature format, i'll need to do some more reading on that | 13:13 |
| *** pojadhav|break is now known as pojadhav | 13:57 | |
| *** soniya29 is now known as soniya29|ruck | 14:06 | |
| dirk | fungi: thank you for the help, openpgp signature worked | 14:38 |
| *** pojadhav is now known as pojadhav|afk | 14:54 | |
| *** soniya29|ruck is now known as soniya29|ruck|dinner | 14:54 | |
| Clark[m] | I suspect it would work if you allowed normal tag pushes. Gerrit doesn't recognize the ssh tag as a gpg tag which is correct but there isn't a specific ACL for ssh tags | 14:58 |
| Clark[m] | And the signing is embedded in the objects so jgit doesn't need to know much about them. That said I could be wrong and pushing such a tag could be problematic | 14:59 |
| *** dviroel is now known as dviroel|lunch | 15:10 | |
| clarkb | infra-root does 15:30 UTC (about 10 minutes from now) still work to chat about CD stuff? | 15:19 |
| fungi | wfm, yep. thanks! | 15:19 |
| *** soniya29|ruck|dinner is now known as soniya29|ruck | 15:36 | |
| *** marios is now known as marios|out | 15:50 | |
| *** ysandeep|rover is now known as ysandeep|out | 16:09 | |
| *** soniya29|ruck is now known as soniya29|out | 16:12 | |
| *** dviroel|lunch is now known as dviroel | 16:24 | |
| clarkb | fungi: any reason to not approve https://review.opendev.org/c/opendev/system-config/+/840955 at this point? I expect to be around today and can monitor | 16:35 |
| clarkb | sorry meant to describe the change. It is the etherpad upgrade | 16:35 |
| fungi | nope! i've approved it now | 16:35 |
| clarkb | thanks! | 16:36 |
| clarkb | Gerrit has pushed their final release candidate before the 3.6 release | 16:45 |
| clarkb | I think we should still target 3.5 as there is a history of new gerrit releases needing time to bake | 16:45 |
| clarkb | But we could potentially be on 3.6 this year before 3.7 happens? That is exciting | 16:46 |
| clarkb | corvus: if you get a chance can you check https://review.opendev.org/c/opendev/system-config/+/840529 this is an update to where we pull keycloak docker images and that will cause a service upgrade I think? | 16:47 |
| clarkb | corvus: I suspect you are the primary use of keycloak currently so wanted your input on that | 16:47 |
| corvus | clarkb: i think it's experimental until someone else wants to start using it, so i'm totally fine merging that and seeing what happens | 17:00 |
| corvus | +3 | 17:00 |
| clarkb | wmf | 17:00 |
| clarkb | er wfm | 17:00 |
| opendevreview | Merged opendev/system-config master: Update etherpad to 1.8.18 https://review.opendev.org/c/opendev/system-config/+/840955 | 17:13 |
| clarkb | I don't think we auto restart the container for etherpad. I'll work on that once automation pulls it down | 17:13 |
| *** jpena is now known as jpena|off | 17:17 | |
| opendevreview | Merged opendev/system-config master: Pull keycloak from quay.io https://review.opendev.org/c/opendev/system-config/+/840529 | 17:25 |
| clarkb | I was wrong it restarted itself jsut now | 17:42 |
| clarkb | and it is unhappy :/ | 17:43 |
| fungi | huh... | 17:44 |
| fungi | Database is not configured with charset utf8mb4 -- This may lead to crashes when certain characters ar | 17:45 |
| fungi | e pasted in pads | 17:45 |
| clarkb | ya then later it complains about logging level not being defined? | 17:45 |
| fungi | which seems like it could be a secondary error | 17:46 |
| fungi | also i thought we explicitly configured the backing db for 4-byte utf-8 | 17:47 |
| fungi | is it misdetecting it, or hitting the wrong db? | 17:47 |
| fungi | very odd | 17:47 |
| clarkb | that first one almost seems like a warning and ya I thought we configured it for that. But we can double check | 17:47 |
| clarkb | also why doesn't it break in CI? I even held the node and it seemed to work | 17:48 |
| fungi | show table status says it's utf8mb4_bin | 17:52 |
| fungi | maybe it checks for utf8mb4 rather than utf8mb4_bin? | 17:53 |
| clarkb | ya I'm pulling up source code now to see if logging that error is what raises the level issue | 17:54 |
| clarkb | its possible that is the problem? | 17:54 |
| fungi | we seem to set utf8mb4_bin for collation_server, but utf8mb4 for default-character-set, character-set-server, and in the etherpad settings.json | 17:54 |
| fungi | maybe in ci jobs we're creating the table as utf8mb4 not utf8mb4_bin | 17:54 |
| fungi | do we want to roll back the container, or in-place migrate the table after dumping it? | 17:56 |
| clarkb | fungi: in our json.settings we set the db charset to utf8mb4 not utf8mb4_bin. I wonder if that is the issue | 17:56 |
| fungi | i guess that's not hard to try changing by hand first | 17:57 |
| clarkb | well can we convert between the two? eg utf8mb4_bin -> utf8mb4? I don't know | 17:57 |
| clarkb | but also I'm not sure if the mixed settinsg you found represent a problem either way | 17:57 |
| fungi | we may need to dump and load | 17:57 |
| fungi | yeah, i honestly have no idea | 17:57 |
| fungi | i mainly wanted to double-check that it wasn't somehow back to the 3-byte default width | 17:57 |
| clarkb | I think before we do anything we need to better understand why this error is happening | 17:59 |
| fungi | yes | 17:59 |
| clarkb | also rolling back may not be straigtforward if we already pruned the image on docker hub? we could try a revert and rebuilt I guess | 17:59 |
| fungi | and whether that's the actual error causing it to crash, or unrelated | 18:00 |
| clarkb | but ya I'm going to dig around ad see if I can figure out why it is complaining when we seem to set it that way | 18:00 |
| clarkb | ++ | 18:00 |
| fungi | and yeah, looks like we don't still have the old container image on the server | 18:00 |
| clarkb | the db error checks DEFAULT_CHARACTER_SET_NAME against charset | 18:02 |
| clarkb | and it queries that for our db schema (not table level) | 18:02 |
| clarkb | and that code hasn't changed in a long time | 18:03 |
| fungi | and we haven't touched that config ourselves for 2 years | 18:04 |
| fungi | it got added to our settings.json and my.cnf by 718536 two years ago | 18:05 |
| clarkb | ok I strongly suspect reverting the etherpad change will fix this | 18:06 |
| fungi | oh? | 18:06 |
| clarkb | one of the changes 1.8.18 made was updating euberdb2 to 2.2.4 which is a super new change | 18:06 |
| clarkb | 1.8.17 used euberdb2 1.4.18 | 18:06 |
| fungi | oh, so maybe it's misreading the schema | 18:07 |
| clarkb | and these errors are all originating in euberdb2 | 18:07 |
| clarkb | fungi: https://github.com/ether/ueberDB/blob/v2.2.4/databases/mysql_db.js#L68-L79 thats the first error | 18:10 |
| clarkb | that exists in 1.4.18 though | 18:10 |
| clarkb | oh but the logging error originates in https://github.com/ether/ueberDB/blob/v1.4.18/databases/mysql_db.js#L42-L52 which is called above | 18:11 |
| clarkb | so anyway I do suspect that rolling back has a good chance of working | 18:12 |
| fungi | so maybe in trying to log the encoding mismatch it's been complaining about for who knows how long, it tripped a bug in logging code not normally traversed and perhaps poorly-tested | 18:12 |
| clarkb | ya thats what I'm suspecting | 18:13 |
| clarkb | however in testing we don't seem to have this problem https://zuul.opendev.org/t/openstack/build/94b0c05140cd48e0a6fb4d4a7562b7b0/log/etherpad01.opendev.org/docker/etherpad-docker_etherpad_1.txt | 18:15 |
| clarkb | in testing it shows connection errors to the database while the database is coming up. And that all looks similar to what we see here except for hte logging failure | 18:16 |
| clarkb | then once the db is up it starts and is happy | 18:16 |
| clarkb | in production the db was never stopped and should be up | 18:16 |
| clarkb | I'm going to try and look at the actual db now | 18:18 |
| clarkb | fungi: etherpad-lite is utf8 | utf8_bin | 18:22 |
| clarkb | according to the schemata which is what it is checking | 18:22 |
| clarkb | fungi: where did you see the utf8 settings before that seemed to match up? | 18:23 |
| clarkb | I think it may work in production because we let etherpad lite create the db freshly which sets the values it wants | 18:24 |
| clarkb | however these are not new checks from what I can tell so I'm still confused as to why it is failing now | 18:24 |
| clarkb | oh I see | 18:25 |
| clarkb | fungi: https://github.com/ether/ueberDB/blob/v2.2.4/databases/mysql_db.js#L106-L113 I think we may actually be failing there | 18:25 |
| fungi | i looked at show table status | 18:26 |
| fungi | the database may be utf8 but the table is utf8mb4 | 18:27 |
| clarkb | ya I think that may be what is going on. I'm going to try this select to get the migration level | 18:27 |
| clarkb | I think what is happening is that it is trying to log the charset for us after that error. in the process of logging the charset it is trying to lookup the migration level which is set later | 18:31 |
| clarkb | that errors and it short circuits there | 18:31 |
| clarkb | if we set the charsets on the schema properly it would in theory get by all this. But then our migration level may be wrong. However, I think migration level may already be correct because it would've set it in the past? | 18:31 |
| fungi | well, s/properly/like etherpad wants/ anyway | 18:32 |
| fungi | it's set properly (the database is still default, but we've set the table to utf8mb4) | 18:33 |
| clarkb | right | 18:33 |
| clarkb | how do yu show it on a table? is that in the information schema too? | 18:33 |
| clarkb | ah yup | 18:34 |
| fungi | i checked show table status which lists extended information for all tables | 18:34 |
| clarkb | my suspicion now is that what broke is logging and that we likely always had these issues previously | 18:36 |
| clarkb | but before it was basically a warning. now with broken logging its fatal | 18:37 |
| fungi | because it breaks trying to log the warning | 18:37 |
| fungi | makes sense | 18:37 |
| clarkb | given that I think what we can do is docker-compose down the etherpad service but not the db. mysqldump the db just in case. Update the schema default utf8 settings for etherpad-lite and then try starting the service again | 18:38 |
| fungi | agreed, that shouldn't require any migration since it's just modifying the db default | 18:38 |
| fungi | also it will at that point match what we're testing, at least in theory | 18:39 |
| clarkb | oh! the sqlalter only affects the store table not the etherpad-lite schema so that explains why it wasn't auot updating | 18:40 |
| clarkb | fungi: I'll go ahead and down the service and run a db backup? | 18:40 |
| fungi | yes, thanks! | 18:41 |
| clarkb | fungi: we want default charset to be 'utf8mb4' and default collation to be 'utf8mb4_bin' if I read this properly | 18:41 |
| clarkb | fungi: maybe you can sort out how to modify the db to do that while I do backups? | 18:41 |
| fungi | right, that's what i see in the my.cnf anyway | 18:41 |
| fungi | looking into it now | 18:42 |
| clarkb | I ran `sudo docker-compose stop etherpad` so that we can check docker-compose logs against that if necessary (down would delete it and no more logs) | 18:43 |
| clarkb | I'm going to give it a few minutes to make sure it isn't going to auto restart somehow then start backups | 18:43 |
| clarkb | its been 2 minutes and it hasn't started. I'll run the db backup now | 18:45 |
| clarkb | fungi: `ALTER DATABASE etherpad-lite CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;` ? | 18:46 |
| clarkb | this backup is not fast. About a tenth of the way complete | 18:47 |
| fungi | https://mariadb.com/kb/en/setting-character-sets-and-collations/ other than quoting the encodings | 18:48 |
| fungi | yes | 18:49 |
| fungi | ALTER DATABASE etherpad-lite CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin'; | 18:49 |
| fungi | er, and the = | 18:50 |
| fungi | ALTER DATABASE etherpad-lite CHARACTER SET = 'utf8mb4' COLLATE = 'utf8mb4_bin'; | 18:50 |
| fungi | clarkb: ^ so like that | 18:51 |
| fungi | at least that's what i gather from the mariadb kb | 18:51 |
| NeilHanlon | that looks right to me | 18:51 |
| clarkb | now I'm trying to figure out why logging is broken :/ | 18:52 |
| NeilHanlon | :( | 18:52 |
| clarkb | in theory it works enouh for our testing to g et by though | 18:52 |
| fungi | can it be just that one logging call is wrong somehow, maybe missed in a transition to a new call structure at some point? | 18:55 |
| fungi | because it's logging other stuff | 18:55 |
| clarkb | https://github.com/ether/ueberDB/blob/v2.2.4/databases/mysql_db.js#L78 is where we break and I think result[0] is taken as the log level since it is logger.log and not logger.error as per the statement above | 18:57 |
| clarkb | so ya it may just be this is specific to that specific doe | 18:57 |
| clarkb | s/doe/code/ | 18:57 |
| clarkb | https://github.com/log4js-node/log4js-node/blob/v0.6.38/lib/logger.js#L53-L55 is where it seems to explode | 18:58 |
| fungi | and logging a particular error condition is likely to not have code coverage for testing | 18:58 |
| clarkb | ya makes sense | 18:59 |
| clarkb | about 2/3s done with the backup | 18:59 |
| clarkb | fungi: ok db backup is done. Did you want to run the alter on the etherpad-lite db schema? | 19:10 |
| fungi | alter test? | 19:11 |
| fungi | oh the alter | 19:11 |
| fungi | yeah, i can, just a sec | 19:11 |
| fungi | it doesn't like that syntax | 19:13 |
| fungi | ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-lite CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin' at line 1 | 19:13 |
| clarkb | I don't think you want the ='s | 19:13 |
| fungi | i guess it doesn't expect the token there to have a hyphen in it, so maybe that's not where the db name goes | 19:13 |
| fungi | well, the alter commands in the mariadb kb included the = | 19:14 |
| clarkb | oh huh ya maybe you ahve to quote the db name? | 19:14 |
| clarkb | does it use backticks for that? | 19:14 |
| fungi | i did try quoting the db name as well | 19:14 |
| fungi | oh, mackticks | 19:14 |
| fungi | backticks | 19:14 |
| clarkb | ya backticks | 19:14 |
| fungi | yeah, that seems to have done it | 19:15 |
| fungi | ftr, complete command line was: | 19:15 |
| fungi | sudo docker-compose -f /etc/etherpad-docker/docker-compose.yaml exec -T mariadb bash -c '/usr/bin/mysql -uroot -p"$MYSQL_ROOT_PASSWORD" -e "ALTER DATABASE \`etherpad-lite\` CHARACTER SET = 'utf8mb4' COLLATE = 'utf8mb4_bin'" etherpad-lite' | 19:15 |
| clarkb | I see it reflected in the information schema too. Should I start the servicen ow? | 19:15 |
| fungi | yep! | 19:15 |
| clarkb | ok doing that | 19:15 |
| fungi | oh, hah, i also just noticed that my quoting of the encodings was probably eaten by the shell, but obviously unnecessary | 19:16 |
| clarkb | [2022-05-09 19:16:18.763] [INFO] server - Etherpad is running | 19:16 |
| clarkb | Up 43 seconds (healthy) | 19:16 |
| clarkb | now to check the actual etherpads are happy | 19:17 |
| clarkb | https://etherpad.opendev.org/p/isitbroken | 19:17 |
| fungi | #status log Updated database-wide default encoding for Etherpad server to utf8mb4, as setting it only on the table is insufficient to satisfy its safety checks | 19:18 |
| opendevstatus | fungi: finished logging | 19:18 |
| fungi | yeah, looks like it's working as desired | 19:18 |
| clarkb | ya I've got multiple browsers pulling up and editing that pad. I think that was it. | 19:19 |
| clarkb | I'll file a bug upstream after lunch | 19:19 |
| fungi | yes, looks to me like it's working as desired | 19:19 |
| fungi | thanks for figuring that out! | 19:20 |
| clarkb | that was far more exciting than expected, but at least running it down was productive | 19:21 |
| clarkb | I'm going t ogo eat lunch now and will file that bug when I get back | 19:21 |
| Clark[m] | As a sanity check those values are only defaults if unspecified when creating tables right? And since etherpad only has a single table with the correct values already the change here is basically nil for us? | 19:26 |
| Clark[m] | That was my understanding and want to make sure others agree | 19:26 |
| Clark[m] | Ya docs say it affects create table, load data, and stored routines that don't have values specified | 19:29 |
| Clark[m] | I think those are non issues here | 19:29 |
| clarkb | I wonder if https://github.com/ether/ueberDB/commit/7a352387eb43dc111a2547e19343134cedb4b622 is to blame | 19:40 |
| fungi | clarkb: for added amusement, checking the default character set for the db is kinda silly, since that doesn't mean the character set for the table etherpad is actually writing to is correct | 19:42 |
| clarkb | ya I think its a asnity check for those other operations but I can make note of that in the issue too | 19:43 |
| fungi | one of the things to come out of the python 3.11.0b1 release this weekend is that pep 594 marks a bunch of things in stdlib deprecated for removal in 3.13, and one of those things is the cgi module which lots of projects have been relying on for http header paramaterization, including pip. so i spent a chunk of time this weekend proposing a fix to replace it with email.message (which has a | 19:50 |
| fungi | similar mime parser), and that entailed not only familiarizing myself with pip's testsuite but even moreso reminding myself how to use github. spoiler: it's still frustrating | 19:50 |
| fungi | at least my pr is passing all 19 of pip's ci jobs now, including coercing things to unambiguous data types in order to appease the typechecking | 19:51 |
| fungi | still need to propose a similar fix for use of cgi in Cython.Tempita._tempita, crypt in passlib.utils, and some places in my own code where i'm using telnetlib in its testsuite | 19:53 |
| fungi | sort of sad to see telnetlib on the chopping block, since the thing i'm testing with it is an actual rfc-compliant telnet server | 19:55 |
| clarkb | https://github.com/ether/ueberDB/issues/266 posted | 19:59 |
| fungi | thanks! | 20:12 |
| fungi | mordred: in the spi board meeting (#spi channel right now) they're talking about whether to renew the drizzle trademark or let it expire, just fyi (no idea if you know anyone who cares) | 20:27 |
| mordred | fungi: I don't think anyone cares. (I mean, I *care* but nobody has worked on the project in long enough that it makes sense for SPI to renew | 20:30 |
| fungi | yeah, i figured | 20:30 |
| mordred | \o/ I have participated in a discussion | 20:36 |
| fungi | indeed. i was hesitant to speak up during the board meeting as i'm not a board member, but i figure feedback from someone who can represent the drizzle project would probably count as solicited feedback | 20:41 |
| *** dviroel is now known as dviroel|afk | 20:43 | |
| ianw | clarkb/fungi/mordred even: if you have a sec for https://review.opendev.org/c/openstack/project-config/+/841054 that will add a repo to build vhd-util and we can use the same infrastructure as the openafs-debs | 21:18 |
| ianw | i think that's really the two ppa's in active use and it will be good to have it zuulified | 21:18 |
| clarkb | ++ I have to do a school run now and have some stuff on the backlog already but will try to get to it | 21:18 |
| ianw | np, that's just adding the repo, nothing interesting yet ... i still have to do that bit :) | 21:19 |
| ianw | fungi: do we have a specific "infra-core" acl i missed? | 21:49 |
| fungi | i don't think so. i was considering just checksumming the acl directory and seeing which ones were identical | 21:56 |
| opendevreview | dasm proposed opendev/elastic-recheck rdo: Enable podman-compose https://review.opendev.org/c/opendev/elastic-recheck/+/841172 | 21:58 |
| fungi | that was the main point of the normalization script years ago: figuring out which acls we could deduplicate | 21:58 |
| fungi | looks like the infra-openafs-deb, zone-opendev.org and zone-zuul-ci.org share the same content checksums right now, so not as many as i'd guessed | 22:01 |
| clarkb | each of the puppet repos got specific acls iirc | 22:01 |
| fungi | also those are the only duplicated acls in the opendev/ namespace | 22:01 |
| fungi | yep | 22:01 |
| clarkb | and then system-config and project-config don't match | 22:02 |
| clarkb | we can probably make a number of repos match though | 22:02 |
| fungi | so not a huge savings to deduplicate the other three at the moment | 22:02 |
| fungi | maybe if we standardize our acls more in the future there would be more reason | 22:02 |
| ianw | yeah there's some others like afsmon that seems to have it's own group but doesn't really need it | 22:11 |
| clarkb | I'm going to put the PPA building stuff on the meeting agenda just so that we can get a quick tldr | 22:12 |
| fungi | i'd love to find time to scan gerrit for unused groups, but... | 22:12 |
| *** rlandy is now known as rlandy|bbl | 22:13 | |
| opendevreview | Merged openstack/project-config master: Add opendev/infra-vhd-util-deb repository https://review.opendev.org/c/openstack/project-config/+/841054 | 22:13 |
| *** cloudnull8 is now known as cloudnull | 23:04 | |
| opendevreview | Ian Wienand proposed opendev/infra-vhd-util-deb focal: Initial import https://review.opendev.org/c/opendev/infra-vhd-util-deb/+/841174 | 23:22 |
| opendevreview | Ian Wienand proposed opendev/infra-vhd-util-deb focal: Initial import of debian build files https://review.opendev.org/c/opendev/infra-vhd-util-deb/+/841175 | 23:25 |
| clarkb | ianw: in ^ we have a bionic.patch and a focal.patch. Should we be handling that with branches or is the build system applying them based on the name and target and we don't need branches for this case? | 23:31 |
| ianw | clarkb: yeah, i was planning on applying those patches as separate changes to the actual source tree, and removing from debian/patches | 23:31 |
| ianw | that's clearer as to what's going on, now the source is in git | 23:32 |
| clarkb | we would have to carry the entire source tree if we did that though? | 23:33 |
| clarkb | I guess some deb pacakges do that and some don't? | 23:33 |
| ianw | yeah, given that this is a very bespoke tool now, and our efforts at upstreaming bits have not succeeded for the past ... 10 years ... i think this is a case of keeping our special source tree is the most practical approach | 23:36 |
| clarkb | that is a good point | 23:36 |
| ianw | i've forgotten all the details, but xen removed big bits of it (blktap2, something something) | 23:38 |
| clarkb | the etehrpad service hasn't restarted since we applied the schema default charset and collation update | 23:56 |
| opendevreview | Ian Wienand proposed opendev/infra-vhd-util-deb focal: Initial import https://review.opendev.org/c/opendev/infra-vhd-util-deb/+/841174 | 23:59 |
| opendevreview | Ian Wienand proposed opendev/infra-vhd-util-deb focal: Initial import of debian build files https://review.opendev.org/c/opendev/infra-vhd-util-deb/+/841175 | 23:59 |
| opendevreview | Ian Wienand proposed opendev/infra-vhd-util-deb focal: [wip] test vhd-util build https://review.opendev.org/c/opendev/infra-vhd-util-deb/+/841179 | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!