This was Thomas' trick to make things versioned properly. I *think* there is a process to doing this.

My guess is that klibc needs to be built twice, or something of the sort.

Thomas, can you explain and/or document this in the PKGBUILDs?

Nothing special here: You build klibc and install it (not twice, just once, as usual). The weird klibc-longstring provides=() entry is added magically. Then you can build the klibc-* packages. However, you need a recent version of klibc installed (IIRC 1.5-4 or higher), otherwise the dependency won't be found (the provides=() entry was missing back then). This bug and the four identical bugs for the other klibc packages are all invalid and can be closed.

Just curious - what happens if I try to build this, have klibc installed, but somehow delete the .so ?

I have never gotten klibc-* to compile without error unless I remove the basename trick no matter if I compile it more than once or I have the exact version that I am trying to compile.

It always fails.

For exmaple I updated abs
copy klibc* to /var/abs/local
removed the basname trick
compiled klibc*
install klibc* with pacman -S kilbc*
remove local klibc*
copy klibc from abs to local
makepkg -c
Compile fails on dependency.
Remove basename trick
makpkg -c
Compile succeeds.

Baho, after you install, what is the output of:
$ basename /lib/klibc-*.so .so
$ pacman -Qi klibc | grep Provides
?

$ basename /lib/klibc-*.so .so
klibc-088J8A5xVqZqloQrhjNKyTEVhY8
$ pacman -Qi klibc | grep Provides
Provides : klibc-088J8A5xVqZqloQrhjNKyTEVhY8

Seems like it'd work for me, but I don't have time to build it at the moment.

If I run the same cmds then this:

basename /lib/klibc-*.so .so
klibc-jfflyAahxqaliwAofrf_fdf5upI

$ pacman -Qi klibc | grep Provides
Provides : None

sudo pacman -Scc
sudo pacman -Syy

sudo pacman -S klibc*
warning: klibc-1.5.14-1 is up to date -- reinstalling
warning: klibc-extras-2.5-1 is up to date -- reinstalling
warning: klibc-kbd-1.15.20080312-7 is up to date -- reinstalling
warning: klibc-module-init-tools-3.4-2 is up to date -- reinstalling
warning: klibc-udev-135-1 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...

Targets (5): klibc-1.5.14-1 klibc-extras-2.5-1 klibc-kbd-1.15.20080312-7
klibc-module-init-tools-3.4-2 klibc-udev-135-1

Total Download Size: 2.72 MB
Total Installed Size: 14.76 MB

