RE: [ITP] run.exe was Re: Running ssh in background[solution/patch]
Alexander Gottwald wrote on Wednesday, October 26, 2005 7:00 PM: On Wed, 2005-10-26 at 18:49 +0200, Alexander Gottwald wrote: run.exe is often used from Windows shortcuts to start programs like XWin. Even the X-start-menu-icons uses it this way, A shortcut will not work. To clarify this: X-start-menu-icons won't be a showstopper since it can be easily adjusted. I'm more concerned about the shortcuts on user X's desktop like those on mine: [snip] Why don't drop it into /bin as well as in /usr/X11R6/bin ? Modern X11 distributions will eliminate the X11RX directory anyway and so might do the Cygwin version in some time. - Jörg
xorg upload ready (but need space)
Does anyone have website or ftp space available to upload the xorg packages too temporarily until they are moved to sourceware ? They are around 70Mb of files. Alan.
g-b-s and bin dir
I'm attempting to create my first Cygwin package, and decided to use the
generic-build-script method.
The package is ctags (http://ctags.sourceforge.net/), which builds just
fine out of the box. With a bit of scripting [*] I have the build
process automated. Problem is, the generated binary tarball has no
binaries in it. It only has usr/share/doc/*. I don't see the binaries
in ctags-$VER/.inst/usr/bin, either.
I don't know if this is because of some nonstandardness in the ctags
autoconf setup, or if g-b-s is not passing the right options to the
configure script.
Exuberant Ctags uses autoconf only; no automake. The install target in
the top-level Makefile puts the binaries in $(bindir), which is set from
the corresponding autoconf variable. As g-b-s runs configure, ${bindir)
ends up being /usr/bin, so when the g-b-s inst step runs, the binaries
go to /usr/bin, not to $UNPACKED_TARBALL/.inst/usr/bin.
Who is at fault here, and how do I fix it?
[*] I've attached the build script I'm using. It's a driver for g-b-s,
to handle things that I think g-b-s should handle already. Whoever is
maintaining g-b-s these days can feel free to rob whatever code they
want from this.
With this interface, you just say ./build ctags 5.5.4 1 to create
ctags-5.5.4-1[-src].tar.bz2. It requires that you have a README file in
the current directory, which is based on the generic README file from
the cygwin.com docs; the build script does variable replacement in it
for package name, version number, and release number. I've attached my
original README file so you can see what the build script has to work
with. The build script also requires that the original source tarball
be in the current directory.
This mechanism works best if you have a directory dedicated to a given
package. I use ~/src/ctags, for instance. The build script, the
README, and any tarballs are here.
#!/bin/sh
if [ $# -lt 3 ]
then
echo usage: $0 pkg version release
echo
exit 1
fi
PKG=$1
VER=$2
REL=$3
ID1=$PKG-$VER
ID2=$PKG-$VER-$REL
TARBALL=$ID1.tar.gz
SRCID=$ID2-src.tar.bz2
BUILD=./$ID2.sh
if [ ! -e $TARBALL ]
then
echo Could not find tarball: $TARBALL
echo
exit 1
fi
rm -rf $ID1
tar xvzf $TARBALL
mkdir $ID1/CYGWIN-PATCHES
sed -e s/PKG/$PKG/g -e s/VER/$VER/g -e s/REL/$REL/g README
$ID1/CYGWIN-PATCHES/$PKG.README
$BUILD mkdirs $BUILD spkg
( cp $SRCID /tmp cd /tmp tar xjf $SRCID $BUILD all )
mv /tmp/$ID2.tar.bz2 . rm -f /tmp/$PKG-*
Exuberant Ctags
--
Exuberant Ctags is an indexing and cross-reference tool for many
programming languages. It is typically used in conjunction with a
programmer's text editor, such as Vim or Emacs.
Runtime requirements:
Should work with any version of Cygwin.
Build requirements:
A bare Cygwin installation plus gcc should suffice.
Canonical homepage:
http://ctags.sourceforge.net/
Canonical download:
http://prdownloads.sourceforge.net/ctags/PKG-VER.tar.gz
License:
GPL
Language:
Written in C. Works with source code for any of 33 different
programming languages, as of this writing.
Build instructions:
unpack PKG-VER-REL-src.tar.bz2
if you use setup to install this src package, it will be
unpacked under /usr/src automatically
cd /usr/src
./PKG-VER-REL.sh all
This will create:
/usr/src/PKG-VER-REL.tar.bz2
/usr/src/PKG-VER-REL-src.tar.bz2
Or use './PKG-VER-REL.sh prep' to get a patched source directory
To find out the files included in the binary distribution, you can
use cygcheck -l PKG, or browse the listing for the appropriate version
at http://cygwin.com/packages/.
--
Port Notes:
Official distribution builds out of the box. No changes required.
For more information about this package, see the upstream documentation in
/usr/share/doc/PKG-VER.
Cygwin port maintained by Warren Young warren at etr dash usa dot com
Please address all questions to the Cygwin mailing list at cygwin@cygwin.com
Re: xorg upload ready (but need space)
On Oct 27 10:51, Alan Hourihane wrote: Does anyone have website or ftp space available to upload the xorg packages too temporarily until they are moved to sourceware ? They are around 70Mb of files. You have an account on sourceware and upload rights. Just scp your stuff to your home dir or /tmp (there's more than enough space on both disks) and when that went fine, move it over to the appropriate spot in the release directory (below /sourceware/ftp/anonftp/pub/cygwin/release/X11). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: g-b-s and bin dir
Warren Young wrote:
the corresponding autoconf variable. As g-b-s runs configure, ${bindir)
ends up being /usr/bin, so when the g-b-s inst step runs, the binaries
go to /usr/bin, not to $UNPACKED_TARBALL/.inst/usr/bin.
Most standard autoconf/automake-generated configure scripts support the
use of DESTDIR for the make install step. This lets you use the
desired --prefix=/usr but divert the destination at the final install
step by doing make install DESTDIR=/some/path, causing the tree to be
installed to /some/path rather than /usr. But note that the package is
otherwise still configured to be installed in /usr, so for example if
there are any hard coded paths they will reference /usr and not
/some/path.
I think this is what the GBS uses to redirect the install to the .inst
dir. If the ctags configure script does not have this capability then
you will have to do one of:
1. Manually recreate the install tree by copying stuff out of /usr and
into .inst/ for inclusion in the binary package.
2. Patch configure.ac/.in to honor $DESTDIR for the install target and
regenerate.
3. Configure with --prefix=/some/temp/packaging/path/.inst and hope that
this prefix is not hard coded anywhere in any files.
#3 is risky but probably okay for very simple packages. #1 is easy but
clumsy. #2 requires that you maintain local patches to configure.ac,
and re-run autoconf to rebuild generated files.
This last point touches on another issue: Do you include patches to
generated files in the source package? One school of thought says that
you do since it's simpler and the end user that builds the package
doesn't have to worry about having the correct version of
autoconf/automake/libtool installed. However this can result in huge
(multiple-megabyte) patches since the generated files can often be quite
large, and it really obscures the actual patches (if any) from the noise
of the diffs in generated files.
The other school of thought is that you should only include patches to
the configure.ac (and other primary source files), and modify the build
script to first run autoreconf to regenerate everything before
configuring. This makes for nice, small, easy to inspect patches, but
the user building the package from source must have the proper developer
tools installed and must know to either run autoreconf or use your build
script.
Brian
Please upload: xorg-*-6.8.99.901
A new release of the xorg-* binaries are available for upload. This coincides with X.Org 6.9/7.0 RC1 (release candidate 1) I'm not sure how or whether packages are identified as test packages anymore through setup, but they should be marked so if possible. Files are at :- http://www.mathematik.uni-kl.de/~wienand/xorg Thanks to Oliver Wienand for the temporary upload space. Alan.
Re: Please upload: xorg-*-6.8.99.901
On Oct 27 12:56, Alan Hourihane wrote: A new release of the xorg-* binaries are available for upload. This coincides with X.Org 6.9/7.0 RC1 (release candidate 1) I'm not sure how or whether packages are identified as test packages anymore through setup, but they should be marked so if possible. Files are at :- http://www.mathematik.uni-kl.de/~wienand/xorg http://cygwin.com/setup.html http://cygwin.com/ml/cygwin-apps/2005-10/msg00264.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: xorg upload ready (but need space)
On Thu, 2005-10-27 at 13:49 +0200, Corinna Vinschen wrote: On Oct 27 10:51, Alan Hourihane wrote: Does anyone have website or ftp space available to upload the xorg packages too temporarily until they are moved to sourceware ? They are around 70Mb of files. You have an account on sourceware and upload rights. Just scp your stuff to your home dir or /tmp (there's more than enough space on both disks) and when that went fine, move it over to the appropriate spot in the release directory (below /sourceware/ftp/anonftp/pub/cygwin/release/X11). I keep forgetting about that. I'll remember next time. Thanks Corinna. Alan.
Re: Please upload: xorg-*-6.8.99.901
On Thu, 2005-10-27 at 14:01 +0200, Corinna Vinschen wrote: On Oct 27 12:56, Alan Hourihane wrote: A new release of the xorg-* binaries are available for upload. This coincides with X.Org 6.9/7.0 RC1 (release candidate 1) I'm not sure how or whether packages are identified as test packages anymore through setup, but they should be marked so if possible. Files are at :- http://www.mathematik.uni-kl.de/~wienand/xorg http://cygwin.com/setup.html http://cygwin.com/ml/cygwin-apps/2005-10/msg00264.html Yep, uploading myself to sourceware now. They'll be in-place in the next hour. Alan.
Re: g-b-s and bin dir
Brian Dessent wrote: Most standard autoconf/automake-generated configure scripts support the use of DESTDIR for the make install step. Ah. Then I think I can fix this by making ctags' Makefile.in honor DESTDIR. Tiny patch with low impact, so likely to be accepted upstream.
[ITP] gnubg: A backgammon player and analysis tool
Hi I would like to contribute and maintain the gnubg package: * http://www.gnu.org/software/gnubg/gnubg.html (Homepage) * ftp://alpha.gnu.org/gnu/gnubg/ (Download location) Ciao Volker -- Here is the setup.hint file: sdesc: A backgammon player and analysis tool ldesc: GNU Backgammon (gnubg) plays and analyses backgammon games and matches. It is currently a work-in-progress. So far it is able to play both independent games and tournament matches, evaluate and roll out positions, tune its own evaluation functions using either TD or supervised training, maintain databases of positions for training and other purposes, and more. It is driven by a command-line interface, and displays an ASCII rendition of a board on text-only terminals, but also allows the user to play games and manipulate positions with a GTK+ board window where available. It is extensible on platforms which support Guile and/or Python. It currently plays at about the level of a championship flight tournament player (depending on its parameters and its luck in recent games, it rates at around 2000 on FIBS, the First Internet Backgammon Server - at its best, it is in the top 5 of over 6000 rated players there) and is gradually improving; it should be somewhat stronger than this when released. GNU Backgammon can be played at numerous other online backgammon servers. category: Games requires: cygwin gmp gtk2-x11-runtime libart_lgpl libesound0 libfreetype26 libgdbm4 libguile12 libintl3 libpng12 libreadline6 libxml2 python xorg-x11-bin-dlls cut here #!/bin/bash mkdir gnubg cd gnubg wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/gnubg/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/gnubg/gnubg-0.14.3-1-src.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/gnubg/gnubg-0.14.3-1.tar.bz2 cut here
xorg-x11-fcyr/xorg-x11-fnts packaging error
I'm getting email about this: upset: *** warning package xorg-x11-fcyr refers to non-existent external-source: xorg-x11-fnts xorg-x11-fcyr contains an external-source line but, unfortunately, upset will only recognize source packages that are actually included in the distribution. That means that upset will not find xorg-x11-fnts-6.8.1.0-2.tar.bz2 since the xort-x11-fnts setup.hint file only mentions 6.8.1.0-3 and 6.8.99.901-1. I've added a prev: 6.8.1.0-2 to the setup.hint for xorg-x11-fnts, which fixes the problem. However, shouldn't the curr release xorg-x11-fcyr be at 6.8.1.0-3, like xorg-x11-fnts? cgf
Re: xorg-x11-fcyr/xorg-x11-fnts packaging error
On Thu, 27 Oct 2005, Christopher Faylor wrote: However, shouldn't the curr release xorg-x11-fcyr be at 6.8.1.0-3, like xorg-x11-fnts? Actually the xorg-x11 packages are not built from the -src files but from a CVS checkout becuase of the monolitic structure. The correct solution would be one large -src file and several bin packages which must all be updated even if only a small package like xorg-x11-xwin has changed. In fact, the font packages are still on version 6.8.1 while the binaries have been updated to 6.8.2 in the meantime, but the fonts were kept at the older version to save unnecessary downloads. Same for the fnts and fcyr package. fnts has been changed (a small tool for updating the font indices) but fcyr has not, so I did not pull it to the newer version. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: xorg-x11-fcyr/xorg-x11-fnts packaging error
On Thu, 2005-10-27 at 10:25 -0400, Christopher Faylor wrote: I'm getting email about this: upset: *** warning package xorg-x11-fcyr refers to non-existent external-source: xorg-x11-fnts xorg-x11-fcyr contains an external-source line but, unfortunately, upset will only recognize source packages that are actually included in the distribution. That means that upset will not find xorg-x11-fnts-6.8.1.0-2.tar.bz2 since the xort-x11-fnts setup.hint file only mentions 6.8.1.0-3 and 6.8.99.901-1. I've added a prev: 6.8.1.0-2 to the setup.hint for xorg-x11-fnts, which fixes the problem. However, shouldn't the curr release xorg-x11-fcyr be at 6.8.1.0-3, like xorg-x11-fnts? I'm not sure why fnts is bumped at -3 and fcyr at -2 as it's been that way for quite some time. Given that your fix works we can either stick with that, or just copy the fcyr -2 package to -3 and remove the prev: keyword. Which do you prefer Chris ? Alan.
