Re: [ANNOUNCEMENT] Updated: make-4.1-1

Re: [ANNOUNCEMENT] Updated: make-4.1-1

[Ti Strga]

BLUF:  either the new make package needs cygltdl-7 as one of its
dependencies, or Guile does, so that setup.exe can Do The Right Thing.

I updated to make-4.1-1 and the executable immediately broke:

$ make --version
/usr/bin/make.exe: error while loading shared libraries: ?: cannot
open shared object file: No such file or directory

Poked the current cygcheck at it:
$ cygcheck /usr/bin/make.exe
C:\cygwin\bin\make.exe
  C:\cygwin\bin\cygwin1.dll
    C:\Windows\system32\KERNEL32.dll
      C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
      C:\Windows\system32\ntdll.dll
      C:\Windows\system32\KERNELBASE.dll
      C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
  C:\cygwin\bin\cygguile-17.dll
    C:\cygwin\bin\cygcrypt-0.dll
    C:\cygwin\bin\cyggmp-3.dll
      C:\cygwin\bin\cyggcc_s-1.dll
    C:\cygwin\bin\cygintl-8.dll
      C:\cygwin\bin\cygiconv-2.dll
cygcheck: track_down: could not find cygltdl-7.dll

I brought up setup.exe, found cygltdl-7 (which was not previously
installed), installed 2.4.6-1, and now all is well:

$ make --version
GNU Make 4.1
Built for i686-pc-cygwin
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ cygcheck /usr/bin/make.exe
C:\cygwin\bin\make.exe
  C:\cygwin\bin\cygwin1.dll
    C:\Windows\system32\KERNEL32.dll
      C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
      C:\Windows\system32\ntdll.dll
      C:\Windows\system32\KERNELBASE.dll
      C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
      C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
  C:\cygwin\bin\cygguile-17.dll
    C:\cygwin\bin\cygcrypt-0.dll
    C:\cygwin\bin\cyggmp-3.dll
      C:\cygwin\bin\cyggcc_s-1.dll
    C:\cygwin\bin\cygintl-8.dll
      C:\cygwin\bin\cygiconv-2.dll
    C:\cygwin\bin\cygltdl-7.dll

The indentation would seem to indicate that cygltdl-7 is needed by
cygguile-17 and not by make.exe directly.  This fits with what little
I know about Guile, however I did not have time to pursue the problem
any further, as I needed to go back to my original task (the one for
which I was running make).  So if/when the cygguile package is rebuilt
next time, this may all solve itself; for now this message is just an
FYI for future google users wondering why setup.exe isn't magically
doing a transitive closure.  :-)

Thanks to everyone involved!

-Ti

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: make-4.1-1

[Franz Sirl]

Am 2015-02-19 um 20:19 schrieb Ti Strga:
> BLUF:  either the new make package needs cygltdl-7 as one of its
> dependencies, or Guile does, so that setup.exe can Do The Right Thing.
>
> I updated to make-4.1-1 and the executable immediately broke:
>
> $ make --version
> /usr/bin/make.exe: error while loading shared libraries: ?: cannot
> open shared object file: No such file or directory
>
> Poked the current cygcheck at it:
> $ cygcheck /usr/bin/make.exe
> C:\cygwin\bin\make.exe
>    C:\cygwin\bin\cygwin1.dll
>      C:\Windows\system32\KERNEL32.dll
>        C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
>        C:\Windows\system32\ntdll.dll
>        C:\Windows\system32\KERNELBASE.dll
>        C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
>        C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
>    C:\cygwin\bin\cygguile-17.dll
>      C:\cygwin\bin\cygcrypt-0.dll
>      C:\cygwin\bin\cyggmp-3.dll
>        C:\cygwin\bin\cyggcc_s-1.dll
>      C:\cygwin\bin\cygintl-8.dll
>        C:\cygwin\bin\cygiconv-2.dll
> cygcheck: track_down: could not find cygltdl-7.dll

Hi,
I had the same problem, but installing cygltdl-7.dll didn't fix it:

