> libgii_0.8.1+rc3-1 and libggi_2.0.1+rc3-2 should soon be apt-getable > >from Debian unstable for architectures: alpha arm hppa i386 ia64 m68k > mips mipsel powerpc s390 sh sparc.
Awesome! BTW: What is 'sh' ? And what's the difference between mips and mipsel? Which powerpc it is exactly? Motorola G3 or G4? IBM PPC64? > For the final release: Shared dynamic libs must not link to static > libs, they were not built with -fPIC. > > For rc3 i patched the helper and dga makefile.ins and configure, adding > a note in the changelog that this wouldn't stand for long. Anybody > doing automake or autoconf now would again link to the wrong libs. > > The library names are Xxf86dga_pic.a and Xxf86vm_pic.a. I don't think > that they are debian specific, not confirmed by me. Could you send me a diff of your changes, please? Simplifies the inclusion for me. > Some reasoning can be found here (same link as already sent before): > http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00028.html > > > Other fixes to be resolved: > > configure: ac_x_include empty, no X helpers are configured. I mailed > Christoph a little more about the details. I think, this is a bug in debian's autoconf as I already explained you. Please talk with the debian's autoconf maintainer about this issue. > ltmain.sh: updated from 1.922.2.110 2002/10/23 01:39:54 to 1.922.2.111 > 2002/10/23 02:54:36, looks like a joke, unfortunately it isn't. With > .110 either old, installed libs are linked or build fails otherwise. I am still wondering, why the libtool folk still do NOT include the debian fixes into their CVS repository. Are debian's libtool fixes too specific to a shell? > glide/gtext.c and glide/visual.c both(?) need config.h. Just fixed in CVS. Can't test this, but adding an include of an always existing file never hurts... :) > Btw., i build against glide2, don't have hardware, should i use glide2 or 3? I don't know. Sorry. > ggidirectfb/directfb.h: fbdev.h seems to have moved into its own subdir > directfb-internal/core/fbdev/fbdev.h in 0.9.13 ... :-/ > Rc3 *disabled* directfb, there were more probs ... Brian updated the directfb driver. I don't know, whether he updated it to build with directfb 0.9.13, 0.9.14 or 0.9.15. > ggiteleserver.[17]: I once wrote a manpage for this (now in 1, > referencing your new one under SEE ALSO ...7). Should you decide to > move yours from 7 to 1, i'd have to remove mine, no problem. Only: mine > lists the options, having one without, would i personally see as a > drawback. Your decision, anyway. You may replace yours with ours. :) > > Other issues to be resolved: > > I already asked this: Do i see and do it correctly: display-x now > replaces old x and xlib, display-dga is continued for now? > This affects the package description (and the modules included :). Yes. display-dga still persists, because nobody wrote a xf86dga _helper_ target for x. > Copyright: no longer LGPL? I still include a notice saying so. This is > important, sorry. Please clarify (for me). Demos are generally public domain. GGI is under the BSD license and most targets, too. Some of them may under the LGPL... We should really change everything (but the demos) to use either BSD _or_ LGPL. Any objections? > Demo programs, libggi-samples package: currently includes monitest, > teleserver and cube3d as binaries, all the rest as source examples. Not > only would it be nice to (make) _install_ (! got it now?) some more > binaries ready to run (at least flying_), but i also noticed, that some > include config.h. That makes them a little less easily compilable ... Well, flying_ggis can NOT be build without the config.h. I tried that and got this: In file included from flying_ggis.c:32: /usr/include/stdlib.h:198: conflicting types for `rand' /usr/include/stdlib.h:129: previous declaration of `rand' > lcd823: If this is usefull, it would become an arch-specific target > (like glide and svgalib are for i386). I would need some input to > prepare a package description (don't have hardware). This is a linux specific target for the powerpc architecture. lcd823 is a motorola chip or something like that. > More Debian issues: There is some new infrastructure available to eg. > let upstream (you, my dear! :) subscribe to bugreports and such. > > More on that from me ASAP. I didn't tell you, because all the real bugs > were solved and there are only lots of old bugs around in the debian > BTS, that do not apply! -- Don't waste time on them! -- > > I don't want to ask sysadmin or install any display target as default. > So, the libggi packages' description clearly says 'You need to install > a target pkg' and 'Recommends' them, but the (once thought as low > level) installation tool apt-get does not care for this field and so > does not install any target by default, other pkg tools do so, however. > So, all bugs regarding this fact are irrelevant for libggi. BTS allows > to merge related bugs, and i did so, but this is not easily obvious in > the output. I will, ASAP, close all of them, after i have again tested > the relevant applications, that they run fine with GGI in any other > respect. Again: -- Don't waste time on these bugs! -- > > All real bugs have been worked on. > I didn't have time lately to _run_ apps ;), but > - using svga without configuring svgalib correctly beforehand may make > the mouse go wild and > - it is clear to me, but users may be puzzled/annoyed by screen > switching issues and behaviour after leaving a ggi app. Yeah, there's an known issue, when exiting. Some people say, it's crashing, other people say, it ends up in an endless loop of allocating more and more memory... Actually noone knows what's going wrong... Are there any volunteers, who wanna fix this? > Often, another newline is needed to make the shell prompt reappear. > I think, noone might reasonably blame ggi for that (and didn't to date). > And, as far as i could see up to now, the behaviour is lots better than > was with 2.0.1, with the demos at least - congrats! Thanks a lot. > > > - I'm currently working on (new) ggi-doc. > > - Haven't checked yet, whether ggimisc needs an update. > > - And yes, the svga wrapper. Least important, though i like the idea > very much. As soon as my time permits i'd like to look after it, evtly. > have it integrated better with existing svgalib and svgalib-dummy. > People have asked for that, me first. Mostly a debian issue, because > those pkgs are not installable at the same time, but 'svgalib4libggi' > would have to be more complete (and less bug plagued) to be really > usable. But imagine, svgalib on a s390 - my own favourite still m68k. Sounds interesting. Unfortunately, svgalib4ggi is lacking a maintainer. So nothing but the common GGI buildsystem updates has been changed. Is/Are there any volunteer(s) on this? > - Before going for more pkgs, i'd like to think about and set naming > schemes, 'task packages', menus and such, to make it more easy and > transparent for users to find all relevant GGI pkgs in debian (> 8000 > pkgs). Ideas and suggestions always welcome! Great! > - libgalloc (?) still under development. > - Dreaming of a GGI driver for cthugha ... cthugha? What's that? > - We're doing some shows in jails here between christmas and new year, > lots of practicing and preparations still needed and > > - have a living ;) > > So, that's for today. May be we can once meet personally and may be i > tell you then how GGI spells for me (would be DGA in french) and why i > love it so. Keep up the good work and have fun! greetings, martin Tnx a lot. You are really the born packager. :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr f�r 1 ct/ Min. surfen!
