bug#42212: [PATCH 1/1] self: Use nearest tag as the version string in documentation.

[Ludovic Courtès]

Hi Arun,

Arun Isaac  skribis:

> * guix/channels.scm (latest-channel-instance): Write nearest tag into .version
> of the checkout.
> * guix/self.scm (info-manual): Use nearest tag from .version as the version
> string while generating documentation.

Thanks for looking into it!  Two comments:

> +  ;; Write nearest tag into .version.
> +  (with-directory-excursion checkout
> +(let ((version
> +   (call-with-port
> +(open-pipe* OPEN_READ "./build-aux/git-version-gen" 
> ".tarball-version")
> +get-string-all)))
> +  (call-with-output-file ".version"
> +(cut put-string <> version)
>  
>  (let* ((name (url+commit->name (channel-url channel) commit))
> (checkout (add-to-store store name #t "sha256" checkout

I would rather not call out to ‘git-version-gen’ and instead use (git
describe) or similar.

However, unless I’m mistaken, the output of ‘git-version-gen’ changes at
each commit, so we’d be rebuilding the manual at every commit, which is
what we should avoid here.

One way to avoid that would be to look at the latest commit that touch
doc/ instead of the latest commit overall (I think that’s what zimoun
was suggesting).  Roughly run ‘git describe’ on ‘git log doc/’, so to
speak.  (Using Guile-Git.)

Thoughts?

Ludo’.

bug#42212: [PATCH 1/1] self: Use nearest tag as the version string in documentation.

[Arun Isaac]

> I would rather not call out to ‘git-version-gen’ and instead use (git
> describe) or similar.

Sure, I'll do that. Then, perhaps we should even rewrite git-version-gen
using (git describe). It would be nice to have that in guile too. WDYT?

> However, unless I’m mistaken, the output of ‘git-version-gen’ changes at
> each commit, so we’d be rebuilding the manual at every commit, which is
> what we should avoid here.

Yes, but I discard the commit part of git-version-gen's output. I keep
only the tag part.

But, like zimoun, I didn't understand why we can't rebuild the manual
every commit. Rebuilding the manual is quite cheap. So, substituting it
shouldn't be a problem, right?

> One way to avoid that would be to look at the latest commit that touch
> doc/ instead of the latest commit overall (I think that’s what zimoun
> was suggesting).  Roughly run ‘git describe’ on ‘git log doc/’, so to
> speak.  (Using Guile-Git.)

This sounds good. I'll try it and get back to you.


signature.asc
Description: PGP signature

bug#42162: Recovering source tarballs

[Ludovic Courtès]

Hi!

There are many many comments in your message, so I took the liberty to
reply only to the essence of it.  :-)

zimoun  skribis:

> On Sat, 11 Jul 2020 at 17:50, Ludovic Courtès  wrote:
>
>> For the now, since 70% of our packages use ‘url-fetch’, we need to be
>> able to fetch or to reconstruct tarballs.  There’s no way around it.
>
> Yes, but for example all the packages in gnu/packages/bioconductor.scm
> could be "git-fetch".  Today the source is over url-fetch but it could
> be over git-fetch with https://git.bioconductor.org/packages/flowCore or
> g...@git.bioconductor.org:packages/flowCore.
>
> Another example is the packages in gnu/packages/emacs-xyz.scm and the
> ones from elpa.gnu.org are "url-fetch" and could be "git-fetch", for
> example using
> http://git.savannah.gnu.org/gitweb/?p=emacs/elpa.git;a=tree;f=packages/ace-window;h=71d3eb7bd2efceade91846a56b9937812f658bae;hb=HEAD
>
> So I would be more reserved about the "no way around it". :-)  I mean
> the 70% could be a bit mitigated.

The “no way around it” was about the situation today: it’s a fact that
70% of packages are built from tarballs, so we need to be able to fetch
them or reconstruct them.

However, the two examples above are good ideas as to the way forward: we
could start a url-fetch-to-git-fetch migration in these two cases, and
perhaps more.

>> In the short term, we should arrange so that the build farm keeps GC
>> roots on source tarballs for an indefinite amount of time.  Cuirass
>> jobset?  Mcron job to preserve GC roots?  Ideas?
>
> Yes, preserving source tarballs for an indefinite amount of time will
> help.  At least all the packages where "lookup-content" returns #f,
> which means they are not in SWH or they are unreachable -- both is
> equivalent from Guix side.
>
> What about in addition push to IPFS?  Feasible?  Lookup issue?

Lookup issue.  :-)  The hash in a CID is not just a raw blob hash.
Files are typically chunked beforehand, assembled as a Merkle tree, and
the CID is roughly the hash to the tree root.  So it would seem we can’t
use IPFS as-is for tarballs.

>> For the future, we could store nar hashes of unpacked tarballs instead
>> of hashes over tarballs.  But that raises two questions:
>>
>>   • If we no longer deal with tarballs but upstreams keep signing
>> tarballs (not raw directory hashes), how can we authenticate our
>> code after the fact?
>
> Does Guix automatically authenticate code using signed tarballs?

Not automatically; packagers are supposed to authenticate code when they
add a package (‘guix refresh -u’ does that automatically).

>>   • SWH internally store Git-tree hashes, not nar hashes, so we still
>> wouldn’t be able to fetch our unpacked trees from SWH.
>>
>> (Both issues were previously discussed at
>> .)
>>
>> So for the medium term, and perhaps for the future, a possible option
>> would be to preserve tarball metadata so we can reconstruct them:
>>
>>   tarball = metadata + tree
>
> There is different issues at different levels:
>
>  1. how to lookup? what information do we need to keep/store to be able
> to query SWH?
>  2. how to check the integrity? what information do we need to
> keep/store to be able to verify that SWH returns what Guix expects?
>  3. how to authenticate? where the tarball metadata has to be stored if
> SWH removes it?
>
> Basically, the git-fetch source stores 3 identifiers:
>
>  - upstream url
>  - commit / tag
>  - integrity (sha256)
>
> Fetching from SWH requires the commit only (lookup-revision) or the
> tag+url (lookup-origin-revision) then from the returned revision, the
> integrity of the downloaded data is checked using the sha256, right?

Yes.

> Therefore, one way to fix lookup of the url-fetch source is to add an
> extra field mimicking the commit role.

But today, we store tarball hashes, not directory hashes.

> The easiest is to store a SWHID or an identifier allowing to deduce the
> SWHID.
>
> I have not checked the code, but something like this:
>
>   https://pypi.org/project/swh.model/
>   https://forge.softwareheritage.org/source/swh-model/
>
> and at package time, this identifier is added, similarly to integrity.

I’m skeptical about adding a field that is practically never used.

[...]

>> The code below can “disassemble” and “assemble” a tar.  When it
>> disassembles it, it generates metadata like this:
>
> [...]
>
>> The ’assemble-archive’ procedure consumes that, looks up file contents
>> by hash on SWH, and reconstructs the original tarball…
>
> Where do you plan to store the "disassembled" metadata?
> And where do you plan to "assemble-archive"?

We’d have a repo/database containing metadata indexed by tarball sha256.

> How this database that maps tarball hashes to metadata should be
> maintained?  Git push hook?  Cron task?

Yes, something like that.  :-)

> What about foreign channels?  Should they maintain their own map?

Yes, presumably.

> To summary, it 

bug#42385: guile-based jupyter kernels mix guile3 and guile2.2

[Ludovic Courtès]

Hi Jesse,

Jesse Gibbons  skribis:

> jupyter-guile-kernel and guix-jupyter mix guile3 and guile2.2.
>
> - jupyter-guile-kernel only has one of its dependencies in
> GUILE_LOAD_PATH, so it doesn't build.
>
> - guix-jupyter builds successfully, but searches in the wrong
> directory for guix-jupyter-kernel.scm.
>
> jupyter-guile-kernel requires guile-json1 which has not been packaged
> for guile3, and is still built with guile2.2. IINM the
> jupyter-guile-kernel repository has been updated to build with guile3,
> so it might be worth updating. Unfortunately, there are no releases in
> its github repository. I expect guix-jupyter will be much easier to
> fix.

> I have a series of patches coming soon that fix both named issues.

Good catch!  Did you eventually manage to complete your work?

Thanks,
Ludo’.

bug#41702: `guix environment` performance issues

[Lars-Dominik Braun]

Hi Ludo,

a new version has been released, so here is the updated patchset. I’m not sure
if it’s possible to make the #:nodelay optional somehow, i.e. retaining
compatibility with guile-ssh<0.13.0. For now there’s a hard feature check.

Lars

From 42ff75c9d4da4eb2aeece96119ae5a65a9ccac82 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun 
Date: Mon, 20 Jul 2020 11:27:35 +0200
Subject: [PATCH 1/2] gnu: guile-ssh: Update to 0.13.0.

* gnu/packages/ssh.scm (guile-ssh): Update to 0.13.0.
---
 gnu/packages/ssh.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index a612b9dd15..50316ea1be 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -297,7 +297,7 @@ Additionally, various channel-specific options can be negotiated.")
 (define-public guile-ssh
   (package
 (name "guile-ssh")
-(version "0.12.0")
+(version "0.13.0")
 (home-page "https://github.com/artyom-poptsov/guile-ssh";)
 (source (origin
   (method git-fetch)
@@ -307,7 +307,7 @@ Additionally, various channel-specific options can be negotiated.")
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32
-"054hd9rzfhb48gc1hw3rphhp0cnnd4bs5qmidy5ygsyvy9ravlad"))
+"1q96h98p6x7ah6nc0d2wfx503fmsj36riv9ka9s79z3lzwaf0k26"))
   (modules '((guix build utils)
 (build-system gnu-build-system)
 (outputs '("out" "debug"))
-- 
2.20.1

From 6a18c9a4533075d1ee9795777a998fde3e64030f Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun 
Date: Mon, 20 Jul 2020 11:28:51 +0200
Subject: [PATCH 2/2] guix: Speed up RPC via SSH connections.

See issue #41702

* guix/ssh.scm (open-ssh-session): Enable #:nodelay.
* m4/guix.m4 (GUIX_CHECK_GUILE_SSH): Add feature check for this new parameter.
---
 guix/ssh.scm | 5 -
 m4/guix.m4   | 6 --
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/guix/ssh.scm b/guix/ssh.scm
index 2d7ca7d01d..3bffb0b525 100644
--- a/guix/ssh.scm
+++ b/guix/ssh.scm
@@ -129,7 +129,10 @@ Throw an error on failure."
;; We need lightweight compression when
;; exchanging full archives.
#:compression compression
-   #:compression-level 3)))
+   #:compression-level 3
+
+   ;; Speed up RPC.
+   #:nodelay #t)))
 
 ;; Honor ~/.ssh/config.
 (session-parse-config! session)
diff --git a/m4/guix.m4 b/m4/guix.m4
index 7c27ae74df..cce03045db 100644
--- a/m4/guix.m4
+++ b/m4/guix.m4
@@ -142,14 +142,16 @@ dnl GUIX_CHECK_GUILE_SSH
 dnl
 dnl Check whether a recent-enough Guile-SSH is available.
 AC_DEFUN([GUIX_CHECK_GUILE_SSH], [
-  dnl Check whether 'userauth-gssapi!' (introduced in 0.12.0) is present.
+  dnl Check whether '#:nodelay' paramater to 'make-session' (introduced in
+  dnl 0.13.0) is present.
   AC_CACHE_CHECK([whether Guile-SSH is available and recent enough],
 [guix_cv_have_recent_guile_ssh],
 [GUILE_CHECK([retval],
   [(and (@ (ssh channel) channel-send-eof)
 (@ (ssh popen) open-remote-pipe)
 (@ (ssh dist node) node-eval)
-(@ (ssh auth) userauth-gssapi!))])
+(@ (ssh auth) userauth-gssapi!)
+((@ (ssh session) make-session) #:nodelay #t))])
  if test "$retval" = 0; then
guix_cv_have_recent_guile_ssh="yes"
  else
-- 
2.20.1



signature.asc
Description: PGP signature

bug#42212: [PATCH 1/1] self: Use nearest tag as the version string in documentation.

[Ludovic Courtès]

Arun Isaac  skribis:

>> I would rather not call out to ‘git-version-gen’ and instead use (git
>> describe) or similar.
>
> Sure, I'll do that. Then, perhaps we should even rewrite git-version-gen
> using (git describe). It would be nice to have that in guile too. WDYT?

Yes, but… one thing at a time.  :-)

>> However, unless I’m mistaken, the output of ‘git-version-gen’ changes at
>> each commit, so we’d be rebuilding the manual at every commit, which is
>> what we should avoid here.
>
> Yes, but I discard the commit part of git-version-gen's output. I keep
> only the tag part.
>
> But, like zimoun, I didn't understand why we can't rebuild the manual
> every commit. Rebuilding the manual is quite cheap. So, substituting it
> shouldn't be a problem, right?

Try rebuilding the manual + translations by yourself: it takes a few
minutes (see also commit a524a31de43b330c911fb08ae02fcd880d32aa04
related commits).

Also, if you don’t build it by yourself, you have to download its
substitutes, which is also not free.

So it’s really important to rebuild only when we have to.  (guix self)
is written in that spirit.

>> One way to avoid that would be to look at the latest commit that touch
>> doc/ instead of the latest commit overall (I think that’s what zimoun
>> was suggesting).  Roughly run ‘git describe’ on ‘git log doc/’, so to
>> speak.  (Using Guile-Git.)
>
> This sounds good. I'll try it and get back to you.

Thanks!

Ludo’.

bug#42212: [PATCH 1/1] self: Use nearest tag as the version string in documentation.

[zimoun]

Hi,

On Mon, 20 Jul 2020 at 14:32, Ludovic Courtès  wrote:

> > But, like zimoun, I didn't understand why we can't rebuild the manual
> > every commit. Rebuilding the manual is quite cheap. So, substituting it
> > shouldn't be a problem, right?
>
> Try rebuilding the manual + translations by yourself: it takes a few
> minutes (see also commit a524a31de43b330c911fb08ae02fcd880d32aa04
> related commits).
>
> Also, if you don’t build it by yourself, you have to download its
> substitutes, which is also not free.

Not free but still cheap enough. :-)

downloading from
https://ci.guix.gnu.org/nar/lzip/p8xbha1fl3j23q05iya43ypzhzjmyr0j-guix-manual
...
 guix-manual  4.4MiB

Especially compared to the other parts of "guix pull".

> So it’s really important to rebuild only when we have to.  (guix self)
> is written in that spirit.
>
> >> One way to avoid that would be to look at the latest commit that touch
> >> doc/ instead of the latest commit overall (I think that’s what zimoun
> >> was suggesting).  Roughly run ‘git describe’ on ‘git log doc/’, so to
> >> speak.  (Using Guile-Git.)

It was not what I was suggesting but it is the next step of my question. :-)

Naively, is it not a situation about kind of grafts?

If the last commit modifying the documentation is 1234abcd, then other
changes unrelated to documentation are committed, say commit wxyz5678,
I would expect to have that commit wxyz5678 appears in the
documentation. As it seems the case with
guix.gnu.org/manual/devel/en/.
So, the documentation should be built with the commit 1234abcd and
probably substituable, then grafted to refer to the last commit
wxyz5648 where it is required.  Even if referring to commit 1234abcd
will be already enough.

All the best,
simon

bug#42385: guile-based jupyter kernels mix guile3 and guile2.2

[Jesse Gibbons]

On 7/20/20 3:22 AM, Ludovic Courtès wrote:

Hi Jesse,

Jesse Gibbons  skribis:


jupyter-guile-kernel and guix-jupyter mix guile3 and guile2.2.

- jupyter-guile-kernel only has one of its dependencies in
GUILE_LOAD_PATH, so it doesn't build.

- guix-jupyter builds successfully, but searches in the wrong
directory for guix-jupyter-kernel.scm.

jupyter-guile-kernel requires guile-json1 which has not been packaged
for guile3, and is still built with guile2.2. IINM the
jupyter-guile-kernel repository has been updated to build with guile3,
so it might be worth updating. Unfortunately, there are no releases in
its github repository. I expect guix-jupyter will be much easier to
fix.
I have a series of patches coming soon that fix both named issues.

Good catch!  Did you eventually manage to complete your work?

Thanks,
Ludo’.



The only reason I have not yet sent these patches (and others I have 
ready to send) is I haven't found the time to make the patches 
acceptable (lint, format commit messages, etc.). I will have time to do 
that tomorrow, so expect patches by July 22.

bug#42162: Recovering source tarballs

[zimoun]

Hi,

On Mon, 20 Jul 2020 at 10:39, Ludovic Courtès  wrote:
> zimoun  skribis:
> > On Sat, 11 Jul 2020 at 17:50, Ludovic Courtès  wrote:

> There are many many comments in your message, so I took the liberty to
> reply only to the essence of it.  :-)

Many comments because many open topics. ;-)


> However, the two examples above are good ideas as to the way forward: we
> could start a url-fetch-to-git-fetch migration in these two cases, and
> perhaps more.

Well, to be honest, I have tried to probe such migration when I opened
this thread:

https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00224.html

and I have tried to summarized the pros/cons arguments here:

https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00448.html


> > What about in addition push to IPFS?  Feasible?  Lookup issue?
>
> Lookup issue.  :-)  The hash in a CID is not just a raw blob hash.
> Files are typically chunked beforehand, assembled as a Merkle tree, and
> the CID is roughly the hash to the tree root.  So it would seem we can’t
> use IPFS as-is for tarballs.

Using the Git-repo map/table, then it becomes an option, right?
Well, SWH would be a backend and IPFS could be another one.  Or any
"cloudy" storage system that could appear in the future, right?


> >>   • If we no longer deal with tarballs but upstreams keep signing
> >> tarballs (not raw directory hashes), how can we authenticate our
> >> code after the fact?
> >
> > Does Guix automatically authenticate code using signed tarballs?
>
> Not automatically; packagers are supposed to authenticate code when they
> add a package (‘guix refresh -u’ does that automatically).

So I miss the point of having this authentication information in the
future where upstream has disappeared.
The authentication is done at packaging time.  So once it is done,
merged into master and then pushed to SWH, being able to authenticate
again does not really matter.

And if it matters, all should be updated each time vulnerabilities are
discovered and so I am not sure SWH makes sense for this use-case.


> But today, we store tarball hashes, not directory hashes.

We store what "guix hash" returns. ;-)
So it is easy to migrate from tarball hashes to whatever else. :-)
I mean, it is "(sha256 (base32" and it is easy to have also
"(sha256-tree (base32" or something like that.

In the case where the integrity is also used as lookup key.

> > The format of metadata (disassemble) that you propose is schemish
> > (obviously! :-)) but we could propose something more JSON-like.
>
> Sure, if that helps get other people on-board, why not (though sexps
> have lived much longer than JSON and XML together :-)).

