IRC channel logs
2023-01-19.log
back to list of logs
<vagrantc>ACTION suspects some assumptions between all the different slightly incompatible pypdf versions <apteryx>sneek: later tell civodul the strange thing is that I've run 'guix pull' (and not ./pre-inst-env guix pull) since, but I'm still stuck with %sysconfdir=/usr/local/etc unless I remove my channel. <vagrantc>huh. well, packaging pypdf 3.2.x as python-pypdf and adding to native-inputs seems to avoid skipping diffoscope some test suites <HexMachina>for the benefit of anyone searching these logs later, I was able to get guix archive to work creating somthing I could copy to the offline machine if I also exported the non-grafted package <HexMachina>example for wget2: guix archive -r --export $(guix build wget2) $(guix build --no-grafts wget2) > wget2-export.nar <HexMachina>manually copy wget2-export.nar to other machine, cat wget2-export.nar | guix archive --import <HexMachina>though it was important that both systems were on the same version of guix <HexMachina>one thing I haven't figured out though - for a package like emacs-magit, I can do a guix build and a guix archive --recursive, and it still doesn't include emacs-async, emacs-compat, or emacs-with-editor, which all all needed to do "guix shell emacs-magit" <HexMachina>so why aren't these dependencies captured by archive --recursive? <lfam>Just realized the Debian mirror I was using hadn't been updated in months <lfam>Thankfully, Guix aims to avoid this kind of problem / attack <lfam>The necessity of such a ranking belies a deeply broken security model <the_tubular>Your concerns are right, but I'm not sure that's an attack though ... <lechner>the_tubular / podiki[m]1 / i get 502 Bad Gateway instead but otherwise similar <lfam>The ranking characterizes the "archive version" as "unexpected mirror version". I interpret that to mean that the list of available packages doesn't match any of the versions that Debian ever made available. As if it's been cherry-picked to provide a "version" of Debian that never existed <lfam>I mean, sure, it could be a mistake or an attack. It's a distinction without a difference if you are designing a secure update system <the_tubular>For Debian concerns you should also reach out to vagrantc :P <lfam>You're missing the point <lfam>The archive version should be a date that matches some list of "official" release dates, if I understand correctly <lfam>It shouldn't be possible for a mirror to basically rewrite the distro <lechner>maybe that's the ftpsync version used, actually <lfam>It's all to say that I think Guix is on a good path and is even leading the way <lechner>yeah, right! how many mirrors do we have again? <lfam>I mean, none for thing that counts the most, which is the Git repo <lfam>That's the ultimate source of truth for Guix <lfam>But at least two for substitutes <lechner>i think those may be independent build farms <lfam>Right, that's what I was thinking of <lfam>There is a more traditional style of mirror in China <lechner>i applied for mirror space recently for substitutes and was told that our traffic is too low <lfam>They'd have to break Git / PGP / Guix codesigning in order to do anything <lechner>the_tubular / it's someone who operates mirrors for CDNs on spare capacity <gnucode>lechner: where did you apply for mirror space? <lechner>gnucode / someone i have been in touch locally. he operates an internet exchange in Hurricane Electric's FMT2 data center. <SUPERB[m]>What's the version of XFCE we check in the installation menu? <gnucode>it looks like issues.guix.gnu.org is down? <mirai>bittorrent for guix substitutes (and package sources) would be a nice addition <mirai>especially with bittorrent v2, you also get per-file hashes that can be used to share the same file across multiple swarms <SUPERB[m]>I searched the website but couldn't figure out how should I configure the /etc/config.scm after installing XFCE and lightdm manually through the shell! <yewscion>Is anyone else having difficulties with java-logback-classic? It won't build for me all of a sudden, and I don't see anything in the backlog (or earlier, on the issue tracker). <gnucode>SUPERB[m]: if you are trying to run xfce as your desktop environment, you do not need to install xfce into your profile. <gnucode>You just need %desktop-services and (service xfce-service-type) <gnucode>it might actually be (service xfce-desktop-service-type) .... <SUPERB[m]>gnucode: This is what happens after the first update <SUPERB[m]>Icons disappear so I decided to install xfce by my own <SUPERB[m]>* first update that was installed by xfce checked through the installation <gnucode>You could try the hi-color-icon-theme, but that might not fix the issue... <gnucode>SUPERB[m]: change %base-services to %desktop-services. <gnucode>%desktop-services include gdm-service-type by default. <gnucode>SUPERB[m]: also it might be easier to just use paste.debian.net to supply snippets of code. <gnucode>I don't think so. I am pretty sure that when you try to reconfigure, guix will complain that you have duplicate services. I think network-manager service is in %desktop-services <gnucode>SUPERB[m]: type in a shell "info guix RET i %desktop-services RET to see which desktop services are in %desktop-services <gnucode>try to reconfigure. If you get errors, tell me what those errors are. <gnucode>also move (service xfce-service-type) right above (service tor-service-type) <SUPERB[m]>gnucode: No need to add any about xorg configurations? <apteryx>nckx, rekado a large full 'guix gc' is currently running with mcron (see /var/log/mcron.log). It seems like it'll take a while (it only reaped ~50 GiB in the first hour). <PotentialUser-34>hi i installed guix only selecting exwm as desktop environment, how can i switch to a different desktop environment instead of exwm? <dsp>i just want to say that i would love to hate it and just use obsd on that box too, but you guys have done a great job. it's the only usable and refreshing packaging of the linux kernel i've seen in a long time. thanks. <bumble[m]>how would one find this information for themselves? <unwox>module is (guix packages), you can derive it from location field <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: the strange thing is that I've run 'guix pull' (and not ./pre-inst-env guix pull) since, but I'm still stuck with %sysconfdir=/usr/local/etc unless I remove my channel. <civodul>apteryx: hi! prolly because %sysconfdir is again being inherited <xiews>My GUIX machine hangs after I: cd /gnu/store;ls <efraim>xiews: at the risk of not being helpful, don't do that :/ Using find my store has ~1.6 million items in the top level of /gnu/store <rekado>in the same vein: M-x ffap on a /gnu/store/… file name takes a very long time to give me a prompt to confirm; does anyone know of a configuration to avoid this delay and have Emacs visit the file right away? <xiews>efraim: Thank you for the advice. <apteryx>civodul: re %sysconfdir; any idea how to get out of that situation of continuously inheriting the wrong setting? also, shouldn't my ./pre-inst-env guix pull have inherited from the correct 'guix' at the time? <apteryx>rekado: if you find one, I'm interested <apteryx>I continously have to jump to non /gnu/store buffers in Emacs before C-x C-f (visiting) another buffer, else it hangs for a bit <apteryx>on berlin: build-package-metadata: completed in 22275.590s <efraim>Looks like mesa-21.3.8 doesn't build with llvm-15. I'll try building it with llvm-14 for testing my llvm-for-mesa patch on master <apteryx>there's also a zillion lines of output like "update-guix-manual-devel: l.3551: Unicode char @u8:?? not defined for Texinfo l.3551" in /var/log/mcron.log on berlin <jbv1[m]>hi guix! I have a quick question I would like to define a package that has no source, just copies everything from an input and modifies some files, how to do that ? <apteryx>rekado, cbaines: guix gc flagged some 12364547 MiB (12 TiB) in about 8 hours, and has been in the process of deleting /gnu/store/trash for the last 2 hours <apteryx>that's a rather good performance from the SAN array, I'd say, and going forward it shouldn't be a problem with guix gc running daily <efraim>We probably should separate out the deleting of /gnu/store/trash from the GC operation <apteryx>it is putting the fat lock on the daemon for the time it deletes /gnu/store/trash? <apteryx>I can also see a btrfs-specific to make that much faster: make /gnu/store/trash on a subvolume, and recreate (delete and create in anew) the subvolume to empty it, which should be relatively zippy <civodul>apteryx: if you run "./pre-inst-env guix pull" from a Guix configured the way you want, it'll be fine <civodul>rekado: i'm interested in a solution to that ffap problem! <ieugen[m]>hi, does guix have any package namespace support ? if I run guix pacakge -i hello and I have hello package available in 3 channels, which one will be chosen ? <civodul>ieugen[m]: hi! the one with the highest version number comes first <civodul>if you want to be unambiguous, you can refer to the variable <civodul>as in: "guix package -e '(@ (my packages) my-hello)' <ieugen[m]>that looks like a job for Guix Hacker (super hero name). not very user friendly :) <ieugen[m]>there can be multiple providers for a package and not being able to specify a package is not reproducible IMO <civodul>that behavior is entirely reproducible :-) <ieugen[m]>IMO the packages could accept the channel as a namespace - to look for pacakges only in that channel ?! <civodul>but yes, there can be cases where package names alone are ambiguous <civodul>so, at the CLI, you need to disambiguate one way or another <nckx>What's this broader issue? (Hullo Guix.) <apteryx>ieugen[m]: the guix package graph doesn't care about extra channel packages, though <rekado>I think it might be due to ivy--sorted-files, which tries to get all possible completions (= all files in /gnu/store) <ieugen[m]>apteryx: I don't get this, sorry. - too new to guix <ieugen[m]>> he guix package graph doesn't care about extra channel packages, though <apteryx>ieugen[m]: with the current way things are, channel packages don't shadow guix packages, so using samed name package will only amount to confusion at the CLI level. I'd suggest using a different name for your version of hello. <ieugen[m]>apteryx: thanks but the name might not be in my control. if two third parties publish channels. I need package xx from party A, which also packages hello. <ieugen[m]>and I need pacakge hello from party B, not party A <ieugen[m]>how can I solve this ? there is a name clash caused by two external, independent parties <apteryx>civodul: already proposed a solution, using the -e option to evaluate an expression <ieugen[m]>for context, this issue IMO has crept up in every pacakge manager out there: java uses group.id for that, npm added scopes, ansible added collections , etc <apteryx>ieugen[m]: also, if you use a manifest to define the packages you want installed in your user profile, you can use the variables and the power of Guile to import them with a name prefix for example <apteryx>Something like: (use-modules ((channel-b) #:prefix channel-b:))) (packages->manifest (list channel-b:hello)) in a manifest.scm file <ieugen[m]>thanks apteryx , I will try that at some point. Nice to know it can be done. <ieugen[m]>could a similar solution be provided for the cli ? <ieugen[m]>one that is simple and works out of the box :) <apteryx>everything is possible, but it takes someone with an itch strong enough to do it :-) <nckx>ieugen[m]: -e '(@ (foo packages bar) mypackage) <ieugen[m]>so is it right to assume that packages are namespaced in each channel by their guile module namespace: e.g. (foo packages bar) has 3 parts in the name <nckx>Maintaining a whole parallel DSL (which is what CLI package specifications are) is a sad reality, and probably needed to not completely alienate newcomers, but I think that extending it by adding more magic characters like ‘/’ or ‘::’ is harmful. <nckx>The number of parts isn't relevant (Guix uses 3, other channels can use as many as they like) but yes, that's the idea. <nckx>To your ‘Java uses x, npm added y, …’ above you could add ‘…and Guile has modules’ :) <ieugen[m]>I use clojure and I am familiar with namespaces. just started to look at guile/scheme <apteryx>For the guix pack rpm format; we can use pure scheme and spend some time to learn how to serialize C structs to binary for the metadata, or use rpm-build. Any preference? <YuuYin[m]>ieugen: guile has namespaces as well. it is just a bit different. <ieugen[m]>I did not know the namespace was there, but not exposed in CLI <apteryx>So far we already have something to generate the payload (guix cpio), and the initial metadata (called "lead") is easy enough to produce <ieugen[m]>so a channel living in git using their own namespace prefix should have no package conflicts. that is good to know. <ieugen[m]>the issue is currently with the CLI - but there is a solution/workaround with -e '...' <apteryx>nckx: every time I try using 'nix' I'm confused having to have to specify nixpkgs::the-package even for the core things, so I agree <apteryx>but if it was just for 3rd party channels, it could be extra sugar on top, as friendlier alternative to -e for newcomers, perhaps <ieugen[m]>apteryx: it might be confusing to specify the pacakge source (channel) - although I don't see why ? but IMO it is more confusing and risky if the package is randomly chosen from a list of channels <apteryx>ieugen[m]: why force to *always* specify an import prefix, even for "core" channel? nixpkgs:: should be optional, while 3rd party channels should all be mandatory in nix in my opinion, that'd make things less verbose. anyway, that's a conversation for #nix <nckx>apteryx: Heh, my ‘::’ example was actually from Exhebro (where IIRC it was a postfix? weird). It's building this complex ‘spec’ DSL that bugs me, not namespacing things in a nice way. But saying that -e is unfriendly is also a stretch. <nckx>* Exherbo. Not sure I'd use something called Exhebro. <ieugen[m]>specifying just the package name could use a default channel - which can be initially set to guix official channel <nckx>guix package install hello --from=gnu coreutils --from=nckx util-linux # no need to force this stuff into spec strings. <apteryx>nckx: -e is friendly once you know Guile, which is probably not the case for most Guix newcomers <nckx>It's saying that guix::hello@4.2 or guix/hello or whatever is friendlier that I'm criticising. <nckx>Both involve learning a new syntax, only one actually opens future doors. <ieugen[m]>I get your point. How would installing 10 packages look? I use something like this in a Dockerfile: apk --no-cache add bash python3 py-pip py-setuptools ca-certificates groff less wget openssl <apteryx>"guix install bash python python-pip python-setuptools nss-certs groff less wget openssl" <nckx>apteryx: Meh. Having two completely independent namespaces (names & specs, vs. variables & [to me] no NIH stuff) has always bugged me, this is just that old annoyance. I wish I were clever enough to find some grand unifying theory of naming Guix packages, but I'm not :) <ieugen[m]>naming is hard :) . that is why we came up with namespaces (or last names for people ;) ) <nckx>I have less of a constructive point that I wish I'd have. Only that ‘let's add more magic to specs’ is a move in the opposite and therefore objectively wrong direction (/s, but serious). <civodul>apteryx: re RPM, unless the format is complex, my personal preference would be for pure Scheme, along the lines of what we did for cpio and a couple of others <civodul>for C structs, perhaps a simple way to start with is by (ab)using (system foreign) <civodul>that would let you serialize C structs easily <civodul>(define-c-struct is nicer, but we'd have to take it out of (guix build syscalls) or make it public, which would be quite an endeavor) <apteryx>OK, I'll have a look at (system foreign), thanks for the pointers! <Obikawa>Hello. I have a directory containing an Emacs package with custom changes. How can I properly load it with Guix Home? <apteryx>is it normal that 'guix publish' takes 10 GiB of resident memory on berlin? <rekado>apteryx, civodul : disabling ivy-mode speeds things up dramatically. <rekado>my rockpro64 cannot be restarted because it doesn’t shut down <rekado>[535205.486898] shepherd[1]: waiting for process termination (processes left: (1 147)) <rekado>shouldn’t shepherd kill processes with a little less patience? <pret7>issues issues.guix.gnu.org down? <apteryx>rekado: I have some machine (an x200 and a desktop) where that seem to happen often too (the machine seemingly hung on shutdown) <pret7>im getting a 502 after ~30 secs <apteryx>deleting that /gnu/store/trash directory seems to take its toll on available IO <apteryx>but issues.guix.gnu.org seems back up <nckx>sneek: later tell pret7: Thanks, I restarted mumi-worker on berlin. <nckx>I'm not sure it was to blame, but it was the last thing I did before it started working. Restarting only mumi wasn't enough. <civodul>rekado: shepherd 0.9.3 does, but this particular piece of code is in Guix <civodul>rekado: do you have a trick to disable ivy-mode around ffap? <sneek>jonsger, you have 3 messages! <sneek>jonsger, lechner says: / Hi, are the angle brackets in the output from the bot causing problems for you, please? <sneek>jonsger, lechner says: / the angle brackets are now gone. thanks for your contribution! <mirai>shouldn't unzip be available when using copy-build-system? <mirai>right now if I don't add it to native-inputs, it fails with %exception #<&invoke-error program: "unzip" arguments: <rekado>civodul: (advice-add #'ffap-read-file-or-url :around (lambda (original &rest args) (let ((completing-read-function #'completing-read-default)) (apply original args)))) <apteryx>mirai: why? unzip is not commonly used <mirai>if you use copy-build-system and have a .zip as a source file you get that message <mirai>it's odd having to add it to native inputs explicitly (we don't add git to native-inputs when checking out git:// for example) <apteryx>the same if you use the gnu-build-system <apteryx>some compressors are supported but not included out of the box <mirai>is it acceptable to pre-generate some files for packages? (these would go into gnu/packages/files) <cgenie[m]>define-module: expected keyword arg in subform (guix build utils) of (use-modules ((ice-9 ftw) (guix build utils) (guix build copy-build-system))) <cgenie[m]>i actually almost copy-pasted code from guix/gnu/packages/build-tools.scm... and i don't know what's wrong with my code <mirai>cgenie[m]: drop one layer of parenthesis for modules <mirai>btw you're mixing gexps and assoc-ref <mirai>instead of (assoc-ref outputs "out"), use #$output <mirai>for unzip you likely will need to do something similar <mirai>(let ((unzip (string-append #$unzip "/bin/unzip)) <mirai>unmatched-paren: does that work? I've had occasions where it wouldn't work within gexps <cgenie[m]>search input file fails for me with unzip not found, am i missing it somewhere? <unmatched-paren>hmm, maybe you need to do (search-input-file native-inputs "bin/unzip") <cgenie[m]>ok indeed, this works, i must have done somethign wrong before <apteryx>mirai: I don't think it's acceptable; it'd be best to fix the build system or implement the generation of the file in a phase <apteryx>by "fix the build system", I meant submit a contribution to upstream so that the needed file is generated at build time <mirai>apteryx: eh, it's a file that it's unlikely to be ever changed (xml catalog for docbook) <apteryx>aren't these shipped with docbook already? <mirai>apteryx: unfortunately for 4.1.2 no <Fare>I could finally build an image without gtk for the pinephone pro... now to see if it boots. <mirai>I think it's only one that didn't came with catalog <mirai>other distros have the values "hard coded" into their buildscripts but that's essentially the same as bundling a pre-generated copy <mirai>for the remainder of docbook versions, the troublesome parts tend to be the <public> elements <apteryx>OK; is it lengthy? (call-with-output-file "catalog.xml" (lambda (port) (display "blob-of-text" port))) <cgenie[m]>btw, is there some way to deal with packages that contain only data? suppose i have some scientific data that is in git and i want to create a package for it to later use it in some programs and make it easier to bundle using guix pack, but i want my scripts to know the path to that data package? <mirai>these can't be easily fixed xmlcatalog and are best fixed with a XSLT sheet <apteryx>looks like you should be able to write a template with %prefix% later substituted (via substitute*) to #$output <apteryx>it's OK to be in a phase, it's compact enough. <mirai>apteryx: I'd prefer not encouraging regex use on xml <rekado>for xml files we use pre-post-order <mirai>much cleaner to pass prefix this way: (invoke xsltproc "--stringparam" "prefix" dtd-path <mirai>"--output" catalog* #$(local-file "aux-files/xml/patch-uri.xsl") catalog) <rekado>examples are build.xml files in java.scm <apteryx>mirai: I was thinking of a simple sed-like text substitution, no regexp needed (although technically it's one) <mirai>apteryx: either cases will still come from a "template file", we might as well do it "the right way" <mirai>it would boil down to: substitute* vs (invoke xsltproc ...) <mirai>rekado: what's this pre-post-order procedure? <mirai>I abandoned it as I couldn't figure out how or what is the module about <mirai>the documentation for sxml is... (left as homework for the reader) <rekado>we use it in a few package definitions <rekado>pre-post-order takes an sxml tree and an alist of tag symbols to transformers <rekado>*default* and *text* are special tags <rekado>the tree is traversed and as a tag from the alist is encountered the sub-tree is passed to the associated transformer <mirai>imo even if somehow I knew how sxml works it would be worse maintenance wise (its tribal knowledge at the moment given the documentation state), save for the few who know its inner workings <mirai>(this is more of a guile doc problem than a guix problem) <mirai>XSLT sheets, though "larger", I think stand a fairer chance of having someone else comprehend and maintain as required <mirai>rekado: though thanks for the explanation and sxml examples <SeerLite[m]>Hi! In what contexts can I use this-operating-system? <SeerLite[m]>I'm trying to use it in kernel-arguments but I get the error "cannot be used outside of a record instantiation" <SeerLite[m]>The manual says it can only be used inside an operating-system, but that's exactly what I'm doing <apteryx>antipode: indeed! glad to see you here <SeerLite[m]>apteryx: my config is a mess but something along these lines: <SeerLite[m]>Basically trying to get the label of the swap partition that's used elsewhere in the same operating-system. I'm starting to think it's better to just define the label somewhere in the top level instead though :P Still curious why this-operating-system doesn't seem to work <lilyp>mirai: xslt is nice and all, but sadly quickly finds its limits <lilyp>meanwhile with sxml you can do the most horrible things of all: parse RDF/XML <jpoiret>SeerLite[m]: if you put the swap-devices part before the kernel-arguments, you can directly use "swap-devices" <jpoiret>no need to refer to the whole record <SeerLite[m]>jpoiret: Yeah that worked for me too! Though I got a type error about swap-devices being a "promise" instead of a record. Passing it to `force` fixes that <jpoiret>heh, yeah, that's what you get for thunked fields. Not ideal <SeerLite[m]>Still curious why this-operating-system wouldn't work though. Is it because kernel-arguments is special? The example in the manual page does work for me with no issues <jpoiret>but it could probably be made to work directly, since swap-devices is handled by the guix record syntax <SeerLite[m]>Ah so that's what thunked means, to make it evaluate lazily? <jpoiret>yes, a lot of things are thunked in guix to ensure they are evaluated with the right dynamic environment (which is a shame) <jpoiret>sometimes, things being evaluated a tad too early can cause them to misbehave :( <unmatched-paren>i think the term originally referred to the technique of wrapping code in a (lambda () ...) to delay its evaluation, though i think guix's thunking might be a wee bit more sophisticated than that...? <jpoiret>SeerLite[m]: regarding `this-operating-system`, they can only be used in thunked fields iirc <jpoiret>i'd wager kernel-arguments is a regular field <unmatched-paren>PotentialUser-88: guix build --no-substitutes --no-grafts will build the latest version from source <SeerLite[m]>lilyp: Is the only difference between delaying and thunking that delaying only evaluates once (the first force)? <PotentialUser-88>i mean can i use another kernel instead of tar xf $(guix build linux-libre --source) <SeerLite[m]>jpoiret: Oh so that's why. The manual makes it seem like it's a magic variable that works anywhere inside operating-system <jpoiret>you thunk if you want the value to depend on something dynamic, and you delay if you have an expensive computation (usually) <civodul>i wonder how bordeaux.guix ended up providing the "wrong" (non-recursive) checkout <attila_lendvai>i need to create a directory in the image that `guix system vm ...` builds. extra-special-file is not capable of that. what can i du? <attila_lendvai>ok, i can use extra-special-file and link there a .ignore-me file to create the directory... but it's a service, and happens too late. virtfs already tries to mount there prior to it running. <nckx>Weird, I just got EBUSY resolving git.sv.gnu.org. I didn't even know that was possible. <nckx>civodul: Me neither… I've settled on *vague hand gestures* ‘QA’ but it's unsatisfying. <podiki[m]1>next step in my procrastination process (recording fosdem talk) might be to move my emacs config to as many guix packages as I can.... <podiki[m]1>anyone have any tips? I guess I'll turn off a global :ensure for use-package and use it only for packages we don't have in guix yet <civodul>nckx: did you confirm that what bordeaux.guix serves is indeed the non-recursive checkout, or could it be some other change, like random data corruption? <nckx>It had the non-recursive hash. <civodul>oh maybe another gcdm patch had that origin with (recursive? #f), so qa.guix grabbed it <ieugen[m]>hi (noob question): how can I get the atchitecture (amd64, aarch64 etc) ? <civodul>and then a subsequent patch added (recursive? #t) *without changing the hash* <civodul>and thus qa.guix said "hey, i already have it in store!" <civodul>ieugen[m]: hi! you can run "guix build --list-systems" <nckx>(or (%current-target-system) (%current-system)) ; generally. <nckx>Oh wait those aren't identical, I always forget. <nckx>‘(%current-system)’ then, but that won't include cross-compilation. <ieugen[m]>I am trying to pacakge a binary pacakge (start small) - I need to take the architecture into account <nckx>But really, you might want to use the target-xxx? helpers in (guix utils), or somelike. <nckx>Right, so you'd ‘cond’ on target-aarch64? → "aarch64", target-x86-64? → "amd64", etc. <nckx>There are many arbitrary conventions for naming architectures, so using (%current-system) directly is often not the best choice. <ieugen[m]>btw, is there any deduplication done by guix store? <nckx>Yes, file level, on by default. <nckx>That's why /gnu/store/.links exists. <ieugen[m]>ok, so if two files have the same hash they are the same files? <nckx>civodul added some minimum size optimisation (because saving 16k wasn't worth the overhead) IIRC, but the limit is small. <nckx>ieugen[m]: We really really hope so. <nckx>I don't understand the reason behind the question though. <ieugen[m]>I guess it makes sense on a "foreign" distribution where /gnu/store and /home might be on different partitions <nckx>The deduplication applies to the (entire) store and duplicate files in the store are tracked & linked. Guix does not scan your entire drive for things you might have downloaded on Tuesday to see if they are also in the store. <ieugen[m]>I was thinking about the profile in user home - but I guess no files are stored / linked there, they are just referenced as env vars <nckx>Your question was fine :) I'm still not sure what scenario the /gnu/store + /home example represents though. Could you give a concrete one? <ieugen[m]>lrwxrwxrwx 1 ieugen ieugen 47 ian 16 00:01 /home/ieugen/.guix-profile -> /var/guix/profiles/per-user/ieugen/guix-profile <nckx>OK, so, store deduplication is implemented through hard links. These do not work across devices, but they don't need to. <nckx>Right, those are ‘just’ symlinks, I wasn't considering those in an explanation of deduplication. <nckx>Symlinks do work across devices, they really are just text files with /some/file/name in them that are automatically dereferenced by the OS. <nckx>They are used by Guix to set up profiles & environments/shells, but that's not really related to dedup. <nckx>Sorry for the confusion. <lechner>Hi, has anybody had any great ideas for a potential new name for guix-helper-bot? Thanks! <lechner>it also resolves commit hashes (and hopes to do better on those in the future) <nckx>ACTION thinks g-h-b is as fine as any name. <nckx>Nick limits are for weakly humans. <civodul>hmm i guess guix-helper-bot is fine after all <bjc>fruix. so we could have fruix-in-#guix <bjc>snuix would also be good =) <nckx>Gort's name in the original novel? <apteryx>can we get our srfi-64 test runner to print full backtraces? <mirai>descriptive names tend to get outdated as more features get added (over time) <mirai>a 'cutesy' name is more memorable as well <nckx>I think guix-helper-bot is both descriptive & memorable (‘hey, it's the guix helper bot!’) and self-documenting (‘hey, it's a bot!’). People do occasionally reply to sneek. But then I don't particularly enjoy the ‘spot the bots or feel silly’ game in a new channel; joining is stressful enough as is. <mirai>you could also name it after a mineral <oriansj>guix-overlord-bot would be appropriate if it had kick/ban powers <nckx>litharge is a terrible name and I hate it with fierce passion. <nckx>Took me months to consintently remember. <oriansj>mirai: how would that even imply that the account is a bot? <mirai>realgar would be a good cryptic name in the same family <mirai>oriansj: the name itself doesn't <mirai>though I don't think I've seen that account do anything other than <mirai>*litharge set ban/silence on .... <ieugen[m]>how dows guix know which binaries should be on the path? <ieugen[m]>I am working on my first pacakge using the copy build system. 
