<pkill9>what's the difference between search-paths and native-search-paths? <NieDzejkob>I'd guess that they behave differently when cross-building. There's certainly no difference in profiles <Formbi>oh, I have a question about the paths too <pkill9>Formbi: i think there is (package-search-paths <package>) that will return the search paths of that package <pkill9>then you can modify it, although identifying which search path to modify might be tricky <Formbi>yeah, but it gives something like this: «$1 = (#<<search-path-specification> variable: "CPATH" files: ("include") separator: ":" file-type: directory file-pattern: #f> #<<search-path-specification> variable: "LIBRARY_PATH" files: ("lib" "lib64") separator: ":" file-type: directory file-pattern: #f>)» <Formbi>I don't know what to do with this :( <NieDzejkob>you could do something like (search-path-specification-variable (package-search-paths ...)) <NieDzejkob>rekado: I'm kinda disappointed the the mock-guix is written in bash and not guile <vagrantc>heh. if you ask for --target=x86_64-linux-gnu on an x86_64 system ... it builds a cross-compiler for x86_64 *sirgazil just took a peek into the future... And it was black... But there was a light that said, "This is the GNU Hurd. Welcome!" <nckx>Guix puts your money away, takes a drag from its cigarette, and mumbles ‘whaddever you wants, kid, I ain't the judgin' type’. <nckx>vagrantc: What did you expect, really? <nckx>Once you have transparent cross-compilation its hard not to use it for everything. <vagrantc>nckx: i think on debian many architectures there's no difference between using the cross-compiler vs. the regular compiler <vagrantc>so i guess i was expecting it to not have to build a new compiler :) <Blackbeard>I am not sure, I think it is not written in lisp <sirgazil>Blackbeard: I saw the future, not heaven. If there is a heaven, they are running Windows. <nckx>That *would* explain a lot. <narispo>hey, is deprecating linux libre, or making GNU Hurd default so early a joke or serious? <vagrantc>never found the whole idea all that interesting anyways, i'll stick to the dirt and grime and free OSes <narispo>It could be interesting but I'm worried it wont run on powerpc64le any time soon, which is a blocker here <nckx>It's an alternative-universe fact. <narispo>I wish I was in that alternative universe <narispo>And that GNU Hurd supported powerpc64le *vagrantc admittedly glanced over it and didn't think much of it, missing some key details on the first pass :) <vagrantc>oh, more hurd progress from janneke, great news! :) <narispo>What would make improving GNU Hurd hardware support so hard? <nckx>Definitely read the whole thing, it's a joke but also really not. <vagrantc>and on that note, i'm going to attempt to be socially distant at a park <vagrantc>pointy sticks help maintain social distance! *nckx has been practicing ‘social distancing’ all their life. My time to shine has arrived! <sirgazil>Blackbeard: If you read it correctly, you won't feel the need to delete it :) <narispo>Maybe GNU Hurd isnt making all the best in breed technical decisions but I'm at least thinking some alternative Free Software non-monolithic kernel should get the world's attention <narispo>It's so sad we can't even run experiments for other paradigms because the effort required to put up the whole code is so huge <narispo>For me, the future of kernels are Object Capabilities kernels such as sel4 <narispo>Zircon is some kind of half "pure" paradigm kernel <Formbi>there was an attempt to use l4 in Hurd <Formbi>but the Hurd guys decided to stick with Mach <nckx>‘due to them not cosidering L4 suitable for implementing a general-purpose operating system on top of it’ <nckx>For fairness I should add the next part, they don't blame L4 alone: ‘and because of deficiencies in the original Hurd's design’. <nckx>So much has changed since then though. <nckx>Nix is on there, for Windows' sake, and we're not. <nckx>Oh, we're on the ‘Nix’ page, under Nix :-/ *sirgazil is seeing local air quality stations go green, probably due to these long days of human inactivity. <dongcarl>so... now that it's april 2nd UTC... the blog post... was that... a joke? At least the deprecation part? <lfam>It's still 1 April where I am <raghavgururajan>sneek, later tell apteryx: I have sent some revision patches for #40264. :-) <starcrATI[m]>guys, I just wrote 2 lines of Python in Emacs ... on Hurd ... and run the file afterwards ... again, on Hurd ... how cool is that ?!?! Thank you all so much for your work! :) <sirgazil>starcrATI[m]: What?! I didn't try that... <nckx>dongcarl: The post is completely serious. Only the dates are off. <brendyyn>starcrATI[m], HN just now has a post on the decreasing relevance of GNU. haha <brendyyn>nckx, im taking humour in the situation, not so much an actual joke <nckx>This is HN we're talking about, so they probably think ‘relevance’ means ‘market share’ or something similarly stupid. No, of course I don't. I think it's the relevance of a trustworthy open system is increasing every year. <brendyyn>a bird just flew into my window and nearly gave me a heart attack <nckx>Formbi: I wrote what I wrote. <brendyyn>probably gave its self a heart attack too. <alextee[m]>is gtk broken? it looks like it's missing rsvg support <alextee[m]>i'm just happy it thought my place was friendly-looking enough *nckx still has an almost perfect impression of a large pigeon when the sun catches an upstairs window. Beautiful, but must have been painful. <Formbi>good that after a while I thought it might be a bird and not something in the pipes <sirgazil>I could run a python program on the GNU Hurd too :) <sirgazil>But installing guile installs something called wishful_thinking :) <alextee[m]>(zrythm:20693): Gtk-WARNING **: 01:34:57.820: Found an icon but could not load it. Most likely gdk-pixbuf does not provide SVG support. <alextee[m]>i see the gtk+ package has gdk-pixbuf+svg as a propagated input <nckx>starcrATI[m]: Good night! <apteryx>raghavgururajan: cool! I'm a bit swamped but will try to look soon <sneek>apteryx, you have 1 message! <sneek>apteryx, raghavgururajan says: I have sent some revision patches for #40264. :-) <drakonis>that blog post is going to be bad for y'alls <se-sm-ca>yep I was happy that HURD was getting some attention but if it's just a joke... :( <drakonis>the hurd support is real but the timing is awful <Blackbeard>drakonis: I disagree. This is a terrible time, but the more reason to try to forget about it for a moment <nckx>‘Things are too serious so we should all be more serious’ doesn't compute. <drakonis>to be fair, the timing is really bad because people will take it seriously and believe that guix is actually axing linux support <drakonis>and therefore they won't be running guix <drakonis>its really not facetious at all to the average reader <bandali>isn't that the norm for tech-related, or hell, convincing, april fools jokes? :-p <bandali>to be fair, there's an "April 1" right at the top <bandali>yes, only the deprecation of linux is a joke <drakonis>again, april fools in the middle of world killing pandemic has kinda made people jaded so <Blackbeard>In my country it is not April's fools it is Innocent's day on December 28th <Blackbeard>So for a Mexican not really used to foreign traditions <drakonis>bandali: to be fair though, it will be taken as sincere because gnu has always tried to make hurd a thing *spk121 is downloading hurd <Blackbeard`>I used to work at a newspaper, we had this huge violence rise in mexico <bandali>drakonis, the `rivalry', if you will, between a gnu kernel and linux has been known, but i don't think so far gnu has ever tried to nix linux *apteryx had a good laugh, attempting to run linux-libre in userspace <bandali>perhaps in a day or two folks could revise the post and clarify that the deprecation of linux support is just an april fools joke <drakonis>would be fine but a little late if the post actually breaks out <brendyyn>anyone else find with duckduckgo when you search something, get the results page, go to a page, then press the back button, it takes you all the way to the ddg home page instead of the search results. and pressing forward again skips it too. its so annoying <apteryx>brendyyn: that because you disable LibreJS <apteryx>the javascript breaks the html page used by the IceCat DDG plugin. <apteryx>nothing Icecat can do about, unfortunately. It convinced me to give another try at LibreJS, though :-). It improved. Can be enabled/disabled without rebooting, whitelisting per domain with wildcards, etc. <Veera>What's %build-input used for? <Veera>#:configure-flags (let ((name (assoc-ref %build-inputs "name")))... <roptat>this is inside arguments, which should be quoted <roptat>this is evaluated later, when %build-inputs is bound to the inputs of the package you are defining <roptat>inside a phase, you can use inputs directly, because it's a parameter for the lambda (as in: (lambda* (#:key inputs #:allow-other-keys) ...)) <roptat>but outside of it, you need to refer to it in another way, and that's %build-inputs <Veera>just needed to pass a path of input to ./configure without using phases, lambda <spk121>yup, that definitely hurd running in qemu, alright <bavier`>thank you to everyone who's helped recently with the Hurd work. Deprecating Linux should let us all focus our efforts where they really count. *vagrantcish gives up on the kNetBSD port *vagrantcish hasn't tried using the non-registered account in a while <nckx>vagrantcish: Why'd ya be? <nckx>Oh, I only do that during spam waves. <vagrantcish>nckx: there was a spam-prevention measure a while back <vagrantcish>and i never bothered to register an irc account with the guix machines <nckx>If it's not mentioned in the topic, everyone can talk! …or I forgot to put it in the topic! <nckx>Both are equally likely but today's your lucky day. <vagrantcish>well, updated linux-libre to 5.6.1 almost kind of sort of <nckx>Cool. I should polish my ‘new’ wireguard-tools package and get it merged soon. <vagrantcish>i think wireguard got disabled by default ... will have to enable it <vagrantcish>it'd be interesting to use a defconfig + overrides approach rather than just copying the whole config file ... but i guess that can lead to unreproducibility under certain scenarios <vagrantcish>but it's much easier to see what you actually know you want, rather than the entire linux kernel .config <vagrantcish>debian does it that way ... it has it's own set of different problems, though *vagrantcish has been favoring linux-libre-arm-generic/linux-libre-arm64-generic which just use defconfigs <vagrantcish>also toyed with the idea of making one for x86_64/i686 <vagrantcish>not sure if there's a reasonable defconfig there or not <nckx>vagrantcish: Which problems are those? <nckx>I wonder how Mark actually manages these updates. He must have some form of automation, or I question whether he's fully human. <nckx>When he took some time off I basically maintained the linux-libre packages and it was… a lot of work. Very far from how I do things with my own kernels. I'd switch to a diffconfig in an instant if it were up to me. <vagrantcish>right, i think i helped with one of those updates too <nckx>And I thank you for it. It wasn't really a fun job. <vagrantcish>it's pretty common in the embedded world to have one config per board or maybe family of boards ... *vagrantcish suspects arm64 failed to build for some reason <vagrantcish>and i didn't run with keep-failed or anything ... so no idea where the log ended up <vagrantcish>i'm very much tempted to just push the source update and a few linux-libre-*-5.6 packages without making them default *nckx 's bcachefs just shit the bed. Badly. 😒 If I suddenly go off-line for the night, good night. <nckx>vagrantcish: Have you tried/been able to reach mhw at all? <vagrantcish>it's been well over a week since i started mumbling about it, and there have been 5.4.x and other kernel updates since <vagrantcish>but communication via git commit could be seen in the wrong light :/ <vagrantcish>though i've gotten pretty used to guix's general policy of anyone commit anything <vagrantcish>so the status of linux-libre, while soon to be deprecated, is still a bit unusual. <nckx>Adding a new non-default version is definitely fine. <vagrantcish>then at least my slower systems will get the source tarball substituted :) <nckx>If you handle .config updates (or the lack of them) different than's usual, do add a comment to that effect. *vagrantcish wonders if linux-libre-latest, linux-libre-lts (long term support) would make sense to have as aliases <nckx>The LTS versions already have an unchanging series variable name AFAIK. <vagrantcish>linux-libre-latest-lts, linux-libre-somewhat-recent-lts, and linux-libre-wow-that-is-still-lts <brendyyyn>i actually searched for lts in linux yesterday and thought we didnt have one <brendyyyn>since my webcam doesnt work on guix i thought lts might fix it <nckx>vagrantcish: Sure. Since this isn't a ‘regular’ package we don't need to worry about NAME and guix package -u, which is nice. <vagrantcish>although, in the "linux" world, "next" kind of means something else <vagrantcish>i'll just add the version and some versioned packages and call it a day. <brendyyyn>i get this uvcvideo: Failed to query (GET_INFO) UVC control 2 on unit 1: -71 (exp. 1). <nckx>Sure, but (a) ‘that’ linux-next is not something that'll ever be in Guix (b) let's yours won't be in there long. <brendyyyn>thats for a usb webcam. the built in one isnt detected at all. <nckx>brendyyyn: Super great helpful message :-/ <nckx>Yeah, UVC was the only thing I recognised from that. <brendyyyn>hmm looks like it should be in since ages ago with 4.9 <nckx>You probably read <title> instead of Fix: <title>. <nckx>brendyyyn: The first release with that fix is 5.5. It's broken in 5.4. <nckx>I don't know your Guix chops, but you can always (kernel (package (inherit linux-libre) (version "5.5") …)) if you're feeling lucky. <brendyyyn>its alright there is no rush. thanks for your help. i did a little duckduckgoing before but didnt come across the fact it may be fixed <nckx>Now I have to go to bed; the sun is about to rise. <raghavgururajan>"Errors found in `Notification` component 1:" (qrc:/ui/modules/Linphone/Notifications/NotificationReceivedFileMessage.qml:2:1: module "QtQuick.Layouts" is not installed, qrc:/ui/modules/Linphone/Notifications/NotificationReceivedFileMessage.qml:1:1: module "QtQuick" is not installed *raghavgururajan don't know what is missing *guix-vits afk ;Hi there. ***calher is now known as KE0VVT
***calher is now known as KE0VVT
<raingloom>so, i guix system init-ed Guix onto an SSD, but when i transferred it, it didn't boot <raingloom>for some reason it didn't want to init with (uuid) partitions (even though the UUID was correct) so i used the /dev/disk/by-uuid path <raingloom>am i gonna have to init it again to reconfigure the bootloader? also, is there a guide for using the rescure REPL effectively? <raingloom>i tried modifying the --root kernel argument in grub to point to /dev/sda1, but that doesn't work either <Blackbeard>raingloom: why are you not using something like (device (uuid "1234-ABCD" 'fat)) <raingloom>Blackbeard: because Guix didn't find the device that way <raingloom>even though i triple checked both the label and the uuid <Blackbeard>raingloom: may it be related to linux instead of linux-libre ? I probably shouldn't <raingloom>Blackbeard: i'm using the same version of linux-libre on both, so it shouldn't be a problem. <raingloom>tried writing the UUID in uppercase, didn't change anything <Blackbeard>raingloom: I don't know. This is out of my knowledge :/ <raingloom>do you happen to know how to use the rescue REPL in a way that doesn' suck? <raingloom>(so, is at least as usable as a /bin/sh REPL) <selea>Good morning, please tell me that the Hurd support is not a april fools joke <rekado_>raingloom: there’s a bug with bournish since the move to guile 3 <raingloom>rekado_: is that related to the rescue shell or the bootloader install/config? <rekado_>raingloom: it’s a problem with bournish itself. It uses @@, which doesn’t work with declarative modules in Guile 3. <selea>Blackbeard, I thought it was an april fools joke at first, but the more I find information about it - it looks like it is true! <rekado_>I had copied the cross-built “hello” closure to the Hurd image, but didn’t think of copying Guile over. <rekado_>then I had the idea of a little “guix” executable and was annoyed to see that I didn’t have Guile. <rekado_>instead of shutting down the VM, remounting the disk image as a loop device, and copying the Guile closure I just used bash. <rekado_>probably could have installed some Guile version with apt, but I don’t remember how to install packages on Debian… <rekado_>for a few moments that little shell script is sufficient to support the illusion :) <rekado_>janneke: now that native builds with Guix on the Hurd are possible do you think it’s the right time to set up a few build VMs for ci.guix.gnu.org? <rekado_>or would it be better to wait some more. <rekado_>(I’d prefer a VM that was built with “guix system”, of course) <janneke>rekado_: i would say, the sooner the better, even if it's not with a proper guix-built vm <janneke>unless it's just too much work, but then we could focus on that first <janneke>at the moment, i start the guix daemon manually... <janneke>i guess a requirement would be to hook that up to the init system? <raingloom>is there developer interest in supporting other kernels too? i've heard a few whispered wishes for *BSD support. <raingloom>brendyyyn: simplicity and improved security. the Linux kernel is quite huge and the BSDs have more developers than the Hurd. <raingloom>(driver support for BSD is probably also better than for Hurd) <bricewge>I think that f2fs isn't supported by Guix <raingloom>bricewge: damn. can't i just add the necessary package and make it work? <raingloom>ah, looks like i'd just have to add it to guix/build/file-systems.scm in the various %partition-*-readers lists <bricewge>raingloom: It look way more involved than that <bricewge>Take a look at the commits to add support to jfs that nckx made a few months ago. <efraim>I have to catch up on the backlog but currently python-minimal on core-updates on aarch64 segfaults during one of the tests. I'm testing it now with 1 core <jonsger>civodul: is this serious that we want to replace linux-libre with hurd at 2.0? <jonsger>civodul: hardware support, hardware support, hardware support :P <rekado_>It’s fascinating to see Phoronix trying to decide whether this is serious or not. <leoprikler>"Try guix install linux-libre to run Linux in userspace." Nice one. <str1ngs>yes, but there is too much keybinding clashing of course <civodul>how can one see the default key bindings in Nomad? <str1ngs>but most of the bindings are pretty standard to what you would expect of emacs. <civodul>i expected those of emacs-w3m/Conkeror :-) <str1ngs>I have still not settled on keybindings for web-mode. the closest model I can think of is info mode in emacs. <str1ngs>the reset of nomad behaves like emacs default bindings <str1ngs>eg echo-area C-a beginning of line C-p for previous history <civodul>really nice to see this Guily Emacsy code! <str1ngs>some feedback for web-mod map would be appriciated. <str1ngs>thanks to emacsy it's doing most of the heavy lifting. <jayspeer>hello! is rust's cargo not present in guix? I've installed rust package but cargo is no where to be found :/ <civodul>jayspeer: i think it's "guix install rust:cargo" <str1ngs>civodul: nomad extentions will be managed by guix. using a profile in ~/.nomad/ <str1ngs>I'm using guix scripts right now. it's not ideal but it works <str1ngs>for installing packages I was going to use (guix script install) and vte for output. <rekado_>str1ngs: could there be an environment variable to point to a directory containing extensions? Then there would be no need for a separate profile in $HOME. <str1ngs>rekado_: yes you can use GUIX_PROFILE. the reason for the profile in ~/.nomad.d is for optional runtime dependacies. <str1ngs>rekado_: say you have a nomad extention that uses guile-gcrypt. nomad can install it for you without affecting GUIX_PROFILE. hope this makes sense? <leoprikler>I personally prefer `guix environment` with propagated inputs. <Formbi>propagated inputs are very annoying <jayspeer>I'm getting ssl error [60] when using cargo from guix (foreign distribution ubuntu); is there an env var I should set? curl from guix resolves crates.io just fine <ericst>Hello, I am trying to package supbackages from a git repository that countains a few... Is there a possiblitlity in the package definition to tell guix to run the build phases in a subdirectory ? <rekado_>ericst: you can run any build phase again, but I recommend unbundling instead. <ericst>in the origin, how do I specify the specific subdirectory <rekado_>hmm, so the guile-emacs build seems to go in circles <rekado_>oh, it’s not a loop. It’s just generating different files. <rekado_>but each time it has to load the same files, and that’s really slow <rekado_>I wonder if the regular Emacs build does the same or if it compiles the files first. <rekado_>something doesn’t seem to stick. It regenerates autoloads, for example, the same again and again, for each file that it tries to generate. <zzappie>following yesterday and today's hot conversation on Hurd/Linux support I have a question. what does "kernel support burden" mean? I understand that there are many linux specific features like namespaces, /proc etc... But can they be abstracted? As an example I thought first - libvirt is basically a common API for many types of hypervisors which are very different. Can guix in theory be structured in a way that differnt kernels support <leoprikler>For Guix to run under some kernel, you need two things: <leoprikler>1. guix, the command, which depends on guile and some other libraries, that need to be built first. <leoprikler>2. a system description, that guix can work with to generate all the necessary files. <civodul>jonsger: does the MATE upgrade you posted fix some of the issues you reported? <civodul>great work on both works BTW, much appreciated! <leoprikler>With how guix uses its own file system structure (/gnu/), it shouldn't be too hard to account for other UNIX kernels. Hence you'll only have to swap out the (kernel ) field <jonsger>civodul: eh no. That are the issues we found while testing. But I guess all of them are already existing on MATE 1.22 <leoprikler>other packages/services may be more problematic, since they first have to build on hurd, and a number of them are probably linux-specific <zzappie>leoprikler: well it does seems like lot of work especially the last part <mbakke>efraim: which Python test is segfaulting? <mbakke>it's been building fine on Berlin FWIW, even before the latest core-updates commit which does not actually work as expected <civodul>jonsger: would you recommend upgrading before the release? <mbakke>civodul: I tried to adjust python-boot0 to ignore a phase from Python as discussed <dutchie>is there a way to see what git commit a given build on ci.guix.gnu.org was run from? about to try to bisect to find where a build fail appeared <mbakke>that snippet almost works, but has a problem: I need to insert an extra ) between "original" and (reverse (fold-right ...)), and remove a stray ) from the result of fold-right! pheeew. <mbakke>also, for some reason I'm not able to fold over added directly, but folding over (reverse added) is fine, hence the double reversing <mbakke>it was a fun pattern matching exercise, but not sure if it's worth the trouble <jayspeer>so... what is exactly the state of guix hurd? can I create an image with hurd yet? <mbakke>Berlin has not started the world rebuild yet, so patching python on all architectures is not that much of an issue <mbakke>dutchie: I don't think so, would be a great Cuirass patch though <mbakke>dutchie: I typically search for "<package-name> spec:guix-master" and go from there <mbakke>jayspeer: not yet, but soon! civodul and others were trying really hard yesterday to add that functionality for the April 1st blog post, but in the end we had to cheat with a Debian base image. <dutchie>hmm, what's the fix for this error again? automake-1.16: error: cannot open < ./doc/guix-cookbook.de.texi: No such file or directory <dutchie>i'm sure i've seen it before and it's a really simple thing <reepca>hmm, I've got a substitute download that's stuck partway through. That's the third time I've noticed that within the past day or so, but I also changed my router recently-ish. Netstat says it's in the ESTABLISHED state, and wireshark hasn't mentioned any traffic on that connection in the past 5 minutes or so. Have we changed up any of our downloading code recently? <dutchie>ahh, ./bootstrap, that's the one, thansk civodul <reepca>strace has it waiting on a recvfrom currently <efraim>mbakke: test_constructor (test.test_io.CBufferedRandomTest) ... Fatal Python error: Segmentation fault , passed afterward with --cores=1 <jayspeer>reepca: are you by change using wifi in highly populated area? <efraim>2.5 hours with 1 core on a pine64 <jayspeer>I had similar issues and sought help with ethernet cable which managed to fix my problems <reepca>jayspeer: using wifi in more or less the middle of nowhere, as it happens <mbakke>apparently a kernel bug, aka CVE-2020-9391 *mjw happily downloads wishful-thinking <reepca>TCP connections should either be reset automatically or continue working if packets fail to make it through for a minute or so, right? The connection to the outside world is a bit spotty here, but it's certainly working now, so I'm wondering if it somehow ended up in a broken state? <mbakke>civodul: any ideas on that pattern matching exercise? or objections to punting and just patching Python directly? :P *mbakke goes for a short meeting <J[m]>Is there any plan regarding the POWER platform? <J[m]>I've read that you are looking for ARM and MIPS based hardware in addition to x86 <efraim>my pine64 is on debian running 5.4.8, i'd just punt on it *efraim goes back to building out to guix and efl on aarch64 <leoprikler>zzappie: it is, but not in the sense that "keeping support for linux" would be a problem <terpri_>J[m], no power plan that i'm aware of but i'm hoping to bootstrap guix on a talos blackbird soon <J[m]>terpri_: That is why I asked 😛 I am thinking about getting the Blackbird too soon <J[m]>Do you have it currently? <kmicu>Hi, I’ve switched to Hurd kernel as described in the recent post but now my mouse and RYF‑certyfied wifi don’t work anymore? Did I miss something? <leoprikler>the joke, perhaps, but in case you want to seriously switch to hurd, you might be missing drivers <leoprikler>I'm not sure how everything works out with hurd's microkernel architecture, though. <kmicu>Even Emacs works on Wayland here so for me switch to Hurd is 99% usable just need to fix the mouse. <terpri_>J[m], yes, just have to assemble the parts (and play with fedora for a bit as that seems like the most popular distro for talos boxes) <terpri_>J[m], #talos-workstation is the main channel for that system btw, and very helpful for part selection if you end up building one (there's a limited selection of compatible cases, ram, etc.) <pkill9>the blog post about guix on hurd says you can run linux in userspace: how does that work? <rekado_>pkill9: linux is just another program. You can install it on the Hurd. <civodul>rekado_: was it you who said the Bournish REPL is broken? <civodul>i've booted a VM with --repl, then did ",bournish" <civodul>and ls, pwd, cd, etc. seem to work fine <rekado_>I did not boot a VM. I just switched to bournish in a REPL and then nothing worked. <civodul>rekado_: ah but wait, on master we use 2.2, so the @@ things are fine ***rekado_ is now known as rekado
<civodul>jonsger: if you feel like one (or two?) of the MATE bugs should be tagged as important, please do tag them <J[m]>Do you know if that room is bridged over to Matrix already? <J[m]>terpri_: I am saving up for the blackbird one at the moment, but when I will have the money for it - the next generation will probably arrive :P <civodul>mbakke: re python-boot0, another option would be to inline the phases that python-boot0 needs to inherit <civodul>that is, instead of ",phases" in python-boot0, you just arrange to have the list of phases you really want from python <mbakke>yes, but that's boring! ;-) but it will do as a backup solution. <terpri_>J[m], no idea though there are some *[m] nicks there <mbakke>in the next core-updates round I intend to inline the phases anyway so that Python can be changed at will. <terpri_>J[m], i haven't heard of major upgrades in the coming months, but you've waited long enough to get the second-generation version of the cpus :) with some upgrades to hypervisor/ultravisor support iiuc <mbakke>but copying all the phases is quite an ugly workaround for a not-so-big problem (rebuilding Python on i686 and x86_64). <civodul>or can't you do: (match phases (('modify-phases original-phases changes ... ('add-before 'the-phase-to-remove _ _)) <J[m]>terpri_: I've heard that POWER10 is around the corner and probably will be released 2021 :) <terpri_>sure, if you can wait til 2022 for your power workstation :p <mbakke>civodul: that looks promising, will try that after a food break, thanks! :-) <efraim>Has anyone managed to get boinc working on Guix? <terpri_>also, raptor has some kind of vps service, but probably not enough for much guix hacking (wouldn't it be fun to have reproducible, free cpu microcode, bootloader, etc.?) <J[m]>terpri_: I am busy saving up for things for my kids, so the workstation comes second :) <jonsger>J[m]: we have a somewhat working powerpc64 (big endian) guix. Ask dftxbs3e for more details. 64bit little endian is still little tricky <bricewge>I plan on writing a patch to add ${fs-type}-utils to the system profile based the file-systems defined. <terpri_>jonsger, oh, that's good to know. surprised be is working first, le seems simpler for driver compatibility etc. <terpri_>bricewge, no, but that's sounds like a great feature to have, i often forget packages like btrfs-progs when installing <terpri_>speaking of which, does guix have official lvm support yet? <terpri_>might be considering how much bloat it would add to just add all the fs utils to %base-packages; people will often want to removable drives with random FSes, regardless of static filesystem configuration <nckx>Any reason they can't install foofs-tools when they do? bricewge: No guidance, just: how? <jonsger>terpri_: yes, LE should be simpler on userland. But LE is harder to bootstrap in Guix due to required versions of gcc and glibc in the bootstrap path... <bricewge>nckx: They can but I assume that when I use a FS I'll need tools to manage it. Especially when something go wrong. <bricewge>And when it happen it's generally not the moment to try to install a package <nckx>bricewge: The first part was more in response to terpri_, not you. Having an fs-type in your system configuration is a good reason to have it present by default. <nckx>I just wonder how you'll pull that off 🙂 <nckx>Being currently a list & all. <bricewge>btrfs-progs added 7.7MiB, so it wasn't merged. <brendyyyn>btrfs is exotix? i thought it was the recommended default filesystem now <joshuaBPMan>Hello guix!!!! Way to make an awesome announcement on the Guix blog! I've only read Phoronix's article about it....now I need to go digest the blog post. And paste it on my wall at home. And Read it every night. <bricewge>nckx: Than plan was to extend the system-profile from file-system-service-type by tweaking file-system-packages (gnu system linux-initrd) <civodul>jonsger: normally there's a "shutdown" entry in the menu next to "log out"? <nckx>brendyyyn: Depends on whom you ask about what. <bricewge>Adding to that btrfs isn't fully supported in Guix yet, subvolume can't be used as root #37305 <terpri_>how does the "services" list end up influencing the package set? maybe something similar could be done for file-systems <mbakke>brendyyyn: RHEL, the canonical "enterprise" GNU/Linux distribution, removed btrfs support entirely in version 8, so there are mixed opinions indeed. <terpri_>doesn't system-services->configuration in (gnu installer services) munge the package list? or am i misundersting its purpose *terpri_ still undercaffienated, clearly <nckx>This is a file system that can't even read from more than one drive at once. It's great for basic home use & hobbying & very specific things like they do at Facebook. I'd never recommend it as the default file system for a distribution. <bricewge>nckx: Do you mean what I suggested can't work? <brendyyyn>mbakke, ext4 doesnt even checksum anything right? seems silly to recommend it in 2020. what is the recommended one then? <mbakke>brendyyyn: RHEL uses XFS by default. <terpri_>also my hacked-together lvm support is 90% functional, i'd be happy to make a proper patch out of it if it would be useful for others <nckx>bricewge: I'd never go that far, everything can be done in Guix. But how do I, say, opt out of the magical jfsutils that Guix would add to my system profile? <mbakke>brendyyyn: it has metadata checksums at least. <mbakke>all file systems have their pros and cons, so there is no obvious best choice <brendyyyn>seems like avoiding data corruption is a pretty important one for recommending to the average user <mbakke>terpri_: LVM support in the configuration system would be a very welcome addition <rekado>XFS is pretty common where I come from <rekado>and that’s probably because we’re using RHEL / CentOS everywhere <rekado>ext4 is a good default for average use cases <rekado>we pick file systems based on requirements. XFS is good for very big storage with many small files, etc <mbakke>brendyyyn: I've heard of weird btrfs corruption issues, so I guess it's not as simple as just having checksums for each block. <mbakke>at least ext4 and xfs have fsck tools, unlike btrfs <bricewge>nckx: That the main pain point I hoped I would get so suggestion on. But isn't it already the case with any service extending 'profile-service-type? <brendyyyn>mbakke, do they come from weird uses though? if were talking just a default single file system install on a home computer, would you expect more reliability with ext4 or btrfs? <mbakke>brendyyyn: ext4 definitely! probably the most battle tested file system out there, maybe except for NTFS. <brendyyyn>i thought it has no silent data corruption protection though? <nckx>I think ZFS is the only reliable file system that does. <alextee[m]>rekado: it looks like we'll have to deprecate the old zynaddsubfx UI. the program is essentially the same, however it uses the same LV2 URI for the plugin and the same URI for the old and for the new UI, and this causes many problems if we keep both. there is no need to keep the old zynaddsubfx because it's essentially the same program with a refreshed UI, and it exposes everythign the old UI did. so i guess i should create <alextee[m]>a zynfusion package and somehow mark zynaddsubfx as deprecated? <mbakke>spoiler alert: ext4 was two hours, btrfs was 5 seconds <rekado>alextee[m]: I wonder if there’s any downside to keeping both <rekado>you can’t install both into the same profile <rekado>but maybe there are people who prefer the old interface <nckx>alextee[m]: Wait, back up, what? <alextee[m]>rekado: 1. you'll have to patch the URI to be different to even have the possibility of a choice in hosts <alextee[m]>2. current hosts don't let you choose between plugin UIs <rekado>(I meant choice in installation only) <rekado>in Guix we can’t express that two packages conflict with one another <alextee[m]>rekado: oh maybe we don't have to deprecate it, but installing both would essentially lead to hosts just detecting a duplicated URI and skip one of them <rekado>so that users won’t accidentally install both of them <alextee[m]>that would be nice to have, im not sure why guix doesn't have that feature yet <nckx>alextee[m]: You're making too many assumptions about hosts. AFAIK qjackctl doesn't use ‘URI‘s over here 😉 <waynedpj>ahoy all. just read the blog post about the move to GNU+Hurd and the phasing out Linux Libre. interesting news, just wondering if there is any background on the the decision, i.e. mailing list archive, IRC logs, blog post? a quick search did not turn up anything. thanks. <alextee[m]>nckx: well, if you only use the binary, it would be fine, but if you use thet plugin, every host uses the lilv library to detect lv2 plugins, and that skips duplicated URIs <alextee[m]>lv2 plugins are identified by their URI and it must be unique for each plugin <nckx>mbakke: That doesn't suprise me at all. I restore a completely destroyed btrfs array at least once a year. <nckx>I know, but not everyone uses LV2. <alextee[m]>one would think you could just oatch the URI but that leads to the huge problem that presets cannot be shared and wont be compatible with what other distros have <nckx>Now I wish I'd followed this discussion y'day. I only saw ‘zynaddsubfx’ and ‘ruby’ and zoned out. <nckx>Is this the same project? Is the stand-alone interface deprecated upstream? <alextee[m]>nckx: it's the exact same project, just needs a flag to enable the new UI, and then a huge ruby mess it needs at runtime for the new ui <nckx>Look at that, the way to get a reaction out of me is to threaten to take away my toys. Who knew. <nckx>alextee[m]: I will most certainly not have fun, thanks! 😉 <nckx>Sorry for flipping out just now. The thing about the toys was real. *sirgazil just decided to move back stay on the multipackage manager train for a longer time :( <sirgazil>I was trying to use guix to manage all the dependencies of my Python-related projects, but packaging all I need is a job in itself and would not be able to get work done. <sirgazil>So I take this opportubity to thank all packagers in the world because that's quite an invisible, ungrateful job. <rekado>nckx, alextee[m]: We don’t need to replace one with the other. <rekado>installing both would be a user error. <alextee[m]>yeah i want to keep both, but guix needs a "conflicts" in its package declaration <nckx>This is the same (non-)problem as, say, overlapping binaries in /bin. <alextee[m]>well, it w on't lead to any errors actually if you install both, just "undefined" which one would be used by hosts if you load the plugin <rekado>alextee[m]: let’s discuss this on guix-devel@gnu.org <alextee[m]>rekado: 👌 will send a mail with a cleaned up patch and some background info soon <alextee[m]>is there an easy way to display the contents of a file for debugging? <brendyyyn>alextee[m], you can build a package with -K if it fails. the files will be kept in /tmp/ <alextee[m]>i want to check if my substitions are actually being made <andydarcyjewell>I've been using the --keep-failed option to test out what's happening with my problems with packaging Factor <andydarcyjewell>Even with freshly grafted-in sources and boot image, I get the same problem, so I don't think it's any kind of patching that's causing it. Any suggestions where else to look, please? <rekado>the error is reported by Factor, isn’t it? Can you build with debug symbols and run it in gdb? <rekado>or even check with strace to see what it tries to do when it fails? <andydarcyjewell>rekado: I can give it a go. Not used strace much, and never tried gdb. The error it's giving is that "Invalid header" one, but I think it's erroneous, because the exact same file works on a binary created the prescribed way. <andydarcyjewell>I'm suspecting now that the error is more related to the way the code checks the header, rather than the header itself - that it is somehow misinterpreting it. Will re-acquiant myself with strace, and see what I find. <mbakke>poor Miguel just missed the 1.0 deadline, and is on track to miss 1.1 too :/ <mbakke>I'm willing to have a stab on merging it <mbakke>but not sure how safe that is just before the release <nikita`>I have a question for a patch on an upstream I'm working on this week. I've been absent long enough to forget the layout of the build container of guix. /dev/null exists, right? <lfam>I'm working on rav1e packaging again <lfam>I'd guess a "minimal /dev" includes it <alextee[m]>not really an expert on binaries, but the binary fails to run unless i run it with LD_LIBRARY_PATH specifying the path of some library <alextee[m]>i mean, there's probably a guixy way to fix this <nikita`>i mean the line is okay, but the execution of the general idea in the makefile is a bit quirky <nikita`>i think it got weird the minute Nick introduced luaJIT to the equation <NieDzejkob>you could patch the path given to dlopen before the build, or add a rpath flag to the linker <alextee[m]>NieDzejkob: yeah, and i already patched it to open the specific .so file, but for some reason it doesn't work <NieDzejkob>alextee[m]: does the library try to load other libraries in the same directory? <alextee[m]>is the rpath the equivalent of LD_LIBRARY_PATH ? <NieDzejkob>alextee[m]: yeah, the linker uses rpath, LD_LIBRARY_PATH, and runpath to try to find libraries <NieDzejkob>I don't recall whether it starts at the start or end of that list :P <alextee[m]>it looks like it gets substituted correctly, and i can ls that file ^, bnut when i run this it still jumps to [ERROR] Cannot Open libzest" for some reason <NieDzejkob>alextee[m]: the code suggests it should print dlerror(), what does it output? <alextee[m]>NieDzejkob: it doesn't go there for some reason. am i running windows? <alextee[m]>[1] 7630 segmentation fault /gnu/store/75vvgynjvmlplgncwlq7sj59cpj839sn-zynfusion-3.0.5/bin/zynfusion <NieDzejkob>alextee[m]: run strings on the library. Is the path to libzest.so in there? <NieDzejkob>weirdly enough, the logs suggest it's trying libzest.so without a path, then /opt <alextee[m]>yeah /opt is the next choice after the handle cannot be obtained <NieDzejkob>but it should be trying the /gnu/store path before <alextee[m]>"strings /gnu/store/75vvgynjvmlplgncwlq7sj59cpj839sn-zynfusion-3.0.5/bin/zynfusion | grep libzest" returns nothing <NieDzejkob>hmm, grep for other mentions of libzest.so in the source code <NieDzejkob>alextee[m]: wait, *absolutely nothing*? It should have the name of the library itself... <NieDzejkob>ah, the jack thing is probably because it's trying to uninitialize jack before initializing it <alextee[m]>the only mentions of libzest.so are those lines between 60ish to 80ish <mbakke>civodul: any thoughts on merging the GRUB localisation work mentioned above? <rndd>hi everyone! i encountered an error after installing virt-manager "cannot connect to virtlogd: failed to connect soccket to /var/run/libvirt/virtlogd-sock: no such file or directory" and didn't find solution. Does anybody know a way out of this? <rekado>rndd: are you using Guix System? <rekado>Guix System has a service for virt-manager that you should enable. <rndd>rekado: do i need append (service virt-manager) to %desktop-services ? <rndd>rekado: there is an error "In procedure service-type-default-value: Wrong type argument: #<package virt-manager@2.2.1 gnu/packages/virtualization.scm:585 7f06a72910a0>" <apteryx>do we still put things based on their function, or is the language world they belong to the main factor now? <apteryx>e.g., pondering whether python-cantools should go to networking.scm vs python-xyz.scm. <rekado>that’s because (service virt-manager) is wrong *rekado looks at the manual <rndd>rekado: oh, i see. now it buids. will give a look at manual. thank you. <alextee[m]>is there a reason that gnome builder is not packaged, other than nobody bothered? <rekado>another possible reason could be difficulty <rekado>“serious” sounds … serious. But I don’t see how ongoing work to package optional GNOME packages is a serious bug. <rekado>dutchie: submitting this upstream could help <civodul>i would mark it as "normal" or even "wishlist" <rekado>dutchie: if you do please also note this for 40388 <raghavgururajan>rekado You are right. That should not be marked serious. I may have used wrong bug number. <ngz>I have a packaging question. I packaged a set of two Emacs themes using Github repository. Now, upstream also released their two themes separately in ELPA. What is the best way forward? Keep updating set from Github? Package both themes from ELPA and deprecate Github source? <rekado>raghavgururajan: if there’s still open work then don’t close it <rekado>it’s good to keep track of progress <rekado>but maybe it’s better to have issues with slightly smaller scope <rekado>they are usually more actionable <civodul>rekado: i think so, i don't feel a need for the proposed change <rekado>civodul: I also think it’s fine the way it is. <rekado>raghavgururajan: if it’s a bug or missing feature in Guix I think it should still be left open; you can become the owner of that issue, though. <rekado>then it’s officially assigned to you <alextee[m]>our glib is old? latest gnome builder can't build because Dependency glib-2.0 found: NO found '2.60.6' but need: '>= 2.61.2' <nckx>Or update [a copy of] glib? *alextee[m] is too scared to do that - feels like building a kernel <rekado>alextee[m]: try not the latest gnome builder but one that matches our version of gnome <rekado>our version of gnome is a bit behind precisely because upgrading glib is a world-rebuilding change. <rekado>gnome upgrades are unfortunately pretty painful *raghavgururajan has no idea what 'seg fault' is. <rekado>raghavgururajan: “segmentation fault” <rekado>it means that the program tried to access memory that it may not access <rekado>this happens, for example, when a program tries to access 0x0 <rekado>and that often happens because somewhere it failed to access a library but didn’t check for errors <rekado>or because it uses an incompatible version of a library <rekado>you can often produce segfaults when you force applications to load incompatible libraries <rekado>that’s one of the reasons why LD_LIBRARY_PATH is a dangerous variable to set because it makes the application look up libraries that might not be ABI compatible. <rekado>on foreign distros this can also happen when XDG_* variables are set causing a foreign application to load plugins or extensions that were built with Guix . <nckx>ngz: Could you take a look at John Soo's mail on guix-devel@? Let's find out what happened here. <nckx>ngz: Ah, I just CC'd you. The one about ‘Mistaken authorship on some commits’. <ngz>Ah yes. I made a mistake on two commits. <nckx>Not a disaster but would be nice to find out what happened and how to avoid it. <ngz>It's simple. I had to apply manually all their patches. So I changed the "=A" flag in Magit, and apparently, I forgot to clear it. <ngz>3? I'm only aware of "emacs-spacemacs-theme" and "emacs-all-the-icons". <ngz>Oh, right, there is also "emacs-graphviz-dot-mode". <ngz>As a side note, I have not seen any new mail from guix-devel since January, 8th. oO; <nckx>All right 🙂 Magit explains a lot. Next time do send a quick heads-up to guix-devel@ (and in this case the ‘author’) when you discover it yourself. <nckx>ngz: That's strange. You're not listed as a subscriber, that's probably why. <nckx>Did you get any bounce warnings? <nckx>Try resubscribing I guess. <nckx>(I only searched for m@ng.fr.) <ngz>It may be more a Gnus' config issue. I have to look into it. <ngz>Ah. I was reading the list through Gwene. <nckx>‘Gwene is an RSS (and Atom, etc) to Usenet News (i. e., NNTP) gateway.’ <ngz>You could read mailing lists without subscribing to them. Now, it's not active anymore. Probably since January, 8th. <nckx>I thought that was Gmane, but I also heard something about it being shut down. That was ages ago though. Doesn't matter, I'm always confused. <ngz>Gmane is still active <ngz>Oh. Wait. I meant Gmane not Gwene... <nckx>I've never used it but it's always sad to hear of these classics shutting down. <nckx>And indeed, they briefly did in 2016 but then came back up. <raghavgururajan>rekado Thank you! So is there a possibility that a seg fault happening in foreign distro, will not happen in guix system? <nckx>That I (or anyone else) cannot say. <nckx>Not without actually solving the bug. <nckx>I'd take that upstream patch, take a look at the file it patches. If it hasn't changed significantly, create a copy of it, insert that hunk of code manually, then diff your new copy with the old one to generate a patch that will work in (patches (search-patches …)). <nckx>That patch wouldn't prevent a SEGV, though. <civodul>did you know? a Git tag can point directly to a "commit" object instead of a "tag" o_O <rndd>hi everyone! there is another small question. when i install different programs with gui there is usually no icons on buttons. this usually happens with gnome-aps. did i miss any package? <nckx>raghavgururajan: *But* it might enable better error logging before dying. That depends on the rest of the code. <nckx>I'd say don't waste too much time on it if you're not comfy with C. It's not the fix in any case. <nckx>raghavgururajan: That *could* be a SEGV fix. Almost every C patch *could* be a SEGV patch. They never look like ‘- trigger_segv() /* this might not be needed */’ 😉 <nckx>In practice these are subtle errors and so are the fixes. <nckx>Without tracing or debugging it's almost impossible to find out which patch might fix it. <nckx>Oh, replacing .diff with .patch in the URL at least produces a commit message. That's something. But it's not a very informative one 🤷 <raghavgururajan>>nckx: raghavgururajan: That *could* be a SEGV fix. Almost every C patch *could* be a SEGV patch. They never look like ‘- trigger_segv() /* this might not be needed */’ 😉 <anadon>What's with `npm` not being installable? <nckx>For this reason I'm not going to play the ‘could this hypothetically fix a hypothetical SEGV?’ with more patches. Yes, it could. It could introduce 6 new ones. It's not a productive question. <nckx>anadon: You tell us. What is up with that? <nckx>Did you type ‘npm’ (instead of ‘node’) here or also in your command? <nckx>If so, there's your answer, otherwise please paste(.debian.net) any errors you got while installing node. <lfam>As always, "What did you try and what happened? <anadon>So many tools and derivatives @_@ <nckx>‘What did you expect? The app work. What actually happened? The app no work’ <anadon>I assumed the tool referenced in the documentation I'm reading in another project was *the* tool. <anadon>I did not expect it to not exist in guix, and then have something which has the same functionality under a different name without some kind of notice. <nckx>But node.js does exist in Guix, as node…? <nckx>Node provides the npm command. <nckx>Even nmpjs.com says ‘npm is distributed with Node.js- which means that when you download Node.js, you automatically get npm installed on your computer’. <nckx>str1ngs: restarting app error please help <anadon>I'm dropping this for the time being. I don't want a fight. *str1ngs error: app failed successfully! <ok> <cancel> <nckx>anadon: If you're fighting your computer it's always time for a break 😊 <nckx>nckx: Are you sure you want to Cancel? <Cancel> <OK> <str1ngs>oh the ole swap the dialog buttons trick. <nckx>I might lose some geek cred but I do think it makes more sense. <str1ngs>you are thinking apple with minimze and close :P <Blackbeard>nckx: oh yes, that's the way GUI's outside Emacs communicate right? I've heard a few legends.. <nckx>And that is Correct and How Things Must Be and I will not compromise on that my friends. <str1ngs> why does warning have an exclamation ... jesh <str1ngs>there is like level of wrong with that dialog haha <nckx>Blackbeard: Indeed. It's not as user-friendly as C-M C-x C-M-x ok-mode RET but one copes. <nckx>But at least the buttons are in the right place! <nckx>Now I'm using Emacs GUI menu bar (which I never use) trying to make it pop up a graphical message window. <nckx>That will tell us what is right and true. <J[m]>Does Guix support the PineBook btw? :) <nckx>J[m]: I don't know the full answer but it's either ‘yes’ or ‘almost’. There are a few PineBook owners actively working on it. <lfam>J[m]: We definitely support the PineBook Pro. The PineBook is probably achievable if not already working <lfam>I see commits about u-boot for pinebook so that's promising <nckx>I think vagrantc is one of them…? <J[m]>nckx: lfam that's great! I have one on it's way. I am looking forward to use it 🙂 GuixSD is the strongest candidate! <lfam>Aweome J[m] :) Let us know how it goes <bricewge>rndd: You are probably missing `adwaita-icon-theme` <J[m]>lfam: I will 🙂 I'll probably get it in may <nckx>J[m]: \o/ Very happy to hear that. (GuixSD is dead; we go by Guix System now, just so you know.) <J[m]>@nckx Ah! Did not know that :) <drakonis>y'all arent gonna shake up that name so soon <Blackbeard>rndd: why don't you have gvfs in packages, and why don't you have (use-package-modules certs gnome) <nckx>Companies would kill for that kind of brand name retention. <bricewge>Blackbeard: He has `(use-modules (gnu packages certs))` and the gnome stuff comes from `(use-service-modules desktop ...)` <nckx>lfam: Then why recommend --format=full though? Did I miss something? <Blackbeard>liberdiko: 🤔 ahh didn't know desktop covered that. <rekado>anadon: perhaps we could mention npm in the description of the “node” package. <apteryx>seems it's not using my localhost machine <apteryx>which I'd expect it would instead of waiting for the fatser (but more loaded 127.0.0.1:6666) <nckx>apteryx: That's what you'd expect if the load was over (* speed 2). The connection failure is weird though. <apteryx>nckx: ah, yes, that's something else <rekado>it does offload to localhost, though <rekado>the only line that’s weird is: substitute: guix substitute: warning: 127.0.0.1: connection failed: Connection refused <nojr>which command will set up a pure dev environment on a foreign distro to add something to guix? <nojr>I'm trying to contribute a package <nojr>but I'm on a foreign distro <rekado>nojr: guix environment --pure guix <rekado>nojr: you’ll still need to clone the git repository and all that <nojr>guix environment --ad-hoc --container guile -- guile <rekado>nojr: this will just give you guile <rekado>Guix needs quite a bit more than just guile <rekado>with “guix environment guix” you get an environment to hack on Guix <nojr>Sometimes it is desirable to isolate the environment as much as <nojr>possible, for maximal purity and reproducibility. In particular, when <nojr>using Guix on a host distro that is not Guix System, it is desirable to <nojr>prevent access to ‘/usr/bin’ and other system-wide resources from the <nojr>development environment. For example, the following command spawns a <nojr>Guile REPL in a “container” where only the store and the current working <nojr>I know so will I have to guix environment --ad-hoc --container guix?? <apteryx>rekado: yeah it says it is offloading to localhost, but then it hangs there. <rekado>--ad-hoc is for packages you want to have in the environment <nojr>ok so guix environment --container guix? <rekado>without --ad-hoc you get the environment to build the target package. <nojr>rekado: yes, that's before right? <rekado>I already wrote before: guix environment --pure guix <rekado>but you can also do guix environment --container guix <nojr>they are the same thing? <rekado>“--container” uses user namespaces <rekado>“--pure” clears only environment variables, which is usually sufficient. <nojr>rekado: ok I will be clearer, when building guix you need guix environment --pure guix --ad-hoc coreutils findutils which <nckx>apteryx: Aren't you out of build slots (--max-jobs) on localhost? <nojr>but once built, I can just guix environment --pure guix <nckx>Guix will still respect --max-jobs=2 even if load isn't actually 2. <rekado>these are different commands with different effects <rekado>the former adds coreutils, findutils, and which to your environment <nckx>apteryx: …which is parallel-builds in machines.scm, by the way. <apteryx>I'm running with --max-jobs=4 locally <lfam>No, you didn't miss anything nckx. It's an old habit from before we signed commits <nckx>But the offloading Guix doesn't query the remote (let's use that word for convenience) for that, it uses its own parallel-builds value from machines.scm. <apteryx>nckx: that's gold. Now wondering if I didn't miss such information from the manual... <nckx>Parallel-builds limits how many jobs an offloader will even attempt to send to a node. If it's 2, it doesn't matter that the node is running with --max-jobs=88 internally. <nckx>I hope that makes sense. <nckx>It might not be in the manual. It wasn't really covered when I wrote that, which is why it exists. <nckx>lfam: That's a relief 🙂 Thanks. <lfam>nckx: It might still be useful in the absence of malicious activity, since it doesn't require a working PGP setup <rndd>Blackbeard: don't know do i need them? <apteryx>nckx: seems to work better now, thanks! <nckx>apteryx: Yay! Nice to know that my atrociously-written notes were of use to someone besides me 😊 <Blackbeard>Apparently not, did you install the icons package that was suggested ? <Blackbeard>rndd: You are probably missing `adwaita-icon-theme` <apteryx>nckx: I even pasted them in my own machines.scm <nckx>Please let me know if you notice discrepancies; that was written 5 years ago and I literally didn't even Scheme. <rndd>Blackbeard: ye, it solved problem, thanks for suggestion <Blackbeard>anyone has experience with perl? I am having this problem <Blackbeard>rekado: probably not, is that in the perl script or a .bash_profile thing? <Blackbeard>rekado: oh I fixed it! I needed to install perl-mozilla-ca <Blackbeard>how can I know what packages are required by a perl package <random-nick>hello, how does guix handle binaries looking for libraries at runtime? <str1ngs>random-nick: yes, but usually to do it right. it requires substituting or patching sources. <str1ngs>random-nick: does the program use dlopen or FFI? <str1ngs>I'm assuming this is what you meant by . libraries at runtime. <drakonis>the question that's to be answered is to get mpv to use vulkan as a renderer <Gooberpatrol66>The April 1 Hurd image freezes at "start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s2] exec" <FennecCode>So... I kinda hate to ask this, but is dropping support for Linux-Libre in the next release an April fools joke, or is it genuine? I really can't tell. It's not a bad move, but it's a big commitment. <civodul>Gooberpatrol66: did you use the QEMU command line given in the blog post? <nckx>FennecCode: That part's a joke. <lfam>Every good joke has an element of truth <Gooberpatrol66>guix environment --ad-hoc qemu -- qemu-system-i386 -enable-kvm -drive file=guix-hurd-20200401.img,cache=writeback -m 1G <FennecCode>Oh thank God. It'd be really cool if that were the case, but it'd severely limit my ability to run GuixSD. <FennecCode>Or maybe not. I admittidly know rather little about Hurd. <civodul>Gooberpatrol66: that should work (it works for me) <mbakke>Gooberpatrol66: are you member of the 'kvm' group? <teythoon>i packaged muchsync, it built fine, but i'd like to test it before i submit the patch <teythoon>and i cannot figure out how to do that :/ <teythoon>i was following chapter 14, contributing <rekado>teythoon: when you build something Guix will print the location <rekado>teythoon: then you could do /gnu/store/…-muchsync/bin/muchsync (or whatever) to run it. <teythoon>heh, i just did that, but felt like that was quite hacky <rekado>(I don’t know muchsync. If it needs more runtime configuration it’s not as simple, of course) <rekado>(installing is little more than linking the /gnu/store/…/ thing to some other location) <rekado>if you don’t like to see the /gnu/store/… file name you can do $(./pre-inst-env guix build muchsync)/bin/muchsync <rekado>but I don’t think that’s much better :) <teythoon>so you are saying that i should test it by running it from the store, and if i'm satisfied submit a patch? <Blackbeard>I did ./pre-inst-env scripts/mumi --worker and I got all the files 
