Mono and .NET Core

[Brett Gilio]

Hi all,

Two questions here.

1) Has anybody already started taking to try and upgrade Mono to latest?
If not, I will give it a go.

2) Have we started any packaging on .NET Core, would like to know to
prevent redundancy in work.

Best,


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix | https://emacs.org

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey Danny,

> welcome back!

Thank you :)

> I agree.  I've been meaning to write parted bindings for guile, but
> I got side-tracked with https://github.com/daym/guile-gcc-unit which
> can extract prototypes out of gcc source files (in order to automate
> wrapper generation).  Now I'm motivated to pick it up again.

I was thinking of writing Guile FFI based bindings in the same spirit as
for Guile-git or Guile-newt. However, if we can write a nice higher
level abstraction above generated bindings, I guess it would be ok too.

Pyparted which was mainly written for Anaconda adopted the strategy of
exporting libparted functions in Python via 1:1 function mapping and
then writting a higher level abstraction built on that.

Anyway, your help would be much appreciated on this part that will be
the trickier :)

Thank you,

Mathieu

Re: Package for LXQt. Help wanted.

[Meiyo Peng]

Hello, Mr. Song.

Thank you for your reply.

> Some notes to you:
> - Wrap lines under 80 characters if possible.

My emacs automatically wrap lines at exactly 80 characters. Should I set
it to less than 80?

#+BEGIN_SRC emacs-lisp
  (setq-default fill-column 80)  ;; Change this to 70?
#+END_SRC

"宋文武" is a Chinese name. Are you a Chinese? I am a Chinese. My name
is 彭美玉 (Peng Mei Yu in Pinyin).

--
Meiyo Peng

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi Ludo!

> Woow, that’s an impressive comeback!  :-)

Thank you :)

> BTW, if your bicycle trip stops by Paris, do not miss
> : you’d have
> nice stories to tell us about.  :-)

Haha, it would have been with pleasure, but I'll still be in
Japan. However, I should be able to attend Fosdem this year!

Thanks,

Mathieu

Re: Come back and graphical installer

[bill-auger]

On Mon, 22 Oct 2018 22:47:29 -0400 bill-auger wrote:
> if non-technical people are ever going
> to try guixsd, then a fully graphical liveISO X desktop environment
> with a mouse-centric installer will be essential

i should qualify that statement as well to note that a graphical
package manager would be just as essential for non-technical users - if
there is not yet any graphical package manager, then there is little
need for a graphical installer either, as the distro is clearly
targeting only "power users" and very much excluding the largest
group of potential users which are not so comfortable on the command
line

Re: Come back and graphical installer

[bill-auger]

FWIW, i will add that the bulk of effort required to have a pretty
user-friendly mouse-centric installer for guixsd is not with the
installer itself, but in making a liveISO that boots a graphical
environment - i would not consider ncurses to be "graphical" and most
casual users would not either - if non-technical people are ever going
to try guixsd, then a fully graphical liveISO X desktop environment
with a mouse-centric installer will be essential

i have experience with the calamares installer which is
very much a ready-made, modular, distro-agnostic solution - all that
would be required for calamares is to write a new module that scripts a
standard command line install procedure and everything else (the GUI,
partitioning, a pretty slideshow) is included for free and maintained
upstream - about a year ago i discussed this with rekado and offered
that i would be willing to adapt it for guix but it was seen then
(as it apparently still is now) to be low-priority, so i left it at that

Re: Package for LXQt. Help wanted.

[Meiyo Peng]

Hello,

I checked kwindowsystem's package in debian. It seems the plugins
directory in kwindowsystem should be installed to
/run/current-system/profile/lib/qt5/plugins rather than
/run/current-system/profile/lib/plugins. Maybe this is a bug in the
kwindowsystem package.

File list of package libkf5windowsystem5 in stretch of architecture
amd64:

