Re: New Git v2.0.4 build to test
Adam Dinwoodie wrote on 2014/8/6 18:21: Hi all, I'm in the long-running process of producing an up-to-date build of Git for Cygwin. I think I'm now (finally) close to having a build ready to upload to be installed via the Cygwin setup programs, but in the meantime I'd appreciate my new build getting some additional testing. You can download my latest build of Git v2.0.4 at http://tastycake.net/~adam/cygwin/. To install, download the package(s) you're interested in using, and unpack them using `tar -xaC/ -f ` from a Cygwin shell. Make sure to check the corresponding setup.hint files to ensure you have all the required dependencies first. This build isn't final, but it does work in at least the mainline use cases; I've been using it for a couple of days for my day-to-day work. However there are still some problems I'm aware of (no `git grep -P` support, `git fetch` occasionally hangs in the test suites in 64-bit) and there are probably some problems I haven't identified yet. I'm currently in the process of working through the Git test suite output to identify missing features, since it's the best way I've found to identify features the Git compile process has quietly skipped since a required library wasn't installed. Once that's done, and any remaining problems are ironed out (or at least identified and I've decided it's safe to ignore them), I'll hopefully be good to upload the builds for general consumption. If anyone's really interested in following my progress at home, or building for themselves based of my latest code, you can follow along at my GitHub repository at https://github.com/me-and/Cygwin-Git. Adam -- 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 Hi Adam, I tried your git with repo. RS-I9E3U8R4:[~/repo/test]> repo --version repo version r1.2.7 (from ssh://repo.realtek.com:29418/repo.git) repo launcher version 1.22 (from /cygdrive/d/cygwin/home/robert_bu/bin/repo) git version 2.0.4 Python 2.7.8 (default, Jul 25 2014, 14:04:36) [GCC 4.8.3] When I tried to initialize the repo, I got some error: From ssh://repo.xxx.com:29418/test/manifest * [new branch] master -> origin/master Traceback (most recent call last): File "/cygdrive/d/repo/test/.repo/repo/main.py", line 500, in _Main(sys.argv[1:]) File "/cygdrive/d/repo/test/.repo/repo/main.py", line 476, in _Main result = repo._Run(argv) or 0 File "/cygdrive/d/repo/test/.repo/repo/main.py", line 155, in _Run result = cmd.Execute(copts, cargs) File "/cygdrive/d/repo/test/.repo/repo/subcmds/init.py", line 390, in Execute self._SyncManifest(opt) File "/cygdrive/d/repo/test/.repo/repo/subcmds/init.py", line 239, in _SyncManifest m.Sync_LocalHalf(syncbuf) File "/cygdrive/d/repo/test/.repo/repo/project.py", line 1170, in Sync_LocalHalf self._InitWorkTree() File "/cygdrive/d/repo/test/.repo/repo/project.py", line , in _InitWorkTree copy_all=False) File "/cygdrive/d/repo/test/.repo/repo/project.py", line 2205, in _ReferenceGitDir os.symlink(os.path.relpath(src, os.path.dirname(dst)), dst) OSError: [Errno 2] No such file or directory My Cygwin environment: CYGWIN_NT-6.1 RS-I9E3U8R4 1.7.31(0.272/5/3) 2014-07-25 11:26 x86_64 Cygwin Do you have any idea? B.R. Robert -- 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: (call-process ...) hangs in emacs
Greetings, Katsumi Yamaoka! >>> % ./autogen.sh >>> [...] >>> Running 'autoreconf -fi -I m4' ... >>> 0 [main] perl 4508 child_info_fork::abort: address space needed by >>> 'POSIX.dll' (0x2D) is already occupied > [...] >> You definitely have a DLL collision. What about perlrebase? > Oh, I did never know such a help tool existence. Thanks so much! > But strangely enough, autogen.sh and perl work today without doing > anything in particular. What I did since last night was only to > shutdown and to boot the PC. Such is one of mysteries of Cygwin. That's no mystery, but looks more like BLODA. One or another DLL got loaded into different address, and everything went up in flames. -- WBR, Andrey Repin (anrdae...@yandex.ru) 07.08.2014, <04:20> 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: (call-process ...) hangs in emacs
On Wed, 06 Aug 2014 10:48:49 +0200, Corinna Vinschen wrote: > On Aug 6 11:30, Katsumi Yamaoka wrote: >> % ./autogen.sh >> [...] >> Running 'autoreconf -fi -I m4' ... >> 0 [main] perl 4508 child_info_fork::abort: address space needed by >> 'POSIX.dll' (0x2D) is already occupied [...] > You definitely have a DLL collision. What about perlrebase? Oh, I did never know such a help tool existence. Thanks so much! But strangely enough, autogen.sh and perl work today without doing anything in particular. What I did since last night was only to shutdown and to boot the PC. Such is one of mysteries of Cygwin. >> On Tue, 05 Aug 2014 13:55:31 -0400, Ken Brown wrote: >>> Angelo and Katsumi, could you test it and see if it solves the >>> problems you reported? If so, I'll issue new emacs releases. Great! Now I'm running trunk Emacs that I built with the patch. I also verified it runs with no problem for the batch jobs; I'm using newly built ELisp packages, such as Gnus, for the first time in these 7 days. Thanks a lot! -- 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: New Git v2.0.4 build to test
On Wed, Aug 06, 2014 at 04:18:41PM +0200, Corinna Vinschen wrote: > On Aug 6 11:21, Adam Dinwoodie wrote: > > This build isn't final, but it does work in at least the mainline use > > cases; I've been using it for a couple of days for my day-to-day work. > > However there are still some problems I'm aware of (no `git grep -P` > > support, > > Sounds like libpcre-devel is missing on your machine. Agreed. I've just spent a while playing whack-a-mole with problems of this ilk and thought I'd try seeing if there where any willing volunteers to do some live testing to spot problems the test suites miss before I offer my builds to the unsuspecting public. > > `git fetch` occasionally hangs in the test suites in 64-bit) > > and there are probably some problems I haven't identified yet. > > > > I'm currently in the process of working through the Git test suite > > output to identify missing features, since it's the best way I've found > > to identify features the Git compile process has quietly skipped since a > > required library wasn't installed. > > If the git build system uses autotools, you might have an easier time by > scanning the config.log file created during the configure call. It does, and doing that trawl picked up a number of missing libraries. Nonetheless looking through the tests that are being skipped due to missing dependencies is highlighting a few things like this that I managed to miss when looking at the configure output. -- 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: cannot display man page for /bin/passwd
On Aug 6 23:57, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> >> When I try to display the man page for /bin/passwd, the man page for > >> >> the openssl passwd subcommand is displayed. > >> >> > >> >> It appears that both the package containing /bin/passwd, and the > >> >> openssl package place the passwd.1.gz file in the /usr/share/man/man1 > >> >> directory, so that only the man page from the most recently installed > >> >> package is displayed. > >> > >> > No, the Cygwin passwd tool has no man page. > >> > >> That's sad. Can we change it? > > > Would you like to take over maintainance of the cygwin-doc package? > > It's orphaned and in desperate need of an active maintainer. > > That's tempting. I'll think about it. It doesn't involve deep knowledge in > the C language, I assume? (Which I'm lacking.) Not necessary. It's a documentation package :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqAVJYbaF5d.pgp Description: PGP signature
Re: Basic question about cygport (and thanks to Jon Turney)
On 4 August 2014 21:56, Yaakov Selkowitz wrote: > On 2014-08-04 14:16, Philip Daniels wrote: > > In this particular case, I would suggest just using a git snapshot of your > forked repository; see git.cygclass in the cygport manual for details. Thanks to Jon Turney I was able to fix my problem with a small makefile tweak. I'll try the GIT_URI technique as well if time allows. > > Yaakov > -- Philip Daniels. -- 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: cannot display man page for /bin/passwd
Greetings, Corinna Vinschen! >> >> When I try to display the man page for /bin/passwd, the man page for >> >> the openssl passwd subcommand is displayed. >> >> >> >> It appears that both the package containing /bin/passwd, and the >> >> openssl package place the passwd.1.gz file in the /usr/share/man/man1 >> >> directory, so that only the man page from the most recently installed >> >> package is displayed. >> >> > No, the Cygwin passwd tool has no man page. >> >> That's sad. Can we change it? > Would you like to take over maintainance of the cygwin-doc package? > It's orphaned and in desperate need of an active maintainer. That's tempting. I'll think about it. It doesn't involve deep knowledge in the C language, I assume? (Which I'm lacking.) >> Also, the paragraph "All operations affecting the current user" is missing a >> "$" sign in reference to environment variable LOGONSERVER. > No, that's deliberate at this point. If we are to think about it as actual Windows environment variable being propagated to affect Cygwin processes, it makes sense. I'll amend the man page in this regard. >> The phrase "to enter a password which" is probably missing a comma. > Hmm, not sure. The English language is pretty lazy in terms of > punctuation characters. Uhhu... >> Slightly unrelated question. I've noticed, that if a paragraph in source file >> have line break after a period, the page is rendered with two spaces between >> a period and first letter of next sentence, even though there's only one >> character (a linefeed) exists. No stray spaces, no CR's. Is this intended? > Yes, for the English language. See > http://en.wikipedia.org/wiki/History_of_sentence_spacing#French_and_English_spacing Thanks. It was looked deliberate, judging from reproducibility on a number of available systems, was just unsure, why. Should probably follow locale settings, though... And it looks weird on fixed-width terminal, especially if you are using pretty-printing font (with most of punctuation shifted to the left). Looks almost like there's 3 spaces between sentences. -- WBR, Andrey Repin (anrdae...@yandex.ru) 06.08.2014, <23:46> 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: cannot display man page for /bin/passwd
On Aug 6 21:21, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> When I try to display the man page for /bin/passwd, the man page for > >> the openssl passwd subcommand is displayed. > >> > >> It appears that both the package containing /bin/passwd, and the > >> openssl package place the passwd.1.gz file in the /usr/share/man/man1 > >> directory, so that only the man page from the most recently installed > >> package is displayed. > > > No, the Cygwin passwd tool has no man page. > > That's sad. Can we change it? Would you like to take over maintainance of the cygwin-doc package? It's orphaned and in desperate need of an active maintainer. > > The documentation is only in the User's Guide: > > https://cygwin.com/cygwin-ug-net/using-utils.html#passwd > > While reading the page, I've noticed a discrepancy in options synopsis > and further description of the tool operation. > Namely, options --minage, --maxage parameter spelled as "DAYS", while down the > text they are referred to as MINDAYS and MAXDAYS. > I suggest changing the options description to match the text, as that it'll > make more sense. Good idea, fixed in CVS. > Also, the paragraph "All operations affecting the current user" is missing a > "$" sign in reference to environment variable LOGONSERVER. No, that's deliberate at this point. > The phrase "to enter a password which" is probably missing a comma. Hmm, not sure. The English language is pretty lazy in terms of punctuation characters. > Other question is relevance of a requirement "to run cygserver as a service > under the LocalSystem account" for modern times. That's ok. The cygserver service typically runs as SYSTEM. > Slightly unrelated question. I've noticed, that if a paragraph in source file > have line break after a period, the page is rendered with two spaces between > a period and first letter of next sentence, even though there's only one > character (a linefeed) exists. No stray spaces, no CR's. Is this intended? Yes, for the English language. See http://en.wikipedia.org/wiki/History_of_sentence_spacing#French_and_English_spacing Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNrBTU5707H.pgp Description: PGP signature
Re: Cygwin terminal collapse
On 8/6/2014 3:08 AM, Warren Young wrote: On Aug 6, 2014, at 3:59 AM, Kal Sze wrote: A Software Engineer, a Hardware Engineer and a Departmental Manager were on their way to a meeting. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside. The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do? "I know," said the Departmental Manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way." "No, no," said the Hardware Engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it, and we can be on our way." "Well," said the Software Engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again.” Source: http://www.workjoke.com/programmers-jokes.html A similar one that I heard (when I was at HP, of course): An HP Hardware Engineer, Software Engineer and an HP Salesman were driving to a meeting when the car got a flat. They jumped out of the car to see what could be done. The hardware engineer says "I know what we can do - we can rotate the tires!". "No," said the software engineer, "we should call back to the office and see if anybody has had this problem before". Then the sales rep pipes up and says "Naw, we'll just call the office and order a new car!" -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cannot display man page for /bin/passwd
Greetings, Corinna Vinschen! >> When I try to display the man page for /bin/passwd, the man page for >> the openssl passwd subcommand is displayed. >> >> It appears that both the package containing /bin/passwd, and the >> openssl package place the passwd.1.gz file in the /usr/share/man/man1 >> directory, so that only the man page from the most recently installed >> package is displayed. > No, the Cygwin passwd tool has no man page. That's sad. Can we change it? > The documentation is only in the User's Guide: > https://cygwin.com/cygwin-ug-net/using-utils.html#passwd While reading the page, I've noticed a discrepancy in options synopsis and further description of the tool operation. Namely, options --minage, --maxage parameter spelled as "DAYS", while down the text they are referred to as MINDAYS and MAXDAYS. I suggest changing the options description to match the text, as that it'll make more sense. Also, the paragraph "All operations affecting the current user" is missing a "$" sign in reference to environment variable LOGONSERVER. The phrase "to enter a password which" is probably missing a comma. Other question is relevance of a requirement "to run cygserver as a service under the LocalSystem account" for modern times. Slightly unrelated question. I've noticed, that if a paragraph in source file have line break after a period, the page is rendered with two spaces between a period and first letter of next sentence, even though there's only one character (a linefeed) exists. No stray spaces, no CR's. Is this intended? The latter issue can be demonstrated with this little sample: echo -e ".TH test 1\n.SH NAME\nJust\ntwo.\nSpaces.\n" | man -l - -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.08.2014, <14:58> Sorry for my terrible english... passwd.1 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: Cygwin terminal collapse
Greetings, Nikhil Nair!
> One thing I should, perhaps, mention: I'd also been using Cygwin Ports, and
> it looks like I'd got more recent versions of some packages by adding that
> repository.
> So, any further hints would be most welcome...
Using Ports is not a problem per se, but NOT using ports AFTER you've used
them once may trigger serious issues in package consistency.
I have this little script
#!/bin/sh
ARCH=x86
if [ "$(uname -m)" = "x86_64" ]; then
ARCH=${ARCH}_64
fi
LANG=C wget -N "http://cygwin.com/setup-${ARCH}.exe";
if [ "$1" = "ports" ]; then
run ./setup-${ARCH}.exe -K http://cygwinports.org/ports.gpg
else
run ./setup-${ARCH}.exe
fi
and I always start it with "ports" option since I've used ports repo once to
bump a number of applications to a desired version.
Talking about your cause directly, seeing as simple resolutions did not quite
worked, I suggest to go the long way.
Make sure ALL the Cygwin applications are closed. That includes anything that
is possible located in your Cygwin home directory, and any applications that
may have files open from these directories.
Rename your Cygwin folder to something else. Cygwin.old or whatever.
Launch setup.exe and reinstall Cygwin anew. Pick appropriate type for your
tasks, though. While Cygwin64 is mature enough for work, it still
lacking/behind on some packages, and may not be suitable for your needs.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.08.2014, <19:55>
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: New Git v2.0.4 build to test
On 8/6/2014 22:18, Corinna Vinschen wrote: >> `git fetch` occasionally hangs in the test suites in 64-bit) >> and there are probably some problems I haven't identified yet. >> >> I'm currently in the process of working through the Git test suite >> output to identify missing features, since it's the best way I've found >> to identify features the Git compile process has quietly skipped since a >> required library wasn't installed. > > If the git build system uses autotools, you might have an easier time by > scanning the config.log file created during the configure call. > It does, I have been using git 2.x since the last 2 months. And yes, PCRE is an optional requirement. signature.asc Description: OpenPGP digital signature
Re: New Git v2.0.4 build to test
Hi Adam, On Aug 6 11:21, Adam Dinwoodie wrote: > Hi all, > > I'm in the long-running process of producing an up-to-date build of Git > for Cygwin. I think I'm now (finally) close to having a build ready to > upload to be installed via the Cygwin setup programs, but in the > meantime I'd appreciate my new build getting some additional testing. > > You can download my latest build of Git v2.0.4 at > http://tastycake.net/~adam/cygwin/. > > To install, download the package(s) you're interested in using, and > unpack them using `tar -xaC/ -f ` from a Cygwin shell. > Make sure to check the corresponding setup.hint files to ensure you have > all the required dependencies first. > > This build isn't final, but it does work in at least the mainline use > cases; I've been using it for a couple of days for my day-to-day work. > However there are still some problems I'm aware of (no `git grep -P` > support, Sounds like libpcre-devel is missing on your machine. > `git fetch` occasionally hangs in the test suites in 64-bit) > and there are probably some problems I haven't identified yet. > > I'm currently in the process of working through the Git test suite > output to identify missing features, since it's the best way I've found > to identify features the Git compile process has quietly skipped since a > required library wasn't installed. If the git build system uses autotools, you might have an easier time by scanning the config.log file created during the configure call. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaH0KOYV_sq.pgp Description: PGP signature
Re: syslog function: Bad file descriptor
On 08/06/2014 05:30 AM, D. Boland wrote: >> Without looking into the sources, I'd assume there's a closelog() >> call missing prior to the descriptor close orgy. This closelog() >> call should fix the problem. > > It is exactly as you say. I found the close() orgy and put a closelog() prior > to it. > Now it works perfectly without corrupting the aliases file (writable to > sendmail). > > I'm asking myself if this closing of 253 file descriptors is a sensible thing > to do. Maybe. There's two schools of thoughts about preventing unintended actions due to accidentally leaked fds: 1. any time a parent forks an unknown child, the parent does an orgy close() between fork() and exec() so that the child starts life clean. 2. any time a child starts from an unknown parent, the child starts with an orgy close() to ensure it starts life clean. [More recently, there is the addition of O_CLOEXEC to open() and other APIs to allow atomic FD_CLOEXEC setting, and then you can avoid the orgy close() in style 1; but that still doesn't stop style 2 paranoid children] > What would Sendmail be trying to accomplish there? It comments "Be shure we > have > enough file descriptors". And: "in 4.4BSD, the table ([of fd's]) can be huge; > impose > a reasonable limit". Bizarre. Other programs that I know do an orgy close() on startup: bash, tcsh. So it's not uncommon. But if you do it first, it MUST be first - before you open any fds that must not be accidentally closed. sendmail is indeed buggy for trying to use syslog() (which uses an fd) prior to doing the orgy close. > > Could it be that incoming e-mail is such a volatile process that previous > opened > file descriptors are not closed quick enough? This feels like a crude hack. Just because the problem hasn't tripped other platforms does not make it any less of an upstream sendmail bug. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: syslog function: Bad file descriptor
On Aug 6 13:30, D. Boland wrote: > Hi Corinna, > > Corinna Vinschen wrote: > > > > On Aug 5 22:35, D. Boland wrote: > > > Corinna Vinschen wrote: > > > > > > > > Can you produce another strace for the overwriting case (non-R/O > > > > aliases) > > > > for comparison? Also, can you do the same strace with no syslogd > > > > running? > > > > > > > > It might be necessary to create a few test versions of Cygwin with more > > > > debug output, but let's please see these straces first. > > > > > > I attached all three of them in a zipped file. > > > > Thanks. I got it now. AFAICS it's a bug in sendmail. Take a look > > into your newaliases.strace.txt file. Start at line 260 (stripping > > off timestamp, thread and process info): > > [...] > > Without looking into the sources, I'd assume there's a closelog() > > call missing prior to the descriptor close orgy. This closelog() > > call should fix the problem. > > It is exactly as you say. I found the close() orgy and put a > closelog() prior to it. Now it works perfectly without corrupting the > aliases file (writable to sendmail). Nice. > I'm asking myself if this closing of 253 file descriptors is a > sensible thing to do. What would Sendmail be trying to accomplish > there? It comments "Be shure we have enough file descriptors". And: > "in 4.4BSD, the table ([of fd's]) can be huge; impose a reasonable > limit". Bizarre. I think this is really old stuff, in the sense that this method has been used on UNIXoid systems for ages. It depends on how many open fds sendmail inherited from its parent process (once typically an rc shell script) which was questionable back in the days sendmail was young I guess, and if sendmail forks/execs, it's a way to disallow arbitrary fds inheritance by the child. > Could it be that incoming e-mail is such a volatile process that > previous opened file descriptors are not closed quick enough? This > feels like a crude hack. Sendmail is not the only one doing this. There's similar code in tcsh, for instance, but tcsh doesn't call syslog. The bug here seems to be an upstream bug which just hasn't been catched yet because syslog() works somewhat differently on other systems and hide their file descriptor usage somehow. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWPeTUzHpjY.pgp Description: PGP signature
Re: syslog function: Bad file descriptor
Hi Corinna, Corinna Vinschen wrote: > > On Aug 5 22:35, D. Boland wrote: > > Corinna Vinschen wrote: > > > > > > Can you produce another strace for the overwriting case (non-R/O aliases) > > > for comparison? Also, can you do the same strace with no syslogd running? > > > > > > It might be necessary to create a few test versions of Cygwin with more > > > debug output, but let's please see these straces first. > > > > I attached all three of them in a zipped file. > > Thanks. I got it now. AFAICS it's a bug in sendmail. Take a look > into your newaliases.strace.txt file. Start at line 260 (stripping > off timestamp, thread and process info): > > 260: normalize_posix_path: src /dev/log > > Here the syslog() function tries to open a connection to a syslogd > listening on /dev/log. > > 282: cygwin_socket: 3 = socket(1, 2 (flags 0x0), 0) > > Socket created, file descriptor is 3. > > 296: connect_syslogd: found /dev/log, fd = 3, type = DGRAM > > Yes, there's a listener on /dev/log. Now Cygwin stores the info that fd > 3 is the connection to the syslog daemon. > > 332: close: close(3) > > And at line 332, a file descriptor close orgy starts. sendmail closes > all descriptors from 3 to 255. This obviously closes fd 3, but how's > Cygwin's syslog() function to know? > > 2263: open: 3 = open(/etc/mail/aliases, 0x8000) > > Uh oh! Now fd 3 is reused for the aliases file. Things certainly go > downhill. > > 2651: writev: -1 = writev(3, 0x2287F0, 2), errno 9 > > This is syslog trying to write the log to the descriptor it knows > is connected to /dev/log. Fortunately the aliases file is R/O at > this point, but it's pretty much working as designed. Syslog() > doesn't know the application broke its connection to the syslog > daemon. It dutyfully writes to the syslog descriptor it knows > about. > > As for using a file descriptor inside of syslog, that's perfectly > valid behaviour, see > http://pubs.opengroup.org/onlinepubs/9699919799/functions/closelog.html: > > "The openlog() and syslog() functions may allocate a file descriptor." > > Without looking into the sources, I'd assume there's a closelog() > call missing prior to the descriptor close orgy. This closelog() > call should fix the problem. It is exactly as you say. I found the close() orgy and put a closelog() prior to it. Now it works perfectly without corrupting the aliases file (writable to sendmail). I'm asking myself if this closing of 253 file descriptors is a sensible thing to do. What would Sendmail be trying to accomplish there? It comments "Be shure we have enough file descriptors". And: "in 4.4BSD, the table ([of fd's]) can be huge; impose a reasonable limit". Bizarre. Could it be that incoming e-mail is such a volatile process that previous opened file descriptors are not closed quick enough? This feels like a crude hack. Can you give your opinion on this? Thanks for the quick response & the time you put into this. 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
New Git v2.0.4 build to test
Hi all, I'm in the long-running process of producing an up-to-date build of Git for Cygwin. I think I'm now (finally) close to having a build ready to upload to be installed via the Cygwin setup programs, but in the meantime I'd appreciate my new build getting some additional testing. You can download my latest build of Git v2.0.4 at http://tastycake.net/~adam/cygwin/. To install, download the package(s) you're interested in using, and unpack them using `tar -xaC/ -f ` from a Cygwin shell. Make sure to check the corresponding setup.hint files to ensure you have all the required dependencies first. This build isn't final, but it does work in at least the mainline use cases; I've been using it for a couple of days for my day-to-day work. However there are still some problems I'm aware of (no `git grep -P` support, `git fetch` occasionally hangs in the test suites in 64-bit) and there are probably some problems I haven't identified yet. I'm currently in the process of working through the Git test suite output to identify missing features, since it's the best way I've found to identify features the Git compile process has quietly skipped since a required library wasn't installed. Once that's done, and any remaining problems are ironed out (or at least identified and I've decided it's safe to ignore them), I'll hopefully be good to upload the builds for general consumption. If anyone's really interested in following my progress at home, or building for themselves based of my latest code, you can follow along at my GitHub repository at https://github.com/me-and/Cygwin-Git. Adam -- 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 terminal collapse
On 06/08/2014 11:50, Andrey Repin wrote: Greetings, Nikhil Nair! My Cygwin setup seems to have... well, imploded, for want of a better word. Warning: There are multiple cygwin1.dlls on your path Please make sure you only have one installation of Cygwin, or remove any stray elements from your path that may compromise the situation, if you absolutely need multiple installations. Andrey that is a red herring. It is referring to the same file through two different paths. the missing bash.exe is the key problem for Nikhil 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: Cygwin terminal collapse
On Aug 6, 2014, at 3:59 AM, Kal Sze wrote: > On 6 August 2014 17:55, Warren Young wrote: >> >> On Aug 6, 2014, at 3:37 AM, Nikhil Nair wrote: >> >>> >> >> The output shows that a number of key packages are incomplete, > > By the way, could that be hint of virus activity or hard disk dying? It certainly means *something* bad happened, but it’s fairly pointless to speculate what exactly happened without more information. I wouldn’t worry about it unless it recurs. A Software Engineer, a Hardware Engineer and a Departmental Manager were on their way to a meeting. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside. The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do? "I know," said the Departmental Manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way." "No, no," said the Hardware Engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it, and we can be on our way." "Well," said the Software Engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again.” Source: http://www.workjoke.com/programmers-jokes.html -- 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 terminal collapse
On 06/08/2014 11:59, Kal Sze wrote: On 6 August 2014 17:55, Warren Young wrote: On Aug 6, 2014, at 3:37 AM, Nikhil Nair wrote: The output shows that a number of key packages are incomplete, meaning that files they own no longer exist on your system. It is not that c:\cygwin is missing, but that a small but critical subset of key Cygwin files are missing. Most importantly, the bash and cygwin packages are broken. You need to reinstall these. I don’t know how your UI works, but those of us who can use mice click the version number in the Cygwin setup.exe package list until it says Reinstall. Also broken are binutils and gcc-core, which will prevent you from compiling most open-source software. You should also reinstall the openssh, pulseaudio, and texinfo packages. These might have just been dragged in as dependencies, and not be software you actually use, but there’s no sense leaving them in a broken state. -- By the way, could that be hint of virus activity or hard disk dying? possible, but also a crash can leave the hard disk in an unclean status. -- 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 terminal collapse
Greetings, Nikhil Nair! > My Cygwin setup seems to have... well, imploded, for want of a better > word. Warning: There are multiple cygwin1.dlls on your path Please make sure you only have one installation of Cygwin, or remove any stray elements from your path that may compromise the situation, if you absolutely need multiple installations. -- WBR, Andrey Repin (anrdae...@yandex.ru) 06.08.2014, <13:49> 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: Cygwin terminal collapse
On 6 August 2014 17:55, Warren Young wrote: > > On Aug 6, 2014, at 3:37 AM, Nikhil Nair wrote: > > > > > The output shows that a number of key packages are incomplete, meaning that > files they own no longer exist on your system. It is not that c:\cygwin is > missing, but that a small but critical subset of key Cygwin files are missing. > > Most importantly, the bash and cygwin packages are broken. You need to > reinstall these. I don’t know how your UI works, but those of us who can use > mice click the version number in the Cygwin setup.exe package list until it > says Reinstall. > > Also broken are binutils and gcc-core, which will prevent you from compiling > most open-source software. > > You should also reinstall the openssh, pulseaudio, and texinfo packages. > These might have just been dragged in as dependencies, and not be software > you actually use, but there’s no sense leaving them in a broken state. > -- > 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 > By the way, could that be hint of virus activity or hard disk dying? -- 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 terminal collapse
On Aug 6, 2014, at 3:37 AM, Nikhil Nair wrote: > The output shows that a number of key packages are incomplete, meaning that files they own no longer exist on your system. It is not that c:\cygwin is missing, but that a small but critical subset of key Cygwin files are missing. Most importantly, the bash and cygwin packages are broken. You need to reinstall these. I don’t know how your UI works, but those of us who can use mice click the version number in the Cygwin setup.exe package list until it says Reinstall. Also broken are binutils and gcc-core, which will prevent you from compiling most open-source software. You should also reinstall the openssh, pulseaudio, and texinfo packages. These might have just been dragged in as dependencies, and not be software you actually use, but there’s no sense leaving them in a broken state. -- 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: syslog function: Bad file descriptor
On Aug 5 22:35, D. Boland wrote: > Corinna Vinschen wrote: > > > > Can you produce another strace for the overwriting case (non-R/O aliases) > > for comparison? Also, can you do the same strace with no syslogd running? > > > > It might be necessary to create a few test versions of Cygwin with more > > debug output, but let's please see these straces first. > > I attached all three of them in a zipped file. Thanks. I got it now. AFAICS it's a bug in sendmail. Take a look into your newaliases.strace.txt file. Start at line 260 (stripping off timestamp, thread and process info): 260: normalize_posix_path: src /dev/log Here the syslog() function tries to open a connection to a syslogd listening on /dev/log. 282: cygwin_socket: 3 = socket(1, 2 (flags 0x0), 0) Socket created, file descriptor is 3. 296: connect_syslogd: found /dev/log, fd = 3, type = DGRAM Yes, there's a listener on /dev/log. Now Cygwin stores the info that fd 3 is the connection to the syslog daemon. 332: close: close(3) And at line 332, a file descriptor close orgy starts. sendmail closes all descriptors from 3 to 255. This obviously closes fd 3, but how's Cygwin's syslog() function to know? 2263: open: 3 = open(/etc/mail/aliases, 0x8000) Uh oh! Now fd 3 is reused for the aliases file. Things certainly go downhill. 2651: writev: -1 = writev(3, 0x2287F0, 2), errno 9 This is syslog trying to write the log to the descriptor it knows is connected to /dev/log. Fortunately the aliases file is R/O at this point, but it's pretty much working as designed. Syslog() doesn't know the application broke its connection to the syslog daemon. It dutyfully writes to the syslog descriptor it knows about. As for using a file descriptor inside of syslog, that's perfectly valid behaviour, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/closelog.html: "The openlog() and syslog() functions may allocate a file descriptor." Without looking into the sources, I'd assume there's a closelog() call missing prior to the descriptor close orgy. This closelog() call should fix the problem. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpr_iphwGZWw.pgp Description: PGP signature
Re: (call-process ...) hangs in emacs
On Aug 6 11:30, Katsumi Yamaoka wrote: > On Tue, 05 Aug 2014 13:55:31 -0400, Ken Brown wrote: > > Angelo and Katsumi, could you test it and see if it solves the > > problems you reported? If so, I'll issue new emacs releases. > > Thanks. But currently I cannot test it since the autogen.sh > script doesn't work as the following. I must make it work, > somehow or other... > > % ./autogen.sh > [...] > Running 'autoreconf -fi -I m4' ... > 0 [main] perl 4508 child_info_fork::abort: address space needed by > 'POSIX.dll' (0x2D) is already occupied > Can't fork, trying again in 5 seconds at /usr/bin/autoreconf-2.69 line 188. > 0 [main] perl 6264 child_info_fork::abort: address space needed by > 'POSIX.dll' (0x26) is already occupied > Can't fork, trying again in 5 seconds at > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/IO/File.pm line 188. > [...] > > rebaseall nor reinstalling of perl and some things doesn't help. > :< You definitely have a DLL collision. What about perlrebase? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpf_G6HgnVy7.pgp Description: PGP signature
Re: Simplify AD integration?
On Aug 4 21:00, Corinna Vinschen wrote: > I just uploaded a new snapshot to http://cygwin.com/snapshots/ > > This snapshot contains only a single change: It drops the prepended > plus entirely, So the builtin and well-known accounts are now called as > familiar: SYSTEM instead of +SYSTEM, Administrators instead of > +Administrators, etc. > > The documentation doesn't reflect this change yet, but I will fix that > pretty soon. > > As for other changes, I'm still not sure since we seem to have as > many different opinions as interested community members :} > > I would still like to drop the db_prefix and db_separator settings and > just stick to the setting called "auto": > > builtin accounts; "SYSTEM", "Administrators", etc. > primary domain "corinna", "yaakov", ... > > This is typically all you see on non-domain machines. On domain > maches, add this: > > other domain: "DOMAIN1+walter", "DOMAIN2+mathilda" > > (local SAM accounts are subsumed under "other domain" here). > > Would anybody have really terrible problems with this approach? > If so, what problems? So nobody would really have a problem? Wow, that's cool. I guess I'll remove the db_prefix and db_separator settings pretty soon. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvVkAaOyhRB.pgp Description: PGP signature
Re: missing extern "C" in sys/file.h
On Aug 5 23:54, Anthony Heading wrote:
> I guess this patch is right.
You guessed right. Patch applied.
Thanks,
Corinna
> --- sys/file.h.Orig 2014-08-05 23:46:27.199694300 -0400
> +++ sys/file.h 2014-08-05 23:46:55.919734500 -0400
> @@ -39,7 +39,14 @@
> #define LOCK_NB0x04/* don't block when
> locking */
> #define LOCK_UN0x08/* unlock file */
>
> +#ifdef __cplusplus
> +extern "C"
> +{
> +#endif
> extern int flock _PARAMS ((int, int));
> +#ifdef __cplusplus
> +}
> +#endif
>
> #endif
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgprQiPYsE0tz.pgp
Description: PGP signature
Re: Missing 64 bit packages
Hi all,as far as I see, I don't have found package revision of Perl 5.18.2 for Windows 64bits.Do you have an idea when it could be available on Cygwin?Regards,Stéphane -- View this message in context: http://cygwin.1069669.n5.nabble.com/re-Missing-64-bit-packages-tp110216p110272.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
