Seeking advice: preparing releases on GuixSD.

Seeking advice: preparing releases on GuixSD.

[ng0]

Hi,

my previous releases of gnurl (https://gnunet.org/gnurl) have
been tested on Gentoo and GuixSD and prepared to release only on
Gentoo, copied back to GuixSD and finished up on that GuixSD
system.
With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
I have to advice people to run ./buildconf again (essentially:
run autotools again), because of artifacts in shebangs and paths
of generated files.

I see three solutions right now:

 1. Opt out of the ./buildconf part and make it a responsibility
    of users and distributions to run it.

 2. Patch (adjust) maketgz, make dist, or any similar hook/script
    to my needs on GuixSD.

 3. Simply remove all occurences of any /gnu/store/… (if it's
    that simple) which could also happen in (2).


I hope I'm not the only person using GuixSD for releasing
software. How do you all deal with these shebangs and paths?

Thanks!
-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Alex Kost]

ng0 (2016-12-23 13:35 +0000) wrote:

> Hi,
>
> my previous releases of gnurl (https://gnunet.org/gnurl) have
> been tested on Gentoo and GuixSD and prepared to release only on
> Gentoo, copied back to GuixSD and finished up on that GuixSD
> system.
> With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
> I have to advice people to run ./buildconf again (essentially:
> run autotools again), because of artifacts in shebangs and paths
> of generated files.

Do you mean "configure" and "Makefile.in" files?  I don't see any
"/gnu/store" artifacts, if that's what you mean.

> I see three solutions right now:
>
>  1. Opt out of the ./buildconf part and make it a responsibility
>     of users and distributions to run it.
>
>  2. Patch (adjust) maketgz, make dist, or any similar hook/script
>     to my needs on GuixSD.
>
>  3. Simply remove all occurences of any /gnu/store/… (if it's
>     that simple) which could also happen in (2).
>
> I hope I'm not the only person using GuixSD for releasing
> software. How do you all deal with these shebangs and paths?

I made releases on GuixSD multiple times, but I've never faced the
problem you describe: "make dist" prepares system-independent files
without any artifacts AFAICT.

-- 
Alex

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Alex Kost <alezost@gmail.com> writes:

> ng0 (2016-12-23 13:35 +0000) wrote:
>
>> Hi,
>>
>> my previous releases of gnurl (https://gnunet.org/gnurl) have
>> been tested on Gentoo and GuixSD and prepared to release only on
>> Gentoo, copied back to GuixSD and finished up on that GuixSD
>> system.
>> With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
>> I have to advice people to run ./buildconf again (essentially:
>> run autotools again), because of artifacts in shebangs and paths
>> of generated files.
>
> Do you mean "configure" and "Makefile.in" files?  I don't see any
> "/gnu/store" artifacts, if that's what you mean.

Almost. What I mean is "Makefile", "configure", etc, everything
which is left when you have run the ./buildconf, configure, make,
make clean.
For the current release this gave me too many /gnu/store/… lines,
last release was better. I'm still trying to get away from the
manual release plan I was given by the person who did the
releases before me.

>> I see three solutions right now:
>>
>>  1. Opt out of the ./buildconf part and make it a responsibility
>>     of users and distributions to run it.
>>
>>  2. Patch (adjust) maketgz, make dist, or any similar hook/script
>>     to my needs on GuixSD.
>>
>>  3. Simply remove all occurences of any /gnu/store/… (if it's
>>     that simple) which could also happen in (2).
>>
>> I hope I'm not the only person using GuixSD for releasing
>> software. How do you all deal with these shebangs and paths?
>
> I made releases on GuixSD multiple times, but I've never faced the
> problem you describe: "make dist" prepares system-independent files
> without any artifacts AFAICT.

This depends on how your make dist is written doesn't it?
make dist is currently not completely functional here (or I need to
investigate if the failures are actually false ones) and the
"maketgz" script breaks because some binaries are not at /bin/*
and needs to be adjusted to gnurl needs as far as I know. So far
it was very manual what I did.

> -- 
> Alex
>

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

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


ng0 <ng0@libertad.pw> writes:

> my previous releases of gnurl (https://gnunet.org/gnurl) have
> been tested on Gentoo and GuixSD and prepared to release only on
> Gentoo, copied back to GuixSD and finished up on that GuixSD
> system.
> With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
> I have to advice people to run ./buildconf again (essentially:
> run autotools again), because of artifacts in shebangs and paths
> of generated files.

I cannot reproduce this.  After packaging roffit I ran this:

    guix environment gnurl --ad-hoc autoconf automake libtool roffit ghostscript
    ./buildconf
    ./configure --enable-ipv6 --with-gnutls --without-libssh2 \
                --without-libmetalink --without-winidn --without-librtmp \
                --without-nghttp2 --without-nss --without-cyassl \
                --without-polarssl --without-ssl --without-winssl \
                --without-darwinssl --disable-sspi --disable-ntlm-wb --disable-ldap \
                --disable-rtsp --disable-dict --disable-telnet --disable-tftp \
                --disable-pop3 --disable-imap --disable-smtp --disable-gopher \
                --disable-file --disable-ftp --disable-smb
    make dist

What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
specifies the version as a dash).  Unpacking it I see exactly *one*
reference to something in /gnu/store and that’s in “ltmain.sh”.

I haven’t tried the “maketgz” script because it contains references to
/usr/bin, but ultimately it runs “make dist” as well.

Attached is the patch to add roffit.


[-- Attachment #2: 0001-gnu-Add-roffit.patch --]
[-- Type: text/x-patch, Size: 2866 bytes --]

From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <rekado@elephly.net>
Date: Sat, 24 Dec 2016 11:12:45 +0100
Subject: [PATCH] gnu: Add roffit.

* gnu/packages/groff.scm (roffit): New variable.
---
 gnu/packages/groff.scm | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/gnu/packages/groff.scm b/gnu/packages/groff.scm
index 93d0380..2509a78 100644
--- a/gnu/packages/groff.scm
+++ b/gnu/packages/groff.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2014 Mark H Weaver <mhw@netris.org>
+;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,6 +22,7 @@
   #:use-module (guix licenses)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
   #:use-module (gnu packages bison)
@@ -56,3 +58,42 @@ formatted output based on formatting commands contained within the text.  It
 is usually the formatter of \"man\" documentation pages.")
    (license gpl3+)
    (home-page "http://www.gnu.org/software/groff/")))
+
+;; There are no releases, so we take the latest commit.
+(define-public roffit
+  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
+        (revision "1"))
+    (package
+      (name "roffit")
+      (version (string-append "0.11-" revision "." (string-take commit 9)))
+      (source (origin
+                (method git-fetch)
+                (uri (git-reference
+                      (url "https://github.com/bagder/roffit.git")
+                      (commit commit)))
+                (file-name (string-append "roffit-" commit "-checkout"))
+                (sha256
+                 (base32
+                  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"))))
+      (build-system gnu-build-system)
+      (arguments
+       `(#:test-target "test"
+         #:make-flags
+         (list (string-append "INSTALLDIR="
+                              (assoc-ref %outputs "out") "/bin"))
+         #:phases
+         (modify-phases %standard-phases
+           (delete 'configure)
+           (add-before 'install 'pre-install
+             (lambda* (#:key outputs #:allow-other-keys)
+               (mkdir-p (string-append (assoc-ref outputs "out")
+                                       "/bin"))
+               #t)))))
+      (inputs
+       `(("perl" ,perl)))
+      (home-page "https://daniel.haxx.se/projects/roffit/")
+      (synopsis "Convert nroff files to HTML")
+      (description
+       "Roffit is a program that reads an nroff file and outputs an HTML file.
+It is typically used to display man pages on a Web site.")
+      (license expat))))
-- 
2.10.2


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


-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ng0@libertad.pw> writes:
>
>> my previous releases of gnurl (https://gnunet.org/gnurl) have
>> been tested on Gentoo and GuixSD and prepared to release only on
>> Gentoo, copied back to GuixSD and finished up on that GuixSD
>> system.
>> With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
>> I have to advice people to run ./buildconf again (essentially:
>> run autotools again), because of artifacts in shebangs and paths
>> of generated files.
>
> I cannot reproduce this.  After packaging roffit I ran this:
>
>     guix environment gnurl --ad-hoc autoconf automake libtool roffit ghostscript
>     ./buildconf
>     ./configure --enable-ipv6 --with-gnutls --without-libssh2 \
>                 --without-libmetalink --without-winidn --without-librtmp \
>                 --without-nghttp2 --without-nss --without-cyassl \
>                 --without-polarssl --without-ssl --without-winssl \
>                 --without-darwinssl --disable-sspi --disable-ntlm-wb --disable-ldap \
>                 --disable-rtsp --disable-dict --disable-telnet --disable-tftp \
>                 --disable-pop3 --disable-imap --disable-smtp --disable-gopher \
>                 --disable-file --disable-ftp --disable-smb
>     make dist
>
> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
> specifies the version as a dash).  Unpacking it I see exactly *one*
> reference to something in /gnu/store and that’s in “ltmain.sh”.

Hm.. that's what I had too before I asked here, I just felt there
must be 0 occurences of /gnu/store.

> I haven’t tried the “maketgz” script because it contains references to
> /usr/bin, but ultimately it runs “make dist” as well.
>
> Attached is the patch to add roffit.

I keep roffit here: https://pagure.io/packages I just felt no
need to add it so far.

> From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Sat, 24 Dec 2016 11:12:45 +0100
> Subject: [PATCH] gnu: Add roffit.
>
> * gnu/packages/groff.scm (roffit): New variable.
> ---
>  gnu/packages/groff.scm | 41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>
> diff --git a/gnu/packages/groff.scm b/gnu/packages/groff.scm
> index 93d0380..2509a78 100644
> --- a/gnu/packages/groff.scm
> +++ b/gnu/packages/groff.scm
> @@ -1,6 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
>  ;;; Copyright © 2014 Mark H Weaver <mhw@netris.org>
> +;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -21,6 +22,7 @@
>    #:use-module (guix licenses)
>    #:use-module (guix packages)
>    #:use-module (guix download)
> +  #:use-module (guix git-download)
>    #:use-module (guix build-system gnu)
>    #:use-module (gnu packages)
>    #:use-module (gnu packages bison)
> @@ -56,3 +58,42 @@ formatted output based on formatting commands contained within the text.  It
>  is usually the formatter of \"man\" documentation pages.")
>     (license gpl3+)
>     (home-page "http://www.gnu.org/software/groff/")))
> +
> +;; There are no releases, so we take the latest commit.
> +(define-public roffit
> +  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
> +        (revision "1"))
> +    (package
> +      (name "roffit")
> +      (version (string-append "0.11-" revision "." (string-take commit 9)))
> +      (source (origin
> +                (method git-fetch)
> +                (uri (git-reference
> +                      (url "https://github.com/bagder/roffit.git")
> +                      (commit commit)))
> +                (file-name (string-append "roffit-" commit "-checkout"))
> +                (sha256
> +                 (base32
> +                  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"))))
> +      (build-system gnu-build-system)
> +      (arguments
> +       `(#:test-target "test"
> +         #:make-flags
> +         (list (string-append "INSTALLDIR="
> +                              (assoc-ref %outputs "out") "/bin"))
> +         #:phases
> +         (modify-phases %standard-phases
> +           (delete 'configure)
> +           (add-before 'install 'pre-install
> +             (lambda* (#:key outputs #:allow-other-keys)
> +               (mkdir-p (string-append (assoc-ref outputs "out")
> +                                       "/bin"))
> +               #t)))))
> +      (inputs
> +       `(("perl" ,perl)))
> +      (home-page "https://daniel.haxx.se/projects/roffit/")
> +      (synopsis "Convert nroff files to HTML")
> +      (description
> +       "Roffit is a program that reads an nroff file and outputs an HTML file.
> +It is typically used to display man pages on a Web site.")
> +      (license expat))))
> -- 
> 2.10.2
>
>
> -- 
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> http://elephly.net

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0 <ng0@libertad.pw> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
>> specifies the version as a dash).  Unpacking it I see exactly *one*
>> reference to something in /gnu/store and that’s in “ltmain.sh”.
>
> Hm.. that's what I had too before I asked here, I just felt there
> must be 0 occurences of /gnu/store.

You wrote earlier:

> 3. Simply remove all occurences of any /gnu/store/… (if it's
>    that simple) which could also happen in (2).

That made it sound like there are countless references that need to be
corrected somehow.

“ltmain.sh” is instantiated from a template by libtool.  It originally
contains a /bin/sh shebang, and I think it should not be patched when
installed to

    /gnu/store/…-libtool-2.4.6/share/libtool/build-aux/ltmain.sh

This seems like a bug to me.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ng0@libertad.pw> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
>>> specifies the version as a dash).  Unpacking it I see exactly *one*
>>> reference to something in /gnu/store and that’s in “ltmain.sh”.
>>
>> Hm.. that's what I had too before I asked here, I just felt there
>> must be 0 occurences of /gnu/store.
>
> You wrote earlier:
>
>> 3. Simply remove all occurences of any /gnu/store/… (if it's
>>    that simple) which could also happen in (2).
>
> That made it sound like there are countless references that need to be
> corrected somehow.

Well in 7.52.0 there are more than 1 reference to /gnu/store, and
in 7.52.1 there were more than in 7.52.0 simply because I did not
have the time to investigate what's wrong now.

> “ltmain.sh” is instantiated from a template by libtool.  It originally
> contains a /bin/sh shebang, and I think it should not be patched when
> installed to

So I can assume that just changing the shebang in ltmain.sh back
to /bin/sh is enough to make it distributable again, or is
ltmain.sh something distributions have anyway and the local file
is "just there"?
I just stepped in for gnurl and I'm picking up what needs to be
done while I'm working with it, so far learning in-depth
autotools + Makefile is still on my TODO list.

>     /gnu/store/…-libtool-2.4.6/share/libtool/build-aux/ltmain.sh
>
> This seems like a bug to me.
>
> -- 
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> http://elephly.net
>
>

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0 <ng0@libertad.pw> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> ng0 <ng0@libertad.pw> writes:
>>
>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>
>>>> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
>>>> specifies the version as a dash).  Unpacking it I see exactly *one*
>>>> reference to something in /gnu/store and that’s in “ltmain.sh”.
>>>
>>> Hm.. that's what I had too before I asked here, I just felt there
>>> must be 0 occurences of /gnu/store.
>>
>> You wrote earlier:
>>
>>> 3. Simply remove all occurences of any /gnu/store/… (if it's
>>>    that simple) which could also happen in (2).
>>
>> That made it sound like there are countless references that need to be
>> corrected somehow.
>
> Well in 7.52.0 there are more than 1 reference to /gnu/store, and
> in 7.52.1 there were more than in 7.52.0 simply because I did not
> have the time to investigate what's wrong now.

If you did what I did on GuixSD (exact sequence in my previous email) I
don’t see how there could have been any more references to store items.

>> “ltmain.sh” is instantiated from a template by libtool.  It originally
>> contains a /bin/sh shebang, and I think it should not be patched when
>> installed to
>
> So I can assume that just changing the shebang in ltmain.sh back
> to /bin/sh is enough to make it distributable again, or is
> ltmain.sh something distributions have anyway and the local file
> is "just there"?

ltmain.sh is included by “make dist”, so it’s supposed to be
distributed.  One of the big ideas of autotools is that users don’t have
to have autotools to build a release tarball.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ng0@libertad.pw> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> ng0 <ng0@libertad.pw> writes:
>>>
>>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>>
>>>>> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
>>>>> specifies the version as a dash).  Unpacking it I see exactly *one*
>>>>> reference to something in /gnu/store and that’s in “ltmain.sh”.
>>>>
>>>> Hm.. that's what I had too before I asked here, I just felt there
>>>> must be 0 occurences of /gnu/store.
>>>
>>> You wrote earlier:
>>>
>>>> 3. Simply remove all occurences of any /gnu/store/… (if it's
>>>>    that simple) which could also happen in (2).
>>>
>>> That made it sound like there are countless references that need to be
>>> corrected somehow.
>>
>> Well in 7.52.0 there are more than 1 reference to /gnu/store, and
>> in 7.52.1 there were more than in 7.52.0 simply because I did not
>> have the time to investigate what's wrong now.
>
> If you did what I did on GuixSD (exact sequence in my previous email) I
> don’t see how there could have been any more references to store items.

More or less, the tl;dr of updates right now is:
old=7_50_1
new=7_50_2
git checkout upstream/master; git pull; git checkout -b gnurl-$new curl-$new # tag of desired version
git cherry-pick `git log gnurl-$old | head -n 1 | cut -c8-`
git mergetool # or whatever needs to be used to fix the broken ones
git cherry-pick --continue

# run the guix-gnurl.scm to test.

./buildconf
./configure --enable-ipv6 --with-gnutls --without-libssh2 --without-libmetalink \ 
--without-winidn --without-librtmp --without-nghttp2 --without-nss --without-cyassl \
--without-polarssl --without-ssl --without-winssl --without-darwinssl --disable-sspi \
--disable-ntlm-wb --disable-ldap --disable-rtsp --disable-dict --disable-telnet --disable-tftp \
--disable-pop3 --disable-imap --disable-smtp --disable-gopher \
--disable-file --disable-ftp --disable-smb
make
make clean

git push -f origin gnurl-$new:master
git diff HEAD^ HEAD >..&gnurl-$new.diff
cp -a . ../gnurl-$new
cd ..
rm -rf gnurl-$new/.git
tar cjf gnurl-$new.tar.bz2 gnurl-$new
rm -rf gnurl-$new
gpg --detach-sig gnurl-$new.tar.bz2
# login to gnunet.org and upload them

Where some parts of this manual procedure have been changed now.
I'll try a simple `make dist` next time.

I will compare my nroff or whatever it was called package with
yours and see if there's anything left to add, if you think it
should go into guix, it's good for me.

>>> “ltmain.sh” is instantiated from a template by libtool.  It originally
>>> contains a /bin/sh shebang, and I think it should not be patched when
>>> installed to
>>
>> So I can assume that just changing the shebang in ltmain.sh back
>> to /bin/sh is enough to make it distributable again, or is
>> ltmain.sh something distributions have anyway and the local file
>> is "just there"?
>
> ltmain.sh is included by “make dist”, so it’s supposed to be
> distributed.  One of the big ideas of autotools is that users don’t have
> to have autotools to build a release tarball.
>
> -- 
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> http://elephly.net
>
>

So the changed shebang in the ltmain.sh is a bug on my side or in
the autotools in Guix? I'm not looking at the sources right now,
but I think I could simply add a line (for make dist) which
changes the shebang back to /bin/sh before assembling the
tarball. After all it's just a shebang.

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ng0@libertad.pw> writes:
>
>> my previous releases of gnurl (https://gnunet.org/gnurl) have
>> been tested on Gentoo and GuixSD and prepared to release only on
>> Gentoo, copied back to GuixSD and finished up on that GuixSD
>> system.

> Attached is the patch to add roffit.
>
> From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Sat, 24 Dec 2016 11:12:45 +0100
> Subject: [PATCH] gnu: Add roffit.
>
> * gnu/packages/groff.scm (roffit): New variable.
> ---
>  gnu/packages/groff.scm | 41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>
> diff --git a/gnu/packages/groff.scm b/gnu/packages/groff.scm
> index 93d0380..2509a78 100644
> --- a/gnu/packages/groff.scm
> +++ b/gnu/packages/groff.scm
> @@ -1,6 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
>  ;;; Copyright © 2014 Mark H Weaver <mhw@netris.org>
> +;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -21,6 +22,7 @@
>    #:use-module (guix licenses)
>    #:use-module (guix packages)
>    #:use-module (guix download)
> +  #:use-module (guix git-download)
>    #:use-module (guix build-system gnu)
>    #:use-module (gnu packages)
>    #:use-module (gnu packages bison)
> @@ -56,3 +58,42 @@ formatted output based on formatting commands contained within the text.  It
>  is usually the formatter of \"man\" documentation pages.")
>     (license gpl3+)
>     (home-page "http://www.gnu.org/software/groff/")))
> +
> +;; There are no releases, so we take the latest commit.
> +(define-public roffit
> +  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
> +        (revision "1"))
> +    (package
> +      (name "roffit")
> +      (version (string-append "0.11-" revision "." (string-take commit 9)))
> +      (source (origin
> +                (method git-fetch)
> +                (uri (git-reference
> +                      (url "https://github.com/bagder/roffit.git")
> +                      (commit commit)))
> +                (file-name (string-append "roffit-" commit "-checkout"))
> +                (sha256
> +                 (base32
> +                  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"))))
> +      (build-system gnu-build-system)
> +      (arguments
> +       `(#:test-target "test"
> +         #:make-flags
> +         (list (string-append "INSTALLDIR="
> +                              (assoc-ref %outputs "out") "/bin"))
> +         #:phases
> +         (modify-phases %standard-phases
> +           (delete 'configure)
> +           (add-before 'install 'pre-install
> +             (lambda* (#:key outputs #:allow-other-keys)
> +               (mkdir-p (string-append (assoc-ref outputs "out")
> +                                       "/bin"))
> +               #t)))))

My only difference is in the (arguments), where I do:

      (arguments
       `(#:test-target "test"
         #:phases
         (modify-phases %standard-phases
           (replace 'configure ; No configure phase
             (lambda* (#:key outputs #:allow-other-keys)
               (let* ((out  (assoc-ref outputs "out"))
                      (bin  (string-append out "/bin/")))
                 (substitute* "Makefile"
                   (("/usr/local/bin")
                    bin))
               (mkdir-p bin))))
           (add-after 'install 'wrap-programs
             (lambda* (#:key outputs #:allow-other-keys)
               ;; Make sure all executables in "bin" find the Perl modules
               ;; provided by this package at runtime.
               (let* ((out  (assoc-ref outputs "out"))
                      (bin  (string-append out "/bin/"))
                      (path (getenv "PERL5LIB")))
                 (for-each (lambda (file)
                             (wrap-program file
                               `("PERL5LIB" ":" prefix (,path))))
                           (find-files bin "\\.*$"))
                 #t))))))


Your synopsis and description are better than mine, otherwise the
packages are almost identical.

> +      (inputs
> +       `(("perl" ,perl)))
> +      (home-page "https://daniel.haxx.se/projects/roffit/")
> +      (synopsis "Convert nroff files to HTML")
> +      (description
> +       "Roffit is a program that reads an nroff file and outputs an HTML file.
> +It is typically used to display man pages on a Web site.")
> +      (license expat))))
> -- 
> 2.10.2
>
>
> -- 
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> http://elephly.net

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0 <ng0@libertad.pw> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
[…]
>> From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus <rekado@elephly.net>
>> Date: Sat, 24 Dec 2016 11:12:45 +0100
>> Subject: [PATCH] gnu: Add roffit.
>>
>> * gnu/packages/groff.scm (roffit): New variable.
[…]
>> +;; There are no releases, so we take the latest commit.
>> +(define-public roffit
>> +  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
>> +        (revision "1"))
>> +    (package
>> +      (name "roffit")
>> +      (version (string-append "0.11-" revision "." (string-take commit 9)))
>> +      (source (origin
>> +                (method git-fetch)
>> +                (uri (git-reference
>> +                      (url "https://github.com/bagder/roffit.git")
>> +                      (commit commit)))
>> +                (file-name (string-append "roffit-" commit "-checkout"))
>> +                (sha256
>> +                 (base32
>> +                  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"))))
>> +      (build-system gnu-build-system)
>> +      (arguments
>> +       `(#:test-target "test"
>> +         #:make-flags
>> +         (list (string-append "INSTALLDIR="
>> +                              (assoc-ref %outputs "out") "/bin"))
>> +         #:phases
>> +         (modify-phases %standard-phases
>> +           (delete 'configure)
>> +           (add-before 'install 'pre-install
>> +             (lambda* (#:key outputs #:allow-other-keys)
>> +               (mkdir-p (string-append (assoc-ref outputs "out")
>> +                                       "/bin"))
>> +               #t)))))
>
> My only difference is in the (arguments), where I do:
>
>       (arguments
>        `(#:test-target "test"
>          #:phases
>          (modify-phases %standard-phases
>            (replace 'configure ; No configure phase
>              (lambda* (#:key outputs #:allow-other-keys)
>                (let* ((out  (assoc-ref outputs "out"))
>                       (bin  (string-append out "/bin/")))
>                  (substitute* "Makefile"
>                    (("/usr/local/bin")
>                     bin))

That’s not necessary, because we can override INSTALLDIR.

>                (mkdir-p bin))))
>            (add-after 'install 'wrap-programs
>              (lambda* (#:key outputs #:allow-other-keys)
>                ;; Make sure all executables in "bin" find the Perl modules
>                ;; provided by this package at runtime.
>                (let* ((out  (assoc-ref outputs "out"))
>                       (bin  (string-append out "/bin/"))
>                       (path (getenv "PERL5LIB")))
>                  (for-each (lambda (file)
>                              (wrap-program file
>                                `("PERL5LIB" ":" prefix (,path))))
>                            (find-files bin "\\.*$"))
>                  #t))))))

Why would this be necessary?  There are no Perl packages among the
inputs.

-- 
Ricardo
  
  GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
  http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ng0@libertad.pw> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
> […]
>>> From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
>>> From: Ricardo Wurmus <rekado@elephly.net>
>>> Date: Sat, 24 Dec 2016 11:12:45 +0100
>>> Subject: [PATCH] gnu: Add roffit.
>>>
>>> * gnu/packages/groff.scm (roffit): New variable.
> […]
>>> +;; There are no releases, so we take the latest commit.
>>> +(define-public roffit
>>> +  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
>>> +        (revision "1"))
>>> +    (package
>>> +      (name "roffit")
>>> +      (version (string-append "0.11-" revision "." (string-take commit 9)))
>>> +      (source (origin
>>> +                (method git-fetch)
>>> +                (uri (git-reference
>>> +                      (url "https://github.com/bagder/roffit.git")
>>> +                      (commit commit)))
>>> +                (file-name (string-append "roffit-" commit "-checkout"))
>>> +                (sha256
>>> +                 (base32
>>> +                  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"))))
>>> +      (build-system gnu-build-system)
>>> +      (arguments
>>> +       `(#:test-target "test"
>>> +         #:make-flags
>>> +         (list (string-append "INSTALLDIR="
>>> +                              (assoc-ref %outputs "out") "/bin"))
>>> +         #:phases
>>> +         (modify-phases %standard-phases
>>> +           (delete 'configure)
>>> +           (add-before 'install 'pre-install
>>> +             (lambda* (#:key outputs #:allow-other-keys)
>>> +               (mkdir-p (string-append (assoc-ref outputs "out")
>>> +                                       "/bin"))
>>> +               #t)))))
>>
>> My only difference is in the (arguments), where I do:
>>
>>       (arguments
>>        `(#:test-target "test"
>>          #:phases
>>          (modify-phases %standard-phases
>>            (replace 'configure ; No configure phase
>>              (lambda* (#:key outputs #:allow-other-keys)
>>                (let* ((out  (assoc-ref outputs "out"))
>>                       (bin  (string-append out "/bin/")))
>>                  (substitute* "Makefile"
>>                    (("/usr/local/bin")
>>                     bin))
>
> That’s not necessary, because we can override INSTALLDIR.

Okay, I didn't give my package much attention it was done in 5
minutes.

>>                (mkdir-p bin))))
>>            (add-after 'install 'wrap-programs
>>              (lambda* (#:key outputs #:allow-other-keys)
>>                ;; Make sure all executables in "bin" find the Perl modules
>>                ;; provided by this package at runtime.
>>                (let* ((out  (assoc-ref outputs "out"))
>>                       (bin  (string-append out "/bin/"))
>>                       (path (getenv "PERL5LIB")))
>>                  (for-each (lambda (file)
>>                              (wrap-program file
>>                                `("PERL5LIB" ":" prefix (,path))))
>>                            (find-files bin "\\.*$"))
>>                  #t))))))
>
> Why would this be necessary?  There are no Perl packages among the
> inputs.

True. Okay, thanks for pushing this.
That leaves one question open from my previous message (about
ltmain.sh), but I don't need/want an immediate reply.

> -- 
> Ricardo
>   
>   GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>   http://elephly.net
>
>

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0 <ng0@libertad.pw> writes:

> So the changed shebang in the ltmain.sh is a bug on my side or in
> the autotools in Guix?

Looks like a bug in how we install the file when building libtool.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> ng0 <ng0@libertad.pw> writes:
>
>> So the changed shebang in the ltmain.sh is a bug on my side or in
>> the autotools in Guix?
>
> Looks like a bug in how we install the file when building libtool.
>
> -- 
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> http://elephly.net
>
>

As it's a shebang, is it as easy as adding back the original
state of the shebang after the shebang phases have run?
-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: Seeking advice: preparing releases on GuixSD.

[Ludovic Courtès]

Hi!

Ricardo Wurmus <rekado@elephly.net> skribis:

> “ltmain.sh” is instantiated from a template by libtool.  It originally
> contains a /bin/sh shebang, and I think it should not be patched when
> installed to
>
>     /gnu/store/…-libtool-2.4.6/share/libtool/build-aux/ltmain.sh
>
> This seems like a bug to me.

Definitely:

--8<---------------cut here---------------start------------->8---
$ head -1 $(find $(guix build libtool) -name ltmain.sh)
#!/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh
--8<---------------cut here---------------end--------------->8---

Opening a new bug now.  This is with v0.12.0-176-ge087671.

Ludo’.

bug#25304: Seeking advice: preparing releases on GuixSD.

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> “ltmain.sh” is instantiated from a template by libtool.  It originally
>> contains a /bin/sh shebang, and I think it should not be patched when
>> installed to
>>
>>     /gnu/store/…-libtool-2.4.6/share/libtool/build-aux/ltmain.sh
>>
>> This seems like a bug to me.
>
> Definitely:
>
> $ head -1 $(find $(guix build libtool) -name ltmain.sh)
> #!/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/sh
>
> Opening a new bug now.  This is with v0.12.0-176-ge087671.

This was fixed by ng0 in 98341757c8c45fca8d2b53f9972f5c6a32cf2c95.

Ludo’.

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

[Ludovic Courtès]

Hi,

Commit 98341757c8c45fca8d2b53f9972f5c6a32cf2c95, which was meant to fix
this bug¹, actually failed to do so:

--8<---------------cut here---------------start------------->8---
$ head -1 $(./pre-inst-env guix build libtool)/share/libtool/build-aux/ltmain.sh
#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/sh
$ git describe
v0.12.0-3136-g7312c62d3
--8<---------------cut here---------------end--------------->8---

I think the problem is that we’re patching ltmain.in when we should
really be patching the final file, after the ‘patch-shebangs’ phase.

Ludo’.

¹ <http://bugs.gnu.org/25304>

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

[Miguel Ángel Arruga Vivas]

[-- Attachment #1.1: Type: text/plain, Size: 784 bytes --]

Hi,

I was looking through the lists because I have a patch that does exactly
what you describe here.  I guess this goes to core updates, so this
version is on top of it.  WDYT?

Happy hacking!
Miguel

ludo@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> Commit 98341757c8c45fca8d2b53f9972f5c6a32cf2c95, which was meant to fix
> this bug¹, actually failed to do so:
>
> $ head -1 $(./pre-inst-env guix build libtool)/share/libtool/build-aux/ltmain.sh
> #!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/sh
> $ git describe
> v0.12.0-3136-g7312c62d3
>
> I think the problem is that we’re patching ltmain.in when we should
> really be patching the final file, after the ‘patch-shebangs’ phase.
>
> Ludo’.
>
> ¹ <http://bugs.gnu.org/25304>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-libtoolize.patch --]
[-- Type: text/x-patch, Size: 2039 bytes --]

From 145273418d3131bcf3b73d416d19f641645cf3f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
 <rosen644835@gmail.com>
Date: Fri, 13 Nov 2020 15:24:46 +0100
Subject: [PATCH] gnu: libtool: Restore shebangs on all libtoolize files.

* gnu/packages/autotools.scm (libtool)[restore-build-aux-shebang]: New
phase after install.
[restore-ltmain-shebang]: Remove phase, it is now performed by the phase
restore-build-aux-shebang.
---
 gnu/packages/autotools.scm | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/autotools.scm b/gnu/packages/autotools.scm
index 96f2925180..c9e1c9bcf1 100644
--- a/gnu/packages/autotools.scm
+++ b/gnu/packages/autotools.scm
@@ -444,11 +444,19 @@ Makefile, simplifying the entire process for the developer.")
                (("/bin/sh")
                 (string-append bash "/bin/sh")))
              #t)))
-         (add-after 'patch-source-shebangs 'restore-ltmain-shebang
-           (lambda* (#:key inputs #:allow-other-keys)
-             (substitute* "build-aux/ltmain.in"
-               (("^#!.*/bin/sh$") "#!/bin/sh"))
-             #t)))))
+         ;; These files may be copied into source trees by libtoolize,
+         ;; therefore they must not point to store file names that would be
+         ;; leaked with tarballs generated by make dist.
+         (add-after 'install 'restore-build-aux-shebang
+           (lambda* (#:key outputs #:allow-other-keys)
+             (let* ((out (assoc-ref outputs "out"))
+                    (dir (string-append out "/share/libtool/build-aux")))
+               (for-each (lambda (file)
+                           (format #t "restoring shebang on `~a'~%" file)
+                           (substitute* file
+                             (("^#!.*/bin/sh") "#!/bin/sh")))
+                         (find-files dir ".*"))
+               #t))))))
 
     (synopsis "Generic shared library support tools")
     (description
-- 
2.29.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

[Ludovic Courtès]

Hi!

Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:

> I was looking through the lists because I have a patch that does exactly
> what you describe here.  I guess this goes to core updates, so this
> version is on top of it.  WDYT?

Yes, looks like a change for ‘core-updates’.

> From 145273418d3131bcf3b73d416d19f641645cf3f8 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
>  <rosen644835@gmail.com>
> Date: Fri, 13 Nov 2020 15:24:46 +0100
> Subject: [PATCH] gnu: libtool: Restore shebangs on all libtoolize files.

You can add “Fixes <https://bugs.gnu.org/25304>.”

> * gnu/packages/autotools.scm (libtool)[restore-build-aux-shebang]: New
> phase after install.
> [restore-ltmain-shebang]: Remove phase, it is now performed by the phase
> restore-build-aux-shebang.

LGTM, thanks for digging through old bugs!

Ludo’.

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

[Miguel Ángel Arruga Vivas]

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

Hi!

Ludovic Courtès <ludo@gnu.org> writes:
> Hi!
>
> Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:
>
>> I was looking through the lists because I have a patch that does exactly
>> what you describe here.  I guess this goes to core updates, so this
>> version is on top of it.  WDYT?
>
> Yes, looks like a change for ‘core-updates’.
>
>> From 145273418d3131bcf3b73d416d19f641645cf3f8 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
>>  <rosen644835@gmail.com>
>> Date: Fri, 13 Nov 2020 15:24:46 +0100
>> Subject: [PATCH] gnu: libtool: Restore shebangs on all libtoolize files.
>
> You can add “Fixes <https://bugs.gnu.org/25304>.”
>
>> * gnu/packages/autotools.scm (libtool)[restore-build-aux-shebang]: New
>> phase after install.
>> [restore-ltmain-shebang]: Remove phase, it is now performed by the phase
>> restore-build-aux-shebang.
>
> LGTM, thanks for digging through old bugs!
>
> Ludo’.

Pushed as 8d263ff254292c9e13a9848f90b52263da52d570 to core-updates with
that line added.  Thanks for the quick review.  :-)

Happy hacking!
Miguel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]