>> If we link with Apple libraries, we also need to heed the licensing
>> conditions of the Apple libraries. Do they stand for this?
>
> I gather Apple licenses have changed over time. Possibly older
> versions of their software were better-aligned with GNU
> expectations. I expect this answe
> The lilypond-devel version [of MacPorts] lists gcc8 as a library
> dependency,
This is because lilypond can only be compiled with gcc and not with
clang, contrary to most other software of MacPorts. The compiler
whitelist of the `lilypond-devel' Portfile starts with gcc8; however,
it will com
>> The lilypond-devel version [of MacPorts] lists gcc8 as a library
>> dependency,
>
> This is because lilypond can only be compiled with gcc and not with
> clang, contrary to most other software of MacPorts. The compiler
> whitelist of the `lilypond-devel' Portfile starts with gcc8;
> however,
Thanks for testing it!
> I made a standalone version using 'port mdmg lilypond-devel' which
> results in a lilypond-devel-2.19.82_4.dmg, on MacOS 10.13.6, and it
> is working after installing: I moved my /opt/ out of way, and it
> gets installed in a new directory /opt/. It is rather large thoug
>>
>> https://guide.macports.org/chunked/using.binaries.html#using.binaries.binary-packages
>
> Also, the MacPorts does not install any documentation, it seems.
IMHO this wouldn't be a serious problem – it's mainly about easily
getting distributable LilyPond binaries for the Mac. We could even
>> IMHO this wouldn't be a serious problem – it's mainly about easily
>> getting distributable LilyPond binaries for the Mac. We could even
>> re-pack them together with documentation in case this makes sense.
>
> Perhaps it is not there because in a typical autoconf configuration
> one has to ma
> I created a lilypond group, added my gub user to it and the upload
> then went smoothly. I'm now allowing the 2 cron jobs that create
> the website to run. The new build should be visible in an hour or
> so.
Thanks a lot for your efforts!
Werner
___
Attached is an image of the regression suite file
`quote-cue-event-types.ly'. Note that the grace not slash is missing
in the `curDuring' line. I consider this a bug, and I tried to fix
it. However, I wasn't able to locate the proper event which is
responsible for that. Any help is greatly app
Would this be of interest for LilyPond?
https://developers.google.com/season-of-docs/docs/project-ideas
Improving the documentation would certainly be quite valuable. Given
that we use the texinfo format, we could respond to the TeX Users
Group's call for projects (thus CCing Mojca).
Deadl
> I have been working on building a 64-bit macOS (x86_64-apple-darwin)
> release.
Very nice! And thanks for your very detailed e-mail.
> One option for build LilyPond for 64-bit macOS is Homebrew. Building
> LilyPond with Homebrew has been met with partial success, but it is
> unclear whether t
> acciaccatura contains
> \temporary \override Flag.stroke-style = #"grace"
> reverting it at the end.
>
> Per default override/revert is not quoted. You may extend
> quotedCueEventTypes by `Override´ and `Revert´ to get the slashed
> grace.
Aah! Thanks a lot!
> Though, now _all_ override
>> > `Override´ and `Revert´ are not listed in the IR but in
>> > `define-event-classes.scm'.
>>
>> This is something which should be fixed! I had a look how the
>> documentation gets generated, but it is far too much Scheme code
>> for me, alas. Can you perhaps provide a fix?
>
> Tbh, I've no
> my third attempt to make R\fermata work (after
> https://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00069.html
> and
> https://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00079.html)
> seems to be successful:
> https://sourceforge.net/p/testlilyissues/issues/5511/
Great!
> O
>>> One option for build LilyPond for 64-bit macOS is Homebrew.
>>> Building LilyPond with Homebrew has been met with partial success,
>>> but it is unclear whether the ongoing work to make that method
>>> production ready would be worth the effort. My full comments
>>> about working on Homebrew
>> And all users that don't use the two latest releases of MacOS (like
>> me) are out of the game, too.
>>
>> [Note that I'm not a MacOS user at all. For daily work I'm
>> exclusively using GNU/Linux. It's just that I'm interested in
>> providing support even on exotic platforms :-)]
>
> Sinc
>> [...], Homebrew does not support macOS 10.7, [...]
>
> Good to know; I wasn't aware of that. However, won't our existing
> 32-bit Mac build process be sufficient for 10.7?
Yes. But this fact doesn't help in creating 64bit stuff for new MacOS
versions.
Werner
> Hi everyone! In working on 64-bit Mac builds of lilypond, I notice,
> to my surprise, that lilypond and lilypond-devel exist in MacPorts
> for 2.18.2 and 2.19.83 respectively. I'm experimenting with these
> builds (as well as other approaches), but does anyone know anything
> about them?
I'v
> After some time without building lilypond I realized that my
> openSuSE Tumbleweed system had changed enough to be unable to build
> lilypond with my old and proven script. The problem is that some
> required libraries are missing from the g++ command line that should
> produce the lilypond ex
> pkg-config --libs "pangoft2 >= 1.38.0" gives
>
>-lpangoft2-1.0 -lpango-1.0 -lfontconfig -lfreetype
Not for me. I get
-L/usr/local/lib64 -lpangoft2-1.0 -lpango-1.0 \
-lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype
> Weird. Look at /usr/lib64/pkgconfig/pangoft2.pc:
>
>prefix=/us
> I think it is clear that we really need to test for and link against
> the glib-2.0 and gobject-2.0 libraries.
OK. Do you have time to prepare a patch?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailma
> The attached patch allows gub to succeed on openSuSE tumbleweed
> again. Please test on other systems.
Since I have openSUSE also, I can only say thank you :-)
However, I don't see any problems with other platforms since OpenMP is
an optional feature.
Consequently, I suggest to apply this pat
> During building stable/ 2.20 we have to build the Portuguese
> website. As we have no txi-pt.tex in the tex/ directory that will
> fail if there is no installation of texinfo on the host system.
So the `stable' branch should add the file `txi-pt.tex' from upstream,
right?
> Before I write a p
>> So the `stable' branch should add the file `txi-pt.tex' from
>> upstream, right?
>
> Yes. And we need to add the filename to the list of copied files in
> grand-replace.py. See attached patch for stable/2.20.
LGTM, thanks!
Werner
___
lilypon
> Right now, I personally am most worried about getting a usable
> native 64-bit Mac build.
You mean a stand-alone package that can be easily distributed, right?
Since MacPorts does provide a 64bit version with the `lilypond-devel'
package.
Werner
__
>> You mean a stand-alone package that can be easily distributed,
>> right? Since MacPorts does provide a 64bit version with the
>> `lilypond-devel' package.
>
> Yes, thanks for the correction. The easiest way right now will
> probably be with port mdmg, but I want to see if I can do better.
I
>> I think that the resulting bundle size of the `port mdmg' command
>> can be greatly reduced if you improve the lilypond-devel package
>> dependencies (i.e., adjusting the packages needed for building and
>> running). Unfortunately, I don't have enough time right now to do
>> it by myself; addit
>> [...] please send more generic questions to
>>
>> macports-us...@lists.macports.org ;
>>
>> the people on the list are quite responsive usually.
>
> Would it be better to email the “users” list about something like
> setting the compiler as a build-phase dependency? From the
> descriptions onli
> I think some commits in master should be cherry-picked for
> stable/2.20:
>
>git cherry-pick -x \
>6e98e7e7b0d0ac46ba7e54f4b3946228f44fc414 \
>9fb52ef2c93588192842fffa1b115c6f2d360321 \
>f76997b5097f588060f823c4c87f01bac9f2fe50 \
>b0300944e015b5957e50441224699e55c68c3dc3 \
>
> Well, the patch first adds the name of the branch used
This is quite useful.
> When I test a patch in a temporary branch, only a hash with the
> subject is in tree.gittxt. The information which commit was the
> base on which I applied the patch is lost, and the hash of a
> temporary branch no
>> What I would like to see for such branches is the ID of the commit
>> where the branch is rooted in master, this is, if we have
>>
>> o---o---o branch
>> /
>> o---o---o---o---o master
>> 0 1 2 3 4
>>
>> I want to see ID 2 in this file, marked as the ro
[Moving the discussion to lilypond-devel.]
>> A loop?
Attached a new version of the patch, now using a loop.
Werner
diff --git a/lily/horizontal-bracket-engraver.cc b/lily/horizontal-bracket-engraver.cc
index 608af35965..a42268a357 100644
--- a/lily/horizontal-bracket-engraver.cc
+++ b/lil
>> diff --git a/lily/horizontal-bracket-engraver.cc
>> b/lily/horizontal-bracket-engraver.cc
>> index 608af35965..a42268a357 100644
>> --- a/lily/horizontal-bracket-engraver.cc
>> +++ b/lily/horizontal-bracket-engraver.cc
>> @@ -56,10 +56,23 @@ Horizontal_bracket_engraver::listen_note_grouping
>
>>if (d == STOP)
>> {
>>pop_count_++;
>> - if (pop_count_ > bracket_stack_.size ())
>> +
>> + // Since N `L' events create N HorizontalBracket grobs we need (at
>> + // most) N `R' events to finish them. However, at this particular
>> + // moment, a single-mom
>> If someone is going to rewrite the algorithm, the order of events
>> should be obeyed.
>
> For simultaneous events, LilyPond has no order.
Oh. This means that
c'\startGroup\stopGroup
and
c'\stopGroup\startGroup
can't be reliably distinguished?
> That's why one needs to have one phas
Folks,
on a Windows 10 box I downloaded and installed the binary distribution
of 2.19.83, which worked fine; I was able to compile a PDF on the
Windows command line (I think that drag and drop to the lilypond icon
doesn't work, but since my Windows knowledge is too limited I haven't
pursued this
Ten days ago I wrote the following.
> on a Windows 10 box I downloaded and installed the binary
> distribution of 2.19.83, which worked fine; I was able to compile a
> PDF on the Windows command line (I think that drag and drop to the
> lilypond icon doesn't work, but since my Windows knowledge i
>> >> I know wonder whether this problem is
>> >>
>> >> (1) limited to the gs program that comes with lilypond,
>> >> (2) related to the way gub is compiling gs,
>> >> (3) connected to changes in the Windows 10 console,
>> >> (4) or whether this a generic issue with gs itself, probably
>>
>> It seems this is a GUB issue: It doesn't set the proper flag(s) to
>> build gs on windows as a console application. In other words,
>> right now GUB builds `gswin32' and not `gswin32c'. Maybe this is
>> intentional – I'm no expert on the Windows setup of GS.
>
> Intentional or not, it does n
To have both `!' and `\!' (and similar `\foo' command and `foo'
property entries) in the index of the info and PDF version of the NR
it is necessary to tag corresponding entries with `@sortas'
directives[*]
https://sourceforge.net/p/testlilyissues/issues/5551/
https://sourceforge.net/p/testli
V 641)"
subtitle = "Analysis from Gene Biringer's Schenker Text, Ex. 5-27"
enteredby = "Kris Shaffer, Werner Lemberg"
}
setup = { \oneVoice
\override NoteColumn.ignore-collision = ##t }
% Some remarks.
%
% - Number `i' in the comments below gives
> I can't comment on it because I don't know much about Schenker
> graphs. But I could right away use it ;-)
> https://github.com/frescobaldi/frescobaldi/pull/1173#issuecomment-531884243
> (actually this was something I had been hoping for).
:-)
Werner
Dear LilyPonders!
Lukas-Fabian Moser, Urs Liska, and I proudly announce the conference
Music Engraving in the 21st Century
Developments and Perspectives
January 17th – 19th, 2020
Mozarteum Salzburg, Austria
All details – and a Call for Papers – can be found here:
https://www.uni-mo
>> I've invested some time to revise the Schenker diagram, which
>> deteriorated over time.
>
> Related: For the last couple of years, I’ve been [slowly] putting
> together a SchenkerLily framework, which makes so much of this a lot
> easier to code. I’m hoping to release it to OpenLilyLib soon.
> https://sourceforge.net/p/testlilyissues/issues/5554/
Ah, too bad, our e-mails crossed each other. I've reviewed this
almost trivial patch (also running `make doc' of course) and applied
it already.
Werner
___
lilypond-devel mailing list
lilyp
Hello Jonas,
welcome to the list!
> I'm using Lilypond since a few years and would like to start
> contributing.
Excellent!
> Find attached a patch to replace outdated references to
> code.google.com by their SourceForge equivalent.
Thanks, I've applied it to `staging'. Regarding your remar
Folks,
have a look at
https://sourceforge.net/p/testlilyissues/issues//
This is a serious regression.
I've noticed the problem since I'm going to rewrite the Stockhausen
Klavierstück II to fix various issues accumulated over time (and to
make the input look less intimidating).
In the
>> > > I wonder whether James can upload his script to the
>> > > repository...
>> >
>> > I'm 99% certain James doesn't use this shell script.
>>
>> It doesn't work with Source Forge. It was used with Google's
>> Tracker.
>
> in that case I'd propose to delete the script from the repository
> a
>> > in that case I'd propose to delete the script from the repository
>> > and update Documentation/contributor/source-code.itexi
>> > accordingly, see
>> >
>> http://lilypond.org/doc/v2.19/Documentation/contributor/the-patch-review-cycle
>>
>> Can you prepare a patch, please?
>
> As I don't actua
Folks,
some stuff like `subdivideBeams' is only documented in files from
`Documentation/snippets'. However, not a single file in this
directory contains an index entry.
What is the proper way to add index entries to those files? Are they
still synchronized with LSI? I would like to add a bun
>> What is the proper way to add index entries to those files? Are
>> they still synchronized with LSI? I would like to add a bunch of
>> them, for obvious reasons.
>
> I think that they are usually referenced from the main manual, and
> that's where the index entries then are placed. Of cours
> I've recently done some significant bunches of cherry-picking from
> the development branch if anybody had bothered to look at the stable
> branch instead of just complaining,
:-) Thanks for that.
Werner
___
lilypond-devel mailing list
lilypon
>> So, I offered to do the 2->3 port a long time ago but circumstances
>> prevented me from doing so. Would it be constructive if I launched
>> into that aspect?
Yes, definitely.
> I've also started looking into this and used the branch
> dev/knupero/lilypy3devel as a starting point (see also
>
> If I remember correctly, this will be the time that we definitely
> have to retire the PowerPC MacOSX version (it's not clear anybody is
> actually using it, though).
Hmm. Looking into MacPorts, I don't see any restriction for using
python 3.7 on PowerPC. It seems that OS X 10.4 and 10.5 are
>> `git add -p' is your friend to do that conveniently.
>
> Sure, that is the usual suggestion. But I'm not sure if that is
> really helpful here because none of these changes will do anything
> on its own.
What do you mean with `none will do anything on its own'?
> So my question is whether th
>> Well, I prefer a series of patches instead of a single patch.
>
> Ok, I'll split the third one. My concern was that a single part of
> the series won't bring any benefit on its own. So for example only
> changing the division operator will not make musicxml2ly work with
> Python 3.
In case
> [...] I've split the third patch ("Fix musicxml2ly with Python 3")
> into four smaller logical groups. I don't really mind which version
> is applied, the outcome is the same.
LGTM, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@
> I've also attached an image of rendering the old code (as present in
> the git) with a lilypond binary from current git.
For reference, here's an image of the original score.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://
>> Here's an updated version of the Stockhausen example, with a lot of
>> added comments to the source code.
>
> Looking at the image, this appears more to the credit of LilyPond
> than Stockhausen. I have a hard time imagining a performer bringing
> this to life in a manner justifying the comple
>>I have a hard time imagining a performer bringing this to life in a
>>manner justifying the complexity written into the score.
>
> Why?
>
> It seems you haven"t heard enough of today"s highly qualified and
> dedicated performers ...
It's not about performing this notation. I'm sure this could
> A separate index for the snippets would likely be nice (we have
> categories, though) but I have no idea how we could sensibly manage
> that without messing up the main manual indexing and also the LSR
> coordination.
It's not clear to me what you exactly mean with a `separate index for
snippet
Attached is a diff file that fixes a bunch of incorrect `begin
verbatim' marks in files from the `snippet' directory, causing
omissions in the manual in case the snippet gets included.
Since I'm unsure how to apply this correctly I post it here so that a
knowledgeable person can proceed.
We
>> Since I'm unsure how to apply this correctly I post it here so that
>> a knowledgeable person can proceed.
>
> I'll try fixing those.
Thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
> I've not used my Ubuntu 14 lilypond computer for a while, and I'm
> now trying to help update the example images on the website. If I
> run configure I'm being told my makeinfo is too old - I've got 5.2
> and it requires 6.1. I can't run the GUI updater because it just
> tells me there's an up
> I have the impression it would be nice to add at least one example
> with an alternative notation font to the example page. [...] Maybe
> reuse this "piece"?
> https://github.com/frescobaldi/frescobaldi/pull/1075#issuecomment-529471468
Sounds like a good idea.
> Also, I think section 3.4.4 o
> This does assume however that GUB is updated to at least target at
> least Python 2.6 (for __future__.print_function).
GUB already contains python 2.6 support. However, lilypond isn't set
up to use it. This should be rather simple to do, I think. However,
I haven't gub used since months and
Using the brand-new `MySQL::Dump::Parser::XS' module from CPAN (with
some additions by me :-) I can now access the LSR sqldump directly
(file `lsr--XX-XX.mysqldump.gz' in directory
http://lsr.di.unimi.it/download, updated daily) without using any
MySQL tools, converting it to a readable text d
> Who would cheer/object if I started working on changes to make the
> build output less verbose by default, which would require saying
>
> make VERBOSE=1 …
>
> when you actually wanted to see all the commands?
>
> By “less verbose,” I mean ideally logging one short line per
> interesting
> Attached please find a patch for tuplet slurs, rebased to current
> master. I haven't checked if it still works, so do let me know if
> you get any surprises.
Seems to work fine, thanks.
https://sourceforge.net/p/testlilyissues/issues/5567/
Some comments:
* I notice is that by default th
I've found some LSR inconsistencies. All of the following snippets
are tagged as `docs' and approved but missing in the lilypond git
repository (while present in the LSR bundle).
#1033
(customize-drumpitchnames,-drumstyletable-and-drumpitchtable-in-layout-and-midi.ly)
#1069 (tam-tam-example
> #1033 can be found in the 2.19.83-snippets, but not in master. No
> clue.
> #1069 was approved Thursday or Friday, can't be in the source until
> someone does a lsr-import
> #1071 same as for #1069
OK. Thanks for checking.
> #1083 title corrected, no clue why it's missing in maste
> lately I've been playing with gub, partly to get python3
> packaged. Upon inspection, it seems some targets are broken and some
> are ... a bit out-of-date:
>
> darwin-ppc: Support for applications targeting PowerPC was removed
> in Darwin 11.0 / Mac OS X 10.7, released in 2011.
>
> darwin-x86:
>> That doesn't mean there aren’t people using PowerPC macs. I don't
>> think there is a reason to eliminate this target.
>
> When we complete transition to Python 3, I don't think there is a
> working port.
Why do you think that? MacPorts provides Python 3 for all supported
platforms, includi
>> I don't see a corrected title in today's sqldump file. [And in the
>> text body the word is written incorrectly, too.]
>
> Maybe I forgot to actually _store_ it :(( Hopefully it'll works now.
It does, thanks!
>> Another minor issue: There are some snippets that have a full stop
>> at the end
> I did have to make one change to the Portfile for lilypond-devel. I
> added macports-gcc-9 at the top of the compiler.fallback-append
> list, because MacPorts was mistakenly trying and failing to build
> gcc8 as a dependency.
Please send me a patch so that I can add it to the Portfile.
We
> A problem with the [MacPorts] lilypond-devel package is that it
> listed all dependencies for the build as required for the installer,
> including GCC, making it very large, so it should be slimmed down.
This is not correct any more, I think. See
https://lists.gnu.org/archive/html/lilypond-
>>> A problem with the [MacPorts] lilypond-devel package is that it
>>> listed all dependencies for the build as required for the
>>> installer, including GCC, making it very large, so it should be
>>> slimmed down.
>>
>> This is not correct any more, I think. See
>>
>> https://lists.gnu.org/ar
>> Well, right now you have to build MacPorts from source on MacOS
>> 10.15 – I guess this takes almost a day of compilation. (I don't
>> have such an OS, by the way).
>
> The link I gave has an installer for MacOS 10.15, and it works. :-)
>https://www.macports.org/install.php
This is irrel
> Done.
Thanks!
>> http://lsr.di.unimi.it/LSR/Item?id=857
>
> Done.
>
> Though the title contains backslashes, thus it's not searchable in
> LSR. Not sure what to do!?
Hmm. I just entered `\mark' in the LSR search box, and it *does*
return snippets with backslashes in the title. What exactl
> gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build
> for me on Thursday.
OK, I misunderstood.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
>> To build a distributable `mpkg', you have to install MacPorts with
>> a *different* prefix (i.e., not `/opt/local') so that it doesn't
>> interfere with the `standard' MacPorts a user might have installed.
>> And for such custom MacPorts installations only building from
>> source works.
>
> I
>> > Though the title contains backslashes, thus it's not searchable
>> > in LSR. Not sure what to do!?
>>
>> Hmm. I just entered `\mark' in the LSR search box, and it *does*
>> return snippets with backslashes in the title. What exactly is the
>> problem?
>
> From here:
>
> https://lsr.di.uni
>>> I think I put it into /usr/local/lilypond or
>>> /usr/local/lilypond-devel. Which location would you prefer?
>>
>> What about `/opt/lilypond’?
>
> The location /usr/local/ is for user installations on BSD systems,
> there is for example /usr/local/texlive, so it seems natural.
Well, I don'
What about `/opt/lilypond’?
>>>
>>> The location /usr/local/ is for user installations on BSD systems,
>>> there is for example /usr/local/texlive, so it seems natural.
>>
>> Well, I don't care enough to argue :-)
>
> Why not? :-) Here are some links:
>
> http://www.pathname.com/fhs/pub/fh
> The standard explicitly says it should not be there, but in
> /opt/. Also, MacPorts is in /opt/local/ but should have been in
> /opt/macports/, as it suggests /opt≮provider>/.
Yes.
> But on the hand, I have never seen anything installing in /opt/
> besides MacPorts on MacOS. And also packages
>> Well, that homebrew occupies `/usr/local' is far from optimal.
>
> Bear in mind usr stands for Unix System Resources (allegededly), not
> user. And as I understood it, /usr is for distro stuff, /usr/local
> is for system-wide stuff that is built locally.
This is the thing: `built locally'. N
>> What dependency?
>
> The port lilypond-devel has been updates now to using gcc9 as a
> build dependency; earlier today, it was gcc8.
Yep.
> But port lilypond does not have any gcc, nor libgcc as library
> dependency. The latter is perhaps required for a standalone
> package.
Why do you thin
> Not directly related, but a consideration this comment reminded me
> of: to make these dylibs as portable as possible they must be built
> using as early of an sdk as possible. While we could choose to
> simply start supporting 64-bit at 10.15 (Catalina) and instruct
> users on 10.14 and below
> BTW, what I’ve done so far is at
> https://github.com/gperciva/gub/pull/69 if anyone wants to take a
> look.
Looks good, thanks (I left one remark).
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listi
>> I still cannot do make-check this morning based on current master.
>
> I have no idea why the problem is only being discussed instead of
> fixed, but I'll revert
>
> commit 911788f173eb58438fc9c850a005638d053b8bba
> Author: Dan Eble
> Date: Thu Oct 17 18:17:44 2019 -0400
>
> Issue 55
> In the past month, I've devoted many hours to testing my
> submissions, but clearly the effort is not achieving the goal.
Don't worry. Some of the problems are very hard to catch and only
show up under certain circumstances.
> I request some help to understand how I can improve my pre-commit
> I will attempt to build gub to reproduce and diagnose this issue.
Thanks!
> If you think my time would be better spent preparing a patch that
> cleanly undoes the 'share' change, I'm open to hearing it.
I second Carl's opinion, namely to fix the issue rather than to
circumvent the problem.
> I installed Ubuntu 19.10 on a spare computer, installed some
> necessary packages, cloned https://github.com/gperciva/gub.git, and
> ran "time make -j7 PLATFORMS=‘linux-64’ lilypond". This got as far
> as package linux-64::lilypond, stage pkg_install, and then exited
> with error 2. The last l
>> [...] because the `share' tree present in
>>
>> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/
>>
>> is not created by the script in
>>
>> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/
>
> This fixes the lilypond-test stage:
> https://github.com/gperciva/gub/pull/70
Thanks a lot! What pa
> When I run configure, an error is returned saying that makeinfo is
> too old (5,2). When I run sudo apt-get install texinfo, I'm told
> that I have the latest version. makeinfo --version still returns
> 5.2.
Ouch. `makeinfo` is part of texinfo. Version 5.2 was published
September 2013!
Th
As the title says: A complete gub build succeeds again on my GNU/Linux
openSUSE platform if I apply
https://github.com/gperciva/gub/pull/70
to gub's master branch.
Werner
>> Now that Dan has made default make commands 'terser' I am noticing
>> while building our fonts that I see quite a few 'errors' that look
>> like this:
>>
>> Internal Error (overlap) in clefs.petrucci.c5_change:
>> Winding number did not return to 0 when x=25.9951
>> Internal Error (overlap)
>> It's not a regression, right.
>
> My first probably-not-very-correct thing to do next was check out
> stable/2.18 and make LP from there (on the same system am building
> latest master on) and search for the same errors. [...]
>
> So is this a regression?
My answer is still no. Our glyph sh
On the TeXLive mailing list, Norbert Preining , one
of the maintainers of TeXLive posted the following today.
With the end of 2019, Python2 will be deprecated and not receive any
security updates. Most distributions will throw out Python2
completely. (Don't ask me about my opinion on the
>> This package is written by Urs Liska , who is
>> quite busy these days. In case you have experience with Python 2
>> to 3 conversion, please help produce a new version!
>
> Should it still be backwards compatible with Python 2.7 if possible or
> is it ok to drop Python2 backwards compatibili
>> There is git-fsck .
>>
>
> [dev@lilydev:lilypond-git]$ git fsck
> Segmentation faultrectories: 45% (116/256)
Ouch. I've never experienced such a thing with git. Maybe something
is broken with your installation? Does removing and installing again
help?
Werner
801 - 900 of 3522 matches
Mail list logo
