Re: [ATTN maintainer] mined

[Thomas Wolff]

Am 18.07.2014 06:39, schrieb Achim Gratz:

The mined directory for both architectures contain temporary files that
apparently sftp has left there (they have the suffix SftpXFR. I
think).  These should be removed, but maybe the transfer script that
moves the files from the upload area could be extended to ignore or
delete such files so they never get distributed to the mirrors.
I had some troubles during my first upload attempts with sftp. I will 
report on details later (after holidays...).

Thomas

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com

Re: Please upload: mined-2014.24-0

[Thomas Wolff]

Am 10.06.2014 20:25, schrieb Yaakov Selkowitz:

On 2014-06-10 06:46, Thomas Wolff wrote:

On 07.06.2014 01:58, Yaakov Selkowitz wrote:

Please note that we have a new upload system:

https://sourceware.org/cygwin-apps/package-upload.html

Thanks, Yaakov; another few question not (yet) in the FAQ:

- After sending an (updated) SSH key, how long would I have to wait
until access works? (The howto says it's handled automatically but it
doesn't work after 15 min).


This is actually what it says:


Requests are handled manually and are acknowledged publicly in response
to email to the cygwin-apps mailing list.


When you see that ack, then you may upload.
Ah, I was confused by the sentence two paragraphs above "It is read by a 
program..." so I thought it was fully automatic, sorry. So I'll be 
patient...

Thanks, Thomas

SSH key for upload access

[Thomas Wolff]

Name: Thomas Wolff
Package: mined
 BEGIN SSH2 PUBLIC KEY 
Comment: "2048-bit RSA, converted from OpenSSH by root@MyBookLive"
B3NzaC1yc2EBIwAAAQEAwMSnVCjNhyiGNhBC/+uPheB4BgG+n7RVmVMiBUJkIy
19fDeLc+0bWgzKLEXl00e0KytGgz6gS3sbDYfv8Ukh9eAnQ9iev31fZmb2UpmXtJCpQHrK
tT3kT3FME+sDX3zYCnpXyOGUP0v0DwUSbRdsMyzH3YKw8XJ60b2gi5PX1wTENR0L4fnXUr
+3Wya4jXUR5d5Az7/Yn9HrBc68qogHn+TwBFZUhXMtlcThKoRBA7160Td7sUeTc1FoqvlD
saneqqnZCgX0qhWZp9V+eNHMnMkNoSwhdDtM+7IRI0doTI7BlzLbiZp1mZOUNWDtdaZwIn
Jbtk5T/FDLw+VIQQWmcQ==
 END SSH2 PUBLIC KEY 

Re: Please upload: mined-2014.24-0

[Thomas Wolff]

On 07.06.2014 01:58, Yaakov Selkowitz wrote:

On 2014-06-06 18:24, Thomas Wolff wrote:

Am 06.06.2014 20:18, schrieb Yaakov Selkowitz:

On 2014-06-06 13:00, Thomas Wolff wrote:

Please upload the release update package for mined:


Please note that we have a new upload system:

https://sourceware.org/cygwin-apps/package-upload.html

Thanks, Yaakov; another few question not (yet) in the FAQ:

- After sending an (updated) SSH key, how long would I have to wait 
until access works? (The howto says it's handled automatically but it 
doesn't work after 15 min).


- How could access from different machines be set up? (which would 
typically generate unique keys...)


- Why is the identical src package expected to appear twice in different 
directories? (I hope the hard link option of sftp is supported - once it 
works - so at least upload can be shortcut but still..)


Thanks
Thomas

SSH key for upload access

[Thomas Wolff]

Name: Thomas Wolff
Package: mined
 BEGIN SSH2 PUBLIC KEY 
Comment: "2048-bit RSA, converted by demsn702@3T29LQ1 from OpenSSH"
B3NzaC1yc2EDAQABAAABAQCeec0gY9huCNMQkWo1x74lqS+YjKXYC/SNHGaEYE
I4u2+ZuDCNeP4Ednvs+E0gpJ8ilEcJMP0MYsnJvngRkQTC9fY++f0XU1cUpJKYwcIFap0I
91XYXJMC4B/qVCzmq7CWUwwZ1GRsblRBpoCXQdOt4vziT43eqXOBQe+vxF1vnRndjCgBmh
8pxx8VaRB7dVX+ctsxFQDJiyg5gfvRautpUU0hZy0MmNsPxf8GXdnsbnDHo8LCLMRZ/MOE
VHWG2DSGPrO2nm3jUwQbj+VddCcR9j2KbGNOw/yq7QpxDNdIlXUJRa5/J195BgVZthLKWw
QaAP8ShJYGHCWlNlJzfVSl
 END SSH2 PUBLIC KEY 

Re: Please upload: mined-2014.24-0

[Thomas Wolff]

Am 06.06.2014 20:18, schrieb Yaakov Selkowitz:

On 2014-06-06 13:00, Thomas Wolff wrote:

Please upload the release update package for mined:


Please note that we have a new upload system:

https://sourceware.org/cygwin-apps/package-upload.html

A few questions not (yet) in the FAQ:
- The page does not mention cygport files, what about them?
- Is there/Should there be an option to transfer files from an external 
upload location (to save upload bandwidth)?

- Is bz2 still accepted?
- Is the new system mandatory?
Kind regards,
Thomas

SSH key for upload access

[Thomas Wolff]

Name: Thomas Wolff
Package: mined
 BEGIN SSH2 PUBLIC KEY 
Comment: "2048-bit RSA, converted from OpenSSH by root@MyBookLive"
B3NzaC1yc2EBIwAAAQEAwMSnVCjNhyiGNhBC/+uPheB4BgG+n7RVmVMiBUJkIy
19fDeLc+0bWgzKLEXl00e0KytGgz6gS3sbDYfv8Ukh9eAnQ9iev31fZmb2UpmXtJCpQHrK
tT3kT3FME+sDX3zYCnpXyOGUP0v0DwUSbRdsMyzH3YKw8XJ60b2gi5PX1wTENR0L4fnXUr
+3Wya4jXUR5d5Az7/Yn9HrBc68qogHn+TwBFZUhXMtlcThKoRBA7160Td7sUeTc1FoqvlD
saneqqnZCgX0qhWZp9V+eNHMnMkNoSwhdDtM+7IRI0doTI7BlzLbiZp1mZOUNWDtdaZwIn
Jbtk5T/FDLw+VIQQWmcQ==
 END SSH2 PUBLIC KEY 

Please upload: mined-2014.24-0

[Thomas Wolff]

Please upload the release update package for mined:


# setup
wget http://towo.net/mined/cygwin/setup.hint

# cygport
wget http://towo.net/mined/cygwin/mined.cygport
# or
wget http://towo.net/mined/cygwin/mined-2014.24-0.cygport

# src
wget http://towo.net/mined/cygwin/mined-2014.24-0-src.tar.bz2

# bin 32 bit
wget http://towo.net/mined/cygwin/32/mined-2014.24-0.tar.bz2
# bin 64 bit
wget http://towo.net/mined/cygwin/64/mined-2014.24-0.tar.bz2


Thank you,
Thomas Wolff

Re: some cygport packaging issues

[Thomas Wolff]

Am 17.08.2013 14:22, schrieb Ken Brown:

On 8/17/2013 4:10 AM, Thomas Wolff wrote:

Am 15.08.2013 10:36, schrieb Corinna Vinschen:

[...]

and drop the DEPEND line.  The deps will be autogenerated anyway.

Amazing, I wonder, how this works reliably (even with packages that do
not use auto-stuff).
If cygport would still consider DEPEND=libncursesw-devel, it could
generate "requires: libncursesw10" rather than "requires: libncurses10"
and setup.hint file could remain the same for 32bit/64bit.
Also, I'd prefer to keep DEPEND=gettext-devel because (as I had reported
earlier) without gettext cygport fails (and hangs).


You're confusing DEPENDand REQUIRES.  The first is for *build* 
dependencies.  It's the second that you want here.  Whatever you put 
in REQUIRES gets added to the automatically generated "requires:".
I didn't confuse them. When I didn't have gettext installed, cygport 
failed (as reported), so as a workaround for that, DEPEND is what I 
needed here (to at least get a warning...) as apparently gettext is a 
build requirement (not for the specific package though, but for cygport 
itself).

Thomas

Re: some cygport packaging issues

[Thomas Wolff]

Am 15.08.2013 10:36, schrieb Corinna Vinschen:

On Aug 14 22:25, Thomas Wolff wrote:

(Packaging algol68g)
There are two warnings at the end:
*** Warning: setup.hint is missing
*** Warning: algol68g.hint is missing

What's the latter (algol68g.hint)?
The file setup.hint is in the same directory as the cygport file where
I invoked cygport. Does it need to be included in the package?

Not at all, if you're using the newer style of cygport files.  Assuming
your package "foo" is a simple package, not having a couple of subpackages,
then it's pretty simple.  If the foo.cygport file starts like this

   NAME="foo"   # Package name
   VERSION="1.2"# Upstream version
   RELEASE=1# Cygwin subversion
   CATEGORY="Text Utils"# String with Cygwin package categories
   SUMMARY="foo SUmmary"# == sdesc in setup.hint
   DESCRIPTION="foo Desc"  # == ldesc in setup.hint

then the setup.hint file will be autogenerated by cygport, including the
"requires:" line.  Apart from the toplevel files (which IMHO really
should not be generated anymore), you 'll find a complete,
distro-suitable subdirectory  "foo-1.2-1/dist/foo", with all files
including the generated setup.hint.
Where the two archives are also copied to the current directory but 
setup.hint is not, giving rise to potential confusion.




...

For the next time, change your file to drop the version from the filename
(just "algol68g.cygport"), and add the missing variables as outlined above:

   NAME="algol68g"
   VERSION="2.7"
   RELEASE=1
   CATEGORY="Devel Interpreters"
   SUMMARY="Algol 68 Genie interpreter"  # Your former DESCRIPTION
   DESCRIPTION="... long text ..."

and drop the DEPEND line.  The deps will be autogenerated anyway.
Amazing, I wonder, how this works reliably (even with packages that do 
not use auto-stuff).
If cygport would still consider DEPEND=libncursesw-devel, it could 
generate "requires: libncursesw10" rather than "requires: libncurses10" 
and setup.hint file could remain the same for 32bit/64bit.
Also, I'd prefer to keep DEPEND=gettext-devel because (as I had reported 
earlier) without gettext cygport fails (and hangs).




The upstream package installs two include files that are not
actually needed on cygwin.
Can cygport be configured to exclude them from packaging?

PKG_IGNORE="file/to/be/excluded another/file/to/be/excluded [...]"

paths are relative to the installation dir ${D}.

This does not work. Error message:
>>> Checking packages for missing or duplicate files
*** Warning: Packages contain duplicate files:
+usr/include/algol68g/a68g-config.h
+usr/include/algol68g/a68g.h
*** ERROR: Packages contain duplicate files:
- as if cygport had tried to add rather than remove those files.




(Packaging mined)

Cygport creates a postinstall file that doesn't seem to be necessary;
can I switch if off?
(I assume the following dependencies to desktop-file-utils and
shared-mime-info would also go away then?)

mined requires: bash desktop-file-utils libncurses10 shared-mime-info

Are you using the mined cygport file I sent to this list a couple of
weeks (months?) ago?  Either way, it would help to see the content of
your cygport file.

See my current upload request.
If I try a "new style" cygport file with mined, it generates a package 
containing only symbolic links, most of them pointing to some local 
directory useless for the distribution. Does "new style" only work with 
"auto-packages"?



Thanks
Thomas

Please upload: mined-2013.23-0

[Thomas Wolff]

Please upload the release update package for mined:


cd mined
#src:
wget http://towo.net/mined/cygwin/mined-2013.23-0-src.tar.bz2
#32bit:
wget http://towo.net/mined/cygwin/32/mined-2013.23-0.tar.bz2
#64bit:
wget http://towo.net/mined/cygwin/64/mined-2013.23-0.tar.bz2


Thank you,
Thomas Wolff

some cygport packaging issues

[Thomas Wolff]

(Packaging algol68g)
There are two warnings at the end:
*** Warning: setup.hint is missing
*** Warning: algol68g.hint is missing

What's the latter (algol68g.hint)?
The file setup.hint is in the same directory as the cygport file where
I invoked cygport. Does it need to be included in the package?
I see some packages generate it as a patch which I think is somewhat weird
as there is no version of it in a typical upstream package;
can it be submitted into the package just as plain file (i.e. does cygport
accept a file to be included not by patch)?



The upstream package installs two include files that are not actually 
needed on cygwin.

Can cygport be configured to exclude them from packaging?


(Packaging mined)

Cygport creates a postinstall file that doesn't seem to be necessary;
can I switch if off?
(I assume the following dependencies to desktop-file-utils and
shared-mime-info would also go away then?)
>>> mined requires: bash desktop-file-utils libncurses10 shared-mime-info



One file to be deployed contains spaces in the filename; cygport chokes
on them:
sed: can't read usr/share/mined/setup_install/win/MinEd: No such file or 
directory

sed: can't read Web: No such file or directory
sed: can't read Manual.url: No such file or directory



When linking, the first attempt fails because somehow cygport suppresses
a gcc link parameter which is included in the makefile ($(SLIB)) so
-lncurses is missing. Error message: *** ERROR: make failed
Interestingly, cygport recovers with another attempt and the original, 
unmodified

makefile rule.
This happens only on 64 Bit; weird - why and how does it do that?

--
Thomas

Re: [RFU] Please upload: algol68g package updates

[Thomas Wolff]

Am 14.08.2013 09:49, schrieb Corinna Vinschen:

On Aug 14 09:40, Thomas Wolff wrote:

...

Update:
#src:
wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2
#32bit:
wget http://towo.net/algol68g/32/algol68g-2.7-0.tar.bz2
#64bit:
wget http://towo.net/algol68g/64/algol68g-2.7-0.tar.bz2

Thanks.  And your setup.hint files?  Their "requires" are probably different.

Oops. Uploaded:

wget http://towo.net/algol68g/setup.hint

Thanks
Thomas

Re: [RFU] Please upload: algol68g package updates

[Thomas Wolff]

Il 8/11/2013 7:02 PM, Thomas Wolff ha scritto:

Please upload the updated packages for algol68g (both 32 and 64 bit):

...


I have managed meanwhile to package algol68g completely with cygport 
(see my other thread which I will respond later) and will provide 
another upload.

Update:
#src:
wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2
#32bit:
wget http://towo.net/algol68g/32/algol68g-2.7-0.tar.bz2
#64bit:
wget http://towo.net/algol68g/64/algol68g-2.7-0.tar.bz2

--
Thomas

Re: [RFU] Please upload: algol68g package updates

[Thomas Wolff]

I had written:

>I think it is really not a good idea to have the same name for archives
>of different packages. No other systems I know does this.

Christopher Faylor responded (for some reason not in my mailbox):

Just to kill two birds with one stone:

http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/x86_64/os/Packages/a/abattis-cantarell-fonts-0.0.10.1-1.fc18.noarch.rpm
http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/i386/os/Packages/a/abattis-cantarell-fonts-0.0.10.1-1.fc18.noarch.rpm

But these two files are identical, and it's a noarch package.

All other comments accepted. I shouldn't have mixed the discussions.

--
Thomas

Re: [RFU] Please upload: algol68g package updates

[Thomas Wolff]

Am 11.08.2013 19:49, schrieb marco atzeri:

Il 8/11/2013 7:02 PM, Thomas Wolff ha scritto:

Please upload the updated packages for algol68g (both 32 and 64 bit):

cd algol68g
wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2
wget http://towo.net/algol68g/algol68g-2.7-0-`uname -m`.tar.bz2

Thank you
Thomas Wolff


you can not assume that
 uname -m

is providing anything useful.

uname -m works on every system I've tried (unlike uname -p, uname -i).
Very useful (e.g. in PATH=$HOME/bin/`uname`.`uname -m`:$PATH).


Moreover we are not using the architecture on the binary file.
I think it is really not a good idea to have the same name for archives 
of different packages. No other systems I know does this.
I had raised this issue well in time 
(http://cygwin.com/ml/cygwin-apps/2013-04/msg00319.html) with some 
initially positive responses (including yours) but unfortunately no 
further discussion.

My upload request was a feable attempt to foster this discussion again...

By the way, I have managed meanwhile to package algol68g completely with 
cygport (see my other thread which I will respond later) and will 
provide another upload.


--
Thomas

[RFU] Please upload: algol68g package updates

[Thomas Wolff]

Please upload the updated packages for algol68g (both 32 and 64 bit):

cd algol68g
wget http://towo.net/algol68g/algol68g-2.7-0-src.tar.bz2
wget http://towo.net/algol68g/algol68g-2.7-0-`uname -m`.tar.bz2

Thank you
Thomas Wolff

Re: why does setup keep trying to install non-required packages?

[Thomas Wolff]

Am 11.08.2013 09:16, schrieb Andrew Schulman:
Fairly often when I run setup just for updates, it selects new 
packages for
installation that I haven't selected and that aren't required by any 
of my

other packages.

Right now setup wants to install the login package.  I didn't select it,
and if I unselect it the installation continues without any problem.  It
happened in setup-x86, and now setup-x86_64 wants to do it too.  I try to
keep my installation slim, so I don't want setup to add new packages that
aren't required and that I didn't select.

Has anyone else observed this?
Yes, I noticed the same thing, and I noted the packages it wanted to 
install once but they were different on the next attempt.
I don't have the list at hand now, but among them were some big packages 
like lyx and ghostscript, certainly not by dependency.

Thomas
Know the reason?  Are they new packages, and setup assumes I want all 
new packages?


Thanks,
Andrew.

Re: [HEADSUP] Please try to build your packages for 64 bit

[Thomas Wolff]

Am 19.04.2013 12:45, schrieb Corinna Vinschen:

Hi maintainers,


the 64 bit Cygwin seems to be quite stable now.  We're still suffering
from a gcc problem which seems to affect C++ inline methods using
templates, so some C++ packages might not be buildable yet(*), but other
than that it looks pretty good.

I would like to ask those of you owning a 64 bit Windows machine to have
a look into the 64 bit distro and to try to build your packages.  ...
Is there any plan to distinguish 64 bit binary packages from 32 bit 
binary packages by a naming scheme?

That might be useful to avoid accidental confusion e.g. during upload.
--
Thomas

Re: GCC-4.7.2-2: Go/No-go?

[Thomas Wolff]

Am 11.04.2013 14:34, schrieb Dave Korn:

On 11/04/2013 13:19, Corinna Vinschen wrote:


On 2013-04-11 01:02, Dave Korn wrote:

   Yep, sure.  *sigh*, I'm sure we'll suddenly find out that someone was using
it and wants to know where it's gone.  (I suppose if that happens I could
always consider rolling a gcc3 package with all -3 suffixed executables.)

   ^^

   If you really want to stick to an old
gcc, make sure it's not the default.  Call it gcc-3 or legacy-gcc, but
let's get it out of the way of the most recent version.

   Yes, that's what I meant to imply by the wording.  Different name + suffixed
executables = out of the way.

   Also, I don't plan on doing it unless there's significant demand.
I would appreciate to keep it as gcc-3. The reason is quite peculiar; 
gcc-4 changed the order of variables in the stack frame of a function 
call, which led to one very specific interworking malfunction (between 
mintty and mined) which in turn unveiled a very subtle bug. This is 
material for very interesting debugging exercises for students... Not 
sure whether it's significant but the changed variable order might in 
fact affect other software as well.

--
Thomas

Re: 64bit package: mined

[Thomas Wolff]

Am 30.03.2013 21:37, schrieb Corinna Vinschen:

Hi Thomas,

On Mar 30 20:44, Thomas Wolff wrote:

wget http://towo.net/mined/cygwin/64/mined-2012.22-0.tar.bz2
wget http://towo.net/mined/cygwin/64/mined-2012.22-0-src.tar.bz2 #
is this needed? (identical to 32 bit source package)

Any chance you can update your package to use cygport for packaging,
Thomas?  It's really not that complicated.
I'd been reluctant because I don't really see an advantage, especially 
for a package that is being developed under cygwin (meanwhile, used to 
be Solaris before) and includes all cygwin support files natively.

I agree though it's much easier than other packaging systems, so I used your

Here's a matching cygport file:
- thanks - as a starting point, and will switch with the next release. I 
find it somewhat bothersome, still, for a number of issues, also with 
other packages I tried to setup, and will post that to a separate thread.

--
Thomas

Re: 64bit: man misconfigured

[Thomas Wolff]

Am 01.04.2013 14:03, schrieb Andy Koppe:

On 30 March 2013 11:17, Thomas Wolff wrote:

Due to changed /etc/man.conf, man64 uses escape sequences for bold display
while man32 uses backspace combinations.

Backspace combinations?
The traditional Unix way to indicate bold, by explicit "overprinting", 
like B^HBO^HOL^HLD^HD.

Compare man ls > ls.man.out with 32/64 bit versions.




However, the escape sequences are not by default interpreted by less (less
-r would work),
so that PAGER=less man ... produces garbage display.

The 32-bit /etc/man.conf has this:

PAGER   /usr/bin/less -isrR

Whereas the 64-bit one has this:

PAGER   /bin/less -is

As Thomas alludes to, the -r option tells 'less' to pass escape
characters through to the terminal rather than turn them into a
highlighted "ESC".

The 32-bit man sources have a source patch that contains the
following, so I guess that hasn't been applied in the 64-bit version.

-DEFAULTLESSOPT="-is"
+DEFAULTLESSOPT="-isrR"

Andy

64bit package: mined

[Thomas Wolff]

wget http://towo.net/mined/cygwin/64/mined-2012.22-0.tar.bz2
wget http://towo.net/mined/cygwin/64/mined-2012.22-0-src.tar.bz2 # is 
this needed? (identical to 32 bit source package)

--
Thomas

64bit: man misconfigured

[Thomas Wolff]

Due to changed /etc/man.conf, man64 uses escape sequences for bold 
display while man32 uses backspace combinations.
However, the escape sequences are not by default interpreted by less 
(less -r would work),

so that PAGER=less man ... produces garbage display.

Re: 64 bit: build problems

[Thomas Wolff]

Am 29.03.2013 15:43, schrieb Corinna Vinschen:

On Mar 29 15:13, Corinna Vinschen wrote:

On Mar 29 12:37, Thomas Wolff wrote:

Am 29.03.2013 10:42, schrieb Corinna Vinschen:

On Mar 29 10:00, Thomas Wolff wrote:

Am 28.03.2013 20:51, schrieb Corinna Vinschen:

On Mar 28 19:45, Thomas Wolff wrote:

I've tried to build my package (mined) with freshly installed 64-bit
cygwin (default + gcc + make).
When I try it with make, nothing happens, make simply hangs.
When I try it without make, it fails with:
linking mined
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32

 From your cygcheck output w32api is, in fact, missing, just as Adam wrote.  
Other than that, the hang is strange.  I installed Cygwin 64 on 3 machines, W7, 
2K8R2, and W8, and none of them is suffering a hang.
I don't know what to say.  Can you try to debug that?

make -d reads all makefiles (with includes), then hangs.
make option --trace, as mentioned in the manual page, does not exist.
Any further hints how/what to debug?

strace and gdb are the usual tools here.  I don't know what to say else.
I'm running native builds using cygport for a couple of days now, and
sure enough I found a few bugs, but I didn't have a make hang at all.
Are you trying to build the exact 2012.22 package?  What's your exact
set of make options?  I can try if this occurs for me too.

I verified that my local copy is identical to the 2012.22 package.
Then strace gave me some hint indeed;
If I comment out line 573 of include file mkinclud.mak (the "links:"
target), all works fine.
Otherwise, strace ends like this:
[...]
30 1643627 [main] make 1412 symlink_info::check: 0 =
symlink.check(D:\temp\mined-2012.22\src, 0x227700) (0x4022)
18 1643645 [main] make 1412 path_conv::check:
this->path(D:\temp\mined-2012.22\src\links), has_acls(1)
19 1643664 [main] make 1412 __set_errno: int
stat_worker(path_conv&, stat*):1880 setting errno 2
32 1643696 [main] make 1412 stat_worker: -1 =
(\??\D:\temp\mined-2012.22\src\links,0x228960)
   271 1643967 [main] make 1412 stat64: entering
15 1643982 [main] make 1412 normalize_posix_path: src //xmined
18 1644000 [main] make 1412 normalize_posix_path: //xmined =
normalize_posix_path (//xmined)

Any idea why it tries to access a file called //xmined?  The double
slash at the beginning indicates a network UNC path.  So what Cygwin
does is trying to access a server called xmined on your network.
The purpose of this make clause is to install links into the bin 
directory, but only when calling make recursively from the install 
target, in which case $(linkdir) would be set e.g. to /usr/bin.
When not installing, make should not really access those files, and in 
fact, make-32 does not (as shown by strace),
only make-64 invokes some actions on the filenames simply when parsing 
the makefile.

Plus...

Ok, so your linkdir is apparently '/'.  That's not good here since it leads to 
the leading double slash.
as I tested, linkdir is actually *not* "/" but rather empty, so the path 
names involved should be e.g. /xmined, not //xmined. Still mysterious.


Furthermore, the suffix $(EXE) seems to be needed for the problem to occur.
Simplified test case: the following makefile hangs in cygwin64 but not 
in cygwin32:


all:
echo x$(linkdir)y

links:  $(linkdir)/xmined$(EXE)

--
Thomas

Re: 64 bit: build problems

[Thomas Wolff]

Am 29.03.2013 10:42, schrieb Corinna Vinschen:

On Mar 29 10:00, Thomas Wolff wrote:

Am 28.03.2013 20:51, schrieb Corinna Vinschen:

On Mar 28 19:45, Thomas Wolff wrote:

I've tried to build my package (mined) with freshly installed 64-bit
cygwin (default + gcc + make).
When I try it with make, nothing happens, make simply hangs.
When I try it without make, it fails with:
linking mined
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32

 From your cygcheck output w32api is, in fact, missing, just as Adam wrote.  
Other than that, the hang is strange.  I installed Cygwin 64 on 3 machines, W7, 
2K8R2, and W8, and none of them is suffering a hang.
I don't know what to say.  Can you try to debug that?

make -d reads all makefiles (with includes), then hangs.
make option --trace, as mentioned in the manual page, does not exist.
Any further hints how/what to debug?

strace and gdb are the usual tools here.  I don't know what to say else.
I'm running native builds using cygport for a couple of days now, and
sure enough I found a few bugs, but I didn't have a make hang at all.
Are you trying to build the exact 2012.22 package?  What's your exact
set of make options?  I can try if this occurs for me too.

I verified that my local copy is identical to the 2012.22 package.
Then strace gave me some hint indeed;
If I comment out line 573 of include file mkinclud.mak (the "links:" 
target), all works fine.

Otherwise, strace ends like this:
  401 1643027 [main] make 1412 stat64: entering
   16 1643043 [main] make 1412 normalize_posix_path: src ./links
   18 1643061 [main] make 1412 cwdstuff::get: posix 
/cygdrive/d/temp/mined-2012.22/src
   15 1643076 [main] make 1412 cwdstuff::get: 
(/cygdrive/d/temp/mined-2012.22/src) = cwdstuff::get (0x60010, 
32768, 1, 0), errno 2
   17 1643093 [main] make 1412 normalize_posix_path: 
/cygdrive/d/temp/mined-2012.22/src/links = normalize_posix_path (./links)
   16 1643109 [main] make 1412 mount_info::conv_to_win32_path: 
conv_to_win32_path (/cygdrive/d/temp/mined-2012.22/src/links)
   20 1643129 [main] make 1412 mount_info::cygdrive_win32_path: src 
'/cygdrive/d/temp/mined-2012.22/src/links', dst 
'D:\temp\mined-2012.22\src\links'

   23 1643152 [main] make 1412 set_flags: flags: binary (0x2)
   17 1643169 [main] make 1412 mount_info::conv_to_win32_path: src_path 
/cygdrive/d/temp/mined-2012.22/src/links, dst 
D:\temp\mined-2012.22\src\links, flags 0x4

022, rc 0
   43 1643212 [main] make 1412 symlink_info::check: 0xC034 = 
NtCreateFile (\??\D:\temp\mined-2012.22\src\links)
   21 1643233 [main] make 1412 symlink_info::check: 0xC034 = 
NtQueryInformationFile (\??\D:\temp\mined-2012.22\src\links)
   60 1643293 [main] make 1412 symlink_info::check: 0xC034 = 
NtCreateFile (\??\D:\temp\mined-2012.22\src\links.exe)
   21 1643314 [main] make 1412 symlink_info::check: 0xC034 = 
NtQueryInformationFile (\??\D:\temp\mined-2012.22\src\links.exe)
   36 1643350 [main] make 1412 symlink_info::check: 0xC034 = 
NtCreateFile (\??\D:\temp\mined-2012.22\src\links.lnk)
   22 1643372 [main] make 1412 symlink_info::check: 0xC034 = 
NtQueryInformationFile (\??\D:\temp\mined-2012.22\src\links.lnk)
   38 1643410 [main] make 1412 symlink_info::check: 0xC034 = 
NtCreateFile (\??\D:\temp\mined-2012.22\src\links.exe.lnk)
   18 1643428 [main] make 1412 symlink_info::check: 0xC034 = 
NtQueryInformationFile (\??\D:\temp\mined-2012.22\src\links.exe.lnk)
   18 1643446 [main] make 1412 symlink_info::check: 0 = 
symlink.check(D:\temp\mined-2012.22\src\links, 0x227700) (0x404022)
   17 1643463 [main] make 1412 mount_info::conv_to_win32_path: 
conv_to_win32_path (/cygdrive/d/temp/mined-2012.22/src)
   34 1643497 [main] make 1412 mount_info::cygdrive_win32_path: src 
'/cygdrive/d/temp/mined-2012.22/src', dst 'D:\temp\mined-2012.22\src'

   18 1643515 [main] make 1412 set_flags: flags: binary (0x2)
   15 1643530 [main] make 1412 mount_info::conv_to_win32_path: src_path 
/cygdrive/d/temp/mined-2012.22/src, dst D:\temp\mined-2012.22\src, flags 
0x4022, rc 0
   41 1643571 [main] make 1412 symlink_info::check: 0x0 = NtCreateFile 
(\??\D:\temp\mined-2012.22\src)

   26 1643597 [main] make 1412 symlink_info::check: not a symlink
   30 1643627 [main] make 1412 symlink_info::check: 0 = 
symlink.check(D:\temp\mined-2012.22\src, 0x227700) (0x4022)
   18 1643645 [main] make 1412 path_conv::check: 
this->path(D:\temp\mined-2012.22\src\links), has_acls(1)
   19 1643664 [main] make 1412 __set_errno: int stat_worker(path_conv&, 
stat*):1880 setting errno 2
   32 1643696 [main] make 1412 stat_

Re: 64 bit: build problems

[Thomas Wolff]

Am 28.03.2013 20:51, schrieb Corinna Vinschen:

On Mar 28 19:45, Thomas Wolff wrote:

I've tried to build my package (mined) with freshly installed 64-bit
cygwin (default + gcc + make).
When I try it with make, nothing happens, make simply hangs.
When I try it without make, it fails with:
linking mined
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32

 From your cygcheck output w32api is, in fact, missing, just as Adam wrote.  
Other than that, the hang is strange.  I installed Cygwin 64 on 3 machines, W7, 
2K8R2, and W8, and none of them is suffering a hang.
I don't know what to say.  Can you try to debug that?

make -d reads all makefiles (with includes), then hangs.
make option --trace, as mentioned in the manual page, does not exist.
Any further hints how/what to debug?
--
Thomas

64 bit: build problems

[Thomas Wolff]

I've tried to build my package (mined) with freshly installed 64-bit 
cygwin (default + gcc + make).

When I try it with make, nothing happens, make simply hangs.
When I try it without make, it fails with:
linking mined
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lshell32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -luser32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lkernel32

--
Thomas


cygcheck.out
Description: Binary data

Re: Maintainers please weigh in on 64-bit Cygwin

[Thomas Wolff]

Am 17.03.2013 17:45, schrieb Christopher Faylor:

I'd like to have a feel for how the 64-bit version of Cygwin will
impact package maintainers.

So, I'd appreciate some discussion about this.

1) Do you have a 64-bit version of Windows available?

yes

3) Are you willing to download the current 64-bit Cygwin and start porting
your stuff, knowing that there are still bugs?

yes

7) Are you ok with a 64-bit alpha release being made available which contains
your packages built by someone else?

yes

There are probably other considerations that I haven't thought of.  Any 
insights welcome.
I would appreciate the package to be buildable out-of-the-box, 
preferably by simply using "make " on the respective 
architecture (as a default),

and maybe adjusting its name.
I would *not* appreciate being urged to move to cygport on this occasion 
(not that it would not be useful but it has its drawbacks, in terms of 
having to apprehend its usage and versioning tweaks first...).

cgf

Answering these questions myself:

...

(Do you want all responses to the list in this case?)
--
Thomas

Re: nuke cygwin legacy?

[Thomas Wolff]

Am 06.02.2013 03:21, schrieb Yaakov (Cygwin/X):

On Tue, 05 Feb 2013 20:56:42 +0100, Erwin Waterlander wrote:

It doesn't matter that it is not secure.

Yes, it does.  IMHO it is irresponsible on our part to distribute
unmaintained or knowingly vulnerable software, and it reflects badly on
the Cygwin project.


Yaakov
Just a proposal (without advocating further) to avoid the problem of 
providing insecure software for current systems:
What about modifying setup.exe so that 1.5 can be installed *only* on 
legacy systems?

--
Thomas

Re: nuke cygwin legacy?

[Thomas Wolff]

Am 05.02.2013 18:41, schrieb Christopher Faylor:

Corinna +1'ed my suggestion that it was time to remove cygwin 1.5
support so I'm wondering if anyone has any objections to removing
1.5 from cygwin.com.

I was going to suggest this a few months ago and mention that the Cygwin
Time Machine was an alternative but it looks like that service is no
longer available.

So, as an alternative, we could advertise that the directory is going
away on the main web page for a month before nuking it.

cgf
I had thought that support had stopped anyway, just keeping the files 
available.
I used to run an old laptop with Windows ME until recently and maybe 
there's an ME or Windows 2000 surviving in some virtual machine...
For owners of old hardware, there is also some Linux installations still 
available that fit into something like 20MB, so why not keep cygwin for 
download?

Thomas

Re: O: jikes

[Thomas Wolff]

Am 19.09.2012 07:10, schrieb Jari Aalto:

I'm orphaning package "jikes". If anyone feels insterested in taking over,
please go ahead.

Jari
I suggest to deprecate it. It is orphaned upstream and has never been 
updated to Java 5.

Thomas

Re: ITP: apngopt -- Optimize APNG animated images

[Thomas Wolff]

Am 16.09.2012 15:40, schrieb marco atzeri:

On 9/16/2012 12:10 PM, Jari Aalto wrote:

wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/apngopt/apngopt-1.1-1-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/apngopt/apngopt-1.1-1.tar.bz2 \
 http://cante.net/~jaalto/tmp/cygwin/apngopt/setup.hint

Not yeat included in Debian but from the same Author as the other 
apng* commands.




should be better to have a single PNG tool package instead of every 
single command having its own package ?


Upstream author has a very peculiar style in this way

I was about to write the same suggestion and would strongly support it. 
Please don't clutter the package list. We'd appreciate apngtools, please.

Thomas

Re: future of su

[Thomas Wolff]

Am 29.05.2012 17:37, schrieb Eric Blake:

Upstream coreutils is considering completely dropping su, in favor of
having util-linux provide su across all GNU/Linux distros.  Right now,
cygwin's su.exe comes from coreutils, but with a cygwin-specific patch,
and it still doesn't do quite what users are used to from a Linux
perspective.  Is it better to completely drop su from cygwin, or should
I coordinate with the util-linux maintainer to hand control of su out of
coreutils and over to util-linux?
Why would you drop it completely? It's an essential tool, especially in 
a Windows environment.
I was quite delighted when I discovered that it works here as expected; 
I don't use it often but when I do it's extremely useful.

--
Thomas

Re: ITP: algol68g

[Thomas Wolff]

Am 31.03.2012 22:08, schrieb Thomas Wolff:
Algol 68 Genie - a compiler for the most thoroughly designed and 
defined programming language ever.

Available as a package already for Debian, Ubuntu, FreeBSD.

wget http://towo.net/algol68g/setup.hint
wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2
wget http://towo.net/algol68g/algol68g-2.3.7.4-0-src.tar.bz2

Thomas
Reminder: I had meanwhile fixed all discussed problems, and also 
suggested the package for cygwinports as an alternative - no response.

Is it really too exotic to consider for either of the repositories?
Thomas

Re: Please upload: mined-2012.22-0

[Thomas Wolff]

Am 10.05.2012 08:14, schrieb Corinna Vinschen:

On May 10 00:14, Thomas Wolff wrote:

Please upload the release update package for mined:


cd mined
wget http://towo.net/mined/cygwin/mined-2012.22-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2012.22-0-src.tar.bz2
#wget http://towo.net/mined/cygwin/setup.hint

Uploaded.  What about older releases (2011.17-0, 2011.19-0, 2012.20-0)?

Please keep two previous versions this time. All 2011 versions can go.
Thanks
Thomas

Please upload: mined-2012.22-0

[Thomas Wolff]

Please upload the release update package for mined:


cd mined
wget http://towo.net/mined/cygwin/mined-2012.22-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2012.22-0-src.tar.bz2
#wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Re: ITP: algol68g

[Thomas Wolff]

Am 05.04.2012 09:50, schrieb Corinna Vinschen:

On Apr  4 20:54, Thomas Wolff wrote:

...


After some manual checking, I changed dependencies for libplot and
postgresql
to libplot-devel and libpq-devel
(where I wonder why the actual runtime libraries are in the -devel
packages here).

Looking into both devel packages, I only see the stuff required for
development, not the runtime libs:

   $ tar tjf libplot-devel-2.6-2.tar.bz2
   usr/include/[...]
   usr/lib/libplot.a
   usr/lib/libplot.dll.a
   usr/lib/libplot.la
   usr/share/[...]

   $ tar tjf libpq-devel-8.2.11-1.tar.bz2
   usr/bin/pg_config.exe
   usr/include/[...]
   usr/lib/libpgport.a
   usr/lib/libpq.a
   usr/share/[...]

The runtimes are in libplot2:

   $ tar tjf libplot2-2.6-2.tar.bz2
   usr/bin/cygplot-2.dll

and libpq5:

   tar tjf libpq5-8.2.11-1.tar.bz2
   usr/bin/cygpq.dll


Corinna


Thanks. Fixed and uploaded. (Last action for 10 days.)
Thomas

Re: ITP: algol68g

[Thomas Wolff]

...
Yaakov (Cygwin/X):
> On 2012-04-03 14:56, Thomas Wolff wrote:
>> cygport algol68g-2.3.7.4-1.cygport ...

>>> Creating source package
2.3.7-fix-install.patch
algol68g-2.3.7.4-1.cygport
algol68g-2.3.7.4-1.cygwin.patch
algol68g-2.3.7.4-1.src.patch
algol68g-2.3.7.4.tar.gz
*** Warning: setup.hint is missing

where the ...cygwin.patch is empty
and the ...src.patch disables curses which, using my hand-made package, 
works
also, cygport gives no hint about missing or incorrect dependencies as 
you suggested, so I don't see any advantage here



After some manual checking, I changed dependencies for libplot and 
postgresql

to libplot-devel and libpq-devel
(where I wonder why the actual runtime libraries are in the -devel 
packages here).


wget http://towo.net/algol68g/setup.hint 

fixed, please check again, thanks and kind regards,
Thomas

Re: ITP: algol68g

[Thomas Wolff]

Am 03.04.2012 22:09, schrieb Yaakov (Cygwin/X):

On 2012-04-03 14:56, Thomas Wolff wrote:

cygport algol68g-2.3.7.4-1.cygport prep, then
cygport algol68g-2.3.7.4-1.cygport compile, says this:
>>> Compiling algol68g-2.3.7.4-1
which: no autopoint in ($PATH)


"cygcheck -p autopoint" will show you what you're missing.

... as we're talking about dependencies :-\
Why does it hang, anyway?
Will continue to try later.
Thomas

Re: ITP: algol68g

[Thomas Wolff]

Am 03.04.2012 01:20, schrieb Yaakov (Cygwin/X):



Am 02.04.2012 21:56, schrieb Yaakov (Cygwin/X):

* Some of the new deps in requires: are incorrect, and commas should
not be used between deps.

Which and why (apart from the commas)? Suggestion to fix?

You'd better let cygport figure that out for you.
Well (see below) anyway, I'd appreciate if you can be more precise about 
which dependencies you think are incorrect (except for the syntax).



...
configure: WARNING: configuring interpreter-only on untested platform

So AFAICS this package will need more work in order to support dynamic 
compilation.

I'll check later.


The attached .cygport and patch should get you started.

cygport algol68g-2.3.7.4-1.cygport prep, then
cygport algol68g-2.3.7.4-1.cygport compile, says this:
>>> Compiling algol68g-2.3.7.4-1
which: no autopoint in ($PATH)

(where $PATH is expanded) then stays silent and hangs indefinitely.
Thomas

Re: ITP: algol68g

[Thomas Wolff]

Am 02.04.2012 21:56, schrieb Yaakov (Cygwin/X):

On 2012-04-02 14:33, Thomas Wolff wrote:

wget http://towo.net/algol68g/setup.hint


* I suggest category: Interpreters instead of Devel.
Maybe. But then Java might fit in there as well. Having another look, 
the split between these two seems a bit unorganized 
(Languages/Devtools/Devlibs might be better).

Are both categories OK?


* Some of the new deps in requires: are incorrect, and commas should 
not be used between deps.

Which and why (apart from the commas)? Suggestion to fix?
New version uploaded.



wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2


What is the purpose of the header files if there is no library?

I thought you might ask...
According to the author they are needed for dynamic compilation. Might 
fit better elsewhere but I don't wish to tamper with the compiler setup.


Thomas

Re: ITP: algol68g

[Thomas Wolff]

Am 02.04.2012 21:11, schrieb Yaakov (Cygwin/X):

On 2012-04-02 12:59, Thomas Wolff wrote:

wget http://towo.net/algol68g/setup.hint
wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2

Please check the new attempt.


These are the same as before.


Yaakov

Oops. Put them into the wrong server directory. Sorry, fixed.

Re: ITP: algol68g

[Thomas Wolff]

Am 01.04.2012 21:30, schrieb Thomas Wolff:

Am 01.04.2012 06:35, schrieb Yaakov (Cygwin/X):

On 2012-03-31 15:08, Thomas Wolff wrote:

wget http://towo.net/algol68g/setup.hint
wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2

Please check the new attempt.

#wget http://towo.net/algol68g/algol68g-2.3.7.4-0-src.tar.bz2

Unchanged.

Thomas



* Where did you get this version of sources from?  No such version is 
listed on the website.

From the author, after discussing cygwin build problems.


* Why did you omit the gsl, libplot, and postgresql features?
Which means I should add dependencies, I guess, and rebuild (I tested 
on one system where these packages are installed so they were included 
by 'configure' - then I built on a different system; thanks for 
noticing.)


Thomas

Re: ITP: algol68g

[Thomas Wolff]

Am 01.04.2012 06:35, schrieb Yaakov (Cygwin/X):

On 2012-03-31 15:08, Thomas Wolff wrote:

wget http://towo.net/algol68g/setup.hint
requires: is incorrect; 'cygwin' should not be listed, libncurses10 is 
missing.  The sdesc: should be quoted.

OK, will be fixed.

wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2
wget http://towo.net/algol68g/algol68g-2.3.7.4-0-src.tar.bz2


* Where did you get this version of sources from?  No such version is 
listed on the website.

From the author, after discussing cygwin build problems.


* Why did you omit the gsl, libplot, and postgresql features?
Which means I should add dependencies, I guess, and rebuild (I tested on 
one system where these packages are installed so they were included by 
'configure' - then I built on a different system; thanks for noticing.)


Thomas

ITP: algol68g

[Thomas Wolff]

Algol 68 Genie - a compiler for the most thoroughly designed and defined 
programming language ever.

Available as a package already for Debian, Ubuntu, FreeBSD.

wget http://towo.net/algol68g/setup.hint
wget http://towo.net/algol68g/algol68g-2.3.7.4-0.tar.bz2
wget http://towo.net/algol68g/algol68g-2.3.7.4-0-src.tar.bz2

Thomas

Please upload: mined-2012.21-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2012.21-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2012.21-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2012.20-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2012.20-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2012.20-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Re: Setup and Mintty

[Thomas Wolff]

Am 18.11.2011 11:59, schrieb Corinna Vinschen:

On Nov 18 05:36, Andy Koppe wrote:

On 17 November 2011 17:17, Corinna Vinschen wrote:
...

Is there anything else missing?

I suspect the manual and FAQ need a few tweaks.

There's the faq entry "My application prints international characters
but I only see gray boxes".  The entry about the console is still
valid, even after changing to mintty on the desktop.  Do you think
it makes sense to add words about mintty here?  If so, I guess the
problem more often occurs with Win32 apps running in a UTF-8 mintty.
Do you have a suggestion for an addition related to mintty?
This problem could at least be partially solved as has been discussed in 
http://www.cygwin.com/ml/cygwin-apps/2010-06/msg00033.html:

test case:

touch bäh
cmd /c dir
chcp 65001 (or cmd /c chcp 65001) <- the corresponding API call could be 
issued by mintty, or cygwin1.dll

cmd /c dir

Thomas

Please upload: mined-2011.19-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2011.19-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2011.19-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2011.17-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2011.17-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2011.17-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Re: setup and mintty (was Re: New setup.exe release?)

[Thomas Wolff]

Am 25.05.2011 09:43, schrieb Andy Koppe:

...
Ah, sorry, I didn't realise that the desktop shortcut at the moment
was simply called "Cygwin" rather than "Cygwin Bash Shell". I suppose
that could just stay like that actually.

Also, since the start menu shortcut already is inside the "Cygwin"
folder, just "Terminal" rather than "Cygwin Terminal" would be nice
and crisp there.
I think common usage is to give shortcuts rather a complete name. That's 
also better if people move them around, placing a copy on the desktop etc.
And since bash shell runs in both command windows (is that a common 
name?), I think the previous proposal "Cygwin Console" and "Cygwin 
Terminal" is the best to distinguish them.

--
Thomas

Re: Please upload: mined-2000.16-0

[Thomas Wolff]

Am 13.02.2011 17:35, schrieb Corinna Vinschen:

Thomas,

On Feb 24 01:32, Thomas Wolff wrote:

Please upload the release update package for mined:


#mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.16-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.16-0-src.tar.bz2
#wget http://towo.net/mined/cygwin/setup.hint


There's a bug in mined's postinstall script, or better, in the
/usr/share/mined/setup_install/bin/setupreg.sh script called from
the postinmstall script:

   $ /usr/share/mined/setup_install/bin/setupreg.sh
   The operation completed successfully.
   The operation completed successfully.
   ERROR: The system was unable to find the specified registry key or value.

The reason is that, at least on Windows 7, there is no key called
HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations.

The result is that a user of Windows 7 gets a postinstall warning from
setup.exe because the mined postinstall script returns a non-zero exit
code.


Corinna

Hi, thanks for the notice.
Actually I'm aware that there is this postinstall return problem also in 
Windows XP and I've fixed it but the code base isn't quite ready yet for 
the next release - can it still wait for a short while?
On the other hand, if the key doesn't exist because the mechanism has 
changed in Windows 7, I'm not sure what to do because I don't have W7 
myself for testing - any advice by someone? Just some other key name 
perhaps?

Thanks
Thomas

Re: default terminal

[Thomas Wolff]

Am 04.06.2010 07:51, schrieb Andy Koppe:

On 2 June 2010 21:39, Thomas Wolff wrote:
   


(There
used to be a project to add graphics to an xterm clone - maybe another
challenge for Andy...?)
 

You mean the Tektronix stuff? No, thanks. The three people who do
still need that are all happy with xterm. ;)
   
No, no, not that... There was a new approach to embed graphics images 
directly into the normal xterm display, with some sample screenshots to 
enhance directory listings with icons. Unfortunately I didn't succeed in 
digging out the reference, will keep trying.

Thomas

Re: mintty/Windows interoperability (was: Re: default terminal)

[Thomas Wolff]

Am 03.06.2010 20:17, schrieb Andy Koppe:

On 2 June 2010 21:39, Thomas Wolff wrote:
   
