<suitsmeveryfine>pizzaiolo: linux-libre-4.5 seems to be working fine on the desktop computer. <suitsmeveryfine>pizzaiolo: I don't know if it's been slowed down though, because the computer is pretty fast (C2D 3 Ghz with a fast SSD) <pizzaiolo>could it be an issue with your kernel and the SSD perhaps? <suitsmeveryfine>I can't figure out how to downgrade linux-libre so I guess that I'll just roll back and wait for an upstream fix of 4.5. <lfam_>Is git too expensive to update on the master branch? Security vulns in git < 2.7.1 were disclosed today <lfam_>Can somebody handle this? I checked that git and git-manpages build, but I have to go now. I can't do any more checking for a few hours <lfam_>We should also make sure that our Savannah repo gets updated <mark_weaver>lfam_: bah, thanks for bringing this to my attention <lfam_>I have a few minutes after all. I'm going to push the update. It can be reverted if necessary <mark_weaver>I've alerted the FSF sysadmins for the sake of savannah <lfam_>I wish there was a little more information available (or *any* info from the git maintainers <mark_weaver>I'm updating on my own machines independently, so that I won't have to use the flawed git to get the update :) <mark_weaver>I get 1di96q86fq3pdn5d5v4fw9vf58gha5i9b3r880mxlh275n8ngi49 on the .tar.xz <lfam_>I can't confirm the CVE IDs. Should I include them in the commit message? <lfam_>I get 1di96q86fq3pdn5d5v4fw9vf58gha5i9b3r880mxlh275n8ngi49 for git <lfam_>I get 0va9j0q9h44jqih38h4cmhvbmjppqq7zbiq70220m7hsqqkq824z for the manpages <lfam_>We should probably use some sort of authenticated communication method for confirming these things in the future... <lfam_>mark_weaver: I can't find any authority to confirm the CVE IDs. Should I include them in the commit message? <lfam_>Some distros are using them (Debian, Red Hat) <mark_weaver>lfam_: the most important thing is to push the update soon. if you can find a good source on the CVEs, include them, otherwise just say: [with security fixes] <mark_weaver>lfam_: I get the same hash as you for the git-manpages <lfam_>Okay, since my first source is somebody I don't know on oss-sec, and the distros are getting their info from ???, I will just say "security fixes" <suitsmeveryfine>mark_weaver: I've rebooted the computer a few times. Did you perhaps answer my question above? <rain1>is anyone interested in baresip on guix? I wrote 99% of a package definition, can't complete it <jesaispas>suitsmeveryfine, it's a slasher movie : ) Better than horror movies <rain1>jesaispas, or worse .. for some :) <jesaispas>rain1, yep, for people whom has bad tastes XD <jesaispas>suitsmeveryfine, if you like "gore" movies and funny movies, watch Scream and Friday 13th, but mainly Scream. <jesaispas>hahaha. Watch Scream, it's as funny as scary movie in his way. <jesaispas>not in these movies, really. It is a caricature in fact. <jesaispas>suitsmeveryfine, just watch it with a girl...: D <jesaispas>then, Attack of the killing tomatoes, something like that X) <suitsmeveryfine>There are so many movivies that I want to see. I haven't even seen Blade Runner for example. <jesaispas>but these last days i watched rocky I to V and expandables <jesaispas>i love movies from 70's until 90's. Since 21 century i think that we did shits... <suitsmeveryfine>No, I haven't seen that. I'll reboot now, hopefully into a different kernel. Bye! <Jookia>Someone with a J in their name? Woo <Jookia>iyzsong: Ludovic has spoken and it looks like we'll need to figure out a way to find all packages that specify both gdk-pixbuf and gdk-pixbuf+svg indirectly/directly and fix them to use just one :| <iyzsong>Jookia: let's see, but I still think the problem are from libtool archives. <iyzsong>jesaispas: yes, I only have 1 laptop <Jookia>iyzsong: I'll be replying in a moment, just one more email to figure out <iyzsong>jesaispas: for work, I'll use what employer provides, but I haven't a job now :-( <kristofer>is it normal that when I remove a package (guix package -r) for guix to rebuild perl? <mark_weaver>I guess you did a GC since the last time you built that profile <mark_weaver>which would have removed the original buggy perl, but now you (temporarily) need it again because of the way grafting works. <mark_weaver>grafting needs to first download or build everything that's needed without grafts, use that to find the set of runtime references, and then create new versions with references to buggy things replaced with the fixed versions. <mik_>is anyone using iwlwifi? <mik_>been trying to get it packaged up myself; some hours later I've been unsuccessful <Jookia>mik_: You'd have to package the firmware and another linux kernel that isn't linux-libre <mik_>ah, is it blacklisted or something? I'm not incredibly familiar with the process <Jookia>linux-libre won't load nonfree firmware <mik_>gah, I don't even know where to begin with that <Jookia>mik_: Package the normal linux kernel <mik_>jookia: in terms of packaging, I shouldn't have to modify anything other than what .tar.gz is downloaded, right? <mik_>jookia: I'm not exactly sure what the patch that's applied does, but I assume the .tar.gz that's downloaded already isn't capable of loading non-free firmware <Jookia>mik_: Doesn't look like there's a patch bieng applied to the kernel <Jookia>Unless it's recent and I don't have it in my version <mik_>hmm. I cloned it today; I might just be misinterpreting, but I thought that's what was happening at line 363 of linux.scm <mik_>the comment above reads "apply the neat patch" <Jookia>Yeah, that's just to change the icon <mik_>oh, ha ha; I'll not worry about that then <mik_>I am getting an error: failed to load '(build-aux build-self)' <mik_>I've gotta get some rest <mik_>might have to drop back to nix tomorrow; have to see if I find the courage to delve back into it. Just really difficult to work on without working wifi <mik_>Jookia: thank you for all the help! <mik_>Jookia: seems like every time I come in here you're the first to respond, always with something useful <Jookia>I wish Guix had better tools for downloading and extracting directories <Jookia>A lot of the good stuff is in the opaque gnu-build-system when I just want to unpack and change to a directory <rekado>Jookia: the gnu-build-system is not opaque. Its phases are defined in guix/build/gnu-build-system. <rekado>for trivial stuff you can use the trivial-build-system <Jookia>rekado: I'd like to use functions from gnu-build-system <efraim>x11 headers should be in libx11? <ozzloy>does guix have a package for the latest ms windows 10? <efraim>looks like i needed libx11, libice, libxdmcp and libxpm (and maybe libxt and libsm) for enough X headers to build gvim <efraim>but apparently it needs x11 headers <efraim>my vim-custom is getting huge, it might be time to see what can be added to vim with no/minimal additional inputs, and what the minimum needed is for gvim and send those in as patches <efraim>ok, my vim-custom's --version output looks like it has feature-parity with debian's "bloated" gvim :) <efraim>and whatever I had in my .vimrc that referenced something pulled in by gvim and gave me errors is fixed in my vim-custom <efraim>guix size vim=335.4, guix size vim-custom=905.4 <efraim>not as bad as when I tried to add X screen capture to ffmpeg <Jookia>Patched lxappearance to find themes in XDG_DATA_DIRS ;) <rekado>why does "guix size" need substitute information? <iyzsong>rekado: run "guix size" on "/gnu/store/…" don’t need it ;-) <civodul>rekado: "guix size" can tell you the size of things that are not in your store <iyzsong>I was suprised when ‘guix size’ start downloading emacs. I guess it’s fixed now. <civodul>that could happen with grafts, but that's no longer the case <Jookia>I built an icon set package that uses symlinks to another icon set, and now building new profiles takes forever <Jookia>Should I just copy the icons in to the new set? <civodul>did you use union-build for your icon set package? <civodul>yes, because it creates the minimum number of symlinks that are needed <Jookia>Oh, well the thing is the upstream iconset has some symlinks that I had to replace since they were broken <Jookia>I think symlinks might be breaking things <civodul>hmm maybe i misunderstood what you were doing <civodul>i thought you were building a package as the union of several icons sets <Jookia> http://sprunge.us/VhPS this is the script, the problem is that numix-icon-theme-circle depends on numix-icon-theme and does this using relative symlinks, assuming a certain set of directories will be in the output as if I did do a union, but I haven't <civodul>mark_weaver: i've started a security-updates evaluation <Jookia>The package installs fine and sets my profile, but I get issues when I install another package <civodul>Jookia: the relation between these two package looks tricky <Jookia>Well, there's numix-icon-theme, and numix-icon-theme-circle which assumes numix-icon-theme is propagated but also symlinks to ../../Numix/, which would be where numix-icon-theme would be if you installed it in a traditional setup in ~/.themes since they go side by side <wingo>iyzsong: "guix package -p /tmp/foo -i gnome" has lots of conflicts in gschemas.compiled; is that a problem? <Jookia>Oh, it does build a profile. Just slowly <iyzsong>wingo: yes, that need to be addressed, but applications using glib-or-gtk-build-system are fine (be wraped). <iyzsong>Jookia: does the symlinks really necessary? I think the ‘Inherits’ field in the index.theme file should handle that for free… <Jookia>iyzsong: See, I thought that. But upstream is using symlinks so I guess they have a good reason? <efraim>or possibly they adhere rigidly to the FHS <Jookia>you're making me curious now, i'll test it to see if this is the case <Jookia>efraim: iyzsong: Guess what theme has needless symlinks that I wasted a few hours getting to work? <iyzsong>Jookia: if they’re not needed for desktop… then maybe the symlinks are for artists to work easily ;- <Jookia>iyzsong: I think that would be true if they didn't edit theme.index <Jookia>time to read git history to see if there's any caveats <Jookia>single line git commit "Added new /panel dir" :| Time to troll through github <Jookia>So apparently these symlinks are there to fix some diamond inheritence problem <rekado>our gfortran package does not seem to install libgfortran.so <rekado>doesn't even produce a "/lib" directory <rekado>or maybe we just need to add the "lib" output <rekado>so, I need to add ("gfortran" ,gfortran) and ("gfortran" ,gfortran "lib") to the native-inputs. <jmarciano>I would like trying shepherd on Debian... replacing the default. <jmarciano>do I need to recompile the kernel to change init to shepherd? Or maybe I can configure it with grub? <Jookia>I think you need to configure it with GRUB <iyzsong>that won’t be easy… out of GuixSD, there’are no services for shepherd. <rain1>I don't think debian lets you use any init system except systemd these days <jmarciano>Yes, but it is not hard to configure, I don't have many services that need to run. <ringst>You can use sysvinit or upstart on Debian without too much trouble <jmarciano>iyzsong: it need not be only GuixSD, although I have few packages in /gnu/store <Jookia>jmarciano: sounds like something fun to do if you're up for the challenge. you could always run shepherd for user services <Jookia>Nothing more satisfying than collecting 50GB of garbage in my Guix store <iyzsong>how would you maintain services? using guix or by plain scheme files? <jmarciano>I think that naming /gnu/store/kjnasjndaj-package, would be better other way around /gnu/store/package-ajknsdjnaksd <jmarciano>I think to run few services, with scm definition probably, reading info <Jookia>jmarciano: this discussion has been had before in nix land <rain1>I find myself using /gnu/store/*-name-ver/ sometimes <rain1>but there can be multiple results <Jookia>I mostly use /gnu/store/<first few letters of hash>, or 'guix build <packagename>' to get the path <jmarciano>in zsh, it works like: /gnu/store/shepherd<TAB> and I get it <Jookia>You probably shouldn't be running things directly from /gnu/store <rain1>it's in guix/gnu/services/shepherd.scm <jmarciano>i need sample script to put in /etc to use it as configuration <davexunit>shepherd configuration files in GuixSD are programmatically generated <rain1>but i think it's not the file you want <jmarciano>at my side is here: ./gnu/services/shepherd.scm <jmarciano>it seems customizable, I would need to shorten it... <jmarciano>he he, if something goes wrong, invoke guile REPL, instead of kernel panic, I like that. <janneke>i'm not succeeding in set-field on an operating-system's packages <mark_weaver>jmarciano: putting the name before the hash would slow down all filesystem lookups in /gnu/store, and to no useful end because you need to know the hash of the one you're looking for anyway, or else you might get something old with security holes or whatever <mark_weaver>janneke: Guix records are enhanced with extra features, they are not plain SRFI-9 records. I don't know that 'set-field' works on them. I suspect not. <jmarciano>yes I guess that relates to guix package management, yes. <jmarciano>but zsh shell expansion finds it fast, I wish to have same option in bash <ehiggs>thanks. is there a systemd-shepherd package yet? <ehiggs>mark_weaver: it would make people chuckle who think systemd has a lot of packages that it forks and subsumes. <ehiggs>mark_weaver: it looks neat. thanks for pointing me to it <janneke>mark_weaver: ah...yes I was wondering about that, thanks <janneke>I want to populate the (packages) field of operating-system <janneke>using the packages->manifest `feature', e.g. with sub-packages/outputs <janneke>but want to do that on plain guix-0.9.0 (debian package) <bavier>my emacs indents 'add-before' etc in modify-phases like an 'if' sexp, is that alright? ***raph is now known as Guest22358
<davexunit>bavier: you mean that it indents subsequent lines by aligning it after 'add-before'? <bavier>davexunit: it indents quote under the '-' in add-before <bavier>are there .dir-locals.el settings that my emacs isn't picking up? <davexunit>the proper way to indent is to add a newline after the second argument <davexunit>bavier: it's indenting correctly, but you're style is wrong. <davexunit>'build 'build-docs should be on the same line as add-before <bavier>davexunit: sure, but it's done the other way all over the place <bavier>ok, I can appreciate that; I'll keep a look out <janneke>ah, my problem is not with the definition or value of os' packages <janneke>it's the handling in services.scm... <rain1>just for fun I blocked facebook in guix system configuration <rain1>this is not blocked though, I guess it's because it's a subdomain <rain1>not sure if that counts as a bug in that service or not <raphmaster>I got a black screen after following the instructions to install GuixSD in Guix manual section 7. I am using the desktop operating system configuration example. After running "guix system init /mnt/etc/desktop.scm /mnt", it starts to download files. The black screen appear during the linux-libre-3.14 download. I am using Oracle VirtualBox. <rain1>raphmaster, is it possible it could be sleep? try pressing a letter key to wake up <rain1>or is it really frozen/crashed? <mik_>I'm getting a strange error when I try to build linux-libre <mik_>ERROR: no code for module (build-aux build-self) <bavier>rekado: I think slepc's origin needs a 'file-name' field. I'm guessing the '?' is throwing things off <jmarciano>rain1: I have blocked facebook so far in simple manner through /etc/hosts, 127.0.0.1 facebook.com www.facebook.com <bavier>rekado: btw slepc won't build currently because of a bug in the petsc package <rekado>bavier: I think I can fix the petsc bug <bavier>rekado: oh, I was just feeling inspired to fix it too <rekado>since the changes to custom-gcc all packages using gfortran also need to add the "lib" output of gfortran to their inputs. <bavier>rekado: I see. I thought it might have been the deduplication of drivers that caused the issue <civodul>mik_: could it be that the Guix source tree is in $GUIX_PACKAGE_PATH? <civodul>rekado: i don't know if it's related, but the file name is obviously wrong; we should fix the recipe for this <mik_>civodul: yes, should that not be the case if I'm trying to package something new? <civodul>simply use: ./pre-inst-env guix build new-thing <civodul>rekado: i think this particular substitute has never worked <civodul>bavier: your guess is probably correct <civodul>(sorry, i'm reading the backlog in semi-random order :-)) <civodul>'guix substitute' now honors 'Cache-Control' HTTP headers, and mirror.guixsd.org advertises one-week TTLs <civodul>so hopefully we'll be making fewer lookups :-) <bavier>rekado: I'll check my hypothesis, but I need to pull latest and rebase some local commits before, so it might take a bit <rekado>I just built petsc after adding ("gfortran" gfortran "lib") <mik_>civodul: thanks, I should read the documentation.... I switched from working on a different package base and didn't start from the beginning again <bavier>we have some documentation tools scattered around, would anyone be opposed to creating a (gnu packages documentation) module? <rekado>this seems undesirable to have to add both outputs to have a working gfortran compiler. <bavier>I have in mind mostly asciidoc, doxygen, and another I'm about to add (doc++) <bavier>rekado: that does seem undesireable <mark_weaver>civodul: fyi, I just tried "guix system build --no-grafts" before "guix system build" (with grafts), and the results were much nicer. I wonder if this could be done by default? <mark_weaver>(also, I see no way to do the equivalent for "guix package -u") <mark_weaver>in particular, I got notification ahead of time of what would be built and downloaded, and it avoided the repeated "updating list of substitutes" messages without useful progress information <mark_weaver>ACTION switched back to xfce for now, so I can suspend-to-ram during LP <wingo>now it is my turn to be jealous of LP folks :) <wingo>after many of yall missed FOSDEM :) <mark_weaver>civodul: something seems to be wrong with hydra. every attempt I now try to build something, anything, results in an error during [lookup-narinfos "https://hydra.gnu.org" #] <mark_weaver>but the 'https' in there makes me curious, I thought hydra.gnu.org didn't support https yet <bavier>mark_weaver: civodul fixed that yesterday <mark_weaver>everything was working for me about 15 minutes ago, but now it consistently failss <mark_weaver>and I haven't changed my guix revision since it worked. <mark_weaver>guix build: error: corrupt input while restoring archive from #<closed: file 0> <mark_weaver>passing --substitute-urls='' doesn't fix it either, it still tries and fails to fetch things from hydra, which is a bit troubling <mark_weaver>I don't even need any substitutes now, I'm just trying to make a minor change to my OS configuration :-( <mark_weaver>gah, it happens even when I remove /etc/guix/acls and pass --substitute-urls='' to "guix system" <bavier>perhaps unrelated, but I'm getting a "hash mismatch" for python-2.7.10 with latest master <mark_weaver>civodul: ^^ evidence of trying to fetch things from hydra even with /etc/guix/acl missing and --no-subsitutes and --substitute-urls='' passed to "guix build" <mark_weaver>I just resorted to disconnecting from the network, but it failed in the same way <civodul>mark_weaver: oooh, oops, you need to run the latest guix-daemon to get https support <mark_weaver>civodul: why is it trying to fetch things from hydra? <civodul>also, it's not trying to fetch stuff from hydra <civodul>it always fetches stuff from the specified servers <civodul>and *then*, it checks whether it's signed by an authorized key <civodul>so it's normal that things are being downloaded even if the ACL is empty <mark_weaver>it should be possible to inhibit any network activity <civodul>--no-substitutes did exactly that until recently <civodul>see %cache-urls in (guix scripts substitutes) <mark_weaver>so --substitute-urls='' effectively means "use the default list of substitutes" ? <mark_weaver>we should have a way to disable this that doesn't involve network activity <civodul>yeah well, we could somehow fix --no-substitutes in the presence of grafts <mark_weaver>I think we should have a way to specify an empty set of substitute-urls <mark_weaver>and I think --substitute-urls='' should be one of those ways :) <mark_weaver>more generally, if --substitute-urls= is passed, and there's some kind of syntax error in that specification, it would be better to error out or assume an empty list than to revert to the default list. <mark_weaver>I apologize if I reacted a bit strongly here, but I'm sensitive to the security issues around having a substitute server being used when I asked it not to. <bavier>rekado: I have a fix for petsc/slepc that doesn't involve gfortran-lib <rekado>does this also apply to "randomforests"? <bavier>seems like it might be different <civodul>mark_weaver: no problem! i agree that it's suboptimal, i'm just unsure what to do yet <bavier>civodul: 'guix refresh -l' still doesn't honor package inheritance, even with the graph rewrite? <davexunit>bavier: inheritance isn't like OOP. it just says "use the fields from this object as default values" <civodul>i had ideas to fix that but that has not materialized yet <civodul>davexunit: yes, but still, this is useful info when you want to know the impact of changing one piece of code <bavier>davexunit: right, I just thought that some of the graph analysis that's done might have been able to "see through" that <civodul>it could look at the graph including origins <davexunit>bavier: not currently because that data isn't part of the graph <civodul>yes but we could look at shared origin objects in the object graph <davexunit>that would cover some subset of cases, but not all, right? <davexunit>the only 100% way I can think of is to have a 'parent' property for each object <bavier>at some point I played with the idea of tracking inheritence via package origins <civodul>but we don't want to have a 'parent' property for other reasons :-) <bavier>or at least throwing origins into the whole mix, since there are other instances of (inputs `(("foo-src" ,(package-source foo))) <civodul>bavier: %bag-with-origins-node-type should help in that regard <civodul>davexunit: this is currently a mock AIUI <civodul>there's the problem that the daemon doesn't tell you what it's doing <civodul>bavier: when doing 'make distcheck', we see that doc/guix.1 gets rebuilt <civodul>bavier: so i'm a bit skeptical about the guix.1 dependency on $(sub_commands_mans) <bavier>civodul: yes, I've noticed that doc/guix.1 <civodul>maybe we could use the same hack as for the others? <bavier>hmm, the current 'man' rules also have the downside that they aren't regenerated after a manual 'rm doc/*.1' <bavier>errr, that might have been an OE <civodul>mark_weaver: will push a fix for --substitute-urls='' shortly <bavier>civodul: I think I've fixed the doc/guix.1 thing, would you like a patch to the ML, or can I just push? <bavier>or, so that I can check myself, what environment are you running 'make distcheck' in? <civodul>bavier: you can try 'make distcheck' in your developement environment <civodul>the error i had was that doc/guix.1 was left in the builddir <suitsmeveryfine>I've tried `(kernel linux-libre4.4)` `(kernel (linux-libre (version "4.4")))` and many other variants but none of them work. <civodul>the name here must be the name of a variable <civodul>those are defined in the gnu/packages/linux.scm file <civodul>bavier: could you paste the patch, out of curiosity? :-) <davexunit>more generally, an expression that evaluates to a package object for a Linux variant. ;) <civodul>suitsmeveryfine: 'linux-libre-4.4' is the name of the variable here <davexunit>suitsmeveryfine: you need to import the module that contains the variable <davexunit>(use-package-modules linux) is one such option yes, <davexunit>it's a convenient shorthand to avoid repetitive typing <bavier>so basically a slight variation on the sub_command_mans rule <civodul>bavier: looks good; if distcheck is happy, feel free to push <suitsmeveryfine>pizzaiolo: do you have alt-gr working now? If not: you can add this command to autostart in Xfce: `xmodmap -e "keycode 104 = ISO_Level3_Shift"` <janneke>how do i make a meta-package, i.e., without source or build system? <rain1>what would one do to get that? just package -u ? <mark_weaver>I hadn't tried in a while though, so I'm not sure when it got fixed <mark_weaver>might also have been the addition of xfce4-power-manager <bavier>civodul: I get a different error from 'make distcheck' about writing emacs/guix-autoloads.el into srcdir <bavier>which I think means that emacs/guix-autoloads.el should be distributed? <bavier>or written to ${builddir}, I'm not sure <efraim>we should switch our qt source uri to the archive link <mark_weaver>efraim: if there's a new version, we should probably upgrade to it, given how many bundled libraries there are in qt and the number of recent security updates. <efraim>actually, looking at qt4, 4.8.6 is in the archive folder and 4.8.6 and 4.8.7 are in the official release folder <mark_weaver>I think we should upgrade and add the archive link as a secondary source URI <mkoenig>is there a gnu'ed version of thunderbird available? <efraim>NiAsterisk: do you need to escape any of the characters? <efraim>also you don't use the output option after the lambda* <efraim>so I'd see if it works with lambda _ <NiAsterisk>I am unsure with substitute.. there's only this one part ";" to "§" i need to patch <mark_weaver>NiAsterisk: remove the parens around the replacement <NiAsterisk>oh, okay. I am not sure if this patched version is worthy to include, but it would effectively do what I described in the powwow which is currently packaged. <mark_weaver>we wouldn't want to make that kind of change in a package incorporated into our official guix <NiAsterisk>if you use it to chat via telnet ";" is a bit annoying <mark_weaver>we try to avoid making non-essential changes to upstream packages in Guix <NiAsterisk>then I need to alter the description and make the location I pointed to include this .scm <efraim>oh, I added python2-pysqlite to my copy of offlineimap and it sped up my syncing by like 35% <roelj>The guix daemon won't start anymore, saying: "error: libgcrypt version mismatch" <paroneayea>roelj: did you compile guix's daemon inside of a guix environment and then try running it outside of it? <paroneayea>I hit this when I was dual booting between guixsd and debian <roelj>paroneayea: No.. not that I'm aware of ;) <NiAsterisk>do I need to escape § ? as § gives me an error where § is displayed as ? <roelj>I compiled guix from the git repo, and have pointed ~/.config/guix/latest to that. <roelj>I haven't used the 'guix environment' command at all <roelj>Then I have GUIX_PACKAGE_PATH that points to another directory with my WIP packages. <civodul>bavier: i've fixed the emacs-autoloads.el issue in 1ac94ae earlier today <roelj>I see there are two versions of libgcrypt and in my profile, it links to the newest version. Should I symlink to the old one instead, and see if that helps? <civodul>roelj: that's a mismatch between the run-time libgcrypt and the headers used to build guix-daemon <civodul>grep for LIBGCRYPT in config.log, and compare with "ldd guix-daemon | grep libgcrypt" <civodul>mkoenig: no, it doesn't support UEFI AFAIK <roelj>civodul: It doesn't specify a version in config.log. What am I looking for? <civodul>roelj: something like /gnu/store/...-libgcrypt-1.6.5 <roelj>civodul: Aha, in config.log it uses /usr/bin/libgcrypt-config.. Not a guix one <bavier>civodul: I see, thanks, you fixed that right after the last pull I did <wingo>systemd-inhibit seems to work ok <roelj>I configured it to use the libgcrypt from the gnu store. No luck.. <roelj>Then reconfigured it to use Fedora's libgcrypt. No luck either. <bavier>NiAsterisk: is the substitution failing, or is the regexp failing to match? <NiAsterisk>I will post the log, just need to get it to fail again <NiAsterisk>bavier: okay.. it no longer fails but the substitute is failing to match and when it fails completely, it displays § as ? <bavier>NiAsterisk: I'd perhaps try to be more liberal on the whitespace matching: "#define CMDSEP[[:space:]]*';'" <bavier>no, it shouldn't; is that just your terminal not displaying the § correctly? <NiAsterisk>bavier: strange enough I can type and display § here but the one you pasted is just as � here <manuels312>Hi, I'm wondering if you can install guix into your home directory and run it without root privileges? <NiAsterisk>bavier: what do I need for [[:space:]] to get accepted? <NiAsterisk>"defines.h")) ("#define CMDSEP[[:space:]]*';'") ("#define CMDSEP[[:space:]]*'?'") is part of the error <mark_weaver>NiAsterisk: [[:space:]] should work, but two things: as I said before (did you miss it?) you need to remove the parens from around the replacement expression, and putting [[:space:]] in the replacement expression will just result in that exact string "[[:space:]]" being put there. <mark_weaver>the replacement is not a regular expression, it is just a string <mark_weaver>or rather, a scheme expression that must evaluate to a string <bavier>good-point, I missed that part. paren-blindness I guess <mark_weaver>("#define CMDSEP[[:space:]]*'§'") as a scheme expression fails, because the parens make that into a procedure call, with the first item being the procedure. but a string literal is not a procedure, so it will fail <NiAsterisk>hm. I thought it was file (string) (replacement) <mark_weaver>it's (substitute* <filename(s)> ((<regexp> <optional-bindings> ...) <replacement>) ...) <mark_weaver>in this case, you want something like (substitute* "defines.h" (("#define CMDSEP[[:space:]]*';'") "#define CMDSEP '§'")) <mark_weaver>btw, the reason you often see parens around the replacement is because in those cases it really is a procedure call that returns a string, e.g. (string-append ...) <mark_weaver>in scheme, parens are not just about grouping, so you can't just add them wherever you want, like in other languages. <mark_weaver>in scheme, each pair of parens indicates a procedure call (or macro use), with the first element being a procedure or macro keyword. <jesaispas>at the beginning, which manual do i need to read? GNU Guix Reference Manual or GuixSD manual? <bavier>jesaispas: are you looking to run GuixSD or use the package manager <bavier>jesaispas: anyway, the guix manual covers a lot of the background and concepts, so that's a nice place to start <mark_weaver>jesaispas: The link to the "GuixSD manual" is actually just pointing to one chapter of the Guix manual. <mark_weaver>NiAsterisk: btw, another option for something like that is to add a patch <NiAsterisk>does guix have an option like gentoo where you can integrate every .patch and ignore it when there are none <mark_weaver>I'm not entirely sure I understand what that means, but I'm fairly sure the answer is "no" <NiAsterisk>hm. makes sense, the packaging architecture is different <mark_weaver>I suppose in theory, the 'patches' field could be an expression that scans a directory for filenames matching a certain pattern and return that list of files, but that's not how we do things in Guix, and I don't think we'd want to. <mark_weaver>for one thing, we often have multiple variants of the same package with different sets of patches applied <mark_weaver>e.g. for 'guile' we have a bootstrap guile with at least one extra patch, and we often have multiple versions of the same package with different patches needed for them, etc. <mark_weaver>and from a stylistic standpoint, I prefer to see from looking at the package definition whether there are any patches, rather than also having to look in a directory to see if there are any files starting with the package name. <mark_weaver>IMO, anyway, feel free to propose something on guix-devel if you disagree :) <NiAsterisk>it's open in gentoo and it's what you write and can include regexp patches in a folder, and also have specific patches. I'm okay with how it works here. <gnudevotee>Happy GNUvidad! May He be with us for a long time! <mik_>I want to modify a package definition in the guix source tree, then actually be able to install it. Someone earlier told me to use pre-inst-env script when developing, but I actually want to be able to install the package <bavier>mik_: ./pre-inst-env guix package -i <my-package> <mik_>it's a kernel, so I wanted to do guix system reconfigure <gnudevotee>bavier, GNUdists celebrate GNUvidad on March 16th <bavier>mik_: same, sudo <path-to>/pre-inst-env guix system reconfigure system.scm <mik_>putting sudo before pre-inst-env always gives this error: no code for module (guix config) <mik_>what does pre-inst-env even do? <mark_weaver>mik_: it sets environment variables so that the uninstalled code in the Guix source directory will be used <mik_>ah, thanks; unfortunately I don't understand its effects, the variables it introduces don't mean anything to me