Should a goal of ArchLinux be that the core and extra repos build without error.
I am rebuilding all the packages from core and some selected packages from extra to take advantage of my processor an AMD Athlon processors, which I use exclusive.
I have used makeworld from a make file and there are several PKGBUILDs that do not build or build incorrectly. Some of the packages fail because of gcc-4.3.2. I have since patched those.
Step two is to run abs then rsync the abs updates into place and fire up my make file to build all the updates on my server box and place them into my custom repos, from cron on Sunday at the zero hour/minute.
If some one would like to test/confirm this here is my Makefile:
.PHONY: cleanstatus cleansrc cleanpkg cleanlog repos clean shutdown update REPNM := testing REPOS := /home/packages/$(REPNM) DBASE := $(REPNM).db.tar.gz PKGS := *.pkg.tar.gz
all: repos cleanstatus cleansrc cleanpkg makeworld --clean --noconfirm --log --syncdeps --rmdeps $(REPOS) . grep fail build.log > failed.log || true cat failed.log || true grep error: makepkg.log || true date repos: repo-add $(REPOS)/$(DBASE) $(REPOS)/$(PKGS) sudo pacman -Syy clean: cleanstatus cleansrc cleanpkg cleanlog cleanstatus: rm build.log || true rm failed.log || true rm makepkg.log || true cleansrc: -find . -name src -type d -exec rm -rf '{}' ; cleanpkg: -find . -name pkg -type d -exec rm -rf '{}' ; cleanlog: -find . -name "*.log*" -exec rm '{}' ; makepkg: clean makepkg --clean --noconfirm --log --syncdeps --rmdeps shutdown: all sudo /sbin/shutdown -h now
Is it possible that your optimizations are responsible for the breakage?
On Fri, Jan 2, 2009 at 8:59 AM, Baho Utot baho-utot@columbus.rr.com wrote:
Should a goal of ArchLinux be that the core and extra repos build without error.
I am rebuilding all the packages from core and some selected packages from extra to take advantage of my processor an AMD Athlon processors, which I use exclusive.
I have used makeworld from a make file and there are several PKGBUILDs that do not build or build incorrectly. Some of the packages fail because of gcc-4.3.2. I have since patched those.
Step two is to run abs then rsync the abs updates into place and fire up my make file to build all the updates on my server box and place them into my custom repos, from cron on Sunday at the zero hour/minute.
If some one would like to test/confirm this here is my Makefile:
.PHONY: cleanstatus cleansrc cleanpkg cleanlog repos clean shutdown update REPNM := testing REPOS := /home/packages/$(REPNM) DBASE := $(REPNM).db.tar.gz PKGS := *.pkg.tar.gz
all: repos cleanstatus cleansrc cleanpkg makeworld --clean --noconfirm --log --syncdeps --rmdeps $(REPOS) . grep fail build.log > failed.log || true cat failed.log || true grep error: makepkg.log || true date repos: repo-add $(REPOS)/$(DBASE) $(REPOS)/$(PKGS) sudo pacman -Syy clean: cleanstatus cleansrc cleanpkg cleanlog cleanstatus: rm build.log || true rm failed.log || true rm makepkg.log || true cleansrc: -find . -name src -type d -exec rm -rf '{}' ; cleanpkg: -find . -name pkg -type d -exec rm -rf '{}' ; cleanlog: -find . -name "*.log*" -exec rm '{}' ; makepkg: clean makepkg --clean --noconfirm --log --syncdeps --rmdeps shutdown: all sudo /sbin/shutdown -h now
On Friday 02 January 2009 09:23:41 am Robert Howard wrote:
Is it possible that your optimizations are responsible for the breakage?
No when using the standard optimizations the same thing happens.
Here are my optimizations: CFLAGS="-march=native -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS=${CFLAGS}
instead of: CFLAGS="-march=i686 -mtune=generic -O2 -pipe" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe"
For example:
If you look at fakeroot you'll find that the package version is not available and you need to use pkgver=1.10.1. So this is not because of optimizations used.
Others are like this:
Flac from extra
--- main.cpp~ 2007-09-13 11:58:03.000000000 -0400 +++ main.cpp 2008-12-25 12:23:06.032076788 -0500 @@ -30,6 +30,7 @@
#include <stdio.h> #include <stdlib.h> +#include <memory.h> #include "FLAC++/metadata.h" #include "FLAC++/encoder.h"
Is why I believe that it is because of a later version of gcc.
On Fri, Jan 02, 2009 at 08:59:18AM -0500, Baho Utot wrote:
Should a goal of ArchLinux be that the core and extra repos build without error.
I am rebuilding all the packages from core and some selected packages from extra to take advantage of my processor an AMD Athlon processors, which I use exclusive.
I have used makeworld from a make file and there are several PKGBUILDs that do not build or build incorrectly. Some of the packages fail because of gcc-4.3.2. I have since patched those.
Report this upstream (the packages ypstream) if this hasnt been reported yet. Make a bug report for each package you found not building in the Archlinux bugtracker. Attach patches for the ones you have managed to build.
Greg
On Friday 02 January 2009 01:20:32 pm Grigorios Bouzakis wrote:
On Fri, Jan 02, 2009 at 08:59:18AM -0500, Baho Utot wrote:
Should a goal of ArchLinux be that the core and extra repos build without error.
I am rebuilding all the packages from core and some selected packages from extra to take advantage of my processor an AMD Athlon processors, which I use exclusive.
I have used makeworld from a make file and there are several PKGBUILDs that do not build or build incorrectly. Some of the packages fail because of gcc-4.3.2. I have since patched those.
Report this upstream (the packages ypstream) if this hasnt been reported yet. Make a bug report for each package you found not building in the Archlinux bugtracker. Attach patches for the ones you have managed to build.
Greg
Ok, I will go through my local copy of core and extra and file the bug reports, though I don't think I will get a good response as I have filed bug reports here before and so far I am at zero for a fix or even some one looking at it. This is evidence by cpio which I filed a bug report in Oct 2008 and it has set without a dev looking at it. It has been assigned but only after I had complained about it. It also has been validated as a bug by another user so I know it was not something that has to do with what I am doing here.
The capi4k-utils package from core is a prime example of a package failing as it spawns a lot shells locking up the host computer from using all the resources available.
As far as the up stream go that will take some time as I have found 20+ packages that exibit the problem with gcc 4.3.2.
My intent is to up my local abs every Sunday and run makeworld from cron to keep my systems current from my custom repos.
Maybe Arch should use something similar where the devs create the PKGBUILDs placing them on a computer that does nitely builds (make world runs) to update or keep current the public core and extra repos.
On Fri, Jan 02, 2009 at 03:41:06PM -0500, Baho Utot wrote:
On Friday 02 January 2009 01:20:32 pm Grigorios Bouzakis wrote:
On Fri, Jan 02, 2009 at 08:59:18AM -0500, Baho Utot wrote:
Should a goal of ArchLinux be that the core and extra repos build without error.
I am rebuilding all the packages from core and some selected packages from extra to take advantage of my processor an AMD Athlon processors, which I use exclusive.
I have used makeworld from a make file and there are several PKGBUILDs that do not build or build incorrectly. Some of the packages fail because of gcc-4.3.2. I have since patched those.
Report this upstream (the packages ypstream) if this hasnt been reported yet. Make a bug report for each package you found not building in the Archlinux bugtracker. Attach patches for the ones you have managed to build.
Greg
Ok, I will go through my local copy of core and extra and file the bug reports, though I don't think I will get a good response as I have filed bug reports here before and so far I am at zero for a fix or even some one looking at it. This is evidence by cpio which I filed a bug report in Oct 2008 and it has set without a dev looking at it. It has been assigned but only after I had complained about it. It also has been validated as a bug by another user so I know it was not something that has to do with what I am doing here.
Usuallu the developers wait for an excuse, most of the times,a new package version, in order to rebuild a package. That reduces packaging load. Of course that only happens if the bug isnt serious, and affects not to many users.
The capi4k-utils package from core is a prime example of a package failing as it spawns a lot shells locking up the host computer from using all the resources available.
That looks dead upstream. Theres already a lot of patching done by the developers. eg. http://repos.archlinux.org/viewvc.cgi/capi4k-utils/repos/core-x86_64/capi-co...
As far as the up stream go that will take some time as I have found 20+ packages that exibit the problem with gcc 4.3.2.
If you actually do report upstream, or find already open reports, include the link to yoyr Archlinux bug report too.
My intent is to up my local abs every Sunday and run makeworld from cron to keep my systems current from my custom repos.
Thats a nice idea, and an alternative way to contribute back to Arch.
Maybe Arch should use something similar where the devs create the PKGBUILDs placing them on a computer that does nitely builds (make world runs) to update or keep current the public core and extra repos.
arch-general@lists.archlinux.org