...

   * Another issue with even those Windows/DOS programs that do work in
 general: They assume the Windows ANSI encoding so their output
 (and input assumption) will not match the mintty character
 encoding in most cases. (Test case: configure Windows UI to
 "German", reboot (grumble)
 

Unfortunately the common (i.e. cheaper) variants don't allow you to
change the UI language.
   

 run mintty in UTF-8, enter 'xcopy'
 (without parameters), see error message "Unzul▒ssige
 Parameteranzahl"). This works fine in the Cygwin Console because
 the I/O method used by those programs bypasses cygwin - the Cygwin
 Console is actually a dual-character set environment. My initial
 idea that Windows could be convinced to change that for mintty
 with 'chcp.com 65001' failed.
 

Ah, 'chcp' actually is a cmd.exe builtin, so you need to run it like
this: 'cmd /c chcp 65001'. I can't test the xcopy error message, but
this did at least yield correct umlauts in filenames when doing a 'cmd
/c dir'.
   
Ah, right! I had not noticed this, only that error message are not 
fixed. Something else that *is* fixed this way is e.g.

cmd /c help
(which also shows that cmd has a built-in chcp in addition to the 
stand-alone chcp.com that at least Windows XP has).
So this would be a partial work-around, and maybe an easy one if mintty 
just aligns the chcp setting with the locale automatically?



 ...
 

When a Windows process is invoked from a Cygwin process using exec()
or spawn(P_OVERLAY, ...), the Cygwin process "hangs around as a 'stub'
presenting it's
pid as the win32 process's pid, to allow cygwin tools to kill the
win32 process." (From winsup/cygwin/how-spawn-works.txt.)

My thinking was that using a couple of extra pipes, that process could
in theory translate between the console's codepage and the locale
charset. The place to hook that in would be spawn_guts() in
winsup/cygwin/spawn.cc. That function is a scary place though, and
I've got no idea whether such an approach could work.
   



 The best thing to do then would be to wrap the spawned
 Windows/DOS program into something like 'luit'. A work-around
 would also be to switch mintty encoding dynamically but that would
 not work with multiple programs producing output simultaneously,
 for example from a background process.
 

There might be another possibility: when the invisible console is
created in fhandler_console::need_invisible, set its input and output
codepages according to the locale charset (using SetConsoleCP and
SetConsoleOutputCP). Obviously that could only work for locale
charsets that do have an equivalent Windows codepage, or at least
something close (like CP1252 vis-a-vis ISO-8859-1).
   
This sounds as if it would have the same effect as chcp, so it might be 
worth a try.



In the end though, these ideas are all imperfect workarounds.
It seems to me the idea with the hook you outlined above would be a 
solution, not just a workaround.



Given that there is a straightforward answer to any issue with console
programs ("use a console"), I find it hard to justify much effort
going into them.
   

Maybe. Or, maybe, as cgf said:

There is no way to know though.  It could be that there is an application
used by thousands that works well in the console window while failing
miserably under a tty/pty.
   
Imagine thousands of complaints after making mintty the default... 
That's something mintty would not deserve, so avoiding it might be a 
benefit.


--
Thomas

mintty/Windows interoperability (was: Re: default terminal)

[Thomas Wolff]

Am 01.06.2010 01:14, schrieb Charles Wilson:

On 5/31/2010 5:29 PM, Christopher Faylor wrote:
   

I'm wondering what the rest of the maintainer community thinks, though.

What do you all think about a two step plan of first making mintty part
of the default install and then making it the default terminal?
 

Sounds good to me.
   


I absolutely support to promote mintty side-by-side as one of two 
desktop links.
Before making it the only default, however, there's still two issues to 
consider concerning interoperability with Windows programs:


   * The known limitation with certain Windows (or even DOS) programs
 due to the incompatibility of some of the multiple Windows output
 methods with pty. Is anyone still trying to find a wrapper that
 might solve this for input and output?
   * Another issue with even those Windows/DOS programs that do work in
 general: They assume the Windows ANSI encoding so their output
 (and input assumption) will not match the mintty character
 encoding in most cases. (Test case: configure Windows UI to
 "German", reboot (grumble), run mintty in UTF-8, enter 'xcopy'
 (without parameters), see error message "Unzul▒ssige
 Parameteranzahl"). This works fine in the Cygwin Console because
 the I/O method used by those programs bypasses cygwin - the Cygwin
 Console is actually a dual-character set environment. My initial
 idea that Windows could be convinced to change that for mintty
 with 'chcp.com 65001' failed. I discussed it with Andy already and
 he suggested a fork point somewhere in cygwin (maybe winsup or
 newlib?) where a Windows/DOS program is being distinguished from a
 cygwin program anyway, and where a wrapper might be activated
 implicitly. (I might try to work on a patch if I knew where that
 point is.) The best thing to do then would be to wrap the spawned
 Windows/DOS program into something like 'luit'. A work-around
 would also be to switch mintty encoding dynamically but that would
 not work with multiple programs producing output simultaneously,
 for example from a background process.

--
Thomas

Re: default terminal

[Thomas Wolff]

Am 02.06.2010 15:30, schrieb Dave Korn:

On 01/06/2010 19:19, Andy Koppe wrote:
   

On 1 June 2010 00:14, Charles Wilson wrote:
 
   

  Perhaps,
instead, setup could create two shortcuts instead of just one.  ...
   

Not a bad idea. "Cygwin Console" and "Cygwin Terminal" perhaps? Of
course people still wouldn't know the difference, but at least they
could try them and find out, and delete as appropriate.
 

   +1.
   
+1 again. Actually I was about to suggest the same two terms just before 
Andy's posting.



Then again, we
might get lots of questions about why setup.exe felt the need to
create two shortcuts and what the difference between them is. Hmm.
 

   We already get plenty of questions about the difference between a console
and a terminal.  Don't think it'll be any different really.  Let's call the
shortcuts "Cygwin Console" and "Cygwin GUI Terminal", and then people will
think it's obvious why there's two of them.
   
Apart from its configuration menu, mintty isn't really more of "GUI" 
than the console; also I don't think that would answer those questions. 
(There used to be a project to add graphics to an xterm clone - maybe 
another challenge for Andy...?)


--
Thomas

Re: Please upload: mined-2000.16-0

[Thomas Wolff]

On Wed, Feb 24, 2010 at 11:03:24AM +0100, Corinna Vinschen wrote:
   

On Feb 24 01:32, Thomas Wolff wrote:
 

Please upload the release update package for mined:


#mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.16-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.16-0-src.tar.bz2
#wget http://towo.net/mined/cygwin/setup.hint

   

Uploaded.

We have 6 versions of mined on sourceware, 14-2, 15-0, 15.2-0, 15.3-0,
15.4-0, and 16-0.  Are there one or two which can be removed?

Btw., who has accepted the announcement message without checking if
the files have actually been uploaded?
 

I accepted it since I *never* check.  The protocol is to send the
release announcement after the files have been uploaded, not before.
   
Which I did (in case this was questioned) but I did not wait with the 
announcement until the upload was confirmed as I used to do a few times 
because I remembered that cgf instructed me a while ago that *this* was 
not required :)

Thomas

Please upload: mined-2000.16-1

[Thomas Wolff]

Please upload the package update for mined:


cd mined
wget http://towo.net/mined/cygwin/mined-2000.16-1.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.16-1-src.tar.bz2
#wget http://towo.net/mined/cygwin/setup.hint


This update contains just two fixes for handling the Windows Explorer context 
menu,
thus I think it can go without an announcement if you agree:
* Handling of filenames with spaces in context menu
* Share context menu with Windows stand-alone package (in case someone installs 
both) 
  to avoid a duplicate entry, and handle the mutual install/uninstall cases

You may delete all previous packages except the last one (2000.15.4).

Thank you,
Thomas Wolff

Please upload: mined-2000.16-0

[Thomas Wolff]

Please upload the release update package for mined:


#mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.16-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.16-0-src.tar.bz2
#wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Weird %SystemDrive% directories

[Thomas Wolff]

On my home machine, setup keeps creating subdirectory trees when installing 
certain packages, like:
/E/cygwin/%SystemDrive%/Dokumente und 
Einstellungen/towo/Anwendungsdaten/Microsoft/SystemCertificates/My/Certificates
/E/cygwin/%SystemDrive%/Dokumente und 
Einstellungen/towo/Anwendungsdaten/Microsoft/SystemCertificates/My/CRLs
/E/cygwin/%SystemDrive%/Dokumente und 
Einstellungen/towo/Anwendungsdaten/Microsoft/SystemCertificates/My/CTLs

(I had mentioned this before in a side note, 
http://www.cygwin.com/ml/cygwin-apps/2009-11/msg00041.html,
but didn't follow up so far because it's not really harmful.)

By the names, my guess was it's somehow related to access rights handling, 
maybe ACLs.
This is on a FAT drive (USB-connected) on Windows XP home.

I have now noticed that there are a few more directory trees of the same name 
and structure, in:
/lib (i.e. /E/cygwin/lib)
/bin
/usr/share/terminfo/* (in every subdirectory)
/... (one more, don't remember)

and this seems to correlate with those directories in which 
chmod is applied to some files during postinstall.

Does that give a clue on the cause?

--
Thomas

Packages keep being installed again

[Thomas Wolff]

A few packages keep showing up in my setup for installation and are 
installed again every time even though they have been installed already; 
currently it's:
glib
lapack

--
Thomas

Installation for user (xinit, mintty, rxvt*, ...)

[Thomas Wolff]

I noticed that some postinstall scripts make entries using cygpath -AP or 
mkshortcut -AP.
I suggest that these packages implement a fallback to -P in case the 
current user does not have the right to install to all, e.g. checking with
test -w "$(cygpath -AP)"

Actually, even if the user has that right, s/he might have chosen "Install For 
Just Me" in setup.exe.
So maybe the check should be
test -w "$(cygpath -AP)"/Cygwin
or
test -w "$(cygpath -AP)"/Cygwin-X
respectively, or cygpath could add an option to fork -A/non-A automatically 
based on the installation decision :)

--
Thomas

Re: [ANNOUNCEMENT] updated: orpie-1.5.1-2

[Thomas Wolff]

[ last section relevant for cygwin-apps, not sure whether this was an 
acceptable excuse for cross-posting :-\  ]


Andrew Schulman wrote:

2010/1/8 Thomas Wolff:



Works well in the cygwin console; in mintty, however, it just reports:
/usr/bin/orpie.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory
It *does* work in a cygwin 1.5 mintty, though, so it's not a limitation
related to Windows console/pty incompatibilites, unless something got
changed here.
  

Same here, but only in an existing mintty window. Orpie works fine in
a newly opened mintty.

And the difference appears to be in the PATH: in the new session it
has an additional /usr/lib/lapack at the end.



OK, sorry about this.  I think a few things are conspiring:

* cygport didn't tell me that orpie depends on lapack, and I had forgotten
that it does, and stupidly removed it from setup.hint.
  

That's strange as lapack was installed with orpie for me.


* In order for lapack to work, you have to have /usr/lib/lapack in your
$PATH.  IMO that's a bug, but the lapack maintainer told me a couple of
years ago that it's a wontfix.
  
This is done by /etc/profile.d/lapack0.*sh which also got installed, so 
as Andy pointed out, it works if only you start a new login shell.



So Thomas, please try this:  install lapack, and add /usr/bin/lapack to
your $PATH.  Then retry orpie, and let me know if that fixes the problem.
  
Thanks, but it was fixed already as mentioned above, no need to amend 
personal PATH settings.



I'm just thinking whether it's worth to handle this situation in 
general, something like:
If a package (lapack actually, in this case) modifies the profile 
environment so shell restarts are needed,

there might be a package option to have setup present a popup warning...
But maybe it's not worth the effort, given the general advice "don't 
start setup from shell" (which I regularly violate) which - on the other 
hand - is somewhat similar to the unpleasant "Close all applications 
before installing" of typical Windows installers...


Thanks anyway for this nice package.
Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

[resending without attachments which got spam-blocked]

Corinna Vinschen schrieb:

On Dec 18 16:08, Thomas Wolff wrote:
  

Corinna Vinschen schrieb:


On Dec 18 11:57, Corinna Vinschen wrote:
  

On Dec 17 17:31, Corinna Vinschen wrote:


I applied a patch which falls back to opening/creating the file/dir
without WRITE_DAC if the first call failed.  That's not quite optimal
but it works.  Please check out the latest from CVS and test in your
scenario.  For me it works now on the share as well as on local drives.
  

The downside is that it will not create any POSIX-like permissions on
the share.  I'm just creating another solution which allows to give
normal POSIX permissions to the files, just like on a local drive.


I applied tha patch to CVS.  The NtCreateFile call now gets the POSIX-like
ACL to create the file immediately with the correct permissions.  Please
give it a try.
  

I can do that on Monday, hope it's sufficient.

Both setup.exe versions of Friday work! Great, thanks. And with both 
network drives.
There were a number of "Permission denied" messages in some of the 
screen logs, mostly during postinstall of terminfo.
And there was a failed attempt to create H:\/setup.log in one of them 
(last instance of \/ or \\ after transformation).


If it's interesting, I can provide additional information about security 
properties of the affected drives and dirs.

Kind regards,
Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen schrieb:

On Dec 18 11:57, Corinna Vinschen wrote:
  

On Dec 17 17:31, Corinna Vinschen wrote:


I applied a patch which falls back to opening/creating the file/dir
without WRITE_DAC if the first call failed.  That's not quite optimal
but it works.  Please check out the latest from CVS and test in your
scenario.  For me it works now on the share as well as on local drives.
  

The downside is that it will not create any POSIX-like permissions on
the share.  I'm just creating another solution which allows to give
normal POSIX permissions to the files, just like on a local drive.


I applied tha patch to CVS.  The NtCreateFile call now gets the POSIX-like
ACL to create the file immediately with the correct permissions.  Please
give it a try.
  

I can do that on Monday, hope it's sufficient.


Be aware that this share is really a problem.  The permissions given on
it are not common.  You can create a file with the desired permissions,
but you will never be able to change the permissions afterwards.  THis
is a flaw in the sharing permission handling if the user has only
"Change" permissions but not "Full Control".  Your admin should change
that and rather fix the permissions in the share's ACL.  Even Microsoft
recommends that.


This problem persists, of course.  Only your admin can change it.
  
I seem to remember that I have full access on this H: drive, according 
to the properties menu, in contrast to another drive which had the same 
problem, but I'll check again.


Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen wrote:

On Dec 17 14:09, Corinna Vinschen wrote:
  

Has the H:\cygwin17 directory been created at all?  If so, we should
examine the cacls for this dir just like the cacls for H:\ itself.


No, it hasn't. For some ACLs, see below.


Hmm.

[...time passes...]

Hang on, there's another possible reason for STATUS_ACCESS_DENIED.
Mkdir_p calls NtCreateFile to create the directory with
STANDARD_RIGHTS_ALL rights.  This includes WRITE_DAC and WRITE_OWNER
rights.  Especially the last one could be a problem for a non-admin
user.

I looked up what these two mean and in fact it sounds like the problem; 
I had previously sent the output of getfacl on the drive directories and 
on directories manually created there, don't know if that helps:
Also here is the output of getfacl for directories on the two network 
drives I had tried:

> # file: /cygdrive/h
> # owner: Administratoren
> # group: 
> user::rwx
> user:wolff:rwx
> group::---
> group:SYSTEM:rwx
> mask:rwx
> other:---
> default:user::rwx
> default:user:Administratoren:rwx
> default:user:wolff:rwx
> default:group:SYSTEM:rwx
> default:mask:rwx
>
> # file: /cygdrive/h/cygwin
> # owner: wolff
> # group: Domänen-Benutzer
> user::rwx
> group::---
> group:root:rwx
> group:SYSTEM:rwx
> mask:rwx
> other:---
> default:user::rwx
> default:user:wolff:rwx
> default:group:root:rwx
> default:group:SYSTEM:rwx
> default:mask:rwx

> # file: /cygdrive/t/TGI
> # owner: Administratoren
> # group: 
> user::rwx
> group::---
> group:SYSTEM:rwx
> group:Benutzer:r-x
> mask:rwx
> other:---
> default:user::rwx
> default:user:Administratoren:rwx
> default:group:SYSTEM:rwx
> default:group:Benutzer:r-x
> default:mask:rwx
>
> # file: /cygdrive/t/TGI/cygwin
> # owner: Administratoren
> # group: 
> user::rwx
> group::---
> group:SYSTEM:rwx
> group:Benutzer:r-x
> mask:rwx
> other:---
> default:user::rwx
> default:user:Administratoren:rwx
> default:group:SYSTEM:rwx
> default:group:Benutzer:r-x
> default:mask:rwx
Also, speaking of ACLs and pondering about possible effects of their 
inheritance, it comes to my mind that it might make a difference whether 
to create H:\cygwin in a mounted H: drive or H:\mydir\cygwin so I'll try 
that next time.



Could you please try to replace STANDARD_RIGHTS_ALL with

  SYNCHRONIZE | WRITE_DAC | READ_CONTROL

If that works, we're done.  If that doesn't work, try

  SYNCHRONIZE | READ_CONTROL

If that works, you will see failure log output from SetPosixPerms().

Either way, this might be the entire problem here.  If the first
expression works, we should be able to use it as is.  If only the
second expression works, we have to do some admin/non-admin conditional.



Good news.  I can finally reproduce the problem.  Digging deeper now...
  

Great, so I'll wait.
Concerning "time until release", if you want me to test something 
tomorrow morning that's OK, if you want me to test something today, 
please provide compiled debug versions somewhere on the net as I cannot 
compile it here.

Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen wrote:

On Dec 17 02:12, Thomas Wolff wrote:
  

I took an extra drive to the lab this afternoon, with no good results.
[...]
mkdir:NtCreateFile -> 0
  
<\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f>
filemanip:NtCreateFile -> 0
  
<\??\D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f\setup-2.ini>
mkdir:NtCreateFile -> C022



This appears to be the actual start of the desaster.
I guess I should have made clear that the trace of the filename comes 
*after* the trace of the status in my logs, sorry. So in this log, it's:

mkdir:NtCreateFile -> C022
 <\??\H:\cygwin17\etc\setup>
Anyway, this complies with the fact that's it's the network drive H: 
giving the problems, not D: which is a local drive.
So I think I should apply all your instructions to 
H:\cygwin17\etc\setup, or to H:\cygwin17p in the reverse test case:

mkdir:NtCreateFile -> C022
 <\??\H:\cygwin17p>


  The problem is
that the above alone gives us no clue about the real reason for the
access denied error.
It's quite puzzeling that there's no log from NTSecurity::SetPosixPerms(),
so setting the permissions worked fine, apparently.
  
That's quite clear because after return status C0*22, SetPosixPerms will 
not be called as it is guarded by

   if (NT_SUCCESS (status))

Maybe I'll be able to test again tomorrow.
What about the option to use mkdir (the normal one from libc) rather 
than NtCreateFile? I think there were some considerations about 
assigning backup flags but maybe that's not needed for directories?


Thomas


Here's what we need next:

- Who are you (Windows user and primary group name)?

- Output of `cacls D:\'

- In GDB, set a breakpoint on mkdir_p and stop right at the point
  above, *before* NtCreateFile gets called.

- What are the permission bits given to the mkdir_p call above?

- Output of `cacls D:\cygwin17p' right before the NtCreateFile call.

- Output of
  `cacls 
D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f'
  right after the NtCreateFile call but *before* the call to
  nt_sec.SetPosixPerms().

- Output of
  `cacls 
D:\cygwin17p\http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f'
  right after the nt_sec.SetPosixPerms() call.


Corinna
  

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen schrieb:

On Dec 11 12:52, Thomas Wolff wrote:
  

Corinna Vinschen wrote:
#define STATUS_OBJECT_PATH_NOT_FOUND ((NTSTATUS)0xC03AL)
#define STATUS_OBJECT_PATH_SYNTAX_BAD ((NTSTATUS)0xC03BL)

However, before the fatal error occurs, it's just
"STATUS_ACCESS_DENIED" in both cases.


...

Starting cygwin install, version 2.662
filemanip:NtCreateFile -> C03B


This one might be the actual problem.  What's the actual path given
to NtCreateFile (in uname)?  Does it contain slashes maybe?
  
There is "\??\/var" and occasional double and triple backslashes; I 
wonder what "\??" means.

See new log files attached.
Thomas
sh-3.2$ ./setup.exe 
Starting cygwin install, version 2.662
filemanip:NtCreateFile -> C03B
  <\??\h:\\\setup.rc>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\setup.rc>
io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\last-cache>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\last-cache>
io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\last-action>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\last-action>
io_stream_cygfile: fopen(/etc/setup/last-action) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\net-method>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\net-method>
io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\net-proxy-host>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\net-proxy-host>
io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\net-proxy-port>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\net-proxy-port>
io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\last-mirror>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\last-mirror>
io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\extrakeys>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\extrakeys>
io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\chooser_window_settings>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\chooser_window_settings>
io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such 
file or directory
Current Directory: h:\
User has NO backup/restore rights
Could not open Service control manager
source: network install
root: H:\cygwin17 binary user
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\installed.db>
io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or 
directory
mkdir:NtCreateFile -> C034
  <\??\/var>
mkdir:NtCreateFile -> C033
  <\??\>
Selected local directory: D:\cygwin17p
mkdir:NtCreateFile -> 0
  <\??\D:\cygwin17p>
net: Direct
filemanip:NtCreateFile -> C03B
  <\??\h:\\\mirrors-lst>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\mirrors-lst>
io_stream_cygfile: fopen(/etc/setup/mirrors-lst) failed 2 No such file or 
directory
Cached mirror list unavailable
get_url_to_membuf http://cygwin.com/mirrors.lst
getUrlToStream http://cygwin.com/mirrors.lst
site: http://linux.rz.ruhr-uni-bochum.de/download/cygwin/
get_url_to_membuf 
http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2
getUrlToStream http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2
get_url_to_membuf 
http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2.sig
getUrlToStream 
http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2.sig
mkdir:NtCreateFile -> 0
  
<\??\D:\cygwin17p\http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f>
filemanip:NtCreateFile -> 0
  
<\??\D:\cygwin17p\http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f\setup-2.ini>
mkdir:NtCreateFile -> C022
  <\??\H:\cygwin17\etc\setup>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\timestamp>
io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C022
  <\??\H:\cygwin17\etc\setup\timestamp>
io_stream_cygfile: fopen(/etc/setup/timestamp) failed 13 Permission denied
mkdir:NtCreateFile -> C03A
  
<\??\D:\cygwin17p\http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen schrieb:

On Dec 11 12:52, Thomas Wolff wrote:
  

Corinna Vinschen wrote:
#define STATUS_OBJECT_PATH_NOT_FOUND ((NTSTATUS)0xC03AL)
#define STATUS_OBJECT_PATH_SYNTAX_BAD ((NTSTATUS)0xC03BL)

However, before the fatal error occurs, it's just
"STATUS_ACCESS_DENIED" in both cases.


...

Starting cygwin install, version 2.662
filemanip:NtCreateFile -> C03B


This one might be the actual problem.  What's the actual path given
to NtCreateFile (in uname)?  Does it contain slashes maybe?
  
There is "\??\/var" and occasional double and triple backslashes; I 
wonder what "\??" means.

See new log files attached.
Thomas
sh-3.2$ ./setup.exe 
Starting cygwin install, version 2.662
filemanip:NtCreateFile -> C03B
  <\??\h:\\\setup.rc>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\setup.rc>
io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\last-cache>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\last-cache>
io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\last-action>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\last-action>
io_stream_cygfile: fopen(/etc/setup/last-action) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\net-method>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\net-method>
io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\net-proxy-host>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\net-proxy-host>
io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\net-proxy-port>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\net-proxy-port>
io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\last-mirror>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\last-mirror>
io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\extrakeys>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\extrakeys>
io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
  <\??\h:\\\chooser_window_settings>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\chooser_window_settings>
io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such 
file or directory
Current Directory: h:\
User has NO backup/restore rights
Could not open Service control manager
source: network install
root: H:\cygwin17 binary user
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\installed.db>
io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or 
directory
mkdir:NtCreateFile -> C034
  <\??\/var>
mkdir:NtCreateFile -> C033
  <\??\>
Selected local directory: D:\cygwin17p
mkdir:NtCreateFile -> 0
  <\??\D:\cygwin17p>
net: Direct
filemanip:NtCreateFile -> C03B
  <\??\h:\\\mirrors-lst>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\mirrors-lst>
io_stream_cygfile: fopen(/etc/setup/mirrors-lst) failed 2 No such file or 
directory
Cached mirror list unavailable
get_url_to_membuf http://cygwin.com/mirrors.lst
getUrlToStream http://cygwin.com/mirrors.lst
site: http://linux.rz.ruhr-uni-bochum.de/download/cygwin/
get_url_to_membuf 
http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2
getUrlToStream http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2
get_url_to_membuf 
http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2.sig
getUrlToStream 
http://linux.rz.ruhr-uni-bochum.de/download/cygwin//setup-2.bz2.sig
mkdir:NtCreateFile -> 0
  
<\??\D:\cygwin17p\http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f>
filemanip:NtCreateFile -> 0
  
<\??\D:\cygwin17p\http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f\setup-2.ini>
mkdir:NtCreateFile -> C022
  <\??\H:\cygwin17\etc\setup>
filemanip:NtCreateFile -> C03A
  <\??\H:\cygwin17\etc\setup\timestamp>
io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C022
  <\??\H:\cygwin17\etc\setup\timestamp>
io_stream_cygfile: fopen(/etc/setup/timestamp) failed 13 Permission denied
mkdir:NtCreateFile -> C03A
  
<\??\D:\cygwin17p\http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

I wrote:

Dave Korn wrote:

Thomas Wolff wrote:
 

Selected local directory: H:\cygwin17p1
mkdir:NtCreateFile -> C022
mbox note: Couldn't create directory H:\cygwin17p1, sorry.  (Is 
drive full or read-only?)


  So that's coming from here:

  status = NtCreateFile (&dir,
   STANDARD_RIGHTS_ALL | FILE_LIST_DIRECTORY,
 &attr, &io, NULL, FILE_ATTRIBUTE_DIRECTORY,
 FILE_SHARE_VALID_FLAGS, FILE_CREATE,
 FILE_DIRECTORY_FILE
 | FILE_SYNCHRONOUS_IO_NONALERT
 | FILE_OPEN_FOR_BACKUP_INTENT, NULL, 0);

  Interesting.  Does it possibly succeed if you remove the
FILE_OPEN_FOR_BACKUP_INTENT flag?
  

Unfortunately not.
Any other flags I might remove?

Also I noticed: parameter 5, AllocationSize, should be an int, while 
NULL is a pointer.
Sorry, it's a pointer to int, I didn't see the "P" before on the MS doc 
page with its tiny font...

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Dave Korn wrote:

Thomas Wolff wrote:
  

Selected local directory: H:\cygwin17p1
mkdir:NtCreateFile -> C022
mbox note: Couldn't create directory H:\cygwin17p1, sorry.  (Is drive full or 
read-only?)


  So that's coming from here:

  status = NtCreateFile (&dir,
 STANDARD_RIGHTS_ALL | FILE_LIST_DIRECTORY,
 &attr, &io, NULL, FILE_ATTRIBUTE_DIRECTORY,
 FILE_SHARE_VALID_FLAGS, FILE_CREATE,
 FILE_DIRECTORY_FILE
 | FILE_SYNCHRONOUS_IO_NONALERT
 | FILE_OPEN_FOR_BACKUP_INTENT, NULL, 0);

  Interesting.  Does it possibly succeed if you remove the
FILE_OPEN_FOR_BACKUP_INTENT flag?
  

Unfortunately not.
Any other flags I might remove?

Also I noticed: parameter 5, AllocationSize, should be an int, while 
NULL is a pointer.


Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen wrote:

Thomas,

On Dec  7 17:09, Thomas Wolff wrote:
  

I've tested the network installation with last Saturday's update of
setup-1.7.exe and unfortunately, the problem remains.
However, I can add a screen log after calling setup from mintty for
the case that setup cannot even store its log anywhere (attached).
Don't know if that helps. Apparently setup-1-7.exe cannot create
directories (including the top package directory) on that network
NFTS drive, although all other tools can easily create them.
Despite cgf's point this should not delay the 1.7.1 release, may I
suggest once more (and I'm not adding this to the "1.7.1 release
date" thread) that while the release is being delayed anyway due to
other discussions, we might as well try to resolve this. Personally,
I can do with a workaround; I'm just trying to help avoid trouble
with other users complaining after "the release"...
Thomas



I just had another look into this and unfortunately I still can't
reproduce it.  What I see in your log output is the fact that ...
hang on ...
  

io_stream_cygfile: fopen(/etc/setup/timestamp) failed 13 Permission denied
io_stream_cygfile: fopen(/var/run/utmp) failed 13 Permission denied
io_stream_cygfile: fopen(/etc/setup/alternatives.lst.gz) failed 13 Permission 
denied
[etc]


So the fopen calls fail.  fopen in setup is actually a call to nt_wfopen
in filemanip.cc.  If you could take a look, it's not a very complicated
function.  The general idea is to call NtCreateFile with
FILE_OPEN_FOR_BACKUP_INTENT rights to allow an admin to install without
permission trouble.

As you can see, the error handling (lines 466ff) is somewhat
oversimplified.  You get a "Permission denied" as a fallback error
if none of the path-related errors is triggered.  Unfortunately
we don't know the exact status code returned by NtCreateFile and
I have no real idea what the problem might be.
  
I have traced the status values returned by NtCreateFile (with printf 
actually), see the screen logs attached. I pasted in the popup error 
messages where they occurred.

There is a bunch of the following NtCreateFile problems in the log:
#define STATUS_ACCESS_DENIED ((NTSTATUS)0xC022L)
#define STATUS_OBJECT_NAME_INVALID ((NTSTATUS)0xC033L)
#define STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC034L)
#define STATUS_OBJECT_PATH_NOT_FOUND ((NTSTATUS)0xC03AL)
#define STATUS_OBJECT_PATH_SYNTAX_BAD ((NTSTATUS)0xC03BL)

However, before the fatal error occurs, it's just "STATUS_ACCESS_DENIED" 
in both cases.



What we need is this:  Build a debug version of setup (you need gcc-3
for that since the -mno-cygwin option is still used), start it under
GDB, and set a breakpoint to filemanip.cc:468.  GDB will break there if
an error gets triggered.  Examine what status codes are returned.
See /usr/include/w32api/ddk/ntstatus.h what status code that is.
  
I also ran it with gdb and could just see the same status code that' 
also in my trace log; don't know if there's any other gdb-retrieved 
information you'd like to see.



That might give us some clue.  The only vague idea what you could try
else is to remove the FILE_OPEN_REPARSE_POINT flag from the NtCreateFile
call and see if it works without that.
  
That makes no difference, I tried both versions. The flag is only used 
in filemanip.cc anyway while the problem occurs in mkdir.cc.
Hope this helps a little bit, maybe at least for coming up with further 
debug instructions.


Thomas
Starting cygwin install, version 2.662
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/last-action) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A
io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or 
directory
filemanip:NtCreateFile -> C03B
filemanip:NtCreateFile -> C03A

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen wrote:

On Dec  8 18:21, Thomas Wolff wrote:
  

Corinna Vinschen schrieb:


... Build a debug version of setup (you need gcc-3
for that since the -mno-cygwin option is still used), start it under
GDB, and set a breakpoint to filemanip.cc:468.  GDB will break there if
an error gets triggered.  Examine what status codes are returned.
See /usr/include/w32api/ddk/ntstatus.h what status code that is.
  

OK; since setup is not a cygwin package, where would I get the
sources in the first place? And is there a README telling me how to
build a debug version (make debug?)?


Basically:

  cvs -d :pserver:anon...@cygwin.com:/cvs/cygwin-apps setup
  CC=gcc-3 configure
  make 'CFLAGS=-g'
  

So I don't need to switch set-gcc-default-3.sh, thanks.
Actually, I already checked out and compiled (after installing a bunch 
of dependencies) over night after cgf's pointer to 
http://sources.redhat.com/cygwin-apps/setup.html.
However, I didn't include the -g flag, assuming that leaving out the 
final 'strip' step might suffice.



In case I don't get it compiled, maybe you could prepare two debug
versions (with/w/o the change below) and send them to me? I could
take an extra trip to that lab tomorrow for testing.


Well, yes, but there's very little reason that you shouldn't get it
build.
  
Kind of... I did the small change you suggested and ran make again for a 
second test build, and guess what happens?
It's compiling *everything* again all over; that's not quite the purpose 
of make, is it?
So is it really useful to go over and do the test after that's finished, 
or do I need to recompile two more full times with -g?


Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen schrieb:

Thomas,

On Dec  7 17:09, Thomas Wolff wrote:
  

I've tested the network installation with last Saturday's update of
setup-1.7.exe and unfortunately, the problem remains.
However, I can add a screen log after calling setup from mintty for
the case that setup cannot even store its log anywhere (attached).
Don't know if that helps. Apparently setup-1-7.exe cannot create
directories (including the top package directory) on that network
NFTS drive, although all other tools can easily create them.
Despite cgf's point this should not delay the 1.7.1 release, may I
suggest once more (and I'm not adding this to the "1.7.1 release
date" thread) that while the release is being delayed anyway due to
other discussions, we might as well try to resolve this. Personally,
I can do with a workaround; I'm just trying to help avoid trouble
with other users complaining after "the release"...
Thomas



I just had another look into this and unfortunately I still can't
reproduce it.  What I see in your log output is the fact that ...
hang on ...

  

io_stream_cygfile: fopen(/etc/setup/timestamp) failed 13 Permission denied
io_stream_cygfile: fopen(/var/run/utmp) failed 13 Permission denied
io_stream_cygfile: fopen(/etc/setup/alternatives.lst.gz) failed 13 Permission 
denied
[etc]



So the fopen calls fail.  fopen in setup is actually a call to nt_wfopen
in filemanip.cc.  If you could take a look, it's not a very complicated
function.  The general idea is to call NtCreateFile with
FILE_OPEN_FOR_BACKUP_INTENT rights to allow an admin to install without
permission trouble.

As you can see, the error handling (lines 466ff) is somewhat
oversimplified.  You get a "Permission denied" as a fallback error
if none of the path-related errors is triggered.  Unfortunately
we don't know the exact status code returned by NtCreateFile and
I have no real idea what the problem might be.

What we need is this:  Build a debug version of setup (you need gcc-3
for that since the -mno-cygwin option is still used), start it under
GDB, and set a breakpoint to filemanip.cc:468.  GDB will break there if
an error gets triggered.  Examine what status codes are returned.
See /usr/include/w32api/ddk/ntstatus.h what status code that is.
  
OK; since setup is not a cygwin package, where would I get the sources 
in the first place? And is there a README telling me how to build a 
debug version (make debug?)?
Then I assume I'd use the gdb commands break and print (sorry, not 
familiar with gdb)?


In case I don't get it compiled, maybe you could prepare two debug 
versions (with/w/o the change below) and send them to me? I could take 
an extra trip to that lab tomorrow for testing.


Thomas


That might give us some clue.  The only vague idea what you could try
else is to remove the FILE_OPEN_REPARSE_POINT flag from the NtCreateFile
call and see if it works without that.
  

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

I've tested the network installation with last Saturday's update of 
setup-1.7.exe and unfortunately, the problem remains.
However, I can add a screen log after calling setup from mintty for the 
case that setup cannot even store its log anywhere (attached).
Don't know if that helps. Apparently setup-1-7.exe cannot create 
directories (including the top package directory) on that network NFTS 
drive, although all other tools can easily create them.
Despite cgf's point this should not delay the 1.7.1 release, may I 
suggest once more (and I'm not adding this to the "1.7.1 release date" 
thread) that while the release is being delayed anyway due to other 
discussions, we might as well try to resolve this. Personally, I can do 
with a workaround; I'm just trying to help avoid trouble with other 
users complaining after "the release"...

Thomas

I wrote:

Corinna Vinschen schrieb:

On Nov 25 18:30, Dave Korn wrote:
 

Thomas Wolff wrote:
   

Corinna Vinschen wrote:
 
Are you sure the share permissions are sufficient?  In contrast to 
the

1.5 setup, the 1.7 setup tries to create files and directories with
explicit ACLs.


On the H: drive, I have "full access" according to the Windows
properties dialog.
On the T: drive, I don't, but I have read and write permissions of
course. However, missing rights to modify ACLs might indeed by the 
issue

here.
  

  100%.



 
In usual *nix terms, however, I have sufficient rights to do 
anything I

need, so I think setup.exe might want to be more fault-tolerant here
(and issue more precise error hints), esp. if setting ACLs fails.
  
  Need better error handling, it should fall back to whatever it 
does on FAT

systems.



The files and directories are created with default ACLs.  The POSIX-like
permissions are set afterwards.  It does not matter to setup if setting
the POSIX-like permissions fails.  However, if anything didn't work in
there, you should see this in the setup log.
  

Here is some additional information, and log files attached.

If I try local package dir D:\cygwin17 and network root dir 
H:\cygwin17, I get the error

"unable to extract /etc ..."
(H:\cygwin17 has not even been created, if I do that manually and 
repeat, there is no change)
since there is no root dir and sub-dirs created, there is also no log 
file (or could I have redirected it with setup-1.7.exe?)


If I try network package dir H:\cygwin17 and local root dir D:\cygwin17,
manual creation of H:\cygwin17 is necessary,
and I get that other error;
two log files for this case are attached.

Also here is the output of getfacl for directories on the two network 
drives I had tried:

# file: /cygdrive/h
# owner: Administratoren
# group: 
user::rwx
user:wolff:rwx
group::---
group:SYSTEM:rwx
mask:rwx
other:---
default:user::rwx
default:user:Administratoren:rwx
default:user:wolff:rwx
default:group:SYSTEM:rwx
default:mask:rwx

# file: /cygdrive/h/cygwin
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::---
group:root:rwx
group:SYSTEM:rwx
mask:rwx
other:---
default:user::rwx
default:user:wolff:rwx
default:group:root:rwx
default:group:SYSTEM:rwx
default:mask:rwx



# file: /cygdrive/t/TGI
# owner: Administratoren
# group: 
user::rwx
group::---
group:SYSTEM:rwx
group:Benutzer:r-x
mask:rwx
other:---
default:user::rwx
default:user:Administratoren:rwx
default:group:SYSTEM:rwx
default:group:Benutzer:r-x
default:mask:rwx

# file: /cygdrive/t/TGI/cygwin
# owner: Administratoren
# group: 
user::rwx
group::---
group:SYSTEM:rwx
group:Benutzer:r-x
mask:rwx
other:---
default:user::rwx
default:user:Administratoren:rwx
default:group:SYSTEM:rwx
default:group:Benutzer:r-x
default:mask:rwx


Hope this helps.
Thomas


sh-3.2$ ./setup-1.7.exe 
Starting cygwin install, version 2.661

io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory

io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/last-action) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or 
directory

io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such 
file or directory

Current Directory: d:\

User has NO backup/restore rights

Could not open Service control manager

source: from cwd

root: H:\cygwin17a binary user

io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or 
directory

Selected local directory: d:\cygwin17

Found ini file - 
d:\cygwin17/http%3a%2f%2flinux.rz.ruhr-uni-b

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen schrieb:

On Nov 25 18:30, Dave Korn wrote:
  

Thomas Wolff wrote:


Corinna Vinschen wrote:
  

Are you sure the share permissions are sufficient?  In contrast to the
1.5 setup, the 1.7 setup tries to create files and directories with
explicit ACLs.


On the H: drive, I have "full access" according to the Windows
properties dialog.
On the T: drive, I don't, but I have read and write permissions of
course. However, missing rights to modify ACLs might indeed by the issue
here.
  

  100%.



  

In usual *nix terms, however, I have sufficient rights to do anything I
need, so I think setup.exe might want to be more fault-tolerant here
(and issue more precise error hints), esp. if setting ACLs fails.
  

  Need better error handling, it should fall back to whatever it does on FAT
systems.



The files and directories are created with default ACLs.  The POSIX-like
permissions are set afterwards.  It does not matter to setup if setting
the POSIX-like permissions fails.  However, if anything didn't work in
there, you should see this in the setup log.
  

Here is some additional information, and log files attached.

If I try local package dir D:\cygwin17 and network root dir H:\cygwin17, 
I get the error

"unable to extract /etc ..."
(H:\cygwin17 has not even been created, if I do that manually and 
repeat, there is no change)
since there is no root dir and sub-dirs created, there is also no log 
file (or could I have redirected it with setup-1.7.exe?)


If I try network package dir H:\cygwin17 and local root dir D:\cygwin17,
manual creation of H:\cygwin17 is necessary,
and I get that other error;
two log files for this case are attached.

Also here is the output of getfacl for directories on the two network 
drives I had tried:

# file: /cygdrive/h
# owner: Administratoren
# group: 
user::rwx
user:wolff:rwx
group::---
group:SYSTEM:rwx
mask:rwx
other:---
default:user::rwx
default:user:Administratoren:rwx
default:user:wolff:rwx
default:group:SYSTEM:rwx
default:mask:rwx

# file: /cygdrive/h/cygwin
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::---
group:root:rwx
group:SYSTEM:rwx
mask:rwx
other:---
default:user::rwx
default:user:wolff:rwx
default:group:root:rwx
default:group:SYSTEM:rwx
default:mask:rwx



# file: /cygdrive/t/TGI
# owner: Administratoren
# group: 
user::rwx
group::---
group:SYSTEM:rwx
group:Benutzer:r-x
mask:rwx
other:---
default:user::rwx
default:user:Administratoren:rwx
default:group:SYSTEM:rwx
default:group:Benutzer:r-x
default:mask:rwx

# file: /cygdrive/t/TGI/cygwin
# owner: Administratoren
# group: 
user::rwx
group::---
group:SYSTEM:rwx
group:Benutzer:r-x
mask:rwx
other:---
default:user::rwx
default:user:Administratoren:rwx
default:group:SYSTEM:rwx
default:group:Benutzer:r-x
default:mask:rwx


Hope this helps.
Thomas
2009/11/26 14:34:10 Starting cygwin install, version 2.656
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No 
such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No 
such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/last-action) failed 2 
No such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No 
such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 
2 No such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 
2 No such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 
No such file or directory
2009/11/26 14:34:10 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No 
such file or directory
2009/11/26 14:34:10 io_stream_cygfile: 
fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory
2009/11/26 14:34:10 Current Directory: H:\
2009/11/26 14:34:10 User has NO backup/restore rights
2009/11/26 14:34:10 Could not open Service control manager
2009/11/26 14:34:12 source: network install
2009/11/26 14:34:16 root: D:\cygwin17 binary user
2009/11/26 14:34:16 io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 
No such file or directory
2009/11/26 14:34:20 Selected local directory: H:\cygwin17
2009/11/26 14:34:20 Could not change dir to H:\cygwin17: Das System kann die 
angegebene Datei nicht finden.

 [0002]
2009/11/26 14:34:30 net: Direct
2009/11/26 14:34:30 io_stream_cygfile: fopen(/etc/setup/mirrors-lst) failed 2 
No such file or directory
Cached mirror list unavailable
get_url_to_membuf http://cygwin.com/mirrors.lst
getUrlToStream http://cygwin.com/mirrors.lst
2009/11/26 14:34:36 site: 
http://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin/
get_url_to_membuf 
http://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin//setup-2.bz2
getUrlToStream 
http://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin/

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

Dave Korn schrieb:

...

  Say, has anyone checked it's still possible to install to a FAT fs using the
latest setup.exe?  I might try digging up a pen drive later tonight and see
what happens.
  

Works (FAT32 @ USB).

Thomas

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

ext Corinna Vinschen wrote:

On Nov 24 18:21, Thomas Wolff wrote:
  

I tried this installation to a network drive on one machine again
with last week's new setup.exe, which didn't solve the problem as
Corinna had assumed, but with more detailed test results:
The machine runs Windows XP Professional, drvies H: and T: are
normal Windows mounts or NFTS network drives.
I started setup-1.7.exe from a command line after explicitly
clearing PATH completely.

1. attempt, root dir T:\cygwin17, package dir H:\cygwin17:


---
Fehler
---
Could not change dir to H:\cygwin17: Das System kann die
angegebene Datei nicht finden.

[0002]
---
Abbrechen   Wiederholen   Ignorieren   ---
  

which - by the way - suggests the recent fix about mkdir was not
complete - at least the package directory still had to be created
manually.



I can't reproduce this.  I tried with shares on Samba, with shares on a
remote NTFS on a machine in the same AD domain, and with shares on a
remote machine which is not member of the domain.  In all three cases I
could install Cygwin from scratch just fine, using the latest
setup-1.7.exe.

Are you sure the share permissions are sufficient?  In contrast to the
1.5 setup, the 1.7 setup tries to create files and directories with
explicit ACLs.
On the H: drive, I have "full access" according to the Windows 
properties dialog.
On the T: drive, I don't, but I have read and write permissions of 
course. However, missing rights to modify ACLs might indeed by the issue 
here.
In usual *nix terms, however, I have sufficient rights to do anything I 
need, so I think setup.exe might want to be more fault-tolerant here 
(and issue more precise error hints), esp. if setting ACLs fails.


Now I guess that would explain/solve the "Unable to extract /etc/ -- the 
file is in use." but not the "Can't open 
H:\cygwin17/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f/release-2/alternatives/alternatives-1.3.30c-10.tar.bz2.tmp 
for writing: No such file or directory" because it's full access on that 
drive.
I should also try the other way, using the respective other network 
drive for root dir / package dir, sorry I didn't try that before.


Also, since I am not really familiar with the Windows security stuff, 
any diagnostic hints might help, like where to look at (so I can take 
some screenshots), what tools to use to check rights, or maybe even a 
debug version of setup.exe.


Thomas


  I assumed that this could make problems, but in my case
it just doesn't make any.  When I created the shares, I just made sure
that the share permissions were sufficient.


Corinna

Re: 1.7 installation failed (on network drive?)

[Thomas Wolff]

I tried this installation to a network drive on one machine again with 
last week's new setup.exe, which didn't solve the problem as Corinna had 
assumed, but with more detailed test results:
The machine runs Windows XP Professional, drvies H: and T: are normal 
Windows mounts or NFTS network drives.
I started setup-1.7.exe from a command line after explicitly clearing 
PATH completely.


1. attempt, root dir T:\cygwin17, package dir H:\cygwin17:

---
Fehler
---
Could not change dir to H:\cygwin17: Das System kann die angegebene 
Datei nicht finden.


 [0002]
---
Abbrechen   Wiederholen   Ignorieren   
---


which - by the way - suggests the recent fix about mkdir was not 
complete - at least the package directory still had to be created manually.


2. attempt, after manual mkdir H:\cygwin17:

---
Cygwin Setup
---
Can't open 
H:\cygwin17/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f/release-2/alternatives/alternatives-1.3.30c-10.tar.bz2.tmp 
for writing: No such file or directory

---
OK   
---


3. attempt, this time with a local package dir D:\cygwin17:

---
In-use files detected
---
Unable to extract /etc/ -- the file is in use.

Please stop all Cygwin processes and select "Retry", or

select "Continue" to go on anyway (you will need to reboot).


---
Wiederholen   Abbrechen   
---
This is something that Alexander Quinn also reported these days, but 
since he mentioned C: paths, I don't think he tried network disks, right?


Side remarks:
1. If I hit Continue after the previous message, setup hangs at 
Installing /etc/alternatives/README
2. If I accidently put a space in front of the root directory, setup 
fails with a confusing message "The install directory must be absolute" 
- maybe some simple space stripping could be added here


4. attempt, the other way round: package directory H:\cygwin17, root 
directory D:\cygwin17:

---
Cygwin Setup
---
Can't open 
H:\cygwin17/http%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fdownload%2fcygwin%2f/release-2/alternatives/alternatives-1.3.30c-10.tar.bz2.tmp 
for writing: No such file or directory

---
OK   
---


Only if I finally use local directories for both package and root dir, 
it works.


And to complete the report, as I noted before, installation of 1.5 to 
the same network locations (package and root) works.


Kind regards,
Thomas

1.7 installation failed (on network drive?)

[Thomas Wolff]

I wanted to install 1.7 on another machine, target directory 
H:\cygwin, but it failed with the attached error.
I had to reinstall 1.5, which I did to the same location and 
it worked seamlessly.
Is there a problem installing 1.7 to a network drive?

Thomas




cygwin-install-error.png
Description: Binary data

Please upload: mined-2000.15.4-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.15.4-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.15.4-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

The following versions can be removed:
2000.13
2000.15
2000.15.2

Thank you,
Thomas Wolff

Please upload: mined-2000.15.3-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.15.3-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.15.3-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Re: Suggestion for terminal package maintainers

[Thomas Wolff]

> On 6/2/2009 9:28 AM, Ken Brown wrote:
> > On 6/2/2009 8:48 AM, Corinna Vinschen wrote:
> >> On Jun  1 17:03, Ken Brown wrote:
> >>> The Cygwin console, after some changes made this past weekend, now 
> >>> uses  ^? as the default erase character, and this is what is sent by 
> >>> the  backspace key instead of ^H  
> >>> [...]
> >>
> >> What makes me a bit concerned about this change is that, while we can
> >> change Cygwin's terminfo and termcap files, we can't do that for
> >> existing non-Cygwin installations.  Is it really safe to change the BS
> >> key to ^? now that the "cygwin" terminal type is known to return ^H for
> >> so many years?
> > 
> > Applications like emacs that use ncurses should have no problem.  Are 
> > there applications that rely on the historical behavior of the cygwin 
> > terminal type rather than querying terminfo?  Apart from cygwin, such 
> > applications would have problems with any terminal type that decides to 
> > change its behavior.

> Sorry, I think I misinterpreted what you meant by "non-Cygwin 
> installations".  But wouldn't the issue be resolved by pushing the 
> change to the cygwin terminal type in terminfo upstream?

If it were about termcap/terminfo, it must be expected that an upstream change 
would take years until it propagates to most actual installations, which means 
years of inconsistent default configuration for remote login from 
cygwin console...
On the other hand, with this specific setting, the dreadful backspace issue, 
it is more crucial that the setting of stty is consistent with what the 
terminal 
actually sends. So of course it needs to be made sure that this works 
within cygwin. -
About remote login, it should be noted that Linux systems (some at 
least) as well as SunOS seem to be assuming "stty ^?" on remote login, 
which is obviously not proper behaviour (especially if termcap says something 
different), but that's what I see. So in that respect, typical 
configuration is not consistent right now and would become consistent 
by this change.



2009/6/2 Corinna Vinschen:
> On Jun  2 11:39, Christopher Faylor wrote:
> > > On Tue, Jun 02, 2009 at 05:33:27PM +0200, Corinna Vinschen wrote:
> >> > >Maybe it is, that's why I'm asking.  But, if we do that, shouldn't
> >> > >Ctrl-Backspace return ^H as in xterm?  So far the Cygwin console
> >> > >returned ^H without and ^? with Ctrl, now it returns ^? in both
> >> > >variations.
While it is true that the xterm resource "backarrowKey" would set this 
to ^H by default, most actual Linux installation change it by common 
configuration.

> > > IMO, cygwin's console == linux console.  On two of my systems (Fedora
> > > and Gentoo) CTRL-Backspace returns Backspace on the console.  Now that
> > > I'm at work, I see that CTRL-Backspace returns ^H on my Ubuntu system.
> > > But, so far, the CTRL-Backspace == Backspace contingent is winning.
> 
> Uh, oh, hmm.  I was always under the impression we try to be as xterm
> compatible as possible, rather than the Linux console.
Checking escape sequences of function keys and keypad keys, there are 
many similarities (and common deficiencies) with Linux console and 
some weird differences:
* Linux console (SUSE, don't know if it's really consistent) defines 
  function keys F1...F12 and Shift-F1...Shift-F8 (very weird to stop here).
* Cygwin console Shift-F1 and Shift-F2 are identical to F11 and F12, 
  I don't think that's intended, I guess it should also be changed 
  on the occasion of revising the console.
* Cygwin console has shifted function keys up to Shift-F10, no F11/F12.
* No Control-/Alt-modified function keys (on either console).
* No Control-/Shift-/Alt-modified keypad keys (i.e. cursor keys, Home etc);
  I would very much appreciate if this gets improved, too.
* Cygwin console lacks one feature that is quite useful: cursor position 
  reports. On output of ^[[6n, the terminal should respond an escape 
  sequence encoding the current cursor position.



> 2009/6/3 Corinna Vinschen:
> > Even not knowing the sequence returned by Alt-Backspace, AFAICS, the
> > right thing to do is to send either ^[^? or \377, dependent on the
> > setting of dev_state->metabit.

> I think that's the right thing to do. I'd pointed out the problem with
> Alt+Backspace, but that got lost in the discussion about my suggestion
> to have Ctrl+Backspace send ^_.

> The keycode probably doesn't show up in od output because the pseudo
> terminal device interprets the ^? for line editing purposes.
Not quite the pseudo terminal. It's the readline function (of bash, cat, ...) 
so obviously ^? rubs out the ESC again as it should.
> Attached
> is a small program I use for echoing keycodes, which puts the terminal
> device into raw mode. Quit with ^D.
The following would also serve as a quick test:
stty raw; od -t x1

By the way, I've always wondered why I cannot use "cat" for a quick test 
of most keyboard escape sequences in cygwin. This works quite nicely in 
Linux (except for the c

Please upload: mined-2000.15.2-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.15.2-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.15.2-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint


This is a maintenance release, mainly containing:
* Tweaks for Cygwin console and MinTTY terminals
(but also for Linux/Unix versions in case of remote login, so it's 
an "upstream" update - in case you wonder about the numbering).

Thank you,
Thomas Wolff

Please upload: mined-2000.15-0

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.15-0.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.15-0-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

setup: Cancel button focus is error-prone

[Thomas Wolff]

In setup, the Cancel button should never be focussed by default.
This seems to happen whenever none of the other buttons is enabled, 
e.g. while downloading mirrors.lst and setup.bz2 files.
During this time, it is likely to accidently cancel setup by just 
hitting Enter when the user actually wants to continue setup (and hits 
Enter a little bit early).
This is "unexpected behaviour" in terms of usability and should be changed.

Kind regards,
Thomas Wolff

Re: Updated: xterm 229

[Thomas Wolff]

Hi,
thanks for updating xterm. Finally, it works again (did not work 
for me for 3 years due to immediate crash after start...).
I am wondering, however, why you configured out support of the -u8 
option. I recompiled xterm 229 with full feature support and 
-u8 gives me a nicely working Unicode terminal, regardless of 
cygwin's broken locale support. Please change that for an update.

Usage note: depending on the application, it may help to set 
the locale environment properly when starting a UTF-8 xterm. This 
would have to be done manually.
The editor joe edits UTF-8 well with proper LC_ALL setting.
The editor mined edits UTF-8 even without proper LC_ALL setting.

Kind regards,
Thomas Wolff

Please upload: mined-2000.14-2 (bin + src)

[Thomas Wolff]

OK, sorry for the version mismatch, here is the fix:
Please upload the fixed update packages for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.14-2.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.14-2-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2000.14-2

[Thomas Wolff]

Unfortunately I made an error when packaging the binary package 
for mined 2000.14, please upload the fixed update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.14-2.tar.bz2
#unchanged: wget http://towo.net/mined/cygwin/mined-2000.14-1-src.tar.bz2
#unchanged: wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2000.14-1

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.14-1.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.14-1-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2000.13.2-1

[Thomas Wolff]

Please upload the release update package for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.13.2-1.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.13.2-1-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Re: ITP: rxvt-unicode-X

[Thomas Wolff]

I have now succeeded in finishing my Unicode support hook for rxvt on 
cygwin (almost, as far as Unicode operation is concerned).
There were some more obstacles to take which I will describe below in 
case anyone is interested :)

A few problems remain:
* If I start rxvt in NON-Unicode mode, 8 bit input doesn't work. This 
  also happens with the unpatched rxvt-unicode 6.0 (compiled from the 
  source archive), but it works in Charles' package, so I would hope 
  that the patch is applicable to the package without injecting this 
  error.
* The wchar_t type on cygwin is only "unsigned short", raising a minor 
  problem with handling Unicode characters beyond 16 bit; my patch is 
  now mapping the output to the Unicode replacement character U+FFFD.
  Substituting a sufficiently wide type might work but would require 
  more subtle modifications to the code.
* Charles pointed out that an application can use setlocale multiple 
  times, switching encoding dynamically, and that rxvt actually does 
  that (although I didn't understand for which purpose). Anyway, 
  a proper substitution of setlocale that mimics this behaviour is 
  still missing in my patch library.
* Suspected remaining handling bug in 'draw_string' as described below.

To apply the patch, please unzip the uwc.zip archive in the rxvt 
src subdirectory. Then invoke the uwc script which applies the patch 
generically, by substituting the respective function names in the 
source files. The final "return NOCHAR" fix described below still has 
to be applied manually, sorry.
The patch can be downloaded from 

Thomas



Now about the problems I had:
* First, I had to remove one more bug in my wide character replacement 
  functions in order to avoid an occasional crash. Alright.
* Then, Unicode input still would not work. I found that indeed I had 
  overlooked one function to be replaced which is XwcLookupString.
  The code in rxvt (command.C) has an alternative invocation of 
  Xutf8LookupString which is commented "// currently disabled, doesn't 
  seem to work, nor is useful".
  It turns out that it is indeed very useful in making input work; the 
  reason the disabled rxvt code could not work is that the return 
  values are not handled properly.
* Finally, there was some occasional weird display garbage remaining 
  which I am describing below in some detail because there is some 
  really buggy rxvt code involved.

When displaying a long string to the screen it may happen that 
rxvt splits a single UTF-8 character into subsequent fills of some 
internal buffer. (I could not observe this on Linux, however, where 
the buffer seems to be chosen always long enough to fit in the complete 
output, whereas on cygwin it seems to have a maximum length of 257 bytes.)

Then at the end of the buffer, rxvt invokes mbrtowc with an incomplete 
UTF-8 sequence:

mbrtowc (& wc, C3 BC E2, 3, & ps) -> 2, wc = FC
mbrtowc (& wc, E2, 1, & ps) -> -1, wc unchanged
now the continuation of E2, combining to E2 80 A7, the dot symbol U+2027:
mbrtowc (& wc, 80 A7 C3 A4 C3 B6 C3 9F ..., 257, & ps) -> -1, wc unchanged
mbrtowc (& wc, A7 C3 A4 C3 B6 C3 9F E2 ..., 256, & ps) -> -1 wc unchanged
mbrtowc (& wc, C3 A4 C3 B6 C3 9F E2 87 ..., 255, & ps) -> 2 wc = E4

The display produced is "üâ§ä" instead of "ü‧ä".

A sample program xwrite.c demonstrating the bug is included in uwc.zip 
(only if the "return NOCHAR" fix below has not yet been applied).


When I further analysed the mbrtowc function (on Linux where it works), 
it turned out that it maintains a state of incomplete UTF-8 and is 
able to automatically consider this with a continuation sequence 
requested later. Also some comments in the rxvt source suggest that 
rxvt might even depend on this undocumented behaviour. So I 
reimplemented it with my cygwin mbrtowc replacement but the display 
bug remained. It finally turned out that rxvt does not need this 
"feature" (or rather bug, as it's not documented), at least not for 
screen display.

So I checked the invocations of mbrtowc in rxvt in command.C and 
menubar.C; I thought it was the latter because it's inside a function 
called 'draw_string' which quite clearly suggests that it would be used 
for screen display but it was not the case.
It rather turned out that the function 'next_char' in command.C is 
handling screen output which is really weird (the function is 
commented "// read the next octet").
The function has the return option
  if (len == (size_t)-1) {
return *cmdbuf_ptr++;
with the comment 
"// the _occasional_ latin1 character is allowed to slip through"; 
now this sounds mega-weird - why should something that't not right 
be allowed to slip through? Anyway, replacing this with just
  if (len == (size_t)-1) {
return NOCHAR;
finally solves the display problem and there we are with a working 
rxvt-unicode on cygwin.


A rem

Re: ITP: rxvt-unicode-X

[Thomas Wolff]

Sorry for the very late response, but I've finally succeessfully 
pursuaded rxvt-unicode now to actually support Unicode on cygwin, 
and I'd like to suggest to include that in the package.


Charles Wilson wrote on Tue, 21 Mar 2006 16:54:11 -0500:

> >   ...
> >   So what is the actual "newlib" problem that prevents rxvt from 
> >   supporting Unicode - apparently even from trying to support it?

> I don't know.  All I know is that (a) I didn't see it actually work, and
> (b) I've read other reports that unicode doesn't actually work on
> cygwin.  Maybe I'm wrong.  I'm pretty clueless on unicode issues: do I
> need a specific unicode font to even try it?  How many LC_* variables
> *should* I have to set in order to "enable" unicode -- say, if I were on
> a Linux system will full unicode support?  I dunno.  I was hoping others
> with more experience could use my package -- or my build system -- and
> experiment, reporting successess and failures.  I know, that's fairly
> pollyanna-ish of me, but...  I was eventually planning on building
> rxvt-unicode with identical options over on my Linux box, and play
> around with it there, but that's a roudtuit item.

Some general remarks:
Depending on the application, Unicode may be triggered either
1) explicitly or
2) using the locale mechanism (which is bogus on cygwin).
   It should be noted that the set of locale variables (LC_* and LANG) 
   are not identical to the locale mechanism which needs addtional 
   library support.

1) For example, xterm has an explicit command line option:
xterm -u8
   which invokes xterm in UTF-8 mode. Additional configuration is 
   needed to use Unicode fonts. And LC_* variables are unfortunately 
   not set implicitly in this invocation mode which confuses many 
   applications.

   My package mined includes a script uterm which invokes xterm in a 
   suitable mode, including font setup. Cygwin/X does include some 
   Unicode fonts, but apparently a very outdated version of them with 
   a very limited character range. I would offer to maintain a package 
   of Unicode X fonts if that helps.

2) Rxvt insists on locale configuration to provide desired encodings.
   This means, you would have to invoke rxvt like this:
LC_CTYPE=en_US.UTF-8 rxvt
   or
LC_ALL=vi_VN rxvt
   (Note: vi_VN is one of the UTF-8 locales that lack the usual 
   indication suffix.)
   And rxvt would run in UTF-8 mode where the locale mechanism 
   works (which it doesn't on cygwin).


The reason why I couldn't trick out rxvt before by just setting the 
variables was that it also depends on the wide character library 
functions which in turn depend on a working locale mechanism.
I have now replaced those functions (well, the subset of them needed 
by rxvt) with substitutes that either operate in UTF-8 mode, or 
delegate to the system functions, depending on the setting of the 
locale variables, and it works. At least it does so for display, 
although it suppresses 8-bit input for some obscure reason still to be 
found.

I will send the files to you (Charles Wilson) directly and would 
appreciate if you confirm the solution.

Kind regards,
Thomas Wolff

Re: best practice for upgrading config files?

[Thomas Wolff]

Igor Peshansky wrote:

> ... If the user has modified the default configuration,
> she most likely knows what she is doing, and probably wouldn't want the
> installation to muck with her changes (not even if we could create diffs
This is certainly true.
(On the other hand, having experienced this nuisance of certain packages 
a number of times, it is good advice anyway not to rely on changing 
system configurations whenever possible, but rather add overriding local 
configurations.)

But - again on the other hand - if a new release brings in additional 
parameters, I would of course want them to show up in the configuration 
so they become effective (and configurable :).

> with the previous version and cleanly apply the patch).  What would be
> nice in this case, though, is some feedback like "Not replacing config
> file /etc/lftp.conf due to user changes" to the postinstall script's
> stdout, which will end up in the setup.log file.

Considering what I said above, I think an automatic merge would be the 
best, not changing modified parameters, and adding any new parameters.
Apart from some moderate handling effort, the only remaining problem 
would be whether to change default values of previously unchanged 
parameters - which might have been deliberately unchanged by the 
user!

> > (3) Compute a checksum of the current /etc/lftp.conf, and compare it to
> > the checksum of the old default.  If they're the same, then the user
> > hasn't touched the old default so copy the new default in.  If they're
> > different, then prompt the user as in (2).  So we need to store
> > checksums of default config files somewhere.  This is Debian's method.
> > ...

> 2) In the preremove, compare each config file from the manifest with the
>current default version of that file, and remove the config file if
>they are identical (using cmp).
> ...

Approaches which either can only replace or not, depending on 
comparison of the complete file, or delegate all merging problems to 
the user, are unsuitable for my taste.

Kind regards,
Thomas Wolff

Please upload: mined-2000.12-3

[Thomas Wolff]

Please upload another package fix for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.12-3.tar.bz2
#unchanged: wget http://towo.net/mined/cygwin/mined-2000.12-2-src.tar.bz2
#unchanged: wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2000.12-2

[Thomas Wolff]

Due to some problems in the binary and source archives, 
please upload another version update for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.12-2.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.12-2-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Please upload: mined-2000.12-1

[Thomas Wolff]

Please upload the version update packages for mined:


mkdir mined
cd mined
wget http://towo.net/mined/cygwin/mined-2000.12-1.tar.bz2
wget http://towo.net/mined/cygwin/mined-2000.12-1-src.tar.bz2
wget http://towo.net/mined/cygwin/setup.hint

Thank you,
Thomas Wolff

Re: [HEADSUP] ALL Maintainers, please reply.

[Thomas Wolff]

> So, ALL maintainers of Cygwin packages,
> 
>   please reply to this mail within the next six weeks,
>
>   including a list of ALL packages you maintain.

mined

Thomas Wolff

Please upload: mined-2000.11-1

[Thomas Wolff]

Please upload the version update packages for mined 2000.11
from http://towo.net/mined/cygwin/




More information (with screenshots, feature overview and change log) 
and download are available from the mined web site at
http://towo.net/mined/


Mined is co-hosted at sourceforge and has a mailing list 
which can be subscribed at
<https://lists.sourceforge.net/lists/listinfo/mined-editor>




Major enhancements in this release:

Unicode support enhancements:

* Updated to Unicode 4.1.0:
  * Case conversion, Script information.
  * Combining character width properties.
  * Han information (from Unihan database) for CJK characters.
  * Radical/Stroke input method (to include new CJK characters).
  * Added Hanyu Pinlu and Tang pronunciation information 
(from Unihan database) to Han information options.
  * Added generic and supplemental character input mnemonics 
for new LATIN characters.
* Indication and character information of Unicode combining characters 
  now refers to the most recent Unicode version, not the actual 
  terminal capabilities.

Interactive enhancements:
* Conciliated keypad assignment preference conflict between Cut/Paste 
  functions (as propagated by mined) and character deletion / line 
  positioning functions (as often commonly expected):
  * The more common Home/End/Delete function assignments to the 
respective keypad keys are also easily accessible (e.g. Alt-Del).
  * Documentation for alternative assignment option improved.
  * Using Del without a paste buffer gives an additional hint on 
alternative usage.
* Pull-down menus are now scrollable so they are always displayed 
  (also the large menus in small terminal windows).
* Additional assignment of "Delete single" function (to delete without 
  auto-undent, or to delete the last combining accent only) to F5 
  Backarrow.
* Additional commands (HOP) F1 F1 / Shift-F1 / Control-F1 / Alt-F1 to 
  display a help status line of (shifted) function key assignments.
* Slight revision of function key assignments to improve intuitive 
  usage and compliance with common usage.
  Unification of DOS version function key assignments.

Interoperability enhancements:
* Improved detection of shifted function keys on various kinds and 
  modes of terminals.
* Added keyboard configuration examples for Control-function key 
  detection for rxvt and mlterm to the runtime support library.
* Added script to support Unicode X font installation to the runtime 
  support library.
* Modified xterm start script "uterm" so that with newer xterm 
  versions (from 201) usage of the xterm built-in most recent version 
  of Unicode width data is enabled (which is often more current than 
  the system-provided locale version).
* Provided makefile for Interix.

Feature enhancements:
* Smart arrows added to optional smart input text replacements.
* New word case toggle function Shift-F3 cycling word casing between 
  all small, beginning capital, and all capitals.
* The "search corresponding bracket" commands ESC ( or ESC ) now also 
  match /* */ pairs and #if #else/#elsif #endif structures.
* New TAB expansion option (-+4 or -+8) that expands TAB key input to 
  an appropriate number of Space characters.

Further enhancements:
* Using paps (a Pango printing script) for printing if available.
* Added PC DOS encoding ("codepage 437") to available encodings.


--------
Thank you,
Thomas Wolff