Lived much longer and still less less less used than JSON or XML alone. ;-)


I have not done yet the clear back-to-envelop computations.  Roughly,
there are ~23 commits on average per day updating packages, so say 70%
of them are url-fetch, it is ~16 new tarballs per day, on average.
How the model using a Git-repo will scale?  Because, naively the
output of "disassemble-archive" in full text (pretty-print format) for
the hello-2.10.tar is 120KB and so 16*365*120K = ~700Mb per year
without considering all the Git internals.  Obviously, it depends on
the number of files and I do not know if hello is a representative
example.

And I do not know how Git operates on binary files if the disassembled
tarball is stored as .go file, or any other.


All the best,
simon

ps:
Just if someone wants to check from where I estimate the numbers.

--8<---cut here---start->8---
for ci in $(git log --after=v1.0.0 --oneline \
| grep "gnu:" | grep -E "(Add|Update)" \
| cut -f1 -d' ')
do
git --no-pager log -1 $ci --format="%cs"
done | uniq -c > /tmp/commits

guix environment --ad-hoc r-minimal \
 -- R -e 'summary(read.table("/tmp/commits"))'

gzip -dc < $(guix build -S hello) > /tmp/hello.tar
guix repl -L /tmp/tar/

scheme@(guix-user)> (call-with-input-file "hello.tar"
  (lambda (port)
 (disassemble-archive port)))
