Re: guile-readline bug -- readline module not available

[Jack Hill]

On Fri, 12 Jun 2020, Josh Marshall wrote:


Hello all,

I ran into an issue where the readline module isn't available for the
guile repl after installing `guile-readline`.  It can be replicated
via:

`echo "(use-modules (ice-9 readline))" | guix environment --pure guile
guile-readline -- guile`

So with that, I'm pretty sure it isn't just me.


I think you actually want to be using a different guix environment 
command.


guix environment --pure --ad-hoc guile guile-readline

should get you what you want. The difference is that without --ad-hoc, 
what you're asking for is an environment with all the dependencies of 
guile and guile-readline. This is useful, for instance, if you want to 
work on those packages. In this case, guile is available because 
guile-readline depends on it, but nothing depends on guile-readline, so it 
is not in the environment.


With --ad-hoc, you specify the the packages you want in the environment 
explicitly.


See the manual [0] for more information and more advanced usage of 
environment.


[0] https://guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html

This isn't the first time the --ad-hoc has caused confusion. I tend to use 
that option more often than not. There was previous discussion [1] about 
making environment more friendly to use interactively without breaking 
compatibility, but more work is still needed on that front.


[1] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00126.html

Hope that helps,
Jack

generate commit messages for package updates

[Ricardo Wurmus]

Hi Guix,

I’m currently working on upgrading all Bioconductor packages to the 3.11
release.  The hardest work here is to write commit messages for the 200+
packages that have changed.  Even with the “update” yasnippet and magit
this takes a very long time.

I wrote a little tool to reduce the amount of time needed to create
commits.  It is not fully automatic yet as it requires my input to stage
hunks, but the commit messages it produces take all input changes into
account, which is something the “update” yasnippet does not do.

After “guix refresh -t bioconductor -u”, manually verifying and
implementing the suggested changes, and building all packages, I run
“git add -p” to stage hunks that belong to the same package definition.
Then I run the attached tool to make a commit:

./committer.scm | git commit -F -

The tool works by looking at the unified diff in the staging area and
generating two S-expressions corresponding to the original package
definition and the changed package definition, respectively.  It then
looks at the inputs, propagated-inputs, and native-inputs fields and
generates a GNU ChangeLog-style commit message describing the changes.

Here’s an example diff:

