These are the packages that would be merged, in order: Calculating dependencies [nomerge ] gnome-base/gnome-light-2.22.0 [nomerge ] gnome-base/gvfs-0.2.3 USE="gnome hal samba -avahi -bluetooth -cdda -debug -doc -fuse -gphoto2 -keyring" [nomerge ] net-fs/samba-3.0.28a USE="acl cups fam pam python readline -ads -async -automount -caps -doc -examples -ipv6 -ldap -quotas (-selinux) -swat -syslog -winbind" LINGUAS="-ja -pl" [ebuild N ] app-admin/gamin-0.1.9-r1 USE="python -debug" [ebuild N ] dev-libs/glib-2.16.3 USE="fam -debug -doc -hardened (-selinux) -xattr" !!! Error: circular dependencies: ('ebuild', '/', 'dev-libs/glib-2.16.3', 'merge') depends on ('ebuild', '/', 'app-admin/gamin-0.1.9-r1', 'merge') (hard) ('ebuild', '/', 'app-admin/gamin-0.1.9-r1', 'merge') depends on ('ebuild', '/', 'dev-libs/glib-2.16.3', 'merge') (hard) !!! Note that circular dependencies can often be avoided by temporarily !!! disabling USE flags that trigger optional dependencies. Reproducible: Always Steps to Reproduce: 1. emerge -pv gnome-light 2. 3.
as per 23:15 < leio> drac: can be PDEPEND I think. Assign to glib maintainers (gnome@) 23:15 < leio> I hit it today at work too on a fresh install sorry if this a dupe.
try: USE="-fam" emerge -vp glib
I checked the code and gio with fam support needs fam.h... So yeah this is a nice and clean circular dep if virtual/fam is provided by gamin. However, gio like gnome-vfs can use inotify directly. So for some arches, the only way out is to either build glib with USE=-fam, install gamin and then rebuild glib with USE=fam or to use the original SGI fam... I don't see how we can find a fix that'll please everyone here. Ideas?
Just always build -fam and screw !linux... (Okay that was just a joke. Don't kill me.) Maybe it's time to split up gamin? Could we patch a local copy of fam.h into glib?
Seems like gamin is made out of two components - libgamin which provides the API and fam.h, and gam_server bits. If these were split up then glib would only need the libgamin parts (I think), which doesn't depend on glib, and gam_server could be PDEPEND
*** Bug 231296 has been marked as a duplicate of this bug. ***
*** Bug 231373 has been marked as a duplicate of this bug. ***
*** Bug 232225 has been marked as a duplicate of this bug. ***
Any news here? this is still visible if one starts with a fresh stage3 and desktop profile... (aka new user visible)
(In reply to comment #9) > Any news here? this is still visible if one starts with a fresh stage3 and > desktop profile... (aka new user visible) I've sent patches to the upstream bug to allow splitting gamin into 2 packages : libgamin (which doesn't need glib) + gam_server, thus breaking the cyclic dependency. All is left to do is to actually create the split ebuilds and to test them. The 5 patches are in the upstream bug, if anyone wants to beat me to it... Other long term solutions include bugging BSD folks to have a native BSD file monitoring back-end inside GIO...
still not fixed. This prevent a lot of packages, including for example git, from emerging for the first time...
did you look at the upstream bug ? remi worked out a few patches already, just need a new release or somebody to take care of creating the ebuild.
*** Bug 238795 has been marked as a duplicate of this bug. ***
Last patch doesn't apply for me: >>> Unpacking source... >>> Unpacking gamin-0.1.9.tar.gz to /var/tmp/portage/app-admin/libgamin-0.1.9/work >>> Unpacking gamin-patches.tar.bz2 to /var/tmp/portage/app-admin/libgamin-0.1.9/work * Applying various patches (bugfixes/splitting) ... * 0001-gam_server-should-use-DAEMON_-instead-of-LIBGAMIN_.patch ... [ ok ] * 0002-libfam-libgamin-does-not-need-glib.patch ... [ ok ] * 0003-make-libgamin_shared-a-noinst-libtool-helper-lib.patch ... [ ok ] * 0004-simplify-python-bindings-installation.patch ... [ ok ] * 0005-add-configure-switches-to-restrict-building-the-serv.patch ... * Failed Patch: 0005-add-configure-switches-to-restrict-building-the-serv.patch ! * ( /var/tmp/portage/app-admin/libgamin-0.1.9/work/patch/0005-add-configure-switches-to-restrict-building-the-serv.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/app-admin/libgamin-0.1.9/temp/0005-add-configure-switches-to-restrict-building-the-serv.patch-870.out * * ERROR: app-admin/libgamin-0.1.9 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 3157: Called epatch 'src_unpack' * environment, line 1790: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * The die message: * Failed Patch: 0005-add-configure-switches-to-restrict-building-the-serv.patch! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/app-admin/libgamin-0.1.9/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-admin/libgamin-0.1.9/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/'
Created attachment 166622 [details, diff] failed.patch Affected patch
Created attachment 166623 [details] 0005-add-configure-switches-to-restrict-building-the-serv.patch-870.out
No problem, it's because "user-cflags" patch must be applied before, sorry
Created attachment 166635 [details] libgamin-0.1.9.ebuild I have just done two ebuilds for this, they work for me but they can have some problems as I don't know much about gamin. Changes: 1. Dropped some redundant eclases already inheritted by autotools.eclass 2. I have packages all patches in a tarball to be provided in gentoo mirrors, for testing, you can safely copy it to your DISTDIR 3. "test" is restricted because it requires gam_server 4. Added old app-admin/gamin as a blocker for preventing file collisions 5. I have set libgamin to providing virtual/fam
Created attachment 166636 [details] gam_server-0.1.9.ebuild Compared with libgamin ebuild, this changes: 1. gam_server is not providing virtual/fam (this is done by libgamin except I have misunderstood this) 2. This don't install docs because they are previusly installed by libgamin
Created attachment 166637 [details] gamin-patches.tar.bz2 These are the patches with a tiny README file and with patches reordered for properly applying all of them
FYI, the 5 patches I've sent upstream apply on top of gamin trunk. I've re-discussed those patches a bit with Gilles and Mart, and I still think splitting is not a good idea. I think we should mask the "fam" useflag on !bsd arches and get it over with. (no one was able to tell me if such a thing was doable for sure...) Thanks
Maybe it's because cflags problem was fixed in trunk but 0.1.9 is still affected Masking fam USE flag seems ok but, Wouldn't be circular problem still affect to bsd users?
(In reply to comment #22) > Maybe it's because cflags problem was fixed in trunk but 0.1.9 is still > affected > > Masking fam USE flag seems ok but, Wouldn't be circular problem still affect to > bsd users? It would. We do need to break this into separate packages anyway, so I hope remi will just do that with his patches contributed upstream... (I think it was remi..)
Upstream has clearly declared gamin to be dead and obsolete. I don't think anyone upstream even *looked* at my patches. And to be honest, I really don't want for us to keep supporting it any longer. In fact, I would even go as far as to _remove_ gamin from Portage completely. Now, for *BSD (hi guys!). I would actually rather we took some time to port the file monitoring code from gamin to GIO. Honestly, it doesn't look that hard, but it'll require a BSD system. If our BSD friends could provide me/us with a virtualbox/vmware image with a simple freebsd on it, I could even volunteer to do it myself as it looks like a cool exercise. Of course, if someone wants to do it (because it'll probably take me some time to figure out how BSDs work), then that's fine. Roy/uberlord showed me the upstream freebsd GLib ports rely on FAM too for GIO. That's _really_ not the way to go, although I don't know what FAM they are using. Bottom line: 1) gamin is dead. Period. 2) fixing GIO instead of gamin seems a much better improvement for all If, of course, no one wants to bother, then let's go ahead with the split packages...
We maintain gamin. Non-GNOME stuff uses virtual/fam and not glib (for instance in the GNOME-2.20 timeline KDE relied much more on virtual/fam than GNOME did). We STILL need to fix this. So lets split it now, rather than wait until the code gets ported and let people still suffer circular deps on fresh installs for much longer.
Does FreeBSD have a more useful way in its kernel for file monitoring, that could be used instead of stupid inefficient polling that gamin currently does on BSD? For solaris glib recently got code for FEM (File Event Monitoring API) for example - the solaris file monitoring stuff. So if FreeBSD has something useful, we are looking at completely new code rather than migrating the polling code from gamin to glib anyway
I'm actually in favor of removing all gamin deps from gnome programs, and marking it maintainer-needed. We don't need to maintain something that upstream has abandoned. I already maintain one such package, and it's a pain in the behind. Not many gnome packages can use fam, and all the packages using fam have it optional.
(In reply to comment #27) > Not many gnome packages can use fam, and all the packages using fam have it > optional. Quite a few GNOME packages rely indirectly on gamin to be around for good functionality on Gentoo/FreeBSD.
(In reply to comment #27) > I'm actually in favor of removing all gamin deps from gnome programs, and > marking it maintainer-needed. We don't need to maintain something that > upstream has abandoned. I already maintain one such package, and it's a pain > in the behind. > > Not many gnome packages can use fam, and all the packages using fam have it > optional. > Why not split this and try to only use (depend on) gamin for gentoo-fbsd ?
That was part of my plan, but fbsd is near dead. The only person who seemed to know anything about gentoo-fbsd was Roy, and he's not even a dev anymore. If it were entirely up to me, I would ditch fam support from glib. If bsd folks want it, they can put it in an overlay or, better yet, fix glib. I have no hard feelings if my patches are never used, I would rather we got rid of gamin :) In the interest of full disclosure, I ran gamin's tests before and after I applied my five patches, and both gave me 17 or so errors. I don't even _know_ if my patches work. I just know they build correctly and that they don't make the number of errors go up.
Well, do what do you want (I didn't know gentoo-fbsd was near dead) but, I am using splitted gamin since I attached ebuilds here and I haven't noticied any regressions over "full gamin") Maybe one option could be mask "fam" use flag in all arches but fbsd and keep splitted gamin for fbsd, it would be in testing, then, I think that most of fbsd users would expect not having full support for gamin
Can anyone please tell in simple way what is best solution for the problem now? I have fresh install here, want to emerge gnome and found the problem. What is the best (for long term) what I can do now? Is the best way: # echo "dev-libs/glib -fam" >> /etc/portage/package.use # emerge -av gnome # rm /etc/portage/package.use # emerge -avuDN world ?
(In reply to comment #32) > Can anyone please tell in simple way what is best solution for the problem now? > I have fresh install here, want to emerge gnome and found the problem. What is > the best (for long term) what I can do now? > > Is the best way: > # echo "dev-libs/glib -fam" >> /etc/portage/package.use > # emerge -av gnome > # rm /etc/portage/package.use > # emerge -avuDN world > > ? Start with: $ USE=-fam emerge -1 gamin $ emerge -1 glib then everything goes OK ;-)
and finally it lands in portage, thanks all for all the work and notably remi for writing the patches, pacho for the ebuild and upstream for integrating it. Thanks guys. Please poke us in 30 days for stabilization if we forget about it.
*** Bug 250448 has been marked as a duplicate of this bug. ***
(In reply to comment #34) > and finally it lands in portage, thanks all for all the work and notably remi > for writing the patches, pacho for the ebuild and upstream for integrating it. > Thanks guys. > > Please poke us in 30 days for stabilization if we forget about it. If you mean: libgamin, I'm afraid it is still ~arch.