(link: https://packages.debian.org/stretch/amd64/libkf5windowsystem5/filelist)
#+BEGIN_EXAMPLE
  /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5
  /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5.28.0
  
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemWaylandPlugin.so
  
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so
  /usr/share/doc/libkf5windowsystem5/changelog.Debian.gz
  /usr/share/doc/libkf5windowsystem5/copyright
#+END_EXAMPLE

File list of kwindowsystem in guix:

#+BEGIN_EXAMPLE
  /gnu/store/snf6dh8fprihac2y0mwspgc5lchv12b6-kwindowsystem-5.49.0/lib
  ├── cmake
  │   └── KF5WindowSystem
  │   ├── KF5WindowSystemConfig.cmake
  │   ├── KF5WindowSystemConfigVersion.cmake
  │   ├── KF5WindowSystemTargets.cmake
  │   └── KF5WindowSystemTargets-relwithdebinfo.cmake
  ├── libKF5WindowSystem.so -> libKF5WindowSystem.so.5
  ├── libKF5WindowSystem.so.5 -> libKF5WindowSystem.so.5.49.0
  ├── libKF5WindowSystem.so.5.49.0
  ├── plugins
  │   └── kf5
  │   └── org.kde.kwindowsystem.platforms
  │   ├── KF5WindowSystemWaylandPlugin.so
  │   └── KF5WindowSystemX11Plugin.so
  └── qt5
  └── mkspecs
  └── modules
  └── qt_KWindowSystem.pri
#+END_EXAMPLE

--
Meiyo Peng

Re: Tensorflow package

[Ricardo Wurmus]

Gábor Boskovits  writes:

> Hello Ricardo,
>
> Ricardo Wurmus  ezt írta (időpont: 2018.
> okt. 22., H, 22:17):
>> I think that the patch I previously posted is not quite as useful as I
>> had originally hoped.  The new package uses the (now removed) CMake
>> build system and unfortunately must be built with all the bundled
>> libraries.
>
> When was cmake-build-system removed? I could not find any reference to
> that.

I didn’t express myself clearly, sorry.

What I meant is that *Tensorflow* no longer comes with the necessary
CMake files (since the latest release).

It used to come with a contributed Makefile and CMake files.  The
Makefile only allowed you to build the core library (as seen in my
previous patch), while the CMake stuff was more comprehensive.

In spite of this I’d like us to add the previous release of Tensorflow
using the cmake-build-system.  Tensorflow uses Bazel, but it is very
difficult to package all of Bazel’s *many* Java dependencies, so this
will probably take a very long time to do without cheating.

--
Ricardo

Re: Tensorflow package

[Gábor Boskovits]

Hello Ricardo,

Ricardo Wurmus  ezt írta (időpont: 2018.
okt. 22., H, 22:17):
> I think that the patch I previously posted is not quite as useful as I
> had originally hoped.  The new package uses the (now removed) CMake
> build system and unfortunately must be built with all the bundled
> libraries.

When was cmake-build-system removed? I could not find any reference to
that. From the manual
it seems it is still there, and also could find nothing in git log.
(Maybe I was not looking properly, though.)

> --
> Ricardo
>
g_bor

Re: Blog: Guix packaging tutorial

[Divan Santana]

Pierre Neidhardt  writes:

> Divan  writes:
>> Off topic, but how did you convert this? Guessing pandoc, but it seems
>> converted better then the standard, =pandoc index.org -t gfm -o
>> /tmp/index.md= would do.
>
> This is a very good question.  Indeed, Org support in Pandoc is sub-par, so I
> did not use that.  Instead, I've used Emacs directly and its
> ~(org-md-export-to-markdown)~ function.  But even then, the export result 
> lacked
> a few elements, such as fenced code language tag or the header.
> So I wrote a wrapper script to fix that automatically for me.
> It's not very generic but it's a starting point.
>
> Here is the implementation:
>
>   
> https://gitlab.com/ambrevar/ambrevar.gitlab.io/tree/master/source/guix-packaging

This is really great and handy. I'll certainly be using this.

Would be great to package something like in emacs community. A blog
about converting back and forth between org and markdown would be
welcome to many in the Emacs community. :)

I'm slow to get around to completing your guix packaging tutorial. As a
complete noob I'm very interested in this and keen to submit a few basic
packages there after.

Re: Tensorflow package

[Ricardo Wurmus]

