<lfam>I agree that it's a little bit confusing currently, but it's something that packagers only have to learn once, and it's really quite minor. Whereas changing it would cause confusion for a while because of external channels. And the benefit of the change is small
<leoprikler>The German Wikipedia entry for instance claims (wrongfully), that the FSF calls the MIT License "X11 License".
<leoprikler>So German native speakers, some of which are not lawyers, might be misled into thinking that those two are the same, when they are not
<leoprikler>admittedly, calling them "expat" and "x11" may not be a great thing either if someone down the line decides to change apply another license to those projects, but that's where we stand right now
<terpri>the Reactive License vs. the calm noble gas of the GNU GPL (v1, or, at your option, any later version)
<kmicu>I want to state before I go to sleep that I understand conservative approach and those are valid points. I personally prefer prioritizing future over past so that’s why I weigh arguments differently.
<terpri>Formbi, it uses guile datastructures internally now, but the macros are actually fexprs although not typically used as such. so might take a while to fully guilify it (considering that i have slightly more useful things to do ;))
<lfam>hendursaga: Send an introductory email to <email@example.com>. You'll get a reply with a bug-ticket email address to send your patch series to. If the new packages depend on each other, they should all be sent to this address
<hendursaga>lfam: I saw as much from the manual. I suppose each one should have a subject line the same as the first line in the commit message?
<lfam>hendursaga: If you use `git send-email`, it will write the subject line for you. Otherwise, just attach all your patches to an email and write a subject that is useful
<hendursaga>lfam: So just one email to guix-patches with all attached patches files?
<hendursaga>Honestly an patch series from the mailing list might be the best example, lol
<FennecCode>Hey, can anyone help me with this? I'm trying to stream files from the internet using MPD, and I'm getting a "CURL failed: server certificate verification failed. CAfile: none CRLfile: none" in ncmpcpp when I try to play them. Does anyone have any ideas?
<pkill9>FennecCode: you may need to add nss-certs to your system's packages
<pkill9>although there may have been a change that has libcurl search for them in user profiles too
<peanutbutterandc>Does anyone here have any idea if it is possible to trace a procedure defined inside of another procedure in guile? Using something like (add-trace-to-procedure-call!) from (system vm trap-state)?
<bonz060>When inheriting from a package, how do you modify the values from, say the propagated inputs? Instead of copy pasting the whole block?
<pkill9>bonz060: you can 'splice' them in by doing (propagated-inputs `(,@(package-propagated-inputs inherited-package) ("another-input" ,another-input)))
<pkill9>and you can replace an input by 'splicing' them in but with an input deleted, by doing `(,@(alist-delete "input-to-remove" (package-propagated-inputs inherited-package)) ("another-input" ,another-input)))
<apteryx>alextee[m]: the best person to answer the question regarding hurd development on the childhurd vm would be janneke
<alextee[m]>i'm on the same boat as damo22 in wanting a viable hurd system for audio work and daily use
<janneke>ah yeah, that's going to need some more effort still, but things are looking good
<c4droid>Someone know how to change default desktop login manager? like change sddm from gdm
<alextee[m]>nice, sounds like there's good progress from the mailing lists. i guess i'll wait a bit more and start reading background info until the VM and whatever damo's working on is in a good state
<pkill9>just having an option to make it strict would be useful
<pkill9>my specific case was building a newer version of wlroots, the package definition patches an absolute path to Xwayland in one of the files, but the new version doesn't reference the Xwayland binary anymore in the file that normally gets patched
<bavier[m]1>it's possible to make `sed` exit with non-zero code if it didn't replace anything
<bavier[m]1>so anyhow, I wouldn't mind if substitute* could similarly be made optionally strict
<lxsameer>hey folks, sorry if it's not so much related to guix , but i'm planning to use guix SD, but i don't have a free wifi adapter, do you have any suggestion for a 5Ghz support adapter that is free?
<janneke>lxsameer: i got an atheros card from thinkpenguin.com
<bonz060>When you pass python(3) as a propagated input, how would you make it be python, so that when you entered in an isolated environment, the command for running python is python instead of python3?
<janneke>(and nonfree stuff can never be cool at all)
<kmicu>(There’s plenty of amazingly cool libre hardware but wifi/bt lacks any reverse engineering / liberation efforts. Only old chipsets from chinese stocks are available.)
<apteryx>with Google sponsoring free hardware runs on 130 nm tech, hopefully that will change.
<apteryx>lxsameer: I'm using a desktop one from thinkpenguin that does 5 GHz. It's a bit but shipped fast and never had an issue with their products (it just works). Aliexpress is a good option if you have more time to research and don't mind the slow shipping I guess.
<LibreCat>vagrantcish: but when i extract a precompiled program like multimc(open source launcher for a propritary game) and then try to launch it it says that the file doesnt exist when it definietly does
<LibreCat>and when i try to run an installed flatpak it says that its not installed when it is
<vagrantcish>LibreCat: no need to highlight me explicitly ... many more experienced guixers around than me :)
<str1ngs>LibreCat: it's probably because the dynamic linker /lib64/ld-linux-x86-64.so.2 does not exist on Guix system
<LibreCat>vagrantcish: /gnu is consuming the inodes
<kmicu>LibreCat: that ext4‑out‑of‑inodes issue is pretty common on NixOS where they don’t have deduplication turned on by default. It also nothing unusual on Guix System if you are using a diverse software and there’s not much to deduplicate.
<str1ngs>janneke: orgianlly I wanted to have good C-h support. but there is alot to do there to get that working.
<LibreCat>kmicu: will going source based fix this issue
<LibreCat>kmicu: or making the system more generic
<kmicu>LibreCat: are you asking about ext4 being static with inodes allocation or specifically about the issue on your computer? If the latter then you need to uninstall stuff and garbage collect or switch to a btrfs where they allocate inodes as needed.
<lfam>No, you'll need to increase the number of available inodes (if possible) or recreate your filesystems
<lfam>I think these sorts of discussions assume that ext4 never has problems. But it does, especially with Guix. It's tanked our CI in the past due to the directory lookup hash table limitations, and `df` does not help understand what is going on when that happens
<lfam>So, we have to choose which errors we want to deal with
<lfam>In the meantime, btrfs has lots of nifty features
<kmicu>lfam: of course ext4 has issues but known issues. DF reports correct free space for it.
<lfam>If you have a directory with too many entries, the tooling will incorrectly report that you are "out of space"
<lfam>You have to read ext4 source code to understand what is happening
<lfam>This is a real problem we've dealt with multiple times for Guix users
<kmicu>I know how to check, how to balance, what to avoid, I read btrfs manuals and wiki. I am happy to have btrfs as default but I absolutely to not recommend it for casual users checking btrfs free space with df.
<lfam>Formbi: Right, sounds like we need to extend that functionality
<lfam>I think that casual users will use a GUI, not command-line tools
<lfam>We have different ideas of what a casual user does
<kmicu>Do they report correct free space for btrfs?
<lfam>I think a casual user does not know that Guix keeps old profile generations (or what a profile generation is), until we explain to them why their ext4 filesystem stopped working
<apteryx>kmicu: what's all the fuss with df? unless you take snapshots, it seems accurate enough. And then as a btrfs user you should know to use 'btrfs filesystem df' if you care about splitting metadata from data.
<kmicu>Then expect more dragons after switching to btrfs as default ;)
<lfam>But, if somebody knows about what filesystem they are using, what df is, etc, then they can learn to use `btrfs filesystem df`
<kmicu>Great, because that not even a correct command to check allocations. 🤦
<kmicu>apteryx: it’s not accurate when you run out of space durign guix switch and then garbage collector is stuck.
<lfam>Anyways, these are choices that will be made by the people who will manage bug reports
<lfam>It's largely the same group of people who triage bugs, fix bugs, and change Guix code
<kmicu>apteryx: Then you cannot simply remove some files because btrfs allocator is stuck too.
<lfam>They are very sensitive to the problem of creating new bugs and won't change the default filesystem without serious consideration
<lfam>Also because there are not many potential choices. 3 options at most
<apteryx>kmicu: well, running out of space is an edge case which I'd reckon is difficult to handle well by any file system (akin to like how your kernel handles your machine running out of RAM). I'll take that over inodes exhaustion while I still have GiB of free memory any time, though.
<apteryx>kmicu: 'btrfs filesystem df' is not what I should use to check for storage use by Btrfs? What should I use then?
<ryanprior>All this talk just prompted me to run `guix gc` and free up 20gb =X
<kmicu>apteryx: I get you could prefer that. That’s ok. I only share my expreriance because I was using btrfs with NixOS before Guix System even existed. I saw all those issues many times and I was active on #nixos with support. I knew inodes issue gonna show up on Guix System before first user reported that.
<lfam>I think it's not that useful to compare btrfs from before Guix to current time
<lfam>That's the timeframe in which the filesystem reached maturity
<apteryx>kmicu: I'm asking, because I'm genuinely interested to know.
<apteryx>on my box 'df -h /' reports 126G used, while 'btrfs filesystem df /' reports 131GB if I sum the data and metadata components.
<kmicu>apteryx: I strongly recommend sudo btrfs fi usage /
<kmicu>If you find broken inodes during balance then hit #btrfs with btrfs ins dump-tree
<kmicu>BTW this is from my workstation [ 347.773456] BTRFS critical (device dm-0): corrupt leaf: root=258 block=516751360 slot=55 ino=6829917, invalid mode: has 00 expect valid S_IF* bit(s)
<lfam>Something that *would* be annoying is users discovering broken hardware that they didn't know was broken previously, and blaming that on Guix
<apteryx>kmicu: neat. Doesn't seem required to use sudo for 'btrfs filesystem usage' on Guix.
<lfam>It happens whenever people adopt software that actually checks for data corruption and I see it all the time in other projects that do that
<kmicu>That issue is from btrfs. It was already diagnosed.
<lfam>There is lots of bad RAM and faulty SATA controllers that people have been happy with for years
<apteryx>kmicu: there's more data reported but the important bits are the same as with 'btrfs fi df /'
<lfam>They might find it with a Git repo but the space usage is usually too small in Git for it to crop up
<kmicu>apteryx: important bit is allocator. Do you see it in df?
<apteryx>You mean this line? Device allocated: 262.06GiB
<kmicu>Yes, how much unallocated space there’s is on your disk from btrfs fi df / output?
<LibreCat>i have 250 gb ssd as root and i had 130 gb of free space when there were no inodes
<kmicu>Usually to recover from that wee need to free some inodes by deleting some files and then run gc. Simple. On btrfs… well, we can start with btrfs balance start -dlimit=2 / because deleting files will not simply unallocate free space.