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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
16 matches
Mail list logo