Re: [arch-general] Escape sequences instead of colors in terminal

[Martin Panter]

On 5 December 2012 23:14, Dave Reisner  wrote:
> On Dec 5, 2012 6:11 PM, "Marcel Korpel"  wrote:
>>
>> Hi all,
>>
>> I already asked this at the forums, but as no one has an answer there
>> I hope someone here knows a solution. On a Git cheat sheet I found
>> that I could add nice colors to Git's output, so I edited my
>> ~/.gitconfig by adding:
>>
>> [color]
>> ui = auto
>> [color "branch"]
>> current = yellow reverse
>> local = yellow
>> remote = green
>> [color "diff"]
>> meta = yellow bold
>> frag = magenta bold
>> old = red bold
>> new = green bold
>> [color "status"]
>> added = yellow
>> changed = green
>> untracked = cyan
>>
>> When performing a git log my terminal looks like this:
>> http://ompldr.org/vZ2t1bA (escape sequences instead of colors). The
>> same problem appears with git diff: http://ompldr.org/vZ2t1bg
>>
>> However, as you can see in the second screenshot, git status and git
>> branch look correct. This happens in urxvt, but also in xterm and the
>> terminal screens (tty[1-6]).
>>
>> Do you know what's wrong?
>>
>> Regards, Marcel
>
> Your pager is to blame. Assuming you're using less, you need to pass the -R
> option. You can add:
>
> export LESS=-R
>
> To your shell rc file.

As far as I can tell, Git seems to be able to set the less -R option
itself. But I notice it doesn’t work if the $LESS environment variable
is already set. So I’d suggest manually adding -R as Dave said, or
deleting the variable entirely.

Re: [arch-general] Unable to contact D-Bus session bus [testing]

[Oon-Ee Ng]

On Thu, Dec 6, 2012 at 8:40 AM, Tom Gundersen  wrote:
> On Thu, Dec 6, 2012 at 1:18 AM, Oon-Ee Ng  wrote:
>> I downgraded immediately due to having some things to finish off. At
>> that time dbus was at 1.6.8-4, now its 1.6.8-5 (just updated again as
>> today I have a bit of time to debug).
>
> Just to be clear: can you reproduce this bug with 1.6.8-5 (in [core])?

Yes, that's the one.
>
>> Most likely cause I can see is (may be) the filesystem update. I have
>> gshadow, shadow, group, and passwd pacnew files, but no idea how to
>> merge them (should I swap the dbus IDs from the pacnew files in?).
>
> Are you seeing a different uid/gid now compared to before? It should
> always have been 81/81.
>
> The only known issue is that in some rare circumstances you now have
> to manually start dbus-launch as we no longer ship the xinitrc.d file
> [0][1].
>
> Cheers,
>
> Tom
>
> [0]: 
> [1]: 

My issue is on the bug (posted same time as you a reply). Thanks. I'll
continue discussion there (in particular on whether this is a hack to
be fixed or a permanent thing).

Re: [arch-general] Unable to contact D-Bus session bus [testing]

[Oon-Ee Ng]

On Thu, Dec 6, 2012 at 8:18 AM, Oon-Ee Ng  wrote:
> Hi all, started having this problem a couple of days back with the
> dbus-core removal move (and corresponding filesystem update).
>
> http://pastebin.com/JKMN58jP is the result of journalctl -b
>
> A whole bunch of my applications cannot contact dbus. Firefox is one,
> even pulseaudio complains (though sound still works as it still runs,
> go figure). gnucash cannot start, etc. etc., but those are just
> symptoms. Oh, and ario and synapse are dumping core.
>
> I downgraded immediately due to having some things to finish off. At
> that time dbus was at 1.6.8-4, now its 1.6.8-5 (just updated again as
> today I have a bit of time to debug).
>
> Most likely cause I can see is (may be) the filesystem update. I have
> gshadow, shadow, group, and passwd pacnew files, but no idea how to
> merge them (should I swap the dbus IDs from the pacnew files in?). The
> original files worked after a downgrade.
>
> Thanks for your help & time.

Sigh, and of course after I sent the message (which was prepared
earlier) I realize that overnight as I slept there were forum posts
etc. about the topic.

https://bugs.archlinux.org/task/32952 said to start dbus-launch, which
seems to work, so adding to my xinitrc. Continuing discussion there.

Re: [arch-general] Unable to contact D-Bus session bus [testing]

