IRC channel logs
2022-11-04.log
back to list of logs
<Andronikos>Also how does Guix know which system is supported by the package? <vagrantc>what are @code{} @command{} etc. called? <nckx>‘Texinfo mark-up’ in my changelogs. <nckx>And since you're here: I've taken the uncontrollable urg^W^Wliberty of rewriting {greetd-,}pam-mount descriptions entirely, sorry. <[>Is goggles the replacement for bayfront-log? <nckx>‘goggles’ proper was the ‘front-end‘ that ‘renders’ logs.guix to look ‘nice’ and not get us in ‘trouble’ with the ‘GDPR’. The bot is much newer. <nckx>Andronikos: (1) The copy-build-system is popular (2) ‘supported-systems’, which is all of them by default but plenty of examples of restricting those. <morganw`>> A Texinfo source file is a plain text file containing text interspersed with @-commands (words preceded by an ‘@’) that tell the Texinfo processors what to do. <morganw`>They always seemed to be referred to as @-commands in the manual. <vagrantc>nckx: if my trivial lint fixes inspire/compell you to rewrite even better, more power to you! :) <vagrantc>nckx: all i ask is you run guix lint on them :) <nckx>I noticed a missing a(rticle), then I read the rest. <nckx>‘guix lint’ knows better than to complain about my edits. <vagrantc>ACTION admires the relationship nckx has with nckx's tools <nckx>Worryingly, it did complain about NIST serving 503s earlier, but that seems to have been genuinely transient. <nckx>Anyone else notice that? <vagrantc>so my guix lint patch fixes ~10% of issues now, should i submit to guix patches or leave as RFC on guix-devel? <vagrantc>i see @code{} and @command{} used almost interchangeably <podiki[m]>Kabouik: I have not, though I'm aware of that <podiki[m]>looks like it uses node underneath? guessing it would want to load some binaries that likely wouldn't work <podiki[m]>though there is --emulate-fhs now ;-) maybe not a bad idea to further sandbox a browser like that <test1234[m]>Is there a way that can reduce disk usage as much as possible, best like the first install usage? I try guix gc, but this can’t reach my goal. <user_>I need to fix a single file in store <user_>there is a specific command to do this? <user_> /gnu/store/yjllxib1fm3zqkwmr5j4lpxhz3zqsjjz-guix-e3280ae/build-aux/build-self.scm <user_>this file is a bunch of zeros her, I need to fix this but gnu/store is not writable <podiki[m]>the store is only writeable by root (the guix daemon) by design <user_>repair is failing for some reason <user_>the file still with a bunch of zeros after repair <user_>there is a change the the file in ci is damaged? <podiki[m]>are you having some problem and think this is the cause? <anschlussy>One thing I've been curious about is what the concept of a package manager actually is. Is there a firm definition that satisfies all types of package managers? <lilyp>a package manager is any program that installs, updates and removes other packages <podiki[m]>user_: not sure, does look like you have a corrupt file <lilyp>putting the files in the right place <cnx>is it possible to make user channel follow the system one? <abrenon>the mention of --emulate-fhs in guix pull --news presents it as an option for guix shell; wouldn't it make sense for other commands like guix pack ? <rekado>cnx: what do you mean by “follow”? <cnx>i mean for it to track the same channel system guix is tracking <cnx>so guix pull as root will sync for both <rekado>you can link the profile at ~/.config/guix/current to root’s profile <roptat>to the one in /var/guix, because the user can't access /root/.config <roptat>(/root/.config/guix/current should be a symlink, you simply target the same thing) <elevenkb>Ok, I've sucessfully installed GuixSD for the first time. <rekado>what should we name *collections* of texlive packages? I think we may not want them to start with just “texlive-” to avoid conflicts with actual texlive package names. <nckx>I was about to say texlive-*-collection so if you're not against the texlive- namespace at all, sounds like a plan. <nckx>elevenkb: Congratulations! <nckx>Just FYI, we don't call it GuixSD. <jonsger>ACTION still likes the GuixSD name :) <roptat>oh, is that a system for the raspberry pi that you install on an SD card? (: <elevenkb>Issue is that my keyboard-layout entry doesn't work. <pkill9>does GuixSD contradict Guix System? <pkill9>idk, does GuixSD not make sense now <pkill9>I feel like, Guix System Distribution could be a subset of Guix System <roptat>I think the reasonning was that GuixSD sounded like something totally different from Guix, but there's not that much difference between Guix System and Guix <nckx>elevenkb: Can you paste your configuration? <roptat>the only difference is you can't reconfigure on a foreign distro <roptat>ACTION just pushed the monthly translations update :) <rekado>“Guix System” is a nice name, because it really is all about the “guix system” commands. <rekado>you don’t need to run Guix System as your distro to use Guix System (in a “guix system container” or VM) <rekado>the name “GuixSD” was a compromise. I thought the name “GSD” (for GNU System Distribution) nicely mirrored “BSD”, but some people (I want to say rms, but maybe there were more) thought it might be misunderstood as a jab against BSD. <rekado>this came after just “GNU System” was rejected. <rekado>and I think with “Guix System” we’re pretty close to where we wanted to be initially <nckx>I wasn't involved in the GuixSD naming but it's obviously aquired some (wholly undeserved) patina as ‘the beloved original name’ when actually, no, nobody involved loved it that much, and I'm also glad it's buried. <rekado>“GuixSD” always seemed a little weird to me; once past the odd pronunciation of “Guix” (already a phonetic obstacle) you had to abruptly stop on an “x” and switch to acronym mode with “SD”. What a bumpy phonetic ride! <nckx>Could be worse. Could be Guixotic. <nckx>rekado: That's a good point I hadn't considered. Ride out the scary exotic Fresh wordplay with a reassuringly boring plain English word. <civodul>it's funny how people still mention "GuixSD" years after it's been removed from the web site <rekado>nckx: exactly. Makes the whole name seem not as weird. <rekado>“patina” is a great concept, and I think it totally applies here. <rekado>(that gunk in your moka pot is not patina) <jonsger>I think many people (including myself) think/are used to names as a stable thing <rekado>when a name is stable but the thing it names changes, is it still appropriate as the name of the changed thing? <abrenon>ACTION wonders about the pronunciation envisioned for Guixotic <xd1le>Like it's so good cause it's so bad :D <nckx>elevenkb: Just FYI I'm building it, but that apperently implies building all of GNOME. My suspicion is currently on ‘norman’. Have you tried with something less… exotic? <elevenkb>It's in the /gnu/store/*-xkeyboard-config-2.34/share/X11/xkb/rules/evdev.lst <nckx>Sure. It's a wholly valid layout & life decision, did not mean to imply otherwise. <nckx>Problem is I don't see any obvious mistakes, so at straws we grasp. <elevenkb>nckx: oh to joys and sorrows of the path towards GNUrvana. <elevenkb>Let me switch to sway actually (which is where I eventually want to end up). <nckx>Reason I asked ‘where’ above is because there are still cases where it's ‘expected’ (=unfixed) for GRUB not to load your layout, but a DE/WM/compositor with the full power of XKB behind it definitely should. <elevenkb>How long should it take to run your first guix pull (on a 15Mbps connection)? <nckx>Minutes. But that's the answer for subsequent guix pulls on many machines. It is not very optimizised. <nckx>elevenkb: (Yes, this is really how long it took to test) When I change nothing else but "us" "norman" → "be" "nodeadkeys" the layout changes, so it's definitely the culprit, even if it shouldn't™ be. <roptat>nckx, the first guix pull needs to clone the git repo, which can take a bit longer than subsequent pulls if you do them frequently <nckx>It also has to authenticate ‘all’ commits, I know. But people often expect apt-like times, or network-bound ones, and I wanted to frame expectations. <elevenkb>nckx: (with-teary-eyed-smile "thanks for letting me know") <gabber>i am unable to (cross-) compile a Guix image for arm architecture (kernel module not found "ahci"). which seems odd since ahci is an intel specific thing? i tried the following command: `guix system --target=arm-linux-gnueabihf image ~/src/guix/gnu/system/examples/beaglebone-black.tmpl` (the path leads to the example in the guix source tree). what am i missing/doing wrong? <test1234[m]>Is there a way that can reduce disk usage as much as possible, best like the first install usage? I try guix gc, but this can’t reach my goal. <nckx>IIRC the problem is that cross-compiling (as opposed to --system) accidentally the host architecture for modules. <nckx>For the Guix meaning of host. <civodul>nckx: should we make "ahci" conditional? <gabber>civodul: not sure if i understand AHCI correctly, but if it's an x86 only thing then i guess, yes, moving it into the if-x86 block below makes sense <civodul>gabber: i'm not sure it's necessarily x86-specific; maybe it just happens to be disabled on ARM for some reason <civodul>we should check and add the appropriate conditional <gabber>civodul: agree! btw WDYM "disabled on ARM" -- do we use different source repos for different architectures? where/how would ARM disable such a module? <gabber>btw: to correctly build only "uas" and "xts" modules can be included in initrd-modules -- otherwise the build fails with the same fail message (kernel module not found) <civodul>gabber: i mean disabled in the ARM builds of Linux-livre <apteryx>uh: sudo strace -p 16666 -> strace: attach: ptrace(PTRACE_SEIZE, 16666): Operation not permitted <nckx>civodul: Intuitively I'd say so. I don't think there's any logic in how we currently configure kernels. That's not criticism; I've just asked a few times now and ‘nobody’ seems to have a reasoning for what goes where. <nckx>Like %default-extra-linux-options implies some kind of layering or consistency that just isn't there, because it's thrown on top of ancient (and very magic, possibly cargo-culted) .configs that differ wildly and undocumentedly by architecture. <civodul>apteryx: what does /proc/sys/kernel/yama/ptrace_scope say? <nckx>This sounds more negative than intended so I'll stop. I'm just trying to express the depth of my confusion, nothing more :) <nckx>And I know my way around Linux. <nckx>I've been around the block layer. <nckx>My blind spot is Linux on non-x86, but I don't think that can cover this. <tricon>nckx: i feel ya. i'd quite like to get into ARM/RISC-V archs; but at this moment, i feel more inclined to hack on x64 Hurd than work with other archs at that level. of course, there's so much work to do on x86 Hurd as-is. <nckx>Oh, always nice to meet a Hurd contributor in the wild. <nckx>Although I guess this channel is next-door to the zoo. Still. <tricon>nckx: not one quite yet! but it's on my radar. <tricon>microkernels are exciting. need to read up on the latest approaches, though, as there's an oft-speculated performance hit with them. curious where/how practical those complaints are in modern times. <apteryx>my emacs has started throwing the error: Invalid handler in ‘file-name-handler-alist’ when I visit /tmp. Any clue? <user_>podiki[m]: yes I have a corruptd file, I cant fix it yet <apteryx>I was trying to strace a process started in a 'guix shell --pure' from outside of it <nckx>user_: I don't even remember what I suggested over mail, but did it work? <nckx>Oh, right, pull a random old guix-current. <elevenkb>Can one run ``guix system reconfigure" as non-root? <florhizome[m]>elevenkb you can run guix system build. You need the root access for deployment mainly <user_>Oh it was you in th mail list nckx <user_>But its curious nckx using your idea it reference another place in the history which is "/gnu/store/vg5b37za8np63s03g98b8rw60h3vv2am-guix-04f8295/build-aux/build-self.scm" <user_>but this 'version' of the file still corrupted (just zeros) <nckx>I wasn't expecting that. Do *all* previous current-guix-??-link/bin/guix's fail that way? <user_>Yep, now Im trying to check i all build-self.scm in my gnu/store are corrupt (I think this is the case) <nckx>It's *possible* that they were all identical and hence deduplicated, but really, (pleading voice) they can't all be broken… <nckx>Right. You beat me to it. <nckx>Good plan. Away for now, TTYL, and good luck. <nckx>ACTION silently mouths ‘halp’ at civodul. <nckx>It doesn't even detect absence. <stevenroose>Anyone know how to install rustup in Guix? There doesn't seem to be a guix package for it, which is weird. And cargo install rustup somehow segfaults for me <unmatched-paren>stevenroose: well, it downloads binaries which use normal ld, not the ld-wrapper <unmatched-paren>> I talked about this before with some people using NixOS, and their opinion was that rustup just didn't fit within the NixOS mentality, so I didn't pursue it further <stevenroose>are you aware of a guix package that contains the source code? <stevenroose>guix packages -s rust | rg "src" doesn't seem to give anything <user_>all build-self.scm in my store hav the same md5sum <user_>that is no one is correct :( <rekado>abrenon: it’s just an example name <rekado>abrenon: but I do have a real world rnaseq example in doc/examples/pigx-rnaseq <nckx>user_: Yes, so do mine (but a different hash, of course :) <nckx>user_: There's a horrible thing we could try: downloading that file from Savannah, remounting your store read-write, and copying it there by hand… <nckx>florhizome[m]: The UI or the mail queue? <rekado>nckx: is the error that “guix build --repair” has no discernable effect? <florhizome[m]>the queue I think. I have been waiting for a whole day now to see an opening mail arrive <rekado>ACTION has never used “guix build --repair”, only ever “guix gc --repair,contents” <nckx>rekado: Could it be related to deduplication? <nckx>rekado: That didn't work for the reporter (user_) either, although I'm not going to look into that. <rekado>IIUC the “guix gc” command must be used as root. I don’t know what mechanism “guix build --repair” uses. <nckx>guix gc errors out if you're not root. <jackhill>my experience with repair is that it doesn't work in the context of grafts <nckx>(Passing ‘--no-grafts’ as done in my example does not remove them from that context, is the problem.) <civodul>ooh, repair relies on substitutability, and grafts aren't substitutable <abrenon>rekado: thanks ! is that from a newer version ? I've tried 0.5.0 and am consquently looking into the sources for this one <nckx>civodul: Now you say it, it's so obvious, so thanks for admitting that 😃 <abrenon>the question I was hoping to answer looking at this actual example was about the syntax for free inputs in workflow <nckx>I was expecting the mismatch to be detected, though, but I can live with that assumptions being invalid. <jackhill>I have had repair repeatedly download the same substittue though. Is that part of the same shortcoming (I thought it was understood which is why I haven't created a report)? <nckx>That's actually the behaviour I was ‘expecting’. It's a bug, but it's not strictly the same bug, IIUC. <rekado>abrenon: when a process declares an input and no connected process provides this input it is said to be a free input. “guix workflow” will abort and ask the user to provide that input (if there is no matching file) <user_>13:26 < nckx> user_: There's a horrible thing we could try: downloading that file from Savannah, remounting your store read-write, and copying it there by hand… <abrenon>ooohhh I see so there's no argument passing from workflow to processes, they help themselves directly <user_>I was thiknig something lik this but I dont know exactly how to do this.. I will need to try this at night <user_>Im at work for now, can really crash my computr if soemthing goes very bad <abrenon>I think I was viewing workflows as "main" functions a little too much <nckx>user_: It won't, but totally agree we shouldn't invite risk in unnecessarily. <rekado>abrenon: yes, a workflow is how processes are connected to one another (and properties that apply to this collection of processes, such as cache keys). Everything we want is really in the processes, including inputs. <rekado>abrenon: I think there might be value in being more explicit about inputs and outputs of a workflow, but I can’t think of a good reason to make this declaration redundant. <rekado>that said: I’d be happy to discuss the merits of different strategies for the GWL over at #guix-hpc or on gwl-devel@gnu.org. The basic premise was “what if we didn’t bring Guix to workflows, but instead bring the workflows to Guix?”; pretty much everything else is negotiable. <abrenon>no I don't think there'd be much added value either, but the overall syntax might deserve an example in the documentation <abrenon>I didn't want to hijack #guix into #guix-hpc, I was initially hoping I was just being slow getting the syntax and a one-line answer would solve my problems : ) <elevenkb>I can't launch any terminals, tried ansi-term in emacs, gnome-terminal, the Xfce terminal (in both GNOME) and Xfce <elevenkb>M-x shell does work though and tty as well. <elevenkb>When I launch gnome-terminal, I get an error: "Failed to open PTY: No such file or directory" <elevenkb>M-x ansi-term RET RET gets me a blank buffer. <tricon>elevenkb: are you able to open a shell by other means outside of Emacs? <nckx>Are /dev and /dev/pts mounted? <elevenkb>To clarify the blank buffer is also unexpected behaviour. I should at least see a shell prompt <tricon>what happens when you CTRL+ALT+F# to another vconsole and sign in? <nckx>(You can open /proc/mounts in emacs if all else fails.) <tricon>elevenkb: sorry, just realized i had missed/misread some of your messages. <elevenkb>nckx: there isn't a /dev/pts subfolder under my /dev folder <tricon>elevenkb: when you run `ansi-term', do you get a minibuffer query as to which shell executable to run? <tricon>in `shell', what does `echo $SHELL' return? <nckx>well_theres_your_problem.ogg <nckx>Did you override all default file-systems or something? <nckx>Make sure you're appending (or consing, if that's your fancy) to %base-file-systems. <nckx>Currently so do I, so no money to be made I'm afraid. <elevenkb>I didn't do that. Thank for the supoort nckx, tricon, yalls are too kind. <tricon>now i want a "well_theres_your_problem.ogg" audio clip on a sound board. <tricon>i should make a touch sound board with an Arduino or something. <nckx>elevenkb: Erk, don't make me blush. Just pay it forward. :) <nckx>tricon: $partner got an Arduino. That's actually a fun project idea. <tricon>nckx: you gave me an idea in return: should i ever get married, announce it with: `declare -r partner="NAME"' <nckx>I'm sure both people who get it will be very happy for you. <silicius>Is it possible to somehow use the mesa package from core-updates branch? Just need mesa>22 <Korven[m]><tricon> "nckx: you gave me an idea in..." <- peak linux moment <silicius>Mesa from core-updates builds succesfully while using an inferior, but inferior packages can't be used with input-rewriting... <f3n1x>i've tried to run 'guix home reconfigure my-home.scm ' but ... <f3n1x>ah, forget about it... found the fix for my simple issue. ThX anyways ! <nckx>Sigh. Look. It's GNU^WLinux. <podiki[m]>silicius: you can make local copies of the package definitions needed, think it is libdrm, wayland-protocols, and mesa itself if I remember, and use them locally <silicius>It seems to be working, already got it build successfuly. Now I'm wating for the package-rewriting to finish <nckx>I don't see the shortening (but's that good, it's very short already). <nckx>Oh, because I screwed up the simple act of reading. <nckx>I'd've just gone with ‘Arbitrary-precision number library’ or something, but that's not to say it's better than yours. <vagrantc>nckx: i'm just cutting off cruft that is also present in the description, figuring it's no real data loss ... but ... i'm not sure what the "important" parts are to cut off <vagrantc>let's just keep shortening it ... Arbitrary library <vagrantc>if you really want a challenge... gnu/packages/bioconductor.scm:3641:14: r-drimseq@1.24.0: synopsis should be less than 80 characters long <vagrantc>they're both rather specialized packages and i'm not sure what to keep <vagrantc>the remaining synopsis that are too long is getting awfully few, though :) <nckx>You'll have to make up some new arbitrary rules soon. <nckx>‘Only 4 vowels per line.’ <vagrantc>wow, i managed to misread "LESS THAN 80 characters long" ... i shortened kuserfeedback to 80 characters. <nckx>Only uses 4 different vowels though 👍 <nckx>‘kuserfeedback is’. There. <henrytill>hi, new user here, installed guix as a package manager on debian testing, followed manual for locales and whatnot, installed guile and am getting "guile: warning: failed to install locale" when i run it <vagrantc>oh-ho, @acronym, I see you lengthening the gssdp description <vagrantc>well, nested string-replace-substring isn't going so well, should probably figure out how to do this correctly <nckx>I still maintain that mark-up commands count here 🤷 <nckx>unless they make the line, even after adding a newline before ", way over 80 characters somehow. <vagrantc>i guess technically, the @code still adds a couple characters... hrm. <nckx>henrytill: Are you on a Debian derivative? <vagrantc>but when you "guix show" something with @code or @acronym, it isn't displaying the full length <vagrantc>henrytill: have you logged out and back in again? <henrytill>yep, debian testing, logged in and out (several times) <nckx>henrytill: If so, check LANG. By default I think it uses the then-nonstandard C.UTF-8 locale, which didn't exist when that glibc was released. It was added in a later version but that's not the one Guix uses less. <vagrantc>henrytill: what locale is running on your debian system? <sneek>lfam, nckx says: Hi, I saw you last checked the btrfs balance status for the SSD pool on berlin. Were you just curious, or had you noticed something odd? <sneek>lfam, nckx says: …never mind. I think. <sneek>lfam, nckhexen says: Any opinion on Documentation/trace/rv/runtime-verification.rst? I'm a bit… overwhelmed. <nckx>henrytill: Choose one from $GUIX_LOCPATH/* . <nckx>henrytill: Could you run ‘strace guile’ to check what it actually, erm, checks before printing ‘failed to …’? <nckx>It should be loading something from GUIX_LOCPATH, at least. <nckx>E.g., strace guile 2>/tmp/log; less /tmp/log <henrytill>vagrantc: setting LC_ALL didn't help unfortunately <henrytill>suspicious: openat(AT_FDCWD, "/home/ht/.guix-profile/lib/locale/2.33/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <vagrantc>i've definitely had challenges with this issue myself ... don't seem to lately <nckx>henrytill: Oh, your glibc-locales is out of date. <nckx>Try upgrading it, or even better, *all* packages in your profile at once. <henrytill>oh yes i forgot to upgrade my locales after guix pulling! <nckx>Yeah, this is a mildly annoying property of glibc locales. <nckx>It's mentioned in the manual near GUIX_LOCPATH I believe. <henrytill>yes, in fact, i context-switched and forgot to do it <Luchadoritos>Hey Guix! I need to install TensorFlow with version newer than 2.7.0 (currently Guix has 1.9.0). I've been having trouble with an error system-error "mkstemp " "~A" ("No such file or directory") (2) after running "guix build tensorflow --with-latest=tensorflow" similarly if I replace with-latest with --with-commit. Any hints on what I can do? <vagrantc>nckx: now, on to more important but trivial matters ... what's your argument with ignoring @code, et. all in the case of that lint check? <lfam>Regarding CONFIG_RV (kernel runtime verification), I didn't end up enabling it. It wasn't clear to me if it's intended to be used all the time or just while developing <nckx>Humph, my kernel just panicked. <lfam>I joined just in time. Which version? <lfam>I actually joined because I'm curious if Guix is planning on a Guix Days conference around FOSDEM this winter. I did see the discussion about the booth at FOSDEM <nckx>lfam: Oh, don't worry, this has nothing to do with Guix or you! I think my root file system's hosed again. <lfam>That's even worse of course, lol <nckx>Yes, I might be AFK a bit. <nckx>This all happened after running ‘guix build tensorflow --with-latest=tensorflow’ so it's clear who's to blame! <vagrantc>- (synopsis "pdfTeX's escape features for plain TeX") <vagrantc>+ (synopsis "Escape features from pdfTeX for use with plain TeX") <jackhill>vagrantc: I think the second one reads better (and not just because it starts with a capital!) <lfam>In the first example, "escape" is clearly modifying "features" as an adjective <lfam>In the second example, it could also be read as a verb <lfam>Perhaps in a humorous way <jackhill>oh, I didn't think of that. Maybe it's less clear 🤷 <vagrantc>i'm not terribly invested, other than making guix lint output less noise and more signal. <rekado>Luchadoritos: it is not at all trivial to build a newer Tensorflow <rekado>you will not be able to build anything newer than 1.9.0 with the package definition we have. <rekado>I have some WIP for Tensorflow 1.15.5, but I don’t think I’ll return to work on it. <rekado>we really need to package bazel and all its Java dependencies; then patch the Tensorflow build system to allow for system libraries to be used instead of having bazel download them all from the internet. <Luchadoritos>rekado: I see. Thank you very much for your input. I'll find some (inelegant) way to do my work. <rekado>if you find any way towards a newer Tensorflow in Guix I’d be happy to help <rekado>I’ve lost most of my teeth while chewing on this problem for the past years. <Luchadoritos>I looked through the IRC+issues history. It seems that Bazel is not bootstrappable? I don't know the system well enough but I'm willing to spend time in this during the weekend <Luchadoritos>I didn't look to see if these packages were freedom respecting btw. Forgive me if I say something out of line <rekado>bazel is free software and it should be possible to build it all from source <rekado>it just has a lot of Java packages as inputs, and we can’t just take the pre-built jars <Luchadoritos>Nice! Time for me to learn about build systems. I have a waays to go on this front. <rekado>we don’t have a whole lot of Java packages in Guix because building them completely from source is often really tedious