- Arch-general - lists.archlinux.org

[arch-general] old firewire stack?
by Dieter Plaetinck 14 Nov '09

14 Nov '09

Hi, according to http://www.kdenlive.org/user-manual/troubleshooting-and-common-problems/tro… we are using an old firewire stack. I'm having big problems with DV-video (firewire) stuff ( see http://bbs.archlinux.org/viewtopic.php?pid=655692 ) and I was wondering if the new stack would fix it, but how can I run it? [root@dieter-p4sci-arch ~]# lsmod | egrep 'firewire|1394' dv1394 18492 0 video1394 15836 0 ohci1394 30220 2 dv1394,video1394 raw1394 25756 0 ieee1394 85668 4 dv1394,video1394,ohci1394,raw1394 [root@dieter-p4sci-arch ~]# modprobe firewire-ohci FATAL: Module firewire_ohci not found. [root@dieter-p4sci-arch ~]# pacman -Ss juju [root@dieter-p4sci-arch ~]# pacman -Ss firewire extra/dvgrab 3.5-1 Saves audio and video data from an IEEE (FireWire) digital source extra/libraw1394 2.0.4-1 Provides an API to the Linux IEEE1394 (FireWire) driver [root@dieter-p4sci-arch ~]# pacman -Qs libraw local/libraw1394 2.0.4-1 Provides an API to the Linux IEEE1394 (FireWire) driver thanks Dieter

3 2

[arch-general] AUR: gcc-java-4.3.3.tar.bz2.part ==> ERROR: Build Failed.
by David C. Rankin 13 Nov '09

13 Nov '09

Guys, Looks like there is a misconfigured locale in the gcc-java-4.3.3 AUR files. Attempting to build the gcc-gcj AUR package, it died with the following: 2009-11-13 00:51:08 (135 KB/s) - “gcc-java-4.3.3.tar.bz2.part” saved [18053140] -> Found gcj-4.3-tools.jar-path.diff in build dir -> Found gcc_pure64.patch in build dir -> Found libjava-disable-static.dpatch in build dir -> Found libjava-sjlj.dpatch in build dir -> Found gcc-hash-style-both.patch in build dir ==> Validating source files with md5sums... gcc-core-4.3.3.tar.bz2 ... Passed gcc-g++-4.3.3.tar.bz2 ... Passed gcc-java-4.3.3.tar.bz2 ... Passed gcj-4.3-tools.jar-path.diff ... Passed gcc_pure64.patch ... Passed libjava-disable-static.dpatch ... Passed libjava-sjlj.dpatch ... Passed gcc-hash-style-both.patch ... Passed ==> Extracting Sources... -> Extracting gcc-core-4.3.3.tar.bz2 with bsdtar -> Extracting gcc-g++-4.3.3.tar.bz2 with bsdtar -> Extracting gcc-java-4.3.3.tar.bz2 with bsdtar ==> Entering fakeroot environment... ==> Starting build()... You need the de_DE locale to build gcc. ==> ERROR: Build Failed. Aborting... What to check? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

4 6

[arch-general] New NVIDIA legacy drivers compatible with our latest xorg-server
by Thomas Bächler 13 Nov '09

13 Nov '09

NVIDIA released new prereleases of their 173.xx.xx and 96.xx.xx drivers ([1], [2]). Driver packages and kernel modules for the 2.6.31-ARCH kernel are being uploaded now, they should start to appear on mirrors soon. Please test them and report. [1] http://www.nvnews.net/vbulletin/showthread.php?p=2122688 [2] http://www.nvnews.net/vbulletin/showthread.php?p=2122691

1 0

[arch-general] Frustrated with Crappy looking Firefox and OpenOffice GTK & QT themes?
by David C. Rankin 13 Nov '09

13 Nov '09

