Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1188192 > unrolled thread

Bug#1064998: guile-lib: broken package when cross building

Started byHelmut Grohne <helmut@subdivi.de>
First post2024-02-28 21:30 +0100
Last post2024-03-02 03:40 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.debian.bugs.dist


Contents

  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

#1188192 — Bug#1064998: guile-lib: broken package when cross building

FromHelmut Grohne <helmut@subdivi.de>
Date2024-02-28 21:30 +0100
SubjectBug#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]


#1188711

FromVagrant Cascadian <vagrant@debian.org>
Date2024-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]


#1188865

FromMaxim Cournoyer <maxim.cournoyer@gmail.com>
Date2024-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]


#1188974

FromDavid Pirotte <david@altosw.be>
Date2024-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]


#1188721

FromVagrant Cascadian <vagrant@debian.org>
Date2024-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