On Wed, 12 Jul 2006 09:20:32 +0300 Blum 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

On Tue, 11 Jul 2006 14:22:33 -0400 Michael McCaskill 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

Blum wrote:

On Tuesday 11 July 2006 21:49, Jason Chu wrote:

...

On Tue, 11 Jul 2006 14:22:33 -0400

Michael McCaskill 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

On Tue, 18 Jul 2006 16:15:14 +0300 Blum wrote:

On Tuesday 11 July 2006 21:49, Jason Chu wrote:

...

On Tue, 11 Jul 2006 14:22:33 -0400

Michael McCaskill 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

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 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

On Wed, 12 Jul 2006, Andreas Radke wrote:

Am Wed, 12 Jul 2006 15:07:44 -0400 schrieb "Robert Howard" :

...

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.

On Wed, 12 Jul 2006 21:56:48 +0200 Andreas Radke wrote:

Am Wed, 12 Jul 2006 15:28:32 -0400 (EDT) schrieb Eric Belanger :

...

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

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

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 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

On Thu, 13 Jul 2006 20:27:07 +0530 Varun Acharya 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

On Thu, 13 Jul 2006 10:04:19 -0400 "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?

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