Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1188192 > unrolled thread
| Started by | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| First post | 2024-02-28 21:30 +0100 |
| Last post | 2024-03-02 03:40 +0100 |
| Articles | 5 — 4 participants |
Back to article view | Back to linux.debian.bugs.dist
Bug#1064998: guile-lib: broken package when cross building Helmut Grohne <helmut@subdivi.de> - 2024-02-28 21:30 +0100
Bug#1064998: guile-lib: broken package when cross building Vagrant Cascadian <vagrant@debian.org> - 2024-03-02 02:10 +0100
Bug#1064998: guile-lib: broken package when cross building Maxim Cournoyer <maxim.cournoyer@gmail.com> - 2024-03-03 04:40 +0100
Bug#1064998: guile-lib: broken package when cross building David Pirotte <david@altosw.be> - 2024-03-04 01:00 +0100
Bug#1064998: guile-lib: broken package when cross building Vagrant Cascadian <vagrant@debian.org> - 2024-03-02 03:40 +0100
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2024-02-28 21:30 +0100 |
| Subject | Bug#1064998: guile-lib: broken package when cross building |
| Message-ID | <IcyIV-dhxj-3@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
Package: guile-lib Version: 0.2.7-4 Tags: patch upstream User: debian-cross@lists.debian.org Usertags: ftcbfs guile-lib actually does cross build, but we still track it as cross build failure, because the resulting package contains a build architecture multiarch tuple and that trips post-build sanity checks. The root cause of the failure lies in the way the ccache directory is determined. There are actually several ways this is being done during configure - some of which work correctly - and ultimately, the last attempt using GUILE_SITE_CCACHE_DIR gets to set the value wrongly. Surprisingly, there already is a more complete and working implementation GUILE_SITE_DIR and simply reusing that makes it compute the ccache directory correctly. Is the attached patch acceptable? Helmut
[toc] | [next] | [standalone]
| From | Vagrant Cascadian <vagrant@debian.org> |
|---|---|
| Date | 2024-03-02 02:10 +0100 |
| Message-ID | <Idm2Z-dOis-5@gated-at.bofh.it> |
| In reply to | #1188192 |
[Multipart message — attachments visible in raw view] — view raw
Forwarding this upstream, originally submitted in the Debian bug
tracking system at:
https://bugs.debian.org/1064998
On 2024-02-28, Helmut Grohne wrote:
> guile-lib actually does cross build, but we still track it as cross
> build failure, because the resulting package contains a build
> architecture multiarch tuple and that trips post-build sanity checks.
>
> The root cause of the failure lies in the way the ccache directory is
> determined. There are actually several ways this is being done during
> configure - some of which work correctly - and ultimately, the last
> attempt using GUILE_SITE_CCACHE_DIR gets to set the value wrongly.
> Surprisingly, there already is a more complete and working
> implementation GUILE_SITE_DIR and simply reusing that makes it compute
> the ccache directory correctly. Is the attached patch acceptable?
>
> Helmut
> --- guile-lib-0.2.7.orig/m4/guile-ext.m4
> +++ guile-lib-0.2.7/m4/guile-ext.m4
> @@ -63,12 +63,4 @@
> # The variable is marked for substitution, as by @code{AC_SUBST}.
> #
> AC_DEFUN([GUILE_SITE_CCACHE_DIR],
> - [AC_REQUIRE([GUILE_PROGS])
> - AC_MSG_CHECKING(for Guile site ccache directory)
> - GUILE_SITE_CCACHE=`$GUILE -c "(display (%site-ccache-dir))"`
> - if test "$GUILE_SITE_CCACHE" = ""; then
> - AC_MSG_FAILURE(site ccache dir not found)
> - fi
> - AC_MSG_RESULT($GUILE_SITE_CCACHE)
> - AC_SUBST(GUILE_SITE_CCACHE)
> - ])
> + [AC_REQUIRE([GUILE_SITE_DIR])])
Would the guile-lib developers consider merging this? Are there any
use-cases where this is inappropriate?
Thanks!
live well,
vagrant
[toc] | [prev] | [next] | [standalone]
| From | Maxim Cournoyer <maxim.cournoyer@gmail.com> |
|---|---|
| Date | 2024-03-03 04:40 +0100 |
| Message-ID | <IdKRH-e3sf-1@gated-at.bofh.it> |
| In reply to | #1188711 |
Hi Vagrant,
+CC David, which maintains Guile-Lib.
Vagrant Cascadian <vagrant@debian.org> writes:
> Forwarding this upstream, originally submitted in the Debian bug
> tracking system at:
>
> https://bugs.debian.org/1064998
>
> On 2024-02-28, Helmut Grohne wrote:
>> guile-lib actually does cross build, but we still track it as cross
>> build failure, because the resulting package contains a build
>> architecture multiarch tuple and that trips post-build sanity checks.
>>
>> The root cause of the failure lies in the way the ccache directory is
>> determined. There are actually several ways this is being done during
>> configure - some of which work correctly - and ultimately, the last
>> attempt using GUILE_SITE_CCACHE_DIR gets to set the value wrongly.
>> Surprisingly, there already is a more complete and working
>> implementation GUILE_SITE_DIR and simply reusing that makes it compute
>> the ccache directory correctly. Is the attached patch acceptable?
>>
>> Helmut
>> --- guile-lib-0.2.7.orig/m4/guile-ext.m4
>> +++ guile-lib-0.2.7/m4/guile-ext.m4
>> @@ -63,12 +63,4 @@
>> # The variable is marked for substitution, as by @code{AC_SUBST}.
>> #
>> AC_DEFUN([GUILE_SITE_CCACHE_DIR],
>> - [AC_REQUIRE([GUILE_PROGS])
>> - AC_MSG_CHECKING(for Guile site ccache directory)
>> - GUILE_SITE_CCACHE=`$GUILE -c "(display (%site-ccache-dir))"`
>> - if test "$GUILE_SITE_CCACHE" = ""; then
>> - AC_MSG_FAILURE(site ccache dir not found)
>> - fi
>> - AC_MSG_RESULT($GUILE_SITE_CCACHE)
>> - AC_SUBST(GUILE_SITE_CCACHE)
>> - ])
>> + [AC_REQUIRE([GUILE_SITE_DIR])])
>
> Would the guile-lib developers consider merging this? Are there any
> use-cases where this is inappropriate?
This looks reasonable to me. If I understand correctly, it makes use of
the guile.m4 already provided macro (GUILE_SITE_DIR) instead of (poorly)
implementing it as 'guile -c "(display (%site-ccache-dir))"'.
--
Thanks,
Maxim
[toc] | [prev] | [next] | [standalone]
| From | David Pirotte <david@altosw.be> |
|---|---|
| Date | 2024-03-04 01:00 +0100 |
| Message-ID | <Ie3Ul-eeVB-1@gated-at.bofh.it> |
| In reply to | #1188711 |
[Multipart message — attachments visible in raw view] — view raw
Hello debian maintainers, Vagrant, > Forwarding this upstream, originally submitted in the Debian bug > tracking system at: > https://bugs.debian.org/1064998 > ... > Would the guile-lib developers consider merging this? Are there any > use-cases where this is inappropriate? Certainly! Thanks for the report, it somehow did skip my attention when i worked on this (a long long time ago ...), that calling GUILE_SITE_DIR also defines GUILE_SITE_CCACHE I'll fix this for the next release. > Thanks! I am the one who thanks (all of you) David
[toc] | [prev] | [next] | [standalone]
| From | Vagrant Cascadian <vagrant@debian.org> |
|---|---|
| Date | 2024-03-02 03:40 +0100 |
| Message-ID | <Idns5-dOZS-5@gated-at.bofh.it> |
| In reply to | #1188192 |
[Multipart message — attachments visible in raw view] — view raw
On 2024-02-28, Helmut Grohne wrote:
> guile-lib actually does cross build, but we still track it as cross
> build failure, because the resulting package contains a build
> architecture multiarch tuple and that trips post-build sanity checks.
I am surprised that it actually cross builds at all... for me with or
without your patch, it still fails on configure:
configure: exit 1
dh_auto_configure: error: cd debian/build/guile-3.0 && ../../../configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}
/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking
--disable-silent-rules --libdir=\${prefix}/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-track
ing --host=aarch64-linux-gnu --with-guile-site=yes GUILE_EFFECTIVE_VERSION=3.0 GUILE=/usr/bin/guile-3.0 GUILD=/usr/bin/guild-3.0 returne
d exit code 1
live well,
vagrant
>
> The root cause of the failure lies in the way the ccache directory is
> determined. There are actually several ways this is being done during
> configure - some of which work correctly - and ultimately, the last
> attempt using GUILE_SITE_CCACHE_DIR gets to set the value wrongly.
> Surprisingly, there already is a more complete and working
> implementation GUILE_SITE_DIR and simply reusing that makes it compute
> the ccache directory correctly. Is the attached patch acceptable?
>
> Helmut
> --- guile-lib-0.2.7.orig/m4/guile-ext.m4
> +++ guile-lib-0.2.7/m4/guile-ext.m4
> @@ -63,12 +63,4 @@
> # The variable is marked for substitution, as by @code{AC_SUBST}.
> #
> AC_DEFUN([GUILE_SITE_CCACHE_DIR],
> - [AC_REQUIRE([GUILE_PROGS])
> - AC_MSG_CHECKING(for Guile site ccache directory)
> - GUILE_SITE_CCACHE=`$GUILE -c "(display (%site-ccache-dir))"`
> - if test "$GUILE_SITE_CCACHE" = ""; then
> - AC_MSG_FAILURE(site ccache dir not found)
> - fi
> - AC_MSG_RESULT($GUILE_SITE_CCACHE)
> - AC_SUBST(GUILE_SITE_CCACHE)
> - ])
> + [AC_REQUIRE([GUILE_SITE_DIR])])
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.bugs.dist
csiph-web