Hi Adam,

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Ricardo eventually submitted a preliminary TensorFlow package:
>>
>>   https://issues.guix.info/issue/31386
>>
>> It’s not directly usable at this stage but I’m sure Ricardo would
>> welcome testing and help.  As a first step, I suppose you could apply
>> the patch from the issue above, build it, and see what’s missing before
>> you can use it.
>>
>> HTH!
>>
>> Ludo’.
>
> Thanks for the help; I missed that patch. I'll let you know
> if I'm able to dive in and make some progress, but my lack
> of experience with java might be a problem :). Thanks to
> Ricardo for all the progress on this!

Thanks for your interest!  I have a better patch for a larger part of
Tensorflow coming up, but it’s not quite ready and I haven’t been able
to finish it yet.

I think that the patch I previously posted is not quite as useful as I
had originally hoped.  The new package uses the (now removed) CMake
build system and unfortunately must be built with all the bundled
libraries.

I’ll be away to attend a conference for the rest of this week, but I
suppose I could rebase the patch some time next week and send the work
in progress as a follow-up to https://issues.guix.info/issue/31386.

--
Ricardo

Re: Tensorflow package

[Adam Massmann]

l...@gnu.org (Ludovic Courtès) writes:

> Ricardo eventually submitted a preliminary TensorFlow package:
>
>   https://issues.guix.info/issue/31386
>
> It’s not directly usable at this stage but I’m sure Ricardo would
> welcome testing and help.  As a first step, I suppose you could apply
> the patch from the issue above, build it, and see what’s missing before
> you can use it.
>
> HTH!
>
> Ludo’.

Thanks for the help; I missed that patch. I'll let you know
if I'm able to dive in and make some progress, but my lack
of experience with java might be a problem :). Thanks to
Ricardo for all the progress on this!

GuixSD on AArch64

[Vagrant Cascadian]

On 2018-10-22, Ludovic Courtès wrote:
> On IRC earlier today Vagrant mentioned that the Pinebook AArch64 laptop
> (see ) should be able to run
> GuixSD when Linux-libre 4.19 and U-Boot 2018.11 are out, with 100% free
> software.  That may give another incentive to work on AArch64.

Looking like u-boot 2019.01 might be more likely, but modest patches
work with 2018.11-rc2. I'll probably bring the pinebook with me to the
Paris meetup in December... though with only 2GB of ram it might not
make the most exciting GuixSD system... :)

Very similar is the free open-source hardware Teres-I from olimex:

  https://www.olimex.com/Products/DIY-Laptop/

... Which is just a kit with all the parts you assemble yourself!


live well,
  vagrant

Re: In reference to outreachy Intership

[Gábor Boskovits]

Hello Swati,

Could you give us a status update?

Best regards,
g_bor

Re: Outreachy applicant

[Gábor Boskovits]

Hello Cecilia,

Could you give us a status update?

Best regards,
g_bor

Re: Trying to crosscompile for POWER9

[Leo Famulari]

On Sun, Oct 21, 2018 at 08:30:03AM +0200, Tobias Platen wrote:
> On 10/20/2018 09:09 PM, Tobias Platen wrote:
> Here are the build logs from guix. I have tried building the toolchain
> twice, but in both cases glibc failed to build.

[...]

> running configure fragment for sysdeps/powerpc/powerpc64/le
> 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.

Searching around, I found other distros hit the same problem for their
POWER ports, and needed to explicitly configure GCC >= 6.2 to build with
128-bit floating point types. Specifically, with the option
'--with-long-double-128':

https://github.com/advancetoolchain/advance-toolchain/commit/e22696eecb39c6b401df14001f01608807e4d934
http://lists.busybox.net/pipermail/buildroot/2017-August/200952.html

I hope that helps!


signature.asc
Description: PGP signature

Re: Come back and graphical installer

[Danny Milosavljevic]

Hi Mathieu,

welcome back!

> I picked up the "Graphical installer" task. After studying the branch
> wip-installer-2, I choose to rewrite it for multiple reasons:
> 
> * I found the guile-ncurses approach too low level and think that many
>   bugs in the current installer could be avoided with a higher level
>   library.

Yeah, it's also why I didn't really continue it except for finishing
what's already there.  It's just to low-level.

I mean it can be done the low-level way, but widget libraries are a solved
problem and the "redraw it only now" stuff is seriously 1980s.