$ cygcheck.exe /usr/bin/make
C:\cygwin\bin\make.exe
   C:\cygwin\bin\cygwin1.dll
     C:\Windows\system32\KERNEL32.dll
       C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
       C:\Windows\system32\ntdll.dll
       C:\Windows\system32\KERNELBASE.dll
       C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
       C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
   C:\cygwin\bin\cygguile-17.dll
     C:\cygwin\bin\cygcrypt-0.dll
     C:\cygwin\bin\cygintl-8.dll
       C:\cygwin\bin\cygiconv-2.dll
     C:\cygwin\bin\cygltdl-7.dll
cygcheck: track_down: could not find cyggmp-3.dll
$ dir /usr/bin/cyggmp*
/usr/bin/cyggmp-10.dll

And I can't seem to find cyggmp-3.dll anywhere anymore?

BTW, a minor wish, I would appreciate it if the make-package would be a 
bit more like the Linux distributions and also provide /usr/bin/gmake in 
addition to /usr/bin/make.

Thanks,
Franz


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Libguile17 dependency issue - attention maintainer

[Marco Atzeri]

On 2/20/2015 2:44 PM, Franz Sirl wrote:
> Am 2015-02-19 um 20:19 schrieb Ti Strga:
>> BLUF:  either the new make package needs cygltdl-7 as one of its
>> dependencies, or Guile does, so that setup.exe can Do The Right Thing.
>>
>> I updated to make-4.1-1 and the executable immediately broke:
>>
>> $ make --version
>> /usr/bin/make.exe: error while loading shared libraries: ?: cannot
>> open shared object file: No such file or directory
>>
>> cygcheck: track_down: could not find cygltdl-7.dll
>
> Hi,
> I had the same problem, but installing cygltdl-7.dll didn't fix it:
>
> cygcheck: track_down: could not find cyggmp-3.dll
> $ dir /usr/bin/cyggmp*
> /usr/bin/cyggmp-10.dll
>
> And I can't seem to find cyggmp-3.dll anywhere anymore?
>

the dependency of cygguile-17.dll on x86 are

/usr/bin/cygcrypt-0.dll  =>  crypt-1.2-1
/usr/bin/cygwin1.dll  =>  cygwin-1.7.34-6
/usr/bin/cyggmp-3.dll  =>  libgmp3-4.3.2-1
/usr/bin/cygintl-8.dll  =>  libintl8-0.19.3-1
/usr/bin/cygltdl-7.dll  =>  libltdl7-2.4.6-1

But there is no require on the setup.ini 32bit version

@ libguile17
sdesc: "The GNU extension language and Scheme interpreter - runtime"
ldesc: "The GNU extension language and Scheme interpreter - runtime
Guile shared object libraries and the ice-9 scheme module.  Guile is
the GNU Ubiquitous Intelligent Language for Extension.
"
category: Libs
version: 1.8.7-2


while the 64 bit version correctly report

requires: bash libcrypt0 libgmp10 libintl8 libltdl7


Moreover the 32bit and 64bit are out of sinc
1.8.7-2 vs 1.8.8-1


> Thanks,
> Franz

Regards
MArco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Cosimo Lupo]

Hi,

is there a way to downgrade and force cygwin use the previous version of 
make-4.1?

thanks


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

Hi Marco,

On Feb 20 15:53, Marco Atzeri wrote:
> [...]
> Moreover the 32bit and 64bit are out of sinc
> 1.8.7-2 vs 1.8.8-1

unfortunately it turns out that our guile (and lilypond) maintainer has
left us, so the packages are orphaned.  Jan's last version of guile was
1.8.7-2 for 32 bit.

I don't remember who provided the 64 bit distro with guile 1.8.8, Yaakov
I suspect.  Whoever it did, any chance to rebuild guile for both
platforms?

Does anybody have fun to take over maintainership of guile or lilypond?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Libguile17 dependency issue - attention maintainer

[Marco Atzeri]

