Bug#607775: /usr/bin/vnc4server: cannot start vncserver
Package: vnc4server Version: 4.1.1+X4.3.0-37 Severity: grave File: /usr/bin/vnc4server Justification: renders package unusable I cannot start the vncserver. If I execute "vncserver" at the command line the message says that the server has started but the log file reports an error. I cannot connect to the server and the process has exited. I tried with and without my ~/.vnc/xstartup file. I created such a file for vncserver on other hosts, this is the first time I've used vncserver on this host. The logfile's contents are: Xvnc Free Edition 4.1.1 - built Mar 10 2010 22:35:30 Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Underlying X server release 4030, The XFree86 Project, Inc Wed Dec 22 10:39:58 2010 vncext: VNC extension running! vncext: Listening for VNC connections on port 5901 vncext: created VNC server for screen 0 error opening security policy file /etc/X11/xserver/SecurityPolicy Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/misc/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/75dpi/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! Fatal server error: could not open default font 'fixed' xsetroot: unable to open display 'paper:1' vncconfig: unable to open display "paper:1" Option "--login" is no longer supported in this version of gnome-terminal; you might want to create a profile with the desired setting, and use the new '--profile' option Window manager error: Unable to open X display paper:1 Failed to parse arguments: Cannot open display: Those font paths don't exist on my system, my fonts seem to be in /usr/share/fonts. The system's hostname is 'paper'. This logfile was generated when using no ~/.vnc/xstartup file, that is the vncserver placed its default file there. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vnc4server depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8GCC support library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libx11-62:1.3.3-4X11 client-side library ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxtst62:1.1.0-3X11 Testing -- Record extension li ii x11-common 1:7.5+8 X Window System (X.Org) infrastruc ii xbase-clients 1:7.5+8 miscellaneous X clients - metapack ii xserver-common 2:1.7.7-10 common files used by various X ser ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages vnc4server recommends: ii xfonts-base 1:1.0.1standard fonts for X Versions of packages vnc4server suggests: pn vnc-java (no description available) -- no debconf information signature.asc Description: Digital signature
Bug#446665: mercury: should this package be removed?
On Wed, Feb 20, 2008 at 06:43:27PM +1100, Peter Hawkins wrote: > Hi... > > On Feb 20, 2008 9:50 AM, Paul Bone <[EMAIL PROTECTED]> wrote: > > Mercury also supports 'grades', this makes it different to other > > compliers and more interesting to package. Each grade represents a > > complier backend and some options. There are two C backends, a Java > > backend, and Erlang backend and a MSIL backend. Options can include > > optional garbage collection (as apposed to never reclaiming memory), > > profiling support, debugging support and more. > > > > I'd like to package the library and runtime for each grade. These can > > all be installed concurrently and won't conflict. > > There are at least two issues you may have to deal with here: > * Mercury does not provide any guarantees about a stable library ABI, > so you'll have difficulty packaging grades using shared libraries and > not breaking applications when you update the libraries. Hrm, that's true. I know that at the top of each .m file in the standard library a comment describes the stability of the API exported by the library. I've also never seen any avalible call change, or go away. Some more interesting grades such as deep profiling change and can no-longer be linked with previous version of the same grade, dispite there being no mercury library code changes, only changes in the complier that will generate incompatible C code. (I'm currently working on such a change for the deep profilier). The real solution would be to standardize the API, and version the runtime along with libraries and programs compiled against it, which is a problem for upstream. Other solutions are static linking or placing the stable version number in the package name, (like zlib1g). Then programs may depend on the version they where compiled/developed against. This could get messy but since releases are sledom it may be ok. > * Mercury standard libraries can be very large (tens of megabytes in > some of the debug grades), so packaging every possible grade seems > rather wasteful of archive space. If you ask me, you need to pick a > small set of useful grades which cover most use cases. I'm not sure > how many architectures Debain supports at the moment, but if you > aren't careful you could easily consume hundreds of megabytes of > fileserver space just on Mercury library grades (10+ architectures * > 10s of Mb/grade * many grades). I begun listing the grades I think would be useful to package, I found about 6 grades, so that's not too bad. I'll list them properly when I build the package and check that I havn't forgotten any. We can also reduce space by limiting the architectures that this is avalible for, (If that's cool with Debian). I don't expect there to be much interest in arm, mips, mipsel or m68k. That said, I want mipsel packages for myself for another project :-) Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
On Tue, Feb 19, 2008 at 03:27:37PM -0500, Barry deFreese wrote: > Hi folks, > > Sorry for all of the CCs but all of you have expressed interest in > fixing/adopting this package (with the exception of QA). > > Do any of you still have an interest and/or a plan to fix this > package? According to the Mecury website, it is supposed to build with > gcc-4.1 which would be a hell of a lot better than gcc-3.x. > > Is that not the case? This thing has been orphaned a while and has an > RC bug over a year old. If no-one wants to fix it up, I will request > removal within the week. > > If I can help with packaging or fixing this thing, please feel free to > contact me and will gladly help if I can. Otherwise it's a goner. :-) > Hi Barry. I'm interested in re-packaging this, however it's going to be one of those things that gets a small amount of attention here and there. I'm one of the Mercury developers, so I use and develop on Mercury day-to-day. The Mercury website should be considered correct, this package (in debian) is a very old version of Mercury and I'd like to release a newer package based on the current stable version, and also ensure I can produce .debs for the current CVS HEAD. There are several components to mercury that I'd like to package in seperate binary packages. These are: + Complier + Runtime and Standard Library + Other tools such as debuggers and profilers. Mercury also supports 'grades', this makes it different to other compliers and more interesting to package. Each grade represents a complier backend and some options. There are two C backends, a Java backend, and Erlang backend and a MSIL backend. Options can include optional garbage collection (as apposed to never reclaiming memory), profiling support, debugging support and more. I'd like to package the library and runtime for each grade. These can all be installed concurrently and won't conflict. This will mean that there may be 6-12 mercury-related packages. And since I haven't packaged for Debian before this is rather an ominous task. I intend to read plenty of documentation and seek the help of [EMAIL PROTECTED] as appropriate. I usually use the ROTD releases, however that's mostly because I'm working on Mercury it's self. It is probably useful to package a stable release and a ROTD, since we havn't made a release for a while. Unfortunatly I can't make any progress of when this will be done, and I'm not yet sure the best way to do it. Will removing the old package from Debian make it harder for me to get this one in? If so I'd like it left in Debian until I'm able to complete this. But since I want to package the new stable version instead removing it may not affect me. Ray Ward: I'd like to addopt this, may I? If you agree I'll change O to ITA and make myself the owner on bug #379682. I've also CC'ed the [EMAIL PROTECTED] mailing list. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
