Re: Have GPGPU support in guix?

[Mark H Weaver]

Hi Jonathan,

Jonathan Brielmaier  writes:

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

What about firmware?  Do we know which AMD Radeon cards, if any, can be
used without including nonfree software in the OS?

A quick web search would seem to suggest that on Debian, it is very
commonly required to install the 'firmware-linux-nonfree' and/or
'firmware-amd-graphics' packages from non-free.

 Thanks,
   Mark

Re: Have GPGPU support in guix?

[Jonathan Brielmaier]

On 26/04/2018 10:04, Mark H Weaver wrote:
> What about firmware?  Do we know which AMD Radeon cards, if any, can be
> used without including nonfree software in the OS?

I'm not aware of an AMD/ATI Radeon card which doesn't need nonfree
firmware. The in-tree firmware in kernel goes back until ATI Radeon
R100[0], out-tree (linux-firmware.git) are all cards who run the amdgpu,
radeon or r600 kernel driver. So no card without nonfree firmware in the
last ~20 years...

There could be some Nvidia cards who doesn't need nonfree firmware
according to [1]. It have to be before Geforce 8000[2].

AFAIK Intel integrated GPUs didn't need nonfree firmware.

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/firmware/radeon?h=v4.4.129
[1]
https://unix.stackexchange.com/questions/393504/which-amd-ati-cards-dont-require-non-free-firmware-when-using-radeon
[2] https://en.wikipedia.org/wiki/GeForce_8_series

Re: staging evaluation in progress

[Marius Bakke]

Mark H Weaver  writes:

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

As far as I could tell, the 1.12.5 release was mostly security fixes
backported from 1.14.

See the log in
.


signature.asc
Description: PGP signature

Re: Cleaning up the /bin for guix.

[Ludovic Courtès]

Hi again,

Roel Janssen  skribis:

> When installing ‘guix’ in a profile, the ‘bin’ directory of that profile
> contains:
>
> asn1Coding -> 
> /gnu/store/2fg01r58vv9w41kw6drl1wnvqg7rkv9d-libtasn1-4.12/bin/asn1Coding
> asn1Decoding -> 
> /gnu/store/2fg01r58vv9w41kw6drl1wnvqg7rkv9d-libtasn1-4.12/bin/asn1Decoding
> asn1Parser -> 
> /gnu/store/2fg01r58vv9w41kw6drl1wnvqg7rkv9d-libtasn1-4.12/bin/asn1Parser
> certtool -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/certtool
> gnutls-cli -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/gnutls-cli
> gnutls-cli-debug -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/gnutls-cli-debug
> gnutls-serv -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/gnutls-serv
> guix -> 
> /gnu/store/qmc24l49za832zpz4xqx9xsvw3w4hd41-guix-0.14.0-10.486de73/bin/guix
> guix-daemon -> 
> /gnu/store/qmc24l49za832zpz4xqx9xsvw3w4hd41-guix-0.14.0-10.486de73/bin/guix-daemon
> idn2 -> /gnu/store/ksyja5lbwy0mpskvn4rfi5klc00c092d-libidn2-2.0.4/bin/idn2
> nettle-hash -> 
> /gnu/store/x0jf9ckd30k3nhs6bbhkrxsjmqz8phqd-nettle-3.4/bin/nettle-hash
> nettle-lfib-stream -> 
> /gnu/store/x0jf9ckd30k3nhs6bbhkrxsjmqz8phqd-nettle-3.4/bin/nettle-lfib-stream
> nettle-pbkdf2 -> 
> /gnu/store/x0jf9ckd30k3nhs6bbhkrxsjmqz8phqd-nettle-3.4/bin/nettle-pbkdf2
> ocsptool -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/ocsptool
> pkcs1-conv -> 
> /gnu/store/x0jf9ckd30k3nhs6bbhkrxsjmqz8phqd-nettle-3.4/bin/pkcs1-conv
> psktool -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/psktool
> sexp-conv -> 
> /gnu/store/x0jf9ckd30k3nhs6bbhkrxsjmqz8phqd-nettle-3.4/bin/sexp-conv
> srptool -> 
> /gnu/store/5kih0kxmipzjw10c53hhckfzkcs7c8mm-gnutls-3.5.13/bin/srptool

Looking at this list, the next steps may be to add a “bin” output to
libtasn1 and perhaps libidn2, on the grounds that the main use of these
packages are their library, not their programs (the same cannot be said
of GnuTLS and Nettle.)

What do people think?

It would have to wait until the next core-updates but we can already
give it a spin anyway.

Thanks,
Ludo’.

Re: Introducing myself as an Outreachy Intern

[Ludovic Courtès]

Hello!

Welcome to Guix, Sahitihi!  I hope this will be a pleasant and fruitful
experience for you.

Ricardo Wurmus  skribis:

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

+1

Sahitihi, please do not hesitate to ask questions on IRC or on the
mailing lists when you’re unsure about something or are looking for
help.  I’m sure people in the group will happily give a hand and provide
guidance.

Happy hacking!  :-)

Ludo’.

Re: Have GPGPU support in guix?

[Ludovic Courtès]

Hello,

Fis Trivial  skribis:

> Ludovic Courtès writes:

[...]

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

Oh sorry, I had overlooked that.

You wrote:

> However, I wanted to manage all of these with guix so that we can have a
> unified dependency tree. Currently there are a few options for OpenCL
> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
> project and the implementation in mesa.
> 
> I tried to package beignet (an old OpenCL runtime from Intel) but it
> wasn't successful due to failed tests (it failed from recognizing
> device).
> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm

Regarding failed tests, I think that tests that expect GPU devices to be
able are likely to fail: it could be that the relevant /dev nodes are
inaccessible to the build users, or, more importantly, it could be that
we’re building on a GPU-less machine such as our build farm.  So these
tests would have to be skipped.

Anyway, I would very much welcome packages in this area!

Ludo’.

Org-mode for Haunt

[Ludovic Courtès]

Hello!

"Thompson, David"  skribis:

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

Andy wrote a parser for a useful subset of Org syntax in Guile-Present:

  http://wingolog.org/projects/guile-present/

Perhaps we could make a new reader out of it in Haunt?  Any takers?  :-)

Ludo’.

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

[Ricardo Wurmus]

Hi Ludo,

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

This is very cool and very useful!  It would make “guix pack” much more
useful than it already is.  Using a pack like that would require little
more than unpacking it and running the application — that’s much less
work than setting up Docker, Singularity or Guix itself, which may be
impossible in an environment where user privileges are severely
restricted.

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

Good idea.  Could we use ptrace directly and optimize it for the case of
“/gnu/store” paths?  I’m just guessing that PRoot may incur a higher
performance penalty because it’s so generic compared to a compile-time
deterministic use of ptrace – after all, we know all /gnu/store
locations in advance.

--
Ricardo

Re: staging evaluation in progress

[Marius Bakke]

Arun Isaac  writes:

> Marius Bakke  writes:
>
>> I just started a 'staging' evaluation:
>
> Hi,
>
> I had pushed the following two texlive-bin patches to staging on Wed Apr
> 11.
>
> gnu: texlive-bin: Patch texlua shebangs.
> gnu: texlive-bin: Use ghostscript executable "gs" in ps2eps.
>
> These patches are missing from the list of patches you mentioned. Did
> something go wrong?

The initial email was sent April 16th, while the texlive patches were
added on April 21st.  So everything is in order :-)


signature.asc
Description: PGP signature

Re: staging evaluation in progress

[Arun Isaac]

Marius Bakke  writes:

> I just started a 'staging' evaluation:

Hi,

I had pushed the following two texlive-bin patches to staging on Wed Apr
11.

gnu: texlive-bin: Patch texlua shebangs.
gnu: texlive-bin: Use ghostscript executable "gs" in ps2eps.

These patches are missing from the list of patches you mentioned. Did
something go wrong?

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

[Ludovic Courtès]

Hey!

Ricardo Wurmus  skribis:

>> We could also have wrappers fall back to PRoot when unshare(2) fails.
>
> Good idea.  Could we use ptrace directly and optimize it for the case of
> “/gnu/store” paths?  I’m just guessing that PRoot may incur a higher
> performance penalty because it’s so generic compared to a compile-time
> deterministic use of ptrace – after all, we know all /gnu/store
> locations in advance.

IWBN, but that’s a project in its own.  ptrace(2) requires knowledge
about the architecture’s ABI so that you know what registers to look at
when a syscall happens, and so on.  So for now it’ll have to be PRoot.

I’ll try to come up with a patch set without PRoot support to begin
with.

Thanks for your feedback,
Ludo’.

Re: Cleaning up the /bin for guix.

[Ricardo Wurmus]

Hi Roel,

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

Please don’t invoke “mv”; you can use “install-file” instead.  For
simple things like creating links, removing files, moving them about,
renaming them, etc, it’s better to use the procedures that Guile
provides instead of spawning coreutils.

But the question here is: why does guile-ssh install these files to bin?
Should this be changed in the build system instead of patching this
downstream?

--
Ricardo

Re: Org-mode for Haunt

[Jose Garza]

What kind of effort do you think this would take? Is this a good first
commit?

On Thu, Apr 26, 2018, 8:50 AM Ludovic Courtès  wrote:

> Hello!
>
> "Thompson, David"  skribis:
>
> > 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. :)
>
> Andy wrote a parser for a useful subset of Org syntax in Guile-Present:
>
>   http://wingolog.org/projects/guile-present/
>
> Perhaps we could make a new reader out of it in Haunt?  Any takers?  :-)
>
> Ludo’.
>
>

[PATCH 0/1] Go importer

[Rouby Pierre-Antoine]

Hi Guix !

This patch is a importer for go packages, it's use git repository and the
'Gopkg.toml' file (https://golang.github.io/dep/docs/Gopkg.toml.html).

Example with totally random package in Go language ;)
---Start---
$ guix import gopkg \
https://gitlab.com/ContinuousEvolution/continuous-evolution.git \
0.8.1

(define-public go-github-com-fsouza-go-dockerclient
  (let ((commit "master") (revision "0"))
(package
  (name "go-github-com-fsouza-go-dockerclient")
  (version (git-version "0.0.0" revision commit))
  (source
(origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/fsouza/go-dockerclient.git";)
 (commit commit)))
  (file-name (git-file-name name version))
  (sha256
(base32
  "0viwysdg5i9dgdazks9wx0f93180j72x3cq9fx2synaqvqa7ldr4"
  (build-system go-build-system)
  (arguments
'(#:import-path
  "github.com/fsouza/go-dockerclient"))
  (native-inputs `())
  (home-page
"https://github.com/fsouza/go-dockerclient";)
  (synopsis "XXX")
  (description "XXX")
  (license #f

(define-public go-github-com-sirupsen-logrus
  (let ((commit "v1.0.4") (revision "0"))
(package
  (name "go-github-com-sirupsen-logrus")
  (version (git-version "0.0.0" revision commit))
  (source
(origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/sirupsen/logrus.git";)
 (commit commit)))
  (file-name (git-file-name name version))
  (sha256
(base32
  "0s8s8wvshmh7cb2f4fqnibqrpxahbaydyvskn3xsrl7z2a5wwajz"
  (build-system go-build-system)
  (arguments
'(#:import-path "github.com/sirupsen/logrus"))
  (native-inputs `())
  (home-page "https://github.com/sirupsen/logrus";)
  (synopsis "XXX")
  (description "XXX")
  (license #f

(define-public go-github-com-heroku-docker-registry-client
  (let ((commit "master") (revision "0"))
(package
  (name "go-github-com-heroku-docker-registry-client")
  (version (git-version "0.0.0" revision commit))
  (source
(origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/heroku/docker-registry-client.git";)
 (commit commit)))
  (file-name (git-file-name name version))
  (sha256
(base32
  "0db2wdgizhg71hn3f3zvan3knb8yglr0njd3mh1jn70ab7277hll"
  (build-system go-build-system)
  (arguments
'(#:import-path
  "github.com/heroku/docker-registry-client"))
  (native-inputs `())
  (home-page
"https://github.com/heroku/docker-registry-client";)
  (synopsis "XXX")
  (description "XXX")
  (license #f

(define-public go-github-com-blang-semver
  (let ((commit "3.5.1") (revision "0"))
(package
  (name "go-github-com-blang-semver")
  (version (git-version "0.0.0" revision commit))
  (source
(origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/blang/semver.git";)
 (commit commit)))
  (file-name (git-file-name name version))
  (sha256
(base32
  "19pli07y5592g4dyjyj0jq5rn548vc3fz0qg3624vm1j5828p1c2"
  (build-system go-build-system)
  (arguments
'(#:import-path "github.com/blang/semver"))
  (native-inputs `())
  (home-page "https://github.com/blang/semver";)
  (synopsis "XXX")
  (description "XXX")
  (license #f

(define-public go-github-com-pelletier-go-toml
  (let ((commit "1.0.1") (revision "0"))
(package
  (name "go-github-com-pelletier-go-toml")
  (version (git-version "0.0.0" revision commit))
  (source
(origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/pelletier/go-toml.git";)
 (commit commit)))
  (file-name (git-file-name name version))
  (sha256
(base32
  "1n8na0yg90gm0rpifmzrby5r385vvd62cdam3ls7ssy02bjvfw15"
  (build-system go-build-system)
  (arguments
'(#:import-path "github.com/pelletier/go-toml"))
  (native-inputs `())
  (home-page
"https://github.com/pelletier/go-toml";)
  (synopsis "XXX")
  (description "XXX")
  (license #f

(define-public go-gitlab-com-continuousevolution-continuous-evolution
  (let ((commit "0.8.1") (revision "0"))
(package
  (name "go-gitlab-com-continuousevolution-continuous-evolution")
  (version (git-version "0.0.0" revision commit))
  (source
(origin
  (method git-fetch)
  (uri (git-reference
 (url 
"https://gitlab.com/ContinuousEvolutio

Re: Have GPGPU support in guix?

[Fis Trivial]

>
> Oh sorry, I had overlooked that.
>

No problem, I really appreciate all the hardwork you have done, thanks. :)

> You wrote:
>
>> However, I wanted to manage all of these with guix so that we can have a
>> unified dependency tree. Currently there are a few options for OpenCL
>> runtime. Namely, beignet, neo from Intel, ROCm stack from AMD, the POCL
>> project and the implementation in mesa.
>> 
>> I tried to package beignet (an old OpenCL runtime from Intel) but it
>> wasn't successful due to failed tests (it failed from recognizing
>> device).
>> https://github.com/trivialfis/guixpkgs/blob/master/opencl.scm
>
> Regarding failed tests, I think that tests that expect GPU devices to be
> able are likely to fail: it could be that the relevant /dev nodes are
> inaccessible to the build users, or, more importantly, it could be that
> we’re building on a GPU-less machine such as our build farm.  So these
> tests would have to be skipped.

I think we might need a better scheme other than skipping tests to
verify the usability of these packages. If we skip tests for OpenCL
runtime, then all the other packages (I promise it will be A LOT) that
depend on it will need to skip their tests, since they won't run without
a proper runtime, resulting in a whole tree of untested packages. And
these thing break easily, due to the fact that they usually rely on
specific version of Clang and LLVM, and many of them still in heavy
development stage.

>
> Anyway, I would very much welcome packages in this area!
>
> Ludo’.

Re: staging evaluation in progress

[Arun Isaac]

Marius Bakke  writes:

> The initial email was sent April 16th, while the texlive patches were
> added on April 21st.  So everything is in order :-)

Ok. Thank you for the clarification! :-)

Re: Org-mode for Haunt

[swedebugia]

Hi
The source code is not available via the git repository on that page and 
neither anywhere else according to a quick search.
Is 0.3 the latest release?

/swedebugia 

On April 26, 2018 3:58:49 PM GMT+02:00, Jose Garza  
wrote:
>What kind of effort do you think this would take? Is this a good first
>commit?
>
>On Thu, Apr 26, 2018, 8:50 AM Ludovic Courtès  wrote:
>
>> Hello!
>>
>> "Thompson, David"  skribis:
>>
>> > 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. :)
>>
>> Andy wrote a parser for a useful subset of Org syntax in
>Guile-Present:
>>
>>   http://wingolog.org/projects/guile-present/
>>
>> Perhaps we could make a new reader out of it in Haunt?  Any takers? 
>:-)
>>
>> Ludo’.
>>
>>

Re: Use .authinfo for git credentials

[Chris Marusich]

Pierre Neidhardt  writes:

> 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

At first blush, this looks like the right solution given your problem
statement.  I believe this is actually included in the Git source under
the contrib/credential subdirectory.  We just don't build it today.
Perhaps you could submit a patch to build it?  I wonder if it would be
simpler to define a separate package that builds it from the source
you've linked above, rather than trying to build it within the (already
rather large) Git package definition.

I type my password when I invoke git-send-email, and it makes me a
little sad inside every time, so I'd love to be able to use this!

-- 
Chris


signature.asc
Description: PGP signature

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

[Chris Marusich]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

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

That's really cool!

I've noticed that when running in a chroot-like environment, sometimes
programs expect certain files to exist that don't - for example, device
files in /dev, procfs files in /proc, or even things like
/etc/resolv.conf.  Does this wrapper automatically create those kinds of
files, or would programs that want to access those kinds of files still
need some special love on an case-by-case basis?

-- 
Chris


signature.asc
Description: PGP signature

Re: Have GPGPU support in guix?

[Chris Marusich]

Jonathan Brielmaier  writes:

> On 26/04/2018 10:04, Mark H Weaver wrote:
>> What about firmware?  Do we know which AMD Radeon cards, if any, can be
>> used without including nonfree software in the OS?
>
> I'm not aware of an AMD/ATI Radeon card which doesn't need nonfree
> firmware. The in-tree firmware in kernel goes back until ATI Radeon
> R100[0], out-tree (linux-firmware.git) are all cards who run the amdgpu,
> radeon or r600 kernel driver. So no card without nonfree firmware in the
> last ~20 years...
>
> There could be some Nvidia cards who doesn't need nonfree firmware
> according to [1]. It have to be before Geforce 8000[2].
>
> AFAIK Intel integrated GPUs didn't need nonfree firmware.
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/firmware/radeon?h=v4.4.129
> [1]
> https://unix.stackexchange.com/questions/393504/which-amd-ati-cards-dont-require-non-free-firmware-when-using-radeon
> [2] https://en.wikipedia.org/wiki/GeForce_8_series

Are there any new graphics cards being made today by anybody, which do
not require non-free firmware?  I don't know much about the state of
graphics cards in the GNU/Linux world, but I'm very curious about it.

-- 
Chris


signature.asc
Description: PGP signature

Re: Guix on android blog post

[Pjotr Prins]

On Tue, Apr 24, 2018 at 05:12:34PM +0530, Pierre Neidhardt wrote:
> This is gold!!  Thanks so much for sharing.

Totally agree. Great work Julien a.o. Praphrasing one of the greats:
what works on large systems tends to work on small. With minimized
size packages Guix is quite ready to take on mobile and embedded
systems in, typically, proprietary software environments. That is a
huge market. We should be able to find companies interested in
pitching in once they realise the benefits.

Pj.

Re: create a symlink

[Rene]

Hello Danny,

after adding the line (install-hurd #$hurd), I have an error, I'm missing some 
module?


-
1238: 15 [run-guix-command system "init" ...]
In ice-9/boot-9.scm:
 157: 14 [catch srfi-34 # ...]
 157: 13 [catch system-error # 
...]
In ice-9/eval.scm:
 481: 12 [lp (#) (#t)]
In ice-9/r4rs.scm:
  90: 11 [dynamic-wind # ...]
In guix/store.scm:
1250: 10 [run-with-store # # # 
...]
In ice-9/eval.scm:
 386: 9 [eval # <1>) <0>)> (# #t # ...)]
 387: 8 [eval # #]
 387: 7 [eval # #]
 432: 6 [eval # #]
In ice-9/boot-9.scm:
 157: 5 [catch system-error # 
...]
In ice-9/eval.scm:
 387: 4 [eval # #]
 387: 3 [eval # #]
 386: 2 [eval # #]
 393: 1 [eval # #]
In unknown file:
   ?: 0 [memoize-variable-access! # #]

ERROR: In procedure memoize-variable-access!:
ERROR: Unbound variable: ungexp
-




‐‐‐ Original Message ‐‐‐

On April 19, 2018 1:26 AM, Danny Milosavljevic  wrote:

> Hi Rene,
> 
> > But Guix waits for a string, is it possible to use a package to do the 
> > symlink?
> 
> Not directly - but you can "convert" a package to a string by putting in 
> guix/scripts/system.scm :
> 
> (install-hurd #$hurd)
> 
> or so (where "install-hurd" is your procedure in gnu/build/install.scm).