Proceed with installation? [Y/n] y
:: Retrieving packages from i686...
klibc-1.5.14-1-i686 2.5M 56.7M/s 00:00:00 [######################] 100%
klibc-extras-2.5-1-i686 10.6K 8.3M/s 00:00:00 [######################] 100%
klibc-kbd-1.15.2008... 39.3K 26.7M/s 00:00:00 [######################] 100%
klibc-module-init-t... 27.9K 20.5M/s 00:00:00 [######################] 100%
klibc-udev-135-1-i686 101.3K 42.2M/s 00:00:00 [######################] 100%
checking package integrity...
(5/5) checking for file conflicts [######################] 100%
(1/5) upgrading klibc [######################] 100%
(2/5) upgrading klibc-extras [######################] 100%
(3/5) upgrading klibc-kbd [######################] 100%
(4/5) upgrading klibc-module-init-tools [######################] 100%
(5/5) upgrading klibc-udev [######################] 100%

basename /lib/klibc-*.so .so
klibc-jfflyAahxqaliwAofrf_fdf5upI

pacman -Qi klibc | grep Provides
Provides : None

Well, there's the problem...
What about:
$ pacman -Qip /var/cache/pacman/pkg/klibc-1.5.14-1-i686.pkg.tar.gz | grep Provides
?

Do you have an older makepkg, by chance?

$ pacman -Q | grep pacman
pacman 3.2.1-2
pacman-mirrorlist 20081213-1

This line in the PKGBUILD must be failing for some reason:

provides[${#provides[@]}]="$(basename $startdir/pkg/lib/klibc-*.so .so)"
export provides

can you add this to the end of the build function:

echo "$(basename $startdir/pkg/lib/klibc-*.so .so)"
for p in ${provides[@]}; do echo "provide => $p"; done

Compiled three times with the following from a bash shell

1 .makepkg -cf --log

2. makeworld --clean --noconfirm --log --syncdeps --rmdeps ${I686_PKG_REPOS} .

3. makepkg -cf

Look at the .PKGINFO files, the only one that has the provides line is the one without the --log parameter
can some one else test this as well?


makepkg -cf --log

klibc-jfflyAahxqaliwAofrf_fdf5upI
provide => klibc-jfflyAahxqaliwAofrf_fdf5upI

.PKGINFO lists:

# Generated by makepkg 3.2.1
# using fakeroot version 1.10.1
# Tue Jan 6 23:26:18 UTC 2009
pkgname = klibc
pkgver = 1.5.14-1
pkgdesc = A minimal libc made for early-userspace
url = http://www.kernel.org/pub/linux/libs/klibc/
builddate = 1231284378
packager = Baho Utot <baho-utot@bildanet.com>
size = 14983168
arch = i686
license = BSD
group = base

makeworld --clean --noconfirm --log --syncdeps --rmdeps ${I686_PKG_REPOS} .

klibc-jfflyAahxqaliwAofrf_fdf5upI
provide => klibc-jfflyAahxqaliwAofrf_fdf5upI

.PKGINFO lists:

# Generated by makepkg 3.2.1
# using fakeroot version 1.10.1
# Tue Jan 6 23:37:21 UTC 2009
pkgname = klibc
pkgver = 1.5.14-1
pkgdesc = A minimal libc made for early-userspace
url = http://www.kernel.org/pub/linux/libs/klibc/
builddate = 1231285041
packager = Baho Utot <baho-utot@bildanet.com>
size = 14983168
arch = i686
license = BSD
group = base


makepkg -cf

klibc-jfflyAahxqaliwAofrf_fdf5upI
provide => klibc-jfflyAahxqaliwAofrf_fdf5

# Generated by makepkg 3.2.1
# using fakeroot version 1.10.1
# Tue Jan 6 23:45:19 UTC 2009
pkgname = klibc
pkgver = 1.5.14-1
pkgdesc = A minimal libc made for early-userspace
url = http://www.kernel.org/pub/linux/libs/klibc/
builddate = 1231285518
packager = Baho Utot <baho-utot@bildanet.com>
size = 14983168
arch = i686
license = BSD
group = base
provides = klibc-jfflyAahxqaliwAofrf_fdf5upI

Hmm, so you think --log may cause this?

tpowa, do you use --log as well?

Just tried this on my desktop box and I get the same result

makepkg -cf works, proper provides line in the .PKGINFO

makepkg -cf --log doesn't, improper provides line in the .PKGINFO

makepkg -cf 2>&1 | tee water.logged works, proper provides line in the .PKGINFO

How is logging done in makepkg, I have not had a look at the source

Maybe some one to look into pacmans --log parameter

It appears we've uncovered a pacman bug... adding Dan.

Oooh... wait a second. The variables exported fail if they're piped, don't they. I remember a similar issue somewhere.
####
FOO=a
test() {
export FOO=b
}

test
echo $FOO #should be b

FOO=a
test | tee /dev/null
echo $FOO #should be a
####

due to this, the exporting in the build function fails.... Dan, didn't we fix something similar somewhere?

Upon further review of the --log parameter in makepkg

I have looked at the resulting log files from successfull and unsuccessfull builds and noticed that all the log file are truncated or not flushed upon closing.

This the tail from the log file from makepkg -cf 2>&1 | tee water.logged
usr/utils/shared/poweroff
==> Tidying install...
-> Removing info/doc files...
==> Creating package...
-> Generating .PKGINFO file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: klibc 1.5.14-1 i686 (Tue Jan 6 19:21:39 EST 2009)
==> Cleaning up...

This the tail from the log file from makepkg -cf --log

INSTALL usr/utils/shared/chroot usr/utils/shared/dd usr/utils/shared/mkdir usr/utils/shared/mkfifo usr/utils/shared/mknod usr/utils/shared/mount usr/utils/shared/pivot_root usr/utils/shared/umount usr/utils/shared/true usr/utils/shared/false usr/utils/shared/sleep usr/utils/shared/ln usr/utils/shared/nuke usr/utils/shared/minips usr/utils/shared/cat usr/utils/shared/uname usr/utils/shared/halt usr/utils/shared/readlink usr/utils/shared/sync usr/utils/shared/dmesg usr/utils/shared/reboot usr/utils/shared/poweroff
klibc-jfflyAahxqaliwAofrf_fdf5upI
provide => klibc-jfflyAahxqaliwAofrf_fdf5upI

Notice it did not finish no tidy/compressing etc.
But the provide test that Aaron had me add to the end of the build section in the PKGBUILD file is there.

The mystery deepens

No, the makepkg --log doesn't currently include any of the makepkg output- only that from build() itself. So I don't see anything weird about the last comment- the log looks as it is supposed to.

We at least have a workaround for this bug- don't build with "makepkg --log", so I don't think this is critical to fix.

Cover your eyes, but here is the beautiful hack Aaron was thinking of: http://dev.archlinux.org/~allan/gitweb/gitweb.cgi?p=pacman.git;a=commitdiff;h=626c75097b75be4e64890b65a4145b391d76f91f

So then we need to make sure the klibc PKGBUILD isn't build using --log, or else we get problems like this. That sounds painful

As a work around for the --log parameter to makepkg

I have patched makeworld to leave the makepkg.log file so that you get log files into the package build subdirectory
by removing "a $toplevel/" from this

PKGDEST="$dest" makepkg $MAKEPKG_OPTS -m 2>&1 1>&2 | tee a $toplevel/makepkg.log

to

PKGDEST="$dest" makepkg $MAKEPKG_OPTS -m 2>&1 1>&2 | tee makepkg.log

That gives you a log file to mimic makepkg -c --log

Status?

This is a makepkg issue, but it should be fixed in pacman trunk. I have to verify this though.

Added me to assignees here as this is a makepkg issue...

This will not be fixed in pacman trunk as the ugly (but working!) hack mentioned above is only used in the makepkg run_package() function and not the run_build() one. Once pacman-3.3 is out, I am going to look into merging these together so that adding a check() function to the PKGBUILD does not duplicate more code.

Of course, using a package() function in the PKGBUILD with pacman-3.3 would fix this.

That attached PKGBUILD shows how this issue can be fixed with pacman-3.3 and the use of a package() function.

But... the build currently fails:
The 'linux' symlink is missing; it should point to a kernel tree
configured for the i386 architecture.
make: *** [linux] Error 1

Edit: fixed attachement

@Allan, the attached pkgbuild not is the correct (is the original). Must change the variable _kver to build OK ;)

I fixed the attachment... I obviously didn't try hard to fix the build failure.

So, can I just push the PKGBUILD to SVN to fix _this_ bug or should we rebuild all that klibc packages to have a working build with the updated _kver?

Allan, will this be fixed with the latest patch in makepkg anyway? And can we close it with your attachment above?

This will be fixed with the seterr patch, but that will be in pacman-3.4. Probably worth doing a rebuild of all the klibc stuff with updates needed to klibc-module-init-tools and klibc-udev anyway, so we can just use the above PKGBUILD then.

Okay, -L should be fixed here, kver updates to 2.6.31 coming later, this one is fixed.
http://repos.archlinux.org/wsvn/packages/?compare[]=%2Fklibc%2Ftrunk%2F%4056331&compare[]=%2Fklibc%2Ftrunk%2F%4041787&comparesubmit=Compare+Revisions&op=comp