Re: [PATCH] Stop automatic dependency selection on setup.exe chooser screen
On 7 August 2010 18:14, Christopher Faylor wrote: On Sat, Aug 07, 2010 at 10:56:48AM +0200, Corinna Vinschen wrote: Please go ahead and check it in, after testing. What's this after testing thing? Oh. Wait. Nevermind. Good idea. I've tortured it a fair bit, including trying to delete random packages, setting Keep, Prev, and Exp, and selecting all packages (whereby the resolver finds a bunch of obsolete packages that still need to be added). I didn't see anything untoward, but of course that's no guarantee for anything. We could really do with some sort of beta testing scheme for setup.exe. Still, I'm confident 2.711 is better than 2.708. The main concern I have about the dependency checking now is the amount of time it takes. On my netbook, it's about a minute with all packages selected, so that's pretty much the worst case. I think this is due to packagedb::findBinary, which is called for every dependency, doing a linear search through all packages. I suspect a precomputed map could make quite a difference there. Andy
Re: [PATCH] Stop automatic dependency selection on setup.exe chooser screen
On Aug 7 12:21, Andy Koppe wrote: On 7 August 2010 10:20, Corinna Vinschen wrote: Maybe it's better to provide as much information as possible. What about this: libao (1.0.0-1) Cross-Platform Audio Output Library (Transition) Required by: libao4, libao-devel libao-devel (1.0.0-1) Cross-Platform Audio Output Library (Development) Required by: libao libao4 (1.0.0-1) Cross-Platform Audio Output Library (Runtime) Required by: vorbis-tools, libao, libao-devel [...] This looks good, I agree it's worth providing all that info. I checked this in. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
gcc4-core PACKAGE BUG
Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Either /etc/postinstall/gcc4-core.sh should call the script like this: sh /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh or the script should be executable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITP: rtorret, libtorrent, libsigc++
On 2010/08/07 8:30 PM, Chris Sutcliffe wrote: Hi Chuck, Thank you for your thorough review of the packaging and the associated patches. I've decided for ligsigc++ and libtorrent to make the base packages the license packages as opposed to having '-lic' packages. I've made all the changes you recommended and included Corinna's updated d_reclen change. I have uploaded all new versions of the packages: libsigc++-2.0-2.2.8-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc++/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/libsigc++2.0_0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/libsigc++2.0-devel-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/libsigc++2.0-doc-2.2.8-1.tar.bz2 libtorrent-0.12.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libtorrent/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/libtorrent11-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/libtorrent-devel-0.12.6-1.tar.bz2 rtorrent-0.8.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/setup.hint \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1.tar.bz2 My preliminary testing of the rtorrent client has been positive. Everything seems to be working as expected so far. Excellent! Some notes about the packaging: The setup.hints of the libtorrent subpackages (libtorrent11 and libtorrent-devel) are missing their 'external-source: libtorrent' line. The setup.hint of libtorrent11 is missing 'libsigc++2.0_0' from its 'requires:' line (likely a typo, missing the trailing _0). The setup.hint of libsigc++2.0_0 is missing 'libgcc1' and 'libstdc++6' from its 'requires:' line. The setup.hint of rtorrent is missing 'libgcc1' and 'libsigc++2.0_0' from its 'requires:' line (the latter is, again, likely a typo). The setup.hints of the libsigc++2.0 subpackages are missing 'libsigc++2.0' from their 'requires:' lines. The setup.hints of the libtorrent subpackages are missing 'libtorrent' from their 'requires:' lines. Best regards, -SM --
build-docbook-catalog PACKAGE BUG
Hi Yaakov, I just encountered a problem with the postinstall scripts of docbook-xml42 and docbook-xsl, an exit code of 1. Both postinstall scripts depend on the /usr/bin/build-docbook-catalog script which in turn calls xmlcatalog --noout --create /etc/xml/catalog The problem here is that xmlcatalog fails if the parent directory, here /etc/xml, does not exist. However, the build-docbook-catalog does neither check the existence of the /etc/xml dir, nor does it make any attempt to mkdir it. As soo as I mkdir the /etc/xml directory, the docbook-xml42.sh and docbook-xsl.sh postinstall scripts work as expected. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITP: rtorret, libtorrent, libsigc++
On 8/8/2010 12:59 PM, Steven Monai wrote: Some notes about the packaging: The setup.hints of the libtorrent subpackages (libtorrent11 and libtorrent-devel) are missing their 'external-source: libtorrent' line. Odd...my local (modified) copy has these; I wonder if the patch I posted for Chris somehow missed this change. In any case, Steven is right and the most recent version of these files are missing the external-source line. The setup.hint of libtorrent11 is missing 'libsigc++2.0_0' from its 'requires:' line (likely a typo, missing the trailing _0). My fault: my local modified copy also has this typo. Also, I think libtorrent11 should list libgcc1 as a requirement, in addition to libstdc++6, since cygtorrent-11.dll has a direct dependence on both libraries (in addition to the others already listed). Also, the libtorrent Cygwin README claims that various docu is in the development package, but it is not. It's in the main package. The setup.hints of the libtorrent subpackages are missing 'libtorrent' from their 'requires:' lines. Well, yes, they are missing that requirement. But that's because libtorrent is NOT a requirement for libtorrent11 nor libtorrent-devel. It only provides some text documentation; why should those other packages require it? The setup.hint of libsigc++2.0_0 is missing 'libgcc1' and 'libstdc++6' from its 'requires:' line. My fault, again. I thought I fixed that, but my locally modified copy does NOT actually contain these requirements; if Chris took my updates directly, well... This also means that the libsigc++2.0 Cygwin README is missing the following runtime requirements: libgcc1-4.3.4-3 libstdc++6-4.3.4-3 The setup.hints of the libsigc++2.0 subpackages are missing 'libsigc++2.0' from their 'requires:' lines. Again, the libsigc++2.0 package provides nothing but documentation. Why should those subpackages require it? The setup.hint of rtorrent is missing 'libgcc1' and 'libsigc++2.0_0' from its 'requires:' line (the latter is, again, likely a typo). Steven is correct here, too. The typo is in my (locally modified) copy, too -- so blame me for that one. However, my locally modified copy has libgcc1 so I'm not sure how it went missing. Furthermore, the rtorrent Cygwin README needs a similar update (libsigc++2.0 - libsigc++2.0_0) under its runtime requirements list. Also, that README is missing the following runtime requirements: libncursesw10 libgcc1 It's also missing the following build requirements: libsigc++2.0-devel libstdc++-devel (*) (*) all three Cygwin READMEs are probably missing this one; I thought it came with the gcc4-g++ package but apparently not. All three READMEs should probably list gcc4-g++ as a build requirement as well (we often elide the obvious build requirements like gcc, binutils, make, and bash -- and cygport/patch/tar/gz/bz2/xz, but the need for a C++ compiler should probably be spelled out explicitly in the README). -- Chuck
Re: ITP: rtorret, libtorrent, libsigc++
On 8 August 2010 14:48, Charles Wilson wrote: On 8/8/2010 12:59 PM, Steven Monai wrote: Some notes about the packaging: The setup.hints of the libtorrent subpackages (libtorrent11 and libtorrent-devel) are missing their 'external-source: libtorrent' line. Odd...my local (modified) copy has these; I wonder if the patch I posted for Chris somehow missed this change. In any case, Steven is right and the most recent version of these files are missing the external-source line. My bad, I didn't use your patches directly, I cut-and-paste the relevant parts and apparently missed a few things. Also, the libtorrent Cygwin README claims that various docu is in the development package, but it is not. It's in the main package. Erm... it actually should say: Files included in the licensing package: usr/share/doc/libtorrent/AUTHORS usr/share/doc/libtorrent/COPYING usr/share/doc/libtorrent/NEWS usr/share/doc/libtorrent/README where the 'licensing' package is the 'main' package. I've hopefully captured all the recommended changes and I'm hoping the third time is the charm: libsigc++-2.0-2.2.8-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc++/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/libsigc++2.0_0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/libsigc++2.0-devel-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/libsigc++2.0-doc-2.2.8-1.tar.bz2 libtorrent-0.12.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libtorrent/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/libtorrent11-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/libtorrent-devel-0.12.6-1.tar.bz2 rtorrent-0.8.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/setup.hint \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1.tar.bz2 Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: ITP: rtorret, libtorrent, libsigc++
On 2010/08/08 11:48 AM, Charles Wilson wrote: On 8/8/2010 12:59 PM, Steven Monai wrote: Some notes about the packaging: The setup.hints of the libtorrent subpackages are missing 'libtorrent' from their 'requires:' lines. Well, yes, they are missing that requirement. But that's because libtorrent is NOT a requirement for libtorrent11 nor libtorrent-devel. It only provides some text documentation; why should those other packages require it? Practically speaking, yes, it is true that the subpackages don't really require the text docs provided by the libtorrent package to correctly perform their function. However, the entire raison d'etre for the libtorrent package seems to be to provide the text docs that upstream intends to accompany the library. So personally, I would make all of libtorrent's subpackages require libtorrent, so that the upstream text docs (including the COPYING file, which contains the GPL license notice) are always installed when any of the subpackages are installed. It is ultimately the packager's decision about how best to distribute the GPL notice with the software. In this case, making the subpackages require the libtorrent package would be an easy way to accomplish that, but it's certainly not the only way. It's really up to Chris to decide. The setup.hints of the libsigc++2.0 subpackages are missing 'libsigc++2.0' from their 'requires:' lines. Again, the libsigc++2.0 package provides nothing but documentation. Why should those subpackages require it? See above, s/libtorrent/libsigc++2.0/ -SM --
Re: ITP: rtorret, libtorrent, libsigc++
On 8 August 2010 16:40, Steven Monai wrote: Practically speaking, yes, it is true that the subpackages don't really require the text docs provided by the libtorrent package to correctly perform their function. However, the entire raison d'etre for the libtorrent package seems to be to provide the text docs that upstream intends to accompany the library. So personally, I would make all of libtorrent's subpackages require libtorrent, so that the upstream text docs (including the COPYING file, which contains the GPL license notice) are always installed when any of the subpackages are installed. It is ultimately the packager's decision about how best to distribute the GPL notice with the software. In this case, making the subpackages require the libtorrent package would be an easy way to accomplish that, but it's certainly not the only way. It's really up to Chris to decide. Valid point. I'll change the hint files for libtorrent and libsigc++ and upload new versions shortly. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: ITP: rtorret, libtorrent, libsigc++
On 8 August 2010 16:45, Chris Sutcliffe wrote: Valid point. I'll change the hint files for libtorrent and libsigc++ and upload new versions shortly. Done: libsigc++-2.0-2.2.8-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc++/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/libsigc++2.0_0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/libsigc++2.0-devel-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/libsigc++2.0-doc-2.2.8-1.tar.bz2 libtorrent-0.12.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libtorrent/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/libtorrent11-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/libtorrent-devel-0.12.6-1.tar.bz2 rtorrent-0.8.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/setup.hint \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1.tar.bz2 Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
[ITP] gnucap - initial questions
The Gnu Circuit Analysis Package has a stable version 0.35 from 2006 and a very usable dev version from December 2009. I have found it useful in my work, and considerably easier than trying to compile SPICE or find a decent free SPICE binary. There are already Debian and Fedora packages. It compiles in Cygwin with an extremely simple 5 line patch, which has not changed over multiple releases from the 2006 version to today. Is there interest in making it a Cygwin package? I'm willing to put together a current package, but I'm not confident that I can handle porting future releases if they require more complicated patching. Perhaps someone else would be willing to take this up? I would lean towards making the initial package the latest dev version and the previous version the stable 0.35 release; what is standard practice? Best, Peter
Re: [ITP] gnucap - initial questions
On Sun, 2010-08-08 at 20:10 -0700, Peter Li wrote: The Gnu Circuit Analysis Package has a stable version 0.35 from 2006 and a very usable dev version from December 2009. I have found it useful in my work, and considerably easier than trying to compile SPICE or find a decent free SPICE binary. There are already Debian and Fedora packages. It compiles in Cygwin with an extremely simple 5 line patch, which has not changed over multiple releases from the 2006 version to today. I did not need a patch to build gnucap; I just added -DRTLD_LOCAL=0 (ahem!) to CPPFLAGS. Did you need something besides that? Is there interest in making it a Cygwin package? I'm willing to put together a current package, but I'm not confident that I can handle porting future releases if they require more complicated patching. Perhaps someone else would be willing to take this up? If it hasn't needed extensive patching for such a long time, I doubt it would in the future. If you want to maintain this within the distro, please feel free to borrow from Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=science/gnucap This isn't the latest devel version, but should be plenty to get you started. I would lean towards making the initial package the latest dev version and the previous version the stable 0.35 release; what is standard practice? The main distros seem to stick with 0.35, so perhaps you want to make 0.35 curr: and the latest dev as test:, if you feel a need to support both. Yaakov
X hardware acceleration still flaky?
Well, it's been eighteen months since I last asked: http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install. Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4. Has any work been attempted on improving hardware acceleration in xwin-gl? thanks, L. SaVi satellite constellation visualization http://savi.sf.net/ -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. I think it's a good idea anyway though to drain the message queue before invoking select() on /dev/windows, except if there's a possibility that message handling blocks out events on other files for too long. That's because select() has a lot more overhead than PeekMessage. Andy -- 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: X hardware acceleration still flaky?
On 08/08/2010 10:18, l.w...@surrey.ac.uk wrote: Well, it's been eighteen months since I last asked: http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install. Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4. I'm not sure what you were testing here, but I can't see how it could be hardware AIGLX. xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running that somehow, it must be an old version, which I am surprised works at all. Alternatively, you are using xwin with software rendering, and your application exposes some bug in the Xserver which makes it crash. I am happy to work with you to resolve these issues. Has any work been attempted on improving hardware acceleration in xwin-gl? Yes, this is something I have been working on in my copious free time(TM): http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html http://x.cygwin.com/devel/todo.html I hope you'll note that savi is one of the applications I've been testing with. However, given the lack of response so far, it seems that you and me are the only 2 people interested in working AIGLX for XWin :-) I wouldn't suggest testing with those binaries at this stage, as I've moved on a bit. I hope to shortly make another test release containing AIGLX based on the upcoming Xserver 1.9, and I would very much appreciate some testing of the AIGLX functionality in that, when it is available. [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: XWin crash after the launch of startkde on a remote Red Hat 5 machine
On 06/08/2010 13:55, Michel Hummel wrote:
I didn't saw any response to my patch proposition, did someone tried it ?
If I didn't posted it in the good place where should I have to
Yes, this is abolutely the right place for your patch.
It looks good and I shall incorporate it in the next X server release.
I will be happy to explain the problem if my first mail wasn't clear.
Nope, the analysis was very clear, thank you.
I wonder if there also exists a race condition when the clipboard thread is
stopping? i.e. if we try to start a new one just as the old one is stopping,
we think it is still running and fail to do so?
In general this code could do with a tidy up: I think it would be much more
sensible to have a long-lived thread which tries to reconnect to the server
when ever it gets disconnected, it would avoid all this complexity and the
complexity of trying to avoid being killed by GDM as well.
2010/8/3 Michel Hummelhummel.mic...@gmail.com:
Hello,
I'm using cygwin on Microsoft Windows XP with XWin version :
sh-3.2# XWin.exe -version
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.8.0.0 (1080)
Build Date: 2010-04-02
Contact: cygwin-xfree@cygwin.com
I think I have found a bug in the XWin reset procedure which leads to
the start of two clipboard thread's and sometime to a crash of the X
server.
The crash can be produced by lauching startkde on a Red Hat 5 remote
machine (The crash should arrive after some minutes of work)
but the bug can simply be produced like this :
On my installation if I launch Xwin with this options :
XWin :0 -ac
then I do
xsetroot -solid '#00'
After setting the color, Xwin launches its reset procedure because
there is no more client connected ( the server loses the color but it
is the normal comportment isn't it ?
http://sourceware.org/ml/cygwin-xfree/2002-01/msg00106.html)
The problem comes from the clipboard thread. In this example, when the
server launches its reset procedure, the clipboard is in state
Launched but is not in state Started (Boolean variable about
clipboard status, see file hw/xwin/winclipboardthread.c).
This particular status of the ClipboardThread during server reset is
normaly managed by two if statements :
* An if in the file hw/xwin/InitOutput.c disables the exit of the
clipboard thread in this state
Extract of the file hw/xwin/InitOutput.c (with line number) :
169 winClipboardShutdown (void)
170 {
171 /* Close down clipboard resources */
172 if (g_fClipboard g_fClipboardLaunched g_fClipboardStarted)
173 {
174 /* Synchronously destroy the clipboard window */
175 if (g_hwndClipboard != NULL)
176 {
177 SendMessage (g_hwndClipboard, WM_DESTROY, 0, 0);
178 /* NOTE: g_hwndClipboard is set to NULL in
winclipboardthread.c */
179 }
180 else
181 return;
182
183 /* Wait for the clipboard thread to exit */
184 pthread_join (g_ptClipboardProc, NULL);
185
186 g_fClipboardLaunched = FALSE;
187 g_fClipboardStarted = FALSE;
188
189 winDebug (winClipboardShutdown - Clipboard thread has exited.\n);
190 }
191 }
* An if statement in the file hw/xwin/winclipboardwrappers.c
prohibits the launch of clipboard thread if one is already Launched.
Extract of the file hw/xwin/winclipboardwrappers.c (with line number)
256 /* If the clipboard client has already been started, abort */
257 if (g_fClipboardLaunched)
258 {
259 ErrorF (winProcEstablishConnection - Clipboard client already
260 launched, returning.\n);
261 return iReturn;
262 }
The problem is that the Boolean variables g_fClipboardLaunched and
g_fClipboardStarted are re-initialized by the server reset procedure
(function winInitializeGlobals of the file hw/xwin/winglobals.c)
Extract of the file hw/xwin/winglobals.c (with line number)
128 /*
129 * Re-initialize global variables that are invalidated 130 * by a
server reset.
131 */
132
133 void
134 winInitializeGlobals (void)
135 {
136 g_dwCurrentThreadID = GetCurrentThreadId ();
137 g_hwndKeyboardFocus = NULL;
138 #ifdef XWIN_CLIPBOARD
139 g_fClipboardLaunched = FALSE;
140 g_fClipboardStarted = FALSE;
141 g_iClipboardWindow = None;
142 g_pClipboardDisplay = NULL;
143 g_atomLastOwnedSelection = None;
144 g_hwndClipboard = NULL;
145 #endif
146 }
The consequence of this Re-initialization in this particular situation
is that the clipboard thread is launched two times and sometimes leads
to a crash of the X server.
You can see the double launch of the clipboard thread at the end of
the attached log file Xwin.0.log ( 2 times the sentence :
winClipboardProc - XOpenDisplay () returned and successfully opened
the display. )
To fix this bug I purpose to remove the variables g_fClipboardLaunched
and g_fClipboardStarted of the winInitializeGlobals (void) function,
as their re-initializations are handled in in the files :
Re: X hardware acceleration still flaky?
Hi Jon, I just downloaded the current X server and its libraries in the Cygwin distro; the xwin-gl allusion came from the previous thread I mentioned. Compiling geomview 1.9.4 --with-opengl is straightforward (that's one improvement on pre-7.4 X; configure doesn't get confused about X library locations and building is easier). I then tried running savi with geomview: - using OpenGL. 30 seconds of slow flickering (slow enough to be the software rendering that you alluded to?), then the X server consistently crashes, even before I've had a chance to turn on texturemapping... - forcing internal geomview software rendering using geomview -noopengl -run ../savi1.4.3/savi $* . Works, but is rather stately. No texturemapping support, obviously. Less slow than the brief opengl attempt, though, which figures given that doing OpenGL in software imposes more layers of overhead? That's the status from testing with what cygwin ships at the moment. I haven't tried your older binaries. Please let me know when you get to another test release, and I'll try it out. thanks, L. SaVi satellite constellation visualization http://savi.sf.net/ On 8 Aug 2010, at 13:57, Jon TURNEY wrote: On 08/08/2010 10:18, l.w...@surrey.ac.uk wrote: Well, it's been eighteen months since I last asked: http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install. Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4. I'm not sure what you were testing here, but I can't see how it could be hardware AIGLX. xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running that somehow, it must be an old version, which I am surprised works at all. Alternatively, you are using xwin with software rendering, and your application exposes some bug in the Xserver which makes it crash. I am happy to work with you to resolve these issues. Has any work been attempted on improving hardware acceleration in xwin-gl? Yes, this is something I have been working on in my copious free time(TM): http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html http://x.cygwin.com/devel/todo.html I hope you'll note that savi is one of the applications I've been testing with. However, given the lack of response so far, it seems that you and me are the only 2 people interested in working AIGLX for XWin :-) I wouldn't suggest testing with those binaries at this stage, as I've moved on a bit. I hope to shortly make another test release containing AIGLX based on the upcoming Xserver 1.9, and I would very much appreciate some testing of the AIGLX functionality in that, when it is available. [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: [PATCH] define RTLD_LOCAL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yaakov (Cygwin/X) wrote, On 8.8.2010 7:49: POSIX requires RTLD_LOCAL to be defined in dlfcn.h[1]. While our dlopen() does nothing with its second argument, portable software can rightfully expect the definition to exist alongside the other RTLD_* macros. So why 0? POSIX states wrt dlopen()[2]: If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, then the default behavior is unspecified. On Linux, RTLD_LOCAL is the default behaviour[3], and hence is defined as 0[4], therefore I have done the same here. Patch attached. Since this doesn't actually do anything, I wasn't sure if I should bump CYGWIN_VERSION_API_MINOR for this or not; I can certainly do so before committing if desired. Is it not undefined in Cygwin because Windows cannot support the behaviour? AFAIK once you do LoadLibrary(A.dll) then any subsequent reference to A.dll and its exports will be satisfied from the already loaded A.dll. IOW, Windows cannot satisfy The object's symbols shall not be made available for the relocation processing of any other object, as specified by [2]. [1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/dlfcn.h.html [2] http://www.opengroup.org/onlinepubs/9699919799/functions/dlopen.html [3] http://linux.die.net/man/3/dlopen [4] http://sourceware.org/git/?p=glibc.git;a=blob;f=bits/dlfcn.h - -- VH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkxebDkACgkQeqrf2dJjGj7uMgEAhtmcXzuborabjWbPCGe6VkoL fo9QyIkvBajGyB9RGp0A/iD+lz/brm33xFvDJ1mZ3SIYorSNGXr3ZXbFPHjTma1Q =Ap0W -END PGP SIGNATURE-
Re: [PATCH] POSIX monotonic clock
On Sun, Aug 08, 2010 at 12:06:18AM -0500, Yaakov (Cygwin/X) wrote: On Tue, 2010-08-03 at 10:04 -0400, Christopher Faylor wrote: On Tue, Aug 03, 2010 at 09:32:47AM +0200, V??clav Haisman wrote: This looks like you could get monotonic clock going backwards. That's a good point. We have that very problem here where I work. However, Yaakov isn't adding anything new here so, if this is a problem, it would be a long-standing one. It sounds like it would be trivially solvable by setting the processor affinity mask but I'm not sure what that would mean for performance. So should I hold off on my patch until this can be fixed? Nah. Go ahead. Thanks. cgf
Opening .n extensions
Hi, First of all I would like to Thank You! in advance for answering this question. I read the 'stupid question' warnings, read through the forum topics, searched dogpile, google, and yahoo search engines and could not find the answer. I admit ahead of time to having a rudimentary understanding of the subject at hand, however I did try everything I knew and your suggestions. That said, I am trying to find the program to download so I can open picture files sent to me by friends from there cell phones to mine. When my phone said the files were too large and was unable to open the files I downloaded them to my computer to open. Windows said it needed to go to the internet to obtain the program to open the file. I went onto the web and no programs, [save expensive file extension repair] were to be found. When I looked up the extension, every listing had the '.n' extension as yours. I have attached one of the files so you can see it. It has been checked for viruses. I apologize again for my ignorance. I did not know who or where else to ask. Thank you in advance for your Job like patience and understanding. I have a: ASUS Notebook G60 Series Intel (R) Core (TM) i5 CPU 4.00 GB Installed memory 64-bit Operating System Running Windows 7 Home Premium A Complete Novice, Luetta 17.n Description: Binary data -- 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
Re: Opening .n extensions
On 8 August 2010 08:23, Luetta wrote: First of all I would like to Thank You! in advance for answering this question. I read the 'stupid question' warnings, read through the forum topics, searched dogpile, google, and yahoo search engines and could not find the answer. I admit ahead of time to having a rudimentary understanding of the subject at hand, however I did try everything I knew and your suggestions. That said, I am trying to find the program to download so I can open picture files sent to me by friends from there cell phones to mine. When my phone said the files were too large and was unable to open the files I downloaded them to my computer to open. Windows said it needed to go to the internet to obtain the program to open the file. I went onto the web and no programs, [save expensive file extension repair] were to be found. When I looked up the extension, every listing had the '.n' extension as yours. I have attached one of the files so you can see it. It has been checked for viruses. I apologize again for my ignorance. I did not know who or where else to ask. Thank you in advance for your Job like patience and understanding. I'm afraid we can't help with this here. Cygwin does use the .n extension on some documentation files (man pages), but that's clearly not what you're looking for. Andy -- 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
Accessing SMB shares without explicit mounting
In order to cut down on the overall time my backups are taking, I am thinking of running flexbackup under cygwin. However, I will want it to write to a directory I have shared from my Linux box using samba, without mounting it explicitly. I understand that this at least ought to be possible using a UNC path (//server/share) but all attempts to list the current content are showing it to be empty. If I try to access a file I know to be there, or to create a new one, I get Permission denied. I can clearly see that the shares are there, but cannot make any practical use of them. I am therefore left in the position of having to seek advice on this. The permissions do allow the shares to be mounted in Windows, but in the case of this particular one, I am looking for it not to be mounted. I am quite happy to post further details if needed. Thanks, Phil Reynolds. This message was sent using IMP, the Internet Messaging Program. -- 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
Re: Opening .n extensions
On 8/08/2010 7:23 p.m., Luetta wrote: [..] When my phone said the files were too large and was unable to open the files I downloaded them to my computer to open. Windows said it needed to go to the internet to obtain the program to open the file. I went onto the web and no programs, [save expensive file extension repair] were to be found. When I looked up the extension, every listing had the '.n' extension as yours. I have attached one of the files so you can see it. It has been checked for viruses. I apologize again for my ignorance. I did not know who or where else to ask. Thank you in advance for your Job like patience and understanding. That file does not contain an image, it is only 168 characters long which is far too small to have a useful photo in it. It seems to contain a pointer to a website where you can download the image from, but I don't know the format of the .n file so I'm unsure of the correct link. It will probably be a format specific to that particular cell provider and understood only by their phone software. It looks like the image is supposed to be visible at: http://mmsc.gci.csky.us:6672/m1?4q4rdk4Z_/w4~u9Z4~~~4kc3KHRukT But the server just returns a file not found error. Either I didn't figure out the link format correctly, or the image has now expired from the server. Cheers, Nicholas Sherlock -- 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
Re: Moses with Cygwin on Windows 7
Dear Eliot, your script does indeed sound much better. Is it available to share? Many thanks for sharing your insights in any case. Best regards, Llio Humphreys Quoting Eliot Moss m...@cs.umass.edu: On 8/7/2010 5:23 PM, cbs...@bangor.ac.uk wrote: many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native windows build of Moses does not currently use IRSTLM LMs. I know next to nothing about Moses, so I'll just trust you on this one! I have been reading up a bit about debasing DLLs, and I gather from http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more DLLs using the same preferred base addresses, or the overheads of relocation. However, on http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df-4087-9c4b-847880d625ad, it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? The problem is that the address space randomization interferes with how cygwin support fork(). Suppose a parent process maps library A at address X, but does not map library B at all. Then suppose a forked process is not yet using library A, and ends up mapping library B at an address that overlaps X. Then the child reaches a point where it needs to use library A. The implementation of cygwin requires that if a parent and child use the same library, it must be at the same address. Therefore the child's mapping attempt will block. That gives a sense of the scenario. That may not be the exact case, but it's like that. Basically, we need to guarantee that all cygwin dlls map to different preferred places. Yes, this defeats the OS attempt to defeat a security attack. My script finds and rebases every dll file that cygwin 'find' can locate, while rebaseall only does certain directories. For me, the difference lies in (at least) some perl-related dlls that are not where rebaseall looks. Another important thing is that the distance between preferred locations needs to be a little bigger than the default for rebase, on Vista (and Windows 7). This is an obscure thing that Corinna found a while back and took me quite a while to locate in old email threads, but before I set that parameter, rebasing did not work right for me and after adding that it did. Maybe they have changed the default by now, but I don't think so. Re UAC prompts: this does look annoying but corporate security regulations may prevent us from turning it off completely. Is there some way to turn it off for individual programs without using third-party software? That lies outside my expertise. I just turned it off. Best wishes -- Eliot Moss This message was sent using IMP, the Internet Messaging Program. -- 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
Re: Moses with Cygwin on Windows 7
Dear Morgan, thanks for the tip. Can you turn it off for only some recognised programs? It does not mention this option in Microsoft's online Guided Help (http://support.microsoft.com/kb/975788). Unfortunately, I don't have Windows 7 yet so I can't test it myself. Thanks, Llio Humphreys Quoting Morgan Gangwere 0.fracta...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/2010 05:33 PM, Eliot Moss wrote: [snip] Windows 7 has a setting /just/ below the default which turns off the Secure Desktop (Pet name for UAC prompts). If you have some amount of administrator access, you can probably disable them. - -- Morgan Gangwere 0 dotpunct fractalus atpunct gmail dotpunct com http://sonof.bandit.name/ あなたのお母さんは、ハムスターとあなたの父エルダーベリーのワカサギでした - - A frenchman. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMXiwXAAoJEEURiCSotvJDFBsP/13kN+WbgQNzw03Jxp6w3XAc P6ailneZS5s03/wO/OdnQJiQ7B5iKAlZEKp9qZ4wcLUDaBpQxIGbVrT0umRMB/r2 osMEY8TErQ/Vlro9AknRi2BvSPe1iit0Lm7jQhRPIMnnraYwzziKJWwDUuSXTREE cj5p9sWgyzvLmtTphVm1kDF94csRBkk9qQI4WLooODGkJeDMP5oFyKRX1mzNYV62 M9QZSr8/QWmXQs9lT3F2bkLRJGBrmUyfoLayNJ4+1BnNl7FfGHGQc0UqpqhHD8sD DvbXe3b7y7LPjb/dTGqGj4P3AuCZxNgtrYOuFfP4v/MZoyhj41SwjifBBFDKin97 u3sgVUXRJuSbNnzNIOPL5dk6U8nb2zo4enNzqdBNi4XfmJsidlAYhjWgGWCbfkRU 6uuJA4hAIrf/07Co/oG7q9jI7mueEIGTvxqguR67cNw+aRrCLWyNsLBOTCOUfRY3 TOjG5WBdO3MTO819V/KJdlpJ46vn37atvnvN7IELy/dWkpR7dLzBuinHDU1+V36g gUDtHNNC/Bv/Yb/c+Qp4umG8aeqRA+scLGToPdc1+bpV9MEk7ps3yfYK4xrmsb8b yCY6UNtqVdQlmCeVNV0CTjGtkdcTiJbfo8glHKUcBI6vYqCmTnp5Mw3qrBgtHeiB 92ieQKVSh9r6cg4M2hGR =K8NM -END PGP SIGNATURE- -- 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 This message was sent using IMP, the Internet Messaging Program. -- 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
Re: Opening .n extensions
I guess I would also mention that you could learn to use the cygwin tools to figure this out on your own later :) The above file not found after the story could even be due to the lack of phone related headers in the request if this mumbo jumbo is designed to lock you to certain devices. If you got some utilities to examine binary contents and then get files with spoofed headers you could probably eventually figure it out. Suffixes are sometimes modified to prevent malicious code from executing automaticlly or to fool mail software that otherwise does something clever when you just want to send a file through without modification. The strategy here is sometimes to look at what is in the file with a binary dump utility and then go from there- this is probably what the poster above did. Also dumping the ASCII strings can help too etc etc. Software that creates artificial barriers is always of interest and I use these tools sometimes to open suspicious mail just to see what is in it. AFAIK there is no general tool set ( or mind set LOL) in windoze that lets you approach this other than something like cygwin so you did at least come to a good place. On 8/8/10, Nicholas Sherlock n.sherl...@gmail.com wrote: On 8/08/2010 7:23 p.m., Luetta wrote: [..] When my phone said the files were too large and was unable to open the files I downloaded them to my computer to open. Windows said it needed to go to the internet to obtain the program to open the file. I went onto the web and no programs, [save expensive file extension repair] were to be found. When I looked up the extension, every listing had the '.n' extension as yours. I have attached one of the files so you can see it. It has been checked for viruses. I apologize again for my ignorance. I did not know who or where else to ask. Thank you in advance for your Job like patience and understanding. That file does not contain an image, it is only 168 characters long which is far too small to have a useful photo in it. It seems to contain a pointer to a website where you can download the image from, but I don't know the format of the .n file so I'm unsure of the correct link. It will probably be a format specific to that particular cell provider and understood only by their phone software. It looks like the image is supposed to be visible at: http://mmsc.gci.csky.us:6672/m1?4q4rdk4Z_/w4~u9Z4~~~4kc3KHRukT But the server just returns a file not found error. Either I didn't figure out the link format correctly, or the image has now expired from the server. Cheers, Nicholas Sherlock -- 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 -- marchy...@gmail.com note new address 2009-12-16: Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)- use this 404-788-1216 (C)- leave message 989-348-4796 (P)- emergency only marchy...@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: hotmail is censoring incoming mail using random criteria beyond my control and often hangs my browser but all my subscriptions are here..., try also marchy...@yahoo.com -- 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
Re: Accessing SMB shares without explicit mounting
On 08/08/2010 03:42 AM, Phil Reynolds wrote: In order to cut down on the overall time my backups are taking, I am thinking of running flexbackup under cygwin. However, I will want it to write to a directory I have shared from my Linux box using samba, without mounting it explicitly. I understand that this at least ought to be possible using a UNC path (//server/share) but all attempts to list the current content are showing it to be empty. If I try to access a file I know to be there, or to create a new one, I get Permission denied. I can clearly see that the shares are there, but cannot make any practical use of them. I am therefore left in the position of having to seek advice on this. The permissions do allow the shares to be mounted in Windows, but in the case of this particular one, I am looking for it not to be mounted. It sounds like your Samba configuration requires authentication in order to access this share. Are you able to access the share as \\server\share using the Windows file explorer without first mapping the share to a drive or authenticating in some other way? Cygwin uses Windows to handle this sort of operation, so if Windows can't access the share without authentication, neither can Cygwin. If authentication is required, you'll either need to map the share to a drive letter or reconfigure your Samba share to allow guests to have read and possibly write access depending on your needs. -Jeremy -- 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
Re: Accessing SMB shares without explicit mounting
Quoting Jeremy Bopp jer...@bopp.net: It sounds like your Samba configuration requires authentication in order to access this share. Are you able to access the share as \\server\share using the Windows file explorer without first mapping the share to a drive or authenticating in some other way? Cygwin uses Windows to handle this sort of operation, so if Windows can't access the share without authentication, neither can Cygwin. If authentication is required, you'll either need to map the share to a drive letter or reconfigure your Samba share to allow guests to have read and possibly write access depending on your needs. Thank you - this has pointed me in the right direction... The main problem I've got now is how to allow write access to the share from this scenario without allowing it from outside... but I am working on that. -- Phil Reynolds mail: p...@tinsleyviaduct.com Web: http://www.tinsleyviaduct.com/phil/ Waltham 66, Emley Moor 69, Droitwich 79, Windows 95 This message was sent using IMP, the Internet Messaging Program. -- 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
Re: Accessing SMB shares without explicit mounting
On 08/08/2010 12:40 PM, Phil Reynolds wrote: Quoting Jeremy Bopp jer...@bopp.net: It sounds like your Samba configuration requires authentication in order to access this share. Are you able to access the share as \\server\share using the Windows file explorer without first mapping the share to a drive or authenticating in some other way? Cygwin uses Windows to handle this sort of operation, so if Windows can't access the share without authentication, neither can Cygwin. If authentication is required, you'll either need to map the share to a drive letter or reconfigure your Samba share to allow guests to have read and possibly write access depending on your needs. Thank you - this has pointed me in the right direction... The main problem I've got now is how to allow write access to the share from this scenario without allowing it from outside... but I am working on that. Might you be able to do something like: net use \\server\share /user:[domain\]username password To access the share supplying the username and password so that you can then use the UNC path proper? For example: Pluto:net use jupiter\\Video /user:username password The command completed successfully. Pluto:net use New connections will not be remembered. Status Local RemoteNetwork --- OK \\jupiter\Video Microsoft Windows Network The command completed successfully. Pluto: -- Andrew DeFaria http://defaria.com If an orange is orange, why isn't a lime called a green or a lemon called a yellow? -- 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
Re: Opening .n extensions
On 8/8/2010 4:54 AM, Nicholas Sherlock wrote: On 8/08/2010 7:23 p.m., Luetta wrote: The 168 byte length strongly suggests that it is a 160 byte SMS (text) message with a few extra bytes added by the phone for its own purposes. And the contents suggest that as well, though why they are not more readable lies beyond my knowledge ... Eliot Moss -- 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
Re: Problem with subversion-apache2
Again, http://cygwin.com/acronyms/#PCYMTNQREAIYR. Don't feed the spammers. On 8/6/2010 8:22 PM, Brian Wilson wrote: Yep, I made sure to shut down all cygwin applications I am aware of that were running which were shown in the Windows Services. Unfortunately I don't know what the errorno 6 means. $ net helpmsg 6 The handle is invalid. So it seems that you have an outdated dash. Try updating that first then rerun rebaseall. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: mkpasswd (434): [31] A device attached to the system is not functioning.
On 8/7/2010 4:46 PM, Linda Walsh wrote: I'm willing to try again if anything has improved. But there were also issues about me signing off contracts to Redhat or something -- not something normal to most open source projects...and that was a bit of a put off as well. Has anything changed? I believe you are confused. There are no contracts involved to build Cygwin. You would be asked to fill out an assignment form if you're contributing anything of significant amount back (with what constitutes significant being defined by Red Hat). I won't speculate about the particular conversation you refer to and how this came up or to what it was referring specifically. But if you're just looking for instructions on building Cygwin, they're in the FAQ: http://cygwin.com/faq/faq-nochunks.html#faq.programming.building-cygwin I'll let you be the judge of whether anything there has changed from the last time you tried to build the DLL. It is, however, worth noting that building the DLL is *not* necessary to build mkpasswd. Certainly it's easiest if you just grab the source for everything from CVS but if you're just looking to be able to debug your mkpasswd issue, I'd recommend foregoing any efforts, at least at the moment, to build the Cygwin DLL. You won't need to do that to investigate the problem with which you started this thread. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Possible pipe(2) bug
I think the pipe(2) implementation may have a bug. The pipe function creates a pipe and returns two file descriptors (which are just numbers), one for reading and one for writing. However sometimes (but rarely) two subsequent calls to the pipe function returns the same file descriptor twice. That is normal when a file descriptor 'number' is re-used after being closed first, but otherwise it is wrong. To demonstrate the problem I wrote a simple program (attached as test.c) that does the following: 1. Create three pipes, so we get 6 file descriptors 2. (dump the FD's we got) 3. Close 3 of the 6 file descriptors 4. (Dump the FD's that were closed) 5. Repeat steps 1-4 a 100 times The first three rounds give sound results: 0 opened: pipe1=(3, 4), pipe2=(5, 6), pipe3=(7, 8) 0 closed: pipe1[0]=3, pipe2[1]=6, pipe3[1]=8 1 opened: pipe1=(3, 6), pipe2=(8, 9), pipe3=(10, 11) 1 closed: pipe1[0]=3, pipe2[1]=9, pipe3[1]=11 2 opened: pipe1=(3, 9), pipe2=(11, 12), pipe3=(13, 14) 2 closed: pipe1[0]=3, pipe2[1]=12, pipe3[1]=14 ... As can be seen the FD's that were closed are re-used next round. Perfectly fine. But then suddenly at round 94... 93 opened: pipe1=(3, 282), pipe2=(284, 285), pipe3=(286, 287) 93 closed: pipe1[0]=3, pipe2[1]=285, pipe3[1]=287 94 opened: pipe1=(3, 285), pipe2=(287, 288), pipe3=(287, 289) - File descriptor 287 is issued twice! I think this is a bug. It actually causes problems under certain circumstances when running a Cygwin build of nodejs (http://nodejs.org). Or am I just doing something stupid? Thanks for your time - Bert cygcheck.out Description: cygcheck.out test.c Description: test.c test.out Description: test.out -- 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
Re: Opening .n extensions
Eliot Moss moss at cs.umass.edu writes: On 8/8/2010 4:54 AM, Nicholas Sherlock wrote: On 8/08/2010 7:23 p.m., Luetta wrote: The 168 byte length strongly suggests that it is a 160 byte SMS (text) message with a few extra bytes added by the phone for its own purposes. And the contents suggest that as well, though why they are not more readable lies beyond my knowledge ... I think you're right, it looks like a standardised MMS notification (that would be sent as a text message to tell the phone where to get an image). I found a spec here: http://www.activexperts.com/xmstoolkit/sms/mmsnotification/ That spec says that the URL was correct as I decoded. This message had a relative expiry time that meant it expired 72 hours after being sent, I guess it has expired now. Cheers, Nicholas Sherlock -- 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
Re: gcc Cygwin package maintainer
On 08/08/2010 00:00, Jerry DeLisle wrote: So I have sjlj backwards. I will fix that. Then the following I am not sure about. --disable-__cxa_atexit --enable-static --enable-shared --enable-shared-libgcc Shall I include these? Yes, do. I think they're mostly the default anyway, but you definitely want the cxa_atexit one for ABI compatibility of any DLLs you build with static cdtors. The --enable-shared stuff gets you DLLs built of all your runtimes, the --enable-static gets you static versions. You probably want those DLLs as well as static library archives, since there are various correctness issues to do with using shared libraries in your application that can only be solved by using shared runtimes; it won't affect simple monolithic executables, but anything you link against shared libraries from the rest of the distro could break in various interesting ways. cheers, DaveK -- 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
Batch-style variables to detect change in Cygdrive
Is there anyway I can get batch-style relative drive paths in Cygwin? An example of what I mean is %~d0. The reason for is is that I would like to mount folders from a USB, so the drive (the variable I showed does drive) will change everytime I plug the USB in. After abit of playing around I found how to mount folders, but it needs be ran from inside Cygwin via a file ran on start-up or written manually. I am attempting to set the mounts from a batch script or atleast get a variable/function that will find out what drive to use. Below is some examples I've cooked up. # batch-style set mono1=cygpath --type windows %~d0\mono\ set mono2=cygpath --type mixed %~d0/mono/ set mono3=cygpath --type unix /cygdrive/%~d0/mono/ mount -o binary '%mono1%' /mnt # Cygwin-style mount -o binary $(cygpath --type windows %~d0\mono\) /mnt mount -o binary $(cygpath --type mixed %~d0/mono/) /mnt mount -o binary $(cygpath --type unix /cygdrive/%~d0/mono/) /mnt -- 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
