Re: ITP: googlecl-0.9.7
On 28 June 2010 09:27, Christopher Faylor wrote: If it is not officially in a distribution then it needs to be voted on. It officially will be part of Fedora 13: https://admin.fedoraproject.org/pkgdb/collections/name/F-13?tg_paginate_limit=0_csrf_token=2d176377b6cdff78cd6eccc7fcfbe0a686917e61 +1 Thank you for the vote (and from Reini as well), are there any more takers? Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
[ITA] cyrus-sasl
I would like to adopt cyrus-sasl. It is listed as orphaned and Gareth Pearce recently indicated he was not planning to repackage it.[1] I have added two new packages with LDAP and SQL plugins. cyrus-sasl.hint -- sdesc: The Cyrus SASL API implementation. (Documentation and Utilities) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Utils requires: libsasl2 libsasl2.hint -- sdesc: The Cyrus SASL API implementation. (Runtime library and Daemon) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: crypt libdb4.5 libgcc libopenssl098 external-source: cyrus-sasl libsasl2-devel.hint -- sdesc: The Cyrus SASL API implementation. (Development files) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libdb4.5-devel openssl-devel openldap-devel libpq-devel external-source: cyrus-sasl libsasl2-ldap.hint -- sdesc: The Cyrus SASL API implementation. (LDAP Plugin) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libopenldap2 external-source: cyrus-sasl libsasl2-sql.hint -- sdesc: The Cyrus SASL API implementation. (SQL Plugin) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libpq5 external-source: cyrus-sasl download: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.23-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/libsasl2-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/libsasl2-devel-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/libsasl2-ldap-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/libsasl2-sql-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/setup.hint [1] http://cygwin.com/ml/cygwin-apps/2010-06/msg00166.html -- David Rothenberger daver...@acm.org How many NASA managers does it take to screw in a lightbulb? That's a known problem... don't worry about it.
Re: [ITP] mingw-w64
On 6/29/2010 1:13 PM, JonY wrote: On 6/30/2010 00:10, Charles Wilson wrote: Now, I thought you wanted to use the w64 prefix as a project origin indicator, and assumed that -mingw64- would be the target bitdepth indicator. However, given w64-mingw64-pthreads-devel32 and w32-mingw64-pthreads-headers32 I'm not sure that's the case. It seems NOW that you want to use 'mingw64' as the project origin indicator, and w64/w32 as the target bit depth (and I'm sure the trailing '32' in these two anomalies is unnecessary). So, I think I'd put the project origin first, followed by the bit depth. Yes, I was using w64/w32 as bitness indicator, as with some releases made with the buildbot on sf, mingw64 to differentiate it from mingw.org. Ah. Well, in that case I would think that the origin should come first, rather than the bitdepth. Our existing mingw-runtime package is from (effectively) mingw.org, after all (*). More below. (*) Well, both mingw.org mingwrt and cygwin's mingw-runtime come from a common repository: the winsup/mingw directory on sourceware's CVS server. [note that the mingwrt and w32api parts of mingw.org are hosted by sourceware; all the rest of mingw.org including other source code repos are hosted by sourceFORGE. The reason for the split is historical.] I don't know much about sf's buildbot; I assume that if you can get a cygport to DTRT on your home PC without human intervention except for kicking off the build, then you can convince the buildbot to do it for you? The trailing 32/64 is to indicate which toolchain the pthreads implibs are for, it is too possible to setup a 32bit default multilib setup, the current toolchain is defaulting to 64bit. So w64*devel32 means 64bit implib for 32bit default toolchain that has yet to bet setup. For the current multilib toolchain example, users would want w32*devel64 and w64*devel64 pthreads packages, 32bit and 64bit implib for 64bit default toolchain (the tarballs have the same installation path to the 64bit libdir). Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous installation of both of the first two: (1) mingw64-derived, multilib, default 64bit (2) mingw64-derived, multilib, default 32bit (3) mingw.org-derived, non-multilib, only 32bit In the first two cases, they each must deliver some components in both 32 and 64 bit form, while some components (within a single case 1 or 2) are shared. However, NO components are shared BETWEEN any of the three cases, not even between (1) and (2). (**) (**) except for a possible sharing of target runtime DLLs with the same target bitdepth, but that's a small matter, discussed at the end of this email. Correct so far? Now, SOME of the components that cannot be shared between (1) and (2) will be IDENTICAL in content, EXCEPT that they get installed into different locations. This would include, for instance, the runtime DLLs for, say, 32bit libgcc1 (UNLESS the 'share the target runtimes between (1) and (2)' approach is taken, but assume for the moment that we do not; wait until the end of this email for that discussion). So, we need a naming scheme that accounts for: 1) origin 2) default bit depth of the tool chain 3) bit depth of the target I think I would drop 'w64' since that's abiguous. windows 64? is that tool chain default, so I've got to use -m32 if I want 32bit, or is that the actual bit depth of the contents, like import libraries for linking 64bit target executables? (Aside: I pity the organizational nightmare that you have to deal with over at mingw64.org, because you've got yet another set of 32/64 bifurcations: what is the bit depth of the toolchain EXE's themselves: is ld.exe a 32bit or 64bit executable...at least cygwin is just...cygwin.) In fact, for complete clarity, I think I'd use: -tc64- or -tc32-== toolchain default bitdepth 64 or 32 -m64- or -m32- == bit depth 64 or 32(use m as a mnemonic for which -mNN option it corresponds to) (And, returning to the aside, that 'frees up' the 'w64'/'w32' tag for use in distinguishing the bit depth of native windows ld.exe/gcc.exe: w64-gcc4 contains a binary gcc4.exe that runs as a 64bit native windows application. Not that you guys need or want to use an elaborate package naming scheme like it appears we need here. You don't have setup.exe to worry about.) If something is common to BOTH, then just drop that element. E.g. both the -m32 and -m64 mingw headers are provided by the same package, so that package would have only mingw64-tc64-. OTOH, if you split the mingw import libs for the defaults-to-64bit toolchain between the normal ones (for that toolchain, e.g. 64bit) and the lib32/ ones, then you'd have mingw64-tc64-m64 and mingw64-tc64-m32 And, I'd put all that categorization up front, so that
Re: [ITP] mingw-w64
As an aside, to compile with a different prefix using cygport requires a bit of work right now, because AFAIK cygport doesn't support anything but --prefix=/usr. See http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-autoconf-2.64-1-src.tar.bz2 for how I did it. Basically I had to copy cygport's cygconf() function and modify it, ditto cygports cyginstall() function. Then, from my src_compile() and src_install() I called my copies. That's what was needed to put autoconf into /opt/gcc-tools/epoch2/ but other, more complex packages -- and they don't get much more complex that gcc! -- might need even more custom overrides. P.S. Hey, Yaakov -- any chance cygport could start supporting custom prefixes? Maybe by inheriting some special cygclass? -- Chuck
Re: [ITP] mingw-w64
On 7/1/2010 00:36, Charles Wilson wrote: On 6/29/2010 1:13 PM, JonY wrote: On 6/30/2010 00:10, Charles Wilson wrote: Now, I thought you wanted to use the w64 prefix as a project origin indicator, and assumed that -mingw64- would be the target bitdepth indicator. However, given w64-mingw64-pthreads-devel32 and w32-mingw64-pthreads-headers32 I'm not sure that's the case. It seems NOW that you want to use 'mingw64' as the project origin indicator, and w64/w32 as the target bit depth (and I'm sure the trailing '32' in these two anomalies is unnecessary). So, I think I'd put the project origin first, followed by the bit depth. Yes, I was using w64/w32 as bitness indicator, as with some releases made with the buildbot on sf, mingw64 to differentiate it from mingw.org. Ah. Well, in that case I would think that the origin should come first, rather than the bitdepth. Our existing mingw-runtime package is from (effectively) mingw.org, after all (*). More below. (*) Well, both mingw.org mingwrt and cygwin's mingw-runtime come from a common repository: the winsup/mingw directory on sourceware's CVS server. [note that the mingwrt and w32api parts of mingw.org are hosted by sourceware; all the rest of mingw.org including other source code repos are hosted by sourceFORGE. The reason for the split is historical.] I understand, they do use sourceware's combined configure tree. I don't know much about sf's buildbot; I assume that if you can get a cygport to DTRT on your home PC without human intervention except for kicking off the build, then you can convince the buildbot to do it for you? Right now, human intervention still needed. cygport messes up the target dll locations by moving them around and trying to fix libtool files. Its also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't lead to the cygport halting. The trailing 32/64 is to indicate which toolchain the pthreads implibs are for, it is too possible to setup a 32bit default multilib setup, the current toolchain is defaulting to 64bit. So w64*devel32 means 64bit implib for 32bit default toolchain that has yet to bet setup. For the current multilib toolchain example, users would want w32*devel64 and w64*devel64 pthreads packages, 32bit and 64bit implib for 64bit default toolchain (the tarballs have the same installation path to the 64bit libdir). Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous installation of both of the first two: (1) mingw64-derived, multilib, default 64bit (2) mingw64-derived, multilib, default 32bit (3) mingw.org-derived, non-multilib, only 32bit In the first two cases, they each must deliver some components in both 32 and 64 bit form, while some components (within a single case 1 or 2) are shared. However, NO components are shared BETWEEN any of the three cases, not even between (1) and (2). (**) (**) except for a possible sharing of target runtime DLLs with the same target bitdepth, but that's a small matter, discussed at the end of this email. Correct so far? Correct, I am attempting the first. Now, SOME of the components that cannot be shared between (1) and (2) will be IDENTICAL in content, EXCEPT that they get installed into different locations. This would include, for instance, the runtime DLLs for, say, 32bit libgcc1 (UNLESS the 'share the target runtimes between (1) and (2)' approach is taken, but assume for the moment that we do not; wait until the end of this email for that discussion). So, we need a naming scheme that accounts for: 1) origin 2) default bit depth of the tool chain 3) bit depth of the target I think I would drop 'w64' since that's abiguous. windows 64? is that tool chain default, so I've got to use -m32 if I want 32bit, or is that the actual bit depth of the contents, like import libraries for linking 64bit target executables? (Aside: I pity the organizational nightmare that you have to deal with over at mingw64.org, because you've got yet another set of 32/64 bifurcations: what is the bit depth of the toolchain EXE's themselves: is ld.exe a 32bit or 64bit executable...at least cygwin is just...cygwin.) Well, Windows is special. It has Cygwin, MinGW, Interix, mingw-w64 and etc, all possibly running on the same time, while Linux is just Linux. It takes some nerve to get them to cooperate :) In fact, for complete clarity, I think I'd use: -tc64- or -tc32- == toolchain default bitdepth 64 or 32 -m64- or -m32- == bit depth 64 or 32(use m as a mnemonic for which -mNN option it corresponds to) (And, returning to the aside, that 'frees up' the 'w64'/'w32' tag for use in distinguishing the bit depth of native windows ld.exe/gcc.exe: w64-gcc4 contains a binary gcc4.exe that runs as a 64bit native windows application. Not that you guys need or want to use an elaborate package naming scheme like it appears we need
Re: [ITP] mingw-w64
On 7/1/2010 00:49, Charles Wilson wrote: As an aside, to compile with a different prefix using cygport requires a bit of work right now, because AFAIK cygport doesn't support anything but --prefix=/usr. See http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-autoconf-2.64-1-src.tar.bz2 for how I did it. Basically I had to copy cygport's cygconf() function and modify it, ditto cygports cyginstall() function. Then, from my src_compile() and src_install() I called my copies. That's what was needed to put autoconf into /opt/gcc-tools/epoch2/ but other, more complex packages -- and they don't get much more complex that gcc! -- might need even more custom overrides. Thanks, I will check it out. (btw, libtool too needs to get an epoch version, having problems with macro version mismatches in gcc cygautoreconf). I added --prefix=/somewhere to CYGCONF_ARGS to override cygport defaults by taking advantage of autotool's behavior (...configure...--prefix=/usr...--prefix=/somewhere), but I don't think its appropriate. P.S. Hey, Yaakov -- any chance cygport could start supporting custom prefixes? Maybe by inheriting some special cygclass? Do also give the ability to tell cygport to exclude some libtool files from getting fixed up, thanks.
Re: [ITP] mingw-w64
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson cyg...@cwilson.fastmail.fm wrote: Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous installation of both of the first two: (1) mingw64-derived, multilib, default 64bit (2) mingw64-derived, multilib, default 32bit (3) mingw.org-derived, non-multilib, only 32bit Is there any reason why there wouldn't be non-multilib versions of our stuff? How many permutations do you want to have?
Re: ITP: python-gdata-2.0.10
On Wed, 2010-06-30 at 16:41 +0200, Corinna Vinschen wrote: Yaakov? You were already looking into this and I'm not python aware. WOuld you mind to have another look if that package is ok now? If he's using my .cygport files then *I* am sure they are, but I thought it would be appropriate for someone else to review them instead. Yaakov
Re: [ITP] mingw-w64
On 6/30/2010 2:53 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
Hmm. So, big picture, we have possibly three different mingw-ish compilers,
and you're currently attempting to shepherd the first one, while being
mindful of future issues related to simultaneous installation of both of the
first two:
(1) mingw64-derived, multilib, default 64bit
(2) mingw64-derived, multilib, default 32bit
(3) mingw.org-derived, non-multilib, only 32bit
Is there any reason why there wouldn't be non-multilib versions of our
stuff?
I don't really mind either way. I first raised the question of whether
JonY's package would support -m32 or just -m64. His answer was -m64
only, but then he almost immediately released a revision #2 that was
multilib.
I assumed that would be the only version, but in the NEXT email
exchange, he stated he was saving the /i686-w64-mingw32/ directory
tree for the (multilib?) version that would default to -m32.
Now, maybe his original plan was to propose two separate non-multilib
compilers, and he didn't think through the implications TO that plan
that switching to multilib would cause.
But again, I don't care either way: one multilib with a specific
default: fine.
Two non-multilibs, one for w64 and one for w32: fine.
Two multilibs, basically identical except for the different default (and
the duplicated /{x85_85|i686}-w64-mingw32/ installation trees): also fine.
THAT's up to JonY. He seems to have settled on the third of these
options (especially given how the pthread stuff was packaged), but the
other choices would also be A-OK IMO.
How many permutations do you want to have?
Whatever's necessary to build both 64bit and 32bit binaries using your
stuff. What that actually means in terms of configure options...is
JonY's decision. I'm just trying to help him package what he wants to
provide, in a way that will let setup.exe be happy, and not violate (too
many) cygwin packaging standards.
I'm really not trying to pile extra work on JonY.
--
Chuck
Re: [ITP] mingw-w64
On Wed, Jun 30, 2010 at 3:34 PM, Charles Wilson
cyg...@cwilson.fastmail.fm wrote:
On 6/30/2010 2:53 PM, NightStrike wrote:
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
Hmm. So, big picture, we have possibly three different mingw-ish
compilers,
and you're currently attempting to shepherd the first one, while being
mindful of future issues related to simultaneous installation of both of
the
first two:
(1) mingw64-derived, multilib, default 64bit
(2) mingw64-derived, multilib, default 32bit
(3) mingw.org-derived, non-multilib, only 32bit
Is there any reason why there wouldn't be non-multilib versions of our
stuff?
I don't really mind either way. I first raised the question of whether
JonY's package would support -m32 or just -m64. His answer was -m64 only,
but then he almost immediately released a revision #2 that was multilib.
I assumed that would be the only version, but in the NEXT email exchange,
he stated he was saving the /i686-w64-mingw32/ directory tree for the
(multilib?) version that would default to -m32.
Now, maybe his original plan was to propose two separate non-multilib
compilers, and he didn't think through the implications TO that plan that
switching to multilib would cause.
But again, I don't care either way: one multilib with a specific default:
fine.
Two non-multilibs, one for w64 and one for w32: fine.
Two multilibs, basically identical except for the different default (and the
duplicated /{x85_85|i686}-w64-mingw32/ installation trees): also fine.
THAT's up to JonY. He seems to have settled on the third of these options
(especially given how the pthread stuff was packaged), but the other choices
would also be A-OK IMO.
How many permutations do you want to have?
Whatever's necessary to build both 64bit and 32bit binaries using your
stuff. What that actually means in terms of configure options...is JonY's
decision. I'm just trying to help him package what he wants to provide, in
a way that will let setup.exe be happy, and not violate (too many) cygwin
packaging standards.
I'm really not trying to pile extra work on JonY.
Ok, sounds good.
Re: [ITP] mingw-w64
On 6/30/2010 1:51 PM, JonY wrote:
On 7/1/2010 00:36, Charles Wilson wrote:
I don't know much about sf's buildbot; I assume that if you can get a
cygport to DTRT on your home PC without human intervention except for
kicking off the build, then you can convince the buildbot to do it for
you?
Right now, human intervention still needed. cygport messes up the target
dll locations by moving them around and trying to fix libtool files. Its
also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't
lead to the cygport halting.
I think you can set a variable in your cygport to suppress both of these
actions -- and then use the correct tool manually in src_install().
I'll check later.
So, we need a naming scheme that accounts for:
1) origin
2) default bit depth of the tool chain
3) bit depth of the target
...
In fact, for complete clarity, I think I'd use:
-tc64- or -tc32- == toolchain default bitdepth 64 or 32
-m64- or -m32- == bit depth 64 or 32(use m as a mnemonic
for which -mNN option it corresponds to)
...
If something is common to BOTH, then just drop that element. E.g. both
the -m32 and -m64 mingw headers are provided by the same package, so
that package would have only mingw64-tc64-. OTOH, if you split the
mingw import libs for the defaults-to-64bit toolchain between the
normal ones (for that toolchain, e.g. 64bit) and the lib32/ ones, then
you'd have mingw64-tc64-m64 and mingw64-tc64-m32
Yes, this is a nice plan, clear and concise naming.
Glad you approve. :-)
The pthreads naming is a bit confusing (to myself as well). I should
change it to something easier. Ideas welcome.
Well, if the ideas above make sense, then it should be pretty
straightforward to extend them to libpthread2.
From the packaging point of view, having them buried in toolchain is a
lot easier than trying to move them around at postinstall.
Hmm...maybe. There are two meanings of the term postinstall. There's
after setup.exe unpacks the tarball on the end-users computer, it runs
a postinstall script. And there's in cygport, within src_install() you
can do additional manipulations of the ${D} tree after calling
cyginstall()/'make install'.
Sure, postinstall scripts in the first sense are a little icky. But I've
never had much trouble manipulating things in src_install().
OK, I will use --prefix=/opt/mingw64 and
--with-sysroot=/opt/mingw64/{x86_64,i686}-w64-mingw32 to avoid stuff
clashing with /usr/share.
Target DLLs will go in /opt/mingw64/bin{32,64}. Users will have a
consistent place to look for them.
I really think this makes sense -- but before haring off on my wild
ideas, wait for some other folks to chime in here. Sounds like
NightStrike isn't too happy with my suggestions.
To consolidate the DLLs, only one copy for 32bit and 64bit will be
packaged from one of the compilers and placed in
/opt/mingw64/bin{32,64}. For example, packaging 32bit libgcc DLL from
the 64bit toolchain, but leaving out the one from the 32bit toolchain
since they're similar.
This leads to the next question, how do I add the /opt/mingw64/bin to
the user's $PATH after installation?
THAT's easy. Just put a couple of files in CYGWIN-PATCHES called
mingw64-tc64.csh
mingw64-tc64.sh
and install them during src_install() into
${D}/etc/profile.d/
They should just add /opt/mingw64/bin/ to the $PATH (front, probably).
Remember, on cygwin we're not too fussed about requiring somebody to
either use a shell (so that .dotfiles can set $PATH and stuff) or to be
knowledgable enough to manually set PATH themselves, if they want to
call cygwin apps from windows directly. Unlike mingw.org and mingw64.
I am currently using this approach, this leads to long and complicated
--exclude lines. Does the list file allow \n delimited list of files to
include in the tarball release?
Yes. cygport basically passes that file to tar via -T. Take a close
look at my gettext cygport: I added functions so that I could use
regexes in the .list file.
That was my first attempt, but I concluded its better to have them
shared according to your replies. There will still be 2 sources (each
for 32bit default and 64bit default), but the runtime target dlls won't
get duplicated.
OK.
I tried fixing up libtool upstream to use w64 and w32 prefix instead
of lib prefix like the cygwin cyg prefix, but maintainers weren't
too welcoming of the idea.
Yeah, I can see that. I think ideally you'd want to leave -m32 alone,
but perhaps modify libtool to use a special prefix only for 64bit dlls.
Or maybe we could extend libtool to allow adding a _64 *suffix* prior
to the DLLNUM: libpng_64-12.dll. That'd be a bigger patch, tho.
As a final shortcut, you tweak both cygports to create
non-tc*-differentiated tarballs for the target runtime dlls to begin
with, so in the end, both cygports create
Good: pick one of each pair of these identically named tarballs.
mingw64-m64-libgcc1-VER-REL.tar.bz2 gen by -tc64- cygport
[RFU] flk, fltk_gdi (take2)
LS, I've uploaded a 2nd try, simplified a lot. Thanks to Yaakov for his feedback. If ok this should supersede 1.1.8r5648-1, which should be left as previous. fetching all in one go: wget -r -np -nH -x --cut-dirs=2 -R index*,*.css ,.gif \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk fetching individual files: wget -x -nH --cut-dirs=2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/fltk-1.1.10-1-src.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk1.1/libfltk1.1-1.1.10-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk1.1/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk-devel/libfltk-devel-1.1.10-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk-devel/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk-doc/libfltk-doc-1.1.10-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk-doc/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk/setup.hint wget -x -nH --cut-dirs=2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk_gdi/fltk_gdi-1.1.10-1-src.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk_gdi/libfltk1.1-gdi/libfltk1.1-gdi-1.1.10-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk_gdi/libfltk1.1-gdi/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk_gdi/setup.hint I hope the lines of the wget command won't wrap on sending .. Teun
Re: ITP: python-gdata-2.0.10
On 30 June 2010 15:16, Yaakov (Cygwin/X) wrote:
On Wed, 2010-06-30 at 16:41 +0200, Corinna Vinschen wrote:
Yaakov? You were already looking into this and I'm not python aware.
WOuld you mind to have another look if that package is ok now?
If he's using my .cygport files then *I* am sure they are, but I thought
it would be appropriate for someone else to review them instead.
Here is the cygport file I used:
---
inherit distutils
DESCRIPTION=Python API for Google web services
HOMEPAGE=http://code.google.com/p/gdata-python-client/;
SRC_URI=http://gdata-python-client.googlecode.com/files/gdata-${PV}.tar.gz;
SRC_DIR=gdata-${PV}
---
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
Re: [ITP] mingw-w64
On 6/30/2010 2:06 PM, JonY wrote: Thanks, I will check it out. (btw, libtool too needs to get an epoch version, having problems with macro version mismatches in gcc cygautoreconf). Oh boy. Yeah, I would imagine so. The gcc-tools-* stuff was added to support Dave Korn's needs when building the cygwin compilers, and since HE didn't need libtool, I didn't package it. I think there was some problem with trying to use full-up 'autoreconf' on the gcc tree, so Dave stuck with manually running the individual tools as needed, but I'm not sure about that. Let's see what suggestions Dave has. P.S. Hey, Yaakov -- any chance cygport could start supporting custom prefixes? Maybe by inheriting some special cygclass? Do also give the ability to tell cygport to exclude some libtool files from getting fixed up, thanks. Again, I *think* you can suppress this; I'll check tomorrow. -- Chuck
Re: [RFU] flk, fltk_gdi (take2)
On Wed, 2010-06-30 at 23:15 +0200, A.R. Burgers wrote: I've uploaded a 2nd try, simplified a lot. Thanks to Yaakov for his feedback. If ok this should supersede 1.1.8r5648-1, which should be left as previous. http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk1.1/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/fltk_gdi/libfltk1.1-gdi/setup.hint \ s/libjpeg62/libjpeg7/ With those changes, I uploaded these and made the necessary changes there to handle the packaging changes so upgrades will go smoothly. Users with 'fltk' currently installed will get libfltk1.1-gdi in order to not break their existing (self-built) programs; those with 'fltk-devel' will now get libfltk-devel which will pull in the X11 libfltk1.1. Accordingly, I will remove fltk from Ports so that users get these versions. Thanks for taking care of this. Yaakov
Re: ITP: python-gdata-2.0.10
On Wed, 2010-06-23 at 21:33 -0400, Chris Sutcliffe wrote: Thank you for the quick review and the tip on the cygport. I've uploaded new versions based on the revised cygport: wget -x -nH --cut-dirs=3 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.10-1.tar.bz2 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.10-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/python-gdata/setup.hint Uploaded and added to cygwin-pkg-maint. Yaakov
Re: ITP: googlecl-0.9.7
On 30 June 2010 13:11, Chris Sutcliffe wrote: On 28 June 2010 09:27, Christopher Faylor wrote: If it is not officially in a distribution then it needs to be voted on. It officially will be part of Fedora 13: https://admin.fedoraproject.org/pkgdb/collections/name/F-13?tg_paginate_limit=0_csrf_token=2d176377b6cdff78cd6eccc7fcfbe0a686917e61 +1 Thank you for the vote (and from Reini as well), are there any more takers? +1 Andy
RE: startxwin/XWin won't start properly
Larry Hall (Cygwin X) wrote: On 6/30/2010 1:07 AM, Bradley, Mike wrote: OK, I removed my old cygwin installation (the directory which contains/usr, /bin/, etc.), and re-installed a new version. I kept the cygwin_package directory, but setup.exe did not remember my previous installation. In the past I have had to install cygwin on multiple machines, and it would be nice to learn a way to have a file which describes the packages I want to install, rather than having to recall them all. 'setup.exe' doesn't remember your previous installations - ones you have removed. There'd be little call for that kind of functionality. 'setup.exe' I disagree. I've had to reinstall cygwin from scratch several times, and also have different coworkers who can benefit from cygwin, but saying Go through the long list of groupings, including the even longer sublist of packages, ignoring lib* is not very helpful. Most of my coworkers are not sysadmins or Unix gurus so they look at a lot of packages and say I'll just use puTTY. And it takes a lot of time. But no one wants EVERYTHING, a lot of it is not useful to us. It would be great to be able to have a file I can email them saying Use this, it'll load everything you need.. And of course have a copy for myself for when I get a new machine, or the OS has to be reloaded, or I have cygwin problems (perhaps related to the anti-virus, but still). Such a thing would be great for anyone who wants to test the bleeding edge. If they knew rolling back was simple they'd be encouraged to be daring. does allow you to install from a local directory though. So if you keep the directory that contained all the packages you've downloaded previously, you can point 'setup.exe' at this directory and tell it to install everything. This will help me in some cases, though it won't for my coworkers (none of whom are local to my area). If I renamed the local directory from, say http%3a%2f%2fmirror.mcs.anl.gov%2fcygwin%2f to say http%3a%2f%2fmirror.cs.vt.edu%2fcygwin%2f, will that work? Brian Timares
Re: startxwin/XWin won't start properly
On Tue, Jun 29, 2010 at 11:07:44PM -0600, Bradley, Mike wrote: In the past I have not found a good way to remember which packages where installed (e.g. non-default packages). Is there a file/way to run setup.exe so that a specified set of packages are installed? OK, I removed my old cygwin installation (the directory which contains /usr, /bin/, etc.), and re-installed a new version. I kept the cygwin_package directory, but setup.exe did not remember my previous installation. In the past I have had to install cygwin on multiple machines, and it would be nice to learn a way to have a file which describes the packages I want to install, rather than having to recall them all. So, after being told that Cygwin remembers your previous installation and to just run setup.exe, you removed your previous installation and are surprised that Cygwin doesn't remember it. Here's some more advice for you to misunderstand/ignore: Don't do 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: startxwin/XWin won't start properly
It would be great to be able to have a file I can email them saying Use this, it'll load everything you need.. And of course have a copy for myself for when I get a new machine, or the OS has to be reloaded, or I have cygwin problems Such a thing would be great for anyone who wants to test the bleeding edge. If they knew rolling back was simple they'd be encouraged to be daring. Absolutely! And I suspect a relatively easy modification/addition for setup.exe. It already has the concept of what's loaded, it's just a matter of storing this off into a single file that is read on subsequent runs of setup.exe. Then when the new install is complete the file is written to. In practice setup.exe would ask if you want to use the default configuration file, or load a separate one. The default Would always be written to. After install the user would then copy and store the default configuration file as a separate one for subsequent use. -Mike
Re: startxwin/XWin won't start properly
On Wed, Jun 30, 2010 at 09:02:34AM -0500, Timares, Brian (Harris) wrote: Larry Hall (Cygwin X) wrote: On 6/30/2010 1:07 AM, Bradley, Mike wrote: OK, I removed my old cygwin installation (the directory which contains/usr, /bin/, etc.), and re-installed a new version. I kept the cygwin_package directory, but setup.exe did not remember my previous installation. In the past I have had to install cygwin on multiple machines, and it would be nice to learn a way to have a file which describes the packages I want to install, rather than having to recall them all. 'setup.exe' doesn't remember your previous installations - ones you have removed. There'd be little call for that kind of functionality. 'setup.exe' I disagree. I've had to reinstall cygwin from scratch several times, and also have different coworkers who can benefit from cygwin, but saying Go through the long list of groupings, including the even longer sublist of packages, ignoring lib* is not very helpful. Most of my coworkers are not sysadmins or Unix gurus so they look at a lot of packages and say I'll just use puTTY. And it takes a lot of time. But no one wants EVERYTHING, a lot of it is not useful to us. You misunderstand what Larry is saying. He is referring to wiping out your installation and then expecting Cygwin to magically remember what you used to have. You are talking about having a fixed set of packages to install and apparently expect that you will be able to use software without actually investigating how to use it. If you read the documentation on setup.exe you'll find how to specify the packages you want on the command line. If you make a .bat file available with the right packages then all of the poor non-UNIX-gurus who can't figure out how to pick openssh from a list will be able to just run pleasedoitforme.bat . OTOH, why not use putty if you don't know linux? 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: startxwin/XWin won't start properly
On 6/30/2010 10:15 AM, Christopher Faylor wrote: OTOH, why not use putty if you don't know linux? You haven't been mean enough. ssh is easier to use than putty, regardless of knowledge of linux. -- Tim Prince -- 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: startxwin/XWin won't start properly
So, after being told that Cygwin remembers your previous installation and to just run setup.exe, you removed your previous installation and are surprised that Cygwin doesn't remember it. What I did was re-run setup.exe. XWin would still not startup. Then I Deleted the cygwin install (except for the package directory). Setup.exe Did not recall/remember/read the package directory, it did a default install. The good news is XWin works now. The bad news is I must remember/find/set the Various packages I need in addition to the default. I'm confused as to why the notion of setup.exe to leave a bread-crumb-trail of what was installed for-the-purpose-of driving a subsequent installation is such a controversial issue Here's some more advice for you to misunderstand/ignore: Don't do that. Uh, I think we have a simple misunderstanding... -- 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: startxwin/XWin won't start properly
On Wed, Jun 30, 2010 at 08:36:05AM -0600, Bradley, Mike wrote: cgf wrote: So, after being told that Cygwin remembers your previous installation and to just run setup.exe, you removed your previous installation and are surprised that Cygwin doesn't remember it. What I did was re-run setup.exe. XWin would still not startup. Then I Deleted the cygwin install (except for the package directory). Setup.exe Did not recall/remember/read the package directory, it did a default install. I guess what you're not getting is that the list of installed packages is located within the cygwin installation itself. If you wipe out then setup.exe won't know what's installed. The good news is XWin works now. The bad news is I must remember/find/set the Various packages I need in addition to the default. I'm confused as to why the notion of setup.exe to leave a bread-crumb-trail of what was installed for-the-purpose-of driving a subsequent installation is such a controversial issue It's not controversial since setup.exe already does that. You just chose to wipe out the record of what's installed. If you wanted to just reinstall X you could have just chosen Reinstall and not gone through the pain of wiping out everything. 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: startxwin/XWin won't start properly
cgf, I'll start off by saying I sense an attitude of only gurus need apply and gurus don't need help from you. To me that's very OpenBSD, but not very Cygwin. If I sense incorrectly, I suggest what you are writing leads me to feel that way. If that's correct, I suggest we'll never come to an agreement and we may as well drop the subject. Christopher Faylor wrote: On Wed, Jun 30, 2010 at 09:02:34AM -0500, Timares, Brian (Harris) wrote: Larry Hall (Cygwin X) wrote: On 6/30/2010 1:07 AM, Bradley, Mike wrote: OK, I removed my old cygwin installation (the directory which contains/usr, /bin/, etc.), and re-installed a new version. I kept the cygwin_package directory, but setup.exe did not remember my previous installation. In the past I have had to install cygwin on multiple machines, and it would be nice to learn a way to have a file which describes the packages I want to install, rather than having to recall them all. 'setup.exe' doesn't remember your previous installations - ones you have removed. There'd be little call for that kind of functionality. 'setup.exe' I disagree. I've had to reinstall cygwin from scratch several times, and also have different coworkers who can benefit from cygwin, but saying Go through the long list of groupings, including the even longer sublist of packages, ignoring lib* is not very helpful. Most of my coworkers are not sysadmins or Unix gurus so they look at a lot of packages and say I'll just use puTTY. And it takes a lot of time. But no one wants EVERYTHING, a lot of it is not useful to us. You misunderstand what Larry is saying. Actually no, I don't. Although I will admit as I get older I do miss more and more and it is frustrating! He is referring to wiping out your installation and then expecting Cygwin to magically remember what you used to have. Hmm, I don't recall magic being mentioned. I know I have had to wipe out the installation (new laptop, troubles with PC, troubles with Cygwin where one wants a clean install), or find that my chosen install site has dropped off the list, or found that some other site has more up-to-date updates [that matter to me]. And I've wished everytime, from the first reinstallation to the most recent, that I didn't have to go through the list, picking what I know is useful and leaving out what my I don't want or my constraints don't allow. You are talking about having a fixed set of packages to install and apparently expect that you will be able to use software without actually investigating how to use it. If you read the documentation on setup.exe Yes, then no. How long has it been since you've gone through the full list of packages that Cygwin offers? There are 29 catagories and I am NOT counting what is underneath them. Yes, I feel that my coworkers should be able to use, say, X Windows programs, without understanding unix. Or if they do know unix, they should be able to expect that, say, bc is there w/o having to look for it. However this discussion more properly belongs on a more general Cygwin list. I'll see if it makes sense to post a suggestion there. you'll find how to specify the packages you want on the command line. If you make a .bat file available with the right packages then all of the poor non-UNIX-gurus who can't figure out how to pick openssh from a list will be able to just run pleasedoitforme.bat . How many packages are we talking about here? Wait, you don't know. So I'll just reject your suggestion as inappropriate for my situation, although I think for some people it is a pretty good work-around. What Mike and I want is actually pretty reasonable. We want to be able to preserve the work we do in picking the wheat from the chaff (from our point of view) to avoid having our coworkers or ourselves duplicate that work, whether they understand Unix or not (I'm sorry I brought it up! It is largely irrelevant.). It seems simple--at some point the Setup program knows what was selected. It just needs to save it out and be able to read it back in. Brian Timares -- 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/
Setup retaining or saving package selections (was: startxwin/XWin won't start properly)
Brian Timares (me! self-replying) wrote: However this discussion more properly belongs on a more general Cygwin list. I'll see if it makes sense to post a suggestion there. I found something where cgf says the big reason remembered installs aren't done are because it takes someone with the time and skills to do it (SHTDI). http://www.mail-archive.com/cyg...@cygwin.com/msg62416.html I found this http://marc.info/?l=cygwinm=114858695408427w=2 which kinda does what I want. It is still more trouble than I want, but less than giving someone a list of n packages that I've found useful and expecting them to go through the list. Mike, that might be worth a try, though I don't know if it would still work. On considering the later link I realize that it might not be 100% as simple as just saving out a list, unless installing package X automatically and at that point did dependency resolution. I find discussions of this going back to 2002, but the search for the main mail list timed out on me. Anyway, I have to get back to work so I'll try to post to the main list after work. Brian Timares -- 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: RE: startxwin/XWin won't start properly
What Mike and I want is actually pretty reasonable. We want to be able to preserve the work we do in picking the wheat from the chaff (from our point of view) to avoid having our coworkers or ourselves duplicate that work, whether they understand Unix or not (I'm sorry I brought it up! It is largely irrelevant.). It seems simple--at some point the Setup program knows what was selected. It just needs to save it out and be able to read it back in. vote +1 I've also had this need many times. Most recently, the update to the latest cygwin dll, which the instructions specifically said should be a clean install rather than an in-place upgrade. Migration wizard would have been nice... Ryan -- 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/
XTerm scrollbar issue
All releases of xterm newer that 229 (i.e. since June '08) have a broken scrollbar. It never bothered me enough to post a message, but I've been setting up some new systems and have found it annoying to dig up xterm-229 and manually install it. These images show what the scrollbar used to look like (and what it still looks like in all recent Linux distributions, even with latest xterm builds): http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-229-1.jpg http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-229-2.jpg The 1st one shows the gray scrollbar shrinking as the history buffer gets filled. The 2nd shows the gray scrollbar moving with a middle-button click-n-drag upwards to view history. These images show what the scrollbar looks like, now, in version 260 (and all versions in between 229 and 260): http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-260-1.jpg http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-260-2.jpg The 1st one shows the gray scrollbar as a constant tiny rectangle always at the top, regardless of how many lines of history there are. The 2nd one shows what happens when you do a middle-button click-n-drag. Seemingly a minor nit, especially since we live in an age of wheel mice, but annoying for those of us accustomed to scrolling the old fashioned way. BTW, here's my ~/.Xdefaults, though even without it the behavior is the same: ! Font XTerm*VT100*font: -xos4-terminus-bold-r-normal-*-12-*-*-*-*-*-*-* ! These affect apps like man XTerm*VT100*highlightSelection: true XTerm*VT100*highlightColorMode: true XTerm*VT100*colorBDMode: on XTerm*VT100*colorBD: green XTerm*VT100*colorULMode: on XTerm*VT100*underLine: on XTerm*VT100*colorUL: yellow ! Pretty colors. XTerm*VT100*dynamicColors: on XTerm*VT100*foreground: white XTerm*VT100*background: black XTerm*VT100*cursorColor: white XTerm*VT100*highlightColor: orange ! I need to scroll XTerm*VT100*scrollBar: true XTerm*VT100*saveLines: 2000 XTerm*VT100*scrollTtyOutput:false XTerm*VT100*scrollKey: true XTerm*VT100*JumpScroll: true ! Run login scripts XTerm*VT100*loginShell:true ! Make use of that big monitor XTerm*VT100*geometry: 110x25 ! Allow backspace to work on wrapped lines XTerm*VT100*reverseWrap:true ! I hate beeping XTerm*VT100*visualBell: true ! This resource specifies whether or not to ignore the alternate screen ! of applications such as vi. When it is on, these applications will restore ! the contents of the screen when they are exited to what they were before ! they were started. When it is off, the contents of vi will remain on the ! screen after the program is quit. XTerm*VT100*titeInhibit: true ! New cygwin xterm includes a toolBar by default. Disable it. XTerm*toolBar:false -- 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: startxwin/XWin won't start properly
On 6/30/2010 11:22 AM, Timares, Brian (Harris) wrote: What Mike and I want is actually pretty reasonable. We want to be able to preserve the work we do in picking the wheat from the chaff (from our point of view) to avoid having our coworkers or ourselves duplicate that work, whether they understand Unix or not (I'm sorry I brought it up! It is largely irrelevant.). It seems simple--at some point the Setup program knows what was selected. It just needs to save it out and be able to read it back in. As you mentioned in your follow-up, if what's already supported in 'setup.exe' doesn't meet your needs, you're welcome to modify it. There are several ways to grab a list of installed packages, as has been discussed already (assuming an installation exists at the time you're doing the grabbing). If you want to the dead-simple approach, then you need to use 'setup.exe' to manage and maintain your local installation. If you need to duplicate that installation elsewhere, you use the same installation directory and point 'setup.exe' to it instead of mirrors. Or you set up your own local mirror that you maintain with the packages and versions you want and point 'setup.exe' at that mirror only. Or you grab the output of 'cygcheck -cd' \ (or /etc/setup/installed.db directly) and gently message it to create script with calls 'setup.exe' with the list of packages you'd like from a mirror. Given all the existing options, it's worth your while to take a good look at them all and figure out what they give you and what they don't when matching them against what you need/want. You may find that the solution you want is simply an extension of something that's already there, saving you time and effort all around. If you decide to create a patch, those would go to the cygwin-apps list. Discussion of 'setup.exe' bugs and enhancements go to that list as well. -- 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? -- 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 02/05/2010 21:52, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig ' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Thanks for the clear reproduction steps. And thanks to the other reporters of this problem :-) This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 -- 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: RE: startxwin/XWin won't start properly
On Wed, Jun 30, 2010 at 06:11:49PM +0200, Ryan Johnson wrote: What Mike and I want is actually pretty reasonable. We want to be able to preserve the work we do in picking the wheat from the chaff (from our point of view) to avoid having our coworkers or ourselves duplicate that work, whether they understand Unix or not (I'm sorry I brought it up! It is largely irrelevant.). It seems simple--at some point the Setup program knows what was selected. It just needs to save it out and be able to read it back in. vote +1 I've also had this need many times. Most recently, the update to the latest cygwin dll, which the instructions specifically said should be a clean install rather than an in-place upgrade. Sheesh. The instructions did *not* say that a clean install was needed. We tried hard to make sure that wasn't necessary in fact. -- 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: Problem when trying to use -nolock Option
On 29/06/2010 17:13, Mathias Friesenbichler wrote: Hi, I posted this Problem 2 Weeks ago and no one answered yet. Is there anyone who can help me? Yourself, first of all. Try reading the 'Xserver' man page. Thanks, Mathias Original-Nachricht Datum: Thu, 17 Jun 2010 08:24:03 +0200 Von: Mathias Friesenbichlerhia...@gmx.at An: cygwin-xfree@cygwin.com Betreff: Problem when trying to use -nolock Option Hi, My CygwinX is installed on a server. Several users are accessing this installation and therefore i want to use the -nolock option. No. If several users are running X servers on the same computer at the same time, they need to each use a unique display number. '-nolock' is only useful if /tmp resides on a FAT filesystem, which doesn't support the semantics needed by lockfiles, or if a stale lockfile has been left behind by a crashed XWin which you don't have rights to remove. Although i have added this option, cygwinx creates the X1 File in tmp/.X11-unix. So no other user can access cygwin while it is open. The logbook output is then: 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 XWin was started with the following command line: /usr/bin/Xwin :1 -ac -query 10.8.248.101 -clipboard -logfile C:\DOKUME~1\fltplehr\LOKALE~1\Temp\xwin.fltplehr.1.log -nolock -dpi 75 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1280 h 1024 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [1061722.984] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [1061722.984] _XSERVTransOpen: transport open failed for inet6/pc08309:1 [1061722.984] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [1061723.015] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed [1061723.015] _XSERVTransMakeAllCOTSServerListeners: server already running [1061723.015] Fatal server error: [1061723.015] Cannot establish any listening sockets - Make sure an X server isn't already running I am starting the program with the following code: start O:\PLS_Faser\Cygwin_PLSStarter\cygwin_installed\bin\Xwin.exe :1 -ac -query IP -clipboard -logfile %TEMP%\xwin.%USERNAME%.1.log -nolock -dpi 75 Can you help me? -- 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: Setup retaining or saving package selections (was: startxwin/XWin won't start properly)
On Wed, Jun 30, 2010 at 10:51:57AM -0500, Timares, Brian (Harris) wrote: Brian Timares (me! self-replying) wrote: However this discussion more properly belongs on a more general Cygwin list. I'll see if it makes sense to post a suggestion there. I found something where cgf says the big reason remembered installs aren't done are because it takes someone with the time and skills to do it (SHTDI). http://www.mail-archive.com/cyg...@cygwin.com/msg62416.html That post is five years old and unrelated to the topic at hand. This message is referencing the idea to make a windows library for accessing the cygwin mount table. We actually pretty much have that now in fact. But, that message has nothing to do with this. I found this http://marc.info/?l=cygwinm=114858695408427w=2 which kinda does what I want. It is still more trouble than I want, but less than giving someone a list of n packages that I've found useful and expecting them to go through the list. Mike, that might be worth a try, though I don't know if it would still work. You're talking about giving someone a file. So just give them a .bat file that contains something like: setup.exe -P openssh,xorg-x11-base,xorg-x11-bin,xterm and let them run it. That will pull in all of the listed packages and any needed dependencies. On considering the later link I realize that it might not be 100% as simple as just saving out a list, unless installing package X automatically and at that point did dependency resolution. setup.exe handles dependencies. That's a big part of its job. I find discussions of this going back to 2002, but the search for the main mail list timed out on me. Anyway, I have to get back to work so I'll try to post to the main list after work. You can find the discussion by people who don't know about setup.exe command-line options nearly every month in the cygwin mailing list. But, anyway, as Larry says, if you don't like the solutions that are available to do what you want then offering a patch is how you will make things happen. I think most of the setup.exe developers are satisfied with the way things work now and aren't looking to implement something else. 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: XTerm scrollbar issue
On Wed, 30 Jun 2010, webmaster wrote: All releases of xterm newer that 229 (i.e. since June '08) have a broken scrollbar. It never bothered me enough to post a message, but I've been setting up some new systems and have found it annoying to dig up xterm-229 and manually install it. These images show what the scrollbar used to look like (and what it still looks like in all recent Linux distributions, even with latest xterm builds): Problems like that shown with the scrollbar are usually a compile-time mismatch on floating-point. There's a configure option for xterm to address this (--enable-narrowproto or --disable-narrowproto), since the mismatch is not detectable via automatic checks. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.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 6/30/2010 1:40 PM, Jon TURNEY wrote: On 02/05/2010 21:52, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Thanks for the clear reproduction steps. And thanks to the other reporters of this problem :-) This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? That seems to have fixed it. I've run it for several hours without any problems. Thanks. Ken -- 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: Problem when trying to use -nolock Option
Hi, Thanks for the reply. But you didn’t get my problem. We are several users running X servers over several computers, but starting the X from the same Installation on the network. So the local Computer doesn’t know anything about the other users and therefore we have written a program that manages this problem for us. This program gives each user a unique display number. The problem now is that if I use the “-nolock” option it does the same as if I don’t use it. It also creates those lockfiles. So what can I do to fix this? Thanks, Mathias -Ursprüngliche Nachricht- Von: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] Im Auftrag von Jon TURNEY Gesendet: Mittwoch, 30. Juni 2010 20:03 An: cygwin-xfree@cygwin.com Cc: hia...@gmx.at Betreff: Re: Problem when trying to use -nolock Option On 29/06/2010 17:13, Mathias Friesenbichler wrote: Hi, I posted this Problem 2 Weeks ago and no one answered yet. Is there anyone who can help me? Yourself, first of all. Try reading the 'Xserver' man page. Thanks, Mathias Original-Nachricht Datum: Thu, 17 Jun 2010 08:24:03 +0200 Von: Mathias Friesenbichlerhia...@gmx.at An: cygwin-xfree@cygwin.com Betreff: Problem when trying to use -nolock Option Hi, My CygwinX is installed on a server. Several users are accessing this installation and therefore i want to use the -nolock option. No. If several users are running X servers on the same computer at the same time, they need to each use a unique display number. '-nolock' is only useful if /tmp resides on a FAT filesystem, which doesn't support the semantics needed by lockfiles, or if a stale lockfile has been left behind by a crashed XWin which you don't have rights to remove. Although i have added this option, cygwinx creates the X1 File in tmp/.X11-unix. So no other user can access cygwin while it is open. The logbook output is then: 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 XWin was started with the following command line: /usr/bin/Xwin :1 -ac -query 10.8.248.101 -clipboard -logfile C:\DOKUME~1\fltplehr\LOKALE~1\Temp\xwin.fltplehr.1.log -nolock -dpi 75 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1280 h 1024 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [1061722.984] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [1061722.984] _XSERVTransOpen: transport open failed for inet6/pc08309:1 [1061722.984] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [1061723.015] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed [1061723.015] _XSERVTransMakeAllCOTSServerListeners: server already running [1061723.015] Fatal server error: [1061723.015] Cannot establish any listening sockets - Make sure an X server isn't already running I am starting the program with the following code: start O:\PLS_Faser\Cygwin_PLSStarter\cygwin_installed\bin\Xwin.exe :1 -ac -query IP -clipboard -logfile %TEMP%\xwin.%USERNAME%.1.log -nolock -dpi 75 Can you help me? -- 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/ -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser -- 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: Shared libraries in Cygwin
--- Mer 30/6/10, Refr Bruhl ha scritto: Data: Mercoledì 30 giugno 2010, 00:27 This is another error message. I apparently cannot build .so files with cygwin for apache. Error below This is my configure script running under ksh crth at lkvn108 in /downloads/apache/httpd-2.2.15 # cat conf_apache.ksh #! /usr/bin/ksh ./configure --prefix=/usr/apache --exec-prefix=/usr/apache --enable-headers=shared --enable-rewrite=shared --enable-dav=shared --enable-vhost-alias=shared --enable-ssl --enable-dav-fs=shared --enable-authz_svn=shared --enable-so I hope its something simple I am missing. Simple is easy to fix right? :O) I am afraid you are far away. I suggest you to take the cygwin package source for apache2-2.2.6-1 and start from them as base of your 2.2.15 porting Warning message /usr/share/apr/build-1/libtool --silent --mode=install cp mod_dav_fs.la /usr/apache/modules/ Warning! dlname not found in /usr/apache/modules/mod_dav_fs.la. Assuming installing a .so rather than a libtool archive. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Incomplete downloads reported across several mirrors
--- Mer 30/6/10, Jim Lawson ha scritto: I still have this kind of problem. Does anyone know is it should be so? More info: 1) gcc: C compiler upgrade helper - version 3.4.4.999 2) glib: Gnome C function library (1.2 sources) - version 1.2.10-10 3) libgnomecanvas2: GNOME canvas widget library (sources) - version 2.26.0-1 -- Forwarded message -- From: Sergey Ivanov icegood1980 at gmail dot com Date: 2010/1/30 Subject: Intgrity fails? To: cygwin@cygwin.com For about last month i still have troubles after downloading without installing from ftp.kernel.org: partial view newer empty - there are still 3 packages: 1) gcc: C compiler upgrade helper 2) glib: Gnome C function library (1.2 sources) - why actually sources if only bin checked... 3) libgnomecanvas2: GNOME canvas widget library (sources) -- King regards, Sergey Ivanov Date: Tue, 22 Jun 2010 19:44:47 -0400 Message-ID: aanlktil1oq5k1yfoebwkwlysis_lmzxchst53vwfm...@mail.gmail.com Subject: Incomplete downloads reported across several mirrors From: Gregg Levine gregg dot drwho8 at gmail dot com Hello!I've been trying to update this 1.7.5 release of Cygwin since 11AM EDT, based on the multiple announcements of updated packages. Each time I select a mirror and select those packages I want to update, the process starts. It continues up to some particular point, and then I get the incomplete download box, and the program wants me to try again. During the first phase of this attempted update I was working in an area that has had the rumors of a poorly configured proxy server, although the information of how this server was configured was never told to me. (Customer who has an IT department that sometimes resembles the Anarchists Football League complete with clones of each of their favorite stars.) Eventually after several repeated tries there, I waited until a few minutes ago here, and decided to try again. This time it happened again with the addition of the mirror based at the Open Software repository at the Oregon State University. - Gregg C Levine gregg dot drwho8 at gmail dot com This signature fought the Time Wars, time and again. I suspect these problems may be due to a broken setup.ini file. The setup.ini file on mirrors.kernel.org (as of 6/29/10) seems to indicate that libgnomecanvas2 is a source-only package (it doesn't have an install: stanza), but other packages are dependent on it. setup.exe tries to install it to satisfy the dependencies but download_one() exits without success since the packagesource::sitestype iterator has nothing to iterate. Manually setting it to Skip in the Gnome category allows the process to complete, albeit with a warning message about the dependency. gcc and glib are empty package, from setup.ini install: release/gcc/gcc-3.4.4-999.tar.bz2 46 install: release/GNOME/glib/glib-1.2.10-10.tar.bz2 46 a 46 byte package is an empty bzipped tar file. They are there to allow the pull of other packages, unfortunately setup forget to tick them and reinstall them every time. libgnomecanvas2 is the source package of libgnomecanvas2-devel libgnomecanvas2_0 I see no package requiring it, all dependency are for libgnomecanvas2_0 Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with ssh using RSA authentication on Windows 7
Hey larry.. I could not find anything related to the rsa authentication of ssh connection on the cygwin site you mentioned..I have posted my problem there also.. Can you provide me some other help? Thanx -Sarthak -- View this message in context: http://old.nabble.com/Problem-with-ssh-using-RSA-authentication-on-Windows-7-tp29023002p29031380.html Sent from the Cygwin list mailing list archive at Nabble.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
AW: [bulk] - Re: Interference with Windows keyboard language
Good morning, Von: Corinna Vinschen Gesendet: Dienstag, 29. Juni 2010 17:07 An: cygwin@cygwin.com Betreff: [bulk] - Re: Interference with Windows keyboard language On Jun 29 17:01, DEWI - N. Zacharias wrote: Hi all, I had to setup an cygwin environment for a colleague which uses a laptop with Portuguese Keyboard under a English version of Windows and sometimes he also has to use german. Under windows the language bar makes it easy to switch between the keyboard layouts. I try to find out how to propagate this to Cygwin. http://www.cygwin.com/cygwin-ug-net/setup-locale.html mentioned that it is sufficient to set the LANG environment variable to the appropriate value. To do so I have to figure out the actual settings of the language bar. Has someone an idea how to solve this ? http://cygwin.com/cygwin-ug-net/using-utils.html#locale Does export LANG=`locale -uU`# bash, dash, ksh, zsh or setenv LANG `locale -uU`# tcsh help? Not really because it uses the default setting not the actual. But anyway it is helpful in term of setting up a setlang.sh in the /etc/profile.d Thanks and have a nice day Norbert Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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: Moving Cygwin directory safe?
Christopher Faylor schrieb am 29.06.2010 um 10:44 (-0400): Actually, the point I was trying to make was that you should never have to use regedit to make Cygwin work correctly. There is no reason to add anything if your installation is working correctly. It would have worked correctly if you had left the registry alone but, since you didn't, there was no reason to restore the first directory. I didn't want the cygwin archives to have advice which suggested that regedit was necessary to move the DLL. Got it. Thanks! -- Michael Ludwig -- 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: Interference with Windows keyboard language
On Jun 29 21:29, Andy Koppe wrote: On 29 June 2010 16:01, DEWI - N. Zacharias wrote: I had to setup an cygwin environment for a colleague which uses a laptop with Portuguese Keyboard under a English version of Windows and sometimes he also has to use german. Under windows the language bar makes it easy to switch between the keyboard layouts. I try to find out how to propagate this to Cygwin. http://www.cygwin.com/cygwin-ug-net/setup-locale.html mentioned that it is sufficient to set the LANG environment variable to the appropriate value. To do so I have to figure out the actual settings of the language bar. Has someone an idea how to solve this ? Both in the Cygwin console and in mintty, you switch keyboard layout as in any other Windows application, using the language bar. Please note that the language bar setting is application-specific, i.e. different applications can use different layouts, as you'll see when switching between applications. The LANG and LC_* settings do not have an effect on the keyboard layout. Oops, looks like I misinterpreted the issue. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: LANG=ru_RU.cp1251, but binutils use UTF-8.
On Tue, Jun 29, 2010 at 10:15 PM, Andy Koppe wrote: Same here. No German either. French and Spanish work, but not quite right: it needlessly decomposes accented characters into ASCII characters: $ LANG=es_ES.UTF-8 objdump --help Modo de empleo: objdump opcion(es) fichero(s) Muestra la informaci'on de fichero(s) objeto. That's odd because the accented character is there in the .mo (in CP1252 though) $ hexdump -C /usr/share/locale/es/LC_MESSAGES/binutils.mo | grep -A2 1d330 0001d330 46 0a 00 4d 75 65 73 74 72 61 20 6c 61 20 69 6e |F..Muestra la in| 0001d340 66 6f 72 6d 61 63 69 f3 6e 20 64 65 20 3c 66 69 |formaci.n de fi| 0001d350 63 68 65 72 6f 28 73 29 3e 20 6f 62 6a 65 74 6f |chero(s) objeto| $ LANG=fr_FR objdump --help | head -2 Usage: objdump options fichiers Afficher les informations depuis les fichiers objet. When I looked at the firts line, I thought French isn't working either :) (That should be Utilisation: ...) $ cygcheck -l binutils | grep binutils.mo /usr/share/locale/da/LC_MESSAGES/binutils.mo /usr/share/locale/es/LC_MESSAGES/binutils.mo /usr/share/locale/fi/LC_MESSAGES/binutils.mo /usr/share/locale/fr/LC_MESSAGES/binutils.mo /usr/share/locale/id/LC_MESSAGES/binutils.mo /usr/share/locale/ja/LC_MESSAGES/binutils.mo /usr/share/locale/ro/LC_MESSAGES/binutils.mo /usr/share/locale/ru/LC_MESSAGES/binutils.mo /usr/share/locale/rw/LC_MESSAGES/binutils.mo /usr/share/locale/sk/LC_MESSAGES/binutils.mo /usr/share/locale/sv/LC_MESSAGES/binutils.mo /usr/share/locale/tr/LC_MESSAGES/binutils.mo /usr/share/locale/uk/LC_MESSAGES/binutils.mo /usr/share/locale/vi/LC_MESSAGES/binutils.mo /usr/share/locale/zh_CN/LC_MESSAGES/binutils.mo /usr/share/locale/zh_TW/LC_MESSAGES/binutils.mo /usr/share/locale/de/LC_MESSAGES/binutils.mo is conspicuously absent. The Russian messages in /usr/share/locale/ru/LC_MESSAGES/binutils.mo appear to be encoded in UTF-8; I don't know what iconv is supposed to do when LANG=ru_RU.cp1251 but outputting UTF-8 to a terminal expecting CP1251 doesn't sound like the right thing to do. -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: Shared libraries in Cygwin
On Tue, 2010-06-29 at 14:58 -0700, Refr Bruhl wrote: I am building Apache with subversion. Perhaps this will help: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ Yaakov Cygwin Ports -- 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: default text mode
Hi, Am 28.06.2010 17:03, schrieb Corinna Vinschen: On Jun 28 13:57, Jan Lübbe wrote: Am 28.06.2010 13:35, schrieb Corinna Vinschen: Role? The automatism is to use binary mode unless /etc/fstab says something else. Other than that, why would you do that at all? If you need textmode for something, do it under some mount point of your own. There's no good reason to use textmode for the system directories, unless Cygwin is too fast on your machine. Cygwin is not to fast, but if I run sed on files all Windows EOL are replaced with Unix EOL. That damages my version control. Of course I can run u2d on that files manually, but I don't want to remind that all time. The files itself are mounted in text mode. They are under /cygdrive/d/Projekte/. But sed changes the EOL anyway. Because sed is saved in /usr/bin, which is mounted in binary mode, I thought this is the reason for sed doing so. Nope. Sed is a stream editor. Usually it does not open the output file by itself but just writes to stdout. Whoever opened the stdout stream has opened it in binary mode. Are you sure the file is actually written to the textmode mounted area? Maybe it's written to /tmp and then just moved over. That would explain the behaviour quite naturally. Also one cannot change the way of mounting /, /usr/bin, and /usr/lib in fstab, as you can see: % cat /etc/fstab # For a description of the file format, see the Users Guide # http://cygwin.com/cygwin-ug-net/using.html#mount-table none /cygdrive cygdrive text,posix=0,user 0 0 There is only the possibility to change the way of mounting /cygdrive. Erm... Thanks for further advises. The advice is given in the /etc/fstab file itself: # For a description of the file format, see the Users Guide # http://cygwin.com/cygwin-ug-net/using.html#mount-table Corinna Which part in that description do you mean? I only find: Note that entries for /, /usr/bin, and /usr/lib are never generated. How can I check wether the files are written to /tmp? In one directory I got the error sed: preserving permissions for `./sedBHiGtF': Permission denied which seems to indicate, that the file is not moved to /tmp, right? Any further ideas? Can somebody reproduce this, or the opposite? Cheers, Jan -- 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
Exception handling: cannot correctly catch the exception
Dear CygWin users developers!
Please, give me a hint, how to deal with the following problem
correctly. I have some code, that calls GraphicsMagick function and I
want to catch the exception thrown. Unfortunately, this does not happen,
when I compile the code with CygWin:
C:\test\bugs\cygwin_exception_test cygwin_exception_test.exe
terminate called after throwing an instance of 'Magick::ErrorFileOpen'
what(): Magick: Unable to open file () reported by
/pub/cygports/graphicksmagick/GraphicsMagick-1.3.7-2/src/GraphicsMagick-1.3.7/magick/constitute.c:8268
(ReadImage)
1 [sig] cygwin_exception_test 9488 open_stackdumpfile: Dumping
stack trace to cygwin_exception_test.exe.stackdump
For Debian it works as expected:
r...@debian:~/test/bugs/cygwin_exception_test# ./cygwin_exception_test
Cannot open file ''
Or is it a GCC-specific problem? Any workarounds?
Additional information:
* Cygwin setup v2.697, gcc-g++-3.4.4-999, libGraphicsMagick3-1.3.7-2
* Debian squeeze, gcc-4.4.4-5, libgraphicsmagick++3-1.3.12-1
--
With best regards,
Dmitry
CXX := g++
LD := g++
RM := /bin/rm
CXXFLAGS:= -g3 -O2
CPPFLAGS:= -I/usr/include/GraphicsMagick
LDFLAGS := -L/usr/lib -L/usr/lib/X11
LIBS:= -lGraphicsMagick++
.PHONY: all
.SUFFIXES: .c .cpp
OBJ = cygwin_exception_test.o
all: cygwin_exception_test
cygwin_exception_test: $(OBJ)
$(LD) $(LDFLAGS) -o $@ $(OBJ) $(LIBS)
clean:
$(RM) -f *.o cygwin_exception_test
#include Magick++.h
#include string
#include iostream
using namespace std;
int main(int argc, char **argv) {
string fileName = ;
string type;
Magick::InitializeMagick(*argv);
try {
Magick::Image image;
image.ping(fileName);
type = image.magick();
} catch (...) {
cerr Cannot open file ' fileName ' endl;
exit(1);
}
cerr File type is ' type ' endl;
return 0;
}
--
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
R: Exception handling: cannot correctly catch the exception
--- Mer 30/6/10, Dmitry Katsubo ha scritto: Dear CygWin users developers! Please, give me a hint, how to deal with the following problem correctly. I have some code, that calls GraphicsMagick function and I want to catch the exception thrown. Unfortunately, this does not happen, when I compile the code with CygWin: C:\test\bugs\cygwin_exception_test cygwin_exception_test.exe terminate called after throwing an instance of 'Magick::ErrorFileOpen' what(): Magick: Unable to open file () reported by /pub/cygports/graphicksmagick/GraphicsMagick-1.3.7-2/src/GraphicsMagick-1.3.7/magick/constitute.c:8268 (ReadImage) 1 [sig] cygwin_exception_test 9488 open_stackdumpfile: Dumping stack trace to cygwin_exception_test.exe.stackdump For Debian it works as expected: r...@debian:~/test/bugs/cygwin_exception_test# ./cygwin_exception_test Cannot open file '' Or is it a GCC-specific problem? Any workarounds? Additional information: * Cygwin setup v2.697, gcc-g++-3.4.4-999, libGraphicsMagick3-1.3.7-2 * Debian squeeze, gcc-4.4.4-5, libgraphicsmagick++3-1.3.12-1 GraphicsMagick is built with gcc-4, so you should test gcc-4 and not gcc-3. Gcc-3 dosn't work with C++ exception -- With best regards, Dmitry Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: Exception handling: cannot correctly catch the exception
--- Mer 30/6/10, Marco Atzeri ha scritto: --- Mer 30/6/10, Dmitry Katsubo ha scritto: Dear CygWin users developers! Please, give me a hint, how to deal with the following problem correctly. I have some code, that calls GraphicsMagick function and I want to catch the exception thrown. Unfortunately, this does not happen, when I compile the code with CygWin: C:\test\bugs\cygwin_exception_test cygwin_exception_test.exe terminate called after throwing an instance of 'Magick::ErrorFileOpen' what(): Magick: Unable to open file () reported by /pub/cygports/graphicksmagick/GraphicsMagick-1.3.7-2/src/GraphicsMagick-1.3.7/magick/constitute.c:8268 (ReadImage) 1 [sig] cygwin_exception_test 9488 open_stackdumpfile: Dumping stack trace to cygwin_exception_test.exe.stackdump For Debian it works as expected: r...@debian:~/test/bugs/cygwin_exception_test# ./cygwin_exception_test Cannot open file '' Or is it a GCC-specific problem? Any workarounds? Additional information: * Cygwin setup v2.697, gcc-g++-3.4.4-999, libGraphicsMagick3-1.3.7-2 * Debian squeeze, gcc-4.4.4-5, libgraphicsmagick++3-1.3.12-1 GraphicsMagick is built with gcc-4, so you should test gcc-4 and not gcc-3. Gcc-3 dosn't work with C++ exception using g++-4 and latest libGraphicsMagick3-1.3.12-1 $ ./cygwin_exception_test.exe Cannot open file '' So it is really only a problem of the right compiler -- With best regards, Dmitry Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
I am unable to install Cygwin on a Windows Datacenter 2008 server image running in the Amazon Web Services cloud. The install process fails at the execution of the post install scripts with a bash segmentation fault and core dump. The scripts complete but do not actually do anything. Attempting to run them after the install produces the same result, script exit but no actions executed. Running the commands in the script one at a time from a shell window works, but this is not acceptable, especially for running the ssh host configuration script !! Things tried so far: running the setup script in compatibility modes, running the scripts after the install completes, running the scripts in bash or sh from the command line. Nothing makes any difference, the scripts fail to do the work required. This seems to be the same as a problem reported already this month, with the same Subject line. However I am opening this new thread, as Cygwin is 100% required on this server in our environment in order to enable Oracle Grid Control 11g to accept agent data from this server. This is a production level server running Oracle applications and I need urgent HELP solving this Cygwin install failure. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/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: default text mode
On Jun 30 12:22, Jan Lübbe wrote: Am 28.06.2010 17:03, schrieb Corinna Vinschen: The advice is given in the /etc/fstab file itself: # For a description of the file format, see the Users Guide # http://cygwin.com/cygwin-ug-net/using.html#mount-table Corinna Which part in that description do you mean? I only find: Note that entries for /, /usr/bin, and /usr/lib are never generated. Looks like you didn't really *read* the section I was refering you to. What about this paragraph: A correct root directory is quite essential to the operation of Cygwin. [...] or this: /usr/bin and /usr/lib are by default also automatic mount points [...] or this: Note that you don't have to specify an fstab entry for the root dir [...] How can I check wether the files are written to /tmp? In one directory I got the error sed: preserving permissions for `./sedBHiGtF': Permission denied which seems to indicate, that the file is not moved to /tmp, right? Right. Looks like you're using sed to do in-place editing... [...time passes...] Hmm. [...more time passes...] This looks like some kind of Cygwin-specific problem. To create the temporary file, sed calls the mkstemp function. In Cygwin, this function *always* opens the temporary file in binary mode, even if it's on a textmode mount. This has been done so since 2006. The reason is that otherwise applications, which write binary files (a compiler for instance) would create broken results on textmode mounts. Since the mkstemp function has no flags parameter, this is an unsolvable problem. Changing that back to use the mount mode would potentially break lots of applications. While, on the other hand, writing LF output instead of CRLF does not spoil the content of textfiles. There's always a way to convert this to CRLF again, u2d. Or, don't use in-place editing. In the long run I guess I'll add a mkstemp function to sed which opens the file in the mode of the underlying mount point. I added that to my already much too long todo list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
XTerm scrollbar issue
All releases of xterm newer that 229 (i.e. since June '08) have a broken scrollbar. It never bothered me enough to post a message, but I've been setting up some new systems and have found it annoying to dig up xterm-229 and manually install it. These images show what the scrollbar used to look like (and what it still looks like in all recent Linux distributions, even with latest xterm builds): http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-229-1.jpg http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-229-2.jpg The 1st one shows the gray scrollbar shrinking as the history buffer gets filled. The 2nd shows the gray scrollbar moving with a middle-button click-n-drag upwards to view history. These images show what the scrollbar looks like, now, in version 260 (and all versions in between 229 and 260): http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-260-1.jpg http://www.donsbox.com/~dfelicia/cygwin-xterm/xterm-260-2.jpg The 1st one shows the gray scrollbar as a constant tiny rectangle always at the top, regardless of how many lines of history there are. The 2nd one shows what happens when you do a middle-button click-n-drag. Seemingly a minor nit, especially since we live in an age of wheel mice, but annoying for those of us accustomed to scrolling the old fashioned way. BTW, here's my ~/.Xdefaults, though even without it the behavior is the same: ! Font XTerm*VT100*font: -xos4-terminus-bold-r-normal-*-12-*-*-*-*-*-*-* ! These affect apps like man XTerm*VT100*highlightSelection: true XTerm*VT100*highlightColorMode: true XTerm*VT100*colorBDMode: on XTerm*VT100*colorBD: green XTerm*VT100*colorULMode: on XTerm*VT100*underLine: on XTerm*VT100*colorUL: yellow ! Pretty colors. XTerm*VT100*dynamicColors: on XTerm*VT100*foreground: white XTerm*VT100*background: black XTerm*VT100*cursorColor: white XTerm*VT100*highlightColor: orange ! I need to scroll XTerm*VT100*scrollBar: true XTerm*VT100*saveLines: 2000 XTerm*VT100*scrollTtyOutput:false XTerm*VT100*scrollKey: true XTerm*VT100*JumpScroll: true ! Run login scripts XTerm*VT100*loginShell:true ! Make use of that big monitor XTerm*VT100*geometry: 110x25 ! Allow backspace to work on wrapped lines XTerm*VT100*reverseWrap:true ! I hate beeping XTerm*VT100*visualBell: true ! This resource specifies whether or not to ignore the alternate screen ! of applications such as vi. When it is on, these applications will restore ! the contents of the screen when they are exited to what they were before ! they were started. When it is off, the contents of vi will remain on the ! screen after the program is quit. XTerm*VT100*titeInhibit: true ! New cygwin xterm includes a toolBar by default. Disable it. XTerm*toolBar:false -- 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: R: Exception handling: cannot correctly catch the exception
On 30.06.2010 13:51, Marco Atzeri wrote: GraphicsMagick is built with gcc-4, so you should test gcc-4 and not gcc-3. Gcc-3 dosn't work with C++ exception Thank you very much. Worked perfectly for me. -- With best regards, Dmitry -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
I promise this is not me posting under another name! Well, it's good to hear someone else is having this exact problem too at least. Michael, I haven't found any solution to this yet. Ernest __ UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT information is ENCOURAGED. cygwin-ow...@cygwin.com wrote on 06/30/2010 08:38:46 AM: I am unable to install Cygwin on a Windows Datacenter 2008 server image running in the Amazon Web Services cloud. The install process fails at the execution of the post install scripts with a bash segmentation fault and core dump. The scripts complete but do not actually do anything. Attempting to run them after the install produces the same result, script exit but no actions executed. Running the commands in the script one at a time from a shell window works, but this is not acceptable, especially for running the ssh host configuration script !! Things tried so far: running the setup script in compatibility modes, running the scripts after the install completes, running the scripts in bash or sh from the command line. Nothing makes any difference, the scripts fail to do the work required. This seems to be the same as a problem reported already this month, with the same Subject line. However I am opening this new thread, as Cygwin is 100% required on this server in our environment in order to enable Oracle Grid Control 11g to accept agent data from this server. This is a production level server running Oracle applications and I need urgent HELP solving this Cygwin install failure. -- 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
Cygwin file permission issues
I've run into a Cygwin permissions issue that I haven't been able to resolve by looking through past discussions. When a file file or folder is created by a user under cygwin, it isn't adhering to the permissions inherited by parent folders. Based on the parent folder, any folders and files created should have full access by all users, but they aren't writable. When I go to the Security tab under Windows I get: The permissions on [file/folder name] are incorrectly ordered, which may cause some entries to be ineffective. Press OK to continue and sort the permissions correctly, or Cancel to reset the permissions. Based on the description of this error message, the result of selecting OK or Cancel seem to indicate something is going to change (sorting, or reseting), so I'm not sure what the actual permissions are from the Windows point of view. When I select OK, I see a bunch of entries that shouldn't be there based on the permissions of the parent folder. When I select Cancel, it shows that 'Everyone' has full control. I've messed around with setting CYGWIN to ntsec an nontsec to see if that affects anything, but neither of these settings seem to affect the way the permissions are assigned for new files. How do I fix this? -- 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 ssh using RSA authentication on Windows 7
On 6/30/2010 2:48 AM, sarthakjain wrote: Hey larry.. I could not find anything related to the rsa authentication of ssh connection on the cygwin site you mentioned..I have posted my problem there also.. That's where I replied to it and I'm continuing to do so. ;-) Can you provide me some other help? I'd recommend that you cover the bases I already mentioned. The devil is in the details as I expect you know. -- 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: XTerm scrollbar issue
On 6/30/2010 11:11 AM, webmaster wrote: All releases of xterm newer that 229 (i.e. since June '08) have a broken scrollbar. Since this is an X issue, you want to report this to the cygwin-xfree list. -- 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: Shared libraries in Cygwin
I guess the question is why can't libtool be fixed? If there are undefined symbols for cygwin I am sure there are undefined symbols for other platforms. - Original Message From: Yaakov (Cygwin/X) yselkow...@users.sourceforge.net To: cygwin cygwin@cygwin.com Sent: Wed, June 30, 2010 3:56:58 AM Subject: Re: Shared libraries in Cygwin On Tue, 2010-06-29 at 14:58 -0700, Refr Bruhl wrote: I am building Apache with subversion. Perhaps this will help: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ Yaakov Cygwin Ports -- 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 -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On 6/30/2010 9:38 AM, Michael Higgins wrote: I am unable to install Cygwin on a Windows Datacenter 2008 server image running in the Amazon Web Services cloud. The install process fails at the execution of the post install scripts with a bash segmentation fault and core dump. The scripts complete but do not actually do anything. Attempting to run them after the install produces the same result, script exit but no actions executed. Since there's not allot of specific data here, I can only hazard a guess. When you mention that the postinstall scripts aren't running, that suggests to me one of two things: 1. http://cygwin.com/acronyms/#BLODA 2. DLL rebasing. Did you try installing the rebase package, reading its readme, and running rebaseall as it directs? -- 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: Mail program
Greetings
Cyrille: You asked which error I was getting on compiling the mailutils. I'e
included it below. Interestingly enough when I compile mailutils with a
--disable-cxx option I get the shared library error message/warning again.
Here is the url for the mailutils package.
http://www.gnu.org/software/mailutils/#downloading
I really need the ability to redirect a text stream to a pipe to mail.
I feel if I can get mailutils to compile successfully then I have reached my
goal of emulating an aix environment
- Forwarded Message
From: Refr Bruhl refr_br...@yahoo.com
To:
bug-mailut...@gnu.org
Sent: Tue, June 29, 2010 9:44:15 AM
Subject: Fatal error in addr.cc under cygwin 1.7.5
Team
I am getting compile errors for the
mailutils package under cygwin. I am using cygwin 1.7.5
I have
found a reoccurring error in the config.log. While its reoccurring I
don't think its related to the compile errors. I I have included it
below
The fatal error is in the addr.cc file as shown below
When I
compile usig the --disable-cxx option the compile works but I don't get
mail when involjkng the mail binary.
is there a spool directory
that needs created? Some other setup needed?
Any help is
appreciated
Thanks!
-Rob
## -
##
## Platform. ##
## - ##
hostname = lkvn108
uname -m = i686
uname -r = 1.7.5(0.225/5/3)
uname -s = CYGWIN_NT-5.1
uname -v = 2010-04-12 19:07
/usr/bin/uname -p = unknown
/bin/uname
-X = unknown
/bin/arch = i686
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
config.log
error msage
conftest.c:10:28: error: ac_nonexistent.h: No such file
or directory
configure:4916: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME GNU Mailutils
|
#define PACKAGE_TARNAME mailutils
| #define PACKAGE_VERSION 2.1
| #define PACKAGE_STRING GNU Mailutils 2.1
| #define
PACKAGE_BUGREPORT bug-mailut...@gnu.org
|
#define PACKAGE mailutils
| #define VERSION 2.1
| /* end
confdefs.h. */
| #include ac_nonexistent.h
Actual compile errors
*** Warning: This system can not link to static
lib archive ../mailbox/libmailutils.la.
*** I have the capability to
make that library automatically link in when
*** you link to this
library. But I can only do this if you have a
*** shared version of
the library, which you do not appear to have.
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared
libraries
This is the fatal error:
Making all in cpp
make[3]: Entering
directory `/downloads/mail/mailutils-2.1/examples/cpp'
g++ -g -O2
-DSYSCONFDIR=\/usr/local/etc\ addr.cc -o addr
addr.cc:23:37:
error: mailutils/cpp/mailutils.h: No such file or directory
addr.cc:26: error: ‘mailutils’ is not a namespace-name
addr.cc:26: error:
expected namespace-name before ‘;’ token
addr.cc: In function ‘int
parse(const char*)’:
addr.cc:31: error: ‘set_user_email_domain’ was
not declared in this scope
addr.cc:34: error: ‘Address’ was not
declared in this scope
addr.cc:34: error: expected `;' before
‘address’
addr.cc:35: error: ‘address’ was not declared in this scope
addr.cc:57: error: expected type-specifier before ‘Exception’
addr.cc:57: error: expected `)' before ‘’ token
addr.cc:57: error: expected `{'
before ‘’ token
addr.cc:57: error: ‘e’ was not declared in this
scope
addr.cc:57: error: expected `;' before ‘)’ token
make[3]:
*** [addr] Error 1
make[3]: Leaving directory
`/downloads/mail/mailutils-2.1/examples/cpp'
make[2]: ***
[all-recursive] Error 1
make[2]: Leaving directory
`/downloads/mail/mailutils-2.1/examples'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/downloads/mail/mailutils-2.1'
make: *** [all] Error 2
- Original Message
From: Cyrille Lefevre cyrille.lefevre-li...@laposte.net
To: cygwin@cygwin.com
Sent: Tue, June 29, 2010 9:49:32 PM
Subject: Re: Mail program
Le 29/06/2010 14:24, Refr Bruhl a écrit :
Good Morning
I am in need of of a mail program similar to the mail found in AIX. I am
emulating an AIX environment.
I've installed the email, ssmtp and other email apps in the email. I get a
segmentation fault for email
I like email as it seems to accept the same parameters and funcitonality as
the AIX mail app. I have a multitude of scripts that use the format:
echo ${MESSAGE} | mail -s '${SUBJECT}' ${EMAIL}
Where ${EMAIL} is a comma delimited list of addresses.
I've compiled the mailutils from gnu but I get a different error there which
I'll take up with the buildlist-mailut...@gnu.org
which error ?
Anyone got any ideas on how to get email to work without a segmentation fault?
ah! this one ? do you know the origin ?
Where can I obtain the source for email? I've pretty much hit cygwin head
first and am not as familiar with it as I am with AIX. My apologies
Re: Cygwin file permission issues
Are you setting permissions in cygwin with a 2775 on directories? Its my understanding the cygwin dll overwrites the windows permissions mode in favor of its own. So then you have to use set gid or set uid on the directory Hope this helps -R - Original Message From: Derek Greer dbgr...@gmail.com To: cygwin cygwin@cygwin.com Sent: Wed, June 30, 2010 11:27:34 AM Subject: Cygwin file permission issues I've run into a Cygwin permissions issue that I haven't been able to resolve by looking through past discussions. When a file file or folder is created by a user under cygwin, it isn't adhering to the permissions inherited by parent folders. Based on the parent folder, any folders and files created should have full access by all users, but they aren't writable. When I go to the Security tab under Windows I get: The permissions on [file/folder name] are incorrectly ordered, which may cause some entries to be ineffective. Press OK to continue and sort the permissions correctly, or Cancel to reset the permissions. Based on the description of this error message, the result of selecting OK or Cancel seem to indicate something is going to change (sorting, or reseting), so I'm not sure what the actual permissions are from the Windows point of view. When I select OK, I see a bunch of entries that shouldn't be there based on the permissions of the parent folder. When I select Cancel, it shows that 'Everyone' has full control. I've messed around with setting CYGWIN to ntsec an nontsec to see if that affects anything, but neither of these settings seem to affect the way the permissions are assigned for new files. How do I fix this? -- 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 -- 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: Cygwin file permission issues
On 6/30/2010 11:27 AM, Derek Greer wrote: I've run into a Cygwin permissions issue that I haven't been able to resolve by looking through past discussions. When a file file or folder is created by a user under cygwin, it isn't adhering to the permissions inherited by parent folders. Based on the parent folder, any folders and files created should have full access by all users, but they aren't writable. When I go to the Security tab under Windows I get: The permissions on [file/folder name] are incorrectly ordered, which may cause some entries to be ineffective. Press OK to continue and sort the permissions correctly, or Cancel to reset the permissions. Read the following sections of the User's guide: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files http://cygwin.com/cygwin-ug-net/using.html#using-pathnames The short and sweet is that this is the intended behavior of Cygwin, but you can work around it by ensuring that the noacl option is set on the mountpoint under which the target file resides. You may need/want to create a new mountpoint just for the files of interest. -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: Cygwin file permission issues
Are you setting permissions in cygwin with a 2775 on directories? Its my understanding the cygwin dll overwrites the windows permissions mode in favor of its own. So then you have to use set gid or set uid on the directory Hope this helps -R I haven't tried this, but wouldn't this just affect the owner of the file? If so, this isn't really what I'm after. What I'm looking for is a way to ensure that all files and folders created have full access for 'Domain Users'. -- 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: Shared libraries in Cygwin
On 6/30/2010 1:00 PM, Refr Bruhl wrote: I guess the question is why can't libtool be fixed? If there are undefined symbols for cygwin I am sure there are undefined symbols for other platforms. You don't understand the difference between DLLs on Windows and shared objects on Unix/Linix (and related) platforms. The behavior of these shared libraries is defined and managed by the loader of the O/S they run on. For Windows, that means that there are no unresolved symbols at link time. This is managed by linking with libraries full of thunks to other DLLs which will be loaded at runtime. libtool understands all this. There's nothing broken there. If this doesn't make sense to you, I would recommend that you take a look at the details of how DLLs work on Windows and then, if needed, also research what libtool does on Windows. That should give you a better understanding of things in general and hopefully specifically for the issues you noted when you were trying to build apache2. -- 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
[ANNOUNCEMENT] Updated: bash-completion-1.2-1
A new release of bash-completion, 1.2-1, is now available for download, leaving 1.1-2 as previous. NEWS: = This is a new upstream release. Changes since the prior release are attached. For more details, including how to enable bash-completion for your interactive shells after installing this package, see /usr/share/doc/bash-completion/. DESCRIPTION: bash-completion provides programmable completion enhancements to bash TAB-completion. Based on the command you type, hitting TAB later on in the command line will perform completions on strings that make sense for the context of the command, rather than blindly completing on filenames. NOTE: = You MUST edit your bash startup files to load bash-completion into memory: make sure ~/.bashrc sources /etc/bash_completion, and ~/.bash_profile sources ~/.bashrc. See /etc/defaults/etc/skel/.bashrc (after installing base-files-3.7-1) for an example. Bash completions is not enabled by default because it adds some noticeable startup delay to every interactive shell (about 1.5 seconds on my 2.5 GHz WinXP). Depending on the reaction on the cygwin mailing list, a future release may make bash_completion turned on by default for every bash user, with no edits to ~/.bashrc required. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'bash-completion' from the 'Shells' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin bash-completion maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. bash-completion (1.2) [ David Paleino ] * Don't use pidof in _known_hosts_real() to detect whether Avahi is available, since it's not available on MacOS X. Thanks to Rainer Müller rai...@codingfarm.de (bash-completion MacPorts maintainer) * Fixed freq and rate completion for iwconfig * contrib/munin-node fixed (Debian: #550943) * contrib/dpkg fixed -W and --show completing on .?(u)deb's (Debian: #552109) * contrib/aptitude: add @(add|remove)-user-tag * Added munindoc completion to contrib/munin-node, thanks to Tom Feiner (Debian: #553371) * Added colordiff completion, same as diff * contrib/cpio: added missing completions for -?, --help, --license, --usage, --version and (-p) --to-stdout (Debian: #557436) * Style policy: don't use fancy globbing in case labels * Added .fdf completion to okular and evince * Added .okular completion to okular (Debian: #545530) * Added lintian completion * Refreshed reportbug completion, added --from-buildd (Debian: #579471) * Special-case apt-get source (Debian: #572000) * Added lintian completion (Debian: #547361) * contrib/dpkg: update completion to current API * Styleguide: establish line wrapping and $() instead of `` [ Ville Skyttä ] * Create bz2 dist tarball too. * Include CHANGES in dist tarball. * Include profile snippet in tarball, install it. * Rename contrib/bluez-utils to contrib/bluez to follow bluez 4.x naming. * Apply cardctl completion to pccardctl too. * Apply pine completion to alpine too. * Remove many unnecessary short option completions where long ones exist. * Improve chsh, chgrp, chown, configure, curl, cvs, find, gkrellm, gzip, iconv, lftp, look, lzma, make, man, mdadm, modprobe, mount, mplayer, mysqladmin, perldoc, rsync, screen, service, scp, ssh, sshfs, unzip, update-alternatives, vncviewer, wget, yp-tools, xine based players' and general hostname completions. * Add abook and wtf completion, based on work by Raphaël Droz. * Add cvsps, dragon, fusermount, jarsigner, k3b, lftpget, modplug123, pm-utils, rtcwake, pack200, unpack200, pbzip2, pbunzip2, pbzcat, pigz, unpigz, and wol completions. * Don't overwrite other host completions when completing from multiple SSH known hosts files. * Speed up installed rpm package completion on SUSE, based on work by Marco Poletti (Alioth: #312021). * Improve sourcing snippets from completion dirs. * Drop support for bash 3. The compatiblity global variables
Re: Shared libraries in Cygwin
It makes sense it just seems compiling is halted or linking is not working correctly Its not just apache I am seeing these issue in. - Original Message From: Larry Hall (Cygwin) reply-to-list-only...@cygwin.com To: cygwin@cygwin.com Sent: Wed, June 30, 2010 12:47:49 PM Subject: Re: Shared libraries in Cygwin On 6/30/2010 1:00 PM, Refr Bruhl wrote: I guess the question is why can't libtool be fixed? If there are undefined symbols for cygwin I am sure there are undefined symbols for other platforms. You don't understand the difference between DLLs on Windows and shared objects on Unix/Linix (and related) platforms. The behavior of these shared libraries is defined and managed by the loader of the O/S they run on. For Windows, that means that there are no unresolved symbols at link time. This is managed by linking with libraries full of thunks to other DLLs which will be loaded at runtime. libtool understands all this. There's nothing broken there. If this doesn't make sense to you, I would recommend that you take a look at the details of how DLLs work on Windows and then, if needed, also research what libtool does on Windows. That should give you a better understanding of things in general and hopefully specifically for the issues you noted when you were trying to build apache2. -- 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 -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
Larry Hall \(Cygwin\) wrote: On 6/30/2010 9:38 AM, Michael Higgins wrote: I am unable to install Cygwin on a Windows Datacenter 2008 server image running in the Amazon Web Services cloud. The install process fails at the execution of the post install scripts with a bash segmentation fault and core dump. The scripts complete but do not actually do anything. Attempting to run them after the install produces the same result, script exit but no actions executed. Since there's not allot of specific data here, I can only hazard a guess. When you mention that the postinstall scripts aren't running, that suggests to me one of two things: 1. http://cygwin.com/acronyms/#BLODA 2. DLL rebasing. Did you try installing the rebase package, reading its readme, and running rebaseall as it directs? His problem is the same as mine, various commands like '[' segfault bash (which naturally hoses the startup scripts during install). No BLODA, these are running nothing but Windows (Datacenter 2008 64-bit, with the Amazon EC2Config installed but that's it), and have turned DEP off (and setting compatibility mode on setup.exe). It works in 32-bit 2008 AMIs fine. I just tried running rebaseall (in c:\cygwin\bin, ash, PATH=. rebaseall -v) and it rebases stuff, but afterwards scripts still segfault. The segfault stack dump is as follows: Exception: STATUS_ACCESS_VIOLATION at eip=76EF930A eax= ebx=FFE6 ecx= edx= esi= edi=0027C6E8 ebp=61226084 esp=0027C69C program=C:\cygwin\bin\bash.exe, pid 2224, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args End of stack trace Thanks, Ernest -- 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: Mail program
Le 30/06/2010 19:07, Refr Bruhl a écrit : I really need the ability to redirect a text stream to a pipe to mail. did you take a look to the attached script ? I call it mailx, but mail will do it also :-) even w/ mailutils, you'il probably need a sendmail which is provided by ssmtp or msmtp... Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On 6/30/2010 2:27 PM, Ernest Mueller wrote: snip His problem is the same as mine, various commands like '[' segfault bash (which naturally hoses the startup scripts during install). No BLODA, these are running nothing but Windows (Datacenter 2008 64-bit, with the Amazon EC2Config installed but that's it), and have turned DEP off (and setting compatibility mode on setup.exe). It works in 32-bit 2008 AMIs fine. I just tried running rebaseall (in c:\cygwin\bin, ash, PATH=. rebaseall -v) and it rebases stuff, but afterwards scripts still segfault. The segfault stack dump is as follows: Exception: STATUS_ACCESS_VIOLATION at eip=76EF930A eax= ebx=FFE6 ecx= edx= esi= edi=0027C6E8 ebp=61226084 esp=0027C69C program=C:\cygwin\bin\bash.exe, pid 2224, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args End of stack trace No stack trace. Hm. Well, you could try installing a snapshot with source and debug info and see if you can get gdb to show you something more useful/ interesting, at least in terms of a backtrace, if nothing else. http://cygwin.com/snapshots/ -- 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: Cygwin file permission issues
Thanks Jeremy, this seems to have resolved the issue. For those who might stumble upon this in the future, here's exactly what I ended up doing: 1. Edit the /etc/fstab file 2. Added the following line (note: our install of Cygwin is on the X drive): X:/cygwin / ntfs override,binary,noacl 0 0 3. Closed and reopened the bash shell. 4. Changed to the folder in question and issued a 'touch' command to create a test file. 5. Opened the properties on the newly created file through Windows Explorer and verified that the permissions were correctly being inherited from the parent folder. Derek On Wed, Jun 30, 2010 at 12:24 PM, Jeremy Bopp jer...@bopp.net wrote: On 6/30/2010 11:27 AM, Derek Greer wrote: I've run into a Cygwin permissions issue that I haven't been able to resolve by looking through past discussions. When a file file or folder is created by a user under cygwin, it isn't adhering to the permissions inherited by parent folders. Based on the parent folder, any folders and files created should have full access by all users, but they aren't writable. When I go to the Security tab under Windows I get: The permissions on [file/folder name] are incorrectly ordered, which may cause some entries to be ineffective. Press OK to continue and sort the permissions correctly, or Cancel to reset the permissions. Read the following sections of the User's guide: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files http://cygwin.com/cygwin-ug-net/using.html#using-pathnames The short and sweet is that this is the intended behavior of Cygwin, but you can work around it by ensuring that the noacl option is set on the mountpoint under which the target file resides. You may need/want to create a new mountpoint just for the files of interest. -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 -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
Larry Hall \(Cygwin\) wrote: No stack trace. Hm. Well, you could try installing a snapshot with source and debug info and see if you can get gdb to show you something more useful/ interesting, at least in terms of a backtrace, if nothing else. Unfortunately, I'm not a programmer and wouldn't know where to start to do that. Michael, are you? If anyone else wants to try, I can provide RDP access to one of these 2008 64-bit systems (since it's Amazon, I can just start one for this purpose and terminate it afterwards so that's pretty safe). Thanks, Ernest -- 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
Windows GUI programs (e.g. notepad) start but are invisible after ssh login
This is what I do: 1) Start sshd cygrunsrv -S sshd 2) Login over ssh ssh k...@localhost 3) Start a Windows application (notepad, calc, whatever). The application starts (it is listed in the Process Explorer), however its windows are invisible. How do I change this behavior and display the application? I (obviously) do not want to export the window to another $DISPLAY in the X11 fashion. I just want the app to be visible on the machine where sshd is running. Any help greatly appreciated, Koszalek -- Mariola juz gra ... a Ty co robisz ? Sprawdz http://linkint.pl/f277a -- 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: Windows GUI programs (e.g. notepad) start but are invisible after ssh login
On 6/30/2010 4:53 PM, Koszalek Opalek wrote: This is what I do: 1) Start sshd cygrunsrv -S sshd 2) Login over ssh ssh k...@localhost 3) Start a Windows application (notepad, calc, whatever). The application starts (it is listed in the Process Explorer), however its windows are invisible. How do I change this behavior and display the application? I (obviously) do not want to export the window to another $DISPLAY in the X11 fashion. I just want the app to be visible on the machine where sshd is running. The short answer? You can't or at least you shouldn't. The longer answer is MS doesn't want to allow this functionality and has disabled the ability to access a desktop from a service as of Vista. If you're running XP, you may find that you can get this to work by using the '-i' flag on 'cygrunsrv' when you install the 'sshd' service. Or you can call up the adminstrator tools, find the sshd service, and enable desktop interaction there. This should work, though there have been some reports of difficulty on this list even for XP. It's not clear why but given the fact that MS is removing support for this anyway, the best way to get a reliable way to do this is to lobby MS for some support. ;-) -- 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: Re: Windows GUI programs (e.g. notepad) start but are invisible after ssh login
From: Larry Hall (Cygwin) Subject: Re: Windows GUI programs (e.g. notepad) start but are invisible after ssh login (...) The short answer? You can't or at least you shouldn't. The longer answer is MS doesn't want to allow this functionality and has disabled the ability to access a desktop from a service as of Vista. Bad news... I have devised a fairly complex environment that allows running regression tests remotely on *nix hosts. I was hoping I will be able to embrace Windows by just running Cygwin sshd. (...) when you install the 'sshd' service. Or you can call up the adminstrator tools, find the sshd service, and enable desktop interaction there. This should work, though there have been some reports of difficulty on this list even for XP. I have just checked it on NT (by using Administrative Tools). The notepad window now pops up but it is not redrawn correctly. I can only see a very thin frame, no menu, no title bar no nothing... I will investigate Vista tomorrow. anyway, the best way to get a reliable way to do this is to lobby MS for some support. ;-) I'm afraid my lobbing powers are not big enough ;-) It's difficult to change the course of a ship that big. K. -- Mariola nudzi sie ... zagraj z nia! Sprawdz http://linkint.pl/f2779 -- 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: 1.7.6 snapshot: intermittent CreateProcessW failed
Greetings, Andy Koppe! C:/bin on /usr/bin type ntfs (binary,auto) C:/lib on /usr/lib type ntfs (binary,auto) C: on / type ntfs (binary,auto) Urgh. I hope you know what you're doing... Yeah, I do trust the Cygwin package maintainers not to overwrite /Windows or /Users. Actually that was a reference to C:/bin being a pointer to /usr/bin instead of /bin In normal installation it is that way plus /usr/bin as symlink to /bin Not the other way around. (sh is in /bin, with your structure, no way it could be reached through C:/bin ) -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.07.2010, 2:50 Sorry for my terrible english... -- 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: Mail program
Re: Cyrille Lefevre cyrille.lefevre-li...@laposte.net wrote: even w/ mailutils, you'il probably need a sendmail which is provided by ssmtp or msmtp... No,a seperately loaded sendmail would not be necessary D. Henman has told me that, the Gnu mailutils suite should have everything needed. It has a sendmail daemon, a mail program to send receive mail, and a movemail. For example I could use movemail to fetch mail messages from a yahoo or gmail pop account, similar to the function fetchmail performs. regards P.S. I use Gnu Mailutils, Gnu MH (Gnu Mail Handler) which enable emacs to use the MH-E functionality to compose/edit/read and store e-mail messages. Once used to emacs' MH-E for mail handling, I think most emacs users would really prefer it over stand ard firebird or explorer type message handling. -- 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: 1.7.6 snapshot: intermittent CreateProcessW failed
On 6/30/2010 6:52 PM, Andrey Repin wrote: Greetings, Andy Koppe! C:/bin on /usr/bin type ntfs (binary,auto) C:/lib on /usr/lib type ntfs (binary,auto) C: on / type ntfs (binary,auto) Urgh. I hope you know what you're doing... Yeah, I do trust the Cygwin package maintainers not to overwrite /Windows or /Users. Actually that was a reference to C:/bin being a pointer to /usr/bin instead of /bin In normal installation it is that way plus /usr/bin as symlink to /bin Not the other way around. (sh is in /bin, with your structure, no way it could be reached through C:/bin ) Actually, what Andy has is what 'setup.exe' provides if you install in 'C:\'. I have the same thing. So what he has is a normal installation if the user chooses to install in 'C:\'. Also, FWIW, 'setup.exe' does not create a symlink from '/usr/bin' to '/bin'. It only creates the mounts like what Andy shows above. -- 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
[ANNOUNCEMENT] New package: python-gdata-2.0.10-1
Version 2.0.10-1 of python-gdata has been uploaded. python-gdata is the Google Data Python Client Library. The Google Data Python Client Library provides a library and source code that make it easy to access data through Google Data APIs. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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
Updated: bash-completion-1.2-1
A new release of bash-completion, 1.2-1, is now available for download, leaving 1.1-2 as previous. NEWS: = This is a new upstream release. Changes since the prior release are attached. For more details, including how to enable bash-completion for your interactive shells after installing this package, see /usr/share/doc/bash-completion/. DESCRIPTION: bash-completion provides programmable completion enhancements to bash TAB-completion. Based on the command you type, hitting TAB later on in the command line will perform completions on strings that make sense for the context of the command, rather than blindly completing on filenames. NOTE: = You MUST edit your bash startup files to load bash-completion into memory: make sure ~/.bashrc sources /etc/bash_completion, and ~/.bash_profile sources ~/.bashrc. See /etc/defaults/etc/skel/.bashrc (after installing base-files-3.7-1) for an example. Bash completions is not enabled by default because it adds some noticeable startup delay to every interactive shell (about 1.5 seconds on my 2.5 GHz WinXP). Depending on the reaction on the cygwin mailing list, a future release may make bash_completion turned on by default for every bash user, with no edits to ~/.bashrc required. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'bash-completion' from the 'Shells' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin bash-completion maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. bash-completion (1.2) [ David Paleino ] * Don't use pidof in _known_hosts_real() to detect whether Avahi is available, since it's not available on MacOS X. Thanks to Rainer Müller rai...@codingfarm.de (bash-completion MacPorts maintainer) * Fixed freq and rate completion for iwconfig * contrib/munin-node fixed (Debian: #550943) * contrib/dpkg fixed -W and --show completing on .?(u)deb's (Debian: #552109) * contrib/aptitude: add @(add|remove)-user-tag * Added munindoc completion to contrib/munin-node, thanks to Tom Feiner (Debian: #553371) * Added colordiff completion, same as diff * contrib/cpio: added missing completions for -?, --help, --license, --usage, --version and (-p) --to-stdout (Debian: #557436) * Style policy: don't use fancy globbing in case labels * Added .fdf completion to okular and evince * Added .okular completion to okular (Debian: #545530) * Added lintian completion * Refreshed reportbug completion, added --from-buildd (Debian: #579471) * Special-case apt-get source (Debian: #572000) * Added lintian completion (Debian: #547361) * contrib/dpkg: update completion to current API * Styleguide: establish line wrapping and $() instead of `` [ Ville Skyttä ] * Create bz2 dist tarball too. * Include CHANGES in dist tarball. * Include profile snippet in tarball, install it. * Rename contrib/bluez-utils to contrib/bluez to follow bluez 4.x naming. * Apply cardctl completion to pccardctl too. * Apply pine completion to alpine too. * Remove many unnecessary short option completions where long ones exist. * Improve chsh, chgrp, chown, configure, curl, cvs, find, gkrellm, gzip, iconv, lftp, look, lzma, make, man, mdadm, modprobe, mount, mplayer, mysqladmin, perldoc, rsync, screen, service, scp, ssh, sshfs, unzip, update-alternatives, vncviewer, wget, yp-tools, xine based players' and general hostname completions. * Add abook and wtf completion, based on work by Raphaël Droz. * Add cvsps, dragon, fusermount, jarsigner, k3b, lftpget, modplug123, pm-utils, rtcwake, pack200, unpack200, pbzip2, pbunzip2, pbzcat, pigz, unpigz, and wol completions. * Don't overwrite other host completions when completing from multiple SSH known hosts files. * Speed up installed rpm package completion on SUSE, based on work by Marco Poletti (Alioth: #312021). * Improve sourcing snippets from completion dirs. * Drop support for bash 3. The compatiblity global variables
