[arch-general] Important changes for mongodb 1.8.2-2

2011-07-01 Thread Thomas Dziedzic
In response to the following bug report https://bugs.archlinux.org/task/24983 I have applied the attached fix to mongodb and as a result there have been some backwards incompatible changes. dbpath has been changed to /var/lib/mongodb logpath has been changed to /var/log/mongodb/mongod.log There

Re: [arch-general] Something Broken with Perl!

2011-07-01 Thread clemens fischer
John K Pate wrote: > I had a breakage (with the same error message) with > rxvt-unicode-chinese from the AUR, but it was resolved upon upgrading > to the new version. I don't know if the fix was due to recompiling or > the new version, however. Note that I don't have any foreign, ie. non ARCH per

Re: [arch-general] Vodafone HSDPA key

2011-07-01 Thread Richard Schütz
Am 01.07.2011 23:14, schrieb Fons Adriaensen: Hello all, Is it possible to use Vodafone's (Italy) HSDPA USB key with Archlinux ? I'd want to use it without depending on any 'desktop' tools - just netcfg and whatever other command line tools it takes. Ciao, pppd with a small chat script is su

Re: [arch-general] Vodafone HSDPA key

2011-07-01 Thread Andrea Scarpino
On Friday 01 July 2011 21:14:36 Fons Adriaensen wrote: > Is it possible to use Vodafone's (Italy) HSDPA USB key > with Archlinux ? I'd want to use it without depending > on any 'desktop' tools - just netcfg and whatever other > command line tools it takes. Ciao, wvdial is enough. Anyway you didn't

[arch-general] Vodafone HSDPA key

2011-07-01 Thread Fons Adriaensen
Hello all, Is it possible to use Vodafone's (Italy) HSDPA USB key with Archlinux ? I'd want to use it without depending on any 'desktop' tools - just netcfg and whatever other command line tools it takes. Ciao, -- FA

Re: [arch-general] Something Broken with Perl!

2011-07-01 Thread Florian Pritz
On 01.07.2011 21:24, Steve Holmes wrote: > On 7/1/11, Florian Pritz wrote: >> On 01.07.2011 14:38, Steve Holmes wrote: >>> I still can't compile perl-moose but I get another lookup error so I >>> rebuilt the package that owns the library causing the error but still >>> no go. At least automake wo

Re: [arch-general] Something Broken with Perl!

2011-07-01 Thread Steve Holmes
On 7/1/11, Florian Pritz wrote: > On 01.07.2011 14:38, Steve Holmes wrote: >> I still can't compile perl-moose but I get another lookup error so I >> rebuilt the package that owns the library causing the error but still >> no go. At least automake works so I can build other packages. I have >> n

Re: [arch-general] [arch-dev-public] The need for /lib64 - testing please

2011-07-01 Thread v01...@gmail.com
2011/7/1 Myra Nelson : > On Thu, Jun 30, 2011 at 23:48, Allan McRae wrote: >> Hi all, >> >> I was looking at the /lib64 folder and wondering what it is really needed >> for...  It just seems clutter to me on a pure x86_64 system (or even with a >> multilib in lib32 folders like we have). As far as

Re: [arch-general] The need for /lib64 - testing please

2011-07-01 Thread Shridhar Daithankar
On Friday 01 Jul 2011 10:18:42 AM Allan McRae wrote: > If you want to try it out, just remove the /lib64 folder (after making > sure it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it. > Run your system as usual for a while and report any issues you come across. Never bothered to lo

Re: [arch-general] Something Broken with Perl!

2011-07-01 Thread Florian Pritz
On 01.07.2011 14:38, Steve Holmes wrote: > I still can't compile perl-moose but I get another lookup error so I > rebuilt the package that owns the library causing the error but still > no go. At least automake works so I can build other packages. I have > never seen such a colamity of errors wit

Re: [arch-general] Something Broken with Perl!

2011-07-01 Thread Steve Holmes
On Fri, Jul 01, 2011 at 09:40:22AM +0530, gt wrote: > Did you try rebuilding perl-scalar-list-utils? I did again just now and re-installed. automake still works but I still can't compile perl-moose but I get another lookup error so I rebuilt the package that owns the library causing the error but

Re: [arch-general] [arch-dev-public] The need for /lib64 - testing please

2011-07-01 Thread Thomas Bächler
Am 01.07.2011 12:16, schrieb Emmanuel Benisty: >> The problem is quite simple: The ELF binary hardcodes the path to the >> interpreter (which is the linker). Binaries that were compiled for other >> distributions or generic binaries distributed by third parties will have >> the path "/lib64/ld-linu

Re: [arch-general] [arch-dev-public] The need for /lib64 - testing please

2011-07-01 Thread Emmanuel Benisty
On Fri, Jul 1, 2011 at 3:10 PM, Thomas Bächler wrote: > Am 01.07.2011 06:48, schrieb Allan McRae: >> Hi all, >> >> I was looking at the /lib64 folder and wondering what it is really >> needed for...  It just seems clutter to me on a pure x86_64 system (or >> even with a multilib in lib32 folders l

Re: [arch-general] [arch-dev-public] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2

2011-07-01 Thread Thomas Bächler
Am 01.07.2011 11:23, schrieb cantabile: > One small problem with mkinitcpio: the -z flag doesn't do anything. > I had COMPRESSION="xz" in the config and tried -z lzop - compressed with > xz. I had COMPRESSION="lzop" in the config and tried -z lzma - > compressed with lzop. (Verified with lsinitcpio

Re: [arch-general] [arch-dev-public] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2

2011-07-01 Thread cantabile
On 06/30/2011 09:15 PM, Thomas Bächler wrote: This is a huge release and should stay in testing for a while. I want to point out two significant changes: 1) We now have a build() function instead of an install() function - the latter was an unfortunate conflict with the install utility. The hook

Re: [arch-general] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2

2011-07-01 Thread Thomas Bächler
Am 30.06.2011 20:15, schrieb Thomas Bächler: > This is a huge release and should stay in testing for a while. I want to > point out two significant changes: The ldd -> internal _ldd change broke image generation for 64 bit kernels on a 32 bit userspace. This can be worked around by using 'linux32'