Re: OCaml 4.09

[Julien Lepiller]

Le 19 janvier 2020 20:35:31 GMT-05:00, Julien Lepiller  a 
écrit :
>Le 19 janvier 2020 15:25:01 GMT-05:00, "Ludovic Courtès" 
>a écrit :
>>Hello!
>>
>>Brett Gilio  skribis:
>>
>>> Short message! I am trying to get our OCaml development system up to
>>> shape, as it is currently lagging some versions behind. I have
>opened
>>a
>>> wip-ocaml4.09 branch for this work. Here are some of the things that
>>> need work that I have identified.
>>
>>I cannot really help on this, but I noticed that Julien added OCaml
>>4.09
>>in commit 7b99aa043c4e661fd86cfe25e7b51f5081f42e5d, so perhaps you can
>>synchronize on the next steps.  :-)
>>
>>Happy λ!
>>
>>Ludo’.
>
>Ah yes, sorry about that! Let's synchronize: we have
>package-with-explicit-ocaml. Next step is to have
>package-with-ocaml-4.07, update any package that doesn't work with 4.09
>(currently 4.07 is still the default), except for the janestreet
>packages and dependents. Then switch to 4.09 by default and make
>janestreet packages use 4.07 instead. Finally, import the new version
>of the janestreet packages and switch lependents to 4.09.
>
>That should ensure every step is buildable. Wdyt?

Ok, I pushed some updates to ocaml packages. I think we can now proceed with 
the switch to ocaml 4.09 by default. There are three phases to the switch, and 
two more to complete it:

- add ocaml4.07-findlib
- add package-with-ocaml4.07
- switch the default:
 + switch ocaml
 + explicitely use ocaml 4.07 on janestreet packages and dependents, rename 
them.
 + use package-with-ocaml4.07 when necessary
- package janestreet packages again, for 4.09
- replace dependents with a version for 4.09 whenever possible (only bap and 
earley may not be upgradable)

I'll try to do the first three phases tomorrow, and the other two will probably 
take me another week.

Re: Parameterized packages

[ison]

On Mon, Jan 20, 2020 at 07:57:30PM +0100, Pierre Neidhardt wrote:
> > The solution of 2. and 3. seems to write, as Ludo mentioned:
> >
> > --8<---cut here---start->8---
> > (define (make-me-a-package option1 option2)
> > (package
> >   …))
> > --8<---cut here---end--->8---

Just a thought, but could this be achieved using Guile's parameterization
feature?
https://www.gnu.org/software/guile/manual/html_node/Parameters.html

Not sure which method will be best overall, but its something to consider
and might avoid the need to define a bunch of extra functions. So basically
all standard parameters could be defined globally using make-parameter, then
in the parameters field of the package it lists the parameters they want
which will pick up the default values, or be overridden by parameterization.

Although I wonder if maybe it's better to not use global defaults for the
parameters and just let packages set their own defaults?

G-Expressions and Scope Preservation

[Chris Marusich]

Hi Ludo,

In your paper "Code Staging in GNU Guix" [1], you use the following
example to illustrate how G-Expressions are hygienic ("they preserve
lexical scope across stages"):

(let ((gen-body (lambda (x)
  #~(let ((x 40))
  (+ x #$x)
  #~(let ((x 2))
  #$(gen-body #~x)))

You explain that it expands to something like this:

(let ((x-1bd8-0 2))
  (let ((x-4f05-0 40))
(+ x-4f05-0 x-1bd8-0)))

However, when I write this gexp to disk, it doesn't look like that:

scheme@(guile-user)> ,use (guix)
scheme@(guile-user)> (define ex
   (let ((gen-body (lambda (x)
 #~(let ((x 40))
 (+ x #$x)
 #~(let ((x 2))
 #$(gen-body #~x
scheme@(guile-user)> ex
$2 = #:out>)) 7f29a4ed9240>:out>) 7f29a4ed91e0>
scheme@(guile-user)> ,run-in-store (lower-object (scheme-file "example" ex))
$3 = # 
/gnu/store/mhlvarq8hc9c40by7sfq7yqvxvjdq7rp-example 7f299a13abe0>
scheme@(guile-user)> ,run-in-store (built-derivations (list $3))
building path(s) `/gnu/store/mhlvarq8hc9c40by7sfq7yqvxvjdq7rp-example'
$4 = #t

The file /gnu/store/mhlvarq8hc9c40by7sfq7yqvxvjdq7rp-example contains
the following expression:

(let ((x 2)) (let ((x 40)) (+ x x)))

This looks different than what I expected.  I expected something more
like what you had written in the paper.  Am I missing something?

I thought this would be an easy way to see the scope preservation in
action, but I get the feeling I've misunderstood something.  I tried
some other ways to use the gexp, and the results were similar:

scheme@(guile-user)> (define write-result
   #~(with-output-to-file #$output
   (lambda ()
 (write #$ex
scheme@(guile-user)> (define write-ex-literally
   #~(with-output-to-file #$output
   (lambda ()
 (write '#$ex
scheme@(guile-user)> ,run-in-store (gexp->derivation "write-result" 
write-result)
$7 = # /gnu/store/jaf44b767y5n2m0zd6q9qswhzv2hsy96-write-result 7fda1342e960>
scheme@(guile-user)> ,run-in-store (gexp->derivation "write-ex-literally" 
write-ex-literally)
$8 = # 
/gnu/store/rhhm38j6yxfs0q7jrvdrv02r7zb9ai8j-write-ex-literally 7fda1342e780>
scheme@(guile-user)> 

The file /gnu/store/jaf44b767y5n2m0zd6q9qswhzv2hsy96-write-result
contained "80", and the file
/gnu/store/rhhm38j6yxfs0q7jrvdrv02r7zb9ai8j-write-ex-literally contained
the following S-Expression:

(let ((x 2)) (let ((x 40)) (+ x x)))

Can you help me to understand why I'm seeing this result instead of a
result that looks more like the one you presented in your paper?

Thank you,

Footnotes: 
[1]  https://hal.inria.fr/hal-01580582

-- 
Chris


signature.asc
Description: PGP signature

Re: Inverted index to accelerate guix package search

[Arun Isaac]

I've replaced the cache building code in gnu/packages.scm with code that
builds a sqlite database instead. I haven't finished hooking this up to
the guix search code. I'll have it ready in another day or two.

> To test "guix pull", simple "make as-derivation". Disclaim: can take
> some time :-)
>
> Then the issue is more to avoid to pollute your ~/.cache/guix and
> ~/.config/guix :-)
>
> 1. Update Guix with the result in /tmp/test
>
> guix pull -p /tmp/test --url=/path/to/guix/repo
>
> 2. Create your SQL index
>
> /tmp/test/bin/guix pull -p /tmp/trash
>
> Now your index should be created with all the packages currently in master.
> To have something reproducible (and faster), I suggest to add
> --commit= and always pull against the same commit.
>
> 3. Test the index
>
> /tmp/test/bin/guix search foo
>
> I mean something along these lines. ;-)

Thanks, I got the idea. I'll try it out.

>> I think it is not possible to search using regular expressions in sqlite
>
> I think it is possible. I imagine something using multiple query.
> I will give a look at the Guile module.

Sure, let me know if you find something.

> I disagree. We should keep the regexp. Otherwise we cannot include
> under "guix search" or "guix package --search=" because arguments
> about backward compatibility.

I agree about backward compatibility.

>> About sqlite versus an inverted index using vhashes, I don't know if it
>> is possible to serialize a vhash onto disk. Even if that were possible,
>> we'll have to load the entire vhash based inverted index into memory for
>> every invocation of guix search, and that could hit
>> performance. Something like guile-gdbm could have helped, but that's
>> another story.
>
> And your first test was not fair. ;-)
> Because you compared when the hash table was already in memory.
> I mean to know the real performance, only timing can talk. :-)

Yes, it wasn't completely fair. :-P I was assuming there was some way to
efficiently serialize to disk and read from it without too much overhead.


signature.asc
Description: PGP signature

patch-shebang and Rust - Change on core-updates?

[Danny Milosavljevic]

Hi,

Rust uses #![...] for something that is definitely not a shebang
(file-wide feature tests).

Currently, our patch-shebang[1] emits a lot of warnings because of those.

Should we change patch-shebang to ignore lines starting with "#![" ?

If so, how?  There's some get-char* magic that I don't understand.

The easiest way would be to add peek-char after the two calls to get-char*,
but not sure if that would work.

Alternatively, we could adapt the regexp.

>(define patch-shebang
>  (let ((shebang-rx (make-regexp 
> "^[[:blank:]]*([[:graph:]]+)[[:blank:]]*([[:graph:]]*)(.*)$")))

The [[:graph:]]+ would have to change to something like 

  [[:graph-without-opening-bracket:]][[:graph:]]+

[1] ./guix/build/utils.scm patch-shebang


pgpFJLthrIF3h.pgp
Description: OpenPGP digital signature

Re: Inverted index to accelerate guix package search

[zimoun]

Hi Arun,


On Fri, 17 Jan 2020 at 20:29, Arun Isaac  wrote:

> > 1.
> > How to update the index.
> > Give a look at the "pull" code and the ~/.cache/guix folder.
>
> We don't "update" the index. At every guix pull we create it
> anew. Currently, generate-package-cache in gnu/packages.scm does
> this. generate-package-cache is called by package-cache-file in
> guix/channels.scm. package-cache-file is a channel profile hook listed
> under %channel-profile-hooks.

I would like to be able to search the packages in all the history of
all the commits, and not only in only the packages for one specific
commit.



> Now, what I am unclear about is how to test my sqlite index building
> code without actually pushing to master and running a guix pull. I will
> go through the various tests in Guix and see if I can figure something
> out, but any pointers would be much appreciated.

To test "guix pull", simple "make as-derivation". Disclaim: can take
some time :-)

Then the issue is more to avoid to pollute your ~/.cache/guix and
~/.config/guix :-)


1. Update Guix with the result in /tmp/test

guix pull -p /tmp/test --url=/path/to/guix/repo

2. Create your SQL index

/tmp/test/bin/guix pull -p /tmp/trash

Now your index should be created with all the packages currently in master.
To have something reproducible (and faster), I suggest to add
--commit= and always pull against the same commit.

3. Test the index

/tmp/test/bin/guix search foo


I mean something along these lines. ;-)


> > 2.
> > How to deal with regexp.
> > It is more or less clear to me how to deal with using the trigram keys
> > but I do not know with SQLite; I have not thought about yet.
>
> I think it is not possible to search using regular expressions in sqlite

I think it is possible. I imagine something using multiple query.
I will give a look at the Guile module.


> I think we should remove regex support altogether. I don't think a good
> search interface should expect the user to provide regexes for
> search. Certainly, it will be a lot less useful if and when we have
> xapian. However, just to keep backward compatibility, we can fall back
> to brute force fold-packages search for regexes. As Ludo pointed out, we
> can't remove the brute force code since we need to support cases when
> the cache is not authoritative.

I disagree. We should keep the regexp. Otherwise we cannot include
under "guix search" or "guix package --search=" because arguments
about backward compatibility.

The end user interface (CLI) has to be exactly the same when using
brute force or the index. And the results too.


> About sqlite versus an inverted index using vhashes, I don't know if it
> is possible to serialize a vhash onto disk. Even if that were possible,
> we'll have to load the entire vhash based inverted index into memory for
> every invocation of guix search, and that could hit
> performance. Something like guile-gdbm could have helped, but that's
> another story.

And your first test was not fair. ;-)
Because you compared when the hash table was already in memory.
I mean to know the real performance, only timing can talk. :-)


> I didn't know about sets.scm when I wrote my first proof of concept
> inverted index script. That is why I reinvented the set using hash
> tables. I don't know how hash tables are different from VHashes or which
> is better.

VHashes is a bit confused in my mind too. ;-)

https://www.gnu.org/software/guile/manual/html_node/VHashes.html


Cheers,
simon

Re: Parameterized packages

[Pierre Neidhardt]

zimoun  writes:

> What is the final aim to have parametrized packages?
> What does it mean "parametrized"?

Easy and composable customization of packages.

> Does it mean extend the transformation options as Ludo described [2].

I think you forgot this reference.  If you meant "like Ludo described in
the original post" I'd say yes, more or less that.

> Could you define what do you mean by "parameters"?
> Sorry to be slow but I am not clear about what we are talking about
> precisely. :-)

No problem.  "Parameters" is a term Ludo came up with, I believe.  We
can always change the naming later.

In my understanding, a parameter is a "first class, globally defined
object -- that comes with a description and a type -- which value can be
used as condition in a package to modify its output.  A package may rely
on multiple parameters to modify its output."

> 1. Because the initial Ludo's message was about glic-locale which is
> somehow an input.

Yes, but in my opinion the example just happened to be an input
modification, it does not have to be.  Gentoo USE flags don't only
change the dependencies, they also change the compilation options, etc.

> 2. The thread spoke also about flags à la Gentoo USE flags.

Indeed, they are essentially the same, but recent discussions are
leading towards limiting Guix parameters a bit more to avoid
a combinatorial explosion in the maintenance complexity.

> 3. Other messages were about set X or Wayland or no-X for this or that 
> package.

Just like Gentoo "X" USE flag I think.

> 4. Another were about change the toolchain of the build systems.
> etc.

In my opinion, we don't need to change anything in the build system.

The point is that parameters can be used anywhere in the package
definition, and thus it can change #:arguments fields like #:python to
customize the python builder.

> All are "parameters". :-)
>
> The solution of 1. and 4. seems to be able to re-write all the implicit 
> inputs.

As Ison mentioned, this might not be reasonable because it might just
break too often.  A better approach could be to only customize the
direct inputs (and build system options).

> The solution of 2. and 3. seems to write, as Ludo mentioned:
>
> --8<---cut here---start->8---
> (define (make-me-a-package option1 option2)
> (package
>   …))
> --8<---cut here---end--->8---

The ellipsis is a bit vague here.  What is this trying to do?

> Well, could you clarify what do you have in mind about "parameters"?
> Just to stay on the wavelength and keep focus. :-)

OK, I'll try with one full example:

--8<---cut here---start->8---
(define-public you-get
  (package
(name "you-get")
(version "0.4.1355")
(PARAMETERS VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
(source (origin
  (method git-fetch)
  (uri (git-reference
(url "https://github.com/soimort/you-get.git;)
(commit (string-append "v" version
  (file-name (git-file-name name version))
  (sha256
   (base32
"0xq7z04hvw3b3npiahlpzhbxsjvam9n9dynplyrkn84dx6k9ajbj"
(build-system python-build-system)
(inputs
 `(("PLAYER" ,(DEREF-PARAM VIDEO-PLAYER))
   ,@(IF (DEREF-PARAM WITH-FFMPEG)
 ;; FOR MULTI-PART AND >=1080P VIDEOS
 `("FFMPEG" ,FFMPEG)
 '( 
(arguments
 `(#:PYTHON ,(DEREF-PARAM PYTHON-VERSION)
   #:phases
   (modify-phases %standard-phases
 ,(WHEN (DEREF-PARAM WITH-FFMPEG)
(add-after 'unpack 'qualify-input-references
  ;; Explicitly invoke the input ffmpeg, instead of whichever one
  ;; happens to be in the user's $PATH at run time.
  (lambda* (#:key inputs #:allow-other-keys)
(let ((ffmpeg (string-append (assoc-ref inputs "ffmpeg")
 "/bin/ffmpeg")))
  (substitute* "src/you_get/processor/ffmpeg.py"
;; Don't blindly replace all occurrences of ‘'ffmpeg'’: the
;; same string is also used when sniffing ffmpeg's output.
(("(FFMPEG == |\\()'ffmpeg'" _ prefix)
 (string-append prefix "'" ffmpeg "'")))
  #t
 (ADD-AFTER 'UNPACK 'TWEAK-PLAYER-SETTINGS
   (LAMBDA* (#:KEY INPUTS #:ALLOW-OTHER-KEYS)
 (MATCH ,(DEREF-PARAM VIDEO-PLAYER)
   (VLC
;; DO SOMETHING WITH VLC.
)
   (MPV
;; DO SOMETHING WITH MPV.
)
   (_
;; ERROR OUT?
)
   #:tests? #f)); XXX some tests need Internet access
(synopsis "Download videos, audio, or images from Web sites")
(description
 "You-Get is a command-line utility to 

Re: Testing the installer

[sirgazil]

  On Sun, 12 Jan 2020 18:34:54 -0500 sirgazil  wrote 
 >   On Sun, 12 Jan 2020 17:13:54 -0500 Ludovic Courtès  
 > wrote 
 >  > Hello Guix!
 >  > 
 >  > One of the lessons from the 1.0.0 screw-up was that we should test the
 >  > graphical installer itself:
 > 
 > And, if possible, not test only using virtual machines, but real ones, 
 > because I remember my installation in a virtual machine went smoothly, but 
 > installing in my real machine was rough (network devices not detected, 
 > installer generated config.scm with truncated UUID, unknown error when 
 > trying to restart installation).
 > 

By the way, in my old notes about my installation of the Guix System 1.0.0, I 
have something about a problem related to the order in which the installer 
checks for network availability. 

My computer had another OS installed at that time. If I recall correctly, I 
started the Guix System installation process, told the installer to use the 
whole disk for installation, and only after formatting the disk, the installer 
told me there was a connection problem, and I couldn't install the system. So I 
couldn't boot to the old OS at that point. Fortunately, people on #guix helped 
me solve the network problem (related to bug) and I could install the Guix 
System.

So, if this is still the case, I think the installer should check for network 
connection before attempting to do any destructive operation.

---
https://sirgazil.bitbucket.io/

Re: Speeding up “guix pull”: splitting modules

[zimoun]

Hi Ludo,

On Sun, 12 Jan 2020 at 00:29, Ludovic Courtès  wrote:

> zimoun  skribis:
>
> > So knowing where the cycles are could help to transform the DaG (not
> > fully acyclic yet) to a DAG. :-)
>
> Unfortunately, the module graph necessarily contains cycles.  The only
> way to avoid them would be to have exactly one module per package, given
> that the package graph is acyclic.

My mind is not clear and I miss a point.

I understand that module graph contains cycles. I am not convinced it
is *necessary* and I am not convinced neither that the only solution
is "one module per package".

Today, the structure of modules is per language and/or topic.
The union of all the package graphs which is big DAG can be
arbitrarily splited into sub-DAGs and these sub-DAGs becomes modules.
And I am not convinced that the size of these sub-DAG is only one
package.


Well, that's another story. :-)
And it will not help for speeding up.

However, working on the graph could help to identify the "hot"
packages and/or modules, IMHO.


Cheers,
simon

Re: Guile 3 migration plan

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> However, on ARMv7, Guile 3.0 segfaults as it’s building:
>
>   
> https://ci.guix.gnu.org/log/8b8c0hxvm9qa5kff168vdr3943cc2s61-guile-next-3.0.0

It seems that the regression happened between 2.9.4 and 2.9.9¹:

  https://ci.guix.gnu.org/build/1687242/details

I’ve reported it here:

  https://issues.guix.gnu.org/issue/39208

Ludo’.

¹ libguile 2.9.5 to 2.9.8 included would fail to build on ARMv7:
  .

Re: Maintaining Jami #3

[Jan]

I didn't really answer your questions earlier, sorry.

On Sun, 19 Jan 2020 10:20:51 +0100
Pierre Neidhardt  wrote:

> Hi Jan,
> 
> I tested the Jami package we have in upstream Guix:
> 
> - It fails to start on my desktop, it only works on my laptop.
What do you mean by desktop, is it even a difference for the OS and the
application?

> - The client kept disconnecting.  I could send a few text messages
> here and there, but most of them didn't go through.
For me it works, I test it in my local network though. The problem
begins when you try communicating with someone behind a strong NAT,
firewall or a badly configured network. Based on my previous experience
I think that's normal - it have never worked well enough, because ISPs
don't want you to have control over your networking - client-server
applications work well, but p2p are broken. Often router firmware is
buggy, outdated and malicious as nonfree software is.

> - I could not give an audio or video call
Works on my machine, except for the bug caused by screen sharing. 

> - I can receive text messages perfectly.
This one works.

> - I can receive calls, but when I click on the "pick up" button, Jami
>   crashes.
Maybe its something hardware specific or depends on the client you call
with - I have no problem answering calls made from Android.
> In general, Jami crashed _a lot_.  I wonder if it's upstream or if we
> have something wrong with our package.
> 
> Did you have a similar experience?
> Does your work fix any of those issues?
> 

I tested 20200115 version now, and it pretty much works the same.
Anyway I fixed my private branch and can continue working, but see no
point in waiting.

What DE are you using? I could try it on my machine. If you run it on
top of Wayland, then you should know Jami is currently broken on
Wayland, they work on fixing it. Aaaand even if client-gnome will
continue being broken like this, they're working on porting
client-windows(Qt) to GNU/Linux and there's a possibility it won't be
broken as well.


Jan Wielkiewicz

Re: Parameterized packages

[zimoun]

On Mon, 20 Jan 2020 at 10:08, Pierre Neidhardt  wrote:
>
> Ludovic Courtès  writes:
>
> > I agree.  ‘package-input-rewriting’ gives us almost what you want, with
> > the limitation that implicit inputs are ignored (which is a good thing
> > sometimes, and a problem in cases where you want to experiment with
> > toolchains, as you write).
> >
> > What we’d need is a variant of ‘package-input-rewriting’ that somehow
> > walks through implicit dependencies.  It could do that by changing the
> > build system, I guess.
>
> To clarify, this does not cover the extent of what "parameters" could
> do, since parameters are not just about input rewriting.

As we discussed here [1]:
<<
> Should we touch implicit inputs, we would have to parse all the
> references and not just the explicit inputs like --with-input does.

My mind is not clear at all.

What is the final aim to have parametrized packages?
What does it mean "parametrized"?
Does it mean extend the transformation options as Ludo described [2].
Does it mean more?
>>

Could you define what do you mean by "parameters"?
Sorry to be slow but I am not clear about what we are talking about
precisely. :-)

1. Because the initial Ludo's message was about glic-locale which is
somehow an input.
2. The thread spoke also about flags à la Gentoo USE flags.
3. Other messages were about set X or Wayland or no-X for this or that package.
4. Another were about change the toolchain of the build systems.
etc.

All are "parameters". :-)

The solution of 1. and 4. seems to be able to re-write all the implicit inputs.

The solution of 2. and 3. seems to write, as Ludo mentioned:

--8<---cut here---start->8---
(define (make-me-a-package option1 option2)
(package
  …))
--8<---cut here---end--->8---


Well, could you clarify what do you have in mind about "parameters"?
Just to stay on the wavelength and keep focus. :-)


[1] https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00274.html




Cheers,
simon

Re: Parameterized packages

[zimoun]

Hi Pierre,

On Fri, 17 Jan 2020 at 17:56, Pierre Neidhardt  wrote:

> In this case, it's trivial to use parameters to influence which compiler
> the build system will use.

I am not sure that "trivial" is the correct word. ;-)


> For gnu-build-system (with gcc, clang, etc.) we can probably do similar
> things already by setting CC.

Yes, and about Rust, Ruby, Perl, etc.

I do think it is the right abstraction. :-)


> The solution to your problem in my opinion is simply to expose just the
> right amount of options through #:arguments for all build systems.
> Would that be satisfactory to you?

Maybe. I am not sure to see what do you mean by '#:arguments'.

If you mean something that does what does
`package-with-explicit-python' to rewrite the 'arguments' field, yes
it is something in this flavor. But generic enough.

For example compare `package-with-explicit-python' and
`package-with-explicit-ocaml'.

Well, something to tweak `lower'. And the question is: what is the
right abstraction?


All the best,
simon

Re: Parameterized packages

[zimoun]

Hi Ludo,

On Sun, 19 Jan 2020 at 21:34, Ludovic Courtès  wrote:

> > I feel something is lacking.
>
> I agree.  ‘package-input-rewriting’ gives us almost what you want, with
> the limitation that implicit inputs are ignored (which is a good thing
> sometimes, and a problem in cases where you want to experiment with
> toolchains, as you write).

Yes. And I do not know what should be exposed, i.e., at which level.

As you probably better know than me, in HPC world, tweaking the
toolchain and its options is an habit (bad or good, not the point :-))


> What we’d need is a variant of ‘package-input-rewriting’ that somehow
> walks through implicit dependencies.  It could do that by changing the
> build system, I guess.

It would be cool! :-)


Cheers,
simon

Re: [bug#39028] [PATCH 5/7] gnu: python-cryptography: Update to 2.8

[宋文武]

Hello Braun, I have pushed the previous 4 patches into master, thank you!

Lars-Dominik Braun  writes:

> * gnu/packages/python-crypto.scm (python-cryptography): Update to 2.8
> (python-cryptography-vectors): Update to 2.8

This is not a small change for me, as 'guix refresh -l python-cryptography' 
says:
  Building the following 167 packages would ensure 367 dependent packages are 
rebuilt...

And I'm not sure about disable tests in python-pyopenssl (in the next
patch), maybe we should update it to 19.1.0.

So I leave this and remain patches for others to pick up, TIA!

Re: Testing the installer

[Jonathan Brielmaier]

On 12.01.20 23:13, Ludovic Courtès wrote:

Hello Guix!

One of the lessons from the 1.0.0 screw-up was that we should test the
graphical installer itself:

   https://guix.gnu.org/blog/2019/gnu-guix-1.0.1-released/

I think we should try to do that before the next release; not doing it
means testing by hand, which also takes a lot of time.


I did a quick test by hand and opened a bug:
https://issues.guix.gnu.org/issue/39199

Re: cmake-build-system: modify-phases picks up wrong %standard-phases

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel  skribis:

> I experience a strange problem: The package below (stripped down to show
> the issue) uses the `qt-build-system`.
>
> When running as shown, the build fails, since the `configure` phase is
> taken from gnu-build-system.
>
> It works fine, when modifying `(@ (guix build cmake-build-system)
> %standard-phases)` instad of just %standard-phases` but - as prepared in
> the line above.
>
> It also works fine when not setting `#:modules`. (Setting `#:modules` is
> required since in the real package definition some phase uses
> `get-string-all` from (ice-9 textual-ports), which needs to be added to
> `#:modules`).
>
> What might cause this issue?


[...]

>   (build-system cmake-build-system)
>   (arguments
>    `(;;#:modules (,@%cmake-build-system-modules)

The problem stems from a confusion between “imported modules” and
“modules in scope” (don’t worry, you’re not the first one to be tripped
up by this!).

‘%cmake-build-system-modules’ and similarly-named variables contain the
closure of the modules to be _imported_ on the build side for
‘cmake-build-system’ to work.

However, the modules that you want _in scope_ are only those used as the
default value of #:modules in ‘cmake-build’, namely:

  ((guix build cmake-build-system)
   (guix build utils))

If you do:

  #:modules ,%cmake-build-system-modules

then you’re also putting (guix build gnu-build-system) in scope, hence
the collision for the ‘%standard-phases’ binding.

HTH!

Ludo’.

Re: Parameterized packages

[Pierre Neidhardt]

Ludovic Courtès  writes:

> I agree.  ‘package-input-rewriting’ gives us almost what you want, with
> the limitation that implicit inputs are ignored (which is a good thing
> sometimes, and a problem in cases where you want to experiment with
> toolchains, as you write).
>
> What we’d need is a variant of ‘package-input-rewriting’ that somehow
> walks through implicit dependencies.  It could do that by changing the
> build system, I guess.

To clarify, this does not cover the extent of what "parameters" could
do, since parameters are not just about input rewriting.

What do you think of my other answer on using parameters to tweak the
`arguments' field?  (E.g. the "python" argument for the python-build-system.)

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


signature.asc
Description: PGP signature