***sneek_ is now known as sneek
***atw` is now known as atw
<rndd>i'm getting this error "gcc: error trying to exec 'as': execvp: No such file or directory" when trying build my test program using trivial build system. i checked, as is presented in gcc-toolchain. and i included this package in inputs. maybe somebody had same issue <roptat>No such file or directory might mean that 'as' is not in $PATH (trivial-build-system doesn't set any I think), or that one of its dependencies is not found <rndd>roptat: oh, thank you =) <drakonis>hmm, what should i do about packages with dependencies on things like rust nightly? <the-catster2>I've been trying to setup EXWM to launch from GDM for the past many hours, and have made no progress. I installed minimal Guix originally, but later added the GDM service. I don't know if I'm supposed to add something to my main manifest, or if there is a package for the .desktop file, but I have had no luck in launching it. I have tried just from <the-catster2>xinit, where it works but I cannot pass in any keyboard input, or from a custom .desktop, but I don't think that was picked up. Is there documentation for this, or what is the recommended method? <MysteriousSilver>Hi! Tried using guix to manage third party elisp in emacs. I tried adding `~/.guix-profile/share/emacs/site-lisp` to load-path but emacs returns this error: http://ix.io/3n42 . How do i fix this? <irfus>command-line transforms + the new --export-manifest functionality is so great for a guile-learning non-programmer like me! Thank you all who worked on this! <MysteriousSilver>Hi! I ran `guix gc`, now why does guix reinstall stuff like curl, git, glibc, py etc when installing new packages? <eyJhb>MysteriousSilver: I difference of the channel the current profile is build on + the one that is active? <eyJhb>I would assume that. gc does not "often" remove too much, it only removes the stuff that isn't actice or does not have a gc root (I think it is called). At least that's what NixOS does, and I don't think they differ in that point. <leoprikler>gc removes stuff, that's not reference, which affects many native inputs ***apteryx_ is now known as apteryx
<leoprikler>For instance, git is often only used to download packages, so it can freely be collected. <eyJhb>leoprikler: but won't it still be in the store, as it most likely will be a dependency of some package somewhere? <eyJhb>Coming from NixOS, I don't think I can get rid of git even on a base install. <leoprikler>tbph I don't understand all of it either, at least libgit *should* be referenced somewhere ***iyzsong-- is now known as iyzsong-w
***ae is now known as Guest34159
<davidl>Hi, I have installed gnome-passwordsafe on a foreign distro and can't get the window buttons to show properly. I have followed the application setup instructions but it has not fixed it. What can I do to troubleshoot the issue? <davidl>Basically everything else works great, like I can run an xfce4-session etc, but some of the application buttons and the window buttons just won't show up. <cronopio>hi, i recently installed guix on a clean ubuntu install <cronopio>and i'm following this guide to set everything up <cronopio>i've tried installing it from guix, but it says no such package found <tissevert>cronopio: that's indeed what I understand from the resource you linked : «recommend that the system [hence, not Guix but the host distro] run […] nscd» <meo>i did exactly that on my ubuntu machine <cronopio>and just installing it will be enough to have it always running, or should i update some init script? <davidl>cronopia: there's a great guide in the guix blog archive on how to set it all up with autologin and everything for CentOS 7 <davidl>I imagine it will work for Ubuntu too <tissevert>that's a question to ask Ubuntu : ) but I bet it will (there are usually post-install hooks in .deb packages that enable services in the distro's init system, you can check it afterwards by checking in systemctl — I assume ubuntu uses systemd, right ?) <tissevert>it's called «systemctl is-enabled <name-of-the-unit>.service» <tissevert>so here I'd expect it to be systemctl is-enabled nscd.service <cronopio>you mean, i should type «systemctl is-enabled nscd.service» in a shell? <tissevert>if you want to check that the service was indeed enabled after its installation, yes : ) <cronopio>davidl: where can i find the guide about setting guix on CentOs 7? i'm unsure what the guix blog is <fnstudio>hi guix, i'd like to try and speed up the upgrade process by pinning texlive (2.6G) to its current version <fnstudio>the idea would be to still upgrade texlive but on a slightly less frequent basis <fnstudio>is there a recommended way of doing this? <cronopio>davidl: the guide begins with the command «sudo sed -i 's/root/alice/' /etc/systemd/system/guix-daemon.service», but being ubuntu, should i change 's/root/alice/' for '/home/alice/' ? (where alice is my user name, obvs) <tissevert>fnstudio: I don't know if that's exactly your use case but for «heavy» packages which latest version I don't always need, I install them «manually» with `guix package` instead of having them in my system's config.scm <tissevert>that way they're not a burden when upgrading, and I can guix weather before upgrading my user packages to check there is a substitute, or at least to get a rough estimate of what time it should take <davidl>cronopio: I don't understand why you would need to do that. You can just open /etc/systemd/system/guix-daemon.service and replace the word root with the word alice manually. <cronopio>ah, i was just following the guide as literally as possible <cronopio>but there's no 'root' word in my guix-daemon.service file <davidl>cronopio: ok, well, regardless of what name was in there before, make sure your user's name is in there on whatever line you think root was on before. <davidl>maybe you can paste the content of guix-daemon.service on paste.debian.org and paste the link to it here? <fnstudio>tissevert: that's great, thanks; i suppose guix pull / guix package --upgrade silently look for a default config.scm (i'm on a foreign distro btw) <fnstudio>tissevert: anyway, that was a very good hint already, i think i can do some web search on that basis <apteryx>are macro error messages not translatable, due to gettext being a procedure rather than a syntax? <tissevert>fnstudio: no, guix pull doesn't depend on any configuration, it's simply the state of the packages as guix know them (<-> apt-get update <-> pacman -Sy) <tissevert>guix package can act on individual packages but also on a manifest, which is what I'm using (so it looks like «part of a whole system config») <fnstudio>tissevert: ah right... so it's when you use guix package that you feed it with a particular manifest/config? <cronopio>also, the guide mentions editing my ~/.bash_profile, but i just have ~/.profile and ~/.bashrc <cronopio>should i edit .profile or create .bash_profile? <tissevert>yeah, very simply I created a git repos where I put a file config.scm for my whole system and user-packages.scm which is only a manifest <tissevert>and, when I feel like it's time to update the system I `sudo guix system reconfigure config.scm` <tissevert>then, from time to time, if I'm curious about a new version on chromium or libreoffice (the two big shots for which I'm doing this, but my manifest also contains my dirty local packages that aren't ready / relevant to share), I `guix weather -m user-packages.scm --display-missing` <tissevert>and if the output shows chromium and libreoffice have substitute, then I upgrade <fnstudio>tissevert: cool, very interesting (any chance that repo is publicly available, if i may ask, or maybe any similar solution that you took inspiration from?) <tissevert>the real repos I'm talking about is public, but it's published at the lab where I work under my legal name which I do not intend to link with my online identity (and I've seen user-packages.scm hasn't been committed yet, shame on me) <tissevert>so anyway there wouldn't be much additional value if you already know what a config.scm is supposed to look like <fnstudio>tissevert: that makes perfect sense, no prob, that's already of great help <tissevert>as for the manifest, it's simply the output of guix package --export-manifest <fnstudio>tissevert: this will make my upgrading process much better and less painful, thanks <fnstudio>oh i see what you meant, excellent, this also helps <- tissevert <roptat>Ikosit, that's an issue in the description of ghc-vty, but that package comes from ikop, not the official guix repo, so we can't do anything about that <roptat>you should report the issue to whoever provides the package *Ikosit notes that he reports an issue to himself :P <roptat>did you use @ikop or something like that in the description? <Ikosit>The package was probably autogenerated with guix import <Ikosit>yes there is a @vty@ and a @vty-examples@ <roptat>if you want to keep the @, replace them with @@ <roptat>the description accepts texinfo syntax, so @vty is understood as a texinfo markup <fakhri>I get this warning when I do reconfigure <fakhri>guix system: warning: while talking to shepherd: No such file or directory <fakhri>so when I run herd status, I get this error: <fakhri>error: connect: /var/run/shepherd/socket: No such file or directory <fakhri>do you have any idea, how can I fix it? <mbakke>fakhri: did you use 'sudo' with guix system reconfigure? does 'sudo herd status' work? <apteryx>civodul: Hello! It seems Makefile.am:716: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS gets printed everytime one touches the guix.texi manual; perhaps recursive make to avoid this warning is not that bad after all? <roptat>fakhri, I would reboot, something's wrong with the shepherd on your system (I mean it should still be running or you'd have gotten a kernel panic, but its socket disappeared) <djames>Looks like my fresh install of Guix hangs at Grub -.- <fakhri>I did reset and reconfigure several times, still the same situation! yes, it's just a warning in reconfigure but after that nothing work! I get an error for the herd status command <apteryx>fakhri: I think I've had that once. Perhaps a reboot could fix it, as roptat suggested? <MysteriousSilver>Hi! Installing a 500kb binary package took like 7mins on a 5yr old hardware, is this expected? Running guix on a non-guix GNU/Linux distro. <djames>I tried installing from the current ISO and this install hangs at Grub too <apteryx>MysteriousSilver: do you have many packages already installed? The cost of creating a new profile increases a lot when the profile is big. <apteryx>you can compare with 'guix environment --ad-hoc your-package' <apteryx>MysteriousSilver: not big, but not small either, I'd say. <lfam>MysteriousSilver: I'm curious, does your computer use an SSD? Or a spinning hard drive? Some other kind of storage? <lfam>apteryx: I'd like to attempt an ungrafting branch starting today. Does that sound alright? <lfam>MysteriousSilver: That command creates an "ad-hoc" profile that contains only your-package. <lfam>It's a handy way to "install" things momentarily, without worrying about the history of your profile generations growing larger for things that you might not want a history for <lfam>The HDD will probably make things slow :( <lfam>Doing "profile operations" on Guix is really I/O intensive. That means that installing and removing things is slower on an HDD <lfam>That question I asked apteryx about "ungrafting" will improve the situation somewhat, but it won't happen for a week or so <lfam>What didn't you understand, MysteriousSilver? <lfam>Do you understand what a "profile" is, in Guix? <lfam>So, if you did `guix install foo`, Guix would create a new generation of your default profile that added the foo package <lfam>Then, when you did `guix package --list-generations`, that new profile would be listed. <lfam>"--ad-hoc" is for when you want to install foo, but you don't want to create a new generation of your profile. The command creates an ephemeral profile that won't be listed in your generations <lfam>It's handy for testing, or just when you know you'll only use foo right now, and don't want to be able to roll-back the generation that includes it <lfam>It won't exist on your $PATH <lfam>`guix environment` works by changing the environment variables of your current shell. So when you start a new shell, the effects of `guix environment` are wiped away <lfam>I recommend doing `env | grep $PATH` before and after running `guix environment --ad-hoc hello` to see what it's doing <lfam>It uses other variables besides $PATH, but that is the main one <lfam>Anyways, apteryx suggested that command as a way to test the speed of installing a single package <lfam>You might also poke around a little bit in ~/.guix-profile, and /var/guix/profiles/per-user/MysteriousSilver, to see how profiles work. They are a "symlink forests" <lfam>Once you really grok that, then `guix environment` starts to make more sense <djames>It appears my issue was with the disk encryption that the installer configures. I installed a non-encrypted install and it works fine. <lfam>It should be illuminating! And feel free to ask questions here too <apteryx>lfam: although, perhaps it'd be better to do the graft work on staging and merge that when it's done? It must be due. <lfam>I think that grafting can be done more quickly than a "real" branch like staging <lfam>I want to remove the performance penalties of the grafts quickly, and I think we can ungraft more frequently than we could in the past. We always intended to do it biweekly or maybe monthly <apteryx>yeah, it's more focused. makes sense <lfam>Anyways, I probably can't help with staging soon. If people take up the cause, and it's convenient, we can put the two branches together :) <apteryx>anyone knows how to use the Cuirass search fature? I tried with "spec:staging status:failed system:x86_64-linux" but it returns "No elements here" <apteryx>also, there's a burger menu that doesn't do anything for me when I click on it <lfam>spec:staging returns nothing at all <lfam>The search has always been unreliable for me <lfam>Sometimes it works, sometimes it doesn't, I don't know what affects that <lfam>The burger menus on the home page offer me "edit" and "delete" options <roptat>apteryx, you need at least a search term in addition to tags <apteryx>can search terms be 'all' ? or .* or something equivalent? <roptat>I don't think there's a good reason to require a search term <drakonis>its a proglang that's required for some specific fields <roptat>drakonis, I have a package for scala2 <roptat>unfortunately, it's not bootstrapped, but at some point I think we have to give up and package a binary... <roptat>at least, it gets the binary and rebuilds from source <hwpplayer1>You need developers to compilere from source if it is available <drakonis>also, i'm curious about being able to use rust nightly, i need it because a python package requires rust nightly <roptat>hwpplayer1, I've been trying to bootstrap scala since 2018... <roptat>hwpplayer1, all you need is get the source code, do the changes you want and submit patches to guix-patches@gnu.org <roptat>you might want to follow the Contributing section in the manual to get started :) <hwpplayer1>I am gonna install the system to Acer Aspire V3 772G <roptat>drakonis, I don't know too much about rust, but if that nightly from before last version, then you can use the current rust instead, otherwise maybe package a recent commit from their repo? <roptat>have you tried using the last version of rust we have in Guix? <drakonis>it needs a flag that is only available on nightly <roptat>I see, then no choice but to package from a recent commit <roptat>I see 27.2 from "guix show emacs" <drakonis>i mean that its a flag that only works on nightly builds, it isnt provided if you're not in the nightly channel <roptat>depends what you want to update. for your user profile, no sudo required <drakonis>gonna try and build the python package real quick to check it <apteryx>is anyone having problems building disarchive 0.2.1? I have this derivation that fails; it's pulled by my operating-system declaration, and is *not* the same derivation as that of disarchive on master (not sure why that is) <apteryx>/gnu/store/sd3vncanhfff7fr8gmjdg5rcy6rk9qnw-disarchive-0.2.1.drv <roptat>that's "guix pull" to get the latest guix and guix recipes, and "guix upgrade" to update your user profile <drakonis>"error: the option `Z` is only accepted on the nightly compiler" <roptat>hwpplayer1, what is written with Scheme? <roptat>ah guix? It's written in Guile, a Scheme implementation, except for the daemon that's still C++ (it's a very small part though, and we plan to rewrite it at some point) <drakonis>but oh boy it will be a fine day when it does finish complete <apteryx>ah,the referrer of the above disarchive derivation is: /gnu/store/d7hap9ra4pacrbf0bq27p1awm3g41bzd-guix-1.3.0-1.771b866.drv. <apteryx>I think that's the Guix built from the childhurd VM <apteryx>so in other words, adding disarchive to Guix broke Guix on the Hurd <roptat>drakonis, no, it's on my other computer, I'll send it when I can access it in a few hours <roptat>although it's technological preview :) <roptat>you can run a childhurd, that is a hurd VM running the Guix System on any Linux system <roptat>I don't know if anyone has already tried installing a Hurd Guix System on real hardware <roptat>guix provides the linux-libre kernel <leoprikler>I think most everyone here uses the linux-libre kernel on some machine at least. <leoprikler>remmina has recently been packaged by raghav IIRC <roptat>drakonis, also, I'll try to create a package for scala3 (it's the same bootstrapping issue, only worse) <roptat>so I'll just use the same approach, get the binary, and rebuild the source with it <roptat>I'm afraid I won't be able to bootstrap it <apteryx>civodul: are you able to build disarchive for the Hurd? <roptat>although someone made a parser in OCaml, which is a part I couldn't even do properly before, so there's some hope <leoprikler>for me personally, not having scala sucks, because certain courses at uni require it <roptat>there's some comments with the "crazy:" tag :D <drakonis>roptat: perhaps there should be a place for these definitions that dont quite match the standards <roptat>drakonis, maybe... we already have a few packages that don't match the standard though <roptat>OCaml, nim, probably a few others <drakonis>kinda like debian's main/contrib/nonfree split? <drakonis>but that'd probably incur a big organization overhead <roptat>I'd like to at least be able to mark them as not being bootstrapped <roptat>mh, scala3 needs a few more packages than what we have <roptat>so I can create a package for the binary, but I can't easily rebuild it <lfam>I wonder if we need to have so many versions of postgres that aren't used anywhere <lfam>IIUC, 9 and 11 are not used <lfam>Right, and 10 is also used in Guix <lfam>Just to boil the oceans a little more? :) <lfam>There are costs, so there should be a demonstrated benefit to justify it <lfam>For example, somebody could say, "Wait! I'm using it" <lfam>That's a good enough reason <lfam>We don't have version 12; there's no policy promising that we'll offer every version <lfam>Or maybe there is an unstated policy :) This is why I'm asking <apteryx>lfam: You could propose reducing the carried versions in a patch and have it on display 2 weeks on guix-patches; and if nobody opposes that's a good sign that nobody has stake in keeping them <lfam>You can also do it "manually" by following the instructions in Binary Installation. It's trivial if you are comfortable with the command line <terpri>or that, a bit easier to remember :) <hwpplayer1>I can install via terminal but I could not be able to fetch install script <civodul>apteryx: i don't know, but i'm not even sure we can go this far on the Hurd, can we? <lfam>hwpplyayer1: My point was that you don't need the install script. <lfam>It's easy to install Guix manually <lfam>You can also do it "manually" by following the instructions in Binary Installation. <civodul>apteryx: yay that involves building lots of things, prolly more than we can "safely" build on GNU/Hurd <apteryx>civodul: well, we could build Guix on Hurd before disarchiver at least, and disarchiver doesn't have much inputs at all <apteryx>or perhaps I'm confused; how is the Guix that runs in the childhurd VM built? by cross compilation? <apteryx>I'm guessing so; so probably disarchiver needs the same --target=$host_alias fix that Chris had found for guile-lib <apteryx>hwpplayer1: the automated version would be something like 'yes | sudo ./install.sh' (after fetching the script from guix.gnu.org/install.sh and chmod +x it. <apteryx>you can use wget to fetch the retreive from a terminal emulator <roptat>hwpplayer1, are you installing Guix as a package manager, or as the distro? <roptat>ah, then there's no script to run <roptat>the installer (ISO) should give you the option to use a graphical (well tty) installer on tty1 <apteryx>civodul: for me building with a childhurd VM zstd-1.4.4 fails <apteryx>seems to fail on a test named: test : should quietly not remove non-regular file <civodul>apteryx: the Guix in the VM is cross built, yes <civodul>apteryx: native compilation on the Hurd is in flux until we figure out how to get isolated build environments <roptat>when? do you get an error message? <hwpplayer1>ERROR: The certificate of ‘git.savannah.gnu.org’ is not trusted. <hwpplayer1>ERROR: The certificate of ‘git.savannah.gnu.org’ is not yet activated. <roptat>when is that, after generating a config.scm? <nckx>Does running ‘date’ return something correct? <roptat>are you running the installer ISO, or you interesting in installing the package manager on your existing distro? <terpri>hwpplayer1, guix-install.sh is not what you want if you want to run Guix System, i.e. as a full distro <apteryx>civodul: OK! So the problem is that disarchiver does not currently cross-compile; this breaks the hurd-vm-service-type service on master <nckx>Yep. With date --set=STRING. <nckx>...this is in the installer...? Never mind... <nckx>See above, but you're heading down a bad road and I recommend you turn back. <roptat>hwpplayer1, are you running the installer ISO? <roptat>in case you didn't see, are you running the installer ISO? <nckx>hwpplayer1: (guix-)install.sh is for installing Guix as a package manager on an existing installation of a ‘foreign’ distribution. It cannot directly install the Guix System. That's a totally different process, automated by the ‘installer’ that should start when you boot the installation ISO. <hwpplayer1>could you please send the distribution install script https address again ? <nckx>hwpplayer1: It is *not* a _distribution_ install script; there's no such thing. <apteryx>civodul: what specifies the requirement for cross-building Hurd components for the Hurd VM image? <rekado>hwpplayer1: but you probably want the iso, which includes the guided installer <roptat>hwpplayer1, it's not a script, it's an ISO that contains a system you must boot, in order to install the Guix System on your machine <hwpplayer1>install.sh or the .iso ? to install whole GUIX distro ? <nckx>Did you boot it, hwpplayer1? <nckx>Were you not greeted by a blue background with a vaguely GUI-like text window? <farkr>is it okay to put "sh ~/.guix-profile/etc/profile" in ~/.bashrc? <nckx>That should guide you through the installation. <terpri>farkr, i don't know, but it'd have to be "." not "sh" (otherwise the variables wouldn't be set in the *running* shell) <rekado>aside from that: put it in .bash_profile <civodul>apteryx: what do you mean by requirements? it's a "standard" cross build from Guix' viewpoint <rekado>.bashrc is for initializations for *every* shell, including sub-shells <nckx>farkr: It's not a good idea. .profile and .bashrc are different things, and you'll run into subtle (and not so subtle) bugs if non-login shells, that shouldn't source your profile, do. <rekado>farkr: this means that you’d break “guix environment”, which spawns a sub-shell. <apteryx>civodul: OK, then I need to educate myself on how Guix handles cross-building generally. Thank you. <civodul>apteryx: the cross toolchain is mostly defined in cross-base.scm <nckx>If you are running this from the booted installer ISO, what you are doing now makes no sense & will never work, but you've been warned enough. <hwpplayer1>I am watching the main page's video not an unofficial video like on Youtube etc <roptat>that video is for installing guix on a foreign distro <lfam>I would use the words "full operating system" instead of "distribution". <lfam>This use of "distribution" is very jargon-y and is hard for newcomers to understand <nckx>I agree, but it's muscle memory at this point. <farkr>so is it alright if I consistently source my guix profile through .bash_profile then? <nckx>That's basically what guix-install.sh does, except it drops a snippet into /etc/profile.d which most distributions support, and applies the change for all users. <terpri>GuixOS or something instead of Guix System would clarify it, but i don't want to paint that bikeshed <terpri>i find it hard to imagine the kind of user who would be installing guix themselves not to know the concept of a gnu/linux distribution <nckx>GuixOS likely ain't ever happening. <lfam>terpri: I think that case is occuring as we speak :) <nckx>(GNU being the OS & all, and just the sheer depth of muck we'd be wading into.) <lfam>And I don't know how this word translates into languages besides English. "Distribution" is not idiomatic English <terpri>and GNU Guix GNU/Linux doesn't exactly roll off the tongue :p <rekado>lfam: “distribution” reminds me of “[distribution of a] collection [of software]” and that in itself is hardly sufficient to distinguish “Guix” from “Guix System”. <rekado>“distribution” is such an inexact word. <nckx>And technically (...oh dear), you're installing ‘Guix the software distribution’ on a foreign distro, not just ‘Guix the package manager’. <nckx>I don't get the ‘Guix System’ hate. It's really a very, very good name for the job. <lfam>People will always complain about names <lfam>Handle it the same you'd handle them complaining about your given name. "It's our name; please respect it" <djames>Does anyone else here have issues installing an encrypted Guix install? I've tried both manually installing and doing the "graphical" installer. When doing an unencrypted install the OS boots fine. <terpri>i don't hate it (and obviously use it), but i think it's unidiomatic for a gnu/$foo distribution (i even preferred GuixSD since it's reminiscent of FooBSD, and obviously distinct from running it on a foreign distro) <terpri>it reminds me of apple's old System $n$ convention, actually <nckx>This is the Internet, you hate it or you love it but what we won't tolerate is nuance. <terpri>the OS was just called "System" (maybe "Macintosh System", it's been a while :p) <terpri>i should clarify that by "old", i mean back in the 90s when their machines were 68ks with (e.g.) 8MiB RAM and half-gigabyte hard disks *nckx 's no fan but if your *branding* is what reminds people of Apple you're doing at least something right. <nckx>In unrelated unnews, I'm still constantly hitting C-PgUp on my Linux console to no effect. The future is weird and scary. Time to try out kmscon. Is anyone actually using it as a daily console? *terpri wonders what happened to the League for Programming Freedom (iirc formed in response to apple's "look and feel" lawsuits) <terpri>huh, apparently it survived until at least 2010 <terpri>nckx, i noticed that too, but never found a solution, not that i looked very hard <nckx>Hum, I thought I'd never heard of them, but "Burn all GIFs" tickles a very dim memory. <merazi>Hello Guix! :-) How's everyone doing? <nckx>The only solutions are (a) to send Linus a friendly mail volunteering to rewrite and maintain a frankly revolting kernel subsystem (b) to switch to a userspace console. Maybe this will finally speed up the glacial development of the latter. <merazi>I'm still closing hexchat by accident lol <nckx>Greetings, fellow human of impeccable IRC client taste. <apteryx>civodul: I think my questioning about cross-compiling is this: usually, attempting cross-compilation of a package is requested manually via the --target option; what and where in the case of the Hurd VM images specifies that the target should be i586-gnu? <merazi>(this time it was not by accident, I swear) <vivien_>Hi, there was recently an update from guile 3.0.2 to 3.0.7 and suddenly my code starts to SIGSEGV half of the time inside libguile :( <vivien_>I guess I’m doing things wrong with the garbage collector, but this is so frustrating <civodul>apteryx: the new image API allows you to define the image's cross-compilation target, and that's what (gnu system images hurd) does <civodul>and "guix image -t hurd" or something <apteryx>about the disarchiver problem, I've added guile-3.0 to native inputs along guile-grypt. Now it bugs on a test to guess O_NOFOLLOW <civodul>actually what's the "disarchive problem"? i think i missed that :-) <nckx>Hm, kmscon's default action when invoked as ‘kmscon’ on a VT is to make your machine unusable. <apteryx>civodul: it fails to cross-compile for i586-gnu <nckx>It fails to exec /bin/login and respawns ad infinitum. <apteryx>civodul: which breaks thi childhurd service <civodul>so yeah, i guess it's missing a bunch of native inputs? <apteryx>guile + guile-gcrypt, and then the configure.ac needs to be massaged a bit it seems <apteryx>to avoid: configure: error: cannot run test program while cross compiling <civodul>maybe you could (1) remove the disarchive dependency from 'guix' when 'hurd-target?' returns true <civodul>and (2) let Timothy know about the other issues :-) <civodul>coz it could be that Disarchive's makefiles don't pass --target to 'guild compile', no? <apteryx>civodul: I think it comes from AC_RUN_IFELSE, it has a 4th arg to do something in case of cross-compilation (defaults to AC_MSG_FAILURE) <apteryx>civodul: yeah that would be visible at run time I guess <apteryx>any clue what a reasonable pessimistic value for O_NOFOLLOW might be in a cross-compilation setting? <civodul>apteryx: it should use AC_CHECK_INT instead, which works when cross-compiling <apteryx>AC_COMPUTE_INT looks promising, thanks <hwpplayer1>Do you think that system install tool is broken ? <pineapples>Not to break the peace and detract your attention from more pressing quandaries, but would someone be willing to do homework for me by showing how to extend `/etc/pam.d/login' by a `*.so' module from `/gnu/store/linux-pam/lib/security'? :') <pineapples>leoprikler: Do you mean `pam-service'? I have only been successful in adding a new file entry to `/etc/pam.d' but this is not what I want <apteryx>civodul: hmm, is there requirement to use that macro? I got: configure.ac:55: error: possibly undefined macro: AC_COMPUTE_INT <leoprikler>No, I mean pam-root-service-type. You can ask it to extend existing services. <pineapples>leoprikler: Ah. I was eye-balling this `pam-root-service-type', but I concluded that it couldn't be used on its own by declaring it in my `(operating-system)'s `(service)' field <pineapples>I thought I'd have needed to write my own service definition to then extend `/etc/pam.d/login' using that `pam-root-service-type' <pineapples>It seems that I'm wrong, and I'll need to write my own service definition for this <civodul>apteryx: weird, AC_COMPUTE_INT has been part of Autoconf for some time <civodul>perhaps the real error is elsewhere? <drakonis>civodul: is there any write-up on why guix was created in the first place? <vivien_>Haaa, that must be it! My code started to break because of the garbage collection of mpz_t values after an upgrade from 3.0.2 to 3.0.7, maybe that’s because of the GMP change <jackhill>yay for an opperunity to fix a mistake I suppose :)