--8<---cut here---start->8---
modified   gnu/packages/bioconductor.scm
@@ -2701,29 +2701,32 @@ gene and isoform level using RNA-seq data")
 (define-public r-karyoploter
   (package
 (name "r-karyoploter")
-(version "1.12.4")
+(version "1.14.0")
 (source (origin
   (method url-fetch)
   (uri (bioconductor-uri "karyoploteR" version))
   (sha256
(base32
-"03jmfgmw35hrgn3pc5lq6pblzhfx9fp4l6dx50rp303lr7kjxp9v"
+"0h0gk4xd95k5phy6qcsv7j931d7gk3p24i2fg4mz5dsk110lpifs"
 (build-system r-build-system)
 (propagated-inputs
- `(("r-regioner" ,r-regioner)
+ `(("r-annotationdbi" ,r-annotationdbi)
+   ("r-bamsignals" ,r-bamsignals)
+   ("r-bezier" ,r-bezier)
+   ("r-biovizbase" ,r-biovizbase)
+   ("r-digest" ,r-digest)
+   ("r-genomeinfodb" ,r-genomeinfodb)
+   ("r-genomicfeatures" ,r-genomicfeatures)
("r-genomicranges" ,r-genomicranges)
("r-iranges" ,r-iranges)
-   ("r-rsamtools" ,r-rsamtools)
("r-memoise" ,r-memoise)
+   ("r-regioner" ,r-regioner)
+   ("r-rsamtools" ,r-rsamtools)
("r-rtracklayer" ,r-rtracklayer)
-   ("r-genomeinfodb" ,r-genomeinfodb)
("r-s4vectors" ,r-s4vectors)
-   ("r-biovizbase" ,r-biovizbase)
-   ("r-digest" ,r-digest)
-   ("r-bezier" ,r-bezier)
-   ("r-bamsignals" ,r-bamsignals)
-   ("r-annotationdbi" ,r-annotationdbi)
("r-variantannotation" ,r-variantannotation)))
+(native-inputs
+ `(("r-knitr" ,r-knitr)))
 (home-page "https://bioconductor.org/packages/karyoploteR/;)
 (synopsis "Plot customizable linear genomes displaying arbitrary data")
 (description "This package creates karyotype plots of arbitrary genomes and
--8<---cut here---end--->8---

…and this is the generated commit message:

--8<---cut here---start->8---
gnu: r-karyoploter: Update to 1.14.0.

* gnu/packages/bioconductor.scm (r-karyoploter): Update to 1.14.0.
[propagated-inputs]: Add r-genomicfeatures.
[native-inputs]: Add r-knitr.
--8<---cut here---end--->8---

Obviously, this can be improved by avoiding the staging area and
operating on all hunks in all selected files, so that more than one
commit can be made at a time.  But I thought I’d share this hack anyway,
crude as it is.

-- 
Ricardo



committer.scm
Description: application/scheme

guile-readline bug -- readline module not available

[Josh Marshall]

Hello all,

I ran into an issue where the readline module isn't available for the
guile repl after installing `guile-readline`.  It can be replicated
via:

`echo "(use-modules (ice-9 readline))" | guix environment --pure guile
guile-readline -- guile`

So with that, I'm pretty sure it isn't just me.

Re: Reducing LLVM closure size

[Julien Lepiller]

Le 12 juin 2020 09:19:48 GMT-04:00, Pierre Neidhardt  a 
écrit :
>Julien Lepiller  writes:
>
>>>By the way, this looks like a bug:
>>>
>>>--8<---cut here---start->8---
 guix refresh -l llvm
>>>Building the following package would ensure 3 dependent packages are
>>>rebuilt: clang-toolchain@10.0.0
>>>--8<---cut here---end--->8---
>>>
>>>Why is only 1 package displayed?
>>
>> Because these are the dependants for llvm@10, but the default llvm is
>llvm@9:
>>
>> guix refresh -l llvm@9
>> Building the following 1180 packages would ensure 2092 lependent
>packages are rebuilt: …
>
>This does not explain why it says "3 dependent packages" but lists only
>one! :)

Because building this one will also rebuild the other two, re-read the sentence 
carefully :)

llvm -> clang -> clang-toolchain

Re: Reducing LLVM closure size

[Oliver Propst]

Well I think regardless that Pierre's efforts are very good and should
be encouraged.


On Fri, Jun 12, 2020 at 2:02 PM Julien Lepiller  wrote:

> Le 12 juin 2020 05:06:32 GMT-04:00, Pierre Neidhardt 
> a écrit :
> >
> >By the way, this looks like a bug:
> >
> >--8<---cut here---start->8---
> >> guix refresh -l llvm
> >Building the following package would ensure 3 dependent packages are
> >rebuilt: clang-toolchain@10.0.0
> >--8<---cut here---end--->8---
> >
> >Why is only 1 package displayed?
>
> Because these are the dependants for llvm@10, but the default llvm is
> llvm@9:
>
> guix refresh -l llvm@9
> Building the following 1180 packages would ensure 2092 lependent packages
> are rebuilt: …
>
> That's not on latest master, so your numbers can vary a bit.
>
>

-- 
-mvh Oliver Propst

Re: Reducing LLVM closure size

[Julien Lepiller]

Le 12 juin 2020 05:06:32 GMT-04:00, Pierre Neidhardt  a 
écrit : 
>
>By the way, this looks like a bug:
>
>--8<---cut here---start->8---
>> guix refresh -l llvm
>Building the following package would ensure 3 dependent packages are
>rebuilt: clang-toolchain@10.0.0
>--8<---cut here---end--->8---
>
>Why is only 1 package displayed?

Because these are the dependants for llvm@10, but the default llvm is llvm@9:

guix refresh -l llvm@9
Building the following 1180 packages would ensure 2092 lependent packages are 
rebuilt: …

That's not on latest master, so your numbers can vary a bit.

Re: Default to the 5.7.X kernel by default

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice 写道：

To get started, you simply


I've merged your bug #41795 with the original discussion at 
.  Lots of useful info there; 
read up!  (And scroll.  A lot.)


Leo Famulari 写道：

I think it's important that we don't wait too long.


Eheh…

T G-R


signature.asc
Description: PGP signature

Re: Default to the 5.7.X kernel by default

[Tobias Geerinckx-Rice]

Romulas,

romulasry 写道：

Would that be a good idea or not?


We're less in need of ideas than volunteers.  There are 5.7 
Linux-Libre kernels already in Guix to support specific ARM 
devices, but the 5.7 kernel configuration hasn't been vetted to 
the same FSDG standards as the 5.4 series from which it diverged. 
This would need to be done for all supported architectures, in 
addition to regular ‘does it boot’ testing.


To get started, you simply copy 
gnu/packages/aux-files/linux-libre/5.4-$ARCH.conf to sources>/.config, then run ‘make oldconfig’.  Then you diff the 
new configuration file against the 5.4, since more will have 
changed than only what you entered interactively.  Then you make 
sure each option makes sense for a generic distribution kernel 
following the FSDG.


I'd close with ‘help wanted’ (and I will!), but this requires 
familiarity with the kernel, the FSDG, and of course Guix.  Still,


Help wanted,

T G-R


signature.asc
Description: PGP signature

Reducing Mesa closure size

[Pierre Neidhardt]

Mesa is a dependency for more or less everything graphical.
Since it's so ubiquitous, can we reduce it's closure size?

--8<---cut here---start->8---
> guix size mesa
store item   totalself
/gnu/store/skxkrhgn9z0fg9hmnbcyfdgzs5w4ryrr-llvm-9.0.1 199.9   
128.5  37.6%
/gnu/store/8jn365r0kk69j1f4b1q2b7aa2qm1xvg1-mesa-19.3.4341.6   
114.6  33.6%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7  10.8%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6   9.6%
/gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10  81.1 
7.9   2.3%
/gnu/store/a8gdwnmpryd39jixzy4xs9p4i7gy17qv-libxcb-1.14 76.2 
4.5   1.3%
...
--8<---cut here---end--->8---

Reducing LLVM would help here.  See the other "Reducing LLVM closure
size" thread.

But Mesa itself can be substantially reduced.  Let's look at the files:

--8<---cut here---start->8---
$ du -h $(find /gnu/store/8jn365r0kk69j1f4b1q2b7aa2qm1xvg1-mesa-19 -type f 
-size +1M) | sort -n
7.5M./lib/libvulkan_radeon.so
7.6M./lib/libxatracker.so.2.5.0
8.4M./lib/libXvMCnouveau.so
8.7M./lib/libvulkan_intel.so
12M ./lib/dri/nouveau_drv_video.so
12M ./lib/vdpau/libvdpau_nouveau.so.1.0.0
14M ./lib/libOSMesa.so.8.0.0
17M ./lib/dri/i915_dri.so
26M ./lib/dri/iris_dri.so
--8<---cut here---end--->8---

Most systems need only one graphics driver.  Allowing the user to choose
which mesa-driver they want could help them save quite a lot.  For
instance,
with a radeon (not radeonsi) I can remove

8.4M./lib/libXvMCnouveau.so
8.7M./lib/libvulkan_intel.so
12M ./lib/dri/nouveau_drv_video.so
26M ./lib/dri/iris_dri.so

which total 55.1 MiB.  Not bad, what do you think?
(libvdpau_nouveau.so.1.0.0 is used by all drivers.)


The "dri" folder is used at least by our Xorg wrapper.
See xorg-wrapper in gnu/services/xorg.scm:

--8<---cut here---start->8---
(define* (xorg-wrapper #:optional (config (xorg-configuration)))
  "Return a derivation that builds a script to start the X server with the
given @var{config}.  The resulting script should be used in place of
@code{/usr/bin/X}."
  define exp
;; Write a small wrapper around the X server.
#~begin
(setenv "XORG_DRI_DRIVER_PATH" (string-append #$mesa "/lib/dri"))
...
--8<---cut here---end--->8---

So what the following strategy:

- Extract the various mesa drivers to separate package,
  e.g. mesa-radeon, mesa-radeonsi, mesa-nouveau, etc.

- Modify xorg-wrapper to accept an extra `drivers'
  parameter.

- Extend xorg-configuration to accept a list of mesa drivers.

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


signature.asc
Description: PGP signature

Reducing LLVM closure size

[Pierre Neidhardt]

Since LLVM is all over the place, _multiple_ versions of LLVM inevitably
end up in anyone's graph.

Can we reduce its closure size?

--8<---cut here---start->8---
> guix size llvm
store item   totalself
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8   
139.3  66.1%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7  17.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6  15.5%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16   1.6 
1.6   0.8%
/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11 71.2 
0.2   0.1%
/gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3  71.2 
0.2   0.1%
total: 210.8 MiB
--8<---cut here---end--->8---

Let's look at what Arch Linux does:

- https://www.archlinux.org/packages/extra/x86_64/llvm/
- https://www.archlinux.org/packages/extra/x86_64/llvm-libs/
- 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/llvm

For the first 2 links, click on
"View the file list for ..." link at the bottom to display the file
list.

"bin" and "include" occupy some 35 MiB.  First thing we can do is split

- either move the libs to a "lib" output,
- or move the "bin" and "include" folder to a new output.

The second approach has the benefit of being less disruptive for dependents.

Now if we look at the PKGBUILD, there are some interesting compilation
flags.  If we remove

  "-DBUILD_SHARED_LIBS:BOOL=TRUE"

and add

  "-DLLVM_BUILD_LLVM_DYLIB=ON"
  "-DLLVM_LINK_LLVM_DYLIB=ON"

it will produce a single libLLVM-10.so library.  This reduces the "lib"
folder size from 107 MiB to 90 MiB.

All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
package (and 210 MiB from its closure).

This would need a bit of testing since LLVM has many versions and many
dependents (a change to llvm-3 rebuilds 1000+ dependents).

By the way, this looks like a bug:

--8<---cut here---start->8---
> guix refresh -l llvm
Building the following package would ensure 3 dependent packages are rebuilt: 
clang-toolchain@10.0.0
--8<---cut here---end--->8---

Why is only 1 package displayed?

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


signature.asc
Description: PGP signature