Re: World-Domination - was Re: multi threaded... Details: Names
On Tuesday 17 December 2002 23:44, Martin Albert wrote: > Hanging out on dubious hacker websites, like ggi-project.org and > such, following links to stuff that interests me, i often end up > downloading from stacken.kth.se, strange favicon, strange mackan@ ... > :-) > > Eg., svgalib4libggi, ggi driver for 1.2 synaesthesia, lcd821(?). > > 'Hey, Marcus' was short for: In my free time i like to try to update Not perfectly proud of it yet, but happy to announce the first result of me trying to gain a little GGI experience (in my free time, ha!): = Synaesthesia 2.2 + GGI Driver. Based on S'2.1 by Paul Harris and the GGI driver code for S'1.2 by Marcus Sundberg. apt-get'able: deb-src http://home.t-online.de/home/eislink/debian unstable. = Remember this is a fully unsupported private branch based on the latest public release 2.1 available from http://yoyo.cc.monash.edu.au/~pfh/. I hope that the author will accept the patch, i also offer a patch to the Debian maintainer: might become the first package using libggiwmh. Non-Debian users may unpack the tar and apply: zcat .diff_file | patch in the top dir. No need for the resulting debian dir? Simply remove it. Changes: synaesthesia (2.1-2.1+2.2) * GGI Driver 2.2 based on Markus Sundbergs for 1.2: 8, 16 & 32 bit - currently LITTLEENDIAN ONLY. * Modify configure.in, Makefile.am, syna.h and main.cc to include ggi driver, main.cc and sound.cc for main mix option. What else? The author has tubes pointing out of his head! The program features a neat scaling UI. Q: S'2.1 with ggi-target-x needs options -nobuf:-nocursor. How to arrange for that from in the program? I was starting to parse the environment for GGI_DISPLAY to evtly extend it, but that cannot quite be the suggested method? martin -- 'apt-get deb-src http://home.t-online.de/home/eislink/debian unstable' for latest and unofficial Debian GGI packages.
Re: directfb--15 fixes
On Monday 13 January 2003 18:50, Martin Albert wrote: > When doing as suggested, however (compiling modded directfb) lots of > errors are now generated by directfb about unexpected pixelformats. > As i could only test with broken nvidia driver, i don't know yet, > whether this is the gfxdriver or really the interface. Diffing libggi-2.0.2/default/fbdev/directfb/ggidirectfb.h and directfb-0.9.15/src/core/gfxcard.c wrt. typedef struct GraphicsDeviceShared and struct _GraphicsDevice gives terrifying first hints. Simple transplant leads to: visual.c: In function `GGIopen': visual.c:243: structure has no member named `driver' visual.c:260: structure has no member named `fix' visual.c:263: structure has no member named `framebuffer' visual.c:264: structure has no member named `framebuffer' ... make[6]: Leaving directory `/tmp/libggi-2.0.2/default/fbdev/directfb' boils down to dfb_driver = dfb_device->driver = &(priv->driver); and memcpy(&(priv->deviceshared.fix), &(fbdevpriv->fix), sizeof(struct fb_fix_screeninfo)); and dfb_device->framebuffer.base = fbdevpriv->fb_ptr; dfb_device->framebuffer.length = fbdevpriv->fb_size; /* mmap_size ?? */ Ah - help, please. Having terrible pain in the back for some days, i''m afraid i can't afford to spend the night on that. martin
Fwd: Bug#176577: minor man page error
Keep the Cc: to have your replies filed with the Debian BTS. DON'T keep the Cc: for discussions. Thank you. Hello, Bas! Thank you for your bug report and your interest in GGI. martin -- Forwarded Message -- Subject: Bug#176577: minor man page error Date: Mon, 13 Jan 2003 21:03:30 +0100 From: Bas Zoetekouw <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Package: libggi Version: unavailable; reported 2003-01-13 Severity: minor The GGI_DISPLAY section of libggi (7) is broken: The default target is specified using a target-spec: .nf target- name [:targetargs] .fi where targetname is the name of the tar- get, and targetargs are any target-specific arguments. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux iasoon 2.4.20 #1 Mon Dec 16 21:13:55 CET 2002 i686 Locale: LANG=en_IE@euro, LC_CTYPE=en_IE@euro ---
Re: directfb--15 fixes
On Monday 13 January 2003 17:35, Brian S. Julin wrote: > my own code first and probably that would have cost me a lot of time. Uh, yes ;) Really haven't found a way yet to debug the opening phase of an fbdev driver. After switching screens, and i suppose not yet having loaded vtswtch, it was the first time i was glad to have an acpi machine, allowing to gracefully power down by pushing the button. When doing as suggested, however (compiling modded directfb) lots of errors are now generated by directfb about unexpected pixelformats. As i could only test with broken nvidia driver, i don't know yet, whether this is the gfxdriver or really the interface. Directfb drivers really speed things up, but are a PITA. Thanks, that you've taken up on it, i couldn't have done in that time. Now Debian build daemons haven't yet made libgii on all archs, giving a delay for ggi anyway, so i can look after that pixformat issue ... martin
Re: directfb--15 fixes
> On Wednesday 08 January 2003 18:04, Brian S. Julin wrote: > > I'll try to update to -15 and fix tonight. Again, I don't have any > > hardware to test with, so it is very likely broken in runtime. > > It was fine last time with my (taking cover; where's that unreadable > font) nvidia, them non-free s... > thanks, i'm currently looking after it too. mail you, martin -- BSJ: Yeah, It should be easy unless they really tangled things up again. I'm working on it now. -- BSJ: It looks like they did some major internal reworking. More than I -- BSJ: OK, give it a test I guess... Brian RCS file: /cvsroot/ggi/ggi-core/libggi/default/fbdev/directfb/directfbglobal.c,v Working file: directfbglobal.c head: 1.7 revision 1.7 date: 2003/01/10 00:56:35; author: skids; state: Exp; lines: +48 -5 Add new names for old functions and new dummy functions for 0.15. -- MA: Compiles nicely. Thanks! Runs fine except directfb gfxdrvrs don't get loaded. -- MA: The relevant test failing is default/fbdev/directfb/visual.c::326. Now i studied 'some' structures to see what's going. Is this simply libdfb's fault? Yes, it is. Modules using conditional compilation in their probe()s should include the relevant headers defining the symbols used. To make use of accelerated ati/nvidia/tdfx with debian directfb_0.9-15-2 add '#include ' to the main modules of said drivers. Guess, i add new directfbglobals with the diff and upload libggi-2.0.2. (mentioned in the changelog naturally) ?? Once directfb gets fixed, there should be accel. When they update, libggi has to be recompiled (as they hardcode version into lib/directfb-version/gfxdrivers and libggi gets this at build time). martin
Re: directfb--15 fixes
On Wednesday 08 January 2003 19:12, Christoph Egger wrote: > IMO, the directfb people are ill, if not braindead! Changing the yup, simply forgot to add that ;-)
Re: directfb--15 fixes
On Wednesday 08 January 2003 18:04, Brian S. Julin wrote: > I'll try to update to -15 and fix tonight. Again, I don't have any No, i'm not an email junkie ... ;-) It' simply the relevant part of the diff so far between -13 and -15 (constructed, diff was as confused as myself): diff /usr/include/directfb-internal/core/gfxcard.h [< -13] [-15 >] < void *dfb_gfxcard_memory_virtual( unsigned int offset ); > void *dfb_gfxcard_memory_virtual( GraphicsDevice *device, unsigned int offset ); diff /usr/include/directfb-internal/core/fusion/reactor.h [< -13] [-15 >] < FusionResult reactor_attach (FusionReactor *reactor, < React react, < void *ctx); > FusionResult reactor_attach (FusionReactor *reactor, > React react, > void *ctx, > Reaction *reaction); I don't know yet where to get that gfxdev or reaction from? martin
Re: directfb--15 fixes
On Wednesday 08 January 2003 18:04, Brian S. Julin wrote: > I'll try to update to -15 and fix tonight. Again, I don't have any > hardware to test with, so it is very likely broken in runtime. It was fine last time with my (taking cover; where's that unreadable font) nvidia, them non-free s... thanks, i'm currently looking after it too. mail you, martin
directfb--15 fixes
On Saturday 07 December 2002 18:27, Martin Albert wrote: > Hi, Brian! compiles and runs. That was about directfb-13. Now i'm here (using -15), still looking, any help apprctd: gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -I/usr/include/directfb -I/usr/include/directfb-internal -I/usr/include/glide -I/usr/include -I/usr/include/directfb -I/usr/include/directfb-internal -I/usr/include/glide -g -O2 -I/usr/include -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -c directfbglobal.c -MT directfbglobal.lo -MD -MP -MF .deps/directfbglobal.TPlo -fPIC -DPIC -o directfbglobal.lo directfbglobal.c:99: conflicting types for `dfb_gfxcard_memory_virtual' /usr/include/directfb-internal/core/gfxcard.h:291: previous declaration of `dfb_gfxcard_memory_virtual' directfbglobal.c:186: conflicting types for `reactor_attach' /usr/include/directfb-internal/core/fusion/reactor.h:54: previous declaration of `reactor_attach' make[6]: *** [directfbglobal.lo] Error 1 martin
Debian NEWS update
Hello, All! Sri, as u know i was away for winnt - as we know this may take longer. So i had a nice :-/ christmas and a happy :-\ new year. A happy new year to all of you! Now, libgii is uploading, libggi following in the morning, misc, gcp, wmh ... giving the autobuilders a little time in between so they can build with newest libs, and don't need another turnaround of the queue. Thanks Christoph, for your 'Geheimtips' and answering bugreports, great job and very nice of you. On Thursday 02 January 2003 14:17, Christoph Egger wrote: > libggiwmh has been packaged. I dunno, if it is already fetchable. libggiwmh_0.1.0-1_i386.changes ACCEPTED Date: Mon, 30 Dec 2002 00:25:02 -0500 From: Debian Installer <[EMAIL PROTECTED]> libggigcp_0.8.2-1_i386.changes ACCEPTED Date: Mon, 30 Dec 2002 00:23:20 -0500 ... but you knew that already. As i've told you, these were new and had to be entered into the database beforehand. for (;2days;) no_sleep(); goto sleep(now:!) // Have a nice GGI, martin
Uploaded: libggigcp*.d{sc,eb}, libggiwmh*.d{sc,eb}
Hello, All! Uploaded files with names similar as given in Subject:. As these are new packages, it may take a while until they go to the archive. Until then you may use http://incoming.debian.org. Ok , i'm away now until weekend. Have fun! martin
Re: World-Domination - was Re: multi threaded... Details: Names
On Tuesday 17 December 2002 20:25, Martin Albert wrote: > > Heh! Where do you get this messages from? > Huh? This my own! [Explicit On] Hanging out on dubious hacker websites, like ggi-project.org and such, following links to stuff that interests me, i often end up downloading from stacken.kth.se, strange favicon, strange mackan@ ... :-) Eg., svgalib4libggi, ggi driver for 1.2 synaesthesia, lcd821(?). 'Hey, Marcus' was short for: In my free time i like to try to update and improve / fledge out these well written pieces of code. I'm always interested in udpates, have some myself, when they are so far, i will send them to you, ok? I understand that you mostly work on sth. else and so think that no further explicit 'locking' of the source code is necessary to avoid duplication of efforts. As for svgalib4libggi, i did not yet apply officially for ggi maintainership, but am very interested and busily hacking on it. Plan is to make it a functional replacement for svgalib while at the same time it should be easy to have them both installed on the same machine and decide as late as possible which one to use. More on that with the beginning of the new year. [Explicit Off] martin :-)
Re: World-Domination - was Re: multi threaded... Details: Names
On Tuesday 17 December 2002 18:42, Christoph Egger wrote: > Heh! Where do you get this messages from? Huh? This my own! martin
Re: LibGGI install issues
CBS already decided to install the demos with ggi- prefix in Debian. I keep this up, you just have to type ggi- and see all demos and other binaries to choose from. I didn't install cpuinfo yet, when you don't either it's ok. The existence of this functionality is recorded in debian.changelog. I might also add it to the readme. The sources are installed to /usr/share/doc/libggi0/examples anyway. martin
Re: World-Domination - was Re: multi threaded... Details: Names
of minor importance, just to avoid duplication ;) - Hey, Marcus, i'm porting your synaesthesia ggi-driver to the current version. - Hey, Marcus, i'm after that svga4libggi of yours. Although you once pointed out it was just a hack, there is so much serious interest in it, it might become one of the secret weapons for world domination. I'm in contact with svgalib maintainers to coordinate the work of (real) svgalib, svgalib-dummy and ours to become a real fine solution. greetings, martin
Re: multi threaded... Details: Names
On Sunday 15 December 2002 16:01, Christoph Egger wrote: > libbse, libgic and libgpf are NO extensions. Thus, how should we mark > ggi libs, which are NO extensions? IMO, extensions should be > distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). > > As far as packaging of gii goes, if I understand the issue > > correctly, it boils down to binary compatibility between libgii and > > its input targets. Currently if a binary incompatile change > > happens, the only way to keep both versions installed would be to > > do some very fancy libgii.conf cruft in order to make each of the > > version of libgii load the proper set of input targets. But given > > that the loading of input targets is fully under libgii control, I > > think it is safe to assume that if any such change happens, libgii > > will provide a mechanism for loading the different versions of > > input targets. Hence I would tend to think that libgii-target-x > > should be the right choice. After three days of psycho rollercoaster between putting it all in one package, giving up on it and having lots of packages nicely split, i had to decide that there is not much that i can do from my side _now_ to put all this on a stable basis within a short term. This one is libggi0-target-x now, proposing the illusion of the possiblility to have more than one generation of libs&mods installed. Anyway, i'm not giving up and hope that we are able to find a midterm solution. /me started to put a script together, quoting the problems that i actually have and can see and we can try to fill in solutions. Mind you, the number of packages depending on libggi is sinking continously ... !!! So for the very moment i have only ONE point that I BEG should be tackled BEFORE any RELEASE: Please, consider how you really want to call your libs and extensions wrt. filenames! What a nice plug, that even one of your core dev's had to find that the name of any lib had silently changed - and that from the name, that i think would be fine to the one that is, from my POV, not feasible to hold up. I'm still holding the upload of libgcp and wmh because of this reason. Call it libggiextwmh if you like that, but go for it. I really like the ideas behind GGI and how you do your project. I try to find a way to promote it's use wo. it having to become too professional. Soon even Debian/BSD might become a reality ... I really don't know what is so hard to understand about my questions and the cases that i bring up to you as The Project. I'm really sorry if i make you feel uncomfortable from time to time ... Again, i have my structures set up here so that i can put out _any_ of your libs in a short time, either from cvs or your tarballs. Getting it all right from Linux binary compatibility, shlibs issues, over Debian policies to the ggi project isn't the easiest thing to do if you pay 2 cents for each minute of internet connectivity. Besides getting the svgalib wrapper going, this is what i see as my part to give sth. back to you. But i know now, how much work it is to keep a ggi application going over time and i'm not willing to promote that to anybody who tries to get sth. else going too. /me now has to get sth. else going too, thanks for your time. Have a nice GGI, have a nice day, martin
Re: multi threaded... Details: Names
On Saturday 14 December 2002 15:06, Filip Spacek wrote: > Personally, I would prefer something like > libggi_window_manager_hints.so, because I don't quite see the need > for shortening the name. And this goes for all extensions: > libggi_descriptive_name_of_the_extension.so. Currently, I have > absolutely no idea what half of the acronyms stand for, and really, I > don't think there's any need to use few characters. As far as I know, > none of the OSs that libggi supports have stringent limits on the > number of characters in the name and the amount of typing saved by > shortening it is really minimal. Because_this_is_neither_windows_NorAda.extend.here.at.will. I receive complaints about things not being readable on 80x25. I ended up with pkg name: libggi2-libwmh0-target-x-dev, could be libggiwmh0x-dev, libggi2svga > > On the other hand, I didn't write any of the extensions, so I > shouln't be questioning authors' choices of names. > > -Filip Sorry, if you find i'm insisting or sth. like that. I feel that i have unsolved problems (some more?: eg. module-versioning). Tell me to shut up or to try to do more mindreading about authors reasons for those choices (am i not correct with: building up GGI, concentrating on writing fine libs for the project with easy names, ...) I think your statement is correct and valid. I think libggiwmh has it all: distinction, elegance, few chars to type. Neither variant seems to be able to make both of us happy. Either i'm confused or there are unsolved issues that confuse (me). Decisions should be made before going further with release. Lay out a stable concept with v.2 giving developers a clear view of a stable GGI. Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht einfacher. "Keep things as simple as possible, but not simpler!" If you don't take sth. upon yourself, somebody else _will have to_. greetings, martin (packaging gii, splitting x and really wondering / worrying about module-versions. libgii-target-x or libgii0-target-x is the question here, together with etc/ggi, lib/ggi all along).
Re: multi threaded... Details: Names
Oh, no, not that again ...! ;-) Yet it must be. Christoph Egger on Friday 13 December 2002 21:24: > Wann wird -rc5 ueberhaupt via aptget downloadbar? Packages are ready. I haven't uploaded, 'cause i don't like them yet. All that strange names ... On Saturday 14 December 2002 02:35, Andreas Beck wrote: > > 2. LibWMH is totally broken for me. This seems to be a binary > > compatibility issue, as the demo runs fine. > > O.K. - got that one. Library name changed from libggiwmh to libwmh. > > I am usure what I prefer. However for compatibilty reasons I would > suggest to place symlinks to emulate the old name libggiwmh for some > time. No, this looks nice, i'm sure what i prefer! That's what i like. libggimisc already exists like that, source, binary and libname are identical - that's the way to go! IMHO publishing these libs of yours with that generic names will not work in the long run at least. So, why don't you just do _that_?: call it libggiwmh, libggiovl, ... leaving gii and ggi itself like they are. Do it, i need one hour to redo the packaging and off it goes ... :) Please consider it. (Still ;) have a nice day, martin -- Use dselect for user-friendly package management
Re: libggi-libwmh-target-x
Ok, then - gii, ggi, [ggimisc], wmh & gcp are packaged, tested, ... ggimisc hasn't been touched, keeping the old package. Everything looks good, builds, runs - fine. ( All time: Reinitialisation after svga or fbdev target were used: i have to switch consoles to see the prompt again. ) ( And my all-time: until release i try to do whatever makes sense (debconf, README, ...) to avoid these no-bugs in the future even more. ) Have a nice day, martin
Re: libggi-libwmh-target-x
On Thursday 12 December 2002 07:47, Christoph Egger wrote: > > IF ( TRUTH >=< what_you_claim( WMH_IsAn_EXTENSION) ) > > HOW COMES: > > it is in /usr/lib/libwmh.so.0.0.1 ? > > No. /usr/lib/ is correct. Applications using it are linked against > it, so you need to place it somewhere, where the dynamic linker can > find and load it, when the application is starting. > /usr/lib/ggi/*/*.so will only work, when this directory is in the > linker's default search path. Hi, Christoph, hello, list! Sorry for that spam, i was too tired - yes, this is correct. And as said, it builds fine and it runs fine - One patched flaw in the build system remains. Package is ready in principle, could be released. I'm i a hurry, got to leave for rehearsal but try to get sth. to say about the status pf libgcp still before. Have a nice day, martin
libggi-libwmh-target-x
and the rest finished that far, besides a small issue: IF ( TRUTH >=< what_you_claim( WMH_IsAn_EXTENSION) ) HOW COMES: it is in /usr/lib/libwmh.so.0.0.1 ? SHOULDN'T THAT BE: /usr/lib/ggi/*/*.so or sth.? NOW WHAT: default: goto sleep() OR TRY: dlopen libgcp ? ;; BTW: everything else was fine with wmh. :-) ENDOF IT; martin -- Use dselect for user-friendly package management
Re: libggi2 static compiling
On Wednesday 11 December 2002 00:16, Cserna Zsolt wrote: > Hi! > > I'm writting because I cannot compile my libggi using application > statically. > > The compile command was: > gcc -Wall -static -o mpointexample mpointexample.c -L/usr/lib -lggi > -I/usr/include -lm -v > > (-lm for math) > > The error message: > /usr/bin/ld: cannot find -lggi > > This means no libggi.a was found in /usr/lib. But the debian package > doesn't contains "libggi.a".. > > (sorry for my english :) > > Thanks, > > Zsolt Cserna > > ps: I'm using debian sid (last year's "edition", from cd.. :) Also hi, my english isn't better ... ;-) Currently there is no provision whatsoever to use any libggi(/any GGI library?) as a static library, sorry. This is an open issue, that should generally be solved but it isn't yet. In general it seems at first glance quite pointless to even try to use libggi statically. Libgg and libggi would actually be linked into your binary, but every other module like display targets, etc. will be loaded at runtime. Besides verifying your interface to libgg and libggi there is no gain to be had when linking static for debugging purposes. There are other scenarios where it would actually be helpful to be able to build binaries that include the libraries and the modules used. Debian has other requirements to demand statically linkable libraries, currently libggi breaks this rule deliberately and as a consequence has to deal with a sticky 'Release-critical' bug report. Please tell the GGI Project why you need that, may be it will get them going ;-) I Cc'd this mail to [EMAIL PROTECTED], the mailing list of the GGI project. Try to return matters of general interest to them, but i assume that you must be a member of the list to write to it. Feel free to mail me, you're welcome. Thanks, martin
Debian package names
Hello, All!
Forgot to mention the Cc in my post to debian-develop, sorry, might be
you receive some mail wrt. to our future in the next days.
Somebody who objects naming the *Source* packages of all your wonderful
libs *in the Debian archive* to ggi-libraryname (eg.: ggi-libwmh,
ggi-piggy)? That is because piggy seems so generic :), also does libgpf.
(In the process of writing the description for wmh: it pulls me to use
libggi-libwmh as the source name instead of ggi-libwmh, or -extwmh? and
the binary?: is libggi-extwmh, might be libggi-ext-wmh, or ggi-ext-wmh
or what? See? Pls. help me out ;) My (current) prefs: src:ggi-libwmh,
libggi-ext-wmh-x (shortest, meets libggi-{sample,target}s-, but may be
libggi2-ext-wmh1-target-x might be more descriptive/correct/necessary?)
I _love_ systems, but why is gpf an *extension* vs. lib? (sorry for
that, but sometimes its a little much for my poor head to stretch from
GGI(packages) on bloated user pc's, over embeddian down to autogens',
licenses all on the way, back through the Gate Great Interface - "don't
stay too long, don't hang around, get back to apt!"
Aahh, yes, and back we are ;)
Somebody who objects naming the *Binary* packages of all your wonderful
libs *in the Debian archive* to libggi-libname and libggi-extname (this
is not as generic as the Source thing, there are already eg.
libggi-target-fbdev, libggi-samples)? libggi-ext-name? Looks better,
adds another char to the length ...
As always, 'historical reasons' can be given, when 'libgii', 'libggi',
and 'svgalib4libggi' should live on with these names for their *source*
packages. I'd rename existing libggimisc to any scheme and keep those
names: gii, ggi don't need libggi :P and svgalib is, well, svgalib.
Have a nice GGI :-), martin
PS. I can talk about that naming thing even longer, wanting it to be as
general as can be and with least DPI changes (Debian Package
Interface:) as possible (the collected list of Replaces and Conflicts
becomes harder to manage everytime). If someone wants to start ...?
--
Use dselect for user-friendly package management
RFC: GGI with Debian
Hello, fellow developers! There is GGI and some basic packages for Debian do already exist (more? source ptrs: ggi-doc, libggi). Most important: complete graphics environment, built up from libraries and (dyn-loaded) extension modules for lots of targets with varying dependencies. Having it all on the system might one day install every available graph related package, if only Depends were used. Modules detect availabilty of a library at runtime, so Recommends are used. Major issues here: naming, granularity of dependancies and install/runtime. Packaging: I'm looking for ways to help users, pkg and archive maintainers to find their way through. A consistent naming scheme and decision on granularity of dependancies are needed, a 'task package' might help installing and, most important, help with the runtime issue. Install/Runtime: GGI display targets are very versatile, some do read/write to/from files, tcp sockets, etc. The basic libggi2 binary pkg is usually depended on by packages that use ggi. There is one unnecessary problem that hits users, developers and the BTS: libggi2 provides some basic targets (file, tcp,...) and is very capable of doing usefull things with only them installed, like X clients with only a client library - you won't see any output (no Xserver) but everything is correct and meant to be that way. The same goes for libggi, you _may_ install display-targets that are Recommended or Suggested but you don't have to. The package description clearly states that you might want to install some and why. Now lots of users report bugs because they apt'ed and don't have display-targets (and don't RTFM, ... but bug), i hold some 12 bugs open to remind me and maintainers of the other pkgs of that issue. I thought about that for a long time, my stand is to do _nothing_: Descriptions, Dependancies, Recommends, Suggests and Enhances are meaningful and should be used. Not being able to select add. pkgs from maintainer scripts and Pre-Configuring make it nearly impossible to do sth. at install time, sending mail to root is ugly, installing default targets is senseless and ugly because of the sheer number of archs and their capabilities and more than often would a target be installed that is not the one the user would actually choose (choose from vcsa, terminfo, aa, svga, fbdev, X and additional arch-dependants) and some are suited better for a given task than others - this might even lead to real bugs then ;) What is the curr. consensus on 'Task pkgs' or the like? I'm thinking about ggi-user and ggi-develop, providing sth. usefull and draw other packages in - the snake bites its tail. So, what are the possibilities of installing additional packages from maintainer scripts and regular programs like ggi-conf. Granularity of Dependancies: GGI started out replacing X. As i took over libgii, that tiny little lib depended on X already. I still didn't dare to change this, afraid of bloating the archive even more. But it is wrong! There should at least be gii-X and non X. Libggi does the right thing, splitting display-targets. Still not consequently enough, but there are 9 binary display-target pkgs for i386 already, because of the varying dependancies. Naming Scheme: There are two 'real libraries', libgii provides input, ggi output and already needs gii. Then there are libraries for general display related operations (blit,ovl,...) that that might never be usable wo. libggi and for sure not the extensions, dyn-loaded modules extending display-targets. I intend to use: libggi-extNAME and libggi-libNAME for all of those. Planned pkgs would so become: libggi-extwmh and libggi-libgalloc. Ok? In short (hey, you didn't expect that?): If no one answers, i will: - close all bugs wo. further notice, regarding the unavailability of 'visible' output, - hold on current practice: libggi2 'Recommends' libggi-target-... - make as many binary packages as seem necessary to me (promise to do it consciously and responsibly) - name them eg.: libgii, libggi, libggi-extwmh, libggi-libgalloc - still not know how to solve the dependancy issues for users and maint. that cannot read. Please, gimme input, i'll sort it out. Maintainers of GGI aware packages, please (re-)consider building with GGI enabled. Greetings, have a nice Debian, martin
Re: Bug: Debian BTS #78585
On Saturday 07 December 2002 20:58, Brian S. Julin wrote: > I think from your perspective, if you compile with the mutexes > internally implemented you can close the bug. Then when we fix Ok, thanks for that Brian. I looked at the code and configure.in upon your mail and found 'builtin' to be default ... I made a note to either check for that again or even configure with builtin set. Your mail was helpful and saved me some time (as always :), thanks. > It should be a simple fix, (except for figuring out how to adjust > autoconf but that's never simple :-) For voice chorus + blues harp and piano: oh, yeah ... have a nice day, martin
directfb--13 fixes
Hi, Brian! compiles and runs. No further check for functionality yet. (no hardware anyway). greetings, martin
Re: rc3.deb -> final, more deb
Sorry, i missed your post at first:
On Thursday 05 December 2002 00:51, Christoph Egger wrote:
> BTW: What is 'sh' ? And what's the difference between mips and
> mipsel? Which powerpc it is exactly? Motorola G3 or G4? IBM PPC64?
Please see: www.de.debian.org, somewhere around 'Ports to different
archs' - PowerPC ('cause i know nothing about it ;).
> Could you send me a diff of your changes, please? Simplifies the
> inclusion for me.
Please see the bottom of my post to this list, Subject: Debian Total.
> > 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.
I thought about it again (and poked around a little in configure): It
shouldn't be possible! I didn't autoconf, just *use* your configure.
> > 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?
Dunno, may be just missing, or lazy, or sth. else to do ...
> > 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... :)
They need it or bail out from compilation.
It does not exist when users want to rebuild examples, though.
I started to include at least flying_ggis and demo as binaries.
The other ones go wo. config.h - may be i should include this once.
> > Btw., build against glide2 or 3?
> I don't know. Sorry.
Ok, i stick to glide 2 (assuming later cards being compatible),
> 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.
Thanks, just updated from cvs. I give it a try.
> > ggiteleserver.[17]: I once wrote a manpage for this (now in 1,
> You may replace yours with ours. :)
Yup, seen that. Nice page, thanks, was easy now to drop mine.
> > display-x now replaces old x and xlib, display-dga is continued?
> Yes. display-dga still persists, because nobody wrote a helper
Ok, thanks.
> > 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?
Just tell me then, explicitly (sorry, you might know Debian is keen on
correct copyright files).
> > lcd823: If this is usefull, it would become an arch-specific target
I made a ppc specific target pkg out of it. Description: (grind, grind)
This package contains the driver for the "lcd823" target, enabling
libGGI (and therefore any program using libGGI) to display its output
using the LCD controller of Motorola MPC823 processors.
> svgalib4ggi is lacking a maintainer. So nothing but the common GGI
> buildsystem updates has been changed.
Ok, then. I'll review existing pkgs of libggimisc and svga4libggi
possibly this weekend.
> > - libgalloc (?)
> still under development.
I see, we talk about that later then ...
Anything usefull (of lowlevel, highlevel, libs, misc, wrap'rs) released?
> cthugha? What's that?
VSOP eyecandy from music. While building it for the first time, it
wanted mesa, wasn't available, outdated libggi - hello, GGI Project!
> Tnx a lot. You are really the born packager. :-)
Tnx a lot! See above. ;-)
martin
Bug: Debian BTS #78585
Before you think this is old: I didn't yet grasp the mutex code, but it
still looks _very_ similar and see the last paragraph of this mail.
Someone please check this before release? I haven't yet tried the code
example given. Can this bug surely & safely be closed?
Sorry, i really didn't have the time to examine this yet :-/
Debian Bug report logs - [1]#78585
libgii0: needs to dlopen the soname of libpthread.so
Date: Sat, 02 Dec 2000 18:33:22 +0100
Delivered-To: [EMAIL PROTECTED]
Package: libc6-i586
Version: 2.2-4
Severity: normal
I have some troubles with libc6-i586: heroes-ggi-0.7 doesn't work
when libc6-i586 is installed. It runs well with the standard libc6.
I played a bit with this. In short, it appears to be due to the fact
that the program loads two differents versions of libpthread.
1) heroes is linked with -lgii and -lpthread (==
/lib/i586/libpthread.so.0)
2) libgii does a dlopen("libpthread.so", RTLD_LAZY)
which actually open /usr/lib/libpthread.so (==
/lib/libpthread.so.0).
Here is how to reproduce. The sample program compiled below never
terminates because for some reason pthread_create never returns (I
suspect this is due the joint use of those two different pthread
libraries).
You needs to install package libgii0-dev to compile th.c.
=
% cat th.c
#include
#include
#include
#include
pthread_t foo_thread;
static void *
foo (void *arg)
{
puts ("entering foo");
sleep (2);
puts ("exiting foo");
return 0;
}
int
main (void)
{
giiInit (); /* this calls dlopen("libpthread.so", RTLD_LAZY)
internally */
pthread_create (&foo_thread, 0, foo, 0);
/* control never goes here */
puts ("thread foo created");
pthread_join (foo_thread, 0);
return 0;
}
% gcc th.c -o th -lpthread -lgii
% ./th
entering foo
exiting foo
^C
% strace ./th 2>&1 | grep thread
open("/lib/i586/libpthread.so.0", O_RDONLY) = 3
open("/usr/lib/libpthread.so", O_RDONLY) = 3
^C
%
=
You may want to reassign this bug to libggi0. I'm not able to decide
whether libgii0 is culprit or not. The fact that
/usr/lib/libpthread.so is installed by libc6-dev (and not libc6)
probably means that giiInit() should NOT dlopen it, but shoudl rather
dlopen "libptread.so.0" or something else. In doubt, I'm submiting
this here, because the libgii0's maintainer does not appear to be
active.
Thanks.
-- System Information
Debian Release: woody
Kernel Version: Linux phobos 2.4.0-test10 #6 Fri Nov 10 11:06:04 CET
2000 i586
unknown
Versions of the packages libc6-i586 depends on:
ii libc6 2.2-4 GNU C Library: Shared libraries and
Timezone
_
Message received at [EMAIL PROTECTED]:
Date: Fri, 29 Dec 2000 14:55:25 -0500
Delivered-To: [EMAIL PROTECTED]
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
_
Message received at [EMAIL PROTECTED]:
Subject: 78585 is *not* fixed (please reopen)
Date: 30 Dec 2000 16:23:47 +0100
>>> "Debian" == Debian Bug Tracking System <[EMAIL PROTECTED]>
writes:
[...]
Debian> * Could not reproduce. My test program showed that it resolved
the
Debian> libpthread properly. I am going to assume user error, or some
Debian> funkiness on the user's system. closes: #78585
I can reproduce it really easily, on (three) differents hosts,
not all beeing mine (which means they are not all configured
likewise and I doubt there is the same funkiness in each of them...).
You'll find below a full transcript which shows how the same
program can have a different behavior whether libc6-i686 (or -i586)
is installed or not.
ii libc6 2.2-6 GNU C Library: Shared libraries and
ii libgii00.6-1.1General Input Interface runtime
/tmp # cat >th.c
#include
#include
#include
#include
pthread_t foo_thread;
static void *
foo (void *arg)
{
puts ("entering foo");
sleep (2);
puts ("exiting foo");
return 0;
}
int
main (void)
{
giiInit (); /* this calls dlopen("libpthread.so", RTLD_LAZY)
internally */
pthread_create (&foo_thread, 0, foo, 0);
/* control never goes here */
puts ("thread foo created");
pthread_join (foo_thread, 0);
return 0;
}
/tmp # gcc th.c -o th -lpthread -lgii
/tmp # ./th
entering foo
exiting foo
^C
/tmp # strace ./th 2>&1 | grep thread
open("/lib/i686/libpthread.so.0", O_RDONLY) = 3
open("/usr/lib/libpthread.so", O_RDONLY) = 3
^C
/tmp # ldd th
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4002)
libgii.so.0 => /usr/lib/libgii.so.0 (0x40037000)
libc.so.6 => /lib/i686/libc.so.6 (0x4003e000)
libgg.so.0 => /usr/lib/libgg.so.0 (0x4015f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
libdl.so.2 => /lib/i686/libdl.so.2 (0x40164000)
/tmp # apt-get remove libc6-i686
/tmp # ./th
thread foo created
enteri
deb-package descriptions
Each GGI .deb description used to start with the following desc (thanks to Charles Brisco-Smith): The GGI project is developing the "General Graphics Interface", a set of APIs, drivers and other interfaces aiming to provide a fast, portable graphics environment for UNIX-like operating systems. Starting with ggi-doc i changed - portable graphics environment for UNIX-like operating systems. + portable graphics environment for many operating systems. Correct? Additions, ... anything? greetings, martin
ggi-doc-1.deb finished!
Hello, all! I'm very pleased to announce the recent upload of ggi-doc_0.0.20021207-1_all.deb to Debian unstable. A pet project of mine i had in mind for a long time. I hope that this pkg will promote usage of and interest in GGI - it was missing just for too long. Thanks, Eric, for your advice. Working with your xml was just plain fun - hey, i usually love assembler best. :-) It was easy to do the fairly small adaptions i had in mind: including your web site (screen shots!), changing start index to 'Introduction' (instead of News) and, i hope this is ok for you, appending 'GGI in Debian' to the bottom of the 'Contact' page, including my email adress. I am very happy with it and am open to suggestions / rejects, especially whether you can live with my unqualified addition. ;-) Should now be in incoming, expected to be in the archive soon. greetings, martin
Debian Total
Because of the minor updates libgii stays at rc3. libggi rc4 is currently built. Now, the topic says it all: You want to stay up to date? This address will allow you to even watch the holes in my underwear as they grow ... http://qa.debian.org/developer.php?login=ma But, may be you want to try http://packages.qa.debian.org/libg/libgii.html http://packages.qa.debian.org/libg/libggi.html and so on. Because of my intermittent internet access, i'm sure you'll know more about my packages than me then ... PLEASE: PLEASE: PLEASE: Not only through this pages, but for a long time already through the debian mirror network, do you have nearly instant access to my diffs that i apply to your sources. PLEASE DO USE THEM or else i have to spend a day like today with a new pkg of yours that is older than my last one ... ;) The pages above give you access, the mirrors (http://mirrors.debian.org, path debian/pool/main/libg/libg[ig]i/) and the still cooling, hot packages can be found http://incoming.debian.org. There are docs around, but i'm sure you know anyway: debian src is 3 files pkg.orig.tar.gz (what i made from yours), .dsc (forget) and .diff.gz: This applied with patch gives ideally only a single dir in the pkg root: debian/. But (today;) you will also find patches to your source ... - pls consider looking at them at least. Thank you. have a nice day, martin
rc3.deb -> final, more deb
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. 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. 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. 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. glide/gtext.c and glide/visual.c both(?) need config.h. Btw., i build against glide2, don't have hardware, should i use glide2 or 3? 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 ... 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. 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 :). Copyright: no longer LGPL? I still include a notice saying so. This is important, sorry. Please clarify (for me). 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 ... 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). 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. 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! - 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. - 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 r
Re: build fails even quicker
On Tuesday 03 December 2002 06:11, Martin Albert wrote about build failures ... > Sigh, just wanted to go test ggi applications. > Seems, i've got to do some more. If i only knew what ... > > 'Some' hours later: in short: Xxf86dga is not built with -fPIC. Sorry, the previous mail went out on a silly action, should have been kept back ... Some more hours later, i have just uploaded a fix using the _pic libraries. More on that later. I had to test on i386, works fine, but the prove on other archs is still to be made, the buildds seem busy. If you want to take a look during the day use url: http://buildd.debian.org/build.php?arch=&pkg=libggi current version to look for is 2.0.1+rc3-2, and don't forget to think about why that page and the machinery behind it is quite nice ;) have a nice day, martin
build fails even quicker
Hallo, All! You know that Debian supports lots of arch's: arm, hppa, ia64, m68k, hurd, sh390, i386 ... And it has set up an even better infrastructure to build on all these archs even faster and that means ... build failures come faster! This might be of interest to you: Bug#171510: libggi_1:2.0.1+rc3-1(hppa/unstable): FTBFS: non-PIC in shared lib From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: libggi Version: 1:2.0.1+rc3-1 Severity: serious There was an error while trying to autobuild your package: Shared libraries can only contain code that is built with -fPIC. ... A full build log can be found at: http://buildd.debian.org/build.php?arch=hppa&pkg=libggi&ver=1:2.0.1+rc3-1 Here is the last part of it: gcc -shared dga.lo -Wl,--rpath -Wl,/build/buildd/libggi-2.0.1+rc3/ggi/.libs -L/usr/lib ../../../../ggi/.libs/libggi.so /usr/lib/libgii.so /usr/lib/libgg.so -L/usr/X11R6/lib -lX11 -lXext -lXxf86dga -Wl,-soname -Wl,helper_x_dga.so -Wl,-retain-symbols-file -Wl,./EXPSYMS -o .libs/helper_x_dga.so /usr/bin/ld: /usr/X11R6/lib/libXxf86dga.a(XF86DGA.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libXxf86dga.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[6]: *** [helper_x_dga.la] Error 1 Sigh, just wanted to go test ggi applications. Seems, i've got to do some more. If i only knew what ... 'Some' hours later: in short: xf86dga was not built with -fPIC. No dynamic lib may link a static lib (like, eg. xf86dga) - not supported by some loaders. There are, however, as a workaround for dl_open'ed modules some xlibs built with -fPIC, mainly xf86dga here. The long version can be found here: http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00028.html cu, martin
rc3.deb
libgii_0.8.1+rc3-1_i386 uploaded to ftp-master.debian.org libggi_2.0.1+rc3-1_i386 uploaded to ftp-master.debian.org Thank you for your contribution to Debian. ;)
Re: libggi202rc3 can't build w/o installed libggi
On Monday 02 December 2002 16:59, Christoph Egger wrote: > Tnx a lot. Directfb-target was last tested against Direct 0.9.12. > Which one do you use? oops: debian unstable has libdirectfb 0.9.13. But first of all, there is no 'format' field in the relevant structure to be found in libggi/default/fbdev/directfb/ggidirectfb.h. That is the reason for the build error. btw., pls is this correct? > > i hope i've got the unification of display-x right: x, xlib, dga -> x + dga? > What's different between native libtool 1.4.3 and the Debian version? I was already going to send the changelog to you, may be i deleted the directfb version along with this. Will send to you again. Generally, upstream seems to lose some patches sent to it and some become reapplied by the deb maintainer ... > >* Configure: diff patches a strange construction away, that kept > > configure from finding the X headers (lead to: -I module.c). > > Snippet from configure.in you probably refer to: > -- > dnl This is necessary as there are plattforms, where > dnl $ac_x_includes does NOT belong to the default search > dnl path. Darwin is such a system, for example. > dnl $ac_x_includes contains the right path to the X > dnl includes (/usr/X11R6/include on most systems). > > cflags_old="$CFLAGS" > cppflags_old="$CPPFLAGS" > CFLAGS="$CFLAGS -I$ac_x_includes" > CPPFLAGS="$CPPFLAGS -I$ac_x_includes" > --- > > Brian and Paul are Debian users. They didn't complain > about such problems (yet). Why doesn't it work for you? > > I use Darwin/MacOS X, btw. > > $ac_x_includes is set by AC_PATH_XTRA. Please check, if > $ac_x_includes is actually set (and not empty). > If not, then there's something going wrong (broken autoconf?). Your exactly right so far and, yes, ac_x_includes is empty, this makes all tests fail (gcc ... -I test.c). But, ususally i don't autogen if your shipped build system is ok and generally i change as less as possible. I didn't autogen in this case. I tried configure --x-includes=... also, no change. > >* Debian/ggiteleserver.1: Add reference to (new) > > ggiteleserver.7. * Add ggiteleserver.7 to samples package. > > Move ggi-monitest man page from section 6 to 1. > > Remove display-xlib manpage from target-x. > > Eric: Could you change this manpage issue in CVS, please? > (Except the xlib one) Huh? At least i don't understand. But guess i was misleading from the beginning, sorry. ggi-monitest and teleserver.1 are written by me. I simply switched sections. When you put teleserver to 1 i have to remove mine, no problem, only it describes the switches in the manpage, which i think is better. Btw., from what i read and hear, ggi-monitest might well be the most often used (and usefull ;) ggi program in debian and it generally seems to work quite well. Lot's of people claim that this is the only ggi program they use ... martin (trying a ggi-doc package)
libggi202rc3 can't build w/o installed libggi
Good morning (TM)! Trying to build libggi ... Directfb has to be disabled, attached the least necessary patches to make it compile anyhow ... Here the relevant lines of the changelogs, i hope i've got the unification of display-x right: x, xlib, dga -> x + dga? libgii (1:0.8.1+rc3-1) unstable; urgency=low . * New upstream source: upcoming 0.8.2 releases third test candidate. Libgg-0.0.8 comes with demo for cpuid detection in examples. Man pages of event structures install in man3 (closes: #159153). * ltmain.sh updated from Debian libtool 1.4.3-2 to be able to build libgii with uninstalled libgg. ... * This Debian package of Free Software was sponsored by Angela Jaschinski, feeding fish to the cats to promote packaging works. libggi (1:2.0.1+rc3-1) unstable; urgency=low . * New upstream source: upcoming 2.0.2 releases third test candidate. Display-fbdev includes DirectFB renderer now (disabled). Display-x and -xlib unified to display-x. All manpages no longer use 'ggi' after section. * ltmain.sh updated from Debian libtool 1.4.3-2 to be able to build without installed libggi. * Configure: diff patches a strange construction away, that kept configure from finding the X headers (lead to: -I module.c). * Debian/ggiteleserver.1: Add reference to (new) ggiteleserver.7. * Add ggiteleserver.7 to samples package. Move ggi-monitest man page from section 6 to 1. Remove display-xlib manpage from target-x. >> ltmain.sh is exactly 1h20 younger than the one in your tree. >> Version is 1.9.22.111 (yours .110). > We use libtool 1.4.3. See above and my previous msgs 'libgii082rc2 can't build w/o installed libgii'. The libraries are _not_ installed w/o updated ltmain.sh. Any objections? Otherwise i'll upload these testpackages to debian tonight. have a nice day, martin bugs.gz Description: Necessary patches to libggi-2.0.2-rc3
Re: libgii082rc2 can't build w/o installed libgii
On Thursday 28 November 2002 10:57, Eric Faurot wrote: > Did you get the one regarding the manpage update? Yes, thanks a lot, i've seen it all, mails just crossed. I have only intermittent internet access (expensive dialup). Thanks to Eric and Cristoph for your mail. No need to Cc me, i'm reading the list; Eric i Cc you only this time as for the private mail. I've seen all of you have been busy working and tossing rc3 out. That's great, really, and i'm really sorry that i can't just join you on IRC, what seems to be your main conversation channel. I'm living on the countryside and Telekom insists my line is some 100m too long for broadband, so i have to live with dial up ISDN and high rates, sorry. (OT: The good news they have, is: eventually they may be able to sell me at some time in the future half the speed for the double rate i had to pay in the city - calling it DSL-light ... what a laugh). > [Christoph] Fixed in -rc3. Yup, seen it just after finishing this morning. I'll get back to this on Saturday, busy until then, have to leave _now_. Thanks, have a good time, great soft, greetings, martin
Re: libgii082rc2 can't build w/o installed libgii
On Tuesday 26 November 2002 13:25, Martin Albert wrote: > Hi, Folks! again. First part is a resend, as it didn't seem to reach the list. Just verified the chroot experiment. Referring to the buildlog in my message from Tue, 26 Nov 2002 13:25:10 +0100, same Subject: libgii is not built, because libgg is not found. You see every other Makefile has its xxx_la_LIBADD variable respected, it simply can not be seen in the gcc invocation for gii. linux_evdev produces duplicate symbol warnings (uint16). Eric Faurot wrote in other mail, he moved the manpages from 9 to 7. Are you comfortable that the .so links point to manXgii/... I still have to hack them then to point to manX instead o manXgii. He also gave me some clues how to build the docs (thanks). Any objections against a debian 'libggi-doc' package from 'ggi-xml.tar.bz2'? ./configure requires g++, otherwise it breaks: g++ can't produce output, although it noticed before that no g++ is available. --- new --- Now, i've built from cvs. First, i personally think Eric did the right thing to not move event manpages to 7 but 3, although they do not specifically describe library routines. The .so links still point to (nonexisting) manXggi sections under man. linux_evdev produces duplicate symbol warnings (uint16). g++ is no longer required: The removal of AC_PROG_CXX did it (thanks christoph). Is there a mailing list for cvs changes? After several hours and giving up - one last try: libgii still wouldn't build without an already installed libgg. I libtoolized -c -f with debian unstable version - IT WORKS!! ltmain.sh is exactly 1h20 younger than the one in your tree. Version is 1.9.22.111 (yours .110). That's how far i could go today, we have shows to do on the weekend. I'll upload to private server for testing/review as soon as i'm able. In case noone objects, i try to build nice libgii-doc. 'd like to include some sort of a mirror of the mostly visible pages from www.ggi-p.o, they not only look good but have some info not easily found in the docs. I will send a link to the list a few days before actually uploading to debian, so anyone interested might have a look, as i'm (still) lacking any experience with sgml/xml and stuff. I'm now prepared to do cvs packages more frequently (todate i do only pkg released material). Really like to have your input on that matter. have a nice day, martin
Re: libgii082rc2 can't build w/o installed libgii
On Tuesday 26 November 2002 13:25, Martin Albert wrote: > Hi, Folks! again Just verified the chroot experiment. Referring to the buildlog in my previous message: libgii is not built, because libgg is not found. You see every other Makefile has its xxx_la_LIBADD variable respected, it simply can not be seen in the gcc invocation for gii. linux_evdev produces duplicate symbol warnings (uint16). Eric Faurot wrote in other mail, he moved the manpages from 9 to 7. Are you comfortable that the .so links point to manXgii/... I still have to hack them then to point to manX instead o manXgii. He also gave me some clues how to build the docs (thanks). Any objections against a debian 'libggi-doc' package from 'ggi-xml.tar.bz2'? ./configure requires g++, otherwise it breaks: g++ can't produce output, although it noticed before that no g++ is available. > martin
libgii082rc2 can't build w/o installed libgii
Hi, Folks!
Sorry, i sent mail yesterday with broken header, should be fixed.
After finishing the package i checked building in a clean chroot:
libgii won't build. After some hours now i still can't find out why.
Attached are the relevant sections from the buildlog, gzipped.
The quick hack i had to use for the manpage problem reported yesterday:
#! /bin/bash
# fix_manpages tim 20021125 # patch man pages of libgii 0.8.2rc2 to
# - be in man7 instead of man9
# - not include manXgii but manX
for file in debian/tmp/usr/share/man/man9/*.9*; do
sed -e 's/9g\(.\)i/7g\1i/g' $file
>debian/tmp/usr/share/man/man7/`basename ${file%.9gii}`.7gii
done
for file in debian/tmp/usr/share/man/man[37]/*.[37]*;do
sed -e '/^\.so/ s:\(man[37]\).*/:\1/:' $file >debian/SEDTMP
mv debian/SEDTMP $file
done
I managed to build html from ggi-xml.tar.bz2 usable, but it seems i
missed some script or else that you use to put the stylesheet refs in
as well as changing the filenames?
gotta get some sleep (ooh, less than 2 hours left), have a nice day,
martin
libgii-0.8.1+rc2.log.gz
Description: libgii build log
libgii082rc2 for debian/unstable, bugs with man pages, docs
Hi, y'all! You fixed the library name before i could complain ;) And redid the manpages ...: I) Now the '.so' links refer to '../manXggi/manX/...'. I'm sure this would trigger even more bugreports :), than the one to forward to you: II) >> Bug#159153: libgii0-dev: manpages in section 9? ... gii_key_event.9gii.gz gii_valuator_event.9gii.gz According to "man man" section 9 is for kernel routines, and is nonstandard. I think these manpages belong to section 7. Please rename and move >> I'ld rather prefer man5 (file formats), but see man7 to be a 'safe' (although rather crowded) place. In the very moment i prepare a patch for '...-rc2.tar.bz2' to fix the '.so' lines as well as moving the man9 pages to man7 just after building the libs and before installing to the debian package. III) I very much apreciate the docs from the webpage, made a (still) unofficial debian package from your HTML version. I haven't yet found a way to format the xml myself using standard debian packages and so cannot prepare a reasonable source package. Any hints?
Re: GGI Demos and Utilities : Compilation and Runtime problems on Solaris
On Thursday 18 October 2001 16:33, Brian S. Julin wrote:
> On Thu, 18 Oct 2001, Ulhas Samant wrote:
> > We could build the GGI on Solaris
> > However we get the following errors while building GGI demos.
...
> > "wrap.c", line 59: undefined symbol: socklen_t
> > "wrap.c", line 59: syntax error before or at: len
Not that one again. Apologies to all using a FREE os already and so
wouldn't need mail to read the quoted version of accept(2):
NOTE
The third argument of accept was originally declared as an `int *'
(and is that under libc4 and libc5 and on many other systems like BSD
4.*, SunOS 4, SGI); a POSIX 1003.1g draft standard wanted to change it
into a `size_t *', and that is what it is for SunOS 5. Later POSIX
drafts have `socklen_t *', and so do the Single Unix Specification and
glibc2. Quoting Linus Torvalds: _Any_ sane library _must_ have
"socklen_t" be the same size as int. Anything else breaks any BSD
socket layer stuff. POSIX initially _did_ make it a size_t, and I (and
hopefully others, but obviously not too many) complained to them very
loudly indeed. Making it a size_t is completely broken, exactly because
size_t very seldom is the same size as "int" on 64-bit architectures,
for example. And it _has_ to be the same size as "int" because that's
what the BSD socket interface is. Anyway, the POSIX people eventually
got a clue, and created "socklen_t". They shouldn't have touched it in
the first place, but once they did they felt it had to have a named
type for some unfathomable reason (probably somebody didn't like losing
face over having done the original stupid thing, so they silently just
renamed their blunder).
Here's how i 'did to' cthugha once:
configure.in:
AC_EGREP_HEADER(socklen_t, bits/socket.h, AC_DEFINE(HAVE_SOCKLEN_T))
acconfig.h:
/* silly socklen_t instead of int is used */
#undef HAVE_SOCKLEN_T
src/cthugha.h:
#include "../config.h"
...
#if HAVE_SOCKLEN_T
# define SOCKLEN_TYPE socklen_t
#else
# define SOCKLEN_TYPE int
#endif
> > "wrap.c", line 75: warning: argument #2 is incompatible with
> > prototype: prototype: pointer to struct sockaddr {ushort sa_family,
> > array[14] of char sa_data} : "/usr/include /sys/socket.h", line 295
> > argument : pointer to const struct sockaddr {ushort
> > sa_family, array[14] of char sa_data} "wrap.c", line 83: undefined
> > symbol: bufsize
This one is ugly. Bash had problems at some 4.anything versions, don't
know about the solution. Usually i'm not, but bits/socket.h makes me
afraid. ;) so i forgot what i did ...
> > "wrap.c", line 126: cannot recover from previous errors
This should have come earlier, at least before
> > "wrap.c", line 91: undefined symbol: text
What a nice plug: Dear Aunt aGGI, would you once consider to install
the demos of libggi2 again? I would really like to show them to all my
friends at Debian, they are so nice! But i guess that you have a reason
that you don't install them and so i don't include them in my package.
You know that i've got only that boring old i386 and not the money to
buy another machine so that i might test other archs - i really wish i
could - but here they work just fine.
Truely yours, martin
Re: Error compiling libggi-2.0.1
On Saturday 15 September 2001 15:52, Sven Garbade wrote: > Maybe this helps: Debian Potato, Xfree 3.3.6, Kernel 2.2.17 > > I just wanted to compile libggi-2.0.1, but this error occured: Debian libggi_2.0.1 has build depends only for xlibs-dev from X4, not xlib6g for X3. The binary packages depend on xlibs | xlib6g, but the libc might be quite high against potato (used the oldest acceptable for woody). Instructions to compile on potato can be found in the source package in debian/README.potato. Basically: You can't build libggi2 (dga at least) with X3 development libraries. This is not Debian specific. You may try to configure with --disable-dga. I'm clearly interested in keeping as much backward compatibility as possible, currently the mentioned problems exist. Greetings, martin
Re: GGI in Debian
On Monday 10 September 2001 21:27, Martin Albert wrote: > Hello, y'all! > Any activities since or comments on libggidemos_990518? > Regarding its debian packaging this is to be updated next. Looking around for demos on ftp.ggi-project.org and after debians libggidemos package, i suggested to remove it from the debian archive. I tried some programs i found on ftp.ggi-proj (not yet from CVS) and will go on, evtly putting together a new -samples/-demo package. Suggestions and Contribs welcome! :o) have fun, greetings, martin
Re: GGI in Debian
Hello, y'all! last weeks uploads to debian/unstable: libgii_0.8.1-1, libggi_2.0.1-1, libggimisc_2.0.1-1, svgalib4libggi_0.6-4 Looking for a(ny) maintainer for svgalib4libggi. Mail to marcus@ returned undeliverable, i believe because of the @ggi-project.org. Any activities since or comments on libggidemos_990518? Regarding its debian packaging this is to be updated next. greetings, martin
ggi 201
Huh! see, it's me already again. What a nice oracle to ask, everything you wanted to know, tgz, by, ftp, http - so nice ... Only the quest for 'svgalib4libggi' remains unasnwered, just murmured sth. like ..., well, actually i didn't understand. Somebody active on that? I still try to get that old version to do sth. usefull. Have fun, martin
ggi 201
Yeah, consulting the download oracle in the very moment! Lets see what you daring people have put together. I take it with me and hope to bring back some nice debian packages. Thanks a lot, have a good time, lots of fun and don't be too sad, that you won't here from me for a whole week now ;-) greetings, martin
Re: GGI in Debian
On Friday, 24. August 2001 01:56, Brian S. Julin wrote: > Debian is very far from being a fixed-configuration embedded system > :-). But a small step further in becoming a GGI distro: A prerelease of GGI source packages for debian is available: deb-src http://home.t-online.de/home/eislink/debian unstable main If the above line is correct, then that URL is also valid in the future (as since init on Jan 31, 2001). Homepage is http://eisbox.debox.de There is libgii_0.8-2 and libggi_2.0.0-1, based on the known stable release of GGI; more issues below. No! static library support and no! plans to include that in libgii_0.8.1-1 or libggi_2.0.1-1 (see other mail). Today i noticed that i was hunting an ld bug for the last two days (sigh) instead of tracing libgii behaviour with statically linked interface libraries. I felt so sure in my cleanroom build chroot, that i didn't notice latest binutils fixing a quite nasty x86 ld bug! Example is the one i told you about in 'GGI in Debian - Probs': configure test for aa_autoinit fails: /usr/lib/libgpm.so.1: undefined reference to `atexit' Back to the debs (sources), some questions, but first: ask in case you really want debs (binaries) from the above http. That way they would even once be tested ;-) - A .la file is generated by ggi build and included in the debs by me, for each input- and display-target, module (how're they called, sublibs?). Possibly used from dynloader? Or useless and away with it? - target-aa tends to segfault, on each exit at least. - demos are built, but not installed. I'ld be happy to include them as well as inputdump, ... to the libggi-samples package. - sad not all sublibs/filters/tools are documented., but nice to see the latest additions. Added manpages myself, but am admittedly not quite sure yet what that programs really do. - described: "ipc" draws into attached shared memory framebuffers ?? - Changelog1999.gz takes 22,5k. Do you see this as part of the complete docs of 2.0? Thanks for your assistance. GGI is cool! After this mail, i will get the latest_tarball to see how packaging matches. Debian might still take a little while to release and as long your source remains available from http[1] protocol also, i should be able to get it. Thanks for your attention, greetings, martin [1] http://ftp.ggi-project.org is fine, SourceForge is ftp only (?) A potato backport using xfree86-3 (without dga) works here too.
Static linking against libgii
(Tinkered with ggi also: Segf'ting quicker, but less readable screen. :) Built and installed gii-deb with configure --enable-static. Build gii/demos/demo.c: gcc -static demo.c -lgg -lggi -ldl demo crashes init'ing stdin (from giiOpen). Chgd. second input in demo.c:main: inp2=ggiOpen from input-stdin to input-null or input-tcp:listen:2. demo crashes joining inputs. Produced on two different debian (deb-src, !deb) machines. Also after installing new ld ;) The GGI_DEBUG=127 output, especially pointer returns from alloc, dl_open and init were, interestingly enough, very similar, both w. static and shared linking. Looked ok. But sure crash when calling input-stdin's init ... >:-/ Lets see. Have fun, greetings, martin
Re: GGI in Debian
On Friday, 24. August 2001 00:16, Thayne Harbaugh wrote: > There's another way to look at things: > ... > Now, tell me where I'm wrong. I think you're right and ggi is wrong in that it does sth. good being highly dynamic and to instantly rewrite this to also be static is bad. I believe your statement really makes a point. GGI will make it's way. Concerning debian, you might have read my mail in the meantime. I still believe this is FUD from a Puszta-BSDy (don't get me wrong, i've got friends over there, i mean Hungaria, not BSD ;-) I try to find a way with debian anyway. After thinking a few minutes after the last post: can you imagine a statically linked input-null of 500k? The libggi package might come directly behind xfree in size. In case it would not be possible to find a solution without, would i try to get static interface libs working. Might need some help of yours. Really useful statics (in the sense of Thaynes and Brians ideas) are a long way ahead as far as i understand that pieces of code that i've come by yet. So, may the FUN be with us, greetings, martin
Re: GGI in Debian
On Thursday, 23. August 2001 23:35, Brian S. Julin wrote: > Hopefully this is not what Debian wants -- what makes most sense > for Debian is to build libraries/sublibs that are statically linked > against everything else (libc/xlib/etc) but still are dynamically > loaded by a statically linked libggi (which is statically linked to > libgii/libgg). > > That is, assuming a staticly linked library _can_ dlopen (?) Wow, suddenly lot's of 'static' here. ;-) Hope this is cool. Debian _policy_ requires static interface libs: libgii.a, libggi.a ... What you describe is the only correct solution (that is not required). And, yes, you link with -ldl. The loading is not the problem. input-stdio crashes when init is called. Others when gii/demo.c joins inputs. Some dynamics (for variaty): There should be no reason why dynamically loaded modules, dynamically linking to the libs on my system, loaded from a statically linked program shouldn't work - but i go check now how to build your proposed statically linked sublibs, may be that's giving the segfaults. Can't believe, though. Another issue is that static libs shouldn't be built with -fPIC, but exactly that happens when simply configuring with --enable-static. Heading back to the box, martin
Re: GGI in Debian
Don't want to produce noise, but: I tried some static linking of ggi and gii libs using the demos. Short: Segfaulting all the way. Logs available on request. I possibly did not do the right thing. Configure with --enable-static and use the resulting .a's. I will (have to) play on with this. As i thought you might be interested, did i crosspost a mail to debian-devel to this list also. May the fun be with us! Greetings, martin
Re: GGI in Debian
On Wednesday, 22. August 2001 23:41, Brian S. Julin wrote: > Do you really mean Debian wants every single LibGGI target, renderer, > and extension lib all rolled into one .a? What do other packages > that have plugins do for their -dev static libraries? I mean, a > static (i.e., linked statically against libc) version of just the > base libggi/libgii would be possible, and may even already work, but > the modules cannot be static without building them in. I certainly > hope that the latter is what the Debian policy really wants and not > the former. Not into one .a :) Each -dev package MUST (that's the problem) have static libs corresponding to the shared libs that are in the shared-libs-package. > > *Bugs: libggidemos and svgalib4libggi collected lots and look bad. > > I'll look into those reports. I don't even know where the svgalib > wrapper is kept these days... I'll take care as soon as libggi_2.0.1 is out. What is needed are demos, or i'ld have to rebuild the old package. > Re: LibGGIMISC, it is not easy to move that back into the tree; it > will have to be split as a package. And, I am actually about to add > some more functions. I will have to file an ITP (Intent to package) then to bugs.debian.org. And i've got one more package ... ;) > > -- > Brian Tnx, martin
GGI in Debian - Probs
currently packaging libggi-2.0final: libggimisc is not part of the archive. Is it required? Latest libggi packages included it (out of the libggi tarball). - I did: automake, aclocal, autoconf to the source (libtool.sh was NOT affected). - FYI only: libgpmg1_1.19.3-6 (current in testing and unstable) is giving me trouble. configure test for aa_autoinit (and so building of the aa-target) fails: configure:8089: checking for aa_autoinit in -laa configure:8108: gcc -o conftest -g -O2 conftest.c -laa 1>&5 /usr/lib/libgpm.so.1: undefined reference to `atexit' As a workaround i use libgpmg1_1.17.8-18 to build. Haven't yet determined who really earns that bug report. - --enable-static builds additional .a files, their names entered under oldlibs in the .la files, but everything seems to be compiled with -fPIC. Is this enough for static linking already? (Sure im going to try myself - as soon as this mail is ready ;-) - libtool gives me warnings like: /bin/sh ../../libtool --mode=install /usr/bin/install -c mansync.la /home/tim/ggi/libggi/debian/tmp/usr/lib/ggi/display/mansync.la libtool: install: warning: relinking `mansync.la' ... libtool: install: warning: remember to run `libtool --finish I read the thread on ggi-devel, debian-devel and the autoconf-,libtool-book in parallel but still can't decide wether this is now in error or not. The only difference i can see between _old_ versions and current is that the old version used relative paths where possible while the new one goes absolute everywhere. It seems to do the right thing, adapting from build-location to install (/usr/lib/...). - Building the monitest-docs to .txt gives me some errors i did not have before and the intro part of the resulting .txt has _very_ short lines (currently i have linuxdoc-tools installed. May be i would need another version of sgml2xxx. The docs tool chain was posted some time ago on ggi-devel, but i must have deleted those msgs): ( set -e; \ cd programs/util/monitest;\ sgml2html monitest.sgml; \ sgml2txt monitest.sgml) Processing file monitest.sgml :80: warning: number register `0:ds-type' not defined :80: warning: number register `0:LL' not defined :80: warning: number register `0:ri' not defined :80: warning: number register `0:LT' not defined :80: warning: number register `0:li' not defined :80: warning: `FAM' not defined :80: warning: number register `0:PS' not defined :80: warning: number register `0:VS' not defined :80: warning: vertical spacing must be greater than 0 :80: warning: number register `0:PD' not defined :80: warning: number register `0:PI' not defined :80: warning: can't break line - What about the demos that are not built/installed? Not yet ready? How do i do monitest in fullscreen (x-target)? It's a whishlist bug. Any docs that are not in the ggi tarball and might be worthwhile a ggi-doc package (mirrored the ggi-project page already, but still have to sort this out). - Well, just a few Qs, nothing serious ;-) I hope that you didn't mind me asking them here? In any case feel free to flame me - can take it most of the time ... Lot's of fun to all of us, greetings, martin
GGI in Debian - Intro
Good Day, dear GGI Developers! My name ist Martin and i have a debian package 'cthugha' that depends on 'mesa' libraries that depend on 'libggi'. In march 2001 they were out of sync and suddenly i was the maintainer of GGI for Debian. ;-) And i really want to be, but i'll still have to learn a lot! I follow and archive 'ggi-develop' since then (coding and release internals deleted) and try to grab what that GGI is and how it works. I found some more hints during the last days (Brians roadmap for future directions, mostly) but i live under the impression that i'm not the only one to be a little disturbed by all that libs with their fine names and the projects going on. I think the state of GGI in Debian was a little sad - Charles, the former maintainer built and maintained some well thought pkgs and did a very good job to provide a stable basis, but also due to the unusual nature of GGI, it's docs and so on, it simply is required for some other pkgs but besides that, i'm afraid, doesn't get too much attention. I'm still in the process to keep up with his old work, ggidemos and xserver-ggi still have to be changed to conform to current debian policy, svgalib4libggi is in an unusable state and i'm actively working on libgii (0.8) and libggi (2.0). Please understand that i would very much like to be more involved and that only (partly massive ;-) real world probs do keep me from working from time to time. But i'll always be back (except for the last time then)! For better readability, i'll close my intro here and continue the next mail with details. Thank you for all the efforts you put into GGI to make it a real Fun. Greetings, martin My mail adress is in the header (as most spammers know meanwhile), ma at debian org is the official maintainer and my homepage URL is http://eisbox.debox.de, sorry it's a framing redirector pointing to where the latest debs can be found: deb-src http://home.t-online.de/home/eislink/debian unstable main
Say hello!
Hello, to all friendly people on this list! Anybody listening? I know of two subjects waiting for anything after subscription. Any technical problems or software too good :) ? Anyone going to listen for Bugreports? I would send one or two. Nothing serious, just changes to hardcoded constants. Thanks for all your work on gii and ggi, greetings, martin
