Am Mon, 25 Jan 2010 03:55:22 +0100
schrieb Sven-Hendrik Haase :
> My issue is that the cdrtools substitute cdrkit that Arch currently
> officially provides is not actively developed (current to last stable
> was around a year) and is technically inferior to cdrtools.
I don't know anything about t
At Montag, 25. Januar 2010 03:55 Sven-Hendrik Haase wrote:
> I know this is a going to be a probably tiresome discussion revived but
> I'd like to get this over with. I've been meaning to do it for a while now.
I support your opinion and use an own package for cdrtools but for me there was
a rea
2010/1/25 Xavier Chantry :
> On Mon, Jan 25, 2010 at 1:04 AM, wrote:
>>
>> It is the 'ssh -X zita2 emacs' that is very slow.
>> Running emacs locally is perfectly OK.
>> The previous install was F9, it used nv, and
>> the same 'ssh -X zita2 emacs' worked perfectly.
>> Nothing has changed on zita2
On 25/01/10 13:53, Allan McRae wrote:
On 25/01/10 12:23, Tavian Barnes wrote:
2010/1/24 Dan McGee:
You probably want a login shell, e.g. /bin/bash -l
Thanks. That fixed the PATH issue I was having but it turns out that was
not my real issue... see below
I'd go with (untested):
#!/bin/sh
On 25/01/10 12:23, Tavian Barnes wrote:
2010/1/24 Dan McGee:
You probably want a login shell, e.g. /bin/bash -l
Thanks. That fixed the PATH issue I was having but it turns out that
was not my real issue... see below
I'd go with (untested):
#!/bin/sh
exec linux32 /bin/bash "$@"
This
Hi all,
I have 4 boxes, all with the same partitioning scheme and using ext4
for all of them. This weird thing has only showed up in one of them.
Some time back while playing some video and with xscreensaver active,
the timeout for xscreensaver expired and then password was required...
Bad thin
I know this is a going to be a probably tiresome discussion revived but
I'd like to get this over with. I've been meaning to do it for a while now.
My issue is that the cdrtools substitute cdrkit that Arch currently
officially provides is not actively developed (current to last stable
was around a
2010/1/24 Dan McGee :
>
> You probably want a login shell, e.g. /bin/bash -l
>
I'd go with (untested):
#!/bin/sh
exec linux32 /bin/bash "$@"
--
Tavian Barnes
On Sun, Jan 24, 2010 at 7:49 PM, Allan McRae wrote:
> I am trying to seamlessly run an x86_64 kernel on my i686 machine. I have
> enough aliases that most things work right (prefixing with linux32), but
> bash can not handle setting e.g. "./configure" as an alias and there is
> always something I
I am trying to seamlessly run an x86_64 kernel on my i686 machine. I
have enough aliases that most things work right (prefixing with
linux32), but bash can not handle setting e.g. "./configure" as an alias
and there is always something I have missed.
So, I came up with a cunning plan... Crea
On Sun, Jan 24, 2010 at 7:26 PM, Andres Perera wrote:
> Is it strictly because it shouldn't depend on initscripts, or is there
> another reason?
makepkg is not Arch specific. That would quite clearly break that
non-dependency.
-Dan
Is it strictly because it shouldn't depend on initscripts, or is there
another reason?
On Mon, Jan 25, 2010 at 1:04 AM, wrote:
>
> It is the 'ssh -X zita2 emacs' that is very slow.
> Running emacs locally is perfectly OK.
> The previous install was F9, it used nv, and
> the same 'ssh -X zita2 emacs' worked perfectly.
> Nothing has changed on zita2.
>
> As far as I can see, the Arch
On Mon, Jan 25, 2010 at 12:27:26AM +0100, Xavier Chantry wrote:
> On Sun, Jan 24, 2010 at 11:50 PM, wrote:
> > Hello all,
> >
> > Today I installed Arch on my desktop which previously had Fedora.
> > All works well except
> >
> > ssh -X zita2 emacs
> >
> > where zita2 is my laptop.
> >
> > It wo
On Sun, Jan 24, 2010 at 11:50 PM, wrote:
> Hello all,
>
> Today I installed Arch on my desktop which previously had Fedora.
> All works well except
>
> ssh -X zita2 emacs
>
> where zita2 is my laptop.
>
> It works, but it is ex tre me ly slow, I can count
> the lines being displayed when scrolli
On Sun, Jan 24, 2010 at 4:09 PM, Eric Bélanger wrote:
> On Mon, Nov 2, 2009 at 3:49 PM, Tobias Powalowski wrote:
>> Hi
>> bump to latest version, please signoff.
>>
>> Changes to initcpio pcmcia hook were needed and added in git tree,
>> on next mkinitcpio bump they will be included.
>> - udev ru
Hello all,
Today I installed Arch on my desktop which previously had Fedora.
All works well except
ssh -X zita2 emacs
where zita2 is my laptop.
It works, but it is ex tre me ly slow, I can count
the lines being displayed when scrolling a page.
This used to work perfectly before.
Other apps do
On Mon, Nov 2, 2009 at 3:49 PM, Tobias Powalowski wrote:
> Hi
> bump to latest version, please signoff.
>
> Changes to initcpio pcmcia hook were needed and added in git tree,
> on next mkinitcpio bump they will be included.
> - udev rules and helper programs are now installed to /lib/udev/
>
> gre
Hi,
AlannY writes:
Hi there. I'm newbie in Archlinux and I have another lame question.
Recently, I've found that Arch mounts tmpfs on /dev. And, as you may see,
this makes big problem to some applications.
I see: "none on /dev type tmpfs" in the output of mount program.
This mount is not pla
> On Sun, Jan 24, 2010 at 2:14 PM, AlannY wrote:
>> Hi there. I'm newbie in Archlinux and I have another lame question.
>> I see: "none on /dev type tmpfs" in the output of mount program.
>> But nothing interesting found.
>> I really don't want to mount tmpfs on /dev. How to don't do it?
Class
On Sun, Jan 24, 2010 at 2:14 PM, AlannY wrote:
> Hi there. I'm newbie in Archlinux and I have another lame question.
>
> Recently, I've found that Arch mounts tmpfs on /dev. And, as you may see,
> this makes big problem to some applications.
Really? What type of problems? Because you will have muc
Hi there. I'm newbie in Archlinux and I have another lame question.
Recently, I've found that Arch mounts tmpfs on /dev. And, as you may see,
this makes big problem to some applications.
I see: "none on /dev type tmpfs" in the output of mount program.
This mount is not placed in /etc/fstab. So,
On Sun, Jan 24, 2010 at 3:01 AM, Heiko Baums wrote:
> See this bug report: http://bugs.archlinux.org/task/17231?project=6
>
> You should be able to continue booting by entering these commands
> at the ramfs$ prompt:
> udevadm trigger
> exit
>
> It's not a fix but a workaround. And this bug really
Quoted from http://bugs.archlinux.org/task/17298 (which is also to be
used for feedback, besides the threads on these mailing lists):
So, now something can be tested. I recommend using it in conjunction
with testing/udev only:
[kill-klibc]
Server = http://dev.archlinux.org/~thomas/kill-klibc/i686
Am Sat, 23 Jan 2010 20:43:42 -0500
schrieb Carlos Williams :
> Every time I try and install Arch Linux 2009.08 Netinst .ISO disk on
> my newly built PC hardware, I get the following error:
>
> Waiting for boot device...
> Error: Boot device didn't show up after 30 seconds...
> Falling back to int
25 matches
Mail list logo
