On Aug 10, 2015, at 10:00 AM, Corinna Vinschen corinna-cyg...@cygwin.com
wrote:
for testing, I need somebody running a small test program on a machine
with more than 64 CPUs under Windows 7 or later.
I don’t think that’s possible today. Windows 7 Professional is limited to 2
physical
On Aug 10, 2015, at 10:23 AM, Warren Young wrote:
On Aug 10, 2015, at 10:00 AM, Corinna Vinschen corinna-cyg...@cygwin.com
wrote:
for testing, I need somebody running a small test program on a machine
with more than 64 CPUs under Windows 7 or later.
I don’t think that’s possible today.
On Aug 10 05:00, mku wrote:
Oh, sorry. I did a fresh 2.2 install to avoid side effects from my previous
updated one and forgot to modify the nsswitch.conf. After correcting it, the
result now is the same from the time aspect but loading of the net dlls have
now disappeared as expected.
+++ 8
Markus Hoenicka writes:
HOMEDRIVE=C:
HOMEPATH=\Users\username
I don't know if these are relevant if you use roaming profiles
though. The path I've shown as $HOME is not arcane at all.
You still haven't shown what $HOME is set in Cygwin, only what path it
maps to on Windows.
windows
At 2015-08-10 18:11, Achim Gratz was heard to say:
Markus Hoenicka writes:
HOMEDRIVE=C:
HOMEPATH=\Users\username
I don't know if these are relevant if you use roaming profiles
though. The path I've shown as $HOME is not arcane at all.
You still haven't shown what $HOME is set in Cygwin, only
I received an e-mail this morning from a gentleman named Joachim
König-Baltes concerning this issue. He found an old post in the
Dexpot forums with a different issue, but the solution is working for
him (and for me) and now the latest version of xorg-server in Cygwin
is working with Dexpot again.
Hi folks,
for testing, I need somebody running a small test program on a machine
with more than 64 CPUs under Windows 7 or later. In fact, the only
thing I'm interested in is the output generated by a certain system
call. Ideally the machine has more than 64 logical CPUs, but not
exactly a
On Aug 10 10:23, Warren Young wrote:
On Aug 10, 2015, at 10:00 AM, Corinna Vinschen corinna-cyg...@cygwin.com
wrote:
for testing, I need somebody running a small test program on a machine
with more than 64 CPUs under Windows 7 or later.
I don’t think that’s possible today. Windows 7
Greetings, Warren Young!
On Aug 10, 2015, at 10:00 AM, Corinna Vinschen corinna-cyg...@cygwin.com
wrote:
for testing, I need somebody running a small test program on a machine
with more than 64 CPUs under Windows 7 or later.
I don’t think that’s possible today. Windows 7 Professional is
Corinna Vinschen writes:
I was referring to Windows 7 because that's the first OS (including
it's 2008R2 server version) which supports more than 64 CPUs and the
OS calls required to use and fetch info on them,
GetLogicalProcessorInformationEx.
I think the only practical use of this
On Mon, Aug 10, 2015 at 10:45 AM, Nem W Schlecht nem...@gmail.com wrote:
In case that forum post goes away, the solution is to create a file
name 'myweschsel.ini' in the Dexpot install directory and simply put
the following 2 lines in it and restart Dexpot.
My sincere apologies for yet
The following packages have been updated in the Cygwin distribution:
* libpoco-devel-1.6.1-1
* libpoco-doc-1.6.1-1
* libpoco31-1.6.1-1
* poco-1.6.1-1
The POCO C++ Libraries are open source C++ class libraries that
simplify and accelerate the development of network-centric, portable
applications
i have just done a fresh reinstall of cygwin.
now vim is misbehaving:
for every file i open with vim, vim usually changes the 1st character of
the 1st line to g.
more exactly, if the 1st line is empty, vim makes no change,
if the 1st line contains only blanks, vim changes the last blank to g
if
On 2015-08-10, grimpen wrote:
i have just done a fresh reinstall of cygwin.
now vim is misbehaving:
for every file i open with vim, vim usually changes the 1st character of
the 1st line to g.
more exactly, if the 1st line is empty, vim makes no change,
if the 1st line contains only blanks,
On Aug 8 12:11, Marco Atzeri wrote:
On 05/08/2015 09:56, Corinna Vinschen wrote:
On Aug 3 23:37, Marco Atzeri wrote:
Testing on 64bit latest pure-ftp, I hit this issue:
/usr/sbin/pure-ftpd.exe -d
1 [main] pure-ftpd 8860 E:\cygwin64\usr\sbin\pure-ftpd.exe: *** fatal
error in
On Aug 7 12:51, mku wrote:
Dear Corinna,
thanks for the tip, but I had done it before (and modified it to my Needs).
To be safe, I did a complete fresh Installation and made the passwd and
group files as described. But the result is the same as before (a ls command
takes 5 to 10 secs to
At 2015-08-07 11:26, Jon TURNEY was heard to say:
On 06/08/2015 17:56, Markus Hoenicka wrote:
I've upgraded my setup yesterday and ran into a problem running the X
server. X ran just fine before the upgrade, just like any X client I
threw at it. I'm aware that some defaults have changed in the
On 8/10/2015 3:41 AM, Markus Hoenicka wrote:
At 2015-08-07 11:26, Jon TURNEY was heard to say:
Is there anything unusual about your home directory?
Well, we use roaming profiles here at work. This has caused problems
before, both in Cygwin and non-Cygwin apps. I've modified
Lester Ingber ingber at alumni.caltech.edu writes:
I do not see any way we can see details of dependencies before committing
to an install?
Patches welcome, I suppose.
For example, if I want to install Cygwin Octave, I can click on several
packages. When I continue to install, I have a
Am 2015-08-10 15:13, schrieb cyg Simple:
On 8/10/2015 3:41 AM, Markus Hoenicka wrote:
At 2015-08-07 11:26, Jon TURNEY was heard to say:
Is there anything unusual about your home directory?
Well, we use roaming profiles here at work. This has caused problems
before, both in Cygwin and
Markus Hoenicka markus.hoenicka at mhoenicka.de writes:
I've noticed the discussion about those changes, but I don't fully
understand the impact of them (and hopefully I don't have to). But I
don't think my problem argues against Corinna's changes because HOME
does not exist in my Windows
Greetings, cyg Simple!
Is there anything unusual about your home directory?
Well, we use roaming profiles here at work. This has caused problems
before, both in Cygwin and non-Cygwin apps. I've modified
/usr/bin/startxwin like this:
$ diff /usr/bin/startxwin.orig /usr/bin/startxwin
Oh, sorry. I did a fresh 2.2 install to avoid side effects from my previous
updated one and forgot to modify the nsswitch.conf. After correcting it, the
result now is the same from the time aspect but loading of the net dlls have
now disappeared as expected.
+++ 8 -
280 44318 [main] ls
mechanical solar system model and mechanical sun earth moon system model,
mainly made from brass, tracking the solar system. see
http://www.orrerystore.com/?q=RZJJBTPRIZ .
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
At 2015-08-10 15:44, Achim Gratz was heard to say:
Markus Hoenicka markus.hoenicka at mhoenicka.de writes:
I've noticed the discussion about those changes, but I don't fully
understand the impact of them (and hopefully I don't have to). But I
don't think my problem argues against Corinna's
At 2015-08-10 16:11, Markus Hoenicka erred:
And why does it *not* change if I set HOME to a local drive?
s/HOME/XAUTHORITY/
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Warren Young writes:
But that’s a side issue, because I don’t see why you think you need
Busybox in the first place, unless it is to be able to run postinst
scripts. Can’t you just say that that setup-*.tar.xz package never
has a postinst script, so that all you need to do is un-tar it?
The
On Aug 10, 2015, at 10:40 AM, Achim Gratz wrote:
Warren Young writes:
In that sense, setup.exe is already bootstrapped: it has everything
within itself to be able to replace itself.
I do like the concept of a self-contained executable, but teaching
setup.exe new tricks is likely a
On Aug 7 15:05, Warren Young wrote:
You’d have to couple this either with a MoveFileEx(…,
MOVEFILE_DELAY_UNTIL_REBOOT) call or a background task that replaces
/bin/setup.exe with %LOCALAPPDATA%/Temp/setup-v$next.exe.
Why?
I was assuming a world where setup.exe lives in /bin and you can
Corinna Vinschen writes:
Link?
I'd think Jon needs to give his OK for me to post it or he should post
it himself.
I'm using setup with the -m option exclusively so I'm mostly
interested that this still works.
That's pretty extensively tested by now since that is what I use for the
Warren Young writes:
Isn’t the whole point of this discussion that setup.exe already knows
all the tricks it needs to in order to do what we want here, except
for the “replace setup.exe in place” issue I’ve brought up separately?
Well, setup.exe today has a lot of probably bitrotted features
On Aug 10, 2015, at 12:03 PM, Achim Gratz wrote:
There have been a bunch of attempts in the past at replacing
setup.exe. At least 3, that I can think of. All have fizzled.
These were?
The Debian and Red Hat packaging systems have both been ported to Cygwin.
Those could be used along
Warren Young writes:
Replacing core infrastructure like this almost never works out
smoothly, and usually fails outright. It’s far better to remediate
the code base in-place, if at all possible.
That's my sentiment as well, but that doesn't preclude the exploration
of alternatives.
There
On Aug 10, 2015, at 11:00 AM, Achim Gratz wrote:
Warren Young writes:
Isn’t the whole point of this discussion that setup.exe already knows
all the tricks it needs to in order to do what we want here, except
for the “replace setup.exe in place” issue I’ve brought up separately?
Well,
On Aug 7, 2015, at 11:22 PM, Achim Gratz strom...@nexgo.de wrote:
a minimal Cygwin install system w/ busybox
Busybox isn’t going to be usable in its normal sense without cygwin1.dll to map
symlinks to argv[0] so that Busybox can tell how it was called, and thus which
function to provide.
With the release of poco-1.6.1, I've decided to do some housekeeping and
remove some of the earlier versions. I've managed to do this, but it has
left some empty directories lying around. Please could some kind soul
remove the following:
x86_64/release/poco/libpoco16/
On 10/08/15 22:49, Yaakov Selkowitz wrote:
On Mon, 2015-08-10 at 22:29 +0100, David Stacey wrote:
With the release of poco-1.6.1, I've decided to do some housekeeping
and remove some of the earlier versions. I've managed to do this, but
it has left some empty directories lying around. Please
The following packages have been updated in the Cygwin distribution:
* libpoco-devel-1.6.1-1
* libpoco-doc-1.6.1-1
* libpoco31-1.6.1-1
* poco-1.6.1-1
The POCO C++ Libraries are open source C++ class libraries that
simplify and accelerate the development of network-centric, portable
applications
On Aug 7 15:05, Warren Young wrote:
On Aug 7, 2015, at 1:47 PM, Corinna Vinschen corinna-cyg...@cygwin.com
wrote:
On Aug 6 17:57, Achim Gratz wrote:
I would consider this a release candidate. Some more testing with
interactive and ad-hoc installs would be useful, though.
I
On Aug 8 07:22, Achim Gratz wrote:
Corinna Vinschen writes:
I would consider this a release candidate. Some more testing with
interactive and ad-hoc installs would be useful, though.
How do you want to handle this? We don't have real provisions for
setup.exe release candidates.
On Sat, 2015-08-08 at 19:39 +0100, Adam Dinwoodie wrote:
On 08/08/2015 06:31, Achim Gratz wrote:
Adam Dinwoodie writes:
I've discovered a neat Git tool -- git subtree -- which is part
of Git's
contrib directory and isn't something we currently distribute
as part
of any of the
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=1641a85e8ffe8a3565fef6ce37502b6b5fb4ee9c
commit 1641a85e8ffe8a3565fef6ce37502b6b5fb4ee9c
Author: Corinna Vinschen cori...@vinschen.de
Date: Mon Aug 10 12:00:12 2015 +0200
Revert to leaving $HOME alone
* uinfo.cc
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=1e15b467379bccd7a2810dc786fdd23cc056da06
commit 1e15b467379bccd7a2810dc786fdd23cc056da06
Author: Corinna Vinschen cori...@vinschen.de
Date: Mon Aug 10 12:07:22 2015 +0200
miscfuncs.cc: Fix comment preceeding x86_64 memset and
43 matches
Mail list logo
