From: ng0 <ng0@libertad.pw>
To: help-guix@gnu.org
Subject: Re: Seeking advice: preparing releases on GuixSD.
Date: Fri, 23 Dec 2016 17:34:11 +0000 [thread overview]
Message-ID: <87bmw2tur0.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <87pokishk6.fsf@gmail.com>
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
next prev parent reply other threads:[~2016-12-23 17:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-23 13:35 Seeking advice: preparing releases on GuixSD ng0
2016-12-23 17:04 ` Alex Kost
2016-12-23 17:34 ` ng0 [this message]
2016-12-24 10:13 ` Ricardo Wurmus
2016-12-24 14:45 ` ng0
2016-12-24 15:32 ` Ricardo Wurmus
2016-12-24 16:13 ` ng0
2016-12-24 16:23 ` Ricardo Wurmus
2016-12-24 16:34 ` ng0
2016-12-26 13:58 ` Ricardo Wurmus
2016-12-26 14:27 ` ng0
2016-12-30 23:34 ` Ludovic Courtès
2016-12-24 22:26 ` ng0
2016-12-25 12:37 ` Ricardo Wurmus
2016-12-26 12:41 ` ng0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bmw2tur0.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me \
--to=ng0@libertad.pw \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).