IRC channel logs


back to list of logs

<pkill9>yea, i'll post a snippet
<brettgilio>leoprikler: just pushed the changes to the emacs-batch-disable-bytecomp and updated emacs-doom-themes. Thanks for your help
<pkill9>cbaines: It seems to create a package in the inferior:
<pkill9>i accidentally put in an extra parenthesis, ignore that error
<leoprikler>brettgilio: no problem
<cbaines>pkill9, ok, great. Is %package-table defined in the inferior?
<cbaines>I think you'll need to manually replicate what happens here, generating the id for the package, and adding it to the hash table:
<pkill9>cbaines: apparently it is:
<cbaines>Once you've done that, you'll want to return the id to the host Guix, which you can do as the result of the inferior eval
<pkill9>ah great, thanks!
<pkill9>so, i can see how to generate the id, do i need to add it to %package-table?
<pkill9>ah yea, i'm guessing that's what hashv-set! does
<cbaines>pkill9, how are you getting on?
<pkill9>cbaines: currently writing an scm file to see if i can get and build the inferior package
<cbaines>cool :)
<pkill9>aaaaaaand it seems to have worked :)
<pkill9>it builds a hello package with a different store hash to the one that my local guix builds
<pkill9>hmm i'll change the name just to check
<pkill9>yes it does, although it didn't show any build output, but it's produced a store path with the new name
<cbaines>Ok, great, I guess you've got an inferior-package you can use in your system configuration then?
<pkill9>here's the snippet that works when running `guix build -f <snippet-file>`:
<pkill9>yes, i should, thank you for helping cbaines
<cbaines>you're welcome. You might want to post about this to bug-guix or guix-devel. This sounds like a reasonable use case, and maybe things could be made easier by providing an easier way of registering a package within the inferior and host Guix processes
<brettgilio>aidenholmes: hey there
<aidenholmes>i have made the mistake of running an antivirus program as root on a computer with guix and it moved some files from the /gnu directory
<aidenholmes>specifically /gnu/store/xa55akvxmqaxi2xdjnwkhxmy1j7pvyb6-gdk-pixbuf+svg-2.40.0/libexec/installed-tests/gdk-pixbuf/test-images/gif-test-suite/max-width.gif
<aidenholmes>another max-width.gif file
<aidenholmes>i ran pull and package -u afterwards and they worked
<gnutec>aidenholmes, Do you use "sudo -E guix system reconfigure /etc/config.scm"?
<aidenholmes>i did not
<aidenholmes>/etc/config.scm does not exist
<aidenholmes>i'm on ubuntu
<gnutec>aidenholmes, Oh! Ok! :)
<pkill9>cbaines: ok i will
<NieDzejkob>on linux, you pretty much never need an antivirus
<nckx>…'specially a crappy one that deletes gifs without asking. You can run ‘guix gc --verify=repair’ if their absence causes any trouble later.
<aidenholmes>oh ok
<aidenholmes>running that now
<aidenholmes>did not work
<aidenholmes>reading the Nix store...
<aidenholmes>checking path existence..
<brettgilio>aidenholmes: wdym it did not work?
<aidenholmes>the command exited before doing anything
<aidenholmes>here's the full output
<nckx>aidenholmes: Try contents,repair instead? I thought repair operated at the file level but maybe it operates at the store item level only.
<nckx>It will read every byte in your store so it will take a long while.
<leoprikler>will it read the bytes individually or will it read it in chunks?
<brettgilio>leoprikler: good question. I'd assume chunks as that seems far more optimizable but with less precision? But idk
<brettgilio>I'm AFK so I can't check
<nckx>leoprikler: It's sane.
<brettgilio>Though it does not seem to be parallel. Maybe that could make it faster.
<brettgilio>I know. Not really the point. Just an observation.
<leoprikler>I don't know whether parallel gc is a good idea in general.
<nckx>brettgilio: Why do you want to murder hard drives.
<brettgilio>nckx: I'm a hard-drive murderer, son.
<brettgilio>Give me your hard-drive, and you will never see it again.
<nckx>I don't think flash/NVME particularly benefits from parallel reads at that scale either, but I've never touched 'an NVME' in my life.
<nckx>brettgilio: I destroy my own hard drives tyvm.
<leoprikler>Not seeing a hard drive again does not equal immediate destruction, though.
<nckx>Running a Guix CI box murdered my Samsung SSD in less than 2 years.
<nckx>Yeah, maybe your torture them slowly.
<leoprikler>Perhaps for two years or so :)
<derzen[m]>Sorry for asking twice, but
<derzen[m]>Does Guix have crypttab support? Couldn't find any information
<nckx>derzen[m]: Nope, not at all.
<derzen[m]>That's bad
<derzen[m]>Thank you
<nckx>We also don't have fstab support and we've survived so far.
<nckx>You can still use LUKS.
<derzen[m]>What? How is this possible to not have fstab support?
<derzen[m]>I mean, I saw I can write some mount options in config, so this should affect fstab
<derzen[m]>Btw, what about f2fs support for root? I heard somewhere that guix can only support ext4 and btrfs
<nckx>derzen[m]: It does, in that an /etc/fstab is created at boot time with those mount options in it, but no part of Guix actually uses that fstab file. It's just for compatibility.
<nckx>However /etc/crypttab is different and we don't bother generating one.
<nckx>derzen[m]: Yep, so far. I have patches to support JFS and bcachefs, too, which I'll submit soonish. F2FS patches welcome! 🙂
<derzen[m]>Ah, I thought guix doesn't work with fstab at all. By the way, you said that it's for comparability, then how it should be done normally?
<derzen[m]>Oh, and also, my two final question. Could I passthrough GPU to VM in Guix? And could I use flatpak (just because not all software is available for now)?
<leoprikler>"Compatibility" probably means compatibility with programs that rely on fstab existing for themselves to work
<nckx>derzen[m]: Guix doesn't ‘work’ with it, it only writes it for compatibility with other programmes that expect it to exist.
<nckx>I can't think of an example, but think mtab in the olden times.
<leoprikler>Hah! This time I was quicker 🙂️
<leoprikler>You can use flatpak, but it's kinda weird and you're restricted to --user stuff.
<derzen[m]>What about GPU passthrough?
<nckx>derzen[m]: What is required to support that?
<nckx>And Guix guest or Guix host?
<pkill9>ive run a flatpak application
<nckx>(Or both.)
<derzen[m]>Guix as host
<derzen[m]>Thats what I use on debian
<nckx>That's mostly between your kernel and virtualisation software. As far as distro is concerned: you would set vfio_pci.ids=10de:1b80,10de:10f0 on the kernel command line instead of in the Debian-specific /etc/initramfs-tools/modules, and load the module in the same spot (your system .scm). I'm not sure how to blacklist modules.
<nckx>(kernel-arguments (list "avfio_pci.ids=10de:1b80,10de:10f")) and (initrd-modules (list "vfio_pci")), something roughly like that.
<derzen[m]>Hm, thanks, I will try
<derzen[m]>By the way, if scheme is a programming language, then I can populate text file from the config? What if just I populate /etc/crypttab?
<derzen[m]>Because as I know, crypttab is a part of cryptsetup package, no?
<nckx>derzen[m]: You can create whatever file you want in /etc (or elsewhere) from your system .scm, yes. But no part of Guix is designed to read it. Guix only handles its own native (file-system …) and mapped-devices record syntax.
<derzen[m]>But should it read? Or cryptsetup will work after Guix will do all the mounting job?
<nckx>derzen[m]: Guix calls cryptsetup luksOpen (or whatever the new syntax is) on any LUKS devices configured in your system .scm.
<nckx>It does not run the cryptsetup equivalent of ‘mount -a’, if that even exists.
<nckx>The cryptsetup manpages contains no mention of crypttab.
<nckx>‘The /etc/crypttab file format is based on the Debian cryptsetup package, and is intended to be compatible.’
<derzen[m]>>The /etc/crypttab file format is based on the Debian cryptsetup package, and is intended to be compatible.
<derzen[m]>But maybe I just read it wrong
<derzen[m]>I just finding ways to not enter password 6 times at every boot
<nckx>Heh, now I was first.
<nckx>So yeah, it's a Debian thing.
<bandali>being able to not type non-root luks passwords in multi-partition setup sure would be nice
<nckx>derzen[m]: I have an encrypted disc, and I enter my password twice each time I boot my laptop (in 2 different keyboard layouts, even, much secure™). There's no way around that for now.
<bandali>same with ^
<derzen[m]>2 times would be fine for me, hah
<nckx>bandali: How is that secure? Of are you assuming encrypted / with unencrypted keys for the other drives?
<nckx>derzen[m]: Well, I mean I enter my LUKS passphrase twice, then have slim auto-log me in to X because I'm not a masochist.
<nckx>(slim is a display manager.)
<derzen[m]>Yeah, I know, I already installed Guix in VM in graphics mode
<nckx>If your 6 was literal, that sounds wrong.
<derzen[m]>So I see how it's working for user
<nckx>The default is GDM now though.
<bandali>nckx, yes, i have an encrypted / which includes /boot. i'd like 1. the initramfs to be able to hold and pass my / password to the kernel, and 2. have a crypttab-like mechanism to unlock additional partitions using keyfiles stored somewhere in /
<derzen[m]>I have 5 drives
<nckx>bandali: Right. 1. is on my wishlist but not pressing enough to write myself, 2. seems like a simple extension of that.
<nckx>derzen[m]: Oh boy.
<nckx>Personally, I'd just unlock that in my .xsession or whatever.
<derzen[m]>I just love to keep everything with me :)
<nckx>It's ugly, but it's currently either that or write patches for Guix.
<gnutec>Just install red-eclipse and is really god. Light and 60fps shotter game. Not need Call of duty anymore.
<bandali>nckx, ha. if i had a clear picture of how it'd be implemented, i'd have given it a shot
<bandali>though alas my guile-foo is still not as good as i want it to be (working on it)
<gnutec>Try flare-game too.
<derzen[m]>Yeah, thats a way, but I would have to enter password for 3 times (/home on another drive)
<nckx>gnutec: I agree with the sentiment (it's fun but buggy at times), but am confused by the context.
<derzen[m]>I better to stay without encryption then for now
<gnutec>nckx, hahahahaha *god is *good and *shotter is *shooter.
<nckx>gnutec: I really enjoy xonotic to blow off steam & stress.
<derzen[m]>Try openspades, it's not bad
<nckx>bandali: Are there any 'better' mechanisms than storing the unencrypted root key in an initramfs on the encrypted root volume? I've never used that set-up, so maybe that's why it sounds fragile & error-prone to me.
<nckx>Maybe that's just prejudice tho' 🙂
<gnutec>nckx, It's first time I install and play red-eclipse
<bandali>nckx, hmm, i'm not sure? isn't that how debian does it?
<nckx>I tried it on my previous laptop but that was too slow. Installing it on my ThinkPad now.
<nckx>bandali: Dunno.
<gnutec>nckx, I did no about xonotic. But I played Urban Terror a lot.
<bandali>last time i was looking into this stuff, this page was very informative:
<bandali>don't have much time to read through it right now, but it may be useful if someone else does :)
<bandali>but the introductory paragraph on suggests that storing a copy of the password/keyfile in the initramfs seems to currently be the only option
<gnutec>nckx, xonotic Is big. I have not internet. Maybe next time.
<nckx>bandali: That was my conclusion when I last looked into it, I just didn't like the conclusion :-p However, I'm now moving away from less-secure LUKS towards more secure file-system-level encryption.
<bandali>nckx, hehe :p
<bandali>i think they're each valuable in their own way
<nckx>I guess FDE can uniquely provide plausible deniability, but I'm just sceptical that's still a thing at all.
<nckx>Eh 🙂
<nckx>In far more exciting news, guix pack red-eclipse has finished, so if you don't hear from me I approve… and good night.
<bandali>o/ night
<gnutec>nckx, :P
<nckx>Supports instagib. nckx-approved. 'night o/
<Parra>does anybody has a non-gnu version or similar for netcore (coreclr)? I need that package
<Parra>it is present on nixos but I can't find it for guix:
<gnutec>Parra, no
<gnutec>Parra, if is not present in guix, is cause no 100% free.
<brettgilio>gnutec: that isn't even remotely true. Just because something is lacking in guix does not immediately mean it is because it is non-free.
<brettgilio>And last I checked, netcore is libre.
<brettgilio>For example, icedove is missing in guix. Icedove is official GNU software. But since it is missing, by your logic, "is cause no 100% free".
***apteryx_ is now known as apteryx
<gnutec>brettgilio, you're right.
<brettgilio>gnutec: sorry if I came off as rude. I'm a bit tired, and wanted to clarify the logic. :)
<brettgilio>I reread it and I think I sound like an asshole
<raghav_gururajan>Hello Guix!
<gnutec>brettgilio, hahahahaha I just say you are right for real. I'm lazy to write about all this.
<raghav-gururajan>sneek: later tell ScaredySquirrel: For WiFi, For Bluetooth,
<raghav-gururajan>sneek: later tell bandali: Saw that you are looking for freedom WiFi Card, check out
<sneek>Got it.
<sneek>Welcome back bandali, you have 1 message.
<sneek>bandali, raghav-gururajan says: Saw that you are looking for freedom WiFi Card, check out
<bandali>raghav-gururajan, thanks!
<brettgilio>sneek: tell bandali he is a cool dude.
<sneek>bandali, brettgilio says: he is a cool dude.
<brettgilio>Thanks sneek
<bandali>sneek, tell brettgilio likewise you :)
<sneek>brettgilio, bandali says: likewise you :)
<bandali>sneek, botsnack
<raghav-gururajan>bandali Welcome!
<raghav-gururajan>sneek you deserve another botsnack. Just don't get fat. :-P
<roptat>hi guix!
<raghav-gururajan>roptat o/
<alloy>Hey Guix! I'm trying to cross-compile a package I defined myself. Because it uses cc as the compiler I set CC=gcc inside the make-flags. How can I generalise it to use for example armhf-linux-gnueabi when cross-compiling for the armhf-linux target?
<roptat>alloy, I don't really know, but doesn't the gcc cross-compiler provide a gcc binary too?
<roptat>I'm a bit surprised, but I never tried cross-compilation myself...
<alloy>I see, it probably does. Still trying to get guix environment working for cross environments, i was surprised it is missing a --target flag
<raghav-gururajan>roptat Do you have commit rights?
<roptat>raghav-gururajan, I do
<raghav-gururajan>roptat Cool! would you be able to have a look at the patch for gnome-themes-extra and push it please?
<roptat>can you remind me the bug number?
<raghav-gururajan>Sure, just a sec.
<raghav-gururajan>#38763 (
<roptat>I need to afk, I'll do that later
<raghav-gururajan>roptat Cool!
<NieDzejkob>nckx: how is fs-level encryption more secure?
<alloy>Back to my cross-compilation problem.. I think I now know what is going on. I set CC=gcc and there is a native gcc included inside the search path when cross compiling, so it uses the native gcc instead of the x86_64-linux-gcc to build and therefor fails. Any idea how to set CC= always to the 'correct' gcc?
<leoprikler>alloy: (if target (cross-gcc target) gcc) ?
<leoprikler>alternatively there should be a "cross-gcc" input if you're using gnu-build-system
<slyfox>alloy: re2 has a example of passing cross-CXX
<alloy>slyfox: That was what i searched for, thank you both!
<Parra>gnutec: I will package it myself then, but netcore is opensourced at the moment
<nixo>Hello guix! I've upgraded aspell to the latest version (, how do I check if all dependent packages build?
<roptat>raghav-gururajan, from what I understand, you can't have both gnome-theme-standard and gnome-theme-extra, right?
<roptat>standard is a subset of extra maybe?
<roptat>also, the description should contain full sentences, and probably explain the difference between this package and gnome-themes-standard. Can you come up with something? then I'll push for you :)
<NieDzejkob>Is the guix boot process documented somewhere? Does the initrd stage use shepherd, like, for mounting the filesystems?
<NieDzejkob>(I'm asking because I'm trying to come up with a good design for mounting LUKS volumes with key files
<NieDzejkob>I think I'll need some way to specify dependencies between mapper-devices and filesystems
<NieDzejkob>or I could make it cycle between finding mapper-devices and filesystems that have become possible to mount...
<roptat>there's a notion of dependency already I think
<pinoaffe>i'm trying to package a tool that uses qt, is the list of all qt headers included throughout the codebase, how can I figure out which qt packages I need?
<str1ngs>pinoaffe: start with qtbase atleast. does the project have qt.conf file?
<str1ngs>pinoaffe: sorry I meant a project file with extension pri
<str1ngs>actually it's pro
<pinoaffe>str1ngs: there are some .pro files, but they're in a /3rdparty folder
<str1ngs>pinoaffe: what what qt package is this?
<str1ngs>pinoaffe: seems it's mainly using qtbase to me
<str1ngs>it's using cmake vs qmake
<raghav-gururajan>roptat gnome-themes-standard is depracated. Whatever was in it, has now become part gtk+. Some additional things that did not fit anywhere else has now put into gnome-themes-extra.
<raghav-gururajan>roptat * part of gtk+
<raghav-gururajan>roptat So in other words, most part of gnome-themes-standard was moved to gtk+(3) itself, and remaining part of gnome-themes-standard was made as gnome-themes-extra.
<raghav-gururajan>roptat May be we can use the gnome's original description for that package: "Themes and theme-y tidbits that don’t really fit in anywhere else, or deserve their own module."
<roptat>raghav-gururajan, ok... should we remove gnome-themes-standard then?
<raghav-gururajan>roptat Yes :-)
<raghav-gururajan>roptat Also, the meta-package 'gnome' has to be revised. It still follows 3.2x stack instead of 3.3x stack. I have already submitted a patch for that. :-)
<roptat>mh... I'm not a gnome user, so it's hard for me to understand the implications...
<raghav-gururajan>Let's worry about the 'gnome' now. We'll first finish the 'gnome-themes-extra'.
<raghav-gururajan>*Let's not
<preciouscookie>Hi guys! I was wondering if it possible to play YouTube vids in Guix.
<raghav-gururajan>preciouscookie youtube-dl, youtube-dl-gui and youtube-viewer :-)
<roptat>and icecat can do it too
<pkill9>and so can chromium (ungoogled-chromium is the package)
<roptat>raghav-gururajan, what do you think of "This package provides themes and related elements that don't really fit in other upstream packages. It offers legacy support for GTK+ 2 versions of Adwaita, Adwaita-dark and HighContrast themes. It also provides index files needed for Adwaita to be used outside of GNOME."
<raghav-gururajan>roptat That sounds perfect. Thanks!
<preciouscookie>Thanks for your answer but my problem is something different. I'm trying to manually define dm service without %desktops-services so it is probablly the reason why system lacks of some packages. Cause IceCat along with Vimb, Next and Qutebrowsers don't play html5 vids at all. So I thought Guix doesn't support any of them...
<preciouscookie>pkill9 Wow, I'll try right now
<roptat>preciouscookie, it should work without anything else in your environment...
<roptat>maybe a configuration issue?
<roptat>(in icecat I mean)
<pinoaffe>str1ngs: thanks, it seems like that is indeed enough
<preciouscookie>roptat Probably. Anyway I'll try ungoogled chromium and other browsers for now.
<pinoaffe>roptat: for me, some youtube videos don't work in icecat either, and that's been the case for a long time
<pinoaffe>it also has some issues with fonts, but I don't really mind those
<preciouscookie>pinoaffe Try noto fonts or something like that. It helped me.
<roptat>raghav-gururajan, done!
<raghav-gururajan>roptat Awesome! thanks so much. I appreciate it. :-)
<roptat>preciouscookie, maybe try to set security.sandbox.content.read_path_whitelist to /gnu/store/ (with the trailing / to mean recursively) in about:config and restart icecat (also make sure your icecat is very recent, since we fixed ffmpeg support only a few days ago)
<roptat>it helped me with webgl, but maybe it could also help with loading ffmpeg libraries, I don't know...
<raghav-gururajan>Out of 20, 4 done, 16 more to go.
<preciouscookie>roptat Thanks but ungoogled-chromium works just perfect so I'll stick with it. pkill9 Thanks again!
<NieDzejkob>woah, noto fonts are almost a gigabyte! (736MiB to be exact)
<preciouscookie>Yeah, hard to be minimal with this thing. But at least it covers all the languages you'll need.
<pinoaffe>the project im packaging depends on icestorm, and I need to add the path to the icestorm root as a cmake argument, how do I get the string corresponding to the path?
<NieDzejkob>hmm, I'm trying to package xsecurelock, and it uses a setuid helper in libexec/authproto_pam, which doesn't really fit into the model of setuid binaries that get put into $PATH. What would be the best way to solve this problem? Should I patch the package to look for the binary in /run?
***ng0_ is now known as ng0
<roptat>pinoaffe, in a phase you can use (assoc-ref inputs "icestorm") if you have an input named icestorm
<roptat>or in the #:cmake-flags argument, you can use (assoc-ref %build-inputs "icestorm") I think
<gnutec>It is possible play red-eclipse 1.6 with 2.0 online? I think people is change to 2.0.
***freedom is now known as gnufr33d0m
<preciouscookie>Hello guys. Some of the programs don't recognize fonts that are installed from config.scm but those which were installed for user profile are available. Is there anything can be done to make them availabl
<NieDzejkob>What's the procedure for package updates? I just noticed that vim is packaged on version 8.1 while 8.2 is available
<roptat>clone the repository, update the version number and hash of the sources, check that it builds and runs fine, then send a patch
<NieDzejkob>OK, will do
<ScaredySquirrel>ok question
<sneek>Welcome back ScaredySquirrel, you have 1 message.
<sneek>ScaredySquirrel, raghav-gururajan says: For WiFi, For Bluetooth,
<PotentialUser-52>I'm still having this issue w/xmonad:, if there are any xmonad and guixsd users around. Haven't turned much up other than, which I don't fully understand (seems like a change to .xsession or .profile might fix things)
<nckx>NieDzejkob: The most recent vim (8.2.0051) has a test failure (‘function RunTheTest[40]..Test_strftime line 32: Expected not equal to '18'’) that nobody's bothered fixing yet.
*nckx included.
<NieDzejkob>Expected not equal to '17' for me
<NieDzejkob>I also get "function RunTheTest[40]..Test_swapfile_delete line 40: Expected '' but got '.XswapfileText.swp'" and "Flaky test failed too often, giving up", though
<nckx>Possible, my notes are not very complete.
<NieDzejkob>I think I'll try to bisect the failure
<apteryx>hello! Recently on one of my machine, when trying to unlock an encrypted drive with udisks, using 'udisksctl unlock -b /dev/sdb', it prints the message: Object /org/freedesktop/UDisks2/block_devices/sdb is not an encrypted device.
<apteryx>It works expectedly on another Guix System (prompts for the passphrase)
<apteryx>has anyone seen this?
<NieDzejkob>maybe it's not /dev/sdb but some other letter
<NieDzejkob>what does blkid say?
<apteryx>it really is sdb; lsblk says 'sdb 8:16 1 14.8G 0 disk'
<apteryx>and there's a partition on sdb1 but the device itself is LUKS encrypted
<roptat>I wonder, do you have a running dbus? or maybe polkit?
<kirisime>Which package provides the host command?
<sneek>kirisime, you have 1 message.
<sneek>kirisime, raghav-gururajan says: Not yet I am afraid. The file-previewing/thumbnail is provided by 'sushi' along with 'gsettings-desktop-schemas'. The patch adds the latter to gnome, but the former is not packaged yet.
<roptat>kirisime, I have it from bind:utils
<roptat>the name "/org/freedesktop" looks like a dbus thing, that's why I'm asking
<kirisime>My guix not being able to resolve hostnames when using git-fetch to download package sources hasn't gone away by waiting or doing a guix pull.
<roptat>and I kind of rememember udisk is related to polkit, so maybe it's not permitting it access?
<roptat>kirisime, is that specific to guix, or other things are failing?
<kirisime>roptat: Just guix git-download/fetch and only when I'm writing a new package.
<roptat>oh, that's really weird...
***KE0VVT_ is now known as KE0VVT
<roptat>so what is different between using guix for a new package and for anything else?
<kirisime>Berlin doesn't have source mirrors.
<kirisime>Or something similar.
<kirisime>After failing to determine the host guix attempts to use a content-addressed mirror at, then software heritage, which finally fails because "Servname not supported for ai_socktype".
<roptat>arg my connection is unstable :/
<roptat>"Servname not supported for ai_socktype" reminds me of something
<roptat>I'm not sure, but I think I got that because of a missing /etc/services or /etc/protocols
<roptat>so probably unrelated...
<Parra>hey guys has anyone tried guix pack with i686-w64-mingw32 target?
<roptat>Parra, we try to avoid "hey guys" because we're not all guys here :) try "hey guix" next time ;)
<roptat>I have never tried though
<roptat>so I'm afraid I can't help :/
<Parra>I just try to be nice
<roptat>yeah I understand, it was just a friendly advice :)
<kirisime>roptat: I tried the same thing on another machine (guix on ubuntu) and got the same error.
<kirisime>Can you try placing a dummy package definition in a file and building it with `guix build -f'?
<kirisime>All it needs is to fetch sources using git, even the url being valid doesn't matter.
<roptat>I thought you were going to give me a package definition, so just a moment :)
<roptat>so, no issue with that on my side, only an http error since the url is not valid
<kirisime>How old is your guix?
<roptat>then it tries content-addressed mirrors at berlin, and finaly software heritage
<roptat>but no resolution issue
<roptat>guix describe says december 24
<kirisime>I was definitely having this problem back then already.
<roptat>my daemon is probably a bit older, since I'm on a guix system is your issue very recent?
<kirisime>I noticed it late this month.
<kirisime>Today I've done a guix pull on both my user and root profiles, and done a reconfigure and the issue persists.
<roptat>so we should have the same daemon...
<kirisime>How do I give guix describe the previous profile?
<Parra>I want to know about how guix package works, and how it supports the targets, do you have any reference about internals?
<kirisime>Does the daemon reload on a system reconfigure or must I remember to do it myself?
<roptat>guix describe -p should work
<Parra>guix pack*
<roptat>I think you should restart it yourself
<roptat>or reboot
<roptat>Parra, mh... it's basically building a profile and then compressing it to a tarball or another format
<Parra>but it has targets
<Parra>it should rebuild with cross-compiling capabilities
<Parra>I'm dealing with software that may be problematic with that
<roptat>isn't target part of the common build options? I think there's a section on that in the manual
<Parra>for example, netcore cannot be cross-compiled to windows with gcc, it needs visual studio ++
<Parra>in fact, in linux it should be compiled with clang instead of gcc for example
<Parra>I'm planning to package netcore
<kirisime>Rebooting is the only blind shooting approach I can try by now.
<roptat>Parra, you could specify clang in a guix package, but I don't know how to specify a compiler depending on the target
<roptat>that's probably what you'd need to have a working guix pack
<roptat>I think if guix build works, guix pack should work too, with the same options
<Parra>I will investigate
<Parra>in any case cross compiling will be impossible in netcore
<Parra>mingw isn't supported by netcore, maybe clang can cross-compile but I should check it out
<Parra>I will investigate
<Parra>I think Guix is awesome, and the I have to package some difficult runtimes that will be interesting to Guix
<Parra>I will publish my investigations
<Parra>by the moment I have achieved this:
<Parra>it works on linux and amd64, it provides a complete self contained version of metacall
<Parra>with ruby, python and nodejs
<roptat>is that built with guix?
<Parra>guix + docker
<roptat>wow, so cool :)
<Parra>docker is only to make it portable among different ci/cd
<Parra>it's a Polyglot, if a Polyglot can be packaged with guix, it means it's the definitive package manager
<Parra>I still think I may have problems but let's be positive, I'm very paranoid with software
<kelsoo>Hello there guix people. I have a new install of guix-1.1 but can't get icecat. Seems to be something with rust. It tried to build rust versions from 19-37 iirc but failed. Any ideas
<roptat>hi kelsoo, you should probably update your guix. after you run guix pull, you'll have a new version of icecat available
<roptat>iirc 1.0.1 used icecat 60, we have 68 now
<roptat>also mrustc was updated, so you won't have to build the whole chain from 19
<roptat>(and you may have more luck with substitutes)
<kelsoo>I did that: guix pull the guix package -U iirc it was trying to build 68
<kelsoo>mrustc ? forgive me I'm not technical
<kelsoo>I've done nothing to change the system atm. bar pull and update
<str1ngs>kelsoo: are you on guix system or foreign distro?
<kelsoo>It complained about locales but my locales are working as expected.
<kelsoo>on guix
<str1ngs>guix system you mean? just to clarify
<kelsoo>freash install of 1.1.iso
<str1ngs>okay good to know thanks
<pkill9>hello guix
<kelsoo>just installing mrustc
<roptat>you don't need to do that by yourself
<roptat>also, have you disabled substitutes?
<roptat>you should receive binaries from the build farm instead of rebuilding everything
<str1ngs>it's possible because it's 32bit substitute binaries do not exist?
<roptat>ah right
<str1ngs>guix weather should help determine this?
<roptat>I think so
<roptat>weather says icecat is not built on berlin for i686
<str1ngs>guix weather mrustc --s i686-linux exists though?
<kelsoo>It seem quit a few packages are being compiled locally
<roptat>i686 is less well supported by the build farm
<str1ngs>I get the same for icecat roptat
<kelsoo>That's fine. I have 5 32bit machines, it's nice to have ant support
<str1ngs>you can set them up to offload :P
<roptat>that's exactly what I was going to say
<kelsoo>I have no idea what that means :-)
<roptat>offloading means having builds distributed among multiple machines
<kirisime>kelsoo: It means that whenever you other computers are down you won't be able to do anything
<roptat>instead of doing just one package at a time, you can build one package per machine at a time, which is better :)
<roptat>you can always specify --no-offload to build locally instead of offloading to other machines
<kelsoo>mrustc has built. I'll try rust again
<roptat>I don't think icecat is using the latest rust
<roptat>just build icecat, guix will build the rust it needs
<kirisime>roptat: make check --no-offload doesn't work when working on the guix source though. It should really just fall back to not offloading if no machine is available.
<roptat>can you report a bug for that?
<kirisime>That's just where I got rid of my offload setup. If there's a way to supply configuration file paths then I'm not sure if it'd qualify as a bug.
<kirisime>It's like, you could either fallback to local building or have the test suite always pass --no-offload, and both would fix not being able to run the test suite when your builders are offline.
<kirisime>Is that two bugs?
<kelsoo>Also. Is there a correct place to request missing (wishlist) packages?
<kirisime>Well for all I know my guix is just broken then.
<kirisime>Reboot time.
<roptat>kelsoo, there's
<kelsoo>here's hoping lynx works :-)
<gnutec>Ok! "guix environment"
<NieDzejkob>Is it possible that during the test suite, vim gets PID 1 in the container?
<NieDzejkob>One of the failing tests has a comment "Process one should never be Vim", and adding a patch to change 0z01000000 to 0zdead0000 makes the test pass
<NieDzejkob>ah, that's not even what matters, but that PID 1 is the same user
<leoprikler>That's how you recognize an inferior text editor. You can't even use it as init.
<NieDzejkob>it's not that you can't, it's just that its test suite assumes you won't
<nckx>What a weird test.