Re: Checking for substitutes

[Timothy Sample]

Hi Konrad,

Konrad Hinsen  writes:

> Hi Guix,
>
> I wonder if there is any way to check if substitutes are available for a
> given set of packages (e.g. a single package with its dependencies, or a
> complete manifest).
>
> The context is optimizing package updates: if I know everything I need
> is available as a substitute, I can do an update immediately, but if big
> packages need to be built locally, I prefer to wait until my computer is
> idle.
>
> Ideally, I'd like "guix package" to have an option –only-substitutes
> that will stop if local builds are required, providing a list of the
> packages that must be built.

There’s an old feature request for this:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26608

I looked into it some time ago, and there were a lot of blockers.  See
https://lists.gnu.org/archive/html/guix-devel/2017-06/msg00190.html for
details.

At the end of that thread, I posted a small shell script that scrapes
the most recent fully evaluated commit from the build farm.  That way,
you can update to that commit, and have a much better chance of getting
all substitutes.  To be honest, I only use the script if I see something
like Icecat building.  In that case, I rollback to the latest complete
evaluation.

There’s also the ‘guix weather’ command.  It is supposed to provide info
about available substitutes.  I have not made much of use of it, though.

Hope that helps.


-- Tim

Re: 'libstdc++.so.6' cannot be found in RUNPATH ()

[Timothy Sample]

Hi Hinko,

Hinko Kocevar  writes:

> Hi Ludovic,
>
> Thank you for the insight.
>
> Is there a way to have the check pass by other means (i.e not skip the check)?

One thing you could do is patch the RUNPATH of the library.  You can do
this with the ‘patchelf’ command.  A good starting place might be to
look at the Rust bootstrap package.  It uses ‘patchelf’ to update the
RUNPATH of binaries, and leaves the ‘validate-runpath’ phase in place.

> I will resort to skipping the check as immediate solution.
>
> /hinko

Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Timothy Sample]

Christopher Lemmer Webber  writes:

> Timothy Sample writes:
>
>> Christopher Lemmer Webber  writes:
>>
>>> Likewise, Gregor and Raart do not install:
>>>
>>> [...]
>>
>> This is a timezone issue.  The “tzinfo” package cannot find the
>> “zoneinfo” directory in GuixSD.  If you install the “tzdata” Racket
>> package, things seem to settle down.  (It would be better to tell
>> “tzinfo” to use the system database, but that’s harder to do.)
>
> Oh that's true.  I guess this was multiple issues.  Anyway, horray, that
> one seems ok now!

I’m glad to hear it!

>>> ... install raart, lots of "cannot open output file" error messages ...
>>> [...]
>>
>> I got better results with “raart” when “gcc-toolchain” was available
>> (i.e., “guix environment --ad-hoc gcc-toolchain”).  I guess it has to
>> compile a bit of native code, so it needs a compiler.  It still brakes
>> due to a syntax error, but I get the same error on Debian, so I guess
>> that’s something.  :)
>
> Yep... that seems to have fixed the install of that issue.

Cool!

>> Also, I checked all of this from Racket without grafts, and it never
>> complained about compiling OpenSSL stuff.  Running “raco setup” gives
>> some other errors, though.
>
> You're right... without grafts it doesn't have the openssl error.  The
> other writing to the store issues still seem to persist, but it doesn't
> block running "raco setup" (after a "raco pkg install", a step I had
> omitted earlier).

Okay.  I was confused about the “raco setup” example, but the other step
makes more sense now.

I will say that even on Debian, with an regular user, I have seen
“permission denied” errors because Racket tries to update files in
“/usr/share”.

> ISTM that this is a separate bug.  In fact I'm afraid I've polluted this
> bug with what I thought were all the same bug but turned out to be
> several different bugs, of which a couple are fixed now thanks to your
> help.
>
> PS: About the bounty, my thoughts are that some of these smaller issues
> being resolved are already worth a smaller amount of compensation (and
> thanks!), but there are *two different* larger issues of which probably
> either is worth the full amount (though I can only afford to pay for
> one)... one of them is the issue of the grafts breaking eg openssl
> (which maybe we should file as a separate bug?), and the other is this
> original bug (30680) about the attempts to compile to the store (which
> does not seem as big of a blocker as it did previously, but is still
> very annoying).  Does that seem fair?  (Feel free to contact me
> off-list.)

Actually I think there is only one bug, which is the grafts thing.  This
bug was originally about compiling OpenSSL files to the store.  Grafting
doesn’t break OpenSSL it just makes Racket try to recompile its OpenSSL
FFI wrappers.

I have a patch, too.  I sent it to guix-patches, but I must have made a
mistake because it ended up in bug-guix attached to this bug report.
The patch can be found at <https://debbugs.gnu.org/30680>.  Also, the
attachment didn’t get sent to the list, but did make it to the bug page.
Hm  Sorry for the goof!

Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Timothy Sample]

Christopher Lemmer Webber  writes:

> Konrad Hinsen writes:
>
>> In my tests, all packages ended up working, but performance is indeed
>> worse than with a Racket installation outside of Guix.
>>
>> It would be nice if someone with more knowledge of Racket internals
>> could give a hint or two for debugging this issue!
>>
>> Konrad.
>
> I'm posting a bug bounty on this issue: if someone can fix this I will
> pay them $250 USD.  I don't have the time or knowledge enough of Racket
> internals to do so myself.

I have discovered a few things, but I’m not sure how to fix the
underlying problem(s).

The reason Racket is trying to recompile the OpenSSL files is because of
a hash mismatch.  This can be seen by enabling debugging output:

$ PLTSTDERR=debug raco setup openssl

Which says a lot of things, but most interestingly it says:


...
compiler/cm: checking: 
/gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 
4d21ac412723fbf33f97669c2f73f0e9367f4510)
compiler/cm: maybe-compile-zo starting 
/gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
compiler/cm:   start-compile: 
/gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
compiler/cm:   compiling 
/gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
open-output-file: cannot open output file
  path: 
/gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570
  system error: Read-only file system; errno=30
  context...:
...


This hash mismatch is caused by grafting.  When the package is built,
the path to OpenSSL gets hard-coded in a source file.  The SHA-1 hash
for this file is stored in its “.dep” file.  When the output is grafted,
the source file gets updated with a new OpenSSL path, but the hash does
not get updated.  This makes Racket think that the cached bytecode file
is incorrect (even though it was likely grafted too), and it tries to
recompile it.  It fails because it tries to write this new bytecode file
to the store.

