- Arch-general - lists.archlinux.org

[arch-general] Malayalam fonts for Arch
by aashiks 14 Jan '09

14 Jan '09

Hi, I understand that there may not be many users who need Malayalam fonts here on this list, but if there are any then there are a set of TTF fonts ( from theep://smc.org.in ) that I have packaged. The PKGBUILD is available at http://aur.archlinux.org/packages.php?ID=23145 These fonts are the default Malayalam fonts in Debian and Fedora. I thought it would be nice to see them on Arch too :) regards, Aashik

1 0

[arch-general] agg - antigrain
by Baho Utot 14 Jan '09

14 Jan '09

I am posting this here because this package is in extra and is orphaned... Can anyone have a look at this? Antigrain build fails current PKGBUILD from abs, compiled attempt with gcc-4.3 default build flags. Here is the error from my log file make[3]: Entering directory `/srv/http/Build/BUILD.i686/extra/agg/src/agg-2.5/src/platform/X11' /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I -g -O2 -c -o libaggplatformX11_la-agg_platform_support.lo `test -f 'agg_platform_support.cpp' || echo './'`agg_platform_support.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I -g -O2 -c agg_platform_support.cpp -fPIC -DPIC -o .libs/libaggplatformX11_la-agg_platform_support.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I -g -O2 -c agg_platform_support.cpp -o libaggplatformX11_la-agg_platform_support.o >/dev/null 2>&1 /bin/sh ../../../libtool --tag=CXX --mode=link g++ -I../../../include -I -g -O2 -version-info 2:4:0 -L -o libaggplatformX11.la -rpath /usr/local/lib libaggplatformX11_la-agg_platform_support.lo -lX11 libtool: link: require no space between `-L' and `-o' make[3]: *** [libaggplatformX11.la] Error 1

2 2

[arch-general] Boot error with 2008.12
by Sergi Pons Freixes 13 Jan '09

13 Jan '09

Hi all, Thanks to a Xmas present, now I'm the proud owner of a ThinkPad X200T. After been a time flirting with Ubuntu, I'm returning to Arch (in fact, I've never abandoned it, because my home server runs Arch). The X200T doesn't have an optical drive, so I tried the USB install method. First I tried the last "official" release, 2008.06, and it booted perfectly. Unfortunately, as you can see here [1], the kernel included (2.6.24) doesn't fully support the wireless neither the ethernet cards. Then, following the recommendation from [1], I tried the "testing" 2008.12 release. But it doesn't boot. It just shows the message: Boot error. I've checked the md5sum of the img file and the pen drive (dd if=/dev/sdb count=875219 status=noxfer |md5sum) and in both cases it's ok (so, no corrupt img file, and no corrupt pen drive). I've checked the forums and in this post [2] at least two people suffer the same issue, but there is no answer. Any idea about the possible origin of the issue and how to solve it? Regards, Sergi [1] http://itgen.blogspot.com/2008/12/installing-arch-linux-on-lenovo.html [2] http://bbs.archlinux.org/viewtopic.php?id=60385

2 2

[arch-general] Pointless to use non-md5 for makepkg INTEGRITY_CHECK
by Aaron Schaefer 13 Jan '09

13 Jan '09

At the request of the upstream developer, I was attempting to change the md5sums in my tarsnap PKGBUILD (http://aur.archlinux.org/packages.php?ID=22963) to use sha256 instead, and ran across a couple of issues. The way makepkg works, when you set INTEGRITY_CHECK in makepkg.conf, those values effect BOTH the generation of the checksums and also the verification upon package compilation. I believe the variable should only effect checksum generation. Validation of the checksums upon compilation should only fail in two cases: 1) There are no checksums listed in the PKGBUILD or 2) One of the listed checksums does not validate against the source The way things are now, it's not feasible to use a non-standard (read non-md5) checksum, because everyone who would like to build the package themselves would either have to alter their own makepkg.conf file, or simply ignore the warning of verification failure. Unless everyone moved to a different standard of checksum at the same time, I don't think it would be realistic for us to expect people to do this. I can't think of a use case where it wouldn't make sense just to verify whatever checksums are listed in the PKGBUILD, and only consult the INTEGRITY_CHECK settings when generating new checksums. This process also led the the discovery of an issue with the AUR code...it seems as though the AUR is hard-coded to check for md5sums only, so if you attempt to upload a package with just a sha256sums line, it will complain and prohibit you from updating the PKGBUILD. Has anyone else ever tried to use a non-standard INTEGRITY_CHECK setting? Is there something here that I'm missing? -- Aaron "ElasticDog" Schaefer

6 26

[arch-general] Microphone issues on ICH7
by Will Siddall 13 Jan '09

13 Jan '09

Hey everyone, I've had this great HP laptop for the past 4 years with no need (of course there's always a want) to upgrade. And of all this time, I never had a problem with it, until now. Out of the past 4 years, I've never needed to use my microphone for anything, but lately I've been sent overseas a lot for work and needing to keep in contact, decided to start skype to call back home. That's when I noticed that my microphone didn't work at all. I thought it would be skype, but trying to use gnome-sound-recorder proved that to be wrong. Nothing is coming through. I've tried running 'alsaconf' again, I've tried a huge number of .asoundrc setups, using different microphones, everything that I can imagine. I'm out of ideas, would anyone have anything else I can try? Has anyone run into this problem before? Thanks, Will

2 2

Re: [arch-general] LZMA - in or out?
by Rogutes 13 Jan '09

13 Jan '09

Dan McGee (2009-01-12 19:59): > Some non-benefits of LZMA for those that brought up compression of packages > : > $ ./testzip.sh openoffice-base-3.0.0-4-x86_64.pkg.tar > <...snip...> > > Yes, LZMA took nearly 5 minutes to compress this package which gzip > accomplished in 22 seconds. I am replying to a thread in arch-dev-public list, since I haven't got permission to post there. I would like to propose my simple test (note the compression ratio switches): compression: gzip -9 openoffice-base-3.0.0-4-i686.pkg.tar 48,20s user 0,30s system 99% cpu 48,609 total lzma -1 openoffice-base-3.0.0-4-i686.pkg.tar 50,16s user 0,42s system 99% cpu 50,969 total bzip2 -1 openoffice-base-3.0.0-4-i686.pkg.tar 58,37s user 0,34s system 99% cpu 58,986 total lzma -2 openoffice-base-3.0.0-4-i686.pkg.tar 72,19s user 0,36s system 99% cpu 1:12,60 total decompression: gzip -d openoffice-base-3.0.0-4-i686.pkg.tar.gz 3,33s user 0,39s system 98% cpu 3,783 total lzma -d openoffice-base-3.0.0-4-i686.pkg.tar.lzma 14,39s user 0,36s system 99% cpu 14,839 total bzip2 -d openoffice-base-3.0.0-4-i686.pkg.tar.bz2 18,61s user 0,44s system 98% cpu 19,260 total sizes: 303M openoffice-base-3.0.0-4-i686.pkg.tar 141M openoffice-base-3.0.0-4-i686.pkg.tar.gz 139M openoffice-base-3.0.0-4-i686.pkg.tar.bz2 129M openoffice-base-3.0.0-4-i686.pkg.tar.lzma 119M openoffice-base-3.0.0-4-i686.pkg.tar.lzma-2 default compression ratio switches: gzip -6 bzip2 -9 lzma -7 And an excerpt from lzma manual: In this manual lzma is compared mostly to bzip2 because that is currently one of the most widely used free software to compress tar files made for distribution. Comparing lzma to gzip is not practical because neither lzma nor bzip2 can compete with gzip in compression speed. On the other hand the compression ratio of gzip is worse than of lzma and bzip2. -- Rogutes

1 0

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.28-3
by Gerhard Brauer 10 Jan '09

10 Jan '09

Am Tue, 06 Jan 2009 17:54:08 +0100 schrieb Thomas Bächler <thomas(a)archlinux.org>: > Aaron Griffin schrieb: > > On Tue, Jan 6, 2009 at 5:08 AM, Tobias Powalowski <t.powa(a)gmx.de> > > wrote: > >> Showstopper: > >> klibc needs to be fixed. It breaks compilation of tools. > > > > Could you be more specific? There was some talk on the klibc ML > > about recent kernel changes, so I'd like to know what is broken. > > Perhaps it is fixable (and Debian may have changes already) > > klibc didn't build against 2.6.28 because some asm headers are now in > arch/x86/include/ instead of include/asm-x86/. I added a quick-fix to > the Makefile so klibc would build. However, I forgot that these > headers weren't installed either, so now klcc does not compile > anything that needs any of those headers (I didn't notice because I > didn't have to recompile the klibc-* packages). This means: klibc > works as a runtime library, but klcc is useless. IMHO is the problem in our kernel26 package. Therein we have a bad symlink to the architecture asm directory. [gerhard@tux1 ~]$ ls -ld /usr/src/linux-2.6.28-ARCH/include/asm lrwxrwxrwx 1 root root 7 26. Dez 11:01 /usr/src/linux-2.6.28-ARCH/include/asm -> asm-x86 [gerhard@tux1 ~]$ ls -l /usr/src/linux-2.6.28-ARCH/include/asm/ -rw-r--r-- 1 root root 5877 26. Dez 10:43 asm-offsets.h If compiling klibc from testing (i use 1.5.15) with the 2.6.28 patch we have in klibc: ----- /usr/lib/klibc/include/asm total 8 lrwxrwxrwx 1 root root 8 2009-01-09 11:54 asm-i386 -> asm-i386 -rw-r--r-- 1 root root 5877 2009-01-09 11:53 asm-offsets.h lrwxrwxrwx 1 root root 7 2009-01-09 11:54 asm-x86 -> asm-x86 ------------ two death symlinks (asm-i386, asm-x86). These are the problems that the other klibc-* tools don't build. But if i change the kernel asm Symlink to: /usr/src/linux-2.6.28-ARCH/include/asm -> /usr/src/linux-2.6.28-ARCH/arch/x86/include/asm (for i686), then i could build a) klibc 1.5.15 without the 2.6.28-patch b) the other klibc-* tools from core. Regards Gerhard