> * As suggested by Ludo[1], using a network manager seems to be a better
>   idea that calling iw, ip and other low level tools.

I agree.  Note that back then network-manager was not used in guix.

> * I prefer relying on a Guile-parted library rather than calling cfdisk
>   and again interfacing with various partioning tools.

I agree.  I've been meaning to write parted bindings for guile, but
I got side-tracked with https://github.com/daym/guile-gcc-unit which
can extract prototypes out of gcc source files (in order to automate
wrapper generation).  Now I'm motivated to pick it up again.

Maybe I should just have written the bindings manually - I would have
been done a long time ago ;-)

> Based on this, I have a first draft for a new installer here[4]. I plan
> to push it on a wip savannah branch soon. Most of the basic features are
> implemented and the last missing part it the partioning one (also the
> bigger ...).

Cool!


pgpS9Lv6923AM.pgp
Description: OpenPGP digital signature

Re: Package for LXQt. Help wanted.

[宋文武]

Meiyo Peng  writes:

> Hello everyone,
>
> I made a series of packages for LXQt. The code is at:
> https://github.com/meiyopeng/guix/tree/lxqt

Hello, it looks great!

>
> I did this beacuse I want to run i3 window manager within lxqt
> session. Currently most things work great except lxqt-panel. I have two
> problems.
>
> 1. The $QT_PLUGIN_PATH environment variable points to
> /run/current-system/profile/lib/qt5/plugins. I don't know where it's
> set.

The QT_PLUGIN_PATH can be set by the 'native-search-paths' of qtbase, I
guess you have qtbase in your system profile.  If you install qtbase
into the user profile, the variable would contains
'~/.guix-profile/lib/qt5/plugins'.

> So qtsvg has to be installed into syetem profile, or all the lxqt
> applications can not properly display icons.

Yeah, instead the system profile you can also install qtsvg, etc. into
the user profile.

> Should I add qtsvg to lxqt applications' propagated-inputs? If so,
> should I add qtbase too, since qtbase also provides lib/qt5/plugins,
> although lxqt works without qtbase in system profile but I can never
> be sure.

Yes, we can make them 'propagated-inputs' so that the variables can be
set by the profile (via native-search-paths), or we can wrap the
binaries with all the environment variables (eg: krita).


>
> 2. lxqt-panel complains about "Warning: Could not find any platform
> plugin". (lxqt-runner also prints this message but it works.) I found
> out this message was printed by kwindowsystem.
>
> The related code in kwindowsystem:
> https://github.com/KDE/kwindowsystem/blob/9f88c9a5d25ff7909c25ce399572ca348b5706b1/src/pluginwrapper.cpp#L79
>
> Qt's document (https://doc.qt.io/qt-5/qcoreapplication.html#libraryPaths)
> says "entries of the QT_PLUGIN_PATH environment variable are always
> added to libraryPaths". So I install kwindowsystem into system profile,
> and add /run/current-system/profile/lib/plugins to QT_PLUGIN_PATH. Then
> this error message disappear. But lxqt-panel still does not work.

Okay, we can look into it later...

>
> I still have no idea how to fix lxqt-panel. This does not affect me
> because I use i3, so lxqt-panel is useless to me. But there may be other
> people interested in LXQt and I want to help them get this fixed. Can
> anybody help me?
>
> Will anybody help me review the code? I'd appreciate it.

