From: ludo@gnu.org (Ludovic Courtès)
To: Mike Gerwitz <mtg@gnu.org>
Cc: guix-devel@gnu.org, maintainers@gnu.org
Subject: Re: gnumaint changes
Date: Thu, 12 Jul 2018 17:57:01 +0200 [thread overview]
Message-ID: <87wou0tpki.fsf@gnu.org> (raw)
In-Reply-To: <87fu0p5fpb.fsf@gnu.org> (Mike Gerwitz's message of "Wed, 11 Jul 2018 22:51:44 -0400")
Hello,
Mike Gerwitz <mtg@gnu.org> skribis:
>> It’d be nice if synopses and descriptions in the Womb could contain
>> Texinfo markup.
>>
>> In fact, perhaps it’d make sense to reverse the roles, i.e., have the
>> Womb take (some of its) descriptions from Guix?
>
> `blub' in pkgblurbs (which is what `official-description' uses) is
> provided by package authors after they've been dubbed by rms. That is
> in turn used on gnu.org. Consequently, I think it's best to have such
> blurbs maintained independently of guix.
I see, that makes sense.
> What sort of Texinfo markup are you looking for, and are we talking
> about the same field? What field does guix use for the synopsis?
> Everything in rec/gnupackages.rec is handled by us at maintainers@, so
> we can do whatever we want there.
For packages we occasionally use Texinfo markup, typically ornaments
like @code or @itemize bullet lists. Not every synopsis/description
needs it, but it’s nice to be able to use it.
> Do you have a couple examples of what you think would be beneficial to
> pull form Guix? I'm certainly open to the idea where it makes sense;
> there's no sense in us duplicating effort within GNU unnecessarily.
I realize that Guix doesn’t have all GNU packages yet so in fact there’s
not so much to pull from at this point. I was suspecting blurbs are
likely to be more up-to-date in Guix, but that’s very subjective, I
don’t know if this is the case.
> I'm also working on automating parts of our recordkeeping: in the next
> few weeks, Womb will have up-to-date version information automatically
> pulled from info-gnu release announcements; the FTP server; and a couple
> websites where necessary, though I'll be manually committing it for the
> first few months to verify that it is all working properly. So Guix
> might also be able to depend on rec/gnupackages.rec for checking for new
> releases as well, since unfortunately GNU doesn't mandate the use of the
> FTP server, or even info-gnu (so releases are all over the place).
The (guix gnu-maintenance) modules are tools to retrieve the latest
version of a GNU package by traversing its ftp.gnu.org (or similar)
directory. That’s something you might find useful. Here’s an example:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(gnu packages gcc)
scheme@(guile-user)> ,use(guix upstream)
scheme@(guile-user)> (package-latest-release gcc (force %updaters))
$4 = #<<upstream-source> package: "gcc" version: "8.1.0" urls: ("mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.xz" "mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.gz") signature-urls: ("mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.xz.sig" "mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.gz.sig")>
--8<---------------cut here---------------end--------------->8---
Or simply:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix gnu-maintenance)
scheme@(guile-user)> (latest-release "emacs")
$5 = #<<upstream-source> package: "emacs" version: "26.1" urls: ("ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.xz" "ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.gz") signature-urls: ("ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.xz.sig" "ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.gz.sig")>
--8<---------------cut here---------------end--------------->8---
This relies primarily on <https://ftp.gnu.org/find.txt.gz>.
Packages not hosted on gnu.org are typically annotated with the download
URL such that the update-checking code does the right thing.
Thanks,
Ludo’.
next prev parent reply other threads:[~2018-07-12 15:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 8:23 gnumaint changes Nils Gillmann
2018-06-27 20:36 ` Ludovic Courtès
2018-06-28 4:52 ` Nils Gillmann
2018-06-28 1:40 ` Mike Gerwitz
2018-06-28 1:55 ` Mike Gerwitz
2018-07-11 14:11 ` Ludovic Courtès
2018-07-12 2:51 ` Mike Gerwitz
2018-07-12 15:57 ` Ludovic Courtès [this message]
2018-07-12 16:32 ` Mike Gerwitz
2018-07-13 10:24 ` Nils Gillmann
2018-07-13 12:01 ` Ludovic Courtès
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=87wou0tpki.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=maintainers@gnu.org \
--cc=mtg@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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).