After mucking around trying to get firefox and openoffice to look right, I thought I would pass on a few tips. For those of you that know already, just hit delete. The dull boxy appearance of both GTK and some Qt apps left me scratching my head for the right tools to fix the look. The normal qtconfig and gtk2_prefs just didn't do it for all applications (like basket and other kde3 now sort of kde4 apps) Trial and error and google helped. The main tools are: GTK Preferences (ff has both GTK and Qt) /usr/bin/gtk2_prefs (themes and more) /usr/bin/gtk-chtheme (change theme ** Don't over look this one) Qt Preferences /usr/bin/qtconfig (themes and more) ** also the gnome-control-center collects most of the tools for you in one place. I don't use gnome, but I installed the control center for convenience. The packages involved are (with the addtional nice themes): GTK TOOLS & ENGINES gnome-control-center 2.28.1-1 gtk2_prefs 0.4.1-1 gtk 1.2.10-9 gtk2 2.18.3-2 gtk-kde4 0.9b-3 gtk-chtheme 0.3.1-4 gtk1-engines 0.12-2 gtk-engines 2.18.4-1 gtk-qt-engine 1.1-1 gtk-aurora-engine 1.5.1-1 gtk-engine-murrine 0.90.3-1 gtk-rezlooks-engine 0.6-8 gtk-smooth-engine 0.6.0.1-3 QT TOOLS & PACKAGES qt3 3.3.8-13 qt 4.5.3-3 qtcurve-gtk2 0.69.2-1 qtcurve-kde3 0.69.1-1 qtcurve-kde4 0.69.2-1 THEMES gnome-icon-theme 2.28.0-1 gnome-themes 2.28.1-1 gnome-themes-extras 2.22.0-1 murrine-themes-collection 20090906-1 qtcurve-gtk2 0.69.2-1 Install what you want, then just run gtk2_prefs and/or gtk-chtheme (if you installed the additional themes), then finish up with qtconfig. You have to shut down and restart you application for the changes to take effect, but when you are done, you will have some really good looking GTK and QT themes and decorations. (you can even select Oxygen as your GTK and Qt theme) The theme packages above have both light and dark themes. You can find some additional/better themes at art.gnome.org Here is an example of firefox and openoffice with the touch-ups applied (60k): http://www.3111skyline.com/download/Archlinux/fixes/gtk-qt-example.jpg -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

3 3

Re: [arch-general] (groff+)ghostscript/us letter/paper size problems
by Mike Bishop 12 Nov '09

12 Nov '09

On Thu, Nov 12, 2009 at 09:49:13AM -0500, Louis Guillaume wrote: > Mike Bishop wrote: <snip> > > > >The problem is that recent versions of ghostscript will (often) > >assume a4 paper size, regardless of /etc/paper. This applies > >after ghostscript 8.64-5 but I am not sure which version (8.70 has > >the problem). > > I don't know much about how this is "supposed" to work with > /etc/paper or /etc/papersize. I always thought those were > ghostscript or grops things. > > If you need to explicitly define a paper size for groff to use (that > isn't the default) I think you need: `-dpaper=letter' in addition to > `-P-pletter'. The latter is for grops. > > Louis > Actually, I screwed up. The file on Arch at /usr/share/groff/1.20.1/font/devps/DESC has "papersize a4" while a more usual entry is "papersize /etc/papersize a4" ... so my settings in /etc/papersize were ignored. I looked for a complicated answer and found it! Rgds, -- Mike Bishop Willow, Alaska

1 0

Re: [arch-general] аrch x86_64 and i686 performance comparison
by Robert Howard 12 Nov '09

12 Nov '09

