<nckx>klm: I can't trigger the error anymore, at least. You try :) <klm>nckx: thanks :-) running guix pull now, I'll report if the issue's still there. off to sleep. <pkill9>just seems to redownload all the packages i specified, havent updated guix, and shouldnt be garbage collected as 8t's in the guix home peofike <gnucode>I think I am going to try storing my yearly agenda that way <pkill9>unmatched-paren: it doesnt do it the second time ommedoately after, it's after i run guix gc, which doesnt make sense as it shouldnt be garbage colldcted as it's in my guix home profile <pkill9>unless it's keeping the grafted packages and removing theboriginal, and it depends on the original? <Cairn>Just read the note about p2p substitutes in the manual. That'd be such a cool feature <pkill9>i guess for now the solution os to avoid garbage collection, lol <yuu[m]>given https://dpaste.com/3NYL32JZF. is it possible to recursively use `file-systems` in `(dependencies (filter (file-system-mount-point-predicate "/") file-systems))` like that? <yuu[m]>or is there an alternative solution? <yuu[m]>or is the only way appending/cons in whole separate (file-systems ...)? <yuu[m]>i'm mean it's lisp/fp, probably there's a way to do recursively? can't connect to guile channel to ask in there <pkill9>maybe there cvould be an option to keep the ungrafted packages from being garbage collected, since guix deduplicates everything in the store <pkill9>i think what's basically happeneing is guix rebuilds the original package just to find out what the hashf or the grafted package is <pkill9>rekado: any idea why `guxi home reconfigure home.scm` rebuilds a loads of packages specified in my home.scm after I garbage collect and nothing has been removed from my home profile and I haven't updated/changed guix? <vagrantc>and the only two builds that succeeded so far are aarch64 ... that's new <vagrantc>guess that's across 4 (3?) architectures <pkill9>does anyone ahve an example of defining a command in guix/extensions? ***Xenguy_ is now known as Xenguy
<acrow>vagrantc: note tzdiff is not packaged for guix. Your comments on undertime made me look. :) <podiki[m]>probably git, dune, libselinux, ...seems a bunch of upgrades at a similar time <haruno1>So after deleting ventoy I tried burning iso to usb via rufus and poweriso as bootable and the stick is detected but instalation isnt starting, acting as if no media found on device. Did I miss something in preparation? <pkill9>also where in guix home config filedo I specify environment variables? <haruno1>seems making it as dd image helped, lets see if install works :D <haruno1>So the dd image is booted and and this time all is fine with usb and then during installation I get <haruno1>substituteL ice-9.scm 1685:16 in procedure raise-exception: guix-system: error: /gnu/store/....../guix substitute died unexpectedly. guix system init --fallback /mnt/etc/config.scm /mnt exited with value 1 <haruno1>in procedure write_wait_fd: unimplemented <podiki[m]>nckx: if you are conscious (or via other means??) kick ^ <conjunctive>Hello, when packaging a standard C project (i.e. with gnu-build-system) located within a sub-directory of a git repo, how do I tell Guix to "focus" on the sub-directory? In this case, all other directories are effectively noise. <acrow>conjunctive: IIRC there may be a #:source-dir argument key that you can use to target that sub-directory for the build. <conjunctive>acrow: Thank you! I noticed that there was a kw argument for the unpack proc. After looking through other package definitions, decided to just add a chdir call as a build-phase for the time being. <acrow>conjunctive: Glad to offer suggestions. chdir may well be the right way to handle it. Good to see others leveraging guix's software freedoms. <Spawns_Carpeting>are there signatures for the various downloads provided at gnu.guix.org? <bdju>can someone update the pfetch package to a newer commit? the author seems allergic to doing new releases and there are some missing features in the current guix version <bdju>I'm also curious if we have the new minetest 5.6.0 yet. I'm doing a guix pull now <lilyp>p sure minetest is still on 5.5 <gnucode>i'm having a doosie of a time trying to get nginx to accept gnucode.me/agenda/index.html to render the file located in /srv/www/html/gnucode.me/agenda/index.html <gnucode>I am getting a 404 not found error, which is very weird. <silicius[m]>gotta ask. Is it ok to use one-use variables in guix source code if it makes the code more readable and not go over the 80th column? <unmatched-paren>hmm, problem: my aerc patchset v6 uses ungexp in the go-notmuch snippet <unmatched-paren>yet, if i don't do the changes in a snippet, they won't be propagated to dependents <unmatched-paren>(I need to patch the paths in it to refer directly to the notmuch store path) <lilyp>unmatched-paren: did you forget to import (guix gexp)? <unmatched-paren>but apparently (snippet) that refers to a package is bad because the source needs to be arch-independent <lilyp>oh, yes, you shouldn't embed store paths or the like <unmatched-paren>but if i use a phase i'll have to reapply the changes for dependents, like we do for a few rust packages (see alacritty) <lilyp>can you split the work so that the phase is just a substitute* or is it already just a substitute*? <lilyp>in that case you'll have to suck it up, I'm afraid <lilyp>as far as I'm aware all our recent "rust bundles this and that" are only raised thanks to efforts in antioxidant-build-system *unmatched-paren searches for "how to repel gophers" <antipode>x86_64-linux builds seem stuck at ci.guix.gnu.org <nckx>Yeh, I was just lookin'. <antipode>Though maybe emulated aarch64-linux in the other jobsets have precedence over the x86_64 antiox jobset ... <nckx>There are no x86_64 builds happening at all. <antipode>unmatched-paren: There was some bug report on some Go compilaation cache, our go-build-system used to reuse intermediate build artifacts but the interface for that broke after a Go update <antipode>unmatched-paren: so it shouldn't be much work, compared to antioxidant <antipode>unmatched-paren: I would still give a post-unpack substitute* a try. <antipode>IIRC, the source code is copied some time after unpack <antipode>so dependents should be picking up the patched source code, though I'm not 100% sure about that. <lilyp>antipode: if post-unpack doesn't work you can still try pre-configure <nckx>podiki[m]: Thanks for the ping! Oddly, I was fast asleep at 04:13. <nckx>(Not sarcasm. It *is* odd.) <nckx>rekado: Node 125 (141.80.167.182) seems down (‘no route to host’), I had to comment it out to get ‘guix deploy’ to finish. <silicius[m]>Weird. My python-mpv package can find the mpv library (libmpv.so) during test phase but not later. <antipode>In procedure mkdir: No space left on device <nckx>Is that node hydra-guix-116 by any chance? <nckx>Oh, we don't log that, perfect. <silicius[m]>Can I hardcode the library's path? There are three files libmpv.so{,.1,.1.109.0} but the first two are links, so I would use libmpv.so and remove the need for python to search it on runtime <lilyp>in fact, we hardcode most libraries – use the unversioned so-link for maximal rebuildability <nckx>If ‘sudo herd status’ lists ‘ssh-daemon’: ‘sudo herd start ssh-daemon’ (or ‘restart’), but it would be unusual that it stopped. Otherwise, add ‘(service openssh-service-type […])’ to your operating-system's services field. It can be configured with (openssh-configuration …). See manual. <pkill9>though it normally starts automatically <nckx>In fact it's hard not to make it do that. <pkill9>manual desceibing guix home says "The first script that needs to be sourced is setup-environment, which sets all the necessary environment variables (including variables declared by the user) ", but the page doesn't say how to declare envoronment variables, so how do you do this? <nckx>apteryx, rekado: I had to manually run guix gc on hydra-guix-116, its / was full. Not sure why. <nckx>apteryx: My key doesn't appear to be authorised on the build nodes. I thought you mentioned doing so a while back? <vldn>any1 built an Android-Kernel with Guix yet? <silicius[m]>just tried to build guix from source, it complains there's no code for module (semver) <pkill9>more awareness needs to be brought to the info command, it has much power <pkill9>the tyrany of web browsders has manuals ina chokehold <unmatched-paren>silicius[m]: You just did `guix shell -D guix` and then `./bootstrap && ./configure --localstatedir=/var && make`? <unmatched-paren>silicius[m]: You need guile-semver, run the build commands inside `guix shell -D guix` to get all the dependencies <silicius[m]>I know, I'm doing that. Though now I see the problem was my changes that I just merged, but they're just packages so it shouldn't do that <nckx>pkill9: Random, but true. <nckx>An info viewer that follows a few more contemporary conventions might be nice though. There's nothing objectively wrong with ‘l’, but *nothing else uses it*. No, eww doesn't count. <nckx>A newbie would have more success hitting keys they find logical in lynx, than in the GNU info viewer. That's a pity. <unmatched-paren>there is pinfo, but it's unmaintained and seems to be a bit of a cludge <silicius[m]>I was stupid and left a merge conflict in a file. Errors were entirely unrelated to the core problem <unmatched-paren>silicius[m]: "entirely unrelated errors" are quite common in Gui{le,x}, sadly. <silicius[m]>yeah, it's kinda hard to debug. I really wish the debugging was like in cl <unmatched-paren>sometimes it will even refuse to tell you where a syntax error is :( <pkill9>where do ya'll backup your system configs and general data to? <pkill9>i shoudl back up to my phone actaully <pkill9>at this point it's like horcruxes <silicius[m]>I started bundling the system config, home config and a personal channel together into one git repo and then it's a matter of uploading it somewhere <vldn>syncthing them to different locations? <pkill9>what if it breaks and they lose all your data <silicius[m]>@pkill9 you should probably have a local backup (eg your phone or some usb stick) and a remote one anywhere you have access to. <pkill9>i was thinking of a ipfs store of everyone's configs <pkill9>so everyone backs up each other's configs, lol <pkill9>not much different concept from p2p static websites <unmatched-paren>i don't think sr.ht's backups failing is a situation i need to prepare for. it would be incredibly unlikely <pkill9>as long as people don't abuse it heh <unmatched-paren>also, since a lot of people (including me!) are paying customers, they aren't just gonna lose our data <pkill9>but that's why you'd have a chain of trust I guess <loosh[m]>how do i enable os-prober in bootloader config <nckx>I don't think that's supported at all. <nckx>You can use another distribution's GRUB (or install it by hand, it's not that magical) and ‘configfile’ Guix's grub.cfg though. <nckx>You can ask Guix not to install the boot loader part of GRUB but only maintain the grub.cfg menu using (bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(const #t)))))) <nckx>I just love quoting that in full. <nckx>unmatched-paren: Thanks for the point towards pinfo. Yeah, that was my understanding of it too, but I'd honestly forgot about its existence at this point. <unmatched-paren>nckx: Yeah, the latest release didn't build, so I had to send a patch to update it to the latest commit. <unmatched-paren>It's just x-tools with a few values changed to make it build gopls instead of the library. *unmatched-paren just realized that the description has only one space after a sentence <nckx>(go)pls don't add packages to the end of files, there are better ways even in unsorted messes. <nckx>So (why) should(n't) this be called golang-org-foobiz-booples-gopls? Or be an output of the go-golang-org-x-tools package instead of a separate package? I have no idea either way, just trying to learn. <unmatched-paren>nckx: (1) because it's a binary package, not a library, (2) I think it might be a limitation of go-build-system. <nckx>But go-golang-org-x-tools isn't a library. <nckx>At least if the description is accurate. <nckx>Or Go has an effed up notion of ‘tools’. <nckx>Which is to say it doesn't match ours so is clearly objectively wrong. <nckx>OK, thanks. I think I understand about as well as I can, considering. <unmatched-paren>> This repository provides the golang.org/x/tools module, comprising various tools and packages mostly for static analysis of Go programs, some of which are listed below. Use the "Go reference" link above for more information about any package. <unmatched-paren>> It also contains the golang.org/x/tools/gopls module, whose root package is a language-server protocol (LSP) server for Go. An LSP server analyses the source code of a project and responds to requests from a wide range of editors such as VSCode and Vim, allowing them to support IDE-like functionality. <unmatched-paren>I think it also contains a library useful for Go programs, since some Go packages depend on it <nckx>I can certainly live with ‘that's how the go-build-system crumbles’ regardless of what's the most correctest otherwise. <nckx>Sure, but usually having a user-facing binary trumps any libraries you happen to include, at least for other language-foo naming schemes. <unmatched-paren>go/ssa, go/packages, go/analysis, go/callgraph, go/ast/inspector, go/cfg, go/expect, go/gcexportdata, go/gccgoexportdata, go/types/objectpath <nckx>If you're looking at the Web archives, those include *several* fun layers of delays. <nckx>The funnest being by far rsync in a bash while true loop. <nckx>I still don't understand how GNU is fine with us doing that, but hey, it works. <unmatched-paren>nckx: Btw, it looks like hplip tries to download a proprietary plugin <unmatched-paren>> HP Device requires proprietary plug-in which is missing. Click "next" to continue plug-in installation <nckx>I'm aware of the plug-in, but the downloading part is ‘new’. <nckx>hplip is already a pain to upgrade because of that. I have to manually diff the source and inspect it just to catch any suspicious new binaries. And that's still error-prone. <nckx>And apparently failed at some point. <nckx>s/new /new mentions of / <nckx>Again, I'll probably just believe whatever you say. <raingloom>could someone take a look at my linode-cli package? i need it for deploy related stuff. ^u^ ***unwox_ is now known as unwoxx
<unmatched-paren>nckx: Looks like I forgot tons of dependencies for gopls, apparently. <unmatched-paren>I'm not sure how that happened, but when I tried to compile a version using gopls's latest tag, instead of x-tools's, it failed due to lots of missing deps. <vldn>how to define custom shepherd services in my system config scm? <unmatched-paren>Though you may want to consider upstreaming the service if it's generally useful <vldn>it's just for my personal dwm config to automatic start as a service <vldn>so i don't have to automatically login to the shell.. <vldn>thanks now the definitions are working :) <raingloom>quick q: what was the incantation for getting full backtraces from Guile that aren't useless? <raingloom>follow up: any trick for getting a useful bactrace that doesn't come from ice-9/eval.scm? i have like 3 match expressions, how do i track down where the match-error is raised without resorting to printf debugging? <raingloom>I'm already running guile with the --debug flag. <raingloom>it still surprises me how much better the error messages are in Lua, which has a much simpler implementation. :| <nckx>🐃 .oO don't sacrifice me! <nckx>raingloom: The two are generally related, no? <raingloom>nckx: Lua was inspired by Scheme somewhat, but it has no quote or quasiquote. <unmatched-paren>guile is relatively old compared to Guix, and it's apparently cludgy in places, as you might expect a lot of pre-2000 software to be <pkill9>where is it cludgy unmatched-paren ? <raingloom>Lua was also started in the 90s, so that's not a good excuse. :) <unmatched-paren>pkill9: Well, there's apparently some cruft lying around in its codebase. <raingloom>Using sexps instead of syntax objects with line number info is a big design mistake. That is AFAIK what makes good error messages difficult. <nckx>That would be a nice excuse but doesn't sound plausible. <nckx>No. How would that reasoning even work? <nckx>I think it's more of a GNU cultural thing, if I make speak freely. Or at least a curious pattern. <unmatched-paren>Hm, yes, now that I think about it, I have seen line numbers printed in guile backtraces before. So they probably are stored somewhere. <nckx>Sure. It's not an excuse (for Guile, to be clear). Other Scheme(alike)s manage this oodles of magnitude better. <unmatched-paren>I remember feeding Racket some faulty code to see what it spat out, and I wasn't too impressed with it either. <nckx>Oh. One max two oodles then. Fair. <raingloom>Lua's load lets you feed it a custom source if I remember correctly. That's what gets used in error messages. Also it doesn't eval, it returns a function that you can call any time. <vldn>possible to import the modules in the use-module line at the top from other used modules? <vldn>that i don't have to declare everything twice.. <vldn>or make one module with all the imports and use this? <raingloom>look in the Guile Reference info pages and search for "#:re-export" <nckx>raingloom: ‘Custom source’? <rekado>guile’s error messages and backtraces seem to have gotten worse as the compiler improved. I don’t think it’s a cultural thing. <nckx>Is anyone else (especially with an i915ish GPU) seeing lots of ‘Purging GPU memory’ log spam? I can't say exactly when it started, but I'm on 5.18 now. <muradm>when doing make is it possible to avoid slow docs stuff? <monkey`>I have just upgraded emacs from 27.2 to 28.1 using guix as a foreign distro <monkey`>It runs the correct version from the command line, but the gnome icon still links to 27.2 <acrow>muradm: I think it goes away when you run po4a-updatepo <acrow>monkey`: On my foreign disto I had to relink the icon to my profile/guix-home once but since then the link has remained stable. <formbi>I'm trying to package easyeffects <formbi>and the build system can't find rnnoise and pipewire even though I put them in the inputs <muradm>acrow: how do I run that po4a-updatepo? <muradm>formbi: if you set "pipewire" by default it is < 0.3 <acrow>muradm: You may need to install po4a to have the script in your environment. <muradm>formbi: try using pipewire-0.3 as input <muradm>should i run it for every doc manually? <muradm>i didn't see useful goal in Makefile for it <acrow>muradm: IIRC, look in the po directory tree. <acrow>muradm: I think the root problem is that the po translations are independent of the applications that use them, like guix, and they update on different timeframes. That is why this happens. I think this is all handled transparently in the developers installation of guix provided that po4a is in place for the process. I think you can just re-run ./configure && make to get things going again.. <acrow>muradm: I'm no translations expert, just grateful that these things exist. I am sympathetic thought bc the same thing happened to me and IIRC the solution was to add po4a to the mix. Sorry it happened to you. <muradm>acrow: i suppose you are right on transparency thing.. i just "git pull && make authenticate && make distclean && ./bootstrap && ./configure && make" <muradm>acrow: would be good to have it somehow optional <acrow>muradm: do you think it is networking or your computer that is slowing things the most? <muradm>why whould i wait hours for docs which i'm not gonna use in local development anyway <muradm>acrow: i suppose both.. laptop is on battery only and network is slow gsm <acrow>muradm: It's a good point. I suspect someone more knowledgable than I might see this and point out an obvious answer that I've missed. I don't know. <muradm>vagrantc: yeah, exaggerated a bit, but definetely more than 30-40 mins, didn't measure specifically <vagrantc>cbaines: does data.guix.gnu.org store all the data over time, or does it gargabe collect old data? <acrow>vagrantc: Yay for reproducibility! <vagrantc>i think mostly because there are a lot of "unknown" things due to lag time in processing between bordeaux.guix.gnu.org and ci.guix.gnu.org <muradm>vagrantc: is there a list of things which are failing to reproducibility? <vagrantc>looking at older revisions where the build farms have had a chance to catch up it seems more consistently 86% <vagrantc>so, i would say it mostly seems to vary in the unknowns, the "not matching" spots seem fairly consistant <muradm>vagrantc: hmm.. yeah i pressed few times, before writing, but then it openned slowly, thanks <vagrantc>i'm only looking at x86_64, since the coverage for other architectures isn't all that great <monkey`>acrow: I am not using guix-home yet. I'm not even sure how gnome found the desktop icons to begin with <monkey`>I checked /usr/local/share/applications/ and /.local/share/applications and neither have a link emacs <monkey`>or any other program I have installed with guix <vagrantc>muradm: doesn't look like a whole lot has changed <monkey`>Huh, looks like it must be taking it from my main guix profile <muradm>what should i import to make (report-error (G_ ...) ..) working ? <muradm>(guix diagnostics) gives weird error <muradm>i see (guix ui) is re-exporting it <vagrantc>weird. gnustandards seems to have been renamed to gnu-standards somewhere in git history but i cannot find where <vagrantc>i committed a fix to gnustandards in 615239d5caa5f668894bfccbb35f5ffa6b756615, and now there's only gnu-standards, which has been there since 2016? ***aeka` is now known as aeka
<acrow>monkey`: Then the link you want will be in your .guix-profile. <acrow>muradm: I have no more insight than before but on thinking about the matter; it seems to me that updating all translations is appropriately part of downloading guix for development. All the translators, after all, are also very important developers. <formbi>ok, I mostly figured out the easyeffects package, but it still says «Run-time dependency rnnoise found: NO (tried pkgconfig and cmake)» <formbi>maybe the rnnoise package doesn't have the pkg-config stuff? <formbi>wait a sec, that package is just some other rnnoise-based thing <nckx>You mean our rnnoise package is misnamed? <nckx>From the synopsis, it seems like that might be true. <formbi>I just made the package for the real one <nckx>It (our ‘rnnoise‘ package) also seems to bundle rnnoise itself. <nckx>formbi: I didn't do much digging, just saw src/rnnoise/{src,CMakeLists.txt,etc}. What's that then? <formbi>where should I put easyeffects and rnnoise? <nckx>Isn't rnnoine already packaged? <nckx>Ugh, pipewire is in the linux.scm dumpster, because of course it is. <nckx>I'd be bold and create a new pipewire.scm file, formbi. <formbi>«There's no public release and a conflicting package, so hide it for now.» <nckx>I am filled with even more confidence looking at that page. <formbi>maybe it could be unhidden since the conflicting package was basically a mishap? <nckx>Well, the ‘conflicting package’ argument is bogus. And yes. <nckx>I think I'm going to remove noisetorch. ***rgherdt_ is now known as rgherdt
<formbi>so if we make a pipewire.scm should we move pipewiwe and other stuff there? <nckx>That would make most sense. <nckx>People will have to adjust their module imports, but c'est la vie. <formbi>hmm, but what about the contributor list? <nckx>Contributions to the pipewire package should be migrated to pipewire.scm. Contributor-years that no longer apply to linux.scm should be removed. <nckx>But note that moving pipewire is a separate step, you don't necessarily have to do it just yet. <formbi>yeah, I mean how to check who contributed the pipewire things <nckx>s/Contribut*/Copyright/ above, to be more precise. <nckx>Hi AhmedNabil[m]. Could you elaborate? Where do you see the old packages, where do you see newer packages, etc.? <nckx>Your question makes sense but there are different ways to interpret the details. <acrow>nckx: Patience is a virtue but in the absence of goals bitrot ensues. <acrow>AhmedNabil: That can be fixed by executing a guix pull and then guix package --update <nckx>AhmedNabil[m]: The GNOME and KDE versions are accurate: those are the versions currently in Guix. Updating Guix packages when upstream releases a new version is human work, and nobody has done that work yet. As for Libreoffice, that is strange, because the version actually in Guix right now is 7.3.5.2. <nckx>So that is probably due to the Web site not being updated properly. <nckx>But the gist is: having an ISO that is rebuilt daily has nothing to do with having bleeding-edge packages. <nckx>acrow: The hick is a reverse ping? :) <acrow>AhmedNabil: nckx has given a more thorough and thoughtful response. <nckx>I have answered this thoughtfully above. <nckx>The short answer is ‘nobody has committed a patch to Guix that updates GNOME & KDE after testing that the new version still works’. <nckx>Upstream releases don't magically update the Guix package. But I repeat myself, sorry. <nckx>acrow: ‘reverse ping’ was the subject line, never mind, probably doesn't matter. So this was that patch that was stalled on reviewing upstream code quality, right? <nckx>I agree that this is admirable but not Guix's job. <nckx>vagrantc casually pasting eco-porn in the channel >:( <nckx>acrow: Ideally, you'd happen to ping a committer who's more confident with Java than I am. <acrow>nckx: That is also how I interpret the situation. <nckx>There's no licence issue, right? <acrow>nckx: It's an apache project of many years. <acrow>nckx: I think we have gone above and beyond in due diligence WRT. <nckx>Listing individual licences is equally admirable, but also not required, if the end licence covering the combined work is listed that suffices. <nckx>acrow: What *I'd* do is ping Julien (roptat here, but currently off-line) who has commit access and knows a lot more about Java than I do. <acrow>nckx: your the best. I can go with that. <nckx>I'd be more comfortable if they committed it. If absolutely nobody does in the next few days, I will (but remind me). *vagrantc wonders what the difference between absolutely nobody and just plain ol nobody is <nckx>AhmedNabil[m]: Sorry to sound impatient. I just feel like I answered your question, but maybe I wasn't clear enough. <nckx>vagrantc: Nobody is the person who does all the work around here. <nckx>Absolutely nobody is… hm, I guess it's the person who gets paid the big bucks to work on Guix. *vagrantc aspires to Nobody's workload <nckx>Yeah, I've sent a few patches their way today and it worked — nobody committed them. *vagrantc grumbles harder at itpp <AhmedNabil[m]>nckx: no my internet connection is bad for that I didn't see your message before I send my messages <nckx>Sorry if the answer was disappointing by the way. We're not the most bleeding edge of distroes, we have way too few volunteers for that, and don't have tools to automatically update & test packages (yet?). <nckx>But I'm sure Nobody's working on those as we speak. <acrow>vagrantc: when does the formulas.log come into existence? I'm guessing after the build --- but your change seems to put it after the install and that is too late. <vagrantc>there is some tooling to automate parts of the update process, but it still requires some review, and GNOME and KDE are huge collections of projects with lots of interconnected parts ... so it's a bit more difficult to get right <acrow>vagrantc: That and $4.50 will get you a coffee in most of the pacific northwest. <vagrantc>acrow: i haven't yet found where it is created, but it ought to be after the build for sure, figured before install ought to be right ... or delete it from the output after the install ... but honestly, i can't find where to reference it <vagrantc>acrow: it's not in the source directory, but a build/ directory <acrow>vagrantc: I think the new build system offers some searchy tools ... let me look around. <vagrantc>/tmp/guix-build-itpp-4.3.1.drv-4/build/html/_formulas.log ... whereas the source is in /tmp/guix-build-itpp-4.3.1.drv-4/itpp-4.3.1/ ... after a --keep-failed run <vagrantc>i also tried (for-each ... (find-files) ... but my lack of guile talents limited that approach, and it seemed like overkill anyways <acrow>vagrantc: no, I understand ... and for-each is a lovely approach... still looking. <nckx>vagrantc: (pk (getcwd)) to make sure you are where you think you are. <nckx>…if I've been following attentively, which I haven't. <acrow>vagrantc: search-input-file is documented in the 'The Big Change' blog entry from a few months ago. I think that this might help. <vagrantc>nckx: thanks, i didn't have any idea where i was at least <vagrantc>acrow: it's not an input, it's part of the build process <nckx>You can't delete files from inputs. They are static. <vagrantc>i guess i could try to patch the buildsystem directly rather than doing it with guix, or exclude _formulas.log from the install target or something <nckx>What you'd want to just find a file anywhere is indeed find-files, but that's indeed overkill here, because it's just trying to escape the fact that you don't know where you are 😉 *nckx is having their own ‘…but the damn file is RIGHT THERE! look!!’ misadventure whilst updating noisetorch, which they have foolishly decided to keep. <nckx>…as always, publicly admitting to it *immediately* makes the problem jump out. <nckx>(string=? "lib" "") => #f <nckx>‘cannot embed irregular file’ — 😒 <vagrantc>heh. now i'm successfully able to delete the file, but it magically finds the file from somehwere else and installs it. <nckx>This is like that scene in the Terminator. <nckx>The one with the Terminator. *vagrantc is always happy to see free software placements in popular media <nckx>Excuse me, but this robot tried to kill me when I tried to reprogramme it, which clearly violates the anti-tivoisation clause of the GPL. <vagrantc>you can't prove what license was at play, it could have been a BSD-3 clause or something <nckx>Like the T-1000 ain't running Busybox *somewhere* in a legacy stack. *vagrantc notes the use of "prove" *nckx notes the use of machine guns and heavy weaponry. <vagrantc>ok, clearly i have to remove this after 'install installs the files ... so i need to remove it from the output ... any examples of doing that? <vagrantc>if i remove it before 'install it re-creates it and installs it <vagrantc>i am 94.837% sure this is not actually needed in the package. *vagrantc works on so many packages and doesn't actually even know what they are supposed to do <nckx>(lambda _ (delete-file (string-append #$output "/unkillable/spawn"))) <nckx>Or if you prefer this for style: (lambda _ (with-directory-excursion #$output (delete-file "unkillable/spawn"))) <nckx>After this question I am even more impressed by all your work on Guix. <vagrantc>give me a cult and a cargo and i'm good to go <cbaines>vagrantc, you asked earlier about data.guix.gnu.org data retention. data.guix.gnu.org currently just keeps everything <cbaines>for data.qa.guix.gnu.org, it does remove data <vagrantc>cbaines: so, in theory, i could take the reproducibility data and generate a chart over time? <cbaines>I'm mostly operating two instances so I can handle this separately <cbaines>vagrantc, yeah, that should be possible <cbaines>currently you'd need to query the data per revision <cbaines>I've considered caching that internally, as that would make generating a chart much easier <vagrantc>cbaines: the "latest-revision" reproducibility info is highly prone to variable results, mostly due to the various build farms being always a little out of sync <vagrantc>so was thinking to chart it over time would be valuable <vagrantc>and the per-revision stuff ... does that change as the build farms catch up? <cbaines>which is probably one of the main reasons why the number may seem to change over time, even for the same revision <vagrantc>though i would presume the build farms usually don't loose builds ... the numbers would just move from unknown to matching/not matching <vagrantc>so few inodes to go around though, who knows <cbaines>as the Guix Data Service doesn't get rid of substitute information, it just assumes substitutes are kept forever <vagrantc>cbaines: as in "at one point they were built and they $match|$notmatch" <cbaines>although I'd like to make this more rigerous in the future <cbaines>ideally data.guix.gnu.org would get "reports" about builds, including the hashes of the outputs <vagrantc>maybe a "substitute currently available" vs. "substitute historically available" or some such? <cbaines>then those reports could be used for these kind of analysis <cbaines>that would reduce ambiguity about where substitutes come from, especially on setups like ci.guix.gnu.org <vagrantc>yeah, just storing the hashes and maybe signatures in a database would be hugely valuable <vagrantc>kind of like .buildinfo files used in other distros <cbaines>and this would improve the data available from setups like bordeaux.guix.gnu.org, where things can be built more than once, but it's just the first successful build that'll be available as a substitute <vagrantc>systematically ensuring that builds happen on multiple dates would catch many date-specific reproducibility issues <vagrantc>timestamps are usually easier the finer grained they get ... ideally at least seconds provides little likelihood you'll get a reproducible result by dumb luck <nckx>“Checking for HP Properitery Plugin's....” — hplip, using properitery substitute*guard® technology. <vagrantc>hrm. this cult has failed my cargo so far. Unbound variable: ungexp ... code incoming <nckx>Sounds like you're trying to use #$ without a surrounding #~ <nckx>My snippet earlier? It assumed you were using gexps. <nckx>(lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out"))) (delete-file (string-append out "/undead/file"))… <nckx>I lost count of the )s but that should be otherwise correct. <vagrantc>i tried something like that and it exploded in other fun ways ... but will try again <nckx>Shouldn't asplode, was probably a tiny typo or so. <vagrantc>i did manage to spend a lot of fruitful time with (add-after 'instal 'my-shiny-phase <nckx>“PLUGIN POP-UP FOR PLUGING SUPPORTED PRINTER'S” Jesus HP. <nckx>Yes, add-after 'nonexistent is a fun failure mode. 
