icu4c 70.1

[Bo98]

Created with brew bump-formula-pr.

Not yet officially announced yet, but it will be by the time we're ready with this.

[carlocab]

Linkage failures on ARM:

apngasm
boost
clickhouse-odbc
dwdiff
freeling
harfbuzz
hfstospell
libcdr
libical
liblcf
libmspub
libphonenumber
libpsl
libvisio
mapnik
mpd
mysql
ncmpcpp
node
node@12
node@14
node@16
openrct2
pazpar2
pcl
percona-server
percona-xtrabackup
php
postgresql
postgresql@10
postgresql@11
postgresql@12
postgresql@13
qt
sile
tectonic
texlive
tracker
vte3
vtk
widelands
yaz
zebra
znc
zorba

There's plenty more on Linux.

[Bo98]

Linux linkage failures are awkward as they are checked recursively, which I'll try fix first before pushing.

codequery etc shouldn't need revision bumps.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. To keep this pull request open, add a help wanted or in progress label.

[Bo98]

Plan for this is to do it after openldap is done, to avoid conflicts.

[SMillerDev]

OpenLDAP is finally merged, shall I rebase this?

[carlocab]

You still have a conflict for tracker

[Bo98]

Oh libsoup just got merged when I was rebasing it seems.

[carlocab]

Are any of these GCC dependents? If they are we may want to rebase this so we can attempt a bottle build when applicable.

[Bo98]

ncmpcpp.

mapnik too though that's not even on Intel Monterey yet.

I've maybe missed others but that's what I see from a very quick glance through what has a arm64_monterey bottle and what doesn't.

[carlocab]

Only ones that show up for me (on master) as ready to bottle are chakra, gjs, mysql, ncmpcpp, tarantool, and percon-server.

Probably only ncmpcpp then, so not worth the rebase.

[Bo98]

I've got PRs open for most failures (last couple will be up in a bit).

I do not think it will be possible to revision bump texlive in this PR so I will likely drop it. Going forward we will need to consider splitting that formula to be manageable.

[SMillerDev]

@danielnachun I think we'll have to reduce the size of the installed packages for texlive. Is this something you could pick up?

[danielnachun]

@danielnachun I think we'll have to reduce the size of the installed packages for texlive. Is this something you could pick up?

Definitely. The reason the bottle is so big right now is because of the texlive-texmf resource. I would propose that we rename the current formula to texlive-bin and remove the texlive-texmf resource. Then we would make a texlive-texmf formula which just installs the texlive-texmf resource and symlinks it into the cellar path for texlive-bin. This texlive-texmf formula would only depend on texlive-bin so it wouldn't get pulled into any dependent tests.

[cho-m]

Since we doubled space of self-hosted Linux to 100G due to dotnet, is it possible that texlive will install now? Though, will probably want to wait for a couple other PRs to get merged first due to conflicts, like boost.

[danielnachun]

I think we were running out of space on macOS actually, though we should confirm that.

[cho-m]

I think we were running out of space on macOS actually, though we should confirm that.

Ah. I do see Intel macOS is out of space now. Only checked Linux and ARM macOS.

[carlocab]

Still can't find unzip for some reason.

[Bo98]

it seems like the home directory is not currently nuked between CI runs

Until ephemeral, I'll cover this scenario with Homebrew/actions#262 (and I'll set GNUPGHOME in the workflow to somewhere in /tmp)

Still can't find unzip for some reason.

Hopefully fixed by Homebrew/brew#12947

[carlocab]

Let's run #96101 ASAP when this is merged, even if it entails premature removal of a CI-long-timeout label. The macOS bottles for texlive have linkage with Homebrew icu4c too (it's in the dep tree through harfbuzz).

[BrewTestBot]

@Bo98 has triggered a merge.

[BrewTestBot]

⚠️ @Bo98 bottle publish failed.

[carlocab]

error: gpg failed to sign the data
error: failed to write commit object

[Bo98]

That error basically means "gpg didn't exit successfully", which is always fun to debug as it means absolutely anything and it's not reproducible in a local Docker container.

[Bo98]

Oh of course, it'll be because brew env filters GNUPGHOME.

[BrewTestBot]

@Bo98 has triggered a merge.

[BrewTestBot]

⚠️ @Bo98 bottle publish failed.

[SMillerDev]

Error: Bottles are for tectonic 0.8.0_1 but formula is version 0.8.1_1!

[carlocab]

Error: Bottles are for tectonic 0.8.0_1 but formula is version 0.8.1_1!

😭

[carlocab]

I suggest a manual merge while dropping tectonic. Let's just rebuild it after.

[carlocab]

Attempting a manual merge. Downloading the bottles now. Will warn before I start an upload attempt.

[carlocab]

I decided to leave the download going overnight. It's finished now, but I'll be on the road so will try an upload when I have a stable connection.

[carlocab]

Attempting upload.

[carlocab]

Merge conflict for sile. Dropping.

[Bo98]

We need a better way to "lock" formula or whatever. A significant amount of the pain here is because of conflicts.

ICU 71 will probably be out next month, and I'm up for coordinating the revision bumps for that again, but I just can't monitor every single PR which comes in while the build is happening.

[Bo98]

Maybe CODEOWNERS is the solution here.

[carlocab]

We need a better way to "lock" formula or whatever. A significant amount of the pain here is because of conflicts.

ICU 71 will probably be out next month, and I'm up for coordinating the revision bumps for that again, but I just can't monitor every single PR which comes in while the build is happening.

Agreed. I tried to monitor PRs too, but I can't watch this repo 24/7 and tectonic and sile were merged while I was away.

Maybe CODEOWNERS is the solution here.

This sounds like a good idea, actually. Is there a way to make code owner review mandatory only for specific files?

[Bo98]

Is there a way to make code owner review mandatory only for specific files?

In terms of GitHub branch protection? No, but we could make pr-pull fail without a code owner review for any formula file - and allow that to be overridable by an argument (which can be passed to pr-publish too) for the "safe" periods.

[Bo98]

Or actually it maybe doesn't even need to be that complicated - it probably only needs to be on autopublish level

[carlocab]

Or actually it maybe doesn't even need to be that complicated - it probably only needs to be on autopublish level

If we could automatically label those PRs with do not merge too that might be useful, in case some maintainer wonders why a PR they approved hasn't been auto-merged and decides to pr-publish it.

The labelling has the bonus of already blocking autopublish.

[Bo98]

Makes sense. I would maybe lean on a separate red label just to make it more obvious to the PR author what's going on rather than getting a random "do not merge" label immediately.

[carlocab]

Makes sense. I would maybe lean on a separate red label just to make it more obvious to the PR author what's going on rather than getting a random "do not merge" label immediately.

Sure, I'm fine with that too.