IRC channel logs

<tschilp>civodul, rekado, apteryx: thanks for the good work, just pulled to c5bc69 and reconfigured everything very fast and smoothly!

<ascetic>Good night everyone! ^_^

<anemofilia>Guys

<anemofilia>I would like to do a custom build of st

<anemofilia>And, for what I've read, channels are the proper way to do so

<anemofilia>But I don't know well how to do it

<anemofilia>I searched for examples, but the ones I've find are pretty different from each other

<anemofilia>Is there some video, article, wiki, discussion, or exemple that is suffiently recent and you guys recomend?

<Gooberpatrol66>anemofilia: nano ~/.config/guix/channels.scm

<Gooberpatrol66>(cons* (channel (name 'channel-name) (url "file:///file/path/")) %default-channels)

<Gooberpatrol66>git init in /file/path

<anemofilia>But how can I do it in the case where the software I want to install is in a git repo?

<Gooberpatrol66>you have to write packages probably

<Gooberpatrol66>or modify existing ones

<anemofilia>oh, that's nice

<anemofilia>I think then it would be nice to learn about creating packages

<anemofilia>I would like to make one for kandria

<anemofilia>Seems a really nice game

<anemofilia>Don't know if you guys have heard about it before

<anemofilia>It's written in Common Lisp

<davidl>unmatched-paren: Is there any way to use the search-input-file procedure when you are using the trivial build system? I was trying to make everything work with the new style there before switching to the copy build system.

<davidl>For the other build systems, people use (lambda* (#:key inputs #:allow-other-keys) to get the inputs variable which the trivial one doesnt have.

<mirai>davidl: avoid trivial-build-system

<mirai>you're inviting pain

<davidl>mirai: I know by now lol. As mentioned, Im planning to switch over, but want to do it step/by/step

<dcunit3d>should loadkeys work with the basic guix console?

<dcunit3d>`dumpkeys | grep 58` is showing that the keycode should map to `CtrlL_Lock` but still acts like Caps_Lock

<dcunit3d>nvm, i've got it. it is 58, not 59.

<civodul>Hello Guix!

<dcunit3d>I can't seem to get X11 to work. i'll submit something on the help mailing list soon. i think i'd rather just switch to wayland at this point.

<dcunit3d>i need to migrate to guix home anyways. it's about the same amount of work, more or less. that is where I'd rather be, since everything is more composable,

<dcunit3d>good morning civodul

<ryuslash>civodul: Hello! o/

<dcunit3d>i've got it to remap with a loadkeys script, but after i press the capslock for control, it's like the control modkey gets stuck on. it ends up affecting all of the sessions, instead of the active one, so i have to restart my laptop

<sneek>tschilp: Greetings!!

<jpoiret>hi guix

<civodul>hey jpoiret

<efraim>o/

<janneke>"<jpoiret>yes, there is :) I did that also when updating the hurd to avoid a world rebuild, it's very ugly though"

<janneke>jpoiret: do you have those patches online somewhere?

<jpoiret>not yet, I could send my wip now though

<janneke>ACTION patched glibc for hurd only, but didn't manage to get them picked-up during the cross-glibc build

<janneke>jpoiret: that would be nice

<ulfvonbelow>hey question, what should happen in (gnu build file-systems) in 'mount-file-system' if 'mount-may-fail?' is #t but 'check?' is also #t?

<jpoiret>civodul: wdyt of regenerating bootstrap blobs for the Hurd?

<jpoiret>i'm thinking the least invasive approach to fix coreutils booting would be to add the kernel headers to the bootstrap blobs. Also, I want to try whether the m4-boot0 succeeds with newer headers, but I'm not sure it will help or not

<jpoiret>for some reason Guile just loops if I try to use %bootstrap-coreutils&co instead of coreutils-boot0 in gcc-boot0's source

<civodul>jpoiret: why would they need to be regenerated?

<civodul>ideally we'd rarely do that

<efraim>jpoiret: what's the snippet you're trying to remove? The one from commencement.scm?

<efraim>Ah, I see the files that need to go

<ulfvonbelow>background: I've got a raid array, and each drive should contain a copy of the grub-efi bootloader, so booting is always possible. So those all have their own efi system partition, and an attempt should be made to mount each one, but it shouldn't break things if one of them fails. If non-risky repairs and checks can be done at the time, that would be good too. But of course if the device doesn't exist, it shouldn't fail.

<efraim>civodul: what do we have inside the snippet, just guile and explicitly imported modules? No packages?

<ulfvonbelow>currently when I unplug a drive between boots it finishes activation and then hangs forever

<jpoiret>civodul: we're missing the kernel headers for coreutils-boot0, and I wanted to see if newer headers would make the m4-boot0 tests crashing go away

<jpoiret>efraim: well, I'm not trying to remove the snippet, only remove the dependency on coreutils-boot0 which doesn't build

<jpoiret>i was thinking of using %bootstrap-coreutils&co but guix doesn't like that for some reason, gets into an infinite loop

<bumble[m]>no recent mentions here about sound suddenly stopping-working, but in case this helps anyone... my sound suddenly stopped working a week or two ago. I opened pavucontrol tonight and found the audio muted (while playing a video in qutebrowser; video needs to be playing for the muted device to appear in pavucontrol) after un-muting the device bam sound is working everywhere (yay)

<jpoiret>apteryx: I also get etc/teams.scm complaining when I use `mumi send-email` with patches which i guess just uses git send-email under the hood.

<jpoiret>janneke: sending the series right now

<janneke>jpoiret: ah, oh wow

<user_oreloznog_>o/

<efraim>jpoiret: Have you thought about switching to gcc-10? that might also work

<civodul>jpoiret: oh i see; i guess i haven't followed closely enough to provide useful feedback

<civodul>so if the bootstrap seeds have to be updated, so be it; if we can avoid it, even better

<civodul>:-)

<efraim>jpoiret, civodul: I got it to build I think

<efraim>swap out (system* #$(file-append coreutils-boot0 "/bin/rm") "-rf" with (system* "rm" "-rf"

<civodul>efraim: what did you get to build?

<civodul>i feel i've been missing out :-)

<efraim>sources for gcc-boot0, without the coreutils-boot0 in the snippet

<jpoiret>efraim: but where is that "rm" from?

<jpoiret>ah, bootstrap-origin pulls in tar, xz, bzip2, gzip and patch from bootstrap-coreutils&co, so the whole package is available in the snippets I guess

<efraim>no clue, I'll look through to see what gets added to the environment of source snippets

<jpoiret>quite hacky, I would prefer to understand why manually using (file-append %bootstrap-coreutils&co "/bin/rm") doesn't work

<efraim>maybe it evaluates to the wrong platform?

<dcunit3d>anyone working on the hyprland window manager yet?

<dcunit3d>i don't see the package anywhere in the basic channels. i'm looking at its flake.nix and it doesn't look too bad.

<cbaines>jpoiret, if Guile is getting stuck/just looping, maybe try with these changes https://git.cbaines.net/guix/commit/?h=add-package-input-loop-detection&id=100aed7c924bb107ff3c836334bcdf1b1f9c746a

<cbaines>that might detect a loop in the package graph if there is one

<civodul>cbaines: looks like bordeaux.guix used to advertise zstd and no longer does, right?

<cbaines>civodul, it still does, I just lowered the cache size to free up some space

<cbaines>I've noticed the errors when substituting too

<civodul>cbaines: not great because it doesn't honor its TTL

<civodul>which in practice applies to the narinfo and all its nar URLs

<civodul>(admittedly shouldn't apply to all of them, but that's how it is)

<ngz>Hi Guix!

<civodul>o/

<cbaines>civodul, yeah, maybe I should make cache eviction somehow dependent on the ttl

<civodul>cbaines: i think it's a prerequisite; we should have better fallback code but for now every client will go wrong when these things happen

<civodul>do you think there's a way to restore the cache in its previous state, somehow?

<trankitron>Hi there! I'm trying to install Guix system for first time but I'm having problems with encrypted root partition. Where should I read about this kind of problems?

<civodul>because even if we have a fix today, it'll take weeks or months to be deployed

<jpoiret>trankitron: you could look them up on issues.guix.gnu.org or ask them here

<civodul>other options is to advertise shorter TTLs that are guaranteed to be honored

<cbaines>civodul, I'll increase the limit which will at least allow some of these files to come back

<cbaines>once we pass 80% disk usage on bayfront, that'll cause the GC to start blocking things again though

<trankitron>civodul thank you. I'll first check issues website.

<civodul>cbaines: ok, thanks!

<jpoiret>cbaines: any reason all issues on https://qa.guix.gnu.org/patches are unknown?

<cbaines>jpoiret, the likely reason is that the qa-frontpage has stopped refreshing the data from data.qa.guix.gnu.org

<cbaines>I'll restart the service on bayfront

<jpoiret>thanks!

<florhizome[m]>Hey guix,

<florhizome[m]>One of kimaps tests fails which should break a lot of kde packages

<janneke>jpoiret: you even got the correct new time patches for glibc-2.37, beautiful!

<janneke>and and updated hurd and gnumach \o/

<dcunit3d>if an invocation of `guix build` is failing when using the meson build system, how do i get to the see what was building? particularly, the meson-log.txt?

<dcunit3d>i can see the build log at *.drv.bz2 and the last derivation. i'm trying --keep-failed

<dcunit3d>ok, nvm i forgot the --keep-failed on the last run. i think most of what i need is in the /tmp folder

<trankitron>FYI I've already solved the problem with encrypted root partition. The problem was the password I was introducing was wrong because the first time the password is required the keyboard layout still is not changed to the configured value (to ES in my case).

<jpoiret>ah yes, that's a common pitfall unfortunately

<jpoiret>janneke: yes, i still had most of the work done in a git stash from when I was trying to make hurd boot

<jpoiret>so it didn't actually need much more :)

<civodul>jpoiret: BTW, i'm happy i have a running childhurd again, thank you :-)

<dcunit3d>i'm trying to build xdg-desktop-portal-hyprland and getting a failure when it tries to use ninja:

<dcunit3d>%exception #<&invoke-error program: "ninja" arguments: ("-j" "32") exit-status: 1 term-signal: #f stop-signal: #f>

<dcunit3d>is it possible that i need to build it with a smaller -j flag?

<dcunit3d>it's a meson-build-system package though

<jpoiret>dcunit3d: you'll need to provide some more logs. But yeah, since ninja is highly parallelized, it can happen that it launches a bunch of linking jobs at the same time and that ends up eating all your RAM

<dcunit3d>jpoiret: here is my build log

<dcunit3d> https://pastebin.com/2qM304u0

<dcunit3d>and the packages are here: https://pastebin.com/HBvMjDKn

<dcunit3d>there are two modules. i just got on to the hyprland discord. if it gets too tough, i may just fallback to sway

<dcunit3d>i think it's actually an undefined reference to drmGetDeviceFromDevId

<chomwitt>the docs refer to a (gnu home services ssh) module. But inserting it in my home-configuration.scm and executing guix home reconfigure i got 'no code for module (gnu home services ssh-agent)'

<chomwitt>s/(gnu home services ssh)/(gnu home services ssh-agent)

<apteryx>jpoiret: mumi just invokes git send-email yes, so the same problems/workaround for etc/teams.scm apply :-)

<janneke>wtf, the updated hurd suddenly has /usr/lib hardcoded

<janneke>i586-pc-gnu-gcc ... -o rumpdisk ... /usr/lib/librump_pic.a /usr/lib/librumpuser_pic.a ...

<janneke>what is it with these FHS minded people?

<janneke>ACTION wrote endless patches removing hardcoded /bin /usr nonsense even in their lilypond GUB cross-build time

<janneke>sigh

<ennoausberlin95>chomwitt: You are right. I checked the guix source tree and there is no (gnu home services ssh-agent). What do you want to configure? BTW: Scheme-Fu is weak in me, so I might be wrong

<ennoausberlin95>chomwitt. You can see the details if you clone the guix source and check /guix/gnu/home/services/ssh.scm. There is a record-type and services defined for the agent configuration, but the defaults are reasonable

<bjc>is bordeaux ok? i keep getting 404 errors from it. lately it's the ‘which-2.21’ nar

<dcunit3d>for shepherd-0.10.0 should we import guile-fibers into the system packages?

<dcunit3d>or is that a bad idea? i think the build for shepherd bundles in everything it needs anyways

<janneke>ACTION again forgot that something like this doesn't work yet:

<janneke>guix shell -D hurd --target=i586-pc-gnu

<janneke>ACTION goes to write an i586-pc-gnu.scm to set that up

<cbaines>bjc, can you share the URL(s)?

<cbaines>there were some zstd nars removed recently that have been causing problems

<janneke>jpoiret: i would like to compile the hurd from source and used to use something like this to setup a cross build environment: https://paste.debian.net/1280878/

<janneke>jpoiret: with your (amazing!) patch set, that doesn't work anymore, i get:

<janneke>[1]17:12:55 janneke@drakenpad:~/src/hurd/hurd [env]

<janneke>$ ~/src/guix/wip-hurd/pre-inst-env guix shell -D -f i586-pc-gnu.scm

<janneke>guix shell: error: package glibc-cross-i586-pc-gnu@2.37 does not support x86_64-linux

<jpoiret>ah, yes.

<janneke>ACTION has commented-out supported systems in glibc/hurd, but that doesn't fix it?

<jpoiret>let me see if there's a better method

<bjc>cbaines: /nar/zstd/1yfwjl3yf5vqf60hq7wl6lap6nlqgljp-libatomic-ops-7.6.12 is one. unfortunately it's one-at-a-time, so i can't deliver more than that rn

<cbaines>bjc, OK, one trick is to request the lzip compression of that substitute 3 times, then the zstd compression will be regenerated, e.g. wget https://bordeaux.guix.gnu.org/nar/lzip/1yfwjl3yf5vqf60hq7wl6lap6nlqgljp-libatomic-ops-7.6.12 -O /dev/null

<jpoiret>janneke: you're going at it the wrong way imho, since the packages in native-inputs are kept

<bjc>cbaines: ok

<janneke>jpoiret: ah, for other cross-builds (such as mingw) that works, of course

<jpoiret>(and they won't be cross-compiled as well!)

<jpoiret>but how could you get the other native-inputs cross-compiled using this setup?

<janneke>i'm trying to setup a cross build environment, so i would only need cross-build toolchain and all inputs cross-built

<jpoiret>ah, native-inputs 🙃 i'm not awake today it seems

<janneke>native-inputs can stay native?

<jpoiret>still, won't you be missing the other inputs?

<janneke>yeah, just looked at that, i have:

<janneke> (inputs '())

<janneke>indeed, that won't work, it'll only give me a cross toolchain

<janneke>minor detail ;)

<janneke>ACTION goes to add a cross-built procedure to map over inputs

<jpoiret>janneke: I have a much better solution! create a file manifest.scm, and in it, use (guix profiles) and (gnu packages hurd), and add `(package->development-manifest hurd #:target "i586-pc-gnu")`

<jpoiret>yes, this exists and seems to do exactly what you expect :)

<jpoiret>then you can `guix shell -m manifest.scm` of course

<janneke>jpoiret: omg, that's so neat!

<civodul>jpoiret: the trick doesn't fully work though because you'd need two profiles: one for native inputs, and one for target inputs, with appropriate env vars

<civodul>it's a low-hanging fruit though, just sayin'!

<janneke>ACTION gets

<janneke>guix shell: error: package autoconf@2.69 does not support x86_64-linux

<janneke>huh?

<janneke>sounds like guix shell -D --target should be doable?

<civodul>it's doable, but like i said we need to change "guix shell" to produce two profiles instead of one

<janneke>ah

<jpoiret>it doesn't? i did manage to create a shell with it though

<jpoiret>under the hood it just uses the usual package lowering mechanism by parametrizing %current-target-system

<civodul>yes, but what abot C_INCLUDE_PATH vs. CROSS_C_INCLUDE_PATH for instance?

<civodul>if it's all in a single profile, it cannot work

<civodul>well, it can work by chance, which is a start :-)

<dcunit3d>i submitted something to the help-guix mailing list, but i don't really see it on here

<dcunit3d>should it pop up in here eventually? https://lists.gnu.org/archive/html/help-guix/2023-05/index.html

<dcunit3d>i mean i'm still learning how to contribute. i've never really sent anything into the mailing list, but i configured GNUS and debbugs in emacs.

<janneke>jpoiret: oh my, your manifest trick works beautifully with master

<janneke>but on your patch set i get

<janneke>(my worktree `x')

<janneke>$ ~/src/guix/x/pre-inst-env guix shell -m manifest.scm

<janneke>guix shell: error: package autoconf@2.69 does not support x86_64-linux

<dcunit3d>is it possible that the help-guix didn't receive my email properly?

<dcunit3d>is this in the help-guix@gnu.org list? Shepherd 0.10: Attempt to suspend fiber within continuation barrier

<bjc>dcunit3d: i don't see it

<dcunit3d>does the email need any kind of formatting? there was a link in it as well. i also added some attachments.

<bjc>oh, help-guix@… i'm not on that list, ignore me

<dcunit3d>i'm on the list, but i'm only getting digest emails. i may be able to start gnus in emacs, but that laptop is down for the moment

<dcunit3d>i mean i think i can still get to GNUS

<anemofilia>Someone knows why this happens when I run "guix system reconfigure /etc/config.scm" ?

<anemofilia> http://0x0.st/Hqb1.txt

<lilyp>anemofilia: no sudo prefix?

<anemofilia>no sudo

<lilyp>:)

<lilyp>there are not many commands that need sudo, but `guix system reconfigure' is one of them

<anemofilia>ah ok

<anemofilia>but then

<anemofilia> http://0x0.st/Hqbj.txt

<anemofilia>I get this

<lilyp>uhm, what?

<anemofilia>Yes, that's my reaction too

<lilyp>that's the first time I'm seeing that one

<lilyp>does your config.scm require anything "weird" like inferiors or stuff?

<anemofilia>I may send my config.scm if you want

<anemofilia>IDK what is a inferior

<anemofilia>I think I didn't anything weird in it

<anemofilia>ttp://0x0.st/Hqb2.scm

<anemofilia>here

<anemofilia>ops, it needs an h at the beggining

<dcunit3d>i'm looking on GNUS and i tried resending my email. I removed my signature in case that's causing problems, but i'm still not seeing the message

<Grimpper>Anyone is suddenly getting a broken package because gettext is not found? I was making a package which I'm currently using but after a guix pull its no longer building...

<Grimpper>This is the error message:

<Grimpper>`../source/data/meson.build:43:5: ERROR: Program 'msgfmt' not found or not executable`

<Grimpper>And I'm adding `gnu-gettext` to the native-inputs. Any ideas?

<alanz>My current "guix pull" is running forever, and had a resident memory size of 28G when I killed it

<alanz>(running on debian testing)

<dcunit3d>civodul jpoiret can someone check the help-guix mailing list and see if my email address is being blocked as spam?

<dcunit3d>it's aionfork@gmail.com

<cbaines>if it's your first time posting dcunit3d, you'll need to wait for someone to approve the message

<cbaines>I've seen the "Attempt to suspend fiber within continuation barrier" error though, if you've seen that please email the details to bug-guix@gnu.org

<cbaines>(that email might take some time to make it's way through as well)

<dcunit3d>cbaines: ah ok. i sent a second one. so i'm not sure if both made it through or not.

<dcunit3d>oh, i see what you're saying. the error message was in the subject line

<dcunit3d>well, the details concerning that were sent to help-guix@gnu.org. i'll just wait before i end up creating a third thread lol

<lilyp>anemofilia: "I want to make this work ..." → s/list/append

<lilyp>you should consider investing in define-syntax for that if you have the time :)

<efraim>dcunit3d: Just let your email through

<lifestronaut>Are there any good but simple guix configs I can use as an example? I've found System Crafter's configs, but that's way too complicated for the simple desktop system I'm looking for

<efraim> https://git.sr.ht/~efraim/guix-config/tree/master/item/3900XT.scm this one is the config for my desktop

<dcunit3d>thanks efraim

<muradm>hi guix

<muradm>sneek: later tell apteryx, could you have change to look at 63198? while it is closed, it has patch within. should i send it separately to have dedicated issue for it?

<sneek>Got it.

<muradm>sneek: later tell apteryx, there is also another one related to PAM but with screen-locker-service-type #63652.

<sneek>Okay.

<muradm>maybe some one else could look at them?

<muradm>#63198 degraded cups in the way that automatic printer detectetion is not working without PAM entry

<muradm>#63652 degrated screen-locker-service-type where it cannot be used for swaylock anymore after it is being compiled with PAM support

<muradm>while workarounds are posible, lack of direct solutions and documentation is very time consuming

<muradm>ACTION back to work

<formbi>hi

<formbi>it seems like «guix pull --news --details» is broken

<formbi>I mean it seems like it has a memory leak, infinite recursion or something

<formbi>it tries to take up all the RAM

<lfam>formbi: Works for me, finishes in a couple seconds

<efraim>formbi: maybe it's related to the commit you've pulled to? what commit do you have from `guix describe`?

<chomwitt>ACTION thanks <ennoausberlin95> for looking

<tschilp>formbi: by what you describe I did have the same thing with e499cb2c12d7f1c6d. 26b71e1982afac91 did not have the memory problem any more, but errored out as well. Yesterday evening's c5bc698e8922d78 brought things to normal for me.

<formbi>efraim: e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5

<janneke>ACTION changes #:make-flags into an upstream patch for the Hurd

<tschilp>formbi: right now's 1638d1f0cecb52a7392d78534e9a0136878759e4 does fine here -- so just running a 'guix pull' before running the 'guix pull --news --details' might solve the problem. The commit you mention is exactly the one, that blew my RAM yesterday too. Thanks to efraim, who saved my brains on that :)

<tschilp>What's the difference between linux-libre and linux-libre-bpf? 'guix show' gives me the same description for both...

<jpoiret>tschilp: I guess the second one has BPF enabled?

<jpoiret>would be nice to have that information in the description though, yeah

<jpoiret>if you don't know what that is, you probably don't need it

<tschilp>jpoiret: and now I have to look up what bpf is, though I most likely don't need it ;)

<formbi>tschilp: ah, maybe the newer one doesn't have a substitute available (I use channel-with-substitutes-available)

<formbi>as for the bpf - it's very annoying when people make a package variant and not put anything new at all in the description

<formbi>but well, that's ok for the holier-than-thou maintainers

<tschilp>formbi: might be -- for my system and home configs everything was there fortunately! Actually still true for the last one I mentioned above (or better -- none of the packages I use got updated since yesterday night, they seem very brand new to me anyway).

<lfam>The lack of package description was surely not intended to annoy anyone or be "holier than thou". It was surely a simple oversight that could be easily corrected

<jpoiret>formbi: maintainers are not the only ones who push commits by the way :)

<jpoiret>and of course, anyone can help review patches!

<formbi>jpoiret: I mean, they sometimes block people's submissions using weird excuses

<formbi>like in the case of ZFS for example

<jpoiret>this might be the worst example of what you're describing

<jpoiret>the case of ZFS is *very* complicated

<formbi>have you read the thread?

<tschilp>jpoiret: totally right, I'm rather sure that I don't need bpf!

<lfam>Lol

<PotentialUser-32>hey, I have a bug when I do "guix system reconfigure config.scm" where it says this:

<PotentialUser-32>guix system: error: symlink: Permission denied: "/var/guix/profiles/system-8-link.new"

<PotentialUser-32>so I add "sudo" before for permission, but then I get this error:

<PotentialUser-32>ice-9/boot-9.scm:1685:16: In procedure raise-exception:

<PotentialUser-32>Git error: error authenticating: no auth sock variable

<PotentialUser-32>anyone an idea what's happening? I'm still pretty new to guix so it's probably a stupid mistake I made.

<jpoiret>formbi: parts of it, but still

<tschilp>PotentialUser-32: It's totally normal that you get a permission denied for a system reconfigure without prepending 'sudo'!

<tschilp>PotentialUser-32: are you running guix system, or installing guix on another distro?

<lfam>formbi, tschilp: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f4474002643efdd1564abbce82bd3df9a574a1e1

<formbi>jpoiret: read the whole thing, my favorite quote is this: «I found myself often changing my mind one way or the other quite often back then, seems like currently it's back to opposal on basis of licensing.»

<tschilp>lfam: now that's what I call quick! Cool!

<PotentialUser-32>tschilp Yeah I know, but it did work some times if I recall correctly. I'm running the guix system.

<jpoiret>formbi: ah, so it's not possible to change opinions over a period of time?

<lfam>I'll quote myself from that thread on ZFS: https://issues.guix.gnu.org/45692#82

<lfam>The problem was mostly that the person contributing the code failed to persuade anybody

<jpoiret>I hope you've never changed your mind! Humans are not infaillible, they are just like you and me, but simply have more responsibilities towards users, hence the reluctance.

<formbi>lfam: ah, it was you…

<formbi>the second best one

<lfam>It was me, that did what?

<formbi>«But until then, contributors are free to make an effort: learn who to contact, build a collegial relationship with them, etc.»

<formbi>is it a software project or a take-me-for-a-beer-or-else project?

<jpoiret>Oh I missed the binding contract towards every possible Guix user that maintainers sign

<lfam>Of course, every project that involves many people requires social skills. Guix is not special

<lfam>If you want to do something that might cause trouble, you better make sure that people have a good feeling about you

<lfam>That's just life

<formbi>so is it about legal stuff or about feels?

<lfam>You might notice that I don't say anything about "legal stuff"

<lfam>I also don't talk about social skills as "feels", because my experience in life has shown me that social skills are the main determinant of success, so I take them seriously

<formbi>What other trouble would it cause? And that was the kind of trouble discussed in the thread.

<lfam>"

<lfam>There is a risk of social problems within GNU if we add ZFS to Guix:

<lfam>there is not a consensus within GNU about whether it's okay to integrate

<lfam>ZFS into our software."

<lfam>To paraphrase, a lot of people would be mad

<lfam>Fewer people are mad if we don't accept the patches

<lfam>Easy choice

<lfam>Let's be clear, I didn't decide this issue. It seems like nobody decided. But I gave my opinion on what happened, and I still think that opinion describes the reality

<tschilp>ACTION is really happy to be an innocent ext4 user reading up the issue with zfs and at the same time never understood raid5

<formbi>I'm sure there are some suckless-like people who are mad that pulseaudio is included

<lfam>Perhaps, but they don't speak up much within GNU

<lfam>In general, suckless and GNU are on different paths

<formbi>I'm not saying they're right, but everything has some people whining about it

<jpoiret>suckless people are probably more annoyed at guix not being configured with a single 10k header file

<lfam>Anyways, nobody can be successful in this project when they insult and curse at people in their patch submission. You'd think it was a joke

<dcunit3d>i'm so confused

<tschilp>PotentialUser-32: are you on your own checkout of guix? If so, I hope somebody else drops in!

<dcunit3d>i've always been hesitant to sign a contract to contribute code. generally, people exclude me from everything anyways.

<formbi>on this I can agree, insulting people isn't nice

<jpoiret>dcunit3d fwiw there's nothing you need to sign to contribute to guix

<dcunit3d>i mean i would just submit patches i guess. i don't think i would want commit access.

<dcunit3d>i'm pretty sure my skill level means that's a non-issue anyways

<dcunit3d>i don't quite understand the hype over ZFS without jails

<tschilp>wow, guix actually has CEPH!

<tschilp>Not so nice for a laptop though

<ieure>dcunit3d, Not sure what you mean by that. Jails like... FreeBSD Jails?

<dcunit3d>ieure: i thought the ZFS file system was integrated with BSD jails or maybe it's the other way around.

<ieure>dcunit3d, No idea. I run it on Linux, the good stuff is _really_ good and the bad stuff is mostly non-critically bad but very annoying.

<ieure>Bad stuff I've run into are like, snapshots and replicating datasets.

<ieure>There are multiple things that try to do this, they're all hideously overgrown very fragile shell scripts. I gave up and set up Syncthing to replicate a subset of my stuff offsite and that worked immediately and with way less horseshit.

<dcunit3d>my exposure to OpenZFS was limited to what I was doing with proxmox. From how the manual indicated the features that it offered (when using proxmox), I used it, but I dreaded any issues that I encountered that would require the cmdline.

<PotentialUser-32>tschilp what do you mean by checkout? If you mean I'm learning and experimenting on my own, kinda, I have someone that helps me but I don't like to trouble him too much. I'm still reading the manual but some stuf is still not easy. I think my problem is linked to the fact that I have a channel from which I pull packages from, and for some reason

<PotentialUser-32>when I reconfigure there is something that he doesn't like. Since it asks for the auth token, I guess I need to put the token I use somewhere, probably in the config.scm I'm thinking, but I'm not sure how yet. there is also a problem with the icecat browser, but I'll probably just uninstall that since I never use it.

<formbi>PotentialUser-32: coule you send your config.scm?

<formbi>could*

<tschilp>PotentialUser-32: I thought you are maybe building guix from a local clone of the repo, I every now and then play with that, but also had some authentication problems (but that was local and gpg, and a misunderstanding on my side). As far as I know git authentication is not supported, so you might be better off putting your channel into a public repo, or if it's public anyway, you could try to use the https instead git url.

<tschilp>s/instead/instead of the/

<PotentialUser-32>tschilp it's from a private repo unfortunately.

<PotentialUser-32>formbi np. where can I paste it?

<formbi>there are many pastebin sites

<ieure>You could go on a pastebinge

<tschilp>PotentialUser-32: I remember having made my repo public to be able to use it. Maybe things have changed in the meantime. At least here I don't see any hint to make it work, the example is using https: https://guix.gnu.org/cs/manual/en/html_node/Specifying-Additional-Channels.html

<bjc>how can i figure out which package in my system config is propagating a pulseaudio input?

<dcunit3d>bjc, it's probably GDM

<civodul>bjc: you can open /run/current-system/profile/manifest, look for "pulseaudio", and walk up the sexp tree from there

<bjc>i'm not using gdm. but this is a more general question

<tschilp>Also on the 'latest' manual there is no hint at using private repos: https://guix.gnu.org/en/manual/devel/en/guix.html#Specifying-Additional-Channels -- if anything has changed, it would be cool to have it there!

<dcunit3d>i tried figuring that out awhile back

<bjc>civodul: ugh ok. i was hoping ‘guix graph’ might have had some neat hidden option =)

<civodul>bjc: you mean "propagate" in the sends of propagated-inputs, right?

<civodul>*sense

<bjc>yeah. i'm not including pipewire directly in my config.scm, but it still ends up in /run/current-system/profile/bin

<bjc>well, pactl et al do

<bjc>oh. the manifest says pulseaudio is being included somehow. does the list there include propagated-inputs?

<bjc>or maybe there's a service i'm using that's pulling it in somehow

<bjc>or maybe i forgot to reconfigure

<formbi>pipewire or pulseaudio?

<bjc>pulseaudio

<formbi>maybe try running just guix system build to be sure it's a separate thing

<bjc>indeed. i just forgot to reconfigure. sorry for the noise

<PotentialUser-32>formbi here is my config.scm https://pastebin.com/m6hV4rCp

<PotentialUser-32>I took out some personal info, but otherwise thats it

<tschilp>How does it come that linux-libre-module-builder uses linux-libre@6.3.3 on a system that's on default 6.2.x?

<tschilp>Can I take some influence on that?

<tschilp>Asking, because my module builds with 6.2.x and fails with 6.3.3 (and I'm not really sure if this all is a good match!)

<tschilp>ACTION just ran 'guix pull -l' and could not find anything about default linux-libre having been upgraded to 6.3.3 recently...

IRC channel logs

2023-05-22.log