experimental texmf packages

experimental texmf packages

[Jan Nieuwenhuizen]

Hi List,

This week I've taken a quick stab at packaging a texmf tree that goes
with the tetex-beta in contrib, so you'll need that too.

This is needed to replace miktex as part of the GNU LilyPond
(http://www.lilypond.org) installation on Windows, and recently the
tetex-beta packager seemed to mention that he was not planning to
package the texmf tree, which we were so eagerly waiting for (this
pkg should make that job a piece of cake).

It's packaged in three parts, texmf-base, texmf-doc, and texmf-extra.
After selecting installing tetex-beta (from cygwin) and texmf-base,
you should have a functioning TeX setup.

The experimental tarballs are at

    http://lilypond.org/people/jan/gnu-windows/tar/texmf/

if you unpack them by hand, you'll need to run

    /etc/postinstall/texmf-base.sh

after unpacking.  Note that tetex-beta should be installed when you do
this.

There may or may not be a working setup.ini at:

    http://lilypond.org/people/jan/gnu-windows

When this works, it will be submitted to cygwin.

If you're unlucky, read /usr/share/doc/tetex-beta-20000804/INSTALL,
edit /usr/share/texmf/web2c/*cnf, and run

    texconfig confall
    texconfig rehash
    texconfig init

These packages all built on GNU/Linux using mirror, build and
packaging scripts at:

    http://lilypond.org/people/jan/gnu-windows/cygwin-cross-1.3.5.3.tar.gz

Note that this is all quite experimental, and on top of that, I'll be
off-line for about a week, but I didn't want to keep this from you.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Jan,

2001-11-26 15:39:17, du schriebst:

> This week I've taken a quick stab at packaging a texmf tree that goes
> with the tetex-beta in contrib, so you'll need that too.

> The experimental tarballs are at

>     http://lilypond.org/people/jan/gnu-windows/tar/texmf/

> if you unpack them by hand, you'll need to run

>     /etc/postinstall/texmf-base.sh

> after unpacking.  Note that tetex-beta should be installed when you do
> this.

>     texconfig confall
>     texconfig rehash
>     texconfig init

Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
version of png, but doesn't work.

I'm in favour to include it in the net release. (and if it is no problem
of my setup, tetex needs a rebuild?)

Gerrit
-- 
convey Information Systems GmbH                   http://www.convey.de/
                                                  Vitalisstraße 326-328
Gerrit P. Haase                                   D-50933 Köln
gerrit.haase@convey.de                            Fon: ++49 221 6903922


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jerome BENOIT]

Bonjour:

Please let me know what is oing on.

Good TeXing,
Jerome BENOIT

("cygnus-tetex current maintainer")

"Gerrit P. Haase" wrote:
> 
> Hallo Jan,
> 
> 2001-11-26 15:39:17, du schriebst:
> 
> > This week I've taken a quick stab at packaging a texmf tree that goes
> > with the tetex-beta in contrib, so you'll need that too.
> 
> > The experimental tarballs are at
> 
> >     http://lilypond.org/people/jan/gnu-windows/tar/texmf/
> 
> > if you unpack them by hand, you'll need to run
> 
> >     /etc/postinstall/texmf-base.sh
> 
> > after unpacking.  Note that tetex-beta should be installed when you do
> > this.
> 
> >     texconfig confall
> >     texconfig rehash
> >     texconfig init
> 
> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
> version of png, but doesn't work.
> 
> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)
> 
> Gerrit
> --
> convey Information Systems GmbH                   http://www.convey.de/
>                                                   Vitalisstraße 326-328
> Gerrit P. Haase                                   D-50933 Köln
> gerrit.haase@convey.de                            Fon: ++49 221 6903922
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
  *º¤., ¸¸,.¤º*¨¨¨*¤    Jerome BENOIT, Ph.D.    *º¤., ¸¸,.¤º*¨¨¨*¤
                  Institute of Molecular Biology
               Friedrich-Schiller University of Jena
             Winzerlaer Strasse 10, Jena 07745, Germany
  *º¤., ¸¸,.¤º*¨¨¨*¤    JGMBenoit@wanadoo.fr    *º¤., ¸¸,.¤º*¨¨¨*¤

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jerome BENOIT]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

Bonjour:

Please let me know what is oing on.

Good TeXing,
Jerome BENOIT

("cygnus-tetex current maintainer")

"Gerrit P. Haase" wrote:
> 
> Hallo Jan,
> 
> 2001-11-26 15:39:17, du schriebst:
> 
> > This week I've taken a quick stab at packaging a texmf tree that goes
> > with the tetex-beta in contrib, so you'll need that too.
> 
> > The experimental tarballs are at
> 
> >     http://lilypond.org/people/jan/gnu-windows/tar/texmf/
> 
> > if you unpack them by hand, you'll need to run
> 
> >     /etc/postinstall/texmf-base.sh
> 
> > after unpacking.  Note that tetex-beta should be installed when you do
> > this.
> 
> >     texconfig confall
> >     texconfig rehash
> >     texconfig init
> 
> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
> version of png, but doesn't work.
> 
> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)
> 
> Gerrit
> --
> convey Information Systems GmbH                   http://www.convey.de/
>                                                   Vitalisstraße 326-328
> Gerrit P. Haase                                   D-50933 Köln
> gerrit.haase@convey.de                            Fon: ++49 221 6903922
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
  *º¤., ¸¸,.¤º*¨¨¨*¤    Jerome BENOIT, Ph.D.    *º¤., ¸¸,.¤º*¨¨¨*¤
                  Institute of Molecular Biology
               Friedrich-Schiller University of Jena
             Winzerlaer Strasse 10, Jena 07745, Germany
  *º¤., ¸¸,.¤º*¨¨¨*¤    JGMBenoit@wanadoo.fr    *º¤., ¸¸,.¤º*¨¨¨*¤

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

"Gerrit P. Haase" wrote:

> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
> version of png, but doesn't work.
> 
> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)

I dunno, it's been a long time since I've updated or looked at the png
code.  I'm surprised that I broke something that long ago.  I'm at work
now, but I'll look into this more when I get home.

--Chuck
libpng maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

"Gerrit P. Haase" wrote:

> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
> version of png, but doesn't work.
> 
> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)

I dunno, it's been a long time since I've updated or looked at the png
code.  I'm surprised that I broke something that long ago.  I'm at work
now, but I'll look into this more when I get home.

--Chuck
libpng maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Gerrit P. Haase wrote:

> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
> version of png, but doesn't work.
> 
> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)


Unfortunately, it looks like the answer is "yes, tetex needs a rebuild". 
  But this time it's not my fault. :-)  See
http://sources.redhat.com/ml/cygwin/2001-02/msg00193.html

--Chuck




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Charles,

Am 2001-11-29 um 05:43 schriebst du:

>> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
>> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
>> version of png, but doesn't work.
>> 
>> I'm in favour to include it in the net release. (and if it is no problem
>> of my setup, tetex needs a rebuild?)


> Unfortunately, it looks like the answer is "yes, tetex needs a rebuild". 
>   But this time it's not my fault. :-)  See
> http://sources.redhat.com/ml/cygwin/2001-02/msg00193.html

Aha, this is from February, never saw this problem before, strange...

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Charles,

Am 2001-11-29 um 05:43 schriebst du:

>> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
>> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
>> version of png, but doesn't work.
>> 
>> I'm in favour to include it in the net release. (and if it is no problem
>> of my setup, tetex needs a rebuild?)


> Unfortunately, it looks like the answer is "yes, tetex needs a rebuild". 
>   But this time it's not my fault. :-)  See
> http://sources.redhat.com/ml/cygwin/2001-02/msg00193.html

Aha, this is from February, never saw this problem before, strange...

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Gerrit P. Haase wrote:

> Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
> the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
> version of png, but doesn't work.
> 
> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)


Unfortunately, it looks like the answer is "yes, tetex needs a rebuild". 
  But this time it's not my fault. :-)  See
http://sources.redhat.com/ml/cygwin/2001-02/msg00193.html

--Chuck




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

"Gerrit P. Haase" <freeweb@nyckelpiga.de> writes:

> >     texconfig confall
> >     texconfig rehash
> >     texconfig init
> 
> Seems to work ok.

Good.  Has this been tried with an automatic setup install, or did you
run texconfig by hand?  It should work right out of the box.  It would
be good to have tetex-beta depend upon tetex-base, and libncurses5
(for texconfig) imho; while having the other texmf packages should
marked optional.  How do we arrange that?

Also, what are the drills for a cygwin submission?  I'm not running
cygwin myself (I'm allowed to use GNU/Linux at work :-)), but I've
read something about setup hints...

> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)

I tried this, but it seems that a plain rebuild gives some (small)
problems; the binary executables don't get a .exe extension, eg.

Greetings,
Jan.

Btw, how is your guile contribution coming along?

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Jan,

Am 2001-11-29 um 16:45 schriebst du:

> "Gerrit P. Haase" <freeweb@nyckelpiga.de> writes:

>> >     texconfig confall
>> >     texconfig rehash
>> >     texconfig init
>> 
>> Seems to work ok.

> Good.  Has this been tried with an automatic setup install, or did you
> run texconfig by hand?  It should work right out of the box.  It would

That was installed with setup.exe.  But I didn't tested much, so I would
like to do more testing.

> be good to have tetex-beta depend upon tetex-base, and libncurses5
> (for texconfig) imho; while having the other texmf packages should
> marked optional.  How do we arrange that?

There seem to be also be dependencies to libpng which causes errors.

> Also, what are the drills for a cygwin submission?  I'm not running
> cygwin myself (I'm allowed to use GNU/Linux at work :-)), but I've
> read something about setup hints...

Request at cygwin-apps and if there are three or more in favour to add it
and no objections, it is in.  If there are pros and contras it needs a
discussion.

>> I'm in favour to include it in the net release. (and if it is no problem
>> of my setup, tetex needs a rebuild?)

> I tried this, but it seems that a plain rebuild gives some (small)
> problems; the binary executables don't get a .exe extension, eg.

Ask the maintainer please.

> Greetings,
> Jan.

> Btw, how is your guile contribution coming along?

The static build is ok, same quality as yours, only two minor patches.
Dynamic seems to make problems at least with lilypond, also another guy
was not able to rebuild it with my patch, I think we should include the
static version and wait until 1.6 is released to provide a build with
static and dynamic libraries.

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

"Gerrit P. Haase" wrote:
> 
> Hallo Jan,

> > be good to have tetex-beta depend upon tetex-base, and libncurses5
> > (for texconfig) imho; while having the other texmf packages should
> > marked optional.  How do we arrange that?
> 
> There seem to be also be dependencies to libpng which causes errors.

Note that if you rebuild tetex (to fix the libpng thing) then you'll
lose the dependency on libncurses5 but pick up a dependency on
libncurses6.

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

"Gerrit P. Haase" wrote:
> 
> Hallo Jan,

> > be good to have tetex-beta depend upon tetex-base, and libncurses5
> > (for texconfig) imho; while having the other texmf packages should
> > marked optional.  How do we arrange that?
> 
> There seem to be also be dependencies to libpng which causes errors.

Note that if you rebuild tetex (to fix the libpng thing) then you'll
lose the dependency on libncurses5 but pick up a dependency on
libncurses6.

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Jan,

Am 2001-11-29 um 16:45 schriebst du:

> "Gerrit P. Haase" <freeweb@nyckelpiga.de> writes:

>> >     texconfig confall
>> >     texconfig rehash
>> >     texconfig init
>> 
>> Seems to work ok.

> Good.  Has this been tried with an automatic setup install, or did you
> run texconfig by hand?  It should work right out of the box.  It would

That was installed with setup.exe.  But I didn't tested much, so I would
like to do more testing.

> be good to have tetex-beta depend upon tetex-base, and libncurses5
> (for texconfig) imho; while having the other texmf packages should
> marked optional.  How do we arrange that?

There seem to be also be dependencies to libpng which causes errors.

> Also, what are the drills for a cygwin submission?  I'm not running
> cygwin myself (I'm allowed to use GNU/Linux at work :-)), but I've
> read something about setup hints...

Request at cygwin-apps and if there are three or more in favour to add it
and no objections, it is in.  If there are pros and contras it needs a
discussion.

>> I'm in favour to include it in the net release. (and if it is no problem
>> of my setup, tetex needs a rebuild?)

> I tried this, but it seems that a plain rebuild gives some (small)
> problems; the binary executables don't get a .exe extension, eg.

Ask the maintainer please.

> Greetings,
> Jan.

> Btw, how is your guile contribution coming along?

The static build is ok, same quality as yours, only two minor patches.
Dynamic seems to make problems at least with lilypond, also another guy
was not able to rebuild it with my patch, I think we should include the
static version and wait until 1.6 is released to provide a build with
static and dynamic libraries.

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

"Gerrit P. Haase" <gp@familiehaase.de> writes:

> That was installed with setup.exe.  But I didn't tested much, so I would
> like to do more testing.
> There seem to be also be dependencies to libpng which causes errors.

Ok.  I've addes setup hints, made some fixes and even did some testing
this weekend.  It seems that the added dependencies on libncurses5,
libpng and sed fix this problem, I hope.

> Request at cygwin-apps and if there are three or more in favour to add it
> and no objections, it is in.  If there are pros and contras it needs a
> discussion.

Ok, then I'll have a go later.

> > Btw, how is your guile contribution coming along?
> 
> The static build is ok, same quality as yours, only two minor
> patches.  [..]  I think we should include the static version and
> wait until 1.6 is released to provide a build with static and
> dynamic libraries.

Yes, that would be fine.

Greetings,
Jan.
-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Jan,

2001-12-03 13:41:16, du schriebst:

>> That was installed with setup.exe.  But I didn't tested much, so I would
>> like to do more testing.
>> There seem to be also be dependencies to libpng which causes errors.

> Ok.  I've addes setup hints, made some fixes and even did some testing
> this weekend.  It seems that the added dependencies on libncurses5,
> libpng and sed fix this problem, I hope.

Nah, what I meant, there is a function in libpng not found because tetex
was linked against another version and the table layout changed (unfortunately),
so tetex needs a rebuild with the current libpng.
Besides that it is ok to have the dependencies correct listed.

> Ok, then I'll have a go later.

I may missed some important point, be sure to lookup http://cygwin.com/setup.html

Gerrit
-- 
convey Information Systems GmbH                   http://www.convey.de/
                                                  Vitalisstraße 326-328
Gerrit P. Haase                                   D-50933 Köln
gerrit.haase@convey.de                            Fon: ++49 221 6903922


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

"Gerrit P. Haase" <freeweb@nyckelpiga.de> writes:

> Nah, what I meant, there is a function in libpng not found because tetex
> was linked against another version and the table layout changed (unfortunately),
> so tetex needs a rebuild with the current libpng.

Yes, I've asked Jerome for a rebuild (after trying myself; I gave up).

> I may missed some important point, be sure to lookup
> http://cygwin.com/setup.html

Thanks.  I know about that page; but I'm not sure about the status of
all individual items; notably the absolute silly reversed-patch
requirement.  I've seen some discussion, but no conclusion or
agreement...

I've tried to stay within the spirit of it, the packages should now be
mostly complient.  (Fwiw, I think it's totally silly to reinvent
package management for the umpteenth time.  Three years ago, I ported
RPM and (cross-)built all my Cygwin (lilypond-support) packages as
RPMS.  RPM didn't catch on, and I built a set of cross-build scripts
from the .spec shell-snippets.  But now discussions on cygwin-apps
mention 'RPM-like' behaviour and layout.  Sigh.)

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Jan Nieuwenhuizen wrote:
> Thanks.  I know about that page; but I'm not sure about the status of
> all individual items; notably the absolute silly reversed-patch
> requirement.  

Silly? no.  Difficult and painful, prompting questions like "surely
there is a better way"?  yes.

You need to understand where that requirement came from: protective
action against maintainers who flake out.  I'm going to pick on Mumit
Khan, here, who is a great guy and has done a lot for cygwin over the
years -- but who, for personal reasons, dropped off the planet for about
a year (he's back now).  Before his departure, Mumit was also the
de-facto gcc-on-cygwin (actually, egcs-on-cygwin) maintainer.

For a long time, Mumit was the only person who really understood and
knew about all of the hacks to egcs/gcc that were necessary for "proper"
operation under cygwin.  He packaged up "replacement" gcc's and
everybody happily downloaded and used them.  He also provided source,
but it was his own modified devel tree.  When he left, we were stuck for
a LONG time without an up-to-date gcc.  I mean, you COULD download the
original source for the version that Mumit forked from, download his
source, do the diff, go thru it line by line to determine what was
necessary to carry forward, and then apply the result to the new version
of the official gcc source...

painful.  It took cgf and dj some months to winnow thru it all.  Right
about that time, we were trying to come up with a packaging
"standard"...and were feeling quite stung by the gcc experience.  We did
NOT want that sort of thing to happen again.  So, we said "provide
prepatched source" -- because people wanted to just unpack, configure,
make -- but also "provide the diff between your source and the official
version".

Yes, it's a pain.  Yes, there are better ways.  But silly? no.  (I think
the silly part was insisting that the source code be PRE-patched. 
Surely folks can patch it themselves if given the diff...)

> I've seen some discussion, but no conclusion or
> agreement...

Well, it sorta ended like this: CGF: "Stop bickering.  This is NOT that
big a deal; we have more important things to worry about.  Whatever is
reasonable, is okay.  And we don't really need just ONE standard." 
(okay, I'm paraphrasing).  But basically, I think we ended up with:
there is no iron clad, my-way-or-the-highway standard, but agreement on
a number of principles:

1) official, unmodified source code should be provided
2) with a diff (or multiple diffs) that are used to turn the official
source into cygwin source
3) there should be some sort of automated script -- shell script,
external makefile, *something*, to drive the entire cygwin build
5) setup will unpack stuff under /usr/src (for now; later setup may
unpack -src archives into a user-selected destination)
4) there is no need to go back and repackage everything that's already
in existence just to make the -src package "conform" to these
principles.  Redo -src packaging in the normal course of updates.

That's it. (right guys?  we all pretty much agree with ^^^ at least,
right?)
 
> I've tried to stay within the spirit of it, the packages should now be
> mostly complient.  (Fwiw, I think it's totally silly to reinvent
> package management for the umpteenth time.  

Yes.  But unavoidable, given the realities...

> Three years ago, I ported
> RPM 

You did that?  I thought *I* did that (cygutils, perl-5.005 modules, mid
1998).  I think it's silly for people to re-port the same applications
for the umpteenth time... :->

> and (cross-)built all my Cygwin (lilypond-support) packages as
> RPMS.  RPM didn't catch on,

But you gloss over the *reasons* it didn't catch on:

  1) There was no true NATIVE port, so you couldn't use rpm to install
cygwin itself.

  2) Nobody, and I mean NOBODY, has followed thru on porting, packaging,
and maintaining the berkeley-db and rpm packages as official,
cygwin-mirror-system distributed packages (surely that's the FIRST step
before attempting to use rpm as the be-all and end-all package
management application for cygwin?  PROVIDE it and maintain an official
port?)
  there's been a lot of talk, and "wouldn't it be nice" and "those guys
at project heavymoon..." or "you know, there's a `cygwin-rpm' project at
sourceforge...".  But NOBODY has stepped forward HERE, on THIS list, to
provide it as an OFFICIAL, sourceware-distributed cygwin package!  It's
funny, but the folks who yell loudest about "why don't you just use rpm
for pkg management" are also the ones who scatter like cockroaches when
somebody flips on the light and says "great, please package up a port so
we can ease into using rpm/dpkg/whatever".  Or, they would rather fork
the entire cygwin project and set up their own page duplicating all of
cygwin under the "rpm" (or "dpkg") paradigm.  (project heavymoon,
cygwin-rpm@sourceware, debian-w32, etc) -- but they always start off
with "first install cygwin using setup.exe, and then..."  (MAN, that
point #1 is a doozy...)

  Dario Alcocer finessed point #1 by using a minicygwin distribution
(that included only ash, rpm, db, and cygwin1.dll itself; he called it
the "cygwin application runtime" or CART) to install the REAL cygwin. 
See http://www.helixdigital.com/~alcocer/rpm-installer/  for a design
document.  Back in September, I heard that Dario had an ISO image ready
for test, but I never saw a URL for it...

  However, unless Dario was volunteering to support official db and rpm
packages for cygwin (I don't think he was, although he "knows" how --
Dario is the ghostscript package maintainer) this still doesn't address
point #2...

> and I built a set of cross-build scripts
> from the .spec shell-snippets.  

that's a neat idea.  Can I see?

> But now discussions on cygwin-apps
> mention 'RPM-like' behaviour and layout.  Sigh.)

Well, except that it was decided that going halfway to rpm-style layout
without ACTUALLY using rpm was kinda silly. (I can say that; it was my
idea that got shot down).  However, "rpm-like" is still on the table in
the sense of:
 1) provide pristine source
 2) provide the patches
 3) provide "something" to autodrive the build (shellscript+sh.exe,
debian.rules+dpkg, spec+rpm, whatever)

Sure.  All modern package management schemes are going to look SOMETHING
like that.  The difference we have on the cygwin platform is that we've
bifurcated the traditional package/system management tasks into two
groups (out of necessity, see point 1 above):

a) source code autobuilding and packing
b) installation and unpacking

Part A assumes you already have a working cygwin development environment
installed on your machine. Part B must be doable on a "virgin" system. 
Thus, the installer-unpacker must NOT rely on cygwin (unless you jump
thru hoops a-la' Dario).  That's setup.exe.  Nobody is proposing that
setup.exe take over part A.  THAT's the primary difference between us
and the umpteen other pkg-management systems.  And it's driven by
necessity: chicken-and-egg.  The existing GOOD pkg-management systems
haven't been ported to the native windows API and therefore require
cygwin1.dll -- but windows won't let you replace a file that is
currently in use, so you can't use *cygwin* ports to install or update
cygwin1.dll itself...

(This sidesteps the question about "where do you put the package
management database for a native windows port of rpm/dpkg/whatever?" 
You can't put it in /var/lib/rpm/ (because cygwin installation will
manipulate the mount table; you don't know where /var will BE until
after the installation is finished).  But if you're relying on "cygwin
will do thus-and-so, so let's put the database HERE" -- then that's not
really a NATIVE port of rpm -- it's a crossbreed.)

Of all the let's-use-rpm proposals, Dario's makes the most sense --
although Robert's eventual plan for setup.exe ain't bad either.  He's
ripped out the guts of setup, made everything stream-based, so now we
can plug in different backends -- eventually.  Like cpio, rpm, etc. 
Still a lot of work left, tho.  Note that the two examples I'm praising
involve actual, roll-up-your-sleeves WORK -- both Robert and Dario put
effort into their proposal and showed something concrete.  Not armchair
quarterbacking  or sideline sniping.

<rant>
Jan, next time try CONTRIBUTING to the discussion, instead of calling
the result silly after the fact. (I refer here to the "-src packaging
standard" discussion on cygwin-apps several weeks ago)  You act as if
you have all the answers, and merely observed us morons flailing our way
toward redoing what you knew all along we should do.  Fine, I'll admit
that I don't know everything -- and I'd sure love to see your
contributions to those discussions (WHILE they are ongoing) since you're
so all-wise.  Anybody can carp after the fact and call the result --
acheived without their input -- "silly". Put your effort where your
mouth is before you criticize.  I put up on the web four or five
EXAMPLES of each packaging proposal so that folks could test and
evaluate them.  Where were you?  Oh, yeah -- sighing about our
reinventing package management for the umpteenth time...but not
contributing to the discussion.
</rant>

I appreciate your efforts w.r.t. tetex-*; please don't take the above
rant as criticism of THOSE contributions.  You've actually contributed
to cygwin as a whole, there; I'm just upset about the sideline criticism
of the packaging discussions, since we obviously could have benefited
from some additional input -- but got very little.  It was mostly a
dialogue between Robert and I, and I'm still a little disappointed at
the lack of wider participation in that discussion.

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

Charles Wilson <cwilson@ece.gatech.edu> writes:

First, thanks for your reply on my ranting mail, that went to the list
by accident (look at Gerrit's address).

> Silly? no.  Difficult and painful, prompting questions like "surely
> there is a better way"?  yes.

Well, I still thought it was silly to have identical forward and
backward patches, when we have a patch -R flag.  Normal mode of
operation is to (apply and) supply forward patches; now my (and
everyone else's packaging procedure) I must be rewritten to do unpack,
rename -> .orig, patch, run diff from .orig tree.  Or, be hacked to
try to determine the direction of the patch before applying, but

> You need to understand where that requirement came from: protective
> action against maintainers who flake out.
[snip]

I understand this must be avoided at all cost.

> So, we said "provide prepatched source" -- because people wanted to
> just unpack, configure, make -- but also "provide the diff between
> your source and the official version".

Sure, but I don't see any advantage in reversed patches.

> Yes, it's a pain.  Yes, there are better ways.  But silly? no.  (I think
> the silly part was insisting that the source code be PRE-patched.

Yes, I think that requirement is silly too.  Because people will be
using a download cache, the pristine source is there too.  Build
environments now hold pristine sources, patched sources, and patches
in both directions.  But, whatever gets you going :-)

> there is no iron clad, my-way-or-the-highway standard, but agreement on
> a number of principles:

> 1) official, unmodified source code should be provided
> 2) with a diff (or multiple diffs) that are used to turn the official
> source into cygwin source
> 3) there should be some sort of automated script -- shell script,
> external makefile, *something*, to drive the entire cygwin build

I'm not sure I understand.  Have the 1-diff,reversed diff, pre-patched
-src requirements been dropped?  Currently, I dist the pristine
tarball as foo-orig.tar.gz; and the pre-patched cygwin, including the
applied patches, as -src.tar.gz.

Is this sort of what it should be now:

    $ tar xzf foo-1.1-1-src.tar.gz
    $ ls foo-1.1-1-src
    foo-1.1-1-src/foo-1.1.tar.gz  # pristine src
    foo-1.1-1-src/foo-1.1-1.patch # forward diff
    foo-1.1-1-src/other.patch
    doit.sh  # how to guess this name?

    $ cat foo-1.1-1-src/doit.sh
    #!/bin/bash
    set -e
    tar xzf foo-1.1.tar.gz
    mv foo-1.1 foo-1.1-1
    cd foo-1.1-1
    patch -p1 < ../other.patch
    patch -p1 < ../foo-1.1-1.patch
    autoconf
    ./configure --prefix=/usr
    make
    make install prefix=/tmp/foo-root/usr
    cd /tmp/foo-root
    tar czf /usr/src/foo-1.1-1.tar.gz *

How about an example dummy package like this?

Now every package should contain a build script.  Isn't that a step
backwards in the evolution?  You'd want a central tool(set) to do the
building and packaging, and package specific scripts/makefile
snippets.

> That's it.

> > Three years ago, I ported RPM
> 
> You did that?  I thought *I* did that (cygutils, perl-5.005 modules, mid
> 1998).  I think it's silly for people to re-port the same applications
> for the umpteenth time... :->

:-)

> But you gloss over the *reasons* it didn't catch on:
> 
>   1) There was no true NATIVE port, so you couldn't use rpm to install
> cygwin itself.

That is a real problem.  But it solved the cross-building, the
tarball/patch issue, binary packaging, dependencies, pre/post
install/remove scripts for me.

>   2) Nobody, and I mean NOBODY, has followed thru on porting, packaging,
> and maintaining the berkeley-db and rpm packages as official,
> cygwin-mirror-system distributed packages (surely that's the FIRST step
> before attempting to use rpm as the be-all and end-all package
> management application for cygwin?  PROVIDE it and maintain an official
> port?)

I didn't have the webspace to do that.  But I did implement
.patch.rpm's (supply pristine source yourself) to work around that,
and put it up here (where it sits and rots):

    http://www.xs4all.nl/~jantien/cygnus/b20/PRPMS
   
Also, while I am/was willing to help out the Cygwin project, I'd
rather work on LilyPond than reinvent packaging/do porting.  I
hoped people to be interested, discuss and maybe take over what I
tried to start, but nothing much happened, then.

> > and I built a set of cross-build scripts
> > from the .spec shell-snippets.  
> 
> that's a neat idea.  Can I see?

Sure (it's been posted to the cygwin list a couple of times, but as
there where no reactions, I decided not to spam the list any
further).  Find the latest here:

    http://lilypond.org/people/jan/gnu-windows/cygwin-cross-1.3.6.0.tar.gz

It's a cardhouse of shell snippets.  The idea is simple: there are
three flavours of packages: binary (= untar, that's it), cross (eg,
binutils, gcc), native (guile, lilypond etc).  Each flavour has a
number of stages that should be performed: download, configure, make,
install etc.  For each stage there's a template script for a well
behaved package, but instead of this template a specific script can be
inserted, eg:

    cygwin-cross-1.3.6.0$ ls -1r stage/*.configure
    stage/template.configure
    stage/native.configure
    stage/lilypond.configure
    stage/guile.configure
    stage/gcc.configure

Then there's a script: bin/cygwin-cross.sh, that simply finds and
sources all stages for all packages for all flavours; upon first run
this recreates a cross-build environment in $HOME/usr/src/cygwin.  If
you run it, please first do it in a safe environment, because it's,
well, hairy shell scripts and evals, and you'll be only the third
user, probably.  Esp. little things like cygwin's source and binary
tarball naming, and the .gz/.bz2 make it a bit hairy.

> However, "rpm-like" is still on the table in
> the sense of:
>  1) provide pristine source
>  2) provide the patches
>  3) provide "something" to autodrive the build (shellscript+sh.exe,
> debian.rules+dpkg, spec+rpm, whatever)

Good.

> a) source code autobuilding and packing
> b) installation and unpacking
> 
> Part A assumes you already have a working cygwin development environment
> installed on your machine. Part B must be doable on a "virgin"
> system.
> Thus, the installer-unpacker must NOT rely on cygwin.

What I did, using rpm, was provide a rpm-x.y.z.bin.tar.gz, including
necessary libs.  If setup.exe can't run rpm, it gets and untars the
tarball.  After that, it installs/upgrades the cygwin, rpm, zlib
.rpm's.  Of course, that's the easy part.  But it wouldn't be hard to
let setup.exe handle the final placment of any binaries that were in
use during the rpm phase.  Is that too kludgy?

> (This sidesteps the question about "where do you put the package
> management database for a native windows port of rpm/dpkg/whatever?"
[..]
> You can't put it in /var/lib/rpm/ (because cygwin installation will
> manipulate the mount table; you don't know where /var will BE until
> after the installation is finished).

Ok, so, a native port, that should be more feasible with the current
state of mingw(?), would pose other problems.  But these seem even
easier to solve?

What if you'd only allow setup.exe to choose the cygwin root for the
first installation?

> Of all the let's-use-rpm proposals, Dario's makes the most sense --
> although Robert's eventual plan for setup.exe ain't bad either.

Ok, so I missed not only this discussions, but also actual code.
Ignore my rpm questions above, I'll have a look into these two
alternatives first.

> <rant>
> Jan, next time try CONTRIBUTING to the discussion, instead of calling
> the result silly after the fact.
> </rant>

You're right to rant here, because my mail really was a rant too, I'm
sorry.  But I always try to put code first, and then start a
discussion.  In this case, I've presented rpm stuff, my cross-build
scripts, and some months ago a patch for a setup.exe postremove
feature.  Maybe it was bad timing, maybe my code was just too bad, but
on each of these occasions I got so little sensible feedback if any at
all.  That turned me off a bit.

> I appreciate your efforts w.r.t. tetex-*; please don't take the above
> rant as criticism of THOSE contributions.

Thanks; no I won't.

> we obviously could have benefited from some additional input -- but
> got very little.  It was mostly a dialogue between Robert and I, and
> I'm still a little disappointed at the lack of wider participation
> in that discussion.

Ok.  I've not been a Cygwin user myself for some years now, I'm only
parasiting on Cygwin to provide a windows port for LilyPond.  That
makes that I don't follow all Cygwin stuff all the time; I only look
into it when there are major updates/and or when setting up a new
cross build environment fails.

About a year ago (?) I asked Christopher if I could be on the
cygwin-developers, to stay in touch a bit more and deliver the
occasional patch to setup.exe or cross-compile fix, but he judged my
contributions too low to warrant membership at that time.

As I had the impression that the only sensible discussions were at
cygwin-developers, and it my posts on cygwin were mostly ignored (even
though Christopher once tried to direct some attention to one of my
posts), I gave up.  Being only involved occasionally, and going
through the archives directly, I didn't find out about the apps list
(and open membership) until recently...

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Robert Collins]

----- Original Message -----
From: "Jan Nieuwenhuizen" <janneke@gnu.org>
>
> Well, I still thought it was silly to have identical forward and
> backward patches, when we have a patch -R flag.  Normal mode of
> operation is to (apply and) supply forward patches; now my (and
> everyone else's packaging procedure) I must be rewritten to do unpack,
> rename -> .orig, patch, run diff from .orig tree.  Or, be hacked to
> try to determine the direction of the patch before applying, but

Well to diff you always need two trees, the orig and the working tree.
So having your pristine source in .orig doesn't seem hard to me :}.

> > So, we said "provide prepatched source" -- because people wanted to
> > just unpack, configure, make -- but also "provide the diff between
> > your source and the official version".
>
> Sure, but I don't see any advantage in reversed patches.

With patches that remove the cygwin code from the source in a tarball,
you need a separate tarball + a separate patch for each -1, -2, -3 of a
given upstream source tarball.

With patches that add the cygwin code to the source in a tarball, you
need a single tarball for the given upstream source tarball + a single
patch for each of the -1 -2 -3 releases. So this is more bandwidth
efficient for everyone. Does setup.exe support this now? No. Will it?
Yes.

> > Yes, it's a pain.  Yes, there are better ways.  But silly? no.  (I
think
> > the silly part was insisting that the source code be PRE-patched.
>
> Yes, I think that requirement is silly too.  Because people will be
> using a download cache, the pristine source is there too.  Build
> environments now hold pristine sources, patched sources, and patches
> in both directions.  But, whatever gets you going :-)

Build environments to recreate a -src package need
a) pristine source TARBALL.
b) patch for current -x version
c) extracted and patched working dir.

I don't see where patchs in both directions come in.

> I'm not sure I understand.  Have the 1-diff,reversed diff, pre-patched
> -src requirements been dropped?  Currently, I dist the pristine

the pre-patch -src requirement has been. See
http://www.cygwin.com/setup.html. No mention of a prepatched source
tarball is made at all.

> Is this sort of what it should be now:
>
>     $ tar xzf foo-1.1-1-src.tar.gz
>     $ ls foo-1.1-1-src
>     foo-1.1-1-src/foo-1.1.tar.gz  # pristine src
yes
>     foo-1.1-1-src/foo-1.1-1.patch # forward diff
yes
>     foo-1.1-1-src/other.patch
what's this?

>
>     $ cat foo-1.1-1-src/doit.sh
>     #!/bin/bash
>     set -e
>     tar xzf foo-1.1.tar.gz
>     mv foo-1.1 foo-1.1-1

Not sure why you're bothering to rename this.

>     cd foo-1.1-1
>     patch -p1 < ../other.patch
>     patch -p1 < ../foo-1.1-1.patch
>     autoconf

autoheader + automake etc etc as needed.

>     ./configure --prefix=/usr
>     make
>     make install prefix=/tmp/foo-root/usr
>     cd /tmp/foo-root
>     tar czf /usr/src/foo-1.1-1.tar.gz *
>
> How about an example dummy package like this?

Chuck went around this with mktemp. It looks similar, but you don't need
to use /tmp, just `pwd`/=install will do.

> Now every package should contain a build script.  Isn't that a step
> backwards in the evolution?  You'd want a central tool(set) to do the
> building and packaging, and package specific scripts/makefile
> snippets.

Yep, like rpm/deb have. But, setup can't read files from either of those
formats (yet).

> >   2) Nobody, and I mean NOBODY, has followed thru on porting,
packaging,
> > and maintaining the berkeley-db and rpm packages as official,
> > cygwin-mirror-system distributed packages (surely that's the FIRST
step
> > before attempting to use rpm as the be-all and end-all package
> > management application for cygwin?  PROVIDE it and maintain an
official
> > port?)
>
> I didn't have the webspace to do that.  But I did implement

Grr. Thats the whole point. Chris has repeatedly offered web space to
interested parties. The WHOLE point is that it should be _here_ for it
to catch on. Then there is no need for any single individual to generate
the whole list of pacakges, or

...
> Also, while I am/was willing to help out the Cygwin project, I'd
> rather work on LilyPond than reinvent packaging/do porting.  I
> hoped people to be interested, discuss and maybe take over what I
> tried to start, but nothing much happened, then.

do porting. So the point is that if RPM had been contributed, and you
maintain *just that one package* as an official package (Hey, Chuck this
goes for you too :}) then there is a chance that it could have caught
on, and maybe the open file issue would have had a workaround
implemented in rpm (which is possible, just non-trivial BTW).

> > a) source code autobuilding and packing
> > b) installation and unpacking
> >
> > Part A assumes you already have a working cygwin development
environment
> > installed on your machine. Part B must be doable on a "virgin"
> > system.
> > Thus, the installer-unpacker must NOT rely on cygwin.
>
> What I did, using rpm, was provide a rpm-x.y.z.bin.tar.gz, including
> necessary libs.  If setup.exe can't run rpm, it gets and untars the
> tarball.  After that, it installs/upgrades the cygwin, rpm, zlib
> .rpm's.  Of course, that's the easy part.  But it wouldn't be hard to
> let setup.exe handle the final placment of any binaries that were in
> use during the rpm phase.  Is that too kludgy?

Potentially. What you have to do is group a set of related files from
multiple packages that solve a dependency issue where *any one* of the
files cannot be installed due to open file issues, schedule those for
copy-after-not-in-use, and the trigger that, and then return to that
exact internal rpm state, and start running the postinstall scripts etc
for that group of files.

> Ok, so, a native port, that should be more feasible with the current
> state of mingw(?), would pose other problems.  But these seem even
> easier to solve?

That hasn't changed - mingw doesn't aim for posix support. A native port
is purely a matter of effort and creating win32 code that does what rpm
does.

> What if you'd only allow setup.exe to choose the cygwin root for the
> first installation?

I'm not sure what that does other than cripple users who want to move
cygwin around on their hard drive.

> You're right to rant here, because my mail really was a rant too, I'm
> sorry.  But I always try to put code first, and then start a
> discussion.  In this case, I've presented rpm stuff, my cross-build
> scripts, and some months ago a patch for a setup.exe postremove
> feature.  Maybe it was bad timing, maybe my code was just too bad, but
> on each of these occasions I got so little sensible feedback if any at
> all.  That turned me off a bit.

BTW: can you freshed up your postremove patch? I'd like that to be
included in setup.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

"Robert Collins" <robert.collins@itdomain.com.au> writes:

> Build environments to recreate a -src package need
> a) pristine source TARBALL.
> b) patch for current -x version
> c) extracted and patched working dir.

> the pre-patch -src requirement has been. See
> http://www.cygwin.com/setup.html. No mention of a prepatched source
> tarball is made at all.

Ah, ok.  I'm just used to those, as I'm rebuilding from available
patched -src packages if possible.
Do we already have -src packages that adhere to this new convention?

If it's not too late, it would be very nice if they could be
distinguished from the old, prepatched -src packages, by using a
different naming convention, ie foo-1.1-cyg.tar.gz?

> >     mv foo-1.1 foo-1.1-1
> 
> Not sure why you're bothering to rename this.

My bad, I was thinking of tarring up the patched src tarball.

> do porting. So the point is that if RPM had been contributed, and you
> maintain *just that one package* as an official package

Ok, but I had conflicting interest: I needed all packages now to
provide lilypond, and couldn't maintain them all for cygwin.  Also, I
assumed, had an rpm or other port caught on, the mirroring at cygnus
would have worked.

> That hasn't changed - mingw doesn't aim for posix support.

Ok.

> BTW: can you freshed up your postremove patch? I'd like that to be
> included in setup.

Yes, will do.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Jan Nieuwenhuizen wrote:


> Do we already have -src packages that adhere to this new convention?


Yep.  mktemp. automake, automake-devel, automake-stable, autoconf,
autoconf-devel, autoconf-stable, cygutils, ...


> If it's not too late, it would be very nice if they could be
> distinguished from the old, prepatched -src packages, by using a
> different naming convention, ie foo-1.1-cyg.tar.gz?


probably too late -- and besides, I don't think setup/upset are prepared 
for source packages that don't end in -src.  But why should they be 
distinguished?  It's up to the maintainer of each package to keep 
track...non-maintainers who want to build it personally should just 
download and follow the instructions.

--Chuck




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

Charles Wilson <cwilson@ece.gatech.edu> writes:

> > different naming convention, ie foo-1.1-cyg.tar.gz?
> 
> probably too late -- non-maintainers who want to build it personally
> should just download and follow the instructions.

Hmm, that sounds awfully unscriptable :-) Am I the only non-maintainer
that uses a script?

Now for something constructive.  What if I fix my scripts to do the
new convention, and we run that over the archive to rebuild everything?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Jan Nieuwenhuizen wrote:

> Charles Wilson <cwilson@ece.gatech.edu> writes:
> 
> 
>>>different naming convention, ie foo-1.1-cyg.tar.gz?
>>>
>>probably too late -- non-maintainers who want to build it personally
>>should just download and follow the instructions.
>>
> 
> Hmm, that sounds awfully unscriptable :-) Am I the only non-maintainer
> that uses a script?


You're in bsd-ports "make world" mode, I see.  I don't think that is a 
goal, yet.  *OUR* concern is "make cygwin work".  Cross environments are 
nice -- but do you really need a cygwin-target man.exe in your cross 
environment? (no, you don't -- unless you're the man maintainer and are 
building the man package for official distribution).  Cross environments 
really only need the devel tools, and the libraries.


> Now for something constructive.  What if I fix my scripts to do the
> new convention, and we run that over the archive to rebuild everything?


Be my guest...but remember those "corner cases" I mentioned?  square 
peg, round hole?  Go back and read the other thread for some of the 
examples.  It is my contention that some (many?) of our ports are not 
yet ready for autobuilding. (cf. jpeg, ncurses, readline, gettext, ...) 
  It's going to take detailed knowledge of an individual package -- 
either to turn it into a round peg, or custom-develop a script.

Suggestion: pick ONE package. convert it.  present it to the maintainer 
and say "Hey, isn't this cool?  Would you like to package up the next 
official release of XXX this way? I'll help convert your other packages 
too..."

And then move on to the next maintainer's packages...

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

Charles Wilson <cwilson@ece.gatech.edu> writes:

> You're in bsd-ports "make world" mode, I see.  I don't think that is a 
> goal, yet.  *OUR* concern is "make cygwin work".

Yes, I guess our priorities don't match.  I've been in "make world"
mode since the b20 days; I needed to build some core development
packages and package additional (possibly unmaintained) packages.
And, I didn't want to do too much manual work for each update of a
package, maintained or unmaintained.

> > Now for something constructive.  What if I fix my scripts to do the
> > new convention, and we run that over the archive to rebuild everything?
> 
> Be my guest...but remember those "corner cases" I mentioned?  square 
> peg, round hole?

Yes, I guess you're right.  Indeed, that's why I have the
lots-of-scripts package: to make each peg round by hand.  Then hope it
will fit with the next release of a package too.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Robert Collins wrote:

> do porting. So the point is that if RPM had been contributed, and you
> maintain *just that one package* as an official package (Hey, Chuck this
> goes for you too :}) 

Yeah, but I don't have that itch.  Sorry, but I don't really *care*
about rpm itself.  I just liked the multidirectory format it used to
separate the various source code/build "script" pieces, which is why my
original packaging proposal said things like /usr/src/cygwin/SPECS/ and
whatnot.

I also got somewhat frustrated with it about a year ago.  I was working
quite a bit with Michael Ring, who was *supposed* to provide official
dllized ports of berk db, and then provide a port of rpm, but he
wandered off into the weeds and I haven't heard anything about that
since Nov 2000.  He did port some stuff and put it in a private
directory on sourceware in Sep 2000 (check cygwin-apps archive), but
nothing since then...

Anyway, that experience kinda burned me on the whole "hey guys let's all
use rpm" bandwagon...

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

Charles Wilson <cwilson@ece.gatech.edu> writes:

> Yeah, but I don't have that itch.  Sorry, but I don't really *care*
> about rpm itself.

No, me neither.  It seemed just more convenient to package my stuff,
although the perl/berk db dependencies didn't really help.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

@%!@#$ AT&T@home smtp server.... it lost my reply to this message, so
this is try #2...

Jan Nieuwenhuizen wrote:

> Well, I still thought it was silly to have identical forward and
> backward patches, when we have a patch -R flag.  Normal mode of
> operation is to (apply and) supply forward patches; now my (and
> everyone else's packaging procedure) I must be rewritten to do unpack,
> rename -> .orig, patch, run diff from .orig tree.  Or, be hacked to
> try to determine the direction of the patch before applying, but

I'm not sure I understand.  It wasn't that you needed to provide a
reverse patch, but that you need to provide the PATCH so that users
could 'unpatch' using 'patch -R'.  The only wackiness was the assertion
that the downloaded source be *already patched*.  So, you get
'pre-patched source' + 'the patch that was used to make it that way',
instead of 'pristine source' + 'the patch you must apply'.

> 
> > You need to understand where that requirement came from: protective
> > action against maintainers who flake out.
> [snip]
> 
> I understand this must be avoided at all cost.
> 
> > So, we said "provide prepatched source" -- because people wanted to
> > just unpack, configure, make -- but also "provide the diff between
> > your source and the official version".
> 
> Sure, but I don't see any advantage in reversed patches.

It's not supposed to be a backward patch; see above.
 
> > Yes, it's a pain.  Yes, there are better ways.  But silly? no.  (I think
> > the silly part was insisting that the source code be PRE-patched.
> 
> Yes, I think that requirement is silly too.  Because people will be
> using a download cache, the pristine source is there too.  Build
> environments now hold pristine sources, patched sources, and patches
> in both directions.  But, whatever gets you going :-)

Well, setup can't yet do what you're implying.  But eventually...

> > there is no iron clad, my-way-or-the-highway standard, but agreement on
> > a number of principles:
> 
> > 1) official, unmodified source code should be provided
> > 2) with a diff (or multiple diffs) that are used to turn the official
> > source into cygwin source
> > 3) there should be some sort of automated script -- shell script,
> > external makefile, *something*, to drive the entire cygwin build
> 
> I'm not sure I understand.  Have the 1-diff,reversed diff, pre-patched
> -src requirements been dropped?  

I think so.

> How about an example dummy package like this?

Okay.  go here:
  http://www.neuro.gatech.edu/users/cwilson/cygutils/packaging/
There are five different versions, each of which demonstrates a
different proposal.  After cgf's "intervention" I pretty much settled on
something like #5 for "my" packages, and that is what the "official"
mktemp package at sourceware uses.  Also cygutils and others.
 
> Now every package should contain a build script.  Isn't that a step
> backwards in the evolution?  

Not really.  It's a lot better than "here are some instructions in this
custom cygwin README -- no, not the official README; look at the custom
one under /usr/doc/Cygwin/.  Follow the instructions
manually...configure with *these* options, 'make install' with *those*
options, etc".  At least a buildscript is automated.  Also, MANY
packages don't even contain instructions (beyond what the primary
distribution site says or includes in the pristine source).  So we don't
know HOW the maintainer configured it...

pop quiz: what are the current configure flags used to build gcc? 
Anyone?  Anyone?  Bueller? (no, Chris, you're not allowed to answer..)

Methinks a build script -- of whatever flavor, sh, make, dpkg, spec --
is a step forward for us.

> You'd want a central tool(set) to do the
> building and packaging, and package specific scripts/makefile
> snippets.

Well, that's what Robert is pushing.  But IMO we shouldn't try to
reinvent THAT wheel (the package building/packing functionality that
other all-in-one package management solutions provide).  In other words,
setup.exe shouldn't become the rpm.exe of cygwin, complete with 'setup
-ba myspecfile'.  Bleagh. We needn't write another tool for this task,
like "cygpack" or something, with yet another grammar to parse and
learn, to drive autobuilds.

There are just too many corner cases and exceptions to deal with.  The
dpkg folk and the rpm folk have already solved (mostly) those issues;
when we're ready we should just USE those tools.  "When we're ready" ==
when setup.exe can install the binary packages created by them.  Which
is not yet.

I described many of the corner cases and exceptions in that other thread
-- probably because most of the things I have chosen to port/maintain
ARE corner cases, so I'm intimately familiar with the problems (or maybe
I'm just not a very good porter, and if I were better at it, I'd've
forced my square-peg-packages into some sort of standardized,
non-corner-case round hole by now...)

Anyway, UNTIL we're ready to make a complete jump over to rpm or dpkg or
whatever, there's no point in developing additional tools.  Custom build
scripts, written in the package maintainer's language of choice -- sh,
perl, make-rules, etc -- provide the *maintainer* with the flexibility
needed to deal with the corner cases (if any) yet allow
newbie-developers to download and build easily.  And we aren't
autocratically forcing all maintainers to "Do it THIS way or go home." 
Which is good -- at least until we adopt rpm or dpkg or something.
 
> > But you gloss over the *reasons* it didn't catch on:
> >
> >   1) There was no true NATIVE port, so you couldn't use rpm to install
> > cygwin itself.
> 
> That is a real problem.  But it solved the cross-building, the
> tarball/patch issue, binary packaging, dependencies, pre/post
> install/remove scripts for me.

And it solved the perl add-on module problem for me.  But once I
relinquished maintaining perl, I had no further need of rpm.  Or
desire.  It's the whole "scratch your own itch" thing.  (Side note: I
*am* considering using the new -- !!not yet ready for public
consumption!! -- libtool to port berk db as a test case...)

> >   2) Nobody, and I mean NOBODY, has followed thru on porting, packaging,
> > and maintaining the berkeley-db and rpm packages as official,
> > cygwin-mirror-system distributed packages (surely that's the FIRST step
> > before attempting to use rpm as the be-all and end-all package
> > management application for cygwin?  PROVIDE it and maintain an official
> > port?)
> 
> I didn't have the webspace to do that.  

That's the thing -- Chris has been offering webspace if folks needed
it.  BUT, you don't even NEED webspace to port a package.  Just port it,
promise to maintain it, and upload it to sourceware.

> But I did implement
> .patch.rpm's (supply pristine source yourself) to work around that,
> and put it up here (where it sits and rots):
> 
>     http://www.xs4all.nl/~jantien/cygnus/b20/PRPMS
>

This is probably why it rots (same as my rpm port): "/b20/".  I figure
anything with "b20" in the name is so old and unmaintained it probably
doesn't work on newer cygwins.  So I just skip over stuff like that.
 
> Also, while I am/was willing to help out the Cygwin project, I'd
> rather work on LilyPond than reinvent packaging/do porting.  

That's fine.  Please continue -- scratch your own itch.  But folks
shouldn't complain when nobody wants to scratch their itch FOR them,
like provide/maintain rpm.

> I
> hoped people to be interested, discuss and maybe take over what I
> tried to start, but nothing much happened, then.
> 
> > > and I built a set of cross-build scripts
> > > from the .spec shell-snippets.
> >
> > that's a neat idea.  Can I see?
> 
> Sure (it's been posted to the cygwin list a couple of times, but as
> there where no reactions, I decided not to spam the list any
> further).  Find the latest here:
> 
>     http://lilypond.org/people/jan/gnu-windows/cygwin-cross-1.3.6.0.tar.gz

[snip]  

I'll take a look this weekend.

> > However, "rpm-like" is still on the table in
> > the sense of:
> >  1) provide pristine source
> >  2) provide the patches
> >  3) provide "something" to autodrive the build (shellscript+sh.exe,
> > debian.rules+dpkg, spec+rpm, whatever)
> 
> Good.
> 
> > a) source code autobuilding and packing
> > b) installation and unpacking
> >
> > Part A assumes you already have a working cygwin development environment
> > installed on your machine. Part B must be doable on a "virgin"
> > system.
> > Thus, the installer-unpacker must NOT rely on cygwin.
> 
> What I did, using rpm, was provide a rpm-x.y.z.bin.tar.gz, including
> necessary libs.  If setup.exe can't run rpm, it gets and untars the
> tarball.  After that, it installs/upgrades the cygwin, rpm, zlib
> .rpm's.  Of course, that's the easy part.  But it wouldn't be hard to
> let setup.exe handle the final placment of any binaries that were in
> use during the rpm phase.  Is that too kludgy?

Sounds like Dario's CART.  Except I think Dario build a special
cygwin1.dll with a different name and shared memory area, and linked his
CART-rpm and CART-sh to THAT.  That way, he could run the installer
tools to install the REAL cygwin and the REAL rpm over in the REAL
location.  Then the CART deleted itself.

> > (This sidesteps the question about "where do you put the package
> > management database for a native windows port of rpm/dpkg/whatever?"
> [..]
> > You can't put it in /var/lib/rpm/ (because cygwin installation will
> > manipulate the mount table; you don't know where /var will BE until
> > after the installation is finished).
> 
> Ok, so, a native port, that should be more feasible with the current
> state of mingw(?), would pose other problems.  But these seem even
> easier to solve?

See Robert's post.

> 
> What if you'd only allow setup.exe to choose the cygwin root for the
> first installation?

Ditto (and ignored).

> > Of all the let's-use-rpm proposals, Dario's makes the most sense --
> > although Robert's eventual plan for setup.exe ain't bad either.

Ditto (and ignored).
 
> Ok, so I missed not only this discussions, but also actual code.
> Ignore my rpm questions above, I'll have a look into these two
> alternatives first.

Okay.
 
> > <rant>
> > Jan, next time try CONTRIBUTING to the discussion, instead of calling
> > the result silly after the fact.
> > </rant>
> 
> You're right to rant here, because my mail really was a rant too, I'm
> sorry.  But I always try to put code first, and then start a
> discussion.  In this case, I've presented rpm stuff, my cross-build
> scripts, and some months ago a patch for a setup.exe postremove
> feature.  Maybe it was bad timing, maybe my code was just too bad, but
> on each of these occasions I got so little sensible feedback if any at
> all.  That turned me off a bit.

It was probably a timing thing (that and everybody hates these packaging
debates.  They're really counterproductive -- a lot of noise, and nobody
works on ACTUAL stuff like fixing cygwin bugs or porting new packages
for a while, and then it's over and nothing's been decided...

Anyway, "some months ago" we were all desperately trying to get
cygwin-1.3.4/5 out the door, and get the new setup.exe with categories
online, and everybody probably said, "Nice idea.  Can't think about that
now. Maybe later..."

It happens.
 
[snip]

> Being only involved occasionally, and going
> through the archives directly, I didn't find out about the apps list
> (and open membership) until recently...

Yep, packaging and setup DEVELOPMENT happen on cygwin-apps. (setup bug
reports, and "wouldn't it be nice if..." belongs on cygwin@ though)

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

Charles Wilson <cwilson@ece.gatech.edu> writes:

> @%!@#$ AT&T@home smtp server.... it lost my reply to this message, so
> this is try #2...

Thanks for doing your try #2

> I'm not sure I understand.  It wasn't that you needed to provide a
> reverse patch,
[..]
> It's not supposed to be a backward patch; see above.

Ok, I mixed stuff in packaging page with older mail discussions and
the actual state of the archive.  Sorry for the confusion.

> Well, setup can't yet do what you're implying.  But eventually...

:-)  Hmm, I do all what I'm 'implying' already.  But no
patched sources, or reversed patches, so I'm happy.

> > How about an example dummy package like this?
> 
> Okay.  go here:
>   http://www.neuro.gatech.edu/users/cwilson/cygutils/packaging/
> There are five different versions, each of which demonstrates a
> different proposal.  After cgf's "intervention" I pretty much settled on
> something like #5 for "my" packages, and that is what the "official"
> mktemp package at sourceware uses.  Also cygutils and others.

Ok thanks for the pointer.  Is there a script to do the packaging?

> pop quiz: what are the current configure flags used to build gcc? 
> Anyone?  Anyone?  Bueller? (no, Chris, you're not allowed to answer..)

   That's easy:

   09:33:15 fred@appel:~/usr/src/cygwin-cross-1.3.6.0$ cat stage/gcc.configure
   mkdir -p $cygpack-build
   cd $cygpack-build

   #urg, --srcdir is broken for 1.1.4
   ##rm -f include && ln -s $cygpack/include include

   sourcedir=$PREFIX/src/$cygpack

   CPPFLAGS="-I $PREFIX/include/w32api"

   CFLAGS="-O2 -g -DATTRIBUTE_NORETURN= -DATTRIBUTE_UNUSED= $CPPFLAGS" \
           $sourcedir/configure --host=$PLATFORM
           --target=$TARGET_PLATFORM \
           --prefix=$prefix -v \
           --enable-threads \
           --with-headers=$PREFIX/$TARGET_PLATFORM/include \
           --with-libs=$PREFIX/$TARGET_PLATFORM/lib

   # URG, brokenstuff
   rm -rf $TARGET_PLATFORM/libiberty
   cp -prv libiberty $TARGET_PLATFORM/libiberty

What do I win?

> We needn't write another tool for this task, like "cygpack" or
> something, with yet another grammar to parse and learn, to drive
> autobuilds.

Ok.  Although my scripts have run a bit out of hand, my autobuilds run
rather well now.  They will only get simpler when packages are
packaged more cleanly.

> Anyway, UNTIL we're ready to make a complete jump over to rpm or dpkg or
> whatever, there's no point in developing additional tools.  Custom build
> scripts, written in the package maintainer's language of choice -- sh,
> perl, make-rules, etc -- provide the *maintainer* with the flexibility
> Which is good -- at least until we adopt rpm or dpkg or something.

Ok.  So you're still aiming for a lot less ambitious target.  This
just means that I'll have to hack up some scripts to do cross
building, as none of them will support it.  Anyway, documentation in
the form of a script is a very good start, I guess.

> And it solved the perl add-on module problem for me.  But once I
> relinquished maintaining perl, I had no further need of rpm.
> It's the whole "scratch your own itch" thing.

Yes.  Or db.

> > I didn't have the webspace to do that.  
> 
> That's the thing -- Chris has been offering webspace if folks needed
> it.  BUT, you don't even NEED webspace to port a package.  Just port it,
> promise to maintain it, and upload it to sourceware.

Ok, I didn't know that.  Feb 1999 I sent this mail:

    http://www.cygwin.com/ml/cygwin/1999-02/msg00822.html

and got no reactions; no questions if I would maintain it; if things
could be uploaded or whatever.  So, I just continued scratching my own
itch.

> I figure anything with "b20" in the name is so old and unmaintained
> it probably doesn't work on newer cygwins.  So I just skip over
> stuff like that.

Sure, but it was skipped over when I announced it, ie b20 was current,
too.

> > all.  That turned me off a bit.
> 
> It was probably a timing thing
> It happens.

I'll try to enter a discussion when it's hot, next time.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Christopher Faylor]

On Thu, Dec 06, 2001 at 10:04:22AM +0100, Jan Nieuwenhuizen wrote:
>Charles Wilson <cwilson@ece.gatech.edu> writes:
>> That's the thing -- Chris has been offering webspace if folks needed
>> it.  BUT, you don't even NEED webspace to port a package.  Just port it,
>> promise to maintain it, and upload it to sourceware.
>
>Ok, I didn't know that.  Feb 1999 I sent this mail:
>
>    http://www.cygwin.com/ml/cygwin/1999-02/msg00822.html
>
>and got no reactions; no questions if I would maintain it; if things
>could be uploaded or whatever.  So, I just continued scratching my own
>itch.

Sadly, I don't believe that I was even in charge of the project in Feb
1999.  And, since I was ill, and the local Cygnus office was being closed
around that time, I probably had other things on my mind.

Regardless, it didn't really require me, or anyone else, to make this
thing fly.  You had a web site.  Why didn't people beat a path to your
door?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Jan Nieuwenhuizen wrote:

> 
> Ok thanks for the pointer.  Is there a script to do the packaging?


yep -- each script contains a script (in some package schemes -- #3, I 
think -- you have to apply the patch FIRST, and then the script is 
created in <srcdir>/CYGWIN-PATCHES/ or something).


>>pop quiz: what are the current configure flags used to build gcc? 
>>Anyone?  Anyone?  Bueller? (no, Chris, you're not allowed to answer..)
>>
> 
>    That's easy:
> 
> What do I win?


No, no, no.  Not "What flags does Jan use" but "What flags WERE used to 
build the official cygwin gcc package".  (Hint: only cgf knows for sure)


> Ok.  Although my scripts have run a bit out of hand, my autobuilds run
> rather well now.  They will only get simpler when packages are
> packaged more cleanly.


Mine too.


> Ok.  So you're still aiming for a lot less ambitious target.  This
> just means that I'll have to hack up some scripts to do cross
> building, as none of them will support it.  


Yep -- you'll have to edit the line where it says "host=i686-pc-cygwin" 
and change it to something appropriate.

> Anyway, documentation in
> the form of a script is a very good start, I guess.
> 
> Ok, I didn't know that.  Feb 1999 I sent this mail:
> 
>     http://www.cygwin.com/ml/cygwin/1999-02/msg00822.html

...

> Sure, but it was skipped over when I announced it, ie b20 was current,
> too.
 

Ah, but back in b20 days we didn't HAVE package-based distribution. 
Everything was all in one "full.exe" 21MB download. There was no way for 
a non-core developer to add something like "rpm" to the distro back then 
-- it just wasn't possible.  A lot of things have changed in 3 years.

--Chuck







--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Robert Collins]

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> > You'd want a central tool(set) to do the
> > building and packaging, and package specific scripts/makefile
> > snippets.
>
> Well, that's what Robert is pushing.  But IMO we shouldn't try to
> reinvent THAT wheel (the package building/packing functionality that
> other all-in-one package management solutions provide).  In other
words,
> setup.exe shouldn't become the rpm.exe of cygwin, complete with 'setup
> -ba myspecfile'.  Bleagh. We needn't write another tool for this task,
> like "cygpack" or something, with yet another grammar to parse and
> learn, to drive autobuilds.

Agreed. I never wanted us to reinvent the wheel. Rpm/deb file reading
support (not the backend stuff at this point) *is* on the cards. I do
want maintainers life to be easy :}.


> > Also, while I am/was willing to help out the Cygwin project, I'd
> > rather work on LilyPond than reinvent packaging/do porting.
>
> That's fine.  Please continue -- scratch your own itch.  But folks
> shouldn't complain when nobody wants to scratch their itch FOR them,
> like provide/maintain rpm.

Better words that I could find - ditto from this corner!


> > Being only involved occasionally, and going
> > through the archives directly, I didn't find out about the apps list
> > (and open membership) until recently...

Point of order: The mailing list website has listed cygwin-apps as being
open for forever and a day.

> Yep, packaging and setup DEVELOPMENT happen on cygwin-apps. (setup bug
> reports, and "wouldn't it be nice if..." belongs on cygwin@ though)

Non-public code bug reports do belong here under the guidelines I posted
~ a week ago. net release bugs goto cygwin@. How to tell the difference?
If you grok the code you can post a setup bug here (only half joking)
:}.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Charles Wilson]

Robert Collins wrote:

> Non-public code bug reports do belong here

you mean, bug reports for non-public code belong on ***cygwin-apps@***,
right?  This thread is on cygwin@ (originally because of the texmf
thing, and Gerrit's Reply-To address).  Perhaps this setup-related
subthread should be moved to cygwin-apps?

Err, whataminute.  Come to think of it, this thread has encompassed
adding a new texmf-related package to the dist, and modifying the
current texmf-beta package, renaming issues,...

Maybe the whole thing belongs over on cygwin-apps, and not only the
setup-related stuff...

> under the guidelines I posted
> ~ a week ago. net release bugs goto cygwin@. How to tell the difference?
> If you grok the code you can post a setup bug here (only half joking)
> :}.
> 
> Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Robert Collins]

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>


> Robert Collins wrote:
>
> > Non-public code bug reports do belong here
>
> you mean, bug reports for non-public code belong on
***cygwin-apps@***,
> right?  This thread is on cygwin@ (originally because of the texmf
> thing, and Gerrit's Reply-To address).  Perhaps this setup-related
> subthread should be moved to cygwin-apps?

Gee whaddya know. OOPS.

> Err, whataminute.  Come to think of it, this thread has encompassed
> adding a new texmf-related package to the dist, and modifying the
> current texmf-beta package, renaming issues,...

Yes, this discussion is nearly 100% cygwin-apps fodder.

BTW: Gerrit, if you post with a munged Reply-To: Address, could you
please also Munge your 'readable version' to be something like "Gerrit
Haase @ Cygwin" rather than just "Gerrit P. Haase"?

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Robert,

Am 2001-12-08 um 03:51 schriebst du:

> BTW: Gerrit, if you post with a munged Reply-To: Address, could you
> please also Munge your 'readable version' to be something like "Gerrit
> Haase @ Cygwin" rather than just "Gerrit P. Haase"?

Yes, good point to avoid trouble.

I would prefer if the listserver would manage this and rewrite the Reply-To
Header regardless who is writing, so it points always to the list.

This is done at Yahoo lists and several other lists I'm subscribed to.
That is why I'm used to this behaviour.

A simple ctrl-r is enough then (with my mailer), and the reply goes only
to the list, now if I want to reply to the list I need to change the adress
everytime I want this (besides the few who have cygwin@cygwin as reply-to
header like corinna or chris).
To make it easier I hit reply-all and delete the adresses I want to exclude,
but it is annoying and often I send out a mail three times because I'm lazy.

I could make it easy and send always to all, but then you or Chuck and others
gets this message twice which isn't that good.

Also it was the case before I set the Reply-To on the listadress that I was
getting every reply from you or Chris and others to me twice which is annoying
too, with the modified reply-to I get these messages only one time.

As long it isn't handled by the listserver it is obviously the best option
for me to change the readable sender name and let the reply-to as it is now.

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

lists, reply-to (was: experimental texmf packages)

[Jochen Küpper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 8 Dec 2001 13:17:26 +0100 Gerrit P Haase wrote:

Gerrit> I would prefer if the listserver would manage this and rewrite
Gerrit> the Reply-To Header regardless who is writing, so it points
Gerrit> always to the list.

That is not what reply-to is intended for.

Gerrit> A simple ctrl-r is enough then (with my mailer), and the reply
Gerrit> goes only to the list, now if I want to reply to the list I
Gerrit> need to change the adress everytime I want this (besides the
Gerrit> few who have cygwin@cygwin as reply-to header like corinna or
Gerrit> chris).

Ha, you do a reply (r/R/whatever) to get back to the author or an
*followup* (f/F/...) to get back to the list:)) So check your mailer
how to do a followup...

Ok, I see you guys want to avoid to get private responses. I don't
[1], sometimes that is exactly what I want.

Yes, I understand that many people don't know how to handle their
mailers (no offense), and some mailers are crappy in that respect, but
setting reply-to in listbots generates at least as much confusion as
it helps.

Suggestion: You could filter the different cygwin-mls into different
folders (you probably do that already) and then tell your MUA to set
your *individual* reply-to depending on the folder you are in. [2]

Greetings,
Jochen

Footnotes: 
[1]  I know, I get way less replys from the cygwin lists and then they
     are intended for me, not the list, whereas some of you guys have
     to suffer from people that think an individual is of more help
     than the list (that individual is actually reading:).
[2]  I can tell you how to do that in Gnus, but I assume that many
     mailers do have similar functionality by now.
- -- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: 44BCCD8E
        Sex, drugs and rock-n-roll
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6-cygwin-fcn-1 (Cygwin)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>

iD8DBQE8Ej+1iJ/aUUS8zY4RAkaGAKCzVbJj1r81l26fB4/oz396KVuqGgCfUe90
XVsPLPqg/59e/Ts5bBmCz5I=
=h74B
-----END PGP SIGNATURE-----


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: lists, reply-to (was: experimental texmf packages)

[Robert Collins]

----- Original Message -----
From: "Jochen Küpper" <jochen@unc.edu>
> Gerrit> I would prefer if the listserver would manage this and rewrite
> Gerrit> the Reply-To Header regardless who is writing, so it points
> Gerrit> always to the list.
>
> That is not what reply-to is intended for.

We are going off topic. There are valid arguments on both sides.

The have both been bosted to one of the cygwin lists in the last
quarter.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: lists, reply-to (was: experimental texmf packages)

[Robert Collins]

===
----- Original Message ----- 
From: "Robert Collins" <robert.collins@itdomain.com.au>
 
> The have both been bosted to one of the cygwin lists in the last
.....................p............................................

Rob



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

guile-1.6 [WAS: experimental texmf packages]

[Jan Nieuwenhuizen]

"Gerrit P. Haase" <gp@familiehaase.de> writes:

>> Btw, how is your guile contribution coming along?
>
> The static build is ok, same quality as yours, only two minor patches.
> Dynamic seems to make problems at least with lilypond, also another guy
> was not able to rebuild it with my patch, I think we should include the
> static version and wait until 1.6 is released to provide a build with
> static and dynamic libraries.

As 1.6 seems to be imminent, I've tried to cross-compile it yesterday,
but it seems that there are problems configuring the ltdl subdir.

Here's what I tried, latest cvs:

  guile-1.5.4-1-build $ ../guile-1.5.4-1/configure --build=i686-gnu-linux \
    --host=i686-pc-cygwin --prefix=/usr --program-suffix= \
    --program-prefix=
  [..]
  configure: creating ./config.status
  config.status: creating Makefile
  configure: configuring in libltdl
  configure: running /bin/sh '../../guile-1.5.4-1/libltdl/configure'
  --build=i686-gnu-linux --host=i686-pc-cygwin --prefix=/usr
  --program-suffix= --program-prefix= build_alias=i686-gnu-linux
  host_alias=i686-pc-cygwin --enable-ltdl-install
  --cache-file=/dev/null --srcdir=../../guile-1.5.4-1/libltdl
  configure: warning: build_alias=i686-gnu-linux: invalid host type
  configure: warning: host_alias=i686-pc-cygwin: invalid host type
  configure: error: can only configure for one host and one target at
  a time
  configure: error: /bin/sh '../../guile-1.5.4-1/libltdl/configure'
  failed for libltdl
  sed: can't read confdefs.h: No such file or directory

Do you have any insights on this, should I forward this to guile-devel?

Also, note:

    http://mail.gnu.org/pipermail/guile-devel/2002-January/004456.html

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jerome BENOIT]

> 
> I tried this, but it seems that a plain rebuild gives some (small)
> problems; the binary executables don't get a .exe extension, eg.

I do not understand: does your source come from the cygwin distribution
?

Thanks inadvance,
Jerome BENOIT

> 
> Greetings,
> Jan.
> 
> Btw, how is your guile contribution coming along?
> 
> --
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
> http://www.xs4all.nl/~jantien       | http://www.lilypond.org
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
  *º¤., ¸¸,.¤º*¨¨¨*¤    Jerome BENOIT, Ph.D.    *º¤., ¸¸,.¤º*¨¨¨*¤
                  Institute of Molecular Biology
               Friedrich-Schiller University of Jena
             Winzerlaer Strasse 10, Jena 07745, Germany
  *º¤., ¸¸,.¤º*¨¨¨*¤    JGMBenoit@wanadoo.fr    *º¤., ¸¸,.¤º*¨¨¨*¤

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Jerome,

Am 2001-11-29 um 22:42 schriebst du:

>> I tried this, but it seems that a plain rebuild gives some (small)
>> problems; the binary executables don't get a .exe extension, eg.

> I do not understand: does your source come from the cygwin distribution
> ?

Maybe something with his cross compilation environment is wrong?

Another question, is there a chance that tetex-beta will be rebuilt?

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jerome BENOIT]

"Gerrit P. Haase" wrote:
> 
> Hallo Jerome,
> 
> Am 2001-11-29 um 22:42 schriebst du:
> 
> >> I tried this, but it seems that a plain rebuild gives some (small)
> >> problems; the binary executables don't get a .exe extension, eg.
> 
> > I do not understand: does your source come from the cygwin distribution
> > ?
> 
> Maybe something with his cross compilation environment is wrong?

I guess so: under cygwin the extension ".exe" is implicit.

> 
> Another question, is there a chance that tetex-beta will be rebuilt?

I can rebuilt that tetex-beta soon:
can you send me a small sample file that generates troubles  ?

Thanks in advance,
Jerome BENOIT 

> 
> Ciao,
> 
> Gerrit P. Haase                            mailto:gp@familiehaase.de
> --
> =^..^=
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
  *º¤., ¸¸,.¤º*¨¨¨*¤    Jerome BENOIT, Ph.D.    *º¤., ¸¸,.¤º*¨¨¨*¤
                  Institute of Molecular Biology
               Friedrich-Schiller University of Jena
             Winzerlaer Strasse 10, Jena 07745, Germany
  *º¤., ¸¸,.¤º*¨¨¨*¤    JGMBenoit@wanadoo.fr    *º¤., ¸¸,.¤º*¨¨¨*¤

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jerome BENOIT]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

"Gerrit P. Haase" wrote:
> 
> Hallo Jerome,
> 
> Am 2001-11-29 um 22:42 schriebst du:
> 
> >> I tried this, but it seems that a plain rebuild gives some (small)
> >> problems; the binary executables don't get a .exe extension, eg.
> 
> > I do not understand: does your source come from the cygwin distribution
> > ?
> 
> Maybe something with his cross compilation environment is wrong?

I guess so: under cygwin the extension ".exe" is implicit.

> 
> Another question, is there a chance that tetex-beta will be rebuilt?

I can rebuilt that tetex-beta soon:
can you send me a small sample file that generates troubles  ?

Thanks in advance,
Jerome BENOIT 

> 
> Ciao,
> 
> Gerrit P. Haase                            mailto:gp@familiehaase.de
> --
> =^..^=
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
  *º¤., ¸¸,.¤º*¨¨¨*¤    Jerome BENOIT, Ph.D.    *º¤., ¸¸,.¤º*¨¨¨*¤
                  Institute of Molecular Biology
               Friedrich-Schiller University of Jena
             Winzerlaer Strasse 10, Jena 07745, Germany
  *º¤., ¸¸,.¤º*¨¨¨*¤    JGMBenoit@wanadoo.fr    *º¤., ¸¸,.¤º*¨¨¨*¤

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

Hallo Jerome,

Am 2001-11-29 um 22:42 schriebst du:

>> I tried this, but it seems that a plain rebuild gives some (small)
>> problems; the binary executables don't get a .exe extension, eg.

> I do not understand: does your source come from the cygwin distribution
> ?

Maybe something with his cross compilation environment is wrong?

Another question, is there a chance that tetex-beta will be rebuilt?

Ciao,

Gerrit P. Haase                            mailto:gp@familiehaase.de
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

520066587150-0001@t-online.de (Jerome BENOIT) writes:

> > 
> > I tried this, but it seems that a plain rebuild gives some (small)
> > problems; the binary executables don't get a .exe extension, eg.
> 
> I do not understand: does your source come from the cygwin distribution
> ?

Yes; but possibly it's an artifact of cross-compilation.  I'm using a
script to fix this for my other packages.

It's being suggested that tetex-beta needs a rebuild, do you want to
do that?  Also, if/when texmf gets included in Cygwin, would you be
willing to add dependencies on texmf-base and libncurses6?  Maybe
tetex and texmf packages should be put in a group 'tex' or
'publishing' or so.

Greetings,

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

520066587150-0001@t-online.de (Jerome BENOIT) writes:

> > 
> > I tried this, but it seems that a plain rebuild gives some (small)
> > problems; the binary executables don't get a .exe extension, eg.
> 
> I do not understand: does your source come from the cygwin distribution
> ?

Yes; but possibly it's an artifact of cross-compilation.  I'm using a
script to fix this for my other packages.

It's being suggested that tetex-beta needs a rebuild, do you want to
do that?  Also, if/when texmf gets included in Cygwin, would you be
willing to add dependencies on texmf-base and libncurses6?  Maybe
tetex and texmf packages should be put in a group 'tex' or
'publishing' or so.

Greetings,

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jerome BENOIT]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

> 
> I tried this, but it seems that a plain rebuild gives some (small)
> problems; the binary executables don't get a .exe extension, eg.

I do not understand: does your source come from the cygwin distribution
?

Thanks inadvance,
Jerome BENOIT

> 
> Greetings,
> Jan.
> 
> Btw, how is your guile contribution coming along?
> 
> --
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
> http://www.xs4all.nl/~jantien       | http://www.lilypond.org
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
  *º¤., ¸¸,.¤º*¨¨¨*¤    Jerome BENOIT, Ph.D.    *º¤., ¸¸,.¤º*¨¨¨*¤
                  Institute of Molecular Biology
               Friedrich-Schiller University of Jena
             Winzerlaer Strasse 10, Jena 07745, Germany
  *º¤., ¸¸,.¤º*¨¨¨*¤    JGMBenoit@wanadoo.fr    *º¤., ¸¸,.¤º*¨¨¨*¤

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

"Gerrit P. Haase" <freeweb@nyckelpiga.de> writes:

> >     texconfig confall
> >     texconfig rehash
> >     texconfig init
> 
> Seems to work ok.

Good.  Has this been tried with an automatic setup install, or did you
run texconfig by hand?  It should work right out of the box.  It would
be good to have tetex-beta depend upon tetex-base, and libncurses5
(for texconfig) imho; while having the other texmf packages should
marked optional.  How do we arrange that?

Also, what are the drills for a cygwin submission?  I'm not running
cygwin myself (I'm allowed to use GNU/Linux at work :-)), but I've
read something about setup hints...

> I'm in favour to include it in the net release. (and if it is no problem
> of my setup, tetex needs a rebuild?)

I tried this, but it seems that a plain rebuild gives some (small)
problems; the binary executables don't get a .exe extension, eg.

Greetings,
Jan.

Btw, how is your guile contribution coming along?

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Gerrit P. Haase]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

Hallo Jan,

2001-11-26 15:39:17, du schriebst:

> This week I've taken a quick stab at packaging a texmf tree that goes
> with the tetex-beta in contrib, so you'll need that too.

> The experimental tarballs are at

>     http://lilypond.org/people/jan/gnu-windows/tar/texmf/

> if you unpack them by hand, you'll need to run

>     /etc/postinstall/texmf-base.sh

> after unpacking.  Note that tetex-beta should be installed when you do
> this.

>     texconfig confall
>     texconfig rehash
>     texconfig init

Seems to work ok., besides a minor problem, pdftex & pdfetex cannot find
the entry point 'png_init_io' to cygpng2.dll. I tried also with the previous
version of png, but doesn't work.

I'm in favour to include it in the net release. (and if it is no problem
of my setup, tetex needs a rebuild?)

Gerrit
-- 
convey Information Systems GmbH                   http://www.convey.de/
                                                  Vitalisstraße 326-328
Gerrit P. Haase                                   D-50933 Köln
gerrit.haase@convey.de                            Fon: ++49 221 6903922


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

experimental texmf packages

[Jan Nieuwenhuizen]

Hi List,

This week I've taken a quick stab at packaging a texmf tree that goes
with the tetex-beta in contrib, so you'll need that too.

This is needed to replace miktex as part of the GNU LilyPond
( http://www.lilypond.org ) installation on Windows, and recently the
tetex-beta packager seemed to mention that he was not planning to
package the texmf tree, which we were so eagerly waiting for (this
pkg should make that job a piece of cake).

It's packaged in three parts, texmf-base, texmf-doc, and texmf-extra.
After selecting installing tetex-beta (from cygwin) and texmf-base,
you should have a functioning TeX setup.

The experimental tarballs are at

    http://lilypond.org/people/jan/gnu-windows/tar/texmf/

if you unpack them by hand, you'll need to run

    /etc/postinstall/texmf-base.sh

after unpacking.  Note that tetex-beta should be installed when you do
this.

There may or may not be a working setup.ini at:

    http://lilypond.org/people/jan/gnu-windows

When this works, it will be submitted to cygwin.

If you're unlucky, read /usr/share/doc/tetex-beta-20000804/INSTALL,
edit /usr/share/texmf/web2c/*cnf, and run

    texconfig confall
    texconfig rehash
    texconfig init

These packages all built on GNU/Linux using mirror, build and
packaging scripts at:

    http://lilypond.org/people/jan/gnu-windows/cygwin-cross-1.3.5.3.tar.gz

Note that this is all quite experimental, and on top of that, I'll be
off-line for about a week, but I didn't want to keep this from you.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: experimental texmf packages

[Billinghurst, David (CRTS)]

Jan,

I have successfully installed your texmf packages using setup.  I just put
your files in my existing downloaded files and edited my existing setup.ini
to add the texmf-* hints.

Simple tests for tex, latex and dvips work.  I will have a play over the
weekend and see what I can break.


-----Original Message-----
From: Jan Nieuwenhuizen [mailto:janneke@gnu.org]
Sent: Saturday, 24 November 2001 12:24 
To: cygwin@cygwin.com
Subject: experimental texmf packages


Hi List,

This week I've taken a quick stab at packaging a texmf tree that goes
with the tetex-beta in contrib, so you'll need that too.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: experimental texmf packages

[Jan Nieuwenhuizen]

"Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com> writes:

> I have successfully installed your texmf packages using setup.  I just put
> your files in my existing downloaded files and edited my existing setup.ini
> to add the texmf-* hints.
> 
> Simple tests for tex, latex and dvips work.  I will have a play over the
> weekend and see what I can break.

Thanks, please do.  I'll be making them Cygwin compliant, while Jerome
will rebuild the tetex-beta package because of libpng issues.  Also we'll
have to look at config file settings before these get into Cygwin.

Greetings,

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/