Re: lilypond on Apple silicon

[Hans Åberg]

> On 16 Jan 2021, at 13:05, Werner LEMBERG  wrote:
> 
> According to
> 
>  https://ports.macports.org/port/lilypond/summary
> 
> the problems with the dependencies have been fixed; this means that
> lilypond should now install fine using MacPorts on Apple silicon.

I tried building lilypond-devel with +universal, first editing 
/opt/local/etc/macports/macports.conf, setting universal_archs, but it failed 
on some x86_64 component even without arm64, I think. It would seem possible to 
make a fat installer for more MacOS versions, but some of the MacPorts people 
would have to help out on that.

Re: probable guile-1.8.9 release

[Han-Wen Nienhuys]

On Sat, Jan 16, 2021 at 2:52 PM Jonas Hahnfeld  wrote:
> > I can probably trim down the fix to be more backward compatible.
> >
> > Do you know of documentation that details what is and is not allowed
> > in an ABI-compatible change?
>
> No, but let me know if you find one, would be good to have a reference
> to a writeup from somebody who knows.
> [..]
> This means you must only change the body of functions and the size of
> static variables (that are local per TU). Changing the meaning of only

Thanks! How's this?
https://github.com/hanwen/guile/commit/3bf5057232c35df155badfee9489081bdbbf4ecb

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: probable guile-1.8.9 release

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, dem 16.01.2021 um 13:38 +0100 schrieb Han-Wen Nienhuys:
> On Sat, Jan 16, 2021 at 9:56 AM Jonas Hahnfeld via Discussions on
> LilyPond development  wrote:
> > 
> > Am Montag, dem 11.01.2021 um 11:06 +0100 schrieb Michael Käppler:
> > > Am 11.01.2021 um 10:58 schrieb Thomas Morley:
> > > > Hi,
> > > > 
> > > > please have a look at
> > > > https://lists.gnu.org/archive/html/guile-user/2021-01/msg00026.html
> > > > 
> > > > Cheers,
> > > >    Harm
> > > > 
> > > Could this probably include Han-Wen's recent fix regarding GC?
> > 
> > My understanding is that the fix is ABI incompatible with earlier
> > releases of Guile 1.8; at least I get
> > $ LD_LIBRARY_PATH=/code/guile/install/lib/ ./out/bin/lilypond -dhelp
> > ./out/bin/lilypond: Symbol `scm_i_master_freelist2' has different size in 
> > shared object, consider re-linking
> > ./out/bin/lilypond: Symbol `scm_i_master_freelist' has different size in 
> > shared object, consider re-linking
> > 
> > This is because scm_t_cell_type_statistics, the type of the two
> > symbols, changed size (got bigger), and this is usually a no-no for a
> > minor bugfix release. I'm not saying this makes sense (AFAICT these
> > symbols shouldn't be public), but it's the current situation and the
> > bugfix would require relinking all objects depending on the library.
> 
> I can probably trim down the fix to be more backward compatible.
> 
> Do you know of documentation that details what is and is not allowed
> in an ABI-compatible change?

No, but let me know if you find one, would be good to have a reference
to a writeup from somebody who knows.

My understanding is the following:
 * API compatibility means that the same source code is expected to
work, ie no removed functions or changed semantics of arguments. Added
functions are mostly fine, I think, as are changes to public data
structures such as adding or reordering symbols. The latter requires
recompilation and / or relinking.
 * On top of that, ABI compatibility means that the library can be used
as a drop-in replacement. This means all data structures and symbols
must have the same size, and I think you may only add methods to the
end of C++ classes (but I may misremember something here).

Now because Guile 1.8 is built without -fvisibility=hidden, my
understand is that *all* internal symbols are part of the public ABI.
This means you must only change the body of functions and the size of
static variables (that are local per TU). Changing the meaning of only
internally used data structures is probably ok as long as you keep the
size.

You can easily find if you did something wrong by executing a binary
compiled against an existing version of the library. If that works,
chances are that it's ABI compatible, but I'd bet there are odd corner
cases...

Jonas


signature.asc
Description: This is a digitally signed message part

Re: probable guile-1.8.9 release

[Werner LEMBERG]

> Do you know of documentation that details what is and is not allowed
> in an ABI-compatible change?

You might try

  https://lvc.github.io/abi-compliance-checker/


Werner

Re: probable guile-1.8.9 release

[Han-Wen Nienhuys]

