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

[ludo@gnu.org (Ludovic Courtès)]

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

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 858 bytes --]

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)

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]


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’.