* Repositories for Cygwin packages. @ 2015-09-10 20:40 David A Cobb 2015-09-10 21:03 ` Marco Atzeri ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: David A Cobb @ 2015-09-10 20:40 UTC (permalink / raw) To: cygwin I see the Git Repo for "the core Cygwin libraries and utilities (Cygwin and Newlib)" @ sourceware.com. I am looking at possible work within *COREUTILS*. Obviously, there are significant deltas /versus/ GNU Upstream. Can you point me to the active repo for coreutils? Just to save net traffic, I'll dare post a second related question in the same message: Is *NEWLIB* intended to be a "drop-in" replacement for *GNULIB*? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Repositories for Cygwin packages. 2015-09-10 20:40 Repositories for Cygwin packages David A Cobb @ 2015-09-10 21:03 ` Marco Atzeri 2015-09-10 21:57 ` Eric Blake [not found] ` <FZ3x1r00P2qVqVd01Z3ytt> 2 siblings, 0 replies; 6+ messages in thread From: Marco Atzeri @ 2015-09-10 21:03 UTC (permalink / raw) To: cygwin On 10/09/2015 22:40, David A Cobb wrote: > I see the Git Repo for "the core Cygwin libraries and utilities (Cygwin > and Newlib)" @ sourceware.com. > > I am looking at possible work within *COREUTILS*. Obviously, there are > significant deltas /versus/ GNU Upstream. > Can you point me to the active repo for coreutils? http://www.gnu.org/software/coreutils/coreutils.html > > Just to save net traffic, I'll dare post a second related question in > the same message: > Is *NEWLIB* intended to be a "drop-in" replacement for *GNULIB*? No. https://sourceware.org/newlib/ https://www.gnu.org/software/gnulib/MODULES.html Roughly: Newlib target is to provide a system libc. Gnulib target is to provide a modular library implementation for software that aim on multi-platform builds. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Repositories for Cygwin packages. 2015-09-10 20:40 Repositories for Cygwin packages David A Cobb 2015-09-10 21:03 ` Marco Atzeri @ 2015-09-10 21:57 ` Eric Blake [not found] ` <FZ3x1r00P2qVqVd01Z3ytt> 2 siblings, 0 replies; 6+ messages in thread From: Eric Blake @ 2015-09-10 21:57 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2123 bytes --] On 09/10/2015 02:40 PM, David A Cobb wrote: > I see the Git Repo for "the core Cygwin libraries and utilities (Cygwin > and Newlib)" @ sourceware.com. > > I am looking at possible work within *COREUTILS*. Obviously, there are > significant deltas /versus/ GNU Upstream. > Can you point me to the active repo for coreutils? The official upstream repo, or something that tracks the cygwin deltas? I don't (currently) maintain the cygwin deltas in git; what you see in the setup.exe source package downloads is all I've ever published. If you really have something to patch for coreutils that is cygwin-specific rather than upstream, then maybe I can revisit this and expose a repo somewhere (I absolutely refuse to use github as the primary location, because that site unfortunately encourages non-free practices, but it wouldn't stop you from setting up a github mirror to whatever other place I would publish). But first post such cygwin-specific patches to this list, to prove that the work to set up and maintain a repo of patches is going to be worth my time. > > Just to save net traffic, I'll dare post a second related question in > the same message: > Is *NEWLIB* intended to be a "drop-in" replacement for *GNULIB*? Not even close to one another. Think of newlib as a [near] drop-in replacement for glibc, and gnulib as a set of source files for adding portability across multiple platforms (gnulib is closer to what boost does for C++). Cygwin requires newlib (I'm not sure why it did not choose glibc, but suspect that it is probably more of a licensing reason than a technical reason) in order to provide libc, but does not need to use gnulib (there is no need for providing cross-platform compatibility when compiling cygwin1.dll for a specific platform). Meanwhile, projects like coreutils include portions of gnulib (so coreutils can be compiled for more than just cygwin) but not newlib (because it relies on dynamic linking against the system libc). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <FZ3x1r00P2qVqVd01Z3ytt>]
* Re: Repositories for Cygwin packages. [not found] ` <FZ3x1r00P2qVqVd01Z3ytt> @ 2015-09-10 23:20 ` David A Cobb 2015-09-10 23:31 ` Eric Blake [not found] ` <FbXq1r00M2qVqVd01bXrPy> 0 siblings, 2 replies; 6+ messages in thread From: David A Cobb @ 2015-09-10 23:20 UTC (permalink / raw) To: cygwin, marco.atzeri On 2015-09-10 17:03, Marco Atzeri wrote: > On 10/09/2015 22:40, David A Cobb wrote: >> I see the Git Repo for "the core Cygwin libraries and utilities (Cygwin >> and Newlib)" @ sourceware.com. >> >> I am looking at possible work within *COREUTILS*. Obviously, there are >> significant deltas /versus/ GNU Upstream. >> Can you point me to the active repo for coreutils? > > http://www.gnu.org/software/coreutils/coreutils.html Yeah, Marco. Thanks. Actually, the repo is <git://git.savannah.gnu.org/coreutils.git>. Are you saying that is your direct upstream and your sources only differ by the patchfiles installed by Cygwin-Setup?? >> >> Just to save net traffic, I'll dare post a second related question in >> the same message: >> Is *NEWLIB* intended to be a "drop-in" replacement for *GNULIB*? > > No. > https://sourceware.org/newlib/ > https://www.gnu.org/software/gnulib/MODULES.html > > Roughly: > Newlib target is to provide a system libc. > > Gnulib target is to provide a modular library implementation for > software that aim on multi-platform builds. > Regards > Marco > I should have phrased the question differently, I guess. My question is related to dependencies of the 'coreutils.' Cloning GNU Coreutils comes in with sub-module 'gnulib'. Suppose I wanted to propose a patch to Coreutils, but being stuck on a Windows platform I use Coreutils only through Cygwin64 and MSYS2. And, suppose for the moment, some of the changes are only relevant to the Windows platform. I don't (yet) know how much GNU (i.e. RMS) really gives a flying bird about making Windows play nice. So, to whom do I propose the changes? I really, really don't want to create a private fork. If I didn't think my ideas are worthy of pushing up the food chain, I should just go back to bed. BTW, and totally irrelevant to the discussion, I'm not really a newbie here. But for several years I had a working Ubuntu installation, so I didn't keep up with the list. And now, I'm back on a borrowed Windows machine. I just want to do some useful stuff on it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Repositories for Cygwin packages. 2015-09-10 23:20 ` David A Cobb @ 2015-09-10 23:31 ` Eric Blake [not found] ` <FbXq1r00M2qVqVd01bXrPy> 1 sibling, 0 replies; 6+ messages in thread From: Eric Blake @ 2015-09-10 23:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2731 bytes --] On 09/10/2015 05:20 PM, David A Cobb wrote: >>> I am looking at possible work within *COREUTILS*. Obviously, there are >>> significant deltas /versus/ GNU Upstream. >>> Can you point me to the active repo for coreutils? >> >> http://www.gnu.org/software/coreutils/coreutils.html > > Yeah, Marco. Thanks. > Actually, the repo is <git://git.savannah.gnu.org/coreutils.git>. > > Are you saying that is your direct upstream and your sources only differ > by the patchfiles installed by Cygwin-Setup?? Yes, the cygwin build of coreutils is made by taking the upstream tarball release (which is created from the upstream coreutils.git at labeled points in time) and then adding additional patches which are distributed (as required by the GPL) in the source package that you can download using setup.exe. >> > I should have phrased the question differently, I guess. My question > is related to dependencies of the 'coreutils.' Cloning GNU Coreutils > comes in with sub-module 'gnulib'. > > Suppose I wanted to propose a patch to Coreutils, but being stuck on a > Windows platform I use Coreutils only through Cygwin64 and MSYS2. Not a problem. My first patch to upstream coreutils was done exactly in that manner. > And, suppose for the moment, some of the changes are only relevant to > the Windows platform. I don't (yet) know how much GNU (i.e. RMS) really > gives a flying bird about making Windows play nice. So, to whom do I > propose the changes? I really, really don't want to create a private > fork. If I didn't think my ideas are worthy of pushing up the food > chain, I should just go back to bed. Depends on how invasive your changes are. If it is truly windows-specific and hard to maintain, then upstream probably won't pay attention (which is why I maintain some cygwin-specific patches, such as .exe magic manipulations, downstream-only). But if it fixes a bad upstream assumption (such as "function foo would never do that", except that on cygwin function foo DOES do that, and it is feasible that some other system would do likewise), then upstream is the right place. (For example, my very first patch to upstream coreutils is dated 2005-01-11, where I fixed Makefile.am to deal with $(EXEEXT) - and more than just cygwin creates binaries with .exe suffix so it is relevant upstream). If you're unsure whether a proposed patch is worth posting upstream or downstream, pick one place, and I'm more than willing to help you redirect it to the other place if it wasn't appropriate. (Picking upstream first is generally a nicer policy). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <FbXq1r00M2qVqVd01bXrPy>]
* Re: Repositories for Cygwin packages. [not found] ` <FbXq1r00M2qVqVd01bXrPy> @ 2015-09-10 23:54 ` David A Cobb 0 siblings, 0 replies; 6+ messages in thread From: David A Cobb @ 2015-09-10 23:54 UTC (permalink / raw) To: eblake, Cygwin Mailing List On 2015-09-10 19:31, Eric Blake wrote: > On 09/10/2015 05:20 PM, David A Cobb wrote: > > Not a problem. My first patch to upstream coreutils was done exactly > in that manner. >> And, suppose for the moment, some of the changes are only relevant to >> the Windows platform. I don't (yet) know how much GNU (i.e. RMS) really >> gives a flying bird about making Windows play nice. So, to whom do I >> propose the changes? I really, really don't want to create a private >> fork. If I didn't think my ideas are worthy of pushing up the food >> chain, I should just go back to bed. > Depends on how invasive your changes are. If it is truly > windows-specific and hard to maintain, then upstream probably won't pay > attention (which is why I maintain some cygwin-specific patches, such as > .exe magic manipulations, downstream-only). But if it fixes a bad > upstream assumption (such as "function foo would never do that", except > that on cygwin function foo DOES do that, and it is feasible that some > other system would do likewise), then upstream is the right place. (For > example, my very first patch to upstream coreutils is dated 2005-01-11, > where I fixed Makefile.am to deal with $(EXEEXT) - and more than just > cygwin creates binaries with .exe suffix so it is relevant upstream). > > If you're unsure whether a proposed patch is worth posting upstream or > downstream, pick one place, and I'm more than willing to help you > redirect it to the other place if it wasn't appropriate. (Picking > upstream first is generally a nicer policy). OK, I think I've got it. At my advanced age, it's hard to be sure ;-D. Thank you Eric, Marco, and Corrina. Especially for your patience when more research would probably have answered a lot of things. I'm made especially sensitive because, once on a very long ago, I asked a question about 'newlib' and Windows in the same sentence, and had my posterior handed back to me on a platter with the advice that anything with my name on it would be instantly disapproved by the newlib owner. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-09-10 23:54 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-09-10 20:40 Repositories for Cygwin packages David A Cobb 2015-09-10 21:03 ` Marco Atzeri 2015-09-10 21:57 ` Eric Blake [not found] ` <FZ3x1r00P2qVqVd01Z3ytt> 2015-09-10 23:20 ` David A Cobb 2015-09-10 23:31 ` Eric Blake [not found] ` <FbXq1r00M2qVqVd01bXrPy> 2015-09-10 23:54 ` David A Cobb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).