<atw>does anyone else use inconsolata in emacs? with the updated inconsolata each character is given twice the space it needs, kinda l i k e t h i s. I have a screenshot if anyone has a recommended image host <atw>(in the meantime I'm using Noto which is nice and I might stick with it) <nckx>atw: That's interesting. I'll try it. <nckx>I assume it's normal everywhere else? I use Inconsolata 3 in Termite and it looks great. <atw>thanks nckx. I haven't tried outside of emacs, let me try firefox <atw>firefox says it's using inconsolata and it looks normal. Could just be an emacs problem <atw>emacs says "display: by this font (glyph code) xft:-CYRE-Inconsolata-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x112)" <nckx>atw: Looks normal in Termite, IceCat, and LibreOffice. But it's similarly mishandled by my emacs. <terpri>somewhat related, i'm interested in improving emacs gnustep to the point where emacs on macos could use modern ui feautures (emoji support, etc.) <nckx>atw: My emacs is a rather old 26.3 version and I can't upgrade. Is yours recent? <leoprikler>terpri: Emacs 27 (emacs-next) should have Emoji support, does it not? <atw>thanks for checking terpri, nckx, guess it's an emacs oddity. I tried emacs-next too and I get the same result there, nckx <leoprikler>atw: is this before or after refreshing the font cache? <terpri>i am not seeing extra space but it's using bold letters for inconsolata buffers <nckx>terpri: And if you explicitly select, say, Inconsolata Medium? <terpri>running emacs -Q --no-site-file after fc-cache -r <atw>leoprikler: I have found that eg 👋 appears as tofu using emacs-next and Noto, but some emoji work, like 🌜 <nckx>terpri: And are you using the latest Inconsolata version (3.000) with clean fc-caches? <atw>leoprikler: this is all after a font cache refresh <terpri>that's with inconsolata medium seleceted <terpri>this is with font-inconsolata@0.8, and emacs-26.3 <nckx>I think the problem is specifically with 3.000 + emacs only. <terpri>fc-cache -r for cache cleanup, dunno if there is a more thorough option <nckx>No, -r is already ‘force, but like really’. <nckx>Well, you could sudo, but that's not relevant here. <leoprikler>atw: 👋🌜 displays nicely (albeit colourless) in my emacs-next <atw>leoprikler: hmm not in mine unfortunately. What font are you using? <leoprikler>though it also renders colourless in emacs 26, hmmm *terpri tests with newer inconsolata <leoprikler>Noto Emoji enables both as far as I can see from debug <terpri>leoprikler, i haven't kept up other than occasionally hearing compliants that emacs-on-osx disables basic features for political reasons <terpri>and i'm one of (probably) few people who actually care about emacs-gnustep, so... <leoprikler>I'm going to ignore complaints about political reasons for political reasons. *atw will have to mess with emacs' fonts more <terpri>insisting that emacs-on-macOS will remain at feature parity with emacs-on-gnustep would be a perfectly reasonably strategy if anyone were around to work on the gnustep side of things :/ <nckx>terpri: …and that v2.x Google dump is itself outdated (the font is hosted under a googley GitHub account IIRC, but not that one). Any luck with 3.000? *nckx wonders what kind of features one would disable ‘for political reasons’ and why. <atw>font-inconsolata 3.000 should be available after a guix pull <nckx>Don't ask me why both google/fonts and googlefonts exist, because the answer is just gonna be ‘Google 🤷’. <nckx>Guix packages the googlefonts version which is 3.000. <nckx>Well, version. It's just upstream. <leoprikler>"We accidentally implemented this thing Mac users like" was taken by Mac users as "Emacs HATES Mac users". <nckx>…and the reasoning's gone. <leoprikler>On another note, nckx, how do you send patch series in a way that it doesn't open a new bug per patch? <nckx>Me personally? By sending a ‘cover letter’ with my MUA, waiting for the bug number, then using git send-email --to=nnn@. <leoprikler>I've configured my git:send-email with sendemail.to = guix-patches@gnu.org to skip this for single patches, but this appears to break things <nckx>I don't get your previous sentence. <nckx>I have [sendemail] to = guix-patches@gnu.org <nckx>When I use ‘git send-email -1’ it just works. <nckx>--to=nnn@ also just works. <leoprikler>yeah, it's my fault for using CC'ing bug numbers normally <nckx>Now I've zoned out the past half hour trying out ‘new’ monospace fonts again, knowing full well that I'll just revert back to Hack anyway. <nckx>Never remind me that fonts exists. <atw>hahaha, revenge! I did the same in a futile effort to make your emoji show up *atw C-u C-x = to find out what emotion is being expressed <nckx>I'm sorry, that was mean; it's just an angry face. <leoprikler>Is there a simple way to "union-build" a package from multiple origins? <nckx>Do you mean Guix unpacking multiple source origins for you, as transparently as a single one is, before the build starts? <nckx>The closest to that is 0 or 1 ‘source’ origins, and passing the rest as regular inputs & unpacking them yourself. <nckx>‘Source’ is just an input with extra sugar anyway. <nckx>Did that address your question at all? <leoprikler>I'll still have to roll my own "union-build" via trivial-build-system from what I understand. <nckx>I guess so, it's not quite clear to me what exactly you're making. *nckx has reverted to Hack and gone back to work so not super-available now. <leoprikler>I'm trying to pack up some unicode-related files for ibus. <terpri>leoprikler, looks like a slightly modified mit/x11 license <terpri>atw, with inconsolata 3 i see the extra spacing too <bandali>does that happen even after a fc-cache -fv ? <nckx>bandali: Indeed, but my attitude to emacs font management is ‘stay away’. <bandali>nckx, looks like possibly an inconsolata issue, not an emacs one, though :) <nckx>bandali: Perhaps. We'll see. <bandali>nckx, re dnssec: i’m powerless; your best bet would be the fsf sysadmins <bandali>:) do you know how to reach them on irc or email? <nckx>Not a clue! But I assume it's not classified. <bandali>hehe definitely not :) you can drop by #fsfsys or write to sysadmin@gnu.org <nckx>bandali: Thanks for saving me some keystrokes. <leoprikler>If the FSF implements a filesystem, will it be the FSFFS? <bandali>probably, since fsfs is already a thing <atw>thanks for finding the GH issue, bandali <bandali>atw, it’d be nice if you could chime in and perhaps show a screenshot of your emacs as well <bandali>(to show that this isn’t a one off issue) <apteryx>uh; during a build on core-updates: ld: BFD (GNU Binutils) 2.33.1 internal error, aborting at merge.c:930 in _bfd_merged_section_offset <apteryx>and then: ld: Please report this bug. <KE0VVT>How do language packs in Guix work? <KE0VVT>I'd like to translate my system to Pennsylvania Dutch. <apteryx>Most applications honor the locale settings (through environment variables such as LC_LANG). <KE0VVT>apteryx: Would pdc_US.UTF-8 be available? <apteryx>hmm, what I can see in glibc-locales data is yi_US, es_US, en_US, chr_US and unm_US. <KE0VVT>apteryx: How does one edit these locale files? The characters are all in Unicode <U1234> things. I can't read or write that! <valignatev>Hey Guix! I have a question about modifying phases during the build. Specifically, I want to patch some source file of a cargo dependency. Standard configure phase stores dependencies in a vendor-dir which happens to be "guix-vendor" by default and it unpacks dependencies to a folder that constructed as a package-name + version + .tar.gz. Here's my <valignatev> question: Is there a generic way of getting a vendor-dir inside a custom phase and how to get a dependency directory without hardcoding it? My current snippet is kinda like this: https://paste.debian.net/1125559/ <valignatev>Hardcoded version works, but I'm sure there's a better way <str1ngs>valignatev: dependencies are called inputs you can get them like this (assoc-ref inputs "depend") <str1ngs>valignatev: if the input was called depend. that would return depends output directory <str1ngs>also this assumes you used depend as the key name for the input <valignatev>Unfortunately, it only works with inputs but not with cargo-inputs that are declared as #:cargo-inputs argument to a build system <valignatev>There's a plenty of examples with plain inputs in guix repo, but I failed to find something useful for my case ***wxie1 is now known as wxie
<valignatev>Another question: how to delete some input from package-inputs by a package name? both delete and delq throw Throw to key `match-error' with args `("match" "no matching pattern" when I'm trying to pass something like `(delete ("input-name" ,input-package) ,inputs) to a substitute-keyword-arguments <valignatev>Where inputs is a list of pairs like (("name" package) ("name2" package2) ("name3" package3)) <valignatev>I can write a custom predicate, but I wonder if there's something out of the box <leoprikler>valignatev I'm pretty sure you want to use alist-* functions <leoprikler>if they end on a !, don't forget to copy-sequence <valignatev>Yeah, I've tried assoc-remove! and friends without any luck <leoprikler>you could also use SRFI-1 remove with (lambda (item) (equal? (car item) key)) <valignatev>Hm, I think that the error happens not where I thought it was. It appears that cargo-build-system tries to match on its inputs before the snippet executes. So I shouldn't quote it <valignatev>I mean, cargo build system expects its inputs alist but gets my quoted code <leoprikler>all build systems expect an alist of (name package [output]) <valignatev>Yup, it's correct, cargo parses its inputs as is, so I shouldn't quote keyword substitution snippet. With that being said, simplest possible (delete) works now. I quoted substitute-keyword-arguments snippets because of some examples that I've found which I think I didn't fully understood <valignatev>leoprikler: your suggestions pointed me to the right direction, thanks! <raghav-gururajan>valignatev May be it is better to do a 'manifest' file, with declaring custom package definitions for your packages of intrest, to 'inhert' original package definitions and remove mentioned inputs. <valignatev>that's what I did - I declared a new inherited package definition where I removed mentioned input <raghav-gururajan>leoprikler bandali May be GFS (GNU File System) or FFS (FSF File System)? ;-) *raghav-gururajan cannot see any of the emoji typed by others here. <leoprikler>(it better be polari after all my packaging efforts) <leoprikler>you do have font-noto installed and usable, right? <leoprikler>yeah, you're gonna need some emoji font for emoji <leoprikler>noto is nice, but you can use other fonts with large unicode support if I'm not mistaken *raghav-gururajan never uses VM. Too lazy to configure and start it. <leoprikler>and I'm too lazy to reopen all my private epiphany tabs, so I test via `./pre-inst-env guix build vm` -m 2G <raghav-gururajan>sneek: later tell oriansj: Pardon? I am not able to understand what you mentioned. <sneek>Welcome back raghav-gururajan, you have 1 message. <sneek>raghav-gururajan, raghav-gururajan says: what <sneek>leoprikler, you have 1 message. <sneek>leoprikler, leoprikler says: hi <valignatev>Is there a way to do (package-arguments) inside of modify-phases? Something liks (modules ...) for source snippet maybe? I've tried to straight up (use-modules (guix packages)) but it can't find the module this way <valignatev>Specifically, I want something like (package-arguments this-package) inside of my modify-phases <leoprikler>valignatev: you would have to unquote (,) that either way, because this-package is not bound during build <leoprikler>depending on your context perhaps ,@ instead of , ***Server sets mode: +cnt
<leoprikler>Is there a way to refer to the outpuf of a hook in advance? <kmicu>Nice to see a chat about font issues in the backlog. <kmicu>Even nicer too see on the mlist how civodul reminds us that features are not a free meal and maintenance cost is the price to pay. ʕノ•ᴥ•ʔノ ︵ ♥❤❣💞 <nixo>Hi, anybody else is having problem with the recent emacs-undo-tree update? <leoprikler>not yet, but that might be a delayed update on my end <nixo>leo: undo-tree-move-GC-elts-to-pool: Wrong type argument: hash-table-p, nil <nixo>and some other error when trying to go back in history, breaking history. Just upgraded to 0.7.1 and seems to work, sent the patch on the list <leoprikler>If 0.7.1 works, that might be an issue with 0.7.0. <leoprikler>though from git log i don't really understand myself <str1ngs>sound like an existential crisis. :P <nixo>Yes, but since I added also olivetti and poet-theme together with the upgrade, I can't be 100% sure on what's causing it. Btw, undo-tree-move-GC-elts-to-pool has been added in 0.7, and 0.7.1 is out, so hopefully it got fixed <oriansj>nckx: your btrfs advice to run btrfs check --repair; actually is supposed to be a last resort solution. if you check out my current btrfs notes: https://paste.debian.net/1125586/ I have the current recommended procedure for fixing a btrfs system. <sneek>Welcome back oriansj, you have 1 message. <sneek>oriansj, raghav-gururajan says: Pardon? I am not able to understand what you mentioned. <leoprikler>From what I can see the function itself is older than that, but there has been some "GC refactoring" that might have broke a call to there. <leoprikler>btw. I use olivetti together with undo-tree and it works fine for older versions <nixo>Well, it's working for me now, so better go back to work :D Thanks <g_bor[m]>I have found an even simpler reproducer for the installer problem. <g_bor[m]>It seems that it also exists on the installer image, but I have not tried if a full installation work or not. <g_bor[m]>ok, painful as is, but the installer image built from the latest commit also fails to install the system. <g_bor[m]>I have a quite simple reproducer also, so I am inculding that. <leoprikler>Either through a package, that installs files there or through a system service. <leoprikler>I can't guarantee that those files will be read, though, unless there's some PATH variable which you can set. <mehlon>so I edited a package definition from my local git clone of guix <NieDzejkob>it's the easiest way and takes only a few minutes <NieDzejkob>a few days ago I came here to ask this question too, and that's the answer I got :D <NieDzejkob>after learning a bit more about Guix, no better way comes to mind <mehlon>well, on nix I just kinda do nix build package -f gitdirectory :p <NieDzejkob>PotentialUser-99: don't ask to ask, just ask your question :D ***ng0_ is now known as ng0
<mehlon>looks like `make authenticate` doesnt work <mehlon> [message: "could not authenticate commit efc32ed8904ca1bbf2123ff1c64782329d7c9941: key 53C41E6E41AAFE55335ACA5E446A2ED4D940BF14 is missing"] 7f9a9ba85b60>)'. <mehlon>NieDzejkob: well.. I dont know what kind of computer you have but this is taking me more than a few minutes... :p <NieDzejkob>mehlon: did you pass -j4 or similar to make? I forgot that I did that because I have that set in $MAKEFLAGS <NieDzejkob>it's safe to ^C interrupt the process and restart with paralellism <NieDzejkob>rndd: If (print) were using procedures like (display) to do output, you could do (with-output-to-file "/tmp/test" print) <NieDzejkob>(see also with-output-to-port, with-output-to-string) <NieDzejkob>but system sidesteps guile's I/O and launches a separate process, I'm not sure how to catch the output of that <NieDzejkob>just read #guile. Please mention when you cross-post and tell us when other channels respond so that we don't duplicate effort and discussion <rndd>ok, NieDzejkob. i didn't know this rule <valignatev>leoprikler: Thanks for your advice to unquoting needed stuff into the phase modification function before it got sent to the build system, it totally worked. I got burned by an infinite recursion once while trying to get this-package arguments while getting this-package arguments but I was able to work around that <drakonis>hmm, is it strange that my fonts arent updating? <NieDzejkob>my fonts also aren't updating, I have to run fc-cache each time <sameerynho>I'm looking to create a package for GraalVM, it's community version released under GPL2 , I pressume it's ok for a GPL software to be part of guix's official repo. right ? <sameerynho>I know, but since it has an enterprise version i was in doubt <leoprikler>As long as the thing you're packaging is covered by the GPL, (or any other libre license for that matter), it should be possible to include it in Guix. <drakonis>no openjdk does not, its a separate project <wdkrnls>Hi, has anyone looked into using AirVPN with Guix? <sameerynho>leoprikler: you can install graal compiler as a jvm plugin, but GraalVM is more than just the graal compiler <pkill9>wdkrnls: there is an openvpn service <kmicu>(Mark patched IceCat to 68.4.1 two days ago so don’t forget to guix pull) ***cyrozap is now known as Guest44281
<hexagonal-sun>Unfortunetly with my internet speed that will take a *long* time! <kmicu>hexagonal-sun: it depends what you want to compile but you can use texlive-tiny or texlive-union. If you are not familiar with TeX packages then it’s better to install all of it. <valignatev>Hey people, what's "error: invalid field specifier" means and how do I find a line number of the file that causes an issue? <kmicu>A section about Using Tex for Basics in the Guix Cookbook could be nice (but I still not migrated from TeX from Nix so cannot help here). <valignatev>I'm pretty sure that I messed up parenthesis somewhere in the file but I can't find it myself and guile doesn't want to help me :( <g_bor[m]>valignatev: most probably one of the records you defined has invalid value in one of its fields. <valignatev>That's for sure, but how do I find which? This is all I have <valignatev>make[2]: Leaving directory '/home/vj/workspace/me/guix' <valignatev>make[1]: *** [Makefile:4782: all-recursive] Error 1 <valignatev>make[1]: Leaving directory '/home/vj/workspace/me/guix' <valignatev>that's it. The only thing I know is the file which I have changed a lot and it's 17k lines of code now <g_bor[m]>oops, that seems to be too much for a paste. <valignatev>Before I do this - is there a way to debug this myself? Some verbosity level or something? <hexagonal-sun>Also another question if people don't mind, is there a way to speed up the building of '-profile' when a package is installed? It seems to be going really slow on my machine. <g_bor[m]>Also I see you are running this in make. <g_bor[m]>Can you tell me something about what you are trying to achieve? <valignatev>I just packaging a lot of cargo packages and I definitely misplaced some field somewhere <valignatev>I'm 100% sure that this is an easy typo, but how do I find where it is <valignatev>In worst case scenario I'll just traverse my undo tree, but I think it's a good opportunity to learn more about how to debug guix <g_bor[m]>maybe you could try to load the module from a repl, but I am not sure thaat you will get more details... <valignatev>Whoa, I actually have something more now: unknown location: package: invalid field specifier in form #:cargo-development-inputs. It still doesn't give me a line number though, but it is more useful at least <sameerynho>how can I ask guix to open up an editor beside emacs for `guix edit` ? <leoprikler>It normally takes me between 22 and 24 minutes to reply, though. <g_bor[m]>:) this one was within a minute, but might be an outlier... <valignatev>Found my issue by rigorously scanning through my undo list. Indeed an easy typo - I places #:cargo-development-inputs outside of (arguments in one package. I wonder why guix doesn't display a line number for such mistake. Probably I should report this <leoprikler>Well, it was at the end of the 22 minutes I was talking about ;) <g_bor[m]>I am trying to bisect this installer bug right now. <valignatev>I've also noticed that whenever I have unbalanced parens, guile always points me to the very end of the file so finding an unbalanced paren is quite difficult <leoprikler>Well, that's the drawback of having your entire language syntax be (,), and everything else <leoprikler>From a syntactic point of view, it is a correct program as long as you match up the parens. <sameerynho>Do i have to add the GraalVM package definition to the `java.scm` file ? <valignatev>I guess I really have to learn that barfing and slurping stuff and stop abusing vim-like surrounds <leoprikler>sameerynho: It would be beneficial if you did. Is there something speaking against that? <sameerynho>leoprikler: well, it's a jvm alright, but it has its own identity with e polygot stuff an everything <roptat>if it's going to have a lot of dependents, probably put it in a separate file, otherwise it's fine in java.scm <nckx>‘GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Groovy, Kotlin, Clojure, and LLVM-based languages such as C and C++.’ <nckx>So not Java, but we don't have a jvm.scm file so whatever. <nckx>sameerynho: Hm, this doesn't look java(.scm)-centric at all… Did you have another file in mind? You certainly don't ‘have to add it to java.scm’ just because it uses the JVM. <nckx>NieDzejkob: Why does cURL upstream not do this? <mbakke>NieDzejkob: the patch looks pretty good, could you submit it upstream as well? <NieDzejkob>nckx: that's a good question I haven't fully considered, thanks for asking <nckx>NieDzejkob: Everything in the commit message should be a comment. Otherwise LGTM, but I've had a bit too much wine to officially review C patches. 🙂 <nckx>(I mean comment in the patch file.) <NieDzejkob>mbakke: I noticed that you left a comment mentioning upstream's thread-safety concerns with making libcurl reading env vars, do you happen to know where that discussion happened so that I could make sure my patch addresses these concerns? <NieDzejkob>(I tried searching the GitHub issue/PR tracker, but perhaps I'm using the wrong search terms) <mbakke>NieDzejkob: I don't have the links at hand unfortunately (it was some mailing list discussion IIRC). <NieDzejkob>argh, is there no way to search the curl ML archives? ***dctrud_ is now known as dctrud
<nckx>oriansj: ‘my advice to run btrfsck --repair’? Wut? <nckx>btrfsck --repair nukes more data than it saves. <sameerynho>nckx: i was thinking of having a dedicated package for it <nckx>sameerynho: Fine by me. That makes more sense to me than java.scm, which is really for Java the language which the JVM has long outgrown. E.g. clojure.scm. llvm.scm is also its own thing. <nckx>NieDzejkob: Fast! Thanks. <nckx>KE0VVT: <btrfsck doesn't sound right> ? <nckx>‘btrfs check --repair (used to be called btrfsck) checks consistency of a btrfs filesystem’. <nckx>Red Hat never never supported btrfs. OpenSuse did, and still do. <KE0VVT>nckx: btrfsck doesn't sound right, because fsck itself does not sound right. <nckx>Commit 373007882def43f43d8da9678f6ab81047e32230 is weird. <nckx>Oh, it's been reverted. Thanks mbakke. <mbakke>I'm getting a bogus "error: failed to load 'gnu/tests/install.scm': No such file or directory" after merging master into core-updates and running 'make'. <mbakke>maddeningly, it does not occur on a fresh clone <nckx>kmicu: <Even nicer too see on the mlist how civodul reminds us that features are not a free meal> Interesting. What was that about? <mbakke>strace reveals it is trying to load some stale rust-cbindgen.go, even though I've tried 'make clean-go' and manually removed stale go files <mbakke>changing to guix environment --container did the trick, though...something from the host environment must have leaked through <mbakke>NieDzejkob: I did not use pure initially, but tried it to no avail. <sirgazil>Looking for boot logs, I found this file called "/var/log/messages" and discovered that it has messages from the time I installed Guix System to date. Is this normal? The file is now ~730 MB. <kmicu>nckx: complexity bomb called use flags aka package x is broken on my computer but works on default installation. <drakonis>NieDzejkob: check your PR on curl's repository, daniel replied <drakonis>kmicu: i dont get it, why not just provide the means to do that and then let people go do whatever <drakonis>the default package definitions are the ones that will be built with cuirass <kmicu>drakonis: If we only add means but not test it (so build it at least once) then we will create a lot of broken packages and a lot of support traffic with dissapointed users. <raghav-gururajan>sirgazil Woah! Thanks for the revalation. I just found out that my '/var/log/messages" is ~230 MB. I believe this is pretty serious. Could you post it to guix-devel or bug-guix please? You can also include that I have the same issue. :-) <alextee[m]>is it normal that my root partition is 50 gb full now ? even after gc it stays pretty high <alextee[m]>is there anything i can do to minimize storage used by guix? <alextee[m]>with other distros and same packages i had around 25GB full only <leoprikler>so worst case scenario you only have place for 2 generations <leoprikler>(simplified maths, it will be more like 5 to 10, but still few) <alextee[m]>i guess i need to resize it... i never thought the root partition would need more than 50GB <raghav-gururajan>alextee[m] Could you check the size of '/var/log/messages'? Please find sirgazil's message above? :-) <leoprikler>(Then again, my messages and debug are 21M each as well and I don't care.) <kmicu>alextee[m]: ncdu /gnu/store and investigate what takes so much space. <raghav-gururajan>alextee[m] Have you tried `guix gc` with `--delete-generations' as root? That is `guix gc --delete-generations` as root? <alextee[m]>raghav-gururajan: no, that might be it because i had a lot of packages installed as root before <alextee[m]>it seems i have a lot of copies of packages, is this normal? for example there's 8 directories for qemu-4.1.1 in /gnu/store <Gooberpatrol66>where can i find documentation about how snippets/patching works <raghav-gururajan>alextee[m] I usually do this once every 4 weeks. I run the following in this order. First as User: `guix profile --delete-generations` --> `guix package --delete-generations` --> `guix gc --delete-generations`. Then as Root: `guix profile --delete-generations` --> `guix package --delete-generations` --> `guix system delete-generations` --> `guix gc --delete-generations`. This might be useful for you. :-) <kmicu>alextee[m]: you could note hashes of those qemu packages and inspect what holds them. <alextee[m]>raghav-gururajan: i thought those did the same thing lol, there's generations for all kinds of things? <kmicu>alextee[m]: sreaching manual for referrers and references will give you pointers. Maybe a cookbook has a section explaining how to investigate the store. <alextee[m]>TIL the system has generations tooo... that's probably it *raghav-gururajan re-posts <raghav-gururajan>alextee[m] I usually do this once every 4 weeks. I run the following in this order. First as User: `guix pull --delete-generations` --> `guix package --delete-generations` --> `guix gc --delete-generations`. Then as Root: `guix pull --delete-generations` --> `guix package --delete-generations` --> `guix system delete-generations` --> `guix gc --delete-generations`. This might be useful for you. :-) <alextee[m]>and i only have 2 qemu's now lol, i can live with that *alextee[m] makes the same script <kmicu>Glad to hear that alextee[m] <jojoz[m]>Anyone here have / know of any programming language using Guix as the canonical package manager? Like, even when Guix is not the system package manager of the distro. <NieDzejkob>I need help with regex-fu. I've got this: (substitute* "scripts/xdg-screensaver.in" (("(?<!ERROR: )xset") (which "xset"))), but guile's regexes don't support negative lookbehind. I have to match 1. xset at the beginning of an indented line, 2. if xset, 3. not match xset in an ERROR string <NieDzejkob>or is the preferred way of doing this to add a PATH entry in a wrapper or at the top of the script? <jojoz[m]>Is that even a good idea? It feels like it would be -- Guix today has basically the same features as e.g. Stack does for Haskell. <kmicu>Hi jojoz[m]: I don’t think there’s any. Idris experimented in using Nix but that’s not the thing too. <drakonis>nix has the whole haskell packageset available <kmicu>jojoz[m]: the issue is that choosing an external package manager brings all additional deps (and knowledeg) into a proglang’s ecosystem. Not everyone wants to pay that cost. <jojoz[m]>kmicu: What do you mean? That the namespace becomes polluted in the view of those who are only concerned with the languages ecosystem?