Platform is Gentoo Prefix on SUSE Enterprise Desktop 10. GCC version in the prefix is gcc-4.2.4-r01.2 p1.1. Attempting `emerge gnome-terminal' causes this console output: emerge: there are no ebuilds to satisfy ">=sys-fs/udev-138". (dependency required by "gnome-base/gvfs-1.4.1" [ebuild]) (dependency required by "gnome-base/libgnome-2.28.0" [ebuild]) (dependency required by "x11-terms/gnome-terminal-2.28.1" [ebuild]) (dependency required by "gnome-terminal" [argument])
udev doesn't make sense in prefix, right? I think we can mask the USE flag globally. local:udev:gnome-base/gvfs: Enable udev base replacement code for cdda feature local:udev:media-sound/pulseaudio: Use sys-fs/udev for autodiscovery of sound devices; this replaces the deprecated sys-apps/hal autodiscovery code. local:udev:media-sound/rhythmbox: Enable hardware detection via sys-fs/udev replacing the deprecated sys-apps/hal code. local:udev:media-video/vlc: Enables Linux udev services discovery. local:udev:net-misc/connman: Enable udev support. local:udev:net-misc/ofono: Use sys-fs/udev for modem detection.
makes sense to me...
Index: use.mask =================================================================== RCS file: /var/cvsroot/gentoo-x86/profiles/prefix/use.mask,v retrieving revision 1.3 diff -u -r1.3 use.mask --- use.mask 30 Jun 2009 14:13:04 -0000 1.3 +++ use.mask 24 Nov 2009 16:03:30 -0000 @@ -27,3 +27,6 @@ # USE=pam just does not make sense in Gentoo Prefix. Should be using the host # auth system. pam + +# USE=udev just does not make sense in Gentoo Prefix. bug 293480 +udev
dang, this bug is still there. gvfs-1.4.3.ebuild: RDEPEND="<snip> >=sys-fs/udev-138 <snip>" I propose "prefix? ( >=sys-fs/udev-138 )"
(In reply to comment #4) > dang, this bug is still there. > > gvfs-1.4.3.ebuild: > RDEPEND="<snip> > >=sys-fs/udev-138 > <snip>" > > I propose "prefix? ( >=sys-fs/udev-138 )" > That is there because of --enable-udev which is hardcoded in configure. I need to summarize proposed changes and re-assign to gnome team.
Created attachment 214665 [details] gvfs-1.4.3-prefix.patch
(as discussed with nirbheek in IRC) The gvfs ebuild has an explicit --enable-udev call for configure. This won't really work for Gentoo Prefix platforms, where we have to rely on the host udev (if it exists, if your on linux). So, please see the attached patch that sets --disable-prefix if you are using a prefix profile (USE=prefix, implicit flag). The patch also has some other fixes in it for Solaris and interix. I'm in #gentoo-desktop if you want to discuss. ;) Thanks.
(In reply to comment #7) > (as discussed with nirbheek in IRC) > > The gvfs ebuild has an explicit --enable-udev call for configure. This won't > really work for Gentoo Prefix platforms, where we have to rely on the host udev > (if it exists, if your on linux). So, please see the attached patch that sets > --disable-prefix if you are using a prefix profile (USE=prefix, implicit flag). --disable-udev, I meant. > > The patch also has some other fixes in it for Solaris and interix. I'm in > #gentoo-desktop if you want to discuss. ;) > > Thanks. >
udev changes: ack solaris/interix changes, mostly ok, just make sure upstream is aware that it misses cflags and proper autoconf tests to build properly on solaris/interix or add a note if it's not relevant for upstream to know about it. About the use of mktemp, like in bug #243206, I strongly disagree with such change, it is documented to be a security risk and should not be used. glib has equivalent platform agnostic functions afaik.
man is your friend :) . It's really deprecated to use mktemp for security issues. there is not another alternative ? really ? In the worst case, a random name could be generated using the buffer entropy.
(In reply to comment #10) > man is your friend :) . It's really deprecated to use mktemp for security > issues. Guys, we are talking about an OS that is many years old.. There is no mkdtemp. It is out of my skillset to come up with an alternative. http://docs.sun.com/app/docs/doc/816-5165/mktemp-1?a=view Anyway, I'm not a primary Solaris user so I just made a complete prefix diff for you. The changes were created by more familiar users than myself. I have nothing else to add, sorry. > there is not another alternative ? really ? > In the worst case, a random name could be generated using the buffer entropy. >
What is the final decision on this? Apply full patch or drop mktemp part?
why not udev? ( >=sys-fs/udev-138 ) iso prefix? ( ... ) actually? since it's +udev in the ebuild, I guess that also means a $(use_enable udev) makes sense?
(In reply to comment #13) > why not udev? ( >=sys-fs/udev-138 ) iso prefix? ( ... ) actually? > > since it's +udev in the ebuild, I guess that also means a $(use_enable udev) > makes sense? > I would prefer to see another gnome team member's opinion since I don't know much about it :-|
I've no problem including most of these changes as said in comment #9. However, re-reading the patch and my comment, it appears that mkdtemp cannot be replaced by mktemp or a glib equivalent. The burn backend really wants a directory. Could someone from prefix tell us if the burn backend really works on solaris ? If not or if it not pertinent for the platform, we could try simply disabling it.
prefix team, could you ask to comment #15 please? Thanks
(In reply to comment #15) > Could someone from prefix tell us if the burn backend really works on solaris ? > If not or if it not pertinent for the platform, we could try simply disabling > it. Sorry, what is the burn backend for exactly? I've lost track of this bug now.
I believe it is the backend for handling blank cd/dvd, the stuff needed to open the brasero plugin in nautilus.
(In reply to comment #18) > I believe it is the backend for handling blank cd/dvd, the stuff needed to open > the brasero plugin in nautilus. can we make it optional and just mask it?
that's most likely doable
I don't have burning equipment available in my Sol boxes, so in any way, I can't test it, even if it would be supported.
Looks like we would need to patch daemon/Makefile.am for disabling burn backend
if mkdtemp is required, we have to resort to gnulib's one. GNOME VFS seems to be deprecated though: http://library.gnome.org/devel/gnome-vfs-2.0/ I wonder what 2.24.0 is actually doing compared to 1.4.3 in this case (for the solaris problems)
(In reply to comment #23) > if mkdtemp is required, we have to resort to gnulib's one. > > GNOME VFS seems to be deprecated though: > http://library.gnome.org/devel/gnome-vfs-2.0/ > > I wonder what 2.24.0 is actually doing compared to 1.4.3 in this case (for the > solaris problems) GNOME VFS (gnome-base/gnome-vfs) != Gvfs (gnome-base/gvfs). They are two entirely different packages. gnome-vfs was replaced by gvfs about two years ago, and will be removed from the tree as soon as possible.
+*gvfs-1.6.7-r1 (27 Jun 2011) + + 27 Jun 2011; Pacho Ramos <pacho@gentoo.org> +gvfs-1.6.7-r1.ebuild, + +files/gvfs-1.6.7-fix-renaming.patch: + Apply patch fixing renaming issues with afc backend, allow to build without + udev on prefix (bug #293480 by Rabbe Fogelholm). +
