- Arch-general - lists.archlinux.org

[arch-general] Importing s/mime certs into kmail - existing bug workaround?
by mike cloaked 07 Dec '12

07 Dec '12

I started to play with kmail to see if it will satisfy my needs for a mail client - but fairly quickly found I could not import my s/mime cert which led me to the bug report at: https://bugs.archlinux.org/task/31900 If anyone knows a workaround I would appreciate it. Thanks -- mike c

1 0

[arch-general] the media keys doesn't work in the login screen
by José Vilmar Estácio de Souza 07 Dec '12

07 Dec '12

Hi all. First of all, forgive my bad english. This is my first message to the list, forgive me if I am sending to the incorrect place. I installed arch in my laptop, a Dell vostro 3300. I am using gnome as my desktop and gdm to manage my login. Since I am blind I use orca as my screen reader in the graphical environment and speakup in text mode. I boot arch in text mode and after login in the console I issue the following command to activate gnome: sudo systemctl start gdm After I enter the above command, the login screen appears, orca begins to talk but I can not increment/decrement the volume using the media keys. After I login in gnome, the keys works ok. Any ideas on how to solve this problem? Thanks. -- {}S José Vilmar Estácio de Souza

1 0

[arch-general] Escape sequences instead of colors in terminal
by Marcel Korpel 06 Dec '12

06 Dec '12

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

3 3

[arch-general] Unable to contact D-Bus session bus [testing]
by Oon-Ee Ng 06 Dec '12

06 Dec '12

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.

2 3

Re: [arch-general] Boot loaders for Linux that can also boot FreeBSD
by Leonardo Dagnino 05 Dec '12

05 Dec '12

2012/12/3 Daniel F. Savarese <dfs(a)savarese.org> > > 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

1 0

[arch-general] rootfs remains in ro at boot on fresh install with new December ISO
by LANGLOIS Olivier PIS -EXT 05 Dec '12

05 Dec '12

Hi, I hope it is not caused by the shortcut that I have taken to update my usb install key from november iso to december iso as described in the other thread. The first symptom that I have observed is that dhcpcd isn't able to update /etc/resolv.conf I am going to provide as much relevant info so you can tell me what to look for 1. Installed from december iso on newly created GPT ext4 partitions 2. Bootloader GRUB2 3. Did a systemctl mask tmpfs as I am mounting a disk partition on /tmp from fstab 4. Double checked 2-3 times that all my mounts are rw in fstab 5. Once logged, I have no problem doing "mount -o remount,rw /" 6. I have removed the ro kernel parameter option in grub.cfg (BTW, why is this used at all? I'm a little bit ignorant about Linux booting good practices). By doing so rootfs still remains ro. I am suspecting either systemd or the content of the initramfs. Until now, those are still black boxes to me. What should I look at to resolve my rootfs ro problem? thank you very much! Olivier (A new Arch user and extremely happy to have found and tried your distribution!) ________________________________ 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.

3 5

[arch-general] No suspend in systemd
by Randy 05 Dec '12

05 Dec '12

Hello, Whenever I try to suspend my system using the systemd command 'systemctl suspend', it will not suspend and returns the following messages: Failed to issue method call: Operation not supported. Failed to issue method call: Access denied. Any idea what could be causing this to happen? Thanks, Randy

4 5

Re: [arch-general] [arch-dev-public] [RFC] dbus cleanup
by Tom Gundersen 03 Dec '12

03 Dec '12

On Mon, Dec 3, 2012 at 6:59 PM, Daniel F. Savarese <dfs(a)savarese.org> wrote: > If you merge the two packages, what am I supposed > to do? I can't simply remove /usr/bin/dbus-launch and > /etc/X11/xinit/xinitrc.d/30-dbus 30-dbus will go away, so that's not an issue. That leaves dbus-launch. I don't see why you would want to remove the binary? Is something on your system trying to call it, even if we remove 30-dbus? Cheers, Tom

3 2