Generally it look good to me, and I had cherry-pick 2 commits, and push
them (hope it doesn't break existing other lxqt things...), and will
look into others in next days.

Some notes to you:
- Wrap lines under 80 characters if possible.
- Keep comments for '#:tests #f', etc.

Thank you!

Re: Come back and graphical installer

[Danny Milosavljevic]

Hi,

On Sat, 20 Oct 2018 21:48:34 +0600
Mathieu Othacehe  wrote:

> * Using Anaconda[1] as suggested by Harmut would mean interfacing a huge
>   codebase in Python, written for FHS based distributions.

I just want to throw this over the fence... *runs away*:

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Danny Milosavljevic 
;;;
;;; 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 (wip anaconda)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix utils)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system python)
  #:use-module (gnu packages)
  #:use-module (gnu packages admin)
  #:use-module (gnu packages autotools)
  #:use-module (gnu packages backup)
  #:use-module (gnu packages base)
  #:use-module (gnu packages check)
  #:use-module (gnu packages curl)
  #:use-module (gnu packages databases)
  #:use-module (gnu packages disk)
  #:use-module (gnu packages flex)
  #:use-module (gnu packages gettext)
  #:use-module (gnu packages glib)
  #:use-module (gnu packages gnome)
  #:use-module (gnu packages gnuzilla)
  #:use-module (gnu packages gtk)
  #:use-module (gnu packages linux)
  #:use-module (gnu packages nettle)
  #:use-module (gnu packages networking)
  #:use-module (gnu packages time)
  #:use-module (gnu packages package-management)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages popt)
  #:use-module (gnu packages python)
  #:use-module (gnu packages python-web)
  #:use-module (gnu packages selinux)
  #:use-module (gnu packages textutils)
  #:use-module (gnu packages tls)
  #:use-module (gnu packages xml)
  #:use-module (gnu packages xorg))

