Re: New Maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | The only real difference is that the *nixes would provide only the DLL | (so) package 'libxext6' and the -devel package 'libxext-devel'; there's | nothing specific in this case that really needs to go in a base | package 'libxext'. However, in Cygwin's case I've noticed that | setup.exe (at least in the past) got annoyed if you have: | foo-*-src.tar.bz2 | libfoo6-*.tar.bz2 (external-source: foo) | libfoo-devel-*.tar.bz2 (external-source: foo) | but do not have | foo-*.tar.bz2 | Maybe this is a bug in setup and we should fix it, or maybe it is not a | problem anymore. In any case, we need to put the cygwin README, and the | normal README/THANKS/AUTHORS/ChangeLog goobledygook somewhere. Might | as well be in the (otherwise empty) foo-*.tar.bz2 package. FWIW, I've just added support for empty packages in cygport; i.e. the following is now legal: abi=6 PKG_NAMES=foo libfoo$abi libfoo-devel PKG_HINTS=setup lib devel PKG_CONTENTS[0]= PKG_CONTENTS[1]=usr/bin/*-$abi.dll usr/share/doc/ PKG_CONTENTS[2]=usr/include/ usr/lib/ usr/share/man/man3/ (The $abi is my trick to make sure I don't miss an ABI change in what may otherwise appear to be an ordinary version bump.) | As it happens, Yaakov chose to put the man3 docs in the main foo-* | package, instead of the libfoo-devel-* package. I'd probably do it more | like the *nixes, in this case. But really, is THIS significant? No, but I see your point, and future Ports releases will have in the devel package. (An X11 refresh will have to wait *at least* until I'm finished with GNOME 2.22, which is in progress.) Now if I could only figure out that server... Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkhIpN4ACgkQpiWmPGlmQSOpugCgwH7tmnUS9Y8i9VSOw6KY0510 gHAAoIO7jZwSW777UPaEpD8JgYZ+8iqK =EC8B -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: New Maintainer
After looking into this further, it doesn't look as if porting the current X.org code to Cygwin is going to be straightforward, particularly since our group has no prior expertise with Cygwin porting or packaging. Thus, I don't think that maintaining Cygwin/X is something that we are going to be able to tackle. The general consensus is that we have much less expertise with Cygwin and X.org than you guys do and certainly less than the cygwinports people. Yet neither community has been able to port xorg-server to Cygwin, so what hope do we have? In any sense, our main justification for porting the most recent X.org code to Cygwin was to provide a vehicle for introducing some new patches to enable certain features that are needed by our project (VirtualGL.) But on further reconsideration, that seems to be tantamount to building our own highway to improve our car's gas mileage. I wish you all the best. Darrell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Wilson Sent: Friday, March 28, 2008 12:09 PM To: cygwin-xfree@cygwin.com Subject: Re: New Maintainer Christopher Faylor wrote: On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote: DRC wrote: Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? Given the new modular structure of the X.org releases, it seems to me that each module should be treated independently. However, that being said, each module may represent multiple tarballs. E.g. I don't think it makes sense to invent a new scheme for what goes where. Just pick a distro (Fedora, Gentoo, SuSE, Ubuntu, etc.) and mimic that. Chris, this is NOT a new scheme, and the linux distros' methods cannot be directly mapped to cygwin with regards to shared libraries, because .so's != dlls, and ld.so != Windows Runtime Loader. There will always be some differences between our packaging and the *nixes. But in this particular case, what is new about the breakdown iisted below? Doesn't it map almost exactly to how Fedora distributes libXext in rpms? libXext-1.0.3-1-src.tar.bz2 libXext-1.0.3-1.tar.bz2 libXext-devel-1.0.3-1.tar.bz2 libXext6-1.0.3-1.tar.bz2 (These filenames were taken directly from Yaakov's libXext cygport.) The only real difference is that the *nixes would provide only the DLL (so) package 'libxext6' and the -devel package 'libxext-devel'; there's nothing specific in this case that really needs to go in a base package 'libxext'. However, in Cygwin's case I've noticed that setup.exe (at least in the past) got annoyed if you have: foo-*-src.tar.bz2 libfoo6-*.tar.bz2 (external-source: foo) libfoo-devel-*.tar.bz2 (external-source: foo) but do not have foo-*.tar.bz2 Maybe this is a bug in setup and we should fix it, or maybe it is not a problem anymore. In any case, we need to put the cygwin README, and the normal README/THANKS/AUTHORS/ChangeLog goobledygook somewhere. Might as well be in the (otherwise empty) foo-*.tar.bz2 package. As it happens, Yaakov chose to put the man3 docs in the main foo-* package, instead of the libfoo-devel-* package. I'd probably do it more like the *nixes, in this case. But really, is THIS significant? We can and should, of course, use the Linux distro's packaging choices as informed guidance, and I'm sure that's exactly what Yaakov did when he created his cygports. (The *nixes whose X components are based on the modular X.org source DO treat each module as independent subsets [that is, separate *.src.rpm's, separate lib*N rpms, separate lib*-devel rpms etc]...although they naturally tend to update/release them in simultaineous waves). Frankly, I'd want to make things as easy as possible for the new X maintainer -- and since an experienced, knowledgeable person has already done a HUGE portion of the necessary work, I'd /start/ with Yaakov's cygports...and *maybe* make some slight modifications if SuSe/Fedora/Debian did something the new X maintainer particularly likes. (Not the other way around, as you seem to suggest). My email was an attempt to explain the general way that dll-providing cygwin packagesets are and should be subdivided, with a short description of the 'why' behind it all. It's the way I've been providing DLL packagesets since 2002 or before. I'm surprised you consider it new. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ
Re: New Maintainer
On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote: DRC wrote: Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? Given the new modular structure of the X.org releases, it seems to me that each module should be treated independently. However, that being said, each module may represent multiple tarballs. E.g. I don't think it makes sense to invent a new scheme for what goes where. Just pick a distro (Fedora, Gentoo, SuSE, Ubuntu, etc.) and mimic that. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: New Maintainer
Christopher Faylor wrote: On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote: DRC wrote: Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? Given the new modular structure of the X.org releases, it seems to me that each module should be treated independently. However, that being said, each module may represent multiple tarballs. E.g. I don't think it makes sense to invent a new scheme for what goes where. Just pick a distro (Fedora, Gentoo, SuSE, Ubuntu, etc.) and mimic that. Chris, this is NOT a new scheme, and the linux distros' methods cannot be directly mapped to cygwin with regards to shared libraries, because .so's != dlls, and ld.so != Windows Runtime Loader. There will always be some differences between our packaging and the *nixes. But in this particular case, what is new about the breakdown iisted below? Doesn't it map almost exactly to how Fedora distributes libXext in rpms? libXext-1.0.3-1-src.tar.bz2 libXext-1.0.3-1.tar.bz2 libXext-devel-1.0.3-1.tar.bz2 libXext6-1.0.3-1.tar.bz2 (These filenames were taken directly from Yaakov's libXext cygport.) The only real difference is that the *nixes would provide only the DLL (so) package 'libxext6' and the -devel package 'libxext-devel'; there's nothing specific in this case that really needs to go in a base package 'libxext'. However, in Cygwin's case I've noticed that setup.exe (at least in the past) got annoyed if you have: foo-*-src.tar.bz2 libfoo6-*.tar.bz2 (external-source: foo) libfoo-devel-*.tar.bz2 (external-source: foo) but do not have foo-*.tar.bz2 Maybe this is a bug in setup and we should fix it, or maybe it is not a problem anymore. In any case, we need to put the cygwin README, and the normal README/THANKS/AUTHORS/ChangeLog goobledygook somewhere. Might as well be in the (otherwise empty) foo-*.tar.bz2 package. As it happens, Yaakov chose to put the man3 docs in the main foo-* package, instead of the libfoo-devel-* package. I'd probably do it more like the *nixes, in this case. But really, is THIS significant? We can and should, of course, use the Linux distro's packaging choices as informed guidance, and I'm sure that's exactly what Yaakov did when he created his cygports. (The *nixes whose X components are based on the modular X.org source DO treat each module as independent subsets [that is, separate *.src.rpm's, separate lib*N rpms, separate lib*-devel rpms etc]...although they naturally tend to update/release them in simultaineous waves). Frankly, I'd want to make things as easy as possible for the new X maintainer -- and since an experienced, knowledgeable person has already done a HUGE portion of the necessary work, I'd /start/ with Yaakov's cygports...and *maybe* make some slight modifications if SuSe/Fedora/Debian did something the new X maintainer particularly likes. (Not the other way around, as you seem to suggest). My email was an attempt to explain the general way that dll-providing cygwin packagesets are and should be subdivided, with a short description of the 'why' behind it all. It's the way I've been providing DLL packagesets since 2002 or before. I'm surprised you consider it new. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: New Maintainer
It's pretty simple. You have to package new new releases of X.org for Cygwin and support people on this mailing list. Well, I'm willing to give it a try at least. I know nothing about Cygwin packaging, but I have experience building X.org on Windows. My project (VirtualGL) needs Cygwin/X because of its support of the MIT-SHM extension, and we have access to plenty of build machines. Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? I assume that part of the duties are to also feed back patches into the master X.org repository to fix the Cygwin build, etc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: New Maintainer
DRC wrote: It's pretty simple. You have to package new new releases of X.org for Cygwin and support people on this mailing list. Well, I'm willing to give it a try at least. I know nothing about Cygwin packaging, but I have experience building X.org on Windows. My project (VirtualGL) needs Cygwin/X because of its support of the MIT-SHM extension, and we have access to plenty of build machines. Sounds terrific! :-) Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? You can find a bunch of info about packaging here: http://cygwin.com/setup.html The one thing that's somewhat dated is the use of gbs as the packaging method. I haven't looked but I expect the current X packages use that. While it's still possible to use, 'cygport' is preferred. But it's still the choice of the maintainer. It is best to stick with one of the existing options though since there's some familiarity with them in the community. I assume that part of the duties are to also feed back patches into the master X.org repository to fix the Cygwin build, etc. Yes, definitely. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: New Maintainer
On Thu, Mar 27, 2008 at 01:56:56PM -0500, DRC wrote: It's pretty simple. You have to package new new releases of X.org for Cygwin and support people on this mailing list. Well, I'm willing to give it a try at least. I know nothing about Cygwin packaging, but I have experience building X.org on Windows. My project (VirtualGL) needs Cygwin/X because of its support of the MIT-SHM extension, and we have access to plenty of build machines. Is there a spec for which files go in which packages, etc.? Any other advice to get started, or should I just start downloading and tinkering? I assume that part of the duties are to also feed back patches into the master X.org repository to fix the Cygwin build, etc. You'll certainly have our undying gratitude if you are willing to do this. As to what goes into the packages, what is there now is a good starting point but anything else is up to you. The best place to ask about packaging issues is cygwin-apps. If you send a query there you should find that a lot of people will have advice. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
New Maintainer
Hi. We are interested in maintaining Cygwin/X and would like more info on what that would entail. Darrell Commander The VirtualGL Project -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: New Maintainer
On Wed, Mar 26, 2008 at 06:31:48PM -0500, DRC wrote: Hi. We are interested in maintaining Cygwin/X and would like more info on what that would entail. It's pretty simple. You have to package new new releases of X.org for Cygwin and support people on this mailing list. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