On 2/20/2015 4:42 PM, Corinna Vinschen wrote:
> Hi Marco,
>
> On Feb 20 15:53, Marco Atzeri wrote:
>> [...]
>> Moreover the 32bit and 64bit are out of sinc
>> 1.8.7-2 vs 1.8.8-1
>
> unfortunately it turns out that our guile (and lilypond) maintainer has
> left us, so the packages are orphaned.  Jan's last version of guile was
> 1.8.7-2 for 32 bit.
>
> I don't remember who provided the 64 bit distro with guile 1.8.8, Yaakov
> I suspect.  Whoever it did, any chance to rebuild guile for both
> platforms?
>
> Does anybody have fun to take over maintainership of guile or lilypond?

Fan not so much I suspect, but I will look on those next week.
Please in the mean time add the right dependency to libguile17

> Thanks,
> Corinna

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Marco Atzeri]

On 2/20/2015 4:18 PM, Cosimo Lupo wrote:
> Hi,
>
> is there a way to downgrade and force cygwin use the previous version of
> make-4.1?

any specific reason to not use version 4.1 ?
(except the momentary install glitch)

> thanks
>

It is easier to install the dependencies of the 32bit version

/usr/bin/cygguile-17.dll

/usr/bin/cygcrypt-0.dll  =>  crypt-1.2-1
/usr/bin/cyggmp-3.dll  =>  libgmp3-4.3.2-1
/usr/bin/cygintl-8.dll  =>  libintl8-0.19.3-1
/usr/bin/cygltdl-7.dll  =>  libltdl7-2.4.6-1

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On Feb 20 17:27, Marco Atzeri wrote:
> On 2/20/2015 4:42 PM, Corinna Vinschen wrote:
> >Hi Marco,
> >
> >On Feb 20 15:53, Marco Atzeri wrote:
> >>[...]
> >>Moreover the 32bit and 64bit are out of sinc
> >>1.8.7-2 vs 1.8.8-1
> >
> >unfortunately it turns out that our guile (and lilypond) maintainer has
> >left us, so the packages are orphaned.  Jan's last version of guile was
> >1.8.7-2 for 32 bit.
> >
> >I don't remember who provided the 64 bit distro with guile 1.8.8, Yaakov
> >I suspect.  Whoever it did, any chance to rebuild guile for both
> >platforms?
> >
> >Does anybody have fun to take over maintainership of guile or lilypond?
> 
> Fan not so much I suspect, but I will look on those next week.
> Please in the mean time add the right dependency to libguile17

Yaakov is working on new guile packages introducing the right set
of dependencies automatically.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Libguile17 dependency issue - attention maintainer

[Achim Gratz]

Marco Atzeri writes:
> It is easier to install the dependencies of the 32bit version
>
> /usr/bin/cygguile-17.dll
>
> /usr/bin/cygcrypt-0.dll  =>  crypt-1.2-1
> /usr/bin/cyggmp-3.dll  =>  libgmp3-4.3.2-1

That's a slight problem since I think Yaakov just nuked this library…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Yaakov Selkowitz]

On Fri, 2015-02-20 at 17:51 +0100, Achim Gratz wrote:
> Marco Atzeri writes:
> > It is easier to install the dependencies of the 32bit version
> >
> > /usr/bin/cygguile-17.dll
> >
> > /usr/bin/cygcrypt-0.dll  =>  crypt-1.2-1
> > /usr/bin/cyggmp-3.dll  =>  libgmp3-4.3.2-1
> 
> That's a slight problem since I think Yaakov just nuked this library…

I just uploaded a new guile.i686 package which has fully listed (and
current) dependencies.

--
Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[David Stacey]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On 20/02/15 15:42, Corinna Vinschen wrote:
> unfortunately it turns out that our guile (and lilypond) maintainer has
> left us, so the packages are orphaned.  Jan's last version of guile was
> 1.8.7-2 for 32 bit.
>
> Does anybody have fun to take over maintainership of guile or lilypond?

First, let me say that I have no intention of maintaining lilypond - I 
am aware that even replying to this e-mail puts me in danger of 
acquiring another couple of packages ;-) I absolutely love lilypond and 
would like it to stay within Cygwin if at all possible, but I don't have 
the time right now to take on a package that is going to be a little 
problematic.

I had a go at building lilypond for x86_64 about 18 months ago, but 
didn't get very far. I managed to produce an executable, but 'make doc' 
and 'make check' both failed, so I didn't have any confidence in the 
binary produced. My need for a working lilypond exceeded the tinkering 
time available, so I just used Fedora.