[Tom Gundersen]

On Thu, Dec 6, 2012 at 1:18 AM, Oon-Ee Ng  wrote:
> I downgraded immediately due to having some things to finish off. At
> that time dbus was at 1.6.8-4, now its 1.6.8-5 (just updated again as
> today I have a bit of time to debug).

Just to be clear: can you reproduce this bug with 1.6.8-5 (in [core])?

> Most likely cause I can see is (may be) the filesystem update. I have
> gshadow, shadow, group, and passwd pacnew files, but no idea how to
> merge them (should I swap the dbus IDs from the pacnew files in?).

Are you seeing a different uid/gid now compared to before? It should
always have been 81/81.

The only known issue is that in some rare circumstances you now have
to manually start dbus-launch as we no longer ship the xinitrc.d file
[0][1].

Cheers,

Tom

[0]: 
[1]: 

[arch-general] Unable to contact D-Bus session bus [testing]

[Oon-Ee Ng]

Hi all, started having this problem a couple of days back with the
dbus-core removal move (and corresponding filesystem update).

http://pastebin.com/JKMN58jP is the result of journalctl -b

A whole bunch of my applications cannot contact dbus. Firefox is one,
even pulseaudio complains (though sound still works as it still runs,
go figure). gnucash cannot start, etc. etc., but those are just
symptoms. Oh, and ario and synapse are dumping core.

I downgraded immediately due to having some things to finish off. At
that time dbus was at 1.6.8-4, now its 1.6.8-5 (just updated again as
today I have a bit of time to debug).

Most likely cause I can see is (may be) the filesystem update. I have
gshadow, shadow, group, and passwd pacnew files, but no idea how to
merge them (should I swap the dbus IDs from the pacnew files in?). The
original files worked after a downgrade.

Thanks for your help & time.

Re: [arch-general] Escape sequences instead of colors in terminal

[Dave Reisner]

On Dec 5, 2012 6:11 PM, "Marcel Korpel"  wrote:
>
> Hi all,
>
> I already asked this at the forums, but as no one has an answer there
> I hope someone here knows a solution. On a Git cheat sheet I found
> that I could add nice colors to Git's output, so I edited my
> ~/.gitconfig by adding:
>
> [color]
> ui = auto
> [color "branch"]
> current = yellow reverse
> local = yellow
> remote = green
> [color "diff"]
> meta = yellow bold
> frag = magenta bold
> old = red bold
> new = green bold
> [color "status"]
> added = yellow
> changed = green
> untracked = cyan
>
> When performing a git log my terminal looks like this:
> http://ompldr.org/vZ2t1bA (escape sequences instead of colors). The
> same problem appears with git diff: http://ompldr.org/vZ2t1bg
>
> However, as you can see in the second screenshot, git status and git
> branch look correct. This happens in urxvt, but also in xterm and the
> terminal screens (tty[1-6]).
>
> Do you know what's wrong?
>
> Regards, Marcel

Your pager is to blame. Assuming you're using less, you need to pass the -R
option. You can add:

export LESS=-R

To your shell rc file.

Re: [arch-general] rootfs remains in ro at boot on fresh install with new December ISO

[LANGLOIS Olivier PIS -EXT]

Tom,

As requested, here is my fstab file. As you'll see, there is nothing fancy in 
it. /dev/sda1 isn't mounted as it is just my 2MB grub partition.

> > Since I didn't want a tmpfs mounted in /tmp, I did follow directives from
> the Beginners guide:
> >
> > systemctl mask tmp.mount
> >
> > The result of that thing is:
> >
> > 1. rootfs is ro.
> >
> > 2. My disk partition for /tmp speficied in fstab isn't mounted.
>
> FWIW, if you have a /tmp entry in your fstab you don't need to mask
> tmp.mount (the fstab takes precedence). The only time you need to maks
> tmp.mount is if you don't want a partition mounted on /tmp at all.
>
Yep, I have discovered that as well during my experiments :-)



CONFIDENTIALITY : This e-mail and any attachments are confidential and may be 
privileged. If you are not a named recipient, please notify the sender 
immediately and do not disclose the contents to another person, use it for any 
purpose or store or copy the information in any medium.


fstab
Description: fstab

[arch-general] Escape sequences instead of colors in terminal

[Marcel Korpel]

Hi all,

