headers
Reini Urban | 1 Sep 2010 01:16
Picon
Gravatar

Re: [ANNOUNCEMENT] Updated: cygwin-1.7.7-1

Corinna Vinschen schrieb:
> - Fix long-standing problem that calling select(2) on /dev/windows hangs
>    for timeout, if no new messages arrived in the message queue since the
>    last call to select.

Yeah! Will test tcltk immediately and report back. This was my only 
blocker. Maybe I can even persuade pTk to emit a fine cygwin wish
with native GDI for git, insight and friends.
--

-- 
Reini Urban
Permalink | Reply | 0 comments |
headers
Michael Ludwig | 1 Sep 2010 01:37
Picon
Picon

Re: Building Mutt: configure: invalid value of canonical build

Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200):
> On 30.08.2010 23:52, Michael Ludwig wrote:
> >The mutt mail reader shipping with Cygwin does not have SMTP
> >enabled, which I'd like to give a try. So I tried to build mutt,
> >but encountered problems.
> 
> [... long whine about non-working build snipped ...]

Whatever pills you've taken to discern lengthiness and whininess, I'd
definitely recommend you stop taking them, especially when driving or
writing email.

[ irrelevant advice snipped ]

--

-- 
Michael Ludwig
Permalink | Reply | 5 comments |
headers
Michael Ludwig | 1 Sep 2010 01:42
Picon
Picon

Re: Building Mutt: configure: invalid value of canonical build

Csaba Raduly schrieb am 31.08.2010 um 09:17 (+0200):
> On Mon, Aug 30, 2010 at 11:52 PM, Michael Ludwig  wrote:
> >
> > It is only after receiving an error because of the script's failure
> > to guess the build system that I added the --build option to
> > configure. But obviously I didn't fill in a correct value. What
> > should I try?
> 
> Try:  i686-pc-cygwin
> 
> This is what gcc -v reports.

Thanks, I didn't know that. Unfortunately, the outcome is identical:

          \,,,/
          (o o)
------oOOo-(_)-oOOo------
cd /usr/src
cp -r mutt-1.5.20-1/ mutt-1.5.20-1.milu     # copy mutt source package
cd mutt-1.5.20-1.milu
touch install-sh                            # else you'll get an error
touch config.sub                            # ditto
./configure --build=i686-pc-cygwin --prefix=/usr/local/mutt \
  --enable-imap --enable-smtp --enable-hcache --with-regex --with-ssl
# configure output snipped
checking build system type...
configure: error: invalid value of canonical build
-------------------------

Might there be something wrong with the source package for mutt?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Andree | 1 Sep 2010 02:17
Picon
Picon

Re: Building Mutt: configure: invalid value of canonical build

Am 01.09.2010, 01:37 Uhr, schrieb Michael Ludwig:

> Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200):
>> On 30.08.2010 23:52, Michael Ludwig wrote:
>> >The mutt mail reader shipping with Cygwin does not have SMTP
>> >enabled, which I'd like to give a try. So I tried to build mutt,
>> >but encountered problems.
>>
>> [... long whine about non-working build snipped ...]
>
> Whatever pills you've taken to discern lengthiness and whininess, I'd
> definitely recommend you stop taking them, especially when driving or
> writing email.

It's your problem if you don't like the answers. Your "fix" attempts break  
the build system further, meaning that: if you "touch config.sub", you  
create a blank canonicalization script, so don't complain about  
canonicalization errors or other malfunctions -- you triggered those that  
you caused yourself. You chose the blue pill, asking for blitheness, joy,  
and ignorance.

So to sell you a faint clue of what the red pill might have provided if  
you had so chosen: a *real* config.sub is what should be doing the  
canonicalization -- a blank script won't achieve that. automake  
--add-missing (which is called as part of ./prepare) is what would install  
a set of real config.sub, install-sh, missing, and related scripts.

The question of if the mutt distribution is incomplete is a distinct one -  
and the command line you showed on Monday works fine on a mutt HEAD  
checkout from the Mercurial repo.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Andree | 1 Sep 2010 02:19
Picon
Picon

Re: Building Mutt: configure: invalid value of canonical build

Am 01.09.2010, 01:37 Uhr, schrieb Michael Ludwig:

> Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200):
>> On 30.08.2010 23:52, Michael Ludwig wrote:
>> >The mutt mail reader shipping with Cygwin does not have SMTP
>> >enabled, which I'd like to give a try. So I tried to build mutt,
>> >but encountered problems.
>>
>> [... long whine about non-working build snipped ...]
>
> Whatever pills you've taken to discern lengthiness and whininess, I'd
> definitely recommend you stop taking them, especially when driving or
> writing email.

Sorry, the first edition went out prematurely. Now for the good one:

It's your problem if you don't like the answers. Your "fix" attempts break  
the build system further, meaning that: if you "touch config.sub", you  
create a blank canonicalization script, so don't complain about  
canonicalization errors or other malfunctions -- you triggered those  
yourself. You chose the blue pill, asking for blitheness, joy, and  
ignorance.

So to sell you a faint clue of what the red pill might have provided if  
you had so chosen: a *real* config.sub is what should be doing the  
canonicalization -- a blank script won't achieve that. automake  
--add-missing (which is called as part of ./prepare) is what would install  
a set of real config.sub, install-sh, missing, and related scripts.

The question of if the mutt distribution is incomplete is a distinct one -
(Continue reading)

