Re: Install Cygwin on mounted drive for multiple concurrent users on multiple machines?
On 19. 11. 2015 23:52, Kenneth Wolcott wrote: > Hi; > > I didn't see this in the Cygwin FAQ (perhaps I didn't look carefully > enough or perhaps it is too obvious a question). > > Instead of installing Cygwin on each Windows machine, is it > advisable to install it once on a public mounted drive? Then not only > multiple users (concurrent or not) could use Cygwin on multiple > machines (concurrently or not) from one place. Since many of the > machines I want to install Cygwin are short of disk space on the local > drive, but there seems to be sufficient space for a slightly larger > than minimal Cygwin installation on a public drive, is this advisable? > I guess I'd see a performance hit if Cygwin were not installed on a > local drive. Are there any other concerns? Potential concerns: - location of home directories (same as Windows, or in $cygwinroot/home, or somewhere else) - location of tmp (one shared in $cygwinroot/home, or per-user, or something else) - location of var, for example for apps that put pidfiles there (one shared, per-user, else) Essentially, as with any other shared app with possibly concurrent use, the program directory should ideally be read-only and any user-generated state gets written in per-user directories. I'm also suspicious of whether advanced filesystem features will work on a network path, e.g. deleting/updating files/binaries when in use. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: BSOD when running from network share
Hi Patrick, On 20/11/2015 8:43 AM, Patrick Herbst wrote: I have cygwin installed on a windows network share folder. Most everything works fine. But I get a BSOD when in bash running the following cat > /tmp/junk < Putting two EOF on the end of a file can cause an error in some filesystems. The problem might be more to do with the << Also what happens if you type in ^Z after asdf instead of EOF? -- Regards, Mike -- 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: BSOD when running from network share
On 11/19/2015 5:13 PM, Patrick Herbst wrote: > As soon as i hit enter on "EOF" I get a BSOD RDR_FILE_SYSTEM STOP: 0x0027 The full error context can be determined by turning on Full Memory Dumps and then reproducing the error. A MEMORY.DMP file will be written to the %SystemRoot%\Windows directory. You can load that file into windbg.exe aka Debugging Tools for Windows which would need to be downloaded and installed. Use the "!analyze -v" command within windbg.exe to generate the full context of the kernel exception. It will tell you which device driver is at fault and what the full stack is. > Can anyone else > 1) reproduce this? Doesn't really matter since you can. The ability to reproduce a kernel exception can be dependent on any number of environmental factors. > 2) confirm this? > 3) fix this? Only the author of the device driver that is crashing will be able to fix it. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Install Cygwin on mounted drive for multiple concurrent users on multiple machines?
Hi; I didn't see this in the Cygwin FAQ (perhaps I didn't look carefully enough or perhaps it is too obvious a question). Instead of installing Cygwin on each Windows machine, is it advisable to install it once on a public mounted drive? Then not only multiple users (concurrent or not) could use Cygwin on multiple machines (concurrently or not) from one place. Since many of the machines I want to install Cygwin are short of disk space on the local drive, but there seems to be sufficient space for a slightly larger than minimal Cygwin installation on a public drive, is this advisable? I guess I'd see a performance hit if Cygwin were not installed on a local drive. Are there any other concerns? Thanks, Ken Wolcott -- 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: BSOD when running from network share
On 11/19/2015 05:13 PM, Patrick Herbst wrote: > I have cygwin installed on a windows network share folder. Most > everything works fine. > > But I get a BSOD when in bash running the following > > cat > /tmp/junk < asdf > asdf > asdf > asdf > EOF > > As soon as i hit enter on "EOF" I get a BSOD RDR_FILE_SYSTEM STOP: 0x0027 > > Can anyone else > 1) reproduce this? > 2) confirm this? > 3) fix this? > > thanks! > FWIW, no problem here: roger@rwells-x220 ~ $ cat > /tmp/junk < asdf > asdf > asdf > asdf > EOF roger@rwells-x220 ~ $ cat /tmp/junk asdf asdf asdf asdf roger@rwells-x220 ~ $ uname -a CYGWIN_NT-10.0 rwells-x220 2.3.0(0.291/5/3) 2015-11-09 10:24 x86_64 Cygwin HTH > -- > 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 > > -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@leidos.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
BSOD when running from network share
I have cygwin installed on a windows network share folder. Most everything works fine. But I get a BSOD when in bash running the following cat > /tmp/junk
Re: Symlink targets dereferenced when winsymlinks:native
On 19. 11. 2015 20:36, Nellis, Kenneth wrote: > FWIW, my results are different: > > $ printenv CYGWIN > winsymlinks:nativestrict > $ touch XXX > $ ln -s XXX YYY > $ ln -s YYY ZZZ > $ ls -l > total 0 > -rw-r- 1 knellis Domain Users 0 Nov 19 14:28 XXX > lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 YYY -> XXX > lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 ZZZ -> YYY > $ uname -svr > CYGWIN_NT-6.1 2.3.1(0.291/5/3) 2015-11-14 12:44 > $ Weird. I also tried in the virtual root directory, in case cygdrive affects it, but no luck, still absolute paths. I'm on Windows 10, if it makes any difference. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: does anyone care about package minor version bump announcements?
Greetings, Andrew Schulman! > Lately I find myself feeling quite unmotivated about writing a mostly > boilerplate announcement every time I upload a minor version bump of a > package I maintain. Then automate the announces! Let stupid hardware do stupid work. It was designed to do exactly that! > "stow has been updated from version 2.2.0 to 2.2.2. You can read the > upstream changelog to see what changed. stow is blah blah blah" > Does anyone care about that? Lately I don't. In fact I've skipped sending > the last few, and no one seems to have noticed. > Can we leave it to the maintainer's discretion about whether they need to > send one of those on every update? Maybe it already is, and I didn't know. > Of course some updates are important or need explanation or a headsup, and > then the maintainer should send one. IMHO, the announcements are useful to track version history. Unless there's some other comparable source, they are useful for archival purposes. -- With best regards, Andrey Repin Thursday, November 19, 2015 23:41:24 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 multithreading performance
Kacper Michajlow wrote:
I recently noticed that Cygwin multithreading is very inefficient. I
was repacking few git repositories and with Cygwin's git, it spawns
threads but they are so badly synchronized that there is no speed gain
over one thread and possible loose because of the overhead. On my
machine I got 7-10% CPU usage while with git build with mingw easily
uses 100%.
You can find the code in question here
https://github.com/git/git/blob/master/builtin/pack-objects.c#L1967-L2094
Do you have any suggestions? Is there any chance to get MT workloads
improved in Cygwin? In present days it is really big problem in my
opinion.
Although there have been some issues with Cygwin pthreads reported and
resolved, I can't recall complaints about their performance. You don't
supply much specific info so I had to guess that you must be doing
something like 'git gc' to provoke calls to the code you quote. Please
give more info if I was mistaken.
I did an strace of 'git gc' over a small source tree I have and found:
~/src/cygwin-cygutils strace --mask=debug+syscall+thread -o git.strace git gc
Counting objects: 1691, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (398/398), done.
Writing objects: 100% (1691/1691), done.
Total 1691 (delta 1250), reused 1691 (delta 1250)
~/src/cygwin-cygutils grep "fork(" git.strace
350 64 [main] git 360 fork: 0 = fork()
59 113379 [main] git 4980 fork: 360 = fork()
496 242346 [main] git 4980 fork: 368 = fork()
513 242585 [main] git 368 fork: 0 = fork()
828 589040 [main] git 4980 fork: 4968 = fork()
685 589341 [main] git 4968 fork: 0 = fork()
591 126631 [main] git 4968 fork: 1784 = fork()
483 126866 [main] git 1784 fork: 0 = fork()
618 2320996 [main] git 4980 fork: 2912 = fork()
558 2321259 [main] git 2912 fork: 0 = fork()
555 3023781 [main] git 4980 fork: 1612 = fork()
500 3024002 [main] git 1612 fork: 0 = fork()
766 3112383 [main] git 4980 fork: 1756 = fork()
681 3112655 [main] git 1756 fork: 0 = fork()
There's your problem. Git is for some reason fork()ing to do its
parallel operations. fork() is very complicated to emulate on Windows
and Cygwin's fork() is already known to be slow compared to native OS
implementations.
Why is mingw faster? Inspection of run-command.c in the git source tree
(BTW thanks for the github link) shows that start_command() has two code
paths divided by "#ifndef GIT_WINDOWS_NATIVE". The Windows native path
(e.g. mingw) doesn't fork() but instead spawns subprocesses. On Cygwin
the fork() path is used. Git probably ought to use the spawn code path
on Cygwin too.
I don't know offhand if this is something Cygwin's git maintainer would
want to tackle or if it should be handled upstream but I'd guess the latter.
Hope this helps,
..mark
--
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: XWin Server starts but terminates shortly after
On 17/11/2015 15:13, Jon Turney wrote:
On 13/11/2015 15:13, Thomas Schweikle wrote:
Adding "-nowgl" does the trick. XWin is running again.
It seems that this problem manifests itself when running on a Windows
guest under VMWare, with their SVGA driver.
This seems to be caused by a c374 (STATUS_HEAP_CORRUPTION) exception
raised whilst loading the VMWare OpenGL driver.
This is easy to reduce to just the code that XWin uses to probe the
capabilities of the native OpenGL renderer (attached).
$ gcc -Wall xwin-gl-probe.c -lgdi32 -lopengl32 -o xwin-gl-probe.exe
$ strace ./xwin-gl-probe.exe
[...]
--- Process 2356, exception c374 at 77B64102
[...]
If I add a checking with HeapValidate() before the crashing call to
ChoosePixelFormat(), that doesn't report any problems, so that seems to
rule out the heap corruption being introduced by this code.
Compiling the same code with VS 2013 works without problems on my test
VM (VMWare Player 12.0.1 + W7 x64 + VMWare SVGA driver)
This doesn't really get me any further forward though. Does this crash
loading vm3dgl64 because of a bug in vm3dgl64 which is only exposed in
Cygwin? or because the Cygwin environment doesn't satisfy some
requirement of vm3dgl64 that it should?
This isn't the first report of a crash in this probe with various
graphics drivers (although typically the exception is c005, which we
can catch and fallback to software rendering), so while it's tempting to
assume this is a problem in the graphics driver, it's possible that
something systematic is wrong.
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
//
// gcc xwin-gl-probe.c -lgdi32 -lopengl32 -o xwin-gl-probe.exe -Wall
//
#include
#include
int
main(void)
{
HWND hwnd;
HDC hdc;
HGLRC hglrc;
// create window class
#define WIN_GL_TEST_WINDOW_CLASS L"XWinGLTest"
{
static ATOM glTestWndClass = 0;
if (glTestWndClass == 0) {
WNDCLASSEXW wc;
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC;
wc.lpfnWndProc = DefWindowProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = GetModuleHandle(NULL);
wc.hIcon = 0;
wc.hCursor = 0;
wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = NULL;
wc.lpszClassName = WIN_GL_TEST_WINDOW_CLASS;
wc.hIconSm = 0;
RegisterClassExW(&wc);
}
}
// create an invisible window for a scratch DC
hwnd = CreateWindowExW(0,
WIN_GL_TEST_WINDOW_CLASS,
L"XWin GL Renderer Capabilities Test Window",
WS_OVERLAPPEDWINDOW|WS_VISIBLE, 0, 0, 0, 0, NULL,
NULL, GetModuleHandle(NULL),
NULL);
if (hwnd == NULL) {
printf("Couldn't create a window for render capabilities testing\n");
goto error;
}
hdc = GetDC(hwnd);
if (!hdc) {
printf("Couldn't create a DC for render capabilities testing\n");
goto error;
}
// we must set a pixel format before we can create a context
{
PIXELFORMATDESCRIPTOR pfd = {
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DEPTH_DONTCARE |
PFD_DOUBLEBUFFER_DONTCARE | PFD_STEREO_DONTCARE,
PFD_TYPE_RGBA,
24,
0, 0, 0, 0, 0, 0,
0,
0,
0,
0, 0, 0, 0,
0,
0,
0,
PFD_MAIN_PLANE,
0,
0, 0, 0
};
int iPixelFormat = ChoosePixelFormat(hdc, &pfd);
if (iPixelFormat == 0) {
printf("ChoosePixelFormat failed\n");
goto error;
}
if (!SetPixelFormat(hdc, iPixelFormat, NULL)) {
printf("SetPixelFormat %d failed\n", iPixelFormat);
goto error;
}
printf("Testing pixelFormatIndex %d\n",iPixelFormat);
}
hglrc = wglCreateContext(hdc);
if (!wglMakeCurrent(hdc, hglrc)) {
printf("wglMakeCurrent error: %08x dc %p ctx %p\n",
(unsigned)GetLastError(), hdc, hglrc);
}
printf("Done\n");
error:
return 0;
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Symlink targets dereferenced when winsymlinks:native
From: David Macek > On 18. 11. 2015 20:48, Corinna Vinschen wrote: > > On Nov 18 19:13, David Macek wrote: > >> On 18. 11. 2015 18:55, Corinna Vinschen wrote: > >>> On Nov 17 23:28, David Macek wrote: > I went through the UG looking for differences between regular Cygwin > symlinks and NTFS symlinks, but couldn't find this documented. It > seems that when using winsymlinks:native, the target path is first > dereferenced before storing it in the link. > >>> > >>> It's a result of the native symlink being a Windows path. The > >>> ultimate conversion from POSIX to Windows path dereferences all > >>> symlinks. > > Hmm. I just performed a test on my Cygwin installation and it doesn't seem > to match the described behavior. > > /cygdrive/w/temp $ export CYGWIN=winsymlinks:nativestrict > /cygdrive/w/temp $ touch XXX > /cygdrive/w/temp $ ln -s XXX YYY > /cygdrive/w/temp $ ln -s YYY ZZZ > /cygdrive/w/temp $ ls -l > ... > -rwxrwxr--+ ... XXX > lrwxrwxrwx ... YYY -> /cygdrive/w/temp/XXX > lrwxrwxrwx ... ZZZ -> /cygdrive/w/temp/YYY > > What's interesting though, is that the paths are converted to absolute > ones. This again only happens for winsymlinks:native, but NTFS symlinks > have no such restriction and `mklink` happily creates relative links. FWIW, my results are different: $ printenv CYGWIN winsymlinks:nativestrict $ touch XXX $ ln -s XXX YYY $ ln -s YYY ZZZ $ ls -l total 0 -rw-r- 1 knellis Domain Users 0 Nov 19 14:28 XXX lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 YYY -> XXX lrwxrwxrwx 1 knellis Domain Users 3 Nov 19 14:28 ZZZ -> YYY $ uname -svr CYGWIN_NT-6.1 2.3.1(0.291/5/3) 2015-11-14 12:44 $ --Ken Nellis
Re: Symlink targets dereferenced when winsymlinks:native
On 18. 11. 2015 20:48, Corinna Vinschen wrote: > On Nov 18 19:13, David Macek wrote: >> On 18. 11. 2015 18:55, Corinna Vinschen wrote: >>> On Nov 17 23:28, David Macek wrote: I went through the UG looking for differences between regular Cygwin symlinks and NTFS symlinks, but couldn't find this documented. It seems that when using winsymlinks:native, the target path is first dereferenced before storing it in the link. >>> >>> It's a result of the native symlink being a Windows path. The >>> ultimate conversion from POSIX to Windows path dereferences all >>> symlinks. Hmm. I just performed a test on my Cygwin installation and it doesn't seem to match the described behavior. /cygdrive/w/temp $ export CYGWIN=winsymlinks:nativestrict /cygdrive/w/temp $ touch XXX /cygdrive/w/temp $ ln -s XXX YYY /cygdrive/w/temp $ ln -s YYY ZZZ /cygdrive/w/temp $ ls -l ... -rwxrwxr--+ ... XXX lrwxrwxrwx ... YYY -> /cygdrive/w/temp/XXX lrwxrwxrwx ... ZZZ -> /cygdrive/w/temp/YYY What's interesting though, is that the paths are converted to absolute ones. This again only happens for winsymlinks:native, but NTFS symlinks have no such restriction and `mklink` happily creates relative links. >> Should that behaviour stay? > > Yes. Consider that neither Cygwin or Interix symlinks with SYSTEM bit > set, nor symlinks using WIndows shortcuts make any sense as part of a > native symlink. As a result, Cygwin does a full path conversion from > POSIX to symlink-less Windows path to crate native symlinks. I'm sorry, but I'm not sure I understand. What does "to be as part of a symlink" mean in this context and how did non-NTFS symlinks get into the discussion? *** After thinking about this for some time, I began to assume that "part of a symlink" was meant as "a symlink target". In that case, it seems that Cygwin is pretty intelligent about this, as the dereferencing only happens when targetting a non-NTFS symlink, at least in trivial cases. If that's the case, then I'm okay with that (and I'll try to document it), and the only question that remains is the one about relative paths (see above). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: ssh ControlMaster re-broken
> On Nov 17 12:46, Zhu, Binbin (Nokia - CN/Hangzhou) wrote: > > Hi, > > > > It worked month ago, but it failed after reinstall. > > Are you really sure it ever worked? To the best of my knowledge the > control master stuff always required descriptor passing via AF_LOCAL > sockets, which is not available under Cygwin. > > Corinna Concur - it's never worked AFAIK. Not that you need my concurrence, since you're the developer in the best position to know. Andrew -- 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: {openldap/openldap-server/libopenldap2_4_2/openldap-devel}-2.4.42-1: Lightweight Directory Access Protocol suite
Hi New versions of 'openldap/openldap-server/libopenldap2_4_2/openldap-devel' have been uploaded to a server near you. o Build for cygwin 2.3.1 with gcc-4.9.3 o Recompiled again latest perl-5.22.0 openldap NEWS: === OpenLDAP 2.4.42 Release (2015/08/14) Fixed liblber address length for CLDAP (ITS#8158) Fixed libldap dnssrv potential overflow with port number (ITS#7027,ITS#8195) Fixed slapd cn=config when updating olcAttributeTypes (ITS#8199) Fixed slapd-mdb to correctly update search candidates for scoped searches (ITS#8203) Fixed slapo-ppolicy with redundant mod ops on glued trees (ITS#8184) Fixed slapo-rwm crash when deleting rewrite rules (ITS#8213) Build Environment Fixed libdb detection with gcc 5.x (ITS#8056) OpenLDAP 2.4.41 Release (2015/06/21) Fixed ldapsearch to explicitly flush its buffer (ITS#8118) Fixed libldap async connections (ITS#8090) Fixed libldap double free of request during abandon (ITS#7967) Fixed libldap error string for LDAP_X_CONNECTING (ITS#8093) Fixed libldap segfault in ldap_sync_initialize (ITS#8001) Fixed libldap ldif-wrap off by one error (ITS#8003) Fixed libldap handling of TLS in async mode (ITS#8022) Fixed libldap null pointer dereference (ITS#8028) Fixed libldap mutex handling with LDAP_OPT_SESSION_REFCNT (ITS#8050) Fixed slapd slapadd config db import of minimal frontend entry (ITS#8150) Fixed slapd slapadd onetime leak with -w (ITS#8014) Fixed slapd sasl auxprop crash with invalid config (ITS#8092) Fixed slapd syncrepl delta-mmr issue with overlays and slapd.conf (ITS#7976) Fixed slapd syncrepl mutex for cookie state (ITS#7968) Fixed slapd syncrepl memory leaks (ITS#8035) Fixed slapd syncrepl to free presentlist at end of refresh mode (ITS#8038) Fixed slapd syncrepl to streamline presentlist (ITS#8042) Fixed slapd syncrepl concurrency when CHECK_CSN is enabled (ITS#8120) Fixed slapd rootdn checks for hidden backends (ITS#8108) Fixed slapd segfault when using matched values control (ITS#8046) Fixed slapd-ldap reconnection behavior on remote failure (ITS#8142) Fixed slapd-mdb minor case typo (ITS#8049) Fixed slapd-mdb one-level search (ITS#7975) Fixed slapd-mdb heap corruption (ITS#7965) Fixed slapd-mdb crash after deleting in-use schema (ITS#7995) Fixed slapd-mdb minor code cleanup (ITS#8011) Fixed slapd-mdb to return errors when using incorrect env flags (ITS#8016) Fixed slapd-mdb to correctly update search candidates (ITS#8036, ITS#7904) Fixed slapd-mdb when there were more than 65535 aliases in scope (ITS#8103) Fixed slapd-mdb alias deref when objectClass is not indexed (ITS#8146) Fixed slapd-meta TLS initialization with ldaps URIs (ITS#8022) Fixed slapd-meta to have better error logging (ITS#8131) Fixed slapd-perl conversion to cn=config (ITS#8105) Fixed slapd-sql autocommit config variable (ITS#8129,ITS#6613) Fixed slapo-collect segfault (ITS#7797) Fixed slapo-constraint with 0 count constraint (ITS#7780,ITS#7781) Fixed slapo-deref with empty attribute list (ITS#8027) Fixed slapo-memberof to correctly reject invalid members (ITS#8107) Fixed slapo-sock result parser for CONTINUE (ITS#8048) Fixed slapo-syncprov synprov_matchops usage of test_filter (ITS#8013) Fixed slapo-syncprov segfault on disconnect/abandon (ITS#5452,ITS#8012) Fixed slapo-syncprov memory leak (ITS#8039) Fixed slapo-syncprov segfault on disconnect/abandon (ITS#8043) Fixed slapo-syncprov deadlock when autogroup is in use (ITS#8063) Fixed slapo-syncprov potential loss of changes when under load (ITS#8081) Fixed slapo-unique enforcement of uniqueness with manageDSAit control (ITS#8057) Build Environment Fixed ftello reference for Win32 (ITS#8127) Enhanced contrib modules build paths (ITS#7782) Fixed contrib/autogroup internal operation identity (ITS#8006) Fixed contrib/autogroup to skip internal ops with accesslog (ITS#8065) Fixed contrib/passwd/sha2 compiler warning (ITS#8000) Fixed contrib/noopsrch compiler warning (ITS#7998) Fixed contrib/dupent compiler warnings (ITS#7997) Test suite: Added vrFilter test (ITS#8046) Contrib Added pbkdf2 sha256 and sha512 schemes (ITS#7977) Fixed autogroup modification callback responses (ITS#6970) Fixed nssov compare with usergroup (ITS#8079) Fixed nssov password change behavior (ITS#8080) Fixed nssov updated to 0.9.4 (ITS#8097) Documentation Added ldap_get_o
RE: does anyone care about package minor version bump announcements?
From: Corinna Vinschen > On Nov 19 10:18, cyg Simple wrote: > > On 11/19/2015 10:13 AM, Andrew Schulman wrote: > > > Does anyone care about that? Lately I don't. In fact I've skipped > > > sending > > > the last few, and no one seems to have noticed. > > > > > > Can we leave it to the maintainer's discretion about whether they need to > > > send one of those on every update? Maybe it already is, and I didn't > > > know. > > > Of course some updates are important or need explanation or a headsup, and > > > then the maintainer should send one. > > > > My opinion is that every time the package is modified there should be an > > announcement of the new package and what was changed. Pointing to a > > ChangeLog may be fine but not announcing the change is just wrong. > > I agree. Maybe cygport's new (in testing) "announce" command simplifies > it enough to be not much of a burden? The announcements let me know when there are updates for my installation, so I would like to see them continue. --Ken Nellis
Re: does anyone care about package minor version bump announcements?
On Nov 19 10:18, cyg Simple wrote: > On 11/19/2015 10:13 AM, Andrew Schulman wrote: > > Does anyone care about that? Lately I don't. In fact I've skipped sending > > the last few, and no one seems to have noticed. > > > > Can we leave it to the maintainer's discretion about whether they need to > > send one of those on every update? Maybe it already is, and I didn't know. > > Of course some updates are important or need explanation or a headsup, and > > then the maintainer should send one. > > My opinion is that every time the package is modified there should be an > announcement of the new package and what was changed. Pointing to a > ChangeLog may be fine but not announcing the change is just wrong. I agree. Maybe cygport's new (in testing) "announce" command simplifies it enough to be not much of a burden? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpRVebjGMLXq.pgp Description: PGP signature
Re: does anyone care about package minor version bump announcements?
On 11/19/2015 10:13 AM, Andrew Schulman wrote: > Does anyone care about that? Lately I don't. In fact I've skipped sending > the last few, and no one seems to have noticed. > > Can we leave it to the maintainer's discretion about whether they need to > send one of those on every update? Maybe it already is, and I didn't know. > Of course some updates are important or need explanation or a headsup, and > then the maintainer should send one. My opinion is that every time the package is modified there should be an announcement of the new package and what was changed. Pointing to a ChangeLog may be fine but not announcing the change is just wrong. -- cyg 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
does anyone care about package minor version bump announcements?
Lately I find myself feeling quite unmotivated about writing a mostly boilerplate announcement every time I upload a minor version bump of a package I maintain. "stow has been updated from version 2.2.0 to 2.2.2. You can read the upstream changelog to see what changed. stow is blah blah blah" Does anyone care about that? Lately I don't. In fact I've skipped sending the last few, and no one seems to have noticed. Can we leave it to the maintainer's discretion about whether they need to send one of those on every update? Maybe it already is, and I didn't know. Of course some updates are important or need explanation or a headsup, and then the maintainer should send one. Andrew -- 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: Fwd: Limited clipboard buffer between X11 apps and Microsoft Windows
On 17/11/2015 18:57, Kevin Connor Arpe wrote: My issue: Copying text between X11 apps and Microsoft Windows has limited clipboard buffer. My office co-worker and I were able to replicate the same issue on our machines. To replicate: 1) Run Cygwin X Server locally. 2) Run gedit remotely (using company Linux hosts) and redirect display to our local Cygwin X Server. 3) Copy some text in gedit, paste in Windows app, e.g. Notepad. We are able to find a limit (approximately 1000+ lines of text). To be very clear: We can copy small amounts to text, but not large amounts of text. My co-worker found this historical Cygwin mailing list item. It looks very similar: http://cygwin.1069669.n5.nabble.com/emacs-x11-new-clipboard-size-limitation-td104696.html When the copy/paste fails, I see the following in /var/log/xwin/XWin.0.log: [298268.591] winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList returned: XConverterNotFound Thanks for reporting this issue. Unfortunately, I don't think this is a recurrence of the regression in that old report. Briefly, there is a different protocol [1] for transferring clipboard contents too large to fit in a single X protocol message (approximately 262144 bytes), which is not currently implemented by the X11/Windows clipboard synchronization code. Your estimate of 1000 lines seems a little low, but in my testing this is the limit I hit. [1] http://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html#INCR_Properties -- 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: gfortran segfaults on "Hello world"
On 19/11/2015 08:05, Thomas Koenig wrote: Hi, Cygwin64 now offers a choice among 4.9.2-3, 4.9.3-1, and 5.2.0-1. I have the last one installed, and in addition a recently built 6.0 on my Haswell laptop. I’m fairly certain I have used the 4.9.3 successfully in the past. It looks like you need to update to the current gmp and mpfr. Normally, cygwin install.exe would tell you to do that if you install a gcc and gfortran built against those. I just installed 5.2.0, and got the same warning about mismatched libraries and the same segfault. If you really wanted 4.9.3-1 running against the older gmp and mpfr, you could build it yourself. The library versions are *newer* than what both 4.9.3 and 5.2.0 from the distribution are built against. This may or may not be the cause of the problem; either way gfortran is currently broken on Cygwin 64. gfortran 4.9.3-1 is working fine on my W7-64 system $ cygcheck -cd |grep -E "fortran|gmp|mpfr" gcc-fortran 4.9.3-1 gmp 6.1.0-1 libgfortran34.9.3-1 libgmp-devel6.1.0-1 libgmp106.1.0-1 libgmpxx4 6.1.0-1 libmpfr-devel 3.1.3-1 libmpfr43.1.3-1 mpfr3.1.3-1 $ gfortran -ffree-form helloworld.f -o helloworld-f77-gcc $ ./helloworld-f77-gcc.exe Hello World! $ cat helloworld.f write (*,*) "Hello World!" end -- 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: cygutils-1.4.15-1
Version 1.4.15-1 of cygutils has been uploaded. Cygutils is a collection of simple (single source file) utilities, including: lpr, banner, dump (no, not the ext2 backup utility; it's a hexdumper), Windows clipboard manipulation programs, and many more. This is a bug fix and maintainer swap release. Two mkshortcut issues reported on the Cygwin mailing list have been fixed: * Segfault due to freeing an adjusted pointer. * Malfunction when saving a link to a relative path on newer versions of Windows after Windows 7. Both issues were reported by Anthony Heading, who also supplied patches. The source tree was converted from CVS to Git by Corinna Vinschen. Minor build and packaging issues were corrected by the new maintainer, yours truly, Mark Geisert. *** 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.com 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. -- 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: gmp-6.1.0-1
[…] Sorry, that message was sent before I finished the sentence. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
Journal
> The message was not delivered due to the following reason(s): Command The not recognised. > Your message was not delivered because the destination server was Command Your not recognised. > unreachable within the allowed queue period. The amount of time Command unreachable not recognised. > a message is queued before it is returned depends on local configura- Command a not recognised. > tion parameters. Command tion not recognised. > Most likely there is a network problem that prevented delivery, but Command Most not recognised. > it is also possible that the computer is turned off, or does not Command it not recognised. > have a mail system running right now. Command have not recognised. > Your message was not delivered within 5 days: Command Your not recognised. > Host 30.204.245.5 is not responding. Command Host not recognised. > The following recipients could not receive this message: Command The not recognised. > Command not recognised. > Please reply to postmas...@cygwin.com Command Please not recognised. > if you feel this message to be in error. Command if not recognised. -- 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
