IRC channel logs


back to list of logs

<oriansj>vagrantc: thank you for that correction.
<PuercoPop>Is there a way to use guix in mac os using shepherd to manage daemons? Or does Shepherd needs to run as PID 1? Searching the web I encounter a lot of articles to run GUIX inside a VM, but no mention of using it as a package-manager + dev-shell
<mwette>civodul: thanks!
<freakingpenguin>PuercoPop: I know Guix uses shepherd both for system daemons and for home/user level daemons. I don't think Shepherd /needs/ PID 1 but it might be some work to get a system shepherd started from another init system.
<freakingpenguin>Depending on what you're trying to daemonize you just might need Guix Home's user shepherd, which runs on log in.
<oriansj>PuercoPop: you can run guix as a package manager without shepherd but not guix as an operating system without shepherd.
<freakingpenguin>You can build shepherd's config file without the rest of the operating system, even a script to run shepherd using that config file. (shepherd-boot-gexp). Just need to get macOS to run that script on system startup.
<freakingpenguin>I think it'd be tricky though, so if Guix Home suffices that would be a better option.
<peanuts>"[PATCH v3 5/8] docs: drop texinfo options"
<apteryx>that explains why my handy QEMU info manual has vanished
<freakingpenguin>That feels like a random change to introduce in that particular patch.
<sturm>hey folks, does anyone have fprintd-service-type working for their fingerprint reader? I added it to my system config and it seemed to break the Gnome login - could no longer login by password (or fingerprint).
<hapst3r>On an old machine, what are the optimisation options to make Guix pull and build Operations faster?
<adanska_>Hi Guix!
<adanska>hi efraim :)
<efraim>I'm feeling like nushell was a mistake. I'm trying to update it to 0.91 on rust-team and I'm probably more than 200 patches in, and that's with mixing in patches from the mailing list. And I tried to pull everything into the main package
<efraim>I think when I upgrade it I'm going to upgrade nushell -> 0.91 and then rip out and slot in all the other rust-nu-shell-* packages in the same commit
<jysh>Hello. I am trying to set up a git server on guix os. The setup has a `git` user-account, locked down through git-shell, and which is also supposed to have a few files right from its creation in ~/git-shell-commands/*. What is the best way to copy these files in this specific user-account during `guix system reconfigure`? I found (skeletons) but that probably adds the specified files to all user-accounts.
<rmnull>Hi, is there a way for me to know the progress of "Computing Guix derivation ....". It seems to be running forever for now
<oriansj>rmnull: not that I know of
<old>hapst3r: you can offload builds to a more powerful machines. As for pull, I do not believe you can offload them
<hapst3r>old: thanks!
<theesm>happy hacking folks, what’s currently the status of the php package chain in ?
<peanuts>"[PATCH 00/95] PHP package chain."
<rmnull>how do i disable guix home altogether and go back to my system home default
<rmnull>There seems to be no option to do this
<civodul>rmnull: hi! i think you can “rm ~/.guix-home” and that should be enough
<civodul>(it’s a symlink)
<civodul>well, actually no, you’d also have to adjust ~/.bash_profile and any other files that were managed by Home
<rmnull>umm, so there's no neat command/solution for this built in guix home
<efraim>ok, I think I'm going to just add a patch when I package rust-poem to remove the 43! optional dependencies
<ds-ac1>Hey! I have just opened a bunch of bugs my mistake when trying to send a patch series :/ Is sending emails to <wrongly opened bug> enough to close them ?
<ds-ac1>Or should I send emails containing "close <bug number><" ?
<civodul>ds-ac: hi! yes, just email and it’ll be closed
<ds-ac>Perfect, thx !
<ahenv>is it possible with GNU Guix system to have GrUB installed in both UEFI and non-UEFI modes?
<ahenv>is same possible using native system configuration? It same possible to be done manually?
<ahenv>can I install GrUB with support for both UEFI and non-UEFI mode (so that I can run grub-install manually for both modes (2 times, 1 time for each mode))
<ahenv>in Debian I can install grub-pc and grub-efi-amd64-bin packages which do not conflict. And it works (I run grub-install for the extra mode manually)
<PotentialUser-78>I am not a native speaker, but reading the mailing list about the concerns/questions regarding software heritage leaves me baffled. People ask to change the names of the commits in the past, because they changed gender? Is my understanding right?
<civodul>PotentialUser-78: i have yet to catch up on the mailing list, but yes, people (understandably) want to be referred to by their current name
<PotentialUser-78>civodul: For every commit AFTER  name change this is no deal, but rewriting history makes me feel uncomfortable. I don't even known if it is technically possible without breaking changes
<janneke>PotentialUser-78: i haven't read it in all detail, but aiui (please correct me if i'm wrong!) it seems the complaint is about historical releases being archived verbatim, instead of being retro-changed after their transition
<janneke>if there's any current web page mentioning a deadname, that's wrong; but if a release happened with a pre-transition name, i would think you'd have to live with that
<janneke>but i'd love to get cwebber's input on this and would defer my judgement to her
<PotentialUser-78>janneke: +1 for asking Christine about that. I tend to follow your view on releases
<janneke>i'm hoping this is all a tragic misunderstanding
<freakingpenguin>My understanding from the original post is it deals with SWH hosting archived repos with the old commits. That's unfortunately a hard issue to crack without defeating the point of SWH I think.
<cwebber>Ah I might have to weigh in I guess
<cwebber>Someone from Software Heritage once did ask me to weigh in but I declined, maybe that was a mistake :/
<janneke>cwebber: that would be great
<janneke>ACTION was quite hesitant to provide ammunition to the flame
<IntermedUsar-75>greetings guix
<jackhill>I'm working on a pakcage that uses cmake. So far, with the vanilla cmake-build-system, I'm getting " relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC" as an error. Am I likely missing some arguments? I haven't found the upstream documentation to be that helpful yet
<peanuts>"GitHub - estkme-group/lpac: C-based eUICC LPA"
<jackhill>adding -DCMAKE_C_FLAGS=-fPIC to #:configure-flags helped.
<darkexior>wassup guys, does anyone run wine and run games in here?