[bug#69661] [PATCH] gnu: Add redo-apenwarr

[Skyler Ferris]

    On 3/12/24 08:39, Massimo Zaniboni wrote:

> 2) I don't consider this PATCH definitive, because: I can improve the
> way I generate documentation; I'm not using the package enough in
> production for being sure it is completely correct; a part of the
> package is probably not optimal. I will send a candidate PATCH after
> more testing and eventually your next review.
>     
    Ok, I'll add the "moreinfo" tag to this issue until you indicate
    that it is ready for merging.
> Now I obtain
>
> ```
> $ make && ./pre-inst-env guix lint redo-apenwarr
>
> make  all-recursive
>
> ]8;;file://think/home/mzan/tmp/guix/guix-cloned-channel/gnu/packages/build-tools.scm\gnu/packages/build-tools.scm:471:7]8;;\:
> warning: failed to fetch Git repository for redo-apenwarr
> 
> ]8;;file://think/home/mzan/tmp/guix/guix-cloned-channel/gnu/packages/build-tools.scm\gnu/packages/build-tools.scm:471:7]8;;\:
> redo-apenwarr@0.42d: updater 'generic-git' failed to find upstream
> releasesmake && ./pre-inst-env guix build -K redo-apenwarr
> ```
>
> I have no idea how to fix them.
>     
    I'm not seeing this on my machine, just a couple of warnings about
    trailing whitespaces. Since it failed to fetch a resource over the
    network I'm wondering if this was a temporary error that was
    preventing your machine from reaching the server? Let me know if you
    still get this error after successfully cloning the repository from
    the same machine (manually, with `git clone`).
> I improved the package code and the comments. Probably now it is more
> clear.
>
> Put in other words: the redo-apenwarr installation script executes git
> commands for querying the git repo, and for deriving the date of the
> last commit. It uses this info for adding version/commit/date to the
> installed application.
>
> Apparently, after the Guix git-fetch phase, there is no anymore this
> info, because there is no .git directory. So I generate this info
> "manually".
>
> This "patch" is not elegant, and I'm open to suggestions about the
> correct way to handle this.
>     
    This is very strange. I have used git commands in build phases before and there was no issue. I was using the same git-fetch origin type. The git folder *should* be there but when I remove the relevant snippet from the build phase and run with --keep-failed it is not. I'll look at this more closely when I have some time.

> > Would it be possible for you to try sending the next
> > revision using `git send-email` as described by the manual
> > <https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html>?
> > Note that while the section is titled "Sending a Patch Series" it also
> > applies to sending single patches.
> >       
> DONE. I hope this time it will be better. But, it is the first time I'm
> using it.
>     
    Looks like it worked! I was able to apply the patch locally without
    modification and I see your complete commit message now.
    
    There are also a couple of small things about the new version of the
    patch that should be changed. In the PREFIX value for makeflags,
    "/out" should not be appended to #$output. This causes binaries to
    be installed to "out/bin" instead of "bin", so they are not actually
    in the path when users add the package to their profile. Also, since
    the build phase no longer uses the arguments given it can be a plain
    lambda instead of lambda*. You can include these changes when you
    send the next version that improves the documentation generation, no
    need to send an intermediate patch for these small changes.