Re: libwmf's sdesc and ldesc

[Gerrit P. Haase]

Hi John,

> Hi all,

> In libwmf's sdesc and ldesc should Windows and Microsoft
> have a stroke through the o?  (sorry to whoever's language
> uses this character, I really should know what it's called!)

> Just wondering,

I copied it from the libwmf website, it is also in the original sources.
Unless it causes problems, I want to keep it, this is the way the
authour describes his software;)

Gerrit
-- 
=^..^=

Re: [ITP-2] glib-2.4.2-1

[Gerrit P. Haase]

Hi Charles,

> Gerrit P. Haase wrote:

>>>It's such things that makes some people think GLib is a GNOME 
>>>or graphical library and should be avoided at all.

>> I agree. There are some overlappings though.  But since there are
>> already some of the core libraries of the GNOME desktop in /usr we
>> should just stay with it.

> I support the /opt/gnome2/ (or whatever) idea for gnome libs and apps.
> However, I wouldn't cry -- and would probably support -- the idea of 
> NON-gnome libs, which are currently not yet part of cygwin, but which 
> gnome uses, to live in /usr.  Like glib, audiofile, etc.

> OTOH, gtk+, being a windowing library, could go either way IMO.  If it
> goes in /opt/gnome2/, then later some genius could provide gtk+win which
> could live in /opt/gnome2-win/ and use MSW windowing+cygwin(*) instead
> of X+cygwin. (I assume that the folks behind this gnome-push are 
> thinking X-based, right?)  OTO-Other-H, gtk+ != gnome, and there are 
> plenty of non-gnome apps that use plain-old-gtk; this mitigates against
> /opt/*.

I have actually not started to build gtk+-2.4.x, I think it should be
possible to include both versions in one package.

> Good thing I'm not in charge of these decisions, or nothing would get 
> done. :-)

[...]

Gerrit
-- 
=^..^=

RE: libwmf's sdesc and ldesc

[Morrison, John]

Gerrit P. Haase wrote:
> Hi John,
> 
>> Hi all,
> 
>> In libwmf's sdesc and ldesc should Windows and Microsoft
>> have a stroke through the o?  (sorry to whoever's language
>> uses this character, I really should know what it's called!)
> 
>> Just wondering,
> 
> I copied it from the libwmf website, it is also in the original
> sources. Unless it causes problems, I want to keep it, this is the
> way the authour describes his software;)

OK.  Strange, but Ok :)

J.


This e-mail has come from Experian International: winner of the UK's National Business 
of the Year Award 2003.

==
Information in this e-mail and any attachments are confidential, and may 
not be copied or used by anyone other than the addressee, nor disclosed 
to any third party without our permission. There is no intention to 
create any legally binding contract or other binding commitment through 
the use of this electronic communication unless it is issued in accordance 
with the Experian Limited standard terms and conditions of purchase or 
other express written agreement between Experian Limited and the recipient 
Experian Limited (registration number 653331) Registered office: 
Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this communication 
and any attachments are free from computer virus, you are advised to take 
your own steps to ensure that they are actually virus free.

Re: [ITP] atk-1.6.1-1

[Gerrit P. Haase]

Hi Igor,

>> >> Devel package setup.hint:
>> >> ===
>> >> category: Libs Devel
>> >> requires: glib2
>> >> sdesc: "headers and import libraries for ATK"
>>
>> > No ldesc?
>>
>> Well, I could add
>> ldesc: "headers and import libraries for ATK"
>> or s.th. similar?

> Yep, this should be ok.

Ok, I added a ldesc now.

Gerrit
-- 
=^..^=

[ITP] gtk-doc (was: Re: [ITP-2] glib-2.4.2-1 (NOT YET))

[Gerrit P. Haase]

Hi Yaakov,

> The build script needs a couple of changes; the patch is attached.  The
> rest of us don't have a working gtk-doc installation, so
> - --disable-gtk-doc is needed.  Note that the resulting glib2-doc tarball
> is half the size of yours, although the file list is the same AFAICT;
> not sure why.

Since I have gtk-doc installed and I'm the maintainer tobe I don't see
why it is needed to remove the flag.  However, it is not much more work
as I already have loaded on my plate to provide also a gtk-doc package
since it is a prerequisite to build gnome packages (at least for the CVS
versions). 

Gerrit
-- 
=^..^=

openjade needed (was: Re: [ITP] gtk-doc)

[Gerrit P. Haase]

Hi all,

>> The build script needs a couple of changes; the patch is attached.  The
>> rest of us don't have a working gtk-doc installation, so
>> - --disable-gtk-doc is needed.  Note that the resulting glib2-doc tarball
>> is half the size of yours, although the file list is the same AFAICT;
>> not sure why.

> Since I have gtk-doc installed and I'm the maintainer tobe I don't see
> why it is needed to remove the flag.  However, it is not much more work
> as I already have loaded on my plate to provide also a gtk-doc package
> since it is a prerequisite to build gnome packages (at least for the CVS
> versions). 

Oh no, it requires openjade..

Is there someone out there who is able to build the current version of
openjade / opensp.  The last time I tried to compile openjade it fails
with weird compiler errors.  OpenSP should build with dynamic libraries
without too much hassle.


Gerrit
-- 
=^..^=

docbook-dsssl wanted

[Gerrit P. Haase]

Hi Marcel,

are you interested to provide also a package for the DocBook DSSSL
Stylesheets: http://docbook.sourceforge.net/projects/dsssl/ ?


Gerrit
-- 
=^..^=

gtk-doc toolchain (was: Re: [ITP] gtk-doc (was: Re: [ITP-2] glib-2.4.2-1 (NOT YET)))

[Gerrit P. Haase]

Hi Marcel,

> Hi Yaakov,

>> The build script needs a couple of changes; the patch is attached.  The
>> rest of us don't have a working gtk-doc installation, so
>> - --disable-gtk-doc is needed.  Note that the resulting glib2-doc tarball
>> is half the size of yours, although the file list is the same AFAICT;
>> not sure why.

> Since I have gtk-doc installed and I'm the maintainer tobe I don't see
> why it is needed to remove the flag.  However, it is not much more work
> as I already have loaded on my plate to provide also a gtk-doc package
> since it is a prerequisite to build gnome packages (at least for the CVS
> versions). 

Since openjade and docbook-dsssl are not available as official cygwin
packages, I post gtk-doc as unofficial package for those who want a
working gtk-doc installation: http://anfaenger.de/cygwin/gtk+/gtk-doc/
An update to gtk-doc-1.2 is following soon.  No setup support for
gtk-doc yet, sorry.  Anyway, there are only some templates and scripts,
dependencies are: a working docbook toolchain (see below) and perl.


You'll need a working openjade installation and docbook-dsssl besides
the cygwin packages libxml2, docbook-xml2 and docbook-xsl.

>From here: http://anfaenger.de/cygwin/docbook, all but tei-xml & tei-xsl
are required (see attached screenshot).

Best bet is to point setup.exe to http://anfaenger.de/cygwin and let
setup do the work.


Later get an update for DSSSL from
http://docbook.sourceforge.net/projects/dsssl/ 

See also the hints at the README: http://anfaenger.de/cygwin/gtk+/gtk-doc/

I use this script to install an initial docbook catalog with which works
ok for me: http://anfaenger.de/cygwin/docbook/buildDocBookCatalog
which is a modified version from this script found here:
http://xmlsoft.org/buildDocBookCatalog 

With this modification, the docbook-xsl path from the cygwin docbook-xsl
package is found which seems to be not 'default' if there is anything
like a default for docbook related things.

It should output s.th. like this:

$ /usr/bin/buildDocBookCatalog
Found DocBook XML 4.1.2 DTD in /usr/share/xml/docbook-4.1.2
Found ISO DocBook entities in /usr/share/xml/docbook-4.1.2/ent
Found DocBook XSLT stylesheets in /usr/share/docbook-xsl



However, I'm not sure if this is all what is needed to get gtk-doc up
and running...


Gerrit
-- 
=^..^=

Re: gtk-doc toolchain (was: Re: [ITP] gtk-doc (was: Re: [ITP-2] glib-2.4.2-1 (NOT YET)))

[Gerrit P. Haase]

Gerrit wrote:

lots of stuff, but no screenshot was attached, posted here now:
http://anfaenger.de/cygwin/docbook/setup.exe.JPG


Gerrit
-- 
=^..^=

RE: Generic build script instructions

[Igor Pechtchanski]

On Thu, 17 Jun 2004, Robb, Sam wrote:

> > Well, yes, I agree that if you really anticipate having to maintain
> > multiple packages from the outset, and want to keep more or less the same
> > build procedure for each of them (helps if they are related), you should
> > probably start already with something more sophisticated than the gbs.
>
> I don't know.  The gbs seems to be pretty good at accomplishing
> it's goals without introducing a whole lot of extra overhead;
> the main problem would seem to be that there's really no way
> to customize the script without altering it.
>
> So, to answer that question, why not something like this:
>
>   # --- BEGIN_DEFS ---
>   if [ -f ${FULLPKG}.defs ]; then
> . ${FULLPKG}.defs
>   fi
>   # --- END_DEFS ---
>
> So, if my source package name is foo.tar.Z, then I can put the
> following in my defs file:
>
>   # Maintainer defs file for package foo
>   src_orig_pkg_name=foo.tar.Z
>   opt_decomp=z
>
> This would allow a package maintainer to put specializatons/
> definitions within a defs file for each package, making for
> easier maintentance (except in cases of siginificantly unusual
> packages).
>
> Next, modify the gbs so that the version of the gbs that
> gets included as part of the source package is result of
> merging the defs file and the canonical gbs.  In the above
> example, when the maintainer built the source package,
> everything in between the BEGIN_DEFS and the END_DEFS lines
> would be replaced with the actual contents of the maintainer's
> def file for the package, so that the packaged gbs would
> actually look like the following:
>
>   # --- BEGIN_DEFS ---
>   src_orig_pkg_name=foo.tar.Z
>   opt_decomp=z
>   # --- END_DEFS ---
>
> For this to really be effective, you'd have to have the ability
> to override more than just the source package name and the
> decompression flags :-/
>
> You could probably get fancy, and do things like allow the defs
> file to override individual functions (ie, unpack() checks to
> see if defs_unpack() is defined; if it is, it calls defs_unpack(),
> otherwise it calls std_unpack(), etc.)

Well, that was essentially the idea that started this thread, except that
I was thinking of (a) always embedding the .defs file at the end of the
package-specific build script (b) as a patch.  I tried to get the gbs to
the state where for most purposes one would just need to change a few
variables / override a function or two, and let the gbs do its magic.
Perhaps instead of a patch we could define a setup() function that will
initially be empty, and have the maintainers redefine it.  Then all the
standard values will be assigned only if the variables weren't already
defined by the setup() function.

FWIW, I don't think Gary's right on croaking if there's no .defs file --
for some (most?) packages, the gbs is fine as is, and we can always assume
a missing .defs file the same as an empty one (i.e., accept the defaults).
This is especially true if one adopts an "empty default setup()" approach.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: openjade needed (was: Re: [ITP] gtk-doc)

[Joshua Daniel Franklin]

On Thu, 17 Jun 2004 11:49:11 +0200, Gerrit P. Haase
<[EMAIL PROTECTED]> wrote:
> Is there someone out there who is able to build the current version of
> openjade / opensp.  The last time I tried to compile openjade it fails
> with weird compiler errors.  OpenSP should build with dynamic libraries
> without too much hassle.

I haven't tried in a while, but I got confusing errors last time too.

[ITP] pango-1.4.0

[Gerrit P. Haase]

Hello,

I want to contribute/maintain Pango.
Canonical website: http://www.pango.org/

This is number three of four of the base/core GNOME libraries.


Runtime package setup.hint:
===
category: Libs Devel Text
requires: cygwin expat glib2 libXft2 libfontconfig1 libfreetype26 libiconv2 libintl2 
xorg-x11-bin-dlls zlib
sdesc: "library for layout and rendering of text"
ldesc: "Pango is a library for layout and rendering of text, with an
emphasis on internationalization. Pango can be used anywhere that text
layout is needed; however, most of the work on Pango-1.0 was done using
the GTK+ widget toolkit as a test platform. Pango forms the core of text
and font handling for GTK+-2.x."



Devel package setup.hint:
===
category: Libs Devel Text
requires: pango
sdesc: "support files, import library and headers for Pango"
ldesc: "support files, import library and headers for Pango,
see main package for detailed description."



Doc package setup.hint:
===
category: Libs Devel Text Doc
sdesc: "documentation and manpages for Pango"
ldesc: "documentation and manpages for Pango,
see main package for detailed description."



Download:
===
http://anfaenger.de/cygwin/gtk+/pango/pango-1.4.0-1-src.tar.bz2
http://anfaenger.de/cygwin/gtk+/pango/pango-1.4.0-1.tar.bz2
http://anfaenger.de/cygwin/gtk+/pango/pango-devel-1.4.0-1.tar.bz2
http://anfaenger.de/cygwin/gtk+/pango/pango-doc-1.4.0-1.tar.bz2
http://anfaenger.de/cygwin/gtk+/pango/md5sums

http://anfaenger.de/cygwin/gtk+/pango/setup.hint
http://anfaenger.de/cygwin/gtk+/pango/setup.hint.devel
http://anfaenger.de/cygwin/gtk+/pango/setup.hint.doc


Gerrit
-- 
=^..^=

Re: Generic build script instructions

[Bas van Gompel]

Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski 

in <[EMAIL PROTECTED]>:
:  On Tue, 15 Jun 2004, Max Bowsher wrote:
[...]
: > This makes me wonder if it might be sensible for all package maintainers
: > to say a little about their packaging methods, maybe even leading to a
: > plan for a new standard cygwin package building system.
[...]
:  I absolutely agree.  If package maintainers could take some time to try to
:  adapt the CVS HEAD of the GBS
:  
()
:  to their packages and let me (and this list, I guess) know what changes
:  needed to be made, we could try to extract common patterns and include
:  them into the CVS version.

I am not a package maintainer, so EMBI.

Following are two patches, one (inline) for review (ignoring
changes in whitespace) and one (attached) for easy application
(``patch 
* templates/generic-build-script: Allow multiple arguments.
(ispatch) New function and argument.

Buzz.

BTW:
2004-02-18  Yaakov Selkowitz 

Re: Generic build script instructions

[Bas van Gompel]

At 05:26 18-6-04, I wrote:
: Following are two patches, one (inline) for review (ignoring
: changes in whitespace) and one (attached) for easy application
: (``patch 

gbs-loop-ispatch.patch
Description: Binary data
Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   //   really is |   and false bits entirely.| post for
  ) |  |  //a 72 by 4 +---+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."| me. 4^re

RE: openjade needed (was: Re: [ITP] gtk-doc)

[Billinghurst, David (CALCRTS)]

> Oh no, it requires openjade..
> 
> Is there someone out there who is able to build the current version of
> openjade / opensp.  
>
> Gerrit

There is  http://www.flett.org/archives/2004/06/09/10.49.58/