<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. <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>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
<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. <efraim>can I create a VM and give it more space for its / or do I need to go with a vm-image? <leoprikler>sneek later tell raghavgururajan GNOME Disks (gnome-disk-utility) is packaged as gnome-disk-utility and an input to gnome. <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. <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) <roptat>looking at the content of folks, the pkgconfig file says it requires glib-2.0 gobject-2.0 gee-0.8 <roptat>but they're not propagated from the folks package <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 <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. <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? <efraim>actually, I guess I could just share a local directory to something filling up <efraim>nevermind! --share is a great idea! *efraim doesn't know why he's yelling <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 <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 <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' <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 <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 <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 <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 <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 ***Guest273 is now known as guilty
<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
<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>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? <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>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>I don't have an example of a u-boot package, but you guessed it, you can use make-u-boot-package for that <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 <jonsger>civodul: Wrong type to apply: #<unknown-type (0x24f . 0x7ffff1f228f8) @ 0x7ffff21f1d08> <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? <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>I'm back with experience report installing GuixSD on DigitalOcean <akoppela>• I downloaded official install system ISO <akoppela>• Converted it to `.dvi` image because DigitalOcean does not eat ISO <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 <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 <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>so it can be any image, either with install system or preinstalled system <akoppela>DigitalOcean is able to eat dvi images, and I used VirtualBox to convert iso to dvi <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>the issue for me is that I'm working from iPad <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 <str1ngs>I think your disk cloning is best solution given the circumstances <akoppela>NixOs install system is booted differently <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>the mapped .go files from lsof? or how do I get them <wingo>you can get then from /proc/$pid/smaps <jonsger>wingo: ah got it. guile-gnutls is guile 2.0 :( <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 <roptat>civodul, what's the address to submit a blog post again? or is guix-devel fine? <Jalepeno_X>Okay I ran the script to install the binary installation of guix. I installed it on top of Linux Mint. <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 <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 :) <mogom23>i encounter with "error: license:gpl2+: unbound variable" during "guix build [.scm file]" <mogom23>i also add (use-modules ((guix licenses) #:prefix license:)) <smithras>mogom23: can you atach a paste of your file <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 <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]>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 <ng0>texi2pdf can compile it just fine <ng0>i use texi2pdf for my LaTeX invoices. <alextee[m]>oh thanks, im a latex noob, didn't even know about that <efraim>i have a big endian powerpc G4 that I'm using as my laptop ATM <efraim>along the way I fixed neovim and efl in debian for powerpc <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 <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 <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 <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]> jonsger thanks! i'll give that a spin when i get it working <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>(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 <dongcarl>seems that the software heritage foundation is already helping out <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>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...