Re: [arch-general] [arch-dev-public] [RFC] dbus cleanup
by Leonid Isaev 03 Dec '12

03 Dec '12

On Mon, 03 Dec 2012 12:59:47 -0500 "Daniel F. Savarese" <dfs(a)savarese.org> wrote: > > In message > <CAG-2HqUx+=R59_24ytS6JefkXWR9qCzfTBXuVi_S_9bxbF83fQ(a)mail.gmail.com> , Tom > Gundersen writes: > >I'd like to propose the following change to our two dbus packages: > > > > * make libx11 an optdep in dbus > > * merge dbus-core into dbus > > * move dbus to [core] > > > >This should not have much of an effect in practice, but should make > >things a bit clearer and especially the naming will be more in-line > >with upstream and other distros. > > For myself, and anyone else administering large numbers of dbus-free systems > (defined as having no running dbus daemons) running Arch Linux (perhaps I'm > the only one?), it adds a maintenance burden. Currently, because of the If you don't run dbus, just update routinely and pacman will figure out which packages to keep. Since dbus 1.6.8-3 conflicts and provides dbus-core, the latter will be removed. > incorrect package dependencies you mention, I have to remove the dbus package > from every system after an update. That extra step is inconvenient, but > manageable via automation. If you merge the two packages, what am I supposed > to do? I can't simply remove /usr/bin/dbus-launch and > /etc/X11/xinit/xinitrc.d/30-dbus because that defeats system versioning via > package management. That means I have to either maintain a custom dbus > package that omits dbus-launch or add a klugey NoExtract directive to NoExtract'ing 30-dbus and dbus-launch is not necessary because (a) They are harmless if dbus is not run; (b) 30-dbus is harmless even with a DE which is properly started from .xinitrc (I haven't even known about 30-dbus until today). > pacman.conf on all systems. I say klugey because names and locations of > files can change over time, making NoExtract fail silently and therefore > requiring one to test for such changes as part of one's system updating > procedures. That's why I maintain custom packages (60+ and counting) > instead of using more fragile alternatives. > > >We can see that the current naming has caused some confusion as most > >of the packages that depend on dbus should in fact be depending on > >dbus-core. > > My understanding (which may be incorrect) was that the separate packages > were created to allow users to opt out of having dbus-launch on their > systems to prevent programs from starting dbus-daemon willy nilly. > (If the same can be achieved via setting DBUS_SESSION_BUS_ADDRESS to > /dev/null then my objection is largely moot, even though setting that > environment variable is not a clean solution for my use case). Of course, > incorrect package dependencies defeat that goal, requiring one to forcibly > remove the dbus package when not required. It seems pretty clear that if > the problem you're trying to solve is incorrect package dependencies, the > correct solution is to correct the package dependencies, not to change the > packaging. By merging the packages you're indicating you no longer want > to make it easy for users to remove dbus-launch. That's your prerogative, > but I ask you to evaluate whether you really want to do that. Supposing > you don't want to do that, as an alternative I suggest that you rename the > dbus package to dbus-launch and dbus-core to dbus (or just leave it as > dbus-core) to resolve package naming confusion. Supposing there are no > longer enough dbus-avoiding users to justify keeping the packages separate, > then I ask you warn users in advance of the change so that people have an > opportunity to take the steps required to keep their systems running as > expected before an update surprises them. With systemd you can't avoid dbus and you can't avoid systemd. Therefore, dbus must be present. Note that on a server dbus-launch will not even start since you will not have libx11, and dbus-launch links to it. > > daniel > -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

1 0

Re: [arch-general] [arch-dev-public] [RFC] dbus cleanup
by Thomas Bächler 03 Dec '12

03 Dec '12

Am 03.12.2012 18:59, schrieb Daniel F. Savarese: > For myself, and anyone else administering large numbers of dbus-free systems > (defined as having no running dbus daemons) running Arch Linux (perhaps I'm > the only one?), it adds a maintenance burden. Running unsupported setups is a high maintenance burden. I'm not sure if we should care.

1 0