--8<---cut here---end--->8---

bug#42321: qgis PyQgsExpressionBuilderWidget test fails

[Wiktor Żelazny]

On Fri, Jul 17, 2020 at 07:20:34PM +0200, Wiktor Żelazny wrote:

> As I was thinking about it, I began to suspect that the problem might be
> caused by outdated input definitions in my private channel.

I made use of the fact that my root user has got no extra channels
defined and had it build qgis today. It worked. Then, I cleaned the
cruft from my private channel, and the subsequent build pointed to the
same hash as for root. So I guess that was the problem, indeed.

Closing.

WŻ


signature.asc
Description: PGP signature

bug#42162: Recovering source tarballs

[Dr. Arne Babenhauserheide]

zimoun  writes:
>> > The format of metadata (disassemble) that you propose is schemish
>> > (obviously! :-)) but we could propose something more JSON-like.
>>
>> Sure, if that helps get other people on-board, why not (though sexps
>> have lived much longer than JSON and XML together :-)).
>
> Lived much longer and still less less less used than JSON or XML alone. ;-)

Though this is likely not a function of the format, but of the
popularity of both Javascript and Java.

JSON isn’t a well defined format for arbitrary data (try to store
numbers as keys and reason about what you get as return-values), and
XML is a monster of complexity.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

