Re: Guix related things in Germany at the end of October/start of November

[Tobias Platen]

On Sat, 2023-09-09 at 08:23 +0200, Matt wrote:
> 
>   On Tue, 05 Sep 2023 19:28:09 +0200  Christopher Baines  wrote -
> -- 
> 
>  > Is anyone else planning to attend these events, or otherwise
> interested
>  > in meeting up in Germany around these dates?
> 
> I recently moved to Hamburg.  Thank you for informing the list (and
> particularly me) of these events!  I'd like to attend, if my schedule
> permits.
> 
I live in Göttingen and I am interested too.

Re: Branch (and team?) for mesa updates

[Tobias Platen]

On Sun, 2023-08-27 at 12:45 +0800, dan wrote:
> Hi John,
> 
> Aug 26, 2023 08:51:49 John Kehayias :
> > 
> > 
> > Though at least (gnu packages gl) looks pretty
> > reasonable to start for maybe a graphics team? Maybe with vulkan?
> > 
> > I'm still not sure but I should probably propose something concrete
> > with at least myself for gl since those patches generally will go
> > to
> > the mesa-updates branch for convenient building.
> > 
> > Anyone else want in?
> 
> I use vulkan and sdl2 for my day to day development, and I once
> submitted 
> a patch series updating various vulkan packages.  I'm interested in 
> maintaining these vulkan packages and I like the idea of having a 
> graphics team.  Meanwhile, I'm not so sure if the team should be 
> responsible for sdl2, but I would like to discuss the possibility
> first.
> 
I would also want to submit the libre-soc vulkan driver to a branch,
once it exists. Currently all vulkan compatible GPUs need non-free
firmware blobs.

Re: plasma desktop in guix

[Tobias Platen]

That looks good. Soon I'll try to get XRDesktop working on the Guix
System, either with Gnome or with KDE. Still a long way to get it
working on my Talos II. (I will have to upgrade my GPU to one from
RED Semiconductor as the current one needs non-free firmware.)

On Fri, 2023-07-21 at 20:30 +0800, Z572 wrote:
> 
> hello!
> 
> i try update kde packages and running a plasma desktop.
> 
> url is https://github.com/Z572/guix/tree/kde-5.108.0
> 
> 
> it running, but maybe have many bug.
> 
> plasma-workspace plasma-desktop kscreenlocker etc. their qml is
> cyclic
> dependence, no idea how to cut cyclic, so i change qtwrap to set
> QML2_IMPORT_PATH from `=' to `prefix', make them get system's env.
> 
> change sddm services to add some environment-variables make breeze
> theme
> work.
> 
> and have many bug, such as screenlocker is cann't unlock, wayland is
> not
> work, and something other.
> 
> you can try it.
> 
> username is plasma
> password is plasma
> 
> ``` bash
> `./pre-inst-env guix system vm gnu/system/examples/plasma.tmpl` -net
> user,hostfwd=tcp::-: -net nic
> ```
> 

Re: Blog post on the Full-Source Bootstrap

[Tobias Platen]

This looks good, I am interested in doing a port to the POWER ISA.
Currently on my OrangeCrab I only have one small C program running,
coldboot. Everything from the HDL to the BIOS should be Full-Source.

https://git.libre-soc.org/?p=ls2.git;a=blob;f=coldboot/coldboot.c 

Tobias

On Wed, 2023-04-26 at 16:12 +0200, Janneke Nieuwenhuizen wrote:
> Hello Guix!
> 
> Now that core-updates has been merged, the Full-Source Bootstrap has
> come to Guix!  This means we're building packages from source all the
> way down.  Read all about it in this new post:
> 
>  
> https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
> 
> Janneke & Ludo
> 

my first package: nearly finnished

[Tobias Platen]

I run guix lint which gave me two warnings, I fixed the rest my self:

gnu/packages/speech.scm:342:12: sekai@0.6.0: 'pkg-config' should
probably be a native input
gnu/packages/speech.scm:332:12: sekai@0.6.0: the source file name
should contain the package name

Once done I will send an email to the Guix issue tracker.

Tobias
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2016 David Thompson 
;;; Copyright © 2016, 2019, 2020 Marius Bakke 
;;; Copyright © 2017 Leo Famulari 
;;; Copyright © 2018, 2020–2022 Tobias Geerinckx-Rice 
;;; Copyright © 2016 Kei Kebreau 
;;; Copyright © 2019, 2021, 2022 Ricardo Wurmus 
;;; Copyright © 2020 Nicolas Goaziou 
;;; Copyright © 2020 Efraim Flashner 
;;; Copyright © 2021 qblade 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

(define-module (gnu packages speech)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix utils)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system meson)
  #:use-module (guix build-system cmake)
  #:use-module (gnu packages)
  #:use-module (gnu packages audio)
  #:use-module (gnu packages algebra)
  #:use-module (gnu packages autotools)
  #:use-module (gnu packages base);for 'which'
  #:use-module (gnu packages boost)
  #:use-module (gnu packages bison)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages documentation)
  #:use-module (gnu packages emacs)
  #:use-module (gnu packages gcc)
  #:use-module (gnu packages gettext)
  #:use-module (gnu packages glib)
  #:use-module (gnu packages gstreamer)
  #:use-module (gnu packages linux)
  #:use-module (gnu packages maths)
  #:use-module (gnu packages machine-learning)
  #:use-module (gnu packages ncurses)
  #:use-module (gnu packages perl)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages pulseaudio)
  #:use-module (gnu packages python)
  #:use-module (gnu packages serialization)
  #:use-module (gnu packages swig)
  #:use-module (gnu packages texinfo)
  #:use-module (gnu packages textutils))

