date:20120327

On Mar 23 14:41, Yaakov (Cygwin/X) wrote:
> On 2012-03-23 06:00, Corinna Vinschen wrote:
> >On Mar 22 22:43, Steven Monai wrote:
> >>I recently downloaded the latest 'openssh' source package (5.9p1-1) via
> >>setup.exe, and was disappointed to discover that it did not come with an
> >>automated build script. Isn't every package supposed to have one? (The
> >>Cygwin Package Contributor's Guide seems to imply this.)
> >>
> >>Anyway, as a side-effect of some other work I did, I created a cygport
> >>script for openssh that (I believe) recreates the latest binary package
> >>correctly. If anyone is interested, I put a copy of the cygport script
> >>and the associated patches here:
> >>
> >>http://dev.monai.ca/cygwin/openssh-cygport/index.html
> >>
> >>The files are very small (each<  1kB); feel free to download and use
> >>them however you like.
> >
> >Cool, thanks!  I'll give them a try next week.
> 
> Close, a few changes are needed:
> 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/openssh;a=tree

Thanks,  I'll use that for the next OpenSSH release.  6.0p1 is already
a bit overdue.  The call for testing was early February.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: rpm, rpm-build missing dependency on libintl2

On Mar 23 12:47, Adam Dinwoodie wrote:
> The rpm and rpm-build packages both require cygintl-2.dll, provided by
> the libintl2 package, but don't have this as a dependency.
> 
> Or, at least, when I installed rpm and rpm-build, Setup.exe didn't
> automatically pick up libintl2, and when running certain commands
> (rpmquery and rpmbuild, for example), I'd get "error while loading
> shared libraries: cygintl-2.dll: cannot open shared object file: No
> such file or directory". Installing libintl2 resolved the error.

Thanks, I added the dependency to rpm's setup.hint.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: rcs 5.8-1 checks out wrong version of file when using similar mark symbols

2012-03-27 Thread Peter Rosin

Csaba Raduly skrev 2012-03-27 09:37:
> On Mon, Mar 26, 2012 at 9:29 PM, Richard Gribble  wrote:
>> Using rcs 5.8-1:
>>
>> Synopsis:
>>Given two mark symbols, abc (version 1.1) and abcd (version 1.2),
>>executing "co -rabc " will check out version 1.2, when it
>>should check out version 1.1.
>>
>> I set the mark symbols as follows:
>>rcs -nabc:1.1 -nabcd:1.2 
>>
>>
>> I dug into it, and found the following (rcsrev.c):
>>
>> 01:  static char const *
>> 02:  rev_from_symbol (struct cbuf const *id)
>> 03:  /* Look up "id" in the list of symbolic names starting with pointer
>> 04: "GROK (symbols)", and return a pointer to the corresponding
>> 05: revision number.  Return NULL if not present.  */
>> 06:  {
>> 07:for (struct link *ls = GROK (symbols); ls; ls = ls->next)
>> 08:  {
>> 09:struct symdef const *d = ls->entry;
>> 10:
>> 11:if (!strncmp (d->meaningful, id->string, id->size))
>> 12:  return d->underlying;
>> 13:  }
>> 14:return NULL;
>> 15:  }
>>
>> Note that line 11 tests the name of the requested mark symbol
>> (id->string) against each element of a linked-list (ls) containing all
>> the mark symbols for the file.  The problem is that it will only test
>> the first 'id->size' characters - so R25 (from the command line) matches
>> R25a (from the list) because the first three characters match and it
>> won't test any more than that (strncmp).
>>
>> I recommend modifying line 11 as follows:
>>if ((strlen(d->meaningful) == strlen(id->size)) && !strncmp
>> (d->meaningful, id->string, id->size))
> 
> I think strlen(id->size) is overkill :)
> 
> If both strings (d->meaningful and id->string) are NULL-terminated ,
> then a simple call to strlen would do the job:

You mean a simple call to strcmp here.

> if (!strcmp(d->meaningful, id->string))
> 
> It would do the right thing w.r.t. different lengths.
> 
>> Of course, since you now know that the two strings are the same size,
>> you could use strcmp - but that assumes that the && short-circuits, and
>> I don't know if that's guaranteed.
> 
> Yes, it required by the C standard.

But...careful!  You have to assume that the original authors were not
idiots!  Maybe the obvious strcmp was not used for a *good* reason?  I
can't tell if d->meaningful is guaranteed to be zero-terminated from the
limited context, but it sure is suspect.  Assuming that the original
authors were not idiots but instead made an off-by one error missing a
corner-case, the safer approach is to replace line 11 with:

11:if (!strncmp (d->meaningful, id->string, id->size + 1))

That is, if id->string is guaranteed to be zero-terminated, which is
not clear either, but perhaps easier to verify...

Cheers,
Peter

--
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: rcs 5.8-1 checks out wrong version of file when using similar mark symbols

2012-03-27 Thread Peter Rosin

Peter Rosin skrev 2012-03-27 10:11:
> But...careful!  You have to assume that the original authors were not
> idiots!  Maybe the obvious strcmp was not used for a *good* reason?  I
> can't tell if d->meaningful is guaranteed to be zero-terminated from the
> limited context, but it sure is suspect.  Assuming that the original
> authors were not idiots but instead made an off-by one error missing a
> corner-case, the safer approach is to replace line 11 with:
> 
> 11:if (!strncmp (d->meaningful, id->string, id->size + 1))
> 
> That is, if id->string is guaranteed to be zero-terminated, which is
> not clear either, but perhaps easier to verify...

Scratch that, including the zero-terminator in the compare doesn't work
as expected if one of the strings is not zero-terminated.  But the point
still stands, don't assume the original authors were idiots, and dig
into the reasons for them to not having used strcmp from the start.

Cheers,
Peter

--
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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 26 22:59, Ryan Johnson wrote:
> On 26/03/2012 9:40 PM, Jason Tishler wrote:
> >New News:
> >=== 
> >I have updated the version of rebase to 4.1.0-1.  The tarballs should be
> >available on a Cygwin mirror near you shortly.
> >
> >The following are the changes since the previous release:
> >
> > * Add rebase/rebaseall touch file (i.e., -t option) support.
> >
> > * Add rebaseall setup (i.e., -p option) support.
> >
> > * Add .oct to the default rebaseall suffix list.
> I've been meaning to ask... but maybe the above-mentioned -p flag
> obsoletes it now: What's the most efficient way to rebase after
> running setup? We've had the rebase db for a while now, so running
> rebaseall seems like overkill. Only the newly downloaded dlls need