bug#42447: Issue with CGIT service

[Brett Gilio]

Hi all,

I am having an issue with the CGIT service. There is a record field for
setting the directory it should watch, defaulting to /srv/cgit or
something similar. Currently when doing this it just returns an empty
cgit web interface.

--8<---cut here---start->8---
(service cgit-service-type
  (cgit-configuration
   (enable-commit-graph? #t)
   (enable-html-serving? #t)
   (repository-directory
(string-append home-directory "/Repos/"))
   (nocache? #t)
   (readme "CGIT README")))
--8<---cut here---end--->8---

Also, I would also be willing to collaborate with
somebody on getting cgit and nginx to work together to set a port other
than 80.

Thoughts?

Brett Gilio

bug#42448: Issue with Qemu Binfmt and CMake not detecting compiler.

[Brett Gilio]

Hey all,

Opening a bug report as per a request following this issue identified
at: https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00124.html.

To recap, when running

--8<---cut here---start->8---
./pre-inst-env guix build --system=armhf-linux swi-prolog
--8<---cut here---end--->8---

the configure phase is failing to identify the C/CXX compiler
toolchains to compile a test CMake file. There is a variety of
CMakeError.log and other object outputs that populate the build
directory when ran with --keep-failed.

This seems to be reported before, but subsequently patched at
https://issues.guix.gnu.org/38454#3. This only occurs when using the
Qemu method of compiling on a foreign architecture, and is not present
when natively compiling on true hardware.

Thanks,
Brett Gilio

bug#42162: Recovering source tarballs

[zimoun]

On Mon, 20 Jul 2020 at 19:05, Dr. Arne Babenhauserheide  wrote:
> zimoun  writes:
> >> > The format of metadata (disassemble) that you propose is schemish
> >> > (obviously! :-)) but we could propose something more JSON-like.
> >>
> >> Sure, if that helps get other people on-board, why not (though sexps
> >> have lived much longer than JSON and XML together :-)).
> >
> > Lived much longer and still less less less used than JSON or XML alone. ;-)
>
> Though this is likely not a function of the format, but of the
> popularity of both Javascript and Java.

