- Arch-general - lists.archlinux.org

[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%2B%3DR59_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

[arch-general] Fail to run startx
by Lu, Boying 03 Dec '12

03 Dec '12

Hi, All, I followed the instructions at https://wiki.archlinux.org/index.php/Beginners%27_Guide#Configure_pacman and https://wiki.archlinux.org/index.php/VirtualBox#Arch_Linux_guests to install the ArchLinux 2012.11.01 in VirtualBox (v4.2.4). My host OS is Windows XP. After installing the base system, I tried to configure X. But 'startx' failed and I found following error messages in the /var/log/Xorg.0.log: AIGLX error: vboxvideo does not export required DRI extension AIGIX: reverting to software rendering Can anyone tell me how to fix this? Thanks in advance. Boying

5 4

[arch-general] Last dbus upgrade in testing busting gnome-online-accounts ?
by fredbezies 03 Dec '12

03 Dec '12

I noticed something strange since last dbus upgrade : my online accounts keeps on expiring. I try to delete and recreate my online account, but after one or two minutes, I got a message that "an online account needs attention". Got this in my /var/log/everything.log : Dec 3 18:41:29 localhost dbus[333]: [system] Reloaded configuration Dec 3 18:41:29 localhost dbus-daemon[333]: dbus[333]: [system] Reloaded configuration Dec 3 18:41:29 localhost dbus[333]: [system] Reloaded configuration Dec 3 18:42:02 localhost goa[690]: /org/gnome/OnlineAccounts/Accounts/account_1354556510: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: Credentials not found in keyring (goa-error-quark, 0): Failed to retrieve credentials from the keyring (goa-error-quark, 4) [goadaemon.c:1248, ensure_credentials_cb()] Kinda related to last dbus update ?! -- Frederic Bezies fredbezies(a)gmail.com

2 3

Re: [arch-general] [arch-announce] December: time for a new install medium
by Robbie Smith 03 Dec '12

03 Dec '12

On 02/12/12 10:01, Arch Linux: Recent news updates: Pierre Schmitz wrote: > Pierre Schmitz wrote: > > Version 2012.12.01 of our install and rescue medium is available on our > [Download][1] page. The latest snapshot contains: > > * arch-install-scripts 9 with an improved fstab generator > > * linux 3.6.8 > > * systemd 196 > > * the usual updates to our core packages > > The next boring snapshot release is scheduled for January 2013. > > [1]: https://www.archlinux.org/download/ > > URL: https://www.archlinux.org/news/december-time-for-a-new-install-medium/ > _______________________________________________ > arch-announce mailing list > arch-announce(a)archlinux.org > https://mailman.archlinux.org/mailman/listinfo/arch-announce > I know it's not really necessary, but I always like to have the most up-to-date Arch live on my toolbox USB stick. Is there a recommended way to update an existing USB install medium (without overwriting other files?), or should I just follow the steps at [1], and update the syslinux configs each time? [1] https://wiki.archlinux.org/index.php/USB_Installation_Media#Without_overwri…

2 1