[aur-general] State of community64
Hi, I would to bring to your attention the current state of the x86_64 community repo. There are currently over 100 x86_64 packages out-of-date compared to the i686 ones (http://dev.archlinux.org/~andyrtr/pkg_diff.html) . Out of curiosity, how many TUs with a x86_64 machine are active? More precisely, are you checking the package diff list on a more or less daily basis to keep the two repo in sync? I have the impression that I was pretty much the only one doing that in the last few months. To help keeping the x86_64 repo in sync, I would recommend any TU without an x86_64 machine to ask Aaron for access on his x86_64 build machine. I'm not sure to what degree the packages can be tested on the build machine but several devs and TU are already using it. Nonetheless, if the build machine would be used, at the very least, for arch-independent packages (e.g. i18n, docs pkg), perl and python modules and non-critical packages (e.g. games, xfce-svn plugin, etc) that would reduce the workload for the x86_64 TUs. I don't mind helping out with the occasional x86_64 build or with problems/bugs only on x86_64. But would like to reduce that to a minimum as it's quite time-consuming. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Jan 4, 2008 8:00 AM, Eric Belanger
Hi,
I would to bring to your attention the current state of the x86_64 community repo. There are currently over 100 x86_64 packages out-of-date compared to the i686 ones (http://dev.archlinux.org/~andyrtr/pkg_diff.htmlhttp://dev.archlinux.org/%7Eandyrtr/pkg_diff.html) . Out of curiosity, how many TUs with a x86_64 machine are active? More precisely, are you checking the package diff list on a more or less daily basis to keep the two repo in sync? I have the impression that I was pretty much the only one doing that in the last few months.
To help keeping the x86_64 repo in sync, I would recommend any TU without an x86_64 machine to ask Aaron for access on his x86_64 build machine. I'm not sure to what degree the packages can be tested on the build machine but several devs and TU are already using it. Nonetheless, if the build machine would be used, at the very least, for arch-independent packages (e.g. i18n, docs pkg), perl and python modules and non-critical packages (e.g. games, xfce-svn plugin, etc) that would reduce the workload for the x86_64 TUs.
I don't mind helping out with the occasional x86_64 build or with problems/bugs only on x86_64. But would like to reduce that to a minimum as it's quite time-consuming.
Eric
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Wow, Eric, I was about to type the exact same email. Thanks ! :) Varun
Eric Belanger a écrit :
Hi,
I would to bring to your attention the current state of the x86_64 community repo. There are currently over 100 x86_64 packages out-of-date compared to the i686 ones (http://dev.archlinux.org/~andyrtr/pkg_diff.html) . Out of curiosity, how many TUs with a x86_64 machine are active? More precisely, are you checking the package diff list on a more or less daily basis to keep the two repo in sync? I have the impression that I was pretty much the only one doing that in the last few months.
To help keeping the x86_64 repo in sync, I would recommend any TU without an x86_64 machine to ask Aaron for access on his x86_64 build machine. I'm not sure to what degree the packages can be tested on the build machine but several devs and TU are already using it. Nonetheless, if the build machine would be used, at the very least, for arch-independent packages (e.g. i18n, docs pkg), perl and python modules and non-critical packages (e.g. games, xfce-svn plugin, etc) that would reduce the workload for the x86_64 TUs.
I don't mind helping out with the occasional x86_64 build or with problems/bugs only on x86_64. But would like to reduce that to a minimum as it's quite time-consuming.
Eric
Hi Eric, First, with respect to your previous posting: I am sure all TUs will share my sentiment that you have done great work as a TU. So we all say thanks! As a relatively new TU who runs Arch32, I must confess I have until now relied on other TUs to bring my pkgs to community64. Now I decided it was time to ask Aaron for access to his x86_64 build machine, which I just did. Since I maintain numerous architecture-independant packages I have also decided to modify the makepkg and communitypkg scripts (which I saved as makepkg64 and communitypkg64) in order to generate and commit architecture-indenpendant pkgs for x86_64 on my i686 machine (this was quite a trivial thing to do). I have just tested it with ttf-linux-libertine and ttf-inconsolata in [community] and it seems my uploads and commits were successful (I'd be glad if someone could confirm this!). So at least for such cases I won't need to access Aaron's machine. My scripts are available under http://ankabut.net/archlinux/scripts-for-arch-indep-community64.zip -- MAKE SURE though to ONLY use them on arch-independant packages!!! ;) But I am really hoping to have a more flexible mechanism to handle non-binary packages with makepkg and pacman. There have been discussions about this in the past, namely to have the possibility to have arch=all in the PKGBUILDs, so that the generated packages can be commited for both i686 and x86_64 at the same time. Roman told me he add submitted a patch for pacman to precisely deal with this. I am looking forward to it. Best, F
Eric Belanger wrote:
Hi,
I would to bring to your attention the current state of the x86_64 community repo. There are currently over 100 x86_64 packages out-of-date compared to the i686 ones (http://dev.archlinux.org/~andyrtr/pkg_diff.html) . Out of curiosity, how many TUs with a x86_64 machine are active? More precisely, are you checking the package diff list on a more or less daily basis to keep the two repo in sync? I have the impression that I was pretty much the only one doing that in the last few months.
To help keeping the x86_64 repo in sync, I would recommend any TU without an x86_64 machine to ask Aaron for access on his x86_64 build machine. I'm not sure to what degree the packages can be tested on the build machine but several devs and TU are already using it. Nonetheless, if the build machine would be used, at the very least, for arch-independent packages (e.g. i18n, docs pkg), perl and python modules and non-critical packages (e.g. games, xfce-svn plugin, etc) that would reduce the workload for the x86_64 TUs.
I don't mind helping out with the occasional x86_64 build or with problems/bugs only on x86_64. But would like to reduce that to a minimum as it's quite time-consuming.
Eric
Although I am not a TU, I would be happy to help build these packages as I have an x86_64 machine. Once I have an updated PKGBUILD and binary package, what would be the best way for me to get them to into the right hands? -- Chess Griffin GPG Key: 0x0C7558C3 http://www.chessgriffin.com
On Fri, 2008-01-04 at 09:00 -0500, Chess Griffin wrote:
Although I am not a TU, I would be happy to help build these packages as I have an x86_64 machine. Once I have an updated PKGBUILD and binary package, what would be the best way for me to get them to into the right hands?
Hmm, are you interested in becoming a TU? I think that would be the most common practise. I'm not sure whether other TU take binary packages by mail and publish them.
Timm Preetz wrote:
On Fri, 2008-01-04 at 09:00 -0500, Chess Griffin wrote:
Although I am not a TU, I would be happy to help build these packages as I have an x86_64 machine. Once I have an updated PKGBUILD and binary package, what would be the best way for me to get them to into the right hands?
Hmm, are you interested in becoming a TU? I think that would be the most common practise.
Yes, most definitely. As I mentioned in my earlier introductory email, I've been packaging for other operating systems for awhile now, but would like to contribute to Arch. I have an x86_64 machine as well as several i686 machines. I've been lurking here for 3-4 years and have been building my own packages from time to time so I'm pretty comfortable with the process.
I'm not sure whether other TU take binary packages by mail and publish them.
I understand. I plan to adopt some orphaned PKGBUILDS in AUR, but in the meantime it seemed like there was a need and so I thought I would jump in and help. -- Chess Griffin GPG Key: 0x0C7558C3 http://www.chessgriffin.com
Timm Preetz wrote:
On Fri, 2008-01-04 at 09:00 -0500, Chess Griffin wrote:
Although I am not a TU, I would be happy to help build these packages as I have an x86_64 machine. Once I have an updated PKGBUILD and binary package, what would be the best way for me to get them to into the right hands?
Hmm, are you interested in becoming a TU? I think that would be the most common practise.
Yes, most definitely. As I mentioned in my earlier introductory email, I've been packaging for other operating systems for awhile now, but would like to contribute to Arch. I have an x86_64 machine as well as several i686 machines. I've been lurking here for 3-4 years and have been building my own packages from time to time so I'm pretty comfortable with the process.
I'm not sure whether other TU take binary packages by mail and publish them.
I understand. I plan to adopt some orphaned PKGBUILDS in AUR, but in the meantime it seemed like there was a need and so I thought I would jump in and help.
again we really appreciate that you want to help :). It is just we can't
It is really great to hear that you want to help out!
But as you mentioned you don't have any packages in the AUR. How do we know
you qualify for the job ? Did you do anything Arch related ? Do you have any
project you work on ?
Best would be to take a bunch of packages in the AUR and show that you are
capable of creating and maintaining packages.
On Jan 4, 2008 6:06 PM, Chess Griffin
Ronald van Haren wrote:
It is really great to hear that you want to help out! But as you mentioned you don't have any packages in the AUR. How do we know you qualify for the job ? Did you do anything Arch related ? Do you have any project you work on ?
I've been using Arch for maybe 3-4 years. No, I have not been involved in anything Arch related. Other projects include the Linux Reality podcast, the Slackware scripts I maintain for Slackbuilds.org, the patches I submit and the ports I maintain for FreeBSD, and the package I maintain in the Debian tree.
Best would be to take a bunch of packages in the AUR and show that you are capable of creating and maintaining packages.
Understood. I'll start with the AUR. Thanks, Chess -- Chess Griffin GPG Key: 0x0C7558C3 http://www.chessgriffin.com
Chess Griffin schrieb:
I understand. I plan to adopt some orphaned PKGBUILDS in AUR, but in the meantime it seemed like there was a need and so I thought I would jump in and help.
If you explain that you want to become a TU only to reduce the size of the difflist, then IMO it wouldn't be necessary to have many packages in AUR. That strongly depends on the TUs who are voting, but as the need of some x86_64 builders is huge, you should be able to convince them. Any opinions from TUs on this? (Note that I am not a TU anymore and thus my opinion doesn't really count when it comes to voting you in or not)
Timm Preetz wrote:
On Fri, 2008-01-04 at 12:06 -0500, Chess Griffin wrote:
Timm Preetz wrote:
Hmm, are you interested in becoming a TU? I think that would be the most common practise. Yes, most definitely.
Cool. So what are you waiting for, someone to sponsor you?
I'll work in the AUR for awhile and then seek out a sponsor. Thanks. -- Chess Griffin GPG Key: 0x0C7558C3 http://www.chessgriffin.com
On Fri, 4 Jan 2008, Chess Griffin wrote:
Timm Preetz wrote:
On Fri, 2008-01-04 at 12:06 -0500, Chess Griffin wrote:
Timm Preetz wrote:
Hmm, are you interested in becoming a TU? I think that would be the most common practise. Yes, most definitely.
Cool. So what are you waiting for, someone to sponsor you?
I'll work in the AUR for awhile and then seek out a sponsor.
Thanks.
You can still help out with the community repo if you're not a TU. You can check the community packages section of the bug tracker to see if you can't suggest/provide some fixes or patches. Some bugs might only affect the x86_64 package wich make them hard to fix if the maintainer don't have direct access to a x86_64 box. You can also browse the package diff list for packages that have been out of sync for x86_64 for a long time ( 1 month or more) or are not available for x86_64. Some of them might have just been forgotten or are i686 only binaries but there are a few that don't build or work on x86_64. If you can fix them, post the fixed PKGBUILD (and patch) on the bug tracker and they'll be be updated/added by someone (perhaps myself). This way you'll be able to help out with the community repo and it will give you an occasion to show your packaging skills when you'll apply to become a TU. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, 2008-01-03 at 21:30 -0500, Eric Belanger wrote:
I would to bring to your attention the current state of the x86_64 community repo. There are currently over 100 x86_64 packages out-of-date compared to the i686 ones (http://dev.archlinux.org/~andyrtr/pkg_diff.html) . Out of curiosity, how many TUs with a x86_64 machine are active? More precisely, are you checking the package diff list on a more or less daily basis to keep the two repo in sync? I have the impression that I was pretty much the only one doing that in the last few months.
I just became a TU and this is one main point I want to work on (as I currently have only one package in community myself). So expect some 64bit packages from me here.
On Jan 4, 2008 3:30 AM, Eric Belanger
Hi,
To help keeping the x86_64 repo in sync, I would recommend any TU without an x86_64 machine to ask Aaron for access on his x86_64 build machine. I'm not sure to what degree the packages can be tested on the build machine but several devs and TU are already using it. Nonetheless, if the build machine would be used, at the very least, for arch-independent packages (e.g. i18n, docs pkg), perl and python modules and non-critical packages (e.g. games, xfce-svn plugin, etc) that would reduce the workload for the x86_64 TUs.
Before I contact Aaron I would first like to get some things straight.
As I understand we have two options for arch INdependent packages. Either using Aaron's x86_64 build machine, or using the scripts ^^ from François. For arch dependent packages however we only can rely on Aaron's build machine. Now the big question is how reliable is the output for these packages, so the overall quality of the packages doesn't drop. How many people actually do use it, and do they find the output to be reliable ? Ronald
On Jan 4, 2008 11:52 AM, Ronald van Haren
Before I contact Aaron I would first like to get some things straight.
As I understand we have two options for arch INdependent packages. Either using Aaron's x86_64 build machine, or using the scripts ^^ from François. For arch dependent packages however we only can rely on Aaron's build machine. Now the big question is how reliable is the output for these packages, so the overall quality of the packages doesn't drop. How many people actually do use it, and do they find the output to be reliable ?
pacman and makepkg will, in the near future, support architecture-independent packages, so these scripts are more of a stop-gap measure However, this also depends on the maintainers of the backend scripts that run the community repo too, which will need modification
If a TU is unable to build for x86_64 for whatever reason, I don't think it should be a problem if any other TU who has access to an x86_64 machine helps out with the difflist. Architecture specific changes are just a " $CARCH = x86_64 " away, and this won't compromise the i686 build in anyway. When I build for community64, I usually don't contact the TU maintaing the i686 package unless there's some major change required in the package to build for both arches. I'm however uncomfortable building certain packages for community, especially since I don't know how to test them...this especially applies to community/lib and commuinty/devel. And when the difflist is huge, I tend to rush thru the building/testing process, and thats something which I don't like doing(like today, where I think I did ~30 packages). If more TU's could help out with this, the difflist would be smaller, and it really wouldn't matter if a handful of people don't have the time to build for x86_64. Varun
participants (8)
-
Aaron Griffin
-
Chess Griffin
-
Eric Belanger
-
Firmicus
-
Ronald van Haren
-
Thomas Bächler
-
Timm Preetz
-
Varun Acharya