Open lazka opened 3 weeks ago
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.
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: