<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>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.
<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>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.
<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>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
<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
<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
<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.
<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>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.
<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?