libbonobo, GConf, gnome-vfs (was Re: desktop-file-utils, hicolor-icon-theme, shared-mime-info, startup-notification)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: | Or send me your READMEs? No just kidding, I don't care much at the moment | if there are more or less packages. I think we should get the stuff | uploaded to get some feedback from the beta testers, even if the README is | missing. | | Also to investigate, which packages need postinstall scripts, I know a few, | but for sure there are more. OK, I worked through libbonobo2, GConf2, and gnome-vfs2. Anything dependent on GConf (and installs schemas) certainly needs postinstall and preremove scripts; see gnome-vfs2 for examples. I worked from your source packages, changed the build-scripts, READMEs, setup.hints, etc. Please take a look at these packages and if you like what I did, then feel free to take them (I'd rather not maintain these ones, but I'm willing to help package this time to get us started). Notes (which may not be showstoppers): libbonobo: * make check seems to get stuck at test 13, not sure why (waiting for something to close?). GConf: * gconftool-2 --shutdown does not kill gconfd-2 (not a surprise); * good news: Gnome2::GConf tests against this look good. gnome-vfs: * I included the necessary postinstall and preremove scripts, these ~ could be used as a template for later GConf-dependent packages; * I built gnome-ls (http://mrod.interfree.it/index.html) against this, ~ seems to work properly; * Gnome2::VFS tests raise errors: /usr/bin/perl.exe -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/GnomeVFS.ok t/GnomeVFSDirectoryUrgh, couldn't delete the scratch directory: Directory not empty # Looks like your test died just after 26. dubious ~Test returned status 255 (wstat 65280, 0xff00) ~after all the subtests completed successfully t/GnomeVFSFileInfo.ok t/GnomeVFSOps..Urgh, couldn't delete the scratch directory: Directory not empty # Looks like your test died just after 44. dubious ~Test returned status 255 (wstat 65280, 0xff00) ~after all the subtests completed successfully t/GnomeVFSURI..ok t/GnomeVFSUtilsok t/GnomeVFSXfer.Failed 2/7 test scripts, 71.43% okay. 0/201 subtests failed, 100.00% okay. ok Failed Test Stat Wstat Total Fail Failed List of Failed - --- t/GnomeVFSDirectory.t 255 65280260 0.00% ?? t/GnomeVFSOps.t255 65280440 0.00% ?? The Gnome2::VFS owner wasn't online tonight, so I'm not sure what are the cause(s) of these failed tests. I've uploaded packages (forgot the setup.hints, but they're in the source packages) to http://cygwin-ports.sourceforge.net/install/temp/ for you. Yaakov N.B. I forgot that gnome-vfs probably depends on shared-mime-info and gnome-mime-data; these should be added to the setup.hint at least, if not the README if you get the chance. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBb4Y+piWmPGlmQSMRAuCEAJ9xX3CkMQHWwR8l3B2sY3tWNwXZsACcDgy3 dgoQhERXmvNP16TOl8ZX8tc= =9C4n -END PGP SIGNATURE-
update: guile-1.6.5 and 1.7.1.CVS
Hi, New upstream guile stable release, and CVS snapshot. Guile CVS has, amongst other things, gmp rationals and a new garbage collector by Han-Wen, which is most helpful for development, esp. debugging. Please upload. Jan. http://lilypond.org/cygwin/uploads/guile/setup.hint test: 1.7.1.20041006-1 curr: 1.6.5-1 sdesc: The GNU extension language and Scheme interpreter (executable) category: interpreters # Strictly, guile does not depend on readline and curses, but if you # want the guile executable, you probably want readline editing. -- jcn requires: cygwin libguile16 libguile12 libncurses7 libreadline5 ldesc: The GNU extension language and Scheme interpreter (executable) Guile, the GNU Ubiquitous Intelligent Language for Extension, is a scheme implementation designed for real world programming, supporting a rich Unix interface, a module system, and undergoing rapid development. `guile' is a scheme interpreter that can execute scheme scripts (with a #! line at the top of the file), or run as an inferior scheme process inside Emacs. http://lilypond.org/cygwin/uploads/guile/guile-1.6.5-1-src.tar.bz2 http://lilypond.org/cygwin/uploads/guile/guile-1.6.5-1.tar.bz2 http://lilypond.org/cygwin/uploads/guile/guile-1.7.1.20041006-1-src.tar.bz2 http://lilypond.org/cygwin/uploads/guile/guile-1.7.1.20041006-1.tar.bz2 === http://lilypond.org/cygwin/uploads/guile/guile-devel/setup.hint test: 1.7.1.20041006-1 curr: 1.6.5-1 sdesc: Development headers and static libraries for Guile. category: devel libs requires: cygwin guile libguile16 libguile12 external-source: guile ldesc: Development headers and static libraries for Guile. `libguile.h' etc. C headers, aclocal macros, the `guile-snarf' and `guile-config' utilities, and static `libguile.a' libraries for Guile, the GNU Ubiquitous Intelligent Language for Extension. http://lilypond.org/cygwin/uploads/guile/guile-devel/guile-devel-1.6.5-1.tar.bz2 http://lilypond.org/cygwin/uploads/guile/guile-devel/guile-devel-1.7.1.20041006-1.tar.bz2 === http://lilypond.org/cygwin/uploads/guile/guile-doc/setup.hint test: 1.7.1.20041006-1 curr: 1.6.5-1 sdesc: The GNU extension language and Scheme interpreter (documentation) category: doc requires: texinfo external-source: guile ldesc: The GNU extension language and Scheme interpreter (documentation) This package contains the documentation for guile, including both a reference manual (via `info guile'), and a tutorial (via `info guile-tut'). http://lilypond.org/cygwin/uploads/guile/guile-doc/guile-doc-1.6.5-1.tar.bz2 http://lilypond.org/cygwin/uploads/guile/guile-doc/guile-doc-1.7.1.20041006-1.tar.bz2 === http://lilypond.org/cygwin/uploads/guile/libguile12/setup.hint #test: 1.7.1.20041006-1 #curr: 1.6.5-1 sdesc: The GNU extension language and Scheme interpreter (runtime libraries) category: libs requires: cygwin libltdl3 external-source: guile ldesc: The GNU extension language and Scheme interpreter (runtime libraries) Guile shared object libraries and the ice-9 scheme module. Guile is the GNU Ubiquitous Intelligent Language for Extension. http://lilypond.org/cygwin/uploads/guile/libguile12/libguile12-1.6.5-1.tar.bz2 === http://lilypond.org/cygwin/uploads/guile/libguile16/setup.hint #test: 1.7.1.20041006-1 #curr: 1.6.5-1 sdesc: The GNU extension language and Scheme interpreter (runtime libraries) category: libs requires: cygwin gmp libltdl3 external-source: guile ldesc: The GNU extension language and Scheme interpreter (runtime libraries) Guile shared object libraries and the ice-9 scheme module. Guile is the GNU Ubiquitous Intelligent Language for Extension. http://lilypond.org/cygwin/uploads/guile/libguile16/libguile16-1.7.1.20041006-1.tar.bz2 === -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
Jean-Sebastien Trottier writes: Hi All (and Chris in particular), I've already been successful in getting the following to compile as native Cygwin packages with minimal patches: Tcl v8.4.7 (without registry and DDE) Tk v8.4.7 Itcl v3.2.1 with Iwidgets v4.0.1 expect v5.42.1 I also intend to add Tclx and Tcllib and try to port the registry and DDE libraries (part of Tcl) that are normally only for straight Windows platform. Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. +1*10^10 These are great news, I think cgf is already dreaming about a gold star, if you follow your way through the end. Some questions: - Did you manage to compile the libs as shared libs - Is wish working for you, last time I tried, it started up but was not response to any input Cheers, Sebastien Ciao Volker
Re: avoiding a huge Cygwin patch
Andrew schrieb: Actually, I think it might even be less trouble to create a separate docs package than to try cramming extra binary files into the unison one, but it's really up to you. Well creating a unison-doc package would be easy-- it only has two files, the HTML and PDF manuals. But please tell me that for the source package I wouldn't then have to get the TeX source and compile it into HTML and PDF using the Hevea compiler, which would then require a package of its own-- I'm entirely uninterested in going down that road. Having Hevea is an option now since we have O'Caml included now. Would be nice to have it, maybe there is someone interested to maintain it? For just a docs package, can I get away with having no corresponding src package at all? Hmmm, there is already another docs package where special tools not in the Cygwin distribution included are needed (dygwin-doc;), so it should be no showstopper, but at least providing a package including the document source would be fine. Gerrit -- =^..^=
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
Jean-Sebastien schrieb: Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. Yes, +1 from me. There are packages out there depending on Cygwin and non Cygwin TCL/TK versins, would be really great to have this as official version. Gerrit -- =^..^=
Re: Please test: openldap-2.2.17-2/libopenldap2_2_7-2.2.17-2/openldap-devel-2.2.17-2
Gareth Pearce writes: I have successfully used your openldap build to login and query a directory using in directory SASL Digest-MD5 authentication. Great, I'll announce shortly to upload the new packages... Regards, Gareth Pearce Ciao Volker
Re: desktop-file-utils, hicolor-icon-theme, shared-mime-info, startup-notification
Hi Yaakov, Thanks for uploading, but I think you missed the setup.hint for gnome-common, could you check and upload again if necessary? Fixed. GNOME category: | No, I don't think we need it. Put it in X11 and others? Or should we | request another category again? The problem is that some stuff is backend (ORBit2, libbonobo, GConf, VFS), some is frontend (GTK, libglade, libgnomecanvas, etc.), some are desktop-related (metacity, nautilus, gnome-session), etc. What we have already is very spread out, and some things can't be well categorized right now. I still think we need a GNOME category. Yes, sounds reasonable to me. Ask the maintainer... SQLite: | It was a request from Jari. It may be that he comes back with a fixed | version of his package. I think I add this to my list and maintain it | myself if he doesn't respond until the weekend. Or you may ask Reini, | he has also lot of packages, but he wants to contribute this GIS stuff | and this needs sqlite too. Maybe we should provide two packages, | sqlite2 and sqlite3, IIRC 2 3 versioned releases they are incompatible. I built sqlite-2.8.x for use in my libgda, so if you need someone for sqlite2 that would be pretty easy for me. Can both be installed in parallel? Yes, can both be installed. Must do it like with BDB2/3/4 then because of the headers and import libs, but it works. Jari replied, I sent my pactches. Is sqlite2 required for libgda or does it work with sqlite3 too? If not we should skip sqlite2. | Or send me your READMEs? No just kidding, I don't care much at the moment | if there are more or less packages. I think we should get the stuff | uploaded to get some feedback from the beta testers, even if the README is | missing. Before you upload, let me go through the packages and see what's needed. ~ I've already run tests on GConf and gnome-vfs by building their perl modules, and it looks like something's missing; I'm building GConf from your source now to figure it out, and while I'm at it I'll fix a few things so that it'll be ready to post. BTW, I think those packages whose libs are versioned 2 or 2.0 should also be numbered with a '2' (i.e. libbonobo(ui)2, GConf2, gnome-vfs2, libgnome(ui)2). Notice I've done this with libglade and libgnomecanvas, but not libwnck (which is libwnck-1), and I believe there's precedent in the linux distros for this. Yes, ok, will do so. Nautilus: | I'll try that. The nautilus problem is known, just no idea yet what to do | about the XKB errors. Haven't yet got that far. Nautilus 2.4 was different, they use now gnome-vfs stuff to get the available mounts, probably the fix needs to be placed in gnome-vfs. BUGS: | I just step through the list provided at the GNOME website, I've arrived | at bug-buddy, so it is time to put some stuff up, now as the users may | submit bugs to the tracker;) Let's make sure that any bugs are in GNOME and not in what we've done first. We don't introduce bugs, do we? Gerrit -- =^..^=
Please upload: openldap-2.2.17-2/libopenldap2_2_7-2.2.17-2/openldap-devel-2.2.17-2
Hi Please upload at your earliest convinience. cut here #!/bin/bash mkdir -p openldap openldap/openldap-devel openldap/libopenldap2_2_7 cd openldap wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/openldap-2.2.17-2.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/openldap-2.2.17-2-src.tar.bz2 cd openldap-devel wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/openldap-devel/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/openldap-devel/openldap-devel-2.2.17-2.tar.bz2 cd ../libopenldap2_2_7 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/libopenldap2_2_7/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/openldap/libopenldap2_2_7/libopenldap2_2_7-2.2.17-2.tar.bz2 cut here DESCRIPTION: Lightweight Directory Access Protocol clients, servers and libraries. CYGWIN NEWS: * Added SASL support Old CYGWIN NEWS: * Fixed packaging bug: Directory tree /usr/share/openldap/ucdata moved from openldap-devel to openldap package Old openldap NEWS = OpenLDAP 2.2.17 Release Fixed slapd syncrepl memory leak bugs Documentation Updated ldif(5) OpenLDAP 2.2.16 Release Fixed libldap getaddrinfo hints portability bug (ITS#3279) Fixed libldap find_connection bug (ITS#3280) Fixed libldap SASL host connected to bug (ITS#3298) Fixed libldap SASL proper sockbuf bug Fixed libldap results lc bug (ITS#3250) Fixed ldapsearch paged results size 0 bug Fixed slapd syncrepl SSF propagation bug (ITS#3131) Fixed slapd ACL sets bug (ITS#3140) Fixed slapd bind referral bug (ITS#3264) Fixed slapd syncrepl misc bugs (ITS#3259,3297) Fixed slapd overlays CSN CTX bug (ITS#3288) Fixed slapd sun_path portability bug Fixed slapd permissive modify bug Fixed slapd hang bug (ITS#3309) Fixed slapcommon shutdown bug (ITS#3326) Fixed back-bdb CSN CTX bug (ITS#3301) Fixed back-bdb id2entry bug Fixed back-bdb syncrepl psearch delete bug (ITS#3309) Fixed back-ldap/meta known controls bugs (ITS#3291) Fixed back-monitor syncrepl bug (ITS#3265) Fixed slurpd replog error message bug (ITS#3275) Added slapd syncrepl exattrs (ITS#3289) Updated slapd SLAPI Updated LDAP C++ library Documentation Updated provided RFCs and I-Ds Updated ldap_url(3) (ITS#3310) Thanks Volker
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
On Fri, Oct 15, 2004 at 10:09:28AM +0200, Dr. Volker Zell wrote: Jean-Sebastien Trottier writes: Hi All (and Chris in particular), I've already been successful in getting the following to compile as native Cygwin packages with minimal patches: Tcl v8.4.7 (without registry and DDE) Tk v8.4.7 Itcl v3.2.1 with Iwidgets v4.0.1 expect v5.42.1 I also intend to add Tclx and Tcllib and try to port the registry and DDE libraries (part of Tcl) that are normally only for straight Windows platform. Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. +1*10^10 TNATTYHWTFI (There's no acronym to tell you how warm the feeling is!) These are great news, I think cgf is already dreaming about a gold star, if you follow your way through the end. Some questions: - Did you manage to compile the libs as shared libs Have a look at my current test directory: [EMAIL PROTECTED] (0) ~] ll test/bin total 2822 -rwxr-xr-x1 jst None 158383 Oct 15 03:17 cygMpexpr10.dll* -rwxr-xr-x1 jst None 215695 Oct 14 21:16 cygexpect5.42.dll* -rwxr-x---1 jst None 123114 Oct 14 22:59 cygitcl3.2.dll* -rwxr-x---1 jst None57251 Oct 14 22:59 cygitk3.2.dll* -r-xr-xr-x1 jst None 735489 Oct 14 21:07 cygtcl8.4.dll* -r-xr-xr-x1 jst None 930546 Oct 14 21:12 cygtk8.4.dll* -rwxr-xr-x1 jst None 177866 Oct 14 21:16 expect.exe* -rwxr-xr-x1 jst None 182994 Oct 14 21:16 expectk.exe* -rw-r--r--1 jst None 223444 Oct 14 21:16 libexpect5.42.a -rw-r-1 jst None 886 Oct 14 22:59 libitclstub3.2.a -rw-r-1 jst None 770 Oct 14 22:59 libitkstub3.2.a -rw-r-1 jst None 1194 Oct 14 21:07 libtclstub8.4.a -rw-r-1 jst None 2308 Oct 14 21:12 libtkstub8.4.a -rwxr-xr-x1 jst None34010 Oct 15 03:17 mpksc* -rw-r--r--1 jst None 7088 Oct 14 21:07 tclConfig.sh -rwxr-x---1 jst None13309 Oct 14 21:07 tclsh8.4.exe* -rw-r--r--1 jst None 3469 Oct 14 21:12 tkConfig.sh -rwxr-x---1 jst None14132 Oct 14 21:12 wish8.4.exe* [EMAIL PROTECTED] (0) ~] ll test/lib total 0 drwxr-x---+ 2 jst None0 Oct 15 03:17 Mpexpr10/ drwxr-x---+ 2 jst None0 Oct 14 21:16 expect5.42/ drwxr-x---+ 2 jst None0 Oct 14 23:00 itcl3.2/ drwxr-x---+ 2 jst None0 Oct 14 23:00 itk3.2/ lrwxrwxrwx1 jst None 32 Oct 14 23:00 iwidgets - /home/jst/test/lib/iwidgets4.0.1/ drwxr-x---+ 4 jst None0 Oct 14 23:00 iwidgets4.0.1/ drwxr-xr-x+ 8 jst None0 Oct 14 21:07 tcl8.4/ drwxr-xr-x+ 5 jst None0 Oct 14 21:13 tk8.4/ I'm not sure yet if I should keep the .a's within bin or lib and if I should also use the cyg prefix on them... Still some housekeeping to work out... - Is wish working for you, last time I tried, it started up but was not response to any input Yes it does... After sending the email last night, I added Mpexpr 1.0... and I tried mpksc (Tk-based multi-precision calculator) and it works fine. Cheers, Sebastien
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
On Oct 15 09:31, Jean-Sebastien Trottier wrote: On Fri, Oct 15, 2004 at 01:06:10PM +0200, Gerrit P. Haase wrote: Jean-Sebastien schrieb: Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. Yes, +1 from me. There are packages out there depending on Cygwin and non Cygwin TCL/TK versins, would be really great to have this as official version. A quick list would be great... we'll need to figure out if we need both the Cygwin and non-Cygwin versions... The Tcl GUI version of GDB, insight, relies on Tcl/Tk for Cygwin with the native GUI. Not everybody who wants to debug using insight wants to install X. It makes sense to me to have both Tcl/Tk versions available. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: libbonobo, GConf, gnome-vfs (was Re: desktop-file-utils, hicolor-icon-theme, shared-mime-info, startup-notification)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: | Hi Yaakov, | I'm currently building libgnomeprint because I need them to continue | with most of the remaining packages, you mentioned that you already have | them, but I couldn't find them at your two SF sites. I have also an IMO | important patch regarding MMAP for libgnomeprint, can you send me your | libgnomeprint patch? | | And as I saw this problem with mmap last night I thought that I need to | review all other packages if mmap is used somewhere and enable it even | if configure tests for mmap are failing. There was a discussion (last month?) on the cygwin list about the autoconf mmap test; maybe fixing this in the autotools so that the configure test works is the proper solution, instead of patching every package that wants mmap? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBb/k3piWmPGlmQSMRAjItAKDHLWIdypuxKq2SvLgXcDglDjPhYgCgh3yp XXqZRiRuj9Rui70G8DfDRpw= =2j2e -END PGP SIGNATURE-
Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
In the interests of clarity, let's agree on some terminology: a cygwin version -- uses the cygwin1.dll for runtime services (like printf etc) a native windows version uses msvcrt.dll for runtime services an X version uses xlib calls to draw stuff on a display this requires a xserver of some kind And here's the tricky one: a GDI version uses the Windows Graphics Device Interface calls to draw stuff on a display -- WITHOUT using an Xlib emulator. no Xserver needed. -- Using these terms, what we already have is cygwin, GDI ActiveState provides a native, GDI What is being proposed is cygwin, X Contrary to Jean-Sebastien Trottier's assertion, replacing the current cygwin, GDI implementation with the native, GDI ActiveState version will NOT satisfy the current requirements of insight/gdb and other existing cygwin packages. Somehow, a way must be found to have both a cygwin, GDI version of tcl/tk/etc and a cygwin, X version -- where both can coexist on the same machine seamlessly, making it easy to use for the end user and develop against for the developer. This is a hard problem, since it requires proper installation and handling of DLLs, import libs, configure scripts (/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh), and include files. I am overjoyed to see someone interested in tackling the issue. -- Chuck
Re: libgnomeprint problems
Yaakov schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: | I cannot get libgnomeprint to do what I expect it to do, printing to a | file. | | I'm getting an error: | | Module /.../cyggnoome-print-file.dll does not contains an init function | ^^^ | This is verbatim! | | I find nothing but the error message in the sources. | | I can continue to build applications, however if one tries to load | libgnome-print it will not work this way. I uploaded my libgnomeprint22 and libgnomeprintui22 for manual download: It is even weird with your version, the transports are searched in /usr/lib/libgnomeprint/2.8.0/modules but they are installed in /usr/lib/libgnomeprint/2.8.0/modules/transports. Do I need to have an init file entry somewhere so the plugins will be found? And when moving the plugins to ../ I get the same error as with my version. Hmm, maybe I use the wrong application to test it? I'll ask the provider of this application if there are known issues and try to build another application which requires and uses libgnomeprint. Gerrit -- =^..^=
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
Charles Wilson wrote: Using these terms, what we already have is cygwin, GDI ActiveState provides a native, GDI What is being proposed is cygwin, X Note that tcl and itcl do not, themselves, do any display-oriented processing. So GDI vs. X is meaningless for them. They could be released in a separate, cygwin tcl package. It's only because we package tcl + tk + itcl + itk all together in one install that we worry about X tcl and X itcl. AFAICT, expect is the same way; it depends only on tcl, not tk (and thus, not X or GDI). The real bone of contention is tk and itk alone. How can we have a cygwin-X tk and a cygwin-GDI tk on the same machine. -- Chuck
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
On Fri, Oct 15, 2004 at 01:35:16PM -0400, Charles Wilson wrote: In the interests of clarity, let's agree on some terminology: a cygwin version -- uses the cygwin1.dll for runtime services (like printf etc) a native windows version uses msvcrt.dll for runtime services an X version uses xlib calls to draw stuff on a display this requires a xserver of some kind And here's the tricky one: a GDI version uses the Windows Graphics Device Interface calls to draw stuff on a display -- WITHOUT using an Xlib emulator. no Xserver needed. I'm OK with these... thanks for clarifying. -- Using these terms, what we already have is cygwin, GDI ActiveState provides a native, GDI What is being proposed is cygwin, X I would say that what we already have is: Tcl/Tk: half-Windows/half-Cygwin, GDI Expect: Cygwin, no GUI Putting aside the GUI part, let me explain the Tcl/Tk case with an example: [EMAIL PROTECTED] (0) ~/test] ln -s /non-existant bad-link [EMAIL PROTECTED] (0) ~/test] ln -s /home/jst/ good-link -- what we already have: half-Windows/half-Cygwin [EMAIL PROTECTED] (0) ~/test] /usr/bin/tclsh84 % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = intel tcl_platform(os)= Windows NT tcl_platform(osVersion) = 5.1 tcl_platform(platform) = windows tcl_platform(user) = jst tcl_platform(wordSize) = 4 % pwd C:/cygwin/home/jst/test % file type bad-link could not read bad-link: no such file or directory % file type good-link directory % file readlink bad-link could not readlink bad-link: no such file or directory % file readlink good-link could not readlink good-link: invalid argument -- what I'm proposing: Cygwin [EMAIL PROTECTED] (1) ~/test] /home/jst/test/bin/tclsh8.4.exe % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = i686 tcl_platform(os)= CYGWIN_NT-5.1 tcl_platform(osVersion) = 1.5.11(0.116/4/2) tcl_platform(platform) = unix tcl_platform(user) = jst tcl_platform(wordSize) = 4 % pwd /home/jst/test % file type bad-link link % file type good-link link % file readlink bad-link /non-existant % file readlink good-link /home/jst/ -- For comparison: linux [EMAIL PROTECTED] (0) ~/test] tclsh8.4.4.0 % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = i686 tcl_platform(os)= Linux tcl_platform(osVersion) = 2.4.27-rc3-smp-gw tcl_platform(platform) = unix tcl_platform(user) = jst tcl_platform(wordSize) = 4 % pwd /home/jst/test % file type bad-link link % file type good-link link % file readlink bad-link /non-existant % file readlink good-link /home/jst As you can see above, the current Tcl version uses windows APIs to access the filesystem. So, I would consider it as a mixed half-Windows/half-Cygwin version... Thus, I would say the Tk GUI is not the only problem in the current version... Contrary to Jean-Sebastien Trottier's assertion, replacing the current cygwin, GDI implementation with the native, GDI ActiveState version will NOT satisfy the current requirements of insight/gdb and other existing cygwin packages. I never (did|meant to) assert that people should switch to using ActiveState's Tcl. Thanks to the list, the requirements are getting clearer now... Read on... Somehow, a way must be found to have both a cygwin, GDI version of tcl/tk/etc and a cygwin, X version -- where both can coexist on the same machine seamlessly, making it easy to use for the end user and develop against for the developer. This is a hard problem, since it requires proper installation and handling of DLLs, import libs, configure scripts (/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh), and include files. I am overjoyed to see someone interested in tackling the issue. Although (I think) it would be possible to have 2 Tk DLL's (Cygwin, X vs Cygwin, GDI), I like Charles Wilson's idea to try and use W11: On Fri, 15 Oct 2004 14:22:02 -0400 (EDT), Charles Wilson wrote: Rxvt already does this. Do tk/itk make GDI calls that aren't covered by rxvt's W11 library? If so, wouldn't a more worthwhile investment of effort be to extend the W11 library with the implementation of the appropriate X11 calls (by plundering the tk/itk GDI implementation as needed), and then use the W11 library in the same way as rxvt does. So, let's extend the terminology: a Cygwin, W11 version uses xlib calls to draw stuff on a display using the W11 library this works with or without a xserver running With this Cygwin, W11 Tk version, this would cover the insight/gdb requirements without the need for 2 distinct Tk DLL's or majorly hacking the
Re: libgnomeprint problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: | It is even weird with your version, the transports are searched in | /usr/lib/libgnomeprint/2.8.0/modules but they are installed in | /usr/lib/libgnomeprint/2.8.0/modules/transports. | | Do I need to have an init file entry somewhere so the plugins will be | found? | | And when moving the plugins to ../ I get the same error as with my | version. | | Hmm, maybe I use the wrong application to test it? I'll ask the | provider of this application if there are known issues and try to build | another application which requires and uses libgnomeprint. What are you trying to test this with? Maybe it is a problem with your program; I tested libgnomeprint(ui) with the included sample/test programs and with the perl module and that which I tried seemed to work properly. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBcDQ8piWmPGlmQSMRAkCOAJ45d/+dCHKm29jVats1aQvy3TqNQwCg0+it yVMXnRGHsMmcMn0xWeS0xJ4= =XufE -END PGP SIGNATURE-
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
Jean-Sebastien Trottier wrote:
I would say that what we already have is:
Tcl/Tk: half-Windows/half-Cygwin, GDI
Err...ok. If by this you mean
tcl: cygwin (no GUI), but it doesn't do cygwin paths correctly in all
cases
tk: cygwin, X11
As you can see above, the current Tcl version uses windows APIs to
access the filesystem. So, I would consider it as a mixed
half-Windows/half-Cygwin version...
Thus, I would say the Tk GUI is not the only problem in the current
version...
Granted, given your examples.
Contrary to Jean-Sebastien Trottier's assertion, replacing the current
cygwin, GDI implementation with the native, GDI ActiveState version
will NOT satisfy the current requirements of insight/gdb and other
existing cygwin packages.
I never (did|meant to) assert that people should switch to using
ActiveState's Tcl.
Err...what was this, then: Apart from getting Tk to work without X, I
don't see any... If you want Tk for Windows, might as well get it from
ActiveState.
To me, that says: there is no need for non-X tk on cygwin. If you want
non-X, what you really want is windows (GDI). So go get ActiveStates'.
My point is that THAT is not true, given the distinction between
windowsGDI and windowsRUNTIME. If I misunderstood your point, I apologize.
Although (I think) it would be possible to have 2 Tk DLL's (Cygwin, X
vs Cygwin, GDI), I like Charles Wilson's idea to try and use W11:
Not my idea -- it was Igor's. ('tis a good one, tho, if you can make it
work.) However, SteveO packages libW11 together with rxvt; it is not a
separate package. (and his build technique to get it to work
is...unique) So, if you need to add stuff to libW11 and need specific
header files, there may be issues. You'll need to work with SteveO and
perhaps split libW11 to a separate project and package.
On Fri, 15 Oct 2004 14:22:02 -0400 (EDT), Charles Wilson wrote:
Rxvt already does this. Do tk/itk make GDI calls that aren't
covered by rxvt's W11 library? If so, wouldn't a more worthwhile
investment of effort be to extend the W11 library with the
implementation of the appropriate X11 calls (by plundering the
tk/itk GDI implementation as needed), and then use the W11 library
in the same way as rxvt does.
So, let's extend the terminology:
a Cygwin, W11 version
uses xlib calls to draw stuff on a display using the W11 library
this works with or without a xserver running
With this Cygwin, W11 Tk version, this would cover the insight/gdb
requirements without the need for 2 distinct Tk DLL's or majorly hacking
the code.
I will try and have a proof of concept working ASAP...
Cool!
BTW, I interpret cgf's statement
If someone wants to take over gdb + tcl/tk maintainership that's fine,
though. That is gold-star worthy.
to mean that cgf is willing to relinquish maintaining gdb/insight AND
tcl/tk -- but not just tcl/tk alone. It's a package deal; you'd need to
accept gdb maintainership too. Is that a correct interpretation, cgf,
or is there a third choice: you'd give up maintaining tcl/tk but
continue maintaining gdb SO LONG AS the tcl/tk maintainer's changes
don't force you to do more than minimal work to keep gdb up-to-snuff?
--
Chuck
gbs cleanup patch
As we discussed a day or two ago, here is a patch that cleans up the
following aspects of the generic build script (today's CVS version):
- Invokes the shell by /bin/sh -e.
- Removes the many superfluous 's, ;'s, and \'s between commands and
at end of lines.
- Removes all of the $STATUS junk at the end. There's no more need for
this, since with -e the script will fail when any subcommand fails.
- Replaces all instances of 'if [ ! -d xxx ] ; then mkdir -p xxx ; fi'
with just 'mkdir -p xxx'. The second form is equivalent but simpler.
- Adds -r to every invocation of xargs. In every case this is desirable
and will prevent errors in null cases.
With /bin/sh -e, one has to be careful about trapping unwanted non-zero
exit statuses. The only place I found where this was an issue was in
mkpatch(), because diff has an exit status of 1 if it finds differences.
Because of this I added '|| true' after the diff command. One could be
fussier here and check for an exit status of 1 (which is okay) or 2
(which is an error), but I didn't bother. I removed all other instances
of trailing 'true's from the script.
I've tested the revised gbs by building three different packages, and
tested each operation at least once. I had no problems.
Andrew.
--- generic-build-script.orig 2004-10-15 13:48:32.0 -0400
+++ generic-build-script2004-10-15 16:54:26.0 -0400
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/sh -e
#
# Generic package build script
#
@@ -123,25 +123,23 @@
unpack() {
tar xv${opt_decomp}f $1
}
-
mkdirs() {
- (cd ${topdir} \
- rm -fr ${objdir} ${instdir} ${srcinstdir} \
- mkdir -p ${objdir} \
- mkdir -p ${instdir} \
+ (cd ${topdir}
+ rm -fr ${objdir} ${instdir} ${srcinstdir}
+ mkdir -p ${objdir}
+ mkdir -p ${instdir}
mkdir -p ${srcinstdir} )
}
prep() {
- (cd ${topdir} \
- unpack ${src_orig_pkg} \
- cd ${topdir} \
- if [ -f ${src_patch} ] ; then \
-patch -Z -p0 ${src_patch} ;\
- fi \
+ (cd ${topdir}
+ unpack ${src_orig_pkg}
+ if [ -f ${src_patch} ] ; then
+patch -Z -p0 ${src_patch}
+ fi
mkdirs )
}
conf() {
- (cd ${objdir} \
+ (cd ${objdir}
CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
${srcdir}/configure \
--srcdir=${srcdir} --prefix=${prefix} \
@@ -152,115 +150,100 @@
--datadir='${prefix}/share' )
}
reconf() {
- (cd ${topdir} \
- rm -fr ${objdir} \
- mkdir -p ${objdir} \
+ (cd ${topdir}
+ rm -fr ${objdir}
+ mkdir -p ${objdir}
conf )
}
build() {
- (cd ${objdir} \
+ (cd ${objdir}
CFLAGS=${MY_CFLAGS} make )
}
check() {
- (cd ${objdir} \
+ (cd ${objdir}
make ${test_rule} | tee ${checkfile} 21 )
}
clean() {
- (cd ${objdir} \
+ (cd ${objdir}
make clean )
}
install() {
- (cd ${objdir} \
- rm -fr ${instdir}/* \
- make install DESTDIR=${instdir} \
- for f in ${prefix}/share/info/dir ${prefix}/info/dir ; do \
-if [ -f ${instdir}${f} ] ; then \
- rm -f ${instdir}${f} ; \
-fi ;\
- done \
- for d in ${prefix}/share/doc/${BASEPKG} ${prefix}/share/doc/Cygwin ;
do \
-if [ ! -d ${instdir}${d} ] ; then \
- mkdir -p ${instdir}${d} ;\
-fi ;\
- done \
- if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs -r gzip
-q ; \
- fi \
- if [ -d ${instdir}${prefix}/share/man ] ; then \
+ (cd ${objdir}
+ rm -fr ${instdir}/*
+ make install DESTDIR=${instdir}
+ for f in ${prefix}/share/info/dir ${prefix}/info/dir ; do
+if [ -f ${instdir}${f} ] ; then
+ rm -f ${instdir}${f}
+fi
+ done
+ mkdir -p ${instdir}${prefix}/share/doc/${BASEPKG}
${instdir}${prefix}/share/doc/Cygwin
+ if [ -d ${instdir}${prefix}/share/info ] ; then
+find ${instdir}${prefix}/share/info -name *.info | xargs -r gzip
-q
+ fi
+ if [ -d ${instdir}${prefix}/share/man ] ; then
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
-name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
- fi \
- templist= \
- for fp in ${install_docs} ; do \
-for f in ${srcdir}/$fp ; do \
- if [ -f $f ] ; then \
-templist=$templist $f; \
- fi ; \
-done ; \
- done \
- if [ ! x$templist = x ]; then \
+ -name *.7 -o -name *.8 | xargs -r gzip -q
+ fi
+ templist=
+ for fp in ${install_docs} ; do
+for f in ${srcdir}/$fp ; do
+ if [ -f $f ] ; then
+templist=$templist $f
+ fi
+done
+ done
+ if [ ! x$templist = x ]; then
/usr/bin/install -m 644 $templist \
- ${instdir}${prefix}/share/doc/${BASEPKG} ; \
- fi \
- if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
+ ${instdir}${prefix}/share/doc/${BASEPKG}
+ fi
+ if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then
/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README \
- ${instdir}${prefix}/share/doc/Cygwin/${BASEPKG}.README ; \
- elif [ -f ${srcdir}/CYGWIN-PATCHES/README ] ; then \
+
Re: gbs cleanup patch
[EMAIL PROTECTED] wrote: As we discussed a day or two ago, here is a patch that cleans up the following aspects of the generic build script (today's CVS version): - Replaces all instances of 'if [ ! -d xxx ] ; then mkdir -p xxx ; fi' with just 'mkdir -p xxx'. The second form is equivalent but simpler. As long as everyone knows that mkdir -p xxx suppresses errors when xxx already exists, in addition to creating all intervening dirs in the dirpath xxx. (mkdir xxx will exit-with-error if xxx exists) Is this behavior true on all platforms? (I know gbs doesn't directly support cross-compiling, but it actually doesn't require too much modification to do so, at present). - Adds -r to every invocation of xargs. In every case this is desirable and will prevent errors in null cases. Do you mean --no-run-if-empty ? I can't find any documentation of a -r flag to xargs... P.S. Thanks for doing this. Your effort is appreciated. -- Chuck
Re: gbs cleanup patch
On Fri, 15 Oct 2004, Schulman.Andrew wrote:
As we discussed a day or two ago, here is a patch that cleans up the
following aspects of the generic build script (today's CVS version):
Great, thanks, Andrew. Would you mind attaching the patch next time,
though, as mailers screw up spacing and line wrapping... Also, it's
missing a ChangeLog (what you wrote below doesn't quite qualify, although
it could be massaged into one). Some more comments below.
- Invokes the shell by /bin/sh -e.
Great. Have you tested whether the -e flag gets propagated inside the
functions?
- Removes the many superfluous 's, ;'s, and \'s between commands and
at end of lines.
Umm, actually that does change the semantics of the calls slightly (though
perhaps for the better). In particular, code like
if [ -f ${src_patch} ] ; then
patch -Z -p0 ${src_patch}
fi
will, I believe, now fail if the 'patch' command fails, and it wouldn't
have before. Just something to note. Have you tested that the script
works properly in these cases?
- Removes all of the $STATUS junk at the end. There's no more need for
this, since with -e the script will fail when any subcommand fails.
Ok, this is fine.
- Replaces all instances of 'if [ ! -d xxx ] ; then mkdir -p xxx ; fi'
with just 'mkdir -p xxx'. The second form is equivalent but simpler.
Ah, I didn't realize that '-p' also means no error if existing. Good
catch! :-)
- Adds -r to every invocation of xargs. In every case this is desirable
and will prevent errors in null cases.
Yup, this is something I was thinking of doing for a while. Thanks.
Later we should also probably change all find | xargs combos to find
-print0 | xargs -0.
With /bin/sh -e, one has to be careful about trapping unwanted non-zero
exit statuses. The only place I found where this was an issue was in
mkpatch(), because diff has an exit status of 1 if it finds differences.
Because of this I added '|| true' after the diff command. One could be
fussier here and check for an exit status of 1 (which is okay) or 2
(which is an error), but I didn't bother. I removed all other instances
of trailing 'true's from the script.
Hmm, you should've really added '|| true' everywhere there was a '; \' in
the original code to make this patch a simple transformation. In
particular, the find | xargs combo sometimes returned false for no
reason, so we used to ignore its exit status (was it the lack of -r?).
Ditto for install -- neither the man nor the info page say anything
about the exit status, and I can't look at the code right now. I don't
mean to nitpick, but whenever you chose to omit '|| true', you could have
probably added a comment saying why the original code was wrong. Would
you mind doing that?
A comment about the exit status 1 vs. 2 for diff would also be helpful in
the source, in case we decide to do this in the future...
I've tested the revised gbs by building three different packages, and
tested each operation at least once. I had no problems.
I assume all of them succeeded... Did you test for failures too (i.e.,
that the script correctly stops if a command fails, etc, etc)?
A few other minor items:
- there were some space changes (blank lines deleted) that shouldn't have
been (the blank line after unpack() is a particular one I'm thinking
of)
- redirections from xargs were removed (perhaps most stderr messages were
removed by the -r flag, but maybe not)
- you changed the cd $dir find . to find $dir in some places, which
I'd be more comfortable changing as a separate step, if at all
- in list(), you changed the files that are found (i.e., .* would have
been ignored before, and won't be now), and added sort. Frankly, I'd
prefer not to include extra improvements like that in a patch this
large. I'll be happy to commit them separately later.
- in the main arg processing loop, you've combined cases. While it makes
the code shorter somewhat, I don't see it as a readability improvement,
and don't think that this patch should cover it -- a separate patch
would be better.
Thanks again for the effort you've invested in this, and for putting up
with my nitpicking.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: gbs cleanup patch
On Fri, 15 Oct 2004, Charles Wilson wrote: Schulman.Andrew wrote: As we discussed a day or two ago, here is a patch that cleans up the following aspects of the generic build script (today's CVS version): - Replaces all instances of 'if [ ! -d xxx ] ; then mkdir -p xxx ; fi' with just 'mkdir -p xxx'. The second form is equivalent but simpler. As long as everyone knows that mkdir -p xxx suppresses errors when xxx already exists, in addition to creating all intervening dirs in the dirpath xxx. (mkdir xxx will exit-with-error if xxx exists) Is this behavior true on all platforms? (I know gbs doesn't directly support cross-compiling, but it actually doesn't require too much modification to do so, at present). Well, it's true for the 'mkdir' from the GNU fileutils/coreutils -- it sez so right there on the man page: $ man -p 'col -bx' mkdir | grep -C1 -w -- -p -p, --parents no error if existing, make parent directories as needed FWIW, the AIX 5.1 manpage says: The mkdir command ignores any Directory parameter that names an existing directory. No error is issued. (yeah, it's verbose, all right)... The ATT mkdir also seems to concur: -p, --parents [snip] Do not consider an argument directory that already exists to be an error. In fact, -p seems to be a POSIX option: http://icewalkers.com/Linux/ManPages/mkdir-1.html -p,--parents [snip] Ignore arguments corresponding to existing directories. (Thus, if a directory /a exists, then `mkdir /a' is an error, but `mkdir -p /a' is not.) http://opengroup.org/onlinepubs/009695399/utilities/mkdir.html: -p [snip] Each dir operand that names an existing directory shall be ignored without error. Don't know if the non-POSIX platforms are as lenient, though. Again, a comment in the code, perhaps? - Adds -r to every invocation of xargs. In every case this is desirable and will prevent errors in null cases. Do you mean --no-run-if-empty ? I can't find any documentation of a -r flag to xargs... $ man -p 'col -bx' xargs | grep -C1 -w -- -r --no-run-if-empty, -r If the standard input does not contain any nonblanks, do not run P.S. Thanks for doing this. Your effort is appreciated. Ditto. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: gbs cleanup patch
Igor Pechtchanski wrote: - you changed the cd $dir find . to find $dir in some places, which I'd be more comfortable changing as a separate step, if at all Oooh, I missed that one. cd $dir find . --- bar.c baz.h find $dir --- $dir/bar.c $dir/baz.h Not good unless the results are then filtered to remove the path component, or you're sure that the extra path info doesn't affect behavior. -- Chuck
Please upload: docbook-xsl-1.66.1-2
Hi. Please upload new docbook-xsl-1.66.1-2 files: http://telka.sk/cygwin/docbook-xsl/docbook-xsl-1.66.1-2-src.tar.bz2 http://telka.sk/cygwin/docbook-xsl/docbook-xsl-1.66.1-2.tar.bz2 and remove old 1.65.1-1 files. Thanks. -- +---+ | Marcel Telka e-mail: [EMAIL PROTECTED] | |homepage: http://telka.sk/ | |jabber: [EMAIL PROTECTED] | +---+
