IRC channel logs


back to list of logs

<rekado_>there seem to be a lot of rebuilds now
<noordinaryspider>i agree
***Piece_Maker is now known as Acou_Bass
<eric23>I believe I have guix version 20171107.19. But it errors.
<eric23>that's what happens when I do a guix pull
<sturm>Gee, magit is very slow for me on the guix repository (running on Guix SD). Any suggestions for speeding it up?
<CharlieBrown>I can't get Gajim working in Trisquel.
<CharlieBrown>ACTION posted a file: gajimerror.txt (4KB) <>
<eric23>guix package -u is compiling everything
<ng0>Hey, is Rémi's email still the one at like back in 2015?
<ng0>if not, can someone send me an email with Rémi's current address? I have questions on a software Rémi wrote back then. I think Rémi told me a while back I could ask
<ng0>what's the full MIME type for nar and narinfo? application/nar and application/narinfo?
<efraim>so many new packages to test building on aarch64
<civodul>Hello Guix!
<efraim>"It has been 21 years since the last release."
<nee`>efraim: sounds like extreamly stable software.
<efraim>nee`: its GNU time
<clacke[m]>the last release of Linux 1.3?
<rekado>Guix makes me build glibc from source.
<rekado>Neither berlin nor the mirror have it.
<rekado>now building ghostscript-with-cups…
<civodul>rekado: yes that's what i noticed yesterday (glibc)
<civodul>that's hopefully fixed in gnu-system.scm, but hydra has probably not evaluated it yet
<Achylles>I have put guix image on a usb and when it loads it. It says that it is an installation image...
<Achylles>How can I try it on a live system?
<Achylles>Can I install it on virtualbox?
<Achylles>I have tried this, but did not work
<Achylles>as well
<rekado>civodul: it seems that a lot of archived sources have disappeared from hydra as well
<rekado>Achylles: the installation image is a live system.
<Achylles>ok so, when I get the root console...
<Achylles>what should I do?
<Achylles>I typed "startx"
<Achylles>and nothing heppened...
<Achylles>Now I am trying to load it on qemu
<Achylles>But, it took some time for me to understand that Guix is other OS, than Linux...
<mekeor>Achylles: Guix is a package manager. the Guix System Distribution (GuixSD) is made in such a way that it can use the Linux kernel or other unix-like kernels.
<mekeor>Achylles: what do you expect from a live-CD?
<mekeor>you want a desktop environment?
<Achylles>I expect to load as a sample and then install if someone wants...
<Achylles>In Linux, if it is not a live non-gui server. Then, yes...
<mekeor>Achylles: as far as i know, we don't have any live images with a desktop environment yet.
<Achylles>pl/ Tjamx//
<Achylles>ok thx...
<mekeor>Achylles: but after booting the installation image, it should be possible to apply a system-configuration which includes a desktop environment..
<Achylles>I think I will install it on a debian virtualbox image first then try it, instead of in my main system...
<mekeor>that's a good idea :)
<janneke>ACTION tracked down guile-emacs segfault
<rekado>janneke: that’s great!
<rekado>janneke: I had it segfaulting with my regular configuration
<janneke>yes, it's emacs bug #24065: calloc loop when compiling with -O2
<civodul>rekado: prolly because i "purged" /var/cache/guix/publish/none, but they'll come back
<civodul>we just need to do narinfo lookups
<civodul>efraim: so there was *really* a new GNU time release, woow
<janneke>efraim: guile-emacs builds with libjpeg 9
<janneke>i added: (inputs `(("libjpeg" ,libjpeg) ,@(alist-delete "libjpeg" (package-inputs emacs))))
<efraim>i wonder if emacs itself actually needs libjpeg8 and not 9
<janneke>i suppose you don't want that in my guile-emacs patch?
<janneke>i cannot imagine, guile-emacs is a fork of 24.5
<efraim>i'll leave that up to you
<janneke>ok, then i'll remove it -- best if guile-emacs just reuses most of emacs' recipy
<janneke>suddenly while building guile-emacs, creation of dir: src/deps/ starts to race :-(
<janneke>sound familiar, anyone?
<rekado>what do you mean by “starts to race”?
<civodul>rekado: thoughts on the 'install-license-files' phase at ?
<janneke>rekado: guile-emacs used to `make' fine, now it fails because src/deps dir does not exist -- a mkdir -p src/deps "fixes" that
<janneke>so i infer a race/missing make dependency -- but i'm not really sure
<rekado>civodul: is (car (first outputs)) really correct?
<rekado>shouldn’t it be just (first outputs)?
<rekado>for the regexp, how about this: "^((COPYING.*|LICEN[CS]E.*|[Ll]icen[cs]e.*|Copy[Rr]ight)(\\\\.(txt|md))?)$"
<rekado>i.e. permit COPYING.txt and alongside COPYING.
<rekado>the rest looks good to me.
<civodul>rekado: regarding the regexp, i wanted to allow COPYING.* because sometimes there's COPYING.GPL3, COPYING.LGPL, etc.
<civodul>that also matches COPYING.txt,, COPYING-whatever
<rekado>oh, right
<rekado>sorry, I misread it
<rekado>that leaves only the question about (car (first outputs))
<fps>has there been progress with getting go packages built? :)
<fps>e.g. go-ipfs?
<civodul>ACTION checks
<civodul>rekado: yeah that one was wrong, i changed it to:
<civodul> (match outputs
<civodul> (((_ . output) _ ...)
<civodul> output))
<civodul>it's in the unlikely event where there's no "out" output though :-)
<civodul>i think it covers some of what Dave Love was suggesting, WDYT?
<vagrantc>hmmm... so i'm booting the 0.13 guixsd installer usb image ... and figured it would be nice to do an install via ssh ... but ssh-keygen (presumably from openssh) isn't installed ... so i have no way of verifying the host keys
<rekado>yes, this looks good
<rekado>civodul: I was wondering about the same problems wrt distributing application bundles
<rekado>Hi vagrantc!
<rekado>vagrantc: on the remote you’d have to install the openssh package first.
<fps>btw: upgrading via the intermediate tgz (0.13) for guix pull fails because a package isn't available on hydra
<fps>i think it was tiff..
<vagrantc>rekado: but the installer is a host ... how do i verify the host keys for the installer?
<rekado>fps: it’s possible that this is just a temporary problem with the mirror.
<fps>rekado: ok.
<vagrantc>and of course, i've now gotten into "updating" the installer system :) kind of cargo-culting guix commands here...
<fps>and of course with my old guix the --fallback option is not supported for guix pull.. but i guess i might try installing the failed package first?
<efraim>We should also mark some files/directories with 'chattr +C' for CoW filesystems, like the db for the store
<rekado>vagrantc: I’m not sure I understand what you mean by “the installer is a host”.
<rekado>ACTION goes afk for a little while
<vagrantc>rekado: i ran "herd start ssh-daemon" and that presumably is using the keys in /etc/ssh/ssh_host* ... how do i verify when i connect to that ssh server is using the correct host keys? i would usually do ssh-keygen -l -f /etc/ssh/host_*.pub or something like that
<vagrantc>and then compare the results from the machine ssh'ing from
<vagrantc>as opposed to blindly typing "yes" when i connect to the machine for the first time
<vagrantc>also, is it generally feasible to install to the same media you've booted the installer from?
<efraim>i wonder if we can parallelize the 'strip phase
<rekado>vagrantc: I have never tried to install GuixSD onto the installer media.
<rekado>vagrantc: do you have direct access to the host that was booted with the GuixSD installer?
<vagrantc>in theory, there's no real reason it shouldn't work ...
<vagrantc>rekado: currently running it in a VM
<rekado>and you cannot run the above command to print the SSH host key fingerprint?
<vagrantc>ssh-keygen isn't included in the installer image
<rekado>ACTION is very slow today
<vagrantc>so i decided to install openssh, hoping it was included there
<rekado>on my machine it is part of the openssh package.
<rekado>(I don’t have an installer-booted system right now to verify this)
<vagrantc>which then advised me to run "guix pull && guix package -u" ... and now from within the installer, i'm apparently updating a bunch of things
<rekado>oh, I see
<vagrantc>rekado: yeah, openssh wasn't installed
<rekado>0.13.0 is quite a few months old and we’re preparing for a new release
<vagrantc>this is certainly a bit of a learning experience in guix, which was the intention
<vagrantc>are there any pre-release installer images for testing?
<rekado>“guix pull” is analogous to “apt-get update”
<rekado>no, there are none, but one can build them with Guix
<vagrantc>yes, i was just thinking it would be really helpful to create a list of apt -> guix correlaries
<vagrantc>if not already documented
<rekado>one thing that trips up many people is that all of these commands are per-user.
<vagrantc>even root?
<rekado>“guix pull” as root only affects the root user.
<rekado>only commands like “guix system reconfigure …” have system-wide effects
<vagrantc>ACTION is happy to be stumbling through this
<rekado>(like installing a new generation of the operating system and registering it with the bootloader)
<rekado>but since “guix system reconfigure” must be run with root privileges, some users end up using the wrong variant of guix
<rekado>I always do “sudo -E guix system reconfigure…” to ensure that my current user’s guix is used.
<rekado>I *think* you could have ignored the suggestion to run “guix pull && guix package -u” at this point
<bavier>rekado: nice tip re 'sudo -E'
<rekado>“guix pull” updates to whatever is currently in the master branch.
<rekado>and this could mean that packages you want would have to be built from source.
<rekado>we try to keep binaries for release tags, but storage has been a problem in the past, so that’s no guarantee.
<vagrantc>from what i've gathered, releases have been happening about every 6 months or so?
<rekado>I think it was every 4 months
<rekado>we’re behind with this release.
<rekado>some would say “inevitable” ;)
<rekado>when bugs are encountered in releases it becomes increasingly difficult to cater for buggy variants.
<rekado>“guix pull” has been changed quite a bit since the last release, for example.
<vagrantc>i should probably just reboot the installer and start over :)
<rekado>I don’t know what the best way forward is.
<rekado>I don’t often install from scratch :-/
<rekado>another idea is to check with “pgrep -fa ssh” to see which sshd is running
<efraim>I found plenty of substitutes when I installed with the installer about 2 weeks ago
<rekado>get the prefix directory /gnu/store/…-openssh-…/ and run ssh-keygen from “bin”
<rekado>that’s a little clunky, but works for me
<vagrantc>is the installer all running in ram? mount and df aren't showing any actual disks mounted
<efraim>what's the minimum version on guile we target? is it still 2.0.7?
<ng0>wasn't it 2.2?
<efraim>for bootstrapping on a foreign distro
<efraim> says 2.0.9
<vagrantc>aw, no C.UTF-8 locale?
<civodul>vagrantc: maybe not, there's en_US.utf8 though
<civodul>(in general "utf8", not "UTF-8")
<Achylles> uscan --download-current-version
<Achylles>gpgv: Can't check signature: No public key
<Achylles>uscan die: OpenPGP signature did not verify.
<Achylles>I ma stuck here :(
<vagrantc>guess the C.UTF-8 (or .utf8) support is not in upstream glibc
<ng0>why would you want just C as a locale for the user?
<ng0>the build environment uses C afaik
<efraim>'par-for-each' in place of 'for-each' during the 'strip phase reduced glibc-final's strip phase from 235 seconds to 215 seconds
<efraim>guix/build-system/gnu.scm:436 says the locale is "en_US.utf8"
<efraim>8.5% faster
<vagrantc>ng0: why would i want a specific country as a locale?
<ng0>I leave that up to others to explain…
<vagrantc>ACTION would like a country-agnostic locale :P
<vagrantc>with UTF-8 support
<vagrantc>is that so unreasonable?
<ng0>seems like you don't understand locales fully. But you can construct your own locale, even with Guix. I had an en_DK+en_US+de_DE mixture for a while didn't bother to recreate it yet
<vagrantc>ACTION doesn't claim to understand anything *fully* heh
<vagrantc>usually sufficient is good enough
<rekado>ACTION admits to not understanding locales
<ng0>vagrantc: basically currency, time, delimiters, blabla set in the locale affect what's displayed in (some) applications making use of that… and more.
<ng0>that's how I understand it
<ng0>for example en_DK.UTF-8 is the only locale (to my knowledge) featuring the ISO format (YYYY-MM-DD) for date
<eric23>how long does it take for a newly released Linux-libre kernel to be included in guix substitute?
<Achylles>I have installed guix. Finally...
<Achylles>How do I update it?
<Achylles>guix package -u guix
<efraim>'guix pull' followed by 'guix package -u'
<Achylles>why guix does not accept TAB autocompletion on my bash?
<janneke>Achylles: possibly you haven't installed the bash-completion package?
<Achylles>Yes. I do have...
<Achylles>It says that my guix version is too old...
<Achylles>uix package -i emacs-guix --fallback
<janneke>initial install/upgrade could be smoother
<Achylles>is this a command?
<Achylles>guix package -i emacs-guix --fallback
<Achylles>I try this and get lots of errors...
<Achylles>guix substitute: error: download from '' failed: 404, "Not Found"
<janneke>that should be the command to install guix-emacs, yes
<Achylles>guix package: error: build failed: unexpected EOF reading a line
<janneke>Achylles: annoying...try adding: --substitute-urls=
<janneke>ACTION is not sure if and how this error should be reported
<Achylles>guix package -i emacs-guix --substitute-urls=
<Achylles>like this?
<janneke>ACTION tried: wget
<janneke>and that works
<Achylles>I think I will give up
<Achylles>It is supposed to be smoother than apt/apt-get...
<Achylles>But, I am having lots of issues...
<Achylles>substitute: ;;; Failed to autoload make-session in (gnutls):
<Achylles>substitute: ;;; ERROR: missing interface for module (gnutls)
<Achylles>substitute: Backtrace:
<Achylles>substitute: In ice-9/boot-9.scm:
<Achylles>and so on...
<janneke>Achylles: hmm, so you don't have gnutls package available...
<Achylles>guix substitute: error: download from '' failed: 404, "Not Found"
<Achylles> guix package -i gnutls
<Achylles>Downloading (4.3MiB installed)...
<Achylles>guix substitute: error: download from '' failed: 404, "Not Found"
<Achylles>guix package: error: build failed: unexpected EOF reading a line
<Achylles>sorry for the flooding...
<janneke>Achylles: that's okay
<janneke>sorry for the bumpy road...
<Achylles>this mirror.hydra is terrible
<Achylles>Isn't there another one?
<janneke>civodul: you're with us here?
<janneke>yes, is one alternative
<Achylles>where do I change it?
<Achylles>in a file?
<Achylles>in the config file. I mean
<bavier>Achylles: you can do it on the command-line with the --substitute-urls options janneke mentioned previously
<janneke>you can add --substitute-urls=... on most every command
<Achylles>I know...
<Achylles>but I want to permanently change it...
<janneke>once you're up, you can add it to the guix-daemon
<bavier>or set it in GUIX_BUILD_OPTIONS environment variable
<Achylles>I need to locate the daemon config file...
<janneke>usually is fine though, you're just hitting some rough weather
<Achylles>all right...
<janneke>are you on guixsd?
<Achylles>on debian
<Achylles>guix is a package here...
<janneke>ah...then you start the guix-daemon using systemd i presume?
<Achylles>which guix
<bavier>Achylles: iirc the debian guix package is a very old version
<Achylles>It says so...
<bavier>so substitutes might have been gc'd on the mirrors and build farms
<bavier>you'd probably be better off using the binary installation method
<janneke>there's probably a /etc/systemd/system/guix-daemon.service or something, you can add --substitute-urls=... there and restart the guix-daemon service
<Achylles>systemctl status guix-daemon
<Achylles>● guix-daemon.service - Build daemon for GNU Guix
<Achylles> Loaded: loaded (/usr/local/lib/systemd/system/guix-daemon.service; enabled; v
<Achylles> Active: active (running) since Wed 2017-11-08 16:53:54 -02; 49min ago
<Achylles> Main PID: 402 (guix-daemon)
<janneke>yes, that's the one
<Achylles>ok I will see...
<myglc2>Yo guix!
<janneke>hey myglc2
<myglc2>Hi janneke
<Achylles>I will install guix using the binary method tomorrow. My version is old...
<Achylles>thx for the help...
<civodul>janneke: hey! so i broke things on uh
<civodul>lemme see
<janneke>civodul: possibly, not sure. never sure with these things, Achylles was possibly using ancient .deb package
<mekeor>is a mcron-service obligatory for the rottlog-service to work?
<janneke>mekeor: that's how i understand it
<mekeor>thanks :)
<civodul>janneke: the 404 tarballs on are my fault
<civodul>it should auto-repair but it takes time, so i'm "forcing a repair" right now
<janneke>civodul: good
<civodul>that is, repopulating the 'guix publish' cache
<janneke>i mean...we still often present newcomers with a pretty rough start
<civodul>i agree, although there are issues i (re)discover only when i switch to a different machine
<civodul>like the glibc rebuild we discussed earlier
<efraim>is there a way to not strip the static output of a package?
<civodul>efraim: not particularly i think
<civodul>janneke: so i think it's important to identify and write down all these issues newcomers face
<civodul>because we as developers don't necessarily encounter them
<civodul>and sometimes we're just used to them, which is terrible
<janneke>that is exactly why i pinged you...we want some convergence esp. on these silly fresh install problems
<janneke>but "we" never do seems to be so much easier when you're "in"
<efraim>we can add the "static" output to the "don't strip me" list, at guix/build/gnu-build-system.scm:400
<civodul>janneke: yeah
<buenouanq>I can't guix pull right now either - Fails compiling at 75.2% `due to signal 9 (Killed)'.
<rekado>who killed it?
<vagrantc>ng0: yeah, i get that locale affects all that. heh. none of that really matters to me much. and you're not on irc now. oh well.
<rekado>vagrantc: you are vagrant of debian fame, no?
<vagrantc>ACTION still isn't convinced that C.utf8 isn't reasonable
<vagrantc>rekado: i don't know about fame, but yes, i've got some solid roots in debian :)
<vagrantc>rekado: the reproducible builds summit reminded me that i should really check out guixsd
<rekado>we usually don’t patch upstream packages with extra features; if upstream doesn’t provide the C.utf-8 locale then we also don’t – for better or worse :-/
<vagrantc>a little bumpy so far, but still really exciting
<vagrantc>rekado: it's a reasonable position
<rekado>vagrantc: yeah, looks like you already took a look at our razor-sharp corners.
<vagrantc>having a bit of trouble getting the right syntax for an encrypted disk in the installer configuration
<rekado>the initial installation is the worst part of it all. Everything else is just an acquired taste.
<rekado>fully encrypted disk?
<rekado>I have a fully encrypted disk and I unlock it with libreboot
<rekado>I can share my os config with you
<vagrantc>ACTION might be getting lost in parens
<vagrantc>rekado: does it need to decrypt the rootfs from the bootloader, or can it be done from initramfs?
<rekado>I have to decrypt it twice: once in libreboot to access /boot, then again from the initrd when booting.
<vagrantc>ACTION just took the example lightweight-desktop.scm and tweaked it a bit
<rekado>in the paste you see that I have one mapped device (line 78) and the root file system (line 83) depends on it.
<vagrantc>ACTION vague recalls grub being able to handle encrypted disks, but has never tried
<rekado>against parenthesis overload I recommend Emacs with paredit.
<vagrantc>adventures in installing within the installation system have prevented me from getting too far with that so far
<vagrantc>ACTION is just using zile so far
<rekado>right, that’s less convenient.
<rekado>for the initial installation I do recommend keeping it simple.
<rekado>reconfiguring the system after the initial install is safe and much more fun than fiddling with the installer.
<vagrantc>yeah, maybe i should drop the idea of encrypted disks for now until i get a few working installs :)
<vagrantc>ACTION has some history working on installers ... maybe could contribute at some point
<efraim>i often run `guix system build os-config.scm' to see if my syntax is right
<rekado>that would be great!
<rekado>we have an almost usable ncurses-based installer, but I’m sure there’s more that we can do in that area.
<civodul>also i really like the idea of statically detecting mistakes, providing hints, etc.
<vagrantc>also curious about the arm ports
<civodul>i'm sure we could do more
<rekado>efraim: unfortunately, we don’t have mount checks yet; so while the syntax may be fine, we can’t guarantee things will work yet
<rekado>civodul: definitely!
<civodul>rekado: we do have mount checks!
<civodul>just not kernel module checks :-)
<efraim>also, reconfigure unmounted my swap, had to remount it
<vagrantc>i've got a handful of arm devices to torture, er, experiment with
<rekado>my bad, the result was the same for me: could not mount (because of missing modules).
<civodul>we'll get there
<efraim>i'm working on the grub bits for non-intel, getting stuck with my 'match' though
<rekado>what’s the problem?
<civodul>efraim: you cannot inherit conditionally based on (%current-system)
<civodul>because (%current-system) will always have its default value at this point
<efraim>I see
<civodul>you could do a magic trick like we do for 'glibc', but that's not recommended
<efraim>It'd probably be better to have a special default grub package per architecture then
<vagrantc>hrm. i've got an instantiated system on an encrypted device, but can't get the syntax for mapped devices correct... and don't have a /boot that grub is likely to be able to read... but other than that, this is going well :)
<vagrantc>can i re-instantiate it on another device without re-downloading and recompiling everything?
<vagrantc>whenever i try to add the mapped device, i get this when running guix system init /mnt/etc/config.scm /mnt: /mnt/etc/config.scm:25:2: error: invalid field specifier
<vagrantc>this isn't whitespace sensitive, is it?
<civodul>what's on line 25?
<vagrantc>ACTION struggles to get a working setup to paste...
<vagrantc>it "works" if i comment out either mapped-device entry
<vagrantc>of course, i end up with an un-unsable system
<civodul>vagrantc: so it should be something like: (operating-system (mapped-devices (list (mapped-device ...))))
<civodul>note that the first one is plural, the 2nd one is singular
<vagrantc>will give it a tr
<vagrantc>that seems to be working
<vagrantc>should re-running "guix system init ..." multiple times be problematic?
<civodul>no, it's ok
<civodul>annoying, but technically ok ;-)
<vagrantc>alright, booting... grub managed to decrypt the disk after prompting for a passphrase, loaded kernel and initrd... but didn't find rootfs ... and i'm at a guile prompt
<vagrantc>hmmm.. comparing against rekado's config, looks like i should have added some kernel modules and maybe other things
<vagrantc>and probably added (dependencies mapped-devices) to the filesystem for rootfs
<happy_gnu[m]>I am curious
<happy_gnu[m]>how do I calculate this (sha256 (base32 "1svzlbz2vripmyq2kjh0rig16bsrnbkwbsm558pjln9l65mcl4qq"))
<lfam>happy_gnu[m]: The `guix hash` tool can calculate it for you:
<lfam>The basic use is `guix hash foo`
<kyamashita>Are there patent-related reasons why we don't build Totem and LibreOffice with gst-plugins besides base and good?
<kyamashita>Or is it a matter of something else?
<lfam>kyamashita: I don't recall previous discussions, but I think we can expect a high rate of security issues and defects in the the bad plugins
<lfam>As for patent issues, we usually ignore them
<lfam>At least, that's my understanding. I don't recall anything in Guix blocked by patent issues
<happy_gnu[m]>lfam: should I hash the .tar.gz
<happy_gnu[m]>or the git
<rekado>vagrantc: the (dependencies mapped-devices) is important
<rekado>otherwise it won’t know that it has to map the device before accessing the root file system
<rekado>happy_gnu[m]: depends on which you use
<lfam>happy_gnu[m]: You can use either one, it's up to you. If you use the Git repository, you have to check out the commit you want to build from and then use `guix hash --recursive --exclude-vcs foo`
<happy_gnu[m]>what option is the best? base32?
<happy_gnu[m]>I think is better to use the tar then
<lfam>You don't need to choose a format option
<lfam>All the packages use nix-base32, which is the default
<lfam>I'm struggling with the CMake update for core-updates. There are a handful of tests that fail non-deterministically
<happy_gnu[m]>so my package should look like this (sha256 (nix-base32 "hash"))
<lfam>No, (sha256 (base32 "..."))
<lfam>Like the other packages
<happy_gnu[m]>lfam: paste lisp is not working
<lfam>'nix-base32' is the wording used for `guix hash --format=`
<lfam>Yes, that site is gone. I recommend <>
<happy_gnu[m]>how can I send you a recipe for you to check if there is something wrong
<happy_gnu[m]>oh ok wait
<happy_gnu[m]>thats the package
<happy_gnu[m]>so I am packaging this one
<happy_gnu[m]>but I used as a base
<happy_gnu[m]>the recipe for sly, which is the deprecated package and not maintained anymore
<happy_gnu[m]>Guile-OpenGL >= 0.1.0
<happy_gnu[m]>and Guile-SDL2 >= 0.2.0
<happy_gnu[m]>and it only needs ./configure && make && make install
<vagrantc>what magic do i need to chroot into a guixsd system... the paths don't appear to be set up at all
<vagrantc>bind mount /run ?
<happy_gnu[m]>I think the '(#:configure-flags ...) are not necessary
<happy_gnu[m]>but I am not sure about (snippet '(begin ....))
<lfam>happy_gnu[m]: I don't know, either. What happens when you try to build the package?
<happy_gnu[m]>oh I have not tried it :/
<lfam>Aha! That will help you answer these questions :)
<happy_gnu[m]>ok so I should do a "guix build chickadee" ?
<happy_gnu[m]>no wait
<happy_gnu[m]>"guix build package.scm"
<happy_gnu[m]>lfam: I am not sure how to do this, I think I should have a clean enviroment right?
<lfam>Where is your code? Is it in its own directory, or is it in a Guix source code directory?
<happy_gnu[m]>oh I have a temp/ directory
<happy_gnu[m]>I have the definition there on a file.scm
<happy_gnu[m]>I have to put that on guix source code directory, with guix import ??
<happy_gnu[m]>I am reading about it
<happy_gnu[m]>but I am not sure how
<lfam>Do you want to contribute this package to Guix? If so, you should follow the steps in 'Building from Git' and 'Running Guix Before It Is Installed':
<lfam>If not, you can use `guix build --file` as described in the documentation 'Invoking guix build':
<happy_gnu[m]>oh ok
<happy_gnu[m]>I want to contribute it
<happy_gnu[m]>but I thought of testing first
<mekeor>it has been some time since i installed my GuixSD with full-disk encryption. i don't seem to have a boot partition. so how is grub encrypted and started then? – i guess grub is ony my encrypted root-partition.
<mekeor>s/how is grub encrypted/how is grub decrypted/
<rekado>mekeor: on my machine this happens through libreboot
<mekeor>how does it work on my computer? i don't understand my computer :O
<rekado>do you use libreboot?
<rekado>have you booted this system before?
<mekeor>i'm using it every day
<vagrantc>does grub prompt for a password when you boot?
<mekeor>yes. i type in my password twice. once for grub, once for linux.
<rekado>ACTION –> zzZ
<mekeor>lsblk, fdisk →
<vagrantc>ACTION would guess that grub isn't encrypted, just reads the encrypted luks partition
<vagrantc>at least, that's what i'm observing on my first grub install...
<vagrantc>er, guixsd install