(define-public flite
  (package
(name "flite")
(version "2.2")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/festvox/flite;)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "1n0p81jzndzc1rzgm66kw9ls189ricy5v1ps11y0p2fk1p56kbjf"
(build-system gnu-build-system)
(arguments
 ;; XXX:
 ;; There numerous issues with the testsuite.
 ;; Enable all of them once they are fixed in upstream.
 `(#:tests? #f
   #:configure-flags
   (list
"--enable-shared"
(string-append "LDFLAGS=-Wl,-rpath="
   (assoc-ref %outputs "out")
   "/lib"))
   #:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'patch-rpath
   (lambda _
 (substitute* "main/Makefile"
  (("flite_LIBS_flags \\+= -Wl,-rpath [^ ]*")
   "flite_LIBS_flags +="))
 #t))
 (delete 'check)
 ;; Modifying testsuite/Makefile is not done in favor of
 ;; overriding 'check.
 ;; The path not taken would be:
 ;; test:\n\t$(foreach x,$(subst tris1,,$(subst dcoffset_wave,,$(subst flite_test,,$(subst by_word,,$(subst bin2ascii,,$(subst lpc_resynth,,$(subst rfc,,$(subst compare_wave,,$(subst record_in_noise,,$(subst combine_waves,,$(patsubst play_%,,$(subst record_wave,,$(subst lex_lookup,,$(patsubst lpc_test%,,$(patsubst asciiS2U%,,$(patsubst asciiU2S%,,$(ALL),echo TEST $x && ./$x data.one && ) true
 (add-after 'install 'check
   (lambda _
 (invoke "make" "-C" "testsuite")
 (with-directory-excursion "testsuite"
   (invoke "./token_test")
   (invoke "./hrg_test")
   (invoke "./regex_test")
   (invoke "./nums_test")
   (invoke "./lex_test")
   (invoke "./utt_test")
   (invoke "./multi_thread"))
 #t))
 (add-after 'install 'remove-static-libs
   (lambda* (#:key outputs #:allow-other-keys)
 (let* ((out (assoc-ref 

Re: Hoping to donate/sell a Talos II motherboard

[Tobias Platen]

I  would want to see running the Guix System on both POWER9 and the
libre-soc.  After I watched CPU tuning in GNU Guix[1], my first thaught
was to add the SVP64 binutils to Guix as a second CPU variant.

[1] https://fosdem.org/2023/schedule/event/cpu_tuning_gnu_guix/

Tobias

On Wed, 2023-03-01 at 14:00 +, Luke Kenneth Casson Leighton wrote:
> 
> 
> On Wednesday, March 1, 2023,  wrote:
> > March 1, 2023 5:11 AM, "Toshaan Bharvani | VanTosh"
> >  wrote:
> 
> > > Yes, please, I am interested.
> > > I would use it for PowerEL, LibreBMC and LibreSOC.
> > > All open source projects.
> > > Is this just a board or also a CPU?
> > 
> > It is just the motherboard.  :)
> 
> so someone has to spend maybe an additional...  USD... 1000? 
> 2000? to get it into a useful state.  minimum 128 GB preferably
> a lot more than that (in order to host multiple VMs),
> plus SSDs / HDDs, plus a minimum 1,000 watt power supply.
> 
> 
> > donate to the university of Oregon, whose contact is Toshaan
> > Bharvani.
> 
> ah no.
> 
> Two SEPARATE options:
> 
> * donate to University of Oregon, whose contact is Sameer Shende,
>   and if they agree they can add it to the multiple POWER9
>   systems which are already available to FOSS Groups through
>   the OpenPOWER Hub, have been for a few years now.
> 
> * donate to Vantosh Ltd, whose contact is Toshaan Bharvani,
>   who already also hosts POWER9 systems for FOSS Projects
>   (Libre-SOC in particular), and who is the maintainer of
>   the PowerEL distribution.
> 
> l.
> 
> 

Re: Guix, Nix flakes, and object capabilities

[Tobias Platen]

I recently saw that the SlimeVR server[1] has nix flakes, is there a
way to convert this for guix? 

On Tue, 2023-02-28 at 22:13 -0500, Jonathan Frederickson wrote:
> Hello Guix,
> 
> I recently had a discussion in #spritely on Libera.Chat about Guix
> and
> Nix, and in particular a (relatively) new feature of Nix called
> flakes
> that Guix doesn't currently have an analogue for.
> 
> I've been a Guix user for a while, but I've only recently started
> looking at using Guix for development via ~guix shell~ as in this
> blog
> post by David Thompson[0]. The Guile port of Spritely has been using
> it,
> so I've been trying it out for one of my own projects as a result.
> And
> it seems pretty nice; you're using the same package definitions you
> might use when contributing a package upstream to Guix, which feels
> pretty natural as someone already pretty familiar with Guix as a
> user.
> 
> However, I noticed something about the resulting dependency graph
> that
> feels somewhat unsatisfying. When you define a package, the
> dependencies you provide in e.g. ~inputs~ are references to
> packages. And the way you get those is, of course, by importing
> modules containing those packages.
> 
> But the package you end up with each time you do that... depends on
> which revision of Guix you're running when you run ~guix shell~! So
> if
> I point someone to a project with a ~guix.scm~ file, they might not
> be
> able to use it if their Guix revision is too old. (Or too new, if
> packages have been renamed or removed.) More generally, it means that
> they do not end up with the same dependency graph that I do. This
> makes troubleshooting potentially tricky, because if something breaks
> you have to check the resulting profile to see which versions of your
> package's dependencies (and transitive dependencies) are actually
> installed.
> 
> For those who haven't used Nix, it has a solution to this called
> flakes. Flakes let you specify git repositories explicitly as inputs
> for
> your project[1]. (It also maintains a flake.lock file so you can lock
> to
> a specific revision automatically while still using a named branch in
> your inputs directly, but I believe you could in theory refer to a
> specific rev in your inputs.) Effectively, the channels you're using
> for
> dependencies are specified by the project you're building, not
> whatever
> happens to be configured on your local machine.
> 
> I think something like this would be useful for Guix for many of the
> same reasons it's useful in Nix. But there's a bit of a security
> conundrum here. Loading Guix package definitions involves code
> execution, which as far as I can tell isn't currently sandboxed at
> all!
> And that's a problem. When you load package definitions from a
> channel
> that you've configured on your system, you've explicitly trusted that
> channel's maintainers. But with a flake-like system... even if you
> might
> be okay depending on someone else's code, that doesn't necessarily
> mean
> you fully trust them. You might ultimately choose to sandbox the
> resulting binary, but that's moot if you can't fetch its dependencies
> without running arbitrary code with all of your user's authority.
> 
> I think there is a solution to this, though. Right now when you
> evaluate Guix package definitions, you're basically running arbitrary
> Guile code. This of course can do anything you can do. But it doesn't
> have to! If you're familiar with Christine Lemmer-Webber's work on
> Spritely, you'll probably know what I'm getting at here: I think
> using
> object capabilities[2] would fix this. I recommend reading the linked
> blog post for a good explainer on what object capabilities are, as I
> won't do it justice here, but to perhaps oversimplify: code in a
> capability system only has access to the things you give it, and no
> more. It's like lexical scope, but taken very seriously.
> 
> If you think about what a typical package definition needs to be able
> to
> do to your system directly, I think it's not actually that much? My
> (admittedly basic, possibly flawed) understanding of how Guix works
> is
> that most of the heavy lifting is done by ~guix-daemon~, which itself
> is
> pretty heavily sandboxed, and that most of what the ~guix~
> subcommands
> are doing is building derivations which instruct ~guix-daemon~ to
> perform build actions. So while you're building these derivations,
> unless I'm misunderstanding:
> 
> - You don't need network access
> - You don't need (much) filesystem access
> 
> I think object capabilities provide a good answer to this
> problem. Rather than evaluating package definitions from a channel as
> you would normally run Guile code, evaluate them in a restricted
> environment that only has access to things you've passed in. In
> JavaScript, this might look like this (taken from this blog post[3]
> about the event-stream incident):
> 
> #+BEGIN_SRC javascript
>   const addHeader = require('./addHeader', {fs, https});

Guix Games Collection

[Tobias Platen]

I had submitted a talk for LibrePlanet called "Gaming on a Talos II -
how I avoid using Steam". Unfortunately, there were so many high
quality talks that it was impossible to fit them all in the program.
So I will do a lightning  talk [1], about my work in progress Guix
Games Collection, a list of games that are playable on a freedom
respecting machine such as the Talos II or Thinkpad X200 (with
Libreboot) on the Guix System. I also plan to make a haunt page with
screenshots/videos for each game, similar to the Steam storepages. 

[1]:
https://libreplanet.org/wiki/LibrePlanet:Conference/2023/Lightning_Talks

Re: FOSDEM’s coming!

[Tobias Platen]

Am Montag, dem 23.01.2023 um 18:39 +0100 schrieb Ludovic Courtès:
> The blog post is on-line now:
> 
>   https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/
> 
> Thanks everyone.  This program is exciting!
> 
> Ludo’.
> 
Unfortunately I'll won't make it to Brussels this year, so I ask if
there is an IRC chat or recording of talks at the fringe event.

Tobias Alexandra

Re: GNU Guix 1.4.0 released

[Tobias Platen]

Hi,

Currently I am testing that one on my ThinkPad X200 and on my Talos II.

Tobias Alexandra
On Thu, 2023-01-05 at 10:57 +0100, Simon Tournier wrote:
> Hi Ludo, all,
> 
> On Tue, 03 Jan 2023 at 10:08, Ludovic Courtès  wrote:
> 
> > In my experience though, a lot of the work is coordination: keeping
> > track of what needs to be done, open bugs, calling for testing,
> > etc.
> 
> Yes, coordination is large part of the work, but not only as shown by
> previous experiences (e.g., [1,2,3,4] and older others).
> 
> 1: 
> 2: 
> 3: 
> 4: 
> 
> 
> > I think we should start thinking about the next release, forming a
> > small release team, and I’ll be happy to mentor!
> 
> Definitively!  Count on me to candidate on such team. :-)
> 
> From my point of view, this team will be a rotating effort.  For
> instance, from 2 to 4 people will be part.  The duty is to be part
> for 2
> releases; 1-2 person step downs for welcoming 1-2 new person after
> each
> release.  Well, something similar to NixOS release management.
> 
> As usual, the question is about the bootstrap. ;-)
> 
> 5: 
> 6:
> 
> 
> 
> Cheers,
> simon
> 

Re: The Guix Days! (FOSDEM 2023)

[Tobias Platen]

Hello, 

Unfortunately I won't go to FOSDEM this year, so I will watch the live
streams from home.

Tobias Alexandra

On Tue, 2023-01-03 at 22:10 +0100, Ludovic Courtès wrote:
> Hello,
> 
> Pjotr Prins  skribis:
> 
> > Just a heads up: we are excited to have Guix days and the FOSDEM
> > devroom in Brussels Feb 2-5!!
> > 
> > If you want to attend Guix days, please add to this list (the login
> > is
> > a bit hidden). We can only have limited people and catering. If we
> > run
> > over the max room number we'll have a problem:
> > 
> > => https://libreplanet.org/wiki/Group:Guix/FOSDEM2023
> > 
> > The programme for the devroom runs partially virtual and partially
> > live. The lineup is great as ever:
> > 
> > =>
> > https://fosdem.org/2023/schedule/track/declarative_and_minimalistic_computing/
> 
> I booked my train, yay!!
> 
> It’s that time of the year where we usually have a blog post inviting
> people to meet us at FOSDEM and at the Guix Days.  :-)
> 
>   https://guix.gnu.org/en/blog/2022/meet-guix-at-fosdem-2022/
>   source:
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts/meet-guix-at-fosdem-2022.md
> 
> Who’s in to prepare this year’s post?
> 
> Ludo’.
> 

Re: Status of armhf-linux and powerpc64le-linux

[Tobias Platen]

On Fri, 2022-10-21 at 10:43 +0200, Ludovic Courtès wrote:
> Moin!
> 
> Mathieu Othacehe  skribis:
> 
> > >  - armhf-linux is disabled on ci.guix due to improper
> > > offloading
> > >    setup (probably along the lines of
> > >    ).  Should we try and
> > > reenable
> > >    it, or should we drop it?
> > > 
> > >  - powerpc64le-linux is disabled on ci.guix since today
> > >    (maintenance.git commit
> > >    d641115e20973731555b586985fa81fbe293aeca).  However it did
> > > work
> > >    until recently and we have one machine to offload to. 
> > > Should we
> > >    fix it or drop it?  Mathieu?
> > 
> > Yeah, we only have a single machine to offload to and each time it
> > is
> > not reachable, the "guix" specification fails on Cuirass.
> 
> How frequently does that machine become unreachable?
> 
> Its uptime right now is “only” 51 days, but it seems to have been
> reliably building things so far (surprisingly so!).
> 
> > That's because we need to offload to a powerpc64le-linux machine in
> > order to evaluate the guix derivation for that specific
> > architecture
> > (that's true for all the other architectures).
> 
> Maybe we should arrange to be more resilient to transient build
> machine
> outage.
> 
> For that we need redundancy; we have it for ARM, but not for POWER9. 
> A
> simple way to get redundancy today would be to set up transparent
> emulation for POWER9 on one of the x86_64 boxes.  That’ll be
> inefficient, but that’ll let Cuirass survive transient failures of
> that
> one POWER9 box.
> 
> WDYT?
> 
> Longer-term, people interested in POWER9 should look into:
> 
>   • Purchasing, setting up, and hosting POWER9 hardware (funds held
> at
>     the FSF are probably sufficient for that!).
Vikings also offers hosting of POWER9 hardware.
> 
>   • And/or: getting in touch with companies who could sponsor us by
>     providing hardware (the AArch64 port was started thanks to a
>     donation by ARM).
> 
> In Cuirass, we should arrange to support partial evaluations or
> per-system evaluations so that a single missing offload machine
> doesn’t
> cause the whole evaluation to fail.
> 
> > Given the lack of workers for powerpc64le-linux I think we should
> > drop
> > it.
> 
> We can do that, but I find embarrassing to drop the architecture
> after
> all the work people have put it “just” because of infrastructure
> issues.
> 
> > Regarding armhf-linux we can in theory rely on the overdrives but
> > we
> > are already struggling on aarch64-linux, we I think we should also
> > drop it for now.
> 
> In theory, ci.guix has at least 3 Honeycombs (2 are currently
> offline)
> and 2 Overdrives, so it’s not that bad, and they don’t seem to be all
> that busy.
> 
> So you’re right in a way, but at the same time this seems to be an
> infrastructure issue.
> 
> > Focusing on x86_64-linux, i686-linux and aarch64-linux for this
> > release
> > seems more pragmatic.
> 
> That’s radical, but maybe that’s the most reasonable option.
> 
> How about a plan like this: until next Thursday, we try to address
> the
> infrastructure issues discussed above to estimate feasibility.  Then
> we
> decide on the way forward.  WDYT?
> 
> If we end up dropping architectures, we’ll have to:
> 
>   1. Update the documentation (and eventually the web site).
> 
>   2. Offer a clear plan as to what it would take to reinstate those
>  architectures, and probably define clear criteria for
> architecture
>  support going forward.
> 
> Thanks,
> Ludo’.
> 

Re: Updating minetest to 5.6.0?

[Tobias Platen]

I'm also working on a VR version of minetest, I'll plan to package that
one too.

OpenVR in Guix

[Tobias Platen]

I saw that Guix includes OpenVR[1], which is kind of problematic,
because there is no libre compatible runtime. I have a Valve Index,
which I use without Steam[2], using the libre runtime Monado, which
currently only supports OpenXR[3], but I plan to add a nonsteam OpenVR
runtime to Monado. So I think there is no need to remove OpenVR.
In Debian this packages is in contrib, because of the SteamVR
dependency.

[1]https://guix.gnu.org/en/packages/openvr-1.8.19/
[2]https://www.gnu.org/philosophy/nonfree-games.html
[3]https://guix.gnu.org/en/packages/openxr-1.0.24/

My first package

[Tobias Platen]

Hello,

I've created my first package for guix, the sekai speech synthesis
toolkit which I use mainly for producing singing voice with lilypond.
I'll also plan a talk at the gnu hackers meeting how I make Desktop
Music using the Guix System. Two more packages will follow next.

Tobias Alexandra
diff --git a/gnu/packages/speech.scm b/gnu/packages/speech.scm
index 042c157e43..cc0b03d110 100644
--- a/gnu/packages/speech.scm
+++ b/gnu/packages/speech.scm
@@ -31,11 +31,14 @@ (define-module (gnu packages speech)
   #:use-module (guix git-download)
   #:use-module (guix utils)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system cmake)
   #:use-module (gnu packages)
   #:use-module (gnu packages audio)
+  #:use-module (gnu packages algebra)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages base);for 'which'
   #:use-module (gnu packages bison)
+  #:use-module (gnu packages boost)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages documentation)
   #:use-module (gnu packages emacs)
@@ -44,15 +47,18 @@ (define-module (gnu packages speech)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gstreamer)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages maths)
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages pulseaudio)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages serialization)
   #:use-module (gnu packages swig)
   #:use-module (gnu packages texinfo)
   #:use-module (gnu packages textutils))
 
+
 (define-public flite
   (package
 (name "flite")
@@ -318,6 +324,33 @@ (define-public sonic
 (home-page "https://github.com/waywardgeek/sonic;)
 (license license:asl2.0)))
 
+(define-public sekai
+  (package
+(name "sekai")
+(version "0.6.0")
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://notabug.org/isengaara/sekai;)
+(commit "0.6rc0")))
+  (sha256
+   (base32
+"0j55pipx3hcp0xl4v0d72fdwysnz9a9a40x65a9lxpl4k6wyp4nm"  
+(build-system cmake-build-system)
+(arguments '(#:tests? #f))
+(inputs `(("fftw" ,fftw)
+  ("libsndfile",libsndfile)
+	  ("pkg-config",pkg-config)
+	  ("gsl",gsl)
+	  ("jsoncpp",jsoncpp)
+	  ("boost",boost)
+	  ("jack" ,jack-1)
+	))
+(synopsis "The SEKAI speech toolkit")
+(description "The future of Singing Voice Synthesis using the Excitation plus Resonances model.")
+(home-page "https://qtau.de/sekai;)
+(license license:agpl3+)))
+
 (define-public festival
   (package
 (name "festival")

Re: secure boot

[Tobias Platen]

That would be interesting, even on a Talos II, which has owner
controlled secure boot. There will be no need to sign with a Microsoft
key as most UEFI implementations do. There are two Microsoft keys, one
for Windows and one for all other OSes.

On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Padoan Junior wrote:
> Hello,
> 
> I hope my question makes sense. It concerns Guix grub UEFI
> bootloaders.
> 
> I would like to understand in which extent Guix functional approach
> helps to secure the computer with regards to an early boot malicious
> code/malware infection.
> 
> As far as I understand, Guix doesn't provide means to automatically
> sign
> bootloaders and kernels in order to use UEFI secure boot after each
> system
> reconfigure (assuming a PKI is properly implemented).  Hence, using
> secure boot with Guix is currently not viable (am i correct?).
> 
> In this context, can I assume that the risk of not having secure boot
> is
> minimized by the fact that in each system reconfiguration, the early
> boot chain is overwritten is such a way that, if a malicious is
> introduced somehow, it will be also overwritten? Am I correct?
> 
> In addition, how much more difficult it is to introduce such
> malicious
> code in a Guix system giving its functional approach and store
> system?
> (in comparison with others Linux distributions).
> 
> I know that Guix provides an amazing approach to secure software
> supply
> chain, but I as wondering if not having secure boot can be considered
> a major drawback for Guix.
> 
> Best regards

Packaging DOS Games

[Tobias Platen]

I recently found dosdefender-ld31, a public domain DOS game, designed
to run in dosbox. To build you only need gnu make and a version of gcc
that targets i386-gnu or i386-gnu-linux. 

Guix on my ROCKPro64 and on an old Android Tablet

[Tobias Platen]

Today I began building the Guix System for my ROCKPro64.
I installed Guix on top of Debian and tried to build uboot, it works:

guix build u-boot-rockpro64-rk3399
successfully built /gnu/store/g1d4kjgn9b46vqk9mwhd0kc2r6sfi7cz-u-boot-
rockpro64-rk3399-2022.04.drv
/gnu/store/90p0yndkj89c5chnri2asj9m46glxq50-u-boot-rockpro64-rk3399-
2022.04

Since my old Android Tablet has an Intel Atom SoC, I could easily
install Debian, on top of that I installed Wesnoth, which I had packed
from my Laptop running the full Guix System. 

Re: gnucash: missing Adwaita icon theme

[Tobias Platen]

I saw something similar with frescobaldi, tomorrow I'll check again.

glibc-2.33 fails to build on POWER9

[Tobias Platen]

I tried to build glibc-2.33 on my Talos II (no cross compile here),
it fails because the compiler is likely outdated.

checking if the target machine is at least POWER8... yes
checking if the compiler supports -mno-gnu-attribute... yes
checking if gcc compiles signbit with 128-bit floating point type...
yes
checking if gcc compiles with -mabi=ieeelongdouble and -mlong-double-
128... no
checking for objcopy... objcopy
checking version of objcopy... 2.37, ok
configure: error: ***  The compiler must support -mabi=ieeelongdouble
and -mlongdouble simultaneously.

guix --version shows
guix (GNU Guix) 7c9ad54b0616112c7eea6dd02379616aef206490
Copyright (C) 2022 the Guix authors

Re: emacs-lilypond-mode should we?

[Tobias Platen]

On Mon, 2022-07-11 at 16:29 +0300, Efraim Flashner wrote:
> On Mon, Jul 11, 2022 at 02:10:36AM -0500, jgart wrote:
> > Hi,
> > 
> > Should we package this mode separately from lilypond as emacs-
> > lilypond-mode?
> > 
> > https://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=tree;f=elisp;h=dc4d450a9f98433d04ac87057571ab58f98497c5;hb=HEAD
> > 
> > all best,
> > 
> > jgart
> 
> I think it would be best to package it separately, and I'm pretty
> sure
> that's already what is suggested. The two packages I have installed
> that
> happen to have .el files installed also don't have them compiled to
> .elc
> files. Best to keep it separate so it's done with all the automation
> of
> the emacs-build-system.
> 
I agree, soon I will use that one when I compose vocasynth songs using
lilypond, since I use emacs and a lilypond addon for festival, which I
have replaced with a more modern sinsy. Soon I will package that one
too.

Re: Reminder: please add yourself to a team

[Tobias Platen]

On Wed, 2022-07-06 at 10:45 +0200, Ricardo Wurmus wrote:
> lease take the time to add an entry for yourself to etc/teams.scm.in
> in
> the Guix repository.  Here’s an example commit:
> 
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/etc/teams.scm.in?id=47ed000d4df98e440a8a9a0788412b2f791b88b4
> 
> Thank you!
I'll do that soon, since I plan to contribute more in the future.

Re: Ten Years of Guix: Call for contributions

[Tobias Platen]

On Fri, 2022-07-01 at 15:30 +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> The Ten Years of Guix  event in Paris, 16–18 September, is shaping
> up,
> and you can register!
> 
>   https://10years.guix.gnu.org/
> 
> (There’s spam in the comment section of the registration form that we
> can’t fully block, but it’s functional.)
> 
> We’re planning to announce the program for Friday 16th, which focuses
> on
> uses of Guix in research, within a couple of weeks.  There will be
> room
> for lightning talks too.
> 
> For Saturday/Sunday, we already have a couple of nice talks and
> discussions scheduled (surprise! :-)), but we’d love to have more of
> them from you!  It could be “getting started” kind of talks for
> newcomers, demos, discussions on specific topics; for Sunday, it
> could
> be more in-depth hacking sessions or community discussions.
My proposed topic for one of these days is porting Guix to the 
Anbernic RG552, a mobile gaming console based on the libre-friendly
RK3399 SoC. I also own a RockPro64 which uses the same SoC.
> 
> Email Simon, Tanguy, and myself at guix-birthday-ev...@gnu.org or
> reply
> to this thread for proposals and questions.
> 
> Ludo’.
> 

Re: D Packages in Guix

[Tobias Platen]

On Tue, 2022-06-21 at 18:55 +0200, Tobias Platen wrote:
> I had a look at Inochi2D[1], which is written in D.
> D has its own packagemanager called dub, so a dub-importer will be
> needed to build Inochi2D with guix
> 
> [1] https://github.com/Inochi2D/inochi2d
> 
> Tobias
> 
> 
In the meanwhile I saw
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/dlang.scm#n423

but it does not support ppc64le and aarch64 yet, so I'll try that out
on my machine. I'll submit patches if something does not work. I'll try
aarch64 first.

D Packages in Guix

[Tobias Platen]

I had a look at Inochi2D[1], which is written in D.
D has its own packagemanager called dub, so a dub-importer will be
needed to build Inochi2D with guix

[1] https://github.com/Inochi2D/inochi2d

Tobias

Packaging Godot games with Guix

[Tobias Platen]

Hello,

I tried to package the game BeepSaber for Guix, which does not really
use a build system. You just git clone the repository containing the
game, then import the game into Godot by clicking import. When I just
do cd /gnu/store/path-to-beepsaber && godot, the Godot engine is unable
to import the media files used by beepsaber. Importing using the godot
editor requires write access to the game directory.

Tobias Alexandra

Guix System on RockPro64

[Tobias Platen]

Hello,

I had a look at the guix page, there is a latest version image for the
PineBook Pro, which uses the same SoC. Unfortunately I was unable to
find the reciepe to build that image. The guix page is currently down,
I will try again tomorrow. Today I was able to install guix on top of
Debian which I have installed on my RockPro64.

Tobias

Re: Let’s meet in person in Paris, Sept. 16–18!

[Tobias Platen]

I'm not sure, but most likely I want to participiate in this
conference. Then I will present the Guix Gaming Service, 
on which I am currently working and the proposed Guix Deck hardware.

Tobias (alyx)

Re: Devicetree overlay (on Rock64)

[Tobias Platen]

I have a ROCKPro64 (Hexa-Core Rockchip RK3399, 4GB) which I plan to use
for guix development too. I was already able to get PureOS in a chroot.

Tobias

Fwd: [Libre-soc-dev] CLEAR, Open Source FPGA

[Tobias Platen]

If they succeed the free toolchain can be packaged in guix.
--- Begin Message ---
https://groupgets.com/campaigns/1003-clear-the-open-source-fpga-asic-by-chipignite

please do share that widely, there are a few days to go before they reach 200.  
both the HDL and the toolchain are Libre, they deserve to succeed.

l.

___
Libre-soc-dev mailing list
libre-soc-...@lists.libre-soc.org
http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev
--- End Message ---

Re: announcement of minimal binary boot (mb2) with indirection table forth

[Tobias Platen]

On Wed, 2022-02-23 at 22:54 +0100, Stefan Karrmann wrote:
> for octal keyboard input on x86: 32 octets (!)
>   - for octal uninitialized serial input on x86: 34 octets
>   - for octal initialized serial input on x86:   41 octets
>   - for octal linux input on x86:    48 octets
> 
>   - for octet keyboard input on x86: 18 octets
>     This make sense, if we use the alt numpad input method.
> 
> For those, who don't regard octal encoded octets as real source code,
> I
> provide a second binary seed which implements a forth nucleus. I call
> it
> itf or indirection table forth.
> The sizes for this interpreter are much bigger than the sizes of the
> monitors but still small in comparision to a boot sector (512
> octets):
That looks interesting, I have been thinking about something similar
for the Rasperry PI GPU, which has been reverse engineered.

Tobias

Re: Excessively energy-consuming software considered malware?

[Tobias Platen]

Yes, bitcoin could be considered malware. There is GNU Taler which is
more efficent. Unfortunately Taler has not started yet, there is no
working exchange at the moment. 

Tobias

Re: CWiid fails to build

[Tobias Platen]

nearly finnished: I get a make[1]: ldconfig: No such file or directory
error when I try to compile my package.

CWiid fails to build

[Tobias Platen]

Hello,

I added the CWiid package to guix, and now autoconf fails when
building. I attached the logs and the package definition.

Tobias


starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to `/gnu/store/6s3mkll9wvgxgkczsjcl9nfqm74wi0mj-tar-1.34/bin:/gnu/store/6rxsi5nqx8dsmvx2ypyz81gb1n4csy3g-gzip-1.10/bin:/gnu/store/iipgssk08gmmkwxv5iyv1lm3blilvdir-bzip2-1.0.8/bin:/gnu/store/11gnzwa2qbqlg4pziysdk2fkbhrhhwrc-xz-5.2.5/bin:/gnu/store/6s9hy00b522g268spk3qasd8j8mg5z7r-file-5.39/bin:/gnu/store/b4s2gz0dyjhsym9rczyg21y909s2yzd1-diffutils-3.8/bin:/gnu/store/q89awzgsj00y74bmqlb4gl6b0plwi0k6-patch-2.7.6/bin:/gnu/store/bgmbk0abkm6nngmgam84fmb6m38kbndi-findutils-4.8.0/bin:/gnu/store/7mfpmrswg4y7apk0hri9hiwgn6xbbh9q-gawk-5.1.0/bin:/gnu/store/fkncn0815qj7k11zj05hyz670gdnb3jv-sed-4.8/bin:/gnu/store/14c1lz6vp2wqs6gh7m48rw3klx6bkvm8-grep-3.6/bin:/gnu/store/yixhh3q2i1x8pqpfq9nz83p15svg698m-coreutils-8.32/bin:/gnu/store/zz2br0lgdw6j6x6yvd0x49775gwn3bry-make-4.3/bin:/gnu/store/sbnx4xjgw2f2c5hxvv2qfdiqqnqyi7zr-bash-minimal-5.1.8/bin:/gnu/store/0mdldh4ih1ff6d7lfya0d62d9vd5d5m8-ld-wrapper-0/bin:/gnu/store/xnxxwmcdv1fl14y9a7c9bkxx8r0rza1j-binutils-2.37/bin:/gnu/store/fnkgp9a8yq4401nijp8v5v7aq1vqrx70-gcc-10.3.0/bin:/gnu/store/bgw8ciirrbpxbds3v9wklf1isysqjlsl-glibc-2.33/bin:/gnu/store/bgw8ciirrbpxbds3v9wklf1isysqjlsl-glibc-2.33/sbin'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to `/gnu/store/iipgssk08gmmkwxv5iyv1lm3blilvdir-bzip2-1.0.8/include:/gnu/store/11gnzwa2qbqlg4pziysdk2fkbhrhhwrc-xz-5.2.5/include:/gnu/store/6s9hy00b522g268spk3qasd8j8mg5z7r-file-5.39/include:/gnu/store/7mfpmrswg4y7apk0hri9hiwgn6xbbh9q-gawk-5.1.0/include:/gnu/store/zz2br0lgdw6j6x6yvd0x49775gwn3bry-make-4.3/include:/gnu/store/xnxxwmcdv1fl14y9a7c9bkxx8r0rza1j-binutils-2.37/include:/gnu/store/fnkgp9a8yq4401nijp8v5v7aq1vqrx70-gcc-10.3.0/include:/gnu/store/bgw8ciirrbpxbds3v9wklf1isysqjlsl-glibc-2.33/include:/gnu/store/fgc0c133apyavjkjhjbz54afy3100wxq-linux-libre-headers-5.10.35/include'
environment variable `CPLUS_INCLUDE_PATH' set to `/gnu/store/iipgssk08gmmkwxv5iyv1lm3blilvdir-bzip2-1.0.8/include:/gnu/store/11gnzwa2qbqlg4pziysdk2fkbhrhhwrc-xz-5.2.5/include:/gnu/store/6s9hy00b522g268spk3qasd8j8mg5z7r-file-5.39/include:/gnu/store/7mfpmrswg4y7apk0hri9hiwgn6xbbh9q-gawk-5.1.0/include:/gnu/store/zz2br0lgdw6j6x6yvd0x49775gwn3bry-make-4.3/include:/gnu/store/xnxxwmcdv1fl14y9a7c9bkxx8r0rza1j-binutils-2.37/include:/gnu/store/fnkgp9a8yq4401nijp8v5v7aq1vqrx70-gcc-10.3.0/include/c++:/gnu/store/fnkgp9a8yq4401nijp8v5v7aq1vqrx70-gcc-10.3.0/include:/gnu/store/bgw8ciirrbpxbds3v9wklf1isysqjlsl-glibc-2.33/include:/gnu/store/fgc0c133apyavjkjhjbz54afy3100wxq-linux-libre-headers-5.10.35/include'
environment variable `LIBRARY_PATH' set to `/gnu/store/iipgssk08gmmkwxv5iyv1lm3blilvdir-bzip2-1.0.8/lib:/gnu/store/11gnzwa2qbqlg4pziysdk2fkbhrhhwrc-xz-5.2.5/lib:/gnu/store/6s9hy00b522g268spk3qasd8j8mg5z7r-file-5.39/lib:/gnu/store/7mfpmrswg4y7apk0hri9hiwgn6xbbh9q-gawk-5.1.0/lib:/gnu/store/xnxxwmcdv1fl14y9a7c9bkxx8r0rza1j-binutils-2.37/lib:/gnu/store/bgw8ciirrbpxbds3v9wklf1isysqjlsl-glibc-2.33/lib:/gnu/store/1xfiv21xwzqf3j56phh8j2lg227391y5-glibc-2.33-static/lib:/gnu/store/w34424h2ihfqfxn72aj08h8z5rjvfk0r-glibc-utf8-locales-2.33/lib'
environment variable `GUIX_LOCPATH' set to `/gnu/store/w34424h2ihfqfxn72aj08h8z5rjvfk0r-glibc-utf8-locales-2.33/lib/locale'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/.gitignore' -> `./.gitignore'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/AUTHORS' -> `./AUTHORS'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/ChangeLog' -> `./ChangeLog'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/Makefile.in' -> `./Makefile.in'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/NEWS' -> `./NEWS'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/README' -> `./README'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/configure.ac' -> `./configure.ac'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/defs.mak.in' -> `./defs.mak.in'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/COPYING' -> `./COPYING'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/wminput/.gitignore' -> `./wminput/.gitignore'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/wminput/Makefile.in' -> `./wminput/Makefile.in'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/wminput/README' -> `./wminput/README'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/wminput/action_enum.awk' -> `./wminput/action_enum.awk'
`/gnu/store/nb2py0jxpm4qmz2481m1mq61p3r0x2zg-git-checkout/wminput/action_enum.txt' -> `./wminput/action_enum.txt'

Planning to package Veloren in Guix

[Tobias Platen]

Hello,

Today I released my prerecorded talk about Gaming on Guix[1], where I
mentioned Veloren. So next I want to package Veloren, which is written
in Rust. 

Tobias

[1] https://tube.tchncs.de/w/wNhzvYHdSiiGNx8zFr3n7H

Re: cross compiling using qemu-user-static

[Tobias Platen]

is now fixed, I can now login from my laptop, and I also use two of my
laptops USB ports for both networking and charging the battery.

isengaara-openpandora:~$ uname -a
Linux isengaara-openpandora 3.2.57 #982 Sun Apr 20 20:33:11 EEST 2014
armv7l GNU/Linux
isengaara-openpandora:~$ ls /gnu/store/
01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-
lib
k384n83b8l5bdwsa05prhlw3wsmak40p-openssh-8.5p1
0acliwmd1gpd1y67bbx7lpl4sqzka2y6-gcc-cross-arm-linux-gnueabihf-7.5.0-
libkxb22znvi7jb3mmc596i33c3y3xsd4mh-ncurses-6.2
1v9ynmn33agz43np663l2bb9ck5n2i4l-linux-pam-
1.5.1  kz9r6h1dziyknbwgg6i5jpays5ggzf3c-profile
2dgh7v30fa85d515n2fghjjrsj56qnf5-linux-libre-headers-cross-arm-linux-
gnueabihf-5.4.20  mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16
3smqcfmicplwcrsbpqf7500i9hpkw8n7-glibc-cross-arm-linux-gnueabihf-
2.31   n0hnwyfvdrrwvg6dc0cbap74hjrazdcx-zlib-1.2.11
59rcg987542x54ryqypkvk68n32gkg82-openssl-
1.1.1k 
pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16
bcjcd97xvh0qkvq1maqj6qab88xb30dv-bash-static-
5.0.16 
r0lvhigifp9acp6razf3r4ccbazpnvbq-libedit-20191231-3.1
bjjikcvyr6m5yiv6h21p3088wh92lv3a-info-
dir
skjd1576693sppg33vp9nzlpmfvwqs3y-mit-krb5-1.18
fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-
2.31   
x84gw65mhp1hz89b005k5g904pr1xp68-gcc-cross-sans-libc-arm-linux-gnueabihf-7.5.0-lib
gznjmd83vrqd5zdm7ryk998whvxf7la3-manual-
database   
zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2

cross compiling using qemu-user-static

[Tobias Platen]

Some time ago I was able to cross compile emacs to run on the
OpenPandora[1] using guix. That seems to be broken:

guix pack --target=armhf-linux-gnu openssh emacs libhandy
guix pack: error: gnu/packages/emacs.scm:77:2: emacs@27.2: build system
`glib-or-gtk' does not support cross builds

So I think one could copy qemu-user-static for the target architecture
into the build directory and execute native versions of the software.

[1] http://www.openpandora.org/

Re: Desktops on non-x86_64 systems

[Tobias Platen]

On Sat, 2021-11-27 at 19:43 -0800, John Soo wrote:
> Hi Guix,
> 
> I had the same thought as Maxim. In my quest for arm support for ghc,
> I thought about using a cross-compiled version. Is this possible or
> even desirable?  I think for rust and ghc it would be very helpful -
> if somewhat less principled than a bootstrap all the way up (on the
> same computer).
> 
> I'm curious what the consensus is here.
> 
> Kindly,
> 
> John
> 
>  
I have a Talos II, on which I have rust running. But that one is not in
Debian or GUIX, it uses its own installer. Rust is needed for the
power-instruction-analyzer and Kazan (a Vulkan implementation). Both
are part of the libre-soc project. https://libre-soc.org/

Tobias

Re: Guix packaging meetup: Saturday 27 November

[Tobias Platen]

I'm interested in joining that packaging meetup, since I have been
using Guix for some years, and want to package some software that I
have written and already packaged for Debian.

Tobias Alexandra

On Thu, 2021-11-25 at 22:01 +0100, Tobias Geerinckx-Rice wrote:
> Hi jgart,
> 
> Thank you for the invitation!
> 
> jgart 写道：
> > Not sure what to do at this point.
> 
> At this point, not much: you might reply to the mail with a 
> non-empty subject, and hope that people will reply to that one, or 
> that they will manually copy it when replying to your original 
> post.  Others might add a meaningful subject of their own, as I 
> have tried to do.
> 
> Still, expect some untitled ‘Re:’ messages.  It's not the end of 
> the world :-)
> 
> Mailing list archives are just that: snapshots of each message 
> sent to members.  They do not generally offer a way to modify 
> recorded history[0].  They do not really track mutable state such 
> as ‘topics’.
> 
> Threading is (or should be) based on message IDs, although some 
> archivers will use the subject as an additional heuristic.
> 
> bug-guix/guix-patches are simple bug trackers built on top of 
> mailing lists that add such mutable state (‘bug title’, priority, 
> openness, etc.) but this is a separate database.
> 
> Kind regards,
> 
> T G-R
> 
> [0]: Exceptions like GDPR and ‘asking nicely to remove 
> embarrassing info’ exist, but are by definition exceptional and 
> often involve human administrator action.

XFCE on Guix System shows rootfs twice no USB flash drives

[Tobias Platen]

Hello,

I installed the GNU Guix System 1.3.0 on my Laptop using the XFCE
desktop. I can mount USB flashdevices using udiskctl and once mounted
they show up in thunar. But before mounting they do not show in thunar.
This behaviour is different from other GNU/Linux distros. I think a
package is missing.

Tobias

Re: Time for a request-for-comments process?

[Tobias Platen]

GNUnet has something similar called the GANA (GNUnet Assigned Numbers
Authority)

https://git.gnunet.org/gana.git/


On Thu, 2021-10-28 at 12:33 +0200, Bengt Richter wrote:
> Hi Zimoun, Ludo,
> 
> On +2021-10-28 10:42:02 +0200, zimoun wrote:
> > Hi Ludo,
> > 
> > On Wed, 27 Oct 2021 at 23:22, Ludovic Courtès  wrote:
> > 
> > > The recent ‘guix shell’ addition is almost anecdotal technically
> > > yet
> > > important for the project because users interact with Guix
> > > primarily
> > > through the CLI.  Adding a new command is a commitment (our users
> > > must
> > > trust it won’t change overnight), and getting the details wrong
> > > could
> > > make us fail to honor that commitment.
> > > 
> > > For ‘guix shell’ I left time for comments and repeatedly asked
> > > people to
> > > comment; yet pushing it was a bit stressful: Did I make a
> > > mistake?  Did
> > > everyone with a stake in this really have a chance to comment?
> > 
> > Note that the patch received many comments; especially v1.  Then,
> > only
> > two people commented for v2.  And v3 did not receive any general
> > LGTM –
> > I sent one for the two trivial parts I reviewed.
> > 
> > For me, one important root of the issue is the review process.  I
> > feel
> > the balance described in thread «Incentives for review» [1],
> > 
> >     There’s a balance to be found between no formal commitment
> > on
> >     behalf of committers, and a strict and codified commitment
> >     similar to what is required for participation in the
> > distros
> >     list¹.
> > 
> > is hard to found.  Because, on one hand, the project has to honor
> > commitments, and on the other hand, no one as team is committed to
> > do
> > it.
> > 
> > From my understanding, your message here is interesting because
> > somehow
> > you did a similar experience as maintainer of what is an usual
> > non-committer contributor experience; somehow explained by some of
> > my
> > soft ramblings from the thread «Incentives for review» [1]. :-)
> > Another
> > meaningful because similar, IMHO, failure of the review process is
> > patch#45692 [4].
> > 
> > As you know, I did some stats in order to find, or at least
> > discuss, how
> > to improve the situation grounded on current facts.  Aside, Debbugs
> > already provides insightful numbers [2], especially this one [3]:
> > 
> >     
> > 
> > The traffic on guix-patches is quite high and I do not know how
> > many
> > people subscribe – I guess few.  I hope the discussed improvements
> > of
> > Mumi will help.  Or perhaps if someone is willing to setup a Guix
> > official public-inbox; for example, the instance
> > https://yhetil.org/guix
> > is providing helpful tools for easily filtering, IMHO.
> > 
> > 1: 
> > 2: 
> > 3: 
> > 4: 
> > 
> > Closing parenthesis, back to your question. :-)
> > 
> > > That makes me think it’s perhaps time for a formalized
> > > request-for-comments (RFC) kind of process for such “major
> > > changes”.  We
> > > could draw inspiration from one of the many existing processes:
> > > Python’s
> > > PEPs, Scheme’s SRFIs, Nix’s RFCs, Rust’s MCPs, etc.  I think a
> > > major
> > > goal of the process would be to formalize a minimum and a maximum
> > > duration under which an RFC is under evaluation, and a mechanism
> > > to
> > > determine whether it’s accepted or withdrawn.
> > 
> > Aside the usual review process, at least my understanding what the
> > review process should be, you are asking for a special flag then
> > expose
> > materials to various channels of communication, IIUC.
> > 
> > For sure, it appears a good idea. :-)
> > 
> > Concretely, what does it mean “major changes”?  How many of these
> > do you
> > consider that happened in the recent two past years?
> > 
> > For example, the recent label-less input style [5] is one instance,
> > IMHO.  However, I do not remember* if it was discussed outside
> > guix-patches.
> > 
> > In addition to the change itself sent to guix-patches with an
> > associated
> > number, it could be worth to send that information elsewhere.
> > 
> > What would be this elsewhere?  Create another dedicated (low-
> > traffic)
> > list would scatter the information and I am not convinced it would
> > help
> > to gain attraction at the moment.  However, it would ease digging
> > in the
> > future because all would be in only one archive.
> 
>  Wherever "elsewhere" might be, I'd like notification when there is
> something
>  new to read.
> 
> I'm visualizing a screensaver hook where the screen is restored after
> being locked,
> like logging in the first or subsequent times, to show an
> intermediate popup
> before going on as usual. Sort of a dynamic motd (message of the
> day).
> 
> What I'd like then, to find out details, is 

Re: I just got my pinephone.

[Tobias Platen]

I ordered my Librem 5 about one year ago and I'm still waiting
for it. Since backorder shipping resumes October 2021, I expect to get
mine in Q4 2021. 

On Sat, 2021-10-02 at 09:04 -0400, Christine Lemmer-Webber wrote:
> jbra...@dismail.de writes:
> 
> > October 1, 2021 6:56 PM, "Christine Lemmer-Webber"
> >  wrote:
> > 
> > > I think the easiest step to first testing would be to install
> > > Guix
> > > (userspace package manager) from Debian on Mobian. I've been
> > > meaning to
> > > do that, haven't tried yet...
> > 
> > WeirdlyI'm not certain that I want guix on my pinephone. 
> > Specifically 
> > I got my Pinephone, because I was tired of google's spyware.  AND I
> > wanted
> > a life phone, which is a phone that is so boring to use, you put it
> > down
> > and go live a life instead.  :)
> > 
> > I've actually installed Mobian, removed the user "mobian" from the 
> > suoders list, and had my mom change the root password on my phone. 
> > So, my phone by design does not have firefox or tootle installed...
> > 
> > If I installed guix system, I could re-install those annoying apps 
> > that drain my life away.  It would be nice if guix system could 
> > create a user that is not allowed to install applications, or had
> > only a whitelist of applications that he could install. 
> > 
> > That's my two cents.  :)
> 
> Well I understand.  For years I've kept all the social stuff off my
> phone to not be too sucked into it.  I use a browser, but in read-
> only
> mode...!
> 
> > > 
> > > from there we can look at what's necessary to go full distro
> > > 
> > > Kaelyn  writes:
> > > 
> > > > Hi Guix!
> > > > 
> > > > I just received my pinephone this morning, so I'm going to be
> > > > interested in bringing Guix to the pinephone as well. I hope to
> > > > have
> > > > the capacity to help with the efforts, even if it's just the
> > > > occasional testing.
> > > > 
> > > > Cheers,
> > > > Kaelyn
> > > > 
> > > > Sent with ProtonMail Secure Email.
> > > > 
> > > > ‐‐‐ Original Message ‐‐‐
> > > > 
> > > > On Wednesday, September 1st, 2021 at 12:39 PM, Joshua Branson
> > > >  wrote:
> > > > 
> > > > > Hey Guix!
> > > > > 
> > > > > I just got my phinephone. It's currently running postmarketOS
> > > > > (1). I
> > > > > 
> > > > > usually work nights two nights a week 10pm-6am (EST) Sunday
> > > > > night and
> > > > > 
> > > > > Monday night. If a guix developer would like ssh access to it
> > > > > during
> > > > > 
> > > > > those times, then please let me know. If I should use Mobian
> > > > > instead
> > > > > 
> > > > > to help port guix to it, then I would be willing to switch.
> > > > > 
> > > > > I'd be happy to help out! Also jmp.chat (2) works really well
> > > > > with
> > > > > 
> > > > > chatty.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Joshua
> > > > > 
> > > > > 1. https://postmarketos.org/source-code
> > > > > 2. https://jmp.chat
> 
> 

Guix pull fails on my Talos II

[Tobias Platen]

/gnu/store/vc2j3816jx9z4vgrw6zmk357xrka3zy0-texlive-latex-amsmath-51265.drv 
wird erstellt …
\ „build“-PhaseBacktrace:
  13 (primitive-load 
"/gnu/store/y5sniqlw2x5aaixyk4bw162v2a7bwdpl-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2090:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1927:8  7 (_ _)
In ./guix/gexp.scm:
   275:18  6 (_ _)
   1156:2  5 (_ _)
   1022:2  4 (_ _)
868:4  3 (_ _)
In ./guix/store.scm:
  1975:12  2 (_ #)
   1377:5  1 (map/accumulate-builds # _ _)
  1388:15  0 (_ # _ _)

./guix/store.scm:1388:15: ERROR:
  1. :
  message: "build of 
`/gnu/store/bbvxcaa31h006wg2kp1ysly55hkm56hn-po4a-0.63.drv' failed"
  status: 100
guix pull: error: You found a bug: the program 
'/gnu/store/y5sniqlw2x5aaixyk4bw162v2a7bwdpl-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"6243ad3812f8c689599a19f0e8b9719ba14461f2"; system: "powerpc64le-linux";
host version: "1.3.0"; pull-version: 1).
Please report it by email to .

