Generating wrappers for execution in non-root non-Guix contexts

[Ludovic Courtès]

Hello Guix!

The hack below allows ‘guix pack’ to produce wrappers that allow,
through user namespaces, programs to automatically relocate themselves
when you run them unprivileged on a machine that lacks Guix.  In the
example below, I run ‘sed’ from a pack on a machine that lacks Guix:

--8<---cut here---start->8---
ludo@fencepost:~/tmp$ tar xf ../pack.tgz
ludo@fencepost:~/tmp$ echo hello > foo
ludo@fencepost:~/tmp$ 
gnu/store/ffdzkyi23n8xh3n6vfqpa1lzg3xx9jpj-sed-4.4/bin/sed -i foo 
-es/hello/bye/g
ludo@fencepost:~/tmp$ cat foo
bye
ludo@fencepost:~/tmp$ ls /gnu/store
ls: cannot access '/gnu/store': No such file or directory
--8<---cut here---end--->8---

Pretty cool no?

What I imagine is that we could make this an option of ‘guix pack’, such
that ‘guix pack -w’ would produce such binaries.

This relies on the same approach as ‘call-with-container’… except it’s
written in C and statically-linked to avoid bootstrapping issues.  Doing
that in Scheme would be a bit involved because a shebang like
#!/gnu/store/…-guile/bin/guile wouldn’t work; the wrappers have to be
statically-linked executables.

There are (minor) issues to be solved: symlinks created by ‘guix pack
-S’ should be relative instead of absolute, and same for symlinks in the
profile.  This would allow users to directly type ./bin/sed instead of
having to find out which directory is the right one as in the example
above.

We could also have wrappers fall back to PRoot when unshare(2) fails.

What do people think?

Cheers,
Ludo’.

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index fe9fbebcc..1026ee892 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -1026,7 +1026,10 @@ COREUTILS-FINAL vs. COREUTILS, etc."
 
  (union-build (assoc-ref %outputs "debug")
   (list (assoc-ref %build-inputs
-   "libc-debug")))
+   "libc-debug")))
+ (union-build (assoc-ref %outputs "static")
+  (list (assoc-ref %build-inputs
+   "libc-static")))
 
 (native-search-paths (package-native-search-paths gcc))
 (search-paths (package-search-paths gcc))
@@ -1038,7 +1041,7 @@ COREUTILS-FINAL vs. COREUTILS, etc."
 be installed in user profiles.  This includes GCC, as well as libc (headers
 and binaries, plus debugging symbols in the 'debug' output), and Binutils.")
 (home-page "https://gcc.gnu.org/";)