Now that the new rebase is out, I'm going to create an _autorebase
package which will automatically call rebaseall at the end of a
successful run of setup, if that run also updated existing DLLs or
came with new DLLs.

In some cases this might take two minutes or so at the end of a setup
run, but at least we should see less rebase problems in future.

The most efficient way would be to change rebaseall so that only
DLLs are given to rebase which are updated or new.  But rebaseall
would still have to search the files in /etc/setup.  And rebase
still opens every DLL in the DB and from the command line to see
if the DB and reality are still in sync, and to decide which DLLs
have to be rebased and which are not.  So I'm not sure you can
make it much faster, unless you make the algorithm in rebase itself
faster.  You're welcome to send patches to the cygwin-apps list.
I'm pretty sure there is room for improvement.

Needless to say that the ultimately most efficient way would be
to find a method to avoid rebase problems after fork at all.  The
last attempt at it looked promising at first, but then again...
http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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.7.10 : output from .NET programs does not get through pipeline

2012-03-27 Thread David Kerrawn

> On Mon, Mar 26, 2012 at 05:00:02PM +0100, David Kerrawn wrote:
> >I too have noticed this problem or a variation of it. I've narrowed it
> down
> >to the change in pipe behavior in snapshot cygwin-src-20111023
> 
> Are you saying that this is still broken in recent snapshots?  A fix
> for
> this went in on March 12.
> 
> cgf
> 

cgf,
I'm sorry, you are correct. The 20120312 and later snapshots work fine.
My searches were only on .NET 1.7.10 and I failed to notice the subject
change.
Plus I should have tried the later snapshots.

Many thanks.

Regards
David.

--
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: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

On Mar 26 19:00, Christian Franke wrote:
> Corinna Vinschen wrote:
> >I see your point, but what bugs me a bit is the fact that
> >clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
> >always return the same value coarsest, regardless what value has been set.
> 
> If clock_setres was called and succeeded, then clock_getres(.)
> should return the value set before.
> 
> If clock_setres was not called, the coarsest value is IMO the only
> value that can be guaranteed.
> 
> The actual value returned by NtQueryTimerResolution is simply
> useless in this context: It is the minimum of all resolutions
> currently set by all running processes. It may change at any time.
> There is apparently no way the query the current setting of the
> current process.

Uh, right, I misunderstood.  I reverted the change to clock_setres.

> clock_gettime is part of the POSIX realtime extensions. On Linux it
> requires -lrt which implies -lpthreads. So if clock_gettime is used
> we can probably assume that the program wants a finer resolution.

Not really.  The usage of clock_gettime only implies that somebody wants
to measure time in a certain way depending on the used clock.  It does
not imply any resolution requirements.  And POSIX does not require any
specific resolutions, rather they are "implementation-defined".

> This leads to a possible alternative if clock_setres is not used: On
> first call of clock_gettime/getres set a finer (the finest?)
> resolution and return this with clock_getres.
> 
> Drawback: The finer resolution will persist until this process and
> all childs terminate. This may have unknown impact on performance,
> power management or whatever.
> 
> This could be fixed by resetting the resolution to default if
> clock_gettime is no longer used for some time (e.g. >= 10min).
> 
> Drawback: Even more complexity :-)

Nah, let's not go that route.  If you want a finer resolution by
default, I think there might be some other solution...

> >>- Unlike on e.g. Linux, CLOCK_REALTIME does not provide a better
> >>resolution than gettimeofday().
> >We can only use what the OS provides.  Starting with Windows 8 there
> >will be a new function call GetSystemTimePreciseAsFileTime:
> >http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx
> 
> This would provide an easy solution for >= Win8: clock_gettime
> returns GetSystemTimePreciseAsFileTime, clock_getres returns
> constant 1us.

As far as I can tell from a quick debug session, the implementation
of the underlying RtlGetSystemTimePrecise function is based on a spiffy
combination of the standard clock tick with the performance counter.
I'm not very good at assembler debugging, but the essence is access
to some known and some unknown time values from SharedUserData, a
call to RtlQueryPerformanceCounter, and a bit of arithmetic.

Maybe we can implement something similar without waiting for W8?  Does
anybody have code to combine a not so precise clock with a more precise
counter to create a more precise clock?

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Michael Lutz

Am 27.03.2012 10:36 schrieb Corinna Vinschen:
> Needless to say that the ultimately most efficient way would be
> to find a method to avoid rebase problems after fork at all.  The
> last attempt at it looked promising at first, but then again...
> http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073

You'd think all the statements about interoperability after the EU
anti-trust cases would apply to Cygwin as well.

If SUA can, Cygwin should as well: "Microsoft shall ensure that
third-party software products can interoperate with Microsoft’s Relevant
Software Products using the same Interoperability Information on an equal
footing as other Microsoft Software Products. (“Interoperability
Commitment”)".
http://www.microsoft.com/Presspass/press/2009/dec09/12-16Statement.mspx

Conveniently, nothing except a press contact is given on that page.


--
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

syslog-ng service fails: Error starting a service: QueryServiceStatus: Win32 error 1062

2012-03-27 Thread Ulrich Schmidt

E-Mail lesen «  1 Von 22 »  



Environment:
Windows 7/32
Cygwin 1.7.11-1
OpenSSH 5.9p1-1
syslog-ng 3.2.1-1

Dear Community,

Im just started with Cygwin and want to run openSSH. Im getting slowly furher 
with knowledge and success and had to install Cygwin therefore several times. I 
couldnt setup the openSSH-config again (with the ssh-host-config cmd). the 
flow of the script looked quite good but the service wasnt startable; I always 
got message cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 
error 1062.
Now I can help by deleting the privileged user cyg_server from /etc/passwd 
before running ssh-host-config.
I can now logon locally to the server by issuing ssh @localhost. But 
Logon from remote system fails with permission denied for some reason and I 
would like to find out by writing messages to syslog. syslog-ng was running; I 
changed the sshd_config to LogLevel DEBUG3 but nothing happened to the log. So 
I tried to restart syslog-ng as well; stopped it with cygrunsrv E syslog-ng  
but starting failed with same error cygrunsrv: Error starting a service: 
QueryServiceStatus:  Win32 error 1062 as before sshd. But here is no user I 
can delete from /etc/passwd.
So I removed the service (cygrunsrv R syslog-ng) and installed it again:
u005078@WS885383 ~
$ cygrunsrv -R syslog-ng