I've tidied up the cygport file this evening, and this (along with a 
small patch) is attached. Hopefully this will be a starting point for a 
prospective maintainer with the time to do it justice.

Dave.


[-- Attachment #2: lilypond.cygport --]
[-- Type: text/plain, Size: 2986 bytes --]

# lilypond.cygport
NAME="lilypond"
VERSION=2.19.15
RELEASE=1
SUMMARY="A typesetting system for music notation."
DESCRIPTION="LilyPond is an automated music engraving system. It formats music beautifully and automatically, and has a friendly syntax for its input files."
CATEGORY="Interpreters"

MAJOR_VERSION="$(echo ${VERSION} | cut -d '.' -f 1)"
MINOR_VERSION="$(echo ${VERSION} | cut -d '.' -f 2)"


#############################################################################
# Patches. These are as follows:
#
#   - 2.18.2-dos-to-posix.patch - Use cygwin_conv_path() instead of
#     cygwin_conv_to_posix_path().
PATCH_URI="
	2.18.2-dos-to-posix.patch
"
#############################################################################


HOMEPAGE="http://www.lilypond.org/"
SRC_URI="http://download.linuxaudio.org/${PN}/sources/v${MAJOR_VERSION}.${MINOR_VERSION}/${P}.tar.gz"
DIFF_EXCLUDES="configure"


#############################################################################
# This cygport file produces two packages, the main 'lilypond' package and
# 'lilypond-doc' which contains the documentation.
PKG_NAMES="lilypond lilypond-doc"
#############################################################################


#############################################################################
# The main 'lilypond' package contains everything except the HTML
# documentation.
lilypond_CONTENTS="--exclude=html usr"
lilypond_SUMMARY="${SUMMARY}"
lilypond_DESCRIPTION="${DESCRIPTION}"
lilypond_CATEGORY="Interpreters"
#############################################################################


#############################################################################
# The 'lilypond-doc' package.
lilypond_doc_CONTENTS="usr/share/doc/lilypond/html"
lilypond_doc_SUMMARY="HTML documentation for LilyPond."
lilypond_doc_DESCRIPTION="${DESCRIPTION} This package contains the HTML documentation for LilyPond."
lilypond_doc_CATEGORY="Doc"
#############################################################################


src_compile() {
	cd "${S}"
	./autogen.sh --noconfigure
	cd "${B}"
	"${S}/configure" --prefix=/usr --exec-prefix=/usr \
		--with-ncsb-dir=/usr/share/ghostscript/fonts

	# lilypond doesn't compile with parallel builds.
	MAKEOPTS+=" -j 1"

	# The code in the python directory won't compile out of the box, as
	# it needs '-lpython', and the makefile doesn't link against this
	# library. So we build this first, explicitly specifying the python
	# libraries. Once this is built, we can build the rest of the
	# lilypond code.
	cd "${B}/python"
	cygmake LDFLAGS="$(python-config --libs)"
	cd "${B}"
	cygmake

	# Make the lilypond documentation.
	cygmake doc
}


src_install() {
	local vimdir=/usr/share/vim/vim74
	mkdir -p "${D}${vimdir}"

	cd "${B}"
	make install DESTDIR="${D}" vimdir="${vimdir}"

	# Symlink lilypond-init.el in emacs' site-start.d directory
	cd "${D}/usr/share/emacs/site-lisp"
	mkdir site-start.d
	ln -s ../lilypond-init.el site-start.d
}

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 2.18.2-dos-to-posix.patch --]
[-- Type: text/x-patch; name="2.18.2-dos-to-posix.patch", Size: 885 bytes --]

--- origsrc/lilypond-2.18.2/flower/file-name.cc	2014-03-17 15:29:16.000000000 +0000
+++ src/lilypond-2.18.2/flower/file-name.cc	2015-02-20 19:49:29.762829900 +0000
@@ -53,13 +53,14 @@ using namespace std;
 static string
 dos_to_posix (const string &file_name)
 {
-  char buf[PATH_MAX] = "";
-  char s[PATH_MAX] = {0};
-  file_name.copy (s, PATH_MAX - 1);
-  /* ugh: char const* argument gets modified.  */
-  int fail = cygwin_conv_to_posix_path (s, buf);
-  if (!fail)
-    return buf;
+  const char* const win32 = file_name.c_str();
+  const ssize_t size = cygwin_conv_path(CCP_WIN_W_TO_POSIX | CCP_RELATIVE, win32, NULL, 0);
+  if (size >= 0)
+  {
+    std::vector<char> posix(size, '\0');
+    if (!cygwin_conv_path(CCP_WIN_W_TO_POSIX | CCP_RELATIVE, win32, &posix[0], size))
+      return std::string(&posix[0], size);
+  }
   return file_name;
 }
 #endif /* __CYGWIN__ */

[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Marco Atzeri]

On 2/21/2015 12:19 AM, David Stacey wrote:
> On 20/02/15 15:42, Corinna Vinschen wrote:
>> unfortunately it turns out that our guile (and lilypond) maintainer has
>> left us, so the packages are orphaned.  Jan's last version of guile was
>> 1.8.7-2 for 32 bit.
>>
>> Does anybody have fun to take over maintainership of guile or lilypond?
>
> First, let me say that I have no intention of maintaining lilypond - I
> am aware that even replying to this e-mail puts me in danger of
> acquiring another couple of packages ;-) I absolutely love lilypond and
> would like it to stay within Cygwin if at all possible, but I don't have
> the time right now to take on a package that is going to be a little
> problematic.
>
> I had a go at building lilypond for x86_64 about 18 months ago, but
> didn't get very far. I managed to produce an executable, but 'make doc'
> and 'make check' both failed, so I didn't have any confidence in the
> binary produced. My need for a working lilypond exceeded the tinkering
> time available, so I just used Fedora.
>
> I've tidied up the cygport file this evening, and this (along with a
> small patch) is attached. Hopefully this will be a starting point for a
> prospective maintainer with the time to do it justice.
>
> Dave.

Thanks Dave,
for the starting point.
I used that as base for the 64 bit package just released.

Removing the cygwin specific usage of
   cygwin_conv_to_posix_path / cygwin_conv_path
did the work. Make check passed on 64bit, and make doc fails
on a corner case, most of the HTML documentation was built.

The 32 bit builds but does not works. I suspect there is an additional
problem with the underlying dependencies, or we are triggering an
existing problem not visible on Linux platform.


Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[David Stacey]

On 12/04/15 11:03, Marco Atzeri wrote:
> On 2/21/2015 12:19 AM, David Stacey wrote:
>> On 20/02/15 15:42, Corinna Vinschen wrote:
>>> unfortunately it turns out that our guile (and lilypond) maintainer has
>>> left us, so the packages are orphaned.  Jan's last version of guile was
>>> 1.8.7-2 for 32 bit.
>>>
>>> Does anybody have fun to take over maintainership of guile or lilypond?
>>
>> First, let me say that I have no intention of maintaining lilypond - I
>> am aware that even replying to this e-mail puts me in danger of
>> acquiring another couple of packages ;-) I absolutely love lilypond and
>> would like it to stay within Cygwin if at all possible, but I don't have
>> the time right now to take on a package that is going to be a little
>> problematic.
>>
>> I had a go at building lilypond for x86_64 about 18 months ago, but
>> didn't get very far. I managed to produce an executable, but 'make doc'
>> and 'make check' both failed, so I didn't have any confidence in the
>> binary produced. My need for a working lilypond exceeded the tinkering
>> time available, so I just used Fedora.
>>
>> I've tidied up the cygport file this evening, and this (along with a
>> small patch) is attached. Hopefully this will be a starting point for a
>> prospective maintainer with the time to do it justice.
>>
>> Dave.
>
> Thanks Dave,
> for the starting point.
> I used that as base for the 64 bit package just released.
>
> Removing the cygwin specific usage of
>   cygwin_conv_to_posix_path / cygwin_conv_path
> did the work. Make check passed on 64bit, and make doc fails
> on a corner case, most of the HTML documentation was built.

