IRC channel logs
2025-10-02.log
back to list of logs
<gorilla>kestrelwx: you nailed it. I have gettext, but not -dev <kestrelwx>Oh, qutebrowser tabs are broken for me on master. Well, happy I finally pulled anyway. Good night! <gorilla>configure: error: cannot find required auxiliary files: ar-lib config.guess config.sub compile missing install-sh <RavenJoad>If I have a bunch of tree-sitter grammars that I want to add to Guix through the new Codeberg forge process, should I open one PR for each grammar or one PR for all the grammars? (Each grammar would be their own commit still.) <wlgreet-issue>hi folks...i have a problem with seatd, greetd and wlgreet. A sway user session is ot being started. Drilling down the Problem it seems that bash instead of sway is the default for a user session. <wlgreet-issue>i tried to summarize it here: https://pastebin.com/34fDaUJe ... i am so lost...i checked ./gnu/services/base.scm but not sure i get it right. i do not want to waste your time so apologies for this...to me it seems as (command greetd-user-session-command (default (file-append bash "/bin/bash"))) is used which uses bash instead of sway...not sure <RavenJoad>wlgreet-issue: I assume you at least get a Bash shell when you log in though? <RavenJoad>Then I think you need to provide a greetd-terminal-configuration in the greetd-configuration. You can find this in the manual, (guix) Base Services. <RavenJoad>The greetd-terminal-configuration allows you to provide a session command, which looks like it can be any arbitrary command. I bet that whatever you provide replaces any default for that virtual terminal. <wlgreet-issue>i did, it runs on tty1 ... but whatever i configure i can not get the user session after successfull wlgreet login to trigger greetd to start sway instead of bash.... <RavenJoad>Hmm... If you're using greetd-wlgreet-sway-session, you should not need to provide a configuration to start sway. According to the documentation, sway should "just work". I don't see the (extra-shepherd-requirement '(seatd)) in your greetd-terminal-configuration though. <RavenJoad>There's a minimal snippet in the manual for this. <wlgreet-issue>correct...with the absolute minimum i expected that sway get started as a user session. This is not the case! The base.scm gives me the impression that always " (command greetd-user-session-command (default (file-append bash "/bin/bash"))) " is used...with no way to adapt it...or at least for me <RavenJoad>What if you completely remove the wlgreet-configuration you have there and use the default? <RavenJoad>Also, what is this base.scm you keep referencing? <RavenJoad>I assume you've already deleted the other login-related service types? If removing all wlgreet-configuration does not work, then I am lost. <wlgreet-issue>yep...i went with all defaults and with a lot of messy variations...inbetween i checked another guys config which i knew worked some time ago...all yield the same result now. No matter what i do if i use wlgreet it drops me to bash. i followed the chain to see what ultimatively gets executed ans saw that it was not an error but that bash is <wlgreet-issue>executed actually in the config(see end of https://pastebin.com/34fDaUJe) ... i got some warnings while doing the test pointing me to deprecated services and hoped adapting these parts would help but did not. then checked base.scm and if i am not mistaken it is actually defined there not to start sway but bash <wlgreet-issue>but my scheme skills are to poor to be really sure so...take with pinch of salt <RavenJoad>I don't recall any of the greet-related services having any deprecations. The Scheme config looks fine. What revision of Guix are you on? I have been assuming you pulled recently. <RavenJoad>Ok. So recent enough that my docs & checkout are close enough. <RavenJoad>At this point, I'm baffled how you're getting this behavior. <wlgreet-issue>in regards to deprecations connected to greetd mentioned in bae.scm <wlgreet-issue> ~$ cat git/guix/gnu/services/base.scm | grep greetd | grep depr <RavenJoad>Right, but you aren't using them in your config, so it cannot be something you are doing. <wlgreet-issue>correct but during trial and error i stumbled over them...not all were documented in the documentation...anyway...i tried to "correct" in a diletant way and successed to some point but nothing changed the situation... <wlgreet-issue>have to go to bed now...late here....currently on vacation in bosnia...4 o'clock here...thanks for lending a ear <untrusem>ok so nc package in not in the guix, atleast with not this name, how to find like what package outputs the package with this name i.e `nc` <untrusem>I am not just talking about this package, many package have different binary name <simendsjo>I managed to reconfigure my home! I ended up disabling the tests for python-xmldiff (my system still works at least), patchelfing libxml2.so.2 to libxml2.so.16 for a program, and removing three fonts. This has been troublesome times. <futurile-afk>simendsjo: woah! Great job getting it done, but what a PITA <simendsjo>futurile: Yes, this whole libxml, mesa-updates, python-updates situation has been problematic. I'm wondering why things have been merged even though they are causing so much troubles? Is it because they require full world rebuilds and there simply is not enough resources available for building everything to detect the issues? <untrusem>so is there a way to easily get documentation of stuff in package like `install-file` `invoke` `with-directory-excursion` some might be part of guix and some are from guile, but I want want way to access them with ease <apteryx>how do we produce core dumps with guix system? <apteryx>I've used 'ulimit -c unlimited', as recommended by robin, but I see no 'core' file produced in the current directory. <robin>apteryx, how are you forcing the segfault? <robin>void main(void){*(char*)0=0;} would do it just to test core dumping <apteryx>with (dynamic-call "errno" (dynamic-link)) ;segfault! (suggested by civodul) <mroh>I simply add ("kernel.core_pattern" . "/var/tmp/core-%e.%p.%t") to the sysctl-configuration. <apteryx>the default is 'core' so I'd expect it produces a core file to the current dir <apteryx>robin: I do see an error for 'guix' appear in 'dmesg' <robin>hm, no idea. i think a program might be able to set a SIGSEGV handler, but guile doesn't <apteryx>ah, the installer is able to produce core dumps; there may be a hint there <apteryx>looking at (gnu installer), seems it calls (setrlimit 'core #f #f), and sets the core_pattern. The latter should be optional I guess (the default is "core") <apteryx>setrlimit is part of guile, though undocumented in the 'Guile Reference' manual. <pinoaffe>untrusem: I usually have a guile REPL open, and you can write ",d function" to get its docstring <pinoaffe>though you'll have to first run the relevant (use-modules ...) of course <untrusem>oh thanks, I use geiser-guile repl in emacs, though that does help with getting function information <untrusem>just wanted to know just in case to find out package name from binary <untrusem>pinoaffe, main guix user are emacs user so they must know about this <kestrelwx>I mostly just open guix or guile manual and search for the symbol in index with 'i' bind. <untrusem>the thing is, I think my guix info file is borked, I can't open it <untrusem>I ran 'guix gc --verify="contents,repair"` it fixed the hash for guix-manual but the problem still persists <simendsjo>untrusem: There has been talk of building a database on the build server for this. After building, it can iterate things like bin and libexec to see what binaries it produces. Right now, a web search might be the best way :/ The package names mostly reflects what they are called in other package managers. Some packages are split between several outputs making it even more difficult.. <untrusem>also thanks for your nyxt package in your channel, though ultimately I ditched nyxt <simendsjo>untrusem: I still haven't started using nyxt@4. Used nyxt@3, but ditched it due to instability. I hit quite a few bugs with nyxt@4 right off the bat, but I haven't had the time to look into them. <untrusem>my main reason for ditching nyxt was electron <simendsjo>untrusem: It's basically the only valid use-case for electron though -- building a browser. Don't know what the alternatives are, but it seems things like gtk webview doesn't work as well. <untrusem>what would be the procedure to make your local guix checkout reading for testing packages addition <untrusem>./bootstrap, ./configure --localstatedir=/var, make <identity>zlqrvx-: “python files” is pretty vague, be more specific; where is the code that installs the files? in the phases? again, be more specific <identity>“the Change-Logs section in the manual” that is also pretty vague, was “the manual” GNU Coding Standards? :3 <pinoaffe>zlqrvx-: first of all, try to mention that this change includes python files in build output, *which* python files need to be included, and *why* <pinoaffe>It seems to me like the build process succeeded before, so this is not a case of "Fix build" <identity>hm, the change is just #:include #~(cons* "\\.py$" %default-include) so i guess “python files” is fine. some thing like “#:include python code required at runtime” (not sure if using “#:include” as a word is okay but whatever) <identity>also you do not need ‘cons*’ here, normal ‘cons’ will do <pinoaffe>there might have been runtime errors, or perhaps optional features were disabled - briefly state which of these is the case <identity>zlqrvx-: the link you gave is indeed to the GNU Coding Standards <zlqrvx->Should I include the runtime error message in the description? `File mode specification error: (error Cannot find the module emacs_sage_shell)` <untrusem>so I cloned guix > compiled the scripts > added a package to emulators.scm > tried `./pre-inst.env guix lint <package>` > guix is throwing `guix: lint: command not found` error <untrusem>turns out you need to be in guix shell before using "./pre-inst-env guix lint" <futurile>simendsjo: it's a good question why updates have caused problems recently. The issues around the build farms resources is definitely part of it. I also think it can be quite difficult to know if you're going to break things as I personally find the UI difficult. <simendsjo>futurile: I see you there, I really have no idea what I'm looking at in the Cuirass GUI or how I can navigate. When I locate a failing package, it works fine, but finding out things have failed is beyond me. <futurile>apteryx: are you OK for me to push the fundraising campaign? I resolved most of your requests and there's a blog post in #20 which you might not have seen yet <futurile>simendsjo: for some reason I always seem to land-up with it showing me that it failed on the branch I'm on, but then I land up on some other branch. I think some clever people wget the xml directly which I really need to figure out <umanwizard>Is there a recommended way to get someone to look at PRs I submit to Codeberg? E.g. should I apply specific reviewers ... or is it recommended to just submit them and wait? <trev>umanwizard: i tried begging here. back with the patches you could email the maintainer or last committer to the file. now i think you just wait for someone to add a label or go through the list <simendsjo>umanwizard: It will get looked at eventually, but it might take some time. If it is important/urgent, it helps raising awareness here and/or in the mailing list. There are currently 334 PRs in the queue, and I don't think there are very many reviewers, and it's pretty much all voluntairy work. <umanwizard>simendsjo: To be clear, I'm not criticizing anyone for not looking at my PRs quickly :). I'm really just asking for factual advice/information. <umanwizard>I don't know whether someone would consider the PRs important. One is crucial for Asahi, but that is a niche platform. <futurile>umanwizard: the factual situation is that the patches that go to a specific team are likely to be reviewed. If it is for a non-team it's less likely. Ones that are hard, particularly 'services' are in a tough spot. <umanwizard>Where is the canonical list of teams, if one exists? <futurile>umanwizard: in etc/teams.scm - it specified which files each team cares about <attila_lendvai>characteristic, damn! thanks! i thought the link cleanup has been implemented already... it has fooled me before, and probably a lot of other people. <janneke>ACTION pulls because inkscape...libxslt.so.1: undefined symbol: inputPush, version LIBXML2_2.4.30 <janneke>yay, a pull fixes it; thanks to whoever took care of this! <iamawacko>Why are so many packages so out of date compared to my Arch Linux install? Is there anyway I can switch to latest from a standard install? <iamawack1>I did run `guix pull` both with sudo and without, and even then rclone, for example, is v1.52.3 when Arch is v1.71.1. Sway is 1.10.1 when Arch is 1.11. <kestrelwx>Can somebody 'guix shell vulkan-tools -- vkcube' on a recent commit? <podiki>kestrelwx: confirm it doesn't work (doesn't see vulkan) <podiki>hmm... i can confirm the dlopen call is still patched correctly though <podiki>LD_LIBRARY_PATH=$(guix build vulkan-loader)/lib guix shell vulkan-tools -- vkcube works <podiki>the only dlopen calls in vulkan-headers are the ones we patch <podiki>so i'm confused how come it can't open the library <podiki>you can see in strace it never looks in vulkan-loader though guix size does show that vulkan-headers retains reference to vulkan-loader <kestrelwx>[env] test $ MESA_LOADER_DRIVER_OVERRIDE=zink strace glxinfo 2> glxinfo.strace <kestrelwx>openat(AT_FDCWD, "/gnu/store/6klxb38z8bczscs29i8wq4cqb7x5l5fx-vulkan-loader-1.4.321.0/lib/libvulkan.so.1", O_RDONLY|O_CLOEXEC) = 4 <kestrelwx>That strace probably worthless, but I was curious. <podiki>i think that we need patches to vkcube, vulkaninfo directly; for instance vkcube has libvulkan.so referenced somehow (via strings output) <podiki>thankfully not a problem with vulkan directly i think, just these utils <podiki>kestrelwx: ^ (for when you return) <podiki>should be straightforward to fix with patches like in vulkan-headers <podiki>cannot reproduce with guix shell qutebrowser -- qutebrowser but i get ye olde Could not find the Qt platform plugin "wayland" in "" so maybe this is not in wayland <podiki>can confirm when adding qtwayland to the profile <podiki>but i don't get the same output as you, i just get "WARNING: Backend texture is not a Vulkan texture." <podiki>feel free to ping me here or on codeberg if you go for the fixes to vulkan-tools, otherwise i can get to it later today <podiki>(volk should be able to be removed from vulkan-tools inputs as well) <podiki>assuming it is simple, I'll push the fix directly later <podiki>not sure about qutebrowser though <Deltafire>you copy-pasted the wrong line when viewing the build log <anemofilia>I ran guix pull and my channel derivation couldn't be built <attila_lendvai>someone somewhere paid attention to catch this exception and thus make this error message useless: guix system: error: exception thrown: #<&assertion-failure> <attila_lendvai> --on-error=backtrace helps, but it's something that people need to learn and remember <anemofilia>attila_lendvai: Are you talking with me? Couldn't understand you <attila_lendvai>anemofilia, no, i'm just ranting... guix badly needs a section about error handling in the contributor readme... <yelninei>anemofilia: there is a (exception getaddrinfo-error (value -8)) in the log. -8 is EAI_SERVICE, I dont know yet where this is coming from <attila_lendvai>and the same applies to guile: (unless (pred obj) (raise (make-assertion-violation))) -- not very useful <kestrelwx>Have you tried to 'guix gc -D $the_deriv' and pull again? At a glance. <untrusem>I am seeing you in irc after a long time <anemofilia>kestrelwx: Yeah, gc'ed it and pulled, same thing again <untrusem>anemofilia: I can now say my guix journey is going good, I am contributing packages now :) <anemofilia>untrusem: That's very nice, I'm happy for you :) <gorilla>ieure: IIUC, the most recent tgz files are from 2022. It's supposedly a piece of cake to compile updated tgz. But it's apparently beyond the abilities of at least one humble prospective user of a package manager. <gorilla>Supposedly, a new version is going to be posted in two months, or maybe a little later. <yelninei>anemofilia: Reverting f858b17c13349766275a426572dba9c3c0e70fb5 fixes it for me. The options->transformations probably does not work <gorilla>The v1.5 milestone has no due date and has six open issues. <gorilla>Unprivileged guix-daemon is due Nov 1, but it isn't part of the v1.5 milestone? <ieure>gorilla, Unprivileged guix-daemon merged months ago. I don't think we want to make it the default for the release until things are more solid. <Rutherther>gorilla: why do you think unprivileged guix-daemon should be part of v1.5? <gorilla>There are 4 open issues on the unprivileged daemon milestone <gorilla>Rutherther: I don't say it should be part of it. Just wishing.. <Rutherther>gorilla: why though? The releases are mostly for installation purposes so I don't really see a benefit of having guix-daemon in the release <gorilla>I was looking for some way I might pull a little weight for all the mooching I'm doing. <gorilla>Rutherther: As a person who has made several attempts at guix, I'd prefer to start with an unprivileged daemon. <Rutherther>gorilla: the guix-install.sh script already can install unprivileged guix-daemon, I think that's even the default, but not sure <gorilla>Especially if packages are managed per user, as was indicated to me yesterday. <Rutherther>note that starting with unprivileged daemon doesn't mean you don't have to execute guix-install.sh as root, it's just that the guix-daemon service runs as non root <Noisytoot>my server's been running for 70 days and it's using 3.6GiB (which is more than half of my total RAM) <characteristic>Noisytoot: i think this (or some shepherd memory leak?) was fixed more recently than 70 days ago <gorilla>Rutherther: are there beta/RC runs of v1.5 happening now? <gorilla>can guix update the selinux policy for guix-daemon? <tesseract>does guix packages get security updates in timely manner? <ieure>gorilla, It's already updated, is it not? Just not in a release? <Rutherther>gorilla: no, there is pretty much nothing happening for v1.5 now <gorilla>ieure: what I mean is, after a fresh install with a broken policy, will guix pull fix the policy? <Rutherther>yes, the selinux is correct in current version, it's not correct in the release. It suffices to pull and use the new version, for the initial version you need to 'hack around it' <gorilla>Or is there some other guix command that will update the policy? <Rutherther>I don't think guix pull itself will fix the policy, you would probably have to run that command from the manual yourself <Rutherther>after a new version of guix is released, it will be alright even for the initial version you get after install <gorilla>Rutherther: which command from the manual is that? <Rutherther>"semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil" <Rutherther>after you "sudo guix pull", this will be updated <gorilla>Rutherther: no. That doesn't fix it. That cil file is what is broken. <Rutherther>so you did do "sudo guix pull" and it is still broken? <gorilla>Rutherther: no. I stepped back for a minute. But I've taken a breath and am trying again. <gorilla>I think I have a path that will let me get things installed finally. <gorilla>I was hoping that from there a guix pull would fix 2+ years of updates. <Rutherther>the cil file in 1.4.0 is broken. The latest not. By "sudo guix pull" you get the latest. But as I was saying, yes, for the 1.4.0 it will be broken, so you can either download the file manually yourself and install that, or hack around it by rw remounting store for that one pull <gorilla>Ok. Great. That's similar to what I am trying. <gorilla>If savannah will cooperate, we'll see it it works. <gorilla>ok. will that pull fix all future pulls to pull from the right place? :-) <gorilla>Rutherther: thanks for preempting my pull, btw. You saved me a small frustration. It wasn't working <Rutherther>gorilla: yes, pretty much (after you relog or source the ~/.config/guix/current/etc/profile yourself). Note that this is concerning pull as your user, without sudo, pull as root is concerning what the guix-daemon will be using, so if you're now doing sudo guix pull, that won't fix the default url for you when you use guix normally as your user <gorilla>Rutherther: I've read your comment multiple times. It is confusing for me. It think you are writing that guix will continue to pull from savannah. <gorilla>My user doesn't have a ~/.config/guix <gorilla>So `sudo guix pull` and `guix pull` achieve different things? <gorilla>fwiw, no .config/guix even after `guix pull` <ieure>But def. don't use Savannah. <gorilla>I'm going to wait until my first `sudo guix pull` is complete before I explore any more <Rutherther>gorilla: so the "guix pull" as your user finished without an error and you didn't get "~/.config/guix/current"? <ieure>gorilla, You almost never want to `sudo guix pull'. <gorilla>ieure: except right after a 1.4 install, right? <Rutherther>ieure: you definitely do on foreign distros to update the guix-daemon, you should do that regularly or watch guix-info for security updates and pull at least when there is something new <Rutherther>gorilla: this is one of the the last steps guix pull does, so yes, if it errored, I wouldn't expect to have that file <gorilla>This is not a complaint, just a curiousity. Why does guix pull take so much longer than, say, `apt-get update; apt-get upgrade`? <gorilla>Just the indexing seems to take a surprisingly long time. <nutcase>Hi. guix lint tells me "extra-cmake-modules' should probably be a native input". Is such a thing worth a commit (that can be added to an existing PR)? <hugohugo>nutcase: I usually "commit --amend" and "push --force" such small changes, that seems to be more liked than multiple small commits <nutcase>ok, that was the alternative, I was too lazy to write down in my question ;). Done so now, thanks. <ieure>gorilla, Most of the perf issues with guix pull are issues with libgit2. Though I think there's room to improve the actual downloading. <gorilla>ieure: ok. it looked like git trying to work through commits. That explains it for me. <gorilla>`sudo git pull` did not fix my selinux policy <Rutherther>gorilla: so you executed the semodule -i command after sudo guix pull? <gorilla>Just because it has a 1969 date doesn't mean it didn't change. <gorilla>it did change. I don't know why the funny date. <ieure>gorilla, All files in the store have a timestamp of 0, for reproduceability. <gorilla>Does guix have a default list of packages, even on foreign distros? <gorilla>Is a git pull going to pull in a bunch of apps that are already available through the native distro? <Rutherther>guix pull created/updates only two commands: guix and guix-daemon <gorilla>and creates/updates ~/.config/guix ? <Rutherther>~/.config/guix/current, yes, that is where those commands are located (or rather those are only symlinks pointing to /var/guix/per-user/$USER/current-guix that symlinks to the /gnu/store somewhere) <bdju>guix pull still telling me "nothing to be done" while another guix command tells me my installation is 9 days old... <bdju>I don't use any channels, I don't think I even have that file. <Rutherther>that seems unlikely. Are you sure /etc/guix/channels.scm and ~/.config/guix/channels.scm do not exist? <bdju>I am sure the latter doesn't exist. I'll check /etc. <bdju>i do not have /etc/guix at all. <bdju>Nevermind, I had to ls with sudo... <bdju>(list (channel (name (quote guix)) (url "https://git.savannah.gnu.org/git/guix.git") (branch "master") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))))% <Rutherther>if it's only readable by root, it doesn't matter either way <Rutherther>but I would suggest to remove this file either way as it refers to the old git.savannah.gnu.org <bdju>Oh. It worked until prettey recently. <bdju>I'm pulling now and it says git.guix.gnu.org, nice. Hopefully this does something now. <umanwizard>Perhaps this is inflammatory, but what is the reason for the commit message format that Guix follows? Spelling out exactly which variables you changed just repeats the same information `git diff` can tell you, AFAICT. <gabber>any other recommendations for a pastebin (termbin also doesn't work for some reason) <trev>umanwizard: it's less of a hassle once you use the snippets that autogenerate that stuff :\ <gabber>umanwizard: it helps a reviewer of your commit judge whether you actually do what you intend to (: <ieure>umanwizard, I believe it's done that way because of the email patch flow we'd been using prior to migrating. I've read some folks expressing that it doesn't seem to be as needed now that we're off that, but no official change has been proposed or discussed. <gabber>it is a bit clumsy for minor changes, but really helps track the introduction of bugs. that way you can search git log for commits that touch certain parts of our code base <umanwizard>gabber: Isn't that what "normal" commit messages are for? Like, I'm not against the idea of commit messages in general that explain what/why is being done. It just seems silly to recapitulate the output of git diff in prose -- "Variable foo: added.\nVariable bar: updated from 3.12 to 3.13" and so on. <ieure>gabber, I don't know how valuable that is, since you can look at the diffstat to see the ground truth of what the patch touched. <umanwizard>FWIW this is by far the most annoying part of committing to Guix, for me as an occasional commiter who has to re-look-up the format every time. <trev>i re-added yasnippet cause of it heh <gorilla>Are all packages installed per user? Is it possible to install a package system-wide? <ieure>gorilla, You can install packages in the system, but it's discouraged. Usually nothing other than the essentials of getting the system booted and users logged in are in there. <umanwizard>gorilla: i.e., what are you trying to accomplish? <ieure>gorilla, Clarifying, you can install system level packages with Guix System. I don't think you can with Guix on a foreign distro. <gabber>no recommendation of a (currently working) pastebin? anyone? <umanwizard>Rutherther: then install using normal distro mechanisms; apt-get or dnf or whatever <gorilla>Say I want to install a web browser for all users, for instance. <ieure>gabber, 0x0.st. But paste.debian.net seems up to me. <characteristic>Change Log format is fairly bare-bones, no? when i first opened the GNU Coding Standards i expected there to be much more stuff than what boils down to () and <> for scope, [] for conditional changes <ieure>gorilla, This generally isn't how Guix systems work. <gorilla>Rutherther is right about my not being on Guix System <ieure>gorilla, Users are given the choice what to install. In the case where multiple users install the same thing, only one copy is actually on disk, in /gnu/store. <Rutherther>gorilla: sure you can make yourself a system-wide profile like /guix, ie. "guix package -i librewolf -p /guix", then add "GUIX_PROFILE=/guix; . $GUIX_PROFILE/etc/profile; unset GUIX_PROFILE" to a custom file in /etc/profile.d <ieure>gorilla, Note that "the same thing" is probably more precise than you expect, ex. the same version of the same package may not be the same thing. <characteristic>if anything GNU Change Log frequently seems insufficient for what i want to express in commit messages <umanwizard>characteristic: well, that is part of the problem <umanwizard>It mandates writing a recapitulation of `git diff`, which is not actually useful, making commit messages basically pointless <gabber> i reconfigured my pinebook pro system for the first time, now it won't boot. the boot medium seems intact (the root partition is there, mountable and seemingly complete). any ideas on how to fix that? http://0x0.st/KM_n.scm <Rutherther>gabber: what state does it get to? what are the errors/what unexpected happens exactly? <gabber>umanwizard: there's two factions to this discussion. i think most people agree that for small changes (new packages, simple updates) it somewhat doubles the work, but i strongly believe that it helps keeping our code clean and the repository in a fine state where you can - just by looking at the commit history text - tell what happens to the code <gabber>Rutherther: no error, it just doesn't boot. maybe i should get the special cable and inspect the serial output... but i don't have that handy right now <characteristic>umanwizard: but what if a commit includes changes that were not intended to be commited? with Change Log, you have a confirmation that yes, this is something that was put there intentionally <umanwizard>gabber: You can also tell this by running `git log -p`, with the bonus that it is guaranteed to be accurate. I still don't grasp the value of being able to see it in `git log` instead of `git log -p`, other than having to type three fewer characters. <umanwizard>characteristic: Somehow every other software project I've ever contributed to manages without this feature, FWIW. Presumably reviewers should check that random unrelated code isn't included. <characteristic>umanwizard: how do you know that the unrelated code is really unrelated? how does somebody a year afterwards know that? <umanwizard>characteristic: if the reviewer doesn't understand a change and how it is related, they can ask (and probably should, before accepting the review) <gabber>umanwizard: in slightly bigger patches you explain *why* you create the diff you commit. including maybe issue numbers and greater goals you are trying to achieve. without adequate commit messages you have to read code and *guess* why stuff happens <umanwizard>gabber: Yes. That is the type of commit message I am actually in favor of / actually think it's a good thing that they exist. <gabber>and nobody is accusing you of anything (: <umanwizard>But I'm not talking about those, I'm talking about the messages that painstakingly restate every variable in the diff that was changed <gabber>i think the current state is the result of some historic growth, where we started with the (truly not crafted for our use-case) ChangeLog format, which we changed on the go and now we're just repeating what we've been doing for a bit more than a decade <bdju>Rutherther: Thanks for the help with the channels file! Finally I can get a working version of yt-dlp again. You've made my day. <gabber>i think — as always — we as a project are open for solid ideas that (ideally) all (or at least the vast majority of contributors) can stand behind <characteristic>umanwizard: nobody forces anybody to painstakingly restate every variable or file affected by the change, something like “src/*.scm (prefix-*-suffix): Remove.” is perfectly acceptable <characteristic>it would be funny if somebody would submit a commit in change log format that uses a fairly complex regular expression to describe the variables affected… <gabber>characteristic: i may be mistaken but i think regex is excluded from the ChangeLog explicitly <characteristic>gabber: i do not see any mention of that anywhere in my copy of GNU Coding Standards <gabber>For example, some people are tempted to abbreviate groups of function names by writing '* register.el ({insert,jump-to}-register)'; this is not a good idea, since searching for 'jump-to-register' or 'insert-register' would not find that entry. <characteristic>i guess they *do* force you to painstakingly restate every file and variable affected <gabber>again, like this you can grep commit messages and *know* when some variable was touched <umanwizard>gabber: "like this you can grep commit messages and *know* when some variable was touched" -- again, what stops you from using `git log -S`, `git log -p`, or `git blame` to do this? <umanwizard>ah, sorry, reading more closely, I guess you weren't advocating for that format, just explaining the reasoning