<terpri>gnu recommends against mit because it's "misleading" and "ambiguous", but at some point it may be worthwhile to reconsider whether common usage has simply shifted <terpri>against calling the license "mit", i should say <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 <lfam>This shed has been painted for a long time <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 <leoprikler>Well, the Expat License, but people are not that strict when it comes to pattern matching. <leoprikler>While the GPL is often copied in full, shorter licenses like the "MIT license" can have their formatting changed and what not while still remaining the same. <leoprikler>And I dare say most would not question it if you say "don't worry about those minor details, they're the same" <kmicu>Any contributor should always diff licence, chece it text. Id is only a pointer and nowdays ‘expat’ is a confusing pointer. No wonder FSF points to SPDX’s mit too xD <leoprikler>Well other licenses like the FreeBSD have links directly to the source, so pointing to spdx is actually a step removed <terpri>leoprikler, re: de wp, nich mehr :) *terpri spreche ein bisschen Deutsch <kmicu>Deutch is eine chance fur bessere Zukunft they said but I forgot it anyway. 😺 <terpri>aber ich bin technisch richtig, und das ist die beste Weise, in richtig zu sein ;) <leoprikler>Technisch richtig sind der französische beziehungsweise englische Eintrag, aber die sind beide etwas verboser ;) <terpri>tbh i have to look it up almost everytime i package an MIT^H^H^HExpat-licensed program, because SPDX, OSI, Git{hub,lab}, etc. all call it thus <terpri>i admit to having said "MIT/X11-style license" and the like in the past, but this might be a trivial issue where the world has moved on <leoprikler>We could also call it the "React License" to stay in the touch with the hip young folks. <terpri>SPDX listed first for a reason, as it might become a de facto standard for license info, akin to ISO 639-$n$ for language tagging <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>i was porting an ancient window manager (GWM) to use Guile Scheme for scripting, in addition to its own Lisp dialect, and found a GPLv1+ script :D <terpri>dated 1992, v2 was in use by 1994 in other script files <Formbi>terpri: and how is the porting going? <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 ;)) <Formbi>now I'm using StumpWM, but the key specifications are annoying <Formbi>one can't easily tell it to use things like C-x C-s :/ <Formbi>(this would be useful in remapping) <terpri>GWM-2 did use guile-1.8 but was also almost a complete rewrite, iirc. "inspired by" gwm-1.x but totally different internally <terpri>interesting that someone got it working with guile 2.x, though <Formbi>I think it's fine if the overall behavior is generally the same <terpri>well, and no backwards compatibility with the various "profiles" (mwm, fvwm, twm, etc. emulation) or other extension scripts <terpri>nothing wrong with it, just not what i'd expect as v2.0 (but, knowing the 1.0 internals, i can certainly understand why they might have wanted to do a complete rewrite :)) <lfam>brettgilio: Does it work if you run the command outside of the Guix build enviroment? <brettgilio>lfam: yep. also when you just run (lambda _ (invoke on it <brettgilio>its when the apply step comes in that it starts to break <brettgilio>NieDzejkob: besides applying the invokation to configure-flags yeah <brettgilio>it's like it stops after applying the config flags and doesnt finish running the configure script <pkill9>how do you change the gcc version used by gnu-build-system? <brettgilio>NieDzejkob, lfam for some reason the configure script returns exit 0 when using the --enable-extras flag. Which is indeed why it was not finishing <brettgilio>I dont know perl well, but removing the exit 0 does fine <brettgilio>something tells me just removing exit 0 isnt the "right" solution, but... meh <brettgilio>ohhh i see. this is actually supposed to be 2 distinct configure steps <pkill9>how do i know if it's properly overwriting the gcc provided by the build system? <NieDzejkob>it usually tells you which compiler it's going to use <brettgilio>pkill9: If you're worried you can pass the gcc in your inputs as a makeflag <pkill9>also how do i find out what arguments a build system accepts <brettgilio>pkill9: if it isnt listed check the build system definition :) <pkill9>i checked and there is nothing mentioning gcc <pkill9>i swear the manual mentioned what arguments are allowed <leoprikler>I think in meson you'd pass it to #:configure-flags <leoprikler>but you may also try setting CC in a pre-configure phase <pkill9>no, i need to specify the gcc package for the build system to use <pkill9>configure-flags is for specifying configure flags for the package <pkill9>this would be an argument for the build system in guix <pkill9>i.e. (arguments `(#:build-system-argument .. <brettgilio>pkill9: this doesnt need to be its own argument though <pkill9>because it said 'cross-gcc' so i thought it's for cross-building <brettgilio>the easiest way I think is still just a make flag setting "CC=" the gcc by passing it as an input key ***catonano_ is now known as catonano
<hendursaga>Say I was trying to package some software, and then, so that it builds, I have to package some dependencies. How do I send that to guix-patches? As a patch series? Or separately? Or what? <pkill9>hendursaga: you send it as a patch series for each package <lfam>hendursaga: Send an introductory email to <guix-patches@gnu.org>. 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 <pkill9>so try just `guix package -i nss-certs` <FennecCode>I have it installed, but it's out of date. I'm updating that now. This hasn't worked for me on previous versions either, though <FennecCode>If I can remember right, I have it installed as part of the system, and I also have it installed as user <pkill9>have you updated mpd? libcurl was updated to have a default search path for certificates <pkill9>anything using libcurl failed to access https in the past <pkill9>but then it got patched to look for them in $SSL_CERTS i think <FennecCode>I can't remember if my MPD is running as system or as user... <FennecCode>I have SSL_CERT_FILE and SSL_CERT_DIR set, but not SSL_CERTS <FennecCode>So I am running it as user. I'll try updating mpd as well. From there I'll try restarting it and see if that does it <apteryx>nckx: I think my offload now hang up pretty often too <FennecCode>pkill9: Hey, so I got it working by running it as user. I had it started as a service, and that was causing the problem finding the certificates <apteryx>brettgilio: you can precompute your list from the host side, i.e., unquote it <jsoo>brettgilio: use map instead of for-each <jsoo>Yes what apteryx said. for-each returns nothing <jsoo>brettgilio: +1 excellent <lfam>hendursaga: I recommend doing whatever is comfortable for you. If you have specific questions I'm happy to answer the <apteryx>Does Jan Wielkiewicz hang around here? <lfam>What do you mean by "returning a broken link on cgit"? <brettgilio>just a moment ago it would return an unknown repository error <str1ngs>brettgilio: I had some weird 504 issues this morning. so could be an issue with reverse proxy on savannah <str1ngs>brettgilio: also on savannah the git directories are mounted so if there is an issue with the mount it will break link on cgit. I've seen that before. it usually comes back eventually ***apteryx_ is now known as apteryx
<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)? <kmicu>Hi LibreCat Installing a font with a good unicode coverage (GNU Unifont in worse case xD) should fix the issue of missing glyphs. <kmicu>I cannot recommend anything because it’s a matter of personal preference. There are corporate fonts with good coverage (like Noto) or academic one like Symbola. <bonz060>In guix when build how do you append multiple paths using the -L flag? <bonz060>This doesn't seem to work: `~/guix/pre-inst-env guix build -L "~/projects/guix-bioinformatics:~/projects/guix-past/modules" python3-genenetwork2/` <alextee[m]>like compile something and then run the hurd guix vm to test it <pkill9>I feel like substitute* should raise an error if it doesn't make all the substitutions it's told to <pkill9>if the source changes and a substitution doesn't have any effect, it would highlight that <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 <efraim>bonz060: guix build -L ../guix-bioinformatics -L ../guix-past/mdules <janneke>alextee[m]: it depends, the childhurd vm is starting to work very well. the biggest hurdle right now is that we don't have many official substitutes or a build farm setup yet. <alextee[m]>janneke: i really want to join hurd development but I am not good with low level/hardware things so being able to develop and do everything with the guix VM would be a big help <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 <janneke>it allows you to build guix from git in the chilhurd <janneke>i don't have a real roadmap, personally i'm "waiting" to get our build farm up to speed <apteryx>thanks for answering the questions that many seem interested in (including myself)! <c4droid>I'm changed the default login manager from gdm to sddm, and reconfigured system, after reboot, the system is start gdm not sddm, someone can tell me why change gdm not success? <janneke>apteryx: yw, really a blog post or at least an updated roadmap/status is somewhat overdue but that's a lot more helpful once we have substitutes -- almost there <str1ngs>sneek later tell c4droid. you may need to remove the gdm service from %desktop-services. (modify-services (remove (lambda (service) <str1ngs> (eq? (service-kind service) gdm-service-type)) <apteryx>pkill9: yeah, substitute* matches sed in behavior. It doesn't fail when it doesn't do anything. It's a double edged sword. <pkill9>apteryx: does it need to match sed? I don't think of them as the same <NieDzejkob>I'll probably add an option like 'one-file apart from #f and #t, because using it together with (find-files) is somewhat common <NieDzejkob>It'll need a bit of a larger refactor, since substitute handles one file at a time, so passing the information around would be somewhat tricky <apteryx>pkill9: it's sometimes useful: you can pass a set of replacement rules to a list of files in a single substitute* call, even if some rules don't apply to some files. <apteryx>but perhaps we could have a flag that'd say: throw an error when no substitution were made, such as: #:strict #t (which would default to #f for backward compatibility) <pkill9>though I think it would be better to have a function that takes a list of pairs of files with their substitutions <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 <apteryx>pkill9: I agree with you that it'd be more maintainable if everything was more strict with regard to substitute* patching. <apteryx>it'd force us to remove obsolete patching <apteryx>or warn us useful patching is no longer having the expected effect <bavier[m]1>`t` starts a new cycle if there was a successful substitution, the `q1` quits with exit code 1 <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 <janneke>yes i'm using a dell xps-13; there are (at least) two types of PCIe card for laptops <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? <LibreCat>for some reason the gnome shell on guix is much smoother compared to arch ubuntu debian testing fedora all running 3.36 <LibreCat>i guess its placebo from using libre gnu/linux <kmicu>lxsameer: you can search aliexpress for Atheros AR9280, besides that oldie there’s nothing newer. <lxsameer>kmicu: i was looking at BrosTrend 1200Mbps , apparently it's popular in raspberry pi community but i don't know whether it has open firmware or not <kmicu>They also use ‘Kali’ term in product name because those libre chips can be used for penetration “testing” 😺 <kmicu>(Libre shops like Thinkpenguin add a ‘libre tax’ and their offering is sometimes order of magnitude more expensive.) <lxsameer>kmicu: but i don't know about that brostrend one, is it libre ? <kmicu>lxsameer: it looks like that brostrend has a Realtek 8812au chip so for sure that’s proprietary. Only old Atheros 9 chipsets or very old and very specific Broadcom B43 are libre. <kmicu>(Nothing modern or cool in wifi/bt space is libre.) <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. <lxsameer>apteryx: could you please paste me a link <janneke>hmm, we have no substitutes available for wine <janneke>and weirdly, an attempt to build wine does not offload (unlike an attempt to build other packages) <janneke>ah, i have no i686-linux offload host defined -- hmm, is that new? <janneke>yeah, that's it: add an i686-linux host; thanks for listening, folks :-) <vagrantcish>"guix environment --pure guix -- make authenticate" is failing with "/bin/sh: line 1: guix: command not found" <LibreCat>i dont think the 5ghz thinkpenguin pc is any different than a custom pc with a libre wifi card and integrated graphics <LibreCat>vagrantcish: sorry this is my 2nd day at guix <NieDzejkob>vagrantcish: It uses your host guix to authenticate, you can try guix environment --pure guix --ad-hoc guix <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 <str1ngs>assuming you are on x86_64 of course <LibreCat>do i need to build from source with a bunch of enviroment variables <str1ngs>LibreCat: if you can't build from source you can create a special-files-service-type service for ("/lib64" ,(file-append glibc "/lib")) <LibreCat>i ran guix install gimp and left the computer now i see that i cant build a profile <str1ngs>janneke: hello, did you every need to use (emacsy coroutine) <str1ngs>LibreCat: In procedure symlink: No space left on device . check with df -h / <apteryx>ha! perhaps the number of inode is depleted? I'm not sure how that would be reported <str1ngs>LibreCat: is /var on another partion? maybe check with df -h if any mount is at 100% <apteryx>then I think that's the end of it. You need to run 'guix gc'. <apteryx>I think newer fs such as Btrfs do not have such inode limitation <apteryx>OK. Not sure then, but I'd guess yes. <str1ngs>I've never run out of inode with ext4 and I've had my /gnu get as larges as 150g <LibreCat>well guix gc cleaned up 4.8 gib of space <apteryx>LibreCat: that's very little. I wonder what else is using them up. <str1ngs>janneke: have you had any experience with emacy's (emacsy coroutine) module? <raghavgururajan>How do I get all the 3 places of a version in the syntax `,(version-major+minor (package-version foo))`? <str1ngs>janneke: if you recall the prompt not found issue. it relates to coroutine's. And I'm trying to reason how to best handle them. <janneke>aiui it's from sdl2 and shares similarities with 8sync <str1ngs>janneke: this for example will provide a prompt for message. (codefine* (co-message fmt . args) (apply message fmt args)) <str1ngs>but for read-from-minibufffer that does not work. <LibreCat>what argument should i use for mkfs.ext4 <str1ngs>janneke: I'll have a good look at it. I was just curious if you understood the module <janneke>str1ngs: i only played a bit with 8sync's agenda and abort-to-prompt...not really with this coroutine/codefine* <janneke>str1ngs: i looked at the new nomad release -- pretty nice <vagrantcish>LibreCat: you really need to figure out what is eating your inodes to know what sort of arguments or mitigation strategies you need <janneke>the thing i missed most is a help page listing all key bindings, in theh end i took a look at the source :-) <vagrantcish>LibreCat: if you have a *lot* of small files, it consumes inodes faster <NieDzejkob>raghavgururajan: if it's docbook-xsl you're packaging, ,version will also work <LibreCat> Filesystem Inodes IUsed IFree IUse% Mounted on <LibreCat>/dev/nvme0n1p2 13402112 12875592 526520 97% / <LibreCat>looks like my linux knowledge is unbalenced *vagrantcish tries to update linux-libre to 5.8 <vagrantcish>gotten as far as validating all the various signatures and hashes *vagrantcish ponders making linux-libre-x86-64-generic based on the defconfig <str1ngs>janneke: I was thinking of looking at 8sync. since daviid says it plays well with glib. Thanks for looking at nomad. there are still some rough edges. This is the first release using g-golf <str1ngs>janneke: I'm defiantly going to have the start page be a keybind primary. just focused on core browsing being stable right now. <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. <janneke>i haven't looked at g-golf and it's been over a year that i looked at guile-gi... <str1ngs>janneke: thanks for the feed back the keybind start page will be next on my list :) <LibreCat>ok what is considered to be a generic guix system <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 <kmicu>If you still have some free space then garbage collector should still work. <lfam>Did you remove old generations? <apteryx>yes, but not in the context of clearing up inodes ;-) <lfam>They are useful, but you're out of space <lfam>I'm curious, was this filesystem created by a Guix tool? Or maybe by another distro? <LibreCat>how can i remove all previous generations <lfam>Are you using Guix System, or Guix on another distro? <lfam>Okay, there are generations for each user, and generations for the system <lfam>And `guix system` will handle the system generations <lfam>So, `guix package --delete-generations`, and `guix system delete-generations`. Not the mismatch in hyphens <lfam>I mean, *note* the mismatch <lfam>After you delete old generations, the garbage collector will be able to delete more stuff <lfam>LibreCat: Do you remember how the filesystem was created? <lfam>Gotcha, so it wasn't done by the Guix installer, but "by hand" <lfam>The defaults for mkfs.ext4 are tuned for old-school distros like Debian <lfam>Sounds like it needs some attention before the next release <LibreCat>when i selected a disk option the install restarted so i did it manually <lfam>I've heard other reports about this <LibreCat>as a result i am using the gnome-xfce scm file <lfam>Sadly it's not much fun to debug the installer since... you need to install a new OS to do so <LibreCat>maybe removing xfce would free up some space <lfam>I think it would be a great candidate for a hackathon day <LibreCat>uhm dh command not found maybe restart after guix gc completes <lfam>Unfortunately, ext4 is solid and works well but its defaults are about 10 years out of date <apteryx>lfam: the Disk Partitioning section which has ext4 examples mention nothing special about inodes <lfam>apteryx; Yes, and I looked at (gnu installer parted) and it also does not pass any special options to `mkfs.ext4` <apteryx>this would be a good place to add something. We could also patch mkfs.ext4 directly to have better defaults in the context of Guix. <lfam>I think we should change the installer to do the right thing. Patching mkfs doesn't feel right <lfam>We could always ask upstream to change the defaults <lfam>I remember the main ext4 issues being 1) inode exhaustion and 2) directory hash table too small <lfam>The hash table issue is even worse because the information is not exposed by command line tools <apteryx>or we could revisit the suggested default file system <lfam>Yes, we could. I use btrfs by default and I find that it works well, but I worry about what people will say if we default to it <apteryx>there was an issue tracking making Btrfs such suggested file system in a future release <lfam>There are many vocal but ignorant people on social media <lfam>Unfortunately, they tend to control the narrative. Many people still seem to think that btrfs doesn't work because of those loudmouths <ryanprior>Fork btrfs and call it gnuboringfs with no changes, then you can stealthily default to it without putting out a bat signal to loudmouths <lfam>I always thought that BoringSSL was a genius bit of marketing <lfam>Well I will support whatever choice we make <lfam>Whether we stay with ext4 or change to btrfs <Formbi>Guix disk specification doesn't handle btrfs too great <lfam>What do you mean Formbi? <lfam>bavier[m]1: It's possible to do online conversion from ext4 to btrfs <kmicu>I recommend staying with ext4 unless Guix wants to patch basic tools like df and educate users how to maintain filesystems with btrfs. <kmicu>Otherwise you just trade inode issues for ‘mysterious’ ENOSPACE issues. <lfam>What do you mean kmicu? I haven't had to really do any special maintenance on btrfs. And all the while we are helping users deal with inode exhaustion on ext4 <kmicu>lfam: not even balancing and checking for errors? <lfam>kmicu: I check for errors sometimes but it's not required. I've never found one. I don't know about balancing <apteryx>kmicu: btrfs doesn't magically eat your space unless you do take snapshots. <kmicu>btrfs magically create I/O errors and df magically reports wrong free space. <lfam>I've never seen "magical errors" <lfam>This is the kind of FUD I was worried about having to address <kmicu>I’m using btrfs everywhere don not recommend using it as default when even common tools does not report correct free space. <apteryx>if you don't know or don't care about btrfs features, the experience for a user is pretty much like the same as with good old ext4 <kmicu>lfam: this is not FUD. I’m a btrfs user. <lfam>Whatever we call it, "magically create I/O errors" is not useful information <kmicu>I have I/O on my disk right now. I consulted the situation with btrfs devs. <kmicu>If you are not running check periodically you can have them too. <apteryx>kmicu: only disk errors I've had with Btrfs was when my CPU was running at > 85 celcius because the fan was broken. And I could recover from it! ***terpri__ is now known as terpri
<kmicu>apteryx: did you run check recently? <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. <kmicu>I am using btrfs by choice. I find it better but that doesn’t make it a good default. <Formbi>lfam: I can't boot my computer when I set options in my file-system thingies with btrfs <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 <lfam>I don't know kmicu. I hope so <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>Which is why it has never been changed <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? <apteryx>It's double the space usage reported by 'df -h /', which makes sense given I'm using RAID1. <kmicu>How much unallocated space is reporeted for you with btrfs fi usage? <kmicu>The issue with Guix/Nix and btrfs is that it can report free space with fi df but it can have no space for allocation. It’s inode issue just more difficult to diagnoze and recover from. <apteryx>with 'btrfs fi df /' -> 121 GiB data + 10 GiB metada = 131 GiB <kmicu>What about Unallocated in fi usage? <apteryx>it does, if I do the maths to difive everything in half (RAID1) <kmicu>If that’s the case and those numbers are still synchronized then I assume you did not hit full disk too many times on that system. <apteryx>Device total (2x 1 TB drives) is 1.82 TiB, Device unallocated is 1.56 TiB, which is about 1.82 TiB - (2 * 0.131 TiB). <kmicu>1.56TiB unallocated‽ Did you had full disk there even once ;)? <kmicu>Then I can assure you btrfs will work flawlessly for you. <apteryx>OK, so what you are saying is that btrfs badly handles disk space exhaustion (and corrupts itself?) <kmicu>I have 250GiB disk on this laptop and I was forced to recover many times from nixos-rebuild or guix reconfigure. <kmicu>apteryx: I state that recovery from full disk on btrfs is more difficult than from inode issues on ext4. <kmicu>and Guix user will hit that issue because common tools, gui or not still, do not report correct free space for btrfs <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. <LibreCat>because everyone's setup is slightly diffrent <LibreCat>and as they install their favorite programs the generations build up <apteryx>kmicu: having to delete files when you still have 130 gb of free space is... suboptimal. <LibreCat>also why is guix downloading packages when i am removing flatpak <LibreCat>is this a source based distro with prebuilt binaries for most common setups <LibreCat>if it is i might choose to go full source based because my cpu is powerful enough <alextee[m]>i also wonder why guix sometimes downloads packages when you remove stuff *vagrantcish would make a wild guess it has something to do with grafts <apteryx>LibreCat: probably you guix pull'd since you last refreshed your profile and when your remove something? <kmicu>apteryx: it is, I get that. The only thing I’m sharing is that getting ENOSPACE on btrfs when it shows many GBs of free space and then performing non trivial recovery could be worse. <apteryx>vagrantcish: that seems a good guess ;-) <kmicu>apteryx: fun fact, regular df tool can report 60GiB of free space before guix reconfigure and then in a second go to 0GiB and after that garbage collector stops working. <vagrantcish>why guix does what it does is sometimes pretty counterintuitive, even if it's actually correct <LibreCat>why did the install gnome 3.32 mesa 19 etc when the latest version was available <LibreCat>also was a manual install with gnome+xfce profile <vagrantcish>the installer is from the last release, there have been many updates since then *vagrantcish hasn't played with the installer much at all <LibreCat>maybe you should use better ext4 defaults in the automatic installer and write them in the documentation for manual users <vagrantcish>guix generally can be fixed without reinstalling, which is a good thing. probably keeps the installer development incentive relatively low, though :) <LibreCat>and explain the options and their reason <kmicu>LibreCat: in practice hitting inode issue is rare (even on NixOS). You are the lucky winner ;) <kmicu>(I guess because you experimented with a lot of desktop environments and setups so Guix System accumulated a lot of unique files.) <kmicu>Then I dunnno what could generate so many unique files. I hope not Gnome. 🤷 <vagrantcish>many aborted builds leaving around small .drv files?