Well done - you've already got further than I managed. I have a soft 
spot for lilypond, so I'm really pleased that you've adopted it - I'd 
hate to see it removed from Cygwin. Next time I update my 64-bit 
installation I'll give it a test.

Dave.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[David Stacey]

On 12/04/15 11:03, Marco Atzeri wrote:
> Removing the cygwin specific usage of
>   cygwin_conv_to_posix_path / cygwin_conv_path
> did the work. Make check passed on 64bit, and make doc fails
> on a corner case, most of the HTML documentation was built.

OK, so I couldn't resist a little play :-)

Seemed to work well with all the '.ly' files I threw at it. I generated 
PDF, PNG and MIDI files successfully. I tried a few files from a web 
site with lots of freely available lilypond files, and a couple of files 
gave warnings. If you try:

     wget 
http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly
     lilypond --formats=pdf,png Caprice_23.ly

Then you see repeated instances of the following warnings:

     warning: no PostScript font name for font 
`/usr/share/fonts/100dpi/ncenR24.pcf.gz'
     warning: FreeType face has no PostScript font name

     programming error: Improbable offset for stencil: -inf staff space
     Setting to zero.
     continuing, cross fingers

I didn't have time to cross my fingers, but the resulting output files 
all looked fine ;-)

I ran the same test using the stock 'lilypond' package in Fedora 21 (the 
version of lilypond is the same), and the warnings weren't generated. 
The first warning is a little baffling, as lilypond knows where the 
PostScript fonts are (the path is specified as a ./configure option). 
It's worth saying that most of the files I tried worked fine without 
generating warnings.

BTW, I assume you're aware that the 'lilypond-doc' package is missing 
most of its content, and that this will be fully populated when the 
'corner case' you mentioned is ironed out.

> The 32 bit builds but does not works. I suspect there is an additional
> problem with the underlying dependencies, or we are triggering an
> existing problem not visible on Linux platform.

Have you tried the old version of lilypond we have in x86 at the moment? 
I couldn't get it to work at all. Every '.ly' file I passed to it (even 
simple ones) caused a segmentation fault. So your suspicion about one of 
the dependencies looks well founded.

Dave.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Eliot Moss]

On 4/12/2015 4:17 PM, David Stacey wrote:
> On 12/04/15 11:03, Marco Atzeri wrote:

> Seemed to work well with all the '.ly' files I threw at it. I generated PDF, PNG and MIDI files
> successfully. I tried a few files from a web site with lots of freely available lilypond files, and
> a couple of files gave warnings. If you try:
>
>      wget http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly
>      lilypond --formats=pdf,png Caprice_23.ly
>
> Then you see repeated instances of the following warnings:
>
>      warning: no PostScript font name for font `/usr/share/fonts/100dpi/ncenR24.pcf.gz'
>      warning: FreeType face has no PostScript font name

I was getting that with the previous version, and segfaults.  I had to back up some to
get it to work at all, and I recall, I still can't get Times Roman.  I wasn't sure who /
how to report it, but this thread prompts me to chime in.  Struck me as a problem with
Guile more than Lilypond itself, but I can't say now why I thought that at the time ...

Regards -- Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Libguile17 dependency issue - attention maintainer

[Marco Atzeri]

On 4/12/2015 10:39 PM, Eliot Moss wrote:
> On 4/12/2015 4:17 PM, David Stacey wrote:
>> On 12/04/15 11:03, Marco Atzeri wrote:
>
>> Seemed to work well with all the '.ly' files I threw at it. I
>> generated PDF, PNG and MIDI files
>> successfully. I tried a few files from a web site with lots of freely
>> available lilypond files, and
>> a couple of files gave warnings. If you try:
>>
>>      wget
>> http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly
>>      lilypond --formats=pdf,png Caprice_23.ly

I just built 2.19.18 on 32bit.
I received an advise on lilypond devel list,
that up to 2.19.15 some bugs were present on 32 bit platform.

"make check passes" , so I will test this one also.

