IRC channel logs
2022-11-27.log
back to list of logs
<minima>and log out and in again or source the profile file, as i've been just told above <minima>unmatched-paren: hm interesting, i've been using channels on my main system, whereas i'm now creating some more generic system images... i hadn't thought of guix home for this scenario <minima>ACTION looking into home-channels-service-type <minima>the example provided at the link above doesn't include any 'introduction' - wouldn't that result in an error? <mbakke>minima: /etc/guix/channels.scm will be used if no user channels are defined <minima>mbakke: i did add an extra channel to my /etc/guix/channels.scm - but that seems to be ignored if i run "guix search package-from-extra-channel" as a user or as root - maybe i need to source a profile file first? <minima>unmatched-paren: oh ok, cool, thanks <mbakke>minima: it should "just work" as long as you have actually pulled with that channels.scm ... and are using ~/.config/guix/current/bin/guix (try `type -P guix`) <minima>hm, interesting, no, it doesn't seem it works - i'll try and redo all the steps to see if there's anything i missed <minima>ok, i launch a freshly built image with qemu and run 'guix pull' as root, i can see my extra channel being pulled from, yay <minima>despite a successful pull, i wasn't able to see any package from my extra channel when i tried earlier <minima>sourcing ~/.config/guix/current/etc/profile fixed it - i'll try again in a min and see what happens (before and after sourcing) <omlet[m]><unmatched-paren> "i might make an attempt to..." <- Please <minima>ok, quick update from my side: no need to copy my '/etc/guix/channels.scm' to my '~/.config/guix/' - 'hash guix' did it <minima>after 'guix pull && hash guix', i can see the packages from all my channels, as expected <minima>and guix does mention 'hash guix' as a hint, i should have noticed that when i tried earlier! :) <minima>when i say guix, i mean the output of 'guix pull' <old>Lately my emacsclients can't connect to their daemon <old>I use a shepherd-service that fork "emacs --fg-daemon" <old>But my clients can't find the daemon's socket <old>well nmv it seems my emacs configuration was wrong and prevent emacs from creating the server socket <lechner>sneek / later tell unmatched-paren / thanks for the reference to the home service for channels! <oriansj>the key bit is that kodi does absolutely have to be displayed on the screen <lechner>oriansj / Hi, how about a "one-shot?" with auto-start? from the Shepherd? <zamfofex>Oh! đź What have I done to deserve the fabled sneek greet? <oriansj>lechner: seems reasonable, lets see if it works <lechner>oriansj / "simple-service" at the bottom <lechner>oriansj / i think you also need a (start) command <oriansj>lechner: well I have (start #~(make-forkexec-constructor "/root/kodi.sh") <oriansj>which should just run /root/kodi.sh right? <oriansj>the whitespace probably could be fixed (you need to scroll to the right to see it) <oriansj>no worries, It is certainly something I should have improved. <oriansj>well I got error: shepherd-service: unbound variable <oriansj>and am attempting to figure out the why <lechner>oriansj / it's in (gnu services shepherd) <lechner>oriansj / doesn't the slim-service-type compete with the startx in kodi.sh? <oriansj>lechner: probably, I just haven't commented it out yet <oriansj>lechner: that results in: source expression failed to match any pattern <lechner>oriansj / how about (service shepherd-service-type ...) instead of (shepherd-service ...) <oriansj>lechner: that also gets: source expression failed to match any pattern <oriansj>and the examples seem to all be using just (shepherd-service ..) <AwesomeAdam54321>sneek: later tell dec0d3r: If you need any help switching to the shepherd as the init system, you can ask me <lechner>oriansj / doesn't the (simple-service stanza at the end name the 'kmonad-service' elsewhere in the file, but it is then included with that name as kmonad-service ? <lechner>it may be (services (list (append kmonad-service ...))) <oriansj>lechner: that is what you would do if you defined the shepherd-service in a separate module <oriansj>but as I am doing everything in a single file, the inner contents is the bit I would be wanting <lechner>oriansj / okay, maybe that's above my pay grade. i am very new to guix <oriansj>as this is about as simple of a usecase possible <oriansj>literally just run a script in a known location on boot <lechner>oriansj / maybe so. either way, i am sorry i could not help you today <zamfofex>Hello, Guix! Does anyone know if it is possible that âldâ is trying to link against the native glibc as opposed the the crossâbuilt glibc when building libstdc++, and that it happens to work âby accidentâ on glibc 2.33 (and not on 2.35) because it links it dynamically, and the symbols just happen to line up right? The target architectures are âcompatibleâ on the CPU level (target is i586, and host is x86â64). <oriansj>lechner: I appreciate your help, now to figure out the little stupid thing that I am missing <zamfofex>sneek: later tell civodul: Do you know if it is possible that âldâ is trying to link against the native glibc as opposed the the crossâbuilt glibc when crossâbuilding libstdc++, and that it happens to work âby accidentâ on glibc 2.33 (but not on 2.35) because itâs shared and the symbols just happen to line up right? The target architectures are âcompatibleâ on the CPU level (i586, x86â64). <lechner>zamfofex / wow, that would be some detective work! <oriansj>lechner: it is a pretty common bug when running guix on other distros <zamfofex>sneek: later tell civodul: Note that âlibpthreadâ does contain the symbol âpthread_createâ on host glibc 2.33, but âlibcâ doesnât on crossâbuilt glibc 2.35 â it only has â__pthread_createâ, so it doesnât seem unlikely to me. Iâd have to check whether âlibcâ contains âpthread_createâ on host glibc 2.35, and if it does, that would seem like a sensible conclusion. <lechner>oriansj / it's amazing. i believe it would be impossible on those foreign distros alone, with modern multi-arch paths <AwesomeAdam54321>If there was a Guix daemon written in Guile, would derivations still be necessary? <zacchae[m]>Hi Guix! I'm finally back and am sad to say I've been gone so long because the synapse package broke <zacchae[m]>On an unrelated note, I set my mom up with an install (so I can fix her problems remotely), and it seems the gnome activites does not show gimp <zacchae[m]>Is that a problem upstream or in the package def? <zacchae[m]>I tried looking at other defs of packages that DO show up in activities, but they don't seem to do anything special about .desktop files <zacchae[m]>Well wouldn't you know: logging in&out didn't fix the gimp icon showing up, but rebooting did <omlet[m]>In guix have the nix same (virtualisation.podman = true;)? <sneek>Welcome back unmatched-paren, you have 1 message! <sneek>unmatched-paren, lechner says: / thanks for the reference to the home service for channels! <omlet[m]>unmatched-paren: The nixos have with option <omlet[m]>unmatched-paren: Yes, but i speak for the website <omlet[m]>in my opinion I think there are still many things to improve on guix <omlet[m]>Bit i thonl this os good for help the guixos <omlet[m]>I think is better create the forum guix , not see the problem for me replace email for forum <unmatched-paren>forums are much harder to host, more annoying to post to (usually requiring a web browser and JS) <unmatched-paren>well, i don't know if they're harder to host, but gnu provides mailing list services for free <omlet[m]>unmatched-paren: Annoying its is good, but the information can not is annoying good <omlet[m]>being anonymous is good, but there are information of public interest that would be a hidden penalty <rekado>still having problems booting the honeycomb :( <rekado>trying with a more recent Guix, but thatâll have to wait for several rusts to be compiled first <jlicht>so setting up a new system with heaps and heaps of RAM. `/tmp' as tmpfs (and orthogonally, with zram), good idea or stupid idea? <mbakke>mothacehe: do you know what's going on with cuirass not evaluating jobsets? <pkal>Is there some Guix meta-package that adds all the default packages like coreutils? <pkal>(for certain values of "default") <nckx>pkal: You nicely pre-empted âthere's no such thing as a default package, make your own listâ. %base-packages has some nice-to-haves. I guess you could use it from the command line with -e '(@ (gnu system) %base-packages)'. <pkal>nckx: Hmm, but nothing I could pass to guix shell? <tribals>I'm trying to migrate my existing virtual machine (cloud) to Guix System. Currently, it runs Debian. But I have no idea whether I can install Guix on it. I can't just make bootable flash drive and plug it into machine as it is virtual one, rented from cloud provider. <nckx>tribals: If you can boot an ISO, you can cleanly install Guix. If you can't, well, I don't personally like the result, but you can run âguix system initâ from any existing OS⊠<nckx>pkal: I'm afraid I don't understand the problem, could you elaborate? <tribals>nckx: do you mean `guix system init` directly to root / ? <nckx>tribals: Yes. But I strongly recommend booting the ISO if at all possible. Some providers allow you to upload your own (so you can boot Guix's), but I've installed most Guix Systems from the SystemRescueCDs or Debians that almost every single provider offers. <nckx>The ci.guix aarch64 nodes were deployed by running âguix system init /â from the OEM's OpenSuSE installation. <nckx>That method works, most of the time, but you get a lot of left-over cruft from the previous distribution. <nckx>pkal: I just tested a very simple manifest, and it worked. But it didn't do anything fancy. <nckx>Just (packages->manifest %base-packages). <nckx>If you get errors, please share them. <tribals>nckx: thanks, I will check for ISO booting, but AFAIK it is not supported (may be to change cloud provider?). And I will try `guix system init` approach. <pkal>nckx: My mistake was in thinking how I could use --export-manifest to generate the mainfest file. <nckx>That does âdereferenceâ the list, yes. <nckx>If that's a problem, I think you'll have to avoid --export-manifest altogether. <nckx>TIL âguix-iconsâ is a thing that is. <pkal>nckx: No, it works, I'm just used to using --export-manifest. <pkal>The actual issue I am trying to solve is building Agda. It appears that there have been changes that aren't reflected in the current Guix definition that break stuff. They do have files related to Nix, so I guess the best strategy is to reverse-engineer that? <nckx>Yeah, I'd start by diffing the Nix files in the last working version with those in the latest, assuming the Nix files are that old. <nckx>âThe interactive mode is no longer under active development. Use at your own risk.â Always a good sign of project health đ <pkal>Haskell stuff is broken, I keep getting missing dependencies. guix import didn't help much either :/ <nckx>Is there an open bug about the issue you're trying to fix? <nckx>Don't get me wrong, I'm very happy you're investigating & trying to fix it rather than just complain âit's brokenâ :) <pkal>nckx: Not to my knowledge, but I don't have enough information to open a bug report yet. <pkal>This is a development release, so it doesn't affect Guix directly yet <nckx>Ah, I (mis)interpreted it as âthe current Agda in Guix builds but has bitrot beyond utilityâ. <stevenroose>Anyone aware of a Guix package definition for Servo? <nckx>pkal: I can't even get that far :) I'm not a Haskeller, at all. Does the suggested âghc-pkg checkâ do anything useful? <nckx>Oh, I'm on master, which calls itself 2.6.4, not 2.6.3. There's no 2.6.3 tag⊠<pkal>Sadly I know less about the internals of agda than of Guix, so I cannot add much :/ <pkal>I have noticed that the order of the packages I list in the manifest file appears to matter. E.g. when I moved ghc-alex to the beginning of the list, it suddently appeared when I loaded the manifest. <nckx>Heh. Ditto-but-opposite. <nckx>Did you run âcabal updateâ? <lechner>lilyp / Hi, thanks for defending Guix! Did you fall for a provocation? <pkal>nckx: No, I just started it right now... <pkal>"cabal update" changes nothing <nckx>pkal: OK. I did, because I basically couldn't continue otherwise. But now make fails with: text-icu-0.8.0.2-IMG16tfmCdjANBCW5ulhyc failed during the configure step. The exception was: ExitFailure 1 <pkal>nckx: I fixed that by adding the guix package icu4c <pkal>It appers this is a new dependency <nckx>OK, I was wondering why pkg-config was missing from your manifest. <nckx>Eh, but I'm using your manifest with icu4c. <elevenkb>hey everyone. has anyone added an hp printer with the standard cups/hplip setup w/o gnome control center (or similar)? <nckx>cabal: The program 'pkg-config' version >=0.9.0 is required but it could not be found. <nckx>elevenkb: What's your problem? <elevenkb>nckx: I can't run any of the hp gui apps, e.g. `hp-setup `hp-wificonfig` etc. they complain about GUI support. <lechner>elevenkb / i have, but only hardwire. it's a Laserjet 1320nw <elevenkb>lechner: not at all, anything that allows my laptop to connect to the hp printer will do. <lechner>elevenkb / mine was auto-detected in the web interface without hplip present, i believe <nckx>There's no reason to use the hp-* tools for that. I'm not even sure they woork. <elevenkb>ok, but if I use the cups interface on localhost:631 and click on "Printers" I'm told to use cupsctl to enable that page. <nckx>See (guix)Printing Services, web-interface? #t. <nckx>I could show you my CUPS configuration but it would make you go mad and smash your printer with a baseball bat. <nckx>pkal: Before I ^C'd make because it was freezing my low-RAM machine, it was building things like utf8-string and unordered-containers (sic). So it's clearly not using the Guix tooling. But then, we are unsetting GHC_PACKAGE_PATH, so I can hardly blame it. <elevenkb>nckx, lechner: is it possible to check if `web-interface?` is presently set to `#t`? <yasht>Does anyone know how to create a shepherd service that runs just before shutdown? <lechner>elevenkb / it would be in your declarative configuration <nckx>Just look in your system configuration, under cups-configuration. <stevenroose>jgart[m]: yeah I meant servo.org, they seem to have an experimental version you can test, it's available for download on their website <elevenkb>:p, i meant not by checking my config file. Basically I'm uncertain about whether I ran `guix system reconfigure` the last time I changed my config to add `(cups-configuration (web-interface? #t))` to it. <pkal>nckx: that might be a good explanation, sadly it appears that cabal doesn't want to use the "system packages" as provided by Guix? <nckx>elevenkb: Ah, no, it's a permissions issue, not enablement issue. <nckx>All true, but will not affect printing or detecting printers in the slightest. <nckx>I mean, until we get that page sorted. <lechner>nckx / what will not affect detection of printers, please? <lechner>elevenkb / just reconfigure and issue herd restart cups <nckx>elevenkb: This âcupsctlâ lie, what does it say, exactly? <nckx>And what does your cups-configuration currently look like? <elevenkb>"The web interface is currently disabled. Run "cupsctl WebInterface=yes" to enable it." <nckx>B-b-but. It clearly is enabled if you can connect to :631. <elevenkb>                    (cups-configuration <elevenkb>                     (web-interface? #t) <elevenkb>                     (extensions <elevenkb>                      (list cups-filters hplip))))`` <nckx>One more line and you would have been botted. Use paste.debian.net next time :) <lechner>elevenkb / i would ditch hplip. what model is your printer? <unmatched-paren>nckx: is there anything else i need to do for commit access or do i just need to wait for my request to be considered by the Grand Cabal Of Maintainers? :) <nckx>elevenkb: Just to make sure I understand: you browse to the Web interface, then click on the âPrintersâ tab in the Web interface, then get an error message telling you to enable the Web interface? <lechner>unmatched-paren / i thought you had to kiss a goat on the mouth <nckx>Just kidding. You actually have to shave a yak at full moon. <elevenkb>lechner: you install vim on a new laptop and burn it in a (necessarily) *scorching* bonfire. <nckx>elevenkb: First, I'm going to try to reproduce that weird error. Adding printers to CUPS on Guix System is still 100% stateful; there's no system.scm record for printers. <lechner>winblows may involve a throwing contest <elevenkb>St. Ignucius says that using vim is merely a penance not a sin. <lechner>lilyp / i do not know, but that kind of thing was common in the community i came from <nckx>elevenkb: Any particular reason you added hplip? <elevenkb>no particular reason, other than obedience towards my manufacturers' instructions. <nckx>ACTION reconfigures with exciting new buggy CUPS. <lechner>elevenkb / hplip worked for me once in fifteen years but i can't remember when <nckx>lechner: Is that list still updated & relevant for remotely modern IPP printers? (I don't know.) <lechner>i actually was looking for linux-printing.org but can't find it anymore <mirai>Any particular guidelines for changes that break a particular service definition interface? <nckx>mirai: #1 is provide transparent compatibility if at all possible. If not possible, try harder. If really not possible, discuss. <mirai>I'm planning on improving an existing service definition which will break the current one (adding reflexive capabilities and switching to define-configuration) <unmatched-paren>switching to define-configuration will not break anything if the define-record-type* uses the full name of the record as the getter prefix <elevenkb>ok, a `sudo guix system reconfigure` followed by a `sudo herd restart cups` allows me to access `localhost:631/printers`. <lechner>elevenkb / your printer also has an embedded web server, which should make hplip unnecessary <nckx>elevenkb: OK. Now you can add it as an IPP Everywhere printer. <nckx>(Make is âGenericâ IIRC.) <nckx>There should be no need for the old hplip software, but test separately. <lechner>ACTION still has to get a "newer" IPP device <nckx>ACTION 's printer will be 20 next year and still needs hplip. Do not be like nckx, unless you like old stuff and for some reason can still buy ink. <elevenkb>ok my printer is discovered but when I try to add it, i'm prompted with a username/password dialog box. <nckx>elevenkb: Just enter your username & password, I don't know what more to say :) <lechner>nckx / tomorrow is cyber monday. the cheapest networked HP laster printer on Amazon i see on is $109 <nckx>Adding printers is a privileged operation. Otherwise anyone can print to anything, and there would be madness. <elevenkb>Ok, I've successfully added the printer. Thanks lechner, nckx. <nckx>But does it print?? Don't leave us hanging like this, jeeze. <lechner>nckx / your advice regarding username and password was indispensable <lechner>that web interface is a declarative loophole <nckx>lechner: IME, people selecting âManufacturer: HPâ âModel: <some model-specific driver like it's 1998>â is more of a problem, that's why I mentioned that. CUPS really should add a big âunless you know better, just click here to set up IPPE which is 99% likely correctâ autobutton. But the Web UI is abandoned, so that won't happen. <nckx>lechner: Does /admin still have the right-hand column for you? <nckx>I can't remember if I pushed that upstream or not. <nckx>That was another imperative loophole, except it didn't work at all. <nckx>Just a quick Oracle plug because I â„ Oracle. Anyway, none of those options, of course, had any effect. <yasht>Do elogind "Hook directories" work in guix? <nckx>They should, but not yet. <lechner>nckx / I only see "printers", "classes", and "jobs". there is no "server" section and no "RSS" <nckx>yasht: Someone was asking about them yesterday. I tried a few months ago. Seems like nothing has improved in the meantime. <nckx>I was messing around with a fix but lost my Guix git repository, then my mojo for a while, and haven't got back to it. <oriansj>nckx: I thought Obscene language like that wasn't tolerated on this channel ;-p <yasht>Any other way to run commands before shutdown or sleep in guix? <nckx>yasht: By adding them to a script and running that, for now. <lechner>nckx / you are the hardest worker i know <yasht>nckx: I need to manually run the script before I try to shutdown? <nckx>yasht: What command do you run to shut down? <lechner>yasht / how about a Shepherd service that does nothing when starting but executes your script when it is stopped (by the shutdown process). not sure about sleeping <nckx>It won't work for suspend, yeah. <nckx>There are no power states in Shepherd. <unmatched-paren>is there a way to reboot without root if i don't have elogind (thus no ``loginctl shutdown'')? <yasht>lechner: Yeah, that makes sense. I'll try it out <nckx>oriansj: Be grateful that it's been a while since I promoted Amazon Linux here. <nckx>yasht: Which command(s)? <unmatched-paren>i tried adding (file-append shepherd "/sbin/halt") to setuid-programs, but alas :) <yasht>nckx: I wanted to unload some kernel modules before shutdown. I shutdown using the gnome power menu <oriansj>nckx: talk about playing the Harlot for overpriced Linux VMs <lechner>yasht / why before shutdown. isn't the sleep case more important (for wifi, i presume)? <nckx>oriansj: See, that's why I promote Oracle's now. <unmatched-paren>actually, i'm probably more likely to get an answer in #kennylevinsen... <oriansj>nckx: I'm not so sure that is any better but then again Oracle is the ultimate whore for money <lechner>unmatched-paren / i saw that in your config. why does it not work? <yasht>lechner: My wifi driver causes my system to be unable to shutdown. So I usually just do a modprobe -r before shutting down. I wanted to automate that <nckx>oriansj: Interesting new slogan. Bold marketing move. <oriansj>nckx: hey sharks are useful just don't try to pet them when they are hungry <lechner>yasht / which module and equipment, please? <yasht>lechner: It's nonfree, I don't think I can talk about it here <unmatched-paren>oh, looks like i can use sudoers to allow /sbin/halt to be run without a password <nckx>oriansj: Do not compare Oracle to the noble shark, who will outlast us all (and rightfully so). But no more off-topic nonsense from me know. Support is happening. <nckx>ACTION goes to take another look at elogind hooks, because the problem isn't what I thought it was. <lechner>yasht / we can switch to #nonguix if you like, but i may not be able to help much further <yasht>lechner: I'll try creating the shepherd service. <nckx>mirai: You could add an (undocumented) âconfig-fileâ field to radicale-configuration and warn when it's set? I would like to take this opportunity to get rid of pointl. abbrev. s/config/configuration/. <unmatched-paren>nckx: i thnk abbrs r smtms gud if t thng is usd oftn, fr exmpl imo 'string-append' is wy too lng <nckx>Consistency good. Inconsistency for no reason bad. <lechner>Hi, could someone please take a look at this new Shepherd service for cachefilesd? Is this going in the right direction? Also, I am getting a rather obscure error on reconfigure http://paste.debian.net/1262043 <unmatched-paren>can shepherd be configured to allow halt without root, then...? someone on #kennylevinsen suggested that some init systems support taht <nckx>rekado, apteryx: Is node 129 down? <raghavgururajan>unmatched-paren: Regarding aerc, the link to 'GPL vs Expat' discussion isn't working. Could you paste the correct one here? <nckx>unmatched-paren: In theory, probably, by controlling access to /var/run/shepherd/socket & using herd --socket=, but in practice I would not trust it to be reliable/secure. <csepp>hab25[m]: Guix code is practically pure, it even uses monads. <rekado>hab25[m]: if only purely functional languages were usable to build a functional package manager then even Haskell would be out. <rekado>and Nix would be out right away with its mix of Nix, Bash, and others. <rekado>(bash is not, in fact, a purely functional language) <unmatched-paren>hab25[m]: it implements purely functional package management using a non-functional language <hab25[m]>rekado: Right. But I think the producing of Nix derivations is a pure process, no? (bash comes when executing the derivations) <unmatched-paren>Nix's pureness is not guaranteed by the language iiuc, it's guaranteed by the way it's built <hab25[m]>csepp: If I write code locally, will any tooling prevent me from writing non-practically-pure code? <rekado>itâs a misunderstanding to equate âfunctionalâ package management with the language used to implement it. <rekado>hab25[m]: Guile would let you generate a package definition that contains a random URL and thus results in a new derivation every time. <rekado>but this is outside the scope of functional package management <csepp>hab25[m]: Scheme's naming convention and docs usually call attention to mutation. You would have to go out of your way to do mutation. <csepp>usually mutation is indicated with an exclamation mark, like so: (set! foo (+ foo 1)) <unmatched-paren>rekado: and that isn't really even a deterministic build, right? since it's a new derivation each time <unmatched-paren>what *can* disrupt functional package management is timestamps and sometimes randomness in the build process <hab25[m]>rekado: AFAIU nix does not let me do that unless I turn the sandbox off (or else I can't access the network in the build). And inside the nix code, there are sha256 that "lock" output of network code <rekado>^^ I think you mean ânot even a *non*-deterministic buildâ <rekado>hab25[m]: in Guix we cannot access the network during build. <rekado>but we can generate derivations as we please <hab25[m]>So, even if is a non-functional, does it possess a mechanism that guarantees that the resulting machine instructions are deterministic, even if e.g. multithreading? I don't see how one could gaurantee their derivations are reproducible otherwise <hab25[m]> * So, even if it is non-purely-functional, does it possess a mechanism that guarantees that the resulting machine instructions are deterministic, even if e.g. multithreading? I don't see how one could gaurantee their derivations are reproducible otherwise <nckx>No. Nix doesn't provide that either, though. <nckx>You don't need instruction-level determinism to hash things. <hab25[m]>nckx: I thought it did. Any thing specific I should research to find more about this? <nckx>Is there a specific scenario you're worried about? That might be easier to answer. <hab25[m]>nckx: Right, but the resulting hashes are usually not stored in the Nix code, and yet it seems always evaluates to those same hashes. So some guarantee must exist, no? <nckx>Well, there are Ludo's papers to which I always lose the link, but I'm not sure they address this as explicitly. <nckx>hab25[m]: The same is true of Guix. <hab25[m]>nckx: I'm just generally worried about my builds not being reproducible if I switch to a non-purely functional language <nckx>Nix builds aren't reproducible either. <nckx>Builds can embed timestamps, or multi-core builds can turn out different each time. Etc. <unmatched-paren>Both Guix and Nix aim to be 100% reproducible in theory, but aren't in practice <nckx>A purely functional language doesn't buy you more reproducibility. <nckx>No no it's on their home page (or was) so it must be true. <jgart[m]>I concur with both statements minus the nix lang not being purely functional <unmatched-paren>When we find a case where a build is not reproducible, though, it's a bug. <jgart[m]>> A purely functional language doesn't buy you more reproducibility. <jgart[m]>> Both Guix and Nix aim to be 100% reproducible in theory, but aren't in practice <hab25[m]>hab25[m]: But ok, the manual might be wrong <nckx>hab25[m]: You would indeed need an instruction-level deterministic VM to get even close to that, but neither Guix nor Nix provide anything like that. It would be uselessly slow. Not VM-without-KVM slow, just useless. <hab25[m]>I think I saw an edolstra talk where he said this is not exactly true <jgart[m]>nix is purely functional but probably not bash ;() <unmatched-paren>nix isn't purely functional precisely *because* it runs bash scripts <yasht>Spack is similar to Guix and Nix, right? It's written in python <nckx>This is a matter of definitions. <jgart[m]>But if you use nix the language itself without bash then it is probably purely functional <rekado>yasht: Spack does not implement functional package management <nckx>Nix doesn't run bash scripts, it just contains strings. But the only implementation on earth that does anything with Nix runs those strings, yes. <rekado>yasht: it is only similar in that it is also a package manager. <jgart[m]>Same you that you can write purely functional code with scheme if you avoid certain types of function calls <hab25[m]>nckx: But the time inside the sandbox is set to the unix epoch, no? <nckx>I'm not trying to be pedantic but it's a pretty important POV difference. <rekado>yasht: it does not provide binaries nor does it have server-side build verification (or even build attempts). <nckx>But again, nor is it in Nix unless they have made some huge stride. <nckx>hab25[m]: Does Nix do this? The epoch sandbox thing? How? <rekado>yasht: it is comparable to Guix package transformations if Guix allowed you to inject your systemâs compiler toolchain and libraries. <rekado>yasht: so, overall, not similar, really. <hab25[m]><nckx> "Builds can embed timestamps..." <- ok, it's definitely true that for the multicore bash builds I don't know of a nix mechanism that prevents the build querying its own cpu load, or prevent against multithreading race conditions <yasht>rekado: I saw it on the Nix discourse, so I thought it was somehow related. My misunderstaing I guess <hab25[m]>In fact, I am remembering some python-related Nix builds of mine that turn out different each time with pycache. So I have experienced what you all are saying of it not being purely reproducible <csepp>hab25[m]: AFAIK Guix contributors are more picky about reproducibility and bootstrapping than Nix ones. That's why Nix has NPM packages and Guix doesn't, only in unofficial channels. <csepp>It's more a matter of policy than a matter of what language you choose. <hab25[m]>nckx: I don't know, but I have definitely seen this somewhere. Also, the files produced by my builds are always timestamped with the UNIX epoch <nckx>hab25[m]: Sure. But that's not because the build âthoughtâ it was 1970! <nckx>Both Guix and Nix just âtouchâ the files after the build completes. <nckx>Sorry if I ruined the magic :) <nckx>Even if you'd count instructions (which is prohibitive) it would *still* be leaky in innumerable places. <nckx>Well, the counting alone isn't prohibitive, before someone points that out⊠<rekado>Debian shows that itâs not necessary to âpurifyâ the build environment all that much when you can make the build itself numb to differences in the environment. <hab25[m]>So assuming this language difference is not a problem, the only downside I see in guix is a less developed ecosystem, perhaps due to the smaller community. But if this is the only downside, then I can prioritize Guix and only resort to Nix if some package or library is not available. <rekado>some features can lead to confusion. <yasht>hab25[m]: No systemd support, maybe? Depends on how much you like systemd <rekado>itâs much less problematic nowadays, but grafts have confused some people in the past. <unmatched-paren>There are a few minor issues that can confuse people, like the ``guix'' *package* being a thing you Definitely Should Not Install. <unmatched-paren>I'm not sure whether Nix has a ``nix'' package that suffers from the same issue? <yasht>What happens if you install the 'guix' package? <unmatched-paren>I do have a patch waiting in the ML that addresses the issue in a fairly hacky way, though I think it might be blocked on a lack of consensus on what to do if a user attempts to install it? <nckx>No, it's meant to be installed. <hab25[m]>unmatched-paren: No, I manage upgrade my nix with nix itself <nckx>yasht: Time starts to go backwards in a weird way. At least where package versions are concerned. <raghavgururajan>unmatched-paren: I'm not getting the GPL part. Could you please expand on that? <rekado>yasht: you get an older version of Guix. <unmatched-paren>yasht: It's an outdated package meant for things like building Guix extensions and running ``guix shell guix'' <hab25[m]>yasht: I like it, but I'm fine resorting to guix for that <rekado>yasht: Guix includes the collection of packages; since a released version of Guix cannot see the future it cannot include a current version of itself. <rekado>yasht: we use âguix pullâ instead <nckx>unmatched-paren: Did the patch to disincentivise âguix install guixâ ever make it out of the shed alive? I admit to leaving, but I did intend to check back in after it quieted down. <unmatched-paren>raghavgururajan: Notmuch is GPL, aerc links to notmuch (if it's enabled in the build flags, which it is in that package) ⎠aerc as I packaged it is GPL. <elevenkb>I wonder is there any way to get `geiser-guile` to make a cached index of the guix source code. <yasht>So "guix pull" pulls the repo and upgrades the guix as well? <elevenkb>Maybe I should just eval-sexp on the module I'm interested in working on, and then leave it running over night. <rekado>elevenkb: what do you mean? Does the Guile REPL interpret the Guix sources? <unmatched-paren>raghavgururajan: Whereas the officially given license is Expat, so if you don't link Notmuch, it stays as such. <raghavgururajan>unmatched-paren: I see. So without linking to notmuch, it'd be expat, correct? <rekado>yasht: pretty much. It runs a trampoline to install a new version of itself. <hab25[m]>So, all of the downsides you have mentioned can be categorized as "confusing" or "small ecosystem". That's promising, I don't mind "confusing" because it can generally be easily overcome through learning. <elevenkb>rekado: it seems to do something along those lines, like when I jump to a module with a lot of imports and evaluate the `define-module` form I get a _lot_ of CPU activity. <elevenkb>so it has to be trying to evaluate all recursive dependencies and build a cache or something. <rekado>elevenkb: maybe the load-compiled-path is not set correctly <unmatched-paren>By the way, does anyone know *approximately* how we could address that confusing "corrupt somethingorother from port" error you get when the network fails? <rekado>hab25[m]: re âsmall ecosystemâ: there is a vibrant community maintaining third-party channels to extend Guix <unmatched-paren>hab25[m]: Smaller than Nix, perhaps, but not "small" by any means at this point :) <elevenkb>yah, let me compare `%load-compiled-path` in the geiser repl and in a `guix repl` . <rekado>hab25[m]: one thing that I really like about Guix is that people generally try to integrate their work into Guix upstream. <unmatched-paren>hab25[m]: There's also the "no nonfree software" rule which depending on your worldview is either a boon or a bane, but there's always the (censored to avoid angering the GNU gods) channel for heretic software :) <rekado>ACTION wonders who the GNU gods are <rekado>hab25[m]: we donât ship proprietary software with Guix, but the channels mechanism makes it almost trivial to extend Guix with whatever packages, no matter the license. <hab25[m]>unmatched-paren: Yeah I've seen that one, unfortunately looked really inactive compared to nix standards, but we've already acknowledged this here <moshy>Hi Guix! Has anyone else had trouble with reboot/shutdown on kernel 6.0? It seems to hang indefinitely, while kernel 5.15 doesn't have this issue. <hab25[m]>rekado: This is very cool. I use emacs and so I have reaping rewards from this type of culture <elevenkb>rekado: the basic issue afaict is that if you make a checkout of the guix sources independently of the one managed by guix itself, then geiser has no way of telling that it doesn't have to recompile the caches methinks. <rekado>a channel with automatically generated Emacs packages. <unmatched-paren>there's an officially supported emacs-guix plugin, we package *tons* of emacs packages, and it's not too hard to write a ``guix home'' service for the emacs daemon <hab25[m]>Thanks for everyone for the input, very helpful! <rekado>elevenkb: itâs been a while since I used geiser with the Guix sources, but I think you can override the load paths. <zamfofex>hab25[m]: Iâm of the opinion that Guix is adorable, and so are the people working on it. uwu <rekado>I like how â(censored)â above doesnât have any censoring effect. <rekado>a channel by any other name would smell as sweet <hab25[m]>@unmatched-paren Thank you. I will definitely refer to this conversation when I start porting some of my stuff to guix-home. I use Doom Emacs, so Emacs will be one of them if I find a replacement for https://github.com/nix-community/nix-doom-emacs, from what I could tell no such guix equivalent exists <unmatched-paren>hab25[m]: hmm, no, i don't think there's a way to use doom with guix <yasht>unmatched-paren: Wouldn't doom work if the doom binary is run under the FHS container? <hab25[m]>unmatched-paren: Yeah, I may consider that in the future. Getting something close to what I want out of doom would be too time consuming right now <hab25[m]>unmatched-paren: It offers a lot more than that <lechner>moshy / Hi, I too have had issues with reboot and shutdown recently, but due to the complexity of my setup I am not sure they are clearly related to the 6.0 kernel series <yasht>I got Doom Emacs to work using the FHS container <hab25[m]><yasht> "I got Doom Emacs to work using..." <- Cool! Can you share, by chance? <moshy>lechner: It's a fresh setup here. And several kernel versions are affected, but haven't properly picked out the version where the regression started <yasht>hab25[m]: guix shell -C -F -N coreutils bash emacs-next-pgtk git ripgrep nss-certs sed <moshy>And forcing a poweroff is not something I'd do often <yasht>Just run the doom binary using the command, you can run emacs natively. <hab25[m]><yasht> "Just run the doom binary using..." <- Does this imply directly `git clone`ing doom or through guix? <unmatched-paren>it should technically be possible to add a doom package though, i think? probably not a thing you could just randomly decide to package though <podiki[m]>why is the container needed, does doom emacs try to download/run binaries? I always assumed it was something you could just put on top of any ol emacs <unmatched-paren>it'll likely require a bit of effort to get it to work in a guixy way <lechner>moshy / that's also my problem. guix is so ultra-stable, sometimes i do not reboot for four weeks or so <hab25[m]>* and its own installation/management system, <unmatched-paren>the installation system in particular won't really mesh well with guix <unmatched-paren>jgart[m]: that's not really a doom package, though, is it? looks like just a package that doom happens to use, no? <jgart[m]>It might be possible to find a way to package doom stuff but might require some hacky solutions <unmatched-paren>still, it's not really "special" in any way, as it's in its own repo <jgart[m]>I've packaged random elisp files from someone's dotfiles as a standalone guix package, for example ;() <cronoStar>Ok I know that this question has been asked many times before, and I have looked through the bug tracker for answers, I have receieved none. But I am trying too delete gdm-service-type with (modify-services %desktop-services (delete gdm-service-type)) and delete caches. For about a 2 years now I still get gdm as the desktop manager. Does anyone have different expreince's, do you think I should set the getty-serv <unmatched-paren>cronoStar: I think there's some silly stateful stuff going on with gdm; people have reported this before. maybe try removing /var/gdm? <cronoStar>unmatched-paren: I have it still shows up even after the removal. Mabye I should make a one-shot service to remove it on boot? <unmatched-paren>jgart[m]: to improve that snippet, you can use gexp rather than quote, the begin wrapper is unnecessary, maybe change equal? to string=?, use (getcwd) instead of ".", and replace the first "file" in the lambda with ``(basename file)'' <unmatched-paren>cronoStar: hmm... maybe do ``guix shell fd -- fd gdm /'' to see what other gdm-related directories there are <jgart[m]>do you have a snippet example I can read that is similar? <cronoStar>unmatched-paren: ok ill try that, do you know how to change tty's in a vm? <jgart[m]>What's the first think you think when you see this error? _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. <unmatched-paren>jgart[m]: are you trying to run an X server without root or a login daemon? <jgart[m]>that's the package definition I'm working with <jgart[m]>What's weird is that when I try to disable the tests in tilix the meson-build-system still runs the tests <unmatched-paren>jgart[m]: please try to use xvfb before resorting to disabling the tests, by the way <jgart[m]>because I tried that already and it also didn't work ;() <jgart[m]>maybe there is something idiosyncratic about this tilix repo that the meson-build-system does not account for regarding running tests... <nckx>Which phase do the tests run in? 'build? <unmatched-paren>Maybe the tilix meson.build runs the tests when you do ``meson compile -C build'' for some reason. <nckx>No, because then #:tests? #f would disable them. <nckx>Don't say 'unpack just to toy with my emotions. <jgart[m]>They run after the prepare-x phase which comes after the build phase <jgart[m]>that's the standard output of me building tilix <jgart[m]>* starting after the build phase succeeds <nckx>And this is not a custom 'check phase? <nckx>ACTION notices ur sr.ht link. <jgart[m]>I haven't added any custom phases except for a custom phase to delete 'check because #tests? keyword was failing to disable the tests <jgart[m]>but deleting the check phase with the modify-phases macro also doesn't work to not run the tests <jgart[m]>so that makes me think that the tests are being run in a phase that is not the check phase <nckx>jgart[m]: So did I, but your output says âstarting phase `check'â, proving me wrong. <nckx>Ugh, the paste is missing module imports. <jgart[m]>Yup, so the tests are being run in the check phase <unmatched-paren>uh, i don't see prepare-x in guix/build/meson-build-system.scm or guix/build/glib-or-gtk-build-system.scm <jgart[m]>courtesy of etc/committer.scm, git format-patch, and paste.sr.ht <jgart[m]>unmatched-paren: sounds like voodoo then <unmatched-paren>jgart[m]: etc/committers.scm Is Not For Adding Packages, remember? :) <unmatched-paren>jgart[m]: sorry, i missed adding xvfb-run to the native-inputs there <jgart[m]>it actually currently works for packages sometimes <jgart[m]>and those sometimes is faster than me typing a commit message with my editor <unmatched-paren>actually, i accidentally added xvfb-run to inputs instead of native-inputs <nckx>Y'all discussing Xvfb and I don't even get the same tilix source hash. <nckx>Can you disable this voodoo thing please. <jgart[m]>and it looks like they have the tests enabled <unmatched-paren>jgart[m]: Hmm, yeah, I get 1ij3ix6yhi8hicxvglrxjyyv8bch9birrgsr8ml6jfh3hvk4pxdh as the hash. <jgart[m]>nckx: Do you get 1ij3ix6yhi8hicxvglrxjyyv8bch9birrgsr8ml6jfh3hvk4pxdh? <unmatched-paren>jgart[m]: Did you, perhaps, copy the hash from eternalterminal and forget to change it? ;) <jgart[m]>That's definitely possible but the source is a different url <jgart[m]>And I see ldc2 compiling a ton of object files <nckx>jgart[m]: Yes, that's what I changed it to. <nckx>I'm currently building gtkd. <nckx>I wasn't following. So you were building a completely different repo than tilix? <unmatched-paren>nckx: the hash they were using was the same as the eternalterminal hash <jgart[m]>So How can I get tilix to actually build tilix? <jgart[m]>I changed the beginning of the sha256 hash to 1 to get it to trigger a sha failure and no luck <jgart[m]>This is the first thing that ldc2 tries to build: <jgart[m]>ldc2 -O -Igenerated/gtkd -c generated/gtkd/atk/ActionIF.d -ofgenerated/gtkd/atk/ActionIF.o <jgart[m]>but ya the failed derivation it tried to build was confusingly gtkd: /tmp/guix-build-gtkd-3.9.0.drv-6 <nckx>XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. <nckx>gtkd is an input to tilix. <nckx>You cannot skip building an input you don't have. <lechner>lilyp / Hi, judgmental threads like that are not for me, but "innovative and evolving" may be an alternative, if one is needed. opinionated discussions like that are similar to presidential debates in that one ends up giving more air time to the opponent <nckx>jgart[m]: I think you misunderstand. âgtkd in guix upstreamâ is the *thing that's broken*! <jgart[m]>I'm going to get a tattoo that says "prepare-x is a gtkd phase" <unmatched-paren>sneek: later ask nckx: could you please merge my gtkd fix patch when it arrives? <jgart[m]>sneek: extra botsnack, you good bot you! <lilyp>lechner: Are we reading the same thread? <lechner>lilyp / i hope so, but sorry. i did not mean to troll you. it <lechner>lilyp / it's just that i agree with you yet do not wish to speak up <lilyp>jgart[m]: re tilix, you should probably not put gtkd as native-input <jgart[m]>lilyp: input? That's actually where I had it before in inputs ;() <unmatched-paren>omlet[m]: on the one hand, it probably will be more secure; on the other hand, rust is a massive pain to package :) <omlet[m]>unmatched-paren: Of the software is freedom <unmatched-paren>Given that they're rewriting it, probably a bad idea, and that Rust has a gazillion developers... <omlet[m]>unmatched-paren: The culture now is create new softwares or rewriting softwares in rust <apteryx>unmatched-paren: no need to remove /var/gdm, it's on a tmpfs nowadays <unmatched-paren>omlet[m]: Dependencies and the fact that a rewrite honestly seems like a ridiculously awful idea, given the potential for tons of new bugs. <omlet[m]>unmatched-paren: But tor not is abandware <unmatched-paren>The idea that Rust is nonfree is spread by a few people who seem to be intent on discrediting anything developed in the 21st centure :P <omlet[m]>Its tor implementation with rust, not replace for at the moment <unmatched-paren>omlet[m]: yeah, but i don't think it's worth using resources to develop a potentially buggier rewrite <omlet[m]>unmatched-paren: I think tje reasnn its the name copyright <unmatched-paren>I don't like Rust, but that's no reason for people to insist it's nonfree. Copyright is allowed under free licenses. <unmatched-paren>Firefox isn't nonfree, but it violates the FSDG for different reasons. <unmatched-paren>omlet[m]: I'm not annoyed with you or anything, sorry if I gave you that impression :) <lechner>ACTION has never seen unmatched-paren annoyed <Kolev>Should I download Standard or Latest? <Kolev>unmatched-paren: lechner: Then why does the website seem to recommend 1.3.0? <lechner>Kolev / I'm not sure it matters that much. You will run 'guix pull' at the earliest opportunity. You just have to make sure to consult the old manual because some of the configuration language changed. <lechner>I used 1.3.0. I did not even realize a later version existed, but I would probably use it <unmatched-paren>Kolev: because it's usually the case that the release is less buggy, but it's so old that it probably isn't <podiki[m]>1.3.0 has some known and fixed problems at this point; a new release is coming "real soon now" (perhaps testing current installer more this coming week) <unmatched-paren>yup, the final issue blocking the release was fixed a couple days ago :) <Kolev>OK, wrote to USB stick. Booting installer. Installing on spare disk. Still using Fedora, but curious to see how much of my setup I can reproduce.