Re: Request: build package with source tarball

[Ryan Prior]

On Monday, September 12th, 2022 at 1:29 AM, Olivier Dion 
 wrote:


> It already can.
> 
> I use this in my Makefiles: [snip]

That's a solid approach with your makefile! I tried it yesterday with just the 
tar.gz and it didn't seem to work, but probably I misspelled something and then 
gave up too early. Just tried again and it's working as expected.

Thank you!
Ryan

Re: Request: build package with source tarball

[Development of GNU Guix and the GNU System distribution.]

On Mon, 12 Sep 2022, Ryan Prior  wrote:
> Hi there! Lately I've been testing distribution tarballs with a workflow like 
> this:
>
> - update some software in my source directory
> - create a distribution tarball
> - untar to a directory like /tmp/mypkg-src
> - run: guix build --with-source=mypkg=/tmp/mypkg-src​
>
> It would be nice to skip step 3 there and just run: guix build 
> --with-source=mypkg.tar.gz​
> Guix should then untar and use the result as the source directory for
> the build.

It already can.

I use this in my Makefiles:
--8<---cut here---start->8---
libpatch.tar.gz:
@git archive --format=tar.gz --prefix=libpatch/ \
--output $@ HEAD

guix-build: libpatch.tar.gz
@guix build --keep-failed --rounds=2 \
--with-source=libpatch=$^ libpatch
--8<---cut here---end--->8---

-- 
Olivier Dion
oldiob.dev

Request: build package with source tarball

[Ryan Prior]

Hi there! Lately I've been testing distribution tarballs with a workflow like 
this:

- update some software in my source directory
- create a distribution tarball
- untar to a directory like /tmp/mypkg-src
- run: guix build --with-source=mypkg=/tmp/mypkg-src​

It would be nice to skip step 3 there and just run: guix build 
--with-source=mypkg.tar.gz​
Guix should then untar and use the result as the source directory for the build.

To soup the process up even further, allow --with-source​ to take a URL of a 
tarball, in which case Guix fetches and untars. Then I could write a trivial 
local microservice which produces distribution tarballs on demand, allowing me 
to skip both steps 2 and 3. That would be a sweet workflow.

Ryan

Re: September update on bordeaux.guix.gnu.org

[John Kehayias]

Hi Chris,

On Sat, Sep 03, 2022 at 01:13 PM, Christopher Baines wrote:

> Hey,
>
> The last update was sent out in May [1], so this update roughly covers
> the last 3 months.
>
> 1: 
>
> This hasn't been my primary focus, so some of the changes that somewhat
> involve bordeaux.guix.gnu.org relate to using it for patch review, but
> to keep this update short I'll mention those elsewhere.
>

Thanks for these updates and all the work you do on these many fronts, much 
appreciated!

[snip]

> ## Mirrors
>
> There's a few test mirror machines setup, and I asked for people to test
> these to see what difference they make [2][3].
>
> 2: 
> 3: 
>
> A couple of responses [4][5] have come in to the mailing list, both of
> which seem to suggest that mirrors could provide a significant boost to
> substitute download speed.
>
> 4: 
> 5: 
>
> Those test servers have been running for a while now, and are generally
> unused. I'll probably shut them down shortly to save money, and try to
> send out a more concrete plan of getting mirrors in place for
> bordeaux.guix.gnu.org.
>

I wasn't sure if these mirrors were going to remain up and were usable, so I 
never actually configured my Guix machines to use them. I did make the main 
Bordeaux server first on my substitute list which has been a nice speedup.

Being based in the US, I would definitely make use of a US mirror, and I'm sure 
there are others that would to. As I mentioned in [4], I'm happy to help 
contribute funds for keeping up such a substitute server. I would be glad to 
help out in any other way I can as well (I'm no system or network administrator 
outside of my own machines and little home server, but feel free to contact me 
off list too).

Thanks again for your work on this!

John

Re: 04/07: guix: Add compression module.

[Ludovic Courtès]

Hi Mathieu,

That’s a long-overdue factorization, but…

guix-comm...@gnu.org skribis:

> +(define-module (guix compression)
> +  #:use-module (guix gexp)
> +  #:use-module (guix ui)
> +  #:use-module ((gnu packages compression) #:hide (zip))

… a (guix …) module Should Not refer to a (gnu …) module¹.  When it
really has to, it should be via lazy-loading at run time, as is done in
(guix build-system …).

While I agree this should be factorize, I wonder if this should be
promoted to (guix compression).  The module name intuitively is a better
fit for the compression-related things currently in (guix utils).

Not sure, maybe (gnu compression) would make more sense?

Ludo’.

¹ For questions of abstraction layering, and also because that’d break
  “make as-derivation”.

Re: 02/02: gnu: shepherd: Update to 0.9.2.

[Mathieu Othacehe]

Hey Ludo,

The installation system tests have fail this night and I suspect this is
related with the shepherd update. The problem seems to occur when we
restart the guix-daemon service before running the installation command,
in the install-system procedure. Any idea what could cause it?

The cgit and gitile tests also fail, but with the following error:

--8<---cut here---start->8---
  result-kind: fail
  actual-value: #f
  actual-error: (read-error #f "socket:5:14: Unknown # object: ~S" ("#<") #f)
--8<---cut here---end--->8---

Thanks,

Mathieu