|
 Re: Issue 872 in lilypond: Changes split-page has broken images
Le samedi 24 octobre 2009 à 17:13 +0000, codesite-noreply@... a
écrit :
> We don't *have* to discuss it as a tracker issue,
Especially when it's not necessary, as Google Code sends text emails
with horrible indentation, or rather I'm not able to fill Google Code
tracker form in a way to avoid such horrible indentation.
> Maybe those aren't good reasons... I have no objection to keeping such TODO
> items to
> myself in the future, if that's desired.
What about the wiki for this kind of stuff?
> Anyway, for this specific issue: if changes.tely is a non-splitted manual,
> then the
> html page from general/manual.itexi @section Changes will overwrite the
> non-splitted
> version of changes.itely. I figured that the simplest way to fix this
> would be to
> make Changes a split manual, thereby putting changes-one-page.html in the
> main doc
> source output, and also giving us changes/index.html.
How ugly, this gives two almost identical HTML documents
changes-one-page.html and changes/index.html.
> There was also an issue with the xref produced by @rchanges{Top,blah}
> inside general,
> that has to do with the broken html refs that I'm avoiding with that
> disgusting find
> | xargs sed trick.
One purpose of postprocess_html is avoiding messing with make and shell
to do such tricks.
> In general (umm, I mean, "as a summary", not anything to do with
> general.texi), I'd
> like to avoid manual-specific hacks; I like the idea of only having two
> types of
> manuals: general.texi, which goes in the top output dir, and all the other
> manuals,
> which are all treated the same.
There are two distinct documentation targets: online (lilypond.org) and
offline (downloadable docball).
As for the offline target, I don't understand why you want to make
General go at the top output dir: why should the directory structure
match the hierarchy between HTML Info manuals? The only grounds I can
see for doing so would be
- navigating directories/typing URL by hand,
- reading the URL to see where you are because the docs structure is not
obvious from the HTML pages themselves.
I hope we put enough effort into the usability of our docs and new web
site so these grounds are not valid.
As for the online docs, we want
- the website in lilypond.org/web (IIRC you suggested lilypond.org,
which changes nothing to the issue)
- the docs in lilypond.org/doc/vX.Y/
Moving HTML output of General one directory up suits none of the two
targets, so it should be abandoned. However, we should generate each
output of General twice, removing for the offline target the download
page and other pages that make sense only for the online web site; I'm
willing to take over this, but not for the to-be-dead build system.
> Long-term, I think it would be nice to have the older Changes in the same
> document,
> but I haven't thought through all the issues involved in doing this.
> (namely, what
> happens if the syntax changes from 1.4 to 1.8, then again from 1.8 to 2.13
> -- how do
> we generate the picture for the changes-1.8 page?)
Let's not have a headache for this :-)
> Now that I think about it some more, I'm leaning towards abandoning the
> idea entirely.
I second this. It's (and it should be with the new web site) easy to
see changes for each new stable branch from the page Documentation from
the web site.
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Le lundi 26 octobre 2009 à 12:38 +0100, John Mandereau a écrit :
> Moving HTML output of General one directory up
For completeness, let's keep in mind that this structure won't work for
online docs, because HTTP content negotiation would cause a conflict in
between "manual.html" and "manual/" in the resolution of "manual".
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Mon, Oct 26, 2009 at 12:38:46PM +0100, John Mandereau wrote:
> Le samedi 24 octobre 2009 à 17:13 +0000, codesite-noreply@... a
> écrit :
> > Maybe those aren't good reasons... I have no objection to keeping such TODO
> > items to
> > myself in the future, if that's desired.
>
> What about the wiki for this kind of stuff?
I think that having multiple "issue" lists would be a mistake. I
really think that as long as they're not tagged as type-defect
(and I'm pretty certain I gave this one type-other), there's no
problem using the google tracker.
I agree that discussing it there is silly, but the simple "here is
a task" message is fine.
> > Anyway, for this specific issue: if changes.tely is a non-splitted manual,
> > then the
> > html page from general/manual.itexi @section Changes will overwrite the
> > non-splitted
> > version of changes.itely. I figured that the simplest way to fix this
> > would be to
> > make Changes a split manual, thereby putting changes-one-page.html in the
> > main doc
> > source output, and also giving us changes/index.html.
>
> How ugly, this gives two almost identical HTML documents
> changes-one-page.html and changes/index.html.
Yes.
> > There was also an issue with the xref produced by @rchanges{Top,blah}
> > inside general,
> > that has to do with the broken html refs that I'm avoiding with that
> > disgusting find
> > | xargs sed trick.
>
> One purpose of postprocess_html is avoiding messing with make and shell
> to do such tricks.
Oh, ok. BTW, what's the difference between python/auxiliar/ and
scripts/build/ ?
> > In general (umm, I mean, "as a summary", not anything to do with
> > general.texi), I'd
> > like to avoid manual-specific hacks; I like the idea of only having two
> > types of
> > manuals: general.texi, which goes in the top output dir, and all the other
> > manuals,
> > which are all treated the same.
>
> There are two distinct documentation targets: online (lilypond.org) and
> offline (downloadable docball).
>
> As for the offline target, I don't understand why you want to make
> General go at the top output dir: why should the directory structure
> match the hierarchy between HTML Info manuals?
I've never understood the online/offline distinction. My sole
knowledge comes from "go to top dir. type make doc. look in
out-www/offline-root/".
> The only grounds I can
> see for doing so would be
> - navigating directories/typing URL by hand,
> - reading the URL to see where you are because the docs structure is not
> obvious from the HTML pages themselves.
>
> I hope we put enough effort into the usability of our docs and new web
> site so these grounds are not valid.
Yes, but it would also be nice if the links (if people posted in
the mailist, for example) weren't long. For example, I'd really
like it if bug maintainers could say
"Sorry, please construct a tiny example as described on
lilypond.org/bugs.html
"
> Moving HTML output of General one directory up suits none of the two
> targets, so it should be abandoned. However, we should generate each
> output of General twice, removing for the offline target the download
> page and other pages that make sense only for the online web site; I'm
> willing to take over this, but not for the to-be-dead build system.
I'm more than willing to have you take over it. As you know, I
quite dislike hacking the build system; I only did it because I
wanted to resolve all (?) broken links for 2.13.6, and nobody else
was touching the build system.
(I _think_ I've resolved them all, and I've checked with make
xref-check, but I haven't tested it with any other tool)
What's the timeframe of the new build system? In particular, is
the January deadline still relevant? How much math work are you
doing already? What's the copyright status of your work once you
officially become a student? How many gorgeous Italian girls have
you met so far? Does Italian wine have a higher alcohol content
than French wine?
(you don't need to answer all those questions; just take them into
account when answering the first one :)
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Hi guys,
I forgot to reply to -devel too, so I include at least all of Graham's
reply.
Le mardi 03 novembre 2009 à 19:21 +0000, Graham Percival a écrit :
> On Fri, Oct 30, 2009 at 07:18:50PM +0100, John Mandereau wrote:
> > The problem is, we might end up creating many issues for trivial
> > building problems, which would surely clutter issues with LilyPond
> > programs, and in our current situation for a build system that may die
> > soon.
>
> I still don't see the problem. Searching for Type-Defect or
> Type-Enhancement (or just "label:not-maintainability") is easy
> enough. I agree that we don't want many issues for trivial
> building problems, but I think we can rely on developers to use
> their own judgement as to what's trivial or not.
>
> Evidently this issue was "too trivial", so I'll bear that in mind
> when considering future additions.
Ah, thanks :-) Before raising such an issue in the future, may I
suggest you bug me with CC to -devel? I mean, I'm not expecting you to
master all of postprocess_html.py and other stuff like this, you have
much more important things to do.
> Why not? I mean, they're called "issues" and not "bugs". We even
> have labels for Type-Other and maintainability.
You're right.
> If there's a strong argument against using the Issue tracker for
> all sorts of development issues, I don't mind reserving it for
> purely bugs... but then how should we keep track of problems in
> GUB, the build system, translation infrastructure, etc?
On the wiki ;-) I have no special strong argument, the little argument
I have is that comments on Google Code issues are turned into emails
with horrible indentation.
> > Speaking of, doesn't ROADMAP already say this?
>
> Oops. I never look at that file. I guess I should include it in
> the CG.
Agreed.
> It explains that there's "special processing, so it can be used on
> a website with content negotiation for automatic language
> selection", but it's not clear to me why we don't make *all* the
> HTML docs "online".
Why do you mean by "making *all* the HTML docs online"?
Are you aware that we do need an offline and a online target as long as
the website uses the automatic language selection we currently have and
we want to distribute a docball? Or do you mean we should always build
both offline and online targets?
> If it adds less than 10 minutes to the total
> processing time, I'd say go for it.
It mostly depends on the speed of your hard disk and the amount of
output HTML files that are still in the cache in RAM.
> But if the lilypond docs place bugs.html under general/bugs.html,
> then we need to do extra work to strip that out.
We'll need such extra work anyway for the online target () if we keep a
directory scheme like
web/
doc/vx.y
or
/ (website)
/doc/vx.y
I don't suggest putting both the website and docs in the same directory,
as this would break a few more links (this is easily fixed
with .htaccess-like stuff, as you pointed out below), and more
importantly this would add a discrepancy between URLs of the last stable
docs -- e.g. /(web/)notation/ -- and URLs of doc for other branches --
e.g. /doc/vx.y/notation.
> > I guess there will be no particular difficulty doing
> > so, but this might break more old pages URLs than putting the new
> > website in web/.
>
> We have url forwarding (or whatever the technical name is) in
> .htaccess, so this shouldn't be a problem.
Sure, agreed.
> > I've done few math work and much bureaucratic work, but this should
> > change in November. A waf-based build system could be developed much
> > quicker (more than twice faster) with two people on it; we'd have been
> > two on switching to SCons if I accepted to switch to this build system,
> > but because of its slowness I don't want to go for it. As I'm alone to
> > work on it, my motivation for this is down too easily to enable me
> > giving any timeframe.
>
> In that case, I think I'll keep on muddling with the old build
> system when necessary.
I frankly don't recommend you to spend time on it, OTOH I concede that
it's sometimes necessary :-(
> I mean, we could try asking for volunteers
> to help you, but this stuff is probably sufficiently technical
> that any random volunteers from -user would slow you down rather
> than help.
Exactly.
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Tue, Nov 03, 2009 at 08:52:30PM +0100, John Mandereau wrote:
> Le mardi 03 novembre 2009 à 19:21 +0000, Graham Percival a écrit :
> > Evidently this issue was "too trivial", so I'll bear that in mind
> > when considering future additions.
>
> Ah, thanks :-) Before raising such an issue in the future, may I
> suggest you bug me with CC to -devel?
Sure! At the time, I thought you were completely engrossed in
sorting out your move, and I didn't want to bother you.
> I mean, I'm not expecting you to
> master all of postprocess_html.py and other stuff like this, you have
> much more important things to do.
Yes and no. My stated aim is that my job is to let everybody else
do their jobs. If the doc people (kind-of not counting myself)
want new manuals, I'll do that. If the font people want updated
packages in GUB, I'll do that. For that matter, if anybody wants
releases, I'll do that.
If somebody else is willing to poke around in postprocess_html.py,
I will gladly not attempt to learn what's happening... but if
nobody else is doing it, I'll buckle down and figure it out.
> > If there's a strong argument against using the Issue tracker for
> > all sorts of development issues, I don't mind reserving it for
> > purely bugs... but then how should we keep track of problems in
> > GUB, the build system, translation infrastructure, etc?
>
> On the wiki ;-) I have no special strong argument, the little argument
> I have is that comments on Google Code issues are turned into emails
> with horrible indentation.
Why don't we just agree that any substantial discussion (more than
2 or 3 sentences) should be on the mailist? Once the discussion
has ended, we can add a link to the archives on the tracker so it
doesn't get lost.
> > It explains that there's "special processing, so it can be used on
> > a website with content negotiation for automatic language
> > selection", but it's not clear to me why we don't make *all* the
> > HTML docs "online".
>
> Why do you mean by "making *all* the HTML docs online"?
> Are you aware that we do need an offline and a online target as long as
> the website uses the automatic language selection we currently have and
> we want to distribute a docball? Or do you mean we should always build
> both offline and online targets?
I'm not aware that we need an offline target. If that's used for
the docball, why not build that from the online target?
This isn't rhetoric; I really honestly do not know what the point
is for having an "offline" doc target. What do we lose if we only
have the "online" doc target?
> > But if the lilypond docs place bugs.html under general/bugs.html,
> > then we need to do extra work to strip that out.
>
> We'll need such extra work anyway for the online target () if we keep a
> directory scheme like
I'm not convinced about this, but let's discuss it again in a few
weeks when it becomes relevant.
> > In that case, I think I'll keep on muddling with the old build
> > system when necessary.
>
> I frankly don't recommend you to spend time on it, OTOH I concede that
> it's sometimes necessary :-(
Well, off the top of my head, the only thing that's left before
declaring the build system side of the new website "finished" is
fixing the image links in changes.tely. So... 15 minutes (?) of
work for you to modify postprocess_html.py, 60 minutes (?) for me
to understand and then modify postprocess_html.py... or 5-10 weeks
to get the new doc build system ready?
At this stage, I really want to be finishing projects and getting
2.14 ready, so I think it makes sense to work on the old build
system.
(I consider postprocess.py part of the build system)
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Le mercredi 04 novembre 2009 à 00:11 +0000, Graham Percival a écrit :
> Sure! At the time, I thought you were completely engrossed in
> sorting out your move, and I didn't want to bother you.
I'm engrossed with many other things, but never mind: I still don't have
time to work on the translations and build system, but at least I have
time to discuss on the lists. BTW the time you don't spend looking at
ROADMAP, the CG and build scripts and thinking to find the answer of
your questions is spent by me to answer the same questions; your time is
as precious as mine, but I likely won't have time to both discuss such
things and work on the new build system.
> Why don't we just agree that any substantial discussion (more than
> 2 or 3 sentences) should be on the mailist? Once the discussion
> has ended, we can add a link to the archives on the tracker so it
> doesn't get lost.
I fully agree.
> I'm not aware that we need an offline target. If that's used for
> the docball, why not build that from the online target?
Because .html (and maybe .png) suffixes are stripped in URLs in the
online target, which completely breaks navigation on a local media
(unless you have a properly set up HTTP sever running on your box :-P)
> Well, off the top of my head, the only thing that's left before
> declaring the build system side of the new website "finished" is
> fixing the image links in changes.tely. So... 15 minutes (?) of
> work for you to modify postprocess_html.py, 60 minutes (?) for me
> to understand and then modify postprocess_html.py... or 5-10 weeks
> to get the new doc build system ready?
I *cannot* estimate the completion of the new doc build system, except
that it can be anything between 3 weeks and 3 months. It depends on how
much email I have to keep with translations and the build system, how
much time I have to spend in bureaucratic details for my PhD...
> At this stage, I really want to be finishing projects and getting
> 2.14 ready, so I think it makes sense to work on the old build
> system.
> (I consider postprocess.py part of the build system)
postprocess_html.py will survive to the switch to another build system.
Please also remember 3-4 weeks for translating the website, when it is
ready; therefore I'm not sure it's worth hacking makefiles too much. I
mean, it's not necessary that translated website builds perfectly for
starting translating it, only having some HTML output is needed for the
translators and us to check the output.
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Le mercredi 04 novembre 2009 à 09:23 +0100, Jan Nieuwenhuizen a écrit :
> Op dinsdag 03-11-2009 om 19:21 uur [tijdzone +0000], schreef Graham
> Percival:
> > On Fri, Oct 30, 2009 at 07:18:50PM +0100, John Mandereau wrote:
> > > I agree with this, but I will not responsible for bringing it to
> > > reality: putting the main website at the root of lilypond.org will be up
> > > to you and Jan.
>
> I'm not too fond of that idea. Also, it would be nice if the name
> of the page were web/bugs [with .LANG.html negotiation] rather
> than web/Bugs.
Agreed, but who wants to hack Texi2HTML init files and/or
postprocess_html.py? I mean, we have so many other problems that we
probably don't want to hack this right now.
> >> I guess there will be no particular difficulty doing
> >> so, but this might break more old pages URLs than putting the new
> >> website in web/.
>
> Why don't we rename general to web [even a more accurate name?]
Because "general" won't show up in the website (splitted HTML output),
and it's perfectly accurate for offline docs IMO; for PDF and
one-big-page output, well, Graham and me are probably tired by renaming
directories :-)
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Op woensdag 04-11-2009 om 10:19 uur [tijdzone +0100], schreef John
Mandereau:
> Le mercredi 04 novembre 2009 à 09:23 +0100, Jan Nieuwenhuizen a écrit :
> > Op dinsdag 03-11-2009 om 19:21 uur [tijdzone +0000], schreef Graham
> > Percival:
> > > On Fri, Oct 30, 2009 at 07:18:50PM +0100, John Mandereau wrote:
> > I'm not too fond of that idea. Also, it would be nice if the name
> > of the page were web/bugs [with .LANG.html negotiation] rather
> > than web/Bugs.
>
> Agreed, but who wants to hack Texi2HTML init files and/or
> postprocess_html.py? I mean, we have so many other problems that we
> probably don't want to hack this right now.
I don't think so, as texinfo wants names to be normalized. We can
simply lowercase our short/file name entries in node menus that
we use in general.*, I think. See attached
> Because "general" won't show up in the website (splitted HTML output),
> and it's perfectly accurate for offline docs IMO; for PDF and
> one-big-page output, well, Graham and me are probably tired by renaming
> directories :-)
Yeah, laugh. That's the reason why hardcoding names all over
the place is so bad. Renaming a directory should be a simple
mv and M-x tags-search-replace.
I'd rather rename directories once, in the source ball, than
on the website. We'll be stuck with /general fixups for
eons to come.
Greetings,
Jan.
--
Jan Nieuwenhuizen < janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org[0001-Downcase-most-toplevel-nodes.-Nicer-more-stable-html.patch]
From 01139e35b942e36a106d50c15d73b0aefdd1b656 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@...>
Date: Wed, 4 Nov 2009 12:07:15 +0100
Subject: [PATCH] Downcase most toplevel @nodes. Nicer/more stable html file names.
TODO: ./general -> ./web :-)
---
Documentation/general.texi | 8 ++--
Documentation/general/community.itexi | 34 +++++++++++-----------
Documentation/general/download.itexi | 16 +++++-----
Documentation/general/introduction.itexi | 34 +++++++++++-----------
Documentation/general/manuals.itexi | 46 +++++++++++++++---------------
5 files changed, 69 insertions(+), 69 deletions(-)
diff --git a/Documentation/general.texi b/Documentation/general.texi
index b71c4de..3b73652 100644
--- a/Documentation/general.texi
+++ b/Documentation/general.texi
@@ -138,10 +138,10 @@ Read more in our @ref{Introduction}!
@divClass{hide}
@menu
-* Introduction:: Start here to creating sheet music.
-* Download:: Get LilyPond.
-* Manuals:: Read The Fine Manuals (RTFM).
-* Community:: Contact other users.
+* introduction:: Start here to creating sheet music.
+* download:: Get LilyPond.
+* manuals:: Read The Fine Manuals (RTFM).
+* community:: Contact other users.
@end menu
@divEnd
diff --git a/Documentation/general/community.itexi b/Documentation/general/community.itexi
index b382196..e4ce434 100644
--- a/Documentation/general/community.itexi
+++ b/Documentation/general/community.itexi
@@ -8,7 +8,7 @@
@include general/basic-authors.itexi
-@node Community
+@node community
@unnumbered Community
@@ -64,19 +64,19 @@ discussing LilyPond.
@divClass{hide}
@menu
-* Contact::
-* Tiny examples::
-* Bug reports::
-* Help us::
-* Development::
-* Authors::
-* Publications::
-* Old news::
+* contact::
+* tiny examples::
+* bug reports::
+* help us::
+* development::
+* authors::
+* publications::
+* old news::
@end menu
@divEnd
-@node Contact
+@node contact
@unnumberedsec Contact
@@ -220,7 +220,7 @@ guidelines for @ref{Bug reports}.}
-@node Tiny examples
+@node tiny examples
@unnumberedsec Tiny examples
@divClass{column-center-top}
@@ -293,7 +293,7 @@ is about those particular commands.
-@node Bug reports
+@node bug reports
@unnumberedsec Bug reports
@divClass{column-center-top}
@@ -374,7 +374,7 @@ account.
@divEnd
-@node Help us
+@node help us
@unnumberedsec Help us
TODO: talk about the Frogs, document suggestions, encourage getting
@@ -382,7 +382,7 @@ involved, etc. Maybe mention GLISS and GOP, if those are happening
in the near future.
-@node Development
+@node development
@unnumberedsec Development
@@ -546,7 +546,7 @@ Comparisons beteween versions.
@divEnd
@divEnd
-@node Authors
+@node authors
@unnumberedsec Authors
@help{Under construction; this is not an accurate list!}
@@ -605,7 +605,7 @@ http://lilypond.org/web/switch/
-@node Publications
+@node publications
@unnumberedsec Publications
@divClass{column-center-top}
@@ -735,7 +735,7 @@ issue CMS06.
@divEnd
-@node Old news
+@node old news
@unnumberedsec Old news
@include general/news.itexi
diff --git a/Documentation/general/download.itexi b/Documentation/general/download.itexi
index 76b2dbd..ef41119 100644
--- a/Documentation/general/download.itexi
+++ b/Documentation/general/download.itexi
@@ -6,7 +6,7 @@
version that you are working on. See TRANSLATION for details.
@end ignore
-@node Download
+@node download
@unnumbered Download
@divClass{heading-center}
@@ -102,18 +102,18 @@ acknowledged.
@divClass{hide}
@menu
-* Unix::
+* UNIX::
* MacOS X::
* Windows::
-* Source::
-* Old downloads::
+* source::
+* old downloads::
* GPL::
@end menu
@divEnd
-@node Unix
-@unnumberedsec Unix
+@node UNIX
+@unnumberedsec UNIX
@divClass{column-center-top}
@subheading Generic Packages or Distribution-Specific Packages?
@@ -483,7 +483,7 @@ acknowledged.
-@node Source
+@node source
@unnumberedsec Source
@warning{We @strong{do not} recommend that you attempt to build
@@ -509,7 +509,7 @@ Instructions are listed in @rcontrib{Compiling LilyPond}.
@divEnd
-@node Old downloads
+@node old downloads
@unnumberedsec Old downloads
@divClass{column-center-top}
diff --git a/Documentation/general/introduction.itexi b/Documentation/general/introduction.itexi
index 7008cd2..c0085f1 100644
--- a/Documentation/general/introduction.itexi
+++ b/Documentation/general/introduction.itexi
@@ -6,7 +6,7 @@
version that you are working on. See TRANSLATION for details.
@end ignore
-@node Introduction
+@node introduction
@unnumbered Introduction
@divClass{column-center-top}
@@ -77,20 +77,20 @@ Impress friends and colleagues with sharp sheet music!
@divClass{hide}
@menu
-* Features:: What can LilyPond do?
-* Examples:: I want to see some music!
-* Freedom:: Freedom and the GPL.
-* Background:: Computational aesthetics.
-* Productions:: Real-life use of LilyPond.
-* Testimonials:: What do people say about it?
-* Text input:: You write music as text?!
-* Alternate input:: Other ways of working with LilyPond.
+* features:: What can LilyPond do?
+* examples:: I want to see some music!
+* freedom:: Freedom and the GPL.
+* background:: Computational aesthetics.
+* productions:: Real-life use of LilyPond.
+* testimonials:: What do people say about it?
+* text input:: You write music as text?!
+* alternate input:: Other ways of working with LilyPond.
@end menu
@divEnd
-@node Features
+@node features
@unnumberedsec Features
@help{hoping to delegate this. Desired: an enthusiastic
@@ -200,7 +200,7 @@ already decided to try LilyPond, first read about our
-@node Examples
+@node examples
@unnumberedsec Examples
Lilypond is a powerful and flexible tool for engraving tasks of
@@ -347,7 +347,7 @@ read about our @ref{Text input}.
@divEnd
-@node Freedom
+@node freedom
@unnumberedsec Freedom
@divClass{column-center-top}
@@ -457,7 +457,7 @@ LilyPond, first read about our @ref{Text input}.
@divEnd
-@node Background
+@node background
@unnumberedsec Background
@divClass{column-center-top}
@@ -480,7 +480,7 @@ try LilyPond, first read about our @ref{Text input}.
@divEnd
-@node Productions
+@node productions
@unnumberedsec Productions
@divClass{column-left-top}
@@ -554,7 +554,7 @@ If you've already decided to try LilyPond, first read about our
@divEnd
-@node Testimonials
+@node testimonials
@unnumberedsec Testimonials
@divClass{testimonial-item}
@@ -695,7 +695,7 @@ Read about our @ref{Text input}.
-@node Text input
+@node text input
@unnumberedsec Text input
@c TRANSLATORS: so far it's mostly from
@@ -811,7 +811,7 @@ convinced? Read about easier editing environments in
@divEnd
-@node Alternate input
+@node alternate input
@unnumberedsec Alternate input
@divClass{column-center-top}
diff --git a/Documentation/general/manuals.itexi b/Documentation/general/manuals.itexi
index 1c5c12a..4d5e92f 100644
--- a/Documentation/general/manuals.itexi
+++ b/Documentation/general/manuals.itexi
@@ -6,7 +6,7 @@
version that you are working on. See TRANSLATION for details.
@end ignore
-@node Manuals
+@node manuals
@unnumbered Manuals
@divClass{heading-center}
@@ -113,18 +113,18 @@ License.
@divClass{hide}
@menu
-* Learning:: Learning.
-* Glossary:: Glossary.
-* Essay:: Essay.
-* Notation:: Reference.
-* Usage:: Usage.
-* Snippets:: Snippets.
+* learning:: Learning.
+* glossary:: Glossary.
+* essay:: Essay.
+* notation:: Reference.
+* usage:: Usage.
+* snippets:: Snippets.
* FAQ:: FAQ.
-* Changes:: NEWS.
-* Extend:: Programming.
-* Internals:: Internals.
-* Translated:: Translation.
-* All:: All manuals.
+* changes:: NEWS.
+* extend:: Programming.
+* internals:: Internals.
+* translated:: Translation.
+* all:: All manuals.
* FDL:: Licence.
@end menu
@@ -135,7 +135,7 @@ License.
@c LM 1.1 About the documentation (before this section was
@c removed in July 2009).
-@node Learning
+@node learning
@unnumberedsec Learning
@divClass{column-left-top}
@@ -188,7 +188,7 @@ download as a PDF file.
@divEnd
-@node Glossary
+@node glossary
@unnumberedsec Glossary
@divClass{column-left-top}
@@ -236,7 +236,7 @@ download as a PDF file.
@divEnd
-@node Essay
+@node essay
@unnumberedsec Essay
@divClass{column-left-top}
@@ -286,7 +286,7 @@ download as a PDF file.
@divEnd
-@node Notation
+@node notation
@unnumberedsec Notation
@divClass{column-left-top}
@@ -336,7 +336,7 @@ download as a PDF file.
@divEnd
-@node Usage
+@node usage
@unnumberedsec Usage
@divClass{column-left-top}
@@ -383,7 +383,7 @@ download as a PDF file.
@divEnd
-@node Snippets
+@node snippets
@unnumberedsec Snippets
@divClass{column-left-top}
@@ -479,7 +479,7 @@ This is explained in @rprogram{Why does the syntax change?}.
@divEnd
-@node Changes
+@node changes
@unnumberedsec Changes
@divClass{column-left-top}
@@ -525,7 +525,7 @@ download as a PDF file.
@divEnd
-@node Extend
+@node extend
@unnumberedsec Extend
@divClass{column-left-top}
@@ -570,7 +570,7 @@ download as a PDF file.
@divEnd
-@node Internals
+@node internals
@unnumberedsec Internals
@divClass{column-left-top}
@@ -628,7 +628,7 @@ download as a PDF file.
-@node Translated
+@node translated
@unnumberedsec Translated
@divClass{column-center-bottom}
@@ -641,7 +641,7 @@ TODO: clean up / prettify
@divEnd
-@node All
+@node all
@unnumberedsec All
@divClass{heading-center}
--
1.6.3.3
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Wed, Nov 04, 2009 at 10:12:59AM +0100, John Mandereau wrote:
> Le mercredi 04 novembre 2009 à 00:11 +0000, Graham Percival a écrit :
> > Sure! At the time, I thought you were completely engrossed in
> > sorting out your move, and I didn't want to bother you.
>
> I'm engrossed with many other things, but never mind: I still don't have
> time to work on the translations and build system, but at least I have
> time to discuss on the lists.
Ok, so we've gone full circle. I added an issue to the tracker to
remind myself to tackle it; we discussed it a bit, and now it
remains as an issue for me to tackle. Granted, I now know that I
should dump awkward fixes into postprocess.py rather than the
makefile.
> BTW the time you don't spend looking at
> ROADMAP, the CG and build scripts and thinking to find the answer of
> your questions is spent by me to answer the same questions; your time is
> as precious as mine, but I likely won't have time to both discuss such
> things and work on the new build system.
I believe that I already apologized for this, and said that I
would add it to the CG.
> > I'm not aware that we need an offline target. If that's used for
> > the docball, why not build that from the online target?
>
> Because .html (and maybe .png) suffixes are stripped in URLs in the
> online target, which completely breaks navigation on a local media
Ok, that makes sense.
> > Well, off the top of my head, the only thing that's left before
> > declaring the build system side of the new website "finished" is
> > fixing the image links in changes.tely. So... 15 minutes (?) of
> > work for you to modify postprocess_html.py, 60 minutes (?) for me
> > to understand and then modify postprocess_html.py... or 5-10 weeks
> > to get the new doc build system ready?
>
> I *cannot* estimate the completion of the new doc build system, except
> that it can be anything between 3 weeks and 3 months.
Ok, I'll spend the hour this weekend or next.
> > At this stage, I really want to be finishing projects and getting
> > 2.14 ready, so I think it makes sense to work on the old build
> > system.
>
> Please also remember 3-4 weeks for translating the website, when it is
> ready; therefore I'm not sure it's worth hacking makefiles too much. I
> mean, it's not necessary that translated website builds perfectly for
> starting translating it, only having some HTML output is needed for the
> translators and us to check the output.
Interesting. When I look at index.nl.html on my system, it's
fine. "LilyPond... muzieknotatie voor iedereen" but on
lilypond.org, it's all broken. Hmm... I wonder if GUB is using
texi2html 1.82? I guess I'll check this tomorrow; there has to be
_some_ difference between my netbook and desktop that breaks this.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Wed, Nov 04, 2009 at 12:10:55PM +0100, Jan Nieuwenhuizen wrote:
> Op woensdag 04-11-2009 om 10:19 uur [tijdzone +0100], schreef John
> Mandereau:
> > Agreed, but who wants to hack Texi2HTML init files and/or
> > postprocess_html.py? I mean, we have so many other problems that we
> > probably don't want to hack this right now.
>
> I don't think so, as texinfo wants names to be normalized. We can
> simply lowercase our short/file name entries in node menus that
> we use in general.*, I think. See attached
It seems to work. I had to change all the @ref{} in the text, but
it looks fine now.
> > Because "general" won't show up in the website (splitted HTML output),
> > and it's perfectly accurate for offline docs IMO; for PDF and
> > one-big-page output, well, Graham and me are probably tired by renaming
> > directories :-)
>
> Yeah, laugh. That's the reason why hardcoding names all over
> the place is so bad.
Totally agreed. But right now, let's just say that making the
build system was a learning experience for everybody involved.
(I don't know who started hard-coding dir names, and I don't care)
> Renaming a directory should be a simple
> mv and M-x tags-search-replace.
NB: a simple replace **in the same directory**, no less. Not some
kind of ../stepmake/stepmake/texinfo-targets.make or
../doc-i8n3d-targets.maek
> I'd rather rename directories once, in the source ball, than
> on the website. We'll be stuck with /general fixups for
> eons to come.
Agreed -- but there's no /general dir in the output.
Documentation/GNUmakefile has:
TOPDIR_MANUAL = general
which produces:
Documentation/out-www/index.html
all other manuals produce:
Documentation/out-www/manual-big-page.html
Documentation/out-www/manual/index.html
it also creates
lilypond-general.pdf
lilypond-general.info
lilypond-{manual}.pdf
lilypond-{manual}.info
where {manual} are all the other manuals. There's also a
special lilypond.info which goes directly to the command-line
options in lilypond-usage.info.
I'm open to renaming "general.tely", but nobody could think of a
better name last June or July when we were contemplating such a
change. Note again that "general" does not appear in any html
URLs.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Le mercredi 04 novembre 2009 à 12:10 +0100, Jan Nieuwenhuizen a écrit :
> I don't think so, as texinfo wants names to be normalized.
We already do our custom normalization in extract_texi_filenames.py, so
I'd rather downcase file names than nodes.
> We can
> simply lowercase our short/file name entries in node menus that
> we use in general.*, I think. See attached
This is a wrong approach, because node names should start with a
capital; downcasing all files names is better, and it's harmless, as we
don't rely on file names that differ only by the case.
> Yeah, laugh. That's the reason why hardcoding names all over
> the place is so bad. Renaming a directory should be a simple
> mv and M-x tags-search-replace.
I don't know this technique, why didn't tell you about it 2 years ago
when I started doing this a wrong way? Can tags be files? How to use
them? I read the Emacs manual about tags but didn't see how we could
use them to softcode file names.
> I'd rather rename directories once, in the source ball, than
> on the website.
Sure, but as the website hosts compiled documentation for several
branches and the documentation sources include the website sources, we
can't have exactly the same directory scheme for both the sources and
the output, can we?
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
2009/11/5 John Mandereau < john.mandereau@...>:
> Le mercredi 04 novembre 2009 à 12:10 +0100, Jan Nieuwenhuizen a écrit :
>> We can
>> simply lowercase our short/file name entries in node menus that
>> we use in general.*, I think. See attached
>
> This is a wrong approach, because node names should start with a
> capital;
Is that a firm rule, or just a suggestion?
>> I'd rather rename directories once, in the source ball, than
>> on the website.
>
> Sure, but as the website hosts compiled documentation for several
> branches and the documentation sources include the website sources, we
> can't have exactly the same directory scheme for both the sources and
> the output, can we?
Sure we can, with symlinks. "make doc" would produce out-www/ and
out-www/doc-v2.13/ with a symlink from doc-v2.13/ to doc/. Stuff in
out-www/*.html points to doc/. Or something like that.
I expect to spend the weekend of Nov 14-15 working on that.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Le jeudi 05 novembre 2009 à 00:30 +0000, Graham Percival a écrit :
> It seems to work. I had to change all the @ref{} in the text, but
> it looks fine now.
Barring well-argumented opposition, I'm going to revert this and apply
the patch below, as completely downcasing titles — node names are some
kind of titles, they are used in Info as titles, at least — is really
quite ugly.
> > Renaming a directory should be a simple
> > mv and M-x tags-search-replace.
>
> NB: a simple replace **in the same directory**, no less. Not some
> kind of ../stepmake/stepmake/texinfo-targets.make or
> ../doc-i8n3d-targets.maek
What do you mean?
> Agreed -- but there's no /general dir in the output.
I already pointed out that this scheme doesn't work for online target,
as there is a conflict between MANUAL.html and MANUAL/index.html. I'll
undo the change that bring general.texi output one directory higher,
unless you do so sooner.
> I'm open to renaming "general.tely", but nobody could think of a
> better name last June or July when we were contemplating such a
> change.
We weren't contemplating this at all, we're arguing about technical
issues more important than the name of the website sources.
### BEGIN PATCH ###
diff --git a/Documentation/lilypond-texi2html.init
b/Documentation/lilypond-texi2html.init
index de2283c..f7a1380 100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -215,7 +215,7 @@ sub texinfo_file_name($)
$result = 't_g' . $result;
}
# DONE
- return $result
+ return lc($result)
}
diff --git a/Documentation/web-texi2html.init
b/Documentation/web-texi2html.init
index fb49202..6430a0b 100644
--- a/Documentation/web-texi2html.init
+++ b/Documentation/web-texi2html.init
@@ -229,7 +229,7 @@ sub texinfo_file_name($)
$result = 't_g' . $result;
}
# DONE
- return $result
+ return lc($result)
}
#### END PATCH ####
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Le jeudi 05 novembre 2009 à 18:28 +0000, Graham Percival a écrit :
> Is that a firm rule, or just a suggestion?
Node names are used like titles in Info, so unless if there's a good
reason (e.g. the node name is a program name), it should start with a
capital, shouldn't it?
> Sure we can, with symlinks. "make doc" would produce out-www/ and
> out-www/doc-v2.13/ with a symlink from doc-v2.13/ to doc/. Stuff in
> out-www/*.html points to doc/. Or something like that.
Why not just do this in mirrortree.py/www_post.py/postprocess_html.py
only for online target? We needn't tweak the directory infrastructure
for offline docs.
> I expect to spend the weekend of Nov 14-15 working on that.
I'll do a round trip to France that week-end, so won't be able to
interact in real time. Please submit ideas and/or patches on -devel
first before committing, unless of course you're are aware of more
technical details than me and you have taken care of making the
translations work as well as docs in English; I'm sorry to ask for this,
but your "something like that" above really scares me.
Best,
John
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Thu, Nov 05, 2009 at 07:56:11PM +0100, John Mandereau wrote:
> Le jeudi 05 novembre 2009 à 00:30 +0000, Graham Percival a écrit :
> > It seems to work. I had to change all the @ref{} in the text, but
> > it looks fine now.
>
> Barring well-argumented opposition, I'm going to revert this and apply
> the patch below, as completely downcasing titles — node names are some
> kind of titles, they are used in Info as titles, at least — is really
> quite ugly.
oh, FFS. Your solution is so ridiculously easy. I want to go and
drunk myself unconscious (especially after discovering that the
online doc target is broken in 2.13.7).
... which would be perfectly normal behavior in Glasgow, if only I
drank alcohol. Curses, foiled again!
(yes, please revert the lower-case patches from Jan and me, and
use yours)
> > > Renaming a directory should be a simple
> > > mv and M-x tags-search-replace.
> >
> > NB: a simple replace **in the same directory**, no less. Not some
> > kind of ../stepmake/stepmake/texinfo-targets.make or
> > ../doc-i8n3d-targets.maek
>
> What do you mean?
I'm complaining again about wanting to change something about the
docs, and needing to look in
Documentation/GNUmakefile
make/doc-i8n-blah.make
stepmake/stepmake/texinfo-*.make
scripts/buildscript/*.py
python/auxiliary/*.py
Just ignore me.
> > Agreed -- but there's no /general dir in the output.
>
> I already pointed out that this scheme doesn't work for online target,
> as there is a conflict between MANUAL.html and MANUAL/index.html. I'll
> undo the change that bring general.texi output one directory higher,
> unless you do so sooner.
No. The solution is to move the docs one directory lower:
index.html
learning.html
docs/learning/index.html
(or maybe docs-v2.13, or maybe v2.13... whatever)
I'll make a first pass at this on the weekend, and send a patch
here for discussion.
> > I'm open to renaming "general.tely", but nobody could think of a
> > better name last June or July when we were contemplating such a
> > change.
>
> We weren't contemplating this at all, we're arguing about technical
> issues more important than the name of the website sources.
I thought that Jan was complaining about the "general" name.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Thu, Nov 05, 2009 at 08:13:03PM +0100, John Mandereau wrote:
> Le jeudi 05 novembre 2009 à 18:28 +0000, Graham Percival a écrit :
> > Sure we can, with symlinks. "make doc" would produce out-www/ and
> > out-www/doc-v2.13/ with a symlink from doc-v2.13/ to doc/. Stuff in
> > out-www/*.html points to doc/. Or something like that.
>
> Why not just do this in mirrortree.py/www_post.py/postprocess_html.py
> only for online target? We needn't tweak the directory infrastructure
> for offline docs.
Why maintain two different directory infrastructures? If we have
any relative links (such as from general to the regtests), we'd
need to hard-code different dirs based on whether it was online or
offline.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Op donderdag 05-11-2009 om 22:40 uur [tijdzone +0000], schreef Graham
Percival:
> On Thu, Nov 05, 2009 at 07:56:11PM +0100, John Mandereau wrote:
> > Le jeudi 05 novembre 2009 à 00:30 +0000, Graham Percival a écrit :
> I thought that Jan was complaining about the "general" name.
I thought that it would be easy/implicit to have general/ show up
somewhere in the urls/output-dir, and that by renaming it to
"web" we would have an easy way to keep all web files in
a single toplevel dir while leaving quite some urls
just where they are now [ie, lilypond.org/install] instead
of having to add even more .htaccess junk.
Greetings,
Jan.
--
Jan Nieuwenhuizen < janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Fri, Nov 06, 2009 at 08:24:11AM +0100, Jan Nieuwenhuizen wrote:
> I thought that it would be easy/implicit to have general/ show up
> somewhere in the urls/output-dir, and that by renaming it to
> "web" we would have an easy way to keep all web files in
> a single toplevel dir while leaving quite some urls
> just where they are now [ie, lilypond.org/install] instead
> of having to add even more .htaccess junk.
I wanted to have the nodes in general.texi become the top-level
files, i.e.
@node Download
->
lilypond.org/download.html
(after filename lower-casing)
@node Bug reports
->
lilypond.org/bug-reports.html
however, given all the problems I'm having (after two hours, I
still can't build the docs in a different location than out-www/
), I'm sorely tempted to use this solution. Then we'd end up with
urls like
lilypond.org/web/download.html
lilypond.org/web/bug-reports.html
lilypond.org/learning/index.html
lilypond.org/notation/index.html
which isn't the end of the world.
Granted, we don't want (or do we?) files like lilypond-web.pdf or
lilypond-web.info, but that can be changed easily in the makefile.
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
Op vrijdag 06-11-2009 om 17:44 uur [tijdzone +0000], schreef Graham
Percival:
> On Fri, Nov 06, 2009 at 08:24:11AM +0100, Jan Nieuwenhuizen wrote:
> lilypond.org/download.html
> lilypond.org/bug-reports.html
I would have to think about whether or not to veto this. Han-Wen?
> however, given all the problems I'm having (after two hours, I
> still can't build the docs in a different location than out-www/
> ), I'm sorely tempted to use this solution. Then we'd end up with
> urls like
> lilypond.org/web/download.html
> lilypond.org/web/bug-reports.html
> lilypond.org/learning/index.html
> lilypond.org/notation/index.html
> which isn't the end of the world.
Much better, but I think learning/ and notation/ should be either
inside web/, or inside doc/v2.xx -- whatever they contain.
> Granted, we don't want (or do we?) files like lilypond-web.pdf or
> lilypond-web.info
Why not?
Greetings,
Jan.
--
Jan Nieuwenhuizen < janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
|
Re: Issue 872 in lilypond: Changes split-page has broken images
On Fri, Nov 06, 2009 at 06:54:19PM +0100, Jan Nieuwenhuizen wrote:
> Op vrijdag 06-11-2009 om 17:44 uur [tijdzone +0000], schreef Graham
> Percival:
> > On Fri, Nov 06, 2009 at 08:24:11AM +0100, Jan Nieuwenhuizen wrote:
>
> > lilypond.org/download.html
> > lilypond.org/bug-reports.html
>
> I would have to think about whether or not to veto this. Han-Wen?
What's the reason to keep the /web/ part? I mean, is it something
to do with the way the server is set up?
In terms of the documentation / user experience, I don't think
that having /web/ adds anything; it just makes the URLs four
characters longer.
> > however, given all the problems I'm having (after two hours, I
> > still can't build the docs in a different location than out-www/
> > ), I'm sorely tempted to use this solution. Then we'd end up with
> > urls like
> > lilypond.org/web/download.html
> > lilypond.org/web/bug-reports.html
> > lilypond.org/learning/index.html
> > lilypond.org/notation/index.html
> > which isn't the end of the world.
>
> Much better, but I think learning/ and notation/ should be either
> inside web/, or inside doc/v2.xx -- whatever they contain.
They can't be directly inside web, because that gives us
/web/learning.html
/web/learning/index.html
conflicting with
/web/learning <-- this is used for the language selection thingy
This problem doesn't manifest with the normal "make doc"; it only
occurs in the docs on lilypond.org.
> > Granted, we don't want (or do we?) files like lilypond-web.pdf or
> > lilypond-web.info
>
> Why not?
When somebody opens a zip of all the lilypond pdfs, we want them
to open lilypond-general.pdf (or lilypond-web.pdf ?) to get to the
description of manuals. What name most looks like "start here" ?
I have no particular feelings on this, one way or the other. I
just remember that we asked the question last June or so, and
either nobody gave any strong reasons one way or the other, or
nobody cared.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel
|
signature.asc (204 bytes) 