Well, the popularity matters to attract a broad audience and maybe get
other people on-board; if it is the aim.
It seems the de-facto format; even if JSON has flaws.  And zillions of
parsers for all the languages are floating around, which is not the
case for Sexp, even if it is easier to parse.

And JSON is already used in Guix, see [1] for an example.

1: https://guix.gnu.org/manual/devel/en/guix.html#Additional-Build-Options

However, I am not convinced that JSON or similarly Sexp will scale
well for a Tarball Heritage perspective.

All the best,
simon

bug#42449: texlive: l3regex.sty not shipped with texlive-latex-l3kernel

[Jonathan Brielmaier]

I'm using a latex "theme" called moderncv
(https://github.com/xdanaux/moderncv).

In `moderncv.cls` it states a dependency on l3regex:
```
\RequirePackage{l3regex}
```

But I couldn't find any texlive package providing `l3regex.sty`.
According to https://www.ctan.org/pkg/l3regex it should be included in
`texlive-latex-l3kernel`.

But something is wrong with the build:
```
find $(guix build --source texlive-latex-l3kernel) -name "*regex*"
/gnu/store/46sm302ggnmk5hcr08psiazj24svpp5d-texlive-latex-l3kernel-51265-checkout/l3regex.dtx

find $(guix build texlive-latex-l3kernel) -name "*regex*"
[no result].
```

bug#42162: Recovering source tarballs

[zimoun]

Hi Chris,

On Mon, 13 Jul 2020 at 20:20, Christopher Baines  wrote:

> Going forward, being methodical as a project about storing the tarballs
> and source material for the packages is probalby the way to ensure it's
> available for the future. I'm not sure the data storage cost is
> significant, the cost of doing this is probably in working out what to
> store, doing so in a redundant manor, and making the data available.

A really rough estimate is 120KB on average* per raw tarball.  So if we
consider 14000 packages and 70% of them are url-fetch, then it leads to
14k*0.7*120K= 1.2GB; which is not significant.  Moreover, if we
extrapolate the numbers, between v1.0.0 and now it is 23 commits per day
modifying gnu/packages/ so 0.7*23*120K*365= 700MB per year.  However,
the 120KB of metadata to re-assemble the tarball have to be compared to
the 712KB of raw compressed tarball; both about the hello package.

*based on the hello package.  And it depends on the number of files in
 the tarball.  File stored not compressed: plain sexp.


Therefore, in addition to what to store, redundancy and availability,
one question is how to store?  Git-repo? SQL database? etc.



> The Guix Data Service knows about fixed output derivations, so it might
> be possible to backfill such a store by just attempting to build those
> derivations. It might also be possible to use the Guix Data Service to
> work out what's available, and what tarballs are missing.

Missing from where?  The substitutes farm or SWH?


Cheers,
simon

bug#42389: Failure to build docker pack with complete store

[Ludovic Courtès]

Hi,

branj...@gmail.com skribis:

> I'm trying out various ways of reproducing my emacs setup for non-guix
>  users. While attempting 'guix pack -f docker' I bumped into the
>  following issue:
>  
> Commits attempted-
> b0e7b6992f3f845e83cfbca4d700b51dba50b4d5
> 03f9a8c35be387f37badcd2c830ac7414ac17225
>
>
> Commands ran-
> guix pack -f docker -m some-manifest-with-nss-certs.scm
>  (works)
>
> guix pack -f docker --localstatedir -m some-manifest-with-nss-certs.scm
>  (fails)
>
>
> Failing output-
> Backtrace:
>2 (primitive-load "/gnu/store/rnhas6d4wb4xy571s45b8v0m907?")
> In guix/store/database.scm:
>127:20  1 (call-with-database _ _ #:wal-mode? _)
> In ice-9/boot-9.scm:
>   1731:15  0 (with-exception-handler # ?)
>
> ice-9/boot-9.scm:1731:15: In procedure with-exception-handler:
> In procedure lstat: No such file or directory:
> "/gnu/store/0llx3y194278l5ksr4xh9kc64mh8nn8d-nss-certs-3.52.1/etc/ssl/
> certs/
> NetLock_Arany_=Class_Gold=_
> F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem"

Fixed with b3802495f607fd5e17c5acf0be2ee014036e2464, thank you!

Ludo’.

bug#41702: `guix environment` performance issues

[Ludovic Courtès]

Hi Lars,

Lars-Dominik Braun  skribis:

> From 42ff75c9d4da4eb2aeece96119ae5a65a9ccac82 Mon Sep 17 00:00:00 2001
> From: Lars-Dominik Braun 
> Date: Mon, 20 Jul 2020 11:27:35 +0200
> Subject: [PATCH 1/2] gnu: guile-ssh: Update to 0.13.0.
>
> * gnu/packages/ssh.scm (guile-ssh): Update to 0.13.0.

[...]

> From 6a18c9a4533075d1ee9795777a998fde3e64030f Mon Sep 17 00:00:00 2001
> From: Lars-Dominik Braun 
> Date: Mon, 20 Jul 2020 11:28:51 +0200
> Subject: [PATCH 2/2] guix: Speed up RPC via SSH connections.
>
> See issue #41702
>
> * guix/ssh.scm (open-ssh-session): Enable #:nodelay.
> * m4/guix.m4 (GUIX_CHECK_GUILE_SSH): Add feature check for this new parameter.

I adjusted the commit log and pushed.

I think it’s okay to use the new Guile-SSH feature right away because
it’s not central, and ‘guix pull’ gives people the ability to get the
new Guile-SSH version.

Thanks!

Ludo’.

bug#42448: A possible solution

[Brett Gilio]

As Marius Bakke pointed out on IRC, this issue is related to a change in
CMake where after 3.15 they removed the explicit `#define
_FILE_OFFSET_BITS 64`. The solution solution to this is to add

--8<---cut here---start->8---
CFLAGS="-D_FILE_OFFSET_BITS=64"
CXXFLAGS="-D_FILE_OFFSET_BITS=64"
--8<---cut here---end--->8---

to CMakes compilation procedure. This is a core-updates change. I will
leave this issue open for now in case this needs more
investigation. Since I am just coming off of a haitus I think there are
changes to the core-updates and staging procedures so I dont think I am
comfortable making this change myself.

Brett Gilio

bug#42173: Nix on Guix System: can't update channels

[Zhu Zihao via web]

We can add the path to bash to build-sandbox-path in /etc/nix.conf, described 
in https://nixos.wiki/wiki/FAQ.

bug#42459: Carla 2.0.0: Patchbay frozen

[Nathan Dehnel]

The patchbay in carla is completely unresponsive, and does not allow
dragging around clients, or making connections.

bug#42459: Carla 2.0.0: Patchbay frozen

[Efraim Flashner]

On Tue, Jul 21, 2020 at 01:12:50AM -0500, Nathan Dehnel wrote:
> The patchbay in carla is completely unresponsive, and does not allow
> dragging around clients, or making connections.

Carla was just updated in Guix to 2.1.1. Is this still a problem with
the latest packaged version?

-- 
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