Portage 2.1.1_pre3-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17.4 i686) ================================================================= System uname: 2.6.17.4 i686 AMD Athlon(TM) XP2400+ Gentoo Base System version 1.12.1 app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 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.17 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://gentoo.blueyonder.co.uk" LANG="fr_FR.UTF-8" LINGUAS="fr" 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X a52 acpi alsa avi bash-completion berkdb bitmap-fonts bonobo bzip2 caps cdparanoia cli crypt cscope cups dbus dlloader dvd eds emboss encode esd expat flac fontconfig foomaticdb gdbm gif gnome gnutls gstreamer gtk gtk2 gtkhtml hal ibgda imlib isdnlog javascript jpeg jpeg2k kde lcms ldap libg++ libwww mad mikmod mmap mmx mp3 mpeg ncurses nls nptl nsplugin offensive ogg opengl pam pcre pda pdf pdflib perl png pppd python quicktime readline reflection session spell spl sse ssl svg symlink theora threads truetype truetype-fonts type1-fonts udev unicode vorbis win32codecs wmf xml xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_fr userland_GNU video_cards_nv video_cards_none" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
AFAIK gossip depends on NetworkManager to reconnect after loss of connection. wontfix?
Well... then the ebuild needs some work. I have not check, but the dbus use flag is probably the mean of enabling communication between gossip and network manager. Gossip does not depend on network-manager. Maybe removing the dbus use flag to make it implicit if a network-manager use flag is enabled, in order to make gossip depend on the right version of network-manager might be a solution to this problem. Actually we could generalize the issue to all pieces of software talking to other pieces of software through a middleware: Should we figure out a *guideline* in order to manager such cases with uses flags?
Hi, Actually I don't know how much of the pottential of D-Bus is used in gossip, but i'm sure that it can be used for more than NetworkManager integration, such peekabo applet (and gnome-screensaver in the future). I don't believe removing dbus USE is necessary by now...
Well... then... enabling dbus use flag should declare all the dbus dependencies for gossip. Namely, network-manager, peekaboo applet etc... But I insist on the fact that if the autoconf allows it, we should be able to use finer grained use flags in order to really compile only the code we want. For instance, we should be able to compile support for peekaboo leaving network-manager away.
Gossip cannot declare NetworkManager as a dependency because it is not in Portage yet. It still isn't quite at the point where it should be - It *is* in the Gentopia overlay, but I will not be putting it into the Portage tree until .7 is released because of issues that will come up because of the things that .7 will fix. So while in theory, it would be nice, there are some issues with portage that do limit some things we can do - namely that we can't declare a dependency based on an overlay.
Okay then. Let this bug live till network-manager gets in portage and become a depency of gossip. I insist on the fact that if gossip autoconf allows finer grained control over the dbus services gossip will deal with, then it should be controlable through use flags.
Even so, networkmanager still shouldn't be under a dbus flag in gossip. And gossip autoconf allows no control whatsover over what dbus functionality is exposed/used.
Well... then that's things to do upstream. I don't think that will be easy to rip off support for the different dbus services from the code.
So... submit a patch upstream?
First, network-manager should go into portage... then we may supply patches upstream to enable/disable dbus services, or brutally provide "rip the unwanted code" patches with the ebuild (I don't know the code, but I guess that won't be easy).
It is the beauty of d-bus integration that there is no need to en-/disable pieces of code for such things. It is higly unlikely that a patch would make it upstream, as there is no benefit to it. The best we could do in the future is adding a conditional runtime dep on NM for those who need it (hardly useful for desktop users). Anyway, this still may be a real bug, since afaik jabber has some keepalive system and that should detect disconnections as well.
Well, if the futur network-manager use flag is not enabled, the dbus network-manager code from gossip should be not be compiled. Using macros and/or constants will make gcc optimise out the code you don't want. I understand that on a binary distro the entire dbus services code from gossip must be compiled in order to enable or not those services at run time. Gentoo is a source distro. We can do better than binary distros-->get rid of the code we don't want.
If gossip actually depends on NM to reconnect, then the solution is to see if NM is running via D-Bus. Runtime dependencies shouldn't be compiled out unless they force a new package to be emerged. With D-Bus, it's not the case. The code just needs to check for NM and disable itself if NM is not found, it's as simple as that. As for gcc optimizing useless code, for this particular case, I'd be willing to bet it wouldn't save more than 4 kB off of the gossip binary, because gossip would still link against the same libraries. If you could file a bug upstream, and post a link back here. Thanks
Indeed, we are looking at, maybe, 4k for the gossip package and probably removing useless runtime depencies. But the "remove, as much as possible, code" guideline is true for *all* gentoo ebuilds. This guideline is justified only if you look at the global gain it brings. This is our only shield against bloat and unwanted dependencies.
Please stop this pointless discussion about a hypothetical situation. It is not going to happen, not upstream, not in Gentoo. It is not bloat and it doesn't introduce dependencies, get your facts straight before claiming such things. If you want to be useful figure out why the disconnection detection code without using NM doesn't work.
It does not work because it seems that there is no such code. As far as drilled down into gossip code, the only reconnect code I saw was the one using network-manager. And this is in the case of a loss of network connection, not a jabber session loss due to, for instance, server disfunctioning.
From gossip-0.16 NEWS: - Fixed #121003, Don't ask to reconnect, just do it (Xavier Claessens) Looking at the patch in the upstream bug, it seems as if it will reconnect when NM tells the network is back IF HAVE_DBUS preprocessor macro is defined, and just try every 10 seconds if it isn't. Does it not work because upstream doesn't differentiate between having DBUS and having NM available, or is it fixed since 0.16?
works like a charm here (gossip-0.23, networkmanager-0.6.5), closing
