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 have just emerged net-misc/vnc-4.1.2 but it doesn't works with x11-base/xorg-server-1.0.2-r7. I get the following error in my /var/log/Xorg.0.log: (II) LoadModule: "vnc" (II) Loading /usr/lib/modules/extensions/libvnc.so (II) Module vnc: vendor="RealVNC Ltd" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (EE) module ABI minor version (3) is newer than the server's version (2) (II) UnloadModule: "vnc" (II) Unloading /usr/lib/modules/extensions/libvnc.so (EE) Failed to load module "vnc" (module requirement mismatch, 0) I bet it won't work with any xorg-server version 1.0.x as vnc-4.1.2 ebuild uses xorg-server-1.1.1 sources. Is xorg-server 1.0.x doomed in no-realvnc-land?
My # emerge --info Portage 2.1-r2 (default-linux/amd64/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-hardened-r11 x86_64) ================================================================= System uname: 2.6.16-hardened-r11 x86_64 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.12.4 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] app-admin/eselect-compiler: [Not Present] 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.17 sys-devel/autoconf: 2.13, 2.59-r7 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-r3 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="-O2 -march=k8 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distcc distlocks fixpackages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-mirror.internap.com/pub/gentoo/ http://gentoo.ccccom.com http://gentoo.mirror.sdv.fr http://gentoo.mirrors.pair.com/http://gentoo.ccccom.com/ http://gentoo.osuosl.org/" MAKEOPTS="-j5" PKGDIR="/var/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-fabrica /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 avi bitmap-fonts bzip2 cli crypt dlloader dri eds emboss encode foomaticdb fortran gif gpm gstreamer gtk2 imlib isdnlog jpeg ldap lzw lzw-tiff md5sum mp3 mpeg ncurses nptl opengl pam pcre pdflib perl png pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd tiff truetype truetype-fonts type1-fonts usb xorg xpm zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_vesa video_cards_vga video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Yes, it won't work...
Isn't the solution in this case to mask net-misc/vnc-4.1.2? IMHO it can't be part of the stable distro if it depends on unstable versions of other packages.
The solution for me was using tightvnc. (In the past tightvnc had a bug on amd64, that's why I had to switch.) It had a problem with font path, see bug 146099 for solution.
(In reply to comment #3) > Isn't the solution in this case to mask net-misc/vnc-4.1.2? No, because it works perfectly fine w/ xorg-server-1.1.1, why should we package.mask it? > IMHO it can't be part of the stable distro if it depends on unstable versions > of other packages. Go blame ATI/nVidia, or just stick it into your package.keywords until it's stabilized.
I was wrong. Of course it does not need to be masked just the dependency should be fixed (something like <=x11-base/xorg-server-1.1).
(In reply to comment #6) > I was wrong. Of course it does not need to be masked just the dependency > should be fixed (something like <=x11-base/xorg-server-1.1). You've got the dependency wrong, it's the other way round. And the dependency is already there anyway (just not for amd64 since it's been stabilized there meanwhile for some reason and xorg-server-1.1.1 is not stabilized there yet).
Hmmm...shall we stick with the stable version of xorg-server? I can switch backwards...at least i think so. amd64 and x86 doesn't have xorg-server-1.1 stabilized...so this ebuild will block people using stable... I don't know if the vnc module made using xorg-server-1.0 will work with 1.1. But, at least, 1.0 is stable.
I talked about this with jakub, forget my last comment :)
(In reply to comment #5) > (In reply to comment #3) > > Isn't the solution in this case to mask net-misc/vnc-4.1.2? > > No, because it works perfectly fine w/ xorg-server-1.1.1, why should we > package.mask it? > > > IMHO it can't be part of the stable distro if it depends on unstable versions > > of other packages. > > Go blame ATI/nVidia, or just stick it into your package.keywords until it's > stabilized. I still don't understand what are you proposing the regular Gentoo user (rGu) should do? As far as I understand, if rGu doesn't wants problems he should stick with stable packages. Sticking to stable packages should work. As far as I can tell, I am sticking to stable packages (at least the packages that matter for this issue). But realvnc isn't working with my X. Aren't stable packages supposed to work? I understand the modular X/ATI/Nvidia issue. I understand the current approach Gentoo choose (keeping X 7.1 masked for x86 and amd64). I don't understand vnc 4.1.2 being masked stable with a dependency on a package Gentoo choose to mask as unstable. What should I do to use realvnc and modular X? Or should I (as a rGu) not use them?
(In reply to comment #10) > I am sticking to stable packages (at least the packages that matter for this > issue). But realvnc isn't working with my X. Aren't stable packages supposed to > work? I've already explained to you what to do. If you dislike it, you can either not use this package or use older version that doesn't compile at all. > What should I do to use realvnc and modular X? Or should I (as a rGu) not use > them? Do as you wish. This bug is CLOSED, enough noise here.
(In reply to comment #11) > (In reply to comment #10) > > I am sticking to stable packages (at least the packages that matter for this > > issue). But realvnc isn't working with my X. Aren't stable packages supposed to > > work? > > I've already explained to you what to do. I believe the solution you proposed is to use X 7.1 even being masked. I will try it. If this really works, it might be a good idea to mention in vnc-4.1.2 that it only works with X >= 7.1. Others users won't be caught by the same trap I did. I couldn't understand your explanation on why the dependency on >=x11-base/xorg-server-1.1 was removed for amd64 machines. Whatever the reason is, I can assure that it is not working. It should be put back.
(In reply to comment #12) > If this really works, it might be a good idea to mention in vnc-4.1.2 that it > only works with X >= 7.1. Others users won't be caught by the same trap I did. The ebuild _dies_ when you have <xorg-server-1.1, need more notice? Can't imagine what more notice do you need, really.
(In reply to comment #13) > (In reply to comment #12) > > If this really works, it might be a good idea to mention in vnc-4.1.2 that it > > only works with X >= 7.1. Others users won't be caught by the same trap I did. > > The ebuild _dies_ when you have <xorg-server-1.1, need more notice? Can't > imagine what more notice do you need, really. The ebuild didn't died when I first tried. If it had died I wouldn't have a /usr/lib/modules/extensions/libvnc.so module at all (see my first comment). This bug report wouldn't exist at all if the ebuild had died. Unfortunately I can't test right now if the there was some change to the ebuild since that makes it die now if I am in a amd64 machine with X 7.0. Was there any change? I have just rechecked the ebuild but got confused by the use of the server USE flag in it so let me clarify that I emerged it with the server flag set. The emerge completed successfully without a problem. I still don't understand why the dependency on X 7.1 is removed from vnc-4.1.2 if running on an amd64 machine. This is the cause of the problem that originated this bug report in the first place.
(In reply to comment #14) > I still don't understand why the dependency on X 7.1 is removed from vnc-4.1.2 > if running on an amd64 machine. This is the cause of the problem that > originated this bug report in the first place. I've already told you in Comment #7. Enough noise here, this bug is closed.
(In reply to comment #15) > (In reply to comment #14) > > I still don't understand why the dependency on X 7.1 is removed from vnc-4.1.2 > > if running on an amd64 machine. This is the cause of the problem that > > originated this bug report in the first place. > > I've already told you in Comment #7. Jakub, the vnc-4.1.2 ebuild is wrong for amd64. It's clear that you can't see it or don't want to acknowledge it but it's wrong nonetheless: The ebuild uses a version of X (XSERVER_VERSION="1.1.1") and *doesn't* depend on it. Not for amd64 machines. Isn't this a bug in the ebuild?
OK, I've had enough... amd64, please drop the stable keyword, thanks.
(In reply to comment #17) > OK, I've had enough... amd64, please drop the stable keyword, thanks. Dropping the stable keyword is a nice "emergency action". The real solution depends on further changes of the ebuild (the possible solutions seems to be): or make it depend on x11-base/xorg-server-1.1 even on amd64 machines by removing the "!amd64?" part of line 42 "!amd64? ( >=x11-base/xorg-server-1.1 )" or making the ebuild not use x11-base/xorg-server-1.1 at all. I can't tell which, if any, is the appropriate solution.
(In reply to comment #18) > (In reply to comment #17) > > OK, I've had enough... amd64, please drop the stable keyword, thanks. > > Dropping the stable keyword is a nice "emergency action". > The real solution depends on further changes of the ebuild (the possible > solutions seems to be): > > or make it depend on x11-base/xorg-server-1.1 even on amd64 machines by > removing the "!amd64?" part of line 42 "!amd64? ( >=x11-base/xorg-server-1.1 )" It can't be amd64 stable AND depend on unstable >=x11-base/xorg-server-1.1, already tried to explain 3 times but it's completely hopeless. > or making the ebuild not use x11-base/xorg-server-1.1 at all. WTH? Do some research before posting even more pointless rants, please.
(In reply to comment #19) > > or make it depend on x11-base/xorg-server-1.1 even on amd64 machines by > > removing the "!amd64?" part of line 42 "!amd64? ( >=x11-base/xorg-server-1.1 )" > > It can't be amd64 stable AND depend on unstable >=x11-base/xorg-server-1.1, > already tried to explain 3 times but it's completely hopeless. No you didn't. You said precisely the opposite in comment #5: --- Begining of Jakub's comment --- (In reply to comment #3) > Isn't the solution in this case to mask net-misc/vnc-4.1.2? No, because it works perfectly fine w/ xorg-server-1.1.1, why should we package.mask it? --- End of Jakub's comment --- P
(In reply to comment #19) > > or make it depend on x11-base/xorg-server-1.1 even on amd64 machines by > > removing the "!amd64?" part of line 42 "!amd64? ( >=x11-base/xorg-server-1.1 )" > > It can't be amd64 stable AND depend on unstable >=x11-base/xorg-server-1.1, > already tried to explain 3 times but it's completely hopeless. No you didn't. You said precisely the opposite in comment #5: --- Begining of Jakub's comment --- (In reply to comment #3) > Isn't the solution in this case to mask net-misc/vnc-4.1.2? No, because it works perfectly fine w/ xorg-server-1.1.1, why should we package.mask it? --- End of Jakub's comment --- Péter Werner was the first to suggest to re-mask the vnc ebuild. I never said nor implied that the ebuild shouldn't be masked as you seem to believe. In my last comment I said masking is a good action. I also called it an emergency action which doesn't mean it is not good. Besides that I see you didn't understand my sugestion. I believe that the ebuild shall and will be masked. When I mentioned that the dependency on xorg-server-1.1.1 should be reinstated for amd64, I was talking about a necessary step towards the final solution for this issue. Another necessary step is unmasking xorg-server-1.1.1 in amd64. When all the necessary steps are taken the solution will be solved. It's simple. > > or making the ebuild not use x11-base/xorg-server-1.1 at all. > > WTH? Do some research before posting even more pointless rants, please. As I said, I was only exploring possible solutions in my last comment. You can call it "pointless rants", it's your call. You calling it "pointless rants" doesn't make it a pointless rant though.
(In reply to comment #20) > > It can't be amd64 stable AND depend on unstable >=x11-base/xorg-server-1.1, > > already tried to explain 3 times but it's completely hopeless. > > No you didn't. You said precisely the opposite in comment #5: Sigh... package.masked != unstable. > When I mentioned that the dependency on xorg-server-1.1.1 should be >reinstated for amd64 It can't be stable until xorg-server-1.1.1 is stable on amd64 if you want to depend on it, period. If you still don't see why the dependency wasn't there for amd64, there go do your research on keywording. > I was talking about a necessary step towards the final solution for this issue. The final solution is to drop stable amd64 keyword and drop !amd64? from DEPEND, it's pretty obvious and there's zero need for more noise on this bug.
I use vnc-4.1.2 with xorg-server-1.0.2 by temporarily installing xorg-server-1.1.1, then emerge vnc-4.1.2, followed by uninstalling xorg-server-1.1.1. I haven't had any issues using vnc this way.
vnc 4.1.2 was working perfectly on x86, but now it's blocked by this dependency. It is however, *not* blocked on my amd64 desktop (and I'm definitely not running xorg-server-1.1). Is the dependency in the ebuild really correct? It seems to work fine on both for me, it's just annoying that I can't emerge world on my laptop thanks to this blockage.
Yeah, that's because genstef added the xorg-server-1.1 just for everything else except amd64. I have to talk with him, so when he will reply to my ping i'll tell him about this.
I've got his answer back. The "everything else" except amd64 xorg-server-1.1 dependency is because amd64 has the package stabilized. Regarding your problem...hmmm, we're working with the ebuild without doing revbumps, so maybe your amd64 was out of sync? The blocker was done September 1st.
(In reply to comment #25) > I've got his answer back. The "everything else" except amd64 xorg-server-1.1 > dependency is because amd64 has the package stabilized. I'm sorry for bringing this issue again. I am not sure I understood: genstef says the vnc's dependency on xorg-server-1.1 was removed for amd64 to stabilize vnc-4.1.2 in amd64? If this is the case, I believe it's a bad move, as vnc-4.1.2 effectivelly uses xorg-server-1.1 but doesn't include xorg-server-1.1 in it's dependency list. It seems as a sure way to make things not work. I see that there is some code to halt the ebuild if the available xorg-server is older that 1.1. It's a different way to enforce dependency. The emerge didn't halt when I used it a few days ago. Maybe this code is newer. Or maybe this different way of enforcing dependency is not working. It's clear that vnc-4.1.2 dependency on >=xorg-server-1.1 is unavoidable if the "server" USE flag is set. What is strange is that for some reason people are preferring a different way to enforce this dependency in this particular case. What advantage is there in this different method of dependency enforcement? If the dependency exists, why not use the regular dependency enforcement method?
(In reply to comment #26) > I'm sorry for bringing this issue again. I am not sure I understood: genstef > says the vnc's dependency on xorg-server-1.1 was removed for amd64 to stabilize > vnc-4.1.2 in amd64? No, it wasn't. Damn dig out the CVS history if you care that much. http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/vnc/vnc-4.1.2.ebuild?rev=1.7&view=log
it's back to unstable now