1 1

[arch-general] Problem building Player with pkgbuild
by Christian Babeux 09 Jan '09

09 Jan '09

Hi, I'm trying to build Player with a pkgbuild from the AUR. Here is the pkgbuild: http://aur.archlinux.org/packages/player/player/PKGBUILD Is seems the build is failing because of Arch's strict GCC (I really don't know if that's the problem) At first it was failing with this error: actarrayproxy.cc: In member function ‘player_actarray_actuator_t PlayerCc::ActArrayProxy::GetActuatorData(uint32_t) const’: actarrayproxy.cc:246: error: ‘memset’ was not declared in this scope So I figured that string.h was not included and modified the config.h to include it : echo -e "#include <unistd.h>\n#include <stdlib.h>\n#include <stdio.h>\n#include <string.h>" >> config.h But now it fails with : speechproxy.cc:96: error: ‘strdup’ was not declared in this scope The strange thing is that strdup is declared in string.h... Any ideas ? Christian Babeux

4 3

[arch-general] Kerberos auto renew does not work.
by Anton 08 Jan '09

08 Jan '09

Good Day. I'm trying to make kcm to work but it does not want :-). I want creds on my workstation to be renewed automatically when it near to expire. I set in [libdefaults] secton default_cc_name = KCM:%{uid}, I started kcm. Then I got cred with command: kinit --renewable user1 it gets tgt with a renewable flag but does not renews automatically and then exires. To check this I used -l 60 and/or -r 60. Tgt never be renewed. It always expires. Google did not help me or my search was wrong :-(. What am I doing wrong ? What are the necessary steps should I do to make auto renew of cred ? -- Anton [WARM-RIPE] Stack ltd division head tel. 8 (3822) 555-797

1 0

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.28-2
by pyther 08 Jan '09

08 Jan '09

On Tue, 06 Jan 2009 01:37:33 +0100, tobias(a)justdreams.de wrote: > Quoting Jan de Groot <jan(a)jgc.homeip.net>: >> I'm running the 2.6 prerelease series for a while on my laptop now. My >> first impressions: >> - EXA is even slower than it was with 2.4.3 >> - UXA is much faster >> - XAA not tested >> - 3D is horribly slow >> - Compiz doesn't draw window decorations due to some breakage in libdrm >> >> If we want to use 2.5.x or 2.6 when it comes out, we have to grab a mesa >> snapshot from git master to get GEM support in mesa also. >> >> As xorg-server 1.6 shouldn't be far away anymore, I think we can wait >> for the next stable release of mesa that has GEM support. >> > Just as I thought you have much more insight on this. I totally agree to > stick with 2.4.x for now. > > Thanks, > -T I just wanted to let the devs know that 2.4.x causes Xorg to crash with Kernel 2.6.28, so some users might have issues. It doesn't matter to me either way just wanted to let that information be known. Thanks, pyther

2 2