Re: Python, poetry, and pandas

[Sébastien Lerique]

Hi Phil and Simon,

Thanks both for the input and advice (not citing it all here).

First the details. Simon wrote:

How did you installed poetry?  Via Guix or something else?
Which python packages do you have in your profile?
Is Guix System or Guix on foreign distro?


I'm using Guix System, and installed poetry via Guix. I have the 
following python packages installed: python, poetry, 
python-jupyterlab (from guix-science), and python-black. And 
guix-jupyter.



(I am aware that python-pandas is packaged for guix, but some
packages I will need down the road might not be; this project 
is
also in collaboration with non guix users, so I am looking for 
a

workflow which will work for them too.)


What are these packages?


I don't know yet, but I suspect the situation might crop up. Phil 
pointed to the PyPi importer, and I haven't used it yet, but it 
does seem to make things simpler if I need to add a package to 
Guix.


Phil wrote:
ImportError: libstdc++.so.6: cannot open shared object file: No 
such

file or directory


If it's only missing a reference to the underlying C++ library 
you could
install this library using Guix, or if you're using a foreign 
distro point to
the non-Guix version under /usr/lib which, at a guess, Poetry 
may have
picked up - but this is going to cause you more trouble down the 
line

than repackaging in Guix in my experience.


Yes, my experience with trying this for some Julia packages 
(GLMakie) convinced me not to try LD_LIBRARY_PATH hacks any more.


Now the broader view. Phil:
Guix offers pretty much everything that virtualenvs offers, but 
it does
things a little differently - you'll need to look at 
environments,
profiles, manifests, and use of a guix.scm to recreate (IMHO) a 
better

experience in the end.


I just set up a simple guix.scm for my current project, which 
indeed does the job, and of course provides all the great 
guarantees of Guix! Given the number of python packages currently, 
and the existence of the PyPi importer, I'm pretty convinced it 
covers my personal needs.


Now my wish is to find ways to collaborate with others on this 
kind of project, who unfortunately often use macOS. I was 
exploring the possibility of Guix on Darwin, but the best way to 
do that looks like running Guix System inside Docker:


http://logs.guix.gnu.org/guix/2021-03-11.log#044004
https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00111.html

So it seems that to collaborate with non-guix and non-GNU/Linux 
users, the options are 1) maintain a second environment management 
configuration (e.g. using poetry) to provide a stop-gap, or 2) 
convince colleagues to run Guix in Docker. The situation for 
Windows might be a bit better using the Linux Subsystem.


Thanks again all,
Sébastien

On 10 Mar 2021 at 19:02, Phil  wrote:


Hi Sébastien,

Sébastien Lerique writes:


Dear all,

(I am aware that python-pandas is packaged for guix, but some 
packages

I will need down the road might not be; this project is also in
collaboration with non guix users, so I am looking for a 
workflow

which will work for them too.)



Under the covers Poetry is just using regular Python virtualenvs 
I think.
These don't work well with Guix for a number of reasons - but in 
my
previous attempts to use them I found that Guix's use of 
PYTHONPATH
meant that virtualenvs where never isolated from packages 
installed by

Guix.

Guix offers pretty much everything that virtualenvs offers, but 
it does
things a little differently - you'll need to look at 
environments,
profiles, manifests, and use of a guix.scm to recreate (IMHO) a 
better

experience in the end.

When I started using Guix I went to some lengths to harmonize
virtualenvs and Guix - and others have made more substantial 
efforts
than I did - but you end up creating as many problems as you 
fix:

https://lists.gnu.org/archive/html/help-guix/2020-11/msg00237.html

If you search the mail archive a couple of other people have 
asked
similar questions to do with poetry, pyenv, pip, etc - they're 
all

interesting reading and easy to grep with those keywords:
https://lists.gnu.org/archive/html/help-guix/

The advice I was given at the time was don't mix package 
managers, and

in hindsight I'm glad repackaged what I needed under Guix.

I've packaged quite a few python libraries now, and most are 
pretty

trivial to do - if they are in PyPi you can just use this:

guix import pypi 

If you need a later version than Guix provides (eg pandas), my 
advice is
to use the ability to "inherit" the current definition in Guix 
and tweak
the version.  For Pandas I did this for a more recent version I 
needed

and all I had to do was disable 2 unit tests (which failed for a
non-Guix reason).

Apologies - not exactly the answer you want (I have a stab at 
that
below), but it's worth considering moving to Guix packaging 
exclusively

to keep your life simple.



 File

Re: Setting up guix source tree for testing a package

[Fredrik Salomonsson]

Hi Zelphir,

Zelphir Kaltstahl  writes:

