[arch-ports] [x86_64] wanted: PCs for our pacbuild build farm
Now that the x86_64 port is official we want to make it as good as ArchLinux (i686). You may have noticed that I'm doing most time a one-man-job. And that's now too much work for one person to keep all packages up to date in an acceptable time. Great news: i686 devs and also TUs want to help us. They offer their time to build the packages they maintain for a second time. What we need: a build farm running several machines Arch64. We will use pacbuild. The great distributed package building tool from Xentac. Read here more about it: http://wiki.archlinux.org/index.php/Pacbuild and http://xentac.net/~jchu/blog/static/pacbuild i686 package maintainers and TrustedUsers will get accounts to sent pkgbuilds to the farm. The main server will send it further to a pc running the local build daemon. The more pcs we have running Arch64 with pacbuild daemon the lower the load will be. Who can offer his pc for running the pacbuild daemon? What you need: just a clean(!) Arch64 installation for correct linking. So there should be only official packages from current/extra and later community on it. A separate system would be nice but is not a must. Don't be afraid. There's no need to have a ssh deamon running. The system should be online most time. 24/7 up would be great. I will also offer one or two systems. We will test the configuration. It would be great to have more systems later running the build daemon so the nice load would get much lower. So who will join the packaging party? AndyRTR
On Tue, 11 Jul 2006 19:47:23 +0200 Andreas Radke <a.radke@arcor.de> wrote:
Now that the x86_64 port is official we want to make it as good as ArchLinux (i686). You may have noticed that I'm doing most time a one-man-job. And that's now too much work for one person to keep all packages up to date in an acceptable time.
Great news: i686 devs and also TUs want to help us. They offer their time to build the packages they maintain for a second time.
What we need: a build farm running several machines Arch64.
We will use pacbuild. The great distributed package building tool from Xentac. Read here more about it:
http://wiki.archlinux.org/index.php/Pacbuild and http://xentac.net/~jchu/blog/static/pacbuild
i686 package maintainers and TrustedUsers will get accounts to sent pkgbuilds to the farm. The main server will send it further to a pc running the local build daemon. The more pcs we have running Arch64 with pacbuild daemon the lower the load will be.
Who can offer his pc for running the pacbuild daemon? What you need: just a clean(!) Arch64 installation for correct linking. So there should be only official packages from current/extra and later community on it. A separate system would be nice but is not a must.
Actually, a clean system is barely needed. Because the build daemon actually creates its own build chroot. Jason
On Tuesday 11 July 2006 21:16, Jason Chu wrote:
On Tue, 11 Jul 2006 19:47:23 +0200
Andreas Radke <a.radke@arcor.de> wrote:
Now that the x86_64 port is official we want to make it as good as ArchLinux (i686). You may have noticed that I'm doing most time a one-man-job. And that's now too much work for one person to keep all packages up to date in an acceptable time.
Great news: i686 devs and also TUs want to help us. They offer their time to build the packages they maintain for a second time.
What we need: a build farm running several machines Arch64.
We will use pacbuild. The great distributed package building tool from Xentac. Read here more about it:
http://wiki.archlinux.org/index.php/Pacbuild and http://xentac.net/~jchu/blog/static/pacbuild
i686 package maintainers and TrustedUsers will get accounts to sent pkgbuilds to the farm. The main server will send it further to a pc running the local build daemon. The more pcs we have running Arch64 with pacbuild daemon the lower the load will be.
Who can offer his pc for running the pacbuild daemon? What you need: just a clean(!) Arch64 installation for correct linking. So there should be only official packages from current/extra and later community on it. A separate system would be nice but is not a must.
Actually, a clean system is barely needed. Because the build daemon actually creates its own build chroot.
Jason
I think I can help, I have a machine x86_64 24/7 uptime online and running arch. But tell me, what exactly means 'clean' system?
On Wed, 12 Jul 2006 09:20:32 +0300 Blum <blum@drundrun.org> wrote:
Actually, a clean system is barely needed. Because the build daemon actually creates its own build chroot.
Jason
I think I can help, I have a machine x86_64 24/7 uptime online and running arch. But tell me, what exactly means 'clean' system?
What Andy means by a clean system is one where you haven't installed a lot of custom packages or programs. That it'd be pretty easy to re-create your system with an install cd and a bunch of pacman commands. But, like I said, it really doesn't matter. Jason
Andreas Radke wrote:
Now that the x86_64 port is official we want to make it as good as ArchLinux (i686). You may have noticed that I'm doing most time a one-man-job. And that's now too much work for one person to keep all packages up to date in an acceptable time.
Great news: i686 devs and also TUs want to help us. They offer their time to build the packages they maintain for a second time.
What we need: a build farm running several machines Arch64.
We will use pacbuild. The great distributed package building tool from Xentac. Read here more about it:
http://wiki.archlinux.org/index.php/Pacbuild and http://xentac.net/~jchu/blog/static/pacbuild
i686 package maintainers and TrustedUsers will get accounts to sent pkgbuilds to the farm. The main server will send it further to a pc running the local build daemon. The more pcs we have running Arch64 with pacbuild daemon the lower the load will be.
Who can offer his pc for running the pacbuild daemon? What you need: just a clean(!) Arch64 installation for correct linking. So there should be only official packages from current/extra and later community on it. A separate system would be nice but is not a must.
Don't be afraid. There's no need to have a ssh deamon running. The system should be online most time. 24/7 up would be great.
I will also offer one or two systems. We will test the configuration.
It would be great to have more systems later running the build daemon so the nice load would get much lower.
So who will join the packaging party?
AndyRTR
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Excellent. I will install pacbuild when I get home. I'm behind a home firewall. Do I need to open any ports?
On Tue, 11 Jul 2006 14:22:33 -0400 Michael McCaskill <mmccaskill@nc.rr.com> wrote:
Excellent. I will install pacbuild when I get home. I'm behind a home firewall. Do I need to open any ports?
Nope, your build machine does all the talking to the server. If you can build regular packages, you can use pacbuild. Jason
On Tuesday 11 July 2006 21:49, Jason Chu wrote:
On Tue, 11 Jul 2006 14:22:33 -0400
Michael McCaskill <mmccaskill@nc.rr.com> wrote:
Excellent. I will install pacbuild when I get home. I'm behind a home firewall. Do I need to open any ports?
Nope, your build machine does all the talking to the server. If you can build regular packages, you can use pacbuild.
Jason
Is it any way to know if the strawberry daemon is working properly? Log, web report or something... I have it started, but for today there is no activity. Maybe there is no packages for building now or it's not logged in.. or there is something wrong? I guess i need some feedback :) Blum
Blum wrote:
On Tuesday 11 July 2006 21:49, Jason Chu wrote:
On Tue, 11 Jul 2006 14:22:33 -0400
Michael McCaskill <mmccaskill@nc.rr.com> wrote:
Excellent. I will install pacbuild when I get home. I'm behind a home firewall. Do I need to open any ports?
Nope, your build machine does all the talking to the server. If you can build regular packages, you can use pacbuild.
Jason
Is it any way to know if the strawberry daemon is working properly? Log, web report or something... I have it started, but for today there is no activity. Maybe there is no packages for building now or it's not logged in.. or there is something wrong? I guess i need some feedback :)
Blum
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
I have the exact same question. ganja_guru
Is it any way to know if the strawberry daemon is working properly? Log, web report or something... I have it started, but for today there is no activity. Maybe there is no packages for building now or it's not logged in.. or there is something wrong? I guess i need some feedback :)
Blum
There's a webinterface for monitoring peach but not for strawberry. As I told you we are still not using it. Just preparing it. You will notice it one day when your hard disc led starts flashing. We will inform you all when it starts. Stay cool. AndyRTR
On Tue, 18 Jul 2006 16:15:14 +0300 Blum <blum@drundrun.org> wrote:
On Tuesday 11 July 2006 21:49, Jason Chu wrote:
On Tue, 11 Jul 2006 14:22:33 -0400
Michael McCaskill <mmccaskill@nc.rr.com> wrote:
Excellent. I will install pacbuild when I get home. I'm behind a home firewall. Do I need to open any ports?
Nope, your build machine does all the talking to the server. If you can build regular packages, you can use pacbuild.
Jason
Is it any way to know if the strawberry daemon is working properly? Log, web report or something... I have it started, but for today there is no activity. Maybe there is no packages for building now or it's not logged in.. or there is something wrong? I guess i need some feedback :)
Blum
When I release 0.4 it will have logging and a web report of the whole build daemon. I've been testing it because I bought an x86_64 just for use as a build daemon. You'll see some packages going through here and there, but not too much. Jason
Andreas Radke wrote:
Now that the x86_64 port is official we want to make it as good as ArchLinux (i686). You may have noticed that I'm doing most time a one-man-job. And that's now too much work for one person to keep all packages up to date in an acceptable time.
Great news: i686 devs and also TUs want to help us. They offer their time to build the packages they maintain for a second time.
What we need: a build farm running several machines Arch64.
We will use pacbuild. The great distributed package building tool from Xentac. Read here more about it:
http://wiki.archlinux.org/index.php/Pacbuild and http://xentac.net/~jchu/blog/static/pacbuild
i686 package maintainers and TrustedUsers will get accounts to sent pkgbuilds to the farm. The main server will send it further to a pc running the local build daemon. The more pcs we have running Arch64 with pacbuild daemon the lower the load will be.
Who can offer his pc for running the pacbuild daemon? What you need: just a clean(!) Arch64 installation for correct linking. So there should be only official packages from current/extra and later community on it. A separate system would be nice but is not a must.
Don't be afraid. There's no need to have a ssh deamon running. The system should be online most time. 24/7 up would be great.
I will also offer one or two systems. We will test the configuration.
It would be great to have more systems later running the build daemon so the nice load would get much lower.
So who will join the packaging party?
AndyRTR
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Count me in. ganja_guru
What about kernels? I'm running Arch64, but I've built a custom kernel. This would seem to be an issue if compiling kernel modules? On 7/12/06, Varun Acharya <ganja.guru.x64@gmail.com> wrote:
Andreas Radke wrote:
Now that the x86_64 port is official we want to make it as good as ArchLinux (i686). You may have noticed that I'm doing most time a one-man-job. And that's now too much work for one person to keep all packages up to date in an acceptable time.
Great news: i686 devs and also TUs want to help us. They offer their time to build the packages they maintain for a second time.
What we need: a build farm running several machines Arch64.
We will use pacbuild. The great distributed package building tool from Xentac. Read here more about it:
http://wiki.archlinux.org/index.php/Pacbuild and http://xentac.net/~jchu/blog/static/pacbuild
i686 package maintainers and TrustedUsers will get accounts to sent pkgbuilds to the farm. The main server will send it further to a pc running the local build daemon. The more pcs we have running Arch64 with pacbuild daemon the lower the load will be.
Who can offer his pc for running the pacbuild daemon? What you need: just a clean(!) Arch64 installation for correct linking. So there should be only official packages from current/extra and later community on it. A separate system would be nice but is not a must.
Don't be afraid. There's no need to have a ssh deamon running. The system should be online most time. 24/7 up would be great.
I will also offer one or two systems. We will test the configuration.
It would be great to have more systems later running the build daemon so the nice load would get much lower.
So who will join the packaging party?
AndyRTR
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Count me in.
ganja_guru
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Am Wed, 12 Jul 2006 15:07:44 -0400 schrieb "Robert Howard" <howard.rob@gmail.com>:
What about kernels? I'm running Arch64, but I've built a custom kernel. This would seem to be an issue if compiling kernel modules?
building packages running a custom kernel shouldn't make the package different. should be ok. andyrtr
On Wed, 12 Jul 2006, Andreas Radke wrote:
Am Wed, 12 Jul 2006 15:07:44 -0400 schrieb "Robert Howard" <howard.rob@gmail.com>:
What about kernels? I'm running Arch64, but I've built a custom kernel. This would seem to be an issue if compiling kernel modules?
building packages running a custom kernel shouldn't make the package different. should be ok.
That is not true for kernel modules. If the farm contains machines running the stock vanilla and beyond kernels, then it might be possible for the build script to chose these machines to compile the packages containing modules. If that is too difficult to implement, these packages could be compiled the "old-fashion" way by a person who has a 64bit machine, i.e. not using the build farm. Snowman
andyrtr
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Wed, 12 Jul 2006 15:28:32 -0400 (EDT) schrieb Eric Belanger <belanger@ASTRO.UMontreal.CA>:
That is not true for kernel modules. If the farm contains machines running the stock vanilla and beyond kernels, then it might be possible for the build script to chose these machines to compile the packages containing modules. If that is too difficult to implement, these packages could be compiled the "old-fashion" way by a person who has a 64bit machine, i.e. not using the build farm.
Snowman
Not needed. If kernel26 or kernel26-beyond are in makedepends pacbuild will install them. Anyway they should be installed. But it's not a must to have them booted. andyrtr
On Wed, 12 Jul 2006 21:56:48 +0200 Andreas Radke <a.radke@arcor.de> wrote:
Am Wed, 12 Jul 2006 15:28:32 -0400 (EDT) schrieb Eric Belanger <belanger@ASTRO.UMontreal.CA>:
That is not true for kernel modules. If the farm contains machines running the stock vanilla and beyond kernels, then it might be possible for the build script to chose these machines to compile the packages containing modules. If that is too difficult to implement, these packages could be compiled the "old-fashion" way by a person who has a 64bit machine, i.e. not using the build farm.
Snowman
Not needed. If kernel26 or kernel26-beyond are in makedepends pacbuild will install them. Anyway they should be installed. But it's not a must to have them booted.
andyrtr
You don't even have to have them installed on the system. Pacbuild will install them in the chroot when it needs them (because packages have makedepends on them). Jason
Great. I'll look into the possibility of adding my machine to the farm. Now, does pacbuild require a separate partition for the chroot or can it just dump the necessary files into a directory? On 7/12/06, Jason Chu <jason@archlinux.org> wrote:
On Wed, 12 Jul 2006 21:56:48 +0200 Andreas Radke <a.radke@arcor.de> wrote:
Am Wed, 12 Jul 2006 15:28:32 -0400 (EDT) schrieb Eric Belanger <belanger@ASTRO.UMontreal.CA>:
That is not true for kernel modules. If the farm contains machines running the stock vanilla and beyond kernels, then it might be possible for the build script to chose these machines to compile the packages containing modules. If that is too difficult to implement, these packages could be compiled the "old-fashion" way by a person who has a 64bit machine, i.e. not using the build farm.
Snowman
Not needed. If kernel26 or kernel26-beyond are in makedepends pacbuild will install them. Anyway they should be installed. But it's not a must to have them booted.
andyrtr
You don't even have to have them installed on the system. Pacbuild will install them in the chroot when it needs them (because packages have makedepends on them).
Jason
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
I think we were both using XFS at the time. Anyway like Jason says, small size differences don't really matter. ganja_guru ------------------------------------------------------------------
No raid here but maybe different filesystems. So our systems may use various numbers of blocks to store the same file. Not sure.
Andy
I'm not too sure of this Andy. Remember a while back, when I was running a custom kernel, we tested out some packages for size and ours always differed by a couple of bytes? Both packages worked but we couldn't figure out why the file sizes were slightly different. ganja_guru
building packages running a custom kernel shouldn't make the package different. should be ok.
andyrtr
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Were you both using identical hardware? CPUs? Compiler flags? This may seem like an obvious line of questioning, but I've found that it always isn't. Anyway, assuming that pacbuid is using a chroot for all the builds, it should work independently of the currently running kernel and for that matter, the currently running system. That said, what if a makefile tries to use the current kernel version (uname -r) for something? Does pacbuild have facilities for dealing with this sort of problem? On 7/13/06, Varun Acharya <ganja.guru.x64@gmail.com> wrote:
I'm not too sure of this Andy. Remember a while back, when I was running a custom kernel, we tested out some packages for size and ours always differed by a couple of bytes? Both packages worked but we couldn't figure out why the file sizes were slightly different.
ganja_guru
building packages running a custom kernel shouldn't make the package different. should be ok.
andyrtr
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
AFAIK, Andy was using Dual Opteron's and I was using an FX-55. Compiler flags were identical. Hardware differed slightly, I was using HW RAID, I'm not sure if Andy was using RAID or not. ganja_guru Robert Howard wrote:
Were you both using identical hardware? CPUs? Compiler flags? This may seem like an obvious line of questioning, but I've found that it always isn't.
Anyway, assuming that pacbuid is using a chroot for all the builds, it should work independently of the currently running kernel and for that matter, the currently running system. That said, what if a makefile tries to use the current kernel version (uname -r) for something? Does pacbuild have facilities for dealing with this sort of problem?
On Thu, 13 Jul 2006 20:27:07 +0530 Varun Acharya <ganja.guru.x64@gmail.com> wrote:
AFAIK, Andy was using Dual Opteron's and I was using an FX-55. Compiler flags were identical. Hardware differed slightly, I was using HW RAID, I'm not sure if Andy was using RAID or not.
ganja_guru
Be aware that two identical builds even on the same machine will differ slightly. Things like modified dates will always be different (unless this exact machine can have exactly the same state over both builds). Even just taking modified dates into account, you could get packages of different sizes. Jason
Am Thu, 13 Jul 2006 20:27:07 +0530 schrieb Varun Acharya <ganja.guru.x64@gmail.com>:
AFAIK, Andy was using Dual Opteron's and I was using an FX-55. Compiler flags were identical. Hardware differed slightly, I was using HW RAID, I'm not sure if Andy was using RAID or not.
ganja_guru
Robert Howard wrote:
Were you both using identical hardware? CPUs? Compiler flags? This may seem like an obvious line of questioning, but I've found that it always isn't.
Anyway, assuming that pacbuid is using a chroot for all the builds, it should work independently of the currently running kernel and for that matter, the currently running system. That said, what if a makefile tries to use the current kernel version (uname -r) for something? Does pacbuild have facilities for dealing with this sort of problem?
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
No raid here but maybe different filesystems. So our systems may use various numbers of blocks to store the same file. Not sure. Andy
On Thu, 13 Jul 2006 10:04:19 -0400 "Robert Howard" <howard.rob@gmail.com> wrote:
Were you both using identical hardware? CPUs? Compiler flags? This may seem like an obvious line of questioning, but I've found that it always isn't.
Anyway, assuming that pacbuid is using a chroot for all the builds, it should work independently of the currently running kernel and for that matter, the currently running system. That said, what if a makefile tries to use the current kernel version (uname -r) for something? Does pacbuild have facilities for dealing with this sort of problem?
Pacbuild can't directly deal with this problem. Strictly speaking, it wasn't a very good idea when it was thought of, so pacbuild doesn't try to fix it. Instead, you just tell the person who wrote the package to fix it ;) Jason
participants (7)
-
Andreas Radke
-
Blum
-
Eric Belanger
-
Jason Chu
-
Michael McCaskill
-
Robert Howard
-
Varun Acharya