Re: planned downtime for ci.guix.gnu.org this Friday

[Christopher Baines]

Ricardo Wurmus  writes:

> on Friday (March 6) the head node and the big storage for
> ci.guix.gnu.org will need to be moved to a different aisle in the MDC
> data centre.  This will require a short downtime as we need to shut off
> ci.guix.gnu.org for a little while.  We will also take some time to
> apply firmware updates, which will delay the reboot.
>
> We expect that this will take less than a day.

Thanks for looking after this Ricardo :)

Maybe it's worth emailing info-guix [1] as well?

1: https://lists.gnu.org/mailman/listinfo/info-guix

Thanks,

Chris


signature.asc
Description: PGP signature

Re: 02/02: gnu: next: Compress the executable.

[Maxim Cournoyer]

Hi Pierre,

Pierre Neidhardt  writes:

> This is fantastic, thanks a lot for the feedback!
>
> Speaking of which, should we update the manual and/or templates to
> encourage users to switch to Btrfs?

Perhaps!  I don't really have an opinion on this :-)

Maxim

Re: Packaging UCSC

[Pjotr Prins]

On Fri, Feb 28, 2020 at 10:12:28AM +0100, Giovanni Biscuolo wrote:
> Is Galaxy also capable of genome browsing?

Not that I am aware. There may be some SNP browsing tools in Galaxy.

> --8<---cut here---start->8---
> 
> The source for the Genome Browser, Blat, liftOver and other utilities is
> free for non-profit academic research and for personal use. For
> information on commercial licensing, see the Genome Browser and Blat
> licensing requirements. The source and executables for several of these
> products can be downloaded or purchased from our online store.
> 
> --8<---cut here---end--->8---

It is good that it is pointed out on this list. Thank you.

Pj.

Re: Packaging UCSC

[Pjotr Prins]

On Fri, Feb 28, 2020 at 02:20:16PM +0100, Ricardo Wurmus wrote:
> 
> Pjotr Prins  writes:
> 
> > Anyone got UCSC running with Guix? May be easier than Galaxy which is
> > also on the books at some point.
> 
> Most of the UCSC browser is non-free software.  The kentutils make up a
> part of the code.  Some of the kentutils are free software and are
> available in Guix as the “kentutils” package.

Ouch. Thanks all for pointing this out. I'll start poking about the
license.

Pj.

New Spanish PO file for 'guix' (version 1.1.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: adding unencoded space character check to guix lint

[Vincent Legoll]

Hello,

I retract that WIP,RFC,PATCH, it was mistakenly created after
seeing a warning about such unencoded (%20) space characters
in url on repology, but since I've been unable to find them again
(the warnings).

They were temporarily activated on repology, and triggered me
into doing something about that... Now the maintainer of that
site explained me they were not real warnings to act upon, and
should be deactivated by now.

Sorry for the noise...

--
Vincent Legoll

Re: adding unencoded space character check to guix lint

[zimoun]

Hi Vincent,

On Sat, 29 Feb 2020 at 20:21, Leo Famulari  wrote:
>
> On Sat, Feb 29, 2020 at 04:26:57PM +0100, Vincent Legoll wrote:
> > The attached (crude, WIP, RFC) patch allowed to find the following
> > packages that have unecoded space characters in their URIs:
>
> Can you explain a little more about these characters and why we want to
> avoid them?

What do you mean by "unencoded" space characters?
Because they are replaced by '%20', isn't?


All the best,
simon

Re: Missing substitutes and TIMEOUT property (Racket, MAME)

[Leo Famulari]

On Tue, Feb 18, 2020 at 03:58:19PM +0100, Pierre Neidhardt wrote:
> Some packages are frequently without substitutes, like Racket and MAME.
> Link between the two?  They both take a long time to build.  So I wonder
> if this is not because the build somehow timeouts.

The logs of the failing builds should say if the failure was caused by
timeout or exceeding the maximum "silent time" (time without any output
from the build).

Re: guix build --repair might not always work

[zimoun]

Hi,

On Sat, 25 Jan 2020 at 19:06, Ludovic Courtès  wrote:

> > And nothing else.  So, let's check the hash
>
> In particular, you should compare the actual hash returned by “guix hash
> -r” with that stored in the local database.  If they match, then the
> store item is not considered corrupt.

It is not possible to do that at the CLI level, right?
And how do you do that at the Scheme level?

All the best,
simon

planned downtime for ci.guix.gnu.org this Friday

[Ricardo Wurmus]

Hi there,

on Friday (March 6) the head node and the big storage for
ci.guix.gnu.org will need to be moved to a different aisle in the MDC
data centre.  This will require a short downtime as we need to shut off
ci.guix.gnu.org for a little while.  We will also take some time to
apply firmware updates, which will delay the reboot.

We expect that this will take less than a day.

--
Ricardo

Re: returning a store directory

[Gábor Boskovits]

Hello,

Efraim Flashner  ezt írta (időpont: 2020. márc. 2.,
Hét 12:54):

> I'm working on some user shepherd services and I want to make use of the
> #:directory option. The directory keyword clearly takes a string but
> guix-build from (guix scripts build) outputs a path and returns
> unspecified. The other things I've tried haven't worked as well.
>

Would ungexping the package from a gexp work for you?


> I'm looking to run a service from the store path of a package.
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

returning a store directory

[Efraim Flashner]

I'm working on some user shepherd services and I want to make use of the
#:directory option. The directory keyword clearly takes a string but
guix-build from (guix scripts build) outputs a path and returns
unspecified. The other things I've tried haven't worked as well.

I'm looking to run a service from the store path of a package.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Missing substitutes and TIMEOUT property (Racket, MAME)

[Pierre Neidhardt]

Friendly ping! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: [GSOC 2020] Idea: Guile based build-tool

[zimoun]

Dear,

Perhaps, some inspiration about build systems in this paper [1] by Haskellers.

[1] 
https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf


All the best,
simon

Re: 23/36: gnu: Add libkdepim.

[Hartmut Goebel]

Hi Ludo,
> I should have been more specific: could you try to expound a bit the
> descriptions and write full sentences?  I understand it’s going to be
> difficult if upstream doesn’t bother to provide a README, so it’ll
> clearly be best effort, no problem!

I updates the ugly ones, see


(And I learned that Debian has improved the descriptions quite a lot
compared to two years ago - this was when I generated the package
descriptions I'm now working on. So I will have a look at the Debian
description for further packages.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |