Jonas Hahnfeld writes:
> Am Dienstag, den 03.03.2020, 20:32 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Dienstag, den 03.03.2020, 17:50 +0100 schrieb David Kastrup:
>> > > Jonas Hahn
on lilypond.org are not reflecting
> 2.19.84 — I've added the documentation for relocation with commit
> 7200d7365be more than a year ago...
>
> This is a serious problem IMHO.
I think that it will cure itself once 2.21.0 is released. We had this
last time round I think.
But the 2.20.0 version is more up to date anyway.
--
David Kastrup
Marnen Laibow-Koser writes:
> On Wed, Mar 4, 2020 at 3:14 PM David Kastrup wrote:
>
>> Werner LEMBERG writes:
>>
>> >> From: Marnen Laibow-Koser
>> >> Date: Wed, 4 Mar 2020 10:35:00 -0500
>> >>
>> >>> The search algorithm is
Marnen Laibow-Koser writes:
> On Wed, Mar 4, 2020 at 3:50 PM David Kastrup wrote:
>
>> Marnen Laibow-Koser writes:
>>
>> > On Wed, Mar 4, 2020 at 3:14 PM David Kastrup wrote:
>> >
>
> [...]
>
>>
>> >> I think that it will cure its
Failed runner: nice make doc -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
That one was actually a segfault. Cannot plausibly come from my patch,
so that is sort-of confusing. I'll retry.
--
David Kastrup
David Kastrup writes:
> pat...@gnu.org writes:
>
>> 23:08:39 (UTC) Begin LilyPond compile, previous commit at
>> 825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>> 23:08:41 Auto packing the repository in background for optimum performance.
>> See "git help gc&qu
k we handle exceptions other than aborting currently) and
Torsten Hämmerle's French beaming stuff. I read through that patch a
few times but did not see any red flags.
To track this down, I'll now enable core dumps and hope that eventually
I'll be able to get a relevant one. I'll stick at current settings for
now.
--
David Kastrup
David Kastrup writes:
> pat...@gnu.org writes:
>
>> 23:42:58 (UTC) Begin LilyPond compile, previous commit at
>> bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:05 Merged staging, now at: bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:06 Succes
David Kastrup writes:
> pat...@gnu.org writes:
>
>> 23:42:58 (UTC) Begin LilyPond compile, previous commit at
>> bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:05 Merged staging, now at: bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>> 23:43:06 Succes
is viable, and prefer using
PKG_CONFIG_PATH .
--
David Kastrup
pkx1...@posteo.net writes:
> David,
>
> On 07/03/2020 00:59, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> pat...@gnu.org writes:
>>>
>>>> 23:42:58 (UTC) Begin LilyPond compile, previous commit at
>>>> bf6f650dbc16cb
David Kastrup writes:
> If I previously did
>
> GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure
> ./config.status --recheck
>
> then the Guile configuration was reused. If I now do
>
> PKG_CONFIG_PATH=/usr/local/tmp/guile-1.8/lib/pkgconfig ./con
unintended version of libguile for a while
(this is likely where my doc-building performance disappeared). James
got tripped up and got it wrong even after I gave the basics of that
problem.
And we are both quite more intimate with LilyPond than the average
system integrator.
Is there anybody w
ent
> stuff differently. This time it slipped my attention that Han-Wen's
> changes w.r.t. pkg-config are not properly described.
In this case, I don't think it is sufficient to add documentation
somewhere (though necessary). People also need to get guided there
instead of stealthily making previously working options do nothing.
--
David Kastrup
usr/local/opt/lib64/pkgconfig
>
> ./autogen.sh \
> --disable-optimising \
> --with-texgyre-dir=... \
> --with-urwotf-dir=...
I just think that for a smooth change not tripping anybody up we
shouldn't be taking too much expertise for granted.
--
David Kastrup
My replies
e, by the way, not adapting any bit of documentation.
For better or worse, deprecation takes work. That's why we have, for
example, convert-ly. That's a user-level feature, but basically
asserting that people able to compile LilyPond have to be able to deal
with anything we throw at them wit
Jonas Hahnfeld writes:
> Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup:
>> David Kastrup <
>> d...@gnu.org
>> > writes:
>>
>> > If I previously did
>> >
>> > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./
unning Patchy frequently on Guile-2.x with core dumps enabled
(set ulimit -c 100 or so).
How often do you run make doc?
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
job
count is constrained due to memory pressure. My laptop has uncommonly
large memory for its overall age and power, so I am not hit worst. The
rough doubling of jobs does not cause me to run into swap space.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup:
>>
>> We are not talking about "keep everything compatible". We are talking
>> about making changes in a manner where they don't trip people up. They
>> way to
Jonas Hahnfeld writes:
> Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup:
>> > > We are not talki
into
lilypond-book, they are stalled within lilypond-book without starting
LilyPond processes until the first lilypond-book has finished.
So the worst memory use is for when one copy of lilypond-book has
finished with its LilyPond part and starts the EPS and PDF processing,
another copy of lilypond-book takes over and starts its LilyPond
processes, and something else happens in another directory.
--
David Kastrup
also a reasonable
candidate for being listed in ./configure --help as well as the
installation instructions.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, den 07.03.2020, 23:20 +0100 schrieb David Kastrup:
>> So assuming GUILE_CONFIG is set, that should be tried in preference
>> to a .pc file, giving a warning (an error would be a nuisance when
>> trying to have a common configuration for
Han-Wen Nienhuys writes:
> On Sun, Mar 8, 2020 at 11:33 AM David Kastrup wrote:
>>
>> Jonas Hahnfeld writes:
>>
>> > Am Samstag, den 07.03.2020, 23:20 +0100 schrieb David Kastrup:
>>
>> >> So assuming GUILE_CONFIG is set, that should be tried in
Jonas Hahnfeld writes:
> Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup:
>> Han-Wen Nienhuys <
>> hanw...@gmail.com
>> > writes:
>> > >
>> > > What about "an error would be a nuisance when trying to have a common
>> &g
Jonas Hahnfeld writes:
> Am Sonntag, den 08.03.2020, 12:34 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup:
>> > > Han-Wen Nienh
s reasonable to assume that it will affect also people outside of
the core team.
This issue is a lot less likely with things other than libguile.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Jonas Hahnfeld writes:
> Am Sonntag, den 08.03.2020, 13:37 +0100 schrieb David Kastrup:
>> At any rate, can we focus on the issue at hand rather than building our
>> strawmen from straw of future harvests? We have a current issue that
>> has already bitten several
n embarrassingly long for us to get there, so it's great that
it's carried on and distributed at a different pace.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 08.03.2020, 15:04 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > How about the attached change? This attempts to locate the .pc file
>> > next to guile-config
retty well. What
problems with doing the actual website may remain, is hard to diagnose
without seeing the actual website. But the worst damage that can happen
to the web site is that the out-of-date size specs disappear temporarily
for links that are currently dead, or at least only visible due to
browser language settings.
--
David Kastrup
Thomas Morley writes:
> Am So., 8. März 2020 um 13:37 Uhr schrieb David Kastrup :
>
>> We have a current issue that
>> has already bitten several not-completely-stupid developers
>
> I'm obviously one of the more stupid ones ;)
> I never understood how to use pk
:space:]]/s/@\(verbatim\)\?include//p" $(1)), \
$(call find-texi,$(f)) \
$(call scan-texi,$(call find-texi,$(f))) \
)
which contains several GNUisms in the sed script. And of course,
nothing but GNU Make will work for the Makefiles.
In short: I have no idea whether GNU sed might be prescribed already or
not.
--
David Kastrup
David Kastrup writes:
> There is in stepmake/stepmake/texinfo-vars.make
>
> # Recursively scan the file $(1) for @include and @verbatiminclude, search for
> # included files within the texinfo include dirs, and return all dependencies.
> scan-texi = \
> $(foreach f, $(shell t
le and uploads it
> to lilypond.org would have the release already on the website *before*
> the GUB build was released.
Would have _something_ already on the website _purporting_ to be the new
version. Whether it actually _is_ the new version depends on timing and
luck.
--
David Kastrup
My
tion status page?
> http://lilypond.org/translated.html
> I’m a bit uncomfortable with the hardcoded date in translations.itexi :-)
I think I was told to run the update script and forgot. I am not sure
where to run it now in order to get the results somewhere.
--
David Kastrup
Valentin Villenave writes:
> On 3/9/20, David Kastrup wrote:
>> I think I was told to run the update script and forgot. I am not sure
>> where to run it now in order to get the results somewhere.
>
> Oh, good. Perhaps we should mention it in the CG’s release-work.itexi
&
Francisco Vila writes:
> El 9/3/20 a las 11:58, David Kastrup escribió:
>> I think I was told to run the update script and forgot. I am not sure
>> where to run it now in order to get the results somewhere.
>
> do
>
> make translation-status
>
> from Documen
translation has to be merged into master and then the website
> regenerated.
I think Francisco is talking about 2.18–2.20 changes, not 2.20–2.22
changes. I really have no clue just when and how the _stable_
documentation makes it into our web pages.
--
David Kastrup
ocations of TeX cause the format files to be a mess.
But that's not really "first time per commit" but "first time per
installation".
--
David Kastrup
o completion.
This got recently changed in master so the stale file was not left
around, and the first failure did not help.
I haven't reported the GUILE_CONFIG/GUILE dependency problem so far.
Probably not related to your problem, though.
--
David Kastrup
producing
> them.
It's worth noting that sharing the engraver does not necessitate sharing
the Grob name (and respective defaults): different grobs can share an
interface, and it is interfaces that an engraver triggers on with regard
to the typesetting. In a similar vein, engravers react to event
classes rather than event types.
So code sharing does not necessitate item sharing.
--
David Kastrup
fails). That should be helpful.
I think this will also get cherry-picked into the stable branch
eventually: makes no sense having wrong sizes there. But it might make
sense getting the links into order in the master branch first.
--
David Kastrup
h?
Rietveld takes OAuth if I understand correctly. While I don't really
know whether that is "sufficiently neutral and uncontroversial", it is
something we have depended on for a long time.
So while it is always good to improve, it doesn't sound like it should
be a complete deal breaker.
--
David Kastrup
Karlin High writes:
> On 3/11/2020 3:04 PM, David Kastrup wrote:
>> Rietveld takes OAuth if I understand correctly. While I don't really
>> know whether that is "sufficiently neutral and uncontroversial", it is
>> something we have depended on for a long ti
ripts actually do the website
creation/build/installation and see whether I can get the size script
inside.
--
David Kastrup
ubdir/')
make[1]: *** [/tmp/lilypond-autobuild/./scripts/build/GNUmakefile:19:
local-test] Error 1
make: *** [/tmp/lilypond-autobuild/GNUmakefile.in:328: test] Error 2
--
David Kastrup
getting
>> created and tested by different people (worksforme, doesn't work for me
>> etc.).
>
> This is exactly why I have been advocating tests based on docker
> containers, so we have a common understanding of when something passes
> tests and when not.
You'
discussions
> about 'worksforme'.
Frankly, I am more sympathetic to "worksforme" discussions among
developers than telling users "worksforme". Where is the point in being
able to tell users that no developer will reproduce their problem?
I'd rather have an error
owed to run LilyPond
natively, get a docker container", and you want to convince developers
to stop using and developing LilyPond natively on their systems because
it will be so much easier to maintain a virtual layer in between?
We have had the LilyDev VM for a long time now. It has seen some use
s (since we are basically bound to blow the
free tiers of anything else with serious testing), our test setup would
need to get seriously more fine-grained.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Wed, Mar 11, 2020 at 11:56 PM David Kastrup wrote:
>>
>>
>> I am not particularly surprised, to be honest: it did seem like the
>> website would employ something other than the online-root/offline-root
>> targets in the normal St
of policy decision, but I
think it makes it more rather than less likely that non-updated code is
tripping LSR users up, and it means that the LSR can only provide
snippets for a single version at one point of time.
--
David Kastrup
Dan Eble writes:
> On Mar 13, 2020, at 09:03, pkx1...@posteo.net wrote:
>>
>> 5703 Run scripts/auxiliar/fixcc.py - David Kastrup
>> https://sourceforge.net/p/testlilyissues/issues/5703
>> http://codereview.appspot.com/549480043
>
> What is the plan for this?
ibguile 1.8.8 is ongoing work,
so it is still recommended to compile LilyPond using libguile 1.8.8
for now.
I would expect that once we find Guilev2 based compilations to be as
dependable and performant as libguile 1.8.8, support for 1.8.8 would be
on the chopping block fast enough that rewriting that paragraph again
rather than removing it would not be necessary.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, den 14.03.2020, 10:50 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Freitag, den 13.03.2020, 23:09 -0600 schrieb Anthony Fok:
>> > > On Fri, Mar 13, 20
Jonas Hahnfeld writes:
> Am Samstag, den 14.03.2020, 11:17 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Samstag, den 14.03.2020, 10:50 +0100 schrieb David Kastrup:
>> > > Jonas Hahn
Jonas Hahnfeld writes:
> Am Samstag, den 14.03.2020, 11:36 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Samstag, den 14.03.2020, 11:17 +0100 schrieb David Kastrup:
>> > > Jonas Hahn
libguile 1.8.8 for now.
More like ambiguous grammar. Intent was
"matching the reliability and performance as compared to LilyPond when
using libguile 1.8.8..."
--
David Kastrup
ain the difference
between
\lyricsmode { \tweak color #red LyricText bla }
and
\lyricsmode { \tweak color #red bla bla }
and using \propertyTweak does not help. Because of this rabbit hole,
\tweak proper has been reduced again to just tweak music expressions.
> Some others are broken as well, or complaining a lot ... step by step ...
--
David Kastrup
> Hints?
(re-)loading internal files seems awfully broken. You could try
switching to module (lily) temporarily but it seems like stacking one
terribly bad idea on another.
--
David Kastrup
most contributors.
Recursive python scripts for writing human-unreadable controlling files
in some build system that is the current fad of the year incompatible
with anything else: who is going to maintain that five years from now?
--
David Kastrup
ant to do in a sh script.
>
> Personally, I'm totally in favor of using python for creating ninja
> files. We have a well-documented, well-maintained, powerful language.
> No different flavors (bash, sh, dash, csh, ksh...).
Regarding the "no different flavors" mantra, you might want to speak
with the people who were (and still are) involved with the Python2 to
Python3 porting effort.
--
David Kastrup
ght now,
> AFAICS,
>> `bash` is optional, and `configure` falls back to whatever is given in
> the
>> `SHELL` environment variable.
>
> Are there still systems that run without bash that we care about?
MacOSX, FreeBSD?
--
David Kastrup
Han-Wen Nienhuys writes:
> On Sun, Mar 15, 2020 at 5:10 PM David Kastrup wrote:
>>
>> hanw...@gmail.com writes:
>>
>> > On 2020/03/14 21:58:52, lemzwerg wrote:
>> >> Just skimming the code: LGTM
>> >>
>> >>
>> > h
Han-Wen Nienhuys writes:
> On Sun, Mar 15, 2020 at 5:03 PM David Kastrup wrote:
>> Makefiles are an established technique well-known to most contributors.
>> Recursive python scripts for writing human-unreadable controlling files
>
> What recursive script are you talking a
or 22 years.
With all due respect, I think characterizing the phases of the project
without your input as mere survival, even if you consider yourself the
sole relevant author for those of the times you were active on it, is
not exactly being a fair characterization of the work of dozens of
contri
. Does it compile with
> LilyPond 2.18? I'd be surprised if it does.
It was prior to 2.18, and it was merely discouraged with 2.18 (in the
course of which all occurences got replaced). There were good reasons
for retiring the syntax for good, but they were not accompanied by a
suitable convert-ly rule.
So basically the complaint is valid.
--
David Kastrup
Marnen Laibow-Koser writes:
> On Wed, Mar 18, 2020 at 6:49 AM David Kastrup wrote:
>
>> Marnen Laibow-Koser writes:
>
> [...]
>
>>
>>
>> > AFAIK this was never proper syntax to begin with. Does it compile with
>> > LilyPond 2.18? I'd
about it. D’oh! So I guess this is under the
> category of “known issues in convert-ly” rather than “broken build”. Sorry
> for the inconvenience!
More like "should have known issues in convert-ly". Analysis of what
decisions have led there just came up yesterday. There likely is going
to be a fix in 2.20.1 but I cannot yet vouch what.
--
David Kastrup
David Kastrup writes:
> Marnen Laibow-Koser writes:
>
>> On Wed, Mar 18, 2020 at 12:18 PM Zone Dremik wrote:
>>
>>> It was quite a few years ago that copied this code sample from the
>>> LilyPond Notation Reference v2.18.2 webpage:
>>>
>>>
ic web files? That might make it more straightforward for
the translations to arrive at a uniform strategy since they then could
just copy what the English version does?
--
David Kastrup
ine.)
Yes, overrides and reverts are properly converted. It's the naked
assignments that seemed too indistinctive to warrant a generic rule for
the conversion (there was one used for one-shot conversion of LilyPond's
own documentation where one can keep the effects in check).
I have it on my to-do list to do something here for the sake of 2.20.1,
but I'm currently laboring on getting 2.21.0 out first: that's also
urgent.
--
David Kastrup
David Kastrup writes:
> Zone Dremik writes:
>
>> Thank you David, Marnen, David and Carl for your excellent
>> suggestions and helpful examples. (I will definitely be using more
>> variables in the future.)
>> For the convert.ly issue, your recommendations inspir
now and will be included in the next
unstable release.
--
David Kastrup
ter's script
now.
Thanks!
--
David Kastrup
xscm commit actually reverts usefully on master.
But maybe not that many patches are in the queue right now.
Ok for me to go ahead, say tomorrow?
--
David Kastrup
ou are suddenly
> talking about fixscm. Is it about cc files, or scm files, or both?
This is about cc files, but scm files are due as well. They will take a
bit more preparation and a separate issue/patch.
--
David Kastrup
think it’s rather
> “building every .o file every time a single .h file is changed” …
It should depend on just what .h file is changed. Some are included by
a whole lot of C files.
--
David Kastrup
Dan Eble writes:
> On Mar 21, 2020, at 11:26, David Kastrup wrote:
>> it got a bit lost in other things, but I think I would want to run
>> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
>> conventions for template arguments but there are com
free expressions (namely quoted lists) and returns the last one which is
(define q "i am Q\n")
This then gets evaluated at run time, defining q .
You probably wanted something like
`(begin (define p ...) (define q ...))
as your body (and return expression) instead.
> (my-macro-old 1 2)
> (my-macro-new 1 2)
> (display x1)
> (display x2)
> (display q)
> (display p)
>
>
> thanks,
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> The website uses scripts that aren't directly checked out from
>> savannah, so you can't directly compromise the webserver through code
>> commits.
>>
>> I can update the scripts.
>
> A
Dan Eble writes:
> On Mar 22, 2020, at 17:04, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> Did you use astyle 2.04 or another version? I built 2.04 from source
> ...
>> 3.1. I am afraid that I may have updated my system since the review,
&
Dan Eble writes:
> On Mar 23, 2020, at 17:10, David Kastrup wrote:
>>
>> Dan Eble writes:
>
>>> As far as I'm concerned, we could just declare 3.1 to be the new
>>> preferred version. I'm not sure whether that would inconvenience
>>> a
ample{R}. Their duration is entered
@example is not an in-text command but rather an environment.
Backing out the respective commit from staging.
All the best.
--
David Kastrup
Francisco Vila writes:
> El 24/3/20 a las 21:58, David Kastrup escribió:
>>> Thanks, I patched it up.
>> Partly. Several download links now contain b'...' visibly.
>>
> Unrelated. I saw this in my local build before the sizes script.
Oh, I didn't ev
be unprecedented, so the cost of implementing such a
policy would be considerably more moderate than if we had to do it from
scratch.
--
David Kastrup
ted action (like when other
important changes depend on it).
But doing so without updating issue status and without giving some
feedback with regard to the reasons for urgency is, if nothing else,
quite impolite towards the people who have to pick up the bits
afterwards and sort them into place.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Wed, Mar 25, 2020 at 8:15 PM David Kastrup wrote:
>> >> We don't push until the status becomes Push. Countdown is a last
>> >> chance for reviewers to comment.
>> >
>> > Sorry, I saw Valentin had pushed his, so I
Han-Wen Nienhuys writes:
> On Wed, Mar 25, 2020 at 4:12 PM David Kastrup wrote:
>>
>> hanw...@gmail.com writes:
>>
>> > Reviewers: lemzwerg,
>> >
>> > Message:
>> > On 2020/03/22 05:51:34, lemzwerg wrote:
>> >> LGT
; IOError: ('http error', 401, 'Unauthorized', instance at 0x7f8715613370>)
>
>
> Traceback attached. What am I doing wrong?
The question is rather what git-cl is doing wrong. This is some fallout
from SourceForge changes (and/or our move from Google Code to there)
that nobody has gotten around to get fixed yet.
--
David Kastrup
actually
be able to work with what they find on the web page.
We can release 2.21.0 prior to that, of course, since the web page
updates are (I think) independent from releases.
Thoughts?
--
David Kastrup
Jean-Charles Malahieude writes:
> Le 26/03/2020 à 17:11, David Kastrup a écrit :
>> Because once the big announcements are made, we want people to
>> actually
>> be able to work with what they find on the web page.
>> We can release 2.21.0 prior to that, of course, si
f a holdup?
--
David Kastrup
Jean-Charles Malahieude writes:
> Le 29/03/2020 à 17:54, David Kastrup a écrit :
>> [Repeat message since I got the address of translations wrong]
>> I see that translation-status is in master. The web site is still
>> getting fixed (including MacOSX download links), so
Werner LEMBERG writes:
>> Anybody can think of a holdup?
>
> No holdup, but I would like to see an LSR import to synchronize
> documentation with snippets.
I think that's standard as part of the release procedure?
--
David Kastrup
Dan Eble writes:
> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>
>> Anybody can think of a holdup?
>
> convert-ly is broken:
>
> find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
> Traceback (most recent call last):
> File &q
Dan Eble writes:
> On Mar 29, 2020, at 14:46, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>>>
>>>> Anybody can think of a holdup?
>>>
>>> convert-ly is broken:
Jean-Charles Malahieude writes:
> Le 29/03/2020 à 18:59, David Kastrup a écrit :
>> Jean-Charles Malahieude writes:
>>>
>>> But, please, pick up the po files I mentioned (ca, da, de, eo, es, fr,
>>> it, ja, nl, sv) which are in advance on stable/2.20. As
401 - 500 of 6220 matches
Mail list logo
