<nckx>jackhill: Long story, or so it felt at the time, disappointing answer. When I pushed that patch I thought it had something to do with the tzdata package in Guix, or glibc, or something, because it was broken both in the build environment (even with tzdata-for-tests) and my desktop. Oddly, the PST8DST time zone worked fine, as does my Europe/Brussels. However, I since discovered that my /etc/environment wasn't being sourced, and hence TZDIR wasn't set. I need to <nckx>try adding it to the package (together with tzdata) and see if that fixes it. <jackhill>nckx: ah. I'm in America/New_York, so I guess I'm safe. Can't say I enjoyed the time I spent at the airport in Las Angeles anyways :þ <nckx>Some say it's the best part. <nckx>jackhill: I actually went as far as to ask someone using Guix System in LA about their time zone setting… sigh. <nckx>I still don't pretend to grok why PST8DST works — some kind of minimal database? — but I'm guessing that setting TZDIR will make it moot. <anadon>nckx: Thanks! I messed up the send-mail command last night. I had spend hours trying to get postfix to work with the new gmail requirements. <nckx>How did they choose to better serve their users this week. <anadon>"Less Secure Applications" were disabled, requiring a new security scheme SASL to be required which was hardly and poorly documented. Google's own documentation was worse than useless in that it tried to force you to use a heavy-wight google workspace fronting your entire enterprise infrastructure. Eventually house a serverfault question that <anadon>was new enough to cover the correct configuration. <nckx>Sure: setting up and maintaining your account is more work that self-hosting a mail server, but you do get the prestige of an @gmail.com address. <nckx>Thanks, I am but a lowly self-hoster myself. I might seriously have to adjust my image of @gmail users: from average e-mail user to elite SASL enjoyer. <nckx>‘You set up git-send-email with Gmail? Hired!’ ***duds-_ is now known as duds-
<anadon>Hey, it is just what I've found practical for my setup. It is by no means sacred. Much less '''good'''. <nalaginrut>alright, guile-3.0.8 has a critical bug to run artanis... <zamfofex>civodul: I’m not sure whether you saw the reply I sent regarding <https://issues.guix.gnu.org/54832> This time I made sure to add the debbugs email to the reply list, but my reply still hasn’t showed on in that thread (maybe I did something stupid). <zamfofex>Actually, I added the debbugs email to the “Reply To” field, rather than “Cc”. Could that have been it? <nckx>zamfofex: ‘Reply-To’ means ‘this is my other address, please send replies there’. <nckx>It does not mean ‘I am replying to…’. <zamfofex>Ah, huh. I suppose that explains it, then! <zamfofex>I’m not particularly familiar with email conventions. <nckx>If you want it to appear on the tracker. <nckx>civodul will receive another copy but he'll live. :) <nckx>zamfofex: If your MUA has a ‘reply all’ feature, use that, it will do the right thing. <nckx>I'll hedge my bets. I'm sure there's zany software out there. <zamfofex>I see. Well, I remember clicking that. Though it had this drag and drop thing that I used to rearrange the addresses. I thought “Reply To” meant that I was replying to that thread, so I dragged the debbugs email there. <KarlJoad>What is the Guix way to describe a Nix Overlay? I want my Emacs to <KarlJoad> also understand where gcc-toolchain and linux-libre-headers are for <KarlJoad> itself, without installing to the shell-available profile. <zamfofex>KarlJoad: Do you mean propagated outputs or something else? When you say “my Emacs”, do you mean you are packaging a custom Emacs, or do you just want for Emacs to be able to find GCC and the Linux headers? I don’t understand what’s the problem with just installing the appropriate packages too alongside Emacs. (Sorry if I’m missing the point.) <KarlJoad>zamfofex: I want Emacs to pick up a GCC & linux-libre-headers path, but do not want those packages to be available from my home profile. Only Emacs should directly refer to those 2 packages. <KarlJoad>So I can upgrade Emacs & the GCC/headers used by my home profile separately from each other. <KarlJoad>I can package a custom Emacs, that's fine. I just want Emacs to pick up its own unique set of GCC and headers. <KarlJoad>I want to avoid the issues I had earlier when I was trying to compile emacsql-sqlite. <zamfofex>KarlJoad: Ah, I understand. You could put the packages into their own profile, then use ‘PATH="$PATH:.../my-profile/bin" emacs’, perhaps with a shell alias or function. Conversely, you could use ‘guix shell’ before running Emacs. I think ‘guix shell’ can accept a manifest file, but I’m unsure. <KarlJoad>guix shell can accept a manifest. I am using that feature right now for a project. It's more that I want to make a "new" Emacs that has its own package symbol that carries the necessary information with it to compile emacsql-sqlite on a new Guix system. <zamfofex>I don’t think I fully understand. Are you trying to package ‘emacsql-sqlite’, or do you want to work on it from Emacs? because if the former, I think you could just specify both Emacs and GCC as build inputs, no? If the latter, I don’t understand what’s wrong with using ‘guix shell emacs gcc-toolchain ...’, for example. Or do you mean you are trying to build a system image with an Emacs package that propagates GCC? <zamfofex>(GCC and the Linux headers, I mean. I was running out of space in that message!) <KarlJoad>So, emacsql-sqlite can only be built at runtime with the way I want it to be done. But, I don't want to specify Emacs in my config and have GCC added to the profile's PATH. <KarlJoad>I do not need to package emacsql-sqlite. I want that to remain a job for my Emacs config to handle. I just want to expose the necessary tools to Emacs to build sqlite during runtime without adding GCC & headers to my home profile's PATH. <zamfofex>I think the two choices you have are to either use ‘guix shell’ before starting Emacs or to use a different profile with ‘PATH="$PATH:..." emacs’ like I had suggested. You mentioned Nix had a solution for it, I think — what does it do? <KarlJoad>With Nix overlays, you can redefine & extend already defined packages. For example, I have a Nix overlay to force any instance of emacs in my system configuration to refer to my Emacs which has the withXwidgets configure-time flag set to true. <zamfofex>KarlJoad: Though note that this won’t “put GCC on the PATH” or anything like that. Rather, it would make the Emacs package refer to GCC from the store. So if you e.g, have a shell in Emacs, you will likely not be able to just run ‘gcc’ directly. <KarlJoad>I mean, for Emacs, no substitutes is fine. It's not a hard program to compile on modern hardware. I think an inherit is what I want. <KarlJoad>But that is exactly what I want. I want Emacs itself to be able to refer to its GCC directly, but for anything else to not see that GCC. (Unless it gets shared by a separate profile, obviously.) <zamfofex>Though I meant more so that this will only really have an effect if the Emacs package itself refers to GCC during its build. If Emacs tries to e.g. invoke GCC as ‘gcc’ from the PATH at runtime, this won’t help. <apteryx>neat, it looks like I'll be able to migrate (gnu build jami-service) to use the AC/D-Bus Guile library instead of some ad-hoc dbus-send parser <zamfofex>KarlJoad: I think this is meant to work transparently for shared libraries, but usually if you want for the GCC invocation to to refer to the input rather than to the one in the PATH during runtime, you’d have to apply a patch or use a snippet. <zamfofex>It works well for shared libraries, I think, because there is a phase that replaces dependencies in the ELF files with their paths from the store (from the input list). <KarlJoad>Yeah. And since Emacs does not directly refer to GCC by an ELF file, such a replacement would do nothing. <zamfofex>Indeed. If there is e.g. a plain string literal in the source containing the contents ‘"gcc"’, Guix has no way to know that it is meant to refer to GCC from the input list, even if it is in a call to ‘exec*’ for example. So you’d have to find that reference in the source write a snippet to replace it with the GCC from the input list if you’d like. <zamfofex>“*and* write a snippet to replace it …” I mean <zamfofex>On other news, I’m trying to use ‘guix system image’, and I’ve realized that it doesn’t work well if I specify e.g. ‘--image-size=64G’. It slows down my entire system, and takes way longer than it should. I suspect it’s somehow trying to allocate 64 GiB of RAM, which is very unideal. Is that the expected way to create a system image with that partition size? <nckx>I'd file a bug, zamfofex. That sounds wrong. Your use of ‘guix system image’ isn't. <voroskoi>I use (patches (list "path/to/patch")) to append patches, but it gives a warning on relative path <lilyp>voroskoi: if you're doing local development, you can ignore this patch <lilyp>if it still appears if you `guix pull' your channel (and are not currently working on it), that's a problem <jpoiret>or do you have some alerts configured when someone pings you on irc offline? <jpoiret>in any case, thanks for the review for the open-bidir patches, though your comment on fprintf/dprintf made me look more closely at the manpages and i realized none of these functions should be called after fork anyways <jpoiret>so i've got ... *even more* patches! <jpoiret>i'll just send them all to guile-devel at this point <jpoiret>hopefully, piped-process will be fully MT-safe with those <maximed>jpoiret: if things fail between 'fork' and 'exec', where does the error message go? <jpoiret>which will be able to properly raise the exception, which is better than what we have no <maximed>jpoiret: sounds complicated but nice <maximed>is this pipe closed before/during/after the exec? <jpoiret>it's just a couple of repetititive lines, nothing wild <maximed>such that it doesn't leak into the child process <jpoiret>yeah, it's marked as CLOEXEC so that on successful exec nothing is read <jpoiret>it's not atomic though, so theoretically another thread that forks in between the pipe + fcntl could steal the fd without CLOEXEC and block it, but it's their responsibility to release the fds they don't need imo <jpoiret>we already do that (release the fds) in piped-process, so it won't happen if all we use is that <maximed>jpoiret: Is there some option for _not_ releasing some of the fds? E.g. for a make jobserver ***PrinceMyshkin3 is now known as PrinceMyshkin
<jpoiret>no, though that behavior was already present <maximed>jpoiret: It's possible to create a pipe that directly is O_CLOEXEC <jpoiret>although i've read somewhere that it is slated for inclusion in whatever new posix version should come out <maximed>WDYT of race-free pipe2(...,O_CLOEXEC) on Linux an technically racy pipe(...) elsewhere? <jpoiret>hmmm, right, i had thought of that but didn't end up doing it. Maybe I'm too scared of #ifdefs :p, let me try <maximed>(though technically there are still races if move->fdes is used) <jpoiret>yeah, or if another thread forks but never execs <jpoiret>multi threaded semantics really are terrible <maximed>jpoiret: Maybe look at AC_CHECK_FUNCS in configure.ac <jpoiret>it'd be great if we could avoid primitive-fork in all of guix's codebase <jpoiret>or at least have some good cleanup primitive we could use to _actually_ isolate the child process and not let it hold resources <jpoiret>also, i've heard that fork is quite costly, i don't know if this affects us ***jesopo is now known as jess
***taiju is now known as Guest1099
***taiju` is now known as taiju
<char[m]>Is there a reason that I have to install additional packages (gcc, binutils, glibc, others?) For ghc to work properly? Why aren't they just in the inputs? <jpoiret>char[m]: how are you using it? installed in your profile? <rekado>(install gcc-toolchain instead of all the individual packages; but the question remains) <jpoiret>it'd seem weird to me that it doesn't work directly <unmatched-paren>there should probably be a ghc-toolchain package that propagates them all <unmatched-paren>the *-toolchain packages install their respective compilers along with binutils et al. <jpoiret>let's see if i can write an hello world in haskell from memory <jpoiret>btw, the -toolchain packages are mostly to choose the glibc for the compilers iirc <char[m]>Installing the libs i mentioned makes ghc work, but the resulting binary still cant find libgmp.so or libffi.so even though i installed those too. <char[m]>No, the binary of my haskell program that ghc made gcc make <unmatched-paren>try `guix shell libffi gmp -- [your compilation command here]` maybe? <char[m]>unmatched-paren: what is the reason for having -toolchain packages? Why not just propogate the needed inputs in the compiler package? They won't function properly without those inputs anyway <jpoiret>char[m]: the non -toolchain packages are hidden, ie not installable from commandline <jpoiret>(and gcc redirects to gcc-toolchain even) <jpoiret> ;; The main raison d'être of this "meta-package" is (1) to conveniently <jpoiret> ;; install everything that we need, and (2) to make sure ld-wrapper comes <jpoiret> ;; before Binutils' ld in the user's profile. <jpoiret>otherwise, you know, gcc and ld are different programs <jpoiret>gcc-toolchain is basically gcc + ld + binutils + glibc <unmatched-paren>ghc-toolchain should be ghc + gcc + ld + binutils + glibc + libffi + gmp <jpoiret>char[m]: an hello world compiled an ran fine with `guix shell ghc gcc-toolchain gmp libffi` <char[m]>That should be it. Im not sure if ghc needs other .so depending on features or libraries used in the haskell code. <char[m]>also just installing libffi and gmp didn't work because they still couldnt be found by the compiled haskell program <unmatched-paren>because it's possible the reason ghc wasn't finding them was because the C library search path hadn't been reloaded...? <jpoiret>you need gcc-toolchain installed for libs to get picked up <jpoiret>since LIBRARY_PATH is a search path of gcc iirc <unmatched-paren>char[m]: if you install gcc-toolchain and do `bash --login` it should work <jpoiret>don't globally install non-user programs ... is my opinion anyway <unmatched-paren>so (specifications->manifest (list "gcc-toolchain@12" "ghc@whatever" "gmp@whatever" ...)) <char[m]>Okay, doing a guix shell like char: `guix shell --pure ghc gcc-toolchain gmp libffi` worked. Im not sure why it didnt work before because i was sourcing ~/.guix-profile/etx/profile every time i installed something <char[m]>Once I have ghc-toolchain, it should just be guix shell ghc-toolchain right? And you said it should propogate the packages?unmatched-paren. Do I need to make one for every veraion of ghc? <unmatched-paren>char[m]: (1) yes (2) yes (3) yes, but you should be able to write a `(make-ghc-toolchain GHC-PACKAGE)` procedure quite easily, I'd think...? <unmatched-paren>you should be able to find a make-gcc-toolchain in gnu/packages/gcc.scm i think <unmatched-paren>yeah, the (make-gcc-toolchain gcc #:optional (libc #f)) procedure is pretty trivial (turns out it's actually in gnu/packages/commencement.scm apparently) <yewscion>seem to do anything on Guix. The basic fix is modifying values that live in `/sys/devices/virtual/powercap/` and want to confirm whether Guix might not honor these values (and work out a real solution, so I can use my laptop on battery). <jpoiret>anything in /sys should be honored since you're directly talking to the kernel <yewscion>jpoiret: Ah, alright. Thanks for the confirmation. Maybe I'm doing something wrong, then. <jpoiret>you should be able to see if the changes you make are taken into account by cat`ing the relevant file ***taiju_ is now known as taiju
<oriansj>yewscion: the link you shared indicates there is a max wattage one can draw from the battery before brownout voltage occurs. So what the change is doing is lowering the max wattage draw for the CPU <yewscion>oriansj: I see, that makes sense. Hopefully it will work this time, I have reapplied the fix as listed and confirmed the changes as jpoiret suggested. <unmatched-paren>is it possible to tune a package _object_ without the command line? I want to tune some packages in my home.scm <lilyp>all transformations plus some more can be coded in scheme <lilyp>see (guix transformations) for the innards <unmatched-paren>hmm, (transform-package-tuning)'s docstring is just "Return a procedure that, when " i suppose that's a mistake <unmatched-paren>Yet another reason to dislike dynamic typing -- it makes it difficult to see what a function will actually accept :( <unmatched-paren>ok, going to see if supertuxkart will benefit from cpu tuning at all... <nckx>Good morning, Guix! (It's been a while since I said that...) <nckx>Perfect response by acrow. <nckx>unmatched-paren: I guess you don't read PMs? That is probably for the best. <nckx>I shall make note of it. <jpoiret>reminder that arun isaac's guix-forge presentation is in less than 10 minutes <unmatched-paren>it's probably the placebo effect, but supertuxkart does seem a bit faster now <nckx>jpoiret: That's why I'm here! <jpoiret>for once i wrote it down in my calendar with a notification <nckx>I can't unmute my mic without hearing the sound of a thousand cats dying, but am looking forward to the presentation. <jpoiret>PurpleSym: alright, went back to the grub patches <jpoiret>unfortunately, they're not really backportable to 2.06, at least for me <jpoiret>so i guess we'll have to wait for the next version <PurpleSym>jpoiret: Bummer. Did you check if we can force the inclusion of all modules required? I can also see if I can come up with something on Monday. <PurpleSym>Could you also point me to the patches by any chance? <nckx>It's a miracly my connection fared as well as it did, but my luck finally ran out. No WebRTC for me. Could you convey my regards to Arun, jgart[m]? Looking forward to the next presentation I can attend. <nckx>whereiseveryone: Or you :) <nckx>Corporate sockpuppet accounts, oh dear. <vivien>TIL that you can write a implies b in scheme as (if a b) <vivien>(if (if a b) "Implication OK!" "Implication not OK :(") <vivien>But (if (if a b) ...) does not seem very readable <f1refly>what is the best way to tell my laptop to disable bluetooth with rfkill on boot? <kiranshila>Hey everyone! Is anyone familiar with SHM_LOCK stuff? I'm working on packaging a radio astronomy data management suite (http://psrdada.sourceforge.net/) and am getting "Cannot allocate memory". The same build on a foreign distro seems to work fine <vivien>kiranshila, you need to tell us more. You present the issue as if something identified by SHM_LOCK is part of the problem, but it doesn’t appear in the error message. <kiranshila>The full error from the application was `ipcbuf_lock: shmctl (shmid, SHM_LOCK): Cannot allocate memory` <kiranshila>I'm pretty unfamiliar with the whole shared memory architecture - but I wasn't sure if there was something special about guix SD' <unmatched-paren>it's possible that the guix sandbox disables shm, but i know nothing about either <kiranshila>This software lets me allocate "keyed blocks" and when I try to request a 4096 block, it works fine. Anything bigger than that fails. I'm not sure where that limit is coming from. <nckx>kiranshila: Just a guess, but prlimit's --memlock option is apparently relevant here. <nckx>According to setrlimit(2). <kiranshila>Oh yeah, that's certainly different on my arch box <kiranshila>I have the pam limits entry for memlock set to unlimited, at least I think I do <kiranshila>Well, I guess it would say "unlimited" if that were truee <nckx>If it is the culprit (it's not clear from your answer if it is, isn't, or you don't know yet, and I have to leave), there's a pam-limits-service in Guix. See the manual's ‘Base Services’ section. <kiranshila>Yeah that very well might be the culprit. I have that `pam-limits-service` entry in my config, but I may have misconfigured it <kiranshila>Yeah /etc/security/limits.conf is certainly set correctly - it's just not actually applying? This was after a reboot <maximed>if that's the culprit, I think the guix daemon should set the limit for the build processes (if that's possible per-process), to eliminate this build irreproducibility variable <nckx>It feels like plugging infinite holes, though. Not that we shouldn't; it's just Sisyphean. <mohammed>hi, I am planning to move to guix linux, and I want ask you about installing packages there because it is risk if delete my currentOS without know about supported package. <mohammed>I have Intel-Wireless AC 9260 and this is not free. can I install the frimware there? <unmatched-paren>mohammed: there _is_ a way, but you can also just use a wifi dongle or card with the ath9k chipset <mohammed>Thanks unmatched-paren, but I didn't use it before <nckx>Uugh. CUPS update is a 112531 diff and it's 80% pointless treewide style changes. *nckx continues auditing C comments… <nckx>I'm using diffoscope. Does difftastic work in text mode? <singpolyma>It has both side by side and inline display modes also <nckx>I'll try it out. Thanks. <zamfofex>mohammed: If you’re unsure about whether the installation will work and you only have one computer, you can always just have another OS (e.g. Debian) on a different installation medium and use it in case the Guix system installation doesn’t work. <zamfofex>I have Guix with the Hurd on a QEMU VM, and it seems to be failing to build and install packages while building Guile 3.0.7, presumably during bootstrapping. Has anyone experienced something like this?