RE: attn cgf - single build integration
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 20, 2002 1:46 PM > To: [EMAIL PROTECTED] > Subject: Re: attn cgf - single build integration > > > On Sat, Apr 20, 2002 at 01:20:03PM +1000, Robert Collins wrote: > > > > > >> -Original Message- > >> From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > >> Sent: Saturday, April 20, 2002 10:13 AM > > > > > >> Btw, if you want to set up a web page off the cygwin > >> directory, that's ok, too. I don't think I could justify a > >> new top-level web page given the fact that I've rejected some > >> other attempts to start up new projects on sourceware due to > >> resource limitations but adding it into the cygwin hierarchy > >> should be ok. > > > >Is there a cygwin-apps hierarchy? I note that there is a > >cygwin-apps/htdocs dir, but I don't know where files put > there appear > >on the website. Having http://cygwin-apps.cygwin.com would be quite > >neat, or http://www.cygwin.com/cygwin-apps. This is for more > than just > >this library (obviously). > > There is nothing there now but apparently I set up the system > so that if you check in an index.html, etc., it will show up > at http://sources.redhat.com/cygwin-apps/ . > > If you want to do that, go ahead. I'm not going to be adding > another virtual domain or host anytime soon. That's cool - sources.redhat.com/cygwin-apps/ works for me. Any objections from the peanut gallery before I go and create an index.html for that? Rob
Re: attn cgf - single build integration
On Sat, Apr 20, 2002 at 01:20:03PM +1000, Robert Collins wrote: > > >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED]] >> Sent: Saturday, April 20, 2002 10:13 AM > > >> Btw, if you want to set up a web page off the cygwin >> directory, that's ok, too. I don't think I could justify a >> new top-level web page given the fact that I've rejected some >> other attempts to start up new projects on sourceware due to >> resource limitations but adding it into the cygwin hierarchy >> should be ok. > >Is there a cygwin-apps hierarchy? I note that there is a >cygwin-apps/htdocs dir, but I don't know where files put there appear on >the website. Having http://cygwin-apps.cygwin.com would be quite neat, >or http://www.cygwin.com/cygwin-apps. This is for more than just this >library (obviously). There is nothing there now but apparently I set up the system so that if you check in an index.html, etc., it will show up at http://sources.redhat.com/cygwin-apps/ . If you want to do that, go ahead. I'm not going to be adding another virtual domain or host anytime soon. cgf
RE: attn cgf - single build integration
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 20, 2002 10:13 AM > Btw, if you want to set up a web page off the cygwin > directory, that's ok, too. I don't think I could justify a > new top-level web page given the fact that I've rejected some > other attempts to start up new projects on sourceware due to > resource limitations but adding it into the cygwin hierarchy > should be ok. Is there a cygwin-apps hierarchy? I note that there is a cygwin-apps/htdocs dir, but I don't know where files put there appear on the website. Having http://cygwin-apps.cygwin.com would be quite neat, or http://www.cygwin.com/cygwin-apps. This is for more than just this library (obviously). Rob
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Fri, Apr 19, 2002 at 10:59:29PM -0400, Charles Wilson wrote: >P.S. Chris, where'd upset go? the current version used to be in >htdocs, but it's gone now. AND, the old version which lived in >cinstall/temp, is still there -- and you said you were going to remove it. http://www.cygwin.com/ml/cygwin-apps/2002-02/msg00028.html cinstall/temp is an empty directory. >Did you remove the wrong one? Nope. upset2 is gone now, though. It is now 'upset'. cgf
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 20, 2002 12:59 PM > Also, setup must do the following (even without new 'views' > and whatnot) Setup should already do that, why not make a test setup.ini and see what happens :]. It's all data driven and there is no requirement for -src packages to follow the same name as the base. Rob
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Robert Collins wrote: >>>we have to make XFree86-base-src the package that contained the full >>>source archive. >>> >>Hmm. Yes. I think this would work. That might be the best solution. >> >>In fact, it may be a nice trend setter. >> > > I think setup.exe needs a little work before doing this, but it's a good > direction. (i.e. setup.exe should have a view to only show src packages, > and a view to only show binaries - to avoid confusing folk). (Think > apt-get source vs apt-get install). How about my 'external-src: ' idea? setup hint for XFree86-[anything but base]-... external-src: XFree86-base setup hint for XFree86-base- and both upset and setup will understand this and "do the right thing": upset needs to, for those pkgs with an external-src in their setup hint, find the -src tarball for the indicated package, whose VER-REL string matches the package-under-consideration, and put THAT into setup.hint, so (for the fonts "package") you get install: release/xfree/xfree86-fonts/XFree86-fonts-4.2.0-2.tar.bz2 source: release/xfree/xfree86-base/XFree86-base-4.2.0-2-src.tar.bz2 [prev] install: release/xfree/xfree86-fonts/XFree86-fonts-4.2.0-1.tar.bz2 source: release/xfree/xfree86-base/XFree86-base-4.2.0-1-src.tar.bz2 Also, setup must do the following (even without new 'views' and whatnot) 1) all XFree86-...- indicate that src is available (that is, 'presence of a -src tarball' == 'no -src tarball but external-src: marker in setup.hint' 2) clicking on any one (or multiple) of the 'src' checkboxes in setup will trigger a download (and only one download) of the actual XFree86-base-4.2.0-1-src.tar.bz2 package - Later, we can get even fancier, and allow the specification of multiple -src packages...then the monolithic 'XFree86-base-4.2.0-1-src.tar.bz2' can be split into "the stuff that cygwin-xfree doesn't change" and "the stuff that changes frequently" (e.g. .../hw/xwin). e.g. setup hint for XFree86-[anything but base]-... external-src: XFree86-base setup hint for XFree86-base- extra-src: XFree86-base2 in release/xfree/xfree86-base/ XFree86-base-4.2.0-1.tar.bz2 XFree86-base-4.2.0-1-src.tar.bz2 XFree86-base2-4.2.0-1-src.tar.bz2 But that (or something like it) can be later - --Chuck P.S. Chris, where'd upset go? the current version used to be in htdocs, but it's gone now. AND, the old version which lived in cinstall/temp, is still there -- and you said you were going to remove it. Did you remove the wrong one?
RFP: boost libraries
Is there anyone on this list interested in providing a distribution of some/all of the boost C+ libraries? Rob
Re: cygwin/xfree86 setup.exe packages available for comments and testing
On Fri, Apr 19, 2002 at 11:17:56PM +0200, Benjamin Riefenstahl wrote: >"Harold Hunt" <[EMAIL PROTECTED]> writes: >> Excellent idea. Now I just need someone to write that script. >> Shouldn't be too hard. Any takers? > >How about > > fontdir=/usr/X11R6/lib/X11/fonts > wfontdir=`cygpath -w $fontdir` > mount -bfs $wfontdir $fontdir 2> /dev/null || mount -bfu $wfontdir $fontdir > >IOW, create a system mount in binary mode on the font directory, >disregarding any existing mount on the same place. If the user is not >allowed to create a system mount, create a user mount instead. > >This would break when there already is a user mount in text mode. >That seems pretty unlikely, though. This looks pretty good to me. How about something like this, though: fontdir=/usr/X11R6/lib/X11/fonts wfontdir=`cygpath -w $fontdir` umount -u $fontdir 2>/dev/null mount -bfs $wfontdir $fontdir 2> /dev/null || mount -bfu $wfontdir $fontdir Just to ensure that there is no user mount? Btw, I like the use of the fontdir variable in this context. It's a little thing, but... cgf
Re: attn cgf - single build integration
On Sat, Apr 20, 2002 at 09:49:34AM +1000, Robert Collins wrote: >Chris, > I'm approaching a point with libgetopt++ that I'll want to roll >it into setup. This will (obviously) affect the single-build procress, >so I'm hoping that you can confirm or suggest alterations to my plan: > >I think that as a general purpose library, it should sit at >winsup/libgetopt++ or even a level above. However the binary linked into >setup.exe needs to be built knowing about setup's String class (as >opposed to the C++ standard basic_string). > >So here's my idea: >we put the library at winsup/libgetopt++ >we make a symlink in the source tree at cinstall/libgetopt++ to >../libgetopt++ > >During configure time setup sub-configures libgetopt++ as a static only >library in cinstall/libgetopt++ > >In the future if any other programs want to start using it, we make >winsup subconfigure winsup/libgetopt++. > >What do you think? I think that libgetopt++ probably belongs at the same level as winsup but there are some, er, political issues that need to be dealt with if that is the case. So, for now, I guess making it a winsup/cygwin sibling makes sense. Btw, if you want to set up a web page off the cygwin directory, that's ok, too. I don't think I could justify a new top-level web page given the fact that I've rejected some other attempts to start up new projects on sourceware due to resource limitations but adding it into the cygwin hierarchy should be ok. cgf
attn cgf - single build integration
Chris, I'm approaching a point with libgetopt++ that I'll want to roll it into setup. This will (obviously) affect the single-build procress, so I'm hoping that you can confirm or suggest alterations to my plan: I think that as a general purpose library, it should sit at winsup/libgetopt++ or even a level above. However the binary linked into setup.exe needs to be built knowing about setup's String class (as opposed to the C++ standard basic_string). So here's my idea: we put the library at winsup/libgetopt++ we make a symlink in the source tree at cinstall/libgetopt++ to ../libgetopt++ During configure time setup sub-configures libgetopt++ as a static only library in cinstall/libgetopt++ In the future if any other programs want to start using it, we make winsup subconfigure winsup/libgetopt++. What do you think? Rob
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 20, 2002 8:48 AM > >I didn't quite gather from the earlier discussions whether > we can have > >a source package seperate from any binary packages. i.e., could we > >have XFree86-full-src without an associated binary package? > Or would > >we have to make XFree86-base-src the package that contained the full > >source archive. > > Hmm. Yes. I think this would work. That might be the best solution. > > In fact, it may be a nice trend setter. I think setup.exe needs a little work before doing this, but it's a good direction. (i.e. setup.exe should have a view to only show src packages, and a view to only show binaries - to avoid confusing folk). (Think apt-get source vs apt-get install). Rob
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Fri, Apr 19, 2002 at 04:55:57PM -0400, Harold Hunt wrote: >The main problem with -src packages for us is that almost nothing will >change after an XFree86 release except for the >xc/programs/Xserver/hw/xwin directory, where I make modifications to >the XWin server. So, what do I do for packaging? Which of the >XFree86-* packages do I include source with? Do I include one huge >tarball with everything and another small tarball that has just the >hw/xwin directory so that it can be easily updated? I'm confused. I had the same thoughts and hoped you'd have a brilliant solution. :-) >I didn't quite gather from the earlier discussions whether we can have >a source package seperate from any binary packages. i.e., could we >have XFree86-full-src without an associated binary package? Or would >we have to make XFree86-base-src the package that contained the full >source archive. Hmm. Yes. I think this would work. That might be the best solution. In fact, it may be a nice trend setter. > >In a related question that has to do with my laziness, I need a way to >tarball a CVS tree without including the CVS directories. I'm sure this can >be done with a simple script, but I'm a programmer not a script writer. >Anyone want to point me to an existing script that does this, or write one >for me? From my "generate a package" script: find $package_src/* -print -follow | egrep -v '\.cvsignore|\.bak$|\.orig$|~$|^.#|CVS|%redact|/tags$' | egrep -v "$src_exclude" | sort | tar -T - --no-recursion -cjf "$tarstem"-src.tar.bz2 cgf
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
> -Original Message- > From: Harold Hunt [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 20, 2002 6:56 AM > In a related question that has to do with my laziness, I need > a way to tarball a CVS tree without including the CVS > directories. I'm sure this can be done with a simple script, > but I'm a programmer not a script writer. Anyone want to > point me to an existing script that does this, or write one for me? Grab the -src for one of the packages that Chuck or I maintain - say libxslt. There is a tar command in the .sh that filters out various directories... I'm sure you can adapt it easily. Rob
RE: strange source packaging?
> -Original Message- > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 20, 2002 12:20 AM > > You must cause the modified files to carry prominent notices > stating that you chaned the files and the date of any change. > > > A differences file alone doesn't accomplish. You must state > in the file header (a prominent place of notice) that you > changed the file. Given the definition of a prominent place of notice, it can be argued that a difference file is just that. It's prominent and states the exact changes made - in both human and computer readable form no less. > Back to the subject at hand, source packaging and the con to > Robert's argument. I can in my wisdom download the > individual binary and accompaning source. At that point I > should be able to rebuild an exacting duplicate from the > source package with supplied scripts found within the source > package Exactly. 'source package' here can mean more than one file. There is no requirement in the GPL that the source be provided as a single entity, just that it be provided in it's entirety. So I don't understand your reasoning for why a pristine source + patches + cygwin build script does not meet the criteria. Certianly debian + *BSD ports systems seem to find it feasible. > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the > Program, and can be reasonably considered independent and > separate works in themselves, then this License, and its > terms, do not apply to those sections when you distribute > them as separate works. But when you distribute the same > sections as part of a whole which is a work based on the > Program, the distribution of the whole must be on the terms > of this License, whose permissions for other licensees extend > to the entire whole, and thus to each and every part > regardless of who wrote it. Yup. That's what we are conforming with. Rob
Re: cygwin/xfree86 setup.exe packages available for comments and testing
"Harold Hunt" <[EMAIL PROTECTED]> writes: > Excellent idea. Now I just need someone to write that script. > Shouldn't be too hard. Any takers? How about fontdir=/usr/X11R6/lib/X11/fonts wfontdir=`cygpath -w $fontdir` mount -bfs $wfontdir $fontdir 2> /dev/null || mount -bfu $wfontdir $fontdir IOW, create a system mount in binary mode on the font directory, disregarding any existing mount on the same place. If the user is not allowed to create a system mount, create a user mount instead. This would break when there already is a user mount in text mode. That seems pretty unlikely, though. so long, benny
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Chris, > It's up there. Should be on mirrors shortly. Very cool. > One thing I just noticed, though (by looking at > http://cygwin.com/packages/), was that the source tar.bz2 files don't > seem to be part of this. There should probably be fewer source tar > balls than binary but they should be part of the distribution, right? > If not, we'll inevitably get questions. I've thought about this enough to make my head spin. The only real solution I could come up with is to tell folks to go to the XFree86 CVS tree. The main problem with -src packages for us is that almost nothing will change after an XFree86 release except for the xc/programs/Xserver/hw/xwin directory, where I make modifications to the XWin server. So, what do I do for packaging? Which of the XFree86-* packages do I include source with? Do I include one huge tarball with everything and another small tarball that has just the hw/xwin directory so that it can be easily updated? I'm confused. I didn't quite gather from the earlier discussions whether we can have a source package seperate from any binary packages. i.e., could we have XFree86-full-src without an associated binary package? Or would we have to make XFree86-base-src the package that contained the full source archive. In a related question that has to do with my laziness, I need a way to tarball a CVS tree without including the CVS directories. I'm sure this can be done with a simple script, but I'm a programmer not a script writer. Anyone want to point me to an existing script that does this, or write one for me? Later, Harold > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor > Sent: Friday, April 19, 2002 1:15 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available > for comments and testing > > > On Fri, Apr 19, 2002 at 12:52:27PM -0400, Christopher Faylor wrote: > >On Fri, Apr 19, 2002 at 01:24:48AM -0400, Harold Hunt wrote: > >>Chris, > >> > >>> Shall we add this to the cygwin distro or are we still waiting for > >>> some postinstall shell script work? > >> > >>These will forever be known as Harold's Famous Last Words: > >>Sure Chris, why not? Go ahead and add the packages to the distro. > >> > >>Be aware, I just updated XFree86-xserv to 4.2.0-2, so you'll > need to grab > >>the latest packages off of ftp://huntharo-4.user.msu.edu/pub/cygwin/ > >> > >>That's all for now. > >> > >>I can't wait to see how many people use Cygwin/XFree86 now! > > > >Ditto. Hope you're ready for this. > > It's up there. Should be on mirrors shortly. > > One thing I just noticed, though (by looking at > http://cygwin.com/packages/), was that the source tar.bz2 files don't > seem to be part of this. There should probably be fewer source tar > balls than binary but they should be part of the distribution, right? > If not, we'll inevitably get questions. > > cgf
Re: [RFC] SWIG package
On Fri, Apr 19, 2002 at 01:56:39PM -0400, Gerald S. Williams wrote: > That's because I haven't built them yet (actually I have, but > I want to do a clean rebuild with the latest "official" SWIG, > which I'll probably do early next week). I interpreted the > instructions at http://cygwin.com/setup.html#submitting as > indicating that I should first propose the package, in case > there's some reason why the package isn't already available. > > I don't currently have a public FTP site set up. In the past, > I've posted things to world.std.com (now ftp://ftp.std.com), > although the public uploads section seems to have gone away, > so I'll have to find another or break down and set up the web > page my dial-up ISP supposedly provides. (Unfortunately, that > will be going away shortly when I finally get my cable modem > hookup.) :-) Do as you like but we need a link to take a look if you did pack it correctly (well, sort of, see the latest discussion about source packaging...) and all that. Don't panic, next week is early enough ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: [RFC] SWIG package
That's because I haven't built them yet (actually I have, but I want to do a clean rebuild with the latest "official" SWIG, which I'll probably do early next week). I interpreted the instructions at http://cygwin.com/setup.html#submitting as indicating that I should first propose the package, in case there's some reason why the package isn't already available. I don't currently have a public FTP site set up. In the past, I've posted things to world.std.com (now ftp://ftp.std.com), although the public uploads section seems to have gone away, so I'll have to find another or break down and set up the web page my dial-up ISP supposedly provides. (Unfortunately, that will be going away shortly when I finally get my cable modem hookup.) :-) -Jerry -O Gerald S. Williams, 55A-134A-E : mailto:[EMAIL PROTECTED] O- -O AGERE SYSTEMS, 6755 SNOWDRIFT RD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18106-9353: mobile:908-672-7592 O- > -Original Message- > From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 19, 2002 3:08 AM > To: [EMAIL PROTECTED] > Subject: Re: [RFC] SWIG package > > > On Thu, Apr 18, 2002 at 03:06:03PM -0400, Gerald S. Williams wrote: > > I'm not familiar with the netiquette here. Should this actually > > be an RFP or ITP? > > > > Anyway, I'd like to volunteer to maintain a SWIG package for > > Cygwin. > > > > Proposed setup.hint: > > --- > > category: Devel > > requires: cygwin > > sdesc: "Simplified Wrapper Interface Generator" > > ldesc: "Simplified Wrapper Interface Generator. > > Generates wrappers for C/C++ modules, allowing them to > > be accessed from a variety of scripting languages. See > > http://www.swig.org for details." > > I'm missing links to the binary and source package... > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Developermailto:[EMAIL PROTECTED] > Red Hat, Inc. >
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Fri, Apr 19, 2002 at 12:52:27PM -0400, Christopher Faylor wrote: >On Fri, Apr 19, 2002 at 01:24:48AM -0400, Harold Hunt wrote: >>Chris, >> >>> Shall we add this to the cygwin distro or are we still waiting for >>> some postinstall shell script work? >> >>These will forever be known as Harold's Famous Last Words: >> Sure Chris, why not? Go ahead and add the packages to the distro. >> >>Be aware, I just updated XFree86-xserv to 4.2.0-2, so you'll need to grab >>the latest packages off of ftp://huntharo-4.user.msu.edu/pub/cygwin/ >> >>That's all for now. >> >>I can't wait to see how many people use Cygwin/XFree86 now! > >Ditto. Hope you're ready for this. It's up there. Should be on mirrors shortly. One thing I just noticed, though (by looking at http://cygwin.com/packages/), was that the source tar.bz2 files don't seem to be part of this. There should probably be fewer source tar balls than binary but they should be part of the distribution, right? If not, we'll inevitably get questions. cgf
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Fri, Apr 19, 2002 at 01:24:48AM -0400, Harold Hunt wrote: >Chris, > >> Shall we add this to the cygwin distro or are we still waiting for >> some postinstall shell script work? > >These will forever be known as Harold's Famous Last Words: > Sure Chris, why not? Go ahead and add the packages to the distro. > >Be aware, I just updated XFree86-xserv to 4.2.0-2, so you'll need to grab >the latest packages off of ftp://huntharo-4.user.msu.edu/pub/cygwin/ > >That's all for now. > >I can't wait to see how many people use Cygwin/XFree86 now! Ditto. Hope you're ready for this. cgf
Re: strange source packaging?
Charles Wilson wrote: > > Robert Collins wrote: > > > And the GPL requires us to document the changes made - if we have the > > patch pre-applied, with no reverse patch, then this isn't the case. > > Asking folk to go elsewhere to get that 'pristine' source puts the onus > > on the upstream to make that available, which we can't do - for the same > > reason that folk that ship cygwin1.dll need to host their own copy of > > the source. > > At the risk of wading into yet another GPL argument -- I don't think the > GPL requires documentation of the entire provenance of changes relative > to some external source; it's just the polite thing to do. > > All the GPL requires is that you distribute THE source that YOU used to > build THE binary YOU distribute. That's it. > You must cause the modified files to carry prominent notices stating that you chaned the files and the date of any change. A differences file alone doesn't accomplish. You must state in the file header (a prominent place of notice) that you changed the file. Now how many of us do that? Instead we use a ChangeLog to note the changes to the files. The GPL itself doesn't give exception for this method. However, since the Copyright holder, Redhat, uses the ChangeLog method for file change notification then it can be argued that the Copyright holder gave the exception to the license so it can continue without change as far as Cygwin is concerned. But the FSF is the copyright holder the most of the other packages we distribute, have the changed files been given appropriate prominent notice? Back to the subject at hand, source packaging and the con to Robert's argument. I can in my wisdom download the individual binary and accompaning source. At that point I should be able to rebuild an exacting duplicate from the source package with supplied scripts found within the source package (autoconfiguration). Therefore having setup.exe perform any patches by downloading only the patch doesn't meet the criteria layed out by the GPL. Nice thought, but not workable within the wording of the GPL. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: strange source packaging?
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 19, 2002 10:57 PM > To: Robert Collins > Cc: Corinna Vinschen > Subject: Re: strange source packaging? > > > Robert Collins wrote: > > > > And the GPL requires us to document the changes made - if > we have the > > patch pre-applied, with no reverse patch, then this isn't the case. > > Asking folk to go elsewhere to get that 'pristine' source puts the > > onus on the upstream to make that available, which we can't > do - for > > the same reason that folk that ship cygwin1.dll need to > host their own > > copy of the source. > > > At the risk of wading into yet another GPL argument -- I > don't think the > GPL requires documentation of the entire provenance of > changes relative > to some external source; it's just the polite thing to do. Section 2a is pretty clear. Rob
Re: strange source packaging?
Robert Collins wrote: > And the GPL requires us to document the changes made - if we have the > patch pre-applied, with no reverse patch, then this isn't the case. > Asking folk to go elsewhere to get that 'pristine' source puts the onus > on the upstream to make that available, which we can't do - for the same > reason that folk that ship cygwin1.dll need to host their own copy of > the source. At the risk of wading into yet another GPL argument -- I don't think the GPL requires documentation of the entire provenance of changes relative to some external source; it's just the polite thing to do. All the GPL requires is that you distribute THE source that YOU used to build THE binary YOU distribute. That's it. --Chuck
RE: strange source packaging?
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 19, 2002 12:44 AM > of the antecedent project. There is no way, given just > gcc-2.95.3-5-src.tar.bz2, to "revert to the 'original' > source" -- short > of also downloading the 2.95.3 source from www.gcc.org, > unpacking both, > and doing 'diff -r cygwin-version-of-gcc gnu-version-of-gcc'. And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. Rob
RE: strange source packaging?
> -Original Message- > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 19, 2002 3:13 AM > I'll add another penny to make it 2c. I agree with Chris > that I'd rather already have the patch applied. Why? If it's for ease of use, then fine - I agree that what the user receives should be patched. However that is somewhat orthogonal to how the download is accomplished. > I > differences from pristine supplied would be nice but if I > really care I would go and find the originals. That's not actually the point. The point is that with some minor setup.exe tweaking, the source download can be done it two parts: 'pristine' + (patch[es] & scripts). Then when a local adjustment is made, but the upstream hasn't released a new version, users can get the new source trivially - setup should be smart enough to see the pristine tarball in the /usr/src (or wherever) directory and just download the appropriate patch set. Rob
Re: When to release a threaded cygwin Python?
On Fri, Apr 19, 2002 at 07:44:17AM -0400, Jason Tishler wrote: > Chris, > > On Fri, Mar 29, 2002 at 12:44:18PM -0500, Christopher Faylor wrote: > > On Fri, Mar 29, 2002 at 08:03:55AM -0500, Jason Tishler wrote: > > >Here's the deal. Although a threaded Cygwin Python runs just fine under > > >Cygwin 1.3.10, one cannot build one themselves without the following > > >patch to sys/features.h: > > > > > >http://sources.redhat.com/ml/newlib/2002/msg00122.html > > > > > >So, should I hold off releasing a new Python until 1.3.11? > > > > Yes. > > > > I'll release 1.3.11 when Corinna comes back from vacation. > > Is Corinna back from vacation? :,) Physically or psychically? ;-) Corinna
Re: When to release a threaded cygwin Python?
Chris, On Fri, Mar 29, 2002 at 12:44:18PM -0500, Christopher Faylor wrote: > On Fri, Mar 29, 2002 at 08:03:55AM -0500, Jason Tishler wrote: > >Here's the deal. Although a threaded Cygwin Python runs just fine under > >Cygwin 1.3.10, one cannot build one themselves without the following > >patch to sys/features.h: > > > >http://sources.redhat.com/ml/newlib/2002/msg00122.html > > > >So, should I hold off releasing a new Python until 1.3.11? > > Yes. > > I'll release 1.3.11 when Corinna comes back from vacation. Is Corinna back from vacation? :,) Jason
RE: FW: libtool devel package still dll crippled.
> > 1. When someone build a shared lib on linux and uses a static lib, are the > > symbols of the static lib automatically exported ? > > Yes, using a static lib is no different than compiling that code > directly into your codebase. Thats the behavior we have on cygwin, isn't it > > > 2a. If yes, and if someone build a second dll with the same static lib, the > > symbols of the static libs are in both > > shared lib defined. Then if someone uses these two shared libs to build for > > example an application, ld fails with duplicated symbol errors. How does ld > > prevent this ? > > ld checks the symbols in the shared libs during compile time to see if it can > resolve all symbols and appearantly also detects duplicated symbols. On Linux > it is not necassery impossible to have two libs that define the same symbols. > E.g. this feature can be used to override the malloc implementation of libc. > Of course when this happens inadvertently it can lead to unexpected > behaviour/crashes. ELF (The linking format used on Linux) has rather complex > rules for determining which symbol should be used if it is defined multiple > times. It also distinguishes between weak and strong symbols. It might be > that it is only possible to override weak-symbols and that multiple > strong-symbols result in link-errors. Does the cygwin ld has some similar rules ?
