Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Ken Brown wrote:
> I'm running Win7 in case that makes a difference.

Here on Win XP SP3, 32 bit. I haven't W7 :(

> Corinna, are there changes in the 20100910 snapshot that could explain this?

Anyway it would be a remarkable coincidence that 20100910 snapshot 
ChangeLog says:

[...]
2010-09-10  Corinna Vinschen  <corinna@vinschen.de>

	* flock.cc (allow_others_to_sync): Define MAX_PROCESS_SD_SIZE.  Use
	instead of ACL_DEFAULT_SIZE.
	* sec_acl.cc (setacl): Use TLS buffer to allow maximum ACL size.
	* security.h (ACL_DEFAULT_SIZE): Drop definition.
	(ACL_MAXIMUM_SIZE): Define.
	(SD_MAXIMUM_SIZE): Define.
	* security.cc (get_file_sd): Allocate security_decscriptor with size
	SD_MAXIMUM_SIZE.
	(alloc_sd): Use TLS buffer to allow maximum ACL size.
[...]


Ciao,
Angelo.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  5 15:36, Angelo Graziosi wrote:
> Ken Brown wrote:
> >I'm running Win7 in case that makes a difference.
> 
> Here on Win XP SP3, 32 bit. I haven't W7 :(
> 
> >Corinna, are there changes in the 20100910 snapshot that could explain this?
> 
> Anyway it would be a remarkable coincidence that 20100910 snapshot
> ChangeLog says:
> 
> [...]
> 2010-09-10  Corinna Vinschen  <BEEP>

Please do NOT quote raw email addresses.

> [...]

The patch you're quoting only raises the size of the buffers so that
even the biggest ACL fits into them.  So far we were restricted to 3K
ACLs in some circumstances.  However, there's another change in this
snapshot which might explain what happens:

  * security.cc (get_file_sd): Add bool parameter justcreated.  Use
  GetSecurityInfo only if justcreated is true, NtQuerySecurityObject
  otherwise.  Add comment to explain why.  Don't waste time to call
  NtQuerySecurityObject twice, just allocate big enough area.
  (get_file_attribute): Call get_file_sd with justcreated set to false.
  [...]

I don't see at all how this is possible, though.  Hmm.

I'm still running the installation myself, but it takes such a long
time.

"A kingdom for a simple testcase"(TM)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  7 11:11, Corinna Vinschen wrote:
> On Mar  5 15:36, Angelo Graziosi wrote:
> > Ken Brown wrote:
> > >I'm running Win7 in case that makes a difference.
> > 
> > Here on Win XP SP3, 32 bit. I haven't W7 :(
> > 
> > >Corinna, are there changes in the 20100910 snapshot that could explain this?
> > 
> > Anyway it would be a remarkable coincidence that 20100910 snapshot
> > ChangeLog says:
> > 
> > [...]
> > 2010-09-10  Corinna Vinschen  <BEEP>
> 
> Please do NOT quote raw email addresses.
> 
> > [...]
> 
> The patch you're quoting only raises the size of the buffers so that
> even the biggest ACL fits into them.  So far we were restricted to 3K
> ACLs in some circumstances.  However, there's another change in this
> snapshot which might explain what happens:
> 
>   * security.cc (get_file_sd): Add bool parameter justcreated.  Use
>   GetSecurityInfo only if justcreated is true, NtQuerySecurityObject
>   otherwise.  Add comment to explain why.  Don't waste time to call
>   NtQuerySecurityObject twice, just allocate big enough area.
>   (get_file_attribute): Call get_file_sd with justcreated set to false.
>   [...]
> 
> I don't see at all how this is possible, though.  Hmm.
> 
> I'm still running the installation myself, but it takes such a long
> time.
> 
> "A kingdom for a simple testcase"(TM)

Ok, I found a simpler testcase.  If you have the texmf-bin package
installed, just try this:

  $ cd /var/lib/texmf/web2c
  $ rm -f aleph.*
  $ aleph -ini -jobname=aleph -progname=aleph *aleph.ini > /dev/null
  $ ls -l aleph.*

and you'll see that the aleph.* files have not 0644, but other, wrong
permissions.

As I expected the aforementioned patch is the culprit, but in an
entirely unexpected way.  Basically, the patch adds a bool parameter to
the functions get_file_sd.  If it's true, the Win32 function
GetSecurityInfo is called, just like before, if it's false, the native
NT function NtQuerySecurityObject is called instead.

Now, for some reason, on XP, but not on Windows 7, the call to
GetSecurityInfo suddenly fails with an error 487, ERROR_INVALID_ADDRESS.
Apart from the fact that it's not always called anymore, nothing has
changed in the way GetSecurityInfo is called!

I tried various changes, but to no avail.  I have not the faintest clue
why GetSecurityInfo suddenly fails on XP.  The only way I can get
GetSecurityInfo to work on XP is by removing the additional bool
parameter :-(


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Corinna Vinschen wrote:
> I applied a patch to CVS and just uploaded a new snapshot to
> http://cygwin.com/snapshots/
>
> Please give it a try.  David, this is for you, too.

The problem is fixed for me. Thanks a lot!

Ciao,
Angelo.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Corinna Vinschen wrote:
> Ok, I found a simpler testcase.

Thanks for you work and your patience...

> Please do NOT quote raw email addresses.

Usually I remove always that... not this time. I apologize..

..and, what about David's report (*)? I am just curios..

Ciao,
Angelo.

---
(*) http://cygwin.com/ml/cygwin/2011-03/msg00184.html

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  7 18:00, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> >Ok, I found a simpler testcase.
> 
> Thanks for you work and your patience...
> 
> >Please do NOT quote raw email addresses.
> 
> Usually I remove always that... not this time. I apologize..
> 
> ..and, what about David's report (*)? I am just curios..

I have no idea.  I guess it's the same underlying problem.  I still
have no idea why the GetSecurityInfo call fails.  There's no visible
logic to this problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  7 20:12, Corinna Vinschen wrote:
> On Mar  7 18:00, Angelo Graziosi wrote:
> > Corinna Vinschen wrote:
> > >Ok, I found a simpler testcase.
> > 
> > Thanks for you work and your patience...
> > 
> > >Please do NOT quote raw email addresses.
> > 
> > Usually I remove always that... not this time. I apologize..
> > 
> > ..and, what about David's report (*)? I am just curios..
> 
> I have no idea.  I guess it's the same underlying problem.  I still
> have no idea why the GetSecurityInfo call fails.  There's no visible
> logic to this problem.

I found the problem, or at least I could narrow down the effect.  It
occurs only on XP and Server 2003, afaics, on 32 as well as on 64 bit
versions.  Hard to explain.  For the curious, just have a look into
http://cygwin.com/ml/cygwin-developers/2011-03/msg00027.html

I applied a patch to CVS and just uploaded a new snapshot to
http://cygwin.com/snapshots/

Please give it a try.  David, this is for you, too.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[David Rothenberger]

On 3/8/2011 7:01 AM, Corinna Vinschen wrote:
> On Mar  7 20:12, Corinna Vinschen wrote:
> I found the problem, or at least I could narrow down the effect.  It
> occurs only on XP and Server 2003, afaics, on 32 as well as on 64 bit
> versions.  Hard to explain.  For the curious, just have a look into
> http://cygwin.com/ml/cygwin-developers/2011-03/msg00027.html
> 
> I applied a patch to CVS and just uploaded a new snapshot to
> http://cygwin.com/snapshots/
> 
> Please give it a try.  David, this is for you, too.

Solves the problem with Subversion, too. Thanks!

-- 
David Rothenberger  ----  daveroth@acm.org

QOTD:
        I'm not bald -- I'm "hair challenged".

        [I thought that was "differently haired". Ed.]

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Corinna Vinschen wrote:
> Since fmtutil-sys is apparently the core of the problem, and given
> my total lack of knowledge about the Tex/Latex system, is there any
> simple call to fmtutil-sys with which I can reproduce the problem
> without having to install texlive?

It seems too difficult for me. fmtutil-sys is a bash script which calls 
another bash script, fmtutil, which in turn calls a bunch of binaries 
(as results from intall-tl.log) in the form like this:

aleph -ini   -jobname=aleph -progname=aleph *aleph.ini
aleph -ini   -jobname=lamed -progname=lamed *lambda.ini
pdftex -ini   -jobname=amstex -progname=amstex -translate-file=cp227.tcx 
*amstex.ini
[...]

It seems that the binaries aleph, pdftex... are passed via a fmtutil.cnf 
configuration file.

Anyway, with a binary testing (only .dll.bz2 of snapshots), I have 
verified that the last snapshot with which the .fmt files get the right 
permissions (-rw-r--r--) is 20100904 snapshot, instead with 20100910 
they acquires wrong permissions (rwx------). In short, after >= 20100910 
  snapshot, fmtutil script creates /tmp/fmtutil.NUMBER with drwx-----+ 
permissions: fmtutil.NUMBER is a working directory for fmtutil.

This is the best I could do!

For the moment I will adopt this manual fix :(

find /usr/local/texlive/ \! -type d \! -type l -perm u=rwx | xargs chmod 
-x,go+r


Ciao,
Angelo.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Ken Brown]

On 3/5/2011 5:22 AM, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
>> Since fmtutil-sys is apparently the core of the problem, and given
>> my total lack of knowledge about the Tex/Latex system, is there any
>> simple call to fmtutil-sys with which I can reproduce the problem
>> without having to install texlive?
>
> It seems too difficult for me. fmtutil-sys is a bash script which calls
> another bash script, fmtutil, which in turn calls a bunch of binaries
> (as results from intall-tl.log) in the form like this:
>
> aleph -ini   -jobname=aleph -progname=aleph *aleph.ini
> aleph -ini   -jobname=lamed -progname=lamed *lambda.ini
> pdftex -ini   -jobname=amstex -progname=amstex -translate-file=cp227.tcx
> *amstex.ini
> [...]
>
> It seems that the binaries aleph, pdftex... are passed via a fmtutil.cnf
> configuration file.
>
> Anyway, with a binary testing (only .dll.bz2 of snapshots), I have
> verified that the last snapshot with which the .fmt files get the right
> permissions (-rw-r--r--) is 20100904 snapshot, instead with 20100910
> they acquires wrong permissions (rwx------). In short, after>= 20100910
>    snapshot, fmtutil script creates /tmp/fmtutil.NUMBER with drwx-----+
> permissions: fmtutil.NUMBER is a working directory for fmtutil.

The permissions on the working directory are not surprising (except 
perhaps for the `+'), since the directory is created by fmtutil with the 
command

   (umask 077; mkdir "$tmpdir")

But on my system, running the latest snapshot, the files within that 
directory still get the expected 644 permissions.  I'm running Win7 in 
case that makes a difference.  At the moment I don't have access to an 
XP system to test this on.

I wonder if this has nothing to do with texlive or fmtutil, but is 
simply a problem with the ACLs on a directory created with umask 077. 
Corinna, are there changes in the 20100910 snapshot that could explain 
this?  And would there be a difference between XP and Win7?

Ken

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  5 08:47, Ken Brown wrote:
> On 3/5/2011 5:22 AM, Angelo Graziosi wrote:
> >Anyway, with a binary testing (only .dll.bz2 of snapshots), I have
> >verified that the last snapshot with which the .fmt files get the right
> >permissions (-rw-r--r--) is 20100904 snapshot, instead with 20100910
> >they acquires wrong permissions (rwx------). In short, after>= 20100910
> >   snapshot, fmtutil script creates /tmp/fmtutil.NUMBER with drwx-----+
> >permissions: fmtutil.NUMBER is a working directory for fmtutil.
> 
> The permissions on the working directory are not surprising (except
> perhaps for the `+'), since the directory is created by fmtutil with
> the command
> 
>   (umask 077; mkdir "$tmpdir")

The '+' isn't surprising either.  When creating a directory, Cygwin
always adds default ACEs for "creator owner", "creator group", and
"everyone".  These ACEs are added for the sake of native Win32
applications.  If a Win32 application creates files or directories, it
usually omits the security descriptor, so the default settings are used.
If the parent directory has no default settings, the default DACL from
the application's user token is used.  That default DACL is not very
useful for files, though.

> But on my system, running the latest snapshot, the files within that
> directory still get the expected 644 permissions.  I'm running Win7
> in case that makes a difference.  At the moment I don't have access
> to an XP system to test this on.

It doesn't make a difference.  It works fine for me when creating files
in such a directory manually, regardless of the OS.  So the scenario
in which this occurs is a bit more complicated, apparently.

> I wonder if this has nothing to do with texlive or fmtutil, but is
> simply a problem with the ACLs on a directory created with umask
> 077. Corinna, are there changes in the 20100910 snapshot that could
> explain this?  And would there be a difference between XP and Win7?

No, not really.  The permissions of a directory should really only
affect the permissions of files created by native Win32 apps.  Or,
it would affect Cygwin apps if the is under a noacl mount.  But in
that case you wouldn't see it, because Cygwin would fake 755/644
permissions.

And then there's rename.  If a file gets renamed from /src/foo to
/dest/foo, the ACL of the file wouldn't be changed.  However, if
/src is a noacl mount, we don't have control over the ACL at
file creation time.  If /dest is a acl mount, we would then see
POSIX permissions which reflect the Win32 ACL of that file.  This
might explain the effect.  It does *not* explain why this should
only occur with newer snapshots, though.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Corinna Vinschen wrote:
> Since fmtutil-sys is apparently the core of the problem, and given
> my total lack of knowledge about the Tex/Latex system, is there any
> simple call to fmtutil-sys with which I can reproduce the problem
> without having to install texlive?

You are right. I will try...

...now, just for completeness, I have tried to rebuild the TL2010 
binaries under the current snapshot (20110303), but...

-------------------------------------------------------
gcc -DHAVE_CONFIG_H -I. -I../../../texk/xdvik -I../../../texk/xdvik/gui 
-DPS_GS -I/tmp/texlive-source/Work/texk -I/tmp/texlive-source/texk 
-I/tmp/texlive-source/Work/libs/t1lib     -Wimplicit -Wreturn-type 
-Wdeclaration-after-statement -Wno-unknown-pragmas -Wno-write-strings 
-Wno-attributes -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o 
../../../texk/xdvik/main.c
sed -f sedscript <../../../texk/xdvik/xdvi.1.in >xdvi.1
In file included from /usr/include/errno.h:9,
                  from /tmp/texlive-source/texk/kpathsea/c-errno.h:22,
                  from /tmp/texlive-source/texk/kpathsea/c-std.h:74,
                  from /tmp/texlive-source/texk/kpathsea/config.h:88,
                  from ../../../texk/xdvik/xdvi.h:43,
                  from ../../../texk/xdvik/main.c:10:
/usr/include/sys/errno.h:25: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '.' token
/usr/include/sys/errno.h:26: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '.' token
make[5]: *** [main.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory `/tmp/texlive-source/Work/texk/xdvik'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/tmp/texlive-source/Work/texk/xdvik'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/tmp/texlive-source/Work/texk/xdvik'
make[2]: *** [subtexk] Error 1
make[2]: Leaving directory `/tmp/texlive-source/Work/texk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/texlive-source/Work/texk'
make: *** [all-recursive] Error 1

real	80m39.341s
user	91m3.353s
sys	57m7.051s
+ echo 2
/tmp/texlive-source/Build: Build failed, no executables under 
/tmp/texlive-source/inst/bin.
done Fri Mar 4 19:09:53 2011
-------------------------------------------------------

The same sources built fine on September with 1.7.7.

Ciao,
Angelo.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Christopher Faylor]

On Fri, Mar 04, 2011 at 07:26:11PM +0100, Angelo Graziosi wrote:
>Corinna Vinschen wrote:
>> Since fmtutil-sys is apparently the core of the problem, and given
>> my total lack of knowledge about the Tex/Latex system, is there any
>> simple call to fmtutil-sys with which I can reproduce the problem
>> without having to install texlive?
>
>You are right. I will try...
>
>...now, just for completeness, I have tried to rebuild the TL2010 
>binaries under the current snapshot (20110303), but...
>
>-------------------------------------------------------
>gcc -DHAVE_CONFIG_H -I. -I../../../texk/xdvik -I../../../texk/xdvik/gui 
>-DPS_GS -I/tmp/texlive-source/Work/texk -I/tmp/texlive-source/texk 
>-I/tmp/texlive-source/Work/libs/t1lib     -Wimplicit -Wreturn-type 
>-Wdeclaration-after-statement -Wno-unknown-pragmas -Wno-write-strings 
>-Wno-attributes -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o 
>../../../texk/xdvik/main.c
>sed -f sedscript <../../../texk/xdvik/xdvi.1.in >xdvi.1
>In file included from /usr/include/errno.h:9,
>                  from /tmp/texlive-source/texk/kpathsea/c-errno.h:22,
>                  from /tmp/texlive-source/texk/kpathsea/c-std.h:74,
>                  from /tmp/texlive-source/texk/kpathsea/config.h:88,
>                  from ../../../texk/xdvik/xdvi.h:43,
>                  from ../../../texk/xdvik/main.c:10:
>/usr/include/sys/errno.h:25: error: expected '=', ',', ';', 'asm' or 
>'__attribute__' before '.' token
>/usr/include/sys/errno.h:26: error: expected '=', ',', ';', 'asm' or 
>'__attribute__' before '.' token
>make[5]: *** [main.o] Error 1
>make[5]: *** Waiting for unfinished jobs....
>make[5]: Leaving directory `/tmp/texlive-source/Work/texk/xdvik'
>make[4]: *** [all-recursive] Error 1
>make[4]: Leaving directory `/tmp/texlive-source/Work/texk/xdvik'
>make[3]: *** [all] Error 2
>make[3]: Leaving directory `/tmp/texlive-source/Work/texk/xdvik'
>make[2]: *** [subtexk] Error 1
>make[2]: Leaving directory `/tmp/texlive-source/Work/texk'
>make[1]: *** [all-recursive] Error 1
>make[1]: Leaving directory `/tmp/texlive-source/Work/texk'
>make: *** [all-recursive] Error 1
>
>real	80m39.341s
>user	91m3.353s
>sys	57m7.051s
>+ echo 2
>/tmp/texlive-source/Build: Build failed, no executables under 
>/tmp/texlive-source/inst/bin.
>done Fri Mar 4 19:09:53 2011
>-------------------------------------------------------
>
>The same sources built fine on September with 1.7.7.

If you look at the line in question you'll see that something in the
sources that you're trying to compile is incorrectly defining
program_invocation_name and program_invocation_short_name.

cgf

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Ken Brown wrote:
> I think fmtutil creates the files in a temporary directory (using TMPDIR, TEMP, or TMP if they exist) and then mv's them. Could this be your problem? What happens if you unset those variables before installing texlive?

It is some time that my Cygwin installation does not set those variables 
any more, and indeed they are all EMPTY.. Perhaps is the TL installation 
process that sets them, at least temporary. And if so, why that does not 
occur with 1.7.7? Why not with other files under TL installed tree?

Ciao,
Angelo.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  4 17:49, Angelo Graziosi wrote:
> Ken Brown wrote:
> >I think fmtutil creates the files in a temporary directory (using TMPDIR, TEMP, or TMP if they exist) and then mv's them. Could this be your problem? What happens if you unset those variables before installing texlive?
> 
> It is some time that my Cygwin installation does not set those
> variables any more, and indeed they are all EMPTY.. Perhaps is the
> TL installation process that sets them, at least temporary. And if
> so, why that does not occur with 1.7.7? Why not with other files
> under TL installed tree?

Since fmtutil-sys is apparently the core of the problem, and given
my total lack of knowledge about the Tex/Latex system, is there any
simple call to fmtutil-sys with which I can reproduce the problem
without having to install texlive?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Corinna Vinschen wrote:
> If you see that behaviour as part of
> a perl script, you should also see that which every other tool,
> even simple stuff like `echo foo > bar'.

Really the perl script, at some time, calls (in a posta install action) 
'fmutil-sys --all', which creates the .fmt file with wrong permission.

Ciao,
Angelo.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

Corinna Vinschen wrote:
> What about some helpful details which allow to reproduce your problem?
> Like, say, how to get the packages, how you install them, stuff like
> that.  You seem to imply that everybody knows how to do that.  I don't.

Sorry, I have omitted details because TL2010 is a full distribution of 
LaTeX. Anyway, just for completeness..

Usually TL2010 can be installed via the WEB (*), but I maintain a local 
repository:

rsync -avz --delete --exclude=*mactex* tug.org::texlive/tlnet/ ./tlnet_repo

(tlnet_repo is about 1.7G). When one has the repository, it is simple to 
install (Cygwin is officially supported). As 'root' I do:

./tlnet_repo/install-tl

(it is a Perl script).

Here, usually I choose to change the installation directory from 
/usr/local/texlive/2010 to /usr/local/texlive:

hit 'd', then '1', then type /usr/local/texlive, then 'r', then 'i'

This starts the installation ('i' == install). After 30-45 minutes (on 
AMD Athlon X2, Win XP 32 SP3), it finishes (2.5G!) and suggests to add 
the binaries directory to PATH etc. (MANPATH, INFOPATH..).

The last steps of installation regard the generation of format file for 
all users (-rw-r--r-- root root), but with recent snapshots the format 
file are creted only for root (-rwx-----+) (**) : these permissions 
resemble those created when one installs native Windows applications 
('c:\Program files' is full of similar files).

I still apologize for my omissions.

Ciao,
Angelo.

---
(*) http://www.tug.org/texlive/quickinstall.html
(**) I am using TL on Cygwin since Aug. 2008, and this never occurred.

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  3 22:23, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> >What about some helpful details which allow to reproduce your problem?
> >Like, say, how to get the packages, how you install them, stuff like
> >that.  You seem to imply that everybody knows how to do that.  I don't.
> 
> Sorry, I have omitted details because TL2010 is a full distribution
> of LaTeX. Anyway, just for completeness..
> 
> Usually TL2010 can be installed via the WEB (*), but I maintain a
> local repository:
> 
> rsync -avz --delete --exclude=*mactex* tug.org::texlive/tlnet/ ./tlnet_repo
> 
> (tlnet_repo is about 1.7G). When one has the repository, it is
> simple to install (Cygwin is officially supported). As 'root' I do:
> 
> ./tlnet_repo/install-tl
> 
> (it is a Perl script).
> 
> Here, usually I choose to change the installation directory from
> /usr/local/texlive/2010 to /usr/local/texlive:
> 
> hit 'd', then '1', then type /usr/local/texlive, then 'r', then 'i'
> 
> This starts the installation ('i' == install). After 30-45 minutes
> (on AMD Athlon X2, Win XP 32 SP3), it finishes (2.5G!) and suggests
> to add the binaries directory to PATH etc. (MANPATH, INFOPATH..).
> 
> The last steps of installation regard the generation of format file
> for all users (-rw-r--r-- root root), but with recent snapshots the
> format file are creted only for root (-rwx-----+) (**) : these
> permissions resemble those created when one installs native Windows
> applications ('c:\Program files' is full of similar files).

Thanks, I'll give it a test.  However, that's very strange.  Keep
in mind that the perl script will at one point just call open(2),
like every other application.  If you see that behaviour as part of
a perl script, you should also see that which every other tool,
even simple stuff like `echo foo > bar'.  Did you check that this
doesn't happen in other, easier to reproduce circumstances as well?
Installing thousands of files just to see a failing open looks a bit
like overkill...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Ken Brown]

On 3/3/2011 4:23 PM, Angelo Graziosi wrote:
> The last steps of installation regard the generation of format file for
> all users (-rw-r--r-- root root), but with recent snapshots the format
> file are creted only for root (-rwx-----+) (**) : these permissions
> resemble those created when one installs native Windows applications
> ('c:\Program files' is full of similar files).

This reminds me of the discussion starting at

   http://cygwin.com/ml/cygwin/2009-11/msg00922.html

in which patching a file unexpectedly changed the permissions.  The 
issue turned out to be related to the ACLs on the temporary director 
used by patch.

In the present situation, the texlive installer calls fmtutil-sys to 
create the format files.  I think fmtutil creates the files in a 
temporary directory (using TMPDIR, TEMP, or TMP if they exist) and then 
mv's them.  Could this be your problem?  What happens if you unset those 
variables before installing texlive?

This is just a wild guess, and I'm not sure it explains why the problem 
first shows up in recent snapshots.

Ken

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

Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Angelo Graziosi]

After I flagged these problems [*], I chose to do a clean reinstall of 
TeXLive 2010 (TL2010). After installed its packages (> 2000!), TL2010 
installation proceeds with its post-install actions, mainly generating 
all format files. The installation is done as 'root' (administrator), 
but the format files are created for all system users (as it should),

-rw-r--r-- 1 root root 20760  3 mar 16.33 foo.fmt

Now, with recent snapshot (say >= 20110215, including the one released 
today) this does not occur any more,

-rwx------ 1 root root 20760  3 mar 16.33 foo.fmt

so, when a simple user builds his/her latex documents the fmt file are 
regenerated in a local directory under HOME.

JUST substituting the snapshot DLL with that of 1.7.7, restores the 
right behavior (like on GNU/Linux). With 1.7.8 it fails completely, as 
described [*].

At first sight, I thought that was caused by my mistaken in installing 
the snapshots, but I followed literally FAQ and installing 1.7.7 as a 
snapshot fixes the problems. So it seems a regression in 1.7.8 series.

Ciao,
Angelo.

---
[*] http://cygwin.com/ml/cygwin/2011-03/msg00065.html
     http://cygwin.com/ml/cygwin/2011-03/msg00066.html
     http://cygwin.com/ml/cygwin/2011-03/msg00067.html

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  3 18:44, Angelo Graziosi wrote:
> After I flagged these problems [*], I chose to do a clean reinstall
> of TeXLive 2010 (TL2010). After installed its packages (> 2000!),
> TL2010 installation proceeds with its post-install actions, mainly
> generating all format files. The installation is done as 'root'
> (administrator), but the format files are created for all system
> users (as it should),
> 
> -rw-r--r-- 1 root root 20760  3 mar 16.33 foo.fmt
> 
> Now, with recent snapshot (say >= 20110215, including the one
> released today) this does not occur any more,

What about some helpful details which allow to reproduce your problem?
Like, say, how to get the packages, how you install them, stuff like
that.  You seem to imply that everybody knows how to do that.  I don't.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[David Rothenberger]

On 3/3/2011 9:44 AM, Angelo Graziosi wrote:
> After I flagged these problems [*], I chose to do a clean reinstall of
> TeXLive 2010 (TL2010). After installed its packages (> 2000!), TL2010
> installation proceeds with its post-install actions, mainly generating
> all format files. The installation is done as 'root' (administrator),
> but the format files are created for all system users (as it should),
> 
> -rw-r--r-- 1 root root 20760  3 mar 16.33 foo.fmt
> 
> Now, with recent snapshot (say >= 20110215, including the one released
> today) this does not occur any more,
> 
> -rwx------ 1 root root 20760  3 mar 16.33 foo.fmt
> 
> so, when a simple user builds his/her latex documents the fmt file are
> regenerated in a local directory under HOME.

I just want to mention that I'm facing a similar issue with the
Subversion unit tests. They are failing because the "svn:executable"
property is being added when it's not expected. This happens
automatically when a file is executable and added to Subversion, so it
seems files created by the test suite are executable with 1.7.8 but not
with 1.7.7.

Unfortunately, this is an equally complex system for reproducing the
problem, but I will try to narrow it down to a simple test case.

Like Angelo, I'm using Windows XP Pro SP3.

-- 
David Rothenberger  ----  daveroth@acm.org

"Well, you see, it's such a transitional creature.  It's a piss-poor
reptile and not very much of a bird."
- Melvin Konner, from "The Tangled Wing", quoting a zoologist who has
studied the archaeopteryx and found it "very much like people"

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[Corinna Vinschen]

On Mar  5 10:08, David Rothenberger wrote:
> On 3/3/2011 9:44 AM, Angelo Graziosi wrote:
> > After I flagged these problems [*], I chose to do a clean reinstall of
> > TeXLive 2010 (TL2010). After installed its packages (> 2000!), TL2010
> > installation proceeds with its post-install actions, mainly generating
> > all format files. The installation is done as 'root' (administrator),
> > but the format files are created for all system users (as it should),
> > 
> > -rw-r--r-- 1 root root 20760  3 mar 16.33 foo.fmt
> > 
> > Now, with recent snapshot (say >= 20110215, including the one released
> > today) this does not occur any more,
> > 
> > -rwx------ 1 root root 20760  3 mar 16.33 foo.fmt
> > 
> > so, when a simple user builds his/her latex documents the fmt file are
> > regenerated in a local directory under HOME.
> 
> I just want to mention that I'm facing a similar issue with the
> Subversion unit tests. They are failing because the "svn:executable"
> property is being added when it's not expected. This happens
> automatically when a file is executable and added to Subversion, so it
> seems files created by the test suite are executable with 1.7.8 but not
> with 1.7.7.
> 
> Unfortunately, this is an equally complex system for reproducing the
> problem, but I will try to narrow it down to a simple test case.

That would be very helpful.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Problems with Cygwin-1.7.8 (or snapshot) and TeXLive 2010

[David Rothenberger]

On 3/7/2011 2:15 AM, Corinna Vinschen wrote:
> On Mar  5 10:08, David Rothenberger wrote:
>> On 3/3/2011 9:44 AM, Angelo Graziosi wrote:
>>> After I flagged these problems [*], I chose to do a clean reinstall of
>>> TeXLive 2010 (TL2010). After installed its packages (> 2000!), TL2010
>>> installation proceeds with its post-install actions, mainly generating
>>> all format files. The installation is done as 'root' (administrator),
>>> but the format files are created for all system users (as it should),
>>>
>>> -rw-r--r-- 1 root root 20760  3 mar 16.33 foo.fmt
>>>
>>> Now, with recent snapshot (say >= 20110215, including the one released
>>> today) this does not occur any more,
>>>
>>> -rwx------ 1 root root 20760  3 mar 16.33 foo.fmt
>>>
>>> so, when a simple user builds his/her latex documents the fmt file are
>>> regenerated in a local directory under HOME.
>>
>> I just want to mention that I'm facing a similar issue with the
>> Subversion unit tests. They are failing because the "svn:executable"
>> property is being added when it's not expected. This happens
>> automatically when a file is executable and added to Subversion, so it
>> seems files created by the test suite are executable with 1.7.8 but not
>> with 1.7.7.
>>
>> Unfortunately, this is an equally complex system for reproducing the
>> problem, but I will try to narrow it down to a simple test case.
> 
> That would be very helpful.

I spent some time over the weekend trying to find a STC but failed
miserably. It only occurs when svn.exe is invoked from their python test
infrastructure. I'm not familiar with it and it is complext.

Sounds like you might know the cause, so if you find a fix, I'll test it
for sure. I could also test to see if the snapshot Angelo identified is
also the culprit for me, but I don't think that will tell you much. If
you don't figure it out, I'll try again for a STC, but it won't be until
next weekend at the earliest.

-- 
David Rothenberger  ----  daveroth@acm.org

Office Automation:
        The use of computers to improve efficiency in the office
        by removing anyone you would want to talk with over coffee.

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