GUB repo
How does one raise issues for the GUB github repo gperciva/gub? It would appear that function has been disabled for that repo. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev 0.3 sha256sum
Oops - the dev user and password is given on github. Andrew On Sun, 16 Dec 2018 at 12:33, Andrew Bernard wrote: > Re hanging VM, I tried downloading the Fedora VM for 0.2 release. It > worked fine. I redownloaded the Debian release for 0.3 and now it works > fine. Given the SHA sum file is wrong and that you can't check the > download, I wonder if the first two downloads were corrupt (although I > very, very rarely see corrupt downloads on my link)? Can we please fix the > SHA sums file? That would be helpful. > > I guessed the password to login. I seem to be in the dark regarding the > documentation for things like this. Where is it located? [Sorry I am so > dull and plodding on this topic.] > > Andrew > > > On Sat, 15 Dec 2018 at 00:15, Andrew Bernard > wrote: > >> To clarify, on W10 host, I can make any 64 bit guestin Virtualbox. In a >> Fedora 29 or Debian 9 guest VM, Virtualbox 5.2 will not show 64 bit machine >> options, despite enabling VT-x/AMD-V in the vm machine settings. >> >> Running lilydev 0.3 Debian just hangs at the UEFI shell prompt, in a >> machine running as a guest on W10. >> >> ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev 0.3 sha256sum
Re hanging VM, I tried downloading the Fedora VM for 0.2 release. It worked fine. I redownloaded the Debian release for 0.3 and now it works fine. Given the SHA sum file is wrong and that you can't check the download, I wonder if the first two downloads were corrupt (although I very, very rarely see corrupt downloads on my link)? Can we please fix the SHA sums file? That would be helpful. I guessed the password to login. I seem to be in the dark regarding the documentation for things like this. Where is it located? [Sorry I am so dull and plodding on this topic.] Andrew On Sat, 15 Dec 2018 at 00:15, Andrew Bernard wrote: > To clarify, on W10 host, I can make any 64 bit guestin Virtualbox. In a > Fedora 29 or Debian 9 guest VM, Virtualbox 5.2 will not show 64 bit machine > options, despite enabling VT-x/AMD-V in the vm machine settings. > > Running lilydev 0.3 Debian just hangs at the UEFI shell prompt, in a > machine running as a guest on W10. > > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB - touch regtests/ignore ???
Am Sa., 15. Dez. 2018 um 21:45 Uhr schrieb Thomas Morley : > I now try > > make lilypond > > We'll see what happens ... It fails very soon with the error already reported here http://lilypond.1069038.n5.nabble.com/What-linux-to-use-for-GUB-builds-make-lilypond-runs-into-KeyError-glibc-doc-when-using-stock-LilyDev-td203227.html And I made the same observations as reported here during 'make bootstrap' http://lilypond.1069038.n5.nabble.com/gub-error-td195268.html In detail: [...] building package: linux-x86::cross/gcc *** Stage: download (cross/gcc, linux-x86) *** Stage: untar (cross/gcc, linux-x86) *** Stage: patch (cross/gcc, linux-x86) *** Stage: autoupdate (cross/gcc, linux-x86) *** Stage: configure (cross/gcc, linux-x86) *** Stage: compile (cross/gcc, linux-x86) *** Stage: install (cross/gcc, linux-x86) *** Stage: package (cross/gcc, linux-x86) *** Stage: clean (cross/gcc, linux-x86) *** Stage: pkg_install (cross/gcc, linux-x86) cross/gcc-core conflicts with cross/gcc-doc removing cross/gcc-core [...] building package: linux-x86::glibc *** Stage: download (glibc, linux-x86) *** Stage: untar (glibc, linux-x86) *** Stage: patch (glibc, linux-x86) *** Stage: autoupdate (glibc, linux-x86) *** Stage: configure (glibc, linux-x86) *** Stage: compile (glibc, linux-x86) *** Stage: install (glibc, linux-x86) *** Stage: package (glibc, linux-x86) *** Stage: clean (glibc, linux-x86) *** Stage: pkg_install (glibc, linux-x86) glibc-core conflicts with glibc-doc removing glibc-core [...] building package: linux-64::cross/gcc *** Stage: download (cross/gcc, linux-64) *** Stage: untar (cross/gcc, linux-64) *** Stage: patch (cross/gcc, linux-64) *** Stage: autoupdate (cross/gcc, linux-64) *** Stage: configure (cross/gcc, linux-64) *** Stage: compile (cross/gcc, linux-64) *** Stage: install (cross/gcc, linux-64) *** Stage: package (cross/gcc, linux-64) *** Stage: clean (cross/gcc, linux-64) *** Stage: pkg_install (cross/gcc, linux-64) cross/gcc-core conflicts with cross/gcc-doc removing cross/gcc-core [...] building package: linux-64::glibc *** Stage: download (glibc, linux-64) *** Stage: untar (glibc, linux-64) *** Stage: patch (glibc, linux-64) *** Stage: autoupdate (glibc, linux-64) *** Stage: configure (glibc, linux-64) *** Stage: compile (glibc, linux-64) *** Stage: install (glibc, linux-64) *** Stage: package (glibc, linux-64) *** Stage: clean (glibc, linux-64) *** Stage: pkg_install (glibc, linux-64) glibc-core conflicts with glibc-doc removing glibc-core [...] building package: linux-ppc::cross/gcc *** Stage: download (cross/gcc, linux-ppc) *** Stage: untar (cross/gcc, linux-ppc) *** Stage: patch (cross/gcc, linux-ppc) *** Stage: autoupdate (cross/gcc, linux-ppc) *** Stage: configure (cross/gcc, linux-ppc) *** Stage: compile (cross/gcc, linux-ppc) *** Stage: install (cross/gcc, linux-ppc) *** Stage: package (cross/gcc, linux-ppc) *** Stage: clean (cross/gcc, linux-ppc) *** Stage: pkg_install (cross/gcc, linux-ppc) cross/gcc-core conflicts with cross/gcc-doc removing cross/gcc-core [...] building package: linux-ppc::glibc *** Stage: download (glibc, linux-ppc) *** Stage: untar (glibc, linux-ppc) *** Stage: patch (glibc, linux-ppc) *** Stage: autoupdate (glibc, linux-ppc) *** Stage: configure (glibc, linux-ppc) *** Stage: compile (glibc, linux-ppc) *** Stage: install (glibc, linux-ppc) *** Stage: package (glibc, linux-ppc) *** Stage: clean (glibc, linux-ppc) *** Stage: pkg_install (glibc, linux-ppc) glibc-core conflicts with glibc-doc removing glibc-core All was tried in an debian-8-OS 32-bit I could try in debian-7 or delete some recent patches from gub locally and test how far I get ... I've no good idea how to proceed, suggestions? Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB - touch regtests/ignore ???
Am Sa., 15. Dez. 2018 um 22:39 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > I tried to join the party about GUB. > > So far I have a successful 'make bootstrap' > > > > As a next step the CG says: > > " > > Once this has completed successfully, you can build the LilyPond > > release package. However, this uses an archived version of the > > regression tests, so it is better to download this first. Download the > > test output from lilypond.org (you will need to replace 2.15.33-1 with > > the latest build): > > > > http://lilypond.org/downloads/binaries/test-output/lilypond-2.15.33-1.test-output.tar.bz2 > > " > > > > Ok, I've done it, for the 2.19.82-regtests. Now the CG recommends: > > " > > Copy the tarball into ‘regtests/’, and tell the build system that you > > have done this: > > > > touch regtests/ignore > > " > > > > ??? > > > > There is no folder in GUB called "regtests", so I've created one and > > inserted the regtest. Trying the next command, i.e.: > > [gub (master) ] $ touch regtests/ignore > > returns: > > touch: cannot touch 'regtests/ignore': no such file or directory > > > > Well, obviously I didn't do things correctly, but what _am_ I supposed to > > do? > > touch just creates the named file as an empty file (if it doesn't exist > yet, otherwise it reads and writes a byte from it in order to update the > modification date). The only way (I am simplifying here since the > symbolic-link related ways are too weird to be relevant here) to have it > clamor "no such file or directory" is when in the _current_ directory > (whatever it may be) there _is_ no directory named "regtests". So > probably your current directory is not what the instructions expect. > > -- > David Kastrup You're right. I just figured it myself. I had created the regtests-folder in the wrong environment. After correction the above command worked. I now try make lilypond We'll see what happens ... Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB - touch regtests/ignore ???
Thomas Morley writes: > I tried to join the party about GUB. > So far I have a successful 'make bootstrap' > > As a next step the CG says: > " > Once this has completed successfully, you can build the LilyPond > release package. However, this uses an archived version of the > regression tests, so it is better to download this first. Download the > test output from lilypond.org (you will need to replace 2.15.33-1 with > the latest build): > > http://lilypond.org/downloads/binaries/test-output/lilypond-2.15.33-1.test-output.tar.bz2 > " > > Ok, I've done it, for the 2.19.82-regtests. Now the CG recommends: > " > Copy the tarball into ‘regtests/’, and tell the build system that you > have done this: > > touch regtests/ignore > " > > ??? > > There is no folder in GUB called "regtests", so I've created one and > inserted the regtest. Trying the next command, i.e.: > [gub (master) ] $ touch regtests/ignore > returns: > touch: cannot touch 'regtests/ignore': no such file or directory > > Well, obviously I didn't do things correctly, but what _am_ I supposed to do? touch just creates the named file as an empty file (if it doesn't exist yet, otherwise it reads and writes a byte from it in order to update the modification date). The only way (I am simplifying here since the symbolic-link related ways are too weird to be relevant here) to have it clamor "no such file or directory" is when in the _current_ directory (whatever it may be) there _is_ no directory named "regtests". So probably your current directory is not what the instructions expect. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB - touch regtests/ignore ???
Hi, I tried to join the party about GUB. So far I have a successful 'make bootstrap' As a next step the CG says: " Once this has completed successfully, you can build the LilyPond release package. However, this uses an archived version of the regression tests, so it is better to download this first. Download the test output from lilypond.org (you will need to replace 2.15.33-1 with the latest build): http://lilypond.org/downloads/binaries/test-output/lilypond-2.15.33-1.test-output.tar.bz2 " Ok, I've done it, for the 2.19.82-regtests. Now the CG recommends: " Copy the tarball into ‘regtests/’, and tell the build system that you have done this: touch regtests/ignore " ??? There is no folder in GUB called "regtests", so I've created one and inserted the regtest. Trying the next command, i.e.: [gub (master) ] $ touch regtests/ignore returns: touch: cannot touch 'regtests/ignore': no such file or directory Well, obviously I didn't do things correctly, but what _am_ I supposed to do? Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for December 15th
Hello, Here is the current patch countdown list. The next countdown will be on the 18th of December, A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: No patches to push at this time. Countdown: 5447 Documentation: add predefined \powerChords command - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5447 http://codereview.appspot.com/344100043 4396 Allow ambitus to appear after clef and key signature - Malte Meyn https://sourceforge.net/p/testlilyissues/issues/4396 http://codereview.appspot.com/348050043 Review: 5448 Documentation: correction in guitar "power chords" tab example - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5448 http://codereview.appspot.com/347030043 New: No new Patches at this time. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ghostscript 9.26 cannot embed CID fonts
I've noticed that gs-9.26 cannot embed CID fonts for the extractpdfmark method. In the method, we defined fonts in PostScript, and use it in PDF. gs-9.26 cannot define the fonts for PDF in PostScript. https://bugs.ghostscript.com/show_bug.cgi?id=700367#c4 To define fonts for ghostscript, root privileges seems to be required on most systems. https://bugs.ghostscript.com/show_bug.cgi?id=700367#c6 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixx #3314 : use superscript for powerChordSymbol (issue 348060043 by v.villen...@gmail.com)
message: On 2018/12/13 12:26:07, Valentin Villenave wrote:
https://codereview.appspot.com/348060043/diff/1/ly/chord-modifiers-init.ly
File ly/chord-modifiers-init.ly (right):
https://codereview.appspot.com/348060043/diff/1/ly/chord-modifiers-init.ly#newcode49
ly/chord-modifiers-init.ly:49: 1-\markup { \super "5" }
On 2018/12/13 11:32:34, dak wrote:
> The way this is arranged currently, it reads jarringly.
I agree, there are a few things that look quite bad: among others,
\partialJazzMusic should be rewritten (and its use is hardly
documented);
there’s a TODO line 534 in chord.itely that should be addressed;
Documentation/included/chord-names-jazz.ly should be entirely
rewritten by
taking advantage of predefined exception lists rather than duplicating
lots of
stuff; "banter-chord-names" isn’t documented anywhere and looks
deprecated
anyway; and there are a bunch of regtests that have been scrapped over
the
years.
Since I don’t know much about all of these and was reluctant to open
that
particular can of worms, I was merely aiming for the low-hanging
fruits here :-)
Putting the change up where it does not look out of place _is_
low-hanging fruit. The reason this was kept the way it was most likely
is because the change looked out of place. Moving it among its kind
would fix that. That's a maintainability issue making the difference
between people daring to touch things and not (as it has proven to be by
the long history of the issue if nothing else). So I don't really get
the "we could do more, so let's do less" argument here.
https://codereview.appspot.com/348060043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4396 (issue 348050043 by lilyp...@maltemeyn.de)
https://codereview.appspot.com/348050043/diff/1/ly/property-init.ly
File ly/property-init.ly (right):
https://codereview.appspot.com/348050043/diff/1/ly/property-init.ly#newcode34
ly/property-init.ly:34: ambitusAfterKeySignature = {
On 2018/12/15 10:40:36, Malte Meyn wrote:
Is this the correct file for such a command? Also, I’m not sure
whether that’s
the best name, it seems very long to me.
This looks like something that might rather warrant an applyContext and
take an argument such as
\ambitusAfter key-signature
\ambitusAfter time-signature
since then it would combine with other changes of break-align-orders.
https://codereview.appspot.com/348050043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4396 (issue 348050043 by lilyp...@maltemeyn.de)
Reviewers: ,
Message:
This doesn’t change LilyPond’s default behaviour (well, except for some
slight horizontal spacing changes; the Ambitus hadn’t been centered
between LeftEdge and Clef). Should it because Ambitus after the
KeySignature makes more sense (looking at accidentals …) for some
people?
https://codereview.appspot.com/348050043/diff/1/ly/property-init.ly
File ly/property-init.ly (right):
https://codereview.appspot.com/348050043/diff/1/ly/property-init.ly#newcode34
ly/property-init.ly:34: ambitusAfterKeySignature = {
Is this the correct file for such a command? Also, I’m not sure whether
that’s the best name, it seems very long to me.
Description:
Issue 4396
This adds the command \ambitusAfterKeySignature to property-init.ly. I’m
not sure whether that’s the correct place, please review.
The command can be placed in a \layout block but not in \layout {
\context { \Staff … } } because it’s an override on Score level.
Maybe it should be a context mod (\with { … }) instead of music
expression?
The suggested change also improves ambitus’s horizontal spacing.
Please review this at https://codereview.appspot.com/348050043/
Affected files (+44, -4 lines):
M ly/property-init.ly
M scm/define-grobs.scm
Index: ly/property-init.ly
diff --git a/ly/property-init.ly b/ly/property-init.ly
index
d1ed3b335a2b624870a99db01c1257a2c31cf1f4..50c722492d229ab72a9fd7027f8f72df0e9233cf
100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -29,6 +29,44 @@ piano styles, which use @samp{GrandStaff} as a context."
)
(*location*))
(make-music 'Music
+%% ambitus
+
+ambitusAfterKeySignature = {
+ \override Score.BreakAlignment.break-align-orders =
+ #'#((left-edge
+ cue-end-clef
+ breathing-sign
+ clef
+ cue-clef
+ staff-bar
+ key-cancellation
+ key-signature
+ ambitus
+ time-signature
+ custos)
+ (left-edge
+ cue-end-clef
+ breathing-sign
+ clef
+ cue-clef
+ staff-bar
+ key-cancellation
+ key-signature
+ ambitus
+ time-signature
+ custos)
+ (left-edge
+ breathing-sign
+ clef
+ key-cancellation
+ key-signature
+ ambitus
+ time-signature
+ staff-bar
+ cue-clef
+ custos))
+}
+
%% arpeggios
% For drawing vertical chord brackets with \arpeggio
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index
7b1ba038283ad6d74ed96c5fae1e93ec0d47af3f..51ae2c37154d7c0137309dc0bf4ee94fe682e34b
100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -110,11 +110,11 @@
(non-musical . #t)
(space-alist . (
(cue-end-clef . (extra-space . 0.5))
-(clef . (extra-space . 0.5))
+(clef . (extra-space . 1.15))
(cue-clef . (extra-space . 0.5))
(key-signature . (extra-space . 0.0))
-(staff-bar . (extra-space . 0.0))
-(time-signature . (extra-space . 0.0))
+(staff-bar . (extra-space . 1.15))
+(time-signature . (extra-space . 1.15))
(first-note . (fixed-space . 0.0
(X-extent . ,ly:axis-group-interface::width)
(Y-extent . ,axis-group-interface::height)
@@ -557,6 +557,7 @@
(non-musical . #t)
(space-alist . ((cue-clef . (extra-space . 2.0))
(staff-bar . (extra-space . 0.7))
+(ambitus . (extra-space . 1.15))
(key-cancellation . (minimum-space . 3.5))
(key-signature . (minimum-space . 3.5))
(time-signature . (minimum-space . 4.2))
@@ -1267,6 +1268,7 @@
(flat-positions . (2 3 4 2 1 2 1))
(sharp-positions . (4 5 4 2 3 2 3))
(space-alist . (
+(ambitus . (extra-space . 1.15))
(time-signature . (extra-space . 1.15))
(staff-bar . (extra-space . 1.1))
(cue-clef . (extra-space . 0.5))
@@ -1341,7 +1343,7 @@
(break-visibility . ,begin-of-line-visible)
(non-musical . #t)
(space-alist . (
-(ambitus . (extra-space . 2.0))
+(ambitus . (extra-space . 1.15))
(breathing-sign . (minimum-space . 0.0))
(cue-end-clef . (extra-space . 0.8))
(clef . (extra-space . 0.8))
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ly: updates to hel-arabic.ly (issue 349810043 by pkxgnugi...@runbox.com)
Thanks for the review Malte https://codereview.appspot.com/349810043/diff/1/ly/hel-arabic.ly File ly/hel-arabic.ly (left): https://codereview.appspot.com/349810043/diff/1/ly/hel-arabic.ly#oldcode73 ly/hel-arabic.ly:73: %% Sajakar: c' d' edb' f' g' ab' b' c'' c'' bb' a' g' f' edb' d' c' On 2018/12/12 08:55:01, Malte Meyn wrote: Is this “never used” in the same way as locrian mode, i. e. only in theory? From Hassan: rast : c d edb f g a bdb c sajkar : c dd edb f g a bdb c rast = #`( (0 . ,NATURAL) (1 . ,NATURAL) (2 . ,SEMI-FLAT) (3 . ,NATURAL) (4 . ,NATURAL) (5 . ,NATURAL) (6 . ,SEMI-FLAT) ) This is rast with the altered note in dd (dis). That's why musicians arabic use rast by altering the note d in dd (dis) %% Sajakar: c dd edb f g a bdb (good) sajkar = #`( (0 . ,NATURAL) (1 . ,SHARP) (2 . ,SEMI-FLAT) (3 . ,NATURAL) (4 . ,NATURAL) (5 . ,NATURAL) (6 . ,SEMI-FLAT) ) it replaces ( an error here in hel-arabic.ly ) (bad ) sajkar = #`( (0 . ,NATURAL) (1 . ,NATURAL) (2 . ,SEMI-FLAT) (3 . ,NATURAL) (4 . ,NATURAL) (5 . ,FLAT) (6 . ,NATURAL) ) https://codereview.appspot.com/349810043/diff/1/ly/hel-arabic.ly#oldcode248 ly/hel-arabic.ly:248: %% Irak: bdb c d edb f g a bdb bb a g f edb d c bdb On 2018/12/12 08:55:01, Malte Meyn wrote: Are these identical to “rast” in the same way ionian is to major? Then I wouldn’t delete them. Maybe simply #(define iraq rast) or iraq = \rast From Hassan: No they arent' identical to rast in the same way ionian to major . in fact rast : c d edb f g a bdb c ( it also includes the note bb (bes) ) irak : bdb c d edb f g a bdb rahatalarouah : bdb c d edb fd g a bdb alboustankar : bdb c d edb f gb a bdb As you see iraq, rahatalarouah and alboustankar contain edb and bdb notes. But the rast key includes edb and bdb. So Arab musicians use the key of rast to write irak, rahatalarouah and alboustankar https://codereview.appspot.com/349810043/diff/1/ly/hel-arabic.ly#oldcode334 ly/hel-arabic.ly:334: major = #`( On 2018/12/12 08:55:01, Malte Meyn wrote: Does hel-arabic.ly *replace* scale-definitions-init.ly? If not, these definitions are redundant. From Hassan: hel-arabic.ly don't need scale-definitions-init.ly. in other words it replaces scale-definitions-init.ly (minor, major,... are defined in hel-arabic.ly). There is no interaction between hel-arabic.ly and scale-definitions-init.ly In addition, it uses bb (b flat) instead of bes and dd (d sharp) instead of dis for example. We write music independently. There is of course edb (e semi-flat), fdd (f semi-sharp ). Major and minor makams exist in Arabic music. They have different names : ajam (for major) and nahawand (for minor) In conclusion I think it's better to delete them. Also Reminder: - hel-arabic.ly uses define-note-names.scm and lily-library.scm define-note-names.scm and lily-library.scm are not modified https://codereview.appspot.com/349810043/diff/1/ly/hel-arabic.ly File ly/hel-arabic.ly (right): https://codereview.appspot.com/349810043/diff/1/ly/hel-arabic.ly#newcode158 ly/hel-arabic.ly:158: (4 . FLAT) On 2018/12/12 08:55:01, Malte Meyn wrote: Should be ,FLAT (with comma). Or ,SHARP == 1/2? Yes this should have a comma. https://codereview.appspot.com/349810043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