-(outputs '("out" "debug"))
+(outputs '("out" "debug" "static"))
 
 ;; The main raison d'être of this "meta-package" is (1) to conveniently
 ;; install everything that we need, and (2) to make sure ld-wrapper comes
@@ -1047,7 +1050,8 @@ and binaries, plus debugging symbols in the 'debug' output), and Binutils.")
   ("ld-wrapper" ,(car (assoc-ref %final-inputs "ld-wrapper")))
   ("binutils" ,binutils-final)
   ("libc" ,glibc-final)
-  ("libc-debug" ,glibc-final "debug")
+  ("libc-debug" ,glibc-final "debug")
+  ("libc-static" ,glibc-final "static")
 
 (define-public gcc-toolchain-4.8
   (make-gcc-toolchain gcc-4.8))
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 95dc9746b..507a441f5 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -318,7 +318,7 @@ denoting a specific output of a package."
  (propagated-inputs #$(map entry->gexp deps))
  (search-paths #$(map search-path-specification->sexp
   search-paths
-  (($  name version output (? package? package)
+  (($  name version output package
(deps ...) (search-paths ...))
#~(#$name #$version #$output
  (ungexp package (or output "out"))
@@ -671,7 +671,9 @@ if not found."
 (return (find-among-inputs inputs)
 ((? string? item)
  (mlet %store-monad ((refs (references* item)))
-   (return (find-among-store-items refs)))
+   (return (find-among-store-items refs
+(item
+ (return #f)
 
   (anym %store-monad
 entry-lookup-package (manifest-entries manifest)))
diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm
index 488638adc..f2c3d4729 100644
--- a/guix/scripts/pack.scm
+++ b/guix/scripts/pack.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2015, 2017 Ludovic Courtès 
+;;; Copyright © 2015, 2017, 2018 Ludovic Courtès 
 ;;; Copyright © 2017 Efraim Flashner 
 ;;; Copyright © 2017 Ricardo Wurmus 
 ;;; Copyright © 2018 Konrad Hinsen 
@@ -216,11 +216,13 @@ the image."
   (('gnu rest ...) #t)
   (rest #f)))
 
+  (define defmod 'define-module)  ;trick Geiser
+

Re: Generating wrappers for execution in non-root non-Guix contexts

[Pierre Neidhardt]

Brilliant!

Would this only work for C-based programs?
What about other languages, shared libaries, external resources, etc.?

-- 
Pierre Neidhardt

The only "ism" Hollywood believes in is plagiarism.
-- Dorothy Parker


signature.asc
Description: PGP signature

Use .authinfo for git credentials

[Pierre Neidhardt]

I would like `git send-email` to use the credentials from ~/.authinfo.gpg
to send patches to the Guix mailing list.

While not related to Guix code per se, I'm posting this here because I
primarily use `git send-email` for Guix and I suppose people around here
must have an answer to that question.

Or else how do you people configure `git send-email' to not prompt for a
password?

All I've found so far is this:


https://github.com/git/git/blob/master/contrib/credential/netrc/git-credential-netrc

--
Pierre Neidhardt

He laughs at every joke three times... once when it's told, once when
it's explained, and once when he understands it.


signature.asc
Description: PGP signature

Re: Use .authinfo for git credentials

[Marius Bakke]

Pierre Neidhardt  writes:

> Or else how do you people configure `git send-email' to not prompt for a
> password?

I use 'msmtp' as the transport and have configured it to look up
passwords from 'password-store'.

$ git config --get-regexp sendemail.*
sendemail.smtpserver /home/marius/.guix-profile/bin/msmtp
sendemail.envelopesender auto

My ~/.msmtprc contains a line such as
'passwordeval "pass Email/fm/mbakke/out 2>/dev/null"'.  Obviously you
can use any other shell command here.

Hope this helps!


signature.asc
Description: PGP signature

Re: Use .authinfo for git credentials

[Pierre Neidhardt]

Marius Bakke  writes:

> I use 'msmtp' as the transport and have configured it to look up
> passwords from 'password-store'.
>
> $ git config --get-regexp sendemail.*
> sendemail.smtpserver /home/marius/.guix-profile/bin/msmtp
> sendemail.envelopesender auto

From the (1)git-send-email man page:

--8<---cut here---start->8---
   --smtp-server=
   If set, specifies the outgoing SMTP server to use (e.g.
   smtp.example.com or a raw IP address). Alternatively it can specify
   a full pathname of a sendmail-like program instead; the program
   must support the -i option. Default value can be specified by the
   sendemail.smtpServer configuration option; the built-in default is
   to search for sendmail in /usr/sbin, /usr/lib and $PATH if such
   program is available, falling back to localhost otherwise.
--8<---cut here---end--->8---

The smtp program must support the -i option.

I use Emacs' message-send to send e-mails.
I don't think Emacs accepts the -i option.

I could write a wrapper, but I don't think this is the most ideal
option.

-- 
Pierre Neidhardt

"Success covers a multitude of blunders."
-- George Bernard Shaw


signature.asc
Description: PGP signature

Re: Use .authinfo for git credentials

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> I use 'msmtp' as the transport and have configured it to look up
>> passwords from 'password-store'.
>>
>> $ git config --get-regexp sendemail.*
>> sendemail.smtpserver /home/marius/.guix-profile/bin/msmtp
>> sendemail.envelopesender auto
>
> From the (1)git-send-email man page:
>
> --8<---cut here---start->8---
>--smtp-server=
>If set, specifies the outgoing SMTP server to use (e.g.
>smtp.example.com or a raw IP address). Alternatively it can specify
>a full pathname of a sendmail-like program instead; the program
>must support the -i option. Default value can be specified by the
>sendemail.smtpServer configuration option; the built-in default is
>to search for sendmail in /usr/sbin, /usr/lib and $PATH if such
>program is available, falling back to localhost otherwise.
> --8<---cut here---end--->8---
>
> The smtp program must support the -i option.
>
> I use Emacs' message-send to send e-mails.
> I don't think Emacs accepts the -i option.
>
> I could write a wrapper, but I don't think this is the most ideal
> option.

I see.  FWIW my emacs uses 'msmtp' too, with this snippet:

(setq mail-specify-envelope-from t
  message-sendmail-envelope-from 'header
  mail-envelope-from 'header
  sendmail-program "/home/marius/.guix-profile/bin/msmtp"
  mail-host-address "fastmail.com"
  send-mail-function 'message-send-mail-with-sendmail
  message-send-mail-function 'message-send-mail-with-sendmail
  message-directory "~/Mail/drafts"
  message-kill-buffer-on-exit t)


signature.asc
Description: PGP signature

Re: Successfully running GNOME on core-updates + staging

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Hi Mark,
>>
>> Mark H Weaver  skribis:
>>
>>> I've successfully updated my x86_64 GuixSD system to my private branch
>>> based on 'core-updates' with recent 'master' and 'staging' merged into
>>> it.  This system includes a full GNOME desktop environment plus a few
>>> programs based on Qt.  It all works quite well.
>>>
>>> My branch includes a few draft fixes and workarounds that I haven't yet
>>> pushed, but nothing that would require many rebuilds to update later.
>>>
>>> So, I think it might be time to ask Hydra to build all of core-updates,
>>> after staging is merged into it.
>>
>> I agree.  There was an issue with cross-compiling ‘bootstrap-tarballs’
>> that Marius reported a few days ago, which I’m looking into right now.
>> I don’t expect the fix(es) to trigger a full rebuild.
>>
>> If Marius and others don’t object, I’d say go for it!
>
> No objections from me.  However I do have a bunch of fairly innocent
> updates in my queue, such as SQLite, Glib and CMake.  It's also tempting
> to get rid of that Perl graft.  Is it too late for such changes?

I think it’s OK for sqlite/glib/cmake, but changing Perl would further
delay things, which perhaps is not desirable.

> Hydra will be busy for a couple of days with 'master' and 'staging', so
> there's little use in starting it immediately.

It took me a couple of days to reply :-), so maybe we can start the
evaluation now?

We can also get berlin to build all of ‘core-updates’ if we want.

Thanks,
Ludo’.

Re: Update the Guix package/version

[Ludovic Courtès]

Roel Janssen  skribis:

> Ludovic Courtès  writes:
>
>> Hello,
>>
>> Roel Janssen  skribis:
>>
>>> What's the decision process for updating the ‘guix’ package revision,
>>> like in commit b1fb247b?
>>
>> There’s no real process, just do it when there’s a good reason to do it.
>>
>>> The reason I ask this is because I'd like to bump the revision so that
>>> the changes from 5cefb13d to ‘guix-daemon’ are available when I install
>>> ‘guix’ in a profile.
>>
>> Makes sense!
>>
>> Note that you can run “make update-guix-package” to do the work.  Be
>> sure to do that from a commit that is available on Savannah.  And of
>> course, make sure the package builds locally.  :-)
>
> Cool! I didn't know about this build step.  May I commit the change, so
> that I won't end up with an ambiguous revision number later on?

Sure if you have an update based on an upstream commit that builds,
you’re welcome to push it.

Perhaps you can also run “guix build -S guix --check” to be 100% sure
that the commit and hash are correct.

Thanks,
Ludo’.

Re: Introducing myself as an Outreachy Intern

[Catonano]

2018-04-25 8:27 GMT+02:00 Sahitihi :

> Hi all,
>
> I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
> pursuing my under graduation final semester in Computer Science. I will
> be
>
Hi Sahithi

Welcome !


> 1. Adding package definitions like r-dyn, r-catdap, r-abc to CRAN Packages
> .
>
> 2. Printed colored strings on terminal using Scheme code
>
> 3. Looked at scheme code to find out build output is printed.
>

Great !

What will you be working on during your internship ?

Maybe making the output of the build command more human ?

Best whishes !
Catonano

Re: Cleaning up the /bin for guix.

[Ludovic Courtès]

Roel Janssen  skribis:

> From 9455c7b94e0010ff4038132affc7a5c796313894 Mon Sep 17 00:00:00 2001
> From: Roel Janssen 
> Date: Tue, 24 Apr 2018 12:48:32 +0200
> Subject: [PATCH] gnu: guile-ssh: Move files from bin to examples directory.
>
> * gnu/packages/ssh.scm (guile-ssh): Move files from bin to the examples
>   directory.

[...]

> +(invoke "mv" (string-append bin "/ssshd.scm") 
> examples)
> +(invoke "mv" (string-append bin "/sssh.scm") 
> examples)

Please use ‘rename-file’ instead of invoking “mv”.  :-)

Otherwise LGTM!

Bonus points if you report the issue to Artyom upstream!

Thanks,
Ludo’.

Re: Blog team

[Ludovic Courtès]

Hello!

I didn’t mention it but here are rough guidelines that I think we should
follow for blog posts:

  • It should indeed be about free software and not promote non-free
software (it’s also a good idea to follow
 IMO.)  So the
topic of patching non-free binaries wouldn’t fit the bill, for
instance.

  • It should be understandable by someone who’s not a die-hard Guix
or Scheme hacker.  :-)  So it’s good to provide enough context,
possibly with links to relevant parts of the manual, previous blog
posts, etc.

  • It’s good to use appropriate Markdown markup (ah ha!), like
backquotes for file names, command names, and so on, or “```scheme”
to introduce Scheme snippets.  See .

Apart from that, anything that teaches people how to solve a problem or
that explains neat hacks in or with Guix(SD) is very welcome IMO!
Articles don’t have to be super long or take days to write; more
informal or short articles can be useful too.

Ludo’.

Re: Generating wrappers for execution in non-root non-Guix contexts

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Brilliant!
>
> Would this only work for C-based programs?

No, it works for everything.  It’s brute-force I must say.  :-)

Ludo’.

Re: Update the Guix package/version

[Roel Janssen]

Ludovic Courtès  writes:

> Roel Janssen  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hello,
>>>
>>> Roel Janssen  skribis:
>>>
 What's the decision process for updating the ‘guix’ package revision,
 like in commit b1fb247b?
>>>
>>> There’s no real process, just do it when there’s a good reason to do it.
>>>
 The reason I ask this is because I'd like to bump the revision so that
 the changes from 5cefb13d to ‘guix-daemon’ are available when I install
 ‘guix’ in a profile.
>>>
>>> Makes sense!
>>>
>>> Note that you can run “make update-guix-package” to do the work.  Be
>>> sure to do that from a commit that is available on Savannah.  And of
>>> course, make sure the package builds locally.  :-)
>>
>> Cool! I didn't know about this build step.  May I commit the change, so
>> that I won't end up with an ambiguous revision number later on?
>
> Sure if you have an update based on an upstream commit that builds,
> you’re welcome to push it.
>
> Perhaps you can also run “guix build -S guix --check” to be 100% sure
> that the commit and hash are correct.

I did:
$ git reset --hard
$ git pull
$ make update-guix-package
$ guix build -S guix --check
$ guix build guix

And after verifying that all went fine, I then pushed the change in
5b862761f.

Thanks!

Kind regards,
Roel Janssen

Re: Have GPGPU support in guix?

[Ludovic Courtès]

Hello,

Joshua Branson  skribis:

> Fis Trivial  writes:
>
>> Hi Guixs, this is actually a feature wish.
>>
>> 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. Currently I need to use CUDA from NVidia, as many of
>> you might know, it's not free software, not even an open source
>> software. However, it's the de fato toolchain in deep learning
>> community, so basically it's a must have dependency for most of the
>> related libraries if you want decent performance. Time passes and
>> hardwork have been done, now we have some libraries ported to OpenCL or
>> HIP (from AMD), it's not mature yet but I think we have a pretty good
>> shot at working them out in near future.
>
> Since this is a GNU endorsed distro, guixSD will never have an official
> way to install or use CUDA.

Indeed.  Specifically, the project is committed to following the FSDG,
so CUDA doesn’t belong in Guix:

  https://gnu.org/distros/free-system-distribution-guidelines.html

Free software that you might find of interest is POCL, an OpenCL
implementation (not yet packaged in Guix):

  https://github.com/pocl/pocl

Ludo’.

Re: Cleaning up the /bin for guix.

[Roel Janssen]

Ludovic Courtès  writes:

> Roel Janssen  skribis:
>
>> From 9455c7b94e0010ff4038132affc7a5c796313894 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen 
>> Date: Tue, 24 Apr 2018 12:48:32 +0200
>> Subject: [PATCH] gnu: guile-ssh: Move files from bin to examples directory.
>>
>> * gnu/packages/ssh.scm (guile-ssh): Move files from bin to the examples
>>   directory.
>
> [...]
>
>> +(invoke "mv" (string-append bin "/ssshd.scm") 
>> examples)
>> +(invoke "mv" (string-append bin "/sssh.scm") 
>> examples)
>
> Please use ‘rename-file’ instead of invoking “mv”.  :-)

Done, and pushed in d00026429.

Thanks!

Kind regards,
Roel Janssen

Re: staging evaluation in progress

[Efraim Flashner]

On Mon, Apr 23, 2018 at 09:53:04PM -0400, Mark H Weaver wrote:
> Marius Bakke  writes:
> 
> > Mark H Weaver  writes:
> >
> >> Hi Marius,
> >>
> >> Marius Bakke  writes:
> >>
> >>> I just started a 'staging' evaluation:
> >>>
> >>> https://hydra.gnu.org/jobset/gnu/staging
> >>>
> >>> Fairly minor changes this round, highlights include Wayland 1.15 and
> >>> GStreamer 1.14.  We narrowly missed Mesa 17.3.9 which was scheduled for
> >>> today but delayed, hopefully 17.3.8 doesn't introduce any new bugs.
> >>>
> >>> Results should start ticking in tomorrow.
> >>
> >> The main issue I see so far is that 'gst-plugins-base' seems to
> >> consistently fail the "elements/opus" test on i686-linux.  It failed
> >> twice in a row, anyway:
> >>
> >>   https://hydra.gnu.org/build/2635798
> >
> > I can reproduce this failure locally, and could not find related bug
> > reports or git commits upstream.  For now I downgraded to 1.12.5 so we
> > can proceed, and will report the i686 and armhf issues upstream.
> 
> Instead of downgrading gstreamer, I think it would be better to simply
> disable that test on i686 for now.  Most likely, it is due to tests that
> are intolerant of the double rounding that occurs on i686 without SSE2,
> where the old x87 FP instructions are used instead.  The double rounding
> happens because x87 operations are performed on 80-bit double-extended
> precision floating-point numbers, which must then be rounded a second
> time when they are converted to 64-bit doubles as used in C.
> 
> What do you think?
> 
>   Mark
> 

somewhat random tests fail on aarch64 also, different ones from the
other architectures. I'd suggest we wait it out until 1.14.1 and watch
upstream for bug fixes.

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


signature.asc
Description: PGP signature

Re: Successfully running GNOME on core-updates + staging

[Efraim Flashner]

On Wed, Apr 25, 2018 at 02:14:04PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Marius Bakke  skribis:
> 
> > Ludovic Courtès  writes:
> >
> >> Hi Mark,
> >>
> >> Mark H Weaver  skribis:
> >>
> >>> I've successfully updated my x86_64 GuixSD system to my private branch
> >>> based on 'core-updates' with recent 'master' and 'staging' merged into
> >>> it.  This system includes a full GNOME desktop environment plus a few
> >>> programs based on Qt.  It all works quite well.
> >>>
> >>> My branch includes a few draft fixes and workarounds that I haven't yet
> >>> pushed, but nothing that would require many rebuilds to update later.
> >>>
> >>> So, I think it might be time to ask Hydra to build all of core-updates,
> >>> after staging is merged into it.
> >>
> >> I agree.  There was an issue with cross-compiling ‘bootstrap-tarballs’
> >> that Marius reported a few days ago, which I’m looking into right now.
> >> I don’t expect the fix(es) to trigger a full rebuild.
> >>
> >> If Marius and others don’t object, I’d say go for it!
> >
> > No objections from me.  However I do have a bunch of fairly innocent
> > updates in my queue, such as SQLite, Glib and CMake.  It's also tempting
> > to get rid of that Perl graft.  Is it too late for such changes?
> 
> I think it’s OK for sqlite/glib/cmake, but changing Perl would further
> delay things, which perhaps is not desirable.
> 
> > Hydra will be busy for a couple of days with 'master' and 'staging', so
> > there's little use in starting it immediately.
> 
> It took me a couple of days to reply :-), so maybe we can start the
> evaluation now?
> 
> We can also get berlin to build all of ‘core-updates’ if we want.
> 
> Thanks,
> Ludo’.
> 

Perl should be straight forward, considering it would've been a normal
graft except for the version string part. Unless you're refering to
starting the rebuilds further down the tree.

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


signature.asc
Description: PGP signature

Re: Preferred blog format - Markdown or SXML?

[Adonay Felipe Nogueira]

2018-04-22T14:08:33+0530 Pierre Neidhardt wrote:
> What about Org-mode?
> Rationale:
>
>   http://karl-voit.at/2017/09/23/orgmode-as-markup-only

Yeah... I was about to ask the same question.

I don't want to force anyone to write in Org-mode, precisely because I
don't write in the blog yet --- but I do know some tricks on how to get
GNU Guix and packages working almost flawlessly in Trisquel 7 and 8 ---,
but I personally find Org-mode easier to learn and write (than
Markdown), has more features, an active community, and (in the near
future perhaps?) will become a document preparation standard (although I
don't like /de facto/ standards, and the only formal one I know about is
the binary and plain-text-editor-unfriendly ODF and co., and if these
are editable in plain text editors, the amount of typing for most basic
markup sets new people off).

-- 
- Formas de contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do /software/ livre (não confundir com gratuito). Avaliador
  da liberdade de /software/ e de /sites/.
- Arquivos que aceito: https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Contribuições à sociedade:
  https://libreplanet.org/wiki/User:Adfeno#Contributions
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
  https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
  permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
  (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook
  #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
  #Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
  https://www.defectivebydesign.org/

Re: Preferred blog format - Markdown or SXML?

[Thompson, David]

On Sun, Apr 22, 2018 at 10:22 AM, Adam Massmann  wrote:
>
> Hi,
>
> Pierre Neidhardt  writes:
>
>> What about Org-mode?
>> Rationale:
>>
>>   http://karl-voit.at/2017/09/23/orgmode-as-markup-only
>
> The website uses the haunt [1] static site generator which
> does not currently support direct reading of org files. However, you
> could easily export an org file to one of the supported formats (like
> html).

If anyone writes an org-mode parser in Guile, let me know and I'll add
support for it in Haunt. I wouldn't even know where to begin with
trying to parse org files. :)

- Dave

Re: staging evaluation in progress

[Marius Bakke]

Hello Mark,

Mark H Weaver  writes:

> Marius Bakke  writes:
>
>> Mark H Weaver  writes:
>>
>>> Hi Marius,
>>>
>>> Marius Bakke  writes:
>>>
 I just started a 'staging' evaluation:

 https://hydra.gnu.org/jobset/gnu/staging

 Fairly minor changes this round, highlights include Wayland 1.15 and
 GStreamer 1.14.  We narrowly missed Mesa 17.3.9 which was scheduled for
 today but delayed, hopefully 17.3.8 doesn't introduce any new bugs.

 Results should start ticking in tomorrow.
>>>
>>> The main issue I see so far is that 'gst-plugins-base' seems to
>>> consistently fail the "elements/opus" test on i686-linux.  It failed
>>> twice in a row, anyway:
>>>
>>>   https://hydra.gnu.org/build/2635798
>>
>> I can reproduce this failure locally, and could not find related bug
>> reports or git commits upstream.  For now I downgraded to 1.12.5 so we
>> can proceed, and will report the i686 and armhf issues upstream.
>
> Instead of downgrading gstreamer, I think it would be better to simply
> disable that test on i686 for now.  Most likely, it is due to tests that
> are intolerant of the double rounding that occurs on i686 without SSE2,
> where the old x87 FP instructions are used instead.  The double rounding
> happens because x87 operations are performed on 80-bit double-extended
> precision floating-point numbers, which must then be rounded a second
> time when they are converted to 64-bit doubles as used in C.
>
> What do you think?

Thanks for the insight here.  My rationale for downgrading was that
there are a handful other tests that fail on armhf; but I just realized
that we haven't had "gst-plugins-base" working on armhf for a long time.

1.12.5 is also "newer" than 1.14.0.  Since there are problems on aarch64
too I went ahead and started the branch with 1.12.5.

Let's revisit this issue on 'core-updates'.


signature.asc
Description: PGP signature

Re: Preferred blog format - Markdown or SXML?

[Clément Lassieur]

Thompson, David  writes:

> On Sun, Apr 22, 2018 at 10:22 AM, Adam Massmann  wrote:
>>
>> Hi,
>>
>> Pierre Neidhardt  writes:
>>
>>> What about Org-mode?
>>> Rationale:
>>>
>>>   http://karl-voit.at/2017/09/23/orgmode-as-markup-only
>>
>> The website uses the haunt [1] static site generator which
>> does not currently support direct reading of org files. However, you
>> could easily export an org file to one of the supported formats (like
>> html).
>
> If anyone writes an org-mode parser in Guile, let me know and I'll add
> support for it in Haunt. I wouldn't even know where to begin with
> trying to parse org files. :)

As a workaround or as a starting point, there is OrgRuby
(https://github.com/wallyqs/org-ruby, packaged for Guix as
ruby-org-ruby).  I don't know if Haunt supports Ruby though.

Re: Preferred blog format - Markdown or SXML?

[Nicolas Goaziou]

Hello,

"Thompson, David"  writes:

> If anyone writes an org-mode parser in Guile, let me know and I'll add
> support for it in Haunt. I wouldn't even know where to begin with
> trying to parse org files. :)

You would probably start here ;)

  https://orgmode.org/worg/dev/org-syntax.html

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: staging evaluation in progress

[Mark H Weaver]

Efraim Flashner  writes:

> On Mon, Apr 23, 2018 at 09:53:04PM -0400, Mark H Weaver wrote:
>> Marius Bakke  writes:
>> 
>> > Mark H Weaver  writes:
>> >
>> >> Hi Marius,
>> >>
>> >> Marius Bakke  writes:
>> >>
>> >>> I just started a 'staging' evaluation:
>> >>>
>> >>> https://hydra.gnu.org/jobset/gnu/staging
>> >>>
>> >>> Fairly minor changes this round, highlights include Wayland 1.15 and
>> >>> GStreamer 1.14.  We narrowly missed Mesa 17.3.9 which was scheduled for
>> >>> today but delayed, hopefully 17.3.8 doesn't introduce any new bugs.
>> >>>
>> >>> Results should start ticking in tomorrow.
>> >>
>> >> The main issue I see so far is that 'gst-plugins-base' seems to
>> >> consistently fail the "elements/opus" test on i686-linux.  It failed
>> >> twice in a row, anyway:
>> >>
>> >>   https://hydra.gnu.org/build/2635798
>> >
>> > I can reproduce this failure locally, and could not find related bug
>> > reports or git commits upstream.  For now I downgraded to 1.12.5 so we
>> > can proceed, and will report the i686 and armhf issues upstream.
>> 
>> Instead of downgrading gstreamer, I think it would be better to simply
>> disable that test on i686 for now.  Most likely, it is due to tests that
>> are intolerant of the double rounding that occurs on i686 without SSE2,
>> where the old x87 FP instructions are used instead.  The double rounding
>> happens because x87 operations are performed on 80-bit double-extended
>> precision floating-point numbers, which must then be rounded a second
>> time when they are converted to 64-bit doubles as used in C.
>> 
>> What do you think?
>> 
>>   Mark
>> 
>
> somewhat random tests fail on aarch64 also, different ones from the
> other architectures. I'd suggest we wait it out until 1.14.1 and watch
> upstream for bug fixes.

Do we know if there are any security fixes in 1.14.0 that are not in
1.12.5?  Is the 1.12.x branch still receiving security updates?

   Mark

Re: Introducing myself as an Outreachy Intern

[Ricardo Wurmus]

Welcome Sahithi!

> I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
> pursuing my under graduation final semester in Computer Science. I will
> be working as an Outreachy Intern for May-August 2018. I am glad to be
> part of Guix Community. I have been working with Ricardo Wurmus during
> the application process. He helped me in understanding and working with
> Guix. Community has given a great support, expecting the same till the end.

In my experience, this community is very supportive, patient, and
friendly.  I’m sure you will find the same.  I’m looking forward to
working with you and hope you’ll enjoy the experience.  Feel free to ask
questions by sending email to guix-devel@gnu.org — chances are that
someone else has the same question but didn’t dare to ask.

To the rest of the Guix community: please welcome Sahithi and support
this project by answering questions on IRC or here on the list.

I should add that Sahithi will be working on the project “Improve the
user experience for the "guix package" command line tool”, which will
address some of the major and minor problems that the command line
interface currently has.  I’m the primary mentor for this project, and
Gábor has volunteered to be co-mentor.  Thank you, Gábor!

--
Ricardo

Re: Have GPGPU support in guix?

[Ricardo Wurmus]

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.

--
Ricardo

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: Use .authinfo for git credentials

[Efraim Flashner]

On Wed, Apr 25, 2018 at 12:07:35PM +0200, Marius Bakke wrote:
> Pierre Neidhardt  writes:
> 
> > Or else how do you people configure `git send-email' to not prompt for a
> > password?
> 
> I use 'msmtp' as the transport and have configured it to look up
> passwords from 'password-store'.
> 
> $ git config --get-regexp sendemail.*
> sendemail.smtpserver /home/marius/.guix-profile/bin/msmtp
> sendemail.envelopesender auto
> 
> My ~/.msmtprc contains a line such as
> 'passwordeval "pass Email/fm/mbakke/out 2>/dev/null"'.  Obviously you
> can use any other shell command here.
> 
> Hope this helps!

The similar line in my .msmtprc is:
passwordeval gpg --no-tty -q -d $HOME/.msmtp.password.gpg


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


signature.asc
Description: PGP signature

Re: Introducing myself as an Outreachy Intern

[Gábor Boskovits]

2018-04-25 21:07 GMT+02:00 Gábor Boskovits :

> 2018-04-25 17:38 GMT+02:00 Ricardo Wurmus :
>
>>
>> Welcome Sahithi!
>>
>> > I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
>> > pursuing my under graduation final semester in Computer Science. I will
>> > be working as an Outreachy Intern for May-August 2018. I am glad to be
>> > part of Guix Community. I have been working with Ricardo Wurmus during
>> > the application process. He helped me in understanding and working with
>> > Guix. Community has given a great support, expecting the same till the
>> end.
>>
>> In my experience, this community is very supportive, patient, and
>> friendly.  I’m sure you will find the same.  I’m looking forward to
>> working with you and hope you’ll enjoy the experience.  Feel free to ask
>> questions by sending email to guix-devel@gnu.org — chances are that
>> someone else has the same question but didn’t dare to ask.
>>
>> To the rest of the Guix community: please welcome Sahithi and support
>> this project by answering questions on IRC or here on the list.
>>
>> I should add that Sahithi will be working on the project “Improve the
>> user experience for the "guix package" command line tool”, which will
>> address some of the major and minor problems that the command line
>> interface currently has.  I’m the primary mentor for this project, and
>> Gábor has volunteered to be co-mentor.  Thank you, Gábor!
>>
>>
> Welcome Sahithi!
>
> I'm looking forward to working with you. I'm Gábor, and I am
> co-mentoring the project. My IRC username is g_bor.
>
>> --
>> Ricardo
>>
>>
>>
>

Re: Introducing myself as an Outreachy Intern

[Gábor Boskovits]

2018-04-25 17:38 GMT+02:00 Ricardo Wurmus :

>
> Welcome Sahithi!
>
> > I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
> > pursuing my under graduation final semester in Computer Science. I will
> > be working as an Outreachy Intern for May-August 2018. I am glad to be
> > part of Guix Community. I have been working with Ricardo Wurmus during
> > the application process. He helped me in understanding and working with
> > Guix. Community has given a great support, expecting the same till the
> end.
>
> In my experience, this community is very supportive, patient, and
> friendly.  I’m sure you will find the same.  I’m looking forward to
> working with you and hope you’ll enjoy the experience.  Feel free to ask
> questions by sending email to guix-devel@gnu.org — chances are that
> someone else has the same question but didn’t dare to ask.
>
> To the rest of the Guix community: please welcome Sahithi and support
> this project by answering questions on IRC or here on the list.
>
> I should add that Sahithi will be working on the project “Improve the
> user experience for the "guix package" command line tool”, which will
> address some of the major and minor problems that the command line
> interface currently has.  I’m the primary mentor for this project, and
> Gábor has volunteered to be co-mentor.  Thank you, Gábor!
>
>
Welcome Sahithi!

I'm looking forward to working with you. I'm Gábor, and I am
co-mentoring the project. My ICR

> --
> Ricardo
>
>
>

Re: Have GPGPU support in guix?

[Joshua Branson]

Tobias Platen  writes:

> 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.

That's actually a really good point.  I forgot about that.  Isn't radeon
close to having free drivers?

>
> Tobias Platen
>>
>> --
>> Ricardo
>>
>>
>>

Re: Have GPGPU support in guix?

[Fis Trivial]

Ludovic Courtès writes:

> Hello,
>
> Joshua Branson  skribis:
>
>> Fis Trivial  writes:
>>
>>> Hi Guixs, this is actually a feature wish.
>>>
>>> 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. Currently I need to use CUDA from NVidia, as many of
>>> you might know, it's not free software, not even an open source
>>> software. However, it's the de fato toolchain in deep learning
>>> community, so basically it's a must have dependency for most of the
>>> related libraries if you want decent performance. Time passes and
>>> hardwork have been done, now we have some libraries ported to OpenCL or
>>> HIP (from AMD), it's not mature yet but I think we have a pretty good
>>> shot at working them out in near future.
>>
>> Since this is a GNU endorsed distro, guixSD will never have an official
>> way to install or use CUDA.
>
> Indeed.  Specifically, the project is committed to following the FSDG,
> so CUDA doesn’t belong in Guix:
>
>   https://gnu.org/distros/free-system-distribution-guidelines.html
>

Sorry that I didn't make it clear in the original mail. The reason I
talked about CUDA, is to express, that's the one thing I want to get rid
of and replace it with Other free alternatives listed in original mail.
But I need help packaging those free alternatives.

> Free software that you might find of interest is POCL, an OpenCL
> implementation (not yet packaged in Guix):
>
>   https://github.com/pocl/pocl
>

I mentioned it in the original mail. But packaging these thing requires
knowledge for kernel space stuffs, like kernel module for GPU, which I
don't have. So, any help is appreciated.

> Ludo’.

Thanks.

Re: Have GPGPU support in guix?

[Fis Trivial]

Ricardo Wurmus writes:

> 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.

No, it doesn't. It do support sycl[1]. But again, there's no usable free
implementation of sycl that supports GPU.

[1]: https://www.khronos.org/sycl

Re: Have GPGPU support in guix?

[Fis Trivial]

Tobias Platen writes:

> 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.
>

That would be a really, really bad news.

> Tobias Platen
>>
>> --
>> Ricardo
>>
>>
>>

Re: Have GPGPU support in guix?

[Pierre Neidhardt]

Joshua Branson  writes:

> That's actually a really good point.  I forgot about that.  Isn't radeon
> close to having free drivers?

I thought it was entirely free already, isn't it?
To my understanding, it's AMDGPU that is partly proprietary.
According to the latest Phoronix benchmarks, the free Radeon performs
really well.

I don't know about OpenCL though.

-- 
Pierre Neidhardt

Once, I read that a man be never stronger than when he truly realizes how
weak he is.
-- Jim Starlin, "Captain Marvel #31"


signature.asc
Description: PGP signature

Re: Have GPGPU support in guix?

[Jonathan Brielmaier]

On 04/26/2018 05:18 AM, Pierre Neidhardt wrote:
> 
> Joshua Branson  writes:
> 
>> That's actually a really good point.  I forgot about that.  Isn't radeon
>> close to having free drivers?
> 
> I thought it was entirely free already, isn't it?
> To my understanding, it's AMDGPU that is partly proprietary.
> According to the latest Phoronix benchmarks, the free Radeon performs
> really well.

There is a bunch of entirely FOSS drivers for AMD Radeon cards:

Kernel drivers:
radeon: for older cards before GCN1.2 (kernel/drivers/gpu/drm/radeon)
amdgpu: for the new cards since GCN1.2 (kernel/drivers/gpu/drm/amd/amdgpu)

Userspace drivers:
radeonsi: for almost all cards in the last decade 
(mesa/src/gallium/drivers/radeonsi)
r600: for the ones before (mesa/src/gallium/drivers/r600)

Vulkan drivers:
RADV: written by the community (RedHat etc.), because AMD initially didn't make 
their Vulkan
userspace FOSS (mesa/src/amd/vulkan)
AMDVLK: AMDs Vulkan driver released as FOSS 
(https://github.com/GPUOpen-Drivers/AMDVLK)

So your FOSS driver would consist of amdgpu + radeonsi + radv and is in almost 
all cases the
best choice (performance, stability etc).

Then there was always a propriatary driver by AMD nowadays it's called "Radeon 
Software for Linux",
which bundles also free software like AMDVLK and ROCm. Other names before were 
"AMDGPU-PRO", 
"AMD Catalyst" and "fglrx"...

I hope it's now less confusing then before :P
Jonathan

Re: Have GPGPU support in guix?

[Pierre Neidhardt]

@Jonathan:  Thanks a lot for this thorough clarification!

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature