IRC channel logs
2022-06-05.log
back to list of logs
<nckx>Library references don't go through your profile, and it's the ‘real’ store file that's busted, not some profile symlink. <wdkrnls>but if guix build did make a new store directory, why would the emacs in my profile not use that one instead? <wdkrnls>e.g. /gnu/store/1zd6x4afmjlgxny37r7h2rx61iz2fdsk-gtk+-3.24.30 <wdkrnls>whereas emacs looks at: /gnu/store/4ccp0z06gx7l69yfw5ha6v26ql6hqyh5-gtk+-3.24.30/ <djeis>Huh. virsh still doesn't see the rbd backend. <djeis>Of course it wouldn't be that simple. <nckx>wdkrnls: References are fixed. That copy of emacs will use that copy of gtk+, forever, because that's what it was built with. <nckx>If you update emacs, that can change. <nckx>If you update gtk+, that just creates a new gtk+ ‘slot’ in the store that your existing emacs doesn't care 2 whits about. <wdkrnls>nckx: how do I do that? I tried `guix install emacs` with no luck... <nckx>I don't think there is an emacs update available. It was just an example, not a strategy. <wdkrnls>oh, so you are saying that even if I pull it won't change either? <wdkrnls>I have to make my own emacs package then? <johnjaye>unmatched-paren: well i did something with virtualbox and lost all my save <johnjaye>so now i have to restart from scratch. doing guix pull... <nckx>AIUI this all comes down to a bug in ‘guix gc --verify=repair’, where it doesn't actually repair anything. It should have been that easy. All work-arounds, assuming we even think of one, are going to suck in comparison. <phodina[m]>what's the proper way to fix issue with sanity-check when it can't find the module e.g. 'wifite.wifite' which is part of the package? <nckx>wdkrnls: You can try pulling. But I don't think it will help. You got unlucky with gtk+ being corrupted of all things: almost everything depends on it, so it's hard/impossible to get rid of/GC, and it's not going to change upstream until the next core-updates merge. <nckx>.oO Then again, it's broken, so you must not be using much software that needs it. <johnjaye>is this like that meme with anakin and padme <wdkrnls>well, I will run guix gc --verify=contents,repair for the sixth time just to confirm that it thinks nothing is busted anymore. <nckx>johnjaye: Guix doesn't ‘use’ python, but it provides python 3 as a package. <rekado_>and Guix Past is where you can get Python 2.4 if you must. <nckx>wdkrnls: What I'd do, personally, is actually rm that 0-length library and the .links and then try that gc command. If it restores an empty file again, I have no idea where it's even getting one from. <nckx>It's ugly but it's what I'd do. <phodina[m]>rekado_: speaking of Guix and Python, what's the proper way to handle sanity-check phase? <phodina[m]>rekado_: yes, when I get that some module in the package is not found and the derivation fails when I'm attempting to create new one <wdkrnls>nckx: thanks, I'll give that a shot before I do the pull. <rekado_>phodina[m]: then maybe something is really wrong with your package? <nckx>Question: I'm mostly happy with paredit-mode, having forced myself through a learning curve, but the way it butchers #; comments is absolutely horrible. Is there a way to stop it from inserting nonsense (;) after each commented line? <phodina[m]>rekado_: Can't it be it just can find the module in the package itself? The package wifite2 works on other distros so I assume just he PYTHONPATH is probably wrong <phodina[m]>...trying to load endpoint console_scripts wifite: ERROR <nckx>‘Taiwan (Province of China)’ → ‘Taiwan’ <nckx>Guix does not take a position on that controversial claim. <wdkrnls>the_tubular: git log --oneline --follow -- gnu/packages/iso-codes.scm | head -n1 | awk '{print $1}' <wdkrnls>err... that's run inside of the guix git repo. *nckx wishes that were the default. <wdkrnls>It's all just way too hard... emacs no longer complains about gtk+. Now it complains about libatk-bridge... <nckx>But you managed to repair gtk+? That's good news. <wdkrnls>yeah, I suppose. Now I just wish guix gc --verify could be run as a daemon to just keep checking for missing files and I mv them about. It seems like guix isn't smart enough to see them otherwise. <wdkrnls>although, hopefully I am just imagining that. <nckx>Well, it's tremendously expensive to be that ‘smart’. <nckx>But it should definitely not replace empty files with empty files, that's of course a bug. <wdkrnls>after that one emacs actually started. yay! <nckx>wdkrnls: This returns 0 results for me, maybe it can help speed things up for you: find $(guix size emacs | grep ^/ | awk '{print $1"/lib"}') -type f -size 0 2>/dev/null <nckx>Glad to be immediately obsolete. Great! <nckx>What's your nick mean, if I may ask? <nckx>Obviously I read it as weedkernels, but that's your own fault. <wdkrnls>but I have been called "one big corn-fed [person]" owing to my size and Nebraskan heritage. So, the name sounded a bit remeniscent. <nckx>I hope that ‘high priority’ bug gets fixed soon. <vagrantc>hrm. guix refresh --list-dependent keyutils suggested i'd see ~50 builds ... but ci.guix.gnu.org is doing more like ~120 <vagrantc>oh yeah, there are "other" architectures... <nckx>Yeah, there's this thing called aarch64 I know you don't care about. <vagrantc>hrm. seems something failed dependency failed building this "gnome" thing. hopefully nobody uses that. <vagrantc>oh wait, that failed before i pushed a commit. not it! <nckx>Only new users with blogs. <nckx>Hm, scripts/extract-vmlinux has already vanished in the very next diffoscope update (215). <nckx>We can blame you for that if you'd like? <vagrantc>nckx: think it would be better to just revert the commit that adds it and then update guix ... or ... manually revert and push it in one commit? <nckx>It fixed a real bug, so even if the intermediate builds it's strictly ‘broken’, and you know the rule. <nckx>The Guix repository contains within it 3,431,987 brackets, both opening and closing. <nckx>After a second or two you'll notice that number is odd. <nckx>I suggest we add or remove one somewhere at random, just in case. <wdkrnls>Does your counting method exclude stuff in strings? <wdkrnls>oh... might be a joke... don't mind me just trying to get mu4e to work again, which makes me easily distracted... <nckx>My counting method was extremely unserious and primitive and did nothing clever, just grep for [()]. <vagrantc>nckx: wouldn't that only show the lines, not the match of parens? <nckx>Not if you use the right flags… <nckx>vagrantc: Thanks for the update! *vagrantc flys the cascadian flag <nckx>It is the most beautiful region if I had to choose one. <vagrantc>i love package inheritance. i grump package inheritance. <vagrantc>wait, groff-minimal has groff as an native-input? how on earth can that possibly reduce the closure size? <nckx>Remember our previous discussion? native-inputs aren't generally retained as references. <tribals>Finally get my channel working in manifest, authenticating my own commits! ^_^ <vagrantc>so, you still need the full closure size to *build* groff-minimal, but the resulting packages closure is smallerified <nckx>Without looking at the code: yes, that sounds accurate. <nckx>Now, I don't know why g-m exists, clearly not to reduce the rebuilds caused by updating groff proper… <tribals>The issue was that I didn't updated `.guix-authorizations` in fact, and used wrong commit for channel introduction. <podiki[m]>that paren/bracket odd number sounds like a fun/maddening rabbit hole... <nckx>Please don't take it seriously :) <podiki[m]>but it is the kind of thing to keep someone up at night... :) <vagrantc>some people develop immune responses to such things <nckx>One flaw in my rigorous — absolutely scientiscious — methodology was that I didn't grep only .scm files. <nckx>But, good news everyone: only .scm files? 1,671,227 brackets \o/ <vagrantc>if you add the two counts together it comes out even. problem solved. <nckx>How many copyright lines does ‘(unmatched parenthesis’ have? <podiki[m]>my guess is from string matching in substitute*, in fact I probably have some that only needed to match an opening ( <podiki[m]>or were only replacing the closing part of such a string <vagrantc>is disabling parallel building for gnucash worth it to get a reproducible build? <nckx>I just grepped for ( or ), for example, just tallying both together, not looking for pairs. <nckx>vagrantc: Sure, with a comment. <nckx>podiki[m]: There are 295 more (s than )s, and the number of )s is even. (substitute* … (("funcy\\(.*") "…"))) is one likely culprit, and this whole tangent was silly anyway. I'm sorry I brought it up. <vagrantc>"no dependents other than itself" ... music to me ears <podiki[m]>I remember having to do something to trick latex into being okay with mismatched parens when doing some manual multilign stuff <podiki[m]>maybe it was \shadow or something? not very fun to do <nckx>‘dependents other than itself’ implies things I could start another tangent on. <johnjaye>heh. i typed guix system reconfigure /etc/config.scm and it says warning make sure to run guix system reconfigure for latest updates <wdkrnls>glad to be back in ERC and out of irssi. <johnjaye>well i will get emacs as soon as i can guix upgrade <nckx>johnjaye: Heh :) At a glance, it looks like the procedure printing that warning has easy access to the current subcommand, so it should be an easy fix. For someone interested. <johnjaye>nckx: if you're suggest i do it i'm flattered. but i have no idea where the code is or where to even start <johnjaye>i'm even afraid to subscribe to mailing lists because my outlook account got flooded with thousands of messages the last time i tried that <nckx>johnjaye: guix/scripts/system.scm, and the guard is (unless (memq action '(build init)) — so it looks *really* trivial, but no pressure was intended. <johnjaye>that's fine. it's just people say things like "file a bug report" or something. and it's not that the task *itself* is hard <nckx>johnjaye: Hmm, that shouldn't happen :-/ <johnjaye>it's all the tooling, scripts, and setup *around* the task that's ahrd <nckx>'s What I meant really: if you ever need to set up git + send-email anyway, and want an easy test case… <johnjaye>oh right this is all on gnu isn't it. so not even github <johnjaye>so you have to like. send email to a email list <johnjaye>it is if my email inbox gets 5,000 messages the next day. <nckx>Say what you will, I regularly do both, and GitHub is the more tedious of the two. <johnjaye>what do you use for that. thunderbird or like a text thing <nckx>git send-email -<number of commits> ; done. After setting it up of course, but that's a 1-line default mail address in .git/config once you've configured your mail account in ~/.gitconfig. <vagrantc>seems a lot of ecl-* packages are not reproducible ... maybe even the majority of unreproducibility in guix <nckx>Vs. doing the Web thing and clicking what feels like 5 times. I know there's a ‘git hub’ CLI, but it broke twice for me over the years, so -1 for GitHub still. <nckx>johnjaye: For reading mail I use mu4e (emacs), but I don't do the magit/commit/send patches from within emacs thing. <vagrantc>hrm. data.guix.gnu.org seems to be havig a hard time $today *nckx removes the silly ‘reconfigure’ warning then, can't well keep it now. <johnjaye>by the way. to actually compile and use guix <johnjaye>can you do it from "inside" the os, or would one have to download compile and create a cd image boot from that and reinstall? <nckx>Uhm… I'm not quite sure what you mean, but most of us develop Guix on a Guix System. I have about 20 commits in my ~ that I haven't pushed upstream, but are part of my guix command & the running OS. You can configure guix to pull from a local (file://) git checkout rather than the official repository. <nckx>There are other methods too. *vagrantc is less confident about isl and gnucash parallelism causing reproducible builds problems *vagrantc has actually been doing guix development on Debian lately ... <johnjaye>nckx: meaning you are in guix and then pull guix and change guix and then reboot to get the changes you made to guix? <vagrantc>figured since i packaged the thing, i should at least see what i'm subjecting, er, making available to people <nckx>johnjaye: Yes, basically. <nckx>My only complaint is that guix pull is so slow. <nckx>Not really a complaint, that would imply having a clue how to improve it. <tomix>Hi, Hi all, I'm trying to get GNOME working on aarch64. Currently this is broken due to mrustc failing on aarch64, which is fixed in staging: 32a87714f4507f853824d82d9c6ca10e1405c8eb "gnu: mrustc: Update to 0.10.". When I build against staging, my machine is unable to find the build via substitutes, so I figure the build jobs haven't caught up yet, or this is failing on ci. When I look for this build <tomix>on ci.guix.gnu.org, I find no results for: "mrustc spec:staging system:aarch64-linux". <tomix>Does anybody know how I can find more info about this job, and why it's not in the build cache. Perhaps I'm using the wrong search query? I see the same query works for s/mrustc/gnome-terminal/ <tomix>mrustc-1.39 did, IIRC, but it took ~1 day, so it'd take too long for my underpowered aarch64 to build the entire chain of mrustc jobs. <nckx>staging isn't built continuously, sorry… <tomix>Sorry no, not mrustc-1.39. rust-1.39 built locally on aarch64. <tomix>nckx: Ah I see, no worries. Thanks for letting me know. I'll be more patient. :) <nckx>So maybe there's a deeper problem (oh goodie). <nckx>So you'll probably wait longer than I meant to imply. <nckx>(aarch64 == everything without hydra-guix or p9 in the name.) <tomix>The joys of working on less popular platforms. :) Shall I file an issue for this? <johnjaye>what does git format-patch -1 HEAD do exactly? <johnjaye>and why does it automatically put someone's email into the CC box? <tomix>johnjaye: IIRC, it'll CC emails that are tagged with "Co-developed-by:" in the commit msg, and possibly others. Your gitconfig might be adding some too. <johnjaye>hrm. so i did that git format-patch command <johnjaye>the file it created has a From: <bob@project.com>, then Date, then Subject: Patch: Fix memory leak <nckx>tomix: Intuitively, I'd send a mail to guix-devel@ instead. <vagrantc>is the running kernel version normalized by guix-daemon ? e.g. uname -r ? <vagrantc>ok, so embedding uname -r outout in is a plausible reproducbility issue. check. <johnjaye>so if i make a .patch and send it with git send-email, does it CC anybody in the From: heading? <nckx>vagrantc: Yes. Uname in general is a bad idea, since literally every field except (GNU/Linux) (and the arch, fine) is supposed to be local. <nckx>Now, I don't know if the hostname is virtualised in the container. <vagrantc>nckx: yeah, i know uname is generally bad for and have many a patch to my name encouraging people to ... not do that. <vagrantc>even uname -s is a little bad ... you could be crossbuilding from a different kernel <vagrantc>though admittedly i mostly look the other way with uname -s <nckx>johnjaye: I don't know (just test, don't trust anyone's answer), but the man page mentions --[no-]suppress-from whose default value seems to imply ‘yes’. <johnjaye>i don't see that in git send-mail info page i'm on <johnjaye>maybe git send-email normal behavior is to CC you a copy of your own patch? <johnjaye>i think i'm missing something basic here <nckx>I'm looking at a man page, not an info page. <johnjaye>i ran git format-patch -1 HEAD to generate the test patch. then did git send-email --to=myemail file.patch <johnjaye>it did email me. but it CC'd the person who did the last commit 4 hours ago on this project <nckx>According to this man page it should ‘confirm before sending when send-email has automatically added addresses from the patch to the Cc list’. <nckx>Have you found/read the man page yet? git send-email is extremely configurable, just because I use it doesn't mean I know all it's warts and secrets. <nckx>That said, you shouldn't need to. It's always done broadly what I meant/expected. Not CC'd my aunt. <johnjaye>hrm. let me look. i'm on the webpage manual <johnjaye>ah it says The Cc list above has been expanded by additional addresses found in the patch commit message. <johnjaye>which still makes no sense. because wouldn't normally you yourself be the source of the message? so it's adding yourself to the CC automatically based on the file? <johnjaye>oh wait lol the output literally says that's what it did <nckx>I should have looked at my ~/.gitconfig sooner (I really had no memory of this): ‘suppresscc = self’. <nckx>So I clearly thought the same thing you did, once. <vagrantc>CCing oneself in case you're not subscribed to whatever lists it is going to doesn't seem so bad. <vagrantc>e.g. you'll at least have one copy of your patch in your email :) <johnjaye>urggggggh I added the --suppress-from and it STILL added it <nckx>I don't want that, but if there's one thing we know about e-mail, it's that every single person wants it slightly differently and will murder you if you disagree. <nckx>johnjaye: Try --suppress-cc=self. The config options map to command line options, except when they don't because that would be boring. <johnjaye>because it's CC'ing the person that made the last commit. which isn't me <nckx>Wait. Are you sending patches made by others? <nckx>That's fine, but it's not (IMO) odd that git CCs them by default. <johnjaye>ok fianlly. i figured out that --suppress-cc=all seems to do it <johnjaye>nckx: yes. but that's precisely what i asked <nckx>‘Made the last commit’ is a strange way of saying ‘wrote the patch I'm sending’. <nckx>All right, glad it worked. <johnjaye>sigh. well this is obviously more complicated than i thought. i guess i'll return to this later. thanks for the help! <vagrantc>i also am a fan of "git format-patch ..." followed by attaching the *.patch files it generates to an email in your favorite email program... <emacsomancer[m]>are there examples of modifying a package definition on the fly? (I wanted to add in a make flag to the flatwhatson nativecomp emacs definition to bulid with xwidgets) <apteryx>what... "/gnu/store/fg2cf9w9dvxin6nycbfjpbmpg8sdbk80-grub-2.06/sbin/grub-install: error: sector sizes of 1 bytes aren't supported yet." <bdju>why was the chirp package removed? does anyone know? it was for configuring radios <bdju>is there any reliable way to figure out what is pulling in a dependency? I do not want to build webkitgtk but skipping it on its own doesn't work <bdju>it's probably nyxt. I'll find out soon if it was nyxt. but that was just a guess <bdju>nope that didn't do it.... god I hate that this is constantly a problem. my PC is unusable when building these large packages and they take more than a day to complete <bdju>ideally I could mark something in my manifest and they would never built, always skip if not available, then just keep updating normally instead of trying to work around the problem <jackhill>bdju: python2 and dependen packages were recently removed. python2 hasn't been maintained by the python developers for many years. I believe that there has been some work done on a python3 port of chirp, but it is not completed <bdju>oh okay. thank you for the info! <jackhill>:) I, too, wish to see chirp return some day <sammm>hey, quick question - i am defining a package and I need to use the trivial-build-system, I have defined my inputs but when I (invoke "node" ...), I get exit code 127 (command not found I presume). Any idea why wouldn't be available while building? <vivien>samm, are you sure node from (gnu packages node) is in the native-inputs? <sammm>ooh, I was using just `inputs` <sammm>same issue though, invoke-error with exit code of 127 :^( <roptat>sammm, probably because the trivial-build-system doesn't set PATH or any variables <sammm>ah, that makes sense, i'll put the bin path into a var then <lilyp>trivial-build-system is really trivial; you most often want copy-build-system in its stead <sammm>I'm trying to build jellyfin which requires running yarn/dotnet build, can copy-build-system run arbitrary build commands? <lilyp>you can add build phases just like with other commands <lilyp>(add-before 'install 'build (lambda _ (invoke ...))) <lilyp>though chances are if it's dotnet that you won't have the dependencies, at least not for clean packaging anyway <zamfofex>sammm: I tried to investigate bootstrapping .NET before. For every commit, they have a list of dependencies specified to the commit level. So even though e.g. Roslyn indirectly depends on itself, it depends on an earlier version of itself (whose commit is specified in an XML file in each commit of the repo). <zamfofex>The problem I ran into is that even after following that list all the way down, the earliest available versions were built using builds before .NET became free software. I tried using Mono to bootstrap for a bit, but eventually moved on to other projects. <sammm>zamfofex: that sounds painful - I really picked a PITA bit of software to package <lilyp>could be worse; try anything related to scala <unmatched-paren>oh, wow, they also include loads of easily-bootstrappable dlls??? *slow clapping* <sammm>going to give the packaging a break for today, have learnt a heap tho <sammm>my goal is to run my new supermicro rackmounted server on guix system, so i will stop at nothing until it has jellyfin/zfs (done)/game servers for killing floor etc *unmatched-paren looks up jellyfin *unmatched-paren sees jellyfin *unmatched-paren thinks jellyfin looks like the kind of project that would have a gazillion dependencies and possibly binary blobs <sammm>maybe i'll just run the bloody thing via containerd if it gets too gnarly <sammm>would love to compile it tho <PurpleSym>phodina: Are you still having trouble with 'sanity-check? Could you post the package definition please if so? <pashencija[m]>`gnu/system/install.scm` includes `(service uvesafb-service-type)` in `%installation-services` <nckx>unmatched-paren: That was a wild ride. The $0…$2 at the end was sheer genius. Well done. <nckx>/home/nckx/guix/gnu/packages/sml.scm:83:2: warning: package 'smlnj' has no source <nckx>Even Guix can't resist being salty about how blobby this thing is. <nckx>Well, this one clearly isn't. I found a build timestamp in the REPL, thought ‘I'll just quickly patch that out’, end up in a dumped heap image. There's corresponding source (we'll assume, generously) but it's never used by our build and you can patch it to say ‘dingdong’ with no effect. *nckx doesn't actually know, but doesn't mind. <unmatched-paren>in case anyone says "but f# is good": it's just ocaml with extra dotnetty syntax <nckx>I'm not saying this to trigger anyone, but as a complete outsider: it doesn't look *that* different from what Python looks like to me… <nckx>The .sln file reminds me of Android build system XML but with extra Microsauce. <nckx>Both seem to me reactions to ‘oh dear, our ‘‘‘source’’’ tree is 32.8 GiB, how can we enable this rather than rethink it’. <unmatched-paren>no, it's "how can we obfuscate this 'source' but still claim it's open" :) <nckx>unmatched-paren: ‘to me’. If you really know Python and/or VB I'm sure the effect goes away. <unmatched-paren>Also The Code Looks Like The Title Of Some Clickbait Article Because Of All The Caps [pics] <nckx>I don't even have a mental image of what Ruby looks like so poss'. :) <nckx>Anyway: you implied you surveyed the ML bootstrap landscape a bit. Which one was the least worst in your experience? <unmatched-paren>nckx: https://github.com/i4ki/awesome-sml <- i looked at "Implementations" here and briefly at each source repo. when i found one that wasn't self-hosting i checked the features to see whether it would be enough to kick-start the bootstrap. that's basically all i did :) <nckx>Well, polyml's in Guix, mlton isn't [under that name anyway]. *unmatched-paren guix edit polyml <nckx>…it is suspiciously short, so unless their Makefile does a full bootstrap for us I'm fearful. <nckx>At least guix build --source does something on this one. <nckx>This doesn't look too bad. <nckx>Yes, I think, interpreted. <nckx>Then come the (legit source) Stage*.smls. <unmatched-paren>so i guess all that's needed is an alternative compiler, maybe translating this one to OCaml 4.07? <unmatched-paren>then we'd try to compile mlton with polyml. sml/nj looks a bit daunting. *unmatched-paren cloning mlton inside `guix shell polyml` <nckx>‘I reject your bootstrapping problem and substitute my own.’ <nckx>You've gone so much deeper than I intended. I'm just figuring out which SMLNJ binary blob to patch, job done. Not that I mind. <tribals>Can I use inverior packages at "build time", in place of g-exps? <unmatched-paren>might have to bend over backwards to get it to compile one of the MLs <iyzsong[m]>tribals: i think yes, an inferno package is a gexp lowerable thing, same as a package. <zamfofex>nckx: Maybe VB’s syntax reminds you of Python because of the lack of semicolons? Note that syntax apart, they are very different semantically. Python is dynamically typed, whereas VB is not. VB is basically just C# but with a different syntax and perhaps fewer language features (for better or for worse). <nckx>Yes, it was meant to be the most superficial likeness imaginable. I have never, nor can I imagine I ever will, used .NET or Virtual Basic or C#. I barely scrape by monkey-patching existing Python packages. <zamfofex>Also, note that I don’t really like .NET and C#/VB. I’m the kind of person who thinks C is enough for most tasks. Though I also really like JavaScript and Haskell/Agda, so you could also say I’m very undecided! 😅 <nckx>(And C♯, for good measure & an excuse to use my compose key.) <nckx>Now this Haskell I want to learn. <zamfofex>I’d be more sympathetic about Haskell if Cabal/Hackage/whatever didn’t suffer from “npm‐itis” so much. I’ve also come to conclude that Haskell (and Agda for that matter) is difficult to learn (just because there are so many different emergent concepts), but then reasonably easy to use once you learn it. Well, Agda never got “easy to use” for me, but maybe that’s just because I haven’t gotten past the learning phase <zamfofex>(And of course, Agda is specially difficult to learn, because it has a few magnitudes more such emergent concepts than Haskell.) <nckx>Hah. That jives with my initial impressions. <nckx>I've chosen to disassociate languages from their blessed package/module systems to stay sane, and to be able to try any new language at all. <singpolyma>Hackage packages are built from distributed source, unlike npm, so not the same problems at all <zamfofex>singpolyma: Well, it definitely makes it easier to bootstrap and perhaps to package, but it still has the same issue of “facilitating adding dependencies too much” that makes people careless about adding too many dependencies. <singpolyma>No such thing as "too many dependencies"...? Unless you have ones you're just not using or something <singpolyma>Much worse is bad discoverability in some ecosystems which results in every project reimplementing the same thing <zamfofex>I think the problem is that it is a fragile practice. Generally adding a dependency also adds a potential for your program becoming unusable in the future if the dependency (or the reference to it) goes away for one reason or another. If you have few large dependendencies, this isn’t a problem that matters at all, because that danger is very small. But as the number of dependencies grows, the problem grows exponentially. <zamfofex>I say “exponentially” because the number of *transitive* dependencies itself grows exponentially as the platform facilitates adding dependencies. <singpolyma>Well, that's why we have package repos, so that the maintainer getting bored won't cause the package to go away. And even better we have guix, so even if hackage itself goes away things could work out <zamfofex>The URL is the screenshot of a conversation I held with a friend of mine a while ago. Note that the last point is also noteworthy. In particular, once people stop caring about the cost of dependencies, they start to create packages with reduced scope that do fewer and fewer things over time. Instead of grouping related functionality in a single library or simply rewriting small functions across projects. <singpolyma>Right. Sounds great. More granularity so more reuse, less wasted time and library bloat <zamfofex>I think it’s nice to an extent. Once people want to create packages for single‐line functions, to me at least, it stops sounding so nice. <zamfofex>Hello, civodul! I have been meaning to ask you something: Has my message regarding the update to glibc reached you? I’m a bit stupid regarding email, so I managed to fail to get it to show up on the debbugs page once again (see <https://logs.guix.gnu.org/guix/2022-05-28.log#014407>) but I hope it at least managed to reach you and perhaps Maxime. Should I resend the email such that it appears on debbugs, or does it not matter? <nckx>zamfofex: I've sent you a PM. <tribals>Another question: how `patch-shebangs` supposed to work? I'm trying to write simple package consisting of script with source as `(plain-file ...)`. I listed script's interpreter as package inputs, it builds successfully but shebangs hasn't been patched <nckx>tribals: It recursively searches through the source (strictly: current working) directory for files starting with #!, then substitutes the full store file name of each interpreter it finds that's in $PATH. <nckx>If it doesn't find $(basename interpreter) in $PATH, it leaves it untouched. <nckx>(Is it $PATH or search-{native-,}input-file now? I forget, but the principle is the same.) E.g. ‘#!/usr/bin/env python’ will be patched only if you have python-wrapper as a {native-,}input, not otherwise. <nckx>If some script does ‘echo "#!/bin/sh" > newfile.sh’ somewhere halfway its code, that also won't be patched, only real shebangs. <tribals>So, if I'm using `(plain-file ...)` as a whole package's source, what is the correct way to specify shebang? Using interpreter's gexp? (prevent patching in the first place, it suppose) (how to specify interpreter an input, though? input? native-input?) Or, what is correct way to specify shebang so it will guaranteed to be patched? /bin/interpreter? (Personally, I don't want to rely on /usr/bin/env) <tribals>(What is mentioned `python-wrapper`?) <tribals>Sorry if it is too much question, but I failed to find this information in docs (and I'm not familiar yet with sources) <nckx>One solution is to add your custom phase before the default patch-shebangs phase, if possible. Otherwise, I'd write something like (lambda* (#:key inputs #:allow-other-keys (with-output to blah (format … "#!~a" (search-input-file inputs "bin/interp")))) if the script is meant to be installed, or use native-inputs if it has to run at build time. <nckx>Hope that shitty pseudocode is clear :-/ <zamfofex>nckx: Won’t it patch ‘#!/usr/bin/env’ to coreutils’ ‘env’ instead of to Python? <nckx>tribals: A very thin wrapper around the python (3) packages that adds a python → python3 symlink. The default python package only provides bin/python3. <nckx>It's clever enough to remove the /usr/bin/env entirely. <tribals>nckx: Oh, I see... That's very good solution, IMO :) <tribals>I'm also not sure I get a inputs/native-inputs difference clearly. <tribals>Or, this can be rephrased as: If I list `python` as package inputs, will it be in `$PATH`? (So, it could be patched by patch-shebangs phase) <tribals>Now I see: it will. This information is printed directly when you do `$ guix build ...`. Sorry for question. <vagrantc>oh wow, autogen still builds with guile-2.2 ... <civodul>mbakke: you around? i tried but failed to fix timescaledb's test phase on 'staging' <civodul>apparently postgres is looking for timescaledb.so in $PWD <civodul>and i don't know how to make it change its mind <nckx>What should I do if ld.so.cache retains a reference to a native-input, but there don't seem to be any ‘real’ references? <nckx>In this case, it's gnome.scm's five-or-more package, where I'd make libxml2 a regular input if I didn't suspect… shenanigans. 🦇 <civodul>nckx: weird, it's unlikely that ldconfig would make a mistake, are you sure none of the installed binaries refers to libxml2? <nckx>Weird: libxml2.so.2 => /gnu/store/g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12/lib/libxml2.so.2 (0x00007af6652ca000) <nckx>How can a binary do that without having ‘libxml’ in it? Can it be transitive? <nckx>Wouldn't that imply that we were missing references before ld.so.cache magic was added? *nckx wishes you could ‘guix gc --references’ individual store files, although it'd probably be a footgun. <nckx>(No it wouldn't imply that, necessarily.) <phodina[m]><rekado_> "phodina: then maybe something is..." <- So I found out the enitre wifite package uses relative imports. Is there a way how to fix this in Guix? <lilyp>nckx: perhaps pkg-config propagations? <vagrantc>guess i could download the .json and manually parse it... <phodina[m]><phodina[m]> "So I found out the enitre wifite..." <- Never mind, I found some fork in the PR which works and has this fixed. So switching the uri and sha256 builds working package <tribals>Another question: is $GUIX_PROFILE supposed to be exported "constantly", or it is an one-off hint? Eg. you need to source guix profile's `/etc/profile` somehow - but you don't need to export anything for it to work? <KarlJoad>Is there anything fancy I need to do to install a font to my home-profile through guix home? Adding fontconfig, for example. <lilyp>KarlJoad: there should be a service type that works for the home profile (and none other) <jpoiret>lilyp: sorry for the commit message, I had to write it without magit :p <jpoiret>writing that commit took a long time without my tools <nckx>jpoiret: How do magit/your tools help you write commits faster? Whisper me your secrets. <jpoiret>writing multi line commits on CLI was weird <lilyp>you can still use magit-less emacs as EDITOR <nckx>You don't *have* to use -m. <singpolyma>Magit is nice, but for some reason when used as editor for git add -p it becomes unusable and won't use evil mode <civodul>nckx: ld.so.cache is transitive indeed, but we were not missing any references before; rather we were just storing direct references, and now we're storing both direct and indirect references <ulfvonbelow>it seems that 'guix environment' doesn't honor --system <vagrantc>grrr... maradns insists on embedding the timestamp ... i cannot figure out where it's getting it from ... it passes it on the compiler commandline and then proceeds to ignore it. hrm. <nckx>ulfvonbelow: Rather, its value is (incorrectly) not part of the cache key, so you need --rebuild-cache. <nckx>Explains how it snuck in unnoticed. <ulfvonbelow>even with --rebuild-cache it's still building as x86-64 instead of i686, despite --system=i686-linux <foobarxyz>Hi, does guix provide any facilities/conventions/guidelines how to reference the jar of an installed java library? I would have thought that java packages would have augmented the CLASSPATH env variable, but this doesn't appear to be happening <nckx>Strange, (guix scripts shell) obviously tries to key SYSTEM. <foobarxyz>For the sake of an example, the java-mxparser package includes a jar package that will end up in ~/.guix-profile/share/java/mxparser.jar. Do I have to manually include this in the classpath, if I say I am developing a java library that uses that jar? <ulfvonbelow>tried building a package that errors out in the configure phase when built without --system=i686-linux with a message that it doesn't support 64-bit, and doesn't do that when built with --system=i686-linux (as passed to 'guix build'), tried creating an environment with it, build log contained said message <ulfvonbelow>I guess in theory it could be some other behavioral difference between 'guix build' and 'guix shell / environment' <nckx>OK. I just ran “guix shell --{system=i686-linux,rebuild-cache,pure} file bash -- sh -c 'file -L $(command -v sh)' “, and it works (both for i686 and aarch64). <ulfvonbelow>./pre-inst-env guix shell --pure --rebuild-cache --system=i686-linux pcsx2 *vagrantc has an aha moment with maradns ... it thinks it's building from git ... which it sort of is ... which triggers a different version path... <nckx>Substitute string=? for eq? I guess. It's been too long since I've Schemed. But the value's never other than x86_64-linux anyway. <vagrantc> ... # Since some systems may not have /dev/urandom (Windows, *cough* *cough*), we <vagrantc># keep a randomly generated prime around <nckx>Guix adds an explicit (system . "x86_64-linux") after (system . "aarch64-linux") to the list of options parsed in profile-cached-gc-root o_O <nckx>Guaranteed through a fair dice roll to be random. <vagrantc>and everybody who downloads the same binary has the same random. <Guest568>My bios uefi have a 3 OS in boot override. I can't load any OS because start grub rescue mode. Generally i wanted to have one OS. What to do with it? <nckx>vagrantc: You wanted reproducibility. Now die in it. <vagrantc>nckx: i take no responsibility for terrible design decisions of random software :) <vagrantc>randomly generated at build time? what could possibly go wrong <nckx>vagrantc: Does just ,version not work? <vagrantc>nckx: it certainly doesn't work without using it! *nckx found out where the extra bogus system comes from… now to find out why. <fnstudio>hey! :) i can use "guix edit bash" to access the relevant package definition (if i'm using the correct terms); is there something similar for "guix system" <fnstudio>"guix system edit login" doesn't seem to work <nckx>fnstudio: Update your Guix? <fnstudio>hmmm how new are we talking about? i can't see "guix system edit" on 8334e7c either, although i guess i might be missing something else, i might be using the wrong syntax *vagrantc taunts maradns with reproducibility <nckx>You really need to pull. <fnstudio>uh, i think i pulled/upgraded that guix yesterday... does it mean it's newer as in "from today"? more likely i'm missing something on how updates are brought in <nckx>Well, pull first, then we can see if there's anything to explain or debug :) <nckx>It was written 34h ago but no idea when pushed. <fnstudio>oh! that's so hilarious and what a concidence! a feature gets added the very same day i look for it <nckx>Oddly lucky. Did you save the life of a old oddly-dressed woman lately? <nckx>Could you wish for npm support please? <unmatched-paren>could you please wish that FAANG release all their software under the AGPL3.0? <fnstudio>ahah this guix system edit is going to cost me dearly! *vagrantc scorns maradns again <zamfofex>tinybronca[m]: I don’t know Nix, but usually Guix’s answer is to use grafts. Of course they don’t solve all the problems because a security vulnerability can still creep in unnoticed, but that’s true of most pieces of software. <tinybronca[m]>I never heard of "inferiors" nor seen this word looking at package defintions <unmatched-paren>"Sometimes you might need to mix packages from the revision of Guix you’re currently running with packages available in a different revision of Guix. Guix inferiors allow you to achieve that by composing different Guix revisions in arbitrary ways. <unmatched-paren>and then you can do (lookup-inferior-packages inferior "PACKAGE-SPEC") <unmatched-paren>the inferior is just a revision of guix that you have pulled alongside your main revision <Guest521>i have installed devuan succesfully, but later decided install guix and <Guest521>after that that ploblems out (cant boot in system, because start only <Guest521>grub in rescue mode). After that i installed debian from live usb, but <Guest521>it not help - grub in rescue mode yet. Later i see that in bios boot override i have these 3 OS. How uninstall these OS from system? <vagrantc>well... this is a new one $ ls $(./pre-inst-env guix build maradns) <vagrantc>ls: cannot access '/gnu/store/2rvgcsfcca05536fzzyfzhcgy7mk925s-maradns-3.5.0020': No such file or directory <vagrantc>guix build spits out something, but it is not added to the store <fnstudio>here's a question re service extensions... i put together a system definition that allows me to boot a blank/vanilla server with the bare minimum (eg ssh)... <fnstudio>i was thinking of using that as a base-image.scm definition <fnstudio>and then to extend it via service extensions and into, say, a web server definition, a gemini server definition, etc <fnstudio>is that what service extensions are meant for? would my idea even work or make sense at all? <fnstudio>actually i don't think i'm making sense... i'd be looking for a way of extending/inheriting from an operating system definition, as opposed to a service <civodul>fnstudio: you can write (operating-system (inherit that-other-os) (services (append ... (operating-system-user-services that-other-os)))) <civodul>that one way to define an OS variant that adds services on top of those of 'that-other-os' <fnstudio>cool, so i can define a base os and then extend it in the direction that's needed on a server by server basis for example, great <civodul>you can even write a function that takes an OS and returns an OS with additional features, say <vagrantc>hah. there was a build failure, and it successfully built a package with nothing in it that would be installed at some path it then reported ... <fnstudio>so far i've defined simple OSes for then passing them to "guix system image os.scm" <fnstudio>when i want to define a OS for later extending it, is it just a matter of (define my-base-os (operating-system ...))? <fnstudio>and then if i still want to build it, i do "(define my-base-os (operating-system ...)) my-base-image", i suppose? <fnstudio>sorry, this is really scheme 101, as opposed to guix... <fnstudio>yeah, it looks like i was on the right track <fnstudio>now i wonder whether operating system definitions should all live in separate files or if i can keep some of them together <fnstudio>in the latter case, if that's a possibility, how do i tell "guix system image my-oses.scm" the specific OS i want to build? <zamfofex>fnstudio: Something like ‘guix ... -e '(include "my-file.scm") my-os'’ should work. <fnstudio>zamfofex: it doesn't seem to work straightaway with include, i might be using the wrong path, but you definitely put me on the right track, i'll figure out the minor details <sneek>maximed, you have 1 message! <sneek>maximed, nckx says: Thanks! I've switched the Cuirass URL back to yours. Have fun. It polls every 15 minutes. HMU if that needs to be tweaked. <maximed>That was a complicated one with static libraries, ffi, C calling Rust and some Rust libraries being passed to gcc from a Makefile <zamfofex>fnstudio: Maybe you have to use ‘define-public’, though I’m not sure. 