On Sat, Apr 26, 2008 at 3:14 PM, Allan McRae
Hi TUs,
I know I keep on about this but I just had a look at the pkg_diff page [1] and I noticed there has been a big increase in the number of differences between the i686 and x86_64 community repos. To put some numbers to this, since the 17th there has been 11 packages added to i686 but not x86_64 and another 29 packages have been updated in i686 but not x86_64. We are now up to 190 differences between the architectures. Taking away the lib32 packages and the known build failures [2] leaves about 80 differences that can be fixed. That is about double the amount in the extra repo and it has more packages in total...
How do we fix this? Here is what I propose:
1. If you add a new package to community and can only build for one repo then you must post a message to the list asking for someone to build it for the other. I.e. if you are bringing the package to community, then you are responsible for getting it in both arches.
By now everyone should be able to use Aaron's build machine. Only for large package groups it does not work out, and a separate builder must be found. Not building packages for both architectures is just plain lazy (at least for new packages). For packages already in community I can understand I can understand people have some time constraints. Maybe for them it is better to drop some packages to unsupported or give the maintainership over to another TU. That said, I think sometimes you guys build the x86_64 package too fast (well in a way it does increase your workload where it is not needed). For example, last 1.5 day I was not able to connect to the build box, but now I can again I see the package has already been build. Well, most likely these things don't happen very often so it should not be that big of a deal.
2. Everyone who does not have access to a x86_64 machine, should get access to the build machine by contacting Aaron.
Yes they should. I'm thinking about filing a feature request for the build box. AFAIK it is not possible to upload packages directly into community from within the build box, having to move the package back to my own box and upload it from there. Is that true or am I missing something obvious?
3. If it is inconvenient to build x86_64 packages on the build box (e.g. because of having to wait on deps to sync) then you should arrange with one of the x86_64 using TU's to do the building for you.
see my point at 1
What do TU's think about these ideas? I'd like to get some official guidelines out there so I can prod consistent offenders (you know who you are....)!
I think I most likely will support your guidelines. I would say create a new (separate) version of the guidelines (http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines), adjust it as you think it should be and organize a vote (really I'm not all that for voting but that is the only way the new guidelines must be followed). Ronald ps. When counting the diffs I hope you don't count the e17 packages (because those are cvs versions and will most likely never be build on the same day as they are not build by the same person). Flock also has no sources released after the 1.1.1 release, whereas binaries are released up until 1.1.3. pss. A couple of days ago I did build pcmanx-gtk2 for Shinlun on i686, but I failed on the build machine. Asked two times if a x86_64 TU could take a look at it but I've never seen any response, nor is the package updated.