> Hello Guix Users,
>
> I am trying to set up GNU Guix for package testing, as I want to test a 
> package
> before sending in a patch to add it to GNU Guix.
>
> I'll describe the steps I am taking and where I am seeing them in the docs in
> the following.
>
> All is happening inside a VM, which runs a Debian 10. The VM is almost fresh,
> except for guest additions and git and vim and such things.
>
>
> I start at https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html
> , wherein 
> I
> find a link to https://guix.gnu.org/manual/en/html_node/Defining-Packages.html
> .
>
> Next the packaging guidelines tell me, that I may run for example:
>
> 
> ./pre-inst-env guix build gnew --keep-failed
> 
>
> inside the Guix build tree.
>
> I clone Guix, so that I have a source tree of Guix.
>
> I define my package inside `guix/gnu/packages/guile.scm`.
>
> In packaging guidelines, there is a link to
> https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html
> .
> I am supposed to run the test inside a fresh Guix, to make sure, that the
> package will work fine for others, if I understand correctly.
>
> On
> https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html
> 
> I am told, that I need to generate a pre-installation script to run guix 
> without
> installing it (running stuff in the Guix build tree, as far as I understand). 
> To
> generate it, I need Guix again. The docs direct me to
> https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
> .
>
> On https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
>  the dilemma 
> is
> finally uncovered, that I need Guix to build the pre-installation script, to 
> use
> that, to build a package in the Guix source tree.
>
> As you can see, there is a chicken-and-egg problem: you first need to have
> Guix installed. Typically you would install Guix System (see System
> Installation) or Guix on top of another distro (see Binary Installation); in
> either case, you would verify the OpenPGP signature on the installation 
> medium.
> This “bootstraps” the trust chain.
>
> I install it.

You don't need guix to build guix, it just makes it a lot easier to
setup the environment to build guix as you don't need to hunt for its
dependencies yourself.

> Then I run:
>
> 
> guix environment guix --pure
> 
>
> The docs tell me I have to run:
>
> 
> ./bootstrap
> ./configure --localstatedir=some_directory
> 
>
> But here I am facing a problem. I have no clue what to set the
> `--localstatedir=directory` to. The docs tell me it is important, but I see no
> instructions on how to choose a directory for the local state, when I have
> already a Guix installed (binary installation on foreign distro). The linked
> docs about the https://guix.gnu.org/manual/en/html_node/The-Store.html
>  do not help me
> choosing it either, because that page is about the store itself, not about my
> specific scenario of doing things from Guix source tree. Since I intend to 
> build
> a package inside the Guix source tree, I think it should exactly _not_ be 
> /var,
> as that would conflict with the Guix installation, that I had to do to create
> the pre-inst-env script.
>
> What is the idea for the local state directory? Is it the location of a
> temporary store, which will contain anything, that I produce using the
> pre-inst-env script? That is what I am guessing. In that case I think
> `localstoredir` might be a good alias for `localstatedir`.
>
>
> I am trying with an empty directory, which I create just for that purpose, on
> the same level as the cloned Guix repository:
>
> 
> $ tree -L 2
> .
> ├── guix
> │   ├── ABOUT-NLS
> │   ├── aclocal.m4
> │   ├── AUTHORS
> │   ├── autom4te.cache
> │   ├── bootstrap
> │   ├── build-aux
> │   ├── ChangeLog
> │   ├── CODE-OF-CONDUCT
> │   ├── config-daemon.ac
> │   ├── config.log
> │   ├── config.status
> │   ├── configure
> │   ├── configure.ac
> │   ├── COPYING
> │   ├── doc
> │   ├── etc
> │   ├── gnu
> │   ├── gnu.scm
> │   ├── guix
> │   ├── guix.scm
> │   ├── HACKING
> │   ├── INSTALL
> │   ├── m4
> │   ├── Makefile
> │   ├── Makefile.am
> │   ├── Makefile.in
> │   ├── NEWS
> │   ├── nix
> │   ├── po
> │   ├── pre-inst-env
> │   ├── README
> │   ├── ROADMAP
> │   ├── scripts
> │   ├── test-env
> │   ├── tests
> │   ├── THANKS
> │   └── TODO
> └── guix-store
> 
>
> So I run:
>
> 
> ./configure 

Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Mikhail Kryshen  writes:

> Fulbert  writes:
>
>> Hello Guixers,
>>
>> For the past few days… maybe a couple of weeks (not sure when
>> it started exactly), I have had frequent errors with
>> substitutions. Those errors are not [always] reproducible as
>> another [or more] installation attempt succeed on the same [set of]
>> file[s].
>>
>> My computers (hardware/software) does not seem to be the
>> cause as I have experienced the same problem on 2 PC's (not
>> sharing the exact same guix configurations).
>>
>> Attached, 2 files with such an error. Note that I have
>> translated the messages back to english (from french)… just in
>> case you find some typos and wonder how guix could mistype… ^^
>>
>> The error message common to all those recent failures is :
>>   error: corrupt input while restoring archive from socket
>
> I'm seeing this too, but only when guix tries to download from my own
> local substitute server, which runs current guix-publish exposed
> directly to the network without reverse proxy.

I experimented for a bit with my substitute server and noticed that
downloads fail only when compressed substitutes are not yet available in
the guix publish cache or if caching is disabled.  This is likely a bug
in Guix.

> Downloading from
> ci.guix.gnu.org works without errors.  Could this be a race condition
> related to download rate?
>
>> Any idea ? I have not found any recent similar issue on
>> issues.guix.gnu.org.
>> downloading from 
>> https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>>  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>>
>> Backtrace:
>> In guix/ui.scm:
>>   2164:12 19 (run-guix-command _ . _)
>> In guix/scripts/substitute.scm:
>> 633:2 18 (guix-substitute . _)
>> In unknown file:
>>   17 (with-continuation-barrier #)
>> In ice-9/boot-9.scm:
>>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>   15 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>>   1731:15 12 (with-exception-handler # …)
>> In guix/scripts/substitute.scm:
>>682:17 11 (_)
>> 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
>> In ice-9/boot-9.scm:
>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> In guix/scripts/substitute.scm:
>> 400:9  8 (_)
>> In ice-9/boot-9.scm:
>>   1731:15  7 (with-exception-handler # …)
>>   1669:16  6 (raise-exception _ #:continuable? _)
>>   1667:16  5 (raise-exception _ #:continuable? _)
>>   1669:16  4 (raise-exception _ #:continuable? _)
>>   1764:13  3 (_ #< components: (#<> #<…>)
>>   1669:16  2 (raise-exception _ #:continuable? _)
>>   1667:16  1 (raise-exception _ #:continuable? _)
>>   1669:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> Bad http-version header component: ¡_¨””8ᗯñÿ
>>
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>3 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>> 718:2  2 (call-with-prompt _ _ #)
>> In ice-9/eval.scm:
>> 619:8  1 (_ #(#(#)))
>> In guix/ui.scm:
>>   2164:12  0 (run-guix-command _ . _)
>>
>> guix/ui.scm:2164:12: In procedure run-guix-command:
>> Bad http-version header component: ¡_¨””8ᗯñÿ
>>
>> substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz 
>> failed 
>> guix package: error: corrupt input while restoring archive from socket
>> downloading from 
>> https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
>>  ghc-blaze-markup-0.8.2.3  124KiB
>> 1.4MiB/s 00:00 [##] 100.0%
>>
>> Backtrace:
>> In guix/ui.scm:
>>   2164:12 19 (run-guix-command _ . _)
>> In guix/scripts/substitute.scm:
>> 633:2 18 (guix-substitute . _)
>> In unknown file:
>>   17 (with-continuation-barrier #)
>> In ice-9/boot-9.scm:
>>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>   15 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>>   1731:15 12 (with-exception-handler # …)
>> In guix/scripts/substitute.scm:
>>682:17 11 (_)
>> 391:7 10 (process-substitution _ "/gnu/store/gs7l81p1xzgdzvxdjc…" …)
>> In ice-9/boot-9.scm:
>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> In guix/scripts/substitute.scm:
>> 400:9  8 (_)
>> In ice-9/boot-9.scm:
>>   1731:15  7 (with-exception-handler # …)
>>   1669:16  6 (raise-exception _ #:continuable? _)
>>   1667:16  5 (raise-exception _ #:continuable? _)
>>   1669:16  4 (raise-exception _ #:continuable? _)
>>   1764:13  3 (_ #< components: (#<> #<…>)
>>   1669:16  2 

Setting up guix source tree for testing a package

[Zelphir Kaltstahl]

Hello Guix Users,

I am trying to set up GNU Guix for package testing, as I want to test a package
before sending in a patch to add it to GNU Guix.

I'll describe the steps I am taking and where I am seeing them in the docs in
the following.

All is happening inside a VM, which runs a Debian 10. The VM is almost fresh,
except for guest additions and git and vim and such things.


I start at https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html
, wherein I
find a link to https://guix.gnu.org/manual/en/html_node/Defining-Packages.html
.

Next the packaging guidelines tell me, that I may run for example:


./pre-inst-env guix build gnew --keep-failed


inside the Guix build tree.

I clone Guix, so that I have a source tree of Guix.

I define my package inside `guix/gnu/packages/guile.scm`.

In packaging guidelines, there is a link to
https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html
.
I am supposed to run the test inside a fresh Guix, to make sure, that the
package will work fine for others, if I understand correctly.

On
https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html

I am told, that I need to generate a pre-installation script to run guix without
installing it (running stuff in the Guix build tree, as far as I understand). To
generate it, I need Guix again. The docs direct me to
https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
.

On https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
 the dilemma is
finally uncovered, that I need Guix to build the pre-installation script, to use
that, to build a package in the Guix source tree.

> As you can see, there is a chicken-and-egg problem: you first need to have
Guix installed. Typically you would install Guix System (see System
Installation) or Guix on top of another distro (see Binary Installation); in
either case, you would verify the OpenPGP signature on the installation medium.
This “bootstraps” the trust chain.

I install it.

Then I run:


guix environment guix --pure


The docs tell me I have to run:


./bootstrap
./configure --localstatedir=some_directory


But here I am facing a problem. I have no clue what to set the
`--localstatedir=directory` to. The docs tell me it is important, but I see no
instructions on how to choose a directory for the local state, when I have
already a Guix installed (binary installation on foreign distro). The linked
docs about the https://guix.gnu.org/manual/en/html_node/The-Store.html
 do not help me
choosing it either, because that page is about the store itself, not about my
specific scenario of doing things from Guix source tree. Since I intend to build
a package inside the Guix source tree, I think it should exactly _not_ be /var,
as that would conflict with the Guix installation, that I had to do to create
the pre-inst-env script.

What is the idea for the local state directory? Is it the location of a
temporary store, which will contain anything, that I produce using the
pre-inst-env script? That is what I am guessing. In that case I think
`localstoredir` might be a good alias for `localstatedir`.

I am trying with an empty directory, which I create just for that purpose, on
the same level as the cloned Guix repository:


$ tree -L 2
.
├── guix
│   ├── ABOUT-NLS
│   ├── aclocal.m4
│   ├── AUTHORS
│   ├── autom4te.cache
│   ├── bootstrap
│   ├── build-aux
│   ├── ChangeLog
│   ├── CODE-OF-CONDUCT
│   ├── config-daemon.ac
│   ├── config.log
│   ├── config.status
│   ├── configure
│   ├── configure.ac
│   ├── COPYING
│   ├── doc
│   ├── etc
│   ├── gnu
│   ├── gnu.scm
│   ├── guix
│   ├── guix.scm
│   ├── HACKING
│   ├── INSTALL
│   ├── m4
│   ├── Makefile
│   ├── Makefile.am
│   ├── Makefile.in
│   ├── NEWS
│   ├── nix
│   ├── po
│   ├── pre-inst-env
│   ├── README
│   ├── ROADMAP
│   ├── scripts
│   ├── test-env
│   ├── tests
│   ├── THANKS
│   └── TODO
└── guix-store


So I run:


./configure --localstatedir=/home/user/dev/guix-store


Next is running:


make check


Some warnings appear:


Your input po file po/doc/guix-manual.de.po seems outdated (The amount of 
entries differ between files: 10012 is not 334
). Please consider running po4a-updatepo to refresh it.


But I am guessing, that these can be ignored for my purposes, as I am not doing
anything with translations or po files.

However, there are other errors, like not finding code for some modules (the
output of make check 

Re: setup c/c++ development environment

[Fredrik Salomonsson]

Hi Ekaitz,

CC:ing the rest of the help-guix mailing list, I hope you don't mind.

Ekaitz Zarraga  writes:

> I have a question with all this you shared.
>
> Is this compiling only the needed parts or it recompiles the whole directory 
> from scratch every time you run `guix build`?

To my knowledge it will recompile everything every time you run
`guix build`.

So this method might be better suited for CI (continuous integration).

But benefit with the `guix.scm` file is that you can also use the same
file to setup the environment you need to build your package.

`guix environment -l guix.scm`
or
`guix environment -l build-aux/guix.scm`

Depending how you have layed out the guix.scm file.

That will use guix to setup the environment needed to build the your
package. And in that shell you can use:

meson build
meson compile -C build
meson test -C build

Or equivalent for other build systems. Which will support partial
builds.

Note that guix might have issues with build generated files for some
build systems when mixing guix environment and guix build. E.g. run
`guix environment`, generate the build files and then run `guix build`.
It seems fine with meson, even when not filtering out the build files.
But I have had issues with GNU autotools and permissions,
`make distclean` before calling `guix build` is a quick workaround. A
better option is probably to filter out those files when collecting the
source.

I hope that answers your question.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Booy fails after fresh, successful installation

[Gabriel Wicki]

hello

since this is a brand-new machine, i hadn't tried anything before. now
it's happily running kubuntu (without any non-free drivers). which
doesn't make it a linux-libre kernel (afaik), but still.

what's the difference between the installer and the to-be-installed
system? i'd be astonished if they weren't both linux-libre...


On Thu, Mar 11, 2021 at 09:19:17AM +0100, Pierre Neidhardt wrote:
> The installer does not have the same hardware requirements as the booted
> OS, in particular when it comes to graphics.
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/




signature.asc
Description: PGP signature

Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Fulbert  writes:

> Le Thu, Mar 11, 2021 at 04:59:42PM +0300, Mikhail Kryshen a écrit :
>> Fulbert  writes:
>> 
>> > Hello Guixers,
>> >
>> > For the past few days… maybe a couple of weeks (not sure when
>> > it started exactly), I have had frequent errors with
>> > substitutions. Those errors are not [always] reproducible as
>> > another [or more] installation attempt succeed on the same [set of]
>> > file[s].
>> >
>> > My computers (hardware/software) does not seem to be the
>> > cause as I have experienced the same problem on 2 PC's (not
>> > sharing the exact same guix configurations).
>> >
>> > Attached, 2 files with such an error. Note that I have
>> > translated the messages back to english (from french)… just in
>> > case you find some typos and wonder how guix could mistype… ^^
>> >
>> > The error message common to all those recent failures is :
>> >   error: corrupt input while restoring archive from socket
>> 
>> I'm seeing this too, but only when guix tries to download from my own
>> local substitute server, which runs current guix-publish exposed
>> directly to the network without reverse proxy.  Downloading from
>> ci.guix.gnu.org works without errors.  Could this be a race condition
>> related to download rate?
>
> Hello and thanks for your time Mikhail,
>
> I only have a local channel with a couple of local files but no
> subtitute server. All downloads go through ci.gui.gnu.org.
>
>> Downloading from ci.guix.gnu.org works without errors.  Could
>> this be a race condition related to download rate?
>
> I don't know. I'm not even sure what it means and how I could
> check that. Wouldn't this kind of problem be handled on the
> network "layers" ?… Because, as stated, I have not experienced
> other problems besides guix substitutions, whether guix related or
> any other use as a connected "desktop" user.

Ah, sorry for the confusion, my question was meant as a
speculation/suggestion to the Guix developers.

>> > Any idea ? I have not found any recent similar issue on
>> > issues.guix.gnu.org.
>> > downloading from 
>> > https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>> >  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>> >
>> > Backtrace:
>> > In guix/ui.scm:
>> >   2164:12 19 (run-guix-command _ . _)
>> > In guix/scripts/substitute.scm:
>> > 633:2 18 (guix-substitute . _)
>> > In unknown file:
>> >   17 (with-continuation-barrier #)
>> > In ice-9/boot-9.scm:
>> >   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> > In unknown file:
>> >   15 (apply-smob/0 #)
>> > In ice-9/boot-9.scm:
>> >   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>> >   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>> >   1731:15 12 (with-exception-handler # …)
>> > In guix/scripts/substitute.scm:
>> >682:17 11 (_)
>> > 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
>> > In ice-9/boot-9.scm:
>> >   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> > In guix/scripts/substitute.scm:
>> > 400:9  8 (_)
>> > In ice-9/boot-9.scm:
>> >   1731:15  7 (with-exception-handler # …)
>> >   1669:16  6 (raise-exception _ #:continuable? _)
>> >   1667:16  5 (raise-exception _ #:continuable? _)
>> >   1669:16  4 (raise-exception _ #:continuable? _)
>> >   1764:13  3 (_ #< components: (#<> #<…>)
>> >   1669:16  2 (raise-exception _ #:continuable? _)
>> >   1667:16  1 (raise-exception _ #:continuable? _)
>> >   1669:16  0 (raise-exception _ #:continuable? _)
>> >
>> > ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> > Bad http-version header component: ¡_¨””8ᗯñÿ
>> >
>> > Backtrace:
>> > In ice-9/boot-9.scm:
>> >   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
>> > In unknown file:
>> >3 (apply-smob/0 #)
>> > In ice-9/boot-9.scm:
>> > 718:2  2 (call-with-prompt _ _ #)
>> > In ice-9/eval.scm:
>> > 619:8  1 (_ #(#(#)))
>> > In guix/ui.scm:
>> >   2164:12  0 (run-guix-command _ . _)
>> >
>> > guix/ui.scm:2164:12: In procedure run-guix-command:
>> > Bad http-version header component: ¡_¨””8ᗯñÿ
>> >
>> > substitution of 
>> > /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz failed 
>> > guix package: error: corrupt input while restoring archive from socket
>> > downloading from 
>> > https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
>> >  ghc-blaze-markup-0.8.2.3  124KiB  
>> >   1.4MiB/s 00:00 [##] 100.0%
>> >
>> > Backtrace:
>> > In guix/ui.scm:
>> >   2164:12 19 (run-guix-command _ . _)
>> > In guix/scripts/substitute.scm:
>> > 633:2 18 (guix-substitute . _)
>> > In unknown file:
>> >   17 (with-continuation-barrier #)
>> > In ice-9/boot-9.scm:
>> >   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
>> > In unknown file:
>> >   15 (apply-smob/0 #)
>> > In ice-9/boot-9.scm:

Re: error: corrupt input while restoring archive from socket

[Fulbert]

Le Thu, Mar 11, 2021 at 04:59:42PM +0300, Mikhail Kryshen a écrit :
> Fulbert  writes:
> 
> > Hello Guixers,
> >
> > For the past few days… maybe a couple of weeks (not sure when
> > it started exactly), I have had frequent errors with
> > substitutions. Those errors are not [always] reproducible as
> > another [or more] installation attempt succeed on the same [set of]
> > file[s].
> >
> > My computers (hardware/software) does not seem to be the
> > cause as I have experienced the same problem on 2 PC's (not
> > sharing the exact same guix configurations).
> >
> > Attached, 2 files with such an error. Note that I have
> > translated the messages back to english (from french)… just in
> > case you find some typos and wonder how guix could mistype… ^^
> >
> > The error message common to all those recent failures is :
> >   error: corrupt input while restoring archive from socket
> 
> I'm seeing this too, but only when guix tries to download from my own
> local substitute server, which runs current guix-publish exposed
> directly to the network without reverse proxy.  Downloading from
> ci.guix.gnu.org works without errors.  Could this be a race condition
> related to download rate?

Hello and thanks for your time Mikhail,

I only have a local channel with a couple of local files but no
subtitute server. All downloads go through ci.gui.gnu.org.

> Downloading from ci.guix.gnu.org works without errors.  Could
> this be a race condition related to download rate?

I don't know. I'm not even sure what it means and how I could
check that. Wouldn't this kind of problem be handled on the
network "layers" ?… Because, as stated, I have not experienced
other problems besides guix substitutions, whether guix related or
any other use as a connected "desktop" user.

> 
> > Any idea ? I have not found any recent similar issue on
> > issues.guix.gnu.org.
> > downloading from 
> > https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
> >  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
> >
> > Backtrace:
> > In guix/ui.scm:
> >   2164:12 19 (run-guix-command _ . _)
> > In guix/scripts/substitute.scm:
> > 633:2 18 (guix-substitute . _)
> > In unknown file:
> >   17 (with-continuation-barrier #)
> > In ice-9/boot-9.scm:
> >   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> > In unknown file:
> >   15 (apply-smob/0 #)
> > In ice-9/boot-9.scm:
> >   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
> >   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
> >   1731:15 12 (with-exception-handler # …)
> > In guix/scripts/substitute.scm:
> >682:17 11 (_)
> > 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
> > In ice-9/boot-9.scm:
> >   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> > In guix/scripts/substitute.scm:
> > 400:9  8 (_)
> > In ice-9/boot-9.scm:
> >   1731:15  7 (with-exception-handler # …)
> >   1669:16  6 (raise-exception _ #:continuable? _)
> >   1667:16  5 (raise-exception _ #:continuable? _)
> >   1669:16  4 (raise-exception _ #:continuable? _)
> >   1764:13  3 (_ #< components: (#<> #<…>)
> >   1669:16  2 (raise-exception _ #:continuable? _)
> >   1667:16  1 (raise-exception _ #:continuable? _)
> >   1669:16  0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> > Bad http-version header component: ¡_¨””8ᗯñÿ
> >
> > Backtrace:
> > In ice-9/boot-9.scm:
> >   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> > In unknown file:
> >3 (apply-smob/0 #)
> > In ice-9/boot-9.scm:
> > 718:2  2 (call-with-prompt _ _ #)
> > In ice-9/eval.scm:
> > 619:8  1 (_ #(#(#)))
> > In guix/ui.scm:
> >   2164:12  0 (run-guix-command _ . _)
> >
> > guix/ui.scm:2164:12: In procedure run-guix-command:
> > Bad http-version header component: ¡_¨””8ᗯñÿ
> >
> > substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz 
> > failed 
> > guix package: error: corrupt input while restoring archive from socket
> > downloading from 
> > https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
> >  ghc-blaze-markup-0.8.2.3  124KiB   
> >  1.4MiB/s 00:00 [##] 100.0%
> >
> > Backtrace:
> > In guix/ui.scm:
> >   2164:12 19 (run-guix-command _ . _)
> > In guix/scripts/substitute.scm:
> > 633:2 18 (guix-substitute . _)
> > In unknown file:
> >   17 (with-continuation-barrier #)
> > In ice-9/boot-9.scm:
> >   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> > In unknown file:
> >   15 (apply-smob/0 #)
> > In ice-9/boot-9.scm:
> >   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
> >   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
> >   1731:15 12 (with-exception-handler # …)
> > In guix/scripts/substitute.scm:
> >682:17 11 (_)
> > 391:7 10 

Re: error: corrupt input while restoring archive from socket

[Mikhail Kryshen]

Fulbert  writes:

> Hello Guixers,
>
> For the past few days… maybe a couple of weeks (not sure when
> it started exactly), I have had frequent errors with
> substitutions. Those errors are not [always] reproducible as
> another [or more] installation attempt succeed on the same [set of]
> file[s].
>
> My computers (hardware/software) does not seem to be the
> cause as I have experienced the same problem on 2 PC's (not
> sharing the exact same guix configurations).
>
> Attached, 2 files with such an error. Note that I have
> translated the messages back to english (from french)… just in
> case you find some typos and wonder how guix could mistype… ^^
>
> The error message common to all those recent failures is :
>   error: corrupt input while restoring archive from socket

I'm seeing this too, but only when guix tries to download from my own
local substitute server, which runs current guix-publish exposed
directly to the network without reverse proxy.  Downloading from
ci.guix.gnu.org works without errors.  Could this be a race condition
related to download rate?

> Any idea ? I have not found any recent similar issue on
> issues.guix.gnu.org.
> downloading from 
> https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz...
>  cmdliner-1.0.3.tbz  48KiB20.4MiB/s 00:00 [##] 100.0%
>
> Backtrace:
> In guix/ui.scm:
>   2164:12 19 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
> 633:2 18 (guix-substitute . _)
> In unknown file:
>   17 (with-continuation-barrier #)
> In ice-9/boot-9.scm:
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>   15 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>   1731:15 12 (with-exception-handler # …)
> In guix/scripts/substitute.scm:
>682:17 11 (_)
> 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/substitute.scm:
> 400:9  8 (_)
> In ice-9/boot-9.scm:
>   1731:15  7 (with-exception-handler # …)
>   1669:16  6 (raise-exception _ #:continuable? _)
>   1667:16  5 (raise-exception _ #:continuable? _)
>   1669:16  4 (raise-exception _ #:continuable? _)
>   1764:13  3 (_ #< components: (#<> #<…>)
>   1669:16  2 (raise-exception _ #:continuable? _)
>   1667:16  1 (raise-exception _ #:continuable? _)
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Bad http-version header component: ¡_¨””8ᗯñÿ
>
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>3 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 718:2  2 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  1 (_ #(#(#)))
> In guix/ui.scm:
>   2164:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:2164:12: In procedure run-guix-command:
> Bad http-version header component: ¡_¨””8ᗯñÿ
>
> substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz 
> failed 
> guix package: error: corrupt input while restoring archive from socket
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3...
>  ghc-blaze-markup-0.8.2.3  124KiB 
>1.4MiB/s 00:00 [##] 100.0%
>
> Backtrace:
> In guix/ui.scm:
>   2164:12 19 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
> 633:2 18 (guix-substitute . _)
> In unknown file:
>   17 (with-continuation-barrier #)
> In ice-9/boot-9.scm:
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>   15 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>   1731:15 12 (with-exception-handler # …)
> In guix/scripts/substitute.scm:
>682:17 11 (_)
> 391:7 10 (process-substitution _ "/gnu/store/gs7l81p1xzgdzvxdjc…" …)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/substitute.scm:
> 400:9  8 (_)
> In ice-9/boot-9.scm:
>   1731:15  7 (with-exception-handler # …)
>   1669:16  6 (raise-exception _ #:continuable? _)
>   1667:16  5 (raise-exception _ #:continuable? _)
>   1669:16  4 (raise-exception _ #:continuable? _)
>   1764:13  3 (_ #< components: (#<> #<…>)
>   1669:16  2 (raise-exception _ #:continuable? _)
>   1667:16  1 (raise-exception _ #:continuable? _)
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Bad Read-Header-Line header: #
>
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>3 (apply-smob/0 #)
> In 

Re: Mixed Languages Programming

[Yasuaki Kudo]

Thank you both,

It feels like using the web API as the interface between the languages would be 
the simplest.

Guix might come in really handy if the web services are all running on the same 
Guix machine in which they can share the resources of the OS such as the file 
system.

Then, using RAM-based or the real disk, different processes compiled in 
different languages can efficiently exchange data!

That's something that Guix and Nix can do more easily than using Docker web 
services on other OSes? 

Yasu




> On Mar 11, 2021, at 09:00, divoplade  wrote:
> 
> Hello,
> 
>> Le jeudi 11 mars 2021 à 08:23 +0900, Yasuaki Kudo a écrit :
>> Does anyone have an insight into mixing different programming
>> language?  Say Visual Basic, Java, Racket, Haskell, etc
> 
> I am aware of 3 different kinds of approaches:
> - writing programs in different languages, with one programming
> language occupying a whole process (so, web services as you say, or
> scripts, or an org-mode file, for instance);
> - extending a "managed" programming language with C or C++ code; in
> theory it could be possible to do the same for two different
> programming languages and link both C interfaces together; this is what
> SWIG (http://swig.org/) does, but using some language in another
> language that way feels a lot like coding in C;
> - using a common virtual machine as the target for the compilation of
> many different languages (like elisp and scheme for guile).
> 

Re: Is there something similar to nix overlays in guix?

[Tobias Geerinckx-Rice]

Hi!

On 2021-03-11 12:05, Adonay Felipe Nogueira via wrote:

I don't know the specifics of the non-free software Nix


Nix is completely Free software, released under the Lesser GNU General 
Public Licence version 2.1.  So is nixpkgs, its official MIT-licenced 
collection of package definitions.  (Guix combines both concepts into 
one repository.)


You might be confusing 'non-free' with 'does not follow GNU's Free 
Software Distribution Guidelines' (FSDG), a much stricter set of 
additional rules that dictate what every single installable package is 
allowed to be and do.


Nix/nixpkgs/NixOS have not opted to follow these unrelated rules; GNU 
Guix have.  Both projects are Free software.


Both must therefore grant you the freedom to run non-free software; Nix 
makes this more convenient.


Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Re: Is there something similar to nix overlays in guix?

[Adonay Felipe Nogueira via]

Em 05/03/2021 16:20, Vinícius dos Santos Oliveira escreveu:
> You don't want to be a slave to upstream developers' decisions and
> want to apply out-of-tree patches that automatically propagate to the
> rest of the packages ecosystem.

I don't know the specifics of the non-free software Nix, but by experience I 
think that one of those might suit your case:

a) the (package (source (origin (patches …) …) …) …) definition, where stuff is 
applied right after being unpacked/extracted, before configuring and building. 
If you are dealing with GNU FSDG issues or things which will be upstreamed, 
this would be the perfect place for the patch since you wouldn't be forcing the 
source package to use Guix's store paths or Guix-specific changes. It also 
means that people who do guix build -S will receive the source with patches 
applied;

b) an invocation of GNU patch from (package (arguments (modify-phases …) …) …), 
allowing you to do as (a) but for Guix-specific changes;

c) use of (package (replacement …) …) to your own package definitions to 
provide grafts (see `info guix "Security Updates" ` for the requirements and 
caveats), but note that, since I don't use this option, I don't know much about 
how to implement it;

d) invoking guix build — or those with support for its transformation options — 
with --with-patches=PACKAGE=FILE, to do it like (a);

e) same as (d), but with --with-grafts=PACKAGE=REPLACEMENT, to do it like (c);

f) same as (d), but with --with-latest=PACKAGE, to force a given 
build/install/upgrade to use the latest known version of PACKAGE instead of the 
one from the built package's definition. This of course comes at a price, as 
can be read on `info guix "Package Transformation Options" `


-- 
* Ativista do software livre
* https://libreplanet.org/wiki/User:Adfeno
* Membro dos grupos avaliadores de
* Software (Free Software Directory)
* Distribuições de sistemas (FreedSoftware)
* Sites (Free JavaScript Action Team)
* Não sou advogado e não fomento os não livres
* Sempre veja o spam/lixo eletrônico do teu e-mail
* Ou coloque todos os recebidos na caixa de entrada
* Sempre assino e-mails com OpenPGP
* Chave pública: vide endereço anterior
* Qualquer outro pode ser fraude
* Se não tens OpenPGP, ignore o anexo "signature.asc"
* Ao enviar anexos
* Docs., planilhas e apresentações: use OpenDocument
* Outros tipos: vide endereço anterior
* Use protocolos de comunicação federadas
* Vide endereço anterior
* Mensagens secretas somente via
* XMPP com OMEMO
* E-mail criptografado e assinado com OpenPGP



signature.asc
Description: OpenPGP digital signature

Re: Booy fails after fresh, successful installation

[Pierre Neidhardt]

The installer does not have the same hardware requirements as the booted
OS, in particular when it comes to graphics.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Asking for clarifications

[Ricardo Wurmus]

Hi Екатерина,

> I presumed that GPLv2 would make the whole product subject to the term of
> this particular license. Still your product is licensed under GPLv3, if I
> am correct?

Individual packages provided by Guix don’t have to be licensed under
compatible licenses.

The source code of Guix is licensed under GPLv3 or later.  The sources
of Linux are indeed under GPLv2.

There is no single license for the whole system, and we don’t claim that
the whole system is licensed under the license under which the sources
of Guix are released.

-- 
Ricardo