I double checked this by trying with an ungrafted Racket, and got better
results.  (There was still a warning about writing to the store, but it
seemed less significant.)

The only thing I can think of for a fix would be to patch Racket to be
more lenient with bytecode files in the store.  That is, ignore hash
mismatches in store-files.  I might give this a try later tonight if
nobody has any better ideas.


-- Tim

Re: Lock screen gnome

[Timothy Sample]

Hi Ludo and Gábor,

Gábor Boskovits  writes:

> Hello,
>
> Ludovic Courtès  ezt írta (időpont: 2018. dec. 19., Sze, 14:53):
>>
>> Hi Timothy,
>>
>> Timothy Sample  skribis:
>>
>> > Someday I would like to return to fixing GDM, but I am a bit
>> > traumatized.  It is a very slow and frustrating package to debug.
>> >
>> > 1. https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00268.html
>> >https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00231.html
>>
>> I would love to have GDM fixed for 1.0 though, because this GNOME
>> screen-locking issue, among other things, is really problematic.
>>
>> Is there anything we can do to help or otherwise provide motivation?
>> :-)
>>
>> Thanks,
>> Ludo’.
>>
>
> Yes, I also believe we need this. Along with the screen-locking
> multi-monitor support and i18n support comes to mind.
>
> If we can help in any way, please feel free to contact us.
>
> Thanks,
> g_bor

The way I was testing it was by running it in a VM.  This made testing
any little idea take way too long.  It would be nice to have a faster
way of testing it.  If anyone has any experience running a nested
instance of GDM, being able to do that would be a big help.  (The trade
off is that figuring that out might be just as hard as fixing GDM in the
first place.)

Other than that, I agree that this is a critical feature.  GNOME needs
GDM to work smoothly, and GNOME is pretty important for wider adoption.
I am happy to take another look at this (eventually!), but I do not have
any particular expertise here, so if anyone else is feeling brave, they
would have just as good a chance at fixing it as me.  :)


-- Tim

Re: Lock screen gnome

[Timothy Sample]

Hi Peter,

"Peter Baumgarten"  writes:

> I just installed guixsd with gnome, but I can not lock the screen when
> hit the meta key + L
>
> Is there anything extra I need to do add this functionality below is
> the config.scm I am using

AFAIK, the lock screen requires GDM, which currently does not work on
GuixSD [1].  For now, I use xlock to lock my screen.  If I want to lock
and suspend, I use the following rather unglamorous command:

$ xlock & (sleep 3; loginctl suspend)

If anyone has any better advice, I would love to hear it!

Someday I would like to return to fixing GDM, but I am a bit
traumatized.  It is a very slow and frustrating package to debug.

1. https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00268.html
   https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00231.html

> [...]


-- Tim

Re: Removing prop-inputs

[Timothy Sample]

Hi brettg,

bre...@posteo.net writes:

> On 12.01.2019 02:25, bre...@posteo.net wrote:
>> Hi all, this is my system configuration file. I am trying to remove
>> nautilus and epiphany from the gnome-desktop-service that gets loaded.
>> So far I am not having any luck. Any ideas?
>>
>> [...]
>
> Update, I got it to work, but with some very hackish code. Any
> suggestions would still be appreciated.
>
> (define-public gnome-custom
>   (package (inherit gnome)
>  (name "gnome-custom")
>  (propagated-inputs (remove
>   (match-lambda
> ((name _)
>  (string=? name "epiphany")))
>   (remove
>(match-lambda
>  ((name _)
>   (string=? name "eog")))
>(remove
> (match-lambda
>   ((name _)
>(string=? name "totem")))
> (remove
>  (match-lambda
>((name _)
> (string=? name "gedit")))
>  (remove
>   (match-lambda
> ((name _)
>  (string=? name "yelp")))
>   (remove
>(match-lambda
>  ((name _)
>   (string=? name "gnome-calculator")))
>(package-propagated-inputs gnome))

You could try

(remove (match-lambda
  ((name _)
   (member name '("epiphany" "eog" ...
(package-propagated-inputs gnome))

Hope that helps!


-- Tim

Re: Help with writing custom boot-loader configuration

[Timothy Sample]

Hi Raghav,

Raghav Gururajan  writes:

> On Thu, 2019-05-30 at 10:11 +, Raghav Gururajan wrote:
>> Hello Guix!
>> 
>> If I want to make the "grub-bootloader" to invoke ONLY
>> "grub-mkconfig" and NOT "grub-install", how should I modify the
>> "bootloader" part of "operating-system" section of system
>> configuration (config.scm)? I am looking for exact Guile Scheme Code
>> to achieve the same.
>> 
>> Thank you!
>> 
>> Regards,
>> RG.
>
> Hello Ludo and Rekado!
>
> May be with your expertise in Guile Scheme, can you please help me with the
> above?

Putting together “exact Guile Scheme Code” is a lot to ask, but I can
give you the following.  You will have to adjust it appropriately if,
for example, you are not using EFI.  Note also that this is untested,
but it is certainly close.

What you want to do is create a custom bootloader that behaves just like
GRUB except for the “installer”.  In Guix, each bootloader is defined by
a “bootloader” record.  Part of that record is an “installer” field,
which tells Guix how to install the bootloader onto the system.

In addition to whatever else you use for your config file, you will need
the following modules:

(use-modules (gnu)
 (guix gexp))

Now you can make your custom bootloader:

(define grub-efi-bootloader-sans-install
  (bootloader
   (inherit grub-efi-bootloader)
   (installer #~(const #t

Here, “(const #t)” tells Guile to create a function that always returns
“#t”, which means “true”.  The “#~” part introduces a G-expression,
which is a handy way to write code that is intended to be run from the
build environment.

Finally, this should work as part of your configuration:

(operating-system
  ;; ...
  (bootloader (bootloader-configuration
   ;; ...
   (bootloader grub-efi-bootloader-sans-install))

That is, you need to change your “bootloader-configuration” to use your
new custom bootloader.

I hope that helps!


-- Tim

Re: Help with writing custom boot-loader configuration

[Timothy Sample]

Hi Raghav,

Raghav Gururajan  writes:

>> 
>> My first thought after reading your question was 
>> . 
>
> Yes, I was looking for a method other than using (const ~#t).

Heh.  I didn’t see this before.  Sorry for sending you code you already
had!

>> However, I guess you need something else, but I'm not sure what it is. Can 
>> you explain more what you're trying to do? Thanks!
>
> I was looking for a way to directly alter the behaviour of grub-installer. The
> two of all functions of grub-installer are "grub-install" and "grub-mkconfig".
> The former install grub binaries on disk and the latter generates grub
> configuration file inside root partition under boot directory. I was thinking 
> if
> there is a straight-forward way to make the grub-installer to invoke ONLY 
> "grub-
> mkconfig" and NOT "grub-install"??

I’m not quite sure what you are asking, since Guix does not use
“grub-mkconfig”.  It has its own way of generating a GRUB configuration
file.  The “#~(const #t)” trick is the Guix version of running
“grub-mkconfig” and not “grub-install”.  Is it working for you?

Is it that you want to use “grub-mkconfig” instead of Guix’s normal
method?  To be honest, it may be possible, but it’s only for the brave
of heart (or at least for those who can tolerate a lot of annoying
difficulties).  :)  The easiest way to do that would be to install GRUB
and run “grub-mkconfig” manually.


-- Tim

Re: GNOME no thumbnails?

[Timothy Sample]

Hi nightowl,

nightowl  writes:

> Does anyone have a problem getting jpg and png picture files to have
> thumbnail previews shown in the file browser (nautilus)?  My instance
> of GNOME does not appear to be generaterating the thumbnail images.

I am seeing this too.  It looks like it may have started after updating
GNOME to 3.28, since some of my older files have thumbnails.


-- Tim

Re: Any questions yet

[Timothy Sample]

Hi Jone,

Jone  writes:

> Hello, people! I don't even know exactly what I would like to ask))
> Well, for example: two calls "guix pull" as root and as user - what
> does the first if the root has 0 packages (besides guix itself,
> right?) But how is this related in the future? I still do not
> understand what I do not understand))

I guess I don’t know exactly what I’m answering, then, but I’ll do my
best!  :)

Running “guix pull” updates Guix the program which also means updating
the list of package definitions.  It does not affect your current
packages – only Guix itself.  This means that it does not matter if you
have 0 packages or 100.

Technically speaking, you usually have (at least) two profiles per user.
One is the “user” profile, and it contains all of the packages you’ve
added either using “guix install” or through a manifest.  The other is
profile that “guix pull” uses.  It only includes a special up-to-date
Guix packages (with all of its dependencies).  Usually, the “user”
profile is linked to from “~/.guix-profile”, and the “guix pull” profile
is linked to from “~/.configure/guix/current”.

If you really want to understand these profiles, the manual is your best
bet.  For the “user” profile, see “(guix) Invoking guix package”.  For
the “guix pull” profile, see “(guix) Invoking guix pull”.  Here are
links to these sections on the Web:







> I know Scheme/Guile only at the level of a ordinary user, so I ask
> such stupid questions, sorry. And English is so-so)) But I love
> freedom! Thanks.
>
> Yes, and also: I wrote a couple of package definitions for several
> XFCE plugins that are not in the repositories. Is it impossible to
> send somewhere? True, the versions is old..

It is possible!  You should update them first, if you can.  Then, you
can send them to us as patches via email.  It may take some time, but
eventually a friendly reviewer will look at your patches, maybe provide
some suggestions on how to improve them, and finally apply them to Guix.
Again, the Guix manual has a good guide to everything you need to know
to do this.  See “(guix) Contributing”, which is on the Web at the
following address:




Particularly, check out the last section called “Submitting Patches”.

Hope that helps!


-- Tim

Re: Should %base-services be included by default in the OS configuration generated by the installer?

[Timothy Sample]

Hi sirgazil,

sirgazil  writes:

> Hi,
>
> The Guix System 1.0.0 installer has a bug that makes it generate
> operating system configuration files that don't include the
> %base-packages
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35541). The
> configuration file of the system I installed was initially generated
> by the installer, so I had to add the base packages by hand. Now, I'm
> reading the Services section in the manual and I see that there is a
> %base-services variable. My configuration file does not include
> this. Should one expect the configuration file generated by the
> installer to include these services too?

Does your configuration have “%desktop-services” instead?  The
“%desktop-services” list includes everything from “%base-services”.


-- Tim

Re: GNOME Desktop

[Timothy Sample]

Hi,

"pelzflorian (Florian Pelz)"  writes:

> On Sun, May 05, 2019 at 10:13:38PM +0200, Ricardo Wurmus wrote:
>> pelzflorian (Florian Pelz)  writes:
>> > You can type in the terminal:
>> >
>> > guix install gnome-calendar
>> >
>> > This should become part of guix’ gnome package.  That it is missing is
>> > a bug.
>> 
>> Is it really?  I do like that we can choose to install only the
>> essential parts of GNOME without having to install packages that we may
>> not need.
>> 
>> Perhaps this could remain configurable.
>>
>
> In this case, maybe there should be a gnome-minimal package.
> Personally, I don’t like epiphany and use my own gnome package
> propagating the same packages but without epiphany.

I agree.  It would be nice to have an minimal package and
bells-and-whistles package.

While checking some things for GNOME 3.30, I (inadvertently) made a list
of all the “core” GNOME software that we are missing.  I thought I would
post it here just for the record.  I don’t know what all of these are,
but some of them look ripe for packaging.  :)

gnome-boxes
gnome-characters
gnome-color-manager
gnome-contacts
gnome-documents
gnome-font-viewer
gnome-getting-started-docs
gnome-initial-setup
gnome-logs
gnome-menus
gnome-music
gnome-online-miners
gnome-photos
gnome-software
gnome-themes-extra
gnome-user-docs
gnome-user-share
gnome-weather
gssdp
gupnp
gupnp-av
gupnp-dlna
gupnp-igd
libgepub
libgovirt
libgrss
libmediaart
mm-common
mousetweaks
phodav
rygel
sushi
tracker-miners
vino


-- Tim

Re: Customize PAM configuration

[Timothy Sample]

Hi Jone,

Jone  writes:

> Hello! I want enter user/root password only once per session. To do this,
> it will probably be convenient to export the password to shell variable.
> For example, adding this to PAM configuration file:
>
>auth sufficient pam_exec.so expose_authtok /path/to/script.sh
>
> But how to write it in system-config.scm? Sorry, I couldn't find any examples.

I don’t fully understand what you are trying to do, but here’s your
example translated into Guix:

(operating-system
  ...
  (pam-services (append (list (pam-service
   (name "my-pam-service") ; or whatever
   (auth (list (pam-entry
(control "sufficient")
(module "pam_exec.so")
(arguments
 (list "expose_authok"
   "/path/to/script.sh")))
(base-pam-services

Note that the “arguments” field of “pam-entry” takes G-Expressions.
This means that the script you want to execute could be a Guile script
built using “program-file”.  Alternatively, it could be a shell script
built using “computed-file” or some script that is outside of the store
using an absolute path.

Hope that helps!


-- Tim

Re: Help defining a trivial package.

[Timothy Sample]

Hi Pierre,

"Pierre-Henry F."  writes:

> Would someone help defining a trivial package?

Sure!

> Here is an attempt at defining the package (incomplete, does not work) in 
> blog.scm:
>
> (define-module (blog)
>   #:use-module (guix packages)
>   #:use-module (guix download)
>   #:use-module (guix build-system trivial)
>   #:use-module (guix licenses)
>   #:use-module (gnu packages python))
>
> (define-public blog
>   (package
> (name "blog")
> (version "3")
> (source
>   (origin
> (method url-fetch)
> (uri (string-append "/home/phf/programs/blog/release_" version 
> ".tar.lz"))
> (sha256
>   (base32
> "1y819b53ksyas6asldysr0r8p73n5i8ipbpmbgjrfx8qz8cy2zsx"
> (build-system trivial-build-system)
> (arguments
>   '(#:builder #~(begin
>   (mkdir #$output)
>   (chdir #$output)
>   ...
>   )))
> (inputs `(("python" ,python)))
> (synopsis "Guix 'hello world' to learn about Guix")
> (license gpl3+)))
>
> Here is the line that I use to try to build and debug along the way:
>
> $ guix build --keep-failed --verbosity=2 --file=./blog.scm
>

As a note for the future, it would be helpful to include the error
message that you saw when things went wrong.  Here, I’m assuming that
Guix said:

guix build: error: #: not something we can build

Running “guix build --file=X” causes Guix to build the last expression
evaluated in the file “X”.  In your case, the last expression that gets
evaluated is the “define-public” form, which returns an unspecified
value.

While testing, you can put “blog” at the bottom of the file, causing
Guix to build your defined “blog” package.

Hope that helps!


-- Tim

Re: Help defining a trivial package.

[Timothy Sample]

Hello,

"Pierre-Henry F."  writes:
>
> Hello Tim !
>
> I'm using a couple of hours here an there to try to rebuild the package you 
> gave me (Thank you for that :-) ).
> So far, I've built a very stupid but "working" package (see below if you 
> really want to ;-) ).

Looks good so far!

> Will answer on the mailing list for others to benefit from this exchange.

I’ve added the mailing list back in, then.  ;)

> Needless to say, it's not exactly obvious to figure these things out /a 
> priori/.

For sure.  By using the trivial build system, you’re working at a pretty
low level.  It’s especially tough to learn both Guix and Guile at the
same time.  For your reference, here’s a sketch of what the “#:builder”
code would look like if it were Python:

import os, shutil, stat, subprocess, guix.build.utils

# Unpack
source = _build_inputs["source"]
tar = _build_inputs["tar"]
lzip = _build_inputs["lzip"]
os.putenv("PATH", ":".join([tar + "/bin", lzip + "/bin"]))
subprocess.run(["tar", "--lzip", "-xvf", source])

# Configure
bash = _build_inputs["bash"]
python = _build_inputs["python"]
guix.build.utils.substitute("blog/bin/program",
[["/usr/bin/bash", bash + "/bin/bash"],
 ["python3", python + "/bin/python3"]])

# Install
out = _outputs["out"]
os.chmod("blog/bin/program", 0o755)
shutil.copytree("blog", out)

Here, “_build_inputs” and “_outputs” are set by Guix, and are
dictionaries.  For “_build_inputs”, the keys are the strings you put in
the “inputs” part of the package, and the values are the paths where the
packages are installed.  So, “_build_inputs["python"]” points to the
directory in the store where Python is installed.  We usually only have
one output, which is called “out”.  This is the path in the store where
we install the package being built.

The only other thing is that “guix.build.utils.substitute” is basically
just find-and-replace.  It takes the name of a file and a list of
two-element lists and replaces all the occurrences of the first elements
in the file with their corresponding second elements.

Obviously the Guile interfaces are a little different, but hopefully
this Rosetta Stone makes it easier to see what’s going on.

As an aside, ever since I learned that there’s a way to do quasiquotes
in Python [1], I’ve wondered how strange it would be if Guix were
written in Python.  Pretty strange!  :)

[1] https://macropy3.readthedocs.io/en/latest/reference.html#quasiquote

> Anyway, thanks!

You’re welcome!


-- Tim

Re: Help defining a trivial package.

[Timothy Sample]

Hi Pierre,

"Pierre-Henry F."  writes:

> So, we have, in ~bash~:
>
>   $ lzip --decompress release_3.tar.lz
>   $ tar xf release_3.tar
>   $ cd blog/ # coming from the preceding line.
>   $ tree
>   .
>   ├── bin
>   │   └── program
>   └── src
>   └── hello_world.py
>
>   $ cat src/hello_world.py
>   print("Hello world!")
>
>   $ cat bin/program
>   #! /usr/bin/env bash
>
>   script_path="${BASH_SOURCE[0]}"
>   script_dir="$(dirname $script_path)"
>   python3 "$script_dir/../src/hello_world.py"
>
> That's it.
>
> The idea is to build a Guix package that does exactly that.
> Expected outcome:
>
>   $ guix package -s blog
>   # fetch release_3.tar.lz
>   # uncompress ...
>   # ...
>
>   $ program
>   Hello World!
>
>
> My question: how to build that Guix package?  I try to get something working 
> using
> the docs.  This is how the package looks to far:
>
>   (use-modules
> (guix packages)
> (guix download)
> (guix build-system trivial)
> (guix licenses)
> (guix gexp)
> (gnu packages base)
> (gnu packages python))
>
>
>   ;; The "derivation" i.e. low level sequence of instructions that the build 
> deamon is
>   ;; supposed to execute on the behalf of the user.
>   (define build-drv
> (gexp->derivation
>   "the-thing"
>   #~(begin
>   (mkdir #$output)
>   (chdir #$output)
>   (symlink (string-append #$coreutils "/bin/ls")
> "list-files"
>
>
>   (package
> (name "blog")
> (version "3")
> (source
>   (origin
> (method url-fetch)
> (uri (string-append "/home/phf/programs/blog/releases/release_" 
> version ".tar.lz"))
> (sha256
>   (base32
> "1y819b53ksyas6asldysr0r8p73n5i8ipbpmbgjrfx8qz8cy2zsx"
> (build-system trivial-build-system)
> (arguments `(#:builder ,build-drv))
>
> (inputs `(("python" ,python)))
> (synopsis "Guix 'hello world' to learn about Guix")
> (description "Guess what GNU Hello prints!")
> (home-page "http://www.gnu.org/software/hello/;)
> (license gpl3+))
>
> Assuming everything else is correct, would you please help refine ~build-drv~ 
> until
> it matches the ~bash~ above ?
>
> This is what the execution trace looks like:
>
>   phf@f02c:~/tools/guix/packages$ guix build --keep-failed --verbosity=2 
> --file=./blog.scm
>   substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>   building /gnu/store/8b0gyazhgmc9rkrxir7vxpav0x28xk3d-blog-3.drv...
>   ERROR: In procedure primitive-load:
>   In procedure scm_lreadr: 
> /gnu/store/zlbf2x6n4084v0cpw2rh9dydqmi5b2rn-blog-3-guile-builder:1:10: 
> Unknown # object: #\<

This error is because you can’t pass a derivation object as the
“#:builder” argument.  It has to be some quoted Scheme code that can run
in the build environment.

I took a little time and wrote a package definition that matches your
example.  There are some things you could do to change your source code
to make it more in-line with what Guix expects, but I didn’t do that.  I
hope that an example dealing with what you have will be more helpful.

I’ve attached the package definition I came up with (note that I changed
the URL of the tarball).

(use-modules ((gnu packages base) #:select (tar))
 ((gnu packages bash) #:select (bash-minimal))
 ((gnu packages compression) #:select (lzip))
 ((gnu packages python) #:select (python))
 (guix)
 (guix build-system trivial))

(package
  (name "blog")
  (version "3")
  (source
   (origin
 (method url-fetch)
 (uri (string-append "file:///tmp/phf/release_" version ".tar.lz"))
 (sha256
  (base32
   "1y819b53ksyas6asldysr0r8p73n5i8ipbpmbgjrfx8qz8cy2zsx"
  (build-system trivial-build-system)
  (arguments
   `(#:modules ((guix build utils))
 #:builder
 (begin
   (use-modules (guix build utils))
   ;; Unpack
   (let ((source (assoc-ref %build-inputs "source"))
 (tar (assoc-ref %build-inputs "tar"))
 (lzip (assoc-ref %build-inputs "lzip")))
 (setenv "PATH" (string-append tar "/bin"
   ":" lzip "/bin"))
 (invoke "tar" "--lzip" "-xvf" source))
   ;; Configure
   (let ((bash (assoc-ref %build-inputs "bash"))
 (python (assoc-ref %build-inputs "python")))
 (substitute* "blog/bin/program"
   (("/usr/bin/env bash") (string-append bash "/bin/bash"))
   (("python3") (string-append python "/bin/python3"
   ;; Install
   (let ((out (assoc-ref %outputs "out")))
 (chmod "blog/bin/program" #o775)
 (copy-recursively "blog" out)
  (inputs
   `(("bash" ,bash-minimal)
 ("python" ,python)))
  (native-inputs
   `(("lzip" ,lzip)
 ("tar" ,tar)))
  (synopsis #f)
  (description #f)
  (home-page #f)
  (license #f))

The builder code imports the “(guix build utils)” module, which has some
really handy shell-like functions like 

Re: Setting environment variables in Gnome session

[Timothy Sample]

Hi Jonathan,

Jonathan Frederickson  writes:

> On Wed, Aug 28, 2019 at 8:40 PM, Timothy Sample 
> wrote:
>> If you use GDM and GNOME, and have Bash as your shell, you need to set
>> the variables in “~/.bash_profile” or “~/.bashrc”.  Guix System sets
>> up
>> GDM to run your X session from the your login shell (which I’m
>> assuming
>> is Bash).  Since Guix System provides a “~/.bash_profile” file by
>> default, Bash will read this and skip “~/.profile”.
>>
>> So if you set the variables in a Bash-specific file it should work.
>>
>>
>> -- Tim
>
> Thanks, but the environment variable I'm looking to set needs to apply
> to Gnome itself rather than my terminal shell. It's the search path
> that Gnome uses to find XDG application files. I believe
> ~/.bash_profile is only read by bash specifically?

Yes.  Because Bash is your login shell, it gets invoked as part of
spawning your X session.  Because of this, Bash-specific configuration
files affect your X session’s environment.

> (I've just tried adding the relevant env var to ~/.bash_profile in any
> case, but it doesn't seem to have affected gnome-shell's environment.)

In my “~/.bash_profile”, I wrote

export PROFILE_MESSAGE=HI

Then, I logged out of GNOME and logged back in to GNOME.  After that, I
opened a program – not a terminal :) – from GNOME Shell and confirmed
that it sees that “PROFILE_MESSAGE” is set to “HI”.

Did you log out and in again?


-- Tim

Re: Setting environment variables in Gnome session

[Timothy Sample]

Hi Jonathan,

Jonathan Frederickson  writes:

> I'm trying to install some software through Flatpak alongside software
> installed through Guix (on a Guix System install) and I'm running into
> what feels like it should be a minor issue. On other distros (including
> my desktop where I'm running Guix as a foreign package manager), I
> would modify XDG_DATA_DIRS in $HOME/.profile to accomplish this.
>
> However, my Gnome session in Guix System seems to ignore this file. 
> I've tried creating a file in my home directory in /etc/profile like
> so, and as far as I can tell it's never getting run:
>
> export XDG_DATA_DIRS=$XDG_DATA_DIRS:/var/lib/flatpak/exports/share
> echo "hi there!" > $HOME/test.txt
>
> Is there a preferred way to set environment variables in a graphical
> session?

If you use GDM and GNOME, and have Bash as your shell, you need to set
the variables in “~/.bash_profile” or “~/.bashrc”.  Guix System sets up
GDM to run your X session from the your login shell (which I’m assuming
is Bash).  Since Guix System provides a “~/.bash_profile” file by
default, Bash will read this and skip “~/.profile”.

So if you set the variables in a Bash-specific file it should work.


-- Tim

Re: Help defining a trivial package.

[Timothy Sample]

Hello!

I’m glad the Python code was helpful.  :)  I’ve commented on some of
your other points below.

"Pierre-Henry F."  writes:

> Development:
>
> $ guix environment --manifest=./guix/manifest.scm --pure --container
> $ # Develop things. Add dependencies at will in manifest.scm
>
>
> Build release:
>
> $ ./deployment/make_release
> Built release: release_4.tar.lz
>
>
> Deployment:
>
> $ guix build --keep-failed --verbosity=2 --file=./blog.scm
> …
> /gnu/store/…-blog-4
>
>
> Test:
>
> $ /gnu/store/…-blog-4/bin/program
> Hello world!
>
>
> What would be very helpful:
>
> - Define blog.scm such that ~$ guix environment blog~ has the same effect 
> as
>   ~$ guix environment --manifest=./guix/manifest.scm --pure --container~

This really depends on what’s in “manifest.scm”.  If it contains tools
for building the blog, it would be same, but I take it that
“manifest.scm” has tools for hacking on the blog, too (like editors or
whatever).  In this case, it’s actually a feature that they’re separate.
It keeps the build and runtime time dependencies apart from the
development dependencies.  You can always combine the two, so that
“manifest.scm” only has to contain the extra stuff:

guix environment --pure --container \
-l blog.scm --ad-hoc -m manifest.scm

This will pull in all the build and runtime dependencies of the package
defined in “blog.scm” plus all the extra tools from “manifest.scm”.

> - Define a package ~blog_executable.scm~ derived from ~blog.scm~ such that
>   ~$ guix package -i blog_executable~ has the same effect has
>   ~$ guix build --file=./blog_v2.scm~, but actually install the thing.
>
>   ~blog_executable.scm~ is essentially ~blog.scm~ but stripped down to 
> the bare
>   minimum to get the executable working.

This is definitely possible.  All you need to do is make sure that the
package defined in “blog_executable.scm” has its source field set
properly.  What I’ve done in the past is use Guile-Git to use all of the
files that Git knows about as the source of the package.  This makes
sure transient build artifacts are not included (since they are likely
ignored by Git).  If you like, take a look at this file:

https://git.savannah.nongnu.org/cgit/gash.git/tree/guix.scm

It is the main Guix package definition that I use when developing Gash
(a shell written in Guile that I maintain).  If you clone the repo, you
can run “guix package -f guix.scm” to build and install Gash from the
latest Git sources (the ones you just cloned).  There are two things to
note, though.  First, if you use it for testing the build, it can get
confusing as to which files are included: is it files in the working
tree, files in the index, or files from the latest commit?  I honestly
get confused and miss things all the time!  The second thing is that
since I wrote that package definition, Guix got a procedure called
“git-predicate” in “(guix git-download)” that does basically the same
thing as my “make-select”.  I recommend using the Guix procedure if
possible, I just haven’t looked into it yet.  :)

> If all the above is true then I hope that we (multiple devs) can have the 
> guarantee
> to have the same dev environment and a simple deployment build that's just the
> development environment minus dev dependencies.
>
> With these things in place, a deployment should be deterministic and as 
> simple as a:
>
> $ guix package -i blog_executable
>
>
> To sum up, here are the questions I try to answer:
>
> - How to define ~blog.scm~ such that ~$ guix environment blog~ works?
> - How to define ~blog_executable.scm~ such that ~$ guix package -i 
> blog_executable~ works?

I hope what I wrote above helps answer these questions!


-- Tim

Re: How to make sure ghc uses installed packages?

[Timothy Sample]

Hi,

John Soo  writes:

> One other problem I can think of is that the current ghc is 8.6 but most
> ghc-* packages are built with 8.4 so most packages are incompatible with
> the default.

I’ve seen a number of bug reports and questions about this.  Maybe we
should rename GHC 8.6 to “ghc-next” until the build system uses it.

Thoughts?


-- Tim

Re: Problem with Guix install with openbox

[Timothy Sample]

Hi Alex,

Alexander Asteroth  writes:

> Dear Timothy,
>
> Thank you for the hint. Unfortunately “~/.config/openbox/menu.xml”
> does not exists and "find ~/.config -name openbox” does not yield any
> result.

I would guess that Openbox has a default menu somewhere, and if you copy
that to “~/.config/openbox/menu.xml”, you will be able to use it to
change the menu you see.  You can probably find it by running
“guix build openbox” and looking around it the directory that gets
printed as output.  For example, when I run “guix build openbox”, Guix
prints “/gnu/store/9cayp0c39v8xnwwhai0jgp0rd56arai4-openbox-3.6.1” (you
might get something different if we are running different versions of
Guix).  In that folder, there is a file, “./etc/xdg/openbox/menu.xml”,
which is the default menu.  Copy it to “~/.config/openbox/menu.xml”, and
then you will be able to edit the menu.  I’m sorry I can’t be more
helpful, but I haven’t used Openbox for a few years, and I’ve never used
it on Guix.

> Also my ~/.guix-profile/bin is very unpopulated. Also at command line
> prompt I don’t have emacs. Shouldn’d this be installed by the install
> process?

If you run “guix install emacs”, Guix will install Emacs into your user
profile, which gets linked from “~/.guix-profile”.  It’s not installed
by default.

> W.r.t. how I “installed” lxde (just by guix install lxde). Do I need
> to reconfigure every time I install something?

Only for “system” stuff.  If you want to change things like which
daemons are running you need to reconfigure.

The reason I asked is that I wanted to know if LXDE was in your user
profile or in the system profile.  Do you use GDM?  If so, you’ll need
to add LXDE to your system profile for GDM to find it and provide it as
an option when logging in.

To do so, you need to edit your operating system configuration file.
First, you need to use the “lxde” module so that Guile knows where to
find the “lxde” package:

(use-modules (gnu packages lxde))

Then, you can add “lxde” to your other system packages:

(operating-system
  ...
  (packages (cons* lxde
   ...
   %base-packages))
  ...)

After this, you will need to reconfigure.

I’m not an LXDE user either, but if I wanted to become one, that’s what
I’d do.

Hope that helps!


-- Tim

Re: Problem with Guix install with openbox

[Timothy Sample]

Hi Alexander,

Alexander Asteroth  writes:

> Hi there,
>
> As a former Guile programmer I like the idea to configure my system using 
> guile.
> I installed Guix in a vm (VmwareFusion I have to admit) and everything
> worked fine.
> I used the graphical installer and chose Openbox as a Windowmanager-Option.
> Unfortunately after Installation the desktop is empty and right-click
> menu contains only dead links.

The last time I looked at our Openbox package, I noticed that it uses a
default menu configuration.  That means it has links to stuff like
Firefox, even though we don’t have a Firefox package.

You will have to edit the Openbox menu configuration to point to
programs that you have in your profile.  If memory serves, it’s at
“~/.config/openbox/menu.xml”.  There, you can tell it how to launch
programs, so you could fix the “emacs” entry to point to
“~/.guix-profile/bin/emacs”, for example.  :)

You will have to get started from the console, because Openbox will not
know how to open any terminal emulators.

> I also tride installing lxde afterwards with no options effect. 
> Any hint what I can do to solve the issue?
> Thanks! 

Unfortunately, I don’t know about LXDE.  Just to be sure, how did you
“install” LXDE?  Did you include it in your operating system
configuration and then run “guix system reconfigure config.scm”?


-- Tim

Re: core-updates call for testing

[Timothy Sample]

Hi Marius,

Marius Bakke  writes:

> The "core-updates" branch is ready for testing!  [...]
>
> Please try upgrading your profiles and systems and file bugs for
> anything that does not work for you.  GNOME users in particular are
> encouraged to try the new GNOME 3.34 and report any regressions.

Just so you know, GNOME 3.34 is working swimmingly for me.  So far I am
a very happy core-updates user.  Thank you very much for all your hard
work!


-- Tim

Re: How do I build a derivation with guix build?

[Timothy Sample]

Hi divoplade,

As I understand it, ‘gexp->derivation’ returns a value in the store
monad.  I’m not sure why ‘guix build’ doesn’t know how to use it
directly, but you can get at the derivation by wrapping it with
‘run-with-store’:

(run-with-store (open-connection)
  (gexp->derivation "the-thing" build-exp))

Don’t forget to use the ‘(guix store)’ module for this.

But!  There’s a better way!!  :)

You can use the “declarative interface”.  Just replace
‘gexp->derivation’ with ‘computed-file’:

(computed-file "the-thing" build-exp)

Now there’s no need for ‘(guix store)’.

HTH!


-- Tim

divoplade  writes:

> Hello,
>
> I am still learning how to use gexps, and I thought that running this
> would work:
>
> guix build -f example.scm
>
> with example.scm containing:
>
> (use-modules (gnu packages base))
> (use-modules (guix gexp))
>
> (define build-exp
>   #~(begin
>   (mkdir #$output)
>   (chdir #$output)
>   (symlink (string-append #$coreutils "/bin/ls")
>"list-files")))
>
> (gexp->derivation "the-thing" build-exp)
>
> This is a copy of what's on the manual for explaining G-expressions.
>
> The guix build -f command should, according to the --help output:
> "build the package or derivation that the code within FILE evaluates
> to"
>
> However, I get an exception, "Wrong number of arguments to # 7f775f854f00 at guix/gexp.scm:1064:2 (state)>", after a backtrace that
> does not even contains example.scm.
>
> What is going on? How do you build the derivation?
>
> Best regards,
>
> divoplade

Re: Using Haskell library packages - linker error

[Timothy Sample]

Jakub Kądziołka  writes:

> On Mon, Sep 07, 2020 at 09:50:51AM -0400, Timothy Sample wrote:
>
>> GHC needs a special flag to link shared libraries.  We recently starting
>> building shared libraries for our Haskell packages.  The static ones are
>> still being built, but they go to a separate output.  I think you can
>> fix your problem in one of two ways:
>> 
>> 1. Pass the “-dynamic” flag to GHC (and maybe “-fPIC”);
>> 2. Use “ghc-ieee754:static”.
>
> ghc-ieee754:static doesn't seem to exist, [...]

Right.  It does exist, but it’s hidden from the Guix UI.  This is a
result of the finicky way the output is added.

> [...] but passing -dynamic does indeed work. The workaround also
> translates to Agda, with
>
> $ agda --ghc-flag=-dynamic --compile hello-world.agda

Cool.  That’s good to know.

> I'd really rather this wasn't necessary, though. I can already imagine
> having to figure out how to pass this flag to agda through build systems
> and editor plugins.

Absolutely.  I’ve done some of that work on our more complicated Haskell
packages, and it can get a little tricky.  To be honest, I’m not sure
how to move forward.  I know that Arch takes a similar approach to
packaging Haskell libraries, but I don’t know how they manage the
experience.

> On a related note, shouldn't it be possible to use agda without
> specifying ghc (and transitively, gcc) in your profile?

AIUI, this is following GCC.  GCC by itself doesn’t know how to find the
assembler, but the “gcc-toolchain” package manages this automatically.
Similarly, GHC doesn’t know how to find GCC, and Agda doesn’t know how
to find GHC.  We might need to make “ghc-toolchain” and “agda-toolchain”
packages (this has sorta been discussed before [1, 2]).

At the end of the day, our Haskell ecosystem is in need of some more
attention.  It’s really not far away from being nice, but it needs some
gentle nudges here and there.


-- Tim

[1] https://lists.gnu.org/archive/html/guix-devel/2018-08/msg00175.html
[2] https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00318.html

Re: Using Haskell library packages - linker error

[Timothy Sample]

Hi Jakub,

Jakub Kądziołka  writes:

> I am trying to set up Agda, and I have reduced it to a simpler problem:
>
> $ cat test.hs
> import Numeric.IEEE
>
> main = return ()
> $ genv --pure --ad-hoc ghc@8.6 ghc-ieee754 gcc-toolchain
> % ghc test.hs
> Linking test ...
> ld: cannot find -lHSieee754-0.8.0-IfCS1Dp7pQVIOQRslM6kD
> collect2: error: ld returned 1 exit status
> `gcc' failed in phase `Linker'. (Exit code: 1)
>
> How can I fix this error? Am I doing something wrong, or is this a
> packaging bug?

GHC needs a special flag to link shared libraries.  We recently starting
building shared libraries for our Haskell packages.  The static ones are
still being built, but they go to a separate output.  I think you can
fix your problem in one of two ways:

1. Pass the “-dynamic” flag to GHC (and maybe “-fPIC”);
2. Use “ghc-ieee754:static”.

The first is preferred because the second could get really tricky if
there are nested dependencies.

The fact that the user experience is so wonky is a bit of packaging bug,
for sure.  I’m not sure how to make it nicer just yet.


-- Tim

Re: What about GCC support for ADA ?

[Timothy Sample]

Hi divoplade,

divoplade  writes:

> Recently I was introduced to the ada programming language.  [...]
> However, it is not installed with gcc-toolchain (I am on a foreign
> distribution).
>
> Are there deep reasons why it is disabled?  [...]  Is there a
> bootstrapping problem for instance?

That’s the issue, yes.

The GNAT frontend is written in Ada, and can only be built with GNAT.
What makes this worse is that there isn’t a pre-built binary available
for bootstrapping.  Adacore Technologies offers a “community” version of
GNAT as a binary, but I think there might be licensing issues. [1]

I wrote code a long while ago that assembles a working GNAT binary from
Debian.  It was the best approach I could come up with for getting a
well-established, free software version of GNAT as a binary.  It might
be useful if someone wanted to make an Ada channel.  The approach was a
little too ugly for Guix proper.


-- Tim

[1] I’m not sure I remember all the details.  The Adacore version is
released under the GPL, but I think it lacks the GCC Runtime Library
Exception.  This means that the code it produces would have to be
released under the GPL.  This might be a problem for compiling GNU GNAT,
since it does contain the exception.  Again, my memory is fuzzy here and
I encourage anyone interested to check for themselves.

Re: Who has had success installing a Guix system on arm?

[Timothy Sample]

Hi Jesse,

Jesse Gibbons  writes:

> Has anyone in this mailing list successfully used the Guix system on
> an armhf or aarch64 computer?

I don’t have a lot of details for you, but I can confirm that I’ve used
Guix on three armhf boards: BeagleBone Black, veyron_speedy (ASUS C201),
and veyron_minnie (ASUS C100PA).

For the BeagleBone, it required using an older version of U-Boot.
Upstream U-Boot has stopped supporting it.  Our package patches support
back in, but it didn’t work for me.  I believe I’ve tried to use Guix on
it three times and only succeeded once.  If you have a BeagleBone Black
and want to use Guix, let me know.  I could track down my notes and see
if I can still produce a usable image.

For the Veyron boards, it is starting to work quite well.  The current
version of U-Boot can boot these boards, but you can also boot U-Boot
from the stock firmware (which is Depthcharge).  This is needed because
the Guix initial RAM disk is too big for Depthcharge to boot directly.

The point I’m trying to make is that Guix can be made to work on armhf,
but it is not at all smooth sailing.  There are usually one or two
things that need fixing before it will work.  IME, we are close to
having a decent experience, but we’re definitely not there yet.  The
saving grace is that Guix makes working on these things pretty painless.


-- Tim

Re: Who has had success installing a Guix system on arm?

[Timothy Sample]

Hi Vagrant,

Vagrant Cascadian  writes:

> On 2020-11-05, Timothy Sample wrote:
>
>> For the Veyron boards, it is starting to work quite well.  The current
>> version of U-Boot can boot these boards, but you can also boot U-Boot
>> from the stock firmware (which is Depthcharge).  This is needed because
>> the Guix initial RAM disk is too big for Depthcharge to boot directly.
>
> Curious; I've never been able to get the U-Boot working on the veyron
> speedy,

AIUI, commit fffdf7290cee85232ee522e27c09c7f1178e6219 makes it work.  It
looks like it was included in 2020.07.  I was able to flash U-Boot onto
an ASUS C201 and now it boots nicely (and can be rolled back with a nice
little menu).  (I was gearing up to debug U-Boot myself, and am very
relieved someone beat me to it!)

> but use an old libreboot to boot guix (but only linux-libre
> versions < 5.5, 5.6+ gets stuck in some loop). The initrd size appears
> to be a non-issue for me.

I have the same problem with the kernel, and am using 5.4 currently.

I tried with Libreboot and with stock Depthcharge and had no luck.  I’m
pretty sure it’s a size issue, because every image I built bigger than
16M could not boot, but plenty of smaller ones could (if I made my own
initial RAM disk, say).  IIRC, upstream Depthcharge bumped the size
limit from 16M to 32M and that version should be included in Libreboot.
However, it didn’t work for me in practice.  Either way, I am much
happier using U-Boot.

>> The point I’m trying to make is that Guix can be made to work on armhf,
>> but it is not at all smooth sailing.  There are usually one or two
>> things that need fixing before it will work.  IME, we are close to
>> having a decent experience, but we’re definitely not there yet.
>
> Yes, I'll definitely agree that it is improving, but maybe not that it
> is close. :)

That’s fair!  My glasses are a bit rosy right now because of my recent
success with U-Boot.


-- Tim

Re: How to use guix hash --serializer?

[Timothy Sample]

Hi zimoun,

zimoun  writes:

> Indeed,
>
> $ guix hash -S git foo -x
> 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal
> $ guix hash -S git foo
> 0czq9304mdv9f2j6a8cdi9855sl8w595p06c1m8bn9pg391lhcal
>
> Hum, I will check if it is expected.

I’m pretty sure it’s a bug.  Fortunately, with Disarchive 0.4.0, the
following (untested) patch should fix it:

diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm
index d73e3d13dd..c44a4de9a4 100644
--- a/guix/scripts/hash.scm
+++ b/guix/scripts/hash.scm
@@ -69,7 +69,7 @@ (define* (git-hash file #:optional
   ((directory) #t)
   (else #f)))
   (if directory?
-  (git-hash-directory file algorithm)
+  (git-hash-directory file algorithm #:select? select?)
   (git-hash-file file algorithm)))
 
 

Hope that helps!


-- Tim

Re: How to use guix hash --serializer?

[Timothy Sample]

Hi zimoun,

zimoun  writes:

> Feel free to adjust with your commit name and push. :-)

Done!  The commit is 8646f1f7a53d28f305f30420ad23b670159c53a9.


-- Tim