(define-public python-blivet
  (package
(name "python-blivet")
(version "0.61.15")
(source (origin
  (method url-fetch)
  (uri
   (string-append
"https://github.com/storaged-project/blivet/archive/blivet-;
version ".tar.gz"))
  (sha256
   (base32
"0j01wjb2drz1r9f4006xn0g9r7hiqm679diczi4z7hsh850v85f7"
(build-system python-build-system)
(home-page "https://fedoraproject.org/wiki/Blivet;)
(synopsis "Installer")
(description "Installer.")
(license license:gpl2))) ; FIXME

(define-public python2-blivet
  (package-with-python2 python-blivet))

(define-public python-ordered-set
(package
  (name "python-ordered-set")
  (version "2.0.2")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "ordered-set" version))
  (sha256
(base32
  "1swh7b75qz9d2179z36ll4n41vf2b8wgngg9rgan01svgmfssb4l"
  (build-system python-build-system)
  (native-inputs
   `(("python-nose" ,python-nose)))
  (home-page "http://github.com/LuminosoInsight/ordered-set;)
  (synopsis "MutableSet that remembers its order in Python")
  (description
"A MutableSet that remembers its order, so that every entry has an index.")
  (license #f)))

(define-public python2-ordered-set
  (package-with-python2 python-ordered-set))

(define-public python-pykickstart
(package
  (name "python-pykickstart")
  (version "3.7")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "pykickstart" version))
  (sha256
(base32
  "09fp4n8sz8xvcljhhs09w9m1gca0bbcxbcmyd0bdc9xxp0sy4576"
  (build-system python-build-system)
  (propagated-inputs
   `(("python-ordered-set" ,python-ordered-set)))
  (home-page
"http://fedoraproject.org/wiki/pykickstart;)
  (synopsis
"Python module for manipulating kickstart files")
  (description
"Python module for manipulating kickstart files")
  (license #f))) ; FIXME

(define-public python2-pykickstart
  (package-with-python2 python-pykickstart))

(define-public python-langtable
  (package
(name "python-langtable")
(version "0.0.38")
(source (origin
  (method url-fetch)
  (uri
   (string-append 
"https://github.com/mike-fabian/langtable/archive/; version ".tar.gz"))
  (sha256
   (base32
"00634x2hjrvf45a3wsjb38cni7rc2bdb39a86rvzyz8syv9igxy1"
(build-system python-build-system)
(home-page "https://fedoraproject.org/wiki/Anaconda;)
(synopsis "Langtable")

Re: Come back and graphical installer

[Ludovic Courtès]

Hello!

Mathieu Othacehe  skribis:

> To give you my opinion, I think that having a X/Wayland installer would
> be really nice and totally agree. However, I also think it is important
> to capitalize on the work already done. Plus, writting this kind of
> installer is quite complicated because:
>
> * Using Anaconda[1] as suggested by Harmut would mean interfacing a huge
>   codebase in Python, written for FHS based distributions.
> * To write this kind of installer in Guile, we need bindings for a nice
>   high level graphical library and we have to be careful not to increase
>   too much the installer footprint.
>
> So this seems that something we want in the future but that is a bit out
> of reach for the 1.0 release.

Seconded.  To me the graphical installer is in the nice-to-have
category and not in the 1.0-blocker category.

Ludo’.

Re: Come back and graphical installer

[Ludovic Courtès]

Hello Mathieu!

Mathieu Othacehe  skribis:

> First mail since a while ! I'm currently finishing a long bicycle trip,
> and was able to start hacking again.

Welcome back, I hope you had a good time!

> I picked up the "Graphical installer" task. After studying the branch
> wip-installer-2, I choose to rewrite it for multiple reasons:
>
> * I found the guile-ncurses approach too low level and think that many
>   bugs in the current installer could be avoided with a higher level
>   library.
> * As suggested by Ludo[1], using a network manager seems to be a better
>   idea that calling iw, ip and other low level tools.
> * I prefer relying on a Guile-parted library rather than calling cfdisk
>   and again interfacing with various partioning tools.
>
> While a lot of work have been accomplished by John and Danny, fixing the
> above issues mean rewrite it almost completely anyway.
>
> So, I wrote Guile bindings for newt[2], which can be found here[3]. Newt
> is the library used by Debian installer and the Anaconda installer
> (RedHat, Centos, ...).
>
> I choose to interface with Connman via connmanctl. It would have been
> better to use DBus but it implies writing Guile-dbus and I did not have
> the courage.
>
> Based on this, I have a first draft for a new installer here[4]. I plan
> to push it on a wip savannah branch soon. Most of the basic features are
> implemented and the last missing part it the partioning one (also the
> bigger ...).

Woow, that’s an impressive comeback!  :-)

The installer you wrote does seem to be much more compact that the one
John and Danny wrote, which seems to confirm your argument in favor of
Newt rather than Ncurses.

I really like the clean interfaces you can came up with for networking,
keymaps, timezones, etc.

For Connman, I wonder if we could talk directly to the daemon without
going through ‘connmanctl’ (which could perhaps provide tighter control
over error reports, etc.), but that’s a minor issue.

> I will soon share some iso files to have some feedbacks. Even if it
> might be too late already, I think that releasing the 1.0 with a
> graphical installer would be a big plus.

Definitely.  I’m really happy that you took a stab at this and I’m
looking forward to running test images!

BTW, if your bicycle trip stops by Paris, do not miss
: you’d have
nice stories to tell us about.  :-)

Cheers,
Ludo’.

Re: GuixSD on the SoftIron OverDrive 1000 (AArch64)

[Ludovic Courtès]

Hello!

Efraim Flashner  skribis:

> On Sat, Oct 20, 2018 at 03:20:44PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> The device comes with openSuSE preinstalled and I had first installed
>> Guix from the binary tarball.  It’s a “normal” UEFI machine so we can
>> use ‘grub-efi’ directly.  I came up with this GuixSD config:
>> 
>>   
>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/overdrive.scm
>> 
>
> Can I draw your attention to commits
> 64791eb7e1dceb0940cc881e84820f0170298b34 and
> 39d7fdce453b0ca23ecbed72048647debbaa58a6 ? :)

Oh, who did that?!  :-)

> How did you figure out which modules you needed for the device?

I could pretend I was smart, but it turns out it was a lot of
trial-and-error, looking at /proc/config.gz on the openSuSE kernel,
diffing configs, lsmod, and all that.

> Also, I'd suggest this diff:

I’m all for it, please push!

If you’d like to GuixSDify the OverDrive that you host, please let me
know if everything works according to plan!

Ludo’.

Re: GuixSD on the SoftIron OverDrive 1000 (AArch64)

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

> Ludovic Courtès writes:

[...]

>> On the first boot, the GuixSD activation snippets fail while trying to
>> install /etc, /etc/pam.d, and /etc/skel, and /etc/ssl because these
>> directories already exist (from openSuSE) whereas GuixSD assumes that
>> they don’t.  The solution is just to remove/rename them from the Guile
>> initrd REPL.  Once this is done, booting proceeds flawlessly and
>> happiness ensues.
>
> We could do with a more powerful REPL ;-)

Using “,bournish” helps a bit, but it’s true that fiddling with this
from the Guile prompt is a bit, ahem, unusual.  :-)

>> ¹ https://gnu.org/software/guix/blog/2018/aarch64-build-machines-donated/
>
> So...is there an opportunity for someone to start looking at a Reduced
> Binary Seed boostrap for AArch64?

I think it’s a worthy goal!

On IRC earlier today Vagrant mentioned that the Pinebook AArch64 laptop
(see ) should be able to run
GuixSD when Linux-libre 4.19 and U-Boot 2018.11 are out, with 100% free
software.  That may give another incentive to work on AArch64.

Ludo’.

Re: New Guix reference card

[Ludovic Courtès]

Hello!

Leo Famulari  skribis:

> On Sat, Oct 20, 2018 at 01:05:18PM -0700, Chris Marusich wrote:
>> I see that the second page is mostly blank.  Is that intended?
>
> I think it's meant to be the back of a printed card.

Exactly!  If you don’t have a double-sided printer, you can obviously
skip the second page.

Or, if you do have a double-sided printer but still find the second page
to be too empty, you could add stuff about ‘guix system’ there.  Hint,
hint!  ;-)

Chris, note that you may want to modify ‘refcard-style.lout’ to use
Letter rather than A4, but then the layout may need to be tweaked.
(Alternately find yourself a bunch of A4 sheets.  ;-))

Gábor Boskovits  skribis:

> Leo Famulari  ezt írta (időpont: 2018. okt. 22., H, 4:56):
>>
>> I think it's meant to be the back of a printed card. It would be great
>> to have a stack of these for FOSDEM :)
>
> How big stack are you thinking about? Maybe I can help there :)

I suppose that’ll depend on whether we get a booth!  But anyway, we
could bring some in the pre-FOSDEM Guix workshop as well as in the
devrooms where we present Guix.

Thanks,
Ludo’.

Re: Tensorflow package

[Ludovic Courtès]

Hello Adam,

Adam Massmann  skribis:

> I was wondering if anyone is currently working on packaging
> Tensorflow, and if so what the progress is looking like. It
> looked like back in April Ricardo was least looking at
> it[1].
>
> I just found out I need to use it for a collaboration, and
> if I can move some other work around I /might/ be able to
> help with the package, depending on how technical the
> roadblocks are. Just want to make sure I'm not repeating any
> work.

Ricardo eventually submitted a preliminary TensorFlow package:

  https://issues.guix.info/issue/31386

It’s not directly usable at this stage but I’m sure Ricardo would
welcome testing and help.  As a first step, I suppose you could apply
the patch from the issue above, build it, and see what’s missing before
you can use it.

HTH!

Ludo’.

Re: Channel dependencies

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

>> I’d recommend ‘match’ for the outer sexp, and then something like the
>> ‘alist-let*’ macro from (gnu services herd) in places where you’d like
>> to leave field ordering unspecified.
>
> I keep forgetting about alist-let* (from srfi-2, not herd), even though
> it’s so useful!  “channel-instance-dependencies” now uses the
>  record via “read-channel-metadata” and uses match.

Heck I didn’t even know about SRFI-2.  :-)

>> Then I think it would make sense to add the ‘dependencies’ field to
>>  directly (and keep  internal.)
>> Each element of the ‘dependencies’ field would be another
>> .
>>
>> Actually ‘dependencies’ could be a promise that reads channel meta-data
>> and looks up the channel instances for the given dependencies.
>> Something like that.
>
> This sounds good, but I don’t know how to make it work well, because
> there’s a circular relationship here if we want to keep the abstractions
> pretty.  I can’t simply define the “dependencies” field of
>  to have a default thunked procedure like this:
>
>(match (read-channel-metadata checkout)
>  (#f '())
>  (($  _ dependencies)
>   dependencies))
>
> Because record fields cannot access other record fields such as
> “checkout”.  This makes the code look rather silly as we’re creating an
> instance with an explicit dependencies value only to read it from that
> same record in the next expression.
>
> In light of these complications I’d prefer to have a procedure
> “channel-instance-dependencies” that handles this for us, and do without
> a “dependencies” field on the  record.
>
> What do you think?

Sure, that makes sense to me (sometimes I throw ideas that look great on
paper but simply don’t fly in practice!).

> From e23225640e723988de215d110e377c93c8108245 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sat, 13 Oct 2018 08:39:23 +0200
> Subject: [PATCH] guix: Add support for channel dependencies.
>
> * guix/channels.scm (): New record.
> (read-channel-metadata, channel-instance-dependencies): New procedures.
> (latest-channel-instances): Include channel dependencies; add optional
> argument PREVIOUS-CHANNELS.
> (channel-instance-derivations): Build derivation for additional channels and
> add it as dependency to the channel instance derivation.
> * doc/guix.texi (Channels): Add subsection "Declaring Channel Dependencies".

[...]

> +  ;; Accumulate a list of instances.  A list of processed channels is also
> +  ;; accumulated to decide on duplicate channel specifications.
> +  (match (fold (lambda (channel acc)
> + (match acc
> +   ((#:channels previous-channels #:instances instances)
> +(if (ignore? channel previous-channels)
> +acc
> +(begin
> +  (format (current-error-port)
> +  (G_ "Updating channel '~a' from Git 
> repository at '~a'...~%")
> +  (channel-name channel)
> +  (channel-url channel))
> +  (let-values (((checkout commit)
> +(latest-repository-commit store 
> (channel-url channel)
> +  #:ref 
> (channel-reference
> + 
> channel
> +(let ((instance (channel-instance channel commit 
> checkout)))
> +  (let-values (((new-instances new-channels)
> +(latest-channel-instances
> + store
> + (channel-instance-dependencies 
> instance)
> + previous-channels)))
> +`(#:channels
> +  ,(append (cons channel new-channels)
> +   previous-channels)
> +  #:instances
> +  ,(append (cons instance new-instances)
> +   instances))
> +   `(#:channels ,previous-channels #:instances ())
> +   channels)

This seems to be assuming that CHANNELS is topologically-sorted, is that
right?

Otherwise LGTM.

There’s the conflict error reporting mentioned in another message that I
think we could implement, but that can come later.

Also we should consider adding unit tests for at least some of this; I
plaid guilty for not having provided a test strategy from the start.

Thank you, and apologies for not replying on time for your presentation!

Ludo’.

Re: Channel dependencies

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> Ricardo Wurmus  writes:
>
>> [...]
>>
>>> Chris raises interesting issues.  I think it’s OK to first come up with
>>> an implementation that has some limitations but works with the simple
>>> use cases we have in mind.
>>
>> I’ve fixed this according to what we’ve discussed: when more than one of
>> the user-provided or channel-required channels have the same name we
>> ignore the more recent specification unless it is more specific
>> (i.e. the new channel specification mentions a commit while the former
>> did not).
>
> As long as the "channel resolution mechanism" is deterministic, it's
> probably OK.  But if you have two channels A which depends on C, and B
> which depends on C', where C' is a different version of C, then we can
> arrive in a situation where the author of A tests and provides support
> for their package definitions in the absence of channel B, and the
> author of B tests and provides support for their package definitions in
> the absence of channel A, and a user who wants to use packages from both
> A and B is stuck because one of the channel owners (the one whose
> dependency we didn't pick) doesn't want to support that use case.

Good point.  I agree that it’s similar to the question of propagated
inputs, which we deal with by reporting an error when a collision
arises.

So, similarly, I think the safe way would be to report an error when
channel requirements conflict.

We must define what it means for two s to conflict:

  • if a channel’s ‘commit’ is #f, then any channel with the same name
but a different ‘uri’ and/or a different ‘branch’ and/or a non-#f
commit conflicts;

  • if a channel’s ‘commit’ is not #f, then any channel with the same
name and otherwise different fields conflicts.

WDYT?

If we have inspiration later, we can liberalize this, for instance by
using several inferiors.  It would be quite a bit of extra work, and
it’s not immediately clear to me how that could work.  I believe what
Ricardo proposes already covers many use cases anyway.

Thanks,
Ludo’.

Re: New Guix reference card

[Gábor Boskovits]

Hello Leo,

Leo Famulari  ezt írta (időpont: 2018. okt. 22., H, 4:56):
>
> I think it's meant to be the back of a printed card. It would be great
> to have a stack of these for FOSDEM :)

How big stack are you thinking about? Maybe I can help there :)
g_bor