guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'Shadow' package home page and tarball no longer accessible


From: Ludovic Courtès
Subject: Re: 'Shadow' package home page and tarball no longer accessible
Date: Sun, 06 Apr 2014 21:11:34 +0200
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Mark H Weaver <address@hidden> skribis:
>>
>>> FYI, for well over a month now, our 'shadow' package cannot be built
>>> because the tarball URL is no longer accessible.  The home page is no
>>> longer accessible either.  I finally looked into this, and found this
>>> post on the mailing list:
>>>
>>>   
>>> https://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-February/010041.html
>>>
>>> The git repository is still accessible, however:
>>>
>>>   git://git.debian.org/git/pkg-shadow/shadow
>>
>> Fixed in commit aaff68e.
>
> This new 'shadow' package fails to build on the Loongson 3A machine,
> even though the old tarball version worked (after I manually added the
> tarball to the store from an existing copy).
>
> I've attached the failed build log.  Any ideas?

This build log reads:

--8<---------------cut here---------------start------------->8---
make[2]: Entering directory '/tmp/nix-build-shadow-4.1.5.1.drv-2/source/po'
test ! -f ./shadow.pot || \
  test -z "bs.gmo ca.gmo cs.gmo da.gmo de.gmo dz.gmo el.gmo es.gmo eu.gmo 
fi.gmo fr.gmo gl.gmo he.gmo hu.gmo id.gmo it.gmo ja.gmo kk.gmo km.gmo ko.gmo 
nb.gmo ne.gmo nl.gmo nn.gmo pl.gmo pt.gmo pt_BR.gmo ro.gmo ru.gmo sk.gmo sq.gmo 
sv.gmo tl.gmo tr.gmo uk.gmo vi.gmo zh_CN.gmo zh_TW.gmo" || make bs.gmo ca.gmo 
cs.gmo da.gmo de.gmo dz.gmo el.gmo es.gmo eu.gmo fi.gmo fr.gmo gl.gmo he.gmo 
hu.gmo id.gmo it.gmo ja.gmo kk.gmo km.gmo ko.gmo nb.gmo ne.gmo nl.gmo nn.gmo 
pl.gmo pt.gmo pt_BR.gmo ro.gmo ru.gmo sk.gmo sq.gmo sv.gmo tl.gmo tr.gmo uk.gmo 
vi.gmo zh_CN.gmo zh_TW.gmo
make[3]: Entering directory '/tmp/nix-build-shadow-4.1.5.1.drv-2/source/po'
: --update --previous bs.po shadow.pot
: --update --previous ca.po shadow.pot
: --update --previous cs.po shadow.pot
: --update --previous da.po shadow.pot
: --update --previous dz.po shadow.pot
: --update --previous de.po shadow.pot
rm -f el.gmo && : -c --statistics -o el.gmo el.po
rm -f es.gmo && : -c --statistics -o es.gmo es.po
mv: cannot stat 't-el.gmo': No such file or directory
Makefile:234: recipe for target 'el.gmo' failed
make[3]: *** [el.gmo] Error 1
--8<---------------cut here---------------end--------------->8---

Obviously it fails because Gettext is not an input.

Conversely, the build log on my machine shows:

--8<---------------cut here---------------start------------->8---
make[2]: Entering directory '/tmp/nix-build-shadow-4.1.5.1.drv-0/source/po'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/tmp/nix-build-shadow-4.1.5.1.drv-0/source/po'
--8<---------------cut here---------------end--------------->8---

So it looks like a timestamp issue.

I think the problem is that ‘copy-recursively’ doesn’t preserve
timestamps, which leads to non-determinism (whereas when building from a
tarball, ‘tar’ does preserve them.)

Can you try this patch:

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 51b40c8..84f86c5 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -201,7 +201,13 @@ client and server, a telnet client and server, and an rsh 
client and server.")
                       (delete-file (string-append bin "/groups"))
                       (for-each delete-file (find-files man "^groups\\."))
                       #t))
-                  %standard-phases))))
+                  (alist-cons-after
+                   'unpack
+                   (lambda _
+                     (for-each (lambda (file)
+                                 (utime file 0 0 0))
+                               (find-files "." "")))
+                   %standard-phases)))))
 
     (inputs (if (string-suffix? "-linux"
                                 (or (%current-target-system)
Unfortunately, the real fix is for ‘unpack’ in gnu-build-system.scm, so
it’ll have to wait until the next core-updates cycle.

Ludo’.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]