Re: [ITA] - base-files
Hi David, I've not had chance to install this but I have pulled and taken a look. May I be (amongst) the first to thank you for the work you've put into this. Regards, John.
Re: Up for new maintainer - base-files and base-passwd
Hi, On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote: Hi John, Thanks for the time and effort you invested into these packages. Thanks to you (and Chris) for putting so much effort in. I only wish I had the time and skills to help more. I learnt a lot from the Cygwin project and it was a definate shove to moving (at home at least) to a 100% *nix base. Since you're not mentioning units, does that mean you keep up maintainership for this package? There is now a cygport script for it (thanks Yaakov) so it takes very very little time. J.
Re: Up for new maintainer - base-files and base-passwd (gold star)
On Tue, September 14, 2010 6:49 pm, Andrew Schulman wrote: Gold watch awarded: http://cygwin.com/goldstars/#JM . Awesome. Thanks Andrew. I was hoping that you'd take the challenge of delivering on a gold watch. No image is too great to scale here at cygwin.com. Thankyou :) I'll appreciate it always. J.
Up for new maintainer - base-files and base-passwd
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. Regards, John.
Re: [Setup] Need customization on setup.exe
On Thu, May 6, 2010 5:35 pm, Krishna Achugatla wrote: On 6 May 2010 08:59, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, May 06, 2010 at 08:18:34AM -0700, Krishna Achugatla wrote: Currently we have windows installer to install Symbian developer tools. Size of the tools are huge and want to improve on the installer. Cygwin installer is best fit for our need, like download the light weight installer and then download all the user selected components under the hood from network. Following are the requirements of our project 1) Clone the setup.exe project and customize it 2)?Symbian logo in the installer, instead of a Cygiwn logo 3) Have our own categories like Build, Test, Analysis, etc 4) Need to access multiple mirror locations, as few components will be hosted by Nokia and few components will be hosted by Symbian 5) Customized?End-user license agreement (EULA). Pls let us know, is it possible to have the requirements mentioned above as part of Cygwin setup.exe project. If you are asking for us to do the above work for you (which you probably aren't) then the answer is a resounding NO. If you're asking if the above is possible then, except for 5) the answer is an obvious yes. �It's just software after all. You can't slap your own EULA on the code. �This is GPLed code. �If you distribute the binary, you need to also be able to send people the source code. �You can't put your own license on it. If you decide to go ahead with this, it probably goes without saying that we won't be interested in supporting your efforts here. �I don't believe that anyone is going to want to help you customize setup.exe in this manner but, if they do, it isn't really an appropriate subject for the Cygwin mailing lists since this would not really have anything to do with Cygwin. cgf Hi Christopher, Thank you very much the quick reply. Sorry for the confusion. We will make all the required changes to Setup. But was interested to know the required changes are possible or not. With you reply, all (except 5) are possible as it's just a software after all. Probably, we need your support in making a clone of the Setup, so that we can make required changes on top of it. Please let us know the procedure to have a clone of the Setup project?. FYI: I was able to successfully build the sources of Setup that I got using CVS. Regards, Krishna. I read 5 as being a EULA for the software that the modified setup would _install_ rather than an EULA for setup itself. Christopher, in this case is 5 still not possible (assuming that none of the software the modified setup installs goes against the EULA?) BTW, Krishna, this list usually bottom posts ;)
Re: [UPLOAD] base-files 3.9-1
On Sat, December 5, 2009 9:10 pm, Corinna Vinschen wrote: In /etc/postinstall/base-files-mketc.sh.done, please remove... Done. http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.9-2.tar.bz2 md5sum: a698f1bbda5270df30bc2d892821b12f Incase they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint J.
[UPLOAD] base-files 3.9-1
Change Log -- 3.9-1 * Set LANG scripts in /etc/profile.d/ - Corinna Vinschen, Thomas Wolff, Christopher Faylor * Unset TMP and TEMP in ~/.bashrc - Angelo Graziosi, Robert Pendell, Ken Brown, Corinna Vinschen http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.9-1.tar.bz2 md5sum: 97b88867e26e36bc52d0ce890996b9d2 Incase they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint Thanks, J. PS, TODO: * Remove X11R6 from $PATH when there are no packages remaining which require it - Angelo Graziosi If somebody can keep and eye on the packages and tell me when it's no longer required I'd appreciate it. PPS, Corinna you did the last modifications (3.8-4), which I think were just permission changes? Could you please check that I duplicated them in my copy of the code base? Thanks, appreciate it.
Re: [UPDATE] base-passwd (Was Re: base-passwd sets weird permissions)
Sorry. Please revert and I'll try and find the time tonight to do it again. J.
Re: [UPDATE] base-passwd (Was Re: base-passwd sets weird permissions)
On Mon, May 11, 2009 12:26 pm, Corinna Vinschen wrote: On May 11 11:47, John Morrison wrote: Sorry. Please revert and I'll try and find the time tonight to do it again. I uploaded a fixed 3.1-1 package instead. I hope you don't mind. Nope, heck you know more about what it does than I do! J.
[UPDATE] base-passwd (Was Re: base-passwd sets weird permissions)
Hi Corinna, Patch applied... md5sum for base-passwd-3.0-1.tar.bz2 479cb2a678f712b326dc09a24d329cfe http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/base-passwd-3.0-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/md5sum (not changed...) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/setup.hint Let me know if there are any issues :) J. On Wed, April 22, 2009 8:02 pm, Corinna Vinschen wrote: Hi John, I just realized that the paswd-grp.sh postinstall script in the base-passwd package sets unsecure permissions on /etc/passwd and /etc/group. Is there any good reason to chmod 777 these files? I don't see any, especially not execute permission. chmod 644 would be the correct setting, afaics. We can also get rid of the sed calls to remove the line with :S-1-1-0: from passwd and group. These entries aren't generated for many many years. Last but not least, the file group should be set to the Administrators group by default. I would like to suggest the following patch: --- passwd-grp.sh.ORIG2009-04-22 20:44:42.521387200 +0200 +++ passwd-grp.sh 2009-04-22 20:59:04.167788000 +0200 @@ -1,24 +1,27 @@ #!/bin/sh +created_passwd=no +created_group=no + if [ ! -e /etc/passwd -a ! -L /etc/passwd ] ; then /bin/mkpasswd -l -c /etc/passwd - /bin/chmod 777 /etc/passwd + /bin/chmod 644 /etc/passwd + created_passwd=yes fi if [ ! -e /etc/group -a ! -L /etc/group ] ; then /bin/mkgroup -l -c /etc/group - /bin/chmod 777 /etc/group + /bin/chmod 644 /etc/group + created_group=yes fi -cp -f /etc/passwd /tmp/passwd.mkpasswd \ -( [ -w /etc/passwd ] || chmod --silent a+w /etc/passwd ; ) \ -sed -e '/:S-1-1-0:/d' /tmp/passwd.mkpasswd /etc/passwd \ -chmod --silent --reference=/etc/group /etc/passwd -rm -f /tmp/passwd.mkpasswd - -cp -f /etc/group /tmp/group.mkgroup \ +cp -fp /etc/group /tmp/group.mkgroup \ ( [ -w /etc/group ] || chmod --silent a+w /etc/group ; ) \ echo root:S-1-5-32-544:0: /etc/group \ -sed -e '/:S-1-1-0:/d' -e '/root:S-1-5-32-544:0:/d' /tmp/group.mkgroup /etc/group \ +sed -e '/root:S-1-5-32-544:0:/d' /tmp/group.mkgroup /etc/group \ chmod --silent --reference=/etc/passwd /etc/group rm -f /tmp/group.mkgroup + +# Deferred to be sure root group entry exists +[ $created_passwd = yes ] /bin/chgrp --silent root /etc/passwd +[ $created_group = yes ] /bin/chgrp --silent root /etc/group Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] [1.7] Base-Files 3.8-2
On Sun, Feb 15, 2009 at 11:59:37AM -, John Morrison wrote: Er, John, I'm sure you really know how to look at the cygwin-announce mailing list archives right? http://cygwin.com/ml/cygwin-announce/2009-02/ Sorry Chris, I've been (a little) out of touch with the cygwin stuff for a while... but it looks like I need to patch it anyway before the announcement. I've not upgraded these packages in, err, years! J.
[RFU] [1.7] Base-Files 3.8-3 (was 3.8-2)
Change Log -- 3.8-3 * Ensure that the destination directory exists during postinstall - Yitzchak Scott-Thoennes http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.8-3.tar.bz2 md5sum: 600a176402bd3f9659433cffd1d71aa0 In case they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint wget http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.8-3.tar.bz2 J.
Re: [RFU] [1.7] Base-Files 3.8-2
Uploaded. Thanks Corinna. Do we do anouncements for 1.7 packages yet and are they done/marked/prefixed differently from 1.5s? J.
[RFU] [1.7] Base-Files
I've updated this with the patch from Herb Maeder (thanks Herb, sorry it took me so long!). I propose leaving the 1.5 as is and just go forward with 1.7. Change Log -- 3.8-1 * Update to Cygwin 1.7 version - Herb Maeder http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.8-1.tar.bz2 md5sum: 22c52ca0ce75300138860b8c16e7bdc5 Incase they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint wget http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.8-1.tar.bz2 if [ `md5sum.exe base-files-3.8-1.tar.bz2 | cut -b -32` != 22c52ca0ce75300138860b8c16e7bdc5 ] ; then echo Download error ; else echo Download validated ; fi J.
Re: [RFU] [1.7] Base-Files
| I've updated this with the patch from Herb Maeder (thanks Herb, sorry it
| took me so long!). I propose leaving the 1.5 as is and just go forward
| with 1.7.
John,
/etc/profile contains
if [ ! -d ${HOME} ]; then
mkdir -p ${HOME}
echo Copying skeleton files.
The skeleton files are copied even if the the mkdir has failed.
This happens to network users who install Cygwin while connected, with
HOME on a
network drive, and then later use their laptop while disconnected.
In that case the skeleton files should not be copied, a warning should be
issued and HOME should
be set to /tmp, $TEMP or some such. It's straightforward and I would be
happy to provide a
patch if you wish.
Thanks
Pierre
Patch would be appreciated, thanks Pierre; I've not got an environment
which could test that.
J.
Re: [RFU] [1.7] Base-Files
- Original Message -
From: John Morrison
To: Pierre A. Humblet
Sent: Friday, February 13, 2009 1:09 PM
Subject: Re: [RFU] [1.7] Base-Files
|
| Patch would be appreciated, thanks Pierre; I've not got an environment
| which could test that.
Here it is,
+ { [ -d $TEMP ] HOME=$TMP; } || { [ -d /tmp ]
HOME=/tmp; } || HOME=/
Did you mean to test for $TEMP then use $TMP? If not, is...
if [ ! -d ${HOME} ]; then
if mkdir -p ${HOME}; then
echo Copying skeleton files.
echo These files are for the user to personalise their
cygwin experience.
echo
echo They will never be overwritten nor automatically
updated.
echo
cd /etc/skel
/bin/find . -type f | while read f; do
fDest=`echo ${f} | sed -e 's/^\.//g'`
if [ ! -e ${HOME}${fDest} -a ! -L
${HOME}${fDest} ]; then
/usr/bin/install -D -p -v ${f}
${HOME}/${fDest}
fi
done
else
echo ${HOME} could not be created.
{ [ -d ${TEMP} ] HOME=${TEMP}; } ||
{ [ -d ${TMP} ] HOME=${TMP}; } ||
{ [ -d /tmp ] HOME=/tmp; } ||
HOME=/
echo Setting HOME to ${HOME}.
fi
fi
OK?
J.
Re: [RFU] [1.7] Base-Files 3.8-2
Change Log
--
3.8-2
* The skeleton files are copied even if the the mkdir has
failed. This happens to network users who install Cygwin while
connected, with HOME on a network drive, and then later use their
laptop while disconnected. In that case the skeleton files are not
copied, a warning issued and HOME set to ${TEMP}, ${TMP}, /tmp,
or (finally) / - Pierre A. Humblet
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.8-2.tar.bz2
md5sum: 600a176402bd3f9659433cffd1d71aa0
Incase they're wanted...
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
wget
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.8-2.tar.bz2
if [ `md5sum.exe base-files-3.8-2.tar.bz2 | cut -b -32` !=
600a176402bd3f9659433cffd1d71aa0 ] ; then echo Download error ; else
echo Download validated ; fi
J.
Re: base-passwd: postinstall script too open permissions
On Wed, August 20, 2008 9:14 am, Corinna Vinschen wrote: Hi John, do you remember the reason why the passwd-grp.sh postinstall script calls chmod 777 /etc/passwd chmod 777 /etc/group ? That's not right, IMO. The permissions should rather be 644 and not allow writing for everyone. Along the same lines, the `chmod a+w' calls in the second half of the script should better just be `chmod u+w'. Would you mind to change that, please? Sure, although it might be tomorrow night before I get time. What were the changes you made to the setup.hint for base-[file/passwd] btw? J.
Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
On Tue, July 29, 2008 12:37 pm, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/28/2008 9:27 AM: | # check the window size after each command and, if necessary, | # update the values of LINES and COLUMNS. | shopt -s checkwinsize | | would it work in cygwin? Also; | | Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric? Hmm. Right now, bash _does_ set LINES and COLUMNS (as shell variables, you have to export them for children to see), but only after the first SIGWINCH, or if you have 'shopt -s checkwinsize', after the first non-builtin-command (ie. if checkwinsize is set, bash does not check window size after builtins - how weird is that?). At any rate, I already have a cygwin-specific patch for the upstream bug that lib/sh/winsize.c forgot to include termios.h. And blindly setting checkwinsize seems like it would slow things down: since SIGWINCH works (I tested in both cmd and urxvt), there is no need to slow down bash to check window size after every single command, when only window size changes are necessary. checkwinsize is primarily for those platforms that lack SIGWINCH. At any rate, you've given me an idea. Add this to /etc/profile, and $LINES and $COLUMNS will be automatically populated for all users, regardless of whether they use 'shopt -s checkwinsize': kill -s WINCH $$ Hi Eric, So, let me get this straight, you _don't_ want/need me to add the shopt but you would like me to add the kill instruction? J.
Package Grep source and Program not installed functionality
Hi All, Would it be possible to extend the cgi http://cygwin.com/cgi-bin2/package-grep.cgi to (optionally) output plain text instead of the formatted HTML? Add a output=text instruction? If the source is available I'd be willing to see if I could do the mod. I was thinking of some kind of command line which would simplify the users finding out what package they would need to install to access a particular tool, for example on my ubuntu machine; [EMAIL PROTECTED]:~$ gedit The program 'gedit' is currently not installed. You can install it by typing: sudo apt-get install gedit bash: gedit: command not found Perhaps the cygwin version could be [EMAIL PROTECTED]:~$ curl The program 'curl' is currently not installed. You can install it from the following package(s); curl/curl-7.15.1-1 command line tool for transferring files with HTTP, HTTPS, FTP, etc. curl/curl-7.15.4-1 command line tool for transferring files with HTTP, HTTPS, FTP, etc. curl/curl-7.16.3-1 command line tool for transferring files with HTTP, HTTPS, FTP, etc. where the tool could use the package-grep.cgi?output=textgrep=/curl.exe I don't know how the instruction get's fired, is there something in bash which says run this if you don't find a program? What do you folks think? Doable? Useful? John.
Re: base-[files|password] for 1.7
On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote: On Jul 29 10:31, Christopher Faylor wrote: On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote: Chris, is there any good reason NOT to call send_winch_maybe on a key event? It only makes sense when there is a mouse event. I don't understand that. Mouse events typically don't happen. I can use the mouse as much as I want in a console window running vim, vim never gets the SIGWINCH. It would make more sense to move the handling of SIGWINCH into the signal handler so that the above works transparently. I'll look into doing that. That would be a nice addition. So I don't need to add anything to /etc/profile? J.
Re: Package Grep source and Program not installed functionality
On Tue, July 29, 2008 3:13 pm, Brian Dessent wrote: John Morrison wrote: Would it be possible to extend the cgi http://cygwin.com/cgi-bin2/package-grep.cgi to (optionally) output plain text instead of the formatted HTML? Add a output=text instruction? If the source is available I'd be willing to see if I could do the mod. I was thinking of some kind of command line which would simplify the users finding out what package they would need to install to access a particular tool, for example on my ubuntu machine; This already exists, it's spelled cygcheck -p. I didn't know. Thanks for the sarcasm. God I'd forgotten just how nasty this list can be. And all for wanting to make cygwin a 'nicer' environment for new/inexperienced users. J.
base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
You can now call mkpasswd and mkgroup without any -l or -d parameter
and both tools choose by themselves what information to print, depending
on the machine being a domain member machine or not.
This should result in a matching change to the base-passwd package for
1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
without any parameter.
Could you please change that for us, John?
Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
parameters when calling mkpasswd and mkgroup. I've left the rest of the
script the same; that's OK?
Do we still want the base-files profile to have the message wrt group
names of mkpassword/mkgroup/mkgroup_l_d?
Are there any other changes wanted? For example, I think a comment about
MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time
to alter anything. Corinna; you use the tcsh shell don't you (I seem to
recall)? Are there any profile defaults we should put in for it?
I've added a few licenses; AFL (1.1, 1.2, 2.0, 2.1), Apache (1.0, 1.1,
2.0), Artistic (1, 2), BSD, GPL (2.0, 3.0), LGPL (2.0, 3.0), MIT, PHP (3).
Are there any others folks would like?
Is there anything more base-[files|password] could do for users?
My Debian /etc/profile sets EDITOR=vim useful? (not if you've not
installed vim I suppose; vi?)
/etc/bash.bashrc has the following in both Debian and Ubuntu (not a
suprise I suppose);
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
would it work in cygwin? Also;
# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- $1
return $?
else
return 127
fi
}
fi
could we do something similar? (Although, I wouldn't want to bring python
into base if I could help it) /usr/lib/command-no-found is a python
script as well.
Should we have a /etc/motd? (not that I know what should calls/displays
it in the cygwin env; /etc/profile?)
I'll package and upload tomorrow evening if nobody has any improvements.
J.
Re: New Cygwin 1.7.0-18 in release-2
On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote: On Jul 23 21:44, John Morrison wrote: On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote: I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. I think that'll probably alter once there's a setup for 1.7. Speaking personally I *need* my installation of cygwin and couldn't stand to be without it. (I will get 'round to patching the base packages, but I was/did hand these over to Igor; is he still around?) Igor is still around, yes. I didn't know (or forgot again) you handed over maintainership of the base packages. Igor? X under 1.7 is a requirement for me. Just wish I had the skills to get the latest version working. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. Once X works, that works for me :) Why is X so important for testing and building packages? testing and building no, but I suspect that for most maintainers (at least those with only one or two packages) the package is a 'thank you' back to cygwin for the environment so the stability of the environment is very important. I know that's why I started with the base- packages, 'cause I wanted to improve the 'out of the box' experience. I mean, the console window and rxvt exist, right? Personally I'm doing a lot in my Linux X console, connecting to my Windows machines via rdesktop and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in different directories, there should be no problem running 1.7 based rxvt/xterm in a 1.5 X server. I didn't know that. (attempting to find some time!) Please with sugar? I only have windows at work now and all my time is 'allocated' to projects... trying! If I don't get it done before the weekend I'll get a virtual machine running. Promise. J.
Re: setup.hints which mention Base in their category
On Thu, July 5, 2007 11:28 am, Corinna Vinschen wrote: John, any problem to update the units package to the latest 1.86 version? Hi Corinna, Sorry, missed this thread - no problem afaik; I'm afraid I probably won't be able to do this before next weekend though. I'll also look at upgrading the package mechanism to cygport while I'm at it. J.
Re: RFC: X11R7 transition
On Tue, June 13, 2006 12:58 am, Yaakov S (Cygwin Ports) wrote: 4) Post my .cygport and patches for xorg-server to the cygwin-xfree list, so that others will be able to help. In the meantime, other packages should be converted to modular dependencies, etc. Do you want to post the .cygport/patches? I can't promise to help, but you'll at least stand a better chance of *somebody* helping... J.
Re: [ITP] PHP 5.1.4 (cli, cgi-fcgi, apache2)
On Sun, June 4, 2006 1:42 pm, Max Bowsher wrote: I now have a PHP package which builds in a manner I think is adequate for release. I still haven't addressed the matter of loadable extensions, so it is mandatory to install postgresql to install PHP at all, but given the regular interest in PHP shown on the cygwin ML, I think people are going to willingly put up with that, to avoid having to build PHP itself. Hi Max, Sorry this reply took so long, I was away last week and busy with work yesterday. The installation of PHP went cleanly, and adding the appropriate lines to the apache config was OK (although either changing the default so they are there but commented out or adding them to the php-apache.README would be useful). This appeared to be all that was necessary for php in Apache to work - thanks. As you pointed out, postgresql is a prereq, but I have to say it isn't the easiest thing in the world to configure! (It could do with a -config script ala sshd-host-config). But that shouldn't stand in the way of you releasing this package esp since the meer presence of postgresql is enough to run php. Thanks again, J.
Re: Apache Tomcat / Tomcat based apps
On Sun, May 21, 2006 9:06 pm, Joshua Daniel Franklin wrote:
On Sun, 21 May 2006, Christopher Molnar wrote:
I would like to find out if it is possible to create a
dependency in a package on the sun java sdk. For example the default
install of Java 1.5 from Sun uses a home directory of:
/cygdrive/c/Program\ Files/Java/jdk1.5.0_06 , so keying on the
presence of that directory is a good bet Java is installed with the
correct version.
There's always the registry key...
JAVA_SDK_VERSION=`cat
/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java\ Development\
Kit/CurrentVersion`
JAVA_JRE_VERSION=`cat
/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java\ Runtime\
Environment/CurrentVersion`
export JAVA_HOME=`cat
/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java\ Development\
Kit/${JAVA_JRE_VERSION}/JavaHome`
export PATH=$PATH:$JAVA_HOME/bin
used to work for me (I don't have Java installed atm (new machine)).
J.
Re: ITP: checkx-0.1.0-1
Charles Wilson wrote: checkx does not yet have a home for ongoing development, save my hard drive, so there's no upstream site, and obviously there are no Linux distributions which include it. Therefore, I need some votes in favor... +1. John.
Re: [Maybe-ITP] PHP
On Thu, April 27, 2006 5:57 pm, Max Bowsher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Please, that would be most appreciated. The 'limitations' arn't really very bad :) J.
Re: [ITP] quilt-0.43 -- Tool to work with series of patches
On Wed, February 8, 2006 2:02 pm, Igor Peshansky wrote: On Tue, 7 Feb 2006, Brian Dessent wrote: [snip] The postinstall/preremove system seems unnecessarily complex. It includes nearly 250 lines of shell script and two manifests to do what could be accomplished simply with: [ ! -f /etc/quilt.quiltrc ] \ cp /etc/defaults/etc/quilt.quiltrc /etc/quilt.quiltrc and cmp -s /etc/defaults/etc/quilt.quiltrc /etc/quilt.quiltrc \ rm -f /etc/quilt.quiltrc ...and by locating the default quiltrc file under /etc/defaults instead of stashed away in /usr/share/doc/quilt-VER/examples/quilt.quiltrc and requiring all that scripting to locate. Do we already have a package (like _update-info-dir) that takes care of moving everything from /etc/defaults to the intended locations? If not, would such a package be useful (so that you can simply add /etc/defaults/pkg.pkgrc, and then depend on that script)? Maybe fold the functionality right into _update-info-dir (since so many packages already depend on it)? I may be misremembering, and something like this may already exist, in which case I'll crawl back under my rock. Not as far as I know - it was proposed when base-files started using /etc/defaults, but it never got written. J.
Re: upstream update nitify [Was: maybe-ITP: bsdiff]
On Fri, January 27, 2006 11:16 pm, Lapo Luchini wrote: John Morrison wrote: Freshmeat do a number of RSS feeds see http://freshmeat.net/backend/ for the list. Mhh, neat. Problem is: freshmeat is not /always/ updated. How about http://distrowatch.com/news/dwp.xml? or scraping http://distrowatch.com/packages.php? rsync, as an example, is at release 2.6.0, while truly it is a 2.6.6 last time I (manually) checked. Distrowatch reports 2.6.6 Perhaps http://rss.freshmeat.net/freshmeat/feeds/fm-releases-unix would be the best? Can perl consume RSS feeds? IMHO the best is to stick with the URL+regular expression form: it an RSS is available it's only easier to parse (less thing on the page that may falsely match the r.e.) While using the official homepage: http://rsync.samba.org/ % links -source http://rsync.samba.org/; | egrep -o [0-9]+\.[0-9]+\.[0-9]+ released | head -n 1 2.6.6 released Parsing the FTP directory would be even less error-prone, if available. Uhm... an approach like this can't as reliable as being the final anwer to update notifications, but IMHO can surely help. More so if each package has /more/ than one address (frashmeat, homepage, ftp) so that if some of the sources fail or change format, the others are still up (a different page could show red lines in the ones that failed to parse the last few days, something like that). My approach to that would probably include PHP and a sqlite database. If there is some interest in it I could develop and mantain it. Fair enough - I never (well, rarely!) argue with somebody who's willing to put the effort in :) J.
Re: maybe-ITP: bsdiff
On Fri, January 27, 2006 4:13 pm, Christopher Faylor wrote: On Fri, Jan 27, 2006 at 02:21:44PM +0100, Lapo Luchini wrote: What do you (all) think about it? Many years ago, I wrote a perl script which queried ftp sites looking for new versions of packages. It required constant tinkering since the sites came and went and the directories on the sites were often renamed arbitrarily. Maybe just monitoring some site like freshmeat would be enough nowadays, though. cgf Freshmeat do a number of RSS feeds see http://freshmeat.net/backend/ for the list. Perhaps http://rss.freshmeat.net/freshmeat/feeds/fm-releases-unix would be the best? Can perl consume RSS feeds? J.
Re: [UPLOAD] Base-files 3.7-1
On Thu, January 26, 2006 1:36 pm, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John Morrison on 1/25/2006 1:55 PM: http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.7-1.tar.bz2 md5sum: 4000a7079f671732128e1f1be4e4147c Uploaded, and I removed 3.4-2 and 3.5-1. You might want to release a -2 soon that addresses Igor's finding about finding but not executing symlinks in /etc/profile.d. Your email to cygwin-announce should have waited until you saw this email that your package was actually uploaded. Humm, sorry, that must have been a typo - I'd have sworn that I sent it to cygwin-apps. J.
[UPLOAD] Base-files 3.7-1
The important thing in this release is that /etc/defaults/etc/DIR_COLORS has been moved into the coreutils-5.93-3 Change Log -- 3.7-1 * Additional (commented out) settings taken from http://www.ukuug.org/events/linux2003/papers/bash_tips/index.html - Append history rather than overwrite - Append whenever displaying the prompt - 'Magic' Space. Inserts a space character and performs a history expansion in the line - Ignore small typos when cd'ing * Corrected settitle() function in .bashrc - Igor Peshansky * DIR_COLORS moved to the coreutils package - Eric Blake * Follow links in /etc/profile.d - Max Bowsher http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.7-1.tar.bz2 md5sum: 4000a7079f671732128e1f1be4e4147c Incase they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint Thanks, J.
Re: Updated: coreutils-5.93-2 [Attn base-files maintainer]
On Sat, January 21, 2006 3:31 pm, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John Morrison on 1/21/2006 8:12 AM: A new release of coreutils, 5.93-2, is available for use, replacing 5.3.0-9. base-files now needs to be updated to use these new features in /etc/defaults/etc/DIR_COLORS. I suggest using dircolors -p as a starting point. Do you think that this would be better in the bash package? If not, I'm quite willing to update the file using dircolors -p, but I'll prob not tweak them from whatever comes out... I think it would be fair for me to release coreutils-5.93-3 with /etc/DIR_COLORS belonging to the coreutils package instead of base-files. Sorry - wrong package! That way, whenever the syntax accepted by dircolors changes in coreutils releases, DIR_COLORS would automatically track it without your help. I don't mind maintaining it, but agree that it would be easier/quicker than its current location. But that means we will need to coordinate the upload, so that the window of time between when base-files removes the file and coreutils supplies the file is minimized. Agreed. I'll probably have a new package prepared by tonight, but to be on the safe side, how about if, in the [UPLOAD] request we ask that it not be done until the other package upload request is sent? I'll do a new release of base-files quite soon, Igor has sent me a change too. John. PS, hope it was OK to take this off list. Reply to the list if it wasn't. Because it involves a package release timing coordination, cygwin-apps was probably the appropriate list. Ok. Replied there. John.
Re: Please *wait* before sending cygwin-announce messages
Just as a thought, could the announcement be a text file contained in the package? That could be extracted by upset(?) and sent when it detects the new version? This would have the benefits that 1) the GTG could check for its existance 2) the email would never be sent until the package was available 3) folks shouldn't forget to send the email (the only thing that they might forget to do is update it) 4) the text file could be appended with the unsubscribe information before it was sent. 5) the package script (sorry Igor can't remember what it's called atm) could either check for its existance or create a stub or... something automated ;) I know that it'd mean changing some programs/scripts (esp upset) but what do you think to the idea? J.
Re: RFC on packaging of additional Apache2 modules
On Fri, November 25, 2005 6:08 am, Igor Pechtchanski wrote: On Thu, 24 Nov 2005, Max Bowsher wrote: I'm preparing a new Apache 2 release, and want to include a conf.d arrangement to allow additional module packagess to install configuration fragments in a useful way. So far, my tentative proposal is: Include /etc/apache2/conf.d/*.conf in httpd.conf. Have module packages install config fragments to /etc/apache2/conf-std.d/, and copy them insto conf.d if no equivalent exists. This is consistent with the way the package currently handles httpd.conf, etc. I'm posting here for input before I go ahead and do it. The above sounds fine, but why not use /etc/defaults/etc/apache2/conf.d/ instead of /etc/apache2/conf-std.d/? Igor That's amost the same as Debian is doing (the only linux I'm running atm)... /etc/apache2/apache2.conf / some standard apache config stuff then lines to include... # Include module configuration: Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf # Include all the user configurations: Include /etc/apache2/httpd.conf # Include ports listing Include /etc/apache2/ports.conf # Include generic snippets of statements Include /etc/apache2/conf.d/[^.#]* /etc/apache2/conf.d/ / site specific config files (I think) /etc/apache2/envvars / any standard vars (I've not got any) /etc/apache2/httpd.conf / this file is basically empty too /etc/apache2/magic / usual magic instructions /etc/apache2/mods-available/ / contains *all* known module information /etc/apache2/mods-enabled/ / contains links to the modules in mods-available you want to use /etc/apache2/ports.conf / just a listen 80 instruction here! /etc/apache2/README / Huh, think you can guess ;) /etc/apache2/sites-available/ / contains all sites you might want this installation of apache to host /etc/apache2/sites-enabled/ / links to the sites to you want to enable from sites-available /etc/apache2/ssl / ssl files Hope this helps. J. PS, I agree with Igor, untar the installation files into /etc/defaults/etc/apache2/... and postinstall copy as appropriate :)
Re: RFC: [ITP] Installation Profiles packages
On Wed, November 9, 2005 9:31 am, Corinna Vinschen wrote: On Nov 8 18:13, Igor Pechtchanski wrote: On Tue, 8 Nov 2005, Christopher Faylor wrote: On Tue, Nov 08, 2005 at 01:52:20PM -0500, Igor Pechtchanski wrote: IMO, these packages should be in a special new category (I propose the name @Profiles to make setup put this at the top, but I don't know if setup will parse this correctly). I've attached a few sample profile packages for commonly requested configurations with the corresponding setup.hints. We could probably concentrate them all in one directory (thus the '@ ...' lines at the top of the hint files). All the .tar.bz2 files are the same empty tarball -- it's the setup.hints that are important. Comments and other suggestions welcome. Note that the attached packages are an initial cut at defining those profiles -- I'm bound to have missed something. Also, I'm not proposing to maintain *all* of the profiles, though I could maintain the ones I've attached, as there isn't too much work involved. Assuming that Corinna agrees, I'm willing to put these in a directory in release. I like the idea. I'd like to get some consensus on the name Profiles, though. Is that adequately intuitive? That's one of the things I wanted suggestions on. The main problem is to get the user to notice that this is something special. I had a long hard look into the chooser window and it's not only that this meta category should come first, it should also be an eye catcher by its own, IMHO. Therefore I'd like to propose an all uppercase name for this category. DEFAULT-PROFILES USER-PROFILES +1 on the caps... How about FUNCTIONAL-[GROUPS|PROFILES] USEFUL-[GROUPS|PROFILES] PRESELECTED-[GROUPS|PROFILES|PACKAGES] ? J.
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Tue, September 27, 2005 6:18 am, Christopher Faylor wrote: On Mon, Sep 26, 2005 at 11:19:36PM -0400, Charles Wilson wrote: Christopher Faylor wrote: There is no clear maintainer. I was asking if you'd be interested in making this available via ncurses. If you release a new version of ncurses which contributes a 'clear', I'll delete the clear package. I've got a new release of ncurses which contains /usr/bin/clear.exe ready to go (but not yet copied into /release). Go ahead an put an empty clear package up on sources (clear-1.0-2 ?) and we'll let that propagate, and then I'll move my new ncurses over to release/. I know that there was some talk of releasing an empty clear package but I don't see how that would be useful. If I do that then we stand the chance of eliminating clear.exe when the clear package is updated, meaning that we could conceivably remove the clear.exe that ncurses installed. I think the only thing we can do is remove clear from the distribution. cgf How about making the new (obsolete) clear package depend on ncurses? Would that force people to upgrade? J.
Re: Musings on PHP
On Sun, September 18, 2005 10:05 pm, Max Bowsher wrote: I personally have no need for PHP, but I know it's a very widely used piece of software. After John Morrison's recent mention of PHP in passing, I decided to do a quick estimate of how difficult getting PHP working on Cygwin would be. To cut a long story short, I got a bit carried away, and now have a functional apache2 php5 module. Wow! Thanks Max - I really didn't expect you to go to this much trouble! I can't help with the questions you asked, but I just wanted you to know that I'm appreciative of all the effort you've put in. J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sun, September 18, 2005 10:14 pm, Corinna Vinschen wrote: On Sep 18 11:12, John Morrison wrote: On Sat, September 17, 2005 2:35 pm, Corinna Vinschen wrote: I'm wondering if base-files can't check if /etc/profile has been changed, for instance, using md5sum. Then it could overwrite the file if it's still the original version, or, if it has been changed, move it away to, for instance, /etc/profile.SAV or something. The preremove part of base-files could be modified to rename any of the files that have been modified (if they haven't then they are deleted ready for the post-install routine to install new versions) - although I don't know if it's desirable behaviour. I'm not sure if I'd be terribly happy to have cygwin just rename my customisations out of the way, would be *highly* confusing the first (at least!) time it happened... That shouldn't be the rule, maybe. But our current layoput has the obvious disadvantage that important changes to default config files in a lot of cases don't make it into the users system in some way. Humm, playing devils advocate for a minute - but if a user is happy with the system they've got (perhaps by tweaking files themselves) - is it the systems job to force them to update? In rpm, there's a mechanism which allows the package maintainer to define the changes as so important, that rpm moves the old file out of the way (renaimg it to foo.oldrpm or something like that), installs the new file and sends a mail to root about this. I don't think we can send emails - lots of people (myself included) don't have email setup to work under cygwin. Personally, I like the Debian way of saying that somethings changed and would the user like to view differences, ignore, merge, overwrite etc (or whatever's appropriate). But am unsure as to how to get this to work when it'd have to be negotiated between setup.exe and the post-install scripts... How about using the return value to flag setup. Setup could then, for example, display a special 'log' file - or, if the file exists perhaps /etc/profile could cat it then delete it? Something like this is definitely missing in our technique, that's why I was trying to start a discussion about this. Sorry, think my reply came across a bit grumpy - not intended! OTOH, I guess there are a lots of people not changing the files in /etc, using always the default files. In these cases, a mechanism which allows to recognize these files as being the genuin one would be helpful, wouldn't it? It would allow to simply overwrite them, so the users would get the latest changes without hassle. If the file hasn't been modified it is deleted by the pre-remove script, the copy in /etc/defaults is overwritten by setup.exe and the post-install script copies missing files. At least that's how base-files works. I did have a conversation, oh a year or more ago now, with cfg to see if we could manage /etc/defaults automatically with one central script, but we couldn't work out how to get it to work consistently. *grin* at this rate how long do you think before cygwin counts as a complete 'distro'? J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sat, September 17, 2005 2:35 pm, Corinna Vinschen wrote:
On Sep 17 07:19, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Max Bowsher on 9/16/2005 4:27 PM:
The current /etc/profile does not permit the use of symlinks in
/etc/profile.d/ - it ignores them.
Unfortunately, even if this was fixed in the package, existing
installs
wouldn't get fixed, because /etc/profile is handled via /etc/defaults
:-(
/me gives up on finding a way for /sbin/alternatives to influence
$MANPATH.
Here's my idea - add a /etc/profile/symlinkhandler.sh that detects
whether
/etc/profile has been patched yet, and if not, source all the symlinks
in
/etc/profile. Now which package should provide that (alternatives vs.
base-files vs. something else), I'm not sure. But you are also right
that
base-files should be patched to source links to regular files as well as
regular files. One idea is to change that the appropriate line in
/etc/default/etc/profile from 'if [ -f ${f} ]' to 'if [ ! -d $f/ ]'.
I'm wondering if base-files can't check if /etc/profile has been changed,
for instance, using md5sum. Then it could overwrite the file if it's
still
the original version, or, if it has been changed, move it away to, for
instance, /etc/profile.SAV or something.
The preremove part of base-files could be modified to rename any of the
files that have been modified (if they haven't then they are deleted ready
for the post-install routine to install new versions) - although I don't
know if it's desirable behaviour. I'm not sure if I'd be terribly happy
to have cygwin just rename my customisations out of the way, would be
*highly* confusing the first (at least!) time it happened...
J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sat, September 17, 2005 5:33 pm, Max Bowsher wrote: John Morrison replied to me privately (accidentally, I presume). Yes, it was - sorry Max. I'm forwarding the message to cygwin-apps@ to maintain threading: Thanks - I wondered by it didn't appear on the list before I logged off! J.
Re: base-files: Does not permit the use of symlinks in /etc/profile.d/
On Sun, September 18, 2005 1:14 am, Max Bowsher wrote:
Eric Blake wrote:
Sorry, didn't realise. If I change the line
/bin/find /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
to be
/bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh'
would that fix things? (The -L tells find to follow the link and make
decisions based on the actual file AFAICT).
Would find then apply the -iname tests to the link destination too,
then?
True - once you turn on -L, all the tests are applied to the
destination.
Also, the existing code is redundant (find has already proven the
file exists and is regular, so the [ -f ${f} ] is unneeded), and
buggy,
since it tries to source non-files named *.zsh, as though it were
written:
\( -type f -a -iname '*.sh' \) -o -iname '*.zsh'
So how about this:
if [ -d /etc/profile.d ]; then
for f in `/bin/find /etc/profile.d -xtype f \( -iname '*.sh' -o
-iname '*.zsh' \) | LC_ALL=C sort` do
. $f
done
fi
That would be a potential confusion. How about using \( -type f -o
-type
l
\) ?
-type l won't cut it, because it gets false positives on a symlink to a
directory.
This makes me think: Why are we trying so incredibly hard to detect
directories?
Humm, hold over from the first days of this code I would imagine.
If someone does someone so incredibly bizarre as creating a directory
named
'/etc/profile.d/foobar.sh/' (or .zsh or .csh), why not let them suffer the
error message?
Not a problem really, so, do I go with:
if [ -d /etc/profile.d ]; then
for f in `/bin/find /etc/profile.d -xtype f \( -iname '*.sh' -o
-iname '*.zsh' \) | LC_ALL=C sort` do
. $f
done
fi
do we even need the outer if?
J.
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, September 15, 2005 5:45 pm, Corinna Vinschen wrote: Mails in the last couple of weeks indicate that we have lost one or the other maintainer without getting any notice from them. Since we have a couple of packages which haven't been updated for a good amount of time, there's apparently a need to find out, which packages are still maintained and which have lost their maintainer on the way. So, ALL maintainers of Cygwin packages, please reply to this mail within the next six weeks, including a list of ALL packages you maintain. This survey will run until 2005-10-31. I will ping every week, so you have a bit of time. However, if you don't reply until 2005-10-31, your packages will be up for grabs. Which means, they will disappear from the Cygwin net distribution if nobody wants to take over maintainership. base-files base-passwd lcms (kinda - said I would but not re-released yet!) units J.
Re: [UPLOAD] base-file 3.6-1
On Fri, August 5, 2005 2:46 am, Eric Blake said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Igor Pechtchanski on 8/4/2005 10:09 AM: What if the user has to set an environment variable for /etc/profile.d/bash-completion.sh to run? You could check for that environment variable in /etc/profile.d/bash-completion.sh and exit if it's not set. And it's easier than editing their .bashrc... The env variable would have to be set before bash starts execution, since /etc/profile finishes before the user's ~/.bashrc starts. BTW, one drawback of the /etc/profile.d approach is that it only works for login shells. True enough. And bash only looks at ~/.bashrc for non-login interactive shells, nothing else. So I guess we are stuck with telling users to edit ~/.bashrc no matter what. Oh well - never mind :) J.
[UPLOAD] base-file 3.6-1
This incorporates the patch (slighly modified) Eric Blake supplied for bash completion. There is another way however - bash completion could put a file in the /etc/profile.d... Anyway, if this is the route Eric would prefer, here it is - if not I don't mind rolling it back. This does not require bash completion to be installed but Eric wanted it in before announcing. Note that changing the skel file doesn't update/synchronise the copy in the users directory...! Change Log -- 3.6-1 * Typo - Eric Blake * Bash completion examples - Eric Blake http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.6-1.tar.bz2 md5sum: 0f226a7b43775b1b99a455d89457d0b1 Incase they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint J.
Re: [UPLOAD] base-file 3.6-1
On Thu, August 4, 2005 1:38 pm, Eric Blake said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John Morrison on 8/4/2005 6:25 AM: This incorporates the patch (slighly modified) Eric Blake supplied for bash completion. There is another way however - bash completion could put a file in the /etc/profile.d... The discussion on this list was that auto-installation in /etc/profile.d, while possible, would probably elicit complaints along the lines of why does bash take so much longer to load now? (even on my 2.5 GHz machine, it adds more than a second to the start of every interactive shell). I guess now we will have to see how many complaints we get of why doesn't bash_completion get sourced? I wouldn't have thought there would be much/any speed gained doing it this way...? If somebody installs bash_completion then they shouldn't have a problem with something taking longer, if they do, they should uninstall it (removing the /etc/profile.d/ file) :) But *shrug* :) J.
Re: [UPLOAD] base-file 3.6-1
On Thu, August 4, 2005 2:04 pm, Corinna Vinschen said: On Aug 4 13:25, John Morrison wrote: http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.6-1.tar.bz2 Uploaded. Thanks.
Re: [UPLOAD] base-file 3.6-1
On Thu, August 4, 2005 2:08 pm, Eric Blake said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John Morrison on 8/4/2005 6:52 AM: I wouldn't have thought there would be much/any speed gained doing it this way...? There's no speed difference, whether bash_completion is sourced by /etc/profile.d/completion.sh or by ~/.bashrc. The difference is that sourced by ~/.bashrc, the user explicitly turned it on, so they are aware that they caused the delay; plus multiple users sharing a machine can independently decide whether or not they want to take the delay. But with /etc/profile.d, the user has no choice; bash_completion WILL be sourced, and cause the delay. I'm afraid there are too many people who blindly install every package without realizing the implications, but I'm willing for the next release of bash-completion to use /etc/profile.d if there are enough complaints of why the user has to edit ~/.bashrc in addition to installing bash-completion. (I guess if I ever do add an /etc/profild.d hook, I'd have to make sure bash_completion is idempotent, so that sourcing it the second time is a no-op, rather than doubling the delay of users that already edited their ~/.bashrc.) If somebody installs bash_completion then they shouldn't have a problem with something taking longer, if they do, they should uninstall it (removing the /etc/profile.d/ file) :) Removing the /etc/profile.d file is a partial solution, but then cygcheck would report the bash-completion package is incomplete. Humm, no, I ment uninstalling the package would remove the file :) Not to worry anyway - works done :) J.
Re: whatever happened with bash_completion, bashdb
On Mon, August 1, 2005 1:30 pm, Eric Blake said: Sourcing bash_completion must be done for every interactive shell startup, login or otherwise, for the completions to be available. And even on my 2.5 GHz WinXP machine, time . /etc/bash_completion reports 1.346 s. Also, I anticipate the time will only grow as upstream adds more completions (it already includes 266 kbytes among 28 files to be sourced). So based on your argument, I've decided that the bash_completion is not enabled by default, and that you must edit your ~/.bashrc to source it (and make sure your ~/.bash_profile sources ~/.bashrc, to cover login shells) if you desire the features. I will also provide patches to base-files to make this more obvious to new users. Not a problem, just send me the patches :) J.
[UPLOAD] base-file 3.5-1
Change Log
--
3.5-1
* Changed setup.hint from ash to bash
* Toned down the warning about customisation - Rex Eastbourne
Andrew Schulman, Igor Pechtchanski
* Changed ${MANPATH}. Changed order and removed autotool -
Igor Pechtchanski, Brian Dessent
* Changed ${INFOPATH}. Changed order and removed autotool.
* Fixed some mistakes in .inputrc and added some more
examples - Igor Pechtchanski
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.5-1.tar.bz2
md5sum: b92f2d18e1d5d15b817d8e333ff674f8
Incase they're wanted...
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
(note that setup.hint changed ash - bash)
Thanks,
J.
PS, base-passwds setup.hint also changed ash - bash, should I post a new
version?
[upload] Base-files 3.4-2
Some minor changes around the chmod introduced in 3.4-1. Thanks to everyone again :) J. PS, are there any new (or updated) OOS licenses needed including? Change Log -- 3.4-2 * Redirected chmod errors to /dev/null caused by lack of admin rights - Angelo Graziosi, Igor Pechtchanski, Karl M * Removed the test around chmod 1777 /tmp - Igor Pechtchanski http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.4-2.tar.bz2 md5sum: bcfff54ad27bfb4dbb5f2a86b8e3f7b7 Incase they're wanted... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
Re: Base-files 3.4-1: Problems for users with Non-Admin. priv. (atn: Corinna)
On Sun, May 15, 2005 9:38 pm, Angelo Graziosi said: When loging as user without admn. priv. (e.g.: owner= Graziosi, group= Users) the standard bash shell (cygwin.bat) says: chmod: changing permissions of `/tmp': Permission denied This is caused by if [ -d /tmp ]; then chmod 1777 /tmp fi in /etc/profile. It assign the permission t to /tmp but this was already a problem with xorg-x11-xwin-6.8.2.0-1 and org-x11-xwin-gl-6.8.2.0-1. The next, 6.8.2.0-2, was released exactly to fix that problem. The solution was to not assign the t permission to /tmp and to whatever it contans! See: http://cygwin.com/ml/cygwin-xfree/2005-04/msg00076.html http://cygwin.com/ml/cygwin-xfree/2005-04/msg00054.html http://cygwin.com/ml/cygwin-xfree/2005-04/msg00053.html http://cygwin.com/ml/cygwin-xfree/2005-04/msg00050.html http://cygwin.com/ml/cygwin-xfree/2005-04/msg00049.html http://cygwin.com/ml/cygwin-xfree/2005-04/msg00048.html angelo. Corinna, this was a change you asked for... what would you like me to do? http://cygwin.com/ml/cygwin-apps/2005-04/msg00206.html J.
[UPLOAD] Base-files 3.4-1
Thanks to everyone who had input... apologies if I forgot anyone (let me know, I'll add you in for next time). 3.4-1 Changes: * Removed stty erase ^H - lots! * chmod 1777 /tmp - Corinna Vinschen * Properly quote [:upper:] [:lower:] - Webb Roberts * Add local to the sort - Eric Blake * Various quote corrections - Eric Blake * Simplified the bash PS1 - Eric Blake * Made the SHELL switch more portable - Eric Blake, Cliff Hones, cfg, Igor Pechtchanski 3.3-1 (Never uploaded) * Add a warning about editing base-files files * Add a note about where the originals are to be found * Add some more examples to skel/.bashrc - Chris Wilson http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.4-1.tar.bz2 md5sum: f837fb9c3641accde0ae4a71b8aef65d I think setup.hint was changed, this is my updated version incase anyone cares :) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint Thanks, J. PS, I skipped 3.3 it was just about ready and then a load of folks started with more changes :)
[UPDATE] base-passwd-2.2-1
Base-passwd Change: added a missing /etc/ - Thanks Igor md5sum for base-passwd-2.2-1.tar.bz2 ed2c2f1670df26ed4f4c704a145b05be http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/base-passwd-2.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/md5sum (not changed...) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/setup.hint Let me know if there are any issues :) J.
Re: Bug in /etc/postinstall/passwd-grp.sh [Attn: base-passwd maintainer]
FYI, line 23 should read chmod --silent --reference=/etc/passwd /etc/group instead of chmod --silent --reference=/etc/passwd group otherwise the script produces an error: chmod: cannot access `group': No such file or directory Thanks for the heads up Igor, I'll do the change tonight. J.
Re: bsdgames
Yitzchak Scott-Thoennes wrote: by default puts the binaries in /usr/games, in accordance with FHS 2.2 and 2.3 (I didn't look at any earlier versions of FHS). Is this what we want? If so, fortune and robots at least should also be there. If we use /usr/games, should it be added to people's path? Two possiblities jump to mind, 1) I can add /usr/games to /etc/profile 2) You can add /usr/games to the path in a /etc/profile.d script Either option would be OK with me. J. (base-files maintainer) PS, sorry to the list if this comes through twice!
Re: bsdgames
On Tue, 18 Jan 2005, John Morrison wrote: Yitzchak Scott-Thoennes wrote: by default puts the binaries in /usr/games, in accordance with FHS 2.2 and 2.3 (I didn't look at any earlier versions of FHS). Is this what we want? If so, fortune and robots at least should also be there. If we use /usr/games, should it be added to people's path? Two possiblities jump to mind, 1) I can add /usr/games to /etc/profile 2) You can add /usr/games to the path in a /etc/profile.d script Either option would be OK with me. Definitely an /etc/profile.d script. We don't want to change /etc/profile for every package with non-standard install paths. *shrug* on my Debian box, /usr/games is in the path... anyone have a RedHat/Fedora install they could check? Does anyone have a link to a more understandable version of the LSB rules? All I keep finding is stuff to do with binary interfaces! J.
Re: [test] base-files 3.2
On Wed, Dec 08, 2004 at 06:24:14PM -, John Morrison wrote:
I'm *fairly* sure that all the variables that need to be escaped have
been.
The only ones that haven't should be PATH, MANPATH and INFOPATH as per a
thread a few weeks ago.
? Can you point to a URL for this discussion? I can't think of any
reason
why PATH and friends should not be quoted.
Sure, err, *looks* I kept the email specifically for this... *ummm*... ah!
It's something to do with the which command...
The thread is
RE: which command does not expand ~ in path (base-files update needed)
Message-ID: [EMAIL PROTECTED]
snip
You can use ~ here. Just don't quote it. It shouldn't be quoted.
export PATH=~/bin:${PATH}
I'm sorry, but this isn't true, even for bash. It still
leaves the ~ in
the PATH, which confuses which (although type, being a
bash builtin, recognizes and expands it).
Why isn't it expanded by bash's tilde substitution at the time the 'export'
command line is parsed then? That's sooo wrong. Oh wow. Guess what: it
depends
whether the *other* part of the assignment is quoted or not:
[EMAIL PROTECTED] ~ echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/win/c/WINDOWS/system32:/win/c/WINDO
WS:/win/c/WINDOWS/System32/Wbem
[EMAIL PROTECTED] ~ export FOO=~/bin:${PATH}
[EMAIL PROTECTED] ~ echo ${FOO}
~/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/win/c/WINDOWS/system32:/win/c
/WINDOWS:/win/c/WINDOWS/System32/Wbem
/snip
snip
This works fine no matter where I put the directory with spaces in it.
Regardless, I don't see any reason to turn this thread into an
exposition on what does or doesn't work with variables that contain
spaces. Dropping the quotes from the original example will just cause
everything to work correctly everywhere.
John Morrison, would you mind doing this, please?
cgf
/snip
Hope this is right :)
J.
Re: [test] base-files 3.2
John Morrison, would you mind doing this, please? cgf Sheesh. You can't trust anything THAT guy says. lol He can't even remember conversations from a month or two ago. Sorry. Never mind. You don't want me to upload this to sourceware.org, right? If you wouldn't mind casting your eyes over them and can't find anything wrong then I'm happy for them to go up. If you've not got the time, I'd prefer to wait until somebody else OKs them (if that's OK with you). J.
Re: [test] base-files 3.2
Given my track record so far, Bah, given the amount of threads you participate in I think you are being too hard on yourself! I think it would be best if someone else ok'ed these. :-) As you wish :) J.
[UPDATE] base-files (3.1-4)
Changes: Wish I knew. For some reason editing it with CodeWright appears to corrupt things. Sorry. Anyway, a textually identical(?!) set of files *not* edited with CodeWright :( http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-4.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint Please upload at your earliest convenience. J.
Re: [UPDATE] base-files (3.1-4)
On Mon, Nov 15, 2004 at 06:58:54PM -, John Morrison wrote: Changes: Wish I knew. For some reason editing it with CodeWright appears to corrupt things. Sorry. Anyway, a textually identical(?!) set of files *not* edited with CodeWright :( http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-4.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint Please upload at your earliest convenience. Uploaded. Btw, it would be helpful if you only provided the links of things that had been changed. I've inspected your setup.hint file twice now but AFAICT it is no different than the one currently in the distribution so there's no need to include it in your upload request. OK. I just thought it was wanted each time :) Do you want the link to the md5sums each time still? J.
[UPDATE] base-files
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-3.tar.bz2
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
Please upload at your earliest convenience.
J.
Re: [UPDATE] base-files
On Sun, Nov 14, 2004 at 07:37:07PM -, John Morrison wrote:
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-3.tar.bz2
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
Please upload at your earliest convenience.
Done.
Deleted base-files-2.6-1.tar.bz2 and base-files-3.0-2.tar.bz2.
Wow! Thanks Chris that was fast :)
J.
Re: setup RFC: Ditch homegrown http/ftp code and use a library?
Max Bowsher wrote: Brian Dessent wrote: Max Bowsher wrote: So, I'm looking for comments, and suggestions for candidate http/ftp client libraries to investigate. What's wrong with libcurl? It has extensive support for all kinds of extended http/ftp features, see for example http://curl.haxx.se/docs/comparison-table.html, and is MIT-licensed so should be no problem statically linking it into setup.exe. Indeed, libcurl was one which came to mind. I've yet to play with it, but one thing I'm a little worried about is it being *too* extensive - I don't want setup.exe to grow very much. If you are worried about the size of setup, would it help to move /cygwin.bat and /cygwin.ico into base-files? I've an update going out for this soon and it would be little/no trouble... (I could even rename them to have a captial 'C' so they don't clash with /cygdrive ;) J.
Re: ATTN: basefiles, tcsh, zsh maintainers; chere updates to login scripts
On Fri, Oct 29, 2004 at 11:11:17AM -0700, Dave wrote: The logic required is: If the environment variable CHERE_INVOKING is present, do not change to the users home directory. http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-2.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint These were done in a hurry (am leaving for holiday in 15 mins!) somebody please check!!! If it's wrong I'm sure cfg or somebody could fix and send me the changes to incorporate for the next version. setup.hint hasn't changed: sdesc: A set of important system configuration and setup files ldesc: A set of important system configuration and setup files requires: ash fileutils sh-utils textutils findutils sed category: base md5sum 71534439bf742f261d0a749fd6186463 *base-files-3.1-2.tar.bz2 9b2695ab19b83cc2eb27e346801a114c *setup.hint Change log: 3.1-2 * Fix for zsh/ksh - Tero Niemela * Change cd $HOME functionality for CHERE - Dave J. PS Dave, I'm sorry I couldn't find your surname anywhere!
Re: [ITP] ctetris
Hi I would like to contribute and maintain the ctetris package: +1 binary installs and runs OK, src rebuilds binary correctly (without the -1, I don't know if that's an issue...?) J.
Re: [update] base-files and base-passwd
On Sat, 21 Aug 2004, Pierre A. Humblet wrote: On Sat, 14 Aug 2004 13:25:24 -0400 I wrote John, could you use cp -p in base-files-profile.sh? The postinstall exim.sh uses the non-existence of /etc/exim.conf as the sign that it's a fresh installation. That test doesn't work right if it happens to run after base-files-profile.sh, because it creates /etc/exim.conf from /etc/defaults/etc Being able to compare dates would greatly help. That was brain dead suggestion because the -p undoes the effect of the touch and reintroduces the ntsec problem with cp. Using the -p to timestamp the file has become unnecessary anyway since now base-files-profile only handles files in its manifest. I am afraid a new version is necessary. Sorry about that. There's always touch -r (or touch --reference=), if you really need the timestamp. This won't touch the ACLs. Hi guys, I've removed the -p from the copy instruction, there's -3 available now at http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.0-3.tar.bz2 is the timestamp really necessary? J. PS, base-passwd needs uploading... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/base-passwd-2.1-1.tar.bz2
RE: [update] base-files and base-passwd
Please upload :) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.0-2.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint Base-files Change: 3.0-2 * Fix for security interactions when using cp - Thanks to Pierre A. Humblet 3.0-1 * Added several open source license files. These were sourced from http://www.opensource.org/licenses/ Packages may contain minor variations on these files. * Added a preremove script to help keep the various scripts uptodate (unless they've been modified). * At Igor Pechtchanski's suggestion, all base-file scripts are now versioned. * Several patches, thanks to all. Now I'm keeping this changelog I'll be sure to add names! Appologies to all who helped with this version. ** ** * NOTE: if you want the automatic update script to * * keep files up to date, you *must* delete the * * following files and then reinstall the * * base-files package; * * /etc/bash.bashrc * * /etc/DIR_COLORS * * /etc/profile * * /etc/skel/.bashrc* * /etc/skel/.bash_profile * * /etc/skel/.inputrc * ** ** Base-passwd Change: chmod 777 /etc/[group|passwd] when created http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/base-passwd-2.1-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/setup.hint Let me know if there are any issues :) J.
[update] base-files and base-passwd
Base-files Change: 3.0-1 * Fix for security interactions when using cp - Thanks to Pierre A. Humblet * Added several open source license files. These were sourced from http://www.opensource.org/licenses/ Packages may contain minor variations on these files. * Added a preremove script to help keep the various scripts uptodate (unless they've been modified). * At Igor Pechtchanski's suggestion, all base-file scripts are now versioned. * Several patches, thanks to all. Now I'm keeping this changelog I'll be sure to add names! Appologies to all who helped with this version. ** ** * NOTE: if you want the automatic update script to * * keep files up to date, you *must* delete the * * following files and then reinstall the * * base-files package; * * /etc/bash.bashrc * * /etc/DIR_COLORS * * /etc/profile * * /etc/skel/.bashrc* * /etc/skel/.bash_profile * * /etc/skel/.inputrc * ** ** http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-fil es-3.0-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hi nt Base-passwd Change: chmod 777 /etc/[group|passwd] when created http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/base-pa sswd-2.1-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/setup.h int Let me know if there are any issues :) J.
RE: [update] base-files and base-passwd
From: Pierre A. Humblet Sent: Saturday, 14 August 2004 6:25 pm Hi Pierre could you use cp -p in base-files-profile.sh? No problem, I'll upload a -2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-fil es-3.0-2.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hi nt The postinstall exim.sh uses the non-existence of /etc/exim.conf as the sign that it's a fresh installation. That test doesn't work right if it happens to run after base-files-profile.sh, because it creates /etc/exim.conf from /etc/defaults/etc It should do now, for the 3.x release I changed the base-files-profile.sh to only install files that are listed in the manifest file. This manifest file is also used when upgrading to future versions :) Being able to compare dates would greatly help. Otherwise base-files-profile.sh looks fine. Thanks Thank you for looking at it so quick! J.
License texts in base-files?
I've just been reading what Debian does with it's base-files, it includes several license texts. Would it be useful for Cygwin to do that too? Then we could just point folks to their own machine :) If we did, is GPL the only license that should be included? Debian includes the following... Artistic BSD GPL (ln -s GPL-2) GPL-2 LGPL (ln -s LGPL-2.1) LGPL-2 LGPL-2.1 Also, should they be in the same location; /usr/share/common-licenses? Thoughts? J.
RE: base-files request
From: Igor Pechtchanski
John,
Would it be possible to add the base-files package version to the header
comment of all the scripts in base-files? It would then be apparent which
version of the base-files package each script came from.
Good idea :)
Another thing that was talked about was checking whether /etc/profile was
edited and updating it if it wasn't (same probably goes for other
/etc/defaults scripts). One way to do this is to compare /etc/profile
with /etc/defaults/etc/profile in the preremove script, and if it's the
same, remove /etc/profile, i.e.,
Yes, I've been playing with this idea...
if /bin/cmp -s /etc/defaults/etc/profile /etc/profile; then
echo /etc/profile was modified, leaving as-is
elif [ $? -eq 127 ]; then
echo diffutils must have been uninstalled, sorry
else
/bin/rm /etc/profile
fi
The contortions above are needed to correctly handle the case when
diffutils is being upgraded as well. Of course, upgrading fileutils
will cause rm to fail, and no postinstall script will work if either
cygwin or bash is upgraded, but at least the above won't remove
/etc/profile if /bin/cmp is missing (as the first obvious choice,
if ! /bin/cmp -s /etc/defaults/etc/profile /etc/profile; then
/bin/rm /etc/profile
fi
would have).
#!/bin/sh
[ -f /etc/preremove/base-files-manifest.lst ] || exit 0
echo *** Removing unmodified base files.
echo *** These will be updated by the postinstall script.
echo *** Please wait.
while read f; do
/bin/cmp -s ${f} /etc/defaults${f}
if [ `echo $?` -eq 0 ]; then
echo ${f} hasn't been modified, it will be updated
/bin/rm -f ${f}
fi
done base-files-manifest.lst
but I'll add the test for diffutils :)
This way the skel files will be upgraded in the same manner.
I have been wondering how best to release this, there have been
several patches to profile, but if I release a new package with the
new version of profile then the preremove script will never
upgrade... but how long do I (we? ;) give people to upgrade?
J.
libwmf's sdesc and ldesc
Hi all, In libwmf's sdesc and ldesc should Windows and Microsoft have a stroke through the o? (sorry to whoever's language uses this character, I really should know what it's called!) Just wondering, J.
setup preremove postremove
Hi everyone Sorry if this post should have gone elsewhere (I'm sure somebody will correct it ;) I'm museing about trying to get /etc/profile to update itself. What I'm currently debating is a script which runs before the new files are installed which compares /etc/profile with /etc/defaults/etc/profile and, if they are identical, deletes /etc/profile (and possibly doing the same for all the other files in the base-files package). My question is this, where should the script reside; preremove or postremove? What's the difference? How can any script in postremove run when setup should have removed all files for a package? Does either/both get run for a package update? :) Thanks, J.
RE: Pending Packages List, 2004-03-13
From: Christopher Faylor On Mon, Mar 15, 2004 at 01:59:58PM -0500, Yaakov Selkowitz wrote: Igor Pechtchanski wrote: |I'd like to propose that if someone's ITP'd package has outstanding |issues, that someone cannot ITP any new packages until either the issues |are addressed or the package is withdrawn. I understand your thinking, but remember when I needed to ITP help2man in order to resolve my problems with gtypist? May I suggest instead to make a limit to how many concurrent pending ITPs that someone may have, perhaps 5. I think a better solution, not just for this problem but to prevent an overload of the ITP system in general. I don't know. I think I like Igor's more draconian approach better. I might even go so far as to say that there should be only one ITP at a time unless there is a demonstrated need for other interrelated packages. Even then, it might be a good idea to only have one package ITP at a time, but to state _why_ this package is needed? (ie, ITP help2man Required for future ITP gtypist) So, one at a time would be the rule and you'd have to wait to get the package entirely through the cycle before offering up another package. I am wondering if we should have some different voting rules, too. I have previously gone on record as thinking that the three vote rule is too easy. Maybe we need a representative council or something. It is usually only a few who actually vote/review :( J.
RE: [RFC] Would there be a need for a java-wrappers package?
From: Igor Pechtchanski I would like to hear opinions on how useful a java-wrappers package would be. The package will contain a few shell scripts that allow users to invoke the regular Java SDK tools (java, javac, javadoc) from Cygwin, making them look like their Unix counterparts (i.e., POSIX filenames). The scripts would be updated versions of those posted in http://cygwin.com/ml/cygwin/2003-01/msg00174.html. There are a few reasons why I have misgivings about this. First off, some tools (notably Ant and Tomcat) recognize Cygwin and do something specific to Cygwin anyway, which will probably (most likely) get screwed up if the java they find looks like a Unix version (this did happen to me with Ant and Cygwin-native jikes). Secondly, the tools will certainly not be foolproof (although I'll try my best to make them as robust and autonomous as possible). Thirdly, java versioning may become a problem. Igor, I'd be interested and have had some fixes committed to Ant before so I know folks there, if you want to continue this off-list, please feel free to email me directly (I almost posted to your private address, but thought an invitation to chat would go down better ;) J.
RE: /WINDOWS
*IF* a /WINDOWS (of some form) was added (in some manner) to cygwin, would that mean I could loose the uname call from /etc/postinstall/base-files-mketc.sh that's causing so much grief under XP? I'd like to get rid of this issue as XP is becoming more and more prevalent. J.
RE: new EMacro package
#/etc/postinstall/emacro.sh copies /etc/skel/.emacs /etc/skel/emacs/**/* to $HOME What happens if there's more than one user? Personally, I think that the /etc/skel/.emacs and /etc/skel/emacs/**/* should be /etc/defaults/etc/skel/.emacs and /etc/defaults/etc/emacs/**/* respectively and /etc/postinstall/emacro.sh should copy them, if they don't already exist, to /etc/skel/... It *should* *not* install them to $HOME. Skel files are copied there by /etc/profile when a new user logs in for the first time. If an existing user wants them then it should be up to them to copy as appropriate. J.
RE: [Update][Test] base-passwd
Christopher Faylor wrote: On Tue, Dec 02, 2003 at 10:36:53AM +0100, Corinna Vinschen wrote: Is it safe to rely on /tmp already existing when the postinstall script runs? I see from the source that setup.exe creates tmp. If it doesn't exist when postinstall scripts are being run, that's clearly a bug. I don't think we should be using any other directory for temporary files. That being the case, they can be uploaded as is :) J.
RE: distcc - Addressed all minor issues - Should be good to go (with John M's approval)
From: Harold L Hunt II John Morrison wrote: From: Harold L Hunt II John, Have you, or are you going to, addressed the isses listed in the PPL below for distcc? Once those minor issues have been addressed, I will try to review the package for you. I don't want to review it right now only to report the same problems though. Thanks Harold, it's appreciated, but I'm pressed by a deadline at work and have (even less) time than usual. I *do* intend to address these, but prob not for at least another week or so :| I took care of the minor issues for you and added a generic patch for a --with-docdir parameter for the configure script (which I have submitted to the distcc mailing list). I created a distcc.README file that specifies you as the maintainer and added 'cygwin' and 'popt' as dependencies in the setup.hint. You are still the maintainer though. If you install this and it works, lets post it and you can handle all future maintenance. Oh yeah, I grabbed the 2.11.2 release instead of the 2.11.1 release that the initial package was for. cut here -- #!/bin/bash wget \ http://msu.edu/~huntharo/cygwin/release/distcc/distcc-2.11.2-1.tar.bz2 wget \ http://msu.edu/~huntharo/cygwin/release/distcc/distcc-2.11.2-1-src.tar.bz2 cut here -- You can point setup.exe to the following address to test my package and source package: http://msu.edu/~huntharo/cygwin/ If it works, lets get this posted. Thanks for all the hard work Harold - it works brilliantly :) Daniel - if you would care to get this from Harolds site above, I'll host the next version on my NTL account. Thanks again Harold. J.
[Update][Test] base-passwd
As per the thread [RFC] Globally creating a user and a group root I've modified the base-passwd packaged to remove user and group which match the pattern :S-1-1-0: and ensure that there's a group root:S-1-5-32-544:0:. Since this version creates tmp files I'd prefer it to be marked as test until Corinna (and maybe some others?!) say it's OK. J. sdesc: A script to set up initial passwords and groups ldesc: A script to set up initial passwords and groups requires: cygwin ash fileutils sed category: base test: 2.0-1 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/md5sum 96b3b805a343a68311d8872c36871087 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-passwd/base-pa sswd-2.0-1.tar.bz2 52b1483382a69b6385f54dd494f4ef5c http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/distcc/setup.hint
RE: distcc - Awaiting another review, or waiting for fixes from first review?
From: Harold L Hunt II John, Have you, or are you going to, addressed the isses listed in the PPL below for distcc? Once those minor issues have been addressed, I will try to review the package for you. I don't want to review it right now only to report the same problems though. Thanks Harold, it's appreciated, but I'm pressed by a deadline at work and have (even less) time than usual. I *do* intend to address these, but prob not for at least another week or so :| J.
RE: Maintainers/Packages List, 2003-11-22
base-files ... !!! no source and no external-source base-passwd ... !!! no source and no external-source There is no source for these packages, they just contain shell and postinstall scripts. Should I do something? J.
RE: Pending Packages List, 2003-11-07
From: Dr. Volker Zell Daniel == Daniel Reed [EMAIL PROTECTED] writes: * Shouldn't the /usr/share/sample.sgreprc go to /etc/defaults/etc/sample.sgreprc and be copied to /usr/share/sgreprc by a postinstall script ? If it is placed in /etc/defaults/ it should be called /etc/defaults/etc/.sgreprc (ie, it should be called the same as the actual file will be) as all that should happen is, if the file (or a link) doesn't exist minus the /etc/defaults prefix, copy it :) The easiest postinstall script is to copy /etc/postinstall/base-files-profile.sh[.done] as this is all that script does :) However the use of /etc/defaults/ is entirely optional and at the package maintainers whim :) J.
RE: [ITP] distcc - without company disclaimer
From: Daniel Reed PROBLEM distcc On 2003-10-08T15:59+0100, John Morrison wrote: One thing I noticed is that the documentation appears to be primarily in usr/share/doc/distcc/, with copies of COPYING, INSTALL, README, and TODO in usr/share/doc/distcc-2.11.1/. I believe all documentation is expected to be in usr/share/doc/distcc-2.11.1/, but surely there should be no duplicates. This was the standard behaviour with the method 2 script. I know I should customise it for the package, but I don't want to tweak it too much - I might end up breaking it! Also, the package includes the *directory* usr/share/doc/Cygwin/, but there are no files in it. There should be a Cygwin-specific file either called distcc-2.11.1.README or distcc-2.11.1-1.README. Again, the method 2 script created this directory. I *really* would like to question the requirement for a document in there - what am I going to say that the original docs don't? I think that that directory should be for documents written about cygwin tools, for example cygserver/which. I'll try and add something... The package also includes the directory etc/postinstall/, which is empty. Not a hold-up, but if you are re-packaging anyway feel free to zap it. There will be, I plan to add a postinstall script to set it up with (less) user intervention. The usr/bin/distccd.exe file has a library dependency on cygpopt-0.dll, which my test machine does not have. The only dependency listed in setup.hint is gcc; it looks like you might need to add either popt or libpopt0. Thanks, I missed that one. distcc.exe, distccd.exe, and distccmon-text.exe all have a dependency on cygwin1.dll, which should require an additional dependency on cygwin. It might seem intuitive that a Cygwin package requires cygwin, and that listing it is just a formality, but some packages truly might not depend on cygwin (such as pure-documentation packages or pure-script packages). This has been raised before on the list, afaicr packages don't need to list cygwin as a dependancy. But I'll add it... So, in the binary package, the documentation needs to be consolidated into usr/share/doc/distcc-2.11.1/, a Cygwin-specific README needs to be created in usr/share/doc/Cygwin/, and etc/postinstall/ should probably be killed. In setup.hint either popt or libpopt0 should be required, and cygwin should also be required. I have not reviewed the functionality. (I am unfamiliar with the distcc utility, perhaps someone who voted for it? :) Thanks for the review, it *is* appreciated, but don't let your new position as package list maintainer bully you into reviewing all proposed packages! If people don't step-up to vote/review, it's going to be quite obvious that the package shouldn't be part of the cygwin distro :) I'll try and do the changes you recommend, but I'm away for the best part of the next fortnight, so it might be after that I'm afraid. Thanks again, J.
[ITP] distcc - without company disclaimer
2.11.1 has just been released... Original from http://distcc.samba.org This is a first attempt. It still needs quite a lot of setup to use. I'm working on the postinstall which will do more of the work, but I thought this might be of use to some folk as it stands. J. sdesc: A fast, free, distributed C/C++ compiler ldesc: is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network requires: gcc category: Devel http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/distcc/ http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/distcc/md5sum d3262ba371eac1f169a712390e783c11 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/distcc/distcc-2.11. 1-1.tar.bz2 1167ebf86dedcab637491d3e1551820e http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/distcc/distcc-2.11. 1-1-src.tar.bz2 ae55ee386915a5c406828bdb44e5543c http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/distcc/setup.hint J.
FW: [update] base-files (was: RE: /etc/profile - futile try to predict order of execution)
(sorry, wrong list) -Original Message- From: John Morrison [mailto:[EMAIL PROTECTED] Sent: Sunday, 21 September 2003 10:25 pm To: [EMAIL PROTECTED] Subject: [update] base-files (was: RE: /etc/profile - futile try to predict order of execution) Subject: RE: /etc/profile - futile try to predict order of execution AFAIK /etc/profile *never* tried to predict/guarentee order of execution. If packages made an assumption, well you know the saying. - `/bin/find /etc/profile.d -iname '*.sh' -type f` + `/bin/find /etc/profile.d -iname '*.sh' -type f | sort` Fixed. Please upload 2.6-1 J. http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum 426b60728ae5061ab9e8e20212ef6fc6 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-fil es-2.6-1.tar.bz2 9b2695ab19b83cc2eb27e346801a114c http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hi nt
[update] base-files (2.2-1)
Last update (fingers crossed!) for a while. J. http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum 1b9efa1c42745fd9ec6067d9f681dbc7 base-files-2.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-fil es-2.2-1.tar.bz2 9b2695ab19b83cc2eb27e346801a114c setup.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hi nt sdesc: A set of important system configuration and setup files ldesc: A set of important system configuration and setup files requires: ash fileutils sh-utils textutils findutils sed category: base
RE: [update] base-files (2.1)
From: Elfyn McBratney Morrison, John [EMAIL PROTECTED] wrote: Fixed some of the issues folks have been emailing about, regtool -q, quotes, defaults for other shells, mk[passwd|group[_l_d]], could somebody upload? Done. Thanks :D J.
Re: setup.ini not updated?
On Thu, 14 Aug 2003, Elfyn McBratney wrote: It's fixed. Should be on mirrors.rcn.net (at least) in about an hour. -- Elfyn Thanks Elfyn :) J.
setup.ini not updated?
http://mirrors.rcn.net/pub/sourceware/cygwin/setup.ini setup.ini 11-Aug-2003 16:30 211k @ vim sdesc: Vi IMproved - enhanced vi editor category: Editors requires: cygwin terminfo libncurses7 libiconv2 version: 6.2-1 install: release/vim/vim-6.2-1.tar.bz2 2216490 eb7b2330c4926bda523835cea7cc0725 source: release/vim/vim-6.2-1-src.tar.bz2 3283371 3c33c4b8438295724ad6ad130d00611e [test] version: 6.2-2 install: release/vim/vim-6.2-2.tar.bz2 2216597 d19ecc62096c407cb51c74233e719624 source: release/vim/vim-6.2-2-src.tar.bz2 3284904 fc760b2d428e25013e1c129d52af0087 http://mirrors.rcn.net/pub/sourceware/cygwin/release/vim/ md5.sum 12-Aug-2003 16:54 1k setup.hint 12-Aug-2003 15:35 1k vim-6.2-1-src.tar.bz2 01-Jun-2003 15:15 3.1M vim-6.2-1.tar.bz2 01-Jun-2003 15:16 2.1M vim-6.2-3-src.tar.bz2 12-Aug-2003 15:34 3.1M vim-6.2-3.tar.bz2 12-Aug-2003 15:33 2.1M And it's like this on lots of mirrors for at least the vim and base-file packaged. Or is it just me? J.
Re: Re: [update] base-files
This is the only reference I can find to mkgroup_l_d; $ grep -rin mkgroup_ * winsup/utils/mkgroup.c:477: printf (mkgroup_l_d:%s:%u:, print_sids ? put_sid (tg.psid) : , what does it do (and what should I say when `id -ng` = mkgroup_l_d)? J. On Mon, 11 Aug 2003, Pierre A. Humblet wrote: I am on vacation and using an unsubscribed address from an internet cafe, hence the personal mail to Igor. Thereis no other than mkpasswd, mkgroup and mkgroup_l_d. Checking uid's becomes useless with 1.5, don't bother. Pierre From: Igor Pechtchanski [EMAIL PROTECTED] Date: 2003/08/10 Sun PM 01:20:13 EDT To: John Morrison [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [update] base-files John, On Sun, 10 Aug 2003, John Morrison wrote: At last, a new version of base-files to try :) [snip] I've also added a test for id -ng = mkpasswd or = mkgroup along with a message. Hopefully this might cut down on the number of I have no user messages :) Did you also check for the mkgroup_l_d value? There might be some more, too -- Pierre would probably know right away; if he doesn't chime in, I'll take a look at the code. If there's a similar test I can do for UID out of range I'd be happy to add that to. I doubt you can check the *current* UID for being out of range, as the numeric value returned is already truncated. You could check if /etc/passwd contains UID+65536 or UID+131072 (the most common case and the next possible one) and issue a warning (with instructions to patch up /etc/passwd) in that case... FYI, we're working on a set of new tests in cygcheck, and checking /etc/passwd and /etc/group planned as one of those tests. If there's a way to check whether the UIDs are 16-bit or 32-bit (other than checking 1.3 vs 1.5, which, now that I think of it, might also work), cygcheck could then issue a warning if /etc/passwd contains UIDs 64k. One last note: any messages printed from postinstall scripts are not seen by the user -- they go directly to setup.log.full. So, if you want this to be seen, we better either move this functionality to cygcheck, or duplicate it there. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
[update] base-files
At last, a new version of base-files to try :) There've been lots of changes (hence the major version increment). Please remember that this *WILL NOT* update your current /etc/profile and the skel files *WILL NOT* be copied unless you are a new user. Thanks to (in no particular order)... Igor Pechtchanski (lots!) Elfyn McBratney (lots!) Kenneth G Lafond (colour changes) Max Bowsher (various) David Kilroy (printer) Corinna Vinschen (printer) Alan Miles (/usr/bin/install -D -p -v) Charles Wilson (MANPATH and INFOPATH) (FHS) If I missed anyone, I'm sorry! I've also added a test for id -ng = mkpasswd or = mkgroup along with a message. Hopefully this might cut down on the number of I have no user messages :) If there's a similar test I can do for UID out of range I'd be happy to add that to. Feedback welcome. All the best, J. -- files -- http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum 76d63becbaee47f97111371a4f29fb6a http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-fil es-2.0-1.tar.bz2 9b2695ab19b83cc2eb27e346801a114c http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hi nt sdesc: A set of important system configuration and setup files ldesc: A set of important system configuration and setup files requires: ash fileutils sh-utils textutils findutils sed category: base
RE: [setup PATCH] Another micropatch heading towardsnext_dialogremoval (1)
From: Robert Collins On Sat, 2003-07-26 at 21:31, Max Bowsher wrote: Actually, no. Today, we don't handle the situation because NEXT() is obsolete code that fails to actually do anything. Well, NEXT() in this does attempt to reactivate the current dialog doesn't it? Gary - any input here? After this, we kind of handle the situation, and will be able to handle the situation properly one we have full use of exceptions. It's not a situation that should warrant an exception or failure. All we need to do is get the correct value from the dialog. It seems better to me to loop (say max 2 times) if such a race occurs, rather than reentering the dialog or exiting. Try to actually trigger it. The dialog changes so fast, it is impossible to do. So, if a user can't trigger this oddness, the only remaining cause is Windows oddness, which is good reason to bail out. Actually, my preferred change would be to not try to detect this error, since I don't think it can occur. Hmm, I'll defer to Gary on this. If he says it's impossible to occur, lets simplify the code. If it is possible to occur, lets Do The Right thing, windows oddness or not. Could you not disable the entire sheet when any button is pressed? Would that not get the functionality you wish? J.
RE: [setup PATCH] Another micropatch headingtowardsnext_dialogremoval (1)
From: Robert Collins On Sat, 2003-07-26 at 22:24, John Morrison wrote: Could you not disable the entire sheet when any button is pressed? Would that not get the functionality you wish? No. As I understand it, it's a race condition. That is, if the user queues two messages to the page - next clicked + a click in the selection window, disabling the sheet would be too late. That said, I don't see how we could ever process that second event before finishing our next event. We're synchronous after all. I can't see that ever happening. Admittedly, I've only ever coded MFC dialogs, but still... J.
RE: setup.. release ready?
From: Robert Collins That shouldn't prevent you using a local mirror though. Does it prevent you using a local mirror? thoughtfulhumm, nooo/thoughtful that would work, the only (minor) complication then would be that folks would need to keep the cygwin cache stuff on their machines as well as the setup app (at the moment, everything is stored on my machine which folks using setup via the share too) which, being a (predominate) Microsoft shop might make folks less likely to want to install cygwin... Question: are there any instructions on how to setup a local mirror? do I have to merge the two setup.ini files I get from the internet mirrors? Do I have to run a webserver? (I do anyway, but...) HOWEVER, I'm not against releasing setup as stands (it has far too many improvements) if a release with a fix for this was OK'd fairly soon after a patch (commandline off switch?) was checked in. Well, a command line 'off' switch will do the job. It will require conscious decision.. yep, I'm happy with that. :) J.