I find the 64 bit version to be on par with the 32 bit version. I do think 64 bit is faster when using it for GIS with large datasets. I have been using 64 bit for years without remorse. Now, no 64 bit Windows OS has ever been worth using. On Nov 11, 2009 11:19 PM, "Sergey Manucharian" <sergeym(a)rmico.com> wrote: Excerpts from Smith Dhumbumroong's message of Thursday 12-Nov-09 10:49am: > Better to install both Arch 32-bit and 64-bit on the same machine > (dual boot) and run the tests... I've already did it. > from my personal experience certain operations, such as video/music > encoding, is a _lot_ faster... Well, in my ThinkPad R61 (Core2 Duo CPU T9300 @ 2.50GHz) I got 1.1 times difference (in favour of 64-bit) with couple of videofiles encoded. (By the way, it means that VM performs almost 1.5 worse then the real HW). Thanks, Sergey

1 0

Re: [arch-general] No sound after hal update
by Christopher Daley 12 Nov '09

12 Nov '09

Also, make sure your user is a member of the group 'audio'? If you're still having problems then run ls -l /dev/snd and show us the output On Tue, Nov 10, 2009 at 5:54 AM, Jozsef <jozefk(a)gmx.com> wrote: > On Tue, 10 Nov 2009, A Rojas wrote: > > > I just updated to hal 0.5.13-3 and after rebooting the soundcard is not > > accessible to non-root users anymore, so there is no sound. Any idea how > to > > solve this? > > Thanks > > > -- > Best, > Jozsef Kurucity | Web & Graphic Designer > +971 50 6783113 | jozefk(a)gmx.com >

4 7

[arch-general] аrch x86_64 and i686 performance comparison
by Sergey Manucharian 12 Nov '09

12 Nov '09

Hi folks, The similar question most probably has been discussed many times, but I really cannot find a clear answer. There are some obvious thinks like 64-bit addressing, but how about math calculations performance? I've set up two identical virtual machines in vbox - one with Arch x86_64 and another with Arch i686. I ran mencoder in both over the same video and got the following figures: x86_64: 43 sec i686: 34 sec which make x86_64 not so impressive ;) Some time ago I read an article at AMD web site, they suggested using their math libs for writing programs instead of standard ones. In such a case a program with complex math involved can performs much better (personally I haven't tried). I'm just curious about other people's opinions on this subject. Cheers, Sergey

7 12

[arch-general] Updated PKGBUILD for libftdi
by Gerardo Exequiel Pozzi 11 Nov '09

11 Nov '09

* Updated to latest 0.16 version * convert $startdir vars in PKGBUILD -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D Index: libftdi/trunk/PKGBUILD =================================================================== --- libftdi/trunk/PKGBUILD (revision 58698) +++ libftdi/trunk/PKGBUILD (working copy) @@ -2,21 +2,21 @@ # Maintainer: Tobias Powalowski <tpowa(a)archlinux.org> pkgname=libftdi -pkgver=0.15 -pkgrel=3 +pkgver=0.16 +pkgrel=1 pkgdesc="A library to talk to FTDI chips" arch=("i686" "x86_64") url="http://www.intra2net.com/en/developer/libftdi/download.php" license=("GPL2") depends=("libusb") +options=('!libtool') source=("http://www.intra2net.com/en/developer/libftdi/download/$pkgname-$pkgver.tar…") -options=('!libtool') +md5sums=('524af6f39aefa1a4e8fac12c6be0ed06') build() { cd $srcdir/$pkgname-$pkgver sed -i '/no-install/d' examples/Makefile.in || return 1 ./configure --prefix=/usr make || return 1 - make DESTDIR=$startdir/pkg install + make DESTDIR=$pkgdir install } -md5sums=('d585c9758cb7085a4448c7c4ece07d8e')

1 0

[arch-general] Segmentation fault in X after last upgrade
by Magnus Therning 11 Nov '09

11 Nov '09

I just upgraded this morning and after a reboot X refuses to start. My /var/log/Xorg.0.log contains a message about a segmentation fault and a short backtrace. I'm on AMD64, with an nVidia card (I'm using the Xorg driver, nv). Anyone else seeing something the same behaviour? Any suggestions on how I can get my system back to normal again? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

11 20