u005078@WS885383 ~
$ /bin/syslog-ng-config
Overwrite existing /etc/syslog-ng/syslog-ng.conf file? (yes/no) yes
/etc/syslog-ng/syslog-ng.conf has been renamed to 
/etc/syslog-ng/syslog-ng.conf.old.
Creating default syslog-ng configuration files in /etc/syslog-ng


Warning: The following function requires administrator privileges!

Do you want to install syslog-ng as service?
(Say "no" if it's already installed as service) (yes/no) yes

The service has been installed under LocalSystem account.
To start the service, call `net start syslog-ng' or `cygrunsrv -S syslog-ng'.

Check /etc/syslog-ng/syslog-ng.conf first, if it suits your needs.

Configuration finished. Have fun!

u005078@WS885383 ~
$ cygrunsrv -S syslog-ng
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
The service was not started.


u005078@WS885383 ~
$ cygrunsrv -VQ syslog-ng
Service : syslog-ng
Display name: CYGWIN syslog-ng
Current State   : Stopped
Command : /usr/sbin/syslog-ng -F
stdin path  : /dev/null
stdout path : /var/log/syslog-ng.log
stderr path : /var/log/syslog-ng.log
Process Type: Own Process
Startup : Automatic
Account : LocalSystem


Then I tried to start it with the privileged user:
u005078@WS885383 ~
$ cygrunsrv -R syslog-ng

u005078@WS885383 ~
$ cygrunsrv -VQ syslog-ng
cygrunsrv: Error querying a service: OpenService:  Win32 error 1060:
Der angegebene Dienst ist kein installierter Dienst. (means: The specified 
service is not an installed service)


u005078@WS885383 ~
$ cygrunsrv -I syslog-ng -d "SYSLOG-NG" -p /usr/sbin/syslog-ng -a "-F" -u 
cyg_server
Enter password of user `WS885383\cyg_server':
Reenter, please:

u005078@WS885383 ~
$ cygrunsrv -VQ syslog-ng
Service : syslog-ng
Current State   : Stopped
Command : /usr/sbin/syslog-ng -F
stdin path  : /dev/null
stdout path : /var/log/syslog-ng.log
stderr path : /var/log/syslog-ng.log
Process Type: Own Process
Startup : Automatic
Account : .\cyg_server


u005078@WS885383 ~
$ cygrunsrv -S syslog-ng
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
The service was not started.

And now I have no idea but to install the whole environment (Cygwin) again. 

I would appreciate to understand and fix whats going on here.

Ulrich



--
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: python-crypto update ?

2012-03-23 07:06 marco atzeri :
| Hi Jary,
| 
| python-crypto is still at 2.0.1-2,
| while latest upstream is at 2.5
| 
| https://www.dlitz.net/software/pycrypto/
| 
| Could you update ?

On it's way.

Please don't hesitate mail me directly if you notice anything to update,
Jari


--
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: optipng 0.6.4-1 -- Advanced PNG (Portable Network Graphics) optimizer


PACKAGE DESCRIPTION
===

Homepage: http://sourceforge.net/projects/optipng
License : GPL

A PNG optimizer that recompresses the image files to a smaller size.
It losslessly reduces the bit depth, the color type and the color
palette of the image, runs a suite of compression methods and
strategies, and selects the compression parameters that yield the
smallest output file. It also recognizes several external file formats
like BMP, GIF, TIFF and PNM (PBM, PGM, PPM).

CHANGES SINCE LAST RELEASE
==

Uses libpng14.

See /usr/share/doc/optipng/history.txt

INSTALL OR UPGRADE NOTES


Standard install.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

If you have questions or comments, please send them to the Cygwin
mailing list at .

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the 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(at)cygwin.com

More information on unsubscribing can be found:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above 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

[ANNOUNCEMENT] Obsoleted: spamprobe -- Bayesian spam filter


PACKAGE DESCRIPTION
===

Homepage: http://sourceforge.net/projects/spamprobe
License : QPL

CHANGES SINCE LAST RELEASE
==

Spamprobe has been obsoleted and will be removed from Cygwin. Please
migrate to the other similar spam filtering programs.

Rationale:

- No longer compiles with latest libdb
- Blocks libpng12 to libpng14 upgrade on Cygwin
- There are alternatives

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the 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(at)cygwin.com

More information on unsubscribing can be found:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above 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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Ryan Johnson

On 27/03/2012 7:40 AM, Michael Lutz wrote:

Am 27.03.2012 10:36 schrieb Corinna Vinschen:

Needless to say that the ultimately most efficient way would be
to find a method to avoid rebase problems after fork at all. The
last attempt at it looked promising at first, but then again...
http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073

You'd think all the statements about interoperability after the EU
anti-trust cases would apply to Cygwin as well.

If SUA can, Cygwin should as well: "Microsoft shall ensure that
third-party software products can interoperate with Microsoft’s Relevant
Software Products using the same Interoperability Information on an equal
footing as other Microsoft Software Products. (“Interoperability
Commitment”)".
http://www.microsoft.com/Presspass/press/2009/dec09/12-16Statement.mspx

Conveniently, nothing except a press contact is given on that page.
I suspect the EU commission could track down the right people at MS if
they were to decide that SUA/cygwin interop were important.
Unfortunately, it would have been much better for that issue to be
raised (a) while MS was still whimpering from the smackdown and (b)
before the announcement that SUA will be deprecated in Win8, after being
essentially unusable for several years before that.

Ryan

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: psmisc-22.16-1

I've updated the version of psmisc to 22.16-1.

This is an update to the latest stable upstream release.  A few
patches were necessary to build on Cygwin to fix the problems with
fuser from 22.14-1.


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.  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

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: python-crypto update ?

On Tue, Mar 27, 2012 at 04:45:37PM +0300, Jari Aalto wrote:
>2012-03-23 07:06 marco atzeri :
>| Hi Jary,
>| 
>| python-crypto is still at 2.0.1-2,
>| while latest upstream is at 2.5
>| 
>| https://www.dlitz.net/software/pycrypto/
>| 
>| Could you update ?
>
>On it's way.
>
>Please don't hesitate mail me directly if you notice anything to update,

That's a pretty bad precedent which completely flies in the face of
words to the contrary on the Cygwin page.

Everyone, please don't assume that Jari's suggestion holds for other
maintainers.  It is fine to send any and all requests/concerns about
Cygwin packages to the Cygwin list.  That is why we have the list.

--
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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Ryan Johnson


On 27/03/2012 4:36 AM, Corinna Vinschen wrote:

On Mar 26 22:59, Ryan Johnson wrote:

On 26/03/2012 9:40 PM, Jason Tishler wrote:

New News:
=== 
I have updated the version of rebase to 4.1.0-1.  The tarballs should be
available on a Cygwin mirror near you shortly.

The following are the changes since the previous release:

 * Add rebase/rebaseall touch file (i.e., -t option) support.

 * Add rebaseall setup (i.e., -p option) support.

 * Add .oct to the default rebaseall suffix list.

I've been meaning to ask... but maybe the above-mentioned -p flag
obsoletes it now: What's the most efficient way to rebase after
running setup? We've had the rebase db for a while now, so running
rebaseall seems like overkill. Only the newly downloaded dlls need

Now that the new rebase is out, I'm going to create an _autorebase
package which will automatically call rebaseall at the end of a
successful run of setup, if that run also updated existing DLLs or
came with new DLLs.

In some cases this might take two minutes or so at the end of a setup
run, but at least we should see less rebase problems in future.

That will be awesome.


The most efficient way would be to change rebaseall so that only
DLLs are given to rebase which are updated or new.  But rebaseall
would still have to search the files in /etc/setup.  And rebase
still opens every DLL in the DB and from the command line to see
if the DB and reality are still in sync, and to decide which DLLs
have to be rebased and which are not.  So I'm not sure you can
make it much faster, unless you make the algorithm in rebase itself
faster.
Honestly, I don't care if it's slow, just so it works. The problem right 
now -- at least in my naive invocations -- is that rebaseall attempts to 
rebase things which are in-use. Perhaps the initial in-sync-ness check 
opens the file in exclusive mode and fails? I know the in-use files were 
still in sync because they were when setup started. Setup didn't 
complain about anything and I didn't start any new processes after it 
completed.


Another idea: right now rebase[all] seems to give up if it encounters an 
in-use file. Can it just skip the file and keep going?



Needless to say that the ultimately most efficient way would be
to find a method to avoid rebase problems after fork at all.  The
last attempt at it looked promising at first, but then again...
http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073
That did look promising... I only run in a console under duress, but 
losing LoadLibrary is a deal-breaker.


Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 27 11:18, Ryan Johnson wrote:
>  The problem
> right now -- at least in my naive invocations -- is that rebaseall
> attempts to rebase things which are in-use. Perhaps the initial
> in-sync-ness check opens the file in exclusive mode and fails? I
> know the in-use files were still in sync because they were when
> setup started. Setup didn't complain about anything and I didn't
> start any new processes after it completed.
> 
> Another idea: right now rebase[all] seems to give up if it
> encounters an in-use file. Can it just skip the file and keep going?

http://cygwin.com/ml/cygwin-apps/2012-03/msg00028.html


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: syslog-ng service fails: Error starting a service: QueryServiceStatus: Win32 error 1062


On 3/27/2012 7:47 AM, Ulrich Schmidt wrote:

$ cygrunsrv -S syslog-ng
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
The service was not started.


This might be a known problem with syslog-ng.  See the thread starting at

  http://cygwin.com/ml/cygwin/2011-10/msg00449.html

Ken


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Ryan Johnson


On 27/03/2012 11:29 AM, Corinna Vinschen wrote:

On Mar 27 11:18, Ryan Johnson wrote:

  The problem
right now -- at least in my naive invocations -- is that rebaseall
attempts to rebase things which are in-use. Perhaps the initial
in-sync-ness check opens the file in exclusive mode and fails? I
know the in-use files were still in sync because they were when
setup started. Setup didn't complain about anything and I didn't
start any new processes after it completed.

Another idea: right now rebase[all] seems to give up if it
encounters an in-use file. Can it just skip the file and keep going?

http://cygwin.com/ml/cygwin-apps/2012-03/msg00028.html

I see... maybe I should subscribe to cygwin-apps.

Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to start bash fatal error

2012-03-27 Thread Diederik Faber


Hi,

sorry for the late reply, i've been on holiday.
Funny enough, that holiday seems to have resolved my bash issue. It no 
longer reproduces, stuff works normally again.


Anyway, marco, thanks for your response.

Kind regards,
Diederik

On 8-3-2012 11:12, marco atzeri wrote:

On 3/8/2012 10:48 AM, Diederik Faber wrote:

Hi all,

My cygwin installation was running quite happily, until I updated this
morning (march 8). After installation bash (now version 4.1.10-4) won't
launch anymore.
When starting it from a DOS box, it gives this output:

D:\cygwin>bash
0 [main] bash 8168 D:\cygwin\bin\bash.exe: *** fatal error - add_item
("\??\D:\cygwin", "/", ...) failed, errno 1
Stack trace:
Frame Function Args
00228908 6102FA3B (00228908, , , 7C9101DB)
00228BF8 6102FA3B (6119BD20, 8000, , 6119DB4F)
00229C28 61005F7C (611D7EA0, 00229C54, , 60FE000C)
00229C48 61005FB8 (611D7EA0, 0022BC70, 0001, 0003000A)
0022CC88 6108FAE4 (60FE000C, 2347, 0022CD58, 61081840)
0022CCB8 610D169F (48C98787, 01CCFD0F, 004657E0, 61272974)
1180 [main] bash 8168 exception::handle: Exception: STATUS_ACCESS_VIOLATION


My cygwin installation resides in D:\cygwin, but the add_item parameter
"\??\D:\cygwin" looks a bit suspicious.
I've located its value in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations\.
If I manually change the value to "D:\cygwin" and then start bash, it
still gives the same problem. Better yet, the \??\ has returned into the
registry key. Is this intended behavior?

Similar output is also generated when running cygcheck, so I couldn't
attach its output.

Does anybody have a similar problem or maybe an idea on how to fix this?

Thanks,
Diederik

try a rebase
http://cygwin.com/faq-nochunks.html#faq.using.fixing-fork-failures

If does not work, please follow

Problem reports: http://cygwin.com/problems.html

Regards

--
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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Karl M




On Mar 27 11:18, Ryan Johnson wrote:
> The problem
> right now -- at least in my naive invocations -- is that rebaseall
> attempts to rebase things which are in-use. Perhaps the initial
> in-sync-ness check opens the file in exclusive mode and fails? I
> know the in-use files were still in sync because they were when
> setup started. Setup didn't complain about anything and I didn't
> start any new processes after it completed.
> 
> Another idea: right now rebase[all] seems to give up if it
> encounters an in-use file. Can it just skip the file and keep going?

 

Can it at least complain about in-use files?

 

Attached are scripts that may help some deal with running cygwin processes.

They need to be run with admin rights.

 

Thanks,

 

...Karl   

cygwin-shutdown
Description: Binary data


cygwin-startup
Description: Binary data


cygwin-restart
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

[ANNOUNCEMENT] New package: _autorebase. Call rebaseall after installing new or updated DLLs

I've added a new package called _autorebase to the Cygwin distro.

This package is usually installed and updated automatically.  In the
default view of setup.exe you won't even see it.

The purpose of this package is to run rebaseall automatically after any
package containing DLLs is updated.

Please note that the _autorebase.sh postinstall script might run a few
minutes.  Don't be alarmed if the postinstall takes that long now.  It's
not because the _autorebase.sh script hangs, but because rebaseall might
take that long.  In my private testing scenario it could take a couple
of seconds up to two minutes.

Please also note that this package requires at least the new rebase
version 4.1.0.  The changes in rebase 4.1.0 deal gracefully with DLLs
which are in use while rebaseall runs.  Without these changes the
automatic call to rebaseall from the _autorebase package will fail and
you have to run rebaseall manually again.


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.  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

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 27 09:09, Karl M wrote:
> 
> 
> 
> On Mar 27 11:18, Ryan Johnson wrote:
> > The problem
> > right now -- at least in my naive invocations -- is that rebaseall
> > attempts to rebase things which are in-use. Perhaps the initial
> > in-sync-ness check opens the file in exclusive mode and fails? I
> > know the in-use files were still in sync because they were when
> > setup started. Setup didn't complain about anything and I didn't
> > start any new processes after it completed.
> > 
> > Another idea: right now rebase[all] seems to give up if it
> > encounters an in-use file. Can it just skip the file and keep going?
> 
>  
> 
> Can it at least complain about in-use files?

It does in the setup.log output.  Other than that, it can't since it
has no window to do output to.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: syslog-ng service fails: Error starting a service: QueryServiceStatus: Win32 error 1062

On Mar 27 11:40, Ken Brown wrote:
> On 3/27/2012 7:47 AM, Ulrich Schmidt wrote:
> >$ cygrunsrv -S syslog-ng
> >cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
> >The service was not started.
> 
> This might be a known problem with syslog-ng.  See the thread starting at
> 
>   http://cygwin.com/ml/cygwin/2011-10/msg00449.html

So you're just wating for me to update the syslog-ng package, right?
I'll see to it in the next couple of days.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: syslog-ng service fails: Error starting a service: QueryServiceStatus: Win32 error 1062


On 3/27/2012 12:16 PM, Corinna Vinschen wrote:

On Mar 27 11:40, Ken Brown wrote:

On 3/27/2012 7:47 AM, Ulrich Schmidt wrote:

$ cygrunsrv -S syslog-ng
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
The service was not started.


This might be a known problem with syslog-ng.  See the thread starting at

   http://cygwin.com/ml/cygwin/2011-10/msg00449.html


So you're just wating for me to update the syslog-ng package, right?


I didn't want to say that, but...


I'll see to it in the next couple of days.


Thanks.

Ken


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Karl M




> Can it at least complain about in-use files?
 
It does in the setup.log output. Other than that, it can't since it
has no window to do output to.
 

But setup will still alert the user about running cygwin processes, true?

 

Thanks,

 

...Karl   

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: python-crypto 2.5-1 -- Cryptographic algorithms and protocols for Python


PACKAGE DESCRIPTION
===

Homepage: https://launchpad.net/pycrypto
License : Public Domain / BSD-3-Clause

A collection of cryptographic algorithms and protocols, implemented
for use from Python. Among the contents of the package:

  * Hash functions: MD2, MD4.
  * Block encryption algorithms: AES, ARC2, Blowfish, CAST, DES, Triple-DES.
  * Stream encryption algorithms: ARC4, simple XOR.
  * Public-key algorithms: RSA, DSA, ElGamal, qNEW.
  * Protocols: All-or-nothing transforms, chaffing/winnowing.
  * Miscellaneous: RFC1751 module for converting 128-key keys
into a set of English words, primality testing.

CHANGES SINCE LAST RELEASE
==

- Built for Python 2.6
- See https://launchpad.net/pycrypto/+announcement

INSTALL OR UPGRADE NOTES


Standard install.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

If you have questions or comments, please send them to the Cygwin
mailing list at .

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the 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(at)cygwin.com

More information on unsubscribing can be found:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above 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

gold star for autorebase please?

I think Corinna's efforts for all of the work that went into getting
autorebase working in setup.exe deserve a gold star.  Could she get
one please?

cgf

--
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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

[Please invest in a mailer which does proper quoting]
On Tue, Mar 27, 2012 at 09:35:38AM -0700, Karl M wrote:
>Corinna wrote:
>>> Can it at least complain about in-use files?
> 
>>It does in the setup.log output. Other than that, it can't since it
>>has no window to do output to.
>
>But setup will still alert the user about running cygwin processes,
>true?

Yes, of course.  But if you choose to ignore the warning for some
reason, as many people seem to do, then there will be DLLs in
use.  And, if there are dlls being used which were not affected
by the update you might not even see the warning.

cgf

--
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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 27 09:35, Karl M wrote:
> 
> 
> 
> > Can it at least complain about in-use files?
>  
> It does in the setup.log output. Other than that, it can't since it
> has no window to do output to.
>  
> 
> But setup will still alert the user about running cygwin processes, true?

I wasn't aware that setup alerts the user about running cygwin processes.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: gold star for autorebase please?

On Mar 27 13:06, Christopher Faylor wrote:
> I think Corinna's efforts for all of the work that went into getting
> autorebase working in setup.exe deserve a gold star.  Could she get
> one please?

Hey, I just did my job ;)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

2012-03-27 Thread Christian Franke


Corinna Vinschen wrote:

On Mar 26 19:00, Christian Franke wrote:

Corinna Vinschen wrote:

I see your point, but what bugs me a bit is the fact that
clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
always return the same value coarsest, regardless what value has been set.

If clock_setres was called and succeeded, then clock_getres(.)
should return the value set before.

If clock_setres was not called, the coarsest value is IMO the only
value that can be guaranteed.

The actual value returned by NtQueryTimerResolution is simply
useless in this context: It is the minimum of all resolutions
currently set by all running processes. It may change at any time.
There is apparently no way the query the current setting of the
current process.

Uh, right, I misunderstood.  I reverted the change to clock_setres.


Sorry, I probably forgot to mention that NtSetTimerResolution returns 
the same useless actual value than NtQueryTimerResolution.


I would suggest:

status = NtSetTimerResolution (period, TRUE, &actual);
if (!NT_SUCCESS (status))
  { ... return -1; }
 -  minperiod = actual;
 +  minperiod = period;



- Unlike on e.g. Linux, CLOCK_REALTIME does not provide a better
resolution than gettimeofday().

We can only use what the OS provides.  Starting with Windows 8 there
will be a new function call GetSystemTimePreciseAsFileTime:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx

This would provide an easy solution for>= Win8: clock_gettime
returns GetSystemTimePreciseAsFileTime, clock_getres returns
constant 1us.

As far as I can tell from a quick debug session, the implementation
of the underlying RtlGetSystemTimePrecise function is based on a spiffy
combination of the standard clock tick with the performance counter.
I'm not very good at assembler debugging, but the essence is access
to some known and some unknown time values from SharedUserData, a
call to RtlQueryPerformanceCounter, and a bit of arithmetic.

Maybe we can implement something similar without waiting for W8?  Does
anybody have code to combine a not so precise clock with a more precise
counter to create a more precise clock?


The problem is that unlike the OS we don't have interrupts and probably 
don't want to start an extra thread which does timer calibrations.


It may be possible to implement a clock_gettime(CLOCK_REALTIME) which 
has the following properties (in most cases:-):
- Absolute time returned is in interval [GetSystemTime, 
GetSystemTime+coarsest)
- Differences between two returned times provide the resolution of the 
PerformanceCounter if the difference is small (tens of seconds).

I probably will have some time to check this next week.

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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1


On 3/27/2012 1:16 PM, Corinna Vinschen wrote:

On Mar 27 09:35, Karl M wrote:





Can it at least complain about in-use files?


It does in the setup.log output. Other than that, it can't since it
has no window to do output to.


But setup will still alert the user about running cygwin processes, true?


I wasn't aware that setup alerts the user about running cygwin processes.


I think there are two different things being discussed in this thread. 
On the one hand, setup alerts the user that certain DLLs are in use and 
can't be replaced.  This, of course, hasn't changed.


On the other hand, the new _autorebase postinstall script 
(/etc/postinstall/autorebase.bat) will run rebaseall and will deal 
gracefully with DLLs that can't be rebased because they're in use.


I just tried it, and the list of DLLs that couldn't be rebased does 
indeed appear in setup.log.full.  I also get a warning from setup.exe 
about the exit code of autorebase.bat, which some users might interpret 
as meaning that autorebase.bat failed.  I wonder if you'd be better off 
suppressing this warning somehow.


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 27 14:01, Ken Brown wrote:
> On 3/27/2012 1:16 PM, Corinna Vinschen wrote:
> >On Mar 27 09:35, Karl M wrote:
> >>
> >>
> >>
> >>>Can it at least complain about in-use files?
> >>
> >>It does in the setup.log output. Other than that, it can't since it
> >>has no window to do output to.
> >>
> >>
> >>But setup will still alert the user about running cygwin processes, true?
> >
> >I wasn't aware that setup alerts the user about running cygwin processes.
> 
> I think there are two different things being discussed in this
> thread. On the one hand, setup alerts the user that certain DLLs are
> in use and can't be replaced.  This, of course, hasn't changed.
> 
> On the other hand, the new _autorebase postinstall script
> (/etc/postinstall/autorebase.bat) will run rebaseall and will deal
> gracefully with DLLs that can't be rebased because they're in use.
> 
> I just tried it, and the list of DLLs that couldn't be rebased does
> indeed appear in setup.log.full.  I also get a warning from
> setup.exe about the exit code of autorebase.bat, which some users
> might interpret as meaning that autorebase.bat failed.  I wonder if
> you'd be better off suppressing this warning somehow.

That's unexpected.  The fact that rebase prints the warnings doesn't
mean it returns with a non-0 exit code.
In fact, as far as I can see, the only reason to fail with a non-0 exit
code after printing the "The following DLLs couldn't be rebased"
messages would be if saving the database failed, which also means
you should see a message "failed to create temporary rebase database"
or "failed to write rebase database" in the log.  If such a message
is not printed, I don't understand where the non-0 exit code is
coming from.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

On Mar 27 20:01, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Mar 26 19:00, Christian Franke wrote:
> >>Corinna Vinschen wrote:
> >>>I see your point, but what bugs me a bit is the fact that
> >>>clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
> >>>always return the same value coarsest, regardless what value has been set.
> >>If clock_setres was called and succeeded, then clock_getres(.)
> >>should return the value set before.
> >>
> >>If clock_setres was not called, the coarsest value is IMO the only
> >>value that can be guaranteed.
> >>
> >>The actual value returned by NtQueryTimerResolution is simply
> >>useless in this context: It is the minimum of all resolutions
> >>currently set by all running processes. It may change at any time.
> >>There is apparently no way the query the current setting of the
> >>current process.
> >Uh, right, I misunderstood.  I reverted the change to clock_setres.
> 
> Sorry, I probably forgot to mention that NtSetTimerResolution
> returns the same useless actual value than NtQueryTimerResolution.
> 
> I would suggest:
> 
> status = NtSetTimerResolution (period, TRUE, &actual);
> if (!NT_SUCCESS (status))
>   { ... return -1; }
>  -  minperiod = actual;
>  +  minperiod = period;

But that's not right.  The "actual" value is not useless, but the value
the resolution has actually been set to.  The OS just doesn't support
arbitrary values for the period.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1


On 3/27/2012 2:20 PM, Corinna Vinschen wrote:

On Mar 27 14:01, Ken Brown wrote:

I just tried it, and the list of DLLs that couldn't be rebased does
indeed appear in setup.log.full.  I also get a warning from
setup.exe about the exit code of autorebase.bat, which some users
might interpret as meaning that autorebase.bat failed.  I wonder if
you'd be better off suppressing this warning somehow.


That's unexpected.  The fact that rebase prints the warnings doesn't
mean it returns with a non-0 exit code.
In fact, as far as I can see, the only reason to fail with a non-0 exit
code after printing the "The following DLLs couldn't be rebased"
messages would be if saving the database failed, which also means
you should see a message "failed to create temporary rebase database"
or "failed to write rebase database" in the log.  If such a message
is not printed, I don't understand where the non-0 exit code is
coming from.


There's no such message, and /etc/rebase.db.i386 does have the same 
timestamp as I find at the end of setup.log.  Here are the last few 
lines of setup.log:


2012/03/27 13:48:01 Extracting from 
file://C:\downloads\cygwin/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/python/python-crypto/python-crypto-2.5-1.tar.bz2

2012/03/27 13:48:01 Changing gid back to original
2012/03/27 13:48:01 running: cmd.exe /c 
C:\cygwin\etc\postinstall\autorebase.bat

2012/03/27 13:48:07 abnormal exit: exit code=-1073741819
2012/03/27 13:48:07 Changing gid to Administrators
2012/03/27 13:48:19 note: Installation Complete
2012/03/27 13:48:19 Ending cygwin install

And the last part of setup.log.full is:

2012/03/27 13:48:01 running: cmd.exe /c 
C:\cygwin\etc\postinstall\autorebase.bat


The following DLLs couldn't be rebased because they were in use:
  /usr/lib/gio/modules/cygdconfsettings.dll
  [...]
  /usr/bin/cygICE-6.dll
2012/03/27 13:48:07 abnormal exit: exit code=-1073741819
2012/03/27 13:48:07 Changing gid to Administrators
2012/03/27 13:48:19 note: Installation Complete
2012/03/27 13:48:19 Ending cygwin install

Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 27 14:32, Ken Brown wrote:
> On 3/27/2012 2:20 PM, Corinna Vinschen wrote:
> >On Mar 27 14:01, Ken Brown wrote:
> >>I just tried it, and the list of DLLs that couldn't be rebased does
> >>indeed appear in setup.log.full.  I also get a warning from
> >>setup.exe about the exit code of autorebase.bat, which some users
> >>might interpret as meaning that autorebase.bat failed.  I wonder if
> >>you'd be better off suppressing this warning somehow.
> >
> >That's unexpected.  The fact that rebase prints the warnings doesn't
> >mean it returns with a non-0 exit code.
> >In fact, as far as I can see, the only reason to fail with a non-0 exit
> >code after printing the "The following DLLs couldn't be rebased"
> >messages would be if saving the database failed, which also means
> >you should see a message "failed to create temporary rebase database"
> >or "failed to write rebase database" in the log.  If such a message
> >is not printed, I don't understand where the non-0 exit code is
> >coming from.
> 
> There's no such message, and /etc/rebase.db.i386 does have the same
> timestamp as I find at the end of setup.log.  Here are the last few
> lines of setup.log:
> 
> 2012/03/27 13:48:01 Extracting from 
> file://C:\downloads\cygwin/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/python/python-crypto/python-crypto-2.5-1.tar.bz2
> 2012/03/27 13:48:01 Changing gid back to original
> 2012/03/27 13:48:01 running: cmd.exe /c
> C:\cygwin\etc\postinstall\autorebase.bat
> 2012/03/27 13:48:07 abnormal exit: exit code=-1073741819
> 2012/03/27 13:48:07 Changing gid to Administrators
> 2012/03/27 13:48:19 note: Installation Complete
> 2012/03/27 13:48:19 Ending cygwin install
> 
> And the last part of setup.log.full is:
> 
> 2012/03/27 13:48:01 running: cmd.exe /c
> C:\cygwin\etc\postinstall\autorebase.bat
> 
> The following DLLs couldn't be rebased because they were in use:
>   /usr/lib/gio/modules/cygdconfsettings.dll
>   [...]
>   /usr/bin/cygICE-6.dll
> 2012/03/27 13:48:07 abnormal exit: exit code=-1073741819

Hmm.  The batch file is very simple:

  @echo off
  rem Postinstall scripts are always started from the Cygwin root dir
  rem so we can just call dash from here
  path .\bin;%path%
  dash -c "/bin/rebaseall -p"

That's all.  -1073741819 is the decimal notation of the status code
0xC005, STATUS_ACCESS_VIOLATION.  Where on earth is that coming
from?  Do you have a dash.exe.stackdump file in / by any chance?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

2012-03-27 Thread Christian Franke


Corinna Vinschen wrote:

On Mar 27 20:01, Christian Franke wrote:

Corinna Vinschen wrote:

On Mar 26 19:00, Christian Franke wrote:

Corinna Vinschen wrote:

I see your point, but what bugs me a bit is the fact that
clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
always return the same value coarsest, regardless what value has been set.

If clock_setres was called and succeeded, then clock_getres(.)
should return the value set before.

If clock_setres was not called, the coarsest value is IMO the only
value that can be guaranteed.

The actual value returned by NtQueryTimerResolution is simply
useless in this context: It is the minimum of all resolutions
currently set by all running processes. It may change at any time.
There is apparently no way the query the current setting of the
current process.

Uh, right, I misunderstood.  I reverted the change to clock_setres.

Sorry, I probably forgot to mention that NtSetTimerResolution
returns the same useless actual value than NtQueryTimerResolution.

I would suggest:

 status = NtSetTimerResolution (period, TRUE,&actual);
 if (!NT_SUCCESS (status))
   { ... return -1; }
  -  minperiod = actual;
  +  minperiod = period;

But that's not right.  The "actual" value is not useless, but the value
the resolution has actually been set to.


No, again this is the minimum of all resolutions currently set by all 
processes.




   The OS just doesn't support
arbitrary values for the period.



Yes - but in 'actual' a smaller value than the value set for the current 
process may be returned.


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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

2012-03-27 Thread Karl M


 

On Mar 27 09:35, Karl M wrote:
> 
> 
> 
> > Can it at least complain about in-use files?
> 
> It does in the setup.log output. Other than that, it can't since it
> has no window to do output to.
> 
> 
> But setup will still alert the user about running cygwin processes, true?
 
I wasn't aware that setup alerts the user about running cygwin processes.
 

Sorry, I wasn't aware that it only complained if some DLLs could not be 
replaced.

 

But if the autorebase returned a non-zero code when some DLLs could not be 
relocated

I think that would be helpful. Especially because non-zero postinstall script 
returns are so rare.

 

Thanks,

 

...Karl   

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: syslog-ng service fails: Error starting a service: QueryServiceStatus: Win32 error 1062

2012-03-27 Thread Ulrich Schmidt

Oh yes - you are right. And I had already seen it before I issued my record,
sorry. But when I started the description I thought I would get somewhere and
forgot about your experience. It is the same problem; after deleting
syslog-ng.persist I could start the service. Thank you.
Ulrich

Ken Brown  hat am 27. März 2012 um 17:40 geschrieben:

> On 3/27/2012 7:47 AM, Ulrich Schmidt wrote:
> > $ cygrunsrv -S syslog-ng
> > cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
> > The service was not started.
>
> This might be a known problem with syslog-ng.  See the thread starting at
>
>http://cygwin.com/ml/cygwin/2011-10/msg00449.html
>
> Ken
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

--
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: binutils-2.22.51-2

I've made a new version of binutils available for installation.  This is
a refresh against CVS.  The contents of the NEWS file for this snapshot
are in /usr/share/doc/Cygwin/binutils-2.22.51-2.README .  However, there
is no reason to read that file.  The only real change is to reset the
auto-image-base for dlls as discussed here:

http://cygwin.com/ml/cygwin-apps/2012-03/msg00019.html

This change will stop annoying collisions with cygwin1.dll for newly
created dlls which use the --enable-auto-image-base option.  With this
release the base is increased.  Additionally --enable-auto-image-base
now takes an optional argument which controls where the base starts.


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

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 web address.

--
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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

On Mar 27 15:12, Ken Brown wrote:
> On 3/27/2012 2:48 PM, Corinna Vinschen wrote:
> >On Mar 27 14:32, Ken Brown wrote:
> >>The following DLLs couldn't be rebased because they were in use:
> >>   /usr/lib/gio/modules/cygdconfsettings.dll
> >>   [...]
> >>   /usr/bin/cygICE-6.dll
> >>2012/03/27 13:48:07 abnormal exit: exit code=-1073741819
> >
> >Hmm.  The batch file is very simple:
> >
> >   @echo off
> >   rem Postinstall scripts are always started from the Cygwin root dir
> >   rem so we can just call dash from here
> >   path .\bin;%path%
> >   dash -c "/bin/rebaseall -p"
> >
> >That's all.  -1073741819 is the decimal notation of the status code
> >0xC005, STATUS_ACCESS_VIOLATION.  Where on earth is that coming
> >from?  Do you have a dash.exe.stackdump file in / by any chance?
> 
> No.  And I just tried running those commands by hand in a cmd shell,
> with no error messages.

I think I fixed that.  For some reason, if I omit the -c option to dash,
the weird STATUS_ACCESS_VIOLATION doesn't occur.  I uploaeded a new
_autorebase package with that change.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

On Mar 27 20:59, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Mar 27 20:01, Christian Franke wrote:
> >>Corinna Vinschen wrote:
> >>>On Mar 26 19:00, Christian Franke wrote:
> Corinna Vinschen wrote:
> >I see your point, but what bugs me a bit is the fact that
> >clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
> >always return the same value coarsest, regardless what value has been 
> >set.
> If clock_setres was called and succeeded, then clock_getres(.)
> should return the value set before.
> 
> If clock_setres was not called, the coarsest value is IMO the only
> value that can be guaranteed.
> 
> The actual value returned by NtQueryTimerResolution is simply
> useless in this context: It is the minimum of all resolutions
> currently set by all running processes. It may change at any time.
> There is apparently no way the query the current setting of the
> current process.
> >>>Uh, right, I misunderstood.  I reverted the change to clock_setres.
> >>Sorry, I probably forgot to mention that NtSetTimerResolution
> >>returns the same useless actual value than NtQueryTimerResolution.
> >>
> >>I would suggest:
> >>
> >> status = NtSetTimerResolution (period, TRUE,&actual);
> >> if (!NT_SUCCESS (status))
> >>   { ... return -1; }
> >>  -  minperiod = actual;
> >>  +  minperiod = period;
> >But that's not right.  The "actual" value is not useless, but the value
> >the resolution has actually been set to.
> 
> No, again this is the minimum of all resolutions currently set by
> all processes.
> 
> 
> >   The OS just doesn't support
> >arbitrary values for the period.
> >
> 
> Yes - but in 'actual' a smaller value than the value set for the
> current process may be returned.

Hmpf, ok.  Boy is that ugly.  Is there a chance that actual is bigger
than period?  In that case we should perhaps set minperiod like this:

  minperiod = MAX (actual, period);


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

2012-03-27 Thread Christian Franke


Corinna Vinschen wrote:

On Mar 27 20:59, Christian Franke wrote:

Corinna Vinschen wrote:

On Mar 27 20:01, Christian Franke wrote:

Corinna Vinschen wrote:

On Mar 26 19:00, Christian Franke wrote:

Corinna Vinschen wrote:

I see your point, but what bugs me a bit is the fact that
clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
always return the same value coarsest, regardless what value has been set.

If clock_setres was called and succeeded, then clock_getres(.)
should return the value set before.

If clock_setres was not called, the coarsest value is IMO the only
value that can be guaranteed.

The actual value returned by NtQueryTimerResolution is simply
useless in this context: It is the minimum of all resolutions
currently set by all running processes. It may change at any time.
There is apparently no way the query the current setting of the
current process.

Uh, right, I misunderstood.  I reverted the change to clock_setres.

Sorry, I probably forgot to mention that NtSetTimerResolution
returns the same useless actual value than NtQueryTimerResolution.

I would suggest:

 status = NtSetTimerResolution (period, TRUE,&actual);
 if (!NT_SUCCESS (status))
   { ... return -1; }
  -  minperiod = actual;
  +  minperiod = period;

But that's not right.  The "actual" value is not useless, but the value
the resolution has actually been set to.

No, again this is the minimum of all resolutions currently set by
all processes.



   The OS just doesn't support
arbitrary values for the period.


Yes - but in 'actual' a smaller value than the value set for the
current process may be returned.

Hmpf, ok.  Boy is that ugly.


Yes, aka broken by design :-)

There should be a function to query the actual setting for the current 
process only. But there is none.




   Is there a chance that actual is bigger
than period?  In that case we should perhaps set minperiod like this:

   minperiod = MAX (actual, period);


According to some experiments this can only happen if period < finest. 
In this case NtSetTimerResolution also succeeds and returns actual == 
finest.


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: [ANNOUNCEMENT] Updated: rebase-4.1.0-1