Re: [ITP] xclip 0.12
On Sep 29 22:47, rolandc wrote: xclip is included in the Debian distribution: http://packages.debian.org/stable/xclip http://zfire.free.fr/cygwin/xclip-0.12-1.tar.bz2 http://zfire.free.fr/cygwin/xclip-0.12-1-src.tar.bz2 setup.hint - category: X11 requires: libXmu6 libX11_6 sdesc: Command line clipboard grabber ldesc: xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections (the clipboard) from the command line. It can read data from standard in or a file and place it in an X selection for pasting into other X applications. xclip can also print an X selection to standard out, which can then be redirected to a file or another program. Packaging looks good. It would be nice if you could provide not only the setup.hint in plain text, but also as downloadable link to simplify uploading. I uploaded this package with a tweak to setup.hint. The ldesc string contains quotation marks - (the clipboard). I just removed them. Please fix that in your local copy of setup.hint. Please send an announcement to the cygwin-announce mailing list per the description in http://cygwin.com/setup.html#submitting. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] tftp-hpa 5.0
Dear Chuck! First of all, thanks for your detailed review, response and your suggestions! Am 01.10.2010 17:47, schrieb Charles Wilson: We'll need to coordinate the release of tftp-hpa Hmmm...now that I think about it, it would be really great if the package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N Users aren't going to CARE that the implementation/source came from the 'tftp-hpa' distribution. [...] setup.exe doesn't have any provision for specifying conflicts. So, we can only have one (current) package that provides any specific file (such as /bin/tftp.exe or /usr/sbin/tftpd.exe). Ic. I'm not that of a Cygwin expert so I just trust your opinion here. Changing the package accordingly is fine for me. (Keeping inetutils' tftp implementation was just a quick idea w/o thinking about the conflict resolving stuff). While I don't really have any issues with remap, I wonder why you dropped tcpwrappers? It adds no complexity to the build, and helps -- to a certain degree -- with some of the security issues endemic to the tftp protocol. (Especially as tftpd-hpa operates in such a way that you *can't* call it via the 'tcpd' utility in inetd.conf). Also, the whole *point* of obsoleting inetutil's version is because it is not capable of support IPv6 -- but tftp-hpa is. So, I really think you should enable IPv6. Now, that means a lot of new porting work, because there are ALWAYS issues with porting IPv6 networking to cygwin/win32...see the rsh package's patches (also, xinetd). Ic. Well, what I've proposed here was the result of an internal project where we just needed bare-bone IPv4 tftpd functionality in an isolated environment w/o security concerns. As I ended up in quite some compiling errors (and found some posts suggesting that those aren't that easy to fix), I simply tried disabling features until tftpd finally worked. Worked for me, you know. :-) And as I wasn't sure if the package would be accepted or taken care of at all, I also didn't want to invest that much upfront effort, but chose to document limitations instead... We can for sure try to re-enable and fix all these issues, but as for you, my time for these tasks is also quite limited and I can't promise quick results here... Now, as far as dropping privileges...that's a tricky one. First, your assumption that most people will run tftpd as a standalone service under cygrunsrv is probably false. I imagine most people will use a superserver (inetd or xinetd) instead. [...] Thanks for all the insights on this complicated topic! Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as ANY privileged user at all: cygserver, Administrator, SYSTEM, ... [...] tftp is SO incredibly insecure it boggles the mind. Letting random *unauthenticated* users upload to your machine (or download), using the credentials of Administrator? Using client-specified paths? Not just no, but hell no. (Recall that cygwin doesn't *really* jail chrooted processes; they can always use win32 functions to break out). Hmmm, anyone running tftpd should know that (s)he should protect it from any productive network as it's insecure by design. In my eyes, putting tftpd behind an effective firewall is just the right answer here. Any effort spent to improve tftpd's security concept *if you don't trust his peers* will only raise the security bar from 10 to 12% IMHO. That's the reason why I didn't spend any effort on this yet and why I personally don't see this as a top-prio. That's, btw, also the reason why I decided not to provide a (postinstall) script which activates a Windows service. People who want to use this piece should really know what they're doing... We should probably take additional discussions offline, just to keep from annoying the list with ongoing development. Sure. I'll come back to you via private mail as soon as I had a detailed look on all your points... -- Gernot
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 5:28 AM, Corinna Vinschen wrote:
On Oct 4 10:24, Gernot Hillier wrote:
Am 01.10.2010 17:47, schrieb Charles Wilson:
So, I really think you should enable IPv6. Now, that means a lot of
new porting work, because there are ALWAYS issues with porting IPv6
networking to cygwin/win32...see the rsh package's patches (also,
xinetd).
Chuck, for the dumb of us, can you please reiterate in a few words
what problems you're talking about? I'm kind of in trouble to think
of any Cygwin-specific IPv6 problem apart from some border cases.
I have at least two packages which I use IPv6 with, openssh and
syslog-ng, and I have no trouble with them.
It's not so much *cygwin*, as *windows*. If a socket is opened to
listen for both IPv4 and IPv6 packets, then *all* received packets will
appear as IPv6 ones -- IPv4 ones will show up wrapped as
::::71.15.23.51 or something.
So, if the app listens for both packet types, it really better support
IPv4-in-IPv6 addressing. Many of them don't.
This isn't really a cygwin bug, but an application bug exposed by how
windows, underneath cygwin, handles mixed-mode sockets.
Also, when iterating interfaces, windows returns *a lot* more than the
obvious ones (like, my simple laptop with wireless + wired returns about
a dozen...some are VPN tunneling devices, etc) and IIRC lists the IPv6
ones first. There was also some issue, the details of which escape me
right now, related to IPv6 localhost ::1 and 127.0.0.1. But the point
is, on a windows machine the application MUST be able to deal with
multi-homed interfacing. A lot of the older apps aren't.
We can for sure try to re-enable and fix all these issues, but as for
you, my time for these tasks is also quite limited and I can't promise
quick results here...
IMHO a new tftp only makes sense if it has some visible advantages
over the old one. Tcpwrappers, readline and IPv6 shouldn't be that
tricky.
Yes on the first two...we'll just have to see on IPv6. Maybe tftp-hpa
is maintained well enough upstream that we won't see the problems that
cropped up wrt inetutils.
But we're all volunteers here. If it's not a security related problem,
we're not asking for quick.
Yep.
Hmmm, anyone running tftpd should know that (s)he should protect it from
any productive network as it's insecure by design. In my eyes, putting
tftpd behind an effective firewall is just the right answer here. Any
effort spent to improve tftpd's security concept *if you don't trust his
peers* will only raise the security bar from 10 to 12% IMHO.
Nevertheless, running tftp with admin privileges is not a good idea.
Maybe you should at least try to seteuid to uid 501, the default uid
for the Guest user.
I was thinking of borrowing a page from openssh's privsep 'sshd' user,
and using a -config script to create a 'tftpd' user. I did some work
over the weekend, and the way I have it structured now, tftpd will
(a) try to setuid to 'tftpd' (after chrooting, if -s is specified)
(b) unless -u USERNAME, in which case it will setuid to that user
(c) but, if USERNAME specified as the argument to -u is 'root', then
it will act like inetd/xinetd, where 'root' is taken to mean
'whatever privileged user I'm actually running as now': e.g.
setuid (getuid())
Unlike 'regular' tftpd, you're supposed to initially launch tftpd-hpa as
a privileged user, so it can chroot if required. It then drops
privileges by changing all of its IDs.
If anything fails, tftpd logs the error and exits; it never attempts to
keep going without dropping privileges -- unless you told it to remain
in a privileged state via '-u root'.
I've also moved the missing arpa/tftp.h header from inetutils to this
package, and restructured the installation process to use the package's
INSTALLROOT support instead of configuring with ${D} in the --prefix
argument. It builds and creates the packages, but...
I just have to test it.
(I've done nothing with regards to IPv6, readline, or tcpwrappers yet).
The tftpd-config script also gives you a choice between installing tftpd
as a superserver client, OR as a standalone service (in which case, the
server needs to be installed to run as cyg_server, but have the -u tftpd
argument). On a virgin machine, this means that tftpd-config would need
to create both the cyg_server privileged user AND the tftpd unprivileged
user. It's very similar to ssh-host-config.
Anyway, once I've done that, I'll send|post the updated tarballs before
beginning to address IPv6 et al -- which might not happen for a week or two.
We should probably take additional discussions offline, just to keep
from annoying the list with ongoing development.
Sure. I'll come back to you via private mail as soon as I had a
detailed look on all your points...
I disagree. We already had a lot of discussion about porting packages
to the Cygwin distro on this list. It might be worth to keep it here,
unless the two of you want to share
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 4:24 AM, Gernot Hillier wrote:
First of all, thanks for your detailed review, response and your
suggestions!
You're welcome.
Am 01.10.2010 17:47, schrieb Charles Wilson:
We'll need to coordinate the release of tftp-hpa
Hmmm...now that I think about it, it would be really great if the
package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N
Users aren't going to CARE that the implementation/source came from
the 'tftp-hpa' distribution.
Ic. I'm not that of a Cygwin expert so I just trust your opinion here.
Changing the package accordingly is fine for me. (Keeping inetutils'
tftp implementation was just a quick idea w/o thinking about the
conflict resolving stuff).
OK. My revised package does this.
So, I really think you should enable IPv6. Now, that means a lot of
new porting work, because there are ALWAYS issues with porting IPv6
networking to cygwin/win32...see the rsh package's patches (also,
xinetd).
Ic.
Well, what I've proposed here was the result of an internal project
where we just needed bare-bone IPv4 tftpd functionality in an isolated
environment w/o security concerns. As I ended up in quite some compiling
errors (and found some posts suggesting that those aren't that easy to
fix), I simply tried disabling features until tftpd finally worked.
Worked for me, you know. :-)
And that's great; obviously your internal team can continue to use what
you have, until the revised version comes along. In fact, it's great
that you have an in-place testing environment; we can easily make sure
that the revised versions don't break anything.
And as I wasn't sure if the package would be accepted or taken care of
at all, I also didn't want to invest that much upfront effort, but chose
to document limitations instead...
That makes sense. However, as we/I are *very* enthusiastic about
deleting inetutils' tftp in favor of tftp-hpa, now's the time to make
that investment.
We can for sure try to re-enable and fix all these issues, but as for
you, my time for these tasks is also quite limited and I can't promise
quick results here...
NP.
Now, as far as dropping privileges...that's a tricky one. First,
your assumption that most people will run tftpd as a standalone
service under cygrunsrv is probably false. I imagine most people will
use a superserver (inetd or xinetd) instead.
[...]
Thanks for all the insights on this complicated topic!
Acquired through PAINFUL experience :-{
Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as
ANY privileged user at all: cygserver, Administrator, SYSTEM, ...
[...]
tftp is SO incredibly insecure it boggles the mind. Letting random
*unauthenticated* users upload to your machine (or download), using
the credentials of Administrator? Using client-specified paths? Not
just no, but hell no. (Recall that cygwin doesn't *really* jail
chrooted processes; they can always use win32 functions to break
out).
Hmmm, anyone running tftpd should know that (s)he should protect it from
any productive network as it's insecure by design. In my eyes, putting
tftpd behind an effective firewall is just the right answer here. Any
effort spent to improve tftpd's security concept *if you don't trust his
peers* will only raise the security bar from 10 to 12% IMHO.
True. Client IP's CAN be spoofed -- but cygwin's tcp wrappers operates
by default in PARANOID mode, so the attacker would also have to hijack
the local DNS server. Not impossible, but worth more than +2%
difficulty rating.
That's the reason why I didn't spend any effort on this yet and why I
personally don't see this as a top-prio.
Well, it should Just Work(tm); tcp_wrappers does all the heavy lifting.
We'll see.
That's, btw, also the reason why I decided not to provide a
(postinstall) script which activates a Windows service. People who want
to use this piece should really know what they're doing...
Well, that's true of most insecure services. However, tftp-hpa DOES
drop privileges (assuming we un-#ifdef-out that stuff), so it NEEDS an
unprivileged user to change to. Since windows doesn't have a default
'nobody' user (other than Guest, and often that account is disabled
entirely), we need a script to create one. Even if it doesn't install
the service.
The problem with NOT making the process relatively turnkey simple, is
that you will spend five times the effort multiply answering FAQs on the
mailing list...How do I... This way, your form letter response is:
0) Read the documentation
1) run tftp-config
2) run xinetd-config
3) edit /etc/xinetd.d/tftp
- disabled yes
+ disabled no
4) (re)start xinetd:
cygrunsrv -E xinetd
cygrunsrv -S xinetd
Cut-n-paste as needed...(and note, variations like 'use inetd instead'
or 'install tftpd as a standalone service' are not mentioned; save that
for the documentation that nobody will read.)
We should probably take additional discussions offline, just to keep
from
[RFU] serf-0.7.0-1
Please leave 0.3.1-1 as current and delete all previous versions. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/libserf0-devel-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/libserf0_1-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/setup.hint -- David Rothenberger daver...@acm.org
Re: [ITP] tftp-hpa 5.0
On Oct 4 11:10, Charles Wilson wrote: On 10/4/2010 5:28 AM, Corinna Vinschen wrote: On Oct 4 10:24, Gernot Hillier wrote: Am 01.10.2010 17:47, schrieb Charles Wilson: So, I really think you should enable IPv6. Now, that means a lot of new porting work, because there are ALWAYS issues with porting IPv6 networking to cygwin/win32...see the rsh package's patches (also, xinetd). Chuck, for the dumb of us, can you please reiterate in a few words what problems you're talking about? I'm kind of in trouble to think of any Cygwin-specific IPv6 problem apart from some border cases. I have at least two packages which I use IPv6 with, openssh and syslog-ng, and I have no trouble with them. It's not so much *cygwin*, as *windows*. If a socket is opened to listen for both IPv4 and IPv6 packets, then *all* received packets will appear as IPv6 ones -- IPv4 ones will show up wrapped as ::::71.15.23.51 or something. Which functions are you talking about? getpeername? accept? readfrom? getaddrinfo? All of them? If so, we could do something about that by massaging the returned addresses from V4-in-V6 into plain V4 addresses. Since the memory region used for V6 can easily contain a V4 address, we don't have to change any memory allocation or so, just tweak the content of the sockaddr structure. Well, except in case AI_V4MAPPED is specified in getaddrinfo... So, if the app listens for both packet types, it really better support IPv4-in-IPv6 addressing. Many of them don't. This isn't really a cygwin bug, but an application bug exposed by how windows, underneath cygwin, handles mixed-mode sockets. Also, when iterating interfaces, windows returns *a lot* more than the obvious ones (like, my simple laptop with wireless + wired returns about a dozen...some are VPN tunneling devices, etc) and IIRC lists the IPv6 ones first. There was also some issue, the details of which escape me right now, related to IPv6 localhost ::1 and 127.0.0.1. But the point is, on a windows machine the application MUST be able to deal with multi-homed interfacing. A lot of the older apps aren't. Well, that's not exactly just a Windows problem. Any interface can at any time return more than one V4 and more than one V6 address. Not only my Windows machines, but also my Linux machines typically have at least one V4 and two V6 addresses. A tool which doesn't grok this is just horribly broken. I guess the age of inetutils really shows... Nevertheless, running tftp with admin privileges is not a good idea. Maybe you should at least try to seteuid to uid 501, the default uid for the Guest user. I was thinking of borrowing a page from openssh's privsep 'sshd' user, and using a -config script to create a 'tftpd' user. I did some work over the weekend, and the way I have it structured now, tftpd will (a) try to setuid to 'tftpd' (after chrooting, if -s is specified) (b) unless -u USERNAME, in which case it will setuid to that user (c) but, if USERNAME specified as the argument to -u is 'root', then it will act like inetd/xinetd, where 'root' is taken to mean 'whatever privileged user I'm actually running as now': e.g. setuid (getuid()) Unlike 'regular' tftpd, you're supposed to initially launch tftpd-hpa as a privileged user, so it can chroot if required. It then drops privileges by changing all of its IDs. If anything fails, tftpd logs the error and exits; it never attempts to keep going without dropping privileges -- unless you told it to remain in a privileged state via '-u root'. Sounds good to me. Anyway, once I've done that, I'll send|post the updated tarballs before beginning to address IPv6 et al -- which might not happen for a week or two. Just to let you know, I'll be mostly unavailable for the next five weeks starting this weekend. If there's something required in terms of the aforementioned V4inV6 problem, the time to do something is either now or late in November. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] tftp-hpa 5.0
Hi there! Am 04.10.2010 17:24, schrieb Charles Wilson: Hmmm...now that I think about it, it would be really great if the package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N Users aren't going to CARE that the implementation/source came from the 'tftp-hpa' distribution. Ic. I'm not that of a Cygwin expert so I just trust your opinion here. Changing the package accordingly is fine for me. (Keeping inetutils' tftp implementation was just a quick idea w/o thinking about the conflict resolving stuff). OK. My revised package does this. Ok, so I'll wait for your update... And that's great; obviously your internal team can continue to use what you have, until the revised version comes along. In fact, it's great that you have an in-place testing environment; we can easily make sure that the revised versions don't break anything. ... and try to push it into our product's mainline which should be well possible in the next weeks. However, please note that we don't use IPv6 and have no testbed for this. That makes sense. However, as we/I are *very* enthusiastic about deleting inetutils' tftp in favor of tftp-hpa, now's the time to make that investment. :-) Let me know when I can help. That's the reason why I didn't spend any effort on this yet and why I personally don't see this as a top-prio. Well, it should Just Work(tm); tcp_wrappers does all the heavy lifting. We'll see. Yes, I'll have a look on it as soon as I receive your update. Well, that's true of most insecure services. However, tftp-hpa DOES drop privileges (assuming we un-#ifdef-out that stuff), so it NEEDS an unprivileged user to change to. Since windows doesn't have a default 'nobody' user (other than Guest, and often that account is disabled entirely), we need a script to create one. Even if it doesn't install the service. Convinced. -- Gernot
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 12:02 PM, Corinna Vinschen wrote: On Oct 4 11:10, Charles Wilson wrote: It's not so much *cygwin*, as *windows*. If a socket is opened to listen for both IPv4 and IPv6 packets, then *all* received packets will appear as IPv6 ones -- IPv4 ones will show up wrapped as ::::71.15.23.51 or something. Which functions are you talking about? getpeername? accept? readfrom? getaddrinfo? All of them? I'm going by memory here...and I don't recall. :-( I'll have to review those threads. If so, we could do something about that by massaging the returned addresses from V4-in-V6 into plain V4 addresses. Since the memory region used for V6 can easily contain a V4 address, we don't have to change any memory allocation or so, just tweak the content of the sockaddr structure. Well, except in case AI_V4MAPPED is specified in getaddrinfo... Well, that's basically what happens already. Incoming V4 packets get turned into AI_V4MAPPED ones, always, IIRC -- when the socket was set for both V4 and V6. Properly written applications, which claim to support V6, should handle V4-in-V6 seamlessly. If they don't, then it's an application bug. If they can only deal with true IPv4 packages or full IPv6 packets...then they should open two sockets, one in V6-only mode on the V6 address, and one in V4-only mode on the V4 address -- and even then it would fail if some other router mapped an incoming IPv4 as V4-in-V6 before it ever gets to your computer! It's easier, really, to just FIX the application to fully support V6, including the V4 variations. Otherwise, it doesn't REALLY support V6, now does it? Well, that's not exactly just a Windows problem. Any interface can at any time return more than one V4 and more than one V6 address. Not only my Windows machines, but also my Linux machines typically have at least one V4 and two V6 addresses. A tool which doesn't grok this is just horribly broken. I guess the age of inetutils really shows... Bingo. I always say that inetutils doesn't support IPv6 but that's not entirely true. inetd kinda sorta does, but badly -- which is where I ran into all of these issue; the patch is...large. The regular servers like rshd etc don't seem to support IPv6 at all. That's the main reason I'm (slowly) trying to use more modern implementations of the regular servers, which DO support IPv6. Like tftp-hpa. I was thinking of borrowing a page from openssh's privsep 'sshd' user, and using a -config script to create a 'tftpd' user. ... If anything fails, tftpd logs the error and exits; it never attempts to keep going without dropping privileges -- unless you told it to remain in a privileged state via '-u root'. Sounds good to me. :-) Anyway, once I've done that, I'll send|post the updated tarballs before beginning to address IPv6 et al -- which might not happen for a week or two. Just to let you know, I'll be mostly unavailable for the next five weeks starting this weekend. If there's something required in terms of the aforementioned V4inV6 problem, the time to do something is either now or late in November. If there is an actual problem that requires cygwin changes (which I doubt) then Nov is soon enough. I don't think it's a good idea for cygwin to automatically unwrap v4-in-v6, because we have no (easy) way of knowing if the packet ACTUALLY arrived on the v6 interface because somebody ELSE wrapped it before it reached our ethernet port, or if Windows wrapped something that arrived on the v4 interface, and then presented it to cygwin AS IF it arrived on the V6 interface, as a V4-in-V6 packet. This unwrapping is an application-level decision, IMO. It just means applications with (poorly coded) IPv6 support need additional fixin' before it will work as expected on cygwin, in mixed-mode environments. You're right, tho, that this is /not/ a cygwin-specific problem; there are many multi-homed and mixed-mode unix systems... -- Chuck
Re: [ITP] tftp-hpa 5.0
On Oct 4 13:13, Charles Wilson wrote: On 10/4/2010 12:02 PM, Corinna Vinschen wrote: If so, we could do something about that by massaging the returned addresses from V4-in-V6 into plain V4 addresses. Since the memory region used for V6 can easily contain a V4 address, we don't have to change any memory allocation or so, just tweak the content of the sockaddr structure. Well, except in case AI_V4MAPPED is specified in getaddrinfo... Well, that's basically what happens already. Incoming V4 packets get turned into AI_V4MAPPED ones, always, IIRC -- when the socket was set for both V4 and V6. Erm... hang on. A socket is created for only one domain/address family, AF_INET, AF_UNIX, AF_INET6. There's no such thing as a socket supporting more than one address family or more than one socket type (stream/dgram). It's easier, really, to just FIX the application to fully support V6, including the V4 variations. Otherwise, it doesn't REALLY support V6, now does it? Sure, you're right. Just to let you know, I'll be mostly unavailable for the next five weeks starting this weekend. If there's something required in terms of the aforementioned V4inV6 problem, the time to do something is either now or late in November. If there is an actual problem that requires cygwin changes (which I doubt) then Nov is soon enough. I don't think it's a good idea for cygwin to automatically unwrap v4-in-v6, because we have no (easy) way of knowing if the packet ACTUALLY arrived on the v6 interface because somebody ELSE wrapped it before it reached our ethernet port, or if Windows wrapped something that arrived on the v4 interface, and then presented it to cygwin AS IF it arrived on the V6 interface, as a V4-in-V6 packet. This unwrapping is an application-level decision, IMO. It just means applications with (poorly coded) IPv6 support need additional fixin' before it will work as expected on cygwin, in mixed-mode environments. There's a difference between Linux and Windows, though, which affects the returned addresses from getaddrinfo, if the AI_V4MAPPED and AI_ALL flags are set. In this case Linux returns V6 and V4 addresses, both formatted in their real address family. Unless the given host has no V6 address, in which case the V4 addresses are returned as V4inV6 addresses. On Windows, AI_V4MAPPED | AI_ALL always returns the V4 addresses as V4inV6 addresses. I read the SUSv4 getaddrinfo man page, and from what I can tell both results should be ok: If the AI_V4MAPPED flag is specified along with an ai_family of AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses on finding no matching IPv6 addresses [...] If the AI_ALL flag is used with the AI_V4MAPPED flag, then getaddrinfo() shall return all matching IPv6 and IPv4 addresses. As you can see, the text does not specify that in the AI_V4MAPPED | AI_ALL case the IPv4 addresses should be returned in a given address family. This *could* be changed in Cygwin to follow the Linux behaviour. However, I have no idea if that affects your case, of course... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] serf-0.7.0-1
On Oct 4 08:51, David Rothenberger wrote: Please leave 0.3.1-1 as current and delete all previous versions. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/libserf0-devel-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/libserf0_1-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/setup.hint Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RFU: python-gdata-2.0.12-1
Please upload: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1.tar.bz2 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1-src.tar.bz2 --- Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
RFU: cppcheck-1.45-1
Please upload: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1.tar.bz2 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1-src.tar.bz2 --- Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
[RFU] libaprutil1-1.3.10-1
wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/setup.hint -- David Rothenberger daver...@acm.org
Re: RFU: python-gdata-2.0.12-1
On Mon, 2010-10-04 at 17:54 -0400, Chris Sutcliffe wrote: http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1.tar.bz2 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1-src.tar.bz2 Uploaded. Yaakov
Re: RFU: cppcheck-1.45-1
On Mon, 2010-10-04 at 18:08 -0400, Chris Sutcliffe wrote: http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1.tar.bz2 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1-src.tar.bz2 Uploaded. Yaakov
Re: [RFU] libaprutil1-1.3.10-1
On Mon, 2010-10-04 at 16:35 -0700, David Rothenberger wrote: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/setup.hint Uploaded. Yaakov
Re: Xlib.h not found
Thank you very much. This solved my problem. Best regards, GD Hi, I installed the xinit package for cygwin, but I cannot find the file Xlib.h. Where is it located, or why was it not installed? Thanks for your help GD it is not installed because you did not request the development package libX11-devel see : http://cygwin.com/packages/ http://cygwin.com/cgi-bin2/package-grep.cgi?grep=Xlib.h Regards Marco -- 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/
Xlib.h not found
Hi, I installed the xinit package for cygwin, but I cannot find the file Xlib.h. Where is it located, or why was it not installed? Thanks for your help GD -- 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: gvim ends when the OPEN menu-item is selected
--- Mar 5/10/10, Larry Hall (Cygwin X) ha scritto: On 10/4/2010 6:23 AM, James Anderson wrote: Rodrigo Medinarodmedinaat cantv.net writes: Hi, I have just installed gvim. I have never used it before. After starting Xwin -multiwindow I run gvim. A window appears, but when the OPEN or SAVE AS menu-items are selected the program ends Me Too! Cygwin 1.8.2 and gvim 7.3.3 on 32bit XP sp3 I assume you meant Cygwin 1.7.2? The latest Cygwin package is 1.7.7. 1.8.2 looks the XWin server version -- Larry Hall -- 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/
libglade2.0.sh exit code 2
Hi all, I just installed libglade as an automatically-detected dependency of pygtk, and it complained of an exit code 2 in the post-install. Looking at /var/log/install.log.full didn't show anything out of the ordinary (no error messages at all) Other than this, it seems to work fine. Is this just a stray exit code? Regards, Ryan -- 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: How to get cygwin path
Afflictedd2 wrote: Ok. nm... it has to be this way: cygpath -u C:\Users\Viper\Tmp Using single quotes would be more general. Consider the difference if the pathname includes a substring like \r. (Backslash is inert in (bash/sh/etc.) single-quoted strings, but sometimes escapes the following character in double-quoted strings. Daniel -- 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
Update/Refesh TCL/Expect package
Hi All, I have developed automation software based on TCL/Expect called expect-lite. However the version in the Cygwin repo is quite old (from 2003). After a bit of effort, I have compiled a more modern version of TCL/Expect under Cygwin. Is there someone who would be willing to take the binaries (or directions on how to compile) and package them? You may be asking why I am not doing this? Because I don't really use cygwin, but I have expect-lite users who do, and I need to support it. TIA, Craig... -- 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: bash bug?: nested bash --login -i doesn't run /etc/profile (still runs ~/.bash_profile)
I wrote: The behavior of bash --login -i seems to vary depending on whether it is a root invocation or a nested invocation of bash. This is inconsistent with the description man bash, and seems to be a bug. Can anyone confirm (or anti-confirm) this behavior?: Details: When bash is started using the Cygwin shortcut (which runs cygwin.bat, which executes bash --login -i), bash reads files /etc/profile and ~/.bash_profile. (Running bash --login -i from an interactive cmd shell does the same.) However, when in that first bash process, another bash is started with that same bash --login -i command, bash does _not_ read /etc/profile. Interestingly, that nested bash shell _does_ still read ~/.bash_profile. According to the bash manual page, bash --login -i should read /etc/profile in either case. (There is no mention of anything, e.g., an environment variable from the context of the invocation, that changes the behavior of that command.) An additional symptom is that the nested bash does not listen to SHELLOPTS as expected: A root invocation notices igncr, verbose, and xtrace in the SHELLOPTS value from its invocation environment (the Windows/cmd environment variable) as specified--it ends up setting SHELLOPTS in itself to a value that includes those options. On the other hand, a nested invocation seems to ignore the SHELLOPTS from its invocation environment (the environment variable from the first bash shell/process)--it sets its SHELLOPTS to a value that does _not_ include those options.) Steps to reproduce (and easily see difference): 1. Set Windows environment variable SHELLOPTS to igncr:verbose:xtrace. 2. Start bash using the installer-created Cygwin shortcut. 3. Notice (from the output from the verbose and xtrace options) that bash runs /etc/profile and then ~/.bash_profile. 4. Notice (from set) that SHELLOPTS in bash includes igncr, verbose and xtrace (among other options). 5. Execute bash --login -i. 6. Notice (again, from the verbose/xtrace output) that bash does _not_ run /etc/profile, but still runs ~/.bash_profile. 7. Notice that SHELLOPTS in that invocation of bash does not include igncr, verbose or xtrace. It seems that something is going wrong between the points at which bash reads SHELLOPTS and runs /etc/profile and the point at which bash runs ~/.bash_profile. Thanks, Daniel -- 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
Emacs Gnus elisp source?
I'm using the Cygwin X version of Emacs Gnus for email. I recently switched from some other version of TLS to the Cygwin gnutls. When I switched, it started prompting me for the send password with each email I send. Previously, it would cache the password somewhere. I'd like to debug this, but the elisp source files are missing, and I don't see how to get the Cygwin installer to install them. I also don't see the precise version on the FSF Gnu FTP site; Emacs reports 23.2.1, but I only see 23.2 there. Where and how do I get the elisp source for Cygwin X Emacs? Hints on getting gnutls to work better with Emacs Gnus are also welcome. -- -- Stephe -- 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: Possible Windows 7 issue? cc1.exe: error while loading shared libraries: ?
Hello, I am wondering if anyone has encountered or might now how to fix the following issue: /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I have been using cygwin with ease for a couple years now, but recently things aren't quite working out. This issue started when I upgraded my operating system to Windows 7 64-bit. Anytime I attempt to compile a C or C++ program (cc1plus.exe in that case), I get the above error. I only get the error if I attempt to compile from the windows command prompt. If I run gcc in the Cygwin shell I have no problems. I have tried reinstalling cygwin a few times to no avail. I just got a new laptop yesterday, same operating system, and I am getting the same problem again. Just another reason I feel like it's an operating system issue. Sorry if I have left out some crucial piece of information. ~Tag Ashby cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possible Windows 7 issue? cc1.exe: error while loading shared libraries: ?
On 10/4/2010 10:35 AM, Taggart Ashby wrote: This issue started when I upgraded my operating system to Windows 7 64-bit. Anytime I attempt to compile a C or C++ program (cc1plus.exe in that case), I get the above error. I only get the error if I attempt to compile from the windows command prompt. If I run gcc in the Cygwin shell I have no problems. When you install the new OS, the non-standard paths you once set up don't get replicated by magic. It's probably better that they don't. -- 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: Emacs Gnus elisp source?
On 10/4/2010 1:07 PM, Stephen Leake wrote: I'm using the Cygwin X version of Emacs Gnus for email. I recently switched from some other version of TLS to the Cygwin gnutls. When I switched, it started prompting me for the send password with each email I send. Previously, it would cache the password somewhere. I'd like to debug this, but the elisp source files are missing, and I don't see how to get the Cygwin installer to install them. The elisp source files are in the emacs-el package. I also don't see the precise version on the FSF Gnu FTP site; Emacs reports 23.2.1, but I only see 23.2 there. This is a common source of confusion. The short answer is that you should ignore the final '.1'. For a longer answer, see http://cygwin.com/ml/cygwin/2010-08/msg00891.html Hints on getting gnutls to work better with Emacs Gnus are also welcome. There's been a lot of discussion about this lately on the emacs-devel mailing list, which I haven't been following in detail. I think you can expect a lot of improvement in gnutls integration in emacs-24, but probably not before that. Ken -- 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: Emacs Gnus elisp source?
Ken Brown kbr...@cornell.edu writes: On 10/4/2010 1:07 PM, Stephen Leake wrote: I'm using the Cygwin X version of Emacs Gnus for email. I recently switched from some other version of TLS to the Cygwin gnutls. When I switched, it started prompting me for the send password with each email I send. Previously, it would cache the password somewhere. I'd like to debug this, but the elisp source files are missing, and I don't see how to get the Cygwin installer to install them. The elisp source files are in the emacs-el package. Ah. I did look, but apparently I just didn't see that. Sorry for the noise. Now I can see the sources; thanks. I also don't see the precise version on the FSF Gnu FTP site; Emacs reports 23.2.1, but I only see 23.2 there. This is a common source of confusion. The short answer is that you should ignore the final '.1'. For a longer answer, see http://cygwin.com/ml/cygwin/2010-08/msg00891.html Ok, thanks; I've never noticed that before. Hints on getting gnutls to work better with Emacs Gnus are also welcome. There's been a lot of discussion about this lately on the emacs-devel mailing list, which I haven't been following in detail. Me either; too much traffic. I think you can expect a lot of improvement in gnutls integration in emacs-24, but probably not before that. Ok, thanks -- -- Stephe -- 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: How to run Cygwin as the root user ?
Thank you Larry for this, Note: I was unsure on how to reply to this so that the thread would be followed. What's the best way ? == Re: How to run Cygwin as the root user ? * From: Larry Hall \(Cygwin\) reply-to-list-only-lh at cygwin dot com * To: cygwin at cygwin dot com * Date: Fri, 01 Oct 2010 17:36:26 -0400 * Subject: Re: How to run Cygwin as the root user ? * References: 8c16dedef6de8b418a724b298297a5300414f...@s0-ott-x3.nrn.nrcan.gc.ca * Reply-to: cygwin at cygwin dot com On 10/1/2010 5:23 PM, Clement, Sebastien wrote: A very basic question but how can we do that ? Cygwin runs as whatever user you start it as. Log in and run it. If you need to switch users, you should install the 'openssh' package, read the readme and configure it, and use 'ssh'. There is no 'root' user in Windows and therefore Cygwin. Something close (but certainly not at all the same) is Administrator. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Possible Windows 7 issue? cc1.exe: error while loading shared libraries: ?
Taggart Ashby unknownsoldier1...@gmail.com writes: Hello, I am wondering if anyone has encountered or might now how to fix the following issue: /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I got a similar message when trying to install Cygwin from scratch. I think the missing dll was cyggcc_s-1.dll (sorry, I did not take good notes). I had to copy that file from a .tar.gz to /bin by hand, then the install went thru. Apparently there is a missing dependency. Note: if you run an executable from Windows Explorer, you get a better message about what DLL is missing (MS finally did something right!). I have been using cygwin with ease for a couple years now, but recently things aren't quite working out. This issue started when I upgraded my operating system to Windows 7 64-bit. Anytime I attempt to compile a C or C++ program (cc1plus.exe in that case), I get the above error. I only get the error if I attempt to compile from the windows command prompt. That makes it sound like a path problem. -- -- Stephe -- 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: Emacs Gnus elisp source?
Stephen Leake stephen.a.le...@nasa.gov writes: Ken Brown kbr...@cornell.edu writes: On 10/4/2010 1:07 PM, Stephen Leake wrote: I'm using the Cygwin X version of Emacs Gnus for email. I recently switched from some other version of TLS to the Cygwin gnutls. When I switched, it started prompting me for the send password with each email I send. Previously, it would cache the password somewhere. I'd like to debug this, but the elisp source files are missing, and I don't see how to get the Cygwin installer to install them. The elisp source files are in the emacs-el package. Ah. I did look, but apparently I just didn't see that. Sorry for the noise. Now I can see the sources; thanks. Just FYI, the problem turned out to be password-cache-expiry; it was set to 16 seconds. I had upgraded Emacs versions as well, apparently this is a new feature. -- -- Stephe -- 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 packages: {serf,libserf0_1,libserf0-devel}-0.7.0-1
The serf packages have been updated to the new upstream release 0.7.0. See http://code.google.com/p/serf/source/browse/tags/0.7.0/CHANGES for more details about the changes in this release. More information about serf can be found at http://code.google.com/p/serf/. CYGWIN NOTES: = This release increases the version of the libserf0 library from 0 to 1, so libserf0_0 and libserf0_1 may be installed in parallel. This is necessary because applications linked against serf-0.3.1-1 will not run with serf-0.7.0-1 and vice versa. Note that upstream did not increase the library version. Please note that 0.7.0 is not API-compatible with 0.3.1. Applications compiled against 0.3.1 may require changes to compile against 0.7.0. DESCRIPTION: The serf library is a C-based HTTP client library built upon the Apache Portable Runtime (APR) library. It multiplexes connections, running the read/write communication asynchronously. Memory copies and transformations are kept to a minimum to provide high performance operation. DOWNLOAD: = Note that downloads from sources.redhat.com (aka 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. 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org -- 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: Possible Windows 7 issue? cc1.exe: error while loading shared libraries: ?
On Mon, Oct 4, 2010 at 11:20 AM, Stephen Leake stephen.a.le...@nasa.gov wrote: Taggart Ashby unknownsoldier1...@gmail.com writes: Hello, I am wondering if anyone has encountered or might now how to fix the following issue: /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I got a similar message when trying to install Cygwin from scratch. I think the missing dll was cyggcc_s-1.dll (sorry, I did not take good notes). I had to copy that file from a .tar.gz to /bin by hand, then the install went thru. Apparently there is a missing dependency. Note: if you run an executable from Windows Explorer, you get a better message about what DLL is missing (MS finally did something right!). I have been using cygwin with ease for a couple years now, but recently things aren't quite working out. This issue started when I upgraded my operating system to Windows 7 64-bit. Anytime I attempt to compile a C or C++ program (cc1plus.exe in that case), I get the above error. I only get the error if I attempt to compile from the windows command prompt. That makes it sound like a path problem. -- -- Stephe The path is set to C:/cygwin/bin which is where it is located. :-\ ~Tag Ashby -- 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
trouble posting to cygwin-apps
Hi, Sorry if this is the wrong mailing list for this, but I am trying to get a new CMake release uploaded to cygwin and am having some trouble. I can not seem to post messages to the cygwin-apps mailing list. I tried to re-subscribe my email address, but it correctly said I was already subscribed. Is there anyone on this list that could help me? Thanks. -Bill -- 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: bash bug?: nested bash --login -i doesn't run /etc/profile (still runs ~/.bash_profile)
On 10/4/2010 12:19 PM, Daniel Barclay wrote: I wrote: The behavior of bash --login -i seems to vary depending on whether it is a root invocation or a nested invocation of bash. This is inconsistent with the description man bash, and seems to be a bug. Can anyone confirm (or anti-confirm) this behavior?: Details: When bash is started using the Cygwin shortcut (which runs cygwin.bat, which executes bash --login -i), bash reads files /etc/profile and ~/.bash_profile. (Running bash --login -i from an interactive cmd shell does the same.) However, when in that first bash process, another bash is started with that same bash --login -i command, bash does _not_ read /etc/profile. Works for me. -- 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: How to run Cygwin as the root user ?
On 10/4/2010 2:17 PM, Clement, Sebastien wrote: On Fri, 01 Oct 2010 17:36:26, Larry Hall wrote: On 10/1/2010 5:23 PM, Clement, Sebastien wrote: A very basic question but how can we do that ? Cygwin runs as whatever user you start it as. Log in and run it. If you need to switch users, you should install the 'openssh' package, read the readme and configure it, and use 'ssh'. There is no 'root' user in Windows and therefore Cygwin. Something close (but certainly not at all the same) is Administrator. Thank you Larry for this, Note: I was unsure on how to reply to this so that the thread would be followed. What's the best way ? Just a reply is enough. _ 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: strange crashes on invocation
On 10/1/2010 5:02 PM, Christopher Faylor wrote: On Mon, Sep 27, 2010 at 11:52:12AM -0500, Heath Kehoe wrote: Ugh! spoke too soon. It happened again: 1 [main] bash 5112! C:\cygwin\bin\bash.exe: *** fatal error - could not load C:\Windows\system32\ws2_32.dll, Win32 error 998 Stack trace: Frame Function Args 00288974 6102740B (00288974, , , ) 00288C64 6102740B (61179C40, 8000, , 6117B997) 00289C94 61004B2B (6117B084, 00289CB0, , ) 00289EE4 6100136E (61053A2A, 0154, 0002, 0002) It's definitely a lot less frequent, though. I truly do not understand why playing with the stack should have any effect but I've added a retry loop to the LoadLibrary call after reading some vague MSDN articles which indicated that it could fail mysteriously. So: How about how? http://cygwin.com/snapshots.html cgf Running from CVS from Friday with your retry loop, I still had the same error happen once, so apparently the retry loop didn't help for me. I have since updated CVS to that of today (10/4), and thus far have not seen the error. If it continues to happen, I should be able to take some time this week to create a test case so that others can repro the problem. -h __ 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
1.5 to 1.7 upgrade.
I held off updating two machines from Cygwin 1.5 to 1.7 until this week because they were critical to a product test and release process. These Cygwin installations are nearly vanilla and the upgrades went very smoothly and except for one crucial item everything seems to have worked as expected. Kudos to every one who contributed to this effort! Here's what didn't work. Both machines map a Samba file system to the F: drive via the normal windows mechanisms and I can read/write files in these file system via windows. However creating or writing files in these file systems via Cygwin now fails whereas prior to the upgrade this was just fine. When I list the cygdrive directory, I get $ ls -l total 1024 drwxrwxr-x+ 1 Administrators SYSTEM 0 2010-10-02 02:08 c drwxrwxr-x 4 0 2009-10-30 08:08 f and $ ls -l -n total 1024 drwxrwxr-x+ 1544 18 0 2010-10-02 02:08 c drwxrwxr-x 4 4294967295 4294967295 0 2009-10-30 08:08 f I can't remember what user / groups used to appear, but the fact that I get the 4294967295 is clearly related to the problem. Mount shows $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) which seems perfectly normal. The Samba version on the remote machine (Linux) is 3.0.10-1.4E.9. Some time ago, I remember seeing e-mail in the cygwin mailing list reporting similar issues, but I don't remember the resolution and searching has not produced one. I ran the /bin/copy-user-registry-fstab script as a precaution, but this understandably didn't do anything because I never had any mount points to begin with. I don't particularly want to ask the sys admins to upgrade Samba and am looking for a workaround. Any help would be appreciated. Andy Hall -- 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
1.5 to 1.7 upgrade.
Slight embarrassment here. Things are not quite as described below but there is a problem. 1. The file systems in F: are indeed writeable, as test with echo builds/test demonstrated. This is what you would expect given the permissions shown by ls despite the question marks in the uid and gid fields. What is bizarre is that on one machine which is Windows 2003 Server SP2, the following happens bu...@taurus /cygdrive/f $ ls -l total 2048 drwxrwxr-x 36 0 2010-10-04 19:19 builds drwxrwxr-x 17 0 2010-10-04 18:23 releases bu...@taurus /cygdrive/f $ test -w /cygdrive/f/builds bu...@taurus /cygdrive/f $ echo $? 1 Which is why I originally thought the file system is not writeable. On the other machine which is Windows XP Professional, you have $ ls -l total 2048 drwxrwxr-x 36 0 2010-10-04 16:19 builds drwxrwxr-x 17 0 2010-10-04 15:23 releases ah...@ahall-pc /cygdrive/f $ test -w /cygdrive/f/builds ah...@ahall-pc /cygdrive/f $ echo $? 0 Now if I explicitly mount the remote samba share by putting the following in /etc/fstab //10.1.13.25/repository /repos smbfs binary,noacl 0 0 Mount produces ah...@ahall-pc /cygdrive/f $ mount //10.1.13.25/repository on /repos type smbfs (binary,noacl) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) and if I cd to /repos and do an ls, I get the following with a reasonable uid and gid. ah...@ahall-pc /repos $ ls -l total 2048 drwxr-xr-x 36 ahall None 0 2010-10-04 16:30 builds drwxr-xr-x 17 ahall None 0 2010-10-04 15:23 releases Now without the explicit mounting of the directories, mount produced $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) So the issue seems to be the difference between the use of noacl in my explicit mount and the default one chosen by Cygwin. How do I force the default one to be mounted with noacl? === I held off updating two machines from Cygwin 1.5 to 1.7 until this week because they were critical to a product test and release process. These Cygwin installations are nearly vanilla and the upgrades went very smoothly and except for one crucial item everything seems to have worked as expected. Kudos to every one who contributed to this effort! Here's what didn't work. Both machines map a Samba file system to the F: drive via the normal windows mechanisms and I can read/write files in these file system via windows. However creating or writing files in these file systems via Cygwin now fails whereas prior to the upgrade this was just fine. When I list the cygdrive directory, I get $ ls -l total 1024 drwxrwxr-x+ 1 Administrators SYSTEM 0 2010-10-02 02:08 c drwxrwxr-x 4 0 2009-10-30 08:08 f and $ ls -l -n total 1024 drwxrwxr-x+ 1544 18 0 2010-10-02 02:08 c drwxrwxr-x 4 4294967295 4294967295 0 2009-10-30 08:08 f I can't remember what user / groups used to appear, but the fact that I get the 4294967295 is clearly related to the problem. Mount shows $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) which seems perfectly normal. The Samba version on the remote machine (Linux) is 3.0.10-1.4E.9. Some time ago, I remember seeing e-mail in the cygwin mailing list reporting similar issues, but I don't remember the resolution and searching has not produced one. I ran the /bin/copy-user-registry-fstab script as a precaution, but this understandably didn't do anything because I never had any mount points to begin with. I don't particularly want to ask the sys admins to upgrade Samba and am looking for a workaround. Any help would be appreciated. Andy Hall -- 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: cppcheck-1.45-1
Version 1.45-1 of cppcheck has been uploaded, following the upstream release. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler don't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes various compiler extensions, inline assembly code, etc. For a list of changes see: https://sourceforge.net/news/?group_id=195752id=292425 *** 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
[ANNOUNCEMENT] Updated: python-gdata-2.0.12-1
Version 2.0.12-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
[ANNOUNCEMENT] Updated: {aprutil1,libaprutil1,libaprutil1-devel}-1.3.10-1
A new version the Apache Portable Runtime utilities library is now available for download. This release fixes security issue CVE-2010-1623. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka 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. 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. -- David Rothenberger daver...@acm.org -- 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: cppcheck-1.45-1
Version 1.45-1 of cppcheck has been uploaded, following the upstream release. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler don't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes various compiler extensions, inline assembly code, etc. For a list of changes see: https://sourceforge.net/news/?group_id=195752id=292425 *** 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
Updated: python-gdata-2.0.12-1
Version 2.0.12-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
Updated: {aprutil1,libaprutil1,libaprutil1-devel}-1.3.10-1
A new version the Apache Portable Runtime utilities library is now available for download. This release fixes security issue CVE-2010-1623. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka 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. 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. -- David Rothenberger daver...@acm.org