I already asked this at the forums, but as no one has an answer there
I hope someone here knows a solution. On a Git cheat sheet I found
that I could add nice colors to Git's output, so I edited my
~/.gitconfig by adding:

[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color "status"]
added = yellow
changed = green
untracked = cyan

When performing a git log my terminal looks like this:
http://ompldr.org/vZ2t1bA (escape sequences instead of colors). The
same problem appears with git diff: http://ompldr.org/vZ2t1bg

However, as you can see in the second screenshot, git status and git
branch look correct. This happens in urxvt, but also in xterm and the
terminal screens (tty[1-6]).

Do you know what's wrong?

Regards, Marcel

Re: [arch-general] Boot loaders for Linux that can also boot FreeBSD

[Leonardo Dagnino]

2012/12/3 Daniel F. Savarese 

>
> In message <1354198069.3059.6.camel@q>, Ralf Mardorf writes:
> >Until now I was comfortable with GRUB legacy, but now I add a FreeBSD
> >install to my machine and against the claims at
> >
> >http://en.wikipedia.org/wiki/Comparison_of_boot_loaders
> >
> >GRUB legacy does not boot FreeBSD (until now). I was thinking of
>
> grub 0.97 does boot FreeBSD.  I have Arch Linux and FreeBSD 9.0 running
> on an old (circa 1999) laptop and boot both using grub.  In case it's of
> any use to you, here's my grub.conf/menu.lst entry:
>
> title FreeBSD
> rootnoverify (hd0,0)
> makeactive
> chainloader +1
>
> daniel
>
>
That is not GRUB booting FreeBSD, that's GRUB chainloading FreeBSD's
bootloader.

-- 
Leonardo Dagnino

[arch-general] harddisk suspending far to often

[G. Schlisio]

hi,
after updating my laptop today [0] (no testing enabled) i notice that my 
harddisk keeps spinning down and up every 10 seconds or so.

might this be related to the update or where can i stop this?
help very appreciated
georg

[0] packages updated today:
pcre
libssh
tdb
bind
lshw
soundkonverter
sage-mathematics
lib32-glib2
lib32-harfbuzz
lib32-pango
lib32-fontconfig
latex-beamer
linux-headers
linux-docs
linux

Re: [arch-general] Secure Boot Support

[Dennis Herbrich]

On Wed, Dec 05, 2012 at 04:23:27PM +0100, Pierre Schmitz wrote:
> But Thomas is right: this has to be implemented and tested by those who
> own such hardware; which at this time we don't.

Seems like a perfect opportunity to spend some hard-earned donation money on a
test rig, no?

Greetings,
  Dennis
-- 
0D21BE6C - F3DC D064 BB88 5162 56BE  730F 5471 3881 0D21 BE6C

Re: [arch-general] Secure Boot Support

[Pierre Schmitz]

Am 05.12.2012 10:36, schrieb Thomas Bächler:
> We don't understand what to do here at all. That's why we the developer
> who will be packaging these things needs access to such a machine
> himself. I'd really have fun figuring this out, but I currently don't
> want to spend money on a new computer.

I don't plan to buy such a mainboard in the near future either. but in
general I would prefer to create our own keys and let the user import
those into the firmware. This way we would not depend on prebuild boot
loaders signed by Microsoft or anybody else. Security-wise this would
also be much saner.

But Thomas is right: this has to be implemented and tested by those who
own such hardware; which at this time we don't.

Greetings,

Pierre

-- 
Pierre Schmitz, https://pierre-schmitz.com

Re: [arch-general] Secure Boot Support

[Thomas Bächler]

Am 05.12.2012 00:57, schrieb kristof:
> I actually just bought a new laptop with secure boot capable UEFI, and
> if a generous developer could just release an iso with both the shim and
> grub-efi installed, then I (and the other Christoph) would gladly try it
> on our own machines.

Use archiso to create the ISO yourself, then submit patches.

> As far as I know, the only bootloader that the shim currently supports
> right now is GRUB2, because the shim is actually coded so that grub will
> call back to the shim to check the MOK list before it boots the kernel.

As far as I understand, you can just place any signed EFI file as
grubx64.efi, not just GRUB. Integration of the bootloader into MOK is
optional.


We don't understand what to do here at all. That's why we the developer
who will be packaging these things needs access to such a machine
himself. I'd really have fun figuring this out, but I currently don't
want to spend money on a new computer.




signature.asc
Description: OpenPGP digital signature