IRC channel logs


back to list of logs

<theruran>guix system (GNU Guix)
<nckx>bavier, theruran: The description is broken, fix queued.
<nckx>theruran: Weird, ‘guix --version’ should not print ‘guix system’ and it should be followed by a version.
<nckx>Here: guix (GNU Guix) be31e63e9fc84c1e87b922d7b8bfd6c25a999a4b
<theruran>nckx: :/ I installed it using the nix-guix Portage overlay. and the ebuild says it's 1.0.1-r2
<bavier>nckx: was it the "@Reply" in the description?
<nckx>@ → @@
<bavier>thanks for fixing :)
<nckx>After the Guile 3 update, the universe demands an @@ equilibrium or whatever.
<drakonis> this is real nice.
<drakonis>pjotr seems to read minds.
<bavier>drakonis: I would personally like to see more progress on the guile daemon
<nckx>bavier: Strange that your error was so opaque, though. Here ‘guix show choqok’ politely barfed ‘Throw to key `parser-error' with args `(#f "Unknown command" Reply)'.’.
<drakonis>getting the guile build system would be a nice foot in the door.
<bavier>nckx: ah, yeah, same as here.
<bavier>nckx: I'm surprised 'guix lint' doesn't complain
<bavier>I thought lint verified the texinfo rendering for descriptions
<drakonis>what would be the technical implications of moving away from using the nix daemon?
<drakonis>other than maybe enabling a significant amount of guile features to be used with it
<bavier>drakonis: besides perhaps tighter integration possibilities, I'd be excited to finally drop the piece of nix that people constantly point to justify saying that Guix is "just a derivative"
<drakonis>ah, sheepdog is also interesting.
<drakonis>now, that one i can certainly agree with.
<drakonis>somebody's gotta put their hat down for it
<nckx>bavier: Oh, I misread theruran's ‘guix show: command not found’ reply as yours.
<wheeler>bavier: Thanks. I've got libx11 in the inputs section now (vs. native-inputs) but still getting the not found error. Using gnu-build-system and following cues from other packages in guix including pkg-config in native-inputs.
<nckx>bavier: guix lint choqok → choqok@1.6.0: Texinfo markup in description is invalid
<nckx>Unless you were being 😉.
<bavier>nckx: heh, totally ;)
<drakonis>guix gsoc is ever so exciting
<PotentialUser-22>Does anyone know if there is a GuixSD live CD/USB for download? I would like to try GuixSD NOT in qemu because the performance of my machine is really bad.
<drakonis>yes there is.
<nckx>PotentialUser-22: The closest thing I know of is the installer, which is a live Guix System. However, it's quite minimal for its size. Certainly not a try-GNOME-out-of-the-box (or even X) thing.
<bavier>PotentialUser-22: The installation media for the "Guix System" will happily boot on bare metal
<drakonis>live, right, i missed that.
<drakonis>you want a graphical interface.
<PotentialUser-22>I need a GUI interface to try some desktop applications
<drakonis>technically speaking, it is a live image but there isnt really a graphical interface available yet, but that's not too difficult to generate.
<drakonis>that sheepdog thing pjotr started writing a month ago is heckin cool.
<nckx>I assume (although I haven't tried) that editing the installer's system configuration (if one is included) and reconfiguring will ‘work’. With enough time and RAM/swap for the hungry cow.
<PotentialUser-22>Are there any documents about how to make live images ?
<drakonis>i wonder if it could potentially be set up to replace dbus
*bavier needs to put their money where their mouth is
<drakonis>i'm not good enough with guile to actually participate on the guile daemon effort so
<nckx>Creating a live image with Guix should be trivial: you type ‘guix system disk-image --file-system-type=iso9660 /etc/system.scm’ instead of ‘guix system reconfigure’ or ‘init’. Done. Haven't actually done this, though.
<nckx>And yes, it requires a running Guix.
*bavier trying right now
<nckx>Heh, let me know how it splodes.
<sirgazil>nckx: If it is already possible and trivial, do you think they will be offered ready for download for the next release?
<sirgazil>For example live media with some desktop environment.
<sirgazil>PotentialUser-22: Do you use Guix already in a foreign distribution?
<PotentialUser-22>Personally I think provide a live image is very useful and friendly for beginners
<nckx>Well, ‘should’ is the operative word and the experience will probably not be polished. OTOH it should be quite similar or even identical to the QEMU image we already have. But if someone volunteers to do it: sure, why not.
<nckx>sirgazil: ☝
<PotentialUser-22>sirgazil: I install GuixSD in qemu, but it killed my poor machine
<PotentialUser-22>My machine is a low end one, it can run VMs but super slow
<nckx>PotentialUser-22: The installer is a complete live system already. It just doesn't have fun desktop packages installed because they'd be a waste of bandwidth for 99% of users.
<nckx>‘Fun desktop packages’ like X, or ‘clear’, admittedly.
<PotentialUser-22>New users always tend to see what it would be like for their future working environment.
<PotentialUser-22>So a desktop environment is a good example
<nckx>But a Guix desktop just looks like any other. Our GNOME is just GNOME, our IceCat is just IceCat. That's not where the magic is. We don't provide a custom desktop experience.
<vagrantc>janneke: i'd love to take a stab at packaging a working kernel for pinebook pro on linux-libre 4.4.x + patches ...
<vagrantc>janneke: and i can probably also build u-boot 2020.01 with patches
<sirgazil>PotentialUser-22: There is no ready to use live media with desktop environments like other distros have. But you could install Guix on top of your current GNU/Linux distribution and install the applications you want to try.
<nckx>PotentialUser-22: I do think a live image is a good idea, it just won't look any different from (random name) Trisquel.
<PotentialUser-22>nckx: yes, I know, thanks
<Blackbeard[m]>It probably comes down to users that like to distro hop and new users who don't understand exactly what a distribution is
<nckx>The Guix one will have slightly more bugs so you know it's Guix but that's about it.
<PotentialUser-22>sirgazil: I have install Guix on top of my distribution, but I would like to try more about running application in container which Shepherd is a must.
<Blackbeard[m]>I prefer a simple installer that lets me chose what I want
<smithras>Maybe adding a section to the cookbook about all of the packages needed for a typical "just-works" desktop could help users.
<nckx>Users have proved to be willing to download 1.5 (or is it more?) GiB for a simple installer, so trimming away the fat and offering a similarly-sized installer with X should keep them happy & attract new(bier) users.
<nckx>There's another $project.
<nckx>s/keep them happy/is not a regression for them/, at least.
<sirgazil>PotentialUser-22: In my case too, running the Guix System with GNOME in a virtual machine was possible but slow. So I checked if my computer worked with Trisquel Live, it did, so I installed the Guix System.
<Blackbeard[m]>smithras: i think there are already a few examples
<PotentialUser-22>sirgazil: Good suggestion, I will do that too.
<sirgazil>PotentialUser-22: I've been using the Guix System with GNOME for almost a year and I don't want to go back to any distro.
<PotentialUser-22>sirgazil: Wow, I should try
<smithras>nckx: I agree that usb install disk space doesn't seem to be a big concern these days
<smithras>*usb installer
<vagrantc>if two channels contain the same package definitions, does everything work fine? e.g. can i make a channel that's just a fork of guix at some commit?
<bavier>vagrantc: I've noticed that the guix package always "wins"
<bavier>I've not investigated further
<bavier>though IMO I'd think the channel declaration order should break ties
<vagrantc>i don't want to have to figure out how to make the minimal set of changes in order to add some random packages ... so this sounds like it could work.
<vagrantc>e.g. i just want a custom linux-libre and u-boot package, for example ... figuring out how to make that standalone without all the other parts ... seems like a lot of work
<drakonis>bavier: i'd prefer to have the ability to pick which channel i want to source it from
<bavier>drakonis: I suppose that'd be possible by just adjusting your module loads properly, but for a default resolution strategy a PATH-style first-come-first-served would seem less surprising
<ActualUser-74943>Hello Guix from IceCat on GuixSD! I finally made it :P. For some reason xf86-video-amdgpu doesn't seem to be giving me hidpi output though :/
<ActualUser-81483>odd... icecat segfaults (installed in a profile) on C-o (open file). will report later
<nckx>ActualUser-81483: Congrats! (Nice nick 🙂).
<bavier>ActualUser-81483: congrats on the install. weird, icecat C-o works for me, curious to see your details
<nckx>ActualUser-81483: Does hidpi work with your card on other free distributions? AMD are somewhat notorious for their lack of free software support.
<ActualUser-81483>nckx: thanks! glad to finally be here. little more refinement and I can move the data over
<ActualUser-81483>bavier: I'll make a note to @ you when I report it
<ActualUser-81483>nckx: it does. with gentoo + kernel settings + amdgpu driver
<nckx>Gentoo includes nonfree software though.
<ActualUser-81483>yeah... I have ACCEPT_LICENSE="-* @FREE", but I think I needed an exception for kernel fw though :/
<nckx>Yeah :-/
<ActualUser-81483>it should work though. I have the radeon 580:
<nckx>AMD likes to lie about their ‘free driver’ but it just loads a proprietary blob.
<nckx>Ah, that's good.
<ActualUser-81483>so I'm wondering if I've done something wrong? is xf86-video-amdgpu the right driver? or should I use -ati? or something else?
<nckx>‘Lots of features are missing however’ might include high-DPI though.
<nckx>ActualUser-81483: It's worth a try Given ‘free driver used: ATI’ on that h-node page.
<dftxbs3e>nckx, I patched glibc to remove throw but that's quite dirty
<dftxbs3e>I just ran another build, we'll see
<dftxbs3e>I feel like the bootstrap part of GNU Guix is a good set of hacks, I wish it could be refactored to make a little more sense
<dftxbs3e>Is bootstrapping that way just not supported upstream that it requires this?
<dftxbs3e>or gcc/glibc itself is a bit hacky in a way that it requires GNU Guix to be as well
<nckx>dftxbs3e: Do you mean the LFS-style ‘self-hosting cross-build’ hack/approach?
<dftxbs3e>nckx, No, just the code, the way it redefines many things without a clear explanation of why, or how some things could be patched upstream instead of inside GNU Guix
<dftxbs3e>the cross build is a very fine process IMO
<nckx>I agree.
<nckx>My personal suspicion (based just on how I feel now 😛) is that when people finally managed to bootstrap the system, the last thing they want to do is to touch anything or go back to redesign/upstream the entire approach.
<nckx>But who knows.
<dftxbs3e>What I don't like is the lack of explanation and lack of code clarity for GNU Guix's commencement.scm
<nckx>More agree.
<dftxbs3e>I can imagine how much of a pain that was
<dftxbs3e>I can see Ludo pushing some commits removing bad code practices that create bloat from the bootstrap process
<ActualUser-93708>nckx: update. I was /actually/ using xf86-video-fbdev. ati listed a bunch of model #s it supports (5800, but not 580), and amdgpu simply didn't work
<nckx>It makes one (=me) very uncertain: why does all these package names include -cross- but not their variable name? Is it an oversight? Or an incredibly important insight? Etc. etc. Very tiring.
<bavier>there are things in the bootstrap too that can't be easily upstreamed, or the upstreaming would require then a drastic change to the bootstrapping process
<bavier>e.g. a new architecture that wasn't supported by the older bootstrap base packages
<nckx>ActualUser-93708: Aha. Well, that's something, even if not perhaps what you've hoped. I hope ati works for you.
<dftxbs3e>Oh and yeah, the way bootstrap binaries are built at a commit then used forever favors that the bootstrap process's code in newer versions is never tested and thus broken
<dftxbs3e>Broken for someone who'd like to port a new arch from latest master
<ActualUser-93708>yeah I'll try it again. h-node says something about blacklisting amdgpu too... maybe I'll try that. I wonder if it matters that I'm running x as myself and not as root. doesn't seem to, as fbdev is working
<dftxbs3e>I think the bootstrap process should always refer to exact versions so that it doesnt break over time
<dftxbs3e>also, self-contained, separated from the rest of GNU Guix, so that changing code in the rest of GNU Guix wouldnt alter the bootstrap process for no reason
<dftxbs3e>Right now, you could update a gcc with a new revision that would break a patch that the bootstrap process is applying on top
<dftxbs3e>I don't think security updates or bugfixes are really necessary when the bootstrap process works. You'd build a new more recent compiler later anyway
<dftxbs3e>I wonder if there's a way to continuously test the whole chain... make-bootstrap.scm + bootstrap.scm/commencement.scm
<dftxbs3e>Without altering GNU Guix's code every time with hashes
<drakonis>dynamic hashes?
<dftxbs3e>Maybe one could do that using offload builders of different archs?
<nckx>Any mention of faking/disregarding hashes (really: breaking the functional model at the lowest level for convenience) makes me supremely nervous. I hope that's not what we're talking about. I'm about to go to bed and don't want nightmares.
<nckx>Yes, bootstrap binaries are arbitrary blobs created by tired angry people, but at least they're content-hashed.
<dftxbs3e>I think don't you *have* to break that. Two different GNU Guix instances of different archs would need to transfer a package output over the network
<dftxbs3e>I don't think *
*nckx is too tired for commencement.scm, good night 🙂
<dftxbs3e>nckx, hah, Good night!
<renich>Just finished installing my first guix with manual install. Awesome work! Thank you, so much, for guix! ;D
<vits95>renich: don't forget to install fonts. Don't forget that to install package system-wide you should use sudo -i, not sudo. Welcome.
<vits95>renich: also there is . The "HTML, entirely on one page" is best for search something through all the manual.
<renich>vits95: yep, thanks for the useful info. I've used the manual in order to install guix manually. Thank you for the recommendation,t hough. You're right. The one page manual rocks!
<dftxbs3e>how can I replace a package from all the transitive dependencies?
<vits95>also, renich, in your sys. config's "(file-systems": use (flags '(no-atime)) ;; if needed . For not "common mount options", like btrfs's "compress-force" is going to (options "compress-force").
<renich>I've installed a bare-bones.scm for now. I want to check it out a bit first and get the hang of the commands.
<renich>vits95: hah, great! Thanks.
<vits95>renich: for bare-bones, append the (elogind-service) to (services ;; if you're like to start things from tty instead of Desktops Manager, like sway WM.
<vits95>dftxbs3e: what is transitive dependencies? i'd searched the manual with "transitive de", and found nothing.
<renich>vits95: I'm gonna go with relatime for now, just to test it out.
<dftxbs3e>vits95, it's the full dependency tree, dependencies and dependencies of dependencies and so on
<vits95>thanks, dftxbs3e!
<vits95>renich: if you using btrfs:
<renich>vits95: ext4 for now, but definitely gonna try btrfs out.
<renich>vits95: ah! Good point on relatime. Will do with noatime then.
<vits95>renich: also, there is /sys/devices/system/cpu/cpufreq/ dir. There is sub-dirs named like policy0, policy1. Under them, there is the files: a scaling_governor, and a scaling_available_governors. Check them too, because for me the scaling_governor for both CPU was performance. It was a Wasted Watts governor for this Web-viewer machine.
<vits95>renich: if you've a HDD (rotational disk), you may be interested in either hdparm + scripts, or a gnome-disks app (package gnome-disk-utility). In Guix there is no care was taken (by default) to prevent the too frequent spindowns to happen.
<vits95>oh, yes: fc-cache -r may be needed after the installation of fonts.
<apteryx>Am I the only one for which Geiser quickly becomes unresponsive after many definitions are eval'd or generally after some time?
<renich>vits95: awesome tips! Thanks. I'm reading about the features and the concept of a functional approach guix follows. Interesting stuff.
<vits95>apteryx: also check the bottom of this page (IRC and such)
<vits95>See your all, soon.
<renich>OK, how do I add my ssh key without having to send a file there? I just want the text:
<divansantana>Having some casting/mirroring software on guix would be nice. /
<sneek>divansantana, you have 1 message.
<sneek>divansantana, bricewge says: Missing OS list in virt-manager should be fixed in #39579.
<divansantana>Nice to have screen mirroring software.
<divansantana>sneek: awesome, thanks! Will check it out.
<nathan__>I just installed icecat and it says "Your IceCat profile cannot be loaded. It may be missing or inaccessible." when I try to launch it.
<efraim>dftxbs3e, nckx: I got the same ld error with 64/128-bit long on libstdc++-boot0@4.9 on 32-bit PPC
<NieDzejkob>sneek: later tell sirgazil: maybe you could add the source of your package as a submodule to your channel repo and then use local-file or something as the source? idk whether channels support recursive checkouts, though
<sneek>Will do.
<NieDzejkob>Gooberpatrol66: where did you put your channel config? Did you run guix pull as your user afterwards?
<vits95>sneek: later tell vits95: You are the best!
<sneek>Got it.
<sneek>vits95, you have 1 message.
<sneek>vits95, vits95 says: You are the best!
<vits95>sneek: What you can do?
<vits95>sneek: help
<efraim>sneek: what is the cake
<sneek>Last time I checked the cake is a lie
<vits95>sneek: what is the Geiser
<vits95>sneek: what is the sneek
<vits95>efraim: what will happens if sneek was asked to tell later something to sneek?
<sneek>later, vits95 says: something to sneek?
<efraim>sneek: later tell sneek hello
<sneek>You just did.
<efraim>sneek's too smart for that
<efraim>sneek: botsnack
<vits95>;) s neek l. tell s neek l. tell hi
<divansantana>is a locale of LC_CTYPE="en_US.utf8" the same as of that of LC_CTYPE="en_US.UTF-8"
<divansantana> explains it nicely.
<divansantana>Trying to see why when I copy and paste out of tmux I have encoding issues.
<lapin>hi, someone know if it is possible to wrap a buildroot package inside a generic builroot-build-system? and by this way do a easy way to switch to guix.
<vits95>lapin: what architecture it is? has the binaries and sources, and the installation instructions for some archs.
<lapin>i don't want a solution to build guix but i want to replace my buildroot project by a guix one
<lapin>i want somrthing like
<lapin>but design to take as imput a buildroot package and a buildroot config
<lapin>and by this way profit repro/isolated env/easy migration
<lapin>and fast compilation due to sharing of binaries
<lapin>even if i understand that this solution add an over layer witch is not technically useful.
<vits95>lapin: If i'm understand, the buildroot is for embedded devices. I'm not developer, but aren't the Guix be to bulky for an buildroot project-replacement?
<civodul>there was a great talk at FOSDEM on using Guix instead of Buildroot/Yocto/etc. for embedded devices:
<civodul>lapin: Guix is self-contained, it cannot be told to use a Buildroot package as an input
<civodul>well it could, but that would defeat the whole purpose of Guix
<vits95>thanks, civodul, for this explanation.
<vits95>I've my network fall down once in a time. /var/log/messages has many "Failed to send 300 byte long packet over enp0s29u1u2 interface." What is that?
<lapin>why he cannot use a buildroot package as a config if the hash of this package and it's config is integrated to the hash of the result
<vits95>lapin: i think, because "Guix is self-contained". There was something performed to build the buildroot package (whatever this is ;) ) -- outside of Guix. So "well it could, but that would defeat the whole purpose of Guix".
<lapin>vits95: GUIX_PACKAGE_PATH give the possibility to define the package
<efraim>oh no, I just realized I don't know if I can boot my G4 from a USB from openfirmware
<lapin>and by this way extends guix (add your own package). to inform how tu build it you need to write a .scm file. and this one have to be of one of category mention in this link
<lapin>the reproductibility of the package is not because of 'Guix is self-contained' but due to functional approach. (same imput -> same output)
<lapin>if i give the same buildroot package, with the same .scm file and all the step inside the guix env is pure functionnal i d'ont undestand the problem.
<efraim>current ISOs are 1.2GB, i wonder if I can realistically trim it down to 700 MB
<vits95>lapin: trouble should be somewhere on the stage of creating this "same buildroot package"; or you are right ;)
<lapin>i will try
<bricewge>Why don't we have tests for `guix deploy`?
<bricewge>I never managed to use it successfully, it either hang indefinitely or crash.
<vits95>lol, i'm think i've found the reason of the messages from dhclient i'd posted above: i'd over ten instances of dhclient running simultaneously.
<vits95>see, lapin: i'm, again, an mr. Flood. But the trouble with the commands like guix challenge. There, by Guix way, should be an clear path for anyone to reproduce the whole chain of inputs, if needed. Building the buildroot package on their machines -- included. So, this looks like a hard work for me (not dev myself): use an buildroot package and mai
<vits95>ntain its reproduct-ability.
<vits95>bricewge: i'm searched info guix and single-page manual. Can you share a link to reading about a `guix deploy`?
<efraim>have you looked at the devel version of the manual?
<bricewge>efraim is too fast for me...
<efraim>I keep the tab open for easy browsing :)
<kmicu>Tomorrow is Guix Love day. Cannot wait ʕノ•ᴥ•ʔノ ︵ ♥❤❣💞
<efraim>does glibc-intermediate fail to build on core-updates on other architectures?
<vits95>bricewge: the tutorial link you'd given to me... "(name Alyssa" ;;(in example) is this a "real" name or a "meme" name? I'd just ... wonder. Only seen such name in a game.
<vits95>efraim: if i'll run this as an user: `guix install glibc-intermediate --no-substitutes` it'll help?
<vits95>or guix build ...
<bricewge>vits95: I do not know. You should ask the author Jakob. But it seems like a real name to me, probably a twist on Alice and Bob placeholder names.
<efraim>probably something more like "./pre-inst-env guix build --no-grafts -e '(@@ (gnu packages commencement) glibc-final-with-bootstrap-bash)'" on core-updates
<vits95>efraim: how to set the core-updates up? It is default?
<efraim>vits95: don't worry about it, i'm testing it now on my x86_64 machine
<vits95>I'll go on through the man, then. Thanks for a devel version link.
<zzappie>Hi Guix!
<zzappie>so I'm hacking some guixy guile lately...
<zzappie>with geiser of corse. Wondering wether my laptop has to compute so hard when I eval any guix buffer that uses package modules
<vits95>zzappie: did you'd check the /sys/devices/system/cpu/cpufreq/policy*/scaling_governor ? By default this is a performance, afaik.
<vits95>I'd switched to powersave on my laptop.
<zzappie>well whole thing hangs for a minute and fills up the ram. I suspect geiser just makes some kind of giant datastructure for autocompletion
<vits95>It: "... conspire with one or more Scheme implementations to keep the Lisp Machine Spirit alive. ..."
<vits95>according to description of the package.
<zzappie>vits95: Yep it says performance. Changing it to powersave probably oly make my laptop buzz less
<zzappie>vits95: haha :D
<zzappie>this is clearly a sicp reference
<zimoun>civodul: in case you have missed bug#39575 reported by janneke; which implies that 'guix time-machine' is potentially broken for a range of commits -- and worse, fragile to upstream re-write. I do not know if it is fixable. Thoughts -- using your queuing batch processing :-) -- are very welcome :-)
<vits95>I didn't read, but there is sicp link:
<civodul>zimoun: i hadn't seen it!
<civodul>i'd say it's fixable as long as we have copies of the original harfbuzz tarball
<zzappie>vits95: there it a 'guix install sicp' ;)
<zimoun>civodul: :-) Ok, so I am going to try to build the old harfbuzz tarball with the old hash.
<zimoun>civodul: maybe a mechanism to prevent such cases should be discussed and/or implemented, maybe pushing to SWH.
<vits95>zzappie: Thanks. I'd added this to @world.
<raingloom>what would cause meson to not find appstream-glib? i'm trying to package Geary (based on its Nix package) and it can't find that in configure. i don't know much about meson but it doesn't look like the build script is doing anything special.
<sneek>raingloom, you have 1 message.
<sneek>raingloom, leoprikler says: gnome.scm is fine, but raghav-gururajan is looking to split that up into multiple parts later on
<leoprikler>raingloom: is it missing as input?
<raingloom>leoprikler: no, it's in native-inputs
<raingloom>was in inputs originally, but that didn't work either
<leoprikler>Perhaps it's missing pkg-config file, I'll try building it.
<raingloom>the one i have seems to have the pkg-config thing in its lib
<leoprikler>what is the specific package?
<leoprikler>(i.e. the one you're trying to build)
<raingloom>> Dependency appstream-glib found: NO (tried cmake)
<raingloom>maybe it's not even trying pkg-config?
<leoprikler>btw. the license is license:lgpl2.1+
<raingloom>leoprikler: there is also a COPYING.ICONS and COPYING.SNOWBALL file in the source, don't those need to be included in the version field?
<leoprikler>licenses, yes
<raingloom>doh. s/version/license/
<leoprikler>for the icons you need to add cc-by3.0 cc-by-sa3.0 and public-domain
<leoprikler>snowball looks a bit weird to me
<leoprikler>ah, it's a 2-clause BSD
<leoprikler>(aka bsd-2)
<raingloom>thanks! updated the license field to a list.
<raingloom>any idea about the pkg-config weirdness?
<leoprikler>had to recompile my local guix, testing rn
<vits95>raingloom, leoprikler: is the order of the packages specified as inputs matter? Place the pkg-config higher, maybe...
<leoprikler>order doesn't matter usually
<leoprikler>the convention is alphabetical, as it's easier to organize
<ngz>Interestingly, I recently encountered a pathological case where it did. But it is very uncommon.
<ngz>The package specified both python2 and python3 as inputs. In this case, python3 must appear after python2.
<leoprikler>raingloom: you can drop cmake, but you need glib:bin and libarchive
<raingloom>leoprikler: in native-inputs, right?
<leoprikler>you also need gnome-online-accounts:lib and (perhaps?) rest
<leoprikler>and ytnef
<raingloom>leoprikler: thanks, that did it for appstream (and goa)
<leoprikler>s/ytnef/libcanberra and ytnef/ -- both as normal inputs
<raingloom>leoprikler: nice, it's building now
<raingloom>let's see if it finishes
<leoprikler>nope, it needs the gspell vapi, which doesn't exist
<leoprikler>you can try adapting gspell or alternatively adapt the generate-vapis phase from gnome-contacts
<raingloom>well, i can certainly try
<raingloom>never used Vala tho, so this will be fun
<sirgazil>I think I misread the news about support for SSH authenticated repositories. It seems it is only supported by "guix pull" command and the "channel" record, not the "package" record nor the build command.
<sneek>sirgazil, you have 1 message.
<sneek>sirgazil, NieDzejkob says: maybe you could add the source of your package as a submodule to your channel repo and then use local-file or something as the source? idk whether channels support recursive checkouts, though
<bricewge>sneek: later tell vits95: Wondering around, by luck, I have found why Alyssa was used as placeholder name in that blog post. Alyssa P. Hacker is a character in SCIP...
*bricewge should probably start reading SCIP.
<apteryx>oups: error: no suitable video mode found. Booting in blind mode.
<apteryx>insmod all_video worked from the GRUB2 command line! as suggested here:
<apteryx>I think this is caused by the monitor being 4K.
<apteryx>Perhaps we should include this module in our default GRUB config?
<vits95>leoprikler, ngz: thanks
<sneek>Welcome back vits95, you have 1 message.
<sneek>vits95, bricewge says: Wondering around, by luck, I have found why Alyssa was used as placeholder name in that blog post. Alyssa P. Hacker is a character in SCIP...
<vits95>sneek: later tell bricewge Thanks. The online version got a pictures, and there is even a characters. What a waste of time it was that i didn't managed to read this. I most certainly will.
<sneek>Will do.
<sirgazil>I can't access Guix resources (website, IRC logs, issues).
<sirgazil>Nothing loads.
<vits95>sirgazil: i's happens. How the way you configured the connection to the Web (dhclient, dhcpcd, other means)? I'd started dhclient recently multiple times, and get multiple instances running simultaneously. And connection was glitchy.
<sirgazil>vits95: The internet is working, it's just Guix stuff that doesn't load. I can access other websites.
<vits95>ping ... 100% packet loss (
<vits95>ping is works.
<sirgazil>NieDzejkob: Thanks, I'll try using a local git repository as the source.
<raingloom>leoprikler: i think i enabled VAPI generation in GSpell but now it fails a test
<raingloom>looks like it expects an X11 connection
<raingloom>i saw some Nix packages used xvfb for those, should i do that?
<leoprikler>yep, just grep for Xvfb in Guix source and you'll see a lot of packages doing that
<vits95>sirgazil: access is works, but ping is not.
<alextee[m]>no guile 3 yet? :o
<zzappie>alextee[m]: wtdy mean?
<alextee[m]>`guix install guile` installed 2.2 here zzappie
<alextee[m]>just pulled too
<zzappie>alextee[m]: its guile-next
<Rovanion>Are guix packages hashed based on inputs to or the outputs from a build?
<alextee[m]>oh i see
<alextee[m]>i want to integrate guile in my C program, any ideas what i should use? guile-2.2 shows up in pkg-config zzappie
<alextee[m]>actually let me ask in #guile
<fps>hmm, my icecat has some problems displaying unicode
<zzappie>alextee[m]: am guile newbie :) The big thing is guile 3 has jit compiler. There is a blogpost on guile webpage about new release. Also wingo's fossdem talk video is about state of gule is nice. Check it out
<fps>i installed quite a few fonts and ran fc-cache, but still
<zzappie>fps: what about --force option?
<alextee[m]>zzappie: will do, thanks!
<fps>zzappie: let's see
<fps>zzappie: other applications show the characters ok (e.g. emacs)
<fps>zzappie: the --force helped. thanks
<zzappie>fps: also if you encounter same problem on foreign distros you may need to add `export XDG_DATA_DIRS="$HOME/.guix-profile/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"' to your profile
<zzappie>Rovanion: There is hash for sources for the package, one you see it in package definition, but there is also /gnu/store hash. Which is the hash of package output (but I duno how precisely it is computed)
<zzappie>word "precisely" is misleading in this sentence, sorry, you can ignore it :)
<Rovanion>zzappie: By sources, do you mean the source code that derivation/package is built from?
<zzappie>Rovanion: yep
<Rovanion>The reason I'm asking is because, I think, in Nix the hashes in /nix/store are based on all the input to the build rather than the output. This has the effect that if a upstream dependency Y to package X is changed but it has no effect on the output of building of package X, all the packages that depend on X still have to be rebuilt. If it is correct that the hashes Guix uses are based on the output of the
<Rovanion>build and nothing else then it will not suffer this issue.
<zzappie>Rovanion: now when you said that I feel like I am not sure :) Need to check
<smithras>Rovanion: The hashes that you see in the store file names are not based on the output AFAIK. Like nix it is all of the inputs to the build
<NieDzejkob>the problem is that some packages will need to embed their own store hash
<fps>i was under the assumption that the guix package definition goes into the hash, too.. let's check the manual :)
<fps>the manual only mentions all inputs to the package. but assuming the build is reproducible then the mapping is unique
<fps>i'm pretty sure "all inputs" must also include the package definition itself. otherwise it would be possible to produce two packages with the exact same inputs, but different outputs which get the same hash
<zzappie>as I understand - output hashes should be somewhere, otherwise how would substitues work?
<fps>well, the basis is a "functional" one. a function in the mathematical sense (and the functional programming sense) only depends on its inputs
<fps>so if you have a function that produces an output from its input and you want to cache its results then you just need to know whether you computed the function for the same inputs before
<fps>thus you hash the inputs and store the result of the computation under that hash
<fps>then the next time you need to evaluate the function you again hash the inputs and see if you have the result already (in the store, or on a substitute server)
<zzappie>fps: I see but when someone sends you a package, you should check It's hash. And you cant do It based on it's inputs
<fps>the matter of trusting a substitute is a different issue :)
<fps>the nix approach (and guix's) only cares about the functional sense. trust is managed in a different way. e.g. you trust the guix maintainers and you trust in their capabilities to keep their build farm secure
<fps>then you use a certificate to make your connection secure and check signatures of their provided substitutes
<zzappie>fps: Ok, Im now digging the source code :) I found thing called "narinfo" and also a test `test-assert "substitute, corrupt output hash"`
<zzappie>that says "Tweak the substituter into installing a substitute whose hash doesn't match the one announced in the narinfo. The daemon must notice this and raise an error."
<raingloom>leoprikler: one of the geary tests fail with some weird error about keycodes so i'll disable it for now with a FIXME comment
<apteryx>Tested AMD R7 240 with Guix: installer boots, but installed systems looses display
<leoprikler>that's fine, we have quite a number of "disable-failing-tests" phases out there
<apteryx>I guess I need to blacklist radeon in my system definition like the installer does.
<ngz>Hmm. I have a frustrating package definition on my hands. It builds fine. I use the same build options as Debian, however, when I run it, it crashes, whereas it doesn't in Debian.
<NieDzejkob>does the backtrace have any hints?
<ngz>Let me check the exact error message. Something about double free or some such.
<ngz>double free or corruption (out)
<ngz>It is reproducible. I just need to enter the game's menu and wait a couple of seconds.
<NieDzejkob>hmm, maybe try valgrind?
<ngz>I never used that. How is it supposed to work?
<NieDzejkob>maybe someone assumed that a path will be $THIS short, and guix's hashes broke that assumption?
<NieDzejkob>you prepend your command with valgrind and it tells you when you screw up memory stuff
<NieDzejkob>with backtrace and all
<NieDzejkob>most useful when the program under test is compiled with -g, but it's not mandatory
<zzappie>Rovanion: fps: My mistake... I was wrong about outputs. Substitutes is a different story. After trying to make sence of derivations.scm found answer in the manual :) "The directory name contains a hash of all the inputs used to build that package; thus, changing an input yields a different directory name."
<ngz>NieDzejkob: with valgrind it errors without even starting.
<NieDzejkob>what is the error?
<ngz>Wow. ERROR SUMMARY: 4855333 errors from 697 contexts (suppressed: 0 from 0)
<ngz>NieDzejkob: I don't know. I have a wall of undecipherable text in front of me. The last lines do not help much.
<ngz>Interestingly, it crashes in the same with Debian package.
<ngz>(when called with valgrind)
<ngz>in the same way*
*zzappie got to afk
<raingloom>what was the library function for escaping a string for regex consumption so that it becomes a literal match?
<raingloom>i can't find it again >_>
<raingloom>ah, nvm, found it
<str1ngs>raingloom: that's what I've used in the past as well.
<sirgazil>I'm trying to use a local git repository as the source of a package, but the package fails to build: fatal: '/home/sirgazil/Documentos/guix-entorno' does not appear to be a git repository
<sirgazil>but it is a git repository and I can clone it with git.
<sirgazil>Can git-fetch handle local repositories or just remote?
<civodul>sirgazil: git-fetch is code run by the builder in a chroot, and it doesn't have access to that directory
<civodul>perhaps you should look into --with-source and --with-git-url
<civodul>they might correspond to your needs
<apteryx>trying to debug the installer on the install target, and at the REPL I get no code for module (newt) (from 'guix repl'). Ideas?
<civodul>apteryx: you'd need to "guix install guile-newt"
<apteryx>done, thanks :-)
<civodul>yw :-)
<raingloom>well, now it runs into an error on install. gonna have to get back to this later.
<raingloom>> No such file or directory: 'gtk-update-icon-cache'
<apteryx>civodul: weird, installed both guile and guile-newt, but still can't import (newt)
<apteryx>ah, probably I have to redefine GUIX_PROFILE, as Guix gently told me ;-)
<str1ngs>sirgazil: this snippet will do local git repositories. replace %source-dir with the full local path.
<sirgazil>str1ngs: But I need it to use a specific commit (using a version tag), like you do for normal, public git repositories...
<ngz>raingloom: See 'skip-gtk-update-icon-phase phases all across the code base.
<noobly>I've been attempting to install guix via the graphical installer - selecting very vanilla options/defaults - but after shepard is started and downloads are complete, I get an error about bootloader installation failing (for partition, I select full disk, no /home, it suggest three partitions and I accept). So, two questions: Any tips to resolve this or investigate furhter? And is there a way to drop down into the command line from the
<noobly>graphical install, or do I really have to exit completely and restart every time (my wifi sucks, so these downloads take all day, for every installation attempt)?
<NieDzejkob>hmm, I think the graphical installer puts an /etc/config.scm into your partition, you can continue with guix system init from there
<sirgazil>str1ngs: but thanks. I was just curious about using local git repositories, but I think what I really need is support for SSH authenticated repositories in package definitions.
<str1ngs>sirgazil: I think there was work to add ssh support to guile-git. I'm not sure if it's complete yet.
<noobly>NieDzejkob: thanks, that way I can at least get some debug info!
<sirgazil>str1ngs: From recent pull news: "guix pull command now supports SSH authenticated repositories as argument of @option{--url} and in custom channels definitions."
<sirgazil>I'm already using a channel that requires SSH authentication, and guix pull works.
<civodul>apteryx: actually "guix repl" is on Guile 3, so you prolly need guile3.0-newt instead (+ GUILE_LOAD_{,COMPILED_}PATH)
<bavier>nckx: iso creation finished, currently booting in qemu (virt-manager failed to validate the image)...
<bavier>oh shoot, the filesystem declarations aren't right for an install image
<nckx>Good morning, Guix o/
<nckx>bavier: M-hm, stuff like that is to be ‘expected’, since we can't really make guix system vm blindly ignore file-systems either.
<bavier>it seems like libvirt scans isos to validate, it failed something about "too many strings"
*nckx lols, cries.
<nckx>df --strings
<bavier>yeah, I kinda threw up my hands and moved on to qemu
<Telior>hello guix! anyone here using quicklisp?
<sneek>Telior, you have 1 message.
<sneek>Telior, NieDzejkob says: two things: it's supplementary-groups, plural, hence the error. Also, use either (file-append fish "/bin/fish") or #~(string-append #$fish "/bin/fish"). I consider the former the much nicer alternative
<Telior>ty, on my conf.scm, right?
<Telior>like this, right?
<nckx>Telior: That will fail. You still need to name the field: (shell (file-append fish "/bin/fish")).
<nckx>Or (shell #~(string-append #$fish "/bin/fish")) but I prefer the former too.
<Telior>like this?
<nckx>Telior: You forgot to delete the previous line but looks OK. One way to find out.
<nckx>I don't know how good our fish integration is.
<dongcarl>Hi all, how would I specify the license for something like:
<dongcarl>Is (license (list license:lgpl3+ license:openssl)) correct?
<nckx>dongcarl: Is any of the package's code actually licenced under the OpenSSL licence?
<nckx>dongcarl: I also don't see ‘lesser’ anywhere.
<bavier>gpl3+ only, seems to me
<nckx>So based on that file alone I'd say (license (license:gpl3+)) ; with openssl exception
<bavier>unless we have a gpl3+-with-openssl-exception
<nckx>It's just added as a comment.
<nckx>Telior: What I mean by that last line is that Guix relies heavily on (POSIX-)shell ‘profile’ files and might break if your shell refuses to parse them, but I haven't tried.
<dongcarl>Ah I see... exceptions can just be a comment
<dongcarl>sorry yeah not familiar with differences between gpl licenses
<dongcarl>thanks for the help!
<bavier>dongcarl: thanks for asking!
<nckx>dongcarl: Not saying it's the best way, but it's the Guix way. Creating ad-hoc gpl-with-foo-exceptions is probably not the solution anyway.
<NieDzejkob>ugh, I need to build icecat yet again
<Telior>nckx sorry, which line am I supposed to delete
<NieDzejkob>line 6 from this paste of yours:
<nckx>Telior: The ‘naked’ #~(string-append #$fish "/bin/fish").
<dftxbs3e>hey so, I think I'm nearly done. I'm rebuilding bootstrap-tarballs so that they include GNU Awk 4.2.1 instead of GNU Awk 5.0.1 because glibc 2.29 requires GNU Awk 4.2.1.
<dftxbs3e>It's at glibc-intermediate
<Telior>ah ok, and leave the rest as is? I also added the plural in "supplementary groupS"
<dftxbs3e>I think we're finally getting to it..
<nckx>user-account is a record, which you can read as (foo (key value) (key2 value2) …). Like with any other key-value system you can't just add (foo (key value) (key2 value2) banana (key3…) …).
<nckx>Telior: The rest *looks* good, but it's easier for you to test than for us to hunt for subtle typoes 🙂
<dftxbs3e>glibc-intermediate is further away in the process, I've never gotten that far. I think it's because I told myself lots of time that monkey-patching glibc sources wasnt acceptable so didnt even try doing it but it may be the only solution..
<Telior>k, I'll reconfigure and report back, thx! :)
<efraim>I got as far as glibc-intermediate with mine also, with libstdc+--boot0 as gcc7
<dftxbs3e>efraim, did you patch glibc to work around conflicting definitions of basename, sbrk, ...? I had to remove something that added 'throw ()' after the prototypes.
<efraim>dftxbs3e: nope, mine just worked until I hit glibc-intermediate
<dftxbs3e>efraim, which versions of glibc? also which platform? powerpc-linux-gnu?
<efraim> 32-bit powerpc-linux-gnu
<dftxbs3e>Ah okay
<dftxbs3e>efraim, which versions of GNU Awk do you have in there?
<efraim>i'm seeing if I can mirror my branch onto gitlab
<efraim>whatever the default is on master I think
<dftxbs3e>master has GNU Awk 5.0.1
<dftxbs3e>Without the ability to downgrade, there's only one package definition
<dftxbs3e>I created another
<efraim>here's my current WIP
<dftxbs3e>well my current wip is the master branch there
<dftxbs3e>Not everything is committed
<efraim>I tossed in a few matches so I wasn't clobbering everything
<dftxbs3e>Good. I havent done that.. I plan on making everything upstreamable later
<apteryx>civodul: the resulting 'guix repl' from building an image using the latest master appears to be Guile 2.2.6
<NieDzejkob>ah, fuck. one of the many dependencies of Keybase is, which doesn't have a license
<apteryx>s/latest/3 days old/
<apteryx>civodul: I'm confused about something: in my installation image, Guix refers to some older Guix than the one defined by the checkout from which it was built; correct?
<apteryx>so when I use 'guix system init ...', it's expected that I don't have the same code as I defined in my Guix checkout... right?
<nckx>apteryx: Yes, until you guix pull.
<apteryx>nckx: OK, but it's uncommitted work so far. Trying to debug it.
<apteryx>I mean, unpublished
<apteryx>(not to savannah at least)
<nckx>I have ~10 ‘XXX’ commits in my ~/guix from which I pull 🙂
<nckx>It doesn't have to be published if you don't want to, just committed.
<civodul>apteryx: 'guix system' installs the 'guix' package, which is a snapshot
<nckx>NieDzejkob: 😠
<nckx>‘Issue 1’. Infuriating.
<apteryx>civodul: I see. Thank you. I want to generate an image which include the very latest guix defined in my checkout. Any trickery already made available? I know we have for the tests.
<apteryx>(where we build a guix package from the git checkout)
<apteryx>oh, I guess I can configure the guix-service-type and choose the Guix package of my choosing there?
<apteryx>(in the operating system definition in gnu/system/install.scm)
<NieDzejkob>nckx: I messaged the author on Keybase and he added a license.
<apteryx> well done!
<nckx>NieDzejkob: 😃
<nckx>That only took 4 years! \o/
<apteryx>Are there any somewhat AMD cards known to work with Guix? I'm stuck in VESA at 1024 x 768 pixels using an AMD R7 240 ;-). The blacklist=radeon kernel argument appears to be necessary to boot.
<jonsger>apteryx: you mean without non-free firmware?
<apteryx>jonsger: yes
<apteryx>somewhat recent*
<jonsger>apteryx: no, because anything recent from AMD requires non-free firmware. Maybe some of them can do better than 1024x768 without firmware. Dont know...
<apteryx>thanks for the info.
<nckx>There was a brand-new user here yesterday with a similar problem (well, they said ‘no hidpi’, but 1024 x 768 qualifies). jonsger: Really none?
<nckx>As in none that need firmware for full features?
<apteryx>perhaps it's time to add a disclaimer to our manual to help people see the light. The libre amdgpu part is not useful without the non-libre blobs.
<jonsger>nckx: there where cards before GCN era which worked without firmware
<jonsger>but I tought that FullHD without any accelariton and some lightweight desktop like i3 should work even without firmware
<nckx>apteryx: That was suggested on the ML (no link, sorz), Ricardo responded that this is not a Guix issue, and I think I agree.
<nckx>This is not Guix's problem, it is not a shortcoming of Guix or GNU.
<apteryx>That's true. But we still help people partitioning their disks or running QEMU, even that's not strictly a Guix problem.
<apteryx>(in the manual)
<nckx>jonsger: ‘native panel resolution’ seemed like a weird feature to lock behind firmware yesterday, now I'm less sure since apteryx's card is so braindead.
<nckx>apteryx: I don't see the equivalence.
<nckx>Lemme find that thread.
<jonsger>I see it as a guix problem, because we remove the non-free firmware
<lispmacs[work]>from the commit log, it looks like a lot of interesting stuff happening in bootstrap land...? Are we about to get a blog post saying bootstrap binaries reduced to 5MBs?
<apteryx>nckx: ty
<Telior>it worked! :D
<dftxbs3e>seems like GNU Awk version change isnt making any difference..
<Telior>I just had to add (gnu packages shell) to the "use modules" bit
<dftxbs3e>Does anyome have a good GNU Guix Emacs config to share?
<dftxbs3e>anyone *
<dftxbs3e>by default, Scheme colored syntax is unreadable on a black terminal because the define names are strong blue
<lispmacs[work]>I like my view:
<dftxbs3e>lispmacs[work], thanks
<dftxbs3e>lispmacs[work], love it! Took the set-faces part
<lispmacs[work]>dftxbs3e: I'm a little confused looking at the .emacs file, trying to understand where the font and theme info is stored exactly
<dftxbs3e>lispmacs[work], just after: custom-set-faces
<lispmacs[work]>I'm also using the mononoki regular font, size 15
<dftxbs3e>I just copied that part in my .emacs and it worked
<lispmacs[work]>which I had to install separately, and then run fc-cache -vf
<lispmacs[work]>font-mononoki package
<lispmacs[work]>I was okay with the default emacs monospace font, but I did an update, and then it mysteriously changed to something awful
<nckx>lispmacs[work]: Something awful or something proportional rendered as monospace?
<nckx>I see the latter a lot.
<dftxbs3e>how would you open a terminal on the top right corner of a buffer in emacs?
<dftxbs3e>like, not split vertically or horizontally, just the top right corner
<lispmacs[work]>nckx: well, to be more precise, after the update it had switched to a proportional font, which look nice but was not, well, monospace. So I switched to the available monospace fonts which were all really ugly
<lispmacs[work]>so eventually I install mononoki regular font. I wouldn't call it perfect, but it is pretty nice
<nckx>Mononoki's ‘r’ bothers me in ways I can't explain.
<dftxbs3e>nckx, do you have any idea why the environment file in /tmp guix-build directories does not get created when bootstrapping GNU Guix?
<dftxbs3e>it would very much help debugging... otherwise I'm fully in the dark it's very frustrating
<nckx>dftxbs3e: No, I hadn't noticed that myself.
<dftxbs3e>nckx, how do you debug things then?
<nckx>Monkey-patching :-/
<dftxbs3e>nckx, I don't know GNU Guile's Scheme for much so it's quite hard for me to do that..
<nckx>I don't know whether (invoke "env") works in a bootstrap package.
<nckx>I'd expect it to.
<dftxbs3e>nckx, it worked yes
<dftxbs3e>that will be a BIG help
<apteryx>when searching with 'guix search' and getting a long list of results, instead of proposing to use | less; shoudln't we do it directly? à la git
<nly>wouldn't that make harder to make scripts with guix search?
<nckx>nly: You only call it if stdout is a terminal.
<nckx>apteryx: FWIW I think that's a great idea.
<nly>nckx: guix search emacs- >> found.txt
<dftxbs3e>nckx, so: "execve("/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-static-5.0.7/bin/bash", ["sh", "-c", "test -d nptl"], 0x3fffd261ecc0 /* 57 vars */) = -1" -- is that normal?
<nckx>nly: ?
<dftxbs3e>how do I replace the eeeeeee here?
<nly>this wouldn't be affected?
<nckx>nly: What would you expect to happen?
<nly>i get a list of all emacs-* pkgs in found.txt
<bavier>would be the same
<nckx>I don't understand what would change.
<nckx>found.txt is by definition not a terminal.
<bavier>isatty? would return #f
<nly>ah, thanks
<nly>i learned something
<valignatev>efraim: Whoa thanks for going through those Rust patches! I can imagine how time consuming it is
<nckx>dftxbs3e: My first instinct is to avoid the execve call altogether, not make it work (which bash would it call?). But I'm completely out of context, so I can't really say much.
*sirgazil decided to make his projects public instead to be able to install its artifacts easily using Guix channels (three things packaged, installed, and they seem to work ok).
<narispo>nckx: it's called by glibc's gawk
<narispo>my desktop just crashed
<nckx>sirgazil: Just in case: you know that channels can be file://s on your hard drive, right? None of my channels are public. Also, ssh:// channels are now supported but I haven't used 'em yet.
<narispo>amdgpu driver hung it
<nckx>3 cheers for AMD, today's shitty vendor of the day!
<narispo>the driver is certainly largely untested on ppc64le
<narispo>even if I think the bugs arent just on here
<nckx>Wait, are you dftx or someone who's stuck in the same spot?
<narispo>my phone's acc
<narispo>but sshhh
<nckx>Your secret's safe with us.
<narispo>I trust all the bots in this channel on that.
<ngz>valignatev: speaking of which, I'd love to see some quick "rust packaging" reference for dummies, because this is very confusing, at least to me.
<sirgazil>nckx: My channel was in a remote SSH authenticated repository, and guix pull worked fine with it. The problem is SSH authenticated repositories are not supported for packages.
<valignatev>Open gnu/packages/crates-io.scm - it has almost 20k LOC of examples :)
<nckx>I always feel a bit weird when I'm playing with $random_shitty_package and ‘guix lint’ announces ‘scheduled Software Heritage archival’. This is now valuable software, archived for humanity AND THE AGES! Oops.
<valignatev>ngz: You can also check relatively big Alacritty patch that I've submitted:;att=2;bug=39397;filename=0275-gnu-Add-alacritty.patch and all its direct and transitive dependencies: Beware though that it might be not very good because it hasn't been full
<valignatev>y reviewed yet
<ngz>valignatev: OK. When do you use #:skip-build? When do you cut the versioning at one digit instead of 2? Even 20k locs didn't help me.
<bavier>future software archeologists will thank you
<nckx>I kynda understand people who think this crosses some line in a presumably passive importer, even if it doesn't bother me.
<valignatev>ngz: These are a very good questions. I don't know about #:skip-build, I wanted to ask efraim the same question :)
<ngz>Also, when do you use '((hidden? . #t))
<valignatev>ngz: About the digits - It seems to me that you can cut them at major versions if they are more than 1.0 and on minor if they are less than 1.0. But you also can have something like 2.1 or 3.3 in case some package are locked at a particular minor version. So yeah, it's all semver
<ngz>I tried to define 2 Rust packages so far, and I stopped because I don't know the answers for these questions.
<valignatev>And it looks like that we don't hide packages anymore. Like ever
<ngz>Some packages are still hidden.
<sirgazil>nckx: Yeah, I was going to ask if there was a way to avoid the software heritage part.
<nckx>sirgazil: For some reason I assumed you were talking about channels, nvm.
<valignatev>But my answers might not be 100% correct, I'm kinda rely on my intuition and on the history of some mailing list discussions. Some packages are hidden because of some historical reasons. If you look for a recent commit history, you'll notice that efraim unhides them furiously
<nckx>sirgazil: Sort of, by specifying all checkers but that one after --checkers. Not a pleasant or future-proof solution.
<ngz>valignatev: I see that hidden packages do not provide any cargo-inputs or cargo-development-inputs. I wonder how it is even possible.
<valignatev>ngz: Example:
<ngz>Yes, but the criteria for un-hiding packages is not clear.
<ngz>It may be: un-hide as soon as their cargo-inputs are properly defined. But I'm not suer.
<valignatev>I guess that it's just unhide them all at this point
<valignatev>So if you package something new - don't hide it and properly define cargo-inputs
<valignatev>But in regards to skip/don't skip the build - I don't know the criteria unfortunately. I skipped the build on all of my patches, but I see that efraim unskips the build on some of them
<NieDzejkob>skip-build and hidden were being set to #t historically but we realized it's a bad idea so we now make it #f again whenever convenient
<valignatev>rust-md5 for example:
<valignatev>NieDzejkob: I thought that you're skipping the build because there's no way of reusing rlibs anyway
<NieDzejkob>there's no way of reusing them, but #:cargo-inputs means that they won't get built as a dependency, and it allows running the tests for the packages in CI
<valignatev>I don't think I understand what's the criteria for skipping and for not skipping the builds :)
<NieDzejkob>don't skip. all exceptions are for historical reasons
<valignatev>Ok, got it - is there some relevant mailing list discussion?
<NieDzejkob>at least, that's how I understand it, perhaps efraim will want to say something on the matter
<valignatev>Also, I think cargo test builds the package anyway
<ngz>Also I hope at some point Someone© implements an importer with semver, because currently, it's a pain to check for every required version in the cargo-inputs.
<valignatev>ngz: You might be surprised, but it's already implemented and awaits its time to be fully approved and merged
<ngz>Good news.
<valignatev>Here it is ^^
<drakonis>what's the status on merging gash and gash-coreutils onto the main tree for usage in packaging?
<valignatev>ngz: Yeah, it's a huge pain currently. I spent more than a month to import all the stuff required for building Alacritty T_T. I would be really grateful if the importer was version-aware
<NieDzejkob>valignatev: I'm not aware of any relevant ML discussion, but there's this:
<ngz>valignatev: I hope this didn't fall through the cracks.
<janneke>drakonis: ah, yes, that just needs to be done
<drakonis>ah, right, its nowhere near done, i take?
<janneke>packages are in wip-bootstrap, ready to be merged with core-updates, hopefully
<valignatev>ngz: I don't think it is, the discussion is quite active by the project metrics. I'll be there eventually, I'm pretty sure about it
<ngz>NieDzejkob: efraim does not explain why this is "unavoidable" in some cases.
<janneke>i guess they can be just copied over to master to play with
<janneke>we've been focussing on getting the bootstrap done
<drakonis>i mean, how would they be made available for invoking as part of the build process?
<drakonis>ie: get rid of needing to import build utils to do copying
<valignatev>NieDzejkob: Ok, I see, thanks. Now I'm kinda sad that I've submitted more than 200 packages and made sure that they contain skip-build just because all ripgrep deps were like that
<drakonis>just pull them into the root dir in master?
<janneke>drakonis: that hasn't been looked at yet, really
<janneke>just ideas
<valignatev>So looks like we're trying to build everything unless it somehow couldn't do it
<drakonis>ah, i see.
<janneke>i did look at replacing bournish some time ago, but that would need some serious work
<drakonis>aight, carry on.
<janneke>but as a "user" package to play with, gash-utils should be added to master
<str1ngs>janneke: latest nomad screenshot
<str1ngs>janneke: I'm just added emacsy window support.
<janneke>str1ngs: that's *so* cool!
<str1ngs>*Messages* buffer is being a PITA but I think I'll get it sorted out
<civodul>str1ngs: looks exciting, indeed!
*apteryx is happy booting from a btrfs subvolume
<vagrantc>janneke: thanks for the link regarding pinebook pro! it got me inspired to start messing with it and the other pinebooks
*vagrantc really needs to test pinebook on guix
<vagrantc>though i guess "guix pull" on aarch64 is not working past a certain commit?
<janneke>drakonis: i've pushed gash-utils to master
<drakonis>very nice.
<janneke>vagrantc: oh, cool!
<drakonis>much appreciated.
<apteryx>is it possible to configure the linux framebuffer resolution?
<apteryx>I see that utility exists, named 'fbset', but we don't yet have it in Guix.
<janneke>vagrantc: indeed, i'm told (#39352) it fails `nondeterministically', but i didn't stumble upon a success yet
<str1ngs>civodul: hello, I also plan on managing nomad extensions using a guix profile ala ~/.nomad.d/guix-profile . I hope to make it generic enough to manage any profile. by manage I mean buffers with graphics widgets to represent package meta data.
<janneke>vagrantc: i'm still using the commit that i mentioned in my post: guix pull --commit=c7dd15596ffd09ab40629c89e7014e51a4d7e95e
<janneke>vagrantc: i did flip the earphone dipswitch and ordered a new serial cable, i'll try to get a u-boot prompt again tomorrow
<vagrantc>janneke: cool :)
<janneke>i'm guessing we'll be getting real close, esp. if you have some u-boot thing
<vagrantc>i built a u-boot on debian with a small number of patches ... but never saw it successfully boot to a rootfs
<apteryx>how can I start gdm manually? I've reconfigured my system, which added GDM and started xorg-server, but it's not launched anywhere.
<janneke>vagrantc: i still haven't gotten any self-compiled kernel to boot :-(
<raingloom>geary packaged! ^u^
<raingloom>gonna clean it up and sent the patch tomorrow. now it's sleepy time.
<janneke>drakonis: yw, thanks for asking (even if you were asking for something else ;-)
<apteryx>nckx: cool, I'll look into it.
<drakonis>real talk though: ship gash as default guix shell in the future?
<janneke>i have no plans for that, but who knows
<civodul>str1ngs: managing Nomad extensions through Guix could be fun (and pleasant!)
<civodul>janneke, drakonis: i like the idea :-)
<civodul>one more step towards the Scheme machine ;-)
<nixo_>civodul, zimoun:
<drakonis>the scheme machine seems like an interesting thing.
<emacsomancer>I was trying to install Guix System on my work desktop (using the guided installer) and encountered this failure:
<nixo_>I finally got a reproducible build of julia 1.4-rc1, let's hope they help us upstreaming everything
<nckx>apteryx: I actually packaged fbset long ago but it didn't do anything interesting for me; I'll dig up my package. At least it won't be outdated 🙂
<civodul>nixo_: congrats!
<civodul>you should share your findings on the rb-general mailing list too
<civodul>so are we ready to merge your patch set?
<apteryx>nckx: cool!
<civodul>emacsomancer: it seems grub-install/efibootmgr is failing to write to your EFI system partition (ESP), with an i/o error
<dftxbs3e>civodul, hi, while you're here, I have a question, do you have an idea of what do we do when such a string wasnt replaced within glibc sources? '/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-static-5.0.7/bin/bash'
<nixo_>civodul: thanks! It really took me way too long. Not so fast, I got a build, it works, but patches are terrible (and not so sure they are completely safe, let's hear something from upstream)
<civodul>dftxbs3e: the "eeeee" thing comes from remove-store-references; we do that on purpose in very specific cases
<emacsomancer>civodul: I don't know enough about EFI to know why it would occur. I just chose a full-disk-partition (encrypted) install with ext4.
<dftxbs3e>civodul, hmm okay. well here it causes 'make' to fail
<dftxbs3e>because gawk itself calls bash to test if a file exists
<nixo_>after that, I'll be super happy to tell it to reproducible-build guys, hopefully it will be in one of the monthly updates :)
<nckx>emacsomancer: Looks like a bug in efibootmgr, or a bad interaction between it and your system firmware's nvram. It's not related to drives.
<janneke>civodul, drakonis: scheme machine, yay!
<drakonis>i discovered eshell
<emacsomancer>drakonis: eshell is great
<emacsomancer>nckx: is there is good workaround? I would just like to get a vanilla guix system install up and running
<nckx>emacsomancer: You should report this or ask for help in efibootmgr channels.
<emacsomancer>I don't care if it's efi boot or not
<drakonis>new users, heyo.
<apteryx>hmm... are the modules seen at the GRUB command line, using 'lsmod', the modules built in our init RAM disk?
<nckx>emacsomancer: If you don't boot any other OS & your firmware offers a CSM (‘compatiblity’, non-UEFI, ‘BIOS’, whatever) boot option in the set-up menu, you can try that.
<nckx>apteryx: No.
<nckx>The initrd and GRUB don't overlap in time. GRUB's lsmod lists GRUB modules.
<emacsomancer>nckx: thanks, I'll probably just try switching to BIOS boot and see if that works (it's just a single OS machine); is it useful to Guix if I report the bug?
<apteryx>nckx: I see. So, it seems we don't currently have a mean to add an extra module to GRUB's configuration, correct?
<nckx>It's not a Guix bug, so I'd rather you report it elsewhere (efibootmgr? GRUB? I don't know who owns what), but it's up to you.
<nckx>apteryx: Not that I know of. Which module would you like to add?
<emacsomancer>if it's not a guix bug, I probably won't bother.
<civodul>dftxbs3e: normally we patch gawk with gawk-shell.patch specifically for this reason
<dftxbs3e>civodul, ahhh! It's indeed being patched but it seems it hasnt worked this time
<civodul>dftxbs3e: perhaps you can strace the thing to see exactly what's trying to exec what
<dftxbs3e>civodul, I'll have a deeper look..
<apteryx>with 'insmod all_video' at the GRUB command line, my installed Guix System doesn't have a video mode to use. Strangely, the Guix System installer could display just fine.
<dftxbs3e>civodul, I did strace already, that's how I found out: "execve("/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-static-5.0.7/bin/bash", ["sh", "-c", "test -d nptl"], 0x3fffd261ecc0 /* 57 vars */) = -1"
<civodul>nixo_: these things can be very time-consuming, esp. on a complex beast like Julia
<nckx>apteryx: If ‘insmod video_all’ already works (even if the result isn't what you'd hoped), it's already available and there's nothing to add.
<civodul>dftxbs3e: so that would come from code calling the 'system' function of libc
<nckx>Adding modules to (say) grubx64.efi is possible, but it's quite exceptional and probably a sign you're actually trying to do something else.
<dftxbs3e>civodul, hmmm... so we should patch glibc in the previous bootstrap stage?
<dftxbs3e>or the glibc bundled with gawk]
<dftxbs3e>gawk should be a statically linked binary, so I suppose so
<civodul>dftxbs3e: that's already the case, see uses of package-with-relocatable-glibc
<civodul>well, unless something broke
<dftxbs3e>how do I query for uses? is there a shortcut in Emacs?
<dftxbs3e>grep should do it.
<dftxbs3e>civodul, so there is "(finalize (compose static-package
<dftxbs3e> package-with-relocatable-glibc)))"
<civodul>nckx: i don't see occurrences of "Internal error: Unreleased memory pool" in efivar and efibootmgr, weird
<commanderkeen>where are the xorg server logs? Im trying to run stumpwm and it fails to load
<nckx>commanderkeen: /var/log/Xorg.0.log?
<commanderkeen>nckx: that's where they normally are. I dont see any
<commanderkeen>NieDzejkob: thank you. i see them there. that's a new one for me
<civodul>found this:
<nckx>Also check for a DM log, e.g. /var/log/slim.log.
<nckx>NieDzejkob: Who the hell puts them there?
<nckx>Is that a GDM thing?
<bandali>XDG_DATA_HOME defaults to ~/.local/share if set, i think
<bandali>so it may just be X adhering to the XDG spec
<nckx>civodul: I'm not sure if that's the same error or not, it's missing ‘Skipping unreadable variable’ and ‘Input/output error’. ‘Internal error: Unreleased memory pool’ may well be irrelevant & non-fatal in other situations, we don't know.
<drakonis>hmm, how would i get libreoffice to load up dictionaries?
<nckx>In the grand tradition of Guile's scary ‘errors’ 😉
<commanderkeen>is anyone else running stumpwm from the repo right now?
<nckx>bandali: I mean X being started as a regular user.
<bandali>nckx, ah. sounds better than starting it as root, no? :p
<civodul>nckx: c'mon, that's not Guile, that's the EFI stuff :-)
<dftxbs3e>is there a way to start an environment that contains a build of a private package definition?
<civodul>Guile doesn't have a monopoly on scary errors, there's a touch competition
<nckx>Ouch, I touched a nerve.
<dftxbs3e>or just the patched sources..?
<civodul>nckx: you did! i almost threw an exception
<dftxbs3e>Got my answer in the manual.
<nckx>civodul: Oh! Speaking of which, I have a general wonderment: in most cases, when Guix dies on an exception, it spits out a sexp with a format string but not actually the formatted output. I hope you know what I mean. Why is that? Are we just missing something to catch & format these?
<nckx>I wondered that while writing babby's first exception yesterday, so apologies for not actually speaking any of the lingo yet.
<dftxbs3e>nope, didnt work for private package definitions :-/
<dftxbs3e>'guix environment -e '(@ (gnu packages make-bootstrap) glibc-for-bootstrap)''
<nckx>dftxbs3e: Does @@ still work?
<nckx>civodul: ‘Unreleased memory pool’ probably comes from lvm2's libdevmapper by the way.
<dftxbs3e>nckx, that throws a non-understandable error
<nckx>Stop triggering civodul.
<dftxbs3e>well I really don't understand it, so :-|
<commanderkeen>so i couldnt find anything in the logs about why stumpwm is failing. normally i'd configure .xinitrc to exec stumpwm via startx, but startx doesnt work. im lost on where to go from here
<commanderkeen>there's an xinitrc file in ~/.guix-profile/etc/X11. is the expectation for me to use that?
<leoprikler>nckx: in my experience, that's what most guile exceptions feel like. I've rarely seen one, where the formatted message is output, probably because calling format could raise another exception
<nckx>leoprikler: Same experience. Interesting suggestion, thanks.
*civodul spits an ugly backtrace
<civodul>nckx: the message comes from LVM2 indeed, good catch
<leoprikler>commanderkeen: does your environment even know about startx? such commands are usually hidden unless installed explicitly
<commanderkeen>leoprikler: I installed xinit package
<commanderkeen>i checked gdm logs and xorg logs. I just want to manually start it so any errors are spitted out to the console
<leoprikler>which console are we talking about here? VT1-6?
<commanderkeen>i dont know. i gotta take a break from this for a while. this all seems really cool. i'll be back in 4-7 days
<commanderkeen>the gentoo hard drive has to go back in until then. but i shall return
<shtwzrd>vagrantc: I'm still trying off and on to build a system for pinebook pro, using a small fork from the last commit before the move to guile 3.0, and with my patch that prevents pulling in the unbuildable xf86-video-intel, but I'm not quite at bootable either yet. Unfortunately, the errors I hit at this point don't seem terribly consistent.
<shtwzrd>vagrantc: but if you want to take a stab yourself, you don't have to go all the way back to kernel version 4.4, necessarily. There's an effort to get the necessary patches for the machine mainlined, and that fork is on 5.5 currently.
<vagrantc>shtwzrd: yeah, saw those too
<vagrantc>though 5.5 hasn't landed in guix yet either :/
<vagrantc>though wouldn't be terribly hard to add ... probably :)
<shtwzrd>is there already a linux-libre 5.5 out? Because I imagine the potentially tricky part is the nonfree blob identification/removal