headers
Marek Telgarsky | 1 Oct 2006 01:36

courier auth+imap

Hello,

I've been able to compile Courier auth+imap under Cygwin. This is 
courier-authlib-0.58 and courier-imap-4.1.1.20060630.
Some details from the compile:

Besides the more obvious packages like gcc, perl, etc, courier-auth requires the
minires-devel package.

for auth:
./configure --with-mailuser=SYSTEM --with-mailgroup=SYSTEM --with-db=gdbm

for imap:
./configure --with-waitfunc=wait --disable-auth-check --with-db=gdbm

Prior to make, I had to change the ./makedat/Makefile in each project. The
following line:

noinst_PROGRAMS = makedatprog

has to be:

noinst_PROGRAMS = makedatprog$(EXEEXT)

Also, in the main Makefile for courier-imap, the following lines:

binPROGRAMS = imapd pop3d maildirmake maildiracl deliverquota maildirkw
sbinPROGRAMS = imaplogin pop3login
libexecPROGRAMS = makedatprog couriertcpd
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Foulk | 1 Oct 2006 02:27

Re: New windows from cygwin in ssh

> >Why when I'm asking about this probably new feature of cygwin sshd, all
> >list become silent? :) Nobody remembers what changes were in cygwin sshd
> >since 01.03.2005? :) Or this information is about to be secret and I
> >have to understand it from sources only?
> 
> It's much simpler than that:  We just don't like you.
> 
> cgf
> 
> 

This would be funny if this list wasn't so surly at times.
Permalink | Reply | 2 comments |
headers
Angelo Graziosi | 1 Oct 2006 02:35
Picon
Picon

Problems with patched gnu make ? (was:Need Volunteers to test patch for gnu make)


I use this since Sep 08, but now I have found a problem with
http://www.cmake.org/files/cygwin/make.exe.

When I build GFortran with this version of make it fails:
--------------------------------------------------------
...
rm -f ./libgcov.a
ar  rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o
libgcc/./_gcov_merge_single.o libgcc/./_gcov_merge_delta.o
libgcc/./_gcov_fork.o libgcc/./_gcov_execl.o libgcc/./_gcov_execlp.o
libgcc/./_gcov_execle.o libgcc/./_gcov_execv.o libgcc/./_gcov_execvp.o
libgcc/./_gcov_execve.o libgcc/./_gcov_interval_profiler.o
libgcc/./_gcov_pow2_profiler.o libgcc/./_gcov_one_value_profiler.o
ranlib ./libgcov.a
make[4]: Leaving directory
`/home/Angelo/Downloads/GFortran/gcc/.build/gcc'
make[3]: *** No rule to make target `cpp.texi', needed by
`doc/cpp.info'.  Stop.
make[3]: Leaving directory
`/home/Angelo/Downloads/GFortran/gcc/.build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/Angelo/Downloads/GFortran/gcc/.build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/Angelo/Downloads/GFortran/gcc/.build'
make: *** [all] Error 2 
....
--------------------------------------------------------

Using the official version in Cygwin of make (make-3.81-1) the build
(Continue reading)

Permalink | Reply | 0 comments |
headers
René Berber | 1 Oct 2006 02:56
Picon
Favicon

Re: courier auth+imap

Marek Telgarsky wrote:

[snip]
> This leads me to actually running the server, and my question for the list: Does
> anyone have experience with that under Cygwin? 

No experience, but I recently did try to use imap-2006a (the latest UW IMAP release) and it compiles cleanly
with no changes but after running for a while it hits problems with advisory locking (which doesn't exist
in Cygwin since it is using Windows mandatory locking).

> Things (like the auth daemon) seem to be failing silently.

Installed as service?

Running under what user & what Windows version?

No messages in the event log (or syslog if you are using it)?

Last year there was some report similar to yours:

  http://permalink.gmane.org/gmane.os.cygwin/62823

but I've heard no comments about experience actually running the server.

Dovecot is another server that compiles easily, but their Wiki seems to point to the same problem with
advisory locking under Cygwin.

As you can see, there are a few of us interested in this subject but, as you say, there isn't much experience reported.
--

-- 
René Berber
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Hall (Cygwin | 1 Oct 2006 03:23
Favicon

Re: Cernlib for cygwin

João Esteves wrote:
> Hello:
> 
> Does anyone knows of a cernlib package for cygwin?

This answers the question of whether it's part of the Cygwin distribution, no?

<http://cygwin.com/cgi-bin2/package-grep.cgi?grep=cernlib>

--

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746
Permalink | Reply | 0 comments |
headers
Larry Hall (Cygwin | 1 Oct 2006 03:29
Favicon

Re: New windows from cygwin in ssh

Richard Foulk wrote:
>>> Why when I'm asking about this probably new feature of cygwin sshd, all
>>> list become silent? :) Nobody remembers what changes were in cygwin sshd
>>> since 01.03.2005? :) Or this information is about to be secret and I
>>> have to understand it from sources only?
>> It's much simpler than that:  We just don't like you.
>>
>> cgf
>>
>>
> 
> This would be funny if this list wasn't so surly at times.
> 

Don't call me Shirley.

(Am I dating myself with this reference? ;-) )