On Sat, Jan 16, 2021 at 9:56 AM Jonas Hahnfeld via Discussions on
LilyPond development  wrote:
>
> Am Montag, dem 11.01.2021 um 11:06 +0100 schrieb Michael Käppler:
> > Am 11.01.2021 um 10:58 schrieb Thomas Morley:
> > > Hi,
> > >
> > > please have a look at
> > > https://lists.gnu.org/archive/html/guile-user/2021-01/msg00026.html
> > >
> > > Cheers,
> > >Harm
> > >
> > Could this probably include Han-Wen's recent fix regarding GC?
>
> My understanding is that the fix is ABI incompatible with earlier
> releases of Guile 1.8; at least I get
> $ LD_LIBRARY_PATH=/code/guile/install/lib/ ./out/bin/lilypond -dhelp
> ./out/bin/lilypond: Symbol `scm_i_master_freelist2' has different size in 
> shared object, consider re-linking
> ./out/bin/lilypond: Symbol `scm_i_master_freelist' has different size in 
> shared object, consider re-linking
>
> This is because scm_t_cell_type_statistics, the type of the two
> symbols, changed size (got bigger), and this is usually a no-no for a
> minor bugfix release. I'm not saying this makes sense (AFAICT these
> symbols shouldn't be public), but it's the current situation and the
> bugfix would require relinking all objects depending on the library.

I can probably trim down the fix to be more backward compatible.

Do you know of documentation that details what is and is not allowed
in an ABI-compatible change?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

lilypond on Apple silicon

[Werner LEMBERG]

According to

  https://ports.macports.org/port/lilypond/summary

the problems with the dependencies have been fixed; this means that
lilypond should now install fine using MacPorts on Apple silicon.


Werner

Re: Stale branches in the canonical repository

[Jonas Hahnfeld]

