On Sat, Jan 29, 2022 at 10:53:41PM +1000, Allan McRae via arch-dev-public wrote:
On 29/1/22 22:11, Morten Linderud via arch-dev-public wrote:
On Sat, Jan 29, 2022 at 11:45:57AM +1000, Allan McRae via arch-dev-public wrote:
On 29/1/22 11:28, Morten Linderud via arch-dev-public wrote:
On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via arch-dev-public wrote:
On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via arch-dev-public wrote: > Is there any particular objection to requiring packagers upload both > architectures?
I'm personally not really motivated doing the required builds. We have an underdeveloped infrastructure which hasn't changed since we abandoned i686 5 years ago.
I'd personally like to see more work on our build tooling before we commit to new architectures.
FYI, it is a single extra command. Either of these will work...
offload-build --arch x86_64_v3 extra-x86_64_v3-build
Nothing else changes for the packager.
Allan
I'll spend twice as long waiting for a package to build which increases the time spent packaging. Which again requires me to spend more time watching stuff fly by.
I have concerns if that is how you spend your time... :)
I have plenty time left over to ask for pacman backports :) DO NOT WORRY!
This also assumes people are capable of using the buildserver which is not always the case either.
This wasn't great with i686, and I'm not sure why we'd find this acceptable today?
What was not great with i686? We managed two architectures for many, many years. The reason for removing i686 was to do with outdated technology, not to do with build times or infrastructure.
Do you have objections beyond not wanting to package for both repos? i.e. do you object to option C in my original email, where we have a team to keep the repos in sync when package maintainers do not build both?
I'm simply not sure where you are going to get the people for that and how you want to deal with it?
There is community demand for this port - it will provide benefit for the majority of our users. I'm sure I can find interested parties to join.
A *lot* has changed since the x86_64 port. Bringing on people to do these rebuild implies they need access to infrastructure, keyring and so on. And we already have a staff shortage.
I'd like to see some details on how you envision C should be working first.
Exactly the same as it did in the i686/x86_64 days. Some packagers will upload both variants, some will not. There was a webpage that showed the package differences between the architectures and a group of people built and uploaded packages to keep x86_64 in sync. This was particularly important when many devs did not have x86_64 hardware yet.
We may/will need to recruit some people to do these rebuilds. The number of people needed depends on how many packagers would package for both architectures.
This doesn't explain what I wanted to know though. Are you expecting we find 5-10-20 people and then onboard them as developers or TUs? Are you envioning a seperate signing keyring, or are you planning on adding them to the archlinux-keyring? How are we dealing with access? Do they get full access to our package repos as devs, or are you planning on a seperate role which has access to the required repositories? This is relevant because of how dbscripts is deployed on gemini. All of this requires a fair bit of planning and thought before it's a feasable option to mention. -- Morten Linderud PGP: 9C02FF419FECBE16