IRC channel logs


back to list of logs

<nckx>krafter: You think that (append %base… (list "your" "modz")) would work? I've mucked around with modules *quite* a bit and have never had to order them; but who knows.
<krafter>As you might understand, I am reluctant to try things that *might* work.
<nckx>Dependeny resolution is implemented.
<nckx>krafter: But as you probably understand, I'm reluctant to promise anything *will* work ;-)
<nckx>Let me see what my VM says. Maybe lsmod gives different (canonical) names.
<nckx>Damn. No.
<nckx>vfio_pci should be vfio-pci.
<nckx>Yes, *only* -pci. The rest uses underscores. The wonderful naming constistency of the kernel Linux at work.
<nckx>modprobe automatically changes the name; we don't; let's argue about who's right on the mailing list :p
<nckx>krafter: So once you get your system to boot, make that one character change, reconfigure, and all will very likely be well.
<nckx>find /run/booted-system/kernel -name "vfio*.ko"
<krafter>I am happy to maybe have found a solution.
<nckx>is how I found that, by the way.
<nckx>I can't give you more than maybe. Sorry. I know doing all this on bare metal is tedious.
<krafter>You have always been most helpful.
<nckx>I'm currently unable to program so I make myself useful here 😊
<krafter>nckx: My guess is that you have at least written a .scm file.
<nckx>Naming/mangling aside; this is a bug in my book. Failing to load a module should print a big fat warning but not be fatal.
<nckx>krafter: I've written several, before smashing myself into the road at high speed and the road pretty much winning that round. I'm at home with broken $limbs and a whole lot of painkillers. These make me both unable to concentrate (no coding) and extremely chatty (hello IRC). And there we are.
<krafter>Sounds like fun.
<nckx>(The above said, I wonder if hitting ^D at the REPL would have continued booting without that module. Hm. Never tried.)
<nckx>Oh, it was.
<pinoaffe>I'm trying to use gnupg in guix, but basically anything I run fails with some variation of "gpg: agent_genkey failed: No pinentry" - how do I make gnupg find/use *any* of the pinentry programs I have available?
<nckx>pinoaffe: /home/nckx/.gnupg/gpg-agent.conf:pinentry-program /home/nckx/.guix-profile/bin/pinentry-tty
<nckx>Works for me.
<nckx>krafter: Where did you find the ‘vfio_pci’ spelling? It's technically ‘wrong’, even though it works with modprobe.
<krafter>nckx: Arch-wiki:
<nckx>(Then again, ‘lsmod | grep vfio.pci’ returns ‘vfio_pci’ despite that not being the file name, so maybe we just buy into modprobe's lies completely. That would work too. At the expense of more complexity.)
<nckx>krafter: Interesting that the URL anchor *is* correct 😃
***ym555_ is now known as ym555
<krafter>Inconsistancies everywhere!
<nckx>krafter: Were you able to boot into an older generation to reconfigure?
<krafter>I am logged into the same PC I am trying to configure.
<krafter>So, I will try to make a VM image and see if I can get that to boot first.
<pinoaffe>nckx: I have such a line in my gpg-agent.conf file, but it still does not work
<nckx>A good habit. ‘guix system vm’ doesn't generate an image, by the way, it uses store files directly. It's pretty light-weight. Just so you know.
<nckx>pinoaffe: Do you have ‘use-agent’ in you gpg.conf?
<nckx>I don't see anything else that could be at all relevant.
<nckx>And it just works here. The path above assumes pinentry-tty is installed into your user profile but you probably knew that much.
<pinoaffe>nckx: it's in my user profile, and there's no ~/.gnupg/gpg.conf file, adding it with a sole "use-agent" line does not help either
<nckx>pinoaffe: Does ‘gpg --sign /some/existing/file’ work?
<pinoaffe>fails with the seemingly unrelated error "no secret key"
<nckx>Hum. Then I don't know either. It's not that my GPG configuration is that baroque; just gpg + agent + pinentry and cipher/keyserver preferences in gpg.conf. That's it.
<nckx>pinoaffe: I'm assuming you know how GPG works in general and actually have a secret key, &c.
<pinoaffe>I had a previously functioning set-up on gentoo, I first tried to merely copy that .gnupg directory over but ran into the missing pinentry issues
<ItsMarlin>nckx a guy at the mailing list told me he had to use the binary blob for his radeon :c
<pinoaffe>nckx so when I re-run `gpg --sign <file>` with those secret keys in the .gnupg folder it yet again fails to find a pinentry program
<nckx>pinoaffe: Weird? What happens when you copy & paste (just to rule out typos) the full path to your pinentry-tty into a terminal? Should print ‘OK Pleased to meet you’.
<nckx>ItsMarlin: I found the thread. What can I say. Sucks ☹
<pinoaffe>nckx: yeah, it does
<ItsMarlin>i have no idea on how i'm gonna do it
<ItsMarlin>i think i'll ask somebody that has one of the custom builds for help
<nckx>pinoaffe: Then, to be honest, I haven't a clue what's wrong. I never really had trouble setting up gpg on Guix, aside from having to add the full path to pinentry, so I've never had to debug it.
<pinoaffe>okidoki, thanks for all the help
<nckx>pinoaffe: You can always send a (unsigned, har har) mail to
<nckx>#guix tends to operate on European time still, although is busier than it used to be now.
<nckx>ItsMarlin: Thanks for understanding that we can't provide support for that here. It sucks, but it's not because we hate users, quite the opposite.
<ItsMarlin>i wish linux libre didn't have the bug for not allowing blobs
<ItsMarlin>i didn't wanna have to compile vanilla
<ItsMarlin>maybe amd will release these blobs someday
<nckx>I wish I shared your optimism, but I certainly wish it.
<nckx>ItsMarlin: Compiling Linux isn't the grandest hobby in the world but it shouldn't take more than half an hour on ‘modern’ hardware.
<ItsMarlin>do i have to package it?
<nckx>I'm not someone who will skirt the rules while winking so it's OK
<nckx>so I won't
<ItsMarlin>Oh ok, sorry
<nckx>but I can honestly say you're not the first one to want to run a stock kernel
<ItsMarlin>i guess it's more of a have, i'd like to use libre if my gpu worked :/
<nckx>and many people publish their configurations on the Web
<nckx>that's me being very subtle. It's not my strong suit ;-)
<nckx>ItsMarlin: Sure. And I'm not sure how much of works now (can you even use that machine at all?), but modesetting is a really shitty bar to stuff into blobware. Wouldn't want those precious VESA mode trade secrets leaking out 😒
<b0f0>the standard procedure here is write a package for the program, so nobody git clones a program from or something like that ?
<b0f0>I mean you do git clone, but in a package discription i guess
<b0f0>something like that
<nckx>b0f0: You can specify a git repository as the SOURCE, yes, but I guess that's not what you meant?
<nckx>You can't ‘guix install’, no.
<nckx>To much guesswork.
<nckx>Some day, when each project ships a ‘guix.scm’ build file in their repo, this could certainly work ;-)
<b0f0>anyway it would be good for me to learn to write a package discription on my own ... I found aerc2 its a new mail program from the same person that wrote i3wm and sway I think. SO if I want to try it just that, to see if its good for me, what would you do ?
<b0f0>aynway I will learn it, have to read the manual ..
<nckx>b0f0: I see that it's a Go programme; and I'm not too familiar with Go. I'd start with copying an existing package that uses the go-build-system and modifying it. Learn by doing, keep the manual close. That's how I learnt Scheme at all.
<nckx>And look at me now, making big $$$ in the Scheme industry!
<b0f0>really ? I never thought scheme is usefull in industry ? Can you tell me what are you working on ? Because everybody use python javascript c++ c and so on. So this is a first for me that someone says what you said.
<nckx>b0f0: Sorry, I was being stupid & sarcastic. It's a weakness of mine. I wish it were true, though.
<b0f0>yes for I wish it were true too.
<nckx>Scheme has spoiled me for ‘useful’ languages. I've heard of (small) Haskell shops delivering commercial projects though, which is cool.
<nckx>b0f0: And people do use Guix ‘in production’; it might be the largest deployed Guile codebase in existence. Actually, it probably is.
*nckx → push some updates & 😴, good night.
<b0f0>good night
<ItsMarlin>bye nckx
<ItsMarlin>night night
***wxie1 is now known as wxie
<eabarbosa>hey, my config.scm file should work fine in guix 1.0? ty
<brendyyn>how can we know that?
<eabarbosa>brendyyn: its worked under fine in .16... lol
<eabarbosa>my bad, for not providing any reference
<eabarbosa>well, its seems nothing have been changed for references its a go! thanks anyway!
<rekado_>OriansJ: line 3 looks suspicious. “~/guix” is not the same as the cloned directory, is it?
<rekado_>OriansJ: does the directory at GUIX_PACKAGE_PATH override modules provided by Guix? If so, that’s likely the problem here.
<rvgn>Hello Guix!
<rvgn>I tried installing the package"balsa" several times but always the process exited with error code:1
<rvgn>What should I do?
<rvgn>I have also tried passing --cores=N, but same result.
<mfg>gpg doesn't import my pgp key with "sending to agent: no pinentry", i'm running from the shell so i read that i should set in /etc/gpg-agent.conf the path to pinentry-curses ... is this really necessary and if so how would i configure that in guix style?
<mfg>it even doesn't work using pinentry-tty package
<rekado_>rvgn: what does the log say?
<rvgn>rekado_ I will have to get back to you regarding that.
<mfg>sry had to reboot, did someone reply?
<mfg>i found a mail on the ml from 2013 which says one should use --pinentry-program ... as i want to use gpg with emacs and on the commandline this doesn't work
<mfg>(makes emacs freeze)
<rekado_>mfg: my .gnupg/gpg-agent.conf contains this line:
<rekado_>pinentry-program /home/rekado/.guix-profile/bin/pinentry-gtk-2
<mfg>i will try
<mfg>thx this works
<matt`>I'm trying to get a system install working in a VM. However, when running guix system init I
<matt`>get "failed to install bootloader". Just above that it says i386-pc/ doesn't exist. This
<matt`>seems to be related to this help mailing list post:
<matt`>basically, looks like qemu is sending me into legacy boot rather than uefi
<matt`>i checked and /sys/firmware/efi doesn't exist
<matt`>is there a way to get qemu to use uefi rather than a legacy boot?
<matt`>my qemu command is:
<matt`> qemu-system-x86_64 -m 1024 -smp 8 \
<matt`> -machine type=q35,accel=kvm -cpu host \
<matt`> -net user -net nic,model=virtio \
<matt`> -boot menu=on \
<matt`> -drive format=raw,file=guix-system-install-1.0.1.x86_64-linux.iso \
<matt`> -drive file=hda.img \
<matt`> -drive file=hdb.img
<mfg>install ovmf and use the -bios option
<mfg>i don't where the ovmf bios is in the guix filesystem, i have only used it on other linux distros with traditional pathnames ...
<mfg>there it would be like /usr/share/OVMF
<mfg>*/usr/share/OVMF/ovmf.fd or so
<mfg>let me search
<mfg>ah for me it was OVMF=/gnu/store/4rxsx2mvkg59yskyvg60jfq7h8k2abnj-ovmf-20170116-1.13a50a6/share/firmware/ovmf_x64.bin
<mfg>can't `find ~/.guix-profile/ -name ovmf_x64.bin' it ... hm
<mfg>Does somebody use gnus?
<matt`>cool thanks i'll try that. actually the host computer is archlinux so shouldn't need the guix
<matt`>specific stuff
<mfg>on arch it should be under /usr/share/ovmf or /usr/share/firmware/ovmf or so
<matt`>running it now, but looks to be working. also i use gnus, but fairly new to it and haven't used
<matt`>it on guix so may not be able to help
<mfg>i found the solution on stackoverflow (perhaps :D), i'm gong to restart emacs a bit
<mfg>jeez, had the wrong filename :D
<nckx>sneek_: later tell mfg: On Guix, use ‘-bios $(guix build ovmf)/share/firmware/ovmf_x64.bin’, don't muck about with file names at all. ☺
<sneek_>Will do.
***jonsger1 is now known as jonsger
***apteryx_ is now known as apteryx
<apteryx>hello Guix!
<apteryx>I'm going to try something: switch our Python 2 and Python 3 packages to use GUIX_PYTHONPATH2 and GUIX_PYTHONPATH3 instead of PYTHONPATH, to solve having both in the same profile. That should be possible, right?
<apteryx>that involves: a) changing the native-search-paths of the python packages, and adapt their
<apteryx>(the later being b) ;)
<mbakke>apteryx: Nice! Did you read <> and related discussions?
<mbakke>See for the whole story.
<apteryx>mbakke: I'll have a look
<b0f0>I trying to build etc, but I have this ERROR: In procedure symlink: In procedure symlink: File exists
<Marlin1113>hi guix
<adhitthana>Hi All, I recently discovered guix with the release of version and an article on linuxfr, awesome job !!
<adhitthana>I would need some help with a very basic things I want to achieve: create a new boost scheme with support for python3 (i.e. with ./lib/ build). I got the scheme used to build boost with python2 support with guix edit boost. I replaced the line python-2 in the input by python-3 and rebuild. But no python binding are built at all
<adhitthana>. I tride to add --with-python, --with-python-version, --with-python-root in the part of the scheme file that calls but this did not help.. Anyone could help me ? I don't understand what I am doing wrong..
<krafter>str1ngs: You mentioned yesterday that you used i3 together with xfce?
<matt```>anyone have experience with using multiple disks with btrfs and luks? guix system init works
<matt```>but having trouble booting...
<nckx>matt`: I use LUKS+btrfs and mdraid+btrfs, not all three.
<efraim>I tried multi device btrfs before 0.16 but wasn't able to boot from it, didn't investigate too much
<nckx>(Doesn't LUKS imply multiple disks == md, not btrfs native? 🤷 )
<matt`>hi nckx
<b0f0>guix pull
<matt`>so i ran cryptsetup on two separate partitions (luks 1 for grub), open them, made pool with -d raid0 -m
<matt`>raid1, then in config.scm have mapped-device with uuid of one of the partitions (doesn't matter
<matt`>right?), target is the label from making the btrfs pool, then specify the pool label as a filesystem
<matt`>in config.scm, mount point is "/", type "btrfs", dependencies mapped-devices
<matt`>am i missing something? my whole /etc dir is empty except for config.scm
<matt`>let me know if that's not clear, happy to post the actual code from my config
<nckx>matt`: Could you share the error message(s) you get, if any?
<matt`>sure, sec
<nckx>My (RAID) configuration lists *all* mapped devices: (mapped-devices (list (mapped-device (type raid-device-mapping) (source (list "/dev/foo" "/dev/bar" …)) (target "/dev/md0"))))
<nckx>When I initially set it up, listing just one didn't work. Might still be the case?
<matt`>BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM00005 " from PciRoot(0x0)/Pci...."
<matt`>that must be it, I didn't put any config for raid devices
<matt`>so you need mapped-devices for btrfs and also for raid?
<nckx>matt`: Well, not that this is a RAID box, not a LUKS box (I don't have multi-device LUKS), so it might not be exactly what you need. Maybe you do need both raid and luks mappings; I can't say. No experience.
<nckx>s/not that/note that/
<matt`>hm ok. did you set up raid separately from btrfs or as part of the mkfs.btrfs command?
<nckx>Doesn't multi-device LUKS + btrfs imply the following stack: mdraid (aggregating your separate discs) → LUKS (seeing one big encrypted volume) → btrfs (seeing one big decrypted volume)?
<nckx>matt`: It's mdraid 5, it has nothing to do with btrfs raid. btrfs raid5/6 eats all your data.
***daviID is now known as Guest63283
***Guest63283 is now known as daviid
<nckx>matt`: So the other half of my set-up is: (file-systems (cons* (file-system (dependencies mapped-devices) (device "/dev/md0") (type "btrfs") (mount-point "/") (options "compress=zlib,relatime")) …
<matt`>ah ok i guess i'm not familiar with mdraid then. but if I understand your question correctly
<matt`>then answer is no, stack is a bit different in my setup. i encrypted to partitions first, then ran
<matt`>mkfs.btrfs. so its separate encrypted volumes, then aggregated with btrfs
<matt`>s/to partitions/the two partitions/
<nckx>Hmm. Right. So each partition is luksOpened separately?
<nckx>matt`: OK, that *should* be possible…
<nckx>matt`: I'll take that offer of pasting your configuration ☺
<matt`>terrific, thanks. just a mo
<nckx>(That *should* above assumes that multi-device btrfs on Guix works; that's the only thing I've no experience with.)
<nckx>(This is usually when someone chimes in that it's the only part that's still missing.)
<b0f0>for the sound to work do I just install the alsa packages and pulseaudio .. or do I need to enable a service too in config.scm ?
<nckx>b0f0: The opposite. You enable the services, packages are just dead things that sit on your disc until you invoke them.
<b0f0>thank you
<nckx>You'll probably want the packages for pavucontrol & friends, of course, but sound should work without them.
<b0f0>nckx: do oyu have your guix config.scm online for the public to see it ?
<matt`>(mapped-devices (list (mapped-device (source (uuid "....")) (target "btrfs_pool") (type luks-device-mapping))))
<nckx>matt`: …multi-device btrfs doesn't seem to be supported yet. ☹
<nckx>I'm surprised myself.
<nckx>b0f0: No.
<matt`>did you find that in the mailing list archive, or?
<matt`>if you have any more info might see if i can fix that
<nckx>matt`: I'm as disappointed as you are. No, just by looking around (so I can't prove a negative and could always have missed something).
<nckx>It's been talked about for years so I'm surprised it doesn't exist.
<matt`>ok well I'll take a look around the mailing list and maybe see if i can fix that. thanks for
<matt`>the help nckx
<nckx>matt`: It's been ages since I used multi-dev btrfs. Is my understanding correct that, after running ‘btrfs device scan’, you can ‘mount /dev/one-single-device /’ to mount a multi-disc fs?
<nckx>Because we do run ‘check-btrfs-file-system’… in place of the traditional boot-time ‘fsck’.
<efraim>That was my understanding from the btrfs docs
<nckx>and that just runs ‘device scan’.
<nckx>So it's a bit of a misnomer/hack, but it might be intended to support multi-devs after all.
<matt`>yeah that's right
<matt`>it's here under "Filesystem creation"
<matt`>if you're interested
<matt`>if you don't run btrfs device scan you can still mount by passing all devices in fstab
<nckx>matt`: Do you get a LUKS passphrase prompt?
<nckx>So there's nothing for ‘btrfs device scan’ to detect.
<nckx>matt`: Did you paste the full error message you get at boot above? (Not just the single ‘failed to …’ line.)
<nckx>Can't find it if so.
<matt`>i did not, but i'll get it for you. there were more lines. just a little slow bc i haven't set up copy/paste with qemu yet..
<nckx>matt`: In such cases screenshot images are fine too, as long as you apologise humbly. ;-)
<matt`>haha sorry in advance! getting now
<nckx>(If I sounded distracted above it was because I was trying to set up a similar system in VM, but golly that's a lot of work…)
<b0f0>Do I have to put anything in use-service-modules for the sound to work ..hmm
<nckx>matt`: You seem pretty virtualised yourself, might be easiest to try multi-device btrfs without LUKS first.
<nckx>b0f0: Are you currently using %desktop-services?
<nckx>That already contains also-service-type.
<b0f0>so the sound should already work with %desktop-services ?
<nckx>*alsa, of course.
<nckx>b0f0: It depends on so much. Are you using a desktop environment?
<b0f0>nckx: i3wm window manager
<matt`>ok foregive me, i'm new to irc (using erc) as well. how can i post a picture?
<matt`>and i am running it through a vm, so yeah that's a good idea
<nckx>b0f0: OK, I think I figured it out. If you're using dbus-launch, adding pulseaudio to your system-packages should work. It doesn't seem to be started by the Shepherd (Guix) after all…
<nckx>b0f0: If you're not launching DBUS I have no idea how it's supposed to be started; I just use ALSA… :-/
<matt`>first link is what i see first, and second is the shell it drops to after failing
<nckx>matt`: Oh… You never even get to Guix.
<nckx>(—'s GRUB.)
<nckx>matt`: The problem is in installing the boot loader, not (yet) mounting the file systems.
<nckx>matt`: Could you share your full system configuration?
<nckx> is fine.
<matt`>ah ok, sure
<nckx>matt`: That shell is the UEFI firmware (‘BIOS’), you'd get it even without a single drive attached.
<nckx>matt`: It would be interesting to type ‘ls fs0:\’ into it, and any subdirectories there might be there.
<nckx>If there's no EFI\boot\grubx64.efi or EFI\Guix\grubx64.efi there, there's no chance of booting the current system.
<nckx>If there is, you can run it and see what happens.
<nckx>(The EFI shell has tab-completion IIRC.)
<b0f0>nckx: I check my herd, I mean herd status command and there is no ALSA there. I have dbus-system runing in the herd. dbus-launch is a part of dbus-system ?
<nckx>b0f0: Not having an ‘alsa’ service/process running is expected (not all ‘services’ in your operating-system lead to a running process, they could just create a file, which is what alsa-service-type does with /etc/asound.conf).
<nckx>b0f0: I don't know enough about DBUS to answer the second ☹
<nckx>matt`: You're instantiating this with ‘guix system vm’? OK, I guess there won't be a bootloader then, and *theme* I don't know enough to know what should happen there either ☹
<matt`> qemu-system-x86_64 -m 1024 -smp 8 \
<matt`> -machine type=q35,accel=kvm -cpu host \
<matt`> -net user -net nic,model=virtio \
<matt`> -boot menu=on \
<matt`> -bios /usr/share/ovmf/x64/OVMF_CODE.fd \
<matt`> -drive file=hda.img \
<matt`> -drive file=hdb.img
<matt`>there's the qemu command i'm running
<matt`>hm. but i did run guix system init /mnt/etc/config.scm /mnt
<matt`>isn't there like a --no-bootloader option to suppress the bootloader?
<nckx>matt`: So you did install it like a traditional system? OK.
<matt`>i also got a message the bootloader installed
<matt`>ok so i actually have an EFI\Guix\grubx64.efi
<nckx>matt`: Could you try typing: fs0:\EFI\Guix\grubx64.efi
<nckx>at the shell prompt you get?
<nckx>Oh ☺
*nckx wonders if TianoCore would automatically boot it if it were called EFI\boot\…
<matt`>ok it mostly works!
<nckx>\o/ Mostly?
<matt`>dropped me into a guile prompt over an error, but this one i think i get
<matt`>i was messing around with it earlier and changed one of the filesystem names and it's
<matt`>complaining about that
<matt`>haven't rerun guix system init .... yet cause it takes a while
<nckx>matt`: Good, so it knows enough to know what's wrong!
<nckx>matt`: You (normally) only run ‘init’ once. After that, you ‘reconfigure’.
<matt`>can i if i haven't properly booted yet?
<nckx>Just remember that ‘init’ will nuke stuff.
<nckx>Which here is fine.
<matt`>ok so you think maybe if i change the bootloader target it could work?
<matt`>but i guess that's just an issue with putting it through a vm
<boogerlad>does guix inputs support logical or? For example, if I had a "kernel" input and I wanted to accept hurd or linux-libre, how would I do that?
<krafter>boogerlad: What are you trying to do?
<nckx>matt`: Not quite; the target (/boot/efi) doesn't contain that bit anyway and it's more of a problem that a) UEFI requires operating systems to register themselves in NVRAM, b) QEMU is stateless in this regard, so it forgets about Guix. I don't know how this is usually supposed to work. Something to report/debug after you get the rest up & running, at least now you can (manually) boot.
<matt`>ok sounds good. i'm gonna rerun the init and turn in. thanks so much for the help nckx!
<nckx>matt`: Sorry for the detour, I'm glad that Guix wasn't (directly; primarily) to blame for once 😛
<Tirifto>Hello! Is still a Work In Progress?
<nckx>Tirifto: It's the official home page now. Is something missing?
<janas>Is just a mirror then?
<nckx> & friends will probably redirect to in time, but that's not yet the case.
<nckx>janas: No, it's a copy. It might not match 100%. This is a known imperfection.
<Tirifto>nckx: Yeah. It appears to lag behind For instance, it suggests to download Guix 1.0.0, rather than 1.0.1, and the two newest blog posts are missing.
<nckx>Tirifto: Indeed ☺ The owner of knows about this but apparently there's another bug preventing them from fixing it right away.
<nckx>It's confusing and Not Great 🤷
<Tirifto>nckx: I'm talking about now; are you, too?
<nckx>Tirifto: I don't know the exact nature of the blocker so don't know exactly which domains are affected.
<Tirifto>Ah. I guess things are working well enough then. :P
<vagrantc>there was a recent thread on either guix-help or guix-devel that explained the situation
<nckx>Tirifto: Ah, I see. Because I mentioned explicitly. No, I meant the same bug.
<nckx>vagrantc: In more detail than ‘something else is blocking this’? I didn't see that. What is it?
<vagrantc>i guess not with much more detail
<nckx>Nope, that's what I'd read too.
<g_bor[m]>nckx: do you think that announcing that and is not authoritative until further notice on the info ml would be worthwhile? We could point the users to the announcement until it is resolved. Wdyt?
<nckx>g_bor[m]: Let's ask rekado_, they know what the actual problem here. I'd prefer just fixing this rather than a(nother) rather embarrassing announcement after %base-packages ☺
<nckx>s/what //
<Tirifto>Slightly off-topic: This screenshot features altogether five animals! Was that intentional? :P
<nckx>Tirifto: Haha, no. I guess animals just make good mascots/logos.
<nckx>(I count 4, but that's with 2 different styles of gnu horns…)
<Tirifto>The system's *GNU* (also mentioned on the web page), the user's name is *antelope*, their desktop environment, XFCE, has a *mouse* on its Applications button, and they're running GNU Ice*cat*, with *Duck*DuckGo set as the search engine.
<Tirifto>Granted, the antelope has no picture, but the word's there. xP
<nckx>Tirifto: Ah, I missed antelope.
<pkill9>what's the name of the nixops-equivalent for guix that is being developed?
<payphone>I'm attempting to run jackd as a regular user, but I keep getting the error message, "JACK is running in realtime mode, but you are not allowed to use realtime scheduling." I read in the manual that I'll have to add a pam-limits-entry for this to work, but the example provided doesn't appear to be working for me.
<payphone>My user is currently in the realtime group, but running `ulimit -a | grep real-time` returns the following, "real-time priority (-r) 0."
<payphone>Here's my current config.scm:
<pkill9>payphone: what does /etc/security/limits.conf have?
<payphone>@realtime - rtprio 99
<payphone>@realtime - memlock unlimited
<apteryx>Would someone know if it is posible to read the Guix archived mailing lists from Gnus?
<pkill9>payphone: have you loggedout and in again?
<payphone>Yup, I tried reboot as well.
<pkill9>hmm im getting it as well and i have that service added, i seem to remember fixing it temporarily somehow, but can't remember what i did
<nly>Apteryx you can read gmane archives
<nly>Called with '(nntp "")
<payphone>pkill9: Ah, so it's not just me. I'll keep investigating, then. Thank you!
<apteryx>nly: ah, right, I do have gmane, but without search functionality its of limited use.
<b0f0>nckx: it was as you said, the sound already worked, I just needed to add pulsaudio pavucontrol. Thank you very much for helping me.
<nckx>b0f0: 😊
<dongcarl>mbakke: wondering why you swapped out CROSS_C_INCLUDE_PATH & co in favor of CROSS_CPATH
<dongcarl>(in core-updates)
<KE0VVT>Can someone give me a Guix pack of CHIRP?
<rekado_>sorry for the delay in updating /
<rekado_>doing this now
<rekado_>(the thing that’s holding it up is the git error I got when running the builder script; so now I have to do it manually…)
<vagrantc>so, i've got a somewhat working guix package for Debian, but when trying to build anything, it ends with: guix: offload: command not found
<Marlin1113>Hi Guix!
<rekado_>vagrantc: is guile-ssh available at runtime?
<vagrantc>rekado_: does it need guile-ssh for local builds?
<vagrantc>it wasn't available, but should be now, same issue
<nckx>rekado_: Yay! Thanks.
<jonsger>vagrantc: is there /usr/lib/guix/offload?
<g_bor[m]>vagrantc: what is the daemon configuration? I believe the need for guile-ssh might be mitigated if you use the --no-build-hook option.
<vagrantc>jonsger: no
<vagrantc>g_bor[m]: will try it
<jonsger>oke, I think thats missing. On openSUSE it's shipped with the guix package
<vagrantc>g_bor[m]: no luck
<vagrantc>it doesn't appear to be part of what make install installs...
<rekado_>vagrantc: if guile-ssh was available at configure time it will be needed at runtime because of the offload hook.
<vagrantc>oh! it's in libexec ... which isn't a thing on debian
<vagrantc>interestingly enough, "guix authenticate" seemed to work, despite being installed in libexec
<dongcarl>vagrantc: I would be happy to test
<dongcarl>and debug
<dongcarl>basically let me know if I can help in any way for the debian package
<vagrantc>it's coming along...
<vagrantc>will likely post to the debian bug and guix-devel soonish
<dongcarl>vagrantc: That's very good to hear. I'll be on the lookout and feel free to ping me for any man-power/machine-power
<vagrantc>dongcarl: i've uploaded a few of the dependent packages, waiting approval through NEW, and then a second wave of them will need to go through NEW, and then ... need to convince gnutls maintainer to re-enable guile-gnutls
<dongcarl>Awesome, I can't wait.
<dongcarl>This'll really make it easy to switch to guix!
<vagrantc>i think i've worked around the bootstrap binaries for bash/tar/xz/mkdir by symlinking to the host's binaries ... not sure if that will break substitute availability
<dongcarl>vagrantc: You mean so that the user doesn't have to bootstrap the first time they use Guix?
<vagrantc>dongcarl: well, if it can re-use binaries produced by guix's standard substitute servers at all ... e.g. if it changes the hashes of bootstrap hashes, it might cascade down to requiring different substitutes for everything
<vagrantc>hope not, don't fully understand it
<dongcarl>vagrantc: genuinely curious: why would guix-on-debian not be able to use the binaries produced by guix's standard substitute servers? I run Guix on Arch and it seems to work great with guix having its own bash/tar/xz/mkdir and Arch having its own
<vagrantc>dongcarl: do the arch packages ship the bootstrap binaries provided by guix?
<vagrantc>in debian, that wouldn't be allowed.
<dongcarl>vagrantc: Ah I just installed using the manual
<dongcarl>Okay so that's what I'm missing... debian won't allow it...
<vagrantc>since those binaries are GPL, debian requires building from source in order to guarantee compliance
<vagrantc>(at least some of them are)
<dongcarl>vagrantc: Hmmm... what does nix do? Are they in debian yet?
<vagrantc>and everything in debian proper has to be built from source too
<vagrantc>dongcarl: it's been sitting in NEW for months, haven't looked at the packaging though
<dftxbs3e>vagrantc: you can't build bootstrap from source, that's the point though, it needs a binary at first
<dftxbs3e>what's the point in building a bootstrap binary from source with itself?
<vagrantc>if it does in fact require those exact bootstrap binaries, then it won't be possible to include in Debian
<dftxbs3e>vagrantc: but it's a chicken and egg problem
<vagrantc>unless we can bit-for-bit recreate them within debina...
<dftxbs3e>not if you use the exact same toolchain that was used to create them
<dftxbs3e>not unless*
<rekado_>vagrantc: the hashes of these binaries unfortunately do matter.
<vagrantc>so, might have to wait for mes, then ...
<dftxbs3e>maybe these binaries could be unbundled and provide specially by debian, built by debian, for the debian GNU Guix flavor, but then, it wont be reproducible with the rest of the eco system
<vagrantc>or accept that it can't share substitutes
<dftxbs3e>provided specially by*
<rekado_>we’ll still have bootstrap binaries with mes, so if it’s a problem of guidelines it still needs to be addressed.
<dongcarl>vagrantc: Perhaps we can do a PPA first with the binaries? Just for usability?
<rekado_>but we could make Guix download the binaries at runtime.
<rekado_>(doesn’t it do that already?)
<vagrantc>dongcarl: sure, it's possible, but at that point, may as well just use the guix-provided binaries
<str1ngs>why not just have a guix Debian package and let guix manage the rest?
<dongcarl>good point... just have Guix download at runtime...
<vagrantc>rekado_: debian policy doesn't allow network access during builds
<str1ngs>I mean all you need then is guix sources, and it's depends.
<str1ngs>all of that is source based.
<rekado_>yes, of course
<vagrantc>oh, at runtime?
<vagrantc>then it might work
<dongcarl>woop woop
<rekado_>they are only needed to build Guix things, no?
<str1ngs>right, which is all source based
<dftxbs3e>guix would download bootstrap binaries
<dftxbs3e>it wouldnt use debian host toolchain
<str1ngs>after that, guix can manage the bootstrap binaries
<vagrantc>i think something in the guix build process requires them
<dftxbs3e>guix doesnt need bootstrap binaries to build as a package manager
<str1ngs>nope you can build guix without guix binaries
<dftxbs3e>it needs them to bootstrap itself then
<dftxbs3e>but that's only if you install something
<str1ngs>right, in which case guix is managing that. not debian
<vagrantc>well, i got failures to build when i removed gnu/packages/bootstrap/* before building
<str1ngs>wait does git distribute binaries?
<dftxbs3e>yes, git distributes tar, xz, etc
<dftxbs3e>but it doesnt required to build Guix
<dftxbs3e>it isnt*
<dftxbs3e>it copies these binaries in /usr/share..
<dftxbs3e>that's it\
<vagrantc>not consistant with my experiences
<dftxbs3e>vagrantc: the Makefile *requires* them to *install* them
<dftxbs3e>not run them
<vagrantc>so patch the makefile to not install them?
<dftxbs3e>Guix needs them to be installed
<mbakke>dongcarl: There are problems with C(PLUS)_INCLUDE_PATH in GCC7. Specifically that #include_next does not work. CROSS_CPATH got me a bit further, but there are still issues with C++ :-/
<dftxbs3e>but these binaries can be the host'
<dftxbs3e>host's binaries*
<dongcarl>mbakke: Yessss... That was causing me problems for riscv64... I'm switching to core-updates just for this haha
<dftxbs3e>you can put a symlink to host bash, xz, tar, and mkdir in /usr/share..
<dftxbs3e>it will work, I tried it
<vagrantc>dftxbs3e: that's what i've done so far ...
<dftxbs3e>vagrantc: okay then, maybe you can hack that as a "debianization" patch, and it will be OK with Debian's guidelines?
<vagrantc>dftxbs3e: right, that's what i've been working on...
<dftxbs3e>alright, already sorted out then!
<dongcarl>I think the takeaway is that the host bash, xz, tar, and mkdir are not going to affect the hash
<dftxbs3e>thanks for this effort, will be much easier to get going on Debian/Ubuntu with Guix
<dftxbs3e>dongcarl: I think Guix doesnt check these binaries for their hashes
*dongcarl is thankful as well
<dftxbs3e>I might be wrong, but when I replaced them, it didnt complain
<janas>Is it possible to modify an existing guix package without building from a git checkout?
<janas>For example, if I want to make a change to the configure flags of a package, do i need to create a new package in another channel, or can I modify the original somehow?
<dongcarl>janas: See the help for `guix build -f`
<jonsger>dftxbs3e: did you made any progress on ppc64le?
<janas>dongcarl: thanks! And can I use the same name as an existing package, or will that cause conflicts?
<dftxbs3e>jonsger: Sorry I never posted to the mailing list, no I didnt, I'm going to cross compile bootstrap from x86 on latest core-updates now
<dftxbs3e>I made progress but what I was doing didnt work so I'll stop bothering with v0.13.0
<dftxbs3e>I built bootstrap binaries for powerpc big endian but didnt test them yet
<dftxbs3e>I should
<dongcarl>janas: Not sure, but I'd just prefix the name with something identifiable and see lol
<janas>alright, I'll give it a try :)
<vagrantc>does guix/offload need to be in PATH ?
<jonsger>vagrantc: no
*vagrantc wonders how to get it to look for offload where it's actually installed
<pkill9>ah, guix deploy
<dongcarl>does core-updates use mes to boostrap already
<rekado_>dongcarl: yes, but only for one architecture IIRC
<dongcarl>rekado_: That's really cool! (experiencing the long build time of switching from master to core-updates RN)
<rekado_>g_bor[m]: / is up-to-date now. There might still be little errors because I couldn’t use the build script, but it’s better than having an outdated site.
*rekado_ feels a little exhausted
<dongcarl>rekado_: go rest!
<dftxbs3e>dongcarl: mes doesnt work for anything else than x86 afaik
<dongcarl>eh, still cool
<vagrantc>looked like there were patches for armhf in mes git
<vagrantc>also was looking into packaging mes for debian ... if we can reduce the bootstrap even further :)
<nckx>While running the installer: permission denied in execvp of bash.
<nckx>This is the farthest I've come before it randomly crashing for no reason \o/
<civodul>rekado_: thanks for updating the web site!
<civodul>nckx: make sure to report bugs
<nckx>civodul: I feel like I've seen this one reported already though.
<nckx>If it doesn't look familiar to anyone else I guess I'm trippin'.
<nckx>(I ‘reported’ it here because I expected 3 people to immediately respond ‘oh, sure, that's bug xxx.’)
<vagrantc>hrm ... sh: 1: build-aux/git-version-gen: not found