Re: [ITP] mksh 2.6.3 -- MirBSD Korn shell, improved pdksh implementation
On Fri, 5 May 2006, Jari Aalto wrote: Igor Peshansky [EMAIL PROTECTED] writes: As the pdksh maintainer, I would like to veto having this package in the distro simultaneously with pdksh (since this is a newer version of pretty much the same package). In fact, I've been (slowly) working on preparing a new release of pdksh that includes many of the mirbsd patches. I don't mind obsoleting pdksh in favor of mksh, but we'll need to coordinate this. Jari, you might want to review the pending complaints about pdksh to see if they are fixed in your mksh version. I can send you a list (with links to archives) if you're interested. Yes please send them, Ok, here are the ones I have on my list: http://cygwin.com/ml/cygwin/2004-08/msg00112.html http://cygwin.com/ml/cygwin/2005-06/msg00202.html http://cygwin.com/ml/cygwin/2005-08/msg01382.html http://cygwin.com/ml/cygwin/2006-02/msg00448.html I've been in contact with the mksh maintainer and already provided a patch to implement standard shell startup file: ~/.mkshrc in addition to current use of ~/.profile + ENV That's nice. As Debian and Gentoo includes both pdksh and mksh, I'm not sure what is vetoed here. I'd like not to involve with politics if there is some schisma between these two development camps. I'd rather like to offer oppurtunity for users to select what they prefer. Just to oppose program because similar is already there to do same thing, would in fact veto any other program as well, like: MTAs? Sure, there is already exim4 in Cygwin, why should there were need for more MTAs? I'd be more in favor of porting applications regardless of GNOME vs KDE type of rivarly. Jari, there is no rivalry that I know of, and no politics. The veto was purely for practical reasons -- since pdksh development is dead, AFAICS, except in various branches (e.g., Debian, or BSD), we shouldn't keep it in the distro if we decide to also provide a newer (better?) version, and I wouldn't want to maintain an obsolete package. If there are substantial differences, please list them so that we can make an informed decision on whether to keep both pdksh and mksh. As I understand it, mksh subsumes pdksh. Again, I'm willing to obsolete pdksh in favor of mksh *if* it is indeed a drop-in replacement. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac
Re: [ITP] cygport
Yaakov S writes: I would like to propose my cygport package as a new package building/maintaining method, as well as a new package for the distribution. +1 Ciao Volker
Re: Maintainer searched
Yaakov schrieb: Gerrit P. Haase wrote: Who wants to maintain one or more of my packages, maybe Yaakov wants to take over some of the GTK+ related packages? Then there are some more major packages which really require a maintainer with more time than I have (i.e. GCC, Perl). I'll take everything of yours GNOME-related, namely: atk* glib2* gtk-doc gtk2-x11* intltool libart_lgpl2 libcroco* pango* Wow, fine with me, you are probably the best candidate :-) Are these yours already? gnome-vfs2 libbonobo2 libbonoboui2 libgnome2 libgnomeui2 AFAICS, that leaves: check gcc* indent lcms libexif libfpx libmng libwmf libxml2 libxslt perl I'll consider a few more of the above (no, gcc is definitely NOT among them), but I really won't be offended if someone else wants them. lcms is not mine. However, there was no update since I dropped the package IIRC. And it is quite stable. I'll keep maintaining the following if there is no interest: antiword db*/libdb* check indent enscript exif/libexif expat freeglut jasper libfpx libmng libwmf libxml2 libxslt openjade OpenSP And TLS related: gnutls, libtasn1, opencdk Gerrit -- =^..^=
Re: [ITP] cygport
On 5/4/06, Yaakov S (Cygwin Ports) wrote: Portage itself was already vetoed, as it would mean entirely changing the distro management scheme, and Portage just isn't meant for only building packages. cygport is much simpler, doesn't require changing the distro entirely, and was written with Cygwin in mind by someone (namely, me) with a repository of 1400 Cygwin binary packages. Conceded. Though my opinion doesn't officially mean anything yet (I haven't successfully contributed a package yet, but I am thinking of packaging an AVR toolchain, using cygport... new thread forthcoming), I like this package. Bravo! A suggestion: Perhaps it would be slightly more elegant to put the cygclass files in $prefix/share/cygport and export all of the functions defined in the cygport script itself into tidy .sh files in $prefix/lib/cygport/lib? I'm not strongly advocating these particular paths, but I kinda feel like the *.cygport files are misplaced and that the cygport script itself could be modularized one step farther. Cheers, Jason
Re: [ITP] cygport
Reini Urban wrote:
BTW Minor nitpick:
SRC_URI=http://prdownloads.sourceforge.net/${PN}/${P}.tar.bz2?download;
will not work.
Of course not, but that wouldn't work with Portage either. Remember,
also, that the source package name is determined from SRC_URI, so even
if the download worked, cygport wouldn't know the correct filename
either (although if necessary I could work around that).
Forcing a sf.net mirror as you did in your samples is not good style,
but okay for a singular maintainer.
Support for mirror URIs as Portage does (i.e.
mirror://sourceforge/${PN}/${P}.tar.bz2), which is the way I *want* to
handle this, is already in TODO, and I've been considering different
ways to handle it. Probably sometime during 0.2 or 0.3 cycle.
Yaakov
Re: Maintainer searched
Gerrit P. Haase wrote: Wow, fine with me, you are probably the best candidate :-) I already have updated packages ready for GNOME 2.14. Are these yours already? gnome-vfs2 libbonobo2 libbonoboui2 libgnome2 libgnomeui2 Yes, I took those for GNOME 2.10. lcms is not mine. However, there was no update since I dropped the package IIRC. And it is quite stable. True. I'll keep maintaining the following if there is no interest: antiword db*/libdb* check indent enscript exif/libexif expat freeglut jasper libfpx libmng libwmf libxml2 libxslt openjade OpenSP And TLS related: gnutls, libtasn1, opencdk I've built already check, libxml2, and libxslt for my own purposes, so I could take those too if you want. Yaakov
Re: XFCE Window Maximized / All parts integrated?
Yaakov S (Cygwin Ports) wrote: Matthew C Snyder wrote: Argh. Sorry, wrong list. Yaakov
Re: [ITP] cygport
On 5/5/06, Yaakov S (Cygwin Ports) wrote: I'm not sure why /usr/share/cygport is less misplaced than /usr/lib/cygport/lib, except that the former sounds more accessible than the latter. Either way, cygport still needs to be documented, then it shouldn't really matter where the components are actually installed. Conceded. I'll confess that my opinion was partly inspired by the Portage code layout, and partly by an attempt to respect the FHS (something seems a little off about having files expected to be hand-edited by a user in a lib-path--a share-path or etc-path seemed better to me). Regarding further modularization, remember that for every script executed, you have another bash process running or you need to inherit a cygclass; therefore, the most common tasks are in cygport itself, to avoid excessive inherit commands or runtime overhead. Apologies, I forgot to say that I meant for those files to be *sourced*. That way, it would work exactly the same way as it is now (no new bash processes on invocation), but the code would be more neatly organized. And there are certain things that _cannot_ be modularized, e.g. insinto, which exports a variable needed by doins, can't be separate because AFAIK you can only export variables to child processes and not to the parent/sibling processes. Ah, but the source is mightier than the fork (as per above)! ;-) In the end, nothing is finalized, and cygport should be flexible enough to move certain things into or out of /usr/lib/cygport/bin without changing API. Ergo the friendly, minor suggestions (I'm writing cygport scripts this weekend if I have time). Yaakov Jason
ITP: checkx-0.1.0-1
checkX is a little utility I wrote that tests to see if (a) the X11 client DLLs are installed on the machine, and (b) the Xserver on $DISPLAY (or -d x.x.x.x:x) is running and usable. It does not link against the Xll libraries itself, but attempts to dlopen it, using a fuzzy name/path search. Both the search path and the target name are explicitly over-ridable via commandline arguments. In its default mode, checkX returns a 0 status if X is present, 1 otherwise, and generates no output. It is intended for use in scripts, which need to intelligently decide whether to launch an X-based application or a non-X (native MS Gui? console?) one. The source code isn't pretty, but it works pretty well; I've been trying to break it for a while now. First published here: http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00148.html but I decided to make it into its own package rather than tack it on to rxvt-unicode-X or cygutils. It's even autotooled...not that it can actually be BUILT on any platform except cygwin. g checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... = checkX determines if X is installed and Xserver is running returns 0 if yes, nonzero otherwise Options: -h|--help: prints this help message -d|--display STR : use STR instead of $DISPLAY -l|--location: print location of Xlib DLL on stdout -a|--appendpath STR : append STR to value of $PATH (cumulative) -p|--prependpath STR : prepend STR to value of $PATH (cumulative) -r|--replacepath STR : use STR instead of $PATH when searching -x|--xlibname STR: use exactly STR instd of fuzzy cygX11-*.dll -t|--timeout FLT : allow FLT seconds to connect with Xserver defaults to 0.5, use 0.0 for Xlib's (safe, 12s) timeout --notty : disable stderr messages --debug : turn on debugging messages --no-silent : allow error, warning, and info messages Note that -a defaults to '/usr/bin:/usr/X11R6/bin'. To eliminate the default, use '-a ' = setup.hint: --- 8 category: Utils requires: cygwin sdesc: checks to see if Xserver is usable ldesc: A quick-n-dirty utility to check if X is installed on the machine and if the Xserver is running. checkX is silent by default (unless configured with --disable-silent), and all it does is return a status (0 or 1). There are no popups or stderr messages. checkX attempts to dynamically load the X11 DLL in order to contact the Xserver; therefore this package does not explicitly depend on the X DLLs. --- 8 http://cygwin.cwilson.fastmail.fm/ITP/checkx.hint http://cygwin.cwilson.fastmail.fm/ITP/checkx-0.1.0-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/checkx-0.1.0-1.tar.bz2 -- Chuck P.S. For some reason I can only intermittently ssh to my cygutils.fruitbat.org site -- and the last time I tried to do so, it apparently took down the httpd server, too. I'm pretty sure that's not an scp + cygwin problem. g So, this ITP is hosted at an alternate location.
[Adopt] rxvt
rxvt has long been on Corinna's list of orphaned packages (last known
version here:)
http://www.cygwin.com/ml/cygwin-apps/2006-02/msg00139.html
The current version, rxvt-2.7.10-6, is over a year old
http://www.cygwin.com/ml/cygwin-announce/2005-04/msg00011.html
Now, upstream development of rxvt has completely halted as well, so in
itself that's not a big deal. However, there are a few changes *I*
wanted in rxvt, and ... nobody responsive to send them to. So...unless
anybody complains, I'll go ahead and upload this over the weekend. I've
actually been using (something very similar to) this version for nine or
ten months now, so it's pretty solid IMO.
ITP-ish stuff:
-
http://cygwin.cwilson.fastmail.fm/ITP/rxvt-20050409-1-src.tar.bz2
http://cygwin.cwilson.fastmail.fm/ITP/rxvt-20050409-1.tar.bz2
http://cygwin.cwilson.fastmail.fm/ITP/rxvt.hint
-- 8 -
category: Shells
sdesc: VT102 terminal emulator for both X and Windows
ldesc: rxvt is a colour vt102 terminal emulator intended as
an xterm replacement for users who do not require features
such as Tektronix 4014 emulation and toolkit-style configurability.
As a result, rxvt uses much less memory. And besides, it's
prettier than xterm and much more usable than cmd.exe on MSWin.
There are, however, known issues with native windows stdio; on
windows/cygwin, rxvt is best used when you are using mostly
cygwin tools.
requires: cygwin bash
-- 8 -
What's different:
-
Operationally, nothing. Just a routine update, from the user
perspective. It does have a few new features:
* it can hide its own console, without requiring run.exe (but there's
no reason your current shortcut, which uses run, needs to change. It'll
be fine).
* better heuristics for the X11 search: it will find cygX11-*.dll
even if /usr/X11R6/bin is not in your $PATH. Soon this won't matter, as
the modular x.org client libs will be in /usr/bin, but it's nice.
* /usr/share/man/man1/rxvt.1.gz is actually usable.
Other stuff
--
Packaging-wise, there are a LOT of changes. It's a fully g-b-s style
build now (no need to edit features.h AFTER configuring, anymore).
Getting into the technical weeds...
Around rxvt-2.7.6 or so, SteveO's win32-native patches were adopted into
the rxvt CVS, kinda. But, his rxvt distribution for cygwin was built by
overlaying a copy of the xpm source code, building a private static
library of it, which was then used to link. But, the -src package
shipped with cygwin didn't indicate that these manipulations occurred:
SteveO just tarred up his working source directory and shipped THAT.
So it was difficult to see, directly, how our source code differed
from their original 2.7.10 code. (Plus, our version was actually
based off of a snapshot taken from CVS *after* the 2.7.10 release, and
then modified from that...)
So, my -src package actually contains the following:
rxvt-20050409.tar.bz2 : a direct CVS pull with that date -D)
rxvt-import-xpm.patch.bz2 : a layover patch that imports the xpm
source code
rxvt-20050409-1.patch : the OTHER cygwin changes needed for a
clean build
rxvt-20050409-1.sh : heavily doctored generic-build-script
I'm using a date-stamp instead of '2.7.10' because, well, OUR 2.7.10
never really was 2.7.10 to begin with. As of 2.7.10-6, it was really
20050409-CVS + local-steveo-patches.
Here are the options I used to configure (somebody was asking about 256
color support earlier). It's enabled -- but the rxvt terminfo entries
do not reflect that (try 'export TERM=xterm-256color' and
'/usr/lib/ncurses/test/ncurses.exe -d'. You'll see the colors, but rxvt
is not xterm so other things will break)
rxvt_cv_struct_utmpx=no \
DLIB=${objdir}/W11/wrap/rxvt_res.o \
CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
${srcdir}/configure \
--srcdir=${srcdir} --prefix=${prefix} \
--exec-prefix='${prefix}' --sysconfdir=${sysconfdir} \
--libdir='${prefix}/lib' --includedir='${prefix}/include' \
--mandir='${prefix}/share/man' --infodir='${prefix}/share/info' \
--libexecdir='${sbindir}' --localstatedir=${localstatedir} \
--datadir='${prefix}/share' \
--disable-shared --enable-xpm-background \
--with-xpm-includes=${objdir}/W11/X11 \
--with-xpm-library=${objdir}/W11/lib \
--x-libraries=${objdir}/W11/lib \
--enable-utmp --enable-wtmp --enable-lastlog --enable-menubar \
--enable-rxvt-scroll --enable-next-scroll --enable-xterm-scroll \
--enable-frills --enable-linespace --enable-mousewheel \
--enable-keepscrolling \
--enable-old-selection --enable-transparency --enable-256-color \
--enable-languages --with-encoding=noenc )
--
Chuck
Re: ITP: checkx-0.1.0-1
checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... You have mine. If I can ever get enough time to get emacs to build reliably, it would be useful for making emacs vs. emacs-nox easier to package. -- Eric Blake
