Re: Packaging Jami progress
On Thu, 14 Nov 2019 22:54:15 +0100 Pierre Neidhardt wrote: > I don't think it's a Jami bug: as I mentioned the same bug affects the > old package so I believe it comes from us. Sorry, didn't read the entire message, I'm a bit tired, because of exams. > The thing is that those are 3 different build processes, so having 3 > packages makes it easier to package. I believe what we have is the > most natural way to go. Okay then. > What do you mean? Guix can be installed on foreign distribution and > Jami would work there the same way it works on Guix System. I mean Windows (ReactOS in the future?), OSX, iOS, Android - Jami is an universal platform. AFAIK there's the option to build with --target=mingw64 or something like this. Could Guix support other targets as well? Some people in the Jami community want to have reproducible builds for Jami, no matter on what distribution. Providing reproducible builds for other systems is going to improve overall security of the platform. > It's the job of the init system to decide what to start. The Guix > pack does not embed any init system information, I don't know if it > can or even if that would make sense. > Wouldn't it be a user service? I'm not sure if I understand this correctly, but autostart on GNU/Linux is handled by different init systems/process supervisors. How is the autostart handled on Guix System? When I searched for the way of adding a program to autostart on Debian-based distributions, I often found tutorials showing how to make an init script or systemd-something, anyway I thought that if libring is a daemon, then there needs to be something written for the Shepherd, but if it's handled as an user service, then it's fine. > I'm not sure there is much more we can do here: regarding the > packaging process, we already have a tutorial (cf. the cookbook) that > covers everything needed to package Jami. (As tough as Jami may be > to package...) I found some things hard/unintuitive, but maybe that's because I didn't entirely read the tutorial. Anyway if I find something worth improving, I'll tell. > Regarding the dependencies, it belongs to upstream > to tell which deps Jami uses; sadly this is not done very well in > their current documentation. We could open an issue I suppose. I'll ask about this. > Cheers! > Jan Wielkiewicz
Re: Packaging Jami progress
Jan writes: > On Thu, 14 Nov 2019 19:07:56 +0100 > Pierre Neidhardt wrote: > >> See https://issues.guix.gnu.org/issue/38211. >> > > Cool, thanks for building it! > As for the issue, I don't know if the Jami version I use is > stable, unfortunately some versions from the tarball repo contain bugs. I don't think it's a Jami bug: as I mentioned the same bug affects the old package so I believe it comes from us. > - what about handling the package in a modular way and instead of > having three separated packages, can we have one package with many > outputs? For example jami:libring, jami:client-gnome, > jami:libringclient, etc. The thing is that those are 3 different build processes, so having 3 packages makes it easier to package. I believe what we have is the most natural way to go. > - support for other operating systems (???) Guix probably doesn't > support this now, but we could build every Jami client in a > reproducible way. What do you mean? Guix can be installed on foreign distribution and Jami would work there the same way it works on Guix System. > - easy to use Jami packages with guix pack for other distributions, > using different init systems (support for autostart)? Or we can > skip this and hope people will install Guix on their systems :) It's the job of the init system to decide what to start. The Guix pack does not embed any init system information, I don't know if it can or even if that would make sense. > - Jami daemon (libring) service for the Shepherd? I could do this, but > I would have to learn about the Shepherd and daemons, since I know > almost nothing. Wouldn't it be a user service? > - a small tutorial about maintaining a package, from the perspective of > someone, who didn't know much about build systems and packaging. > Things like where do you look for the needed dependencies, etc. I'm not sure there is much more we can do here: regarding the packaging process, we already have a tutorial (cf. the cookbook) that covers everything needed to package Jami. (As tough as Jami may be to package...) Regarding the dependencies, it belongs to upstream to tell which deps Jami uses; sadly this is not done very well in their current documentation. We could open an issue I suppose. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Stackage LTS 14
Ah, ok makes sense!
Re: Packaging Jami progress
On Thu, 14 Nov 2019 19:07:56 +0100 Pierre Neidhardt wrote: > See https://issues.guix.gnu.org/issue/38211. > Cool, thanks for building it! As for the issue, I don't know if the Jami version I use is stable, unfortunately some versions from the tarball repo contain bugs. I can ask the devs about it. I wanted to check if Jami compiles at all with the current state of work, not to break already working things. Now, because we know it compiles, I can improve the quality of the package and its dependencies, and of course keep it updated. My ideas: - what about handling the package in a modular way and instead of having three separated packages, can we have one package with many outputs? For example jami:libring, jami:client-gnome, jami:libringclient, etc. - finishing pjproject - the current package doesn't work at all, what works is pjproject-jami, because we disable some features. To prevent further breaking and not to keep a broken package it would be a right thing to do to finish it. - support for other operating systems (???) Guix probably doesn't support this now, but we could build every Jami client in a reproducible way. - easy to use Jami packages with guix pack for other distributions, using different init systems (support for autostart)? Or we can skip this and hope people will install Guix on their systems :) - Jami daemon (libring) service for the Shepherd? I could do this, but I would have to learn about the Shepherd and daemons, since I know almost nothing. - a small tutorial about maintaining a package, from the perspective of someone, who didn't know much about build systems and packaging. Things like where do you look for the needed dependencies, etc. Jan Wielkiewicz
Re: Stackage LTS 14
Hi John, John Soo writes: > When we bump to Stackage 14 can issue 36653 be closed? I think these changes should still be merged (with review and fixes). Eventually Stackage LTS 15 will come out while we’re still on LTS 14. At that point, we will have the same issue with the importer and linter giving us information about LTS 15 when we only want LTS 14. -- Tim
Speaking about Guix at NL-RSE 2019
I'm speaking about Guix at the Netherlands Research Software Engineers Conference 2019 at Amsterdam on November 20 (next Wednesday). https://nl-rse.org/events/NL-RSE19.html I plan for the talk to be very basic and targeted at an audience new to Guix. It will be similar to Ricardo's talk at FOSDEM 2017, but I will mix and match stuff from Ludo's and other people's various talks as well. https://archive.fosdem.org/2017/schedule/event/guixintroduction/ I'm travelling all the way from India. This is my first time to Europe, and I might not travel to Europe again in a long time. I will be in Amsterdam from November 19 to November 25. If anyone is around and would like to meet, do contact me off list. All this is subject to my visa being approved. I will likely know about that within the next 48 hours. Thanks, and happy hacking! :-) signature.asc Description: PGP signature
Re: Stackage LTS 14
Hey everyone, When we bump to Stackage 14 can issue 36653 be closed? - John
Re: Packaging Jami progress
See https://issues.guix.gnu.org/issue/38211. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Packaging Jami progress
Update: I've managed to build libring. Jami should follow soon, stay tuned. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Loading modules built using linux-module-build-system
Hi Ludo,
On Tue, 22 Oct 2019 14:24:51 +0200
Ludovic Courtès wrote:
> I’m wondering if we could avoid clobbering the global profile with the
> kernel and module packages, though (as is currently the case.)
Sounds good.
> > (define* (operating-system-profile os)
> >"Return a derivation that builds the system profile of OS."
> >(mlet* %store-monad
> > - ((services -> (operating-system-services os))
> > - (profile (fold-services services
> > - #:target-type profile-service-type)))
> > + ((kernel -> (operating-system-kernel os))
> > + (services -> (operating-system-services os))
> > + (profile (cons kernel (fold-services services
> > +#:target-type
> > +profile-service-type
> > (match profile
> >(("profile" profile)
> > (return profile)
>
> The value of ‘profile’ above can never match this pattern, or am I
> missing something?
Ah! Now I see it.
> Besides, I wonder how much is missing from (gnu build linux-modules) to
> do this without resorting to kmod. :-)
True :)
> Maybe we should not add this hook by default, to avoid overhead for a
> very unusual use case. The caller of ‘profile-derivation’ could add it
> when needed.
I think the eventual overhead of it is minimal because it can just check
whether "lib/modules" is anywhere in the source and if not, skip everything.
> Thinking more about it, what about handling the union/profile thing in
> ‘operating-system-directory-base-entries’? We could still use
> ‘profile-derivation’ with the hook you wrote, but we’d be able to keep
> that here instead of adding it to (guix profiles).
Should we just change out the "kernel" entry to be the union? After all,
that's what actually happens at runtime as far as the Linux kernel is
concerned.
> Also, if we take that route, we would probably need a
> ‘linux-module-packages’ field in .
Or make the `kernel` field a list, including linux-libre ;-)
pgplJuxMq1JW7.pgp
Description: OpenPGP digital signature
Missing fonts when compiling latex documents
Hi Guix,
I spent a few hours trying to get texi2pdf working on a simple tex
file:
```
\documentclass[10pt]{article}
\usepackage[margin=3cm]{geometry}
\title{\bfseries\Huge My Name}
\author{m...@me.com}
\date{}
\begin{document}
\maketitle
\end{document}
```
I tried installing a bunch of tex packages to get this to compile, but
I kept getting errors about fonts not being found:
```
texlive-generic-pdftex texlive-bin texlive-latex-xkeyval texlive-fonts-
latex texlive-fonts-ec texlive-latex-mflogo texlive-latex-type1cm
texinfo texlive-ae texlive-txfonts texlive-cm-super texlive-fontinst
texlive-graphics-def texlive-kpathsea texlive-latex-psnfss texlive-
latexconfig texlive-metafont-base texlive-latex-base texlive-latex-pdfx
texlive-latex-pgf texlive-latex-geometry texlive-latex-graphics
```
I tried this for example:
```
guix environment -C --ad-hoc texlive-fonts-ec texlive-tex-texinfo
texlive-generic-epsf texinfo coreutils sed texlive-bin grep texlive-
latex-base tar texlive-latex-graphics texlive-latex-geometry
texi2pdf my_tex_file.tex
```
It was not until I installed the "texlive" package that I manged to
compile the .tex file.
I found that the following are the minimum packages required to compile
a simple latex file into pdf:
```
guix environment -C --ad-hoc texinfo coreutils sed grep tar texlive
diffutils
```
Maybe this would be straight forward to some users but it took me some
time to figure out which packages are needed since I don't know much
about latex. I found a lot of information about how to install the
fonts on other distros when I searched online, but for guix I had to
experiment on my own, so maybe this information should be mentioned
somewhere, maybe a blog post? Or maybe someone will stumble on this
post.
Anyway, just posting my findings :-)
signature.asc
Description: This is a digitally signed message part
Re: Stackage LTS 14
Timothy Sample writes: > Hi John, > > John Soo writes: > >> Xmobar builds properly with all the extensions but I haven't really given it >> a spin. I did have to >> add a few more packages, but I think they are reasonable. > > This is fantastic! Thanks so much for your help. > >> I think the update to ghc after 8.4 will fix a segfault that i have been >> experiencing :). > > \o/ > >> Here are my patches, is this the place to put them? > > This is perfect. I have “ngless” building, too, so we are well on our > way. I will incorporate these patches and start working on the final > steps of getting these changes into master. This is amazing work, thank you both. :-) I've read some of the changes and they LGTM. If Cuirass is happy, I think you can go ahead and merge the branch. \o/ signature.asc Description: PGP signature
Re: Stackage LTS 14
Hi John, John Soo writes: > Xmobar builds properly with all the extensions but I haven't really given it > a spin. I did have to > add a few more packages, but I think they are reasonable. This is fantastic! Thanks so much for your help. > I think the update to ghc after 8.4 will fix a segfault that i have been > experiencing :). \o/ > Here are my patches, is this the place to put them? This is perfect. I have “ngless” building, too, so we are well on our way. I will incorporate these patches and start working on the final steps of getting these changes into master. Thanks again! -- Tim
Re: wip blog post: running Guix System on ARM
Hi Julien, On Wed, 13 Nov 2019 22:21:54 +0100 Julien Lepiller wrote: > Hi, attached is a draft for a blog post (or a section in the cookbook) > for explaining how to install the Guix System on an ARM board. WDYT? I guess it can't hurt to describe this stuff as it works now, but the goal is not to need to do any of this complicated stuff--and there's no fundamental reason why one would have to. There are projects like buildroot which have all the u-boot configuration (and more--like the partitioning, which also can sometimes have funny requirements, for example on Allwinner) that Guix could import to generically install Guix on any ARM board. Eventually there will be an importer for those. The kernel module situation is awful. It would be good if we could automate it more in the future (if the information is statically available in the first place). If the foreign distribution doesn't have it, not much can be done. I'm not sure what buildroot does--whether we have kernels with different built-in modules for different modules or what? Some comments on your draft: (1) You absolutely can use an existing u-boot to boot Guix (bugs nonwithstanding). Guix only generates "extlinux.conf" and doesn't touch the other u-boot config. The default u-boot-bootloader installer (as opposed to config installer) is "do nothing". So your existing u-boot (for example in NAND flash) would display a boot menu and then you could boot from SSD or SD, for example. If this doesn't work, please file a bug report. Also, the old generations should be able to be selected, too. Doesn't it work? FWIW, I'm also using an existing Grub inside Libreboot to boot Guix on X86, with exactly the same mechanism (grub.conf generated, grub-install not invoked). (2) If possible, can you mention that non-exported, non-documented variables are subject to change? I mean I like that "@@" is possible, but let's make sure the user knows that it would be better to contact us for including his stuff if it's supposed to continue to work. pgpMg3GLHY34d.pgp Description: OpenPGP digital signature
Re: wip blog post: running Guix System on ARM
On Thu, Nov 14, 2019 at 10:29:22AM +0100, Pierre Neidhardt wrote: > Neat, thanks for this article! > Yes, thank you! I have not tried yet though. Maybe add the top add instructions what to do if installation fails (i.e. flash the SD with another operating system and start anew). > > Make sure there is an empty /etc, or the new system won't boot > > properly. > > Isn't this a bug in Guix? > > Is installing on the same drive an “official” installation method? I mean, it probably works and people can ask for help after using it, but remaining files from the old system could be problematic. If this is dangerous (is it?) then please add a warning. Also, I wonder: On Wed, Nov 13, 2019 at 10:21:54PM +0100, Julien Lepiller wrote: > Then, initialize the system with: > > ```bash > mount /dev/sda1 /mnt > mkdir /mnt/etc > $EDITOR /mnt/etc/config.scm # create the configuration file > guix system init /mnt/etc/config.scm /mnt > ``` So the mmcblk you install on is different from the running system’s mmcblk, otherwise how could you keep your old system’s SD card? Then the mmcblk device number will change on the running Guix System and the config.scm will have to be adapted to use the mmcblk before reconfiguring from the installed Guix System. Otherwise if you install on the same mmcblk as the running system, then maybe this could fail if the u-boot partition is too small? That would leave both the existing operating system and the new Guix System unusable. Maybe there should be more of a warning. > ### The bootloader > > Because of the way the Guix System is designed, you cannot use an already > existing bootloader > to boot your system: it wouldn't know where to look for the kernel, because > it doesn't know > its store path. It wouldn't be able to let you boot older generations > either. Most boards > use the u-boot bootloader, so we will focus on that bootloader here. More generally, since no old Guix generation can be selected in pure u-boot when booting (I think) this warrants more of a warning that one important feature of Guix is missing. For later: What would a rescue of a broken Guix System look like? I do not know if all this works better with grub-efi on supported ARM systems; I have never tried. For later, maybe in the manual: Maybe it would be interesting how to create a reusable SD install image for Guix. I also remember there were discussions about making ci.guix.gnu.org build a two-part bootable installation image in the past, one part with a bootloader for a specific board and another part general for all boards. Regards, Florian
Re: wip blog post: running Guix System on ARM
Hi, Thank you for the article! I would find interesting to point somewhere in your post to these previous blog posts [1] [2] [3] about ARM and Guix. :-) [1] https://guix.gnu.org/blog/2017/porting-guixsd-to-armv7/ [2] http://guix.gnu.org/blog/2018/guix-on-android/ [3] http://guix.gnu.org/blog/2019/guix-days-bootstrapping-arm/ à tantôt, simon
Re: Stackage LTS 14
Hi Tim,
Xmobar builds properly with all the extensions but I haven't really given
it a spin. I did have to add a few more packages, but I think they are
reasonable.
I think the update to ghc after 8.4 will fix a segfault that i have been
experiencing :).
Here are my patches, is this the place to put them?
- John
From 579f1152545ca873c2a38a9bd5ef5c48f394 Mon Sep 17 00:00:00 2001
From: John Soo
Date: Thu, 14 Nov 2019 01:10:01 -0800
Subject: [PATCH 2/5] gnu: Add ghc-timezone-series.
* gnu/packages/haskell-xyz.scm (ghc-timezone-series): Add it.
---
gnu/packages/haskell-xyz.scm | 23 +++
1 file changed, 23 insertions(+)
diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index 3f61800d00..c80d905c86 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -11102,6 +11102,29 @@ timer manager.")
used CPU time of monadic computation with an IO base.")
(license license:bsd-3)))
+(define-public ghc-timezone-series
+ (package
+ (name "ghc-timezone-series")
+ (version "0.1.9")
+ (source
+(origin
+ (method url-fetch)
+ (uri
+ (string-append
+ "mirror://hackage/package/timezone-series/timezone-series-"
+ version ".tar.gz"))
+ (sha256
+ (base32
+ "1blwgnyzqn917rgqkl4dncv9whv3xmk0lav040qq0214vksmvlz5"
+ (build-system haskell-build-system)
+ (home-page "http://projects.haskell.org/time-ng/;)
+ (synopsis "Enhanced timezone handling for Time")
+ (description
+"This package endows @code{Data.Time}, from the time package, with several
+data types and functions for enhanced processing of timezones. For one way to
+create timezone series, see the ghc-timezone-olson package.")
+ (license license:bsd-3)))
+
(define-public ghc-tldr
(package
(name "ghc-tldr")
--
2.24.0
From abb2062d2df2727584570091fd72331577dd3781 Mon Sep 17 00:00:00 2001
From: John Soo
Date: Thu, 14 Nov 2019 01:25:58 -0800
Subject: [PATCH 4/5] gnu: Add ghc-dbus.
* gnu/packages/haskell-xyz.scm (ghc-dbus): Add it.
---
gnu/packages/haskell-xyz.scm | 51
1 file changed, 51 insertions(+)
diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index 28c2ffd183..5b8b785a81 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -2665,6 +2665,57 @@ It includes hashing functions for all basic Haskell98 types.")
"This module provides set and multiset operations on ordered lists.")
(license license:bsd-3)))
+(define-public ghc-dbus
+ (package
+(name "ghc-dbus")
+(version "1.2.7")
+(source
+ (origin
+(method url-fetch)
+(uri
+ (string-append
+ "mirror://hackage/package/dbus/dbus-"
+ version ".tar.gz"))
+(sha256
+ (base32
+"0ypkjlw9fn65g7p28kb3p82glk7qs7p7vyffccw7qxa3z57s12w5"
+(build-system haskell-build-system)
+(inputs
+ `(("ghc-cereal" ,ghc-cereal)
+("ghc-conduit" ,ghc-conduit)
+("ghc-exceptions" ,ghc-exceptions)
+("ghc-lens" ,ghc-lens)
+("ghc-network" ,ghc-network)
+("ghc-random" ,ghc-random)
+("ghc-split" ,ghc-split)
+("ghc-th-lift" ,ghc-th-lift)
+("ghc-vector" ,ghc-vector)
+("ghc-xml-conduit" ,ghc-xml-conduit)
+("ghc-xml-types" ,ghc-xml-types)))
+(native-inputs
+ `(("ghc-extra" ,ghc-extra)
+("ghc-quickcheck" ,ghc-quickcheck)
+("ghc-resourcet" ,ghc-resourcet)
+("ghc-tasty" ,ghc-tasty)
+("ghc-tasty-hunit" ,ghc-tasty-hunit)
+("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)))
+;; FIXME - Some tests try to talk to network.
+(arguments `(#:tests? #f))
+(home-page
+ "https://github.com/rblaze/haskell-dbus#readme;)
+(synopsis
+ "A client library for the D-Bus IPC system")
+(description
+ "D-Bus is a simple, message-based protocol for inter-process
+communication, which allows applications to interact with other parts
+of the machine and the user's session using remote procedure
+calls. D-Bus is a essential part of the modern Linux desktop, where
+it replaces earlier protocols such as CORBA and DCOP. This library
+is an implementation of the D-Bus protocol in Haskell. It can be used
+to add D-Bus support to Haskell applications, without the awkward
+interfaces common to foreign bindings.")
+(license license:asl2.0)))
+
(define-public ghc-deepseq-generics
(package
(name "ghc-deepseq-generics")
--
2.24.0
From 436b2f7079fe12b71dace446dff0cc086f6b74a6 Mon Sep 17 00:00:00 2001
From: John Soo
Date: Wed, 13 Nov 2019 23:59:23 -0800
Subject: [PATCH 1/5] gnu: Add ghc-alsa-mixer.
* gnu/packages/haskell-xyz.scm (ghc-alsa-mixer): Add it.
---
gnu/packages/haskell-xyz.scm | 23 +++
1 file changed, 23 insertions(+)
diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index e952ab46c0..3f61800d00 100644
---
Re: wip blog post: running Guix System on ARM
Hi Julien,
Julien Lepiller writes:
> Hi, attached is a draft for a blog post (or a section in the cookbook)
> for explaining how to install the Guix System on an ARM board. WDYT?
LOL! \O/
This should be a cookbook section, and released soon unless other people
find some error or important things missing (I still do not use some ARM
SoC, but hope to test soon)
What about to start a wip-cookbook-install-on-arm branch with a 1/2
weeks time frame to allow patch proposals from interested
parties?... then publish? :-)
I have just a couple of comments and one typo... BTW discussion based on
my comments should be postponed after your section is published in the
cookbook, since I don't have patch proposals :-D
[...]
> Most boards can be booted from an existing GNU+Linux distribution. You will
> need to install a distribution (any of them) and install GNU Guix on it, using
> e.g. the installer script.
Is it possible to install to SDD (eventually with external HDD) using
another host (e.g. my laptop) with `guix system disk-image...` and then
``dd ... of=/dev/sdX`` on SDD?
[...]
> ### The kernel modules
[...]
AFAIU this is the only "tricky" part for the user: can we find a way for
Guix to help them automagically populate the list of needed initrd
kernel modules for their SoC?
> Your own board may need other kernel modules to boot properly, however it is
> hard to discover
> them. Guix can tell you when a module is missing in your configuration file
> if it is loaded
> as a module. Most distros however build these modules in the kernel
> directly, so Guix cannot
> detect them reliably. Another way to find what drivers might be needed is to
> look at the output
> of `dmesg`. You'll find messages such as:
This implies that we are booting a distro on the SoC, so (if possible)
we cannot install using `guix system disk-image`. This means that the
only way to make Guix automagically know the list of base modules needed
for each SoC should be to... define them in Guix.
Should be possible to extend (gnu system linux-initrd) whith code
defining default-initrd-modules if string-match some specific SoC
architectures (are they detected?) ?
--8<---cut here---start->8---
(define* (default-initrd-modules
#:optional
(system (or (%current-target-system)
(%current-system
"Return the list of modules included in the initrd by default."
(define virtio-modules
;; Modules for Linux para-virtualized devices, for use in QEMU guests.
'("virtio_pci" "virtio_balloon" "virtio_blk" "virtio_net"
"virtio_console" "virtio-rng"))
`("ahci" ;for SATA controllers
"usb-storage" "uas" ;for the installation image etc.
"usbhid" "hid-generic" "hid-apple" ;keyboards during early boot
"dm-crypt" "xts" "serpent_generic" "wp512" ;for encrypted root partitions
"nls_iso8859-1";for `mkfs.fat`, et.al
,@(if (string-match "^(x86_64|i[3-6]86)-" system)
'("pata_acpi" "pata_atiixp";for ATA controllers
"isci") ;for SAS controllers like Intel C602
'())
,@virtio-modules))
--8<---cut here---end--->8---
I mean something like adding a proper form of this pseudocode:
--8<---cut here---start->8---
,@(if (string-match "^()-" system)
'("sd_mod" "ahci_sunxi";for sunxi ATA controller
"sunxi-mmc") ;for sunxi MMC
'())
--8<---cut here---end--->8---
Obviously there should be quite some work to do to extend our
default-initrd-modules this way for each SoC (or class of SoCs) since we
should find them reading some appropriate documentation or testing
things like you described in this draft, but once done it's forever and
for all :-)
> Installing the Guix System
> --
[...]
> In this scenario, we use the foreign system as we would the installer iso,
> using the manual
> installation procedures described in the manual. Essentially, you have to
> partition your SSD
> to your liking, format your new partations and make sure to reference the
> correct partition
^ i (typo)
[...]
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
signature.asc
Description: PGP signature
Re: gnu: python: Update to 3.8.0.
Hi Gábor, Marius, Guix! Le 11/13, Gábor Boskovits a écrit : > Tanguy Le Carrour ezt írta > > ``` > > $ ./pre-inst-env guix build --no-grafts --rounds=2 python@3.8 > > ``` > > > > This works! \o/ > > > > Unfortunately, I only have a vague idea of what a graft is and what it > > is used for! … shame on me! ^_^' > > So, it goes without saying that I have no clue what the next step should > > be! :-) > > > This actually means that the build is ok as is, so if there are no other > things beside this issue, I would say it is safe to push. Thanks for your help guys! I've submitted it as bug #38208: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38208 Regards, -- Tanguy