-- 
Tobias Platen 

Re: Libre GPU/VPU/SOC updates/OFF TOPIC

[Tobias Platen]

On Wed, 30 Jun 2021 23:08:28 +0200
Ricardo Wurmus  wrote:

> It was never completed.  I supported the campaign back then, but I 
> never received that first EOMA68-A20 “Libre Tea” computer card.

For porting to the EOMA68-A20 we can use similar hardware that uses the same 
SOC. 
For the Libre-SOC port we can start with a Talos II or BlackBird. 

-- 
Tobias Platen 

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Tobias Platen]

For me the best way to run 32 bit powerpc software,
is using KVM on a POWER9 system. The https://www.powerpc-notebook.org/
will run 32 bit software as well. 

Tobias

On Wed, 26 May 2021 16:09:29 +0200
Ludovic Courtès  wrote:

> Hi,
> 
> Efraim Flashner  skribis:
> 
> > On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote:
> 
> [...]
> 
> >> Maybe it’s more readable to keep it as a bullet list, like:
> >> 
> >>   @item mips64el-linux (@emph{unsupported})
> >>   …
> >> 
> >>   @item powerpc-linux (@emph{unsupported})
> >>   …
> >> 
> >> with a sentence explaining what “unsupported” means.
> >
> > That was kind-of my idea with grouping them together
> 
> Yes, but people who just skim through that page may just see that
> ‘powerpc-linux’ is listed, without noticing that there’s a sentence ten
> line above that says “The following arches are not supported”.  Having
> “unsupported” next to it should avoid that (yes, I’ve learned to be
> super cautious.  :-)).
> 
> >> IMO guix.m4 should either require --with-courage or emit a prominent
> >> warning for these.
> 
> [...]
> 
> > The problem then becomes whoever tinkers with it will have to keep
> > either a custom guix.m4 for their guix package or a custom guix package
> > with "--with-courage" as a configure-flag.
> 
> True.  In that case, let it go without ‘--with-courage’ but emit a
> warning with AC_MSG_WARN that points to the relevant section of the
> manual.
> 
> Deal?
> 
> Thanks!
> 
> Ludo’.
> 


