Hoping to donate/sell a Talos II motherboard

[jbranso]

Hello you fabulous developers!

My friend has a spare Talos II motherboard that is currently sitting in his 
house 
in Indiana USA collecting dust.

https://www.raptorcs.com/TALOSII/

I have convinced him to donate/sell it to an open source project or developer.

I reached out to Richard Stallman, and he agreed to take the board.  I am 
certain that the
FSF would put it to good use.  My friend and I have not yet decided, to whom we 
will give 
the motherboard.  Is it possible that I could give it to someone or project, 
such that all 
parties here would benefit?

Is there any project or developer here that would be willing to take this 
motherboard and create 
virtual machines that other projects could have access to?

Thoughts?

Thanks,

Joshua Branson
FOSS enthusiast 
https://gnucode.me

Re: universal aarch64/riscv64 images

[Vagrant Cascadian]

On 2023-02-27, Efraim Flashner wrote:
> I've been thinking some about how we create our disk images for aarch64
> devices and how we'll eventually create images for riscv64 devices.
> Currently we use u-boot to load extlinux to boot linux. I propose we use
> u-boot with its EFI interface to load grub-efi to boot linux.
>
> Major benefit of this is that we can create one generic aarch64 image
> using raw-with-offset to create the image and then ship a separate
> script to flash either the SD card or an SPI chip or whatever someone
> wants.

It is certainly worth exploring this!

That said...

By default u-boot will pass a device-tree from the one included u-boot,
which may or may not be compatible with the kernel you want to
boot. There is a mechanism for grub to load a specific device-tree,
but... that will be device-specific again, kind of weakening the
benefits of a device-agnostic "universal" image. Or fix grub to support
a device-tree-directory (much like u-boot syslinux/extlinux support).

U-boot does not (yet?) implement EFI variables, such as the boot order
for EFI to load, so you have to use the fallback /EFI/BOOT/BOOTX64.efi
path, rather than, say, /EFI/GUIX/GRUBX64.efi.

There are probably more surprises!


Ideally, you could build an image that supports both grub-efi and one of
u-boot's other boot methods (boot.scr, syslinux/extlinux style menu,
etc.) ... fundamentally speaking, I do not see any compelling reason you
could not have both grub-efi/grub.cfg and extlinux.conf on the same boot
media, and I have manually built images that do exactly that.

Then people can "bring their own boot firmware" either by using a system
with EFI already out of the box, or installing u-boot (possibly shipped
with guix) to other media, or directly onto the image itself. Or using
https://tow-boot.org, a u-boot fork for some platforms configured to be
installed outside of the boot media when possible (e.g. SPI or eMMC boot
partitions).

For maximal compatibility, I would suggest the first partition should
start at 16MB with an MBR/DOS-style partition table(GPT is basically
incompatible with sunxi64), leaving the rest of the image empty up till
the first partition, so that you can install u-boot directly to the
image if needed or desired. Welcome to the festival of rabbit holes!


live well,
  vagrant


signature.asc
Description: PGP signature

universal aarch64/riscv64 images

[Efraim Flashner]

I've been thinking some about how we create our disk images for aarch64
devices and how we'll eventually create images for riscv64 devices.
Currently we use u-boot to load extlinux to boot linux. I propose we use
u-boot with its EFI interface to load grub-efi to boot linux.

Major benefit of this is that we can create one generic aarch64 image
using raw-with-offset to create the image and then ship a separate
script to flash either the SD card or an SPI chip or whatever someone
wants. We also don't need to reflash u-boot at every reconfigure (I
couldn't follow the code well enough to see if that's currently the
case), just regenerate extlinux or grub-efi like we do on x86_64.

Currently here's the script to install u-boot on the disk image for a pine64:

