[arch-general] glibc 2.7 for i586
Just a heads up if there are still any other i586 archers out there: glibc 2.7 needs an extra patch to compile for CHOST=i586. PLD Linux has the patch here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/glibc-i586-build-fix.patch Cheers. Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/
[arch-general] flac makedepends on xmms ??
xmms hasn't been in the official repositories for some time, IIRC. Looking for a X-Mas gift? Everybody needs a Flickr Pro Account. http://www.flickr.com/gift/
Re: [arch-general] flac makedepends on xmms ??
oops, sorry for the top-post, bad habit... :) Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/
Re: [arch-general] flac makedepends on xmms ??
OK, no need to file a bug report I guess. I wonder if the plugin could be built against one of the xmms forks like bmp or audacious ? (though I see now bmp development is discontinued in favour of bmpx). --- Eric Belanger <[EMAIL PROTECTED]> wrote: > On Thu, 13 Dec 2007, Aaron Griffin wrote: > > > On Dec 13, 2007 10:55 PM, Mister Dobalina > <[EMAIL PROTECTED]> wrote: > >> xmms hasn't been in the official repositories for > some > >> time, IIRC. > > > > Please file a bug report > > > > > > > > FYI, that makedepends is required to build the xmms > plugin which is still > being included in the flac package. That issue has > been mentionned on the > dev ML several months ago. The consensus was, at > that time, that it was a > minor and acceptable issue as it's just a > makedepends. Plus the fact that > I am xmms' maintainer in the community repo and am > also a dev. Still, > you can fill a bug report. > > > Eric (Snowman) > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php
[arch-general] missing /usr/lib/libstdc++.la / kdelibs won't build
I know you'll tell to file a bug report, but I like to get people's opinion on this ;) So I'm trying to build kdelibs, but after building some kwallet stuff it fails with grep & sed complaining about there being no /usr/lib/libstdc++.la file, which is odd, since gcc-libs has options=(!libtool). On an older arch install on a different machine, I actually have a stale /usr/lib/libstdc++.la lying around, but "pacman -Qo" comes up empty, and a look inside tells me that this is circa libstdc++.so.6.0.3 (current is libstdc++.so.6.0.9). I guess I'll try to figure out how to get libtool to build the missing libstdc++.la so I can finish my kdelibs build. Cheers. Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com.
Re: [arch-general] problem compiling for i586 with new makepkg
--- Travis Willard <[EMAIL PROTECTED]> wrote:
> Just a hint, since you were looking to add i586 -
> find and sed are
> your friends. :D
>
> find -name PKGBUILD -exec sed -i '/^arch=/ { /i586/
> !{
> s/^arch=(/arch=(i586 / } }' {} \;
>
> That will find every PKGBUILD and add i586 to the
> packages that don't
> already have it. Yay!
>
No good, many PKGBUILDs have stuff like
if [ "$CARCH" = "i686" ]; then
<< do something >>
fi
in the build() section, where the something done is
usually something you want done in the i586 case too.
Better to straight out replace i686 by i586 in the
whole PKGBUILD.
find /var/abs -name PKGBUILD -exec sed -i -e
's|i686|i586|g' '{}' \;
Might also want to do
grep -R i686 /var/abs/*
just to be sure there are no i686's hiding in .install
files.
cheers.
Be smarter than spam. See how smart SpamGuard is at giving junk email the
boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New
Mail today or register for free at http://mail.yahoo.ca
Re: [arch-general] problem compiling for i586 with new makepkg
--- Karolina Lindqvist <[EMAIL PROTECTED]> wrote: > Actually, I added i586 when I did it the last time, > one year ago, with the > result that it was practically hopeless to diff with > the original, when doing > an update with "abs". So this time, I just ignore to > put in i586, making it > easier with upgrades. Yes, you will have to do this search-and-replace i686->i586 after every time you update abs. > I still question the whole purpose of the arch= tag, > if it means that it > is "certified" by the developers. All files > downloaded with abs are certified > by the developers, so what is the big deal? And > makeworld does not exclude > building packages that are not for the architecture. The point is that the developers don't want to get a bunch of bug reports for things that might be i586-specific problems. They are saying "we've tested the package that is built using this PKGBUILD on i686 and/or x86_64, and if you have a problem with it let us know, but if you use this PKGBUILD to build for some other architecture, you're on your own". Though I agree that makepkg just aborting on i586 is kind of pointless, just a nice big warning would suffice. From previous posts I assume this will change in future versions of makepkg. > And then, what does it mean for AUR, if everyone are > forced to put the tag in, > but now not meaning that it is certified by the > developers anymore? I assume AUR maintainers are free to put whatever they like in the arch tag -- it's up to them what architectures they want to support for their specific package. > I think a better usage would be that the package is > tried and works and is > meaningful on that architecture. Well, that's exactly what it means now. But the devs don't want to go to the work of doing that on i586, because arch is an i686/x86_64-optimized distribution, and has never claimed to be "tried and working" on i586. Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://mail.yahoo.ca
