* bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS
@ 2016-10-31 5:33 Mark H Weaver
2016-10-31 5:58 ` bug#24832: Hydra generates faulty derivation for gettext-boot0 Mark H Weaver
2016-10-31 12:01 ` Ludovic Courtès
0 siblings, 2 replies; 6+ messages in thread
From: Mark H Weaver @ 2016-10-31 5:33 UTC (permalink / raw)
To: 24832
Almost all of the derivations being generated on Hydra for MIPS on the
'core-updates' branch differ from what is generated locally by guix on a
mips64el-linux machine. The differences go at least as far back as
'gettext-boot0', where Hydra generates:
/gnu/store/yzsx42kva1pgj96n9yir7j6xx0ndp7is-gettext-boot0-0.19.8.1.drv
but 'guix' on both my Yeeloong and on hydra-slave0 generates:
/gnu/store/2zzkamx4a0wrv2372pxjm5kdd0jvnl76-gettext-boot0-0.19.8.1.drv
Comparing those two derivations, I see that the derivation built by
Hydra includes as an input:
/gnu/store/armz91zr59wzv0v0p3x9kvjxwzi714dx-ld-wrapper-x86_64-guix-linux-gnu-0.drv
but the one generated by 'guix' on a mips machine includes:
/gnu/store/cc5bm6lhpv6bfny24akih86jsgzx8j82-ld-wrapper-mips64el-guix-linux-gnu-0.drv
I guess this means that the entire 'core-updates' branch will need to be
rebuilt from scratch for MIPS :-(
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#24832: Hydra generates faulty derivation for gettext-boot0 2016-10-31 5:33 bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS Mark H Weaver @ 2016-10-31 5:58 ` Mark H Weaver 2016-10-31 12:01 ` Ludovic Courtès 1 sibling, 0 replies; 6+ messages in thread From: Mark H Weaver @ 2016-10-31 5:58 UTC (permalink / raw) To: 24832 Mark H Weaver <mhw@netris.org> writes: > Almost all of the derivations being generated on Hydra for MIPS on the > 'core-updates' branch differ from what is generated locally by guix on a > mips64el-linux machine. The differences go at least as far back as > 'gettext-boot0', where Hydra generates: > > /gnu/store/yzsx42kva1pgj96n9yir7j6xx0ndp7is-gettext-boot0-0.19.8.1.drv > > but 'guix' on both my Yeeloong and on hydra-slave0 generates: > > /gnu/store/2zzkamx4a0wrv2372pxjm5kdd0jvnl76-gettext-boot0-0.19.8.1.drv > > Comparing those two derivations, I see that the derivation built by > Hydra includes as an input: > > /gnu/store/armz91zr59wzv0v0p3x9kvjxwzi714dx-ld-wrapper-x86_64-guix-linux-gnu-0.drv > > but the one generated by 'guix' on a mips machine includes: > > /gnu/store/cc5bm6lhpv6bfny24akih86jsgzx8j82-ld-wrapper-mips64el-guix-linux-gnu-0.drv > > I guess this means that the entire 'core-updates' branch will need to be > rebuilt from scratch for MIPS :-( It turns out that this same problem exists on all systems except for x86_64. To easily see the problem, start from here: https://hydra.gnu.org/eval/109337?filter=mesa and go to the build page for 'mesa-12.0.1' on any non-x86_64 system. Look up the .drv file for that package and open the corresponding file on Hydra. Then find the 'bash-4.4.0' input derivation and look at it. You'll see that it references: /gnu/store/*-ld-wrapper-x86_64-guix-linux-gnu-0.drv where that 'x86_64' should instead match the appropriate system. It appears that we'll need to rebuild all of 'core-updates' again from scratch :-( Mark ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0 2016-10-31 5:33 bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS Mark H Weaver 2016-10-31 5:58 ` bug#24832: Hydra generates faulty derivation for gettext-boot0 Mark H Weaver @ 2016-10-31 12:01 ` Ludovic Courtès 2016-10-31 12:49 ` Mark H Weaver 1 sibling, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2016-10-31 12:01 UTC (permalink / raw) To: 24832 [-- Attachment #1: Type: text/plain, Size: 645 bytes --] Hi Mark, The bug stems from ‘ld-wrapper-boot0’ and was introduced in d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine that builds the derivation—i.e., hydra.gnu.org. Instead, it should use the value of the system we’re building for, so its evaluation should be delayed, as is the case for ‘inputs’ fields. The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches except x86_64. However, this is harmless: we don’t need this ld wrapper anyway, except for GNU/Hurd. So, a short-term hack might be this: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 785 bytes --] diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index 53ba718..0a8e608 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -424,8 +424,8 @@ the bootstrap environment." (define ld-wrapper-boot0 ;; We need this so binaries on Hurd will have libmachuser and libhurduser ;; in their RUNPATH, otherwise validate-runpath will fail. - (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet)) - #:target (boot-triplet) + (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu") + #:target "x86_64-guix-linux-gnu" #:binutils binutils-boot0 #:guile %bootstrap-guile #:bash (car (assoc-ref %boot0-inputs "bash")))) [-- Attachment #3: Type: text/plain, Size: 419 bytes --] That way, we would not have to rebuild anything (it temporarily breaks GNU/Hurd though, but that’s the cost we’d have to pay.) How does that sound? The actual fix, for the next core-updates cycle, would be to delay evaluation of ld-wrapper-boot0. I guess this bug shows that nobody tried to get substitutes for core-updates on non-x86_64 platforms. :-/ Thanks a lot for the heads-up! Ludo’. ^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0 2016-10-31 12:01 ` Ludovic Courtès @ 2016-10-31 12:49 ` Mark H Weaver 2016-10-31 15:13 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Mark H Weaver @ 2016-10-31 12:49 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 24832 Hi Ludovic, ludo@gnu.org (Ludovic Courtès) writes: > The bug stems from ‘ld-wrapper-boot0’ and was introduced in > d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that > ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine > that builds the derivation i.e., hydra.gnu.org. > > Instead, it should use the value of the system we’re building for, so > its evaluation should be delayed, as is the case for ‘inputs’ fields. > > The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches > except x86_64. However, this is harmless: we don’t need this ld wrapper > anyway, except for GNU/Hurd. > > So, a short-term hack might be this: > > diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm > index 53ba718..0a8e608 100644 > --- a/gnu/packages/commencement.scm > +++ b/gnu/packages/commencement.scm > @@ -424,8 +424,8 @@ the bootstrap environment." > (define ld-wrapper-boot0 > ;; We need this so binaries on Hurd will have libmachuser and libhurduser > ;; in their RUNPATH, otherwise validate-runpath will fail. > - (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet)) > - #:target (boot-triplet) > + (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu") > + #:target "x86_64-guix-linux-gnu" > #:binutils binutils-boot0 > #:guile %bootstrap-guile > #:bash (car (assoc-ref %boot0-inputs "bash")))) > > That way, we would not have to rebuild anything (it temporarily breaks > GNU/Hurd though, but that’s the cost we’d have to pay.) > > How does that sound? Ah, nice! Could be avoid breaking GNU/Hurd by delaying evaluation of ‘ld-wrapper-boot0’ right now, but temporarily rigging it so that on all _non-Hurd_ platforms, the hard-coded value "x86_64-guix-linux-gnu" is used? Thanks! Mark ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0 2016-10-31 12:49 ` Mark H Weaver @ 2016-10-31 15:13 ` Ludovic Courtès 2017-01-20 22:17 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2016-10-31 15:13 UTC (permalink / raw) To: Mark H Weaver; +Cc: 24832 Hi Mark, Mark H Weaver <mhw@netris.org> skribis: > ludo@gnu.org (Ludovic Courtès) writes: >> The bug stems from ‘ld-wrapper-boot0’ and was introduced in >> d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that >> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine >> that builds the derivation i.e., hydra.gnu.org. >> >> Instead, it should use the value of the system we’re building for, so >> its evaluation should be delayed, as is the case for ‘inputs’ fields. >> >> The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches >> except x86_64. However, this is harmless: we don’t need this ld wrapper >> anyway, except for GNU/Hurd. >> >> So, a short-term hack might be this: >> >> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm >> index 53ba718..0a8e608 100644 >> --- a/gnu/packages/commencement.scm >> +++ b/gnu/packages/commencement.scm >> @@ -424,8 +424,8 @@ the bootstrap environment." >> (define ld-wrapper-boot0 >> ;; We need this so binaries on Hurd will have libmachuser and libhurduser >> ;; in their RUNPATH, otherwise validate-runpath will fail. >> - (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet)) >> - #:target (boot-triplet) >> + (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu") >> + #:target "x86_64-guix-linux-gnu" >> #:binutils binutils-boot0 >> #:guile %bootstrap-guile >> #:bash (car (assoc-ref %boot0-inputs "bash")))) >> >> That way, we would not have to rebuild anything (it temporarily breaks >> GNU/Hurd though, but that’s the cost we’d have to pay.) >> >> How does that sound? > > Ah, nice! Could be avoid breaking GNU/Hurd by delaying evaluation of > ‘ld-wrapper-boot0’ right now, but temporarily rigging it so that on all > _non-Hurd_ platforms, the hard-coded value "x86_64-guix-linux-gnu" is > used? Good idea. I committed something along these lines as 5bde4503eeaa1d772744abcf87afc29eb0e9329d. We’ll have to remove the workaround on the next cycle. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24832: Hydra generates faulty derivation for gettext-boot0 2016-10-31 15:13 ` Ludovic Courtès @ 2017-01-20 22:17 ` Ludovic Courtès 0 siblings, 0 replies; 6+ messages in thread From: Ludovic Courtès @ 2017-01-20 22:17 UTC (permalink / raw) To: Mark H Weaver; +Cc: 24832-done ludo@gnu.org (Ludovic Courtès) skribis: > Hi Mark, > > Mark H Weaver <mhw@netris.org> skribis: > >> ludo@gnu.org (Ludovic Courtès) writes: >>> The bug stems from ‘ld-wrapper-boot0’ and was introduced in >>> d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that >>> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine >>> that builds the derivation i.e., hydra.gnu.org. >>> >>> Instead, it should use the value of the system we’re building for, so >>> its evaluation should be delayed, as is the case for ‘inputs’ fields. >>> >>> The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches >>> except x86_64. However, this is harmless: we don’t need this ld wrapper >>> anyway, except for GNU/Hurd. >>> >>> So, a short-term hack might be this: >>> >>> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm >>> index 53ba718..0a8e608 100644 >>> --- a/gnu/packages/commencement.scm >>> +++ b/gnu/packages/commencement.scm >>> @@ -424,8 +424,8 @@ the bootstrap environment." >>> (define ld-wrapper-boot0 >>> ;; We need this so binaries on Hurd will have libmachuser and libhurduser >>> ;; in their RUNPATH, otherwise validate-runpath will fail. >>> - (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet)) >>> - #:target (boot-triplet) >>> + (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu") >>> + #:target "x86_64-guix-linux-gnu" >>> #:binutils binutils-boot0 >>> #:guile %bootstrap-guile >>> #:bash (car (assoc-ref %boot0-inputs "bash")))) >>> >>> That way, we would not have to rebuild anything (it temporarily breaks >>> GNU/Hurd though, but that’s the cost we’d have to pay.) >>> >>> How does that sound? >> >> Ah, nice! Could be avoid breaking GNU/Hurd by delaying evaluation of >> ‘ld-wrapper-boot0’ right now, but temporarily rigging it so that on all >> _non-Hurd_ platforms, the hard-coded value "x86_64-guix-linux-gnu" is >> used? > > Good idea. I committed something along these lines as > 5bde4503eeaa1d772744abcf87afc29eb0e9329d. > > We’ll have to remove the workaround on the next cycle. Done in 168c400045bda767e9921789d93562c737b7b147 in ‘core-updates’. Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-20 22:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-31 5:33 bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS Mark H Weaver 2016-10-31 5:58 ` bug#24832: Hydra generates faulty derivation for gettext-boot0 Mark H Weaver 2016-10-31 12:01 ` Ludovic Courtès 2016-10-31 12:49 ` Mark H Weaver 2016-10-31 15:13 ` Ludovic Courtès 2017-01-20 22:17 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.