Am Sonntag, dem 10.01.2021 um 12:32 +0100 schrieb Jonas Hahnfeld:
> Hi all,
> 
> there are currently 38 branches (out of 72 in total) in the canonical
> repository that have a committed date older than 90 days, excluding the
> stable/* branches. I suppose many of these were temporary, abandoned in
> the mean time or simply don't apply anymore. IMHO this might become
> problematic over time as we accumulate branches because important ones
> will be harder to find.
> For that reason, I'd like to ask everyone to go through the list below
> and delete your branches that you don't need anymore, from both GitLab
> and Savannah (or let me know and I can do it). Also please remember to
> delete branches of closed merge requests to avoid this problem in the
> future. Or open MRs from your private fork in which case I don't care
> how many branches you have  (I use this all the time and there's no
> disadvantage, you even benefit from the fast CI if you're a Developer
> in the project.)

Let me share some thoughts on un-prefixed branches that don't seem to
be related to a single developer:

> Branch dev/guile-v2-work, last commit:
> XXX reset the locale when building index.html
> by Antonio Ospite at 2016-11-22, committed at 2020-02-10

plus commit "XXX don't override LANG globally in the build process"

> Branch dev/guilev21, last commit:
> Source_file::init_port: Keep GUILEv2 from redecoding string input
> by David Kastrup at 2014-09-21, committed at 2016-01-10

... which is now in master as de9f49055c (and was later replaced by
commit 483292eb80).

Current master builds and works fine with Guile 2.x (from a correctness
perspective), so I think we should delete these.

> Branch dev/upc-test-2, last commit:
> x
> by David Kastrup at 2013-07-17, committed at 2013-07-17
> 
> Branch dev/upc-test, last commit:
> These are all the modifications save those to define-grobs.scm.
> by Mike Solomon at 2013-07-16, committed at 2013-07-16

I think these two branches were used to debug
https://gitlab.com/lilypond/lilypond/-/issues/3385 , see also
https://lists.gnu.org/archive/html/lilypond-devel/2013-07/msg00153.html
Since that is fixed, the branches can be deleted I would say.

If nobody objects, I will remove these branches in a few days from both
GitLab and Savannah (I still have monthly backups from GitLab, so we
won't lose them until I need more space on my backup drive...)

Jonas


signature.asc
Description: This is a digitally signed message part

Re: LilyPond 2.22.0 released!

[Jonas Hahnfeld]

Am Montag, dem 11.01.2021 um 13:35 + schrieb Phil Holmes:
> We are proud to announce the release of GNU LilyPond 2.22.0. LilyPond
> is a music engraving program devoted to producing the highest-quality
> sheet music possible. It brings the aesthetics of traditionally
> engraved music to computer printouts.
> 
> This version includes improvements and fixes since the branching of
> the previous stable release in August 2017 (even though the final
> 2.20.0 was only released in March 2020). A list of added features and
> other user-visible changes can be found at
> https://lilypond.org/doc/v2.22/Documentation/changes/
> Behind the scenes, this release switches to Python 3 and includes a
> number of performance improvements that should be noticeable for
> larger scores.

This new stable version of LilyPond was uploaded to Arch Linux at the
beginning of this week (not by me, but I was in contact with the
package maintainer) and I wanted to share a cool advancement:
https://tests.reproducible-builds.org/archlinux/community/lilypond/lilypond-2.22.0-2-x86_64.pkg.tar.zst.html
This infrastructure built the package twice and they were identical at
the binary level!

Even better, every user of Arch Linux can now verify that the
downloaded package was exactly produced by the claimed sources:
 $ repro /var/cache/pacman/pkg/lilypond-2.22.0-2-x86_64.pkg.tar.zst
[...]
==> Comparing hashes...
==> Package is reproducible!

(This will first download the exact same set of packages installed
during build of the package, around 500 MB. Then it will build LilyPond
according to the uploaded PKGBUILD and compare the result.)

tl;dr: Thanks Werner for figuring out the fix to make the font
generation reproducible!

Cheers
Jonas


signature.asc
Description: This is a digitally signed message part

Re: Pop up from Gitlab about Job artifacts expiring

[Werner LEMBERG]

> before that date last year (June 22, 2020) it was possible to create
> CI artifacts that never expired.  This posed problems (huge data
> volume) for GitLab Inc running gitlab.com, so they decided to add an
> expiration date retrospectively.  I guess that some may start to
> expire around now which could be unexpected if users relied on this
> 'never' happening.  However, LilyPond isn't affected by this, our
> artifacts expire after one week (IIRC) and have been since the
> beginning.

It is, however, possible to avoid expiration.  I've activated this for
one pipeline

  
https://lilypond.gitlab.io/-/lilypond/-/jobs/944871436/artifacts/test-results/index.html

so that I have a demo example how the FreeType testing system should
evolve :-)


Werner

Re: probable guile-1.8.9 release

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Montag, dem 11.01.2021 um 11:06 +0100 schrieb Michael Käppler:
> Am 11.01.2021 um 10:58 schrieb Thomas Morley:
> > Hi,
> > 
> > please have a look at
> > https://lists.gnu.org/archive/html/guile-user/2021-01/msg00026.html
> > 
> > Cheers,
> >    Harm
> > 
> Could this probably include Han-Wen's recent fix regarding GC?

My understanding is that the fix is ABI incompatible with earlier
releases of Guile 1.8; at least I get
$ LD_LIBRARY_PATH=/code/guile/install/lib/ ./out/bin/lilypond -dhelp
./out/bin/lilypond: Symbol `scm_i_master_freelist2' has different size in 
shared object, consider re-linking
./out/bin/lilypond: Symbol `scm_i_master_freelist' has different size in shared 
object, consider re-linking

This is because scm_t_cell_type_statistics, the type of the two
symbols, changed size (got bigger), and this is usually a no-no for a
minor bugfix release. I'm not saying this makes sense (AFAICT these
symbols shouldn't be public), but it's the current situation and the
bugfix would require relinking all objects depending on the library.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Pop up from Gitlab about Job artifacts expiring

[Jonas Hahnfeld]

Hi James, all,

before that date last year (June 22, 2020) it was possible to create CI
artifacts that never expired. This posed problems (huge data volume)
for GitLab Inc running gitlab.com, so they decided to add an expiration
date retrospectively. I guess that some may start to expire around now
which could be unexpected if users relied on this 'never' happening.
However, LilyPond isn't affected by this, our artifacts expire after
one week (IIRC) and have been since the beginning.

Cheers
Jonas

Am Freitag, dem 15.01.2021 um 09:15 + schrieb James:
> OK, I guess the inline attachments didn't work.
> 
> Sorry,
> 
> Here is the text verbatim.
> 
> --snip--
> 
> Important changes to default expiration dates for job meta data and 
> artifacts took effect on June 22, 2020. As part of this change 
> expiration dates have been applied to job artifacts that were created 
> without them. Find out more details and why this benefits all @gitlab 
>  users via our blog 
> .
> 
> --snip--
> 
> 
> On 15/01/2021 09:07, James wrote:
> > Hello,
> > 
> > I suddenly started getting this pop up when looking at reg tests from 
> > our CI system.
> > 
> > 
> > I can see the date is from last year, so I don't know the significance 
> > of me seeing this 'today' - after all, I've been looking at CI reg 
> > tests for a while now and not seen this before.
> > 
> > So in case this means something to someone or it matters, I thought 
> > I'd mention it.
> > 
> > James
> > 



signature.asc
Description: This is a digitally signed message part