Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I installed sys-apps/dbus-1.0.1-r2 and did /etc/init.d/dbus restart: fairtrade vmware # /etc/init.d/dbus restart * Starting D-BUS system messagebus ... Failed to start message bus: Failed to read directory "/etc/dbus-1/system.d": No such file or directory [ !! ] # mkdir /etc/dbus-1/system.d did it then ...
emerge --info: Portage 2.1.2_rc3 (default-linux/amd64/2005.1, gcc-4.1.1, glibc-2.4-r4, 2.6.18-gentoo-r3 x86_64) ================================================================= System uname: 2.6.18-gentoo-r3 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.6 Last Sync: Sat, 09 Dec 2006 14:20:01 +0000 ccache version 2.3 [disabled] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=k8 -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://130.59.10.34/mirror/gentoo/ http://130.59.10.35/mirror/gentoo/" LANG="de_DE.utf-8" LC_ALL="de_DE.utf-8" LINGUAS="de cz it fr en" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="amd64 X aalib alsa arts audiofile berkdb bitmap-fonts bzip2 cdr cjk cli cracklib crypt css cups dlloader dri dvd dvdr eds elibc_glibc emboss encode foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 iconv imlib immqt-bc input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg jpeg2k kde kernel_linux linguas_cz linguas_de linguas_en linguas_fr linguas_it lzw lzw-tiff mozilla mp3 mpeg musicbrainz mysql ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pango pcre pdf perl png pppd python qt qt3 qt4 quicktime readline reflection samba sasl sdl session spell spl ssl tcpd tiff truetype truetype-fonts type1-fonts unicode usb userland_GNU video_cards_fbdev video_cards_nvidia video_cards_vesa video_cards_vga vorbis xorg xosd xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
I can't seem to reproduce this, im guessing you did this in a vmware image?
No, I didn't, and I cannot see how this should be related?! Well, I think I switched (involuntarily) several times between 0.6x and 1.0.1 due to these strange circular dependencies.
Can't reproduce it here either. Either way, you'll run into problems using ~arch dbus on a stable arch system. Hence, the circular depends. Also it's very possible since you're using a deprecated profile. And as another total side note, if you're gonna install ccache... at least enable it.. FEATURES="ccache" in /etc/make.conf. And don't remove "-pipe" from your CFLAGS, that will increase your compile times since files have to be written to disk then read back rather then going through pipes... i.e. memory copies.
Hi, I run ~x86 and have had the following versions active: #>> grep /dbus /var/log/emerge.log | grep -e 'unmerge success' -e 'completed emerge' | awk '{$1=strftime( "%c", gensub( ":", "", 1, $1 ) ); print}' ... Sat Nov 25 23:09:04 2006 ::: completed emerge (82 of 284) sys-apps/dbus-0.62-r1 to / Sun Dec 10 04:20:00 2006 >>> unmerge success: sys-apps/dbus-0.62-r1 Sun Dec 10 04:20:00 2006 ::: completed emerge (166 of 554) sys-apps/dbus-1.0.1-r2 to / Mon Dec 11 02:06:41 2006 >>> unmerge success: sys-apps/dbus-1.0.1-r2 Mon Dec 11 02:06:41 2006 ::: completed emerge (21 of 53) sys-apps/dbus-0.62-r1 to / Wed Jan 10 06:01:17 2007 >>> unmerge success: sys-apps/dbus-0.62-r1 Wed Jan 10 06:01:17 2007 ::: completed emerge (7 of 11) sys-apps/dbus-0.62-r2 to / Fri Jan 12 17:46:31 2007 ::: completed emerge (288 of 332) sys-apps/dbus-0.62-r2 to / #>> last -15 reboot reboot system boot 2.6.18-suspend2 Fri Dec 22 17:54 (21+03:34) reboot system boot 2.6.18-suspend2 Sat Oct 7 04:08 (97+18:20) ... This time, after emerging, i tried to restart dbus (reload failed, so I restarted) which failed because of the missing "system.d". After checking /etc/dbus-1/system.conf, I simply created system.d and startup went fine. So, maybe the postins(?) for dbus-0.62-r2 and newer should include a "mkdir -p system.d"? Regards, Dominik
Can't reproduce this AT ALL. Unless you guys can give us info how to reproduce it, we can't fix it. A lot of packages actually create files in that directory so it should always exist.
(In reply to comment #6) > Can't reproduce this AT ALL. Unless you guys can give us info how to reproduce > it, we can't fix it. A lot of packages actually create files in that directory > so it should always exist. > It 'should' exist. But if I never had any of these packages on my machine than it apparently doesn't exist. For example on our main server with KDE and GNOME the directory exists and: # equery belongs /etc/dbus-1/system.d [ Searching for file(s) /etc/dbus-1/system.d in *... ] gnome-extra/gnome-power-manager-2.16.2 (/etc/dbus-1/system.d) sys-apps/hal-0.5.7.1-r5 (/etc/dbus-1/system.d) sys-apps/dbus-1.0.2-r1 (/etc/dbus-1/system.d) On a desktop of a colleague without GNOME (and without any package that would pull in hal) the directory does not exist and: # equery belongs /etc/dbus-1/system.d [ Searching for file(s) /etc/dbus-1/system.d in *... ] sys-apps/dbus-1.0.2-r1 (/etc/dbus-1/system.d)
(In reply to comment #7) > On a desktop of a colleague without GNOME (and without any package that would > pull in hal) the directory does not exist and: > # equery belongs /etc/dbus-1/system.d > [ Searching for file(s) /etc/dbus-1/system.d in *... ] > sys-apps/dbus-1.0.2-r1 (/etc/dbus-1/system.d) > Case in point, it is created by dbus as it should be. My point was other applications will create that directory and stick files in there.
I have the same problem. In fact, it is properly created by dbus, but as it is empty, it is removed by Portage when cleaning the tree. I have dbus installed only because of gthumb, gedit, and vlc (libnotify), which do not seem to write anything in this directory. Please reopen, and add a `keepdir /etc/dbus-1/system.d`, somewhere in the ebuild. ################################################################################ [...] --- /etc/dbus-1/ >>> /etc/dbus-1/system.d/ >>> /etc/dbus-1/system.conf [...] --- !empty dir /etc/init.d <<< dir /etc/dbus-1/system.d --- !empty dir /etc/dbus-1 [...] ################################################################################
I confirm Mathieu's observation, with sys-apps/dbus-1.0.2-r2. Some more experimentation reveals that two things can happen: 1) If /etc/dbus-1 does not exist at all, then /etc/dbus-1 and /etc/dbus-1/system.d will both be created when you emerge dbus. All is well. 2) If /etc/dbus-1 already exists, but /etc/dbus-1/system.d does NOT exist, then when you emerge dbus, it creates and then promptly REMOVES /etc/dbus-1/system.d. You can artificially provoke this behavior by doing: emerge dbus rm -rf /etc/dbus-1/system.d/ emerge dbus What I don't understand is how situation 2 can happen, short of manually removing the directory like that - but it evidently DOES happen. Is it possible that some other package previously created /etc/dbus-1, but did not create (or removed) /etc/dbus-1/system.d ? FWIW, my emerge.log reveals that on this system I have only ever had versions dbus-1.0.1-r1 and dbus-1.0.2-r2 installed.
I'll add the keepdir.
Fixed in 1.0.2-r2.
