Re: Another protocol repository merge attempt

[Alan Coopersmith]

On 12/14/17 11:25 PM, Keith Packard wrote:

Given that the fonts we specify have free licenses; is there any problem
with just including them in the repo? That would avoid all font issues
when building the docs.


I can't think of any off hand - unlike including other software, it's not
like we're going to be exposing critical bugs or security holes if they're
kept in sync with upstream on a regular basis.

-alan-
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Another protocol repository merge attempt

[Keith Packard]

Alan Coopersmith  writes:

> Honestly, I think the versions of Java I've used for generating the docs
> just uses fontconfig to find local fonts, but we do ship with a bunch of
> commercially licensed fonts from way back when that should be automatically
> added to those paths.

I'm not surprised that Oracle has AWT configured right; just frustrated
that Debian does not.

The documents specify fonts that I have installed (deja vu), so I'm
reasonably sure it's a local configuration problem. Note that I couldn't
make docbook work in another context either, and resorted to copying the
desired fonts alongside the document and hand-configuring docbook to
find them.

Given that the fonts we specify have free licenses; is there any problem
with just including them in the repo? That would avoid all font issues
when building the docs.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Another protocol repository merge attempt

[Alan Coopersmith]

On 12/14/17 04:21 PM, Keith Packard wrote:

Of course, bugs in the fonts will involve copying new versions into our
repo. I don't have a great solution here. I do suspect the Oracle has
their AWT configured to find local fonts so that the docbook toolchain
works, but that isn't true for me, and relies on having the right fonts
on the build system anyways.


Honestly, I think the versions of Java I've used for generating the docs
just uses fontconfig to find local fonts, but we do ship with a bunch of
commercially licensed fonts from way back when that should be automatically
added to those paths.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Another protocol repository merge attempt

[Keith Packard]

Eric Anholt  writes:

> I like that it's just commits and merges instead of filter-branch.

Yeah, it makes the history really easy to see, and (if we don't move
files), the per-file history easy to track.

> I think it would make more sense if the headers matched the structure they
> are installed into, but that could be a thing we could move later.

That's a good idea. Having the source reflect the installed tree would
be nice.

> Similarly, the Makefile.am is gross, but if it's autogenerated then it's
> also pretty believable and easy to fix up by hand later.

Yes, it's entirely autogenerated with a script (which is in the
repo). I'd suggest cleaning it up as we move files around later on.

One question I have remaining is what to do with the specs -- having
them all mashed into the 'specs' directory is pretty ugly. I guess we
can clean that up in the same manner as cleaning up the header file
locations?

Oh -- I can't build any of the specs correctly; none of the fonts are
selected right. I've fixed that in other projects by actually shipping
the fonts as a part of the documentation source and referencing them
directly from the fop configuration file. This seems kinda messy, but it
results in reliably built documentation, which is something of a
feature.

Of course, bugs in the fonts will involve copying new versions into our
repo. I don't have a great solution here. I do suspect the Oracle has
their AWT configured to find local fonts so that the docbook toolchain
works, but that isn't true for me, and relies on having the right fonts
on the build system anyways.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Another protocol repository merge attempt

[Eric Anholt]

Keith Packard  writes:

> [ Unknown signature status ]
>
> The idea of merging all of our X protocol repositories came up again,
> and Adam Jackson asked if I wanted to wait for this before merging my
> randr lease/non-desktop changes.
>
> Not really? But, I'm still interested in a merge of the protocol
> repositories; we've got way too many, and they're mostly tiny.
>
> Ok, so I gave another run at this, with a slightly different goal. I
> want to avoid renaming files as that makes history tracking a bit harder
> to manage. So, what I did was find all of the filenames which are
> duplicated between repositories. It's a short list:
>
> .gitignore
> AUTHORS
> autogen.sh
> configure.ac
> COPYING
> docbook.am
> Makefile.am
> README
> specs/Makefile.am
> specs/.gitignore
>
> Then I generated some scripts that would merge in a repo, move the
> (potentially) conflicting files to a directory named after the source
> repo and commit that move.
>
> Another script to merge the Makefile.am contents and I've got a
> repository which installs all of the header files at least. It doesn't
> build the docs for anything, and in fact all of the docs are mashed into
> a 'specs' sub-directory
>
> I don't know if this is more or less useful than the earlier plan which
> placed each extension in a sub-directory; I'm good either way, I just
> want to finish this up and get back to more interesting work.
>
> Take a look and let me know what you think.
>
> git clone git://people.freedesktop.org/~keithp/mergeproto
>
> This was less than an hours work; if the consensus is 'yuck', you won't
> hurt my feelings at all.

I like that it's just commits and merges instead of filter-branch.  I
think it would make more sense if the headers matched the structure they
are installed into, but that could be a thing we could move later.
Similarly, the Makefile.am is gross, but if it's autogenerated then it's
also pretty believable and easy to fix up by hand later.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Another protocol repository merge attempt

["Keith Packard"]

The idea of merging all of our X protocol repositories came up again,
and Adam Jackson asked if I wanted to wait for this before merging my
randr lease/non-desktop changes.

Not really? But, I'm still interested in a merge of the protocol
repositories; we've got way too many, and they're mostly tiny.

Ok, so I gave another run at this, with a slightly different goal. I
want to avoid renaming files as that makes history tracking a bit harder
to manage. So, what I did was find all of the filenames which are
duplicated between repositories. It's a short list:

.gitignore
AUTHORS
autogen.sh
configure.ac
COPYING
docbook.am
Makefile.am
README
specs/Makefile.am
specs/.gitignore

Then I generated some scripts that would merge in a repo, move the
(potentially) conflicting files to a directory named after the source
repo and commit that move.

Another script to merge the Makefile.am contents and I've got a
repository which installs all of the header files at least. It doesn't
build the docs for anything, and in fact all of the docs are mashed into
a 'specs' sub-directory

I don't know if this is more or less useful than the earlier plan which
placed each extension in a sub-directory; I'm good either way, I just
want to finish this up and get back to more interesting work.

Take a look and let me know what you think.

git clone git://people.freedesktop.org/~keithp/mergeproto

This was less than an hours work; if the consensus is 'yuck', you won't
hurt my feelings at all.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel