Re: LICENSE: base-files and use of CC0 - public domain
On Fri, Oct 26, 2012 at 12:26:59PM -0600, Warren Young wrote: On 10/25/2012 11:49 AM, Jari Aalto wrote: Neither OSI, nor FSF recommend use of public domain for Open Source software. I think you should total up the list of recommendations the FSF has made over the years, and decide if you really want to be constrained use only things that make FSF happy. FSF recommends use of existing licences (GNU licences, Apache ...), likewise OSI: We recommend that you always apply an approved Open Source license to software you are releasing, rather than try to waive copyright [= put into public domain] altogether. http://opensource.org/faq#public-domain CC0 is a bit more complicated than pure public domain. ... This “Give-It-Away” license provides no protection for anyone if the donated software causes harm (...) one [cannot] escape a lawsuit just because his gift was only accidentally harmful. CC0 contains a warranty disclaimer. (§4.b.) If utmost free were the initial intention -- What was wrong with the BSD[1] or MIT licenses, which are desinged to be Open Source software licenses? My point is that this is basically what you get, when you live somewhere that doesn't allow public domain copyright disclaimer. When I first decided to use CC0, I admitedly didn't do too much of a research. I concur with Corinna that the contents of the base-files package is simple enough not to even worry about licensing, but as concern about this reached the list[1], I simply looked for something a little bit more serious than the beer-ware[2] license and used it: I found the CC0 to be FSF[3] approved, and I thought it was an authoritative enough source of information. I really don't mind to move to any of BSD-2 or GPLv3 if needed, but I definitely don't want to see my name in each and every one of the files, because I'm only the mantainer here, and most of the code was already there or has been contributed by others, so before I merge those kindly sent pull-requests, I'd like to know if the copyright attribution in the headers could reference the cygwin project, something like: ( Copyright (c) 2010-2012 The cygwin project http://cygwin.com ) That would be both fair and accurate. Thanks for any pointers. [1] Sorry, didn't find it in the archives, look for it around October 2011 [2] https://en.wikipedia.org/wiki/Beerware [3] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses https://www.gnu.org/licenses/license-list.html#CC0 -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: LICENSE: base-files and use of CC0 - public domain
https://github.com/dsastrem/base-files.git
Most probably, a wrong assumption on my side.
I am not a lawyer, and most of this parlance goes far beyond my
understanding. I wouldn't mean any harm whatsoever to this project, or
would I purposedly introduced a legal flaw by using the Public Domain
License in the base-files package contents.
What would be more appropriate? GPLv3?
On other news, I'm frankly short of time to dedicate to base-files
mantainership. It has a long time pending promotion from test to
current. The aforementioned github repo is available to anyone who
would like to adopt it, as well as the packages from cygwin.com, of
course. The only outstanding issue I can think of right now, would be
to revert this change:
-PATH=/usr/local/bin:/usr/bin:${PATH}
+ORIGINAL_PATH=${PATH}
+PATH=/usr/local/bin:/usr/bin
The details about this issue can be found here:
http://cygwin.com/ml/cygwin/2012-08/msg00488.html
I'm still actively monitoring the cygwin list, so I'll try to respond
promptly to any comments or suggestions regarding this question.
--
Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: RFU: keychain 2.7.1-1 (ITA: new maintainer)
On Wed, Oct 10, 2012 at 11:00:04AM +0200, Corinna Vinschen wrote: On Oct 10 08:44, Jari Aalto wrote: 2012-10-09 21:49 David Sastre Medina | | P.S. keychain (also a simple shell script) is orphaned, and there's a | new version upstream, just in case you're interested. New upstream release: Err... hang on. This package is officially maintained by Jonathan C. Allen. I admit that we had no feedback from him since 2007, but it doesn't hurt to ask. Jonathan? Are you still with us in some way? You are still officially maintainer of 5 packages, bsflite, keychain, naim, ncftp and tnef. None of them has been update since 2007, though... I'm sorry. Somehow, I had the idea of keychain being orphaned already. I tried searching the mail archives, but I could only find this thread from some months ago: http://sourceware.org/ml/cygwin-apps/2012-03/msg00082.html Again, I apologize. Completely unintended. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: ITP: makeself -- Utility to generate self-extractable archives
On Mon, Oct 08, 2012 at 04:02:30PM +0300, Jari Aalto wrote: 2012-10-08 07:41 Steven Monai: | makeself is already in the Cygwin archive. Ok, good. Jari, If you want to take over mantainership of makeself, I have no objections. According to its git log, there have been some minor improvements during this year. P.S. keychain (also a simple shell script) is orphaned, and there's a new version upstream, just in case you're interested. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files-4.1-2
Hello, Please upload base-files-4.1-2. I'd like to release 4.1-2 as a test release, so setup.hint has changed, too. http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2.sig http://crapsteak.org/cygwin/release/base-files/setup.hint I've left 4.1-1 as current and 4.1-2 as test. Please delete any older releases. Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files-4.1-1
Hello, Please upload base-files-4.1-1. http://crapsteak.org/cygwin/release/base-files/base-files-4.1-1.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.1-1.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files 4.0-8 [BUGFIX]
Hello, Please upload base-files-4.0-8. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-8.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-8.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[RFU] base-files-4.0-9 [BUGFIX]
Hello, Sorry to bother again. Please upload base-files-4.0-9. Contains a fix for the bug reported in http://cygwin.com/ml/cygwin/2012-02/msg00352.html http://crapsteak.org/cygwin/release/base-files/base-files-4.0-9.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-9.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [RFU] base-files-4.0-9 [BUGFIX]
On Sun, Feb 12, 2012 at 04:10:54PM -0600, Yaakov (Cygwin/X) wrote: On Sun, 2012-02-12 at 22:49 +0100, David Sastre Medina wrote: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-9.tar.bz2 Uploaded. Should 4.0-7 and 4.0-8 be removed? Yes. Thank you. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
[ RFU ] base-files-4.0-7
Hello, Please upload base-files-4.0-7. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-7.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-7.tar.bz2.sig Thanks. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [ITP] ca-certificates
On Mon, Oct 31, 2011 at 08:58:25PM -0500, Yaakov (Cygwin/X) wrote: On Mon, 2011-10-31 at 21:06 +0100, David Sastre wrote: The cygport 'get' command failed because SRC_URI=fedora/certdata.txt fedora/blacklist.txt fedora/certdata2pem.py Is this intended? Short version: yes, because the files aren't easily wget(1)able. The files are still part of the -src tarball, of course, so this doesn't affect rebuilding from source. Also, in the 'compile' step: /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 26: ident: command not found /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 40: ident: command not found ident is part of the rcs package. I meant to say there's no build requirements list. Looks like you forgot an empty src_test(): Testing ca-certificates-1.78-1 *** ERROR: no Makefile found. You must define your own src_test(). No, there's no testsuite, but it really shouldn't be an error. Fixed in cygport master, commit db03c46. During 'install': *** Warning: Cygwin README is missing Obsolete warning, fixed in cygport master, commit 6f889ab. Thanks, GTG. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [ITP] ca-certificates
On Sun, Oct 30, 2011 at 07:19:52PM -0500, Yaakov (Cygwin/X) wrote: While we're waiting for the Tcl/Tk rebuild, with gcc-4.5 out, I can start resyncing the distro with Ports' overrides. ca-certificates contains the Certificate Authority root certificates needed for verifying SSL certificates. It is needed for updating curl and GNOME; wget can can also use it via the ca-certificate option. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/_DISTRO_/ca-certificates/ ca-certificates is already included in all major distros. Hello Yaakov, The cygport 'get' command failed because SRC_URI=fedora/certdata.txt fedora/blacklist.txt fedora/certdata2pem.py $ cygport ca-certificates-1.78-1.cygport get cp: cannot stat `fedora/certdata.txt': No such file or directory *** ERROR: Copying certdata.txt failed Is this intended? Also, in the 'compile' step: /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 26: ident: command not found /usr/src/ca-certificates-1.78-1-src/ca-certificates-1.78-1.cygport: line 40: ident: command not found Looks like you forgot an empty src_test(): Testing ca-certificates-1.78-1 *** ERROR: no Makefile found. You must define your own src_test(). During 'install': *** Warning: Cygwin README is missing -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: lost announcements
On Mon, Oct 24, 2011 at 04:16:18PM -0400, Andrew Schulman wrote: This morning I sent 4 package update announcements to cygwin-announce. Two of them (socat, lftp) were posted, but the other two (stunnel, sng) haven't shown up yet. Meanwhile, other later announcements have been posted. Are the missing messages held up in the queue? Anything I need to do about that? Or, should I resend them? Thanks, Andrew. I have received them, and they both show in the web: http://cygwin.com/ml/cygwin-announce/2011-10/msg00036.html http://cygwin.com/ml/cygwin-announce/2011-10/msg00035.html -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: lost announcements
On Mon, Oct 24, 2011 at 05:20:52PM -0400, Andrew Schulman wrote: On Mon, Oct 24, 2011 at 04:16:18PM -0400, Andrew Schulman wrote: This morning I sent 4 package update announcements to cygwin-announce. Two of them (socat, lftp) were posted, but the other two (stunnel, sng) haven't shown up yet. Meanwhile, other later announcements have been posted. Are the missing messages held up in the queue? Anything I need to do about that? Or, should I resend them? I have received them, and they both show in the web: http://cygwin.com/ml/cygwin-announce/2011-10/msg00036.html http://cygwin.com/ml/cygwin-announce/2011-10/msg00035.html Hm, you're right. But the odd thing is that they weren't posted to the cygwin list, which is where I read them: http://cygwin.com/ml/cygwin/2011-10/. Any idea why? Nope. And I'm afraid I can't help there. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: [RFU] GraphicsMagick-1.3.12-2
2011/3/23, Christopher Faylor wrote: On Wed, Mar 23, 2011 at 06:24:53AM +0100, marco atzeri wrote: On Tue, Mar 22, 2011 at 9:56 AM, Corinna Vinschen wrote: On Mar 21 22:30, marco atzeri wrote: wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/GraphicsMagick/index.html Uploaded. Hi Corinna one user find a dependency mistake for libGraphicsMagick3 -- requires: libgcc1 libstdc++6 libbz2_1 libfreetype6 libjasper1 libjbig2 libjpeg7 liblcms1 libltdl7 libpng12 libssp0 libtiff5 libwmf027 libX11_6 libXext6 libxml2 zlib0 - libjpeg7 - libjpeg8 libpng12 - libpng14 Could you amend it ? Done. I noticed that libgraphicsmagick0 is still listed as ORPHANED in cygwin-pkg-maint, but it's no longer in the distro. Can that be amended too? Thanks.
[ RFU ] base-files-4.0-6
Hello, Please upload base-files-4.0-6. It contains corrections for the errors reported regarding PRINTER setting and non-POSIX tests in /etc/profile. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-6.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-6.tar.bz2.sig Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
[ RFU ] base-files-4.0-5
Hello, Please upload base-files-4.0-5. It contains a bugfix to correct the PRINTER setting in /etc/profile. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-5.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-5.tar.bz2.sig My apologies for the misleading message to the main list, as well as not properly requesting a RFU. Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ ITA ] base-files
On Sat, Mar 12, 2011 at 10:12:01AM +0100, Corinna Vinschen wrote: On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Can versions before 3.9-3 be deleted? If this is a question for me, I think they can be safely deleted now. Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Indeed. It took so long to iron out the package that I already thought it would get the vaporware award at one point :) I'm really glad that you took over the package, David, and that you worked so diligently on it. A gold star is well deserved. Being part (even such a little one) of the awesome collective effort the cygwin project represents is the Real Gold Star I'm the recipient of. Thank You. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On Sat, Mar 05, 2011 at 05:03:37PM +, Andy Koppe wrote: The problem appears to be back: Sorry for not getting round to this sooner. Hello Andy, It should be alive again. Thanks for checking. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On Sun, Mar 06, 2011 at 07:07:18AM +, Andy Koppe wrote:
On 5 March 2011 17:03, Andy Koppe wrote:
Actually I had already downloaded this anyway. Looks great, only two
suggestions:
- Not that it makes a great difference, but I think the interactive
checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc
from /etc/profile and ~/.profile, respectively, rather than doing it
in the rc files. That would save opening the rc files in
non-interactive login shells and unnecessary checks in interactive
non-login shells.
That's true, but the check also serves the purpose of avoiding those
files to be sourced in non-interactive sesions, regardless who's
calling.
- I think the commented-out CVS stuff in /etc/profile would be better
placed in ~/.bash_profile, to allow non-admin users to uncomment it.
Or perhaps just delete it altogether; since
CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src isn't what's
recommended at http://cygwin.com/cvs.html anymore anyway.
Done. I've dropped it.
And a question:
- Can we do away with ~/.bash_profile, and move the commented-out
PATH, MANPATH, and INFOPATH setting from there into ~/.profile? I see
the latter sources .bashrc anyway for bash shells, which makes sense.
I'd rather keep .bash_profile around, because it has higher precedence in
case both files exist. Sourcing .bashrc from .profile only exists as a
fallback mechanism.
In case you are about to upload this, could you please apply this patch
to your local 4.0-3 copy?
If you think these changes deserve a release bump, I'd roll a 4.0-4
version.
Thanks!
--- a/etc/defaults/etc/profile
+++ b/etc/defaults/etc/profile
@@ -42,12 +42,6 @@ unset TEMP
read -r PRINTER '/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
PRINTER=${PRINTER%%,*}
-# It is recommended that cvs uses ssh for it's remote shell environment
-# CVS_RSH=/usr/bin/ssh
-
-# Patches to Cygwin always appreciated ;)
-# CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src
-
# Default to removing the write permission for group and other
# (files normally created with mode 777 become 755; files created with
# mode 666 become 644)
@@ -123,7 +117,7 @@ else PS1=$
fi
export PATH MANPATH INFOPATH USER PRINTER PS1 HOSTNAME
-# export TMP TEMP CVS_RSH CVSROOT
+# export TMP TEMP
# Check to see if mkpasswd/mkgroup needs to be run try and cut down the emails
# about this on the lists!
--- a/usr/share/doc/base-files/ChangeLog
+++ b/usr/share/doc/base-files/ChangeLog
@@ -15,6 +15,7 @@ Change Log
* Supressed a fork in /etc/profile routine for copying skeletal files and
added a test to `cd' command - Cyrille Lefevre
* Removed /bin from path, as it is included via /usr/bin.
+* Dropped CVS stuff from /etc/profile - Andy Koppe
4.0-2
* Never released.
* A modified version of a case switch to run shell dependent stuff based
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
Hello, I think the links to the latest revision got lost in the replies to my question about privileged users. In the meantime, the domain I was using expired. These are the valid links now: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
Hello, I have corrected some stuff in the /etc/profile reported offlist by Cyrille Lefevre and a pair of little annoyances (e.g. hostname was not referenced by its full path). I have a question yet: is there a consistent way of knowing the GID of users with administrative privileges (from a windows perspective) so that could be used to add /usr/sbin to their paths? Would that be useful? Anyway, there is a new pkg hopefully ready for release here: http://eco-lution.tv/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://eco-lution.tv/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
2011/1/11, Corinna Vinschen wrote: On Jan 10 19:40, David Sastre wrote: On Mon, Jan 10, 2011 at 06:08:06PM +0100, Corinna Vinschen wrote: On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. Why do we need them? I don't see equivalent tests on Linux... There aren't, indeed. And re-thinking the idea, those tests are not needed in any of the files but maybe in /etc/bash.bashrc, which is definitely affected by changes in this version of base-files that modify the order in which startup files are read. Its purpose would be avoiding double sourcing of a file, given the following scenario: - a user updates base-files. - base-files' preremove script keeps modified files untouched (which is the correct behaviour). - a user's modified ~./bash_profile still sources /etc/bash.bashrc, when that has already been done by new /etc/profile. One goal here is to define a SYS-level of configuration that does not rely in the existence or content of any USER-level conffile (e.g. ./bash_profile). Related to this, bash-4.1 will have SYS_BASHRC (/etc/bash.bashrc) enabled.
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
2011/1/11, jdzstz - gmail dot com : 2011/1/11 David Sastre : 2011/1/11, Christopher Faylor wrote: On Tue, Jan 11, 2011 at 07:23:45AM +0100, David Sastre wrote: On Mon, Jan 10, 2011 at 07:57:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote: OK. Please bump the cygwin package release number when you do that. Why bump the package release on something that has never been released? I think it makes sense that the first release should be -1. That's what I understand from: 2.?Do increase the version number no matter what (if upstream version didn't change, bump the Cygwin release number): even if the package was bad, even if it was removed from the server for a security issue, even if has only been discussed in mailing list and never uploaded: it costs nothing and avoids confusion in both setup.exe and people mind. The package was never on the server, i.e., it was never released. If a package ever touches cygwin.com then, yes, you have to bump the version any time you make any change no matter how tiny. I don't care if the package is released with -57 release number but I don't want it to get into the common knowledge pool that it is a requirement because it isn't. Duly noted. Thanks for the clarification. Do you want to renumber the packages to varnish-xxx-1 or I keep actual name varnish-xxx-5?? The only problem with rename is that old messages in cygwin-apps mailist can confuse in the future. Let's keep it. Thanks.
Re: [ITA] - base-files
On Mon, Jan 10, 2011 at 06:08:06PM +0100, Corinna Vinschen wrote: On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig I was trying to download the files, but I get a permanent error: Yep...the box has been down all day long. Files are available again. Sorry for the inconvenience. Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 06:12:02PM +0100, Corinna Vinschen wrote:
On Jan 9 12:58, David Sastre wrote:
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote:
Can you try installing recent Cygwin snapshot
Can you try launching only failed test r00326.vtc??
Can you send me your IPv6 error log?
CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin
I have used a modified version of c5.vtc to test IPv6 in
2.1.4-4 and 2.1.2-4.
All tests have run successfully.
David, is that a GTG? If so, I'd upload the files...
I'm waiting for Jorge to pack a version correcting the absence of
setup.hint and a README in varnish-${version}.cygwin.patch.
My apologies to both. I wasn't clear about that.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 08:07:13PM +0100, Jorge Díaz wrote:
2011/1/10 David Sastre !!: ===!!¹
On Mon, Jan 10, 2011 at 06:12:02PM +0100, Corinna Vinschen wrote:
On Jan 9 12:58, David Sastre wrote:
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote:
Can you try installing recent Cygwin snapshot
Can you try launching only failed test r00326.vtc??
Can you send me your IPv6 error log?
CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin
I have used a modified version of c5.vtc to test IPv6 in
2.1.4-4 and 2.1.2-4.
All tests have run successfully.
David, is that a GTG? If so, I'd upload the files...
I'm waiting for Jorge to pack a version correcting the absence of
setup.hint and a README in varnish-${version}.cygwin.patch.
My apologies to both. I wasn't clear about that.
I am working on it.
I have added setup.hint and README files and also made two minor changes.
I think it will be finished today.
Please http://cygwin.com/acronyms/#TOFU
and ¹http://cygwin.com/acronyms/#PCYMTNQREAIYR
OK. Please bump the cygwin package release number when you do that.
Thanks for the quick response!
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 09:43:31PM +0100, Jorge Díaz wrote: I have prepared last set of packages. - added setup.hint and README to packages Thanks. - cygport deleted /var/varnish empty dir when packing, fixed with keepdir instruction in cygport I overlooked that... - IPv6 test is enabled (c5.vtc) is passed ok (windows xp problems was caused by a machine configuration error) I see, 2.1.2-5 and 2.1.4-5 now have :: / 0 uncommented in c5.vtc test. - removed AC_DEFINE([RTLD_LOCAL], [0] from configure.ac (in cygwin 1.7.7 is not necesary) I get this to mean starting from 1.7.7 - removed a very ugly fix only for r5665 package for drand48 function (in future cygwin 1.7.8 is fixed: http://www.cygwin.com/ml/cygwin/2010-12/msg00460.html) One -really- minor annoyance (at least in win7) regarding how the test suite is executed in r5665. It looks like it runs too fast to clean /tmp properly. But issuing a quick-and-dirty: $ for a in /usr/src/varnish/varnish-r5665-5-src/varnish-r5665-5/src/varnish-cache/bin/varnishtest/tests/*vtc; do ./varnishtest $a; sleep 2; rm -rf /tmp/vtc*; done gets all of the test run successfully. GTG. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Mon, Jan 10, 2011 at 07:57:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote: OK. Please bump the cygwin package release number when you do that. Why bump the package release on something that has never been released? I think it makes sense that the first release should be -1. That's what I understand from: 2. Do increase the version number no matter what (if upstream version didn't change, bump the Cygwin release number): even if the package was bad, even if it was removed from the server for a security issue, even if has only been discussed in mailing list and never uploaded: it costs nothing and avoids confusion in both setup.exe and people mind. in http://cygwin.com/setup.html It makes sense to me regardless it is a first release or an update. Is it a wrong assumption? -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
2011/1/11, Christopher Faylor wrote: On Tue, Jan 11, 2011 at 07:23:45AM +0100, David Sastre wrote: On Mon, Jan 10, 2011 at 07:57:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2011 at 08:34:03PM +0100, David Sastre wrote: OK. Please bump the cygwin package release number when you do that. Why bump the package release on something that has never been released? I think it makes sense that the first release should be -1. That's what I understand from: 2.?Do increase the version number no matter what (if upstream version didn't change, bump the Cygwin release number): even if the package was bad, even if it was removed from the server for a security issue, even if has only been discussed in mailing list and never uploaded: it costs nothing and avoids confusion in both setup.exe and people mind. The package was never on the server, i.e., it was never released. If a package ever touches cygwin.com then, yes, you have to bump the version any time you make any change no matter how tiny. I don't care if the package is released with -57 release number but I don't want it to get into the common knowledge pool that it is a requirement because it isn't. Duly noted. Thanks for the clarification.
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Sun, Jan 09, 2011 at 04:54:26AM +0100, Jorge Díaz wrote: Can you try installing recent Cygwin snapshot Can you try launching only failed test r00326.vtc?? Can you send me your IPv6 error log? CYGWIN_NT-6.1 win7 1.7.8s(0.234/5/3) 20101229 01:34:45 i686 Cygwin I have used a modified version of c5.vtc to test IPv6 in 2.1.4-4 and 2.1.2-4. All tests have run successfully. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [Please upload] Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Fri, Jan 07, 2011 at 06:56:15PM +0100, Jorge Díaz wrote:
I have prepared a new set of packages, with some changes:
Building the packages from source works OK, but setup.hint and a README file
should have been included in varnish-${VERSION}.cygwin.patch.
You can let cygport generate that patch by manually copying both files into
varnish-${VERSION}/CYGWIN-PATCHES/ when you build it the first time.
There is a template for the README here¹.
Some tests are failing in 2.1.4-4-src and r5665-4, most of them because /tmp
is failing to get cleaned properly:
rm: cannot remove `/tmp/vtc.3468.0ae6ed42/v1': Device or resource busy
Assert error in tst_cb(),
/usr/src/varnish/varnish-r5665-4-src/varnish-r5665-4/src/varnish-cache/bin/varnishtest/vtc_main.c
line 194:
Condition((system(buf)) == 0) not true.
make[2]: *** [check] Aborted (core dumped)
(The stackdump is an empty file)
$ ls -lrt /tmp/
total 0
drwx--+ 1 dawud None 0 Jan 8 19:55 vtc.3468.4ce835d3/
drwx--+ 1 dawud None 0 Jan 8 19:55 vtc.3468.0ae6ed42/
There are other errors as well:
### v1 CLI connection fd = 5
### v1 CLI RX 107
v1 CLI RX| iqvdmjmzgcpenunnblmauaiwxenptrtd\n
v1 CLI RX| \n
v1 CLI RX| Authentication required.\n
v1 CLI TX| auth
f5a6c3eaf76b5bffd27bb5ca8e6ba116a0a868fdee08c914dd0af69268cad153\n
### v1 CLI RX 200
v1 CLI RX| -\n
v1 CLI RX| Varnish HTTP accelerator CLI.\n
v1 CLI RX| -\n
v1 CLI RX|
CYGWIN_NT-6.1,1.7.7(0.230/5/3),i686,-sfile,-hcritbit\n
v1 CLI RX| \n
v1 CLI RX| Type 'help' for command list.\n
v1 CLI RX| Type 'quit' to close CLI session.\n
v1 CLI RX| Type 'start' to launch worker process.\n
v1 CLI TX| vcl.inline vcl1 backend s1 { .host = \127.0.0.1\;
.port = \49841\; }\n\n\tsub vcl_fetch {\n\t\tesi;\n\t}\n
### v1 CLI RX 106
v1 CLI RX| Message from C-compiler:\n
v1 CLI RX| collect2: vfork: Resource temporarily unavailable\n
v1 CLI RX| Running C-compiler failed, exit 1\n
v1 CLI RX| VCL compilation failed
v1 FAIL VCL does not compile
#top Test timed out
##top TEST
#
/usr/src/varnish/varnish-2.1.4-4-src/varnish-2.1.4-4/src/varnish-2.1.4/bin/varnishtest/tests/r00326.vtc
#FAILED
#rm: cannot remove `/tmp/vtc.3380.6b8b4567/v1': Device or resource
#busy
#Assert error in main(),
#
/usr/src/varnish/varnish-2.1.4-4-src/varnish-2.1.4-4/src/varnish-2.1.4/bin/varnishtest/vtc.c
#line 682:
# Condition((system(cmd)) == 0) not true.
# /bin/sh: line 5: 3380 Aborted (core dumped)
# ./varnishtest ${dir}$tst
# FAIL:
#
/usr/src/varnish/varnish-2.1.4-4-src/varnish-2.1.4-4/src/varnish-2.1.4/bin/varnishtest/tests/r00326.vtc
Modifying c5.vtc to test IPv6 results in an error, too.
I'd rather send the check-logs to you off-list if you need them, or better yet,
you could try to reproduce it locally.
¹http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/packaging/templates/generic-readme?content-type=text/plaincvsroot=cygwin-apps
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On Sun, Dec 19, 2010 at 05:20:14PM +, Andy Koppe wrote: On 14 December 2010 20:41, David Sastre wrote: On Fri, Dec 10, 2010 at 06:50:32AM +, Andy Koppe wrote: I'll try selective sourcing from /etc/profile e.g. bash sources *sh, and not *.zsh, and viceversa. Done. On a related note, due to the many possible combinations of old and new startup files, double sourcing is a distinct possibility, e.g. due to the current /etc/defaults/etc/skel/.bash_profile sourcing /etc/bash.bashrc. Perhaps this should be addressed with guard variables similar to include guards in C headers? Done. I learnt that enabling /etc/bash.bashrc to be sourced as a system-wide *rc file can be defined in a header file in the bash sources, and also /etc/bash.bash_logout, BTW. Forthcoming bash-4.1 will have SYS_BASHRC and SYS_BASH_LOGOUT enabled. Wasn't there a patch for doing that switch without forks? Found it. Daniel Colascione suggested the following at http://cygwin.com/ml/cygwin/2010-11/msg00464.html: - Detect the current shell by examining BASH_VERSION, ZSH_VERSION, and so on, not by forking for the echo|tr|sed pipeline Done. New package available at: http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2 http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2.sig Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: Fwd: [ITP] varnish-2.1.4-1 and varnish-r5665
On Behalf Of David Sastre Sent: viernes, 31 de diciembre de 2010 14:19 Subject: Re: [ITP] varnish-2.1.4-1 and varnish-r5665 On Thu, Dec 30, 2010 at 06:52:32PM +0100, Jorge Díaz wrote: I have prepared two packages: * Current: varnish 2.1.4-1 = last released version, 2.1.4 * Test: varnish r5665 = subversion trunk r5665 version Varnish cygwin patched source version can be compiled succesfully in Linux and Solaris. I have tested the package listed above in a CYGWIN_NT-6.1 win7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Varnish fails to compile due to curses.h not being found: Also, many tests failed: On Mon, Jan 03, 2011 at 11:34:01AM +0100, Jorge Díaz wrote: I have fixed the package problems reported by David. * Curses library problem (error: curses.h: No such file or directory) This problem is explained in: http://cygwin.com/ml/cygwin/2010-05/msg00397.html for some reason, my Cygwin environment retained old links from /usr/include to /usr/include/ncurses, so compiled OK, but newer installations had problems. I have added -I/usr/include/ncurses to CFLAGS and now it works fine. * Test problems. Varnish compiles VCL file to DLL using GCC. I think the problem is that GCC does not find libraries when Varnish is not installed because only searchs in /usr/lib (my PC had a copy there). I have fixed GCC compilation command, so it try to use /usr/lib and after searchs in compilation dir. The fixed packages (varnish-2.1.4-1 and varnish-r5665) can be downloaded from sourceforge: New packages build fine. Tests now run OK, too. Setup.hint looks good. I've tried a very simple config to access an apache backend running on another host, and also tested the web interface and some of the utilities. I havent tried advanced setups, though. All my tests have been run using r5665. Everything seems to work properly so far. I've noticed that 2.1.4 is still experimental in Debian, and available for RHEL6 beta, Mandriva devel cooker and Fedora Core 15. But it is also available as updates for Fedora 13/14, so unless anybody else has an objection, it would be GTG for me. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITP] varnish-2.1.4-1 and varnish-r5665
On Thu, Dec 30, 2010 at 06:52:32PM +0100, Jorge Díaz wrote:
I have prepared two packages:
* Current: varnish 2.1.4-1 = last released version, 2.1.4
* Test: varnish r5665 = subversion trunk r5665 version
The packages can be downloaded from sourceforge:
wget
http://downloads.sourceforge.net/project/cygvarnish/cygwin-varnish%20package/varnish-2.1.4-1-src.tar.bz2
Varnish cygwin patched source version can be compiled succesfully in
Linux and Solaris.
Hello,
I have tested the package listed above in a
CYGWIN_NT-6.1 win7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
Varnish fails to compile due to curses.h not being found:
checking for library containing initscr... -lcurses
varnishhist.c:39:20: error: curses.h: No such file or
directory
Also, many tests failed:
Assert error in main(), vtc.c line 682:
Condition((system(cmd)) == 0) not true.
/bin/sh: line 5: 3368 Aborted (core dumped)
./varnishtest ${dir}$tst
FAIL: ./tests/b00027.vtc
v1 FAIL VCL does not compile
Varnish need GCC in runtime because its VCL configuration file is
translated to C and compiled in so file in order to better
performance.
Varnish also needs Libpcre and Libncurses.
All dependencies (both for building and runtime) seem to be installed:
Cygwin Package Information
Package VersionStatus
libncurses-devel 5.7-18 OK
libncurses10 5.7-18 OK
libncursesw-devel5.7-18 OK
libncursesw105.7-18 OK
ncurses 5.7-18 OK
ncursesw 5.7-18 OK
libpcre-devel8.02-1 OK
libpcre0 8.02-1 OK
libpcrecpp-devel 8.02-1 OK
libpcrecpp0 8.02-1 OK
gcc 3.4.4-999 OK
In addition to the patch provided in the src package, I included the
attached changes. The build succeeded, but tests are failing anyway.
Regards.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
diff -Nrup varnish-2.1.4.patched.orig/Makefile.am varnish-2.1.4.patched.new/Makefile.am
--- varnish-2.1.4.patched.orig/Makefile.am 2010-10-21 10:57:22.0 +0200
+++ varnish-2.1.4.patched.new/Makefile.am 2010-12-30 03:06:32.0 +0100
@@ -3,7 +3,7 @@
SUBDIRS = include lib bin man etc doc
SUBDIRS += redhat
-
+ACLOCAL_AMFLAGS = -I m4
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = varnishapi.pc
diff -Nrup varnish-2.1.4.patched.orig/bin/varnishhist/varnishhist.c varnish-2.1.4.patched.new/bin/varnishhist/varnishhist.c
--- varnish-2.1.4.patched.orig/bin/varnishhist/varnishhist.c 2010-10-21 10:57:22.0 +0200
+++ varnish-2.1.4.patched.new/bin/varnishhist/varnishhist.c 2010-12-31 13:34:30.09320 +0100
@@ -36,7 +36,7 @@
SVNID($Id: varnishhist.c 4093 2009-06-06 15:56:17Z des $)
#include sys/types.h
-#include curses.h
+#include ncursesw/curses.h
#include errno.h
#include limits.h
#include math.h
diff -Nrup varnish-2.1.4.patched.orig/bin/varnishsizes/varnishsizes.c varnish-2.1.4.patched.new/bin/varnishsizes/varnishsizes.c
--- varnish-2.1.4.patched.orig/bin/varnishsizes/varnishsizes.c 2010-10-21 10:57:22.0 +0200
+++ varnish-2.1.4.patched.new/bin/varnishsizes/varnishsizes.c 2010-12-31 13:34:30.09320 +0100
@@ -36,7 +36,7 @@
SVNID($Id: varnishsizes.c 4709 2010-04-21 10:40:27Z tfheen $)
#include sys/types.h
-#include curses.h
+#include ncursesw/curses.h
#include errno.h
#include limits.h
#include math.h
diff -Nrup varnish-2.1.4.patched.orig/bin/varnishstat/varnishstat.c varnish-2.1.4.patched.new/bin/varnishstat/varnishstat.c
--- varnish-2.1.4.patched.orig/bin/varnishstat/varnishstat.c 2010-10-21 10:57:22.0 +0200
+++ varnish-2.1.4.patched.new/bin/varnishstat/varnishstat.c 2010-12-31 13:34:30.09320 +0100
@@ -37,7 +37,7 @@ SVNID($Id: varnishstat.c 4553 2010-02-1
#include sys/time.h
-#include curses.h
+#include ncursesw/curses.h
#include errno.h
#include limits.h
#include signal.h
diff -Nrup varnish-2.1.4.patched.orig/bin/varnishtop/varnishtop.c varnish-2.1.4.patched.new/bin/varnishtop/varnishtop.c
--- varnish-2.1.4.patched.orig/bin/varnishtop/varnishtop.c 2010-10-21 10:57:22.0 +0200
+++ varnish-2.1.4.patched.new/bin/varnishtop/varnishtop.c 2010-12-31 13:34:30.09320 +0100
@@ -36,7 +36,7 @@
SVNID($Id: varnishtop.c 5150 2010-08-30 12:01:05Z tfheen $)
#include ctype.h
-#include curses.h
+#include ncursesw/curses.h
#include errno.h
#include pthread.h
#include signal.h
diff -Nrup varnish-2.1.4.patched.orig/configure.ac varnish-2.1.4.patched.new/configure.ac
--- varnish-2.1.4.patched.orig/configure.ac 2010-12-30 13:33:44.0 +0100
+++ varnish-2.1.4.patched.new/configure.ac 2010-12-30 13:33:44.0 +0100
@@ -8,7 +8,7 @@ AC_REVISION([$Id: configure.ac 5443 2010
AC_INIT([Varnish], [2.1.4], [varnish-...@varnish-cache.org])
AC_CONFIG_SRCDIR(include/varnishapi.h)
AM_CONFIG_HEADER(config.h)
-
+AC_CONFIG_MACRO_DIR([m4])
AC_CANONICAL_SYSTEM
Re: [ITA] - base-files
On Fri, Dec 10, 2010 at 06:50:32AM +, Andy Koppe wrote:
On 10 December 2010 00:05, David Sastre wrote:
Speaking of /etc/profile.d, it seems wrong to do that from
/etc/bash.bashrc. The name of the directory suggests that its content
is for login shells only.
Absolutely. I'll try selective sourcing from /etc/profile e.g. bash sources
*sh, and not *.zsh, and viceversa.
A bash login shell only
automatically sources the *profile files, not the *bashrc files. Users
have every right to customise their ~/.bash_profile and ~/.bashrc to
death, or to just delete them. Or perhaps they didn't have them in the
first place because they nominated an existing directory as their home
without copying the skel files. So there's no guarantee that ~/.bashrc
and /etc/bash.bashrc are sourced by a bash login shell.
This is important. The conclusion of this reasoning is that users'
personal files (~/.bash{rc,_profile}) shouldn't be trusted at all in
order to define a system-wide configuration. That's what happens both in my
proposal and in the current base-files. (See below for a possible solution)
That's true. Unless sourced from /etc/profile. Would that be
acceptable?
I think that would make sense, but it should only do so when the shell
is an interactive login shell. Here's how to find out:
http://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html
If you propose to check for *i* in $- instead of PS1 (as I'm doing now),
yeah, it does look more reliable.
Zsh sources *profile files in login shells and the *zshrc files in
interactive shells, so an interactive login shell sources both.
Not in bash. This is an example of a login shell. I have commented out
the code that sources /etc/bash.bashrc and ~/.bashrc from
~/.bash_profile:
$ grep MY_TEST /etc/profile /etc/bash.bashrc .bashrc .bash_profile
/etc/profile:MY_TEST=${MY_TEST}:/etc/profile
/etc/bash.bashrc:MY_TEST=${MY_TEST}:/etc/bash.bashrc
.bashrc:MY_TEST=${MY_TEST}:~/.bashrc
.bash_profile:MY_TEST=${MY_TEST}:~/.bash_profile
$ echo $MY_TEST
:/etc/profile:/home/dawud/.bash_profile
$ echo $-
himBH
(Erm...I just realized know that was _exactly_ your point, was it?)
Hence
stuff that needs to be done once at login (e.g. setting up paths) goes
into *profile, and stuff to make an interactive shell comfortable
(e.g. prompt and aliases) goes into *zshrc. I think that makes plenty
of sense.
It does, indeed.
Bash isn't going to change in this respect though, so emulating it by
/etc/profile sourcing /etc/bash.bashrc and ~/.bash_profile sourcing
~/.bashrc is the next best thing.
I learnt that enabling /etc/bash.bashrc to be sourced as a system-wide *rc
file can be defined in a header file in the bash sources, and also
/etc/bash.bash_logout, BTW.
I'm sending a request to enable both of them to the bash mantainer;
if he agrees to include them, it would be easier for me to define
a system-wide configuration layer that doesn't interfere with (neither
depend on) users' custom files, and also, presumably, allows smoother updates
from there on.
- There must be a switch for bash/mksh/*
Wasn't there a patch for doing that switch without forks?
Not that I know of... I'll try to write it down, though.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
[ ATTN : bash mantainer ] Request to enable sys-wide conffiles
Hello, Regarding the ITA of base-files, I'm trying to define a consistent, system-wide configuration that doesn't need to rely in user-defined files, as it's currently made, and at the same time, avoid as much as possible to source some conf files from others. I think that this could be achieved easier if /etc/bash.bashrc were enabled at compile-time. A trivial patch to do that is attached. It would enable both SYS_BASHRC and SYS_BASH_LOGOUT. I'd appreciate if this changes were kindly taken into consideration. Also, I've seen that SSH_SOURCE_BASH is defined in bash-3.2.51-24.src.patch, but access through ssh with a bash shell as login shell doesn't seem to source ~/.bashrc. One related question: if SYS_BASHRC were enabled, would SSH_SOURCE_BASHRC try to source /etc/bash.bashrc or ~/.bashrc? The coment in config-top.h only mentions the latter. (This is just curiosity) Thanks and regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB --- config-top.h.orig 2010-12-13 21:23:31.0 +0100 +++ config-top.h 2010-12-13 21:24:05.0 +0100 @@ -73,10 +73,10 @@ #define KSH_COMPATIBLE_SELECT /* System-wide .bashrc file for interactive shells. */ -/* #define SYS_BASHRC /etc/bash.bashrc */ +#define SYS_BASHRC /etc/bash.bashrc /* System-wide .bash_logout for login shells. */ -/* #define SYS_BASH_LOGOUT /etc/bash.bash_logout */ +#define SYS_BASH_LOGOUT /etc/bash.bash_logout /* Define this to make non-interactive shells begun with argv[0][0] == '-' run the startup files when not in posix mode. */ signature.asc Description: Digital signature
Re: [ITA] - base-files
On Thu, Dec 09, 2010 at 09:59:32AM -0800, Karl M wrote:
Date: Thu, 9 Dec 2010 12:04:39 +
From: andy
On 9 December 2010 06:29, David Sastre wrote:
On Wed, Dec 08, 2010 at 11:21:38PM +, Andy Koppe wrote:
On 8 December 2010 21:22, David Sastre wrote:
I have decided to pull out of /etc/profile the case switch that tries
to detect the shell and sets PS1 (and HOSTNAME) accordingly.
That's not going to work for people whose .bash_profile and .bashrc
don't adhere to that pattern or who don't have those files for
whatever reason, i.e. they'll suddenly get the default $ prompt.
Hang on, /etc/bash.bashrc isn't an official bash startup file, is it?
Nope. It is not listed as such in the GNU Bash manual, but it does exist in
RHEL as /etc/bashrc and in debian as /etc/bash.bashrc, like in cygwin BTW.
The bash man page in debian even lists /etc/bash.bashrc as a startup
file (and it's actually read before ~/.bashrc). So, yes, you are right.
And in the case some people don't use this layout, well, AFAICT, if
they don't use the default, they are supposed to know what they're
doing, right?
Sure, but that doesn't mean that breaking existing setups that don't
follow the /etc/skel layout is a good idea. I'd expect lots of
questions about how to fix the prompt.
I fail to see how any customised setup would end up broken.
The skeletal files are copied to the user's $HOME only if $HOME
doesn't exist and they are never overwritten nor updated; the installation of
a new base-files package places its defaults in /etc/default/etc and does not
touch anything that may have been modified by the user in /etc/skel.
And given that critical files will be detected as modified (even if
they are not) because of the cmp line in preremove, existing files
remain untouched and new files end up in /etc/default/etc.
That's the point I was trying to make. A bash login shell only
automatically sources the *profile files, not the *bashrc files. Users
have every right to customise their ~/.bash_profile and ~/.bashrc to
death, or to just delete them. Or perhaps they didn't have them in the
first place because they nominated an existing directory as their home
without copying the skel files. So there's no guarantee that ~/.bashrc
and /etc/bash.bashrc are sourced by a bash login shell.
That's true. Unless sourced from /etc/profile. Would that be
acceptable? Debian proposes this in its /etc/bash.bashrc.
(now I wonder if that's a patch in Debian, a compile-time option for
bash, or what...)
The whole thing would be:
- /etc/profile is the login entry-point for everybody
- There must be a switch for bash/mksh/* (again, but...)
- The switch sources the corresponding /etc/${SHELL}rc
- Afterwards, it will read ~/.*profile automatically, so we don't
depend on ~/.bash_profile to have /etc/bash.bashrc sourced.
- Interactive non-login access uses ~/.${SHELL}rc
- There we source /etc/${SHELL}rc. Here, if the line sourcing
/etc/bash.bashrc is removed, you're on your own.
(and we wouldn't depend on ~/.bashrc either if the actual order was
/etc/bash.bashrc - ~/.bashrc. It's starting to make sense that
debian stuff...)
This requires minimal changes to the existing proposal, and still
solves a pair of annoyances. Opinions?
But do we have to provide backward compatibility for user modified startup
files?
I don't think we should. I don't even think we could. As I said above, user's
customised environments should have their base-files packages updated
transparently.
Only new users, new installations, and manual intervention should ever notice
the changes.
Can't we provide an efficient set of defaults that play together nicely with
no redundancy and then let the user hack from there?
I hope so :)
Again, thanks for taking the time to review this.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On Fri, Dec 10, 2010 at 01:05:44AM +0100, David Sastre wrote: And given that critical files will be detected as modified (even if they are not) because of the cmp line in preremove, existing files remain untouched and new files end up in /etc/default/etc. Scratch that. Preremove can't do that kind of sorcery. It is PRE remove... (and it's triggered _before_ installing anything...) It looks like /etc/bash.bashrc and /etc/profile deserve some special treatment. The rest of the reasoning is still valid, I think. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
from this URL:
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2.sig
md5sums:
ff8000e0c128c9a7732d17c5eaace129 base-files-4.0-1.tar.bz2
bcdea646fcf7038f0796c68838759829 base-files-4.0-1.tar.bz2.sig
Setup.hint is unchanged.
I'd like to explain the most important change I've made, and also the
purpose of that change.
I have decided to pull out of /etc/profile the case switch that tries
to detect the shell and sets PS1 (and HOSTNAME) accordingly.
The reason for this change is that all of bash, mksh, zsh and tcsh, provide
their own files for doing that job. The result is a lighter /etc/profile
that sets a minimun PS1='$ ' that will be used by posh and dash (the only
two shells in the repo that lack specific startup files), allowing shells
that do have that files to alter this setting(s).
Notice that neither posh nor mksh, despite being ksh derivatives, read
/etc/ksh.kshrc nor ~/.kshrc.
(I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not)
BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc
BI!L= /etc/bash.bashrc - ~/.bashrc
ML= /etc/profile - ~/.mkshrc - /etc/mkshrc
MI!L= ~/.mkshrc - /etc/mkshrc
OL= /etc/profile - ~/.profile (as of now, /etc/profile is not
posh-compatible!!)
ZLZI!L= Well... the startup routines for zsh are complicated enough to let
the end
users craft their own environment (IMHO).
It's in the system-wide /etc/${SHELL}rc where PS1 and HOSTNAME are defined
now (overriding the /etc/profile default). Also, the logic that sources
/etc/profile.d/ scripts will be included there, to avoid the current situation,
where /etc/profile sources everything under /etc/profile.d, regardless
the calling shell (bash sources /etc/profile.d/*.zsh)
This changes solve the reported bug about interactive shells with a
non-interactive ancestor presenting an unset PS1 prompt.
The bug was reported regarding bash, but this logic should apply to
every shell now.
Also, the reported bug about mksh not having a well-defined PS1 can
be considered solved, since mksh will set its own PS1 in /etc/mkshrc,
sourced by ~/.mkshrc. For completeness, a skeleletal .mkshrc is provided
now which sources a system-wide /etc/mkshrc. Should that file be provided
by the mksh mantainer and installed in /etc/defaults/etc/mkshrc ?
As of now, this is the panorama: three shells offer a default system-wide rc
file in their packages, dash and posh won't use it and bash's is included in
base-files, though only two of them install it per default (tcsh and bash).
It would be better if all shells unify their criteria regarding this.
$ cygcheck -l zsh mksh tcsh dash posh bash | grep rc$
/usr/share/doc/mksh/examples/dot.mkshrc
/etc/defaults/etc/csh.cshrc
/usr/share/doc/zsh-4.3.10/StartupFiles/etc/zshrc
All changes (and bugfixes) included in this release are detailed in the
ChangeLog.
Whilst I've tried to be thorough, there are probably errors/bugs, so
I'd appreciate any testing people can give to this, in order to find
them. TIA, and sorry for the long post.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On Wed, Dec 08, 2010 at 11:21:38PM +, Andy Koppe wrote:
On 8 December 2010 21:22, David Sastre wrote:
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
I'm afraid there's a syntax error in /etc/profile though:
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]
That's missing a ; then.
Oops, it looks like I only corrected that in my win7 box and that never made it
to my git repo.
(git newbie here, you've been warned! O:-) )
da...@win7 ~
$ grep elif /etc/profile
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]; then
(...and now, I'll have to check for other differences :-D)
Also, indentation is rather wonky, due to a mix of tabs and spaces.
You appear to be using a tab size of 2?
Yep. Sorry for that. It was invisible to me... I'll correct this ASAP.
I have decided to pull out of /etc/profile the case switch that tries
to detect the shell and sets PS1 (and HOSTNAME) accordingly.
The reason for this change is that all of bash, mksh, zsh and tcsh, provide
their own files for doing that job. The result is a lighter /etc/profile
that sets a minimun PS1='$ ' that will be used by posh and dash (the only
two shells in the repo that lack specific startup files), allowing shells
that do have that files to alter this setting(s).
Notice that neither posh nor mksh, despite being ksh derivatives, read
/etc/ksh.kshrc nor ~/.kshrc.
(I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not)
BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc
That's not going to work for people whose .bash_profile and .bashrc
don't adhere to that pattern or who don't have those files for
whatever reason, i.e. they'll suddenly get the default $ prompt.
BI!L= /etc/bash.bashrc - ~/.bashrc
Doesn't /etc/bash.bashrc end up being sourced twice here, due to
~/.bashrc including it.
As far as I tested, it doesn't. It happens like I described above.
I'll repeat the tests, though.
FYI, the way I did it was placing a line like this:
TEST_RC=$TEST_RC:/name/of/the/file
in every startup file, and echeoing the var after opening the shell,
both interactive-login and interactive non-login.
And in the case some peolple don't use this layout, well, AFAICT, if
they don't use the default, they are supposed to know what they're
doing, right? And this is the default currently (3.9-3).
I think your startup file list should distinguish between files that
are automatically sourced by the shell and those that are sourced by
other startup files.
All of those files are automatically sourced, depending on the shell
being a login shel or an interactive shell. That's exactly what I'm
trying to get advantage of. To be fair, in the case of a login shell,
we force the course of things, but also does ~/.bash_profile in 3.9-3.
Regarding the ChangeLog:
* New file: skel/.bash_logout: clear the screen after logout.
Why is that necessary? Do other systems do that?
It's not necessary. Just a nice(?) touch. IIRC, RHEL does.
Andy
Thanks you for your time.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On Wed, Dec 08, 2010 at 11:21:38PM +, Andy Koppe wrote:
On 8 December 2010 21:22, David Sastre wrote:
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
from this URL:
I'm afraid there's a syntax error in /etc/profile though:
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]
That's missing a ; then.
Corrected. New files and md5sums:
1ccd796eb9f1406806f75c624ba287c5 base-files-4.0-1.tar.bz2
6802a8d33ad4effdecd3c130a4982d70 base-files-4.0-1.tar.bz2.sig
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2.sig
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: Unbelievably obscure setup bug
On Sat, Nov 20, 2010 at 11:04:02AM +0100, Corinna Vinschen wrote: On Nov 19 19:13, David Sastre wrote: Is there a chance that this bug provides an opportunity to merge base-files and base-passwd? I was told it was difficult (or at least not recommended) because of a dependency chain issue. Please excuse me if this is non-sense. It's not. But it would make much more sense to combine base-cygwin and base-passwd. Base-files is pretty low priority in the dependency order, in contrast to the other two. If we combine base-cygwin and base-passwd into one, we would have one less problem. I volunteer to combine them into a single base-cygwin package, if nobody knows a good reason why the functionality should stay separated. David, would you like to take over base-files? It's still officially orphaned... I'll pack a release during next week. Thanks for being patience, though (not much spare time these days...) -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: Unbelievably obscure setup bug
On Fri, Nov 19, 2010 at 06:11:57PM +0100, Corinna Vinschen wrote: On Nov 19 10:15, Christopher Faylor wrote: On Fri, Nov 19, 2010 at 02:20:13PM +, Jon TURNEY wrote: On 19/11/2010 13:36, Corinna Vinschen wrote: On Nov 19 13:23, Jon TURNEY wrote: On 19/11/2010 13:13, Corinna Vinschen wrote: The code in question was supposed to make sure that the order is always base-cygwin base-passwd [...] and that was the case so far. Of course, given the obvious mishandling of the casecompare return value it's not clear why this ever worked. Even more mysterious is the fact that the bugfix *breaks* this order. Well, time to debug... Well, the bugfix breaks the order because visit() on base-cygwin inserts it and all it's dependencies depth-first (ignoring loops). In theory base-cygwin has no dependecies. Here are the setup.hint snippets: base-cygwin: category: Base base-passwd: requires: base-cygwin category: Base noautodep: cygwin cygwin: requires: base-passwd base-cygwin noautodep: _update-info-dir I think that explains it. The problem in base-cygwin is that it depends on cygwin since the noautodep: cygwin is missing. So there's a dependency chain which goes base-cygwin - cygwin - base-passwd. That's how this order is generated. If we add noautodep: cygwin to base-cygwin, it would really have no dependency and should always become the first package. I wasn't aware of the existence of noautodep. Now it all makes sense :-) I believe that I actually added this so that we wouldn't need to special-case packages in setup. For some reason, even if I remove the cygwin dependency from base-cygwin in setup.ini, I still get the base-passwd cygwin base-cygwin dependency order. Hmm. EMBI, Is there a chance that this bug provides an opportunity to merge base-files and base-passwd? I was told it was difficult (or at least not recommended) because of a dependency chain issue. Please excuse me if this is non-sense. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITP] Onigurama-5.9.2
On Thu, Sep 16, 2010 at 08:12:48PM +, Marco Atzeri wrote: --- Gio 16/9/10, David Sastre ha scritto: On Thu, Sep 16, 2010 at 10:08:54AM +, Marco Atzeri wrote: Hi thinking about packaging slrn I decided to start from its dependency Oniguruma - S-lang - slrn Just in case it could be useful in any way, I've attached a cygport file for S-Lang. AFAICT, it builds and works OK. The only thing to care about is building with -j1, otherwise it fails. David, I guess you are using a patched version of s-lang, but your source is not reachable cygport slang-2.2.2-1.cygport almostall Preparing slang-2.2.2-1 *** ERROR: Cannot find source package slang-2.2.2.tar.bz2 Weird... Wait a second...I know what has happened. You need to get the source first. :-) $ cygport slang-2.2.2-1.cygport get prep --2010-09-17 10:32:13-- ftp://space.mit.edu/pub/davis/slang/v2.2/slang-2.2.2.tar.bz2 = `slang-2.2.2.tar.bz2.tmp' Resolving space.mit.edu (space.mit.edu)... 18.75.0.10 Connecting to space.mit.edu (space.mit.edu)|18.75.0.10|:21... connected. Logging in as anonymous ... Logged in! == SYST ... done.== PWD ... done. == TYPE I ... done. == CWD (1) /pub/davis/slang/v2.2 ... done. == SIZE slang-2.2.2.tar.bz2 ... 1366850 == PASV ... done.== RETR slang-2.2.2.tar.bz2 ... done. Length: 1366850 (1.3M) (unauthoritative) 100%[] 1,366,850387K/s in 3.9s 2010-09-17 10:32:20 (339 KB/s) - `slang-2.2.2.tar.bz2.tmp' saved [1366850] Preparing slang-2.2.2-1 Unpacking source slang-2.2.2.tar.bz2 Preparing working source directory *** Info: applying patch slang-2.2.2-1.cygwin.patch: patching file CYGWIN-PATCHES/devel.hint patching file CYGWIN-PATCHES/modules.hint patching file CYGWIN-PATCHES/runtime.hint patching file CYGWIN-PATCHES/setup.hint patching file CYGWIN-PATCHES/shell.hint patching file CYGWIN-PATCHES/slang.README For what I saw s-lang is built by every distribution with a long list of patches I overlooked that... and moreover I hate a package that use autoconf and does not allow to build in a separate directory from source. My source Aesthetics asks me to make some autoconf/automake cleaning, and to build in a separate directory. I hope it will not take too long. Agree. I wasn't smart enough to do that either. I'm looking forward to see S-Lang in the distro! Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
[ITA] - base-files base-passwd
Hello,
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
1 http://sourceware.org/ml/cygwin/2010-04/msg00521.html
case sensitivity of system32 dir (win7 and vista)
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
1 This is a simple fix, so it'd be applied.
2 This could be solved by redefinig the skeletal files for every shell
(more below).
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
What do you people think?
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
TIA for the feedback.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files base-passwd
On Fri, Sep 17, 2010 at 04:50:40PM +0200, Corinna Vinschen wrote:
On Sep 17 13:59, David Sastre wrote:
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash
shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
Tcsh is somewhat different from the other shells because it's using
an entirly different script syntax.
WHat's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
Absolutely nothing is wrong with the patch. I'm only thinking about
an unified method for supplying skeletal files, regardless the
shell. I mean, currently /etc/profile includes logic to deal with all kinds
of shells; being mksh an example, a /etc/skel/.mkshrc could be supplied,
to source a system-wide /etc/mkshrc provided by the mksh package,
this is a simplified example taken from Debian:
case $KSH_VERSION in
*MIRBSD\ KSH*) ;;
*) return 0 ;;
esac
[[ -s /etc/mkshrc ]] . /etc/mkshrc
This would be my solution to nº2 and nº3 above, i.e. PS1 is correctly
set and inherited, because every shell that needs it, provides a
system-wide *rc file to set PS1 and HOSTNAME, distributed with that
shell's package.
I think this is positive because it frees /etc/profile from a work
that can be done by the shells on-demand. Base-files would only
provide /etc/defaults/etc/skel/.${SHELL}rc files to source
/etc/${SHELL}rc, installed by the packages, unneeded otherwise.
BTW, mksh is the only *ksh shell in the distro, being pdksh orphaned
and unmaintained upstream.
Also, I am curious to know if there is a reason why
/etc/defaults/etc/profile.d/lang.csh is not included in tcsh.
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
I agree with Chris. Let's keep them separate. I can imagine that the
process to create default /etc/passwd and /etc/group files might change
in the future (more intelligent, no such files at all, you name it), and
there's no reason to change base-files in that case.
OK. No problem.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
It's good enough for a start. If we come up with a better solution,
we can still change it, right?
All right.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITP] Onigurama-5.9.2
On Thu, Sep 16, 2010 at 10:08:54AM +, Marco Atzeri wrote:
Hi
thinking about packaging slrn I decided to start
from its dependency
Oniguruma - S-lang - slrn
Just in case it could be useful in any way, I've attached a
cygport file for S-Lang. AFAICT, it builds and works OK.
The only thing to care about is building with -j1, otherwise it
fails.
Regards.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
DESCRIPTION=multi-platform programmer's library
SRC_URI=ftp://space.mit.edu/pub/davis/slang/v2.2/${P}.tar.bz2;
HOMEPAGE=http://www.s-lang.org/;
NO_AUTOHEADER=true
CYGCONF_ARGS=--with-x --with-pcre --with-onig
--with-png --with-z --with-iconv
--with-readline=gnu
MAKEOPTS+= -j1
PKG_NAMES=${PN} slsh lib${PN}2 lib${PN}2-devel lib${PN}2-modules
PKG_HINTS=setup shell runtime devel modules
DIFF_EXCLUDES=Makefile slang.pc src/sysconf.h
slsh_CONTENTS=etc/slsh.rc usr/bin/slsh.exe
usr/share/doc/slsh/
usr/share/man/man1/
usr/share/slsh/
libslang2_CONTENTS=usr/bin/libslang2.dll
usr/share/doc/slang/v2/
usr/share/doc/Cygwin/slang.README
usr/share/doc/slang/CHANGES.txt
usr/share/doc/slang/COPYING
usr/share/doc/slang/NEWS
usr/share/doc/slang/README
libslang2_devel_CONTENTS=usr/include/
usr/lib/libslang.dll.a
usr/lib/pkgconfig/
libslang2_modules_CONTENTS=usr/lib/slang/v2/modules
src_compile() {
cd ${S}
cygconf
cygmake
}
src_test() {
:
}
src_install() {
cd ${S}
cyginstall
make distclean
}
signature.asc
Description: Digital signature
Re: Up for new maintainer - base-files and base-passwd
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote: Hi John, On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. I've been unable to find sufficient time to do these packages justice a situation which is unlikely to improve at this time. The source for the packages is the package itself. I have a small set of automations for building (replacing version numbers etc) which I will happily give to the new maintainer, but I have not created a cygport package for it. I am not going to unsubscribe from the lists nor stop answering questions. I've enjoyed the time I've spent on this project and wish it well. I'm sorry to read that. Thanks for the time and effort you invested into these packages. Since you're not mentioning units, does that mean you keep up maintainership for this package? Other than that, is anybody willing to take over maintainership of base-passwd and/or base-files? While the base-passwd file is relatively uncritical, especially the base-files package needs some work, to pick up the stray bits of problems we collected over the time. Anybody willing to take over a few bash scripts? I'd like to do that. Is there a detailed list of things to correct in the base-files package? Or should I look for that info in the archives? Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
[RFU] makeself-2.1.5-2
Hello, Please upload: wget http://eco-lution.tv/cygwin/release/makeself/makeself-2.1.5-2-src.tar.bz2 wget http://eco-lution.tv/cygwin/release/makeself/makeself-2.1.5-2.tar.bz2 Regards.
Re: [ITP] makeself-2.1.5
Hello, And there's really no reason to repeat the RFU mail *every* day. Sorry for that. I suppossed the subject was wrong (ITP instead of RFU) and could have been unnoticed. Thanks and regards.
