Hello,
The following program (see below) is working properly under plain
1.7.18. With all the snapshots afterwards (including
the current one 20130508), it fails after day=19, looping forever (it
seems). I use XP.
Regards,
Denis Excoffier.
% cat foo.c
#include
#include
int
main ()
{
in
2013/5/8 NightStrike :
> How did you install the cross compiler without the dependencies
> picking up the headers package?
Well, installing the cross-compiler I only get
the following 4 dependencies:
mingw64-x86_64-binutils(20130314-1)
Binutils for Win64 toolchain
Required by: mingw64
2013/5/8 NightStrike:
> How did you install the cross compiler without the dependencies
> picking up the headers package?
Well, installing the cross-compiler I only get
the following 4 dependencies:
mingw64-x86_64-binutils(20130314-1)
Binutils for Win64 toolchain
Required by: mingw64-
On May 10 11:13, Warren Young wrote:
> On 5/10/2013 08:31, Christopher Faylor wrote:
> >
> >I don't know what Corinna's return has to do with this.
>
> http://cygwin.com/ml/cygwin-patches/2013-q2/msg00011.html
>
> The open question is whether we're going to switch all the DOCTOOL
> tags and *.sgm
Providing the functionality of some obscure, barely used project is not
a stated goal for Cygwin. No one here is interested in adapting
ourselves to people's expectations for the project if the expectations
have nothing to do with the goals of the project.
??
unxutils is just a bundle of win32
On Mon, May 13, 2013 at 08:44:50AM -0600, Daniel Jensen wrote:
>>Providing the functionality of some obscure, barely used project is not
>>a stated goal for Cygwin. No one here is interested in adapting
>>ourselves to people's expectations for the project if the expectations
>>have nothing to do w
On May 13 09:08, Denis Excoffier wrote:
> Hello,
>
> The following program (see below) is working properly under plain
> 1.7.18. With all the snapshots afterwards (including
> the current one 20130508), it fails after day=19, looping forever
> (it seems). I use XP.
>
> Regards,
>
> Denis Excoffi
On May 13 17:36, Corinna Vinschen wrote:
> On May 13 09:08, Denis Excoffier wrote:
> > Hello,
> >
> > The following program (see below) is working properly under plain
> > 1.7.18. With all the snapshots afterwards (including
> > the current one 20130508), it fails after day=19, looping forever
> >
On 2013-05-13 17:49, Corinna Vinschen wrote:
> On May 13 17:36, Corinna Vinschen wrote:
>> On May 13 09:08, Denis Excoffier wrote:
>>> Hello,
>>>
>>> The following program (see below) is working properly under plain
>>> 1.7.18. With all the snapshots afterwards (including
>>> the current one 2013
On May 13 18:41, Denis Excoffier wrote:
> On 2013-05-13 17:49, Corinna Vinschen wrote:
> > Erm... hang on. Is that really a problem? 2147483647 is 0x7fff,
> > which is the maximum you get with a 4 byte time_t (== signed long)
> > anyway. If you switch the date to 2038-01-20, the value will b
cgf, I've been using cygwin off and on for ~14 years and I'm aware what
it is and is not. Getting defensive and huffy over a rhetorical (not
technical/internal) comparison of cygwin to other "collections of tools
which provide [with varying completeness] a Linux look and feel
environment for Wi
Hi,
I'm trying to bring up Cygwin in a Windows 8 machine and see this error:
1 [main] bash 3680 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.
Cygwin Version: CYGWIN_NT-6.2
Windows Version: Windows 8, Version 6.2 (Build 9200)
What is the impact of this? Is there a work-around?
Tha
Hello,
The current version of the mkgroup utility does not seem to care
about group members when generating the group file (either out of
domain or locally). I wonder what prevented it from using
NetGroupGetUsers()/NetLocalGroupGetMembers() to list the group
users after that last colon.
Thanks,
On May 13 12:11, Vasavi Levendel wrote:
> Hi,
>
> I'm trying to bring up Cygwin in a Windows 8 machine and see this error:
>
> 1 [main] bash 3680 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.
>
> Cygwin Version: CYGWIN_NT-6.2
> Windows Version: Windows 8, Version 6.2 (Build 9200)
>
On May 13 17:43, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hello,
>
> The current version of the mkgroup utility does not seem to care
> about group members when generating the group file (either out of
> domain or locally). I wonder what prevented it from using
> NetGroupGetUsers()/NetLocalG
> so is extra work for no gain.
But what if I need to see who's in a particular group?
Then when I use getgrgid() / getgrnam() (or equivalent), I get an empty list.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
I've updated clamav to the latest version 0.97.8
Release Notes
0.97.8: This release addresses several reported potential security bugs.
0.97.7: This is a bugfix release.
See http://www.clamav.net/ or http://freecode.com/projects/clamav/
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler
On May 13 17:53, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > so is extra work for no gain.
>
> But what if I need to see who's in a particular group?
>
> Then when I use getgrgid() / getgrnam() (or equivalent), I get an empty list.
In that case, your expectations of the getgrXXX functions ar
I may have put it a bit incorrectly,
> In that case, your expectations of the getgrXXX functions are wrong.
but I don't think so. I am looking if a user belongs to a group,
either as their primary or secondary one. So when using getgrXXX()
I check to see if a user (whose primary, passwd-supplie
On May 13 18:17, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> I may have put it a bit incorrectly,
>
> > In that case, your expectations of the getgrXXX functions are wrong.
>
> but I don't think so. I am looking if a user belongs to a group,
> either as their primary or secondary one. So when
On May 13 20:23, Corinna Vinschen wrote:
> On May 13 18:17, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > I may have put it a bit incorrectly,
> >
> > > In that case, your expectations of the getgrXXX functions are wrong.
> >
> > but I don't think so. I am looking if a user belongs to a group,
> I'm shuddering to think of the memory requirements if all gr_mem
> fields are filled in a bigger company.
Well, for supplementary groups (which it was supposed to be used for)
that does not actually look like very overwhelming...
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> you can also use the POSIX function
Hmm.. It is listed as BSDism, wherever I looked..
> getgrouplist, which is implemented in Cygwin
Anyways, thanks much for the hint, I'll look into it!
Anton Lavrentiev
Contractor NIH/NLM/NCBI
On May 13 18:30, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > I'm shuddering to think of the memory requirements if all gr_mem
> > fields are filled in a bigger company.
>
> Well, for supplementary groups (which it was supposed to be used for)
> that does not actually look like very overwhelmin
On May 13 18:36, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > you can also use the POSIX function
>
> Hmm.. It is listed as BSDism, wherever I looked..
s/POSIX/UNIX/ Anyway, I was using "POSIX" in place of "not Windows".
Corinna
--
Corinna Vinschen Please, send mails reg
Hello,
Per a hint I've got earlier today from this list (and which I appreciate!),
I've tried to use getgrouplist() to obtain group information about a user.
There's a problem with that.
I notice that the actual behavior of this call deviates from
what's documented: nowhere in the documentation
I inadvertently dumped a binary stream to the terminal and it froze
mintty. When I tried to kill the process dumping the data, it
wouldn't die, even when using -9 switch. When I used Process Explorer
to kill it, it died and mintty resumed working.
I narrowed the stream down to 370 'lines' by cat
On 13 May 2013 22:35, Adrian H wrote:
> I inadvertently dumped a binary stream to the terminal and it froze
> mintty. When I tried to kill the process dumping the data, it
> wouldn't die, even when using -9 switch. When I used Process Explorer
> to kill it, it died and mintty resumed working.
>
>
On 5/10/2013 17:19, Linda Walsh wrote:
the PDF code font is less than optimal..
The current doco PDFs are generated through dblatex, via xmlto. I don't
know if it's possible to reach through two generators to affect final
output fonts.
I suspect part of this is due to the weirdness of font
On 2013-05-13 17:04, Warren Young wrote:
I know how to fix this when you generate PDF from DocBook via XSL-FO
(e.g. xsltproc and Apache FOP) but that brings in its own bag of
problems. For one biggie, all the XSL-FO processors depend on Java.
Fop is available in Ports; it is used to generate t
On Mon, May 13, 2013 at 5:45 PM, Andy Koppe wrote:
>
> On 13 May 2013 22:35, Adrian H wrote:
> > I inadvertently dumped a binary stream to the terminal and it froze
> > mintty. When I tried to kill the process dumping the data, it
> > wouldn't die, even when using -9 switch. When I used Process
The following packages have been updated for the Cygwin distribution:
*** vim-7.3.943-1
*** vim-common-7.3.943-1
*** vim-minimal-7.3.943-1 (NEW)
*** xxd-7.3.943-1
*** gvim-7.3.943-1
Vim is an advanced text editor that seeks to provide the power of the
de-facto Unix editor 'Vi', with a more compl
The following packages have been updated for the Cygwin distribution:
*** libboost1.53-1.53.0-2
*** libboost-devel-1.53.0-2
*** libboost_python1.53-1.53.0-2
*** libboost_python-devel-1.53.0-2
*** libboost_python3_1.53-1.53.0-2
*** libboost_python3-devel-1.53.0-2
Boost provides a large collection
On Mon, May 13, 2013 at 10:45:17PM +0100, Andy Koppe wrote:
>On 13 May 2013 22:35, Adrian H wrote:
>> I inadvertently dumped a binary stream to the terminal and it froze
>> mintty. When I tried to kill the process dumping the data, it
>> wouldn't die, even when using -9 switch. When I used Proces
On 14 May 2013 01:23, Jack Adrian Zappa wrote:
> On Mon, May 13, 2013 at 5:45 PM, Andy Koppe wrote:
>>
>> On 13 May 2013 22:35, Adrian H wrote:
>> > I inadvertently dumped a binary stream to the terminal and it froze
>> > mintty. When I tried to kill the process dumping the data, it
>> > wouldn't
On Tue, May 14, 2013 at 05:39:17AM +0100, Andy Koppe wrote:
>On 14 May 2013 01:23, Jack Adrian Zappa wrote:
>>In any case, how does Linux deal with this issue?
>
>I don't know. A buffer on the terminal's side of the pty? Automatic
>deadlock detection in the kernel, causing one of the blocking wri
36 matches
Mail list logo
