Re: mintty project
Personally I feel that a platform like sourceforge provides a more professional project environment which would provide more confidence in stable project development. What do you think? Sourceforge is awful. It's incredibly unreliable, on a project I contribute to where we deal with dozens of commits and pull requests every day, we've had to put in workarounds and caching servers into our continuous integration system specifically for Sourceforge-hosted dependencies because it goes down so often. Open-source mindshare is entirely on GitHub today. Even Microsoft is aware of this and adapting to the times. Opening up mintty's development so it's literally a click of a button to suggest a patch is a good thing, especially since it looks like that GitHub fork was done well, including migrating all the open issues over. We should put in some unit tests too, and set up a hosted continuous integration service like AppVeyor to build and run the tests on every commit and suggested pull request. -Tony -- 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: From Microsoft: Windows 10 Console and Cygwin
On May 31 11:51, Ismail Donmez wrote: > Rich Eizenhoefer wrote > > I've created a backlog item for this request so we can track the ask. It's > > possible, but would probably need to pick your brain in-depth more about > > the ask in the future. In the meantime, is it okay if I attach a copy of > > this email thread to the internal tracking item in our database? If not, > > I'll just keep the summary that I've already added. > > I wonder if there is any news on this? Since Windows 10 RTM is approaching > it would be nice to have some update about this. I'd sent my OK to attach the thread to Rich in PM during my vacation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAXG7bldA_Y.pgp Description: PGP signature
Re: mintty project
On May 31 23:15, Thomas Wolff wrote: > As a contributor to mintty, some sent me a notice discussing the move to > github > (http://www.reddit.com/r/cygwin/comments/37vgwi/what_happened_to_minttys_maintainer_andy_kopp/) > and now there is already a github fork of mintty > (https://github.com/nowox/mintty/tree/master/src). > I'd like to discuss what you (cygwin maintainers and others) think of this > move, whether it's good for mintty to be hosted on github. Personally I feel > that a platform like sourceforge provides a more professional project > environment which would provide more confidence in stable project > development. > What do you think? It's not so much the hosting service providing the upstream repository which concerns me, it's the lack of development, the lack of a responsive maintainer, and the lack of a new, stable mintty package. You're in for one of the newly created pink plush hippos if you're going to take over mintty maintainership ;) Having said that, github is ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqVGh80rNVc.pgp Description: PGP signature
Re: Group 544 no longer shows in output of /usr/bin/id when a shell is run as administrator
On May 31 22:07, GrahamC wrote:
> It used to be possible to test for the presence of 544 in the bash array
> GROUPS or the output of the /usr/bin/id program to determine when running as
> administrator.
>
> Since updating to the latest version this no longer works.
>
> E.g. while running as administrator:
>
>
> $ echo ${GROUPS[@]}
> 197121 114 197610 0 559 545 4 66049 11 15 113 4095 66048 262154 405504
>
>
> $ /usr/bin/id
> uid=1001(xxx) gid=197121(None) groups=197121(None),114(Local account
> and member of Administrators
> group),197610(HomeUsers),0(root),559(Performance Log
^^^
This is the problem.
Please remove the /etc/group file, or at least remove the entry for root.
If you missed the changes in Cygwin in terms of account handling, which
were developed and tested by the community during almost all of 2014,
see https://cygwin.com/cygwin-ug-net/ntsec.html
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpM9vpiHJvsb.pgp
Description: PGP signature
[ANNOUNCEMENT] Updated: gawk-4.1.3-1
I've updated the gawk package to 4.1.3-1. This is a new upstream release. Changes from 4.1.2 to 4.1.3 --- 1. Regexp parsing with extra brackets should now be working again. There are several new tests to keep this stuff on track. 2. Updated to latest config.guess and config.sub. 3. A (small) number of bugs have been fixed. See the ChangeLog. Changes from 4.1.1 to 4.1.2 --- 1. The manual has been considerably improved. - Thoroughly reviewed and updated. - Out-of-date examples replaced. - Chapter 15 on MPFR reworked. - Summary sections added to all chapters. - Exercises added in several chapters. - Heavily proof-read and copyedited. 2. The debugger's "restart" command now works again. 3. Redirected getline is now allowed inside BEGINFILE/ENDFILE. 4. A number of bugs have been fixed in the MPFR code. 5. Indirect function calls now work for both built-in and extension functions. 6. Built-in functions are now included in FUNCTAB. 7. POSIX and historical practice require the exclusive use of the English alphabet in identifiers. In non-English locales, it was accidentally possible to use "letters" beside those of the English alphabet. This has been fixed. (isalpha and isalnum are NOT our friends.) If you feel that you must have this misfeature, use `configure --help' to see what option to use when configuring gawk to reenable it. 8. The "where" command has been added to the debugger as an alias for "backtrace". This will make life easier for long-time GDB users. 9. Gawk no longer explicitly checks the current directory after doing a path search of AWKPATH. The default value continues to have "." at the front, so most people should not be affected. If you have your own AWKPATH setting, be sure to put "." in it somewhere. The documentation has been updated and clarified. 10. Infrastructure upgrades: Automake 1.15, Gettext 0.19.4, Libtool 2.4.6, Bison 3.0.4. 11. If a user-defined function has a parameter with the same name as another user-defined function, it is no longer possible to call the second function from inside the first. 12. POSIX requires that the names of function parameters not be the same as any of the special built-in variables and also not conflict with the names of any functions. Gawk has checked for the former since 3.1.7. With --posix, it now also checks for the latter. 13. The test suite should check for necessary locales and skip the tests where it matters if support isn't what it should be. 14. Gawk now expects to be compiled on a system with multibyte character support. Systems without such support, at least at the C language level, are so obsolete as to not be worth supporting anymore. 15. A number of bugs have been fixed. See the ChangeLog. To update your installation, click on the "Install Cygwin" link on the http://cygwin.com web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developercygwin AT cygwin DOT com Red Hat, Inc. -- 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: mintty project
2015-06-01 10:36 GMT+02:00 Corinna Vinschen: > On May 31 23:15, Thomas Wolff wrote: >> As a contributor to mintty, some sent me a notice discussing the move to >> github >> (http://www.reddit.com/r/cygwin/comments/37vgwi/what_happened_to_minttys_maintainer_andy_kopp/) >> and now there is already a github fork of mintty >> (https://github.com/nowox/mintty/tree/master/src). I see that "nowox" only imported the repo from Google Code very recently, most likely by simply pressing the "Export to GitHub" button on Google Code. And didn't make much "real changes" to his repo so far. >> I'd like to discuss what you (cygwin maintainers and others) think of this >> move, whether it's good for mintty to be hosted on github. Personally I feel >> that a platform like sourceforge provides a more professional project >> environment which would provide more confidence in stable project >> development. >> What do you think? I agree with Tony. Although I am still using the SF alias as one of my email addresses I think at this moment GitHub has the most active community. If you want to have a greater change on others contributing I would really go for GitHub. Seen it happen so many times already, move a project to GH and the PRs start coming. > It's not so much the hosting service providing the upstream repository > which concerns me, it's the lack of development, the lack of a responsive > maintainer, and the lack of a new, stable mintty package. You're in for > one of the newly created pink plush hippos if you're going to take over > mintty maintainership ;) > > Having said that, github is ok. Would it be useful for cygwin to have its own place on GitHub? This could be the place to host the mintty sources and maybe other things as well. There is a user named "cygwin" on github, but it appear very inactive. https://github.com/cygwin GitHub has a policy for that: https://help.github.com/articles/name-squatting-policy/ So if interested, maybe Corinna or Yaakov (being our project leaders) could ask GitHub to hand that account to them. And after that turn it into an organization where projects like this can be hosted. This way the project doesn't depend on one person to have full access when needed to these kind of repos. Just an idea. Regards, Frank -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problem with Windows 8.1 on-screen keyboard (tablet) and Alt-Gr-Keys in mintty
On a tablet running Windows 8.1pro I installed Cygwin 2.0.0 /64. Unfortunately I have issues using the on-screen (virtual) keyboard with Alt-Gr keys from within mintty. Example: In Germany to get to the "@" character you have to press [Alt-Gr][q]. This, however, doesn't work in mintty using the on-screen keyboard. Instead of @ it produces the sequence [ESC][CTL-Q]. When I start bash from a Windows CMD terminal the "@" using [Alt-Gr][q] works nicely. It also works when I use a real keyboad connected through USB. The problem only exists when using a mintty window and the on-screen keyboard. Does anybody have any advice? Regards Richard 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: cygwin on W7: stalled scp (openssh-6.8p1), lost ssh-scp-pipe data
Hi folks,
unfortunately, my issue seems to be not interesting enough to trigger someones
attention... ;)
Was my issue well described or do you have further questions? I'd appreciate
any help leading me forward, e.g. maybe some hints in howto instrument cygwin
sources to be able to further trace the data through and debug into the cygwins
write / read functions...
Thanks,
Theo
-Ursprüngliche Nachricht-
Gesendet: Freitag, 22 Mai 2015 um 09:52:20 Uhr
Von: theodor.kaz...@gmx.de
An: cygwin@cygwin.com
Betreff: cygwin on W7: stalled scp (openssh-6.8p1), lost ssh-scp-pipe data
Hi ML-followers,
I occasionally observe stalled scp connections while copying logfile archives
from a debian server to cygwin on Windows 7. Besides
https://sourceware.org/ml/cygwin/2015-02/msg00575.html I did not find similar
issues, but there is no blocking/non-blocking switch involved in the middle of
the data transmission (at random places in subsequent tests) through the pipe,
where some data is lost (pls see below).
Pls find the redacted output of my "cygcheck -svr" attached. I also noticed
that issue also before upgrading my cygwin to that latest version.
As I'm not into the details of read/write functions, I was only able to track
down the issue as follows - I hope it is reproducible or otherwise helpful - so
now I need your help:
1) I added some instrumentation in scp/ssh (both binaries copied to
/usr/local/bin/ and used below):
user@host /usr/src/openssh-6.8p1-1.src/openssh-6.8p1-debug
$ grep -n -C4 TK: *.c
channels.c-1724-
channels.c-1725-if (c->datagram) {
channels.c-1726-/* ignore truncated writes, datagrams
might get lost */
channels.c-1727-len = write(c->wfd, buf, dlen);
channels.c:1728:logit("TK: channels.c: channel_handle_wfd(1): write: len=%d,
buf=%.16s", len, buf);
channels.c-1729-free(data);
channels.c-1730-if (len < 0 && (errno == EINTR || errno
== EAGAIN ||
channels.c-1731-errno == EWOULDBLOCK))
channels.c-1732-return 1;
--
channels.c-1745-dlen = MIN(dlen, 8*1024);
channels.c-1746-#endif
channels.c-1747-
channels.c-1748-len = write(c->wfd, buf, dlen);
channels.c:1749:logit("TK: channels.c: channel_handle_wfd(2): write: len=%d,
buf=%.16s", len, buf);
channels.c-1750-if (len < 0 &&
channels.c-1751-(errno == EINTR || errno == EAGAIN || errno
== EWOULDBLOCK))
channels.c-1752-return 1;
channels.c-1753-if (len <= 0) {
--
channels.c-2368-return 0;
channels.c-2369-
channels.c-2370-/* Get the data. */
channels.c-2371-data = packet_get_string_ptr(&data_len);
channels.c:2372:logit("TK: channels.c: channel_input_data: data_len=%d,
buf=%.16s", data_len, data);
channels.c-2373-win_len = data_len;
channels.c-2374-if (c->datagram)
channels.c-2375-win_len += 4; /* string length header */
channels.c-2376-
--
dispatch.c-107- return r;
dispatch.c-108- if (type == SSH_MSG_NONE)
dispatch.c-109- return 0;
dispatch.c-110- }
dispatch.c:111:logit("TK: dispatch.c: ssh_dispatch_run: type=%d", type);
dispatch.c-112- if (type > 0 && type < DISPATCH_MAX &&
dispatch.c-113- ssh->dispatch[type] != NULL) {
dispatch.c-114- if (ssh->dispatch_skip_packets) {
dispatch.c-115- debug2("skipped packet (type %u)",
type);
--
scp.c-1110- count += amt;
scp.c-- do {
scp.c-1112- j = atomicio6(read, remin, cp, amt,
scp.c-1113- scpio, &statbytes);
scp.c:1114:logit("TK: scp.c: sink: amt=%d, j=%d, i=%d, size=%d, count=%d,
buf=%.16s", amt, j, i, size, count, cp);
scp.c-1115- if (j == 0) {
scp.c-1116- run_err("%s", j != EPIPE ?
scp.c-1117- strerror(errno) :
scp.c-1118- "dropped connection");
2) Generated easily debuggable (numbered 16k ascii blocks) HUGEFILE on a debian
server (file size taken from an original log archive):
$ for BLOCK in `seq -w 1 1 94795`; do for ELEM in `seq -w 1 1 1024`; do echo -n
"B0$BLOCK-N00$ELEM-"; done; done > TEST.txt
3) Pulled that file in a loop from the debian server to the local cygwin on
Windows 7:
$ while true; do /usr/local/bin/scp -v -C -o BatchMode=yes
user@10.IP2.IP3.IP4:logDownload_m/TEST.txt 93_KO_TEST.txt 2>&1 | tee
93_KO_scp_trace.txt; echo; date; echo; sleep 15; done
4) In case of stalled scp (in my env, it does not take that much time to get
it, maybe 10-to-30 tries), collect and compare the "KO" output to a previously
recorded and prepared "OK" output:
$ spl
How to collaborate as maintainer
Hello. I am not sure is this is the correct destination address for this message. Anyway I would like to know if exist any package on Cygwin needed of a maintainer by now or even others needed of some kind of collaboration in a similar basis. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- Sergio Pedraja -- mobile: +34-699-996568 twitter: @sergio_pedraja | skype: Sergio Pedraja - No crea todo lo que ve, ni crea que está viéndolo todo -- 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 collaborate as maintainer
On 6/1/2015 5:08 PM, SPC wrote: Hello. I am not sure is this is the correct destination address for this message. Anyway I would like to know if exist any package on Cygwin needed of a maintainer by now or even others needed of some kind of collaboration in a similar basis. Dear Sergio, The list of all packages including orphaned is here: https://cygwin.com/cygwin-pkg-maint most of the orphans are probably not worth as they are also dead upstream, but some still alive need a maintainer. Please looks at general info here https://cygwin.com/setup.html and at the dedicated mailing list https://cygwin.com/ml/cygwin-apps/ 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
man segmentation fault
Hi, I just discovered recently that `man *` where * is anything results in a segmentation fault. The stackdump is: Exception: STATUS_ACCESS_VIOLATION at rip=0018017855D rax=766972646779632F rbx=000100418290 rcx=000600049E30 rdx= rsi=000100418280 rdi=000100418288 r8 = r9 = r10=0024 r11=00010040A1BA r12=000600049E30 r13= r14= r15=0023CA60 rbp= rsp=0023C938 program=C:\cygwin64\bin\man.exe, pid 8116, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 000 0018017855D (00600046FC0, 006000465C0, 001800C52B3, 000) 000 0010040A1C8 (00600047090, 0010048, 0010008, 00100418174) 00100411AD3 0010040E195 (023CB70, 3000101FF00, 001800484E0, 000) 023CBD0 00180048551 (000, 000, 000, 000) 000 001800463EC (000, 000, 000, 000) 000 00180046494 (000, 000, 000, 000) 000 0010040D4D1 (000, 000, 000, 000) 000 00100401010 (000, 000, 000, 00100401000) 000 7FFD575B13D2 (000, 000, 000, 000) 000 7FFD57705444 (000, 000, 000, 000) End of stack trace Everything else seems to work, and I have no idea when this error started occuring, because I've been using Cygwin and updating to the latest when possible. Current cygwin version 2.871. Thanks, Roger -- Founder of Matrix AI http://matrix.ai/ +61420925975 -- 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: mintty project
On Jun 1 16:16, Frank Fesevur wrote: > 2015-06-01 10:36 GMT+02:00 Corinna Vinschen: > > It's not so much the hosting service providing the upstream repository > > which concerns me, it's the lack of development, the lack of a responsive > > maintainer, and the lack of a new, stable mintty package. You're in for > > one of the newly created pink plush hippos if you're going to take over > > mintty maintainership ;) > > > > Having said that, github is ok. > > Would it be useful for cygwin to have its own place on GitHub? This > could be the place to host the mintty sources and maybe other things > as well. > > There is a user named "cygwin" on github, but it appear very inactive. > https://github.com/cygwin > GitHub has a policy for that: > https://help.github.com/articles/name-squatting-policy/ > > So if interested, maybe Corinna or Yaakov (being our project leaders) > could ask GitHub to hand that account to them. And after that turn it > into an organization where projects like this can be hosted. This way > the project doesn't depend on one person to have full access when > needed to these kind of repos. > Just an idea. We could also put mintty under the cygwin-apps cover on sourceware. We just need to fetch a git repo or import the original svn repo. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0qteJir4Jw.pgp Description: PGP signature
Re: mintty project
Thomas Wolff writes: > I'd like to discuss what you (cygwin maintainers and others) think of > this move, whether it's good for mintty to be hosted on > github. The first thing should really be to find out what Andy Koppe thinks about this, or is there any information about his whereabouts that says he's abandoned his project (other than the long silence)? And that question of yours is moot since mintty already is on GitHub, in 26 different forks. Most of them are "Automatically exported from Google Code." and some not even fully up-to-date. Then closest to Cygwin is the one from cygwinports (Yaakov). Two of them simply dropped the history and only three of them have non-trivial commits. > Personally I feel that a platform like sourceforge provides a > more professional project environment which would provide more > confidence in stable project development. > What do you think? Sourceforge has been deteriorating for at least the last two years and personally I don't like the lock-in that GitHub tries to sneak upon its users. I certainly won't register with GitHub just for reporting an issue in one of their projects. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: vim causes bash to die
Thanks for looking into this Larry. You have to run vim several times in the same terminal for the fault to occur. I launch bash from a desktop shortcut, and it appears to be using the conhost process. My bash terminal is configured with white background and black text, and vim is configured with a light background. I've been using cygwin since it first came out, and I've always launched bash and vim this way, and never seen this problem before. In fact I have another Windows 7 computer with an older version of cygwin that works fine. So it seems that a bug has been introduced along the line. I'm wondering if it has something to to with the ongoing terminal issues I've seen discussed in the mailing list. I would like to submit a detailed problem report. How is this done? Thanks again, John -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Larry Hall (Cygwin) Sent: Sunday, May 31, 2015 6:51 PM To: cygwin@cygwin.com Subject: Re: Cygwin: vim causes bash to die On 05/31/2015 02:32 PM, John Marsh wrote: > > Issue: vim causes bash to die > > Windows Event Viewer (Application Error) > > Faulting application name: conhost.exe, version: 6.1.7601.18839, time stamp: > 0x553e7baa > Faulting module name: conhost.exe, version: 6.1.7601.18839, time stamp: > 0x553e7baa > Exception code: 0xc005 > Fault offset: 0x000234df > Faulting process id: 0x2254 > Faulting application start time: 0x01d09bc9f5b48b51 Faulting > application path: C:\Windows\system32\conhost.exe Faulting module > path: C:\Windows\system32\conhost.exe Report Id: > 50014a1e-07be-11e5-b4f2-fc1aad7fabda > > Is there a fix for this? Sorry, I can't reproduce this from a bash started in cmd.exe or mintty.exe. Based on the Windows Event Viewer information above, it's actually the Windows console (conhost) that's crashing. Perhaps it would better for you if you ran it from mintty? If you want to submit a complete problem report that describes the steps to reproduce the problem, that may throw some light on the problem. With the exception of me running on Windows 8 and you Windows 7, I don't see a significant difference in configuration. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty project
On Jun 1 18:14, Achim Gratz wrote: > Thomas Wolff writes: > > I'd like to discuss what you (cygwin maintainers and others) think of > > this move, whether it's good for mintty to be hosted on > > github. > > The first thing should really be to find out what Andy Koppe thinks > about this, or is there any information about his whereabouts that says > he's abandoned his project (other than the long silence)? Well, I don't know what Andy really wants. I pinged him May 2015 and he replied a couple of days later. Life was taking a toll, so he was not actively working on mintty anymore. He told me he'd have a look into providing a new mintty version. I pinged him twice since then, once in October 2014, once in January 2015. I'm willing to ping Andy again (done with this mail), but if he doesn't reply we should really go forward I think, even if it's unfortunate, Andy being a nice guy. > And that question of yours is moot since mintty already is on GitHub, in > 26 different forks. Most of them are "Automatically exported from > Google Code." and some not even fully up-to-date. Then closest to > Cygwin is the one from cygwinports (Yaakov). That should probably be the version going ahead with... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXxYU31ZFre.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: tcsh-6.19.00-1
I've updated the tcsh package to 6.19.00-1. This is an upstream version update. The Cygwin version is build from the vanilla upstream 6.19.00 sources as release on 2015-05-21. Peace, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.17.1-4 xorg-server documentation update
On 23/05/2015 22:14, Matthew Horwood wrote: I have been trying to connect to a raspberry PI over XDMCP, but have been having issues getting it to work. After looking at both the cygwin/X and raspberry PI sites, I did a search for 'lightdm connecting to xserver windows' and found a post that suggested using VcXsrv. As it uses an option of -from that seems to work, so I have tried it with cygwin/X and also got connected. It would seem your User's Guide needs to be updated, it needs to include the -from option when making XDMCP connections. http://unix.stackexchange.com/questions/26000/how-to-cygwin-xwin-query-an-ubuntu-11-10-xserver Hi, Thanks for pointing this out. I have added a mention of that option to the XDMCP section of the UG. But it should not be the case that the option is always required. It should only be needed when the host has multiple network interfaces and the right one isn't selected, for whatever reason. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: mintty project
On 06/01/2015 10:14 AM, Achim Gratz wrote: > Thomas Wolff writes: >> I'd like to discuss what you (cygwin maintainers and others) think of >> this move, whether it's good for mintty to be hosted on >> github. > > The first thing should really be to find out what Andy Koppe thinks > about this, or is there any information about his whereabouts that says > he's abandoned his project (other than the long silence)? > > And that question of yours is moot since mintty already is on GitHub, in > 26 different forks. Most of them are "Automatically exported from > Google Code." and some not even fully up-to-date. Then closest to > Cygwin is the one from cygwinports (Yaakov). Two of them simply dropped > the history and only three of them have non-trivial commits. > >> Personally I feel that a platform like sourceforge provides a >> more professional project environment which would provide more >> confidence in stable project development. >> What do you think? > > Sourceforge has been deteriorating for at least the last two years and > personally I don't like the lock-in that GitHub tries to sneak upon its > users. I certainly won't register with GitHub just for reporting an > issue in one of their projects. I personally avoid github; it encourages the use of proprietary code (the bug tracker and pull requests are not based on free software); while it can be used for a free software project (by hosting bug reports elsewhere, and using a mailing list rather than pull requests for merging in patches), it is never my go-to solution for an upstream project hosting site. I'm fine with github serving as a mirror to make downstream forking easier and to increase mindshare among developers that aren't as picky about free software, but I'd much rather use an upstream site that does not encourage the use of proprietary software. See for example how libvirt is using github merely as a read-only mirror: https://github.com/libvirt/libvirt -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: mingw64-* regression: LTO builds fail
JonY wrote: On 5/9/2015 05:57, Christian Franke wrote: After upgrading to recent mingw64 toolchain, builds with link time optimizer fail during linking. Can you try with the upstream binutils git version? It is most likely a new regression. Sorry for the delay. Same result with a build from upstream binutils git version bd16da5: $ i686-w64-mingw32-ld --version GNU ld (GNU Binutils) 2.25.51.20150601 $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.9.2 $ i686-w64-mingw32-gcc -flto true.c /tmp/ccA4vxFb.ltrans0.ltrans.o:ccA4vxFb.ltrans0.o:(.text+0x0): multiple definition of `main' /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):/usr/src/debug/mingw64-i686-runtime-4.0.2-1/crt/crt0_c.c:17: first defined here /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o): In function `main': /usr/src/debug/mingw64-i686-runtime-4.0.2-1/crt/crt0_c.c:18: undefined reference to `WinMain@16' collect2: error: ld returned 1 exit status Downgrading to "prev" package fixes this. $ i686-w64-mingw32-ld --version GNU ld (GNU Binutils) 2.24.51.20140411 Christian -- 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: File permissions different inside and outside cygwin root
Duane Ellis sent the following at Sunday, May 24, 2015 11:03 AM >(Sorry I cannot reply directly to the previous email I just subscribed >to the list, I am quoting from the list archive) >>> (from the archive - permissions inside and outside of /cygwin get messed up) > >I think this is *THE* cause of my problems. > >My question is how do I turn this of 100% totally - and completely? > >How it is effecting me: > >In my case, I *OFTEN* edit source code using 'emacs-w32' under cygwin. > >and often refer to files via a filename like this >/cygdrive/c/some/path/foo.c > >Sadly what happens in the end is, the ACL gets set to the point where I >cannot edit source files. > >Another common example is this: > >Step 1: On Linux - create a "tar.gz" of a source directory. > tar cfz foo.tar.gz somedirectory > >(In my case, it is an open source package that *must* build under both >cygwin and linux) I need to move the code back and forth - to make sure >my changes don't break things > >Step 2: Pull that tar file over to Cygwin (I use cygwin64) > >Step 3: Unpack the tar.gz file using CYGWIN > tar xfz foo.bar.tz > > I specifically use "emacs-w32" - to edit the source code. > It seems that *randomly* the ACL gets totally bunkered > >Step 4: > Maybe there is a method to this madness, but I can't figure out the > exact sequence > >I am *NOT* building or doing this under any Cygwin mount I should not >need to, and I should not be required to > >I specifically use: /cygdrive/c/some/path/ > >**NOTE** > This does not *require* the 'tar-copy' method > Using CYGWIN - I "git clone" some repository and edit the files in the > standard way > It seems to be more predominant when I copy via TAR across systems. > > I can no longer edit my source code. > I would end up having to "right click" permissions and fix things using > windows tools > >Result: > It seems the ACLs are totally messed up > >Bottom line, my expected behavior > I should be able to use a simple editor - i.e.: Emacs-w32 > I should be able to edit a source code file > When I save the source code file - the permissions *before* and *after* > should be identical > > They are not, permissions are totally messed up. > > Whatever I am seeing, it is fundamentally broken. The following is totally a guess. You try it at your own risk. It is possible that the solution is in windows, not cygwin. Windows can have security settings that propagate down a directory tree. And when Windows and Cygwin argue, Windows wins. - Go into Windows Explorer for C:\some or C:\some\path. (I advise NOT trying this on C:\. If you do and it results in disaster, it is on your head.) - Right click and select "Properties". - Go to the "Security" tab. - "Advanced". - Select the account under which you use cygwin. - "Change permissions". - You might need to experiment on whether to check or uncheck "Include inheritable permissions from this object's parent". - Check "Replace all child permissions with inheritable permissions from this object". - Select the account under which you use cygwin. - "Edit". - "Full control". - "OK", etc. Or something like that. Again, you play with the Security tab at your own risk. Good luck, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: cygwin on W7: stalled scp (openssh-6.8p1), lost ssh-scp-pipe data
On Jun 1 17:03, theodor.kaz...@gmx.de wrote: > Hi folks, > > unfortunately, my issue seems to be not interesting enough to trigger > someones attention... ;) > > Was my issue well described or do you have further questions? I'd > appreciate any help leading me forward, e.g. maybe some hints in howto > instrument cygwin sources to be able to further trace the data through > and debug into the cygwins write / read functions... I have no good idea how to debug this further, other than running under strace (which takes a lot of patience), but I tried to do the same with the stock scp 6.8 on Cygwin 2.0.2 x86_, basically a loop: while true do scp -C my_linux_box:TEST.txt . && diff TEST.orig TEST.txt || break done The TEST.orig/TEST.txt file was generated as described in your OP. The loop is running now for a couple of hours without fail. Any chance this is BLODA-induced? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbXGa15gSba.pgp Description: PGP signature
Re: cygwin on W7: stalled scp (openssh-6.8p1), lost ssh-scp-pipe data
On Jun 1 20:53, Corinna Vinschen wrote: > On Jun 1 17:03, theodor.kaz...@gmx.de wrote: > > Hi folks, > > > > unfortunately, my issue seems to be not interesting enough to trigger > > someones attention... ;) > > > > Was my issue well described or do you have further questions? I'd > > appreciate any help leading me forward, e.g. maybe some hints in howto > > instrument cygwin sources to be able to further trace the data through > > and debug into the cygwins write / read functions... > > I have no good idea how to debug this further, other than running under > strace (which takes a lot of patience), but I tried to do the same with > the stock scp 6.8 on Cygwin 2.0.2 x86_, basically a loop: ^^^ 64 > while true > do > scp -C my_linux_box:TEST.txt . && diff TEST.orig TEST.txt || break > done > > The TEST.orig/TEST.txt file was generated as described in your OP. The > loop is running now for a couple of hours without fail. > > Any chance this is BLODA-induced? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpZp96MbuoZG.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: setup.exe (Release 2.871)
On May 31, 2015, at 4:24 AM, Corinna Vinschen wrote: > > On May 29 17:49, Steven Penny wrote: >> On Fri, May 29, 2015 at 8:51 AM, Corinna Vinschen wrote: >>> - Improved performance in terms of SHA512 checksum computation. >> >> Thanks for this, but how was it done? > > It was embarrassingly simple: That reminds me of a case I ran into a few months ago. I have some UDP stream reception code that works perfectly on Linux. Someone wanted it on Windows, too, so I ported it in an afternoon, a relatively easy task since Winsock is mostly a superset of BSD sockets, and there wasn’t much to the app besides Standard C++ and sockets code. It worked fine on my machine, so I shipped it off, confident that it would work just as well as the Linux version. Then I start getting field reports about dropped packets whenever the machine wasn’t perfectly idle while running the app. This is not a high data rate application. With the 8 kiB buffers I was using — a perfectly sensible size for UDP — it would take about 3 ms to overflow a buffer. That’s approximately forever in CPU time, so I felt it was more than adequate, even considering multitasking overheads. In the end, I had to increase the UDP stack buffers for the Windows port to 64 kiB to get it to work reliably on Windows, which effectively increased the buffer time to ~23 ms. That means the time-slice delay was somewhere between 3 and 22 ms! That’s on the scale of HDD head seek times, one of the slowest things a computer does! -- 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: From Microsoft: Windows 10 Console and Cygwin
This feature requires multiple moving parts from other teams at Microsoft and we have not started on it yet. We have begun planning for the first post-Windows 10 release, and within our team we have talked about how to create hidden consoles and make the console driver/API better all around. I don't have a timeframe yet when we might get to this but it has been part of our presentation to management about the backlog items we prioritized. Overall there are almost 280 items on the backlog and this is in the "elite 25" that are being considered. Thanks, Rich -Original Message- From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Sent: Monday, June 1, 2015 1:25 AM To: cygwin@cygwin.com Cc: Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin On May 31 11:51, Ismail Donmez wrote: > Rich Eizenhoefer wrote > > I've created a backlog item for this request so we can track the > > ask. It's possible, but would probably need to pick your brain > > in-depth more about the ask in the future. In the meantime, is it > > okay if I attach a copy of this email thread to the internal > > tracking item in our database? If not, I'll just keep the summary that I've > > already added. > > I wonder if there is any news on this? Since Windows 10 RTM is > approaching it would be nice to have some update about this. I'd sent my OK to attach the thread to Rich in PM during my vacation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: man segmentation fault
On 6/1/2015 5:39 PM, Roger Qiu wrote: Hi, I just discovered recently that `man *` where * is anything results in a segmentation fault. The stackdump is: As no one else is complaining about it, must be a local issue of your machine Everything else seems to work, and I have no idea when this error started occuring, because I've been using Cygwin and updating to the latest when possible. Current cygwin version 2.871. this is the setup version. Thanks, Roger please follow guideline at http://cygwin.com/problems.html so we can understand the status of your system -- 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: man segmentation fault
On Jun 1, 2015, at 9:39 AM, Roger Qiu wrote: > > I just discovered recently that `man *` where * is anything results in a > segmentation fault. What does “echo man *” say? -- 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: man segmentation fault
On Jun 1, 2015, at 9:39 AM, Roger Qiu wrote: > > I just discovered recently that `man *` where * is anything results in a > segmentation fault. What does “echo man *” say? -- 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: File permissions different inside and outside cygwin root
On Mon, Jun 1, 2015 at 1:38 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: > - Right click and select "Properties". > - Go to the "Security" tab. > - "Advanced". For goodness sake, do not do this. Do not break your computer because Cygwin sucks at permissions. Just read my post on noacl and live with the compromise until they fix it: http://cygwin.com/ml/cygwin/2015-05/msg00297.html Do NOT listen to Barry, you can break your computer following his advice: http://cygwin.com/ml/cygwin/2015-04/msg00103.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
[ANNOUNCEMENT] Updated: sharutils-4.15.2-1
A new release of sharutils, 4.15.2-1, has been uploaded and will soon be available at your favorite mirror. This leaves 4.15-1 as the previous build. NEWS: = This is a new upstream release. Using shar on text mounts continues to have the possibility that line endings on text files might not be handled the way you want, but if it was truly a text file, that should not matter to you; the heuristic that shar uses to decide between text and binary files is whether it contains non-printing characters. It is safer to use shar/unshar on binary mounts (remembering that unshar is inherently unsafe). uuencode and uudecode, on the other hand, work reliably regardless of the underlying mount point. See also the package documentation found in /usr/share/doc/sharutils/. DESCRIPTION: The sharutils package contains the GNU shar utilities, a set of tools for encoding and decoding packages of files (in binary or text format) in a special plain text format called shell archives (shar). This format can be sent through e-mail (which can be problematic for regular binary files). The shar utility supports a wide range of capabilities (compressing, uuencoding, splitting long files for multi-part mailings, providing checksums), which make it very flexible at creating shar files. After the files have been sent, the unshar tool scans mail messages looking for shar files. Unshar automatically strips off mail headers and introductory text and then unpacks the shar files. Note that unshar is inherently unsafe by design, because it executes arbitrary shell scripts; therefore the creation of shar archives should be limited to situations where the receiver trusts the sender. However, uuencode and uudecode are useful in their own right, and are safe to use. UPDATE: === To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'sharutils' from the 'Archive' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin sharutils package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html signature.asc Description: OpenPGP digital signature
Re: mintty project
Am 01.06.2015 um 10:36 schrieb Corinna Vinschen: On May 31 23:15, Thomas Wolff wrote: As a contributor to mintty, some sent me a notice discussing the move to github (http://www.reddit.com/r/cygwin/comments/37vgwi/what_happened_to_minttys_maintainer_andy_kopp/) and now there is already a github fork of mintty (https://github.com/nowox/mintty/tree/master/src). I'd like to discuss what you (cygwin maintainers and others) think of this move, whether it's good for mintty to be hosted on github. Personally I feel that a platform like sourceforge provides a more professional project environment which would provide more confidence in stable project development. What do you think? It's not so much the hosting service providing the upstream repository which concerns me, it's the lack of development, the lack of a responsive maintainer, and the lack of a new, stable mintty package. You're in for one of the newly created pink plush hippos if you're going to take over mintty maintainership ;) OK, I'll take the hippo ;) I just spoke to Andy and we agreed that I take the maintainership for the cygwin package for the time being. He does intend to continue to participate but isn't currently finding the time (as many others...). Having said that, github is ok. Achim Gratz wrote: ... mintty already is on GitHub, in 26 different forks. Terrible, this needs to be sorted out. Then closest to Cygwin is the one from cygwinports (Yaakov). Corinna wrote: That should probably be the version going ahead with... I'll check that out... -- Thomas --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. http://www.avast.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
