[SOLVED]ABS failing: Getting useful info out of it / putting it where?

whoops · 2009-05-25 10:51:27

Hi!

As I'm currently doing a full rebuild of my system, I wonder how to find useful information on why makepkg fails and where to post it. I don't have a lot of time and/or experience to investigate those much further - just don't want to let that build time it needs anyway totally "go to waste".

I'm currently running the build script the fourth time and am...:
1) logging all LC_ALL=C makepkg >> afile.log (this should contain a horrible mess of the packages that already failed the first 3 times)
3) makepkg's -L option should give me separate log's in the different directories if I got it right...

So... should I do anything with those logs or just delete them? I really got no idea if they are of any use to anyone and what parts of it... (using arch64 btw.)

thx!

Last edited by whoops (2009-05-26 08:47:36)

Allan · 2009-05-25 11:08:10

Hmmm.... I would consider an app not compiling from ABS a bug. So you could file a bug report for each broken app and attach the relevant part of the makepkg output. Even better if you can find a patch!

whoops · 2009-05-25 11:34:49

Point is;
- I'm not sure which ones are "supposed to fail" because e.g. building/installing a dependency failed or I did something wrong
- Most of the time I don't know which ones are the "relevant parts" of the logs.
- There is a lot of it and I really don't have the time to look into all of them separately if I don't even know, what about I'm looking for

Those are the ones failing to build...:

blender-2.48a-2-x86_64.log
festival-1.96beta-2-x86_64.log
glob2-0.9.3-1-x86_64.log
go-openoffice-3.1.0rc5-1-x86_64.log
grub-0.97-15-x86_64.log
heimdal-1.2.1-3-x86_64.log
libldap-2.3.43-3-x86_64.log
libmp4v2-1.6-1-x86_64.log
libxcursor-1.1.9-2-x86_64.log
libxdamage-1.1.1-2-x86_64.log
libxdmcp-1.0.2-2-x86_64.log
libxfixes-4.0.3-2-x86_64.log
libxfontcache-1.0.4-2-x86_64.log
libxmu-1.0.4-2-x86_64.log
libxpm-3.5.7-1-x86_64.log
libxrender-0.9.4-2-x86_64.log
libxres-1.0.3-2-x86_64.log
libxt-1.0.5-2-x86_64.log
libxtst-1.0.3-2-x86_64.log
libxxf86dga-1.0.2-2-x86_64.log
libxxf86misc-1.0.1-2-x86_64.log
netpbm-10.35-841-x86_64.log
syslog-ng-3.0.1-6-x86_64.log
taglib-1.5-1-x86_64.log
wxgtk-2.8.10-1-x86_64.log

and then there's other stuff like p.E.:

cryptsetup: unable to resolve host address `luks.endorphin.org'

Installing package cups with pacman -U... / error: failed to prepare transaction (conflicting files

fusion-icon says it's never than community rep.

Validating source files with md5sums... emerald-themes-0.6.0.tar.bz2 ... FAILED

Validating source files with md5sums... icu4c-4_0-src.tgz ... FAILED ==> ERROR: One or more files did not pass the validity check!

lib32-glib2:
==> ERROR: Failure while downloading gcc-libs-4.3.3-1-i686.pkg.tar.gz
==> ERROR: Failure while downloading glib2-2.20.1-1-i686.pkg.tar.gz
==> ERROR: Failure while downloading glibc-2.9-4-i686.pkg.tar.gz

lib32-libpng:
==> ERROR: Failure while downloading libpng-1.2.35-1-i686.pkg.tar.gz

lib32-libsm:
==> ERROR: Failure while downloading libsm-1.1.0-1.1-i686.pkg.tar.gz

Connecting to www.infradead.org|85.118.1.10|:80... connected. / HTTP request sent, awaiting response... 404 Not Found ==> ERROR: Failure while downloading libnl-1.1.tar.gz

bsdtar: Unrecognized archive format
bsdtar: Error exit delayed from previous errors.
==> ERROR: Failed to extract openssh-5.2p1.tar.gz

==> Validating source files with md5sums... / readline-5.2.013.tar.gz ... FAILED

... and it goes on...

Last edited by whoops (2009-05-25 11:39:45)

Allan · 2009-05-25 11:39:43

Well, if you are not prepared to look into and report the issues, then there is really nothing to be done...

BTW, heimdal needs to be built on a system without heimdal so that will be the cause of that issue. The lib32 packages are out of date.

whoops · 2009-05-25 11:50:47

OK, then I guess I'll just have to concentrate on a few one by one... and just skip the ones I don't understand.

Thought there'd maybe be a "log-dump" or something somewhere to collect those so the ones who actually know how stuff works don't have to constantly waste time compiling.

whoops · 2009-05-25 13:34:39

Hmh... maybe I'm thinking to complicated - sorry - but I don't get it. Starting out with the most simple and least severe thing as example...:

fusion-icon: local (20090524-1) is newer than community (20090414-1)

Now do I do...
a) nothing, skip to next "bug"
b) look if fusion-icon is allready flagged out of date somewhere and if not find out how to flag it
c) file a "SEVERITY:VERY LOW" bug which says:
fusion-icon: local (20090524-1) is newer than community (20090414-1)
Steps to reproduce:
- compile fusion-icon from abs
- pacman -Syu

or something...? Or do I think of it as a symptom of the "bug":
"pacman complains about abs compiled packages newer than repository when abs pkbuild uses GIT and version is newer something something don't know"
... which is actually a feature - maybe...?.

Maybe I should just ignore that stuff until I magically spontaneously gained enough knowledge to not just confuse people... (or something).

Last edited by whoops (2009-05-25 13:39:25)

tdy · 2009-05-25 19:24:47

whoops wrote:

fusion-icon: local (20090524-1) is newer than community (20090414-1)
Now do I do...
a) nothing, skip to next "bug"
b) look if fusion-icon is allready flagged out of date somewhere and if not find out how to flag it
c) file a "SEVERITY:VERY LOW" bug which says:
fusion-icon: local (20090524-1) is newer than community (20090414-1)
Steps to reproduce:
- compile fusion-icon from abs
- pacman -Syu

Well, this one isn't even a bug unless you just want the pkgname to be renamed as fusion-icon-git or something.

fusion-icon pulls the latest git snapshot to build, so obviously it will be newer than the previously compiled [community] snapshot. That warning message is expected whenever a local package is newer than a repo package.

Last edited by tdy (2009-05-25 20:40:33)

karol · 2009-05-25 21:50:51

To get a happy building env you should have things in sync: some apps don't easily compile w/ certain toolchains etc.

whoops · 2009-05-25 22:10:13

OK, so better no bug filing for me yet. Maybe I'll have more of a clue when I've been watching the bug-tracker every other day for a while.

thx

karol · 2009-05-25 22:17:27

[solved]? ;-)

whoops · 2009-05-26 08:47:03

Jupp, guess It's better to start a new topic when I try again - skips some of the initial confusion.

Last edited by whoops (2009-05-26 08:48:22)

Arch Linux

#1 2009-05-25 10:51:27

[SOLVED]ABS failing: Getting useful info out of it / putting it where?

#2 2009-05-25 11:08:10

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#3 2009-05-25 11:34:49

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#4 2009-05-25 11:39:43

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#5 2009-05-25 11:50:47

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#6 2009-05-25 13:34:39

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#7 2009-05-25 19:24:47

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#8 2009-05-25 21:50:51

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#9 2009-05-25 22:10:13

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#10 2009-05-25 22:17:27

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

#11 2009-05-26 08:47:03

Re: [SOLVED]ABS failing: Getting useful info out of it / putting it where?

Board footer