- Arch-ports - lists.archlinux.org

[arch-ports] Rsync Problem
by Alexander Baldeck 22 Sep '05

22 Sep '05

Hey, I know it's someone in here: c-24-147-98-103.hsd1.ma.comcast.net (24.147.98.103) Please make you rsyn settings a bit more log friendly, as it seems your sync touches all packages not only the changes. ;-) Thank you! Best regards, -kth5

2 1

[arch-ports] 32bit support
by seshu yamajala 20 Sep '05

20 Sep '05

I have found a much better solution for the 32bit backwards compatibility issue. After looking at how debian does things, i have found that for 32bit support they setup a chroot. I thought about this, and it seems like an excellent idea. It will save a lot of time, and it addresses the problem of installing 2 versions of the same package. dchroot could be used to make the chroot almost transparent to the user. The existing 32bit arch packages could be used as well. Since i have not started working the multilib support, this will probably be implemented instead. For more info on the chroot method look here: https://alioth.debian.org/docman/view.php/ 30192/21/debian-amd64-howto.html#id271960 Also I would like to mention that vitorlima has joined the project and has already made great contributions! - syamajala

2 2

[arch-ports] Do you need any help with Arch64
by Mr Green 10 Sep '05

10 Sep '05

Hi, If you need any help please let me know ..... Mr Green Arch64 User

1 0

[arch-ports] New PPC Mirror
by Alexander Baldeck 03 Sep '05

03 Sep '05

Hey List, just underwent the hassle to finally set up my very own server for to mirror the ppc packages. Feel free to give it a shot: [current] Server = http://kleiner-weise.de/~kth5/archlinux/current/os/ppc [testing] Server = http://kleiner-weise.de/~kth5/archlinux/testing/os/ppc Additionally everyone who rsyncs the packages should start to use this machine instead as well: rsync kleiner-weise.de::archppc-current/ rsync kleiner-weise.de::archppc-testing/ Extra will not be mirrored since it is *NOT* maintained at the moment! regards, -kth5

2 2

[arch-ports] x86_64 update
by Seshu Yamajala 03 Sep '05

03 Sep '05

ok, its been a while since i have actually done some work on the port. Today I grabbed the latest pkgbuilds from testing, current, extra, and started working on gcc 4. The packages will now support the emt64 and amd64 chips. I have also decided that 32bit support will be included in the base install. This make life much easier for me and anyone else who decides to help out. Many things like the ati drivers, grub, opera, and openoffice 1 will only work with 32bit "stuff" installed. Also i am gonna start a subversion repo soon and put pkgbuilds up. Xentac knows how i was doing things before. I had managed 2 dirs. one where development occured (packages were built there, pkgbuilds were edited...) and one where the final pkgbuild for the package was kept. It worked fine for me, but people weren't able to see the pkgbuilds or get them from me unless i put them on my web server. Since cvsup is still messed up on x86_64 i'm gonna go with subversion. I have no experience in these thi ngs (subversion, cvs, ...), so if i shouldn't use subversion or something please tell me. - Seshu Yamajala (syamajala)

2 1

[arch-ports] pacbuild status and design
by Jason Chu 31 Aug '05

31 Aug '05

First I'll go over the basic design of pacbuild, then I'll highlight how far I am, and then I'll explain the the problems I see so far. My original goal with pacbuild was to write a program that would scan abs for package discrepencies between different architecture's repos (well, between i686 and everything else), build the new package for that architecture, and stick it in the appropriate repo. I broke the design into four pieces: peach, cherry, strawberry, and waka. Peach is the web interface for package validation. Cherry is the main build manager, it scans the abs repo, queues packages, sends them to remote strawberry instances, sets them to be validated, and adds them to the repo after validation. Strawberry runs on each remote build machine. It gets builds from cherry and sends them to waka to be built. Waka takes a source package (I can explain this later if needed), builds it in a clean chroot, and spits out a binary package. Currently cherry does everything up to the validation part and strawberry and waka are complete. Peach is still but a twinkle in my eye. Now the fun part: problems. I started pacbuild for i586. It worked really well, because packages are very rarely modified from i686 to i586. There was no real need for a cvsup tree and whatnot. I also designed cherry to do too much. I should probably make another one or two daemons in there. One, at least, to scan the repos and queue packages. That way cherry can just worry about managing all the remote builds. The other daemon would be for putting the packages back into the repos. The only reason I would develop this seperately is then we could use it for i686 as well. The way pacbuild was designed originally, it needed the single-PKGBUILD-for-all-architectures method. It depended on all PKGBUILDs working for all architectures and tried to build them for all architectures without those architecture developers even having looked at an update. This way architecture developers become more of a manager than an active maintainer. The problem here is that each architecture's version of a package (if the newer version isn't in the ppc repo, for example) isn't accessible in abs. To do the abs thing for each individual architecture, we need to tag them at the very least (have seperate repos at the most). Tagging them pretty much means they'd need someone looking at them. It's possible that the build script could tag all the ones that were verified, but developers would still need to fix problems that showed up and tag those. As far as I know, Debian does it with one source package for many architectures. They also have different source sharing methods (I don't know exactly how they work). Frugalware does it with multiple repos, I believe. Gentoo has people sign off on each package on each architecture, but they sort of have to in gentoo... Comments? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.

3 3

[arch-ports] PPC Port Developer List Reset
by Alexander Baldeck 23 Aug '05

23 Aug '05

Hey List, I am going to wipe all currently registered SVN accounts from the PPC repo in the next few days, as most people haven't done a thing yet or at least didn't seem to. However, I'm open for new devs so feel free to contact me. Also I need to have at least one other dev who will be able to manage the whole thing while I am unavailable. This actually happens quite often, since I travel a lot and might not get the chance to hook up with the internet. regards, -kth5

1 0

[arch-ports] integration of ports into original archlinux
by Alexander Baldeck 11 Aug '05

11 Aug '05

hey list, i am wondering about this quite some time now: how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much talk about this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first step. since then i haven't heard much. now then, i simply want to start another discussion. maybe to find a few things a port has to implement before it may be officially mentioned or even why they should not be considered as a part of the official archlinux. regards, alex

3 8

[arch-ports] i586 port
by Seshu Yamajala 05 Aug '05

05 Aug '05

Ok, I personally have not used the i586 packages. I am just hosting them for maci and disc-devil. I haven't heard anything from either of them in a while. So maybe the best thing to do is just merge their changes with what is on the main servers? I don't know, just an idea. Also, this is my first time using a mailing list so bare with me. Finally, i will be on "vacation" for 3 weeks (i think?) in India. - Seshu

2 1

[arch-ports] x86_64 port
by syamajala＠gamebox.net 05 Aug '05

05 Aug '05

Well, its been more than 6 months since the port was started. I think a lot of good progress has been made. There are well over 650 packages. I'm not really as organized as I could be, packages that I use have are top priority for me. So there is a mix of extra packages and current packages. Then I just do random packages. I would also like to migrate to gcc 4 and add 32bit support, or make it optional. It probably should not be optional because there are things like grub that need to be 32bit. Right now the grub package has been compiled on a 32bit system but it has been statically linked. There are also things like flash and opera. Cvsup needs to be fixed. The pacman issue that kth5 talked about needs to be fixed. Dorphell suggested that it might be a problem with the kernel. Also, one major request has been to support the intel 64bit chip. So when things are migrated to gcc 4 i would like to change the flags to support both cpu (intel 64bit chip whatever it may be called and the amd64). All in all I think the future is bright for arch and its various ports! - Seshu (syamajala)

1 0