-- 
Tobias Platen 

Re: Please review blog post draft: powerpc64le-linux support

[Tobias Platen]

On Fri, 09 Apr 2021 00:59:44 +0200
Léo Le Bouter  wrote:

> On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote:
> > They also say in that Twitter thread: "We have been putting together
> > our
> > systems from blob-free components only (sans NIC as is known and
> > being
> > actively worked), and this is an area where no low-cost blob-free
> > silicon is available right now."
> > 
> 
> I've been using the Free Software firmware replacement for the NIC
> since a while now and it's working great: 
> https://github.com/meklort/bcm5719-fw/

I've install that firmware on my Talos II and I can confirm that it works.
I have reviewed 0001-website-drafts-Add-powerpc64le-linux-announcement.patch 
and it looks good.
It would be good to mention the Libre-SoC project(https://libre-soc.org/), 
which might be a good target for the future.

Tobias

--
Sent from my IBM 7094

Re: I've rebased wip-ppc64le onto core-updates

[Tobias Platen]

On Sun, 28 Feb 2021 21:42:44 +0100
Léo Le Bouter  wrote:

> On Sat, 2021-02-27 at 22:53 -0800, Chris Marusich wrote:
> > Hi Léo and others,
> > 
> > I just wanted to let you know that I've rebased the wip-ppc64le
> > branch
> > onto core-updates.  The wip-ppc64le branch head used to be
> > 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> > df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
> > 
> > I wanted to inform you so you don't get caught off-guard the next
> > time
> > you update your local copy.
> > 
> > I've squished some commits together where it made sense to do
> > so.  I've
> > omitted some commits which were cherry-picked before, but which are
> > already in the core-updates branch.  And I have explicitly NOT merged
> > master into wip-ppc64le at this time.
> > 
> > I have also taken the liberty of cherry-picking Tobias' commit
> > 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo
> > to
> > .guix-authorizations.  This should allow him to add commits on
> > wip-ppc64le without worrying about causing problems for "guix pull"
> > later.
> > 
> 
> Thanks a bunch!!
> 
> Léo

In my recent talk about the guix port to POWER9, 
I also mentioned the libre-soc project.
Unlike POWER9 and maybe POWER8, libre-soc and microwatt do not implement VSX.
The libre-soc project instead has SVP64, and also plans to extend the POWER ISA
to support GPU like instructions. Since I work mostly on the libre-soc I will 
have
less time to contribute to the GUIx project.

The relevant bug report to GUIX is
https://bugs.libre-soc.org/show_bug.cgi?id=602

-- 
Tobias Platen 

Music Production on Guix System

[Tobias Platen]

I liked Ricardo's blogpost "Music Production on Guix System", which I read last 
weekend while installing the Guix System on my laptop. 
For the next release I might be interested in contributing to the release song 
as well. I'm also a Lilypond user, I got into Scheme
when I started hacking the Festival Speech Synthesis System. This week I plan 
to submit a python package called utauly[1] to guix.
I also plan to do multiple Music Production on GNU/Linux workshops soon, using 
BigBlueButton[2]. There first one will be held next Monday.

[1] https://notabug.org/isengaara/python-utauly
[2] https://www.qtau.de/

-- 
Tobias Platen 

Re: GNU Guix 1.2.0rc1 available for testing!

[Tobias Platen]

On Tue, 17 Nov 2020 19:13:28 +0100
Mathieu Othacehe  wrote:

Just saw that GNU Guix 1.2.0 released was recently released.
In the Ode to 1.2.0 the back vocals are done by Festival (likely 
singing-mode.scm).
Can I have the XML file that that was given to Festival.

> 
> Hey,
> 
> > One this patch is in, I think we’re ready for either an RC2 or the real
> > thing.
> 
> Pushed to 1.2.0 and master. Thanks Florian for all the testing!
> 
> No objections to make the rc2 the final one.
> 
> Thanks,
> 
> Mathieu
> 


-- 
Tobias Platen 

Re: Guix now compiles on my Talos II, but download fails

[Tobias Platen]

On Mon, 9 Nov 2020 22:13:52 +0100
Tobias Platen  wrote:

> I checked out the wip-ppc branch which I compiled on my Talos II.

Guix now runs and is able to download files and put them in the store.

./pre-inst-env guix download https://ftp.gnu.org/gnu/guix/guix-1.1.0.tar.gz
works, but other commands that download files do not work, with the following 
error message:

building /gnu/store/gcsaa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv...
error: failed to run download program '/home/user/guix-ppc/guix/scripts/guix': 
Permission denied
builder for `/gnu/store/gcsaa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv' 
failed with exit code 1
build of /gnu/store/gcsaa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv 
failed
View build log at 
'/usr/local/var/log/guix/drvs/gc/saa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv.gz'.
cannot build derivation 
`/gnu/store/n4r9d1rxw6091s878wz7p6658mdzpjzj-hello-2.10.drv': 1 dependencies 
couldn't be built
guix build: error: build of 
`/gnu/store/n4r9d1rxw6091s878wz7p6658mdzpjzj-hello-2.10.drv' failed





-- 
Tobias Platen 

Re: Guix now compiles on my Talos II

[Tobias Platen]

On Thu, 12 Nov 2020 18:22:18 -0500
Joshua Branson  wrote:

Guix does compile, everything else is still untested.
That took my 6 hours to compile everything from scratch,
half of that time was needed to compile guile itsself.

I've also uploaded my talk which I did last week.
http://platen-software.de/tobias/GUIX_PPC/
> 
> Does most software compile for it?
> 
> Are you running gnome?  Or something else?
> 
> Thanks,
> 
> -- 
> Joshua Branson
> Sent from Emacs and Gnus
> https://gnucode.me
> https://video.hardlimit.com/accounts/joshua_branson/video-channels
> "You can have whatever you want, as long as you help enough other people get 
> what they want." - Zig Ziglar


-- 
Tobias Platen 

Working Guix on 64 bit PowerPC.

[Tobias Platen]

Hello,

I've got the wip-ppc branch of Guix compiling unmodified on my Talos II.
Since the POWER9 is backwards compatible with the PowerPC G4, it can run
the existing bootstrap binaries for powerpc-linux. The binaries from
http://flashner.co.il/guix/bootstrap/powerpc-linux/ have been verified
working on my Talos II. I also plan to setup a mirror of those binaries.

[user@staticvoid guix]$ arch
ppc64
[user@staticvoid guix]$ ps -A | grep guix
 1104 pts/100:00:00 guix-daemon
[user@staticvoid guix]$ ./pre-inst-env guix build hello
guix build: error: could not find bootstrap binary 'tar' for system 
'powerpc64-linux'
[user@staticvoid guix]$ cat /proc/cpuinfo 
processor   : 0
cpu : POWER9, altivec supported
clock   : 2154.00MHz
revision: 2.2 (pvr 004e 1202)

-- 
Tobias Platen 

Guix now compiles on my Talos II

[Tobias Platen]

I checked out the wip-ppc branch which I compiled on my Talos II.

-- 
Tobias Platen 

Re: Porting Guix to RISCV

[Tobias Platen]

On Tue, 3 Nov 2020 11:06:20 +0100
Matias Jose Seco Baccanelli  wrote:

> are efforts ongoing to integrate Power architecture in Guix, you 
> can find the latest additions on the "wip-ppc" branch[1].
> 
> There's actually a blocking issue related to reproducibility[2].
> 
> You're welcome for any hint to try out Guix on Libre-Soc platform, would 
> be awesome!
> 
> Have a happy hacking day!
Yes, I was actually able to run a 32-bit program on my Talos II. 

[user@staticvoid ~]$ file 
/gnu/store/mizksigsqgn3h4mvignqg8j8hjlwrbg3-hello-2.10/bin/hello
/gnu/store/mizksigsqgn3h4mvignqg8j8hjlwrbg3-hello-2.10/bin/hello: ELF 32-bit 
MSB executable, PowerPC or cisco 4500, version 1 (SYSV), d
ynamically linked, interpreter 
/gnu/store/m5rbrwvzaw526i0aiwkfjzihxha3phkd-glibc-cross-powerpc-linux-gnu-2.29/lib/ld.so.1,
 for GNU/Linu
x 2.6.32, not stripped
[user@staticvoid ~]$ arch
ppc64
[user@staticvoid ~]$ 
/gnu/store/mizksigsqgn3h4mvignqg8j8hjlwrbg3-hello-2.10/bin/hello
Hello, world!
[user@staticvoid ~]$ 


-- 
Tobias Platen 

Re: Porting Guix to RISCV

[Tobias Platen]

On Sat, 31 Oct 2020 12:52:19 -0700
Vagrant Cascadian  wrote:

> On 2020-10-31, Pjotr Prins wrote:
> > Anyone interested in porting GNU Mes and GNU Guix to RISCV? We can try
> > and purchase the hardware. We have a Polarfire running
> >
> >   https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit
> >
> > and there are more options coming. I am happy to support such an
> > initiative and buy the hardware.
> 
> I added a few RISC-V related packages to guix already:
> 
>   u-boot-qemu-riscv64
>   u-boot-qemu-riscv64-smode
>   u-boot-sifive-fu540
>   opensbi-sifive-fu540
>   opensbi-qemu-sifive-u
>   linux-libre-riscv64-generic
> 
> Got as far as booting a kernel in qemu, at least. So the basic boot
> infrastructure is at least partly there...
> 
> So, I guess you could count me as interested. :)
> 
> 
> live well,
>   vagrant
The libre-soc also supports riscv userspace, but its primary architectrue is 
the POWER ISA.
Therefore I propose to port guix to the POWER architecture too. 

Tobias

-- 
Tobias Platen 

Crosscompiling C++ for powerpc64le fails

[Tobias Platen]

Hello,

Im trying to cross compile basic GNU software such as bash and coreutils
for powerpc.

When building mpfr the build fails using the message above. I guess I
have to specify the include paths for glibc to the configure script,
since headers won't be found in /usr/include

Tobias


configure:10515: checking C++ compiler powerpc64le-linux-g++  -m64  -O3
Test compile: 
configure:10529: powerpc64le-linux-g++  -m64  -O3 conftest.cc >&5
configure:10532: $? = 0
Test compile: namespace
configure:10569: powerpc64le-linux-g++  -m64  -O3 conftest.cc >&5
configure:10572: $? = 0
Test compile: std iostream
configure:10615: powerpc64le-linux-g++  -m64  -O3 conftest.cc >&5
In file included from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ext/string_conversions.h:41:0,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/basic_string.h:6361,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/string:52,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/locale_classes.h:40,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/ios_base.h:41,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ios:42,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ostream:38,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/iostream:39,
 from conftest.cc:3:
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/cstdlib:75:15:
 fatal error: stdlib.h: No such file or directory
 #include_next 
   ^~
compilation terminated.
configure:10618: $? = 1
failed program was:
/* This test rejects g++ 2.7.2 which doesn't have , only a
pre-standard iostream.h. */
#include 

/* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream
   mode, since that mode puts cout in the global namespace, not "std".  */
void someoutput (void) { std::cout << 123; }

int main (void) { return 0; }
configure:10644: result: no, std iostream
configure:10515: checking C++ compiler powerpc64le-linux-g++  -g -O2
Test compile: 
configure:10529: powerpc64le-linux-g++  -g -O2 conftest.cc >&5
configure:10532: $? = 0
Test compile: namespace
configure:10569: powerpc64le-linux-g++  -g -O2 conftest.cc >&5
configure:10572: $? = 0
Test compile: std iostream
configure:10615: powerpc64le-linux-g++  -g -O2 conftest.cc >&5
In file included from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ext/string_conversions.h:41:0,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/basic_string.h:6361,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/string:52,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/locale_classes.h:40,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/ios_base.h:41,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ios:42,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ostream:38,
 from 
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/iostream:39,
 from conftest.cc:3:
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/cstdlib:75:15:
 fatal error: stdlib.h: No such file or directory
 #include_next 
   ^~
compilation terminated.
configure:10618: $? = 1
failed program was:
/* This test rejects g++ 2.7.2 which doesn't have , only a
pre-standard iostream.h. */
#include 

/* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream
   mode, since that mode puts cout in the global namespace, not "std".  */
void someoutput (void) { std::cout << 123; }

int main (void) { return 0; }
configure:10644: result: no, std iostream
configure:10660: error: C++ compiler not available, see config.log for details

Re: GNU Guix 1.0.0 released

[Tobias Platen]

Am 02.05.2019 um 14:12 schrieb Ludovic Courtès:
> We are thrilled to announce the release of GNU Guix 1.0.0!
>
> This 1.0 release is a major milestone for Guix.  It represents 7 years
> of hard work with more than 40,000 commits by 260 people, 19 releases,
> and an equally amazing amount of work on documentation, translation,
> artwork, web design, mentoring, outreach, and many other activities that
> together have made it a thriving project.
>
> Read more about today’s announcement at:
>
>   https://gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released
>
> Whether you’re a software developer, a user, or a free software
> enthusiast, we hope GNU Guix will provide you with the tools to deploy
> and manage software with confidence and ease, qualities that are not
> usually associated with software deployment.  We’d love to hear from you!
>
> • About
>
>   GNU Guix is a transactional package manager and an advanced
>   distribution of the GNU system that respects user freedom.  Guix can
>   be used on top of any system running the kernel Linux, or it can be
>   used as a standalone operating system distribution for i686, x86_64,
>   ARMv7, and AArch64 machines.
>
>   In addition to standard package management features, Guix supports
>   transactional upgrades and roll-backs, unprivileged package
>   management, per-user profiles, and garbage collection.  When used as a
>   standalone GNU/Linux distribution, Guix offers a declarative,
>   stateless approach to operating system configuration management.  Guix
>   is highly customizable and hackable through Guile programming
>   interfaces and extensions to the Scheme language.
>
>   https://www.gnu.org/software/guix/
>
> • Download
>
>   Here are the compressed sources and a GPG detached signature[*]:
> https://ftp.gnu.org/gnu/guix/guix-1.0.0.tar.gz
> https://ftp.gnu.org/gnu/guix/guix-1.0.0.tar.gz.sig
>
>   Here are the bootable USB installation images and their signatures[*]:
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.i686-linux.iso.xz
> 
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.i686-linux.iso.xz.sig
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz
> 
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz.sig
>
>   Here is the QCOW2 virtual machine (VM) image and its signature:
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.0.x86_64-linux.xz
> 
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.0.x86_64-linux.xz.sig
>
>   Here are the binary tarballs and their signatures[*]:
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.i686-linux.tar.xz
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.i686-linux.tar.xz.sig
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.x86_64-linux.tar.xz
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.x86_64-linux.tar.xz.sig
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.armhf-linux.tar.xz
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.armhf-linux.tar.xz.sig
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.aarch64-linux.tar.xz
> https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.aarch64-linux.tar.xz.sig
>
>   Use a mirror for higher download bandwidth:
> https://www.gnu.org/order/ftp.html
>   
>   Here are the SHA1 checksums:
>
>   fd64cd4347214a4e75d611696c9929cba8995323  guix-1.0.0.tar.gz
>   c17006616782405eee852dbd85292e73a0182d7e  
> guix-binary-1.0.0.aarch64-linux.tar.xz
>   9b168fa2835f911b9f340f2930d28b1287b53004  
> guix-binary-1.0.0.armhf-linux.tar.xz
>   a75a2571cc7aa8dbbb0a355bf1a29f4475c243ff  
> guix-binary-1.0.0.i686-linux.tar.xz
>   6ebfcb5cbed6dcd0c7514b8b3f2406125d30f1a5  
> guix-binary-1.0.0.x86_64-linux.tar.xz
>   c9f67b69b45a0ac4946e4472511e925782129e92  
> guix-system-install-1.0.0.i686-linux.iso.xz
>   802177714b7c96cf83dcab4b24e36f3111ba64b8  
> guix-system-install-1.0.0.x86_64-linux.iso.xz
>   244c3218326a706f495bfa2a7c03fe5f68549a8e  
> guix-system-vm-image-1.0.0.x86_64-linux.xz
>   
>   [*] Use a .sig file to verify that the corresponding file (without the
>   .sig suffix) is intact.  First, be sure to download both the .sig file
>   and the corresponding tarball.  Then, run a command like this:
>   
> gpg --verify guix-1.0.0.tar.gz.sig
>   
>   If that command fails because you don't have the required public key,
>   then run this command to import it:
>   
> gpg --keyserver pool.sks-keyservers.net \
> --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
>   
>   and rerun the 'gpg --verify' command.
>
>   To install the standalone Guix system, please see “System
>   Installation” in the manual.  To install Guix on a running system, see
>   “Installation” in the manual.
>
> • Changes since version 0.16.0 (excerpt from the NEWS file)
>
>  ** Package management
>  *** New ‘-v’/‘--verbosity’ option for all commands
>  *** Most commands now default to verbosity level 1 (“quiet”)
>  *** New ‘guix package’ aliases: ‘install’, 

Re: Guix on Purism's Librems?

[Tobias Platen]

Am 18.04.2019 um 04:44 schrieb Katherine Cox-Buday:

> Hey all,
>
> I brought this up in IRC tonight, and I thought I'd cast a net on the
> mailing list to collect experiences. I am considering purchasing a
> Librem laptop, and I was curious how Guix runs on it. Would anyone who
> has these laptops (especially if you have a version with the TPM and
> head) care to write up an experience-report?
>
> Also, would it make sense for us to have a package specifically for
> hardware like this to make it easier to build install images for the
> machines? Even if the packages don't do much, there is still value in
> declaring that the specific configuration of hardware has been
> investigated, and is supported.
>
Guix runs on two of my coreboot machines: the ThinkPad X200 and the
Vikings D16.
Since the Librem laptop has Intel ME, it won't respect privacy and
freedom. [1]
The Talos II [2] and the upcoming PowerPC notebook [3] do not have that
problem.
Currently I am working on a port to Guix to PPC64EL so that I can use
Guix on my Talos II.

Tobias

[1]
https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom
[2] https://www.raptorcs.com/
[3] https://www.powerpc-notebook.org/en/

Failure to build powerpc64le-linux glibc

[Tobias Platen]

Hello,

I have tried to cross compile the bootstrap binaries for ppc64le using

./pre-inst-env guix build --target=powerpc64le-linux bootstrap-tarballs

but the build failed again, it seems that this is a known bug that
affects other architectures.

https://lists.gnu.org/archive/html/bug-guix/2015-01/msg00014.html



Tobias

a - string/strcspn-power8.os
a - string/strcspn-ppc64.os
a - string/strlen-power8.os
a - string/strcasestr-power8.os
a - string/strcasestr-ppc64.os
a - string/strcasecmp-ppc64.os
a - string/strcasecmp-power8.os
a - string/strncase-ppc64.os
a - string/strncase-power8.os
a - wcsmbs/wcscat.os
a - wcsmbs/wcschr.os
a - wcsmbs/wcscmp.os
a - wcsmbs/wcscpy.os
a - wcsmbs/wcscspn.os
a - wcsmbs/wcsdup.os
a - wcsmbs/wcslen.os
a - wcsmbs/wcsncat.os
a - wcsmbs/wcsncmp.os
a - wcsmbs/wcsncpy.os
a - wcsmbs/wcspbrk.os
a - wcsmbs/wcsrchr.os
a - wcsmbs/wcsspn.os
a - wcsmbs/wcstok.os
a - wcsmbs/wcsstr.os
a - wcsmbs/wmemchr.os
a - wcsmbs/wmemcmp.os
a - wcsmbs/wmemcpy.os
a - wcsmbs/wmemmove.os
a - wcsmbs/wmemset.os
a - wcsmbs/wcpcpy.os
a - wcsmbs/wcpncpy.os
a - wcsmbs/wmempcpy.os
a - wcsmbs/btowc.os
a - wcsmbs/wctob.os
a - wcsmbs/mbsinit.os
a - wcsmbs/mbrlen.os
a - wcsmbs/mbrtowc.os
a - wcsmbs/wcrtomb.os
a - wcsmbs/mbsrtowcs.os
a - wcsmbs/wcsrtombs.os
a - wcsmbs/mbsnrtowcs.os
a - wcsmbs/wcsnrtombs.os
a - wcsmbs/wcsnlen.os
a - wcsmbs/wcschrnul.os
a - wcsmbs/wcstol.os
a - wcsmbs/wcstoul.os
a - wcsmbs/wcstoll.os
a - wcsmbs/wcstoull.os
a - wcsmbs/wcstod.os
a - wcsmbs/wcstold.os
a - wcsmbs/wcstof.os
a - wcsmbs/wcstol_l.os
a - wcsmbs/wcstoul_l.os
a - wcsmbs/wcstoll_l.os
a - wcsmbs/wcstoull_l.os
a - wcsmbs/wcstod_l.os
a - wcsmbs/wcstold_l.os
a - wcsmbs/wcstof_l.os
a - wcsmbs/wcstod_nan.os
a - wcsmbs/wcstold_nan.os
a - wcsmbs/wcstof_nan.os
a - wcsmbs/wcscoll.os
a - wcsmbs/wcsxfrm.os
a - wcsmbs/wcwidth.os
a - wcsmbs/wcswidth.os
a - wcsmbs/wcscoll_l.os
a - wcsmbs/wcsxfrm_l.os
a - wcsmbs/wcscasecmp.os
a - wcsmbs/wcsncase.os
a - wcsmbs/wcscasecmp_l.os
a - wcsmbs/wcsncase_l.os
a - wcsmbs/wcsmbsload.os
a - wcsmbs/mbsrtowcs_l.os
a - wcsmbs/isoc99_wscanf.os
a - wcsmbs/isoc99_vwscanf.os
a - wcsmbs/isoc99_fwscanf.os
a - wcsmbs/isoc99_vfwscanf.os
a - wcsmbs/isoc99_swscanf.os
a - wcsmbs/isoc99_vswscanf.os
a - wcsmbs/mbrtoc16.os
a - wcsmbs/c16rtomb.os
a - wcsmbs/wcstof128_l.os
a - wcsmbs/wcstof128.os
a - wcsmbs/wcstof128_nan.os
a - wcsmbs/wcschr-power7.os
a - wcsmbs/wcschr-power6.os
a - wcsmbs/wcschr-ppc64.os
a - wcsmbs/wcsrchr-power7.os
a - wcsmbs/wcsrchr-power6.os
a - wcsmbs/wcsrchr-ppc64.os
a - wcsmbs/wcscpy-power7.os
a - wcsmbs/wcscpy-power6.os
a - wcsmbs/wcscpy-ppc64.os
a - time/offtime.os
a - time/asctime.os
a - time/clock.os
a - time/ctime.os
a - time/ctime_r.os
a - time/difftime.os
a - time/gmtime.os
a - time/localtime.os
a - time/mktime.os
a - time/time.os
a - time/gettimeofday.os
a - time/settimeofday.os
a - time/adjtime.os
a - time/tzset.os
a - time/tzfile.os
a - time/getitimer.os
a - time/setitimer.os
a - time/stime.os
a - time/dysize.os
a - time/timegm.os
a - time/ftime.os
a - time/getdate.os
a - time/strptime.os
a - time/strptime_l.os
a - time/strftime.os
a - time/wcsftime.os
a - time/strftime_l.os
a - time/wcsftime_l.os
a - time/timespec_get.os
a - time/era.os
a - time/alt_digit.os
a - time/lc-time-cleanup.os
a - time/ntp_gettime.os
a - time/ntp_gettimex.os
a - dirent/opendir.os
a - dirent/closedir.os
a - dirent/readdir.os
a - dirent/readdir_r.os
a - dirent/rewinddir.os
a - dirent/seekdir.os
a - dirent/telldir.os
a - dirent/scandir.os
a - dirent/alphasort.os
a - dirent/versionsort.os
a - dirent/getdents.os
a - dirent/getdents64.os
a - dirent/dirfd.os
a - dirent/readdir64.os
a - dirent/readdir64_r.os
a - dirent/scandir64.os
a - dirent/alphasort64.os
a - dirent/versionsort64.os
a - dirent/fdopendir.os
a - dirent/scandirat.os
a - dirent/scandirat64.os
a - dirent/scandir-cancel.os
a - dirent/scandir-tail.os
a - dirent/scandir64-tail.os
a - dirent/getdirentries.os
a - dirent/getdirentries64.os
a - grp/fgetgrent.os
a - grp/initgroups.os
a - grp/setgroups.os
a - grp/getgrent.os
a - grp/getgrgid.os
a - grp/getgrnam.os
a - grp/putgrent.os
a - grp/getgrent_r.os
a - grp/getgrgid_r.os
a - grp/getgrnam_r.os
a - grp/fgetgrent_r.os
a - grp/grp-merge.os
a - pwd/fgetpwent.os
a - pwd/getpw.os
a - pwd/putpwent.os
a - pwd/getpwent.os
a - pwd/getpwnam.os
a - pwd/getpwuid.os
a - pwd/getpwent_r.os
a - pwd/getpwnam_r.os
a - pwd/getpwuid_r.os
a - pwd/fgetpwent_r.os
a - posix/uname.os
a - posix/times.os
a - posix/wait.os
a - posix/waitpid.os
a - posix/wait3.os
a - posix/wait4.os
a - posix/waitid.os
a - posix/alarm.os
a - posix/sleep.os
a - posix/pause.os
a - posix/nanosleep.os
a - posix/fork.os
a - posix/vfork.os
a - posix/_exit.os
a - posix/execve.os
a - posix/fexecve.os
a - posix/execv.os
a - posix/execle.os
a - posix/execl.os
a - posix/execvp.os
a - posix/execlp.os
a - posix/execvpe.os
a - posix/getpid.os
a - posix/getppid.os
a - posix/getuid.os
a - posix/geteuid.os
a - posix/getgid.os
a - posix/getegid.os
a - posix/getgroups.os
a - 

Re: Patch adding POWER9 cross compile support

[Tobias Platen]

I had to work on the core-updates branch, or in the past on the wip-gcc7 
branch. I mentioned this some month ago. The current branch has an 
outdated gcc version.


On 03/12/2019 03:10 PM, Ludovic Courtès wrote:

Hi!

Efraim Flashner  skribis:


On Sun, Mar 10, 2019 at 09:20:04PM +0100, Tobias Platen wrote:

I ran configure on my Talos II, and got the following error message.

checking for the Guix system type... powerpc64le-linux


Sure but that’s the next step.  My question was about the triplet you
passed to ‘--target’ when cross-compiling from your Intel(?) machine,
but I think I can derive the answer now:

   guix build --target=powerpc64le-linux-gnu …


Guix already knows about this architecture, but building glibc will fail if
gcc does not have the float128 datatype. Once I saw this link[1] on the guix
mailing list, I knew how to solve the build error.

For the second question I could not find an answer.

[1] http://lists.busybox.net/pipermail/buildroot/2017-September/201379.html


Alright.

Thanks for the info.


In the off chance we ever wish to support powerpc64 big endian, I
suggest instead using (string-prefix? "powerpc64*-" target)


Yes.

Unfortunately, with just this extra --with-long-double-128, this:

   guix build sed --target=powerpc64le-linux-gnu

eventually leads to a glibc build failure:

--8<---cut here---start->8---
running configure fragment for sysdeps/unix/sysv/linux/powerpc
checking whether powerpc64le-linux-gnu-gcc -g -O2 -mlong-double-128 uses IBM 
extended format... yes
running configure fragment for sysdeps/unix/sysv/linux
checking installed Linux kernel header files... 3.2.0 or later
configure: WARNING: minimum kernel version reset to 3.10.0
checking for kernel header at least 3.10.0... ok
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64/le
checking if powerpc64le-linux-gnu-gcc supports binary128 floating point type... 
no
checking if the target machine is at least POWER8... yes
configure: error: ***  binary128 floating point type (GCC >= 6.2) is required 
on powerpc64le.
--8<---cut here---end--->8---

See ‘config.log’ excerpt below.  Do you happen to have an additional
change needed?

Thanks,
Ludo’.

--8<---cut here---start->8---
configure:6698: result: running configure fragment for 
sysdeps/powerpc/powerpc64/le
configure:5: checking if powerpc64le-linux-gnu-gcc supports binary128 floating 
point type
configure:31: powerpc64le-linux-gnu-gcc -c -g -O2 -Werror -mfloat128  conftest.c 
>&5
powerpc64le-linux-gnu-gcc: error: unrecognized command line option '-mfloat128'
configure:31: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "glibc"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla/;
| #define PACKAGE_URL "http://www.gnu.org/software/glibc/;
| #define PKGVERSION "(GNU libc) "
| #define REPORT_BUGS_TO "<http://www.gnu.org/software/libc/bugs.html>"
| #define HAVE_TUNABLES 1
| #define HAVE_CC_NO_STACK_PROTECTOR 1
| #define STACK_PROTECTOR_LEVEL 0
| #define USE_MULTIARCH 1
| #define HAVE_ASM_SET_DIRECTIVE 1
| #define HAVE_SDATA_SECTION 1
| #define NO_CTORS_DTORS_SECTIONS 1
| #define HAVE_Z_COMBRELOC 1
| #define HAVE_CC_INHIBIT_LOOP_TO_LIBCALL 1

| #define HAVE_EHDR_START 1
| #define HAVE_BUILTIN_TRAP 1
| #define HAVE_ELFV2_ABI 1
| #define __LINUX_KERNEL_VERSION (3 * 65536 + 10 * 256 + 0)
| #define __ABI_TAG_VERSION 2,6,32
| #define HAVE_INLINED_SYSCALLS 1
| /* end confdefs.h.  */
|
| __float128 a, b, c, d, e;
| int i;
|
| __float128
| foobar (__float128 x)
| {
|   a = __builtin_nansq ("0");
|   b = __builtin_huge_valq ();
|   c = __builtin_infq ();
|   d = __builtin_fabsq (x);
|   e = __builtin_nanq ("0");
|   i = __builtin_signbit (x);
|   return __builtin_copysignq (x, x);
| }
|
configure:39: result: no
configure:47: checking if the target machine is at least POWER8
configure:61: powerpc64le-linux-gnu-gcc -c -g -O2   conftest.c >&5
configure:61: $? = 0
configure:68: result: yes
configure:75: error: ***  binary128 floating point type (GCC >= 6.2) is 
required on powerpc64le.
--8<---cut here---end--->8---

Re: Patch adding POWER9 cross compile support

[Tobias Platen]

I ran configure on my Talos II, and got the following error message.

checking for the Guix system type... powerpc64le-linux
configure: error: `powerpc64le-linux' is not a supported platform.
See "GNU Distribution" in the manual, or try `--with-courage'.

Guix already knows about this architecture, but building glibc will fail 
if gcc does not have the float128 datatype. Once I saw this link[1] on 
the guix mailing list, I knew how to solve the build error.


For the second question I could not find an answer.

[1] http://lists.busybox.net/pipermail/buildroot/2017-September/201379.html

Tobias

On 03/10/2019 06:27 PM, Ludovic Courtès wrote:

Hi Tobias,

Tobias Platen  skribis:


On 03/06/2019 02:54 PM, Ludovic Courtès wrote:

+   ,@(if (string-prefix? "powerpc9-" target)
+ ;; On POWER9 we need this because XXX.
+ '("--with-long-double-128")
+ '())
+

It needs to be ppc64el I think. I will later do a test in a big endian
vm. POWER9 is a bi-endian architecture, and most distros only support
little-endian. POWER4 only supports big-endian, and is still supported
by some distros. After testing I will send an updated patch.


I don’t think that answers my questions.  :-)

Those were:

   1. What GNU triplet do you use?




   2. What the reason for this extra configure flag, so we can add it in
  the comment above in place of XXX?

TIA!

Ludo’.

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 6a09272..0992259 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -138,6 +138,10 @@ base compiler and using LIBC (which may be either a libc package or #f.)"
"--disable-libquadmath"
"--disable-decimal-float" ;would need libc
"--disable-libcilkrts"
+   ,@(if (string-prefix? "powerpc64le-" target)
+   ;; On POWER9 (little endian) glibc needs the 128 bit long double type.
+   '("--with-long-double-128")
+   '())
 
;; When target is any OS other than 'none' these
;; libraries will fail if there is no libc

Re: Patch adding POWER9 cross compile support

[Tobias Platen]

On 03/06/2019 02:54 PM, Ludovic Courtès wrote:

+   ,@(if (string-prefix? "powerpc9-" target)
+ ;; On POWER9 we need this because XXX.
+ '("--with-long-double-128")
+ '())
+
It needs to be ppc64el I think. I will later do a test in a big endian 
vm. POWER9 is a bi-endian architecture, and most distros only support 
little-endian. POWER4 only supports big-endian, and is still supported 
by some distros. After testing I will send an updated patch.


Tobias

Re: Patch adding POWER9 cross compile support

[Tobias Platen]

In the next step I will try to build the bootstrap binaries.

On 02/27/2019 10:24 PM, Jonathan Brielmaier wrote:

On 2/27/19 7:29 PM, Tobias Platen wrote:

I succesfully crosscompiled GNU Hello and all its dependencies including
glibc for POWER9. Without my patch glibc will fail to build. I am using
the core-updates branch, since the default branch uses an outdated
version of GCC.

Tobias


Nice! And it's just a simple one-liner :P

I get following result for hello:
/gnu/store/x0372n45l5ckiddra4g2xjl693y2wld3-hello-2.10

Patch adding POWER9 cross compile support

[Tobias Platen]

I succesfully crosscompiled GNU Hello and all its dependencies including 
glibc for POWER9. Without my patch glibc will fail to build. I am using 
the core-updates branch, since the default branch uses an outdated 
version of GCC.


Tobias
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 8fe9d5b..f642bad 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -138,6 +138,8 @@ base compiler and using LIBC (which may be either a libc package or #f.)"
"--disable-decimal-float" ;would need libc
"--disable-libcilkrts"
 
+"--with-long-double-128" ; required for power9 bootstrap
+
;; When target is any OS other than 'none' these
;; libraries will fail if there is no libc
;; present. See

Re: Trying to crosscompile for POWER9

[Tobias Platen]

It is the same error in both cases.
the binary128 type is not avialable in gcc, but requires for glibc to build.
Im now trying out the GCC 7 branch

On 10/20/2018 08:31 PM, Efraim Flashner wrote:

On Sat, Oct 20, 2018 at 05:05:35PM +0200, Tobias Platen wrote:



On 10/16/2018 08:24 PM, Efraim Flashner wrote:

On Tue, Oct 16, 2018 at 08:08:27PM +0200, Tobias Platen wrote:

Hello,

When I try to compile GUIX for POWER9 an old version of GCC is used.
How do I use the gcc version used for cross compiling.

./pre-inst-env guix build --target=powerpc64le-linux hello

checking if powerpc64le-linux-gcc supports
binary128 floating point type... no
checking if the target machine is at least POWER8... yes

configure: error: ***
binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

Tobias "Tomoko" Platen



I'd recommend starting by editing gnu/packages/make-bootstrap.scm:103
and change the line:
`(("cross-gcc"  ,(cross-gcc target
to:
`(("cross-gcc"  ,(cross-gcc target #:gcc-6

there are other places, like lines 110 and 391 (and possibly others) which
should be turned to (inherit gcc-6)

That should work for this round, then you can decide if it's worth
upstreaming and wrap it in 'match' keywords for some of the newer
architectures (like riskv).


It still fails after changing to gcc 6


Where does it fail? It'd be nice if we can get it to work.

Re: Trying to crosscompile for POWER9

[Tobias Platen]

On 10/16/2018 08:24 PM, Efraim Flashner wrote:

On Tue, Oct 16, 2018 at 08:08:27PM +0200, Tobias Platen wrote:

Hello,

When I try to compile GUIX for POWER9 an old version of GCC is used.
How do I use the gcc version used for cross compiling.

./pre-inst-env guix build --target=powerpc64le-linux hello

checking if powerpc64le-linux-gcc supports
binary128 floating point type... no
checking if the target machine is at least POWER8... yes

configure: error: ***
binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

Tobias "Tomoko" Platen



I'd recommend starting by editing gnu/packages/make-bootstrap.scm:103
and change the line:
`(("cross-gcc"  ,(cross-gcc target
to:
`(("cross-gcc"  ,(cross-gcc target #:gcc-6

there are other places, like lines 110 and 391 (and possibly others) which
should be turned to (inherit gcc-6)

That should work for this round, then you can decide if it's worth
upstreaming and wrap it in 'match' keywords for some of the newer
architectures (like riskv).


It still fails after changing to gcc 6

Trying to crosscompile for POWER9

[Tobias Platen]

Hello,

When I try to compile GUIX for POWER9 an old version of GCC is used.
How do I use the gcc version used for cross compiling.

./pre-inst-env guix build --target=powerpc64le-linux hello

checking if powerpc64le-linux-gcc supports
binary128 floating point type... no
checking if the target machine is at least POWER8... yes

configure: error: ***
binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

Tobias "Tomoko" Platen

Re: Terrible Docs: Whats the qemu image password?

[Tobias Platen]

The username is root, and there is no password

Tobias

On 08.07.2018 07:04, Tommy Lane wrote:

So, what’s the qemu image password and username?

Thanks,
-Tommy

Re: Have GPGPU support in guix?

[Tobias Platen]

On 25.04.2018 19:17, Ricardo Wurmus wrote:


Hi,


I tried to use guix to manage many of my softwares on my system, but
some dependencies are missing which is blocking a full transition to
Guix based system and development environment. Most notably is GPU
computing support.

My daily routine is doing machine learning, which requires GPU for
computing nowadays.


I’m currently working on packaging Tensorflow (without GPU support).  I
don’t know if Tensorflow with GPU support will work with OpenCL.
I don't think that any modern GPU will be supported without non-free 
software. Many of them require blobs for power management and 
instruction scheduling.


Tobias Platen


--
Ricardo

Re: Scope of support for Guix on other distros

[Tobias Platen]

On 02.10.2017 20:52, Christopher Allan Webber wrote:
> ng0 writes:
> 
>> Christopher Allan Webber transcribed 0.6K bytes:
>>> Konrad Hinsen writes:
>>>
 On 02/10/2017 11:18, David Seaward wrote:

> To what extent is support for other distros a priority for the Guix
> project? In other words, explicitly planning to make Guix available as
> an alternate installation source on non-Guix-SD distros.

 That's already possible right now. Go to the download page and check for 
 "GNU Guix 0.13.0 Binary". This is Guix for other Linux distros, as a 
 look at the installation instructions will confirm. I am using this on a 
 Ubuntu 16.04 LTS installation on my laptop.

 Konrad.
>>>
>>> It would still be nice if we provided .deb/.rpm/etc files on that page.
>>
>> By my own observation, systems including Guix either officially
>> or by third-party / community methods:
> 
> Cool!
> 
>> Archlinux: https://aur.archlinux.org/packages/guix/
>> Gentoo: https://packages.gentoo.org/packages/sys-apps/guix
> 
> These provide Guix in their own upstream repository so I think it would
> be good to mention on the Download page.
> 
>> Debian: from past discussion and on request from Whonix iirc it is currently
>> not possible due to Debian Packaging Standards (expected package
>> behavior) or something along the lines, see guix-devel archives.
>> Fedora: https://copr.fedorainfracloud.org/coprs/lantw44/guix/
>> Slackware: https://slackbuilds.org/repository/14.2/system/guix/
>>is on 0.12, needs an update. Any slacker up for that task?
>>Otherwise, ping the maintainer:
>>> Maintained by: Hunter Sezen
Parabola also has guix, but an outdated version [1]. I installed the
latest binary version on my Parabola system, which I downloaded from
gnu.org.
> 
> Since these don't provide Guix in the main repo (and Debian won't
> because we violate the FHS with /gnu/) we could probably auto-generate
> the .deb or .rpm from some gexp? 
> 
Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu
could be moves to /usr/gnu on Debian.

[1] https://www.parabola.nu/packages/?q=guix

How to add library dependency to guix build

[Tobias Platen]

Hello,

I tried to package a speech syntesizer framework called WORLD for Guix,
which I had earlier packaged for Trisquel. The guix build process does
not find , even if I declared a dependency on libsndfile.

Tobias Platen
warning: failed to install locale: Invalid argument
The following package will be installed:
   world0.3.1   /gnu/store/g0x1z1rp639b1m48q1pq96am1fwlaik3-world-0.3.1

The following derivations will be built:
   /gnu/store/f9y64ns3dr3nlzbkyri1nk67v5qsrff7-profile.drv
   /gnu/store/sqwp9g3m5j6gg283bbbjj1bjxnbcdqk9-ca-certificate-bundle.drv
   /gnu/store/mvvdzf38m226dwklvkcv1dnr1jhzdv08-xdg-mime-database.drv
   /gnu/store/fi8mvnzcsan0gy7m6d240gpw96m6af9b-info-dir.drv
   /gnu/store/42g7f9jiyxkaiacbm8scaqsbmb3drmh2-fonts-dir.drv
   /gnu/store/1hwf475l9ghwmpz88svhpqlvckclrasb-gtk-icon-themes.drv
   /gnu/store/d8wswii4lw5a59zrhkxidxr7h0ncixgz-world-0.3.1.drv
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/zcn7lm8lf60q0756q7z9qpvl9z5wbh82-cmake-3.5.2/bin:/gnu/store/3a3qhlr9ssczrkjr10jllb01mbdgsijp-pulseaudio-8.0/bin:/gnu/store/2pdb9h9mdq7qnjj1b9b6k2a2md46idyj-tar-1.29/bin:/gnu/store/54ilw1jcicj7n259cpra59y6gik2mig2-gzip-1.8/bin:/gnu/store/pzk986yikywnql4x393pbhzbiz7vl72n-bzip2-1.0.6/bin:/gnu/store/p9c6hk9rdln5rz752fkwd6zxj2xs3sa9-xz-5.2.2/bin:/gnu/store/3nhg61n6p870vj1q654rbxrgsq5zsgsp-file-5.25/bin:/gnu/store/lr2vwc88wck5ra3p969rgk8nnqh111aj-diffutils-3.3/bin:/gnu/store/ni491r4ffm03v0cr70df12lwiq826das-patch-2.7.5/bin:/gnu/store/bzv2l4hx3j74jm49fb7g20900yqjdn22-sed-4.2.2/bin:/gnu/store/53p06lrr734a1xxa770xz9ddan4a2zjq-findutils-4.6.0/bin:/gnu/store/bd4m0d7h247iwwgl7wi3b28prv554gjn-gawk-4.1.3/bin:/gnu/store/dk9hvkwr5s4n22z9pjgcmxrppd08k286-grep-2.25/bin:/gnu/store/lpvkjic9dhj55plc29jhq8l39irvqm4f-coreutils-8.25/bin:/gnu/store/1iiqn2124niw1pvqfwr7wb3lxi28r67q-make-4.2/bin:/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin:/gnu/store/5k8z2aj8ca16nmvwvdsl0mdc3slm14k2-ld-wrapper-0/bin:/gnu/store/z53lxlrp7061vggbnhpxcsmad6lx96p8-binutils-2.25.1/bin:/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/bin:/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/bin:/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/sbin:/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12/bin:/gnu/store/y51frvdprzpq3skac6w392px91vyp4rq-libcap-2.24/sbin'
environment variable `CMAKE_PREFIX_PATH' set to 
`/gnu/store/zcn7lm8lf60q0756q7z9qpvl9z5wbh82-cmake-3.5.2/:/gnu/store/3a3qhlr9ssczrkjr10jllb01mbdgsijp-pulseaudio-8.0/:/gnu/store/2pdb9h9mdq7qnjj1b9b6k2a2md46idyj-tar-1.29/:/gnu/store/54ilw1jcicj7n259cpra59y6gik2mig2-gzip-1.8/:/gnu/store/pzk986yikywnql4x393pbhzbiz7vl72n-bzip2-1.0.6/:/gnu/store/p9c6hk9rdln5rz752fkwd6zxj2xs3sa9-xz-5.2.2/:/gnu/store/3nhg61n6p870vj1q654rbxrgsq5zsgsp-file-5.25/:/gnu/store/lr2vwc88wck5ra3p969rgk8nnqh111aj-diffutils-3.3/:/gnu/store/ni491r4ffm03v0cr70df12lwiq826das-patch-2.7.5/:/gnu/store/bzv2l4hx3j74jm49fb7g20900yqjdn22-sed-4.2.2/:/gnu/store/53p06lrr734a1xxa770xz9ddan4a2zjq-findutils-4.6.0/:/gnu/store/bd4m0d7h247iwwgl7wi3b28prv554gjn-gawk-4.1.3/:/gnu/store/dk9hvkwr5s4n22z9pjgcmxrppd08k286-grep-2.25/:/gnu/store/lpvkjic9dhj55plc29jhq8l39irvqm4f-coreutils-8.25/:/gnu/store/1iiqn2124niw1pvqfwr7wb3lxi28r67q-make-4.2/:/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/:/gnu/store/5k8z2aj8ca16nmvwvdsl0mdc3slm14k2-ld-wrapper-0/:/gnu/store/z53lxlrp7061vggbnhpxcsmad6lx96p8-binutils-2.25.1/:/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/:/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/:/gnu/store/w74j2phxh04phnspxmjg9hpzpk90054x-glibc-utf8-locales-2.23/:/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12/:/gnu/store/y51frvdprzpq3skac6w392px91vyp4rq-libcap-2.24/:/gnu/store/k3nwrfrgkg1bafhqi9w8inh2rr8njb1b-linux-libre-headers-4.1.18/'
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/3a3qhlr9ssczrkjr10jllb01mbdgsijp-pulseaudio-8.0/include:/gnu/store/pzk986yikywnql4x393pbhzbiz7vl72n-bzip2-1.0.6/include:/gnu/store/p9c6hk9rdln5rz752fkwd6zxj2xs3sa9-xz-5.2.2/include:/gnu/store/3nhg61n6p870vj1q654rbxrgsq5zsgsp-file-5.25/include:/gnu/store/bd4m0d7h247iwwgl7wi3b28prv554gjn-gawk-4.1.3/include:/gnu/store/1iiqn2124niw1pvqfwr7wb3lxi28r67q-make-4.2/include:/gnu/store/z53lxlrp7061vggbnhpxcsmad6lx96p8-binutils-2.25.1/include:/gnu/store/frrj3bfbmg5vrd0flh9cf8j64h7cr2v4-gcc-4.9.3/include:/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/include:/gnu/store/8pskv4xpdjg1grx3c2an3g5fqj8pcrgh-gdbm-1.12/include:/gnu/store/y51frvdprzpq3skac6w392px91vyp4rq-libcap-2.24/include:/gnu/store/k3nwrfrgkg1bafhqi9w8inh2rr8njb1b-linux-libre-headers-4.1.18/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/3a3qhlr9ssczrkjr10jllb01mbdgsijp-pulseaudio-8.0/include:/gnu/store/pzk986yikywnql4x393pbhzbiz7vl72n-bzip2-1.0.6/include:/gnu/store/p9c6hk9rdln5rz752fkwd6zxj2xs3sa9-xz-5.2.2/include:/gnu/store/3nhg61n6p870vj1q654rbxrgsq5zsgsp-file-5.25/include

New to GNU Guix packaging

[Tobias Platen]

Hello,

Recently I watched a video about GNU Guix, and concluded that this 
solves many of the technical problems that I have when I work on Debian 
packages for my own Trisquel addon repository [1] which contains music 
software. Instead of contributing to the non-free Debian distribution, 
and indirectly to Debian derivates such as Ubuntu and Trisquel, I 
decided to go with GNU Guix instead. How do I get started in packaging.


[1] http://ongakunix.isengaara.de/ongakunix/

Tobias Platen