Permalink | Reply | 3 comments |
headers
Larry Hall (Cygwin | 1 Sep 2010 02:35
Favicon

Re: endless problems with SSHD - bug ??

On 8/18/2010 11:24 PM, Bob Goldberg wrote:
> -----Original Message-----
> From: cygwin-owner
         ^^^^^^^^^^^^
<http://cygwin.com/acronyms/#PCYMTNQREAIYR>  We don't encourage feeding the
spammers around here.  Thanks.

> Sent: Wednesday, August 18, 2010 1:04 PM
> To: cygwin
       ^^^^^^
Ditto.  And actually all these header fields are unnecessary.

<snip>

>
> and as I finish this - just had a hmmmm...
> having cygwin installed on non- C: isn't a problem - is it??

No but this may be relevant:

<http://www.cygwin.com/ml/cygwin/2009-12/msg01052.html>

Make sure you read the whole thread.

--

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brennan Peter Sellner | 1 Sep 2010 04:40
Picon

Re: Support for the TIOCINQ ioctl

On Sat, 28 Aug 2010, Andy Koppe wrote:
> On 27 August 2010 23:31, Brennan Peter Sellner wrote:
>> By any chance, has support for the TIOCINQ ioctl on file descriptors (used
>> to check how many bytes of data are in the input buffer) been added to
>> Cygwin?  It hadn't as of 2004:
>>
>>  http://sourceware.org/ml/cygwin/2004-07/msg00910.html
>
> It's still implemented only for serial devices.

As I suspected.  Thanks for the confirmation.

>> ...but I haven't found any newer references to it.  I'm inferring that it's
>> not supported, as ioctl(fd, TIOCINQ, &available) (where fd is a valid file
>> descriptor, and available is a long) fails, with errno set to 'invalid
>> argument'.  I'm running Cygwin 1.7.6 on Vista.
>>
>> I'm hoping I'm missing something...  Is there an alternative way to check
>> the number of bytes on an fd's input buffer in Cygwin?
>
> What's your use case? And on what sort of fd?
>
> select() of course can tell you whether there are any bytes available
> to be read from an fd, and usually that's all one needs to know.

I'm porting a fair chunk of legacy code that spawns processes in the 
background, provides an emulated tty, and monitors the output, allowing 
remote clients to interact with the backgrounded processes as if they were 
running in a local terminal.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reid Thompson | 1 Sep 2010 05:26

Re: Building Mutt: configure: invalid value of canonical build

Download the mutt 1.5.20 source from the mutt website.. it configures fine for me (had to add some dev libs, etc)
...snip...
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking for iswalnum... yes
checking for iswalpha... yes
checking for iswcntrl... yes
checking for iswdigit... yes
checking for iswgraph... yes
checking for iswlower... yes
checking for iswprint... yes
checking for iswpunct... yes
checking for iswspace... yes
checking for iswupper... yes
checking for iswxdigit... yes
checking for towupper... yes
checking for towlower... yes
checking for mbstate_t... yes
checking for wchar_t functions... yes
checking for nl_langinfo and CODESET... yes
checking for nl_langinfo and YESEXPR... yes
checking for ospcat... none
configure: creating ./config.status
config.status: creating Makefile
config.status: creating contrib/Makefile
config.status: creating doc/Makefile
config.status: creating imap/Makefile
config.status: creating intl/Makefile
config.status: creating m4/Makefile
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andy Koppe | 1 Sep 2010 07:18
Picon

Re: scp and cygwin randomly and automatically converts text files from utf-8 to windows encoding (cp1251)

On 31 August 2010 20:23, rPman wrote:
> It happens when files are copied from cygwin windows machines to any linux
> (tried different versions of ubuntu and gentoo with utf-8 locale).

Cygwin does not change the encoding of file content when copying
files. Cygwin 1.7 does translate file names between the UTF-16
encoding used by Windows and the encoding you have configured in
Cygwin via the LC_ALL, LC_CTYPE or LANG variables.

Please try to desribe in more detail what you were trying to do and
how it went wrong. Also, what version of Cygwin are you using?

> As it is not possible to understand in what cases are re-encoding, sometimes
> enough to add one blank line in a text file that, when the transfer encoding
> has not happened. Just changing the format of a newline (in the source files
> are unix-style \n, but on the linux machine has come to win-style \r\n)

Line endings are a separate issue from character encodings. By
default, directories are mounted in binary mode, where file content is
left alone. Alternatively, they can be mounted in text mode, were line
endings are automatically translated between Windows and Unix style.
See http://www.cygwin.com/cygwin-ug-net/using-textbinary.html for lots
more on that.

Andy
Permalink | Reply | 1 comment |
headers
Harie Ram | 1 Sep 2010 10:00
Picon

Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

---------- Forwarded message ----------
From: Harie Ram <hari.ram66 <at> gmail.com>
Date: Tue, Aug 31, 2010 at 8:11 PM
Subject: Windows File permissions are not being inherited - Cygwin 1.7
- Windows 7
To: cygwin-info <at> cygwin.com

Hi ,

I am currently packaging Cygwin 1.7 i.e. bundling all the files into
an msi and installing it. The requirement is : install only the basic
cygwin packages. Provide permissions to the Cygwin users so that they
can install the packages that they require later.

The issue that I am currently facing is : the modify permissions given
to the INSTALLDIR "C:\Cygwin" using the msi lock permission table is
being inherited through all the subfolders and files. Any new manually
created folders and files anywhere within C:\Cygwin via Windows
explorer or via the Cygwin Bash Shell are inheriting permissions. But
any new installations done by the user by choosing a package from the
Cygwin list are not inheriting the permissions. The installed user who
installs the package has full permissions to delete/modify the folder
and its contents . But the local admin/administrator/system does not
have permissions. It gives an access denied error. These 3 user groups
administrators/system/users are not even being listed in the security
properties of those installed folders.

I have tried editing the /etc/fstab file with the noacl value. Still
its not working. The content of my /etc/fstab file is as follows:
(Continue reading)

Permalink | Reply | 21 comments |

Gmane