Re: generic-build-script extension to update version numbers in README
Igor Pechtchanski wrote:
At the time I've thought long and hard about integrating more features.
The original argument for including them was to allow the maintainers to
release packages with minor modifications of the g-b-s (mostly to set
parameters). And this worked for most *new* packages (though I agree that
the maintainer-only features are getting clunky). It probably won't work
for any package that has a more sophisticated build procedure. Perhaps
it's time to rethink this.
At times I wish that I had originally stored all of my build scripts in
a cvs repository. If I imported the "official" generic-build-script as
a "vendor branch", then I could more easily do a 'cvs merge -j
vendor-release-27' within a workspace on the 'gettext' branch...
That would have made this a lot easier. But now, it's just too much
work to set up for all 30+ packages, so I keep on keeping on,
hand-merging with every new release...
Could these added features be simply refactored into ancillary scripts
instead of integrated into the main gbs?
E.g.
./foo.sh externaltool /path/to/update-readme
where the gbs's externaltool function would simply source the
update-readme fragment -- and the update-readme fragment would inherit
all of the variable settings from the top of the gbs. I'd figure that
'update-readme' would NOT be shipped with cygwin packages, but could be
downloaded from the sourceware cvs by a maintainer who wanted to use it
on her machine when maintaining her package foo.
FWIW, I like this idea. A lot. Maybe we should have only *one* ancillary
script that contains all maintainer-only features. That way,
./foo.sh maintainer-action update-readme
would do what you said (say, use the 'update-readme' function from a local
'maintainer.sh', or pass the 'update-readme' option to some function that
would properly dispatch it, or even fetch the proper 'maintainer.sh'
version from CVS on sourceware.org and eval it). That way, the package
maintainers would have less to worry about, since the core g-b-s would not
change all that often.
I too thought of a "regular" gbs and a single "maintainer-extras"
script. However, I suggested multiple fragments because it's
open-ended. We just keep adding more fragments to the master
repository, and it's up to the end-user (e.g. package maintainers) which
ones they actually download and use. Or they can write their own.
Maybe the "regular" gbs's 'maintainer-action' function can honor an
environment variable, like CVSROOT: GBS_PATH=.:/usr/src/gbs-fragments or
something. That way, gbs can look in the specified locations for the
proper fragments ('.' first for package-specific versions).
Sure, it's insecure as all heck, but if you're maintaining cygwin
packages on a compromised machine...we've ALL got a problem!
Yes, but there's the question of the extent to which it has diverged. If
all you do is change parameters, it ought to be easy. It would help if
you outlined the difficulties you had (feel free to email me privately,
though I think a public summary might produce more patches).
See attached patch, which shows the changes from gbs-1.38 and
gettext-0.14.5-1. These changes were necessary to support:
1) four separate binary packages
2) two variant builds: "normal" and "relocatable". I wanted both
variants to be buildable with only minor changes to the buildscript
(it's simply a 3 line change to the buildscript now)
3) The upstream maintainer is VERY specific about which files should go
into the "runtime" package (cygwin's libintl3 + libgettextpo0 + gettext
packages) and which files should go into the developer's package
(cygwin's gettext-devel). It's not a simple regex, but specific file
listings.
4) The test suite CAN be run all at once -- but the rpath tests take
over an hour. I split them up into three different sets.
5) My modifications require bootstrapping. To ease maintainance and
avoid giant patches, I ship only the pre-autotool patches and run the
bootstrap as part of the prep() phase.
6) I *also* run the boostrap in the -orig directory as part of the
mkpatch() step. Thus, I ship two patches: the pre-autotool one, and the
post-autotool one (which SHOULD just be the contents of CYGWIN-PATCHES
if I've done it right).
7) Since I've got two patches, I had to include them both in the
checksig and spkg functions, along with their signatures. (No, I don't
actually sign anything, but it's all set up if someone more security
obsessed were to take over my package)
BTW, the cvs buildscript is even worse: I have to keep track of which
tests in the testsuite are known-to-fail, for two different test
harnesses (local and pseudo-remote) -- because a failed test completely
stops the suite. No '-k' option! Heck, even my simplest package, zlib,
doesn't use the gbs directly; zlib is not autotool enabled so...
Heh, the argument for including the logs (which I, after having installed
some package source t
Re: Security advisory: gtk2-x11
Yaakov S (Cygwin Ports) wrote: Gerrit P. Haase wrote: Will integrate this asap. Thanks. Ok. Just prepare what is needed next and notify seperately when you're uploading. I have GConf2, libbonobo2, gnome-vfs2, libgnome2, libbonoboui2, and libgnomeui2 all up to 2.10.1, and I have a renamed libart_lgpl2 in order to make space for gnome-libs-1.4.2. You are able to upload yourself? No. Ok. Send me your links. Gerrit -- =^..^=
Re: Security advisory: gtk2-x11
Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: Ok. Just prepare what is needed next and notify seperately when you're uploading. Forgot to mention, I also have (glitz and) cairo, which is required for pango-1.10 and gtk+-2.8, if you think you're ready to make that move. Hmm, this is the first time I hear about glitz and cairo. Is it used instead of X11? Gerrit -- =^..^=
Re: generic-build-script extension to update version numbers in README
On Fri, 18 Nov 2005, Charles Wilson wrote: > Christian Franke wrote: > > the build-script of the smartmontools package creates the > > "Cygwin/package-*.README" file from > > "srcdir/CYGWIN-PATCHES/package.README.in" by replacing VER/REL with the > > current version/release numbers. > > > > This might be useful for other packages to avoid extra editing of > > README on each minor release. > > Christian, please don't take offense; the following semi-rant is not > aimed at you, but is a product of my frustration with gbs. It's become > an issue for me in that the difficulty of trying to track changes in the > gbs is a significant portion of my effort when releasing a new version > of an existing package. > > I'd like to make a request: gbs is getting out of control with this > feature and that feature added. Some of these tasks are NEVER going to > be performed by anyone other than the primary maintainer: has anyone > actually used 'foo.sh list' or 'foo.sh depends'? At the time I've thought long and hard about integrating more features. The original argument for including them was to allow the maintainers to release packages with minor modifications of the g-b-s (mostly to set parameters). And this worked for most *new* packages (though I agree that the maintainer-only features are getting clunky). It probably won't work for any package that has a more sophisticated build procedure. Perhaps it's time to rethink this. > It's a nice feature, but how useful is it, really? Ditto this > maintainer-only 'muck with the README' script. BTW, the "muck with the README" idea isn't new -- I still have a link to an unapplied patch from last February that does essentially that (and more). That patch was dubbed too complex, and the original submitter never followed up. > Could these added features be simply refactored into ancillary scripts > instead of integrated into the main gbs? > E.g. > > ./foo.sh externaltool /path/to/update-readme > > where the gbs's externaltool function would simply source the > update-readme fragment -- and the update-readme fragment would inherit > all of the variable settings from the top of the gbs. I'd figure that > 'update-readme' would NOT be shipped with cygwin packages, but could be > downloaded from the sourceware cvs by a maintainer who wanted to use it > on her machine when maintaining her package foo. FWIW, I like this idea. A lot. Maybe we should have only *one* ancillary script that contains all maintainer-only features. That way, ./foo.sh maintainer-action update-readme would do what you said (say, use the 'update-readme' function from a local 'maintainer.sh', or pass the 'update-readme' option to some function that would properly dispatch it, or even fetch the proper 'maintainer.sh' version from CVS on sourceware.org and eval it). That way, the package maintainers would have less to worry about, since the core g-b-s would not change all that often. > Thus, I don't see exploding out a bunch of 'build.frag' and 'prep.frag' > and 'mkpatch.frag' fragments; the current intrinsic functions in the gbs > should stay there. > > The reason I bring this up is that recently I re-packaged cvs (and am > also working on updating gettext and libiconv) and decided to take the > latest-and-greatest gbs and merge in my package-specific mods. It was > quite a bit more difficult than it should have been given all the thrash > in the main gbs. Basically, EVERY package is a fork... Yes, but there's the question of the extent to which it has diverged. If all you do is change parameters, it ought to be easy. It would help if you outlined the difficulties you had (feel free to email me privately, though I think a public summary might produce more patches). > I eventually decided to NOT use the latest-and-greatest, but instead > used the version just before LOGGING support was added. And honestly, I > don't think I'll ever bother to up-merge again. That version of gbs > does everything I want and I see no need for "auto-edit README" or > "LOGGING support". If I want a log, I'll tee the output of configure or > make myself. Logs are for me, the maintainer... Heh, the argument for including the logs (which I, after having installed some package source tarballs, think aren't such a hot idea anymore) was that when users build the packages on their machines, they can see if they get a different configuration from what the maintainer had. And it may be a useful feature to run the build with logging turned on (though I don't think it should be the default). Perhaps another job for an external maintainer.sh script. > Every new feature added to gbs makes it that much more difficult for > maintainers to keep pace with gbs updates when they update their > packages. Please think carefully before adding new stuff: is feature X > *really* worth it? True enough, though this is the first official complaint from an active package maintainer about the new features. Let me try to find
Re: generic-build-script extension to update version numbers in README
Christian Franke wrote: the build-script of the smartmontools package creates the "Cygwin/package-*.README" file from "srcdir/CYGWIN-PATCHES/package.README.in" by replacing VER/REL with the current version/release numbers. This might be useful for other packages to avoid extra editing of README on each minor release. Christian, please don't take offense; the following semi-rant is not aimed at you, but is a product of my frustration with gbs. It's become an issue for me in that the difficulty of trying to track changes in the gbs is a significant portion of my effort when releasing a new version of an existing package. I'd like to make a request: gbs is getting out of control with this feature and that feature added. Some of these tasks are NEVER going to be performed by anyone other than the primary maintainer: has anyone actually used 'foo.sh list' or 'foo.sh depends'? It's a nice feature, but how useful is it, really? Ditto this maintainer-only 'muck with the README' script. Could these added features be simply refactored into ancillary scripts instead of integrated into the main gbs? E.g. ./foo.sh externaltool /path/to/update-readme where the gbs's externaltool function would simply source the update-readme fragment -- and the update-readme fragment would inherit all of the variable settings from the top of the gbs. I'd figure that 'update-readme' would NOT be shipped with cygwin packages, but could be downloaded from the sourceware cvs by a maintainer who wanted to use it on her machine when maintaining her package foo. Thus, I don't see exploding out a bunch of 'build.frag' and 'prep.frag' and 'mkpatch.frag' fragments; the current intrinsic functions in the gbs should stay there. The reason I bring this up is that recently I re-packaged cvs (and am also working on updating gettext and libiconv) and decided to take the latest-and-greatest gbs and merge in my package-specific mods. It was quite a bit more difficult than it should have been given all the thrash in the main gbs. Basically, EVERY package is a fork... I eventually decided to NOT use the latest-and-greatest, but instead used the version just before LOGGING support was added. And honestly, I don't think I'll ever bother to up-merge again. That version of gbs does everything I want and I see no need for "auto-edit README" or "LOGGING support". If I want a log, I'll tee the output of configure or make myself. Logs are for me, the maintainer... Every new feature added to gbs makes it that much more difficult for maintainers to keep pace with gbs updates when they update their packages. Please think carefully before adding new stuff: is feature X *really* worth it? -- Chuck P.S. It'd be a different story if we were using an 'engine' with external overrides, like mingwports or cgf's netrel(?) -- then mods to the engine to provide new features would be distinct from the package-specific overrides. But gbs ain't like that.
generic-build-script extension to update version numbers in README
[Resummited to cygwin-apps on request of Igor]
Hi,
the build-script of the smartmontools package creates the
"Cygwin/package-*.README" file from
"srcdir/CYGWIN-PATCHES/package.README.in" by replacing VER/REL with the
current version/release numbers.
This might be useful for other packages to avoid extra editing of README
on each minor release.
A patch for generic-build-script 1.43 is attached.
Christian
--- generic-build-script.orig Sat Nov 12 15:21:55 2005
+++ generic-build-scriptFri Nov 18 10:54:58 2005
@@ -220,9 +220,16 @@
mkdir -p ${objdir} && \
conf )
}
+buildreadme() {
+ sed "s//${VER}/g;s//${REL}/g"
+}
build() {
(cd ${objdir} && \
- make CFLAGS="${MY_CFLAGS}" 2>&1 | tee ${makelogfile} )
+ make CFLAGS="${MY_CFLAGS}" 2>&1 | tee ${makelogfile} && \
+ if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README.in ]; then \
+buildreadme < ${srcdir}/CYGWIN-PATCHES/${PKG}.README.in \
+ > ${objdir}/${FULLPKG}.README; \
+ fi )
}
check() {
(cd ${objdir} && \
@@ -230,7 +237,8 @@
}
clean() {
(cd ${objdir} && \
- make clean )
+ make clean && \
+ rm -f ${objdir}/${FULLPKG}.README )
}
install() {
(cd ${objdir} && \
@@ -269,8 +277,11 @@
/usr/bin/install -m 644 $templist \
${instdir}${prefix}/share/doc/${SHORTPKG} ; \
fi && \
- if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
-/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README \
+ if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README.in ]; then \
+/usr/bin/install -m 644 ${objdir}/${FULLPKG}.README \
+ ${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
+ elif [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
+/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README ] \
${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
elif [ -f ${srcdir}/CYGWIN-PATCHES/README ] ; then \
/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/README \
Re: Please upload: naim-0.11.8
Thanks to all for the positive feedback. As a new maintainer, it's really great to see such a warm reception. Thanks for the gold star! You guys rock. jca
Re: Please upload: naim-0.11.8
On Fri, 18 Nov 2005, Corinna Vinschen wrote: > On Nov 18 11:13, Christopher Faylor wrote: > > On Fri, Nov 18, 2005 at 03:40:23PM +, Jon Allen wrote: > > >On Fri, Nov 18, 2005 at 11:34:06AM +0100, Corinna Vinschen wrote: > > >>Packaging looks good. The above setup.hint is not quite correct, naim > > >>is linked against libncurses8, not libncurses7. I fixed that and > > >>uploaded the package to cygwin.com. You should also fix your local > > >>copy, perhaps. > > >> > > > > > >Thanks for catching that. The source package contains a copy of the > > >incorrect setup.hint in naim-0.11.8-1.patch - should I correct this and > > >roll a new source package? > > > > I don't think that's necessary as long as you've corrected your local > > version. > > > > Thanks for stepping up to do this. It is much appreciated. > > Igor, can we get a gold star for Jon? Everybody taking over an orphaned > package should get one in future. Sure, done. Igor P.S. I didn't want to send a separate message, but since I'm replying to this thread anyway -- big thanks to Jon for not letting a very useful package fall through the cracks. -- 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! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Please upload: naim-0.11.8
On Nov 18 15:53, Christopher Faylor wrote: > On Fri, Nov 18, 2005 at 09:21:00PM +0100, Corinna Vinschen wrote: > >Igor, can we get a gold star for Jon? Everybody taking over an orphaned > >package should get one in future. > > I agree 100% but I'd like to see whomever picks up this duty take the package > through a full release before giving out a gold star. Jon has done that. Uh, thanks. I knew I was missing something but I couldn't remember what it was. Having a package really uploaded and announced as precondition, that was it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: Please upload: naim-0.11.8
On Fri, Nov 18, 2005 at 09:21:00PM +0100, Corinna Vinschen wrote: >On Nov 18 11:13, Christopher Faylor wrote: >> On Fri, Nov 18, 2005 at 03:40:23PM +, Jon Allen wrote: >> >On Fri, Nov 18, 2005 at 11:34:06AM +0100, Corinna Vinschen wrote: >> >>Packaging looks good. The above setup.hint is not quite correct, naim >> >>is linked against libncurses8, not libncurses7. I fixed that and >> >>uploaded the package to cygwin.com. You should also fix your local >> >>copy, perhaps. >> >> >> > >> >Thanks for catching that. The source package contains a copy of the >> >incorrect setup.hint in naim-0.11.8-1.patch - should I correct this and >> >roll a new source package? >> >> I don't think that's necessary as long as you've corrected your local >> version. >> >> Thanks for stepping up to do this. It is much appreciated. > >Igor, can we get a gold star for Jon? Everybody taking over an orphaned >package should get one in future. I agree 100% but I'd like to see whomever picks up this duty take the package through a full release before giving out a gold star. Jon has done that. Thanks again, Jon. cgf
Re: Please upload: naim-0.11.8
On Nov 18 11:13, Christopher Faylor wrote: > On Fri, Nov 18, 2005 at 03:40:23PM +, Jon Allen wrote: > >On Fri, Nov 18, 2005 at 11:34:06AM +0100, Corinna Vinschen wrote: > >>Packaging looks good. The above setup.hint is not quite correct, naim > >>is linked against libncurses8, not libncurses7. I fixed that and > >>uploaded the package to cygwin.com. You should also fix your local > >>copy, perhaps. > >> > > > >Thanks for catching that. The source package contains a copy of the > >incorrect setup.hint in naim-0.11.8-1.patch - should I correct this and > >roll a new source package? > > I don't think that's necessary as long as you've corrected your local > version. > > Thanks for stepping up to do this. It is much appreciated. Igor, can we get a gold star for Jon? Everybody taking over an orphaned package should get one in future. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: Security advisory: gtk2-x11
Gerrit P. Haase wrote: > Will integrate this asap. Thanks. > Ok. Just prepare what is needed next and notify seperately when you're > uploading. I have GConf2, libbonobo2, gnome-vfs2, libgnome2, libbonoboui2, and libgnomeui2 all up to 2.10.1, and I have a renamed libart_lgpl2 in order to make space for gnome-libs-1.4.2. > You are able to upload yourself? No. Yaakov
Re: Security advisory: gtk2-x11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: > Ok. Just prepare what is needed next and notify seperately when you're > uploading. Forgot to mention, I also have (glitz and) cairo, which is required for pango-1.10 and gtk+-2.8, if you think you're ready to make that move. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfiIhpiWmPGlmQSMRAkrXAJ0X1lkfSDX6E+lCY7O4+SCt5cYDxQCfUqzl jUwms2E647IHgPUCl5VofWA= =I6PY -END PGP SIGNATURE-
Re: Security advisory: gtk2-x11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: > Will integrate this asap. Thanks. > Ok. Just prepare what is needed next and notify seperately when you're > uploading. I have GConf2, libbonobo2, gnome-vfs2, libgnome2, libbonoboui2, and libgnomeui2 all up to 2.10.1, and I have a renamed libart_lgpl2 in order to make space for gnome-libs-1.4.2. > You are able to upload yourself? No. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfiEnpiWmPGlmQSMRAs3AAKDJ80/UlXg0lfLTWytIt9+ZkAElcgCfSKev /tArleA5QJFkSfVc2KRqh2o= =Iv0X -END PGP SIGNATURE-
Re: [ITP] perl-Tk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yitzchak Scott-Thoennes wrote: > At the risk of incurring Corinna's wrath, I second the request. I'd like > to see someone submit an X-less perl-Tk package too, with support in both > for alternatives. Here are the issues: 1) Two ports of perl-Tk, one X11 and one Win32, *will* collide with each other, and may lead to more confusion from the end users. 2) Since 804.xxx, the Win32 build has been broken on Cygwin, whereas the X11 build works with a minor patch (to fix an assumption that Cygwin is using Win32). 3) The fact that tcltk is Win32 (as stated numerous times in the past, the reason being to support insight) does not mean that perl-Tk need be Win32 as well. 4) Even regarding tcltk, there's been discussion recently on finding a way to make the primary installation Unix/X11 and a secondary Win32 version for insight. Considering all the above, I found it most feasible to package *one* perl-Tk, based on X11, and I have yet to see a convicing argument otherwise. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfiAcpiWmPGlmQSMRAnKmAKCZgavU57TVCRn8CcWFeTiGy5vojgCfSd6T jrVOpMEdH/HU0jGgX+cvDNw= =IBAN -END PGP SIGNATURE-
Re: [ITP] cadaver: Command-line WebDAV client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. Volker Zell wrote: > I would like to contribute and maintain the cadaver package: > > * http://www.webdav.org/cadaver/ (Homepage) > > Max, would it be possible to recompile neon so that it picks up the new > openssl package ? Refreshing neon is of course, not a problem. However, there is another potential problem. Neon is still in development, and breaks API compat fairly regularly. I was planning to move from neon 0.24.x to 0.25.x soon (an API break). When I do, of course a _runtime_ compat package will remain, but after investigation, I found that it would require quite a lot of work to make it possible for multiple versions of development versions of neon to co-exist - so I hadn't been planning on doing that. This isn't a problem, so long as all client applications are actively maintained, and get updated reasonably promptly to compile against new upstream neon versions, but cadaver hasn't had a release in over a year. I couldn't find conclusive information on whether the current cadaver release is compatible with 0.25.x - do you happen to know? Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFDfhdYfFNSmcDyxYARAmTuAKCzVI+FneVqxD3ljVB6Bdv87BX6RgCgqVn8 ijENMyyuGp2BXWrgOUN+VYs= =JWFy -END PGP SIGNATURE-
Re: [ITP] Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim O'Callaghan wrote: > On Fri, Nov 18, 2005 at 05:57:14AM -0700, Eric Blake wrote: > >>>3) If a package needs a specific tool to build it, such as asciidoc being >>>needed for >>> git documentation, does it also need to be supported or not? if so does >>> it need >>> to be bundled with the source, or as a separate package? >> >>In general, we like the ability to reproduce a build using cygwin >>packages. This has not always been the case, but cygwin is now >>self-sustaining enough that you can rebuild almost all cygwin packages >>using just cygwin (cross-compiling would be hands down faster, but it is >>the principle of the thing). I would consider proposing asciidoc as a >>separate package, again because it might prove useful outside of git. >> > > > Ok. I'll set it up as a separate package. > > I was thinking about the current distro method, its probably a stupid > question, but i was wondering why don't you support, or have tools to convert > rpm/dpkg type build packages? Cygwin seems to have native rpm & dpkg tools and > most source packages have a 'dist' type target... Leaving aside the SHTDI issue that has already been discussed, I'm not sure this would be as useful as it sounds. The generic-build-script does quite a few little things like autoinstalling certain doc files, helping out with pre/postinstall scripts, providing default configure args to put files in the standard Cygwin places. All of which would be missed out if you used the package's own idea of how to package things. The main configure/make/install buildsystem of a package is often better maintained than bundled RPM specfiles, etc. Also, as far as Cygwin's rpm/dpkg tools go: dpkg is maintainerless and slated for removal, and current upstream versions of RPM die before entering main(), when compiled on Cygwin. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFDfg2ifFNSmcDyxYARAizDAKDD47o8OV+5qw9p9y1LilvQGYQQlACcD/W3 JFh2UCd+hXUnCIg2cdlm53s= =T5pQ -END PGP SIGNATURE-
[ITP] cadaver: Command-line WebDAV client
Hi I would like to contribute and maintain the cadaver package: * http://www.webdav.org/cadaver/ (Homepage) * http://www.webdav.org/cadaver/ (Download location) It seems to be in a lot of distros: http://rpmfind.net/linux/rpm2html/search.php?query=cadaver Max, would it be possible to recompile neon so that it picks up the new openssl package ? Ciao Volker -- Here is the setup.hint file: sdesc: "Command-line WebDAV client" ldesc: "cadaver is a command-line WebDAV client, with support for file upload, download, on-screen display, in-place editing, namespace operations (move/copy), collection creation and deletion, property manipulation, and resource locking.." category: Web requires: cygwin libneon24 libreadline6 cut here #!/bin/bash mkdir cadaver cd cadaver wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/cadaver/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/cadaver/cadaver-0.22.2-1-src.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/cadaver/cadaver-0.22.2-1.tar.bz2 cut here
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 04:48:34PM +0100, Tim O'Callaghan wrote: >On Fri, Nov 18, 2005 at 10:05:07AM -0500, Christopher Faylor wrote: >>On Fri, Nov 18, 2005 at 03:14:59PM +0100, Tim O'Callaghan wrote: >>>I was thinking about the current distro method, its probably a stupid >>>question, but i was wondering why don't you support, or have tools to >>>convert rpm/dpkg type build packages? Cygwin seems to have native rpm >>>& dpkg tools and most source packages have a 'dist' type target... >> >>There's no mystery here. We're all just mean SOBs who like to make >>things as hard as possible for people. > >I thought as much. > >>What other reason could there be for the lack of existence of something >>in a free software project? >> > >Lack of someone bothered enough by the problem to do anything about it, >is the usual reason ;) Bingo! cgf
Re: Please upload: naim-0.11.8
On Fri, Nov 18, 2005 at 03:40:23PM +, Jon Allen wrote: >On Fri, Nov 18, 2005 at 11:34:06AM +0100, Corinna Vinschen wrote: >>Packaging looks good. The above setup.hint is not quite correct, naim >>is linked against libncurses8, not libncurses7. I fixed that and >>uploaded the package to cygwin.com. You should also fix your local >>copy, perhaps. >> > >Thanks for catching that. The source package contains a copy of the >incorrect setup.hint in naim-0.11.8-1.patch - should I correct this and >roll a new source package? I don't think that's necessary as long as you've corrected your local version. Thanks for stepping up to do this. It is much appreciated. cgf
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 10:05:07AM -0500, Christopher Faylor wrote: > On Fri, Nov 18, 2005 at 03:14:59PM +0100, Tim O'Callaghan wrote: > >I was thinking about the current distro method, its probably a stupid > >question, but i was wondering why don't you support, or have tools to > >convert rpm/dpkg type build packages? Cygwin seems to have native rpm > >& dpkg tools and most source packages have a 'dist' type target... > > There's no mystery here. We're all just mean SOBs who like to make > things as hard as possible for people. I thought as much. > What other reason could there be > for the lack of existence of something in a free software project? > Lack of someone bothered enough by the problem to do anything about it, is the usual reason ;) Tim. "However beautiful the strategy, you should occasionally look at the results." -- Winston Churchill
Re: Please upload: naim-0.11.8
On Fri, Nov 18, 2005 at 11:34:06AM +0100, Corinna Vinschen wrote: > > Packaging looks good. The above setup.hint is not quite correct, > naim is linked against libncurses8, not libncurses7. I fixed that > and uploaded the package to cygwin.com. You should also fix your > local copy, perhaps. > Thanks for catching that. The source package contains a copy of the incorrect setup.hint in naim-0.11.8-1.patch - should I correct this and roll a new source package? jca
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 03:14:59PM +0100, Tim O'Callaghan wrote: >I was thinking about the current distro method, its probably a stupid >question, but i was wondering why don't you support, or have tools to >convert rpm/dpkg type build packages? Cygwin seems to have native rpm >& dpkg tools and most source packages have a 'dist' type target... There's no mystery here. We're all just mean SOBs who like to make things as hard as possible for people. What other reason could there be for the lack of existence of something in a free software project? cgf
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 05:57:14AM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > > 3) If a package needs a specific tool to build it, such as asciidoc being > > needed for > >git documentation, does it also need to be supported or not? if so does > > it need > >to be bundled with the source, or as a separate package? > > In general, we like the ability to reproduce a build using cygwin > packages. This has not always been the case, but cygwin is now > self-sustaining enough that you can rebuild almost all cygwin packages > using just cygwin (cross-compiling would be hands down faster, but it is > the principle of the thing). I would consider proposing asciidoc as a > separate package, again because it might prove useful outside of git. > Ok. I'll set it up as a separate package. I was thinking about the current distro method, its probably a stupid question, but i was wondering why don't you support, or have tools to convert rpm/dpkg type build packages? Cygwin seems to have native rpm & dpkg tools and most source packages have a 'dist' type target... Tim. "However beautiful the strategy, you should occasionally look at the results." -- Winston Churchill
Re: [ITP] Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim O'Callaghan wrote: > Hi, > > Sorry about the delay with getting back to this stuff. > > I'd like to ask a few quick questions before i send my formal ITP's > 1) should i send a separate ITP email for each one or one for all of them? Choose based on whether it makes sense for them to be discussed as a unit, or not. If packages are entirely unrelated, use separate emails. Combine multiple packages into a single ITP mail if it makes little sense for one to be added to the Cygwin distro without the other. > 2) bundling - If i need to include a new tool/lib to support a particular > feature >such as String::ShellQuote or CVSps, should i bundle it in or separate it > out? > are there guidelines? Separate packages are nicer, because then you can update the tool/lib without updating the 'parent' package, and vice versa. Plus, there's always the possibility another package might want to depend on the tool/lib later. > 3) If a package needs a specific tool to build it, such as asciidoc being > needed for >git documentation, does it also need to be supported or not? if so does it > need >to be bundled with the source, or as a separate package? It really ought to be possible to rebuild any Cygwin package using only software available as Cygwin packages, so a package would be preferable. Separately - the answer to 2) applies equally here too. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFDfdN5fFNSmcDyxYARAg29AJ9XtPak16gfcQ20lOhjFL/MhuECEwCgrKXA KArsHvi7oenlEqx8k4UC9go= =Syzp -END PGP SIGNATURE-
Re: [ITP] perl-Tk
Corinna Vinschen wrote: On Nov 18 08:11, Reini Urban wrote: Yaakov S (Cygwin Ports) schrieb: Due to popular request, I would like to ITP Perl/Tk: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint Can we have a "-X" in the name please, to make it clear that this is NOT the native version. I was just fighting again with the native version yesterday, but didn't succeed yet. Wonder what broke that since 804.025 category: Perl X11 requires: cygwin crypt libXft2 libfontconfig1 libfreetype26 libjpeg62 libpng12 perl xorg-x11-base zlib sdesc: "Perl interface for Tk (X11)" ldesc: "Complete Perl interface for Tk, built against Cygwin/X." Could people also start to *review* new packages? Having an opinion is nice, but it doesn't result in having packages in the distro. Already done. It builds fine, however I see some tests failing and the demo widget is not running properly here. Already posted a question about this at the main list. Gerrit -- =^..^=
Re: Security advisory: gtk2-x11
Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit, The GdkPixbuf library, that is also included in GTK+ 2, contains vulnerabilities that could lead to a Denial of Service or the execution of arbitrary code. Solution: a patch for gtk+-2.x is required (URL below). Will integrate this asap. (BTW, Gerrit, what are your plans for GTK/GNOME? I'm willing to take stuff over if you've lost interest.) Ok. Just prepare what is needed next and notify seperately when you're uploading. You are able to upload yourself? Gerrit -- =^..^=
Re: [ITP] Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tim O'Callaghan on 11/18/2005 4:04 AM: > > I'd like to ask a few quick questions before i send my formal ITP's > 1) should i send a separate ITP email for each one or one for all of them? If they are for related packages, one email will do (look at yesterday's upload request for multiple xemacs packages, for example). > > 2) bundling - If i need to include a new tool/lib to support a particular > feature >such as String::ShellQuote or CVSps, should i bundle it in or separate it > out? > are there guidelines? If the feature is useful on its own, it is worth considering a separate package. But as the package proposer, you have some freedom here to do what you think is best, then you can ask for some feedback as to whether your proposed layout actually made sense. > > 3) If a package needs a specific tool to build it, such as asciidoc being > needed for >git documentation, does it also need to be supported or not? if so does it > need >to be bundled with the source, or as a separate package? In general, we like the ability to reproduce a build using cygwin packages. This has not always been the case, but cygwin is now self-sustaining enough that you can rebuild almost all cygwin packages using just cygwin (cross-compiling would be hands down faster, but it is the principle of the thing). I would consider proposing asciidoc as a separate package, again because it might prove useful outside of git. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfc+q84KuGfSFAYARAuwNAJsEvEm7vXEzz5y4h3O4/B5yblegswCfeHiG SpjLb7HB+S9vRHmK0AGiw68= =cEN7 -END PGP SIGNATURE-
Re: [ITP] smartmontools: monitoring S.M.A.R.T. disks and devices
On Nov 18 13:49, Christian Franke wrote: > http://franke.dvrdns.org/cygwin/setup.hint > http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1.tar.bz2 > http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1-src.tar.bz2 Thanks, uploaded. Please send an announcement to cygwin-announce in a couple of hours. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: [ITP] smartmontools: monitoring S.M.A.R.T. disks and devices
> > Corinna Vinschen wrote: > > [...] > > 2nd try: > > > > http://franke.dvrdns.org/cygwin/setup.hint > > http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1.tar.bz2 > > http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1-src.tar.bz2 > > Erm... looks fine, but... now that the package is called > smartmontools-5.33foo, maybe the documentation should also be in > /usr/share/doc/smartmontools-5.33 or > /usr/share/doc/smartmontools-5.33foo instead of in > /usr/share/doc/smartmontools-5.34? OK changed, 3rd try: http://franke.dvrdns.org/cygwin/setup.hint http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1.tar.bz2 http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1-src.tar.bz2 The smartmontools*.sh script now contains extra commands to build the native windows package on Cygwin: wconf, wbuild, wpkg, ... Christian
Re: Guile misbehavior
Jan Nieuwenhuizen schrieb: Andreas Seidl writes: $ cd /tmp $ guile --version ERROR: In procedure make-struct-layout: ERROR: Wrong type argument in position 1 (expecting STRINGP): pw Any ideas what causes this? No, it works for me. What does pwd say in the directories where it doesn't work? $ pwd /tmp What does cygcheck /usr/bin/guile.exe say? $ cygcheck /usr/bin/guile.exe C:/cygwin/bin/guile.exe C:/cygwin/bin\cygguile-12.dll C:/cygwin/bin\cygcrypt-0.dll C:/cygwin/bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:/cygwin/bin\cygguile-ltdl-1.dll In addition: $ cygcheck -svr | grep guile 528k 2005/10/09 C:\cygwin\bin\cygguile-12.dll - os=4.0 img=1.0 sys=4.0 "cygguile-12.dll" v0.0 ts=2005/10/9 15:25 640k 2004/10/12 C:\cygwin\bin\cygguile-16.dll - os=4.0 img=1.0 sys=4.0 "cygguile-16.dll" v0.0 ts=2004/10/12 16:42 18k 2005/10/09 C:\cygwin\bin\cygguile-ltdl-1.dll - os=4.0 img=1.0 sys=4.0 "cygguile-ltdl-1.dll" v0.0 ts=2005/10/9 15:24 5k 2004/10/12 C:\cygwin\bin\cygguile-ltdl-2.dll - os=4.0 img=1.0 sys=4.0 "cygguile-ltdl-2.dll" v0.0 ts=2004/10/12 13:02 11k 2004/10/12 C:\cygwin\bin\cygguile-srfi-srfi-1-v-2-2.dll - os=4.0 img=1.0 sys=4.0 "cygguile-srfi-srfi-1-v-2-2.dll" v0.0 ts=2004/10/12 16:42 68k 2005/10/09 C:\cygwin\bin\cygguile-srfi-srfi-13-14-v-1-1.dll - os=4.0 img= 1.0 sys=4.0 "cygguile-srfi-srfi-13-14-v-1-1.dll" v0.0 ts=2005/10/9 15:25 4k 2004/10/12 C:\cygwin\bin\cygguile-srfi-srfi-13-14-v-2-2.dll - os=4.0 img= 1.0 sys=4.0 "cygguile-srfi-srfi-13-14-v-2-2.dll" v0.0 ts=2004/10/12 16:43 31k 2005/10/09 C:\cygwin\bin\cygguile-srfi-srfi-4-v-1-1.dll - os=4.0 img=1.0 sys=4.0 "cygguile-srfi-srfi-4-v-1-1.dll" v0.0 ts=2005/10/9 15:25 22k 2004/10/12 C:\cygwin\bin\cygguile-srfi-srfi-4-v-2-2.dll - os=4.0 img=1.0 sys=4.0 "cygguile-srfi-srfi-4-v-2-2.dll" v0.0 ts=2004/10/12 16:42 12k 2005/10/09 C:\cygwin\bin\cygguilereadline-v-12-12.dll - os=4.0 img=1.0 sy s=4.0 "cygguilereadline-v-12-12.dll" v0.0 ts=2005/10/9 15:25 11k 2004/10/12 C:\cygwin\bin\cygguilereadline-v-16-16.dll - os=4.0 img=1.0 sy s=4.0 "cygguilereadline-v-16-16.dll" v0.0 ts=2004/10/12 16:42 guile 1.6.7-4 guile-devel 1.6.7-4 guile-doc 1.6.7-4 libguile12 1.6.7-4 libguile12abi13 1.6.4-3 libguile16 1.7.1.20041006-1 Andreas -- http://www.fmi.uni-passau.de/~seidl
[ITP] Questions
Hi, Sorry about the delay with getting back to this stuff. I'd like to ask a few quick questions before i send my formal ITP's 1) should i send a separate ITP email for each one or one for all of them? 2) bundling - If i need to include a new tool/lib to support a particular feature such as String::ShellQuote or CVSps, should i bundle it in or separate it out? are there guidelines? 3) If a package needs a specific tool to build it, such as asciidoc being needed for git documentation, does it also need to be supported or not? if so does it need to be bundled with the source, or as a separate package? cheers, Tim. "However beautiful the strategy, you should occasionally look at the results." -- Winston Churchill
Re: [ITP] smartmontools: monitoring S.M.A.R.T. disks and devices
On Nov 17 23:20, Christian Franke wrote: > > >Corinna Vinschen wrote: > >[...] > > > >>- The postinstall script copies the file /etc/defaults/etc/smartd.conf, > >> but the file itself is accidentally in /etc/defaults. > >> > >> > > > >Yes, thanks. > > > >>If you change this, the package is GTG, AFAICS. > >> > >> > > > 2nd try: > > http://franke.dvrdns.org/cygwin/setup.hint > http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1.tar.bz2 > http://franke.dvrdns.org/cygwin/smartmontools-5.33cvs20051115-1-src.tar.bz2 Erm... looks fine, but... now that the package is called smartmontools-5.33foo, maybe the documentation should also be in /usr/share/doc/smartmontools-5.33 or /usr/share/doc/smartmontools-5.33foo instead of in /usr/share/doc/smartmontools-5.34? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: Please upload: naim-0.11.8
On Nov 18 09:01, Jon Allen wrote: > Files: > > http://jca.sdf1.org/cygwin/naim-0.11.8-1.tar.bz2 > http://jca.sdf1.org/cygwin/naim-0.11.8-1-src.tar.bz2 > http://jca.sdf1.org/cygwin/setup.hint > > setup.hint: > > sdesc: "Console AIM, ICQ, IRC, and Lily client" > ldesc: "A console AIM, ICQ, IRC and Lily CMC client." > category: Net Web > requires: cygwin libncurses7 Packaging looks good. The above setup.hint is not quite correct, naim is linked against libncurses8, not libncurses7. I fixed that and uploaded the package to cygwin.com. You should also fix your local copy, perhaps. Welcome as new package maintainer! Please don't forget to send an announcement to cygwin-announce in a few hours. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: [ITP] perl-Tk
On Fri, Nov 18, 2005 at 08:11:03AM +0100, Reini Urban wrote: > Yaakov S (Cygwin Ports) schrieb: > >Due to popular request, I would like to ITP Perl/Tk: > > > >ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3-src.tar.bz2 > >ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3.tar.bz2 > >ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint > > Can we have a "-X" in the name please, to make it clear that this is NOT > the native version. > I was just fighting again with the native version yesterday, but didn't > succeed yet. Wonder what broke that since 804.025 At the risk of incurring Corinna's wrath, I second the request. I'd like to see someone submit an X-less perl-Tk package too, with support in both for alternatives. > >category: Perl X11 > >requires: cygwin crypt libXft2 libfontconfig1 libfreetype26 libjpeg62 > >libpng12 perl xorg-x11-base zlib > >sdesc: "Perl interface for Tk (X11)" > >ldesc: "Complete Perl interface for Tk, built against Cygwin/X." > > -- > Reini Urban > http://phpwiki.org/
Re: Guile misbehavior
Andreas Seidl writes: > $ cd /tmp > $ guile --version > ERROR: In procedure make-struct-layout: > ERROR: Wrong type argument in position 1 (expecting STRINGP): pw > Any ideas what causes this? No, it works for me. What does pwd say in the directories where it doesn't work? What does cygcheck /usr/bin/guile.exe say? You may have bits of another guile-1.6.x lying around, I have seen the make-struct-layout bug with guile-1.6.4 library files. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Guile misbehavior
I firstly encountered this problem with guile-config. Guile works in my home directory (I should add that my home directory in C:\cygwin\home is a symbolic link to /cygdrive/d), but not in the /tmp directory: $ cd /tmp $ guile --version ERROR: In procedure make-struct-layout: ERROR: Wrong type argument in position 1 (expecting STRINGP): pw $ cd ~ $ guile --version Guile 1.6.7 Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. $ cd /cygdrive/c $ guile --version ERROR: In procedure make-struct-layout: ERROR: Wrong type argument in position 1 (expecting STRINGP): pw $ cd /cygdrive/d $ guile --version Guile 1.6.7 Copyright (c) 1995, 1996, 1997, 2000, 2001, 2002, 2003, 2004 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. Guile is up-to-date: guile 1.6.7-4 guile-devel 1.6.7-4 guile-doc 1.6.7-4 libguile12 1.6.7-4 libguile12abi13 1.6.4-3 libguile16 1.7.1.20041006-1 Any ideas what causes this? Best Regards Andreas -- http://www.fmi.uni-passau.de/~seidl
Re: [ITP] perl-Tk
On Nov 18 08:11, Reini Urban wrote: > Yaakov S (Cygwin Ports) schrieb: > >Due to popular request, I would like to ITP Perl/Tk: > > > >ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3-src.tar.bz2 > >ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-3.tar.bz2 > >ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint > > Can we have a "-X" in the name please, to make it clear that this is NOT > the native version. > I was just fighting again with the native version yesterday, but didn't > succeed yet. Wonder what broke that since 804.025 > > >category: Perl X11 > >requires: cygwin crypt libXft2 libfontconfig1 libfreetype26 libjpeg62 > >libpng12 perl xorg-x11-base zlib > >sdesc: "Perl interface for Tk (X11)" > >ldesc: "Complete Perl interface for Tk, built against Cygwin/X." Could people also start to *review* new packages? Having an opinion is nice, but it doesn't result in having packages in the distro. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
