Re: Consensus about man and doc X11 directory structure
On Wed, Oct 12, 2005 at 05:40:33PM -0400, Larry Hall (Cygwin X) wrote: >Christopher Faylor wrote: >>On Wed, Oct 12, 2005 at 03:08:50PM -0400, Larry Hall (Cygwin X) wrote: >> >>>Gary R. Van Sickle wrote: >>> [snip] >>1) How many of our BDs actually work for Red Hat anymore? > >1 (one) Harold also stated: "Look, it has been made quite clear to us on several occasions that Red Hat doesn't pay for anyone in their company to do development on Cygwin[...]" Is this correct? >>> >>>Yes, Chris has made this statement in the past. > >>Actually, Corinna does get paid to work on Cygwin from time to time but >>it isn't a full-time arrangement, AFAIK. I believe that the vast >>majority of what she does is on a volunteer basis, though. >> >>The last work that I did on Cygwin for Red Hat was entirely unpaid, >>however. I worked through Christmas 2003 implementing some >>thread-related signal handling stuff for a big customer. > > >My apologies. My memory must be going. > >My apologies. My memory must be going. Actually, sometimes I get over exuberant in proclaming that Red Hat doesn't really support Cygwin, so, it's entirely possible that I was unclear about this in the past. 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: Consensus about man and doc X11 directory structure
Christopher Faylor wrote: On Wed, Oct 12, 2005 at 03:08:50PM -0400, Larry Hall (Cygwin X) wrote: Gary R. Van Sickle wrote: [snip] 1) How many of our BDs actually work for Red Hat anymore? 1 (one) Harold also stated: "Look, it has been made quite clear to us on several occasions that Red Hat doesn't pay for anyone in their company to do development on Cygwin[...]" Is this correct? Yes, Chris has made this statement in the past. Actually, Corinna does get paid to work on Cygwin from time to time but it isn't a full-time arrangement, AFAIK. I believe that the vast majority of what she does is on a volunteer basis, though. The last work that I did on Cygwin for Red Hat was entirely unpaid, however. I worked through Christmas 2003 implementing some thread-related signal handling stuff for a big customer. My apologies. My memory must be going. My apologies. My memory must be going. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - 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: Consensus about man and doc X11 directory structure
On Wed, Oct 12, 2005 at 03:08:50PM -0400, Larry Hall (Cygwin X) wrote: >Gary R. Van Sickle wrote: >>[snip] 1) How many of our BDs actually work for Red Hat anymore? >>> >>>1 (one) >> >>Harold also stated: >>"Look, it has been made quite clear to us on several occasions that Red Hat >>doesn't pay for anyone in their company to do development on Cygwin[...]" >> >>Is this correct? > >Yes, Chris has made this statement in the past. Actually, Corinna does get paid to work on Cygwin from time to time but it isn't a full-time arrangement, AFAIK. I believe that the vast majority of what she does is on a volunteer basis, though. The last work that I did on Cygwin for Red Hat was entirely unpaid, however. I worked through Christmas 2003 implementing some thread-related signal handling stuff for a big customer. 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: Consensus about man and doc X11 directory structure
Gary R. Van Sickle wrote: [snip] 1) How many of our BDs actually work for Red Hat anymore? 1 (one) Harold also stated: "Look, it has been made quite clear to us on several occasions that Red Hat doesn't pay for anyone in their company to do development on Cygwin[...]" Is this correct? Yes, Chris has made this statement in the past. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - 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: Consensus about man and doc X11 directory structure
Harold L Hunt II wrote: Charles Wilson wrote: All of this mucking about with tk and insight requires the concurrence of -- and oodles of extra work by -- the tk maintainer and the insight maintainer. Plus, given the centrality of the debugger to the GNUPro product, this sort of change might meet resistance from the PowersThatBe channeled thru our local Benign Dictator(s). Look, it has been made quite clear to us on several occasions that Red Hat doesn't pay for anyone in their company to do development on Cygwin, so I say, "Who is Red Hat?". Why do they matter if they aren't contributing to the project and are either holding us hostage to supporting some long-gone product or secretly using our efforts to sell a couple million a year of some product that uses our work? Well, granted that cgf (current maintainer of tk and insight IIRC) no longer works for Red Hat, so perhaps their needs are no longer as important to him as they once were. OTOH, *personally*, I don't want the debugger to require X, for speed issues if nothing else. However, that's really cgf's decision so... How many people feel the same way when this argument about supporting Insight via Win32 Tk comes up? ... but I would just like to know how Red Hat gets to make decisions in this community that seems to get very little investment from them. I *said* it was speculation, and *speculated* that "pressure" might be applied -- not that decisions would be imposed -- by RH. Given Corinna's post, it seems that my speculation was (A) wrong (B) out-of-date, and (C) in all other ways immaterial. So we can drop the "WWRHD?" (What Would Red Hat Do?) from this thread, and move on to "what is the best(*) thing for the cygwin open-source community" in this regard? (*) where the definition of "best" is in the eye of the beholder: least disruptive? Most theoretically self-consistent? Provides path future growth/enhancement? etc... -- 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: Consensus about man and doc X11 directory structure
[snip] > > 1) How many of our BDs actually work for Red Hat anymore? > > 1 (one) > Harold also stated: "Look, it has been made quite clear to us on several occasions that Red Hat doesn't pay for anyone in their company to do development on Cygwin[...]" Is this correct? -- Gary R. Van Sickle -- 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: Consensus about man and doc X11 directory structure
Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Wilson wrote: Not gonna happen: it has been stated before on this list that 'insight' *must* run without X -- which means that tk will remain Win32GUI. Tk must remain Win32GUI, or *a* Win32GUI Tk must remain, for the sake of insight? It may be possible, eventually, to have both win32GUI-cygwin-runtime-tk and XGUI-cygwin-runtime-tk on the same machine, but nobody has undertaken the daunting task to make that happen. Ditto gtk. Others have mentioned building *NIX tcl/tk on Cygwin, and I wouldn't call building gtk2 daunting; I'm not personally interested, as I'm focusing on the X11 ports. However, I don't see the problem in assuming that GUI apps are presumed to be X-flavor (with the tk exception, above). If at some point somebody figures out how to build a similar GUI app/toolkit in the opposite flavor, it can go in /opt/. Static X based tcl/tk is doable now. I needed it because I had a X based tcl/tk app that didn't work right with the cyg native tcl/tk. dll's will take some effort and coordination upstream. Regards, Doug -- 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: Consensus about man and doc X11 directory structure
On Oct 10 21:59, Harold L Hunt II wrote: > Charles Wilson wrote: > >Yaakov S (Cygwin Ports) wrote: > [...] > >>What's stopping us from moving the Win32 tcltk in /opt/win32, and making > >>new *NIX tcl and tk packages in /usr? Then all that's necessary for > >>insight is to add /opt/win32 to PATH (either through a script, > >>profile.d, or manually). Similar packages (i.e. that have both X11/*NIX > >>and Win32 flavors) could use /opt/win32 as well. > > > > > >All of this mucking about with tk and insight requires the concurrence > >of -- and oodles of extra work by -- the tk maintainer and the insight > >maintainer. Plus, given the centrality of the > >debugger to the GNUPro product, this sort of change might meet > >resistance from the PowersThatBe channeled thru our local Benign > >Dictator(s). > > Umm... reality check: Fine with me. > 1) How many of our BDs actually work for Red Hat anymore? 1 (one) > 2) Is GNUPro even a product anymore? The only date I could find related > to the product mentioned "GNUPro 2001": > > http://www.redhat.com/software/gnupro/technical/gnupro_gdb.html Well, the marketing is fortunately not my job, but there is still a GnuPro product which is worked on regulary. Cygwin based toolchains are a part of it. > 3) If Red Hat isn't updating any product that uses Cygwin to provide a > product on Windows, then why are we holding onto this idea that we must > continue to support something that was once sold? > > 4) If Red Hat is updating GNUPro, but doing a piss-poor job of telling > people about it, then what are we? Red Hat's underground GNUPro > development team? I guess I can let this go uncommented. I have no idea how the marketing in relation to GnuPro works. That's not my business, so I can't tell anything about it. The layout of the Cygwin distro is not exactly something important to the way GnuPro works, however. Tcl/Tk is shipped with the Cygwin based GnuPro toolchains, so where it is in the distro is free for discussion. But, apart from GnuPro, I don't think it's such a good idea to move the Windows-based Tcl/Tk DLLs out of /usr/bin without having a clear idea how the replacement should work for the Windows-based apps like Insight. Even better, I don't think the DLLs should be moved somewhere else at all. The POSIX-based DLLs should follow the Cygwin naming convention anyway, so they would have to be named cygtcl8.4.dll/cygtk8.4.dll (or whatever the version number is right now). They don't collide with the Win-based ones, so what? As for the other stuff (includes, libs, /usr/share/tk8.4, etc), I think this would be ok to be moved to /opt or /usr/lib/win or something. However, how to handle the tcltk package and as a result, the GDB package, is up to Chris, he's the maintainer after all, not I or Red Hat. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- 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: Consensus about man and doc X11 directory structure
Charles Wilson wrote: Yaakov S (Cygwin Ports) wrote: [...] What's stopping us from moving the Win32 tcltk in /opt/win32, and making new *NIX tcl and tk packages in /usr? Then all that's necessary for insight is to add /opt/win32 to PATH (either through a script, profile.d, or manually). Similar packages (i.e. that have both X11/*NIX and Win32 flavors) could use /opt/win32 as well. All of this mucking about with tk and insight requires the concurrence of -- and oodles of extra work by -- the tk maintainer and the insight maintainer. Plus, given the centrality of the debugger to the GNUPro product, this sort of change might meet resistance from the PowersThatBe channeled thru our local Benign Dictator(s). Umm... reality check: 1) How many of our BDs actually work for Red Hat anymore? 2) Is GNUPro even a product anymore? The only date I could find related to the product mentioned "GNUPro 2001": http://www.redhat.com/software/gnupro/technical/gnupro_gdb.html 3) If Red Hat isn't updating any product that uses Cygwin to provide a product on Windows, then why are we holding onto this idea that we must continue to support something that was once sold? 4) If Red Hat is updating GNUPro, but doing a piss-poor job of telling people about it, then what are we? Red Hat's underground GNUPro development team? Look, it has been made quite clear to us on several occasions that Red Hat doesn't pay for anyone in their company to do development on Cygwin, so I say, "Who is Red Hat?". Why do they matter if they aren't contributing to the project and are either holding us hostage to supporting some long-gone product or secretly using our efforts to sell a couple million a year of some product that uses our work? Why do we kowtow to Red Hat when they appear to have abandoned the project, except possibly for some sales that benefit only them? This just doesn't make any sense to me. How many people feel the same way when this argument about supporting Insight via Win32 Tk comes up? I don't mean to be insulting and I'm not implying that I would do anything to overturn or route-around these decisions (since I really don't care about Tk and haven't got the time for a fight), but I would just like to know how Red Hat gets to make decisions in this community that seems to get very little investment from them. Harold -- 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: Consensus about man and doc X11 directory structure
Yaakov S (Cygwin Ports) wrote: Others have mentioned building *NIX tcl/tk on Cygwin, and I wouldn't call building gtk2 daunting; Daunting to build it in such a way that (a) the win32 version doesn't interfere with the X version, (b) vice versa, and (c) you're SURE that nothing win32-runtime 'leaks' into either version, but ONLY win32-GUI gets into the win32 version. I'm not personally interested, as I'm focusing on the X11 ports. What's stopping us from moving the Win32 tcltk in /opt/win32, and making new *NIX tcl and tk packages in /usr? Then all that's necessary for insight is to add /opt/win32 to PATH (either through a script, profile.d, or manually). Similar packages (i.e. that have both X11/*NIX and Win32 flavors) could use /opt/win32 as well. All of this mucking about with tk and insight requires the concurrence of -- and oodles of extra work by -- the tk maintainer and the insight maintainer. Plus, given the centrality of the debugger to the GNUPro product, this sort of change might meet resistance from the PowersThatBe channeled thru our local Benign Dictator(s). Good luck with that. -- 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: Consensus about man and doc X11 directory structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Wilson wrote: > Not gonna happen: it has been stated before on this list that 'insight' > *must* run without X -- which means that tk will remain Win32GUI. Tk must remain Win32GUI, or *a* Win32GUI Tk must remain, for the sake of insight? > It may be possible, eventually, to have both win32GUI-cygwin-runtime-tk > and XGUI-cygwin-runtime-tk on the same machine, but nobody has > undertaken the daunting task to make that happen. Ditto gtk. Others have mentioned building *NIX tcl/tk on Cygwin, and I wouldn't call building gtk2 daunting; I'm not personally interested, as I'm focusing on the X11 ports. > However, I don't see the problem in assuming that GUI apps are presumed > to be X-flavor (with the tk exception, above). If at some point > somebody figures out how to build a similar GUI app/toolkit in the > opposite flavor, it can go in /opt/. What's stopping us from moving the Win32 tcltk in /opt/win32, and making new *NIX tcl and tk packages in /usr? Then all that's necessary for insight is to add /opt/win32 to PATH (either through a script, profile.d, or manually). Similar packages (i.e. that have both X11/*NIX and Win32 flavors) could use /opt/win32 as well. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDSyMSpiWmPGlmQSMRAlCrAJwOhWNKN88hXnK+UasAHCeCDDpBhQCgtjSE LrtlZOCNUN3xcI1gQoT0VFw= =Yz4+ -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: Consensus about man and doc X11 directory structure
Yaakov S (Cygwin Ports) wrote: What does "Cygwin native" mean? If Cygwin is meant to be a POSIX environment, then X11 should be the standard for GUI apps. Not gonna happen: it has been stated before on this list that 'insight' *must* run without X -- which means that tk will remain Win32GUI. It may be possible, eventually, to have both win32GUI-cygwin-runtime-tk and XGUI-cygwin-runtime-tk on the same machine, but nobody has undertaken the daunting task to make that happen. Ditto gtk. However, I don't see the problem in assuming that GUI apps are presumed to be X-flavor (with the tk exception, above). If at some point somebody figures out how to build a similar GUI app/toolkit in the opposite flavor, it can go in /opt/. -- 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: Consensus about man and doc X11 directory structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Ford wrote: > Why do you propose keeping a distinct X11R6 tree yet puting documentation > outside it. I would prefer these to be consistent. FWIW, Debian and Gentoo both do as proposed. > IIRC, Harold had decided to eliminate the X11R6 subtree and cgf agreed. I > guess that was the direction Xorg and several Linux distros were taking. Gentoo did this already with X11R6.8.2. I would agree, with the upcoming modular, autotooled X11R7, that the whole reason for the /usr/X11R6 exception to the FHS no longer applies. > IMHO, that was not desirable. Eventually I could imagine X11 and > Cygwin native versions of the same package. I liked this method of making > the distinction. What does "Cygwin native" mean? If Cygwin is meant to be a POSIX environment, then X11 should be the standard for GUI apps. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDSxA9piWmPGlmQSMRAuwZAKDT0/fkqzHEkuTcXba3eAq5ugQdEwCfdFmN 7TlTParj9ElUf0IGi1wFWVc= =5BME -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: Consensus about man and doc X11 directory structure
On Mon, 10 Oct 2005, Dr. Volker Zell wrote: > I propose that documentation in general should go to /usr/share/doc/$PACKAGE > even for X11 packages and the main man page directory should be dictated > by the generic X11 tree, which is right now /usr/X11R6/man/manX (X=1,) > > Any comments ? Why do you propose keeping a distinct X11R6 tree yet puting documentation outside it. I would prefer these to be consistent. IIRC, Harold had decided to eliminate the X11R6 subtree and cgf agreed. I guess that was the direction Xorg and several Linux distros were taking. http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00228.html IMHO, that was not desirable. Eventually I could imagine X11 and Cygwin native versions of the same package. I liked this method of making the distinction. > The situation right now is: [snip] > Docs pages not belonging to the x11-org packages: > = > > /usr/X11R6/doc: > > fvwm-2.4.7 > lesstif-0.93.94 > libPropList-0.10.1 > openbox-0.99.1 > transfig-3.2.4 <- empty > x2x-1.30 > Xaw3d-1.5D > xfig-3.2.4 > xgraph-12.1 > xpdf-0.91 I believe these are simply packages that have not been updated since the FHS standards began being enforced. > /usr/X11R6/share/doc: > > xorg-x11-xwin > freeglut-2.2.0 > gv-3.5.8 > libXft-2.1.6 > nedit-5.5 > tcm-2.20 > WindowMaker-0.90.0 > X-start-menu-icons-1.0.3 > X-startup-scripts-1.0.10 > x3270-3.2.20 > XmHTML-1.1.7 > xwinclip-1.2.0 These would appear correct from my point of view. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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/
Consensus about man and doc X11 directory structure
Hi all As you all know by now, Corinna is hunting for our vacant package maintainers. So may be it's a good idea to also have consensus about our X11 directory structure regarding man pages and documentation. I propose that documentation in general should go to /usr/share/doc/$PACKAGE even for X11 packages and the main man page directory should be dictated by the generic X11 tree, which is right now /usr/X11R6/man/manX (X=1,) Any comments ? The situation right now is: Man pages not belonging to the x11-org packages: WindowMaker-0.90.0-2 /usr/X11R6/share/man/man1/geticonset.1x /usr/X11R6/share/man/man1/getstyle.1x /usr/X11R6/share/man/man1/seticons.1x /usr/X11R6/share/man/man1/setstyle.1x /usr/X11R6/share/man/man1/wdwrite.1x /usr/X11R6/share/man/man1/wmaker.1x /usr/X11R6/share/man/man1/wmsetbg.1x /usr/X11R6/share/man/man1/wxcopy.1x /usr/X11R6/share/man/man1/wxpaste.1x /usr/X11R6/share/man/sk/man1/geticonset.1x /usr/X11R6/share/man/sk/man1/getstyle.1x /usr/X11R6/share/man/sk/man1/seticons.1x /usr/X11R6/share/man/sk/man1/setstyle.1x /usr/X11R6/share/man/sk/man1/wdwrite.1x /usr/X11R6/share/man/sk/man1/wmaker.1x /usr/X11R6/share/man/sk/man1/wmsetbg.1x /usr/X11R6/share/man/sk/man1/wxcopy.1x /usr/X11R6/share/man/sk/man1/wxpaste.1x tetex-x11-3.0.0-3 /usr/X11R6/share/man/man1/mf.1 /usr/X11R6/share/man/man1/mfw.1 /usr/X11R6/share/man/man1/oxdvi.1 /usr/X11R6/share/man/man1/xdvi.1 /usr/X11R6/share/man/man1/xdvizilla.1 libXft-2.1.6-1 /usr/X11R6/share/man/man3/Xft.3 x3270-3.2.20-1 /usr/X11R6/man/man1/x3270.1<-- inconsistent in itself /usr/X11R6/share/man/man1/x3270-script.1 /usr/X11R6/share/man/man1/x3270if.1 /usr/X11R6/share/man/man5/ibm_hosts.5 Docs pages not belonging to the x11-org packages: = /usr/X11R6/doc: fvwm-2.4.7 lesstif-0.93.94 libPropList-0.10.1 openbox-0.99.1 transfig-3.2.4 <- empty x2x-1.30 Xaw3d-1.5D xfig-3.2.4 xgraph-12.1 xpdf-0.91 /usr/X11R6/share/doc: xorg-x11-xwin freeglut-2.2.0 gv-3.5.8 libXft-2.1.6 nedit-5.5 tcm-2.20 WindowMaker-0.90.0 X-start-menu-icons-1.0.3 X-startup-scripts-1.0.10 x3270-3.2.20 XmHTML-1.1.7 xwinclip-1.2.0 Ciao Volker -- 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/