--

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746
Permalink | Reply | 1 comment |
headers
Christopher Faylor | 1 Oct 2006 03:33
Favicon

Re: Similar Bash 3.1.18 CR/LF Problem

On Sat, Sep 30, 2006 at 09:42:39AM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to mwoehlke on 9/29/2006 12:14 PM:
>> Wilks, Dan wrote:
>>> So we just got the short-end?  A long(?) standing behavior of cygwin
>>> and DOS paths and a recent change to bash that eliminates support for
>>> \r's.  I guess we were living on the edge of something that wasn't
>>> supposed to work at all and didn't even know it.  :/
>>>
>>> We'll try to figure out some workaround for our environment.  I just
>>> wish going "pure cygwin" was an option.
>> 
>> Well, as we like to say here, http://cygwin.com/acronyms/#PTC. Since
>> Eric is currently amenable to adding a shopt to bash, you have the
>> option of implementing it yourself and submitting the patch for upstream
>> consideration.
>
>I also mentioned that I am toying with the idea of a cygwin-specific patch
>that converts all script path to posix before opening them (a'la
>cygwin_conv_to_full_posix_path in <sys/cygwin.h>); at which point DOS
>paths to a text mode mount would inherit text mode behavior, but DOS paths
>to a binary mode mount would still remain binary.  At any rate, I hope to
>post bash-3.1-9 next week with something a little nicer for ignoring \r
>and working with DOS paths, without too much of a penalty to people like
>me that avoid \r and use POSIX paths at all costs in the first place.

If you are not going to support CRLF line endings, I really don't see
any point in going overboard in trying to support MS-DOS path names.
(Continue reading)

Permalink | Reply | 20 comments |
headers
Larry Hall (Cygwin | 1 Oct 2006 03:53
Favicon

Re: Install hangs

Eric Mader wrote:
> Larry Hall (Cygwin) wrote:
>> Eric Mader wrote:
>>>
>>> In the process of messing around w/ the scripts in /etc/postinstall I 
>>> ran into a problem w/ find. In an attempt to find scripts where both 
>>> the '.sh' and the '.sh.done' versions existed I typed the command:
>>>
>>> find . -name "*.sh" -exec ls \{\}.done \;
>>>
>>> This caused some strange error messages, and left some stalled 
>>> processes running 'find' behind. (I can't run this command now 
>>> because the successful run of setup.exe cleaned them all up, but 
>>> here's the output of a similar use of '-exec' in find:
>>>
>>> $ find . -name "*.sh.done" -exec ls \{\} \;
>>>     197 [main] find 16764 fhandler_dev_zero::fixup_mmap_after_fork: 
>>> requested 0x
>>> 430000 != 0x0 mem alloc base 0x430000, state 0x2000, size 1040384, 
>>> Win32 error 4
>>> 87
>>>     543 [main] find 16764 c:\cygwin\bin\find.exe: *** fatal error - 
>>> c:\cygwin\bi
>>> n\find.exe: *** recreate_mmaps_after_fork_failed
>>>
>>> It takes quite a long time to get a command prompt back after these 
>>> error messages, and it leaves behing a stalled process.
>>>
>>> Is this releated somehow to my many failed attempts to run setup.exe, 
>>> or is it a know problem w/ find?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Lee | 1 Oct 2006 04:42
Picon
Favicon

Re: mssing packages for cygwin


>According to Tom Lee on 9/29/2006 10:23 PM:
> > Eric,
>
>http://cygwin.com/acronyms/#PCYMTNQREAIYR - list policy is that you don't
>repeat raw email addresses, please

Sorry about it. Will take care of it.

>
> > when I copy cpp.exe and all cygwin related dll to another computer, I
> > got the error:
> >  cpp: installation problem, cannot exec 'cc1': No such file or directory
>
>Are you SURE you copied all things cygwin related?

Just checked if I just want to run cpp and copy
C:/cygwin/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe over, it works fine.
thanks for the help.

I got one more question.
I read mount and cygpath manual, but still not sure if there is a way that I 
can
run
tar cvf test.tar c:/test or
tar cvf test.tar c:\test

does cygwin allow such a command in dos shell if I run some special command 
with mount and cygpath?
(Continue reading)

Permalink | Reply | 14 comments |
headers
Eric Blake | 1 Oct 2006 04:54
Gravatar

Re: mssing packages for cygwin


According to Tom Lee on 9/30/2006 8:42 PM:
> 
> Just checked if I just want to run cpp and copy
> C:/cygwin/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe over, it works fine.
> thanks for the help.

Not a problem, although cygcheck output would have sped things up.

> 
> I got one more question.
> I read mount and cygpath manual, but still not sure if there is a way
> that I can
> run
> tar cvf test.tar c:/test or
> tar cvf test.tar c:\test
> 

Actually, from either a DOS or a bash (or other cygwin) shell, you can do:

tar cvf test.tar /cygdrive/c/test

Get used to POSIX paths - cygwin is a Linux emulation for Windows, and
POSIX paths will work in more places than DOS paths (not to mention that
backslashes are a pain to use on the command line with regards to proper
quoting rules between the two different styles of shells, but forward
slashes work great in both cases).

--
Life is short - so eat dessert first!
(Continue reading)

Permalink | Reply | 10 comments |

Gmane