msys2
[RFC] Dropping old msys/i686 packages from repo.msys2.org [edit:] sync instead
Context: Motivated by https://github.com/jeremyd2019/msys2-build32/issues/2#issuecomment-2170938529
We currently still have 32bit msys packages hosted on repo.msys2.rog: https://repo.msys2.org/msys/i686/
We dropped support for them 4 years ago, but updated them once more about 3 years ago based on jeremy's builds, to keep them somewhat usable.
Since @jeremyd2019 is still putting work into them and building all packages we could just remove our remaining packages and point to his repo instead:
- Check the logs if there are any users of those packages
- (optional) rename the dir to see if anyone complains
- Drop msys/i686 and the 32bit sfx/tarball
- Point users to https://github.com/jeremyd2019/msys2-installer/releases if they need 32bit still
I would have to adjust some scripts, currently I still have the i686 [msys] section in pacman.conf, but my new [build32] section is first, but that repo now has everything that the msys repo has so it'd just cause errors syncing.
My 'main' 32-bit tag of jeremyd2019/setup-msys2 uses the original 32-bit sfx and repos to install (and then I modify pacman.conf later on), so there will be some accesses from that. I also have another branch that uses my installer and build32 repo directly, and that would probably be a better choice to use moving forward - but I never switched on jeremyd2019/msys2-build32 because I want to exercise the update path.
I would have to adjust some scripts, currently I still have the i686
[msys]section in pacman.conf, but my new[build32]section is first, but that repo now has everything that the msys repo has so it'd just cause errors syncing.
I could leave an empty db there, if it helps.
Check the logs if there are any users of those packages
Here are the 32bit logs for last week, excluding cloud IP addresses (we had an outage, so it's not complete)
-------- ----------------------------------------------------------------------
Start 2024-06-12T12:25:36Z
End 2024-06-17T05:22:06Z
Requests 2480
Clients 122 (Clients are grouped by IP+WinVer+Arch, which is far from perfect)
-------- ----------------------------------------------------------------------
Repo Type % Requests Requests
--------- ------ ------------ ----------
msys/i686 pkg 100.00% 1936
Repo Type % Requests Requests
--------- ------ ------------ ----------
msys/i686 db 100.00% 544
Windows % Clients Clients % Requests Requests
--------- ----------- --------- ------------ ----------
10 53.28% 65 40.97% 1016
7 22.13% 27 24.72% 613
8.1 13.93% 17 1.41% 35
11 10.66% 13 32.90% 816
Win Ver Build Number % Clients Clients
--------- -------------- ----------- ---------
10 19045 33.61% 41
6.1 7601 22.13% 27
10 -1 16.39% 20
6.3 9600 13.93% 17
10 22631 7.38% 9
10 22621 3.28% 4
10 19042 0.82% 1
10 19041 0.82% 1
10 19044 0.82% 1
10 17763 0.82% 1
Pacman Ver % Clients Clients
------------ ----------- ---------
6.0.0 69.67% 85
5.1.1 13.93% 17
5.2.1 10.66% 13
5.0.1 2.46% 3
6.1.0 1.64% 2
5.2.2 0.82% 1
5.1.3 0.82% 1
Arch WOW64 % Clients Clients
------ ------- ----------- ---------
i686 True 60.66% 74
i686 False 39.34% 48
Filtering out WOW64, that makes 48 users, which is 0.1%:
-------- ---------------------------------------------------------------------
Start 2024-06-12T15:24:44Z
End 2024-06-17T05:22:06Z
Requests 431
Clients 48 (Clients are grouped by IP+WinVer+Arch, which is far from perfect)
-------- ---------------------------------------------------------------------
Repo Type % Requests Requests
--------- ------ ------------ ----------
msys/i686 pkg 100.00% 228
Repo Type % Requests Requests
--------- ------ ------------ ----------
msys/i686 db 100.00% 203
Windows % Clients Clients % Requests Requests
--------- ----------- --------- ------------ ----------
7 41.67% 20 71.23% 307
8.1 31.25% 15 7.19% 31
10 27.08% 13 21.58% 93
Win Ver Build Number % Clients Clients
--------- -------------- ----------- ---------
6.1 7601 41.67% 20
6.3 9600 31.25% 15
10 19045 20.83% 10
10 19042 2.08% 1
10 19041 2.08% 1
10 17763 2.08% 1
Pacman Ver % Clients Clients
------------ ----------- ---------
6.0.0 85.42% 41
5.2.1 12.50% 6
6.1.0 2.08% 1
Arch WOW64 % Clients Clients
------ ------- ----------- ---------
i686 False 100.00% 48
A reasonable question to ask is whether filtering out wow64 is a good assumption. 1) I build 32-bit packages on wow64, and 2) I think i686 on arm64 counts as wow64, but windows 10 could not run x86_64 binaries yet. This is actually the last remaining use case I have for i686 msys2, now that my 32-bit-UEFI tablet is dead. Either way, I suppose that's a negligible number of users in the scheme of things.
BTW, my plan for this has always been to stop building i686 packages when windows 10 goes out of support in October 2025. I also planned to leave packages at old versions if it became impossible to build newer versions for i686, but luckily everything has worked out so far except msys2-runtime and msys2-runtime-3.4. For a while doxygen was giving me address space trouble trying to build, but a subsequent update started working again.
Jinxed myself... aspell-de is giving me trouble now, for no apparent reason (the update was just to pkgver, the package itself hasn't changed).
For some reason, aspell 0.60.8-2-i686 works, and 0.60.8-3 and 0.60.8.1-1 crash building aspell-de. Rebuilding aspell 0.60.8.1 does not help. 0.60.8-3 was just a rebuild anyway.
I remember aspell crashes some time ago for 64bit. I don't remember what the issue was though. maybe it fixed itself or we got lucky.
I just built aspell-de with 0.60.0-2 for now. Nothing seems to depend on aspell except more aspell stuff anyway.
For the record, Git for Windows uses those packages and will need to continue supporting i686 builds until April 2029...
assuming you didn't mean aspell :grin:.... sorry to get off-topic there
so that kind of puts a wrench on that idea. What about lazka's original idea of doing another sync with my updated packages? Would that mess up Git for Windows somehow?
What about lazka's original idea of doing another sync with my updated packages? Would that mess up Git for Windows somehow?
I think this would most likely be beneficial to Git for Windows. Is there anything I can do to assist?
ok, I'll try another sync then some time. I don't think there is anything you can help with, thanks.
remember now to remove msys2-runtime-3.3{,-devel} from the 32-bit repos if/when you sync, in addition to anything not in the 64-bit repos.
oh, I see, the-32bit repo never had any packages removed it seems. Thanks, I'll try to diff them.
oh, I see, the-32bit repo never had any packages removed it seems. Thanks, I'll try to diff them.
Yeah, based on my original design of having build32 basically be an overlay on i686/msys, if I removed anything from it, it would just fall back to an even older version in i686/msys. At one point when you were talking about dropping i686/msys, I merged the latest versions of everything from i686/msys that was not in build32, so I could have changed to replacing i686/msys with build32, and could then have removed things from it, but I never got around to it because i686/msys was never dropped.
Sync is done, installer tarballs will follow tomorrow.
Please also do the .sfx.exe. That's what I use.
Yeah, based on my original design of having build32 basically be an overlay on i686/msys [...]
ah, right, makes sense.
Please also do the .sfx.exe. That's what I use.
sure, done
One difference I noticed is that autorebase is now required before the first start, as gpg fill fail otherwise. I think previously the initial setup worked without it.
One difference I noticed is that autorebase is now required before the first start, as gpg fill fail otherwise. I think previously the initial setup worked without it.
That's odd, I've built installers for i686 corresponding to the 64-bit installer releases, and I've not seen that with any of them. It'd be bad luck if it decided to fail like that right when you did a sync/new installer.
One difference I noticed is that autorebase is now required before the first start, as gpg fill fail otherwise. I think previously the initial setup worked without it.
works for ~me~ gha: https://github.com/jeremyd2019/setup-msys2/actions/runs/13227295124/job/36919801491
works for ~me~ gha: https://github.com/jeremyd2019/setup-msys2/actions/runs/13227295124/job/36919801491
only the gpg key refresh was failing (I assume dirmngr is the issue), which is skipped in setup-msys2
works for ~me~ gha: https://github.com/jeremyd2019/setup-msys2/actions/runs/13227295124/job/36919801491
only the gpg key refresh was failing (I assume dirmngr is the issue), which is skipped in setup-msys2
ok, yeah, I'm seeing that locally too. very strange, 2024-12-08 was working. even stranger is it seems to have started working partway through:
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: error retrieving '[email protected]' via WKD: No dirmngr
gpg: error reading key: No dirmngr
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: keyserver refresh failed: No dirmngr
==> ERROR: Could not update key: F40D263ECA25678A
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: error retrieving '[email protected]' via WKD: No dirmngr
gpg: error reading key: No dirmngr
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: keyserver refresh failed: No dirmngr
==> ERROR: Could not update key: 790AE56A1D3CFDDC
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: error retrieving '[email protected]' via WKD: No dirmngr
gpg: error reading key: No dirmngr
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: keyserver refresh failed: No dirmngr
==> ERROR: Could not update key: DA7EF2ABAEEA755C
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: error retrieving '[email protected]' via WKD: No dirmngr
gpg: error reading key: No dirmngr
gpg: error running '/usr/bin/dirmngr': exit status 2
gpg: failed to start dirmngr '/usr/bin/dirmngr': General error
gpg: can't connect to the dirmngr: General error
gpg: keyserver refresh failed: No dirmngr
==> ERROR: Could not update key: 755B8182ACD22879
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key 9F418C233E652008: "Ignacio Casal Quinteiro <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key BBE514E53E0D0813: "Ray Donnelly (MSYS2 Developer - master key) <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key 5F92EFC1A47D45A1: "Alexey Pavlov (Alexpux) <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key 974C8BE49078F532: "David Macek <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key FA11531AA0AA7F57: "Christoph Reiter (MSYS2 development key) <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: Try again later
gpg: error reading key: Try again later
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key 794DCF97F93FC717: "Martell Malone (martell) <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key D595C9AB2C51581E: "Martell Malone (MSYS2 Developer) <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: error retrieving '[email protected]' via WKD: No data
gpg: error reading key: No data
gpg: refreshing 1 key from hkps://keyserver.ubuntu.com
gpg: key 4DF3B7664CA56930: "Ray Donnelly (MSYS2 Developer) <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
Initial setup complete. MSYS2 is now ready to use.
relevant overlaps for dirmngr:
/usr/bin/msys-gnutls-30.dll base 0x61e40000 size 0x001de000 *
/usr/bin/msys-intl-8.dll base 0x62000000 size 0x00024000 *
/usr/bin/msys-unistring-5.dll base 0x63d40000 size 0x00205000 *
/usr/bin/msys-gmp-10.dll base 0x63d80000 size 0x00088000 *
yeah, that would help. probably remove the rebase db after though
yeah, that would help. probably remove the rebase db after though
I'm a bit out of the loop re rebase: why remove it?
Wouldn't it make sense to keep it to also make the install hook work out of the box?
:: Running post-transaction hooks...
(1/1) Rebasing DLLs
rebase: failed to open rebase database "/etc/rebase.db.i386":
No such file or directory
error: command failed to execute correctly
ok, I just put up a new release
edit: here was my script to sync btw: https://github.com/msys2/msys2-devtools/commit/8ff47b78e826e967df8f0bfd1cb0c1115fad02cb
I guess this is done now.
If there are any more syncs needed in the future, let me know.