(define install-allwinner64-u-boot
  #~(lambda (bootloader root-index image)
  (let ((spl (string-append bootloader 
"/libexec/u-boot-sunxi-with-spl.bin"))
(u-boot (string-append bootloader 
"/libexec/u-boot-sunxi-with-spl.fit.itb")))
(write-file-on-device spl (stat:size (stat spl))
  image (* 8 1024))
(write-file-on-device u-boot (stat:size (stat u-boot))
  image (* 40 1024)

And in the OS config:

(bootloader (bootloader-configuration
 (bootloader u-boot-pine64-lts-bootloader)
 (targets '("/dev/vda"

This would transition to (work in progress):

(define install-allwinner64-u-boot
  #~(lambda (bootloader root-index image)
  (let ((spl (string-append bootloader 
"/libexec/u-boot-sunxi-with-spl.bin"))
(u-boot (string-append bootloader 
"/libexec/u-boot-sunxi-with-spl.fit.itb")))
(write-file-on-device spl (stat:size (stat spl))
  image (* 8 1024))
(write-file-on-device u-boot (stat:size (stat u-boot))
  image (* 40 1024)

;; This needs to be fixed up to actually work!!
;; To be run (as root): 'u-boot-installer-pine64-lts /dev/sda'
(define-public u-boot-installer-pine64-lts
  (program-file "u-boot-installer-pine64-lts"
#~((let ((bootloader u-boot-pine64-lts)
 (image $1)))
   #$(install-allwinner-u-boot

(bootloader (bootloader-configuration
 (bootloader grub-efi)
 (targets '("/dev/vda"

(extra-special-file `(("/sbin/flash-u-boot" ,u-boot-installer-pine64-lts)))



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


signature.asc
Description: PGP signature

Re: Question on the process of packge withdrawal

[Leo Famulari]

On Mon, Feb 27, 2023, at 12:12, Maxim Cournoyer wrote:
> I think packages removal should go to the patch tracker, with a CC to
> guix-devel to give more visibility to let time for all parties to
> comment or find a solution (perhaps a maintained fork exists, etc.)

I agree that removal should go through the patch tracker. However, for a case 
like this one, I don't think there's any reason to wait very long before pushing

>From the users' point of view, the package is effectively already gone, 
>because it does not build. 

It's confusing and frustrating for the list of available packages in the UI to 
include broken packages, so I suggest that speedy removal is best.

Re: Feedback on indentation rules (was: [PATCH 0/5] Add support for the RPM format to "guix pack")

[Efraim Flashner]

On Thu, Feb 23, 2023 at 05:20:55PM -0500, Maxim Cournoyer wrote:
> -CC bug#61255
> +CC guix-devel
> 
> Hi Ludovic and guix-devel readers,
> 
> Ludovic Courtès  writes:
> 
> > Hi,
> >
> > Maxim Cournoyer  skribis:
> >
> >> Ludovic Courtès  writes:
> >>
> 
> [...]
> 
> >>> I’m not convinced by the indentation rule for ‘gexp->derivation’ added
> >>> in 82daab42811a2e3c7684ebdf12af75ff0fa67b99: there’s no reason to treat
> >>> ‘gexp->derivation’ differently from other procedures.
> >>
> >> The benefit I saw was that writing
> >>
> >>  (gexp->derivation the-name
> >>   #~(begin
> >>  (the
> >>(multi-line
> >> (gexp)
> >
> > I understand, but you know, it’s best to avoid unilaterally changing
> > established conventions.  :-)
> >
> > If and when there’s consensus about this change, (guix read-print)
> > should be updated.
> 
> OK.  I'm not against soliciting more opinions; I'm CC'ing guix-devel,
> hoping some opinionated individuals tip in on this 2021
> 82daab42811a2e3c7684ebdf12af75ff0fa67b99 commit, more specifically, the
> part that change the indentation rules for .dir-locals.el like this:
> 
> --8<---cut here---start->8---
> +   (eval . (put 'gexp->derivation 'scheme-indent-function 1))
> --8<---cut here---end--->8---
> 
> In the same spirit there was also
> b1c25e2ce364741d1c257d3bb3ab773032807a80 (".dir-locals.el: Add
> indentation rule for computed-file.") made more recently (last month).
> 
> The idea was to be able to format gexp->derivation like this:
> 
> --8<---cut here---start->8---
>   (gexp->derivation "check-deb-pack"
> (with-imported-modules '((guix build utils))
>   #~(begin
>   (use-modules (guix build utils)
>(ice-9 match)
>(ice-9 popen)
>(ice-9 rdelim)
>(ice-9 textual-ports)
>(rnrs base))
> [...]
> --8<---cut here---end--->8---
> 
> Rather than like this:
> 
> --8<---cut here---start->8---
>   (gexp->derivation "check-deb-pack"
> (with-imported-modules '((guix build utils))
>   #~(begin
>   (use-modules (guix build utils)
>(ice-9 match)
>(ice-9 popen)
>(ice-9 rdelim)
>(ice-9 textual-ports)
>(rnrs base))
> --8<---cut here---end--->8---
> 
> (or having to use another 'builder' variable, for example).
> 
> What do you all think?

The second one is wy to indented. For myself I sometimes end up
wrapping the lines (although I don't love it) so it looks like this:

   (gexp->derivation
 "check-deb-pack"
 (with-imported-modules '((guix build utils))
   #~(begin
   (use-modules (guix build utils)
(ice-9 match)
(ice-9 popen)
(ice-9 rdelim)
(ice-9 textual-ports)
(rnrs base))

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


signature.asc
Description: PGP signature

Re: Python

[Lars-Dominik Braun]

Hi,

> I updated it to its latest version under its current name python-cheetah,
> but would suggest to rename it to python-ct3. What do you think?

I don’t think we should follow PyPi’s names strictly. python-cheetah3
makes much more sense than python-ct3. That’s what upstream-name is for.

Lars

Re: Python

[Lars-Dominik Braun]

Hi,

> Do we have a list of packages in the python importer that can be removed
> from inputs? Like already exists for hackage (and maybe others)?
I’m not aware of any list like that and to compile it we’d probably
have to build all python-* packages and check whether any of their
installed modules collides with anything the python package itself
provides (where collision does not necessarily mean file collision,
but package namespace collision in the Python world).

Cheers,
Lars

Re: Oniro or Guix on Zephyr kernel?

[Efraim Flashner]

On Fri, Feb 24, 2023 at 01:36:06PM -0500, Mitchell Schmeisser via Development 
of GNU Guix and the GNU System distribution. wrote:
> jbra...@dismail.de writes:
> 
> >> Guix System, 1 Gig of ram, etc, due to the package builder and Guix/Nix 
> >> daemon? If it was possible
> >> to declare an instance of Guix System that did not include those and only 
> >> used cross-compiled
> >> packages, could some portion of Guix System function in a similar way as 
> >> Oniro, or is that a
> >> nonsense question?
> 
> What I understand your question to be is "Can we use Guix to describe an
> embedded operating system which does not run Guix?" and I think the
> answer is probably. I don't think the guix daemon is technically required
> for the shepherd to boot (being the daemon is a shepherd process
> itself).

I can answer this. I built a one-off Guix image of gparted and it
doesn't have the guix-daemon service included.

> I don't think it's a good idea because you need the daemon in order to
> use `guix deploy`. Otherwise you have to make an installation image and
> it can become "involved."

If you were willing to forgo `guix deploy` (and guix install, and really
any package management) and just reflash it every time then the memory
constraints go down to whatever the running programs require.

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


signature.asc
Description: PGP signature

Re: Qt in core-updates (was: KDE in core-updates)

[Efraim Flashner]

On Sun, Feb 26, 2023 at 09:38:43PM -0500, kiasoc5 wrote:
> On 2/26/23 18:43, Philip McGrath wrote:
> > Hi,
> > 
> > On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote:
> > > 
> > > In any case, I realised that we are still compiling most packages 
> > > (including
> > > KDE) with Qt 5, which is seriously outdated (not maintained any more in 
> > > the
> > > free version since May 2021). Qt 6.3 support will end in April 2023, that
> > > of the current version Qt 6.4 in September 2023. So we have the work 
> > > carved
> > > out for a (yet to be created) Qt/KDE team.
> > > 
> > 
> > Note that KDE maintains a patch collection for Qt 5.15:
> > https://community.kde.org/Qt5PatchCollection
> > 
> > There was an announcement here:
> > https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection
> > 
> > Patches are exclusively backports of bugfixes that have already been 
> > committed
> > to upstream Qt 6, except that patches for Qt 5.15 components removed in Qt 6
> > are also accepted. The patches are curated by a small group of KDE 
> > developers
> > who also have commit privileges in the upstream Qt Project (as distinct from
> > the Qt Company).
> > 
> > I think out Qt 5 packages should be based on the KDE patch collection.
> > 
> > The patches are maintained in Git repositories with the same structure as
> > upstream Qt. They could be extracted with `git format-patch v5.15.3-lts-
> > lgpl..origin/kde/5.15` and added to "gnu/packages/patches/", or we could 
> > just
> > change the origins for Qt 5 to point to KDE's repositories, e.g. this one 
> > for
> > qt-base: https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15
> 
> The KDE patchset moves quickly and does not have tagged releases. If that
> proves difficult we could also just bump the QT5 version to 5.15.8, which is
> freely available.

This is something we should probably do anyway.

We should also try to keep qtwebengine patched as much as possible,
since it is a web engine :)

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


signature.asc
Description: PGP signature

Re: Python

[Efraim Flashner]

On Fri, Feb 24, 2023 at 07:08:44PM +0100, Lars-Dominik Braun wrote:
> Hi Andreas,
> 
> sorry, I can’t quite keep up with the Python issues on core-updates
> right now :(
> 
> > Yet another python failure: python-pathlib
> this is a backport of Python’s built-in pathlib library. It should be
> dropped as a dependency for all of these packages, since our Python is >=
> 3.4 – the version pathlib was introduced into the standard library. And
> then drop the package entirely.

Do we have a list of packages in the python importer that can be removed
from inputs? Like already exists for hackage (and maybe others)?

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


signature.asc
Description: PGP signature

Re: Follow-up on julia import script

[Development of GNU Guix and the GNU System distribution.]

On 2023-02-27 14:46, Simon Tournier wrote:

>
> Oh cool!  Thanks.
>
>> - we don't have a `hash` field in the json, tough we might be able to
>>   get it by parsing Versions.toml additionally to the json. This I can
>>   do with a very simple parser.
>
> Do you mean Versions.toml from General registry?

That's what I meant, but it seems indeed impossible. In the hypothesis
this juliahub script gets merged, what should we do? Really cloning the
repository and getting it or rather just provide a given (false) hash?

-- 
Best regards,
Nicolas Graves

Re: Question on the process of packge withdrawal

[Maxim Cournoyer]

Hi,

Sharlatan Hellseher  writes:

[...]

>   Other example
>   
> 
>   the reason it's not updated at  -
>   development was moved to .

The reason this one was removed was that it had not built since 2018,
and nobody offered to do the work to package the missing Go things to
update it.  It was discussed in the associated bug [0].

[0]  https://issues.guix.gnu.org/33614

>   That tendency concerns me as a packager it's not clear for me which
>   criterias were used to make a division to withdraw the package(s). The
>   age of project is not always a good measure for example example,
>   [Common Lisp] ecosystem has quite ancient packages (5-8y old of not
>   touched since the last commit) but still in active use (check
>   [pgloader])
>
>   It's an open discussion to drag some attention to this case and
>   compile some common seance checklist before removing package from Guix
>   ecosystem. From my experience it's sometimes hard to have new package
>   to be included :).

I think packages removal should go to the patch tracker, with a CC to
guix-devel to give more visibility to let time for all parties to
comment or find a solution (perhaps a maintained fork exists, etc.)

-- 
Thanks,
Maxim

Re: Using Guix inside a Guix container

[Konrad Hinsen]

Ludovic Courtès  writes:

> That’s an interesting use case!  I guess we have a hard-enough time
> getting the message through regarding the environment of tasks that we
> didn’t really consider the environment of the “driver”.

It takes something messy such as Snakemake to illustrate the importance
of this.

> (Well, in a way, GWL and Guix-Jupyter sidestep the issue by integrating
> the mechanism to declare task environments.)

OK, let's pass a law that workflows must be written in Guile or in a
language implemented in Guile ;-)

> I’d be inclined to add a new ‘-W’ (say) option to (1) share the whole
> store, and (2) share the daemon socket.  That would be the documented
> way to create a container with support for nested containers.

Sounds good to me!

> That one’s interesting.  Reported here:
>
>   https://issues.guix.gnu.org/61690
>
> At least there’s a workaround: using ‘-CN’ in the nested container.

That's already good to know.

Thanks,
  Konrad.

Re: Follow-up on julia import script

[Simon Tournier]

Hi Nicolas,

On lun., 27 févr. 2023 at 12:37, Nicolas Graves via "Development of GNU Guix 
and the GNU System distribution."  wrote:

> What we get from juliahub is really not bad, since it's really close to
> what we have in other importers.

Oh cool!  Thanks.


> - we don't have a `hash` field in the json, tough we might be able to
>   get it by parsing Versions.toml additionally to the json. This I can
>   do with a very simple parser.

Do you mean Versions.toml from General registry?

Well, I do not think it is straightforward to go from Git SHA1 hash to
NAR SHA256 hash, to put it mildly. :-)  Because two points:

  1. Git uses one way for serializing and NAR is another.
  2. SHA1 is one hash function and SHA256 is another.

1. Git uses one way for serializing and NAR is another.  From
Versions.toml [0], it reads,

--8<---cut here---start->8---
["0.6.41"]
git-tree-sha1 = "3cfdb31b517eec4173584fba2b1aa65daad46e09"
--8<---cut here---end--->8---

0: 


--8<---cut here---start->8---
$ git -C Zygote.jl log -1 --oneline
467 (HEAD, tag: v0.6.41) un-bump version

$ guix hash -S git -H sha1 -f hex -x Zygote.jl
3cfdb31b517eec4173584fba2b1aa65daad46e09
--8<---cut here---end--->8---

Let only replace the serializer from Git to NAR:

--8<---cut here---start->8---
$ guix hash -S nar -H sha1 -f hex -x Zygote.jl
85fc67799543110880acaa8c584d44edb3565b7d
--8<---cut here---end--->8---

2. SHA1 is one hash function and SHA256 is another.  Obviously, it is
impossible to go from one to the other.

--8<---cut here---start->8---
$ guix hash -S nar -H sha256 -f hex -x Zygote.jl
f3d1776c4f3f539987141ad4a57198fd62038e6ef5e9a2eea8ba0819aa916f09
--8<---cut here---end--->8---

However, here the format is ’hex’ and it is possible to convert this
checksum from the format ’hex’ to the format ’nix-base32’.  From this
f3d1776c4f3f539987141ad4a57198fd62038e6ef5e9a2eea8ba0819aa916f09, it is
straightforward to get
02bgj6m1j25sm3pa5sgmds706qpxk1qsbm0s2j3rjlrz9xn7glgk as specified by the
recipe,

--8<---cut here---start->8---
(version "0.6.41")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/FluxML/Zygote.jl;)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "02bgj6m1j25sm3pa5sgmds706qpxk1qsbm0s2j3rjlrz9xn7glgk"
--8<---cut here---end--->8---


For my point of view, you need to clone the repository to be able to
compute the ’hash’ field.


Cheers,
simon

Re: Merging branch wip-haskell

[Development of GNU Guix and the GNU System distribution.]

Hi Lars,

> the branch has been merged into master.

Thank you for that giant contribution to making Haskell more usable in Guix!

Kind regards
Felix Lechner

Re: Follow-up on julia import script

[Development of GNU Guix and the GNU System distribution.]

What we get from juliahub is really not bad, since it's really close to
what we have in other importers.

I've been working on that this wkend, nearly finished a first version,
but there's still a few points I'm not sure of :

- we don't have a `hash` field in the json, tough we might be able to
  get it by parsing Versions.toml additionally to the json. This I can
  do with a very simple parser.

- there's a difficulty for defining guix-name->julia-name with the
  simple guix/import/utils.scm snake-case. We should define proper
  functions to convert without ambiguity from CamelCase to snake-case
  and back, and that also encompasses cases like JuMP and OCReract. I
  had one option in mind but haven't tested it to get the name in the
  url. Or maybe we should have a #:julia-name field in arguments or
  properties. WDYT ?

- We only have direct and indirect dependencies in juliahub's json. We
  can't separate native-inputs (as is done in jvb1's guix.jl) or
  propagated-inputs (as discussed with zimoun) without additionally
  parsing Project.toml. This I can't do with my very simple parser.

- readme is full of html junk, I don't know if we can process it to get
  pure text output easily in Guile ?

It looks like that as of now :

(define-module (guix scripts juliahub)
  #:use-module (ice-9 textual-ports)
  #:use-module (ice-9 regex)
  #:use-module (ice-9 match)
  #:use-module (ice-9 string-fun)
  #:use-module (srfi srfi-9)
  #:use-module (srfi srfi-1)
  #:use-module (guix http-client)
  #:use-module (guix import utils)
  #:use-module (guix import json)
  #:use-module (guix base16)
  #:use-module (guix base32)
  #:use-module (guix packages)
  #:use-module (json)
  #:use-module ((guix licenses) #:prefix license:)

  #:export (juliahub->guix-package))

(define (juliahub-uri name)
  (let* ((url (string-append "https://docs.juliahub.com/; name "/"))
 (port (http-fetch url #:text? #t))
 (_ (get-line port))
 (meta (get-line port))
 (regex "url=[a-zA-Z0-9]{5}\\/[0-9\\.]*")
 (redirect (match:substring (string-match regex meta
(close-port port)
(string-drop redirect 4)))

(define (juliahub-url name)
  (let* ((url (string-append "https://docs.juliahub.com/; name "/"))
 (uri (juliahub-uri name)))
(string-append url uri "/")))

(define (juliahub-slug-version name)
  (let* ((uri (juliahub-uri name))
 (slug (string-take uri 5))
 (latest-version (string-drop uri 6)))
`(,slug ,latest-version)))

(define (json->juliahub-direct-dependencies vector)
  (if (vector? vector)
  (filter-map
   (lambda (el)
 (let ((dep (json->juliahub-dependency el)))
   (if (juliahub-dependency-direct? dep)
   dep
   #f)))
   (vector->list vector

;; Julia package.
(define-json-mapping  make-juliahub-package juliahub-package?
  json->juliahub-package
  (homepage juliahub-package-homepage) ;string
  (readme juliahub-package-readme) ;string
  ;; (slug juliahub-package-slug) ;string
  (version juliahub-package-version) ;string
  (description juliahub-package-description) ;string
  (dependencies
   juliahub-package-dependencies "deps"
   json->juliahub-direct-dependencies) ;list of 
   ;; (lambda (vector)
 ;; (map json->juliahub-dependency (vector->list vector
  (url juliahub-package-url) ;string
  (uuid juliahub-package-uuid) ;string
  (license juliahub-package-license)) ;string

(define-json-mapping 
  make-juliahub-dependency juliahub-dependency?
  json->juliahub-dependency
  (direct? juliahub-dependency-direct? "direct") ;boolean
  (name juliahub-dependency-name) ;string
  (uuid juliahub-dependency-uuid) ;string
  (versions juliahub-dependency-versions "versions" vector->list)) ;list of 
strings
  ;; (slug juliahub-dependency-slug) ;string

(define (julia-name->guix-name name)
  (string-append "julia-" (snake-case name)))

(define* (juliahub-fetch name #:key (version #f))
  "Return a  record for package NAME, or #f on failure."
  (and=> (json-fetch (string-append (juliahub-url name) "pkg.json"))
 json->juliahub-package))

(define (make-julia-sexp name version uri hash home-page synopsis description
 dependencies licenses)
  "Return the `package' s-expression for a Julia package with the given NAME,
VERSION, URI, HASH, HOME-PAGE, DESCRIPTION, DEPENDENCIES, and LICENSES."
  `(package
 (name ,(julia-name->guix-name name))
 (version ,version)
 (source (origin
   (method url-fetch)
   (uri ,uri)
   (sha256
(base32
 "0sjjj9z1dhilhpc8pq4154czrb79z9cm044jvn75kxcjv6v5l2m5"
 ;; ,(bytevector->nix-base32-string hash)
 
 (build-system julia-build-system)
 ,@(if (null? dependencies)
   '()
   `((inputs
  (list ,@(map (compose julia-name->guix-name 
juliahub-dependency-name)
   dependencies)
 (synopsis 

Re: Merging branch wip-haskell

[Lars-Dominik Braun]

Hi,

> > the branch has been merged into master.
> \o/ Nice, thank you!
well, GHC fails a single testcase on i686 (which we did not test for
wip-haskell) right now[1], but it’ll take some rounds of building it
locally until I have this sorted out too.

Lars

[1] https://ci.guix.gnu.org/eval/230900?status=failed=0

Re: Merging branch wip-haskell

[Simon Tournier]

Hi,

On Sun, 26 Feb 2023 at 10:47, Lars-Dominik Braun  wrote:

> the branch has been merged into master.

\o/ Nice, thank you!

Cheers,
simo

Re: Follow-up on julia import script

[Simon Tournier]

Hi,

>> DataAPI = "9a962f9c-6df0-11e9-0e5d-c546b8b5ee8a"
>> DataValueInterfaces = "e2d170a0-9d28-54be-80f0-106bbe20a464"
>> IteratorInterfaceExtensions = "82899510-4779-5014-852e-03e436cf321d"
>> LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838f9c8e"
>> OrderedCollections = "bac558e1-5e72-5ebc-8fee-abe8a469f55d"
>> TableTraits = "3783bdb8-4a98-5b6b-af9a-565f29a5fe9c"
>> Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
>
> How does one resolve those UUIDs?

Arf, good question. :-)

You have to go back to General registry and open the corresponding
entry.  For instance,

name = "DataAPI"
uuid = "9a962f9c-6df0-11e9-0e5d-c546b8b5ee8a"
repo = "https://github.com/JuliaData/DataAPI.jl.git;


https://github.com/JuliaRegistries/General/blob/master/D/DataAPI/Package.toml


What is really boring is the ’compat’ part that I skipped.

Cheers,
simon

Re: ’inherit’ and list-dependent (was Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.)

[Simon Tournier]

Hi,

On Sat, 25 Feb 2023 at 19:10, Ludovic Courtès  wrote:

>>> In effect that means keeping back the chain of inherited objects, which
>>> would lead to space leaks.

[...]

>> What do you mean by “space leaks”?
>
> Unbounded memory usage: each copy of an object is linked back to its
> “parent” (“previous generation”).

As Gábor, I miss some details. :-) And I do not understand what would be
these “space leak” since what I am suggesting is somehow done with all
Python 2 packages using package-with-python2
(package-with-explicit-python) for example.

Cheers,
simon

Re: Projects for the Google Summer of Code

[Simon Tournier]

Hi,


On Sun, 26 Feb 2023 at 16:52, Kyle  wrote:

> One idea might be to write a conda importer which looks at the
> versions of software in the resulting environment and tries to make
> feasible package variants of make a manifest which matches the
> existing conda environment as close as possible.

Do you mean, from ’conda env export’ Which outputs something like, 

name: justnumpy
channels:
  - defaults
dependencies:
  - _libgcc_mutex=0.1=main
  - _openmp_mutex=5.1=1_gnu
  - blas=1.0=mkl
  - libuuid=1.41.5=h5eee18b_0
  - mkl=2021.4.0=h06a4308_640
  - mkl-service=2.4.0=py310h7f8727e_0
  - mkl_fft=1.3.1=py310hd6ae3a3_0
  - mkl_random=1.2.2=py310h00e6091_0
  - ncurses=6.3=h5eee18b_3
  - numpy=1.23.4=py310hd5efca6_0
  - numpy-base=1.23.4=py310h8e6c178_0
  - ...
  - ...

transform this into some Guix manifest.scm?  Well, indeed, it could help
people for transitioning.


> Another idea would be to create a python package for working with Guix
> more directly from inside their preferred language environment instead
> of through the shell. I also wouldn't mind it if such a thing existed
> for R as well.

Do you mean ’guix.install()’ from r-guix-install?

https://cran.rstudio.com/web/packages/guix.install/index.html

How do you install Python packages from the Python REPL?


Cheers,
simon

PS:

>  Simon thought often
> the python version usually didn't matter, but it makes users a lot
> less woosy to stick with software combinations they have already
> tested.

This is out of context. :-)  For the context, see [1].

Well, if you have only one Python version, you only test against this
one, so being able to combine on the fly the matrix of Python versions
is not so much important – it is a collective practise inherited from
the “unstable” Python ecosystem and I am doubtful about its relevancy
concerning referencing software for reproducing.  Now Conda is more than
10 years and very very broadly used, so if its specification using
version labels and relying on some matrix of Python versions would be
enough for reproducibility, then I would have never landed in Guix. ;-)

1: https://yhetil.org/guix/86pma2t3jd@gmail.com

My 2 cents. :-)