IRC channel logs


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.
<sneek>Will do.
<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>then "guix shell wget2" worked
<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?
<the_tubular> seems to be down :(
<the_tubular>I'm getting 504s
<lfam>Just realized the Debian mirror I was using hadn't been updated in months
<lfam>Just terrible UX
<lfam>Thankfully, Guix aims to avoid this kind of problem / attack
<podiki[m]1>the_tubular: same here
<lfam>I think it's absurd for a distro to need to rank mirrors in this way:[results]=4-0
<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
<podiki[m]1>oh right, 502 actually
<lechner>splitting haris
<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
<the_tubular>Attack must have ill intent
<lfam>You're missing the point
<lechner>wow, ftpsync 20130501
<the_tubular>No, I said I agree with what you said
<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>which ones?
<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
<the_tubular>CCP's inspected guix, must be good :P
<lechner>those may be by necessity
<lfam>They'd have to break Git / PGP / Guix codesigning in order to do anything
<the_tubular>What do you mean applied for mirror space lechner ?
<lfam>Totally possible
<lfam>Looking forward to this talk:
<the_tubular39>Ludo's talk are always good
<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 is down?
<lechner>gnucode / yes, see backlog
<mirai>bittorrent for guix substitutes (and package sources) would be a nice addition
<SUPERB[m]>gnucode: yep
<gnucode>ok. just checking.
<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!
<SUPERB[m]>Would you share the page plz?
<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]>ACTION uploaded an image: (7069KiB) < >
<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
<SUPERB[m]>gnucode: How about for a login manager?
<gnucode>You want to use gdm most likely.
<gnucode>You could try the hi-color-icon-theme, but that might not fix the issue...
<gnucode>try installing hi-color-icon-theme
<SUPERB[m]>ACTION uploaded an image: (4696KiB) < >
<gnucode>SUPERB[m]: change %base-services to %desktop-services.
<gnucode>also delete lightdm-service-type
<gnucode>%desktop-services include gdm-service-type by default.
<gnucode>SUPERB[m]: also it might be easier to just use to supply snippets of code.
<SUPERB[m]>ACTION uploaded an image: (4169KiB) < >
<SUPERB[m]>gnucode: Is that correct now?
<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>so is gdm-service-type
<gnucode>SUPERB[m]: type in a shell "info guix RET i %desktop-services RET to see which desktop services are in %desktop-services
<SUPERB[m]>gnucode: I haven't moved them
<gnucode>try to reconfigure. If you get errors, tell me what those errors are.
<SUPERB[m]>Move them under the desktop section?gnucode
<gnucode>also move (service xfce-service-type) right above (service tor-service-type)
<SUPERB[m]>gnucode: ok
<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).
<apteryx>(on berlin)
<PotentialUser-34>hi i installed guix only selecting exwm as desktop environment, how can i switch to a different desktop environment instead of exwm?
<PotentialUser-34>if i want to switch to openbox for example
<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.
<unmatched-paren>hello guix :)
<bumble[m]>which guix module exports origin as used here?
<bumble[m]>how would one find this information for themselves?
<unwox>bumble[m]: we at guixrus have developed a small service for this: https://toys.whereis.xn--q9jyb4c/symbols?search=origin
<unwox>module is (guix packages), you can derive it from location field
<bumble[m]>wow thank you!
<unwox>my pleasure :)
<civodul>Hello Guix!
<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
<xiews>From eshell
<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>(I'm using ivy)
<apteryx>on berlin: build-package-metadata: completed in 22275.590s
<apteryx>that's a bit long
<rekado>(also using ivy here)
<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 ?
<jbv1[m]>ok so its (source #f) nevermind
<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
<apteryx>*btrfs-specific trick
<civodul>apteryx: if you run "./pre-inst-env guix pull" from a Guix configured the way you want, it'll be fine
<apteryx>I see!
<apteryx>thank you!
<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 ?
<ieugen[m]>I checked the docs and there does not seem to be support for that
<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]>and there is also a broader issue here IMO.
<drakonis>there is room for improvements.
<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
<ieugen[m]>guix package -i my-channel/hello ?!
<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
<apteryx>ieugen[m]: ^
<ieugen[m]>for context, this issue IMO has crept up in every pacakge manager out there: java uses 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
<apteryx>then 'guix install -m manifest.scm'
<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.
<apteryx>I now have the signature and header sections to populate with tags, and that'll need a bit more thoughts (see the RPM file format:
<ieugen[m]>the issue is currently with the CLI - but there is a solution/workaround with -e '...'
<apteryx>this is what I have so far for the RPM format:
<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 :)
<apteryx>nckx: you have a fair point
<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 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 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?
<civodul>ACTION committed a FOSDEM blog post draft:
<civodul>feedback welcome :-)
<jonsger>looks good
<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!
<sneek>jonsger, lechner says: /
<jonsger>ah, nice lechner :)
<jonsger>civodul: will trigger a rebuild of every package which uses the copy-build-system?
<guix-helper-bot>"[PATCH] build-system: copy: Add substitutable keyword."
<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>oh ok
<mirai>is it acceptable to pre-generate some files for packages? (these would go into gnu/packages/files)
<cgenie[m]>hello, I'm trying to modify the `copy-build-system` so that it pulls a git repo and then, after the 'install step, unzips all the files. So far I have this: but guix complains with a strange error:
<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
<cgenie[m]>silly me
<mirai>btw you're mixing gexps and assoc-ref
<cgenie[m]>what do you mean?
<mirai>instead of (assoc-ref outputs "out"), use #$output
<cgenie[m]>ah ok
<mirai>for unzip you likely will need to do something similar
<mirai>(let ((unzip (string-append #$unzip "/bin/unzip))
<unmatched-paren>better: #$(file-append unzip "bin/unzip")
<mirai>unmatched-paren: does that work? I've had occasions where it wouldn't work within gexps
<mirai>for modify-phases
<unmatched-paren>oh, wait
<unmatched-paren>you aren't supposed to do things like that anyway
<unmatched-paren>don't directly ungexp packages
<unmatched-paren>(search-input-file inputs "bin/unzip")
<cgenie[m]>search input file fails for me with unzip not found, am i missing it somewhere?
<cgenie[m]>i added to (native-inputs)
<unmatched-paren>hmm, maybe you need to do (search-input-file native-inputs "bin/unzip")
<cgenie[m]>but native-inputs is not in #:key ?
<cgenie[m]>ah ok it's in %build-inputs
<unmatched-paren>never use %build-inputs
<unmatched-paren>it's deprecated
<unmatched-paren>if it's in %build-inputs, it surely must be in inputs
<cgenie[m]>ok indeed, this works, i must have done somethign wrong before
<unmatched-paren>typo maybe
<cgenie[m]>ok works! thanks!
<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>it can be implemented in a phase, I got this monstrosity here that does just that:
<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
<mirai>(ignore the bottom lines)
<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
<mirai>though templatewise
<mirai>I had this prototype:
<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 ...)
<rekado>or pre-post-order
<rekado>from (sxml transform)
<mirai>rekado: what's this pre-post-order procedure?
<mirai>oh, the sxml module
<mirai>yeah, I considered using it
<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>e.g. in axoloti-patcher
<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
<sneek>nckx: wb!
<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>share you config
<sneek>antipode: wb!!
<apteryx>antipode: indeed! glad to see you here
<unmatched-paren>hello antipode :)
<SeerLite[m]>apteryx: my config is a mess but something along these lines:
<SeerLite[m]>ACTION sent a scheme code block:
<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?
<unmatched-paren>SeerLite[m]: yes.
<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...?
<lilyp>no, it's exactly that
<lilyp>delayed is via delay
<unmatched-paren>oh, cool
<lilyp>thunked is via thunks
<jackhill>hi guix!
<PotentialUser-88>Can I compile and install linux kernel?
<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
<unmatched-paren>if you don't already have it in your store, that is
<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)
<unmatched-paren>PotentialUser-88: --with-source=https://... i guess
<SeerLite[m]>jpoiret: I see. Good to know, thanks :)
<civodul>nckx: thanks for the gdcm fix!
<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 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>howdy guixers
<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>ah yes
<nckx>Not some random one.
<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>sounds plausible
<civodul>ieugen[m]: hi! you can run "guix build --list-systems"
<ieugen[m]>how can I get that in a package definition?
<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]>thank you :)
<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.
<ieugen[m]>how does linking work across partitions ?
<nckx>It doesn't.
<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
<ieugen[m]>* different partitions / filesystems
<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]>maybe my question was not ok.
<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]>ls -la /home/ieugen/.guix-profile
<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!
<nckx>Must we?
<civodul>ACTION is being creative
<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.
<unmatched-paren>guix-hivemind-frontend, of course.
<nckx>Nick limits are for weakly humans.
<civodul>ah, then: guix-issue+commit-bot
<civodul>hmm i guess guix-helper-bot is fine after all
<unmatched-paren>The GNUtler.
<bjc>fruix. so we could have fruix-in-#guix
<bjc>snuix would also be good =)
<nckx>(Too obscure?
<nckx>Oh wow.
<nckx>Gort's name in the original novel?
<nckx>I did not know this.
<nckx>s/novel/pulp fiction/
<podiki[m]1>new guix mascot indeed
<apteryx>can we get our srfi-64 test runner to print full backtraces?
<mirai>guix-alice ?
<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
<mirai>there's... litharge?
<nckx>litharge is a terrible name and I hate it with fierce passion.
<nckx>Took me months to consintently remember.
<nckx>ACTION flees.
<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>*chanserv has .....
<mirai>*litharge set ban/silence on ....
<mirai>*chanserv has removed ....
<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.