>> Then you see repeated instances of the following warnings:
>>
>>      warning: no PostScript font name for font
>> `/usr/share/fonts/100dpi/ncenR24.pcf.gz'
>>      warning: FreeType face has no PostScript font name
>
> I was getting that with the previous version, and segfaults.  I had to
> back up some to
> get it to work at all, and I recall, I still can't get Times Roman.  I
> wasn't sure who /
> how to report it, but this thread prompts me to chime in.  Struck me as
> a problem with
> Guile more than Lilypond itself, but I can't say now why I thought that
> at the time ...

I am taking over also guile.

> Regards -- Eliot Moss

Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Lilypond

[Marco Atzeri]

On 4/12/2015 11:44 PM, Marco Atzeri wrote:
> On 4/12/2015 10:39 PM, Eliot Moss wrote:
>> On 4/12/2015 4:17 PM, David Stacey wrote:
>>> On 12/04/15 11:03, Marco Atzeri wrote:
>>
>>> Seemed to work well with all the '.ly' files I threw at it. I
>>> generated PDF, PNG and MIDI files
>>> successfully. I tried a few files from a web site with lots of freely
>>> available lilypond files, and
>>> a couple of files gave warnings. If you try:
>>>
>>>      wget
>>> http://www.mutopiaproject.org/ftp/PaganiniN/O1/Caprice_23/Caprice_23.ly
>>>      lilypond --formats=pdf,png Caprice_23.ly
>
>>>
>>>      warning: no PostScript font name for font
>>> `/usr/share/fonts/100dpi/ncenR24.pcf.gz'
>>>      warning: FreeType face has no PostScript font name
>>
>> I was getting that with the previous version, and segfaults.  I had to
>> back up some to
>> get it to work at all, and I recall, I still can't get Times Roman.  I
>> wasn't sure who /
>> how to report it, but this thread prompts me to chime in.

using 2.19.18 I see

warning: no PostScript font name for font 
`/usr/share/fonts/75dpi/ncenR24.pcf.gz'
warning: FreeType face has no PostScript font name
warning: no PostScript font name for font 
`/usr/share/fonts/75dpi/ncenB24.pcf.gz'
warning: FreeType face has no PostScript font name
warning: no PostScript font name for font 
`/usr/share/fonts/75dpi/ncenB24.pcf.gz'
warning: FreeType face has no PostScript font name
programming error: Improbable offset for stencil: -inf staff space
Setting to zero.
continuing, cross fingers
Layout output to `Caprice_23.ps'...
Converting to `./Caprice_23.pdf'...
Converting to PNG...
Success: compilation successfully completed

the warning is also mentioned here
http://comments.gmane.org/gmane.comp.gnu.lilypond.general/93663

But it seems not related to segfaults.

Building docs still hang in some place but I will deploy 2.19.18
with PDF only documentation.



Regards
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Lilypond

[Eliot Moss]

On 4/13/2015 5:56 AM, Marco Atzeri wrote:
> On 4/12/2015 11:44 PM, Marco Atzeri wrote:
>> On 4/12/2015 10:39 PM, Eliot Moss wrote:
>>> On 4/12/2015 4:17 PM, David Stacey wrote:
>>>> On 12/04/15 11:03, Marco Atzeri wrote:

> using 2.19.18 I see
>
> warning: no PostScript font name for font `/usr/share/fonts/75dpi/ncenR24.pcf.gz'
> warning: FreeType face has no PostScript font name
> warning: no PostScript font name for font `/usr/share/fonts/75dpi/ncenB24.pcf.gz'
> warning: FreeType face has no PostScript font name
> warning: no PostScript font name for font `/usr/share/fonts/75dpi/ncenB24.pcf.gz'
> warning: FreeType face has no PostScript font name
> programming error: Improbable offset for stencil: -inf staff space
> Setting to zero.
> continuing, cross fingers
> Layout output to `Caprice_23.ps'...
> Converting to `./Caprice_23.pdf'...
> Converting to PNG...
> Success: compilation successfully completed
>
> the warning is also mentioned here
> http://comments.gmane.org/gmane.comp.gnu.lilypond.general/93663

Yes, that reference reminds me that the finger did point toward pango -- that it
is somehow not detecting Postscript font availability.

Regards -- Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple