IRC channel logs


back to list of logs

<kolyad>In various guix scripts, the verbosity option is available. What are the available verbosity levels and what do they denote, for, for example, ‘guix package’.
<sneek>Welcome back kolyad, you have 1 message.
<sneek>kolyad, nckx says: LUKS2-by-default is blocked by, once that lands I can unleash the full JSON power of LUKS2 upon innocent guix.
<leoprikler>it appears 0..2
<leoprikler>but you can try higher if you want :)
<kolyad>As in which file
<leoprikler>I'm guessing based on the values I found in guix/scripts/something.scm
<leoprikler>for instance, build sets verbosity to two, which is why you get the entire build logs
<lfam>kolyad: It's documented in the manual section Common Build Options, which are options that can be used with any command that builds things. That includes `guix system`, `guix package`, `guix environment`, and others
<lfam>"Use the given verbosity level, an integer. Choosing 0 means that no output is produced, 1 is for quiet output, and 2 shows all the build log output on standard error. "
<leoprikler>"no output" and "quiet output" sound really similar tho
<lfam>I'd guess that no output means it only prints something if there is an error, whereas quiet output gives you some info but not the compiler messages
<lfam>In general Guix commands are "composable" in the Unix way, so they print useful things on stdout
<lfam>For example:
<lfam>guix gc --references $(guix build --no-grafts hello)
<lfam>That will show you the store items referenced by the built hello package
<lfam>Because the `guix build --no-grafts hello` command prints the path to the store item created by building hello
<lfam>There are lots of things like that that you can do
<lfam>Or, use substitutes to set up a build environment for hello, but do not use substitutes for hello:
<lfam>guix environment hello -- guix build --no-substitutes hello
<lfam>Useful for debugging things seem to be somehow machine-specific
<vagrantc>if .scm and corresponding .go files have an identical timestamp, does that cause issues?
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<raghavgururajan>Hello Guix!
<sneek>Welcome back raghavgururajan, you have 1 message.
<sneek>raghavgururajan, nckx says: Your builder is trying to run ‘gulp’ which doesn't exist. ‘127’ usually just means ‘command not found’. I doubt gulp is available; Node stuff in general is a nightmare to properly package or use.
<raghavgururajan>sneek: later tell nckx: Thanks!
<sneek>Got it.
<raghavgururajan>I am not able to view this bug page All it get is blank white page.
<efraim>can I create a VM and give it more space for its / or do I need to go with a vm-image?
<roptat>hi guix!
<leoprikler>sneek later tell raghavgururajan GNOME Disks (gnome-disk-utility) is packaged as gnome-disk-utility and an input to gnome.
<sneek>Got it.
<raghavgururajan>Hello Folks! I was trying to package gnome-contacts, which uses meson-build-system. It asked for 'folks' as dependency and I did putting 'folks' as input. But even after that, meson is throwing an error "Could not generate cargs for folks". What is this mean?
<sneek>raghavgururajan, you have 1 message.
<sneek>raghavgururajan, leoprikler says: GNOME Disks (gnome-disk-utility) is packaged as gnome-disk-utility and an input to gnome.
<raghavgururajan>leoprikler Thanks! I'll update the chart :-)
<roptat>raghavgururajan, I don't know a lot about the meson build system, but it probably means it couldn't find folks for some reason?
<roptat>raghavgururajan, do you maybe have a log file generated that you could look at? (using guix build --keep-failed to keep the file)
<raghavgururajan>roptat Yes, I found that error from the log file.
<roptat>looking at the content of folks, the pkgconfig file says it requires glib-2.0 gobject-2.0 gee-0.8
<raghavgururajan>And you are right, it also says that it could not find folks.
<roptat>but they're not propagated from the folks package
<roptat>maybe that's it?
<raghavgururajan>roptat So it should folks under propagated-inputs ?
<raghavgururajan>*i should
<roptat>no, I think folks should have glib, gobject (?) and gee as propagated inputs
<roptat>but for now, try to add gee glib and gobject (is that gobject-introspection?) to your inputs
<raghavgururajan>roptat Cool, I will try that.
<numerobis>Hi #guix! The new guix pull --news is amazing, great work!! :) Is it possible to see all the previous news, though, and not just the ones added in the latest 'guix pull'?
<roptat>numerobis, guix pull --list-generations I think
<raghavgururajan>roptat Also, by any chance do you know what is 'goa'? For gnome-music, meson asks for 'goa-1.0'. But on web, there is no program/package like that. Colloqially, gnome-online-accounts is called as goa. But I am pretty sure that is not the right dependency.
<civodul>Hello Guix!
<raghavgururajan>civodul o/
<roptat>I think that's it. Does it have a goa-1.0.pc file?
<efraim>civodul! I have a question! I need a 'guix system vm' with more than 1G of /, where do I edit?
<civodul>efraim: root is a tmpfs in that case, no?
<civodul>so there's no 1G limit, IIRC
<efraim>actually, I guess I could just share a local directory to something filling up
<civodul>but yeah, you could use --share
<efraim>nevermind! --share is a great idea!
*efraim doesn't know why he's yelling
<civodul>that's fine!
<raghavgururajan>roptat The tarball does not have a file called 'goa-1.0.pc'.
<roptat>I mean, gnome-online-accounts
<numerobis>roptat: That works, thank you!
<raghavgururajan>roptat I already tried gnome-online-accounts as input. I get the same error in the log.
<ng0>gash is guile 2.2 only, right?
<efraim>find /gnu/store -name gia-1.0.pc
<jonsger>ng0: yes
<ng0>we're thinking about our guile multiversioning at the moment, I have a couple of packages to publish in pkgsrc. does guix still have guile 1.8 or 2.0 at this point for some packages? I found it a good resource reading
<jonsger>raghavgururajan: I replied to your mailing thread about gnome-contacts
<jonsger>ng0: 1.8 at least for lilypond
<ng0>ah. okay, this resolves "can we drop 1.8" to "no" :)
<efraim>hmm, /var/lib/docker is 1.5G itself and / is at 800+M of 995M, I'
<raghavgururajan>roptat Thanks. I'll check
<efraim>i'll just assume everything is compressed on the fly
<jonsger>ng0: I'm unsure about 2.0, I guess there are still packages out there who don't work with 2.2...
<ng0>2.0 no longer receives security fixes right?
<ng0>it's either that or "very broken" or "no users are using this particular version anymore in pkgsrc" (since there's some very old stuff but it still has users).
*ng0 should read up on guile releases again
<jonsger>ng0: looks like
<ng0>jonsger: do you maintain gash? if so, it's now in pkgsrc. I had it in pkgsrc-wip for a long time.
<jonsger>ng0: I maintain it for openSUSE, not upstream :)
<jonsger>ng0: upstream should be Timoty Sample
<jonsger>how do I built the bootstrap-executables bash, mkdir, tar and xz? Do I have to exctract them from somewhere?
<civodul>jonsger: they're "taken for granted"
<civodul>if you look at (gnu packages bootstrap), they're downloaded
<civodul>see 'bootstrap-executable' and related code
<jonsger>yeah, I added now the hashes from my bootstrap-binaries-powerpc64le.tar.xz and it works
<jonsger>now a different error :)
<civodul>oh oh!
<civodul>right, so you need to somehow provide these 4 files (bash, mkdir, tar, xz)
<jonsger>civodul: were do I save them? the other bootstrap .tar.xz are lying on my webserver and the link, hashes etc added gnu/packages/bootstrap.scm
<civodul>jonsger: for testing purposes, you can simply "intern" them in your store by doing "guix download file://$PWD/mkdir", etc.
<civodul>then you also need to add the hashes in %bootstrap-executables
<efraim>it's not clear that preseeding them in the store works, you may need to change the download url for the bootstrap-executables to point to a location on the internets
<jonsger>something is broken in downloading source tarballs
<jonsger>how can I debug this
<jonsger>I think https makes problems
<jonsger>afk for lunch
<civodul>efraim: ah you're right, it doesn't work with "guix download" because you need to preserve the executable bit
<civodul>so you have to call add-to-store explicitly, as done in the 'guix' package
<civodul>"Wrong type to apply: #<unknown-type (0x24f . 0x7ffff1f228f8) @ 0x7ffff21f1d08>" sounds bad
<civodul>it could be either a miscompiled Guile, or a genuine bug
<divansan`>pre grub, my guix system prompts for decryption password. This keyboard layout is in qwerty. Thereafter it's in dvorak correctly everywhere.
<divansan`>How does one get the pre grub (or is it grub) to be in dvorak too?
<ng0>civodul: what's your prefered way of contact for debugging guile-reader builds, as the maintainer of it?
<ng0>(not for guix, but as external packager)
<civodul>ng0: there's the guile-reader-devel mailing list where i'll do my best to answer
<civodul>you can ping me if i don't :-)
<ng0>ah, thanks :)
<ng0>oh. sorry for asking, i just skipped the website
<civodul>divansan`: that's probably grub, and grub is supposed to honor the layout you chose
<civodul>maybe something is amiss
***Guest273 is now known as guilty
<guilty>hi #guix
<efraim>Turns out there are problems with docker and a p9 filesystem, I'll need to make a VM image or figure out how to make the vm from the script larger
***guilty is now known as mogom
<efraim>Docker being dockerd
<leoprikler>raghavgururajan: try gnome-online-accounts:lib
<jonsger>civodul: how can I debug this error? guix repl is not so useful as it doesn't give me a backtrace or so
<mogom>how i could generate a u-boot image in guix for special board?
<mogom>this is a sample:
<mogom>but it's build OS that include u-boot.
<mogom>i know something like "make-u-boot-package" works.
<mogom>but the question is that i most write a .scm for this?
<mogom>use it "guix build -f /path_of_scm.scm"?
<mogom>or maybe define a package in .scm and try to build it?
<mogom>I'm confused about it :/
<roptat>mogom49, see for example
<roptat>you can define all you need in your config.scm file
<roptat>simply define them before (operating-system ...)
<roptat>if there's no package for your board, you can create one with make-u-boot-package, as you have guessed already :)
<roptat>then, you can use it in a bootloader definition
<roptat>so you would have your own bootloader definition instead of u-boot-beaglebone-black-bootloader in the example
<mogom49>roptat: ene.scm has a OS definition and build it make an OS and not an u-boot
<mogom49>you mean, do "guix build -f [file.scm]"?
<roptat>no, guix build would simply build the package and add it to the store
<roptat>it wouldn't install u-boot
<roptat>you need to run guix system init/reconfigure to install u-boot properly
<roptat>and the correct u-boot needs to be defined in your config.scm file
<roptat>my ene.scm is an operating-system declaration that uses a u-boot bootloader defined above the declaration (although, the u-boot package I use is already defined in Guix)
<roptat>in you example, there's an operating-system declaration with a u-boot-bootloader that's already defined by guix
<mogom49>so if i want only generate u-boot. can i do "guix build u-boot-[my created u-boot package]-bootloader". is it?
<roptat>see the line with "define u-boot-cubietruck-bootloader" in ene.scm? that's where I define the bootloader. Here, I inherit from an already defined bootloader, because I want the same, but with another package
<roptat>the u-boot-*-bootloader is not a package
<roptat>so you can't build it
<roptat>I don't have an example of a u-boot package, but you guessed it, you can use make-u-boot-package for that
<roptat>see here for a lot of examples of using make-u-boot-package:
<mogom49>:) so what to do if i want only generate u-boot image for test u-boot?
<roptat>ok, if you only want to build it (but not use it), you can create a file, say u-boot.scm where you (define-public my-uboot (make-u-boot-package ...))
<roptat>you'll have to import (gnu packages bootloaders) too
<roptat>then at the end of the file add my-uboot (it refers to the variable you defined, so the file can be evaluated to a value, instead of #<unspecified>) and you can build the package with "guix build -f u-boot.scm"
<roptat>if all goes well, you'll end up with the store path where u-boot is built
<mogom49>'=D thanks, the builtin u-boot can run on the target board?
<roptat>I think what make-u-boot-package does is to specialize the u-boot package for a board
<roptat>if you don't specialize it, it won't run correctly I think
<roptat>actually, what do you mean by "builtin"?
<roptat>I don't think you can use a previously installed u-boot if that's what you mean
<mogom49>sorry my means was this "you'll end up with the store path where u-boot is built"
<roptat>ah yes, the store path will contain a u-boot that can be installed on your board
<roptat>normally, it's done by guix system
<roptat>I guess you could do it manually,
<mogom49>i will write my .scm as you guided an share it's problem in this group and check it with you and others.'=D
<civodul>jonsger[m]: which error actually?
<jonsger>civodul: Wrong type to apply: #<unknown-type (0x24f . 0x7ffff1f228f8) @ 0x7ffff21f1d08>
<civodul>ah that one
<civodul>jonsger: how did you obtain that bootstrap Guile? "guix build --target=... guile-static-stripped"?
<civodul>does a natively-built Guile 2.2 work fine on ppc64le?
<jonsger>I did guix build --target= bootstrap-tarballs and added it bootstrap.scm. See
<str1ngs>civodul: does there exist a srfi that handles named fields like define-record-type*? or something similar to it?
<jonsger>for building guix in the git repo I use guile 2.2 from SUSE/openSUSE. This usually works fine
<jonsger>testsuite passes the same way then on amd64...
<akoppela>Hello everyone.
<akoppela>I'm back with experience report installing GuixSD on DigitalOcean
<akoppela>• I downloaded official install system ISO
<akoppela>• Uncompressed it
<akoppela>• Converted it to `.dvi` image because DigitalOcean does not eat ISO
<akoppela>• Added custom image to DO
<akoppela>• Created droplet from custom image
<akoppela>• For some reason I was unable to install system to the booted drive. DigitalOcean boots install system in `/dev/vda` and it
<akoppela>I could not find a way yet to reformat booted drive with install system. Because it the only one I got.
<akoppela>They always say the disk is in use by system
<str1ngs>akoppela: what is the output of lsblk -f
<akoppela>But I was able to install GuixSD on additional volume which is `/dev/sda`
<str1ngs>akoppela: from the looks of this /dev/vda is the dvi and /dev/sda is the OS drive
<akoppela>Then I just cloned `/dev/sda` to `/dev/vda` with `dd` was able to boot to GuixSD after restart
<akoppela>So it's hooray. But feels like a workaround.
<akoppela>str1ngs: When I boot with install system ISO `lsblk -f` returns four partitions created by install system
<akoppela>`/dev/vda1`,.. `/dev/vda4`
<akoppela>nothing is mounted
<str1ngs>akoppela: install system being guix installer?
<akoppela>yes it's Guix installer from the official website
<str1ngs>I would determine what drive is the dvi and which is the hard disk. I'm assumming /dev/vda is the dvi and /dev/sda is the HD
<akoppela>By default DigitalOcean gives only `/dev/vda`
<str1ngs>in which case you would install to /dev/sda . maybe you need to tell DO to boot /dev/sda
<akoppela>with whatever coming from the given image
<akoppela>but it's possible to attach externals drives
<akoppela>which will be `/dev/sdX`
<akoppela>so `/dev/vda` is the `dvi` for sure
<truby>has anyone tried running guix on top of guile 3? is it possible? The jit for aarch64 looks really promising (guile is pretty slow on aarch64 atm in my experience :-()
<str1ngs>akoppela: are dvi's intended for custom install? or are they only for os images?
<akoppela>`dvi` is VirtualBox format for images
<akoppela>so it can be any image, either with install system or preinstalled system
<akoppela>As I understodd
<akoppela>As I understood
<akoppela>DigitalOcean is able to eat dvi images, and I used VirtualBox to convert iso to dvi
<str1ngs>maybe you mean load
<akoppela>eat means I'm able to upload an image and DigitalOcean is able to use it to create droplets
<str1ngs>I guess alternatively you can create a guix dvi image locally. then upload and boot from that dvi on DO
<akoppela>yes, that's also possible
<akoppela>the issue for me is that I'm working from iPad
<akoppela>so I can not do that locally
<str1ngs>I suspect though your cloning sda to vda has the same effect. with less network overhead
<akoppela>with same `dd` command I can create an image from `/dev/sda` and upload it to DO
<akoppela>I'm quite happy to finally run GuixSD
<akoppela>i'm total noob with linux
<str1ngs>this is kinda trial by fire then :P
<akoppela>So I though maybe I'm missing something
<akoppela>I tried the same process with NixOs
<str1ngs>I think your disk cloning is best solution given the circumstances
<akoppela>NixOs install system is booted differently
<akoppela>it has different partitions, etc..
<akoppela>and I'm able to reformat `/dev/vda`
<akoppela>interesting though
<jonsger>I can now reproduce this issue in "guix repl" but I don't know how to get a backtrace or something like that
<wingo>jonsger: if you can get a core file or something it would be useful to see what .go files are mapped into the process
<jonsger>wingo: what I do to reproduce:
<jonsger>the mapped .go files from lsof? or how do I get them
<wingo>you can get then from /proc/$pid/smaps
<wingo>or /proc/$pid/maps
<jonsger>wingo: maps
<jonsger>wingo: ah got it. guile-gnutls is guile 2.0 :(
<wingo>ah :)
<jonsger>hm, now I have different problem
<jonsger>`guix download file:///path/to/bash` where bash is the one from static-bootstraps leads to /gnu/store/qziv75p1qz4lw31rppbbfx65piqjs689-bash but `guix build` tries to download /gnu/store/n9g7kihfj1kzz0nh9106wvbx7g7sc49f-bash
<jonsger>^ civodul
<roptat>civodul, what's the address to submit a blog post again? or is guix-devel fine?
<Jalepeno_X>can you guys see my message?
<jonsger>Jalepeno_X: yes
<Jalepeno_X>Okay I ran the script to install the binary installation of guix. I installed it on top of Linux Mint.
<Jalepeno_X>But nothing changed,
<Jalepeno_X>How do I get Guix to boot instead of Linux mint. Is there a good tutorial on how to actually use Guix, because I feel like I don't understand what it's doing.
<roptat>Jalepeno_X, the install script is to install guix on top of the distro, not *instead* of the distro
<roptat>basically, you installed guix the package manager, not guix the operating system
<Jalepeno_X>Okay got it.
<roptat>to install the operating system, you should use the iso image we provide here:
<roptat>"GNU Guix System 1.0.1"
<roptat>yw :)
<str1ngs>though you can use the guix package manager to install guix operating system aswell.
<roptat>absolutely, but it's more difficult than the graphical installer :)
<mogom>hi #guix
<mogom23>i encounter with "error: license:gpl2+: unbound variable" during "guix build [.scm file]"
<mogom23>i also add (use-modules ((guix licenses) #:prefix license:))
<mogom23>but error persist
<mogom23>i use this code
<smithras>mogom23: can you atach a paste of your file
<mogom>Uploaded file:
<mogom>smithras: it's above
<mogom>any idea?
<mogom>i ran "guix build -f rockpi4.scm"
<jonsger>mogom: why did you commented out the "(use-modules ((guix licenses) #:prefix license:))" line?
<mogom>jonsger: because it's make error : "error: #<unspecified>: not something we can build"
<str1ngs>mogom: you need to add a package name to the end of the file. and you need to pass the -f flag when using build. like so $ guix build -f ./rockpi4.scm
<str1ngs>mogom: unless you meant to use the command guix system build
<str1ngs>sneek: later tell mogom I suspect you want to use guix system build . not guix build
<str1ngs>sneek: later tell mogom, after actually reading your definitions. you need to add the package the end of the file you would like to build. the build with guix build -f ./rockpi4.scm
<sneek>Got it.
<civodul>roptat: guix-devel is fine if you want public discussion, or guix-blog if you want to prepare a surprise :-)
<truby>Note to self: don't enable aggressive-indent-mode when preparing patches :-)
<alextee[m]>anyone know what packages you need for pdflatex?
<alextee[m]>(trying to compile a .tex file to pdf)
<alextee[m]>i installed texlive-latex-base texlive-latex-pdfx and texlive-generic-pdftex
<alextee[m]>but i don't see any latex to pdf compiler anywhere in ~/.guix-profile/bin
<alextee[m]>i think i need pdftex or pdflatex
<alextee[m]>oh, texlive-bin
<ng0>texi2pdf can compile it just fine
<ng0>or luatex
<ng0>i use texi2pdf for my LaTeX invoices.
<alextee[m]>oh thanks, im a latex noob, didn't even know about that
<mbakke>efraim: I can't remember their IRC nickname, but someone did a powerpc64le bootstrap a while back here:
<efraim>i have a big endian powerpc G4 that I'm using as my laptop ATM
<mbakke>ooh, cool :)
<efraim>along the way I fixed neovim and efl in debian for powerpc
<roptat>hey guix!
<roptat>oh nevermind I didn't see the bug report associated with it ^^'
<roptat>mh... I think there was only a typo, so I'm going to fix it, try to build a few package that use svn-fetch and push if it works
***ng0_ is now known as ng0
<alextee[m]>is there a way to refresh font caches or something in latex? looking these up online just confuses me more. i installed a bunch of tex related packages with fonts but i keep getting errors that it can't find fonts lol
<civodul>alextee: i think you need "texlive-fonts-ec"
<alextee[m]>civodul: that's already installed. i have a feeling it needs some kind of "refresh fonts" command
<alextee[m]>i tried restarting but didn't help
<civodul>hmm, weird
<civodul>alextee: could you try that command in "guix environment -C --ad-hoc texlive-fonts-ec texlive-tex-texinfo texlive-generic-epsf"?
<civodul>these are the 3 packages needed for texi2dvi, it seems
<htsr>hi, I'm trying to guix system init (I've guix pull) but I have this error
<alextee[m]>civodul: that doesn't work on its own, missing sed, coreutils, etc., but using this gives me the same error:
<alextee[m]>guix environment -C --ad-hoc texlive-fonts-ec texlive-tex-texinfo texlive-generic-epsf texinfo coreutils sed texlive-bin grep texlive-latex-base tar texlive-latex-graphics texlive-latex-geometry
*alextee[m] upgrades system
<alextee[m]>trying to compile the title part from here btw:
<jonsger>alextee[m]: I use moderncv, a latex package for CVs :)
<civodul>alextee[m]: whether you eventually succeed or not :-), you should post your findings to guix-devel
<civodul>setting that up is incredibly difficult
<alextee[m]>civodul: will do!
<alextee[m]> jonsger thanks! i'll give that a spin when i get it working
<bandali>PSA for .org domain owners: consider either renewing for as long as possible, or transition away, while you still can. a price jump may be incoming
<truby>hi guix :) has anyone looked into using guix environment -C with something similar to guix pack -S to make FHS compliant container environments containing the asked for packages? This would be really useful for making reproducible build environments for C/C++ programs whose build systems aren't necessarily friendly to non-FHS distros
<truby>(if the answer is no I'm happy to dig into the code and look at this myself if it's something anyone else would find useful other than me!)
<leoprikler>truby: with "FHS compliant" you mean only relying on /bin and /usr etc., not e.g. /gnu?
<truby>yeah, particularly reliance on /bin,/lib,/usr/bin,/usr/lib
<truby>I can already create a squashfs and load it with singularity e.g. with guix pack -R -S bin=/bin lib=/lib gcc-toolchain@8; singularity shell /path/to/result.squashfs
<truby>being able to do this in one line with guix environment -C --fhs or whatever would be really great (for my workflow at least :-))
<leoprikler>perhaps you want to make use of --expose=SPEC and --share=SPEC
<leoprikler>e.g. map some profile/bin to /bin
<leoprikler>(not sure if that is possible in this exact way)
<truby>is that what guix pack -S uses? because the containers I load that were created by that are pretty much exactly what I'm looking for
<leoprikler>wait, I'll dive into guix pack for a moment
<dongcarl>I'm not sure how we're helping out with the software heritage foundation but perhaps we can also collaborate with this effort:
<dongcarl>seems that the software heritage foundation is already helping out
<civodul>dongcarl: interesting and... weird
<civodul>they seem to present the same mission as Software Heritage
<civodul>except that they're a for-profit company, which makes me wonder
<leoprikler>Software Heritage: Let us archive software!
<leoprikler>Microsoft: Let us archive software... for money!
<civodul>the Artic Code Vault looks fun, though!
<civodul>the "1,000 years" promise is ridiculous given that computers are less than 100 years old
<leoprikler>truby: It appears guix pack -S does its own stuff, look at the self-contained-tarball function
<civodul>anyway, it's worth keeping an eye on this initiative!
<dongcarl>I don't think they're asking for money, agree that we should keep an eye out!
<leoprikler>environment uses specification->file-system-mapping, which is also used by guix system
<stikonas>ok, I think I finally got kde-frameworks 5.63 working. A few more tests and I can submit a pull request
<stikonas>argh, there is already a similar patch on the mailing list...
<stikonas>oh well...